February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] shout and Pharo 1.2 or 1.3

by Hilaire Fernandes

I have been reading the related discussion in the bug tracker. It is not clear to me if finally shout will eventually work with 1.2. I am going to prepare a DrGeo public release where I want shout, I am wondering if I should just use early 1.3 Pharo to do (where shout works nicely). Are there any reason or pitfall I should be aware of before doing so? Thanks hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Levente Uzonyi

On Sun, 13 Feb 2011, Igor Stasenko wrote: > On 13 February 2011 02:58, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Sun, 13 Feb 2011, Igor Stasenko wrote: >> >>> Please read the Ian's paper about switch statement vs message sends.. >>> You will discover something surprising for you. >> >> Link please? That's C's switch statement (whose performance depends on the compiler, the structure of the cases, etc.) compared to inline caching? I don't see how is it relevant to #caseOf:? Levente >> >> > Here: > > www.piumarta.com/pepsi/objmodel.pdf- > > ------------------- > > Lastly, we implemented the example presented in Section > 2 of this paper: data structures suitable for a Lisp-like > language. We implemented a ËËtraditionalËË length primitive > using a switch on an integer tag to select the appropriate > implementation amongst a set of possible case labels. > This was compared with an implementation in which data > was stored using our object model and the length primitive > used send to invoke a method in the objects themselves.7 > Both were run for one million iterations on forty objects, ten > each of the four types that support the length operation. > The results, with varying degrees of object model optimisations > enabled, were: > > implementation time % of switch > switch-based 503 ms 100.0% > dynamic object-based 722 ms 69.7% > + global cache 557 ms 90.3% > + inline cache 243 ms 207.0% > > This shows that an , object-based implementation > can perform at better than half the speed of a typical C implementation > for a simple language primitive. With a global > method cache (constant overhead, no matter how many > method invocation sites exist) the performance is within > 10% of optimised C. When the inline cache was enabled > the performance was better than twice that of optimised C. > --------------------- > > > >> Levente >> >>> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 13 February 2011 09:05, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > I also think we do not need caseOf: in the default distribution. > > It is probably useful for some cases (like dealing with integers from some external source as mentioned by Levente), but those cases are so rare that we should not affect everyone with this message. > Yes, i know the case where its useful: it used by VMMaker code generator, which translating caseOf: to C switch statement :) > Cheers, > Doru > > > On 13 Feb 2011, at 08:57, StÃ©phane Ducasse wrote: > >> Hi ricardo, igor and levente >> >> I really want to remove caseOf: since years. >> Why: >> Â Â Â - conceptually wrong (even if this may be nice to have for $A and numbers) >> Â Â Â - to me it looks like coming from another age >> Â Â Â - never needs to use it: of course other people may of course >> Â Â Â - Three less methods in Object >> Â Â Â - only available in Squeak/Pharo >> Â Â Â - but more more more important: >> Â Â Â Â Â Â Â makes the compiler, decompiler, inliner....., more complex. >> Â Â Â I want opal to get out because we need a better infrastructure: simpler, better compiler. >> Â Â Â - Ideally I would prefer that we can extend the compiler with it and that people needed it just ship a plugin with >> Â Â Â their code. >> >> Marcus is opal dealing with caseOf:? >> >> I did not want to have a war. I thought that it was pretty obvious that we do not really need that. >> >> Stef >> >>> Ok, guys... I'm sorry to interrupt this polite discussion, but this is taking nowhere. Having such strong arguments (for or against) is not helpful for anybody. >>> We all know using #caseOf:otherwise: it's not exactly good style, but sometimes you need to compromise between design and efficiency, and having simple and efficient constructs such as #caseOf: is very good IMHO. >>> You are free to avoid them if your projects don't need it, and if you happen to need extra performance you can always build your own JIT, right? :) >>> But please don't ban people who are willing to sacrifice a little readability for performance reasons. Thanks. >>> >>> Best regards. >>> Richo >> >> > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 13, 2011

Re: [Pharo-project] A new GUI visual designer

by Norbert Hartl

On 12.02.2011, at 19:13, Esteban Lorenzano wrote: > No, I don't believe anything except smalltalk is bad. Just XML. I worked with Java, C# and a lot of XML to know that. > Don't be confused... I'm not talking against XML alternatives because of microsoft or anything, I have serious technical complains against it. Also, XUL is not microsoft's and I'm opposing to it as strongly as XAML (but Seaside-XUL is cool, he). > Esteban, it doesn't matter to me _why_ you are arguing like you do. I'm interested in hearing _what_ you have to say. Stating that you have a lot of experience (I have no doubt about it) and that you have good reasons does not make me believe/being convinced in any way. Just tell some of your good reasons so I can get anything from it. > Said so... i'm not against build an XAML importer or so, but I think you'll find a lot of several issues to solve, and it will maybe impossible :) > why? > <Spanish here> (yeah... bad joke) > AdemÃ¡s... no lo defiendo porque crea que Smalltalk es mejor siempre, solo que en este caso, es mucho mejor que usar XML. > Trabajo en la industria desde hace 18 aÃ±os y solo hace 4 con Smalltalk, y ademÃ¡s todavÃa hoy trabajo haciendo consultorÃa de arquitectura de proyectos hechos en Java o C#... se perfectamente de que estoy hablando... no estoy en contra ni de Oracle ni de Microsoft... simplemente, creo que usar XML es una mala alternativa, no te vayas por las ramas, plis :) > </Spanish here> > Well, my understanding of this is probably of the level of reading a french text :) Norbert > Cheers, > Esteban > > El 12/02/2011, a las 2:59p.m., nullPointer escribiÃ³: > >> >> Create the UI with plain Smalltalk code have problems... my UIBuilder use >> that system and have limitations for limit of lityerals in a spec method, >> and other problems. >> >> Another alternative is the VW or Smalltalk/X mechanism, no readable, no >> updatable; only could be modified for the same designer routine. >> >> XAML is a standard (or XUL). Allow define the UI, but too allow define >> bindings, templates, commands etc for work with the >> controller/presenter/viewmodel. For do the same in any language, with plain >> code, you need much more code lines. A example with only a textbox and a >> label donÂ´t works. Try build a view with three grids, many fields, bindings, >> events, tranmsformations, styles... and then compare the number of code >> lines from a way and another. And compare too the readable result...!!! >> >> And is possible create it with external designers; a Smalltalk designer is >> not needed. Only a XAML reader-builder is needed, and a set of widgets for >> work of that way. >> >> Ahhhhh! I see the problem!!!. Now I see. ItÂ´s a Microsoft product, then >> anyway is bad. >> >> Los programadores de Smalltalk, somos cangrejos ermitaÃ±os. Estamos tan >> acostumbrados a pensar que somos lo mejor y tenemos la mejor herramienta que >> nos hemos quedado anquilosados. Estoy hasta las pelotas de esta mentalidad. >> Lo digo en castellano porque no sÃ© expresarlo en inglÃ©s. >> >> Regards. >> -- >> View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302962.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by StÃ©phane Ducasse

You got the process :) I like that we really discuss (because sometimes I'm wrong and I have no problem to change my mind :) I reminded me the discussion we got two yeras ago about number and nicolas convinced me that his approach was good about float (not been mathematical numbers). Stef On Feb 13, 2011, at 11:58 AM, Alain Plantec wrote: > Le 13/02/2011 04:05, Ricardo Moran a Ã©crit : >> Ok, guys... I'm sorry to interrupt this polite discussion, but this is taking nowhere. > no, it allows people to make their own opinion. > interesting thread. > > Now I can say that I would be more for getting rid of case of. > > thanks > Alain > > >

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Alain Plantec

Le 13/02/2011 04:05, Ricardo Moran a Ã©crit : > Ok, guys... I'm sorry to interrupt this polite discussion, but this is > taking nowhere. no, it allows people to make their own opinion. interesting thread. Now I can say that I would be more for getting rid of case of. thanks Alain

Feb. 13, 2011

Re: [Pharo-project] [Hudson] Cog Unix build

by Tudor Girba

Great job! Doru On 13 Feb 2011, at 09:56, Sven Van Caekenberghe wrote: > > On 12 Feb 2011, at 23:19, Igor Stasenko wrote: > >> Yes. i found the issue. Now it runs!!! :) >> >> And i were able to run all tests in pharo 1.3 core image on StackVM: >> >> 7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 >> unexpected passes >> >> no more crashes! :) > > That is really great and very impressive as well ! > > Sven > > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Sven Van Caekenberghe

