[armedbear-devel] Fixing PRINT.RANDOM-STATE.1

Mark Evenson evenson at panix.com
Sat Jul 16 05:00:05 UTC 2011


Doh! Yes, Java is missing a getSeed() here. Then I would verify that the java.ip.Serialazable contract does what one would expect, and use that. For a possible optimization, one might use some variant of SecureRandom here, which presumably has greater entropy.

Tersely written from my iPhone

On 15.07.2011, at 21:45, Erik Huelsmann <ehuels at gmail.com> wrote:

> Hi Mark,
> 
> On Fri, Jul 15, 2011 at 9:41 PM, Mark Evenson <evenson at panix.com> wrote:
> I think all you need to serialize is a structure that contains the long seed for java.until.Random.  Or am I missing something?
> 
> 
> Well, the problem I'm having with that approach is that I don't seem to have any means to extract the seed from the Random object: it has a method setSeed(), but not a getSeed(). Do you have any idea how?
> 
> 
> Bye,
> 
> 
> Erik.
>  
> Sent from my iPad
> 
> On Jul 15, 2011, at 6:59 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
> 
> >
> > Today I was looking at fixing some of our PRINT.* failures in the ansi test suite.
> >
> > Hoping to get an easy start, I started looking PRINT.RANDOM-STATE.1 The problem shown by the test is that our RANDOM-STATEs are not printable. From the perspective of ABCL, that's logical: Java's Random objects are serializable, but as everywhere in Java, it's serialization is internal to the implementation. The Random object is initialized using a 'seed' long value, but there's no way to extract a 'seed' value from the object to be used to initialize an object into the same state.
> >
> > So, I'm now pondering what action to take. I'm seeing several options:
> >
> > 1. build our own pseudo random number generator with its own random state
> > 2. serialize the Random object to a byte array and use that array as some sort of printed representation (sure, we'll definitely need to look into ways to load)
> >
> > The advantage of (1) is that we can create it all in Lisp, however, it's  pure additional code, since we won't be leveraging what's already there.
> >
> > The advantage of (2) is that we can use what Java maintains for us and even better: we can use the random number generator shared between Lisp and Java code. I imagine the disadvantage of this solution is that the serialization of the random state can differ between Java versions and implementations.
> >
> > Any ideas??
> >
> >
> > Bye,
> >
> >
> > Erik.
> > _______________________________________________
> > armedbear-devel mailing list
> > armedbear-devel at common-lisp.net
> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20110716/fd4bafc1/attachment.html>


More information about the armedbear-devel mailing list