• Dave (4/4) Aug 18 2004 Attached is a log when compiled with:
• Dave (4/11) Aug 18 2004 Oops:
• Walter (5/9) Aug 18 2004 Unfortunately, a log doesn't do me much good. Please reduce it to the
• Dave (10/24) Aug 19 2004 I was able to recreate the same crash (at least the -v log is the same) ...
• Dave (20/52) Aug 19 2004 Dave wrote:
• Matthew (7/11) Aug 18 2004 Yikes!
• antiAlias (22/25) Aug 18 2004 You're not alone with that problem ... several library developers have b...
• Matthew (16/41) Aug 18 2004 Don't apologise. I think your concerns are real. I don't know what the a...
• Andy Friesen (16/74) Aug 18 2004 What I would really like to see is a working backend that can be
• J C Calvarese (9/29) Aug 18 2004 Great idea! Actually, this is the kind of like the inverse of Walter's
• Ilya Minkov (8/15) Aug 19 2004 I think it gets better the better one knows it, and only if one is able
• Walter (16/23) Aug 19 2004 project
• antiAlias (11/14) Aug 19 2004 Have they really? More power to you if that's really the case (all the D...
• Walter (16/32) Aug 19 2004 The ones reported have been, except for struct fr's.
• Matthew (5/39) Aug 19 2004 Wouldn't one smart move at this point be to appoint a panel of NG modera...
• Walter (10/14) Aug 19 2004 moderators?
• Matthew (8/23) Aug 19 2004 I understand that, but there has to be a finite limit to the volume you ...
• Dave (19/35) Aug 19 2004 How about something along these lines until Walter is ready to add those
• Matthew (7/42) Aug 19 2004 Sorry, I must be thick. Can you rephrase?
• Carlos Santander B. (16/16) Aug 19 2004 "Matthew" escribió en el mensaje
• Dave (4/8) Aug 19 2004 Exactly.
• Matthew (4/18) Aug 19 2004 You mean an intermediate release to a "group" of "important" library wri...
• Walter (6/20) Aug 20 2004 is
• Carlos Santander B. (7/7) Aug 20 2004 "Walter" escribió en el mensaje
• Dave (13/28) Aug 19 2004 Wow, my post was really cryptic. Sorry..
• Matthew (11/38) Aug 19 2004 Ah. Perfect. (And inordinately better expl. btw. My hats off to you. Nor...
• antiAlias (23/66) Aug 19 2004 This is all fine and well, but addresses backwards-compatibility only. W...
• Matthew (2/79) Aug 19 2004
• Walter (5/10) Aug 20 2004 it
• antiAlias (30/31) Aug 20 2004 - The ongoing Interface issues (now described as Interface MI issues)
• Walter (8/39) Aug 20 2004 Ok, I'll check them out.
• Matthew (5/56) Aug 20 2004 Can either/both of you report on the results of resolution of all (but t...
• Juanjo =?ISO-8859-15?Q?=C1lvarez?= (7/10) Aug 20 2004 This showns that what is really needed here is a bug tracking software f...
• antiAlias (5/15) Aug 20 2004 An alternative might be to use the bug-tracking that's being put into pl...
• Walter (5/7) Aug 20 2004 interface contract stuff. If/when this gets fixed,
• Matthew (3/10) Aug 20 2004 Alas, I don't have much bandwidth left, so I thought I could do a last m...
• antiAlias (10/17) Aug 20 2004 Surely there must be some mistake? I believe the name of the relevant th...
• antiAlias (12/63) Aug 22 2004 "v0.99: Fixed MI bug with interface vtbl dispatch."
• antiAlias (27/93) Aug 22 2004 more info:
• Walter (1/1) Aug 22 2004 Can you post a complete example, please?
• antiAlias (4/5) Aug 22 2004 I would, but Mango is a bit too big
• Walter (4/12) Aug 24 2004 If it's too big for you, what hope have I, who is totally unfamiliar wit...
• antiAlias (17/34) Aug 24 2004 I offered to guide you; doesn't that help? There is a small example prog...
• Walter (17/32) Aug 24 2004 program
• antiAlias (8/59) Aug 24 2004 say
• Walter (10/71) Aug 24 2004 Message numbers of the specific ones would also be most helpful.
• antiAlias (27/105) Aug 27 2004 No problem ... here's a few:
• Walter (14/121) Aug 28 2004 Thanks!
• Walter (3/4) Aug 20 2004 Sounds like just making a 'beta' available, like I do for DMC++.
• Andy Friesen (5/6) Aug 19 2004 It all builds now, actually.
• Ben Hinkle (14/18) Aug 19 2004 I just downloaded DWT and tried compiling it. It didn't end up working

Dave <Dave_member pathlink.com> writes:

Attached is a log when compiled with:

dmd -c -v -I../.. test/list_test.d >dmd_list_test.log 2>&1

The rest of DTL v0.1.1 compiles and the test executables work fine on this
platform.

Dave <Dave_member pathlink.com> writes:

Dave wrote:

 
 Attached is a log when compiled with:
 
 dmd -c -v -I../.. test/list_test.d >dmd_list_test.log 2>&1
 
 The rest of DTL v0.1.1 compiles and the test executables work fine on this
 platform.

Oops:

Fedora Core 1, 2.4.22-1.2174.nptl
dmd v0.98

"Walter" <newshound digitalmars.com> writes:

Unfortunately, a log doesn't do me much good. Please reduce it to the
minimum source that causes the problem and submit it, then I can get it
fixed. Thanks!

"Dave" <Dave_member pathlink.com> wrote in message
news:cg0g2m$vqk$1 digitaldaemon.com...
 Attached is a log when compiled with:

 dmd -c -v -I../.. test/list_test.d >dmd_list_test.log 2>&1

 The rest of DTL v0.1.1 compiles and the test executables work fine on this
 platform.

Dave <Dave_member pathlink.com> writes:

I was able to recreate the same crash (at least the -v log is the same) by
compiling a "program" with these two lines:

import std.dtl.containers.list;
List!(int) l;

Commenting out all of the TransformedRange(...) and MatchedRange(...)
functions in list.d enabled the compiler to finish.

Search for /*** and ***/ in the attached.

Thanks,

- Dave

Walter wrote:

 Unfortunately, a log doesn't do me much good. Please reduce it to the
 minimum source that causes the problem and submit it, then I can get it
 fixed. Thanks!
 
 "Dave" <Dave_member pathlink.com> wrote in message
 news:cg0g2m$vqk$1 digitaldaemon.com...
 Attached is a log when compiled with:

 dmd -c -v -I../.. test/list_test.d >dmd_list_test.log 2>&1

 The rest of DTL v0.1.1 compiles and the test executables work fine on
 this platform.

Dave <Dave_member pathlink.com> writes:

Dave wrote:

To clarify, the -v log with the program stub below is the same as the
original from right after 'main' on down, with the exception that now
'this' is logged right after the last 'opCall':

generating code for function 'this'
generating code for function 'opCall'
generating code for function 'this'
<end>

original:
generating code for function 'this'
generating code for function 'opCall'
<end>

containers/list.o is generated fine so I believe the problem starts when
code gen hits the TransformedRange! constructor in range/filters.d when
that constructor needs to be generated, or right after.

It doesn't look like I can take it any further w/o commenting out large
chunks of code starting in filter.d, which of course would defeat the
purpose of narrowing it down.

dmd v0.98 on Windows seems to work fine, if that is any help.

- Dave

 
 I was able to recreate the same crash (at least the -v log is the same) by
 compiling a "program" with these two lines:
 
 import std.dtl.containers.list;
 List!(int) l;
 
 Commenting out all of the TransformedRange(...) and MatchedRange(...)
 functions in list.d enabled the compiler to finish.
 
 Search for /*** and ***/ in the attached.
 
 Thanks,
 
 - Dave
 
 Walter wrote:
 
 Unfortunately, a log doesn't do me much good. Please reduce it to the
 minimum source that causes the problem and submit it, then I can get it
 fixed. Thanks!
 
 "Dave" <Dave_member pathlink.com> wrote in message
 news:cg0g2m$vqk$1 digitaldaemon.com...
 Attached is a log when compiled with:

 dmd -c -v -I../.. test/list_test.d >dmd_list_test.log 2>&1

 The rest of DTL v0.1.1 compiles and the test executables work fine on
 this platform.

"Matthew" <admin.hat stlsoft.dot.org> writes:

Yikes!

Although it's hardly surprising. The whole development of DTL seems to be short
bursts between waiting for language
facilities and/or compiler/linker fixes.

Such is our lot when we're ploughing virgin earth.

:-)

Matthew

"Dave" <Dave_member pathlink.com> wrote in message
news:cg0g2m$vqk$1 digitaldaemon.com...
 Attached is a log when compiled with:

 dmd -c -v -I../.. test/list_test.d >dmd_list_test.log 2>&1

 The rest of DTL v0.1.1 compiles and the test executables work fine on this
 platform.

"antiAlias" <fu bar.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote
 Although it's hardly surprising. The whole development of DTL seems
 to be short bursts between waiting for language facilities and/or
 compiler/linker fixes.

You're not alone with that problem ... several library developers have been
faced with this for ages. It can be terribly frustrating and depressing when
specific compiler issues are not fixed for months on end.

For example; here's just a sample of problems that have plagued some
developers: continual issues with Interfaces not working, continual issues
with import and forward-references, continual issues with invalid
static-constructor ordering ...

You'd think projects such as DTL, DWT, Mango, and the others would get some
kind of priority in terms of support. After all, they're being written by
busy people who are giving up their valuable time to provide free libraries
in support of the language itself. The end result is those same people
sometimes become so despondent that the projects simply languish.

I, for one, cannot fathom why there's been zero support for the DWT project
specifically; it's perhaps the most promising & valuable to a significant
audience segment -- yet it's been stalled since the get-go over
forward-reference issues.

This sounds like a gripe, but it's actually reality. A poxy situation to be
in, for sure; and one that should have been both addressed and resolved long
ago. If it had been, I wouldn't feel obliged to write this now.

This question should have been posed months ago, but, what can be done about
this situation?

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"antiAlias" <fu bar.com> wrote in message
news:cg17jq$2oh1$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote
 Although it's hardly surprising. The whole development of DTL seems
 to be short bursts between waiting for language facilities and/or
 compiler/linker fixes.

 You're not alone with that problem ... several library developers have been
 faced with this for ages. It can be terribly frustrating and depressing when
 specific compiler issues are not fixed for months on end.

 For example; here's just a sample of problems that have plagued some
 developers: continual issues with Interfaces not working, continual issues
 with import and forward-references, continual issues with invalid
 static-constructor ordering ...

 You'd think projects such as DTL, DWT, Mango, and the others would get some
 kind of priority in terms of support. After all, they're being written by
 busy people who are giving up their valuable time to provide free libraries
 in support of the language itself. The end result is those same people
 sometimes become so despondent that the projects simply languish.

 I, for one, cannot fathom why there's been zero support for the DWT project
 specifically; it's perhaps the most promising & valuable to a significant
 audience segment -- yet it's been stalled since the get-go over
 forward-reference issues.

 This sounds like a gripe, but it's actually reality. A poxy situation to be
 in, for sure; and one that should have been both addressed and resolved long
 ago. If it had been, I wouldn't feel obliged to write this now.

 This question should have been posed months ago, but, what can be done about
 this situation?

Don't apologise. I think your concerns are real. I don't know what the answer
is, however.

I can see the argument that some projects should get priority. Certainly the
three you mention, assuming they eventually
yield on their promise, will be of profound importance to D. But I guess there
are probably several other projects that
could claim to be as important, though - and this is partly due to being
stymied with DTL resulting in my spending my
time on other things of late -  I don't know what they are.

Perhaps one option would be to organise a vote on the main ng, regarding which
projects we'd like Walter to prioritise
his time on. But my guess is that Walter's a particular kind of genius that
finds it difficult to time-share in such a
way. (I know I am. Time-share challenged, that is, not genius.)

I've noticed a distinct drop in traffic on the main ng. Normally each week I am
away there are hundreds of new messages.
But delving in again the other day I think there were less than 200 since my
last snuffle around the trough. While I
appreciate the reduced level of future shock, I hope it's not indicative of D
losing momentum.

Maybe the answer is for us (interested people + Walter) to get a definitive
list of language _and_ library issues
identified for 1.0, and pretty much settle on that. Most of anything else can
go in the 1.1 basket.

Here's hoping ...


Walter, it'd be great if you could opine on this issue.

Andy Friesen <andy ikagames.com> writes:

Matthew wrote:
 "antiAlias" <fu bar.com> wrote in message
news:cg17jq$2oh1$1 digitaldaemon.com...
 
"Matthew" <admin.hat stlsoft.dot.org> wrote

Although it's hardly surprising. The whole development of DTL seems
to be short bursts between waiting for language facilities and/or
compiler/linker fixes.

You're not alone with that problem ... several library developers have been
faced with this for ages. It can be terribly frustrating and depressing when
specific compiler issues are not fixed for months on end.

For example; here's just a sample of problems that have plagued some
developers: continual issues with Interfaces not working, continual issues
with import and forward-references, continual issues with invalid
static-constructor ordering ...

You'd think projects such as DTL, DWT, Mango, and the others would get some
kind of priority in terms of support. After all, they're being written by
busy people who are giving up their valuable time to provide free libraries
in support of the language itself. The end result is those same people
sometimes become so despondent that the projects simply languish.

I, for one, cannot fathom why there's been zero support for the DWT project
specifically; it's perhaps the most promising & valuable to a significant
audience segment -- yet it's been stalled since the get-go over
forward-reference issues.

This sounds like a gripe, but it's actually reality. A poxy situation to be
in, for sure; and one that should have been both addressed and resolved long
ago. If it had been, I wouldn't feel obliged to write this now.

This question should have been posed months ago, but, what can be done about
this situation?

 
 
 Don't apologise. I think your concerns are real. I don't know what the answer
is, however.
 
 I can see the argument that some projects should get priority. Certainly the
three you mention, assuming they eventually
 yield on their promise, will be of profound importance to D. But I guess there
are probably several other projects that
 could claim to be as important, though - and this is partly due to being
stymied with DTL resulting in my spending my
 time on other things of late -  I don't know what they are.
 
 Perhaps one option would be to organise a vote on the main ng, regarding which
projects we'd like Walter to prioritise
 his time on. But my guess is that Walter's a particular kind of genius that
finds it difficult to time-share in such a
 way. (I know I am. Time-share challenged, that is, not genius.)
 
 I've noticed a distinct drop in traffic on the main ng. Normally each week I
am away there are hundreds of new messages.
 But delving in again the other day I think there were less than 200 since my
last snuffle around the trough. While I
 appreciate the reduced level of future shock, I hope it's not indicative of D
losing momentum.
 
 Maybe the answer is for us (interested people + Walter) to get a definitive
list of language _and_ library issues
 identified for 1.0, and pretty much settle on that. Most of anything else can
go in the 1.1 basket.
 
 Here's hoping ...
 
 
 Walter, it'd be great if you could opine on this issue.

What I would really like to see is a working backend that can be 
connected to the open source frontend, preferably unmodified.

Given that, contributors could implement and test bugfixes as they are 
found, not to mention the ability for the community to implement various 
syntax extension proposals on a try-and-see basis.

If nothing else, this potentially gives us the ability to respond to 
proposals with "we tried that but it sucked".

I'd suggest GDC, but GCC's signal-to-noise is bad enough that my brain 
turns to butter.  I haven't been able to build GDC using more recent 
frontend sources because of this. :)  (maybe this is just because I'm a 
relative compiler newbie, but I feel better about myself when I blame C)

