"clayasaurus" <clayasaurus@gmail.com> wrote in message news:cgj3mu$2jl6$1@digitaldaemon.com...
> Ben Hinkle wrote:
> > I was thinking about that, too. But I'm not sure what needs attention. It
> > would make sense to list the stuff that the group would work on
> > Some possible items are:
> > - error/exception
> > - possible mmfile update
> > - large unicode effort (possible new toUTF impls)
> > - possible changes to streams (my updates should get in soon)
> > - phobos.html updating
> > - std.thread features (maybe - I'd like to look at some issues)
> > - program exit semantics (wait for threads, exit immediately...)
> >
> > Then there are new features and modules to add. I haven't thought about those.
> >
> > Can we do the above by modifying the code individually and sending Walter the new files (including doc changes)? It might make sense to have a newsgroup for phobos "development".
>
> I agree phobos should have its own newsgroup. I have something to add to that phobos to-do list as well.
>
> - get loader.d compiled into phobos on linux.

This typifies my concerns with it being in Walter's sole hands. I've been trying to get WindowsException into Phobos for, er, about 6 months or so, as well as updates to other libraries.

This is my main motivation for suggesting that we, as a group, take over Phobos. There's nothing Walter having final say over what gets to make it into Phobos 1.0, but at least we could be (dis)proving components at a *far* greater rate than is currently happening.

Most of my phobos-related projects have just stagnated for months in this way, such that I have little or no interest in maintaining them because I can't get my changes in.

And it's no good suggesting that everything go somewhere in etc, because some things have to be sorted *within* phobos. Exceptions/Errors are a great example of this.

> Is phobos development currently on hold until the compiler is 1.0? Just curious.

Beats me.

I'm only working on DTL these days, because that's the only thing where I'm not dependent on other things needing to go into Phobos.

"Sean Kelly" <sean@f4.ca> wrote in message news:cgif3g$29ft$1@digitaldaemon.com...
> In article <cgh9fl$1ods$1@digitaldaemon.com>, Matthew says...
> >
> >What with the various whinges, incompletenesses and general moans and groans, coupled with the motivating case of the continue Error/Exception saga, it occurs to me that it might be timely to suggest that a Standard Library Group be mooted again.
>
> At the very least, such a group could organize submissions and work out interface consistency guidelines and such.  I'm all for it, even it it means that everything just ends up living in an etc library for now.  It would give us a head start on getting D ready for release and free Walter from dealing with library requests when he's already plenty busy with language issues.  My only concern is that this be handled amicably lest this forum turn into "Animal Farm."

I don't think that's a danger. There are enough strong personalities with experience here such that anyone trying to do that would quickly be identified and slapped. If people were only interested in making others feel stupid, they'd not be on this ng, but rather somewhere on gmane.org ...

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:cgi098$236e$1@digitaldaemon.com...
> Matthew wrote:
>
> > What with the various whinges, incompletenesses and general moans and groans, coupled with the motivating case of the continue Error/Exception saga, it occurs to me that it might be timely to suggest that a Standard Library Group be mooted again.
> >
> > IMO, the bottleneck to future large-scale progress is our august and brilliant leader, so maybe it's time to cut up the pie ...
> >
> > Sure, it'll be shot down, or ignored, but at least I'll sleep straight in bed.
> >
> > Derek the Downhearted Dastard
>
> I was thinking about that, too. But I'm not sure what needs attention.

I've had several things that I've been trying to get in/changed for months on end, such that I've now pretty much given up. When you're time poor, you tend to stop spending lots of it banging your head on a wall and move on to more profitable things pretty soon.

Some of the things I've been wanting to do for 6+months require a proper sorting of the exception hierarchy, and inclusion of a Windows exception (and, presumably, a corresponding Linux exception) which provides message formatting (and lookup from system and user supplied message libraries). If memory serves, this component was written last year, but I've been unable to get Walter to put the prerequesites - that would enable a seamless integration of all of it - into Phobos all through that time. And if, as some suspect, I have an inside track to Walter, then god help the rest of you.

Basically, I don't see why Walter needs to have sole control of Phobos. I don't believe his wisdom/talent in this regard is greater than the sum of ours, and if it turns out to be so, then he can easily have a merry week or two junking stuff from Phobos before it goes 1.0. Nothing's cast in stone until 1.0, everyone's already aware of that.

> It
> would make sense to list the stuff that the group would work on
> Some possible items are:
> - error/exception
> - possible mmfile update
> - large unicode effort (possible new toUTF impls)
> - possible changes to streams (my updates should get in soon)
> - phobos.html updating
> - std.thread features (maybe - I'd like to look at some issues)
> - program exit semantics (wait for threads, exit immediately...)
>
> Then there are new features and modules to add. I haven't thought about those.
>
> Can we do the above by modifying the code individually and sending Walter the new files (including doc changes)? It might make sense to have a newsgroup for phobos "development".

No. It doesn't work. Much of the time it gets back-burner'd. Also, some things are interrelated, and I've had several unhappy instances in that regard. Look at the f-ing mess inside some of my contributed modules trying to work with some future anticipated sensible exception hierarchy.

For my part, I'm past the point of thinking it's possible for me to make future contributions to Phobos, except for DTL. (And even there, I know there'll be some issues.)

I've got a wealth of useful components in STLSoft that could be ported over, but I just can't be bothered with the hassle. In future I'm going to release them under the umbrella of "a third-party organisation", if at all.

Roll on the schism, the competing dialects, and the vendor wars. :-(

Sean Kelly wrote:
> In article <cgh9fl$1ods$1@digitaldaemon.com>, Matthew says...
> 
>>What with the various whinges, incompletenesses and general moans and groans, coupled with the motivating case of the
>>continue Error/Exception saga, it occurs to me that it might be timely to suggest that a Standard Library Group be
>>mooted again.
> 
> 
> At the very least, such a group could organize submissions and work out
> interface consistency guidelines and such.  I'm all for it, even it it means
> that everything just ends up living in an etc library for now.  It would give us
> a head start on getting D ready for release and free Walter from dealing with
> library requests when he's already plenty busy with language issues.  My only
> concern is that this be handled amicably lest this forum turn into "Animal
> Farm."
> 
> 
> Sean

Since Walter isn't keen on the idea, we might want to use the Deimos project at dsource for proposing items to add to Phobos. (In fact, some people are already doing this :)).

http://www.dsource.org/projects/deimos/

If someone complains about Phobos's std.stream being buggy, we could direct them to try Ben Hinkle's etc.stream from Deimos. When Matthew releases another version of std.mmfile, he can commit it to the SVN repository at dsource. Also, we could use the Deimos forum for Deimos-specific discussions (so that it wouldn't clutter up this newsgroup).

It won't be a secret from Walter where cool stuff is. If he wants to fix up Phobos, he can come and get it from the Deimos project.

I'm not saying it's a perfect plan, but it could be a big improvement from how we're doing it (or not doing it) right now.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

On Wed, 25 Aug 2004 03:01:01 -0700, Walter <newshound@digitalmars.com> wrote:
> "Lars Ivar Igesund" <larsivar@igesund.net> wrote in message
> news:cghck7$1pgv$1@digitaldaemon.com...
>> The point is (as it was when I made a rather elaborate suggestion 8
>> months ago) that the standard library (read 'Phobos') is not anywhere
>> near a good library product.
>>
>> My suggesgestion included a plan to create a separate project/group that
>> would design/implement/harvest code for the standard library, making a
>> good API the most important part. Then compiler vendors should either
>> provide their own implementation of the API or just include the sample
>> implementation of the group. Giving Walter at least some control was
>> part of the plan, but leave all the real work to other people.
>>
>> Some of the controversy were over whether Walter should give away any
>> control of his baby at this point, but I think he needs to to get a good
>> library bundled with his compiler.
>>
>> With all the emergent issues in the language itself, I don't see the
>> need for DSLG as pressing as I did then, but I still vote 'YES; Create
>> DSLG'.
>
> I don't think it's a disaster if the library development is decentralized
> and largely disorganized at this stage in D. I'd like anyone with what they
> believe is a good idea for a library module to go full speed ahead in
> developing it, regardless of what anyone else thinks about it.
>
> The complete ones of those should go under the etc package name.
>
> Eventually, it will become clear which are the proper core ones, and those
> will move into std with likely some refactoring to fit into a common style.
> I don't think it's so easy to tell in advance, or to know what the right
> approaches are. And as surely as the sun rises, some of the best ideas will
> probably look like crackpot ones to me at first blush. I like to build cars,
> just like I like to build compilers, but that doesn't mean I'm so good at
> driving them. (for my latest project, see www.mitymopar.com)

So how does this sound to you Walter, and anyone else listening...

What we can do right now, is take phobos and move things from it into Deimos refactoring as we go. We can also add new modules for people to try/test/evaluate.

At some stage when Walter is ready to produce/polish a standard library for distribution with the D compiler he can take a long hard look at what we have produced in deimos and include what he feels relevant/required. (which if we've done our jobs right will be the whole thing)

In the meantime we'll have something to build on, something that everyone can obtain and trial, something we can test the whole DSLG idea on.

The other advantage to this approach is things added to deimos need not ever be removed, meaning, people can rely on them while developing, some things may move to phobos, but nothing ever needs to be removed.

We can also have 2 competing implementations allowing users to trial both. Something a standard library shouldn't have.

I think this is a great idea, Deimos as it is has kinda stagnated, I think it's because there isn't any base to build on (no offence to all the contributors - myself included) we're kinda added un-related modules which while useful don't provide a base to build other modules off.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Matthew wrote:
...
> Most of my phobos-related projects have just stagnated for months in this way, such that I have little or no interest in
> maintaining them because I can't get my changes in.

Person A tried the direct approach. Walter said "No, thanks."

Two months later, person B tried the direct approach. Walter said "No, thanks."

Six months later, person C tried the direct approach. Walter said "No, thanks."

Last night, person D tried the direct approach. Walter said "No, thanks." Does anyone else see a pattern here?

I'm saying let's try the INdirect approach. Let's take all of toys to "etc" and invite Walter to come play.

> And it's no good suggesting that everything go somewhere in etc, because some things have to be sorted *within* phobos.
> Exceptions/Errors are a great example of this.

You make a good point, but I don't see it as a deal-breaker. Can't we put a work-around in etc? Or is a work-around even necessary? I've read all of the Exceptions vs. Errors threads (and it sounds like there's consensus that it should be changed), but I don't understand what problem it causes. (But let's save that for another thread.)

If it has to be perfect in the next couple hours, we'll fail. I'd settle for better in the next couple hours. Let's set up a place to meet. Walter's invited. He can come if he wants.

I've been using std.stream for a long time. Nothing against mango - I don't need a web server, I just want to process a little text file. Let's get that fix and the other improved modules in one place so that we can check them other together and call it Deimos. If Deimos eclipses Phobos, we should get some interest from Walter. Even with a DSLG, Walter would still give the final say-so before it's added to the official .zip file.

> 
>>Is phobos development currently on hold until the compiler is 1.0? Just
>>curious.
> 
> 
> Beats me.
> 
> I'm only working on DTL these days, because that's the only thing where I'm not dependent on other things needing to go
> into Phobos.

I'm just throwing ideas out here. I'm hoping we can get something to stick.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Regan Heath wrote:
> On Wed, 25 Aug 2004 03:01:01 -0700, Walter <newshound@digitalmars.com> wrote:
> 
>> "Lars Ivar Igesund" <larsivar@igesund.net> wrote in message
>> news:cghck7$1pgv$1@digitaldaemon.com...
>>
...

>>> My suggesgestion included a plan to create a separate project/group that
>>> would design/implement/harvest code for the standard library, making a
>>> good API the most important part. Then compiler vendors should either
>>> provide their own implementation of the API or just include the sample
>>> implementation of the group. Giving Walter at least some control was
>>> part of the plan, but leave all the real work to other people.
>>>
>>> Some of the controversy were over whether Walter should give away any
>>> control of his baby at this point, but I think he needs to to get a good
>>> library bundled with his compiler.
>>>
...
>>
>> I don't think it's a disaster if the library development is decentralized
>> and largely disorganized at this stage in D. I'd like anyone with what 

First, a comment for Walter:

Disorganized, yes. Decentralized, no! There's only one person at the top of the period. All power and authority with Phobos is you!

>> they
>> believe is a good idea for a library module to go full speed ahead in
>> developing it, regardless of what anyone else thinks about it.

...
> 
> 
> So how does this sound to you Walter, and anyone else listening...

I'm tired of waiting for Walter to respond to the issue of improving Phobos. I know he's busy fixing compiler bugs. It just seems that he's not even interested in accepting help.

> 
> What we can do right now, is take phobos and move things from it into Deimos refactoring as we go. We can also add new modules for people to try/test/evaluate.
> 
> At some stage when Walter is ready to produce/polish a standard library for distribution with the D compiler he can take a long hard look at what we have produced in deimos and include what he feels relevant/required. (which if we've done our jobs right will be the whole thing)
> 
> In the meantime we'll have something to build on, something that everyone can obtain and trial, something we can test the whole DSLG idea on.
> 
> The other advantage to this approach is things added to deimos need not ever be removed, meaning, people can rely on them while developing, some things may move to phobos, but nothing ever needs to be removed.

I agree big time. In fact, I just posted a similar concept (I called it "Deimos Rising") on the other end of this thread.

> 
> We can also have 2 competing implementations allowing users to trial both. Something a standard library shouldn't have.
> 
> I think this is a great idea, Deimos as it is has kinda stagnated, I think it's because there isn't any base to build on (no offence to all the contributors - myself included) we're kinda added un-related modules which while useful don't provide a base to build other modules off.

If the people who are already posting updates here could be persuaded to put them in the Deimos project at dsource, I think we could get some momentum. On this newsgroup stuff just scrolls off my screen. Ack! It doesn't matter if I save the fun stuff to my hard drive (which I do), I just can't keep up with this stuff. And I really have no interest in re-compiling my personal version of Phobos once a week. Let's all get on the same team here. :)

> 
> Regan

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Absolutely. Phobos shriveled up and shuffled off its mortal-coil rather a long time ago.

DSLG will get nowhere as long as Walter pooh-poohs the idea, so make it Deimos Standard Library Group instead. If we can form a loosely knit "committee" to lay down some overall notion of function, form, and namespace guidelines, then so much the better. It's in everyone's interests to do this effectively, wisely, and in the spirit of kindridship.

I'm tempted to suggest hoisting a few salvageable pieces from Phobos, and reorganize them into something resembling a cohesive front. At least that would provide some backward compatibility, once people had updated their imports to avoid the Phobos namespace-pollution.

What I'm saying is, subvert Phobos altogether. It will remain buried even if it continues to ship with the compiler. It's really unfortunate that Walter does not support us fixing Phobos itself, but that has been his consistent choice for a long time now. Dump it, and let's get some progression for a change!


"J C Calvarese" <jcc7@cox.net> wrote in message news:cgj7f1$2kvj$1@digitaldaemon.com...
> Sean Kelly wrote:
> > In article <cgh9fl$1ods$1@digitaldaemon.com>, Matthew says...
> >
> >>What with the various whinges, incompletenesses and general moans and
groans, coupled with the motivating case of the
> >>continue Error/Exception saga, it occurs to me that it might be timely
to suggest that a Standard Library Group be
> >>mooted again.
> >
> >
> > At the very least, such a group could organize submissions and work out interface consistency guidelines and such.  I'm all for it, even it it
means
> > that everything just ends up living in an etc library for now.  It would
give us
> > a head start on getting D ready for release and free Walter from dealing
with
> > library requests when he's already plenty busy with language issues.  My
only
> > concern is that this be handled amicably lest this forum turn into
"Animal
> > Farm."
> >
> >
> > Sean
>
> Since Walter isn't keen on the idea, we might want to use the Deimos project at dsource for proposing items to add to Phobos. (In fact, some people are already doing this :)).
>
> http://www.dsource.org/projects/deimos/
>
> If someone complains about Phobos's std.stream being buggy, we could direct them to try Ben Hinkle's etc.stream from Deimos. When Matthew releases another version of std.mmfile, he can commit it to the SVN repository at dsource. Also, we could use the Deimos forum for Deimos-specific discussions (so that it wouldn't clutter up this
newsgroup).
>
> It won't be a secret from Walter where cool stuff is. If he wants to fix up Phobos, he can come and get it from the Deimos project.
>
> I'm not saying it's a perfect plan, but it could be a big improvement from how we're doing it (or not doing it) right now.
>
> --
> Justin (a/k/a jcc7)
> http://jcc_7.tripod.com/d/

In article <opsdbappcv5a2sq9@digitalmars.com>, Regan Heath says...
>
>What we can do right now, is take phobos and move things from it into Deimos refactoring as we go. We can also add new modules for people to try/test/evaluate.

Personally, I'd rather start from nothing and pull in pieces as needed.  Phobos contains some slightly redundant functionality as well as other stuff I'm not convinced needs to be in Phobos at all.  Refactoring tends to avoid fundamental changes, and until it's been kicked around a bit I would prefer leaving the option of such changes open.

>I think this is a great idea, Deimos as it is has kinda stagnated, I think it's because there isn't any base to build on (no offence to all the contributors - myself included) we're kinda added un-related modules which while useful don't provide a base to build other modules off.

I don't really care what the forum is so long as it happens.  And I'd prefer it happen in a readily accessible location as things could only benefit from any attention Walter decides to give.  My only concern about using Demios is that it would likely mean tossing what's currently there and starting fresh, which may not be entirely fair to its current contributors.


Sean

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsdbappcv5a2sq9@digitalmars.com...
> On Wed, 25 Aug 2004 03:01:01 -0700, Walter <newshound@digitalmars.com> wrote:
> > "Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:cghck7$1pgv$1@digitaldaemon.com...
> >> The point is (as it was when I made a rather elaborate suggestion 8
> >> months ago) that the standard library (read 'Phobos') is not anywhere
> >> near a good library product.
> >>
> >> My suggesgestion included a plan to create a separate project/group that would design/implement/harvest code for the standard library, making a good API the most important part. Then compiler vendors should either provide their own implementation of the API or just include the sample implementation of the group. Giving Walter at least some control was part of the plan, but leave all the real work to other people.
> >>
> >> Some of the controversy were over whether Walter should give away any control of his baby at this point, but I think he needs to to get a good library bundled with his compiler.
> >>
> >> With all the emergent issues in the language itself, I don't see the need for DSLG as pressing as I did then, but I still vote 'YES; Create DSLG'.
> >
> > I don't think it's a disaster if the library development is decentralized
> > and largely disorganized at this stage in D. I'd like anyone with what
> > they
> > believe is a good idea for a library module to go full speed ahead in
> > developing it, regardless of what anyone else thinks about it.
> >
> > The complete ones of those should go under the etc package name.
> >
> > Eventually, it will become clear which are the proper core ones, and
> > those
> > will move into std with likely some refactoring to fit into a common
> > style.
> > I don't think it's so easy to tell in advance, or to know what the right
> > approaches are. And as surely as the sun rises, some of the best ideas
> > will
> > probably look like crackpot ones to me at first blush. I like to build
> > cars,
> > just like I like to build compilers, but that doesn't mean I'm so good at
> > driving them. (for my latest project, see www.mitymopar.com)
>
> So how does this sound to you Walter, and anyone else listening...
>
> What we can do right now, is take phobos and move things from it into Deimos refactoring as we go. We can also add new modules for people to try/test/evaluate.
>
> At some stage when Walter is ready to produce/polish a standard library for distribution with the D compiler he can take a long hard look at what we have produced in deimos and include what he feels relevant/required. (which if we've done our jobs right will be the whole thing)
>
> In the meantime we'll have something to build on, something that everyone can obtain and trial, something we can test the whole DSLG idea on.
>
> The other advantage to this approach is things added to deimos need not ever be removed, meaning, people can rely on them while developing, some things may move to phobos, but nothing ever needs to be removed.
>
> We can also have 2 competing implementations allowing users to trial both. Something a standard library shouldn't have.
>
> I think this is a great idea, Deimos as it is has kinda stagnated, I think it's because there isn't any base to build on (no offence to all the contributors - myself included) we're kinda added un-related modules which while useful don't provide a base to build other modules off.

Does your proposal require that we move package names? If not, how do we manage that? If so, are you confident that that can actually be acheived? (For example, how do we modify the exception hierarchy?)

Sounds like a nice idea in principle, but I'm skeptical it can be achieved either way