[Pharo-project] Announcements/Seaside continuations collision in newer cog vm's
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 interpret 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
On 08.09.2011 21:19, Esteban Lorenzano wrote:
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 interpret
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 subs is a collection. after: returns a collection of the elements after each, or raises a NotFound error if the subscriber was the last one. If the one which was curtailed was the last one (and an error is raised), we don't need to handle delivering anything else, and thus simply return self.
At least that's how it's supposed to work... What kind of error is thrown? Cheers, Henry
On 08.09.2011 21:30, Henrik Sperre Johansen wrote:
On 08.09.2011 21:19, Esteban Lorenzano wrote:
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 interpret
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 subs is a collection. after: returns a collection of the elements after each, or raises a NotFound error if the subscriber was the last one. If the one which was curtailed was the last one (and an error is raised), we don't need to handle delivering anything else, and thus simply return self.
At least that's how it's supposed to work...
What kind of error is thrown?
Cheers, Henry
Oh yes, use of after: is wrong... I was of the impression it would return all objects after the argument, not just the next one :/ This is incompetence, not a VM bug :) Cheers, Henry
On 08.09.2011 21:32, Henrik Sperre Johansen wrote:
On 08.09.2011 21:30, Henrik Sperre Johansen wrote:
On 08.09.2011 21:19, Esteban Lorenzano wrote:
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 interpret
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 subs is a collection. after: returns a collection of the elements after each, or raises a NotFound error if the subscriber was the last one. If the one which was curtailed was the last one (and an error is raised), we don't need to handle delivering anything else, and thus simply return self.
At least that's how it's supposed to work...
What kind of error is thrown?
Cheers, Henry
Oh yes, use of after: is wrong... I was of the impression it would return all objects after the argument, not just the next one :/
This is incompetence, not a VM bug :)
Cheers, Henry
The correct code should be: self deliver: anAnnouncement to: (subs copyAfter: each) sorry about that :/ Cheers, Henry
yep, that seems to solve the problem. Should I fill a bug report? this is very, very important to me :) cheers, Esteban El 08/09/2011, a las 4:35p.m., Henrik Sperre Johansen escribió:
On 08.09.2011 21:32, Henrik Sperre Johansen wrote:
On 08.09.2011 21:30, Henrik Sperre Johansen wrote:
On 08.09.2011 21:19, Esteban Lorenzano wrote:
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 interpret
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 subs is a collection. after: returns a collection of the elements after each, or raises a NotFound error if the subscriber was the last one. If the one which was curtailed was the last one (and an error is raised), we don't need to handle delivering anything else, and thus simply return self.
At least that's how it's supposed to work...
What kind of error is thrown?
Cheers, Henry
Oh yes, use of after: is wrong... I was of the impression it would return all objects after the argument, not just the next one :/
This is incompetence, not a VM bug :)
Cheers, Henry
The correct code should be: self deliver: anAnnouncement to: (subs copyAfter: each)
sorry about that :/
Cheers, Henry
On 08.09.2011 21:38, Esteban Lorenzano wrote:
yep, that seems to solve the problem. Should I fill a bug report? this is very, very important to me :)
cheers, Esteban
El 08/09/2011, a las 4:35p.m., Henrik Sperre Johansen escribió:
Already did (4775), submitting slices for 1.3 / 1.4 now. Cheers, Henry
I still wonder why interpreter does not executes curtailedBlock and cog does... but anyway... if that works... :) thanks! Esteban El 08/09/2011, a las 4:40p.m., Henrik Sperre Johansen escribió:
On 08.09.2011 21:38, Esteban Lorenzano wrote:
yep, that seems to solve the problem. Should I fill a bug report? this is very, very important to me :)
cheers, Esteban
El 08/09/2011, a las 4:35p.m., Henrik Sperre Johansen escribió:
Already did (4775), submitting slices for 1.3 / 1.4 now.
Cheers, Henry
On 08.09.2011 21:43, Esteban Lorenzano wrote:
I still wonder why interpreter does not executes curtailedBlock and cog does... but anyway... if that works... :)
thanks!
Esteban Well, that's a separate issue from the logic error...
How is the Notification handled? On the Cog/NonCog VM's I test on, a normal, unresponded to Notification is not curtailed: [[Transcript show: 'before'. Notification new signal. Transcript show: 'after'.] ifCurtailed: [Transcript show: 'Too late!']]fork. prints beforeafter while one which is terminated while handled is curtailed on both: [[[Transcript show: 'before'. Notification new signal. Transcript show: 'after'.] on: Notification do: [:err | Processor activeProcess terminate]] ifCurtailed: [Transcript show: 'Too late!']]fork prints beforeToo late! Cheers, Henry
Thanks :)
yep, that seems to solve the problem. Should I fill a bug report? this is very, very important to me :)
cheers, Esteban
El 08/09/2011, a las 4:35p.m., Henrik Sperre Johansen escribió:
Already did (4775), submitting slices for 1.3 / 1.4 now.
Cheers, Henry
participants (3)
-
Esteban Lorenzano -
Henrik Sperre Johansen -
Stéphane Ducasse