www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is it time for a DSLG yet?

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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
Aug 24 2004
next sibling parent "antiAlias" <fu bar.com> writes:
It was time for the DSLG a long time ago :-)

But, you have to get at least three people to co-operate first ... <G>

Okay, okay. That's not very helpful. Did you have some specific ideas (or
people) in mind Matthew?



"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cgh9fl$1ods$1 digitaldaemon.com...
 What with the various whinges, incompletenesses and general moans and

 continue Error/Exception saga, it occurs to me that it might be timely to

 mooted again.

 IMO, the bottleneck to future large-scale progress is our august and

 pie ...

 Sure, it'll be shot down, or ignored, but at least I'll sleep straight in

 Derek the Downhearted Dastard

Aug 24 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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.

I don't know what that means. I wrote a library (etc.bigint) without asking anyone's permission (although the NG as a whole discussed the usage of the namespace "etc" and the concept of "Deimos" and Walter gave approval). Then I wrote another one (etc.unicode although it looks like this is going to be replaced with some form of ICU). Others (etc.random and etc.crypto) are in-progress. Would would a Standard Library Group do? If it is designed to stop the public from writing libraries, reserving that right for a privileged few, then I wouldn't be in favor of it. But that's an "if". Arcane Jill
Aug 24 2004
next sibling parent "antiAlias" <fu bar.com> writes:
It dates from way back, Jill. You'd have to scour the old forums, but I
think it's been brought up three times now.

The general idea, as I recall, was to form a group that would act as a kind
of "clearing house" for a number of tasks. Certainly not to stop the public
writing. For example, the DSLG might try and shake some order into Phobos;
would probably be the group responsible for moving things into etc.*; and
would possibly review third party libs for the consumption of the rest of
us.

The DSLG might also attempt to co-ordinate, group, and prioritize bugs;
report fixes; act as a second-in-command. Generally try to offload some
weight from Walter, and kick D maturation into a higher gear.

Or something like that.


"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cghb4o$1p4o$1 digitaldaemon.com...
 In article <cgh9fl$1ods$1 digitaldaemon.com>, Matthew says...

What with the various whinges, incompletenesses and general moans and


continue Error/Exception saga, it occurs to me that it might be timely to


mooted again.

I don't know what that means. I wrote a library (etc.bigint) without

 anyone's permission (although the NG as a whole discussed the usage of the
 namespace "etc" and the concept of "Deimos" and Walter gave approval).

 wrote another one (etc.unicode although it looks like this is going to be
 replaced with some form of ICU). Others (etc.random and etc.crypto) are
 in-progress.

 Would would a Standard Library Group do? If it is designed to stop the

 from writing libraries, reserving that right for a privileged few, then I
 wouldn't be in favor of it. But that's an "if".

 Arcane Jill

Aug 24 2004
prev sibling next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cghb4o$1p4o$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.

I don't know what that means. I wrote a library (etc.bigint) without asking anyone's permission (although the NG as a whole discussed the usage of the namespace "etc" and the concept of "Deimos" and Walter gave approval). Then I wrote another one (etc.unicode although it looks like this is going to be replaced with some form of ICU). Others (etc.random and etc.crypto) are in-progress.

It's all in the newsgroup history. Sounds like from before your time, although we managed to refrain from being the cabal of a megalomaniacal few before you arrived, you'll be pleased to know.
 Would would a Standard Library Group do? If it is designed to stop the public
 from writing libraries, reserving that right for a privileged few, then I
 wouldn't be in favor of it. But that's an "if".

Yawn. I retract my suggestion. This is the kind of peurile shit that's making this ng unreadable.
Aug 24 2004
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Arcane Jill 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.

I don't know what that means. I wrote a library (etc.bigint) without asking anyone's permission (although the NG as a whole discussed the usage of the namespace "etc" and the concept of "Deimos" and Walter gave approval). Then I wrote another one (etc.unicode although it looks like this is going to be replaced with some form of ICU). Others (etc.random and etc.crypto) are in-progress. Would would a Standard Library Group do? If it is designed to stop the public from writing libraries, reserving that right for a privileged few, then I wouldn't be in favor of it. But that's an "if". Arcane Jill

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'. Lars Ivar Igesund
Aug 25 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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)
Aug 25 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
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/
Aug 25 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Aug 25 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:cgj98d$2lms$1 digitaldaemon.com...
 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.

That's my impression, too. I understand that he's very busy, and that from his perspective there are probably very good reasons for the situation, but I find it very demotivating. (To the degree that I've pretty much given up on Phobos. :< )
 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. :)

How will the packages be handled? How will be be able to work with stuff that *must* go into std.* ??
Aug 25 2004
next sibling parent "antiAlias" <fu bar.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote...
 How will the packages be handled? How will be be able to work with stuff

Why must anything go into std.* ? Just leave the gc, object, and exception there ... oh, you want to resolve the exception hierarchy, right?
Aug 25 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cgja94$2m1o$2 digitaldaemon.com>, Matthew says...

How will be be able to work with stuff that *must* go into std.* ??

There's nothing to stop you putting "module std.utf" (instead of "module etc.utf") at the top of a source file in Deimos, if it really /must/ be in std for some reason. Then all you have to do is link in the right order, and the linker will pick up the Deimos/std file instead of the Phobos/std file. Arcane Jill
Aug 26 2004
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cgk3k6$1nu$1 digitaldaemon.com...
 In article <cgja94$2m1o$2 digitaldaemon.com>, Matthew says...

How will be be able to work with stuff that *must* go into std.* ??

There's nothing to stop you putting "module std.utf" (instead of "module etc.utf") at the top of a source file in Deimos, if it really /must/ be in std for some reason. Then all you have to do is link in the right order, and the linker will pick up the Deimos/std file instead of the Phobos/std file.

Yup. I was auto-dumbo'd. (Just shows how weak my D brain is becoming - amazing what effect (D)motivation can have on one's faculties.) In fact, I've been doing this myself for the last year or two with my own std.* additions. Now that shows just how bad my brain's been functioning ... :-(
Aug 26 2004
prev sibling parent teqDruid <me teqdruid.com> writes:
On Thu, 26 Aug 2004 07:31:18 +0000, Arcane Jill wrote:

 In article <cgja94$2m1o$2 digitaldaemon.com>, Matthew says...
 
How will be be able to work with stuff that *must* go into std.* ??

There's nothing to stop you putting "module std.utf" (instead of "module etc.utf") at the top of a source file in Deimos, if it really /must/ be in std for some reason. Then all you have to do is link in the right order, and the linker will pick up the Deimos/std file instead of the Phobos/std file. Arcane Jill

In fact, if Deimos to meant as a total Phobos replacement, /all/ the Deimos modules should be in std. Agreed?
Aug 26 2004
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Aug 25 2004
next sibling parent reply "antiAlias" <fu bar.com> writes:
Hell, then we'll start a new one called "Phoenix" or something.


"Sean Kelly" <sean f4.ca> wrote in message
news:cgja2l$2lvl$1 digitaldaemon.com...
 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.

 contains some slightly redundant functionality as well as other stuff I'm

 convinced needs to be in Phobos at all.  Refactoring tends to avoid

 changes, and until it's been kicked around a bit I would prefer leaving

 option of such changes open.

I think this is a great idea, Deimos as it is has kinda stagnated, I


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


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

 happen in a readily accessible location as things could only benefit from

 attention Walter decides to give.  My only concern about using Demios is

 would likely mean tossing what's currently there and starting fresh, which

 not be entirely fair to its current contributors.


 Sean

Aug 25 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message
news:cgja9v$2m27$1 digitaldaemon.com...
 Hell, then we'll start a new one called "Phoenix" or something.

I like that. I vote for Phoenix!
 "Sean Kelly" <sean f4.ca> wrote in message
 news:cgja2l$2lvl$1 digitaldaemon.com...
 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.

 contains some slightly redundant functionality as well as other stuff I'm

 convinced needs to be in Phobos at all.  Refactoring tends to avoid

 changes, and until it's been kicked around a bit I would prefer leaving

 option of such changes open.

I think this is a great idea, Deimos as it is has kinda stagnated, I


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


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

 happen in a readily accessible location as things could only benefit from

 attention Walter decides to give.  My only concern about using Demios is

 would likely mean tossing what's currently there and starting fresh, which

 not be entirely fair to its current contributors.


 Sean


Aug 25 2004
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Matthew wrote:
 "antiAlias" <fu bar.com> wrote in message
news:cgja9v$2m27$1 digitaldaemon.com...
 
Hell, then we'll start a new one called "Phoenix" or something.

I like that. I vote for Phoenix!

Phoenix it should be. But I think the lib should use the std namespace (such that anything that comes in the way could be truly fixed (Exceptions/Errors, alternative GC implementations, etc)), at least for those parts linked in implicitly (the internal parts). I believe the Phobos license would allow a fork of those. phoenix namespace for the rest is probably best when API changes start to appear. And as mentioned previously, I don't want to steal anyones work (Walter's included), although I wouldn't mind Walter harvesting our results if and when they are available. Lars Ivar Igesund
Aug 26 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:cgk2r7$mv$1 digitaldaemon.com...
 Matthew wrote:
 "antiAlias" <fu bar.com> wrote in message
news:cgja9v$2m27$1 digitaldaemon.com...

Hell, then we'll start a new one called "Phoenix" or something.

I like that. I vote for Phoenix!

Phoenix it should be. But I think the lib should use the std namespace (such that anything that comes in the way could be truly fixed (Exceptions/Errors, alternative GC implementations, etc)), at least for those parts linked in implicitly (the internal parts). I believe the Phobos license would allow a fork of those. phoenix namespace for the rest is probably best when API changes start to appear.

Yes, I had a bit of a rethink here. Since we can just put phoenix.lib in our include paths, we can override any bits of std.* we want to. Hence, I say, std.* it is. Except for the bits that should be phoenix.*, that is.
 And as mentioned previously, I don't want to steal anyones work
 (Walter's included), although I wouldn't mind Walter harvesting our
 results if and when they are available.

Sure. Either this will become a new and working Phobos, or it'll be the end of D for most contributors. Kill or cure. So I would think, anyway.
Aug 26 2004
parent Ben Hinkle <bhinkle4 juno.com> writes:
Matthew wrote:

 
 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:cgk2r7$mv$1 digitaldaemon.com...
 Matthew wrote:
 "antiAlias" <fu bar.com> wrote in message
 news:cgja9v$2m27$1 digitaldaemon.com...

Hell, then we'll start a new one called "Phoenix" or something.

I like that. I vote for Phoenix!

Phoenix it should be. But I think the lib should use the std namespace (such that anything that comes in the way could be truly fixed (Exceptions/Errors, alternative GC implementations, etc)), at least for those parts linked in implicitly (the internal parts). I believe the Phobos license would allow a fork of those. phoenix namespace for the rest is probably best when API changes start to appear.

Yes, I had a bit of a rethink here. Since we can just put phoenix.lib in our include paths, we can override any bits of std.* we want to. Hence, I say, std.* it is. Except for the bits that should be phoenix.*, that is.

I tried overriding a few bits on std.* on Linux and the linker complained about having multiple definitions of what I was overriding - it didn't just pick the first definition it found. I didn't try Windows. But that doesn't mean std.* isn't the right thing to do anyway.
Aug 26 2004
prev sibling next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cgja2l$2lvl$1 digitaldaemon.com...
 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 agree. Start from scratch. I propose that we *don't* emulate the std.* structure. Let's start with d. deimos. or such. Then it can be moved over to std.* as and when appropriate.
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.

Then start with a new library. Call it something different.
Aug 25 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cgja2l$2lvl$1 digitaldaemon.com>, Sean Kelly says...

My only concern about using Demios is that it
would likely mean tossing what's currently there

Like hell it would! Deimos is open to all contributors. Phobos isn't. If you limit Deimos to a select few, then I'm afraid I'll have no choice but to start a third project which /is/ open to all contributors. Deimos's purpose is very simple. It's a place to put Phobos-wannabe code. It fits with what everybody's been saying on this thread. But if you're gonna start suggesting throwing out Int, or any other contribution, then expect some disagreement. Jill
Aug 26 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cgk3gb$1n1$1 digitaldaemon.com>, Arcane Jill says...
In article <cgja2l$2lvl$1 digitaldaemon.com>, Sean Kelly says...

My only concern about using Demios is that it
would likely mean tossing what's currently there

Like hell it would! Deimos is open to all contributors. Phobos isn't. If you limit Deimos to a select few, then I'm afraid I'll have no choice but to start a third project which /is/ open to all contributors. Deimos's purpose is very simple. It's a place to put Phobos-wannabe code. It fits with what everybody's been saying on this thread. But if you're gonna start suggesting throwing out Int, or any other contribution, then expect some disagreement.

Exactly. Which is why I suggested not using Demios as the forum. If this DSLG business is truly focused on developing a single coherent library for D then it will likely be somewhat restrictive both in what it includes and how its components are structured. This seems incompatible with the purpose of Demios which is a bit more open. By choosing a different playground it's less likely that toes will be stepped on. Sean
Aug 26 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cgl27o$fok$1 digitaldaemon.com>, Sean Kelly says...

Exactly.  Which is why I suggested not using Demios as the forum.  If this DSLG
business is truly focused on developing a single coherent library for D then it
will likely be somewhat restrictive both in what it includes and how its
components are structured.  This seems incompatible with the purpose of Demios
which is a bit more open.  By choosing a different playground it's less likely
that toes will be stepped on.

Okay, that makes complete sense to me. Clearly there must be control in a Phobos-replacement, otherwise we'll have one person changing bool to int, someone else coming along and changing it to ubyte, someone else changing it to void*, and then someone else changing back to bit all over again. That sort of thing would be counterproductive for all. In that context, then, I'm all for it. On the other hand, Deimos is a place where Phobos-wannabees can put their code in the hope that Walter may one day move it to std. It's hard to get stuff into Phobos, so I've always maintained that it should be easy to get stuff into Deimos. All you have to do is start a project and get on with it. No committees, no barriers. So you're quite right to say there are two different purposes here. And with that understanding, I support the proposal. "Phoenix" seems to be the preferred name for the new arena, so I'll add my support to that. /Presumably/ (although I may have misunderstood this) the top level namespace within Phoenix will just be "std", to take over from Phobos. Is that right? If that's so then perhaps people could develop stuff in Deimos without restraint, and then propose it to the DSLG for possible movement to Phoenix (instead of Phobos) when it reaches a certain level of maturity? Jill
Aug 26 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
In article <cgl4pn$gs4$1 digitaldaemon.com>, Arcane Jill says...
In article <cgl27o$fok$1 digitaldaemon.com>, Sean Kelly says...

So you're quite right to say there are two different purposes here. And with
that understanding, I support the proposal. "Phoenix" seems to be the preferred
name for the new arena, so I'll add my support to that. /Presumably/ (although I
may have misunderstood this) the top level namespace within Phoenix will just be
"std", to take over from Phobos. Is that right? If that's so then perhaps people
could develop stuff in Deimos without restraint, and then propose it to the DSLG
for possible movement to Phoenix (instead of Phobos) when it reaches a certain
level of maturity?

