- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Multiple worlds

by Henrik Sperre Johansen

On 02.05.2012 16:22, Sean P. DeNigris wrote: > EstebanLM wrote >> I propose to just close the issue... having different words don't seems to >> match with current pharo approach and future envisioned scenarios. >> > What does that mean? For one thing, anybody that's been using TWM (like me) > has had multiple worlds already since 1.3. Also, the code is extremely > minimal (and could even be reduced a little more if that's the issue). > Finally, this is a powerful feature... think OS X Spaces... > > Sean > +1. Multiple worlds as per traditional morphic worlds = separate desktops containing different morphs, different change sets, separate other bits of state, fileOut/in of said state using image segments, various intertwingeling here and there to make it tick. Multiple worlds as proposed in the issue = separate desktops containing different morphs. Cheers, Henry

May 2, 2012

Re: [Pharo-project] Multiple worlds

by Esteban Lorenzano

In any case, it doesn't need to be in the core... maybe as part of TWM fits better? Sent from my iPhone On 02/05/2012, at 17:32, "H. Hirzel" <hannes.hirzel(a)gmail.com> wrote: > Thanks Sean for pointing this out. > > And is it possible to work with TWM in a way that you just use the > multiple worlds option, not the tiling mechanism? > > --Hannes > > On 5/2/12, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> EstebanLM wrote >>> >>> I propose to just close the issue... having different words don't seems >>> to >>> match with current pharo approach and future envisioned scenarios. >>> >> >> What does that mean? For one thing, anybody that's been using TWM (like me) >> has had multiple worlds already since 1.3. Also, the code is extremely >> minimal (and could even be reduced a little more if that's the issue). >> Finally, this is a powerful feature... think OS X Spaces... >> >> Sean >> >> -- >> View this message in context: >> http://forum.world.st/Multiple-worlds-tp4603200p4603357.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >

May 2, 2012

Re: [Pharo-project] Multiple worlds

by H. Hirzel

Thanks Sean for pointing this out. And is it possible to work with TWM in a way that you just use the multiple worlds option, not the tiling mechanism? --Hannes On 5/2/12, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote >> >> I propose to just close the issue... having different words don't seems >> to >> match with current pharo approach and future envisioned scenarios. >> > > What does that mean? For one thing, anybody that's been using TWM (like me) > has had multiple worlds already since 1.3. Also, the code is extremely > minimal (and could even be reduced a little more if that's the issue). > Finally, this is a powerful feature... think OS X Spaces... > > Sean > > -- > View this message in context: > http://forum.world.st/Multiple-worlds-tp4603200p4603357.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

May 2, 2012

Re: [Pharo-project] Multiple desktops

by Henrik Sperre Johansen

On 02.05.2012 15:40, H. Hirzel wrote: > How come? > > Maybe I should have chosen 'Multiple desktops' as the subject line. > > I just downloaded Pharo 1.4 a few days ago and with only one screen I > feel quickly limited. > > How are people dealing with this? > > Having different desktops for a system is not a uncommon thing at all. > > --Hannes I believe it was integrated into the TilingWindowManager package. It should be loadable through the Metacello Configurations Browser in 1.4, (Tools -> Configuration Browser), though I ran into a #DNU doing that... The monticello repository is http://www.squeaksource.com/TilingWindowManager . Cheers, Henry

May 2, 2012

[Pharo-project] Progress and changes

by Francois Stephany

This year Railsconf keynote reminds me something about Squeak, Pharo and the awesome work of the Pharo team :) http://37signals.com/svn/posts/3171-keynote-by-david-from-railsconf-2012-on…

May 2, 2012

Re: [Pharo-project] OSProcess error in 1.3

by Sean P. DeNigris

David T. Lewis wrote > > Can you please try two things, in this order, and let me know which > one causes the problem to go away? > Thanks, David. I can't reproduce the problem at the moment, but if it pops up again, I'll try those... Sean -- View this message in context: http://forum.world.st/OSProcess-error-in-1-3-tp4602389p4603501.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 2, 2012

Re: [Pharo-project] Nautilus load problem

