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

Re: [Pharo-project] [Hudson] updates

by StÃ©phane Ducasse

marcus we should add Zinc as project to be built :) On Feb 11, 2011, at 1:10 AM, Marcus Denker wrote: > done in the last week: > > - current core and full are now automatically loaded from gforge for building and testing the core image > (1.3 just updates the last core build artefact) > > - For 1.3, there is now a new script build13 that does not kill the image when a debuglog is written. > (all 1.3 builds use this) > > - updated the vm used for running builds and tests (not yet the one bundled in the One-Click) > > - there is now the latest cog. the buildWithCog.sh uses this > > - seaside is build with cog, but tests are run on the interpreter for now > > - aida, seaside, xmlrpc and petitparser used as client tests for 1.2 > https://pharo-ic.lille.inria.fr/hudson/view/Pharo-Clients/ > > - RMod now has it's own view: > https://pharo-ic.lille.inria.fr/hudson/view/Rmod/ > > - the script used for building now available as an artefact > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.1/lastSuccessfulBuild/… > > - Disk usage plugin installed > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

Feb. 11, 2011

Re: [Pharo-project] about FS: a roadmap

by StÃ©phane Ducasse

- Merged damien changes in fs Stef

Feb. 11, 2011

[Pharo-project] terse guide should be adapted to pharo

by StÃ©phane Ducasse

HI guys the terse guide available in pharo contains reference to removed class. FillInTheBlank We should also clear the use of *** because this is strange. Stef

Feb. 11, 2011

Re: [Pharo-project] [Hudson] updates

by Sven Van Caekenberghe

You were being too modest last time, Marcus, you are really pushing this CI thing forward and forward, really nice to see. Thanks! On 11 Feb 2011, at 01:10, Marcus Denker wrote: > done in the last week: > > - current core and full are now automatically loaded from gforge for building and testing the core image > (1.3 just updates the last core build artefact) > > - For 1.3, there is now a new script build13 that does not kill the image when a debuglog is written. > (all 1.3 builds use this) > > - updated the vm used for running builds and tests (not yet the one bundled in the One-Click) > > - there is now the latest cog. the buildWithCog.sh uses this > > - seaside is build with cog, but tests are run on the interpreter for now > > - aida, seaside, xmlrpc and petitparser used as client tests for 1.2 > https://pharo-ic.lille.inria.fr/hudson/view/Pharo-Clients/ > > - RMod now has it's own view: > https://pharo-ic.lille.inria.fr/hudson/view/Rmod/ > > - the script used for building now available as an artefact > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.1/lastSuccessfulBuild/… Super! > - Disk usage plugin installed Sven

Feb. 11, 2011

Re: [Pharo-project] A tinyBenchmark

by StÃ©phane Ducasse

it is on the radar http://code.google.com/p/pharo/issues/detail?id=3546 Stef On Feb 11, 2011, at 2:03 AM, David T. Lewis wrote: > On Thu, Feb 10, 2011 at 07:12:03PM +0100, Sven Van Caekenberghe wrote: >> >> On 10 Feb 2011, at 17:45, Felipe Ba?ados Schwerter wrote: >> >>> Every System was the one available from their websites. (Got Pharo 1.2 from Hudson about 3 days ago.) However, VisualWorks is not available from its website right now. I installed it from a Cincom CD-ROM I got on Smalltalks 2010 . >>> >>> - There are two different Cog VMs. You didn't specify which one did you use with Pharo. >>> >>> Smalltalk vmVersion returns 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.35]'). >> >> +1 >> >> There does indeed not seem to be a very good way to get at the proper >> VM version (let alone build) from inside the Smalltalk image. It frustrates me too. >> > > Check out SystemReporter on SqueakSource. It's being used in Squeak now > and AFIK should load in Pharo also. Very convenient, and tells you everything > you need to know about VM version and lots of other things. > > Dave > >

Feb. 11, 2011

Re: [Pharo-project] Issue 1057 in pharo: SerialPlugin doesn't handle arbitrary nodes names

by pharo＠googlecode.com

Updates: Status: Fixed Comment #11 on issue 1057 by stephane...(a)gmail.com: SerialPlugin doesn't handle arbitrary nodes names http://code.google.com/p/pharo/issues/detail?id=1057 (No comment was entered for this change.)

