September 2014 - Pharo-dev - lists.pharo.org

[ANN] Test Coverage with Hapao

by Alexandre Bergel

Dear all, We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro Infante put quite some work on Spy2 (an Ã¼ber cool profiling framework for Pharo) and Hapao2. Hapao2 is about assessing the test coverage of your code and is a major revamp of Hapao1, which was presented a couple of years ago by Vanessa. Hapao2 does not only list covered and uncovered methods, as most test coverage tool on Earth will do. Hapao gives a great visualization to easily navigate in your code, assess its complexity, and give you a great visual output telling its coverage. You need Roassal in your image: Gofer new smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; package: 'ConfigurationOfRoassal2'; load. (Smalltalk at: #ConfigurationOfRoassal2) load and you need S2py: MCHttpRepository location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' user: '' password: '' New entries will appear in the world menu: You can run the test coverage on : - the class classes you have modified, - on a particular - on a particular class category - on the last class categories you have modified - on the last packages you have modified Here is a portion of a large coverage: A technical description of Hapao may be found on http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf We are daily using Hapao to help us understand our tests. Cheers, Ricardo, Alejandro & Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 16, 2014

Re: [Pharo-dev] TestCoverage magic?

by Alexandre Bergel

Hi Yuriy, We put quite some work on Hapao, a test code coverage for Pharo. I am preparing an announcement... Cheers, Alexandre On Sep 15, 2014, at 11:53 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone, > > Iâm trying to understand how current coverage works and executing "TestCoverage new" returns nilâ¦ and "TestCoverage class>>#on:â sends #initializeOn: to that nil. > > Iâll be very thankful for explanation. > Uko -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 16, 2014

Re: [Pharo-dev] Spec Understandability

by Sean P. DeNigris

Sean P. DeNigris wrote > It seems like you can no longer do "self instantiate: > MyComposableModelSubclass" Oops, nevermind. It was: "PanelMorph" -> "PanelMorph asSpecAdapter" ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-Understandability-tp4778370p4778376.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014

Re: [Pharo-dev] Spec Understandability

by Sean P. DeNigris

Sean P. DeNigris wrote > PanelMorph(Object)>>doesNotUnderstand: #layout: It seems like you can no longer do: "self instantiate: MyComposableModelSubclass" What is the appropriate migration? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-Understandability-tp4778370p4778373.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014

Spec Understandability

by Sean P. DeNigris

What is one supposed to do with an error like this? It's about as readable as a C++ template error ;) PanelMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector: SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [ :each | self class private_interpretASpec: each ...etc... Array(SequenceableCollection)>>collect: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector: SpecInterpreter>>computeSpecFrom:selector: SpecInterpreter>>retrieveSpecFrom:selector: SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector: SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [ :each | self class private_interpretASpec: each ...etc... Array(SequenceableCollection)>>collect: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector: SpecInterpreter class>>private_buildWidgetFor:withSpec: (ComposableModel)>>private_buildWithSpec: (ComposableModel)>>private_buildWithSpec SpecInterpreter>>returnInterpretationOf: SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector: ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-Understandability-tp4778370.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014

Re: [Pharo-dev] DateModel not working in 3.0

by Sean P. DeNigris

Stephan Eggermont wrote > Well, it is strictly compatible with the behavior of 30851... I'm not sure what you mean, but I fixed it... Issue 14025: DateModel Broken in 3.0 Fix in inbox: SLICE-Issue-14025-DateModel-Broken-in-30-SeanDeNigris.1 ButtonModel icon can no longer be set with #label:, must use #icon: Will someone please review... It's a very simple change. To test: "DateModel new openWithSpec" should not cause a MNU ----- Cheers, Sean -- View this message in context: http://forum.world.st/DateModel-not-working-in-3-0-tp4778355p4778362.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014

Re: [Pharo-dev] DateModel not working in 3.0

by Stephan Eggermont

Well, it is strictly compatible with the behavior of 30851... Stephan

Sept. 16, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by kilon alios

so its a people problem more than a technology problem from what you saying . As it is in most cases. I don't care if its python but 100k cpus sounds a lot of fun. Huge potential :) "Safer because non programmers wouldn't be writing code anymore, yes!" if you write programs you are a programmer , no ? Can you ever be safe in this life ? I think not . I don't believe in holy grail and static types look like a holy grail to me, similar to functional coding style. I can understand the benefit cant understand all this hype. But then I am not too attached to dynamic typing as well. I just dont want complexity imposed on me that I dont need, I want to be the boss of my code and no stupid language or language designer tell me how to code as if he know the needs of millions different coders. There I said it :D On Tue, Sep 16, 2014 at 4:23 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-16 14:59 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > >> I don't know maybe you are correct I have not coded for embeded platforms >> so I dont offer opinion about things I dont know. But I do know is that >> once the creator of python himself claimed that if you use python for >> performance then you are using the wrong language. But hey what does he >> know , he only created python . People having proving him so wrong for >> years now with many libraries targeting top performance. What makes those >> people special is what makes all innovators special, their unwillingness to >> compromise, to accept defeat and stop asking "What if?". >> > > There is a body of work on making Python fast, because Python is so cool > that people keep using it against all odds :) I'm working on making R fast, > for the same reason: non programmers using it to do big data. > > Think of using Python + numPy on a 100 000 CPUs supercomputer :) Fun ! > > Well, of course, you have scores of project trying to show that writing > the same code in C++ (with the right DSL or framework) would be a hell of a > lot faster and safer because of static types. > > Safer because non programmers wouldn't be writing code anymore, yes! > > >> So I am sorry I cant digest with "you are not supposed to have fun >> with...." I am sure you are correct and you speak from experience but I >> "just dont have the stomach to digest it" as we say here in Greece >> > > Sorry, but this is real. Tales of the industry... It's hard to stomach > when you talk Research directions with those guys :( > > >> >> PS: What is RT ? >> > > Real-Time. > > Thierry > >

Sept. 16, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by ClÃ©ment Bera

2014-09-16 14:55 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > What would be valuable is a reading list / path to VM enlightenment. > > Bluebook is useful > Then a tour of the Object Engine by Tim > Then plugin articles + Slang > The bytecode set > Primitive... > Context to stack mapping > Blocks > Non local returns > Display/Sensor/event look/timer implementation (like in the porting > document). > and only then one would move to more advanced topics. > > I saw that Clement had a set of VM related books on his desk at INRIA, > maybe posting the list would be great! > > The book that explains the best how to implement a high performance VM for Smalltalk and why is Urs Holzle phd <http://www.cs.ucsb.edu/~urs/oocsb/self/papers/urs-thesis.html>. Other relevant books on my office focus on specific topics, such as Advanced Compiler Design and Implementation by Steven Muchnick for optimizing compilers or The garbage collection handbook by Richard Jones, Antony Hosking and Eliot Moss. All the best, > Phil > > > > On Tue, Sep 16, 2014 at 11:48 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> >> >> 2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> >>> Hi Ronie, >>> >>> On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg(a)gmail.com> >>> wrote: >>> >>>> >>>> Hello, >>>> >>>> I am segmenting this mail in several sections. >>>> >>>> --------------------------------------------------------------- >>>> - On Lowcode and Cog >>>> >>>> I have been working in the last week with the Cog VM, implementing the >>>> Lowcode instructions in Cog. >>>> >>> >>> remember to send me code for integration. I'm eagerly waiting to use >>> your code! >>> >>> Lowcode is currently a spec of new bytecode instructions. These >>>> instructions can be used for: >>>> - Implementing a C like language compiler. >>>> - Making FFI calls >>>> >>>> I am implementing these instructions using a feature of the new >>>> bytecode set for SistaV1, which is called "inline primitives". Because of >>>> this, these new instructions can be mixed freely with the standard VM >>>> bytecode set. This also allows the Sista adaptive optimizer to inline FFI >>>> calls. >>>> >>>> These instructions provides features for: >>>> - Int32 and Int64 integer arithmetic without type checking. >>>> - Pointers, with arithmetics. >>>> - Memory access and memory manipulation. >>>> - Single and double precision floating point arithmetics. >>>> - Conversion between primitive types. >>>> - Boxing and unboxing of primitive types. >>>> - Unchecked comparisons. >>>> - Native function call. Direct and indirect calls. >>>> - The atomic operation compare and swap. >>>> - Object pin/unpin (requires Spur). >>>> - VM releasing and grabbing for threaded ffi. >>>> >>>> Current I have implemented the following backends: >>>> - A C interpreter plugin. >>>> - A LLVM based backend. >>>> >>>> Currently I am working in getting this working using the Cog code >>>> generator. So far I am already generating code for >>>> int32/pointer/float32/float64. I am starting to generate C functions calls >>>> and object boxing/unboxing. >>>> >>>> During this work I learned a lot about Cog. Specially that Cog is >>>> missing a better Slang generator, that allows to force better inlining and >>>> more code reviews. There is a lot of code duplication in Cog, that can be >>>> attributed to limitations of Slang. In my opinion, if we could use Slang >>>> not only for building the VM we should end with a better code generator. In >>>> addition we, need more people working in Cog. We need people that performs >>>> code reviews and documentation of Cog. >>>> >>>> After these weeks, I learned that working in Cogit it is not that hard. >>>> Our biggest problem is lack of documentation. Our second problem could be >>>> the lack of documentation about Slang. >>>> >>> >> Lack of documentation ? >> >> About Cog there are these documentation: >> Back to the future <http://ftp.squeak.org/docs/OOPSLA.Squeak.html> >> About VMMaker <http://wiki.squeak.org/squeak/2105> >> Object engine >> <http://www.rowledge.org/resources/tim%27s-Home-page/Squeak/OE-Tour.pdf> >> General information <http://squeakvm.org/index.html> >> Blue book part 4 >> <http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf> >> Deep into Pharo part 4 about blocks and exceptions >> <http://www.deepintopharo.com/> >> VMIL paper about Cogit >> <http://design.cs.iastate.edu/vmil/2011/papers/p03-miranda.pdf> >> The Cog blog <http://www.mirandabanda.org/cogblog/> >> About Spur: summary >> <http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me…> and >> object format >> <http://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/> >> This post >> <http://clementbera.wordpress.com/2013/08/09/the-cog-vm-lookup/> >> And many useful class and method comments that taught me a lot. >> >> When I try to work with Pharo frameworks, even recent ones, it is very >> rare that I see as much documentation than it exists for Cog. Some >> frameworks are documented in the Pharo books and a few other as Zinc have >> good documentation, but in general, there are few documentation and *even >> fewer people writing documentation*. The website about Cog has existed >> for over 6 years now. I think Cog is far from the worst documented part of >> Pharo. >> >> >>> Yes, and that's difficult because it's a moving target and I have been >>> lazy, not writing tests, instead using the Cog VM as "the test". >>> >>> It's also difficult because the first tests to write are the hardest to >> write. >> >> I am so happy to have your involvement. You and ClÃ©ment bring such >>> strength and competence. >>> >>> --------------------------------------------------------------- >>>> - Smalltalk -> LLVM ? >>>> >>>> As for having a Smalltalk -> LLVM code generator. The truth is that we >>>> will not gain anything. LLVM is a C compiler, which is designed to optimize >>>> things such as loops with lot of arithmetics. It is designed to optimize >>>> large sections of code. In Smalltalk, most of our code is composed mostly >>>> of message sends. LLVM cannot optimize a message send. >>>> >>>> To optimize a message send, you have to determine which is the method >>>> that is going to respond to the message. Then you have to inline the >>>> method. And then you can start performing the actual optimizations, such as >>>> constant folding, common subexpressions, dead branch elimination, loop >>>> unrolling, and a long etc. >>>> >>>> Because we don't have information in the actual language (e.g. static >>>> types a la C/C++/Java/C#) that tells us what is going to be the actual >>>> method invoked by a message send, we have the following alternatives to >>>> determine it: >>>> - Don't optimize anything. >>>> - Perform a costly static global analysis of the whole program. >>>> - Measure in runtime and hope for the best. >>>> - Extend the language. >>>> >>>> In other words, our best bet is in the work of ClÃ©ment in Sista. The >>>> only problem with this bet are real time applications. >>>> >>> >>> Ah! But! Sista has an advantage that other adaptive optimizers don't. >>> Because it optimizes from bytecode to bytecode it can be used during a >>> training phase and then switched off. >>> >> >>> Real time applications requires an upper bound guarantee in their >>>> response time. In some cases, the lack of this guarantee can be just an >>>> annoyance, as happens in video games. In some mission critical applications >>>> the results can not be good, if this time constraint is not met. An example >>>> of a mission critical system could the flight controls of an airplane, or >>>> the cooling system of a nuclear reactor. >>>> >>>> For these application, it is not possible to rely in an adaptive >>>> optimizer that can be triggered sometimes. In these application you have to >>>> either: >>>> - Extend the language to hand optimize some performance critical >>>> sections of code. >>>> - Use another language to optimize these critical section. >>>> - Use another language for the whole project. >>>> >>> >>> The additional option is to "train" the optimizer by running the >>> application before deploying and capturing the optimised methods. Discuss >>> this with ClÃ©ment and he'll explain how straight-forward it should be. >>> This still leaves the latency in the Cogit when it compiles from bytecode >>> to machine code. But >>> >>> a) I've yet to see anybody raise JIT latency as an issue in Cog >>> b) it would be easy to extend the VM to cause the Cogit to precompile >>> specified methods. We could easily provide a "lock-down" facility that >>> would prevent Cog from discarding specific machine code methods. >>> >>> And of course, you have to perform lot of profiling. >>>> >>> >>> Early and often :-). >>> >>> Because we can have complete control over the optimizer, and because >>> Sista is byetcode-to-bytecode and can hence store its results in the image >>> in the form of optimized methods, I believe that Sista is well-positioned >>> for real-time since it can be used before deployment. In fact we should >>> emphasise this in the papers we write on Sista. >>> >> >> The solution of Eliot makes sense. >> To write a paper about that I need benchs showing result on real time >> applications. >> So there's quite some work to do before. >> >>> >>> Greetings, >>>> Ronie >>>> >>>> 2014-09-15 16:38 GMT-03:00 Craig Latta <craig(a)netjam.org>: >>>> >>>>> >>>>> >>>>> Hear hear! >>>>> >>>>> >>>>> -C >>>>> >>>>> [1] http://tinyurl.com/m66fx8y (original message) >>>>> >>>>> -- >>>>> Craig Latta >>>>> netjam.org >>>>> +31 6 2757 7177 (SMS ok) >>>>> + 1 415 287 3547 (no SMS) >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >> > >

Sept. 16, 2014

DateModel not working in 3.0

by Sean P. DeNigris

In #30856, "DateModel new openWithSpec" -> MessageNotUnderstood: ImageMorph>>asText Any ideas? ----- Cheers, Sean -- View this message in context: http://forum.world.st/DateModel-not-working-in-3-0-tp4778355.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014