www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Criteria for 1.0 (was: Re: If D becomes a failure, what's the key reason, do you think?)

reply "Tony" <ignorethis nowhere.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e8n9mi$2flp$1 digitaldaemon.com...
 Kyle Furlong wrote:
 *Standing Ovation*

Yeah, that's concerned me as well. But it isn't just me trying to make it perfect, everyone's got their favorite bug/feature that must get in before 1.0. So what do you say we just call D right now *1.0* and move on? It's not like D will stop undergoing improvements.

I've taken the liberty of making this a new thread as the old one was getting a little long. Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release. My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made. For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release. Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0. This still leaves bug fixing and additional language features which don't break existing code for post-1.0 releases. Tony Melbourne, Australia
Jul 07 2006
next sibling parent reply kris <foo bar.com> writes:
Tony wrote:
 "Walter Bright"  wrote 
So what do you say we just call D right now *1.0* and move on? It's not
like D will stop undergoing improvements.

I've taken the liberty of making this a new thread as the old one was getting a little long. Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release. My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made. For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release. Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0. This still leaves bug fixing and additional language features which don't break existing code for post-1.0 releases.

Hear Hear! One thing to add, though, is a certain /level of expectation/ should be accomodated without significant issue. We don't want to announce a grand opening, so to speak, and have loads of new folks rush through the doors and simply fall through holes in the floor. Would be a public-relations disaster. Given that aspect, I suspect there's still certain outstanding "major issues" that really ought to be addressed first? There's no point in jumping the gun if you're going to take a dive at the first hurdle. Would there a problem with setting a schedule for release, rather than just being a tad reactive? I mean, what's another month or two to those who really want the language to succeed?
Jul 07 2006
parent Dave <Dave_member pathlink.com> writes:
kris wrote:
 Tony wrote:
 "Walter Bright"  wrote
 So what do you say we just call D right now *1.0* and move on? It's not
 like D will stop undergoing improvements.



My vote too, but in line with what Kris mentions below I think it's important to see the following addressed either through better docs. or (if it is a bug) a fix for v1.0: digitalmars.D.bugs/7649 - Dave
 I've taken the liberty of making this a new thread as the old one was 
 getting a little long.

 Walters post raises the issue of exactly what criteria should be used 
 to determine when D reaches a state suitable for a 1.0 release.

 My personal take is that it should be a 1.0 release when Walter 
 believes that all of the language changes which are expected to break 
 existing code have been made.  For example, if he expects to add any 
 further reserved words, reserve them (even if not presently 
 implemented) prior to the 1.0 release.  Also, any change which alters 
 the semantics of an existing feature and thus breaks existing code 
 should be made prior to 1.0.

 This still leaves bug fixing and additional language features which 
 don't break existing code for post-1.0 releases.

Hear Hear! One thing to add, though, is a certain /level of expectation/ should be accomodated without significant issue. We don't want to announce a grand opening, so to speak, and have loads of new folks rush through the doors and simply fall through holes in the floor. Would be a public-relations disaster. Given that aspect, I suspect there's still certain outstanding "major issues" that really ought to be addressed first? There's no point in jumping the gun if you're going to take a dive at the first hurdle. Would there a problem with setting a schedule for release, rather than just being a tad reactive? I mean, what's another month or two to those who really want the language to succeed?

Jul 07 2006
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Tony wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:e8n9mi$2flp$1 digitaldaemon.com...
 Kyle Furlong wrote:
 *Standing Ovation*

Yeah, that's concerned me as well. But it isn't just me trying to make it perfect, everyone's got their favorite bug/feature that must get in before 1.0. So what do you say we just call D right now *1.0* and move on? It's not like D will stop undergoing improvements.

I've taken the liberty of making this a new thread as the old one was getting a little long. Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release. My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made. For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release. Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0. This still leaves bug fixing and additional language features which don't break existing code for post-1.0 releases. Tony Melbourne, Australia

With the latest posts on template issues (some are labeled bugs, some are labeled 2.0), I believe there are two major problems with the current implementation and/or specification (and a whole bunch of niggles, but those might just qualify as bugs): - The const issue - Visibility and accessibility rules I think both are far from being able to be labeled as "just bugs", and if any of them are fixed with steel wire and strong tape, then they will be revisited with double strength post 1.0 release. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jul 08 2006
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Tony wrote:
<snip>
 Walters post raises the issue of exactly what criteria should be used to 
 determine when D reaches a state suitable for a 1.0 release.
 
 My personal take is that it should be a 1.0 release when Walter believes 
 that all of the language changes which are expected to break existing code 
 have been made.  For example, if he expects to add any further reserved 
 words, reserve them (even if not presently implemented) prior to the 1.0 
 release.  Also, any change which alters the semantics of an existing feature 
 and thus breaks existing code should be made prior to 1.0.

Yes, that's part of it. AISI the prerequisites for 1.0 readiness are: (a) a clear, complete and consistent spec (b) a fully documented and reasonably clean standard library (c) all known serious compiler bugs and most not-so-serious compiler bugs fixed (d) as you say, sufficient stability that any language or standard library changes are unlikely to break existing code (e) agreement among all of us that the above have been achieved Stewart.
Jul 11 2006
next sibling parent Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 Tony wrote:
 <snip>
 Walters post raises the issue of exactly what criteria should be used 
 to determine when D reaches a state suitable for a 1.0 release.

 My personal take is that it should be a 1.0 release when Walter 
 believes that all of the language changes which are expected to break 
 existing code have been made.  For example, if he expects to add any 
 further reserved words, reserve them (even if not presently 
 implemented) prior to the 1.0 release.  Also, any change which alters 
 the semantics of an existing feature and thus breaks existing code 
 should be made prior to 1.0.

Yes, that's part of it. AISI the prerequisites for 1.0 readiness are: (a) a clear, complete and consistent spec (b) a fully documented and reasonably clean standard library (c) all known serious compiler bugs and most not-so-serious compiler bugs fixed (d) as you say, sufficient stability that any language or standard library changes are unlikely to break existing code (e) agreement among all of us that the above have been achieved

I don't think that any of those are achievable until a 1.0 language feature freeze happens. The language needs to be stable for months before there's any chance of a 1.0 library such as you describe. And I think that (e) is impossible.
Jul 11 2006
prev sibling parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e90ai8$26ve$1 digitaldaemon.com>, Stewart Gordon says...
Tony wrote:
<snip>
 Walters post raises the issue of exactly what criteria should be used to 
 determine when D reaches a state suitable for a 1.0 release.
 
 My personal take is that it should be a 1.0 release when Walter believes 
 that all of the language changes which are expected to break existing code 
 have been made.  For example, if he expects to add any further reserved 
 words, reserve them (even if not presently implemented) prior to the 1.0 
 release.  Also, any change which alters the semantics of an existing feature 
 and thus breaks existing code should be made prior to 1.0.

Yes, that's part of it. AISI the prerequisites for 1.0 readiness are: (a) a clear, complete and consistent spec

That'd be nice. I don't know if the current gaps in the spec are big enough to prevent D 1.0 though.
(b) a fully documented and reasonably clean standard library

I don't think we should wait that long. Phobos isn't perfect, but I think it's good enough for D 1.0.
(c) all known serious compiler bugs and most not-so-serious compiler 
bugs fixed

I think there could be quite a few not-so-serious compiler bugs in D 1.0 release. But they have to be hard to find for D newcomers.
(d) as you say, sufficient stability that any language or standard 
library changes are unlikely to break existing code

Or at least, the code wouldn't break until around D 2.0.
(e) agreement among all of us that the above have been achieved

I hope by "all of us" you mean "most of us" or "many of us" because "all of us" won't ever happen. jcc7
Jul 11 2006
next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
jcc7 wrote:
 Tony wrote:
 (b) a fully documented and reasonably clean standard library

I don't think we should wait that long. Phobos isn't perfect, but I think it's good enough for D 1.0.

I agree on that. As I see it phobos is a library using a very productive style, through sometimes their is parts missing. A good standard library dont have to bee bloated or monolithic. However I think their is a few issues in phobos that need to be fixed before 1.0, most notably string functions for wchar[] and dchar[] and standard containers (others can certainly think of other things). But I think that thees shortcomings can bee quickly solved (a few months maybe 1 or 2) once we get a feature freeze of the specification.
Jul 11 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e90gih$2f7i$1 digitaldaemon.com>, Johan Granberg says...
jcc7 wrote:
 Tony wrote:
 (b) a fully documented and reasonably clean standard library

I don't think we should wait that long. Phobos isn't perfect, but I think it's good enough for D 1.0.

I agree on that. As I see it phobos is a library using a very productive style, through sometimes their is parts missing. A good standard library dont have to bee bloated or monolithic. However I think their is a few issues in phobos that need to be fixed before 1.0, most notably string functions for wchar[] and dchar[] and standard containers (others can certainly think of other things). But I think that thees shortcomings can bee quickly solved (a few months maybe 1 or 2) once we get a feature freeze of the specification.

I just think calling it "D 1.0" is about the language specification being frozen (which could happen soon), and the standard library doesn't need to be fully fleshed out for D 1.0. It'd be nice if it were (I'm not trying discourage people from pointing out the problems in Phobos or offering fixes), but I think D 1.0 needs to arrive sooner rather than later to help with D's public image. D has been in development for many years, and eventually people just shrug and say, "Yeah, D might be nice, but it's just an experiment with no major releases in sight". jcc7
Jul 11 2006
next sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
jcc7 wrote:
 I just think calling it "D 1.0" is about the language specification being
frozen
 (which could happen soon), and the standard library doesn't need to be fully
 fleshed out for D 1.0. It'd be nice if it were (I'm not trying discourage
people
 from pointing out the problems in Phobos or offering fixes), but I think D 1.0
 needs to arrive sooner rather than later to help with D's public image. 
 
 D has been in development for many years, and eventually people just shrug and
 say, "Yeah, D might be nice, but it's just an experiment with no major releases
 in sight".
 
 jcc7

that I think should bee fixed before 1.0. I agree that a 1.0 should bee released soon, a good target release date would bee in october, september. that way we could have a feature freeze in the language in august and make some cleanup (bugs and phobos) before 1.0.
Jul 11 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
jcc7 wrote:
 In article <e90gih$2f7i$1 digitaldaemon.com>, Johan Granberg says...
 jcc7 wrote:
 Tony wrote:
 (b) a fully documented and reasonably clean standard library

good enough for D 1.0.

style, through sometimes their is parts missing. A good standard library dont have to bee bloated or monolithic. However I think their is a few issues in phobos that need to be fixed before 1.0, most notably string functions for wchar[] and dchar[] and standard containers (others can certainly think of other things). But I think that thees shortcomings can bee quickly solved (a few months maybe 1 or 2) once we get a feature freeze of the specification.

I just think calling it "D 1.0" is about the language specification being frozen (which could happen soon), and the standard library doesn't need to be fully fleshed out for D 1.0. It'd be nice if it were (I'm not trying discourage people from pointing out the problems in Phobos or offering fixes), but I think D 1.0 needs to arrive sooner rather than later to help with D's public image. D has been in development for many years, and eventually people just shrug and say, "Yeah, D might be nice, but it's just an experiment with no major releases in sight". jcc7

I agree 1.0 should be soon (as-in certainly by winter considering an RC with all features frozen and such), however I just want to point out that 5-6 years seems about right for a new language gestation so I'm not overly concerned that we're behind the curve there. For example, I think Java as we know it was conceived in early '91 and didn't really take off until early '96 or so, right? I think Walter started work on D in '01.
Jul 11 2006
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
jcc7 wrote:
 In article <e90ai8$26ve$1 digitaldaemon.com>, Stewart Gordon says...
 Tony wrote:
 <snip>
 Walters post raises the issue of exactly what criteria should be used to 
 determine when D reaches a state suitable for a 1.0 release.

 My personal take is that it should be a 1.0 release when Walter believes 
 that all of the language changes which are expected to break existing code 
 have been made.  For example, if he expects to add any further reserved 
 words, reserve them (even if not presently implemented) prior to the 1.0 
 release.  Also, any change which alters the semantics of an existing feature 
 and thus breaks existing code should be made prior to 1.0.

Yes, that's part of it. AISI the prerequisites for 1.0 readiness are: (a) a clear, complete and consistent spec

That'd be nice. I don't know if the current gaps in the spec are big enough to prevent D 1.0 though.

These certainly are big enough from where I am: http://www.digitalmars.com/d/archives/digitalmars/D/21572.html http://www.digitalmars.com/d/archives/26273.html Regarding the latter, Walter has mentioned the idea of an implicit pinning system, but it has yet to make it into the spec.
 (b) a fully documented and reasonably clean standard library

I don't think we should wait that long. Phobos isn't perfect, but I think it's good enough for D 1.0.

But cleaning up some of the functions in std.socket to throw an exception rather than practising the dreaded art of using return values to indicate error conditions is something that'd better be done sooner rather than later so that it doesn't break too much existing code. Stewart.
Jul 11 2006
prev sibling next sibling parent reply Tim Starling <tstarling wikimedia.org> writes:
A few comments as an outsider and a latecomer to this thread.

I did "fall through the holes in the floor" as one poster put it, about 6 
months ago, when I ran into bug 8 on my second experimental project. I made 
the decision at that point to wait until the language was a bit more stable, 
which I judged would take a few years.

Personally I have never found visibility or const to be effective debugging 
tools. I would be quite happy if they were entirely ignored in an initial D 
release, optionally allowed for documentation purposes as a replacement for 
e.g. /*private*/, which is the effective access control keyword we used for 
years in PHP 4. Truly useful debugging tools are things like meaningful 
compiler error messages and exceptions. Or if you want a pipedream, a 
segfault handler which detects NULL pointer dereferences and converts them 
to exceptions.

If it's impractical to fix all bugs before a release, then allow the bugs to 
be documented as comments on the official documentation. That way the 
developer can avoid surprises. I think the documentation would greatly 
benefit from a more open editing model: put it on a CMS, give 20 people 
write access, and allow unauthorised comments on the same page. I could have 
easily avoided bug 8 if the linker issues were noted at the bottom of the 
std.boxer page.

Why is Walter the only person who ever fixes bugs in the compiler? This 
seems to slow the whole project down. Why not move the free frontend source 
to a versioning system and give 10 people write access? Then Walter can 
produce DMD binaries from the improved multi-developer source code, and 
everyone else can produce GDC binaries from the same source. Maybe some 
interfaces would have to be cleaned up, but I would think it would be well 
worth the effort, in the long term.

-- Tim Starling
Jul 11 2006
parent Dave <Dave_member pathlink.com> writes:
Tim Starling wrote:

[Good points snipped for brevity]

 
 Why is Walter the only person who ever fixes bugs in the compiler? This 
 seems to slow the whole project down. Why not move the free frontend 
 source to a versioning system and give 10 people write access? Then 
 Walter can produce DMD binaries from the improved multi-developer source 
 code, and everyone else can produce GDC binaries from the same source. 
 Maybe some interfaces would have to be cleaned up, but I would think it 
 would be well worth the effort, in the long term.
 

A compiler perhaps more than 95% of the rest of the software out there is subject to "a change in one thing could break several others". The other part is that this is not like GCC C or C++ where there is an agreed upon and very detailed language spec; the D spec is still evolving here and there as it needs to right now. As to compiler development productivity: Walter makes a new release every month or so on average, most of them with either several bug fixes and/or a new feature or two. I don't see that from any other compiler vendor out there, OSS or not :)
 -- Tim Starling

Jul 12 2006
prev sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Tony wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e8n9mi$2flp$1 digitaldaemon.com...
 
Kyle Furlong wrote:

*Standing Ovation*

Yeah, that's concerned me as well. But it isn't just me trying to make it perfect, everyone's got their favorite bug/feature that must get in before 1.0. So what do you say we just call D right now *1.0* and move on? It's not like D will stop undergoing improvements.

I've taken the liberty of making this a new thread as the old one was getting a little long. Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.

Here's something that has been annoying me, and this week-old thread is as good a place as any to bring it up: Shared library support on Linux. I could not take D seriously if it did a "1.0" release without this. I do hate to cram more on your plate, Walter, but I consider this a more serious issue than even this import thing that has gripped the newsgroup for the past week. Now, I am undoubtedly biased: This is a feature that makes Pyd vastly more useful. This is true to the point that many potential users of the library would dismiss it outright -- laugh in my face, even! -- if I suggested they use it when it lacks Linux (and even Mac!) support. Until D gets shared libraries on Linux, Pyd will be little more than a toy. I have little comprehension of the technical hurdles involved here. Still, I would consider this to be a high priority for the language. I will probably be ready to announce the first "release" of Pyd within the month. However, I cannot recommend it as a useful library without Linux support (where Python has a certain degree of popularity). I can see D being appealing to the Python crowd. I know some regular posters in this newsgroup are into the language (back me up on this, guys), and I come from it myself. The utility of Pyd is obvious, in my mind. For CPython (the most popular implementation of the language), there are only three languages in which you can write extensions: C, C++, and now D. [1] Writing extensions in the raw C API is the very definition of tedious. C++'s Boost.Python is a nice library, but I for one am sick and tired of C++. And so I'm writing Pyd. It fills a niche, I think. D and Python! Two great tastes that taste great together! So please, Walter, add this shared library support. It can't be /that/ hard, can it? [1] Well, in truth you can use just about any language with C linkage, but that just means using the C API all over again. I am not aware of any libraries built on top of this except for Boost.Python and now Pyd that make the experience substantially less painful. -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 13 2006
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Kirk McDonald wrote:

 So please, Walter, add this shared library support. It can't be /that/
 hard, can it?

I agree with you, not because of Pyd, but because share libraries are important. Period. When that is said, have you tried GDC for what you want to do? -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jul 13 2006
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Lars Ivar Igesund wrote:
 Kirk McDonald wrote:
 
 
So please, Walter, add this shared library support. It can't be /that/
hard, can it?

I agree with you, not because of Pyd, but because share libraries are important. Period. When that is said, have you tried GDC for what you want to do?

I was under the impression that GDC didn't support shared libraries, either. No, I haven't; does it support them? -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 13 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Kirk McDonald wrote:
 Here's something that has been annoying me, and this week-old thread is 
 as good a place as any to bring it up: Shared library support on Linux. 
 I could not take D seriously if it did a "1.0" release without this. I 
 do hate to cram more on your plate, Walter, but I consider this a more 
 serious issue than even this import thing that has gripped the newsgroup 
 for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?
Jul 13 2006
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:
 Kirk McDonald wrote:
 
 Here's something that has been annoying me, and this week-old thread 
 is as good a place as any to bring it up: Shared library support on 
 Linux. I could not take D seriously if it did a "1.0" release without 
 this. I do hate to cram more on your plate, Walter, but I consider 
 this a more serious issue than even this import thing that has gripped 
 the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does: [myso2.d] import std.stdio; export extern(C) void mysoprint() { writefln("Hello 'so' world!"); } [myso.d] export extern(C) void mysoprint(); [test.d] import myso; void main() { mysoprint(); } $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc /usr/bin/ld: warning: creating a DT_TEXTREL in object. (Not sure what that means...) $ sudo cp libmyso.so /usr/lib $ gdc -c test.d $ gdc test.o -Wl,-lmyso -o test $ ./test Hello 'so' world! Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here? -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 13 2006
next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Kirk McDonald wrote:
 Walter Bright wrote:
 
 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old thread 
 is as good a place as any to bring it up: Shared library support on 
 Linux. I could not take D seriously if it did a "1.0" release without 
 this. I do hate to cram more on your plate, Walter, but I consider 
 this a more serious issue than even this import thing that has 
 gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does: [myso2.d] import std.stdio; export extern(C) void mysoprint() { writefln("Hello 'so' world!"); } [myso.d] export extern(C) void mysoprint(); [test.d] import myso; void main() { mysoprint(); }

Uhh, I forgot a line. :-) $ gdc -fPIC -g -c -Wall myso2.d
 $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc
 /usr/bin/ld: warning: creating a DT_TEXTREL in object.
 
 (Not sure what that means...)
 
 $ sudo cp libmyso.so /usr/lib
 $ gdc -c test.d
 $ gdc test.o -Wl,-lmyso -o test
 $ ./test
 Hello 'so' world!
 
 Sweet. However, I am a little concerned. When making DLLs on Windows, 
 there is some boilerplate code needed to initialize and shut down the GC 
 and do some other routine things. Is something like that needed here?
 

-- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 13 2006
prev sibling next sibling parent reply BCS <BCS pathlink.com> writes:
Kirk McDonald wrote:
 Walter Bright wrote:
 
 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old thread 
 is as good a place as any to bring it up: Shared library support on 
 Linux. I could not take D seriously if it did a "1.0" release without 
 this. I do hate to cram more on your plate, Walter, but I consider 
 this a more serious issue than even this import thing that has 
 gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does:

 
 Sweet. However, I am a little concerned. When making DLLs on Windows, 
 there is some boilerplate code needed to initialize and shut down the GC 
 and do some other routine things. Is something like that needed here?
 

Doesn't said boilerplate consist of linking the GC of the calling program in to the GC of the called so? why not do it the other way around? place the GC in its own so and have everything else link in to it? Not too clean for small projects but once you are using so's anyway it would be cleaner than putting gc hookup code all over the place.
Jul 13 2006
next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
BCS wrote:
 Kirk McDonald wrote:
 
 Walter Bright wrote:

 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old thread 
 is as good a place as any to bring it up: Shared library support on 
 Linux. I could not take D seriously if it did a "1.0" release 
 without this. I do hate to cram more on your plate, Walter, but I 
 consider this a more serious issue than even this import thing that 
 has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does:

 Sweet. However, I am a little concerned. When making DLLs on Windows, 
 there is some boilerplate code needed to initialize and shut down the 
 GC and do some other routine things. Is something like that needed here?

Doesn't said boilerplate consist of linking the GC of the calling program in to the GC of the called so? why not do it the other way around? place the GC in its own so and have everything else link in to it? Not too clean for small projects but once you are using so's anyway it would be cleaner than putting gc hookup code all over the place.

If I am (for instance) writing an .so that will be loaded by the Python interpreter, it will not have a D GC to hook into. -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 13 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
BCS wrote:
 Kirk McDonald wrote:
 Walter Bright wrote:

 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old thread 
 is as good a place as any to bring it up: Shared library support on 
 Linux. I could not take D seriously if it did a "1.0" release 
 without this. I do hate to cram more on your plate, Walter, but I 
 consider this a more serious issue than even this import thing that 
 has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does:

 Sweet. However, I am a little concerned. When making DLLs on Windows, 
 there is some boilerplate code needed to initialize and shut down the 
 GC and do some other routine things. Is something like that needed here?

Doesn't said boilerplate consist of linking the GC of the calling program in to the GC of the called so? why not do it the other way around? place the GC in its own so and have everything else link in to it? Not too clean for small projects but once you are using so's anyway it would be cleaner than putting gc hookup code all over the place.

The issue is somewhat messy. If Phobos is statically linked and the user DLL is loaded by a D app then there would be two GCs and two thread lists that need to cooperate. It would be far preferable to put Phobos in a DLL of its own so only a single copy of this code is in use. But now assume the DLL is loaded by a C app. The user DLL would have to load/attach to the Phobos DLL. I think the "cr_init" and "cr_term" functions I mentioned in my other post might have to be reentrant for everything to work properly? I'll admit to having given the DLL issue basically no thought so far. Sean
Jul 13 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Sean Kelly wrote:
 BCS wrote:
 
 Kirk McDonald wrote:

 Walter Bright wrote:

 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old 
 thread is as good a place as any to bring it up: Shared library 
 support on Linux. I could not take D seriously if it did a "1.0" 
 release without this. I do hate to cram more on your plate, Walter, 
 but I consider this a more serious issue than even this import 
 thing that has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does:

 Sweet. However, I am a little concerned. When making DLLs on Windows, 
 there is some boilerplate code needed to initialize and shut down the 
 GC and do some other routine things. Is something like that needed here?

Doesn't said boilerplate consist of linking the GC of the calling program in to the GC of the called so? why not do it the other way around? place the GC in its own so and have everything else link in to it? Not too clean for small projects but once you are using so's anyway it would be cleaner than putting gc hookup code all over the place.

The issue is somewhat messy. If Phobos is statically linked and the user DLL is loaded by a D app then there would be two GCs and two thread lists that need to cooperate. It would be far preferable to put Phobos in a DLL of its own so only a single copy of this code is in use. But now assume the DLL is loaded by a C app. The user DLL would have to load/attach to the Phobos DLL. I think the "cr_init" and "cr_term" functions I mentioned in my other post might have to be reentrant for everything to work properly? I'll admit to having given the DLL issue basically no thought so far. Sean

I just did some testing, and this is exactly right. I modified the old myso2.d to create a class and instantiate it: [myso2.d] module myso; import std.stdio; class A { ~this() { writefln("A.~this()"); } void foo() { writefln("A.foo()"); } } export extern(C) void mysoprint() { A a = new A; a.foo(); } When loaded by a D module, it works just fine. However, the following promptly causes Python to segfault when imported: [testpy.d] import python; import std.stdio; PyMethodDef testpy_methods[] = [ { null, null, 0, null } ]; class A { ~this() { writefln("A.~this()"); } void foo() { writefln("A.foo()"); } } extern(C) export void inittestpy() { Py_InitModule("testpy", testpy_methods); A a = new A; a.foo(); }
 import testpy



$ This, however, runs fine: [testpy2.d] import python; import std.stdio; PyMethodDef testpy_methods[] = [ { null, null, 0, null } ]; extern(C) export void inittestpy() { Py_InitModule("testpy", testpy_methods); writefln("Hello, world!"); }
 import testpy2






It seems clear to me that the GC is causing the trouble. -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 13 2006
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Kirk McDonald wrote:
 When loaded by a D module, it works just fine. However, the following 
 promptly causes Python to segfault when imported:
 

With these modifications, it works:
 [testpy.d]
 import python;
 import std.stdio;
 
 PyMethodDef testpy_methods[] = [
     { null, null, 0, null }
 ];
 
 class A {
     ~this() { writefln("A.~this()"); }
     void foo() { writefln("A.foo()"); }
 }
 

extern(C) { void gc_init(); void gc_term(); }
 extern(C)
 export void inittestpy() {

     Py_InitModule("testpy", testpy_methods);
     A a = new A;
     a.foo();
 }

// The standard Linux dynamic library finalization function extern(C) void _fini() { gc_term(); } It must be compiled with the -nostartfiles switch. When imported:
 import testpy



 ^D



$ However, I saw some notes about _fini being obsolete and possibly dangerous. Anyone more experienced with Linux coding want to comment? -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 13 2006
prev sibling parent reply BCS <BCS pathlink.com> writes:
Sean Kelly wrote:
 BCS wrote:
 
 Kirk McDonald wrote:

 Walter Bright wrote:

 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old 
 thread is as good a place as any to bring it up: Shared library 
 support on Linux. I could not take D seriously if it did a "1.0" 
 release without this. I do hate to cram more on your plate, Walter, 
 but I consider this a more serious issue than even this import 
 thing that has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does:

 Sweet. However, I am a little concerned. When making DLLs on Windows, 
 there is some boilerplate code needed to initialize and shut down the 
 GC and do some other routine things. Is something like that needed here?

Doesn't said boilerplate consist of linking the GC of the calling program in to the GC of the called so? why not do it the other way around? place the GC in its own so and have everything else link in to it? Not too clean for small projects but once you are using so's anyway it would be cleaner than putting gc hookup code all over the place.

The issue is somewhat messy. If Phobos is statically linked and the user DLL is loaded by a D app then there would be two GCs and two thread lists that need to cooperate. It would be far preferable to put Phobos in a DLL of its own so only a single copy of this code is in use. But now assume the DLL is loaded by a C app. The user DLL would have to load/attach to the Phobos DLL. I think the "cr_init" and "cr_term" functions I mentioned in my other post might have to be reentrant for everything to work properly? I'll admit to having given the DLL issue basically no thought so far. Sean

You would need a special Phobos to do it. For that matter, you would also want a hacked startup section to automatically hook into the gc.so, same for the so's themselves. (They have some start up code don't they?) I guess what you'd have is a complete duplication of the D runtime. One set (what is there now) for static linking and one set (with the above hacks, and more I assume) for dynamic linking.
Jul 13 2006
parent reply Sean Kelly <sean f4.ca> writes:
BCS wrote:
 Sean Kelly wrote:
 BCS wrote:

 Kirk McDonald wrote:

 Walter Bright wrote:

 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old 
 thread is as good a place as any to bring it up: Shared library 
 support on Linux. I could not take D seriously if it did a "1.0" 
 release without this. I do hate to cram more on your plate, 
 Walter, but I consider this a more serious issue than even this 
 import thing that has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does:

 Sweet. However, I am a little concerned. When making DLLs on 
 Windows, there is some boilerplate code needed to initialize and 
 shut down the GC and do some other routine things. Is something like 
 that needed here?

Doesn't said boilerplate consist of linking the GC of the calling program in to the GC of the called so? why not do it the other way around? place the GC in its own so and have everything else link in to it? Not too clean for small projects but once you are using so's anyway it would be cleaner than putting gc hookup code all over the place.

The issue is somewhat messy. If Phobos is statically linked and the user DLL is loaded by a D app then there would be two GCs and two thread lists that need to cooperate. It would be far preferable to put Phobos in a DLL of its own so only a single copy of this code is in use. But now assume the DLL is loaded by a C app. The user DLL would have to load/attach to the Phobos DLL. I think the "cr_init" and "cr_term" functions I mentioned in my other post might have to be reentrant for everything to work properly? I'll admit to having given the DLL issue basically no thought so far.

You would need a special Phobos to do it.

Well, that's basically what Ares is :-) Though it would be easy enough for Walter to add to Phobos if he thought it was a good idea.
 For that matter, you would
 also want a hacked startup section to automatically hook into the gc.so, 
 same for the so's themselves. (They have some start up code don't they?)

cr_init would initialize the GC, run module ctors, and any other special things that need doing. cr_term would shutdown the GC, run module dtors, etc. These functions would simply be called in internal/dmain2 instead of the code being inline.
 I guess what you'd have is a complete duplication of the D runtime. One 
 set (what is there now) for static linking and one set (with the above 
 hacks, and more I assume) for dynamic linking.

