www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Developer

reply Fredrik Olsson <peylow treyst.se> writes:
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
Jan 13 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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...
Jan 13 2006
prev sibling next sibling parent reply "Charles" <noone nowhere.com> writes:
 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
Jan 13 2006
parent reply Sean Kelly <sean f4.ca> writes:
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
Jan 13 2006
next sibling parent reply "Charles" <noone nowhere.com> writes:
 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
Jan 13 2006
next sibling parent reply "Kris" <fu bar.com> writes:
"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.
Jan 13 2006
parent reply John Reimer <terminal.node gmail.com> writes:
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
Jan 13 2006
next sibling parent reply "Kris" <fu bar.com> writes:
"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?
Jan 13 2006
parent reply John Reimer <terminal.node gmail.com> writes:
Kris wrote:



 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.
 



My mistake was including Mango and Ares in the same breath.  Mango is by 
far feature complete.  I believe it is fairly close to lacking nothing, 
for my needs: I love it.  Ares, on the other hand, could use a couple of 
useful string functions as per discussion on dsource.



 I think Mango needs some better documentation <g>



Yes, Mango needs a strong tutorial to reveal it's deep, dark secrets to 
the world, but the examples do nicely in the meantime.  I believe that 
concurrent to the publication of the /D Programming Language/ there 
should be a /Plucking the Mango Tree/ released as well.  ;)



 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? 
 
 


I spoke to soon, perhaps.  I'll give it a try again.  Thousand pardons. :)

-JJR



 Jan 13 2006



 next sibling parent reply Sean Kelly <sean f4.ca>  writes:


John Reimer wrote:

 
 My mistake was including Mango and Ares in the same breath.  Mango is by 
 far feature complete.  I believe it is fairly close to lacking nothing, 
 for my needs: I love it.  Ares, on the other hand, could use a couple of 
 useful string functions as per discussion on dsource.


Aye.  I'm thinking this may all sort itself out rather nicely if 
Mango.io is submitted to Ares (which I may do quite soon).  Though I 
suppose my idea of adding the toUtf functions to the object module may 
be problematic when building against Ares and Mango... hrm... I suppose 
I'll jump off that bridge when I come to it.


Sean



 Jan 13 2006



  parent reply John Reimer <terminal.node gmail.com>  writes:


Sean Kelly wrote:

 John Reimer wrote:

 My mistake was including Mango and Ares in the same breath.  Mango is 
 by far feature complete.  I believe it is fairly close to lacking 
 nothing, for my needs: I love it.  Ares, on the other hand, could use 
 a couple of useful string functions as per discussion on dsource.


 
 Aye.  I'm thinking this may all sort itself out rather nicely if 
 Mango.io is submitted to Ares (which I may do quite soon).  Though I 
 suppose my idea of adding the toUtf functions to the object module may 
 be problematic when building against Ares and Mango... hrm... I suppose 
 I'll jump off that bridge when I come to it.
 
 
 Sean



Hey Sean,

I read your thoughts on adding Mango.io or the UTF functions.  I'm 
really not certain what the correct approach is either.  Mango.io is 
tremendously useful, but does take the OO approach to things.

This is definitely a topic for further discussion... perhaps on dsource.org.

BTW, I /really/ appreciate all you've done in Ares.  It's worked very 
well for me so far.  It just needs to be slowly built up.

Thanks again,

John



 Jan 13 2006



  parent  Sean Kelly <sean f4.ca>  writes:


John Reimer wrote:

 Hey Sean,
 
 I read your thoughts on adding Mango.io or the UTF functions.  I'm 
 really not certain what the correct approach is either.  Mango.io is 
 tremendously useful, but does take the OO approach to things.


This is my one trepidation, but it's based more on speculation than 
experience.  I want to spend some time with Mango before I will feel 
comfortable saying much on the matter.  And it doesn't help that Mango 
is such a well-designed library.


 This is definitely a topic for further discussion... perhaps on 
 dsource.org.


True.  No reason to derail this topic further :-)


 BTW, I /really/ appreciate all you've done in Ares.  It's worked very 
 well for me so far.  It just needs to be slowly built up.


Yeah it does.  But at the same time I don't want to feel like I'm doing 
everything from scratch, particularly when there are good alternatives 
available.  Though by the same token, I really do want Ares to feel like 
a cohesive whole.  It's a somewhat narrow line to walk at times, and 
possibly a contributing factor in why progress has been relatively slow.


Sean



 Jan 13 2006



prev sibling  parent reply "Kris" <fu bar.com>  writes:


"John Reimer" <terminal.node gmail.com> wrote ...

 Kris wrote:
 Yes, Mango needs a strong tutorial to reveal it's deep, dark secrets to 
 the world, but the examples do nicely in the meantime.  I believe that 
 concurrent to the publication of the /D Programming Language/ there should 
 be a /Plucking the Mango Tree/ released as well.  ;)


Funny!

I do wish I were a better writer. I don't suppose there's anyone here who'd 
be interested in writing some high-level documentation for a suite of 
library components? I imagine that would be asking for too much <g>



 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?


 I spoke to soon, perhaps.  I'll give it a try again.  Thousand pardons. :)


Please do!

if (broken)
    kris.fix (issue); 



 Jan 13 2006



  parent  John Reimer <terminal.node gmail.com>  writes:


Kris wrote:

 "John Reimer" <terminal.node gmail.com> wrote ...

 Kris wrote:
 Yes, Mango needs a strong tutorial to reveal it's deep, dark secrets to 
 the world, but the examples do nicely in the meantime.  I believe that 
 concurrent to the publication of the /D Programming Language/ there should 
 be a /Plucking the Mango Tree/ released as well.  ;)


 
 Funny!
 
 I do wish I were a better writer. I don't suppose there's anyone here who'd 
 be interested in writing some high-level documentation for a suite of 
 library components? I imagine that would be asking for too much <g>
 
 



Ha ha... you're even funnier.  You wish you were a better writer? 
Hogwash.  I won't lavish you with any useless flattery, but I will say 
that I think you are more than adequately equipped for any such task.

I have considered doing some tutorial stuff myself for Mango, but have 
no time for that, at the moment (original excuse, no?).  I've already 
jumped into more things than I can handle at this time.



 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?


 I spoke to soon, perhaps.  I'll give it a try again.  Thousand pardons. :)


 
 Please do!
 
 if (broken)
     kris.fix (issue); 



I will.  Just got to get some higher priority things done over the next 
few days.  For some reason, everything is piling up on me recently, both 
work and home. *sigh*

-JJR



 Jan 13 2006



prev sibling next sibling parent reply Sean Kelly <sean f4.ca>  writes:


John Reimer wrote:

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


It isn't.  At some point Ares began requiring more Posix stuff that was 
included in Phobos and I haven't had access to enough headers to fill in 
the gaps.  If someone wants to just zip up their include directory from 
a Linux install and send it my way, I'll see about improving Posix 
support in the near future.  This should get things working on Linux, or 
at least to the state where stuff can be debugged.  That said, I suppose 
I should really create a Linux partition to play with.  Perhaps I'll ask 
around today and see if IT would have fits if I did this on my work 
laptop ;-)


Sean



 Jan 13 2006



 next sibling parent reply John Reimer <terminal.node gmail.com>  writes:


Sean Kelly wrote:

 John Reimer wrote:

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


 
 It isn't.  At some point Ares began requiring more Posix stuff that was 
 included in Phobos and I haven't had access to enough headers to fill in 
 the gaps.  If someone wants to just zip up their include directory from 
 a Linux install and send it my way, I'll see about improving Posix 
 support in the near future.  This should get things working on Linux, or 
 at least to the state where stuff can be debugged.  That said, I suppose 
 I should really create a Linux partition to play with.  Perhaps I'll ask 
 around today and see if IT would have fits if I did this on my work 
 laptop ;-)
 
 
 Sean


I could do the zip up some headers for you, but maybe you could also 
download one of the many linux-header packages that are distributed with 
linux systems -- some of these distributions have this package available 
on the internet for separate download.  I'm not sure how complete they 
are, however.  I'll try to get back to you on this.

