Pharo-dev

By thread

pharo-dev@lists.pharo.org

3 participants
144616 messages

[ann] moldable brick editor - alpha

by Tudor Girba

Hi, We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc) This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors. Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters. The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor. Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area. The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure (https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice. We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector. This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable. We will continue the work on this over the next period and we expect to announce new developments soon. If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development Please let us know what you think. Cheers, Alex and Doru -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

Aug. 4, 2017

Re: [Pharo-dev] About cr and lf

by Tudor Girba

+1. We need a basic representation of those characters. Logical ones should be derived from the simple ones. Doru > On Aug 4, 2017, at 3:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet(a)gmail.com> wrote: >> >> I agree with Pablo, #cr and #lf should not be clever and just be names for the carriage return and linefeed characters/codepoints. > > +1 > >> >> Making #newLine's behavior dependent on the current platform disturbs me, though. I'd rather have: >> >> Stream >> newLineFor: platform >> self nextPutAll: platform lineEnding >> >> Stream >> newLineForCurrentPlatform >> self newLineFor: OSPlatform current >> >> Stream >> newLineForWindows "convenience for the most common platforms >> Stream >> newLineForUnix >> Stream >> newLineForHistoricReasons >> >> Stream >> newLine >> "delegates to one of the above, I'd argue for unix for convenience, but windows is the technically correct combination of cr + lf, and cr only is the historic one" >> >> >> On 4 August 2017 at 14:25, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: >> To me it is clear that cr and lf should be in streams. But they should put the 'cr' or 'lf' character only. And of course the platform independent newline should be also. >> >> The first (cr, lf) should be used by the code wanting to have absolute control of what is in the stream. The later (newline) when you just want a new line. >> >> The two have completely different behaviour, ones are really low level, the other is higher level. >> >> On 4 Aug 2017 14:20, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: >> >> > On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> > >> > Well. This is not implemented like that in Pharo. >> > >> > cr is bad because it does not mean that it is independent of the platform. >> > So cr can be redefined as newLine and keep but not used inside the system. >> >> sometimes you actually want to write a cr (or a lf). So it needs to remain in the system, of course. >> now, including #newLine can be cool (most of the times you want the âplatform compatibleâ new line). Also I would consider including #nl, abbreviatedâ¦ just for convenience :P >> >> Esteban >> >> > >> > Stef >> > >> > On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >> On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote: >> >>> Hi guys >> >>> >> >>> While writing pillar code, I ended up using "stream cr" and it >> >>> worries >> >>> me to still expand usage >> >>> of a pattern I would like to remove. >> >>> >> >>> Let us imagine that we would like to prepare the migration from cr. >> >>> I was thinking that we could replace cr invocation by newLine so that >> >>> after newLine >> >>> could be redefined as >> >>> >> >>> Stream >> newLine >> >>> self nextPutAll: OSPlatform current lineEnding >> >>> >> >>> >> >>> what do you think about this approach? >> >> >> >> Why not? But please keep #cr. >> >> >> >> Section 5.9.4.1 of ANSI reads: >> >> >> >> Message: cr >> >> >> >> Synopsis >> >> Writes an end-of-line sequence to the receiver. >> >> >> >> Definition: <puttableStream> >> >> A sequence of character objects that constitute the implementation- >> >> defined end-of-line sequence is added to the receiver in the same >> >> manner as if the message #nextPutAll: was sent to the receiver with >> >> an argument string whose elements are the sequence of characters. >> >> >> >> Return Value >> >> UNSPECIFIED >> >> Errors >> >> It is erroneous if any element of the end-of-line sequence is an >> >> object that does not conform to the receiver's sequence value type . >> >> >> >> my 2c, >> >> >> >> Jan >> >> >> >>> >> >>> Stef >> >>> >> >> >> > >> >> >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet > -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Aug. 4, 2017

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

by Pavel Krivanek

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> 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: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. 4, 2017

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

by Tim Mackinnon

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/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> 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> 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> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Aug 3, 2017 at 8:58 AM, Tim Mackinnon <tim(a)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> 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/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… 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… one gives me a walkback when trying to run my install script : >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 25 UndefinedObject(Object)>>doesNotUnderstand: #addTo: >>>>>>>>>>>>>>>>>>>>>>> 26 MCRepositoryGroup>>addRepository: >>>>>>>>>>>>>>>>>>>>>>> 27 createRepository >>>>>>>>>>>>>>>>>>>>>>> | repo | >>>>>>>>>>>>>>>>>>>>>>> repo := self project createRepository: self. >>>>>>>>>>>>>>>>>>>>>>> ^ MCRepositoryGroup default repositories >>>>>>>>>>>>>>>>>>>>>>> detect: [ :each | each = repo ] >>>>>>>>>>>>>>>>>>>>>>> ifNone: [ >>>>>>>>>>>>>>>>>>>>>>> MCRepositoryGroup default addRepository: repo. >>>>>>>>>>>>>>>>>>>>>>> repo ] in MetacelloRepositorySpec>>createRepository >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think this is because the image doesnât support Metacello? As in: >>>>>>>>>>>>>>>>>>>>>>> Metacello new >>>>>>>>>>>>>>>>>>>>>>> repository: 'filetree://../src'; >>>>>>>>>>>>>>>>>>>>>>> baseline: 'Lambda'; >>>>>>>>>>>>>>>>>>>>>>> load. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> How do you guys load things into the minimal images (I thought you used Metacello - but maybe you do it some other way?) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I can use a big 6.1 image fine (as it has Metacello loaded) but Iâd really like a minimal solution - that can load in libraries like AWS S3, or XML parsing etc. and it seems like I should be a good customer for kicking the tires on all of this. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Tim >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I checked the 64-bit Pharo 7 minimal image and loading of baseline (of SUnit from pharo-project/pharo) works: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval --save "Metacello new baseline: 'SUnit'; repository: 'filetree://./pharo-core/src'; load." >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval "TestCase suite run" >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Can you test it too? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- Pavel >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Guille Polito >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Research Engineer >>>>>>>>>>>>>>>>>>> French National Center for Scientific Research - http://www.cnrs.fr >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Web: http://guillep.github.io >>>>>>>>>>>>>>>>>>> Phone: +33 06 52 70 66 13 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Mariano >>>>>>>>>>>> http://marianopeck.wordpress.com >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mariano >>>>>>>>>> http://marianopeck.wordpress.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mariano >>>>>>>> http://marianopeck.wordpress.com >>>>>>> >>>>>> >>>>> >>>> >>> >> >

Aug. 4, 2017

Re: [Pharo-dev] About cr and lf

by Damien Pollet

On 4 August 2017 at 18:52, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Fri, Aug 04, 2017 at 03:41:05PM +0200, Damien Pollet wrote: > > > Stream >> newLineForWindows "convenience for the most common platforms > > Stream >> newLineForUnix > > Stream >> newLineForHistoricReasons > > Practically speaking this looks insanely wordy. In 102% (est.) you want to > use the same consistent newline and not thinking about for which platform > you are writing every time you want to write a new line. > Hmm, granted :) > I think that most WriteStream miss what MultiByteFileStream has -- > lineEndConvention. > > fileStream lineEndConvention: #lf. > Agreed. > fileStream cr. "<- this will be autoconverted to #lf" > Noâ¦ please don't abuse a low-level explicit selector to mean something context-dependent. Also I would like to see a situation where you actually _want_ to use > different line endings at the same time, so converting lf/cr to the global > one shouldn't break things. > But it's uglyâ¦ > So maybe instead of stating what kind of line ending you want to write, > you would specify them for the whole stream > > > Stream >> newLineForWindows "convenience for the most common platforms > > Stream >> newLineForUnix > > Stream >> newLineForHistoricReasons > > Stream>>beForCurrentPlatform (would be the default maybe?) > > Stream>>beForWindows "crlf" > Stream>>beForUnix "lf" > Stream>>beAnnoyingOutsideOfPharo "cr" Yes, I actually prefer that to my own proposition, just don't make #cr and #lf contextually put something else than their name implies. #newline (or #nl if you prefer it concise) should be the contextual message -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 4, 2017

Re: [Pharo-dev] About cr and lf

by Gabriel Cotelli

I vote for: #cr and #lf just put this character in the stream. #newLine put the underlying OS line ending. This is consisten also with String>>expandMacrosWithArguments: <r> -> cr <l> -> lf <n> -> OSPlatform current lineEnding On Fri, Aug 4, 2017 at 7:03 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi guys > > While writing pillar code, I ended up using "stream cr" and it worries > me to still expand usage > of a pattern I would like to remove. > > Let us imagine that we would like to prepare the migration from cr. > I was thinking that we could replace cr invocation by newLine so that > after newLine > could be redefined as > > Stream >> newLine > self nextPutAll: OSPlatform current lineEnding > > > what do you think about this approach? > > Stef > >

Aug. 4, 2017

Re: [Pharo-dev] About cr and lf

by Jan Vrany

On Fri, 2017-08-04 at 14:06 +0200, Stephane Ducasse wrote: > Well. This is not implemented like that in Pharo. > > cr is bad because it does not mean that it is independent of the > platform. > So cr can be redefined as newLine and keep but not used inside the > system. Yes, that's exactly what I meant. cr self newLine Jan > > Stef > > On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > wrote: > > On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote: > > > Hi guys > > > > > > While writing pillar code, I ended up using "stream cr" and it > > > worries > > > me to still expand usage > > > of a pattern I would like to remove. > > > > > > Let us imagine that we would like to prepare the migration from > > > cr. > > > I was thinking that we could replace cr invocation by newLine so > > > that > > > after newLine > > > could be redefined as > > > > > > Stream >> newLine > > > Â Â Â Â Â Â Â self nextPutAll: OSPlatform current lineEnding > > > > > > > > > what do you think about this approach? > > > > Why not? But please keep #cr. > > > > Section 5.9.4.1 of ANSI reads: > > > > Message: cr > > > > Synopsis > > Â Writes an end-of-line sequence to the receiver. > > > > Definition: <puttableStream> > > Â A sequence of character objects that constitute the > > implementation- > > Â defined end-of-line sequence is added to the receiver in the same > > Â manner as if the messageÂ Â #nextPutAll: was sent to the receiver > > with > > Â an argument string whose elements are the sequence of characters. > > > > Return Value > > Â UNSPECIFIED > > Errors > > Â It is erroneous if any element of the end-of-line sequence is an > > Â object that does not conform to the receiver's sequence value type > > . > > > > my 2c, > > > > Jan > > > > > > > > Stef > > > > >

Aug. 4, 2017

Re: [Pharo-dev] About cr and lf

by Peter Uhnak

On Fri, Aug 04, 2017 at 03:41:05PM +0200, Damien Pollet wrote: > Stream >> newLineForWindows "convenience for the most common platforms > Stream >> newLineForUnix > Stream >> newLineForHistoricReasons Practically speaking this looks insanely wordy. In 102% (est.) you want to use the same consistent newline and not thinking about for which platform you are writing every time you want to write a new line. I think that most WriteStream miss what MultiByteFileStream has -- lineEndConvention. fileStream lineEndConvention: #lf. fileStream cr. "<- this will be autoconverted to #lf" Also I would like to see a situation where you actually _want_ to use different line endings at the same time, so converting lf/cr to the global one shouldn't break things. So maybe instead of stating what kind of line ending you want to write, you would specify them for the whole stream > Stream >> newLineForWindows "convenience for the most common platforms > Stream >> newLineForUnix > Stream >> newLineForHistoricReasons Stream>>beForCurrentPlatform (would be the default maybe?) Stream>>beForWindows "crlf" Stream>>beForUnix "lf" Stream>>beAnnoyingOutsideOfPharo "cr" Peter > > Stream >> newLine > "delegates to one of the above, I'd argue for unix for convenience, but > windows is the technically correct combination of cr + lf, and cr only is > the historic one" > > > On 4 August 2017 at 14:25, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > > > To me it is clear that cr and lf should be in streams. But they should put > > the 'cr' or 'lf' character only. And of course the platform independent > > newline should be also. > > > > The first (cr, lf) should be used by the code wanting to have absolute > > control of what is in the stream. The later (newline) when you just want a > > new line. > > > > The two have completely different behaviour, ones are really low level, > > the other is higher level. > > > > On 4 Aug 2017 14:20, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > > > >> > >> > On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self(a)gmail.com> > >> wrote: > >> > > >> > Well. This is not implemented like that in Pharo. > >> > > >> > cr is bad because it does not mean that it is independent of the > >> platform. > >> > So cr can be redefined as newLine and keep but not used inside the > >> system. > >> > >> sometimes you actually want to write a cr (or a lf). So it needs to > >> remain in the system, of course. > >> now, including #newLine can be cool (most of the times you want the > >> âplatform compatibleâ new line). Also I would consider including #nl, > >> abbreviatedâ¦ just for convenience :P > >> > >> Esteban > >> > >> > > >> > Stef > >> > > >> > On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > >> wrote: > >> >> On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote: > >> >>> Hi guys > >> >>> > >> >>> While writing pillar code, I ended up using "stream cr" and it > >> >>> worries > >> >>> me to still expand usage > >> >>> of a pattern I would like to remove. > >> >>> > >> >>> Let us imagine that we would like to prepare the migration from cr. > >> >>> I was thinking that we could replace cr invocation by newLine so that > >> >>> after newLine > >> >>> could be redefined as > >> >>> > >> >>> Stream >> newLine > >> >>> self nextPutAll: OSPlatform current lineEnding > >> >>> > >> >>> > >> >>> what do you think about this approach? > >> >> > >> >> Why not? But please keep #cr. > >> >> > >> >> Section 5.9.4.1 of ANSI reads: > >> >> > >> >> Message: cr > >> >> > >> >> Synopsis > >> >> Writes an end-of-line sequence to the receiver. > >> >> > >> >> Definition: <puttableStream> > >> >> A sequence of character objects that constitute the implementation- > >> >> defined end-of-line sequence is added to the receiver in the same > >> >> manner as if the message #nextPutAll: was sent to the receiver with > >> >> an argument string whose elements are the sequence of characters. > >> >> > >> >> Return Value > >> >> UNSPECIFIED > >> >> Errors > >> >> It is erroneous if any element of the end-of-line sequence is an > >> >> object that does not conform to the receiver's sequence value type . > >> >> > >> >> my 2c, > >> >> > >> >> Jan > >> >> > >> >>> > >> >>> Stef > >> >>> > >> >> > >> > > >> > >> > >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 4, 2017

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

by Pavel Krivanek

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> 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: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> 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> >>>>> 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. 4, 2017

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

by Ben Coman

On Fri, Aug 4, 2017 at 3:22 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Ben, > > reason is that for Pharo 7 currently an sha git hash is used in the file > name > instead of a (more clear) build number. > > See http://files.pharo.org/image/70/ > > This problem (which has more side effects on different sides, not only the > Launcher now) was discussed > already yesterday on Discord #iceberg channel with Esteban and Pavel. > > The current sha based image file name scheme is not only confusing but has > some downsides. > One can not easily remember the SHA or see which image is the latest, or > sort from recent > images to older in a folder. > > If I understood correctly the reason to (initially) choose sha's in the > image name has something > to do with Travis and a discussion between Pavel, Esteban and Guille. > > I would vote for using Build numbers again. > > We would have several BENEFITS when keeping/returning to build numbers for > Pharo 7: > - we do not change image file names, about box behavior, ... compared to > previous Pharo version < 7 > (as we used image build number already in the past) > - we tag each release as before and see it in Git (we can easily > reproduce) > - the build number easily tells you which image is more recent (as before) > - we can easily sort when we have several images in a directory > - a build number is more readable and recognizable by a human (compared > to the shas) > - Pharo is not an "aliens" compared to the rest of the software world as > often software > follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) > - we do not change the order in Launcher (higher numbers at the top to > download more recent) > > According to the discussion with Esteban and Pavel it is technically > possible to have build numbers again - > it means to tag each commit again with a build number (we already did this > for Pharo 6, > see https://github.com/pharo-project/pharo/releases) > Annotating build-commits with tags "seems" the right way to go, but I haven't played with them much. There does seem to some potential confusion in how tags operate to pay attention to... https://stackoverflow.com/questions/16678072/fetching-all-tags-from-a-remot… The example here by joshtkling that has two fetch lines might be useful (but I'm not sure if thats relevant to libgit or just to command-line git)... https://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/ cheers -ben > > The outcome from yesterday was that Pavel will discuss again with Guile on > that topic. It would be good if others > could comment on that topic too. Maybe we can return to the known build > number scheme > or (if there are problems with that) at least know the arguments why we > need to be exotic/different on > this corner in the future. > > Thanks > T. > > *Gesendet:* Donnerstag, 03. August 2017 um 15:41 Uhr > *Von:* "Ben Coman" <btc(a)openinworld.com> > *An:* "Pharo Development List" <pharo-dev(a)lists.pharo.org> > *Betreff:* [Pharo-dev] PharoLauncher - uninformative Pharo7 template names > > Attached is what I see for Pharo 7 images in PharoLauncher. > I presume the top one is the latest, but Its a bit hard to tell :P > Anyone else seeing this? > > Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) > and doing "ConfigurationOfPharoLauncher loadDevelopment" > which loads PharoLauncher-Core-ChristopheDemarey.116 (latest) > > This is with Pharo builds 60486 and 60510, and same VM for both... > Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker > versionString VM: 201705310241 > CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 > May 31 2017 > > (but btw, does that look strange? The 60510 image was lauched from the > original 60486-PharoLauncher which said it was downloading the matching VM, > so I kind of expect each image to have a different VM ?? ) > > cheers -ben >

Aug. 4, 2017

Jump to page: