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]> 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/> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> > >
