August 26, 2004
"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
> > 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.
> >
> > ====================
> > 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.

************************

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


August 26, 2004
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

August 26, 2004
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
August 26, 2004
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


August 26, 2004
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


August 26, 2004
"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!

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.


August 26, 2004
"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.



August 26, 2004
"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 ...

:-(



August 26, 2004
"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
at
> 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?



August 26, 2004
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