On Mon, 26 Jul 2004 19:37:35 +0000 (UTC), Sean Kelly wrote:

> 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

That's why a team of three or four would be better. Walter to coordinate/review/design, two or three others to code, and one to document. More sets of eyes (to a point) will always work better than one set. This NG can do 'peer' reviews and acceptance testing.

This is a *big* project and is one that can be done in parallel coding.

(I'm not volunteering, just observing.)

-- 
Derek
Melbourne, Australia
27/Jul/04 9:58:51 AM

Walter wrote:

> "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.

As the original post said,

- it's impossible to deprecate a class.  Deprecating the constructors, and then tweaking them to make sure they don't call each other, is a bit of an ugly workaround.

- there's no easy way of weeding out the calls to old versions of functions

- there's no easy way of weeding out the calls to deprecated methods while using a class, which is the more important situation, rather than developing it.

OK, so maybe it isn't a showstopper by itself.  But when one finds that a class/function/whatever doesn't exist anymore, having pretended never to have been deprecated before, it could come as a nasty surprise.  Even more so when these hiddenly deprecated bits have built up over time.

<snip>
>> (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.

Maybe if I could see the middle-end code, I'd see the difficulty....

>> (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.
<snip>

An idea for the implementation logic that seems straightforward to me:

    void qwert_IN() {
        try {
            ... do contents of in block ...
        } catch (AssertError e) {
            super.qwert_IN();
        }
    }

    void qwert_OUT(ReturnType result) {
        ... do contents of out block ...
        super.qwert_OUT(result);
    }

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.

Derek Parnell wrote:


>> Sean
> 
> That's why a team of three or four would be better. Walter to coordinate/review/design, two or three others to code, and one to document. More sets of eyes (to a point) will always work better than one set. This NG can do 'peer' reviews and acceptance testing.
> 
> This is a *big* project and is one that can be done in parallel coding.
> 
> (I'm not volunteering, just observing.)
> 

I completely agree with you. A team of developers would be a great benefit to D.

We have many good developers in this newsgroup. They would help in the development efforts and accelerate it.

Bruno.

"Derek Parnell" <derek@psych.ward> wrote in message news:ce463r$1k32$1@digitaldaemon.com...
> On Mon, 26 Jul 2004 19:37:35 +0000 (UTC), Sean Kelly wrote:
>
> > 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
>
> That's why a team of three or four would be better. Walter to coordinate/review/design, two or three others to code, and one to
document.
> More sets of eyes (to a point) will always work better than one set. This NG can do 'peer' reviews and acceptance testing.
>
> This is a *big* project and is one that can be done in parallel coding.
>
> (I'm not volunteering, just observing.)
>
> --
> Derek
> Melbourne, Australia
> 27/Jul/04 9:58:51 AM

This all sounds very familiar.......

Phill

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ce30uo$10fq$1@digitaldaemon.com...
> 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 '.'?

X.Y - X is major, Y is minor. 2.101 is the 101st minor increment of version 2.

Doesn't seem particularly ambiguous.

Matthew wrote:

<snip>
> X.Y - X is major, Y is minor. 2.101 is the 101st minor increment of version 2.
> 
> Doesn't seem particularly ambiguous.

Doesn't seem particularly unambiguous.  Unless you've been brought up as a child to understand version numbers in this way, never seen any exceptions, and never heard the '.' pronounced "point".  None of these criteria apply to me.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ced43q$2da2$1@digitaldaemon.com...
> Matthew wrote:
>
> <snip>
> > X.Y - X is major, Y is minor. 2.101 is the 101st minor increment of version 2.
> >
> > Doesn't seem particularly ambiguous.
>
> Doesn't seem particularly unambiguous.  Unless you've been brought up as a child to understand version numbers in this way, never seen any exceptions, and never heard the '.' pronounced "point".  None of these criteria apply to me.

What '.' are you trying to make here? IIRC you raised this some months ago - if not you, someone else - and every response gave what is the de facto standard. Now it's raised again, with the same responses. There's a surprise.

Certainly, I'm not aware that this convention is written in stone anywhere, but one only has to look at just about any RPM file or Win32 dll to see version numbers where individual components are greater than 100.

Since much learning in IT is empirical, what exactly is the problem here?

Matthew wrote:

<snip>
> Certainly, I'm not aware that this convention is written in stone anywhere, but one only has to look at just about any RPM file or Win32 dll to see version numbers where individual components are greater than 100.
> 
> Since much learning in IT is empirical, what exactly is the problem here?

Simply that people on this 'group are implying that the structure of a
version number is a constant of nature.

OK, so some structure may be the 'norm' in some circles.  But since we both agree now that nothing is set in stone, we might as well leave it at that.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <ced43q$2da2$1@digitaldaemon.com>, Stewart Gordon says...
>
>Matthew wrote:
>
><snip>
>> X.Y - X is major, Y is minor. 2.101 is the 101st minor increment of version 2.
>> 
>> Doesn't seem particularly ambiguous.
>
>Doesn't seem particularly unambiguous.  Unless you've been brought up as a child to understand version numbers in this way, never seen any exceptions, and never heard the '.' pronounced "point".  None of these criteria apply to me.

Let's just toss the whole idea of version numbers and instead use random place names, flavors, and colors.  I'm all for the "Monaco veridian" release.


Sean