- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alain Rastoul

On 26/02/2016 23:06, Alain Rastoul wrote: > On 26/02/2016 23:01, Alain Rastoul wrote: >> I also recompiled the CriticBrowser with an invariant to see where >> something was wrong with right-click/ban from selected package (DNU). Thought there is still something related to ast/recompilation I have to investigate : It start with a DNU in IRTranslatorV2 with a packageCount not found that it should find, the second time you open Critic Browser it is ok If you want to try this, with IceCompiler package installed copy paste the following in a playground and do in sequence: " 1. add the invariant method I gave to CriticBrowser (may be it is completely false but whatever) : rulesModelChildrenUnderstandLeaves <contract: invariant> ^ rulesModel selectedItem ifNil: [ true ] ifNotNil: [ :rule | rule respondsTo: #leaves ]. then " "2 .recompile CriticBrowser with the invariant:" IceCompiler compile: CriticBrowser . "3. open an inspector on the blacbox" IceReporter open . " 4. do CriticBrowser stuff here 4.1 open CritiBrowser on my package, first time DNU to investigate related to Metalink ast recompilation I guess close it 4.2 then second time, opening CriticBrowser is ok 4.3 then right click on rule, select 'ban from selected package' => DNU" "5.refresh the blackbox, you will see the traces of contract failures" "6. clean the CriticBrowser compiled methods from contracts (ie recompile)" IceCompiler clean: CriticBrowser fun :) -- Alain

Feb. 26, 2016

Re: [Pharo-dev] wrong method trailer kind

by Tudor Girba

I would be curious to find out as well :) Doru > On Feb 26, 2016, at 11:16 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > It seems, the gt-Methods are actually methods not in any method dictionary. > And if I inspect the real methods from the method dictionary, that "flag" is different. > But I can not find any object pointing to this elements, and they arent cleaned up with > Smalltalk garbageCollect ... > > 2016-02-26 22:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > 17618 Failing test: ReleaseTest>>#testInstalledMethodsWithIncorrectTrailerKind > Interesting bug. > someone who can tell me what exactly is this trailer kind and why it is based > on some "flag" in "method at: method size". > And why it seems to be wrong for many GT-methods: > > (CompiledMethod allInstances select:[:m | (m at: m size) = 24]) collect:[:k | > k -> k trailer kind] "an Array(String class>>#gtInspectorFourtyTwo->#EmbeddedSourceQCompress OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress GlobalVariable class>>#gtExampleSmalltalk->#EmbeddedSourceQCompress VirtualMachine class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMBrowser class>>#gtExampleBasic->#EmbeddedSourceQCompress RPackageTag class>>#gtExamplePackageTag->#EmbeddedSourceQCompress Object class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMCompositePresentation class>>#gtExampleCompositePresentation->#EmbeddedSourceQCompress LiteralVariable class>>#gtExampleUniqueLiteralVariable->#EmbeddedSourceQCompress GTSpotterRecorderEvent class>>#gtExampleAnySubclass->#EmbeddedSourceQCompress MetacelloAbstractPackageSpec class>>#gtExamplePackageSpec->#EmbeddedSourceQCompress MetacelloProjectReferenceSpec class>>#gtExampleProjectReferenceSpec->#EmbeddedSourceQCompress MetacelloProjectSpec class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloSpec class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloVersion class>>#gtExampleMetacelloVersion->#EmbeddedSourceQCompress GLMPresentation class>>#gtExampleBasic->#EmbeddedSourceQCompress Bag class>>#gtExampleBagWithTenElements->#EmbeddedSourceQCompress Bag class>>#gtExampleBagWithOneElement->#EmbeddedSourceQCompress GTDummyExamplesRecursive class>>#h->#EmbeddedSourceQCompress GLMAlertBrick class>>#gtExample->#EmbeddedSourceQCompress GTDummyExampleProvider>>#a->#EmbeddedSourceQCompress GTDummyExampleProvider>>#b->#EmbeddedSourceQCompress GTDummyExampleWithAssertions>>#a->#EmbeddedSourceQCompress GTDummyExampleWithAssertions>>#b->#EmbeddedSourceQCompress GTDummyExamples class>>#l->#EmbeddedSourceQCompress GTDummyExamples class>>#o->#EmbeddedSourceQCompress GTDummyExamplesInvalid class>>#a:->#EmbeddedSourceQCompress GTDummyExamplesPragmas class>>#a->#EmbeddedSourceQCompress GTDummyExamplesPragmas class>>#c->#EmbeddedSourceQCompress GTDummyExamplesPragmas class>>#b->#EmbeddedSourceQCompress GLMCollapsableBrick class>>#gtExample->#EmbeddedSourceQCompress FileReference class>>#gtExampleText->#EmbeddedSourceQCompress GTSpotterStep class>>#gtExampleBasic->#EmbeddedSourceQCompress GTEventAnnouncement class>>#gtExampleEmptyAnnouncement->#EmbeddedSourceQCompress UndefinedObject>>#DoIt->#EmbeddedSourceQCompress UndefinedObject>>#DoIt->#EmbeddedSourceQCompress)" > -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

Feb. 26, 2016

Re: [Pharo-dev] wrong method trailer kind

by Nicolai Hess

It seems, the gt-Methods are actually methods not in any method dictionary. And if I inspect the real methods from the method dictionary, that "flag" is different. But I can not find any object pointing to this elements, and they arent cleaned up with Smalltalk garbageCollect ... 2016-02-26 22:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > 17618 > <https://pharo.fogbugz.com/f/cases/17618/Failing-test-ReleaseTest-testInstal…> > Failing test: ReleaseTest>>#testInstalledMethodsWithIncorrectTrailerKind > Interesting bug. > someone who can tell me what exactly is this trailer kind and why it is > based > on some "flag" in "method at: method size". > And why it seems to be wrong for many GT-methods: > > (CompiledMethod allInstances select:[:m | (m at: m size) = 24]) > collect:[:k | > k -> k trailer kind] "an Array(String > class>>#gtInspectorFourtyTwo->#EmbeddedSourceQCompress > OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress > OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress GlobalVariable > class>>#gtExampleSmalltalk->#EmbeddedSourceQCompress VirtualMachine > class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMBrowser > class>>#gtExampleBasic->#EmbeddedSourceQCompress RPackageTag > class>>#gtExamplePackageTag->#EmbeddedSourceQCompress Object > class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMCompositePresentation > class>>#gtExampleCompositePresentation->#EmbeddedSourceQCompress > LiteralVariable > class>>#gtExampleUniqueLiteralVariable->#EmbeddedSourceQCompress > GTSpotterRecorderEvent > class>>#gtExampleAnySubclass->#EmbeddedSourceQCompress > MetacelloAbstractPackageSpec > class>>#gtExamplePackageSpec->#EmbeddedSourceQCompress > MetacelloProjectReferenceSpec > class>>#gtExampleProjectReferenceSpec->#EmbeddedSourceQCompress > MetacelloProjectSpec > class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloSpec > class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloVersion > class>>#gtExampleMetacelloVersion->#EmbeddedSourceQCompress GLMPresentation > class>>#gtExampleBasic->#EmbeddedSourceQCompress Bag > class>>#gtExampleBagWithTenElements->#EmbeddedSourceQCompress Bag > class>>#gtExampleBagWithOneElement->#EmbeddedSourceQCompress > GTDummyExamplesRecursive class>>#h->#EmbeddedSourceQCompress GLMAlertBrick > class>>#gtExample->#EmbeddedSourceQCompress > GTDummyExampleProvider>>#a->#EmbeddedSourceQCompress > GTDummyExampleProvider>>#b->#EmbeddedSourceQCompress > GTDummyExampleWithAssertions>>#a->#EmbeddedSourceQCompress > GTDummyExampleWithAssertions>>#b->#EmbeddedSourceQCompress GTDummyExamples > class>>#l->#EmbeddedSourceQCompress GTDummyExamples > class>>#o->#EmbeddedSourceQCompress GTDummyExamplesInvalid > class>>#a:->#EmbeddedSourceQCompress GTDummyExamplesPragmas > class>>#a->#EmbeddedSourceQCompress GTDummyExamplesPragmas > class>>#c->#EmbeddedSourceQCompress GTDummyExamplesPragmas > class>>#b->#EmbeddedSourceQCompress GLMCollapsableBrick > class>>#gtExample->#EmbeddedSourceQCompress FileReference > class>>#gtExampleText->#EmbeddedSourceQCompress GTSpotterStep > class>>#gtExampleBasic->#EmbeddedSourceQCompress GTEventAnnouncement > class>>#gtExampleEmptyAnnouncement->#EmbeddedSourceQCompress > UndefinedObject>>#DoIt->#EmbeddedSourceQCompress > UndefinedObject>>#DoIt->#EmbeddedSourceQCompress)" >

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alain Rastoul

On 26/02/2016 23:01, Alain Rastoul wrote: > I also recompiled the CriticBrowser with an invariant to see where > something was wrong with right-click/ban from selected package (DNU). > nb : the invariant was : > > rulesModelChildrenUnderstandLeaves > <contract: invariant> > ^ rulesModel selectedItem ifNil: [ true ] ifNotNil: [ :rule | rule > respondsTo: #leaves ] > > because the DNU was on 'leaves' not understood. > > :) > forgot to say that I had several stack traces recorded in the black box ... > I was too short on TreeModel knowledge to go forward but this didn't > break CodeCritic. -- Alain

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alain Rastoul

On 26/02/2016 22:01, stepharo wrote: > > You see this is a lot more difficult than it appears. ***Ideally*** old > should be a full copy of the object :) > But we can live with an approx solution. You are right, I didn't thought about this problem at all, I was thinking about the way to connect the two objects wrapping the method calls with MetaLink, and the implications in the workflow of the compiler front-end I did (rewrite several parts in fact). I don't measure all the implications of making a deep copy, a shallow copy or no copy (pointers only), but this could be a parameter at run-time > > In any case I would really love to see if we can have contracts in > classes in Pharo libraries and > see how it improves them. > > I would like to see the performance penalties. > What we could have is the following: > The extra cost is almost only in what is done in the checks : I did the small test of using a FakeOrderedCollection (the one in IceCompiler-Core-Tests package) and adding 10K integer to it, with and without contracts and I had terrible results : more than 2mn with contract checking, less than 1s without (I don't remember the exact values) without, but no surprise at all, all the cost was in the collection>>includes: check done in the postCondition: postAdd: anObject ^ self includes: anObject who does a scan of the collection .... The cost of MetaLink or IceContractor and co is neglectable for a run-time check IMHO, abd when releasing, all the code will be recompiled without contract checking. > When we run the tests we run them twice > One with contracts on and one without contracts. > > - first the results should be same :) > - second the contracts should be working But this is done in the tests classes in the IceCompiler package with very small runs and my intention is to add more tests. I may be ashamed but you can look at the code... ( don't flame me please , I'm no coder and I know I have to refactor lot of things) ... ;) The approach I took is to have a blackbox to record test failures, no assert, exceptions or whatever, I just record failures, because I wanted to be non intrusive/agressive towards the system. And this could be a parameter too. I also recompiled the CriticBrowser with an invariant to see where something was wrong with right-click/ban from selected package (DNU). nb : the invariant was : rulesModelChildrenUnderstandLeaves <contract: invariant> ^ rulesModel selectedItem ifNil: [ true ] ifNotNil: [ :rule | rule respondsTo: #leaves ] because the DNU was on 'leaves' not understood. :) I was too short on TreeModel knowledge to go forward but this didn't break CodeCritic. > > Then we could start to have test harnessing (I know that guys from > argentina did some libraries for that) > and we could have better tests and find bugs in code by using the > contracts. > > Stef > > -- Alain

Feb. 26, 2016

wrong method trailer kind

by Nicolai Hess

17618 <https://pharo.fogbugz.com/f/cases/17618/Failing-test-ReleaseTest-testInstal…> Failing test: ReleaseTest>>#testInstalledMethodsWithIncorrectTrailerKind Interesting bug. someone who can tell me what exactly is this trailer kind and why it is based on some "flag" in "method at: method size". And why it seems to be wrong for many GT-methods: (CompiledMethod allInstances select:[:m | (m at: m size) = 24]) collect:[:k | k -> k trailer kind] "an Array(String class>>#gtInspectorFourtyTwo->#EmbeddedSourceQCompress OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress GlobalVariable class>>#gtExampleSmalltalk->#EmbeddedSourceQCompress VirtualMachine class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMBrowser class>>#gtExampleBasic->#EmbeddedSourceQCompress RPackageTag class>>#gtExamplePackageTag->#EmbeddedSourceQCompress Object class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMCompositePresentation class>>#gtExampleCompositePresentation->#EmbeddedSourceQCompress LiteralVariable class>>#gtExampleUniqueLiteralVariable->#EmbeddedSourceQCompress GTSpotterRecorderEvent class>>#gtExampleAnySubclass->#EmbeddedSourceQCompress MetacelloAbstractPackageSpec class>>#gtExamplePackageSpec->#EmbeddedSourceQCompress MetacelloProjectReferenceSpec class>>#gtExampleProjectReferenceSpec->#EmbeddedSourceQCompress MetacelloProjectSpec class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloSpec class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloVersion class>>#gtExampleMetacelloVersion->#EmbeddedSourceQCompress GLMPresentation class>>#gtExampleBasic->#EmbeddedSourceQCompress Bag class>>#gtExampleBagWithTenElements->#EmbeddedSourceQCompress Bag class>>#gtExampleBagWithOneElement->#EmbeddedSourceQCompress GTDummyExamplesRecursive class>>#h->#EmbeddedSourceQCompress GLMAlertBrick class>>#gtExample->#EmbeddedSourceQCompress GTDummyExampleProvider>>#a->#EmbeddedSourceQCompress GTDummyExampleProvider>>#b->#EmbeddedSourceQCompress GTDummyExampleWithAssertions>>#a->#EmbeddedSourceQCompress GTDummyExampleWithAssertions>>#b->#EmbeddedSourceQCompress GTDummyExamples class>>#l->#EmbeddedSourceQCompress GTDummyExamples class>>#o->#EmbeddedSourceQCompress GTDummyExamplesInvalid class>>#a:->#EmbeddedSourceQCompress GTDummyExamplesPragmas class>>#a->#EmbeddedSourceQCompress GTDummyExamplesPragmas class>>#c->#EmbeddedSourceQCompress GTDummyExamplesPragmas class>>#b->#EmbeddedSourceQCompress GLMCollapsableBrick class>>#gtExample->#EmbeddedSourceQCompress FileReference class>>#gtExampleText->#EmbeddedSourceQCompress GTSpotterStep class>>#gtExampleBasic->#EmbeddedSourceQCompress GTEventAnnouncement class>>#gtExampleEmptyAnnouncement->#EmbeddedSourceQCompress UndefinedObject>>#DoIt->#EmbeddedSourceQCompress UndefinedObject>>#DoIt->#EmbeddedSourceQCompress)"

Feb. 26, 2016

Re: [Pharo-dev] Setting the font for a spec button

by Stephan Eggermont

On 26-02-16 20:44, stepharo wrote: > Stephan > > I created a Spec tutorial on github and the goal is to gather all the > material on Spec. > Do you want to add your example in a file? So that it does not get lost Yes, I'll commit some examples Stephan

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by stepharo

>>> Now can you support the old value? > > Sorry I responded too quickly, I thought you where talking of the > syntax (no problem) > but you mean the value before the call I guess. > I didn't understood at first. > yes it should be possible too, a bit trickier, with an small extra > cost in performance but cool You see this is a lot more difficult than it appears. ***Ideally*** old should be a full copy of the object :) But we can live with an approx solution. In any case I would really love to see if we can have contracts in classes in Pharo libraries and see how it improves them. I would like to see the performance penalties. What we could have is the following: When we run the tests we run them twice One with contracts on and one without contracts. - first the results should be same :) - second the contracts should be working Then we could start to have test harnessing (I know that guys from argentina did some libraries for that) and we could have better tests and find bugs in code by using the contracts. Stef

Feb. 26, 2016

[updated Pharo by example] new chapter to review

by stepharo

https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample… I hope that in Pharo 6 we will migrate to Xstreams but for now this chapter should be ok. Stef

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alain Rastoul

On 26/02/2016 21:23, Alain Rastoul wrote: > On 26/02/2016 20:51, stepharo wrote: >> Now can you support the old value? Sorry I responded too quickly, I thought you where talking of the syntax (no problem) but you mean the value before the call I guess. I didn't understood at first. yes it should be possible too, a bit trickier, with an small extra cost in performance but cool -- Alain

Feb. 26, 2016