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

Fwd: Tonel sourceDir

by Ben Coman

Okay, that was 13 hours ago. Once again... (CCing Esteban & Guille. Can you guys let me know if its at least getting out) ---------- Forwarded message --------- From: Ben Coman <btc(a)openinworld.com> Date: Mon, 10 Dec 2018 at 06:18 Subject: Tonel sourceDir To: Pharo Development List <pharo-dev(a)lists.pharo.org> This did make it through the mail list in 8 hours, so mabe the double arrow in the subject line confused things. Trying again... ---------- Forwarded message --------- From: Ben Coman <btc(a)openinworld.com> Date: Sun, 9 Dec 2018 at 23:05 Subject: Tonel>>sourceDir To: Pharo Development List <pharo-dev(a)lists.pharo.org> For Exercism we are using Tonel in Pharo 6.1. We are getting an error "Instance of TonelWriter did not understand #sourceDir:" but the same code works fine on Pharo 7. The 6.1 image had been updated to latest Iceberg per https://github.com/pharo-vcs/iceberg#for-pharo-61, so I used ICeberg to updated to latest "master" of pharo-vcs/tonel but no avail. In Pharo 7 I see TonelWriter>>sourceDir in protocol "accessing" but if I search for "sourceDir" in the pharo-vcs/tonel repo it doesn't find it... https://github.com/pharo-vcs/tonel/search?q=sourcedir&unscoped_q=sourcedir I'm having trouble understanding where the #sourceDir method comes from in Pharo 7. Which repo/branch can I load that from into another system? cheers -ben

Dec. 10, 2018

LibC system pops up a CMD.exe window in Windows 10 (Pharo 6.1)

by Christopher Fuhrman

Hello, My Git data mining API in Pharo 6.1 uses "LibC uniqueInstance system: 'some commands'" which has an annoying side effect of popping up a window (which steals the GUI focus in Windows 10). Maybe it's the same on MacOS and Linux? As such, I can't use my Windows PC to do anything else when the mining process is running (it can take several minutes). I'm not able to use Pharo's OSProcess or OSSubprocess because they don't support Windows (yet?). I tried creating a separate Windows Desktop (feature of Windows 10), but the CMD.EXE window manages to pop up there, too - almost seems like a windows bug. Does anyone know of a way to have the LibC window not pop up? Cheers, Christopher

Dec. 10, 2018

Re: [Pharo-dev] periodic auto actions on bug tracker

by Marcus Denker

> On 9 Dec 2018, at 01:50, Ben Coman <btc(a)openinworld.com> wrote: > > I support the auto-closing of old tickets to avoid bug bankruptcy. Sometimes things seem more important at the time and when my own tickets come back around I get to be more analytical about the effort/reward balance. > > It would be useful to expand this a bit to have a quarterly mail out saying something like "Is this issue still important to you? Try socializing it on the pharo-dev mail list. Issues going twelve months without interaction will be auto-closed". Then its not a bad surprise to new users when their ticket is auto-closed. > Yes, that is a good idea. I will add it to the things to do for the issue tracker / integration related scripts. Marcus

Dec. 10, 2018

Esteban's ChangeLog week of 3 December 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 3 December 2018 to 9 December 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=3/12/2018&to=9/12/2018 ChangeLog ========= 6 December 2018: ---------------- * I made a small [PR](https://github.com/pharo-ide/Calypso/pull/375) on Calypso to better expose the contextual spotter that helps to find available Calypso commands. 5 December 2018: ---------------- * Ok, finally I finished next stop on automation of releases, which made us to change the default development branch (to "Pharo7.0" for the moment). This will allow us to keep different active "development" branches. One thing I would like to achieve eventually is to keep: * A current development version (it will be Pharo8.0 soon). * A maintained stable version (Pharo7.0 and potential Pharo7.1, etc.). * A Long term support (LTS) version that will continue incorporating critic systems. So well, this are the steps to arrive there :) cheers! Esteban

Dec. 10, 2018

Tonel sourceDir

by Ben Coman

This did make it through the mail list in 8 hours, so mabe the double arrow in the subject line confused things. Trying again... ---------- Forwarded message --------- From: Ben Coman <btc(a)openinworld.com> Date: Sun, 9 Dec 2018 at 23:05 Subject: Tonel>>sourceDir To: Pharo Development List <pharo-dev(a)lists.pharo.org> For Exercism we are using Tonel in Pharo 6.1. We are getting an error "Instance of TonelWriter did not understand #sourceDir:" but the same code works fine on Pharo 7. The 6.1 image had been updated to latest Iceberg per https://github.com/pharo-vcs/iceberg#for-pharo-61, so I used ICeberg to updated to latest "master" of pharo-vcs/tonel but no avail. In Pharo 7 I see TonelWriter>>sourceDir in protocol "accessing" but if I search for "sourceDir" in the pharo-vcs/tonel repo it doesn't find it... https://github.com/pharo-vcs/tonel/search?q=sourcedir&unscoped_q=sourcedir I'm having trouble understanding where the #sourceDir method comes from in Pharo 7. Which repo/branch can I load that from into another system? cheers -ben

Dec. 9, 2018

