"Kris" <Kris_member@pathlink.com> wrote in message news:csse93$1jq1$1@digitaldaemon.com...
> In article <cssd2a$1ig3$1@digitaldaemon.com>, Walter says...
>>
>>
>>"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8vr$1e0b$1@digitaldaemon.com...
>>>
>>> "Walter" <newshound@digitalmars.com> wrote in message
>>news:css3k9$18ou$1@digitaldaemon.com...
>>> > The idea of using a single gc across multiple DLLs just doesn't sit well with me. I prefer to make DLLs that are, as far as allocation goes, independent of each other. To that end, the API a D DLL should expose
>>should
>>> > be C style functions, COM interfaces, or D interfaces. The first two
>>choices
>>> > have the nice feature that just about any decent language will have some level of access to that DLL.
>>> >
>>> > In particular I am not fond of the idea of making Phobos into a DLL. The problem, as we all eventually run into, is DLL hell. Suppose you buy one
>>D
>>> > app from vendor A, and another from vendor B. They each ship a different phobos.dll. Which one do you use? Ak. Now, if you say keep A's
>>phobos.dll on
>>> > an island with A's app, why not just statically link it in? (It's not
>>like
>>> > there's a shortage of disk space!)
>>>
>>> It's certainly true that that's unpleasant, but if the alternative is that
>>one cannot talk "D" across link-units, then
>>> D's going to be pretty still born.
>>
>>You can - I just argue that that would be a poor design of a DLL.
>>
>>> I believe we can concoct a better solution. Just not sure what ... yet.
>>
>>Why not use D interfaces?
>
> It would be great to use interfaces. I presume you mean "in conjunction with a Factory Pattern" ?
>
> Surely the obvious problem is this, Walter:
>
> 1) the factory (within the DLL) would create the implementing class, and hand it
> back to the caller
> 2) the caller now hangs onto the returned interface handle
> 3) the DLL GC thinks there are no more references to the constructed class, and
> reaps it
> 4) the other GC (from the caller) may try to reap the interface handle, which
> does not belong within its pools

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

> There are many more, non-trivial, examples.
>
> Since we're talking about the factory pattern, one might consider adding a version number as an argument? So the client could specify some kind of expected version? Perhaps not ideal, but it might address some of your concerns?

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

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.

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

> 
> "Walter" <newshound@digitalmars.com> wrote in message news:cssd2a$1ig3$1@digitaldaemon.com...
>>
>> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8vr$1e0b$1@digitaldaemon.com...
>>>
>>> "Walter" <newshound@digitalmars.com> wrote in message
>> news:css3k9$18ou$1@digitaldaemon.com...
>>> > The idea of using a single gc across multiple DLLs just doesn't sit well with me. I prefer to make DLLs that are, as far as allocation goes, independent of each other. To that end, the API a D DLL should expose
>> should
>>> > be C style functions, COM interfaces, or D interfaces. The first two
>> choices
>>> > have the nice feature that just about any decent language will have some level of access to that DLL.
>>> >
>>> > In particular I am not fond of the idea of making Phobos into a DLL. The problem, as we all eventually run into, is DLL hell. Suppose you buy one
>> D
>>> > app from vendor A, and another from vendor B. They each ship a different phobos.dll. Which one do you use? Ak. Now, if you say keep A's
>> phobos.dll on
>>> > an island with A's app, why not just statically link it in? (It's not
>> like
>>> > there's a shortage of disk space!)
>>>
>>> It's certainly true that that's unpleasant, but if the alternative is that
>> one cannot talk "D" across link-units, then
>>> D's going to be pretty still born.
>>
>> You can - I just argue that that would be a poor design of a DLL.
>>
>>> I believe we can concoct a better solution. Just not sure what ... yet.
>>
>> Why not use D interfaces?
> 
> But how do we manage the memory that may be exchanged between link units? Which GC owns it? I confess I little understand this, but it seems pretty clear that if GCs are link unit-specific, then there're going to be problems.


Make the GC part of the OS? :-)

(forgive me that wasn't very constructive).

- John R.

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

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

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

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

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

Anyway, welcome back!

Some things going on from my perspective:

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

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

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

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

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

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

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

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

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

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

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

So, welcome back :-)

- John R.

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:csse2c$1jk2$2@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message
news:cssd2a$1ig3$2@digitaldaemon.com...
> >
> > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8m0$1dn7$1@digitaldaemon.com...
> >> One issue on which I'm not clear, and for which I'd appreciate input
from
> > you more expert than I to inform on my
> >> musings: If a statically-linked D exe loaded, via a C-API /
> > interface-based API, a statically linked (to GC, that is)
> >> DLL, got some memory from it, and then unloaded it, what would happen?
I
> > presume that it crashes.
> >
> > What if you had two DLLs written in C, both statically linked to their
own
> > malloc/free's. Malloc a pointer in one DLL, pass it to the other, and
free
> > it. You'll crash.
>
> I'm not talking about malloc(). That's a well-trodden path.
>
> AFAICS, the problem is when D code in different link units exchange 'D'
memory. What happens then?

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

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:csse2e$1jk2$3@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message
news:cssdl8$1j47$1@digitaldaemon.com...
> >
> > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8m0$1dn7$1@digitaldaemon.com...
> >> In one sense I'm pleased that the DLL issue's not progressed, since it
> > means that I have a chance to help with/opine on
> >> it. On the other hand, it's quite concerning, since it's a show-stopper
> > IMO, at least as far as getting D past the "very
> >> useful for writing system apps and small GUIs, but cannot be used for
> > component-based architectures" stage.
> >
> > But it *can* be used for component based architectures! That's exactly
what
> > the COM support does. That's exactly what the interfaces do. There are
even
> > sample COM server DLL's in \dmd\samples\d\
>
> Ok, so I misspoke. I should have said
>
>     [D will be] "very useful for writing system apps and small GUIs, but
cannot be used for component-based
> architectures [that exchange information via D code]"

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

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

In article <csuu5g$1uc1$1@digitaldaemon.com>, Walter says...
>
>
>"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:csse2c$1jk2$2@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message
>news:cssd2a$1ig3$2@digitaldaemon.com...
>> >
>> > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8m0$1dn7$1@digitaldaemon.com...
>> >> One issue on which I'm not clear, and for which I'd appreciate input
>from
>> > you more expert than I to inform on my
>> >> musings: If a statically-linked D exe loaded, via a C-API /
>> > interface-based API, a statically linked (to GC, that is)
>> >> DLL, got some memory from it, and then unloaded it, what would happen?
>I
>> > presume that it crashes.
>> >
>> > What if you had two DLLs written in C, both statically linked to their
>own
>> > malloc/free's. Malloc a pointer in one DLL, pass it to the other, and
>free
>> > it. You'll crash.
>>
>> I'm not talking about malloc(). That's a well-trodden path.
>>
>> AFAICS, the problem is when D code in different link units exchange 'D'
>memory. What happens then?
>
>I guess I'm trying to point out that C doesn't solve the problem - dealing with it requires an understanding about how memory allocation works. The same goes for D. In D, a gc will only recover a pointer *that it can find the root for* AND *that it has allocated*. All pretty much follows from these two key points. If you're passing gc allocated memory between DLLs, you'll need to think about if and where a root for that pointer exists, and which gc will be looking at that root.

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

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

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

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




The Dr .....

Walter 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-

"Walter" <newshound@digitalmars.com> wrote in message news:csuuoc$1uti$1@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:csse2e$1jk2$3@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message
> news:cssdl8$1j47$1@digitaldaemon.com...
>> >
>> > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8m0$1dn7$1@digitaldaemon.com...
>> >> In one sense I'm pleased that the DLL issue's not progressed, since it
>> > means that I have a chance to help with/opine on
>> >> it. On the other hand, it's quite concerning, since it's a show-stopper
>> > IMO, at least as far as getting D past the "very
>> >> useful for writing system apps and small GUIs, but cannot be used for
>> > component-based architectures" stage.
>> >
>> > But it *can* be used for component based architectures! That's exactly
> what
>> > the COM support does. That's exactly what the interfaces do. There are
> even
>> > sample COM server DLL's in \dmd\samples\d\
>>
>> Ok, so I misspoke. I should have said
>>
>>     [D will be] "very useful for writing system apps and small GUIs, but
> cannot be used for component-based
>> architectures [that exchange information via D code]"
>
> But COM and interfaces are directly supported by D code! Seriously, I don't understand what the issue is.

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

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

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

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

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