> On 19 Jul 2017, at 14:55, Esteban A. Maringolo <emaring...@gmail.com> wrote:
>
> I don't know how "mainstream" solutions perform on AWS Lambda or EC2,
> but this seems really fast to me. 50 ms is great, assuming it bills by
> every 100ms, you still have room to perform your computation.
Yes, it seems incredibly fast. I'll have to try this myself to check, but I
have no time now.
> Thank you for pursuing this path, it could open a new territory for
> using Pharo at big scale.
>
> Esteban A. Maringolo
>
>
> 2017-07-17 8:32 GMT-03:00 Tim Mackinnon <tim@testit.works>:
>> Well I’ve been shooting in the dark a bit - but I also left out the sound
>> and display so’s (e.g. -x execlude the following and add back the null so's
>>
>> zip -r --symlinks ../deploy/$LAMBDA_NAME.zip * -x pharo-local/\* \*.sources
>> \*.changes \*.st \*.log
>> */libgit2.* */libSDL2* */B3DAccelerator* */JPEGRead* */vm-sound*
>> */vm-display* tmp/\* */__MACOSX\*
>> - zip -uR ../deploy/$LAMBDA_NAME.zip *-null.so
>>
>>
>> And everything seems to run clean. (Would be useful to get some feedback
>> from those in the know - does just leaving out so’s incurred a penalty if
>> you don’t recompile the VM? Presumably something would get written to std
>> error or pharodebug if it was an issue).
>>
>> In fact my run times on EC2 are pretty impressive:
>>
>> PharoLambdaMin]$ time ./pharo Pharo.image exec "Lambda processJSON: '{}'"
>> {"outputSpeech":{"text":"Good Morning, it's eleven
>> twenty-six","type":"PlainText"},"shouldEndSession":true,"card":{"content":"Operation
>> Successful","title":"Pharo Lambda","type":"Simple"}}
>>
>> real 0m0.039s
>> user 0m0.028s
>> sys 0m0.000s
>> [ec2-user@ip-172-31-44-73 PharoLambdaMin]$ time ./pharo Pharo.image exec
>> "Lambda processJSON: '{}'"
>> {"outputSpeech":{"text":"Good Morning, it's eleven
>> twenty-six","type":"PlainText"},"shouldEndSession":true,"card":{"content":"Operation
>> Successful","title":"Pharo Lambda","type":"Simple"}}
>>
>> real 0m0.039s
>> user 0m0.020s
>> sys 0m0.008s
>>
>>
>> Not bad eh?
>>
>> Tim
>>
>> On 17 Jul 2017, at 07:00, Tim Mackinnon <tim@testit.works> wrote:
>>
>> Thanks again Pavel - I'll try the 6.0 step 4 or possibly step 5 with sunit
>> (as many libraries don't separate out their tests).
>>
>> I've also tried leaving out libgit and libsdl2 .so's on my server build and
>> that seems fine too - making me wonder what others I can safely leave out?
>> Sound is a candidate (but small fry in size but do you need the null
>> variant?).
>>
>> Libcrypto is big - but I wonder if https routines would use that (and it
>> sounds server processing'y so maybe best left).
>>
>> I was hoping to find a list explaining them somewhere - but it remains
>> rather mysterious.
>>
>> However, at this point, I think I may have hit the sweet spot in size where
>> AWS seems to load efficiently below a zip of 10mb?
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 15 Jul 2017, at 09:35, Pavel Krivanek <pavel.kriva...@gmail.com> wrote:
>>
>> If you want to stay with Pharo 6 image, you can try the bootstrapped version
>> of the minimal image:
>> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/
>>
>> -- Pavel
>>
>> 2017-07-15 10:33 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>>>
>>> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is
>>> already converting to 64bit). There should be no problem with STON because
>>> whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal
>>> image is done differently (by shrinking) and not so well tested.
>>>
>>> For the conversion of 32-bit image to 64-bit image you need a VMMaker
>>> image:
>>>
>>> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact/vmmaker-image.zip
>>> and then evaluate:
>>> ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage:
>>> 'conversion.image'] on: AssertionFailure do: [ :fail | fail resumeUnchecked:
>>> nil ]"
>>>
>>> -- Pavel
>>>
>>>
>>>
>>> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon <tim@testit.works>:
>>>>
>>>> Hi Pavel - thanks for getting me to the point where I could even have a
>>>> minimal image. As I’m on the edge of my Pharo knowledge here, I’ll try and
>>>> run with this as best I can.
>>>>
>>>> I’d been using the 6.0 image you suggested to me - but maybe I could use
>>>> a 70 image with Pharo 6 for a while (until the VM diverges) right?
>>>>
>>>> The bit I haven’t quite understood however, is how the 64bit image is
>>>> created - as your reference is to a 32bit version? Is the 64bit one
>>>> converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I
>>>> right in thinking the pipeline stage after this one is the one you sent me
>>>> -
>>>> and the travis.yml file shows me what it does? But I can’t see a trivis.yml
>>>> in the conversion stage so I’m not sure how it does that. (Question - how
>>>> do
>>>> I see what the pipelines do to answer my own questions?)
>>>>
>>>> I was hoping that there was a basic image that got me up to metacello
>>>> baseline level to load git file tree packages/baselines in my own repo as
>>>> well baselines on the internet. The one you sent me is fairly close to that
>>>> (its just missing STON in the image and seems to have an issue with
>>>> resolving undeclared classes that get loaded in - should do a fogbugz on
>>>> that?)
>>>>
>>>> The follow-on from a metacello image is how we can get people to create
>>>> better baselines that give you more minimal loading options (e.g.
>>>> conditionally leave out the test cases perhaps)
>>>>
>>>> Tim
>>>>
>>>> On 15 Jul 2017, at 08:24, Pavel Krivanek <pavel.kriva...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi Tim,
>>>>
>>>> you can base the your work on the bootstrapped image, see
>>>> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/, file
>>>> Pharo7.0-core-*.zip
>>>>
>>>> This image does not have a lot of basic components like Monticello or
>>>> network but it has a compiler so the code can be imported as *.st files.
>>>> Then we have Pharo7.0-monticello-*.zip which will be easier to use and
>>>> probably can fit your needs. Monticello and network support are included.
>>>> But you cannot use baselines nor configurations to load your code.
>>>>
>>>> -- Pavel
>>>>
>>>> 2017-07-14 9:59 GMT+02:00 Tim Mackinnon <tim@testit.works>:
>>>>>
>>>>> Hi - buoyed by the success of a minimal image (thanks Pavel), I'm
>>>>> wondering if I can get even smaller.
>>>>>
>>>>> There are lots of .so's in the vm which wouldn't make sense on a server
>>>>> once deployed - sound, maybe libgit ...
>>>>>
>>>>> Is there a list of the essential ones, or tips on what I can strip out
>>>>> of the Linux deployment? I also recall that i can leave out .sources and
>>>>> .changes as well right?
>>>>>
>>>>> Tim
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>
>>>>
>>>
>>
>>
>
