- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Sept. 3, 2016

[pharo-project/pharo-core] 7ba4f9: 60200

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 7ba4f9c5ad6e8b0765f38d6c4baead332aee61bb https://github.com/pharo-project/pharo-core/commit/7ba4f9c5ad6e8b0765f38d6c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-03 (Sat, 03 Sep 2016) Changed paths: M Kernel.package/Deprecation.class/instance/handling/transform.st A Kernel.package/Deprecation.class/instance/private/rewriterClass.st M Manifest-Core.package/extension/RPackage/instance/packageManifest.st R Manifest-Core.package/extension/TBehavior/instance/isManifest.st M RPackage-Core.package/RPackage.class/instance/accessing/packageManifestOrNil.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60199.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60200.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60199.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60200.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/TBehavior.class/instance/testing/isManifest.st Log Message: ----------- 60200 19014 Autodeprecation creates a DoIt method on UndefinedObject https://pharo.fogbugz.com/f/cases/19014 19029 SystemAnnouncer allInstances size = 2 https://pharo.fogbugz.com/f/cases/19029 19027 minimal Pharo build failing https://pharo.fogbugz.com/f/cases/19027 http://files.pharo.org/image/60/60200.zip

Sept. 3, 2016

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

by Denis Kudriashov

2016-09-03 9:48 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > 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. Bad result will be in other cases too (not only zero): expected := 8085- 8084.9999. computed := (80.85 * 100) - 8084.9999. (computed - expected) abs <= (computed ulp max: expected ulp) "==> false"

Sept. 3, 2016

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

by Denis Kudriashov

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 > > We could add it but as different issue. Also I really want move away from assertions to should expressions. It is much nicer to write things like this (which available in StateSpecs): 10.1234 should equal: 10.12 within: 0.01 "success" 10.1234 should equal: 10.12 within: 0.001 "failure" Also I has idea that float assertions should always use default precision (like 0.00000000001) without special message. (80.85 * 100) should equal: 8085 It will fail now but I want it always succeed in such cases. Because in most cases users don't care about this. And when it has real value users will specify concrete precision

Sept. 3, 2016

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