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 <pavel.kriva...@gmail.com> 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 <tim@testit.works>:
>> 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 <pavel.kriva...@gmail.com> 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 <tim@testit.works>:
>>>> 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 <tim@testit.works> 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 <tim@testit.works> 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 <tim@testit.works> 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 <marianop...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <tim@testit.works>
>>>>>>>>> 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
>>>>>>>>>> <marianop...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Aug 3, 2017 at 1:17 PM, Tim Mackinnon <tim@testit.works>
>>>>>>>>>> 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
>>>>>>>>>>>> <marianop...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <tim@testit.works>
>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <pavel.kriva...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2017-08-03 13:02 GMT+02:00 Tim Mackinnon <tim@testit.works>:
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> <pavel.kriva...@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2017-08-03 10:14 GMT+02:00 Pavel Krivanek
>>>>>>>>>>>>>>>> <pavel.kriva...@gmail.com>:
>>>>>>>>>>>>>>>>> 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 <tim@testit.works>:
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> <guillermopol...@gmail.com> 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
>>>>>>>>>>>>>>>>>>>> <pavel.kriva...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon
>>>>>>>>>>>>>>>>>>>> <tim@testit.works>:
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>> <pavel.kriva...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon
>>>>>>>>>>>>>>>>>>>>>> <tim@testit.works>:
>>>>>>>>>>>>>>>>>>>>>>> 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-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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Web: http://guillep.github.io
>>>>>>>>>>>>>>>>>>> Phone: +33 06 52 70 66 13
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Mariano
>>>>>>>>>>>> http://marianopeck.wordpress.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mariano
>>>>>>>>>> http://marianopeck.wordpress.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mariano
>>>>>>>> http://marianopeck.wordpress.com
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
