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

Re: [Pharo-dev] IMPORTANT: Proposal to create a github team for Voyage and MongoTalk

by Stephan Eggermont

On 08/06/16 11:54, Esteban Lorenzano wrote: > Using github we can benefit of their tools to improve our process > (issue tracker, travis and appveyor, etc.) and we will improve > project visibility. I fear that without the in-image tooling, it will be difficult to actually get other people to contribute at the code level. I have, and have seen others, struggled to use git-based tooling for Pharo. Stephan

June 8, 2016

Re: [Pharo-dev] shortcut settings (was: Re: Playground and text evaluation printing result default.)

by Nicolai Hess

2016-06-08 22:15 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > > On Jun 8, 2016, at 7:35 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-06-08 19:11 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Yes, we already agreed on that both for the debugger and for Spotter. We > just did not get the chance to do it yet. > > > > Hey Doru, > > > > about your report > > https://pharo.fogbugz.com/f/cases/18455 Spotter shortcuts should be > externalized as settings > > > > Please don't do this just for spotter. We really need a general solution > for all tools shortcuts. > > Hehe, I was about to raise another thread with this issue :) > > > > I am alread about to clean up the shortcut definitions. In the tools and > the PharoShortcuts class. > > I was thinking of using PharoShortcuts and providing settings for them. > > > > But we still need a way to really define this in a customizable way. > > > > I already wrote about this and asked (ML or fogbugz, I don't remember). > > The current shortcut definitions (with pragmas for example). Can be > browsed and in the Keymap browser (that is good), but they can not be > changed of course, they are defined in the source. > > And, the current keymap definitions (KMKEyCombination) need a way to be > able to read and write as a setting, that currently does not work (as I > wrote). > > > > My proposition was, to define some kind of "Named-Keyaction" or > "Named-Action", for example > > > > CopySelectionAction (name = CopySelection, shortcut Ctrl+C), it would > act as a KMKeyCombination, but its own shortcut (Ctrl+C) would be > configurable. > > > > Now, in PharoShortcuts instead of > > > > PharoShortcuts >>#copySelectionShortcut > > > > ^ $c meta > > > > we define > > > > PharoShortcuts >>#copySelectionShortcut > > > > ^ CopySelectionAction withShortcut: $c meta > > I was thinking to have directly the setting > > PharoShortcuts >>#copySelectionShortcut > ^ self shortcutFor: #copySelection default: [ $c meta ] > > and in PharoShortcuts we have a dictionary out of which we can create > settings. > > Would this not be enough? > I don't know. What would shortcutFor return ? Just a plain shortcut. If so, changing this shortcut in the settings would only take an effect if (the user or the settings browser) triggers a KMRepository reset. And only for keybdings defined by a keymap pragma. If a tools had registered a direct keybinding on a Morph of an already opened tool, would this be updated as well? > > Doru > > > > (maybe on unique Instance of CopySelectionAction, or one per category) > > > > And the keymap browser, or the settings browser could list these actions > and provide a way to reset the > > keycombination: > > > > CopySelectionAction - | type some keycombination here | > > > > > > The current way with the PharoShortcuts class and how the keys are > binded to the tools don't really work for customizable shortcut definitions > (or keymaps) or > > > > I just don't see it. > > > > > > nicolai > > > > > > > > > > Doru > > > > > > > On Jun 8, 2016, at 11:33 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > > > > > >> On 08 Jun 2016, at 09:04, stepharo <stepharo(a)free.fr> wrote: > > >> > > >> the fact that I cannot access Spotter without hurting my hand it is > also probably why I do not try more. > > > > > > yeah, shortcut has to be configurable, for people with big hands :) > > > > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Every now and then stop and ask yourself if the war you're fighting is > the right one." > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > > >

June 8, 2016

shortcut settings (was: Re: Playground and text evaluation printing result default.)

by Tudor Girba

Hi, > On Jun 8, 2016, at 7:35 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-08 19:11 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Yes, we already agreed on that both for the debugger and for Spotter. We just did not get the chance to do it yet. > > Hey Doru, > > about your report > https://pharo.fogbugz.com/f/cases/18455 Spotter shortcuts should be externalized as settings > > Please don't do this just for spotter. We really need a general solution for all tools shortcuts. Hehe, I was about to raise another thread with this issue :) > I am alread about to clean up the shortcut definitions. In the tools and the PharoShortcuts class. I was thinking of using PharoShortcuts and providing settings for them. > But we still need a way to really define this in a customizable way. > > I already wrote about this and asked (ML or fogbugz, I don't remember). > The current shortcut definitions (with pragmas for example). Can be browsed and in the Keymap browser (that is good), but they can not be changed of course, they are defined in the source. > And, the current keymap definitions (KMKEyCombination) need a way to be able to read and write as a setting, that currently does not work (as I wrote). > > My proposition was, to define some kind of "Named-Keyaction" or "Named-Action", for example > > CopySelectionAction (name = CopySelection, shortcut Ctrl+C), it would act as a KMKeyCombination, but its own shortcut (Ctrl+C) would be configurable. > > Now, in PharoShortcuts instead of > > PharoShortcuts >>#copySelectionShortcut > > ^ $c meta > > we define > > PharoShortcuts >>#copySelectionShortcut > > ^ CopySelectionAction withShortcut: $c meta I was thinking to have directly the setting PharoShortcuts >>#copySelectionShortcut ^ self shortcutFor: #copySelection default: [ $c meta ] and in PharoShortcuts we have a dictionary out of which we can create settings. Would this not be enough? Doru > (maybe on unique Instance of CopySelectionAction, or one per category) > > And the keymap browser, or the settings browser could list these actions and provide a way to reset the > keycombination: > > CopySelectionAction - | type some keycombination here | > > > The current way with the PharoShortcuts class and how the keys are binded to the tools don't really work for customizable shortcut definitions (or keymaps) or > > I just don't see it. > > > nicolai > > > > > Doru > > > > On Jun 8, 2016, at 11:33 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > >> On 08 Jun 2016, at 09:04, stepharo <stepharo(a)free.fr> wrote: > >> > >> the fact that I cannot access Spotter without hurting my hand it is also probably why I do not try more. > > > > yeah, shortcut has to be configurable, for people with big hands :) > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > > > > -- www.tudorgirba.com www.feenk.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

June 8, 2016

Re: [Pharo-dev] endless loop again

by stepharo

May be you should raise the question in the vm mailing-list. It would be a really great feature. Stef Le 8/6/16 Ã 21:33, Esteban A. Maringolo a Ã©crit : > 2016-06-08 6:29 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> On 08 Jun 2016, at 11:24, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >>> Not entirely true :-) There are smalltalks out there that detect such stack growth and do the same as CL, >>> throw a (resumable) exception. Super-handy. Some of them have this for at least 10 years now :-) >> I was talking about our VM. It is good to know that it already exists in other Smalltalk implementations. You mean Smalltalk/X ? > Dolphin has this feature (see atached file), and AFAIR VisualAge too. > I implemented an infinite recursion, which was handled by Dolphin, but > crashed Pharo. > > > Regards,

June 8, 2016

Re: [Pharo-dev] Playground and text evaluation printing result default.

by Tudor Girba

Hi, > On Jun 8, 2016, at 9:12 AM, stepharo <stepharo(a)free.fr> wrote: > > Le 8/6/16 Ã 09:04, stepharo a Ã©crit : > >> This is incorrect. If you would not complain aggressively, we would simply have a smoother conversation about solutions. > My final point: > > Aggressivity is often the result of not being heard. This is a choice. > So now you can argue that you listen :) > But I decided that I will not bother people about such little problems anymore. > If people believe that I'm trolling then it is the time to do something else for me. Not once did you get a reply on this mailing list saying that a problem that was raised was bothering us. And you certainly will never get it from me. You always got a reply related to the content, and often the discussion led to new things. We need these discussions. Doru > And this is what I will do. > Stef > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

June 8, 2016

Re: [Pharo-dev] endless loop again

by Esteban A. Maringolo

2016-06-08 6:29 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> On 08 Jun 2016, at 11:24, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> Not entirely true :-) There are smalltalks out there that detect such stack growth and do the same as CL, >> throw a (resumable) exception. Super-handy. Some of them have this for at least 10 years now :-) > > I was talking about our VM. It is good to know that it already exists in other Smalltalk implementations. You mean Smalltalk/X ? Dolphin has this feature (see atached file), and AFAIR VisualAge too. I implemented an infinite recursion, which was handled by Dolphin, but crashed Pharo. Regards,

June 8, 2016

Re: [Pharo-dev] IMPORTANT: Proposal to create a github team for Voyage and MongoTalk

by stepharo

Le 8/6/16 Ã 12:12, Sabine Manaa a Ã©crit : > Hi Esteban, > > a few days ago, I started reading about Pharo/Github because I am > interested in administering my code in github, too. > I stopped then, because I loose time, which I can not spend in > development of my application. > I thought, I will do that later - when there will be more automated > support for github within Pharo. > Also, from the beginning of administering my code in github, I have to > pay for it, because my project is not public. use bitbucket Now Pharo will move to git so it is just a question of time. > But in the long run, I have to do this and learn it and I am looking > forward to it. > And getting code for mongo from github does not mean, putting my stuff > there immediately, too. > For me it would be the first github learning step. But this will be transparent for you. Just load the configuration from the Catalog and nothing to change. > > It would help to have a description, what to do to get the code then > from github instead of sthub, but I am sure you will do that. > I mean not only get code from catalog but also through my > configurationOf.... > > I would be happy to help if I can. > > Regards > Sabine > > > > > > 2016-06-08 11:54 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>>: > > Hi, > > (this mail is intended to Voyage/MongoTalk users and collaborators) > > Iâm spending a couple of days in Cologne, at 2Denker offices and I > was talking Norbert about organisation of Voyage and the NoSQL > driversâ¦ As a conclusion, we want to propose to move the Voyage > and MongoTalk development to github, into a common team where > other NoSQL drivers can eventually arrive (Voyage will incorporate > other backends that might well be there). > > One reason from this is that I do not consider appropriate to keep > Voyage into my repository, because is more a community project > than a personal one. I want others to be able to participate more > and I think this is the right step (also Dale is porting it to > Gemstone soâ¦) > > Using github we can benefit of their tools to improve our process > (issue tracker, travis and appveyor, etc.) and we will improve > project visibility. > > So, we wanted to create âPharoNoSQL" team, and move all thereâ¦ > then we will close sthub projects to avoid confusion and we will > handle configurations and baselines same way as Yuriy does with > QualityAssistance (so it will be available through catalog as always). > > Opinions? > > Esteban > >

June 8, 2016

Re: [Pharo-dev] Playground and text evaluation printing result default.

by Nicolai Hess

2016-06-08 19:45 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi nicolai > > Indeed we need on way to define "menuItem action" > > I do not know if it should be bound to shortcut but it should have a > shortcut. > > I saw that Glamour has one way, the core other ways and probably Spec a > third one. > > So this is really confusing. > > With guille we discussed a while ago about a hierarchy of command > > id > > description > > flyhelp > > action > > shortcut. > > So probably the shortcut should be virtual so that we can bind the one we > want system wide. > +1 yes , something like that > I would love to have Ctrle Ctrla.... ") > > stef > Le 8/6/16 Ã 19:35, Nicolai Hess a Ã©crit : > > > > 2016-06-08 19:11 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Yes, we already agreed on that both for the debugger and for Spotter. We >> just did not get the chance to do it yet. >> > > Hey Doru, > > about your report > https://pharo.fogbugz.com/f/cases/18455 Spotter shortcuts should be > externalized as settings > > Please don't do this just for spotter. We really need a general solution > for all tools shortcuts. > > I am alread about to clean up the shortcut definitions. In the tools and > the PharoShortcuts class. > But we still need a way to really define this in a customizable way. > > I already wrote about this and asked (ML or fogbugz, I don't remember). > The current shortcut definitions (with pragmas for example). Can be > browsed and in the Keymap browser (that is good), but they can not be > changed of course, they are defined in the source. > > And, the current keymap definitions (KMKEyCombination) need a way to be > able to read and write as a setting, that currently does not work (as I > wrote). > > My proposition was, to define some kind of "Named-Keyaction" or > "Named-Action", for example > > CopySelectionAction (name = CopySelection, shortcut Ctrl+C), it would act > as a KMKeyCombination, but its own shortcut (Ctrl+C) would be configurable. > > Now, in PharoShortcuts instead of > > PharoShortcuts >>#copySelectionShortcut > > ^ $c meta > > we define > > PharoShortcuts >>#copySelectionShortcut > > ^ CopySelectionAction withShortcut: $c meta > > (maybe on unique Instance of CopySelectionAction, or one per category) > > And the keymap browser, or the settings browser could list these actions > and provide a way to reset the > keycombination: > > CopySelectionAction - | type some keycombination here | > > > The current way with the PharoShortcuts class and how the keys are binded > to the tools don't really work for customizable shortcut definitions (or > keymaps) or > > I just don't see it. > > > nicolai > > > > >> >> Doru >> >> >> > On Jun 8, 2016, at 11:33 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > >> > >> >> On 08 Jun 2016, at 09:04, stepharo < <stepharo(a)free.fr> >> stepharo(a)free.fr> wrote: >> >> >> >> the fact that I cannot access Spotter without hurting my hand it is >> also probably why I do not try more. >> > >> > yeah, shortcut has to be configurable, for people with big hands :) >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every now and then stop and ask yourself if the war you're fighting is >> the right one." >> >> >> >> >> >> > >

June 8, 2016

Re: [Pharo-dev] Playground and text evaluation printing result default.

by stepharo

Le 8/6/16 Ã 11:33, Esteban Lorenzano a Ã©crit : > >> On 08 Jun 2016, at 09:04, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> the fact that I cannot access Spotter without hurting my hand it is >> also probably why I do not try more. > > yeah, shortcut has to be configurable, for people with big hands :) and big mouth.... and strong teeth :) Stef > >

June 8, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] bb7382: 60072

by stepharo

> 60072 > 18451 Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo: > https://pharo.fogbugz.com/f/cases/18451 > > Is there a rule for such case? Stef

June 8, 2016