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

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Yuriy Tymchuk

I cannot see the text I type into the Spotterâs search bar. Otherwise everything is great so far. Uko > On 29 Oct 2016, at 17:09, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 28/10/2016 Ã 15:18, Esteban Lorenzano a Ã©crit : >> >>> On 28 Oct 2016, at 14:22, Thierry Goubier <thierry.goubier(a)gmail.com >>> <mailto:thierry.goubier@gmail.com>> wrote: >>> >>> apart from the missing SSL support which makes loading complex stuff >>> from github a bit painfull, it seems to be usable enough. >> >> I should work on this :) > > Anything we can be of help on this? > > In the meantime, I'm becoming expert at writing wget requests to github to get tarballs of smalltalk projects :) > > Thierry > >> Esteban > >

Nov. 1, 2016

[pharo-project/pharo-core]

by GitHub

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

Nov. 1, 2016

[pharo-project/pharo-core] 1f3f58: 60273

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 1f3f58a3fb37b65925d300a8d829d8ffe5643fbc https://github.com/pharo-project/pharo-core/commit/1f3f58a3fb37b65925d300a8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-01 (Tue, 01 Nov 2016) Changed paths: M AST-Core.package/RBPatternVariableNode.class/instance/matching/copyInContext_.st A AST-Tests-Core.package/RBParseTreeRewriterTest.class/instance/tests - ok/testRewriteDoesNotReuseOriginalNodes.st M ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/class/properties/supportedVersions.st M ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/symbolic versions/stable_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/versions/versionv3%5F2%5F8_.st A OpalCompiler-Core.package/OCRequestorScope.class/instance/lookup/lookupGlobalVar_.st M OpalCompiler-Core.package/OCRequestorScope.class/instance/lookup/lookupVar_.st A OpalCompiler-Tests.package/OpalCompilerTests.class/instance/tests/testBindingsWithUppercaseNameDoNotOverwriteGlobals.st A OpalCompiler-Tests.package/OpalCompilerTests.class/instance/tests/testEvaluateWithBindingsWithUppercaseName.st M Renraku-Help.package/RenrakuRuleCreationHelp.class/class/accessing/bookDescription.st M Renraku-Help.package/RenrakuRuleCreationHelp.class/class/accessing/pages.st M Renraku-Help.package/RenrakuRuleCreationHelp.class/class/pages/advancedChecking.st A Renraku-Help.package/RenrakuRuleCreationHelp.class/class/pages/resetCache.st M Renraku-Help.package/RenrakuRuleHelp.class/class/accessing/bookDescription.st M Renraku.package/ReIntervalSourceAnchor.class/instance/gt-inspector-extension/gtInspectorAnchorIn_.st M Renraku.package/ReSearchStringSourceAnchor.class/instance/gt-inspector-extension/gtInspectorAnchorIn_.st M Renraku.package/extension/CompiledMethod/instance/glmCritiqueSourceIn_.st M Renraku.package/extension/Object/instance/spotterRePropertiesFor_.st M Renraku.package/extension/RBProgramNode/instance/glmCritiqueSourceIn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60272.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60273.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60272.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60273.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60273 19243 different parents in one ast tree https://pharo.fogbugz.com/f/cases/19243 19257 Uppercase bindings do not work https://pharo.fogbugz.com/f/cases/19257 19269 QA update v3.2.8 https://pharo.fogbugz.com/f/cases/19269 http://files.pharo.org/image/60/60273.zip

Nov. 1, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

On 10/31/2016 05:07 PM, Ben Coman wrote: > So then why don't we *really* help the naive programmer make "x > roundTo: 0.1" an error? > Conceptually... > > Number>>roundTo: quantum > quantum < 1 ifTrue: [ quantum isFraction ifFalse: [ > SubtleArithmeticError signal ]. > ^(self / quantum) rounded * quantum > > SubtleArithmeticError >> defaultAction > self inform: 'Decimals have an inexact Float representation, so > rounding may not give you what you expect. Us Fractions instead.'. > > cheers -ben > While this is tempting, this philosophy would, I'm afraid, lead to signaling this error on *all* uses of Floats, because Floats are *full* of this kind of behavior that is surprising to the uninitiated. Regards, -Martin

Nov. 1, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Ben Coman

On Mon, Oct 31, 2016 at 11:10 PM, test <wkassens(a)libello.com> wrote: > Hi, > just a simple numerical example using nicolas' implementation: > 1.199999999999999999 round: 1. > "1.2" > i'd guess this result is more or less what a beginner would expect with this > line. how would he do it with roundTo:? perhaps this way? > 1.199999999999999999 roundTo: 0.1. > "1.2000000000000002" > i'm not so sure that he would immediately see that he'd need to do it this > way: > (1.199999999999999999 roundTo: (1/10))asFloat. > "1.2" > werner > On Tue, Nov 1, 2016 at 4:58 AM, Martin McClure <martin(a)hand2mouse.com> wrote: > tl;dr: > > 1.2000000000000002 *is* the correct answer for 1.19 roundTo: 0.1. > (1.19 roundTo: (1/10))asFloat gives a different answer because it's > rounding to a multiple of exactly 0.1, not the Float nearest to 0.1. So then why don't we *really* help the naive programmer make "x roundTo: 0.1" an error? Conceptually... Number>>roundTo: quantum quantum < 1 ifTrue: [ quantum isFraction ifFalse: [ SubtleArithmeticError signal ]. ^(self / quantum) rounded * quantum SubtleArithmeticError >> defaultAction self inform: 'Decimals have an inexact Float representation, so rounding may not give you what you expect. Us Fractions instead.'. cheers -ben

Nov. 1, 2016