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. :-)

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:csqmfc$2gm9$2@digitaldaemon.com...
> As some may have noticed, and a few may have been pleased, I've been
largely away from D for the last few months. I've
> been working on a large infrastructure project for a client, which has
involved a lot of networking (ACE) and middleware
> (TibCo EMS), and some GUI / logging (so C++ aficionados may expect to see
more sub-projects in STLSoft in the next few
> months).
>
> Since I've been doing some seriously long, and arse-widening, hours, I've
not had time for the most rapidly growing of
> my three favourite languages, so I'm wondering what I've missed. Anyone
care to give me a quick update of how they think
> D has progressed over the last few months? Walter, Kris, Anders, John,
Ben, all the guys (and gals) ...
>
>
> FYI, I expect to be largely free of my current duties in the next few
weeks, and am planning to get back into D with a
> vengeance next month. Walter and I will also be starting the real work on
our D book, and are hoping (probably
> deludedly) to have that finished by mid-year. As part of the research for
that book, and to get me back on stride, I
> will be getting back into recls/D, Open-RJ/D, the D exception stuff that I
promised last year (unless that's already
> been sorted), and, of course, DTL, for which latter I have had some good
ideas of late.
>
> So, Hi! Hope you're all hale and hearty. And fill me in on all the good
stuff.
>
> Cheers, and well (re-)met
>
> Matthew
>
> P.S. "Imperfect C++"'s dropped out of the top 20 C++ books on Amazon now,
so if you've been hanging fire, now'd be the
> time to pry out those coppers. :-)

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

-Ben

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?

"Kris" <Kris_member@pathlink.com> wrote in message news:csrksh$mn3$1@digitaldaemon.com...
> In article <csqmfc$2gm9$2@digitaldaemon.com>, Matthew says... <snip>
> >So, Hi! Hope you're all hale and hearty. And fill me in on all the good
stuff.
>
> Hey Matthew; you'll be "not is" surprised to learn that the beloved issues surrounding DLLs and the GC are all still present (Sean's excellent work
aside)
> .. stepping away from a statically-linked model still transports one back
into
> the stone-age.
>
> Question: would D benefit from it's own (binary) link-loader? If the
compiler
> were to spit out DDLs (Dynamic D Libraries), and the runtime had the
equivalent
> of a linking-class-loader, then the issues regarding multiple GC's would
go away
> (since the GC, and all libraries, would be DDLs instead).
>
> Such an approach would also presumeably expose D classes correctly, which
is
> currently the other major problem regarding D and shared-libraries.
>
> Thoughts?

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

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

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:csqmfc$2gm9$2@digitaldaemon.com...
> Since I've been doing some seriously long, and arse-widening, hours, I've
not had time for the most rapidly growing of
> my three favourite languages, so I'm wondering what I've missed. Anyone
care to give me a quick update of how they think
> D has progressed over the last few months? Walter, Kris, Anders, John,
Ben, all the guys (and gals) ...

The focus has been on fixing problems and doing DMDScript.

Walter <newshound@digitalmars.com> schrieb:
>
> "Kris" <Kris_member@pathlink.com> wrote in message news:csrksh$mn3$1@digitaldaemon.com...
> >
> > Question: would D benefit from it's own (binary) link-loader? If the
> > compiler were to spit out DDLs (Dynamic D Libraries), and the runtime
> > had the equivalent of a linking-class-loader, then the issues regarding
> > multiple GC's would go away
> > (since the GC, and all libraries, would be DDLs instead).
> >
> > Such an approach would also presumeably expose D classes correctly, which is currently the other major problem regarding D and shared-libraries.
> >
> > Thoughts?
>
> The idea of using a single gc across multiple DLLs just doesn't sit well with me. I prefer to make DLLs that are, as far as allocation goes, independent of each other. To that end, the API a D DLL should expose should be C style functions, COM interfaces, or D interfaces. The first two choices have the nice feature that just about any decent language will have some level of access to that DLL.
>
> In particular I am not fond of the idea of making Phobos into a DLL. The problem, as we all eventually run into, is DLL hell. Suppose you buy one D app from vendor A, and another from vendor B. They each ship a different phobos.dll. Which one do you use? Ak. Now, if you say keep A's phobos.dll on an island with A's app, why not just statically link it in? (It's not like there's a shortage of disk space!)

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

Thomas

