May 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Cryptography Team] Re: Random is not random at startup

by Bob Clark

[1] http://pharo.org/success On 05/22/2016 09:46 AM, Robert Withers wrote: > > > On 05/21/2016 06:44 PM, Luciano Notarfrancesco wrote: >> (Hey Rob, long time no Smalltalk!) > > Hi Luciano, I'm grateful to hear you. I've got a feeling, you know. I > got a feeling down deep there deep inside. and a got a feeling you got > this feeling too! Do you know this feeling? do you know the > resurrection mythtales of Icarus? The Phoenix? Lilith the Vampire? > OpenSmalltalk is getting ready to rise up: all domains. Hang on. > 'cause I got thisfeeling, you know. ;) >

May 22, 2016

Re: [Pharo-dev] [Cryptography Team] Re: Random is not random at startup

by Robert Withers

On 05/21/2016 06:44 PM, Luciano Notarfrancesco wrote: > (Hey Rob, long time no Smalltalk!) Hi Luciano, I'm grateful to hear you. I've got a feeling, you know. I got a feeling down deep there deep inside. and a got a feeling you got this feeling too! Do you know this feeling? do you know the resurrection mythtales of Icarus? The Phoenix? Lilith the Vampire? OpenSmalltalk is getting ready to rise up: all domains. Hang on. 'cause I got thisfeeling, you know. ;)

May 22, 2016

Re: [Pharo-dev] [Cryptography Team] Re: Random is not random at startup

by Nicolas Cellier

2016-05-22 0:44 GMT+02:00 Luciano Notarfrancesco <luchiano(a)gmail.com>: > (Hey Rob, long time no Smalltalk!) > > I suggest some changes we did in Cuis. First, for Park-Miller you can do a > small change to #initialize, insert a hashMultiply somewhere when > initializing the seed. I did experiments in Cuis, drawing histograms to see > if it looks like a uniform distribution, and ended up doing something like > seed _ (Time millisecondClockValue + self identityHash) hashMultiply \\ m > > Another issue with Random that we addressed in Cuis is related to the bit > size of each output. Random>>nextValue returns Floats with 31 random bits > (or 30). It doesn't return a uniformly distributed Float between 0 and 1 > (some Float values don't have a chance to be output). Similarly, > Random>>nextInt: n will not really return an integer between 1 and n if n > is large enough, for example (1 << 64) atRandom returns always odd integers > (not very random uh). > > So I suggest to think of Random as a generator of random "bits" or "blocks > of bits", and to generate a Float it should actually build it from 52 > randomly generated bits (to fill out the mantissa), and nextInt: n should > also be implemented from random bits (or chunks of bits). > > > Yes, that's in Squeak for more than a year now. Still, a 30bits Park Miller does not have enough different states, and one should not be amazed that among the 2^53 possible Float values, most have a probability of exactly 0. Worse for LargeIntegers... > On Wed, May 18, 2016 at 11:25 PM, Robert Withers < > robert.w.withers(a)gmail.com> wrote: > >> Thanks for cc-ing me. I don't have much exposure to random, so I am >> cc-ing the Cryptography list, in hopes they might help. This doesn't very >> random, you're right. Here were Peter's questions: >> >> My questions: >> 1) do we really want to have global fixed seed? >> 2) Random new should actually setup a usable seed so I don't need to >> first run it N times before I can use the value >> 3) Should we switch to what UUIDGenerator is usingâ¦ reading /dev/urandom >> for the initial seed setup? >> >> Rob >> >> >> On 05/18/2016 07:05 PM, Peter UhnÃ¡k wrote: >> >> Hi, >> >> (cc-ing Robert Withers as he seems to be working with cryptography and >> security... as this seems related and may have some implications, but I am >> likely wrong about the implications) >> >> yesterday I've encountered a very surprising behavior >> >> I executed the same script `10 atRandom` on the same image without saving >> it and got the same output: >> >> while true; do >> pharo-vm --nodisplay latest.image --no-default-preferences eval >> '10 atRandom' >> done >> 10 >> 10 >> 10 >> 10 >> 10 >> 10 >> >> Not so randomâ¦ not random at all. >> >> Apparently the default random generator uses SharedRandom pool, that is >> initialized only onceâ¦ so every time you start an image you get the EXACT >> same random seed... I think this is stupid, and I am not sure what are the >> security implications of this (e.g. when opening an SSL connectionâ¦ having >> fixed world-wide initial seed seems like an awful, awful idea), but >> whateverâ¦ >> >> So instead I tried to explicitly specify the Random generatorâ¦ which I >> can do >> >> while true; do >> pharo-vm --nodisplay latest.image --no-default-preferences eval >> '10 atRandom: Random new' >> done >> 5 >> 5 >> 5 >> 5 >> 5 >> >> Still not randomâ¦ what? >> >> while true; do >> pharo-vm --nodisplay latest.image --no-default-preferences eval >> 'Random new instVarNamed: #seed' >> done >> 426306047 >> 426305545 >> 426305546 >> 426306010 >> >> So the seed is different but thanks to the magic of masking the seed, I >> always get the same first several bitsâ¦ thus the same result for small >> numbers. >> >> So if I actually want what seems like a random valueâ¦ I have to at least >> once run the generatorâ¦ >> >> while true; do >> pharo-vm --nodisplay latest.image --no-default-preferences eval >> '10 atRandom: (Random new next; yourself)' >> done >> 7 >> 3 >> 4 >> 9 >> 6 >> 7 >> >> Once I start to use it the properties of the algo kick in so it's >> pseudo-randomâ¦ but I need to run it once to initialize it, which is wtf. >> >> My questions: >> 1) do we really want to have global fixed seed? >> 2) Random new should actually setup a usable seed so I don't need to >> first run it N times before I can use the value >> 3) Should we switch to what UUIDGenerator is usingâ¦ reading /dev/urandom >> for the initial seed setup? >> >> Peter >> >> >> >> _______________________________________________ >> Cryptography mailing list >> Cryptography(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography >> >> >

