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

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

"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

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

"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

"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

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

"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

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

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

"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

"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

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

"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

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

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

"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

"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

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

"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

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

"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

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

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

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

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

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

"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

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

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

"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

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

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

"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

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

"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

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

"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

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

"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

"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

"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

"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

"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

"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

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

"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

"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

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

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

"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

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

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

"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

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

"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

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

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

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

"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

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

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

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

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

"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

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

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

D Programming

C/C++ Programming

Other

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