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

Re: [Pharo-project] Issue 3763 in pharo: assert failure during Decompiler>>popIntoTemporaryVariable:

by pharo＠googlecode.com

Updates: Status: Closed Comment #5 on issue 3763 by marcus.d...(a)gmail.com: assert failure during Decompiler>>popIntoTemporaryVariable: http://code.google.com/p/pharo/issues/detail?id=3763 We will see if this happens again after the compiler merges

April 2, 2011

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

by Henrik Sperre Johansen

On 02.04.2011 13:04, Igor Stasenko wrote: > 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. Why? If multiple different systems are interested in the same announcement, that is definately not the case, you want to keep the listeners separate for modularity. > And if there multiple subscribers, they should not operate with same > data. Otherwise you will have many problems. Right. Immutability would come in handy here :) In other words, don't mess with the contents of an Announcements when you handle it. Cheers, Henry

April 2, 2011

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

by Henrik Sperre Johansen

On 02.04.2011 09:16, StÃ©phane Ducasse wrote: > Henrik what is your answer to problem 1 > > Problem 1 > - the second announcement was never sent, because the first one broke the second was blocked. > >> we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass > > Because we can get the system down just because one guy can register a bug. http://forum.world.st/Another-finalization-concern-error-handling-td2989615… It's basically the same. Cheers, Henry

April 2, 2011

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

by Henrik Sperre Johansen

On 02.04.2011 12:13, StÃ©phane Ducasse wrote: >> 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 It has nothing to do with registration ordering, but using the proper API. If you look at the RPackageOrganizer registrations in RPackage-SystemIntegration, all they do in the action block is send self a message. Instead of: anAnnouncer when: SystemCategoryAddedAnnouncement do: [ :ann | self systemCategoryAddedActionFrom: ann ]; you write: announcer on: SystemCategoryAddedAnnouncement send: #systemCategoryAddedActionFrom: to: self It also has the added benefit you can make them weak if you want :) Cheers, Henry And ugh, why the Announcement at the end of the Announcement names? :/

April 2, 2011

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

by Marcus Denker

On Apr 2, 2011, at 9:31 AM, StÃ©phane Ducasse wrote: > Hi guys > > Johan Brichau and Andy Kellens are organizing a sprint at VUB. > Please let us know who will join. > I will join > me too. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 2, 2011

[Pharo-project] Issue 3942 in pharo: Transcript missing compatibility method ensureCr

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3942 by marcus.d...(a)gmail.com: Transcript missing compatibility method ensureCr http://code.google.com/p/pharo/issues/detail?id=3942 Transcript missing compatibility method ensureCr

April 2, 2011

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

by Schwab,Wilhelm K

Stef, This sounds like a job of a unit (acceptance) test :) One suggestion was to break the rename into pieces. I follow the thinking, but fear it will make the problem worse. Dolphin has a really slick event system, which was perhaps more of a big deal c 1997 than it is now. One thing that became clear early on is that events are a best effort system, and I ended up adding some messages to, at the expense of performance, provide a hardened version of the system. It's no big deal: I just trapped errors so that down-stream receivers would get their events. The events in question caused network activity, so failures were far more common than one would expect renaming a class. However, I think what you need here is a #rename:to:in: event that provides both old and new class names and the package that owns the affected class (the renamed version goes in the same package, right???). I **think** that, combined with some pre-rename checks (Is this going to work? If not, stop now...) will take care of the problem. HTH. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Friday, April 01, 2011 3:07 PM To: Pharo Development Subject: [Pharo-project] Announcement real problems - please read and comment. 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. Problem 1 - the second announcement was never sent, because the first one broke the second was blocked. >> we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass 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? Stef

April 2, 2011

Re: [Pharo-project] SqueakSource Down

by Mariano Martinez Peck

thanks! On Sat, Apr 2, 2011 at 2:31 PM, Fabrizio Perin <fabrizio.perin(a)gmail.com>wrote: > up again > > 2011/4/2 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> thanks >> > >

April 2, 2011

Re: [Pharo-project] SqueakSource Down

by Fabrizio Perin

up again 2011/4/2 Mariano Martinez Peck <marianopeck(a)gmail.com> > thanks >

April 2, 2011

[Pharo-project] SqueakSource Down

by Mariano Martinez Peck

thanks

April 2, 2011