Announcements/Seaside continuations collision in newer cog vm's
Locked
 
|
Hi,
(yep, I'm copying tree lists because I think is a vm problem, but can be a seaside problem, or a pharo problem) (yes, it can be MY problem too... but I don't think so... ;) I'm having this really, really strange problem (because it was working before, and I do not change anything... so, maybe a change in latest changes on pharo 1.3, the version I'm using, is the cause)... This is the problem: I'm creating an application who sends an announcement, to edit something... this announcement ends in a WAComponent>>#call: message... The problem is: continuation execution fires a notification (WARenderNotification), and SubscriptionRegistry>>deliver:to: process the announcement this way: deliver: anAnnouncement to: subs subs do: [:each | [each deliver: anAnnouncement] "each is always in subs, so error will be due to each being last element. So return, nothing more to process" ifCurtailed: [self deliver: anAnnouncement to: ([subs after: each] on: NotFound do: [^self])]] ...and curtailedBlock is being executed... and that throws an error. This was working on older versions of VM, so maybe this is a recent change? this error was confirmed in my builds, and also in latest Eliot build. Also... is confirmed NOT being there in older cogs or interpreter. and btw... self deliver: anAnnouncement to: ([subs after: each] on: NotFound do: [^self]) shouldn't be self deliver: anAnnouncement to: ([Array with: (subs after: each)] on: NotFound do: [^self]) because #deliver:to: is expecting a collection, not a registry? thanks, Esteban_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Announcements/Seaside continuations collision in newer cog vm's
|
|
2011/9/8 Esteban Lorenzano <[hidden email]>:
> Hi, > (yep, I'm copying tree lists because I think is a vm problem, but can be a seaside problem, or a pharo problem) > (yes, it can be MY problem too... but I don't think so... ;) > > I'm having this really, really strange problem (because it was working before, and I do not change anything... so, maybe a change in latest changes on pharo 1.3, the version I'm using, is the cause)... The announcements in the latest Pharo 1.3 don't work with Seaside anymore. For some reason they fork them instead of running them in an exception handler. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Announcements/Seaside continuations collision in newer cog vm's
|
|
Igor and Stef can provide more details.
The reason for forking is that even if one announcement breaks, the others should still be announced. Announcements are used for the functioning of the core of the system and this means that even if you register new objects, the core mechanisms (such as package management) should continue to work. It would be great if Seaside would work with these, and now depend on another framework. Cheers, Doru On 9 Sep 2011, at 06:38, Philippe Marschall wrote: > 2011/9/8 Esteban Lorenzano <[hidden email]>: >> Hi, >> (yep, I'm copying tree lists because I think is a vm problem, but can be a seaside problem, or a pharo problem) >> (yes, it can be MY problem too... but I don't think so... ;) >> >> I'm having this really, really strange problem (because it was working before, and I do not change anything... so, maybe a change in latest changes on pharo 1.3, the version I'm using, is the cause)... > > The announcements in the latest Pharo 1.3 don't work with Seaside > anymore. For some reason they fork them instead of running them in an > exception handler. > > Cheers > Philippe > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Announcements/Seaside continuations collision in newer cog vm's
|
|
2011/9/9 Tudor Girba <[hidden email]>:
> Igor and Stef can provide more details. > > The reason for forking is that even if one announcement breaks, the others should still be announced. You don't need forking to do this. A simple exception handler would work very well and not break any code. It just doesn't make you look clever. cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Announcements/Seaside continuations collision in newer cog vm's
|
|
In reply to this post by Tudor Girba-2
Isn't the plain events mechanism forkless and essential to the core of the system already?
if you introduce that fork you break not only seaside but all artifacts of all the people that will rightly assume the current process between event and reaction is the same On Sep 9, 2011, at 7:13 AM, Tudor Girba wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Announcements/Seaside continuations collision in newer cog vm's
|
|
Henrik provided a better answer than mine:
On 9 Sep 2011, at 14:44, Henrik Sperre Johansen wrote: > Which is why it was changed, after discussion with Lukas. > It only forks UnhandledErrors now, before delivering the remaining. > As long as there is no abnormal termination, it will work just as before. > If any subscribers would abnormally terminate though, the ifCurtailed: kicks in, and (was supposed to) ensure delivers to remaining subscribers. > > If something in Seaside relies on such behaviour (like terminating current process in order for subsequent subscribers to not receive the announcement) that will be broken. > I don't think messing with announcement delivery should be considered a good control flow mechanism though. > > What Esteban encountered as an error on some VM's was a pure bug I made in the ifCurtailed: block (by using after: instead of copyAfter:), and had nothing to do with forking. > Why some VM's considered the delivery abnormally terminated, while others didn't, I have no idea though... > (The error he got only happens when the ifCurtailed block is invoked). > > Cheers, > Henry Cheers, Doru On 9 Sep 2011, at 15:20, Sebastian Sastre wrote: > Isn't the plain events mechanism forkless and essential to the core of the system already? > > if you introduce that fork you break not only seaside but all artifacts of all the people that will rightly assume the current process between event and reaction is the same > > > > On Sep 9, 2011, at 7:13 AM, Tudor Girba wrote: > >> Igor and Stef can provide more details. >> >> The reason for forking is that even if one announcement breaks, the others should still be announced. Announcements are used for the functioning of the core of the system and this means that even if you register new objects, the core mechanisms (such as package management) should continue to work. >> >> It would be great if Seaside would work with these, and now depend on another framework. >> >> Cheers, >> Doru >> >> >> On 9 Sep 2011, at 06:38, Philippe Marschall wrote: >> >>> 2011/9/8 Esteban Lorenzano <[hidden email]>: >>>> Hi, >>>> (yep, I'm copying tree lists because I think is a vm problem, but can be a seaside problem, or a pharo problem) >>>> (yes, it can be MY problem too... but I don't think so... ;) >>>> >>>> I'm having this really, really strange problem (because it was working before, and I do not change anything... so, maybe a change in latest changes on pharo 1.3, the version I'm using, is the cause)... >>> >>> The announcements in the latest Pharo 1.3 don't work with Seaside >>> anymore. For some reason they fork them instead of running them in an >>> exception handler. >>> >>> Cheers >>> Philippe >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> -- >> www.tudorgirba.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > sebastian > > o/ > > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- www.tudorgirba.com "Be rather willing to give than demanding to get." _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |