- Pharo-users - lists.pharo.org

Re: [Pharo-users] Which command-line handlers do you use most?

by Sven Van Caekenberghe

> On 9 Jul 2018, at 17:38, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > Hi all, > > I'm starting to port / reimplement existing command line handlers using Clap. There's a dozen, but I wonder which ones are the most relied upon, because it's a good opportunity for refactoring the command line API as a whole and simplifying it or at least making it more orthogonal. > > For instance I discovered there is a "perform" command, which is sort of redundant with the "eval" one. Similarly there are both a "configuration" and a "metacello" handlers which seem to have the same exact purposeâ¦ > > Since Clap can exist besides the current command-line handlers, we can have a deprecation period to minimize breakage and leave time for people to adapt before we kill old command line handlers for real. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet Most used: eval, config, st (default to run script.st) Please make sure to stay as compatible as possible, lots of CI and server deploy/run code depends on it.

July 9, 2018

Re: [Pharo-users] Which command-line handlers do you use most?

by Santiago Bragagnolo

This are great news. Maybe you can extend Pharo launcher as a usage case for implantation! It would be really welcomed and useful. Santiago El lun., 9 de jul. de 2018 17:40, Damien Pollet <damien.pollet(a)gmail.com> escribiÃ³: > Hi all, > > I'm starting to port / reimplement existing command line handlers using > Clap. There's a dozen, but I wonder which ones are the most relied upon, > because it's a good opportunity for refactoring the command line API as a > whole and simplifying it or at least making it more orthogonal. > > For instance I discovered there is a "perform" command, which is sort of > redundant with the "eval" one. Similarly there are both a "configuration" > and a "metacello" handlers which seem to have the same exact purposeâ¦ > > Since Clap can exist besides the current command-line handlers, we can > have a deprecation period to minimize breakage and leave time for people > to adapt before we kill old command line handlers for real. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

July 9, 2018

Which command-line handlers do you use most?

by Damien Pollet

Hi all, I'm starting to port / reimplement existing command line handlers using Clap. There's a dozen, but I wonder which ones are the most relied upon, because it's a good opportunity for refactoring the command line API as a whole and simplifying it or at least making it more orthogonal. For instance I discovered there is a "perform" command, which is sort of redundant with the "eval" one. Similarly there are both a "configuration" and a "metacello" handlers which seem to have the same exact purposeâ¦ Since Clap can exist besides the current command-line handlers, we can have a deprecation period to minimize breakage and leave time for people to adapt before we kill old command line handlers for real. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 9, 2018

Re: [Pharo-users] Changing a BaselineOf... to include one more package

by Guillermo Polito

To give a bit more of insight (and fill some holes in my explanation because I couldn't finish my coffee yet :)), actually, your baseline does not work because in the metacello spec you're saying that 'SmaCC-Reification' resides in Grace's repository, which is wrong I assume. So metacello will try to load that dependency (and fail) and so, it will fail to load Grace-Parser (transitivity...). And now that I think it better, even putting spec package: 'Grace-Parser' with: [ spec requires: {'SmaCC' . 'SmaCC-Reification'. 'Grace-Scope'} ]. Is wrong. - First thing is to see if SmaCC exports SmaCC-Reification by default or in a separate group. - If SmaCC-Reification is downloaded by default, you just need spec package: 'Grace-Parser' with: [ spec requires: {'SmaCC' . 'Grace-Scope'} ]. - If SmaCC-Reification is in a non-default group, you probably want to add spec baseline: 'SmaCC-Reification' with: [ spec repository: 'github://apblack/SmaCC:working'; loads: #( 'NAME-OF-YOUR-REIFICATION-GROUP' ) ]. And then your packages can depend on it. - IF SmaCC-Reification is not in the SmaCC baseline, then, there is nothing you can do, but to add it :) On Mon, Jul 9, 2018 at 9:29 AM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Andrew, > > I'd say you got almost everything right. Let me try to guide you to fix > what's not so well and see if you can make it work. > > On Sun, Jul 8, 2018 at 4:19 PM Andrew P. Black <apblack(a)pdx.edu> wrote: > >> I have a baselineOfGrace that has been working fine for some time: >> >> baseline: spec >> <baseline> >> >> spec for: #'common' do: [ >> spec >> baseline: 'SmaCC' >> with: [ spec repository: 'github://apblack/SmaCC:working' ]. >> spec >> baseline: 'FileDialog' >> with: [ spec repository: 'github://peteruhnak/file-dialog/repository' ]. >> spec package: 'Grace-Scope'. >> spec package: 'Grace-Names' with: [ spec requires: {'Grace-Parser' . >> 'Grace-Scope'} ]. >> spec package: 'Grace-Parser' with: [ >> spec requires: {'SmaCC' . 'Grace-Scope'} ]. >> spec package: 'Grace-HValidator' with: [ spec requires: {'SmaCC' } ]. >> spec package: 'Grace-IDE' with: [ >> spec requires: {'FileDialog' . 'Grace-Compiler'} ]. >> spec package: 'Grace-Compiler' with: [ >> spec requires: {'Grace-Parser' . 'Grace-Names'} ]. >> spec package: 'Grace-Tests' with: [ >> spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-HValidator'} ]. >> spec package: 'Grace-Types' with: [ >> spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope'} ]. >> spec package: 'Grace-TypeTests' with: [ >> spec requires: {'Grace-Tests' . 'Grace-Types' } ]. >> spec package: 'Grace-Ast' with: [ >> spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope' . >> 'Grace-Types'} ]. >> spec package: 'Grace-AstTests' with: [ >> spec requires: {'Grace-Tests' . 'Grace-Ast'} ]. >> ] >> >> >> Now I have added a dependency from the package âGrace-Parserâ on the >> package 'SmaCC-Reificationâ. The latter exists *only* within the branch >> SmaCC called âfglrâ. So I have changed my >> baseline to the following: >> >> baseline: spec >> <baseline> >> >> spec for: #'common' do: [ >> spec >> baseline: 'SmaCC' >> with: [ spec repository: 'github://apblack/SmaCC:fglr' ]. >> >> 1) This is perfect. > >> spec >> baseline: 'FileDialog' >> with: [ spec repository: 'github://peteruhnak/file-dialog/repository' ]. >> spec package: 'Grace-Scope'. >> spec package: 'Grace-Names' with: [ spec requires: {'Grace-Parser' . >> 'Grace-Scope'} ]. >> spec package: 'Grace-Parser' with: [ >> spec requires: {'SmaCC' . 'SmaCC-Reification'. 'Grace-Scope'} ]. >> >> 2) This... It depends: Does the BaselineOfSmaCC export a package/group > with that name? > When you import another project, you should think a baseline as a kind of > black box, where the only things you can import are those declared in the > baseline. If that baseline loads other stuff you don't care. > > In other words, this means that the BaselineOfSmaCC that lives in the > `fglr` branch needs to have a `spec package: 'SmaCC-Reification'` > expression to work. > > >> spec package: 'Grace-HValidator' with: [ spec requires: {'SmaCC' } ]. >> spec package: 'Grace-IDE' with: [ >> spec requires: {'FileDialog' . 'Grace-Compiler'} ]. >> spec package: 'Grace-Compiler' with: [ >> spec requires: {'Grace-Parser' . 'Grace-Names'} ]. >> spec package: 'Grace-Tests' with: [ >> spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-HValidator'} ]. >> spec package: 'Grace-Types' with: [ >> spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope'} ]. >> spec package: 'Grace-TypeTests' with: [ >> spec requires: {'Grace-Tests' . 'Grace-Types' } ]. >> spec package: 'Grace-Ast' with: [ >> spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope' . >> 'Grace-Types'} ]. >> spec package: 'Grace-AstTests' with: [ >> spec requires: {'Grace-Tests' . 'Grace-Ast'} ]. >> spec package: 'SmaCC-Reification'. >> >> 3) And this is wrong :). You don't need to specify external packages like > this. > It's not up to your baseline to load SmaCC stuff. Your baseline describes > things in your grace repository. > It's up to SmaCC's baseline to describe every loadable unit (package, > group...) that you can depend on. > > > So in summary, you should do 1) and 2) in BaselineOfGrace and make sure > that 3) is done in BaselineOfSmacc. > > Keep us posted! > Guille > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

July 9, 2018

12 Jul Pharo TechTalk: Tensorflow

by Marcus Denker

Pharo TechTalk: Tensorflow A regular chat about Pharo. Happens on Discord. The Tech talks are open to both members and non-members! Topic: Machine Learning with TensorFlow and Pharo https://association.pharo.org/event-2973748

July 9, 2018

Re: [Pharo-users] Changing a BaselineOf... to include one more package

by Guillermo Polito

Hi Andrew, I'd say you got almost everything right. Let me try to guide you to fix what's not so well and see if you can make it work. On Sun, Jul 8, 2018 at 4:19 PM Andrew P. Black <apblack(a)pdx.edu> wrote: > I have a baselineOfGrace that has been working fine for some time: > > baseline: spec > <baseline> > > spec for: #'common' do: [ > spec > baseline: 'SmaCC' > with: [ spec repository: 'github://apblack/SmaCC:working' ]. > spec > baseline: 'FileDialog' > with: [ spec repository: 'github://peteruhnak/file-dialog/repository' ]. > spec package: 'Grace-Scope'. > spec package: 'Grace-Names' with: [ spec requires: {'Grace-Parser' . > 'Grace-Scope'} ]. > spec package: 'Grace-Parser' with: [ > spec requires: {'SmaCC' . 'Grace-Scope'} ]. > spec package: 'Grace-HValidator' with: [ spec requires: {'SmaCC' } ]. > spec package: 'Grace-IDE' with: [ > spec requires: {'FileDialog' . 'Grace-Compiler'} ]. > spec package: 'Grace-Compiler' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names'} ]. > spec package: 'Grace-Tests' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-HValidator'} ]. > spec package: 'Grace-Types' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope'} ]. > spec package: 'Grace-TypeTests' with: [ > spec requires: {'Grace-Tests' . 'Grace-Types' } ]. > spec package: 'Grace-Ast' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope' . > 'Grace-Types'} ]. > spec package: 'Grace-AstTests' with: [ > spec requires: {'Grace-Tests' . 'Grace-Ast'} ]. > ] > > > Now I have added a dependency from the package âGrace-Parserâ on the > package 'SmaCC-Reificationâ. The latter exists *only* within the branch > SmaCC called âfglrâ. So I have changed my > baseline to the following: > > baseline: spec > <baseline> > > spec for: #'common' do: [ > spec > baseline: 'SmaCC' > with: [ spec repository: 'github://apblack/SmaCC:fglr' ]. > > 1) This is perfect. > spec > baseline: 'FileDialog' > with: [ spec repository: 'github://peteruhnak/file-dialog/repository' ]. > spec package: 'Grace-Scope'. > spec package: 'Grace-Names' with: [ spec requires: {'Grace-Parser' . > 'Grace-Scope'} ]. > spec package: 'Grace-Parser' with: [ > spec requires: {'SmaCC' . 'SmaCC-Reification'. 'Grace-Scope'} ]. > > 2) This... It depends: Does the BaselineOfSmaCC export a package/group with that name? When you import another project, you should think a baseline as a kind of black box, where the only things you can import are those declared in the baseline. If that baseline loads other stuff you don't care. In other words, this means that the BaselineOfSmaCC that lives in the `fglr` branch needs to have a `spec package: 'SmaCC-Reification'` expression to work. > spec package: 'Grace-HValidator' with: [ spec requires: {'SmaCC' } ]. > spec package: 'Grace-IDE' with: [ > spec requires: {'FileDialog' . 'Grace-Compiler'} ]. > spec package: 'Grace-Compiler' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names'} ]. > spec package: 'Grace-Tests' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-HValidator'} ]. > spec package: 'Grace-Types' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope'} ]. > spec package: 'Grace-TypeTests' with: [ > spec requires: {'Grace-Tests' . 'Grace-Types' } ]. > spec package: 'Grace-Ast' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope' . > 'Grace-Types'} ]. > spec package: 'Grace-AstTests' with: [ > spec requires: {'Grace-Tests' . 'Grace-Ast'} ]. > spec package: 'SmaCC-Reification'. > > 3) And this is wrong :). You don't need to specify external packages like this. It's not up to your baseline to load SmaCC stuff. Your baseline describes things in your grace repository. It's up to SmaCC's baseline to describe every loadable unit (package, group...) that you can depend on. So in summary, you should do 1) and 2) in BaselineOfGrace and make sure that 3) is done in BaselineOfSmacc. Keep us posted! Guille

July 9, 2018

Re: [Pharo-users] Changing a BaselineOf... to include one more package

by Paul DeBruicker

Seems like its not looking in your iceberg directory/subdirectories for the SmaCC-Reification package. Just the package-cache and on github. Did you try adding a SmaCC-Reification specific repository declaration yet to your baseline? e.g. spec package: 'SmaCC-Reification' with:[ spec repository:'/my/full/path/iceberg/apblack/SmaCC'] I'm definitely in the "fiddle around with stuff until it works" level of competency on Baselines so there may be a better (correct :) ) way. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 9, 2018

Changing a BaselineOf... to include one more package

by Andrew P. Black

I have a baselineOfGrace that has been working fine for some time: > baseline: spec > <baseline> > > spec for: #'common' do: [ > spec > baseline: 'SmaCC' > with: [ spec repository: 'github://apblack/SmaCC:working' ]. > spec > baseline: 'FileDialog' > with: [ spec repository: 'github://peteruhnak/file-dialog/repository' ]. > spec package: 'Grace-Scope'. > spec package: 'Grace-Names' with: [ spec requires: {'Grace-Parser' . 'Grace-Scope'} ]. > spec package: 'Grace-Parser' with: [ > spec requires: {'SmaCC' . 'Grace-Scope'} ]. > spec package: 'Grace-HValidator' with: [ spec requires: {'SmaCC' } ]. > spec package: 'Grace-IDE' with: [ > spec requires: {'FileDialog' . 'Grace-Compiler'} ]. > spec package: 'Grace-Compiler' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names'} ]. > spec package: 'Grace-Tests' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-HValidator'} ]. > spec package: 'Grace-Types' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope'} ]. > spec package: 'Grace-TypeTests' with: [ > spec requires: {'Grace-Tests' . 'Grace-Types' } ]. > spec package: 'Grace-Ast' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope' . 'Grace-Types'} ]. > spec package: 'Grace-AstTests' with: [ > spec requires: {'Grace-Tests' . 'Grace-Ast'} ]. > ] Now I have added a dependency from the package âGrace-Parserâ on the package 'SmaCC-Reificationâ. The latter exists only within the branch SmaCC called âfglrâ. So I have changed my baseline to the following: > baseline: spec > <baseline> > > spec for: #'common' do: [ > spec > baseline: 'SmaCC' > with: [ spec repository: 'github://apblack/SmaCC:fglr' ]. > spec > baseline: 'FileDialog' > with: [ spec repository: 'github://peteruhnak/file-dialog/repository' ]. > spec package: 'Grace-Scope'. > spec package: 'Grace-Names' with: [ spec requires: {'Grace-Parser' . 'Grace-Scope'} ]. > spec package: 'Grace-Parser' with: [ > spec requires: {'SmaCC' . 'SmaCC-Reification'. 'Grace-Scope'} ]. > spec package: 'Grace-HValidator' with: [ spec requires: {'SmaCC' } ]. > spec package: 'Grace-IDE' with: [ > spec requires: {'FileDialog' . 'Grace-Compiler'} ]. > spec package: 'Grace-Compiler' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names'} ]. > spec package: 'Grace-Tests' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-HValidator'} ]. > spec package: 'Grace-Types' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope'} ]. > spec package: 'Grace-TypeTests' with: [ > spec requires: {'Grace-Tests' . 'Grace-Types' } ]. > spec package: 'Grace-Ast' with: [ > spec requires: {'Grace-Parser' . 'Grace-Names' . 'Grace-Scope' . 'Grace-Types'} ]. > spec package: 'Grace-AstTests' with: [ > spec requires: {'Grace-Tests' . 'Grace-Ast'} ]. > spec package: 'SmaCC-Reification'. > ] Notice that I have changed the branch of SmaCC, added the dependency to âGrace-Parserâ, and added a spec package" statement for âSmaCC-Reificationâ This does not work. I get a MetacelloPackageSpecResolutionError: > 'Could not resolve: SmaCC-Reification [SmaCC-Reification] in /Users/black/Development/Pharo/images/Pharo 7.0 SmallGrace 0.34/pharo-local/package-cache https://github.com/apblack/GraceInPharo.git[master]' <https://github.com/apblack/GraceInPharo.git%5Bmaster%5D'> This is not surprising, because there is nothing in that package-cache. I have configured iceberg to use a shared directory (~/iceberg), and SmaCC has been cloned there â including the 'SmaCC-Reificationâ package > Sylvanite: ~/iceberg/apblack/SmaCC$ ls -d *Reif* > SmaCC-Reification.package > Sylvanite: ~/iceberg/apblack/SmaCC$ What is going wrong, and how can I get this configured to work correctly? Thanks to all! Andrew

July 8, 2018

Re: [Pharo-users] Pharo 7 and shortcuts

by Tim Mackinnon

I find the inconsistency the worst problem, sometimes cmd-m sometimes cmd-b,m and sometimes both work. I can handle double keys for lesser used items, but some really common code editing things need a single key. I would actually like more shortcuts available for code refactoring like inlining etc - and I have a few others I want to add (which are now possible with a contribution I made to P7 that uses the ast to find the best nodes close to you cursor) like widen selection, jump to next code element etc. (Eg catch up with intelliJ). I guess there are just so many things to clean up, it can be Overwhelming, still, bit by bit. Tim Sent from my iPhone > On 7 Jul 2018, at 19:36, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Shortcuts have long been a thorn for Pharo, the lack of global state and the fact that are hard coded. Colors and Themes had the same issue and it was the effort Esteban who wanted to bring the dark theme that really changed this. I suspect like Theme these are legacy Squeak stuff that are not easy to fix. > > Ideally shortcuts should be fully customisable with preset support accessible from Pharo user settings. This way for example a vim user could implement his own set of keys after his favorite editor. It would be nice if that became a target for Pharo 7 or at least Pharo 8. No Pharo tool should be allowed to manage its own shortcuts , not even third party tools. > > > >> On Sat, Jul 7, 2018 at 6:18 PM Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> > Am 07.07.2018 um 17:08 schrieb Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: >> > >> >> Le 07/07/2018 Ã 16:17, Ben Coman a Ã©crit : >> >> Any seeming agreement may just have been the nay-sayers falling silent since >> >> there seemed little chance of having it changed when it came as a >> >> done-deal with Nautilus. >> >> Personally I tried to conform to using the double-sequence-shortcuts >> >> but could never get over the cumbersome feel of it, >> >> to the point where in Nautlius I actually stopped using shortcuts and >> >> reverted to using context menus. >> >> >> >> I guess lovers of the double-sequence-shortcuts are now in that boat. >> >> I'm not sure there was much discussion around Calypso using >> >> single-key-shortcuts. >> >> But I'm personally very happy with this behaviour change introduced by >> >> Nautlius was reverted. >> >> I'm glad to using shortcuts in the System Browser again. >> >> >> > For my part I'm not because before I could delete/rename/add a >> > package/class/protocol/method without the mouse but now it became much >> > harder with simple key shortcut since it works only on the focused pane. >> > >> > But I guess this kind of things depend on everyone. >> > >> > Maybe it could be good to be able to customize it via settings. >> > >> I donât understand anyway why keyboard shortcuts are dependent on a tool. Shouldnât there be an abstraction mapping between action and shortcut? >> >> Norbert >> >> cheers -ben >> >> >> > >> > >> > -- >> > Cyril Ferlicot >> > https://ferlicot.fr >> > >> >>

July 8, 2018

Re: [Pharo-users] Pharo 7 and shortcuts

by Esteban Lorenzano

Hi, > On 7 Jul 2018, at 17:18, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 07.07.2018 um 17:08 schrieb Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: >> >>> Le 07/07/2018 Ã 16:17, Ben Coman a Ã©crit : >>> Any seeming agreement may just have been the nay-sayers falling silent since >>> there seemed little chance of having it changed when it came as a >>> done-deal with Nautilus. >>> Personally I tried to conform to using the double-sequence-shortcuts >>> but could never get over the cumbersome feel of it, >>> to the point where in Nautlius I actually stopped using shortcuts and >>> reverted to using context menus. >>> >>> I guess lovers of the double-sequence-shortcuts are now in that boat. >>> I'm not sure there was much discussion around Calypso using >>> single-key-shortcuts. >>> But I'm personally very happy with this behaviour change introduced by >>> Nautlius was reverted. >>> I'm glad to using shortcuts in the System Browser again. >>> >> For my part I'm not because before I could delete/rename/add a >> package/class/protocol/method without the mouse Yes, but it was not working properly nor everywhere. >> but now it became much >> harder with simple key shortcut since it works only on the focused pane. Now in calypso you have cmd+/ who will show you an spotter with all options. You can then select the command you look for. I do not use mouse when using calypso thanks to this addition. In general, while it requires some time to get used to it (and some options needs renames, etc. to make a better experience) is a lot more powerful than shortcuts (because letâs be realistic there will be always more options than shortcuts available), and makes commands easier to find/learn. Another thing is that we still need to find which commands deserve a shortcut anyway :) >> >> But I guess this kind of things depend on everyone. >> >> Maybe it could be good to be able to customize it via settings. >> > I donât understand anyway why keyboard shortcuts are dependent on a tool. Shouldnât there be an abstraction mapping between action and shortcut? Because tools as most of the system was badly designed, without a central vision and without and it evolved (mutated?) without any control. This is changing, but as always iterative development means we cannot just throw everything and start over (something I dream to do, but this will also bring new problems soâ¦ :P) Cheers, Esteban > > Norbert >>> cheers -ben >>> >> >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr <https://ferlicot.fr/>

July 8, 2018