August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] why is gt playground not saving the code

by Esteban A. Maringolo

2016-08-31 18:43 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > >> On Aug 31, 2016, at 11:39 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> One use case that sometimes bites me is when I'm working in the "code" >> of the Playground (first screen), and then I start going deep with >> "Evaluate and Go", basically inspecting my objects, and then I close >> the window thinking I'm dealing with an inspector hence losing the >> code of the "workspace" in the Playground that started the inspection >> "workflow", without receiving any warning about "losing" my changes. >> I'd like an explicit "Save" in the Playground, but since I'm not >> adding it, I can't complain much. :) > > Thanks for the input. What would the Save do in this case? It should let me decide IF and WHEN to store the code contents. Also, if you tests scripts in a workspace and evaluate them "outside" of it (e.g. from the command line) I have to copy/paste the contents back and forth from the Playground to a text editor to save/modify something that in the past I did with the Workspace. > Should the âsave" save the code from the playground? Yes. > The code from the playground is actually not lost when you close the Playground, and neither is the code you write in the Raw panes. Or is there a different thing you have in mind? Is not lost, but sometimes I want to reset it (reload) from a previous saved state. Maybe the latest evaluation isn't what I want to recover. Also the menu isn't the best option if you have several expressions that start with the same characters and are indistinguishable from each other. I appreciate the "autosave" like feature (although I'd like to be able to disable it for security paranoid concerns), but I also like to decide when to save. But the use case I pointed wasn't about storing the contents outside of the playground but instead of getting a warning or something when closing the Playground doing inspection. Sometimes I don't want to close the playground, just want to reset everything to the original code pane as if no "Evaluate and Go" was ever ran. Regards! Esteban A. Maringolo

Aug. 31, 2016

Re: [Pharo-dev] why is gt playground not saving the code

by Tudor Girba

Hi, > On Aug 31, 2016, at 11:39 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > One use case that sometimes bites me is when I'm working in the "code" > of the Playground (first screen), and then I start going deep with > "Evaluate and Go", basically inspecting my objects, and then I close > the window thinking I'm dealing with an inspector hence losing the > code of the "workspace" in the Playground that started the inspection > "workflow", without receiving any warning about "losing" my changes. > I'd like an explicit "Save" in the Playground, but since I'm not > adding it, I can't complain much. :) Thanks for the input. What would the Save do in this case? Should the âsave" save the code from the playground? The code from the playground is actually not lost when you close the Playground, and neither is the code you write in the Raw panes. Or is there a different thing you have in mind? Doru > > Regards. > > > Esteban A. Maringolo > Esteban A. Maringolo > > > 2016-08-31 17:10 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: >> Hi, >> >> The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm? >> >> One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed. >> >> As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well. >> >> In any case, the dealing with the history of the playground is underdeveloped. So, letâs see if we can identify ways to improve the situation. >> >> What do you think? >> >> Cheers, >> Doru >> >> >>> On Aug 31, 2016, at 12:00 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>> At this point Iâve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose. >>> >>> In the picture below the code was demonstrably executed and yet itâs not in the history and if I would crash (which happens several times a day in âstableâ pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical codeâ¦ >>> >>> <F091EED2725D4C679C390F5BC76E1CE3.png> >>> >>> Peter >>> <F091EED2725D4C679C390F5BC76E1CE3.png> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Speaking louder won't make the point worthier." >> >> > -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

Aug. 31, 2016

Re: [Pharo-dev] why is gt playground not saving the code

by Esteban A. Maringolo

One use case that sometimes bites me is when I'm working in the "code" of the Playground (first screen), and then I start going deep with "Evaluate and Go", basically inspecting my objects, and then I close the window thinking I'm dealing with an inspector hence losing the code of the "workspace" in the Playground that started the inspection "workflow", without receiving any warning about "losing" my changes. I'd like an explicit "Save" in the Playground, but since I'm not adding it, I can't complain much. :) Regards. Esteban A. Maringolo Esteban A. Maringolo 2016-08-31 17:10 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm? > > One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed. > > As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well. > > In any case, the dealing with the history of the playground is underdeveloped. So, letâs see if we can identify ways to improve the situation. > > What do you think? > > Cheers, > Doru > > >> On Aug 31, 2016, at 12:00 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> At this point Iâve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose. >> >> In the picture below the code was demonstrably executed and yet itâs not in the history and if I would crash (which happens several times a day in âstableâ pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical codeâ¦ >> >> <F091EED2725D4C679C390F5BC76E1CE3.png> >> >> Peter >> <F091EED2725D4C679C390F5BC76E1CE3.png> > > -- > www.tudorgirba.com > www.feenk.com > > "Speaking louder won't make the point worthier." > >

Aug. 31, 2016

Re: [Pharo-dev] Binary selector and special characters

by Thierry Goubier

2016-08-31 20:55 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-08-31 17:31 GMT+02:00 John Brant <brant(a)refactoryworkers.com>: > >> On 08/31/2016 08:46 AM, Nicolai Hess wrote: >> >> Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner) >>> explicit allowes >>> "#($Â± $Â· $Ã $Ã·)" to be binary selector characters ? >>> >> >> I do -- I added them about 20 years ago :)... >> >> Is there any smalltalk dialect that uses these characters ? >>> >> >> VW allows them. When possible, we made the scanner/parser be a superset >> of the VW & VA syntax. >> >> >> John Brant >> >> > Thank you John, for the info. > Hm, now, what to do, fix our (pharo) parser to allowe these characters as > binary selectors or change the scanner to not > generate binary selector tokens for them... > I'd say change the parser to accept them. Thierry

Aug. 31, 2016

Re: [Pharo-dev] About Pharo 60

by Serge Stinckwich

On Wed, Aug 31, 2016 at 9:16 PM, stepharo <stepharo(a)free.fr> wrote: > In squeak by example > > we could tag in the document code snippet as text and a perl script > > turn the expression into Sunit method and run the tests > > We lost that. Yes I remember this was very nice. We should have a look to the org-babel env that I demonstrate shortly during the ESUG "show us your project" session. This based also on a markup language (org-mode) and you could use for doing literate programming: http://orgmode.org/worg/org-contrib/babel/ Some lessons should be extracted from that in order to enhance Pillar in this direction also. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 31, 2016

Re: [Pharo-dev] why is gt playground not saving the code

by Sven Van Caekenberghe

You can also explicitly name your pages (tabs) by double-clicking the title and changing it. Then your pages get copied to play-stash using that name. This gives you more control over what happens. > On 31 Aug 2016, at 22:30, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > On Wed, Aug 31, 2016 at 10:10:21PM +0200, Tudor Girba wrote: >> Hi, >> >> The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm? >> >> One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed. >> >> As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well. >> >> In any case, the dealing with the history of the playground is underdeveloped. So, letâs see if we can identify ways to improve the situation. >> >> What do you think? > > Thank you both for the answers, I didn't know there was a disk storage that was independent of what was shown to me, so next time I crash I will check. > But there were other strange issues going around, or at least confusing. So I'll try to play with it a bit tomorrow. > > Thanks, > Peter

Aug. 31, 2016

Re: [Pharo-dev] why is gt playground not saving the code

by Peter Uhnak

On Wed, Aug 31, 2016 at 10:10:21PM +0200, Tudor Girba wrote: > Hi, > > The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm? > > One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed. > > As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well. > > In any case, the dealing with the history of the playground is underdeveloped. So, letâs see if we can identify ways to improve the situation. > > What do you think? Thank you both for the answers, I didn't know there was a disk storage that was independent of what was shown to me, so next time I crash I will check. But there were other strange issues going around, or at least confusing. So I'll try to play with it a bit tomorrow. Thanks, Peter

