December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] MultiByteFileStream #converter - what does it do?

by stepharo

Sven could we not nuke MultiByteFileStream and use ZnCharacterStreams? Le 17/12/14 19:54, Sven Van Caekenberghe a Ã©crit : >> On 17 Dec 2014, at 19:42, sheridan(a)sheridan-mahoney.com wrote: >> >> >> Hi there, >> >> I am still working my way through MultiByteFileStream tests, and have come across the messages #converter and #converter: . I would like to be able to test these - could someone explain briefly how the converters are used in this class? > In order to convert from bytes to characters and vice versa, MultiByteFileStream uses a TextConverter subclass instance as a helper. The messages #nextFromStream: and #nextPut:onStream: are the main interface between the two. > > The silly thing is that both MultiByteFileStream and TextConverter convert from wrongly encoded strings to correctly encoded strings. ZnCharacter[Read|Write]Stream and ZnCharacterEncoder do the correct thing. > > Sven >

Dec. 18, 2014

Re: [Pharo-dev] 14615 Change in Delay semantics when high priority timer event loop stopped

by stepharo

BTW I **loved** your concerns about concurrency and announcement improving delay Keep pushing Le 17/12/14 16:51, Ben Coman a Ã©crit : > > I'm looking for some community feedback on Case 14615. When the high > priority Delay timer event loop is stopped, there are two basic choices: > > 1. Delays wait indefinitely, since their delaySemaphore is never > signaled, and so for example, the UI locks up. > > 2. Delays are ignored, proceeding immediately. This would let the UI > continue working, give you a chance to restart the timer event loop, > or change the DelayScheduler algorithm on-the-fly (e.g. mutex, > semaphore, spinlock). > > The system currently does (1.). This is impeding integration of > Case 14252 to change Delays from millisecond to microsecond clock, > since as a Preload the Delay timer event loop is stopped to load the > slice. > > I'd like to change it to (2.), which can be done in a single line. > > Your thoughts ? > > > https://pharo.fogbugz.com/default.asp?14615 > > https://pharo.fogbugz.com/default.asp?14353 > >

Dec. 18, 2014

Re: [Pharo-dev] 14615 Change in Delay semantics when high priority timer event loop stopped

by stepharo

Ben I would love to be able to answer a clever answer but I'm not deadlock free when it comes with concurrency. I would like igor to answer because he has accumulated experience of concurrent matters. Now I have the impression that I would go for 2 because it opens more doors and that 1 does not really help. Le 17/12/14 16:51, Ben Coman a Ã©crit : > > I'm looking for some community feedback on Case 14615. When the high > priority Delay timer event loop is stopped, there are two basic choices: > > 1. Delays wait indefinitely, since their delaySemaphore is never > signaled, and so for example, the UI locks up. > > 2. Delays are ignored, proceeding immediately. This would let the UI > continue working, give you a chance to restart the timer event loop, > or change the DelayScheduler algorithm on-the-fly (e.g. mutex, > semaphore, spinlock). > > The system currently does (1.). This is impeding integration of > Case 14252 to change Delays from millisecond to microsecond clock, > since as a Preload the Delay timer event loop is stopped to load the > slice. > > I'd like to change it to (2.), which can be done in a single line. > > Your thoughts ? > > > https://pharo.fogbugz.com/default.asp?14615 > > https://pharo.fogbugz.com/default.asp?14353 > >

Dec. 18, 2014

Re: [Pharo-dev] [Moose-dev] Re: [ANN] CubeHelix and slider

by stepharo

Le 17/12/14 13:26, Alexandre Bergel a Ã©crit : > This is exactly what we are trying to do: > http://agilevisualization.com > > It takes time, but we will succeedâ¦ There is no doubt about that. + 1 Esteban did some bench with OSWindow cairo rendering (instead of passing via bitblt) and he got 12% for OSWindow instead of 70% of cpu eats :) > > Alexandre > > >> On Dec 17, 2014, at 9:42 AM, phil(a)highoctane.be wrote: >> >> One good feature I'd see added to PillarHub would be the ability to CC: a PillarHub email address so that the snippet gets included directly in a PH page (or specific hub, like the Roassal Hub, the GT Hub, the ANN Hub ...) >> >> What do you think? >>

Dec. 18, 2014

Re: [Pharo-dev] RBEnvironments allClasses/Traits/Meta ...

by Yuriy Tymchuk

Iâm ready to help with this issue, but as far as I can tell, itâs not hard to implement the mentors. Here we should decide on the meaning of the phrases. What are "all behaviorsâ and so on. The reason of the refactoring that Iâve done was that there were two methods with similar names that were doing different things. Uko > On 18 Dec 2014, at 21:19, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Hi, > > some time ago Yuriy cleaned up the RBBrowserEnvironment methods for > allClassesAndTraits(Do), classesDo, .... > > The fix was good and necessary (I think). But they had an impact > on some SmallLint-rules (they arent applied on the class side) and the behavior > for the different Environments changed (compared with Pharo3 > (-> 14621 <https://pharo.fogbugz.com/default.asp?14621> Some RBBrowserEnvironments don't work well with Metaclasses)) > > As some SmallLint-rules need to iterate over the metaclasses as well and > I don't want to revert Yuriys change, I 'll add another method that > collect classes and metaclasses. > > So, I need some help, how to name this methods: > > all classes (Object, Integer, ....) -> allClasses, ok > all classes and metaclasses (Object, Object class, Integer class ) -> ? allBehaviors? > all classes and traits -> allClassesAndTraits, ok > all classes and meta classes and traits and class traits -> ? no idea! > all metaclasses and class traits -> allMeta(ClassesAndTraits) ? I don't know if we need this > > One problem with "allBehaviors" is, SystemNavigation uses allBehaviors to iterate > over classes, metaclasses, traits and class traits, > allthough a Trait is not a Behavior. (TClass isBehavior -> false) > > feedback is welcome > > > nicolai > >

Dec. 18, 2014

Integrator commit messages

by Torsten Bergmann

This is what is written as commit message for "NativeBoost-Core-TheIntegrator.159.mcz" in Pharo40 repo: ---------------------------------------------------- Name: NativeBoost-Core-TheIntegrator.159 Author: TheIntegrator Time: 15 December 2014, 3:52:08.722338 pm UUID: 0d05c400-7772-4c62-926c-03ffcde840f1 Ancestors: NativeBoost-Core-TorstenBergmann.158 14627 Taskbar > Close all > windows to right https://pharo.fogbugz.com/f/cases/14627 ----------------------------------------------------- But the issue that was solved between "NativeBoost-Core-TheIntegrator.157.mcz" and "NativeBoost-Core-TheIntegrator.159" was issue #14626 (https://pharo.fogbugz.com/f/cases/14626) and not #14627 Is this a bug in the new Integrator tool? Thanks T.

Dec. 18, 2014

RBEnvironments allClasses/Traits/Meta ...

by Nicolai Hess

Hi, some time ago Yuriy cleaned up the RBBrowserEnvironment methods for allClassesAndTraits(Do), classesDo, .... The fix was good and necessary (I think). But they had an impact on some SmallLint-rules (they arent applied on the class side) and the behavior for the different Environments changed (compared with Pharo3 (-> 14621 <https://pharo.fogbugz.com/default.asp?14621> Some RBBrowserEnvironments don't work well with Metaclasses)) As some SmallLint-rules need to iterate over the metaclasses as well and I don't want to revert Yuriys change, I 'll add another method that collect classes and metaclasses. So, I need some help, how to name this methods: all classes (Object, Integer, ....) -> allClasses, ok all classes and metaclasses (Object, Object class, Integer class ) -> ? allBehaviors? all classes and traits -> allClassesAndTraits, ok all classes and meta classes and traits and class traits -> ? no idea! all metaclasses and class traits -> allMeta(ClassesAndTraits) ? I don't know if we need this One problem with "allBehaviors" is, SystemNavigation uses allBehaviors to iterate over classes, metaclasses, traits and class traits, allthough a Trait is not a Behavior. (TClass isBehavior -> false) feedback is welcome nicolai

Dec. 18, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40419 Home: https://github.com/pharo-project/pharo-core

Dec. 18, 2014

[pharo-project/pharo-core] 415dbb: 40419

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 415dbbe176ed05cb2b52023bb3fe356e8273cc14 https://github.com/pharo-project/pharo-core/commit/415dbbe176ed05cb2b52023b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-18 (Thu, 18 Dec 2014) Changed paths: A Deprecated40.package/NBWin32Caret.class/README.md A Deprecated40.package/NBWin32Caret.class/class/accessing/getBlinkTime.st A Deprecated40.package/NBWin32Caret.class/definition.st A Deprecated40.package/NBWin32Menu.class/README.md A Deprecated40.package/NBWin32Menu.class/definition.st A Deprecated40.package/NBWin32MessageBox.class/README.md A Deprecated40.package/NBWin32MessageBox.class/class/instance creation/messageBox_text_title_flags_.st A Deprecated40.package/NBWin32MessageBox.class/class/instance creation/test.st A Deprecated40.package/NBWin32MessageBox.class/definition.st A Deprecated40.package/NBWin32Process.class/README.md A Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcess.st A Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcessId.st A Deprecated40.package/NBWin32Process.class/definition.st A Deprecated40.package/NBWin32Process.class/instance/accessing/getPriorityClass.st A Deprecated40.package/NBWin32Process.class/instance/testing/isHighPriorityClass.st A Deprecated40.package/NBWin32Process.class/instance/testing/isIdlePriorityClass.st A Deprecated40.package/NBWin32Process.class/instance/testing/isNormalPriorityClass.st A Deprecated40.package/NBWin32Process.class/instance/testing/isRealtimePriorityClass.st A Deprecated40.package/NBWin32ShellTest.class/README.md A Deprecated40.package/NBWin32ShellTest.class/definition.st A Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetCommandLine.st A Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetComputerName.st A Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetDriveType.st A Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNoDebuggerPresentByDefault.st A Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNumberOfProcessors.st A Deprecated40.package/NBWin32Thread.class/README.md A Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThread.st A Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThreadId.st A Deprecated40.package/NBWin32Thread.class/definition.st A Deprecated40.package/NBWin32Thread.class/instance/testing/isThreadAllAccess.st M Morphic-Base.package/MenuMorph.class/instance/events/handleFocusEvent_.st M Morphic-Base.package/MenuMorph.class/instance/invoking/invokeAt_in_allowKeyboard_.st M Morphic-Base.package/MenuMorph.class/instance/modal control/invokeModalAt_in_allowKeyboard_.st A Morphic-Base.package/MenuMorph.class/instance/private/restoreFocus_in_.st R NativeBoost-Tests.package/NBWin32ShellTest.class/README.md R NativeBoost-Tests.package/NBWin32ShellTest.class/definition.st R NativeBoost-Tests.package/NBWin32ShellTest.class/instance/tests/testGetCommandLine.st R NativeBoost-Tests.package/NBWin32ShellTest.class/instance/tests/testGetComputerName.st R NativeBoost-Tests.package/NBWin32ShellTest.class/instance/tests/testGetDriveType.st R NativeBoost-Tests.package/NBWin32ShellTest.class/instance/tests/testNoDebuggerPresentByDefault.st R NativeBoost-Tests.package/NBWin32ShellTest.class/instance/tests/testNumberOfProcessors.st R NativeBoost-Win32.package/NBWin32Caret.class/README.md R NativeBoost-Win32.package/NBWin32Caret.class/class/accessing/getBlinkTime.st R NativeBoost-Win32.package/NBWin32Caret.class/definition.st R NativeBoost-Win32.package/NBWin32Menu.class/README.md R NativeBoost-Win32.package/NBWin32Menu.class/definition.st R NativeBoost-Win32.package/NBWin32MessageBox.class/README.md R NativeBoost-Win32.package/NBWin32MessageBox.class/class/instance creation/messageBox_text_title_flags_.st R NativeBoost-Win32.package/NBWin32MessageBox.class/class/instance creation/test.st R NativeBoost-Win32.package/NBWin32MessageBox.class/definition.st R NativeBoost-Win32.package/NBWin32Process.class/README.md R NativeBoost-Win32.package/NBWin32Process.class/class/accessing/getCurrentProcess.st R NativeBoost-Win32.package/NBWin32Process.class/class/accessing/getCurrentProcessId.st R NativeBoost-Win32.package/NBWin32Process.class/definition.st R NativeBoost-Win32.package/NBWin32Process.class/instance/accessing/getPriorityClass.st R NativeBoost-Win32.package/NBWin32Process.class/instance/testing/isHighPriorityClass.st R NativeBoost-Win32.package/NBWin32Process.class/instance/testing/isIdlePriorityClass.st R NativeBoost-Win32.package/NBWin32Process.class/instance/testing/isNormalPriorityClass.st R NativeBoost-Win32.package/NBWin32Process.class/instance/testing/isRealtimePriorityClass.st R NativeBoost-Win32.package/NBWin32Thread.class/README.md R NativeBoost-Win32.package/NBWin32Thread.class/class/accessing/getCurrentThread.st R NativeBoost-Win32.package/NBWin32Thread.class/class/accessing/getCurrentThreadId.st R NativeBoost-Win32.package/NBWin32Thread.class/definition.st R NativeBoost-Win32.package/NBWin32Thread.class/instance/testing/isThreadAllAccess.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script419.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40419.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40419 14637 Deprecate some NBWin32xxxx classes in favour of external OS-Windows package https://pharo.fogbugz.com/f/cases/14637 13269 MenuMorph invokeModal restores focus https://pharo.fogbugz.com/f/cases/13269 5809 Overlapping sub-MenuMorphs do not hold focus https://pharo.fogbugz.com/f/cases/5809 http://files.pharo.org/image/40/40419.zip

Dec. 18, 2014

Re: [Pharo-dev] 14615 Change in Delay semantics when high priority timer event loop stopped

by Ben Coman

Guillermo Polito wrote: > On Wed, Dec 17, 2014 at 4:51 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > > I'm looking for some community feedback on Case 14615. When the high > priority Delay timer event loop is stopped, there are two basic choices: > > 1. Delays wait indefinitely, since their delaySemaphore is never > signaled, and so for example, the UI locks up. > > 2. Delays are ignored, proceeding immediately. This would let the UI > continue working, give you a chance to restart the timer event loop, > or change the DelayScheduler algorithm on-the-fly (e.g. mutex, > semaphore, spinlock). > > The system currently does (1.). This is impeding integration of > Case 14252 to change Delays from millisecond to microsecond clock, > since as a Preload the Delay timer event loop is stopped to load the > slice. > > > Did you try to do the switch in another process? > > [ > oldDelayLoop stop. > newDelayLoop start. > ] forkAt: Processor highestPriority. > > That should do that outside of the UI event loop, and so the new delay > process installation will not be suspended forever. > That could be a useful approach, except for the current purpose we need to do... oldDelayLoop stop. "User operation of the UI to use the Integration tool" newDelayLoop start. btw, Another reason to avoid a stopped delay loop freezing the UI (as proposed) is that you then can't debug a broken delay loop (which has been important to me to develop these changes). > Also, is there any kind of migration from the old delays to the new > delay process? Or they are shared and as soon as the new delay loop > starts it handles the old delays? Even though I said change timer event loop "on-the-fly", I don't expect it will be a frequent activity. Stopping the timer event loop currently signals all suspended delays to clear them, to guarantee no stuck delays. The supposition being that... one reason to stop the event loop is if something goes wrong and you need to start it fresh, this should be done without carrying forward old data that may be problematic. Now if you require the delays to be transfered to the newDelayLoop, that facility could be added. For the particular case changing from millisecond to microsecond clock, sharing the delays is problematic since the instance variable holding the delayDuration has significantly changed magnitude. Working on a some kind of migration strategy was more work than was necessary. Thanks for you feedback. > > > > I'd like to change it to (2.), which can be done in a single line. > > Your thoughts ? > > > https://pharo.fogbugz.com/__default.asp?14615 > <https://pharo.fogbugz.com/default.asp?14615> > > https://pharo.fogbugz.com/__default.asp?14353 > <https://pharo.fogbugz.com/default.asp?14353> >

Dec. 18, 2014