There's also DLI, which worked at one point, and could possibly be made 
to work again.  hm... (LLVM <http://llvm.org> looks like it would be an 
easy target too)

  -- andy

J C Calvarese <jcc7 cox.net> writes:

Andy Friesen wrote:
 What I would really like to see is a working backend that can be 
 connected to the open source frontend, preferably unmodified.

Great idea! Actually, this is the kind of like the inverse of Walter's 
bug report demands: complete and repeatable code. The current state of 
the frontend source is similar to when people submit half an example and 
  an impossible amount of guessing is required to figure out how they 
produced the error message.

 
 Given that, contributors could implement and test bugfixes as they are 
 found, not to mention the ability for the community to implement various 
 syntax extension proposals on a try-and-see basis.
 
 If nothing else, this potentially gives us the ability to respond to 
 proposals with "we tried that but it sucked".
 
 I'd suggest GDC, but GCC's signal-to-noise is bad enough that my brain 
 turns to butter.  I haven't been able to build GDC using more recent 
 frontend sources because of this. :)  (maybe this is just because I'm a 
 relative compiler newbie, but I feel better about myself when I blame C)
 
 There's also DLI, which worked at one point, and could possibly be made 
 to work again.  hm... (LLVM <http://llvm.org> looks like it would be an 
 easy target too)
 
  -- andy


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Ilya Minkov <minkov cs.tum.edu> writes:

Andy Friesen schrieb:

 I'd suggest GDC, but GCC's signal-to-noise is bad enough that my brain 
 turns to butter.  I haven't been able to build GDC using more recent 
 frontend sources because of this. :)  (maybe this is just because I'm a 
 relative compiler newbie, but I feel better about myself when I blame C)

I think it gets better the better one knows it, and only if one is able 
to invest time. But then it's probably not that bad.

 There's also DLI, which worked at one point, and could possibly be made 
 to work again.  hm... (LLVM <http://llvm.org> looks like it would be an 
 easy target too)

Hm. Interesting to see that again.

I'm hacking COCO/R right now. Is there an interest that i make a version 
able to generate D and try to create a D grammar?

Uh oh. I gotta better study.

-eye

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cg18ii$2p6f$1 digitaldaemon.com...
 I, for one, cannot fathom why there's been zero support for the DWT


project
 specifically; it's perhaps the most promising & valuable to a


significant
 audience segment -- yet it's been stalled since the get-go over
 forward-reference issues.


The fw issues have been resolved.

 I've noticed a distinct drop in traffic on the main ng. Normally each week

I am away there are hundreds of new messages.
 But delving in again the other day I think there were less than 200 since

my last snuffle around the trough. While I
 appreciate the reduced level of future shock, I hope it's not indicative

of D losing momentum.

August is usually a pretty slow month. People are out on vacation, having
fun, etc. Back in the olden days we discovered that running advertisements
in August was just throwing money away. PC Magazine would go to once in
August rather than their usual every-two-weeks.

I understand the importance of making the compiler work right, which is why
I've stopped adding features. The current revision I'm working on fixes
another boatload of bugs. I was going to ship it last night, but it failed
the regression tests.

"antiAlias" <fu bar.com> writes:

"Walter" wrote ...
 audience segment -- yet it's been stalled since the get-go over
 forward-reference issues.


 The fw issues have been resolved.

Have they really? More power to you if that's really the case (all the DWT
inner-imports can all be removed, and everything compiles cleanly? Antonio
might also care to comment on this particular topic).

It's certainly not my intention to give you a hard-time, Walter, but the
point remains that if the persistent FR issues had been given some priority
way back in early March, or April, or May (instead of August)  there's a
reasonable chance we'd have a partly operational DWT right now. The FR
problems were noted back then.

This is not about crying-over-spilt-milk; it's about how to avoid the same
long-term problem going forward. What can we do in this respect?

"Walter" <newshound digitalmars.com> writes:

"antiAlias" <fu bar.com> wrote in message
news:cg3110$2dl6$1 digitaldaemon.com...
 "Walter" wrote ...
 audience segment -- yet it's been stalled since the get-go over
 forward-reference issues.


 The fw issues have been resolved.

 Have they really?

The ones reported have been, except for struct fr's.

 More power to you if that's really the case (all the DWT
 inner-imports can all be removed, and everything compiles cleanly? Antonio
 might also care to comment on this particular topic).

I have not attempted to compile DWT.

 It's certainly not my intention to give you a hard-time, Walter, but the
 point remains that if the persistent FR issues had been given some

priority
 way back in early March, or April, or May (instead of August)  there's a
 reasonable chance we'd have a partly operational DWT right now. The FR
 problems were noted back then.

 This is not about crying-over-spilt-milk; it's about how to avoid the same
 long-term problem going forward. What can we do in this respect?

There's only one of me, and early this year there was an explosion in the
number of people using D. As a consequence, a lot of compiler bugs and
shortcomings in the language were uncovered. I fell way, way behind. I still
haven't read all the threads in the old D newsgroup, for example. There's
frequently over a hundred posts a day. They are nearly all technical, and
have to be read slowly. So it might sometimes appear that I am ignoring an
issue, when in reality I just haven't read that thread yet. There's not much
chance I can play around with DWT myself, I have to rely on others to
compile it, isolate, and report problems.

I hope that, long term, the compiler will get much more stable and so this
will be less of a problem.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:cg3220$2esv$1 digitaldaemon.com...
 "antiAlias" <fu bar.com> wrote in message
 news:cg3110$2dl6$1 digitaldaemon.com...
 "Walter" wrote ...
 audience segment -- yet it's been stalled since the get-go over
 forward-reference issues.


 The fw issues have been resolved.

 Have they really?

 The ones reported have been, except for struct fr's.

 More power to you if that's really the case (all the DWT
 inner-imports can all be removed, and everything compiles cleanly? Antonio
 might also care to comment on this particular topic).

 I have not attempted to compile DWT.

 It's certainly not my intention to give you a hard-time, Walter, but the
 point remains that if the persistent FR issues had been given some

 priority
 way back in early March, or April, or May (instead of August)  there's a
 reasonable chance we'd have a partly operational DWT right now. The FR
 problems were noted back then.

 This is not about crying-over-spilt-milk; it's about how to avoid the same
 long-term problem going forward. What can we do in this respect?

 There's only one of me, and early this year there was an explosion in the
 number of people using D. As a consequence, a lot of compiler bugs and
 shortcomings in the language were uncovered. I fell way, way behind. I still
 haven't read all the threads in the old D newsgroup, for example. There's
 frequently over a hundred posts a day. They are nearly all technical, and
 have to be read slowly. So it might sometimes appear that I am ignoring an
 issue, when in reality I just haven't read that thread yet. There's not much
 chance I can play around with DWT myself, I have to rely on others to
 compile it, isolate, and report problems.

 I hope that, long term, the compiler will get much more stable and so this
 will be less of a problem.

Wouldn't one smart move at this point be to appoint a panel of NG moderators?

Perhaps in conjunction with a new digitalmars.D.strategy ng that was moderated
only? Then you could, in conscience,
ignore the main ngs.


Another idea might be that you include DTL, DWT and Mango in your regression
tests.

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg32e6$2f4b$1 digitaldaemon.com...
 Wouldn't one smart move at this point be to appoint a panel of NG

moderators?
 Perhaps in conjunction with a new digitalmars.D.strategy ng that was

moderated only? Then you could, in conscience,
 ignore the main ngs.

But I don't want to hide behind moderators and ignore the main ng. I never
have in 25 years of supporting compilers, and that's been one of the
strengths of my products. Part of the reason for the creation of the bugs
ng, however, was to make it easier to identify the more critical issues.

 Another idea might be that you include DTL, DWT and Mango in your

regression tests.

That'll have to happen at some point.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:cg34dh$2gv6$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg32e6$2f4b$1 digitaldaemon.com...
 Wouldn't one smart move at this point be to appoint a panel of NG

 moderators?
 Perhaps in conjunction with a new digitalmars.D.strategy ng that was

 moderated only? Then you could, in conscience,
 ignore the main ngs.

 But I don't want to hide behind moderators and ignore the main ng. I never
 have in 25 years of supporting compilers, and that's been one of the
 strengths of my products. Part of the reason for the creation of the bugs
 ng, however, was to make it easier to identify the more critical issues.

I understand that, but there has to be a finite limit to the volume you can
support, beyond which your level of service
starts to drop.

Obviously it's just an issue of whether you're at that point. At some point,
you will have to hide behind moderators.
You'll have no choice. I don't see the point of putting it off, because even if
you don't think you're there, I would
guess that many of the "important" library developers think you may be.

This is not meant as a slight, as I'm sure you realise, more it's a reflection
of your success.

 Another idea might be that you include DTL, DWT and Mango in your

 regression tests.

 That'll have to happen at some point.

Good to hear you're responsive to that.

Dave <Dave_member pathlink.com> writes:

Matthew wrote:

 
 "Walter" <newshound digitalmars.com> wrote in message
 news:cg34dh$2gv6$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg32e6$2f4b$1 digitaldaemon.com...
 Wouldn't one smart move at this point be to appoint a panel of NG

 moderators?


 
 Another idea might be that you include DTL, DWT and Mango in your

 regression tests.

 That'll have to happen at some point.

 
 Good to hear you're responsive to that.

How about something along these lines until Walter is ready to add those
libs. to his reg. testing:

Walter provides the "important" lib. developers (or other volunteers) for a
given library with any build that passes his regression tests b4 general
release, and they do their own regression testing.

It would still be Walter's decision whether or not to release, no questions
asked (why delay something that fixes many problems even if it
re/introduces a few. If the problems turned out to be large with a major
library or two, I'm pretty confident Walter would hold the release anyway).

It would then be the responsibility of the lib. developers to post version
specific errata along with the lib. download. i.e.: Linux, 0.98, DTL List,
etc..., if Walter did decide to release a version.

Who better than the lib. developers or other lib. expert to regression test
the libs.?

I realize that the lib. developers have already given a lot of their time,
but a canned regression test can't take too long once developed and is
probably 90% finished with the developers own test routines anyhow.

- Dave

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Dave" <Dave_member pathlink.com> wrote in message
news:cg3g1i$2lrs$1 digitaldaemon.com...
 Matthew wrote:

 "Walter" <newshound digitalmars.com> wrote in message
 news:cg34dh$2gv6$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg32e6$2f4b$1 digitaldaemon.com...
 Wouldn't one smart move at this point be to appoint a panel of NG

 moderators?


 Another idea might be that you include DTL, DWT and Mango in your

 regression tests.

 That'll have to happen at some point.

 Good to hear you're responsive to that.

 How about something along these lines until Walter is ready to add those
 libs. to his reg. testing:

 Walter provides the "important" lib.

Don't know what you mean. Do you mean the import lib??

 developers (or other volunteers) for a
 given library with any build that passes his regression tests b4 general
 release, and they do their own regression testing.

Sorry, I must be thick. Can you rephrase?

 It would still be Walter's decision whether or not to release, no questions
 asked (why delay something that fixes many problems even if it
 re/introduces a few. If the problems turned out to be large with a major
 library or two, I'm pretty confident Walter would hold the release anyway).

 It would then be the responsibility of the lib. developers to post version
 specific errata along with the lib. download. i.e.: Linux, 0.98, DTL List,
 etc..., if Walter did decide to release a version.

 Who better than the lib. developers or other lib. expert to regression test
 the libs.?

 I realize that the lib. developers have already given a lot of their time,
 but a canned regression test can't take too long once developed and is
 probably 90% finished with the developers own test routines anyhow.

Sorry, Dave. I *really* must be thick today. I just don't get any of the
details of what you're proposing. Can you
rephrase so a two-dig IQ trog can understand?

:)

Matthew

"Carlos Santander B." <carlos8294 msn.com> writes:

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
news:cg3lvu$2nuk$1 digitaldaemon.com
| Sorry, Dave. I *really* must be thick today. I just don't get any of the
details
| of what you're proposing. Can you rephrase so a two-dig IQ trog can
understand?
|
| :)
|
| Matthew

I think he means what Walter has done with you in the past, Matthew, which is
sending non-released versions of the compiler to test it. But instead of doing
it only with you, it'd be done with those in charge of the most important
libraries (DTL, DWT, Mango).

-----------------------
Carlos Santander Bernal

Dave <Dave_member pathlink.com> writes:

Carlos Santander B. wrote:

 I think he means what Walter has done with you in the past, Matthew, which
 is sending non-released versions of the compiler to test it. But instead
 of doing it only with you, it'd be done with those in charge of the most
 important libraries (DTL, DWT, Mango).

Exactly.

Thanks,

- Dave

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:cg3ohg$2ooc$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
 news:cg3lvu$2nuk$1 digitaldaemon.com
 | Sorry, Dave. I *really* must be thick today. I just don't get any of the
 details
 | of what you're proposing. Can you rephrase so a two-dig IQ trog can
 understand?
 |
 | :)
 |
 | Matthew

 I think he means what Walter has done with you in the past, Matthew, which is
 sending non-released versions of the compiler to test it. But instead of doing
 it only with you, it'd be done with those in charge of the most important
 libraries (DTL, DWT, Mango).

You mean an intermediate release to a "group" of "important" library writers.

That can work, iff such a group can be identified without consternation and
rancour. I'll leave that to some else,
methinks. :-)

"Walter" <newshound digitalmars.com> writes:

"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:cg3ohg$2ooc$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
 news:cg3lvu$2nuk$1 digitaldaemon.com
 | Sorry, Dave. I *really* must be thick today. I just don't get any of the
 details
 | of what you're proposing. Can you rephrase so a two-dig IQ trog can
 understand?
 |
 | :)
 |
 | Matthew

 I think he means what Walter has done with you in the past, Matthew, which

is
 sending non-released versions of the compiler to test it. But instead of

doing
 it only with you, it'd be done with those in charge of the most important
 libraries (DTL, DWT, Mango).

I haven't really sent Matthew compilers to test, I just would send him one
now and then to help him past a roadblock with DTL.

"Carlos Santander B." <carlos8294 msn.com> writes:

"Walter" <newshound digitalmars.com> escribió en el mensaje
news:cg4804$30v7$2 digitaldaemon.com
| I haven't really sent Matthew compilers to test, I just would send him one
| now and then to help him past a roadblock with DTL.

My bad then. But basically that's what they've been talking about.

-----------------------
Carlos Santander Bernal

Dave <Dave_member pathlink.com> writes:

Matthew wrote:
 
 "Dave" <Dave_member pathlink.com> wrote in message
 news:cg3g1i$2lrs$1 digitaldaemon.com...
 Matthew wrote:

 Walter provides the "important" lib.

 
 Don't know what you mean. Do you mean the import lib??
 
 developers (or other volunteers) for a
 given library with any build that passes his regression tests b4 general
 release, and they do their own regression testing.

 
 Sorry, I must be thick. Can you rephrase?
 

Wow, my post was really cryptic. Sorry..

You had mentioned "important" library developers earlier, and my suggestion
boils down to:

After a new release candidate passes Walter's regression testing, Walter
would provide that build to the 'major library' developers for their own
testing. This would happen before general availability of that build.

Since the library developers have already devoted a bunch of time to the
libraries, volunteers could do the library regression tests also.

Just a suggestion to try and keep this off Walter's plate for a while and
still include regression testing on major libraries. I have no idea if the
logistics could be worked out or not.

- Dave

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Dave" <Dave_member pathlink.com> wrote in message
news:cg3r7p$2qi9$1 digitaldaemon.com...
 Matthew wrote:
 "Dave" <Dave_member pathlink.com> wrote in message
 news:cg3g1i$2lrs$1 digitaldaemon.com...
 Matthew wrote:

 Walter provides the "important" lib.

 Don't know what you mean. Do you mean the import lib??

 developers (or other volunteers) for a
 given library with any build that passes his regression tests b4 general
 release, and they do their own regression testing.

 Sorry, I must be thick. Can you rephrase?

 Wow, my post was really cryptic. Sorry..

 You had mentioned "important" library developers earlier, and my suggestion
 boils down to:

 After a new release candidate passes Walter's regression testing, Walter
 would provide that build to the 'major library' developers for their own
 testing. This would happen before general availability of that build.

 Since the library developers have already devoted a bunch of time to the
 libraries, volunteers could do the library regression tests also.

 Just a suggestion to try and keep this off Walter's plate for a while and
 still include regression testing on major libraries. I have no idea if the
 logistics could be worked out or not.

Ah. Perfect. (And inordinately better expl. btw. My hats off to you. Normally
takes me three or four rewrites, if ever,
to make that leap in clarity.)

Yes, I think this is a fine idea, and would work very well.

From my POV, the major library developers - which may well be a wider group
than that mooted thus far - can, probably
already, and most certainly should, have the infrastructure to make beta
installations and conduct builds with old and
new compilers, and such. So I can't see any major problems.

The only issue might be if said developers were unavailable for a while (as I
am myself from time to time). I think
they're free to miss an intermediate release, and it's tough if their code
loses out. Doubtless they could "catch up"
with the next intermediate or two.

Walter?

"antiAlias" <fu bar.com> writes:

This is all fine and well, but addresses backwards-compatibility only. While
that's a valid and positive thing to do, it doesn't address the point that
library developers have (so far) not had much joy in having their issues
resolved in a timely fashion (and Walter pointed out exactly why).

