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

Re: [Pharo-project] Vim Keys?

by Igor Stasenko

On 30 November 2012 23:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Nov 2012, at 23:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> And here is where shortcuts come in handy.. > > Igor, you are not even using Command-Enter to search for classes/methods last time we sat togetherâ¦ ;-) > the explanation is much easier than you think: in my dev image, which i didn't updated for a while, this function is non-existent. i find myself that, time to time i pressing this magic key combination, get nothing.. and then enduring and continue the old way. :) but from other side, i bet you're not using my little patch to treat multiple white-space characters as a single entity for cursor movement, while i enjoying it :) > Like Command-Click on Class/method names, so cool and technically not keyboard shortcuts ! > yes i like it.. but same issue: i do not change images that often. > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > -- Best regards, Igor Stasenko.

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by Igor Stasenko

On 30 November 2012 22:17, âking <rkingdesk(a)sharpsaw.org> wrote: > 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. > yeah yeah. I can even remember that Bill Gates once said that 640kb of RAM is more than enough for any application. and, btw do you know that color of a blue sky is bad for your sight? :) >> 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? > In that sense, a software which works is the only compelling argument to me :) But since i knowing a bit about VI style of text editing, what you propose is not quite compelling to me. Once i tried hard to become 'pro' vi user and tried to remember all its commands/shortcuts.. but failed miserably after a while.. It looks like i am too spoiled by modeless text editors.. and nothing can change my brain patterns. Because the very first text editor for coding, which i was using around '86 was like hundred times more convenient comparing to what i seen in vim once first time i tried to learn it around 2000's. > 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. i am quite happy with the speed at which i editing right now. :) besides 'fluid interface' is too vague, and adding 'vi' label to it sounds even more fuzzy to me. What i understand that you want to see/make certain improvements in Pharo. And i appreciate that. > 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. > same here, except that i don't use vi keys :) >> 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. > > ââ > > -- Best regards, Igor Stasenko.

Nov. 30, 2012

[Pharo-project] STON Update

by Sven Van Caekenberghe

Hi, Based on feedback by Norbert Hartl, Stuart Herring and Dale Hendrichs (thank you) I improved the current STON version a bit. http://ss3.gemstone.com/ss/STON https://github.com/svenvc/ston Changelog: A nasty cycle bug was fixed Performance was improved, especially for large structures. Some implementation changes (recursion done using a stack, stonProcessSubObjects: optimized using stonContainsSubObjects) I did some stress/performance testing/tuning. Using STONTestMap classTreeExtended. to generate a structure mimicing the class hierarchy, with objects for all classes, about 7000 in my image and all methods, about 64000 in my image, with super/subclass and method owner links to create cycles. This results in a 7 Mb .ston file. The normal code, serializes this in 28 seconds and materializes it in 11.5 seconds. The 'fast' versions (using ZnBuffered[Write|Read]Streams and Fuel Large Datastructures) does it in 1.1 and 3.8 seconds respectively. New users are always welcome. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 30, 2012

Re: [Pharo-project] CogVM crash code

by Eliot Miranda

OK, this is fixed. Thanks, Jon. The bug was that the pop of the folded constant did not record the implicit send in the folding, hence pc mapping was wrong. i.e. 1-1 gets folded away to 0, and the code generator marks the result 0 as being the result of a send, but then the result gets discarded (when it is popped) without being noted in the pc map. In the machine code there needs to be at least a nop generated, and in the map there needs to be an entry, to correspond to the send of +, so that when machine code pcs are mapped to bytecode pcs there are the correct number of entries in the map. In the above case, the VM converts the interpreted frame to a machine code frame (coincidently) on the 20th iteration and needs to map the bytecode pc to the correct machine code pc to continue in machine code. But because of the missing entry in the map for 1-1, the pc mapping machinery answered 0, and the VM ended up jumping into the void. Thanks very much for the bug report! On Fri, Nov 30, 2012 at 9:07 AM, 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, Eliot

Nov. 30, 2012

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

by Sebastian Nozzi

I am one of those developers coding Java for a living, but day-dreaming of using Smalltalk instead. As such, the Redline project of course cought my attention and took a look at it. I am no authority on Redline, but I think there is some confusion here that I could clarify. 2012/11/30 Marcus Denker <marcus.denker(a)inria.fr>: > We will seeâ¦ it's hard to implement a real smalltalk in Java (think about > #become:â¦), but I think Redline is not trying to be a full-fledged Smalltalk (not like the Squeak port to the JVM). It is more in the spirit of Amber. A Smalltalk-to-Java compiler, with some underlying runtime support. It does not aim at supporting the full enchilada :-) Are there some vital things that are impossible if #become: is missing? (no irony in my question, I just don't know) > I fear it will be even harder to follow where Pharo is goingâ¦ Again, I think the comment was meant to mean that Pharo-based projects could be exported to the Redline source format, and made be to run there also. Not that Pharo (core) code will/can run automatically on Redline. Many things just will never run or not make sense at all (Fuel, Monti-/Metacello, Polymorph/Spec, NativeBoost, etc.) I for one welcome the possibility to be able to run Smalltalk in one more runtime-environment. Smalltalk should run everywhere! :-) On the other hand I am also aware that the experience of coding in Maven/Eclipse projects is just not the same as in an environment like Pharo. It is just... different. I found joy and sorrow on both sides ;-) Cheers, Sebastian

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by Igor Stasenko

On 30 November 2012 22:16, âking <rkingdesk(a)sharpsaw.org> wrote: > 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. > But then you started from wrong end, isn't? You're free to implement own full blown text editor using smalltalk, as well as any other language. with any shortcuts you may like.. but you trying to sell it as "vi shortcuts for pharo".. which a bit strange. Because what is not clear to me, is where is the gain concretely for Pharo IDE and its tools. And don't take me wrong: i would be happy to have good rich-text editor widget with configurable shortcuts. But i just see key thing: it does not looks like absolute necessity to me (as for smalltalk developer). And if i would be a book writer or html "writer" you may get different opinion. But that's the point: there's already tons of text editors specialized for anything (but smalltalk).. which you can use right now, without need to wait till someone will implement it. So, why not use them? > ââ > -- Best regards, Igor Stasenko.

Nov. 30, 2012

Re: [Pharo-project] Combining Regular Monticello with Github/FileTree

by Camillo Bruni

On 2012-11-30, at 19:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I have been using both Github/FileTree and Monticello for STON this week, and things have definitively progressed. Thank you, Dale & friends. > > It does seem that I have to save a version to Github/FileTree first and then copy it to Monticello (ss3) and not the other way around - otherwise things seem to get messed up. So Github/FileTree is sticky ;-) > > Sven > > PS: in th FileTree code that I am using (from Metacello/Pharo 2.0) there is a small UI problem: > > SmallInteger>>/ > Job>>progress > JobChange>>progress > SystemProgressMorph class>>updateJob: > MessageSend>>value: > MessageSend>>cull: > MessageSend>>cull:cull: > AnnouncementSubscription>>deliver: in Block: [action cull: anAnnouncement cull: announcer] > BlockClosure>>on:do: > BlockClosure>>on:fork: in Block: [Processor terminateActive] my bad, I have to finish my Job/ProgressBar refactoring :P

Nov. 30, 2012

Re: [Pharo-project] Combining Regular Monticello with Github/FileTree

by Sven Van Caekenberghe

I have been using both Github/FileTree and Monticello for STON this week, and things have definitively progressed. Thank you, Dale & friends. It does seem that I have to save a version to Github/FileTree first and then copy it to Monticello (ss3) and not the other way around - otherwise things seem to get messed up. So Github/FileTree is sticky ;-) Sven PS: in th FileTree code that I am using (from Metacello/Pharo 2.0) there is a small UI problem: SmallInteger>>/ Job>>progress JobChange>>progress SystemProgressMorph class>>updateJob: MessageSend>>value: MessageSend>>cull: MessageSend>>cull:cull: AnnouncementSubscription>>deliver: in Block: [action cull: anAnnouncement cull: announcer] BlockClosure>>on:do: BlockClosure>>on:fork: in Block: [Processor terminateActive] (The stack isn't any longer ;-) On 27 Nov 2012, at 22:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Dale, Max, > > It might be that I was using an older filetree version, I am just going to overwrite the git files and commit and see from there. > It is good to know that it should work. > > Thx, > > Sven > > > On 27 Nov 2012, at 21:58, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> Sven, >> >> When viewing changes from the Monticello Browser, there are certain circumstances when the Browser doesn't recognize that the package in a FileTree repository is an ancestor (I haven't fully characterized this, but I have seen it happen - I think it usually happens when the package in FileTree is not a direct ancestor of the in-image package) ... This is the type of thing that happens when packages names have been changed in Monticello as well ... >> >> In those cases, you be able to _open_ the repository and do a direct comparison of the in-image package and the package in the repository and get a good comparison ... >> >> Dale >> >> ----- Original Message ----- >> | From: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> | To: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> >> | Sent: Tuesday, November 27, 2012 11:56:18 AM >> | Subject: [Pharo-project] Combining Regular Monticello with Github/FileTree >> | >> | Hi, >> | >> | Before I get too frustrated trying, a quick question: is it possible >> | to combine regular monticello with github/filetree ? >> | >> | I have STON both in ss3 as on github, but it seems I cannot compare >> | my in-image ss3 version with a filetree/github repository on disk: >> | it reports everything as changed (maybe due to meta data >> | differences, I don't know). >> | >> | How do I know the difference between the ss3 version and the filetree >> | version ? >> | I guess I could just save the filetree version and let git decide ? >> | But maybe, then everything will be different as well ? >> | >> | Sven >> | >> | -- >> | Sven Van Caekenberghe >> | http://stfx.eu >> | Smalltalk is the Red Pill >> | >> | >> | >> | >> | >> >

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by Sven Van Caekenberghe

On 30 Nov 2012, at 23:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > And here is where shortcuts come in handy.. Igor, you are not even using Command-Enter to search for classes/methods last time we sat togetherâ¦ ;-) Like Command-Click on Class/method names, so cool and technically not keyboard shortcuts ! -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by Igor Stasenko

On 30 November 2012 20:25, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > 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. i am not against it. I just a bit tired of seeing this recurring topic appear again and again and no action. Come on, people. Pharo is open-source project. If you need it so badly, then do it. Don't wait till someone, one day do it for you, and stop wasting time, repeating same arguments over and over again, how good vi/emacs mappings are comparing to what we having now. > > 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. > it can and should be improved. Absolutely. But pharo environment is much more than text editing, and so, asking if it can provide "vi mapping" to me sounds similar to "can photoshop provide vi/emacs mapping" , i.e. makes no sense at all. apart from this is implementing a full-fledged text editor/word processor: it is doable and been done before (like Sophie project did). But this is completely orthogonal to IDE: i simply do not see how shortcuts like making text "bold" or "italic" could significantly improve my daily coding experience. For coding i concerned about completely different things: code navigation, browser etc.. And here is where shortcuts come in handy.. Now if someone tell me how "senders of it" action shortcut (to browse senders of selector) which i often using by pressing 'Cmd-n' can be ton times more convenient to use, once we will use vi shortcut for it (btw, what is default vi shortcut for such action?)... i am all ears. > I am actually in the process of learning elisp code to port some of the > features of emacs to pharo. > -- Best regards, Igor Stasenko.

Nov. 30, 2012