Another option, Sean, is to use the vmplayer, available free from 
vmware.  Then all you need is to download a Linux virtual machine/drive 
from somewhere.

-JJR



 Jan 13 2006



 next sibling parent  Lars Ivar Igesund <larsivar igesund.net>  writes:


John Reimer wrote:


 Sean Kelly wrote:

 John Reimer wrote:

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


 
 It isn't.  At some point Ares began requiring more Posix stuff that was
 included in Phobos and I haven't had access to enough headers to fill in
 the gaps.  If someone wants to just zip up their include directory from
 a Linux install and send it my way, I'll see about improving Posix
 support in the near future.  This should get things working on Linux, or
 at least to the state where stuff can be debugged.  That said, I suppose
 I should really create a Linux partition to play with.  Perhaps I'll ask
 around today and see if IT would have fits if I did this on my work
 laptop ;-)
 
 
 Sean


 
 I could do the zip up some headers for you, but maybe you could also
 download one of the many linux-header packages that are distributed with
 linux systems -- some of these distributions have this package available
 on the internet for separate download.  I'm not sure how complete they
 are, however.  I'll try to get back to you on this.
 
 Another option, Sean, is to use the vmplayer, available free from
 vmware.  Then all you need is to download a Linux virtual machine/drive
 from somewhere.
 
 -JJR


Here is a KDE Suse 10 image

http://developer.kde.org/~binner/vmware/



 Jan 13 2006



prev sibling  parent  Sean Kelly <sean f4.ca>  writes:


John Reimer wrote:

 
 Another option, Sean, is to use the vmplayer, available free from 
 vmware.  Then all you need is to download a Linux virtual machine/drive 
 from somewhere.


I can't believe this never occurred to me.  And it beats the heck out of 
dual booting.  Linux, here I come!


Sean



 Jan 13 2006



prev sibling  parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


Sean Kelly wrote:

 John Reimer wrote:
 

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


 
 
 It isn't.  At some point Ares began requiring more Posix stuff that was 
 included in Phobos and I haven't had access to enough headers to fill in 
 the gaps.  If someone wants to just zip up their include directory from 
 a Linux install and send it my way, I'll see about improving Posix 
 support in the near future.  This should get things working on Linux, or 
 at least to the state where stuff can be debugged.  That said, I suppose 
 I should really create a Linux partition to play with.  Perhaps I'll ask 
 around today and see if IT would have fits if I did this on my work 
 laptop ;-)
 
 
 Sean


Zipped include directories, Linux partitions, Linux virtual machines..
Wouldn't installing Cygwin suffice? Or is the POSIX layer provided by 
Cygwin not perfect?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."



 Jan 18 2006



  parent reply Sean Kelly <sean f4.ca>  writes:


Bruno Medeiros wrote:

 Sean Kelly wrote:

 John Reimer wrote:


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



 It isn't.  At some point Ares began requiring more Posix stuff that 
 was included in Phobos and I haven't had access to enough headers to 
 fill in the gaps.  If someone wants to just zip up their include 
 directory from a Linux install and send it my way, I'll see about 
 improving Posix support in the near future.  This should get things 
 working on Linux, or at least to the state where stuff can be 
 debugged.  That said, I suppose I should really create a Linux 
 partition to play with.  Perhaps I'll ask around today and see if IT 
 would have fits if I did this on my work laptop ;-)


 
 Zipped include directories, Linux partitions, Linux virtual machines..
 Wouldn't installing Cygwin suffice? Or is the POSIX layer provided by 
 Cygwin not perfect?


The Posix standard is very vague about the contents of data structures, 
so their definition tends to vary from OS to OS.  For example, I know 
for a fact that BSD, Linux, and Interix (Windows Services for Unix) all 
use different implementations.  So there's no telling if the Cygwin 
version is compatible with Linux, etc.  I figured the easiest thing 
would be to get a Linux implementation done, since that's the most 
popular Unix OS nowadays.  I thought that meant having access to a Linux 
install, but I recently found glibc, which *may* support Linux--I have 
yet to look at the files.


Sean



 Jan 18 2006



  parent  Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


Sean Kelly wrote:

 Bruno Medeiros wrote:
 

 Sean Kelly wrote:


 John Reimer wrote:


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




 It isn't.  At some point Ares began requiring more Posix stuff that 
 was included in Phobos and I haven't had access to enough headers to 
 fill in the gaps.  If someone wants to just zip up their include 
 directory from a Linux install and send it my way, I'll see about 
 improving Posix support in the near future.  This should get things 
 working on Linux, or at least to the state where stuff can be 
 debugged.  That said, I suppose I should really create a Linux 
 partition to play with.  Perhaps I'll ask around today and see if IT 
 would have fits if I did this on my work laptop ;-)



 Zipped include directories, Linux partitions, Linux virtual machines..
 Wouldn't installing Cygwin suffice? Or is the POSIX layer provided by 
 Cygwin not perfect?


 
 
 The Posix standard is very vague about the contents of data structures, 
 so their definition tends to vary from OS to OS.  For example, I know 
 for a fact that BSD, Linux, and Interix (Windows Services for Unix) all 
 use different implementations.  So there's no telling if the Cygwin 
 version is compatible with Linux, etc.  I figured the easiest thing 
 would be to get a Linux implementation done, since that's the most 
 popular Unix OS nowadays.  I thought that meant having access to a Linux 
 install, but I recently found glibc, which *may* support Linux--I have 
 yet to look at the files.
 
 
 Sean


 From their webpage:
"What Is Cygwin?
Cygwin is a Linux-like environment for Windows. ..."
Cygwin is the Windows port of the Linux GNU tools and the Linux POSIX 
layer. So it should work the same way as Linux.
Conversely, testing with Linux proper, also doesn't garantee 
compatibility with other Unixes like BSD or Interix.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."



 Jan 25 2006



prev sibling  parent reply Sean Kelly <sean f4.ca>  writes:


John Reimer wrote:

 
 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.


For what it's worth, I've begun thinking it might be nice to add toUtfX 
functions to the global object module, as well as to Object itself. 
Thus, UTF conversions for strings should be a matter of:

"blah blah".toUtf32();
myObject.toUtf8(); // equivalent to myObject.toString();

This leaves out atoi-like functions, but I believe some of those are 
provided with Mango?


Sean



 Jan 13 2006



  parent reply John Reimer <terminal.node gmail.com>  writes:


Sean Kelly wrote:

 John Reimer wrote:

 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.


 
 For what it's worth, I've begun thinking it might be nice to add toUtfX 
 functions to the global object module, as well as to Object itself. 
 Thus, UTF conversions for strings should be a matter of:
 
 "blah blah".toUtf32();
 myObject.toUtf8(); // equivalent to myObject.toString();
 
 This leaves out atoi-like functions, but I believe some of those are 
 provided with Mango?
 
 
 Sean



This could be quite useful, as long as implementing these functions 
didn't become a hugely complicated task.  If these functions were basic 
enough, I believe they would fit more in line with the Ares theme.

Mango does indeed provide most of the more comprehensive functionality, 
so I don't think it's too critical to cover every detail with Utf style 
methods in Ares.

-JJR



 Jan 13 2006



  parent  Sean Kelly <sean f4.ca>  writes:


John Reimer wrote:

 Sean Kelly wrote:

 John Reimer wrote:

 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.


 For what it's worth, I've begun thinking it might be nice to add 
 toUtfX functions to the global object module, as well as to Object 
 itself. Thus, UTF conversions for strings should be a matter of:

 "blah blah".toUtf32();
 myObject.toUtf8(); // equivalent to myObject.toString();

 This leaves out atoi-like functions, but I believe some of those are 
 provided with Mango?


 
 This could be quite useful, as long as implementing these functions 
 didn't become a hugely complicated task.  If these functions were basic 
 enough, I believe they would fit more in line with the Ares theme.


I agree.  And if they were added to the object module I'd likely 
implement them there as well.  The implementation for these functions is 
really pretty straightforward, so adding them to the object module 
doesn't seem prohibitive assuming it seems like a good interface decision.


 Mango does indeed provide most of the more comprehensive functionality, 
 so I don't think it's too critical to cover every detail with Utf style 
 methods in Ares.