May 22, 2016

Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5

by Henrik Nergaard

There is a method in SourceFileArray #localProcessReadStreamAtFileIndex:atPosition:ifPresent:ifAbsent: which uses a ProccessLocalVariable called ProccessAndSessionLocalSourcesFileArray (see #localProcessReadOnlyCopy). Changing the last line in #readStreamAt:ifPresent:ifAbsent: to use this local process one makes the time to run this snippet: [ 1 systemNavigation browseMethodsWithSourceString: 'Morph' matchCase: false ] timeProfile >From ~ 10 seconds to ~ 3 seconds (Windows). However I cannot see that the file handles created by this processLocalVariable to ever be closed, so I suspect those are leaked? In that case there might be the need to implement some âclean upâ mechanism for ProccessLocalVariables before they are changed/nilled when a process changes. Another approach could be to not use a ProccessLocalVariabe at all, but extend the SourceFilesArray class to also hold one read only handle for each of its files, and use these in readStreamAtFileIndex:::â¦ . I guess that it is also necessary then to have semaphore protecting the two last lines such that setting the position in the stream and reading from it cannot be changed by other threads. readStreamAtFileIndex: index atPosition: position ifPresent: presentBlock ifAbsent: absentBlock | stream result| stream := self readOnlyFileAt: index. stream ifNil: [ ^ absentBlock value ]. "sources file not available" position > stream size ifTrue: [ ^ absentBlock value ]. readSema critical: [ stream position: position. result := presentBlock value: stream ]. ^ result Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess Sent: Thursday, May 19, 2016 9:31 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5 Squeak caches the opened readonly file(handle). It does not have to reopen the file on every call for reading (readonly). 2016-05-18 19:12 GMT+02:00 stepharo <stepharo(a)free.fr<mailto:stepharo@free.fr>>: I am wondering why does the search 'method source with it' take so long in Pharo 5? On my PC, When I select the text 'menu' and search for all 'method source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it takes 21 seconds.

May 22, 2016

Re: [Pharo-dev] the fastest way to load external code

by Max Leske

> On 22 May 2016, at 10:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Interesting. How do I do that? [ Smalltalk closeSourceFiles. "do your thing" ] ensure: [ Smalltalk openSourceFiles ] Seems to work in Pharo 5 too, as far as I can tell. > > Doru > >> On May 22, 2016, at 9:49 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> Another thing you can do (but be careful) is to close the changes file. Sources (and change operations) will then not be written to disk which saves a lot of I/O operations. I use this for some special imports. Iâm not sure however, how well that will work in Pharo 5 (Iâve been doing this in Pharo 1.3). >> >> Cheers, >> Max >> >>> On 21 May 2016, at 23:51, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi Doru, >>> >>>> On May 21, 2016, at 12:50 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hi, >>>> >>>> I am looking for ways to make loading of code from an st file faster. To this end, I would like to find in-image mechanisms that are not mandatory for obtaining a functional image. >>>> >>>> For example, one place I look at is SystemAnnouncer uniqueInstance, and I know that I should have no Nautilus open and that I can disable Renraku and GTExample: >>>> >>>> ReRuleManager uniqueInstance unsubscribe. >>>> GTExampleOrganizer instance stopSystemAnnouncements. >>>> >>>> What else do you see around? >>> >>> Strikes me that parsing, not compiling and either holding onto the source String or simply keeping a pointer into the source file makes sense. Compilation to methods can wait until installation. With that approach you need no notifications at all. HTH >>> >>> >>> _,,,^..^,,,_ (phone) >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Don't give to get. Just give." >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Speaking louder won't make the point worthier." > >

