www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - stops compiling

reply debugger <debugger_member pathlink.com> writes:
dmd 0.149,Win stops compiling without messsage if number of statements is too
large.

void init1(){}
void init2(){
init1();
// ... 16,000 times -> stops 
//     only 8,000 times -> compiles
init1();
}
void init3(){}

The effect can be seen with the -v option, because init4 does not get code
generated
Mar 18 2006
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

debugger schrieb am 2006-03-19:

 dmd 0.149,Win stops compiling without messsage if number of statements is too
 large.

 void init1(){}
 void init2(){
 init1();
 // ... 16,000 times -> stops 
 //     only 8,000 times -> compiles
 init1();
 }
 void init3(){}

 The effect can be seen with the -v option, because init4 does not get code
 generated



I can't reproduce this. Are you sure the code above is complete
(I see no "init4")?

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFEH0jH3w+/yD4P9tIRApmUAJ9yw9hU7Cgqbi/Zq1yy1I7PxjzJ1gCfYede
LCFszuRP2cCbmNa97H4wuW0=
=BAB7
-----END PGP SIGNATURE-----
Mar 20 2006
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Thomas Kuehne wrote:

 debugger schrieb am 2006-03-19:

 dmd 0.149,Win stops compiling without messsage if number of statements is too
 large.

 void init1(){}
 void init2(){
 init1();
 // ... 16,000 times -> stops 
 //     only 8,000 times -> compiles
 init1();
 }
 void init3(){}

 The effect can be seen with the -v option, because init4 does not get code
 generated






 I can't reproduce this. Are you sure the code above is complete
 (I see no "init4")?
 
 Thomas
 
 



I think he typoed and was talking about init3, as that's the behaviour I get. I
used code like this:

void init1(){}
void init2(){
// around 16 000 calls to init1()
}
void init3(){ printf("hello"); }
void main() { init3(); }

And nothing was printed when I ran the program - in fact, -v claimed that even
main() had no code generated.

Approximately halving the number of calls to init1() (I wasn't counting how
many, just going by his approximate 16 and 8 thousand) made it work fine.
Mar 20 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Deewiant schrieb am 2006-03-21:

 Thomas Kuehne wrote:

 debugger schrieb am 2006-03-19:






[snip]


 I can't reproduce this. Are you sure the code above is complete
 (I see no "init4")?



 I think he typoed and was talking about init3, as that's the behaviour I get. I
 used code like this:

 void init1(){}
 void init2(){
 // around 16 000 calls to init1()
 }
 void init3(){ printf("hello"); }
 void main() { init3(); }

 And nothing was printed when I ran the program - in fact, -v claimed that even
 main() had no code generated.

 Approximately halving the number of calls to init1() (I wasn't counting how
 many, just going by his approximate 16 and 8 thousand) made it work fine.



Seems to be a Windows specific bug.

Does
http://dstress.kuehne.cn/run/m/many_functions_02.d
show the same behaviour?

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFEH90A3w+/yD4P9tIRAh54AJ4gBR3KCaNAXzxbG3ZpvqFe7Ph0tQCfQiBg
thOuEeVNRR09uRqD22qbwhk=
=B+ii
-----END PGP SIGNATURE-----
Mar 21 2006
parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Thomas Kuehne wrote:

 Deewiant schrieb am 2006-03-21:

 Thomas Kuehne wrote:

 debugger schrieb am 2006-03-19:









 [snip]
 

 I can't reproduce this. Are you sure the code above is complete
 (I see no "init4")?



 used code like this:

 void init1(){}
 void init2(){
 // around 16 000 calls to init1()
 }
 void init3(){ printf("hello"); }
 void main() { init3(); }

 And nothing was printed when I ran the program - in fact, -v claimed that even
 main() had no code generated.

 Approximately halving the number of calls to init1() (I wasn't counting how
 many, just going by his approximate 16 and 8 thousand) made it work fine.






 Seems to be a Windows specific bug.
 
 Does
 http://dstress.kuehne.cn/run/m/many_functions_02.d
 show the same behaviour?
 
 Thomas
 
 



Yes, it does.

