[Openmcl-devel] weird random problem

[Gary Byers]

On Mon, 19 May 2008, Todd Ingalls wrote:

> Not that the problem happens at random but rather with the function
> random.
>
> I am using Carbon emacs 22.1.1 and have tried the following with both
> the last stable release of slime from April 20 2006 and the newest
> version from CVS.
>
> In a lisp buffer
>
> (random 100)
>
> will continuously return 91
>
> or (random 10) will continuously return 1 etc.
>
> However in the *slime-repl openmcl* buffer doing the above results in
> actual random numbers
>
> BTW, this works fine in the cocoa-ide .
>
>
> Any ideas? I am using 1.2-r9226-RC1 but i am seeing the same behavior
> in 1.1 version.

This isn't too much of an idea, but (on x86-64):

? (process-run-function "randomly" (lambda () (dotimes (i 10) (print (random 100)))))
#<PROCESS randomly(2) [Active] #x3000411EAB2D>
? 
91 
6 
55 
20 
45 
62 
19 
80 
50 
86 
()
NIL
? (process-run-function "randomly" (lambda () (dotimes (i 10) (print (random 100)))))
#<PROCESS randomly(3) [Active] #x3000411E419D
>
? 91 
6 
55 
20 
45 
62 
19 
80 
50 
86 
()
NIL
?

So, when a thread starts up, its binding of *RANDOM-STATE* is set to some
value which returns 91 on the first call to (RANDOM 100).  The fact that
91 is the value that you get repeatedly when you do something similar
under SLIME is likely significant, but it's not clear how.  I don't
usually use SLIME, but didn't see this behavior with 1.2 on x86-64 Linux
using something called "SLIME 2008-01-27".

I'd be a little surprised if any version of SLIME is resetting
*RANDOM-STATE* at ... random .. intervals, but I don't have a good
explanation beyond noting that repeatedly getting the first element
of the sequence is what whould happen if something, somewhere was
doing that.