- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Vim Keys?

by Igor Stasenko

On 30 November 2012 17:48, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Nov 30, 2012, at 5:41 PM, âking <rkingdesk(a)sharpsaw.org> wrote: > >> On 11/30/2012 02:15 AM, Goubier Thierry wrote: >>> It's underway. The infrastructure is moving to a better (unified) way of >>> specifying and handling shortcuts, and then vi and vim-keys and emacs >>> and others should become available. >> >> I have a radical question that I'd like to float. >> >> What about making vi keys not only possible, but the *default* for Pharo? >> > > I am sure the Emacs user will be violently against it. > > Another thing is that I personally think that one of the things that Smalltalk > did very early is to not have modes for editingâ¦ > > Are editing modes really something people want in 2012? > > (and no, I am not a vi user. I know one vi command and that is esc : q ! > to get out of thereâ¦) > i know a bit more. but that's my favorite :) as to me, it is ok if pharo could have key bindings for anything, as long as it does not interfere with my workflow and does not forcing me to "do it right way". > Marcus -- Best regards, Igor Stasenko.

Nov. 30, 2012

Re: [Pharo-project] CogVM crash code

by Igor Stasenko

On 30 November 2012 18:27, Camillo Bruni <camillobruni(a)gmail.com> wrote: > uuh nasty :), also happens under 2.0 ;) > huh... unbelievable.. how such simple piece of code can do any harm? :) > could you open an issue on the cog issue tracker with the contents of this email? > https://code.google.com/p/cog/issues/list > > thanks > > On 2012-11-30, at 14:07, Jon Anderson <jonkanderson(a)gmail.com> wrote: > >> Hi all, >> >> I don't post to lists often, but I thought some of you might be >> interested in these few lines of code that crash the CogVM on both >> Linux and Windows. File-in the Smalltalk code below, then evaluate >> [nil crashCogVM]. The code uses [1-1] but it could use [1+1] or >> [56+98]. I put the code on nil, but that is not important either. I >> think the important thing is that the primitive (+ or -) is evaluated >> but the result is not assigned into any variable. Also important is >> that the code is put into a loop that I assume has been JIT optimized. >> The image I used is Pharo 1.4 one-click with latest update #14459. >> This code does not crash StackVM. Have fun! - Jon. >> >> !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! >> crashCogVM >> " Evaluate [ >> nil crashCogVM ]" >> >> | i | >> i := 20. >> 1 to: i do: [:d | 1-1 ] >> ! ! >> > > -- Best regards, Igor Stasenko.

Nov. 30, 2012

Re: [Pharo-project] Trying Athens

by Casimiro de Almeida Barreto

On 30-11-2012 15:24, Camillo Bruni wrote: > most probably https://code.google.com/p/pharo/issues/detail?id=6986 > > are you behind a proxy? Yes, seems to be the problem just as reported in issues #6986 > > On 2012-11-30, at 14:13, Casimiro de Almeida Barreto <casimiro.barreto(a)gmail.com> wrote: > >> I've had strange problem with Pharo 2.0: it times out at Gofer. For >> instance: >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfSeaside30'; >> load. >> >> Will spend the 30secs timeout & then give-me a debugger window >> complaining that could not connect. But network is OK and Pharo 1.4 does >> not have this problem. Besides, Pharo 2.0 updates OK (so, again, there's >> no network problem). >> >> CdAB >> > >

Nov. 30, 2012

Re: [Pharo-project] CogVM crash code

by Camillo Bruni

uuh nasty :), also happens under 2.0 ;) could you open an issue on the cog issue tracker with the contents of this email? https://code.google.com/p/cog/issues/list thanks On 2012-11-30, at 14:07, Jon Anderson <jonkanderson(a)gmail.com> wrote: > Hi all, > > I don't post to lists often, but I thought some of you might be > interested in these few lines of code that crash the CogVM on both > Linux and Windows. File-in the Smalltalk code below, then evaluate > [nil crashCogVM]. The code uses [1-1] but it could use [1+1] or > [56+98]. I put the code on nil, but that is not important either. I > think the important thing is that the primitive (+ or -) is evaluated > but the result is not assigned into any variable. Also important is > that the code is put into a loop that I assume has been JIT optimized. > The image I used is Pharo 1.4 one-click with latest update #14459. > This code does not crash StackVM. Have fun! - Jon. > > !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! > crashCogVM > " Evaluate [ > nil crashCogVM ]" > > | i | > i := 20. > 1 to: i do: [:d | 1-1 ] > ! ! >

Nov. 30, 2012

Re: [Pharo-project] Trying Athens

by Camillo Bruni

most probably https://code.google.com/p/pharo/issues/detail?id=6986 are you behind a proxy? On 2012-11-30, at 14:13, Casimiro de Almeida Barreto <casimiro.barreto(a)gmail.com> wrote: > I've had strange problem with Pharo 2.0: it times out at Gofer. For > instance: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside30'; > load. > > Will spend the 30secs timeout & then give-me a debugger window > complaining that could not connect. But network is OK and Pharo 1.4 does > not have this problem. Besides, Pharo 2.0 updates OK (so, again, there's > no network problem). > > CdAB >

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by âking

On 11/30/2012 10:48 AM, Marcus Denker wrote: > I am sure the Emacs user will be violently against it. Actually, that's the thing: Namespacing. You could install vi keys on emacs and an emacs user would never notice without hitting the Escape key. Emacs keys, on the other hand, *do* conflict with existing Pharo bindings. > Another thing is that I personally think that one of the things that Smalltalk > did very early is to not have modes for editingâ¦ > > Are editing modes really something people want in 2012? Think of modes as a monkey that sits by your keyboard. Every time you bop him on the head (that is, you hit Escape), he obediently reaches over and holds down a special keyboard modifier for you, and continues to do so until you tell him to stop. Since bopping him on the head takes no more time than hitting the modifier key itself, hitting [Bop],[Key] is always going to be an equally concise way of entering a string of commands compared to chording [Modifier+Key]. But generally it's more concise, because you tend to do big sequences of one or the other: edit a bunch, or input a bunch. That is, in real life you do [Bop],[Key],[Key2],[Key],[Key3], which is better than [Modifier1+Key],[Modifier2+Key2],[Modifier1+Key],[Ctrl+Alt+Shift+Modifier+TurboDrive+Footpedal+â+Key3] The critical point is that users that don't enter command mode would never be bothered by it. Users who do stumble upon it could get an additional leg up with the help text, and they don't even really have to know it's "Vi Keys", just that it's a non-chorded interface. I know it's radical, but that's how we roll. (Right?) ââ

Nov. 30, 2012

[Pharo-project] Trying Athens

by Casimiro de Almeida Barreto

I've had strange problem with Pharo 2.0: it times out at Gofer. For instance: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. Will spend the 30secs timeout & then give-me a debugger window complaining that could not connect. But network is OK and Pharo 1.4 does not have this problem. Besides, Pharo 2.0 updates OK (so, again, there's no network problem). CdAB

Nov. 30, 2012

[Pharo-project] CogVM crash code

by Jon Anderson

Hi all, I don't post to lists often, but I thought some of you might be interested in these few lines of code that crash the CogVM on both Linux and Windows. File-in the Smalltalk code below, then evaluate [nil crashCogVM]. The code uses [1-1] but it could use [1+1] or [56+98]. I put the code on nil, but that is not important either. I think the important thing is that the primitive (+ or -) is evaluated but the result is not assigned into any variable. Also important is that the code is put into a loop that I assume has been JIT optimized. The image I used is Pharo 1.4 one-click with latest update #14459. This code does not crash StackVM. Have fun! - Jon. !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! crashCogVM " Evaluate [ nil crashCogVM ]" | i | i := 20. 1 to: i do: [:d | 1-1 ] ! !

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by Marcus Denker

On Nov 30, 2012, at 5:41 PM, âking <rkingdesk(a)sharpsaw.org> wrote: > On 11/30/2012 02:15 AM, Goubier Thierry wrote: >> It's underway. The infrastructure is moving to a better (unified) way of >> specifying and handling shortcuts, and then vi and vim-keys and emacs >> and others should become available. > > I have a radical question that I'd like to float. > > What about making vi keys not only possible, but the *default* for Pharo? > I am sure the Emacs user will be violently against it. Another thing is that I personally think that one of the things that Smalltalk did very early is to not have modes for editingâ¦ Are editing modes really something people want in 2012? (and no, I am not a vi user. I know one vi command and that is esc : q ! to get out of thereâ¦) Marcus

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by âking

On 11/30/2012 02:15 AM, Goubier Thierry wrote: > It's underway. The infrastructure is moving to a better (unified) way of > specifying and handling shortcuts, and then vi and vim-keys and emacs > and others should become available. I have a radical question that I'd like to float. What about making vi keys not only possible, but the *default* for Pharo? They generally don't conflict with anything, because they're all "Namespaced" under sequences that you hit Escape for. This means you could continue to edit exactly as you do, but when you hit Esc you get some bonus functionality. And just because vi keys are the most hardcore interface ever of all time, that doesn't mean it has to be for neckbeards-only. We could make it so the text box has a status indicator, with help available and everything. Imagine a bar at the bottom that says, "Vi Command Mode", which can be clicked for a full help, then the rest of the bar has hints about common commands. It could even be adaptive, like learn to tell you commands that you haven't used much. The same bar could also say "Stop this crazy feature I don't like it". ââ

Nov. 30, 2012