- Pharo-dev - lists.pharo.org

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

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