Perhaps the offer disappeared int he noise, so I repost what I wrote earlier in the "D's commercial weaknesses?" thread in D.announce:

===
Thought it over, we could dedicate one person full time (40 hours/week) from the beginning of April and then for about ten weeks for the task of writing and fixing code in Phobos.

But before we do, the big question is, where should the effort be made, and how so the time is not wasted?
===

Lars Ivar Igesund suggested working on Ares not Phobos. But well, big question still is what and where to put the effort in. Time changes, so unless something can be decided in in the next weeks this window probably closes for now.

// Fredrik Olsson

Fredrik Olsson wrote:

> Lars Ivar Igesund suggested working on Ares not Phobos. But well, big question still is what and where to put the effort in. 

As you may or may now know already:

Phobos is maintained by Digital Mars, so any changes go to Walter...
Ares is both a Phobos replacement/alternative, as well as extension.

Then we have "gphobos", which is the GNU version of the DMD Phobos
that has all of the extra changes *needed* for GDC to work properly.

(such as extending to Unix platforms beyond linux, and some bug fixes.
Most *could* be included in Phobos, possibly with a "version(GNU) {}")
See http://www.algonet.se/~afb/d/diffs/dmd-0.140-gdc-0.17.diff.gz
(also has the changes to the D compiler, so search down for "phobos")


Where indeed, there seems to be a bit too many "standard libraries" ?
--anders


PS. I believe the Mango Tree targets *both* of Phobos and Ares...

> Thought it over, we could dedicate one person full time (40 hours/week) from the beginning of April and then for about ten weeks for the task of writing and fixing code in Phobos.


Thats awesome!  Though I would defintly build on top of Ares, it seems more modular and it would avoid any licensing issues .  Then probably pitch it to Walter as a replacement for phobos.

I think the Ares team at the moment  is debating a 'theme' for the library , ala C++'s STL algorithm approach.  My personal vote goes to opApply and foreach () ( see the Library Chaos thread starting about here : http://www.dsource.org/forums/viewtopic.php?t=1033&start=12 ).

I think the only chance for building a new stdlib is for someone to pick it up and run with it .  Once its a bit more fleshed out I imagine contributors would come out of the wood work.

You might also consider how DDL could help the stdlib .

Here's to hoping you do it!

Charlie





"Fredrik Olsson" <peylow@treyst.se> wrote in message news:dq7qd9$7ct$1@digitaldaemon.com...
> Perhaps the offer disappeared int he noise, so I repost what I wrote earlier in the "D's commercial weaknesses?" thread in D.announce:
>
> ===
> Thought it over, we could dedicate one person full time (40 hours/week)
> from the beginning of April and then for about ten weeks for the task of
> writing and fixing code in Phobos.
>
> But before we do, the big question is, where should the effort be made,
> and how so the time is not wasted?
> ===
>
> Lars Ivar Igesund suggested working on Ares not Phobos. But well, big question still is what and where to put the effort in. Time changes, so unless something can be decided in in the next weeks this window probably closes for now.
>
> // Fredrik Olsson

Charles wrote:
>> Thought it over, we could dedicate one person full time (40 hours/week)
>> from the beginning of April and then for about ten weeks for the task of
>> writing and fixing code in Phobos.
> 
> Thats awesome!  Though I would defintly build on top of Ares, it seems more
> modular and it would avoid any licensing issues .  Then probably pitch it to
> Walter as a replacement for phobos.

Ares is contribution-based, so if there's something you think Ares needs, feel free to submit it.  At the moment, it needs pretty much everything, but for the moment I'm trying to focus on the essentials. In the queue to be added are IO support, Don's math functions (in a std.math package area), and containers.  The GC interface needs a redesign as well, and I'm planning to rework the low-level interaction between the GC and runtime code at the same time.  But the GC work has been pushed off for the moment in favor of simpler and more visible improvements.

> I think the Ares team at the moment  is debating a 'theme' for the library ,
> ala C++'s STL algorithm approach.  My personal vote goes to opApply and
> foreach () ( see the Library Chaos thread starting about here :
> http://www.dsource.org/forums/viewtopic.php?t=1033&start=12 ).

Yup.  Every standard library needs a 'theme' around which its interfaces are designed.  For C++, this is the algorithm/iterator approach. foreach seems a reasonable D equivalent, though it doesn't fit all scenarios addressed by iterators... though iterators don't work nearly as well without implicit template instantiation.  In any case, Ares needs a more solid vision of its 'theme'.  I do like the current C++ idea of favoring free functions whenever possible as opposed to the deep inheritance hierarchies of Java, but again without implicit templates it's a hard sell.  However things sort out though, I think it's important that while one approach should be encouraged, it should not be mandatory.  Thus, I'm trying to support both object-oriented programming and C-like procedural programming whenever doing so doesn't compromise the overall design.

> I think the only chance for building a new stdlib is for someone to pick it
> up and run with it .  Once its a bit more fleshed out I imagine contributors
> would come out of the wood work.

Aye.  And thus Ares.

> You might also consider how DDL could help the stdlib .

And maybe Eric could talk about that a bit.  Personally, I think DDL is one of the most important D projects in progress right now and I guarantee that it will be a part of Ares so long as all involved parties are willing.  Frankly, I'd be happy with plain old dll support, but if D could match the dynamic loading capabilities of Java/.NET I'd jump for joy.


Sean

> Ares is contribution-based, so if there's something you think Ares needs, feel free to submit it.

Yes and Im excited about ares I think its going to be awesome .  Im just impatient ;).

