Hi Guillermo - its 64bit I’m after for running AWS Lambda - the metacello version at 10mb looks very interesting (as the one I’m using from build #27 is 15mb). However, given I’m trying to find a stable place where I can develop on Pharo 6.1 and get a bit more experience - it looks like the latest post #27 images start breaking things for me with as I get weird errors (see below). But maybe your cleanup might resolve all of this.
I really appreciate the work you guys are putting into have some minimal images - its very cool seeing all of this come together. Tim > On 7 Aug 2017, at 15:41, Guillermo Polito <[email protected]> wrote: > > Hi Tim, > > in the file server: > > http://files.pharo.org/image/70/ <http://files.pharo.org/image/70/> > > You can get now latest 32 bit builds in many flavours: > - compiler (basic pharo image with just a compiler) > - core (compiler + package initialization) > - monticello bootstrap (core + basic monticello packages -- no network here!) > - monticello (monticello bootstrap + network support) > - metacello (monticello + metacello) > - default/full (image with everything loaded) > > If you check the built images you'll see that: > > - compiler is 4.7MB > - core is 5.6MB > - monticello bootstrap is 8.3MB > - monticello is 9MB > - metacello is 10MB > - full pharo is 30MB > > However, metacello and monticello images could be cleaned up a bit, as they > still have some monticello cache to flush. > > I'm working on uploading 64 bit images too now. > > On Mon, Aug 7, 2017 at 4:26 PM, Tim Mackinnon <[email protected] > <mailto:[email protected]>> wrote: > Hey thanks again - it looks like that file is from Build #25 (I think Jenkins > might cache the last 5 builds from the looks of it). > > Interestingly that image is 2mb smaller than the later ones (which is > helpful) - however when I try to use it, I get a walkback because Metacello > wasn’t available in that build. > > (I then tried with build #29 the latest? and #28) - and then I get an error > as it seems that the Locale class is not defined in that one? > > 'Errors in script loaded from minimal.st <http://minimal.st/>' > MessageNotUnderstood: receiver of "currentPlatform" is nil > UndefinedObject(Object)>>doesNotUnderstand: #currentPlatform > LanguageEnvironment class>>currentPlatform > LanguageEnvironment class>>defaultSystemConverter > TextConverter class>>defaultSystemConverter > MultiByteFileStream>>converter > MultiByteFileStream>>nextPut: > MultiByteFileStream(WriteStream)>>cr > UndefinedObject>>DoIt > > > So I guess the timing of my question was spot on as it looks like I’ve been > running with build #27 for a few days (without realising I had cached it) and > that one works. > > I would be interesting in working out how to get metacello in build #25 as > its smaller size is attractive (assuming its not metacello support that adds > 3mb to the image size), Do you think its worth it? Can I use the command line > package loader to shoe-horn it in? > > Tim > > >> On 7 Aug 2017, at 13:47, Pavel Krivanek <[email protected] >> <mailto:[email protected]>> wrote: >> >> Unfortunately we store minimal versions only for the latest build and you >> should use older build with hash b1625bf32c6b2b6c6f8babb789e377af5132d740. >> >> You can download this image here (I have found a random copy of it): >> https://drive.google.com/open?id=0BzSsmZhqtUTeclFEbDhtd0JvdEk >> <https://drive.google.com/open?id=0BzSsmZhqtUTeclFEbDhtd0JvdEk> >> >> Copy it to some public location you can reach. >> >> -- Pavel >> >> >> 2017-08-07 14:25 GMT+02:00 Tim Mackinnon <[email protected] >> <mailto:[email protected]>>: >> Thanks Pavel - as I’m downloading: >> >> curl -L -o min.zip >> https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip >> >> <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip> >> >> I noted that the last successful build of that asset was: >> Last stable build (#29), 2 days 23 hr ago >> <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastStableBuild/> >> Should I peg myself to a specific version that is more or less compatible >> with Pharo 6.1? I can see builds 28 (Aug 4 11am) or 27 (July 31?) - or >> should I go earlier? >> >> Can I rely on those builds sticking around - or should I cache one somewhere? >> >> Tim >> >>> On 7 Aug 2017, at 12:03, Pavel Krivanek <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> 2017-08-07 12:56 GMT+02:00 Tim Mackinnon <[email protected] >>> <mailto:[email protected]>>: >>> I’ve just switched branches and diffed - and yep, those methods were the >>> difference. Sorry about the extra noise on that - I should have read your >>> instructions a bit better - still I’ve learned a lot doing this, and am >>> really chuffed that I’ve managed to get something working. >>> >>> I’m looking at how to get my image size down a bit more - and have another >>> thread on how to properly remove packages. >>> >>> How stable do you think the minimal image will be? Should I try and >>> snapshot it as a baseline - or do you think I can keep pulling safely from >>> Jenkins for a while? >>> >>> Pharo 7 is not stable in principle. You should not depend on the latest >>> version but of course you can take a particular build that is supposed to >>> be quite solid. Now you should rather take builds before Hermes integration >>> and related refactorings. >>> >>> -- Pavel >>> >>> >>> >>> Tim >>> >>>> On 4 Aug 2017, at 21:19, Pavel Krivanek <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> yes, because master branch contains code of Pharo 6. For Pharo 7 we have >>>> flattened the traits in the kernel, but this is probably the only >>>> difference that affects Fuel packages >>>> >>>> -- Pavel >>>> >>>> 2017-08-04 20:32 GMT+02:00 Tim Mackinnon <[email protected] >>>> <mailto:[email protected]>>: >>>> Ah - I checked out master. So should I have checked out dev? Would this >>>> explain it? >>>> >>>> I've appreciated the help a lot by the way. >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>>> >>>> On 4 Aug 2017, at 17:28, Pavel Krivanek <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> It it were packages from the development branch then you do not need to >>>>> flatten them. >>>>> >>>>> -- Pavel >>>>> >>>>> 2017-08-04 15:52 GMT+02:00 Tim Mackinnon <[email protected] >>>>> <mailto:[email protected]>>: >>>>> Hi Pavel - When you say “packages from the Pharo repo” - I think I’m >>>>> doing that - yesterday I cloned the Pharo repo and then I copied the Fuel >>>>> packages you guys suggested over into my branch (not elegant, but simple). >>>>> >>>>> So I should have the flattened versions then? >>>>> >>>>> (I have now managed to get the P7 image working - so thanks for all your >>>>> help, but I’m curious about this part) >>>>> >>>>> Tim >>>>> >>>>>> On 4 Aug 2017, at 12:49, Pavel Krivanek <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> Hmm, Pharo 7 has flattened traits in the kernel, but it still supports >>>>>> them. So probably because you are using vanilla Fuel packages, they >>>>>> extend traits that are not used for real. You should use packages from >>>>>> the Pharo repository. >>>>>> >>>>>> -- Pavel >>>>>> >>>>>> 2017-08-04 13:42 GMT+02:00 Tim Mackinnon <[email protected] >>>>>> <mailto:[email protected]>>: >>>>>> Sadly - false call, that was my logging message - so I’m stumped why >>>>>> these traits aren’t being compiled when I load in Fuel? >>>>>> >>>>>> However I have figured out why I get the BigEndian error - this is >>>>>> because the platform is now 7 and so the FlPharo06Platform is not being >>>>>> identified and the more generic FlPharoPlatform is then the default and >>>>>> it doesn’t implement #isBigEndian. >>>>>> >>>>>> Tim >>>>>> >>>>>> >>>>>> >>>>>>> On 4 Aug 2017, at 12:20, Tim Mackinnon <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> I’ve spotted something interesting in my logs - when I added one of the >>>>>>> missing methods to ClassDescription - I see in the log the message: >>>>>>> >>>>>>> Loaded -> Fuel-cypress.1 --- >>>>>>> filetree:///builds/macta/PharoLambda/bootstrap <> --- cache >>>>>>> ...finished baseline >>>>>>> Compiling missing traits... >>>>>>> Evaluating post load initialization... >>>>>>> Finished Script. >>>>>>> >>>>>>> However when I remove all the compiles I don’t see this message: >>>>>>> >>>>>>> Loaded -> Fuel-cypress.1 --- >>>>>>> filetree:///builds/macta/PharoLambda/bootstrap <> --- cache >>>>>>> ...finished baseline >>>>>>> Evaluating post load initialization... >>>>>>> Finished Script. >>>>>>> >>>>>>> >>>>>>> So I wonder if this is similar to the problem I had in the previous 6.0 >>>>>>> image - where some things didn’t seem to compile properly (in that >>>>>>> case, it was loading a missing class that didn’t seem to cause >>>>>>> recompilation). >>>>>>> >>>>>>> Tim >>>>>>> >>>>>>>> On 4 Aug 2017, at 11:10, Tim Mackinnon <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Actually there is something weird going on - as now I’m getting a >>>>>>>> complaint about "FLPharoPlatform had the subclass responsibility to >>>>>>>> implement #isBigEndian”, and that’s in the FuelPlatform-Pharo-06 which >>>>>>>> you said to include (and it looks like I am). >>>>>>>> >>>>>>>> I need to double check this - as I must be making some trivial mistake. >>>>>>>> >>>>>>>> Tim >>>>>>>> >>>>>>>>> On 4 Aug 2017, at 11:01, Tim Mackinnon <[email protected] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> Hi Mariano - I’ve looked at this again, and it was my fault - I was >>>>>>>>> compiling in : >>>>>>>>> >>>>>>>>> fuelAccept: aGeneralMapper >>>>>>>>> ^self explicitRequirement. >>>>>>>>> >>>>>>>>> Because when I looked at the Traits for fuel - this is what it had >>>>>>>>> for TClass? - as I’m not so clear on traits, what does this mean - as >>>>>>>>> I had just assumed that I should flatten the Fuel methods for TCLass, >>>>>>>>> TBehaviour and TClassDescription - but I think I’ve misunderstood >>>>>>>>> what I should do (and I guess from Pavel’s comment - I should really >>>>>>>>> look at why that initial method was missing as it sounds like it >>>>>>>>> should have worked - so maybe its an order loading thing?). >>>>>>>>> >>>>>>>>> Thanks, for helping by the way - this is proving very instructional. >>>>>>>>> >>>>>>>>> Tim >>>>>>>>> >>>>>>>>>> On 3 Aug 2017, at 18:26, Mariano Martinez Peck >>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <[email protected] >>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>> Hi Mariano - I compiled in the trait methods manually and it got >>>>>>>>>> further - but now I’m seeing another error - Error: Explicitly >>>>>>>>>> required method", >>>>>>>>>> "\u001b[0mLambda class(Object)>>error:", >>>>>>>>>> "explicitRequirement”, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> mmmm the stack is weird... it looks like if Class >> fuelAccept: >>>>>>>>>> would have the wrong implementation, that is, having the one from >>>>>>>>>> TClass: >>>>>>>>>> >>>>>>>>>> fuelAccept: aGeneralMapper >>>>>>>>>> ^self explicitRequirement. >>>>>>>>>> >>>>>>>>>> Rather than the correct one: >>>>>>>>>> >>>>>>>>>> fuelAccept: aGeneralMapper >>>>>>>>>> >>>>>>>>>> ^aGeneralMapper visitClass: self >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Maybe the solution is to compile all those methods from traits BUT >>>>>>>>>> NOT those that are "^self explicitRequirement." because those will >>>>>>>>>> override the good methods. >>>>>>>>>> >>>>>>>>>> If that doesn't work, then maybe can you print to console the each >>>>>>>>>> impl (source) of each implementor of #fuelAccept: ? >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Any ideas? >>>>>>>>>> >>>>>>>>>> Tim >>>>>>>>>> >>>>>>>>>> "--- RUNNING ERROR HANDLER ---", >>>>>>>>>> "Error: Explicitly required method", >>>>>>>>>> "", >>>>>>>>>> "\u001b[0m\u001b[31mError: Explicitly required method", >>>>>>>>>> "\u001b[0mLambda class(Object)>>error:", >>>>>>>>>> "explicitRequirement", >>>>>>>>>> " self error: 'No decompiler available' in Lambda >>>>>>>>>> class(Object)>>explicitRequirement in Block: explicitRequirement...", >>>>>>>>>> "False>>ifFalse:", >>>>>>>>>> "Lambda class(Object)>>explicitRequirement", >>>>>>>>>> "Lambda class(Class)>>fuelAccept:", >>>>>>>>>> "FLLightGeneralMapper>>mapAndTrace:", >>>>>>>>>> "FLLightGlobalMapper>>mapAndTrace:", >>>>>>>>>> "FLPluggableSubstitutionMapper>>mapAndTrace:", >>>>>>>>>> "FLAnalysis>>mapAndTrace:", >>>>>>>>>> "FLAnalysis>>run", >>>>>>>>>> "setDefaultAnalysis", >>>>>>>>>> " self error: 'No decompiler available' in >>>>>>>>>> FLAnalyzer>>setDefaultAnalysis in Block: setDefaultAnalysis...", >>>>>>>>>> "FLAnalyzer>>analysisFor:", >>>>>>>>>> "FLSerialization>>analysisStep", >>>>>>>>>> "FLSerialization>>run", >>>>>>>>>> "setDefaultSerialization", >>>>>>>>>> " self error: 'No decompiler available' in >>>>>>>>>> FLSerializer>>setDefaultSerialization in Block: >>>>>>>>>> setDefaultSerialization...", >>>>>>>>>> "serialize: t1 on: t2", >>>>>>>>>> " self error: 'No decompiler available' in >>>>>>>>>> FLSerializer>>serialize:on: in Block: serialize: t1 on: t2...", >>>>>>>>>> "on: t1 globalEnvironment: t2 do: t3", >>>>>>>>>> " self error: 'No decompiler available' in FLEncoder >>>>>>>>>> class>>on:globalEnvironment:do: in Block: on: t1 globalEnvironment: >>>>>>>>>> t2 do: t3...", >>>>>>>>>> "BlockClosure>>ensure:", >>>>>>>>>> "FLEncoder class>>on:globalEnvironment:do:", >>>>>>>>>> "FLSerializer>>serialize:on:", >>>>>>>>>> "NonInteractiveUIManager>>writeFuelContext:", >>>>>>>>>> "Lambda class>>processDebug:", >>>>>>>>>> "Lambda class>>processJSON:", >>>>>>>>>> "Lambda class>>process:", >>>>>>>>>> "activate", >>>>>>>>>> >>>>>>>>>>> On 3 Aug 2017, at 17:26, Mariano Martinez Peck >>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Aug 3, 2017 at 1:17 PM, Tim Mackinnon <[email protected] >>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>> Hi guys - I think I’m getting close - I’m able to load remote >>>>>>>>>>> packages, and I’ve added fuel to my repo and its loading - however >>>>>>>>>>> I am getting an error when I run and test writing out a context - >>>>>>>>>>> MessageNotUnderstood: Context >>>>>>>>>>> class>>fuelIgnoredInstanceVariableNames >>>>>>>>>>> >>>>>>>>>>> I can see that this is a trait - is trait support missing in the >>>>>>>>>>> minimal image? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Uff...that's a good question hahahhah >>>>>>>>>>> I don't know if the minimal image supports traits, but what I am >>>>>>>>>>> almost sure, is the Behavior DOES need the methods defined in >>>>>>>>>>> TBehavior. So maybe the minimal image flattens the traits. In this >>>>>>>>>>> case you could do the same for Fuel (flattenDownAllTraits) >>>>>>>>>>> >>>>>>>>>>> (I also seemed to get this far just loading the Fuel package - but >>>>>>>>>>> just to be sure I added the other platform ones like you suggested >>>>>>>>>>> and still get the same error). Given how simple that method is, I >>>>>>>>>>> could just compile it in - but maybe there are many more? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> TBehavior, TClass and TClassDescription are the only one that comes >>>>>>>>>>> to my mind right now... there are only a few methods from Fuel. So >>>>>>>>>>> could compile those directly at least on a first step...at least >>>>>>>>>>> you keep you going. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Tim >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> "errorMessage": "Command failed: ./pharo Pharo.image >>>>>>>>>>> --no-default-preferences process Lambda >>>>>>>>>>> '{\"debug\":true,\"data\":5}'\n >>>>>>>>>>> "errorType": "Error", >>>>>>>>>>> "stackTrace": [ >>>>>>>>>>> "Writing fuel context to S3...", >>>>>>>>>>> "Using S3 bucket morethan-technology-projects", >>>>>>>>>>> "\u001b[31m", >>>>>>>>>>> "--- RUNNING ERROR HANDLER ---", >>>>>>>>>>> "MessageNotUnderstood: Context >>>>>>>>>>> class>>fuelIgnoredInstanceVariableNames", >>>>>>>>>>> "", >>>>>>>>>>> "\u001b[0m\u001b[31mMessageNotUnderstood: Context >>>>>>>>>>> class>>fuelIgnoredInstanceVariableNames", >>>>>>>>>>> "\u001b[0mContext class(Object)>>doesNotUnderstand: >>>>>>>>>>> #fuelIgnoredInstanceVariableNames", >>>>>>>>>>> "FLVariablesMapping>>instanceVariableNamesToSerialize", >>>>>>>>>>> "FLVariablesMapping>>initializeAnalyzing", >>>>>>>>>>> "FLVariablesMapping class>>newAnalyzing:references:", >>>>>>>>>>> >>>>>>>>>>> "FLContextCluster(FLPointerObjectCluster)>>initializeAnalyzing:", >>>>>>>>>>> "FLContextCluster class(FLObjectCluster class)>>newAnalyzing:", >>>>>>>>>>> "clusterKeyedByObjectClass: t1 class: t2", >>>>>>>>>>> " self error: 'No decompiler available' in >>>>>>>>>>> FLLightGeneralMapper(FLMapper)>>clusterKeyedByObjectClass:class: in >>>>>>>>>>> Block: clusterKeyedByObjectClass: t1 class: t2...", >>>>>>>>>>> "clusterInstanceOf: t1 keyInBucket: t2 factory: t3", >>>>>>>>>>> " self error: 'No decompiler available' in >>>>>>>>>>> FLLightGeneralMapper(FLMapper)>>clusterInstanceOf:keyInBucket:factory: >>>>>>>>>>> in Block: clusterInstanceOf: t1 keyInBucket: t2 factory: t3...", >>>>>>>>>>> "at: t1 ifAbsentPut: t2", >>>>>>>>>>> " self error: 'No decompiler available' in >>>>>>>>>>> IdentityDictionary(Dictionary)>>at:ifAbsentPut: in Block: at: t1 >>>>>>>>>>> ifAbsentPut: t2...", >>>>>>>>>>> "IdentityDictionary(Dictionary)>>at:ifAbsent:", >>>>>>>>>>> "IdentityDictionary(Dictionary)>>at:ifAbsentPut:", >>>>>>>>>>> >>>>>>>>>>> "FLLightGeneralMapper(FLMapper)>>clusterInstanceOf:keyInBucket:factory:", >>>>>>>>>>> >>>>>>>>>>> "FLLightGeneralMapper(FLMapper)>>clusterKeyedByObjectClass:class:", >>>>>>>>>>> "FLLightGeneralMapper(FLMapper)>>mapAndTraceByObjectClass:to:", >>>>>>>>>>> "FLLightGeneralMapper>>visitMethodContext:", >>>>>>>>>>> "Context>>fuelAccept:", >>>>>>>>>>> "FLLightGeneralMapper>>mapAndTrace:", >>>>>>>>>>> "FLLightGlobalMapper>>mapAndTrace:", >>>>>>>>>>> "FLPluggableSubstitutionMapper>>mapAndTrace:", >>>>>>>>>>> "FLAnalysis>>mapAndTrace:", >>>>>>>>>>> "FLAnalysis>>run", >>>>>>>>>>> "setDefaultAnalysis", >>>>>>>>>>> " self error: 'No decompiler available' in >>>>>>>>>>> FLAnalyzer>>setDefaultAnalysis in Block: setDefaultAnalysis...", >>>>>>>>>>> "FLAnalyzer>>analysisFor:", >>>>>>>>>>> "FLSerialization>>analysisStep", >>>>>>>>>>> "FLSerialization>>run", >>>>>>>>>>> "setDefaultSerialization", >>>>>>>>>>> " self error: 'No decompiler available' in >>>>>>>>>>> FLSerializer>>setDefaultSerialization in Block: >>>>>>>>>>> setDefaultSerialization...", >>>>>>>>>>> "serialize: t1 on: t2", >>>>>>>>>>> " self error: 'No decompiler available' in >>>>>>>>>>> FLSerializer>>serialize:on: in Block: serialize: t1 on: t2...", >>>>>>>>>>> "on: t1 globalEnvironment: t2 do: t3", >>>>>>>>>>> " self error: 'No decompiler available' in FLEncoder >>>>>>>>>>> class>>on:globalEnvironment:do: in Block: on: t1 globalEnvironment: >>>>>>>>>>> t2 do: t3...", >>>>>>>>>>> "BlockClosure>>ensure:", >>>>>>>>>>> "FLEncoder class>>on:globalEnvironment:do:", >>>>>>>>>>> "\u001b[0m" >>>>>>>>>>>> On 3 Aug 2017, at 13:16, Mariano Martinez Peck >>>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <[email protected] >>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>> I’m so close now (bit of a diversion with gitlab yml not liking >>>>>>>>>>>> the eval string) - that did load and it got me really close - I’m >>>>>>>>>>>> just missing FlSerializer now (I have progressed my work to fuel >>>>>>>>>>>> out the context for debugging to S3)… so looking at the repo, >>>>>>>>>>>> there are quite a few fuel packages - but in a big image I can see >>>>>>>>>>>> that FLSerialiser is in Core - so do I just need core? But then >>>>>>>>>>>> there are a few fuel packages with Core? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The easiest way to understand that is either checking >>>>>>>>>>>> ConfigurationOfFuel directly or some of the related Metacello tool. >>>>>>>>>>>> Anyway, for this case, I think you need the packages (in this >>>>>>>>>>>> order): FuelPlatform and Fuel. Bug again, Metacello allows some >>>>>>>>>>>> postLoad actions (which we use in Fuel)... so...it's not always >>>>>>>>>>>> easy to load a project without Metacello. >>>>>>>>>>>> >>>>>>>>>>>> Sometimes you can print the result of #record: >>>>>>>>>>>> >>>>>>>>>>>> Metacello new >>>>>>>>>>>> configuration: 'Fuel'; >>>>>>>>>>>> smalltalkhubUser: 'Pharo' project: 'Fuel'; >>>>>>>>>>>> version: #stable; >>>>>>>>>>>> record: #('Core'). >>>>>>>>>>>> >>>>>>>>>>>> -> >>>>>>>>>>>> >>>>>>>>>>>> "linear load : >>>>>>>>>>>> linear load : 2.1.10 [ConfigurationOfFuel] >>>>>>>>>>>> linear load : baseline [ConfigurationOfFuelPlatform] >>>>>>>>>>>> load : FuelPlatform-Core >>>>>>>>>>>> load : FuelPlatform-Pharo-Core >>>>>>>>>>>> load : FuelPlatform-Pharo-06" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------ >>>>>>>>>>>> >>>>>>>>>>>> Anyway.... I guess I would try to load these packages (in this >>>>>>>>>>>> order): >>>>>>>>>>>> >>>>>>>>>>>> FuelPlatform-Core >>>>>>>>>>>> FuelPlatform-Pharo-Core >>>>>>>>>>>> FuelPlatform-Pharo-06 >>>>>>>>>>>> Fuel >>>>>>>>>>>> >>>>>>>>>>>> And when you are down loading, then execute: >>>>>>>>>>>> >>>>>>>>>>>> (Smalltalk at: #FLPlatform) current addHacks >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I’m also not quite clear on how I would load packages without a >>>>>>>>>>>> Baseline (would I create my own baseline for the fuel packages I >>>>>>>>>>>> need?) >>>>>>>>>>>> >>>>>>>>>>>> Tim >>>>>>>>>>>> >>>>>>>>>>>>> On 3 Aug 2017, at 12:07, Pavel Krivanek <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-08-03 13:02 GMT+02:00 Tim Mackinnon <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>>>>> I really appreciate your patience and help on this - it looks >>>>>>>>>>>>> very promising and I am giving it a spin now… >>>>>>>>>>>>> >>>>>>>>>>>>> When you say the pharo repository - are you referring to this: >>>>>>>>>>>>> https://github.com/pharo-project/pharo/tree/master/src >>>>>>>>>>>>> <https://github.com/pharo-project/pharo/tree/master/src>. ? Just >>>>>>>>>>>>> so I know for the future. >>>>>>>>>>>>> >>>>>>>>>>>>> yes >>>>>>>>>>>>> >>>>>>>>>>>>> -- Pavel >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Tim >>>>>>>>>>>>> >>>>>>>>>>>>>> On 3 Aug 2017, at 09:16, Pavel Krivanek >>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2017-08-03 10:14 GMT+02:00 Pavel Krivanek >>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>>: >>>>>>>>>>>>>> The easiest think you can do is to copy to your repository (or >>>>>>>>>>>>>> some other) related packages from the Pharo repository (to do >>>>>>>>>>>>>> not have to clone it all): >>>>>>>>>>>>>> >>>>>>>>>>>>>> Metacello-GitBasedRepository.package >>>>>>>>>>>>>> Metacello-GitHub.package >>>>>>>>>>>>>> SUnit-Core.package >>>>>>>>>>>>>> >>>>>>>>>>>>>> and create baseline to load them. I already tried it so you can >>>>>>>>>>>>>> test it: >>>>>>>>>>>>>> https://drive.google.com/open?id=0BzSsmZhqtUTeMVJacTZtdW5UQW8 >>>>>>>>>>>>>> <https://drive.google.com/open?id=0BzSsmZhqtUTeMVJacTZtdW5UQW8> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Then you will do something like: >>>>>>>>>>>>>> >>>>>>>>>>>>>> (accidental message send ;-) ) >>>>>>>>>>>>>> >>>>>>>>>>>>>> BASELINE=MetacelloGitBasedRepository >>>>>>>>>>>>>> pharo "$IMAGE_NAME.image" --no-default-preferences eval --save \ >>>>>>>>>>>>>> "Metacello new baseline: '$BASELINE'; repository: >>>>>>>>>>>>>> 'filetree://./PharoLambda/src <>'; load." >>>>>>>>>>>>>> >>>>>>>>>>>>>> BASELINE=Lambda >>>>>>>>>>>>>> pharo "$IMAGE_NAME.image" --no-default-preferences eval --save \ >>>>>>>>>>>>>> "Metacello new baseline: '$BASELINE'; repository: >>>>>>>>>>>>>> 'filetree://./PharoLambda/src <>'; load." >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I tried that. The baseline of Lambda is then able to be >>>>>>>>>>>>>> loaded. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Pavel >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2017-08-02 15:18 GMT+02:00 Tim Mackinnon <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>>>>>> Ah, I think I’m starting to get closer to what I need… >>>>>>>>>>>>>> >>>>>>>>>>>>>> So if I want to load in that last piece to enable more general >>>>>>>>>>>>>> remote loading - how do I figure out how to do that? I’m trying >>>>>>>>>>>>>> to work out where the build steps for building up the image (can >>>>>>>>>>>>>> I see them in Jenkins? It wasn’t clear to me if I can look it >>>>>>>>>>>>>> up? Or the BaselineOfIDE was mentioned - looking there I can see >>>>>>>>>>>>>> a few metacello and gofer packages - but then I guess I’m >>>>>>>>>>>>>> looking for an easy Mcz I can use with the example below? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Or do I just load Metacello as a git submodule and then it will >>>>>>>>>>>>>> be on my local filesystem to then bootstrap up? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I guess I’m trying to work out the best sustainable approach to >>>>>>>>>>>>>> getting to a good server based image that has minimal tools and >>>>>>>>>>>>>> the ability to easily load remote code for pre-req projects. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tim >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2 Aug 2017, at 07:05, Guillermo Polito >>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, you should be able to load an mcz in that image by doing: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (MCDirectoryRepository new directory: 'where-your-mcz-is') >>>>>>>>>>>>>>> loadVersionFromFileNamed: >>>>>>>>>>>>>>> 'Metacello-GitBasedRepository-Author.1.mcz') load. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Guille >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Aug 2, 2017 at 7:57 AM, Pavel Krivanek >>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>>>>>>> Hi Pavel - I tried it again and the problem is do with >>>>>>>>>>>>>>> Metacello dependencies in your baseline. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The SUnit baseline doesn’t specify any additional dependencies >>>>>>>>>>>>>>> to load (it just loads local packages), whereas my baseline >>>>>>>>>>>>>>> that fails looks like this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> baseline: spec >>>>>>>>>>>>>>> <baseline> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> spec for: #common do: [ >>>>>>>>>>>>>>> spec configuration: 'ZTimestamp' with: [ >>>>>>>>>>>>>>> spec >>>>>>>>>>>>>>> versionString: #stable; >>>>>>>>>>>>>>> repository: >>>>>>>>>>>>>>> 'http://mc.stfx.eu/Neo <http://mc.stfx.eu/Neo>' ]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> spec baseline: 'AWS' with: [ >>>>>>>>>>>>>>> spec repository: >>>>>>>>>>>>>>> 'github://newapplesho/aws-sdk-smalltalk:v1.10/pharo-repository >>>>>>>>>>>>>>> <>' ]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> spec >>>>>>>>>>>>>>> package: 'Lambda' with: [ spec >>>>>>>>>>>>>>> requires: {'ZTimestamp'. 'AWS'}]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The “spec configuration: ….” Specifications cause the error: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 25 UndefinedObject(Object)>>doesNotUnderstand: #addTo: >>>>>>>>>>>>>>> 26 MCRepositoryGroup>>addRepository: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If I remove those lines from my baseline above (as well the >>>>>>>>>>>>>>> requires: reference to them) I can then successfully load my >>>>>>>>>>>>>>> packages. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So is this something the minimal image should support >>>>>>>>>>>>>>> (otherwise how do you load external packages into your image >>>>>>>>>>>>>>> without checking them in locally?) OR is there something simple >>>>>>>>>>>>>>> I can checkin and load locally to return that behaviour? >>>>>>>>>>>>>>> (Personally I think it would make sense to allow remote loading >>>>>>>>>>>>>>> - I’m guessing Pharo itself as a core has everything it needs - >>>>>>>>>>>>>>> but if you want to do any experimentation on the core and need >>>>>>>>>>>>>>> remote packages, you would hit this too - so it feels a bit >>>>>>>>>>>>>>> limiting). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The dependencies in th baseline are supported but the support >>>>>>>>>>>>>>> for most of external repositories (like package >>>>>>>>>>>>>>> Metacello-GitBasedRepository) is loaded at the end of >>>>>>>>>>>>>>> bootstrapping process in BaselineOfIDE. We should check/solve >>>>>>>>>>>>>>> dependencies and move it into the minimal Pharo. For now you >>>>>>>>>>>>>>> can try to load it by yourself or work with already prepared >>>>>>>>>>>>>>> local clones of required repositories. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Pavel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tim >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 1 Aug 2017, at 10:06, Pavel Krivanek >>>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>>>>>>>> I wasn’t clear on which image to retry - the >>>>>>>>>>>>>>>> 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> >>>>>>>>>>>>>>>> one still shows as being last updated 7 days ago. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/> >>>>>>>>>>>>>>>> one gives me a mismatch error: This interpreter (vers. 68021) >>>>>>>>>>>>>>>> cannot read image file (vers. 6521). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>> 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> >>>>>>>>>>>>>>>> one gives me a walkback when trying to run my install script : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 25 UndefinedObject(Object)>>doesNotUnderstand: #addTo: >>>>>>>>>>>>>>>> 26 MCRepositoryGroup>>addRepository: >>>>>>>>>>>>>>>> 27 createRepository >>>>>>>>>>>>>>>> | repo | >>>>>>>>>>>>>>>> repo := self project createRepository: self. >>>>>>>>>>>>>>>> ^ MCRepositoryGroup default repositories >>>>>>>>>>>>>>>> detect: [ :each | each = repo ] >>>>>>>>>>>>>>>> ifNone: [ >>>>>>>>>>>>>>>> MCRepositoryGroup default addRepository: repo. >>>>>>>>>>>>>>>> repo ] in MetacelloRepositorySpec>>createRepository >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think this is because the image doesn’t support Metacello? >>>>>>>>>>>>>>>> As in: >>>>>>>>>>>>>>>> Metacello new >>>>>>>>>>>>>>>> repository: 'filetree://../src <>'; >>>>>>>>>>>>>>>> baseline: 'Lambda'; >>>>>>>>>>>>>>>> load. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> How do you guys load things into the minimal images (I thought >>>>>>>>>>>>>>>> you used Metacello - but maybe you do it some other way?) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I can use a big 6.1 image fine (as it has Metacello loaded) >>>>>>>>>>>>>>>> but I’d really like a minimal solution - that can load in >>>>>>>>>>>>>>>> libraries like AWS S3, or XML parsing etc. and it seems like I >>>>>>>>>>>>>>>> should be a good customer for kicking the tires on all of this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tim >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I checked the 64-bit Pharo 7 minimal image and loading of >>>>>>>>>>>>>>>> baseline (of SUnit from pharo-project/pharo) works: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval --save >>>>>>>>>>>>>>>> "Metacello new baseline: 'SUnit'; repository: >>>>>>>>>>>>>>>> 'filetree://./pharo-core/src <>'; load." >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval "TestCase >>>>>>>>>>>>>>>> suite run" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Can you test it too? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Pavel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 <tel:+33%206%2052%2070%2066%2013> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Mariano >>>>>>>>>>>> http://marianopeck.wordpress.com >>>>>>>>>>>> <http://marianopeck.wordpress.com/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Mariano >>>>>>>>>>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mariano >>>>>>>>>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > > > > -- > > 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
