- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] Cleanup of debug requests API

by Andrei Chis

On Wed, Nov 25, 2015 at 6:29 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2015-11-25 17:16 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > >> Hi, >> >> In updating the debuggers from moose to the new API just one small issue >> came up: >> >> - Process>>newDebugSessionNamed:startedAt: hardcodes DebugSession. >> However we are using different debugging sessions. >> >> The class side method #sessionClass of a debugger returns the debugging >> session's class. That could be used instead of DebugSession. >> > > To provide fast fix we can rewrite process method with: > > Process>>newDebugSessionNamed: aString startedAt: aContext > > ^Smalltalk tools debugger sessionClass named: aString on: self startedAt: > aContext > > Could you publish issue and slice? > We can postpone this for the moment. I'll look a bit more at how this fits with the debuggers from moose as I'd like a more general solution where the debugger can be dynamically selected. > > In my fixes I try to put single point for debugging. I removed some old > methods and clean places where they was used. > Session is actual debugger model. And I was think that it is better to > always create debugger on it. > Now I think that maybe debug session should be internal object for > debugger. But it's seems strange. > When I added the session I viewed it as a model for the debugger. SpecDebugger and GTStackDebugger are just two different user interfaces for the same model (DebugSession). > > My main target is remote debugger. So I try to investigate all related > stuff. > Cool target :) > > What subclasses of DebugSession implement specifically? For what they > needed? > For example, GTBytecodeDebugger uses GTBytecodeDebuggerSession which makes sure step instructions only go over one bytecode (so no usage of #stepToSendOrReturn which are needed in the normal debugger). Apart from this other sessions store more information. For example GTSUnitDebugSession stores the context with the failing assertion. > If we move to GTDebugger completely can we have only debug session class? > GTGenericStackDebugger, the equivalent of SpecDebugger, uses also DebugSession (it just adds a few extension methods). All other debuggers have sessions that just inherit from DebugSession and they can be loaded separately. Cheers, Andrei

Nov. 25, 2015

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

by Dale Henrichs

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] Java Future

by Nicolas Anquetil

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

Nov. 25, 2015