- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3079 in pharo: Suggestion for Remodularisation -> ThreadSafeTranscript

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3079 by marcus.d...(a)gmail.com: Suggestion for Remodularisation -> ThreadSafeTranscript http://code.google.com/p/pharo/issues/detail?id=3079 ThreadSafeTranscript should be merged (or replaced by?) the new Transcript. I close this issue.

April 2, 2011

Re: [Pharo-project] Issue 3105 in pharo: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet

by pharo＠googlecode.com

Comment #2 on issue 3105 by marcus.d...(a)gmail.com: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet http://code.google.com/p/pharo/issues/detail?id=3105 fix attached Attachments: KernelCleanDeepCopier.1.cs 713 bytes

April 2, 2011

Re: [Pharo-project] Issue 3105 in pharo: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet

by pharo＠googlecode.com

Updates: Status: FixProposed Labels: Milestone-1.3 Comment #1 on issue 3105 by marcus.d...(a)gmail.com: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet http://code.google.com/p/pharo/issues/detail?id=3105 fix attached Attachments: KernelCleanDeepCopier.1.cs 713 bytes

April 2, 2011

Re: [Pharo-project] Issue 3080 in pharo: DSM analysis: Stream depends on compiler

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3080 by marcus.d...(a)gmail.com: DSM analysis: Stream depends on compiler http://code.google.com/p/pharo/issues/detail?id=3080 already done

April 2, 2011

Re: [Pharo-project] Issue 3598 in pharo: [Failing Test]Tests.Compiler.CompilerTest.testNotInteractiveInBlockTempArgumentShadowing

by pharo＠googlecode.com

Comment #1 on issue 3598 by marcus.d...(a)gmail.com: [Failing Test]Tests.Compiler.CompilerTest.testNotInteractiveInBlockTempArgumentShadowing http://code.google.com/p/pharo/issues/detail?id=3598 Issue 3873 has been merged into this issue.

April 2, 2011

Re: [Pharo-project] Issue 3873 in pharo: [Failing Test] 1.3 CompilerTest

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 3598 Comment #1 on issue 3873 by marcus.d...(a)gmail.com: [Failing Test] 1.3 CompilerTest http://code.google.com/p/pharo/issues/detail?id=3873 (No comment was entered for this change.)

April 2, 2011

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