View mode: basic / threaded / horizontal-split · Log in · Help
November 12, 2012
dmd: ../ztc/aa.c:423: void AArray::rehash_x(aaA*, aaA**, size_t): Assertion `0' failed.
OK, as this problem seems to not be of any priority, let me state things 
here.

I'm working on a program in D that is ~20 000 LOC. This is a non trivial 
program, but really an huge one.

Compiling it trigger the error mentioned above. To have real data to 
show, I did some test, right now, and as a first shot (so it may not be 
really accurate, but I didn't either choose the worse data, just the 
first I can get).

On 10 compilation of the exact same source code, 8 ended up triggering 
the error. YES 8 out of 10 !

Not to mention the compilation process take ~50s to fail and ~53s to 
succed (so yes, you basically have to wait almost as long to get the 
error than to get something useful) and it is not possible to break it 
down because of this bug : 
http://d.puremagic.com/issues/show_bug.cgi?id=8997

The compilation process use now about 2.2Gb of RAM. I read Walter today 
saying that memory usage isn't an issue in dmd, and that GC slowed it 
down significantly. YOU KNOW WHAT ? It is damn slow because I have to 
compile my program 4 time on average to get something, and recompile 
*EVERYTHING EVERY SINGLE TIME*. Ha and pushing my programs in the swap 
isn't really improving my user experience.

How the hell anybody is supposed to develop any serious project in such 
conditions ?

When does we stop pushing MOAR shit into master and get something 
working ? I mean working for real, not on some marketing speech, or some 
rhetorical assertion that the only dead software are stable ?

PS: I'm also facing a bug that cause the GC to collect live object, and 
the only solution I have now is to disable GC. But hey, the same goes 
for dmd for ages, so it may not be an issue after all !
November 12, 2012
Re: dmd: ../ztc/aa.c:423: void AArray::rehash_x(aaA*, aaA**, size_t): Assertion `0' failed.
Le 12/11/2012 19:02, deadalnix a écrit :
> OK, as this problem seems to not be of any priority, let me state things
> here.
>
> I'm working on a program in D that is ~20 000 LOC. This is a non trivial
> program, but really an huge one.
>
> Compiling it trigger the error mentioned above. To have real data to
> show, I did some test, right now, and as a first shot (so it may not be
> really accurate, but I didn't either choose the worse data, just the
> first I can get).
>
> On 10 compilation of the exact same source code, 8 ended up triggering
> the error. YES 8 out of 10 !
>
> Not to mention the compilation process take ~50s to fail and ~53s to
> succed (so yes, you basically have to wait almost as long to get the
> error than to get something useful) and it is not possible to break it
> down because of this bug :
> http://d.puremagic.com/issues/show_bug.cgi?id=8997
>
> The compilation process use now about 2.2Gb of RAM. I read Walter today
> saying that memory usage isn't an issue in dmd, and that GC slowed it
> down significantly. YOU KNOW WHAT ? It is damn slow because I have to
> compile my program 4 time on average to get something, and recompile
> *EVERYTHING EVERY SINGLE TIME*. Ha and pushing my programs in the swap
> isn't really improving my user experience.
>
> How the hell anybody is supposed to develop any serious project in such
> conditions ?
>
> When does we stop pushing MOAR shit into master and get something
> working ? I mean working for real, not on some marketing speech, or some
> rhetorical assertion that the only dead software are stable ?
>
> PS: I'm also facing a bug that cause the GC to collect live object, and
> the only solution I have now is to disable GC. But hey, the same goes
> for dmd for ages, so it may not be an issue after all !

Ha, and the report : http://d.puremagic.com/issues/show_bug.cgi?id=8596
Top | Discussion index | About this forum | D home