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 <[email protected]> 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 <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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>>: >> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Hi Tim, >>> >>> I will prepare jobs that will convert them to 64bits. >>> >>> -- Pavel >>> >>> 2017-07-12 23:14 GMT+02:00 Tim Mackinnon <[email protected] >>> <mailto:[email protected]>>: >>> 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 >>> >> >
