This is a better link: https://workingcopy.app/git/#path=scripts/build.sh&repo=g...@gitlab.com:macta/PharoLambda.git
Sent from my iPhone > On 18 Oct 2019, at 16:18, Tim Mackinnon <tim@testit.works> wrote: > > Hi Norbert - it’s all in the gitlab repo (the idea was to fork it and > configure your own pipeline e vars) > > However the key stuff was in the scripts dir, and this file - > /scripts/build.sh > > Which also loads some .st files for image fix ups . > > Tim > > Sent from my iPhone > > > > Sent from my iPhone >> On 18 Oct 2019, at 16:07, Jan van de Sandt <jvdsa...@gijjes.nl> wrote: >> >> Hi Norbert, >> >> Last year I did some experiments with Pharo Lambda functions, see: >> >> https://github.com/jvdsandt/pharo-aws-toolbox/blob/master/doc/pharo-lambda-runtime.md >> >> >> I didn't spend a lot of time on minimizing the image. There is still a lot >> of room for improvement. >> >> Jan. >> >> >> >> >>> On Fri, Oct 18, 2019 at 12:30 PM Norbert Hartl <norb...@hartl.name> wrote: >>> Tim, >>> >>> is there a document anywhere explaining how to do a lambda image? >>> >>> Norbert >>> >>> > Am 18.10.2019 um 11:00 schrieb Tim Mackinnon <tim@testit.works>: >>> > >>> > I haven’t tried in a while, but in 2017 with PharoLambda I had a >>> > combined Pharo image and VM size if 21 mb using the early Pharo minimal >>> > (I recall it was an early 7.0 image ). I was loading a simple hello Alexa >>> > app, so not a ton of code (but it had Neo Json and other AWS libs as a >>> > dependency I recall). >>> > >>> > I’m interested in trying these Docker experiments, so I’ll have to look >>> > at some point and see if I can get similar sizes. >>> > >>> > As I scripted my build, I have the steps laid out. I recall there were >>> > many vm plugins not needed for a server install (sound etc) and I also >>> > ran a cleanup step in the image as there was lots of metacello stuff >>> > cached ... so I’m sure tinier is possible even without candle. >>> > >>> > Tim >>> > >>> > Sent from my iPhone >>> > >>> >>> On 18 Oct 2019, at 07:48, Norbert Hartl <norb...@hartl.name> wrote: >>> >>> >>> >>> >>> >>> >>> >>>> Am 17.10.2019 um 02:00 schrieb Julián Maestri <serp...@gmail.com>: >>> >>> >>> >>> As a side note, the final image size is not what really matters, if you >>> >>> have 20 different images all starting from the same base image (eg >>> >>> ubuntu:18.04) the base layer is shared among all images so the network >>> >>> / disk usage is less than the total size of the image. >>> >> >>> >> The overlayfs does only help here with the disk storage that is not >>> >> multiplied. As the image is a memory dump of an individual image nothing >>> >> can be shared there. So if you have 20 images you have 20 times the >>> >> heap. So a small image is actually important. The vm is different. It is >>> >> the same static file which will be paged into shared memory and the vm >>> >> binary should be shared for all 20 runtimes. But the interpreter memory >>> >> will not be shared so a small vm pays out as well. >>> >> >>> >> Norbert >>> >> >>> > >>> > >>> >>> >> >> >> -- >> Jan van de Sandt >> gsm: +31 (0)6 3039 5998
