[Pharo-project] Class creation notification
Hi guys. I was checking who needs to be notified when a class is created. If I follow correctly senders of #notify:ofSystemChangesOfItem:change:using: and friends, I don't really find too many listeners. I found TestRunner >> initialize and MCPackageManager -- Mariano http://marianopeck.wordpress.com
grrr shorcuts.. then I found AutomaticMethodCategorizerApplier which I don't care. And I don't care if I need to close and open again the TestRunner. So....what I mean is that class creation notification increases Fuel classes materialization like 50%. Do you think this is un-important enough to provide a way to NOT notify? I mean, should I provide a way to avoid that and avoid the 50% ? or it will be totally unsafe? Thanks! On Fri, Sep 23, 2011 at 7:52 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys. I was checking who needs to be notified when a class is created. If I follow correctly senders of #notify:ofSystemChangesOfItem:change:using: and friends, I don't really find too many listeners. I found TestRunner >> initialize and MCPackageManager
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
grrr shorcuts.. then I found AutomaticMethodCategorizerApplier which I don't care.
+1
And I don't care if I need to close and open again the TestRunner.
-1 Alexandre
So....what I mean is that class creation notification increases Fuel classes materialization like 50%. Do you think this is un-important enough to provide a way to NOT notify? I mean, should I provide a way to avoid that and avoid the 50% ? or it will be totally unsafe?
Thanks!
On Fri, Sep 23, 2011 at 7:52 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote: Hi guys. I was checking who needs to be notified when a class is created. If I follow correctly senders of #notify:ofSystemChangesOfItem:change:using: and friends, I don't really find too many listeners. I found TestRunner >> initialize and MCPackageManager
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2011/9/23 Mariano Martinez Peck <marianopeck@gmail.com>
grrr shorcuts.. then I found AutomaticMethodCategorizerApplier which I don't care. And I don't care if I need to close and open again the TestRunner.
So....what I mean is that class creation notification increases Fuel classes materialization like 50%. Do you think this is un-important enough to provide a way to NOT notify? I mean, should I provide a way to avoid that and avoid the 50% ? or it will be totally unsafe?
I have no idea how notification works. I imagine that every class creation is notified. Perhaps it could be faster to notify only time that multiple classes have created. of course it requires a way to create classes without notifying. just an idea, Luc
Thanks!
On Fri, Sep 23, 2011 at 7:52 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys. I was checking who needs to be notified when a class is created. If I follow correctly senders of #notify:ofSystemChangesOfItem:change:using: and friends, I don't really find too many listeners. I found TestRunner >> initialize and MCPackageManager
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Mariano Martinez Peck wrote:
grrr shorcuts.. then I found AutomaticMethodCategorizerApplier which I don't care. And I don't care if I need to close and open again the TestRunner.
So....what I mean is that class creation notification increases Fuel classes materialization like 50%. Do you think this is un-important enough to provide a way to NOT notify? I mean, should I provide a way to avoid that and avoid the 50% ? or it will be totally unsafe?
Thanks!
Yes, it will be totally unsafe, if tools hold caches relying on the notifications for invalidation (which is entirely appropriate). A better solution would be to provide bulk notifications, so instead of sending a notification to subscribers once for each class added, you update them only once, after all classes are created. Same holds true for other kind of system changes. Cheers, Henry -- View this message in context: http://forum.world.st/Class-creation-notification-tp3837570p3841078.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Of course, this is best handled by modifying the notifier to determine what is a "bulk". One way; - fork off notification in a lower priority thread, keeping a (threadsafe) reference to the collection of classes. - thread nils var when starting delivery - if new notification should be raised, and collection not nil, add it to current instead. Cheers, Henry -- View this message in context: http://forum.world.st/Class-creation-notification-tp3837570p3841079.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
indeed.
Yes, it will be totally unsafe, if tools hold caches relying on the notifications for invalidation (which is entirely appropriate). A better solution would be to provide bulk notifications, so instead of sending a notification to subscribers once for each class added, you update them only once, after all classes are created. Same holds true for other kind of system changes.
Cheers, Henry
-- View this message in context: http://forum.world.st/Class-creation-notification-tp3837570p3841078.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
you should have also the browser and the recentMessageList look for event: Stef On Sep 23, 2011, at 7:52 PM, Mariano Martinez Peck wrote:
Hi guys. I was checking who needs to be notified when a class is created. If I follow correctly senders of #notify:ofSystemChangesOfItem:change:using: and friends, I don't really find too many listeners. I found TestRunner >> initialize and MCPackageManager
-- Mariano http://marianopeck.wordpress.com
participants (5)
-
Alexandre Bergel -
Henrik Sperre Johansen -
Luc Fabresse -
Mariano Martinez Peck -
Stéphane Ducasse