String>expandMacros rules?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

String>expandMacros rules?

timrowledge
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



Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

timrowledge
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.



Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

Levente Uzonyi
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.

Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

timrowledge

> 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.



Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

Levente Uzonyi
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.
Well, on the other hand it has considerable overhead, and probably
inaccurate float printing.

Levente

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Change is inevitable....except from vending machines.

Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

Tobias Pape
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.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

John Brant-2
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

Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

Chris Muller-3
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!

Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

timrowledge
[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.



Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

Chris Muller-3
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.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: String>expandMacros rules?

Hannes Hirzel
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.
>
>
>
>