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