Attached is a log when compiled with:

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

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

Dave 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

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

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

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

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

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

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/

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

> 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