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

[pharo-project/pharo-core] fbe8af: 50472

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: fbe8af8dcaedca1a3c081bbbce0e1ec01ccc2d00 https://github.com/pharo-project/pharo-core/commit/fbe8af8dcaedca1a3c081bbb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-26 (Thu, 26 Nov 2015) Changed paths: M Collections-Strings.package/Symbol.class/instance/system primitives/flushCache.st M Kernel.package/CompiledMethod.class/instance/accessing/flushCache.st M Kernel.package/MethodDictionary.class/README.md R Morphic-Base.package/extension/BorderedMorph/instance/addCornerGrips.st R Morphic-Base.package/extension/BorderedMorph/instance/addPaneSplitters.st R Morphic-Base.package/extension/BorderedMorph/instance/addPaneVSplitterBetween_and_.st R Morphic-Base.package/extension/BorderedMorph/instance/removeCornerGrips.st R Morphic-Base.package/extension/BorderedMorph/instance/splitters.st R Morphic-Core.package/BorderedMorph.class/instance/lookenhancements/linkSubmorphsToSplitters.st R Morphic-Core.package/BorderedMorph.class/instance/lookenhancements/removePaneSplitters.st R Morphic-Core.package/Morph.class/instance/initialize/openInWindow.st R Morphic-Core.package/Morph.class/instance/initialize/openInWindowLabeled_.st R Morphic-Core.package/Morph.class/instance/structure/isInSystemWindow.st A Morphic-Widgets-Windows.package/extension/BorderedMorph/instance/addCornerGrips.st A Morphic-Widgets-Windows.package/extension/BorderedMorph/instance/addPaneSplitters.st A Morphic-Widgets-Windows.package/extension/BorderedMorph/instance/addPaneVSplitterBetween_and_.st A Morphic-Widgets-Windows.package/extension/BorderedMorph/instance/linkSubmorphsToSplitters.st A Morphic-Widgets-Windows.package/extension/BorderedMorph/instance/removeCornerGrips.st A Morphic-Widgets-Windows.package/extension/BorderedMorph/instance/removePaneSplitters.st A Morphic-Widgets-Windows.package/extension/BorderedMorph/instance/splitters.st A Morphic-Widgets-Windows.package/extension/Morph/instance/initialColorInSystemWindow_.st A Morphic-Widgets-Windows.package/extension/Morph/instance/isInSystemWindow.st A Morphic-Widgets-Windows.package/extension/Morph/instance/modalLockTo_.st A Morphic-Widgets-Windows.package/extension/Morph/instance/nextMorphAcrossInWindow.st A Morphic-Widgets-Windows.package/extension/Morph/instance/nextMorphInWindow.st A Morphic-Widgets-Windows.package/extension/Morph/instance/nextMorphWantingFocus.st A Morphic-Widgets-Windows.package/extension/Morph/instance/openInWindow.st A Morphic-Widgets-Windows.package/extension/Morph/instance/openInWindowLabeled_.st A Morphic-Widgets-Windows.package/extension/Morph/instance/previousMorphInWindow.st A Morphic-Widgets-Windows.package/extension/Morph/instance/previousMorphWantingFocus.st A Morphic-Widgets-Windows.package/extension/Morph/instance/shadowOffsetRectangle.st M Nautilus.package/NautilusUI.class/instance/accessing/showHierarchy_.st M Nautilus.package/NautilusUI.class/instance/private/updateOnClassSelection.st R Nautilus.package/PackageTreeGroupNodeModel.class/README.md R Nautilus.package/PackageTreeGroupNodeModel.class/definition.st R Nautilus.package/PackageTreeGroupNodeModel.class/instance/accessing/icon.st R Nautilus.package/PackageTreeGroupNodeModel.class/instance/accessing/rowMorphForColumn_.st R Nautilus.package/PackageTreeGroupNodeModel.class/instance/converting/asNautilusSelection.st R Polymorph-Widgets.package/extension/Morph/instance/initialColorInSystemWindow_.st R Polymorph-Widgets.package/extension/Morph/instance/modalLockTo_.st R Polymorph-Widgets.package/extension/Morph/instance/nextMorphAcrossInWindow.st R Polymorph-Widgets.package/extension/Morph/instance/nextMorphInWindow.st R Polymorph-Widgets.package/extension/Morph/instance/nextMorphWantingFocus.st R Polymorph-Widgets.package/extension/Morph/instance/previousMorphInWindow.st R Polymorph-Widgets.package/extension/Morph/instance/previousMorphWantingFocus.st R Polymorph-Widgets.package/extension/Morph/instance/shadowOffsetRectangle.st M Reflectivity-Tools-Tests.package/WatchpointTests.class/instance/values/testTimestamp.st R Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/label.st R Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/label_.st M Reflectivity.package/ReflectiveMethod.class/instance/forwarding/flushCache.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50471.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50472.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50471.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50472.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TBehavior.class/instance/private/flushCache.st Log Message: ----------- 50472 17136 [cleanup] remove unused PackageTreeGroupNodeModel https://pharo.fogbugz.com/f/cases/17136 17135 WatchpointTests>>#testTimestamp https://pharo.fogbugz.com/f/cases/17135 17106 better MethodDictionary comment https://pharo.fogbugz.com/f/cases/17106 17130 Morph+BorderedMorph SystemWindow Protocol cleanup https://pharo.fogbugz.com/f/cases/17130 17080 Special Object Array does not hold the right Processor association https://pharo.fogbugz.com/f/cases/17080 http://files.pharo.org/image/50/50472.zip

Nov. 26, 2015

Pharo Consortium New Gold Member: Thales

by marcus.denker＠inria.fr

The Pharo Consortium is very happy to announce that Thales has joined the Consortium as an Gold Member. About - Thales: https://www.thalesgroup.com - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Nov. 26, 2015

Re: [Pharo-dev] [ANN] Twisty, text with active state framework

by Denis Kudriashov

2015-11-26 11:55 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > I especially like the masking capabilitie Thank's. Interesting how it is implemented. In Twisty portion of text have attributes collection like color and font. Asterix in masked text is just special kind of such attribute TwyMaskAsterixAttribute. Its value is character which should be used as asterix. TwyMaskedTextDecorator edits only text regions with such attribute. There is another attribute TwySecreteAsterixAttribute. Any text region which marked with it will be shown as asterix characters (from it value).

Nov. 26, 2015

Re: [Pharo-dev] [ANN] Twisty, text with active state framework

by Denis Kudriashov

2015-11-26 12:01 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > Quite impressive, I was developing a specialised input for time formats of > HH:MM:SS and I wanted to extend with ability to take minutes as pure number > and autoformat it to the above format. I have accomplished some of it but > your implementation seems more powerful. Will give it a try , thanks I was think to implement it to. But I have other tasks. It should be easy with Twisty. Just look at how smartNumbers implemented where thousands split by separator. If I right understand what you want (I'm not sure) you will need implement kind of TwyDecorationFormat and TwyTextSpec

Nov. 26, 2015

Re: [Pharo-dev] Improving API of Date, Month....

by Esteban Lorenzano

I donât know chronos, but Chalten (the Aconcagua date API) is quite nice (overuse of globals, IMO, but you gain a lot of expressivity). Esteban > On 24 Nov 2015, at 18:34, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > I made the mistake to think that it was a good move to improve and make the core more full (and complex in the past). > Now what I would love is the following. > > - keep and reduce if necessary the core date classes (only used internally by the system) > - have nice packages that we can load to represent time / calendar > -- chronos > -- aconcagua > -- or a new one > > That do it the right way: with locale and so on. > Why? because it can be complex and verbose and we want to have a small core (for many different reasons). > About the durationFormatter I think that we should definitively have more strategies to represent dates and other > within a nice date/calendar package. > > I would love that someone propose something to get the nice extensible Calendar/Date package > > Stef > > Le 24/11/15 16:25, Esteban A. Maringolo a Ã©crit : >> 2015-11-24 12:14 GMT-03:00 Skip Lentz <skip.lentz(a)inria.fr>: >>> Hi, >>> >>> I also had an idea for a method which returns the most significant unit of a Duration. >>> >>> For example, you have a duration of 432 days, 3 hours, 21 minutes, 5 seconds, etc., and >>> it would return you "432 days" (or just â1 yearâ). I encountered this when wanting to create >>> a time indication on e.g. a commit or a comment. Itâs much more readable and user-friendly >>> than a timestamp. >>> >>> Would this be a nice addition to the Duration API? >> It would be nice to have. But why not something like a >> DurationFormatter? that in turn collaborates with the Locale to ge the >> words for "Year, Month, Week" in the current language. >> >> Regards! >> >> > >

Nov. 26, 2015

Re: [Pharo-dev] Pharo Launcher on Mac

by Ben Coman

Do you mean in step 4 that Pharo Launcher doesn't open at all? That does sound strange. Now I just downloaded latest.dmg (build #51) and while it shows my list of images, it won't open any of them. I had dragged Pharo.app to a temporary folder rather than Applications folder since I didn't want to overwrite my current setup, but don't know if that made a difference. Lets see what others report. cheers -ben On Thu, Nov 26, 2015 at 5:32 PM, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: > Ciao, > > i load a Pharo Launcher on MacBook OS X 10.7.5 from: > https://ci.inria.fr/pharo/view/Launcher/job/Launcher-Mac/ latest.dmg > > Now i have this problematic: > > 1. I open the Pharo launcher > 2. Open the Image A with it > 3. I close the Pharo launcher > 4. when i re-open the Pharo Launcher ( double click on relative icon ) > again, it go directly to image A window. > > It's strange? > > Thanks, > > Dario > > P.S. The Pharo Launcher on Linux Ubuntu system work fine without this > problematic > >

Nov. 26, 2015

Re: [Pharo-dev] About the announcements model for SUnit

by Max Leske

Hi NicolÃ¡s, > On 26 Nov 2015, at 00:43, NicolÃ¡s Papagna Maldonado <nicolas.papagna(a)gmail.com> wrote: > > Hi everyone! > > Lately I've been playing with/digging into the announcements model for > SUnit, and have a couple of questions about it. > > I'm trying to understand the model and I am by no means an expert to it. Any > pointers/references/feedback is appreciated. > > 1) As expected TestCaseEnded is notified after a test case is run in > TestResult>>#runCase:, but after some tests I've noticed that the > announcement (which is created with the TestResult instance as collaborator) > is sent before the passing test case is added to the TestResult instance. > That means that one gets notified that a test case has been run > successfully, but when inspecting the result, that test case won't be there: > > runCase: aTestCase > [ > aTestCase announce: TestCaseStarted withResult: self. > aTestCase runCase. > *aTestCase announce: TestCaseEnded withResult: self. > self addPass: aTestCase*] > on: self class failure , self class skip, self class warning, self class > error > do: [:ex | ex sunitAnnounce: aTestCase toResult: self] > > Is this the expected behavior? No, of course not. But what do you mean by âinspecting the resultâ? The TestResult instance should contain the finished test regardless. Say, you inspect the TestResult before the test has been added, then refreshing the inspector (or opening a new one) should correctly show the test case in the result because it has been added in the mean time. I guess that switching those two statements wouldnât hurt though. > > 2) When a test case does not pass (for whatever reason), the failure is > handled and the TestResult instance is updated, but a TestCaseEnded > announcement is not sent. So there's a chance that you'd get a > TestCaseStarted announcement, but never receive a TestCaseEnded announcement > if it didn't pass: > > runCase: aTestCase > [ > *aTestCase announce: TestCaseStarted withResult: self.* > aTestCase runCase. > aTestCase announce: TestCaseEnded withResult: self. > self addPass: aTestCase] > on: self class failure , self class skip, self class warning, self class > error > do: [:ex | *ex sunitAnnounce: aTestCase toResult: self*] > > Is this the expected behavior? I agree. TestCaseEnded should be announced in all cases. > > 3) When a TestSuiteEnded is announced (TestResult>>#updateResultsInHistory), > the announcement instance is created passing in the TestCase subclass as > result. So, when sending #testResult to the annoucement, one does not get a > TestResult instance (as expected) but the TestCase subclass. > > updateResultsInHistory > |classesToNotify| > classesToNotify:= Set new. > #(#passed #failures #errors) do: [ :status | > (self perform: status) do: [ :testCase | > classesToNotify add:testCase class. > self class updateTestHistoryFor: testCase status: status ] ]. > *classesToNotify do:[:cl | * > cl historyAnnouncer announce: (*TestSuiteEnded result: cl*)] That should probably be âTestSuiteEnded testCase: clâ. If you look at the subscribers to TestSuiteEnded youâll see that #result is used to retrieve the test case. So those senders would need to be updated. but yes, since there is a #testCase: selector itâs pretty bad that the selector used is #result:. > > 4) I've read an old post about using a Dictionary instead of storing the > TestResult instance as history, and it seemed like that was the intended > design. The only issue I see there is that there could be potentially > duplicated code in writing the interpretation of that dictionary (ie. > #passed, #failures, #defects, etc..). Has anyone worked with TestCase > results history before? if So, which was your approach to do it? > > Cheers, > Nico PM > > Thanks for looking at that code! Itâs been lying around for ages and everyone fears it (at least thatâs my impression :) ). Cheers, Max > > > > -- > View this message in context: http://forum.world.st/About-the-announcements-model-for-SUnit-tp4863569.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 26, 2015

