- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Slides of my Lecture this morning..

by phil＠highoctane.be

Yes, nice. On Tuesday, October 29, 2013, Tudor Girba wrote: > Great material. > > Doru > > > On Tue, Oct 29, 2013 at 2:01 PM, Martin Dias <tinchodias(a)gmail.com<javascript:_e({}, 'cvml', 'tinchodias(a)gmail.com');> > > wrote: > >> And even the class Slot could be compact (it's not right now) >> >> >> On Tue, Oct 29, 2013 at 1:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu<javascript:_e({}, 'cvml', 'sven(a)stfx.eu');> >> > wrote: >> >>> >>> On 29 Oct 2013, at 13:40, Marcus Denker <marcus.denker(a)inria.fr<javascript:_e({}, 'cvml', 'marcus.denker(a)inria.fr');>> >>> wrote: >>> >>> > >>> > On 29 Oct 2013, at 13:38, Sven Van Caekenberghe <sven(a)stfx.eu<javascript:_e({}, 'cvml', 'sven(a)stfx.eu');>> >>> wrote: >>> > >>> >> Thanks for sharing, Marcus, I really appreciate this. >>> >> >>> >> It is cool to know that we have already slots under the hood, and >>> that much more application are on their way. >>> >> >>> > >>> > Slot allInstances size >>> > >>> > ==> 7128 >>> > >>> > :-) >>> > >>> > Marcus >>> >>> And nobody ever noticed ! >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Oct. 29, 2013

Pharo Sprint in Buenos Aires Nov 7th

by Gisela Decuzzi

Hello, we are organizing a Pharo Sprint in Bs As: When: November 7th, starting at 10:00 am Where: 10 Pines (Av Leandro N. Alem 693 5Â°B)

Oct. 29, 2013

Re: [Pharo-dev] [Pharo-users] Slides of my Lecture this morning..

by Tudor Girba

Great material. Doru On Tue, Oct 29, 2013 at 2:01 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > And even the class Slot could be compact (it's not right now) > > > On Tue, Oct 29, 2013 at 1:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> >> On 29 Oct 2013, at 13:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> > >> > On 29 Oct 2013, at 13:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> >> Thanks for sharing, Marcus, I really appreciate this. >> >> >> >> It is cool to know that we have already slots under the hood, and that >> much more application are on their way. >> >> >> > >> > Slot allInstances size >> > >> > ==> 7128 >> > >> > :-) >> > >> > Marcus >> >> And nobody ever noticed ! >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 29, 2013

Re: [Pharo-dev] [Pharo-users] Slides of my Lecture this morning..

by Martin Dias

And even the class Slot could be compact (it's not right now) On Tue, Oct 29, 2013 at 1:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 29 Oct 2013, at 13:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > On 29 Oct 2013, at 13:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> Thanks for sharing, Marcus, I really appreciate this. > >> > >> It is cool to know that we have already slots under the hood, and that > much more application are on their way. > >> > > > > Slot allInstances size > > > > ==> 7128 > > > > :-) > > > > Marcus > > And nobody ever noticed ! >

Oct. 29, 2013

Re: [Pharo-dev] Unwind error during termination

by Camille Teruel

On 29 oct. 2013, at 13:22, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > (Igor speaking with Clement) Another, tangent. > > I feel extremely wrong with given piece of code (however it works): > > [ ^ 2 ] ensure: [ ^ 5 ] > > my point, that you cannot return from same context twice, and what happens here is really weird. > > Or even more weird: > > [ ^ 2 ] ifCurtailed: [ ^ 5 ] Debug it -> Into -> Over -> Over (does nothing) -> Over (again) ==> Freeze :) > > or imagine more abstract case: > > someBlock ifCurtailed: [ ^ 5 ] > > The someBlock can belong to other context (like the caller context), > and if evaluating it leads to non-local return, it must continue execution from the sender context of its home context. > But alas, our ifCurtailed block thinks otherwise and intercepts that.. and does own non-local return to possibly alredy > unwinded portion of stack.. > > > I feel there's something extremely wrong with that :) > > We changed the #resume:through: method > to catch that: > > unwindBlock ifCurtailed: [ self error: 'cannot resume execution due to curtailing' ] > instead of: unwindBlock value > > i am, however don't really know what is the least surprising behavior for such situation. > > > > 2013/10/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > If I remember correctly andreas wrote the tests. > I always like them. > > Stef > > >> The author of the test is Andreas Raab, but I'm not sure who found it (excavating mailing list is hard work) >> >> >> 2013/10/25 Igor Stasenko <siguctua(a)gmail.com> >> >> >> >> On 25 October 2013 00:26, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Hard to debug this kind of code :( >> This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar. >> >> Still, I do not see how you get the errorSubscriptBound:... >> In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... >> I never saw this, but if Eliot says so... >> >> >> >> ExceptionTests>>testHandlerFromAction >> "A test ensuring that nested exceptions work as expected." >> >> | result | >> result := [ >> [ >> [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] >> ] on: Error do: [ :ex | 3 / 0 ] >> ] on: ZeroDivide do: [ :ex | 'outer' ]. >> self assert: 'outer' equals: result description: 'Incorrect handler'. >> >> good find :) >> >> https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem >> >> >> >> 2013/10/24 Igor Stasenko <siguctua(a)gmail.com> >> >> ok, it seems i found how to reproduce the situation with following: >> >> [ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ] >> >> you will get halt, and if you close the debugger , it will throw unwind error. >> (while instead it should throw DNU) >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Oct. 29, 2013

Re: [Pharo-dev] [Pharo-users] Slides of my Lecture this morning..

by Sven Van Caekenberghe

On 29 Oct 2013, at 13:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 29 Oct 2013, at 13:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Thanks for sharing, Marcus, I really appreciate this. >> >> It is cool to know that we have already slots under the hood, and that much more application are on their way. >> > > Slot allInstances size > > ==> 7128 > > :-) > > Marcus And nobody ever noticed !

Oct. 29, 2013

Re: [Pharo-dev] [Pharo-users] Slides of my Lecture this morning..

by Marcus Denker

On 29 Oct 2013, at 13:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Thanks for sharing, Marcus, I really appreciate this. > > It is cool to know that we have already slots under the hood, and that much more application are on their way. > Slot allInstances size ==> 7128 :-) Marcus

