• Matthew (17/17) Jan 21 2005 As some may have noticed, and a few may have been pleased, I've been lar...
• Ben Hinkle (25/42) Jan 21 2005 largely away from D for the last few months. I've
• Matthew (4/53) Jan 21 2005 Sounds excellent. I doubt I can be of much assistance, but I'll certainl...
• Kris (13/14) Jan 21 2005 Hey Matthew; you'll be "not is" surprised to learn that the beloved issu...
• Walter (21/35) Jan 21 2005 stuff.
• Thomas Kuehne (6/31) Jan 21 2005 The GC issue aside, a "phobos.dll on an island" does make sense. Suppose...
• Walter (23/27) Jan 21 2005 you
• Matthew (4/43) Jan 21 2005 It's certainly true that that's unpleasant, but if the alternative is th...
• Walter (11/28) Jan 21 2005 news:css3k9$18ou$1@digitaldaemon.com...
• Matthew (3/33) Jan 21 2005 But how do we manage the memory that may be exchanged between link units...
• John Reimer (4/43) Jan 22 2005 Make the GC part of the OS? :-)
• Walter (11/14) Jan 23 2005 Which GC owns it? I confess I little
• Kris (16/46) Jan 21 2005 It would be great to use interfaces. I presume you mean "in conjunction ...
• Matthew (4/54) Jan 21 2005 I strongly believe that we need to handle *all* situations *gracefully*....
• Walter (17/32) Jan 23 2005 with a
• Matthias Becker (7/30) Jan 24 2005 In my world there isn't anything like release, close, dispose, ... . Eve...
• Kris (44/83) Jan 21 2005 Please read that last sentence again, Walter ... what we're trying to do...
• Matthew (6/95) Jan 21 2005 Sounding more and more normal. ;)
• Walter (8/12) Jan 23 2005 I've said three times in the last 24hrs,
• kris (33/56) Jan 23 2005 With respect, Walter, that kind of rebuke is somewhat pedantic and
• Norbert Nemec (14/17) Jan 23 2005 Might that be an inherent Windows problem? In Linux, I see no direct
• David L. Davis (15/18) Jan 23 2005 Norbert: I agreed with your other points...but in the sentence above, I ...
• Norbert Nemec (23/42) Jan 23 2005 OK, sorry for becoming a bit polemic in that sentence above. It's just t...
• Georg Wrede (19/25) Jan 23 2005 If D-made DLLs were only used from D-made programs, then we'd have a lot...
• Norbert Nemec (14/48) Jan 23 2005 I still don't understand: where is the problem with a dynamically linked...
• kris (42/59) Jan 23 2005 Exactly, Norbert.
• Pragma (59/65) Jan 24 2005 Yet there are ways to circumvent the majority of issues involved with mu...
• pragma (22/22) Jan 24 2005 I know it's in poor taste to reply to one's own post, but there was one ...
• Norbert Nemec (20/37) Jan 24 2005 I don't even want to understand that whole issue but just add one commen...
• Ant (5/11) Jan 24 2005 [...]
• Paul Bonser (17/88) Jan 24 2005 I think that this scheme would work very well, not just for D, but for
• Norbert Nemec (6/14) Jan 25 2005 That's why I say: the problem should not be solved within the compiler.
• Matthew (13/26) Jan 21 2005 So the rule would be:
• John Reimer (12/16) Jan 21 2005 It's still a work in progress, I believe.
• Lars Ivar Igesund (6/30) Jan 22 2005 Great idea! Although for all those
• Walter (6/9) Jan 21 2005 not had time for the most rapidly growing of
• Matthew (23/32) Jan 21 2005 Sounds like I've not _that_ much to catch up on. ;)
• Walter (8/11) Jan 21 2005 you more expert than I to inform on my
• Matthew (3/14) Jan 21 2005 I'm not talking about malloc(). That's a well-trodden path.
• Walter (15/31) Jan 22 2005 news:cssd2a$1ig3$2@digitaldaemon.com...
• Matthew (16/50) Jan 22 2005 My point is that languages/runtime environments such as Java and .NET - ...
• Walter (25/48) Jan 23 2005 dealing
• Matthew (10/61) Jan 23 2005 Come on. Clearly I'm not talking about Windows .DLL DLLs. I'm talking ab...
• Norbert Nemec (15/34) Jan 23 2005 Now, are you talking about mixing languages in dynamically linked librar...
• Walter (8/11) Jan 21 2005 means that I have a chance to help with/opine on
• Matthew (4/15) Jan 21 2005 Ok, so I misspoke. I should have said
• Walter (15/32) Jan 22 2005 news:cssdl8$1j47$1@digitaldaemon.com...
• John Demme (15/21) Jan 22 2005 Java. (Yeah, I know, it's not DLLs, but shared libraries all the same)....
• Matthew (9/45) Jan 23 2005 With respect, I suspect you are going to feel like that because (i) you ...
• John Reimer (38/46) Jan 22 2005 Unfortunately, Matthew, when you say "John", it could be one of 3 or 4
• Matthew (9/38) Jan 26 2005 Nice

"Matthew" <admin.hat stlsoft.dot.org> writes:

As some may have noticed, and a few may have been pleased, I've been largely
away from D for the last few months. I've 
been working on a large infrastructure project for a client, which has involved
a lot of networking (ACE) and middleware 
(TibCo EMS), and some GUI / logging (so C++ aficionados may expect to see more
sub-projects in STLSoft in the next few 
months).

Since I've been doing some seriously long, and arse-widening, hours, I've not
had time for the most rapidly growing of 
my three favourite languages, so I'm wondering what I've missed. Anyone care to
give me a quick update of how they think 
D has progressed over the last few months? Walter, Kris, Anders, John, Ben, all
the guys (and gals) ...


FYI, I expect to be largely free of my current duties in the next few weeks,
and am planning to get back into D with a 
vengeance next month. Walter and I will also be starting the real work on our D
book, and are hoping (probably 
deludedly) to have that finished by mid-year. As part of the research for that
book, and to get me back on stride, I 
will be getting back into recls/D, Open-RJ/D, the D exception stuff that I
promised last year (unless that's already 
been sorted), and, of course, DTL, for which latter I have had some good ideas
of late.

So, Hi! Hope you're all hale and hearty. And fill me in on all the good stuff.

Cheers, and well (re-)met

Matthew

P.S. "Imperfect C++"'s dropped out of the top 20 C++ books on Amazon now, so if
you've been hanging fire, now'd be the 
time to pry out those coppers. :-)

"Ben Hinkle" <bhinkle mathworks.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:csqmfc$2gm9$2 digitaldaemon.com...
 As some may have noticed, and a few may have been pleased, I've been

largely away from D for the last few months. I've
 been working on a large infrastructure project for a client, which has

involved a lot of networking (ACE) and middleware
 (TibCo EMS), and some GUI / logging (so C++ aficionados may expect to see

more sub-projects in STLSoft in the next few
 months).

 Since I've been doing some seriously long, and arse-widening, hours, I've

not had time for the most rapidly growing of
 my three favourite languages, so I'm wondering what I've missed. Anyone

care to give me a quick update of how they think
 D has progressed over the last few months? Walter, Kris, Anders, John,

Ben, all the guys (and gals) ...
 FYI, I expect to be largely free of my current duties in the next few

weeks, and am planning to get back into D with a
 vengeance next month. Walter and I will also be starting the real work on

our D book, and are hoping (probably
 deludedly) to have that finished by mid-year. As part of the research for

that book, and to get me back on stride, I
 will be getting back into recls/D, Open-RJ/D, the D exception stuff that I

promised last year (unless that's already
 been sorted), and, of course, DTL, for which latter I have had some good

ideas of late.
 So, Hi! Hope you're all hale and hearty. And fill me in on all the good

stuff.
 Cheers, and well (re-)met

 Matthew

 P.S. "Imperfect C++"'s dropped out of the top 20 C++ books on Amazon now,

so if you've been hanging fire, now'd be the
 time to pry out those coppers. :-)

Welcome back! I don't remember exactly what state D was in a few months ago
but there has just been bug fixes and then these last few days I'm sure
you've seen the DMDScript posts. For my own D stuff I'm currently trying to
convince Walter of a serious bug in toStringz and I'm working on MinWin - a
pure-D miminal multi-platform GUI toolkit. MinWin is still in its infancy
(my current task is getting modal dialogs hooked up) but I'm developing the
Windows, Motif and GTK backends simulatenously to minimize the risk of
steering it towards one platform. The dsource forum is at
http://www.dsource.org/forums/viewforum.php?f=47

-Ben

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:csr5em$3bu$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:csqmfc$2gm9$2 digitaldaemon.com...
 As some may have noticed, and a few may have been pleased, I've been

 largely away from D for the last few months. I've
 been working on a large infrastructure project for a client, which has

 involved a lot of networking (ACE) and middleware
 (TibCo EMS), and some GUI / logging (so C++ aficionados may expect to see

 more sub-projects in STLSoft in the next few
 months).

 Since I've been doing some seriously long, and arse-widening, hours, I've

 not had time for the most rapidly growing of
 my three favourite languages, so I'm wondering what I've missed. Anyone

 care to give me a quick update of how they think
 D has progressed over the last few months? Walter, Kris, Anders, John,

 Ben, all the guys (and gals) ...
 FYI, I expect to be largely free of my current duties in the next few

 weeks, and am planning to get back into D with a
 vengeance next month. Walter and I will also be starting the real work on

 our D book, and are hoping (probably
 deludedly) to have that finished by mid-year. As part of the research for

 that book, and to get me back on stride, I
 will be getting back into recls/D, Open-RJ/D, the D exception stuff that I

 promised last year (unless that's already
 been sorted), and, of course, DTL, for which latter I have had some good

 ideas of late.
 So, Hi! Hope you're all hale and hearty. And fill me in on all the good

 stuff.
 Cheers, and well (re-)met

 Matthew

 P.S. "Imperfect C++"'s dropped out of the top 20 C++ books on Amazon now,

 so if you've been hanging fire, now'd be the
 time to pry out those coppers. :-)

 Welcome back! I don't remember exactly what state D was in a few months ago
 but there has just been bug fixes and then these last few days I'm sure
 you've seen the DMDScript posts. For my own D stuff I'm currently trying to
 convince Walter of a serious bug in toStringz

I read that thread. Kind of scary. I didn't notice a post by big-W on that
thread, so I guess he's still cogitating.

and I'm working on MinWin - a
 pure-D miminal multi-platform GUI toolkit. MinWin is still in its infancy
 (my current task is getting modal dialogs hooked up) but I'm developing the
 Windows, Motif and GTK backends simulatenously to minimize the risk of
 steering it towards one platform. The dsource forum is at
 http://www.dsource.org/forums/viewforum.php?f=47

Sounds excellent. I doubt I can be of much assistance, but I'll certainly
follow along, as I'm keen to get on top of 
UNIX windowing stuff. :-)

Kris <Kris_member pathlink.com> writes:

In article <csqmfc$2gm9$2 digitaldaemon.com>, Matthew says...
<snip>
So, Hi! Hope you're all hale and hearty. And fill me in on all the good stuff.

Hey Matthew; you'll be "not is" surprised to learn that the beloved issues
surrounding DLLs and the GC are all still present (Sean's excellent work aside)
.. stepping away from a statically-linked model still transports one back into
the stone-age.

Question: would D benefit from it's own (binary) link-loader? If the compiler
were to spit out DDLs (Dynamic D Libraries), and the runtime had the equivalent
of a linking-class-loader, then the issues regarding multiple GC's would go away
(since the GC, and all libraries, would be DDLs instead).

Such an approach would also presumeably expose D classes correctly, which is
currently the other major problem regarding D and shared-libraries.

Thoughts?

"Walter" <newshound digitalmars.com> writes:

"Kris" <Kris_member pathlink.com> wrote in message
news:csrksh$mn3$1 digitaldaemon.com...
 In article <csqmfc$2gm9$2 digitaldaemon.com>, Matthew says...
 <snip>
So, Hi! Hope you're all hale and hearty. And fill me in on all the good


stuff.
 Hey Matthew; you'll be "not is" surprised to learn that the beloved issues
 surrounding DLLs and the GC are all still present (Sean's excellent work

aside)
 .. stepping away from a statically-linked model still transports one back

into
 the stone-age.

 Question: would D benefit from it's own (binary) link-loader? If the

compiler
 were to spit out DDLs (Dynamic D Libraries), and the runtime had the

equivalent
 of a linking-class-loader, then the issues regarding multiple GC's would

go away
 (since the GC, and all libraries, would be DDLs instead).

 Such an approach would also presumeably expose D classes correctly, which

is
 currently the other major problem regarding D and shared-libraries.

 Thoughts?

The idea of using a single gc across multiple DLLs just doesn't sit well
with me. I prefer to make DLLs that are, as far as allocation goes,
independent of each other. To that end, the API a D DLL should expose should
be C style functions, COM interfaces, or D interfaces. The first two choices
have the nice feature that just about any decent language will have some
level of access to that DLL.

In particular I am not fond of the idea of making Phobos into a DLL. The
problem, as we all eventually run into, is DLL hell. Suppose you buy one D
app from vendor A, and another from vendor B. They each ship a different
phobos.dll. Which one do you use? Ak. Now, if you say keep A's phobos.dll on
an island with A's app, why not just statically link it in? (It's not like
there's a shortage of disk space!)

"Thomas Kuehne" <thomas-dloop kuehne.cn> writes:

Walter <newshound digitalmars.com> schrieb:
 "Kris" <Kris_member pathlink.com> wrote in message
 news:csrksh$mn3$1 digitaldaemon.com...
 Question: would D benefit from it's own (binary) link-loader? If the
 compiler were to spit out DDLs (Dynamic D Libraries), and the runtime
 had the equivalent of a linking-class-loader, then the issues regarding
 multiple GC's would go away
 (since the GC, and all libraries, would be DDLs instead).

 Such an approach would also presumeably expose D classes correctly, which
 is currently the other major problem regarding D and shared-libraries.

 Thoughts?

 The idea of using a single gc across multiple DLLs just doesn't sit well
 with me. I prefer to make DLLs that are, as far as allocation goes,
 independent of each other. To that end, the API a D DLL should expose should
 be C style functions, COM interfaces, or D interfaces. The first two choices
 have the nice feature that just about any decent language will have some
 level of access to that DLL.

 In particular I am not fond of the idea of making Phobos into a DLL. The
 problem, as we all eventually run into, is DLL hell. Suppose you buy one D
 app from vendor A, and another from vendor B. They each ship a different
 phobos.dll. Which one do you use? Ak. Now, if you say keep A's phobos.dll on
 an island with A's app, why not just statically link it in? (It's not like
 there's a shortage of disk space!)

The GC issue aside, a "phobos.dll on an island" does make sense. Suppose you
are using a D programm without direct access to the D sources or timely
customer support. If a new version of the Phobos.dll is available that features
bug fixes, you could instantly drop in the new Phobos.dll.

Thomas

"Walter" <newshound digitalmars.com> writes:

"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message
news:css767$1c4c$1 digitaldaemon.com...
 The GC issue aside, a "phobos.dll on an island" does make sense. Suppose

you
 are using a D programm without direct access to the D sources or timely
 customer support. If a new version of the Phobos.dll is available that

features
 bug fixes, you could instantly drop in the new Phobos.dll.

True, but now you (the application customer) are using a combination of
binaries that the vendor never tested. As an application vendor myself, I
just don't want to deal with those kind of "my app stopped working" issues.

Back in the distant memory, when dinosaurs ruled the earth and the
atmospheric oxygen content was 36%, I didn't have a linker to go with the
compiler. Microsoft conveniently shipped a linker with every version of
MS-DOS. The trouble started happening when Microsoft started shipping
multiple linkers, all with various different bugs. Some would work, some
would not. I started accumulating a "linker collection", dozens of them,
some that would work, some wouldn't, some worked under some circumstances
but not others, etc. It was a looming customer support disaster, that was
only solved when Bjorn Freeman-Benson came to my rescue and wrote a linker
(Blink.exe) for me.

Now, customers got a linker with predictable behavior, and I could even fix
bugs in it. The problems went away.

Having a phobos.dll doesn't cause those sorts of problems for myself, just
like the various versions of MS-LINK did not cause any problems for
Microsoft. But it *will* cause customer support problems for any application
vendor that ships a phobos.dll along with their application.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:css3k9$18ou$1 digitaldaemon.com...
 "Kris" <Kris_member pathlink.com> wrote in message
 news:csrksh$mn3$1 digitaldaemon.com...
 In article <csqmfc$2gm9$2 digitaldaemon.com>, Matthew says...
 <snip>
So, Hi! Hope you're all hale and hearty. And fill me in on all the good


 stuff.
 Hey Matthew; you'll be "not is" surprised to learn that the beloved issues
 surrounding DLLs and the GC are all still present (Sean's excellent work

 aside)
 .. stepping away from a statically-linked model still transports one back

 into
 the stone-age.

 Question: would D benefit from it's own (binary) link-loader? If the

 compiler
 were to spit out DDLs (Dynamic D Libraries), and the runtime had the

 equivalent
 of a linking-class-loader, then the issues regarding multiple GC's would

 go away
 (since the GC, and all libraries, would be DDLs instead).

 Such an approach would also presumeably expose D classes correctly, which

 is
 currently the other major problem regarding D and shared-libraries.

 Thoughts?

 The idea of using a single gc across multiple DLLs just doesn't sit well
 with me. I prefer to make DLLs that are, as far as allocation goes,
 independent of each other. To that end, the API a D DLL should expose should
 be C style functions, COM interfaces, or D interfaces. The first two choices
 have the nice feature that just about any decent language will have some
 level of access to that DLL.

 In particular I am not fond of the idea of making Phobos into a DLL. The
 problem, as we all eventually run into, is DLL hell. Suppose you buy one D
 app from vendor A, and another from vendor B. They each ship a different
 phobos.dll. Which one do you use? Ak. Now, if you say keep A's phobos.dll on
 an island with A's app, why not just statically link it in? (It's not like
 there's a shortage of disk space!)

It's certainly true that that's unpleasant, but if the alternative is that one
cannot talk "D" across link-units, then 
D's going to be pretty still born.

I believe we can concoct a better solution. Just not sure what ... yet.

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:css8vr$1e0b$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

news:css3k9$18ou$1 digitaldaemon.com...
 The idea of using a single gc across multiple DLLs just doesn't sit well
 with me. I prefer to make DLLs that are, as far as allocation goes,
 independent of each other. To that end, the API a D DLL should expose


should
 be C style functions, COM interfaces, or D interfaces. The first two


choices
 have the nice feature that just about any decent language will have some
 level of access to that DLL.

 In particular I am not fond of the idea of making Phobos into a DLL. The
 problem, as we all eventually run into, is DLL hell. Suppose you buy one


D
 app from vendor A, and another from vendor B. They each ship a different
 phobos.dll. Which one do you use? Ak. Now, if you say keep A's


phobos.dll on
 an island with A's app, why not just statically link it in? (It's not


like
 there's a shortage of disk space!)

 It's certainly true that that's unpleasant, but if the alternative is that

one cannot talk "D" across link-units, then
 D's going to be pretty still born.

You can - I just argue that that would be a poor design of a DLL.

 I believe we can concoct a better solution. Just not sure what ... yet.

Why not use D interfaces?

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:cssd2a$1ig3$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:css8vr$1e0b$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

 news:css3k9$18ou$1 digitaldaemon.com...
 The idea of using a single gc across multiple DLLs just doesn't sit well
 with me. I prefer to make DLLs that are, as far as allocation goes,
 independent of each other. To that end, the API a D DLL should expose


 should
 be C style functions, COM interfaces, or D interfaces. The first two


 choices
 have the nice feature that just about any decent language will have some
 level of access to that DLL.

 In particular I am not fond of the idea of making Phobos into a DLL. The
 problem, as we all eventually run into, is DLL hell. Suppose you buy one


 D
 app from vendor A, and another from vendor B. They each ship a different
 phobos.dll. Which one do you use? Ak. Now, if you say keep A's


 phobos.dll on
 an island with A's app, why not just statically link it in? (It's not


 like
 there's a shortage of disk space!)

 It's certainly true that that's unpleasant, but if the alternative is that

 one cannot talk "D" across link-units, then
 D's going to be pretty still born.

 You can - I just argue that that would be a poor design of a DLL.

 I believe we can concoct a better solution. Just not sure what ... yet.

 Why not use D interfaces?

But how do we manage the memory that may be exchanged between link units? Which
GC owns it? I confess I little 
understand this, but it seems pretty clear that if GCs are link unit-specific,
then there're going to be problems. 

John Reimer <brk_6502 yahoo.com> writes:

On Sat, 22 Jan 2005 13:32:52 +1100, Matthew wrote:

 
 "Walter" <newshound digitalmars.com> wrote in message
news:cssd2a$1ig3$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:css8vr$1e0b$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

 news:css3k9$18ou$1 digitaldaemon.com...
 The idea of using a single gc across multiple DLLs just doesn't sit well
 with me. I prefer to make DLLs that are, as far as allocation goes,
 independent of each other. To that end, the API a D DLL should expose


 should
 be C style functions, COM interfaces, or D interfaces. The first two


 choices
 have the nice feature that just about any decent language will have some
 level of access to that DLL.

 In particular I am not fond of the idea of making Phobos into a DLL. The
 problem, as we all eventually run into, is DLL hell. Suppose you buy one


 D
 app from vendor A, and another from vendor B. They each ship a different
 phobos.dll. Which one do you use? Ak. Now, if you say keep A's


 phobos.dll on
 an island with A's app, why not just statically link it in? (It's not


 like
 there's a shortage of disk space!)

 It's certainly true that that's unpleasant, but if the alternative is that

 one cannot talk "D" across link-units, then
 D's going to be pretty still born.

 You can - I just argue that that would be a poor design of a DLL.

 I believe we can concoct a better solution. Just not sure what ... yet.

 Why not use D interfaces?

 
 But how do we manage the memory that may be exchanged between link units?
Which GC owns it? I confess I little 
 understand this, but it seems pretty clear that if GCs are link unit-specific,
then there're going to be problems.


Make the GC part of the OS? :-)

(forgive me that wasn't very constructive).

- John R.

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:csse2a$1jk2$1 digitaldaemon.com...
 Why not use D interfaces?

 But how do we manage the memory that may be exchanged between link units?

Which GC owns it? I confess I little
 understand this, but it seems pretty clear that if GCs are link

unit-specific, then there're going to be problems.

GC's own memory that is allocated from the pool it controls. A gc will not
free a pointer unless it is pointing into its own pool. Next, a gc looks for
pointers by examining its "roots". The roots include the stack and the
static data owned by the dll. Other roots can be manually added to the gc's
scan list through the gc API.

The easy answer is maintain a pointer to the allocated memory in the DLL
that allocated it, in one of the roots that are scanned by its gc.

Kris <Kris_member pathlink.com> writes:

In article <cssd2a$1ig3$1 digitaldaemon.com>, Walter says...
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:css8vr$1e0b$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

news:css3k9$18ou$1 digitaldaemon.com...
 The idea of using a single gc across multiple DLLs just doesn't sit well
 with me. I prefer to make DLLs that are, as far as allocation goes,
 independent of each other. To that end, the API a D DLL should expose


should
 be C style functions, COM interfaces, or D interfaces. The first two


choices
 have the nice feature that just about any decent language will have some
 level of access to that DLL.

 In particular I am not fond of the idea of making Phobos into a DLL. The
 problem, as we all eventually run into, is DLL hell. Suppose you buy one


D
 app from vendor A, and another from vendor B. They each ship a different
 phobos.dll. Which one do you use? Ak. Now, if you say keep A's


phobos.dll on
 an island with A's app, why not just statically link it in? (It's not


like
 there's a shortage of disk space!)

 It's certainly true that that's unpleasant, but if the alternative is that

one cannot talk "D" across link-units, then
 D's going to be pretty still born.

You can - I just argue that that would be a poor design of a DLL.

 I believe we can concoct a better solution. Just not sure what ... yet.

Why not use D interfaces?

It would be great to use interfaces. I presume you mean "in conjunction with a
Factory Pattern" ?

Surely the obvious problem is this, Walter:

1) the factory (within the DLL) would create the implementing class, and hand it
back to the caller
2) the caller now hangs onto the returned interface handle
3) the DLL GC thinks there are no more references to the constructed class, and
reaps it
4) the other GC (from the caller) may try to reap the interface handle, which
does not belong within its pools

There are many more, non-trivial, examples.

Since we're talking about the factory pattern, one might consider adding a
version number as an argument? So the client could specify some kind of expected
version? Perhaps not ideal, but it might address some of your concerns?

- Kris

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Kris" <Kris_member pathlink.com> wrote in message
news:csse93$1jq1$1 digitaldaemon.com...
 In article <cssd2a$1ig3$1 digitaldaemon.com>, Walter says...
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:css8vr$1e0b$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

news:css3k9$18ou$1 digitaldaemon.com...
 The idea of using a single gc across multiple DLLs just doesn't sit well
 with me. I prefer to make DLLs that are, as far as allocation goes,
 independent of each other. To that end, the API a D DLL should expose


should
 be C style functions, COM interfaces, or D interfaces. The first two


choices
 have the nice feature that just about any decent language will have some
 level of access to that DLL.

 In particular I am not fond of the idea of making Phobos into a DLL. The
 problem, as we all eventually run into, is DLL hell. Suppose you buy one


D
 app from vendor A, and another from vendor B. They each ship a different
 phobos.dll. Which one do you use? Ak. Now, if you say keep A's


phobos.dll on
 an island with A's app, why not just statically link it in? (It's not


like
 there's a shortage of disk space!)

 It's certainly true that that's unpleasant, but if the alternative is that

one cannot talk "D" across link-units, then
 D's going to be pretty still born.

You can - I just argue that that would be a poor design of a DLL.

 I believe we can concoct a better solution. Just not sure what ... yet.

Why not use D interfaces?

 It would be great to use interfaces. I presume you mean "in conjunction with a
 Factory Pattern" ?

 Surely the obvious problem is this, Walter:

 1) the factory (within the DLL) would create the implementing class, and hand
it
 back to the caller
 2) the caller now hangs onto the returned interface handle
 3) the DLL GC thinks there are no more references to the constructed class, and
 reaps it
 4) the other GC (from the caller) may try to reap the interface handle, which
 does not belong within its pools

Exactly. That's one of I guess many that'd cause problems.

 There are many more, non-trivial, examples.

 Since we're talking about the factory pattern, one might consider adding a
 version number as an argument? So the client could specify some kind of
expected
 version? Perhaps not ideal, but it might address some of your concerns?

I strongly believe that we need to handle *all* situations *gracefully*. Hacks
are not going to work, both politically, 
and also in terms of sustainability.

"Walter" <newshound digitalmars.com> writes:

"Kris" <Kris_member pathlink.com> wrote in message
news:csse93$1jq1$1 digitaldaemon.com...
Why not use D interfaces?

 It would be great to use interfaces. I presume you mean "in conjunction

with a
 Factory Pattern" ?

 Surely the obvious problem is this, Walter:

 1) the factory (within the DLL) would create the implementing class, and

hand it
 back to the caller
 2) the caller now hangs onto the returned interface handle
 3) the DLL GC thinks there are no more references to the constructed

class, and
 reaps it

How the gc works is it scans regions for roots. If any those roots point
into the gc's own memory pool, the associated allocated memory is not
deleted. So the solution here is to add the ranges of the caller where the
handle may reside to the DLL's gc. The stack is already there, because the
DLL and the caller share the same stack.

Another way is to use the COM style AddRef and Release.

 4) the other GC (from the caller) may try to reap the interface handle,

which
 does not belong within its pools

This won't happen because the gc won't reap memory which is not in its own
pool.

 There are many more, non-trivial, examples.

 Since we're talking about the factory pattern, one might consider adding a
 version number as an argument? So the client could specify some kind of

expected
 version? Perhaps not ideal, but it might address some of your concerns?

COM uses the guid approach for this. It hasn't worked out as well in
practice as was initially hoped.

Matthias Becker <Matthias_member pathlink.com> writes:

"Kris" <Kris_member pathlink.com> wrote in message
news:csse93$1jq1$1 digitaldaemon.com...
Why not use D interfaces?

 It would be great to use interfaces. I presume you mean "in conjunction

with a
 Factory Pattern" ?

 Surely the obvious problem is this, Walter:

 1) the factory (within the DLL) would create the implementing class, and

hand it
 back to the caller
 2) the caller now hangs onto the returned interface handle
 3) the DLL GC thinks there are no more references to the constructed

class, and
 reaps it

How the gc works is it scans regions for roots. If any those roots point
into the gc's own memory pool, the associated allocated memory is not
deleted. So the solution here is to add the ranges of the caller where the
handle may reside to the DLL's gc. The stack is already there, because the
DLL and the caller share the same stack.

So I have to do it on my own. But wasn't a GC about not having to do
memory-management on my own. I am confused.

Another way is to use the COM style AddRef and Release.

In my world there isn't anything like release, close, dispose, ... . Everything
is done by RAII. At least this is ture for my C++ code. I haven't done any big
project in D, yet. But as RAII is one of D's features I hope I will be able to
continue this style.


-- Matthias Becker

Kris <Kris_member pathlink.com> writes:

In article <css3k9$18ou$1 digitaldaemon.com>, Walter says...
"Kris" <Kris_member pathlink.com> wrote in message
news:csrksh$mn3$1 digitaldaemon.com...
 In article <csqmfc$2gm9$2 digitaldaemon.com>, Matthew says...
 <snip>
So, Hi! Hope you're all hale and hearty. And fill me in on all the good


stuff.
 Hey Matthew; you'll be "not is" surprised to learn that the beloved issues
 surrounding DLLs and the GC are all still present (Sean's excellent work

aside)
 .. stepping away from a statically-linked model still transports one back

into
 the stone-age.

 Question: would D benefit from it's own (binary) link-loader? If the

compiler
 were to spit out DDLs (Dynamic D Libraries), and the runtime had the

equivalent
 of a linking-class-loader, then the issues regarding multiple GC's would

go away
 (since the GC, and all libraries, would be DDLs instead).

 Such an approach would also presumeably expose D classes correctly, which

is
 currently the other major problem regarding D and shared-libraries.

 Thoughts?

The idea of using a single gc across multiple DLLs just doesn't sit well
with me. I prefer to make DLLs that are, as far as allocation goes,
independent of each other. To that end, the API a D DLL should expose should
be C style functions, COM interfaces, or D interfaces. The first two choices
have the nice feature that just about any decent language will have some
level of access to that DLL.

In particular I am not fond of the idea of making Phobos into a DLL. The
problem, as we all eventually run into, is DLL hell. Suppose you buy one D
app from vendor A, and another from vendor B. They each ship a different
phobos.dll. Which one do you use? Ak. Now, if you say keep A's phobos.dll on
an island with A's app, why not just statically link it in? (It's not like
there's a shortage of disk space!)


Please read that last sentence again, Walter ... what we're trying to do is
build systems that /cannot/ be statically linked. That's the whole point. 

When you attempt to build any kind of dynamic system in D, all hell breaks loose
regarding MM, small mobile-behaviours become enormously bloated (saturating
bandwidth), and development becomes systematically more complex than it would be
if these issues were resolved.

Would you prefer everybody to statically link their code with, say, a Relational
Database? If said DB was written in D, who would be responsible for managing
memory?

There are some very serious issues regarding what happens when memory is
allocated within one GC and then manipulated within another. And there are many,
many ways for that to happen. Do you think we should all manage that ourselves?
The current situation allows for one GC to reap memory that's currently in use
elsewhere; I hope you can agree such behaviour is "non-productive"? While you
may prefer to keep the allocation seperated between DLLs, you don't offer a
reasonable solution for the programmer.

Your argument has to do with library versioning, right? Perhaps you might do
something creative with a DLL loader? Whatever ...  

The upshot of this, as you know, is that D is seriously crippled from a dynamic
perspective. Yes, one can link a C-based dynamic library. Yet one cannot link to
a D library without jumping through a number of hoops. oh; and thoroughly
understanding all the many devilish issues regarding memory allocation across
multiple GC instances. Oh! And then inventing a whole bunch of code to manage
those multiple GC instances. 

If that sounds absurd, well, that's because it is. 

We should also recognize that the Corporate Environment will (rightfully)
consider D as a toy, without such facilities exposed in a natural, robust,
comprehensive, and comprehendable manner.

Personally, I just don't get it, Walter. This is an issue that has always been
around, yet all suggestions made thus far (from several people) have either been
thoroughly ignored or simply "pooh poohed" by you. How about something a little
more constructive instead? How about opening up a productive discussion amongst
the members here?

As for DLLs themselves -- I don't give a toss how things are implemented, so
long as:

(a) one can dynamically load, and naturally access, classes exposed via a D
shared-library 

(b) there are no bizarre, sneaky, or obscure gotcha's regarding memory
allocations between a shared-lib and an application (or other shared-lib)

IMHO;

- Kris


P.S. Does this feel more like the NG you've been missing, Matthew? 

:-)

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Kris" <Kris_member pathlink.com> wrote in message
news:cssd33$1igm$1 digitaldaemon.com...
 In article <css3k9$18ou$1 digitaldaemon.com>, Walter says...
"Kris" <Kris_member pathlink.com> wrote in message
news:csrksh$mn3$1 digitaldaemon.com...
 In article <csqmfc$2gm9$2 digitaldaemon.com>, Matthew says...
 <snip>
So, Hi! Hope you're all hale and hearty. And fill me in on all the good


stuff.
 Hey Matthew; you'll be "not is" surprised to learn that the beloved issues
 surrounding DLLs and the GC are all still present (Sean's excellent work

aside)
 .. stepping away from a statically-linked model still transports one back

into
 the stone-age.

 Question: would D benefit from it's own (binary) link-loader? If the

compiler
 were to spit out DDLs (Dynamic D Libraries), and the runtime had the

equivalent
 of a linking-class-loader, then the issues regarding multiple GC's would

go away
 (since the GC, and all libraries, would be DDLs instead).

 Such an approach would also presumeably expose D classes correctly, which

is
 currently the other major problem regarding D and shared-libraries.

 Thoughts?

The idea of using a single gc across multiple DLLs just doesn't sit well
with me. I prefer to make DLLs that are, as far as allocation goes,
independent of each other. To that end, the API a D DLL should expose should
be C style functions, COM interfaces, or D interfaces. The first two choices
have the nice feature that just about any decent language will have some
level of access to that DLL.

In particular I am not fond of the idea of making Phobos into a DLL. The
problem, as we all eventually run into, is DLL hell. Suppose you buy one D
app from vendor A, and another from vendor B. They each ship a different
phobos.dll. Which one do you use? Ak. Now, if you say keep A's phobos.dll on
an island with A's app, why not just statically link it in? (It's not like
there's a shortage of disk space!)


 Please read that last sentence again, Walter ... what we're trying to do is
 build systems that /cannot/ be statically linked. That's the whole point.

 When you attempt to build any kind of dynamic system in D, all hell breaks
loose
 regarding MM, small mobile-behaviours become enormously bloated (saturating
 bandwidth), and development becomes systematically more complex than it would
be
 if these issues were resolved.

 Would you prefer everybody to statically link their code with, say, a
Relational
 Database? If said DB was written in D, who would be responsible for managing
 memory?

 There are some very serious issues regarding what happens when memory is
 allocated within one GC and then manipulated within another. And there are
many,
 many ways for that to happen. Do you think we should all manage that ourselves?
 The current situation allows for one GC to reap memory that's currently in use
 elsewhere; I hope you can agree such behaviour is "non-productive"? While you
 may prefer to keep the allocation seperated between DLLs, you don't offer a
 reasonable solution for the programmer.

 Your argument has to do with library versioning, right? Perhaps you might do
 something creative with a DLL loader? Whatever ...

 The upshot of this, as you know, is that D is seriously crippled from a dynamic
 perspective. Yes, one can link a C-based dynamic library. Yet one cannot link
to
 a D library without jumping through a number of hoops. oh; and thoroughly
 understanding all the many devilish issues regarding memory allocation across
 multiple GC instances. Oh! And then inventing a whole bunch of code to manage
 those multiple GC instances.

 If that sounds absurd, well, that's because it is.

 We should also recognize that the Corporate Environment will (rightfully)
 consider D as a toy, without such facilities exposed in a natural, robust,
 comprehensive, and comprehendable manner.

 Personally, I just don't get it, Walter. This is an issue that has always been
 around, yet all suggestions made thus far (from several people) have either
been
 thoroughly ignored or simply "pooh poohed" by you. How about something a little
 more constructive instead? How about opening up a productive discussion amongst
 the members here?

 As for DLLs themselves -- I don't give a toss how things are implemented, so
 long as:

 (a) one can dynamically load, and naturally access, classes exposed via a D
 shared-library

 (b) there are no bizarre, sneaky, or obscure gotcha's regarding memory
 allocations between a shared-lib and an application (or other shared-lib)

 IMHO;

 - Kris


 P.S. Does this feel more like the NG you've been missing, Matthew?

 :-)

Sounding more and more normal. ;)

But I agree with your implication of the importance of this issue to D. As I've
said three times in the last 24hrs, 
without an effective and elegant (i.e. totally ignorable to 98% of users)
solution, D will be stillborn. Of that I have 
no doubt. Hence, I agree with Kris that Walter needs to consider this to be a
serious issue, and a mandatory pre-1.0 
accomplishment.

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cssdt2$1jea$1 digitaldaemon.com...
 But I agree with your implication of the importance of this issue to D. As

I've said three times in the last 24hrs,
 without an effective and elegant (i.e. totally ignorable to 98% of users)

solution, D will be stillborn. Of that I have
 no doubt. Hence, I agree with Kris that Walter needs to consider this to

be a serious issue, and a mandatory pre-1.0
 accomplishment.

Memory management is never totally ignorable, in any language. And I know of
no DLLs in any language where one can totally ignore memory management and
not get into nasty trouble.

kris <fu bar.org> writes:

Walter wrote:
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cssdt2$1jea$1 digitaldaemon.com...
 
But I agree with your implication of the importance of this issue to D. As

 
 I've said three times in the last 24hrs,
 
without an effective and elegant (i.e. totally ignorable to 98% of users)

 
 solution, D will be stillborn. Of that I have
 
no doubt. Hence, I agree with Kris that Walter needs to consider this to

 
 be a serious issue, and a mandatory pre-1.0
 
accomplishment.

 
 
 Memory management is never totally ignorable, in any language. And I know of
 no DLLs in any language where one can totally ignore memory management and
 not get into nasty trouble.
 
 

With respect, Walter, that kind of rebuke is somewhat pedantic and 
seemingly irrational.

I'd like to ask you to consider the field here:

1) dynamically (non-statically) linked systems are a reality, and they 
are important. Please put aside the specifics of MS DLLs, and think 
about what you can do with such systems: grid-computing, agent-based 
systems, the lofty goals of ubiquitous computing, even a lowly web-server.

2) D, like other moderns languages, deliberately removes the need to 
explicitly manage heap allocation. Yet to build said dynamic systems in 
D, one must revert to C-style heap management and, at the same time, 
both understand and compensate for every little nuance of the particular 
GC itself. There is a pre-requisite for uber-expertise before embarking 
on such a trail, and the maintainence thereof. These are surely blatant 
contradictions for a language such as D?

3) allowing for one, per-process, GC cleanly and elegantly resolves the 
problems of (2) and thereby opens the doors of (1) to D.

4) one approach to implement a per-process GC is to place it into its 
own shared-lib. You have noted some concerns about "DLL hell" for such 
an implementation.


Three questions arise:

a) do you feel there's not much value in anything but statically-linked 
systems? If yes, then I will understand you position much more clearly.

b) assuming "no" to (a), is there another means of implementing a single 
per-process GC, without placing it into a shared-lib?

c) please consider the serious difficulties exposed to the programmer 
when dealing with (and maintaining) the fallout from multpile GC 
instances, and balance that against the likelyhood of "DLL hell" 
specifically for a D GC shared-lib instance. Please also consider if 
there's a means of implementing that specific shared-lib such that any 
potential for the latter would be further minimized, or completely 
eliminated.

Thanks;

Norbert Nemec <Norbert Nemec-online.de> writes:

Walter wrote:

 Memory management is never totally ignorable, in any language. And I know
 of no DLLs in any language where one can totally ignore memory management
 and not get into nasty trouble.

Might that be an inherent Windows problem? In Linux, I see no direct
connection between memory management and dynamic linking at all. Each
process has its memory and it does not matter at all whether the code of
that process is statically linked or placed in a dll.

Also, the versioning of dlls is not a problem at all under Linux. Of course,
one has to be careful about it, there are tons of sophisticated tools to
help with that.

What is important to consider: Dynamic loading is not just a means of saving
diskspace and RAM but also a very important method for plugins and other
kinds of sophisticated programming methods.

I know, that under Windows, DLLs are such a hassle that it really is the
easiest solution to avoid them, but then, using Windows at all actually is
such a hassle that it is the easiest solution to avoid using it...

David L. Davis <SpottedTiger yahoo.com> writes:

Norbert Nemec says...
I know, that under Windows, DLLs are such a hassle that it really is the
easiest solution to avoid them, but then, using Windows at all actually is
such a hassle that it is the easiest solution to avoid using it...

Norbert: I agreed with your other points...but in the sentence above, I really
wish you'd be more careful about stepping on another man's OS. I've been making
a good livelihood programming Windows applications in MS Visual Basic v6.0 SP6

world). And to tell the truth, I've never had any real problems with creating
and using DLLs, only when writing them in C (my past second language choose, now
it's D then followed by C) which most of the time it was somethiing I wrote
incorrectly. So this whole Windows' DLLs are a hassle thing seems like wishful
thinking on your part to me. 

Besides, if Linux is your thing, more power to ya! In fact with Linux growing
like it is, I think MS will be forced to make an even better Windows OS...so we
both win!! :))

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Norbert Nemec <Norbert Nemec-online.de> writes:

David L. Davis wrote:

 Norbert Nemec says...
I know, that under Windows, DLLs are such a hassle that it really is the
easiest solution to avoid them, but then, using Windows at all actually is
such a hassle that it is the easiest solution to avoid using it...

 Norbert: I agreed with your other points...but in the sentence above, I
 really wish you'd be more careful about stepping on another man's OS.

OK, sorry for becoming a bit polemic in that sentence above. It's just that
I've had years of intricate experience with Windows myself, so I've built
up a certain amount of steam which shows up once in a while. I hope
everybody will understand from the words above, that this is a personal
opinion. I am still willing to live in peace and cooperate with anybody who
doesn't share it.

 I've 
 been making a good livelihood programming Windows applications in MS
 Visual Basic v6.0 SP6 my primary language (not everyone has come to D from

 real problems with creating and using DLLs, only when writing them in C
 (my past second language choose, now it's D then followed by C) which most
 of the time it was somethiing I wrote incorrectly. So this whole Windows'
 DLLs are a hassle thing seems like wishful thinking on your part to me.

Sorry to disagree here. VB certainly is a nice language, but you should be
aware that it shields the programmer from the operating system by a good
deal. The intricate details of creating and using DLLs are covered by the
programming system, at the cost of performance and flexibility.

As you state, you already gained experience with handling DLLs in C, so you
know the difficulty. It is just this complexity that D has to deal with. Of
course: 95% of the problems arise from incorrect code by the 'user'. The
'hassle' that I am talking about is the difficulty to get it correct.

I did some (relatively simple) DLL programming on Windows myself, so I
really can compare it to Linux. I know Linux much better, so I'm certainly
biased (assume you guessed that already... :-)  ) but it certainly is more
than wishful thinking when I talk about the hassles of programming Windows
without a huge safety-belt like VB.

 Besides, if Linux is your thing, more power to ya! In fact with Linux
 growing like it is, I think MS will be forced to make an even better
 Windows OS...so we both win!! :))