D:\Main>dmd asdf.d -v
parse     asdf
semantic  many_functions_02
semantic2 many_functions_02
semantic3 many_functions_02
code      many_functions_02
generating code for function 'init1'
generating code for function 'init2'

And no .exe is generated.

In my previous post, I already had an old asdf.exe which is why "nothing was
printed when I ran the program", instead of no program appearing there at all,
like in this case.
Mar 21 2006
prev sibling parent debugger <debugger_member pathlink.com> writes:
In article <avt3f3-ode.ln1 birke.kuehne.cn>, Thomas Kuehne says...

I can't reproduce this. Are you sure the code above is complete
(I see no "init4")?




Seems, that D sources without UI calls, which are runnable under linux, have
already lost there capability to be runnable under windows also.

Have a good day.
Mar 24 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"debugger" <debugger_member pathlink.com> wrote in message 
news:dvj2tg$2i3s$1 digitaldaemon.com...

 dmd 0.149,Win stops compiling without messsage if number of statements is 
 too
 large.

 void init1(){}
 void init2(){
 init1();
 // ... 16,000 times -> stops
 //     only 8,000 times -> compiles
 init1();
 }
 void init3(){}



It's a stack overflow in the compiler. No big deal, it'll be fixed in the 
next update. I kinda wonder, though, what purpose 16,000 statements serves?
Mar 22 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:

 "debugger" <debugger_member pathlink.com> wrote in message 
 news:dvj2tg$2i3s$1 digitaldaemon.com...

 dmd 0.149,Win stops compiling without messsage if number of statements is 
 too
 large.

 void init1(){}
 void init2(){
 init1();
 // ... 16,000 times -> stops
 //     only 8,000 times -> compiles
 init1();
 }
 void init3(){}



 It's a stack overflow in the compiler. No big deal, it'll be fixed in the 
 next update. I kinda wonder, though, what purpose 16,000 statements serves? 
 
 



To try and make a perfect compiler of course! <g> Or did you just increase the
stack size? Could I still smash it with say... a 
million statements?
Mar 22 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Kyle Furlong" <kylefurlong gmail.com> wrote in message 
news:dvsp6s$23r8$10 digitaldaemon.com...

 To try and make a perfect compiler of course! <g> Or did you just increase 
 the stack size? Could I still smash it with say... a million statements?



No, I didn't increase the stack size. I put in an exception handler for the 
stack overflow exception. It still quits, it just gives a message first.
Mar 22 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Brad Roberts wrote:

 On Wed, 22 Mar 2006, Walter Bright wrote:
 

 "Kyle Furlong" <kylefurlong gmail.com> wrote in message 
 news:dvsp6s$23r8$10 digitaldaemon.com...

 To try and make a perfect compiler of course! <g> Or did you just increase 
 the stack size? Could I still smash it with say... a million statements?



 stack overflow exception. It still quits, it just gives a message first. 



 Did you check the results on linux?  That sounds like you're catching a 
 structured exception under windows that doesn't have an analog under any 
 unix system.
 
 Too bad it's not actually making it so it's capable of handling a 
 seriously long function.. in some auto-code generation scenarios this 
 isn't that odd a case.  I see it come up from time to time on the gcc 
 developers list.  Obviously, failing gracefully is better than failing 
 catastrophically, but it's still failing.
 
 - Brad



I agree, what about the future, i.e. metaprogramming? I can also think of some
reasons for having such a long function. Do 
templates also use such a statement stack?
Mar 23 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Brad Roberts" <braddr puremagic.com> wrote in message 
news:Pine.LNX.4.64.0603230012080.5795 bellevue.puremagic.com...

 On Wed, 22 Mar 2006, Walter Bright wrote:

 No, I didn't increase the stack size. I put in an exception handler for 
 the
 stack overflow exception. It still quits, it just gives a message first.



 Did you check the results on linux?  That sounds like you're catching a
 structured exception under windows that doesn't have an analog under any
 unix system.



Yes, that's exactly what's done. I don't know what the linux analog is.


 Too bad it's not actually making it so it's capable of handling a
 seriously long function.. in some auto-code generation scenarios this
 isn't that odd a case.  I see it come up from time to time on the gcc
 developers list.  Obviously, failing gracefully is better than failing
 catastrophically, but it's still failing.



The algorithms used in the compiler are fundamentally recursive, which means 
they use stack. I could bump up the stack, but then it's just a longer 
function that fails. The trouble is, you must decide *in advance* how much 
stack space to allocate (it's not like malloc/realloc). Once you run out, 
there's no recovery.

The only thing to do is pick a reasonable size, that will cover all but 
extreme cases, and error out on the rest.
Mar 23 2006
prev sibling next sibling parent reply debugger <debugger_member pathlink.com> writes:
Walter Bright says...

It's a stack overflow in the compiler. No big deal, it'll be fixed in the 
next update. I kinda wonder, though, what purpose 16,000 statements serves? 



Wow, His Majesty is visiting the populace--and what seems He to be thinking: My
bugs are manna for My choosen people, without Me they would starve in the
desert.

What is the reason to stack a sequence of statements---and what is the reason
for the runtime, that seems to be quadratic in the number of statements within
the analyzed function? No answers please, He is the almighty.

16,00 statemenst are too much? Forgive me Master, that was an inadequate try to
initialize one of the prides of your creation, an associative array, with some
10,000 elements. Do not try to make Your novices convenient with your pride, You
are almighty.
Mar 22 2006
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Mar 2006 05:02:48 +0000 (UTC), debugger  
<debugger_member pathlink.com> wrote:


 Walter Bright says...

 It's a stack overflow in the compiler. No big deal, it'll be fixed in  
 the
 next update. I kinda wonder, though, what purpose 16,000 statements  
 serves?






<snip puerile garbage>

Troll.

Regan
Mar 22 2006
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I'm guessing it has to do with inlining or something similar where it's 
counting functions, but maybe I'm wrong.

Either way, 16,000 statements in the same scope are an obvious example 
of bad coding style ::).

And, my good sir, I strongly suggest you read this page:

http://redwing.hutman.net/~mreed/

Can you figure out which one you are :)?

-[Unknown]



 Walter Bright says...

 It's a stack overflow in the compiler. No big deal, it'll be fixed in the 
 next update. I kinda wonder, though, what purpose 16,000 statements serves? 



 Wow, His Majesty is visiting the populace--and what seems He to be thinking: My
 bugs are manna for My choosen people, without Me they would starve in the
 desert.
 
 What is the reason to stack a sequence of statements---and what is the reason
 for the runtime, that seems to be quadratic in the number of statements within
 the analyzed function? No answers please, He is the almighty.
 
 16,00 statemenst are too much? Forgive me Master, that was an inadequate try to
 initialize one of the prides of your creation, an associative array, with some
 10,000 elements. Do not try to make Your novices convenient with your pride,
You
 are almighty.
Mar 22 2006
parent reply debugger <debugger_member pathlink.com> writes:
In article <dvtehj$1pj$1 digitaldaemon.com>, Unknown W. Brackets says...

Either way, 16,000 statements in the same scope are an obvious example 
of bad coding style ::).



restriction.

You have to code a script used by a generator that offers you three definition
facilities: PRE, POST and ITEM and you must implement a sparsely populated
function f from natural numbers to natural numbers. Where sparsely means at most
10,000,000 elements out of 4,000,000,000 possible elements and the values of the
pairs for the function are given as $(x) and $(y)

My _bad_ style looks like this:

<script>
PRE:
define uint X;
define uint Y;
Y[X] f;
void init( uint x, uint y){
f[cast(X)x]=cast(Y)y;
}
static this(){
POST:
}
ITEM:
init($(x)u,$(y)u); 
</script>

That are nine lines to understand and maintain.

In case you will accept this invitation in addition to your coding solution I
expect a sound argument, why your proposed _better_ coding style will spare a
significant amount of maintenance man time.

Otherwise it should be clear who of us is a warrior.
Mar 24 2006
next sibling parent BCS <BCS_member pathlink.com> writes:
load the data into an array and stream it into the AA at runtime.

uint[2][] foo =
[
[1,2],
[3,4],
[5,6],
...
];

uint[uint] f;
static this()
{
	foreach(uint a; foo)
		f[a[0]]=a[1];
}

pros:
	fewer function calls
	less code
	no scripting needed
	well maybe a bit of formatting, awk, sed or your scripting engine
	...


