- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Good news !

by phil＠highoctane.be

Kudos! 2013/4/8 Serge Stinckwich <serge.stinckwich(a)gmail.com> > Dear all, > > Our Organization Application for "ESUG (European Smalltalk User > Group)" in Google Summer of Code 2013 has been accepted ! > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > >

April 8, 2013

Re: [Pharo-project] [Pharo-users] PharoConf Videos: Pharo Roadmap video online (full)

by Bernardo Ezequiel Contreras

+1 :) On Mon, Apr 8, 2013 at 3:50 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > Hi stefan > > I sent you a dropbox link with my presentations. Let me know if this is > working. > Marcus published them on slideShare too. > > Stef > On Apr 8, 2013, at 5:41 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > https://www.youtube.com/watch?v=9xRVzzjgPu8 > > > > Rendering and uploading (probably 1 or 2 a day): > > Data Migration with Moose > > FileSystem-Git > > Pharo CLI > > Building UIs with Spec > > MongoDB > > Fuel & Tanker > > > > Others: later > > > > Stephan > > > > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

April 8, 2013

Re: [Pharo-project] Good news !

by Damien Cassou

On Mon, Apr 8, 2013 at 8:49 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Our Organization Application for "ESUG (European Smalltalk User > Group)" in Google Summer of Code 2013 has been accepted ! that's great. Do you know how many slots we got? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

April 8, 2013

Re: [Pharo-project] [Pharo-users] PharoConf Videos: Pharo Roadmap video online (full)

by stephane ducasse

Hi stefan I sent you a dropbox link with my presentations. Let me know if this is working. Marcus published them on slideShare too. Stef On Apr 8, 2013, at 5:41 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > https://www.youtube.com/watch?v=9xRVzzjgPu8 > > Rendering and uploading (probably 1 or 2 a day): > Data Migration with Moose > FileSystem-Git > Pharo CLI > Building UIs with Spec > MongoDB > Fuel & Tanker > > Others: later > > Stephan >

April 8, 2013

[Pharo-project] Good news !

by Serge Stinckwich

Dear all, Our Organization Application for "ESUG (European Smalltalk User Group)" in Google Summer of Code 2013 has been accepted ! Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 8, 2013

Re: [Pharo-project] First 13 minutes of PharoConf

by Marcus Denker

This is on youtube, too: https://www.youtube.com/watch?v=m2LeNBY_5gk On Apr 8, 2013, at 8:36 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Have a look here :) > > https://gforge.inria.fr/frs/?group_id=1299&release_id=4982 > > https://gforge.inria.fr/frs/shownotes.php?release_id=4982 > > On Apr 8, 2013, at 10:41 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > >> Thank you very much for the videos. I love the lighthouses in the storm >> videos and I agree with much of ideas expressed in the roadmap. >> >> >> >> -- >> View this message in context: http://forum.world.st/First-13-minutes-of-PharoConf-tp4680143p4680183.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

April 8, 2013

Re: [Pharo-project] Improving the programmer experience with Pharo (ideas)

by stephane ducasse

On Apr 8, 2013, at 1:21 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Mon, Apr 8, 2013 at 1:08 PM, Gisela Decuzzi <giseladecuzzi(a)gmail.com> wrote: >> Please let me know your thoughts about it and if you have more ideas, they >> are always welcome. > > > 1) when you have a selector with multiple keywords, I would like to > navigate easily between the arguments. For example : > > self doSomething: (1) with: (2) andThen: (3) > > I would like to be able to easily go in one of the 3 positions (for > example typing TAB could go from one to the next). Dolphin had > something equivalent. > > 2) The pretty printer (ALT+SHIFT+u) should keep all comments where > they are and be a bit smarter and more configurable That we will see :) this is a good idea because since we want better and easier way to do code transformation we will have to handle this point. > > 3) I want AST-based text seletion. Lukas has a screencast where he > demonstrates the use of CTRL+SHIFT+Up and CTRL+SHIFT+Down to select > larger and larger (respectively smaller and smaller) AST nodes in the > source code. Something like > https://www.youtube.com/watch?v=fTMX1f8Lu5w and > http://youtu.be/_RvHz3vJ3kA?t=52s We will get that :)

April 8, 2013

Re: [Pharo-project] First 13 minutes of PharoConf

by stephane ducasse

Have a look here :) https://gforge.inria.fr/frs/?group_id=1299&release_id=4982 https://gforge.inria.fr/frs/shownotes.php?release_id=4982 On Apr 8, 2013, at 10:41 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > Thank you very much for the videos. I love the lighthouses in the storm > videos and I agree with much of ideas expressed in the roadmap. > > > > -- > View this message in context: http://forum.world.st/First-13-minutes-of-PharoConf-tp4680143p4680183.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 8, 2013

Re: [Pharo-project] [Preview] Branch test coverage analysis tool for Pharo 3.0 :)

by ClÃ©ment Bera

Well my stuff is much more basic I just wanted to implement a prototype to show what you could do with the AST-interpreter. Basically I overrided 'interpretNode:' of the AST-interpreter by : interpretNode: aNode aNode mark. super interpretNode: aNode And then at the end I have the result expected. 2013/4/8 Alexandre Bergel <alexandre.bergel(a)me.com> > What I had in mind, is something like: > -=-=-=-=-=-=-=-=-=-= > myMethodWithBranch > self foo. > v > ifTrue: [ ... ] > ifFalse: [ ... ] > -=-=-=-=-=-=-=-=-=-= > > -=-=-=-=-=-=-=-=-=-= > myMethodWithBranch > self foo. > v > ifTrue: [ *self checkPoint: 1.* ... ] > ifFalse: [ *self checkPoint: 2.* ... ]. > *self checkPoint: 3.* > -=-=-=-=-=-=-=-=-=-= > > All these checkpoint will be inserted by manipulating the bytecode. You > can then optimize a bit by removing checkpoints that have been reached. > The method #checkPoint: could then use some attributes to the > CompiledMethod. > > This is a common technique when (i) the VM does not give you what you need > and (ii) when you do not want to change the VM. > > This is something I wanted to do for year in Hapao... > > Alexandre > > > > On Apr 7, 2013, at 3:21 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > I don't know. The main problem is that the AST-interpreter is not fast > enough. The best solution for speed would be to improve it as they do in > this paper : http://dl.acm.org/citation.cfm?id=2384587 (their > ast-interpreter is faster than a byte code interpreter). > > Another solution would be to execute some method with the vm and other one > with the ast-interpreter, but it is quite some work. > > > 2013/4/7 Alexandre Bergel <alexandre.bergel(a)me.com> > Would it be possible to annotate the method with some checkpoints within > the method? This should be fast enough I guess. > > Alexandre > > > On Apr 6, 2013, at 10:35 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > This is exactly that. The tree coverage tool is a subclass of > AST-interpreter, which adding to the interpretation marks the nodes. And > then I use this marking to color the source code. And I use as you said RB > ast. > > > > This is why I implemented it in a few hours, I had already an > AST-interpreter, so I've just created a quick subclass and a spec UI. > > > > > > 2013/4/6 Frank Shearar <frank.shearar(a)gmail.com> > > So if you don't mind me being very loose with terminology, you > > interpret (RB) ASTs, and the act of interpreting marks the nodes in > > these ASTs, which you can then use to colour source? > > > > frank > > > > On 6 April 2013 11:00, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Actually, it is quite different than Jejak. > > > > > > Implementation wise, Jejak used Opal so I guess it relies on bytecode > > > modification to do its analysis where my tool relies on ast > annotations. > > > > > > This implies some difference in features. It seems that Jejak record > all > > > calls, all values and all assignments in a method (which is byte code > level > > > feature), whereas I record for each ast node if it was interpreted or > not > > > (which is ast level feature). I guess there would be a little > difference in > > > the use cases. > > > > > > > > > 2013/4/6 Frank Shearar <frank.shearar(a)gmail.com> > > >> > > >> On 6 April 2013 07:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > >>> > > >>> Clement built in a couple of hours the following nice branch > > >>> analysecoverage tools :) > > >>> It is dead slow but cool. > > >> > > >> > > >> By "branch coverage tool" do you mean Jejak? > > >> > > >> frank > > >> > > >> > > > > > > > > > > > > -- > > > ClÃ©ment BÃ©ra > > > Mate Virtual Machine Engineer > > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > > > > > > -- > > ClÃ©ment BÃ©ra > > Mate Virtual Machine Engineer > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

April 8, 2013

Re: [Pharo-project] [Preview] Branch test coverage analysis tool for Pharo 3.0 :)

by Alexandre Bergel

What I had in mind, is something like: -=-=-=-=-=-=-=-=-=-= myMethodWithBranch self foo. v ifTrue: [ ... ] ifFalse: [ ... ] -=-=-=-=-=-=-=-=-=-= -=-=-=-=-=-=-=-=-=-= myMethodWithBranch self foo. v ifTrue: [ self checkPoint: 1. ... ] ifFalse: [ self checkPoint: 2. ... ]. self checkPoint: 3. -=-=-=-=-=-=-=-=-=-= All these checkpoint will be inserted by manipulating the bytecode. You can then optimize a bit by removing checkpoints that have been reached. The method #checkPoint: could then use some attributes to the CompiledMethod. This is a common technique when (i) the VM does not give you what you need and (ii) when you do not want to change the VM. This is something I wanted to do for year in Hapao... Alexandre On Apr 7, 2013, at 3:21 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > I don't know. The main problem is that the AST-interpreter is not fast enough. The best solution for speed would be to improve it as they do in this paper : http://dl.acm.org/citation.cfm?id=2384587 (their ast-interpreter is faster than a byte code interpreter). > > Another solution would be to execute some method with the vm and other one with the ast-interpreter, but it is quite some work. > > > 2013/4/7 Alexandre Bergel <alexandre.bergel(a)me.com> > Would it be possible to annotate the method with some checkpoints within the method? This should be fast enough I guess. > > Alexandre > > > On Apr 6, 2013, at 10:35 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > This is exactly that. The tree coverage tool is a subclass of AST-interpreter, which adding to the interpretation marks the nodes. And then I use this marking to color the source code. And I use as you said RB ast. > > > > This is why I implemented it in a few hours, I had already an AST-interpreter, so I've just created a quick subclass and a spec UI. > > > > > > 2013/4/6 Frank Shearar <frank.shearar(a)gmail.com> > > So if you don't mind me being very loose with terminology, you > > interpret (RB) ASTs, and the act of interpreting marks the nodes in > > these ASTs, which you can then use to colour source? > > > > frank > > > > On 6 April 2013 11:00, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Actually, it is quite different than Jejak. > > > > > > Implementation wise, Jejak used Opal so I guess it relies on bytecode > > > modification to do its analysis where my tool relies on ast annotations. > > > > > > This implies some difference in features. It seems that Jejak record all > > > calls, all values and all assignments in a method (which is byte code level > > > feature), whereas I record for each ast node if it was interpreted or not > > > (which is ast level feature). I guess there would be a little difference in > > > the use cases. > > > > > > > > > 2013/4/6 Frank Shearar <frank.shearar(a)gmail.com> > > >> > > >> On 6 April 2013 07:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > >>> > > >>> Clement built in a couple of hours the following nice branch > > >>> analysecoverage tools :) > > >>> It is dead slow but cool. > > >> > > >> > > >> By "branch coverage tool" do you mean Jejak? > > >> > > >> frank > > >> > > >> > > > > > > > > > > > > -- > > > ClÃ©ment BÃ©ra > > > Mate Virtual Machine Engineer > > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > > > > > > -- > > ClÃ©ment BÃ©ra > > Mate Virtual Machine Engineer > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > ClÃ©ment BÃ©ra > Mate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 8, 2013