Re: [Pharo-users] PIllar >> #visitAnnotatedParagraph:
Ben Coman wrote: PRMarkdownWriter >>visitAnnotatedParagraph: says "Pier seems to lack consistency here ...". Indeed, for #visitAnnotatedParagraph: we currently have: * PRPillarWriter outputs all annotations unchanged * PRMarkdownWriter * prepends the the annotationLabel to the annotationText * has special handling for @@todo by calling #visitCommentedLine: * indicates it does some kind of nesting in a custom way; but I can't work out the semantics; and it interrupts nested list numbering similar to what I reported for comments. * PRVisitor * throws away the annotationLabel by just calling #visitParagraph * knows nothing about @@todo * knows nothing about nesting * PRHTMLWriter has no definition inheriting from PRVisitor * PRLaTeXWriter has no definition inheriting from PRVisitor * PRTextWriter has no definition inheriting from PRVisitor To bring some consistency I propose to... 1. Prepend annotationLabel for all the xxWriters Now I discovered existing tests... PRAnnotatedParagraphTest>>testParseBasic | wiki text tree | wiki := '@@foo bar zork'. text := 'bar zork'. which with this proposal would become... text := 'Foo: bar zork'. PRAnnotatedParagraphTest>>testParseOnlyAnnotation | wiki text tree | wiki := '@@foo'. text := ''. would become text := 'Foo:'. etc! This is since existing PRTextWriter throws the annotation label away. So on the side of: * "include annotation label" we have PRMarkdownWriter & PRLaTeXWriter, * "exclude annotation label" we have PRHTMLWriter & PRTextWriter. To resolve this discrepancy, I lean towards the former, so you can differentiate between annotation types in the produced document. So I will update the PRAnnotatedParagraphTest methods accordingly. btw, with PRHTMLWriter I am using... canvas tag name: 'p'; parameterAt: 'class' put: anAnnotatedParagraph annotation; ... so that each annotation type can be separately styled by CSS. cheers -ben [1] http://forum.world.st/Pharo-users-smallwiki-Pillar-annotations-for-Latex-tt4760229.html 2. Change PRMarkdownWriter to use the code I implemented for nested comments. Have all xxWriters use this also. 3. Drop the @@todo from PRMarkdownWriter, since if you want ToDos to be hidden like a comment, you should just use a comment, e.g." %todo ..." . However this change would alter the semantics of existing users of Pier. So what is the process for such changes? Announce here and wait some period? For consideration, there are currently no tests for annotated paragraphs, so this could be considered outside the existing API ;) - and so I'll add tests, which will be simpler without @@todo. cheers -ben ___ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Re: [Pharo-users] PIllar >> #visitAnnotatedParagraph:
On Sun, Jun 1, 2014 at 11:37 AM, Ben Coman wrote: > etc! This is since existing PRTextWriter throws the annotation label away. > So on the side of: > * "include annotation label" we have PRMarkdownWriter & PRLaTeXWriter, > * "exclude annotation label" we have PRHTMLWriter & PRTextWriter. > To resolve this discrepancy, I lean towards the former I agree that we can do better than the current situation but I disagree with your solution. Annotated paragraphs are a way to have different kinds of paragraphs. Printing the kind is not the right way to do it. I like your solution of using the "class" parameter in HTML. The same should apply in LaTeX. For text, I think the annotation should have no impact on the output (just as it is now). For Markdown, we should probably have the same solution as for HTML. What do you think? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Re: [Pharo-users] STON on ScaledDecimal?
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 : > Hi José, > > On 31 May 2014, at 01:32, José Comesaña 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 >
Re: [Pharo-users] STON on ScaledDecimal?
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 : > 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 : > > Hi José, >> >> On 31 May 2014, at 01:32, José Comesaña 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 >> > >
Re: [Pharo-users] STON on ScaledDecimal?
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. Hope not to bore you too much. Regards 2014-06-02 1:56 GMT+02:00 José Comesaña : > 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 : > > 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 : >> >> Hi José, >>> >>> On 31 May 2014, at 01:32, José Comesaña 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 >>> >> >> >
Re: [Pharo-users] Mac keyboard bindings
Thanks for the help Ben. Submitted! -- View this message in context: http://forum.world.st/Mac-keyboard-bindings-tp4760656p4761232.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Mac keyboard bindings
darrinm wrote: Thanks for the help Ben. Submitted! -- View this message in context: http://forum.world.st/Mac-keyboard-bindings-tp4760656p4761232.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. Cool. Now its good practice to end the mail thread with a link to the issue, since... * It makes it easier for people to pop over for a quick look and comment (and maybe you hook someones interest earlier than otherwise) * Its a lead in for anyone finding the thread in a web search or their own local mailbox cheers -ben
Re: [Pharo-users] Mac keyboard bindings
Ben Coman wrote: darrinm wrote: Thanks for the help Ben. Submitted! -- View this message in context: http://forum.world.st/Mac-keyboard-bindings-tp4760656p4761232.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. Cool. Now its good practice to end the mail thread with a link to the issue, since... * It makes it easier for people to pop over for a quick look and comment (and maybe you hook someones interest earlier than otherwise) * Its a lead in for anyone finding the thread in a web search or their own local mailbox cheers -ben Sorry Darrin :). I now see that you did that, but my mail filters VM stuff into a group I hadn't read yet. cheers -ben
