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

Re: [Pharo-project] Getting the stack trace for an exception

by Guillermo Polito

Yeap, I found that what I want should be something like: exception signalerContext errorReportOn: aStream Thanks! On Thu, Mar 8, 2012 at 7:54 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 March 2012 23:26, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi! > > > > I can't find any way of asking an exception it's stacktrace, which I > found > > useful when logging errors... > > > > I know the code for it is surely written somewhere, but > > - I do not know where > > - wouldn't be ok to move this behaviour to exception/error? (if not, > why?) > > > usually it is a context which having #stack > and exception, which having #signalerContext > > > Guille > > > > -- > Best regards, > Igor Stasenko. > >

March 8, 2012

Re: [Pharo-project] Getting the stack trace for an exception

by Igor Stasenko

On 8 March 2012 23:26, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi! > > I can't find any way of asking an exception it's stacktrace, which I found > useful when logging errors... > > I know the code for it is surely written somewhere, but > - I do not know where > - wouldn't be ok to move this behaviour to exception/error?Â (if not, why?) > usually it is a context which having #stack and exception, which having #signalerContext > Guille -- Best regards, Igor Stasenko.

March 8, 2012

[Pharo-project] Getting the stack trace for an exception

by Guillermo Polito

Hi! I can't find any way of asking an exception it's stacktrace, which I found useful when logging errors... I know the code for it is surely written somewhere, but - I do not know where - wouldn't be ok to move this behaviour to exception/error? (if not, why?) Guille

March 8, 2012

Re: [Pharo-project] more Nautilus feed back

by Benjamin

On Mar 8, 2012, at 8:25 PM, Esteban Lorenzano wrote: > Hi, > > I'm using Nautilus for my current projects since... well... couple of days, and I have some feedback: > > (yeah... maybe they are dumb reports, but that's because you did a great work with nautilus, I just have some really small observations :) > > 1) OB had double-click action: show hierarchy. I miss it a lot :( If you activate the "open a class on hierarchy" setting, it does the same :) > Also, hierarchy button is too far away when I want to see the hierarchy... ok, if you don't want to add double click functionality... can it be a menu option? (show hierarchy (h)) Maybe I should switch the group button and the hierarchy button. It will make more sense :) > Even worst: it swaps panels which is very confusing... but that leads to point 2 :) There are some good arguments to do that :) But I am quite fed up to tell them again and again ^^ > 2) swap panel configuration is not working for me in latest pharo 1.4 Ie ? > 3) I find "Class", "Instance" buttons very confusing. I liked more the older solution but well, I understand you want to improve visibility of comments, but then, I think class button would be better as a "toggle" button (those buttons who stays pressed) Do you have an example of such a button ? > 4) bold for class side method and categories is too strong, I don't see any reason for that, we have panel titles and future ;) toggle button to know which side is. Some people (Laurent not toell who) complain about the lack of visibility. And indeed, I found than when you have multiples browsers, it helps a lot to find where you are in a second. > 5) OB had a #browserIcon method on classes who changed class icon on browser. This is really useful for knowing different types/hierarchies like errors, announcements, morphs, etc. Again, this collides with "uncommented" icon, but I would like to have them back... There are icons for Morph/Erros/Announcements/Magnitude/String/Collection/etc... But maybe I could also add a mechanism to let each class defines it's own icon. > 6) I'm sorry for saying this, but I don't like the icons, nor the colored options (source, bytecode, decompiled, etc.) at the side. I would prefer a combo on button panel... and better looking icons (yes Stef, FamFam icons is ok :) I will be really glad to use yours :) You know, I am kind of a programmer. It means that making icons is not my work. And due to that, it takes me ages to do them. I have no problem to change them at all, but I really don't have time to do them. > 7) Why we have a button panel (which is in fact a toolbar) in the middle of the browser and not where it belongs: on top? this is a remain of OB, who took this from old Browser... but conceptually (as in usability terms), this is a not-good solution. We could think on change this and place the button bar where it belongs (and add some cool keybindings too) You can't say that the hierarchy button is to far, and ask for putting the toolbar on top ^^ It's here because it's close to the lists (where you spend 20% of your time) and also close to the source code (where you spend 80% of your time). > 8) different sized buttons are a really bad concept. Yes... in Smalltalk this is very common: to create buttons with the size of text... but this is bad design because disrupts harmony, and that hurts to the eyes... and when something hurts, you try not to use it :) I can't agree more. But buttons are kind of a pain in the ass (because they are embedded into a group morph with its own layout etc). As soon as I can set vResizing: #rigid; hResizing: #rigid, I'll do it for sure ^^ > > yeah.. most of my observations are also for any other tool we have, and most are about usability... I humbly recommend (for all people doing GUIs), the lecture of this book: http://en.wikipedia.org/wiki/Don't_Make_Me_Think. It is for web design, but is also a great guide when you want to make things people like. > > (Also, reading apple design guide is a good way to notice some interesting things... those guys had invest an insanely amount of time and money in development them) > I will try to find time to read them, but as I said, my exams are in 11 days so ;) Thanks for the feedback :) Ben > best, > Esteban >

March 8, 2012

Re: [Pharo-project] GSoC: ARM jitter for Squeak VM

by Eliot Miranda

On Thu, Mar 8, 2012 at 1:20 PM, Nick Ager <nick.ager(a)gmail.com> wrote: > Hi Elliot, > > I'm probably the least qualified of the people who have responded so far - > but if at all possible I'd love to try and help. > You're welcome too. > If you want something to do now, the first thing to do is to produce an >> ARM simulator plugin, analogous to the Bochs simulator. The first thing to >> do is go out and find a suitable software simulator, written in either C or >> C++ (cuz these suit the plugin compilation system) and play with it, >> configuring an ARM and running some simple assembler on it. >> > > In terms of ARM emulators a popular one seems to be QEMU [1] - the Android > simulator uses it. > Right, but this one is unsuitable because it does dynamic translation. Because the Squeak VM has a moving garbage collector and because, when simulating, the entire Cog heap, including generated machine-code, lives in a single ByteArray, the machine code generated by Cog, when simulating, can move. So the interface between the processor simulator and the generated machine code and memory must be based on virtual addresses. I'm pretty certain that a JIT like QEMU will use real addresses and so its own code generation would get confused by any movements of the Cog heap ByteArray. Hence it is I think better to stick with a simple interpretive simulator such as the Armulator <http://en.wikipedia.org/wiki/ARMulator>, and of course Bochs <http://en.wikipedia.org/wiki/Bochs>. BTW, the ARM is so simple that the core instruction set simulator in the ARM is only 1500 lines of C++ (including whitespace). So another approach might be to implement ARM in Smalltalk, e.g. by back-porting the Armulator code, although I expect it'll be significantly slower than optimized C++. > > Cheers > > Nick > > [1] http://en.wikipedia.org/wiki/QEMU > -- best, Eliot

March 8, 2012

Re: [Pharo-project] GSoC: ARM jitter for Squeak VM

by Nick Ager

Hi Elliot, I'm probably the least qualified of the people who have responded so far - but if at all possible I'd love to try and help. If you want something to do now, the first thing to do is to produce an ARM > simulator plugin, analogous to the Bochs simulator. The first thing to do > is go out and find a suitable software simulator, written in either C or > C++ (cuz these suit the plugin compilation system) and play with it, > configuring an ARM and running some simple assembler on it. > In terms of ARM emulators a popular one seems to be QEMU [1] - the Android simulator uses it. Cheers Nick [1] http://en.wikipedia.org/wiki/QEMU

March 8, 2012

[Pharo-project] more Nautilus feed back

by Esteban Lorenzano

Hi, I'm using Nautilus for my current projects since... well... couple of days, and I have some feedback: (yeah... maybe they are dumb reports, but that's because you did a great work with nautilus, I just have some really small observations :) 1) OB had double-click action: show hierarchy. I miss it a lot :( Also, hierarchy button is too far away when I want to see the hierarchy... ok, if you don't want to add double click functionality... can it be a menu option? (show hierarchy (h)) Even worst: it swaps panels which is very confusing... but that leads to point 2 :) 2) swap panel configuration is not working for me in latest pharo 1.4 3) I find "Class", "Instance" buttons very confusing. I liked more the older solution but well, I understand you want to improve visibility of comments, but then, I think class button would be better as a "toggle" button (those buttons who stays pressed) 4) bold for class side method and categories is too strong, I don't see any reason for that, we have panel titles and future ;) toggle button to know which side is. 5) OB had a #browserIcon method on classes who changed class icon on browser. This is really useful for knowing different types/hierarchies like errors, announcements, morphs, etc. Again, this collides with "uncommented" icon, but I would like to have them back... 6) I'm sorry for saying this, but I don't like the icons, nor the colored options (source, bytecode, decompiled, etc.) at the side. I would prefer a combo on button panel... and better looking icons (yes Stef, FamFam icons is ok :) 7) Why we have a button panel (which is in fact a toolbar) in the middle of the browser and not where it belongs: on top? this is a remain of OB, who took this from old Browser... but conceptually (as in usability terms), this is a not-good solution. We could think on change this and place the button bar where it belongs (and add some cool keybindings too) 8) different sized buttons are a really bad concept. Yes... in Smalltalk this is very common: to create buttons with the size of text... but this is bad design because disrupts harmony, and that hurts to the eyes... and when something hurts, you try not to use it :) yeah.. most of my observations are also for any other tool we have, and most are about usability... I humbly recommend (for all people doing GUIs), the lecture of this book: http://en.wikipedia.org/wiki/Don't_Make_Me_Think. It is for web design, but is also a great guide when you want to make things people like. (Also, reading apple design guide is a good way to notice some interesting things... those guys had invest an insanely amount of time and money in development them) best, Esteban

March 8, 2012

[Pharo-project] vmPath vs vmFullPath

by Camillo Bruni

What are these two methods / primitives supposed to return? Under OSX StackVM StackInterpreter VMMaker-oscog-EstebanLorenzano.139 I get the following: Smalltalk vmFullPath '/Applications/StackVM.app' Smalltalk vmPath '/Applications/StackVM.app/' according to the comments I should get the following Smalltalk vmFullPath '/Applications/StackVM.app/Contents/MacOS/StackVM' Smalltalk vmPath '/Applications/' or as well the quirky '/Applications/StackVM.app/Contents/MacOS/' As far as we understand vmPath should be the place where you go and look for the PharoV10.sources file, meaning the second option does not make a lot of sense here... best cami + damien

March 8, 2012

Re: [Pharo-project] Adding a statement programmatically

by Sean P. DeNigris

Norbert Hartl wrote > > Try... Thanks Norbert. Same result. -- View this message in context: http://forum.world.st/Adding-a-statement-programmatically-tp4454447p4457352… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 8, 2012

Re: [Pharo-project] GSoC: ARM jitter for Squeak VM

by Eliot Miranda

Hi Krish, Hi Esteban, On Thu, Mar 8, 2012 at 9:17 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > Let me know if I can help in any way.. on this.. On Thu, Mar 8, 2012 at 9:22 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > I would really like to co-mentor something like this... but I presume I > have more things to learn than to teach :) > > anyway, if there is a place to help, count me in. > > Esteban > you are both most welcome. i will definitely involve you. If you want something to do now, the first thing to do is to produce an ARM simulator plugin, analogous to the Bochs simulator. The first thing to do is go out and find a suitable software simulator, written in either C or C++ (cuz these suit the plugin compilation system) and play with it, configuring an ARM and running some simple assembler on it. Once that's working you can write a plugin, and an Alien interface a la BochsIA32Plugin and BochsIA32Alien. You can find tests you could use as a model in source.squeak.org/VMMaker/Cog-Processors-Tests BochsIA32AlienTests. e.g. testNFib16 runs machine code that implements NFib (same as benchFib). this is exciting! cheers! > El 08/03/2012, a las 8:07a.m., Nick Ager escribiÃ³: > > Here's hoping that in a similar way to Yanni and the ePUB proposal and > someone will jump in and say that they are already working on this. > > Quoting Eliot: > > It's not overambitious for someone good. And I'd love to see it happen. >> But finding time to be a mentor has proven difficult for me in the past. >> I'd happily be part-mentor, but I need someone to at least help in the >> GSoC process... > > > > so if there is anyone out there that can help Eliot and Igor with > mentoring or the GSoC process, jump in and offer support. > > The proposal: > > ----- > > Name: ARM jitter for Squeak VM > Level: Advanced > Possible mentor: Eliot Miranda > Possible second mentor: Igor Stasenko > > Description > The Squeak VM is the dynamic virtual machine used for many open-source > software projects such as Scratch [1], eToys [2], Pharo [3], the Newspeak > language [4], the innovative web framework Seaside [5] and many others. > CogVM [6] is a development of the Squeak VM which adds a powerful Intel x86 > JITer [7]. The CogVM JIT has significantly improved the performance of the > open-source Smalltalk projects which have adapted to use it. > Increasingly low cost highly capable ARM hardware such as the Raspberry Pi > [8] and the Beagle Board [9] have become widely available. In addition the > new version of the one-laptop-per-child is based on the ARM platform [10]. > The Squeak VM compiles for ARM platforms, but currently there is no JIT on > ARM platforms, significantly decreasing the performance of popular software > on ARM. The goal of this project is to add simple ARM JITTing capability to > the CogVM. > > [1] http://scratch.mit.edu/ > [2] http://www.squeakland.org/about/intro/ > [3] http://www.pharo-project.org > [4] http://newspeaklanguage.org/ > [5] http://seaside.st/ > [6] http://gitorious.org/cogvm > [7] http://en.wikipedia.org/wiki/Just-in-time_compilation > [8] http://www.raspberrypi.org/ > [9] http://beagleboard.org/bone > [10] http://one.laptop.org/about/xo-3 > > Technical Details > The work would require a interest in virtual machine optimisation, some > knowledge of Intel x86 and ARM assembler and knowledge of C and dynamic > languages. > The Squeak and Cog VM are written in a simplified subset of Smalltalk > known as slang [11] - which then generates C output and forms the basis of > the VM. > As the Squeak VM is a Smalltalk program, it is developed in Smalltalk, and > the Cog JIT is no exception. The VM, including the JIT, is written in > Smalltalk and run in the context of the Smalltalk IDE, but the JIT still > generates machine-code that must be evaluated within the Smalltalk > environment. On x86 is done by interfacing to an x86 simulator library > derived from the Bochs x86/x86-64 PC simulator, written in C++. > Implementing the ARM port should be no different. The first task will be > to choose and interface to a suitable ARM simualtor/emulator. Once this is > working, the ARM code generator can be incrementally developed within > Smalltalk. Finally once the simulator is fully functional one can get down > and dirty with an actual physical ARM machine - such as the Raspberry Pi or > Beagle Board. > [11] http://wiki.squeak.org/squeak/2267 > > > Benefits to the Student > The student will gain an in-depth knowledge of virtual machine > optimisation, working in a productive innovative environment - it's > great fun to be able to implement a JIT in a safe high-level dynamic > language, instead of the traditional route of developing in C/C++ and > debugging in GDB. > The student will have the satisfaction of seeing performance gains for a > range of high-profile projects which use the Squeak VM on ARM. > > Benefits to the Community > The Smalltalk community will gain an initial implementation of an ARM > Jitter which can then be further developed along-side the x86 dynamic > translation work. An ARM Jitter for the CogVM will improve the performance > of many notable open-source projects on low-cost ARM hardware, bringing > innovative software and development environments to wider community. > > ---- > > Cheers > > Nick > > > -- best, Eliot

March 8, 2012