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

Re: [Pharo-project] FAST presentation video on youtube

by kilon

very well done presentation, congratulations and a very interesting project. -- View this message in context: http://forum.world.st/FAST-presentation-video-on-youtube-tp4680355p4680382.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 9, 2013

Re: [Pharo-project] FAST looking great

by Tudor Girba

Indeed, nice work. The nicest thing is the heuristic to recover the links between invocations and underlying AST nodes. We should just have the same for accesses. Cheers, Doru On Tue, Apr 9, 2013 at 11:15 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Good presentation. Nice video. Keep up the good work! > > Stephan > > Sent from my iPad > > -- www.tudorgirba.com "Every thing has its own flow"

April 9, 2013

[Pharo-project] Versionner in 2.0 again

by Norbert Hartl

Yesterday I tried again to use Versionner in 2.0 but did have much success. So I tried myself (because I think Versionner is important) and could final generate a new version of my project using versionner. Following things I noticed (I'm writing this because I'm not sure which issue to open for what package. I'm just want opinions and after that I can open/upload whatever): I loaded Versionner from Metacello (taken from [1]) Gofer new url: 'http://ss3.gemstone.com/ss/Versionner'; package: 'ConfigurationOfVersionner'; load. (Smalltalk at: #ConfigurationOfVersionner) perform: #load monticello issues ============= While updating the rest of the packages to the newest I saw that Versionner-Core-Model-ChristopheDemarey.19 has an older ancestor for fixing something for pharo 1.4. The package Versionner-Core-Model-ChristopheDemarey.20 merged the packages back to HEAD but reverted some things like SystemAnnouncer back to SystemChangeNotifier. So I'm using Versionner-Core-Model-ChristopheDemarey.18 and Versionner-Core-Commands-ChristopheDemarey.17 as older packages. Any other package is the newest in the repository. metacello toolbox issues ================== I don't know much about metacello toolbox but the separation of files into ConfigurationOf and Baseline seems to have potential for confusion. There is a notion of a basename so it can build ConfigurationOfMyProject as well as BaselineOfMyProject (MyProject being the basename). But in the MetacelloToolbox in the pharo2.0 repository it does not seem right. I had to change the code to use (MBToolbox baseNameOf: â¦) at a few places. I took orientation from the message signature. If a method expects a configurationBaseName and the sender used the configuration class I changed it. I'll attach the mcz for now to this mail until it is clear what to do. versionner issues ============= At one place I added a metacello toolbox name conversion because it made sense to make it there. The other thing I had to fix is a method notification that takes the wrong entity from an announcement. Both packages attached as I don't have commit rights and don't know where the issue tracker for versionner is if there is any) I would be glad if any of you guys that know about that stuff could drop me a note if this is ok or where I've gone wrong. thanks, Norbert [1] http://users.dcc.uchile.cl/~jsandova/versionner/

April 9, 2013

[Pharo-project] FAST looking great

by Stephan Eggermont

Good presentation. Nice video. Keep up the good work! Stephan Sent from my iPad

April 9, 2013

Re: [Pharo-project] Toothpick

by phil＠highoctane.be

Logging tool. 2013/4/9 kilon <thekilon(a)yahoo.co.uk> > I would not mind if someone added a short description of what toothpick is > about . > > > > -- > View this message in context: > http://forum.world.st/Toothpick-tp4680310p4680363.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 9, 2013

Re: [Pharo-project] Toothpick

by phil＠highoctane.be

Hi, No, it didn't. There are missing selectors for DateAndTime and the tests aren't right in the first place. No, didn't change SqueakSource. Anyone is welcome to do so. Also, some FileSystem changes have to occur. Phil 2013/4/9 Paul DeBruicker <pdebruic(a)gmail.com> > philippeback wrote > > I've taken the Toothpick source (as mentioned in the Collaboractive book) > > and put the packages in Smalltalk Hub. > > > > There were some things with trimming blanks which I fixed. > > > > Now, some tests aren't right (but because they use dates from 2006 and we > > are in 2013) > > > > If someone could look in there, it would be nice. > > > > http://smalltalkhub.com/#!/~philippeback/Toothpick > > > > Phil > > > So just changing from 2006 to 2013 made the tests pass? > > > Thanks for moving the repo. Did you edit the Squeaksource page to point at > it? > > > > > > > -- > View this message in context: > http://forum.world.st/Toothpick-tp4680310p4680345.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 9, 2013

Re: [Pharo-project] Toothpick

by kilon

I would not mind if someone added a short description of what toothpick is about . -- View this message in context: http://forum.world.st/Toothpick-tp4680310p4680363.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 9, 2013

[Pharo-project] [update 3.0] #30027

by Marcus Denker

30027 ----- 7603 PositionalStream>>#last is a candidate for removal https://pharo.fogbugz.com/f/cases/7603 10096 remove Network-URI https://pharo.fogbugz.com/f/cases/10096 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Collections-Streams-MarcusDe…

April 9, 2013

[Pharo-project] FAST presentation video on youtube

by Yuriy Tymchuk

Hi, uploaded mine to http://youtu.be/dRr3WHOD3x4 Cheers. Uko

April 9, 2013

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

by Frank Shearar

On 9 April 2013 02:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Mon, Apr 8, 2013 at 9:32 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> 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. > > > I just implemented something to this effect for our project at Cadence. It works by > - an assembler/disassebler that can convert a method into a sequence of messages, one for each of its bytecodes and back > - using the disassembler to obtain labels which occur at the start of each basic block > - replacing the first bytecode in every basic block with an illegal bytecode, remembering the pc and its correct bytecode in the method properties > - implementing a method on MethodContext which receives the unknowBytecode message sent by the VM when it encounters an illegal bytecode > - the method replaces the illegal bytecode with the correct bytecode, removing the entry from properties, and continues > > The JIT refuses to compile methods that contain illegal bytecodes so this runs at interpreter speed until a method no longer contains illegal bytecodes (has been completely covered). But the illegal bytecode is executed at most once for each basic block, since it is replaced immediately it is executed. The information remaining in properties is that of the basic blocks that have not been executed. > > In the Squeak/Pharo bytecode set there are three unknown bytecodes, 126, 127 & 139. I have a Monticello package and tests if you're interested. I most definitely am! frank >> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > > > > -- > best, > Eliot >

April 9, 2013