Jill

My belief is that "std" is one of the things that it can't be. If we use "std", it won't be obvious that it's something different than Phobos. When someone sees import somethingdifferent.stream; he/she can tell right away, somethingdifferent is needed. I think it should be short and self-explaining (and catchy would be nice, too). We have a forum called "Phobos Rising", but "phobosrising" is too much typing. I was thinking more along the lines of "phoenix", "newt", "newstd", etc. I started a forum topic to talk about choosing a name: http://www.dsource.org/forums/viewforum.php?f=31 jcc7
Aug 26 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <cgl4pn$gs4$1 digitaldaemon.com>, Arcane Jill says...
/Presumably/ (although I
may have misunderstood this) the top level namespace within Phoenix will just be
"std", to take over from Phobos. Is that right? If that's so then perhaps people
could develop stuff in Deimos without restraint, and then propose it to the DSLG
for possible movement to Phoenix (instead of Phobos) when it reaches a certain
level of maturity?

Exactly. Sean
Aug 26 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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
Aug 25 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 26 Aug 2004 10:03:41 +1000, Matthew <admin.hat stlsoft.dot.org> 
wrote:
 "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 


 would design/implement/harvest code for the standard library, making 


 good API the most important part. Then compiler vendors should either
 provide their own implementation of the API or just include the 


 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 


 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; 


 DSLG'.

I don't think it's a disaster if the library development is

 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 

 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 

 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?

Yes.
 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?)

For the things we cannot move, we'll just have to use phobos. i.e. Object, Exception, GC? what others are untouchable?
 Sounds like a nice idea in principle, but I'm skeptical it can be 
 achieved either way

It's only the base objects that we cannot touch, correct? As that's the case we either: - ask Walter to produce an alternate we can modify. - ask Walter to change the phobos ones. - soldier on anyway As long as the base objects we want could be slipped into place later does it matter too much at this stage? Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 25 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cghofq$202k$1 digitaldaemon.com>, Walter says...
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)

I just noticed the license plate. Nice touch :) Sean
Aug 26 2004
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cgmgmu$16ne$1 digitaldaemon.com...
 In article <cghofq$202k$1 digitaldaemon.com>, Walter says...
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)

I just noticed the license plate. Nice touch :)

Unfortunately, I've lost the right to that plate because the car has been in storage for 12 years. I have to get a new one.
Aug 28 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
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. 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".
Aug 25 2004
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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. Is phobos development currently on hold until the compiler is 1.0? Just curious.
Aug 25 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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.
Aug 25 2004
parent J C Calvarese <jcc7 cox.net> writes:
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/
Aug 25 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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. :-(
Aug 25 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Aug 25 2004
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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 ...
Aug 25 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Aug 25 2004
next sibling parent reply "antiAlias" <fu bar.com> writes:
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



continue Error/Exception saga, it occurs to me that it might be timely



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


 that everything just ends up living in an etc library for now.  It would


 a head start on getting D ready for release and free Walter from dealing


 library requests when he's already plenty busy with language issues.  My


 concern is that this be handled amicably lest this forum turn into


 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

 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/

Aug 25 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
Well, if Kris is in, maybe I should consider it. (I shall reserve my right to
flick off if it turns out into an
argument-fest, rather than a hive of cohesive industry.)

What's the next step, anyone? (My D brain's so blurred that I really can't see
a clear picture of this stuff anymore. I
am yours, willing to be guided any which way ...)

Does this mean we will be debating such library things on dsource.org?
Instructions, please.

I'm still going to work on DTL as an unallied library for the moment, ok? I
don't expect that will trouble anyone any,
just want to be clear.

For the record: if I get involved with this activity, it's a pragmatic thing
with the sole purpose of helping to get a
working (de facto) standard library in the shortest time practicable. It's not
a political statement on my part. I've
not fallen in with any particular viewpoint/faction, and I've not fallen out
with any either.

Bob Dent, With a Bent for Independent Statement

"antiAlias" <fu bar.com> wrote in message
news:cgj9it$2lql$1 digitaldaemon.com...
 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



continue Error/Exception saga, it occurs to me that it might be timely



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


 that everything just ends up living in an etc library for now.  It would


 a head start on getting D ready for release and free Walter from dealing


 library requests when he's already plenty busy with language issues.  My


 concern is that this be handled amicably lest this forum turn into


 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

 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/


Aug 25 2004
parent reply "antiAlias" <fu bar.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote ...
 Well, if Kris is in, maybe I should consider it. (I shall reserve my right

 argument-fest, rather than a hive of cohesive industry.)

===================== Like you, I'm in for as long as there's cohesive progress. The poncy politics are best left to groups like "Avalon" :-)
 What's the next step, anyone? (My D brain's so blurred that I really can't

 am yours, willing to be guided any which way ...)

===================== I think we should move to dsource.org. Perhaps Brad can set something up for us to communicate more effectively? For example, while voting is not always appropriate, it does have its value ~ there's a voting mechanism over at dsource. Antonio will hate the UI :-(
 Does this mean we will be debating such library things on dsource.org?

===================== I'd say that's a good idea
 I'm still going to work on DTL as an unallied library for the moment, ok?

 just want to be clear.

===================== As will I continue to work on Mango.
 For the record: if I get involved with this activity, it's a pragmatic

 working (de facto) standard library in the shortest time practicable. It's

 not fallen in with any particular viewpoint/faction, and I've not fallen

==================== Right; but it needs support. I believe your help will be of enormous benefit.
 Bob Dent, With a Bent for Independent Statement

 "antiAlias" <fu bar.com> wrote in message

 Absolutely. Phobos shriveled up and shuffled off its mortal-coil rather


 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


 guidelines, then so much the better. It's in everyone's interests to do


 effectively, wisely, and in the spirit of kindridship.

 I'm tempted to suggest hoisting a few salvageable pieces from Phobos,


 reorganize them into something resembling a cohesive front. At least


 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


 it continues to ship with the compiler. It's really unfortunate that


 does not support us fixing Phobos itself, but that has been his


 choice for a long time now. Dump it, and let's get some progression for


 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





 groans, coupled with the motivating case of the
continue Error/Exception saga, it occurs to me that it might be





 to suggest that a Standard Library Group be
mooted again.

At the very least, such a group could organize submissions and work




 interface consistency guidelines and such.  I'm all for it, even it




 means
 that everything just ends up living in an etc library for now.  It




 give us
 a head start on getting D ready for release and free Walter from




 with
 library requests when he's already plenty busy with language issues.




 only
 concern is that this be handled amicably lest this forum turn into


 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,



 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

 It won't be a secret from Walter where cool stuff is. If he wants to



 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/



Aug 25 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 For the record: if I get involved with this activity, it's a pragmatic

 working (de facto) standard library in the shortest time practicable. It's

 not fallen in with any particular viewpoint/faction, and I've not fallen

==================== Right; but it needs support. I believe your help will be of enormous benefit.

I think you *significantly* overestimate the level of my current/continuing influence.
Aug 25 2004
parent reply "antiAlias" <fu bar.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cgjf8g$2o6j$1 digitaldaemon.com...
 For the record: if I get involved with this activity, it's a pragmatic

 working (de facto) standard library in the shortest time practicable.



 not a political statement on my part. I've
 not fallen in with any particular viewpoint/faction, and I've not



 out with any either.

 ====================
 Right; but it needs support. I believe your help will be of enormous
 benefit.

I think you *significantly* overestimate the level of my

************************ <g> I meant with the library code and organization <g>
Aug 25 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message
news:cgjfh0$2oal$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:cgjf8g$2o6j$1 digitaldaemon.com...
 For the record: if I get involved with this activity, it's a pragmatic

 working (de facto) standard library in the shortest time practicable.



 not a political statement on my part. I've
 not fallen in with any particular viewpoint/faction, and I've not



 out with any either.

 ====================
 Right; but it needs support. I believe your help will be of enormous
 benefit.

I think you *significantly* overestimate the level of my

************************ <g> I meant with the library code and organization <g>

I am increasingly short of time and, if I'm honest, motivation. (I won't say interest, although that probably reads better, because I'm still very interested in D.) So, I'm keen to contribute, but I don't know how much effort I can spare. I intend to be an eager sheep in this, rather than a shepherd. I'll gladly shoulder a share of reviews, and maybe in return people can help me with my biggest library failing: poor/lack of documentation. I'll also help out in discussions with library cohesiveness and such. Maybe you can all help me get back my D-mojo? :-)
Aug 26 2004
prev sibling parent Ant <duitoolkit yahoo.ca> writes:
On Wed, 25 Aug 2004 18:03:20 -0700, antiAlias wrote:


I think this time is it!

 =====================
 I think we should move to dsource.org.

it's the place to be. but consider having a project on sf just for the exposure, just a redirection to the real thing.
 Antonio will hate the UI :-(

:) I think that's why I never go there... no other reason. Ant
Aug 25 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"antiAlias" <fu bar.com> wrote in message
news:cgj9it$2lql$1 digitaldaemon.com...
 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

 guidelines, then so much the better. It's in everyone's interests to do

 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

 it continues to ship with the compiler. It's really unfortunate that

 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!

It's actually quite cool with me if you fellows want to do this. I'm best at working on the core language, not the library.
Aug 26 2004
next sibling parent reply "antiAlias" <fu bar.com> writes:
"Walter" <newshound digitalmars.com> wrote.
 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!

It's actually quite cool with me if you fellows want to do this. I'm best

 working on the core language, not the library.

That's the spirit! Why didn't you say so before? dammit <g> I'd like to ask that we get some assistance from the compiler. While some ideas will trickle out over the next few days, I'd like to ask that we get better support for DLLs. It would be great to ship this thing as a DLL instead, along with the UCI-port DLL, etc, etc. What do you think?
Aug 26 2004
parent Ant <Ant_member pathlink.com> writes:
In article <cgk5gq$2gp$1 digitaldaemon.com>, antiAlias says...
"Walter" <newshound digitalmars.com> wrote.

 It's actually quite cool with me if you fellows want to do this. I'm best

 working on the core language, not the library.

That's the spirit! Why didn't you say so before?

Walter is saying that for the past year every single time some one even dreams on a better lib. Ant
Aug 26 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cgk411$1u2$1 digitaldaemon.com>, Walter says...

It's actually quite cool with me if you fellows want to do this. I'm best at
working on the core language, not the library.

Excellent. Now, call me thick if you like, but there are a couple of things I don't understand (everyone). A while back, I wrote the big integer class Int. When it was nearly finished, we had a discussion on this very newsgroup about what the project/namespace should be called, whether it could go into Phobos, etc.. The very things, in other words, that we are discussing now. The conclusion then was pretty much the same as the conclusion now - we (the D community) need a place where we can develop our own libraries, without "approval" from Walter. I didn't really care what the project would be called, but it ended up being called Deimos, because Mars has two moons, Phobos and Deimos (fear and chaos!). Then, as now, Walter gave his blessing. I also didn't care what the namespace would be called, but it ended up being called "etc.", and again Walter gave his blessing. I guess I just don't understand why this is all happening /again/. I (still) don't care whether it's called "Deimos" or "Phoenix". I never have cared. Since we already /have/ a place to put user-contributed code, those calling for Phoenix would appear to be arguing for something we already have. Unless, of course, what they're /really/ arguing for is the existence of a committee with power to do exactly what Walter does now - and that stinks of a power struggle, of which I want no part. I have a "vision" regarding my crypto software. I know where it's going, even though the end result is a long way off (and I keep getting distracted by Unicode). I do not want to have to "justify" every interface or class design to some committee. If it's there, it's because some future feature (which I might not write for six months or more) is going to need it. I don't want someone else coming along and tweaking it in a different direction, because they won't have the same "vision" - they won't necessarily see where it's /going/. The issues involved in security and crypto are mind-bogglingly subtle, and it might take me an enormous amount of effort to "explain" a decision, particularly if someone is trying to argue against it for some aesthetic principle. Now - sure - you could say: "Jill, you can be on the committee", or "Jill, the DSLG will approve your project", or whatever, and maybe I'd be placated by that. But the moment somebody says "Nope, we're not doing (for example) random numbers /that/ way, we're doing them /this/ way", you're going to leave me with no choice but to go ahead with my project outside the auspices of the DSLG. Because I'm convinced that I'm "right". So explain it to me. We need a place to develop libraries which are outside of Walter's control? Okay, we got that. We need a committee to control it? That's the part that bothers me (though, somewhat selfishly, I'll acknowledge that it would bother me less if it endorsed, rather than encumbered, my work). But I just don't get why we need a committee at all. What is with this desire for some people to control /other/ people's creative direction? Arcane Jill
Aug 26 2004
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cgk9q0$45v$1 digitaldaemon.com...
 In article <cgk411$1u2$1 digitaldaemon.com>, Walter says...

It's actually quite cool with me if you fellows want to do this. I'm best at
working on the core language, not the library.

Excellent. Now, call me thick if you like, but there are a couple of things I don't understand (everyone). A while back, I wrote the big integer class Int. When it was nearly finished, we had a discussion on this very newsgroup about what the project/namespace should be called, whether it could go into Phobos, etc.. The very things, in other words, that we are discussing now. The conclusion then was pretty much the same as the conclusion now - we (the D community) need a place where we can develop our own libraries, without "approval" from Walter. I didn't really care what the project would be called, but it ended up being called Deimos, because Mars has two moons, Phobos and Deimos (fear and chaos!). Then, as now, Walter gave his blessing. I also didn't care what the namespace would be called, but it ended up being called "etc.", and again Walter gave his blessing.

Sigh. Yet another Jill-centric post. Is this a "hug me" message? Dare I posit that this post comes across as a dummy-spit, and maybe that's a clue as to one answer to the questions you pose. As for the notion of Walter's blessing, this is surely a tenuous thing. He's a very smart, very creative guy, but he's massively overstretched. I wouldn't accord his blessing of your Deimos project with any more, or any less, significance than todays' blessing of Phoenix. If it's off his to-do list, all to the good. If it has some finite chance of future advantage, all the better. But what more significance do you think it does/should have?
 I guess I just don't understand why this is all happening /again/.

 I (still) don't care whether it's called "Deimos" or "Phoenix". I never have
 cared.

 Since we already /have/ a place to put user-contributed code, those calling for
 Phoenix would appear to be arguing for something we already have. Unless, of
 course, what they're /really/ arguing for is the existence of a committee with
 power to do exactly what Walter does now - and that stinks of a power struggle,
 of which I want no part.

One can't help but wonder whether you're a frustrated ex-punk, needing to strike out anarchically at every possible coalescence of two or more human beings into the faintest semblance of organisation, seeing mechanistic autocracy where there's only a desire for cooperation and idea-exchange. I think I've followed all elements of the rising of the Phoenix idea over the last day or so, and I don't recall a single post that had me in the slightest bit concerned about my creativity being stifled. This is hot-airing; you're just punching shadows. Maybe your forum has not been ignored deliberately? Maybe it's just that it's not on the radar of every D user. Or maybe that people like, say, Kris, have a great deal of pull that you haven't? Or maybe you've misunderstood this issue and you're reacting to something that isn't on anyone else's minds? In the end, this is an opt-in idea. If it gives you the creeps, then don't participate. I'm certainly going to reserve the right to withdraw, and even if I don't, who's gonna stop me?
 I have a "vision" regarding my crypto software. I know where it's going, even
 though the end result is a long way off (and I keep getting distracted by
 Unicode). I do not want to have to "justify" every interface or class design to
 some committee. If it's there, it's because some future feature (which I might
 not write for six months or more) is going to need it. I don't want someone
else
 coming along and tweaking it in a different direction, because they won't have
 the same "vision" - they won't necessarily see where it's /going/. The issues
 involved in security and crypto are mind-bogglingly subtle, and it might take
me
 an enormous amount of effort to "explain" a decision, particularly if someone
is
 trying to argue against it for some aesthetic principle.

 Now - sure - you could say: "Jill, you can be on the committee", or "Jill, the
 DSLG will approve your project", or whatever, and maybe I'd be placated by
that.
 But the moment somebody says "Nope, we're not doing (for example) random
numbers
 /that/ way, we're doing them /this/ way", you're going to leave me with no
 choice but to go ahead with my project outside the auspices of the DSLG.
Because
 I'm convinced that I'm "right".

Man, oh man! Is there no beginning to your modesty? Are you the reification of all distilled wisdom on number theory, such that there's not one iota anywhere else? I suspect not. How the hell do you know that your design is a global maxima, and none of the very smart people who will inhabit Phoenix might have a better idea, or perhaps ways in which small modifications to your library can improve its cohesion with other libraries, or within (the nascent, Phoenix) standard library? Here's a radical thought: I suggest only people who have a tinge of humility mixed with their arrogance should participate in Phoenix. For my part, I intend to subject many of my current (and planned) Phobos modules to Phoenix, and I invite, nay relish, criticism. I don't believe that _any_ libraries I write are perfect, and I look forward to the criticism of Phoenixers helping me to improve them. Call me perverse if you like!
 So explain it to me. We need a place to develop libraries which are outside of
 Walter's control? Okay, we got that. We need a committee to control it? That's
 the part that bothers me (though, somewhat selfishly, I'll acknowledge that it
 would bother me less if it endorsed, rather than encumbered, my work). But I
 just don't get why we need a committee at all. What is with this desire for
some
 people to control /other/ people's creative direction?

There's simply a desire on the part of some people to work together, such that their time spent on D will involve reading and writing _more_ code and _less_ NG jabber. All the rest of it seems to be only in your head. Good luck
Aug 26 2004
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <cgk9q0$45v$1 digitaldaemon.com>, Arcane Jill says...
In article <cgk411$1u2$1 digitaldaemon.com>, Walter says...

It's actually quite cool with me if you fellows want to do this. I'm best at
working on the core language, not the library.

Excellent. Now, call me thick if you like, but there are a couple of things I don't understand (everyone).

You're not thick though I might be.
A while back, I wrote the big integer class Int. When it was nearly finished, we
had a discussion on this very newsgroup about what the project/namespace should
be called, whether it could go into Phobos, etc.. The very things, in other
words, that we are discussing now.

If you haven't caught on yet, around here settled issues can become quickly unsettled. The natives are restless and we're discussing doing something different than we had been doing. I brought up the idea of "taking over" Deimos/etc and flooding it with new contributions. Someone else out with the idea of starting anew and redesigning everything. The ideas aren't exactly compatible, so I'm not sure what we're doing yet. I don't think we're going to flood Deimos because you seem to be against the idea of the idea. (I don't think we've even agreed on a plan, but I think you're already against us.)
The conclusion then was pretty much the same as the conclusion now - we (the D
community) need a place where we can develop our own libraries, without
"approval" from Walter. I didn't really care what the project would be called,
but it ended up being called Deimos, because Mars has two moons, Phobos and
Deimos (fear and chaos!). Then, as now, Walter gave his blessing. I also didn't
care what the namespace would be called, but it ended up being called "etc.",
and again Walter gave his blessing.

I guess I just don't understand why this is all happening /again/.

I (still) don't care whether it's called "Deimos" or "Phoenix". I never have
cared.

Since we already /have/ a place to put user-contributed code, those calling for
Phoenix would appear to be arguing for something we already have. Unless, of
course, what they're /really/ arguing for is the existence of a committee with
power to do exactly what Walter does now - and that stinks of a power struggle,
of which I want no part.

There's a lot of talk right now and some of that talk is about talking more. I know that's a warning sign for design-by-committee, but I think it's a false alarm. We're just venting. "Oh, the situation is so bad! We need to just burn the whole thing down! And start with a clean slate! And wash the chalkboard first!" That's my impression.
I have a "vision" regarding my crypto software. I know where it's going, even
though the end result is a long way off (and I keep getting distracted by
Unicode). I do not want to have to "justify" every interface or class design to
some committee. If it's there, it's because some future feature (which I might
not write for six months or more) is going to need it. I don't want someone else
coming along and tweaking it in a different direction, because they won't have
the same "vision" - they won't necessarily see where it's /going/. The issues
involved in security and crypto are mind-bogglingly subtle, and it might take me
an enormous amount of effort to "explain" a decision, particularly if someone is
trying to argue against it for some aesthetic principle.

But we can discuss ideas, right?
Now - sure - you could say: "Jill, you can be on the committee", or "Jill, the
DSLG will approve your project", or whatever, and maybe I'd be placated by that.
But the moment somebody says "Nope, we're not doing (for example) random numbers
/that/ way, we're doing them /this/ way", you're going to leave me with no
choice but to go ahead with my project outside the auspices of the DSLG. Because
I'm convinced that I'm "right".

Can we at least wait until we have an argument to have an argument? Now, I understand why we set up a separate "Phobos Rising" forum at dsource. http://www.dsource.org/forums/viewtopic.php?t=312 After reading your post, I'm sure we'll have different module names than "etc.*". I don't want to get in your way.
So explain it to me. We need a place to develop libraries which are outside of
Walter's control? Okay, we got that. We need a committee to control it? That's
the part that bothers me (though, somewhat selfishly, I'll acknowledge that it
would bother me less if it endorsed, rather than encumbered, my work). But I
just don't get why we need a committee at all. What is with this desire for some
people to control /other/ people's creative direction?

Arcane Jill

Don't think of it as an authoritarian committee. Think of it as a group of concerned D citizens. We'll only have the power of our coding skill. If someone doesn't want to join, we won't try to make them. If we start laying down a bunch of stuffy rules for our members and no one does anything constructive, we won't accomplish anything. But if we develop common-sense solutions and good code rather than pontificate, we could do well. jcc7
Aug 26 2004
next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <cgktp2$d5r$1 digitaldaemon.com>, J C Calvarese says...

If you haven't caught on yet, around here settled issues can become quickly
unsettled. The natives are restless and we're discussing doing something
different than we had been doing. I brought up the idea of "taking over"
Deimos/etc and flooding it with new contributions. Someone else out with the
idea of starting anew and redesigning everything. The ideas aren't exactly
compatible, so I'm not sure what we're doing yet. I don't think we're going to
flood Deimos because you seem to be against the idea of the idea.

No, I'm not against the idea. Quite the reverse actually. My understanding always was that Deimos (unlike Phobos) is open to all. Anyone can contribute. I have absolutely no problem with that.
(I don't think
we've even agreed on a plan, but I think you're already against us.)

Not exactly. I don't like Walter's playing the role of "Mr Veto" any more than anyone else. What I'm against is someone else (whether person or committee) taking over that role. What I want to see is the freedom to write and contribute code.
There's a lot of talk right now and some of that talk is about talking more. I
know that's a warning sign for design-by-committee, but I think it's a false
alarm. We're just venting. "Oh, the situation is so bad! We need to just burn
the whole thing down! And start with a clean slate! And wash the chalkboard
first!" That's my impression.

I think you're right.
But we can discuss ideas, right?

Right.
After reading your post, I'm sure we'll have different module names than
"etc.*". I don't want to get in your way.

etc. is for everyone. Or so I've always believed. I only want to be allowed to finish what I've started without its having to be approved by some offical or unofficial body. What I've started is "etc.random" and "etc.crypto". That's all.
Don't think of it as an authoritarian committee. Think of it as a group of
concerned D citizens. We'll only have the power of our coding skill. If someone
doesn't want to join, we won't try to make them. If we start laying down a bunch
of stuffy rules for our members and no one does anything constructive, we won't
accomplish anything. But if we develop common-sense solutions and good code
rather than pontificate, we could do well.

That sounds absolutely and totally agreeable. No problem with that at all. Jill
Aug 26 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:cgktp2$d5r$1 digitaldaemon.com...
 Don't think of it as an authoritarian committee. Think of it as a group of
 concerned D citizens. We'll only have the power of our coding skill. If

 doesn't want to join, we won't try to make them. If we start laying down a

 of stuffy rules for our members and no one does anything constructive, we

 accomplish anything. But if we develop common-sense solutions and good

 rather than pontificate, we could do well.

How does the Boost committee work? It seems to be rather successful.
Aug 26 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cgl5mo$hf2$1 digitaldaemon.com>, Walter says...
"J C Calvarese" <jcc7 cox.net> wrote in message
news:cgktp2$d5r$1 digitaldaemon.com...
 Don't think of it as an authoritarian committee. Think of it as a group of
 concerned D citizens. We'll only have the power of our coding skill. If

 doesn't want to join, we won't try to make them. If we start laying down a

 of stuffy rules for our members and no one does anything constructive, we

 accomplish anything. But if we develop common-sense solutions and good

 rather than pontificate, we could do well.

How does the Boost committee work? It seems to be rather successful.

Boost works in a similar way to what I was envisioning here. The committee consists of all mailing list members. Formal submissions require a list sponsor who volunteers to be the review manager (so there's no one person with more authority than any other). All list members are welcome to submit formal reviews and it is the review manager's job to sort through all the information and reject or accept the submission. Pre-submission evaluation is kind of unstructured and happens both on the list and in other forums. In our case, I had proposed that Deimos be the venue for pre-review discussion, since that's pretty much what it was intended for in the first place. The full description of the Boost process is here: http://boost.org/more/formal_review_process.htm Sean
Aug 26 2004
parent reply "antiAlias" <fu bar.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cglale$js5$1 digitaldaemon.com...
 In article <cgl5mo$hf2$1 digitaldaemon.com>, Walter says...
"J C Calvarese" <jcc7 cox.net> wrote in message
news:cgktp2$d5r$1 digitaldaemon.com...
 Don't think of it as an authoritarian committee. Think of it as a group



 concerned D citizens. We'll only have the power of our coding skill. If

 doesn't want to join, we won't try to make them. If we start laying



bunch
 of stuffy rules for our members and no one does anything constructive,



won't
 accomplish anything. But if we develop common-sense solutions and good

 rather than pontificate, we could do well.

How does the Boost committee work? It seems to be rather successful.

Boost works in a similar way to what I was envisioning here. The

 consists of all mailing list members.  Formal submissions require a list

 who volunteers to be the review manager (so there's no one person with

 authority than any other).  All list members are welcome to submit formal
 reviews and it is the review manager's job to sort through all the

 and reject or accept the submission.  Pre-submission evaluation is kind of
 unstructured and happens both on the list and in other forums.  In our

 had proposed that Deimos be the venue for pre-review discussion, since

 pretty much what it was intended for in the first place.  The full

 of the Boost process is here:

 Sean

That sounds quite good! How about taking this over to dsource? Brad has kindly set up a forum here: http://www.dsource.org/forums/viewforum.php?f=31&sid=1ddb9ad9d82f7ab9d1cfbe4 85cd722a1 FWIW, I think it's in our best interests to get this part sorted out before most anything else.
Aug 26 2004
parent Sean Kelly <sean f4.ca> writes:
In article <cglblu$kdv$1 digitaldaemon.com>, antiAlias says...
How about taking this over to dsource? Brad has kindly set up a forum here:
http://www.dsource.org/forums/viewforum.php?f=31&sid=1ddb9ad9d82f7ab9d1cfbe4
85cd722a1

FWIW, I think it's in our best interests to get this part sorted out before
most anything else.

Agreed. And done :) Sean
Aug 26 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cgk9q0$45v$1 digitaldaemon.com>, Arcane Jill says...
So explain it to me. We need a place to develop libraries which are outside of
Walter's control? Okay, we got that. We need a committee to control it? That's
the part that bothers me (though, somewhat selfishly, I'll acknowledge that it
would bother me less if it endorsed, rather than encumbered, my work). But I
just don't get why we need a committee at all. What is with this desire for some
people to control /other/ people's creative direction?

To me, it's because the end result has to follow an established set of interface standards and such if it's to feel like a standard library. I have some trepidation as well, but I think some degree of organization is necessary if this will have any hope of supplanting Phobos. But I think it should be clear that no one should try and tell another *how* to do something. Especially in their area of expertise. I think we all feel pretty much the same way as you--if this is going to work we'll need to cooperate, and if it turns into a power struggle then I suspect we'll all leave the project. Sean
Aug 26 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cgl2vu$g45$1 digitaldaemon.com>, Sean Kelly says...

To me, it's because the end result has to follow an established set of interface
standards and such if it's to feel like a standard library.  I have some
trepidation as well, but I think some degree of organization is necessary if
this will have any hope of supplanting Phobos.

Yeah. I got it now. I'm agreeing with you now.
But I think it should be clear that no one should try and tell another *how* to
do something.  Especially in their area of expertise.  I think we all feel
pretty much the same way as you--if this is going to work we'll need to
cooperate, and if it turns into a power struggle then I suspect we'll all leave
the project.

Sounds good. I think the biggest difficulty is that committees tend to consist of people who want to be on committees. I don't have a better answer though. Arcane Jill
Aug 26 2004
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cgl53j$h6u$1 digitaldaemon.com...
 Sounds good. I think the biggest difficulty is that committees tend to

 of people who want to be on committees. I don't have a better answer

I think it would be best if I wasn't on the Diemos committee, as I think it would be good for D to establish some organizational momentum that is independent. One of my big goals for D is that it reach that "tipping point" where it is self-sustaining regardless of whether I am pushing or not.
Aug 26 2004
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
In article <cgl53j$h6u$1 digitaldaemon.com>, Arcane Jill says...
Sounds good. I think the biggest difficulty is that committees tend to consist
of people who want to be on committees. I don't have a better answer though.

True enough. Though I'd like to believe that none of us are doing this because we want to be on a committe :) Sean
Aug 26 2004
prev sibling parent reply Peter Prohaska <pitrp wg78.de> writes:
On Thu, 26 Aug 2004 17:02:43 +0000, Arcane Jill wrote:

 In article <cgl2vu$g45$1 digitaldaemon.com>, Sean Kelly says...
 
To me, it's because the end result has to follow an established set of
interface standards and such if it's to feel like a standard library.  I
have some trepidation as well, but I think some degree of organization
is necessary if this will have any hope of supplanting Phobos.

Yeah. I got it now. I'm agreeing with you now.

Agreed. One big problem with C and C++ always goes like: "where is my library" or "oops, which implementation are you using then?... and which one is broken?... ok, here is a shell script so we support both now." Part of the reason for the spreading of languages like python or php etc. IMO is that there is one central place where you will always find the reference standard library (in working code). This makes it quite clear that every other implementation that is not compatible is to be considered wrong. When people talk about posix on the other hand, you cannot simply point someone to "http://this-is-posix.org/source/download/" and the problem is solved. So even if the reference implementation is horribly broken, you at least know whom to address.
But I think it should be clear that no one should try and tell another
*how* to do something.  Especially in their area of expertise.  I think
we all feel pretty much the same way as you--if this is going to work
we'll need to cooperate, and if it turns into a power struggle then I
suspect we'll all leave the project.

Sounds good. I think the biggest difficulty is that committees tend to consist of people who want to be on committees. I don't have a better answer though.

