2017-08-07 12:56 GMT+02:00 Tim Mackinnon <tim@testit.works>:

> 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 <pavel.kriva...@gmail.com> 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 <tim@testit.works>:
>
>> 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/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 <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> 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 <marianop...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <tim@testit.works> 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 <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-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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

Reply via email to