www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Linux compiler segfaults compiling DTL v0.1.1

reply Dave <Dave_member pathlink.com> writes:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit


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.
Aug 18 2004
next sibling parent 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
Aug 18 2004
prev sibling next sibling parent reply "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.

Aug 18 2004
parent reply Dave <Dave_member pathlink.com> writes:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit


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.


Aug 19 2004
parent 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.



Aug 19 2004
prev sibling parent reply "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.

Aug 18 2004
parent reply "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?
Aug 18 2004
next sibling parent reply "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.
Aug 18 2004
next sibling parent reply 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
Aug 18 2004
next sibling parent 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/
Aug 18 2004
prev sibling parent 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
Aug 19 2004
prev sibling parent reply "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


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


 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

 But delving in again the other day I think there were less than 200 since

 appreciate the reduced level of future shock, I hope it's not indicative

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.
Aug 19 2004
parent reply "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?
Aug 19 2004
parent reply "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

 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.
Aug 19 2004
next sibling parent reply "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

 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.
Aug 19 2004
parent reply "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

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

 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

That'll have to happen at some point.
Aug 19 2004
parent reply "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

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

 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

That'll have to happen at some point.

Good to hear you're responsive to that.
Aug 19 2004
parent reply 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



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

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
Aug 19 2004
parent reply "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



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

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
Aug 19 2004
next sibling parent reply "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
Aug 19 2004
next sibling parent 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
Aug 19 2004
prev sibling next sibling parent "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. :-)
Aug 19 2004
prev sibling parent reply "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

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

 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.
Aug 20 2004
parent "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
Aug 20 2004
prev sibling parent reply 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
Aug 19 2004
parent reply "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?
Aug 19 2004
next sibling parent reply "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

 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




 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


 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


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


 logistics could be worked out or not.

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

 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

 already, and most certainly should, have the infrastructure to make beta

 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

 they're free to miss an intermediate release, and it's tough if their code

 with the next intermediate or two.

 Walter?

Aug 19 2004
next sibling parent "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

 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




 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


 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


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


 logistics could be worked out or not.

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

 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

 already, and most certainly should, have the infrastructure to make beta

 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

 they're free to miss an intermediate release, and it's tough if their code

 with the next intermediate or two.

 Walter?


Aug 19 2004
prev sibling parent reply "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

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

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

What exactly is mango waiting on?
Aug 20 2004
parent reply "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.
Aug 20 2004
parent reply "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

 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

 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

 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

 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

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

Aug 20 2004
next sibling parent reply "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

 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

 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

 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

 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

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


Aug 20 2004
next sibling parent reply 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).
Aug 20 2004
parent "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


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

Aug 20 2004
prev sibling parent reply "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

 it'd be very useful to have an explanation.

There was a long and rather acrimonious thread about this recently on digitalmars.D.
Aug 20 2004
next sibling parent "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

 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. ;)
Aug 20 2004
prev sibling parent "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

 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
Aug 20 2004
prev sibling next sibling parent reply "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


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

 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


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

 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

 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

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


 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

 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),


 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


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


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


Aug 22 2004
parent reply "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

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

 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


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



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



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



 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

 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

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


 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



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



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



 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),


 there are likely several ways to avoid said hole completely while



 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


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


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



Aug 22 2004
parent reply "Walter" <newshound digitalmars.com> writes:
Can you post a complete example, please?
Aug 22 2004
parent reply "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?

Aug 22 2004
parent reply "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?


Aug 24 2004
parent reply "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?



Aug 24 2004
parent "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

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

 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

 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

 for regression purposes (once you understood exactly how the problem

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

 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

 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

 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.
Aug 24 2004
prev sibling parent reply "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


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

 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


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

 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

 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

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


 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

 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),


 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


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


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


Aug 24 2004
parent reply "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


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



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



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



 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

 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

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


 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



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



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



 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),


 there are likely several ways to avoid said hole completely while



 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


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


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



Aug 24 2004
parent reply "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




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




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



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




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



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



 it
 to another. Adding additional Interfaces to class declarations




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




 stopped.

 - The version() operational discrepancy between Windows and linux




 still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

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


 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




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



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



 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,




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



 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




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


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








Aug 27 2004
parent "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

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

 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




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




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



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




 example, whenever a gpf would occur in relation to Interface





 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





 move
 it
 to another. Adding additional Interfaces to class declarations




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




 stopped.

 - The version() operational discrepancy between Windows and linux




 still
 causing grief recently.

 - Static constructors not invoked for inner/nested classes.

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





 held
 off on a few things until that is resolved.

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





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




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





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



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





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





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




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



 providing the required functionality.

 - Corrupt stack when assigning 'out' arguments within a





 function.


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




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





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









Aug 28 2004
prev sibling parent "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++.
Aug 20 2004
prev sibling parent 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/.
Aug 19 2004
prev sibling parent 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
Aug 19 2004