December 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] new Cog VMs

by Eliot Miranda

Hi All, I've released a new version of Cog that has a substantially improved code generator along the lines of Peter Deutsch's HPS (VisualWorks) and various of Ian Piumarta's VMs. These all use a simple tecnique to identify constant references in bytecode and to support a register-based calling convention. While this does produce faster code it tends to accelerate low-level code much more than high-level code as you can see by the following benchmarks: SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 192 - 691 / 6.91 -72% SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 sends/sec' StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; 128157989 sends/sec' 931756141 - 753495217 / 7534952.17 -24% 128157989 - 64769127 / 647691.27 -98% SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no transcript StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no transcript) 43406 - 47013 / 470.13 -7.67234594686576 The status of this code is essentially beta. The test suite runs the same on the new code generator as on the old, but I think there are still bugs because I get the occasional transient error. I am therefore very interested in any reproducible errors you can find. The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few other important changes: - a bug fix to bytecode<->native pc mappng that produced incorrect results for methods containing blocks with ^-returns in them. One symptom is incorrect highlighting of the pc in the debugger, althoguh symptoms could be much serious. - jitting interpreted methods on backward branches. Currently any interpreted method that performs more than 20 backward branches will be considered for JIT compilation and if it is suitable (default, <= 60 literals) will be compiled to native code. - new callback support. I need to commit some changes to the Alien package to provide access to this but essentially the VM's callback support is now able to be ported to architectures with register-based calling conventions (ARM, PowerPC, SPARC etc). I'll try and get the Alien code released soon, and to back-port the changes to the standard VM before the end of the holiday. One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. Apologies. I'll try and get a fix for this before the end of the holidays too, but time might be too tight. There are other priorities such as harmonising the standard and Cog VMs for the 4.2 release. best Eliot

Dec. 31, 2010

Re: [Pharo-project] realized and learned something today :)

by csrabak＠bol.com.br

Em 30/12/2010 19:56, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > Hi guys > I think that over the years I (but also many of you, I know) tried > to expose newbies to smalltalk or our culture. And often we get bad > reactions, bad windows, bad colors, slow, why not in svn, ..... I Those specific reactions are more likely to be about Squeak of Pharo than Smalltalk in general, isn't? > think that showing Smalltalk to newbies is the best we can do to > ourselves, not really to attract new people but also to get a large > kick in the %^&* because most of the time students are not stupid, > they are exposed to other technos. Yes. They make an excellent litmus test without the risks of expending lots of money in the 'launching of product' which can become an Edsel of the programming languages... > So each time we believe we want > to show them something cool and they do not really consider it as > cool as we believe, we can of course think that they are idiot (some > of them are) but most of the time we can also think that may be we > stayed too long in our little boxes and the world moved (interfaced > well with c, fast, cool frameworks, has cool tools, processes > (integration...), cool UIs, web stuff.....). Indeed. > So each time we get > down because we do not see the little flame opening in the yes of > the others we can think hard and get from them what we missed. I believe this is the first step to get the best direction to follow. > I really happy to get exposed to student acid tests, this is a > valuable feedback and I wanted to share that with you. Stef, now comes the rub: do you think it is possible to systematize the lessons learned and post a summary for us here? Perhaps we should open a specific Wiki page on this? Regards, -- Cesar Rabak

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by John McIntosh

Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask. On 12/30/10, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Hopefully that can eventually be said as "backward compatibility with good > stuff is a priority for Pharo." Moving targets are perhaps best left > moving for now. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi > [leves(a)elte.hu] > Sent: Thursday, December 30, 2010 6:13 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported > > (or so) which is unrelated. The method was removed during a "cleanup". And > as you know, backwards compatibility is not a priority for Pharo. > > > Levente > > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Schwab,Wilhelm K

Hopefully that can eventually be said as "backward compatibility with good stuff is a priority for Pharo." Moving targets are perhaps best left moving for now. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Thursday, December 30, 2010 6:13 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported (or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo. Levente

Dec. 31, 2010

[Pharo-project] UI for Shortcuts [WAS: Which Keymaps/Shortcuts do we want to have?]

by Guillermo Polito

Hi, I would like to discuss the UI for shortcuts and not to impose it :). So.. I was exploring the Idea of configuring the shortcuts in settings as the screenshot shows. What do you think of that? I don't think we need a separated tool to configure shortcuts. Settings look ok. Tomorrow I'll be putting a lot of effort on it ;). Cheers! On Mon, Dec 27, 2010 at 6:53 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Dec 27, 2010 at 12:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> I also would like a cmd+f: search anything... but that needs also an >> application (like algernon, which I'm currently not supporting anymore due >> time issues), not just a command :( >> well, at least a cmd+f: search class would be fine :) >> > > +1 > It sound like a good project for someone with time and wanting to learn :) > > >> >> El 27/12/2010, a las 5:38a.m., StÃ©phane Ducasse escribiÃ³: >> >> > I suggest that you define lists = >> > >> > simple eamcs bindings = >> > ctral a ctrle >> > >> > Windows manipulation >> > cmd W >> > ... >> > >> > Your special binding >> > >> > >> > Then you should have contexts >> > World >> > TextMorph >> > Editor only >> > >> > (of course some list will only be able to be attached to a given >> object programmatically >> > example: for botsinc I wanted specific binding to that morph class >> only -- but you do not care) >> > >> > then a config is >> > >> > (lists, lists) context >> > (mybinding, lists, lists) context >> > >> > where , make sure that mybinding take precedence >> > >> > >> > Does it make sense? >> > >> > Stef >> > >> > >> > >> > On Dec 27, 2010, at 2:37 AM, Guillermo Polito wrote: >> > >> >> What about something like the attach? >> >> >> >> On Sun, Dec 26, 2010 at 7:45 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >> Wow, haha, this is wonderful! So, putting some order: >> >> >> >> 1) shortcuts published as settings with a default? Will that be ok? >> This make me think the following: >> >> - how to share shortcuts. Files? Keymapping used to use SIXX, but >> maybe it is not suitable for a light solution (I don't know much about SIXX) >> >> - downloading a new image (or a new version of a package with >> shortcuts) could make us lose our own-defined shortcuts. >> >> >> >> 2) support for the following shortcuts: >> >> >> >> - a shortcut to bring up the wolrd menu. Not sure which shortcut. >> >> - use ctrl + tab to switch between windows instead of cmd + arrows >> >> - a shortcut for what it is (hidden) now with cmd + shift + click >> (list of opened windows) >> >> - Shortcuts for opening standard tools: Workspace, Transcript, >> TestRunner, etc. >> >> - Shortcut for duplicating a windows >> >> - a shortcut for saving the image (cmd+ shoft + s ?) >> >> - a shortcut for quitting the image with and without saving >> >> - a shortcut to see a list of shortcuts >> >> >> >> I would like to add some more items to #2, and to define the keys that >> triggers them. >> >> #1 seems to be of some work :). I'll work on it ASAP. >> >> >> >> Step by step, as Stef and Mostaza Merlo says :). >> >> >> >> Cheers! >> >> Guille >> >> >> >> >> >> On Sun, Dec 26, 2010 at 7:18 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >> + 1 :) >> >> And save them as configuration >> >> >> >>> On Sun, Dec 26, 2010 at 1:13 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >>> my wishlist: >> >>> >> >>> - a shortcut to see all available shortcuts and change them >> >>> >> >>> + a lot >> >> >> >> >> >> >> >> >> >> <PharoScreenshot.2.png> >> > >> > >> >> >> >

Dec. 30, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Igor Stasenko

2010/12/31 Levente Uzonyi <leves(a)elte.hu>: > On Thu, 30 Dec 2010, Igor Stasenko wrote: > >> On 30 December 2010 23:11, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> As I port code from Sophie, I keep running into >>> WeakArray>>isFinalizationSupported calls. >> >> This is strange.. >> this code was introduced only since Pharo 1.2 >> and Squeak 4.2 images jut couple of months ago. >> And of course, Pharo 1.1 images, Â where you porting know nothing about >> this method. >> >> You can patch Pharo 1.1. by putting >> WeakArray>>isFinalizationSupported >> ^ false >> in this method. >> >> But i don't understand what you doing... how it could happen that >> Sophie knows about (and using) this recently introduced code? >> >> Or perhaps you trying to port Collections-Weak? which i would not >> recommend to do, >> because it is a part of Kernel. > > You are mixing the methods. #isFinalizationSupported used to answer what > it's name suggests: "does the VM support any form of finalization?". What > you're thinking about is WeakFinalizationList class >> #hasNewFinalization > (or so) which is unrelated. The method was removed during a "cleanup". And > as you know, backwards compatibility is not a priority for Pharo. > > Ah... phew.. sorry for confusion :) > Levente > >> >> >>> >>> Why was this method removed from Pharo? Â I want to make sure I understand >>> what I'm doing when I remove these calls. >>> >>> Thanks. >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.h… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > -- Best regards, Igor Stasenko AKA sig.

Dec. 30, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Levente Uzonyi

On Thu, 30 Dec 2010, Igor Stasenko wrote: > On 30 December 2010 23:11, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> As I port code from Sophie, I keep running into >> WeakArray>>isFinalizationSupported calls. > > This is strange.. > this code was introduced only since Pharo 1.2 > and Squeak 4.2 images jut couple of months ago. > And of course, Pharo 1.1 images, where you porting know nothing about > this method. > > You can patch Pharo 1.1. by putting > WeakArray>>isFinalizationSupported > ^ false > in this method. > > But i don't understand what you doing... how it could happen that > Sophie knows about (and using) this recently introduced code? > > Or perhaps you trying to port Collections-Weak? which i would not > recommend to do, > because it is a part of Kernel. You are mixing the methods. #isFinalizationSupported used to answer what it's name suggests: "does the VM support any form of finalization?". What you're thinking about is WeakFinalizationList class >> #hasNewFinalization (or so) which is unrelated. The method was removed during a "cleanup". And as you know, backwards compatibility is not a priority for Pharo. Levente > > >> >> Why was this method removed from Pharo? Â I want to make sure I understand >> what I'm doing when I remove these calls. >> >> Thanks. >> Sean >> -- >> View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.h… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 30, 2010

Re: [Pharo-project] realized and learned something today :)

by StÃ©phane Ducasse

Thanks janko. We should pay attention to get old guys in a private club sure that we understand everything when kids are ruling the world out there. Let us the kids kick our truth, we will just get more credible and stronger. Stef On Dec 30, 2010, at 11:11 PM, Janko MivÅ¡ek wrote: > Stef, very true, I agree 100% > > Janko > > On 30. 12. 2010 22:56, StÃ©phane Ducasse wrote: >> Hi guys >> >> I think that over the years I (but also many of you, I know) tried to expose newbies to smalltalk or our culture. >> And often we get bad reactions, bad windows, bad colors, slow, why not in svn, ..... >> I think that showing Smalltalk to newbies is the best we can do to ourselves, not really to attract new people >> but also to get a large kick in the %^&* because most of the time students are not stupid, they are exposed to >> other technos. So each time we believe we want to show them something cool and they do not really >> consider it as cool as we believe, we can of course think that they are idiot (some of them are) but >> most of the time we can also think that may be we stayed too long in our little boxes and the world >> moved (interfaced well with c, fast, cool frameworks, has cool tools, processes (integration...), cool UIs, web stuff.....). >> So each time we get down because we do not see the little flame opening in the yes of the others >> we can think hard and get from them what we missed. >> >> I really happy to get exposed to student acid tests, this is a valuable feedback and I wanted to share that with you. >> >> Stef >> > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Dec. 30, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Igor Stasenko

On 30 December 2010 23:11, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > As I port code from Sophie, I keep running into > WeakArray>>isFinalizationSupported calls. This is strange.. this code was introduced only since Pharo 1.2 and Squeak 4.2 images jut couple of months ago. And of course, Pharo 1.1 images, where you porting know nothing about this method. You can patch Pharo 1.1. by putting WeakArray>>isFinalizationSupported ^ false in this method. But i don't understand what you doing... how it could happen that Sophie knows about (and using) this recently introduced code? Or perhaps you trying to port Collections-Weak? which i would not recommend to do, because it is a part of Kernel. > > Why was this method removed from Pharo? Â I want to make sure I understand > what I'm doing when I remove these calls. > > Thanks. > Sean > -- > View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3168849.h… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

Dec. 30, 2010

Re: [Pharo-project] are we going to remove MethodFinder and MessagesNames for Pharo 1.2?

by csrabak＠bol.com.br

Em 29/12/2010 07:41, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: > > On Wed, Dec 29, 2010 at 10:18 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > > No preference plague. Now we will keep the tool in 1.2 and remove > > them in 1.3. > Ok, it is cool...but, as I said...image it is your first time you > open pharo...you will have THREE tools which looks similar. You > don't know its differences, nor which to use. And the menu is > starting to be long. I agree the menu is starting to be long, but see below. > Can we at least remove them from the menu as I suggested (not the > code) ? Poeple that prefer MessagesSend / MethodFInder know how > to put them back on the menu or open them by hand. Removing from the menu is a kind of 'selection' of a winner, so if we can agree which has to stay in the menu, let's agree also: 1) Code which is only accessible by 'connoisseurs' is better put in packages and those users could easily install them back if it is their wish; 2) People that prefer other tools and know how to put back in the menu should know how to install a package as well. Now, about the information about the differences or recommendations on what to use, I suggest be put in the Welcome workspace in a specific section/paragraph. > > > And we should bug fixes the new tool on the way. Yes this is essential. my 0.019999.... -- Cesar Rabak

Dec. 30, 2010