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

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/

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

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

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

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

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

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

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

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