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

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

by stepharo

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 15, 2015

Re: [Pharo-dev] Workspace and GTPlayground menu item

by stepharo

+1 Especially because I will start working on a mooc and videos and I would like to have a stable part. Stef Le 15/3/15 19:03, Nicolai Hess a Ã©crit : > Although it is difficult to find a agreement for this, I suggest > to add a menu entry "Playground" and reuse the entry "Workspace" for > the old workspace. > > Soon we will have a new Pharo release. And I am afraid there will be > some complaining > like this: > (Only on Workspace menu item that opens GTPlayground) > -> "Hey where is my workspace?" > > But instead I would like a > Workspace menu item opens Workspace / Playground opens GTPlayground: > and the feedback: > -> "Hey, GTPlayground is so cool" > > what do you think? > > > nicolai

March 15, 2015

ExtendedNumberParser now has its own repository

by stepharo

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?

March 15, 2015

Re: [Pharo-dev] [Pharo4] 203 issues tagged tagged for Pharo4

by stepharo

I will go over some and etiher fix or at least sort the non showstopper. Stef Le 15/3/15 11:40, Marcus Denker a Ã©crit : > Hi, > > We have 203 issues right now that have the Pharo4 Milestone: > > https://pharo.fogbugz.com/f/filters/103/4-0-All > > -> we need to go through that list and remove the tag for everything that is not > a show stopper. > -> if you know of an issue that is *not* on this list but should, please add the Pharo4 tag. > > Marcus > > > >

March 15, 2015

Re: [Pharo-dev] Workspace and GTPlayground menu item

by Tudor Girba

Hi, The Workspace is in the image. The only discussion is about the title of the menu item. When the Playground is enabled, the menu should show Playground instead of Workspace. And when the Workspace is enabled, it should show Workspace. The slice in this direction is on my to do list. Cheers, Doru On Sun, Mar 15, 2015 at 7:52 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Sun, Mar 15, 2015 at 7:03 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Although it is difficult to find a agreement for this, I suggest > > to add a menu entry "Playground" and reuse the entry "Workspace" for > > the old workspace. > > > > Soon we will have a new Pharo release. And I am afraid there will be some > > complaining > > like this: > > (Only on Workspace menu item that opens GTPlayground) > > -> "Hey where is my workspace?" > > > > But instead I would like a > > Workspace menu item opens Workspace / Playground opens GTPlayground: > > and the feedback: > > -> "Hey, GTPlayground is so cool" > > > > what do you think? > > I think that this is the way I want things to be in Pharo4. > > If we get the Playground only, I want a way to get the workspace as a > loadable configuration. > > Phil > > > > > > > nicolai > > -- www.tudorgirba.com "Every thing has its own flow"

March 15, 2015

Re: [Pharo-dev] [Vm-dev] Re: Status of Pharo VM for FreeBSD

by Andreas Wacknitz

Hi Eliot, as promised I checked what I did and found something I changed: The file platforms/unix/vm/sqUnixHeartbeat.c has the function void ioUpdateVMTimezone(). It was changed to something similar to what is in Cog's sqUnixITimerHeartbeat.c: void ioUpdateVMTimezone() { updateMicrosecondClock(); #ifdef HAVE_TM_GMTOFF time_t utctt; utctt = (get64(utcMicrosecondClock) - MicrosecondsFrom1901To1970) / MicrosecondsPerSecond; vmGMTOffset = localtime(&utctt)->tm_gmtoff * MicrosecondsPerSecond; #else # ifdef HAVE_TIMEZONE extern time_t timezone, altzone; extern int daylight; vmGMTOffset = -1 * (daylight ? altzone : timezone) * MicrosecondsPerSecond; # else # error "cannot determine timezone correction" # endif #endif } One thing is striking: the call to updateMicrosecondClock() is here before the #ifdef HAVE_TM_GMTOFF while in sqUnixITimerHeartbeat.c it is after the #ifdef. I don't know which one is correct (I may have copied it wrongly from sqUnixITimerHeartbeat). Albeit the one here seems to be correct in my eyes. What do you think? (Side note: As far as I remember Solaris does not have tm_gmtoff and thus the else part is being executed). Regards Andreas Am 14.03.15 18:33, schrieb Andreas Wacknitz: > Hi Eliot, > >> Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>>: >> >> HI Andreas, >> >> On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz(a)gmx.de >> <mailto:a.wacknitz@gmx.de>> wrote: >> >> >> Hi Clement, >> >>> Am 11.03.2015 um 09:23 schrieb ClÃ©ment Bera >>> <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: >>> >>> Hello, >>> >>> About the FreeBSD VM, Holger Freyther worked on it so he's the >>> best person to answer. I think some people used it and it was at >>> least partially working. >> Thatâs my impression. The VMMaker contains some FreeBSD classes >> but I have the impression that they are not complete (and >> probably outdated). >> >>> >>> About your NativeBoost bug on openSolaris, need more information: >>> >>> - Can you confirm that you use an intel processor on your >>> openSolaris machine ? I assume that yes but I ask because >>> solaris were typically running on other processors. NativeBoost, >>> as of today, works only with intel processor. >>> >> Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300). >> >>> - Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or >>> PharoSVMBuild ? I think the PharoSVMBuild does not include >>> NativeBoost by default, that may be your problem. There's a fix >>> somewhere... >>> >> PharoVM from "branch 'master' of >> https://github.com/pharo-project/pharo-vm" (thus Cog VM). >> >> >> I would like to fold back any changes into the svn master repository >> for Cog. What are the diffs? (If you have time to send me the >> diffs that would save me a lot of time). > I donât know whether there is much to harvest from what I did. As far > as I remember most of my work was hacking the generator image created > by the pharo vm scripts (for my Mac) in order to make > the resulting C code to compile under openindiana. The basis for > Solaris was already there (and as far as I can see it is also in the > Squeak VM sources). I only tweaked some definitions and includes. > I will look at my notes tomorrow and will post if I will find > something relevant. > > I am curios about the future of the PharoVM. The main development of > the VM seem to happen in the SqueakVM (by you). Getting the Spur > changes into the PharoVM seem to be a lot of work. > Wouldnât it be better to move back the changes of the PharoVM into the > SqueakVM and have a united development? > And what is the status and what are the plans regarding Timothyâs > (gettimothy) work? > > Regards > Andreas >

March 15, 2015

Re: [Pharo-dev] Workspace and GTPlayground menu item

by phil＠highoctane.be

On Sun, Mar 15, 2015 at 7:03 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Although it is difficult to find a agreement for this, I suggest > to add a menu entry "Playground" and reuse the entry "Workspace" for > the old workspace. > > Soon we will have a new Pharo release. And I am afraid there will be some > complaining > like this: > (Only on Workspace menu item that opens GTPlayground) > -> "Hey where is my workspace?" > > But instead I would like a > Workspace menu item opens Workspace / Playground opens GTPlayground: > and the feedback: > -> "Hey, GTPlayground is so cool" > > what do you think? I think that this is the way I want things to be in Pharo4. If we get the Playground only, I want a way to get the workspace as a loadable configuration. Phil > > > nicolai

March 15, 2015

Re: [Pharo-dev] Workspace and GTPlayground menu item

by Peter UhnÃ¡k

I think that there could be confusion about whether Playground is actually Workspace... so why not name the item in world menu as "Workspace / Playground", so it's obvious it is both? Also don't forget that there is keyboard shortcut which now opens Playground instead of Workspace; so some amount of confusion will probably happen anyway. Or maybe have a way to inform the user about the new changes... so maybe a new world menu entry "Pharo 4.0 news/changes/whatever"? Or just put some release notes on Pharo.org. If someone opens new MAJOR release then changes and BC breaks are to be expected, otherwise what would be the point of a major release. Peter On Sun, Mar 15, 2015 at 7:03 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Although it is difficult to find a agreement for this, I suggest > to add a menu entry "Playground" and reuse the entry "Workspace" for > the old workspace. > > Soon we will have a new Pharo release. And I am afraid there will be some > complaining > like this: > (Only on Workspace menu item that opens GTPlayground) > -> "Hey where is my workspace?" > > But instead I would like a > Workspace menu item opens Workspace / Playground opens GTPlayground: > and the feedback: > -> "Hey, GTPlayground is so cool" > > what do you think? > > > nicolai >

March 15, 2015

Workspace and GTPlayground menu item

by Nicolai Hess

Although it is difficult to find a agreement for this, I suggest to add a menu entry "Playground" and reuse the entry "Workspace" for the old workspace. Soon we will have a new Pharo release. And I am afraid there will be some complaining like this: (Only on Workspace menu item that opens GTPlayground) -> "Hey where is my workspace?" But instead I would like a Workspace menu item opens Workspace / Playground opens GTPlayground: and the feedback: -> "Hey, GTPlayground is so cool" what do you think? nicolai

March 15, 2015

Re: [Pharo-dev] [OT]: Fwd: Why GSoC? Why me?

by Sean P. DeNigris

> I meant things like [2] which could be embedded directly. > Also, [4] is something that you can link to. > The 'Ideas for research' could all be links as well. > I cannot find [1] in the text itself. > You could also add some (relevant or just nice) pictures. Thanks, I fixed all except the pics... no time right now :/ ----- Cheers, Sean -- View this message in context: http://forum.world.st/OT-Fwd-Why-GSoC-Why-me-tp4811878p4812074.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 15, 2015