1. The current version is 0.96, which makes it look as though 1.0 is just around the corner.  Walter, I presume this is just an illusion, and that you're not going to release 1.0 before it's ready.

(a) It goes without saying that 1.0 represents a milestone, one of a first 'finished' version, ready for mainstream release.

(b) It also represents a convenient milestone for developers of applications and, more importantly, libraries.  At the moment, I don't doubt I'm one of several library developers who's been using occasional new D features/bug fixes here and there as they become available.  But when 1.0 comes out, I can see that people, including myself, would like to stabilise to its feature set.

For me, the main blocker at the moment is deprecation bugs.

http://www.digitalmars.com/drn-bin/wwwnews?D/25715

At the moment, I've no easy and reliable way of checking that my lib, and apps written using it, don't depend on deprecated features.  Even less so do others who use my lib.  As it happens, SDWF has already accumulated quite a few deprecated entities, and when SDWF 1.0 finally arrives, I anticipate removing this pre-1.0 junk altogether.  But before removing it, there should be a stage at which people can be told it's deprecated and have the time to clear their code of the old stuff.

2. faq.html
"Programmers waited years for the various pieces of C++ to get implemented after they were specified. If C++ was not so enormously popular, it's doubtful that very complex features like multiple inheritance, templates, etc., would ever have been implemented."

"The programming community is better served by multiple implementations competing on quality of code generated rather than by which corners of the spec are implemented at all."

And yet this is the agony that a few corners of the spec are currently going through:

(a) Bit array slicing and concatenation.  Except that this has actually been implemented three times over, just not hooked up.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3782

(b) Inheritance of in/out contracts.

(c) dbc.html - A feature I actually hadn't noticed before now:
"The in-out statement can also be used inside a function, for example, it can be used to check the results of a loop"

(d) Another thing I hadn't noticed before:
"The compiler can be adjusted to verify that every in and inout parameter is referenced in the in { }, and every out and inout parameter is referenced in the out { }."
I haven't been able to find this feature.  Not that I'd be inclined to bloat my code with assert (qwert == qwert) checks all over....

(e) Array arithmetic operations.  If we don't get this soon, then more and more numerical programmers are just going to give up and go back to Fortran.

These missing features are blocking quite a few of us, who could be serving the D community by testing them.

3. Not even the spec is quite finished, and I've seen little to no work in filling up the holes.  Those who've been following PendingPeeves'll know that it covers this, not just bona fide compiler bugs....

http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves

And so on....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <ce2tsr$u17$1@digitaldaemon.com>, Stewart Gordon says...
>
>1. The current version is 0.96, which makes it look as though 1.0 is just around the corner.

Stewart, you said this before, and people expaind it to you:

for DMD 0.96 means that there were 95 versions before it (public or not); it doesn't mean anything else.

(now let me read the rest of the post)

Ant

Ant wrote:

> In article <ce2tsr$u17$1@digitaldaemon.com>, Stewart Gordon says...
> 
>> 1. The current version is 0.96, which makes it look as though 1.0 is just around the corner.
> 
> Stewart, you said this before, and people expaind it to you:

And I explained back that different developers use different version numbering systems, even if version numbers take the same visual appearance under the different systems.

> for DMD 0.96 means that there were 95 versions before it (public or not);
> it doesn't mean anything else.

But is this by virtue of its decimal value, or the value of the integer notated by the digits after the '.'?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

> For me, the main blocker at the moment is deprecation bugs.
>
> http://www.digitalmars.com/drn-bin/wwwnews?D/25715
>
> At the moment, I've no easy and reliable way of checking that my lib, and apps written using it, don't depend on deprecated features.  Even less so do others who use my lib.  As it happens, SDWF has already accumulated quite a few deprecated entities, and when SDWF 1.0 finally arrives, I anticipate removing this pre-1.0 junk altogether.  But before removing it, there should be a stage at which people can be told it's deprecated and have the time to clear their code of the old stuff.

geez, if this is the main blocker for you then we shoud ship 1.0 right now. Anyone who has deprecated features should just rip them out before 1.0. There are so few users of our tools right now that right now is the easiest time to change things.

> 2. faq.html
> "Programmers waited years for the various pieces of C++ to get
> implemented after they were specified. If C++ was not so enormously
> popular, it's doubtful that very complex features like multiple
> inheritance, templates, etc., would ever have been implemented."
>
> "The programming community is better served by multiple implementations competing on quality of code generated rather than by which corners of the spec are implemented at all."
>
> And yet this is the agony that a few corners of the spec are currently going through:
>
> (a) Bit array slicing and concatenation.  Except that this has actually been implemented three times over, just not hooked up.
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3782
>
> (b) Inheritance of in/out contracts.
>
> (c) dbc.html - A feature I actually hadn't noticed before now:
> "The in-out statement can also be used inside a function, for example,
> it can be used to check the results of a loop"
>
> (d) Another thing I hadn't noticed before:
> "The compiler can be adjusted to verify that every in and inout
> parameter is referenced in the in { }, and every out and inout parameter
> is referenced in the out { }."
> I haven't been able to find this feature.  Not that I'd be inclined to
> bloat my code with assert (qwert == qwert) checks all over....
>
> (e) Array arithmetic operations.  If we don't get this soon, then more and more numerical programmers are just going to give up and go back to Fortran.
>
> These missing features are blocking quite a few of us, who could be serving the D community by testing them.

From my point of view these are not blocking me. I think Walter should fix up some of the most common the compiler crashes and stability bugs and then move back to design questions. D is young and everything is basically on the "bleeding edge".

> 3. Not even the spec is quite finished, and I've seen little to no work in filling up the holes.  Those who've been following PendingPeeves'll know that it covers this, not just bona fide compiler bugs....
>
> http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves
>
> And so on....
>
> Stewart.
>
> -- 
> My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Ben Hinkle wrote:

>> For me, the main blocker at the moment is deprecation bugs.
>> 
>> http://www.digitalmars.com/drn-bin/wwwnews?D/25715
>> 
>> At the moment, I've no easy and reliable way of checking that my lib, and apps written using it, don't depend on deprecated features.  Even less so do others who use my lib.  As it happens, SDWF has already accumulated quite a few deprecated entities, and when SDWF 1.0 finally arrives, I anticipate removing this pre-1.0 junk altogether.  But before removing it, there should be a stage at which people can be told it's deprecated and have the time to clear their code of the old stuff.
> 
> geez, if this is the main blocker for you then we shoud ship 1.0 right now.

How do you work that out?

> Anyone who has deprecated features should just rip them out before 1.0.
<snip>

By "has", do you mean uses deprecated D notations, or has the word 'deprecated' somewhere in his/her own code?  I'm talking about deprecated features of my lib.  I tend to stop using deprecated D notations as and when they become deprecated, if not before.

And do you mean before DMD 1.0, or before version 1.0 of the lib being developed?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ce358f$13qd$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
> >> For me, the main blocker at the moment is deprecation bugs.
> >>
> >> http://www.digitalmars.com/drn-bin/wwwnews?D/25715
> >>
> >> At the moment, I've no easy and reliable way of checking that my lib, and apps written using it, don't depend on deprecated features.  Even less so do others who use my lib.  As it happens, SDWF has already accumulated quite a few deprecated entities, and when SDWF 1.0 finally arrives, I anticipate removing this pre-1.0 junk altogether.  But before removing it, there should be a stage at which people can be told it's deprecated and have the time to clear their code of the old stuff.
> >
> > geez, if this is the main blocker for you then we shoud ship 1.0 right now.
>
> How do you work that out?

I don't think the issue you describe is a significant problem so if it is the most significant problem then D is in very good shape.

> > Anyone who has deprecated features should just rip them out before 1.0.
> <snip>
>
> By "has", do you mean uses deprecated D notations, or has the word 'deprecated' somewhere in his/her own code?  I'm talking about deprecated features of my lib.  I tend to stop using deprecated D notations as and when they become deprecated, if not before.
>
> And do you mean before DMD 1.0, or before version 1.0 of the lib being developed?

That sentance was confusing, you're right. I assumed 1.0 would be a good time to bump revisions of libraries that had bleeding edge issues and so in general the whole D world should strive to have no deprecated code when 1.0 comes out. It seems pointless to be straddled by a legacy made during a beta period. I consider anything I write in D to be "beta" or "unstable" until the D compiler gets out of beta.

> Stewart.
>
> -- 
> My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ce2tsr$u17$1@digitaldaemon.com...
> For me, the main blocker at the moment is deprecation bugs.
>
> http://www.digitalmars.com/drn-bin/wwwnews?D/25715

Yes, those could be improved. But I don't see really why it's a showstopper, which is why it's been on the backburner.

