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!

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

"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.

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

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

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

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

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

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

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.