I fear, history shows, that MS will first try to pull all other tricks out
of the box (law suits, FUD, etc.) before actually sitting down and
improving their products. :-(

Georg Wrede <georg.wrede nospam.org> writes:

Matthew wrote:
 Sounding more and more normal. ;)
 
 But I agree with your implication of the importance of this issue to D. As
I've said three times in the last 24hrs, 
 without an effective and elegant (i.e. totally ignorable to 98% of users)
solution, D will be stillborn. Of that I have 
 no doubt. Hence, I agree with Kris that Walter needs to consider this to be a
serious issue, and a mandatory pre-1.0 
 accomplishment.

If D-made DLLs were only used from D-made programs, then we'd have a lot 
more freedom.

Until the OS does provide gc, the dll has to manage its own gc, at least 
when called from a non-D program.

Besides, DLLs written in non-gc languages manage their own memory, too.

(OT: Gee, I wish there was a "standalone gc" OSS project, having a well 
designed api, and robust, well known implementations for the most used 
OSs! A Pipe Dream, I know.)

I am afraid fixing this issue may be so hard that D1.0 can't wait for 
it. Maybe D1.5 or something, but please, not 1.0.

With the unfathomable experience Walter has, an accurate intuition 
follows. That's why he might not be able to refute exactly every attack 
with fact-by-fact analysis. Not to mention the time it would take away 
from actually developing D.

One solution would be a non-standard, for D-use-only DDL (dynamic D 
library  :-) that uses the main program's gc, and solves whatever other 
issues on the side. But this would not be much better than the ancient 
CP/M Program Overlays.

Norbert Nemec <Norbert Nemec-online.de> writes:

I still don't understand: where is the problem with a dynamically linked gc
like the Boehm GC? Every D-created DLL would just link to that one and use
it for its memory management.

As long as you link together only D libraries, each one will link to the
same GC, so there exists only one GC handling everything.

If you mix D libraries with foreign libraries, the foreign libraries could
either use the same GC (which should have a C interface like every DLL) or
they ignore it, doing their own memory management.

In the last case, danger only arises when you pass around pointers between
GC and non-GC code. That case, of course, is always tricky, but that does
not change at all whether you have dynamic or static linking.

Ciao,
Norbert


Georg Wrede wrote:

 Matthew wrote:
 Sounding more and more normal. ;)
 
 But I agree with your implication of the importance of this issue to D.
 As I've said three times in the last 24hrs, without an effective and
 elegant (i.e. totally ignorable to 98% of users) solution, D will be
 stillborn. Of that I have no doubt. Hence, I agree with Kris that Walter
 needs to consider this to be a serious issue, and a mandatory pre-1.0
 accomplishment.

 
 If D-made DLLs were only used from D-made programs, then we'd have a lot
 more freedom.
 
 Until the OS does provide gc, the dll has to manage its own gc, at least
 when called from a non-D program.
 
 Besides, DLLs written in non-gc languages manage their own memory, too.
 
 (OT: Gee, I wish there was a "standalone gc" OSS project, having a well
 designed api, and robust, well known implementations for the most used
 OSs! A Pipe Dream, I know.)
 
 I am afraid fixing this issue may be so hard that D1.0 can't wait for
 it. Maybe D1.5 or something, but please, not 1.0.
 
 With the unfathomable experience Walter has, an accurate intuition
 follows. That's why he might not be able to refute exactly every attack
 with fact-by-fact analysis. Not to mention the time it would take away
 from actually developing D.
 
 One solution would be a non-standard, for D-use-only DDL (dynamic D
 library  :-) that uses the main program's gc, and solves whatever other
 issues on the side. But this would not be much better than the ancient
 CP/M Program Overlays.

kris <fu bar.org> writes:

Norbert Nemec wrote:
 I still don't understand: where is the problem with a dynamically linked gc
 like the Boehm GC? Every D-created DLL would just link to that one and use
 it for its memory management.
 
 As long as you link together only D libraries, each one will link to the
 same GC, so there exists only one GC handling everything.
 
 If you mix D libraries with foreign libraries, the foreign libraries could
 either use the same GC (which should have a C interface like every DLL) or
 they ignore it, doing their own memory management.
 
 In the last case, danger only arises when you pass around pointers between
 GC and non-GC code. That case, of course, is always tricky, but that does
 not change at all whether you have dynamic or static linking.
 
 Ciao,
 Norbert

Exactly, Norbert.

Unfortunately, D internalizes specific kinds of memory allocations: 
adjusting the length of an array, for example.

What we're effectively asking for is for D to expose all such behavior, 
such that the GC can be treated as a third-, and shareable, party. Just 
as you suggest.

Additionally, the static-data extents of each shared-lib need to be 
registered with the GC as potential roots (in the same manner as 
statically-linked code). The latter is really a job for the compiler, 
although it could perhaps be done manually?

Walter is apparently concerned that exposing the GC as an externalized 
entity (a shared-lib) will lead to all kinds of versioning conflict. Yet 
the upside is that MM would become trivial, robust, comprehensive, and 
comprehendable for component-based designs (for D code) -- one could 
immediately build sophisticated, dynamic systems.

The alternative (what we have now with multiple GC instances) leads to 
incredibly pedantic management of multiple heaps, by the programmer. 
This is actually much worse than malloc/free, since the multiple GC 
instances effectively fight against you. And that's without considering 
the cognitive model-change, switching from a managed-memory environment 
(statically-linked D) to one that could be termed "disruptive memory 
management".

Pragma ran into some truly hideous problems with his DSP project, doing 
just this kind of thing. I've held off doing large scale grid-style 
processing (via mango.cluster) for many months, waiting for this to be 
resolved. Such issues are truly holding D back. Sean has taken the 
initiative, and has managed to pry the GC away from DMD such that it 
/can/ actually be located in a shared-lib. All we need is for the 
compiler to generate static-data roots for DLLs and so on ...

Theoretically speaking, Walter is correct in saying the programmer can 
manage all this by themselves. However, that argument is no different 
that one calling for the removal of GC altogether. Therein lies the 
conflict: to do what Walter proposes would actually be considerably 
simpler, and more robust, if the GC did not exist at all, and we all 
went back to explicitly managing heap allocations.

Again; the only reason for the pushback on this is Walter's concern over 
what he terms "DLL hell". Yes, that is perhaps of some concern. Yet, 
let's put that into perspective: exactly how often would this happen 
with a GC shared-lib? And, couldn't the "DLL hell" be managed for this 
one specific case? I think it can. And when you consider the downside of 
not doing it, one simply cannot fathom the pushback.

Pragma <Pragma_member pathlink.com> writes:

In article <ct0v2s$1cl2$1 digitaldaemon.com>, kris says...
Again; the only reason for the pushback on this is Walter's concern over 
what he terms "DLL hell". Yes, that is perhaps of some concern. Yet, 
let's put that into perspective: exactly how often would this happen 
with a GC shared-lib? And, couldn't the "DLL hell" be managed for this 
one specific case? I think it can. And when you consider the downside of 
not doing it, one simply cannot fathom the pushback.

Yet there are ways to circumvent the majority of issues involved with multiple
dll versions hanging around.  If you break down the whole "dll hell" scenario
you get the following patterns:

1) Finding the wrong dll by name.
2) Finding the right dll, with the wrong version internally.
3) Not finding any dll at all due to some sort of misconfiguration.

Which arise due to simple file names (and 8.3 filenames in old DOS systems), a
commmon misconception about what versioning actually does to code, and lazyness
and/or coding mistakes (dll loader code not versatile enough for the current
environment). :)

For D-Dyanmic Libraries, and the proposed GC-DDL itself, I would like to
reccomend the following solutions to be used in concert:


1) encoding the build version into the library filename.

This is *really* easy to do, and could possibly be better managed by dmd or
d-compiler toolchain of some kind.  For example, if we put the version number
into the name of the dll, it will allow multiple GC versions to co-exist within
the same directory.

Example:
dgc.0.111.dll
dgc.1.0.dll
mango.1.1.dll
mylib.0.42.dll

The advantages here are obvious: its easy to see what you have, and all the more
so when placed in the same directory.


2) exposing a standard DDL function, for all DDLs, that returns the current
build or GUID/UUID based on the program name and version (akin to strong-names
for .Net).

Having a verification mechanism is a good way to avoid versioning problems; the
application can compensate early (or halt) if the wrong library is found.  IMO,
something like this would be best suited by some form of compiler support,
although it /can/ be managed manually.   

I'll add that its also cross-platform since it doesn't rely on any OS-specific
metadata features.

This also opens the door for additional metadata to be served by DDLs in the
future, if for instance a sister method could describe the kind of library used
(eg. "i have a GC compiled in", "i'm a class library", or "i'm for C
compatibility only").


3) providing a standard library loader in Phobos that is more flexible than the
present solutions for windows and unix/linux (std.loader on steroids).


sane approach.  There are also some differing behaviors in how search paths are
investigated, that may warrant some inclusion (and discussion) into std.loader.

- The dll search order in Windows is different between versions and
ditributions.  Some anecdotes I've managed to dig up in 5 minutes of googling
show a wide variety of things.  Basically, the *latest* versions of windows (and
service packs) force the OS to search the System file tree before the
application directory.  Older versions will do the opposite.

- There is also a useful win32 api function, SetDllDirectory, that is not
available on Win2k.

- I assume that unix/linux is pretty much solid since it would likely use the
current search path and leave it at that.  Is this so?  It may be a moot point,
but unless you can guarantee that /var, /etc, /lib and /sbin (or any other
critical system directory) are first on the path, then it has the potential for
behavior different from its non-unix counterparts.

I'd also like to advocate that the fact that D is "installation path agnostic",
is truely a blessing.  I think we can create a solid GC-Dynamic Library *and*
General-Purpose Dynamic Library solution for D without sacrificing this.

- Pragma

pragma <pragma_member pathlink.com> writes:

I know it's in poor taste to reply to one's own post, but there was one issue I
left out:

4) Problem: the possible creation of multiple instances of the exact same DLL in
memory.

I can only think of solutions as exotic as the problem itself.  Granted, careful
management, and smart loading of libraries (especially the proposed GC-library)
may help mitigate this.  Also, the careful installation of such libraries in a
system would also be critical; maybe we need to agree on where such common files
should be installed?

I think this point really needs discussion.  

The only facts I can contribute is that .Net uses a system service to provide a
universal hook for the VM and Java (as most here probably know) uses environment
vars and the system path.  

Perhaps we could use some form of IPC so GC's can "talk" to each other (GC1 to
GC2: "hey, I'm new here and we're the same version, so give me your free-list
ptr, object-list ptr and mutex so I can help this other process out") is
probably out of the question; but it might be worth a try.  

It may also be worth noting that all of the above could very well be moot simply
because an admin could use *just* the file system to steer apps/libs onto a
particular GC instance.  After all, I'm sure having all your D the same exact GC
instance might be a problem; isolation is good for plenty of reasons.

- EricAnderton at yahoo

Norbert Nemec <Norbert Nemec-online.de> writes:

Pragma wrote:

 In article <ct0v2s$1cl2$1 digitaldaemon.com>, kris says...
