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

Re: [Pharo-project] DrGeo in success stories

by laurent laffont

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

Feb. 13, 2011

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

by laurent laffont

Waouh, not a week without incredible news :) Thank you ! Laurent On Sat, Feb 12, 2011 at 11:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. 13, 2011

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

by Tudor Girba

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

Feb. 13, 2011

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

by StÃ©phane Ducasse

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

Feb. 13, 2011

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

by StÃ©phane Ducasse

****EXCELLENT NEWS**** > 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! :) really really great. >> Ideally, build should be triggered only when we commit something to git :) Yes! Yes! Yes! > So, then by checking-out some historical commit, one should be able to > reproduce the same VM as we had, > when committing it. What we are doing is MUCH more than just a build system, we are building a system that will - increase our trust in the system - show credibility to the world - show that we can control risks even with an evolving system I think that this is important for people willing to invest in Smalltalk to see that virtual machines and the software is following adequate **engineered** practices. Thanks igor for all the energy you are putting on that. Soon we will start to have real fun at the image level. Stef

Feb. 13, 2011

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

by nullPointer

XML suxxx.... XAML or XUL suxxxs too? regards. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3303424.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 13, 2011

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

by Igor Stasenko

my 0.002 cents: - XML suxx - we need better UI - we need good graphics engine - we need good event system - we need to evaluate all alternatives :) -- Best regards, Igor Stasenko AKA sig.

Feb. 13, 2011

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

by Schwab,Wilhelm K

WindowBuilder is impressive. I'm not sure how to clean room it though. If the concern is over the serialization of objects, has anyone considered SIXX for that? Doing that could give us something similar to the Dolphin ViewComposer but clearly of distinct origin. To the result, we could add some features of WindowBuilder (adding event handlers, etc.). Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of HernÃ¡n Morales Durand [hernan.morales(a)gmail.com] Sent: Saturday, February 12, 2011 5:04 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] A new GUI visual designer 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. 13, 2011

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

by Igor Stasenko

On 13 February 2011 04:05, Ricardo Moran <richi.moran(a)gmail.com> wrote: > But please don't ban people who are willing to sacrifice a little > readability for performance reasons. Thanks. Then C language is your choice! It is full of such sacrifices :) But can i ask you to not turn smalltalk into C , please? > Best regards. > Richo -- Best regards, Igor Stasenko AKA sig.

Feb. 13, 2011

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

by Ricardo Moran

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 2011/2/12 Levente Uzonyi <leves(a)elte.hu> > On Sat, 12 Feb 2011, Miguel CobÃ¡ wrote: > > El dom, 13-02-2011 a las 02:58 +0100, Levente Uzonyi escribiÃ³: >> >>> On Sat, 12 Feb 2011, Miguel CobÃ¡ wrote: >>> >>> El dom, 13-02-2011 a las 02:26 +0100, Levente Uzonyi escribiÃ³: >>>> >>>> I know what's premature optimization. >>>>> >>>> >>>> It appear that you know but doesn't understand. See below. >>>> >>>> What I do differently than other >>>>> people (including you) is: >>>>> - if I can choose from different solutions for some problem, then I >>>>> usually pick the one with the best expected performance if it has >>>>> neglible >>>>> other extra cost (complexity, readability, size, etc) compared to other >>>>> solutions. E.g.: I usually write 1 to: 10 do: instead of (1 to: 10) >>>>> do:, >>>>> foo ifNotNil: [ ... ] instead of foo ifNotNilDo: [ ... ] or foo isNil >>>>> ifFalse: [ ... ]), etc. >>>>> >>>> >>>> This *is* premature optimization. Why? because you're programming with >>>> the performance in mind *all* the time, since the first second you start >>>> programming! >>>> >>> >>> What you fail to realize is that the code is not longer or complicated at >>> all. It has zero extra cost for you to read it, for me to write it, for >>> the machine to execute it. >>> >>> >>>> And not only that, it relies on a specific VM implementation, the squeak >>>> one. Presumes that the given messages are *more efficient* (just because >>>> you know that the squeak compiler/vm combination makes them so). But >>>> this could be wrong or at least useless in other vm (like GNU or >>>> Gemstone). So by definition it is premature optimization. >>>> >>> >>> That's right, I don't care about other VMs. Do the developers of VW, >>> Gemstone or GNU Smalltalk care about how their code will perform on >>> SqueakVM or CogVM? Hardly. >>> >>> >>>> Lastly, to program like you (and not like others, Igor and I and most >>>> people I think) we should have in the head the specifics of the vm >>>> implementation and a handy list of the inlined messages of the vm. >>>> >>> >>> That list is surprisingly short. There are more keywords or syntax >>> constructs in C/C++/Java/C#/Python/whatever than these special messages. >>> >> >> The list of registers in a intel 386 cpu is short too but that doesn't >> means that everyone must learn what registers are better for what kind >> of datatype performance-wise. Again this is not the task for the >> > > I'm sure, every assembly programmer has to learn it, but how is it related > to the messages that are inlined by the compiler? > > > developer. As everyone trying to do OO programing, the implementation >> details are irrelevant when programming. >> > > Are you serious? > > > >> >>> This is the job of the JIT, not from the developer! >>>> >>> >>> Show me the JIT that does it. >>> >> >> I said that is the *job* of the JIT not that every JIT can do it/should >> do it/does it. >> > > Be honest, there's no JIT for a Pharo image, that can do this. > > > Levente > > > >> >> >>> >>> Levente >>> >>> >>>> >>>> - I optimize library code which is expected to be heavily used >>>>> >>>> >>>> This the time and usage will tell >>>> >>>> >>>> - I like to optimize code >>>>> >>>> >>>> Prematurely it appears! >>>> >>>> Cheers >>>> >>>> -- >>>> Miguel CobÃ¡ >>>> http://twitter.com/MiguelCobaMtz >>>> http://miguel.leugim.com.mx >>>> >>>> >>>> >>>> >>>> >>>> >> -- >> Miguel CobÃ¡ >> http://twitter.com/MiguelCobaMtz >> http://miguel.leugim.com.mx >> >> >> >> >>

Feb. 13, 2011