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

Re: [Pharo-dev] [Pharo-users] [ann] gtspotter: a moldable interface for spotting objects

by Tudor Girba

Hi Christophe, On Mon, Dec 8, 2014 at 10:43 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi Doru and all, > > Great work. All these tools are really moving the development experience a > step forward :) > I will try it ASAP. > At this time, I just wonder if it is possible to search text in method > sources. It is often useful. > It's not done now, but you can just add it. It should probably take you a couple of minutes :). Just try to follow the instructions from the end of the post and let us know how it goes. > Another related thing I don't know how to do, is to refactor a set of > methods (could be some methods to 20 or more). In these methods, I send a > specific message. Now, I just want to remove the message implementation (it > is not a rename) and I have to update the code accordingly. Sometimes, I > could do that by just a search/replace (text) functionality (would be cool > to use patterns there) in methods source code but I cannot find a way do > that for now. So I do it by hand. > I wonder if it already exists a way to do that or if GTSpotter could > address this issue. > I think this is out of the direct realm of GTSpotter. But, it would be an interesting area nevertheless. We would likely be able to benefit from combining somehow RB rules with spotter. Cheers, Doru > Christophe. > > Le 7 dÃ©c. 2014 Ã 14:14, Tudor Girba a Ã©crit : > > Hi, > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to the > Glamorous Toolkit: > GTSpotter, a novel interface for spotting objects. > > GTSpotter has two goals: > - Provide a uniform yet moldable interface that can work on any object, and > - Handle searching through arbitrary levels of object nesting. > > We think this will have a significant impact on the development workflow > in Pharo. > > Here is a couple of screenshots: > <gtspotter-packages-classes.png> <gtspotter-dive-class-method-sender.png> > <gtspotter-playground.png> > > > A trailer is available here: > https://www.youtube.com/watch?v=PhSmjR3NOlU > > A detailed description is available here: > http://www.humane-assessment.com/blog/introducing-gtspotter > > It works already in Pharo 3.0 and can be played with by following the > instructions from: > http://gt.moosetechnology.org > > Please let us know what you think. > > Enjoy, > The Glamorous Team > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Torsten Bergmann

I would go the opposite direction and rename the "Playground" window to "Workspace". Several reasons: 1. "Playground" reminds me too much on toyish things (and we had too much of this in the past already, thats why Pharo was forked). The windows intention is to be used for both: prototyping and serious stuff. 2. "Workspace" depicts the area where you usually work and this term is IMHO much much better suited. It is also a common concept known not only in Smalltalk but also other IDE's. 3. I do not understand where the significant shift is (that justifies a new name) as we had similar tools already in the past. Basically it is a script space merged with an inspector, so more an evolution instead of a revolution. (This does not mean that I'm not happy that the GT tools are now in and provide such an easy to use extensibility!) 3. There is a "Workspace open" but no "Playground open" possibility. 4. Having two separate tools "Workspace" and "Playground" with nearly similar goals (write scripts and inspect objects) would be confusing for newbees. Maybe we could set up a "community voting" somewhere. Other things I would like to see: ================================= A. Change to "double clicking" behavior instead of "single clicking" when diving deeper into the iVars of objects. This would allow to use it as a normal inspector first without having directly more and more panes opening to the right. Anytime I start with a script in the initial code pane it is moving away when using "Do it and go" and clicking on my objects iVars in the right list view. With a "double click" the user could decide hisself if he just wants to select (single click to do any other menu item action) or dive deeper into the object (double click). B. Possibility to have splitters between the opened panes because sometimes the area is not wide enough. C. When several windows are open the "playgrounds" can not be distinguished by title in the world tool bar. Note that when I save a workspace contents the title of the workspace window is changed to the *.ws file. D. Change the initial tab name to something more meaninful (related to C). Or use a better timestamp representation as the current precision. As a human I do not distinguish up to milliseconds when opening such a window. Maybe up to seconds is enough. Using a tab is questionable by itself - we never have more than one on the initial code pane... E. Easily saving in the cloud is nice - but I would ask the user before sending it. This prevents wrong usage by accidentially clicking. Think of usage in a business scenario where you may work with confidential data that would otherwise be posted on the web... Thanks T.

