June 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Minimal kernel

by Esteban Lorenzano

> On 21 Jun 2018, at 09:18, Guido Chari <charig(a)gmail.com> wrote: > > > > El lun., 11 jun. 2018 a las 21:25, HernÃ¡n Morales Durand (<hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>>) escribiÃ³: > Hi Pablo, > > 2018-06-11 6:06 GMT-03:00 tesonep(a)gmail.com <mailto:tesonep@gmail.com> <tesonep(a)gmail.com <mailto:tesonep@gmail.com>>: > > You can execute the bootstrap process. > > How you do that? > > Yes, I am wondering the same. guys, is written in the README (I donât want to be rude, but that would be RTFM ;) ) now *after* that, there can be problems. We will be pleased to hear about them and help :) cheers! Esteban > Is it any documentation on how to run the bootstrap process? In my case I need an image that is functional, but as small as possible. > > > > However, maybe that is not required, as the bootstrapped images for Pharo7 > > are stored. > > > > > > These are the latest (always): > > > > Compiler: > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > > Compiler + Traits: > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > > > > Both links return a: > > Problem accessing > /pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo-core-7.0.0-alpha.build.1037.sha.7fc6bdf.arch.32bit.zip. > Reason: > > Not Found > > Btw, aren't the miniaml images in http://files.pharo.org/image/60/ <http://files.pharo.org/image/60/> usable? Is there any 64bit compatible minimal image available? > > > Cheers, > > Hernan > > > These are the first images that are usable, the first one has a compiler and > > the second adds the traits implementation. > > As Esteban said, you can modify the process to bootstrap whatever you want. > > However, having an image that does not have compiler it is more difficult to > > use. > > > > If you define better what do you call a minimal image we can help you more. > > > > Cheers, > > Pablo > > > > > > On Mon, Jun 11, 2018 at 10:30 AM, Guido Chari <charig(a)gmail.com <mailto:charig@gmail.com>> wrote: > >> > >> Hi, > >> > >> Is there any way to build a minimal (kernel) pharo image or at least some > >> kind of small image without the whole default packages? > >> > >> Best regards, > >> Guido. > > > > > > > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com <mailto:tesonep@gmail.com> >

June 21, 2018

Re: [Pharo-dev] Minimal kernel

by Guido Chari

El lun., 11 jun. 2018 a las 21:25, HernÃ¡n Morales Durand (< hernan.morales(a)gmail.com>) escribiÃ³: > Hi Pablo, > > 2018-06-11 6:06 GMT-03:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > > You can execute the bootstrap process. > > How you do that? > Yes, I am wondering the same. Is it any documentation on how to run the bootstrap process? In my case I need an image that is functional, but as small as possible. > > > However, maybe that is not required, as the bootstrapped images for > Pharo7 > > are stored. > > > > > > These are the latest (always): > > > > Compiler: > > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > Compiler + Traits: > > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > > Both links return a: > > Problem accessing > > /pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo-core-7.0.0-alpha.build.1037.sha.7fc6bdf.arch.32bit.zip. > Reason: > > Not Found > Btw, aren't the miniaml images in http://files.pharo.org/image/60/ usable? Is there any 64bit compatible minimal image available? > > Cheers, > > Hernan > > > These are the first images that are usable, the first one has a compiler > and > > the second adds the traits implementation. > > As Esteban said, you can modify the process to bootstrap whatever you > want. > > However, having an image that does not have compiler it is more > difficult to > > use. > > > > If you define better what do you call a minimal image we can help you > more. > > > > Cheers, > > Pablo > > > > > > On Mon, Jun 11, 2018 at 10:30 AM, Guido Chari <charig(a)gmail.com> wrote: > >> > >> Hi, > >> > >> Is there any way to build a minimal (kernel) pharo image or at least > some > >> kind of small image without the whole default packages? > >> > >> Best regards, > >> Guido. > > > > > > > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com > >

June 21, 2018

Re: [Pharo-dev] Fuel Error in Latest Launcher

by Max Leske

Good on you! I don't need the information for Fuel, but if you discovered a compiler bug it would help to post the information. Max On 21 Jun 2018, at 5:54, Sean P. DeNigris wrote: > Eliot Miranda-2 wrote >> could you post some more information? > > Hey guys, I solved my problem by recreating the blocks in question. I > got > lucky that they were all default values, so that was easy. However, if > the > problem is an interesting one, I can go back to the corrupt data and > get the > info you requestedâ¦ > > > > ----- > Cheers, > Sean > -- > Sent from: > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 21, 2018

Re: [Pharo-dev] Fuel Error in Latest Launcher

by Sean P. DeNigris

Eliot Miranda-2 wrote > could you post some more information? Hey guys, I solved my problem by recreating the blocks in question. I got lucky that they were all default values, so that was easy. However, if the problem is an interesting one, I can go back to the corrupt data and get the info you requestedâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 21, 2018

