www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How the slow development of DMD is getting silly

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 26 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
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
Jul 26 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 26 2004
next sibling parent Derek Parnell <derek psych.ward> writes:
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.



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.

 
-- 
Derek
Melbourne, Australia
27/Jul/04 9:52:37 AM
Jul 26 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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.
Jul 29 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 30 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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?
Jul 30 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 30 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
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
Jul 30 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 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.
Jul 26 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 26 2004
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"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.
Jul 26 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jul 26 2004
next sibling parent reply Stephen Waits <steve waits.net> writes:
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
Jul 26 2004
parent reply Sean Kelly <sean f4.ca> writes:
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
Jul 26 2004
parent reply Derek Parnell <derek psych.ward> writes:
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
Jul 26 2004
next sibling parent "Bruno A. Costa" <bruno codata.com.br> writes:
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.
Jul 27 2004
prev sibling parent "Phill" <phill pacific.net.au> writes:
"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
Jul 29 2004
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 27 2004