Again; the only reason for the pushback on this is Walter's concern over
what he terms "DLL hell". Yes, that is perhaps of some concern. Yet,
let's put that into perspective: exactly how often would this happen
with a GC shared-lib? And, couldn't the "DLL hell" be managed for this
one specific case? I think it can. And when you consider the downside of
not doing it, one simply cannot fathom the pushback.

 
 Yet there are ways to circumvent the majority of issues involved with
 multiple
 dll versions hanging around.  If you break down the whole "dll hell"
 scenario you get the following patterns:
 
 1) Finding the wrong dll by name.
 2) Finding the right dll, with the wrong version internally.
 3) Not finding any dll at all due to some sort of misconfiguration.

I don't even want to understand that whole issue but just add one comment
for the record:
As I guessed before, this issue really is a pure Windows issue. Under Linux
(and probably under MacOS X also) there is a sophisticated system of
dealing with library versions given by the operating system.

For Windows, I would propose the solution that is used for Windows in
general: leave the handling of dll versioning to the installer and don't
try to solve it in the compiler. There are a number of installers available
for anyone who needs to distribute software. 

If somebody wants to link their program statically, this should be an option
and it might be the simplest solution for anyone who just writes a single
program and wants to save the hassle. Anybody who writes a complicated set
of applications and needs to use DLLs, though, should have that option and
should be aware that he'll have to solve the versioning and distribution
problem himself.

Trying to find a sophisticated versioning scheme for libraries really is a
job for the operating system designers. Trying to solve this in the
compiler will result in a complicated situation that creates more confusion
than it solves.

Ant <duitoolkit yahoo.ca> writes:

On Mon, 24 Jan 2005 23:38:46 +0100, Norbert Nemec wrote:

 Pragma wrote:
 
 "DLL hell".



 I don't even want to understand that whole issue but just add one comment

[...]
  leave the handling of dll versioning to the installer and don't
 try to solve it in the compiler. 

[...]

I agree.

Ant

Paul Bonser <misterpib gmail.com> writes:

Pragma wrote:
 In article <ct0v2s$1cl2$1 digitaldaemon.com>, kris says...
 
Again; the only reason for the pushback on this is Walter's concern over 
what he terms "DLL hell". Yes, that is perhaps of some concern. Yet, 
let's put that into perspective: exactly how often would this happen 
with a GC shared-lib? And, couldn't the "DLL hell" be managed for this 
one specific case? I think it can. And when you consider the downside of 
not doing it, one simply cannot fathom the pushback.

 
 
 Yet there are ways to circumvent the majority of issues involved with multiple
 dll versions hanging around.  If you break down the whole "dll hell" scenario
 you get the following patterns:
 
 1) Finding the wrong dll by name.
 2) Finding the right dll, with the wrong version internally.
 3) Not finding any dll at all due to some sort of misconfiguration.
 
 Which arise due to simple file names (and 8.3 filenames in old DOS systems), a
 commmon misconception about what versioning actually does to code, and lazyness
 and/or coding mistakes (dll loader code not versatile enough for the current
 environment). :)
 
 For D-Dyanmic Libraries, and the proposed GC-DDL itself, I would like to
 reccomend the following solutions to be used in concert:
 
 
 1) encoding the build version into the library filename.
 
 This is *really* easy to do, and could possibly be better managed by dmd or
 d-compiler toolchain of some kind.  For example, if we put the version number
 into the name of the dll, it will allow multiple GC versions to co-exist within
 the same directory.
 
 Example:
 dgc.0.111.dll
 dgc.1.0.dll
 mango.1.1.dll
 mylib.0.42.dll
 
 The advantages here are obvious: its easy to see what you have, and all the
more
 so when placed in the same directory.
 
 
 2) exposing a standard DDL function, for all DDLs, that returns the current
 build or GUID/UUID based on the program name and version (akin to strong-names
 for .Net).
 
 Having a verification mechanism is a good way to avoid versioning problems; the
 application can compensate early (or halt) if the wrong library is found.  IMO,
 something like this would be best suited by some form of compiler support,
 although it /can/ be managed manually.   
 
 I'll add that its also cross-platform since it doesn't rely on any OS-specific
 metadata features.
 
 This also opens the door for additional metadata to be served by DDLs in the
 future, if for instance a sister method could describe the kind of library used
 (eg. "i have a GC compiled in", "i'm a class library", or "i'm for C
 compatibility only").
 
 
 3) providing a standard library loader in Phobos that is more flexible than the
 present solutions for windows and unix/linux (std.loader on steroids).
 

I think that this scheme would work very well, not just for D, but for 
anything, really. But for D, I think it would be ideally perfect, or 
perfectly ideal. Even if only the version part ever gets used, it would 
give a great deal of help to the whole dynamic situation.
I'd really like to see D be set up so it helps with dynamic libraries 
rather than fights against them.
There are many applications for being able to load libraries as plugins 
to a program that cannot be implemented as static libraries (not without 
recompiling the main program each time, and a lot more hassle..)

 
 - I assume that unix/linux is pretty much solid since it would likely use the
 current search path and leave it at that.  Is this so?  It may be a moot point,
 but unless you can guarantee that /var, /etc, /lib and /sbin (or any other
 critical system directory) are first on the path, then it has the potential for
 behavior different from its non-unix counterparts.

Actually, Linux doesn't use the same search path for binaries that it 
does for libraries..they are kept separate.

-- 
-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch

Norbert Nemec <Norbert Nemec-online.de> writes:

Paul Bonser wrote:

 Pragma wrote:
 3) providing a standard library loader in Phobos that is more flexible
 than the present solutions for windows and unix/linux (std.loader on
 steroids).
 

 
 I think that this scheme would work very well, not just for D, but for
 anything, really.

That's why I say: the problem should not be solved within the compiler.
Either Microsoft or some third party should come up with a solution that
works for and language. Then DMD could simply use that solution on Windows
and do the regular thing in other environments.

Whatever is done, it should definitely not get in the way on Linux.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Kris" <Kris_member pathlink.com> wrote in message
news:csrksh$mn3$1 digitaldaemon.com...
 In article <csqmfc$2gm9$2 digitaldaemon.com>, Matthew says...
 <snip>