> At the moment, it needs pretty much
> everything, but for the moment I'm trying to focus on the essentials.

I think it would be hard to contribute anything w/o the theme , or IO routines.  Once that is added it will give contribitors something to look at and base their work off IMO.

> Thus, I'm trying to support both object-oriented programming and C-like
procedural programming whenever doing so doesn't compromise

I still think it should be two teired,  the stdlib of free functions, and an OO lib build on top, but Im pretty sure im alone in that opinion :S.

> And maybe Eric could talk about that a bit.

Yes I get that feeling that Ares + DDL is going to be something big :).

Charlie




"Sean Kelly" <sean@f4.ca> wrote in message news:dq8p8n$13be$1@digitaldaemon.com...
> Charles wrote:
> >> Thought it over, we could dedicate one person full time (40 hours/week) from the beginning of April and then for about ten weeks for the task
of
> >> writing and fixing code in Phobos.
> >
> > Thats awesome!  Though I would defintly build on top of Ares, it seems
more
> > modular and it would avoid any licensing issues .  Then probably pitch
it to
> > Walter as a replacement for phobos.
>
> Ares is contribution-based, so if there's something you think Ares needs, feel free to submit it.  At the moment, it needs pretty much everything, but for the moment I'm trying to focus on the essentials. In the queue to be added are IO support, Don's math functions (in a std.math package area), and containers.  The GC interface needs a redesign as well, and I'm planning to rework the low-level interaction between the GC and runtime code at the same time.  But the GC work has been pushed off for the moment in favor of simpler and more visible improvements.
>
> > I think the Ares team at the moment  is debating a 'theme' for the
library ,
> > ala C++'s STL algorithm approach.  My personal vote goes to opApply and
> > foreach () ( see the Library Chaos thread starting about here :
> > http://www.dsource.org/forums/viewtopic.php?t=1033&start=12 ).
>
> Yup.  Every standard library needs a 'theme' around which its interfaces are designed.  For C++, this is the algorithm/iterator approach. foreach seems a reasonable D equivalent, though it doesn't fit all scenarios addressed by iterators... though iterators don't work nearly as well without implicit template instantiation.  In any case, Ares needs a more solid vision of its 'theme'.  I do like the current C++ idea of favoring free functions whenever possible as opposed to the deep inheritance hierarchies of Java, but again without implicit templates it's a hard sell.  However things sort out though, I think it's important that while one approach should be encouraged, it should not be mandatory.  Thus, I'm trying to support both object-oriented programming and C-like procedural programming whenever doing so doesn't compromise the overall design.
>
> > I think the only chance for building a new stdlib is for someone to pick
it
> > up and run with it .  Once its a bit more fleshed out I imagine
contributors
> > would come out of the wood work.
>
> Aye.  And thus Ares.
>
> > You might also consider how DDL could help the stdlib .
>
> And maybe Eric could talk about that a bit.  Personally, I think DDL is one of the most important D projects in progress right now and I guarantee that it will be a part of Ares so long as all involved parties are willing.  Frankly, I'd be happy with plain old dll support, but if D could match the dynamic loading capabilities of Java/.NET I'd jump for
joy.
>
>
> Sean

"Charles" <noone@nowhere.com> wrote ...
>> Ares is contribution-based, so if there's something you think Ares needs, feel free to submit it.
>
> Yes and Im excited about ares I think its going to be awesome .  Im just impatient ;).
>
>> At the moment, it needs pretty much
>> everything, but for the moment I'm trying to focus on the essentials.
>
> I think it would be hard to contribute anything w/o the theme , or IO
> routines.  Once that is added it will give contribitors something to look
> at
> and base their work off IMO.


You can always use Mango with Ares ... it has a pretty cohesive structure to it, a fairly small number of usage patterns (including the themes you speak of), and a wide variety of functionality.

To use Mango with Ares, compile with a -version=Ares, point -I at Ares instead of Phobos, and replace phobos.lib with the Ares equivalent.

