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

Re: [Pharo-dev] Voyage cannot be load

by Pharo4Stef

>> > I know. I would wish we would stop having metacello versions that contain dependencies to symbolic versions. A tool like versionner should rewrite every symbolic version to a number version when producing a release. Indeed! Christophe is working on that. Release should not be symbolic! Stef

March 21, 2014

Re: [Pharo-dev] Nautilus: plugins, PackageTreePackageSelection, PackageTreeTagSelectop, promote, tags, ...

by phil＠highoctane.be

Furthering the investigation: With groups, plugins are not working at all as package doesn't exist in DynamicClassGroup etc. I fixed the plugin I was interested in but this makes for strange code as: >>packageSelected: anAnnouncement | package name | (anAnnouncement respondsTo: #package) ifTrue: [ ... This is because the announcement comes for a package which is not one. even if one has registered it with: registerTo: aModel aModel announcer on: NautilusPackageSelected send: #packageSelected: to: self Maybe should we have other announcements for these specific items like DynamicClassGroup (e.g. DynamicClassGroupSelected announcement) I have made a little plugin to help me explore the selected classes in the left most list. Also adding RPackage>>package ^self helps with package selected code as without it it is hard to write: package node item package for both PackageTreeTagSelection and PackageTreePackageSelection This makes the TasksPlugin code like; packageSelected: anAnnouncement | package | (anAnnouncement respondsTo: #package) ifTrue: [ package := anAnnouncement package. package ifNil: [ tasks removeAll ] ifNotNil: [ (package node item respondsTo: #package) ifTrue: [ tasks := (self systemNavigation allCallsOn: 'flag:' asSymbol) select: [ :m | package node item package includesMethod: m selector ofClass: m methodClass ] ]. ]. ] ifFalse: [ tasks removeAll. ]. self changed: #tasks. Maybe can we get this leaner with the proposed changes to the announcements. Phil On Fri, Mar 21, 2014 at 7:12 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > I have been looking at Nautilus plugins as I wanted to be able to export > some classes to other formats (e.g. CSV, XML for use with other tools). > > Then, I started playing around with the URLPlugin with its buildString > method, which proves helpful to find out about what is selected in the > 'list2'. > > So, that's where I started drilling down the rabbit hole... > > So, I see that we have packages and package tags. And actions like promote > as true package and demote (which kind of doesn't work and crashes, but I > should test further). > > One thing is that this setup breaks the PackageTasks plugin is broken at > this point. > > We have: > >>packageSelected: anAnnouncement > package := anAnnouncement package. > ... > tasks := (self systemNavigation allCallsOn: 'flag:' asSymbol) select: [ :m > | package includesMethod: m selector ofClass: m methodClass ] ] > > But with the packages and tags, it doesn't work. > > In fact, package is misleading as the announcement contains a > PackageTreePackageSelection or a PackageTreeTagSelection. > > Question: how is one filtering on either the package or a given tag? Is > this possible? > I saw the >>node and node>>item things. > > I was trying to build the full path (Like "Nautilus-Plugin" from what is > selected in the model). > Question; Is there any method for doing that at this point? (e.g. fullTag?) > > Then I tried this: > > Object subclass: #XXXX > instanceVariableNames: '' > classVariableNames: '' > category: 'Nautilus-Nautilus' > > This gets XXXX mixed with the classes in Nautilus under the Nautilus > package in the Nautilus tag. > > So, a tag class is mixed with the root package. Not nice. > > What's the underlying model? Is there a doc somewhere? > > Going back to the digging... > > TIA > Phil >

March 21, 2014

Re: [Pharo-dev] An attempt to use interactive tools detected, while in non-interactive mode

by Johan Brichau

Please see the thread "Voyage cannot be load" Johan > On 21 Mar 2014, at 18:23, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > On Thu, Mar 20, 2014 at 4:02 AM, Sebastian Sastre > <sebastian(a)flowingconcept.com> wrote: >> my Pharo 3.0 staging builds started to fail today and this seems to be >> involved. > > > I confirm the problem: > > https://ci.inria.fr/pharo-contribution/job/Pier3/PHARO=20,VERSION=developme… > > -- > 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

Nautilus: plugins, PackageTreePackageSelection, PackageTreeTagSelectop, promote, tags, ...

by phil＠highoctane.be

I have been looking at Nautilus plugins as I wanted to be able to export some classes to other formats (e.g. CSV, XML for use with other tools). Then, I started playing around with the URLPlugin with its buildString method, which proves helpful to find out about what is selected in the 'list2'. So, that's where I started drilling down the rabbit hole... So, I see that we have packages and package tags. And actions like promote as true package and demote (which kind of doesn't work and crashes, but I should test further). One thing is that this setup breaks the PackageTasks plugin is broken at this point. We have: >>packageSelected: anAnnouncement package := anAnnouncement package. ... tasks := (self systemNavigation allCallsOn: 'flag:' asSymbol) select: [ :m | package includesMethod: m selector ofClass: m methodClass ] ] But with the packages and tags, it doesn't work. In fact, package is misleading as the announcement contains a PackageTreePackageSelection or a PackageTreeTagSelection. Question: how is one filtering on either the package or a given tag? Is this possible? I saw the >>node and node>>item things. I was trying to build the full path (Like "Nautilus-Plugin" from what is selected in the model). Question; Is there any method for doing that at this point? (e.g. fullTag?) Then I tried this: Object subclass: #XXXX instanceVariableNames: '' classVariableNames: '' category: 'Nautilus-Nautilus' This gets XXXX mixed with the classes in Nautilus under the Nautilus package in the Nautilus tag. So, a tag class is mixed with the root package. Not nice. What's the underlying model? Is there a doc somewhere? Going back to the digging... TIA Phil

March 21, 2014

Re: [Pharo-dev] An attempt to use interactive tools detected, while in non-interactive mode

by Damien Cassou

On Thu, Mar 20, 2014 at 4:02 AM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > my Pharo 3.0 staging builds started to fail today and this seems to be > involved. I confirm the problem: https://ci.inria.fr/pharo-contribution/job/Pier3/PHARO=20,VERSION=developme… -- 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] 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