2017-08-07 12:56 GMT+02:00 Tim Mackinnon <[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]> 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]>: > >> 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]> 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]>: >> >>> 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]> >>> 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]>: >>> >>>> 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]> 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/Pharo >>>> Lambda/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/Pharo >>>> Lambda/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]> 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]> 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]> >>>> wrote: >>>> >>>> >>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <[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]> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On Thu, Aug 3, 2017 at 1:17 PM, Tim Mackinnon <[email protected]> w >>>>> rote: >>>>> >>>>>> 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:keyInBu >>>>>> cket: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]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <[email protected]> w >>>>>> rote: >>>>>> >>>>>>> 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]> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-08-03 13:02 GMT+02:00 Tim Mackinnon <[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. ? Just so >>>>>>>> I know for the future. >>>>>>>> >>>>>>> >>>>>>> yes >>>>>>> >>>>>>> -- Pavel >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Tim >>>>>>>> >>>>>>>> On 3 Aug 2017, at 09:16, Pavel Krivanek <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2017-08-03 10:14 GMT+02:00 Pavel Krivanek <[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 >>>>>>>>> >>>>>>>>> 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]>: >>>>>>>>> >>>>>>>>>> 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]> 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]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <[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' ]. >>>>>>>>>>>> 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]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <[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 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/ 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-32bi >>>>>>>>>>>>> t-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 <+33%206%2052%2070%2066%2013> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > >
