[Pharo-project] [update 1.4] #14152
14152 - - Issue 4824: New tests for CompiledMethod equality. Thanks Mariano Martinez-Peck. http://code.google.com/p/pharo/issues/detail?id=4824 - Issue 4822: Improving TickList. Thanks Benjamin van Ryseghem. http://code.google.com/p/pharo/issues/detail?id=4822 - Issue 4823: Make MCSliceMaker use TickList. Thanks Benjamin van Ryseghem. http://code.google.com/p/pharo/issues/detail?id=4823 Stef
Re: [Pharo-project] scaled decimal question
On 17 September 2011 14:06, Peter Hugosson-Miller wrote: > Probably because Floats are not exact, so the result of #asScaledDecimal: > when sent to a Float, differs from what the compiler produces when it parses > 0.1s2. Indeed. In particular, the Floats turn themselves into "exact representations" (Float >> #asTrueFraction) - Fractions whose bit patterns duplicate the float representation. That means that the resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing fraction instvars. frank > -- > Cheers, > Peter. > > On 17 sep 2011, at 15:01, Stéphane Ducasse wrote: > >> >> Why >> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: >> 2) >> returns false >> >> while >> >> 0.1s2 + 0.2s2 = 0.3s2 >> returns true >> >> ? > >
[Pharo-project] [update 1.4] #14153
14153 - Issue 2986: DemoModeshould not change Fonts only sizes http://code.google.com/p/pharo/issues/detail?id=2986 -- Marcus Denker -- http://marcusdenker.de
[Pharo-project] Tablet choice (was: New CogDroid alpha: with intent filter).
Stephane, Stéphane Ducasse wrote: > I would like to buy a tablet for our team to try pharo on it. > What do you suggest? While I would not recommend any particular brand (first of all I don't know what is available in Europe and at what price), take a look at the tinyBenchmarks page: http://code.google.com/p/squeakvm-tablet/wiki/TinyBenchmark and this might help you make decision. After all, there are not so more chipsets (SOCs) out there, so you can see that 1Ghz performs almost twice faster than 800MHz (I asked this on the ARM forum, and they suggested that cheaper SOCs may come with cheaper and slower memory, smaller cache, etc.). NVidia Tegra seems to be much better than Samsung. The rest of your choice will be likely affected by screen size, number of external ports (USB, HDMI, Ethernet), price, and known reliability record of a particular vendor ;) I'd recommend resistive touch screen (cheaper and works with any non-conductive stylus) but this might be just me. Thanks. -- Dimitry Golubovsky Anywhere on the Web
Re: [Pharo-project] scaled decimal question
For me the problem is that if "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. a number is a scaled decimal or not. On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: > On 17 September 2011 14:06, Peter Hugosson-Miller > wrote: >> Probably because Floats are not exact, so the result of #asScaledDecimal: >> when sent to a Float, differs from what the compiler produces when it parses >> 0.1s2. Sure I guessed that too but I hate this behavior. > Indeed. In particular, the Floats turn themselves into "exact > representations" (Float >> #asTrueFraction) - Fractions whose bit > patterns duplicate the float representation. That means that the > resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing > fraction instvars. > > frank > >> -- >> Cheers, >> Peter. >> >> On 17 sep 2011, at 15:01, Stéphane Ducasse wrote: >> >>> >>> Why >>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: >>> 2) >>> returns false >>> >>> while >>> >>> 0.1s2 + 0.2s2 = 0.3s2 >>> returns true >>> >>> ? >> >> >
[Pharo-project] do not forget to sign and send us the license agreement
Hi guys this is important that you sign the license agreement for your code. http://code.google.com/p/pharo/wiki/HowToContribute Stef
Re: [Pharo-project] MethodDictionary fast #rehash
I'm not quite sure it is correct. The problem is if another Process want to use this MethodDictionary while it is in an inconsistent state... Or if you are rehashing on of the MethodDictionary which contains one of the methods used by the rehashing itself. See recent changes from Levente in trunk. Nicolas 2011/9/17 Mariano Martinez Peck : > > > On Sat, Sep 17, 2011 at 10:26 PM, Nicolas Cellier > wrote: >> >> 2011/9/17 Mariano Martinez Peck : >> > Hi guys. I was checking MethodDictionary >> rehash and this is terribly >> > slow >> > because of the #become. Then I saw #rehashWithoutBecome but it answers >> > a >> > different instance. I need a #rehash that does the rehash in the real >> > object >> > and answers self. So...I need the regular #rehash but I want to avoid >> > the >> > #become. Is that possible somehow? >> > >> > This is the current implementation: >> > >> > rehashWithoutBecome >> > >> > | newInstance | >> > newInstance := self species new: self basicSize - 1. "Make sure it >> > has >> > the same capacity" >> > 1 to: self basicSize do: [ :index | >> > (self basicAt: index) ifNotNil: [ :key | >> > newInstance at: key put: (array at: index) ] ]. >> > ^newInstance >> > >> > I am terrible bad with Collection and friends, but cannot we do >> > soemthing >> > like this: >> > >> > rehashWithoutBecome >> > >> > | newInstance | >> > newInstance := self species new: self basicSize - 1. "Make sure it >> > has >> > the same capacity" >> > >> > 1 to: self basicSize do: [ :index | >> > (self basicAt: index) ifNotNil: [ :key | >> > newInstance at: key put: (array at: index) ] ]. >> > >> > 1 to: newInstance basicSize do: [ :index | >> > (newInstance basicAt: index) ifNotNil: [ :key | >> > self at: key put: (newInstance array at: index) ] ]. >> > >> > ^ self >> > >> >> I guess you should at least also copy the nil entries... >> Maybe something like >> >> 1 to: newInstance basicSize do: [ :index | >> self basicAt: index put: (newInstance basicAt: index). >> array at: index put: (newInstance array at: index)]. >> > > > Good point. SoI was not that mistaken ;) > I have just replaced CompiledMethod >> hash with this new method and at > least all the tests in MethodDictionaryTest are green. > Do you think this implementation is correct or there can be problems? > because it is really MUCH faster than the original one. > > Thanks in advance > >> >> > >> > Thanks for any help. >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >
[Pharo-project] Fwd: scaled decimal question
Begin forwarded message: > From: Werner Kassens > Date: September 18, 2011 5:11:59 PM GMT+02:00 > To: Stéphane Ducasse > Subject: scaled decimal question > > Hi Stephane, > occasionally i look at the the Pharo-project mailing list and i saw your > question re ScaledDecimals. they are Fractions and you can can look at their > internal representation by using asFraction. things like 0.1s2 are fractions > built from scratch , hence 0.1s2 asFraction returns 1/10 while (0.1 > asScaledDecimal: 2) asFraction returns the same thing as 0.1 asFraction. > aFloat asFraction is constructed in such a way that > aFloat asFraction asFloat= aFloat > for every aFloat. At least with a probability of (100 - epsilon)% with > epsilon going to 0. while epsilon is not equal to 0 according to the author > of asFraction (see the last comment at the end of > Float>>asTrueFraction),obviously nobody has as yet found a counterexample, > hence i would forget that. > iow (0.1 asScaledDecimal: 2)represents exactly the same number as the float > 0.1. > since 0.1 + 0.2=0.3 returns false you would of course expect your first > example to return false. and you would expect the error in the equality to be > similar to the error in 0.1 + 0.2=0.3. although not necessarily equal. if > this last statement does not immediately make sense, you might want to think > a second or two about the results of these things: > ((0.1 asFraction ) + (0.2 asFraction))asFloat = (0.1 +0.2) . > ((0.1 asFraction ) + (0.2 asFraction)) = (0.1 +0.2) asFraction . > > werner
Re: [Pharo-project] scaled decimal question
2011/9/18 Stéphane Ducasse : > For me the problem is that if > > "s2" means scaled decimal then I do not understand why asScaledDecimal > produce objects with different properties. > > a number is a scaled decimal or not. > There is a difference between these two: (1/10) asScaledDecimal: 2. (1/10) asFloat asScaledDecimal: 2. asFloat introduces a rounding error. Though the result prints 0.1, it is different from (1/10), asFrank said, just convert it back asTrueFraction, and you'll see. asScaledDecimal: does not undo the rounding error, it just uses asTrueFraction. If you want to undo the error, you may try (0.1 roundTo: 0.01s2). Nicolas > > On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: > >> On 17 September 2011 14:06, Peter Hugosson-Miller >> wrote: >>> Probably because Floats are not exact, so the result of #asScaledDecimal: >>> when sent to a Float, differs from what the compiler produces when it >>> parses 0.1s2. > > Sure I guessed that too but I hate this behavior. > > >> Indeed. In particular, the Floats turn themselves into "exact >> representations" (Float >> #asTrueFraction) - Fractions whose bit >> patterns duplicate the float representation. That means that the >> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >> fraction instvars. >> >> frank >> >>> -- >>> Cheers, >>> Peter. >>> >>> On 17 sep 2011, at 15:01, Stéphane Ducasse >>> wrote: >>> Why (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) returns false while 0.1s2 + 0.2s2 = 0.3s2 returns true ? >>> >>> >> > > >
Re: [Pharo-project] scaled decimal question
Hi nicolas I'm sure that I understand. In fact I'm totally confused by the name used. > 0.1s2 is this expression supposed to return a scaled decimal? > (0.1 asScaledDecimal: 2) what this expression supposed to return? I thought it was a scaled decimal too. So for me as a stupid guy, if both return scaled decimal then I do not get with we get different results. Or the expressions returns soemthing different and in such a case one should be renamed. Or I'm do not understand at all this world. Stef On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: > 2011/9/18 Stéphane Ducasse : >> For me the problem is that if >> >>"s2" means scaled decimal then I do not understand why >> asScaledDecimal produce objects with different properties. >> >> a number is a scaled decimal or not. >> > > There is a difference between these two: > > (1/10) asScaledDecimal: 2. > (1/10) asFloat asScaledDecimal: 2. > > asFloat introduces a rounding error. > Though the result prints 0.1, it is different from (1/10), asFrank > said, just convert it back asTrueFraction, and you'll see. > asScaledDecimal: does not undo the rounding error, it just uses > asTrueFraction. > If you want to undo the error, you may try (0.1 roundTo: 0.01s2). > > Nicolas > >> >> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: >> >>> On 17 September 2011 14:06, Peter Hugosson-Miller >>> wrote: Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. >> >> Sure I guessed that too but I hate this behavior. >> >> >>> Indeed. In particular, the Floats turn themselves into "exact >>> representations" (Float >> #asTrueFraction) - Fractions whose bit >>> patterns duplicate the float representation. That means that the >>> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >>> fraction instvars. >>> >>> frank >>> -- Cheers, Peter. On 17 sep 2011, at 15:01, Stéphane Ducasse wrote: > > Why > (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 > asScaledDecimal: 2) > returns false > > while > > 0.1s2 + 0.2s2 = 0.3s2 > returns true > > ? >>> >> >> >> >
Re: [Pharo-project] scaled decimal question
On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: > 2011/9/18 Stéphane Ducasse : >> For me the problem is that if >> >>"s2" means scaled decimal then I do not understand why >> asScaledDecimal produce objects with different properties. >> >> a number is a scaled decimal or not. >> > > There is a difference between these two: > > (1/10) asScaledDecimal: 2. > (1/10) asFloat asScaledDecimal: 2. That I can understand Float is inexact. No problem with that. Now I do not understand how 0.1s2 relates to the above expressions. > asFloat introduces a rounding error. > Though the result prints 0.1, it is different from (1/10), asFrank > said, just convert it back asTrueFraction, and you'll see. > asScaledDecimal: does not undo the rounding error, it just uses > asTrueFraction. > If you want to undo the error, you may try (0.1 roundTo: 0.01s2). > > Nicolas > >> >> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: >> >>> On 17 September 2011 14:06, Peter Hugosson-Miller >>> wrote: Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. >> >> Sure I guessed that too but I hate this behavior. >> >> >>> Indeed. In particular, the Floats turn themselves into "exact >>> representations" (Float >> #asTrueFraction) - Fractions whose bit >>> patterns duplicate the float representation. That means that the >>> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >>> fraction instvars. >>> >>> frank >>> -- Cheers, Peter. On 17 sep 2011, at 15:01, Stéphane Ducasse wrote: > > Why > (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 > asScaledDecimal: 2) > returns false > > while > > 0.1s2 + 0.2s2 = 0.3s2 > returns true > > ? >>> >> >> >> >
Re: [Pharo-project] scaled decimal question
2011/9/18 Stéphane Ducasse : > > On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: > >> 2011/9/18 Stéphane Ducasse : >>> For me the problem is that if >>> >>> "s2" means scaled decimal then I do not understand why >>> asScaledDecimal produce objects with different properties. >>> >>> a number is a scaled decimal or not. >>> >> >> There is a difference between these two: >> >> (1/10) asScaledDecimal: 2. >> (1/10) asFloat asScaledDecimal: 2. > > That I can understand Float is inexact. No problem with that. > > Now I do not understand how 0.1s2 relates to the above expressions. > Ah, because the NumberParser knows you want a ScaledDecimal with the s2 specification, so it just doesn't use an intermediate Float, but directly convert (1/10) asScaledDecimal: 2. You can also try ScaledDecimal readFrom: '0.1', it avoids a an intermediate conversion to Float too. Nicolas > >> asFloat introduces a rounding error. >> Though the result prints 0.1, it is different from (1/10), asFrank >> said, just convert it back asTrueFraction, and you'll see. >> asScaledDecimal: does not undo the rounding error, it just uses >> asTrueFraction. >> If you want to undo the error, you may try (0.1 roundTo: 0.01s2). > > > > > >> >> Nicolas >> >>> >>> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: >>> On 17 September 2011 14:06, Peter Hugosson-Miller wrote: > Probably because Floats are not exact, so the result of #asScaledDecimal: > when sent to a Float, differs from what the compiler produces when it > parses 0.1s2. >>> >>> Sure I guessed that too but I hate this behavior. >>> >>> Indeed. In particular, the Floats turn themselves into "exact representations" (Float >> #asTrueFraction) - Fractions whose bit patterns duplicate the float representation. That means that the resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing fraction instvars. frank > -- > Cheers, > Peter. > > On 17 sep 2011, at 15:01, Stéphane Ducasse > wrote: > >> >> Why >> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 >> asScaledDecimal: 2) >> returns false >> >> while >> >> 0.1s2 + 0.2s2 = 0.3s2 >> returns true >> >> ? > > >>> >>> >>> >> > > >
Re: [Pharo-project] scaled decimal question
Yeah, but the *big* difference is that "asScaledDecimal: 2" is a message sent to a Float, whereas the "s2" is just part of the literal representation of a ScaledDecimal, and *not* a message sent to anything. -- Cheers, Peter. On 18 sep 2011, at 17:59, Stéphane Ducasse wrote: > > On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: > >> 2011/9/18 Stéphane Ducasse : >>> For me the problem is that if >>> >>> "s2" means scaled decimal then I do not understand why >>> asScaledDecimal produce objects with different properties. >>> >>> a number is a scaled decimal or not. >>> >> >> There is a difference between these two: >> >> (1/10) asScaledDecimal: 2. >> (1/10) asFloat asScaledDecimal: 2. > > That I can understand Float is inexact. No problem with that. > > Now I do not understand how 0.1s2 relates to the above expressions. > > >> asFloat introduces a rounding error. >> Though the result prints 0.1, it is different from (1/10), asFrank >> said, just convert it back asTrueFraction, and you'll see. >> asScaledDecimal: does not undo the rounding error, it just uses >> asTrueFraction. >> If you want to undo the error, you may try (0.1 roundTo: 0.01s2). > > > > > >> >> Nicolas >> >>> >>> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: >>> On 17 September 2011 14:06, Peter Hugosson-Miller wrote: > Probably because Floats are not exact, so the result of #asScaledDecimal: > when sent to a Float, differs from what the compiler produces when it > parses 0.1s2. >>> >>> Sure I guessed that too but I hate this behavior. >>> >>> Indeed. In particular, the Floats turn themselves into "exact representations" (Float >> #asTrueFraction) - Fractions whose bit patterns duplicate the float representation. That means that the resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing fraction instvars. frank > -- > Cheers, > Peter. > > On 17 sep 2011, at 15:01, Stéphane Ducasse > wrote: > >> >> Why >> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 >> asScaledDecimal: 2) >> returns false >> >> while >> >> 0.1s2 + 0.2s2 = 0.3s2 >> returns true >> >> ? > > >>> >>> >>> >> > >
Re: [Pharo-project] scaled decimal question
And in Squeak 3.7, I just verified that (Number class>>readFrom:) did use an intermediate Float... 0.1s2 asFraction -> (3602879701896397/36028797018963968) This was corrected in 3.8, so maybe not integrated by you Stef ? Nicolas 2011/9/18 Peter Hugosson-Miller : > Yeah, but the *big* difference is that "asScaledDecimal: 2" is a message sent > to a Float, whereas the "s2" is just part of the literal representation of a > ScaledDecimal, and *not* a message sent to anything. > > -- > Cheers, > Peter. > > On 18 sep 2011, at 17:59, Stéphane Ducasse wrote: > >> >> On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: >> >>> 2011/9/18 Stéphane Ducasse : For me the problem is that if "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. a number is a scaled decimal or not. >>> >>> There is a difference between these two: >>> >>> (1/10) asScaledDecimal: 2. >>> (1/10) asFloat asScaledDecimal: 2. >> >> That I can understand Float is inexact. No problem with that. >> >> Now I do not understand how 0.1s2 relates to the above expressions. >> >> >>> asFloat introduces a rounding error. >>> Though the result prints 0.1, it is different from (1/10), asFrank >>> said, just convert it back asTrueFraction, and you'll see. >>> asScaledDecimal: does not undo the rounding error, it just uses >>> asTrueFraction. >>> If you want to undo the error, you may try (0.1 roundTo: 0.01s2). >> >> >> >> >> >>> >>> Nicolas >>> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: > On 17 September 2011 14:06, Peter Hugosson-Miller > wrote: >> Probably because Floats are not exact, so the result of >> #asScaledDecimal: when sent to a Float, differs from what the compiler >> produces when it parses 0.1s2. Sure I guessed that too but I hate this behavior. > Indeed. In particular, the Floats turn themselves into "exact > representations" (Float >> #asTrueFraction) - Fractions whose bit > patterns duplicate the float representation. That means that the > resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing > fraction instvars. > > frank > >> -- >> Cheers, >> Peter. >> >> On 17 sep 2011, at 15:01, Stéphane Ducasse >> wrote: >> >>> >>> Why >>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 >>> asScaledDecimal: 2) >>> returns false >>> >>> while >>> >>> 0.1s2 + 0.2s2 = 0.3s2 >>> returns true >>> >>> ? >> >> > >>> >> >> > >
Re: [Pharo-project] scaled decimal question
thank I will digest that slowly :) On Sep 18, 2011, at 6:16 PM, Nicolas Cellier wrote: > 2011/9/18 Stéphane Ducasse : >> >> On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: >> >>> 2011/9/18 Stéphane Ducasse : For me the problem is that if "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. a number is a scaled decimal or not. >>> >>> There is a difference between these two: >>> >>> (1/10) asScaledDecimal: 2. >>> (1/10) asFloat asScaledDecimal: 2. >> >> That I can understand Float is inexact. No problem with that. >> >> Now I do not understand how 0.1s2 relates to the above expressions. >> > > Ah, because the NumberParser knows you want a ScaledDecimal with the > s2 specification, so it just doesn't use an intermediate Float, but > directly convert (1/10) asScaledDecimal: 2. > You can also try ScaledDecimal readFrom: '0.1', it avoids a an > intermediate conversion to Float too. > > Nicolas > >> >>> asFloat introduces a rounding error. >>> Though the result prints 0.1, it is different from (1/10), asFrank >>> said, just convert it back asTrueFraction, and you'll see. >>> asScaledDecimal: does not undo the rounding error, it just uses >>> asTrueFraction. >>> If you want to undo the error, you may try (0.1 roundTo: 0.01s2). >> >> >> >> >> >>> >>> Nicolas >>> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: > On 17 September 2011 14:06, Peter Hugosson-Miller > wrote: >> Probably because Floats are not exact, so the result of >> #asScaledDecimal: when sent to a Float, differs from what the compiler >> produces when it parses 0.1s2. Sure I guessed that too but I hate this behavior. > Indeed. In particular, the Floats turn themselves into "exact > representations" (Float >> #asTrueFraction) - Fractions whose bit > patterns duplicate the float representation. That means that the > resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing > fraction instvars. > > frank > >> -- >> Cheers, >> Peter. >> >> On 17 sep 2011, at 15:01, Stéphane Ducasse >> wrote: >> >>> >>> Why >>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 >>> asScaledDecimal: 2) >>> returns false >>> >>> while >>> >>> 0.1s2 + 0.2s2 = 0.3s2 >>> returns true >>> >>> ? >> >> > >>> >> >> >> >
Re: [Pharo-project] scaled decimal question
On Sep 18, 2011, at 6:25 PM, Nicolas Cellier wrote: > And in Squeak 3.7, I just verified that (Number class>>readFrom:) did > use an intermediate Float... > > 0.1s2 asFraction -> (3602879701896397/36028797018963968) > > This was corrected in 3.8, so maybe not integrated by you Stef ? you confused me :) Should we integrate something in pharo? Stef > > Nicolas > > 2011/9/18 Peter Hugosson-Miller : >> Yeah, but the *big* difference is that "asScaledDecimal: 2" is a message >> sent to a Float, whereas the "s2" is just part of the literal representation >> of a ScaledDecimal, and *not* a message sent to anything. >> >> -- >> Cheers, >> Peter. >> >> On 18 sep 2011, at 17:59, Stéphane Ducasse wrote: >> >>> >>> On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: >>> 2011/9/18 Stéphane Ducasse : > For me the problem is that if > > "s2" means scaled decimal then I do not understand why > asScaledDecimal produce objects with different properties. > > a number is a scaled decimal or not. > There is a difference between these two: (1/10) asScaledDecimal: 2. (1/10) asFloat asScaledDecimal: 2. >>> >>> That I can understand Float is inexact. No problem with that. >>> >>> Now I do not understand how 0.1s2 relates to the above expressions. >>> >>> asFloat introduces a rounding error. Though the result prints 0.1, it is different from (1/10), asFrank said, just convert it back asTrueFraction, and you'll see. asScaledDecimal: does not undo the rounding error, it just uses asTrueFraction. If you want to undo the error, you may try (0.1 roundTo: 0.01s2). >>> >>> >>> >>> >>> Nicolas > > On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: > >> On 17 September 2011 14:06, Peter Hugosson-Miller >> wrote: >>> Probably because Floats are not exact, so the result of >>> #asScaledDecimal: when sent to a Float, differs from what the compiler >>> produces when it parses 0.1s2. > > Sure I guessed that too but I hate this behavior. > > >> Indeed. In particular, the Floats turn themselves into "exact >> representations" (Float >> #asTrueFraction) - Fractions whose bit >> patterns duplicate the float representation. That means that the >> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >> fraction instvars. >> >> frank >> >>> -- >>> Cheers, >>> Peter. >>> >>> On 17 sep 2011, at 15:01, Stéphane Ducasse >>> wrote: >>> Why (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) returns false while 0.1s2 + 0.2s2 = 0.3s2 returns true ? >>> >>> >> > > > >>> >>> >> >> >
Re: [Pharo-project] scaled decimal question
On Sep 18, 2011, at 6:21 PM, Peter Hugosson-Miller wrote: > Yeah, but the *big* difference is that "asScaledDecimal: 2" is a message sent > to a Float, whereas the "s2" is just part of the literal representation of a > ScaledDecimal, and *not* a message sent to anything. sure you are explaining to me why I get a different behavior at the implementation level but my question is at the conceptual level :) At the end we (the language designer) could make that they are the same because 0 is a character . too and 1 too. So I have no problem that we decide that 0.1 asScaledDecimal: 2 is not the same as 0.1s2 but in that case we call it 0.1 asSomethingElseThanScaledDecimal: 2 and this is perfect for me. This is all my point. else 2 could be different from 1+1 too :) Stef > > -- > Cheers, > Peter. > > On 18 sep 2011, at 17:59, Stéphane Ducasse wrote: > >> >> On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: >> >>> 2011/9/18 Stéphane Ducasse : For me the problem is that if "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. a number is a scaled decimal or not. >>> >>> There is a difference between these two: >>> >>> (1/10) asScaledDecimal: 2. >>> (1/10) asFloat asScaledDecimal: 2. >> >> That I can understand Float is inexact. No problem with that. >> >> Now I do not understand how 0.1s2 relates to the above expressions. >> >> >>> asFloat introduces a rounding error. >>> Though the result prints 0.1, it is different from (1/10), asFrank >>> said, just convert it back asTrueFraction, and you'll see. >>> asScaledDecimal: does not undo the rounding error, it just uses >>> asTrueFraction. >>> If you want to undo the error, you may try (0.1 roundTo: 0.01s2). >> >> >> >> >> >>> >>> Nicolas >>> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: > On 17 September 2011 14:06, Peter Hugosson-Miller > wrote: >> Probably because Floats are not exact, so the result of >> #asScaledDecimal: when sent to a Float, differs from what the compiler >> produces when it parses 0.1s2. Sure I guessed that too but I hate this behavior. > Indeed. In particular, the Floats turn themselves into "exact > representations" (Float >> #asTrueFraction) - Fractions whose bit > patterns duplicate the float representation. That means that the > resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing > fraction instvars. > > frank > >> -- >> Cheers, >> Peter. >> >> On 17 sep 2011, at 15:01, Stéphane Ducasse >> wrote: >> >>> >>> Why >>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 >>> asScaledDecimal: 2) >>> returns false >>> >>> while >>> >>> 0.1s2 + 0.2s2 = 0.3s2 >>> returns true >>> >>> ? >> >> > >>> >> >> >
Re: [Pharo-project] scaled decimal question
2011/9/18 Stéphane Ducasse : > > On Sep 18, 2011, at 6:21 PM, Peter Hugosson-Miller wrote: > >> Yeah, but the *big* difference is that "asScaledDecimal: 2" is a message >> sent to a Float, whereas the "s2" is just part of the literal representation >> of a ScaledDecimal, and *not* a message sent to anything. > > sure you are explaining to me why I get a different behavior at the > implementation level but my question is at the conceptual level :) > > At the end we (the language designer) could make that they are the same > because > 0 is a character > . too > and 1 too. > > So I have no problem that we decide that > > 0.1 asScaledDecimal: 2 > is not the same as 0.1s2 but in that case we call it > > 0.1 asSomethingElseThanScaledDecimal: 2 > > and this is perfect for me. > > This is all my point. else 2 could be different from 1+1 too :) > > Stef > Oh, but they are: (1 to: 1000) detect: [:i | | s1 s2 | s1 := Number readFrom: '0.' , (String new: i withAll: $0) , '1'. s2 := Number readFrom: '0.' , (String new: i withAll: $0) , '2'. s1+s1~=s2] -> 308 Thus 0.1 + 0.1 ~= 0.2 ;) Nicolas > >> >> -- >> Cheers, >> Peter. >> >> On 18 sep 2011, at 17:59, Stéphane Ducasse wrote: >> >>> >>> On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: >>> 2011/9/18 Stéphane Ducasse : > For me the problem is that if > > "s2" means scaled decimal then I do not understand why > asScaledDecimal produce objects with different properties. > > a number is a scaled decimal or not. > There is a difference between these two: (1/10) asScaledDecimal: 2. (1/10) asFloat asScaledDecimal: 2. >>> >>> That I can understand Float is inexact. No problem with that. >>> >>> Now I do not understand how 0.1s2 relates to the above expressions. >>> >>> asFloat introduces a rounding error. Though the result prints 0.1, it is different from (1/10), asFrank said, just convert it back asTrueFraction, and you'll see. asScaledDecimal: does not undo the rounding error, it just uses asTrueFraction. If you want to undo the error, you may try (0.1 roundTo: 0.01s2). >>> >>> >>> >>> >>> Nicolas > > On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: > >> On 17 September 2011 14:06, Peter Hugosson-Miller >> wrote: >>> Probably because Floats are not exact, so the result of >>> #asScaledDecimal: when sent to a Float, differs from what the compiler >>> produces when it parses 0.1s2. > > Sure I guessed that too but I hate this behavior. > > >> Indeed. In particular, the Floats turn themselves into "exact >> representations" (Float >> #asTrueFraction) - Fractions whose bit >> patterns duplicate the float representation. That means that the >> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >> fraction instvars. >> >> frank >> >>> -- >>> Cheers, >>> Peter. >>> >>> On 17 sep 2011, at 15:01, Stéphane Ducasse >>> wrote: >>> Why (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) returns false while 0.1s2 + 0.2s2 = 0.3s2 returns true ? >>> >>> >> > > > >>> >>> >> > > >
Re: [Pharo-project] MethodDictionary fast #rehash
On Sun, Sep 18, 2011 at 5:40 PM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > I'm not quite sure it is correct. > The problem is if another Process want to use this MethodDictionary > while it is in an inconsistent state... > Or if you are rehashing on of the MethodDictionary which contains one > of the methods used by the rehashing itself. > Interesting. Thanks Nicolas for the pointer. > See recent changes from Levente in trunk. > > heheheheh it seems Levente is still reading the Pharo mailing list. So...I took his commits of today, and I have made a Pharo change set. I have put all the information here: http://code.google.com/p/pharo/issues/detail?id=4826 Basically, he used #copyFrom: which is primitive and hence it avoids the inconsistent state. If someone can check the changeset and give the OK, we can integrate it. Thanks a lot > Nicolas > > 2011/9/17 Mariano Martinez Peck : > > > > > > On Sat, Sep 17, 2011 at 10:26 PM, Nicolas Cellier > > wrote: > >> > >> 2011/9/17 Mariano Martinez Peck : > >> > Hi guys. I was checking MethodDictionary >> rehash and this is > terribly > >> > slow > >> > because of the #become. Then I saw #rehashWithoutBecome but it > answers > >> > a > >> > different instance. I need a #rehash that does the rehash in the real > >> > object > >> > and answers self. So...I need the regular #rehash but I want to avoid > >> > the > >> > #become. Is that possible somehow? > >> > > >> > This is the current implementation: > >> > > >> > rehashWithoutBecome > >> > > >> > | newInstance | > >> > newInstance := self species new: self basicSize - 1. "Make sure it > >> > has > >> > the same capacity" > >> > 1 to: self basicSize do: [ :index | > >> > (self basicAt: index) ifNotNil: [ :key | > >> > newInstance at: key put: (array at: index) ] ]. > >> > ^newInstance > >> > > >> > I am terrible bad with Collection and friends, but cannot we do > >> > soemthing > >> > like this: > >> > > >> > rehashWithoutBecome > >> > > >> > | newInstance | > >> > newInstance := self species new: self basicSize - 1. "Make sure it > >> > has > >> > the same capacity" > >> > > >> > 1 to: self basicSize do: [ :index | > >> > (self basicAt: index) ifNotNil: [ :key | > >> > newInstance at: key put: (array at: index) ] ]. > >> > > >> > 1 to: newInstance basicSize do: [ :index | > >> > (newInstance basicAt: index) ifNotNil: [ :key | > >> > self at: key put: (newInstance array at: index) ] ]. > >> > > >> > ^ self > >> > > >> > >> I guess you should at least also copy the nil entries... > >> Maybe something like > >> > >> 1 to: newInstance basicSize do: [ :index | > >> self basicAt: index put: (newInstance basicAt: index). > >> array at: index put: (newInstance array at: index)]. > >> > > > > > > Good point. SoI was not that mistaken ;) > > I have just replaced CompiledMethod >> hash with this new method and at > > least all the tests in MethodDictionaryTest are green. > > Do you think this implementation is correct or there can be problems? > > because it is really MUCH faster than the original one. > > > > Thanks in advance > > > >> > >> > > >> > Thanks for any help. > >> > > >> > > >> > -- > >> > Mariano > >> > http://marianopeck.wordpress.com > >> > > >> > > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > -- Mariano http://marianopeck.wordpress.com
[Pharo-project] slices does not work anymore in Pharo1.4
Hi guys. Someting really weird is happening in Pharo. I have 3 dirty packages: Kernel, KernelTests and ScriptLoader14. I have created an issue and select those 3 packages. But when the slice is created, it the MonticelloBrowser, it shows only one dependency: ScriptLoader14. So..it misses Kernel and KernelTests. What is worst, is that if I then commit such slice and I see the commits details, it says: "Dependencies: Kernel-MarianoMartinezPeck.940, ScriptLoader14-MarianoMartinezPeck.175" WTF? now it shows 2 instead of 3 ? Can someone reprouce this problem? I think it may be related to the selection focus in the UI. Cheers -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] slices does not work anymore in Pharo1.4
strange. BTW normally scriptLoader should not be added to slice since this a private and strange package. Stef On Sep 18, 2011, at 8:17 PM, Mariano Martinez Peck wrote: > Hi guys. Someting really weird is happening in Pharo. I have 3 dirty > packages: Kernel, KernelTests and ScriptLoader14. I have created an issue and > select those 3 packages. But when the slice is created, it the > MonticelloBrowser, it shows only one dependency: ScriptLoader14. So..it > misses Kernel and KernelTests. What is worst, is that if I then commit such > slice and I see the commits details, it says: "Dependencies: > Kernel-MarianoMartinezPeck.940, ScriptLoader14-MarianoMartinezPeck.175" > WTF? now it shows 2 instead of 3 ? > > Can someone reprouce this problem? I think it may be related to the > selection focus in the UI. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com >
Re: [Pharo-project] scaled decimal question
Ok I will read finally all the remarks so that I really understand. :) (or not ;)) Stef On Sep 18, 2011, at 7:21 PM, Nicolas Cellier wrote: > 2011/9/18 Stéphane Ducasse : >> >> On Sep 18, 2011, at 6:21 PM, Peter Hugosson-Miller wrote: >> >>> Yeah, but the *big* difference is that "asScaledDecimal: 2" is a message >>> sent to a Float, whereas the "s2" is just part of the literal >>> representation of a ScaledDecimal, and *not* a message sent to anything. >> >> sure you are explaining to me why I get a different behavior at the >> implementation level but my question is at the conceptual level :) >> >> At the end we (the language designer) could make that they are the same >> because >> 0 is a character >> . too >> and 1 too. >> >> So I have no problem that we decide that >> >>0.1 asScaledDecimal: 2 >>is not the same as 0.1s2 but in that case we call it >> >>0.1 asSomethingElseThanScaledDecimal: 2 >> >> and this is perfect for me. >> >> This is all my point. else 2 could be different from 1+1 too :) >> >> Stef >> > > Oh, but they are: > > (1 to: 1000) detect: [:i | > | s1 s2 | > s1 := Number readFrom: '0.' , (String new: i withAll: $0) , '1'. > s2 := Number readFrom: '0.' , (String new: i withAll: $0) , '2'. > s1+s1~=s2] > -> 308 > > Thus > 0.1 > + > 0.1 > ~= > 0.2 > > ;) > > Nicolas >> >>> >>> -- >>> Cheers, >>> Peter. >>> >>> On 18 sep 2011, at 17:59, Stéphane Ducasse >>> wrote: >>> On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: > 2011/9/18 Stéphane Ducasse : >> For me the problem is that if >> >> "s2" means scaled decimal then I do not understand why >> asScaledDecimal produce objects with different properties. >> >> a number is a scaled decimal or not. >> > > There is a difference between these two: > > (1/10) asScaledDecimal: 2. > (1/10) asFloat asScaledDecimal: 2. That I can understand Float is inexact. No problem with that. Now I do not understand how 0.1s2 relates to the above expressions. > asFloat introduces a rounding error. > Though the result prints 0.1, it is different from (1/10), asFrank > said, just convert it back asTrueFraction, and you'll see. > asScaledDecimal: does not undo the rounding error, it just uses > asTrueFraction. > If you want to undo the error, you may try (0.1 roundTo: 0.01s2). > > Nicolas > >> >> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: >> >>> On 17 September 2011 14:06, Peter Hugosson-Miller >>> wrote: Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. >> >> Sure I guessed that too but I hate this behavior. >> >> >>> Indeed. In particular, the Floats turn themselves into "exact >>> representations" (Float >> #asTrueFraction) - Fractions whose bit >>> patterns duplicate the float representation. That means that the >>> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >>> fraction instvars. >>> >>> frank >>> -- Cheers, Peter. On 17 sep 2011, at 15:01, Stéphane Ducasse wrote: > > Why > (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 > asScaledDecimal: 2) > returns false > > while > > 0.1s2 + 0.2s2 = 0.3s2 > returns true > > ? >>> >> >> >> > >>> >> >> >> >
Re: [Pharo-project] How can I get smart characters in Pharo 1.4?
so that's an issue with the keyboard input not pharo directly see http://code.google.com/p/pharo/issues/detail?id=3748 and try to figure out what keyboard events you get in for meta + " meta + shift + " ctrl + " ctrl + shift + " alt + " alt + shift + " cause I am sure that they are rather randomly distributed around some sane average... On 2011-09-16, at 12:54, Alexis Parseghian wrote: > On Fri, Sep 16, 2011 at 11:02 AM, Damien Cassou > wrote: >> It does *not* work for me either. My setup is Pharo #14140, on Ubuntu >> Linux 32bits with a US International keyboard layout. > > Not working here either. Image updated to #14140 as well, debian > testing 64-bit, canadian-french keyboard. > > CogVM -version > 3.9-7 #1 Wed Aug 31 14:50:51 CEST 2011 gcc 4.1.2 > Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-IgorStasenko.123] > > Works fine in Pharo 1.3 #13295, everything else being identical. >
Re: [Pharo-project] slices does not work anymore in Pharo1.4
On Sun, Sep 18, 2011 at 10:00 PM, Stéphane Ducasse < stephane.duca...@inria.fr> wrote: > strange. > BTW normally scriptLoader should not be added to slice since this a private > and strange package. > Yes, but #cleanUpForProduction was there, and I needed to fix that. Soin fact, we should move that method and it friends to a new class. > > Stef > > On Sep 18, 2011, at 8:17 PM, Mariano Martinez Peck wrote: > > > Hi guys. Someting really weird is happening in Pharo. I have 3 dirty > packages: Kernel, KernelTests and ScriptLoader14. I have created an issue > and select those 3 packages. But when the slice is created, it the > MonticelloBrowser, it shows only one dependency: ScriptLoader14. So..it > misses Kernel and KernelTests. What is worst, is that if I then commit such > slice and I see the commits details, it says: "Dependencies: > Kernel-MarianoMartinezPeck.940, ScriptLoader14-MarianoMartinezPeck.175" > WTF? now it shows 2 instead of 3 ? > > > > Can someone reprouce this problem? I think it may be related to the > selection focus in the UI. > > > > Cheers > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] How can I get smart characters in Pharo 1.4?
On Sun, Sep 18, 2011 at 10:43 PM, Camillo Bruni wrote: > so that's an issue with the keyboard input not pharo directly > > see http://code.google.com/p/pharo/issues/detail?id=3748 > > and try to figure out what keyboard events you get in for > > where can I put a Transcript show: to get the results you expect? > meta + " > meta + shift + " > > ctrl + " > ctrl + shift + " > > alt + " > alt + shift + " > > cause I am sure that they are rather randomly distributed around some sane > average... > > On 2011-09-16, at 12:54, Alexis Parseghian wrote: > > On Fri, Sep 16, 2011 at 11:02 AM, Damien Cassou > wrote: > >> It does *not* work for me either. My setup is Pharo #14140, on Ubuntu > >> Linux 32bits with a US International keyboard layout. > > > > Not working here either. Image updated to #14140 as well, debian > > testing 64-bit, canadian-french keyboard. > > > > CogVM -version > > 3.9-7 #1 Wed Aug 31 14:50:51 CEST 2011 gcc 4.1.2 > > Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-IgorStasenko.123] > > > > Works fine in Pharo 1.3 #13295, everything else being identical. > > > > > -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] How can I get smart characters in Pharo 1.4?
see TextEditor >> performCmdActionsWith: aKeyboardEvent shifted: aBoolean return: return | asciiValue actions action| aKeyboardEvent inspect. … and add the inspect line :) On 2011-09-18, at 23:00, Mariano Martinez Peck wrote: > > > On Sun, Sep 18, 2011 at 10:43 PM, Camillo Bruni > wrote: > so that's an issue with the keyboard input not pharo directly > > see http://code.google.com/p/pharo/issues/detail?id=3748 > > and try to figure out what keyboard events you get in for > > > where can I put a Transcript show: to get the results you expect? > > meta + " > meta + shift + " > > ctrl + " > ctrl + shift + " > > alt + " > alt + shift + " > > cause I am sure that they are rather randomly distributed around some sane > average... > > On 2011-09-16, at 12:54, Alexis Parseghian wrote: > > On Fri, Sep 16, 2011 at 11:02 AM, Damien Cassou > > wrote: > >> It does *not* work for me either. My setup is Pharo #14140, on Ubuntu > >> Linux 32bits with a US International keyboard layout. > > > > Not working here either. Image updated to #14140 as well, debian > > testing 64-bit, canadian-french keyboard. > > > > CogVM -version > > 3.9-7 #1 Wed Aug 31 14:50:51 CEST 2011 gcc 4.1.2 > > Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-IgorStasenko.123] > > > > Works fine in Pharo 1.3 #13295, everything else being identical. > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >
[Pharo-project] Failing tests in 1.4
Hi, We should try to keep the tests green: http://code.google.com/p/pharo/issues/list?can=2&q=type=FailingTest -- Marcus Denker -- http://marcusdenker.de
[Pharo-project] [bug tracker ] Issues tagged 1.3
Would be nice to focus on these, too: http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.3 -- Marcus Denker -- http://marcusdenker.de