On 12 Feb 2011, at 18:41, Levente Uzonyi wrote: > ~27x slowdown in this case. I personally never heard of #caseOf:otherwise ! It feels like a hack that is not often needed. If after writing correct code you need to optimize integer/byte handling, there are many solutions, check any book on algorithms, most of them are using table dispatch. Another problem in your benchmark is that you keep the creation of the dynamic array inside the code to measure, while in the compiler primitive case it is of course compiled away, that alone makes a huge difference: (timings on my machine) [ 1 to: 10 do: [ :each | each caseOf: { [ 1 ] -> [ $a ]. [ 2 ] -> [ $b ]. [ 3 ] -> [ $c ]. [ 4 ] -> [ $d ]. [ 5 ] -> [ $e ] } otherwise: [ $x ] ] ] bench. '8,920,000 per second.' [ 1 to: 10 do: [ :each | ({ [ 1 ] -> [ $a ]. [ 2 ] -> [ $b ]. [ 3 ] -> [ $c ]. [ 4 ] -> [ $d ]. [ 5 ] -> [ $e ] } detect: [ :ea | ea key value = each ] ifNone: [ [ $x ] ]) value ] ] bench. '70,600 per second.' | actions | actions := { [ $a ]. [ $b ]. [ $c ]. [ $d ]. [ $e ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. }. [ 1 to: 10 do: [ :each | (actions at: each) value ] ] bench. '3,230,000 per second.' | letters | letters := 'abcdexxxxx'. [ 1 to: 10 do: [ :each | letters at: each ] ] bench. '8,930,000 per second.' If other Smalltalks can live without it, so can we. Sven

Feb. 13, 2011

Re: [Pharo-project] DrGeo in success stories

by Hilaire Fernandes

Thanks Laurent! With the re-introduction of programming/algorithm in senior high school in the French educative system, mathematics teacher are in charge of this teching. Natturally these teachers prefer a math oriented programming language. Software like Dr. Geo with programming power tools is very neat. Indeed, I am in touch with a French math teacher exploring all the features offered by DrGeo in user programming. This teacher explored Smalltalk and DrGeo internal and wrote several articles http://fr.wikibooks.org/wiki/Programmation_objet_et_g%C3%A9om%C3%A9trie He also wrote an article on DrGeo in a math teacher publication http://revue.sesamath.net/spip.php?article330 Therefore for the next DrGeo release, hopefully in March, I will open a bit more the Smalltalk programming facilities with a DrGeo world menu giving access to Browser, Worspace, Find tool, Transcript and Save session. With the feedback of this teacher I already improved a lit bit DrGeo in fundamental area - See this article explaining the idea of user power tools and recent enhancement of DrGeo user script with block closure http://blog.ofset.org/hilaire/index.php?post/2011/02/12/Dr.-Geo-and-block-c… To help teacher to catch these power tools I rewrote the DrGeo II documentation with a full description of the Smalltalk scripting http://documentation.ofset.org/drgeo2/fr. These doc is only written in French because I can't achieve an English writing level good enough for English native speaking teachers. But translators are very welcome. If you know any math or programming teachers, please speak about Dr.Geo and forward this message. Oh, by the way, the user programming feature was sponsored by ESUG to promote Smalltalk. Thanks ESUG! It was a good investment! Hilaire Le 13/02/2011 09:41, laurent laffont a Ã©crit : > Added. http://pharo-project.org/about/success-stories > > > Laurent > > On Sat, Feb 12, 2011 at 7:02 PM, Hilaire Fernandes > <hilaire.fernandes(a)gmail.com > <mailto:hilaire.fernandes@gmail.com>> wrote: > > Le 12/02/2011 18:40, laurent laffont a Ã©crit : > > I take the description on http://community.ofset.org/index.php/DrGeo ? > > > > Do you how many schools / teachers use it approximatively ? > > > > > > For Free software you never know. > In youtube there are videos produced by teacher, mainly spanish speaking > one. > > > Hilaire > > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > > -- Education 0.2 -- http://blog.ofset.org/hilaire

Feb. 13, 2011

Re: [Pharo-project] [Hudson] Cog Unix build

by Sven Van Caekenberghe

On 12 Feb 2011, at 23:19, Igor Stasenko wrote: > Yes. i found the issue. Now it runs!!! :) > > And i were able to run all tests in pharo 1.3 core image on StackVM: > > 7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 > unexpected passes > > no more crashes! :) That is really great and very impressive as well ! Sven

Feb. 13, 2011