Before you say it, an array of struct could be used to make this work with any 
set of types.


<script>
PRE:
define uint X;
X[X] f;
static this()
{
	foreach(X a; foo)
		f[a[0]]=a[1];
}
uint[2][] foo = [
POST:
];
ITEM:
[$(x)u,$(y)u],
</script>



debugger wrote:

 In article <dvtehj$1pj$1 digitaldaemon.com>, Unknown W. Brackets says...
 

Either way, 16,000 statements in the same scope are an obvious example 
of bad coding style ::).



 I invite you to describe your _better_ coding style under aproximately
following
 restriction.
 
 You have to code a script used by a generator that offers you three definition
 facilities: PRE, POST and ITEM and you must implement a sparsely populated
 function f from natural numbers to natural numbers. Where sparsely means at
most
 10,000,000 elements out of 4,000,000,000 possible elements and the values of
the
 pairs for the function are given as $(x) and $(y)
 
 My _bad_ style looks like this:
 
 <script>
 PRE:
 define uint X;
 define uint Y;
 Y[X] f;
 void init( uint x, uint y){
 f[cast(X)x]=cast(Y)y;
 }
 static this(){
 POST:
 }
 ITEM:
 init($(x)u,$(y)u); 
 </script>
 
 That are nine lines to understand and maintain.
 
 In case you will accept this invitation in addition to your coding solution I
 expect a sound argument, why your proposed _better_ coding style will spare a
 significant amount of maintenance man time.
 
 Otherwise it should be clear who of us is a warrior.
Mar 24 2006
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
That's just bad design.  I thought they still taught basic looping and 
scripting in schools these days.

But, in the end, you'll have to understand that being "a warrior" on the 
internet is not a good thing.  Instead, I much prefer to have pleasant 
working relationships with people.

I understand if you prefer to fight, and to argue.  But I'm just not 
interested in arguing with people like you.  Especially since you, as 
much posturing as you may go through, don't sound like someone I would 
contract work out to.

But, really, I mean no offense by that comment.  I'm sure you're a 
reasonable guy, and just don't like dealing with us "open source types." 
  And that is, of course, your right.

-[Unknown]



 In article <dvtehj$1pj$1 digitaldaemon.com>, Unknown W. Brackets says...

 Either way, 16,000 statements in the same scope are an obvious example 
 of bad coding style ::).



 restriction.
 
 You have to code a script used by a generator that offers you three definition
 facilities: PRE, POST and ITEM and you must implement a sparsely populated
 function f from natural numbers to natural numbers. Where sparsely means at
most
 10,000,000 elements out of 4,000,000,000 possible elements and the values of
the
 pairs for the function are given as $(x) and $(y)
 
 My _bad_ style looks like this:
 
 <script>
 PRE:
 define uint X;
 define uint Y;
 Y[X] f;
 void init( uint x, uint y){
 f[cast(X)x]=cast(Y)y;
 }
 static this(){
 POST:
 }
 ITEM:
 init($(x)u,$(y)u); 
 </script>
 
 That are nine lines to understand and maintain.
 
 In case you will accept this invitation in addition to your coding solution I
 expect a sound argument, why your proposed _better_ coding style will spare a
 significant amount of maintenance man time.
 
 Otherwise it should be clear who of us is a warrior.
Mar 24 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On Wed, 22 Mar 2006, Walter Bright wrote:


 "Kyle Furlong" <kylefurlong gmail.com> wrote in message 
 news:dvsp6s$23r8$10 digitaldaemon.com...

 To try and make a perfect compiler of course! <g> Or did you just increase 
 the stack size? Could I still smash it with say... a million statements?



 No, I didn't increase the stack size. I put in an exception handler for the 
 stack overflow exception. It still quits, it just gives a message first. 



Did you check the results on linux?  That sounds like you're catching a 
structured exception under windows that doesn't have an analog under any 
unix system.

Too bad it's not actually making it so it's capable of handling a 
seriously long function.. in some auto-code generation scenarios this 
isn't that odd a case.  I see it come up from time to time on the gcc 
developers list.  Obviously, failing gracefully is better than failing 
catastrophically, but it's still failing.

- Brad
Mar 23 2006