• Yonggang Luo (36/36) Oct 30 2008 This is care about druntime.
• Jarrett Billingsley (4/11) Oct 31 2008 I think those module names are hard-coded into the compiler, and
• Sean Kelly (45/83) Oct 31 2008 The current setup is for modules that are compiled into the runtime

Yonggang Luo <yonggangluo hotmail.com> writes:

This is care about druntime.
The trunk version is 40 
First, in file root/trunk/import/core/bitmanip.di, 
The 8th line of this file is 
"module bitmanip;" I don't know if it's must be change to module
"core.bitmanip" 

And I think the files 
exception.d 
memory.d 
runtime.d 
thread.d 
also to be place in the floder root/trunk/import/core/ will be better. (Just a
advice) 

And I am curios the three files in the folder root/trunk/import/std 
Is this possible to migrate these three files to folder root/trunk/import/core/
? 
It's should be more meaningful, means these three file is not a general
library, It's just used by the compiler, OR 
The compiler intrinsic functions, so it belong to 'core', (Just a advice, maybe
it's impossible); 

It's possible be a good idea is we migrate the file object.di to the folder
root/trunk/import/core/  
so we have the 

module core.object 
module core.bitmanip 
module core.exception 
module core.memory 
module core.runtime 
module core.thread 

module core.intrinsic for replacement of std.intrinsic  


and we have 
module core.stdc.* 
module core.sys.windows.* 
module core.sys.linux.* 
module core.sys.posix.* 

and for c 
we have a special module 
module core.stdc.stdarg; for replacement for std.stdarg and std.c.stdarg. 

And I don't know why we need two stdarg file? 
one is std.stdarg, and the other one is std.c.stdarg? 
It's so strange. but the content of these two file is the same. 

So it's should be file is we merge these two file.

"Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:

On Fri, Oct 31, 2008 at 1:02 AM, Yonggang Luo <yonggangluo hotmail.com> wrote:
 This is care about druntime.
 The trunk version is 40
 First, in file root/trunk/import/core/bitmanip.di,
 The 8th line of this file is
 "module bitmanip;" I don't know if it's must be change to module
"core.bitmanip"

You're probably right about that one.

 And I am curios the three files in the folder root/trunk/import/std
 Is this possible to migrate these three files to folder
root/trunk/import/core/ ?

I think those module names are hard-coded into the compiler, and
therefore can't be moved yet.  So once DMD is fixed, they can move.

Sean Kelly <sean invisibleduck.org> writes:

Yonggang Luo wrote:
 This is care about druntime.
 The trunk version is 40 
 First, in file root/trunk/import/core/bitmanip.di, 
 The 8th line of this file is 
 "module bitmanip;" I don't know if it's must be change to module
"core.bitmanip" 

It should.  Thank you for catching this.

 And I think the files 
 exception.d 
 memory.d 
 runtime.d 
 thread.d 
 also to be place in the floder root/trunk/import/core/ will be better. (Just a
advice) 

The current setup is for modules that are compiled into the runtime 
library to live in src, while import holds header modules both for 
building the runtime and for distribution.  The build process for 
druntime publishes .di files for the modules you list above into 
import/core, however, auto-generated header modules aren't terribly 
readable.  What I'd done in Tango was to use a code beautifier on these 
files during the export process, but then the beautifier I was using 
broke and I had to disable it.  So... I have considered both manually 
creating legible headers as well as simply copying the source files 
during the build process, but I'm still undecided about how best to 
handle this.

 And I am curios the three files in the folder root/trunk/import/std 
 Is this possible to migrate these three files to folder
root/trunk/import/core/ ? 
 It's should be more meaningful, means these three file is not a general
library, It's just used by the compiler, OR 
 The compiler intrinsic functions, so it belong to 'core', (Just a advice,
maybe it's impossible); 

The compiler has the locations of intrinsics hardcoded, so the std 
modules currently exist by necessity.  I hope that in a few more 
releases, DMD might change to look for these in core instead, but it's 
something that hasn't been discussed yet.  For the moment my priority is 
simply to get the runtime functional, finalize the locations of stuff, 
naming, build options, etc.  So while I consider the "std" thing to be a 
hack, it's one that's pretty much invisible to users and so isn't a top 
priority.

 It's possible be a good idea is we migrate the file object.di to the folder
root/trunk/import/core/  
 so we have the 
 
 module core.object 
 module core.bitmanip 
 module core.exception 
 module core.memory 
 module core.runtime 
 module core.thread

This is an interesting idea, but I'm not sure it buys us anything. 
Wherever it lives, the object module will be implicitly imported into 
all D modules.  So the location of this module is really only relevant 
from a filesystem standpoint... plus potential namespace collisions, I 
suppose.  Another issue is that currently, the compiler runtime 
implements this module, and this code is distinct and separate from the 
'core' code.  So moving object into core might confuse things from a 
responsibility standpoint somewhat.

 module core.intrinsic for replacement of std.intrinsic  

core.bitmanip fills this need right now.  It's been brought up before 
that 'bitmanip' may not be the best name for this module (I think Don 
may even have submitted a ticket about this), but I haven't come up with 
anything better yet.

 and we have 
 module core.stdc.* 
 module core.sys.windows.* 
 module core.sys.linux.* 
 module core.sys.posix.* 

Yup.

 and for c 
 we have a special module 
 module core.stdc.stdarg; for replacement for std.stdarg and std.c.stdarg. 
 
 And I don't know why we need two stdarg file? 
 one is std.stdarg, and the other one is std.c.stdarg? 
 It's so strange. but the content of these two file is the same.

They're the same right now, but they may not remain the same in the 
future.  We need two because each provides vararg support for a 
different calling convention.  So you should use std.stdarg (though 
perhaps this should be in core) for D functions and std.c.stdarg for C 
functions.

 So it's should be file is we merge these two file.

See above.  Personally, I'm now inclined to have:

core.vararg
core.stdc.stdarg

The C stuff in druntime isn't currently being built into a library, but 
that may change.


Sean