Sebastian,

FileTree is already integrated in Pharo3 and has probably diverged a bit from Dale FileTree repository, so you don't have to reload it (shouldn't).

Thierry


De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Sebastian Sastre [sebastian@flowingconcept.com]
Envoy� : mardi 8 juillet 2014 01:19
� : Pharo Development List
Objet : Re: [Pharo-dev] Workaround monticello issue

Hi Thierry,

is a
 
Pharo3.0
Latest update: #30851

with

Gofer new
url: 'http://ss3.gemstone.com/ss/FileTree';
package: 'ConfigurationOfFileTree';
load.
((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load.

in it

thanks for taking a look!




On Jul 7, 2014, at 6:18 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:

Hi Sebastian,

which version are you using? I looked into 3.0 and 4.0, and there is nothing there about setting packageList to nil in MCFileRepositoryInspector.

Thierry

De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Sebastian Sastre [sebastian@flowingconcept.com]
Envoy� : lundi 7 juillet 2014 22:45
� : Pharo Development List
Objet : [Pharo-dev] Workaround monticello issue

Hi there,

I�ve just hit an issue that prevented to open packages in monticello

MessageNotUnderstood: receiver of "indexOf:" is nil
UndefinedObject(Object)>>doesNotUnderstand: #indexOf:
MCFileRepositoryInspector>>packageSelection
PluggableListMorph>>getCurrentSelectionIndex
PluggableListMorph>>updateList
PluggableListMorph>>update:
MCFileRepositoryInspector(Object)>>changed: in Block: [ :aDependent | aDependent update: aParameter ]
DependentsArray>>do:
MCFileRepositoryInspector(Object)>>changed:
MCFileRepositoryInspector>>refresh
MCFileRepositoryInspector>>setRepository:workingCopy: in Block: [ ...
BlockClosure>>newProcess in Block: [ ...

This is what I�m using as hacky workaround:


MCFileRepositoryInspector>>packageSelection
^ self packageList isNil
ifTrue:[ 1 ]
ifFalse:[ self packageList indexOf: selectedPackage ]

The problem is that packageList is nil for some reason.

Looks like filetree is involved since
1. I�m using it and 
2. it sets an extension method #refresh that makes packageList := nil