@nim-nim :
One shouldn't expect `nil == false` any more than one would expect `"yes" ==
true`, although both sides *evaluate to* true, ie `("yes" and true)` *is* true.
The language documentation is quite explicit about this, and this has
wonderfully little to do with rpm or the interface it
> What I objected here is exposing false instead of nil when something is unset.
But there's no such thing in the PR linked to this item at all! That's what's
so frustrating to me here and why I've been urging you to look at what was
actually implemented for this ticket:
BTW, the whole state of things is painful and frustrating to me too. If things
can not work out today let’s just forget about it for now. I’m not looking for
a fight and I have no energy left for arguing in circles.
--
You are receiving this because you are subscribed to this thread.
Reply to
@pmatilai Look, the only thing I care about lua side is being able to access
spec state easily and reliably. state = state of macros/variables, state of
flags and option passed to a macro, etc. The best macro logic in the world will
produce erroneous results if it is mistaken about spec state.
Closed #1092 via 67abf72ef57e58251271f5b218f867357d78a4e0.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Sigh. *Obviously* nil is not *equal to* false, any more than, say, None and
False in Python. It would be one bizarre language if they were!
Point out concrete problems in the pull-request, or shut up.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
> Oh, looking closer:
>
> > @nim-nim wrote
> > [...]
> > exist because nil is not the same as false or empty
>
> Yes, nil is not same as empty. It however very explicitly is same as false,
> quoting https://www.lua.org/manual/5.4/manual.html#2.1:
(lua)
> if (nil == false) then print("nil
Oh, looking closer:
> @nim-nim wrote
> [...]
> exist because nil is not the same as false or empty
Yes, nil is not same as empty. It however very explicitly is same as false,
quoting https://www.lua.org/manual/5.4/manual.html#2.1:
> Both nil and false make a condition false; they are
And none of us here would have the slightest clue as to what those fragments
are supposed to be doing and in what context. As I'm sure you know perfectly
well, the devil is in the details.
If you're not interested in testing and reviewing *this* implementation that's
fine, just don't come
I assume option without argument would be true while option with argument would
be string with its value?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/common.lua#_30
exists because nil is not the same as false lua-side.
And no I don’t remember out of hand all the problems it fixed. I definitely
*do* *not* want to remember them. Debugging the corner cases induced by the
@nim-nim, if there's a concrete problem with how testing for option presence is
handled here, lets hear it out. To me it seems to work exactly like one would
expect it to, but sorry ponies not included.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@pmatilai given lua was added as a macro language because the built-in
constructs were driving everyone crazy as soon as you needed some non-trivial
processing I don’t find this argument too convincing :)
Anyway lua has built-in conventions for booleans and nil values, you can’t dump
blindly
The Lua native arguments have to match those of non-Lua macros, otherwise
everybody goes crazy.
For more advanced use there will be that option to let the macro do its own
processing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
@hroncok from the lua language POW you need a tristate for flags: nil (not
passed), true (passed as true), false (passed as false). Otherwise it’s real
easy to be confused when handling things that have a default state absent any
flag, or an antonym (with/without, quiet/verbose, etc), or
One
...and done, now including actual documentation:
https://github.com/rpm-software-management/rpm/pull/1383/commits/a3c336434f0abcfb5c17ef4718429f86873f7f4d
@hroncok - basically yes, options without value are saved as empty strings in
the Lua table so both boolean and value access work as you'd
(This all is making me think if we couldn't actually arrange parametric macros
to appear as native callable functions in Lua...)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
We can't pass NULL's in middle of ARGV_t, but that gave me an idea...
What we could do is pass pass options and a table and the arguments as another,
and prepend this to the anonymous Lua chunk from C side:
```
opt = select(1, ...)
arg = select(2, ...)
```
Which I think makes it all really nice
I'd love to write:
```
%{lua: opt_z, arg = ...; }
```
i.e pass an argument for every option in the macro definition (using the order
specified in the definition). Use nil if the option was not used, 0/1 for
options with no argument.
--
You are receiving this because you are subscribed to
https://lua.programmingpedia.net/en/tutorial/4475/variadic-arguments applies,
eg to walk through arguments:
> $ ./rpm --define "foo(..) %{lua: t = {...}; print('nargs '..rpm.expand('%{#}:
> ')); for i, v in ipairs(t) do print(i..':'..v..' '); end}" --eval "%foo 5 4 3
> 2 -z"
nargs 5: 1:5 2:4
Do you have an example of usage? It's hard to find for me in the tests.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Implemented now as a part of #1383.
There are various ways this could be done, what's implemented now is that %{**}
macro, ie the unprocessed arguments to the macro, are passed to Lua as
arguments. The processed per-option macros are still accessible via
rpm.expand() of course. Feedback
I was about to explore this as well, thanks for filing this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#546 and #547 need to be considered when doing this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Accessing macro arguments via rpm.expand("%1") etc is tedious, non-intuitive
and subject to all sorts of expansion issues. Make macro options and arguments
available to Lua via native data structures (tables in practise), as if they
were just function arguments. Which they largely are.
PR
25 matches
Mail list logo
