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

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

by StÃ©phane Ducasse

On Feb 12, 2011, at 6:59 PM, nullPointer wrote: > > 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. No because one single array can contain all the specs. They do that in VW since 1997 at least and it work well - you get a spec object tree - you can generate the widgets you want - morphic - html5 > Another alternative is the VW or Smalltalk/X mechanism, no readable, This is exactly the same than xml except that you do not need an xml parser to get the objects > 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. As I already said it multiple time, XML or UISpec are the same except that UISpec you get a real tree with potentially sspecific nodes. All the rest you can do exactly the same than wiht XML One day I will prove that to you. > 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. Not at all. We do not need xml to represent UISpec!!!!!!!! We can have plain objects and just call them UISpec. We can build a nice visitor on the spec tree and do a lot of things with it. > > 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

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

by StÃ©phane Ducasse

On Feb 12, 2011, at 6:22 PM, Tobias Pape wrote: > Am 2011-02-12 um 09:54 schrieb StÃ©phane Ducasse: >> tobias >> >> if you want to think that I'm an asshole and I do not want to have a better UI, you are free to think that. > > Please rest assured that this is _not_ the case. ok good > I just was astonished that you denied the usability of > the Gui builder with just few very general words. No I just evaluate MY time and what I'm able to achieve >>>>>> >>>>>> Yes so who is standing up and saying ok I will allocate one month to make sure that this is well integrated? > > However, if you want it in Pharo, thats the way to go. > Think of Seaside on any non-Pharo. It is just the same. Yes so this is why I said about my time. >>>>>> >> >> Yes. Now the question is do we want that in addition to >> - event, >> - announcement >> - changed >> >> We are working ***HARD*** to remove event and system changenotifier. >> Design is not layering, it is about bringing the right infrastructure in place. >> So if signals are important/good then they should be not in competition to other but either integrated into >> or we should migrate the code to the other abstractions. > > Probably. However, cirticising initially other goals for not being > Pharoâs isnât fair, IMHO. This is not what I did. I just evaluate: ok if I want that I need X, Z, K so my message was ok guys do not dream we cannot just include the builder that you and me would love to have. There is a lot of work to be done to arrive to that stage. >>>> In the case of the UIBuilder of void, >>> >>> Void? >> The nikname of the personn > > He is called Marcel and posted elsewhere in the thread. Ok this was nullPointer that I wanted to say. Not marcel because I know the first name of marcel. >>>> >> Yes and this is why we do not want that. >> Even for polymorph the goal is to merge everything and get one set of excellent widgets based on an excellent core. > > No Objection. > >>>> >>>> >> in pharo we use postcopy > > So does Squeak. Ok good to know one less point to check. >>>> > > I doubt that there are _ assignments. I do not know. Rob ask me how to load code without _ > No, I mean, What about _creating_ a PharoCompat > package that matches your style of preferences. Ah this would be good. >> > Thats quite clear and I concur. > The point is, you would have to do this with or without the builder. yes except that I have to check the widgets and check that. > Oh, and for this and my previous emails: No offence meant. No problem just a question: are the new widgets relying on signal? Because I would have to really study signal to imagine what we can do? Or are signal use to plug together widgets? > > So Long, > -Tobias > >

Feb. 12, 2011

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

by Esteban Lorenzano

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

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

by nullPointer

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

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

by Marcus Denker

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. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 12, 2011

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

by Esteban Lorenzano

really cool! Next week I will prepare scripts for doing same with cocoa cog and cocoa stack vms, if you agree :) Cheers, Esteban El 12/02/2011, a las 2:38p.m., Marcus Denker escribiÃ³: > 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 > 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. > > 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. > > 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. > >

Feb. 12, 2011

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

by Levente Uzonyi

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. Levente

Feb. 12, 2011

Re: [Pharo-project] DrGeo in success stories

by laurent laffont

I take the description on http://community.ofset.org/index.php/DrGeo ? Do you how many schools / teachers use it approximatively ? Laurent On Sat, Feb 12, 2011 at 5:59 PM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > Sure! > > Hilaire > > Le 12/02/2011 17:17, laurent laffont a Ã©crit : > > Hi, > > > > I was impressed by DrGeo at PharoConf. It's used by several schools. > > Is it OK to add it to the success stories page on pharo-project.org > > <http://pharo-project.org> ? > > > > > > Laurent Laffont - @lolgzs <http://twitter.com/#%21/lolgzs> > > > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > > Blog: http://magaloma.blogspot.com/ > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

Feb. 12, 2011

[Pharo-project] [Hudson] Cog Unix build

by Marcus Denker

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 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. 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. 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.

Feb. 12, 2011

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

by Tobias Pape

Am 2011-02-12 um 18:31 schrieb Miguel CobÃ¡: >>>>> In the case of the UIBuilder of void, >>>> >>>> Void? >>> The nikname of the personn >> >> He is called Marcel and posted elsewhere in the thread. > > I think that Stef is refering to nullPointer that also worked on a GUI > Builder Ok, thanks for clarification. So Long, -tobias

Feb. 12, 2011