June 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Playground auto-save?

by Hilaire

June 19, 2019

Re: [Pharo-users] Playground auto-save?

by Esteban Maringolo

I still don't know why there is no explicit "save", to at least capture that state in the play-stash. There is an explicit "publish" to the cloud, but no save. Esteban A. Maringolo On Wed, Jun 19, 2019 at 2:34 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > if you give the playground's tab a name, it will save it under that name > in pharo-local/play-stash - which I found reasonably reliable. > > > On 19 Jun 2019, at 15:38, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi Hilaire, > > > > this is a known problem. I've been losing code to Playground for years. > (e.g. using undo (ctrl+z) is a good way to lose code) > > > > What helps a lot is to look into pharo-local/play-cache directory (you > can open Spotter and type in "pharo-local" (without quotes)) which contains > a log of probably 90% of playgrounds you executed. > > > > There are still some conditions under which you can lose code even with > play-cache (e.g. ctrl+z sometimes)... so good to keep that in mind. > > > > Peter > > > > On Wed, Jun 19, 2019 at 3:20 PM Hilaire <hilaire(a)drgeo.eu> wrote: > > Beside that, auto-save is a nice feature, but it needs to be predictable. > > > > Hilaire > > > > Le 18/06/2019 Ã 21:53, Hilaire a Ã©crit : > > > Hi, > > > > > > I have to admit it is working randomly in P7 with Dr.Geo. (19.06 rel) > > > > > > Sometime script can be retrieved with the playpage button other time > no: > > > executed script can not be retrieved. > > > > > > Its behavior is not predictable and it is a problem for me and the kids > > > playing code. > > > > > > Hilaire > > > > -- > > Dr. Geo > > http://drgeo.eu > > > > > > > > >

June 19, 2019

Re: [Pharo-users] Playground auto-save?

by Hilaire

Ok, good to know. Looking fot pharo-local from Spotter does not produce meaningful results within DrGeo (P7 based), screenshot attached. The folder DrGeo/Contents/Resources/pharo-local/play-cache exists though Thanks. Le 19/06/2019 Ã 15:38, Peter Uhnak a Ã©critÂ : > this is a known problem. I've been losing code to Playground for > years. (e.g. using undo (ctrl+z) is a good way to lose code) > -- Dr. Geo http://drgeo.eu

June 19, 2019

Re: [Pharo-users] Playground auto-save?

by Sven Van Caekenberghe

if you give the playground's tab a name, it will save it under that name in pharo-local/play-stash - which I found reasonably reliable. > On 19 Jun 2019, at 15:38, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi Hilaire, > > this is a known problem. I've been losing code to Playground for years. (e.g. using undo (ctrl+z) is a good way to lose code) > > What helps a lot is to look into pharo-local/play-cache directory (you can open Spotter and type in "pharo-local" (without quotes)) which contains a log of probably 90% of playgrounds you executed. > > There are still some conditions under which you can lose code even with play-cache (e.g. ctrl+z sometimes)... so good to keep that in mind. > > Peter > > On Wed, Jun 19, 2019 at 3:20 PM Hilaire <hilaire(a)drgeo.eu> wrote: > Beside that, auto-save is a nice feature, but it needs to be predictable. > > Hilaire > > Le 18/06/2019 Ã 21:53, Hilaire a Ã©crit : > > Hi, > > > > I have to admit it is working randomly in P7 with Dr.Geo. (19.06 rel) > > > > Sometime script can be retrieved with the playpage button other time no: > > executed script can not be retrieved. > > > > Its behavior is not predictable and it is a problem for me and the kids > > playing code. > > > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > >

June 19, 2019

Re: [Pharo-users] Playground auto-save?

by Peter Uhnak

Hi Hilaire, this is a known problem. I've been losing code to Playground for years. (e.g. using undo (ctrl+z) is a good way to lose code) What helps a lot is to look into pharo-local/play-cache directory (you can open Spotter and type in "pharo-local" (without quotes)) which contains a log of probably 90% of playgrounds you executed. There are still some conditions under which you can lose code even with play-cache (e.g. ctrl+z sometimes)... so good to keep that in mind. Peter On Wed, Jun 19, 2019 at 3:20 PM Hilaire <hilaire(a)drgeo.eu> wrote: > Beside that, auto-save is a nice feature, but it needs to be predictable. > > Hilaire > > Le 18/06/2019 Ã 21:53, Hilaire a Ã©crit : > > Hi, > > > > I have to admit it is working randomly in P7 with Dr.Geo. (19.06 rel) > > > > Sometime script can be retrieved with the playpage button other time no: > > executed script can not be retrieved. > > > > Its behavior is not predictable and it is a problem for me and the kids > > playing code. > > > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > >

June 19, 2019

Re: [Pharo-users] Playground auto-save?

by Hilaire

Beside that, auto-save is a nice feature, but it needs to be predictable. Hilaire Le 18/06/2019 Ã 21:53, Hilaire a Ã©critÂ : > Hi, > > I have to admit it is working randomly in P7 with Dr.Geo. (19.06 rel) > > Sometime script can be retrieved with the playpage button other time no: > executed script can not be retrieved. > > Its behavior is not predictable and it is a problem for me and the kids > playing code. > > Hilaire -- Dr. Geo http://drgeo.eu

June 19, 2019

Re: [Pharo-users] Question: anyone using NOCompletion setting?

by Marcus Denker

> On 18 Jun 2019, at 19:34, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I use it sometimes. IIRC there was a paper that it was objectively better at > finding the "right" thing. Are you thinking of removing it? > > I would like to re-implement sorting of results in a more pluggable wayâ¦ so that e.g. people can add more sorting ideas. But doing that in one step seems hardâ¦ it would be much easier if we could simplify the system first. Removing the Ocompletion (for a while) would make it much easierâ¦ Marcus

June 19, 2019

Playground auto-save?

by Hilaire

Hi, I have to admit it is working randomly in P7 with Dr.Geo. (19.06 rel) Sometime script can be retrieved with the playpage button other time no: executed script can not be retrieved. Its behavior is not predictable and it is a problem for me and the kids playing code. Hilaire -- Dr. Geo http://drgeo.eu

June 18, 2019

Re: [Pharo-users] Iceberg loading a Tonel package migrated using SETT

by Esteban Maringolo

Dale, Besides the issue affecting this particular case, I think that the Tonel "format" should support and honor "metadata" at the class/package/method level. E.g. the SETT exporter creates the #vw_namespace for classes, other dialects may need to specify other information that would be useful that when written back by Pharo are honored as well. E.g. You export a package from VW that has the class "Foo" in the "FooNamespace" namespace, so the Tonel class type definition will be defined with "Foo" as name and the #vw_namespace set to be "FooNamespace", if you lad this into Pharo everything will compile because the #vw_namespace will be ignored, but once you commit back the #vw_namespace property will be lost. I can think in other cases like Dolphin's class GUID or VAST Application/Subapplication mapping to a package or public/private to methods, etc. Tonel files don't have exactly the best format, but it seems to be the one that has the most widespread adoption in file based SCM, and maybe we (as a Smalltalk community) could make another attempt of having a common format to interchange code between dialects without much effort from the "main trunk" (Pharo). Regards, Esteban A. Maringolo On Tue, Jun 18, 2019 at 2:32 PM Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > SETT was create based on our understanding (GemTalk Systems) of what the > tonel disk format was _supposed_ to be and I think that Pharo has departed > from somewhat from what was understood to be the format. > > I've had similar problems trying to use filetree repositories with Iceberg > that have been readable by the old Monticello/Filetree readers for years > [1] ... and are readable when loaded through the Monticello Browser, but > not readable when using Iceberg ... > > One of these days, there needs to be agreement as to what the actual disk > format of tonel and filetree repositories is going to be/has been and then > stick to them, otherwise these problems are going to continue to plague us. > > Dale > > [1] https://github.com/pharo-vcs/iceberg/issues/1239 > On 6/18/19 6:40 AM, Esteban Maringolo wrote: > > Hi Guillermo, > > Your workaround effectively solved my issue. > > About the tonel format, in the .properties file at the sources directory > there was such setting: > > https://github.com/eMaringolo/rbac/blob/9279f22ef5fd1c4149090b5b39a6afa143a… > > > But the .project file was missing at the root of the repository. So maybe > it is a mix of both conditions. > > In any case, I'm glad the workaround works, and that it helped spotting a > bug. > > Thank you! > > > Esteban A. Maringolo > > > On Tue, Jun 18, 2019 at 4:35 AM Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Iâve created an issue: >> >> https://github.com/pharo-vcs/iceberg/issues/1251 >> >> El 18 jun 2019, a las 9:30, Guillermo Polito <guillermopolito(a)gmail.com> >> escribiÃ³: >> >> Hi Esteban, >> >> It seems like a bug in Iceberg. If you click on debug, youâll see that >> although youâve said the project is in tonel format, itâs trying to use a >> Filetree reader >> >> <PastedGraphic-2.png> >> >> This is due to some missing metadata in the commit (iceberg is relying on >> commit information there and not working copy information). >> >> There is however a simple workaround. If you click in the commit button >> youâll see that Iceberg tries to create and commit the missing files: >> >> <PastedGraphic-3.png> >> >> If you commit those files, then youâll be able to load your packages. >> >> Guille >> >> >> El 18 jun 2019, a las 2:34, Esteban Maringolo <emaringolo(a)gmail.com> >> escribiÃ³: >> >> Hi, >> >> I'm trying to load a package from a Tonel repository[1] that was created >> using SETT[2]. >> >> The structure seems fine, but when I try to load a package, I'm getting >> the message saying that there is no version for the package in the current >> commit (which seems wrong at least to the naked eye). >> >> Eg. >> <image.png> >> >> Any idea of how to fix it? >> >> Regards! >> >> [1] https://github.com/eMaringolo/rbac/tree/master/sources/ >> [2] https://github.com/gemtalk/sett >> >> >> >> Esteban A. Maringolo >> >> >> >>

June 18, 2019

Re: [Pharo-users] Question: anyone using NOCompletion setting?

by Sean P. DeNigris

I use it sometimes. IIRC there was a paper that it was objectively better at finding the "right" thing. Are you thinking of removing it? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 18, 2019