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

Re: [Pharo-dev] SUnit improvements need review and feedback

by Denis Kudriashov

Hi 2016-09-03 9:22 GMT+02:00 stepharo <stepharo(a)free.fr>: > *3) Any failures inside forked processes should not spawn debugger while > running tests.* > Only when we debug tests we need debugger on forked failed processes. > During normal run SUnit should prevent such "background debuggers" and > mark such tests as failed. > > Definitevely. Now when we execute tests from the testRunner and nautilus > we should get the debugger, right? > Yes

Sept. 3, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by Nicolas Cellier

For floating points it would be good to also have something related to unit of least precision like I think it exists in google tests: assert: aFloat isWithin: anInteger ulpFrom: anotherFloat ^(aFloat - anotherFloat) abs <= (anotherFloat ulp max: aFloat ulp) It's testing if the result are the same with a tolerance on least significant bits. (anotherFloat ulp max: aFloat ulp) is not really necessary, it's only for making the comparison symmetric. indeed, 2 and 2 predecessor do not have the same exponent, so do not have the same ulp. If we don't have symmetry, then self assert: 2.0 predecessor predecessor isWithin: 1 ulpFrom: 2.0. might differ from: self assert: 2.0 isWithin: 1 ulpFrom: 2.0 predecessor predecessor . Note that the this message cannot be used to test for zero result (because 0.0 ulp is the smallest denormal). For example: self assert: 2.0 - 2.0 predecessor isWithin: 4 ulpFrom: 0.0. would anwer false, but it makes no sense! One should write self assert: 2.0 isWithin: 4 ulpFrom: 2.0 predecessor. 2016-09-03 9:22 GMT+02:00 stepharo <stepharo(a)free.fr>: > Denis > > can we also have > > assert: aNumber withPrecision: precision equals: otherNumber > > self > assert: (aNumber round: precision) > equals: otherNumber > > assert: aNumber closeTo: otherNumber > > assert: aNumber withPrecision: self defaultPrecision equals: otherNumber > > defaultPrecision > ^ 2 > > > > Le 31/8/16 Ã 14:10, Denis Kudriashov a Ã©crit : > > Hi. > > I am working on SUnit improvements. I open issue 19015 > <https://pharo.fogbugz.com/f/cases/19015/Tests-should-never-hang-and-leave-f…>. > Slice is inbox which waits your review and feedback. > I was trying to address three problems: > > *1) Tests should never hang. They should be always executed within time > limit.* > > I give them 10 minutes for now to not change existing behaviour of tests. > At next step it should be really reduced to ~100 milliseconds (?). > Any TestCase could redefine time limit by method #defaultTimeLimit. > Or it could be specified directly in test code by > self timeLimit: 10 seconds > (could be changed at any time of test execution). > > > would be good > > > To implement this logic special watch dog process is running for given > test suite to control execution time of tests. It is single process for > full test suite. > > *2) When test completes all forked processes should be terminated.* > > If your tested code produced zombie processes SUnit will take care about > destroying all such garbage. > (it not means that you don't need to clean table in #tearDown but any code > could be broken and running tests should not produce dirty system). > > Yes!!! > > *3) Any failures inside forked processes should not spawn debugger while > running tests.* > Only when we debug tests we need debugger on forked failed processes. > During normal run SUnit should prevent such "background debuggers" and > mark such tests as failed. > > Definitevely. Now when we execute tests from the testRunner and nautilus > we should get the debugger, right? > > > To implement this behaviour SUnit will handle errors from forked processes > by suspending them and collecting them in special collection. > I introduce TestFailedByForkedProcess error to signal these kind of > problems at the end of tests. This error is resumable and resume will opens > debuggers of suspended failures (in fact it will resume suspended > processes). > So to debug background failures you will need extra Proceed action on > debugger when TestFailedByForkedProcess is signalled. > But in normal run such tests will be just failed by > TestFailedByForkedProcess error. > > We should really write a little doc so that I can add it to the Sunit > Chapter. > > > > > *Now details on how it is done:* > > I introduce special process specific variable CurrentExecutionEnvironment. > It is not installed by default and as default value it returns > DefaultExecutionEnvironment instance. > This variable is inheritable. If your install concrete environment into > process it will be installed to any child process. > > So value of variable is instance of ExecutionEnvironment subclasses and > you can install it by: > > anYourExecutionEnvironment beActiveDuring: aBlock > > > When block completes previous environment is restored. > For default environment there is class side method: > > DefaultExecutionEnvironment beActiveDuring: aBlock > > > And to reset current environment to default: > > DefaultExecutionEnvironment beActive. > > > SUnit introduces TestExecutionEnvironment which implements all described > behaviour for time limits and forked processes. > To activate environment there is new method #runCaseManaged. And submitted > slice uses it instead of simple runCase. > > TestCase>>runCaseManaged > CurrentExecutionEnvironment runTestCase: self > > > DefaultExecutionEnvironment will install new TestExecutionEnvironment and > delegate processing to it. And if TestExecutionEnvironment is already > active it will just process new test case. > > Now monkey has problem in checking slice (annoying timeout for loading). > So I can't see real system impact. But it should not stop you from review > :)) > I think it is very important features for all our tests. And environment > idea will lead to very interesting future. > > > Indeed! > > > Best regards, > Denis > > >

