- Pharo-dev - lists.pharo.org

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

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