November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Who broke my System Preferences ?

by stepharo

> yeaâ¦ I wanted to normally move the whole class somewhere else, but then I stopped and just committed > what I had. > > I did the #theme thing because it looks so ugly to have #theme implemented everywhere > (we have 33 implementors! 33!!) > and I just saw two senders in this classâ¦ > > All the Theme stuff is so uglyâ¦ Yes but let it like that for the moment. I would prefer that you push OPAL because we need a strong OPAL + slot + reflectivity for the future. Stef > >> May be changing >> theme >> UIManager default theme >> >> by >> theme >> ^ Smalltalk ui theme >> >> is better but not expanding all the self theme with this expression >> Because we do not know in the future how the theme will be implemented in the future. >> >> Stef >> >> >> On 10/11/14 14:46, Marcus Denker wrote: >>>> On 10 Nov 2014, at 14:18, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>> looks like latest Pharo 4 40363 broke System Preferences clicking on Appearance gives me this >>>> >>> Oh, I missed call in fontSizeRowâ¦ I thought I tested it. I will fix it... >>> (Hint: I always wait for people to review my changesâ¦ but that does not happen very often) >>> >>> >>> Marcus >>> >>> >> > >

Nov. 15, 2014

Re: [Pharo-dev] [Bloc] Getting involved

by stepharo

On 11/11/14 00:43, Santiago Bragagnolo wrote: > Hi Guys, (Alan and Steph punctually) I want to comment I am getting > involved with Bloc, since i need to draw several things and i need an > Athens canvas. > > I am checking if it is the best tool for my needs. In any case I am > doing some contributions that i would like to commit and to share. > Actually i am working on draft a window, a tool bar, a button based on > images and animations. > > Then, there is any mailing list for Bloc? How is the push-request cycle? Alain told me that you should design a widget and based on the quality he will let you commit :) I'm confident. So let us know which widget you want to work on. Stef > > Thanks :). > > Santiago. >

Nov. 15, 2014

Re: [Pharo-dev] cross platform issue with versionner in pharo 3.0 - want a slice?

by stepharo

> Hey - > > I'm thinking about making a slice to that versionner doesn't use Symbols for class names when creating baselines. The problem is that on GemStone symbols and strings don't compare as equal, so looking up a class in a repo fails. ouch we were not aware of that > > > Is that slice something that is generally interesting ? probably, I will let christophe reply. > Is it already fixed in Pharo 4? I do not think so > > > Thanks > > Paul >

Nov. 15, 2014

Re: [Pharo-dev] [NB] Undocumented NativeBoost options

by stepharo

On 15/11/14 12:37, Max Leske wrote: > I got a bit frustrated and ended up searching the source for â[\w]opt[[:upper]]â to find all NativeBoost options. Some of those options are in fact undocumented: > > optMayGC > optProxyLabels > optCdecl > optReturnNullAsNil > optStdcall > optNonMovable > optReserveCallgateSpace > optDebug > optNoAlignment > optEmitCall > optNoCleanup > optCheckFailOnEveryArgument > optStringOrNull > WinUnicode > > NBFFICallout>>defaultOptions documents most options but refers to NBFFICallout>>allOptions, wich does not exist. Most of the above options can be considered internal, I guess, but the one option I needed (âoptStringOrNullâ) isnât documented anywhere. I had to step through the execution to find out why my function call wasnât working (because I was trying to use âoptCoerceNilToNullâ and didnât know that strings need a special option). > > Iâd be very thankful if these options would be included in the documentation. Which documentation? There is one? And yes this pisses me off. > > Note: âWinUnicodeâ is used by the Windows code in a couple of places, even though the option name is not valid, according to NBNativeCodeGen>>parseOptions: > > Cheers, > Max >

Nov. 15, 2014

Re: [Pharo-dev] How to refresh the pharo window manually

by stepharo

did you try update? On 15/11/14 13:26, kilon alios wrote: > Hello guys I am making a theme manager and I have observed that when I > choose a background color for pharo windows it does not update > properly. How I can force the whole pharo window to update ? I have > found DisplayScreen and WorldMorph but no idea how to use them.

Nov. 15, 2014

Re: [Pharo-dev] ValueHolder analysis

by stepharo

Hi Henrik Thanks for your point :) I agree with you. Esteban prefered the current solution because of law of demeter but I do not think that this is good. So we will rewrite all these methods. If you want to help you are welcome. Stef On 14/11/14 16:25, Henrik Johansen wrote: >> On 14 Nov 2014, at 12:01 , stepharo <stepharo(a)free.fr> wrote: >> >> I checked a bit deeper >> >> >> Nautilus is not implemented in Spec. But senders and implementors are and they also leak memory. Around 400 Announcers after each >> opening and closing. >> >> Now >> >> whenChangedDo: aBlock >> >> | block | >> block := [:announcement :ann | aBlock cull: announcement newValue cull: announcement oldValue cull: announcement cull: ann ]. >> announcer when: ValueChanged do: block >> >> can also be part of the cause of some of our problems. >> >> There are 146 senders and many of them could just be replaced by whenChanged:send:to: and whenChanged:send:to:with: >> >> >> Finally we were discussing with igor about the general API of spec model: We are thinking that the following patterns >> are bloating the interface for an not obvious gain. >> >> whenWindowChanged: aBlock >> >> window whenChangedDo: aBlock >> >> >> whenShortcutsChanged: aBlock >> <api: #event> >> "Set a block to value when the shortcuts block has changed" >> >> additionalKeyBindings whenChangedDo: aBlock > I'd argue the window and additionalKeyBindings' whenChangedDo: implementations are unnecessary bloat as well. > Why on earth would you limit yourself to a an API where you have to use seperate methods to register for every single announcement type? > > To me, > myObject additionalKeyBindings when: ValueChanged do: aBlock > is just as easy, if not easier to read compared to > myObject whenShortCutsChanged: [] > > Not to mention, it easily lets you do unsubscription when you expect not to outlive the source (through the 3rd block parameter, whose *main purpose for even being there* is enabling easy unsubscription), rather than discarding it during useless indirection and leaving the task harder to do later on? > > Cheers, > Henry >

Nov. 15, 2014

cross platform issue with versionner in pharo 3.0 - want a slice?

by Paul DeBruicker

Hey - I'm thinking about making a slice to that versionner doesn't use Symbols for class names when creating baselines. The problem is that on GemStone symbols and strings don't compare as equal, so looking up a class in a repo fails. Is that slice something that is generally interesting ? Is it already fixed in Pharo 4? Thanks Paul

Nov. 15, 2014

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

Apologies but at least the Spur VMs are broken. They don't load images. Consequently I've taken down the files. Normal service will be resumed asap. On Fri, Nov 14, 2014 at 3:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/. > > CogVM binaries as per VMMaker.oscog-eem.934/r3133 > These VMs should be functionally identical to the 3126 VMs; the core VM > differs > only in having been compiled from generated source that has been > refactored to > enable convenient 32-bit to 64-bit Spur image bootstrap. I'm building and > releasing them mostly to test that refactoring. However, there is new DNS > support on Windows and SSL support on Unix. See below. > > Simulator/Slang: > Refactor to allow 32-bit and 64-bit Spur to coexist > in the simulator, thereby allowing a 64-bit bootstrap. > > Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and > BaseHeaderSize > with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize > respectively. > Make sure these are still output as the manifest constants in the > generated C. > Eliminate use of bytesPerSlot in favour of bytesPerOop. The use of sends > is > similar to those in trunk VMMaker, but I don't have time to merge. Sorry > :-(. > > Work-around use of sends for bytesPerOop in e.g. > generateToByDo:on:indent: and > users of isConstantNode:valueInto:. > > Do a better job at inlining via inlineCodeOrNilForStatement:in:. Comment > in > isNode:substitutableFor:inMethod:in: explains. > > Eliminate generic VM_LABEL support, labelling only the bytecodes in > interpret. > > Eliminate use of LargeContextSize in the stack and cog VMs. Alas haven't > yet > eliminated the frame offset constants such as FoxCallerSavedIP et al. We > only > need one of the two word sizes of interpreter to be executable in the > bootstrap. > > And remember to generate the GdbARMPlugin > > Add accessorDepths for the exported browser plugin primitives for Spur. > > Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix. > See > http://squeakvm.org/cgi-bin/viewvc.cgi/squeak?view=revision&revision=2249 > http://bugs.squeak.org/view.php?id=7824 > > Have the Unix & Mac VMs print the process id and working directory when > blocking > on error or assert fail. Add scripts for the ARM VM archives. > -- > best, > Eliot > -- best, Eliot

Nov. 15, 2014

Julia vs Pharo

by Serge Stinckwich

Hi all, I find a recent paper about Julia that might be appealing for people interested in doing scientific computation in Pharo (like the SciSmalltalk community) : http://arxiv.org/pdf/1411.1607v1.pdf "Julia: A fresh approach to numerical computing" Julia is a new dynamic programming language for scientific programming with much higher performance than R or Python. I found that some concepts are quite closed to Pharo in fact: - meta-programming and code generation - arbitrary precision integer - JIT compiler (based on LLVM) - call to C API What is missing in Pharo at the moment: - multiple dispatch - arbitrary precision float - dynamic dataflow type inference - optional type annotations (maybe with pluggable type extensions for Pharo ?) - special matrices types like spares or dense matrix, tri-diagonal, etc ... - vectorization Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Help fight Ebola by joining the Computing for Ebola Challenge http://bit.ly/1oEdBag

Nov. 15, 2014

Re: [Pharo-dev] Configurations and Github for a specialised configuration browswe

by kilon alios

Travis seems like an overkill for me right now. Sure if I was bombarded by pull requests from other developers but in reality I work alone . But I will definitely keep it in mind in case my projects become so popular that people start to send me pull requests regularly. All I wanted was an easy way to install code from github to pharo without the need to install git and you gave me that. Next step is to see how I would integrate github with pharo better, should I use Configuration versions or is it better to use branches ? I am more orientated towards branches. I have stared your repos to make sure I get keep updated in any progress you make. I plan also to go back and re read that metacello chapter to better understand metacello. Thank you very much for your hard work, keep rocking :) On Sat, Nov 15, 2014 at 7:15 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Kilon, > > Regarding Pharo4.0 and Metacello, I just recently added Pharo4.0 support > to Metacello[1] and buildCI[2]. > > If you are using github, then you should checkout builderCI. BuilderCI > let's you hook into travis-ci[3] and run unit tests on every commit. It's > especially useful when you get a pull request, because the unit tests are > run against the MERGED version of the pull request (BEFORE you do the > merge), so you can be assured that when you do the merge, your tests will > be green ... > > Let me know if the builderCI instructions[4] work for you...It's been > awhile since I've reviewed the docs:) > > Dale > > [1] https://groups.google.com/forum/#!topic/metacello/TVzfP8ZwPPE > [2] https://github.com/dalehenrich/builderCI > [3] https://travis-ci.org/ > [4] https://github.com/dalehenrich/builderCI#using-builderci > > On Sat, Nov 15, 2014 at 8:55 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> YESSSS!!!! >> >> thanks Dale, you are awesome, it works like a charm for me now. >> >> Yes you needed to download the Pharo3DarkTheme because the Theme is >> installed by default in Pharo 4 and I dont intent on supporting pharo 3 >> with my project. If you tried Pharo 4 you would have no such issue. >> >> I would appreciate it if other people could spend just a minute getting >> latest Pharo 4 and trying this in a Workspace >> >> Metacello new >> baseline:'Nireas'; >> repository:'github://kilon/nireas:master'; >> get. >> >> Metacello new >> baseline:'Nireas'; >> repository:'github://kilon/nireas:master'; >> load. >> >> Then open a System Browser and make sure Nireas package exist and please >> report it here if its not much trouble. This solution is super easy for >> installing git repos and we could make a class to make it even easier with >> a single line command. >> >> Question: Why Pharo 4 has not got the latest Metacello ? >> >> On Sat, Nov 15, 2014 at 6:33 PM, Dale Henrichs < >> dale.henrichs(a)gemtalksystems.com> wrote: >> >>> Kilon, >>> >>> This code: >>> >>> Metacello new >>> baseline:'Nireas'; >>> repository:'github://kilon/Nireas:master'; >>> get; >>> load. >>> >>> does require a pretty recent version of Metacello ("chaining" the get >>> and load)[1]. I tried the following in a stock pharo3.0 and got an error >>> about requiring Pharo3DarkTheme, so I was able to load the package: >>> >>> Metacello new >>> baseline:'Nireas'; >>> repository:'github://kilon/Nireas:master'; >>> get. >>> Metacello new >>> baseline:'Nireas'; >>> repository:'github://kilon/Nireas:master'; >>> load. >>> >>> Dale >>> >>> [1] https://github.com/dalehenrich/metacello-work#pharo30 >>> >>> On Sat, Nov 15, 2014 at 3:13 AM, kilon alios <kilon.alios(a)gmail.com> >>> wrote: >>> >>>> ok after rereading your emails more carefully i realised that you meant >>>> that BaselineOf should go to its own package, so I moved the class to >>>> BaselineOfNireas package and now it does not report the same error but now >>>> it complain that project,baseline or configuration not specified. >>>> >>>> Is it mandatory to specify a configuration for my project , I though >>>> the baseline class was enough. Would love to hear more info on the subject, >>>> I am looking also at the Metacello chapter which by the way is in Deep Into >>>> Pharo and not PBE , I see loads of info on the subject but does not seem to >>>> mention anything about the BaselineOf class . >>>> >>>> Will love it if we can gave a simple way to load git repos to pharo 4. >>>> >>>> On Sat, Nov 15, 2014 at 12:53 PM, kilon alios <kilon.alios(a)gmail.com> >>>> wrote: >>>> >>>>> small typo in my paste >>>>> >>>>> the actual code i used is >>>>> >>>>> Metacello new >>>>> baseline:'Nireas'; >>>>> repository:'github://kilon/Nireas:master'; >>>>> get; >>>>> load. >>>>> >>>>> any help is appreciated :) >>>>> >>>>> On Sat, Nov 15, 2014 at 12:50 PM, kilon alios <kilon.alios(a)gmail.com> >>>>> wrote: >>>>> >>>>>> hello Dale I tried your approach with a new project I created called >>>>>> Nireas, its a theme manager for pharo 4. I followed your instructions and >>>>>> it complains that it cannot find the BaselineOfNireas >>>>>> >>>>>> This is the code I used >>>>>> >>>>>> Metacello new >>>>>> baseline:'Nireas'; >>>>>> repository:'github://kilon/nireas:master'; >>>>>> get; >>>>>> load. >>>>>> >>>>>> here is the repo >>>>>> >>>>>> https://github.com/kilon/Nireas >>>>>> >>>>>> and here is the error >>>>>> >>>>>> >>>>>> MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: >>>>>> linearLoadPackageSpec: packageSpec gofer: gofer >>>>>> MetacelloPlatform current >>>>>> do: [ >>>>>> | references nearestReference cachedReference externalReference >>>>>> mcVersion loadedVersionInfos | >>>>>> "check to see if mcz file is already in cacheRepository" >>>>>> cachedReference := self resolvePackageSpec: packageSpec cachedGofer: >>>>>> self loaderPolicy cacheGofer. >>>>>> (cachedReference ~~ nil and: [ packageSpec getFile ~~ nil ]) >>>>>> ifTrue: [ >>>>>> cachedReference name = packageSpec file >>>>>> ifTrue: [ >>>>>> "exact match between packageSpec file and cache" >>>>>> ^ self scheduleFetchFor: packageSpec cachedReference: cachedReference >>>>>> ] ]. "look up mcz file" >>>>>> references := self retryingResolvePackageSpecReferences: packageSpec >>>>>> gofer: gofer. >>>>>> nearestReference := references last >>>>>> asMetacelloCachingResolvedReference. "If the mcz is already in the >>>>>> cacheRepository, no need to copy" >>>>>> (cachedReference ~~ nil and: [ cachedReference name = >>>>>> nearestReference name ]) >>>>>> ifTrue: [ >>>>>> "latest reference in repository matches cachedReference ... " >>>>>> ^ self scheduleFetchFor: packageSpec nearestReference: >>>>>> nearestReference ]. "If the mcz is already loaded into the image, no >>>>>> need to copy" >>>>>> (self ignoreImage not and: [ (loadedVersionInfos := self >>>>>> ancestorsFor: packageSpec) ~~ nil ]) >>>>>> ifTrue: [ >>>>>> loadedVersionInfos >>>>>> do: [ :info | >>>>>> info name = nearestReference name >>>>>> ifTrue: [ ^ self ] ] ]. >>>>>> externalReference := (references select: [ :ref | ref name = >>>>>> nearestReference name ]) first >>>>>> asMetacelloCachingResolvedReference. >>>>>> self repositoryMap at: externalReference name put: externalReference >>>>>> repository. >>>>>> (self >>>>>> resolveDependencies: externalReference >>>>>> nearest: nearestReference >>>>>> into: (OrderedCollection with: nearestReference)) >>>>>> do: [ :reference | >>>>>> | pSpec l | >>>>>> mcVersion := reference version. >>>>>> (l := (GoferVersionReference name: reference name) resolveAllWith: >>>>>> self loaderPolicy cacheGofer) isEmpty >>>>>> ifTrue: [ >>>>>> self cacheRepository storeVersion: mcVersion. >>>>>> reference == nearestReference >>>>>> ifTrue: [ pSpec := packageSpec ] >>>>>> ifFalse: [ >>>>>> pSpec := packageSpec project packageSpec. >>>>>> pSpec name: mcVersion package name ]. >>>>>> self loadData >>>>>> addVersion: mcVersion >>>>>> versionInfo: mcVersion info >>>>>> resolvedReference: reference >>>>>> packageSpec: pSpec ] ]. >>>>>> self scheduleFetchFor: packageSpec externalReference: >>>>>> externalReference ] >>>>>> displaying: 'Fetching ' , packageSpec file in >>>>>> MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: in Block: >>>>>> linearLoadPackageSpec: packageSpec gofer: gofer... >>>>>> MetacelloPharo30Platform(MetacelloPlatform)>>do:displaying: >>>>>> MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: >>>>>> MetacelloPackageSpec>>loadUsing:gofer: >>>>>> [ :pkg | pkg loadUsing: self gofer: gofer ] in >>>>>> MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: >>>>>> in Block: [ :pkg | pkg loadUsing: self gofer: gofer ] >>>>>> Array(SequenceableCollection)>>do: >>>>>> >>>>>> MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: >>>>>> [ super linearLoadPackageSpecs: packageSpecs repositories: >>>>>> repositories ] in >>>>>> MetacelloFetchingMCSpecLoader>>explicitLoadPackageSpecs:repositories: in >>>>>> Block: [ super linearLoadPackageSpecs: packageSpecs repos...etc... >>>>>> BlockClosure>>ensure: >>>>>> MetacelloLoaderPolicy>>pushLoadDirective:during: >>>>>> MetacelloLoaderPolicy>>pushExplicitLoadDirectivesDuring:for: >>>>>> MetacelloFetchingMCSpecLoader>>explicitLoadPackageSpecs:repositories: >>>>>> MetacelloPackageSpec>>explicitLoadUsing: >>>>>> MetacelloPackageSpec>>load >>>>>> [ >>>>>> self setDefaultsAndValidateProjectSpec. >>>>>> spec := self projectSpec. >>>>>> projectPackage := spec projectPackage. >>>>>> projectPackage repositorySpecs do: [ :repoSpec | repoSpec >>>>>> createRepository flushForScriptGet ]. >>>>>> projectPackage load. >>>>>> self root: (Smalltalk at: spec className asSymbol) project. >>>>>> MetacelloProjectRegistration >>>>>> registrationForProjectSpec: spec >>>>>> ifAbsent: [ :new | new registerProject ] >>>>>> ifPresent: [ :existing :new | >>>>>> existing >>>>>> copyOnWrite: [ :existingCopy | >>>>>> spec >>>>>> copyForRegistration: existingCopy >>>>>> onWrite: [ :specCopy | specCopy ifNil: [ existingCopy merge: new ] >>>>>> ifNotNil: [ specCopy mergeScriptRepository: spec ] ] ] ] ] in >>>>>> MetacelloScriptEngine>>get in Block: [ ... >>>>>> BlockClosure>>ensure: >>>>>> MetacelloProjectRegistration class>>copyRegistryRestoreOnErrorWhile: >>>>>> MetacelloScriptEngine>>get >>>>>> [ :projectSpec | >>>>>> | engine | >>>>>> engine := MetacelloScriptEngine new >>>>>> options: self options copy; >>>>>> projectSpec: projectSpec; >>>>>> yourself. >>>>>> engine perform: actionArg key withArguments: actionArg value. >>>>>> engine root ifNotNil: [ :root | self roots add: root ] ] in >>>>>> MetacelloScriptApiExecutor(MetacelloScriptExecutor)>>execute: in Block: [ >>>>>> :projectSpec | ... >>>>>> [ :projectSpec | projectSpec ifNotNil: [ projectSpecBlock value: >>>>>> (self applyArgsToProjectSpec: projectSpec copy) ] ] in >>>>>> MetacelloScriptApiExecutor>>executeString:do: in Block: [ :projectSpec | >>>>>> projectSpec ifNotNil: [ projectSp...etc... >>>>>> Array(SequenceableCollection)>>do: >>>>>> MetacelloScriptApiExecutor>>executeString:do: >>>>>> ByteString(String)>>execute:against: >>>>>> MetacelloScriptApiExecutor(MetacelloScriptExecutor)>>execute: >>>>>> Metacello>>execute >>>>>> Metacello>>get >>>>>> UndefinedObject>>DoIt >>>>>> OpalCompiler>>evaluate >>>>>> RubSmalltalkEditor>>evaluateSelectionAndDo: >>>>>> >>>>>> >>>>>> On Tue, Oct 21, 2014 at 10:55 PM, kilon alios <kilon.alios(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Thank you Dale very much , this is very clear :) >>>>>>> >>>>>>> On Tue, Oct 21, 2014 at 10:53 PM, Dale Henrichs < >>>>>>> dale.henrichs(a)gemtalksystems.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Oct 21, 2014 at 12:04 PM, kilon alios < >>>>>>>> kilon.alios(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> Thank you Dale, this is more simple than I expected. >>>>>>>>> >>>>>>>>> From what you linked it looks like by [:comitish] you mean the git >>>>>>>>> branch .Which in my case is master so it should be >>>>>>>>> >>>>>>>>> Metacello new >>>>>>>>> baseline: 'BaselineOfXXX'; >>>>>>>>> repository: 'github://kilon/phEphestos:master/' >>>>>>>>> get; >>>>>>>>> load. >>>>>>>>> >>>>>>>>> https://github.com/kilon/phEphestos >>>>>>>>> >>>>>>>> >>>>>>>> From looking at your repo on githug, the expression would be: >>>>>>>> >>>>>>>> Metacello new >>>>>>>> baseline: 'Ephestos'; >>>>>>>> repository: 'github://kilon/phEphestos:master' >>>>>>>> get; >>>>>>>> load. >>>>>>>> >>>>>>>> A commitish is a branch, SHA or tag. Note also, that my example was >>>>>>>> wrong ... the 'BaselineOf' shouldn't be used in the baseline: argument, >>>>>>>> just the base name of the project. >>>>>>>> >>>>>>>> You also need to create a BaselineOfEphestos which specifies >>>>>>>> package load order. BaselineOfEphestos would be created as a subclass of >>>>>>>> BaselineOf and have a single method: >>>>>>>> >>>>>>>> baseline: spec >>>>>>>> <baseline> >>>>>>>> spec >>>>>>>> for: #pharo >>>>>>>> do: [ >>>>>>>> spec package: 'Ephestos' ]. >>>>>>>> >>>>>>>> Then the above expression would load the Epestos package. >>>>>>>> >>>>>>>> If you were to add another package, say EphestosTests, then you'd >>>>>>>> update the baseline to declare that EphestosTests requires Ephestos to be >>>>>>>> loaded first you'd edit the baseline: method: >>>>>>>> >>>>>>>> baseline: spec >>>>>>>> <baseline> >>>>>>>> spec >>>>>>>> for: #pharo >>>>>>>> do: [ >>>>>>>> spec >>>>>>>> package: 'Ephestos'; >>>>>>>> package: 'EphestosTests' with: [ spec requires: #( >>>>>>>> 'Ephestos' ) ] ]. >>>>>>>> >>>>>>>> You commit the BaselineOf along with the rest of the packages for >>>>>>>> your project ... >>>>>>>> >>>>>>>> For more information see the Metacello chapter in Pharo by >>>>>>>> Example... >>>>>>>> >>>>>>>> Dale >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

Nov. 15, 2014