Re: [Pharo-dev] Multiline method definition in Tonel

by Peter Uhnak

That's just whitespace... or more specifically any of these are fine (TonelParser>>extractSelector:) ``` separators := { Character space. Character tab. Character lf. Character newPage. Character cr. $: "not me though"}. ``` You can also try to parse it directly and see the result: ``` def := 'Class { #name : #Whatever, #superclass : #Object, #category : ''Wherever'' } { #category : #protocol } Whatever >> testWith: arg1 with: arg2 with: arg3 [ ^ 42 ] '. TonelParser parseStream: def readStream. ``` Note that exporting it will result in a "normalized" format, so if you keep it in git you will see a change (this also applies to the ordering of methods and some optional stuff) Peter On Fri, Dec 7, 2018 at 5:57 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys, > > I was reading the Tonel spec here [1] but it is not clear to me the case > of the multiline method definitions. Are those allowed or not? Say I have > a method like this: > > testWith: arg1 > with: arg2 > with: arg3 > > ^ 42 > > Is that valid as Tonel format? Or tonel expects to have method definition > in a one liner like: > > testWith: arg1 with: arg2 with: arg3 > > ^ 42 > > > Thanks in advance, > > > [1] https://github.com/pharo-vcs/tonel > > -- > Mariano > https://twitter.com/MartinezPeck > http://marianopeck.wordpress.com >

Dec. 9, 2018

Tonel>>sourceDir

by Ben Coman

For Exercism we are using Tonel in Pharo 6.1. We are getting an error "Instance of TonelWriter did not understand #sourceDir:" but the same code works fine on Pharo 7. The 6.1 image had been updated to latest Iceberg per https://github.com/pharo-vcs/iceberg#for-pharo-61, so I used ICeberg to updated to latest "master" of pharo-vcs/tonel but no avail. In Pharo 7 I see TonelWriter>>sourceDir in protocol "accessing" but if I search for "sourceDir" in the pharo-vcs/tonel repo it doesn't find it... https://github.com/pharo-vcs/tonel/search?q=sourcedir&unscoped_q=sourcedir I'm having trouble understanding where the #sourceDir method comes from in Pharo 7. Which repo/branch can I load that from into another system? cheers -ben

Dec. 9, 2018

Re: [Pharo-dev] Playground "remote publish" feedback from discord

by Ben Coman

On Sun, 9 Dec 2018 at 18:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 8 Dec 2018, at 17:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Maybe an additional menu item somewhere ? > > Or a little bit more API. > > Right now with the standard GT infrastructure in Pharo 7 (and Pharo 6.1 > also I guess), you can do > > GTPlayground openOn: (GTPlayPage loadFromPublishUrl: ' > http://ws.stfx.eu/1WS4U'). > > We could add one of the following > > GTPlayground loadFromPublishUrl: 'http://ws.stfx.eu/1WS4U'. "keeps the > same selector" > GTPlayground openPublishUrl: 'http://ws.stfx.eu/1WS4U'. "shorter, more > in line with the opening action" > GTPlayground openUrl: 'http://ws.stfx.eu/1WS4U'. "the original on > ZnWorkspace, shortest" > The last is easiest to remember - composed of just two words rather than three or four.. > > If we agree, I can change the default instructions on the web page as seen > in a browser. > > There is little point in wanting to keep the ZnWorkspace code, as it is no > longer needed. > okay. cheers -ben

Dec. 9, 2018

Re: [Pharo-dev] Calypso equivalent <nautilusGlobalPackageMenu>

by Denis Kudriashov

Hi Ben. All Calypso commands are implemented with Commander. Look for example at remove package command. The menu item is declared by SycRemovePackageCommand class>>#fullBrowserMenuActivation. Doc for Commander https://github.com/SquareBracketAssociates/Booklet-Infrastructure (with link to pdf). Ð²Ñ, 9 Ð´ÐµÐº. 2018 Ð³. Ð² 01:50, Ben Coman <btc(a)openinworld.com>: > What is the Calypso equivalent of <nautilusGlobalPackageMenu> ? > I need to add an extra menu item to the Packages context menu. > > cheers -ben >

Dec. 9, 2018

Re: [Pharo-dev] Playground "remote publish" feedback from discord

by Sven Van Caekenberghe

> On 8 Dec 2018, at 17:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Maybe an additional menu item somewhere ? Or a little bit more API. Right now with the standard GT infrastructure in Pharo 7 (and Pharo 6.1 also I guess), you can do GTPlayground openOn: (GTPlayPage loadFromPublishUrl: 'http://ws.stfx.eu/1WS4U'). We could add one of the following GTPlayground loadFromPublishUrl: 'http://ws.stfx.eu/1WS4U'. "keeps the same selector" GTPlayground openPublishUrl: 'http://ws.stfx.eu/1WS4U'. "shorter, more in line with the opening action" GTPlayground openUrl: 'http://ws.stfx.eu/1WS4U'. "the original on ZnWorkspace, shortest" If we agree, I can change the default instructions on the web page as seen in a browser. There is little point in wanting to keep the ZnWorkspace code, as it is no longer needed.

Dec. 9, 2018