So, Hi! Hope you're all hale and hearty. And fill me in on all the good stuff.

 Hey Matthew; you'll be "not is" surprised to learn that the beloved issues
 surrounding DLLs and the GC are all still present (Sean's excellent work aside)
 .. stepping away from a statically-linked model still transports one back into
 the stone-age.

What is Sean's work? In what ways - I presume more than one <g> - is it
excellent? Where can I see it?

 Question: would D benefit from it's own (binary) link-loader? If the compiler
 were to spit out DDLs (Dynamic D Libraries), and the runtime had the equivalent
 of a linking-class-loader, then the issues regarding multiple GC's would go
away
 (since the GC, and all libraries, would be DDLs instead).

So the rule would be:

    1. If it's a .DLL, then it must only expose strictly C types and semantics.
In other words, if the C-API 
(D-implemented) function returns a pointer to memory, it must also have a
AcmeLib_Resource_Close() or equiv, or it must 
allocate a copy of the 'D' memory object to 'C' before returning.

    2. Alternatively, if it's a .DDL, then we would manage it such that there's
a single per-process GC, and memory 
issues would not occur (at least between D code and other D code).

Is that the kind of thing you mean?

 Such an approach would also presumeably expose D classes correctly, which is
 currently the other major problem regarding D and shared-libraries.

I think that's going to be much harder, and have no current thoughts on how it
might be achieved. Has there been 
much/any debate on this of late?

Cheers

Matthew

John Reimer <brk_6502 yahoo.com> writes:

Matthew wrote:

 
 What is Sean's work? In what ways - I presume more than one <g> - is it
excellent? Where can I see it?
 
 

It's still a work in progress, I believe.

Yet, I think Sean's work is an important move in the D language world. 
It can be found on dsource.org. It's called project "Ares" aka "the 
second coming of Phobos."  It separates the phobos gc from the main 
package and rearranges and reimplements other things (like threading, I 
think).

Have a look at the forum here for a better description:

http://www.dsource.org/forums/viewforum.php?f=31

You can download the current zipped source under the forum heading "Ares 
update."

- John R.

Lars Ivar Igesund <larsivar igesund.net> writes:

Kris wrote:
 In article <csqmfc$2gm9$2 digitaldaemon.com>, Matthew says...
 <snip>
 
So, Hi! Hope you're all hale and hearty. And fill me in on all the good stuff.

 
 
 Hey Matthew; you'll be "not is" surprised to learn that the beloved issues
 surrounding DLLs and the GC are all still present (Sean's excellent work aside)
 .. stepping away from a statically-linked model still transports one back into
 the stone-age.
 
 Question: would D benefit from it's own (binary) link-loader? If the compiler
 were to spit out DDLs (Dynamic D Libraries), and the runtime had the equivalent
 of a linking-class-loader, then the issues regarding multiple GC's would go
away
 (since the GC, and all libraries, would be DDLs instead).
 
 Such an approach would also presumeably expose D classes correctly, which is
 currently the other major problem regarding D and shared-libraries.
 
 Thoughts?
 
 
 
 

Great idea! Although for all those 
'couple-different-languages'-afficionados, both possibilities probably 
should be present. If possible. As I don't use D from other languages, I 
wouldn't mind doing it the described way only.

Lars Ivar Igesund

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:csqmfc$2gm9$2 digitaldaemon.com...
 Since I've been doing some seriously long, and arse-widening, hours, I've

not had time for the most rapidly growing of
 my three favourite languages, so I'm wondering what I've missed. Anyone

care to give me a quick update of how they think
 D has progressed over the last few months? Walter, Kris, Anders, John,

Ben, all the guys (and gals) ...

The focus has been on fixing problems and doing DMDScript.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:css476$19ah$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:csqmfc$2gm9$2 digitaldaemon.com...
 Since I've been doing some seriously long, and arse-widening, hours, I've

 not had time for the most rapidly growing of
 my three favourite languages, so I'm wondering what I've missed. Anyone

 care to give me a quick update of how they think
 D has progressed over the last few months? Walter, Kris, Anders, John,

 Ben, all the guys (and gals) ...

 The focus has been on fixing problems and doing DMDScript.

Sounds like I've not _that_ much to catch up on. ;)

In one sense I'm pleased that the DLL issue's not progressed, since it means
that I have a chance to help with/opine on 
it. On the other hand, it's quite concerning, since it's a show-stopper IMO, at
least as far as getting D past the "very 
useful for writing system apps and small GUIs, but cannot be used for
component-based architectures" stage. I very much 
want to see a *full* solution to the DLL problem, which includes, in my book,
support for the statically linked model 
_as well as_ the dynamically linked model.

So far - albeit I may well have missed much debate - it seems like there's the
Walter camp of "statically linked is 
adequate" and the Kris(& Eric??) camp of "Phobos needs to be dynamically linked
to support all these other 
(<mw>eminently reasonable, even commercially necessary</mw>) scenarios". Well,
I think you're both right in so far as 
what you say, but both wrong in so far as neither of these positions represent
the full truth.

As I've said many times before, D has to support *all* these scenarios,
otherwise it'll never be able to claim to be 
better than C++ or as widely 'usable' as Java/.NET.

But since this ng has, by *far*, the smartest+nicest set of chaps in
Programmia, I fail to see why we should assume we 
cannot cover all bases.

Many wild and whacky ideas are floating round my head at the mo. For example,
on Win32 at least, memory mapped files may 
be executed. If other sharing scenarios do not answer our requirements, we
could maybe even spawn the GC code into a 
shared mmf. But that might require programs / components to be able to describe
the earliest and latest GC's that they 
could work with. Ah, it's a puzzle ... ;)

One issue on which I'm not clear, and for which I'd appreciate input from you
more expert than I to inform on my 
musings: If a statically-linked D exe loaded, via a C-API / interface-based
API, a statically linked (to GC, that is) 
DLL, got some memory from it, and then unloaded it, what would happen? I
presume that it crashes.

Billy-Bob

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:css8m0$1dn7$1 digitaldaemon.com...
 One issue on which I'm not clear, and for which I'd appreciate input from

you more expert than I to inform on my
 musings: If a statically-linked D exe loaded, via a C-API /

interface-based API, a statically linked (to GC, that is)
 DLL, got some memory from it, and then unloaded it, what would happen? I

presume that it crashes.

What if you had two DLLs written in C, both statically linked to their own
malloc/free's. Malloc a pointer in one DLL, pass it to the other, and free
it. You'll crash.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:cssd2a$1ig3$2 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:css8m0$1dn7$1 digitaldaemon.com...
 One issue on which I'm not clear, and for which I'd appreciate input from

 you more expert than I to inform on my
 musings: If a statically-linked D exe loaded, via a C-API /

 interface-based API, a statically linked (to GC, that is)
 DLL, got some memory from it, and then unloaded it, what would happen? I

 presume that it crashes.

 What if you had two DLLs written in C, both statically linked to their own
 malloc/free's. Malloc a pointer in one DLL, pass it to the other, and free
 it. You'll crash.

I'm not talking about malloc(). That's a well-trodden path.

AFAICS, the problem is when D code in different link units exchange 'D' memory.
What happens then? 

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:csse2c$1jk2$2 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

news:cssd2a$1ig3$2 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:css8m0$1dn7$1 digitaldaemon.com...
 One issue on which I'm not clear, and for which I'd appreciate input



from
 you more expert than I to inform on my
 musings: If a statically-linked D exe loaded, via a C-API /

 interface-based API, a statically linked (to GC, that is)
 DLL, got some memory from it, and then unloaded it, what would happen?



I
 presume that it crashes.

 What if you had two DLLs written in C, both statically linked to their


own
 malloc/free's. Malloc a pointer in one DLL, pass it to the other, and


free
 it. You'll crash.

 I'm not talking about malloc(). That's a well-trodden path.

 AFAICS, the problem is when D code in different link units exchange 'D'

memory. What happens then?

I guess I'm trying to point out that C doesn't solve the problem - dealing
with it requires an understanding about how memory allocation works. The
same goes for D. In D, a gc will only recover a pointer *that it can find
the root for* AND *that it has allocated*. All pretty much follows from
these two key points. If you're passing gc allocated memory between DLLs,
you'll need to think about if and where a root for that pointer exists, and
which gc will be looking at that root.

Matthew <Matthew_member pathlink.com> writes:

In article <csuu5g$1uc1$1 digitaldaemon.com>, Walter says...
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:csse2c$1jk2$2 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

news:cssd2a$1ig3$2 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:css8m0$1dn7$1 digitaldaemon.com...
 One issue on which I'm not clear, and for which I'd appreciate input



from
 you more expert than I to inform on my
 musings: If a statically-linked D exe loaded, via a C-API /

 interface-based API, a statically linked (to GC, that is)
 DLL, got some memory from it, and then unloaded it, what would happen?



I
 presume that it crashes.

 What if you had two DLLs written in C, both statically linked to their


own
 malloc/free's. Malloc a pointer in one DLL, pass it to the other, and


free
 it. You'll crash.

 I'm not talking about malloc(). That's a well-trodden path.

 AFAICS, the problem is when D code in different link units exchange 'D'

memory. What happens then?

I guess I'm trying to point out that C doesn't solve the problem - dealing
with it requires an understanding about how memory allocation works. The
same goes for D. In D, a gc will only recover a pointer *that it can find
the root for* AND *that it has allocated*. All pretty much follows from
these two key points. If you're passing gc allocated memory between DLLs,
you'll need to think about if and where a root for that pointer exists, and
which gc will be looking at that root.

My point is that languages/runtime environments such as Java and .NET - *which
use garbage collection* - provide exactly this guarantee. Since GC memory is a
big feature of D, then it's eminently reasonable for users who are attracted to
D for this feature will expect that cross-module memory issues will not exist,
i.e. 'D' memory will be like it is in Java and .NET. 

Conversely, the situation in C and C++ is that one *knows* to be careful with
*all* memory, and so one is. But because we'll be used to GC nonchalence inside
the (D) implementation of our DLLs, it's very likely that will carry over to our
use/implementation of the module boundaries.

In my opinion, this facet of D is a strong disadvantage and, if left as it is,
will cause large-scale dismissal of D as a serious language for anything other
than statically linked (and therefore trivial) applications.

D must provide memory transparency like that of Java/.NET, at least when used
between different D link-units.




The Dr .....

"Walter" <newshound digitalmars.com> writes:

"Matthew" <Matthew_member pathlink.com> wrote in message
news:csv2tk$234l$1 digitaldaemon.com...
 In article <csuu5g$1uc1$1 digitaldaemon.com>, Walter says...
I guess I'm trying to point out that C doesn't solve the problem -


dealing
with it requires an understanding about how memory allocation works. The
same goes for D. In D, a gc will only recover a pointer *that it can find
the root for* AND *that it has allocated*. All pretty much follows from
these two key points. If you're passing gc allocated memory between DLLs,
you'll need to think about if and where a root for that pointer exists,


and
which gc will be looking at that root.

 My point is that languages/runtime environments such as Java and .NET -

*which
 use garbage collection* - provide exactly this guarantee.

I don't know about .net, but if you're hooking DLLs up to Java, you have to
understand how Java's gc works and adapt to it. You cannot ignore the issue.
The "guarantee" is provided by the implementor of the DLL conforming to the
rules of Java's gc, which are non-trivial.

 Since GC memory is a
 big feature of D, then it's eminently reasonable for users who are

attracted to
 D for this feature will expect that cross-module memory issues will not

exist,
 i.e. 'D' memory will be like it is in Java and .NET.

Those cross module memory issues do exist in Java. I've written a Java gc,
and I've written DLLs to hook into Java.

 Conversely, the situation in C and C++ is that one *knows* to be careful

with
 *all* memory, and so one is. But because we'll be used to GC nonchalence

inside
 the (D) implementation of our DLLs, it's very likely that will carry over

to our
 use/implementation of the module boundaries.

 In my opinion, this facet of D is a strong disadvantage and, if left as it

is,
 will cause large-scale dismissal of D as a serious language for anything

other
 than statically linked (and therefore trivial) applications.

 D must provide memory transparency like that of Java/.NET, at least when

used
 between different D link-units.

Perhaps Java has changed in the last few years, but I don't recall Java
behaving that way with DLLs. The Java vm itself doesn't hook up to other
Java code using DLLs. It hooks up to DLLs using the "java native interface"
which has a carefully described protocol on how to handle pointers and
memory allocation - and that interface is a C interface.

It's a lot easier to do a DLL to hook into D than one to hook into Java.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:ct029h$5s8$1 digitaldaemon.com...
 "Matthew" <Matthew_member pathlink.com> wrote in message
 news:csv2tk$234l$1 digitaldaemon.com...
 In article <csuu5g$1uc1$1 digitaldaemon.com>, Walter says...
I guess I'm trying to point out that C doesn't solve the problem -


 dealing
with it requires an understanding about how memory allocation works. The
same goes for D. In D, a gc will only recover a pointer *that it can find
the root for* AND *that it has allocated*. All pretty much follows from
these two key points. If you're passing gc allocated memory between DLLs,
you'll need to think about if and where a root for that pointer exists,


 and
which gc will be looking at that root.

 My point is that languages/runtime environments such as Java and .NET -

 *which
 use garbage collection* - provide exactly this guarantee.

 I don't know about .net, but if you're hooking DLLs up to Java, you have to
 understand how Java's gc works and adapt to it. You cannot ignore the issue.
 The "guarantee" is provided by the implementor of the DLL conforming to the
 rules of Java's gc, which are non-trivial.

 Since GC memory is a
 big feature of D, then it's eminently reasonable for users who are

 attracted to
 D for this feature will expect that cross-module memory issues will not

 exist,
 i.e. 'D' memory will be like it is in Java and .NET.

 Those cross module memory issues do exist in Java. I've written a Java gc,
 and I've written DLLs to hook into Java.

 Conversely, the situation in C and C++ is that one *knows* to be careful

 with
 *all* memory, and so one is. But because we'll be used to GC nonchalence

 inside
 the (D) implementation of our DLLs, it's very likely that will carry over

 to our
 use/implementation of the module boundaries.

 In my opinion, this facet of D is a strong disadvantage and, if left as it

 is,
 will cause large-scale dismissal of D as a serious language for anything

 other
 than statically linked (and therefore trivial) applications.

 D must provide memory transparency like that of Java/.NET, at least when

 used
 between different D link-units.

 Perhaps Java has changed in the last few years, but I don't recall Java
 behaving that way with DLLs. The Java vm itself doesn't hook up to other
 Java code using DLLs. It hooks up to DLLs using the "java native interface"
 which has a carefully described protocol on how to handle pointers and
 memory allocation - and that interface is a C interface.


Come on. Clearly I'm not talking about Windows .DLL DLLs. I'm talking about
dynamically loaded executable objects, 
which, for D will likely be in Windows .DLLs and UNIX .sos.

In Java, such a thing is a jar and/or class file. Are you telling me that I
cannot pass objects created in one class 
file to another? Do all classes in Java communicate only by fundamental types?
I don't think so.

In .NET, such a thing is an assembly. Are you telling me that I cannot pass
objects created in one assembly to another? 
Do all classes in .NET communicate only by fundamental types? I'm pretty sure
they do not.

 It's a lot easier to do a DLL to hook into D than one to hook into Java.

That's just not true (since I wasn't talking about JNI/native DLLs). And it
worries me that you think it's reasonable to 
say so. Do you really not care to engage the massive (and, with modernity,
growing) sub-set of software 
development/engineers that need to do this kind of engineering? I cannot fathom
the attitude.

Norbert Nemec <Norbert Nemec-online.de> writes:

Matthew wrote:
 Come on. Clearly I'm not talking about Windows .DLL DLLs. I'm talking
 about dynamically loaded executable objects, which, for D will likely be
 in Windows .DLLs and UNIX .sos.
 
 In Java, such a thing is a jar and/or class file. Are you telling me that
 I cannot pass objects created in one class file to another? Do all classes
 in Java communicate only by fundamental types? I don't think so.
 
 In .NET, such a thing is an assembly. Are you telling me that I cannot
 pass objects created in one assembly to another? Do all classes in .NET
 communicate only by fundamental types? I'm pretty sure they do not.
 
 It's a lot easier to do a DLL to hook into D than one to hook into Java.

 
 That's just not true (since I wasn't talking about JNI/native DLLs). And
 it worries me that you think it's reasonable to say so. Do you really not
 care to engage the massive (and, with modernity, growing) sub-set of
 software development/engineers that need to do this kind of engineering? I
 cannot fathom the attitude.

