jcc7 wrote:
> In article <e90gih$2f7i$1@digitaldaemon.com>, Johan Granberg says...
>> jcc7 wrote:
>>>> Tony wrote:
>>>> (b) a fully documented and reasonably clean standard library
>>> I don't think we should wait that long. Phobos isn't perfect, but I think it's
>>> good enough for D 1.0.
>>>
>> I agree on that. As I see it phobos is a library using a very productive style, through sometimes their is parts missing. A good standard library dont have to bee bloated or monolithic. However I think their is a few issues in phobos that need to be fixed before 1.0, most notably string functions for wchar[] and dchar[] and standard containers (others can certainly think of other things). But I think that thees shortcomings can bee quickly solved (a few months maybe 1 or 2) once we get a feature freeze of the specification.
> 
> I just think calling it "D 1.0" is about the language specification being frozen
> (which could happen soon), and the standard library doesn't need to be fully
> fleshed out for D 1.0. It'd be nice if it were (I'm not trying discourage people
> from pointing out the problems in Phobos or offering fixes), but I think D 1.0
> needs to arrive sooner rather than later to help with D's public image. 
> 
> D has been in development for many years, and eventually people just shrug and
> say, "Yeah, D might be nice, but it's just an experiment with no major releases
> in sight".
> 
> jcc7

I agree 1.0 should be soon (as-in certainly by winter considering an RC with all features frozen and such), however I just want to point out that 5-6 years seems about right for a new language gestation so I'm not overly concerned that we're behind the curve there. For example, I think Java as we know it was conceived in early '91 and didn't really take off until early '96 or so, right? I think Walter started work on D in '01.

jcc7 wrote:
> In article <e90ai8$26ve$1@digitaldaemon.com>, Stewart Gordon says...
>> Tony wrote:
>> <snip>
>>> Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.
>>>
>>> My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made.  For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release.  Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0.
>> <snip>
>>
>> Yes, that's part of it.  AISI the prerequisites for 1.0 readiness are:
>> (a) a clear, complete and consistent spec
> 
> That'd be nice. I don't know if the current gaps in the spec are big enough to
> prevent D 1.0 though.

These certainly are big enough from where I am:

http://www.digitalmars.com/d/archives/digitalmars/D/21572.html
http://www.digitalmars.com/d/archives/26273.html

Regarding the latter, Walter has mentioned the idea of an implicit pinning system, but it has yet to make it into the spec.

>> (b) a fully documented and reasonably clean standard library
> 
> I don't think we should wait that long. Phobos isn't perfect, but I think it's
> good enough for D 1.0.
<snip>

But cleaning up some of the functions in std.socket to throw an exception rather than practising the dreaded art of using return values to indicate error conditions is something that'd better be done sooner rather than later so that it doesn't break too much existing code.

Stewart.

A few comments as an outsider and a latecomer to this thread.

I did "fall through the holes in the floor" as one poster put it, about 6 months ago, when I ran into bug 8 on my second experimental project. I made the decision at that point to wait until the language was a bit more stable, which I judged would take a few years.

Personally I have never found visibility or const to be effective debugging tools. I would be quite happy if they were entirely ignored in an initial D release, optionally allowed for documentation purposes as a replacement for e.g. /*private*/, which is the effective access control keyword we used for years in PHP 4. Truly useful debugging tools are things like meaningful compiler error messages and exceptions. Or if you want a pipedream, a segfault handler which detects NULL pointer dereferences and converts them to exceptions.

If it's impractical to fix all bugs before a release, then allow the bugs to be documented as comments on the official documentation. That way the developer can avoid surprises. I think the documentation would greatly benefit from a more open editing model: put it on a CMS, give 20 people write access, and allow unauthorised comments on the same page. I could have easily avoided bug 8 if the linker issues were noted at the bottom of the std.boxer page.

Why is Walter the only person who ever fixes bugs in the compiler? This seems to slow the whole project down. Why not move the free frontend source to a versioning system and give 10 people write access? Then Walter can produce DMD binaries from the improved multi-developer source code, and everyone else can produce GDC binaries from the same source. Maybe some interfaces would have to be cleaned up, but I would think it would be well worth the effort, in the long term.

-- Tim Starling

Tim Starling wrote:

[Good points snipped for brevity]

> 
> Why is Walter the only person who ever fixes bugs in the compiler? This seems to slow the whole project down. Why not move the free frontend source to a versioning system and give 10 people write access? Then Walter can produce DMD binaries from the improved multi-developer source code, and everyone else can produce GDC binaries from the same source. Maybe some interfaces would have to be cleaned up, but I would think it would be well worth the effort, in the long term.
> 

A compiler perhaps more than 95% of the rest of the software out there is subject to "a change in one thing could break several others". The other part is that this is not like GCC C or C++ where there is an agreed upon and very detailed language spec; the D spec is still evolving here and there as it needs to right now.

As to compiler development productivity: Walter makes a new release every month or so on average, most of them with either several bug fixes and/or a new feature or two. I don't see that from any other compiler vendor out there, OSS or not :)

> -- Tim Starling

Tony wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:e8n9mi$2flp$1@digitaldaemon.com...
> 
>>Kyle Furlong wrote:
>>
>>>*Standing Ovation*
>>
>>Yeah, that's concerned me as well. But it isn't just me trying to make
>>it perfect, everyone's got their favorite bug/feature that must get in
>>before 1.0.
>>
>>So what do you say we just call D right now *1.0* and move on? It's not
>>like D will stop undergoing improvements.
> 
> 
> I've taken the liberty of making this a new thread as the old one was getting a little long.
> 
> Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.
> 

