- Pharo-dev - lists.pharo.org

[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

[Pharo-project] Prune stack serialization
by Martin Dias Dec. 2, 2011

Dec. 2, 2011

Hi folks In Fuel, we serialize a block closure with its state, including its outerContext. This enables to serialize a sorted collection with its sortBlock: | bytes result | bytes := FLSerializer serializeToByteArray: (SortedCollection sortBlock: [:a :b | a > b ]). result := FLMaterializer materializeFromByteArray: bytes. result addAll: #(1 2 3); yourself. ---> a SortedCollection(3 2 1) Here the problem: the byte array is huge! (800kb) because we are serializing unneeded context for the sort block. We wonder how to prune it and save time and space. Thanks in advance MartÃn

4 7

[Pharo-project] [TODO 1.3] Issues tagged 1.3
by Marcus Denker Dec. 2, 2011

Dec. 2, 2011

http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 ... the interesting thing is that there are 3 issues that have *solutions*, yet nobody looked at them since the last time I sent this email... I wonder how important actually is it to fix bugs? -- Marcus Denker -- http://marcusdenker.de

1 0