- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Using a newer vm with PharoLauncher, platform differences

by Ben Coman

On Thu, Nov 12, 2015 at 11:12 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > I wanted to use a newer vm with PharoLauncher, > so I added a vms directory in > /Users/stephan/Library/Application Support/Pharo/ > and used > curl get.pharo.org/vmLatest50 | bash > to install it there. > In PharoLauncher I then set the vm full path to either > /Users/stephan/Library/Application > Support/Pharo/vms/pharo-vm/Pharo.app/Contents/MacOS/pharo > or > /Users/stephan/Library/Application Support/Pharo/vms/pharo-vm/Pharo.app > > Neither works to launch an image (Mac 10.10.5). > The similar procedure on Ubuntu 15.04 works (though the apt dependencies of > SDL2/Cairo/Freetype:i386 are somewhat broken). > > What is the vm path supposed to be? > > Stephan > > I remember having some problems and worked out escaping spaces is important. So this works for me... /Users/ben/Library/Application\ Support/Pharo/vm/ pharo-mac-stable-vm/Contents/MacOS/Pharo ...but thinking further on this, its non-obvious and we should make this easier - ideally using a file selection dialog. cheers -ben

Nov. 13, 2015

Re: [Pharo-dev] Some menu entries should not be in spotter

by Juraj Kubelka

Hi, Maybe it could be better to raise a confirmation dialog when clicking on the Software update item. Less a user need to know about structure of any entity (World Menu, Catalog, ...) while using Spotter, better. Cheers, Juraj > On Nov 11, 2015, at 10:14, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > We added all entries from the world menu to spotter. > But indeed without a better ordering of results this can cause some issues. > We can revert to a previous solution where we just show the items from the main and the tools menu. > > On Wed, Nov 11, 2015 at 1:03 PM, Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: > I managed to start 'Software update' by typing Date in spotter. > There are probably a few more menu entries that should > not be so easily accessible? > > Stephan > > >

Nov. 13, 2015

[Reflectivity] Method level breakpoints are back

by marcus.denker＠inria.fr

Hi, 50 441 now has simple method level breakpoints that are implemented using Reflectivity MetaLinks. Like the old breakpoints on Pharo3 and earlier, there is a menu entry to add (or remove) a break. The method icon is that of a #halt for now for active breakpoints. Next: Merge with the AST level breakpoint model. Marcus

Nov. 13, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 13, 2015

[pharo-project/pharo-core] acbcb3: 50441

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: acbcb34b4d8cd91b6bd77c7907663af0a5a3158d https://github.com/pharo-project/pharo-core/commit/acbcb34b4d8cd91b6bd77c79… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-13 (Fri, 13 Nov 2015) Changed paths: M Nautilus.package/MethodContainsHaltAction.class/instance/order/isActionHandled.st M Nautilus.package/MethodWidget.class/class/menu/elementsMenu_.st A Nautilus.package/NautilusUI.class/instance/menus behavior/toggleBreakOnEntryIn_.st A Nautilus.package/NautilusUI.class/instance/menus behavior/toggleBreakPoint.st A Reflectivity.package/Breakpoint2.class/README.md A Reflectivity.package/Breakpoint2.class/class/break/break.st A Reflectivity.package/Breakpoint2.class/class/install%2Fremove/installOn_.st A Reflectivity.package/Breakpoint2.class/class/install%2Fremove/removeAll.st A Reflectivity.package/Breakpoint2.class/class/install%2Fremove/removeFrom_.st A Reflectivity.package/Breakpoint2.class/definition.st A Reflectivity.package/BreakpointManager.class/README.md A Reflectivity.package/BreakpointManager.class/definition.st M Reflectivity.package/ReflectiveMethod.class/instance/invalidate/metaLinkOptions.st A Reflectivity.package/ReflectiveMethod.class/instance/invalidate/removeLink_.st A Reflectivity.package/extension/CompiledMethod/instance/hasBreakpoint.st R Reflectivity.package/extension/CompiledMethod/instance/removeLink.st A Reflectivity.package/extension/CompiledMethod/instance/removeLink_.st M Reflectivity.package/extension/LiteralVariable/instance/removeLink_.st M Reflectivity.package/extension/RBProgramNode/instance/removeLink_.st R Reflectivity.package/extension/RGMethodDefinition/instance/removeLink.st A Reflectivity.package/extension/RGMethodDefinition/instance/removeLink_.st M Reflectivity.package/extension/Slot/instance/removeLink_.st M Reflectivity.package/extension/TemporaryVariable/instance/removeLink_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50440.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50441.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50440.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50441.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50441 17000 Breakpoints per method using meta links https://pharo.fogbugz.com/f/cases/17000 http://files.pharo.org/image/50/50441.zip

Nov. 13, 2015

Re: [Pharo-dev] keyboard events in the windows VM

by Nicolai Hess

2015-11-12 16:43 GMT+01:00 EuanM <euanmee(a)gmail.com>: > I'm happy to test on Windows 7, and on Raspbian Linux > > (Although Raspbian Linux runs Pharo UI events slo-o-owly, so I am not > the best person to do the Linux testing) > Thank you EuanM, I 'll provide a vm with these changes. All changes are only for the windows vm at the moment. > > On 12 November 2015 at 15:42, EuanM <euanmee(a)gmail.com> wrote: > > I think anything that makes a consistent UI to Pharo for users on > > different platforms is a good thing. > > > > However, I do not know what the downside-effects of this change are. > > > > The key thing is to capture all breaks caused by the changed, so they > > can be coded through or around. And ensure that the test results are > > viewed with at least the same importance as the automated Jenkins CI > > test results. > > > > I do not know the extent that the Jenkins CI tests actually simulate > > user keyboard input, so... (Pharo pseudocode for comic effect and > > clarity) > > > > We can write Jenkins tests that simulate user input > > ifTrue: [ we should do so ]. > > ifFalse: [ > > we should > > write a canonical set of regression test scripts for human > > users to follow . > > we should > > do: [:eachPlatformSupportedByPharo | > > run the tests in which humans use keyboard tasks ] . > > we should > > capture the results ; > > and feed them into automated the regression tests results database > > ] > > > > > > On 12 November 2015 at 08:35, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> A short overview: > >> > >> With Ctrl-Key pressed, > >> > >> some keyboard events don't generate smalltalk keystrokes (EventKeyChar) > >> ctrl+tab, ctrl+1, ctrl+2, ..., ctrl+0, ctrl+Tab, ctrl+m > >> > >> for some keyboard events there are only key down and key up events (from > >> windows) but the vm "generates" a keypress (EventKeyChar) event > >> ctrl+Home, ctrl+End, ctrl+PageUp, ... > >> > >> But the key value , char code and ctrl flag for this generated events, > make > >> them undistinguishable from other ctrl+key shortcuts > >> ctrl+a = ctrl+Home, ctrl+d = ctrl+End, ctrl+k=ctrl+PageUp,... > >> > >> And one key (ctrl+Enter) creates two EventKeyChar events one "normal" > and > >> one that is generated from the vm > >> one with keyvalue 10 and one with 13. > >> > >> And the keycode for char like "a","b", ..., are different if you they > are > >> typed with or without ctrl-key > >> > >> just key "a": > >> keycode: > >> 65 (keydown event) > >> 97 (keyvalue/charcode event) (65 if you press shift key) > >> 65 (keyup event) > >> > >> with ctrl key pressed: > >> keycode > >> 65 (keydown event) > >> 1 (keyvalue/charcode event) > >> 65 (keyup event) > >> > >> > >> I would like to change this, that means: > >> > >> generate EventKeyChar events for > >> ctrl+1, ctrl+2, ..., ctrl+Tab, ctrl+m > >> > >> remove the double key event for ctrl+Enter > >> > >> and adopt the behavior of the linux vm, for keyValue, charCode values > for > >> events like > >> ctrl+a, ctrl+home, ... > >> > >> for example, the linux vm generates event buffer values: > >> #(2 7329656 1 0 2 65 0 1) for ctrl+a (keyValue 1/charCode 65) > >> but > >> #(2 7329656 1 0 2 1 0 1) for ctrl+home (keyValue 1/charCode 1) > >> > >> this may need some changes on the image side. For example, in Pharo we > >> have some special handling that adds "96" to the keyValue for keystrokes > >> with ctrl-key). > >> > >> What do you think? > >> > >> > >> > >> nicolai > >> > >

Nov. 13, 2015

Re: [Pharo-dev] Using a newer vm with PharoLauncher, platform differences

by Dimitris Chloupis

nice , I did not know that. Where is that setting located ? On Fri, Nov 13, 2015 at 3:09 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > On 12/11/15 23:46, Dimitris Chloupis wrote: > > I could be wrong but since pharolauncher on macos is a mac app then you > > will need to change the vm inside the pharo.app folder, in > > pharo.app/Contents/MacOS > > PharoLauncher has a setting to use a different vm to start its images > than the one it uses itself. I can get that to work on Ubuntu, but not > on mac. Changeing the vm in pharo.app in Applications and leaving the vm > path empty woudl be a workaround. > > Stephan > > > >

Nov. 13, 2015

Re: [Pharo-dev] Using a newer vm with PharoLauncher, platform differences

by Stephan Eggermont

On 12/11/15 23:46, Dimitris Chloupis wrote: > I could be wrong but since pharolauncher on macos is a mac app then you > will need to change the vm inside the pharo.app folder, in > pharo.app/Contents/MacOS PharoLauncher has a setting to use a different vm to start its images than the one it uses itself. I can get that to work on Ubuntu, but not on mac. Changeing the vm in pharo.app in Applications and leaving the vm path empty woudl be a workaround. Stephan

Nov. 13, 2015

Re: [Pharo-dev] Using a newer vm with PharoLauncher, platform differences

by Dimitris Chloupis

I could be wrong but since pharolauncher on macos is a mac app then you will need to change the vm inside the pharo.app folder, in pharo.app/Contents/MacOS On Thu, Nov 12, 2015 at 5:13 PM Stephan Eggermont <stephan(a)stack.nl> wrote: > I wanted to use a newer vm with PharoLauncher, > so I added a vms directory in > /Users/stephan/Library/Application Support/Pharo/ > and used > curl get.pharo.org/vmLatest50 | bash > to install it there. > In PharoLauncher I then set the vm full path to either > /Users/stephan/Library/Application > Support/Pharo/vms/pharo-vm/Pharo.app/Contents/MacOS/pharo > or > /Users/stephan/Library/Application Support/Pharo/vms/pharo-vm/Pharo.app > > Neither works to launch an image (Mac 10.10.5). > The similar procedure on Ubuntu 15.04 works (though the apt dependencies > of SDL2/Cairo/Freetype:i386 are somewhat broken). > > What is the vm path supposed to be? > > Stephan > > >

Nov. 12, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Tudor Girba

+1 Doru > On Nov 12, 2015, at 10:21 PM, stepharo <stepharo(a)free.fr> wrote: > > thanks max this is great to have your support. > > Le 12/11/15 21:21, Max Leske a Ã©crit : >> I found a single test method I could use to narrow down the problem (be aware that this might not work for you. I have other (fresh) images where the issue never occurs). The method I used is EpRedoAndUndoVisitorTest>>testClassModification. >> >> I was able to mitigate the hang by making a small modification to the method EpUndoVisitor>>visitClassModification: Simply add >> >> 2 seconds asDelay wait. Smalltalk garbageCollect. >> >> or >> >> Smalltalk garbageCollect. 2 seconds asDelay wait. >> >> after the compilation phase. My guess is, that announcements build up (a simple printout showed 1 announcement instance before and 74 instances after the #evaluate:) and do stuff in the system that influence the process scheduling. For instance, a lot of those announcements will probably be weak and need to be finalized at some point. >> >> I donât have enough experience with the ClassBuilder to go on hunting but this should hopefully give you a good head start. >> >> >> For testing I used the following command line: >> >> ./pharo found_case.image eval "CommandLineTestRunner runPackages: #('Epicea' 'Kernel-Testsâ)" >> >> Install Epicea with >> >> ./pharo Pharo.image get Epicea 6.5 >> >> >> To isolate the test case I simply moved test classes from Epicea to a differently named package and once I had found the class I started excluding methods (e.g. with âself fail.â at the beginning). >> >> >> HTH, >> Max >> >> >> >> >>> On 12 Nov 2015, at 18:57, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >>> Yes! with Max Leske we have been isolating the problem and we realized that a fresh image was enough: >>> >>> 1) >>> curl get.pharo.org/50+vm | bash >>> >>> 2) >>> ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" >>> >>> Martin >>> >>> On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Then it must be that waiting on the delay never ends, which is probably a problem all by itself. >>> >>> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> > >>> > The fun thing is that I now get the same problem when integrating the GT Tools update. >>> > >>> > After doing the update for issue 16957, the test run hangs with >>> > >>> > starting testcase: BlockClosureTest>>testBenchFor ... >>> > >>> > >>> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >> >>> >> Hello, >>> >> >>> >> I'm trying to understand why this method hangs in certain conditions*. What happens is that the #whileTrue: in the following method is never cut. >>> >> >>> >> benchFor: duration >>> >> "Run me for duration and return a BenchmarkResult" >>> >> >>> >> "[ 100 factorial ] benchFor: 2 seconds" >>> >> >>> >> | count run started | >>> >> count := 0. >>> >> run := true. >>> >> [ duration wait. run := false ] forkAt: Processor timingPriority - 1. >>> >> started := Time millisecondClockValue. >>> >> [ run ] whileTrue: [ self value. count := count + 1 ]. >>> >> ^ BenchmarkResult new >>> >> iterations: count; >>> >> elapsedTime: (Time millisecondsSince: started) milliSeconds; >>> >> yourself >>> >> >>> >> Strangely, I verified with several #logCr that the forked block starts, but the #wait never ends. >>> >> ---> Maybe you see something I don't in the code. Any clue? >>> >> >>> >> I will continue trying to isolate the problem, but maybe you have some idea. >>> >> >>> >> * the conditions to reproduce are: >>> >> 1) curl get.pharo.org/50+vm | bash >>> >> 2) ./pharo Pharo.image get Epicea 6.5 >>> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*' >>> >> >>> >> Notes: >>> >> - It doesn't hang when running from UI >>> >> - it doesn't hang when running less tests, like: >>> >> pharo Pharo.image test '^(?!Metacello)[E-L].*' >>> >> - it *does* hang even when removing all Epicea tests >>> >> - Epicea doesn't extend or override "kernel" behavior... >>> >> >>> >> Regards, >>> >> Martin >>> > >>> >>> >>> >> > -- www.tudorgirba.com "To utilize feedback, you first have to acquire it."

Nov. 12, 2015