Le��lun. 11 f��vr. 2019 ����15:58, David Richards <david.i.richards.iii@gmail.com> a ��crit��:
Thanks Nicolas and Henry,For now, simple alternative expressions can easily generate the values I need for my project, such as:(String new: 32) collect: [ :each | '0123456789abcdef' atRandom ]Maybe in a few months (or years!) from now I will have acquired enough ambient familiarity with Pharo to attempt a fix. But, for the time being, I'll just avoid stepping on the landmine.In doing some research on this problem I spotted this, which seemed to possibly point a way toward a cutting edge RNG implementation for Pharo:DavidOn Sun, 10 Feb 2019 at 23:21, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:Try it in Squeak and pick the relevant methods. Open a bug report and commit the fix. Of course, original authorship will somehow be spoiled, so be kind and cite them in commit message.Le lun. 11 f��vr. 2019 �� 07:59, David Richards <david.i.richards.iii@gmail.com> a ��crit��:Hello community.Kindly consider:| n i r |n := ( 2 ** 256 ) - 1 .�� "the largest 256-bit value"i := ( 0 to: n ) .�� "the interval 0 to 2**256-1""Produce three sets of computed test results."3 timesRepeat: [�� ��Transcript show: ( r := i atRandom ) ; cr .�� ��Transcript show: ( r asByteArray hex ) ; cr . ]According to comments in Pharo library code, atRandom fails for integer magnitudes greater than 2**30 .�� A reason for this limitation is not given, and it's not clear to a novice such as myself why the computed result of atRandom is permitted to sometimes be in conflict with the semantics of atRandom .Can anyone provide a basic explanation of the rationale for a 'broken' atRandom ?Alternatively, is this a known bug?Thanks.dr