On Dec 27, 2007, at 5:41 PM, Ralf S. Engelschall wrote:

> On Thu, Dec 27, 2007, Jeff Johnson wrote:
>
>>     - convert %{@foo:|} to "foo|bar|quux" tuple. %@foo assumes CSV  
>> comma.
>
> Cool. Just the following immediate feedback:
>
> 1. I'm wondering whether it was intentional or just
>    an accident that you implemented it in a way so that only a
>    single-character separator is allowed (instead of an arbitrary
>    string):
>

>    | $ ./rpm --define 'foo foo' --define 'foo bar' --define 'foo  
> quux' --eval "%{@foo:, }"
>    | quux,bar,foo,foo
>
>    I would have expected the output
>
>    | quux, bar, foo, foo
>

Pure laziness, nothing more. In addition to string, character escaping
with \n \t etc needs doing.

The behavior with ! ? and @ interactions likely needs understanding  
first imho.
I have no idea what will happen yet.

There's also the additional decision of whether the macro bodies get  
expanded
(or not). And then there is what to do with parameterized macro  
expansions
and recursion loops and ...


> 2. Additionally, I think there is still a bug as the bottom element is
>    doubled, as the expected output actually should be just:
>
>    | quux, bar, foo
>

The doubled ...foo,foo is different that what I saw with "make  
tmacro". But the rpm CLI
also has multiple macro contexts.

The order is determined by me->prev being the convenient ptr,
so LIFO display was easier to code.

Checking ... reproduced. I'll take a look tomorrow. There's likely an  
extra
interaction with the rpm CLI context somehow.

> 3. Finally, although internally a real "stack", there remains the
>    question for me what the "natural" order of the expansion is? I
>    personally think that for the sequence "Test: foo", "Test: bar",
>    "Test: quux" the expansion of "%{@test:,}" actually should be
>    "foo,bar,quux" and not in "quux,bar,foo". Technically, in mist
>    situations I can think of it will not matter. But it will be easier
>    for a human to match a resulting expansion text to the actual
>    origin(s).
>

Was just easier to use the existing implementation through me->prev.

Doubly linked lists aren't hard ...

73 de Jeff