Feb. 11, 2011

Re: [Pharo-project] Accessing the serial interface with Pharo on Windows/Linux?

by StÃ©phane Ducasse

On Feb 11, 2011, at 2:32 AM, Serge Stinckwich wrote: > All is here: http://code.google.com/p/pharo/issues/detail?id=1057 > The same code is integrated in Squeak 4.2. > The integration in 1.2 (or 1.3) is still pending. > Should i ask David and SÃ©verin to explicitely sign the Pharo licence agreement ? woudl be good but the problem was not there. it was not marked as fixed so we did not see it. Stef > > Regards, > > On Fri, Feb 11, 2011 at 12:20 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> The serial port should be working (there is a fix for named ports) I do not remember whether we should or we already integrated it. >> >> Stef >> >> On Feb 10, 2011, at 6:02 PM, Friedrich Dominicus wrote: >> >>> Just wondering if there is some Smalltalk way to access the serial >>> interface. >>> >>> A little bit extended. Can one use COM and Pharo on Windows? >>> >>> Regards >>> Friedrich >>> >> >> >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ >

Feb. 11, 2011

Re: [Pharo-project] [Hudson] updates

by Francisco Ortiz PeÃ±aloza

Great work! On Thu, Feb 10, 2011 at 10:10 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > done in the last week: > > - current core and full are now automatically loaded from gforge for > building and testing the core image > (1.3 just updates the last core build artefact) > > - For 1.3, there is now a new script build13 that does not kill the image > when a debuglog is written. > (all 1.3 builds use this) > > - updated the vm used for running builds and tests (not yet the one bundled > in the One-Click) > > - there is now the latest cog. the buildWithCog.sh uses this > > - seaside is build with cog, but tests are run on the interpreter for now > > - aida, seaside, xmlrpc and petitparser used as client tests for 1.2 > https://pharo-ic.lille.inria.fr/hudson/view/Pharo-Clients/ > > - RMod now has it's own view: > https://pharo-ic.lille.inria.fr/hudson/view/Rmod/ > > - the script used for building now available as an artefact > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.1/lastSuccessfulBuild/… > > - Disk usage plugin installed > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Feb. 11, 2011

Re: [Pharo-project] A tinyBenchmark

by Levente Uzonyi

On Fri, 11 Feb 2011, Igor Stasenko wrote: > so much noise for so insignificant smoke test. > I'd rather prefer seeing Cog doing copy-down compiled method, at least > for most simple cases - self sends :) Do you mean inlining? Levente > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 11, 2011

Re: [Pharo-project] [squeak-dev] Object>>is:

by Levente Uzonyi

On Fri, 11 Feb 2011, Igor Stasenko wrote: > On 11 February 2011 02:28, David T. Lewis <lewis(a)mail.msen.com> wrote: >> We had a good deal of discussion earlier about adding Object>>is: >> with an inconclusive outcome: >> Â http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148501.ht… >> >> Igor's original proposal is: >> Â http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html >> >> I have been tinkering around with Juan's SimpleMorphic in hopes of >> getting it running in Squeak alongside MVC and Morphic, and it would >> be convenient to have the default implementation of #is: in the image >> so I don't have to put it in a package override. >> > > Just yesterday i had discussion about this with people in the lab. I > can't say that i heard something new regarding this, > and not saying that i'd like to resurrect the discussion. > So, in short: there was no objection concerning getting rid of isXXX > in favor of using #is: method. What about performance? > The only thing which still looks controversial is too simple default > implementation which answers false. > > To my current opinion, Juan's variant is preferable. :) Yes. it should > answer false and don't contain any extra logic , like trying to follow > class hierarchy etc. > Because it serves to replace isXXXX pattern, and not adding something > new (i.e. more 'userful'). So, answering false for Object class fits > well for this purpose. > > And of course solution to that problem is simple: > - avoid writing code in style, which require isXXX tests and then > branching. Nicely written code should use message dispatch instead. > Too bad, we are not living in perfect world :) Is it better to flood superclasses with no-op extension methods? Levente > >> Any strong objections? >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 11, 2011