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

Re: [Pharo-dev] Updating JSON package

by Tommaso Dal Sasso

On 16/03/15 18:45, stepharo wrote: > I wnated to add you to pharo extras but I could not guess your account > so I did not do it. I always forget that... My account on SmalltalkHub is 'dalsat' Thanks, Tommaso > > Le 16/3/15 18:42, Tommaso Dal Sasso a Ã©crit : >> Hi, >> >> the JSON package in PharoExtras uses code that has been deprecated in >> Pharo 4.0. >> >> To solve the issue it is enough to change the initialize method in >> the class side of the class Json. >> >> The invocation of the method >> (each printStringHex padded: #left to: 4 with: $0) >> should be changed in: >> (each printStringHex padLeftTo: 4 with: $0) >> >> The new code still works with Pharo 3.0 and all the tests are still >> gree. >> Can somebody update that? I can also do that, but I need write access >> to the PharoExtras. >> >> Thanks, >> Tommaso >> >> > >

March 16, 2015

Re: [Pharo-dev] Updating JSON package

by stepharo

I wnated to add you to pharo extras but I could not guess your account so I did not do it. Le 16/3/15 18:42, Tommaso Dal Sasso a Ã©crit : > Hi, > > the JSON package in PharoExtras uses code that has been deprecated in > Pharo 4.0. > > To solve the issue it is enough to change the initialize method in the > class side of the class Json. > > The invocation of the method > (each printStringHex padded: #left to: 4 with: $0) > should be changed in: > (each printStringHex padLeftTo: 4 with: $0) > > The new code still works with Pharo 3.0 and all the tests are still gree. > Can somebody update that? I can also do that, but I need write access > to the PharoExtras. > > Thanks, > Tommaso > >

March 16, 2015

Updating JSON package

by Tommaso Dal Sasso

Hi, the JSON package in PharoExtras uses code that has been deprecated in Pharo 4.0. To solve the issue it is enough to change the initialize method in the class side of the class Json. The invocation of the method (each printStringHex padded: #left to: 4 with: $0) should be changed in: (each printStringHex padLeftTo: 4 with: $0) The new code still works with Pharo 3.0 and all the tests are still gree. Can somebody update that? I can also do that, but I need write access to the PharoExtras. Thanks, Tommaso

March 16, 2015

Re: [Pharo-dev] ExtendedNumberParser now has its own repository

by stepharo

thanks! I will update it. Le 16/3/15 16:14, Mariano Martinez Peck a Ã©crit : > > > On Sun, Mar 15, 2015 at 5:41 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > I did not want to lose the work of Nicolas Cellier around > alternate number parsers so I went > back in Pharo 30 and packaged them as a separate package (may be > it was already done but I could not find it). > > All the tests are green in Pharo 40. So I hope that everything is > ok :) > > MCHttpRepository > location: > 'http://www.smalltalkhub.com/mc/PharoExtras/ExtendedNumberParser/main' > user: '' > password: '' > > I did a configuration and published the code in the meta > repository for Pharo 40. > > Thanks Nicolas Cellier for the original code. > > Stef (I believe that we should pay attention that doing is > difficult and we should not lose good assets) > > Mariano can you verify if you can load it? > > > Yes, I can load it. > Regarding my own scenario, at least ExtendedNumberParser >> > allowPlusSign answers true. > But still, SqNumberParser >> exponentLetters does not contemplate > upper cases. So I still need to override it to: > > exponentLetters > ^'edqEDQ' > > > > > -- > Mariano > http://marianopeck.wordpress.com

March 16, 2015

Re: [Pharo-dev] [Pharo-users] [Pharo4] Please test Pharo4 *now*

by Sven Van Caekenberghe

> On 16 Mar 2015, at 17:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello, > > As every year: We can only fix what we know. > > And this means that no, just because *you* think that X and Y obviously needs to be fixed, > it will only be fixed if > a) there is an issue on the issue tracker > b) someone fixes it. > > I should repeat: *Nothing*, even the most obvious or trivial, happens by itself. > > Marcus Maybe it is also important to add that we are talking about bugs, not features. This is not the time for free wheeling discussions about anything, we need help in QA, to finalize the 4.0 release. Please load your code and give it a spin. Sven

March 16, 2015

Re: [Pharo-dev] Next Pharo sprints

by Marcus Denker

\ > We also hope to plan more informal sprints every other Friday afternoon. > If you have students who are working on (or with) Pharo, it could be > interesting for them to be present (please tell them). > For the private sprints, I do not know how we want them: > - like public sprints but in a small group (bug hunt) > - dedicated to one or several projects of team members > I think this part was meant more for the people in lille. Marcus

March 16, 2015

Next Pharo sprints

by stepharo

Hello, Next public Pharo sprints are now planned: http://pharo.org/news/Pharo-Sprints The next sprint will be on Friday, 3rd April, at Inria Lille. We also hope to plan more informal sprints every other Friday afternoon. If you have students who are working on (or with) Pharo, it could be interesting for them to be present (please tell them). For the private sprints, I do not know how we want them: - like public sprints but in a small group (bug hunt) - dedicated to one or several projects of team members JC

March 16, 2015

Re: [Pharo-dev] Exporting Setting preferences

by Juraj Kubelka

> 16. 3. 2015 v 13:23, Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> On 16 Mar 2015, at 17:11, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >> >> Hi, >> >> I have just realized that once someone exportes preferences in Pharo image, it overrides a lot of things in Moose image, e.g., debugger, icons. I do not really like it! Everyone who use both Pharo and Moose image will be surprised and unhappy. > > Yes, that is why I never use this export feature, it is broken by design, for me. Well, Spotter is potentially the first use case where people likely want to persist the setting about âsend usage dataâ. Otherwise it will ask in every new image. > > An image is a persistent world which can hold its own settings. > > I can imagine some people want some automatic loading in each new image, but that should be opt-in. Automatic loading is on by default. Cheers, Juraj > >> If someone exports preferences in Moose, he/she will always have debugger window at the beginning. I have written about it recently in another post. >> >> Technically speaking once someone exports preferences, he/she should always use the same kind of image. >> >> Talking about recent Spotter preference about âsending usage dataâ: we have already changed the preferences the way it uses Pharo settings; but do we really want it with all the consequences written above? I believe that we can still change it back for Pharo 4 and improve the whole preference mechanism in Pharo 5. >> >> Cheers, >> Juraj > >

March 16, 2015

Re: [Pharo-dev] strange bevahiour between three dependent Metacello configurations

by Dale Henrichs

Stef, Yeah I think so ... I've been running tests against Pharo4.0 for a while now[1] and the rate of change is pretty low, so picking up the latest version of Metacello from the master branch would be a good thing... Dale [1] https://travis-ci.org/dalehenrich/metacello-work On 03/15/2015 02:09 PM, stepharo wrote: > Dale should we load the latest version of Metacello for Pharo 40? > > Stef > > > Le 4/3/15 18:58, Dale Henrichs a Ã©crit : >> Stef, >> >> You can use the `get` command in the Metacello scripting api[1] to >> force a reload of a ConfigurationOf/BaselineOf. >> >> I don't think that the lastest version of Metacello is loaded into >> Pharo4.0/Pharo3.0 so you probably should explicitly load Metacello[2] >> (that'll work for Pharo4.0 and Pharo3.0) .... >> >> If you are going to use the Metacello scripting api, then you should >> be using the scripting api for loading as well ... the scripting API >> records the versions of projects that you've loaded into the image >> while the old way of loading calculates the loaded version which is >> slow and at times just plain wrong. >> >> Metacello new >> configuration: 'GlamourCore'; >> version: #development; >> get; >> load >> >> Refreshes the ConfigurationOfGlamourCore and then does the load. >> >> There is also a bit more documentation in the Metacello User Guide[3]... >> >> Dale >> >> [1] >> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr… >> [2] https://github.com/dalehenrich/metacello-work#pharo30 >> [3] >> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… >> >> On 03/04/2015 08:57 AM, Stefan Reichhart wrote: >>> Hi, >>> >>> We solved it but we could still need some help from you. >>> >>> Without using gofer to load/update metacello configurations >>> manually/explicitly, is there a way to force metacello to update >>> existing configurations to the very latest ones while metacello is >>> loading a configuration ? >>> >>> Example: >>> >>> The dependencies of the configurations is as follows: >>> ConfigurationOfGToolkitCore ---> ConfigurationOfGTInspectorCore + >>> ConfigurationOfGTPlaygroundCore + ConfigurationOfGTSpotter >>> ... >>> Whereas ConfigurationOfGTInspectorCore, >>> ConfigurationOfGTPlaygroundCore, ConfigurationOfGTSpotter are >>> already in a fresh Pharo 4 image (but outdated) >>> >>> Updating and loading "ConfigurationOfGToolkitCore" will only load >>> itself and the latest packages that are defined by the >>> configurations which are already in the image. But we would actually >>> like to update those configurations (and their packages) as well. >>> Otherwise the load would be "incomplete" (dependencies broken). >>> >>> Can Metacello do that ? Is there an easy way to do it ? Or is gofer >>> the only solution ? >>> >>> How do you handle configurations that depend on other configurations >>> (already loaded, but outdated) ? <-> Consistency of dependencies >>> >>> >>> Thanks >>> stef >>> >>> >>> ---------- >>> >>> >>> What we want is equivalent to the following snippet: >>> >>> { 'ConfigurationOfGToolkitCore'. 'ConfigurationOfGTInspectorCore'. >>> 'ConfigurationOfGTPlaygroundCore'. 'ConfigurationOfGTSpotter'. >>> 'ConfigurationOfGlamourCore'. 'ConfigurationOfRubricCore' } do: [ >>> :aConfigurationName | >>> Gofer new >>> smalltalkhubUser: 'Pharo' project: 'Pharo40Inbox'; >>> package: aConfigurationName; >>> load ]. >>> (ConfigurationOfGToolkitCore project version: #development) load. >>> >>> >>> >>> >>> Am 04/03/15 um 14:53 schrieb Andrei Chis: >>>> Hi, >>>> >>>> We fixed this but we are not sure if the behaviour that we got was a >>>> result of a bug or a feature in Metacello. >>>> >>>> Again our setup is that we have three configurations with linear >>>> dependencies between them: >>>> -- ConfigurationOfGTInspectorCore (2.0-baseline) >>>> -- ConfigurationOfGlamourCore (3.1-baseline) >>>> -- ConfigurationOfRubric (0.2-baseline) >>>> >>>> In ConfigurationOfRubric we had version "1.2.8" that uses >>>> '0.2-baseline'. >>>> >>>> The development version is '0.2-baseline' and the stable version >>>> '1.2.8' >>>> >>>> [1] (ConfigurationOfGlamourCore project version: #development) record >>>> loadDirective >>>> [2] (ConfigurationOfGTInspectorCore project version: #development) >>>> record loadDirective. >>>> >>>> When performing [1] Metacello decides to load Rubric. >>>> This because "MetacelloNullRecordingMCSpecLoader" uses the operator >>>> "=" >>>> (since none was specified before) to figure out whether something >>>> should >>>> be loaded. At a certain point this is executed: >>>> >>>> compareCurrentVersion:targetVersionStatus:using: (from above) >>>> ... >>>> ... >>>> ... >>>> ... >>>> #allLoadedToSpec = #allLoadedToSpec ===> TRUE >>>> "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline >>>> [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE >>>> ===> Rubric is not removed from the loader list >>>> >>>> When performing [2] Metacello decides not to load Rubric. >>>> In this case Metacello deals first with >>>> #ConfigurationOfGlamourCore. But >>>> after "GlamorCore" has been processed, the operator in the global >>>> mcLoader is set to ">=". All further specs-to-load >>>> (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". >>>> So now >>>> rubric get's removed: >>>> >>>> compareCurrentVersion:targetVersionStatus:using: (from above) >>>> ... >>>> ... >>>> ... >>>> ... >>>> #allLoadedToSpec >= #allLoadedToSpec ===> TRUE >>>> "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline >>>> [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE >>>> ===> Rubric is removed from the loader list >>>> >>>> That's why "Rubric" doesn't show up in the final loader list. The >>>> second >>>> (inner/nested) spec-to-load will remove it (after it has been >>>> successfully resolved by the previous nested configuration >>>> ConfigurationOfGlamourCore) because of the operator. >>>> >>>> So there is a difference between #ConfigurationOfGlamourCore and >>>> #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and >>>> loaded. >>>> >>>> Anybody else encountered this? >>>> >>>> Cheers, >>>> GT team >>>> >>>> >>>> >>>> >>>> On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis >>>> <chisvasileandrei(a)gmail.com >>>> <mailto:chisvasileandrei@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> We are having the following problem when trying to update >>>> GTolols to >>>> their latest version in the latest Pharo 4 image: Rubric does not >>>> get updated. >>>> We have: >>>> >>>> -- ConfigurationOfGTInspectorCore (2.0-baseline) >>>> -- ConfigurationOfGlamourCore (3.1-baseline) >>>> -- ConfigurationOfRubric (0.2-baseline) >>>> >>>> Performing [1] shows that rubric gets updated (atomic load : >>>> 0.2-baseline [ConfigurationOfRubric]) >>>> Performing [2] contains no trace of rubric. >>>> >>>> [1] (ConfigurationOfGlamourCore project version: #development) >>>> record loadDirective >>>> [2] (ConfigurationOfGTInspectorCore project version: >>>> #development) >>>> record loadDirective. >>>> >>>> Loading then the inspector [3] does not update Rubric. >>>> Loading just Glamour [4] updates it. >>>> >>>> [3] (ConfigurationOfGTInspectorCore project version: >>>> #development) load. >>>> [4] (ConfigurationOfGlamourCore project version: #development) >>>> load >>>> >>>> Any ideas or sugestions? Maybe we are missing something trivial. >>>> This updates the previous configurations to their latest versions: >>>> >>>> Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; >>>> package: 'ConfigurationOfGTInspectorCore'; load. >>>> Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; >>>> package: 'ConfigurationOfGlamourCore'; load. >>>> Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; >>>> package: 'ConfigurationOfRubric'; load. >>>> >>>> >>>> Cheers, >>>> Andrei >>>> >>>> >>> >> >> >> > >

March 16, 2015

[Pharo4] Please test Pharo4 *now*

by Marcus Denker

Hello, As every year: We can only fix what we know. And this means that no, just because *you* think that X and Y obviously needs to be fixed, it will only be fixed if a) there is an issue on the issue tracker b) someone fixes it. I should repeat: *Nothing*, even the most obvious or trivial, happens by itself. Marcus

March 16, 2015