Re: [Pharo-dev] Hash on collections

by Nicolas Cellier

2018-06-21 0:16 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2018-06-21 0:00 GMT+02:00 <Vincent.Blondeau(a)lamresearch.com>: > >> >> >> >> >> *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf >> Of *Nicolas Cellier >> *Sent:* Wednesday, June 20, 2018 14:52 >> *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> >> *Subject:* Re: [Pharo-dev] Hash on collections >> >> >> >> Hi, >> >> >> >> Hi, >> >> >> >> >> >> it does not look like a good hash (in term of probability of collisions) >> and would deserve a revision. >> >> But what problem did you detect wrt equality? >> >> >> >> None, I was just wondering why there is a limit defined at 10 and if a >> problem can exist due to this. >> >> >> >> The implication is this way: >> >> self assert: (a = b) ==> (a hash = b hash) >> >> >> >> Since the element hash are bitXor'ed, the resulting hash will be >> independent of ordering of elements. >> >> It will thus work for unordered collections (like Set in which ordering >> depends on container size). >> >> (and badly for others if they omit to refine hash). >> >> >> >> Thx for the explanation! >> >> Or is it because Collection of different species could be equal? >> >> >> >> I was watching to the dictionaries #= and #hash. And indeed, it is not a >> problem in it. But the hash used is really not efficient for unordered >> collections of unordered collections of same size. >> >> >> >> Vincent >> >> >> > > Indeed, > but remember that we even not have a guaranty that Collection are of > finite size... > I would expect that they are countable (by virtue of do: we can iterate > over its elements, possibly with an infinite loop). > So it would make sense to refine hash in Set/Dictionary/HashedCollection > and remove the size limitation there... > > Maybe something like ^self inject: self size hash into: [:hash :elem | > hash bitXor: elem hash]. > > > Oh, and I forgot, you could offer you the book of Andres Valloud: http://www.lulu.com/shop/andres-valloud/hashing-in-smalltalk-theory-and-pra… it will give a pretty deep insight in hashing algorithm efficiency (and measurement of). Nicolas >> >> >> >> 2018-06-20 23:15 GMT+02:00 <Vincent.Blondeau(a)lamresearch.com>: >> >> Hi, >> >> I was watching to the Collection>>#hash implementation and I found >> something strange: >> self size <= 10 ifTrue: >> [self do: [:elem | hash := hash bitXor: >> elem hash]]. >> >> Can someone know why the contents are only considered for the hash if the >> collection size is below 10? Is that a bug or a feature? >> >> Moreover, it is in contradiction with the end of the comment: >> -- two equal objects have equal hash values >> >> TIA, >> >> Cheers, >> Vincent >> >> >> > >

June 20, 2018

Re: [Pharo-dev] Hash on collections

by Nicolas Cellier

2018-06-21 0:00 GMT+02:00 <Vincent.Blondeau(a)lamresearch.com>: > > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Nicolas Cellier > *Sent:* Wednesday, June 20, 2018 14:52 > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] Hash on collections > > > > Hi, > > > > Hi, > > > > > > it does not look like a good hash (in term of probability of collisions) > and would deserve a revision. > > But what problem did you detect wrt equality? > > > > None, I was just wondering why there is a limit defined at 10 and if a > problem can exist due to this. > > > > The implication is this way: > > self assert: (a = b) ==> (a hash = b hash) > > > > Since the element hash are bitXor'ed, the resulting hash will be > independent of ordering of elements. > > It will thus work for unordered collections (like Set in which ordering > depends on container size). > > (and badly for others if they omit to refine hash). > > > > Thx for the explanation! > > Or is it because Collection of different species could be equal? > > > > I was watching to the dictionaries #= and #hash. And indeed, it is not a > problem in it. But the hash used is really not efficient for unordered > collections of unordered collections of same size. > > > > Vincent > > > Indeed, but remember that we even not have a guaranty that Collection are of finite size... I would expect that they are countable (by virtue of do: we can iterate over its elements, possibly with an infinite loop). So it would make sense to refine hash in Set/Dictionary/HashedCollection and remove the size limitation there... Maybe something like ^self inject: self size hash into: [:hash :elem | hash bitXor: elem hash]. Nicolas > > > > 2018-06-20 23:15 GMT+02:00 <Vincent.Blondeau(a)lamresearch.com>: > > Hi, > > I was watching to the Collection>>#hash implementation and I found > something strange: > self size <= 10 ifTrue: > [self do: [:elem | hash := hash bitXor: > elem hash]]. > > Can someone know why the contents are only considered for the hash if the > collection size is below 10? Is that a bug or a feature? > > Moreover, it is in contradiction with the end of the comment: > -- two equal objects have equal hash values > > TIA, > > Cheers, > Vincent > > >

June 20, 2018

Re: [Pharo-dev] Hash on collections

by Vincent.Blondeau＠lamresearch.com

From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolas Cellier Sent: Wednesday, June 20, 2018 14:52 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Hash on collections Hi, Hi, it does not look like a good hash (in term of probability of collisions) and would deserve a revision. But what problem did you detect wrt equality? None, I was just wondering why there is a limit defined at 10 and if a problem can exist due to this. The implication is this way: self assert: (a = b) ==> (a hash = b hash) Since the element hash are bitXor'ed, the resulting hash will be independent of ordering of elements. It will thus work for unordered collections (like Set in which ordering depends on container size). (and badly for others if they omit to refine hash). Thx for the explanation! Or is it because Collection of different species could be equal? I was watching to the dictionaries #= and #hash. And indeed, it is not a problem in it. But the hash used is really not efficient for unordered collections of unordered collections of same size. Vincent Nicolas 2018-06-20 23:15 GMT+02:00 <Vincent.Blondeau(a)lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>>: Hi, I was watching to the Collection>>#hash implementation and I found something strange: self size <= 10 ifTrue: [self do: [:elem | hash := hash bitXor: elem hash]]. Can someone know why the contents are only considered for the hash if the collection size is below 10? Is that a bug or a feature? Moreover, it is in contradiction with the end of the comment: -- two equal objects have equal hash values TIA, Cheers, Vincent

June 20, 2018

Re: [Pharo-dev] Hash on collections

by Nicolas Cellier

Hi, it does not look like a good hash (in term of probability of collisions) and would deserve a revision. But what problem did you detect wrt equality? The implication is this way: self assert: (a = b) ==> (a hash = b hash) Since the element hash are bitXor'ed, the resulting hash will be independent of ordering of elements. It will thus work for unordered collections (like Set in which ordering depends on container size). (and badly for others if they omit to refine hash). Or is it because Collection of different species could be equal? Nicolas 2018-06-20 23:15 GMT+02:00 <Vincent.Blondeau(a)lamresearch.com>: > Hi, > > I was watching to the Collection>>#hash implementation and I found > something strange: > self size <= 10 ifTrue: > [self do: [:elem | hash := hash bitXor: > elem hash]]. > > Can someone know why the contents are only considered for the hash if the > collection size is below 10? Is that a bug or a feature? > > Moreover, it is in contradiction with the end of the comment: > -- two equal objects have equal hash values > > TIA, > > Cheers, > Vincent > >

June 20, 2018

Hash on collections

by Vincent.Blondeau＠lamresearch.com

Hi, I was watching to the Collection>>#hash implementation and I found something strange: self size <= 10 ifTrue: [self do: [:elem | hash := hash bitXor: elem hash]]. Can someone know why the contents are only considered for the hash if the collection size is below 10? Is that a bug or a feature? Moreover, it is in contradiction with the end of the comment: -- two equal objects have equal hash values TIA, Cheers, Vincent

June 20, 2018

Re: [Pharo-dev] Fuel Error in Latest Launcher

by Eliot Miranda

Hi Sean, could you post some more information? What's the pc? What's the CompiledMethod's output for #symbolic? Where in interpretNextV3PlusClosureInstructionFor: is it stuck? What's the computed index? On Wed, Jun 20, 2018 at 6:07 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > While Fuel was trying to serialize a sort block ([ :a :b | a name < b name > ]), I got CompiledMethod>>errorSubscriptBounds:. One strange thing about > the > block is that the outerContext is `SortedCollection>>DoIt`, meaning I > probably had to initialize it by hand due to a previous Fuel problem. > > The odd thing about the error is that this object graph was serializing and > materializing just fine before I upgraded Pharo Launcher. > > Call chain: > CompiledMethod(Object)>>errorSubscriptBounds: > CompiledMethod(Object)>>at: > InstructionStream>>interpretNextV3PlusClosureInstructionFor: > OpalEncoderForV3PlusClosures class>>interpretNextInstructionFor:in: > InstructionStream>>interpretNextInstructionFor: > [ (InstructionStream new method: self pc: pc) > interpretNextInstructionFor: nil ] in > CompiledMethod(CompiledCode)>>abstractBytecodeMessageAt: in Block: [ > (InstructionStream new method: self pc: pc)... > BlockClosure>>on:do: > CompiledMethod(CompiledCode)>>abstractBytecodeMessageAt: > BlockClosure>>blockCreationBytecodeMessage > BlockClosure>>endPC > BlockClosure>>abstractBytecodeMessagesDo: > BlockClosure>>isClean > BlockClosure>>shouldBeSubstitutedByCleanCopy > BlockClosure>>fuelAccept: > FLLightGeneralMapper>>mapAndTrace: > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- _,,,^..^,,,_ best, Eliot

June 20, 2018