Dec. 8, 2014

Re: [Pharo-dev] [Pharo-users] [ann] gtspotter: a moldable interface for spotting objects

by Christophe Demarey

Hi Doru and all, Great work. All these tools are really moving the development experience a step forward :) I will try it ASAP. At this time, I just wonder if it is possible to search text in method sources. It is often useful. Another related thing I don't know how to do, is to refactor a set of methods (could be some methods to 20 or more). In these methods, I send a specific message. Now, I just want to remove the message implementation (it is not a rename) and I have to update the code accordingly. Sometimes, I could do that by just a search/replace (text) functionality (would be cool to use patterns there) in methods source code but I cannot find a way do that for now. So I do it by hand. I wonder if it already exists a way to do that or if GTSpotter could address this issue. Christophe. Le 7 dÃ©c. 2014 Ã 14:14, Tudor Girba a Ã©crit : > Hi, > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to the Glamorous Toolkit: > GTSpotter, a novel interface for spotting objects. > > GTSpotter has two goals: > - Provide a uniform yet moldable interface that can work on any object, and > - Handle searching through arbitrary levels of object nesting. > > We think this will have a significant impact on the development workflow in Pharo. > > Here is a couple of screenshots: > <gtspotter-packages-classes.png> <gtspotter-dive-class-method-sender.png> <gtspotter-playground.png> > > > A trailer is available here: > https://www.youtube.com/watch?v=PhSmjR3NOlU > > A detailed description is available here: > http://www.humane-assessment.com/blog/introducing-gtspotter > > It works already in Pharo 3.0 and can be played with by following the instructions from: > http://gt.moosetechnology.org > > Please let us know what you think. > > Enjoy, > The Glamorous Team

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Tudor Girba

Hi Kilon, I agree with you in saying that we should have documentation. But, those tools are already added. And they are documented on the humane-assessment.com blog, and this can serve as a strong basis for a more official documentation. Please keep in mind that Pharo 4.0 is still under development, and things will still change until the release. And, of course, we would welcome anyone willing to contribute with documentation. Cheers, Doru On Mon, Dec 8, 2014 at 10:27 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > I disagree as I also disagree with the replacement of workspace and the > inspector. > > My opinion on this can be summarised as "*Nothing should be added to > Pharo without being fully documented*" . > > The use of workspace and the inspector is well documented in PBE. There is > no official documentation for GTPlayground and GTInspector. Sure those > tools are not as powerful as the tools you guys have developed but they are > production ready, well tested and fully documented. > > But I know of course that my opinion is not popular since pharoers care > more about extending their environment than caring about newcomers or > teaching people how to use Pharo. This is a trend that has dominated Pharo > and it looks it will continue and takes Pharo a direction I definetly dont > want to go. On the other hand Pharo is the only tool and language that does > this at least compared to my experience. > > On Mon, Dec 8, 2014 at 10:47 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> This makes a lot of sense. >> >> Having a plain workspace alongside would be perfect for me. >> >> I am using Playground in my 3.0 (now having installed the new version >> with the nicer menus) and it works well. But this is definitely not what I >> use as a workspace. >> >> One use case for a plain Workspace is when providing a kind of list of >> sample commands to customers to use on the image. >> >> Like in: "Open this workspace contents, here are the typical commands for >> you to use". >> >> Removing this ability and having a large thing popping at the right is >> really disturbing for these use cases. >> >> Phil >> >> >> >> On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> As you might see, the GTPlayground is called playground not workspace. >>> The main reason for this is that workspace implies the place where work is >>> done, and work is typically associated with creating code. >>> >>> This is not the intention of the workspace. >>> >>> Workspace also comes with a history that is associated with actual >>> implementations. While the current GTPlayground might appear to be similar >>> to the workspace, I think the way you can use the latter produces a >>> significant shift. >>> >>> Furthermore, I think the term playground is more inline with the idea of >>> "playing with live objects". And, in the future, the implementation will >>> likely evolve towards even more liveliness. >>> >>> It is for this reason that I would prefer that the World menu item gets >>> renamed to Playground. >>> >>> What do you think? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by phil＠highoctane.be

