Re: [Rpm-maint] [rpm-software-management/rpm] Implement a real stack for parametric macro locals (#1409)

2021-03-19 Thread Panu Matilainen
This isn't moving anywhere, closing.

-- 
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/1409#issuecomment-802604852___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Implement a real stack for parametric macro locals (#1409)

2021-03-19 Thread Panu Matilainen
Closed #1409.

-- 
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/1409#event-4480430884___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Implement a real stack for parametric macro locals (#1409)

2020-10-23 Thread Panu Matilainen
Updated to preserve the scoped macro behavior, ie the example case now expands 
to `hello` again.
Just wondering now whether all these macro tables actually make sense - with 
these semantics we could probably get by with just two tables for global and 
non-global macros. It's the argv stuff that needs an actual stack, the macro 
table is a stack in itself...

-- 
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/1409#issuecomment-715280048___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Implement a real stack for parametric macro locals (#1409)

2020-10-23 Thread Panu Matilainen
Oh and FWIW, I've various other doubts and reservations about this 
implementation so there's a good chance that it'll end up trashed (or at least 
drastically revised) anyhow. If getting an actual definition and some testcases 
of how macro scoping is supposed to work comes out of it, that alone would make 
it well worth the trouble :smile: 

The little language hygienist in me thinks non-global macros should be local to 
the scope defined in, ie what's implemented in this PR, and communication 
between macros should be options and arguments instead. There seems to be (from 
this and past discussions) to be varying opinions about that though.

If the general consensus is that the existing scoping should be kept I guess I 
can live with that, but then we need to define what %undefine does: does it 
simply act on the local-most define, regardless of where in the local-global 
axle that happens to be in? It's simple enough as a rule, but I find macros 
undefining allegedly local macros from others somewhat ugly.

-- 
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/1409#issuecomment-715248421___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Implement a real stack for parametric macro locals (#1409)

2020-10-23 Thread Panu Matilainen
Right, I forgot that user-defined scoped macros follow different rules from 
automatic macros as it is. Which is of course undocumented behavior, like most 
of all this...

What's implemented here is a strict local stack for parametric macros, so no, 
it no longer expands to `hello` unless you change the `%define` to `%global`. 
So I guess this would be more drastic change than I initially thought - and I 
admit this isn't all that thoroughly thought out in the first place, hence RFC 
only.

Breaking things is not a goal here, eliminating buggy and ambiguous behavior 
is. But I suppose we should really start by defining and documenting the 
expected behavior wrt scopes and all...

-- 
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/1409#issuecomment-715216459___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Implement a real stack for parametric macro locals (#1409)

2020-10-23 Thread Michael Schroeder
I just glanced over the pull request, so this might be wrong. But shouldn't you 
look in the lower levels as well in findEntry? I.e. if you have:
```
%foo() %bar
%foo2() %define bar hello \
%foo
```
Does %foo2 still expand to `hello`?

-- 
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/1409#issuecomment-715202404___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Implement a real stack for parametric macro locals (#1409)

2020-10-22 Thread Panu Matilainen
FWIW, the macro argument argv needs similar treatment but I'm out of steam for 
the day...

-- 
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/1409#issuecomment-714448481___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Implement a real stack for parametric macro locals (#1409)

2020-10-22 Thread Panu Matilainen
Mixing up local stack and global data never was such a hot idea, as locals 
could get trapped between globals and not freed at appropriate times etc.

This clears the semantics wrt that, fixing a long-standing expected failure in 
the test-suite. Another semantics change is that you can no longer undefine a 
locally defined macro, which eliminates the ambiguity of what should happen 
on %undefine if both global and local macros exist. As such, theres of 
course some potential for breakage too.

Besides clear semantics, this should speed up parametric macro execution as we 
no longer need to huff and puff the global table up and down on entry and exit. 
Furthermore, this paves way to using a hash for the macro table.
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/1409

-- Commit Summary --

  * Separate macro table from the context
  * Implement a real stack for parametric macro locals

-- File Changes --

M build/rpmfc.c (2)
M rpmio/macro.c (180)
M rpmio/rpmmacro.h (1)
M tests/rpmmacro.at (3)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1409.patch
https://github.com/rpm-software-management/rpm/pull/1409.diff

-- 
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/1409
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint