November 2015 - Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

> On 12 Nov 2015, at 10:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > But how could Epicea have an impact on that part ? > > That is the question. > > Unless someone objects, I would not say that this should hold integration. There will be much more work to do after integration when people start using it ;-) Unless #benchFor: is broken for everyone, everywhere, of course >> On 12 Nov 2015, at 10:40, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Hi Sven, >> >> El 12/11/2015 9:32, "Sven Van Caekenberghe" <sven(a)stfx.eu> escribiÃ³: >> Hi Martin, >> >> Here is the relevant issue for the last change in that method: >> >> https://pharo.fogbugz.com/f/cases/14989/Improve-and-simplify-BlockClosure-b… >> >> IIRC the timing change was done in Squeak too, not the BenchmarkResult object. >> >> Maybe the old code is more reliable, thing is, the CI machines being VM's sometimes act very weird with respect to timing and clocks. >> >> Thanks for the pointer, I like the improvements of that slice: using the fork instead of comparing on each run, the new API, the new object to model the benchmark. >> >> Any suggestion of what to do with my problem? If I skip #testBenchFor, then no problem. So, it's the only test in the whole image that presents this problem. >> >> Ah, and this happens locally in my Mac OS too, not only in the CI. >> >> Martin >

Nov. 12, 2015

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

by Sven Van Caekenberghe

But how could Epicea have an impact on that part ? That is the question. Unless someone objects, I would not say that this should hold integration. There will be much more work to do after integration when people start using it ;-) > On 12 Nov 2015, at 10:40, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi Sven, > > El 12/11/2015 9:32, "Sven Van Caekenberghe" <sven(a)stfx.eu> escribiÃ³: > Hi Martin, > > Here is the relevant issue for the last change in that method: > > https://pharo.fogbugz.com/f/cases/14989/Improve-and-simplify-BlockClosure-b… > > IIRC the timing change was done in Squeak too, not the BenchmarkResult object. > > Maybe the old code is more reliable, thing is, the CI machines being VM's sometimes act very weird with respect to timing and clocks. > > Thanks for the pointer, I like the improvements of that slice: using the fork instead of comparing on each run, the new API, the new object to model the benchmark. > > Any suggestion of what to do with my problem? If I skip #testBenchFor, then no problem. So, it's the only test in the whole image that presents this problem. > > Ah, and this happens locally in my Mac OS too, not only in the CI. > > Martin

Nov. 12, 2015

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

by Martin Dias

Hi Sven, El 12/11/2015 9:32, "Sven Van Caekenberghe" <sven(a)stfx.eu> escribiÃ³: > Hi Martin, > > Here is the relevant issue for the last change in that method: > > > https://pharo.fogbugz.com/f/cases/14989/Improve-and-simplify-BlockClosure-b… > > IIRC the timing change was done in Squeak too, not the BenchmarkResult > object. > > Maybe the old code is more reliable, thing is, the CI machines being VM's > sometimes act very weird with respect to timing and clocks. > Thanks for the pointer, I like the improvements of that slice: using the fork instead of comparing on each run, the new API, the new object to model the benchmark. Any suggestion of what to do with my problem? If I skip #testBenchFor, then no problem. So, it's the only test in the whole image that presents this problem. Ah, and this happens locally in my Mac OS too, not only in the CI. Martin

Nov. 12, 2015

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by Frank Shearar

On 12 November 2015 at 09:04, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Le 10 nov. 2015 Ã 21:39, Sven Van Caekenberghe a Ã©crit : > >> << Sport is a Smalltalk portability layer. Sport presents a consistent interface and implemented in a number of Smalltalk dialects. Smalltalk code written to the Sport interfaces can be run in any Smalltalk dialect without alteration. >> >> >> Anyway, that was the idea some years ago. It is somewhat comparable to Grease (used by Seaside). > > Any reason to prefer one or the other? While they're both compatibility layers, Grease is a portability layer _for Seaside_, while Sport is a portability layer for time, sockets, and files. frank

Nov. 12, 2015

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by Christophe Demarey

Le 10 nov. 2015 Ã 21:39, Sven Van Caekenberghe a Ã©crit : > << Sport is a Smalltalk portability layer. Sport presents a consistent interface and implemented in a number of Smalltalk dialects. Smalltalk code written to the Sport interfaces can be run in any Smalltalk dialect without alteration. >> > > Anyway, that was the idea some years ago. It is somewhat comparable to Grease (used by Seaside). Any reason to prefer one or the other?

Nov. 12, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 12, 2015

[pharo-project/pharo-core] 224f0e: 50438

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 224f0e85618e9da1e6680661ef22490bfc47a786 https://github.com/pharo-project/pharo-core/commit/224f0e85618e9da1e6680661… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-12 (Thu, 12 Nov 2015) Changed paths: M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/stable_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version%5F0%5F11_.st A Growl.package/GrowlMorph.class/instance/internal/activeGrowlMorphs.st M Growl.package/GrowlMorph.class/instance/internal/is_saneWithRespectTo_.st M Growl.package/GrowlMorph.class/instance/position/unoccupiedPositionBottomLeft.st M Growl.package/GrowlMorph.class/instance/position/unoccupiedPositionBottomRight.st M Growl.package/GrowlMorph.class/instance/position/unoccupiedPositionTopLeft.st M Growl.package/GrowlMorph.class/instance/position/unoccupiedPositionTopRight.st M Morphic-Widgets-Windows.package/StandardWindow.class/instance/operations/flash.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50437.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50438.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50437.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50438.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tool-Catalog.package/CatalogProvider.class/class/installation/install_version_.st M Tool-Catalog.package/CatalogProvider.class/instance/private/loadProjects.st A Tool-Catalog.package/CatalogSettings.class/README.md A Tool-Catalog.package/CatalogSettings.class/class/accessing/catalogSourceURL.st A Tool-Catalog.package/CatalogSettings.class/class/accessing/catalogSourceURL_.st A Tool-Catalog.package/CatalogSettings.class/class/accessing/displayCatalogProjectsInSpotter.st A Tool-Catalog.package/CatalogSettings.class/class/accessing/displayCatalogProjectsInSpotter_.st A Tool-Catalog.package/CatalogSettings.class/class/defaults/defaultCatalogSourceURL.st A Tool-Catalog.package/CatalogSettings.class/class/settings/catalogSettingsOn_.st A Tool-Catalog.package/CatalogSettings.class/definition.st M Tool-Catalog.package/extension/GTSpotter/instance/spotterCatalogProjectsFor_.st Log Message: ----------- 50438 16997 Update to Catalog 0.11 (Easy loading, setting to switch of catalog spotter integration) https://pharo.fogbugz.com/f/cases/16997 16994 GrowlMorph position improvement https://pharo.fogbugz.com/f/cases/16994 16995 StandardWindow>>#flash should not block the UI thread https://pharo.fogbugz.com/f/cases/16995 http://files.pharo.org/image/50/50438.zip

Nov. 12, 2015

Re: [Pharo-dev] Ubuntu fullscreen problems

by Nicolai Hess

2015-11-09 21:41 GMT+01:00 J.F. Rick <self(a)je77.com>: > Works like a charm: both toggling modes and using the Unity pager to > switch workspaces. > Thank you for testing. Dave Lewis added another change to enable the old fullscreen method by a command line option. (some (older) windowmanager may not support the wm-protocol we used in our fix) see http://bugs.squeak.org/view.php?id=7833 I am sure, as soon as this change is in the squeak vm sources, estaban can pick this change for the pharo vm. > > Thanks! > > Jeff > > > On Sun, Nov 8, 2015 at 6:40 PM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> 2015-10-28 20:14 GMT+01:00 J.F. Rick <self(a)je77.com>: >> >>> Cool. I guess if there is a bug report on squeak then there is no reason >>> to create one on pharo. If you need someone to test a solution on Ubuntu >>> 15.10, let me know. >>> >> >> Hi Jeff, >> >> can you check this version, it works for me on >> >> DISTRIB_ID="elementary OS" >> DISTRIB_RELEASE=0.3.1 >> DISTRIB_CODENAME=freya >> DISTRIB_DESCRIPTION="elementary OS Freya" >> >> >> https://drive.google.com/file/d/0B8yEahnuIem2VGJlejJpUjZfZHc/view?usp=shari… >> >> it should work on Ubuntu, but I don|t have Ubuntu 15 installed. >> >> >> >> >>> >>> On Wed, Oct 28, 2015 at 11:21 AM Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> >>>> 2015-10-28 15:35 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>>> >>>>> I think there must be some incompatibility between Pharo and the host >>>>> window manager/desktop environment. >>>>> >>>>> On Debian/dwm (I am using Ubuntu VM) I can reproduce (1), but not (2). >>>>> >>>>> There is however interesting behavior... if I try to switch desktop >>>>> while in fullscreen it doesn't switch, however once I switch back to >>>>> non-fullscreen, suddenly I jump to the other desktop, as if the keyboard >>>>> shortcut for the switch got buffered somewhere... >>>>> >>>>> Opening a issue in FogzBugz is a good idea so it doesn't get forgotten. >>>>> >>>>> Peter >>>>> >>>>> On Wed, Oct 28, 2015 at 3:15 PM, J.F. Rick <self(a)je77.com> wrote: >>>>> >>>>>> Hi everybody, >>>>>> >>>>>> I just upgraded to Ubuntu 15.10 and am using Unity User Interface. I >>>>>> want Pharo to use the full screen (i.e., above the menu bar and launcher). >>>>>> Inside Pharo, I can choose "Toggle full screen mode". This works to some >>>>>> extent but has some problems: >>>>>> >>>>>> (1) I can no longer switch applications or desktops (i.e., pager). So >>>>>> it stops me doing work where I move between Pharo and a browser. This may >>>>>> be expected functionality. >>>>>> >>>>>> (2) More problematically, when I try to switch out of full screen >>>>>> mode by choosing "Toggle full screen mode", the Pharo interface completely >>>>>> disappears (just a giant gray area) and no mouse or keyboard events seem to >>>>>> register. I have to use command line to kill it. In good news, I can use >>>>>> "save and quit" instead and relaunching it just has it in maximum mode >>>>>> (full screen but launcher and menu bar are visible). I can then toggle full >>>>>> screen mode twice to get back to full screen. >>>>>> >>>>>> I searched for this on FogBugz but found nothing. Is there a >>>>>> workaround? This seems like a VM issue. Is there a newer VM that fixes >>>>>> this? I just used the most recent one on the Pharo 4.0 download page. >>>>>> >>>>>> If nobody has a fix, I'll open a case on FogBugz. This isn't a large >>>>>> problem but it would be nice to have this >>>>>> >>>>> >>>> It is a know problem (with possible fixes) >>>> (http://bugs.squeak.org/view.php?id=7812) >>>> You can not switch back from fullscreen on a linux 64-bit system ( >>>> http://bugs.squeak.org/view.php?id=7833) (maybe not only 32bit issue, >>>> but just the more recent windowmanager) >>>> >>>> >>>> >>>>> >>>>>> Cheers, >>>>>> >>>>>> Jeff >>>>>> >>>>> >>>>> >>>>

Nov. 12, 2015

keyboard events in the windows VM

by Nicolai Hess

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. 12, 2015

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

by Sven Van Caekenberghe

Hi Martin, Here is the relevant issue for the last change in that method: https://pharo.fogbugz.com/f/cases/14989/Improve-and-simplify-BlockClosure-b… IIRC the timing change was done in Squeak too, not the BenchmarkResult object. Maybe the old code is more reliable, thing is, the CI machines being VM's sometimes act very weird with respect to timing and clocks. Sven > On 12 Nov 2015, at 02:45, Martin Dias <tinchodias(a)gmail.com> wrote: > > I also tried with a modified #benchFor: that doesn't use a forked block, and that fixed the issue. > > benchFor: duration > "Run me for duration and return a BenchmarkResult" > > "[ 100 factorial ] benchFor: 2 seconds" > > | count started endTime | > count := 0. > started := Time millisecondClockValue. > endTime := started + duration asMilliSeconds. > [ Time millisecondClockValue > endTime ] whileTrue: [ self value. count := count + 1 ]. > ^ BenchmarkResult new > iterations: count; > elapsedTime: (Time millisecondsSince: started) milliSeconds; > yourself > > Do you think comparing each time, instead of using #fork is a bad idea? That's how it was working #bench in Pharo 3. > > Martin > > On Thu, Nov 12, 2015 at 2:42 AM, 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 >

Nov. 12, 2015