Sept. 3, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by stepharo

Denis can we also have assert: aNumber withPrecision: precision equals: otherNumber self assert: (aNumber round: precision) equals: otherNumber assert: aNumber closeTo: otherNumber assert: aNumber withPrecision: self defaultPrecision equals: otherNumber defaultPrecision ^ 2 Le 31/8/16 Ã 14:10, Denis Kudriashov a Ã©crit : > Hi. > > I am working on SUnit improvements. I open issue 19015 > <https://pharo.fogbugz.com/f/cases/19015/Tests-should-never-hang-and-leave-f…>. > Slice is inbox which waits your review and feedback. > I was trying to address three problems: > > *1) Tests should never hang. They should be always executed within > time limit.* > I give them 10 minutes for now to not change existing behaviour of > tests. At next step it should be really reduced to ~100 milliseconds > (?). > Any TestCase could redefine time limit by method #defaultTimeLimit. > Or it could be specified directly in test code by > self timeLimit: 10 seconds > (could be changed at any time of test execution). would be good > > To implement this logic special watch dog process is running for given > test suite to control execution time of tests. It is single process > for full test suite. > > *2) When test completes all forked processes should be terminated.*** > > If your tested code produced zombie processes SUnit will take care > about destroying all such garbage. > (it not means that you don't need to clean table in #tearDown but any > code could be broken and running tests should not produce dirty system). Yes!!! > *3) Any failures inside forked processes should not spawn debugger > while running tests.* > Only when we debug tests we need debugger on forked failed processes. > During normal run SUnit should prevent such "background debuggers" and > mark such tests as failed. > Definitevely. Now when we execute tests from the testRunner and nautilus we should get the debugger, right? > To implement this behaviour SUnit will handle errors from forked > processes by suspending them and collecting them in special collection. > I introduce TestFailedByForkedProcess error to signal these kind of > problems at the end of tests. This error is resumable and resume will > opens debuggers of suspended failures (in fact it will resume > suspended processes). > So to debug background failures you will need extra Proceed action on > debugger when TestFailedByForkedProcess is signalled. > But in normal run such tests will be just failed by > TestFailedByForkedProcess error. We should really write a little doc so that I can add it to the Sunit Chapter. > > *Now details on how it is done:* > > I introduce special process specific variable > CurrentExecutionEnvironment. It is not installed by default and as > default value it returns DefaultExecutionEnvironment instance. > This variable is inheritable. If your install concrete environment > into process it will be installed to any child process. > > So value of variable is instance of ExecutionEnvironment subclasses > and you can install it by: > > anYourExecutionEnvironment beActiveDuring: aBlock > > > When block completes previous environment is restored. > For default environment there is class side method: > > DefaultExecutionEnvironment beActiveDuring: aBlock > > > And to reset current environment to default: > > DefaultExecutionEnvironment beActive. > > > SUnit introduces TestExecutionEnvironment which implements all > described behaviour for time limits and forked processes. > To activate environment there is new method #runCaseManaged. And > submitted slice uses it instead of simple runCase. > > TestCase>>runCaseManaged > CurrentExecutionEnvironment runTestCase: self > > > DefaultExecutionEnvironment will install new TestExecutionEnvironment > and delegate processing to it. And if TestExecutionEnvironment is > already active it will just process new test case. > > Now monkey has problem in checking slice (annoying timeout for loading). > So I can't see real system impact. But it should not stop you from > review :)) > I think it is very important features for all our tests. And > environment idea will lead to very interesting future. Indeed! > > Best regards, > Denis

Sept. 3, 2016

Somewhat more advanced theming

by Stephan Eggermont

https://dribbble.com/shots/2934454-Consistent-Colors-for-Varying-Sized-Obje… Color needs to be dependent on font size... Stephan

Sept. 2, 2016

Re: [Pharo-dev] about clas deprecation

by stepharo

Gustavo The fix is now in Pharo 60 :) Stef Le 2/9/16 Ã 13:35, Gustavo Santos a Ã©crit : > Make sure to have the latest version of Refactoring-Core, because we > fixed a bug on it yesterday > > On Fri, Sep 2, 2016 at 1:32 PM, Gustavo Santos <gugajansen(a)gmail.com > <mailto:gugajansen@gmail.com>> wrote: > > Gofer it > smalltalkhubUser: 'GustavoSantos' > project: 'Refactoring2'; > configurationOf: 'Refactoring2'; > loadDevelopment. > > then RBRenameAndDeprecateClassTransformation is the class you need > > > > On Fri, Sep 2, 2016 at 12:41 PM, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > > 2016-09-02 11:35 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > Excellent! > > How can I try it? > > > +100 and same question > > > > > -- > Gustavo Santos > http://gustavojss.github.io/ > > > > > -- > Gustavo Santos > http://gustavojss.github.io/

Sept. 2, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V2.1

by Serge Stinckwich

If you have install R with brew, you will find the dll here: /usr/local/Cellar/r/3.3.1_2/R.framework/Versions/3.3/Resources/lib On Thu, Sep 1, 2016 at 7:25 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > I do not see any apparent libraries on OSX. I am inspecting the content of > the R application Package and it only contains images and some executables. > > Alexandre > > On Sep 1, 2016, at 1:55 PM, Blondeau Vincent > <vincent.blondeau(a)worldline.com> wrote: > > Sorry, I havenât a Mac. > > First, you have to install R. > Then, I think you should only have to copy the R libraries (somewhere in the > disk^^) to the Pharo VM folder. > > Tell me if it works ;) > > Vincent > > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > Alexandre Bergel > EnvoyÃ© : jeudi 1 septembre 2016 17:49 > Ã : Any question about pharo is welcome > Cc : scismalltalk(a)googlegroups.com; Pharo Development List > Objet : Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V2.1 > > I wanted to try, but there is no installation instruction for OS X :-( > Can you produce some on OS X? It would be great > > Anyway, this is great Vincent! Keep pushing! > > Alexandre > > > > On Sep 1, 2016, at 12:42 PM, Blondeau Vincent > <vincent.blondeau(a)worldline.com> wrote: > > Hello everyone, > > I am glad to announce the release of version 2.1 of the RProjectConnector. > The binding between Pharo and R (https://www.r-project.org/) is now > translated to UFFI and so to Pharo 6.0. > > You can call directly your R methods from Pharo. For example, with the > famous iris clustering example: > > iris := 'eval' asREval: {RObject findVar: 'iris'}. > 'plot' > asREval: > {(iris at: 'Petal.Length'). > (iris at: 'Petal.Width'). > (#pch -> 21). > (#xlab -> 'length'). > (#ylab -> 'Width'). > (#bg ->((iris at: 'Species') collect: [ > :value | {'red'. 'green3'. 'blue'} at: value ])). > (#main -> 'Edgar Anderson''s Iris Data')}. > iris inspect. > > To use it, you should install R and copy the R libraries near the Pharo VM > (see the documentation on SmalltalkHub > (http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector) for how to > proceed). > > > > Donât forget to relaunch Pharo after the installation to be able to use the > connector. > > Only basic features are implemented yet, but you can participate to its > extension! > > Cheers, > Vincent Blondeau > > !!!************************************************************************************* > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended solely > for the addressee; it may also be privileged. If you receive this e-mail in > error, please notify the sender immediately and destroy it. As its integrity > cannot be secured on the Internet, the Worldline liability cannot be > triggered for the message content. Although the sender endeavours to > maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted.!!!" > > > > !!!************************************************************************************* > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended solely > for the addressee; it may also be privileged. If you receive this e-mail in > error, please notify the sender immediately and destroy it. As its integrity > cannot be secured on the Internet, the Worldline liability cannot be > triggered for the message content. Although the sender endeavours to > maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted.!!!" > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 2, 2016

Re: [Pharo-dev] [ANN] RProjectConnector V2.1

by Serge Stinckwich

Great job Vincent ! There is some problems on Mac OS X: - when I try to load in a fresh Pharo 5.0 image, I got a DNU on: RObjectArray class>>initElementType: I was able to load the package after a while by loading directly the package with the Monticello Browser - Apparently there is still some methods using NB like: RSession class>>checkSession or RSession class>>initEmbeddedR: I try to move the R dll close to my Pharo VM and also inside the Plugins directory but without success ... Is there a way to say where are the R dll instead of copying them ? Thank you. On Thu, Sep 1, 2016 at 5:42 PM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > Hello everyone, > > > > I am glad to announce the release of version 2.1 of the RProjectConnector. > > The binding between Pharo and R (https://www.r-project.org/) is now > translated to UFFI and so to Pharo 6.0. > > > > You can call directly your R methods from Pharo. For example, with the > famous iris clustering example: > > > > iris := 'eval' asREval: {RObject findVar: 'iris'}. > > 'plot' > > asREval: > > {(iris at: 'Petal.Length'). > > (iris at: 'Petal.Width'). > > (#pch -> 21). > > (#xlab -> 'length'). > > (#ylab -> 'Width'). > > (#bg ->((iris at: 'Species') collect: [ > :value | {'red'. 'green3'. 'blue'} at: value ])). > > (#main -> 'Edgar Anderson''s Iris Data')}. > > iris inspect. > > > > To use it, you should install R and copy the R libraries near the Pharo VM > (see the documentation on SmalltalkHub > (http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector) for how to > proceed). > > > > Donât forget to relaunch Pharo after the installation to be able to use the > connector. > > > > Only basic features are implemented yet, but you can participate to its > extension! > > > > Cheers, > > Vincent Blondeau > > > !!!************************************************************************************* > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended solely > for the addressee; it may also be privileged. If you receive this e-mail in > error, please notify the sender immediately and destroy it. As its integrity > cannot be secured on the Internet, the Worldline liability cannot be > triggered for the message content. Although the sender endeavours to > maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted.!!!" -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 2, 2016

[pharo-project/pharo-core] c0db47: 60199

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: c0db47aa711a34a5b3df11c9ba33ccab066fd891 https://github.com/pharo-project/pharo-core/commit/c0db47aa711a34a5b3df11c9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-02 (Fri, 02 Sep 2016) Changed paths: M HudsonBuildTools20.package/HDTestCoverage.class/instance/actions/install.st M HudsonBuildTools20.package/HDTestCoverage.class/instance/actions/uninstall.st R HudsonBuildTools20.package/HDTestCoverage.class/instance/private/flushCache.st M Kernel.package/MethodDictionary.class/instance/accessing/at_put_.st M Kernel.package/MethodDictionary.class/instance/removing/removeKey_ifAbsent_.st M Refactoring-Core.package/RBNamespace.class/instance/changes/defineClass_.st M Refactoring-Core.package/RBNamespace.class/instance/changes/renameClass_to_around_.st A Refactoring-Core.package/RBNamespace.class/instance/private/markAsRemoved_.st A Refactoring-Core.package/RBNamespace.class/instance/private/unmarkAsRemoved_.st A Refactoring-Tests-Core.package/RBRenameClassTest.class/instance/tests/testUnmarkRemovedClassIfRenameTargetClass.st M Reflectivity.package/ReflectiveMethod.class/instance/invalidate/installMethod_.st R SUnit-UI.package/TestCoverage.class/instance/private/flushCache.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60198.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60199.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60198.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60199.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TBehavior.class/instance/adding%2Fremoving methods/basicAddSelector_withMethod_.st M Traits.package/TBehavior.class/instance/adding%2Fremoving methods/basicRemoveSelector_.st Log Message: ----------- 60199 19021 RB forgets to unmark removedClasses https://pharo.fogbugz.com/f/cases/19021 10025 MethodDictionary at:put: and #flushCache https://pharo.fogbugz.com/f/cases/10025 http://files.pharo.org/image/60/60199.zip

Sept. 2, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60199 Home: https://github.com/pharo-project/pharo-core

Sept. 2, 2016

Re: [Pharo-dev] Slides online: "Perfection & Feedback Loops" talk from esug

by HernÃ¡n Morales Durand

Thank you for sharing this Marcus. HernÃ¡n 2016-09-02 3:38 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > At ESUG last Friday I gave a talk "Perfection & Feedback Loops or: why > worse is betterâ, I was asked for the slides. > > They are now online: > > http://www.slideshare.net/MarcusDenker/perfection- > feedback-loops-or-why-worse-is-better-65540840 > > As the slides do not contain much (just headlines), I created a special > âAnnotatedâ version with links and some comments > so one can follow better: > > http://marcusdenker.de/talks/16ESUG/FeedbackLoopsAnnotated.pdf > > PDF and .key file are there, too: http://marcusdenker.de/talks/16ESUG/ > (the .key file contains the embedded videos shown). > > A video of the presentation should be available soon. > > > Marcus >

Sept. 2, 2016