I agree.  My goal here is mostly to provide simple routines to convert 
between the built-in string types since the language offers little 
support for this natively.  But this seems like such basic functionality 
that making it globally available may be appropriate.



Sean



 Jan 13 2006



prev sibling next sibling parent reply James Dunne <james.jdunne gmail.com>  writes:


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



 Jan 13 2006



  parent reply "Kris" <fu bar.com>  writes:


"James Dunne" <james.jdunne gmail.com> wrote ...

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



I'll toss in a small anecdote:

There was a fair bit of back-and-forth on this topic when Ares first got 
started,which didn't reach a resolution (read the posts at dsource.org). 
It's actually a very hard problem to resolve in the general sense (standing 
with a foot in both camps). Thus, the Mango library went the 'encapsulated' 
route, where any static-functions and their ilk are wrapped in a struct ~ 
simply to give them an isolated namespace, and to avoid the problems that 
still crop up with phobos modules/functions bumping into each other.

When Mango started getting a slew of unicode support, the namespace 
encapsulation turned out to be a blessing ~ it was trivial to convert the 
encapsulation approach to a template instead, with char/wchar/dchar 
variations, and none of the existing usage was broken (an alias was made 
available to handle common cases). This would have been a royal mess with 
freeform C-like functions.

Take that for what it's worth, but for me there's certain value in 
explicitly managing the namespace. Heck, it can make the code more readable 
too (look at a reasonable chunk of the Mango source).

There are some who think that it requires too much typing. Well, consider 
the benefits instead (or get an IDE with code-completion <g>). There are 
others who worry about heap-usage ~ "using encapsulated functionality means 
allocating classes everywhere!". I've found that to be a complete fallacy. 
For example, the Mango http/servlet engine happily serves requests without a 
single heap allocation. There's not one C-like freeform function within that 
server ~ it uses classes (and a few encapsulating structs) throughout.

Being "old school" I still tend to think a lot about performance and 
overhead on a device ~ yet have not found issue with going the encapsulation 
route. You might consider these points when discussing one approach versus 
the other?



 Jan 13 2006



  parent  Sean Kelly <sean f4.ca>  writes:


Kris wrote:

 "James Dunne" <james.jdunne gmail.com> wrote ...

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


 
 I'll toss in a small anecdote:
 
 There was a fair bit of back-and-forth on this topic when Ares first got 
 started,which didn't reach a resolution (read the posts at dsource.org). 
 It's actually a very hard problem to resolve in the general sense (standing 
 with a foot in both camps). Thus, the Mango library went the 'encapsulated' 
 route, where any static-functions and their ilk are wrapped in a struct ~ 
 simply to give them an isolated namespace, and to avoid the problems that 
 still crop up with phobos modules/functions bumping into each other.


Aye.  Which is why I qualified my original statement with "whenever 
doing so doesn't compromise the overall design" :-).  The attempt to 
support both schemes has been one reason why I added thread-local 
storage and allow Thread to be initialized with a delegate or function 
pointer parameter, but I haven't gone much farther than that.  I suppose 
the important distinction to me is that, in general, I don't want to 
*require* derivation if composition can achieve the same goal in a 
sufficiently elegant manner.


 When Mango started getting a slew of unicode support, the namespace 
 encapsulation turned out to be a blessing ~ it was trivial to convert the 
 encapsulation approach to a template instead, with char/wchar/dchar 
 variations, and none of the existing usage was broken (an alias was made 
 available to handle common cases). This would have been a royal mess with 
 freeform C-like functions.


I occasionally wish module namespace qualifiers were required by 
default, as it seems odd to do this:

module Atomic;

struct Atomic {
     // the whole module lives here
}

But this isn't a problem I've had to deal with much yet.  Though I 
suppose that will change soon enough :-).


 Take that for what it's worth, but for me there's certain value in 
 explicitly managing the namespace. Heck, it can make the code more readable 
 too (look at a reasonable chunk of the Mango source).


I did try a sort of grouping approach with std.atomic in Ares, but the 
attempt failed miserably:

CC:\code\d>type test.d
enum msync
{
     acq,
     rel
}

struct Atomic( T )
{
     template load( msync ms ) {
         static T load( inout T val ) { return val; }
     }

     template load( msync ms ) {
         T load() { return Atomic.load!(ms)( m_val ); }
     }

     private T m_val;
}

int main()
{
     int x;
     int y = Atomic!(int).load!(msync.acq)( x );
     Atomic!(int) s;
     x = s.load!(msync.acq)();
     return 0;
}
C:\code\d>dmd test
test.d(23): template instance matches more than one template declaration
test.d(23): function expected before (), not load!(cast(msync)0) of type 
void
test.d(24): Atomic!(int) is used as a type
test.d(24): variable test.main.s voids have no value
test.d(25): template load!(msync.acq) is not a member of s
test.d(25): function expected before (), not 0 of type int

C:\code\d>

(note that the last error can be addressed by removing the empty parens 
from "x = s.load!(msync.acq)();", though it seems silly that the 
property syntax is required in this case)

I haven't tried this with DMD .143 yet.  And I suppose the current 
method is arguably more clear:

int y = atomicLoad!(int,msync.acq)( x );


Sean



 Jan 13 2006



prev sibling  parent  Chris Lajoie <ctlajoie___remove___this___ ___gmail.com>  writes:


Charles wrote:

 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.


I (kinda) agree. D caters to both styles of coding and the library 
should support both wherever possible. But (and I think this is what 
Sean is talking about) I see no reason why the free functions and the OO 
implementation can't exist in the same lib. In fact, I would even prefer 
they be in the same module.

Chris



 Jan 13 2006



prev sibling  parent  pragma <pragma_member pathlink.com>  writes:


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



 Jan 13 2006



prev sibling next sibling parent reply Chris Lajoie <ctlajoie___remove___this___ ___gmail.com>  writes:


Fredrik Olsson wrote:

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


It has happened once again in this thread. Apparently everyone here has 
ADD. We are distracted very easily ;)


 ===
 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?
 ===


I would like to see this question discussed more.


 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.


I too think it would be better work on Ares instead of Phobos (like 
Charles said, we could probably ask Walter to replace phobos with ares 
later on if it is indeed worthy). While Charles noted some other good 
reasons, my main concern is that all changes to phobos have to be 
filtered through Walter first, while you can freely contribute to Ares 
whenever you want, and all we have to do is an svn update to get the 
changes, while we would need to wait for a new release of dmd to get the 
changes to phobos.