If the compiler had no bugs, and no requirements, then there would be no
issue. One would be inclined to agree that it's less of an issue now than it
was six months ago, yet Mango (for instance) is still waiting for resolution
on things noted months ago. It's rather likely that others are in the same
boat.

What you suggest is a fine notion. But please let's no lose sight of the
other issues also ...


"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg3tiu$2rpa$2 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote in message

news:cg3r7p$2qi9$1 digitaldaemon.com...
 Matthew wrote:
 "Dave" <Dave_member pathlink.com> wrote in message
 news:cg3g1i$2lrs$1 digitaldaemon.com...
 Matthew wrote:

 Walter provides the "important" lib.

 Don't know what you mean. Do you mean the import lib??

 developers (or other volunteers) for a
 given library with any build that passes his regression tests b4




general
 release, and they do their own regression testing.

 Sorry, I must be thick. Can you rephrase?

 Wow, my post was really cryptic. Sorry..

 You had mentioned "important" library developers earlier, and my


suggestion
 boils down to:

 After a new release candidate passes Walter's regression testing, Walter
 would provide that build to the 'major library' developers for their own
 testing. This would happen before general availability of that build.

 Since the library developers have already devoted a bunch of time to the
 libraries, volunteers could do the library regression tests also.

 Just a suggestion to try and keep this off Walter's plate for a while


and
 still include regression testing on major libraries. I have no idea if


the
 logistics could be worked out or not.

 Ah. Perfect. (And inordinately better expl. btw. My hats off to you.

Normally takes me three or four rewrites, if ever,
 to make that leap in clarity.)

 Yes, I think this is a fine idea, and would work very well.

 From my POV, the major library developers - which may well be a wider

group than that mooted thus far - can, probably
 already, and most certainly should, have the infrastructure to make beta

installations and conduct builds with old and
 new compilers, and such. So I can't see any major problems.

 The only issue might be if said developers were unavailable for a while

(as I am myself from time to time). I think
 they're free to miss an intermediate release, and it's tough if their code

loses out. Doubtless they could "catch up"
 with the next intermediate or two.

 Walter?

"Matthew" <admin.hat stlsoft.dot.org> writes:

Ok, I agree. So suggest something better.

"antiAlias" <fu bar.com> wrote in message
news:cg40vn$2tsi$1 digitaldaemon.com...
 This is all fine and well, but addresses backwards-compatibility only. While
 that's a valid and positive thing to do, it doesn't address the point that
 library developers have (so far) not had much joy in having their issues
 resolved in a timely fashion (and Walter pointed out exactly why).

 If the compiler had no bugs, and no requirements, then there would be no
 issue. One would be inclined to agree that it's less of an issue now than it
 was six months ago, yet Mango (for instance) is still waiting for resolution
 on things noted months ago. It's rather likely that others are in the same
 boat.

 What you suggest is a fine notion. But please let's no lose sight of the
 other issues also ...


 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg3tiu$2rpa$2 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote in message

 news:cg3r7p$2qi9$1 digitaldaemon.com...
 Matthew wrote:
 "Dave" <Dave_member pathlink.com> wrote in message
 news:cg3g1i$2lrs$1 digitaldaemon.com...
 Matthew wrote:

 Walter provides the "important" lib.

 Don't know what you mean. Do you mean the import lib??

 developers (or other volunteers) for a
 given library with any build that passes his regression tests b4




 general
 release, and they do their own regression testing.

 Sorry, I must be thick. Can you rephrase?

 Wow, my post was really cryptic. Sorry..

 You had mentioned "important" library developers earlier, and my


 suggestion
 boils down to:

 After a new release candidate passes Walter's regression testing, Walter
 would provide that build to the 'major library' developers for their own
 testing. This would happen before general availability of that build.

 Since the library developers have already devoted a bunch of time to the
 libraries, volunteers could do the library regression tests also.

 Just a suggestion to try and keep this off Walter's plate for a while


 and
 still include regression testing on major libraries. I have no idea if


 the
 logistics could be worked out or not.

 Ah. Perfect. (And inordinately better expl. btw. My hats off to you.

 Normally takes me three or four rewrites, if ever,
 to make that leap in clarity.)

 Yes, I think this is a fine idea, and would work very well.

 From my POV, the major library developers - which may well be a wider

 group than that mooted thus far - can, probably
 already, and most certainly should, have the infrastructure to make beta

 installations and conduct builds with old and
 new compilers, and such. So I can't see any major problems.

 The only issue might be if said developers were unavailable for a while

 (as I am myself from time to time). I think
 they're free to miss an intermediate release, and it's tough if their code

 loses out. Doubtless they could "catch up"
 with the next intermediate or two.

 Walter?

"Walter" <newshound digitalmars.com> writes:

"antiAlias" <fu bar.com> wrote in message
news:cg40vn$2tsi$1 digitaldaemon.com...
 If the compiler had no bugs, and no requirements, then there would be no
 issue. One would be inclined to agree that it's less of an issue now than

it
 was six months ago, yet Mango (for instance) is still waiting for

resolution
 on things noted months ago. It's rather likely that others are in the same
 boat.

What exactly is mango waiting on?

"antiAlias" <fu bar.com> writes:

"Walter" wrote...
 What exactly is mango waiting on?

- The ongoing Interface issues (now described as Interface MI issues)
originally noted in April, then again in June. Release notes for v0.99 say
this is resolved, though I haven't tried it yet. Certain areas of Mango have
been terribly fragile for months due to this, and non-extensible. For
example, whenever a gpf would occur in relation to Interface usage, I'd go
in and switch the order in which Interfaces were declared in class
declarations (lunacy!). It would eliminate the gpf for one area but move it
to another. Adding additional Interfaces to class declarations simply
aggravated the problem, so Mango development vis-a-vis Interfaces just
stopped.

- The version() operational discrepancy between Windows and linux was still
causing grief recently.

- Static constructors not invoked for inner/nested classes.

- The static-constructor ordering noted in May, June, and July. I've held
off on a few things until that is resolved.

- The inability of a class to satisfy an Interface contract via its
inheritance tree (noted in April). This is a design issue rather than a bug,
but it places a burden on Mango clients that is totally unnecessary and,
frankly, untenable. You don't really run into this until you start using
Interfaces a lot. Mango is an Interface-based design so, naturally,
comes-a-cropper over this all the time. You note there's a potential
type-hole involved (though the hole is of a questionable nature, IMO), yet
there are likely several ways to avoid said hole completely while still
providing the required functionality.

- Corrupt stack when assigning 'out' arguments within a nested/inner
function.


Each of these has stalled, delayed, or halted Mango development in one way
or another. Sure, one just finds something else to work on; but it's hard to
maintain focus when ongoing issues are not resolved for months on end.

"Walter" <newshound digitalmars.com> writes:

Ok, I'll check them out.

"antiAlias" <fu bar.com> wrote in message
news:cg5gte$k4c$1 digitaldaemon.com...
 "Walter" wrote...
 What exactly is mango waiting on?

 - The ongoing Interface issues (now described as Interface MI issues)
 originally noted in April, then again in June. Release notes for v0.99 say
 this is resolved, though I haven't tried it yet. Certain areas of Mango

have
 been terribly fragile for months due to this, and non-extensible. For
 example, whenever a gpf would occur in relation to Interface usage, I'd go
 in and switch the order in which Interfaces were declared in class
 declarations (lunacy!). It would eliminate the gpf for one area but move

it
 to another. Adding additional Interfaces to class declarations simply
 aggravated the problem, so Mango development vis-a-vis Interfaces just
 stopped.

 - The version() operational discrepancy between Windows and linux was

still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

 - The static-constructor ordering noted in May, June, and July. I've held
 off on a few things until that is resolved.

 - The inability of a class to satisfy an Interface contract via its
 inheritance tree (noted in April). This is a design issue rather than a

bug,
 but it places a burden on Mango clients that is totally unnecessary and,
 frankly, untenable. You don't really run into this until you start using
 Interfaces a lot. Mango is an Interface-based design so, naturally,
 comes-a-cropper over this all the time. You note there's a potential
 type-hole involved (though the hole is of a questionable nature, IMO), yet
 there are likely several ways to avoid said hole completely while still
 providing the required functionality.

 - Corrupt stack when assigning 'out' arguments within a nested/inner
 function.


 Each of these has stalled, delayed, or halted Mango development in one way
 or another. Sure, one just finds something else to work on; but it's hard

to
 maintain focus when ongoing issues are not resolved for months on end.

"Matthew" <admin.hat stlsoft.dot.org> writes:

Can either/both of you report on the results of resolution of all (but the
trivial) issues, and provide some description
of the ramifications.

For example, I definitely want to know a lot more about the class vs interface
contract stuff. If/when this gets fixed,
it'd be very useful to have an explanation.

"Walter" <newshound digitalmars.com> wrote in message
news:cg5lqs$n6p$1 digitaldaemon.com...
 Ok, I'll check them out.

 "antiAlias" <fu bar.com> wrote in message
 news:cg5gte$k4c$1 digitaldaemon.com...
 "Walter" wrote...
 What exactly is mango waiting on?

 - The ongoing Interface issues (now described as Interface MI issues)
 originally noted in April, then again in June. Release notes for v0.99 say
 this is resolved, though I haven't tried it yet. Certain areas of Mango

 have
 been terribly fragile for months due to this, and non-extensible. For
 example, whenever a gpf would occur in relation to Interface usage, I'd go
 in and switch the order in which Interfaces were declared in class
 declarations (lunacy!). It would eliminate the gpf for one area but move

 it
 to another. Adding additional Interfaces to class declarations simply
 aggravated the problem, so Mango development vis-a-vis Interfaces just
 stopped.

 - The version() operational discrepancy between Windows and linux was

 still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

 - The static-constructor ordering noted in May, June, and July. I've held
 off on a few things until that is resolved.

 - The inability of a class to satisfy an Interface contract via its
 inheritance tree (noted in April). This is a design issue rather than a

 bug,
 but it places a burden on Mango clients that is totally unnecessary and,
 frankly, untenable. You don't really run into this until you start using
 Interfaces a lot. Mango is an Interface-based design so, naturally,
 comes-a-cropper over this all the time. You note there's a potential
 type-hole involved (though the hole is of a questionable nature, IMO), yet
 there are likely several ways to avoid said hole completely while still
 providing the required functionality.

 - Corrupt stack when assigning 'out' arguments within a nested/inner
 function.


 Each of these has stalled, delayed, or halted Mango development in one way
 or another. Sure, one just finds something else to work on; but it's hard

 to
 maintain focus when ongoing issues are not resolved for months on end.

Juanjo =?ISO-8859-15?Q?=C1lvarez?= <juanjuxNO SPAMyahoo.es> writes:

Matthew wrote:

 Can either/both of you report on the results of resolution of all (but the
 trivial) issues, and provide some description of the ramifications.
 

This showns that what is really needed here is a bug tracking software for
the D compiler (bugzilla, mantis or something like that.) I wish I had a
little more time to set up one (it's no difficult at all but it takes
time), maybe in a month or two when things relax a little in my daywork
(we're about to finish and deploy a big project to thousands of clients,
you know what I mean).

"antiAlias" <fu bar.com> writes:

An alternative might be to use the bug-tracking that's being put into place
over at dsource.org ...

"Juanjo Álvarez" <juanjuxNO SPAMyahoo.es> wrote in message
news:cg62rd$u6g$2 digitaldaemon.com...
 Matthew wrote:

 Can either/both of you report on the results of resolution of all (but


the
 trivial) issues, and provide some description of the ramifications.

 This showns that what is really needed here is a bug tracking software for
 the D compiler (bugzilla, mantis or something like that.) I wish I had a
 little more time to set up one (it's no difficult at all but it takes
 time), maybe in a month or two when things relax a little in my daywork
 (we're about to finish and deploy a big project to thousands of clients,
 you know what I mean).

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg61on$u9i$1 digitaldaemon.com...
 For example, I definitely want to know a lot more about the class vs

interface contract stuff. If/when this gets fixed,
 it'd be very useful to have an explanation.

There was a long and rather acrimonious thread about this recently on
digitalmars.D.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:cg6gks$158t$2 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg61on$u9i$1 digitaldaemon.com...
 For example, I definitely want to know a lot more about the class vs

 interface contract stuff. If/when this gets fixed,
 it'd be very useful to have an explanation.

 There was a long and rather acrimonious thread about this recently on
 digitalmars.D.

Alas, I don't have much bandwidth left, so I thought I could do a last minute,
definitive, cramming once it's all
sorted. ;)

"antiAlias" <fu bar.com> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:cg6gks$158t$2 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg61on$u9i$1 digitaldaemon.com...
 For example, I definitely want to know a lot more about the class vs

 interface contract stuff. If/when this gets fixed,
 it'd be very useful to have an explanation.

 There was a long and rather acrimonious thread about this recently on
 digitalmars.D.

Surely there must be some mistake? I believe the name of the relevant thread
was "Satisfying Interface Requirements" but, in reviewing it, I don't see
any acrimony there. Perhaps there was in other, related, active threads at
the same time?  That particular thread got little traction due to a typo in
the example, which apparently caused a misunderstanding. This was later
rectified, but then left unanswered and dangling ...

Here's the post noting said misunderstanding:
news:ce24uf$b8j$1 digitaldaemon.com

"antiAlias" <fu bar.com> writes:

"v0.99: Fixed MI bug with interface vtbl dispatch."

Whatever you fixed doesn't resolve the broken MI-Interface vTable afflicting
certain areas of Mango ... the wrong methods are still invoked when calling
through an interface.


"Walter" <newshound digitalmars.com> wrote in message
news:cg5lqs$n6p$1 digitaldaemon.com...
 Ok, I'll check them out.

 "antiAlias" <fu bar.com> wrote in message
 news:cg5gte$k4c$1 digitaldaemon.com...
 "Walter" wrote...
 What exactly is mango waiting on?

 - The ongoing Interface issues (now described as Interface MI issues)
 originally noted in April, then again in June. Release notes for v0.99


say
 this is resolved, though I haven't tried it yet. Certain areas of Mango

 have
 been terribly fragile for months due to this, and non-extensible. For
 example, whenever a gpf would occur in relation to Interface usage, I'd


go
 in and switch the order in which Interfaces were declared in class
 declarations (lunacy!). It would eliminate the gpf for one area but move

 it
 to another. Adding additional Interfaces to class declarations simply
 aggravated the problem, so Mango development vis-a-vis Interfaces just
 stopped.

 - The version() operational discrepancy between Windows and linux was

 still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

 - The static-constructor ordering noted in May, June, and July. I've


held
 off on a few things until that is resolved.

 - The inability of a class to satisfy an Interface contract via its
 inheritance tree (noted in April). This is a design issue rather than a

 bug,
 but it places a burden on Mango clients that is totally unnecessary and,
 frankly, untenable. You don't really run into this until you start using
 Interfaces a lot. Mango is an Interface-based design so, naturally,
 comes-a-cropper over this all the time. You note there's a potential
 type-hole involved (though the hole is of a questionable nature, IMO),


yet
 there are likely several ways to avoid said hole completely while still
 providing the required functionality.

 - Corrupt stack when assigning 'out' arguments within a nested/inner
 function.


 Each of these has stalled, delayed, or halted Mango development in one


way
 or another. Sure, one just finds something else to work on; but it's


hard
 to
 maintain focus when ongoing issues are not resolved for months on end.

"antiAlias" <fu bar.com> writes:

more info:

Turns out this is aggravated by what I'd term a "compound" Interface. If you
do the following:

interface ICompound : ISomeInterface, IOtherInterface, IYetAnotherInterface
{}

and then

interface IDerived : ICompound
{
   // some method signatures ...
}

IDerived.method ();

the vTable gets borked. Note that the ICompound interface is /empty/.
There's no additional signatures, as it's just a convenience for
combining/gathering common interfaces together. If I declare the Interfaces
explicitly (rather than using ICompound) then v0.100 does the right thing.

The "empty" Interface may be a factor?



"antiAlias" <fu bar.com> wrote in message
news:cgaob0$10as$1 digitaldaemon.com...
 "v0.99: Fixed MI bug with interface vtbl dispatch."

 Whatever you fixed doesn't resolve the broken MI-Interface vTable

afflicting
 certain areas of Mango ... the wrong methods are still invoked when

calling
 through an interface.


 "Walter" <newshound digitalmars.com> wrote in message
 news:cg5lqs$n6p$1 digitaldaemon.com...
 Ok, I'll check them out.

 "antiAlias" <fu bar.com> wrote in message
 news:cg5gte$k4c$1 digitaldaemon.com...
 "Walter" wrote...
 What exactly is mango waiting on?

 - The ongoing Interface issues (now described as Interface MI issues)
 originally noted in April, then again in June. Release notes for v0.99


 say
 this is resolved, though I haven't tried it yet. Certain areas of



