• Tony (16/23) Jul 07 2006 I've taken the liberty of making this a new thread as the old one was
• kris (13/33) Jul 07 2006 Hear Hear!
• Dave (6/44) Jul 07 2006 My vote too, but in line with what Kris mentions below I think it's
• Lars Ivar Igesund (14/44) Jul 08 2006 With the latest posts on template issues (some are labeled bugs, some ar...
• Stewart Gordon (12/21) Jul 11 2006
• Don Clugston (5/27) Jul 11 2006 I don't think that any of those are achievable until a 1.0 language
• jcc7 (11/31) Jul 11 2006 That'd be nice. I don't know if the current gaps in the spec are big eno...
• Johan Granberg (9/15) Jul 11 2006 I agree on that. As I see it phobos is a library using a very productive...
• jcc7 (10/25) Jul 11 2006 I just think calling it "D 1.0" is about the language specification bein...
• Johan Granberg (6/17) Jul 11 2006 I'm not speaking of a fully fleshed out phobos I just noted a few issues...
• Dave (7/34) Jul 11 2006 I agree 1.0 should be soon (as-in certainly by winter considering an RC
• Stewart Gordon (12/35) Jul 11 2006 These certainly are big enough from where I am:
• Tim Starling (28/28) Jul 11 2006 A few comments as an outsider and a latecomer to this thread.
• Dave (11/21) Jul 12 2006 A compiler perhaps more than 95% of the rest of the software out there
• Kirk McDonald (36/57) Jul 13 2006 Here's something that has been annoying me, and this week-old thread is
• Lars Ivar Igesund (8/10) Jul 13 2006 I agree with you, not because of Pyd, but because share libraries are
• Kirk McDonald (7/18) Jul 13 2006 I was under the impression that GDC didn't support shared libraries,
• Walter Bright (5/11) Jul 13 2006 I know about the shared library issue on Linux. And to tell the truth,
• Kirk McDonald (28/43) Jul 13 2006 Ha! Well, at least this simple case does:
• Kirk McDonald (7/60) Jul 13 2006 Uhh, I forgot a line. :-)
• BCS (7/34) Jul 13 2006 Doesn't said boilerplate consist of linking the GC of the calling
• Kirk McDonald (7/47) Jul 13 2006 If I am (for instance) writing an .so that will be loaded by the Python
• Sean Kelly (11/47) Jul 13 2006 The issue is somewhat messy. If Phobos is statically linked and the
• Kirk McDonald (53/113) Jul 13 2006 I just did some testing, and this is exactly right. I modified the old
• Kirk McDonald (22/46) Jul 13 2006 extern(C) {
• BCS (7/64) Jul 13 2006 You would need a special Phobos to do it. For that matter, you would
• Sean Kelly (13/77) Jul 13 2006 Well, that's basically what Ares is :-) Though it would be easy enough
• BCS (7/30) Jul 13 2006 Maybe, but I was thinking more along the lines of an alternate build of
• Sean Kelly (8/57) Jul 13 2006 I think it is. Perhaps the best approach would be to expose two extern
• Dave (5/65) Jul 13 2006 Could these be exposed to be the same on both platforms? If so that
• Sean Kelly (4/67) Jul 13 2006 Yup. It would be a trivial change to internal/dmain2. I'll probably do...
• Georg Wrede (9/85) Jul 13 2006 This not being my specialty, I have to ask the dumb question:
• Sean Kelly (8/21) Jul 23 2006 Probably. Though dealing with DLLs is deceptive because the application...
• Bruno Medeiros (8/68) Jul 14 2006 Shouldn't it be "language runtime" or "D runtime"? The runtime is *made*...
• Sean Kelly (10/14) Jul 14 2006 Probably. I just use the term "compiler runtime" to indicate which

"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 

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?

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:

http://www.digitalmars.com/drn-bin/wwwnews?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?

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

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.

<snip>

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.

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.

 <snip>
 
 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.

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.

<snip>

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

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.

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

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

I'm not speaking of a fully fleshed out phobos I just noted a few issues 
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.

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

 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

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.

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.

 <snip>

 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.

<snip>

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.

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

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

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

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

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

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?

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

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

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:
 

[proof]
 
 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.

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:

 [proof]
 
 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

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:

 [proof]
 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

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:

 [proof]

 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



Segmentation fault
$

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



Hello, world!



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

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() {

     gc_init();
     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



A.foo()
 ^D



A.~this()
$

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

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:

 [proof]

 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.

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:

 [proof]

 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

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.

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

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

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

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?

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

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

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