Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

2017-08-22 Thread Stephane Ducasse
Ok I checked and the Session manager is not the toolRegistry.
I do not like the design of the latter: a global variable used from
anywhere.
Now the alternative is that each tool access other tools via a context
object
but the question is how to update such context when we have a new tool
loaded.

Stef

On Tue, Aug 22, 2017 at 7:03 PM, Stephane Ducasse 
wrote:

> My impression is that this code is old and we should rewrite it.
> Now I wonder why the session manager register itself to the tools.
> The idea of the tool registration was that we can swap them to get
> different suite of tools.
> This was never really used and I would replace that by a tool context
> passed around instead of an ugly
> global variable (because this is what it is).
>
> So I wonder why the logic is like that.
> SessionManager default registerToolClassNamed: self name
> I hope that code relying on the DNU aspect of the tool registry does not
> exist.
>
> Now may be I'm confusing the sessionManager tool registry with the
> toolregistry.
>
> We should really reassess some of the solutions we have.
>
> stef
>
> On Tue, Aug 22, 2017 at 6:58 PM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>>
>> Le mar. 22 août 2017 à 18:33, Alistair Grant  a
>> écrit :
>>
>>> Hi Guille,
>>>
>>> On Tue, Aug 22, 2017 at 05:55:22PM +0200, Guillermo Polito wrote:
>>> > I don't think so... Build number only works from the CI. This means
>>> > that if you build your image in your machine you'll have no build
>>> > number and then this piece of code will not work neither. Thus maybe
>>> > we need to find a separate solution for it?
>>>
>>> P.S. Shouldn't the highestUpdate still be set as described below?
>>
>>
>> But how do you do it? Imagine I build my image from outsider the ci.
>> Where do I get the build number ? In my machine I have no thing such as a
>> build or a job.
>>
>> Pharo should work independently from where it is build.
>>
>> We should not mistake build number for version number. They do not mean
>> the same.
>>
>>
>>>
>>> This is an image that presumably came from the CI
>>> (http://files.pharo.org/image/70/latest.zip).
>>>
>>> Thanks,
>>> Alistair
>>>
>>>
>>> > On 8/22/17, Alistair Grant  wrote:
>>> > > Hi Everyone,
>>> > >
>>> > > I'm attempting to update to the latest Pharo7 image (918efe2, 32
>>> bit),
>>> > > but am getting an error while loading OSsubprocess.
>>> > >
>>> > > The error occurs in FFISharedPool class>>initialize:
>>> > >
>>> > >
>>> > > initialize
>>> > > self flag: #removeIt.
>>> > > "This IF will be eliminated soon...only here temporary"
>>> > > (SystemVersion current highestUpdate >= 50558)
>>> > > ifTrue: [
>>> > > SessionManager default registerToolClassNamed:
>>> self name
>>> > >  ]
>>> > > ifFalse: [
>>> > > Smalltalk addToStartUpList: self.
>>> > > ]
>>> > >
>>> > >
>>> > > because #highestUpdate is nil.
>>> > >
>>> > >
>>> > > The top of the stack is:
>>> > >
>>> > > UndefinedObject(Object)>>doesNotUnderstand: #'>='
>>> > > FFISharedPool class>>initialize
>>> > > MCMethodDefinition>>postloadOver:
>>> > > [ :each | each postloadOver: (self obsoletionFor: each) ] in
>>> > > MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each
>>> postloadOver:
>>> > > (self obsoletionFor: ...etc...
>>> > >
>>> > >
>>> > > Based on the method above, it looks like highestUpdate used to be set
>>> > > based on the image number, and has presumably broken during the move
>>> to
>>> > > Pharo 7 and git.
>>> > >
>>> > > Earlier Pharo 7 images had it set to 0, which doesn't sound right.
>>> > >
>>> > > Since a build number was recently introduced (fogbugz 20321), should
>>> the
>>> > > highestUpdate be set to 7+buildNumber?
>>> > >
>>> > > E.g. this image has an identifier of:
>>> > >
>>> > > Pharo 7.0
>>> > > Build information:
>>> > > alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6
>>> > >
>>> > > So highestUpdate would be 70056.
>>> > >
>>> > >
>>> > > Thanks!
>>> > > Alistair
>>> > >
>>> > >
>>> >
>>> >
>>> > --
>>> >
>>> >
>>> >
>>> >
>>> > Guille Polito
>>> >
>>> >
>>> > Research Engineer
>>> >
>>> > French National Center for Scientific Research - *http://www.cnrs.fr*
>>> > 
>>> >
>>> >
>>> >
>>> > *Web:* *http://guillep.github.io* 
>>> >
>>> > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>> >
>>>
>>> --
>>
>>
>>
>> Guille Polito
>>
>>
>> Research Engineer
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr*
>> 
>>
>>
>>
>> *Web:* *http://guillep.github.io* 
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>


Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

2017-08-22 Thread Stephane Ducasse
My impression is that this code is old and we should rewrite it.
Now I wonder why the session manager register itself to the tools.
The idea of the tool registration was that we can swap them to get
different suite of tools.
This was never really used and I would replace that by a tool context
passed around instead of an ugly
global variable (because this is what it is).

So I wonder why the logic is like that.
SessionManager default registerToolClassNamed: self name
I hope that code relying on the DNU aspect of the tool registry does not
exist.

Now may be I'm confusing the sessionManager tool registry with the
toolregistry.

We should really reassess some of the solutions we have.

stef

On Tue, Aug 22, 2017 at 6:58 PM, Guillermo Polito  wrote:

>
> Le mar. 22 août 2017 à 18:33, Alistair Grant  a
> écrit :
>
>> Hi Guille,
>>
>> On Tue, Aug 22, 2017 at 05:55:22PM +0200, Guillermo Polito wrote:
>> > I don't think so... Build number only works from the CI. This means
>> > that if you build your image in your machine you'll have no build
>> > number and then this piece of code will not work neither. Thus maybe
>> > we need to find a separate solution for it?
>>
>> P.S. Shouldn't the highestUpdate still be set as described below?
>
>
> But how do you do it? Imagine I build my image from outsider the ci. Where
> do I get the build number ? In my machine I have no thing such as a build
> or a job.
>
> Pharo should work independently from where it is build.
>
> We should not mistake build number for version number. They do not mean
> the same.
>
>
>>
>> This is an image that presumably came from the CI
>> (http://files.pharo.org/image/70/latest.zip).
>>
>> Thanks,
>> Alistair
>>
>>
>> > On 8/22/17, Alistair Grant  wrote:
>> > > Hi Everyone,
>> > >
>> > > I'm attempting to update to the latest Pharo7 image (918efe2, 32 bit),
>> > > but am getting an error while loading OSsubprocess.
>> > >
>> > > The error occurs in FFISharedPool class>>initialize:
>> > >
>> > >
>> > > initialize
>> > > self flag: #removeIt.
>> > > "This IF will be eliminated soon...only here temporary"
>> > > (SystemVersion current highestUpdate >= 50558)
>> > > ifTrue: [
>> > > SessionManager default registerToolClassNamed:
>> self name
>> > >  ]
>> > > ifFalse: [
>> > > Smalltalk addToStartUpList: self.
>> > > ]
>> > >
>> > >
>> > > because #highestUpdate is nil.
>> > >
>> > >
>> > > The top of the stack is:
>> > >
>> > > UndefinedObject(Object)>>doesNotUnderstand: #'>='
>> > > FFISharedPool class>>initialize
>> > > MCMethodDefinition>>postloadOver:
>> > > [ :each | each postloadOver: (self obsoletionFor: each) ] in
>> > > MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each
>> postloadOver:
>> > > (self obsoletionFor: ...etc...
>> > >
>> > >
>> > > Based on the method above, it looks like highestUpdate used to be set
>> > > based on the image number, and has presumably broken during the move
>> to
>> > > Pharo 7 and git.
>> > >
>> > > Earlier Pharo 7 images had it set to 0, which doesn't sound right.
>> > >
>> > > Since a build number was recently introduced (fogbugz 20321), should
>> the
>> > > highestUpdate be set to 7+buildNumber?
>> > >
>> > > E.g. this image has an identifier of:
>> > >
>> > > Pharo 7.0
>> > > Build information:
>> > > alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6
>> > >
>> > > So highestUpdate would be 70056.
>> > >
>> > >
>> > > Thanks!
>> > > Alistair
>> > >
>> > >
>> >
>> >
>> > --
>> >
>> >
>> >
>> >
>> > Guille Polito
>> >
>> >
>> > Research Engineer
>> >
>> > French National Center for Scientific Research - *http://www.cnrs.fr*
>> > 
>> >
>> >
>> >
>> > *Web:* *http://guillep.github.io* 
>> >
>> > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>> >
>>
>> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>


Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

2017-08-22 Thread Guillermo Polito
Le mar. 22 août 2017 à 18:33, Alistair Grant  a
écrit :

> Hi Guille,
>
> On Tue, Aug 22, 2017 at 05:55:22PM +0200, Guillermo Polito wrote:
> > I don't think so... Build number only works from the CI. This means
> > that if you build your image in your machine you'll have no build
> > number and then this piece of code will not work neither. Thus maybe
> > we need to find a separate solution for it?
>
> P.S. Shouldn't the highestUpdate still be set as described below?


But how do you do it? Imagine I build my image from outsider the ci. Where
do I get the build number ? In my machine I have no thing such as a build
or a job.

Pharo should work independently from where it is build.

We should not mistake build number for version number. They do not mean the
same.


>
> This is an image that presumably came from the CI
> (http://files.pharo.org/image/70/latest.zip).
>
> Thanks,
> Alistair
>
>
> > On 8/22/17, Alistair Grant  wrote:
> > > Hi Everyone,
> > >
> > > I'm attempting to update to the latest Pharo7 image (918efe2, 32 bit),
> > > but am getting an error while loading OSsubprocess.
> > >
> > > The error occurs in FFISharedPool class>>initialize:
> > >
> > >
> > > initialize
> > > self flag: #removeIt.
> > > "This IF will be eliminated soon...only here temporary"
> > > (SystemVersion current highestUpdate >= 50558)
> > > ifTrue: [
> > > SessionManager default registerToolClassNamed:
> self name
> > >  ]
> > > ifFalse: [
> > > Smalltalk addToStartUpList: self.
> > > ]
> > >
> > >
> > > because #highestUpdate is nil.
> > >
> > >
> > > The top of the stack is:
> > >
> > > UndefinedObject(Object)>>doesNotUnderstand: #'>='
> > > FFISharedPool class>>initialize
> > > MCMethodDefinition>>postloadOver:
> > > [ :each | each postloadOver: (self obsoletionFor: each) ] in
> > > MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each
> postloadOver:
> > > (self obsoletionFor: ...etc...
> > >
> > >
> > > Based on the method above, it looks like highestUpdate used to be set
> > > based on the image number, and has presumably broken during the move to
> > > Pharo 7 and git.
> > >
> > > Earlier Pharo 7 images had it set to 0, which doesn't sound right.
> > >
> > > Since a build number was recently introduced (fogbugz 20321), should
> the
> > > highestUpdate be set to 7+buildNumber?
> > >
> > > E.g. this image has an identifier of:
> > >
> > > Pharo 7.0
> > > Build information:
> > > alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6
> > >
> > > So highestUpdate would be 70056.
> > >
> > >
> > > Thanks!
> > > Alistair
> > >
> > >
> >
> >
> > --
> >
> >
> >
> >
> > Guille Polito
> >
> >
> > Research Engineer
> >
> > French National Center for Scientific Research - *http://www.cnrs.fr*
> > 
> >
> >
> >
> > *Web:* *http://guillep.github.io* 
> >
> > *Phone: *+33 06 52 70 66 13
> >
>
> --



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13


Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

2017-08-22 Thread Alistair Grant
Hi Guille,

On Tue, Aug 22, 2017 at 05:55:22PM +0200, Guillermo Polito wrote:
> I don't think so... Build number only works from the CI. This means
> that if you build your image in your machine you'll have no build
> number and then this piece of code will not work neither. Thus maybe
> we need to find a separate solution for it?

P.S. Shouldn't the highestUpdate still be set as described below?

This is an image that presumably came from the CI
(http://files.pharo.org/image/70/latest.zip).

Thanks,
Alistair


> On 8/22/17, Alistair Grant  wrote:
> > Hi Everyone,
> >
> > I'm attempting to update to the latest Pharo7 image (918efe2, 32 bit),
> > but am getting an error while loading OSsubprocess.
> >
> > The error occurs in FFISharedPool class>>initialize:
> >
> >
> > initialize
> > self flag: #removeIt.
> > "This IF will be eliminated soon...only here temporary"
> > (SystemVersion current highestUpdate >= 50558)
> > ifTrue: [
> > SessionManager default registerToolClassNamed: self name
> >  ]
> > ifFalse: [
> > Smalltalk addToStartUpList: self.
> > ]
> >
> >
> > because #highestUpdate is nil.
> >
> >
> > The top of the stack is:
> >
> > UndefinedObject(Object)>>doesNotUnderstand: #'>='
> > FFISharedPool class>>initialize
> > MCMethodDefinition>>postloadOver:
> > [ :each | each postloadOver: (self obsoletionFor: each) ] in
> > MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each postloadOver:
> > (self obsoletionFor: ...etc...
> >
> >
> > Based on the method above, it looks like highestUpdate used to be set
> > based on the image number, and has presumably broken during the move to
> > Pharo 7 and git.
> >
> > Earlier Pharo 7 images had it set to 0, which doesn't sound right.
> >
> > Since a build number was recently introduced (fogbugz 20321), should the
> > highestUpdate be set to 7+buildNumber?
> >
> > E.g. this image has an identifier of:
> >
> > Pharo 7.0
> > Build information:
> > alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6
> >
> > So highestUpdate would be 70056.
> >
> >
> > Thanks!
> > Alistair
> >
> >
> 
> 
> -- 
> 
> 
> 
> 
> Guille Polito
> 
> 
> Research Engineer
> 
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
> 
> 
> 
> *Web:* *http://guillep.github.io* 
> 
> *Phone: *+33 06 52 70 66 13
> 



Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

2017-08-22 Thread Alistair Grant
On Tue, Aug 22, 2017 at 05:55:22PM +0200, Guillermo Polito wrote:
> I don't think so... Build number only works from the CI. This means
> that if you build your image in your machine you'll have no build
> number and then this piece of code will not work neither. Thus maybe
> we need to find a separate solution for it?

Good point.

I guess that #registerToolClassNamed: was introduced around image #50558
and didn't exist in earlier versions, so the test could be replaced
with:

SessionManager default respondsTo: #registerToolClassNamed:

I'll see if I can download an older Pharo 5 VM and image and check (pre
50558).

Thanks,
Alistair


> On 8/22/17, Alistair Grant  wrote:
> > Hi Everyone,
> >
> > I'm attempting to update to the latest Pharo7 image (918efe2, 32 bit),
> > but am getting an error while loading OSsubprocess.
> >
> > The error occurs in FFISharedPool class>>initialize:
> >
> >
> > initialize
> > self flag: #removeIt.
> > "This IF will be eliminated soon...only here temporary"
> > (SystemVersion current highestUpdate >= 50558)
> > ifTrue: [
> > SessionManager default registerToolClassNamed: self name
> >  ]
> > ifFalse: [
> > Smalltalk addToStartUpList: self.
> > ]
> >
> >
> > because #highestUpdate is nil.
> >
> >
> > The top of the stack is:
> >
> > UndefinedObject(Object)>>doesNotUnderstand: #'>='
> > FFISharedPool class>>initialize
> > MCMethodDefinition>>postloadOver:
> > [ :each | each postloadOver: (self obsoletionFor: each) ] in
> > MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each postloadOver:
> > (self obsoletionFor: ...etc...
> >
> >
> > Based on the method above, it looks like highestUpdate used to be set
> > based on the image number, and has presumably broken during the move to
> > Pharo 7 and git.
> >
> > Earlier Pharo 7 images had it set to 0, which doesn't sound right.
> >
> > Since a build number was recently introduced (fogbugz 20321), should the
> > highestUpdate be set to 7+buildNumber?
> >
> > E.g. this image has an identifier of:
> >
> > Pharo 7.0
> > Build information:
> > alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6
> >
> > So highestUpdate would be 70056.
> >
> >
> > Thanks!
> > Alistair
> >
> >
> 
> 
> -- 
> 
> 
> 
> 
> Guille Polito
> 
> 
> Research Engineer
> 
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
> 
> 
> 
> *Web:* *http://guillep.github.io* 
> 
> *Phone: *+33 06 52 70 66 13
> 



Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

2017-08-22 Thread Guillermo Polito
I don't think so... Build number only works from the CI. This means
that if you build your image in your machine you'll have no build
number and then this piece of code will not work neither. Thus maybe
we need to find a separate solution for it?

On 8/22/17, Alistair Grant  wrote:
> Hi Everyone,
>
> I'm attempting to update to the latest Pharo7 image (918efe2, 32 bit),
> but am getting an error while loading OSsubprocess.
>
> The error occurs in FFISharedPool class>>initialize:
>
>
> initialize
>   self flag: #removeIt.
>   "This IF will be eliminated soon...only here temporary"
>   (SystemVersion current highestUpdate >= 50558)
>   ifTrue: [
>   SessionManager default registerToolClassNamed: self name
>]
>   ifFalse: [
>   Smalltalk addToStartUpList: self.
>   ]
>
>
> because #highestUpdate is nil.
>
>
> The top of the stack is:
>
> UndefinedObject(Object)>>doesNotUnderstand: #'>='
> FFISharedPool class>>initialize
> MCMethodDefinition>>postloadOver:
> [ :each | each postloadOver: (self obsoletionFor: each) ] in
> MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each postloadOver:
> (self obsoletionFor: ...etc...
>
>
> Based on the method above, it looks like highestUpdate used to be set
> based on the image number, and has presumably broken during the move to
> Pharo 7 and git.
>
> Earlier Pharo 7 images had it set to 0, which doesn't sound right.
>
> Since a build number was recently introduced (fogbugz 20321), should the
> highestUpdate be set to 7+buildNumber?
>
> E.g. this image has an identifier of:
>
> Pharo 7.0
> Build information:
> alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6
>
> So highestUpdate would be 70056.
>
>
> Thanks!
> Alistair
>
>


-- 




Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13