Jerome Quelin wrote: > --snip-- > But, there is a tiny, little problem: I don't call srand(), and thus get > always the same value. I don't know *where* to call srand(). I don't even > know *if* I should call srand(). > Anyway, here's the patch and be kind since this is my first patch ;) (pod > cleaning doesn't count).
My local manpage claims that srand() is BSD, and perldoc POSIX claims that we should use internal rand()... So we probably need to come up with our own portable implementation. One idea I had while thinking about this was the Mersenne Twister, http://www-personal.engin.umich.edu/~wagnerr/MersenneTwister.html but I'm sure there are better solutions. One interesting (if slightly dangerous) area might be the bit-shifting registers used to generate cryptographically-secure pseudorandom keys. > Please, could you tell me if the parrot team (that is, all of you guys) wants > to add new ops, or if we should wait for a new source organization / > extension API / etc. srand() would probably cover our needs for the time being, but since that won't always be available, a fallback algorithm might be nice. The above contains at least two ideas, and I'm certainly more than open to more. > This makes me think: I looked for the ord() and chr() functions, and found > just the ord() in core.ops, that calls string_ord() in string.c. I wanted to > code the chr() function, but I realized that it depends in fact from the > encoding? How one should treat this? It would probably be derived from the encoding used by the string the character derives from. Look at the encoding table in the string's data structure. -- Jeff <[EMAIL PROTECTED]>
