June 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

by StÃ©phane Ducasse

I will review it but I would like to know if somebody else can have a look at it http://code.google.com/p/pharo/issues/detail?id=5913 Stef

June 9, 2012

[Pharo-project] recompiling class

by S Krish

Can we do this in Pharo: "in Java, the computation of numeric o ffsets for instance elds in memory is done by the run-time system. This permits updating a class with new instance elds or methods without aff ecting existing code. In other words, it is possible to run an existing bytecode fi le for a subclass after updating and recompiling the class, but without recompiling the subclass."

June 9, 2012

[Pharo-project] Pharo 1.3 - Build # 44 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 8, 2012

Re: [Pharo-project] Using github & Travis CI for a Smalltalk project

by Dale Henrichs

June 8, 2012

[Pharo-project] Pharo 1.3 - Build # 43 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 8, 2012

Re: [Pharo-project] Using github & Travis CI for a Smalltalk project

by Igor Stasenko

Nice, i like that..! On 8 June 2012 11:45, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Hi all, > > I have done some experiments in order to use travis CI for Smalltalk > project hosted on github. > Travis is a free continuous integration service: http://travis-ci.org/ > that is deeply integrated with github. > > I'm using FileTree repository (thanks to Dale !) to store the code on github. > Look at this example project here: https://github.com/SergeStinckwich/PlayerST > I configure Travis continuous integration service to run the tests > everytime i commit on github. > > This is quite easy, you just have to add a .travis.yml script like this one: > https://github.com/SergeStinckwich/PlayerST/blob/master/.travis.yml > > This script use Builder tools (thanks to Lukas !): > https://github.com/renggli/builder > > This is the result of running the tests: > http://travis-ci.org/#!/SergeStinckwich/PlayerST/builds/1565363 > > At the moment, this is quite rough, because i just print all the > result on the console. > There is room for improvements, but the idea is that every Smalltalk > project could use a continuous integration process like the one used > by Pharo. > > What is really nice is that travis runs also the script for all the > branches and pull request. > So you can imagine, take into account the results of the script before > doing the integration in the main branch of your dev. > > Cheers, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > -- Best regards, Igor Stasenko.

June 8, 2012

[Pharo-project] Using github & Travis CI for a Smalltalk project

by Serge Stinckwich

Hi all, I have done some experiments in order to use travis CI for Smalltalk project hosted on github. Travis is a free continuous integration service: http://travis-ci.org/ that is deeply integrated with github. I'm using FileTree repository (thanks to Dale !) to store the code on github. Look at this example project here: https://github.com/SergeStinckwich/PlayerST I configure Travis continuous integration service to run the tests everytime i commit on github. This is quite easy, you just have to add a .travis.yml script like this one: https://github.com/SergeStinckwich/PlayerST/blob/master/.travis.yml This script use Builder tools (thanks to Lukas !): https://github.com/renggli/builder This is the result of running the tests: http://travis-ci.org/#!/SergeStinckwich/PlayerST/builds/1565363 At the moment, this is quite rough, because i just print all the result on the console. There is room for improvements, but the idea is that every Smalltalk project could use a continuous integration process like the one used by Pharo. What is really nice is that travis runs also the script for all the branches and pull request. So you can imagine, take into account the results of the script before doing the integration in the main branch of your dev. Cheers, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

June 8, 2012

[Pharo-project] [update 2.0] #20115

by Marcus Denker

20115 ----- Issue 6031: Spec upgrade http://code.google.com/p/pharo/issues/detail?id=6031 Issue 5988: Windows default commands http://code.google.com/p/pharo/issues/detail?id=5988 Issue 6045: RelativeInstructionPrinter: do not print offsets in pushClosureCopyNumCopiedValues: http://code.google.com/p/pharo/issues/detail?id=6045 Issue 6037: Lets remove ReferenceStream http://code.google.com/p/pharo/issues/detail?id=6037 -- Marcus Denker -- http://marcusdenker.de

June 8, 2012

[Pharo-project] Pharo 1.3 - Build # 42 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 8, 2012

Re: [Pharo-project] [Pharo-users] Fuel FLMethodChanged error

by Mariano Martinez Peck

On Fri, Jun 8, 2012 at 1:41 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > On 06/07/2012 02:25 PM, Mariano Martinez Peck wrote: > >> | serializer | >> serializer := FLSerializer newFull. >> serializer serialize: xxx on: aStream. >> >> and tell me if that also work? >> > > > > After loading FuelMetaLevel as Martin suggested the above code works to > serialize and materialize the problematic domain objects just fine. > Ok, just to clarify: when you install the package Fuel only, and in your graph you have entities like classes or methods, they will be considered "global", that is, we just store the class name and selector and during materialization we search it in the Smalltalk globals. If the class/method is not present, we throw an error. Now...closures are more complicated because you can even EVALUATE them. If the method surrounding the closure has changed in the image you are materializing, evaluating the closure (depending on the change in the method) can even crash your VM. Because of that, when serializing methods "as globals" we also store a chemsum and we compare during materialization to see that it hasn't change it. If changed, we throw the FLMethodChanged. With the package FuelMetalevel, and by using #newFull the serializer will consider the method as "full" so it will be fully serialized, and therefore you don't have the problem of the checksum. Anyway, you found a bug because you should not be needing FuelMetalevel since you are serializing and materializing in the same image. We will investigate it. Thanks -- Mariano http://marianopeck.wordpress.com

June 8, 2012