- Pharo-dev - lists.pharo.org

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

by stephane ducasse

I have no idea. I'm sorry but I'm rather busy (in fact more than busy). I will not have the time to produce a version that works for other dialects. Now if this is a problem I will simply fork the project. We have to migrate Moose to 2.0 and this is not an easy task. We want to rewrite all the configurations and I have no time for the rest. As you know my goal is to make sure that people can make money with Smalltalk and we are working hard on that, we are building a company and I want it to succeed. So there is only that and Pharo in my radar. Stef > 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... > > 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] INI file in 2.0 one-click and Win-Executable

by Marcus Denker

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. > Yes, we made the one click work the last working build of the VMs we could find, which was NBCog. We need to get the build working and get the VM from there. This will be Pharo.exe And for 3.0 we should have -> real installers for every platform -> They come with a read-only image as part of the install that is started when you start the VM form e.g. the start menu -> Save then saves the VM like a document to the users dir -> klicking on such an image starts it ->This image is one file, simplifying everything. Marcus

Feb. 10, 2013

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