www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - On "Standard" Libraries

reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
Here we go...

I'm an experienced C/C++ programmer and am very close to refusing to program 
C++ (does this happen to all C++ programmers at some point?), which is why 
I'm looking at alternatives. Obviously, D is the best candidate (for me) at 
the moment.

What disturbs me is the fact that every new language introduces a new 
'standard' library. And it's mostly the success of the standard library that 
determines the language's faith. It's one thing to learn a new syntax, but 
with each new language we also have to learn a new library. This wastes a 
lot of time, probably more than learning the language itself. Why is there 
no single, cross-language standard library? .NET?

In this respect, I think Microsoft's got it right with their .NET framework: 
whatever language you use, there's only one 'standard library'. Python's 
library (the default modules) is also very extensive and I'm convinced it's 
one of the reasons for that language's success: whatever you want to make, 
most work has probably been done already in some module or other.

And then there's D with Phobos. Of course, D has all rights to have its own 
library, in its own structure, framework, hierarchy. Similar to other 
languages, Phobos should be the key to D's success. But it gets confusing. 
Phobos has some problems and lacks functionality. Great, problems can be 
fixed and functionality can be added. But I've noticed that there are two 
more 'standard libraries': Ares and Mango. (Perhaps Mango's not really a 
standard library, but just count the number of times people need something 
and it happens to be in Mango; shouldn't it be standard?)

"Great! Freedom of choice! Through competition, the alternatives will 
evolve: the consumer wins!"
Either that, or it will split the 'consumers', and we'll have 'outages' 
before you know it.

I'm really confused. How much of D is actually Phobos? Are the things I 
don't like in D actually shortcomings in Phobos? Wouldn't D be better with 
Ares, or Mango included, or merged? Yes, they can be downloaded and added, 
but don't underestimate the power of 'out-of-the-box'. Would Python have 
succeeded without all those modules? "Just go to python.org and get what you 
need!" Would you, really?

Which brings me back to a post of mine some time ago. At that time I 
suggested to port Phobos 'back' to C++. Ridiculous? Stay with me.

Porting Phobos to C++ would not only make it a cross-language library, but 
also familiarize people with the library's layout and help acceptance of D: 
imagine knowing a C++ Phobos and only afterwards getting to know D. Having a 
C++ Phobos would also be a first conversion step for existing C++ projects 
towards D. By the time DMD reaches 1.0, a C++ project using Phobos would be 
ported to D in no time. Having a larger user base would also help 
standardize and stablize Phobos, another benifit to the D community. But 
perhaps keeping two implementations of the same library is undoable.

I like D, but I'm reluctant to invest time in getting to know Phobos. I 

to spend time getting familiar with the .NET framework.

Language... Library... Language.. Library.. Why can't I have both? Like that 
guy that liked Python, but also liked the .NET framework. He ended up 
writing his own MSIL language (Boo) based on python. I definately don't want 
to write another language! Couldn't if I wanted to.

My point? Something must be done about D's standard library. A repository 
would be a good start. That's a plus for Ares and Mango. And the treshold 
should be lowered. This can be achieved by either porting the D standard 
library to other languages, or by adopting the structure of another common 
library.

My suggestions:
* merge Phobos, Ares and Mango into one helluva standard library
* adopt either the .NET framework or the python modules structure

Of course, D's standard library must remain in native code. I'm only 
suggesting adopting another library's structure.

Do react.

L.
Nov 22 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Lionello Lunesu wrote:

 
 I'm really confused. How much of D is actually Phobos? Are the things I 
 don't like in D actually shortcomings in Phobos? Wouldn't D be better with 
 Ares, or Mango included, or merged? Yes, they can be downloaded and added, 
 but don't underestimate the power of 'out-of-the-box'. Would Python have 
 succeeded without all those modules? "Just go to python.org and get what you 
 need!" Would you, really?


A lot of D is in Phobos, in the 'internal' area.  Ares includes all this 
as well, but rearranged into dmdrt (runtime) and dmdgc (garbage 
collector) sub-libraries.  Beyond that Ares contains little more than 
what is needed to build and run a D application, most of which is also 
present in  Phobos, so there would be little reason to include Ares in 
Phobos... excepting perhaps std.atomic.

I'll reply to the rest later.  I'm running late and need to get out of 
the house :-)


Sean
Nov 22 2005
parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
 A lot of D is in Phobos, in the 'internal' area.  Ares includes all this 
 as well, but rearranged into dmdrt (runtime) and dmdgc (garbage collector) 
 sub-libraries.  Beyond that Ares contains little more than what is needed 
 to build and run a D application, most of which is also present in 
 Phobos, so there would be little reason to include Ares in Phobos... 
 excepting perhaps std.atomic.


Seperating the core D stuff from the rest is a good start. And 'atomic' 
sounds like something that I'd put in a standard library (D has 
'synchronized', so something like 'atomic makes sense). By the way, how is 
'synchronized' done? Is it also done by the library?

L.
Nov 22 2005
parent reply Sean Kelly <sean f4.ca> writes:
Lionello Lunesu wrote:

 
 Seperating the core D stuff from the rest is a good start. And 'atomic' 
 sounds like something that I'd put in a standard library (D has 
 'synchronized', so something like 'atomic makes sense). By the way, how is 
 'synchronized' done? Is it also done by the library?


As with a bunch of other built-in functionality, the DMD compiler 
generates code for this that calls extern (C) functions and such in the 
'internal' portion of Phobos--if you do a search for the Windows 
critical section calls you'll find  the code in question.  I don't 
really consider this to be a part of the standard library though so much 
as compiler runtime code, which is why I split it out into a completely 
different library in Ares.  It is my hope that even if Ares never really 
makes it, the three library structure it uses will be applied to Phobos.


Sean
Nov 23 2005
parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:dm29c5$1fhs$1 digitaldaemon.com...

 It is my hope that even if Ares never really makes it, the three library 
 structure it uses will be applied to Phobos.


Let's hope so. Thanks for the explanation.

L.
Nov 24 2005
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
If you have time enough to learn D, then you should have time enough to 
learn phobos. ( http://www.digitalmars.com/d/phobos/phobos.html ) Phobos 
is really simple. Merging phobos, ares, and mango would not make phobos 
any easier to learn.

I can't imagine C++ developers would want to use Phobos as their 
standard library, since they already have their own + STL + boost, and 
they most likely don't want to be forced to use the garbage collector.

I don't think the D community has the resources to create a cross 
platform version of the .NET libraries anyway. Same for python.
Nov 22 2005
parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
"clayasaurus" <clayasaurus gmail.com> wrote in message 
news:dlvkg7$2a4k$1 digitaldaemon.com...

 If you have time enough to learn D, then you should have time enough to 
 learn phobos. ( http://www.digitalmars.com/d/phobos/phobos.html ) Phobos 
 is really simple. Merging phobos, ares, and mango would not make phobos 
 any easier to learn.


Learning D is all about learning Phobos, that's my point. The language is 
just too easy : ) The problems start then you notice something missing in 
Phobos and start looking at other libs, and you find out that also Ares and 
Mango have file-IO. And then there's also the CRT, yet another way of doing 
things.


 I can't imagine C++ developers would want to use Phobos as their standard 
 library, since they already have their own + STL + boost, and they most 
 likely don't want to be forced to use the garbage collector.


I'm a c++ developer and I don't use STL / Boost (which leaves "own" :-). And 
nobody's forcing anybody. I would love to get familiar with Phobos and 
garbage collection in my current C++ projects. Surely I'm not alone?


 I don't think the D community has the resources to create a cross platform 
 version of the .NET libraries anyway. Same for python.


I disagree. The only thing you'd have to do is use a similar module/class 
structure. It's not even needed to implement the complete .NET framework 
(the "compact .NET framework"?) to get started. It's just so people don't 
have to look to far to know how to go about doing something.

In my original post I forgot to mention the fact that in D+Phobos there are 
in fact many ways of doing the same thing. You can even use the ol' CRT, or 
worse mix CRT / Phobos. In fact, some parts of Phobos appear to be using 
CRT. The CRT is the first lib I'd through out of the window. It's nice to 
have it somewhere, in case you want to port an existing project.

L.
Nov 22 2005
prev sibling next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
 My point? Something must be done about D's standard library. A repository 
 would be a good start. That's a plus for Ares and Mango. And the treshold 
 should be lowered. This can be achieved by either porting the D standard 
 library to other languages, or by adopting the structure of another common 
 library.

 My suggestions:
 * merge Phobos, Ares and Mango into one helluva standard library
 * adopt either the .NET framework or the python modules structure


I think it's universally acknowledged that Phobos must change and grow. Even 
though it's still in beta, D is very usuable, while its library lets it down 
(I've found myself preferring to reinvent the wheel rather than try to cope 
with its bugs and shortcomings).

What should constitute a standard library? It is perhaps worth considering 
other standard libraries. J2SE/J2EE and the .NET framework (and to some 
extent Delphi's VCL) cover a vast swathe of ground, from base types to 
collections, from I/O to HTTP, from XML processing to databases, from 
graphics to windowing. But the C++ standard library restricts itself more or 
less to containers and memory. Ruby and Python seem to fall somewhere 
between the two camps. Where should Phobos draw the line?

Looking at Boost - it began as a repository and over time evolved into a 
comprehensive library, parts of which are to be brought into a future C++ 
standard. I think copying Boost's model would prove too slow if the aim is 
to improve Phobos now. However, Walter, single-handedly, won't be able to 
build a library the size and scale of others mentioned above.

So as I see it, the solution is for the community to club together and build 
its own ideal standard library, and if it ends up remaining unofficial, so 
be it - D users would at least have a single, deep, compendious library to 
code against. What would the cons be of taking this path (design by 
committee isn't always a curse)?

As for basing your library on other language's libraries, there'd be 
numerous pitfalls you'd need to avoid. Do you slavishly clone every aspect? 
What about differences in behaviour? Users would probably expect it to 
function the same as the API they're accustomed to (I think we've seen some 
of this already with DWT and DFL). And so on. But such an approach could 
provide a good, solid springboard.

In this day and age, I reckon a practical, valuable standard library should 
include, on top of what Phobos provides, modules that cover character 
encoding (and conversions), globalisation (calendars, cultures), 
Internet/HTTP (with asynchronous I/O), databases (SQL etc), and XML 
(stream-based readers and writers, a DOM implementation, schemas, XSLT, 
XPath).

One consideration - what's the consensus on distributing shared binaries 
with a library? Certainly this would speed things up, like the writing of 
the XML packages, which could sit atop libxml2 (and in fact I have already 
done this).

John.
Nov 22 2005
next sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
I think it's universally acknowledged that Phobos must change and grow. Even

 though it's still in beta, D is very usuable, while its library lets it 
 down (I've found myself preferring to reinvent the wheel rather than try 
 to cope with its bugs and shortcomings).


That can't be right. Who wants to do that? If the solution to problems in 
Phobos is 'to reinvent the wheel' it's clear that there's something wrong 
somewhere.


 What should constitute a standard library? It is perhaps worth considering 
 other standard libraries. J2SE/J2EE and the .NET framework (and to some 
 extent Delphi's VCL) cover a vast swathe of ground, from base types to 
 collections, from I/O to HTTP, from XML processing to databases, from 
 graphics to windowing. But the C++ standard library restricts itself more 
 or less to containers and memory. Ruby and Python seem to fall somewhere 
 between the two camps. Where should Phobos draw the line?


Defining this would indeed be a good start. But also the other functionality 
(not in Phobos) should be given direction.


 Walter, single-handedly, won't be able to build a library the size and 
 scale of others mentioned above.


Of course. My concern is that Phobos stays as is and that 'other 
functionality' will only be available in 'third party' libraries, scattered 
among multiple, overlapping libraries. Your linked exe ends up having 4 
different 'open file' functions.


 So as I see it, the solution is for the community to club together and 
 build its own ideal standard library, and if it ends up remaining 
 unofficial, so be it - D users would at least have a single, deep, 
 compendious library to code against. What would the cons be of taking this 
 path (design by committee isn't always a curse)?


I think that's perfect! And whiule designing this new library, why not adopt 
an existing library's structure? Should also save some time since you don't 
spend much time thinking about the API, classes, interfaces.


 As for basing your library on other language's libraries, there'd be 
 numerous pitfalls you'd need to avoid. Do you slavishly clone every 
 aspect?


I think the positive aspects of slavishly cloning the structure outweigh the 
negative. Familiarity for many people is a greater benefit (to them, and 
therefor to the language) than being able to optimize special cases.


 What about differences in behaviour? Users would probably expect it to 
 function the same as the API they're accustomed to (I think we've seen 
 some of this already with DWT and DFL). And so on. But such an approach 
 could provide a good, solid springboard.


By adopting an existing API you obviously adopt its behaviour. The behaviour 
of the function is in fact more important than it's name or the module it's 
in. Thinking about it, I think it's the behaviour of functions that takes 
the longest to learn. Does it throw? Does it accept null? What if....?
As for DWT, DFL: they should both have adopted WTL or Windows Forms, or VCL 
or something :-)


 In this day and age, I reckon a practical, valuable standard library 
 should include, on top of what Phobos provides, modules that cover 
 character encoding (and conversions), globalisation (calendars, cultures), 
 Internet/HTTP (with asynchronous I/O), databases (SQL etc), and XML 
 (stream-based readers and writers, a DOM implementation, schemas, XSLT, 
 XPath).


I agree. Seems Phobos has a long way to go.


 One consideration - what's the consensus on distributing shared binaries 
 with a library? Certainly this would speed things up, like the writing of 
 the XML packages, which could sit atop libxml2 (and in fact I have already 
 done this).


I don't know what the consensus is but I wouldn't mind ; )  It surely beats 
the rewriting the whole lib in D.

L.
Nov 22 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Lionello Lunesu" <lio remove.lunesu.com> wrote in message 
news:dm161c$q45$1 digitaldaemon.com...

I think it's universally acknowledged that Phobos must change and grow. 
Even

 though it's still in beta, D is very usuable, while its library lets it 
 down (I've found myself preferring to reinvent the wheel rather than try 
 to cope with its bugs and shortcomings).


 That can't be right. Who wants to do that? If the solution to problems in 
 Phobos is 'to reinvent the wheel' it's clear that there's something wrong 
 somewhere.


 What should constitute a standard library? It is perhaps worth 
 considering other standard libraries. J2SE/J2EE and the .NET framework 
 (and to some extent Delphi's VCL) cover a vast swathe of ground, from 
 base types to collections, from I/O to HTTP, from XML processing to 
 databases, from graphics to windowing. But the C++ standard library 
 restricts itself more or less to containers and memory. Ruby and Python 
 seem to fall somewhere between the two camps. Where should Phobos draw 
 the line?


 Defining this would indeed be a good start. But also the other 
 functionality (not in Phobos) should be given direction.


 Walter, single-handedly, won't be able to build a library the size and 
 scale of others mentioned above.


 Of course. My concern is that Phobos stays as is and that 'other 
 functionality' will only be available in 'third party' libraries, 
 scattered among multiple, overlapping libraries. Your linked exe ends up 
 having 4 different 'open file' functions.


 So as I see it, the solution is for the community to club together and 
 build its own ideal standard library, and if it ends up remaining 
 unofficial, so be it - D users would at least have a single, deep, 
 compendious library to code against. What would the cons be of taking 
 this path (design by committee isn't always a curse)?


 I think that's perfect! And whiule designing this new library, why not 
 adopt an existing library's structure? Should also save some time since 
 you don't spend much time thinking about the API, classes, interfaces.


 As for basing your library on other language's libraries, there'd be 
 numerous pitfalls you'd need to avoid. Do you slavishly clone every 
 aspect?


 I think the positive aspects of slavishly cloning the structure outweigh 
 the negative. Familiarity for many people is a greater benefit (to them, 
 and therefor to the language) than being able to optimize special cases.


Still not sure about that. This assumes the API you copy is the best way of 
doing something. I like the structure of the .NET BCL and there's a lot it 
gets right, but is it appropriate for D?


 What about differences in behaviour? Users would probably expect it to 
 function the same as the API they're accustomed to (I think we've seen 
 some of this already with DWT and DFL). And so on. But such an approach 
 could provide a good, solid springboard.


 By adopting an existing API you obviously adopt its behaviour. The 
 behaviour of the function is in fact more important than it's name or the 
 module it's in. Thinking about it, I think it's the behaviour of functions 
 that takes the longest to learn. Does it throw? Does it accept null? What 
 if....?
 As for DWT, DFL: they should both have adopted WTL or Windows Forms, or 
 VCL or something :-)


 In this day and age, I reckon a practical, valuable standard library 
 should include, on top of what Phobos provides, modules that cover 
 character encoding (and conversions), globalisation (calendars, 
 cultures), Internet/HTTP (with asynchronous I/O), databases (SQL etc), 
 and XML (stream-based readers and writers, a DOM implementation, schemas, 
 XSLT, XPath).


 I agree. Seems Phobos has a long way to go.


 One consideration - what's the consensus on distributing shared binaries 
 with a library? Certainly this would speed things up, like the writing of 
 the XML packages, which could sit atop libxml2 (and in fact I have 
 already done this).


 I don't know what the consensus is but I wouldn't mind ; )  It surely 
 beats the rewriting the whole lib in D.


Of course, rewriting existing libraries in D isn't the only way to go about 
it, and wouldn't be optimal - you end up copying those libraries' bugs and 
inefficiencies. You could start from scratch, as Mango did with its XML 
modules.


 L.


There might be an opportunity here to start over, to re-think string 
handling (see the recent threads), add missing functionality, fill language 
gaps (array helpers like indexOf/lastIndexOf, insert/remove; a hashtable 
that works with interfaces), and so on.
Nov 23 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
 As for DWT, DFL: they should both have adopted WTL or Windows
 Forms, or VCL or something :-)




...


 Of course, rewriting existing libraries in D isn't the only way to go
 about it, and wouldn't be optimal - you end up copying those
 libraries' bugs and inefficiencies. You could start from scratch, as
 Mango did with its XML modules.


I see like three different tacks.

1) We create good os-independent libraries.

2) We write adapters for existing platform specific libraries.

3) Phobos gets some more help from us.

I don't see these as mutually exclusive.

---

As to how we'd get more bang for the brain-cell hours we have, the idea 
of a repository sounds good to me. The repository could be a place for 
anything from small single functions that do one thing well, up to 
largish packages for an application area.

We might decide that anything that gets uploaded into the repository, is 
implicitly there for any Real Library Developer (think Mango, Ares, 
Phobos, DWT, whatever), to incorporate into their libraries, as they see 
fit. And for others just to use in their D code as such.
Nov 23 2005
prev sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message 
news:dlvl2i$2al4$1 digitaldaemon.com...

 What should constitute a standard library? It is perhaps worth considering 
 other standard libraries. J2SE/J2EE and the .NET framework (and to some 
 extent Delphi's VCL) [...]


I just now realized how great Delphi's VCL framework was at the time. I was 
mixing Delphi and C++ with their C++ Builder in a single project, and it 
worked just great. I guess it was the .NET of its time. Where did they go 
wrong?

L.
Nov 25 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Lionello Lunesu wrote:

 "John C" <johnch_atms hotmail.com> wrote in message 
 news:dlvl2i$2al4$1 digitaldaemon.com...
 

 What should constitute a standard library? It is perhaps worth
 considering other standard libraries. J2SE/J2EE and the .NET
 framework (and to some extent Delphi's VCL) [...]


 
 
 I just now realized how great Delphi's VCL framework was at the time.
 I was mixing Delphi and C++ with their C++ Builder in a single
 project, and it worked just great. I guess it was the .NET of its
 time. Where did they go wrong?


IIRC, they had their first major change of leadership at the time. Which 
also resulted in certain dithering, and identity crisis. (Inprise.)
Nov 25 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Lionello Lunesu wrote:

 
 I like D, but I'm reluctant to invest time in getting to know Phobos. I 

 to spend time getting familiar with the .NET framework.


It's important to learn to use the tools you plan to use to complete 
your particular project.  If you're writing D code, that may be some or 
all of Phobos, or it may be none of it.  Same goes for the .NET library.


 Language... Library... Language.. Library.. Why can't I have both? Like that 
 guy that liked Python, but also liked the .NET framework. He ended up 
 writing his own MSIL language (Boo) based on python. I definately don't want 
 to write another language! Couldn't if I wanted to.


Someone was working on an MSIL compiler for D.  The project was doing 
pretty well the last time I heard about it, too, though it's been a 
while since then.


 My point? Something must be done about D's standard library. A repository 
 would be a good start. That's a plus for Ares and Mango. And the treshold 
 should be lowered. This can be achieved by either porting the D standard 
 library to other languages, or by adopting the structure of another common 
 library.


Ares was created to serve a twofold purpose: first, some folks were 
unhappy with the overall "feel" of Phobos for one reason or another and 
wanted to try and address those issues, and second, response from Walter 
regarding library submissions has been a bit too slow on occasion for 
the rabid newsgroup posse, and it seemed like a community-driven effort 
might be more accessible.  That said, I'm not particularly interested in 
seeing Phobos, Ares, or Mango ported to another language, largely 
because I'm using D because I prefer it to those other languages.  In a 
world full of procedural languages, the reasons to choose one over 
another typically come down to tool support or style preference.


 My suggestions:
 * merge Phobos, Ares and Mango into one helluva standard library
 * adopt either the .NET framework or the python modules structure
 
 Of course, D's standard library must remain in native code. I'm only 
 suggesting adopting another library's structure.


All of the libraries you've mentioned are still evolving.  If there's 
something you like or don't like about one of them, by all means post 
feedback.  And if you're interested in porting another library to D, 
feel free to do so.  The greatest barrier to progress is a lack of free 
time ;-)


Sean
Nov 22 2005
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Sean Kelly wrote:

 Someone was working on an MSIL compiler for D.  The project was doing 
 pretty well the last time I heard about it, too, though it's been a 
 while since then.
 


Deja Augustine was doing a great job with that, but unfortunatelly he 
doesn't seem to be working on it any more.

Although having a MSIL D compiler would be great. I am often forsed to 
program in .NET and it would be wonderfull to be able to do that in my 
favourite language.
Nov 22 2005
next sibling parent reply Chris <ctlajoie yahoo.com> writes:
On Tue, 22 Nov 2005 22:21:40 +0100, Ivan Senji
<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:


Deja Augustine was doing a great job with that, but unfortunatelly he 
doesn't seem to be working on it any more.

Although having a MSIL D compiler would be great. I am often forsed to 
program in .NET and it would be wonderfull to be able to do that in my 
favourite language.


I requested (quite politely of course) that Deja Augustine release the
source to the D community so we could continue to develop it.
Unfortunately I never heard back from him.

I know a thing or two about MSIL but I lack the experience to write a
full parser and compiler. I could not start a project such as this,
but I could definitely improve on existing code if it were available.

Chris
Nov 22 2005
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Chris wrote:

 I requested (quite politely of course) that Deja Augustine release the
 source to the D community so we could continue to develop it.
 Unfortunately I never heard back from him.
 


That is really a shame.


 I know a thing or two about MSIL but I lack the experience to write a
 full parser and compiler. I could not start a project such as this,
 but I could definitely improve on existing code if it were available.


If you ever get that code you can count on me to help you improve it.
:)


 
 Chris
Nov 23 2005
prev sibling parent reply J C Calvarese <technocrat7 gmail.com> writes:
In article <l7c7o1pobdcq54mjevlncu0qtc0gavq11k 4ax.com>, Chris says...

On Tue, 22 Nov 2005 22:21:40 +0100, Ivan Senji
<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:


Deja Augustine was doing a great job with that, but unfortunatelly he 
doesn't seem to be working on it any more.

Although having a MSIL D compiler would be great. I am often forsed to 
program in .NET and it would be wonderfull to be able to do that in my 
favourite language.


I requested (quite politely of course) that Deja Augustine release the
source to the D community so we could continue to develop it.
Unfortunately I never heard back from him.


I contacted him a while back, and he told me that he lost the source for D.NET.
He seemed to be interested in rewriting it (he thought a rewrite would've been a
good idea even if he hadn't lost the original source code). As far as I know, he
hasn't worked any more on it though. See
http://www.prowiki.org/wiki4d/wiki.cgi?DDotNet for more info about D.NET.

I'm sure I still have a copy of a D.NET compiler around somewhere if someone
wants to try disassembling and/or reverse engineering it. ;)

jcc7
Nov 23 2005
parent Chris <ctlajoie yahoo.com> writes:
On Wed, 23 Nov 2005 15:47:55 +0000 (UTC), J C Calvarese
<technocrat7 gmail.com> wrote:


In article <l7c7o1pobdcq54mjevlncu0qtc0gavq11k 4ax.com>, Chris says...



I requested (quite politely of course) that Deja Augustine release the
source to the D community so we could continue to develop it.
Unfortunately I never heard back from him.


I contacted him a while back, and he told me that he lost the source for D.NET.
He seemed to be interested in rewriting it (he thought a rewrite would've been a
good idea even if he hadn't lost the original source code). As far as I know, he
hasn't worked any more on it though. See
http://www.prowiki.org/wiki4d/wiki.cgi?DDotNet for more info about D.NET.

I'm sure I still have a copy of a D.NET compiler around somewhere if someone
wants to try disassembling and/or reverse engineering it. ;)

jcc7


If you email me the compiler I can decompile it with Reflector
(http://www.aisto.com/roeder/dotnet/). I might need to get the old
beta 2.0 framework again though. Unfortunately it's completely
incompatible with the current 2.0 framework. I'd have to uninstall my
framework and reinstall the old one, just to decompile it. 
No big deal I guess. please send it to ctlajoie at gmail if you find
it.

Chris
Nov 24 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Ivan Senji wrote:

 Sean Kelly wrote:
 

 Someone was working on an MSIL compiler for D.  The project was doing 
 pretty well the last time I heard about it, too, though it's been a 
 while since then.


 
 Deja Augustine was doing a great job with that, but unfortunatelly he 
 doesn't seem to be working on it any more.
 
 Although having a MSIL D compiler would be great. I am often forsed to 
 program in .NET and it would be wonderfull to be able to do that in my 
 favourite language.


Hmm. I kinda hate the thought of compiling D to MSIL.

Is there a theoretical reason for not having the D program as a native 
.exe and it using an interface library so it can use all of the .NET APIs?
Nov 23 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:43849FFC.2080503 nospam.org...

 Ivan Senji wrote:

 Sean Kelly wrote:


 Someone was working on an MSIL compiler for D.  The project was doing 
 pretty well the last time I heard about it, too, though it's been a 
 while since then.


 Deja Augustine was doing a great job with that, but unfortunatelly he 
 doesn't seem to be working on it any more.

 Although having a MSIL D compiler would be great. I am often forsed to 
 program in .NET and it would be wonderfull to be able to do that in my 
 favourite language.


 Hmm. I kinda hate the thought of compiling D to MSIL.

 Is there a theoretical reason for not having the D program as a native 
 .exe and it using an interface library so it can use all of the .NET APIs?


You can host the runtime via COM, but it's barely documented and like 
squeezing water from a stone.
Nov 23 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
John C wrote:

 "Georg Wrede" <georg.wrede nospam.org> wrote
 
 You can host the runtime via COM, but it's barely documented and like 
 squeezing water from a stone. 


LOL, how true. And brittle, IMHO.

Yes, I really could use a library (be it C or D) that I just link with, 
and then get to use .NET APIs.

But I guess writing such a library would be a huge project for anyone?
Nov 24 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:4385B76C.8060809 nospam.org...

 John C wrote:

 "Georg Wrede" <georg.wrede nospam.org> wrote

 You can host the runtime via COM, but it's barely documented and like 
 squeezing water from a stone.


 LOL, how true. And brittle, IMHO.

 Yes, I really could use a library (be it C or D) that I just link with, 
 and then get to use .NET APIs.

 But I guess writing such a library would be a huge project for anyone?


Fairly huge, yes, and it wouldn't be pretty. And apart from the actual 
interfaces that host the CLR, most of the API isn't exposed. For example, 
the COM representation of the String class has no methods. Here it is:

    interface _String : IDispatch {}

That's it. You have to call IDispatch.GetIDsOfNames(...) and 
IDispatch.Invoke(...) to do anything useful.

Only COM experts and sadists need apply.
Nov 24 2005
parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
I got from  http://staff.develop.com/jasonw/clr/readme.htm :



struct __declspec(uuid("6a33391c-fe7d-36e6-83b6-8b926ab94dc2"))

_String : IDispatch

{

//

// Raw methods provided by interface

//

virtual HRESULT __stdcall get_ToString (

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall Equals (

VARIANT obj,

VARIANT_BOOL * pRetVal ) = 0;

virtual HRESULT __stdcall GetHashCode (

long * pRetVal ) = 0;

virtual HRESULT __stdcall GetType (

struct _Type * * pRetVal ) = 0;

virtual HRESULT __stdcall CompareTo (

VARIANT Value,

long * pRetVal ) = 0;

virtual HRESULT __stdcall Clone (

VARIANT * pRetVal ) = 0;

virtual HRESULT __stdcall GetTypeCode (

enum TypeCode * pRetVal ) = 0;

virtual HRESULT __stdcall ToBoolean (

VARIANT_BOOL * pRetVal ) = 0;

virtual HRESULT __stdcall ToChar (

unsigned short * pRetVal ) = 0;

virtual HRESULT __stdcall ToSByte (

char * pRetVal ) = 0;

virtual HRESULT __stdcall ToByte (

unsigned char * pRetVal ) = 0;

virtual HRESULT __stdcall ToInt16 (

short * pRetVal ) = 0;

virtual HRESULT __stdcall ToUInt16 (

unsigned short * pRetVal ) = 0;

virtual HRESULT __stdcall ToInt32 (

long * pRetVal ) = 0;

virtual HRESULT __stdcall ToUInt32 (

unsigned long * pRetVal ) = 0;

virtual HRESULT __stdcall ToInt64 (

__int64 * pRetVal ) = 0;

virtual HRESULT __stdcall ToUInt64 (

unsigned __int64 * pRetVal ) = 0;

virtual HRESULT __stdcall ToSingle (

float * pRetVal ) = 0;

virtual HRESULT __stdcall ToDouble (

double * pRetVal ) = 0;

virtual HRESULT __stdcall ToDecimal (

DECIMAL * pRetVal ) = 0;

virtual HRESULT __stdcall ToDateTime (

DATE * pRetVal ) = 0;

virtual HRESULT __stdcall ToType (

struct _Type * type,

VARIANT * pRetVal ) = 0;

virtual HRESULT __stdcall Equals_2 (

BSTR Value,

VARIANT_BOOL * pRetVal ) = 0;

virtual HRESULT __stdcall get_chars (

long index,

unsigned short * pRetVal ) = 0;

virtual HRESULT __stdcall CopyTo (

long sourceIndex,

SAFEARRAY * destination,

long destinationIndex,

long Count ) = 0;

virtual HRESULT __stdcall ToCharArray (

SAFEARRAY * * pRetVal ) = 0;

virtual HRESULT __stdcall ToCharArray_2 (

long startIndex,

long Length,

SAFEARRAY * * pRetVal ) = 0;

virtual HRESULT __stdcall get_Length (

long * pRetVal ) = 0;

virtual HRESULT __stdcall Split (

SAFEARRAY * separator,

SAFEARRAY * * pRetVal ) = 0;

virtual HRESULT __stdcall Split_2 (

SAFEARRAY * separator,

long Count,

SAFEARRAY * * pRetVal ) = 0;

virtual HRESULT __stdcall Substring (

long startIndex,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall Substring_2 (

long startIndex,

long Length,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall Trim (

SAFEARRAY * trimChars,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall TrimStart (

SAFEARRAY * trimChars,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall TrimEnd (

SAFEARRAY * trimChars,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall CompareTo_2 (

BSTR strB,

long * pRetVal ) = 0;

virtual HRESULT __stdcall EndsWith (

BSTR Value,

VARIANT_BOOL * pRetVal ) = 0;

virtual HRESULT __stdcall IndexOf (

unsigned short Value,

long * pRetVal ) = 0;

virtual HRESULT __stdcall IndexOf_2 (

unsigned short Value,

long startIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall IndexOf_3 (

unsigned short Value,

long startIndex,

long endIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall IndexOf_4 (

SAFEARRAY * Value,

long * pRetVal ) = 0;

virtual HRESULT __stdcall IndexOf_5 (

SAFEARRAY * Value,

long startIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall IndexOf_6 (

SAFEARRAY * Value,

long startIndex,

long endIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall IndexOf_7 (

BSTR Value,

long * pRetVal ) = 0;

virtual HRESULT __stdcall IndexOf_8 (

BSTR Value,

long startIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall IndexOf_9 (

BSTR Value,

long startIndex,

long endIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall LastIndexOf (

unsigned short Value,

long * pRetVal ) = 0;

virtual HRESULT __stdcall LastIndexOf_2 (

unsigned short Value,

long startIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall LastIndexOf_3 (

unsigned short Value,

long startIndex,

long endIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall LastIndexOf_4 (

SAFEARRAY * Value,

long * pRetVal ) = 0;

virtual HRESULT __stdcall LastIndexOf_5 (

SAFEARRAY * Value,

long startIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall LastIndexOf_6 (

SAFEARRAY * Value,

long startIndex,

long endIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall LastIndexOf_7 (

BSTR Value,

long * pRetVal ) = 0;

virtual HRESULT __stdcall LastIndexOf_8 (

BSTR Value,

long startIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall LastIndexOf_9 (

BSTR Value,

long startIndex,

long endIndex,

long * pRetVal ) = 0;

virtual HRESULT __stdcall PadLeft (

long totalWidth,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall PadLeft_2 (

long totalWidth,

unsigned short paddingChar,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall PadRight (

long totalWidth,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall PadRight_2 (

long totalWidth,

unsigned short paddingChar,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall StartsWith (

BSTR Value,

VARIANT_BOOL * pRetVal ) = 0;

virtual HRESULT __stdcall ToLower (

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall ToLower_2 (

struct _CultureInfo * culture,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall ToUpper (

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall ToUpper_2 (

struct _CultureInfo * culture,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall Trim_2 (

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall Insert (

long startIndex,

BSTR Value,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall Replace (

unsigned short oldChar,

unsigned short newChar,

BSTR * pRetVal ) = 0;

virtual HRESULT __stdcall Remove (

long startIndex,

long Count,

BSTR * pRetVal ) = 0;

};
Nov 24 2005
next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Lionello Lunesu" <lio remove.lunesu.com> wrote in message 
news:dm4ggf$bk4$1 digitaldaemon.com...

I got from  http://staff.develop.com/jasonw/clr/readme.htm :


<snip>

Thanks for that. If only I knew it existed when I was tinkering with this 
stuff last year. I wonder why OleView omits those methods.
Nov 24 2005
parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
John (or anyone),

Am I mistaken, or can we use code similar to that .net moniker to interface 
D with .NET natively?

Seems we have to define all those interface (=converting the mscorlib.h) and 
we need some factory to obtain those interfaces from. We'd define the 
interfaces in D modules similar to the .NET namespaces. Then we need some 
classes for the exotic CLI types, like variant, bstr. But it seems very 
doable??

L.
Nov 24 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Lionello Lunesu" <lio remove.lunesu.com> wrote in message 
news:dm4m3h$hnc$1 digitaldaemon.com...

 John (or anyone),

 Am I mistaken, or can we use code similar to that .net moniker to 
 interface D with .NET natively?


No, you're not mistaken.


 Seems we have to define all those interface (=converting the mscorlib.h) 
 and we need some factory to obtain those interfaces from. We'd define the 
 interfaces in D modules similar to the .NET namespaces. Then we need some 
 classes for the exotic CLI types, like variant, bstr. But it seems very 
 doable??

 L.


Indeed, it's very doable. To get started, you'll need a more complete COM 
module than that included in phobos (it doesn't define IDispatch or VARIANT; 
note that bstr is just an alias for "wchar_t*"). You use coclasses to create 
instances of those interfaces.

I'll post a complete example tomorrow. Although Mr Wrede might have beaten 
me to it by then.
Nov 24 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
John C wrote:

 "Lionello Lunesu" <lio remove.lunesu.com> wrote
 I'll post a complete example tomorrow. 
 Although Mr Wrede might have beaten me to it by then. 


<Blush!> Thanks for the compliment, but I'm way too old to get 
_anything_ done in a day!  .-)
Nov 24 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Lionello Lunesu wrote:

 I got from  http://staff.develop.com/jasonw/clr/readme.htm :
 
 struct __declspec(uuid("6a33391c-fe7d-36e6-83b6-8b926ab94dc2"))
 
 _String : IDispatch
 
 {


(snip)

Gee, thanks!
Nov 24 2005
prev sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
 Someone was working on an MSIL compiler for D.  The project was doing 
 pretty well the last time I heard about it, too, though it's been a while 
 since then.


DNet, yeah, I saw it. It allowed you to use the .NET framework, which is 
great, but too bad the exe is not native code in that case. Indeed, is it 
even possible to use .NET from a native code application? I'll have to try 
this VS2005.


 Ares was created to serve a twofold purpose: first, some folks were 
 unhappy with the overall "feel" of Phobos for one reason or another and 
 wanted to try and address those issues, and second, response from Walter 
 regarding library submissions has been a bit too slow on occasion for the 
 rabid newsgroup posse, and it seemed like a community-driven effort might 
 be more accessible.


Walter already has a compiler to take care of, can imagine he's busy : )


 That said, I'm not particularly interested in seeing Phobos, Ares, or 
 Mango ported to another language, largely because I'm using D because I 
 prefer it to those other languages.  In a world full of procedural 
 languages, the reasons to choose one over another typically come down to 
 tool support or style preference.


My problem is that I don't really start with a new project any time soon. 
I'm working on a huge project and am constantly rewriting bits. The entire 
project must keep running, and we release a new version once per week. 
There's no way to convert all the code to D, but it's doable to start using 
a different library for some pieces. I was imagining my own C++ Phobos to 
replace all the fopen's and CreateFile's. Not necessarily to convert the 
whole thing to D later, but just to force people to use 1 way of doing 
things. And to clean up, of course.


 All of the libraries you've mentioned are still evolving.  If there's 
 something you like or don't like about one of them, by all means post 
 feedback.  And if you're interested in porting another library to D, feel 
 free to do so.  The greatest barrier to progress is a lack of free time 
 ;-)


How true. If I would have had more free time, I would have started making an 
ultimate standard library and would have posted that instead of the post I 
wrote now.

L.
Nov 22 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Lionello Lunesu wrote:

 There's no way to convert all the code to D, but it's doable to start
 using a different library for some pieces. I was imagining my own C++
 Phobos to replace all the fopen's and CreateFile's. Not necessarily
 to convert the whole thing to D later, but just to force people to
 use 1 way of doing things. And to clean up, of course.


I can imagine some gc-issues with that tack.

Would it not be better to first have folks do garbage collected C++, and 
once they're used to that, introduce D as a more productive and pleasant 
way to develop code?
Nov 23 2005
parent reply Sean Kelly <sean f4.ca> writes:
Georg Wrede wrote:

 
 Would it not be better to first have folks do garbage collected C++, and 
 once they're used to that, introduce D as a more productive and pleasant 
 way to develop code?


In the past few months I've begun to realize just how much time, effort, 
and library code goes into memory management in C++.  It's really 
somewhat absurd.  I'm beginning to find the idea of using the Boehm GC 
in C++ to be a very attractive option, and I have a feeling it would 
speed up my development time substantially.  I also hope that the C++ GC 
proposal makes it into the next C++ standard library, for much the same 
reason.  D is a subversive language--the longer I use it the more I 
dislike other languages :-)


Sean
Nov 23 2005
parent reply John Reimer <terminal.node gmail.com> writes:
Sean Kelly wrote:

 D is a subversive language--the longer I use it the more I 
 dislike other languages :-)
 


You've got that right!  Every time I try to go back to C/C++, I get a 
feeling of complete lethargy.  I just have no heart to face the old, 
convoluted ways again.  Walter has certainly managed to create some kind 
of pyschological machinery to control our minds! :-)

-JJR
Nov 23 2005
parent JT <JT_member pathlink.com> writes:
In article <dm2esb$1kqk$1 digitaldaemon.com>, John Reimer says...

Sean Kelly wrote:

 D is a subversive language--the longer I use it the more I 
 dislike other languages :-)
 


You've got that right!  Every time I try to go back to C/C++, I get a 
feeling of complete lethargy.  I just have no heart to face the old, 
convoluted ways again.  Walter has certainly managed to create some kind 
of pyschological machinery to control our minds! :-)

-JJR


D is downright beautifull compared to those other ugly languages. Ive recently
ended a 15 year infatuation with C++. I dont even want to talk to her anymore.
:D
Nov 23 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
Lionello Lunesu wrote:

 Someone was working on an MSIL compiler for D.  The project was doing 
 pretty well the last time I heard about it, too, though it's been a while 
 since then.


 
 DNet, yeah, I saw it. It allowed you to use the .NET framework, which is 
 great, but too bad the exe is not native code in that case. Indeed, is it 
 even possible to use .NET from a native code application? I'll have to try 
 this VS2005.


It is with C++.  I'm not sure that any other language has mixed-mode 
support.  I'm fairly certain there's a basic version of VS 2005 
available for free, though I think it doesn't contain a code optimizer.


 All of the libraries you've mentioned are still evolving.  If there's 
 something you like or don't like about one of them, by all means post 
 feedback.  And if you're interested in porting another library to D, feel 
 free to do so.  The greatest barrier to progress is a lack of free time 
 ;-)


 
 How true. If I would have had more free time, I would have started making an 
 ultimate standard library and would have posted that instead of the post I 
 wrote now.


We're all busy :-)  I haven't been able to find more than a spare hour 
here or there in the past few months--for coding at any rate, I can 
always slack off and check the newsgroups while I'm at work.  But things 
are winding down for the holidays so I'm hoping to have some time free 
before too long.


Sean
Nov 23 2005
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Lionello Lunesu wrote:
  > What disturbs me is the fact that every new language introduces a new

 'standard' library. And it's mostly the success of the standard library that 
 determines the language's faith. It's one thing to learn a new syntax, but 
 with each new language we also have to learn a new library. This wastes a 
 lot of time, probably more than learning the language itself. Why is there 
 no single, cross-language standard library? .NET?
 
 In this respect, I think Microsoft's got it right with their .NET framework: 
 whatever language you use, there's only one 'standard library'. 


<rant>
  I think .NET is a great fraud. There is only *one* .NET language, it's 

other languages don't have one. Other languages are supported only to 

shafted. C++ got a lobotomy, a hack was required to supported 
deterministic destruction. The container classes  are pathetic by C++ 

through and through.
They had an enormous budget, and they abandoned compatibility with C, 
with the Windows API, and even the x86 CPU, they had Java to learn from, 

cleaner language by cutting the stupid bits out of C++, if you don't 
mind losing the best bits at the same time.
</rant>

Libraries are always closely tied to their language. But, I agree that 
we should copy a successful structure as far as possible.


 My suggestions:
 * merge Phobos, Ares and Mango into one helluva standard library
 * adopt either the .NET framework or the python modules structure
 
 Of course, D's standard library must remain in native code. I'm only 
 suggesting adopting another library's structure.


I agree completely, I think we should clarify what the barriers are to 
repackaging Phobos.
The crucial question is, can the code from Phobos be pulled into Ares, 
and repackaged as a much better standard library, or are there issues 
with the licenses? It would just be ridiculous for Ares to reimplement 
things that are already in Phobos.

Walter's a fantastic language designer and compiler writer, but D would 
progress much faster if the standard library could be spun off. Even if 
there was a repository for branches on the library, with Walter 
retaining the sole authority to merge branches into the trunk. The docs 
could improve quickly, for a start, instead of wasting effort updating 
that stupid wiki instead of the real thing.
Reduce Walter's involvement into "have a look at the changes in this 
file, if it's OK, click this button to check it into the official 
Phobos". Especially, he's got better things to do than fix typos in 
documentation.
Nov 23 2005
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Don Clugston wrote:

 <rant>
  I think .NET is a great fraud. There is only *one* .NET language, it's 



What do you mean by this? There are many .NET languages. Any language 
that conforms to some rules, types and gets translated to MSIL can be a 
.NET language. Even D could.





Iz is .NET standard library, and if D had a .NET compiler it would 
equally be D.NET's std lib.


 The 
 other languages don't have one. Other languages are supported only to 

 shafted. C++ got a lobotomy, a hack was required to supported 
 deterministic destruction. 


With this I agree, C++.NET is the ugliest thing in the world.


 The container classes  are pathetic by C++ 

 through and through.
 They had an enormous budget, and they abandoned compatibility with C, 
 with the Windows API, and even the x86 CPU, they had Java to learn from, 


Well in the end .NET code gets just-in-time compiled to WinAPI calls and 
x86 instructions, there is just one more step in between - MSIL.



 cleaner language by cutting the stupid bits out of C++, if you don't 
 mind losing the best bits at the same time.



would ne so great to have an alternative D(.NET) compiler. Some people 
like-it-or-not have to program in .NET and D would be IMHO a far better
Nov 23 2005
next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
news:dm1e9c$vj6$1 digitaldaemon.com...

 Don Clugston wrote:

 <rant>
  I think .NET is a great fraud. There is only *one* .NET language, it's 



 What do you mean by this? There are many .NET languages. Any language that 
 conforms to some rules, types and gets translated to MSIL can be a .NET 
 language. Even D could.


Right - there are dozens of .NET languages. 

designed especially for .NET.





 Iz is .NET standard library, and if D had a .NET compiler it would equally 
 be D.NET's std lib.


 The other languages don't have one. Other languages are supported only to 

 shafted. C++ got a lobotomy, a hack was required to supported 
 deterministic destruction.


 With this I agree, C++.NET is the ugliest thing in the world.


That's not the case anymore. The new C++/CLI is a vast improvement over 
Managed C++ (although it no longer looks like C++).


 The container classes  are pathetic by C++ standards. There's no support 

 They had an enormous budget, and they abandoned compatibility with C, 
 with the Windows API, and even the x86 CPU, they had Java to learn from,


 Well in the end .NET code gets just-in-time compiled to WinAPI calls and 
 x86 instructions, there is just one more step in between - MSIL.



 cleaner language by cutting the stupid bits out of C++, if you don't mind 
 losing the best bits at the same time.



 ne so great to have an alternative D(.NET) compiler. Some people 
 like-it-or-not have to program in .NET and D would be IMHO a far better
Nov 23 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
John C wrote:

 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dm1e9c$vj6$1 digitaldaemon.com...
 

 Don Clugston wrote:
 

 <rant> I think .NET is a great fraud. There is only *one* .NET



 
 What do you mean by this? There are many .NET languages. Any
 language that conforms to some rules, types and gets translated to
 MSIL can be a .NET language. Even D could.


 
 
 Right - there are dozens of .NET languages. 

 to be designed especially for .NET.
 
 




 
 Iz is .NET standard library, and if D had a .NET compiler it would
 equally be D.NET's std lib.
 
 

 The other languages don't have one. Other languages are supported

 different, it got shafted. C++ got a lobotomy, a hack was
 required to supported deterministic destruction.


 
 With this I agree, C++.NET is the ugliest thing in the world.


 
 
 That's not the case anymore. The new C++/CLI is a vast improvement
 over Managed C++ (although it no longer looks like C++).
 
 

 The container classes  are pathetic by C++ standards. There's no

 through. They had an enormous budget, and they abandoned
 compatibility with C, with the Windows API, and even the x86 CPU,
 they had Java to learn from,


 
 Well in the end .NET code gets just-in-time compiled to WinAPI
 calls and x86 instructions, there is just one more step in between
 - MSIL.
 
 


 produce a cleaner language by cutting the stupid bits out of C++,
 if you don't mind losing the best bits at the same time.


 

 it would ne so great to have an alternative D(.NET) compiler. Some
 people like-it-or-not have to program in .NET and D would be IMHO a





IF D becomes as universal as we'd like, then unavoidably the day comes 
when some big-buck company (not Microsoft) starts selling a D.NET 
compiler. And they'll get filthy rich. Filthy!

Maybe Walter should now copyright everything so that, if that's done, 
they have to pay him royalties!

(I'm not asking commission for this idea. :-)
Nov 23 2005
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Georg Wrede wrote:

 IF D becomes as universal as we'd like, then unavoidably the day comes 
 when some big-buck company (not Microsoft) starts selling a D.NET 
 compiler. And they'll get filthy rich. Filthy!
 


Or a better solution, a user or a group of D users write that compiler
and share it with the community. Not so imposible as it allready
happened before.
Nov 23 2005
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Ivan Senji wrote:

 Don Clugston wrote:
 

 <rant>
  I think .NET is a great fraud. There is only *one* .NET language, 





  > What do you mean by this? There are many .NET languages. Any language

 that conforms to some rules, types and gets translated to MSIL can be a 
 .NET language. Even D could.


I know that's the official line, but it is really not true. AFAICT, the 
only reason the other languages exist is so that C++ and VB programmers 
don't feel like they've been abandoned. (In fact, VB.NET is just a 

compiler).

Of course I'm exaggerating, but the point is, the rules and types, and 


every other language has to "make do". To an extent, you can deduce the 






 
 Iz is .NET standard library, and if D had a .NET compiler it would 
 equally be D.NET's std lib.


That would be the same as C++ using the C standard library. It's not a 
C++ library, it's not written the way you'd write a C++ library, at all.

And this is why C++.NET and VB.NET had to have features like delegates 
and garbage collection added, they are an essential part of the libraries.



 would ne so great to have an alternative D(.NET) compiler. Some people 
 like-it-or-not have to program in .NET and D would be IMHO a far better 



I agree with that.
Nov 23 2005
prev sibling next sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
Hi,





Well yeah, why wouldn't you have at least one language that fits the library 

don't know which one was first : )


 They had an enormous budget, and they abandoned compatibility with C, with 
 the Windows API, and even the x86 CPU, they had Java to learn from, and 

 cleaner language by cutting the stupid bits out of C++, if you don't mind 
 losing the best bits at the same time.


As I recall they not only cut stuff, but also added quite a few new 
thingies, not unlike D. As far as C++ .NET is concerned, I've done a small 
program in it and it is ...disgusting... I'm sticking to WTL when coding 
Windows apps in C++.


 The crucial question is, can the code from Phobos be pulled into Ares, and 
 repackaged as a much better standard library, or are there issues with the 
 licenses? It would just be ridiculous for Ares to reimplement things that 
 are already in Phobos.


I think that's what's already been done. I believe Ares is a full 
replacement for Phobos, including AA and GC.


 Walter's a fantastic language designer and compiler writer, but D would 
 progress much faster if the standard library could be spun off. Even if 
 there was a repository for branches on the library, with Walter retaining 
 the sole authority to merge branches into the trunk. The docs could 
 improve quickly, for a start, instead of wasting effort updating that 
 stupid wiki instead of the real thing.


I agree! The wiki's is getting kind-of messy. Of course, anybody can go 
about and organize stuff. Maybe the official docs should be imported into 
the wiki and be the unofficial "official doc".


 Especially, he's got better things to do than fix typos in documentation.


<cynic>Yeah, fixing bugs in DDoc.</cynic>
Walter's doing a great job as the language designer and compiler writer. 
Eventhough the language lacks some features I would personally like, in the 
end having 1 reviewer is reassuring. At least there's consitency in 
decisions (well, should be anyway).

I really believe Phobos is pulling D down, rather than pushing it up, which 
is a real shame. D deserves better.

L.
Nov 23 2005
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
The crucial question is, can the code from Phobos be pulled into Ares, and 
repackaged as a much better standard library, or are there issues with the 
licenses? It would just be ridiculous for Ares to reimplement things that 
are already in Phobos.


 
 
 I think that's what's already been done. I believe Ares is a full 
 replacement for Phobos, including AA and GC.


It's only enough to compile. All the functions like writef(), the string 
functions, the math functions, io, etc are not in Ares.


 I agree! The wiki's is getting kind-of messy. Of course, anybody can go 
 about and organize stuff. Maybe the official docs should be imported into 
 the wiki and be the unofficial "official doc".


Better I think would be to create a subversion repository (on dsource?) 
and import phobos and the docs into it.
Then anyone could change it, and if Walter liked any changes, he could 
bless it as official, and someone could update the unofficial phobos 
with the official one every time a release was made. Of course he would 
have to agree to the existence such an unofficial phobos repository.

I just suggest this because it would require no effort from Walter. It 
would of course be better if there was an official repository.

trunk --- official DMD releases
branch --- latest unofficial release for Walter to review
subbranches --- new submissions.

One branch could be called 'Ares' :-) The Ares crowd could fold relevant 
Phobos updates into their branch, instead of needing to reinvent the wheel.
I just hate to see duplicated effort.


 I really believe Phobos is pulling D down, rather than pushing it up, which 
 is a real shame. D deserves better.


I couldn't agree more.
Nov 23 2005
next sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:dm1jtv$12ff$1 digitaldaemon.com...

The crucial question is, can the code from Phobos be pulled into Ares, 
and repackaged as a much better standard library, or are there issues 
with the licenses? It would just be ridiculous for Ares to reimplement 
things that are already in Phobos.



 I think that's what's already been done. I believe Ares is a full 
 replacement for Phobos, including AA and GC.


 It's only enough to compile. All the functions like writef(), the string 
 functions, the math functions, io, etc are not in Ares.


 I agree! The wiki's is getting kind-of messy. Of course, anybody can go 
 about and organize stuff. Maybe the official docs should be imported into 
 the wiki and be the unofficial "official doc".


 Better I think would be to create a subversion repository (on dsource?) 
 and import phobos and the docs into it.
 Then anyone could change it, and if Walter liked any changes, he could 
 bless it as official, and someone could update the unofficial phobos with 
 the official one every time a release was made. Of course he would have to 
 agree to the existence such an unofficial phobos repository.

 I just suggest this because it would require no effort from Walter. It 
 would of course be better if there was an official repository.

 trunk --- official DMD releases
 branch --- latest unofficial release for Walter to review
 subbranches --- new submissions.

 One branch could be called 'Ares' :-) The Ares crowd could fold relevant 
 Phobos updates into their branch, instead of needing to reinvent the 
 wheel.
 I just hate to see duplicated effort.


That would be an interesting idea; have  ares be the "testbed" for phobos. 
That way ares would just be phobos-unstable or something like that, and 
after a period of testing and such a module is put in to phobos.

 I really believe Phobos is pulling D down, rather than pushing it up, 
 which is a real shame. D deserves better.


 I couldn't agree more.
Nov 23 2005
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Don Clugston wrote:

 The crucial question is, can the code from Phobos be pulled into
  Ares, and repackaged as a much better standard library, or are
 there issues with the licenses? It would just be ridiculous for
 Ares to reimplement things that are already in Phobos.


 
 I think that's what's already been done. I believe Ares is a full 
 replacement for Phobos, including AA and GC.


 
 It's only enough to compile. All the functions like writef(), the
 string functions, the math functions, io, etc are not in Ares.


Maybe it's okay with Walter if Ares can pick what it wants from Phobos? 
Doesn't hurt to ask.


 I agree! The wiki's is getting kind-of messy. Of course, anybody
 can go about and organize stuff. Maybe the official docs should be
  imported into the wiki and be the unofficial "official doc".


 
 Better I think would be to create a subversion repository (on
 dsource?) and import phobos and the docs into it. Then anyone could
 change it, and if Walter liked any changes, he could bless it as
 official, and someone could update the unofficial phobos with the
 official one every time a release was made. Of course he would have
 to agree to the existence such an unofficial phobos repository.
 
 I just suggest this because it would require no effort from Walter.
 It would of course be better if there was an official repository.


That sounds excellent!


 trunk --- official DMD releases branch --- latest unofficial release
 for Walter to review subbranches --- new submissions.
 
 One branch could be called 'Ares' :-) The Ares crowd could fold
 relevant Phobos updates into their branch, instead of needing to
 reinvent the wheel. I just hate to see duplicated effort.
 

 I really believe Phobos is pulling D down, rather than pushing it
 up, which is a real shame. D deserves better.


 
 I couldn't agree more.


Ditto!
Nov 23 2005
parent Sean Kelly <sean f4.ca> writes:
Georg Wrede wrote:

 Don Clugston wrote:

 It's only enough to compile. All the functions like writef(), the
 string functions, the math functions, io, etc are not in Ares.


 
 Maybe it's okay with Walter if Ares can pick what it wants from Phobos? 
 Doesn't hurt to ask.


Pretty much all of the standard Phobos modules are in the public domain, 
so they can be incorporated into Ares so long as the file headers are 
preserved.  I will likely "submit" some Phobos features to Ares at some 
point, if they seem to fit the bill.  The math functions are a good 
candidate, for example, which is why I asked about including them a few 
days ago.  As for I/O... I personally like writef quite a bit, and I 
like Mango.io as well, both for slightly different reasons, and one or 
both of these may be submitted before too long.  I've mostly been 
holding off on I/O because it's such a big can of worms--it raises UTF 
conversion and other internationalization issues, and designing a good 
interface for this stuff is not trivial.  ICU seems like an ideal 
candidate for a robust solution, but it shouldn't be necessary to link 
against all of ICU simply to do the basics.


Sean
Nov 23 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:

 The crucial question is, can the code from Phobos be pulled into 
 Ares, and repackaged as a much better standard library, or are there 
 issues with the licenses? It would just be ridiculous for Ares to 
 reimplement things that are already in Phobos.



 I think that's what's already been done. I believe Ares is a full 
 replacement for Phobos, including AA and GC.


 
 It's only enough to compile. All the functions like writef(), the string 
 functions, the math functions, io, etc are not in Ares.


Yup.  Though this may start to change in the coming months.


 Better I think would be to create a subversion repository (on dsource?) 
 and import phobos and the docs into it.
 Then anyone could change it, and if Walter liked any changes, he could 
 bless it as official, and someone could update the unofficial phobos 
 with the official one every time a release was made. Of course he would 
 have to agree to the existence such an unofficial phobos repository.
 
 I just suggest this because it would require no effort from Walter. It 
 would of course be better if there was an official repository.
 
 trunk --- official DMD releases
 branch --- latest unofficial release for Walter to review
 subbranches --- new submissions.
 
 One branch could be called 'Ares' :-) The Ares crowd could fold relevant 
 Phobos updates into their branch, instead of needing to reinvent the wheel.
 I just hate to see duplicated effort.


I already do this.  Difference in this case being that the changes I 
fold in are at a very low level.  But personally, I don't want any 
obligation to preserve Phobos interface compatibility in Ares--one of 
the reasons the project was started was to be free from that yoke.  That 
said, it would be relatively trivial to make Phobos run on Ares.  It's 
practically just a matter of taking everything in the 'std' Phobos 
package and dropping in the 'std' Ares package.  I have a feeling that 
nearly all of it would Just Work.


Sean
Nov 23 2005
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Lionello Lunesu wrote:

 Walter's a fantastic language designer and compiler writer, but D
 would progress much faster if the standard library could be spun
 off. Even if there was a repository for branches on the library,
 with Walter retaining the sole authority to merge branches into the
 trunk. The docs could improve quickly, for a start, instead of
 wasting effort updating that stupid wiki instead of the real thing.


 
 I agree! The wiki's is getting kind-of messy. Of course, anybody can
 go about and organize stuff. Maybe the official docs should be
 imported into the wiki and be the unofficial "official doc".


Yes, please!!!!

The docs should be automatically put to the Wiki each time a new version 
of DMD comes out. Then folks could just look at the Wiki changes to 
quickly see what's new or what's changed.

Like it is today, no matter how much and often one rereads the docs, 
there's always _something_ you non't notice, that's been fixed like 6 
months ago, and you still don't know. A total waste of everybody's time. 
It would also reduce static on this forum.


On other pages on the Wiki we could start developing a proper manual!
Nov 23 2005
parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:4384B00B.8070105 nospam.org...

 The docs should be automatically put to the Wiki each time a new version 
 of DMD comes out. Then folks could just look at the Wiki changes to 
 quickly see what's new or what's changed.


What's the license of the D docs on digitalmars.com ?

L.
Nov 25 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Lionello Lunesu wrote:

 "Georg Wrede" <georg.wrede nospam.org> wrote
 

The docs should be automatically put to the Wiki each time a new version 
of DMD comes out. Then folks could just look at the Wiki changes to 
quickly see what's new or what's changed.


 
 What's the license of the D docs on digitalmars.com ?


Makes no difference.

??? Cause we'd ask Walter's permission anyhow. ;-)
Nov 25 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
Lionello Lunesu wrote:

 
 As I recall they not only cut stuff, but also added quite a few new 
 thingies, not unlike D. As far as C++ .NET is concerned, I've done a small 
 program in it and it is ...disgusting... I'm sticking to WTL when coding 
 Windows apps in C++.


Don't make that decision quite yet.  C++/CLI (in the new Visual Studio 
8) features a complete rewrite of C++ .NET integration and you almost 
can't tell the new syntax apart from native C++.  I'm still not that 
anxious to write .NET code, but at least this time around using C++ 
won't be so much of a nightmare.


Sean
Nov 23 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:

 
 <rant>
  I think .NET is a great fraud. There is only *one* .NET language, it's 

 other languages don't have one. Other languages are supported only to 

 shafted. C++ got a lobotomy, a hack was required to supported 
 deterministic destruction. The container classes  are pathetic by C++ 

 through and through.
 They had an enormous budget, and they abandoned compatibility with C, 
 with the Windows API, and even the x86 CPU, they had Java to learn from, 

 cleaner language by cutting the stupid bits out of C++, if you don't 
 mind losing the best bits at the same time.
 </rant>


I agree completely.  However, the .NET library is still the best library 
MS has produced to date.  It's a vast improvement over MFC, for example. 
  And C++/CLI, unlike other .NET languages, allows managed and unmanaged 
code to be quite easily intermixed.  I do my utmost to avoid front-end 
programming tasks, but if I ever had to I would write a thin layer in 
C++ .NET and do the bulk of my codebase in plain old unmanaged C++.  Or 
perhaps managed C++ but using STL containers and the like--.NET 2.0 
contains some clever hacks to make templates and such work with managed 
code.


 Walter's a fantastic language designer and compiler writer, but D would 
 progress much faster if the standard library could be spun off. Even if 
 there was a repository for branches on the library, with Walter 
 retaining the sole authority to merge branches into the trunk. The docs 
 could improve quickly, for a start, instead of wasting effort updating 
 that stupid wiki instead of the real thing.


Agreed.  Though Walter would have to retain ownership of the DMD runtime 
code.  That said, one thing I like about Ares being unofficial is that 
it allows me to make fundamental changes to it if someone has a good 
idea.  Even with D in its current beta state, I think Walter has a bit 
less freedom with Phobos simply because so many people expect it to be 
as stable as a release-level library.  If this ever happens I think it 
should begin as a new (from scratch) library project where things can be 
refined before being made "official" so people expect new features to 
change a bit while they're being evaluated.  Standard Phobos components 
may be retained in a compatibility area, but only to support legacy 
code.  This is pretty much what Ares is doing, but without any sort of 
official stamp of approval.


 Reduce Walter's involvement into "have a look at the changes in this 
 file, if it's OK, click this button to check it into the official 
 Phobos". Especially, he's got better things to do than fix typos in 
 documentation.


Aside from the runtime code and perhaps the DMD GC implementation, I 
agree.  There's simply no reason for Walter to be responsible for the 
language design *and* for the entire standard library.  Some degree of 
advisory or veto control over the library code should be sufficient IMO. 
  But this is an old topic.  I suggest that anyone who is interested in 
this sort of thing participate in the Ares project.  If Ares gets to the 
point where it's "better" than Phobos, I have the feeling Walter would 
be amenable to using it in some way or another.  Until that time, it's 
really just an interesting idea that may or may not pan out.


Sean
Nov 23 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Let me give some of my thoughts on this issue:

I too think good libraries are very important, but I question the need 
for them to be "standard", and by "standard" I mean supervised by the 
language makers, or being part of the language library standard itself. 
Actually, let me refine this statement in two cases:
One is about libraries about general-purpose stuff, like containers, IO, 
memory, etc., -> yes, those should be in the language standard.
But more specific or advanced stuff, like XML, DOM's, HTTP and advanced 
networking, databases, graphical toolkits, etc., they could well be in 
seperate libraries, or in a whole seperate high-level library. What I 
want of such library is that it be consistent, well-structured, etc. and 
possibly "standard" in the sense that there aren't a slew of different 
ones to do the same thing, but I don't necessarely want to be the 
language makers the responsable for such library.
Take for example Boost, it's a great library, and it didn't have to be 
part of the standard library (altough they're thinking of assimilating 
some things)

Also, in D's case, Walter as a one-man show will never be able to make a 
standard library as comprehensive as .Net's or Java's, altough surely he 
agrees on the importance of a good library.
In fact, even for the core library (the general-purpose stuff) Walter's 
time is very limited, so there's no purpose is just sitting and wishing 
for such a library to exist. The best we can do is ask to those 
interested in the D community to help build a good "single" library 
instead of the slew of stuff we have currently (Phobos, Ares, MinTL, 
DTL, Mango, etc.), and then maybe someday it would be good enough that 
it (or parts of it) would be incorporated in the D standard.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Nov 23 2005
parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dm1pbf$1528$2 digitaldaemon.com...

 Let me give some of my thoughts on this issue:

 I too think good libraries are very important, but I question the need for 
 them to be "standard", and by "standard" I mean supervised by the language 
 makers, or being part of the language library standard itself. Actually, 
 let me refine this statement in two cases:
 One is about libraries about general-purpose stuff, like containers, IO, 
 memory, etc., -> yes, those should be in the language standard.


I guess if only the stuff D _really_ needs to be in Phobos, meaning the GC 
and AA stuff. And one can use the CRT for IO, although it doesn't really 
show D's strengths.


 But more specific or advanced stuff, like XML, DOM's, HTTP and advanced 
 networking, databases, graphical toolkits, etc., they could well be in 
 seperate libraries, or in a whole seperate high-level library. What I want 
 of such library is that it be consistent, well-structured, etc. and 
 possibly "standard" in the sense that there aren't a slew of different 
 ones to do the same thing, but I don't necessarely want to be the language 
 makers the responsable for such library.


True. They/he has better things to do, I assume. But D definately needs this 
kind of library. It will open many doors.


 In fact, even for the core library (the general-purpose stuff) Walter's 
 time is very limited, so there's no purpose is just sitting and wishing 
 for such a library to exist. The best we can do is ask to those interested 
 in the D community to help build a good "single" library instead of the 
 slew of stuff we have currently (Phobos, Ares, MinTL, DTL, Mango, etc.), 
 and then maybe someday it would be good enough that it (or parts of it) 
 would be incorporated in the D standard.


It's true that the initiative lies with the community on this one.

L.
Nov 23 2005
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Lionello Lunesu wrote:

 
 I guess if only the stuff D _really_ needs to be in Phobos, meaning the GC 
 and AA stuff. And one can use the CRT for IO, although it doesn't really 
 show D's strengths.


I don't understand that first phrase: it's not well constructed, and I 
can't deduce the intended meaning.
-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Nov 23 2005
parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dm2s0c$2066$1 digitaldaemon.com...

 Lionello Lunesu wrote:

 I guess if only the stuff D _really_ needs to be in Phobos, meaning the 
 GC and AA stuff. And one can use the CRT for IO, although it doesn't 
 really show D's strengths.


 I don't understand that first phrase: it's not well constructed, and I 
 can't deduce the intended meaning.


You're right, it's missing some words.. I have a hard time myself trying to 
remember what I wanted to say:

 I guess only the stuff that D _really_ needs should be in Phobos, being 
 the GC and AA stuff.




You can add to this the critical section calls.

L.
Nov 23 2005