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 <marianopeck@gmail.com> wrote:
On Fri, Aug 4, 2017 at 8:42 AM, Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>> 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 <tim@testit.works <mailto: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 <mailto: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 <mailto: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 <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote:
On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <tim@testit.works <mailto: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",