Re: [Pharo-dev] [ANN] Twisty, text with active state framework

by Dimitris Chloupis

Quite impressive, I was developing a specialised input for time formats of HH:MM:SS and I wanted to extend with ability to take minutes as pure number and autoformat it to the above format. I have accomplished some of it but your implementation seems more powerful. Will give it a try , thanks On Thu, Nov 26, 2015 at 12:09 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Iâm glad to announce new text framework Twisty. > > Twisty is text implementation based on active state idea. In this library > text instances announce any change which happens with it. Due to this > behavior Twisty provides cursors and layout objects which state are > automatically restored after text changes. It is simplified implementation > of text tools which operate on single text instance. They do not need to > implement any synchronization of their state when somebody edit text. > > Any text editing should be performed by: > > text > editContentsBy: [cursor insert: ânew stringâ] > andSubmitChangesBy: [text asString allDigits] > > First block in this example performs text changes by cursor instance. > Cursor can be fetched by "text newActiveCursor". Also text can be edited by > text region instances. > Last block is predicate which validate changes. At the time of its > execution text already applied all changes from first block. So full and > completed text state can be verified. If state is incorrect all changes > will be cancelled. If anything ok text will accept all changes by > announcing TwyTextChanged event. > In this example changes will be cancelled and ânew stringâ will be not > accepted. > There is short version of editing method without any validation: > > text editContentsBy: [region backspaceKey] > > Editing methods return announced event. It can be TwyTextChanged or > TwyChangesCancelled events. This events contains all changes which happened > during editing block execution. Changes are presented by first class > objects subclasses of TwyImmediateChangeAnnouncement: > TwyCharactersSpanIncreased, TwyElementInserted, TwyElementsGroupRemoved, > TwyCursorMoved and others. > Changes can be cancelled. Cancel should be performed inside editing block: > > text editContentsBy: [textChanged cancel] > > It is used for undo/redo implementation. > > Twisty implements single text morph TwyTextMorph. Different behavior > should be implemented by specific class of text tool (subclasses of > TwyTextTool). It can be editor tool, selection tool, cursor tool, undo/redo > tool and others. Text morph contains collection of such tools. Different > combination of tools supplies different behavior. For example, text morph > without any tools is simple readonly text field. Text morph with selection > tool allows select text region and copy it to clipboard. If cursor tool are > added to morph then blinked cursor are shown for visible text navigation. > Tools approach allows replace usual hierarchy of text morphs by > composition of tool classes. > Tools are added to text morph by: > textMorph ensureTool: TwyCursorTool > > TwyEditorTool adds editing behavior to text morph. It subscribes on key > press events from morph to accept arbitrary characters input, cut selection > or insert clipboard contents. All actions are delegated to instance of > TwyEditor. Editor by itself delegates execution of actions to text > decorator and then It validates resulted changes by text validator. > Text validator is responsible for text changes verification. For example > validator can check that text has only digits and forbid insertion of any > other characters. By default editor has TwyNullTextValidator which allowed > any text. > Text decorator is responsible for specific processing of usual editing > operations. Text decorator decides how characters should be inserted or > removed, how selected text region should be changed. By default editor have > TwyNativeTextDecorator which inserts characters with usual logic where > characters are inserted at cursor position and selection region are reset. > But there is TwyMaskedTextDecorator which implements it differently. It > overrides asterix characters of mask with inserted string and skips non > asterix characters. > > You can see examples on available features in TwyTextMorph class side and > in attached videos. > > Twisty. Text editor <https://www.youtube.com/watch?v=WNLSBt1eB2w> > Twisty. Masked fields <https://www.youtube.com/watch?v=nZ3mWmJWp-k> > Twisty. Smart numbers <https://www.youtube.com/watch?v=ilx8XuRFOeY> > Twisty. Smart Characters <https://www.youtube.com/watch?v=iRpafGFcH_4> > Twisty. Autoscrolling without scroll pane > <https://www.youtube.com/watch?v=I_x3INGJy-E> > Twisty. PlaceHolder <https://www.youtube.com/watch?v=tHNO-qnTY1E> > Twisty. Live tuning <https://www.youtube.com/watch?v=Rm1jp3eHsCU> > > You can load code in Pharo 4 and 5 by: > > Gofer it > smalltalkhubUser: 'dionisiy' project: 'Twisty'; > configurationOf: 'Twisty'; > loadStable > > Best regards, > Denis >

Nov. 26, 2015

Re: [Pharo-dev] [ANN] Twisty, text with active state framework

by Peter Uhnak

This is really nice! I especially like the masking capabilities. Peter On 11/26, Denis Kudriashov wrote: > Iâm glad to announce new text framework Twisty. > > Twisty is text implementation based on active state idea. In this library > text instances announce any change which happens with it. Due to this > behavior Twisty provides cursors and layout objects which state are > automatically restored after text changes. It is simplified implementation > of text tools which operate on single text instance. They do not need to > implement any synchronization of their state when somebody edit text. > > Any text editing should be performed by: > > text > editContentsBy: [cursor insert: ânew stringâ] > andSubmitChangesBy: [text asString allDigits] > > First block in this example performs text changes by cursor instance. > Cursor can be fetched by "text newActiveCursor". Also text can be edited by > text region instances. > Last block is predicate which validate changes. At the time of its > execution text already applied all changes from first block. So full and > completed text state can be verified. If state is incorrect all changes > will be cancelled. If anything ok text will accept all changes by > announcing TwyTextChanged event. > In this example changes will be cancelled and ânew stringâ will be not > accepted. > There is short version of editing method without any validation: > > text editContentsBy: [region backspaceKey] > > Editing methods return announced event. It can be TwyTextChanged or > TwyChangesCancelled events. This events contains all changes which happened > during editing block execution. Changes are presented by first class > objects subclasses of TwyImmediateChangeAnnouncement: > TwyCharactersSpanIncreased, TwyElementInserted, TwyElementsGroupRemoved, > TwyCursorMoved and others. > Changes can be cancelled. Cancel should be performed inside editing block: > > text editContentsBy: [textChanged cancel] > > It is used for undo/redo implementation. > > Twisty implements single text morph TwyTextMorph. Different behavior should > be implemented by specific class of text tool (subclasses of TwyTextTool). > It can be editor tool, selection tool, cursor tool, undo/redo tool and > others. Text morph contains collection of such tools. Different combination > of tools supplies different behavior. For example, text morph without any > tools is simple readonly text field. Text morph with selection tool allows > select text region and copy it to clipboard. If cursor tool are added to > morph then blinked cursor are shown for visible text navigation. > Tools approach allows replace usual hierarchy of text morphs by composition > of tool classes. > Tools are added to text morph by: > textMorph ensureTool: TwyCursorTool > > TwyEditorTool adds editing behavior to text morph. It subscribes on key > press events from morph to accept arbitrary characters input, cut selection > or insert clipboard contents. All actions are delegated to instance of > TwyEditor. Editor by itself delegates execution of actions to text > decorator and then It validates resulted changes by text validator. > Text validator is responsible for text changes verification. For example > validator can check that text has only digits and forbid insertion of any > other characters. By default editor has TwyNullTextValidator which allowed > any text. > Text decorator is responsible for specific processing of usual editing > operations. Text decorator decides how characters should be inserted or > removed, how selected text region should be changed. By default editor have > TwyNativeTextDecorator which inserts characters with usual logic where > characters are inserted at cursor position and selection region are reset. > But there is TwyMaskedTextDecorator which implements it differently. It > overrides asterix characters of mask with inserted string and skips non > asterix characters. > > You can see examples on available features in TwyTextMorph class side and > in attached videos. > > Twisty. Text editor <https://www.youtube.com/watch?v=WNLSBt1eB2w> > Twisty. Masked fields <https://www.youtube.com/watch?v=nZ3mWmJWp-k> > Twisty. Smart numbers <https://www.youtube.com/watch?v=ilx8XuRFOeY> > Twisty. Smart Characters <https://www.youtube.com/watch?v=iRpafGFcH_4> > Twisty. Autoscrolling without scroll pane > <https://www.youtube.com/watch?v=I_x3INGJy-E> > Twisty. PlaceHolder <https://www.youtube.com/watch?v=tHNO-qnTY1E> > Twisty. Live tuning <https://www.youtube.com/watch?v=Rm1jp3eHsCU> > > You can load code in Pharo 4 and 5 by: > > Gofer it > smalltalkhubUser: 'dionisiy' project: 'Twisty'; > configurationOf: 'Twisty'; > loadStable > > Best regards, > Denis -- Peter

Nov. 26, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by Jan Vrany

Oops, sorry - accidentally sent unfinished message Another slim implementation of Cypress decoupled from Monticello is the one I wrote for St/X: https://bitbucket.org/janvrany/stx-goodies-cypress/src or in Cypress format itself:Â https://github.com/CampSmalltalk/Cypress/tree/master/implementations/sm alltalkx/packages/stx_goodies_cypress.package though this might be a little behind, I'll check an eventuallyÂ update soon(ish) It has the nice feature of keeping all files and properties it doesÂ not understand, though this behaviour is *not* required byÂ Cypress spec.Â Best, Jan > > On Wed, 2015-11-25 at 21:42 +0100, Thierry Goubier wrote: > > Hi Dale, > > > > thanks for the update. So not only it would be possible to extract > > FileTree from its relation to Monticello, this has in fact already > > been > > done (and more than once). > > > > Thierry > > > > Le 25/11/2015 20:33, Dale Henrichs a Ã©crit : > > > > > > > > > On 11/25/2015 02:31 AM, Thierry Goubier wrote: > > > > > > > > > > > > 2015-11-25 10:39 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr > > > > <mailto:skip.lentz@inria.fr>>: > > > > > > > > > > > > > Â Â Â Â Â Â Â Â I think having a FileTree reader/writer that is not > > > > > coupled > > > > > Â Â Â Â Â Â Â Â to Monticello would be good, but maybe Iâm saying > > > > > something > > > > > Â Â Â Â Â Â Â Â that is not possible. > > > > > > > > > > > > > > > Â Â Â Â No, it is possible (everything is), but a bit complex for > > > > > Â Â Â Â maintenance (how do you track changes and corrections in > > > > > the > > > > > Â Â Â Â FileTree code?). > > > > > > > > Â Â Â Â Of course, the sky is the limit :P. Although Iâm not sure I > > > > Â Â Â Â understand what you mean here, could you explain? > > > > > > > > FileTree has a large set of test cases, sample repositories, CI > > > > setup, > > > > cross-platform knowledge, bug fixes coming from a large group > > > > of > > > > users > > > > (far larger than the Pharo community). > > > > > > > > Cutting ourselves from that is counter productive and looks > > > > like > > > > a > > > > case of the NIH syndrome. > > > > > > > > > > Thierry, > > > > > > I understand where you are coming from with your comment and I am > > > not > > > necessarily disagreeing with you, but:) > > > > > > A "FileTree reader/writer that is not coupled to Monticello" is > > > not > > > necessarily a bad thing and in fact I have implemented such a > > > beast > > > a > > > couple of times[1][2] and I think that Jan based his initial > > > implementation on the Pharo Cypress implementation[5]. > > > > > > My initial implementation[1] was done in support of Amber > > > Skeleton[3][6] > > > where I added implemented an Amber source code server in Pharo > > > and > > > used > > > the Cypress reader/writer[1] to pass packages back and forth > > > between > > > Amber and Pharo once the package hit Pharo it was written to disk > > > using > > > FileTree. > > > > > > The second implementation[2] was done to implement a FileTree > > > reader/writer for Cuis which does not use Monticello, so I needed > > > a > > > reader/writer that understood the FileTree disk format without > > > being > > > coupled to the Monticello package implementation and loader. > > > > > > Richard Sargent has a Cypress reference implementation for > > > GemStone > > > that > > > is also independent of Monticello[4]. > > > > > > These Cypress implementations read/write the FileTree disk format > > > without being coupled to the in-image Monticello implementation > > > ... > > > the > > > definition model and loaders are basically stripped down versions > > > of the > > > Monticello implementations, with the major difference being the > > > absence > > > of the Monticello meta data --- ancestors and the like --- which > > > means > > > that in a world where you rely on the disk-based scm to manage > > > versions, > > > there is no need to have the Monticello meta data in the image at > > > all ... > > > > > > Skip will be downloading individual files from GitHub and will > > > need > > > to > > > construct a coherent package model from those files and > > > directories. > > > There may be an advantage to constructing "Cypress snapshots" > > > from > > > the > > > raw GitHub data as an intermediate format if nothing else - much > > > as > > > I > > > did for the Amber Skeleton project .... > > > > > > If there is interest in moving forward with the Pharo Cypress > > > code[1], I > > > would be in favor of splitting that code out into a separate > > > project, so > > > that it can evolve independent of it's Amber Skeleton roots ... > > > > > > Dale > > > > > > [1] > > > https://github.com/CampSmalltalk/Cypress/tree/master/implementati > > > on > > > s/pharo/cypress/packages > > > [2] > > > https://github.com/CampSmalltalk/Cypress/tree/master/implementati > > > on > > > s/cuis/packages > > > [3] https://github.com/dalehenrich/amber-skeleton/tree/master/ser > > > ve > > > r > > > [4] https://github.com/rjsargent/CypressReferenceImplementation > > > [5] > > > https://github.com/CampSmalltalk/Cypress/tree/master/implementati > > > on > > > s/smalltalkx/packages/stx_goodies_cypress.package > > > [6] https://github.com/CampSmalltalk/amber-cypress > >

Nov. 26, 2015