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

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

by Henrik Sperre Johansen

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 1, 2011

Re: [Pharo-project] Solarized Color Scheme

by Tudor Girba

Hi, On 1 Apr 2011, at 20:53, StÃ©phane Ducasse wrote: > the red in @param in java does not work so it is strange > same remarks for ruby. > Now the text color is nice and lavande are nice but I wonder for color blind people I tested it with Sim Daltonism: http://michelf.com/projects/sim-daltonism/ It does pretty well (except for Protanopia). Cheers, Doru > On Apr 1, 2011, at 1:27 PM, Tudor Girba wrote: > >> Interesting link. Thanks. >> >> Cheers, >> Doru >> >> >> On 1 Apr 2011, at 13:22, Sven Van Caekenberghe wrote: >> >>> I remember there were some discussions about (theme / syntax highlighting) colors on this list in the past, and someone said that picking good colors is an art. I came across this site: >>> >>> http://ethanschoonover.com/solarized >>> >>> And it seems to me that this could be a good basis for a professional color scheme in one of Pharo's look and feels. As a fan / user of Glamorous, using the light theme on top of it would seem great. >>> >>> I am just posting this as a way to bookmark this link and because it might be useful. >>> >>> Solarized is MIT licensed. >>> >>> Sven >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of problem understanding." >> >> >> >> > > -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

April 1, 2011

[Pharo-project] http://www.mirandabanda.org/files/Cog/VM/VM.r2378/

by Eliot Miranda

Hi All, these fix the recent FFI bug and revert the HostWindowPlugin and SoundPlugin to the trunk VMs (away from the Teleplace versions). http://www.mirandabanda.org/files/Cog/VM/VM.r2378/ enjoy. Eliot

April 1, 2011

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

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3939 by nicolas....(a)gmail.com: Small DSA refactorings from squeak http://code.google.com/p/pharo/issues/detail?id=3939 Name: SLICE-Issue-3939-DSA-refactorings-nice.1 Dependencies: System-Hashing-nice.13

April 1, 2011

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

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #2 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 not in 13129. Strange

April 1, 2011

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

by pharo＠googlecode.com

Status: Accepted Owner: nicolas....(a)gmail.com Labels: Type-Squeak New issue 3939 by nicolas....(a)gmail.com: Small DSA refactorings from squeak http://code.google.com/p/pharo/issues/detail?id=3939 The main change is to use #reciprocalModulo:, otherwise there are some simplification too.

April 1, 2011

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

by StÃ©phane Ducasse

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 1, 2011

[Pharo-project] forum.world.st is down

by laurent laffont

could not access.... Laurent

April 1, 2011

Re: [Pharo-project] Issue 3934 in pharo: Add isDisplayed in SystemWindow

by StÃ©phane Ducasse

may be this is the same. Stef > Is not #isInWorld not sufficient? > > Regards, Gary > > ----- Original Message ----- From: <pharo(a)googlecode.com> > To: <pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, April 01, 2011 4:09 PM > Subject: [Pharo-project] Issue 3934 in pharo: Add isDisplayed in SystemWindow > > >> Status: FixProposed >> Owner: Benjamin...(a)gmail.com >> Labels: Nautilus >> >> New issue 3934 by Benjamin...(a)gmail.com: Add isDisplayed in SystemWindow >> http://code.google.com/p/pharo/issues/detail?id=3934 >> >> isDisplayed >> " Answer true if I am a submorph of World, ie if I am displayed " >> >> Attachments: >> SystemWindow.BenjaminVanRyseghem.1.cs 303 bytes >> > >

April 1, 2011

Re: [Pharo-project] who is using softSqueak and standard Squeak

by StÃ©phane Ducasse

Thanks I want to rename, repackage, glamourous and remove the bubble oriented color squeak look and keep one old sq colored for now. On Apr 1, 2011, at 3:04 PM, Patrick Barroca wrote: > Hello, > > Just to say that I have now a simple theme extending UITheme with the look of Glamourous and the support of squeak windows colour management. > > Since I worked in 1.2 I have yet to verify how this load in Pharo 1.3 and then I will publish it ;) > > On Wed, Mar 30, 2011 at 3:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > My first look yesterday night taught me that different windows colour management is a basic behaviour of UITheme via #patchworkUIThemeColorFor:. > > If I simply subclass UITheme and do nothing more I get more or less a standard squeak theme with coloured windows minus some fills and borders styles. > > > > From here I think I could try to make a simple theme with the look of Glamourous one with support for squeak windows colour management. > > Is this the right direction ? > > yes :) > I plan to refactor/clean the theme package too. > So if you have results let us know. > > Stef > > > > -- > Patrick Barroca

April 1, 2011