- Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 4 regressions found. Gofer.Tests.GoferOperationTest.testReinitialize Tests.Files.SourceFileArrayTest.testProtocol Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testObsoleteClasses

June 21, 2013

[update 3.0] #30213

by Esteban Lorenzano

June 21, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 7 regressions found. CompilerTests.CompilerTest.testInBlockArgumentInstanceVariableShadowing CompilerTests.CompilerTest.testInBlockTempInstanceVariableShadowing CompilerTests.CompilerTest.testInstanceVariableShadowing CompilerTests.CompilerTest.testNotInteractiveInBlockArgumentInstanceVariableShadowing CompilerTests.CompilerTest.testNotInteractiveInBlockTempInstanceVariableShadowing CompilerTests.CompilerTest.testNotInteractiveSiblingBlocksInstanceVariableShadowing CompilerTests.CompilerTest.testSiblingBlocksInstanceVariableShadowing

June 21, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 7 regressions found. CompilerTests.CompilerTest.testInBlockArgumentInstanceVariableShadowing CompilerTests.CompilerTest.testInBlockTempInstanceVariableShadowing CompilerTests.CompilerTest.testInstanceVariableShadowing CompilerTests.CompilerTest.testNotInteractiveInBlockArgumentInstanceVariableShadowing CompilerTests.CompilerTest.testNotInteractiveInBlockTempInstanceVariableShadowing CompilerTests.CompilerTest.testNotInteractiveSiblingBlocksInstanceVariableShadowing CompilerTests.CompilerTest.testSiblingBlocksInstanceVariableShadowing

June 21, 2013

First shot on acceptance tests for the VM

by Guillermo Polito

Hi! We were discussing over here about it, so I decided to finally start something on the front of an acceptance test for our VM. The core idea is to stress the VM to test its stability and find bugs and regressions. So I created the ci job in [1] which does: - use latest vm - use 2.0 latest image - loads seaside and moose on it - runs all tests Right now it runs on 6 different slaves, getting different results on each, which we should take care about :). Also there are some things on it that should be improved easily: - once 2.0 summer is released this job should use that version instead of the "latest" 2.0 - right now we are loading the development version of moose because moose 4.8 is not released (but will be soon :) And of course, now we have them, we can improve them (and make them run because not all of them do :D). Guille [1] https://ci.inria.fr/pharo/view/VM/job/PharoVM-AcceptanceTest/

June 21, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 7 regressions found. CompilerTests.CompilerTest.testInBlockArgumentInstanceVariableShadowing CompilerTests.CompilerTest.testInBlockTempInstanceVariableShadowing CompilerTests.CompilerTest.testInstanceVariableShadowing CompilerTests.CompilerTest.testNotInteractiveInBlockArgumentInstanceVariableShadowing CompilerTests.CompilerTest.testNotInteractiveInBlockTempInstanceVariableShadowing CompilerTests.CompilerTest.testNotInteractiveSiblingBlocksInstanceVariableShadowing CompilerTests.CompilerTest.testSiblingBlocksInstanceVariableShadowing

June 21, 2013

[update 3.0] #30212

by Esteban Lorenzano

30212 ----- 10976 kernel methods refactor https://pharo.fogbugz.com/f/cases/10976/kernel-methods-refactor (pass 3) Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-EstebanLorenzano.512.d… http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Core-EstebanLorenzan… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-EstebanLorenza… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-EstebanLorenzano.1488.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FuelTests-EstebanLorenzano.32… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-EstebanLorenzano.486…

June 21, 2013

Re: [Pharo-dev] on:do: for shortcuts?

by Goubier Thierry

Wouldn't that be a bit too much for what is called *Key*mapping in the first place ? I don't know if you've tried to debug the internals of the Keymapping machine... But, when I did so, I found them complex enough not to try to get them to do more than keymapping :) In particular, the double going down the Morph tree to try on the Morph which has the focus and then going up each owner to see if they want the event combined with the global tables which are class based were enough to give me a headache ;) I'd prefer to leave it as it is and maybe use it as an inspiration for other kind of events. The big case switch of event processing in many gui toolkits has never been my cup of tea. Thierry Le 21/06/2013 16:38, Denis Kudriashov a Ã©crit : > Hello. > > Keymappings is very nice approach to subscribe on concrete system state > instread of working with primitive event instances. And it can be > generalized to support other events (not only key combinations). In this > case subscribing API should not be related to key combinations > > > 2013/6/19 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com > <mailto:benjamin.vanryseghem.pharo@gmail.com>> > > Why not something like > > bindKeyCombination:toAction: > > ? > > Ben > > On Jun 19, 2013, at 9:28 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > >> excellent >> so how do we integrate this change? >> >> I will chnage the chapter on keymapping :) >> >> >> On Jun 18, 2013, at 9:57 PM, Guillermo Polito >> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >>> I prefer the onKeyCombination* because of the following rationale: >>> >>> - to me a shortcut is the association between a key combination >>> and an action >>> - a key combination is a combination of keys :), which is >>> associated with an action >>> >>> Stef, so far I changed the asShortcut => asKeyCombination, >>> following the same idea :). >>> >>> Guille >>> >>> >>> On Tue, Jun 18, 2013 at 8:25 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >>> >>> >>> On Jun 18, 2013, at 7:21 PM, GOUBIER Thierry >>> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> wrote: >>> >>> > The problem with onkeypress, onkeydown, onkeyup is that >>> they are low-level events compared to the shortcuts we are >>> talking about. >>> > >>> > A shortcut is at least one key, but is usually a key + a >>> modifier or a sequence of key + modifiers (such as the emacs >>> ^X ^C ($x ctrl, $c ctrl). The Keymapping stuff sits a lot >>> higher than the basic keypress events (which do exist as >>> well) and can recognize multi-keys combinations. If you call >>> that onKeyPress:do:, then you loose in the name part of the >>> power of it. >>> > >>> > Hence the onKeyCombination:do: (but I prefer onShortcut:do:) >>> >>> onShortcut:do: looks good to me. >>> >>> Stef >>> >>> >>> > >>> > Thierry >>> > ________________________________________ >>> > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org >>> <mailto:pharo-dev-bounces@lists.pharo.org>] de la part de >>> Esteban A. Maringolo [emaringolo(a)gmail.com >>> <mailto:emaringolo@gmail.com>] >>> > Date d'envoi : mardi 18 juin 2013 18:14 >>> > Ã : Pharo Development List >>> > Objet : Re: [Pharo-dev] on:do: for shortcuts? >>> > >>> > 2013/6/18 ClÃ©ment Bera <bera.clement(a)gmail.com >>> <mailto:bera.clement@gmail.com>> >>> > >>> >> On Javascript, there are : >>> >> >>> >> onkeypress >>> >> onkeydown >>> >> onkeyup >>> >> >>> >> >>> >> I think we should have same API than other languages, >>> especially popular ones. So 1 of these 3 would be the best >>> for me. >>> >> >>> >> Why not onKeyPress:do: ? >>> > >>> > +1 to each of the last two statements. >>> > >>> > >>> >>> >>> >> > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 21, 2013

Re: [Pharo-dev] Barcodes

by Guillaume Larcheveque

I prefer the first one, creating a separate package depending on both. 2013/6/21 Stephan Eggermont <stephan(a)stack.nl> > I've committed and merged. > That introduces a dependency on Barcode in Artefact. > Would you prefer: > - creating a separate package depending on both > - splitting artefact > - making Artefact depend on Barcode > - making the dependency the other direction > - reverting > > Stephan > > -- *Guillaume Larcheveque*

June 21, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 1 regressions found. Tests.Release.ReleaseTest.testObsoleteBehaviors

June 21, 2013