[Pharo-project] [Jenkins] New issue status for real problems.
Hi, I added a new tracker status: HorribleErrorBlockingEverything = World is stopped until this is resolved. Right now this has one: Issue 6336: deleting a method raises error 'No package found for selector.... http://code.google.com/p/pharo/issues/detail?id=6336 -- Marcus Denker -- http://marcusdenker.de
That was a weird bug... but I fixed it. We need a Debugger for the announcement system! I tried to refactoring a bit so you can get a clue what's going on when stepping through with the debugger... On 2012-07-11, at 09:05, Marcus Denker wrote:
Hi,
I added a new tracker status:
HorribleErrorBlockingEverything = World is stopped until this is resolved.
Right now this has one:
Issue 6336: deleting a method raises error 'No package found for selector.... http://code.google.com/p/pharo/issues/detail?id=6336
-- Marcus Denker -- http://marcusdenker.de
On Jul 11, 2012, at 11:05 AM, Camillo Bruni wrote:
That was a weird bug... but I fixed it. We need a Debugger for the announcement system! What do you mean? Because what I know is that debugging the test of announcement can be a pain because registrations are done in another world.
I tried to refactoring a bit so you can get a clue what's going on when stepping through with the debuggerâ¦
What you describe is more related to the state of the debugger and yes it was on our todo to fix the debugger.
Hi,
I added a new tracker status:
HorribleErrorBlockingEverything = World is stopped until this is resolved.
Right now this has one:
Issue 6336: deleting a method raises error 'No package found for selector.... http://code.google.com/p/pharo/issues/detail?id=6336
-- Marcus Denker -- http://marcusdenker.de
On 2012-07-11, at 15:02, Stéphane Ducasse wrote:
On Jul 11, 2012, at 11:05 AM, Camillo Bruni wrote:
That was a weird bug... but I fixed it. We need a Debugger for the announcement system! What do you mean? Because what I know is that debugging the test of announcement can be a pain because registrations are done in another world.
the problem is, that on:fork: and co are used in the WeakMessageSends and thus lose the complete reference to where they came from..
I tried to refactoring a bit so you can get a clue what's going on when stepping through with the debuggerâ¦
What you describe is more related to the state of the debugger and yes it was on our todo to fix the debugger.
no no, when you do SubscriptionRegistry >> #deliver: you create a complete copy of the subscriptions collection. This is not very useful, since you can filter them while copying => less items to copy, easier to inspect
On 11.07.2012 15:14, Camillo Bruni wrote:
On 2012-07-11, at 15:02, Stéphane Ducasse wrote:
On Jul 11, 2012, at 11:05 AM, Camillo Bruni wrote:
That was a weird bug... but I fixed it. We need a Debugger for the announcement system! What do you mean? Because what I know is that debugging the test of announcement can be a pain because registrations are done in another world. the problem is, that on:fork: and co are used in the WeakMessageSends and thus lose the complete reference to where they came from..
I tried to refactoring a bit so you can get a clue what's going on when stepping through with the debugger⦠What you describe is more related to the state of the debugger and yes it was on our todo to fix the debugger. no no, when you do SubscriptionRegistry >> #deliver: you create a complete copy of the subscriptions collection. This is not very useful, since you can filter them while copying => less items to copy, easier to inspect
Not threadsafely. Cheers, Henry
On 2012-07-11, at 15:28, Henrik Sperre Johansen wrote:
On 11.07.2012 15:14, Camillo Bruni wrote:
On 2012-07-11, at 15:02, Stéphane Ducasse wrote:
On Jul 11, 2012, at 11:05 AM, Camillo Bruni wrote:
That was a weird bug... but I fixed it. We need a Debugger for the announcement system! What do you mean? Because what I know is that debugging the test of announcement can be a pain because registrations are done in another world. the problem is, that on:fork: and co are used in the WeakMessageSends and thus lose the complete reference to where they came from..
I tried to refactoring a bit so you can get a clue what's going on when stepping through with the debugger⦠What you describe is more related to the state of the debugger and yes it was on our todo to fix the debugger. no no, when you do SubscriptionRegistry >> #deliver: you create a complete copy of the subscriptions collection. This is not very useful, since you can filter them while copying => less items to copy, easier to inspect
Not threadsafely.
? this has absolutely nothing to do with thread safeness....
On 11.07.2012 15:41, Camillo Bruni wrote:
On 2012-07-11, at 15:28, Henrik Sperre Johansen wrote:
On 11.07.2012 15:14, Camillo Bruni wrote:
On 2012-07-11, at 15:02, Stéphane Ducasse wrote:
On Jul 11, 2012, at 11:05 AM, Camillo Bruni wrote:
That was a weird bug... but I fixed it. We need a Debugger for the announcement system! What do you mean? Because what I know is that debugging the test of announcement can be a pain because registrations are done in another world. the problem is, that on:fork: and co are used in the WeakMessageSends and thus lose the complete reference to where they came from..
I tried to refactoring a bit so you can get a clue what's going on when stepping through with the debugger⦠What you describe is more related to the state of the debugger and yes it was on our todo to fix the debugger. no no, when you do SubscriptionRegistry >> #deliver: you create a complete copy of the subscriptions collection. This is not very useful, since you can filter them while copying => less items to copy, easier to inspect Not threadsafely. ? this has absolutely nothing to do with thread safeness.... You're right, I'd forgotten exactly what we'd done :) In my mind it still read something like:
deliver: anAnnouncement subscriptions copy do: [:each | each deliver: anAnnouncement ], relying on atomicity implicit through copy primitives rather than explicitly with a mutex. Filtering with the standard collection methods leaves you with an IdentitySet though, so you'd have to either convert it afterwards, change the curtailing code in deliver:to: (which uses Sequenceable protocol). Either probably has some tradeoff in readability/performance compared to the current delivery. Cheers, Henry
participants (4)
-
Camillo Bruni -
Henrik Sperre Johansen -
Marcus Denker -
Stéphane Ducasse