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

Reply via email to