February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: I will customize phexample to work on both 1.4 and 2.0

by H. Hirzel

Hello Stefan Good that you work on customizing phexample to work on both 1.4 and 2.0. On 2/10/13, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 10 February 2013 17:28, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: >> Hi Stef: >> >> Begin forwarded message: >> >>> because now it only works on 2.0 >>> So I will use symbolic versions for real. >>> I think that you are working on 2.0. >>> On 1.4 I get DNU due to substrings... >> >> >> What's the best way to handle such trivial difference between different >> versions, or even dialects? >> >> So, the problem is basically #includesSubString: vs. #includesSubstring:, >> used by a single method. >> >> Creating a version specific package just for that methods seems to be >> exaggerated. No, if you look at it as a 'Shim' http://en.wikipedia.org/wiki/Shim_%28computing%29 It documents the differences between Pharo 1.4 and Pharo 2.0. If there is only one method in it that this is a helpful piece of information. Maybe there will be more methods later. Frank once had a 'PharoCompatibilityPackage' for Squeak for a particular purpose. I only had one method. This is a solution which communicate well. --Hannes >> However, you committed now Phexample-StephaneDucasse.68 that is based on >> Phexample-StefanMarr.67. >> I think, in general that will lead to mighty confusion because it is not a >> general fix, but Pharo 1.4 specific. >> The latest version now breaks on Pharo 2.0 again (with a deprecation...) >> >> Wouldn't it have been better to properly branch off this change and commit >> it to Phexample.Pharo1.4-StephaneDucasse.68 for instance? >> >> Any other good approach to handle such small differences in a scalable way >> would also be interesting... > > Given that Squeak suffers this particular problem as well (at least > for the moment...), perhaps a compatibility shim might be in order? > Non-Pharo-2.0 images simply file in a compatibility package that lets > them use Phexample. It keeps the problem where it belongs: in those > images that still have a horrible mEthodNaMe. > > frank > >> Thanks >> Stefan >> >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> > >

Feb. 10, 2013

Re: [Pharo-project] Empty top level class category

by Benjamin

Yep, I experienced that, and then you are more or less screwed, you can't load a new version :S Ben On Feb 10, 2013, at 8:21 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > If you load slice 6657 "[ENH] Spec Request : make nextFocus / previousFocus > Keymapping-based", there will be an extra, empty Spec-Tools category > created, causing Spec-Tools to be marked dirty in the MC Browser. > > > > -- > View this message in context: http://forum.world.st/Empty-top-level-class-category-tp4669050.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 10, 2013

[Pharo-project] Empty top level class category

by Sean P. DeNigris

If you load slice 6657 "[ENH] Spec Request : make nextFocus / previousFocus Keymapping-based", there will be an extra, empty Spec-Tools category created, causing Spec-Tools to be marked dirty in the MC Browser. -- View this message in context: http://forum.world.st/Empty-top-level-class-category-tp4669050.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 10, 2013

Re: [Pharo-project] SystemNavigation >> #allSelect:

by stephane ducasse

open an issue for 3.0 so that we do not forget Stef On Feb 10, 2013, at 5:25 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?

Feb. 10, 2013

Re: [Pharo-project] Less than 50 issues!

by Sean P. DeNigris

Sean P. DeNigris wrote > Current stats: > 29 Open 2.0 Issues (up from 27) [1] > 02 Ready to Review [2] > 04 Ready to Integrate [3] > ______ = > 23 Outstanding [4] (up from 22) > > A few more issues surfaced, but some nasty ones were resolved, and several > more are ready to integrate. We're still making very nice progress! > > [1] http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D2.0 > [2] > http://code.google.com/p/pharo/issues/list?can=2&q=label%3AMilestone-2.0+st… > [3] > http://code.google.com/p/pharo/issues/list?can=2&q=status%3AFixToInclude+Mi… > [4] > http://code.google.com/p/pharo/issues/list?cursor=pharo%3A7102&q=label%3AMi… -- View this message in context: http://forum.world.st/Less-than-50-issues-tp4667961p4669046.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 10, 2013

[Pharo-project] strange behavior of tests

by StÃ©phane Ducasse

This is strange I was running the tests of the fame project MCHttpRepository location: 'http://www.smalltalkhub.com/mc/Moose/Fame/main' user: 'StephaneDucasse' password: '' when I run the tests they get red and I get a lot of zeroDivide errorâ¦. something related to the progress bar because I get a division by zero When I edit the code so that the division is never 0 just adding + 1 as in the method progress ^ (currentValue - min) / ((max - min) + 1) the tests get green. I'm puzzled. Stef

Feb. 10, 2013

[Pharo-project] Pharo Regression Tests

by Camillo Bruni

I think I got the regression tests working ;) https://ci.inria.fr/pharo/job/Pharo-2.0-Regression-Tests/ and it detected the first bug in the `eval` command line handler, which would output a cr instead of an lf ;)

Feb. 10, 2013

Re: [Pharo-project] INI file in 2.0 one-click and Win-Executable

by Esteban Lorenzano

Hi, we already have that! problem is that build is broken since one month now and we still didn't find the time for fixing it (also there were a jenkins slave causing us problems). but it will be ready for 2.0 release Esteban On Feb 10, 2013, at 8:00 PM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > The new one-click on the CI server contains > an *.ini file. > > But it is named CogVM.ini and since the VM > is called NBCog.exe it's useless. > > > Maybe this is already taken care of since > I've seen a thread about the naming of the VM. > > IMHO we should have: > - Pharo.exe > - Pharo.ini > > and a resource section within the executable that > contains the details about the VM type (Cog, NB, ...), the distributor > and (file) version. > > We already discussed this in 2011 (!) here: > > http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/49287 > > and it is a shame that we made no progress for such > simple enhancements. > > Thanks > Torsten > >

Feb. 10, 2013

Re: [Pharo-project] Fwd: I will customize phexample to work on both 1.4 and 2.0

by Frank Shearar

On 10 February 2013 17:28, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi Stef: > > Begin forwarded message: > >> because now it only works on 2.0 >> So I will use symbolic versions for real. >> I think that you are working on 2.0. >> On 1.4 I get DNU due to substrings... > > > What's the best way to handle such trivial difference between different versions, or even dialects? > > So, the problem is basically #includesSubString: vs. #includesSubstring:, used by a single method. > > Creating a version specific package just for that methods seems to be exaggerated. > > However, you committed now Phexample-StephaneDucasse.68 that is based on Phexample-StefanMarr.67. > I think, in general that will lead to mighty confusion because it is not a general fix, but Pharo 1.4 specific. > The latest version now breaks on Pharo 2.0 again (with a deprecation...) > > Wouldn't it have been better to properly branch off this change and commit it to Phexample.Pharo1.4-StephaneDucasse.68 for instance? > > Any other good approach to handle such small differences in a scalable way would also be interesting... Given that Squeak suffers this particular problem as well (at least for the moment...), perhaps a compatibility shim might be in order? Non-Pharo-2.0 images simply file in a compatibility package that lets them use Phexample. It keeps the problem where it belongs: in those images that still have a horrible mEthodNaMe. frank > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

Feb. 10, 2013

[Pharo-project] INI file in 2.0 one-click and Win-Executable

by Torsten Bergmann

The new one-click on the CI server contains an *.ini file. But it is named CogVM.ini and since the VM is called NBCog.exe it's useless. Maybe this is already taken care of since I've seen a thread about the naming of the VM. IMHO we should have: - Pharo.exe - Pharo.ini and a resource section within the executable that contains the details about the VM type (Cog, NB, ...), the distributor and (file) version. We already discussed this in 2011 (!) here: http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/49287 and it is a shame that we made no progress for such simple enhancements. Thanks Torsten

Feb. 10, 2013