Here's something that has been annoying me, and this week-old thread is as good a place as any to bring it up: Shared library support on Linux. I could not take D seriously if it did a "1.0" release without this. I do hate to cram more on your plate, Walter, but I consider this a more serious issue than even this import thing that has gripped the newsgroup for the past week.

Now, I am undoubtedly biased: This is a feature that makes Pyd vastly more useful. This is true to the point that many potential users of the library would dismiss it outright -- laugh in my face, even! -- if I suggested they use it when it lacks Linux (and even Mac!) support. Until D gets shared libraries on Linux, Pyd will be little more than a toy.

I have little comprehension of the technical hurdles involved here. Still, I would consider this to be a high priority for the language.

I will probably be ready to announce the first "release" of Pyd within the month. However, I cannot recommend it as a useful library without Linux support (where Python has a certain degree of popularity).

I can see D being appealing to the Python crowd. I know some regular posters in this newsgroup are into the language (back me up on this, guys), and I come from it myself. The utility of Pyd is obvious, in my mind. For CPython (the most popular implementation of the language), there are only three languages in which you can write extensions: C, C++, and now D. [1] Writing extensions in the raw C API is the very definition of tedious. C++'s Boost.Python is a nice library, but I for one am sick and tired of C++. And so I'm writing Pyd. It fills a niche, I think. D and Python! Two great tastes that taste great together!

So please, Walter, add this shared library support. It can't be /that/ hard, can it?

[1] Well, in truth you can use just about any language with C linkage, but that just means using the C API all over again. I am not aware of any libraries built on top of this except for Boost.Python and now Pyd that make the experience substantially less painful.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Kirk McDonald wrote:

> So please, Walter, add this shared library support. It can't be /that/ hard, can it?

I agree with you, not because of Pyd, but because share libraries are important. Period. When that is said, have you tried GDC for what you want to do?

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Lars Ivar Igesund wrote:
> Kirk McDonald wrote:
> 
> 
>>So please, Walter, add this shared library support. It can't be /that/
>>hard, can it?
> 
> 
> I agree with you, not because of Pyd, but because share libraries are
> important. Period. When that is said, have you tried GDC for what you want
> to do?
> 

I was under the impression that GDC didn't support shared libraries, either. No, I haven't; does it support them?

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Kirk McDonald wrote:
> Here's something that has been annoying me, and this week-old thread is as good a place as any to bring it up: Shared library support on Linux. I could not take D seriously if it did a "1.0" release without this. I do hate to cram more on your plate, Walter, but I consider this a more serious issue than even this import thing that has gripped the newsgroup for the past week.

I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done.

Will the shared libraries work with GDC?

Walter Bright wrote:
> Kirk McDonald wrote:
> 
>> Here's something that has been annoying me, and this week-old thread is as good a place as any to bring it up: Shared library support on Linux. I could not take D seriously if it did a "1.0" release without this. I do hate to cram more on your plate, Walter, but I consider this a more serious issue than even this import thing that has gripped the newsgroup for the past week.
> 
> 
> I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done.
> 
> Will the shared libraries work with GDC?

Ha! Well, at least this simple case does:

[myso2.d]
import std.stdio;

export extern(C)
void mysoprint() { writefln("Hello 'so' world!"); }

[myso.d]
export extern(C) void mysoprint();

[test.d]
import myso;

void main() {
    mysoprint();
}

$ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc
/usr/bin/ld: warning: creating a DT_TEXTREL in object.

(Not sure what that means...)

$ sudo cp libmyso.so /usr/lib
$ gdc -c test.d
$ gdc test.o -Wl,-lmyso -o test
$ ./test
Hello 'so' world!

Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here?

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Kirk McDonald wrote:
> Walter Bright wrote:
> 
>> Kirk McDonald wrote:
>>
>>> Here's something that has been annoying me, and this week-old thread is as good a place as any to bring it up: Shared library support on Linux. I could not take D seriously if it did a "1.0" release without this. I do hate to cram more on your plate, Walter, but I consider this a more serious issue than even this import thing that has gripped the newsgroup for the past week.
>>
>>
>>
>> I know about the shared library issue on Linux. And to tell the truth, I've been procrastinating on it. The big job, -fPIC, is done. I don't know how much beyond that needs to be done.
>>
>> Will the shared libraries work with GDC?
> 
> 
> Ha! Well, at least this simple case does:
> 
> [myso2.d]
> import std.stdio;
> 
> export extern(C)
> void mysoprint() { writefln("Hello 'so' world!"); }
> 
> [myso.d]
> export extern(C) void mysoprint();
> 
> [test.d]
> import myso;
> 
> void main() {
>     mysoprint();
> }
> 

Uhh, I forgot a line. :-)

$ gdc -fPIC -g -c -Wall myso2.d

> $ gdc -shared -Wl,-soname,libmyso.so -o libmyso.so myso2.o -lc
> /usr/bin/ld: warning: creating a DT_TEXTREL in object.
> 
> (Not sure what that means...)
> 
> $ sudo cp libmyso.so /usr/lib
> $ gdc -c test.d
> $ gdc test.o -Wl,-lmyso -o test
> $ ./test
> Hello 'so' world!
> 
> Sweet. However, I am a little concerned. When making DLLs on Windows, there is some boilerplate code needed to initialize and shut down the GC and do some other routine things. Is something like that needed here?
> 


-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki