OpenEuphoria

2. Re: [EuForum] Definition of insanity...

• Posted by Tone Škoda <tskoda at email.si> Nov 23, 2004
• 586 views

Patrick Barnes wrote:
> 
> Doing the same thing twice and getting different results...

For this kind of bugs a "history debugger" would be nice: a debugger which
records all statements executed and info what values variables had. Then when
program crashes or something works wrong you can stop program execution and debug
for back, ie when debugging you can jump back to any statement in code which was
executed, not only (one statement) forward, like in normal debuggers. You could
also search for a condition, ie var=val.

The problem with such debugger would be that it program execution work quite
slow, both because it would use execute.e and would have to record all that info
to hard drive, and it would produce gigabytes large debug files.

I'm not sure if it would be really that useful, considering it is needed quite a
lot of work to create such debugger. But it could be it would be VERY useful.

4. Re: [EuForum] Definition of insanity...

• Posted by CoJaBo <CoJaBo_EUforum_Address at CJBN.net> Nov 23, 2004
• 581 views
• Last edited Nov 24, 2004

Patrick Barnes wrote:
> 
> Doing the same thing twice and getting different results...
> 
> Working on the contest engine... 
> 
> I have 3 bots set up to run a game. Each is given its own identity at
> startup. (12 letter random string, and an incremental number)
> 
> When the engine calls a procedure in one of the bots, it does its
> business, then calls a notify procedure in the engine to signify that
> it's done.
> 
> The notify procedure receives the number from the bot, and increments
> an appropriate flag element (there's 1 for each bot)
> 
> After a certain amount of time, the engine breaks out of the loop,
> checks the notification flags, and aborts if one of the bots didn't
> respond.
> 
> Got that?
> 
> Somehow, the data is getting mixed up in the IPC library. The correct
> identities are being sent to the correct bots, each bot is sending
> their own identity, but at the engine end:
> (Say with three bots)
> The engine is receiving the first two messages correctly.
> The third message is a duplicate of the second. And I mean, *exact*
> duplicate. So, rather than flagging 1,3,2 (which is success), it might
> flag 1, 3, 3!
> This is not a bot problem, I've checked that they're each sending
> different data...
> By the time it gets to the notify function, the 3rd piece of data has
> been messed up already, it seems to be a problem with the ipc.ew
> library.
> 
> 
> So why the subject line? Well, sometimes it works fine, sometimes it
> does this!! I can't figure out the common factors, let alone the
> problem...
You must never have done this:

for o=1 to rand(1000000)*100 do
	--It doesnt seem to happen
	--unless the program runs for a while
end for
integer g
g=time()*100
?g
include get.e
?wait_key()

Run it a few times, you'll eventually get a fairly unexpected error!
This was the cause of headaches for many weeks before I figured it out...

> 
> If anyone would like to have a crack at solving this, I can email your
> the source code...
> If it can't be fixed, no contest!
> -- 
> MrTrick
> 
>

6. Re: [EuForum] Definition of insanity...

• Posted by CoJaBo <CoJaBo_EUforum_Address at CJBN.net> Nov 24, 2004
• 581 views

Pete Lomax wrote:
> 
> On Tue, 23 Nov 2004 14:14:41 -0800, CoJaBo <guest at RapidEuphoria.com>
> wrote:
> 
> >You must never have done this:
> >}}}
<eucode>
> >for o=1 to rand(1000000)*100 do
> >	--It doesnt seem to happen
> >	--unless the program runs for a while
> >end for
> >integer g
> >g=time()*100
> >?g
> >include get.e
> >?wait_key()
> ></eucode>
{{{

> >Run it a few times, you'll eventually get a fairly unexpected error!
> >This was the cause of headaches for many weeks before I figured it out...
> 
> I assume you mean that:
> 	g=floor(time()*100)
> 
> is occasionally (and seemingly against the docs) required?
> 
> If so, and having run the above several times, I'm slightly confused.
> Compare this to:
> 
> }}}
<eucode>
> if 0.1+0.2!=0.3 then
> 	puts(1,"not equal!\n")
> end if
> </eucode>
{{{

> 
> Which fails (100%) because (eg) 0.1 cannot be *exactly* represented in
> binary floating point (a hardware thing, not a dig at RDS). What
> confuses me is your code does not fail very often...
The origanal program went unchanged for months
before the problem appeared. At first it happened only
about 1% of the time, but eventually increased to 95%!
This change was what really confused me. Eu also kept
writing garbage to ex.err, making it even more confusing!

After it was finally fixed, I wanted to tar-and-feather
the creater of floating point!

> 
> Try this (failed 2dp atoms shown on the right, apologies for the line
> wrap):
> }}}
<eucode>
> procedure t100(sequence a)
> integer i
> 	for j=1 to length(a) do
> 		i=a[j]*100
> 		?i
> 	end for
> end procedure
> t100({1.90,1.91,1.92,1.93,1.94,1.95,1.96,1.97,1.98,1.99,	-- <none>
> 	  2.00,2.00,2.02,2.02,2.04,2.04,2.06,2.06,2.08,2.09,	--2.01,
> 2.03, 2.05, 2.07
> 	  2.10,2.11,2.12,2.13,2.14,2.15,2.16,2.17,2.17,2.19,	--2.18,
> 	  2.21,2.21,2.21,2.23,2.23,2.25,2.25,2.27,2.27,2.29,	--2.20,
> 2.21, 2.24, 2.25, 2.28
> 	  2.29,2.29,2.29,2.29,2.34,2.34,2.36,2.36,2.38,2.38,	--2.30,
> 2.31, 2.32, 2.33, 2.35, 2.37, 2.39
> 	  2.40,2.40,2.42,2.42,2.44,2.44,2.46,2.46,2.48,2.48,	--2.41,
> 2.42, 2.45, 2.47, 2.48
> 	  2.50,2.50,2.52,2.52,2.54,2.54,2.56,2.57,2.58,2.59,	--2.51,
> 2.53, 2.55
> 	  2.60,2.61,2.62,2.63,2.64,2.65,2.66,2.67,2.68,2.69,	-- <none>
> 	  2.70,2.71,2.72,2.73,2.74,2.75,2.76,2.77,2.78,2.79})	-- <none>
> </eucode>
{{{

> 
> I am *NOT* saying this can be fixed (apart from use of floor()),
> I am just exploring this in detail.
> It's a fairly strange spread, if anything can be read into that...
> Does anyone regularly using another language get the same results?
> 
> Yours curiously,
> Pete
> 
>