by Marcus Denker

On May 2, 2012, at 4:55 PM, Sean P. DeNigris wrote: > Now I'm getting an error because GrowlMorph is not in the image. I'm on 1.4 > and the config is loading version 4.3 We did not release 1.4 with Nautilus because it is not ready. Now getting it ready will be double as hard if it has to run on both 1.4 and 2.0. Marcus -- Marcus Denker -- http://marcusdenker.de

May 2, 2012

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: Kernel-eem.684.mcz

by Mariano Martinez Peck

Hi stef. Eliot send us (me and marcus) a private email about these changes and a suggestion for Fuel. Marcus has already integrates all of these new methods ;) On Wed, May 2, 2012 at 4:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > Begin forwarded message: > > *From: *pharo-project-owner(a)lists.gforge.inria.fr > *Subject: **Fwd: [squeak-dev] The Trunk: Kernel-eem.684.mcz* > *Date: *April 30, 2012 6:48:24 PM GMT+02:00 > *To: *stephane.ducasse(a)gmail.com > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > *From: *stephane ducasse <stephane.ducasse(a)gmail.com> > *Subject: **Fwd: [squeak-dev] The Trunk: Kernel-eem.684.mcz* > *Date: *April 30, 2012 6:46:40 PM GMT+02:00 > *To: *Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > > > > > Begin forwarded message: > > From: commits(a)source.squeak.org > > Subject: [squeak-dev] The Trunk: Kernel-eem.684.mcz > > Date: April 26, 2012 6:07:56 PM GMT+02:00 > > To: squeak-dev(a)lists.squeakfoundation.org, > packages(a)lists.squeakfoundation.org > > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > > Eliot Miranda uploaded a new version of Kernel to project The Trunk: > > http://source.squeak.org/trunk/Kernel-eem.684.mcz > > > ==================== Summary ==================== > > > Name: Kernel-eem.684 > > Author: eem > > Time: 26 April 2012, 11:07:37.737 am > > UUID: e838a325-27ec-4a62-a907-d4059451a046 > > Ancestors: Kernel-nice.683 > > > Implement endPC numArgs and numTemps for closures > > and contexts (both block and method activations). > > Provide CompiledMethod>abstractBytecodeMessagesDo: > > et al. > > Implement BlockClosure>isClean to identify self-contained blocks. > > > =============== Diff against Kernel-nice.683 =============== > > > Item was added: > > + ----- Method: BlockClosure>>abstractBytecodeMessagesDo: (in category > 'scanning') ----- > > + abstractBytecodeMessagesDo: aBlock > > + "Evaluate aBlock with the sequence of abstract bytecodes in the > receiver." > > + self method > > + abstractBytecodeMessagesFrom: startpc > > + to: self endPC > > + do: aBlock > > + > > + "| msgs | > > + msgs := OrderedCollection new. > > + (SortedCollection sortBlock: [:a :b| a compare: b caseSensitive: > false]) sortBlock > > + abstractBytecodeMessagesDo: [:msg| msgs add: msg selector]. > > + msgs"! > > > Item was added: > > + ----- Method: BlockClosure>>blockCreationBytecodeMessage (in category > 'scanning') ----- > > + blockCreationBytecodeMessage > > + "Answer the abstract bytecode message that created the receiver." > > + | blockCreationBytecodeSize | > > + ^self method abstractBytecodeMessageAt: startpc - > (blockCreationBytecodeSize := 4) > > + > > + "(SortedCollection sortBlock: [:a :b| a compare: b caseSensitive: > false]) sortBlock blockCreationBytecodeMessage"! > > > Item was added: > > + ----- Method: BlockClosure>>endPC (in category 'accessing') ----- > > + endPC > > + ^self blockCreationBytecodeMessage arguments last + startpc - 1! > > > Item was changed: > > ----- Method: BlockClosure>>hasMethodReturn (in category 'testing') ----- > > hasMethodReturn > > "Answer whether the receiver has a method-return ('^') in its code." > > + | scanner endpc | > > + scanner := InstructionStream new method: outerContext method pc: > startpc. > > + endpc := self endPC. > > + scanner scanFor: [:byte | (byte between: 120 and: 124) or: [scanner pc > > endpc]]. > > + ^scanner pc <= endpc! > > - | myMethod scanner preceedingBytecodeMessage end | > > - "Determine end of block from the instruction preceding it. > > - Find the instruction by using an MNU handler to capture > > - the instruction message sent by the scanner." > > - myMethod := outerContext method. > > - scanner := InstructionStream new method: myMethod pc: myMethod > initialPC. > > - [scanner pc < startpc] whileTrue: > > - [[scanner interpretNextInstructionFor: nil] > > - on: MessageNotUnderstood > > - do: [:ex| preceedingBytecodeMessage := ex message]]. > > - end := preceedingBytecodeMessage arguments last + startpc - 1. > > - scanner method: myMethod pc: startpc. > > - scanner scanFor: [:byte | (byte between: 120 and: 124) or: [scanner pc > > end]]. > > - ^scanner pc <= end! > > > Item was added: > > + ----- Method: BlockClosure>>isClean (in category 'testing') ----- > > + isClean > > + "Answer if the receiver does not close-over any variables other than > globals, and does > > + not ^-return (does not close over the home context). Clean blocks are > amenable to > > + being created at compile-time." > > + self numCopiedValues > 0 ifTrue: > > + [^false]. > > + self abstractBytecodeMessagesDo: > > + [:msg| > > + (#( pushReceiver > > + pushReceiverVariable: popIntoReceiverVariable: > storeIntoReceiverVariable: > > + methodReturnConstant: methodReturnReceiver methodReturnTop) > > + includes: msg selector) ifTrue: > > + [^false]]. > > + ^true > > + > > + "clean:" > > + "[] isClean" > > + "[:a :b| a < b] isClean" > > + "unclean" > > + "[^nil] isClean" > > + "[self class] isClean" > > + "| v | v := 0. > > + [v class] isClean"! > > > Item was added: > > + ----- Method: BlockClosure>>numTemps (in category 'accessing') ----- > > + numTemps > > + "Answer the number of temporaries for the receiver; this includes > > + the number of arguments and the number of copied values." > > + | blockCreationBytecodeSize | > > + ^self numCopiedValues > > + + self numArgs > > + + (BlockLocalTempCounter > > + tempCountForBlockAt: startpc - (blockCreationBytecodeSize := 4) > > + in: self method)! > > > Item was added: > > + ----- Method: CompiledMethod>>abstractBytecodeMessageAt: (in category > 'scanning') ----- > > + abstractBytecodeMessageAt: pc > > + "Answer the abstract bytecode message at pc in the receiver." > > + ^[(InstructionStream new method: self pc: pc) > interpretNextInstructionFor: nil] > > + on: MessageNotUnderstood > > + do: [:ex| ex message]! > > > Item was added: > > + ----- Method: CompiledMethod>>abstractBytecodeMessagesDo: (in category > 'scanning') ----- > > + abstractBytecodeMessagesDo: aBlock > > + "Evaluate aBlock with the sequence of abstract bytecodes in the > receiver" > > + self abstractBytecodeMessagesFrom: self initialPC > > + to: self endPC > > + do: aBlock > > + > > + "| msgs | > > + msgs := OrderedCollection new. > > + CompiledMethod >> #abstractBytecodeMessagesFrom:to: > abstractBytecodeMessagesDo: > > + [:msg| msgs add: msg selector]. > > + msgs"! > > > Item was added: > > + ----- Method: CompiledMethod>>abstractBytecodeMessagesFrom:to:do: (in > category 'scanning') ----- > > + abstractBytecodeMessagesFrom: startpc to: endpc do: aBlock > > + "Evaluate aBlock with the sequence of abstract bytecodes from startpc > through endpc in the receiver" > > + | scanner | > > + scanner := InstructionStream new method: self pc: startpc. > > + [scanner pc <= endpc] whileTrue: > > + [[scanner interpretNextInstructionFor: nil] > > + on: MessageNotUnderstood > > + do: [:ex| aBlock value: ex message]] > > + > > + "| m msgs | > > + msgs := OrderedCollection new. > > + (m := CompiledMethod >> #abstractBytecodeMessagesFrom:to:) > > + abstractBytecodeMessagesFrom: m initialPC > > + to: m endPC > > + do: [:msg| msgs add: msg selector]. > > + msgs"! > > > Item was added: > > + ----- Method: MethodContext>>endPC (in category 'private') ----- > > + endPC > > + ^closureOrNil > > + ifNil: [self method endPC] > > + ifNotNil: [closureOrNil endPC]! > > > Item was added: > > + ----- Method: MethodContext>>numArgs (in category 'accessing') ----- > > + numArgs > > + "Answer the number of arguments for this activation." > > + ^closureOrNil > > + ifNil: [method numArgs] > > + ifNotNil: [closureOrNil numArgs]! > > > Item was added: > > + ----- Method: MethodContext>>numTemps (in category 'accessing') ----- > > + numTemps > > + "Answer the number of temporaries for this activation; this includes > > + the number of arguments, and for blocks, the number of copied values." > > + ^closureOrNil > > + ifNil: [method numTemps] > > + ifNotNil: [closureOrNil numTemps]! > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

May 2, 2012

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: Tests-eem.151.mcz

by Mariano Martinez Peck

Yes, that's why I asked Eliot about the case of ClassVariables. mmmm sorry, that was in a private email. Don't worry, I will take care about testIsClean On Wed, May 2, 2012 at 4:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > Begin forwarded message: > > *From: *pharo-project-owner(a)lists.gforge.inria.fr > *Subject: **Fwd: [squeak-dev] The Trunk: Tests-eem.151.mcz* > *Date: *April 30, 2012 6:48:05 PM GMT+02:00 > *To: *stephane.ducasse(a)gmail.com > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > *From: *stephane ducasse <stephane.ducasse(a)gmail.com> > *Subject: **Fwd: [squeak-dev] The Trunk: Tests-eem.151.mcz* > *Date: *April 30, 2012 12:42:55 PM GMT+02:00 > *To: *Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > > > > > Begin forwarded message: > > From: commits(a)source.squeak.org > > Subject: [squeak-dev] The Trunk: Tests-eem.151.mcz > > Date: April 26, 2012 7:02:28 PM GMT+02:00 > > To: squeak-dev(a)lists.squeakfoundation.org, > packages(a)lists.squeakfoundation.org > > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > > Eliot Miranda uploaded a new version of Tests to project The Trunk: > > http://source.squeak.org/trunk/Tests-eem.151.mcz > > > ==================== Summary ==================== > > > Name: Tests-eem.151 > > Author: eem > > Time: 26 April 2012, 12:02:22.807 pm > > UUID: d1afe8a4-9721-4e74-a3f3-b2fc1057d51b > > Ancestors: Tests-ul.150 > > > Add tests for BlockClosure>isClean > > > =============== Diff against Tests-ul.150 =============== > > > Item was added: > > + ----- Method: ClosureTests>>testIsClean (in category 'testing') ----- > > + testIsClean > > + | local | > > + local := #testIsClean. > > + > > + self assert: [] isClean. "closes over nothing at all" > > + self assert: [:a :b| a < b] isClean. "accesses only arguments" > > + self assert: [:a :b| | s | s := a + b. s even] isClean. "accesses only > local variables" > > + > > + self deny: [^nil] isClean. "closes over home (^-return)" > > + self deny: [self] isClean. "closes over the receiver" > > + self deny: [collection] isClean. "closes over the receiver (to access > the inst var collection)" > > + self deny: [local] isClean. "closes over local variable of outer > context"! > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

May 2, 2012

Re: [Pharo-project] Nautilus load problem

by Sean P. DeNigris

Now I'm getting an error because GrowlMorph is not in the image. I'm on 1.4 and the config is loading version 4.3 -- View this message in context: http://forum.world.st/Nautilus-load-problem-tp4603363p4603440.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 2, 2012