- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo on Debian 7

by Damien Cassou

On Thu, Mar 20, 2014 at 10:16 PM, jannik laval <jannik.laval(a)gmail.com> wrote: > Ok, any solution ? or deb package ? http://files.pharo.org/vm/pharo/linux/debian_ubuntu/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

March 21, 2014

Re: [Pharo-dev] Voyage cannot be load

by Norbert Hartl

Am 21.03.2014 um 15:57 schrieb Johan Brichau <johan(a)inceptive.be>: > It can be something to try indeed. > > Though I believe we all need to move on to using the Metacello scripting API too. That allows the end-user to control what happens with version upgrades, conflicts etc.. > Though there are issues with it too, I have been using it for over a year already to prevent pulling in inadvertent version upgrades. > > And, btw, all this would not solve the current problem... > Right. Only atomic loading can solve this. Norbert > Johan > >> On 21 Mar 2014, at 15:24, Diego Lont <diego.lont(a)delware.nl> wrote: >> >> Hi all, >> >> Recently we had a lot of trouble, because Seaside upgraded its stable version from 2.8 to 3.0. This caused a lot of configurations not to load properly anymore, because #stable was referenced in a lot of release version. >> >> In reaction to that, I advocated to replace references to #stable to specific versions. Downstream configurations should not break if a configuration it depends on upgrades its stable version. Not all projects have adopted this policy, so that is the source of the configuration mismatch. >> >> We also have a different problem, that we used to solve by using #stable. Minor releases, included bug fixes, should be automatically be pulled over in the configurations downstream. So my solution was probably too much cutting corners. >> >> To solve this, I think we should introduce a new symbolic version for projects that are used a lot. For seaside this would mean defining the following versions: >> #stable28 >> #stable30 >> #stable31 >> These versions should be used when referencing to seaside, as #stable was clear too coarse grained. You do not want a major version upgrade in a dependent configuration, as this can lead to a lot of trouble, but you do want minor changes (patches) pulled in automatically. >> >> If people agree this is a good idea, I will add these versions to Seaside and add the versions #stable10 and #stable11 to grease, and update the downstream configurations that I am allowed to changed. I should have time for this somewhere next week. I will also add the versions #stable30 and #stable31 to Magritte3 >> >> Regards, >> Diego >> >>> On 21 Mar 2014, at 14:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> adding: >>> >>> ConfigurationOfGrease>>#stable: spec >>> <symbolicVersion: #'stable'> >>> >>> spec for: #'common' version: '1.1.6'. >>> spec for: #'pharo2.x' version: '1.1.5' >>> >>> makes voyage *and* seaside load fine in pharo2.0. >> >> I do not think this is a good idea. The problem is that 2 different references to grease exist. These should all correspond to the same version. >> >> >

March 21, 2014

Re: [Pharo-dev] Voyage cannot be load

by Johan Brichau

It can be something to try indeed. Though I believe we all need to move on to using the Metacello scripting API too. That allows the end-user to control what happens with version upgrades, conflicts etc.. Though there are issues with it too, I have been using it for over a year already to prevent pulling in inadvertent version upgrades. And, btw, all this would not solve the current problem... Johan > On 21 Mar 2014, at 15:24, Diego Lont <diego.lont(a)delware.nl> wrote: > > Hi all, > > Recently we had a lot of trouble, because Seaside upgraded its stable version from 2.8 to 3.0. This caused a lot of configurations not to load properly anymore, because #stable was referenced in a lot of release version. > > In reaction to that, I advocated to replace references to #stable to specific versions. Downstream configurations should not break if a configuration it depends on upgrades its stable version. Not all projects have adopted this policy, so that is the source of the configuration mismatch. > > We also have a different problem, that we used to solve by using #stable. Minor releases, included bug fixes, should be automatically be pulled over in the configurations downstream. So my solution was probably too much cutting corners. > > To solve this, I think we should introduce a new symbolic version for projects that are used a lot. For seaside this would mean defining the following versions: > #stable28 > #stable30 > #stable31 > These versions should be used when referencing to seaside, as #stable was clear too coarse grained. You do not want a major version upgrade in a dependent configuration, as this can lead to a lot of trouble, but you do want minor changes (patches) pulled in automatically. > > If people agree this is a good idea, I will add these versions to Seaside and add the versions #stable10 and #stable11 to grease, and update the downstream configurations that I am allowed to changed. I should have time for this somewhere next week. I will also add the versions #stable30 and #stable31 to Magritte3 > > Regards, > Diego > >> On 21 Mar 2014, at 14:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> adding: >> >> ConfigurationOfGrease>>#stable: spec >> <symbolicVersion: #'stable'> >> >> spec for: #'common' version: '1.1.6'. >> spec for: #'pharo2.x' version: '1.1.5' >> >> makes voyage *and* seaside load fine in pharo2.0. > > I do not think this is a good idea. The problem is that 2 different references to grease exist. These should all correspond to the same version. > >

March 21, 2014

Re: [Pharo-dev] Voyage cannot be load

by Ben Coman

March 21, 2014

Re: [Pharo-dev] Voyage cannot be load

by Johan Brichau

Ok, so you suggest to leave out latest bug fixes to Grease from Pharo 2? The problem is elsewhere and this is just hacking around that. Johan > On 21 Mar 2014, at 15:41, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 21 Mar 2014, at 15:37, Johan Brichau <johan(a)inceptive.be> wrote: >> >> Yes, but that is incorrect and just a workaround to not load the latest version in Pharo 2. >> 1.1.6 is also intended for Pharo2! > > why? > >> >> Johan >> >>> On 21 Mar 2014, at 14:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> adding: >>> >>> ConfigurationOfGrease>>#stable: spec >>> <symbolicVersion: #'stable'> >>> >>> spec for: #'common' version: '1.1.6'. >>> spec for: #'pharo2.x' version: '1.1.5' >>> >>> makes voyage *and* seaside load fine in pharo2.0. >>> >>> Esteban >>> >>> >>> >>> >>>> On 21 Mar 2014, at 13:37, Johan Brichau <johan(a)inceptive.be> wrote: >>>> >>>> >>>> >>>>>> If both configurations reference the same Grease version, there will not be a problem. >>>>>> >>>>> Can you do that? I donât have commit rights for those repos. >>>> >>>> No, I am not an author of either projects.... I guess it's best if Magritte references Grease #stable. Though I concur with your remark regarding symbolic versions, it also becomes hell if different projects reference different versions of Grease, just because those were the stable versions when they were created (which is actually the problem here). >>>> >>>> I'm on iPad only right now, so can't help you any further before tonight. >>>> >>>>>> However, this is a more fundamental problem. Metacello first loads 1.1.5 and then loads 1.1.6, which has moved classes between packages, leading to a temporary (i.e. during load) dirty package, leading to the Monticello warning. >>>>>> >>>>>> You can also try to change the metacello loadType to #atomic instead of #linear. >>>>>> Finally, you can also wrap an exception handler around the load statement. >>>>>> >>>>> Yeah, I wanted to do that. But then I changed my workflow to use zero conf scripts and that whole problem handling you loose by using the âmodernâ workflow. >>>> >>>> I also wonder if the Metacello scripting API has a handler for this situation (i.e. suppressing errors) >>>> >>>> >>>>> >>>>> Norbert >>>>> >>>>>> Johan >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>>> On 21 Mar 2014, at 09:20, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>>>> >>>>>>> What should be changed in order to solve it? >>>>>>> >>>>>>> Norbert >>>>>>> >>>>>>>> Am 20.03.2014 um 17:09 schrieb Johan Brichau <johan(a)inceptive.be>: >>>>>>>> >>>>>>>> Found it: >>>>>>>> >>>>>>>> Magritte3 references Grease1.1.5 explicitly >>>>>>>> MongoTalk references Grease #stable >>>>>>>> >>>>>>>> Looks more like a Metacello bug to me... there clearly is a load conflict and Metacello should decide on a version rather than load them both sequentially. >>>>>>>> But I have not looked any deeper.... >>>>>>>> >>>>>>>> Johan >>>>>>>> >>>>>>>>> On 20 Mar 2014, at 17:02, Johan Brichau <johan(a)inceptive.be> wrote: >>>>>>>>> >>>>>>>>> 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 21, 2014

Re: [Pharo-dev] Voyage cannot be load

by Esteban Lorenzano

On 21 Mar 2014, at 15:37, Johan Brichau <johan(a)inceptive.be> wrote: > Yes, but that is incorrect and just a workaround to not load the latest version in Pharo 2. > 1.1.6 is also intended for Pharo2! why? > > Johan > >> On 21 Mar 2014, at 14:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> adding: >> >> ConfigurationOfGrease>>#stable: spec >> <symbolicVersion: #'stable'> >> >> spec for: #'common' version: '1.1.6'. >> spec for: #'pharo2.x' version: '1.1.5' >> >> makes voyage *and* seaside load fine in pharo2.0. >> >> Esteban >> >> >> >> >>> On 21 Mar 2014, at 13:37, Johan Brichau <johan(a)inceptive.be> wrote: >>> >>> >>> >>>>> If both configurations reference the same Grease version, there will not be a problem. >>>>> >>>> Can you do that? I donât have commit rights for those repos. >>> >>> No, I am not an author of either projects.... I guess it's best if Magritte references Grease #stable. Though I concur with your remark regarding symbolic versions, it also becomes hell if different projects reference different versions of Grease, just because those were the stable versions when they were created (which is actually the problem here). >>> >>> I'm on iPad only right now, so can't help you any further before tonight. >>> >>>>> However, this is a more fundamental problem. Metacello first loads 1.1.5 and then loads 1.1.6, which has moved classes between packages, leading to a temporary (i.e. during load) dirty package, leading to the Monticello warning. >>>>> >>>>> You can also try to change the metacello loadType to #atomic instead of #linear. >>>>> Finally, you can also wrap an exception handler around the load statement. >>>>> >>>> Yeah, I wanted to do that. But then I changed my workflow to use zero conf scripts and that whole problem handling you loose by using the âmodernâ workflow. >>> >>> I also wonder if the Metacello scripting API has a handler for this situation (i.e. suppressing errors) >>> >>> >>>> >>>> Norbert >>>> >>>>> Johan >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On 21 Mar 2014, at 09:20, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>>> >>>>>> What should be changed in order to solve it? >>>>>> >>>>>> Norbert >>>>>> >>>>>>> Am 20.03.2014 um 17:09 schrieb Johan Brichau <johan(a)inceptive.be>: >>>>>>> >>>>>>> Found it: >>>>>>> >>>>>>> Magritte3 references Grease1.1.5 explicitly >>>>>>> MongoTalk references Grease #stable >>>>>>> >>>>>>> Looks more like a Metacello bug to me... there clearly is a load conflict and Metacello should decide on a version rather than load them both sequentially. >>>>>>> But I have not looked any deeper.... >>>>>>> >>>>>>> Johan >>>>>>> >>>>>>>> On 20 Mar 2014, at 17:02, Johan Brichau <johan(a)inceptive.be> wrote: >>>>>>>> >>>>>>>> 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 21, 2014

Re: [Pharo-dev] Voyage cannot be load

by Johan Brichau

Yes, but that is incorrect and just a workaround to not load the latest version in Pharo 2. 1.1.6 is also intended for Pharo2! Johan > On 21 Mar 2014, at 14:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > adding: > > ConfigurationOfGrease>>#stable: spec > <symbolicVersion: #'stable'> > > spec for: #'common' version: '1.1.6'. > spec for: #'pharo2.x' version: '1.1.5' > > makes voyage *and* seaside load fine in pharo2.0. > > Esteban > > > > >> On 21 Mar 2014, at 13:37, Johan Brichau <johan(a)inceptive.be> wrote: >> >> >> >>>> If both configurations reference the same Grease version, there will not be a problem. >>>> >>> Can you do that? I donât have commit rights for those repos. >> >> No, I am not an author of either projects.... I guess it's best if Magritte references Grease #stable. Though I concur with your remark regarding symbolic versions, it also becomes hell if different projects reference different versions of Grease, just because those were the stable versions when they were created (which is actually the problem here). >> >> I'm on iPad only right now, so can't help you any further before tonight. >> >>>> However, this is a more fundamental problem. Metacello first loads 1.1.5 and then loads 1.1.6, which has moved classes between packages, leading to a temporary (i.e. during load) dirty package, leading to the Monticello warning. >>>> >>>> You can also try to change the metacello loadType to #atomic instead of #linear. >>>> Finally, you can also wrap an exception handler around the load statement. >>>> >>> Yeah, I wanted to do that. But then I changed my workflow to use zero conf scripts and that whole problem handling you loose by using the âmodernâ workflow. >> >> I also wonder if the Metacello scripting API has a handler for this situation (i.e. suppressing errors) >> >> >>> >>> Norbert >>> >>>> Johan >>>> >>>> Sent from my iPad >>>> >>>>> On 21 Mar 2014, at 09:20, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> >>>>> What should be changed in order to solve it? >>>>> >>>>> Norbert >>>>> >>>>>> Am 20.03.2014 um 17:09 schrieb Johan Brichau <johan(a)inceptive.be>: >>>>>> >>>>>> Found it: >>>>>> >>>>>> Magritte3 references Grease1.1.5 explicitly >>>>>> MongoTalk references Grease #stable >>>>>> >>>>>> Looks more like a Metacello bug to me... there clearly is a load conflict and Metacello should decide on a version rather than load them both sequentially. >>>>>> But I have not looked any deeper.... >>>>>> >>>>>> Johan >>>>>> >>>>>>> On 20 Mar 2014, at 17:02, Johan Brichau <johan(a)inceptive.be> wrote: >>>>>>> >>>>>>> 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 21, 2014

Debugger acting up

by Diego Lont

Hi all, I do not have a proper test case yet, but as I have seen it twice now I want to ask you guys if you have any problems with it. In a recent moose 5.0 image with seaside and some other suff loaded, the page would not load. Interrupting the image showed that the debugger was lost in the following loop: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: Originally it was a halt that caused the signal, and that should pop up the debugger, but instead of that it went into an infinite loop. Now I see that building Pier3 development on a pharo2 image also seems to causes this loop. The root cause is also in the mail, so maybe this is just the size of the stack ...: Startup Error: An attempt to use interactive tools detected, while in non-interactive mode Interactive Request: You are about to load new versions of the following packages that have unsaved changes in the image: Grease-Tests-Pharo20-Core If you continue, you will lose these changes: [0mNonInteractiveUIManager>>nonInteractiveWarning: NonInteractiveUIManager>>nonInteractiveRequest:title: NonInteractiveUIManager>>nonInteractiveRequest: NonInteractiveUIManager>>confirm:trueChoice:falseChoice:cancelChoice:default: MCMergeOrLoadWarning>>defaultAction UndefinedObject>>handleSignal: If anyone knows where this problem might come from, please put a mail on the mailing list. Cheers, Diego

March 21, 2014

Re: [Pharo-dev] Voyage cannot be load

by Diego Lont

Hi all, Recently we had a lot of trouble, because Seaside upgraded its stable version from 2.8 to 3.0. This caused a lot of configurations not to load properly anymore, because #stable was referenced in a lot of release version. In reaction to that, I advocated to replace references to #stable to specific versions. Downstream configurations should not break if a configuration it depends on upgrades its stable version. Not all projects have adopted this policy, so that is the source of the configuration mismatch. We also have a different problem, that we used to solve by using #stable. Minor releases, included bug fixes, should be automatically be pulled over in the configurations downstream. So my solution was probably too much cutting corners. To solve this, I think we should introduce a new symbolic version for projects that are used a lot. For seaside this would mean defining the following versions: #stable28 #stable30 #stable31 These versions should be used when referencing to seaside, as #stable was clear too coarse grained. You do not want a major version upgrade in a dependent configuration, as this can lead to a lot of trouble, but you do want minor changes (patches) pulled in automatically. If people agree this is a good idea, I will add these versions to Seaside and add the versions #stable10 and #stable11 to grease, and update the downstream configurations that I am allowed to changed. I should have time for this somewhere next week. I will also add the versions #stable30 and #stable31 to Magritte3 Regards, Diego On 21 Mar 2014, at 14:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > adding: > > ConfigurationOfGrease>>#stable: spec > <symbolicVersion: #'stable'> > > spec for: #'common' version: '1.1.6'. > spec for: #'pharo2.x' version: '1.1.5' > > makes voyage *and* seaside load fine in pharo2.0. I do not think this is a good idea. The problem is that 2 different references to grease exist. These should all correspond to the same version.

March 21, 2014

Bug in Rectangle?

by Noury Bouraqadi

Inverting the origin and the corner of a rectangle changes the result of intersection. I guess it's a bug, though I imagine that changing the code of Rectangle is likely to have deep/undesired consequences.. (0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false !!!! Noury

March 21, 2014