November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Redline Smalltalk on heroku ....

by Marcus Denker

On Nov 30, 2012, at 10:08 PM, James Ladd <james_ladd(a)hotmail.com> wrote: > Redline Smalltalk is easily deployed to Heroku, a cloud service. > > So writing web apps in Smalltalk and deploying them to the could > just got a whole let easier. https://stout.herokuapp.com/ > > Please support the Redline project here: http://www.indiegogo.com/smalltalk/x/1366536 > YES - We are providing classes to make deploying Pharo app to Redline a snap. We will seeâ¦ it's hard to implement a real smalltalk in Java (think about #become:â¦), but I fear it will be even harder to follow where Pharo is goingâ¦ (We can discuss that over a beer sometime :-) Marcus

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by âking

On 11/30/2012 12:13 PM, Igor Stasenko wrote: > well, what you explaining here is not just about handling keyboard > typing, but also > requires changes in UI (showing command line, black & white color > scheme, 80x25 text mode ;) ) etc.. I know you're joking, but limiting one's self to 80 columns is generally a good way to maximize screen space. Step back and look at code that runs with really long lines, and you'll see a vast emptiness on most lines. > i think, if vi would contest for "best obscure editor", i guess it > would get 1st prize. i don't really care why you like it , just can you > (or someone else) explain me, why you think it is best possible way of > doing things? Since i can't see it. Monkey-bopping not a compelling argument? I mean, the goal is to make a fluid interface. The subtitle of one of the vim books is "Edit at the Speed of Thought". That's the key thing. When I'm coding with vi keys, the text just goes where I want it, and quickly, with very little stopping to think about it. > What exactly commands/shortcuts you wanna have there? > And wouldn't it be better to focus UI design towards avoiding the need > for shortcuts/modes alltogether? Possibly. I'll think about that. > After all, you can run vi/emacs/<put your favorite> in separate window, > and can always copy-paste text between, and enjoy your lovely keyboard > shortcuts. This is something that Pentadactyl (a amazing Firefox plugin that makes the browser vim-like) does. You can hit Ctrl+i on any text field, and it pops up a gvim window with that text. Perhaps something like this is sufficient. We'll see. My problem right now is that I have dozens of projects that steal my free time from getting into Smalltalk, but I'll fix that as soon as I can. ââ

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by âking

On 11/30/2012 01:25 PM, dimitris chloupis wrote: > Both #emacs and #vim show how popular both of these text editors are, > why not pharo attract that crowd. Another part of this is just making UIs for editing non-Smalltalk code. If I had a good editor widget available, I could use it to make any number of powerful other tools. ââ

Nov. 30, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by stephane ducasse

camillo one of the problem that we have is that the refactoring stopped in the middle because displayProgressFrom: minVal to: maxVal during: workBlock now works with job and this is nice but job requires but all the user of displayProgressFrom: minVal to: maxVal during: workBlock are using bar current: aNumber and not a value between 0 and 1.0. So this means that we will a lot of broken code. Am I correct? Stef displayProgressFrom: minVal to: maxVal during: workBlock "Display this string as a caption over a progress bar while workBlock is evaluated. 'Now here''s some Real Progress' displayProgressFrom: 0 to: 10 during: [:bar | 1 to: 10 do: [:x | bar value: x. (Delay forMilliseconds: 500) wait]]. " ^ UIManager default displayProgress: self from: minVal to: maxVal during: workBlock displayProgress: titleString from: minVal to: maxVal during: workBlock "SystemProgressMorph show: titleString from: minVal to: during: " ^ workBlock asJob title: titleString; min: minVal; max: maxVal; run.

Nov. 30, 2012

[Pharo-project] Redline Smalltalk on heroku ....

by James Ladd

Redline Smalltalk is easily deployed to Heroku, a cloud service. So writing web apps in Smalltalk and deploying them to the could just got a whole let easier. https://stout.herokuapp.com/ Please support the Redline project here: http://www.indiegogo.com/smalltalk/x/1366536 YES - We are providing classes to make deploying Pharo app to Redline a snap. Heroku work was done by Will Leinweber His github repo has the project and code.

Nov. 30, 2012

Re: [Pharo-project] CogVM crash code

by Eliot Miranda

thanks, Jon. Good one! On Fri, Nov 30, 2012 at 9:07 AM, Jon Anderson <jonkanderson(a)gmail.com>wrote: > !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, Eliot

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by Peter Hugosson-Miller

+1 -- Cheers, Peter. On 30 nov 2012, at 19:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 30 November 2012 18:23, âking <rkingdesk(a)sharpsaw.org> wrote: >> 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] >> > > well, what you explaining here is not just about handling keyboard > typing, but also > requires changes in UI (showing command line, black & white color > scheme, 80x25 text mode ;) ) etc.. > > i think, if vi would contest for "best obscure editor", i guess it > would get 1st prize. > i don't really care why you like it , just can you (or someone else) > explain me, why you think > it is best possible way of doing things? > Since i can't see it. > > What exactly commands/shortcuts you wanna have there? > And wouldn't it be better to focus UI design towards avoiding the need > for shortcuts/modes alltogether? > > Also, i going to repeat same over again: we don't need a full-fledged > text editor(s) in smalltalk IDE. > In smalltalk you will find yourself rarely need to edit more than 10 > lines of code at time. > From that perspective, do you think it is wise to invest people's > energy into that? > I think it should be a call for those who miss it: if you want it - make it. > > After all, you can run vi/emacs/<put your favorite> in separate window, > and can always copy-paste text between, and enjoy your lovely keyboard > shortcuts. > > Sorry, maybe i miss something and don't see full picture, > but i really don't understand what is so cool in having vi/emacs > shortcuts in pharo.. > > >> >> 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?) >> >> ââ >> > > > > -- > Best regards, > Igor Stasenko. >

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by dimitris chloupis

Even though I agree with your Igor , text editing is not per se required by existing smalltalk users, though even that is debatable, introducing vim and emacs mapping, in a completely optional state, will be definitely a motivation for vim and emacs user to join pharo. For example if you enter the pharo channel in irc you will be happy to find one person talking to himself, squeak channel more or less the same. Both #emacs and #vim show how popular both of these text editors are, why not pharo attract that crowd. Let me throw a crazy idea on the table why smalltalk cannot be a more ultimate text editor than those. Sure its ton of work and definetly you or I should not do , but I am sure if we provide minimum means of people to do this we will see more and more people porting vim and emacs features to pharo. Also your point that we dont need text editing that much in pharo , is vaild from one side, however you should not forget that even though vim and emacs might appear radically diffirent from pharo those diffirences are skin deep. All of them have IDE tools , code navigation tools, debuging tools etc ... so I am not that convinced that for example using system browsers via shortcuts cannot be improved. I am actually in the process of learning elisp code to port some of the features of emacs to pharo. ________________________________ From: Igor Stasenko <siguctua(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Friday, 30 November 2012, 20:13 Subject: Re: [Pharo-project] Vim Keys? On 30 November 2012 18:23, âking <rkingdesk(a)sharpsaw.org> wrote: > 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] > well, what you explaining here is not just about handling keyboard typing, but also requires changes in UI (showing command line, black & white color scheme, 80x25 text mode ;) ) etc.. i think, if vi would contest for "best obscure editor", i guess it would get 1st prize. i don't really care why you like it , just can you (or someone else) explain me, why you think it is best possible way of doing things? Since i can't see it. What exactly commands/shortcuts you wanna have there? And wouldn't it be better to focus UI design towards avoiding the need for shortcuts/modes alltogether? Also, i going to repeat same over again: we don't need a full-fledged text editor(s) in smalltalk IDE. In smalltalk you will find yourself rarely need to edit more than 10 lines of code at time. >From that perspective, do you think it is wise to invest people's energy into that? I think it should be a call for those who miss it: if you want it - make it. After all, you can run vi/emacs/<put your favorite> in separate window, and can always copy-paste text between, and enjoy your lovely keyboard shortcuts. Sorry, maybe i miss something and don't see full picture, but i really don't understand what is so cool in having vi/emacs shortcuts in pharo.. > > 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?) > > ââ > -- Best regards, Igor Stasenko.

Nov. 30, 2012

Re: [Pharo-project] CogVM crash code

by Jon Anderson

I added the issue. It is #109. > 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

Nov. 30, 2012

Re: [Pharo-project] Trying Athens

by Casimiro de Almeida Barreto

On 30-11-2012 16:00, Camillo Bruni wrote: > interesting :) can you figure out your proxy configuration? this is very strange :P Proxy Test This request appears to have come via a proxy. The proxy host is *ex1.lsi.usp.br* which has ip address 143.107.161.170 The proxy server has announced itself as *1.1 gate.lsi.usp.br (squid/3.0.STABLE18)* The proxy informs us that the client host ip address was 10.0.164.156 The Lagado <http://www.lagado.com/> Proxy Test shows details of any proxy servers you are using. It is especially useful to expose transparent proxies. These are proxies inserted between your browser and the web, typically by your ISP, and often without you knowing. Sometimes a proxy will be deliberately hidden so it won't be exposed by this test. In this case you can use the Cache Test <http://www.lagado.com/tools/cache-test> to expose stealthed transparent proxy caches. The Raw Details Here are the raw details of the request received by this server. *Remote Host* ex1.lsi.usp.br *IP Address* 143.107.161.170 *Request Protocol* HTTP/1.0 *Method* GET *Request Headers* *Host* www.lagado.com *User-Agent* Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.91 Safari/537.11 *Accept* text/html,application/xhtml+xml,application/xml;q=0.9, */*;q=0.8 *Referer* http://www.lagado.com/text/tools_b7f5.htm *Accept-Encoding* gzip,deflate,sdch *Accept-Language* pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4 *Accept-Charset* ISO-8859-1,utf-8;q=0.7,*;q=0.3 *Via* 1.1 gate.lsi.usp.br (squid/3.0.STABLE18) *X-Forwarded-For* 10.0.164.156 *Cache-Control* max-age=259200 *Connection* keep-alive *This Server Host* www.lagado.com *IP Address* 210.50.6.232 *Date:* Saturday 1 Dec 2012 5:31:44 GMT+1100 > > > > On 2012-11-30, at 14:33, Casimiro de Almeida Barreto <casimiro.barreto(a)gmail.com> wrote: > >> 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