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

Re: [Pharo-users] STON on ScaledDecimal?

by JosÃ© ComesaÃ±a

Hi Sven 2014-06-02 12:59 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi JosÃ©, > > Thanks for your feedback, suggestions and code. I incorporated a slightly > changed version (fixing the precision issue; you also did not provided the > necessary changes to support writing Fractions and ScaledDecimals). I also > added some unit tests. > Oh, yes, sorry, too late at night, I forgot to paste them, :) > > In #bleedingEdge: > > === > Name: STON-Core-SvenVanCaekenberghe.50 > Author: SvenVanCaekenberghe > Time: 2 June 2014, 12:52:39.808591 pm > UUID: ce24c992-4f32-4f3a-8853-a4a9cf55c453 > Ancestors: STON-Core-SvenVanCaekenberghe.49 > > Add support for Fractions and ScaledDecimals as primitive numbers (thx > JosÃ© ComesaÃ±a): > > - add Fraction>>#stonOn: delegating to STONWriter>>#writeFraction: > - add ScaledDecimal>>#stonOn: delegating to > STONWriter>>#writeScaledDecimal: > - extended STONReader>>#parseNumber to allow / and s notations > - changed STONReader>>#parseNumberFraction to return pure Fractions as > required by ScaledDecimal > === > Name: STON-Tests-SvenVanCaekenberghe.45 > Author: SvenVanCaekenberghe > Time: 2 June 2014, 12:53:39.436939 pm > UUID: bf7a8e27-4b7b-4a0e-b517-6321c1da1694 > Ancestors: STON-Tests-SvenVanCaekenberghe.44 > > Add support for Fractions and ScaledDecimals as primitive numbers (thx > JosÃ© ComesaÃ±a). > > Added specific tests for Fractions and ScaledDecimals > === > > Please let me know if this works for you. > > Regards, > > Sven > > Thank you very much for yor good work. It find it very useful. I have my on #toXml and #fromXml versions, but I think I will change to STON. Regards JosÃ© ComesaÃ±a

June 2, 2014

Re: [Pharo-users] HTML5 Generation

by Damien Cassou

On Mon, Jun 2, 2014 at 1:42 PM, Larry Staton Jr. <larry(a)larrystaton.com> wrote: > I'm not sure if I can just pull in the HTML generation and leave out the rest. I tried for a minute or two and this is not that simple. What I did is reimplementing something much less powerful (but that was ok for my use case): canvas tag name: 'a'; parameterAt: 'href' put: href; with: [ isAnchor ifTrue: [ ... ]. super visitInternalLink: anInternalLink ] If this is enough for you, we can extract this from my code ( http://www.smalltalkhub.com/#!/~Pier/Pillar) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 2, 2014

HTML5 Generation

by Larry Staton Jr.

Iâm writing an implementation of Webmachine[1] in Pharo and Iâm at the point where I need to generate some resources. Webmachine does not care how you represent your resources, so Iâm looking for a way to represent my resources in text/html (or application/xml+xhtml). In Ruby, I use ROAR[2] with Webmachine to represent my resources[3]. I really like how Seaside lets you programmatically construct HTML, but Iâm not sure if I can just pull in the HTML generation and leave out the rest. Is this possible or do I have to recreate ROAR in Smalltalk (which isnât a bad idea!)? Thanks! /ls [1] http://smalltalkhub.com/#!/~statonjr/DLWebmachine [2] https://github.com/apotonick/roar [3] https://speakerdeck.com/statonjr/hypermedia-apis-with-webmachine-and-roar Larry Staton Jr. https://keybase.io/statonjr

June 2, 2014

Re: [Pharo-users] STON on ScaledDecimal?

by jtuchel＠objektfabrik.de

Sorry, I'm trying to do too many things at the same time... Am 02.06.14 13:40, schrieb jtuchel(a)objektfabrik.de: > Okay, here we go ;-) > > VisualWorks also prints the trailing zeros. So maybe the weirdness > lies on the VAST side ;-) > VisualWorks also prints the ScaledDecimal without its scale. it prints FixedPoint, not ScaledDecimal... > It does parse all three correctly: 0.500s3 0.5s3 0.500 the last one should be 0.500s > > Joachim > > > > > Am 02.06.14 13:35, schrieb jtuchel(a)objektfabrik.de: >> >> >> Am 02.06.14 13:03, schrieb Sven Van Caekenberghe: >>> Apart from the class name, another issue is that 0.5s3 prints as >>> 0.500s3 in Pharo, the trailing zeros are possibly not added everywhere. >> >> Hmm, that looks strange to me. If you DisplayIt a 0.5s3 in VAST, you >> get 0.5. If you inspect it, it is debugPrint'ed as 0.5s3. >> I would tend to say that Pharo's display string is strange, not >> necessarily incorrect. I don't have access to the ANSI standard, but >> I guess the fact that there is the s3 already, which says there are 3 >> digits in the fraction part, alrady says enough. >> >> Pharo does parse 0.5s3 correctly, so it can probably juist be >> accepted as a harmless weirdness. VAST, otoh, also parses 0.500s3 >> correctly, so it seems there is no harm done in exchange between VAST >> and Pharo. Not sure about VW, however. >> >> Another question: doesn't creating a fraction when you parse a >> ScaledDecimal make life a bit harder than it should be in terms of >> CPU cycles burnt? Not that this matters for a few hundred or thousand >> numbers, but it might for large files.... Precision-wise there is no >> gain in it, right? >> >> Joachim >> >> >> > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

June 2, 2014

Re: [Pharo-users] STON on ScaledDecimal?

by jtuchel＠objektfabrik.de

Okay, here we go ;-) VisualWorks also prints the trailing zeros. So maybe the weirdness lies on the VAST side ;-) VisualWorks also prints the ScaledDecimal without its scale. It does parse all three correctly: 0.500s3 0.5s3 0.500 Joachim Am 02.06.14 13:35, schrieb jtuchel(a)objektfabrik.de: > > > Am 02.06.14 13:03, schrieb Sven Van Caekenberghe: >> Apart from the class name, another issue is that 0.5s3 prints as >> 0.500s3 in Pharo, the trailing zeros are possibly not added everywhere. > > Hmm, that looks strange to me. If you DisplayIt a 0.5s3 in VAST, you > get 0.5. If you inspect it, it is debugPrint'ed as 0.5s3. > I would tend to say that Pharo's display string is strange, not > necessarily incorrect. I don't have access to the ANSI standard, but I > guess the fact that there is the s3 already, which says there are 3 > digits in the fraction part, alrady says enough. > > Pharo does parse 0.5s3 correctly, so it can probably juist be accepted > as a harmless weirdness. VAST, otoh, also parses 0.500s3 correctly, so > it seems there is no harm done in exchange between VAST and Pharo. Not > sure about VW, however. > > Another question: doesn't creating a fraction when you parse a > ScaledDecimal make life a bit harder than it should be in terms of CPU > cycles burnt? Not that this matters for a few hundred or thousand > numbers, but it might for large files.... Precision-wise there is no > gain in it, right? > > Joachim > > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

June 2, 2014

Re: [Pharo-users] STON on ScaledDecimal?

by jtuchel＠objektfabrik.de

Am 02.06.14 13:03, schrieb Sven Van Caekenberghe: > Apart from the class name, another issue is that 0.5s3 prints as > 0.500s3 in Pharo, the trailing zeros are possibly not added everywhere. Hmm, that looks strange to me. If you DisplayIt a 0.5s3 in VAST, you get 0.5. If you inspect it, it is debugPrint'ed as 0.5s3. I would tend to say that Pharo's display string is strange, not necessarily incorrect. I don't have access to the ANSI standard, but I guess the fact that there is the s3 already, which says there are 3 digits in the fraction part, alrady says enough. Pharo does parse 0.5s3 correctly, so it can probably juist be accepted as a harmless weirdness. VAST, otoh, also parses 0.500s3 correctly, so it seems there is no harm done in exchange between VAST and Pharo. Not sure about VW, however. Another question: doesn't creating a fraction when you parse a ScaledDecimal make life a bit harder than it should be in terms of CPU cycles burnt? Not that this matters for a few hundred or thousand numbers, but it might for large files.... Precision-wise there is no gain in it, right? Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

June 2, 2014

Re: [Pharo-users] STON on ScaledDecimal?

by Sven Van Caekenberghe