Dynamic linking is a pain, which is why I've avoided the issue thus far. DDL is another option that I think is far preferable in instances where it can be used. I'll admit I'm not at all keen on trying to turn the compiler runtime code into a DLL, what will all the exports likely required and such. Sean
Jul 13 2006
parent BCS <BCS pathlink.com> writes:
Sean Kelly wrote:
 BCS wrote:
 
 You would need a special Phobos to do it.

Well, that's basically what Ares is :-) Though it would be easy enough for Walter to add to Phobos if he thought it was a good idea.

Maybe, but I was thinking more along the lines of an alternate build of Phobos, not a rewriting. I guess the same could be able to be done with most stdlib's. [...]
 
 I guess what you'd have is a complete duplication of the D runtime. 
 One set (what is there now) for static linking and one set (with the 
 above hacks, and more I assume) for dynamic linking.

Dynamic linking is a pain, which is why I've avoided the issue thus far. DDL is another option that I think is far preferable in instances where it can be used. I'll admit I'm not at all keen on trying to turn the compiler runtime code into a DLL, what will all the exports likely required and such. Sean

I'm thinking of a same-code-link-with-both kind of thing, just pick the lib you want and go.
Jul 13 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Kirk McDonald wrote:
 Walter Bright wrote:
 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old thread 
 is as good a place as any to bring it up: Shared library support on 
 Linux. I could not take D seriously if it did a "1.0" release without 
 this. I do hate to cram more on your plate, Walter, but I consider 
 this a more serious issue than even this import thing that has 
 gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does: [myso2.d] import std.stdio; export extern(C) void mysoprint() { writefln("Hello 'so' world!"); } [myso.d] export extern(C) void mysoprint(); [test.d] import myso; void main() { mysoprint(); } $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc /usr/bin/ld: warning: creating a DT_TEXTREL in object. (Not sure what that means...) $ sudo cp libmyso.so /usr/lib $ gdc -c test.d $ gdc test.o -Wl,-lmyso -o test $ ./test Hello 'so' world! Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here?

