Smalltalk › Pharo › Pharo Smalltalk Users

Is there a 64bit minimal image for either 6.0 or 7.0?

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 9 messages Options
Tim Mackinnon
Reply | Threaded
Open this post in threaded view
♦
♦
|

Is there a 64bit minimal image for either 6.0 or 7.0?

Tim Mackinnon
Hi - I would like to try a minimal image on AWS lambda (so I need a 64 bit version).

Is there a 64bit image for either 6.0 or 7.0 that is easy to download?

I can see - http://get.pharo.org/60-minimal but it doesn’t say its 64 bit, so I assume its 32bit?

Tim
Pavel Krivanek-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Is there a 64bit minimal image for either 6.0 or 7.0?

Pavel Krivanek-3
Hi Tim,

I will prepare jobs that will convert them to 64bits.

-- Pavel

2017-07-12 23:14 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hi - I would like to try a minimal image on AWS lambda (so I need a 64 bit version).

Is there a 64bit image for either 6.0 or 7.0 that is easy to download?

I can see - http://get.pharo.org/60-minimal but it doesn’t say its 64 bit, so I assume its 32bit?

Tim
Tim Mackinnon
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Is there a 64bit minimal image for either 6.0 or 7.0?

Tim Mackinnon
That would be great. I'm keen to see if I can reproduce what Sven seemed to measure where he seemed to get image launch times down.

Currently on Lambda I am seeing an avg 3.5s to return a simple result.

I know that 700ms of this is the overhead of a nodejs shim (the golang Sparta project has reported this aspect).

So I'm curious if a smaller image (& no sources) could get me into a sub 2s range)

Tim

Sent from my iPhone



Sent from my iPhone
On 13 Jul 2017, at 06:51, Pavel Krivanek <[hidden email]> wrote:

Hi Tim,

I will prepare jobs that will convert them to 64bits.

-- Pavel

2017-07-12 23:14 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hi - I would like to try a minimal image on AWS lambda (so I need a 64 bit version).

Is there a 64bit image for either 6.0 or 7.0 that is easy to download?

I can see - http://get.pharo.org/60-minimal but it doesn’t say its 64 bit, so I assume its 32bit?

Tim
Pavel Krivanek-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Is there a 64bit minimal image for either 6.0 or 7.0?

Pavel Krivanek-3

2017-07-13 8:10 GMT+02:00 Tim Mackinnon <[hidden email]>:
That would be great. I'm keen to see if I can reproduce what Sven seemed to measure where he seemed to get image launch times down.

Currently on Lambda I am seeing an avg 3.5s to return a simple result.

I know that 700ms of this is the overhead of a nodejs shim (the golang Sparta project has reported this aspect).

So I'm curious if a smaller image (& no sources) could get me into a sub 2s range)

Tim

Sent from my iPhone



Sent from my iPhone
On 13 Jul 2017, at 06:51, Pavel Krivanek <[hidden email]> wrote:

Hi Tim,

I will prepare jobs that will convert them to 64bits.

-- Pavel

2017-07-12 23:14 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hi - I would like to try a minimal image on AWS lambda (so I need a 64 bit version).

Is there a 64bit image for either 6.0 or 7.0 that is easy to download?

I can see - http://get.pharo.org/60-minimal but it doesn’t say its 64 bit, so I assume its 32bit?

Tim
Tim Mackinnon
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Is there a 64bit minimal image for either 6.0 or 7.0?

Tim Mackinnon
Hmmm - its very, very minimal… I am trying to load in my local code (checked out from git) with:

Metacello new
    repository: '<a href="filetree://../src" class="">filetree://../src';
    baseline: 'Lambda';
    load.

However I get an error: MCFileTreeRepository>>repositoryProperties (STON is Undeclared) 

As I’m guessing that STON is not in that minimal image -  I have tried to load ConfigurationOfSton into the image first by doing:
./pharo Pharo.image config http://ss3.gemstone.com/ss/STON ConfigurationOfSton --install=stable —-save

It looks like this does load it, however when I then run my commands to load my code into the new image with:
./pharo Pharo.image --no-default-preferences --save --quit st loadLocal.st
(loadLocal.st has the Metacello expression I first mentioned) - I still seem to be getting an error as if STON is not in the image,
E.g.
UndefinedObject class>>fromStream:
And PharoDebug has lines confirming this (pointing at the method #repositoryProperties):
27 MessageNotUnderstood(Exception)>>signal
28 UndefinedObject class(Object)>>doesNotUnderstand: #fromStream:
29 repositoryProperties
  repositoryProperties
    ifNil: [ 

At this point, I am having trouble loading this minimal image with a ui, but if I use the command line and use the “eval” command line handler, and do something like:
./pharo Pharo.image eval "(Smalltalk at: #STONReader) class methods" 
{STONReader class>>#on:}
It is showing me methods as if the class is there. Can anyone think of what I might be doing wrong? Or could try?

Tim

On 13 Jul 2017, at 08:47, Pavel Krivanek <[hidden email]> wrote:


2017-07-13 8:10 GMT+02:00 Tim Mackinnon <[hidden email]>:
That would be great. I'm keen to see if I can reproduce what Sven seemed to measure where he seemed to get image launch times down.

Currently on Lambda I am seeing an avg 3.5s to return a simple result.

I know that 700ms of this is the overhead of a nodejs shim (the golang Sparta project has reported this aspect).

So I'm curious if a smaller image (& no sources) could get me into a sub 2s range)

Tim

Sent from my iPhone



Sent from my iPhone
On 13 Jul 2017, at 06:51, Pavel Krivanek <[hidden email]> wrote:

Hi Tim,

I will prepare jobs that will convert them to 64bits.

-- Pavel

2017-07-12 23:14 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hi - I would like to try a minimal image on AWS lambda (so I need a 64 bit version).

Is there a 64bit image for either 6.0 or 7.0 that is easy to download?

I can see - http://get.pharo.org/60-minimal but it doesn’t say its 64 bit, so I assume its 32bit?

Tim
Tim Mackinnon
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Is there a 64bit minimal image for either 6.0 or 7.0?

Tim Mackinnon
Thinking about this a bit more - if the minimal image is too minimal, and I load in some required classes - do I need to force methods to recompile to pick up the now loaded classes?

Is there an easy way to do that?

Tim

On 13 Jul 2017, at 17:40, Tim Mackinnon <[hidden email]> wrote:

Hmmm - its very, very minimal… I am trying to load in my local code (checked out from git) with:

Metacello new
    repository: '<a href="filetree://../src" class="">filetree://../src';
    baseline: 'Lambda';
    load.

However I get an error: MCFileTreeRepository>>repositoryProperties (STON is Undeclared) 

As I’m guessing that STON is not in that minimal image -  I have tried to load ConfigurationOfSton into the image first by doing:
./pharo Pharo.image config http://ss3.gemstone.com/ss/STON ConfigurationOfSton --install=stable —-save

It looks like this does load it, however when I then run my commands to load my code into the new image with:
./pharo Pharo.image --no-default-preferences --save --quit st loadLocal.st
(loadLocal.st has the Metacello expression I first mentioned) - I still seem to be getting an error as if STON is not in the image,
E.g.
UndefinedObject class>>fromStream:
And PharoDebug has lines confirming this (pointing at the method #repositoryProperties):
27 MessageNotUnderstood(Exception)>>signal
28 UndefinedObject class(Object)>>doesNotUnderstand: #fromStream:
29 repositoryProperties
  repositoryProperties
    ifNil: [ 

At this point, I am having trouble loading this minimal image with a ui, but if I use the command line and use the “eval” command line handler, and do something like:
./pharo Pharo.image eval "(Smalltalk at: #STONReader) class methods" 
{STONReader class>>#on:}
It is showing me methods as if the class is there. Can anyone think of what I might be doing wrong? Or could try?

Tim

On 13 Jul 2017, at 08:47, Pavel Krivanek <[hidden email]> wrote:


2017-07-13 8:10 GMT+02:00 Tim Mackinnon <[hidden email]>:
That would be great. I'm keen to see if I can reproduce what Sven seemed to measure where he seemed to get image launch times down.

Currently on Lambda I am seeing an avg 3.5s to return a simple result.

I know that 700ms of this is the overhead of a nodejs shim (the golang Sparta project has reported this aspect).

So I'm curious if a smaller image (& no sources) could get me into a sub 2s range)

Tim

Sent from my iPhone



Sent from my iPhone
On 13 Jul 2017, at 06:51, Pavel Krivanek <[hidden email]> wrote:

Hi Tim,

I will prepare jobs that will convert them to 64bits.

-- Pavel

2017-07-12 23:14 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hi - I would like to try a minimal image on AWS lambda (so I need a 64 bit version).

Is there a 64bit image for either 6.0 or 7.0 that is easy to download?

I can see - http://get.pharo.org/60-minimal but it doesn’t say its 64 bit, so I assume its 32bit?

Tim
Tim Mackinnon
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Is there a 64bit minimal image for either 6.0 or 7.0?

Tim Mackinnon
I think there is something wrong with the minimal image - but it looks like the following has nudged me a bit closer (rather inelegantly but I think the minimal images may need checking for errors):

MCFileTreeRepository methods do: [ :m | m recompile ].
MCFileTreeStCypressReader methods do: [:m | m recompile ].
MCFileTreeAbstractReader methods do: [:m | m recompile ].
Tim

On 13 Jul 2017, at 18:18, Tim Mackinnon <[hidden email]> wrote:

Thinking about this a bit more - if the minimal image is too minimal, and I load in some required classes - do I need to force methods to recompile to pick up the now loaded classes?

Is there an easy way to do that?

Tim

On 13 Jul 2017, at 17:40, Tim Mackinnon <[hidden email]> wrote:

Hmmm - its very, very minimal… I am trying to load in my local code (checked out from git) with:

Metacello new
    repository: '<a href="filetree://../src" class="">filetree://../src';
    baseline: 'Lambda';
    load.

However I get an error: MCFileTreeRepository>>repositoryProperties (STON is Undeclared) 

As I’m guessing that STON is not in that minimal image -  I have tried to load ConfigurationOfSton into the image first by doing:
./pharo Pharo.image config http://ss3.gemstone.com/ss/STON ConfigurationOfSton --install=stable —-save

It looks like this does load it, however when I then run my commands to load my code into the new image with:
./pharo Pharo.image --no-default-preferences --save --quit st loadLocal.st
(loadLocal.st has the Metacello expression I first mentioned) - I still seem to be getting an error as if STON is not in the image,
E.g.
UndefinedObject class>>fromStream:
And PharoDebug has lines confirming this (pointing at the method #repositoryProperties):
27 MessageNotUnderstood(Exception)>>signal
28 UndefinedObject class(Object)>>doesNotUnderstand: #fromStream:
29 repositoryProperties
  repositoryProperties
    ifNil: [ 

At this point, I am having trouble loading this minimal image with a ui, but if I use the command line and use the “eval” command line handler, and do something like:
./pharo Pharo.image eval "(Smalltalk at: #STONReader) class methods" 
{STONReader class>>#on:}
It is showing me methods as if the class is there. Can anyone think of what I might be doing wrong? Or could try?

Tim

On 13 Jul 2017, at 08:47, Pavel Krivanek <[hidden email]> wrote:


2017-07-13 8:10 GMT+02:00 Tim Mackinnon <[hidden email]>:
That would be great. I'm keen to see if I can reproduce what Sven seemed to measure where he seemed to get image launch times down.

Currently on Lambda I am seeing an avg 3.5s to return a simple result.

I know that 700ms of this is the overhead of a nodejs shim (the golang Sparta project has reported this aspect).

So I'm curious if a smaller image (& no sources) could get me into a sub 2s range)

Tim

Sent from my iPhone



Sent from my iPhone
On 13 Jul 2017, at 06:51, Pavel Krivanek <[hidden email]> wrote:

Hi Tim,

I will prepare jobs that will convert them to 64bits.

-- Pavel

2017-07-12 23:14 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hi - I would like to try a minimal image on AWS lambda (so I need a 64 bit version).

Is there a 64bit image for either 6.0 or 7.0 that is easy to download?

I can see - http://get.pharo.org/60-minimal but it doesn’t say its 64 bit, so I assume its 32bit?

Tim
Guillermo Polito
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Is there a 64bit minimal image for either 6.0 or 7.0?

Guillermo Polito
Two different things:

1) yes, the minimal image is indeed minimal. Actually, the minimal image is around 20% of the full image. Two working directions that are looking for active contributions are:
 - reduce that 20% so bootstrap times are smaller
 - modularise the other 80% so that we can easily load new stuff.
     About this last point, there are already there in the repository a couple of metacello configurations made by Pavel that allow us to reload the 80% into the 20% image. But we should modularise them because so far they are too big.

2) About the second point. You should not need to recompile everything. In the image there is the Undeclared mechanism that should rebind new classes as soon as they are loaded. Can you provide more insight on the bug? Why do you need to recompile?

Tx,
Guille

On Thu, Jul 13, 2017 at 7:55 PM, Tim Mackinnon <[hidden email]> wrote:
I think there is something wrong with the minimal image - but it looks like the following has nudged me a bit closer (rather inelegantly but I think the minimal images may need checking for errors):

MCFileTreeRepository methods do: [ :m | m recompile ].
MCFileTreeStCypressReader methods do: [:m | m recompile ].
MCFileTreeAbstractReader methods do: [:m | m recompile ].
Tim

On 13 Jul 2017, at 18:18, Tim Mackinnon <[hidden email]> wrote:

Thinking about this a bit more - if the minimal image is too minimal, and I load in some required classes - do I need to force methods to recompile to pick up the now loaded classes?

Is there an easy way to do that?

Tim

On 13 Jul 2017, at 17:40, Tim Mackinnon <[hidden email]> wrote:

Hmmm - its very, very minimal… I am trying to load in my local code (checked out from git) with:

Metacello new
    repository: 'filetree://../src';
    baseline: 'Lambda';
    load.

However I get an error: MCFileTreeRepository>>repositoryProperties (STON is Undeclared) 

As I’m guessing that STON is not in that minimal image -  I have tried to load ConfigurationOfSton into the image first by doing:
./pharo Pharo.image config http://ss3.gemstone.com/ss/STON ConfigurationOfSton --install=stable —-save

It looks like this does load it, however when I then run my commands to load my code into the new image with:
./pharo Pharo.image --no-default-preferences --save --quit st loadLocal.st
(loadLocal.st has the Metacello expression I first mentioned) - I still seem to be getting an error as if STON is not in the image,
E.g.
UndefinedObject class>>fromStream:
And PharoDebug has lines confirming this (pointing at the method #repositoryProperties):
27 MessageNotUnderstood(Exception)>>signal
28 UndefinedObject class(Object)>>doesNotUnderstand: #fromStream:
29 repositoryProperties
  repositoryProperties
    ifNil: [ 

At this point, I am having trouble loading this minimal image with a ui, but if I use the command line and use the “eval” command line handler, and do something like:
./pharo Pharo.image eval "(Smalltalk at: #STONReader) class methods" 
{STONReader class>>#on:}
It is showing me methods as if the class is there. Can anyone think of what I might be doing wrong? Or could try?

Tim

On 13 Jul 2017, at 08:47, Pavel Krivanek <[hidden email]> wrote:


2017-07-13 8:10 GMT+02:00 Tim Mackinnon <[hidden email]>:
That would be great. I'm keen to see if I can reproduce what Sven seemed to measure where he seemed to get image launch times down.

Currently on Lambda I am seeing an avg 3.5s to return a simple result.

I know that 700ms of this is the overhead of a nodejs shim (the golang Sparta project has reported this aspect).

So I'm curious if a smaller image (& no sources) could get me into a sub 2s range)

Tim

Sent from my iPhone



Sent from my iPhone
On 13 Jul 2017, at 06:51, Pavel Krivanek <[hidden email]> wrote:

Hi Tim,

I will prepare jobs that will convert them to 64bits.

-- Pavel

2017-07-12 23:14 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hi - I would like to try a minimal image on AWS lambda (so I need a 64 bit version).

Is there a 64bit image for either 6.0 or 7.0 that is easy to download?

I can see - http://get.pharo.org/60-minimal but it doesn’t say its 64 bit, so I assume its 32bit?

Tim








--

   

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
Tim Mackinnon
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Is there a 64bit minimal image for either 6.0 or 7.0?

Tim Mackinnon
Hi Guille - thanks for replying and giving me some insight into all of this.

I have managed to get something working but there are definitely some issues that may need a bug report?

As I initially mentioned - if I download the Linux 64bit VM (curl get.pharo.org/64/ | bash) and then use the minimal image suggested by Pavel (https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip) I immediately hit a problem:

This minimal image supports Metacello, and the ST command line handler - however it us unable to process a script like the following (which is attempting to load a local filetree git package)

Metacello new
    repository: '<a href="filetree://../src" class="">filetree://../src';
    baseline: 'Lambda';
    load.

It fails because Metacello wants to use STON class>>readFromStream (in its #repositoryProperties method)- this minimal image does not contain STON (which is an error? Too much has been removed).

If I try to workaround this by loading STON as follows using the CONFIG command line handler:

./pharo Pharo.image config http://ss3.gemstone.com/ss/STON ConfigurationOfSton --install=stable —save

 this then highlights several other issues:

1) ConfigurationOfSton doesn’t have a group load will load it without Tests, and so loading it provides a series of errors due to TestCase not being in the min image (and there doesn’t appear to be a Configuration for loading SUnit by itelsf?) - I think this should be solved by either keeping STON in the image and/or having a config of Ston that loads without tests

2) Having loaded STON into that min image (albeit with broken Test cases), the minimal image doesn’t seem to use the Undeclared mechanism you describe and so the following classes (which have references to STON) - all need to be force recompiled like this:

{ MCFileTreeRepository. MCFileTreeStCypressReader. MCFileTreeAbstractReader } do: [:c | c compileAll ].

Otherwise I get an Undefined talkback when I try my metacello load, which I do using the ST command handler. 

Having dealt with 1 & 2, I am then able to run my Metacello load (as shown at the top). So it appears that there are a few related problems here.

I have a running example of this in Gitlab that demonstrates this - and can be used to replicate this problem if that helps (although the description is pretty clear I think).

Tim

On 14 Jul 2017, at 11:14, Guillermo Polito <[hidden email]> wrote:

Two different things:

1) yes, the minimal image is indeed minimal. Actually, the minimal image is around 20% of the full image. Two working directions that are looking for active contributions are:
 - reduce that 20% so bootstrap times are smaller
 - modularise the other 80% so that we can easily load new stuff.
     About this last point, there are already there in the repository a couple of metacello configurations made by Pavel that allow us to reload the 80% into the 20% image. But we should modularise them because so far they are too big.

2) About the second point. You should not need to recompile everything. In the image there is the Undeclared mechanism that should rebind new classes as soon as they are loaded. Can you provide more insight on the bug? Why do you need to recompile?

Tx,
Guille

On Thu, Jul 13, 2017 at 7:55 PM, Tim Mackinnon <[hidden email]> wrote:
I think there is something wrong with the minimal image - but it looks like the following has nudged me a bit closer (rather inelegantly but I think the minimal images may need checking for errors):

MCFileTreeRepository methods do: [ :m | m recompile ].
MCFileTreeStCypressReader methods do: [:m | m recompile ].
MCFileTreeAbstractReader methods do: [:m | m recompile ].
Tim

On 13 Jul 2017, at 18:18, Tim Mackinnon <[hidden email]> wrote:

Thinking about this a bit more - if the minimal image is too minimal, and I load in some required classes - do I need to force methods to recompile to pick up the now loaded classes?

Is there an easy way to do that?

Tim

On 13 Jul 2017, at 17:40, Tim Mackinnon <[hidden email]> wrote:

Hmmm - its very, very minimal… I am trying to load in my local code (checked out from git) with:

Metacello new
    repository: 'filetree://../src';
    baseline: 'Lambda';
    load.

However I get an error: MCFileTreeRepository>>repositoryProperties (STON is Undeclared) 

As I’m guessing that STON is not in that minimal image -  I have tried to load ConfigurationOfSton into the image first by doing:
./pharo Pharo.image config http://ss3.gemstone.com/ss/STON ConfigurationOfSton --install=stable —-save

It looks like this does load it, however when I then run my commands to load my code into the new image with:
./pharo Pharo.image --no-default-preferences --save --quit st loadLocal.st
(loadLocal.st has the Metacello expression I first mentioned) - I still seem to be getting an error as if STON is not in the image,
E.g.
UndefinedObject class>>fromStream:
And PharoDebug has lines confirming this (pointing at the method #repositoryProperties):
27 MessageNotUnderstood(Exception)>>signal
28 UndefinedObject class(Object)>>doesNotUnderstand: #fromStream:
29 repositoryProperties
  repositoryProperties
    ifNil: [ 

At this point, I am having trouble loading this minimal image with a ui, but if I use the command line and use the “eval” command line handler, and do something like:
./pharo Pharo.image eval "(Smalltalk at: #STONReader) class methods" 
{STONReader class>>#on:}
It is showing me methods as if the class is there. Can anyone think of what I might be doing wrong? Or could try?

Tim

On 13 Jul 2017, at 08:47, Pavel Krivanek <[hidden email]> wrote:


2017-07-13 8:10 GMT+02:00 Tim Mackinnon <[hidden email]>:
That would be great. I'm keen to see if I can reproduce what Sven seemed to measure where he seemed to get image launch times down.

Currently on Lambda I am seeing an avg 3.5s to return a simple result.

I know that 700ms of this is the overhead of a nodejs shim (the golang Sparta project has reported this aspect).

So I'm curious if a smaller image (& no sources) could get me into a sub 2s range)

Tim

Sent from my iPhone



Sent from my iPhone
On 13 Jul 2017, at 06:51, Pavel Krivanek <[hidden email]> wrote:

Hi Tim,

I will prepare jobs that will convert them to 64bits.

-- Pavel

2017-07-12 23:14 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hi - I would like to try a minimal image on AWS lambda (so I need a 64 bit version).

Is there a 64bit image for either 6.0 or 7.0 that is easy to download?

I can see - http://get.pharo.org/60-minimal but it doesn’t say its 64 bit, so I assume its 32bit?

Tim








--
   
Guille Polito

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


Phone: +33 06 52 70 66 13

Free forum by Nabble Edit this page