Issue 4131 in pharo: Announcer instance problems

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue 4131 in pharo: Announcer instance problems

pharo
Status: New
Owner: ----

New issue 4131 by [hidden email]: Announcer instance problems
http://code.google.com/p/pharo/issues/detail?id=4131

Pharo image: Pharo-core
Pharo core version: Pharo1.3a
Latest update: #13172
Virtual machine used: <Pharo4.1.1 on Win32>
Class browser used (if applicable): "SystemBrowser default"

There are a several of problems with Announcements:
1. If an announcement subclass is deleted, the system will still send the  
deleted announcement.
2. It is possible to delete, then recreate an announcement, and the  
subscriber will not recognize the new one, even though it has the same name  
as the old one.
3. The standard Browser and the Finder do not easily find usage of an  
Announcement subclass.

The attached file is just something to work with. 1) DoIt in a workspace:  
x:=Run1 new run. 2. Then delete one of the announcements and run it again.  
It will probably show the results of both announcements.  If it only shows  
the one it should, try recreating the one you just deleted.  It will  
probably not do what it should when receiving that announcement.





Attachments:
        Sandbox110430Combo.st  2.3 KB


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4131 in pharo: Announcer instance problems

pharo
Updates:
        Status: Accepted
        Cc: [hidden email] [hidden email]
        Labels: Milestone-1.3

Comment #1 on issue 4131 by [hidden email]: Announcer instance  
problems
http://code.google.com/p/pharo/issues/detail?id=4131

Igor/ henrik
can you have a look?

Tx


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4131 in pharo: Announcer instance problems

pharo

Comment #2 on issue 4131 by [hidden email]: Announcer instance problems
http://code.google.com/p/pharo/issues/detail?id=4131

I fail to see how this related to announcements per se.
When you deleting a class, it removes an association with class name from  
Smalltalk globals dictionary, but
all other references to class are kept untouched.
This is how things working for everything, not just announcements.

Object subclass: #TTT
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'TTT'.

Object subclass: #TTT2
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'TTT'.

TTT2 class>>meth
        ^ TTT

TTT2 meth
-> TTT

now if you remove TTT class,
a #meth literal still points to same class object:

TTT2 meth
-> AnObsoleteTTT

except that name of class is changed by appending 'AnObsolete' to it.

To 'fix' the reference to non-existent class you should do:

TTT2 compileAll

now,
TTT2 meth
answers nil.

Now, after adding TTT class again,

TTT2 meth
will again answer TTT

So, this is nothing to do with Announcements.
If you want it to work like you want to, then
when you adding a new class, a references to 'AnObsolete<ClassName>' should  
be
updated and replaced by reference to newly created class.
But this is arguable. Because what if newly created class is not compatible  
with old one?
In any case manipulating with classes is not thing you doing too often, and  
so you should know what you doing and how.

There of course an option to change subscriptions to use a class name  
symbol instead of class object itself. Then to check if given subscription  
should deliver an announcement it should check that either announcement  
class name or one of its superclasses has the same name as held by  
subscription.
But this is too stretched i think, and slows down all announcements  
delivery.

So, my verdict to this issue: no action should be taken, and if it is, then  
in completely different place (the way how we deleting/replacing classes  
and updating references to them, but not the way how announcements working).



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4131 in pharo: Announcer instance problems

pharo

Comment #3 on issue 4131 by [hidden email]: Announcer instance problems
http://code.google.com/p/pharo/issues/detail?id=4131

"3. The standard Browser and the Finder do not easily find usage of an  
Announcement subclass. "

I didn't see anything related to that in the change set, What would you  
suggest?
For me, navigating to the announcement subclass, then browsing class  
references is usually enough.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4131 in pharo: Announcer instance problems

pharo

Comment #4 on issue 4131 by [hidden email]: Announcer instance  
problems
http://code.google.com/p/pharo/issues/detail?id=4131

If not here, something should be done elsewhere.

Run the sample code (MyRun1 new run), with a Transcript open.  Then delete  
both of the Announcements (Ann1 and Ann2), and run it again.  You get the  
exact same output.

Both MyAnnouncer1>>announce1 and MyAnnouncer1>>announce2 should generate a  
run-time error, when they hit the lines
    self announce: Ann1.
    self announce: Ann2.

Also deleting the classes doesn't give any indication of effect on other  
methods.  On the other hand, attempting to rename them does trigger a  
popup, allowing you to see what methods use the announcements. BUT SEE  
BELOW!

Otherwise you're leaving a bug that will be very hard to trace during  
run-time. An announcement could be triggering a whole lot more than some  
gentle Transcript entry. Maybe it's turning on electricity (oblivious to  
the fact that other code has detected gas).

Here's another problem.

After deleting Ann1 and Ann2, I added them back again. So now the category  
shows Ann1 and Ann2 as it did originally.  I run the code, and everything  
seems to look okay.  BUT:
Now I rename Ann1 to Ann1x. I expected a popup like when I tried to rename  
the original Ann1.  This time there is NO POPUP warning about methods that  
expect Ann1.
AND
if I run the trial (MyRun1 new run) again, MyAnnouncer>>announce1 still  
works, resulting in the Subscriber1 method being triggered. Apparently  
announce1 is still connected to the old Ann1, even though it has been  
deleted and replaced.

Perhaps dependent subscribers and announcers (I don't know which) need to  
automatically recompiled whenever an associated Announcement is deleted?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4131 in pharo: Announcer instance problems

pharo

Comment #5 on issue 4131 by [hidden email]: Announcer instance problems
http://code.google.com/p/pharo/issues/detail?id=4131

Doug, the problems you describing are not related to announcements per se.  
These problems are rather related to development tools and class management  
in system.

So, if you want to keep drawing attention to those, just change the topic  
of current issue or start another issue with proper name.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4131 in pharo: Announcer instance problems

pharo
Updates:
        Status: Invalid

Comment #6 on issue 4131 by [hidden email]: Announcer instance  
problems
http://code.google.com/p/pharo/issues/detail?id=4131

So this report is invalid?

(We need to really manage the bug tracker better... we are drowned in  
reports. Open reports that are acutally already fixed/closed/ found to be  
invalid are *HARMFUL* to an extreme as they take away time from everyone.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker