- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Monticello and Fuel

by Chris Muller

> Yes, performance seems to be the main use case. Fuel files of hundreds of MB > take a long time to load and save, even if you only change a single string. > One instance where this is relevant is the Moose model. They currently use > .mse files, which use a textual representation (if Iâm not mistaken). Usman > asked me if Fuel were an option, especially for updating only parts of the > model. > > > Ok, but how could patching the file be much faster? The file has to be > parsed into something; why not the objects themselves? To me loading, > editing and red acing is patching and done as fast as Fuel can do things. > > Depending on syntax you may be able to scan for a string and replace using > eg the sed stream editor. But that'll only work for simple data like > strings. > > If you really need this to be faster have you considered > > - decomposing the Moose model into smaller individual components? > > - keeping the moose model to be saved in an image (possibly live running in > a server) and patching the model in the image and saving it This is a classic problem; as models start to get large they get harder to update. If there were some way to update the file with just the parts in memory that changed since the last save, it would perform a lot faster for the end user. Of course whatever makes models large is also what tends to make them more interesting to more users, but moves inversely to the sharability. Some kind of server is needed to serve up the fuel file and use the above to dish out whatever portions of the file needed by user for the part of the model they're accessing. When they save, only the parts of the model they changed, nothing more, are sent back to the server which performs a random-access update to the fuel file in a controlled, synchronous manner. Although, even with that I guess users could still overlay other users work very easily. Some kind of concurrency control mechanism should look at the changes being made and signal a warning if that happens.

Dec. 8, 2014

trying to download Hapa'o in a fresh Pharo image (4.0)

by sheridan＠sheridan-mahoney.com

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. 7, 2014

Code repository

by Benoit St-Jean

Hi guys! Coming back to Pharo! I was wondering, what is the preferred code repository for Pharo 3.x/4.x packages?Â SqueakSource 3 or SmalltalkHub ? tiaÂ ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

Dec. 7, 2014

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

by Tudor Girba

Hi Sven, Exactly! :) To be relevant, we had to show how it solves existing use cases (plus a bit more :)). Next we will focus on objects that are less "code". The hard part of actually getting the interface smooth and performant was kind of done. It's play time now :). As I noted in the post, we already have some 30 extensions for handling these cases. This was actually easy. The menu is an example of how we used this concept to approach a problem that is classically dealt with in a completely different way. There are a couple of things we did not show yet. For example, we already have a simple implementation of how to make a Moose model completely browseable through this interface. But, as with the inspector, the coolest thing is that if someone has a specific need, it is even simpler than with the inspector to hook that need in the system and make it searchable. Your list is definitely exciting, and I am hoping that people will start playing a bit and discover things we otherwise would not consider. It should be easier than with the inspector (because there are less things to specify, hence less variation). And wait to see what happens when we start to combine this interface with others. For example, the interesting thing about being able to search a menu is that you can actually open any menu with a spotter, which essentially has the potential of changing the way we deal with contextual actions (all through keybindings without shortcuts). I am quite sure we are just scratching the surface of what is possible. So, let's play together :). Cheers, Doru On Sun, Dec 7, 2014 at 10:35 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Doru, > > One of the things/aspects that I miss a bit is the 'objects' part. In your > overall description/presentation you talk about 'objects', but right now I > would say it are mainly 'code objects' like classes & methods and friends, > and some IDE artefacts, like menus. > > What about arbitrary (user) objects ? > > Literal constants, like 123, 'some string' ? > Globals like the Transcript ? > Singletons accessible by class side accessors, like announcers ? > An evaluation functionality, just type an expression ? > Examples ? > The clipboard (contents), open windows, processes, ... > > Anyway, I am sure you get the idea ;-) > > Sven > > > On 07 Dec 2014, at 19:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi Sven, > > > > Thanks for the kind words. Indeed, having the current selection is one > of the things we should keep in mind. For that we need to go to the next > step and integrate the interface in the overall environment. This will > certainly come. > > > > Cheers, > > Doru > > > > > > > > On Sun, Dec 7, 2014 at 6:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > On 07 Dec 2014, at 14:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to > the Glamorous Toolkit: > > > GTSpotter, a novel interface for spotting objects. > > > > Excellent work, all around. Congratulations to the team. Thank you for > pushing things like this, for thinking differently. > > > > Yes, I want this in Pharo 4 too, ASAP (especially since the main > shortcut is different from the old one, cmd+Enter vs. shift+Enter). > > > > The presentation is again very well done too: excellent article, super > movie. You are putting the bar very high for the rest of us ;-) > > > > A suggestion/idea: would it be possible to take the current selection > anywhere and feed it into Spotter ? That way there would be very good way > to make it replace all the other shortcuts: you would get implementers, > senders, references almost for free. > > > > Sven > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 7, 2014

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

by Sven Van Caekenberghe

Doru, One of the things/aspects that I miss a bit is the 'objects' part. In your overall description/presentation you talk about 'objects', but right now I would say it are mainly 'code objects' like classes & methods and friends, and some IDE artefacts, like menus. What about arbitrary (user) objects ? Literal constants, like 123, 'some string' ? Globals like the Transcript ? Singletons accessible by class side accessors, like announcers ? An evaluation functionality, just type an expression ? Examples ? The clipboard (contents), open windows, processes, ... Anyway, I am sure you get the idea ;-) Sven > On 07 Dec 2014, at 19:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Sven, > > Thanks for the kind words. Indeed, having the current selection is one of the things we should keep in mind. For that we need to go to the next step and integrate the interface in the overall environment. This will certainly come. > > Cheers, > Doru > > > > On Sun, Dec 7, 2014 at 6:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 07 Dec 2014, at 14:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to the Glamorous Toolkit: > > GTSpotter, a novel interface for spotting objects. > > Excellent work, all around. Congratulations to the team. Thank you for pushing things like this, for thinking differently. > > Yes, I want this in Pharo 4 too, ASAP (especially since the main shortcut is different from the old one, cmd+Enter vs. shift+Enter). > > The presentation is again very well done too: excellent article, super movie. You are putting the bar very high for the rest of us ;-) > > A suggestion/idea: would it be possible to take the current selection anywhere and feed it into Spotter ? That way there would be very good way to make it replace all the other shortcuts: you would get implementers, senders, references almost for free. > > Sven > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Dec. 7, 2014