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

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Lukas Renggli

> in 1.3 we introduced on:fork: to ensure that for example a system announcement is processed even if a user announcement would break for the same registry. I saw that, but didn't understand the implications. > The idea is that on Error the stack is copied and forked and the current process is resumed. The problem is that the code does not only catches Error, but Exception. This means it will also capture notifications, or any other exception that your code might be handling. > Now with DynamicVariable (and probably Notification) > the stack is cut and the resume of the notification or dynamic variable gets nuts because it does not find the information it needs. I think this is a serious problem in the new announcer framework. Announcing something should not affect the existing exception handing. I believe the problem could be fixed (for most users) if announcements would catch UnhandledError only, this exception is raised to open the debugger. > We believe that on: fork: will really improve the stability of the system (ui process, announcement). We want to be able to debug UI process without having to rinstall the current process > and all the current magic. I do not want to see the new package system on its knees just because somebody registered a broken announcement on a systemEvent (it already happened before on:fork:). Yes, but you should not interfere with intentionally raised exceptions (and this is not only for notifications). The current announcement implementation breaks many users and many legitimate use-cases. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 17, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by StÃ©phane Ducasse

Hi lukas in 1.3 we introduced on:fork: to ensure that for example a system announcement is processed even if a user announcement would break for the same registry. The idea is that on Error the stack is copied and forked and the current process is resumed. Now with DynamicVariable (and probably Notification) the stack is cut and the resume of the notification or dynamic variable gets nuts because it does not find the information it needs. We believe that on: fork: will really improve the stability of the system (ui process, announcement). We want to be able to debug UI process without having to rinstall the current process and all the current magic. I do not want to see the new package system on its knees just because somebody registered a broken announcement on a systemEvent (it already happened before on:fork:). Now Igor published a new version of on:fork: that only performs the fork and cuts the stack on exception that are not always resuming. To indicate that an exception is alwaysResuming, it is necessary to define alwaysResuming ^ true and we are done. So we did a try on Glamour Seaside by adding DynamicVariable>>alwaysResuming ^ true and we are open to suggestion because we are thinking about putting Notification >>alwaysResuming ^ true So for Seaside it would be good that you introduce such method. Stef On Jul 17, 2011, at 7:17 PM, Lukas Renggli wrote: > Not sure why the request context is suddenly gone in your code. > > It could be that this has something to do with the announcements, the > implementation changed drastically in Pharo 1.3. I had to revert the > announcements to the original implementation in OB to make them work. > > Do you properly receive the request context before doing the > announcement, just to rule out any problems in Seaside? Seaside has > not really been tested on Pharo 1.3 yet, our builds are all based on > stable Pharo 1.2.1. > > Lukas > > On 17 July 2011 18:53, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: >> Hi all, >> >> In have a simple case: in an ajax callback I trigger an announcement and in >> the callback associated with the announcement I try to render a Date object. >> When I do this I get a WARequestContextNotFound exception. >> To be more exact I have in a component this function to render the callback >> link: >> renderAnnouncementUpdate: html >> html anchor >> onClick: (html jQuery ajax script: [ :s | >> script := s. >> model announce: SGLLinkClickedAnnouncement new ]); >> with: 'Update Announcements' >> The model is initialized when I create the component in: >> initialize >> super initialize. >> model := SGLVerySimplePresentation new. >> model on: SGLLinkClickedAnnouncement do: [:ann| >> self onClick: ann]. >> When the announcement is called it will trigger the onclick: method which >> will do the rendering: >> onClick: ann >> self addScripts: script >> addScripts: s >> s << (s jQuery: #date1) >> html: [ :r | r render: Date today ]. >> s << (s jQuery: #time1) >> html: [ :r | r render: Time now ] >> However the html: method trigers an WARequestContextNotFound exception. >> I'v tried this on Pharo 1.3 (running on CogVM) with the latest version of >> Seaside. >> The application can be found in the Moose Playground project from >> http://www.squeaksource.com in the package SGL-Seaside-Problem. Atfer you >> install the package and >> start a web server you have to execute "SGLTestComponentMin >> registerAsApplication: 'SGLTestComponentMin'." to register the application. >> Am I missing something? >> Cheers, >> Andrei >> >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

July 17, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Lukas Renggli

Not sure why the request context is suddenly gone in your code. It could be that this has something to do with the announcements, the implementation changed drastically in Pharo 1.3. I had to revert the announcements to the original implementation in OB to make them work. Do you properly receive the request context before doing the announcement, just to rule out any problems in Seaside? Seaside has not really been tested on Pharo 1.3 yet, our builds are all based on stable Pharo 1.2.1. Lukas On 17 July 2011 18:53, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > Hi all, > > In have a simple case: in an ajax callback I trigger an announcement and in > the callback associated with the announcement I try to render a Date object. > When I do this I get aÂ WARequestContextNotFound exception. > To be more exact I have in a component this function to render the callback > link: > renderAnnouncementUpdate: html > Â html anchor > Â Â onClick: (html jQuery ajax script: [ :s | > script := s. > model announce: SGLLinkClickedAnnouncement new ]); > Â Â Â with: 'Update Announcements' > The model is initialized when I create the component in: > initialize > super initialize. > model := SGLVerySimplePresentation new. > model on: SGLLinkClickedAnnouncement do: [:ann| > self onClick: ann]. > When the announcement is called it will trigger the onclick: method which > will do the rendering: > onClick: ann > self addScripts: script > addScripts: s > s << (s jQuery: #date1) > Â Â Â Â Â Â Â html: [ :r | r render: Date today ]. > Â Â Â s << (s jQuery: #time1) > Â Â Â Â Â Â Â html: [ :r | r render: Time now ] > However the html: method trigers anÂ WARequestContextNotFound exception. > I'v tried this on Pharo 1.3 (running on CogVM) with the latest version of > Seaside. > The application can be found in the Moose Playground project from > http://www.squeaksource.com in the package SGL-Seaside-Problem. Atfer you > install the package and > start a web server you have to execute "SGLTestComponentMin > registerAsApplication: 'SGLTestComponentMin'." to register the application. > Am I missing something? > Cheers, > Andrei > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Lukas Renggli www.lukas-renggli.ch

July 17, 2011

[Pharo-project] Problem with announcements in Seaside when using Pharo 1.3

by Andrei Vasile Chis

Hi all, In have a simple case: in an ajax callback I trigger an announcement and in the callback associated with the announcement I try to render a Date object. When I do this I get a WARequestContextNotFound exception. To be more exact I have in a component this function to render the callback link: renderAnnouncementUpdate: html html anchor onClick: (html jQuery ajax script: [ :s | script := s. model announce: SGLLinkClickedAnnouncement new ]); with: 'Update Announcements' The model is initialized when I create the component in: initialize super initialize. model := SGLVerySimplePresentation new. model on: SGLLinkClickedAnnouncement do: [:ann| self onClick: ann]. When the announcement is called it will trigger the onclick: method which will do the rendering: onClick: ann self addScripts: script addScripts: s s << (s jQuery: #date1) html: [ :r | r render: Date today ]. s << (s jQuery: #time1) html: [ :r | r render: Time now ] However the html: method trigers an WARequestContextNotFound exception. I'v tried this on Pharo 1.3 (running on CogVM) with the latest version of Seaside. The application can be found in the Moose Playground project from http://www.squeaksource.com in the package SGL-Seaside-Problem. Atfer you install the package and start a web server you have to execute "SGLTestComponentMin registerAsApplication: 'SGLTestComponentMin'." to register the application. Am I missing something? Cheers, Andrei

July 17, 2011

Re: [Pharo-project] AnimatedImageMorph

by StÃ©phane Ducasse

sure do it. Stef On Jul 17, 2011, at 11:28 AM, Hilaire Fernandes wrote: > Is this class in dedicated package? I did not find it in PharoNonCore. > If so I will revive it and put it there. > > Hilaire > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

July 17, 2011

Re: [Pharo-project] [update 1.4] #14043

by StÃ©phane Ducasse

no just in ring. I'm trying to fix it but I will sync with veronica tomorrow. On Jul 17, 2011, at 10:29 AM, Pavel Krivanek wrote: > Hi Stef, > > do you mean one failing test in Ring or in whole image? Because for my > reloaded Core there's one Undeclared (so testUndeclared) fails because > of method doTestDebuggerTempAccessWith:with:. Unfortuatelly the CI > server is still not accessible. > > -- Pavel > > > On Sat, Jul 16, 2011 at 11:05 PM, stephane ducasse > <stephane.ducasse(a)free.fr> wrote: >> 14043 >> ----- >> >> - Adding ring container objects and fixing missing isRingObject. >> all tests green except one. >> >> one little step at a time... >> >> Stef >> >> >

July 17, 2011

Re: [Pharo-project] image freezes when setting time "back"

by StÃ©phane Ducasse

>>> >>> >>>> Hi >>>> >>>> I have had the following experience. I'm running Pharo 1.3 on a Linux >>>> box where the time is set on start up using ntp. The hardware clock is >>>> set to the local time (because I'm dual booting). When there is no >>>> network connection during booting the system the clock is two hours >>>> "ahead" until I get network connection and set the time using ntp. When >>>> a Pharo image is running during this the UI freezes and doesn't react >>>> anymore. Does anybody else observe this? Is this a known limitation? >>> >>> not that we are aware of. >>> what a bug.... :) >> >> i reported it and we discussed it months ago. > > So I don't need to report a bug or anything? probably on the cog issue tracker. > > Cheers > Philippe > >

July 17, 2011

[Pharo-project] AnimatedImageMorph

by Hilaire Fernandes

Is this class in dedicated package? I did not find it in PharoNonCore. If so I will revive it and put it there. Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

July 17, 2011

Re: [Pharo-project] [update 1.4] #14043

by Pavel Krivanek

Hi Stef, do you mean one failing test in Ring or in whole image? Because for my reloaded Core there's one Undeclared (so testUndeclared) fails because of method doTestDebuggerTempAccessWith:with:. Unfortuatelly the CI server is still not accessible. -- Pavel On Sat, Jul 16, 2011 at 11:05 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > 14043 > ----- > > - Adding ring container objects and fixing missing isRingObject. > Â Â Â Â all tests green except one. > > one little step at a time... > > Stef > >

July 17, 2011

Re: [Pharo-project] image freezes when setting time "back"

by Philippe Marschall

On 16.07.2011 23:28, Igor Stasenko wrote: > On 16 July 2011 23:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Jul 16, 2011, at 8:07 PM, Philippe Marschall wrote: >> >>> Hi >>> >>> I have had the following experience. I'm running Pharo 1.3 on a Linux >>> box where the time is set on start up using ntp. The hardware clock is >>> set to the local time (because I'm dual booting). When there is no >>> network connection during booting the system the clock is two hours >>> "ahead" until I get network connection and set the time using ntp. When >>> a Pharo image is running during this the UI freezes and doesn't react >>> anymore. Does anybody else observe this? Is this a known limitation? >> >> not that we are aware of. >> what a bug.... :) > > i reported it and we discussed it months ago. So I don't need to report a bug or anything? Cheers Philippe

July 17, 2011