December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Send a notification

by Alexandre Bergel

Cool :-) Alexandre On 2 Dec 2011, at 16:08, Sean P. DeNigris wrote: > > Alexandre Bergel-7 wrote >> >> We first thought about sending email directly from Pharo, but apparently >> it is not easy to send email. > > I cleaned up Pharo's mail code a little. > > Issue 5051: [ENH]: Clean up Mail code > http://code.google.com/p/pharo/issues/detail?id=5051 > > Added simpified API, for example: > message := MailMessage > from: 'sender(a)domain.com' > to: { 'recipient(a)domain.com'. 'recipient2(a)domain.com' } > about: 'Very Important Subject' > asFollows: 'Hi, how are you?'. > message sendOn: 'mail.domain.com'. > > Added some tests to MailMessage > > -- > View this message in context: http://forum.world.st/Send-a-notification-tp3503711p4148595.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: #ensure: What would you expect?

by Schwab,Wilhelm K

I have *NO* idea whether this is relevant or helpful, but just in case... If memory serves, Dolphin makes a point of getting ensured blocks to run on the correct process by (perhaps conditionally) suspending and re-starting the offending Process instance. HTH. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Friday, December 02, 2011 1:56 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Re: #ensure: What would you expect? On Fri, Dec 2, 2011 at 8:17 AM, Andreas Raab <andreas.raab(a)gmx.de<mailto:andreas.raab@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

Dec. 2, 2011

Re: [Pharo-project] [GS/SS Beta] Monticello enhancing

by Mariano Martinez Peck

On Fri, Dec 2, 2011 at 4:54 PM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Dear all, > > afte Fuel being available for both Squeak and Pharo, > I experimented a little bit. > Be aware that Fuel is "partially" supported in Squeak. It was just a first try Martin and I did. The idea is to have at least the "Core" working. Previously, the Core included also all the code to be able to completely serialize classes, traits and compiled methods. Most of the times this is not used, since most users want to serialize the class/trait/method as "global", that is, we just serialize its name and then search it at materialization time. In the latest version of Fuel (1.8, which is not yet released), such behavior was moved to a separate package called FuelMetalevel. That package, does NOT work in Squeak since Class and Trait are different in Squeak than Pharo. So, you are NOT able to serialize classes/traits completely. Since that package is not supported, FuelPackageLoader is not supported either. So....just the plain/core serialization works so far in Squeak. Of course we welcome someone to push with the other packages. > > So, I put a new snapshot.fuel beside the snapshot.bin in > the mcz zips (same for patch.* in mcd). > I am surprised that it worked since (as said) full serialization of classes/methods is not working in Squeak. I thought that Monticello serialize that in that snapshot.bin but it seems I am wrong. So...what is exactly serialized in that snapshot.bin ? > > But to make it easier in the future to experiment with things, > I included a small facility to extend serializers/materializers > or similar things more easily. How is it done? > > Example: new serializer in MCZ files: > After my patch, include > > MCMczWriter class>>serializerMine > > ^ [:writer :snapshot | writer writeSnapshotAsMyFormat: snapshot] > > and > > MCMczWriter>>writeSnapshotAsMyFormat: snapshot > > self addString: (self doSomeConversion: aSnapshot) at: > 'snapshot.myformat'. > > as Extension methods in MCMczWriter, and execute > > MCMczWriter populateSerializers. > > Now, a new file member is added to every new mcz file. > > Excellent. > As an example, I have done such thing for Fuel. > Don't worry, it just uses the default behavior if > Fuel is not present in either the image or the mcz-file. > So, is it working? can I commit/load with Monticello using the Fuel instead of DataStream? Did you notice performance improvement in using Fuel rather than DataStream? I guess (well, once Levente showed something) it is a small percentage in the overall process of Monticello, so I don't expect that much improvement in the whole action of saving/commiting. Thanks > > Best, > -Tobias > > PS: for Squeak, see Inbox Monticello-topa.491, > And I also have an MCD attached that should help using the code > elsewhere. > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

[Pharo-project] Videos Pharo talks ESUG 2010/2011

by Marcus Denker

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

Dec. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization

by Mariano Martinez Peck

On Fri, Dec 2, 2011 at 8:18 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > >>> Is this clear or as clear as mud? >>> >> >> Much clear now. One last question. So far, then, I didn't find/think a >> scenario where serializing the whole stack (from a closure) make sense. >> So, if I just want to serialize a closure and be able to materialize it, >> then it is *never* necessary the whole stack, in all scenarios? or I am >> missing a case where the whole stack is needed? I am talking only about >> when serializing closures, because if I directly serialize a MethodContext, >> it may happen that I want the whole stack (like the example I showed in >> ESUG where I serialized the whole Debugger and then I continue debugging in >> another image). >> >> > For example, would this work? > > > | bytes result blah | > blah := 42. > bytes := FLSerializer serializeToByteArray: (SortedCollection sortBlock: > [:a :b | (a + blah) > b. ^ blah ]). > > of course it doesn't make sense to do a return there. I was just an example, imagine another place where there is a blockclosure I want to serialize and there is a return inside. > has the return something to do with this? > > Thanks > > > Thanks! >> >> >>> >>> >>>> >>>> Thanks! >>>> >>>> >>>> On Fri, Dec 2, 2011 at 7:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >>>> >>>>> >>>>> >>>>> On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier < >>>>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>> >>>>>> 2011/12/2 Martin Dias <tinchodias(a)gmail.com>: >>>>>> > 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 >>>>>> >>>>>> In the case of such clean block, there is no need of outer context >>>>>> during block execution. >>>>>> However I don't know if implementation makes it possible to ignore the >>>>>> context... >>>>>> That's more a question directed to Eliot ;) >>>>>> >>>>> >>>>> Arguably there is a bug in my closure implementation, which is that >>>>> both the receiver and the method are fetched from the outerContext. That's >>>>> not a bug which can be fixed without a new VM/image combination and may be >>>>> something I'll look at long-term, but is something we have to live with at >>>>> the moment. This means that you *do* have to serialize the outerContext. >>>>> But the outerContext is used only for the receiver and method. So you >>>>> don't need to full serialize the outerContext. In particular you don't >>>>> need to serialize any of the outerContext's stack contents or its sender. >>>>> This needs special handling, I guess in BlockClosure, to substitute a >>>>> suitably reduced outerContext, but it shouldn't be hard to do. e.g. >>>>> >>>>> BlockClosure methods for: '*Fuel-serialization' >>>>> outerContextForSerialization >>>>> ^MethodContext >>>>> sender: nil >>>>> receiver outerContext receiver >>>>> method: outerContext method >>>>> args: #() >>>>> >>>>> >>>>> BlockClosure methods for: '*Fuel-serialization' >>>>> outerContextForSerialization >>>>> ^MethodContext >>>>> sender: nil >>>>> receiver self receiver >>>>> method: self method >>>>> args: #() >>>>> >>>>> >>>>> >>>>>> Nicolas >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> best, >>>>> Eliot >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization

by Mariano Martinez Peck

