July 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Logging system

by Miguel Campusano

thanks! On Tue, Jul 10, 2018 at 3:20 AM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi Miguel, > > there is beacon for logging https://github.com/pharo-project/pharo-beacon > > you can also consider pharo-sentry > https://github.com/peteruhnak/pharo-sentry (note that sentry can be > self-hosted) > > Peter > > On Mon, Jul 9, 2018 at 10:30 PM, Miguel Campusano < > m.campusano.araya(a)gmail.com> wrote: > >> Hello guys, >> >> I want to capture the logs of a Pharo program to visualize them, but I do >> not find something like Python to log stuffs with more info than the string >> itself (such as severity or source of the log) ( >> https://docs.python.org/2/howto/logging.html) >> >> Is there a standard tool for logging in Pharo already in use? >> >> Bests, >> Miguel >> > >

July 10, 2018

Re: [Pharo-users] Logging system

by Peter UhnÃ¡k

Hi Miguel, there is beacon for logging https://github.com/pharo-project/pharo-beacon you can also consider pharo-sentry https://github.com/peteruhnak/pharo-sentry (note that sentry can be self-hosted) Peter On Mon, Jul 9, 2018 at 10:30 PM, Miguel Campusano < m.campusano.araya(a)gmail.com> wrote: > Hello guys, > > I want to capture the logs of a Pharo program to visualize them, but I do > not find something like Python to log stuffs with more info than the string > itself (such as severity or source of the log) (https://docs.python.org/2/ > howto/logging.html). > > Is there a standard tool for logging in Pharo already in use? > > Bests, > Miguel >

July 10, 2018

Logging system

by Miguel Campusano

Hello guys, I want to capture the logs of a Pharo program to visualize them, but I do not find something like Python to log stuffs with more info than the string itself (such as severity or source of the log) ( https://docs.python.org/2/howto/logging.html) Is there a standard tool for logging in Pharo already in use? Bests, Miguel

July 9, 2018

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

Re: [Pharo-users] [Moose-dev] Re: Roassal2 in Pharo 6.1 (Win) 137 tests fails

by Alexandre Bergel

Wow!!!! Glad to hear everything works now... Alexandre > On Jul 7, 2018, at 7:01 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Hi Peter, > > I don't know why but restarted the PC and it worked! On a new image > and Roassal2 installation. > Thank you, > > Cheers, > > HernÃ¡n > > 2018-07-06 12:52 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>> May be Roassal2 is broken on Windows? >> >> Sometimes Pharo on Windows decides that it will not load external library. >> >> Try to restart your PC and see if it persists. >> >> Peter >> >> On Fri, Jul 6, 2018 at 5:38 PM, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >>> >>> In a clean Pharo 6.1 (Windows 8) I loaded Roassal2 with the following >>> spec in a baseline: >>> >>> spec >>> project: 'Roassal2' >>> with: [ >>> spec >>> className: #ConfigurationOfRoassal2; >>> versionString: #stable; >>> repository: >>> 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2' ]. >>> >>> But many Trachel tests fails because of "External module not found" >>> error (Screenshots attached). >>> May be Roassal2 is broken on Windows? >>> >>> I tried loading Roassal2 from the Catalog browser and the same 137 tests >>> fails. >>> >>> Any idea what could be missing? >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >

July 8, 2018

Re: [Pharo-users] Pharo 7 and shortcuts

by Dimitris Chloupis

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 7, 2018

Re: [Pharo-users] Pharo 7 and shortcuts

by Norbert Hartl

> 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 7, 2018

Re: [Pharo-users] Pharo 7 and shortcuts

by Cyril Ferlicot D.

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. > cheers -ben > -- Cyril Ferlicot https://ferlicot.fr

July 7, 2018

Re: [Pharo-users] Pharo 7 and shortcuts

by Norbert Hartl

> Am 07.07.2018 um 16:17 schrieb Ben Coman <btc(a)openinworld.com>: > >> On 7 July 2018 at 20:35, Norbert Hartl <norbert(a)hartl.name> wrote: >> Maybe I missed an important discussion but as Iâm trying pharo7 now and I wonder about the keyboard shortcuts. >> >> Wasnât the old agreement moving to the multiple keys? So browsing senders with CMD-bn instead of the old CMD-n? > > 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. > I cannot say I liked the idea of having double key sequences. You see Iâm using vi since 28 years and never emacs for exactly that reason. The important constraint for this seems to be number of shortcuts you need. I thought there is going to be more. So I convinced myself not to be sad having double key sequences. Iâm more or less glad about the revert, too. Best is that now the keyboard shortcuts are unified again ð Norbert > cheers -ben >

July 7, 2018

Re: [Pharo-users] Pharo 7 and shortcuts

by Ben Coman

On 7 July 2018 at 20:35, Norbert Hartl <norbert(a)hartl.name> wrote: > Maybe I missed an important discussion but as Iâm trying pharo7 now and I wonder about the keyboard shortcuts. > > Wasnât the old agreement moving to the multiple keys? So browsing senders with CMD-bn instead of the old CMD-n? 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. cheers -ben

July 7, 2018

Pharo 7 and shortcuts

by Norbert Hartl

Maybe I missed an important discussion but as Iâm trying pharo7 now and I wonder about the keyboard shortcuts. Wasnât the old agreement moving to the multiple keys? So browsing senders with CMD-bn instead of the old CMD-n? What I find really confusing is that the shortcut keys in the menu are uppercase but the shortcut is lowercase. This does not look like an improvement to me. Any hints are highly appreciated. Norbert

July 7, 2018

Re: [Pharo-users] Pharo stable version with git support

by Dimitris Chloupis

I have used Pharo with Git, for versioning source code and variable assets , images and audio files using filetree and the git client of my choosing. Git is super flexible , especially if you combine it with make files that I also use to build my own custom pharo images together with pharo startup scripts (the operate on the startup of a pharo image to check for dependencies and incompatibilities with the image and then compensate for any such problem). Iceberg is great to make things easier and keep everything organized from inside the image but I cannot stress enough that Iceberg SHOULD NOT be used to avoid learning Git because in the end Git is extremely powerful , although sometimes not that elegant, its not easy to replace the existing super powerful gui clients that exist for it and are used by millions of developers worldwide. If you are on windows I recommend tortoiseGit cause integrates elegantly with windows explorer and is very powerful. For MacOS I recommend GitUp it has its own Undo functionality to quickly recover from accidental mistakes. All the above of course can be used together with Iceberg and there is little reason for them to conflict because in the end , everything has to follow the Git workflow and rules. I have also tested these workflow for Gitlab (an open source alternative to Github and probably the second most popular online repo website after Github) and it works without any issues. The workflows is practically the same. On Sat, Jul 7, 2018 at 11:54 AM dario.trussardi(a)tiscali.it < dario.trussardi(a)tiscali.it> wrote: > > Ciao, > thanks..... > > Hi Dario, > >> i'm interested to port all my code to new Pharo version that >>> manage git support. >>> >>> I found information in pharo.org news, it talk of Pharo 6.1. >>> >>> But it run only on macOS 64bits o i can run it on Linux Ubuntu >>> 16.04 LTS System? >>> >>> New information - update about it? >>> >>> Pharo 6.1 runs on 64bits, except for windows. > > OK, i have setup a Pharo 6.1 image with Iceberg update as >> https://github.com/pharo-vcs/iceberg >> >> Now i'm "new" to git support ...... >> > > Take into account that this is highly necessary. The version of Iceberg in > Pharo 6.1 is just an old preview version. > While Pharo works on 64 bits, Iceberg itself was not at that time, so > upgrading is necessary to have that support. > > > 1) OK, i have do the upgrade to: iceberg:dev-0.7 > > "load iceberg"Metacello new > baseline: 'Iceberg'; > repository: 'github://pharo-vcs/iceberg:v1.?'; > onWarningLog; > load."Re-initialize libgit2" > (Smalltalk at: #LGitLibrary) initialize. > > But it's the last version ? > > How i can understand what is the right version to update ? > > 2) for error i delete the......shared/pharo-local/iceber/git/iceberg > directory. > > i need to setup a new pharo environment ? > > > >> I understand ??? that Iceberg has some limitations, it is not complete >> ......???? >> > > Iceberg already has pretty good support to manage pharo code. > > You'll find however that it does not manage (yet) non-pharo files. That > is, if your repository has scripts, pictures or such kind of resources, you > will have for now to edit and commit them from the outside (command line or > another tool). > > The reasons for that are so far explained in here > https://github.com/pharo-vcs/iceberg/blob/master/docs/The-Working-Copy(ies)… > > I would be grateful if someone explained to me how operatively I can >> manage everything ... up to where I can do with Iceberg directly from Pharo >> and how to operate from the shell on the git repository. >> >> Documentation in this sense? >> > > Well, you have iceberg's wiki > > https://github.com/pharo-vcs/iceberg/wiki > > We are moving the documentation (hey, bit thanks to Tim Mackinon here!) > to the main repository so people can easy contribute to it. > See https://github.com/pharo-vcs/iceberg/tree/master/docs. > What is left is a sync mechanism between that directory and the wiki > repository. > >> >> My goal is to setup a environment for integrate Pharo development with >> Gemstone GLASS Tode git support..... >> >> Does anyone have experience in this sense? >> > > That's not me, I hope you'll find somebody. But if you have any questions > regarding Iceberg, don't hesitate to ask them! > > > You intend at this support ? > > Thanks, > > Dario > >

July 7, 2018

Re: [Pharo-users] Pharo stable version with git support

by dario.trussardi＠tiscali.it

Ciao, thanks..... > Hi Dario, >> i'm interested to port all my code to new Pharo version that manage git support. >> >> I found information in pharo.org news, it talk of Pharo 6.1. >> >> But it run only on macOS 64bits o i can run it on Linux Ubuntu 16.04 LTS System? >> >> New information - update about it? >> > > Pharo 6.1 runs on 64bits, except for windows. > > OK, i have setup a Pharo 6.1 image with Iceberg update as https://github.com/pharo-vcs/iceberg > > Now i'm "new" to git support ...... > > Take into account that this is highly necessary. The version of Iceberg in Pharo 6.1 is just an old preview version. > While Pharo works on 64 bits, Iceberg itself was not at that time, so upgrading is necessary to have that support. 1) OK, i have do the upgrade to: iceberg:dev-0.7 "load iceberg" Metacello new baseline: 'Iceberg'; repository: 'github://pharo-vcs/iceberg:v1.?'; onWarningLog; load. "Re-initialize libgit2" (Smalltalk at: #LGitLibrary) initialize. But it's the last version ? How i can understand what is the right version to update ? 2) for error i delete the......shared/pharo-local/iceber/git/iceberg directory. i need to setup a new pharo environment ? > > > I understand ??? that Iceberg has some limitations, it is not complete ......???? > > Iceberg already has pretty good support to manage pharo code. > > You'll find however that it does not manage (yet) non-pharo files. That is, if your repository has scripts, pictures or such kind of resources, you will have for now to edit and commit them from the outside (command line or another tool). > > The reasons for that are so far explained in here https://github.com/pharo-vcs/iceberg/blob/master/docs/The-Working-Copy(ies)… > > I would be grateful if someone explained to me how operatively I can manage everything ... > > up to where I can do with Iceberg directly from Pharo and how to operate from the shell on the git repository. > > Documentation in this sense? > > Well, you have iceberg's wiki > > https://github.com/pharo-vcs/iceberg/wiki > > We are moving the documentation (hey, bit thanks to Tim Mackinon here!) to the main repository so people can easy contribute to it. > See https://github.com/pharo-vcs/iceberg/tree/master/docs. > What is left is a sync mechanism between that directory and the wiki repository. > > My goal is to setup a environment for integrate Pharo development with Gemstone GLASS Tode git support..... > > Does anyone have experience in this sense? > > That's not me, I hope you'll find somebody. But if you have any questions regarding Iceberg, don't hesitate to ask them! You intend at this support ? Thanks, Dario

July 7, 2018

Re: [Pharo-users] Pharo stable version with git support

by Guillermo Polito

Hi Dario, > i'm interested to port all my code to new Pharo version that >> manage git support. >> >> I found information in pharo.org news, it talk of Pharo 6.1. >> >> But it run only on macOS 64bits o i can run it on Linux Ubuntu >> 16.04 LTS System? >> >> New information - update about it? >> >> Pharo 6.1 runs on 64bits, except for windows. OK, i have setup a Pharo 6.1 image with Iceberg update as > https://github.com/pharo-vcs/iceberg > > Now i'm "new" to git support ...... > Take into account that this is highly necessary. The version of Iceberg in Pharo 6.1 is just an old preview version. While Pharo works on 64 bits, Iceberg itself was not at that time, so upgrading is necessary to have that support. > I understand ??? that Iceberg has some limitations, it is not complete > ......???? > Iceberg already has pretty good support to manage pharo code. You'll find however that it does not manage (yet) non-pharo files. That is, if your repository has scripts, pictures or such kind of resources, you will have for now to edit and commit them from the outside (command line or another tool). The reasons for that are so far explained in here https://github.com/pharo-vcs/iceberg/blob/master/docs/The-Working-Copy(ies)… I would be grateful if someone explained to me how operatively I can manage > everything ... up to where I can do with Iceberg directly from Pharo and > how to operate from the shell on the git repository. > > Documentation in this sense? > Well, you have iceberg's wiki https://github.com/pharo-vcs/iceberg/wiki We are moving the documentation (hey, bit thanks to Tim Mackinon here!) to the main repository so people can easy contribute to it. See https://github.com/pharo-vcs/iceberg/tree/master/docs. What is left is a sync mechanism between that directory and the wiki repository. > > My goal is to setup a environment for integrate Pharo development with > Gemstone GLASS Tode git support..... > > Does anyone have experience in this sense? > That's not me, I hope you'll find somebody. But if you have any questions regarding Iceberg, don't hesitate to ask them!

July 7, 2018

Re: [Pharo-users] [Moose-dev] Re: Roassal2 in Pharo 6.1 (Win) 137 tests fails

by HernÃ¡n Morales Durand

Hi Peter, I don't know why but restarted the PC and it worked! On a new image and Roassal2 installation. Thank you, Cheers, HernÃ¡n 2018-07-06 12:52 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> May be Roassal2 is broken on Windows? > > Sometimes Pharo on Windows decides that it will not load external library. > > Try to restart your PC and see if it persists. > > Peter > > On Fri, Jul 6, 2018 at 5:38 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> >> In a clean Pharo 6.1 (Windows 8) I loaded Roassal2 with the following >> spec in a baseline: >> >> spec >> project: 'Roassal2' >> with: [ >> spec >> className: #ConfigurationOfRoassal2; >> versionString: #stable; >> repository: >> 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2' ]. >> >> But many Trachel tests fails because of "External module not found" >> error (Screenshots attached). >> May be Roassal2 is broken on Windows? >> >> I tried loading Roassal2 from the Catalog browser and the same 137 tests >> fails. >> >> Any idea what could be missing? >> >> Cheers, >> >> HernÃ¡n >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

July 7, 2018

Re: [Pharo-users] [Moose-dev] Re: Roassal2 in Pharo 6.1 (Win) 137 tests fails

by HernÃ¡n Morales Durand

Hi Alex, I used the VM which is provided by the zeroconf, i.e.: wget -O- https://get.pharo.org | bash This VM is Cog Spur VM 5.0 (release) from May 9 2018. gcc 6.4.0 Could happen that loading a library on Windows sometimes fails? It would be nice to have the path or additional information on the loading error. Cheers, HernÃ¡n 2018-07-06 13:55 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Dear Hernan, > > Likely that you use a VM that does not have the Cairo library. Can you try > updating your VM? > > Cheers > Alexandre > > http://bergel.eu > > Le 6 juil. 2018 Ã 18:38, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> a > Ã©crit : > > In a clean Pharo 6.1 (Windows 8) I loaded Roassal2 with the following > spec in a baseline: > > spec > project: 'Roassal2' > with: [ > spec > className: #ConfigurationOfRoassal2; > versionString: #stable; > repository: > 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2' ]. > > But many Trachel tests fails because of "External module not found" > error (Screenshots attached). > May be Roassal2 is broken on Windows? > > I tried loading Roassal2 from the Catalog browser and the same 137 tests > fails. > > Any idea what could be missing? > > Cheers, > > HernÃ¡n > > <Test Runner.png> > > <Error - External module not found.png> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

July 7, 2018