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

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

by Levente Uzonyi

On Sun, 13 Feb 2011, Igor Stasenko wrote: > Don't try to convince me that there are sort of problems which can be > solved only by using case statement :) We all know that it can be solved, but the solution won't be nicer at all, instead it will be a lot slower. > First, get rid of these integers in your code. Use symbolic names. > And then for dispatching using parameter, there is a #peform: primitive. The integers are from a binary stream, so I can't do much about it. > > So, then switch statement will be turned into: > > self peform: (self decode: someInteger) > > and this is how it should look like. > And again, if you can avoid using integers at all, use symbols , so > you don't have to decode/translate them. > Just do #perform. > > I thought that this is obvious for you. What you wrote here is obvious, but not an answer to my question. What should #decode: do? Use #detect:? Or a dictionary? Maybe a binary search on an array? Or should it be a bunch of #ifTrue:ifFalse: conditionals? (I guess the separate class per integer idea is abandoned, but who knows.) Also note that #perform:with: is ~11x slower on Cog than sending a message. And a send is a lot slower (~5.5x IIRC) than a direct assignment. That's ~55x combined slowdown not counting the integer->selector matching. Levente > >> >> Levente >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 12, 2011

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

by Igor Stasenko

On 13 February 2011 00:17, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 12 Feb 2011, Igor Stasenko wrote: > >> oh come on. Switch statement should live where it belongs to: C code. > > It's nothing like C's switch statement, and I'm sure you know that. > >> >> Why we should support this ridiculous syntax constructs in smalltalk? > > What's so ridiculous about it? > >> IMO: >> All users of such code should die. And i don't care if they are >> working fast or not.. >> This is plainly against the spirit of smalltalk. > > Okay, then enlighten me please, how one should rewrite the following > dispatch without #caseOf:? > > You have some integers: 0 83 67 77 68 72 80 112 113 87 70 82. When a > variable's value is equal to any of these, a predefined value has to be set > to an instance variable depending on the integer. The current code is like: > > foo caseOf: { > Â Â Â Â [ 0 ] -> [ var2 := x ]. > Â Â Â Â [ 83 ] -> [ var13 := x ]. > Â Â Â Â ... > > Should I use #detect: to find the variable? Or a dictionary? Maybe a binary > search on an array? Or a bunch of #ifTrue:ifFalse: conditionals? Maybe a > separate class for each variable and let the VM do the dispatch? > How should I set the value? With #perform:? Or #instVarAt:put:? > Don't try to convince me that there are sort of problems which can be solved only by using case statement :) First, get rid of these integers in your code. Use symbolic names. And then for dispatching using parameter, there is a #peform: primitive. So, then switch statement will be turned into: self peform: (self decode: someInteger) and this is how it should look like. And again, if you can avoid using integers at all, use symbols , so you don't have to decode/translate them. Just do #perform. I thought that this is obvious for you. > > Levente > -- Best regards, Igor Stasenko AKA sig.

Feb. 12, 2011

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

by Levente Uzonyi

On Sat, 12 Feb 2011, Igor Stasenko wrote: > oh come on. Switch statement should live where it belongs to: C code. It's nothing like C's switch statement, and I'm sure you know that. > > Why we should support this ridiculous syntax constructs in smalltalk? What's so ridiculous about it? > IMO: > All users of such code should die. And i don't care if they are > working fast or not.. > This is plainly against the spirit of smalltalk. Okay, then enlighten me please, how one should rewrite the following dispatch without #caseOf:? You have some integers: 0 83 67 77 68 72 80 112 113 87 70 82. When a variable's value is equal to any of these, a predefined value has to be set to an instance variable depending on the integer. The current code is like: foo caseOf: { [ 0 ] -> [ var2 := x ]. [ 83 ] -> [ var13 := x ]. ... Should I use #detect: to find the variable? Or a dictionary? Maybe a binary search on an array? Or a bunch of #ifTrue:ifFalse: conditionals? Maybe a separate class for each variable and let the VM do the dispatch? How should I set the value? With #perform:? Or #instVarAt:put:? Levente > >> >> Levente >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 12, 2011

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

by Igor Stasenko

On 12 February 2011 18:41, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 11 Feb 2011, stephane ducasse wrote: > >> Hi guys >> >> let us do another pass at cleaning and realigning the system. >> Could we agree to deprecate caseOf: and caseOf:otherwise:? >> it will simply the compiler, decompiler and also we do not need that at >> all. >> >> | z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. #b caseOf: z >> >> => >> "| z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. >> z detect: [:each | each key value = #b] " >> >> there is one user which I fixing right now. > > IMHO you shouldn't remove it. There are a lot more users of this method (16 > in the Pharo image I have and a lot more in external packages), but this > method is inlined by the compiler, so you won't see it in the senders list. > Try this instead: > > SystemNavigation default browseMethodsWithSourceString: 'caseOf:'. > > Using #detect: and #detect:ifNone: with a dynamically created array is a > _lot_ slower than the inlined #caseOf: and #caseOf:otherwise:. For example: > > [ 1 to: 10 do: [ :each | > Â Â Â Â each > Â Â Â Â Â Â Â Â caseOf: { > Â Â Â Â Â Â Â Â Â Â Â Â [ 1 ] -> [ $a ]. > Â Â Â Â Â Â Â Â Â Â Â Â [ 2 ] -> [ $b ]. > Â Â Â Â Â Â Â Â Â Â Â Â [ 3 ] -> [ $c ]. > Â Â Â Â Â Â Â Â Â Â Â Â [ 4 ] -> [ $d ]. > Â Â Â Â Â Â Â Â Â Â Â Â [ 5 ] -> [ $e ] } > Â Â Â Â Â Â Â Â otherwise: [ $x ] ] ] bench. > '1,790,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. > '66,600 per second.' > > ~27x slowdown in this case. > oh come on. Switch statement should live where it belongs to: C code. Why we should support this ridiculous syntax constructs in smalltalk? IMO: All users of such code should die. And i don't care if they are working fast or not.. This is plainly against the spirit of smalltalk. > > Levente > > -- Best regards, Igor Stasenko AKA sig.

Feb. 12, 2011

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

by Igor Stasenko

On 12 February 2011 18:38, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hudson news > ------------------ > > Cog Unix > > Â Â Â Â https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix%201.3/ > > This is using Igor's non-interactive build. Hudson does the following: > > git clone git://gitorious.org/~abrabapupa/cogvm/sig-cog.git > cd sig-cog/codegen-scripts > sh ./buildImage.sh -nodisplay > sh ./generate.sh -nodisplay ./CogUnix.st i changed the generate.sh to take the configuration class name. So now we should have multiple (sub)projects for building VM for each of the following configurations: sh ./generate.sh -headless CogUnixConfig sh ./generate.sh -headless StackInterpreterUnixConfig sh ./generate.sh -headless StackInterpreterDebugUnixConfig sh ./generate.sh -headless CogDebugUnixConfig > cd sig-cog/build > cmake . > make > zip -r Cog.zip results/* > > Problems: > Â Â Â Â - do not do a clone but update the checked out source when they are already there > Â Â Â Â - the generated VM crashes shortly after image startup > > But nevertheless, another tiny step. > 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! :) > What is nice is that this allows to trigger a build (and test) automatically when either > a new monticello or git commit happens, leading to a much faster turnaround when > doing changes to the VM. > Ideally, build should be triggered only when we commit something to git :) I should fix the codegen-scripts/LoadVMMaker.st to always use exact package version(s) for building image, not the latest one. So, then by checking-out some historical commit, one should be able to reproduce the same VM as we had, when committing it. And for testing if VMMaker could be loaded into latest development image, we can set up a separate project or use different scripts. > And of course the other important reason is that this allows people to set up their > own auto-build from a git clone when doing VM experiments, very useful in a > research and university setting. > > > Â Â Â Â Marcus > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 12, 2011

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

by HernÃ¡n Morales Durand

2011/2/12 nullPointer <epicfan(a)gmail.com>: > > >>> no >>> updatable; > >>??? > >>> only could be modified for the same designer routine. > >>??? > > Can you modify manually the code generated for the UI Painter of VW? IÂ´m > not; IÂ´m not mutant :) > > The use of XAML or XUL is for portability. Exists many tools for design a > GUI in XAML or XUL. > The perfect GUI designer already exists. In all Smalltalks implementations, > ALL, donÂ´t exists a best GUI Builder of that tools. I donÂ´t understand how > we can think could create one easily, of the same level, if not exists in > any Smalltalk, include commercials. The UI Painter and widgets of VW is > pathetical... that is the example to copy??? > Take a look at WindowBuilder Pro, is the most professional GUI Builder for Smalltalk. Cheers, HernÃ¡n

Feb. 12, 2011

[Pharo-project] saving a monticello working copy

by Tudor Girba

Hi, Does anyone know a simple way to save a Monticello working copy into the package-cache? Cheers, Doru -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Feb. 12, 2011

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

by Igor Stasenko

On 12 February 2011 18:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 12, 2011, at 9:43 AM, Esteban Lorenzano wrote: > >> really cool! >> Next week I will prepare scripts for doing same with cocoa cog and cocoa stack vms, if you agree :) >> > Yes! We will get a mac mini from INRIA for the mac build and tests. > Yes, tomorrow i will meet the guys to discuss it. > Â Â Â Â Marcus > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 12, 2011

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

by nullPointer

>> no >> updatable; >??? >> only could be modified for the same designer routine. >??? Can you modify manually the code generated for the UI Painter of VW? IÂ´m not; IÂ´m not mutant :) The use of XAML or XUL is for portability. Exists many tools for design a GUI in XAML or XUL. The perfect GUI designer already exists. In all Smalltalks implementations, ALL, donÂ´t exists a best GUI Builder of that tools. I donÂ´t understand how we can think could create one easily, of the same level, if not exists in any Smalltalk, include commercials. The UI Painter and widgets of VW is pathetical... that is the example to copy??? Well, we can still dreaming. And talking. Regards. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3303152.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 12, 2011

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

by StÃ©phane Ducasse

xml is good a simple interexchange format. Now when you have you xml stream you have to map your nodes (different to objects) so for UISPec you can just get a parser and object builder for free. NO need to load XMLSupport. read my VW examples to understand. In VW you can click on a button and see the spec or see the rendering of the spec in your code pane and this is just based on spec objects that are stored in arrays. Simple! This is not because the world does not have a nice synatx with can be used to get xml description that we should use xml everywhere. (Book title: 'Zorro'; year: 1969; pages: 230) Is better than <xml tage \xml> why because I can do doit and get a book object on the first expression with the second I have to do XMLDomParser on ::.... parse..... map to books..... I know I'm saving some of my projects in XML and mapping is boring. Stef On Feb 12, 2011, at 7:13 PM, 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). > > 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 :) > > <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> > > 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. 12, 2011