May 22, 2016

New Success Story: Sysmocom: Free Software for Mobile Communication

by Marcus Denker

Sysmocom: Free Software for Mobile Communication http://pharo.org/success/Sysmocom "Sysmocom is a leading provider of Free Software Mobile Communication solutions. In 2012 we have started a long term project to develop a complete ASN1, TCAP, MAP, CAP, GSN stack using the Pharo Object Environment. We have decided to use Pharo because of the increased productivity, the great tooling, the live inspection and if necessary modification of a running system to deploy a critical bugfix. Pharo has allowed us to focus on what is important. The stack was used to uncover security and privacy issues inherent to the MAP protocol design in 2014/2015. We have used the stack to build a carrier-grade AuthenticationCenter (AuC) and helped a customer to move their production traffic off a proprietary system to ours. We look forward to move a HomeLocationRegister (HLR) into production this year. said Holger Freyther CEO."

May 22, 2016

Re: [Pharo-dev] the fastest way to load external code

by Tudor Girba

Hi, Interesting. How do I do that? Doru > On May 22, 2016, at 9:49 AM, Max Leske <maxleske(a)gmail.com> wrote: > > Another thing you can do (but be careful) is to close the changes file. Sources (and change operations) will then not be written to disk which saves a lot of I/O operations. I use this for some special imports. Iâm not sure however, how well that will work in Pharo 5 (Iâve been doing this in Pharo 1.3). > > Cheers, > Max > >> On 21 May 2016, at 23:51, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Doru, >> >>> On May 21, 2016, at 12:50 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> I am looking for ways to make loading of code from an st file faster. To this end, I would like to find in-image mechanisms that are not mandatory for obtaining a functional image. >>> >>> For example, one place I look at is SystemAnnouncer uniqueInstance, and I know that I should have no Nautilus open and that I can disable Renraku and GTExample: >>> >>> ReRuleManager uniqueInstance unsubscribe. >>> GTExampleOrganizer instance stopSystemAnnouncements. >>> >>> What else do you see around? >> >> Strikes me that parsing, not compiling and either holding onto the source String or simply keeping a pointer into the source file makes sense. Compilation to methods can wait until installation. With that approach you need no notifications at all. HTH >> >> >> _,,,^..^,,,_ (phone) >> >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Don't give to get. Just give." >>> >>> >>> >>> >>> >>> >>> >> > > -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

May 22, 2016

Re: [Pharo-dev] the fastest way to load external code

by Max Leske

Another thing you can do (but be careful) is to close the changes file. Sources (and change operations) will then not be written to disk which saves a lot of I/O operations. I use this for some special imports. Iâm not sure however, how well that will work in Pharo 5 (Iâve been doing this in Pharo 1.3). Cheers, Max > On 21 May 2016, at 23:51, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Doru, > >> On May 21, 2016, at 12:50 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> I am looking for ways to make loading of code from an st file faster. To this end, I would like to find in-image mechanisms that are not mandatory for obtaining a functional image. >> >> For example, one place I look at is SystemAnnouncer uniqueInstance, and I know that I should have no Nautilus open and that I can disable Renraku and GTExample: >> >> ReRuleManager uniqueInstance unsubscribe. >> GTExampleOrganizer instance stopSystemAnnouncements. >> >> What else do you see around? > > Strikes me that parsing, not compiling and either holding onto the source String or simply keeping a pointer into the source file makes sense. Compilation to methods can wait until installation. With that approach you need no notifications at all. HTH > > > _,,,^..^,,,_ (phone) > >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Don't give to get. Just give." >> >> >> >> >> >> >> >

May 22, 2016

Re: [Pharo-dev] [Cryptography Team] Re: Random is not random at startup

by Luciano Notarfrancesco

(Hey Rob, long time no Smalltalk!) I suggest some changes we did in Cuis. First, for Park-Miller you can do a small change to #initialize, insert a hashMultiply somewhere when initializing the seed. I did experiments in Cuis, drawing histograms to see if it looks like a uniform distribution, and ended up doing something like seed _ (Time millisecondClockValue + self identityHash) hashMultiply \\ m Another issue with Random that we addressed in Cuis is related to the bit size of each output. Random>>nextValue returns Floats with 31 random bits (or 30). It doesn't return a uniformly distributed Float between 0 and 1 (some Float values don't have a chance to be output). Similarly, Random>>nextInt: n will not really return an integer between 1 and n if n is large enough, for example (1 << 64) atRandom returns always odd integers (not very random uh). So I suggest to think of Random as a generator of random "bits" or "blocks of bits", and to generate a Float it should actually build it from 52 randomly generated bits (to fill out the mantissa), and nextInt: n should also be implemented from random bits (or chunks of bits). On Wed, May 18, 2016 at 11:25 PM, Robert Withers <robert.w.withers(a)gmail.com > wrote: > Thanks for cc-ing me. I don't have much exposure to random, so I am cc-ing > the Cryptography list, in hopes they might help. This doesn't very random, > you're right. Here were Peter's questions: > > My questions: > 1) do we really want to have global fixed seed? > 2) Random new should actually setup a usable seed so I don't need to first > run it N times before I can use the value > 3) Should we switch to what UUIDGenerator is usingâ¦ reading /dev/urandom > for the initial seed setup? > > Rob > > > On 05/18/2016 07:05 PM, Peter UhnÃ¡k wrote: > > Hi, > > (cc-ing Robert Withers as he seems to be working with cryptography and > security... as this seems related and may have some implications, but I am > likely wrong about the implications) > > yesterday I've encountered a very surprising behavior > > I executed the same script `10 atRandom` on the same image without saving > it and got the same output: > > while true; do > pharo-vm --nodisplay latest.image --no-default-preferences eval > '10 atRandom' > done > 10 > 10 > 10 > 10 > 10 > 10 > > Not so randomâ¦ not random at all. > > Apparently the default random generator uses SharedRandom pool, that is > initialized only onceâ¦ so every time you start an image you get the EXACT > same random seed... I think this is stupid, and I am not sure what are the > security implications of this (e.g. when opening an SSL connectionâ¦ having > fixed world-wide initial seed seems like an awful, awful idea), but > whateverâ¦ > > So instead I tried to explicitly specify the Random generatorâ¦ which I can > do > > while true; do > pharo-vm --nodisplay latest.image --no-default-preferences eval > '10 atRandom: Random new' > done > 5 > 5 > 5 > 5 > 5 > > Still not randomâ¦ what? > > while true; do > pharo-vm --nodisplay latest.image --no-default-preferences eval > 'Random new instVarNamed: #seed' > done > 426306047 > 426305545 > 426305546 > 426306010 > > So the seed is different but thanks to the magic of masking the seed, I > always get the same first several bitsâ¦ thus the same result for small > numbers. > > So if I actually want what seems like a random valueâ¦ I have to at least > once run the generatorâ¦ > > while true; do > pharo-vm --nodisplay latest.image --no-default-preferences eval > '10 atRandom: (Random new next; yourself)' > done > 7 > 3 > 4 > 9 > 6 > 7 > > Once I start to use it the properties of the algo kick in so it's > pseudo-randomâ¦ but I need to run it once to initialize it, which is wtf. > > My questions: > 1) do we really want to have global fixed seed? > 2) Random new should actually setup a usable seed so I don't need to first > run it N times before I can use the value > 3) Should we switch to what UUIDGenerator is usingâ¦ reading /dev/urandom > for the initial seed setup? > > Peter > > > > _______________________________________________ > Cryptography mailing list > Cryptography(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography > >

May 21, 2016

Re: [Pharo-dev] TEXT drag and drop

by Thierry Goubier

Le 21/05/2016 22:47, stepharo a Ã©crit : > > > Le 21/5/16 Ã 16:02, Thierry Goubier a Ã©crit : >> Le 21/05/2016 15:58, stepharo a Ã©crit : >>> How can I see the effects of your changes? >> >> Install both packages that are in that smalltalkhub archive, > > I did that even before asking. > >> and try dragging a text selection. > > I have no idea how to do this. Select some text, click and hold on it and then move. Unless you tried that already, then it becomes strange because it works when I do that :) Thierry >> At least, that process works for PluggableTextMorph. >> >> Nice demonstration of both the drag and drop api and the text api, >> because it's even nicely undoable in the editor :) >> >> Thierry >> >>> >>> Stef >>> >>> >>> Le 18/5/16 Ã 19:09, lb a Ã©crit : >>>> Hi, >>>> I have made a little tool for draging and dropping text selection. >>>> like windows Word. >>>> It can work in Pharo 40 50 and 60. >>>> >>>> Have a fun! >>>> >>>> LiangBing >>>> >>>> MCHttpRepository >>>> location: >>>> 'http://www.smalltalkhub.com/mc/liangbing/Text-DragDrop/main' >>>> user: '' >>>> password: '' >>>> >>>> >>>> >>> >> >> >> > > >

May 21, 2016