- Pharo-dev - lists.pharo.org

[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

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

by StÃ©phane Ducasse

Gofer new squeaksource: 'PharoTaskForces'; package: 'ConfigurationOfRPackage'; load ConfigurationOfRPackage project load: '1.0' load RPackage in latest 1.3 Stef On Apr 1, 2011, at 10:36 PM, Henrik Sperre Johansen 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. > >> 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. > 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? >

April 2, 2011

Re: [Pharo-project] Issue 3854 in pharo: Move taskbar methods from Project to PasteUpMorph

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3854 by marcus.d...(a)gmail.com: Move taskbar methods from Project to PasteUpMorph http://code.google.com/p/pharo/issues/detail?id=3854 in 13130

April 2, 2011

Re: [Pharo-project] Issue 3938 in pharo: Fix ugly flashing in list morph

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3938 by marcus.d...(a)gmail.com: Fix ugly flashing in list morph http://code.google.com/p/pharo/issues/detail?id=3938 in 13130

April 2, 2011

Re: [Pharo-project] Issue 3921 in pharo: due to *graphics package, we lost some string changes

by pharo＠googlecode.com

Updates: Status: Closed Comment #4 on issue 3921 by marcus.d...(a)gmail.com: due to *graphics package, we lost some string changes http://code.google.com/p/pharo/issues/detail?id=3921 in 13130

April 2, 2011