1. VERY strange problem? HELP!
- Posted by CoJaBo <cojabo at suscom.net> Jun 26, 2004
- 450 views
I have been working on a program when somthing very strange happened. The server generates a number using "n=time()*100+rand(99)", then starting a client program using 'n' as a parameter. After getting strange results, I modified both to display n. I ran it a few times and got: # from server 488 567 (501) 467 # from client 488 567 (500) 467 As you can see, at on point the server displayed '501' and the client displayed '500'. I tried to create the problem in another program, but got another strange error: [ex.err] ...\New Windows App.exw:11 in procedure w_onOpen() type_check failure, n is 486 self = 3 event = 4 params = {} o = 6 ... ...\New Windows App.exw: f = 42'*' n = 486 [end] In types.e: constant True = (1=1) global type int( integer i ) return True end type so 'n' is an integer, and 486 is a perfectly leagal value for an integer. Also, int() always returns True, so an invalid value woulgd cause an error on 'i'. And the program also displayed a few other numbers just fine. The example programs are below, put them in thsame place and run New Windows App.exw Can somine explain what is happenning here?!?!?!?! [New Windows App.exw] include win32lib.ew without warning int f,n constant w=createEx( Window, "", 0, Default, Default, 600, 400, 0, 0 ) procedure w_onOpen (integer self, integer event, sequence params)--params is () for o=1 to 10 do n=time()*100+rand(99) ?n f=shellExecuteEx(0, "exw.exe", sprintf("%s %d",{"p2",n}), "",--reverse(ms1), SW_SHOWNORMAL, 0) end for end procedure setHandler( w, w32HClick, routine_id("w_onOpen")) WinMain(w,Normal) [end] [p2.exw] include win32lib.ew seq a a=command_line() puts(1,a[3]) a[1]=wait_key() [end]
2. Re: VERY strange problem? HELP!
- Posted by CoJaBo <cojabo at suscom.net> Jun 26, 2004
- 437 views
I think a hacker is messing up my computer; it is possible that is what is causing this, but is that even possible? CoJaBo wrote: > > I have been working on a program when somthing very strange happened. > The server generates a number using "n=time()*100+rand(99)", > then starting a client program using 'n' as a parameter. > After getting strange results, I modified both to display n. > I ran it a few times and got: > > # from server 488 567 (501) 467 > # from client 488 567 (500) 467 > > As you can see, at on point the server displayed '501' > and the client displayed '500'. > I tried to create the problem in another program, but got another > strange error: > > [ex.err] > ...\New Windows App.exw:11 in procedure w_onOpen() > type_check failure, n is 486 > self = 3 > event = 4 > params = {} > o = 6 > > ... > > ...\New Windows App.exw: > f = 42'*' > n = 486 > [end] > > In types.e: > constant True = (1=1) > > global type int( integer i ) > return True > end type > so 'n' is an integer, and 486 is a perfectly leagal value for an integer. > Also, int() always returns True, so an invalid value woulgd cause > an error on 'i'. And the program also displayed a few other numbers just fine. > > The example programs are below, put them in thsame place and > run New Windows App.exw > Can somine explain what is happenning here?!?!?!?! > > [New Windows App.exw] > include win32lib.ew > without warning > > > int f,n > constant w=createEx( Window, "", 0, Default, Default, 600, 400, 0, 0 ) > > > procedure w_onOpen (integer self, integer event, sequence params)--params is > () > for o=1 to 10 do > n=time()*100+rand(99) > ?n > f=shellExecuteEx(0, > "exw.exe", > sprintf("%s %d",{"p2",n}), > "",--reverse(ms1), > SW_SHOWNORMAL, > 0) > end for > end procedure > setHandler( w, w32HClick, routine_id("w_onOpen")) > WinMain(w,Normal) > [end] > > [p2.exw] > include win32lib.ew > > seq a > a=command_line() > puts(1,a[3]) > a[1]=wait_key() > [end] >
3. Re: VERY strange problem? HELP!
- Posted by Robert Craig <rds at RapidEuphoria.com> Jun 26, 2004
- 446 views
If n displays as 486, it does not mean that n is precisely the integer: 486.00000000000000... n might well be: 485.99999999999999 which will fail the integer() test. By default, Euphoria displays numbers to about 10 significant digits. Try: ? n - 486 Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
4. Re: VERY strange problem? HELP!
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jun 26, 2004
- 446 views
On Fri, 25 Jun 2004 18:44:00 -0700, CoJaBo <guest at RapidEuphoria.com> wrote: >The server generates a number using "n=time()*100+rand(99)", Try n=floor(time()*100)+rand(99) Regards, Pete
5. Re: VERY strange problem? HELP!
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jun 26, 2004
- 448 views
On Sat, 26 Jun 2004 14:41:25 -0700, CoJaBo <guest at RapidEuphoria.com> wrote: >On Win32, time()*100+rand(99) can only be an integer. FALSE. Try: ?integer(1.1*100) IEEE 754 floats are not designed for this handling. This is a hardware feature, nothing to do with RDS Euphoria, or any other software. As you have found, if you had defined n as an integer in the first place, rather than an atom or object, the error would have occurred immediately, and I think you would have figured it out much quicker. Regards, Pete
6. Re: VERY strange problem? HELP!
- Posted by CoJaBo <cojabo at suscom.net> Jun 27, 2004
- 465 views
Thanks! The problem was that it was defined as an ATOM. I thought it was an INT, but I had been looking at another similirely named integer (which explains why time()*100+rand(99) seemed to have been returning an integer). But that still doesn't explain why it ?time() once displayed -3812688, or why the problem only exists around this time (it worked fine this morning!). You will be added to the credits screen for the program (for if I ever release it). Pete Lomax wrote: > > On Sat, 26 Jun 2004 14:41:25 -0700, CoJaBo <guest at RapidEuphoria.com> > wrote: > > >On Win32, time()*100+rand(99) can only be an integer. > FALSE. Try: > > ?integer(1.1*100) > > IEEE 754 floats are not designed for this handling. This is a hardware > feature, nothing to do with RDS Euphoria, or any other software. > > As you have found, if you had defined n as an integer in the first > place, rather than an atom or object, the error would have occurred > immediately, and I think you would have figured it out much quicker. > > Regards, > Pete > >