digitalmars.D.bugs - Linux compiler segfaults compiling DTL v0.1.1
- 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,
- antiAlias (12/63) Aug 22 2004 "v0.99: Fixed MI bug with interface vtbl dispatch."
- antiAlias (27/93) Aug 22 2004 more info:
- antiAlias (8/59) Aug 24 2004 say
- 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
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
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
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
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
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. - DaveI 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
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
"Matthew" <admin.hat stlsoft.dot.org> wroteAlthough 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
"antiAlias" <fu bar.com> wrote in message news:cg17jq$2oh1$1 digitaldaemon.com..."Matthew" <admin.hat stlsoft.dot.org> wroteDon'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.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
Matthew wrote:"antiAlias" <fu bar.com> wrote in message news:cg17jq$2oh1$1 digitaldaemon.com...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"Matthew" <admin.hat stlsoft.dot.org> wroteDon'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.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
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
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
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cg18ii$2p6f$1 digitaldaemon.com...projectI, for one, cannot fathom why there's been zero support for the DWTsignificantspecifically; it's perhaps the most promising & valuable to aThe fw issues have been resolved.audience segment -- yet it's been stalled since the get-go over forward-reference issues.I've noticed a distinct drop in traffic on the main ng. Normally each weekI am away there are hundreds of new messages.But delving in again the other day I think there were less than 200 sincemy last snuffle around the trough. While Iappreciate the reduced level of future shock, I hope it's not indicativeof 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.
Aug 19 2004
"Walter" wrote ...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?The fw issues have been resolved.audience segment -- yet it's been stalled since the get-go over forward-reference issues.
Aug 19 2004
"antiAlias" <fu bar.com> wrote in message news:cg3110$2dl6$1 digitaldaemon.com..."Walter" wrote ...The ones reported have been, except for struct fr's.Have they really?The fw issues have been resolved.audience segment -- yet it's been stalled since the get-go over forward-reference issues.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 somepriorityway 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
"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...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" wrote ...The ones reported have been, except for struct fr's.Have they really?The fw issues have been resolved.audience segment -- yet it's been stalled since the get-go over forward-reference issues.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 somepriorityway 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
"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 NGmoderators?Perhaps in conjunction with a new digitalmars.D.strategy ng that wasmoderated 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 yourregression tests. That'll have to happen at some point.
Aug 19 2004
"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...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.Wouldn't one smart move at this point be to appoint a panel of NGmoderators?Perhaps in conjunction with a new digitalmars.D.strategy ng that wasmoderated 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.Good to hear you're responsive to that.Another idea might be that you include DTL, DWT and Mango in yourregression tests. That'll have to happen at some point.
Aug 19 2004
Matthew wrote:"Walter" <newshound digitalmars.com> wrote in message news:cg34dh$2gv6$1 digitaldaemon.com...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.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 NGmoderators?Good to hear you're responsive to that.Another idea might be that you include DTL, DWT and Mango in yourregression tests. That'll have to happen at some point.
Aug 19 2004
"Dave" <Dave_member pathlink.com> wrote in message news:cg3g1i$2lrs$1 digitaldaemon.com...Matthew wrote:Don't know what you mean. Do you mean the import lib??"Walter" <newshound digitalmars.com> wrote in message news:cg34dh$2gv6$1 digitaldaemon.com...How about something along these lines until Walter is ready to add those libs. to his reg. testing: Walter provides the "important" lib."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 NGmoderators?Good to hear you're responsive to that.Another idea might be that you include DTL, DWT and Mango in yourregression tests. That'll have to happen at some point.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
"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
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
"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
"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, whichissending non-released versions of the compiler to test it. But instead ofdoingit 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
"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
Matthew wrote:"Dave" <Dave_member pathlink.com> wrote in message news:cg3g1i$2lrs$1 digitaldaemon.com...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. - DaveMatthew 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?
Aug 19 2004
"Dave" <Dave_member pathlink.com> wrote in message news:cg3r7p$2qi9$1 digitaldaemon.com...Matthew wrote: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?"Dave" <Dave_member pathlink.com> wrote in message news:cg3g1i$2lrs$1 digitaldaemon.com...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.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?
Aug 19 2004
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 messagenews:cg3r7p$2qi9$1 digitaldaemon.com...generalMatthew 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 b4suggestionWow, my post was really cryptic. Sorry.. You had mentioned "important" library developers earlier, and myrelease, and they do their own regression testing.Sorry, I must be thick. Can you rephrase?andboils 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 whilethestill include regression testing on major libraries. I have no idea ifNormally takes me three or four rewrites, if ever,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 widergroup than that mooted thus far - can, probablyalready, and most certainly should, have the infrastructure to make betainstallations and conduct builds with old andnew 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 thinkthey're free to miss an intermediate release, and it's tough if their codeloses out. Doubtless they could "catch up"with the next intermediate or two. Walter?
Aug 19 2004
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 messagenews:cg3r7p$2qi9$1 digitaldaemon.com...generalMatthew 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 b4suggestionWow, my post was really cryptic. Sorry.. You had mentioned "important" library developers earlier, and myrelease, and they do their own regression testing.Sorry, I must be thick. Can you rephrase?andboils 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 whilethestill include regression testing on major libraries. I have no idea ifNormally takes me three or four rewrites, if ever,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 widergroup than that mooted thus far - can, probablyalready, and most certainly should, have the infrastructure to make betainstallations and conduct builds with old andnew 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 thinkthey're free to miss an intermediate release, and it's tough if their codeloses out. Doubtless they could "catch up"with the next intermediate or two. Walter?
Aug 19 2004
"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 thanitwas six months ago, yet Mango (for instance) is still waiting forresolutionon things noted months ago. It's rather likely that others are in the same boat.What exactly is mango waiting on?
Aug 20 2004
"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
Ok, I'll check them out. "antiAlias" <fu bar.com> wrote in message news:cg5gte$k4c$1 digitaldaemon.com..."Walter" wrote...haveWhat 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 Mangobeen 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 moveitto 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 wasstillcausing 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 abug,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 hardtomaintain focus when ongoing issues are not resolved for months on end.
Aug 20 2004
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...haveWhat 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 Mangobeen 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 moveitto 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 wasstillcausing 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 abug,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 hardtomaintain focus when ongoing issues are not resolved for months on end.
Aug 20 2004
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
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:theCan either/both of you report on the results of resolution of all (buttrivial) 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
"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 vsinterface 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.
Aug 20 2004
"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...Alas, I don't have much bandwidth left, so I thought I could do a last minute, definitive, cramming once it's all sorted. ;)For example, I definitely want to know a lot more about the class vsinterface 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.
Aug 20 2004
"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...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.comFor example, I definitely want to know a lot more about the class vsinterface 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.
Aug 20 2004
"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...say"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.99gothis is resolved, though I haven't tried it yet. Certain areas of Mangohavebeen terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage, I'dheldin and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but moveitto 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 wasstillcausing grief recently. - Static constructors not invoked for inner/nested classes. - The static-constructor ordering noted in May, June, and July. I'veyetoff 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 abug,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),waythere 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 onehardor another. Sure, one just finds something else to work on; but it'stomaintain focus when ongoing issues are not resolved for months on end.
Aug 22 2004
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 vTableafflictingcertain areas of Mango ... the wrong methods are still invoked whencallingthrough an interface. "Walter" <newshound digitalmars.com> wrote in message news:cg5lqs$n6p$1 digitaldaemon.com...MangoOk, I'll check them out. "antiAlias" <fu bar.com> wrote in message news:cg5gte$k4c$1 digitaldaemon.com...say"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.99this is resolved, though I haven't tried it yet. Certain areas ofI'dhavebeen terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage,gomovein and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area butaitheldto 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 wasstillcausing grief recently. - Static constructors not invoked for inner/nested classes. - The static-constructor ordering noted in May, June, and July. I'veoff 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 thanand,bug,but it places a burden on Mango clients that is totally unnecessaryusingfrankly, untenable. You don't really run into this until you startstillyetInterfaces 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 whilewayproviding 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 onehardor another. Sure, one just finds something else to work on; but it'stomaintain focus when ongoing issues are not resolved for months on end.
Aug 22 2004
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
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
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
"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 exampleprogramthat 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 outinthe compiler in terms of resolving the issue. Change the compiler; compile the example again; see if it got fixed; if so, make your own smalltest-casefor regression purposes (once you understood exactly how the problemarose).You noted recently in a post to Matthew that if a bug could not bewhittleddown 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 youresolvethis 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 ifitwould 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
Appreciated. Please let me know if you need further input. "Walter" wroteOk, I'll check them out."antiAlias" <fu bar.com> wrote in message news:cg5gte$k4c$1 digitaldaemon.com...say"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.99gothis is resolved, though I haven't tried it yet. Certain areas of Mangohavebeen terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage, I'dheldin and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but moveitto 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 wasstillcausing grief recently. - Static constructors not invoked for inner/nested classes. - The static-constructor ordering noted in May, June, and July. I'veyetoff 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 abug,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),waythere 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 onehardor another. Sure, one just finds something else to work on; but it'stomaintain focus when ongoing issues are not resolved for months on end.
Aug 24 2004
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" wroteMangoOk, I'll check them out."antiAlias" <fu bar.com> wrote in message news:cg5gte$k4c$1 digitaldaemon.com...say"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.99this is resolved, though I haven't tried it yet. Certain areas ofI'dhavebeen terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage,gomovein and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area butaitheldto 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 wasstillcausing grief recently. - Static constructors not invoked for inner/nested classes. - The static-constructor ordering noted in May, June, and July. I'veoff 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 thanand,bug,but it places a burden on Mango clients that is totally unnecessaryusingfrankly, untenable. You don't really run into this until you startstillyetInterfaces 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 whilewayproviding 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 onehardor another. Sure, one just finds something else to work on; but it'stomaintain focus when ongoing issues are not resolved for months on end.
Aug 24 2004
"Walter" <newshound digitalmars.com> wroteMessage 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...issues)Appreciated. Please let me know if you need further input. "Walter" wroteOk, 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 MIv0.99originally noted in April, then again in June. Release notes forForsayMangothis is resolved, though I haven't tried it yet. Certain areas ofhavebeen terribly fragile for months due to this, and non-extensible.simplyI'dexample, whenever a gpf would occur in relation to Interface usage,gomovein and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area butitto another. Adding additional Interfaces to class declarationsjustaggravated the problem, so Mango development vis-a-vis Interfaceswasstopped. - The version() operational discrepancy between Windows and linuxthanstillheldcausing grief recently. - Static constructors not invoked for inner/nested classes. - The static-constructor ordering noted in May, June, and July. I'veoff 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 ratheraIMO),and,bug,but it places a burden on Mango clients that is totally unnecessaryusingfrankly, untenable. You don't really run into this until you startInterfaces 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,oneyetstillthere are likely several ways to avoid said hole completely whileproviding the required functionality. - Corrupt stack when assigning 'out' arguments within a nested/inner function. Each of these has stalled, delayed, or halted Mango development inend.wayhardor another. Sure, one just finds something else to work on; but it'stomaintain focus when ongoing issues are not resolved for months on
Aug 27 2004
Thanks! "antiAlias" <fu bar.com> wrote in message news:cgnvea$1u5g$1 digitaldaemon.com..."Walter" <newshound digitalmars.com> wroteupMessage 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 writtenas a bug, because it's a (crucial, IMO)missing feature. I sent email toyouabout this one on April 8th, 12:08pm PST, and it's been noted a few times since then.usage,"antiAlias" <fu bar.com> wrote in message news:cgesu7$k2r$1 digitaldaemon.com...issues)Appreciated. Please let me know if you need further input. "Walter" wroteOk, 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 MIv0.99originally noted in April, then again in June. Release notes forForsayMangothis is resolved, though I haven't tried it yet. Certain areas ofhavebeen terribly fragile for months due to this, and non-extensible.example, whenever a gpf would occur in relation to InterfacebutI'dgoin and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one areaI'vemovesimplyitto another. Adding additional Interfaces to class declarationsjustaggravated the problem, so Mango development vis-a-vis Interfaceswasstopped. - The version() operational discrepancy between Windows and linuxstillcausing grief recently. - Static constructors not invoked for inner/nested classes. - The static-constructor ordering noted in May, June, and July.itsheldoff on a few things until that is resolved. - The inability of a class to satisfy an Interface contract viaunnecessarythaninheritance tree (noted in April). This is a design issue ratherabug,but it places a burden on Mango clients that is totallynaturally,and,usingfrankly, untenable. You don't really run into this until you startInterfaces a lot. Mango is an Interface-based design so,potentialcomes-a-cropper over this all the time. You note there's anested/innerIMO),type-hole involved (though the hole is of a questionable nature,yetstillthere are likely several ways to avoid said hole completely whileproviding the required functionality. - Corrupt stack when assigning 'out' arguments within ait'sonefunction. Each of these has stalled, delayed, or halted Mango development inwayor another. Sure, one just finds something else to work on; butend.hardtomaintain focus when ongoing issues are not resolved for months on
Aug 28 2004
"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
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
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