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

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

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

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?

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

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.

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")?
Its a typo. I meant "init3".

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.

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

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