> At the moment, I've no easy and reliable way of checking that my lib, and apps written using it, don't depend on deprecated features.  Even less so do others who use my lib.  As it happens, SDWF has already accumulated quite a few deprecated entities, and when SDWF 1.0 finally arrives, I anticipate removing this pre-1.0 junk altogether.  But before removing it, there should be a stage at which people can be told it's deprecated and have the time to clear their code of the old stuff.
>
> 2. faq.html
> "Programmers waited years for the various pieces of C++ to get
> implemented after they were specified. If C++ was not so enormously
> popular, it's doubtful that very complex features like multiple
> inheritance, templates, etc., would ever have been implemented."
>
> "The programming community is better served by multiple implementations competing on quality of code generated rather than by which corners of the spec are implemented at all."
>
> And yet this is the agony that a few corners of the spec are currently going through:

Yes, that is a bit embarassing. :-(

>
> (a) Bit array slicing and concatenation.  Except that this has actually been implemented three times over, just not hooked up.
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3782

Hooking it up isn't as simple as it should be.

> (b) Inheritance of in/out contracts.

This isn't so easy to implement, and nobody has asked for it. So I've been deferring it in preference to more pressing items.

> (c) dbc.html - A feature I actually hadn't noticed before now:
> "The in-out statement can also be used inside a function, for example,
> it can be used to check the results of a loop"

That shouldn't be there, I forgot to remove it.

> (d) Another thing I hadn't noticed before:
> "The compiler can be adjusted to verify that every in and inout
> parameter is referenced in the in { }, and every out and inout parameter
> is referenced in the out { }."
> I haven't been able to find this feature.  Not that I'd be inclined to
> bloat my code with assert (qwert == qwert) checks all over....

I'm not sure if adding this is a good idea or not.

> (e) Array arithmetic operations.  If we don't get this soon, then more and more numerical programmers are just going to give up and go back to Fortran.

I know, I know <g>.

> These missing features are blocking quite a few of us, who could be serving the D community by testing them.
>
> 3. Not even the spec is quite finished, and I've seen little to no work in filling up the holes.  Those who've been following PendingPeeves'll know that it covers this, not just bona fide compiler bugs....
>
> http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves
>
> And so on....

There are hundreds of bugs in my list to get at. Between 3AM last night when I went to bed and 10AM this morning, there were 48 new messages in this n.g. - many of which want answers, resolution, code written, bugs fixed, etc.

Walter wrote:

> There are hundreds of bugs in my list to get at. Between 3AM last night when
> I went to bed and 10AM this morning, there were 48 new messages in this
> n.g. - many of which want answers, resolution, code written, bugs fixed,
> etc.

Not so much of a one-man project now..  How about giving someone else, someone you trust, a commit bit?

--Steve

In article <ce3jbi$1cgu$1@digitaldaemon.com>, Stephen Waits says...
>
>Walter wrote:
>
>> There are hundreds of bugs in my list to get at. Between 3AM last night when I went to bed and 10AM this morning, there were 48 new messages in this n.g. - many of which want answers, resolution, code written, bugs fixed, etc.
>
>Not so much of a one-man project now..  How about giving someone else, someone you trust, a commit bit?

Adding a person means that Walter and that person would have to coordinate their efforts.  And coordination takes time.  Walter is probably more efficient by himself than a team of two would be at this point.  Though we do have access to the source code so we can already help.  If you can post a source-level fix for the D compiler then by all means do so.


Sean

On Mon, 26 Jul 2004 14:28:55 +0100, Stewart Gordon wrote:

> Ant wrote:
> 
>> In article <ce2tsr$u17$1@digitaldaemon.com>, Stewart Gordon says...
>> 
>>> 1. The current version is 0.96, which makes it look as though 1.0 is just around the corner.
>> 
>> Stewart, you said this before, and people expaind it to you:
> 
> And I explained back that different developers use different version numbering systems, even if version numbers take the same visual appearance under the different systems.
> 
>> for DMD 0.96 means that there were 95 versions before it (public or not); it doesn't mean anything else.
> 
> But is this by virtue of its decimal value, or the value of the integer notated by the digits after the '.'?
> 
> Stewart.

I read v0.96 as "version zero, build # ninty-six". I have learnt that a '.' in this context is not a decimal point. There are many applications that have versions such as "v4.17.23" or "v7.52 build 3834".

Disregard the '.' delimiter and insert another of your own preference.
"v0-96" "v0#96" "v0@96" ...

-- 
Derek
Melbourne, Australia
27/Jul/04 9:52:37 AM