- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Crazy Smalltalk code snippets

by ClÃ©ment Bera

Hello, The pharo continuations were ported from seaside because several people were using seaside continuations in non seaside related projects. I wouldn't rely on assigning the receiver on thisContext because it's a bit buggy. See: ByteSymbol>>bar thisContext receiver: #foo. ^ self 10 timesRepeat: [Transcript show: #bar bar] Transcript: foofoofoobarbarbarbarbarbarbar 2014-03-25 0:58 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > On Mon, Mar 24, 2014 at 4:33 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> On Tue, Mar 25, 2014 at 12:11 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> >>> >>> >>> On Mon, Mar 24, 2014 at 4:02 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: >>> >>>> 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. >>>> >>> >>> It *should* "just work" :-) (provided the jump distance of -12 is >>> correct). The VM traps assignments to variables of contexts, and converts >>> them to vanilla contexts. Therefore the jump doesn't occur in JITTED code >>> but back in normal interpreted bytecode. >>> >>> >> How magical! >> >> >>> 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 :-) >>>>> >>>> >>> this is my favourite, and would lock-up a strict blue book VM. (I once >>> locked up Allen Wirfs-Brock's 4404 with this and he wasn't best pleased >>> [forgive me Allen]) >>> >>> >>> | a | >>> a := Array with: #perform:withArguments: with: nil. >>> a at: 2 put: a. >>> a perform: a first withArguments: a >>> >>> ;-) >>> >>> >> >> The infinite is near. >> >> Not as blocking, but still... (Alt-. interrupts this one) >> >> Crazy>>run >> Continuation currentDo: [ :cc | here := cc ]. >> here value: true. >> >> Crazy new run >> >> BTW, is there any support for partial continuations in Pharo? >> Continuations like this one look like full continuations and that's *huge*. >> > > Yes, see Seaside. Remember a Process is simply a linked list of context > /objects/, so it is easy to copy as much or as little of one as one wants. > > >> >> >> >>>>> Cheers, >>>>> -- Pavel >>>>> >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> > > > -- > best, > Eliot >

March 25, 2014

Re: [Pharo-dev] threading in Pharo

by Stephan Eggermont

Alexandre 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. I hope you have large collections use multiple arrays? In other systems Iâve mostly found copying/moving the arrays to be more of a bottleneck. Why do you use 15% less memory? Stephan

March 25, 2014

Re: [Pharo-dev] Crazy Smalltalk code snippets

by Eliot Miranda

On Mon, Mar 24, 2014 at 4:33 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > On Tue, Mar 25, 2014 at 12:11 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> >> On Mon, Mar 24, 2014 at 4:02 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: >> >>> 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. >>> >> >> It *should* "just work" :-) (provided the jump distance of -12 is >> correct). The VM traps assignments to variables of contexts, and converts >> them to vanilla contexts. Therefore the jump doesn't occur in JITTED code >> but back in normal interpreted bytecode. >> >> > How magical! > > >> 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 :-) >>>> >>> >> this is my favourite, and would lock-up a strict blue book VM. (I once >> locked up Allen Wirfs-Brock's 4404 with this and he wasn't best pleased >> [forgive me Allen]) >> >> >> | a | >> a := Array with: #perform:withArguments: with: nil. >> a at: 2 put: a. >> a perform: a first withArguments: a >> >> ;-) >> >> > > The infinite is near. > > Not as blocking, but still... (Alt-. interrupts this one) > > Crazy>>run > Continuation currentDo: [ :cc | here := cc ]. > here value: true. > > Crazy new run > > BTW, is there any support for partial continuations in Pharo? > Continuations like this one look like full continuations and that's *huge*. > Yes, see Seaside. Remember a Process is simply a linked list of context /objects/, so it is easy to copy as much or as little of one as one wants. > > > >>>> Cheers, >>>> -- Pavel >>>> >>> >>> >> >> >> -- >> best, >> Eliot >> > > -- best, Eliot

March 25, 2014

Re: [Pharo-dev] Crazy Smalltalk code snippets

by phil＠highoctane.be

On Tue, Mar 25, 2014 at 12:11 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Mon, Mar 24, 2014 at 4:02 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> 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. >> > > It *should* "just work" :-) (provided the jump distance of -12 is > correct). The VM traps assignments to variables of contexts, and converts > them to vanilla contexts. Therefore the jump doesn't occur in JITTED code > but back in normal interpreted bytecode. > > How magical! > 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 :-) >>> >> > this is my favourite, and would lock-up a strict blue book VM. (I once > locked up Allen Wirfs-Brock's 4404 with this and he wasn't best pleased > [forgive me Allen]) > > > | a | > a := Array with: #perform:withArguments: with: nil. > a at: 2 put: a. > a perform: a first withArguments: a > > ;-) > > The infinite is near. Not as blocking, but still... (Alt-. interrupts this one) Crazy>>run Continuation currentDo: [ :cc | here := cc ]. here value: true. Crazy new run BTW, is there any support for partial continuations in Pharo? Continuations like this one look like full continuations and that's *huge*. >>> Cheers, >>> -- Pavel >>> >> >> > > > -- > best, > Eliot >

March 25, 2014

Re: [Pharo-dev] Crazy Smalltalk code snippets

by Eliot Miranda

On Mon, Mar 24, 2014 at 4:02 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > 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. > It *should* "just work" :-) (provided the jump distance of -12 is correct). The VM traps assignments to variables of contexts, and converts them to vanilla contexts. Therefore the jump doesn't occur in JITTED code but back in normal interpreted bytecode. 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 :-) >> > this is my favourite, and would lock-up a strict blue book VM. (I once locked up Allen Wirfs-Brock's 4404 with this and he wasn't best pleased [forgive me Allen]) | a | a := Array with: #perform:withArguments: with: nil. a at: 2 put: a. a perform: a first withArguments: a ;-) > >> Cheers, >> -- Pavel >> > > -- best, Eliot

March 25, 2014

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 25, 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