I think it is. Perhaps the best approach would be to expose two extern (C) functions: one for startup and one for shutdown. By default, these would be called automatically by internal/dmain2, but the user could opt to call them in DllInit or whatever if he knows that function will not be the entry point for his program. In Ares, I'd probably call these "cr_init" and "cr_term" where "cr" means "compiler runtime." Sean
Jul 13 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
Sean Kelly wrote:
 Kirk McDonald wrote:
 Walter Bright wrote:
 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old thread 
 is as good a place as any to bring it up: Shared library support on 
 Linux. I could not take D seriously if it did a "1.0" release 
 without this. I do hate to cram more on your plate, Walter, but I 
 consider this a more serious issue than even this import thing that 
 has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does: [myso2.d] import std.stdio; export extern(C) void mysoprint() { writefln("Hello 'so' world!"); } [myso.d] export extern(C) void mysoprint(); [test.d] import myso; void main() { mysoprint(); } $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc /usr/bin/ld: warning: creating a DT_TEXTREL in object. (Not sure what that means...) $ sudo cp libmyso.so /usr/lib $ gdc -c test.d $ gdc test.o -Wl,-lmyso -o test $ ./test Hello 'so' world! Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here?

I think it is. Perhaps the best approach would be to expose two extern (C) functions: one for startup and one for shutdown. By default, these would be called automatically by internal/dmain2, but the user could opt to call them in DllInit or whatever if he knows that function will not be the entry point for his program. In Ares, I'd probably call these "cr_init" and "cr_term" where "cr" means "compiler runtime."

Could these be exposed to be the same on both platforms? If so that would be great. Thanks, - Dave
 
 Sean

Jul 13 2006
parent reply Sean Kelly <sean f4.ca> writes:
Dave wrote:
 Sean Kelly wrote:
 Kirk McDonald wrote:
 Walter Bright wrote:
 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old 
 thread is as good a place as any to bring it up: Shared library 
 support on Linux. I could not take D seriously if it did a "1.0" 
 release without this. I do hate to cram more on your plate, Walter, 
 but I consider this a more serious issue than even this import 
 thing that has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does: [myso2.d] import std.stdio; export extern(C) void mysoprint() { writefln("Hello 'so' world!"); } [myso.d] export extern(C) void mysoprint(); [test.d] import myso; void main() { mysoprint(); } $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc /usr/bin/ld: warning: creating a DT_TEXTREL in object. (Not sure what that means...) $ sudo cp libmyso.so /usr/lib $ gdc -c test.d $ gdc test.o -Wl,-lmyso -o test $ ./test Hello 'so' world! Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here?

I think it is. Perhaps the best approach would be to expose two extern (C) functions: one for startup and one for shutdown. By default, these would be called automatically by internal/dmain2, but the user could opt to call them in DllInit or whatever if he knows that function will not be the entry point for his program. In Ares, I'd probably call these "cr_init" and "cr_term" where "cr" means "compiler runtime."