Mango
 have
 been terribly fragile for months due to this, and non-extensible. For
 example, whenever a gpf would occur in relation to Interface usage,



I'd
 go
 in and switch the order in which Interfaces were declared in class
 declarations (lunacy!). It would eliminate the gpf for one area but



move
 it
 to another. Adding additional Interfaces to class declarations simply
 aggravated the problem, so Mango development vis-a-vis Interfaces just
 stopped.

 - The version() operational discrepancy between Windows and linux was

 still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

 - The static-constructor ordering noted in May, June, and July. I've


 held
 off on a few things until that is resolved.

 - The inability of a class to satisfy an Interface contract via its
 inheritance tree (noted in April). This is a design issue rather than



a
 bug,
 but it places a burden on Mango clients that is totally unnecessary



and,
 frankly, untenable. You don't really run into this until you start



using
 Interfaces a lot. Mango is an Interface-based design so, naturally,
 comes-a-cropper over this all the time. You note there's a potential
 type-hole involved (though the hole is of a questionable nature, IMO),


 yet
 there are likely several ways to avoid said hole completely while



still
 providing the required functionality.

 - Corrupt stack when assigning 'out' arguments within a nested/inner
 function.


 Each of these has stalled, delayed, or halted Mango development in one


 way
 or another. Sure, one just finds something else to work on; but it's


 hard
 to
 maintain focus when ongoing issues are not resolved for months on end.

"Walter" <newshound digitalmars.com> writes:

Can you post a complete example, please?

"antiAlias" <fu bar.com> writes:

I would, but Mango is a bit too big <g>

Can you work with the original source, if I guide you on it?


"Walter" <newshound digitalmars.com> wrote in message
news:cgb2ai$18df$1 digitaldaemon.com...
 Can you post a complete example, please?

"Walter" <newshound digitalmars.com> writes:

If it's too big for you, what hope have I, who is totally unfamiliar with
it, to even identify what's going wrong?

"antiAlias" <fu bar.com> wrote in message
news:cgb37c$190f$1 digitaldaemon.com...
 I would, but Mango is a bit too big <g>

 Can you work with the original source, if I guide you on it?


 "Walter" <newshound digitalmars.com> wrote in message
 news:cgb2ai$18df$1 digitaldaemon.com...
 Can you post a complete example, please?

"antiAlias" <fu bar.com> writes:

I offered to guide you; doesn't that help? There is a small example program
that exhibits the bug, but it uses a reasonable portion of Mango. Therefore,
it's way too big to post.

I suppose I was hoping you might take a look at the Interface inheritance
layout, inspect the generated vTables, and deduce a few ideas to try out in
the compiler in terms of resolving the issue. Change the compiler; compile
the example again; see if it got fixed; if so, make your own small test-case
for regression purposes (once you understood exactly how the problem arose).

You noted recently in a post to Matthew that if a bug could not be whittled
down to the requisite "10 line" size, then what one had would be good
enough. That's the situation here, and I'd like to try and help you resolve
this bug. I can tell you exactly how to change the source to make said bug
appear and disappear; is that not helpful? I'll add a version() block if it
would make it easier?

What do you wish to do?


"Walter" <newshound digitalmars.com> wrote in message
news:cgeu4l$l4d$1 digitaldaemon.com...
 If it's too big for you, what hope have I, who is totally unfamiliar with
 it, to even identify what's going wrong?

 "antiAlias" <fu bar.com> wrote in message
 news:cgb37c$190f$1 digitaldaemon.com...
 I would, but Mango is a bit too big <g>

 Can you work with the original source, if I guide you on it?


 "Walter" <newshound digitalmars.com> wrote in message
 news:cgb2ai$18df$1 digitaldaemon.com...
 Can you post a complete example, please?

"Walter" <newshound digitalmars.com> writes:

"antiAlias" <fu bar.com> wrote in message
news:cgf0en$ma1$1 digitaldaemon.com...
 I offered to guide you; doesn't that help? There is a small example

program
 that exhibits the bug, but it uses a reasonable portion of Mango.

Therefore,
 it's way too big to post.

 I suppose I was hoping you might take a look at the Interface inheritance
 layout, inspect the generated vTables, and deduce a few ideas to try out

in
 the compiler in terms of resolving the issue. Change the compiler; compile
 the example again; see if it got fixed; if so, make your own small

test-case
 for regression purposes (once you understood exactly how the problem

arose).
 You noted recently in a post to Matthew that if a bug could not be

whittled
 down to the requisite "10 line" size, then what one had would be good
 enough. That's the situation here, and I'd like to try and help you

resolve
 this bug. I can tell you exactly how to change the source to make said bug
 appear and disappear; is that not helpful? I'll add a version() block if

it
 would make it easier?

My intent was to show how to do a shrink. All of them did shrink to 10 or 15
lines.

 What do you wish to do?

Copy mango to another directory, and delete everything that is not
absolutely necessary for reproducing the problem. I ask you to believe me
that that is far more productive at finding the problem then it is trying to
disassemble the object files and poke through thousands of lines of
irrelevant instructions.

"antiAlias" <fu bar.com> writes:

Appreciated. Please let me know if you need further input.

"Walter"  wrote
 Ok, I'll check them out.




 "antiAlias" <fu bar.com> wrote in message
 news:cg5gte$k4c$1 digitaldaemon.com...
 "Walter" wrote...
 What exactly is mango waiting on?

 - The ongoing Interface issues (now described as Interface MI issues)
 originally noted in April, then again in June. Release notes for v0.99


say
 this is resolved, though I haven't tried it yet. Certain areas of Mango

 have
 been terribly fragile for months due to this, and non-extensible. For
 example, whenever a gpf would occur in relation to Interface usage, I'd


go
 in and switch the order in which Interfaces were declared in class
 declarations (lunacy!). It would eliminate the gpf for one area but move

 it
 to another. Adding additional Interfaces to class declarations simply
 aggravated the problem, so Mango development vis-a-vis Interfaces just
 stopped.

 - The version() operational discrepancy between Windows and linux was

 still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

 - The static-constructor ordering noted in May, June, and July. I've


held
 off on a few things until that is resolved.

 - The inability of a class to satisfy an Interface contract via its
 inheritance tree (noted in April). This is a design issue rather than a

 bug,
 but it places a burden on Mango clients that is totally unnecessary and,
 frankly, untenable. You don't really run into this until you start using
 Interfaces a lot. Mango is an Interface-based design so, naturally,
 comes-a-cropper over this all the time. You note there's a potential
 type-hole involved (though the hole is of a questionable nature, IMO),


yet
 there are likely several ways to avoid said hole completely while still
 providing the required functionality.

 - Corrupt stack when assigning 'out' arguments within a nested/inner
 function.


 Each of these has stalled, delayed, or halted Mango development in one


way
 or another. Sure, one just finds something else to work on; but it's


hard
 to
 maintain focus when ongoing issues are not resolved for months on end.

"Walter" <newshound digitalmars.com> writes:

Message numbers of the specific ones would also be most helpful.

"antiAlias" <fu bar.com> wrote in message
news:cgesu7$k2r$1 digitaldaemon.com...
 Appreciated. Please let me know if you need further input.

 "Walter"  wrote
 Ok, I'll check them out.




 "antiAlias" <fu bar.com> wrote in message
 news:cg5gte$k4c$1 digitaldaemon.com...
 "Walter" wrote...
 What exactly is mango waiting on?

 - The ongoing Interface issues (now described as Interface MI issues)
 originally noted in April, then again in June. Release notes for v0.99


 say
 this is resolved, though I haven't tried it yet. Certain areas of



Mango
 have
 been terribly fragile for months due to this, and non-extensible. For
 example, whenever a gpf would occur in relation to Interface usage,



I'd
 go
 in and switch the order in which Interfaces were declared in class
 declarations (lunacy!). It would eliminate the gpf for one area but



move
 it
 to another. Adding additional Interfaces to class declarations simply
 aggravated the problem, so Mango development vis-a-vis Interfaces just
 stopped.

 - The version() operational discrepancy between Windows and linux was

 still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

 - The static-constructor ordering noted in May, June, and July. I've


 held
 off on a few things until that is resolved.

 - The inability of a class to satisfy an Interface contract via its
 inheritance tree (noted in April). This is a design issue rather than