I *may* be very much alone in this opinion:
I believe it is better to put out a lot of working code and not 
necessarily worry about a "theme" for the stdlib /initially/. Later on 
the code can be made to conform to that theme by someone else with some 
time on their hands. (here's something even more controversial) I also 
don't think it's that big of a deal, especially early on in development, 
to break old code using a module that has been restructured.

just my opinion, I hope you all don't hate me now ;)

Chris



 Jan 14 2006



  parent reply "Matthew" <matthew stlsoft.com>  writes:


 I *may* be very much alone in this opinion:
 I believe it is better to put out a lot of working code and not 
 necessarily worry about a "theme" for the stdlib /initially/. Later on the 
 code can be made to conform to that theme by someone else with some time 
 on their hands. (here's something even more controversial) I also don't 
 think it's that big of a deal, especially early on in development, to 
 break old code using a module that has been restructured.


Seconded.

Refactoring is easier (and more meaningful) than divining the future. 



 Jan 14 2006



  parent reply Sean Kelly <sean f4.ca>  writes:


Matthew wrote:

 I *may* be very much alone in this opinion:
 I believe it is better to put out a lot of working code and not 
 necessarily worry about a "theme" for the stdlib /initially/. Later on the 
 code can be made to conform to that theme by someone else with some time 
 on their hands. (here's something even more controversial) I also don't 
 think it's that big of a deal, especially early on in development, to 
 break old code using a module that has been restructured.


 
 Seconded.
 
 Refactoring is easier (and more meaningful) than divining the future. 


Agreed.  And I believe that some attempts and refactoring must take 
place during development.  However, I don't want Ares to end up feeling 
like a loose collection of useful tools, which is kind of how Phobos 
feels to me now.  If this could be avoided by establishing some design 
goals at the outset, then I'm all for it.

That said, it's difficult to hit a moving target.  If D gets implicit 
template instantiation before 1.0 it will have a significant impact on 
what I see as acceptable interface requirements--suddenly iterators 
won't seem quite so unappealing.  It may be best to do as you say and 
try something with the caveat that it may change significantly later on.


Sean



 Jan 17 2006



 next sibling parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Sean Kelly" <sean f4.ca> wrote in message
news:dqjo4k$23kj$1 digitaldaemon.com...

 Matthew wrote:

 I *may* be very much alone in this opinion:
 I believe it is better to put out a lot of working code and not
 necessarily worry about a "theme" for the stdlib /initially/. Later on






the

 code can be made to conform to that theme by someone else with some






time

 on their hands. (here's something even more controversial) I also don't
 think it's that big of a deal, especially early on in development, to
 break old code using a module that has been restructured.


 Seconded.

 Refactoring is easier (and more meaningful) than divining the future.


 Agreed.  And I believe that some attempts and refactoring must take
 place during development.  However, I don't want Ares to end up feeling
 like a loose collection of useful tools, which is kind of how Phobos
 feels to me now.  If this could be avoided by establishing some design
 goals at the outset, then I'm all for it.

 That said, it's difficult to hit a moving target.  If D gets implicit
 template instantiation before 1.0 it will have a significant impact on
 what I see as acceptable interface requirements--suddenly iterators
 won't seem quite so unappealing.  It may be best to do as you say and
 try something with the caveat that it may change significantly later on.


Well, one option is that when (if?) I "come back" to D, I can do a review of
Ares (and yes, Kris, Mango also; only two years after 'twas first promised
<g>), since I will have, in a very real way, a fresh perspective. Since
criticising other people's work is largely what I get paid to do these
days - when I'm not idly away my time writing books for pennies - it
shouldn't be too hard to apply these skills to your D libs. (I'll inevitably
be getting on my soap box about the language anyway, so might as well bundle
all the bile in one go.)

And it'd also really help ramp me back up on D ready for attacking DTL,
which I want to do before I get stuck into Extended STL, volume 2 (since I
want to talk about it in there, if it can be made to fit without seeming
like blatant advertainment).

Interested?

Matthew

P.S. If so, you can return the favour with a good savaging of STLSoft. ;-)



 Jan 17 2006



  parent  Sean Kelly <sean f4.ca>  writes:


Matthew wrote:

 
 Well, one option is that when (if?) I "come back" to D, I can do a review of
 Ares (and yes, Kris, Mango also; only two years after 'twas first promised
 <g>), since I will have, in a very real way, a fresh perspective. Since
 criticising other people's work is largely what I get paid to do these
 days - when I'm not idly away my time writing books for pennies - it
 shouldn't be too hard to apply these skills to your D libs. (I'll inevitably
 be getting on my soap box about the language anyway, so might as well bundle
 all the bile in one go.)
 
 And it'd also really help ramp me back up on D ready for attacking DTL,
 which I want to do before I get stuck into Extended STL, volume 2 (since I
 want to talk about it in there, if it can be made to fit without seeming
 like blatant advertainment).
 
 Interested?


Definitely.  Perhaps then I'll polish what's there before adding new 
stuff, as there are a few things in Ares I haven't given the once-over yet.

And it's good to hear that DTL will get some attention before too long. 
  I liked some of the initial design decisions.


 P.S. If so, you can return the favour with a good savaging of STLSoft. ;-)


*cracks knuckles* ;-)


Sean



 Jan 17 2006



prev sibling  parent reply "Regan Heath" <regan netwin.co.nz>  writes:


On Tue, 17 Jan 2006 13:38:28 -0800, Sean Kelly <sean f4.ca> wrote:

 Matthew wrote:

 I *may* be very much alone in this opinion:
 I believe it is better to put out a lot of working code and not  
 necessarily worry about a "theme" for the stdlib /initially/. Later on  
 the code can be made to conform to that theme by someone else with  
 some time on their hands. (here's something even more controversial) I  
 also don't think it's that big of a deal, especially early on in  
 development, to break old code using a module that has been  
 restructured.


  Seconded.
  Refactoring is easier (and more meaningful) than divining the future.


 Agreed.  And I believe that some attempts and refactoring must take  
 place during development.  However, I don't want Ares to end up feeling  
 like a loose collection of useful tools, which is kind of how Phobos  
 feels to me now.  If this could be avoided by establishing some design  
 goals at the outset, then I'm all for it.

 That said, it's difficult to hit a moving target.  If D gets implicit  
 template instantiation before 1.0 it will have a significant impact on  
 what I see as acceptable interface requirements--suddenly iterators  
 won't seem quite so unappealing.  It may be best to do as you say and  
 try something with the caveat that it may change significantly later on.


How about having a section in Ares for these things. If for example  
ares.std.<thing> is where the well written, well documented, well thought  
out and implemented modules go (i.e. complete except for bug fixes and  
additional improvements), then ares.tmp.<thing> could be where we put  
useful submissions that maybe are not complete, that will require later  
refactoring for whatever reason.

It would allow contributors to submit things, and people to try them on  
and see if they like or dislike them. It gives people a place to  
experiment with things which will later interact with the rest of the  
library. It can be the "workshop" area of the library, where the messy  
work gets done.

Regan



 Jan 17 2006



  parent reply Sean Kelly <sean f4.ca>  writes:


Regan Heath wrote:

 
 How about having a section in Ares for these things. If for example 
 ares.std.<thing> is where the well written, well documented, well 
 thought out and implemented modules go (i.e. complete except for bug 
 fixes and additional improvements), then ares.tmp.<thing> could be where 
 we put useful submissions that maybe are not complete, that will require 
 later refactoring for whatever reason.
 
 It would allow contributors to submit things, and people to try them on 
 and see if they like or dislike them. It gives people a place to 
 experiment with things which will later interact with the rest of the 
 library. It can be the "workshop" area of the library, where the messy 
 work gets done.


I had ares.sub reserved for submissions and ares.rev reserved for 
packages under review, however, in practice it seemed difficult to 
manage.  I've since decided (for the moment) to have submissions 
initially considered apart from Ares and then add them directly to 
ares.std, where they will undergo in-place revisions.  The scheme is 
still largely undecided however, as Ares hasn't been exactly swamped 
with submissions ;-)


Sean



 Jan 17 2006



  parent  Chris Lajoie <Chris_member pathlink.com>  writes:


In article <dqjsb6$2779$1 digitaldaemon.com>, Sean Kelly says...

I had ares.sub reserved for submissions and ares.rev reserved for 
packages under review, however, in practice it seemed difficult to 
manage.  I've since decided (for the moment) to have submissions 
initially considered apart from Ares and then add them directly to 
ares.std, where they will undergo in-place revisions.  The scheme is 
still largely undecided however, as Ares hasn't been exactly swamped 
with submissions ;-)

Sean


I feel like a hypocrite getting off the subject, but I have a template with a
set of standard array operations to do things like push/pop, cut (delete range
and return deleted values), insert, insert range, indexOf, lastIndexOf, and some
others I forgot. I am not the original author but I have made bug fixes and
added several functions. I don't have access to the file right now or I would
give the original author credit. 
a set of aliases allow you to do code like this (also with any other data type):



I considered submitting it before but I decided not to because I'm not the
original author. Also I'm not entirely sure this kind of thing should even be in
an stdlib. I've been using it in all of my small projects lately so maybe it
should ;)

Chris



 Jan 17 2006



prev sibling  parent  Lars Ivar Igesund <larsivar igesund.net>  writes:


Fredrik Olsson wrote:


 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


Hmm, I'll just resuggest Ares here, since I suppose you'll have to decide
soon. Sean seems to start including some larger changes now, which shows
both will and commitment to get a better standard lib up and going. And he
did ask for it himself.

Just another 2 øre from me.

Lars Ivar Igesund



 Jan 23 2006