On 02 Jun 2014, at 09:34, jtuchel(a)objektfabrik.de wrote: > Hi, > > VA Smalltalk comes with ScaledDecimal, and as far as I know, it always print out the scale of a number, because it could be something like 0.5s3. And I'd guess ScaledDecimal or FixedPoint are pretty common, because the use of this class has been encouraged for the modelling of monetary amounts for decades now. Yes, I realise it is important in some contexts, that is why I added it now. Apart from the class name, another issue is that 0.5s3 prints as 0.500s3 in Pharo, the trailing zeros are possibly not added everywhere. > Joachim > > Am 02.06.14 01:51, schrieb JosÃ© ComesaÃ±a: >> Hi Sven. >> >> First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain. >> >> There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo. >> >> I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start. >> >> You can see here the changes I have made to STONReader >>#parseNumber: >> >> parseNumber >> | negated number | >> negated := readStream peekFor: $-. >> number := self parseNumberInteger. >> (readStream peekFor: $.) >> ifTrue: [ number := number + self parseNumberFraction ]. >> " -------------- >> New from here >> -------------- >> " >> >> (readStream peekFor: $s) >> ifTrue: [ | scale | >> scale := self parseNumberInteger. >> number := ScaledDecimal newFromNumber: number scale: scale ]. >> (readStream peekFor: $/) >> ifTrue: [ | denominator | >> denominator := self parseNumberInteger. >> number := Fraction numerator: number denominator: denominator ]. >> " -------------- >> to here >> -------------- >> " >> >> ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) >> ifTrue: [ number := number * self parseNumberExponent ]. >> negated >> ifTrue: [ number := number negated ]. >> self consumeWhitespace. >> ^ number >> â >> I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things. >> >> I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition: >> >> readStream atEnd not and: [ readStream peek isDigit ] >> >> why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do: >> >> number := Number readFromString: tmpString >> >> That way, we would have a "native" parsing in each language >> >> Hope this helps. If someone needs more information, pleas ask. >> >> Best regards >> >> >> >> 2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> Hi JosÃ©, >> >> On 31 May 2014, at 01:32, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com> wrote: >> >> > Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful. >> > >> > Regards >> >> That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals. >> >> One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ? >> >> I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ? >> >> Sven >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel > mailto:jtuchel@objektfabrik.de > > Fliederweg 1 > http://www.objektfabrik.de > > D-71640 Ludwigsburg > http://joachimtuchel.wordpress.com > > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

June 2, 2014

Re: [Pharo-users] STON on ScaledDecimal?

by Sven Van Caekenberghe

On 02 Jun 2014, at 02:06, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com> wrote: > One last thing. If you do: > > sd := STON fromString: '1345.76s2'. > sd2 := ScaledDecimal readFromString: '1345.76s2'. > > you can note that sd = sd2 returns false, and that sd - sd2 returns 0.00s2. Both numbers are different in the order of precision, because the first has numerator 5918715072783319 and denominator 4398046511104 and the second has numerator 33644 and denominator 25. I still have to fix this. The problem was that #parseNumberFraction returned a Float which let to reduced precision when creating the ScaledDecimal. Now it returns a pure/precise Fraction, with Float conversion happening later, if necessary. > Hope not to bore you too much. No, you do not ;-) > Regards > > > > 2014-06-02 1:56 GMT+02:00 JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com>: > And this is an improved version. More changes to avoid parsing weird things as 123.456s3e2 (it could be improved, for sure, but I don't have any more time...) > > parseNumber > | negated number | > negated := readStream peekFor: $-. > number := self parseNumberInteger. > (readStream peekFor: $.) > ifTrue: [ number := number + self parseNumberFraction ]. > (readStream peekFor: $s) > ifTrue: [ | scale | > scale := self parseNumberInteger. > number := ScaledDecimal newFromNumber: number scale: scale ] > ifFalse: [ > (readStream peekFor: $/) > ifTrue: [ | denominator | > denominator := self parseNumberInteger. > number := Fraction numerator: number denominator: denominator ] > ifFalse: [ > ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) > ifTrue: [ number := number * self parseNumberExponent ]. > ] > ]. > negated > ifTrue: [ number := number negated ]. > self consumeWhitespace. > ^ number > > > 2014-06-02 1:51 GMT+02:00 JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com>: > > Hi Sven. > > First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain. > > There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo. > > I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start. > > You can see here the changes I have made to STONReader >>#parseNumber: > > parseNumber > | negated number | > negated := readStream peekFor: $-. > number := self parseNumberInteger. > (readStream peekFor: $.) > ifTrue: [ number := number + self parseNumberFraction ]. > " -------------- New from here -------------- " > (readStream peekFor: $s) > ifTrue: [ | scale | > scale := self parseNumberInteger. > number := ScaledDecimal newFromNumber: number scale: scale ]. > (readStream peekFor: $/) > ifTrue: [ | denominator | > denominator := self parseNumberInteger. > number := Fraction numerator: number denominator: denominator ]. > " -------------- to here -------------- " > ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) > ifTrue: [ number := number * self parseNumberExponent ]. > negated > ifTrue: [ number := number negated ]. > self consumeWhitespace. > ^ number > â > I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things. > > I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition: > > readStream atEnd not and: [ readStream peek isDigit ] > > why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do: > > number := Number readFromString: tmpString > > That way, we would have a "native" parsing in each language > > Hope this helps. If someone needs more information, pleas ask. > > Best regards > > > > 2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi JosÃ©, > > On 31 May 2014, at 01:32, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com> wrote: > > > Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful. > > > > Regards > > That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals. > > One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ? > > I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ? > > Sven > > >

June 2, 2014

Re: [Pharo-users] STON on ScaledDecimal?

by Sven Van Caekenberghe

Hi JosÃ©, Thanks for your feedback, suggestions and code. I incorporated a slightly changed version (fixing the precision issue; you also did not provided the necessary changes to support writing Fractions and ScaledDecimals). I also added some unit tests. In #bleedingEdge: === Name: STON-Core-SvenVanCaekenberghe.50 Author: SvenVanCaekenberghe Time: 2 June 2014, 12:52:39.808591 pm UUID: ce24c992-4f32-4f3a-8853-a4a9cf55c453 Ancestors: STON-Core-SvenVanCaekenberghe.49 Add support for Fractions and ScaledDecimals as primitive numbers (thx JosÃ© ComesaÃ±a): - add Fraction>>#stonOn: delegating to STONWriter>>#writeFraction: - add ScaledDecimal>>#stonOn: delegating to STONWriter>>#writeScaledDecimal: - extended STONReader>>#parseNumber to allow / and s notations - changed STONReader>>#parseNumberFraction to return pure Fractions as required by ScaledDecimal === Name: STON-Tests-SvenVanCaekenberghe.45 Author: SvenVanCaekenberghe Time: 2 June 2014, 12:53:39.436939 pm UUID: bf7a8e27-4b7b-4a0e-b517-6321c1da1694 Ancestors: STON-Tests-SvenVanCaekenberghe.44 Add support for Fractions and ScaledDecimals as primitive numbers (thx JosÃ© ComesaÃ±a). Added specific tests for Fractions and ScaledDecimals === Please let me know if this works for you. Regards, Sven On 02 Jun 2014, at 01:56, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com> wrote: > And this is an improved version. More changes to avoid parsing weird things as 123.456s3e2 (it could be improved, for sure, but I don't have any more time...) > > parseNumber > | negated number | > negated := readStream peekFor: $-. > number := self parseNumberInteger. > (readStream peekFor: $.) > ifTrue: [ number := number + self parseNumberFraction ]. > (readStream peekFor: $s) > ifTrue: [ | scale | > scale := self parseNumberInteger. > number := ScaledDecimal newFromNumber: number scale: scale ] > ifFalse: [ > (readStream peekFor: $/) > ifTrue: [ | denominator | > denominator := self parseNumberInteger. > number := Fraction numerator: number denominator: denominator ] > ifFalse: [ > ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) > ifTrue: [ number := number * self parseNumberExponent ]. > ] > ]. > negated > ifTrue: [ number := number negated ]. > self consumeWhitespace. > ^ number > > > 2014-06-02 1:51 GMT+02:00 JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com>: > Hi Sven. > > First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain. > > There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo. > > I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start. > > You can see here the changes I have made to STONReader >>#parseNumber: > > parseNumber > | negated number | > negated := readStream peekFor: $-. > number := self parseNumberInteger. > (readStream peekFor: $.) > ifTrue: [ number := number + self parseNumberFraction ]. > " -------------- New from here -------------- " > (readStream peekFor: $s) > ifTrue: [ | scale | > scale := self parseNumberInteger. > number := ScaledDecimal newFromNumber: number scale: scale ]. > (readStream peekFor: $/) > ifTrue: [ | denominator | > denominator := self parseNumberInteger. > number := Fraction numerator: number denominator: denominator ]. > " -------------- to here -------------- " > ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) > ifTrue: [ number := number * self parseNumberExponent ]. > negated > ifTrue: [ number := number negated ]. > self consumeWhitespace. > ^ number > â > I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things. > > I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition: > > readStream atEnd not and: [ readStream peek isDigit ] > > why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do: > > number := Number readFromString: tmpString > > That way, we would have a "native" parsing in each language > > Hope this helps. If someone needs more information, pleas ask. > > Best regards > > > > 2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi JosÃ©, > > On 31 May 2014, at 01:32, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com> wrote: > > > Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful. > > > > Regards > > That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals. > > One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ? > > I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ? > > Sven > >

