March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Crazy Smalltalk code snippets

by phil＠highoctane.be

I am curious. Maybe on the first one, substitute something when a DNU is encountered. Like logging undefined receivers. I wonder how the next one behaves on JITted methods. I fear that offset errors may lead to weird errors. On Mon, Mar 24, 2014 at 11:51 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Who can find the most useful usage of this? > > thisContext instVarNamed: #receiver put: 42. > self factorial > > GOTO statement in Pharo: > > FileStream stdout nextPutAll: 'Hello world'; lf. > thisContext jump: -12. > Let's collect the next ones :-) > > Cheers, > -- Pavel >

March 24, 2014

Crazy Smalltalk code snippets

by Pavel Krivanek

Who can find the most useful usage of this? thisContext instVarNamed: #receiver put: 42. self factorial GOTO statement in Pharo: FileStream stdout nextPutAll: 'Hello world'; lf. thisContext jump: -12. Let's collect the next ones :-) Cheers, -- Pavel

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Eliot Miranda

Also Smalltalk-80: the Language and its Implementation (the Blue Book<http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf>) has a good chapter, Chapter 15: 15 Multiple Independent Processes On Mon, Mar 24, 2014 at 3:29 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Here is the better documentation I found online about it when I learnt it: > > http://wiki.squeak.org/squeak/382 > > Afterwards... reading the vm and playing was the hard way to learn it... > > Then it seems there is an ongoing chapter in the topic > > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > > > On Mon, Mar 24, 2014 at 10:54 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> >>> >> I am working on a memory model for expandable collection in Pharo. >>> Currently, OrderedCollection, Dictionary and other expandable collections >>> use a internal array to store their data. My new collection library recycle >>> these array instead of letting the garbage collector dispose them. I simply >>> insert the arrays in an ordered collection when an array is not necessary >>> anymore. And I remove one when I need one. >>> > >>> > Hm, is that really going to be worth the trouble? >>> >>> This technique reduces the consumption of about 15% of memory. >>> >>> >> At the end, #add: and #remove: are performed on these polls of >>> arrays. I haven't been able to spot any problem regarding concurrency and I >>> made no effort in preventing them. I have a simple global collection and >>> each call site of "OrderedCollection new" can pick an element of my global >>> collection. >>> >> >>> >> I have the impression that I simply need to guard the access to the >>> global poll, which is basically guarding #add: #remove: and #includes: >>> > >>> > One of the AtomicCollections might be the right things for you? >>> >>> I will have a look at it. >>> >>> >> What is funny, is that I did not care at all about multi-threading >>> and concurrency, and I have not spotted any problem so far. >>> > >>> > There isn't any 'multi-threading' like in Java, you got a much more >>> control version: cooperative on the same priority, preemptive between >>> priorities. >>> > So, I am not surprised. And well, these operations are likely not to >>> be problematic when they are racy, except when the underling data structure >>> could get into an inconsistent state itself. The overall operations >>> (adding/removing/searing) are racy on the application level anyway. >>> > >>> > However, much more interesting would be to know what kind of benefit >>> do you see for such reuse? >>> > And especially, with Spur around the corner, will it still pay off >>> then? Or is it an application-specific optimization? >>> >>> I am exploring a new design of the collection library of Pharo. Not all >>> the (academic) ideas will be worth porting into the mainstream of Pharo. >>> But some of them yes. >>> >>> Thanks for all your help guys! You're great! >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> An interesting method I stumbled upon which may help in understanding how >> these things do work. >> >> BlockClosure>>valueUnpreemptively >> "Evaluate the receiver (block), without the possibility of preemption >> by higher priority processes. Use this facility VERY sparingly!" >> "Think about using Block>>valueUninterruptably first, and think about >> using Semaphore>>critical: before that, and think about redesigning your >> application even before that! >> After you've done all that thinking, go right ahead and use it..." >> | activeProcess oldPriority result semaphore | >> activeProcess := Processor activeProcess. >> oldPriority := activeProcess priority. >> activeProcess priority: Processor highestPriority. >> result := self ensure: [activeProcess priority: oldPriority]. >> >> > -- best, Eliot

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by phil＠highoctane.be

Chapters 17 and 18 are interesting too. http://stephane.ducasse.free.fr/FreeBooks/ByExample/SmalltalkByExampleNewRe… On Mon, Mar 24, 2014 at 11:29 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Here is the better documentation I found online about it when I learnt it: > > http://wiki.squeak.org/squeak/382 > > Afterwards... reading the vm and playing was the hard way to learn it... > > Then it seems there is an ongoing chapter in the topic > > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > > > On Mon, Mar 24, 2014 at 10:54 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> >>> >> I am working on a memory model for expandable collection in Pharo. >>> Currently, OrderedCollection, Dictionary and other expandable collections >>> use a internal array to store their data. My new collection library recycle >>> these array instead of letting the garbage collector dispose them. I simply >>> insert the arrays in an ordered collection when an array is not necessary >>> anymore. And I remove one when I need one. >>> > >>> > Hm, is that really going to be worth the trouble? >>> >>> This technique reduces the consumption of about 15% of memory. >>> >>> >> At the end, #add: and #remove: are performed on these polls of >>> arrays. I haven't been able to spot any problem regarding concurrency and I >>> made no effort in preventing them. I have a simple global collection and >>> each call site of "OrderedCollection new" can pick an element of my global >>> collection. >>> >> >>> >> I have the impression that I simply need to guard the access to the >>> global poll, which is basically guarding #add: #remove: and #includes: >>> > >>> > One of the AtomicCollections might be the right things for you? >>> >>> I will have a look at it. >>> >>> >> What is funny, is that I did not care at all about multi-threading >>> and concurrency, and I have not spotted any problem so far. >>> > >>> > There isn't any 'multi-threading' like in Java, you got a much more >>> control version: cooperative on the same priority, preemptive between >>> priorities. >>> > So, I am not surprised. And well, these operations are likely not to >>> be problematic when they are racy, except when the underling data structure >>> could get into an inconsistent state itself. The overall operations >>> (adding/removing/searing) are racy on the application level anyway. >>> > >>> > However, much more interesting would be to know what kind of benefit >>> do you see for such reuse? >>> > And especially, with Spur around the corner, will it still pay off >>> then? Or is it an application-specific optimization? >>> >>> I am exploring a new design of the collection library of Pharo. Not all >>> the (academic) ideas will be worth porting into the mainstream of Pharo. >>> But some of them yes. >>> >>> Thanks for all your help guys! You're great! >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> An interesting method I stumbled upon which may help in understanding how >> these things do work. >> >> BlockClosure>>valueUnpreemptively >> "Evaluate the receiver (block), without the possibility of preemption >> by higher priority processes. Use this facility VERY sparingly!" >> "Think about using Block>>valueUninterruptably first, and think about >> using Semaphore>>critical: before that, and think about redesigning your >> application even before that! >> After you've done all that thinking, go right ahead and use it..." >> | activeProcess oldPriority result semaphore | >> activeProcess := Processor activeProcess. >> oldPriority := activeProcess priority. >> activeProcess priority: Processor highestPriority. >> result := self ensure: [activeProcess priority: oldPriority]. >> >> >

March 24, 2014

Trait1 Trait2 Trait3 in Smalltalk globals allClassesAndTraits

by phil＠highoctane.be

On a fresh 3.0, there are Trait1, Trait2 and Trait3 in Smalltalk globals allClassesAndTraits These 3 look like they are equivalents to Trait. What are these for? Phil

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Guillermo Polito

Here is the better documentation I found online about it when I learnt it: http://wiki.squeak.org/squeak/382 Afterwards... reading the vm and playing was the hard way to learn it... Then it seems there is an ongoing chapter in the topic https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… On Mon, Mar 24, 2014 at 10:54 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> >> I am working on a memory model for expandable collection in Pharo. >> Currently, OrderedCollection, Dictionary and other expandable collections >> use a internal array to store their data. My new collection library recycle >> these array instead of letting the garbage collector dispose them. I simply >> insert the arrays in an ordered collection when an array is not necessary >> anymore. And I remove one when I need one. >> > >> > Hm, is that really going to be worth the trouble? >> >> This technique reduces the consumption of about 15% of memory. >> >> >> At the end, #add: and #remove: are performed on these polls of >> arrays. I haven't been able to spot any problem regarding concurrency and I >> made no effort in preventing them. I have a simple global collection and >> each call site of "OrderedCollection new" can pick an element of my global >> collection. >> >> >> >> I have the impression that I simply need to guard the access to the >> global poll, which is basically guarding #add: #remove: and #includes: >> > >> > One of the AtomicCollections might be the right things for you? >> >> I will have a look at it. >> >> >> What is funny, is that I did not care at all about multi-threading and >> concurrency, and I have not spotted any problem so far. >> > >> > There isn't any 'multi-threading' like in Java, you got a much more >> control version: cooperative on the same priority, preemptive between >> priorities. >> > So, I am not surprised. And well, these operations are likely not to be >> problematic when they are racy, except when the underling data structure >> could get into an inconsistent state itself. The overall operations >> (adding/removing/searing) are racy on the application level anyway. >> > >> > However, much more interesting would be to know what kind of benefit do >> you see for such reuse? >> > And especially, with Spur around the corner, will it still pay off >> then? Or is it an application-specific optimization? >> >> I am exploring a new design of the collection library of Pharo. Not all >> the (academic) ideas will be worth porting into the mainstream of Pharo. >> But some of them yes. >> >> Thanks for all your help guys! You're great! >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > An interesting method I stumbled upon which may help in understanding how > these things do work. > > BlockClosure>>valueUnpreemptively > "Evaluate the receiver (block), without the possibility of preemption by > higher priority processes. Use this facility VERY sparingly!" > "Think about using Block>>valueUninterruptably first, and think about > using Semaphore>>critical: before that, and think about redesigning your > application even before that! > After you've done all that thinking, go right ahead and use it..." > | activeProcess oldPriority result semaphore | > activeProcess := Processor activeProcess. > oldPriority := activeProcess priority. > activeProcess priority: Processor highestPriority. > result := self ensure: [activeProcess priority: oldPriority]. > >

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by phil＠highoctane.be

On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > >> I am working on a memory model for expandable collection in Pharo. > Currently, OrderedCollection, Dictionary and other expandable collections > use a internal array to store their data. My new collection library recycle > these array instead of letting the garbage collector dispose them. I simply > insert the arrays in an ordered collection when an array is not necessary > anymore. And I remove one when I need one. > > > > Hm, is that really going to be worth the trouble? > > This technique reduces the consumption of about 15% of memory. > > >> At the end, #add: and #remove: are performed on these polls of arrays. > I haven't been able to spot any problem regarding concurrency and I made no > effort in preventing them. I have a simple global collection and each call > site of "OrderedCollection new" can pick an element of my global collection. > >> > >> I have the impression that I simply need to guard the access to the > global poll, which is basically guarding #add: #remove: and #includes: > > > > One of the AtomicCollections might be the right things for you? > > I will have a look at it. > > >> What is funny, is that I did not care at all about multi-threading and > concurrency, and I have not spotted any problem so far. > > > > There isn't any 'multi-threading' like in Java, you got a much more > control version: cooperative on the same priority, preemptive between > priorities. > > So, I am not surprised. And well, these operations are likely not to be > problematic when they are racy, except when the underling data structure > could get into an inconsistent state itself. The overall operations > (adding/removing/searing) are racy on the application level anyway. > > > > However, much more interesting would be to know what kind of benefit do > you see for such reuse? > > And especially, with Spur around the corner, will it still pay off then? > Or is it an application-specific optimization? > > I am exploring a new design of the collection library of Pharo. Not all > the (academic) ideas will be worth porting into the mainstream of Pharo. > But some of them yes. > > Thanks for all your help guys! You're great! > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > An interesting method I stumbled upon which may help in understanding how these things do work. BlockClosure>>valueUnpreemptively "Evaluate the receiver (block), without the possibility of preemption by higher priority processes. Use this facility VERY sparingly!" "Think about using Block>>valueUninterruptably first, and think about using Semaphore>>critical: before that, and think about redesigning your application even before that! After you've done all that thinking, go right ahead and use it..." | activeProcess oldPriority result semaphore | activeProcess := Processor activeProcess. oldPriority := activeProcess priority. activeProcess priority: Processor highestPriority. result := self ensure: [activeProcess priority: oldPriority].

March 24, 2014

Re: [Pharo-dev] Migration from Pharo 1.1 to 2.0

by Max Leske

Cool :) We were just discussing the other day if we really need to support old platforms. I guess hereâs the answer. On 24.03.2014, at 22:32, Laurent Laffont <laurent.laffont(a)gmail.com> wrote: > It works ! Thank you ! > > Laurent > > Le lundi 24 mars 2014, 22:10:14 Max Leske a Ã©crit : >> Fuel 1.9.3 still works with 1.1.1 >> >> On 24.03.2014, at 21:57, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >>> Fuel works from 1.1.1 to 3.0: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/… >>> >>> If I remember correctly.... 1.1.1 was just same image but with support for cog right? in such a case, it is likely it should work for 1.1 as well. >>> You can give it a try. >>> >>> Cheers, >>> >>> >>> On Mon, Mar 24, 2014 at 5:37 PM, Laurent Laffont <laurent.laffont(a)gmail.com> wrote: >>> Hi, >>> >>> is there a way to export / fileOut objects from Pharo 1.1 and reload them into Pharo 2.0 or 3.0 ? >>> >>> Cheers, >>> >>> Laurent >>> >>> >>> >>> >> > >

March 24, 2014

Re: [Pharo-dev] Migration from Pharo 1.1 to 2.0

by Laurent Laffont

It works ! Thank you ! Laurent Le lundi 24 mars 2014, 22:10:14 Max Leske a Ã©crit : > Fuel 1.9.3 still works with 1.1.1 > > On 24.03.2014, at 21:57, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > Fuel works from 1.1.1 to 3.0: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/… > > > > If I remember correctly.... 1.1.1 was just same image but with support for cog right? in such a case, it is likely it should work for 1.1 as well. > > You can give it a try. > > > > Cheers, > > > > > > On Mon, Mar 24, 2014 at 5:37 PM, Laurent Laffont <laurent.laffont(a)gmail.com> wrote: > > Hi, > > > > is there a way to export / fileOut objects from Pharo 1.1 and reload them into Pharo 2.0 or 3.0 ? > > > > Cheers, > > > > Laurent > > > > > > > > >

March 24, 2014

Re: [Pharo-dev] Migration from Pharo 1.1 to 2.0

by Max Leske

Fuel 1.9.3 still works with 1.1.1 On 24.03.2014, at 21:57, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Fuel works from 1.1.1 to 3.0: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/… > > If I remember correctly.... 1.1.1 was just same image but with support for cog right? in such a case, it is likely it should work for 1.1 as well. > You can give it a try. > > Cheers, > > > On Mon, Mar 24, 2014 at 5:37 PM, Laurent Laffont <laurent.laffont(a)gmail.com> wrote: > Hi, > > is there a way to export / fileOut objects from Pharo 1.1 and reload them into Pharo 2.0 or 3.0 ? > > Cheers, > > Laurent > > > > > -- > Mariano > http://marianopeck.wordpress.com

March 24, 2014