• Fredrik Olsson (7/7) Oct 27 2006 I am looking into using D for an embedded system, for this GDC for ARM,
• Chris Nicholson-Sauls (5/15) Oct 27 2006 You could take a look at Ares to get a good idea. The only ones I know ...
• Sean Kelly (14/30) Oct 27 2006 A few other modules needed offhand:
• Sean Kelly (4/31) Oct 27 2006 Oops, I think syserror is for converting system errors to strings and is...

Fredrik Olsson <peylow gmail.com> writes:

I am looking into using D for an embedded system, for this GDC for ARM, 
and some tweaking of Phobos needed.

For this I find most of the functionality in Phobos is kind of 
superfluous. So my question is, what are the bare minimum needed to get 
D up and running? And would it not be a good idea to move this from 
std.* to say core.* or equivalent?


// Fredrik Olsson

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Fredrik Olsson wrote:
 I am looking into using D for an embedded system, for this GDC for ARM, 
 and some tweaking of Phobos needed.
 
 For this I find most of the functionality in Phobos is kind of 
 superfluous. So my question is, what are the bare minimum needed to get 
 D up and running? And would it not be a good idea to move this from 
 std.* to say core.* or equivalent?
 
 
 // Fredrik Olsson

You could take a look at Ares to get a good idea.  The only ones I know for
sure are 
module 'object' and package 'std.internal'.  Giving the required runtime code
its own 
'core' package (or whatever name) isn't a bad idea.

-- Chris Nicholson-Sauls

Sean Kelly <sean f4.ca> writes:

Chris Nicholson-Sauls wrote:
 Fredrik Olsson wrote:
 I am looking into using D for an embedded system, for this GDC for 
 ARM, and some tweaking of Phobos needed.

 For this I find most of the functionality in Phobos is kind of 
 superfluous. So my question is, what are the bare minimum needed to 
 get D up and running? And would it not be a good idea to move this 
 from std.* to say core.* or equivalent?


 // Fredrik Olsson

 
 You could take a look at Ares to get a good idea.  The only ones I know 
 for sure are module 'object' and package 'std.internal'.  Giving the 
 required runtime code its own 'core' package (or whatever name) isn't a 
 bad idea.

A few other modules needed offhand:

std.thread
std.asserterror
std.cover (for -cov, not used by gdc)
std.moduleinit
std.outofmemory
std.switcherror
std.syserror
std/typeinfo/*

Aside from import dependencies by the code in internal, I think that 
about covers it.  And you can stub out the thread code if you aren't 
targeting a multithreaded system.


Sean

Sean Kelly <sean f4.ca> writes:

Sean Kelly wrote:
 Chris Nicholson-Sauls wrote:
 Fredrik Olsson wrote:
 I am looking into using D for an embedded system, for this GDC for 
 ARM, and some tweaking of Phobos needed.

 For this I find most of the functionality in Phobos is kind of 
 superfluous. So my question is, what are the bare minimum needed to 
 get D up and running? And would it not be a good idea to move this 
 from std.* to say core.* or equivalent?


 // Fredrik Olsson

 You could take a look at Ares to get a good idea.  The only ones I 
 know for sure are module 'object' and package 'std.internal'.  Giving 
 the required runtime code its own 'core' package (or whatever name) 
 isn't a bad idea.

 
 A few other modules needed offhand:
 
 std.thread
 std.asserterror
 std.cover (for -cov, not used by gdc)
 std.moduleinit
 std.outofmemory
 std.switcherror
 std.syserror

Oops, I think syserror is for converting system errors to strings and is 
not an error handler itself.  This one shouldn't be necessary after all.


Sean