a
 bug,
 but it places a burden on Mango clients that is totally unnecessary



and,
 frankly, untenable. You don't really run into this until you start



using
 Interfaces a lot. Mango is an Interface-based design so, naturally,
 comes-a-cropper over this all the time. You note there's a potential
 type-hole involved (though the hole is of a questionable nature, IMO),


 yet
 there are likely several ways to avoid said hole completely while



still
 providing the required functionality.

 - Corrupt stack when assigning 'out' arguments within a nested/inner
 function.


 Each of these has stalled, delayed, or halted Mango development in one


 way
 or another. Sure, one just finds something else to work on; but it's


 hard
 to
 maintain focus when ongoing issues are not resolved for months on end.

"antiAlias" <fu bar.com> writes:

"Walter" <newshound digitalmars.com> wrote
 Message numbers of the specific ones would also be most helpful.

No problem ... here's a few:

news:c74fis$gfi$1 digitaldaemon.com
news:c9h3us$2qjl$1 digitaldaemon.com
news:c9igfc$1r64$1 digitaldaemon.com
news:c9j0lk$2i1a$1 digitaldaemon.com
news:c9lc9k$2vc0$1 digitaldaemon.com
news:cbla1e$1llq$1 digitaldaemon.com
news:ccc8kc$306m$1 digitaldaemon.com
news:cctgns$sst$1 digitaldaemon.com
news:c4f7rj$2qgi$1 digitaldaemon.com
news:c5phf1$1idh$1 digitaldaemon.com
news:cgaqe6$11je$1 digitaldaemon.com

The "Satisfying Interface Contracts via Inheritance" issue is not written up
as a bug, because it's a (crucial, IMO)missing feature. I sent email to you
about this one on April 8th, 12:08pm PST, and it's been noted a few times
since then.



 "antiAlias" <fu bar.com> wrote in message
 news:cgesu7$k2r$1 digitaldaemon.com...
 Appreciated. Please let me know if you need further input.

 "Walter"  wrote
 Ok, I'll check them out.




 "antiAlias" <fu bar.com> wrote in message
 news:cg5gte$k4c$1 digitaldaemon.com...
 "Walter" wrote...
 What exactly is mango waiting on?

 - The ongoing Interface issues (now described as Interface MI




issues)
 originally noted in April, then again in June. Release notes for




v0.99
 say
 this is resolved, though I haven't tried it yet. Certain areas of



 Mango
 have
 been terribly fragile for months due to this, and non-extensible.




For
 example, whenever a gpf would occur in relation to Interface usage,



 I'd
 go
 in and switch the order in which Interfaces were declared in class
 declarations (lunacy!). It would eliminate the gpf for one area but



 move
 it
 to another. Adding additional Interfaces to class declarations




simply
 aggravated the problem, so Mango development vis-a-vis Interfaces




just
 stopped.

 - The version() operational discrepancy between Windows and linux




was
 still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

 - The static-constructor ordering noted in May, June, and July. I've


 held
 off on a few things until that is resolved.

 - The inability of a class to satisfy an Interface contract via its
 inheritance tree (noted in April). This is a design issue rather




than
 a
 bug,
 but it places a burden on Mango clients that is totally unnecessary



 and,
 frankly, untenable. You don't really run into this until you start



 using
 Interfaces a lot. Mango is an Interface-based design so, naturally,
 comes-a-cropper over this all the time. You note there's a potential
 type-hole involved (though the hole is of a questionable nature,




IMO),
 yet
 there are likely several ways to avoid said hole completely while



 still
 providing the required functionality.

 - Corrupt stack when assigning 'out' arguments within a nested/inner
 function.


 Each of these has stalled, delayed, or halted Mango development in




one
 way
 or another. Sure, one just finds something else to work on; but it's


 hard
 to
 maintain focus when ongoing issues are not resolved for months on




end.

"Walter" <newshound digitalmars.com> writes:

Thanks!

"antiAlias" <fu bar.com> wrote in message
news:cgnvea$1u5g$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote
 Message numbers of the specific ones would also be most helpful.

 No problem ... here's a few:

 news:c74fis$gfi$1 digitaldaemon.com
 news:c9h3us$2qjl$1 digitaldaemon.com
 news:c9igfc$1r64$1 digitaldaemon.com
 news:c9j0lk$2i1a$1 digitaldaemon.com
 news:c9lc9k$2vc0$1 digitaldaemon.com
 news:cbla1e$1llq$1 digitaldaemon.com
 news:ccc8kc$306m$1 digitaldaemon.com
 news:cctgns$sst$1 digitaldaemon.com
 news:c4f7rj$2qgi$1 digitaldaemon.com
 news:c5phf1$1idh$1 digitaldaemon.com
 news:cgaqe6$11je$1 digitaldaemon.com

 The "Satisfying Interface Contracts via Inheritance" issue is not written

up
 as a bug, because it's a (crucial, IMO)missing feature. I sent email to

you
 about this one on April 8th, 12:08pm PST, and it's been noted a few times
 since then.



 "antiAlias" <fu bar.com> wrote in message
 news:cgesu7$k2r$1 digitaldaemon.com...
 Appreciated. Please let me know if you need further input.

 "Walter"  wrote
 Ok, I'll check them out.




 "antiAlias" <fu bar.com> wrote in message
 news:cg5gte$k4c$1 digitaldaemon.com...
 "Walter" wrote...
 What exactly is mango waiting on?

 - The ongoing Interface issues (now described as Interface MI




 issues)
 originally noted in April, then again in June. Release notes for




 v0.99
 say
 this is resolved, though I haven't tried it yet. Certain areas of



 Mango
 have
 been terribly fragile for months due to this, and non-extensible.




 For
 example, whenever a gpf would occur in relation to Interface





usage,
 I'd
 go
 in and switch the order in which Interfaces were declared in class
 declarations (lunacy!). It would eliminate the gpf for one area





but
 move
 it
 to another. Adding additional Interfaces to class declarations




 simply
 aggravated the problem, so Mango development vis-a-vis Interfaces




 just
 stopped.

 - The version() operational discrepancy between Windows and linux




 was
 still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

 - The static-constructor ordering noted in May, June, and July.





I've
 held
 off on a few things until that is resolved.

 - The inability of a class to satisfy an Interface contract via





its
 inheritance tree (noted in April). This is a design issue rather




 than
 a
 bug,
 but it places a burden on Mango clients that is totally





unnecessary
 and,
 frankly, untenable. You don't really run into this until you start



 using
 Interfaces a lot. Mango is an Interface-based design so,





naturally,
 comes-a-cropper over this all the time. You note there's a





potential
 type-hole involved (though the hole is of a questionable nature,




 IMO),
 yet
 there are likely several ways to avoid said hole completely while



 still
 providing the required functionality.

 - Corrupt stack when assigning 'out' arguments within a





nested/inner
 function.


 Each of these has stalled, delayed, or halted Mango development in




 one
 way
 or another. Sure, one just finds something else to work on; but





it's
 hard
 to
 maintain focus when ongoing issues are not resolved for months on




 end.

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg3tiu$2rpa$2 digitaldaemon.com...
 Walter?

Sounds like just making a 'beta' available, like I do for DMC++.

Andy Friesen <andy ikagames.com> writes:

Walter wrote:
 I have not attempted to compile DWT.

It all builds now, actually.

The final* trick is getting rid of some freaky link errors.

  -- andy

* Not final.  Once it /links/, we get to try making it /work/.

Ben Hinkle <bhinkle4 juno.com> writes:

 I, for one, cannot fathom why there's been zero support for the DWT
 project specifically; it's perhaps the most promising & valuable to a
 significant audience segment -- yet it's been stalled since the get-go
 over forward-reference issues.

I just downloaded DWT and tried compiling it. It didn't end up working
because I'm on Linux and it only supports Windows, but the first two build
problems were simple module naming problems. The module dwt.util.throwable
was called dwt.util.Throwable and dwt.util.util was called
dwt.internal.util.util. Once I made those two changes it looked to me like
the only problems were due to lack of Linux support.
Also I noticed lots of code was using the style
class Foo {
 private import dtw.bar.baz;
 ...
}
which Walter has suggested avoiding. Since that style was to work around
forward-reference issues it shouldn't be needed.

-Ben