June 2021 - Pharo-users - lists.pharo.org

Zn and AWS - retrieving object versions?

by Tim Mackinnon

Hi everyone - Iâm wondering if someone knows the trick to listing object versions in AWS S3? I was previously using a non-Zn library (there are a few around - but they are quite old and Iâm not sure how much they are maintained) - however I hadnât realised that Zn actually supports S3 until I read it a bit carefully and realised that I needed to load an extra AWS group. So - I have a bucket that is versioned, and I wanted to read the versions of an object - and hopefully be able to read the contents of an older version. I can list the contents of a bucket, but when I try to read the versions of an object - I get a forbidden error - which when I dig deeper gives a stranger explanation? I have confirmed that the AWS CLI is able to list versions in that bucket - so Iâm a bit confused what the issue might be? (client := ZnAWSS3Client new) accessKeyId: 'xxx'; secretAccessKey: âyyyyy'; checkIntegrity: true. client buckets. âWorks" client keysIn: 'mtt-dataâ. âWorks" client at: 'mtt-data' -> 'sample.txtâ. âWorks" client keysIn: 'mtt-data' query: (Dictionary with: 'versions'->nil). âGives an error?â HTTP/1.1 403 Forbidden <?xml version="1.0" encoding="UTF-8"?> <Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>xxx</AWSAccessKeyId><StringToSign>GET Has anyone tried doing this - Iâm sure there is something really simple that I am missing? Tim

June 17, 2021

Re: Rounding in Floats

by Richard O'Keefe

"first we are not good in math" First, I am not criticising YOU. Pharo's weird ScaledDecimal is Squeak's weird ScaledDecimal and you have not changed it. Fine. "second Pharo is what we have and we never said that it is the best system ever" True, but irrelevant. "third I never saw a piece of code from you" That is not true. Why, in this thread alone I contributed #roundOut. I have provided several pieces of code in this mailing list over the years. You can say that my code is no good, or that you don't want it, or that you think there is a better way to do the (admittedly small) things that I have provided, but if you never saw them you must have shut your eyes. In addition, a snapshot of my system is available on the web for anyone to play with. I shall post here when my GitHub repository is populated; I just have to clear a few more things out of the local directory that I don't have the right to distribute. (For example, benchmarking my CSV library against NeoCSV meant having to have NeoCSV, but it's not mine to distribute.) On Thu, 17 Jun 2021 at 08:45, ducasse <stepharo(a)netcourrier.com> wrote: > > Richard > > As I said it thousands of times, > - first we are not good in math > - second Pharo is what we have and we never said that it is the best system ever > we just enhanced daily > - third, I never saw a piece of code from you. > - if you want to see Pharo improve (which I doubt about) just send us code and tests > > Iâm sad that you systematically ignore any of my emails on the topic. > You could have an impact but you prefer to hide yourselves in your tower. Good luck with it. > > S.

June 17, 2021

Re: Rounding in Floats

by Richard O'Keefe

2Decimal floats are (a) part of the IEEE 758-2008 standard for floating-point arithmetic, (b) implemented as part of the instruction set in IBM z/Series and POWER computers, (c) allowed for in the current C standard, (d) partially supported by GCC https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Decimal-Float.html and (e) available for most machines via the "reference implementation" in C. The current COBOL standard basically defines its arithmetic in terms of this. Java of course has BigDecimal. While decimal floats became part of IEEE 754 in 2008, they were previously covered by IEEE 854. Reverting to ScaledDecimal, let us consider the 10.0s1 / 3 example. There is a huge problem here with no really satisfactory answer. In my library, it currently answers 3.3s1, exactly equal to 33/10. In Squeak/Pharo, it answers "I am really 10/3 but print me with one decimal", so you see 3.3a1 but it *behaves* like 10.3. In VisualAge Smalltalk you get 3.333333333333333333333333333333 If it were not for the fact that the ANSI Smalltalk standard appears to require that <scaled decimal> / <integer> yield a <scaled decimal>, I would prefer to answer 10/3. Decimals just plain are not closed under division (although they are closed under addition, subtraction, and multiplication). When it comes to scaled decimals, the ANSI Smalltalk standard is frankly a mess. Amongst other things, it defers the semantics of operations on them to the Language-Independent Arithmetic standard, which explicitly denies having anything to say about them! I understand why my library does what it does. I even tried to publish a paper about it. I understand why VisualAge Smalltalk does what it does. (I've read IBM/360 PrincOps.) I do NOT understand why Squeak and Pharo do what they do, and if anyone knows the rationale for their ScaledDecmal please tell me. On Thu, 17 Jun 2021 at 06:29, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > I didn't know there were decimal floats. > > Are they used elsewhere? > > Esteban A. Maringolo > > On Wed, Jun 16, 2021 at 11:20 AM Konrad Hinsen > <konrad.hinsen(a)fastmail.net> wrote: > > > > On 16/06/2021 15:52, Sven Van Caekenberghe wrote: > > > I am also a bit intrigued by this. Like you said: several other programming languages (I tried a couple of Common Lisp and Scheme implementations) do the same as Pharo, but handheld calculators, normal and scientific, do not. > > > > Handheld calculators use decimal floats, not binary floats. That doesn't > > remove rounding issues, but it makes conversion to and from print > > representations loss-free. > > > > > > Konrad

June 17, 2021

Re: Reading http post data using Zinc

by Sven Van Caekenberghe

Hi Davide, > On 16 Jun 2021, at 23:17, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Hi Guys, > I'm posting from an http form and I'm wondering how to read data from the > post. It seems the request should give a ZnMultiPartFormDataEntity, but I > can't find how to use it. > > Can you help me please? > Davide > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html It depends on how the form is posted (there are two approaches). A working example of both can be found in ZnDefaultServerDelegate>>#formTest2: and #formTest3: ZnServerTest>>#testFormTest2: and #testFormTest3: exercise this functionality Basically, you just take the entity from the request and use it. HTH, Sven

June 16, 2021

Reading http post data using Zinc

by Davide Varvello

Hi Guys, I'm posting from an http form and I'm wondering how to read data from the post. It seems the request should give a ZnMultiPartFormDataEntity, but I can't find how to use it. Can you help me please? Davide -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 16, 2021

Re: Rounding in Floats

by ducasse

Richard As I said it thousands of times, - first we are not good in math - second Pharo is what we have and we never said that it is the best system ever we just enhanced daily - third, I never saw a piece of code from you. - if you want to see Pharo improve (which I doubt about) just send us code and tests Iâm sad that you systematically ignore any of my emails on the topic. You could have an impact but you prefer to hide yourselves in your tower. Good luck with it. S.

June 16, 2021

Re: Rounding in Floats

by Konrad Hinsen

Sven Van Caekenberghe <sven(a)stfx.eu> writes: > It would be possible (and maybe it has already been done) to > implement/add such a decimal floating point number to Pharo. It would > require reimplementing all operations from scratch (esp. sin/cos/tan > log/exp and so on), it would be slow, but interesting. That would be an interesting experiment indeed. Either use one of the IEEE754 decimal float formats (https://en.wikipedia.org/wiki/Decimal_floating_point) or Douglas Crockford's DEC64 proposal (https://www.crockford.com/dec64.html, which strangely enough does not refer to the older IEEE standard). There are implementations of both for various other languages that can serve as inspiration. Konrad.

June 16, 2021

Re: Rounding in Floats

by Sven Van Caekenberghe

> On 16 Jun 2021, at 16:20, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > On 16/06/2021 15:52, Sven Van Caekenberghe wrote: >> I am also a bit intrigued by this. Like you said: several other programming languages (I tried a couple of Common Lisp and Scheme implementations) do the same as Pharo, but handheld calculators, normal and scientific, do not. > > Handheld calculators use decimal floats, not binary floats. That doesn't remove rounding issues, but it makes conversion to and from print representations loss-free. > > > Konrad > mmm, this is interesting. It would be possible (and maybe it has already been done) to implement/add such a decimal floating point number to Pharo. It would require reimplementing all operations from scratch (esp. sin/cos/tan log/exp and so on), it would be slow, but interesting.

June 16, 2021

Re: Rounding in Floats

by Esteban Maringolo

I didn't know there were decimal floats. Are they used elsewhere? Esteban A. Maringolo On Wed, Jun 16, 2021 at 11:20 AM Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > On 16/06/2021 15:52, Sven Van Caekenberghe wrote: > > I am also a bit intrigued by this. Like you said: several other programming languages (I tried a couple of Common Lisp and Scheme implementations) do the same as Pharo, but handheld calculators, normal and scientific, do not. > > Handheld calculators use decimal floats, not binary floats. That doesn't > remove rounding issues, but it makes conversion to and from print > representations loss-free. > > > Konrad

June 16, 2021

Re: Rounding in Floats

by Esteban Maringolo

On Wed, Jun 16, 2021 at 10:52 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I am also a bit intrigued by this. Like you said: several other programming languages (I tried a couple of Common Lisp and Scheme implementations) do the same as Pharo, but handheld calculators, normal and scientific, do not. > > I think that going for 1/10 fractions/precision is not going to help: you got a division by 113 in your formula [https://en.wikipedia.org/wiki/Handicap_(golf)] this will give smaller fractions. And the reasons behind why they chose 113 are still unknown, because that number is used to get a "difficulty coefficient", so if the course is rated a 125, then 125/113 will give you roughly a ~1.1 coefficient. They could have used 100. > The problem is not the calculation (modern 64-bit floats as in Pharo are plenty accurate), it is how you handle results. You should just round it correctly and be done with it. > Note that > a roundTo: 0.00000000000001. (1e-14) still gives 4.5 > it is only one step further that you hit the limit and get the ugly but correct result. I'm not doing that, and I only store the original number (which has a fixed decimal) and the "rounded" (to no decimals) number, all intermediate numbers are re-calculated (maybe cached) but not stored elsewhere. What I might be doing wrong is to store the original index as float instead of a Decimal number. > When computing with money, you would be inclined to put everything in cents (because you cannot divide them further). But once you start computing percentage discounts or taxes, you again get problems. At each of those steps you must make sure that no cents are lost. And that includes adding a "rounding" item for any difference in all invoices, orders, etc. Regards! Esteban A. Maringolo

June 16, 2021