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

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

[pharo-project/pharo-core]

by GitHub

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

Nov. 25, 2015

[pharo-project/pharo-core] ea4d12: 50470

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: ea4d128d76b310561c48b502e8b46e37b56f17b5 https://github.com/pharo-project/pharo-core/commit/ea4d128d76b310561c48b502… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-25 (Wed, 25 Nov 2015) Changed paths: A Kernel.package/Date.class/class/accessing constant/dayNames.st A Kernel.package/Date.class/class/accessing constant/daysInMonth.st A Kernel.package/Date.class/class/accessing constant/monthNames.st M Kernel.package/Year.class/instance/accessing/daysInMonth.st M MonticelloFileTree-Core.package/MCFileTreeAbstractReader.class/instance/testing/hasMonticelloMetadata.st M Reflectivity-Tools.package/WatchpointWindow.class/instance/initialization/setupMenu.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50469.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50470.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50469.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50470.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions-Tests.package/SugsMockContext.class/instance/api-context/message_.st M SmartSuggestions.package/SugsWatchpointSuggestion.class/instance/accessing/label.st A SmartSuggestions.package/SugsWatchpointSuggestion.class/instance/as yet unclassified/selectedNodeHasWatchpoint.st M SmartSuggestions.package/SugsWatchpointSuggestion.class/instance/execution/isValidForContext.st Log Message: ----------- 50470 17098 Improve Date class API https://pharo.fogbugz.com/f/cases/17098 17127 Fix watchpoints https://pharo.fogbugz.com/f/cases/17127 17125 Metadata-less compatibility with FileTree https://pharo.fogbugz.com/f/cases/17125 17126 Watchpoint window should use Watchpoint start/stop API instead of Install/Uninstall https://pharo.fogbugz.com/f/cases/17126 http://files.pharo.org/image/50/50470.zip

Nov. 25, 2015

Re: [Pharo-dev] Java Future

by Jimmie Houchin

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. The nice part about the Pharo story is this, as Stef says: Pharo is yours. What Pharo is and becomes is up to us, the community. Not what any major corporation says it is or is not going to do. Pharo is what we make it to be. Pharo will become what we make it to become. It is nice to have organizations and corporations as part of the community, such as INRIA, etc. They offer substantial resources and are a blessing. And the nice thing is that Pharo does not need an Oracle size corporation to keep it going and viable. Can Java say that? Time will tell. Could Java have gotten to where it is without it? As you say, let's keep Pharo going so that it can empower the little guy or smaller business. :) Shalom. Jimmie On 11/25/2015 04:29 AM, Dimitris Chloupis wrote: > Clickbait ! ClickBAIT !!!!! > > Let me remind you that bloggers have been declaring Java dead for over > a decade now. Java still goes strong and is the undisputed king of > Enterprise coding no other language can even remotely touch it, mainly > because of its huge powerful library made for big businesses. Pharo > cannot compete with Java, it does not have the resources to, right now > the only true competitor to java is C# and even C# though backed by > Micro$oft , still it lags very much behind it in terms of popularity. > Let me also remind you that Java is the language that mutilated the > then undisputed king of of programming languages C++ stealing away > tons of its coders. Probably the biggest migration of coders ever. > > Only fools underestimate Java. > > Java is big, Java is ugly, Java is powerful and Java is here to stay > for a long, long time. > > My advice to Pharo, keep doing what you know best, helping lone coders > and small teams compete with large companies in terms of productivity. > Dont compete, innovate. > > On Wed, Nov 25, 2015 at 12:03 PM S Krish > <krishnamachari.sudhakar(a)gmail.com > <mailto:krishnamachari.sudhakar@gmail.com>> wrote: > > /Opportunities.. for Pharo.. > / > > / > / > > /The email, sent to InfoWorld on Tuesday by a former high-ranking > Java official, claimed to feature details from inside Oracle. It > said the company was becoming a cloud company, competing with > Salesforce, and âJava has no interest to them anymore.â The > subject line cited âJava â planned obsolescence.â/ > > /Oracle is not interested in empowering its competitors and > doesnât want to share innovation, the email further alleges. The > company is slimming down Java EE (Enterprise Edition), but it also > doesnât want anyone else to work on Java or Java EE and is > sidelining the JCP (Java Community Process). âThey have a > winner-take-all mentality and they are not interested in > collaborating,â said the email. âProprietary product work will be > done on WebLogic, and thereâll be a proprietary microservices > platform.â WebLogic is the Java application server Oracle acquired > when it bought BEA Systems in 2008./ > > https://dzone.com/articles/even-if-oracle-is-losing-interest-in-java-should… >

Nov. 25, 2015

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

by Eliot Miranda

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) _,,,^..^,,,_ (phone) > 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] empty Random package

by Marcus Denker

On Thu, Nov 19, 2015 at 4:39 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > and Ring-ChangesExtensions... > > If you will find the cleanup code, plese post it here because as I found, > the shrinking process generates several empty packages too... > > This is now in the last update ImageCleaner new removeEmptyPackages with removeEmptyPackages | empty | empty := RPackageOrganizer default packages select: #isEmpty. empty do: #unregister.

Nov. 25, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 25, 2015

[pharo-project/pharo-core] 558411: 50469

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 5584115135b6fd6fb3f6a157bf02028e2a853e4a https://github.com/pharo-project/pharo-core/commit/5584115135b6fd6fb3f6a157… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-25 (Wed, 25 Nov 2015) Changed paths: A RPackage-Core.package/RPackage.class/instance/testing/isEmpty.st R Reflectivity-Examples.package/MetalinkIconStyler.class/instance/defaults/icon.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/defaults/iconFor_.st A Reflectivity-Tools-Tests.package/WatchpointTests.class/instance/adding/testAddSameWatchpointSameNode.st A Reflectivity-Tools-Tests.package/WatchpointTests.class/instance/adding/testAddWatchpoint.st A Reflectivity-Tools-Tests.package/WatchpointTests.class/instance/adding/testAddWatchpointsSameNode.st A Reflectivity-Tools-Tests.package/WatchpointTests.class/instance/adding/testWatchpointTwice.st A Reflectivity-Tools-Tests.package/WatchpointTests.class/instance/recording/testStopRecording.st R Reflectivity-Tools-Tests.package/WatchpointTests.class/instance/values/testAddWatchpoint.st R Reflectivity-Tools.package/AbstractIconStyler.class/instance/defaults/icon.st A Reflectivity-Tools.package/AbstractIconStyler.class/instance/defaults/iconFor_.st M Reflectivity-Tools.package/AbstractIconStyler.class/instance/styling/addIconStyle_from_to_color_.st R Reflectivity-Tools.package/BreakpointIconStyler.class/instance/defaults/icon.st A Reflectivity-Tools.package/BreakpointIconStyler.class/instance/defaults/iconFor_.st M Reflectivity-Tools.package/Watchpoint.class/class/instance creation/in_named_.st M Reflectivity-Tools.package/Watchpoint.class/definition.st M Reflectivity-Tools.package/Watchpoint.class/instance/initialization/initialize.st M Reflectivity-Tools.package/Watchpoint.class/instance/install/install.st M Reflectivity-Tools.package/Watchpoint.class/instance/install/uninstall.st A Reflectivity-Tools.package/Watchpoint.class/instance/recording/isRecording.st A Reflectivity-Tools.package/Watchpoint.class/instance/recording/start.st A Reflectivity-Tools.package/Watchpoint.class/instance/recording/stop.st R Reflectivity-Tools.package/WatchpointIconStyler.class/instance/defaults/icon.st A Reflectivity-Tools.package/WatchpointIconStyler.class/instance/defaults/iconFor_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50468.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50469.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50468.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50469.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/SugsMenuBuilder.class/class/show/showMenuFor_.st M SmartSuggestions.package/SugsSuggestionFactory.class/class/cleanup/cleanUp.st M SmartSuggestions.package/SugsSuggestionFactory.class/class/methods/createBreakCommand.st M SmartSuggestions.package/SugsSuggestionFactory.class/class/methods/createBreakConditionCommand.st M SmartSuggestions.package/SugsSuggestionFactory.class/class/methods/createBreakOnceCommand.st M Tool-ImageCleaner.package/ImageCleaner.class/instance/api/cleanUpForRelease.st M Tool-ImageCleaner.package/ImageCleaner.class/instance/cleaning/examplePackages.st M Tool-ImageCleaner.package/ImageCleaner.class/instance/cleaning/helpPackages.st A Tool-ImageCleaner.package/ImageCleaner.class/instance/cleaning/removeEmptyCategories.st A Tool-ImageCleaner.package/ImageCleaner.class/instance/cleaning/removeEmptyPackages.st Log Message: ----------- 50469 17123 allowing start and stop recording for watchpoints https://pharo.fogbugz.com/f/cases/17123 16361 There are some empty packages https://pharo.fogbugz.com/f/cases/16361 17121 Allow breakpoint on everything https://pharo.fogbugz.com/f/cases/17121 http://files.pharo.org/image/50/50469.zip

Nov. 25, 2015