Oct. 29, 2013

Re: [Pharo-dev] [Pharo-users] Slides of my Lecture this morning..

by Sven Van Caekenberghe

Thanks for sharing, Marcus, I really appreciate this. It is cool to know that we have already slots under the hood, and that much more application are on their way. Sven On 29 Oct 2013, at 13:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > I am just visiting Jordi Delgado in Barcelona and I gave a lecture in his course this morning. > âAdvanced Reflection in Pharoâ, this is meant to be a lecture after an introduction to standard > Smalltalk reflection. > > SlideShare > http://www.slideshare.net/MarcusDenker/lecture-27685035 > > PDF > http://marcusdenker.de/talks/13BarcelonaLecture/ > > > Marcus

Oct. 29, 2013

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by Mariano Martinez Peck

On Tue, Oct 29, 2013 at 6:53 AM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Guys, > > Fuel itâs perfect, it wasâof courseâmy fault. > > When I considered everything and I moved away from Ring definition which > caused me lot of troubles I forgot to consider MethodContext objects, which > in turn points to CompiledMethod which point to classes. Thus Fuel > serialize all this crap (including classes) and in the materialization > phase I got clearly a FLClassNotFound. > > Even in this case, Fuel should have not serialized classes. Instead, if a class was found in the graph, Fuel should have serialized a "mock" object that just contains the class name and a few other things, but not the whole class. Then at materialization it should search that class name in the SmalltalkDictionary and get that. So...it could still happen that the class name you stored during serialization is NOT present in materialization. But Fuel should not have serialized the class itself but rather this mock object. Cheers, > Thanks a lot for the support, > Roby > > On Oct 29, 2013, at 8:03 AM, roberto.minelli(a)usi.ch wrote: > > > Iâll look at the docâ¦ However if some of you is online in Skype we can > have a chatâ¦ > > > > Cheers and thanks for help, > > Roby > > > > On Oct 28, 2013, at 11:45 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > > >> Indeed, I think I agree with Max. You can also use the substitute > feature and replace the instVars you don't want with nil or something...See > the doc link Martin sent. > >> > >> > >> On Mon, Oct 28, 2013 at 7:00 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> In my opinion the #fuelAccept: for the meta description object should > be overridden and there the behaviour for problematic references should be > defined. > >> > >> Roberto, what references does your meta object hold on to? > >> > >> Max > >> > >> > >> On 28.10.2013, at 22:16, Martin Dias <tinchodias(a)gmail.com> wrote: > >> > >>> > >>> > >>> > >>> On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli(a)usi.ch < > roberto.minelli(a)usi.ch> wrote: > >>> The idea is that I have an object (a session) which has meta data > (time, duration, author) and some other object inside. > >>> > >>> I want that Fuel serializes just that object and not pointes to other > object, globals and what not. > >>> > >>> This causes me a lot of troubles, moreover it makes the fuel file > bigger than the optimumâ¦ > >>> > >>> Still there is something that I don't understand in your problem. If > you just prune the graph, what your objects represent (conceptually) can be > lost. Did you pick one of your problematic "session objects" are explored > it until find how the unwanted block closures are referenced? I mean, fuel > doesn't invent the unwanted closures magically, you are saying to fuel to > serialize the graph with the unwanted objects already there. > >>> > >>> > >>> Cheers, > >>> R > >>> > >>> > >>> On Oct 28, 2013, at 4:57 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > >>> > >>>> > >>>> > >>>> > >>>> On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli(a)usi.ch < > roberto.minelli(a)usi.ch> wrote: > >>>> Thanks, > >>>> > >>>> On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias(a)gmail.com> > wrote: > >>>> > >>>>> Currently there is no such option. > >>>> > >>>> Maybe it is something which is needed, what do you think? > >>>> > >>>> The idea is that, if you serialize: > >>>> > >>>> a -> b -> c > >>>> > >>>> fuel actually would encode: > >>>> > >>>> a -> b -> nil > >>>> > >>>> > >>>> that? > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > > > > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 29, 2013