Could these be exposed to be the same on both platforms? If so that would be great.

Yup. It would be a trivial change to internal/dmain2. I'll probably do it in Ares in the next few days, just to have it as an option. Sean
Jul 13 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Sean Kelly wrote:
 Dave wrote:
 
 Sean Kelly wrote:

 Kirk McDonald wrote:

 Walter Bright wrote:

 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old 
 thread is as good a place as any to bring it up: Shared library 
 support on Linux. I could not take D seriously if it did a "1.0" 
 release without this. I do hate to cram more on your plate, 
 Walter, but I consider this a more serious issue than even this 
 import thing that has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does: [myso2.d] import std.stdio; export extern(C) void mysoprint() { writefln("Hello 'so' world!"); } [myso.d] export extern(C) void mysoprint(); [test.d] import myso; void main() { mysoprint(); } $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc /usr/bin/ld: warning: creating a DT_TEXTREL in object. (Not sure what that means...) $ sudo cp libmyso.so /usr/lib $ gdc -c test.d $ gdc test.o -Wl,-lmyso -o test $ ./test Hello 'so' world! Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here?

I think it is. Perhaps the best approach would be to expose two extern (C) functions: one for startup and one for shutdown. By default, these would be called automatically by internal/dmain2, but the user could opt to call them in DllInit or whatever if he knows that function will not be the entry point for his program. In Ares, I'd probably call these "cr_init" and "cr_term" where "cr" means "compiler runtime."

