"Ant" <Ant_member@pathlink.com> wrote in message news:bnmliv$t2c$1@digitaldaemon.com...
> Lars said: na, na, we need more talk.

I didn't say that ;) Anyway, I use both first names. I get confused unless addressed as Lars Ivar.

As to the other points. I don't really have anything against such
a project and I'd love to be part of it (although I probably don't have
time ;). I just still think that we really, really need a group that
decides a standard API. Thousands of libraries could implement it,
but the API should be standard! And this group should probably
have elected members (and Walter). Hmm, sounds interesting.

Well, count me in to stop by from time to time.

And I like Benji's suggestion: core

Lars Ivar Igesund

In article <bnmouo$11us$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>
>"Ant" <Ant_member@pathlink.com> wrote in message news:bnmliv$t2c$1@digitaldaemon.com...
>> Lars said: na, na, we need more talk.
>
>I didn't say that ;) Anyway, I use both first names. I get confused unless addressed as Lars Ivar.

(You are right. I very sorry, I see you took it lightly, but I got carry way by my joke idea and forgot how things need to be done on the internet.)

> standard API. Thousands of libraries could implement it,
>but the API should be standard!

I tried to say that before but you made it clear,
unfortunatly nobody can do it (for what ever reason).
I also think that API should be common to the target
platforms of D, then we could have extensions for
specific platforms.
Users (developers) can then decide to make a portable
aplication or take advantage of facifilites not
available on all platforms.

>And this group should probably
>have elected members (and Walter).

Walter is very important here, but lets imagine that people
realy wants to use DUI and DUI only works with the modified version,
then they will use the new version
(specialy if it doesn't break other stuff)
This is not a revolution, I think if we produce interesting thing
Walter will pay attention (not before).

>
>Lars Ivar Igesund
>

Ant

In article <bnmliv$t2c$1@digitaldaemon.com>, Ant says...
>
>In article <bnmgdl$ln7$1@digitaldaemon.com>, Charles Sanders says...
>>

>>Yes I agree this would get ugly quick.  A Phobos library group has been talked about alot but no-one has the time or the "want" to participate, but I agree with Ilya said if we get a standard group we can let Walter focus more on the compiler.

>Walter has spoken before on this.
>He said to go ahead (I'll try to find the actual posts he made later)

Here they are
(unfortunatly I was not smart enough to make a note of the URLs...)

Ant
(no wonder one should take the bull by the horns,
did you look at the other end?...)

############################################################################
Title: Re: Standard D Library
Author: "Walter" <walter@digitalmars.com>
Date: Sat, 16 Aug 2003 01:29:05 -0700

I want to encourage everyone to help out with the library. My primary focus, as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, will take on the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at.

A couple philosophical points on what I think makes a good library:

1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class, so the smallest app pulled in the entire library. Library modules should be as decoupled as practical. Calling a directory function shouldn't pull in 100k of bloat.

2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires.

3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere.

4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly.

5) Performance matters.

6) Size matters.

7) Make use of the in, out, invariant and unittest features, especially the unittest.

8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch.

9) Put your name in the code you write! You'll be famous as one of the D pioneers!

I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>.

######################################################################
Title: Re: Library for D
Author: "Walter" <walter@digitalmars.com>
Date: Sun, 28 Sep 2003 17:52:55 -0700

"Sjoerd van Leent" <Sjoerd_member@pathlink.com> wrote in message news:bl7c80$q0$1@digitaldaemon.com...
> Dear D Developers,
>
> I too think that D is a beautiful language. But the language is also very
young.
> This comes with advantages such as new techniques (GC, DBC, Threading) but
also
> with a lot of disadvantages.
>
> Well those disadvantages must be eliminated, that's why I had a thought
about
> creating a Library such as "STL" for C++ or the "java package" for JAVA
for the
> D language.
>
> I do not know about how the other D fans think about this, but I think
that the
> D language is stable enough to start implementing such a thing. Please let
met
> know how you think about this.
>
> Kind regards,
> Sjoerd van Leent

Yes, start implementing it! It also will be a great way to flush out any shortcomings in D.

In article <bnjtv0$7g2$1@digitaldaemon.com>, Y.Tomino says...
>
>Hello.
>
>I think we should use "private import" instead of "(public) import" for
>platform modules.
>"private import" can avoid conflicting identifiers, and high-level or
>cross-platform libraries should not show low-level platform modules it used.

A version for windows will need to be created
but meanwhile this can be used for linux:

@see attachment

All my D progs still compile

Ant