Well... there does not necessarily need to be _one_ big committee that decides about everything. The concept of python's special interest groups feels very useful and seems to work. I don't know about the details though. cheers, peter.
Aug 26 2004
parent reply Deja Augustine <deja scratch-ware.net> writes:
While this is a long post describing a relatively detailed idea, it is 
my strong feelings that D has a really great community.  I think that a 
standard library should really be a community-wide undertaking.  A 
central committee is needed to oversee the process (as you'll see below) 
but I think that the community as a whole could do a lot to make a 
relatively comprehensive standard library a reality in a relatively 
short period of time.

This may have already been mentioned (I didn't feel like sifting through 
384 new posts since I last had internet access in order to try to read 
all of the ones pertainant to this topic), but...

I think that a nice idea might be to form a small "committee" of say 2-4 
people, tops, who come up with a library interface standard: a specific 
set of codified rules for anything to become a part of the standard 
library.  Have everything from package/module nomenclature to the 
notation of classes, methods and members (CONSTANT, ThisIsAMethod, 
thisIsAMember, STDThisIsAClass, thisisalocal, etc...).

Once the library standard has been codified, then it should be posted to 
the NG for comments and criticism.  After a period of, say, one week of 
discussion, a final set of rules would be drawn up.

Once the rules are in place, the "committee" should post a list of all 
of the various library features and "contract" out those tasks to people 
such that the list could look something like:

Feature             - Author         - Date Started - Last Update -  %
...
Regular Expressions - Deja Augustine - 08/26/2004   - 08/26/2004  -  0%
File Streams        - ...            - ...          - ...         - ...
...


So that anyone can easily see the current state of the standard library.

Furthermore, if you let anyone help but permit them to only "contract" 
one item, it will prevent people from doing redundant work, but will let 
people more easily get in touch with the contracted coder to help out. 
Also, if a while goes by without any progress, that can easily be seen 
by the last update.

People could also volunteer to pre-check library code at any updates to 
see if it follows the standards with final verification being done by 
the "committee" once it reaches 100% completion.

-Deja
Aug 26 2004
parent pragma <pragma_member pathlink.com> writes:
Deja, thank you for your input.  If you don't mind, I'm going to cross-post your
suggestions to the current open call for suggestions on DSource

http://www.dsource.org/forums/viewtopic.php?t=316

Thanks!

- Pragma

In article <cgm67t$11vk$1 digitaldaemon.com>, Deja Augustine says...
While this is a long post describing a relatively detailed idea, it is 
my strong feelings that D has a really great community.  I think that a 
standard library should really be a community-wide undertaking.  A 
central committee is needed to oversee the process (as you'll see below) 
but I think that the community as a whole could do a lot to make a 
relatively comprehensive standard library a reality in a relatively 
short period of time.

This may have already been mentioned (I didn't feel like sifting through 
384 new posts since I last had internet access in order to try to read 
all of the ones pertainant to this topic), but...

I think that a nice idea might be to form a small "committee" of say 2-4 
people, tops, who come up with a library interface standard: a specific 
set of codified rules for anything to become a part of the standard 
library.  Have everything from package/module nomenclature to the 
notation of classes, methods and members (CONSTANT, ThisIsAMethod, 
thisIsAMember, STDThisIsAClass, thisisalocal, etc...).

Once the library standard has been codified, then it should be posted to 
the NG for comments and criticism.  After a period of, say, one week of 
discussion, a final set of rules would be drawn up.

Once the rules are in place, the "committee" should post a list of all 
of the various library features and "contract" out those tasks to people 
such that the list could look something like:

Feature             - Author         - Date Started - Last Update -  %
...
Regular Expressions - Deja Augustine - 08/26/2004   - 08/26/2004  -  0%
File Streams        - ...            - ...          - ...         - ...
...


So that anyone can easily see the current state of the standard library.

Furthermore, if you let anyone help but permit them to only "contract" 
one item, it will prevent people from doing redundant work, but will let 
people more easily get in touch with the contracted coder to help out. 
Also, if a while goes by without any progress, that can easily be seen 
by the last update.

People could also volunteer to pre-check library code at any updates to 
see if it follows the standards with final verification being done by 
the "committee" once it reaches 100% completion.

-Deja

Aug 26 2004
prev sibling next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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



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.

Ok, sounds like a plan. Maybe it's not perfect, but it's a quantum leap from where we are now, I guess.
Aug 25 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
Hi All,
from what I've read over the last few days, there seems to be a bit of
confusion about a whole range of things. I've tried to distil the ideas and
I've come up with this ...

*** There are at least four categories of publicly available libraries:
(a) The "official" standard library that is packaged and shipped with DMD.
Currently the name of this library is "Phobos"
(b) An "unofficial" standard library that could be used to replace the
"official" standard one. We don't have any of these yet, as far as I know.
(c) A library (module) that could potentially be added to the standard
library. Currently a lot of these are a part of the "Deimos" project, but
there may be others that are drifting about.
(d) A library module/library that is not intended to be added to the
standard library. 

*** The current evolutionary stage of DMD is that Phobos needs to be
reviewed and probably a lot of it rewritten.

*** Walter would rather that the work of producing the next generation of
official standard library was done by others, however as it would be
distributed with his DMD, Walter would need some right to control it's
content.

*** A new project, possibly called "Phoenix", is about to be undertaken to
review Phobos and build the next generation of the DMD standard library. 

*** There is a concern that committees may act unreasonably at times.

*** There is a concern that contributors may act unreasonably at times.

If Phoenix gets going, it will need a written set of guidelines and visions
so that contributors will know where they stand and what would be expected
of their work. There will need to be a "disputes" process so that everyone
involved can seek justice and resolution. 

I suspect that peer review will be the most effective way to control the
quality and direction of contributions. 

And these are only the start of many real issues that would have to be
dealt with in such a large project.

-- 
Derek
Melbourne, Australia
27/Aug/04 12:13:34 PM
Aug 26 2004
parent pragma <pragma_member pathlink.com> writes:
Derek, much like I did with Deja's post, I'm going to cross post your
suggestions as well since this is as comprehensive a summary as we've had yet.

http://www.dsource.org/forums/viewtopic.php?t=316

Many thanks,
- Pragma

In article <cgm6vd$124q$1 digitaldaemon.com>, Derek Parnell says...
Hi All,
from what I've read over the last few days, there seems to be a bit of
confusion about a whole range of things. I've tried to distil the ideas and
I've come up with this ...

*** There are at least four categories of publicly available libraries:
(a) The "official" standard library that is packaged and shipped with DMD.
Currently the name of this library is "Phobos"
(b) An "unofficial" standard library that could be used to replace the
"official" standard one. We don't have any of these yet, as far as I know.
(c) A library (module) that could potentially be added to the standard
library. Currently a lot of these are a part of the "Deimos" project, but
there may be others that are drifting about.
(d) A library module/library that is not intended to be added to the
standard library. 

*** The current evolutionary stage of DMD is that Phobos needs to be
reviewed and probably a lot of it rewritten.

*** Walter would rather that the work of producing the next generation of
official standard library was done by others, however as it would be
distributed with his DMD, Walter would need some right to control it's
content.

*** A new project, possibly called "Phoenix", is about to be undertaken to
review Phobos and build the next generation of the DMD standard library. 

*** There is a concern that committees may act unreasonably at times.

*** There is a concern that contributors may act unreasonably at times.

If Phoenix gets going, it will need a written set of guidelines and visions
so that contributors will know where they stand and what would be expected
of their work. There will need to be a "disputes" process so that everyone
involved can seek justice and resolution. 

I suspect that peer review will be the most effective way to control the
quality and direction of contributions. 

And these are only the start of many real issues that would have to be
dealt with in such a large project.

-- 
Derek
Melbourne, Australia
27/Aug/04 12:13:34 PM

Aug 26 2004