Now, are you talking about mixing languages in dynamically linked libraries
or about staying within one language?

In the first case, the problem is mostly language independent: linking D
code with C code and passing around objects gives you about the same kind
of troubles as linking a native library into a Java program or vice versa.

Mixing a bunch of Java libraries is unproblematic, as is mixing various D
libraries (as long as you don't explicitely fiddle with the memory
allocation by replacing the allocator in one of the libraries.)

(Of course, with Java, you can also use other languages targeting the same
virtual machine, but that would be similar of using the D libraries for
memory management of foreign code.)

In any case, I still don't see where the problem is intrinsically linked
with the issue of dynamic libraries. Statically linked libraries collide in
the same manner when they use different mechanisms for memory management.

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:css8m0$1dn7$1 digitaldaemon.com...
 In one sense I'm pleased that the DLL issue's not progressed, since it

means that I have a chance to help with/opine on
 it. On the other hand, it's quite concerning, since it's a show-stopper

IMO, at least as far as getting D past the "very
 useful for writing system apps and small GUIs, but cannot be used for

component-based architectures" stage.

But it *can* be used for component based architectures! That's exactly what
the COM support does. That's exactly what the interfaces do. There are even
sample COM server DLL's in \dmd\samples\d\

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:cssdl8$1j47$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:css8m0$1dn7$1 digitaldaemon.com...
 In one sense I'm pleased that the DLL issue's not progressed, since it

 means that I have a chance to help with/opine on
 it. On the other hand, it's quite concerning, since it's a show-stopper

 IMO, at least as far as getting D past the "very
 useful for writing system apps and small GUIs, but cannot be used for

 component-based architectures" stage.

 But it *can* be used for component based architectures! That's exactly what
 the COM support does. That's exactly what the interfaces do. There are even
 sample COM server DLL's in \dmd\samples\d\

Ok, so I misspoke. I should have said

    [D will be] "very useful for writing system apps and small GUIs, but cannot
be used for component-based 
architectures [that exchange information via D code]"

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:csse2e$1jk2$3 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

news:cssdl8$1j47$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:css8m0$1dn7$1 digitaldaemon.com...
 In one sense I'm pleased that the DLL issue's not progressed, since it

 means that I have a chance to help with/opine on
 it. On the other hand, it's quite concerning, since it's a show-stopper

 IMO, at least as far as getting D past the "very
 useful for writing system apps and small GUIs, but cannot be used for

 component-based architectures" stage.

 But it *can* be used for component based architectures! That's exactly


what
 the COM support does. That's exactly what the interfaces do. There are


even
 sample COM server DLL's in \dmd\samples\d\

 Ok, so I misspoke. I should have said

     [D will be] "very useful for writing system apps and small GUIs, but

cannot be used for component-based
 architectures [that exchange information via D code]"

But COM and interfaces are directly supported by D code! Seriously, I don't
understand what the issue is. If the issue is "can I totally forget about
memory management across DLL boundaries", then you'll be disappointed. (But
I know of no language that allows you to create DLLs and not have such
concerns, certainly not C or C++.)

I think with a bit of care in designing the DLL API, this should not be a
big problem. And why not use COM or interfaces as your DLL API? It's a
proven, workable, cross-language solution. D interfaces are *ideal* for
component based architectures!

John Demme <me teqdruid.com> writes:

Walter wrote:
 
 But COM and interfaces are directly supported by D code! Seriously, I don't
 understand what the issue is. If the issue is "can I totally forget about
 memory management across DLL boundaries", then you'll be disappointed. (But
 I know of no language that allows you to create DLLs and not have such
 concerns, certainly not C or C++.)

Java.  (Yeah, I know, it's not DLLs, but shared libraries all the same). 
  When programming in Java, 99.9% of the time I never have to worry 
about memory management.  I'm not familiar with how DLLs work (or 
Linux's shared objects) but I don't think I've heard anyone here say 
that MM issues aren't in C or C++ DLLs.

The difference is that in C or C++ MM is an issue with *everything*. 
I've been programming with D for about a year now, and I haven't yet had 
to worry about MM.  Maybe I don't understand the issues, but I don't see 
why I should have to worry about MM when I want to use a shared library. 
  I've come to expect the D GC to *just work* now that I've been using it.

On a related note, can someone point me to some material about this 
subject.  I've held off commenting until now due to my nearly complete 
lack of knowledge on the subject.  I'd like to remedy this problem.

-John-

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:csuuoc$1uti$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:csse2e$1jk2$3 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

 news:cssdl8$1j47$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:css8m0$1dn7$1 digitaldaemon.com...
 In one sense I'm pleased that the DLL issue's not progressed, since it

 means that I have a chance to help with/opine on
 it. On the other hand, it's quite concerning, since it's a show-stopper

 IMO, at least as far as getting D past the "very
 useful for writing system apps and small GUIs, but cannot be used for

 component-based architectures" stage.

 But it *can* be used for component based architectures! That's exactly


 what
 the COM support does. That's exactly what the interfaces do. There are


 even
 sample COM server DLL's in \dmd\samples\d\

 Ok, so I misspoke. I should have said

     [D will be] "very useful for writing system apps and small GUIs, but

 cannot be used for component-based
 architectures [that exchange information via D code]"

 But COM and interfaces are directly supported by D code! Seriously, I don't
 understand what the issue is.

With respect, I suspect you are going to feel like that because (i) you don't
(AFAICT) do component-based programming, 
and (ii) you don't (any more) use other languages, such as Java and .NET ...

 If the issue is "can I totally forget about
 memory management across DLL boundaries", then you'll be disappointed. (But
 I know of no language that allows you to create DLLs and not have such
 concerns, certainly not C or C++.)

...  in which you most certainly can "forget about memory management across DLL
boundaries". C and C++ are far from a 
representative spread on this issue; also, as I mention in the other thread,
one is used, nay primed, to expect explicit 
mem mgmt in C and C++, and not so in D.

 I think with a bit of care in designing the DLL API, this should not be a
 big problem. And why not use COM or interfaces as your DLL API? It's a
 proven, workable, cross-language solution. D interfaces are *ideal* for
 component based architectures!

All of these things I can do far more easily in C and C++. (Note: this is so
because extensive libs exist for C/C++, 
which may change, and because programming in C/C++ inclines one to think about
the pertinent cross-link unit issues and 
programming in D does not, which will not change.) Why, then would, I use D?

John Reimer <brk_6502 yahoo.com> writes:

On Fri, 21 Jan 2005 21:46:11 +1100, Matthew wrote:

 As some may have noticed, and a few may have been pleased, I've been largely
away from D for the last few months. I've 
 been working on a large infrastructure project for a client, which has
involved a lot of networking (ACE) and middleware 
 (TibCo EMS), and some GUI / logging (so C++ aficionados may expect to see more
sub-projects in STLSoft in the next few 
 months).
 
 Since I've been doing some seriously long, and arse-widening, hours, I've not
had time for the most rapidly growing of 
 my three favourite languages, so I'm wondering what I've missed. Anyone care
to give me a quick update of how they think 
 D has progressed over the last few months? Walter, Kris, Anders, John, Ben,
all the guys (and gals) ...

Unfortunately, Matthew, when you say "John", it could be one of 3 or 4
people here now.

I'll flatter myself and pretend that you meant me. :-) Of course, it
wouldn't hurt if all of us just responded in turn, I guess.

Anyway, welcome back!

Some things going on from my perspective:

1) Dsource.org is growing quickly thanks to Brad's dedication and hard
work.  I hear improvements are in the works.

2) Mango still remains one of the best, most comprehensive examples of a D
programming library thanks to Kris.  He's added an ICU interface to the
the package that works on both Windows and Linux.

3) Walter seems to have stopped adding features to dmd, instead
concentrating on lots of bug fixes (pheww!)

4) Many new projects have been started: work on Ares seems to be one to
keep an eye on.

5) A more comprehensive dmake tool has been discussed periodically, mostly
based off the original by Helmet.  A couple of dmake derivatives have made
some interesting additions to automate the build of whole projects and
libraries using version() and pragma directives within the d source code.

6) Ant seems to be dutifully continuing his work with DUI; Windows and
Linux versions seem to be improving.  Ant has put a fair bit of effort
into simplifying the Windows installation.  Windows OpenGL now works in
DUI. 

7) DWT is still stagnating, although signs of life appear now and again as
new dmd versions fix certain bugs. I'm still interested in seeing this one
succeed eventually.

8) There are quite a few more new people getting involved in D from what I
can tell.

9) The Japanese D community continues to release some very fancy examples
of what D can do in the computer game field.

10) Gdc continues to get better thanks to David.  Linux and Mac builds
are no longer a rarity.  

That said, D still suffers from a few annoying problems that keep some
development processes from advancing.  But I think you are already in the
thick of discovering those details from this newsgroup.

So, welcome back :-)

- John R.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"John Reimer" <brk_6502 yahoo.com> wrote in message
news:pan.2005.01.22.17.35.31.210363 yahoo.com...
 On Fri, 21 Jan 2005 21:46:11 +1100, Matthew wrote:

 As some may have noticed, and a few may have been pleased, I've been largely
away from D for the last few months. 
 I've
 been working on a large infrastructure project for a client, which has
involved a lot of networking (ACE) and 
 middleware
 (TibCo EMS), and some GUI / logging (so C++ aficionados may expect to see more
sub-projects in STLSoft in the next 
 few
 months).

 Since I've been doing some seriously long, and arse-widening, hours, I've not
had time for the most rapidly growing 
 of
 my three favourite languages, so I'm wondering what I've missed. Anyone care
to give me a quick update of how they 
 think
 D has progressed over the last few months? Walter, Kris, Anders, John, Ben,
all the guys (and gals) ...

 Unfortunately, Matthew, when you say "John", it could be one of 3 or 4
 people here now.

I meant you, mi auld mucker

 I'll flatter myself and pretend that you meant me. :-) Of course, it
 wouldn't hurt if all of us just responded in turn, I guess.

 Anyway, welcome back!

 Some things going on from my perspective:

 1) Dsource.org is growing quickly thanks to Brad's dedication and hard
 work.  I hear improvements are in the works.

Nice

 2) Mango still remains one of the best, most comprehensive examples of a D
 programming library thanks to Kris.  He's added an ICU interface to the
 the package that works on both Windows and Linux.

Nice.

 3) Walter seems to have stopped adding features to dmd, instead
 concentrating on lots of bug fixes (pheww!)

Good. He he

 4-10) >

All good stuff.

 So, welcome back :-)

Thanks. I hope I can get back to my intended contributions - 100% D Open-RJ/D,
DTL, some COM D libs - now that life's 
going to be more mine than my clients' again. :-)

The Dr .....