> I'll try to get it into a submittable state tomorrow or so.
...except that nope, didn't see a way to achieve this with a reasonable effort.
Doesn't necessarily mean there isn't one, but I lost my appetite for now. I
might revisit at some later time, but if somebody wants to pick up the pieces
No worries. I got tangled in the argument/option parsing/passing recursion -
I've a feeling the mb->args vs argument macros and all isn't quite right as it
is, and just ran out of steam for now. So I was actually kinda hoping you'd say
that...
Meanwhile, here's a related step towards making
Sorry, I didn't want to discourage you. I'll open a pull request with that
rpmExpandThisMacro() implementation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1398.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1398#event-3902168598___
Rpm-maint mailing list
> you should add a `rpmExpandThisMacro(rpmMacroContext mc, const char *n,
> ARGV_t args)` function which can be used to expand macro `n` with the
> provided args without needing the rpmExpand arg hackery. Note that this call
> would not expand the arguments.
@mlschroe , it's not so much that
Now that the table version exists, I don't feel any particular need to hang on
to the multi-argument auto-join thing. The convenience of not having to
manually and tediously construct the string was the point of that, but since
*that* can be avoided with the table syntax, eliminating the string
Rebased again to include the other new Lua/macro stuff and a new snapshot build
at https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/build/1712012/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
After some more consideration, renamed to `macros`. This is more in line with
our other globals (sources, patches) and leaves room for iteration options in
the future.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai pushed 1 commit.
81e1068bf1193bceb0ca8c6abb3be95c250eb3ee Implement a table-like shortcut to
rpm macros in Lua
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Updated to have function calls only accept a single string or table.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai pushed 1 commit.
7d1d772be5f2cdf8d4ecb0a0dcc79514ab1c9658 Implement a table-like shortcut to
rpm macros in Lua
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
On a related note on the builtins: I've been thinking about turning the
builtins into parametric macros, or at least blur the difference considerably
(and allow dynamic registering of builtins). The syntax differs a bit and the
calling convention much more, so it's not entirely
Indeed, either 1 string or 1 list (table) sounds more natural to me.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Regarding the macro call feature: I was going to suggest something like that.
Perl, for example, offers both `system(STRING)` and `system(LIST)`. The STRING
version uses the shell to do the call, so you get argument splitting and
variable expansion. The LIST version does a verbatim call without
Okay, iteration is a fair point. The catch is that we don't support that at
all, and I'm not sure we ever will.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Typically if I have some `macro`, then the collection of them is plural
`macros`. If you want to iterate over the collection, then you want to have
something like `for macro in macros do ...`. Of course you can have `for m in
macro do ...` or something similar, but that does not help with
Updated:
- macro call arguments are auto-quoted if passed as a table
- more docs on the behavior
- build the strings on Lua side and use Lua rpm.expand() call consistently for
all macro expansions
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
@pmatilai pushed 1 commit.
252c9360f6572836f903c05470f7ced5c09e57e8 Implement a table-like shortcut to
rpm macros in Lua
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
The plural form could be argued, yes. I considered it, but somehow it seems
weird to me in this context, in particular the dot-syntax (eg
`macros.with('foo')`). Do you have some concrete reason why `macro['_libdir']`
seems objectionable to you? I'm just curious, as I actually find that more
> * rename the global `m` table to `macro`, it's indeed better for
> readability
Thx, just nitpicking, shouldn't it be `macros`? The `macro._libdir ==
'/usr/lib64'` is probably Ok, but `macro['zzz']` is questionable.
--
You are receiving this because you are subscribed to this thread.
Regarding the auto-quotation behavior, I think we could leave that up to the
caller, the Lua table syntax lends itself to this nicely:
```
res = macro.foo(1, 2, 3)
res = macro.foo({1, 2, 3})
```
In the first case, no automatic quotation is done so it's *literally*
equivalent of joining the
But then you should change the code so that it does not accept more than one
argument. Everything else is not "identical" and does not match the user
expectation.
Btw, please do not use %quote, this will break if the argument contains an
unmatched '}' character. It's much saner to simply
This is starting to spin out of scope...
This PR is not about changing parametric macro semantics at all, it's about
making them more accessible from Lua, and basically I think results need to be
identical between `rpm.expand('%foo [...])` and `macro.foo([...])` or everybody
will go crazy.
Updated:
- rename the global `m` table to `macro`, it's indeed better for readability
- implement undefine via nil assignment
- automatically quote parametric macro arguments when called as Lua function
- rebased
- new build of this state at
@pmatilai pushed 1 commit.
495252a69443f1987990404aa8b211d0f6bc2148 Implement a table-like shortcut to
rpm macros in Lua
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> But then you should change the code so that it does not accept more than one
> argument. Everything else is not "identical" and does not match the user
> expectation.
Hmm. I fail to see the problem here, it's just a shortcut for building that
string yourself, ie these two should be equal:
(Hmm, an unmatched '}' will break the expansion anyway, so nevermind about not
using %quote.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Looking back on my code, I see it required both the expanded and non expanded
variants. The general case is expansion (recursively, till there is nothing
else to process). However in less frequent but tricky cases expanding can be
premature and you really need to pass things as is (I've come to
But in the function call, we just catenate the args into a string that gets
passed plain old rpmExpand(), so if one method expands them and the other
doesn't, you can get quite different results. Which doesn't seem sane.
--
You are receiving this because you are subscribed to this thread.
No, this is not about the called macro. My point is with macro calls via
rpm.expand, we expand macros first and then split into args. With your new call
from lua we already provide the args, so it's not clear if we want expansion or
not. Both works, it's just a matter of documentation.
--
You
Calling a parametric macro as a function vs traditional rpm.expand() needs to
behave identically as the *called* macro will have no idea about any of this.
Auto-quoting is of course already on a slippery slope.
--
You are receiving this because you are subscribed to this thread.
Reply to this
Oh, you want the arguments in a macro call expanded? I was going to suggest
that we should add code to make them stay unexpanded (i.e. double the '%'
chars). There's merit in both sides, I guess.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Yup. The reason it's not there now is that from wherever I had this idea it
might prevent macro expansion in said arguments, and somehow never got around
to check what it actually did :roll_eyes: (I'm getting old, it's just three
years since I added that thing...)
Now actually checking, yeah
You can easily implement quoting by always surrounding the arguments with 0x1f
characters, see splitQuoted() and the %quote macro.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Other random remarks of the day:
- We could of course put it into rpm namespace, and macro-heavy users can
declare their own shortcut, eg `m = rpm.macro; m._libdir = "foo"`, but then if
every Lua macro starts with that, we've failed somewhere
- This doesn't enable *anything* new, it's all just
Could of course call the table `macro`to make it blindingly obvious what that
is, although I do think the context makes it quite clear anyhow. It's not like
rpm macros ever were nice or readable to begin with
:stuck_out_tongue_winking_eye:
Macros are by far the most accessed thing from rpm
> > There's ample potential for bikeshedding here (eg what to call the global
> > table)
>
> Indeed :) `m` is nice and short, but possibly a bit too much? What about
> including it in the `rpm` namespace as `rpm.m`?
I agree with @hroncok. I think the code should be readable on the first place.
It stops being nice and short if we put it into the rpm namespace :-/
Unlike a generic Lua library extension, rpm owns the environment in which these
things run so I don't see a reason we couldn't maximise the convenience. Too
bad `%` is not a legitimate character in Lua names... OTOH, `_` is
> There's ample potential for bikeshedding here (eg what to call the global
> table)
Indeed :) `m` is nice and short, but possibly a bit too much? What about
including it in the `rpm` namespace as `rpm.m`?
--
You are receiving this because you are subscribed to this thread.
Reply to this
https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/ has pre-built
binaries for Fedora, updated manually once/twice a week. Usually those are
strictly from rpm git master but it's not like I can't make exceptions...
If that works that will be terrific! However as usual the devil is in the
detail, is it available as a pre-built rpm somewhere or do one need to build
his own binary?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
See the docs + test cases in the commit for details, if something isn't covered
then do ask.
There's ample potential for bikeshedding here (eg what to call the global
table), should it do some sort of auto-quoting for empty strings as arguments
etc.
Tagging @hroncok @nim-nim @mlschroe
42 matches
Mail list logo
