April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Announcement real problems - please read and comment.

by Igor Stasenko

On 1 April 2011 22:36, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 01.04.2011 21:07, StÃ©phane Ducasse wrote: >> >> Hi guys >> >> We found a problem with ben and RPackage. >> Here is the scenario and may be you can help us finding the right >> solutions. >> >> Nautilus renames a class >> Â Â Â Â the class got renamed >> Â Â Â Â -> Â an announcement is raised >> Â Â Â Â Â Â Â Â - nautilus gets notified, it asks rpackageOrganizer (which >> also listens to the same event) >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> Â rpackageOrg breaks because the class if >> was referting to does not exist anymore. > > This sounds like mess in logic. > You ask package of class that is in the process of being renamed? > Why would you expect this to work? > Use more announcements to represent multiple steps in renaming process, for > example both ClassRenaming and ClassRenamed. > Changing it's package is something you do as an action that should be _part_ > of renaming, while updating it's location is something you would do _after_ > renaming is complete. > I want to add that there should be single place handling this event. And if there multiple subscribers, they should not operate with same data. Otherwise you will have many problems. >> Problem 2 >> Â Â Â Â If rappckageOrganizer would be reached before Nautilus we would not >> get any problem (beside the problem 1). >> >> Â Â Â Â - we spent one hour playing with alternatives. >> Â Â Â Â We thought that if RPackage would points to classes a rename would >> not break the system. >> Â Â Â Â While this is true for class, the same problem will occur for >> method rename since compiled method are not shared and a new compiled method >> Â Â Â Â is compiled. >> >> Â Â Â Â - If RPackage was as deep inside the system as superclass/subclass, >> the invariant would be directly maintained by the system >> Â Â Â Â and we would not have to rely on announcement. But now we should >> find a solution. >> >> Â Â Â Â >> Â may be we should be able to say that an announcement has a >> priority. >> Â Â Â Â Typically we would like to say that when RPackageOrganizer >> Â register interests it should be served first. >> Â Â Â Â we could have a systemLevel priority that could be specified on >> registration. >> >> Â Â Â Â what do you think? > > Bad, bad, bad, bad, baaaaaad idea. > I know from experience that once you concede that announcement listener > order should matter, you are setting yourself up to fail. Exactly. > Although you know one listener _HAS_ to respond first, there will always be > someone else who want to respond "firstester". > Not to mention the logic in this case becomes next to impossible to > follow/debug/ maintain, as you've already experienced. > > For a proper solution, introduce more Announcements for actions which should > happen in different phases of a process, as explained above. > > Cheers, > Henry > > PS. I was unable to load RPackage. > The initialize method of PackageOrganizer in RPackage-Core calls > registerInterestToSystemAnnouncement, which is an extensions in > RPackage-SystemIntegration. > > PPS. There's a neat method called #on:send:to:, Â which would be perfect for > the different actions in RPackage-SystemIntegration. > > PPPS. Is the code for Nautilus available anywhere? > > -- Best regards, Igor Stasenko AKA sig.

April 2, 2011

Re: [Pharo-project] Pharo sprint at Brussels Friday 15th of April

by Igor Stasenko

On 2 April 2011 09:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > Johan Brichau and Andy Kellens are organizing a sprint at VUB. > Please let us know who will join. > I will join > > I probably too. > Stef > > -- Best regards, Igor Stasenko AKA sig.

April 2, 2011

Re: [Pharo-project] Issue 3940 in pharo: BlockNode has undeclared ivar optimizedMessageNode

by pharo＠googlecode.com

Comment #1 on issue 3940 by marcus.d...(a)gmail.com: BlockNode has undeclared ivar optimizedMessageNode http://code.google.com/p/pharo/issues/detail?id=3940 and there are accessors for an undefined var "tempsMark"

April 2, 2011

[Pharo-project] Issue 3941 in pharo: Paragraph (deprecated) has lots of refs to undefined temps

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3941 by marcus.d...(a)gmail.com: Paragraph (deprecated) has lots of refs to undefined temps http://code.google.com/p/pharo/issues/detail?id=3941 ... do we remove all methods? It's unlikely that we mange to not break the code anyway.

April 2, 2011

[Pharo-project] Issue 3940 in pharo: BlockNode has undeclared ivar optimizedMessageNode

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3940 by marcus.d...(a)gmail.com: BlockNode has undeclared ivar optimizedMessageNode http://code.google.com/p/pharo/issues/detail?id=3940 accessed in noteOptimizedIn: analyseTempsWithin: scopeBlock "<BlockNode>" rootNode: rootNode "<MethodNode>" assignmentPools: assignmentPools

April 2, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by StÃ©phane Ducasse

> PPS. There's a neat method called #on:send:to:, which would be perfect for the different actions in RPackage-SystemIntegration. I'm trying to understand how this on:send:to: would help us. Because Nautilus registered to system announcer Now I do not understand why RPackageOrganizer should not register to systemAnnouncer too. And even if we use on:send:to: who can garantee that the on:send:to: will notify first the RPackageOrganizer and not that an announcement will reach the browser before. What was your idea? Stef

April 2, 2011

Re: [Pharo-project] Issue 3936 in pharo: should recompile whole image in update

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3936 by marcus.d...(a)gmail.com: should recompile whole image in update http://code.google.com/p/pharo/issues/detail?id=3936 in 13130

April 2, 2011

[Pharo-project] [update 1.3] #13130

by Marcus Denker

13130 ----- Issue 3921: due to *graphics package, we lost some string changes Issue 3938: Fix ugly flashing in list morph Issue 3854: Move taskbar methods from Project to PasteUpMorph Issue 3939: Small DSA refactorings from squeak -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 2, 2011

Re: [Pharo-project] Issue 3939 in pharo: Small DSA refactorings from squeak

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3939 by marcus.d...(a)gmail.com: Small DSA refactorings from squeak http://code.google.com/p/pharo/issues/detail?id=3939 in 13130

April 2, 2011

Re: [Pharo-project] Issue 3935 in pharo: remove TranscriptTest from Deprecated 13

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.3 Comment #1 on issue 3935 by marcus.d...(a)gmail.com: remove TranscriptTest from Deprecated 13 http://code.google.com/p/pharo/issues/detail?id=3935 in 13130

April 2, 2011