- Pharo-dev - lists.pharo.org

[Pharo-project] TestNewParagraphFix
by Sean P. DeNigris Dec. 3, 2011

Dec. 3, 2011

NewParagraph is deprecated in 1.4. TestNewParagraphFix doesn't actually mention NewParagraph directly. The class comment says "This class tests the same things as its superclass, but for NewParagraph which is used in the Morphic environment." but its superclass is TestCase. Is TestNewParagraphFix still relevant? What was the original motivation i.e. why is it called XxxFix? Sean -- View this message in context: http://forum.world.st/TestNewParagraphFix-tp4147219p4147219.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 1

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization
by Mariano Martinez Peck Dec. 3, 2011

Dec. 3, 2011

Thank you very much Eliot and Juan for this nice discussion. I have just commit this new functionality and it seems to work fine. I ended up using Eliot's #abstractBytecodes since the one from Juan didn't work out of the box in Pharo. On Fri, Dec 2, 2011 at 10:38 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Juan, > > On Fri, Dec 2, 2011 at 11:59 AM, Juan Vuletich <juan(a)jvuletich.org> wrote: > >> Mariano Martinez Peck wrote: >> >>> >>> >>> On Fri, Dec 2, 2011 at 9:46 PM, Eliot Miranda <eliot.miranda(a)gmail.com<mailto: >>> eliot.miranda@gmail.**com <eliot.miranda(a)gmail.com>>> wrote: >>> >>> >>> >>> On Fri, Dec 2, 2011 at 12:40 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>**> wrote: >>> >>> >>> >>> On Fri, Dec 2, 2011 at 8:30 PM, Juan Vuletich >>> <juan(a)jvuletich.org <mailto:juan@jvuletich.org>> wrote: >>> >>> Eliot Miranda wrote: >>> >>> >>> >>> On Fri, Dec 2, 2011 at 10:55 AM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com> >>> <mailto:marianopeck@gmail.com >>> >>> <mailto:marianopeck@gmail.com>**>> wrote: >>> >>> Thanks both. I am right to assume that if the block >>> refers to temp >>> vars, parameters, or whatever in another scope, >>> then such solution >>> won't work. I mean, if I have this example for example: >>> >>> | bytes result blah | >>> blah := 42. >>> bytes := FLSerializer serializeToByteArray: >>> (SortedCollection >>> sortBlock: [:a :b | (a + blah) > b ]). >>> >>> Then the 'blah' is in a different context. So the >>> mentioned >>> solution works for "clean" closures, which are >>> "self contained". >>> In the other cases (such as this example), we >>> should serialize the >>> whole stack. Is this correct? >>> >>> >>> No. The closure implementation arranges that any and >>> all temporary variables accessed by the closure are >>> directly accessible from the closure without accessing >>> the outer contexts. >>> ... >>> >>> >>> WRT clean closures, check what I did in Cuis to serialize >>> SortedCollections. See implementors and senders of #isClean. >>> >>> >>> Nice. Thanks Juan. I was checking your code, and that's >>> exactly why I asked Eliot. In your method you say: >>> >>> isClean >>> "A clean closure is one that doesn't really need the home >>> context because: >>> - It doesn't send messages to self or super >>> - It doesn't access any instance variable >>> - It doesn't access any outer temp >>> - It doesn't do ^ return" >>> ..... >>> >>> So... my question is, WHAT do I need to serialize if I want to >>> be able to serialize also "non clean". >>> >>> >>> IMO, dy default, everything reachable from the closure, including >>> the outerContext chain and their senders. But that's only a >>> default. What makes sense in any given context is up to the >>> application, e.g. see Seaside. One size won't fit all. You >>> should handle the common cases (e.g. clean blocks and everything >>> else) and leave it up to the user to figure out what they need to >>> do in complex situations, making sure you provide them with the >>> hooks they'll need, such as the ability to substitute objects when >>> serializing etc, and perhaps some useful examples. >>> >>> >>> +1 Then we will do the following: we will check whether the closure is >>> clean. If it is, then we serialize just the closure plus its outerContext >>> but only with receiver and method. If it is not clean, then we serialize >>> the whole stack. That's all by default. If then someone needs something >>> different, then to use the hooks :) >>> So the final question is whether what Juan is using in Cuis is up to >>> date. If it is, then I have all I need :) >>> Thank you guys. >>> >> >> I can say that it does indeed work. But I'd be really grateful if Eliot >> took a good look at that code! >> > > There is a much better way, using > InstructionStream>>interpreetNextInstructionFor: which abstracts away from > the bytecode encoding and allows one to simply use messages. e.g. look at > > BlockClosure methods for private > abstractBytecodes > "Answer an OrderedCollection of the abstract bytecodes sent in the > receiver." > | scanner blockCreationMessage end abstractBytecodes | > scanner := InstructionStream new. > "find the creation message to find the extent of the block." > scanner method: self method pc: self method initialPC. > [scanner pc < startpc] whileTrue: > [[scanner interpretNextInstructionFor: nil] > on: MessageNotUnderstood > do: [:ex| blockCreationMessage := ex message]]. > end := blockCreationMessage arguments last + startpc - 1. > "now collect all the bytecode messages in the block." > abstractBytecodes := OrderedCollection new. > scanner method: self method pc: startpc. > [scanner pc < end] whileTrue: > [[scanner interpretNextInstructionFor: nil] > on: MessageNotUnderstood > do: [:ex| abstractBytecodes add: ex message selector]]. > ^abstractBytecodes > > and (SortedCollection sortBlock: [:a :b| a compare: b caseSensitive: > false]) sortBlock abstractBytecodes evaluates to > > an OrderedCollection(#pushTemporaryVariable: #pushTemporaryVariable: > #pushConstant: #send:super:numArgs:) > > So a check for clean blocks would check for a block's abstractBytecodes > not including some particular set of banned messages (which I *think* is > pushReceiver pushReceiverVariable: popIntoReceiverVariable: > storeIntoReceiverVariable: methodReturnConstant: methodReturnReceiver > methodReturnTop). > > e.g. > > isClean > ^(self abstractBytecodes intersection: #(pushReceiver > pushReceiverVariable: popIntoReceiverVariable: storeIntoReceiverVariable: > methodReturnConstant: methodReturnReceiver methodReturnTop)) isEmpty > > >> Cheers, >> Juan Vuletich >> >> >>> >>> >>> I mean, for each item on that list, what do I need apart from >>> the closure instance and the receiver and method from the >>> outerContext ? the whole stack of contexts ? >>> >>> >>> Thanks a lot in advance! >>> >>> >>> >>> -- Mariano >>> http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>> >>> >>> >>> >>> >>> >>> >>> -- best, >>> Eliot >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >>> ------------------------------**------------------------------** >>> ------------ >>> >>> >>> >>> ------------------------------**------------------------------** >>> ------------ >>> >>> No virus found in this message. >>> Checked by AVG - www.avg.com <http://www.avg.com> >>> Version: 10.0.1411 / Virus Database: 2102/4052 - Release Date: 12/02/11 >>> >>> >> >> > > > -- > best, > Eliot > > > > > -- Mariano http://marianopeck.wordpress.com

1 0

[Pharo-project] SubscriptOutOfBounds while Debugging
by Sean P. DeNigris Dec. 2, 2011

Dec. 2, 2011

In Pharo1.4a Latest update: #14238, I keep getting the error while stepping through code. Also, the tools (Browser, Implementors, etc.) take *forever* to appear. Is anyone else experiencing either? Sean -- View this message in context: http://forum.world.st/SubscriptOutOfBounds-while-Debugging-tp4148106p414810… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 3

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization
by Mariano Martinez Peck Dec. 2, 2011

Dec. 2, 2011

> WRT clean closures, check what I did in Cuis to serialize >> SortedCollections. See implementors and senders of #isClean. >> >> >> Nice. Thanks Juan. I was checking your code, and that's exactly why I >> asked Eliot. In your method you say: >> >> isClean >> "A clean closure is one that doesn't really need the home context >> because: >> - It doesn't send messages to self or super >> - It doesn't access any instance variable >> - It doesn't access any outer temp >> - It doesn't do ^ return" >> ..... >> >> So... my question is, WHAT do I need to serialize if I want to be able to >> serialize also "non clean". I mean, for each item on that list, what do I >> need apart from the closure instance and the receiver and method from the >> outerContext ? the whole stack of contexts ? >> >> > I think it is needed to know why you need to serialize a non-clean > closure. If it is just to be able to evaluate it, well, some people may just need that, but there are cases where I need it completely. I mean, I need to serialize the whole possible graph of objects. This is an example for what I am doing in my PhD. We are also experiment with remote messages and things like that and sometimes we pass a whole stack. In that case I thin it also make sense. But again, these are particular cases. I agree that most of the times the closure will be "clean" > maybe you don't need the stack at all. My trick could be augmented by > serializing any referenced objects, but not the stack. > > Yes, maybe I was not clear. When I refer to "stack" I refer all instances of ContextPart (well, subclasses) and all the objects reachable from there. > Cheers, > Juan Vuletich > > > >> Thanks a lot in advance! >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> > > > -- Mariano http://marianopeck.wordpress.com

1 0

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization
by Mariano Martinez Peck Dec. 2, 2011

Dec. 2, 2011

On Fri, Dec 2, 2011 at 8:30 PM, Juan Vuletich <juan(a)jvuletich.org> wrote: > Eliot Miranda wrote: > >> >> >> On Fri, Dec 2, 2011 at 10:55 AM, Mariano Martinez Peck < >> marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>**> wrote: >> >> Thanks both. I am right to assume that if the block refers to temp >> vars, parameters, or whatever in another scope, then such solution >> won't work. I mean, if I have this example for example: >> >> | bytes result blah | >> blah := 42. >> bytes := FLSerializer serializeToByteArray: (SortedCollection >> sortBlock: [:a :b | (a + blah) > b ]). >> >> Then the 'blah' is in a different context. So the mentioned >> solution works for "clean" closures, which are "self contained". >> In the other cases (such as this example), we should serialize the >> whole stack. Is this correct? >> >> >> No. The closure implementation arranges that any and all temporary >> variables accessed by the closure are directly accessible from the closure >> without accessing the outer contexts. >> ... >> > > WRT clean closures, check what I did in Cuis to serialize > SortedCollections. See implementors and senders of #isClean. > > Nice. Thanks Juan. I was checking your code, and that's exactly why I asked Eliot. In your method you say: isClean "A clean closure is one that doesn't really need the home context because: - It doesn't send messages to self or super - It doesn't access any instance variable - It doesn't access any outer temp - It doesn't do ^ return" ..... So... my question is, WHAT do I need to serialize if I want to be able to serialize also "non clean". I mean, for each item on that list, what do I need apart from the closure instance and the receiver and method from the outerContext ? the whole stack of contexts ? Thanks a lot in advance! -- Mariano http://marianopeck.wordpress.com

1 1

[Pharo-project] VM page in pharo book is outdated
by Esteban Lorenzano Dec. 2, 2011

Dec. 2, 2011

Hi, Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information? Cheers, Esteban pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book? I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. pppd: yeah... today is my "stupid questions" day... :P

8 14

[Pharo-project] latest VM sources
by Pavel Krivanek Dec. 2, 2011

Dec. 2, 2011

Hi, a guy from Red Hat owes me a favor so he promised me to create official Fedora packages for latest Pharo/Squeak related projects (virtual machines and images). But he wants some information like where to find latests virtual machines source codes, what are the dependencies etc. Looking at squeakvm.org, there is only a link to 3.11-3.2135 svn repository. Can you please summarize me the links to latest StackVM and CogVM sources? I guess he will not want to fight to VMMaker - at least at start ;-). Cheers, -- Pavel

5 6

[Pharo-project] Send a notification
by Alexandre Bergel Dec. 2, 2011

Dec. 2, 2011

Hi! Together with Ivan we have been looking for an easy way to send notifications. We first thought about sending email directly from Pharo, but apparently it is not easy to send email. Anyone has experience with this? We then thought about emitting twitts, but there is a need to authorize the client. Anyone has experience? Maybe producing a RSS could do the thing? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 7

Re: [Pharo-project] [squeak-dev] Re: #ensure: What would you expect?
by Eliot Miranda Dec. 2, 2011

Dec. 2, 2011

On Fri, Dec 2, 2011 at 8:17 AM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > There is only one possibly correct answer which is raising > BlockCannotReturn, because we're trying to return while we're in the midst > of returning already, so there is no place to return to. That answer is > implemented by the attached change set. > > BTW, the code duplication between ContextPart>>restart > ContextPart>>resume:, ContextPart>>unwindTo:, and Process>>terminate > bothers me greatly. The change set only fixes one of these locations (the > one triggered by your problem statement) but having such critical code > duplicated all over the places can't be good. Any takers? > The first thing is a good set of tests. Do we have some of them? Clearly we don't have them for this case. What's the scope of the tests? The second thing I find related is that I find ContextPart>jump incomprehensible and worrying. Using simulation machinery to advance execution just seems wrong with me and yet this code is used in process termination (via runUntilErrorOrReturnFrom:) and in exception handling (via ContextPart>restart). ContextPart>jump is extremely complex and slow and buggy (I recently ( eem 11/16/2011 10:58) found and fixed a bad bug in runUntilErrorOrReturnFrom: that was causing too much peeling back of the stack in exception delivery when trying to advance a process to a particular point suitable for presenting to the user. If we could simplify this code that would be a relief to me :) The third thing that is related is that if a process is terminated from a different process, then unwinds execute in the context of the process that initiated the termination, not the process being terminated. The fourth thing that is related in my mind is that Cog supports a much faster Mutex which is in use in OpenQwaq and could be ported to Squeak and Pharo. But it needs some work on process termination, to avoid losing a signal when a process is terminated while in a critical section on the mutex. This is related because fixing this requires some work on unwind implementation. I think all of these need addressing, but they shouldn't be conflated. I'm just writing them down here so they don't get forgotten. cheers, Eliot > Cheers, > - Andreas > > > On 12/2/2011 15:18, Tobias Pape wrote: > >> Dear All, >> >> given the following class: >> >> Object subclass: #Foo >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Foo'! >> a >> self b: [^ 1].! ! >> >> b: aBlock >> >> [self c: aBlock] ensure: [^ 2]. >> >> c: aBlock >> >> aBlock value. >> ^ 3 >> >> And you would do >> >> Foo new a >> >> what would you expect? >> >> I am very curious. >> Please, first guess, then execute. >> >> Best >> -Tobias >> >> >> >> >> >> >> > > > > -- best, Eliot

2 1

[Pharo-project] Videos Pharo talks ESUG 2010/2011
by Marcus Denker Dec. 2, 2011

Dec. 2, 2011

Hi, The Pharo talks of ESUG 2011 and ESUG 2010 are online: ESUG 2011 Pharo RoadMap (missing the a bit at the end, I think) http://www.youtube.com/watch?v=cJfiNQ8zhIE Slides: http://www.slideshare.net/MarcusDenker/the-pharo-roadmap ESUG 2010: Pharo http://www.youtube.com/watch?v=pu-w9wX6RwQ Smalltalks 2011 Slides: http://www.slideshare.net/MarcusDenker/pharo-one-year-later Video: Not yet. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0