"Walter" <newshound@digitalmars.com> wrote in message news:css476$19ah$1@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:csqmfc$2gm9$2@digitaldaemon.com...
>> Since I've been doing some seriously long, and arse-widening, hours, I've
> not had time for the most rapidly growing of
>> my three favourite languages, so I'm wondering what I've missed. Anyone
> care to give me a quick update of how they think
>> D has progressed over the last few months? Walter, Kris, Anders, John,
> Ben, all the guys (and gals) ...
>
> The focus has been on fixing problems and doing DMDScript.

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

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

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

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

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

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

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

Billy-Bob

"Walter" <newshound@digitalmars.com> wrote in message news:css3k9$18ou$1@digitaldaemon.com...
>
> "Kris" <Kris_member@pathlink.com> wrote in message news:csrksh$mn3$1@digitaldaemon.com...
>> In article <csqmfc$2gm9$2@digitaldaemon.com>, Matthew says... <snip>
>> >So, Hi! Hope you're all hale and hearty. And fill me in on all the good
> stuff.
>>
>> Hey Matthew; you'll be "not is" surprised to learn that the beloved issues surrounding DLLs and the GC are all still present (Sean's excellent work
> aside)
>> .. stepping away from a statically-linked model still transports one back
> into
>> the stone-age.
>>
>> Question: would D benefit from it's own (binary) link-loader? If the
> compiler
>> were to spit out DDLs (Dynamic D Libraries), and the runtime had the
> equivalent
>> of a linking-class-loader, then the issues regarding multiple GC's would
> go away
>> (since the GC, and all libraries, would be DDLs instead).
>>
>> Such an approach would also presumeably expose D classes correctly, which
> is
>> currently the other major problem regarding D and shared-libraries.
>>
>> Thoughts?
>
> The idea of using a single gc across multiple DLLs just doesn't sit well with me. I prefer to make DLLs that are, as far as allocation goes, independent of each other. To that end, the API a D DLL should expose should be C style functions, COM interfaces, or D interfaces. The first two choices have the nice feature that just about any decent language will have some level of access to that DLL.
>
> In particular I am not fond of the idea of making Phobos into a DLL. The problem, as we all eventually run into, is DLL hell. Suppose you buy one D app from vendor A, and another from vendor B. They each ship a different phobos.dll. Which one do you use? Ak. Now, if you say keep A's phobos.dll on an island with A's app, why not just statically link it in? (It's not like there's a shortage of disk space!)

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

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

"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

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:csr5em$3bu$1@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:csqmfc$2gm9$2@digitaldaemon.com...
>> As some may have noticed, and a few may have been pleased, I've been
> largely away from D for the last few months. I've
>> been working on a large infrastructure project for a client, which has
> involved a lot of networking (ACE) and middleware
>> (TibCo EMS), and some GUI / logging (so C++ aficionados may expect to see
> more sub-projects in STLSoft in the next few
>> months).
>>
>> Since I've been doing some seriously long, and arse-widening, hours, I've
> not had time for the most rapidly growing of
>> my three favourite languages, so I'm wondering what I've missed. Anyone
> care to give me a quick update of how they think
>> D has progressed over the last few months? Walter, Kris, Anders, John,
> Ben, all the guys (and gals) ...
>>
>>
>> FYI, I expect to be largely free of my current duties in the next few
> weeks, and am planning to get back into D with a
>> vengeance next month. Walter and I will also be starting the real work on
> our D book, and are hoping (probably
>> deludedly) to have that finished by mid-year. As part of the research for
> that book, and to get me back on stride, I
>> will be getting back into recls/D, Open-RJ/D, the D exception stuff that I
> promised last year (unless that's already
>> been sorted), and, of course, DTL, for which latter I have had some good
> ideas of late.
>>
>> So, Hi! Hope you're all hale and hearty. And fill me in on all the good
> stuff.
>>
>> Cheers, and well (re-)met
>>
>> Matthew
>>
>> P.S. "Imperfect C++"'s dropped out of the top 20 C++ books on Amazon now,
> so if you've been hanging fire, now'd be the
>> time to pry out those coppers. :-)
>
> Welcome back! I don't remember exactly what state D was in a few months ago but there has just been bug fixes and then these last few days I'm sure you've seen the DMDScript posts. For my own D stuff I'm currently trying to convince Walter of a serious bug in toStringz

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

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

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