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 <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: '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 <guillermopol...@gmail.com> 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 <tim@testit.works > <mailto:tim@testit.works>> 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 <tim@testit.works >> <mailto:tim@testit.works>> 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 <tim@testit.works >>> <mailto:tim@testit.works>> 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 >>> <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 >>> <http://loadlocal.st/> >>> (loadLocal.st <http://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 <pavel.kriva...@gmail.com >>>> <mailto:pavel.kriva...@gmail.com>> wrote: >>>> >>>> For Pharo 6: >>>> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip >>>> >>>> <https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip> >>>> For Pharo 7: >>>> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip >>>> >>>> <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip> >>>> >>>> -- Pavel >>>> >>>> 2017-07-13 8:10 GMT+02:00 Tim Mackinnon <tim@testit.works >>>> <mailto:tim@testit.works>>: >>>> 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 <pavel.kriva...@gmail.com >>>> <mailto:pavel.kriva...@gmail.com>> wrote: >>>> >>>>> Hi Tim, >>>>> >>>>> I will prepare jobs that will convert them to 64bits. >>>>> >>>>> -- Pavel >>>>> >>>>> 2017-07-12 23:14 GMT+02:00 Tim Mackinnon <tim@testit.works >>>>> <mailto:tim@testit.works>>: >>>>> 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 >>>>> <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 > <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13
