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

[Pharo-project] Issue 3569 in pharo: Error logging cleanup
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Status: Started Owner: siguc...(a)gmail.com New issue 3569 by siguc...(a)gmail.com: Error logging cleanup http://code.google.com/p/pharo/issues/detail?id=3569 Not best, but little better than before. - remove repetitive use of 'PharoDebug.log' all over the places. Now Debugger have #logFileName and keeps name in class var (should expose it in settings later). - deprecated #logError:inContext:to: , one should use #logError:inContext: instead. Attachments: DebuggerLog.3.cs 12.1 KB

1 1

[Pharo-project] Issue 3570 in pharo: EdgeGripMorph DNU when resizing
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Status: Accepted Owner: tudor.gi...(a)gmail.com Labels: Milestone-1.2 Type-Patch Importance-Low New issue 3570 by tudor.gi...(a)gmail.com: EdgeGripMorph DNU when resizing http://code.google.com/p/pharo/issues/detail?id=3570 From Andreas Wacknitz: 1. downloaded 12303: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/67/artifa… 2. filed in the attached CS 3. executed | m leftMorph scroll | m := PanelMorph new. m hResizing: #shrinkWrap; vResizing: #spaceFill; changeTableLayout; listDirection: #leftToRight. m addMorphBack: (leftMorph := Morph new color: Color red; minimumExtent: 150@10; extent: 150@10; hResizing: #rigid; "shown for clarity, is the default" vResizing: #spaceFill). m addMorphBack: (EdgeGripMorph new width: ProportionalSplitterMorph splitterWidth; hResizing: #rigid; "not the default this time, vResizing is also #spaceFill by default" target: leftMorph). m addMorphBack: (Morph new color: Color green; minWidth: 100; hResizing: #shrinkWrap; vResizing: #spaceFill). scroll := GeneralScrollPane new changeScrollerTableLayout; scrollTarget: m. scroll openInWindow. 4. When I execute the code in a Workspace a little dialog will open. It has a horizontal scroll bar that I can use. As soon as I move the splitter I will get the aforementioned DNU. I am on Mac OS 10.6.6.

1 3

[Pharo-project] [update 1.3] #13015
by Marcus Denker Jan. 22, 2011

Jan. 22, 2011

13015 ----- Issue 3500: Create deprecated13 Issue 3563: PCCByCompilationTest tests sometimes fail randomly Issue 3179: Failing Tests for Monticello Issue 3570: EdgeGripMorph DNU when resizing -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Issue 3179 in pharo: Failing Tests for Monticello
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Comment #1 on issue 3179 by marcus.denker: Failing Tests for Monticello http://code.google.com/p/pharo/issues/detail?id=3179 Current state: >>> Tests.Monticello.MCChangeNotificationTest.testExtMethodModified 0.0050 >>> 50 >>> Tests.Monticello.MCPackageTest.testUnload 0.636 50 The Tests.Monticello.MCPackageTest.testUnload only fails on Hudson.

1 8

[Pharo-project] Issue 3493 in pharo: Remove definitely MessagesNames and MethodFinder
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Status: Accepted Owner: marianopeck Labels: Milestone-1.3 New issue 3493 by marianopeck: Remove definitely MessagesNames and MethodFinder http://code.google.com/p/pharo/issues/detail?id=3493 In Pharo 1.2, we remove those guys from the menu. Now in 1.3 we should really remove them (remove its code).

1 1

[Pharo-project] Issue 3563 in pharo: PCCByCompilationTest tests sometimes fail randomly
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2 Milestone-1.3 New issue 3563 by marcus.d...(a)gmail.com: PCCByCompilationTest tests sometimes fail randomly http://code.google.com/p/pharo/issues/detail?id=3563 PCCByCompilationTest tests sometimes fail randomly

1 2

[Pharo-project] Issue 3500 in pharo: Create deprecated13
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Status: Fixed Owner: stephane.ducasse New issue 3500 by stephane.ducasse: Create deprecated13 http://code.google.com/p/pharo/issues/detail?id=3500 We should create a package deprecated13 as one of the first move in 1.3.

2 3

[Pharo-project] [update 1.2] #12319
by Marcus Denker Jan. 22, 2011

Jan. 22, 2011

12319 ----- Issue 3570: EdgeGripMorph DNU when resizing -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Instruments for headless images
by Igor Stasenko Jan. 22, 2011

Jan. 22, 2011

Hello folks. I'd like to ask, if there any 'standartized' instruments for headless images (or alike). I need a simple things: - redirect all ToolSet/UIManager messages to Transcript - redirect Transcript logging to file or stdout in short, these tools should serve a simple, yet important purpose: - if image runs in headless mode, it should suppress anything which expecting user interaction (like showing warnings with 'continue' button) and either log such messages to file or simply quit image with error message. Without such tool it is quite difficult to monitor, what happens with your headless image.. unless you have RFB installed.. but that is different and unrelated story. I did a prototype once for Hydra (you can check it at SqS/HydraVM/HydraVM.mcz package) there are two subclasses: - MorphicUIManager subclass: #HydraUIManager - StandardToolSet subclass: #HydraDebugToolSet and - WriteStream subclass: #HydraTranscript which can be installed as a Transcript. And in order to prepare image to run in headless mode, i issued: ToolSet unregister: StandardToolSet. ToolSet register: HydraDebugToolSet. UIManager default: HydraUIManager new. Also, HydraTranscript startUp does something like: TranscriptStream newTranscript: (self basicNew initialize on: (String new: 1000)) With that i could run the image in headless mode, knowing that in case of error or warning etc, all will be redirected to transcript, moreover i even stopped the UI process, so it never run on headless images. I wonder if there are other work, which can offer similar, and is there any way to detect that image are running in headless mode? -- Best regards, Igor Stasenko AKA sig.

6 25

[Pharo-project] PharoSound
by Henrik Sperre Johansen Jan. 22, 2011

Jan. 22, 2011

Hi Mariano & all! About the changes in 3489 and 3566 earlier today, I think there were some misunderstandings. The changes I made in 3566 is to PharoCore, and are intended to work with the Sound package in http://www.squeaksource.com/PharoSound. It moves the settings stored in SoundSettings to SoundService + ThemeSounds, which are more localized places for them. This makes sense by itself, but also because that's where they (well, only soundEnabled) are likely to be found if refactored to use preference pragmas in Squeak. Because the package in PharoSound has the Squeak trunk Sound package as ancestor as well, it's easy to synch up changes from it. (AFAIK the one in NonCorePackages does not). I feel this is important, since Sound does not really receive a lot of attention in Pharo, and efforts in Squeak should be as easy to integrate as possible. Thus, I'd really appreciate it if the ConfigurationOfSound could be changed to use this repository as the primary source. Cheers, Henry

3 5