Whilst looking for ways of formatting values of my weather data I discovered the String>expandMacros etc methods, which look rather like they are intended to do something like formatting. But there are no comments, no hints about what is supposed to happen, etc, etc. Couldn’t find anything in the swiki either. None of it appears to be used except in a single unit test.
So what is meant to happen here? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Die dulci fruere = Have a nice day |
Following up on this I found what appears to be a very useful printf() equivalent package on SqueakSource - http://www.squeaksource.com/Printf.html
So far any test I try seems to work nicely. Worth considering including stuff like this in the main image IMO. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Has a one-way ticket on the Disoriented Express. |
We already have #format:, which is why #expandMacros* is not being used at
all. I don't think we need a third implementation unless it provides something the other two doesn't. Levente On Sun, 5 Mar 2017, tim Rowledge wrote: > Following up on this I found what appears to be a very useful printf() equivalent package on SqueakSource - http://www.squeaksource.com/Printf.html > > So far any test I try seems to work nicely. Worth considering including stuff like this in the main image IMO. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Useful random insult:- Has a one-way ticket on the Disoriented Express. |
> On 05-03-2017, at 3:08 PM, Levente Uzonyi <[hidden email]> wrote: > > We already have #format:, which is why #expandMacros* is not being used at all. OK; then we should remove the redundant stuff some time. > I don't think we need a third implementation unless it provides > something the other two doesn’t. Oh, the printf stuff most definitely adds something; ‘%-0.1e’ printf: x is a whole lot nicer than (x printShowingDecimalPlaces: 1) padded: #left to: 1 with: $0 .. and having all the other options provided nice and cleanly is a real bonus. It’s well worth quickly loading to take a look at. I suspect quite a bit of code could be cleaned up by using this instead of assorted ad hoc methods. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Change is inevitable....except from vending machines. |
On Sun, 5 Mar 2017, tim Rowledge wrote:
> >> On 05-03-2017, at 3:08 PM, Levente Uzonyi <[hidden email]> wrote: >> >> We already have #format:, which is why #expandMacros* is not being used at all. > > OK; then we should remove the redundant stuff some time. > >> I don't think we need a third implementation unless it provides >> something the other two doesn’t. > > Oh, the printf stuff most definitely adds something; > > ‘%-0.1e’ printf: x > is a whole lot nicer than > (x printShowingDecimalPlaces: 1) padded: #left to: 1 with: $0 > > .. and having all the other options provided nice and cleanly is a real bonus. It’s well worth quickly loading to take a look at. I suspect quite a bit of code could be cleaned up by using this instead of assorted ad hoc methods. inaccurate float printing. Levente > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Change is inevitable....except from vending machines. |
In reply to this post by timrowledge
On 06.03.2017, at 01:58, tim Rowledge <[hidden email]> wrote: > >> On 05-03-2017, at 3:08 PM, Levente Uzonyi <[hidden email]> wrote: >> >> We already have #format:, which is why #expandMacros* is not being used at all. > > OK; then we should remove the redundant stuff some time. > >> I don't think we need a third implementation unless it provides >> something the other two doesn’t. > > Oh, the printf stuff most definitely adds something; > > ‘%-0.1e’ printf: x > is a whole lot nicer than > (x printShowingDecimalPlaces: 1) padded: #left to: 1 with: $0 I would really say the other way round. Really, frist is faster to write, but second is easier to read. I don't have to memorize what character means left or right padding, what number means precision and what means overall length and such. I think the first one is trying too hard (why, yes, C, I am looking at you) Best regards -Tobias > > .. and having all the other options provided nice and cleanly is a real bonus. It’s well worth quickly loading to take a look at. I suspect quite a bit of code could be cleaned up by using this instead of assorted ad hoc methods. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Change is inevitable....except from vending machines. > > > |
In reply to this post by timrowledge
On 03/05/2017 02:23 PM, tim Rowledge wrote:
> Whilst looking for ways of formatting values of my weather data I discovered the String>expandMacros etc methods, which look rather like they are intended to do something like formatting. But there are no comments, no hints about what is supposed to happen, etc, etc. Couldn’t find anything in the swiki either. None of it appears to be used except in a single unit test. > > So what is meant to happen here? I'm guessing that these methods originally came from the Refactoring Browser port. VisualWorks has expandMacros* methods which were used by the RB. When the RB was ported, these were created to support the parts of expandMacros that the RB used. I don't know if the VW expandMacros supports more features. Here are the rules: *) All text is output directly *) Special items are delimited by <> *) <n> inserts a cr *) <t> inserts a tab *) <#p> prints the # argument on the stream *) <#s> appends the # argument on the stream (for strings) *) <#?trueValue:falseValue> if # argument is true output trueValue else output falseValue (good luck if you want a colon in your true value or a greater than in either part) *) If you want a < character in your string, you need %< (I don't remember if the original RB implementation had this, but it appears that Squeak now does) Here's an example, that shows all features: '%<<1p><n><t>Apple<2?s:><n><3s>' expandMacrosWith: 1 with: #() size ~= 1 with: 'This is a string' => '<1 Apples This is a string' As a macro expansion goes, it isn't that powerful, but it is fairly simple. John Brant |
In reply to this post by Tobias Pape
>>> On 05-03-2017, at 3:08 PM, Levente Uzonyi <[hidden email]> wrote:
>>> >>> We already have #format:, which is why #expandMacros* is not being used at all. >> >> OK; then we should remove the redundant stuff some time. >> >>> I don't think we need a third implementation unless it provides >>> something the other two doesn’t. >> >> Oh, the printf stuff most definitely adds something; >> >> ‘%-0.1e’ printf: x >> is a whole lot nicer than >> (x printShowingDecimalPlaces: 1) padded: #left to: 1 with: $0 > > I would really say the other way round. > Really, frist is faster to write, but second is easier to read. > I don't have to memorize what character means left or right padding, what number means precision and what means overall length and such. > > I think the first one is trying too hard (why, yes, C, I am looking at you) My thoughts exactly! |
[removing some mangled quote-misattribution that doesn’t really matter ]
>>> >>> ‘%-0.1e’ printf: x >>> is a whole lot nicer than >>> (x printShowingDecimalPlaces: 1) padded: #left to: 1 with: $0 >> >> I would really say the other way round. >> Really, frist is faster to write, but second is easier to read. >> I don't have to memorize what character means left or right padding, what number means precision and what means overall length and such. >> >> I think the first one is trying too hard (why, yes, C, I am looking at you) > > My thoughts exactly! Well there’s two parts to this a) the ability to neatly format output for printing/displaying in textmorphs/writing to CSV or similar files/transmitting across messaging systems b) the precise syntax used It’s useful to be able to get a Float to print in a suitable format with alignment, precision, padding or whatever. Same with other numbers. We have quite a lot of code scattered about that does various parts of it with varying degrees of niceness. It would be nice to get it nicely aligned so that it is findable without spending too much time. If the best way to do that is with Float>printInMaxWidth:withDecimalPlaces:aligned:paddingChar:etc:etc: then fine; it’s better than the current situation. Then to simplify life we’d probably want versions that assume default width, or precision, or padding and so on, so now you have more messages to know about. Then someone will want a simple spec language to encode the format. And we re-invent the C format in all but name and possibly incompletely anyway. At a total cost of 53 methods across 10 classes (including unit tests) to provide a neat and simple and flexible formatter - even if you don’t like the specific spec language details - this is a pretty good deal. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim The problem with the gene pool is that there is no lifeguard. |
I admit I do find the formatter approach better for code or script
generation; so you can see it! And the tokens are just minimal substitutions, specified at the end of the script string. On Mon, Mar 6, 2017 at 12:43 PM, tim Rowledge <[hidden email]> wrote: > [removing some mangled quote-misattribution that doesn’t really matter ] > >>>> >>>> ‘%-0.1e’ printf: x >>>> is a whole lot nicer than >>>> (x printShowingDecimalPlaces: 1) padded: #left to: 1 with: $0 >>> >>> I would really say the other way round. >>> Really, frist is faster to write, but second is easier to read. >>> I don't have to memorize what character means left or right padding, what number means precision and what means overall length and such. >>> >>> I think the first one is trying too hard (why, yes, C, I am looking at you) >> >> My thoughts exactly! > > Well there’s two parts to this > a) the ability to neatly format output for printing/displaying in textmorphs/writing to CSV or similar files/transmitting across messaging systems > b) the precise syntax used > > It’s useful to be able to get a Float to print in a suitable format with alignment, precision, padding or whatever. Same with other numbers. We have quite a lot of code scattered about that does various parts of it with varying degrees of niceness. It would be nice to get it nicely aligned so that it is findable without spending too much time. > > If the best way to do that is with Float>printInMaxWidth:withDecimalPlaces:aligned:paddingChar:etc:etc: then fine; it’s better than the current situation. Then to simplify life we’d probably want versions that assume default width, or precision, or padding and so on, so now you have more messages to know about. Then someone will want a simple spec language to encode the format. And we re-invent the C format in all but name and possibly incompletely anyway. > > At a total cost of 53 methods across 10 classes (including unit tests) to provide a neat and simple and flexible formatter - even if you don’t like the specific spec language details - this is a pretty good deal. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > The problem with the gene pool is that there is no lifeguard. > > > |
In reply to this post by timrowledge
On 3/6/17, tim Rowledge <[hidden email]> wrote:
> [removing some mangled quote-misattribution that doesn’t really matter ] > >>>> >>>> ‘%-0.1e’ printf: x >>>> is a whole lot nicer than >>>> (x printShowingDecimalPlaces: 1) padded: #left to: 1 with: $0 >>> >>> I would really say the other way round. >>> Really, frist is faster to write, but second is easier to read. >>> I don't have to memorize what character means left or right padding, what >>> number means precision and what means overall length and such. >>> >>> I think the first one is trying too hard (why, yes, C, I am looking at >>> you) >> >> My thoughts exactly! > > Well there’s two parts to this > a) the ability to neatly format output for printing/displaying in > textmorphs/writing to CSV or similar files/transmitting across messaging > systems Yes, this is a definite need. Thanks, Tim that you works on this. > b) the precise syntax used A matter of discussion.... > It’s useful to be able to get a Float to print in a suitable format with > alignment, precision, padding or whatever. Same with other numbers. To have a consistent solution for numbers is a need. > We have > quite a lot of code scattered about that does various parts of it with > varying degrees of niceness. It would be nice to get it nicely aligned so > that it is findable without spending too much time. +1 > If the best way to do that is with > Float>printInMaxWidth:withDecimalPlaces:aligned:paddingChar:etc:etc: then > fine; it’s better than the current situation. Surely a good first step and you will probably have no objections from anybody for this. > Then to simplify life we’d > probably want versions that assume default width, or precision, or padding > and so on, so now you have more messages to know about. Then someone will > want a simple spec language to encode the format. And we re-invent the C > format in all but name and possibly incompletely anyway. Yes, this is an issue. > At a total cost of 53 methods across 10 classes (including unit tests) to > provide a neat and simple and flexible formatter - even if you don’t like > the specific spec language details - this is a pretty good deal. I do not understand what you mean with the last paragraph. To what do the 53 methods refer to? However going for a well known existing formatting language is surely a good thing. Even if you do not like the particular syntax. https://en.wikipedia.org/wiki/Printf_format_string " The format string is written in a simple template language, and specifies a method for rendering an arbitrary number of varied data type parameters into a string" The list here https://en.wikipedia.org/wiki/Printf_format_string#Programming_languages_with_printf has 27 languages implementing the small printf DSL. --Hannes > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > The problem with the gene pool is that there is no lifeguard. > > > > |
Free forum by Nabble | Edit this page |