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

Re: [Pharo-project] changes with announcements ?

by Tudor Girba

On 28 Jun 2011, at 15:16, Marcus Denker wrote: > > On Jun 28, 2011, at 3:11 PM, Tudor Girba wrote: > >> >> On 28 Jun 2011, at 14:57, Igor Stasenko wrote: >> >>> http://code.google.com/p/pharo/issues/detail?id=4470 >>> >>> Issue 4470: on:fork: re-entering multiple times fix >>> >>> @Marcus, is it too late to add this fix to 1.3 ? >>> Its kind of critical one. >> >> This would be so cool :) > > > Ok, I am doing an update for this and the transcript. > Great. Let me know when I should update the image for the Moose builds. Doru > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- www.tudorgirba.com "When people care, great things can happen."

June 28, 2011

Re: [Pharo-project] changes with announcements ?

by Marcus Denker

On Jun 28, 2011, at 3:11 PM, Tudor Girba wrote: > > On 28 Jun 2011, at 14:57, Igor Stasenko wrote: > >> http://code.google.com/p/pharo/issues/detail?id=4470 >> >> Issue 4470: on:fork: re-entering multiple times fix >> >> @Marcus, is it too late to add this fix to 1.3 ? >> Its kind of critical one. > > This would be so cool :) Ok, I am doing an update for this and the transcript. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 28, 2011

Re: [Pharo-project] changes with announcements ?

by Henrik Johansen

On Jun 28, 2011, at 2:40 10PM, Igor Stasenko wrote: > Yes, > so the problem is when exceptions are go through handler multiple times. > This is not often case, but it could be happen. http://i220.photobucket.com/albums/dd143/itachi412/yo-dawg-errors.jpg ;) Cheers, Henry

June 28, 2011

Re: [Pharo-project] changes with announcements ?

by Tudor Girba

On 28 Jun 2011, at 14:57, Igor Stasenko wrote: > http://code.google.com/p/pharo/issues/detail?id=4470 > > Issue 4470: on:fork: re-entering multiple times fix > > @Marcus, is it too late to add this fix to 1.3 ? > Its kind of critical one. This would be so cool :) > > On 28 June 2011 14:44, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Thanks, Igor. >> >> It looks like Moose is a good tester for Pharo. Especially when it always runs on the latest version :). >> > > Indeed. It is always good to test stuff in real situation(s). > And apparently it is much easier to hot-fix the errors, since memory > is still fresh. Indeed. Continuous delivery at its very best :) Cheers, Doru > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "Don't give to get. Just give."

June 28, 2011

Re: [Pharo-project] changes with announcements ?

by Igor Stasenko

http://code.google.com/p/pharo/issues/detail?id=4470 Issue 4470: on:fork: re-entering multiple times fix @Marcus, is it too late to add this fix to 1.3 ? Its kind of critical one. On 28 June 2011 14:44, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks, Igor. > > It looks like Moose is a good tester for Pharo. Especially when it always runs on the latest version :). > Indeed. It is always good to test stuff in real situation(s). And apparently it is much easier to hot-fix the errors, since memory is still fresh. -- Best regards, Igor Stasenko AKA sig.

June 28, 2011

Re: [Pharo-project] [Jenkins] Kernel 1.4 with Gofer+Networking

by Pavel Krivanek

Please, from the script loadCore.st remove the first lines up to line 42. This patch is already integrated. -- Pavel On Tue, Jun 28, 2011 at 2:37 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> As I see we have the first successfull build of the reloaded core :-) > Very nice!!! > >> Maybe it will be better to have separate project for it and run all >> tests on it (the standard way used for the normal image may be used). >> > > Yes, that is a good idea. I will set it up (slowly). > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

June 28, 2011

Re: [Pharo-project] Please test Pharo 1.3!

by Fernando Olivero

I just fixed issue 4467: Transcript show problem. The TranscriptWindow on left click, opens a menu. Just as the previous transcript, from there you can toggle the interactive/non interactive morph, and the log to file. On non interactive/read only mode, the transcript displays a super fast non morphic transcript contents. (This is taken from CUIS 1.3). The custom made toolbar at the bottom, presents the status. Only info icons, not buttons. The transcript window presents one-line per entry, in a custom made scrollable widget (vertical scrolling working, horizontal missing for now ISSUE 4431). Let me know if something else isn't clear. Fernando On Tue, Jun 28, 2011 at 2:12 PM, Philippe Marschall <philippe.marschall(a)netcetera.ch> wrote: > On 06/28/2011 11:10 AM, Marcus Denker wrote: >> Please test Pharo 1.3! >> >> There is no magic.. what is now here: >> >> Â Â Â https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.3/ >> >> Will be the release. Issues fixed until the released are just those that will be detected and fixed. >> >> There is no magic. >> >> For those who only run released software: Version Number is 1.3. Consider this released. There will be no RC. > > A quick test with Seaside showed no problems. > > Cheers > Philippe > > >

June 28, 2011

Re: [Pharo-project] changes with announcements ?

by Tudor Girba

Thanks, Igor. It looks like Moose is a good tester for Pharo. Especially when it always runs on the latest version :). Cheers, Doru On 28 Jun 2011, at 14:40, Igor Stasenko wrote: > Yes, > so the problem is when exceptions are go through handler multiple times. > This is not often case, but it could be happen. > Apparently #on:fork: splits stack only once, > and if you throw exception again it will go into exception handler, > but no longer > will find the sender context (since stack is cut). > > So the fix is to check if it can find the context, and if not , just > pass an exception to > handler >> onDoCtx ifNil: [ ^ ex pass ] ]. > > should be: > >> onDoCtx ifNil: [ ^ handlerAction cull: ex ] ]. > > So, a process will be forked only once (upon first exception received), > and for next ones, it will simply pass exception to handler block > (since you cannot fork anymore). > > I will add this to issue tracker > > > On 28 June 2011 14:22, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: >> Igor this is the code you proposed: >> on: exception fork: handlerAction >> "Activate the receiver. In case of exception, fork a new process, which will >> handle an error. >> An original process will continue running as if receiver evaluation finished >> and answered nil, >> i.e., an expression like: >> [ self error: 'some error'] on: Error fork: [:ex | 123 ] >> will always answer nil for original process, not 123. >> The context stack , starting from context which sent this message to >> receiver and >> up to the top of the stack will be transferred to forked process, with >> handlerAction on top. >> (so when forked process resuming, it will enter the handlerAction) >> " >> ^ self on: exception do: [:ex | >> | copy onDoCtx process handler bottom thisCtx | >> onDoCtx := thisContext. >> thisCtx := onDoCtx home. >> "find the context on stack for which this method's is sender" >> [ onDoCtx sender == thisCtx] whileFalse: [ onDoCtx := onDoCtx sender. >> onDoCtx ifNil: [ ^ ex pass ] ]. >> bottom := [ Processor terminateActive ] asContext. >> onDoCtx privSender: bottom. >> handler := [ handlerAction cull: ex ] asContext. >> handler privSender: thisContext sender. >> (Process forContext: handler priority: Processor activePriority) resume. >> "cut the stack of current process" >> thisContext privSender: thisCtx. >> nil >> ] >> >> 2011/6/28 Igor Stasenko <siguctua(a)gmail.com> >>> >>> On 28 June 2011 11:43, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: >>>> Ok, thank you henrik. >>>> So I understand well that the announcement delivery handler will recast >>>> in >>>> new thread. The point I do not get (and maybe its obvious, sorry in >>>> advance), is why does it raise an error ? >>>> When I look at the debugger, it seems that at one moment in the on:fork: >>>> method we got a 'context' that is nil whereas it should not. >>>> It is quite to understand what is problem (As I do not have a lot of >>>> knowledge around that) >>>> >>> What VM you using? >>> Can you try running using other VM? >>> >>>> 2011/6/28 Henrik Johansen <henrik.s.johansen(a)veloxit.no> >>>>> >>>>> On Jun 28, 2011, at 10:23 56AM, Cyrille Delaunay wrote: >>>>> >>>>> I got another issue related to that i think. >>>>> In moose , at one moment in a announcement handling code, we are >>>>> doing: Notification signal: 'Save successful!'. >>>>> That has for consequence that the on:fork: cuts the stack and I end up >>>>> with a 'MessageNotUnderstood: receiver of "sender" is nil'. >>>>> So I don't know if the problem is that we are signaling a notification? >>>>> >>>>> Yes, if nothing inside the announcement handling code handles it, it >>>>> will >>>>> get handled by the announcement delivery handler which recasts it in >>>>> new >>>>> thread, for the reason Igor mentioned below. >>>>> It's not safe to simply pass it on for handling by the code that made >>>>> the >>>>> announcement, if you want to ensure delivery. >>>>> >>>>> if yes what should we use to notify something ? >>>>> >>>>> ... an Announcement? >>>>>> >>>>>> It was because on:fork: cuts the stack. >>>>>> If you signaling exception in your code, you should handle it before >>>>>> leaving your #actionSelector method. >>>>>> Otherwise you may put the rest recipients of announcement in danger >>>>>> and that's why there #on:fork: to prevent that. >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> Henry >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "Obvious things are difficult to teach."

June 28, 2011

Re: [Pharo-project] changes with announcements ?

by Igor Stasenko

Yes, so the problem is when exceptions are go through handler multiple times. This is not often case, but it could be happen. Apparently #on:fork: splits stack only once, and if you throw exception again it will go into exception handler, but no longer will find the sender context (since stack is cut). So the fix is to check if it can find the context, and if not , just pass an exception to handler > onDoCtx ifNil: [ ^ ex pass ] ]. should be: > onDoCtx ifNil: [ ^ handlerAction cull: ex ] ]. So, a process will be forked only once (upon first exception received), and for next ones, it will simply pass exception to handler block (since you cannot fork anymore). I will add this to issue tracker On 28 June 2011 14:22, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: > Igor this is the code you proposed: > on: exception fork: handlerAction > "Activate the receiver. In case of exception, fork a new process, which will > handle an error. > An original process will continue running as if receiver evaluation finished > and answered nil, > i.e., an expression like: > [ self error: 'some error'] on: Error fork: [:ex | Â 123 ] > will always answer nil for original process, not 123. > The context stack , starting from context which sent this message to > receiver and > up to the top of the stack will be transferred to forked process, with > handlerAction on top. > (so when forked process resuming, it will enter the handlerAction) > " > ^ self on: exception do: [:ex | > | copy onDoCtx process handler bottom thisCtx | > onDoCtx := thisContext. > thisCtx := onDoCtx home. > "find the context on stack for which this method's is sender" > [ onDoCtx sender == thisCtx] whileFalse: [ onDoCtx := onDoCtx sender. > onDoCtx ifNil: [ ^ ex pass ] ]. > bottom := [ Processor terminateActive ] asContext. > onDoCtx privSender: bottom. > handler := [ handlerAction cull: ex ] asContext. > handler privSender: thisContext sender. > (Process forContext: handler priority: Processor activePriority) resume. > "cut the stack of current process" > thisContext privSender: thisCtx. > nil > ] > > 2011/6/28 Igor Stasenko <siguctua(a)gmail.com> >> >> On 28 June 2011 11:43, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: >> > Ok, thank you henrik. >> > So I understand well that the announcement delivery handler will recast >> > in >> > new thread. The point I do not get (and maybe its obvious, sorry in >> > advance), is why does it raise an error ? >> > When I look at the debugger, it seems that at one moment in the on:fork: >> > method we got a 'context' that is nil whereas it should not. >> > It is quite to understand what is problem (As I do not have a lot of >> > knowledge around that) >> > >> What VM you using? >> Can you try running using other VM? >> >> > 2011/6/28 Henrik Johansen <henrik.s.johansen(a)veloxit.no> >> >> >> >> On Jun 28, 2011, at 10:23 56AM, Cyrille Delaunay wrote: >> >> >> >> I got another issue related to that i think. >> >> In moose , at one moment in a announcement handling code, we are >> >> Â doing:Â Notification signal: 'Save successful!'. >> >> That has for consequence that the on:fork: cuts the stack and I end up >> >> with a 'MessageNotUnderstood: receiver of "sender" is nil'. >> >> So I don't know if the problem is that we are signaling a notification? >> >> >> >> Yes, if nothing inside the announcement handling code handles it, it >> >> will >> >> get handled by the announcement delivery handler which recasts it in >> >> new >> >> thread, for the reason Igor mentioned below. >> >> It's not safe to simply pass it on for handling by the code that made >> >> the >> >> announcement, if you want to ensure delivery. >> >> >> >> if yes what should we use to notify something ? >> >> >> >> ... an Announcement? >> >>> >> >>> It was because on:fork: cuts the stack. >> >>> If you signaling exception in your code, you should handle it before >> >>> leaving your #actionSelector method. >> >>> Otherwise you may put the rest recipients of announcement in danger >> >>> and that's why there #on:fork: to prevent that. >> >>> >> >>> >> >>> -- >> >>> Best regards, >> >>> Igor Stasenko AKA sig. >> >>> >> >> >> >> >> >> >> >> Cheers, >> >> Henry >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig.

June 28, 2011

Re: [Pharo-project] [Jenkins] Kernel 1.4 with Gofer+Networking

by Marcus Denker

> > As I see we have the first successfull build of the reloaded core :-) Very nice!!! > Maybe it will be better to have separate project for it and run all > tests on it (the standard way used for the normal image may be used). > Yes, that is a good idea. I will set it up (slowly). -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 28, 2011