Hi tim if you see libraries not separating their tests: you should report it to their authors or to us if this is our mistakes. You can also load the SUnit package.
Stef On Mon, Jul 17, 2017 at 8:00 AM, Tim Mackinnon <[email protected]> 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 <[email protected]> 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 <[email protected]>: >> >> 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 <[email protected]>: >>> >>> 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 <[email protected]> >>> 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 <[email protected]>: >>>> >>>> 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 >>>> >>> >>> >> >
