- Pharo-dev - lists.pharo.org

About Smalltalk ui icons...

by stepharo

loadConfigurationButton: aList <menu> aList act: [ :presenter | self onLoadFrom: presenter ] icon: Smalltalk ui icons configIcon entitled: 'Load configuration (do not install project)' why we could not have something like loadConfigurationButton: aList <menu> aList act: [ :presenter | self onLoadFrom: presenter ] icon: #configIcon entitled: 'Load configuration (do not install project)' and the class knows how to fetch it?

May 22, 2016

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

by Esteban Lorenzano

> On 22 May 2016, at 17:26, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Henrik, > > cc'ing squeak-dev cuz this is relevant to both communities (if and until Pharo takes the unwise decision to double the size of the image by keeping sources in the image). this will not happen :) yes, we have played with the idea, but at the end we have some good reasons to not do itâ¦ but by the way, it was not âdoublingâ because what we were keeping was a compressed version. What weâll probably do is to change the file format to a real hash database for sources (like CDB, or something) and to epicea for changes (because epicea can store full refactor histories, etcâ¦)â¦ but this format migration is still very green, we need first to extract the functionality and decouple it (because now read/write is scattered all over the image). > > On May 22, 2016, at 5:01 AM, Henrik Nergaard <henrik.nergaard(a)uia.no <mailto:henrik.nergaard@uia.no>> wrote: > >> 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. > > I like this approach, but it has a fatal flaw. If one is debugging file access, then as the debugger causes the source of methods to be fetched as the debugger displays them, so the file pointer in the read-only file the access of which one is trying to debug will change under one's feet, and the results will be completely wrong. > > An approach which uses a special copy for the debugger doesn't work; one can't debug access to that file for the same reason. > > An approach that /should/ work is for the debugger to install its own copy around file-access. This should be recursive. So around every file access in the debugger there would need to be something like > > SourceFiles substituteFreshReadOnlyCopiesDuring: [...file access...] > > which would remember the current read-only files, evaluate the block using ensure: and have the ensure: block reinstall the previous file. > > Does this make sense? > >> >> 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 <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 <mailto:pharo-dev@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] From a mooc user: method source with it' take so long in Pharo 5

by Eliot Miranda

Hi Henrik, cc'ing squeak-dev cuz this is relevant to both communities (if and until Pharo takes the unwise decision to double the size of the image by keeping sources in the image). > On May 22, 2016, at 5:01 AM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > 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. I like this approach, but it has a fatal flaw. If one is debugging file access, then as the debugger causes the source of methods to be fetched as the debugger displays them, so the file pointer in the read-only file the access of which one is trying to debug will change under one's feet, and the results will be completely wrong. An approach which uses a special copy for the debugger doesn't work; one can't debug access to that file for the same reason. An approach that /should/ work is for the debugger to install its own copy around file-access. This should be recursive. So around every file access in the debugger there would need to be something like SourceFiles substituteFreshReadOnlyCopiesDuring: [...file access...] which would remember the current read-only files, evaluate the block using ensure: and have the ensure: block reinstall the previous file. Does this make sense? > > 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>: > 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] From a mooc user: method source with it' take so long in Pharo 5

by Eliot Miranda

Hi Steph, almost certainly because in Pharo the sources file is opened once for each method whereas in squeak a read-only copy is taken and reused. I don't like the squeak approach: CurrentReadOnlySourceFiles cacheDuring: [...] but it does play well with the debugger. So fixing this elegantly is non-trivial. I suggest you try and real squeak-dev messages talking about CurrentReadOnlySourceFiles and "read-only copies" of the sources files. _,,,^..^,,,_ (phone) > On May 18, 2016, at 10:12 AM, stepharo <stepharo(a)free.fr> wrote: > > 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] [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