In case you didn't notice, the Pier job is broken for a few days now:
https://ci.inria.fr/pharo-contribution/job/Pier3/?
It looks related to Grease and there has been a discussion about a
similar problem in the "Voyage cannot be load" thread of the Pharo
mailing list. I don't know what to do and don't have time to look at
it.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill
Hi,
It looks to me that this:
MAListMorph>>#strings
^ self options collect: [ :each | self magritteDescription reference toString: each ]
should instead be:
MAListMorph>>#strings
^ self options collect: [ :each | self magritteDescription displayStringFor: each ]
what do you think?
Esteban
All - It seems that the page table of contents (value:toc) hasn't worked for a while - the problem can be resolved by updating this method:
PRValueLink>>tocIn: aContext
<value: 'toc' comment: 'Display the table of contents of the current structure.'>
^ self lookupStructure: aContext structure do: [ :structure | [ :html |
PRTocRenderer new
start: structure
in: html painter
on: html ] ]
Instead of html painter, use self.
How would one go about making this update in Pier3 package?
Thanks,
John
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.
>>
>>
>
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.
Has anyone noticed that the images from https://ci.inria.fr/pharo-contribution/job/Pier3Addons/PHARO=30,VERSION=sta… are having issues with the editor? When one tries to open it, it gives the loading message in the text area, a few inactive links, and the message
MessageNotUnderstood: receiver of "builder" is nil
I'm getting this from a Pharo 3 VM and testing the files from Mar-7th until today's image. At first I thought this may be due to WARenderCanvas being undefined, but I've found an image from a month ago that works fine. Anyone know the last time this worked successfully?
Thanks,
John
Damien,
Please check on regular basis if you can still run Pier and if it looks good. This is the second time you broke Pier and I do not want to debug your code.
With other words: use an image that has Pier and all add ons loaded when you do your re-factorings!
Diego
We want to be able to run and edit a local pier and push updates to a production server.
When we run the following script as loadPier.st, we have a pier image we can update
by making sure there is a new file in the mczs directory.
on mac
open -n ./Pharo\ 3.app --args Pharo-30792.image st loadPier.st
on linux:
nohup ./Pharo Pharo-30792.image st loadPier.st &
Contents of loadPier.st:
Gofer new
smalltalkhubUser: 'Pier'
project: 'Pier3Addons';
configurationOf: 'Pier3AddOns';
load.
((Smalltalk at: #ConfigurationOfPier3AddOns) project version: #'development') load: 'Pier-Exporter-Code'.
(Smalltalk at: #WAAdmin) clearAll.
(Smalltalk at: #WAAdmin) defaultDispatcher
register: (Smalltalk at: #WAFileHandler) default
at: 'files'.
(Smalltalk at: #WAAdmin) disableDevelopmentTools.
Gofer new
directory: 'mczs';
package: 'Pier-Exported-Code';
load.
Gofer new
smalltalkhubUser: 'Pier'
project: 'Pier3Addons';
package: 'Pier-Updater';
load.
(Smalltalk at: #WAAdmin) defaultDispatcher defaultName:'pier'.
(Smalltalk at: #ZnZincServerAdaptor) startOn: 8080.
In Pier-Updater in the Pier3Addons we added a class that
every 10 seconds tries to find a newer version of the
Pier-Exported-Code package in its last repository
and then resets the kernel and registers the PRKernelCreatorForPier.
It has a class side initialize that starts the process.
Stephan
