www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What have I missed?

reply "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. :-)
Jan 21 2005
next sibling parent reply "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

 been working on a large infrastructure project for a client, which has

 (TibCo EMS), and some GUI / logging (so C++ aficionados may expect to see

 months).

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

 my three favourite languages, so I'm wondering what I've missed. Anyone

 D has progressed over the last few months? Walter, Kris, Anders, John,

 FYI, I expect to be largely free of my current duties in the next few

 vengeance next month. Walter and I will also be starting the real work on

 deludedly) to have that finished by mid-year. As part of the research for

 will be getting back into recls/D, Open-RJ/D, the D exception stuff that I

 been sorted), and, of course, DTL, for which latter I have had some good

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

 Cheers, and well (re-)met

 Matthew

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

 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
Jan 21 2005
parent "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

 been working on a large infrastructure project for a client, which has

 (TibCo EMS), and some GUI / logging (so C++ aficionados may expect to see

 months).

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

 my three favourite languages, so I'm wondering what I've missed. Anyone

 D has progressed over the last few months? Walter, Kris, Anders, John,

 FYI, I expect to be largely free of my current duties in the next few

 vengeance next month. Walter and I will also be starting the real work on

 deludedly) to have that finished by mid-year. As part of the research for

 will be getting back into recls/D, Open-RJ/D, the D exception stuff that I

 been sorted), and, of course, DTL, for which latter I have had some good

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

 Cheers, and well (re-)met

 Matthew

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

 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. :-)
Jan 21 2005
prev sibling next sibling parent reply 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?
Jan 21 2005
next sibling parent reply "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


 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

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

 the stone-age.

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

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

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

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

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

 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!)
Jan 21 2005
next sibling parent reply "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
Jan 21 2005
parent "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

 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

 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.
Jan 21 2005
prev sibling next sibling parent reply "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


 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

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

 the stone-age.

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

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

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

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

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

 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.
Jan 21 2005
parent reply "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

 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


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


 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


 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


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


 there's a shortage of disk space!)

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

 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?
Jan 21 2005
next sibling parent reply "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

 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


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


 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


 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


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


 there's a shortage of disk space!)

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

 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.
Jan 21 2005
next sibling parent 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

 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


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


 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


 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


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


 there's a shortage of disk space!)

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

 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.
Jan 22 2005
prev sibling parent "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?

 understand this, but it seems pretty clear that if GCs are link

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.
Jan 23 2005
prev sibling parent reply 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

 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


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


 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


 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


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


 there's a shortage of disk space!)

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

 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
Jan 21 2005
next sibling parent "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

 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


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


 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


 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


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


 there's a shortage of disk space!)

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

 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.
Jan 21 2005
prev sibling parent reply "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

 Factory Pattern" ?

 Surely the obvious problem is this, Walter:

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

 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

 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,

 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

 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.
Jan 23 2005
parent 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

 Factory Pattern" ?

 Surely the obvious problem is this, Walter:

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

 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

 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
Jan 24 2005
prev sibling parent reply 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


 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

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

 the stone-age.

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

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

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

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

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

 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? :-)
Jan 21 2005
parent reply "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


 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

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

 the stone-age.

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

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

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

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

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

 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.
Jan 21 2005
next sibling parent reply "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

 without an effective and elegant (i.e. totally ignorable to 98% of users)

 no doubt. Hence, I agree with Kris that Walter needs to consider this to

 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.
Jan 23 2005
next sibling parent 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.

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;
Jan 23 2005
prev sibling parent reply 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...
Jan 23 2005
parent reply 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...

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 my primary language (not everyone has come to D from the C/C++/Java/C# .net 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!"
Jan 23 2005
parent 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...

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
 the C/C++/Java/C# .net 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.

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. :-(
Jan 23 2005
prev sibling parent reply 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.
Jan 23 2005
parent reply 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.

Jan 23 2005
parent reply 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.
Jan 23 2005
parent reply 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). This is critical since a Phobos library hook for folding in point #2 is the most 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
Jan 24 2005
next sibling parent 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
Jan 24 2005
prev sibling next sibling parent reply 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.
Jan 24 2005
parent 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
Jan 24 2005
prev sibling parent reply 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
Jan 24 2005
parent 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.
Jan 25 2005
prev sibling next sibling parent reply "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
Jan 21 2005
parent 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.
Jan 21 2005
prev sibling parent 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
Jan 22 2005
prev sibling next sibling parent reply "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

 my three favourite languages, so I'm wondering what I've missed. Anyone

 D has progressed over the last few months? Walter, Kris, Anders, John,

The focus has been on fixing problems and doing DMDScript.
Jan 21 2005
parent reply "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

 my three favourite languages, so I'm wondering what I've missed. Anyone

 D has progressed over the last few months? Walter, Kris, Anders, John,

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
Jan 21 2005
next sibling parent reply "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

 musings: If a statically-linked D exe loaded, via a C-API /

 DLL, got some memory from it, and then unloaded it, what would happen? I

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.
Jan 21 2005
parent reply "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

 musings: If a statically-linked D exe loaded, via a C-API /

 DLL, got some memory from it, and then unloaded it, what would happen? I

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?
Jan 21 2005
parent reply "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

 "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



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

 DLL, got some memory from it, and then unloaded it, what would happen?



 presume that it crashes.

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


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


 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'

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.
Jan 22 2005
parent reply 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

 "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



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

 DLL, got some memory from it, and then unloaded it, what would happen?



 presume that it crashes.

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


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


 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'

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 .....
Jan 22 2005
parent reply "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 -


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,


which gc will be looking at that root.

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

 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

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

 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

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

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

 use/implementation of the module boundaries.

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

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

 than statically linked (and therefore trivial) applications.

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

 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.
Jan 23 2005
parent reply "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 -


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,


which gc will be looking at that root.

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

 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

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

 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

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

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

 use/implementation of the module boundaries.

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

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

 than statically linked (and therefore trivial) applications.

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

 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.
Jan 23 2005
parent 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.
Jan 23 2005
prev sibling parent reply "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

 it. On the other hand, it's quite concerning, since it's a show-stopper

 useful for writing system apps and small GUIs, but cannot be used for

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\
Jan 21 2005
parent reply "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

 it. On the other hand, it's quite concerning, since it's a show-stopper

 useful for writing system apps and small GUIs, but cannot be used for

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]"
Jan 21 2005
parent reply "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

 "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

 it. On the other hand, it's quite concerning, since it's a show-stopper

 useful for writing system apps and small GUIs, but cannot be used for

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


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


 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

 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!
Jan 22 2005
next sibling parent 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-
Jan 22 2005
prev sibling parent "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

 "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

 it. On the other hand, it's quite concerning, since it's a show-stopper

 useful for writing system apps and small GUIs, but cannot be used for

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


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


 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

 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?
Jan 23 2005
prev sibling parent reply 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.
Jan 22 2005
parent "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 .....
Jan 26 2005