"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cg18ii$2p6f$1@digitaldaemon.com...
> > I, for one, cannot fathom why there's been zero support for the DWT
project
> > specifically; it's perhaps the most promising & valuable to a
significant
> > audience segment -- yet it's been stalled since the get-go over forward-reference issues.

The fw issues have been resolved.

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

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

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

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

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

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

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

I have not attempted to compile DWT.

> It's certainly not my intention to give you a hard-time, Walter, but the point remains that if the persistent FR issues had been given some
priority
> way back in early March, or April, or May (instead of August)  there's a reasonable chance we'd have a partly operational DWT right now. The FR problems were noted back then.
>
> This is not about crying-over-spilt-milk; it's about how to avoid the same long-term problem going forward. What can we do in this respect?

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

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

"Walter" <newshound@digitalmars.com> wrote in message news:cg3220$2esv$1@digitaldaemon.com...
>
> "antiAlias" <fu@bar.com> wrote in message news:cg3110$2dl6$1@digitaldaemon.com...
> > "Walter" wrote ...
> > > > > audience segment -- yet it's been stalled since the get-go over forward-reference issues.
> > >
> > > The fw issues have been resolved.
> >
> > Have they really?
>
> The ones reported have been, except for struct fr's.
>
> > More power to you if that's really the case (all the DWT
> > inner-imports can all be removed, and everything compiles cleanly? Antonio
> > might also care to comment on this particular topic).
>
> I have not attempted to compile DWT.
>
> > It's certainly not my intention to give you a hard-time, Walter, but the point remains that if the persistent FR issues had been given some
> priority
> > way back in early March, or April, or May (instead of August)  there's a reasonable chance we'd have a partly operational DWT right now. The FR problems were noted back then.
> >
> > This is not about crying-over-spilt-milk; it's about how to avoid the same long-term problem going forward. What can we do in this respect?
>
> There's only one of me, and early this year there was an explosion in the number of people using D. As a consequence, a lot of compiler bugs and shortcomings in the language were uncovered. I fell way, way behind. I still haven't read all the threads in the old D newsgroup, for example. There's frequently over a hundred posts a day. They are nearly all technical, and have to be read slowly. So it might sometimes appear that I am ignoring an issue, when in reality I just haven't read that thread yet. There's not much chance I can play around with DWT myself, I have to rely on others to compile it, isolate, and report problems.
>
> I hope that, long term, the compiler will get much more stable and so this will be less of a problem.

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

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


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

Dave wrote:

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

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

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

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

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

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

- Dave

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

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg32e6$2f4b$1@digitaldaemon.com...
> Wouldn't one smart move at this point be to appoint a panel of NG
moderators?
>
> Perhaps in conjunction with a new digitalmars.D.strategy ng that was
moderated only? Then you could, in conscience,
> ignore the main ngs.

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

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

That'll have to happen at some point.

Andy Friesen schrieb:

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

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

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

Hm. Interesting to see that again.

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

Uh oh. I gotta better study.

-eye

"Walter" <newshound@digitalmars.com> wrote in message news:cg34dh$2gv6$1@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg32e6$2f4b$1@digitaldaemon.com...
> > Wouldn't one smart move at this point be to appoint a panel of NG
> moderators?
> >
> > Perhaps in conjunction with a new digitalmars.D.strategy ng that was
> moderated only? Then you could, in conscience,
> > ignore the main ngs.
>
> But I don't want to hide behind moderators and ignore the main ng. I never have in 25 years of supporting compilers, and that's been one of the strengths of my products. Part of the reason for the creation of the bugs ng, however, was to make it easier to identify the more critical issues.

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

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

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

> > Another idea might be that you include DTL, DWT and Mango in your
> regression tests.
>
> That'll have to happen at some point.

Good to hear you're responsive to that.

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

Matthew wrote:

> 
> "Walter" <newshound@digitalmars.com> wrote in message news:cg34dh$2gv6$1@digitaldaemon.com...
>>
>> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg32e6$2f4b$1@digitaldaemon.com...
>> > Wouldn't one smart move at this point be to appoint a panel of NG
>> moderators?
>> >
> 
>> > Another idea might be that you include DTL, DWT and Mango in your
>> regression tests.
>>
>> That'll have to happen at some point.
> 
> Good to hear you're responsive to that.

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

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

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

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

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

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

- Dave