Pharo-dev

By thread

pharo-dev@lists.pharo.org

1 participants
144633 messages

Re: [Pharo-dev] fixing the tab morph

by Denis Kudriashov

Hi Esteban Did you check white theme? 2017-08-07 17:47 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > some remarks: > > 1) I find TabManagerMorph an ugly name. Do you think we should change it? > (I tend to think anything called *Manager, *Controller, etc. as a bad > naming chose and probably the mark of a smell). > 2) much more important: we should deprecate TabGroupMorph and > LazyTabGroupMorph familyâ¦ there should not be more than one widget to do > the same in the system. > These morphs are used for window tabs. > > So well, as usual with old things: you fix a little thing and you uncover > a lot of new problems :) > Yes and many internal things can be improved and cleaned. I want lazy behaviour where tab content is built only when tab is selected. It will improve performance (especially in remote case). > > Esteban > > >

Aug. 7, 2017

Re: [Pharo-dev] fixing the tab morph

by Guillermo Polito

I'm waiting your pull request here :) On Mon, Aug 7, 2017 at 5:47 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Soâ¦ summer project (to do when there is too much hot to go outside): fix > some minor things that are inside the image that annoys me since some time. > > First issue: the tab morph we have is horrible (and makes horrible > anything with it). > Iâve been working on it to fix that âchromish-but-badâ style we had and to > fix some (a lot) hardcoded colors there. > Now, for example, Calypso looks like this: > > > > > which is IMHO a lot better :) > > some remarks: > > 1) I find TabManagerMorph an ugly name. Do you think we should change it? > (I tend to think anything called *Manager, *Controller, etc. as a bad > naming chose and probably the mark of a smell). > 2) much more important: we should deprecate TabGroupMorph and > LazyTabGroupMorph familyâ¦ there should not be more than one widget to do > the same in the system. > > So well, as usual with old things: you fix a little thing and you uncover > a lot of new problems :) > > Esteban > > > -- 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

Aug. 7, 2017

fixing the tab morph

by Esteban Lorenzano

Hi, Soâ¦ summer project (to do when there is too much hot to go outside): fix some minor things that are inside the image that annoys me since some time. First issue: the tab morph we have is horrible (and makes horrible anything with it). Iâve been working on it to fix that âchromish-but-badâ style we had and to fix some (a lot) hardcoded colors there. Now, for example, Calypso looks like this: which is IMHO a lot better :) some remarks: 1) I find TabManagerMorph an ugly name. Do you think we should change it? (I tend to think anything called *Manager, *Controller, etc. as a bad naming chose and probably the mark of a smell). 2) much more important: we should deprecate TabGroupMorph and LazyTabGroupMorph familyâ¦ there should not be more than one widget to do the same in the system. So well, as usual with old things: you fix a little thing and you uncover a lot of new problems :) Esteban

Aug. 7, 2017

Re: [Pharo-dev] Creating the smallest server runtime footprint

by Tim Mackinnon

Hi Guillermo - its 64bit Iâm after for running AWS Lambda - the metacello version at 10mb looks very interesting (as the one Iâm using from build #27 is 15mb). However, given Iâm trying to find a stable place where I can develop on Pharo 6.1 and get a bit more experience - it looks like the latest post #27 images start breaking things for me with as I get weird errors (see below). But maybe your cleanup might resolve all of this. I really appreciate the work you guys are putting into have some minimal images - its very cool seeing all of this come together. Tim > On 7 Aug 2017, at 15:41, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Tim, > > in the file server: > > http://files.pharo.org/image/70/ <http://files.pharo.org/image/70/> > > You can get now latest 32 bit builds in many flavours: > - compiler (basic pharo image with just a compiler) > - core (compiler + package initialization) > - monticello bootstrap (core + basic monticello packages -- no network here!) > - monticello (monticello bootstrap + network support) > - metacello (monticello + metacello) > - default/full (image with everything loaded) > > If you check the built images you'll see that: > > - compiler is 4.7MB > - core is 5.6MB > - monticello bootstrap is 8.3MB > - monticello is 9MB > - metacello is 10MB > - full pharo is 30MB > > However, metacello and monticello images could be cleaned up a bit, as they still have some monticello cache to flush. > > I'm working on uploading 64 bit images too now. > > On Mon, Aug 7, 2017 at 4:26 PM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hey thanks again - it looks like that file is from Build #25 (I think Jenkins might cache the last 5 builds from the looks of it). > > Interestingly that image is 2mb smaller than the later ones (which is helpful) - however when I try to use it, I get a walkback because Metacello wasnât available in that build. > > (I then tried with build #29 the latest? and #28) - and then I get an error as it seems that the Locale class is not defined in that one? > > 'Errors in script loaded from minimal.st <http://minimal.st/>' > MessageNotUnderstood: receiver of "currentPlatform" is nil > UndefinedObject(Object)>>doesNotUnderstand: #currentPlatform > LanguageEnvironment class>>currentPlatform > LanguageEnvironment class>>defaultSystemConverter > TextConverter class>>defaultSystemConverter > MultiByteFileStream>>converter > MultiByteFileStream>>nextPut: > MultiByteFileStream(WriteStream)>>cr > UndefinedObject>>DoIt > > > So I guess the timing of my question was spot on as it looks like Iâve been running with build #27 for a few days (without realising I had cached it) and that one works. > > I would be interesting in working out how to get metacello in build #25 as its smaller size is attractive (assuming its not metacello support that adds 3mb to the image size), Do you think its worth it? Can I use the command line package loader to shoe-horn it in? > > Tim > > >> On 7 Aug 2017, at 13:47, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >> Unfortunately we store minimal versions only for the latest build and you should use older build with hash b1625bf32c6b2b6c6f8babb789e377af5132d740. >> >> You can download this image here (I have found a random copy of it): >> https://drive.google.com/open?id=0BzSsmZhqtUTeclFEbDhtd0JvdEk <https://drive.google.com/open?id=0BzSsmZhqtUTeclFEbDhtd0JvdEk> >> >> Copy it to some public location you can reach. >> >> -- Pavel >> >> >> 2017-08-07 14:25 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> Thanks Pavel - as Iâm downloading: >> >> curl -L -o min.zip https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastSuccessfulB… <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastSuccessfulB…> >> >> I noted that the last successful build of that asset was: >> Last stable build (#29), 2 days 23 hr ago <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastStableBuild/> >> Should I peg myself to a specific version that is more or less compatible with Pharo 6.1? I can see builds 28 (Aug 4 11am) or 27 (July 31?) - or should I go earlier? >> >> Can I rely on those builds sticking around - or should I cache one somewhere? >> >> Tim >> >>> On 7 Aug 2017, at 12:03, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>> >>> >>> >>> 2017-08-07 12:56 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@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(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@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(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@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(a)testit.works <mailto: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(a)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(a)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(a)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(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <tim(a)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", >>>>>>>>>> >>>>>>>>>>> On 3 Aug 2017, at 17:26, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Aug 3, 2017 at 1:17 PM, Tim Mackinnon <tim(a)testit.works <mailto: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 <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <tim(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-08-03 13:02 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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 <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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2017-08-03 10:14 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@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 <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(a)testit.works <mailto: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 <guillermopolito(a)gmail.com <mailto:guillermopolito@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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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 <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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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/lastSuccess… <https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccess…> 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-Configu… <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu…> 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/lastSu… <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSu…> 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/> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > > > > -- > > 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

Aug. 7, 2017

Re: [Pharo-dev] Creating the smallest server runtime footprint

by Guillermo Polito

Hi Tim, in the file server: http://files.pharo.org/image/70/ You can get now latest 32 bit builds in many flavours: - compiler (basic pharo image with just a compiler) - core (compiler + package initialization) - monticello bootstrap (core + basic monticello packages -- no network here!) - monticello (monticello bootstrap + network support) - metacello (monticello + metacello) - default/full (image with everything loaded) If you check the built images you'll see that: - compiler is 4.7MB - core is 5.6MB - monticello bootstrap is 8.3MB - monticello is 9MB - metacello is 10MB - full pharo is 30MB However, metacello and monticello images could be cleaned up a bit, as they still have some monticello cache to flush. I'm working on uploading 64 bit images too now. On Mon, Aug 7, 2017 at 4:26 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Hey thanks again - it looks like that file is from Build #25 (I think > Jenkins might cache the last 5 builds from the looks of it). > > Interestingly that image is 2mb smaller than the later ones (which is > helpful) - however when I try to use it, I get a walkback because Metacello > wasnât available in that build. > > (I then tried with build #29 the latest? and #28) - and then I get an > error as it seems that the Locale class is not defined in that one? > > 'Errors in script loaded from minimal.st' > MessageNotUnderstood: receiver of "currentPlatform" is nil > UndefinedObject(Object)>>doesNotUnderstand: #currentPlatform > LanguageEnvironment class>>currentPlatform > LanguageEnvironment class>>defaultSystemConverter > TextConverter class>>defaultSystemConverter > MultiByteFileStream>>converter > MultiByteFileStream>>nextPut: > MultiByteFileStream(WriteStream)>>cr > UndefinedObject>>DoIt > > > So I guess the timing of my question was spot on as it looks like Iâve > been running with build #27 for a few days (without realising I had cached > it) and that one works. > > I would be interesting in working out how to get metacello in build #25 as > its smaller size is attractive (assuming its not metacello support that > adds 3mb to the image size), Do you think its worth it? Can I use the > command line package loader to shoe-horn it in? > > Tim > > > On 7 Aug 2017, at 13:47, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Unfortunately we store minimal versions only for the latest build and you > should use older build with hash b1625bf32c6b2b6c6f8babb789e377 > af5132d740. > > You can download this image here (I have found a random copy of it): > https://drive.google.com/open?id=0BzSsmZhqtUTeclFEbDhtd0JvdEk > > Copy it to some public location you can reach. > > -- Pavel > > > 2017-08-07 14:25 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > >> Thanks Pavel - as Iâm downloading: >> >> curl -L -o min.zip https://ci.inria.fr/pharo/job/ >> 70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/l >> atest-minimal-64.zip >> >> I noted that the last successful build of that asset was: >> >> - Last stable build (#29), 2 days 23 hr ago >> <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastStableBuild/> >> >> Should I peg myself to a specific version that is more or less compatible >> with Pharo 6.1? I can see builds 28 (Aug 4 11am) or 27 (July 31?) - or >> should I go earlier? >> >> Can I rely on those builds sticking around - or should I cache one >> somewhere? >> >> Tim >> >> On 7 Aug 2017, at 12:03, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >> >> >> 2017-08-07 12:56 GMT+02:00 Tim Mackinnon <tim(a)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.krivanek(a)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(a)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.krivanek(a)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(a)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.krivanek(a)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(a)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(a)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(a)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(a)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(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <tim(a)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 < >>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 3, 2017 at 1:17 PM, Tim Mackinnon <tim(a)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)>>initializeAnaly >>>>>>>> zing:", >>>>>>>> "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 < >>>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <tim(a)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.krivanek(a)gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-08-03 13:02 GMT+02:00 Tim Mackinnon <tim(a)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.krivanek(a)gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-08-03 10:14 GMT+02:00 Pavel Krivanek <pavel.krivanek@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(a)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 < >>>>>>>>>>>> guillermopolito(a)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.krivanek(a)gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <tim(a)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.krivanek(a)gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <tim(a)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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > -- 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

Aug. 7, 2017

Re: [Pharo-dev] Creating the smallest server runtime footprint

by Tim Mackinnon

Hey thanks again - it looks like that file is from Build #25 (I think Jenkins might cache the last 5 builds from the looks of it). Interestingly that image is 2mb smaller than the later ones (which is helpful) - however when I try to use it, I get a walkback because Metacello wasnât available in that build. (I then tried with build #29 the latest? and #28) - and then I get an error as it seems that the Locale class is not defined in that one? 'Errors in script loaded from minimal.st' MessageNotUnderstood: receiver of "currentPlatform" is nil UndefinedObject(Object)>>doesNotUnderstand: #currentPlatform LanguageEnvironment class>>currentPlatform LanguageEnvironment class>>defaultSystemConverter TextConverter class>>defaultSystemConverter MultiByteFileStream>>converter MultiByteFileStream>>nextPut: MultiByteFileStream(WriteStream)>>cr UndefinedObject>>DoIt So I guess the timing of my question was spot on as it looks like Iâve been running with build #27 for a few days (without realising I had cached it) and that one works. I would be interesting in working out how to get metacello in build #25 as its smaller size is attractive (assuming its not metacello support that adds 3mb to the image size), Do you think its worth it? Can I use the command line package loader to shoe-horn it in? Tim > On 7 Aug 2017, at 13:47, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Unfortunately we store minimal versions only for the latest build and you should use older build with hash b1625bf32c6b2b6c6f8babb789e377af5132d740. > > You can download this image here (I have found a random copy of it): > https://drive.google.com/open?id=0BzSsmZhqtUTeclFEbDhtd0JvdEk <https://drive.google.com/open?id=0BzSsmZhqtUTeclFEbDhtd0JvdEk> > > Copy it to some public location you can reach. > > -- Pavel > > > 2017-08-07 14:25 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > Thanks Pavel - as Iâm downloading: > > curl -L -o min.zip https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastSuccessfulB… <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastSuccessfulB…> > > I noted that the last successful build of that asset was: > Last stable build (#29), 2 days 23 hr ago <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastStableBuild/> > Should I peg myself to a specific version that is more or less compatible with Pharo 6.1? I can see builds 28 (Aug 4 11am) or 27 (July 31?) - or should I go earlier? > > Can I rely on those builds sticking around - or should I cache one somewhere? > > Tim > >> On 7 Aug 2017, at 12:03, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >> >> >> 2017-08-07 12:56 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@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(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@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(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@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(a)testit.works <mailto: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(a)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(a)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(a)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(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <tim(a)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", >>>>>>>>> >>>>>>>>>> On 3 Aug 2017, at 17:26, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Aug 3, 2017 at 1:17 PM, Tim Mackinnon <tim(a)testit.works <mailto: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 <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <tim(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-08-03 13:02 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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 <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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-08-03 10:14 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@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 <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(a)testit.works <mailto: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 <guillermopolito(a)gmail.com <mailto:guillermopolito@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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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 <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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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/lastSuccess… <https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccess…> 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-Configu… <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu…> 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/lastSu… <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSu…> 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/> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > >

Aug. 7, 2017

Re: [Pharo-dev] Creating the smallest server runtime footprint

by Pavel Krivanek

Unfortunately we store minimal versions only for the latest build and you should use older build with hash b1625bf32c6b2b6c6f8babb789e377af5132d740. You can download this image here (I have found a random copy of it): https://drive.google.com/open?id=0BzSsmZhqtUTeclFEbDhtd0JvdEk Copy it to some public location you can reach. -- Pavel 2017-08-07 14:25 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > Thanks Pavel - as Iâm downloading: > > curl -L -o min.zip https://ci.inria.fr/pharo/job/ > 70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/ > latest-minimal-64.zip > > I noted that the last successful build of that asset was: > > - Last stable build (#29), 2 days 23 hr ago > <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastStableBuild/> > > Should I peg myself to a specific version that is more or less compatible > with Pharo 6.1? I can see builds 28 (Aug 4 11am) or 27 (July 31?) - or > should I go earlier? > > Can I rely on those builds sticking around - or should I cache one > somewhere? > > Tim > > On 7 Aug 2017, at 12:03, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2017-08-07 12:56 GMT+02:00 Tim Mackinnon <tim(a)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.krivanek(a)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(a)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.krivanek(a)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(a)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.krivanek(a)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(a)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(a)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(a)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(a)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(a)gmail.com> >>>>> wrote: >>>>> >>>>> >>>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <tim(a)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 <marianopeck(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 3, 2017 at 1:17 PM, Tim Mackinnon <tim(a)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)>>initializeAnaly >>>>>>> zing:", >>>>>>> "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 < >>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <tim(a)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.krivanek(a)gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2017-08-03 13:02 GMT+02:00 Tim Mackinnon <tim(a)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.krivanek(a)gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-08-03 10:14 GMT+02:00 Pavel Krivanek <pavel.krivanek@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(a)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 < >>>>>>>>>>> guillermopolito(a)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.krivanek(a)gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <tim(a)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.krivanek(a)gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <tim(a)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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > >

Aug. 7, 2017

Re: [Pharo-dev] Creating the smallest server runtime footprint

by Tim Mackinnon

Thanks Pavel - as Iâm downloading: curl -L -o min.zip https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastSuccessfulB… <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastSuccessfulB…> I noted that the last successful build of that asset was: Last stable build (#29), 2 days 23 hr ago <https://ci.inria.fr/pharo/job/70-Bootstrap-32bit-Conversion/lastStableBuild/> Should I peg myself to a specific version that is more or less compatible with Pharo 6.1? I can see builds 28 (Aug 4 11am) or 27 (July 31?) - or should I go earlier? Can I rely on those builds sticking around - or should I cache one somewhere? Tim > On 7 Aug 2017, at 12:03, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2017-08-07 12:56 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@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(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@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(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@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(a)testit.works <mailto: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(a)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(a)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(a)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(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <tim(a)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", >>>>>>>> >>>>>>>>> On 3 Aug 2017, at 17:26, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Aug 3, 2017 at 1:17 PM, Tim Mackinnon <tim(a)testit.works <mailto: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 <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <tim(a)testit.works <mailto: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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-08-03 13:02 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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 <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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-08-03 10:14 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@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 <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(a)testit.works <mailto: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 <guillermopolito(a)gmail.com <mailto:guillermopolito@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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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 <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.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto: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/lastSuccess… <https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccess…> 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-Configu… <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu…> 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/lastSu… <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSu…> 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/> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> > >

Aug. 7, 2017

Re: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names

by Guillermo Polito

On Mon, Aug 7, 2017 at 3:17 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, Aug 7, 2017 at 12:25 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> About tagging... It looks super ackward to me to tag EVERY commit with >>>> "build information". >>>> >>> >>> I'm not sure which comment your responding to, >>> >> >> yours :P. Yes, too early, I did not want to properly quote... >> >> >>> and not sure what you mean by "build information", >>> >> >> In this particular case I mean build number. >> >> but obviously someone may do several commits before doing a pull request, >>> as they work through developing and testing a fix for an Issue. Its only >>> the successful builds that are uploaded to files.pharo.org that are >>> important to tag. >>> >> >> But then, why not just going through the files in files.pharo.org and >> get the corresponding hash from there (since they have the hash they >> correspond to)? I do not see the practical usecase. It's just redundance, >> no? >> >> >>> Building does not mean releasing... I prefer the other way around: we >>>> tag builds with commit information. Like that we know how to reproduce the >>>> build. >>>> >>>> I'm ok with tagging build artifacts by explicitly saying "this is BUILD >>>> #X", which is ~= from "this is RELEASE #X". >>>> >>> >>> I'd imagine that tagging a commit as BUILD#X would be done as part of >>> the CI immediately before the upload to files.pharo.org. >>> >> >> That's what I wanto to avoid. Why is that required? The generated file >> already has a pointer to the git commit it was generated from. Why do we >> need the backpointer from git to the build? >> > > So should PharoLauncher attach a datestamp to each entity? > There needs to be something visible that a human can sort by. > I guess this is an interim solution until PharoLauncher is made to work > with Iceberg, but we need something working until then. > But PharoLauncher does not access commits. It never did. I think it gets all information from the file server and the naming schema of files... > > >> >> >>> >>> >>>> Moreover, before we needed to store ALL versions of the image because >>>> that was the way we versionned the system. Now, every commit in the >>>> #development branch should be buildable (delta some bugs of course ;)). >>>> This means that we can rebuild all images by just iterating the git history >>>> and building from scratch. >>>> >>> >>> I don't understand why you'd need to iterate git history. >>> Shouldn't you be able to rebuild an image from a single git commit? >>> >> >> Yes you are. I meant in here that "if you want to rebuild all images from >> files.pharo.org" you can walk all commits. >> > > got it. > > >> >> >>> >>> >>>> No need to store all images. >>>> >>> >>> Do you mean on files.pharo.com? >>> That might be a good later goal, but for now these resultant images are >>> useful to work with PharoLauncher without expending effort on redeveloping >>> that to also rebuild images on the fly. >>> >>> >> >> Yeah, I did not mean that we have to change it. But we have to keep in >> mind that before files.pharo.org was used for versioning purposes but in >> a process where we are bootstrapping from sources, the intermediate >> generated images are build artifacts and are just a "cache". >> >> I know the launcher depends on it right now, but does it make sense that >> it provides access to every alpha image >> > > It may make sense when someone wants to bisect an Issue to determine when > a defect was introduced. > How does the time downloading ten images compare to bootstrapping ten > images? > True true. That's why I say it's a cache :). While this is cheap enough to have all builds stored, I'm ok with it. > > > >> >> >>> Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUIL >>>>> D_NUMBER}.zip >>>>> >>>> >>> +1 to Torsten's suggestion to put the BUILD_NUMBER first, since it is >>> more sortable than HASH. >>> >> >> Ok, that's easily doable :) >> >> https://github.com/pharo-project/pharo/pull/185/files#diff-b >> f8112f4242808a7d70517e28088f72b >> >> >>> By "arch", do you mean Win/Linux/Mac? Or were labelling the bit-ness >>> field? >>> >> >> bitness. Images are portable between operating systems but not between >> 32&64 bit vms. >> >> >>> Also, is it important to prepend these with the numbers with "build." >>> and "sha." fieldname strings? This bulks out the name increases the chance >>> some interface needs to mangle the name to fit into a thin column. >>> >> >> I like that they make the metadata more explicit. Otherwise we will start >> having strange scripts that have magic numbers here and there. At least >> like this we can read the file name and identify what is each field. I >> prefer to pay some extra bytes in filenames... >> >> About column names in UIs.... That's a UI problem. I'd not design the >> filename of our build artifacts because of a UI... >> > > fair enough. > > >> >> >>> >>> >>> While we are discussion version naming (and I ask this from a position >>> of ignorance) >>> could you discuss with your team, without insider knowledge, how do we >>> distinguish between the released 7.0.0 and all the 7.0.0 development builds >>> heading towards that release? >>> Can we add something to distinguish the development phase >>> i.e. alpha/beta/rc/release (which coincidentally sort well with build >>> numbers.) >>> >>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-alpha.${BUILD_NUMBER}.${HASH}.zip >>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-beta.${BUILD_NUMBER}.${HASH}.zip >>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-rc.${BUILD_NUMBER}.${HASH}.zip >>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-release.${BUILD_NUMBER}.${HASH}. >>> zip >>> >>> beta might be the defined point to ask applications to test-port to the >>> new version, this perhaps being the optimum point to get fixes into the the >>> next release. >>> >> >>> or if you don't want to be that sophisticated, maybe just phases dev/rel >>> >> >> I like that. The only thing is that right now what is "alpha" version is >> managed in the file server as "latest". That will otherwise break zeroconf >> scripts that depend on that. >> >> I'd say every build in development is alpha so far. At some point we will >> move to beta. Releases and release candidates should be managed explicitly >> (like there is someone that will decide "this is a release and I'll tag it >> explicitly like it"). >> >> >>> >>> or for a more continuous release process, maybe '#' for the patch >>> number... >>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-${BUILD_NUMBER}.${HASH}.zip >>> (since '#' sorts before '0') >>> >> >> I did not get this one. >> > > I was thinking something like below, but perhaps it gets too awkward after > 7.0.0. > > Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70001.sha.${HASH}.zip > Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70002.sha.${HASH}.zip > ... > Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70639.sha.${HASH}.zip > Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-.build.70640.sha.${HASH}.zip > Pharo-${IMAGE_KIND}${BITNESS}-7.0.1-.build.70641.sha.${HASH}.zip > Pharo-${IMAGE_KIND}${BITNESS}-7.0.2-.build.70642.sha.${HASH}.zip > Ah! I understand now. You want to tag with a # the latest build. > > > cheers -ben > -- 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

Aug. 7, 2017

Re: [Pharo-dev] Creating the smallest server runtime footprint

by Pavel Krivanek

2017-08-07 12:56 GMT+02:00 Tim Mackinnon <tim(a)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.krivanek(a)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(a)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.krivanek(a)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(a)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.krivanek(a)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(a)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(a)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(a)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(a)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(a)gmail.com> >>>> wrote: >>>> >>>> >>>> On Thu, Aug 3, 2017 at 2:14 PM, Tim Mackinnon <tim(a)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 <marianopeck(a)gmail.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On Thu, Aug 3, 2017 at 1:17 PM, Tim Mackinnon <tim(a)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 <marianopeck(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <tim(a)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.krivanek(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-08-03 13:02 GMT+02:00 Tim Mackinnon <tim(a)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.krivanek(a)gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2017-08-03 10:14 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)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(a)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 < >>>>>>>>>> guillermopolito(a)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.krivanek(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <tim(a)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.krivanek(a)gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <tim(a)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 >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > >

Aug. 7, 2017

Jump to page: