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

[Pharo-project] Green CI for Soup :)

by StÃ©phane Ducasse

Hi guys Yet another ci script running green https://ci.inria.fr/pharo-contribution/job/Soup/ Stef

Feb. 22, 2013

Re: [Pharo-project] Pharo in Debian

by Damien Cassou

Hi Philippe, On Thu, Feb 21, 2013 at 10:19 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I don't have a clue about Debian packaging but as there is already > squeak, we may be able to reuse a bit. it would be great if you could have a look at that. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Feb. 22, 2013

[Pharo-project] Soup has been migrated to SmalltalkHub/PharoExtras/Soup

by stephane ducasse

Hi guys I migrated to SmalltalkHub/PharoExtras/Soup with Olivier Auverlot. And we are adding an integration server for soup :). If you want to contribute please register to SmalltalkHub and we will add you as contributors. Stef

Feb. 22, 2013

[Pharo-project] [update 2.0] #20563

by Marcus Denker

20563 ----- Issue 7547: Cannot select entry in Changes browser when clicking on the entry label http://code.google.com/p/pharo/issues/detail?id=7547 Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Widgets-MarcusDenker.106.diff http://ss3.gemstone.com/ss/Pharo20/Spec-Core-MarcusDenker.88.diff http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-MarcusDenker.775.diff http://ss3.gemstone.com/ss/Pharo20/NewList-MarcusDenker.24.diff http://ss3.gemstone.com/ss/Pharo20/NautilusRefactoring-MarcusDenker.73.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1358.diff

Feb. 22, 2013

Re: [Pharo-project] code coverage

by Marcus Denker

On Feb 21, 2013, at 8:52 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > anyone have any bytecode-to-bytecode transformation tools for > doing basic-block resolution coverage? > Opal can represent the byte code in a control flow graph. This was used for ByteSurgeon, we should revisit that as soon as the Compiler is in the image. Of course for basic blocks, one need to take care about where to add at the start of the block. Lots byte codes (creating tempVectors, pushing the nil for the tempsâ¦) that have no semantic meaning in Smalltalk. In the long term I would like to get rid of byte code as a visible artefact for reflection, though. It's just too low level. Especially the current byte code set is very low level. You can not even tell if a temp is a real temp without resorting to the full compiler chain. (Which shows that it is an execution level artefact, not a reflective one). I think moving the reflective model to something closer to the language is the way to go in the long term. Marcus

Feb. 22, 2013

Re: [Pharo-project] [squeak-dev] code coverage

by Marcus Denker

On Feb 22, 2013, at 9:16 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 22/02/2013 07:23, Marcus Denker a Ã©crit : >> >> On Feb 21, 2013, at 9:52 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> On 21 February 2013 19:52, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> Hi All, >>>> >>>> anyone have any bytecode-to-bytecode transformation tools for >>>> doing basic-block resolution coverage? >>> >>> Is it possible that Jejak [1] might vaguely fit this bill? It's a >>> tracing tool, but maybe one could hack something on the side to turn >>> it into a coverage tool? >>> >>> Certainly I've wanted a fine resolution (branch/block level) coverage >>> tool for a long time. >>> >> >> In Pharo 3.0 we will add Opal to the release (with the old Compiler to be an >> unload able package, to be killed as the first action in 4.0) > > Yes, yes, I want Opal :) > >> This will allow *a lot* of very very interesting things to be done. > > From your doc, I think there are many hooks to explore and change the generated bytecode with Opal, am I right ? > Yes, it has a control flow graph of byte code instruction objects. These can be easily explored and there an API for adding / removing nodes. We should get the high-level byte code transformation API working again, too. http://scg.unibe.ch/archive/papers/Denk06aRuntimeByteCodeESUGJournal.pdf But in general, I am not that of a fan of byteocode anymore. It's just too low level as a structural representation of code. Marcus

Feb. 22, 2013

Re: [Pharo-project] [squeak-dev] code coverage

by Goubier Thierry

Le 22/02/2013 07:23, Marcus Denker a Ã©crit : > > On Feb 21, 2013, at 9:52 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 21 February 2013 19:52, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> Hi All, >>> >>> anyone have any bytecode-to-bytecode transformation tools for >>> doing basic-block resolution coverage? >> >> Is it possible that Jejak [1] might vaguely fit this bill? It's a >> tracing tool, but maybe one could hack something on the side to turn >> it into a coverage tool? >> >> Certainly I've wanted a fine resolution (branch/block level) coverage >> tool for a long time. >> > > In Pharo 3.0 we will add Opal to the release (with the old Compiler to be an > unload able package, to be killed as the first action in 4.0) Yes, yes, I want Opal :) > This will allow *a lot* of very very interesting things to be done. From your doc, I think there are many hooks to explore and change the generated bytecode with Opal, am I right ? Thierry > Imagine this combined with > -> a Parser that can parse code with syntax errors (in Pharo 2.0) > -> a new ClassBuilder > -> The first class Slots replacing instance variables (see the OOPLSA Paper) > -> the new Debugger Model and UI > -> the new text model > > It (slowly) start to get interesting! :-) > > Marcus > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Feb. 22, 2013

Re: [Pharo-project] [squeak-dev] code coverage

by Goubier Thierry

Le 21/02/2013 21:52, Frank Shearar a Ã©crit : > On 21 February 2013 19:52, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi All, >> >> anyone have any bytecode-to-bytecode transformation tools for >> doing basic-block resolution coverage? > > Is it possible that Jejak [1] might vaguely fit this bill? It's a > tracing tool, but maybe one could hack something on the side to turn > it into a coverage tool? Yes, it could, but remember that it works at the source code level and that as a consequence you need to plan a bit your probes so that they match the expected bytecode generation (i.e. beware of optimisations). On the plus side, it's totally compiler-independent. > Certainly I've wanted a fine resolution (branch/block level) coverage > tool for a long time. That can be done in a short time... Thierry > frank > > [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Feb. 22, 2013

Re: [Pharo-project] [squeak-dev] code coverage

by Marcus Denker

On Feb 21, 2013, at 9:52 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 21 February 2013 19:52, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi All, >> >> anyone have any bytecode-to-bytecode transformation tools for >> doing basic-block resolution coverage? > > Is it possible that Jejak [1] might vaguely fit this bill? It's a > tracing tool, but maybe one could hack something on the side to turn > it into a coverage tool? > > Certainly I've wanted a fine resolution (branch/block level) coverage > tool for a long time. > In Pharo 3.0 we will add Opal to the release (with the old Compiler to be an unload able package, to be killed as the first action in 4.0) This will allow *a lot* of very very interesting things to be done. Imagine this combined with -> a Parser that can parse code with syntax errors (in Pharo 2.0) -> a new ClassBuilder -> The first class Slots replacing instance variables (see the OOPLSA Paper) -> the new Debugger Model and UI -> the new text model It (slowly) start to get interesting! :-) Marcus

Feb. 22, 2013

[Pharo-project] Migrating ProfStef from Squeaksource to PharoExtras

by StÃ©phane Ducasse

Hi guys I'm migrating ProfStef to SmalltalkHub/PharoExtras. I'm also copying the configurationOf from MetacelloRepository and I will produce a new configuration for 2.0 and for SmalltalkHub. Stef

Feb. 21, 2013