Aug. 31, 2016

Re: [Pharo-dev] why is gt playground not saving the code

by Tudor Girba

Hi, The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm? One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed. As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well. In any case, the dealing with the history of the playground is underdeveloped. So, letâs see if we can identify ways to improve the situation. What do you think? Cheers, Doru > On Aug 31, 2016, at 12:00 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > At this point Iâve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose. > > In the picture below the code was demonstrably executed and yet itâs not in the history and if I would crash (which happens several times a day in âstableâ pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical codeâ¦ > > <F091EED2725D4C679C390F5BC76E1CE3.png> > > Peter > <F091EED2725D4C679C390F5BC76E1CE3.png> -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

Aug. 31, 2016

Re: [Pharo-dev] About Pharo 60

by stepharo

In squeak by example we could tag in the document code snippet as text and a perl script turn the expression into Sunit method and run the tests We lost that. Stef Le 31/8/16 Ã 12:21, Peter Uhnak a Ã©crit : > On Wed, Aug 31, 2016 at 12:00:30PM +0200, Yuriy Tymchuk wrote: >> Ok, now I know what I want. >> >> I want a better way to document. Because Iâm trying to write a documentation about my stuff, but there are too many disconnected ways to do that. Iâm trying to always have reasonable class comments. But sometimes you need a more general description, so you write help topics which are disconnected from class comments. Yes, we can add help topics generated from class comments but thatâs too weak. Additionally I version my projects on github, so I want t doc there in readme, or on a wiki. Whatâs more I think that itâs a good idea to export doc to the web. Because when someone mentioned package manifest I started to google for it and could not find anything. >> >> My suggestions: >> - write comments in pillar and slowly add pillar support to enrich comment (documentation) styles >> - add a possibility to reference classes/methods and help topics from pillar comments >> - have exporters to generate html documentation about a project based on comments and help topics >> - then I will be able to add a hook to Icebeg telling it: ok, on commit also generate a doc and export it as MarkDown (because we can) and commit it as a README or as a wiki entry or whatever. >> >> This way we will have interconnected documentation in the image, and if it should be placed somewhere else we export it. > +14. > > Knowing that I cannot verify that the documentation is sync with code is very discouraging to even start writing the docs. When I was writing a chapter for agile visualization, I had the examples as independent scripts which I could execute (I believe Pillar has added executable examples since then). > > But there are more things than examples, e.g. a Travis could run "docs verification" that would look at all the code (so even method and class name references) and made sure they exist and are not, say, deprecated. As Pillar provides you with a real syntax tree this might not be so hard. > > At least personally the above could be a real value for me with Pillar, because up until now it was just another document format (and there's a lot of better ones) with poor infrastructure. But deep integration with Pharo could make it really valuable, and we are getting there. > >> - then I will be able to add a hook to Icebeg telling it: ok, on commit also generate a doc and export it as MarkDown (because we can) and commit it as a README or as a wiki entry or whatever. > so close :) https://github.com/peteruhnak/IconFactory/blob/master/repository/BaselineOf… > > Peter > >

Aug. 31, 2016

Re: [Pharo-dev] Binary selector and special characters

by Nicolai Hess

2016-08-31 17:31 GMT+02:00 John Brant <brant(a)refactoryworkers.com>: > On 08/31/2016 08:46 AM, Nicolai Hess wrote: > > Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner) >> explicit allowes >> "#($Â± $Â· $Ã $Ã·)" to be binary selector characters ? >> > > I do -- I added them about 20 years ago :)... > > Is there any smalltalk dialect that uses these characters ? >> > > VW allows them. When possible, we made the scanner/parser be a superset of > the VW & VA syntax. > > > John Brant > > Thank you John, for the info. Hm, now, what to do, fix our (pharo) parser to allowe these characters as binary selectors or change the scanner to not generate binary selector tokens for them...

Aug. 31, 2016