> >> Is this clear or as clear as mud? >> > > Much clear now. One last question. So far, then, I didn't find/think a > scenario where serializing the whole stack (from a closure) make sense. > So, if I just want to serialize a closure and be able to materialize it, > then it is *never* necessary the whole stack, in all scenarios? or I am > missing a case where the whole stack is needed? I am talking only about > when serializing closures, because if I directly serialize a MethodContext, > it may happen that I want the whole stack (like the example I showed in > ESUG where I serialized the whole Debugger and then I continue debugging in > another image). > > For example, would this work? | bytes result blah | blah := 42. bytes := FLSerializer serializeToByteArray: (SortedCollection sortBlock: [:a :b | (a + blah) > b. ^ blah ]). has the return something to do with this? Thanks Thanks! > > >> >> >>> >>> Thanks! >>> >>> >>> On Fri, Dec 2, 2011 at 7:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >>> >>>> >>>> >>>> On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>>> 2011/12/2 Martin Dias <tinchodias(a)gmail.com>: >>>>> > 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 >>>>> >>>>> In the case of such clean block, there is no need of outer context >>>>> during block execution. >>>>> However I don't know if implementation makes it possible to ignore the >>>>> context... >>>>> That's more a question directed to Eliot ;) >>>>> >>>> >>>> Arguably there is a bug in my closure implementation, which is that >>>> both the receiver and the method are fetched from the outerContext. That's >>>> not a bug which can be fixed without a new VM/image combination and may be >>>> something I'll look at long-term, but is something we have to live with at >>>> the moment. This means that you *do* have to serialize the outerContext. >>>> But the outerContext is used only for the receiver and method. So you >>>> don't need to full serialize the outerContext. In particular you don't >>>> need to serialize any of the outerContext's stack contents or its sender. >>>> This needs special handling, I guess in BlockClosure, to substitute a >>>> suitably reduced outerContext, but it shouldn't be hard to do. e.g. >>>> >>>> BlockClosure methods for: '*Fuel-serialization' >>>> outerContextForSerialization >>>> ^MethodContext >>>> sender: nil >>>> receiver outerContext receiver >>>> method: outerContext method >>>> args: #() >>>> >>>> >>>> BlockClosure methods for: '*Fuel-serialization' >>>> outerContextForSerialization >>>> ^MethodContext >>>> sender: nil >>>> receiver self receiver >>>> method: self method >>>> args: #() >>>> >>>> >>>> >>>>> Nicolas >>>>> >>>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> >> >> >> -- >> best, >> Eliot >> >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization

by Mariano Martinez Peck

On Fri, Dec 2, 2011 at 8:04 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Fri, Dec 2, 2011 at 10:55 AM, Mariano Martinez Peck < > marianopeck(a)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. > Ahhhhhhh :) > You were there for my presentation Mariano :) And you understood the > issue then right ? :) > Well, yes, but I usually understand in the second or third time ;) > Remember the closure compiler *copies* any temporary variables that are > not changed after being closed over into a closure's copiedValues, and > *moves* any temporary variables that could be changed after being closed > over into indirection vectors, and these indirection vectors are copied > into the copied values of the closure. > Excellent. So everything is inside the closure. When you say "copiedValues" I guess you use the variable part of BlockClosure, is that right? > But, as I just said, the receiver and method are not copied (to save time > at closure creation) since these are in the outerContext already. These > are fetched from the outerContext when the closure is activated. > Got it. > > That's the trade-off, slower closure creation and larger closures and > duplication if a closure refers to its method and receiver directly, faster > closure creation, smaller closures, less duplication and very slightly > slower activation if closures refer to their receiver and method > indirectly. The additional trade-off is this issue; the indirect approach > entails more problems for serialization and for implementing compile-time > clean closures (since the compiler needs to create an outerContext for the > method and nil for the non-existent receiver - clean closures can't refer > to self). > > Is this clear or as clear as mud? > Much clear now. One last question. So far, then, I didn't find/think a scenario where serializing the whole stack (from a closure) make sense. So, if I just want to serialize a closure and be able to materialize it, then it is *never* necessary the whole stack, in all scenarios? or I am missing a case where the whole stack is needed? I am talking only about when serializing closures, because if I directly serialize a MethodContext, it may happen that I want the whole stack (like the example I showed in ESUG where I serialized the whole Debugger and then I continue debugging in another image). Thanks! > > >> >> Thanks! >> >> >> On Fri, Dec 2, 2011 at 7:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> >>> >>> On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>>> 2011/12/2 Martin Dias <tinchodias(a)gmail.com>: >>>> > 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 >>>> >>>> In the case of such clean block, there is no need of outer context >>>> during block execution. >>>> However I don't know if implementation makes it possible to ignore the >>>> context... >>>> That's more a question directed to Eliot ;) >>>> >>> >>> Arguably there is a bug in my closure implementation, which is that both >>> the receiver and the method are fetched from the outerContext. That's not >>> a bug which can be fixed without a new VM/image combination and may be >>> something I'll look at long-term, but is something we have to live with at >>> the moment. This means that you *do* have to serialize the outerContext. >>> But the outerContext is used only for the receiver and method. So you >>> don't need to full serialize the outerContext. In particular you don't >>> need to serialize any of the outerContext's stack contents or its sender. >>> This needs special handling, I guess in BlockClosure, to substitute a >>> suitably reduced outerContext, but it shouldn't be hard to do. e.g. >>> >>> BlockClosure methods for: '*Fuel-serialization' >>> outerContextForSerialization >>> ^MethodContext >>> sender: nil >>> receiver outerContext receiver >>> method: outerContext method >>> args: #() >>> >>> >>> BlockClosure methods for: '*Fuel-serialization' >>> outerContextForSerialization >>> ^MethodContext >>> sender: nil >>> receiver self receiver >>> method: self method >>> args: #() >>> >>> >>> >>>> Nicolas >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> > > > -- > best, > Eliot > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

Re: [Pharo-project] Send a notification

by Sean P. DeNigris

Alexandre Bergel-7 wrote > > We first thought about sending email directly from Pharo, but apparently > it is not easy to send email. I cleaned up Pharo's mail code a little. Issue 5051: [ENH]: Clean up Mail code http://code.google.com/p/pharo/issues/detail?id=5051 Added simpified API, for example: message := MailMessage from: 'sender(a)domain.com' to: { 'recipient(a)domain.com'. 'recipient2(a)domain.com' } about: 'Very Important Subject' asFollows: 'Hi, how are you?'. message sendOn: 'mail.domain.com'. Added some tests to MailMessage -- View this message in context: http://forum.world.st/Send-a-notification-tp3503711p4148595.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization

by Eliot Miranda

On Fri, Dec 2, 2011 at 10:55 AM, Mariano Martinez Peck < marianopeck(a)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. You were there for my presentation Mariano :) And you understood the issue then right ? :) Remember the closure compiler *copies* any temporary variables that are not changed after being closed over into a closure's copiedValues, and *moves* any temporary variables that could be changed after being closed over into indirection vectors, and these indirection vectors are copied into the copied values of the closure. But, as I just said, the receiver and method are not copied (to save time at closure creation) since these are in the outerContext already. These are fetched from the outerContext when the closure is activated. That's the trade-off, slower closure creation and larger closures and duplication if a closure refers to its method and receiver directly, faster closure creation, smaller closures, less duplication and very slightly slower activation if closures refer to their receiver and method indirectly. The additional trade-off is this issue; the indirect approach entails more problems for serialization and for implementing compile-time clean closures (since the compiler needs to create an outerContext for the method and nil for the non-existent receiver - clean closures can't refer to self). Is this clear or as clear as mud? > > Thanks! > > > On Fri, Dec 2, 2011 at 7:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> 2011/12/2 Martin Dias <tinchodias(a)gmail.com>: >>> > 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 >>> >>> In the case of such clean block, there is no need of outer context >>> during block execution. >>> However I don't know if implementation makes it possible to ignore the >>> context... >>> That's more a question directed to Eliot ;) >>> >> >> Arguably there is a bug in my closure implementation, which is that both >> the receiver and the method are fetched from the outerContext. That's not >> a bug which can be fixed without a new VM/image combination and may be >> something I'll look at long-term, but is something we have to live with at >> the moment. This means that you *do* have to serialize the outerContext. >> But the outerContext is used only for the receiver and method. So you >> don't need to full serialize the outerContext. In particular you don't >> need to serialize any of the outerContext's stack contents or its sender. >> This needs special handling, I guess in BlockClosure, to substitute a >> suitably reduced outerContext, but it shouldn't be hard to do. e.g. >> >> BlockClosure methods for: '*Fuel-serialization' >> outerContextForSerialization >> ^MethodContext >> sender: nil >> receiver outerContext receiver >> method: outerContext method >> args: #() >> >> >> BlockClosure methods for: '*Fuel-serialization' >> outerContextForSerialization >> ^MethodContext >> sender: nil >> receiver self receiver >> method: self method >> args: #() >> >> >> >>> Nicolas >>> >>> >> >> >> -- >> best, >> Eliot >> >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- best, Eliot

Dec. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: #ensure: What would you expect?

by Eliot Miranda

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

Dec. 2, 2011