On Mon, Dec 8, 2014 at 10:27 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > I disagree as I also disagree with the replacement of workspace and the > inspector. > > My opinion on this can be summarised as "*Nothing should be added to > Pharo without being fully documented*" . > > The use of workspace and the inspector is well documented in PBE. There is > no official documentation for GTPlayground and GTInspector. Sure those > tools are not as powerful as the tools you guys have developed but they are > production ready, well tested and fully documented. > That's why I think we should keep the classic tools in the system. I am going to train people for two days on how to use the application and people ask for reference works to read. I fall they see is different from the books, that's a problem indeed. Phil > > But I know of course that my opinion is not popular since pharoers care > more about extending their environment than caring about newcomers or > teaching people how to use Pharo. This is a trend that has dominated Pharo > and it looks it will continue and takes Pharo a direction I definetly dont > want to go. On the other hand Pharo is the only tool and language that does > this at least compared to my experience. > > On Mon, Dec 8, 2014 at 10:47 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> This makes a lot of sense. >> >> Having a plain workspace alongside would be perfect for me. >> >> I am using Playground in my 3.0 (now having installed the new version >> with the nicer menus) and it works well. But this is definitely not what I >> use as a workspace. >> >> One use case for a plain Workspace is when providing a kind of list of >> sample commands to customers to use on the image. >> >> Like in: "Open this workspace contents, here are the typical commands for >> you to use". >> >> Removing this ability and having a large thing popping at the right is >> really disturbing for these use cases. >> >> Phil >> >> >> >> On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> As you might see, the GTPlayground is called playground not workspace. >>> The main reason for this is that workspace implies the place where work is >>> done, and work is typically associated with creating code. >>> >>> This is not the intention of the workspace. >>> >>> Workspace also comes with a history that is associated with actual >>> implementations. While the current GTPlayground might appear to be similar >>> to the workspace, I think the way you can use the latter produces a >>> significant shift. >>> >>> Furthermore, I think the term playground is more inline with the idea of >>> "playing with live objects". And, in the future, the implementation will >>> likely evolve towards even more liveliness. >>> >>> It is for this reason that I would prefer that the World menu item gets >>> renamed to Playground. >>> >>> What do you think? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by kilon alios

I disagree as I also disagree with the replacement of workspace and the inspector. My opinion on this can be summarised as "*Nothing should be added to Pharo without being fully documented*" . The use of workspace and the inspector is well documented in PBE. There is no official documentation for GTPlayground and GTInspector. Sure those tools are not as powerful as the tools you guys have developed but they are production ready, well tested and fully documented. But I know of course that my opinion is not popular since pharoers care more about extending their environment than caring about newcomers or teaching people how to use Pharo. This is a trend that has dominated Pharo and it looks it will continue and takes Pharo a direction I definetly dont want to go. On the other hand Pharo is the only tool and language that does this at least compared to my experience. On Mon, Dec 8, 2014 at 10:47 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > This makes a lot of sense. > > Having a plain workspace alongside would be perfect for me. > > I am using Playground in my 3.0 (now having installed the new version with > the nicer menus) and it works well. But this is definitely not what I use > as a workspace. > > One use case for a plain Workspace is when providing a kind of list of > sample commands to customers to use on the image. > > Like in: "Open this workspace contents, here are the typical commands for > you to use". > > Removing this ability and having a large thing popping at the right is > really disturbing for these use cases. > > Phil > > > > On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> As you might see, the GTPlayground is called playground not workspace. >> The main reason for this is that workspace implies the place where work is >> done, and work is typically associated with creating code. >> >> This is not the intention of the workspace. >> >> Workspace also comes with a history that is associated with actual >> implementations. While the current GTPlayground might appear to be similar >> to the workspace, I think the way you can use the latter produces a >> significant shift. >> >> Furthermore, I think the term playground is more inline with the idea of >> "playing with live objects". And, in the future, the implementation will >> likely evolve towards even more liveliness. >> >> It is for this reason that I would prefer that the World menu item gets >> renamed to Playground. >> >> What do you think? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by phil＠highoctane.be

This makes a lot of sense. Having a plain workspace alongside would be perfect for me. I am using Playground in my 3.0 (now having installed the new version with the nicer menus) and it works well. But this is definitely not what I use as a workspace. One use case for a plain Workspace is when providing a kind of list of sample commands to customers to use on the image. Like in: "Open this workspace contents, here are the typical commands for you to use". Removing this ability and having a large thing popping at the right is really disturbing for these use cases. Phil On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > As you might see, the GTPlayground is called playground not workspace. The > main reason for this is that workspace implies the place where work is > done, and work is typically associated with creating code. > > This is not the intention of the workspace. > > Workspace also comes with a history that is associated with actual > implementations. While the current GTPlayground might appear to be similar > to the workspace, I think the way you can use the latter produces a > significant shift. > > Furthermore, I think the term playground is more inline with the idea of > "playing with live objects". And, in the future, the implementation will > likely evolve towards even more liveliness. > > It is for this reason that I would prefer that the World menu item gets > renamed to Playground. > > What do you think? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Hilaire

Le 08/12/2014 07:18, Tudor Girba a Ã©crit : > It is for this reason that I would prefer that the World menu item gets > renamed to Playground. > > What do you think? > I agree with your POV Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Dec. 8, 2014

playground vs workspace

by Tudor Girba

Hi, As you might see, the GTPlayground is called playground not workspace. The main reason for this is that workspace implies the place where work is done, and work is typically associated with creating code. This is not the intention of the workspace. Workspace also comes with a history that is associated with actual implementations. While the current GTPlayground might appear to be similar to the workspace, I think the way you can use the latter produces a significant shift. Furthermore, I think the term playground is more inline with the idea of "playing with live objects". And, in the future, the implementation will likely evolve towards even more liveliness. It is for this reason that I would prefer that the World menu item gets renamed to Playground. What do you think? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Dec. 8, 2014

Re: [Pharo-dev] trying to download Hapa'o in a fresh Pharo image (4.0)

by Alejandro Infante

Hello, Actually that version of Hapao is really outdated, currently we are using S2py, a brand new release of Spy that involve mayor changes in performance and design using everything that we learnt developing Spy. Since it depends on Roassal2, you have to load it first. Gofer new smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; package: 'ConfigurationOfRoassal2'; load. (Smalltalk at: #ConfigurationOfRoassal2) load. And then we load Spy2. Gofer new smalltalkhubUser: 'ObjectProfile' project: 'S2py'; package: 'S2py'; load. Hapao is already included on Spy2, so you donât have to do anything else. To use Hapao you can do it from the WorldMenu or using a workspace like: (Hapao2 runTestsForClasses: RTObject withAllSubclasses , RTTest withAllSubclasses) visualize or (Hapao2 runTestsForPackagesMatching: 'Nautilus*') visualize I have already tried this on today fresh 4.0 image so unless I mess up on a commit tonight it should work. Let us know how was your experience! All the feedback is welcome. Cheers, Alejandro > On Dec 7, 2014, at 7:56 PM, sheridan(a)sheridan-mahoney.com wrote: > > Hello, > > I am trying to get Hapa'o loaded in a fresh 4.0 image, using the following command: > > Gofer new > squeaksource: 'Spy'; > package: 'ConfigurationOfSpy'; > load. > (Smalltalk at: #ConfigurationOfSpy) perform: #loadDefault > > and I run across this error: > > This package depends on the following classes: > RBFormatter > You must resolve these dependencies before you will be able to load these definitions: > HapaoLineCoverage > acceptAssignmentNode: > acceptBlockNode:startBlockString:endBlockString: > acceptCascadeNode: > acceptLiteralArrayNode: > acceptLiteralNode: > acceptMessageNode: > acceptPragmaNode: > acceptReturnNode: > acceptSequenceNode: > acceptVariableNode: > addAllText: > addCoverageAtribute:isCovered: > addText: > coveredCondition > format: > ... > > This isn't something I'm familiar with, can someone tell me how to resolve it? > > Many thanks, > > Sheridan >

Dec. 8, 2014