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

[ANN] Twisty, text with active state framework

by Denis Kudriashov

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] Basic versioning of GitHub repositories from within Pharo

by Jan Vrany

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:Â 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/implementation > > s/pharo/cypress/packages > > [2] > > https://github.com/CampSmalltalk/Cypress/tree/master/implementation > > s/cuis/packages > > [3] https://github.com/dalehenrich/amber-skeleton/tree/master/serve > > r > > [4] https://github.com/rjsargent/CypressReferenceImplementation > > [5] > > https://github.com/CampSmalltalk/Cypress/tree/master/implementation > > s/smalltalkx/packages/stx_goodies_cypress.package > > [6] https://github.com/CampSmalltalk/amber-cypress > >

Nov. 26, 2015

Pharo Launcher on Mac

by Trussardi Dario Romano

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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50471 Home: https://github.com/pharo-project/pharo-core

Nov. 26, 2015

[pharo-project/pharo-core] dbc41a: 50471

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: dbc41ab6856a624c53f93cb190b1525454a5b1e5 https://github.com/pharo-project/pharo-core/commit/dbc41ab6856a624c53f93cb1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-26 (Thu, 26 Nov 2015) Changed paths: R Nautilus.package/TransformWithLayoutMorphForMultipleEditors.class/README.md R Nautilus.package/TransformWithLayoutMorphForMultipleEditors.class/definition.st R Nautilus.package/TransformWithLayoutMorphForMultipleEditors.class/instance/geometry/bounds_.st R Nautilus.package/TransformWithLayoutMorphForMultipleEditors.class/instance/geometry/updateSubMorph_.st R Reflectivity-Tools.package/AbstractIconStyler.class/instance/visiting/visitVariableNode_.st M Reflectivity-Tools.package/WatchpointWindow.class/instance/api/extent.st M Reflectivity-Tools.package/WatchpointWindow.class/instance/initialization/setupMenu.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50470.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50471.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50470.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50471.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/ChangeSorterApplication.class/instance/menu - message/removeMessage.st Log Message: ----------- 50471 17131 styling for watchpoints on variable node happens twice https://pharo.fogbugz.com/f/cases/17131 17129 Watchpoint window should also be able to uninstall a watchpoint https://pharo.fogbugz.com/f/cases/17129 17128 remove unused class TransformWithLayoutMorphForMultipleEditors https://pharo.fogbugz.com/f/cases/17128 17114 ChangeSorterModel has invalid method ref in removeMethod: inClass: https://pharo.fogbugz.com/f/cases/17114 http://files.pharo.org/image/50/50471.zip

Nov. 26, 2015

About the announcements model for SUnit

by NicolÃ¡s Papagna Maldonado

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? 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? 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*)] 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 -- 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. 25, 2015

Re: [Pharo-dev] Is code pane should show secondary selection on any characters like spaces and tabs?

by Ben Coman

On Thu, Nov 26, 2015 at 2:31 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Denis, > > I think this is cool :). I'm anal enough to hate spaces hidden before > tabs, but they're invisible...unless, selecting a space highlights all > spaces in the method :) > > (I also hate trailing white space; wish it weren't so prevalent) > I find the auto-selection of all spaces really annoying, since it happens a lot by accident. I just had not complained yet since I thought it was temporary alpha-code for debugging. I've never accidentally had the tab auto-selection occur (actually I never noticed the feature), so I could live with that, and that maybe that is sufficient for Eliot(?). An intuitive alternative might be that it only works in the left-margin-whitespace and shows both tab and spaces together - i.e. its not a space or a tab you are selecting, its whitespace. cheers -ben > > On Nov 25, 2015, at 8:09 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > When you select single space on code pane all spaces in code become > selected. To me it is look very weird. > > If I'm not alone on this feeling we can integrate issue 16962 > > For more details current behavior is: > If you select "self", all "self"s in the code pane are selected with > "secondary selection color" > If you select "." all dots are selected. > If you select a space-char all spacess are selected > If you select a tab-char all tabs are selected ... > > With my fix you will not see secondary selection on any separators (space > ,tab). > It was my first impression when I start to navigate/select text by command > left/right. And spaces selection during this process looks to me very bad.

Nov. 25, 2015

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

by Thierry Goubier

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/implementations/pharo/… > [2] > https://github.com/CampSmalltalk/Cypress/tree/master/implementations/cuis/p… > [3] https://github.com/dalehenrich/amber-skeleton/tree/master/server > [4] https://github.com/rjsargent/CypressReferenceImplementation > [5] > https://github.com/CampSmalltalk/Cypress/tree/master/implementations/smallt… > [6] https://github.com/CampSmalltalk/amber-cypress

Nov. 25, 2015

Re: [Pharo-dev] Debugging a failing test doesn't include the full stack

by Esteban A. Maringolo

2015-11-25 6:32 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Iâve seen this problem tons of times since Pharo4. But the worst is that I > never found a way to reproduce it. > > To me there is some side effect somewhere. Because it does not happen in a > fresh image, but once you have it, you have it all the time. I thought it had to do with how GLORP handles the exceptions and/or block unwinding. But it doesn't seem so. There is a bug report for this: https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop Esteban A. Maringolo

Nov. 25, 2015

Re: [Pharo-dev] Java Future

by Casimiro - GMAIL

Em 25-11-2015 17:21, Nicolas Anquetil escreveu: > > > On 25/11/2015 19:55, Jimmie Houchin wrote: >> Much truth in what you say. However, what Oracle choose to invest its >> money, time, personnel resource into Java does affect its present and >> future. It has a great affect. But it isn't the whole story. Java has >> enough momentum in what already exists in the language and vm and >> what has been release under its license, for businesses to keep going >> for some time with only what currently exists. >> > Cobol is still alive (and well) after > 50 years. > You can expect Java programmers to find jobs for many years yet to come > :-) > > nicolas > -- > Nicolas Anquetil > RMod team -- Inria Lille 1st: Java is extremely profitable. Each android phone, each android TV, each android embedded system pays copyrights to Oracle. 2nd: Much of current cloud infrastructure depends on java. 3rd: Java is already obsolete, like Frotran, Cobol, C, C++. It will continue to be used by same reasons these languages are used. IMHO, discussing java is not profitable. Better to discuss things to be than talk about things that already happened. casimiro -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. == This email may be signed using PGP key *ID: 0x4134A417*

Nov. 25, 2015