- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Voyage cannot be load

by Norbert Hartl

Ok, I can load my own project now when I exchange the grease reference from 1.1.5 to stable. After a hint from Stephan Eggermont I changed the mongotalk build to include the right repo for grease. So this mismatch should have been gone. While Iâm able to build my own project I still cannot load voyage in a fresh 2.0 image. Norbert Am 20.03.2014 um 16:39 schrieb Johan Brichau <johan(a)inceptive.be>: > Norbert, > > From your screenshot, I see that the Grease package you have loaded in your image is dirty. It is also the package version that gets loaded with Grease 1.1.5. > My first question is: why is it dirty? Can you check that? > > The package version you are loading is the one that is referenced by Grease 1.1.6 > > I just tagged Grease 1.1.6 as #stable yesterday. So that probably triggers this. > > Though I cannot see any reason why this occurs and Seaside 3.1 is loading well here. > > Johan > > On 20 Mar 2014, at 15:47, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I encountered a strange problem while loading voyage. It seems the configuration for magritte or grease is strange. If I load voyage from the configuration browser I get the following screen >> >> <Bildschirmfoto 2014-03-20 um 15.43.56.png> >> >> Any ideas? >> >> Norbert >>

March 20, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Eliot Miranda

On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi Eliot, > > Le 19 mars 2014 Ã 16:25, Eliot Miranda a Ã©crit : > > Hi Christophe, > > On Mar 19, 2014, at 1:45 AM, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > > > Le 18 mars 2014 Ã 19:50, Eliot Miranda a Ã©crit : > > On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> Why arguments should be read only? >> They are just temporary variables with an initial value. >> > > Read the blue book. It was a decision of the language designers to forbid > assignment to arguments to allow debugging. The assignment to block > arguments is a side-effect of the old BlockContext implementation of blocks > where block arguments were mapped onto temporary variables of the home > context. It is an anachronism and should be forbidden also. > > > Thank you for the explanation. > I'm just curious why it is so difficult to implement a debugger if > arguments are assignable? > If you need to restart the execution of a method, and so you need to get > the initial value of the argument, I understand you cannot find the value > anymore in the method context but it is available in the caller context, no? > As I never implemented a debugger, I cannot figure out the difficulties. > > > the args are no longer available; they get moved from the caller context > to the callee. If you think about stack frames then what happens is that > the slots containing the outgoing arguments are used as the slots for the incoming > arguments. So if arguments are assigned to they are indeed lost. > > > ok, I understand. Thank you for the explanation. > > > But look at how many methods in the system (or in any system). The > proportion of methods/functions/procedures that could be written to assign > their arguments is very small so the Smalltalk trade off is a good one. > > > I agree we don't really loose something. You can always assign arguments > to temporary variables and update temporary variables. My point was just: > if possible, why don't do it? > It's that tricky trade-off between value and cost. Is it worth it? Does doing it provide as much value as doing what it displaces (opportunity cost). IMO it simply doesn't provide enough value, and there are different priorities in the compiler. But if you disagree implement it your self and then it'll be done. -- best, Eliot

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Johan Brichau

I can reproduce the problem. For some strange reason, first Grease 1.1.5 is loaded and then 1.1.6 is loaded (in the same metacello load of VoyageMongo). The package becomes dirty because some classes changed from the Pharo20 package in 1.1.5 to the Core package in 1.1.6. Because Metacello first loads the Core package, the Pharo20 package becomes dirty. When the new version of the Pharo20 package is loaded, Monticello raises the warning. I have noticed a similar issue when upgrading versions of Zinc in Pharo1.4 because significant package refactorings occurred. So, this is nothing specific to Grease / Magritte / Seaside / ... I wonder if this can be simply fixed by changing the load type to #atomic. At least, that is how I fix those issues when loading Yesplan in Gemstone. But clean builds work perfectly. And I would want to know why first version 1.1.5 is loaded in this load process. Johan On 20 Mar 2014, at 16:39, Johan Brichau <johan(a)inceptive.be> wrote: > Norbert, > > From your screenshot, I see that the Grease package you have loaded in your image is dirty. It is also the package version that gets loaded with Grease 1.1.5. > My first question is: why is it dirty? Can you check that? > > The package version you are loading is the one that is referenced by Grease 1.1.6 > > I just tagged Grease 1.1.6 as #stable yesterday. So that probably triggers this. > > Though I cannot see any reason why this occurs and Seaside 3.1 is loading well here. > > Johan > > On 20 Mar 2014, at 15:47, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I encountered a strange problem while loading voyage. It seems the configuration for magritte or grease is strange. If I load voyage from the configuration browser I get the following screen >> >> <Bildschirmfoto 2014-03-20 um 15.43.56.png> >> >> Any ideas? >> >> Norbert >> >

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Norbert Hartl

Am 20.03.2014 um 16:39 schrieb Johan Brichau <johan(a)inceptive.be>: > Norbert, > > From your screenshot, I see that the Grease package you have loaded in your image is dirty. It is also the package version that gets loaded with Grease 1.1.5. > My first question is: why is it dirty? Can you check that? > > The package version you are loading is the one that is referenced by Grease 1.1.6 > > I just tagged Grease 1.1.6 as #stable yesterday. So that probably triggers this. > > Though I cannot see any reason why this occurs and Seaside 3.1 is loading well here. > Me neither. The screenshot is from a an image that I downloaded freshly and used the configuration browser to initiate the load. I can see a reference to 1.1.5 grease as well but Iâm not sure where this comes from. Every configuration involved just references grease #stable. Norbert > Johan > > On 20 Mar 2014, at 15:47, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I encountered a strange problem while loading voyage. It seems the configuration for magritte or grease is strange. If I load voyage from the configuration browser I get the following screen >> >> <Bildschirmfoto 2014-03-20 um 15.43.56.png> >> >> Any ideas? >> >> Norbert >>

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Johan Brichau

Norbert, >From your screenshot, I see that the Grease package you have loaded in your image is dirty. It is also the package version that gets loaded with Grease 1.1.5. My first question is: why is it dirty? Can you check that? The package version you are loading is the one that is referenced by Grease 1.1.6 I just tagged Grease 1.1.6 as #stable yesterday. So that probably triggers this. Though I cannot see any reason why this occurs and Seaside 3.1 is loading well here. Johan On 20 Mar 2014, at 15:47, Norbert Hartl <norbert(a)hartl.name> wrote: > I encountered a strange problem while loading voyage. It seems the configuration for magritte or grease is strange. If I load voyage from the configuration browser I get the following screen > > <Bildschirmfoto 2014-03-20 um 15.43.56.png> > > Any ideas? > > Norbert >

March 20, 2014

Re: [Pharo-dev] SmalllineManifestCheckerTest class >> DoIt

by Marcus Denker

On 20 Mar 2014, at 16:27, Ben Coman <btc(a)openInWorld.com> wrote: > Can anyone tell me how the following fits into the system? > > SmalllineManifestCheckerTest class >> DoIt > ^ MCWorkingCopy > managersForClass: MFClassA > do: [:p | ^ p first] > > Its currently "unclassified" and I need to fix that to submit a slice that otherwise doesn't touch this. > To me it looks like the method should just be deleted. DoIt is the selector of the methods generated for dots, but they are never installed in any class. Marcus

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Esteban Lorenzano

Mmmâ¦ Iâm loading it without problems. At least it was compatible until last week. Esteban On 20 Mar 2014, at 16:26, Stephan Eggermont <stephan(a)stack.nl> wrote: > Mongotalk configuration is not Pharo 3 compatible >

March 20, 2014

Re: [Pharo-dev] Nautilus keyboard behavior

by Benjamin

On 20 Mar 2014, at 15:48, Stephan Eggermont <stephan(a)stack.nl> wrote: > 13100 triggered me to take a look at keyboard based navigation > in Nautilus. These should probably be a number of different issues. > > There seems to be no way to get from the text pane back to > methods-categories-classes-packages , both tab and right-arrow > are captured. > cmd+crt+left/right arrow > How do I open the menu on one of the top panes in Nautilus? Do you need menu when you have shortcut for menu items? Can you give me example of application where one can open a contextual menu whiteout the mouse (in OSX you cannot). > How do I open the History navigator? By tabbing to it and pressing arrow down? > Iâd expect groups and hierarchy to be selectable with a key combination > when the packages pane is selected. They are Ben

March 20, 2014

SmalllineManifestCheckerTest class >> DoIt

by Ben Coman

Can anyone tell me how the following fits into the system? SmalllineManifestCheckerTest class >> DoIt ^ MCWorkingCopy managersForClass: MFClassA do: [:p | ^ p first] Its currently "unclassified" and I need to fix that to submit a slice that otherwise doesn't touch this. cheers -ben

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Stephan Eggermont

Mongotalk configuration is not Pharo 3 compatible

March 20, 2014