June 2, 2014

Re: [Pharo-users] STON on ScaledDecimal?

by jtuchel＠objektfabrik.de

Hi, VA Smalltalk comes with ScaledDecimal, and as far as I know, it always print out the scale of a number, because it could be something like 0.5s3. And I'd guess ScaledDecimal or FixedPoint are pretty common, because the use of this class has been encouraged for the modelling of monetary amounts for decades now. Joachim Am 02.06.14 01:51, schrieb JosÃ© ComesaÃ±a: > Hi Sven. > > First of all, I know that in VisualWorks there exists a class called > FixedPoint, that is (more or less) similar to ScaledDecimal (is what > the class comment says). But, instead of 123.45s2, VWs writes 123.45s. > NEVERTHELESS, it can read 123.45s2 with no pain. > > There exists a Fraction type also in VW, which, I believe, uses the > same notation as in Pharo. > > I know that portability is an important issue, but, at least for me, > portability from Pharo to Pharo is the most important. I depend on > ScaledDecimal for an application (for storing money values -changing > the storage mode is not an option now-) and need the possibility of > converting it to string and reading it back. The string version is my > database, that gets loaded into memory upon program start. > > You can see here the changes I have made to STONReader >>#parseNumber: > > parseNumber > | negated number | > negated := readStream peekFor: $-. > number := self parseNumberInteger. > (readStream peekFor: $.) > ifTrue: [ number := number + self parseNumberFraction ]. > " -------------- New from here -------------- " > (readStream peekFor: $s) > ifTrue: [ | scale | > scale := self parseNumberInteger. > number := ScaledDecimal newFromNumber: number scale: scale ]. > (readStream peekFor: $/) > ifTrue: [ | denominator | > denominator := self parseNumberInteger. > number := Fraction numerator: number denominator: denominator ]. > " -------------- to here -------------- " > ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) > ifTrue: [ number := number * self parseNumberExponent ]. > negated > ifTrue: [ number := number negated ]. > self consumeWhitespace. > ^ number > â > I am a newbie about STON. I don't know if it is correct, but it works > for me, at least for some tests I have made. I know it needs > improvements, thinking about strange strings we could receive. But I > trust the writer not to create such weird things. > > I could suggest another way of making the function of parseNumber (OK, > OK, I know I am thinking from a Pharo-only perspective...). Seeing > that number parsing always ends with this condition: > > readStream atEnd not and: [ readStream peek isDigit ] > > why not create a temporary string (including possibility of $e, $s, > $/, even $@ ...) to that point (tmpString) and do: > > number := Number readFromString: tmpString > > That way, we would have a "native" parsing in each language > > Hope this helps. If someone needs more information, pleas ask. > > Best regards > > > > 2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>>: > > Hi JosÃ©, > > On 31 May 2014, at 01:32, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com > <mailto:jose.comesana@gmail.com>> wrote: > > > Wouldn't it be good if STON could save ScaledDecimals as > 12345.678s?. That way, we could read them back again as > ScaledDecimal, instead of Float. I have tried and it seems quite > useful. > > > > Regards > > That is an interesting idea and it is probably nice to have for > those relying on ScaledDecimals. > > One of the ideas of STON is to be portable across dialects, so I > am wondering if ScaledDecimals exists everywhere ? > > I am curious as to how you did it though, since STONReader > basically contains its own number parser. Could you share your code ? > > Sven > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

June 2, 2014