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

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

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

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):
# char[] atest = "the dog ran";
# writef("index of dog = %d", atest.indexOf("dog"));

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

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

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

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

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