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

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

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

by Stephan Eggermont

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

Re: [Pharo-project] [3.0] Package the be removed: Network-URI

by Frank Shearar

On 8 April 2013 11:35, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 8, 2013, at 12:00 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> Sadly then due to politics I don't understand to this day, Impara was >>> forced to stop contributing to Squeak and URI never was put into use. >> >> I don't recall hearing anything about Impara being forced to stop >> contributing to Squeak. Do you have pointers to such discussions? IIRC >> "Impara" pretty much meant "Andreas Raab", and he carried on >> contributing to Squeak right up until his death, except when he was >> working too much on his day job. > > If that is what you want to believeâ¦ lets just say: It was not that simple. It's not a question of what I _believe_. I may not remember everything, or remember clearly, but that's what email archives are for. You could easily alter my beliefs with evidence. Making these kinds of remarks doesn't help anyone. What do you hope to gain? _Who_ prevented Impara from contributing to Squeak, and how did "they" manage to prevent anyone contributing to an open source project? Anyway, I don't actually expect you to answer these questions, and they're off topic for this thread. My point is that making these remarks doesn't help you. frank > Marcus > >

April 8, 2013

Re: [Pharo-project] Re; Videos of PharoConf & MooseDay: Presenters of show us your project

by Max Leske

On 08.04.2013, at 16:42, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Max wrote: >> I demoed FileSystem-Git on the first day. I was second last I think. > > Ok, you are next. Raw version, not merged with screencast yet. Cool :) > I assume having video fast, and fancy later is the way to do this. I agree. > > Stephan >

April 8, 2013