HURRAH - I got it to work, and Fuel out an error to S3 and read it back into a
fat 6.1 image with a debug stack (which is so cool!).
My footprint size is still a bit larger than I would like (31mb - image of
22.7mb - of which 1mb if fuel and 7mb is S3 and XMLParser support) - so I guess
I need to find ways to trim down some of the addons (and any additional image
size reductions would be helpful - if there are any to be had).
Is there any easy tools/scripts to explore a headless image and figure out what
takes the most size (maybe at a package level?). But definitely this has got me
into a good place for experimentation.
For the record I had to do the following to get things working:
Define a new baseline:
baseline: spec
<baseline>
spec for: #common do: [
spec
package: 'Metacello-GitBasedRepository';
package: 'Metacello-GitHub';
package: 'FuelPlatform-Core';
package: 'FuelPlatform-Pharo-Core';
package: 'FuelPlatform-Pharo-06';
package: 'Fuel'.
].
Run the following script:
Metacello new
baseline: 'MetacelloGitBasedRepository';
repository: 'filetree://../bootstrap';
load.
“Replace missing traits"
Behavior compiledMethodAt: #fuelIgnoredInstanceVariableNames
ifPresent: [ :m | logger cr; nextPutAll: 'Trait method is present' ]
ifAbsent: [
logger cr; nextPutAll: 'Recompile missing traits ...'.
Behavior
compile: 'fuelIgnoredInstanceVariableNames
"Indicates which variables have to be ignored during
serialization."
^#()';
compile: 'fuelNew
"Answer an instance of mine in which serialized
references will be injected."
^ self basicNew';
compile: 'fuelNew: sizeRequested
"Answer an instance of mine in which serialized
references will be injected."
^ self basicNew: sizeRequested'.
"Ignore this one"
"Class
compile: 'fuelAccept: aGeneralMapper
^self explicitRequirement.'."
ClassDescription
compile: 'instanceVariableNamesDo: anUnaryBlock
"This is part of the interface between the compiler and
a class''s instance or field names.
The class should enumerate anUnaryBlock with the
instance variable name strings. The order is important. Names evaluated later
will override the
same names occurring earlier."
| superInstSize |
(superInstSize := self superclass notNil ifTrue: [self
superclass instSize] ifFalse: [0]) > 0 ifTrue:
[self superclass instanceVariableNamesDo:
anUnaryBlock].
1 to: self instSize - superInstSize do:
[:i| anUnaryBlock value: (self instVarNames at: i)]'.
].
“Add a tacky Pharo7Platform"
Smalltalk at: #FLPharo7Platform ifAbsent: [
logger cr; nextPutAll: '>Creating FLPharo7Platform'.
(Smalltalk at: #FLPharo6Platform) subclass: #FLPharo7Platform.
(Smalltalk at: #FLPharo6Platform) class compile:
'isResponsibleForCurrentPlatform
^true'.
].
logger cr; nextPutAll: 'Evaluating post load initialization...'.
(Smalltalk at: #FLPlatform) current addHacks.
> On 4 Aug 2017, at 12:48, Mariano Martinez Peck <[email protected]> wrote:
>
>
>
> On Fri, Aug 4, 2017 at 8:42 AM, Tim Mackinnon <[email protected]
> <mailto:[email protected]>> wrote:
> 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.
>
>
>
> Max, should we do something to the Fuel Platform for Pharo 7?
>
>
>
> Tim
>
>
>
>> On 4 Aug 2017, at 12:20, Tim Mackinnon <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> I’ve spotted something interesting in my logs - when I added one of the
>> missing methods to ClassDescription - I see in the log the message:
>>
>> Loaded -> Fuel-cypress.1 --- filetree:///builds/macta/PharoLambda/bootstrap
>> <> --- cache
>> ...finished baseline
>> Compiling missing traits...
>> Evaluating post load initialization...
>> Finished Script.
>>
>> However when I remove all the compiles I don’t see this message:
>>
>> Loaded -> Fuel-cypress.1 --- filetree:///builds/macta/PharoLambda/bootstrap
>> <> --- cache
>> ...finished baseline
>> Evaluating post load initialization...
>> Finished Script.
>>
>>
>> So I wonder if this is similar to the problem I had in the previous 6.0
>> image - where some things didn’t seem to compile properly (in that case, it
>> was loading a missing class that didn’t seem to cause recompilation).
>>
>> Tim
>>
>>> On 4 Aug 2017, at 11:10, Tim Mackinnon <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Actually there is something weird going on - as now I’m getting a complaint
>>> about "FLPharoPlatform had the subclass responsibility to implement
>>> #isBigEndian”, and that’s in the FuelPlatform-Pharo-06 which you said to
>>> include (and it looks like I am).
>>>
>>> I need to double check this - as I must be making some trivial mistake.
>>>
>>> Tim
>>>
>>>> On 4 Aug 2017, at 11:01, Tim Mackinnon <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Hi Mariano - I’ve looked at this again, and it was my fault - I was
>>>> compiling in :
>>>>
>>>> fuelAccept: aGeneralMapper
>>>> ^self explicitRequirement.
>>>>
>>>> Because when I looked at the Traits for fuel - this is what it had for
>>>> TClass? - as I’m not so clear on traits, what does this mean - as I had
>>>> just assumed that I should flatten the Fuel methods for TCLass, TBehaviour
>>>> and TClassDescription - but I think I’ve misunderstood what I should do
>>>> (and I guess from Pavel’s comment - I should really look at why that
>>>> initial method was missing as it sounds like it should have worked - so
>>>> maybe its an order loading thing?).
>>>>
>>>> Thanks, for helping by the way - this is proving very instructional.
>>>>
>>>> Tim
>>>>
>>>>> On 3 Aug 2017, at 18:26, Mariano Martinez Peck <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>
>>>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>> Hi Mariano - I compiled in the trait methods manually and it got further
>>>>> - but now I’m seeing another error - Error: Explicitly required method",
>>>>> "\u001b[0mLambda class(Object)>>error:",
>>>>> "explicitRequirement”,
>>>>>
>>>>>
>>>>> mmmm the stack is weird... it looks like if Class >> fuelAccept: would
>>>>> have the wrong implementation, that is, having the one from TClass:
>>>>>
>>>>> fuelAccept: aGeneralMapper
>>>>> ^self explicitRequirement.
>>>>>
>>>>> Rather than the correct one:
>>>>>
>>>>> fuelAccept: aGeneralMapper
>>>>>
>>>>> ^aGeneralMapper visitClass: self
>>>>>
>>>>>
>>>>> Maybe the solution is to compile all those methods from traits BUT NOT
>>>>> those that are "^self explicitRequirement." because those will override
>>>>> the good methods.
>>>>>
>>>>> If that doesn't work, then maybe can you print to console the each impl
>>>>> (source) of each implementor of #fuelAccept: ?
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Tim
>>>>>
>>>>> "--- RUNNING ERROR HANDLER ---",
>>>>> "Error: Explicitly required method",
>>>>> "",
>>>>> "\u001b[0m\u001b[31mError: Explicitly required method",
>>>>> "\u001b[0mLambda class(Object)>>error:",
>>>>> "explicitRequirement",
>>>>> " self error: 'No decompiler available' in Lambda
>>>>> class(Object)>>explicitRequirement in Block: explicitRequirement...",
>>>>> "False>>ifFalse:",
>>>>> "Lambda class(Object)>>explicitRequirement",
>>>>> "Lambda class(Class)>>fuelAccept:",
>>>>> "FLLightGeneralMapper>>mapAndTrace:",
>>>>> "FLLightGlobalMapper>>mapAndTrace:",
>>>>> "FLPluggableSubstitutionMapper>>mapAndTrace:",
>>>>> "FLAnalysis>>mapAndTrace:",
>>>>> "FLAnalysis>>run",
>>>>> "setDefaultAnalysis",
>>>>> " self error: 'No decompiler available' in
>>>>> FLAnalyzer>>setDefaultAnalysis in Block: setDefaultAnalysis...",
>>>>> "FLAnalyzer>>analysisFor:",
>>>>> "FLSerialization>>analysisStep",
>>>>> "FLSerialization>>run",
>>>>> "setDefaultSerialization",
>>>>> " self error: 'No decompiler available' in
>>>>> FLSerializer>>setDefaultSerialization in Block:
>>>>> setDefaultSerialization...",
>>>>> "serialize: t1 on: t2",
>>>>> " self error: 'No decompiler available' in
>>>>> FLSerializer>>serialize:on: in Block: serialize: t1 on: t2...",
>>>>> "on: t1 globalEnvironment: t2 do: t3",
>>>>> " self error: 'No decompiler available' in FLEncoder
>>>>> class>>on:globalEnvironment:do: in Block: on: t1 globalEnvironment: t2
>>>>> do: t3...",
>>>>> "BlockClosure>>ensure:",
>>>>> "FLEncoder class>>on:globalEnvironment:do:",
>>>>> "FLSerializer>>serialize:on:",
>>>>> "NonInteractiveUIManager>>writeFuelContext:",
>>>>> "Lambda class>>processDebug:",
>>>>> "Lambda class>>processJSON:",
>>>>> "Lambda class>>process:",
>>>>> "activate",
>>>>>