Could these be exposed to be the same on both platforms? If so that would be great.

Yup. It would be a trivial change to internal/dmain2. I'll probably do it in Ares in the next few days, just to have it as an option.

This not being my specialty, I have to ask the dumb question: does all this mean that - helloworld could be only a few kB - on a machine where D programs are run almost continuously, the startup time of a D app would be vastly quicker - total memory consumption of the D programs would be much reduced And on the other hand, (almost) every time a new DMD comes out, one would have to recompile the .so files? And therefore the apps too?
Jul 13 2006
parent Sean Kelly <sean f4.ca> writes:
Georg Wrede wrote:
 Sean Kelly wrote:
 Yup.  It would be a trivial change to internal/dmain2.  I'll probably 
 do it in Ares in the next few days, just to have it as an option.

This not being my specialty, I have to ask the dumb question: does all this mean that - helloworld could be only a few kB

Probably. Though dealing with DLLs is deceptive because the application would consume far more memory than just the few KB indicated by the EXE size.
  - on a machine where D programs are run almost continuously, the 
 startup time of a D app would be vastly quicker

I don't think so, because (I believe) there would still be a separate GC instance per app.
  - total memory consumption of the D programs would be much reduced

Assuming a single shared GC, yes. Sean
Jul 23 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Sean Kelly wrote:
 Kirk McDonald wrote:
 Walter Bright wrote:
 Kirk McDonald wrote:

 Here's something that has been annoying me, and this week-old thread 
 is as good a place as any to bring it up: Shared library support on 
 Linux. I could not take D seriously if it did a "1.0" release 
 without this. I do hate to cram more on your plate, Walter, but I 
 consider this a more serious issue than even this import thing that 
 has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done. Will the shared libraries work with GDC?

Ha! Well, at least this simple case does: [myso2.d] import std.stdio; export extern(C) void mysoprint() { writefln("Hello 'so' world!"); } [myso.d] export extern(C) void mysoprint(); [test.d] import myso; void main() { mysoprint(); } $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc /usr/bin/ld: warning: creating a DT_TEXTREL in object. (Not sure what that means...) $ sudo cp libmyso.so /usr/lib $ gdc -c test.d $ gdc test.o -Wl,-lmyso -o test $ ./test Hello 'so' world! Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here?

I think it is. Perhaps the best approach would be to expose two extern (C) functions: one for startup and one for shutdown. By default, these would be called automatically by internal/dmain2, but the user could opt to call them in DllInit or whatever if he knows that function will not be the entry point for his program. In Ares, I'd probably call these "cr_init" and "cr_term" where "cr" means "compiler runtime." Sean

Shouldn't it be "language runtime" or "D runtime"? The runtime is *made* by the compiler, but it is the runtime *of* D, not the runtime of the compiler. Compare: JRE = Java Runtime Environment. :P (Yes I'm way picky with names... X-p ) -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 14 2006
parent Sean Kelly <sean f4.ca> writes:
Bruno Medeiros wrote:
 
 Shouldn't it be "language runtime" or "D runtime"? The runtime is *made* 
 by the compiler, but it is the runtime *of* D, not the runtime of the 
 compiler.

Probably. I just use the term "compiler runtime" to indicate which portion of the code it represents, as Ares splits it out into three segments: the portion of the runtime that is compiler-specific, the garbage collector, and any user-visible code that is required to complete the package (which involves some thread code for use by the GC, at the very least). I would consider the combination of these three components to be the "language runtime," as they are all required for a D program to run. Sean
Jul 14 2006