Re: [Pharo-dev] Unwind error during termination

by ClÃ©ment Bera

(Igor speaking with Clement) Another, tangent. I feel extremely wrong with given piece of code (however it works): [ ^ 2 ] ensure: [ ^ 5 ] my point, that you cannot return from same context twice, and what happens here is really weird. Or even more weird: [ ^ 2 ] ifCurtailed: [ ^ 5 ] or imagine more abstract case: someBlock ifCurtailed: [ ^ 5 ] The someBlock can belong to other context (like the caller context), and if evaluating it leads to non-local return, it must continue execution from the sender context of its home context. But alas, our ifCurtailed block thinks otherwise and intercepts that.. and does own non-local return to possibly alredy unwinded portion of stack.. I feel there's something extremely wrong with that :) We changed the #resume:through: method to catch that: unwindBlock ifCurtailed: [ self error: 'cannot resume execution due to curtailing' ] instead of: unwindBlock value i am, however don't really know what is the least surprising behavior for such situation. 2013/10/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > If I remember correctly andreas wrote the tests. > I always like them. > > Stef > > > The author of the test is Andreas Raab, but I'm not sure who found it > (excavating mailing list is hard work) > > > 2013/10/25 Igor Stasenko <siguctua(a)gmail.com> > >> >> >> >> On 25 October 2013 00:26, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> Hard to debug this kind of code :( >>> This is reproducible on Squeak wiht on:do:, so on:fork: bizareness >>> apart, this is another flaw in exception handling, along with wrong handler >>> for nested exception (testHandlerFromAction below), unless it's an avatar. >>> >>> Still, I do not see how you get the errorSubscriptBound:... >>> In Squeak that would mean that you sent #handleSignal: to a not >>> isHandlerContext ContextPart... >>> I never saw this, but if Eliot says so... >>> >>> >>> >>> ExceptionTests>>testHandlerFromAction >>> "A test ensuring that nested exceptions work as expected." >>> >>> | result | >>> result := [ >>> [ >>> [self error: 'trigger error'] on: ZeroDivide do: [ :ex | >>> 'inner' ] >>> ] on: Error do: [ :ex | 3 / 0 ] >>> ] on: ZeroDivide do: [ :ex | 'outer' ]. >>> self assert: 'outer' equals: result description: 'Incorrect handler'. >>> >>> good find :) >> >> https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem >> >> >>> >>> >>> 2013/10/24 Igor Stasenko <siguctua(a)gmail.com> >>> >>>> >>>> ok, it seems i found how to reproduce the situation with following: >>>> >>>> [ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ] >>>> >>>> you will get halt, and if you close the debugger , it will throw unwind >>>> error. >>>> (while instead it should throw DNU) >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > >

Oct. 29, 2013