Kris wrote:
> "Charles" <noone@nowhere.com> wrote ...
>>> Ares is contribution-based, so if there's something you think Ares
>>> needs, feel free to submit it.
>> Yes and Im excited about ares I think its going to be awesome .  Im just
>> impatient ;).
>>
>>> At the moment, it needs pretty much
>>> everything, but for the moment I'm trying to focus on the essentials.
>> I think it would be hard to contribute anything w/o the theme , or IO
>> routines.  Once that is added it will give contribitors something to look at
>> and base their work off IMO.
> 
> 
> You can always use Mango with Ares ... it has a pretty cohesive structure to it, a fairly small number of usage patterns (including the themes you speak of), and a wide variety of functionality.
> 
> To use Mango with Ares, compile with a -version=Ares, point -I at Ares instead of Phobos, and replace phobos.lib with the Ares equivalent.
> 
> 

I can attest to this working great on Windows.  I use Mango with Ares on most of my projects now.  There are still a few things I'm missing, though, like std.string with all the toString methods.  But it's easy enough to customize that solution until Ares eventually provides its own.  Mango easily fills in all other needs.  I'm satisfied to ride the Mango/Ares combination as they continue to grow.

Note, though, that Ares does not appear to be working completely on Linux ATM.  Or maybe it has been updated to work again recently?

-JJR

[snippity snip]

Charles wrote:
> 
>>Thus, I'm trying to support both object-oriented programming and C-like procedural programming whenever doing so doesn't compromise
> 
> I still think it should be two teired,  the stdlib of free functions, and an
> OO lib build on top, but Im pretty sure im alone in that opinion :S.
> 

If going this route, please templatize every method such that it is guaranteed that the OO is not simply calling the flat functions in a wrapper, but instead inlining them directly with the templates.

How will you maintain state across functions with this approach that supports both flat functions and OO?  Something to chew on...

"John Reimer" <terminal.node@gmail.com> wrote...
> Kris wrote:
>> "Charles" <noone@nowhere.com> wrote ...
>>>> Ares is contribution-based, so if there's something you think Ares needs, feel free to submit it.
>>> Yes and Im excited about ares I think its going to be awesome .  Im just impatient ;).
>>>
>>>> At the moment, it needs pretty much
>>>> everything, but for the moment I'm trying to focus on the essentials.
>>> I think it would be hard to contribute anything w/o the theme , or IO
>>> routines.  Once that is added it will give contribitors something to
>>> look at
>>> and base their work off IMO.
>>
>>
>> You can always use Mango with Ares ... it has a pretty cohesive structure to it, a fairly small number of usage patterns (including the themes you speak of), and a wide variety of functionality.
>>
>> To use Mango with Ares, compile with a -version=Ares, point -I at Ares instead of Phobos, and replace phobos.lib with the Ares equivalent.
>>
>>
>
> I can attest to this working great on Windows.  I use Mango with Ares on most of my projects now.  There are still a few things I'm missing, though, like std.string with all the toString methods.


Au contraire, my friend :)

Take a look at convert.Double, convert.Integer, and convert.Rfc1123 ... they handle formatting and parsing of floating point, integer and (internet) dates. Each one operates with char/wchar/dchar, just like the rest of the mango.convert package.

I think Mango needs some better documentation <g>


> But it's easy enough to customize that solution until Ares eventually provides its own.  Mango easily fills in all other needs.  I'm satisfied to ride the Mango/Ares combination as they continue to grow.
>
> Note, though, that Ares does not appear to be working completely on Linux ATM.  Or maybe it has been updated to work again recently?


I think there's still some work to do with Ares threading on linux, but I believe Mango operates fine on linux when using Phobos?

In article <dq8p8n$13be$1@digitaldaemon.com>, Sean Kelly says...
>
>> You might also consider how DDL could help the stdlib .
>
>And maybe Eric could talk about that a bit.  Personally, I think DDL is one of the most important D projects in progress right now and I guarantee that it will be a part of Ares so long as all involved parties are willing.  Frankly, I'd be happy with plain old dll support, but if D could match the dynamic loading capabilities of Java/.NET I'd jump for joy.
>

Well, there's not much to say that hasn't already been said.  I'd happily submit DDL for inclusion into Ares once we get through 1.0.  Its been slow but steady work, and I'm happy to say that almost all of the research for the project has been completed.  We're down to refining the library API, fixing portability issues, and debugging, debugging, debugging.  Its all "Beta = very yes" right now.

If I had to guess, I'd reckon that DDL will probably have to mature beyond 1.0 into something that fits with the eventual Ares theme, before it is fit for inclusion.  Since the style and theme of Ares hasn't been 100% determined yet, I really don't know how far from the mark we're going to get.  At worst, it'll remain a satellite library with compatiblity in mind; at a minimum that will be the case for using it with phobos.

One more thing: I've also got to hand it to J Duncan, Lars, Don, Sean and Kris for helping make this the single best example of "stone soup" I can think of. DDL has come a long way in a very short timeframe, and is far closer to completing the overall project vision thanks to them.  Thanks guys. :)

- EricAnderton at yahoo