www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Some advice about druntime.

reply 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.
Oct 30 2008
next sibling parent "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.
Oct 31 2008
prev sibling parent 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
Oct 31 2008