Re: HAProxy Lua Map.end & reserved keywords
On Sat, Jan 28, 2017 at 09:38:13AM +0100, thierry.fourn...@arpalert.org wrote: > Hi, I prefer the prefix '_' because it is shorter that "match_". I'm > confident for the unicity of these name because there are locked in the > namespace "Map". If someone uses "_beg" or "_end" in other context, > these new words will not conflict the the map pattern matching: the > namespace "Map" differenciate this ones. > > I join a patch. Now applied, thank you Thierry. Willy
Re: HAProxy Lua Map.end & reserved keywords
On Mon, Jan 30, 2017 at 06:19:25PM +0100, thierry.fourn...@arpalert.org wrote: > > Thanks for doing this, I think it's the right way to address it. Do you > > think > > there is a way to emit a warning when the deprecated names are used ? That > > would be nice for next version, though it's not critical. > > > I don't known. I dont think that it is possible. I don't think that Lua > can hook some object / function during parsing for sending warnings. > > I hesitate to mention the deprecated in the documentation, but, finally > I don't. OK don't worry it was just a question just in case. The doc is sufficient. > > I noticed a typo below, I'll try to think about fixing it by hand when > > applying it : > > > > > +.. js:attribute:: Map._ip > > > > > >See the HAProxy configuration.txt file, chapter "Using ACLs and > > > fetching > > >samples" ans subchapter "ACL basics" to understand this pattern > > > matching > > >method. > > > > > > -.. js:attribute:: Map.str > > > + Note that :js:attr:`Map.p` is also available for compatibility. > > > > That's "Map.ip". > > Ok, do you want another patch. No thank you, I already fixed it, it's just that I didn't have the time to merge it yet (lots of local stuff to do). thanks, Willy
Re: HAProxy Lua Map.end & reserved keywords
On Mon, 30 Jan 2017 08:37:16 +0100 Willy Tarreau wrote: > Hi Thierry, > > On Sat, Jan 28, 2017 at 09:38:13AM +0100, thierry.fourn...@arpalert.org wrote: > > >From dc3695a41af3d3a77681cec0ba23005d0370fc07 Mon Sep 17 00:00:00 2001 > > From: Thierry FOURNIER > > Date: Sat, 28 Jan 2017 08:33:08 +0100 > > Subject: [PATCH 1/2] BUG/MINOR: lua: Map.end are not reliable because "end" > > is a reserved keyword > > > > This patch change the names prefixing it by a "_". So "end" becomes "_end". > > The backward compatibility with names without the prefix "_" is assured. > > In other way, another the keyword "end" can be used like this: Map['end']. > > > > Thanks Robin H. Johnson for the bug repport > > > > This should be backported in version 1.6 and 1.7 > > Thanks for doing this, I think it's the right way to address it. Do you think > there is a way to emit a warning when the deprecated names are used ? That > would be nice for next version, though it's not critical. I don't known. I dont think that it is possible. I don't think that Lua can hook some object / function during parsing for sending warnings. I hesitate to mention the deprecated in the documentation, but, finally I don't. > I noticed a typo below, I'll try to think about fixing it by hand when > applying it : > > > +.. js:attribute:: Map._ip > > > >See the HAProxy configuration.txt file, chapter "Using ACLs and fetching > >samples" ans subchapter "ACL basics" to understand this pattern matching > >method. > > > > -.. js:attribute:: Map.str > > + Note that :js:attr:`Map.p` is also available for compatibility. > > That's "Map.ip". Ok, do you want another patch. Thierry
Re: HAProxy Lua Map.end & reserved keywords
Hi Thierry, On Sat, Jan 28, 2017 at 09:38:13AM +0100, thierry.fourn...@arpalert.org wrote: > >From dc3695a41af3d3a77681cec0ba23005d0370fc07 Mon Sep 17 00:00:00 2001 > From: Thierry FOURNIER > Date: Sat, 28 Jan 2017 08:33:08 +0100 > Subject: [PATCH 1/2] BUG/MINOR: lua: Map.end are not reliable because "end" > is a reserved keyword > > This patch change the names prefixing it by a "_". So "end" becomes "_end". > The backward compatibility with names without the prefix "_" is assured. > In other way, another the keyword "end" can be used like this: Map['end']. > > Thanks Robin H. Johnson for the bug repport > > This should be backported in version 1.6 and 1.7 Thanks for doing this, I think it's the right way to address it. Do you think there is a way to emit a warning when the deprecated names are used ? That would be nice for next version, though it's not critical. I noticed a typo below, I'll try to think about fixing it by hand when applying it : > +.. js:attribute:: Map._ip > >See the HAProxy configuration.txt file, chapter "Using ACLs and fetching >samples" ans subchapter "ACL basics" to understand this pattern matching >method. > > -.. js:attribute:: Map.str > + Note that :js:attr:`Map.p` is also available for compatibility. That's "Map.ip". Thanks, Willy
Re: HAProxy Lua Map.end & reserved keywords
On Thu, 12 Jan 2017 09:51:28 + "Robin H. Johnson" wrote: > On Wed, Jan 11, 2017 at 12:17:26PM +0100, Willy Tarreau wrote: > > On Mon, Jan 09, 2017 at 08:47:17PM +, Robin H. Johnson wrote: > > > Maybe Willy would considering changing the name of the matches to 'prefix' > > > & 'suffix' instead of 'beg' & 'end', and just keep beg/end as legacy. > > Another approach would be to have simple rules when mapping a namespace > > to another one. For example we could easily imagine that all "map_something" > > in haproxy are mapped to their exact equivalent name in Lua (thus we would > > have "map_end" instead of "map.end"), or that we could prefix all these > > words by "_" which would give "map._end" which is not much different from > > the haproxy keyword "map_end" and easy enough to remember. > This is actually why I thought of Map.match_str, with a potential idea > that at some point it MIGHT become a bitfield for additional behaviors > (eg the output types per > https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#7.3.1-map). > > The underscore is not sufficiently unique I think, but my knowledge of > Lua is nowhere near as extensive as I'd like. Hi, I prefer the prefix '_' because it is shorter that "match_". I'm confident for the unicity of these name because there are locked in the namespace "Map". If someone uses "_beg" or "_end" in other context, these new words will not conflict the the map pattern matching: the namespace "Map" differenciate this ones. I join a patch. Thierry > -- > Robin Hugh Johnson > E-Mail : robb...@orbis-terrarum.net > Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 > ICQ# : 30269588 or 41961639 > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 > >From dc3695a41af3d3a77681cec0ba23005d0370fc07 Mon Sep 17 00:00:00 2001 From: Thierry FOURNIER Date: Sat, 28 Jan 2017 08:33:08 +0100 Subject: [PATCH 1/2] BUG/MINOR: lua: Map.end are not reliable because "end" is a reserved keyword X-Bogosity: Ham, tests=bogofilter, spamicity=0.001260, version=1.2.4 This patch change the names prefixing it by a "_". So "end" becomes "_end". The backward compatibility with names without the prefix "_" is assured. In other way, another the keyword "end" can be used like this: Map['end']. Thanks Robin H. Johnson for the bug repport This should be backported in version 1.6 and 1.7 --- doc/lua-api/index.rst | 44 ++-- src/hlua.c|4 2 files changed, 34 insertions(+), 14 deletions(-) diff --git a/doc/lua-api/index.rst b/doc/lua-api/index.rst index e04c5b5..b6dcc23 100644 --- a/doc/lua-api/index.rst +++ b/doc/lua-api/index.rst @@ -1863,7 +1863,7 @@ Map class default = "usa" -- Create and load map - geo = Map.new("geo.map", Map.ip); + geo = Map.new("geo.map", Map._ip); -- Create new fetch that returns the user country core.register_fetches("country", function(txn) @@ -1888,60 +1888,76 @@ Map class return loc; end); -.. js:attribute:: Map.int +.. js:attribute:: Map._int See the HAProxy configuration.txt file, chapter "Using ACLs and fetching samples" ans subchapter "ACL basics" to understand this pattern matching method. -.. js:attribute:: Map.ip + Note that :js:attr:`Map.int` is also available for compatibility. + +.. js:attribute:: Map._ip See the HAProxy configuration.txt file, chapter "Using ACLs and fetching samples" ans subchapter "ACL basics" to understand this pattern matching method. -.. js:attribute:: Map.str + Note that :js:attr:`Map.p` is also available for compatibility. + +.. js:attribute:: Map._str See the HAProxy configuration.txt file, chapter "Using ACLs and fetching samples" ans subchapter "ACL basics" to understand this pattern matching method. -.. js:attribute:: Map.beg + Note that :js:attr:`Map.str` is also available for compatibility. + +.. js:attribute:: Map._beg See the HAProxy configuration.txt file, chapter "Using ACLs and fetching samples" ans subchapter "ACL basics" to understand this pattern matching method. -.. js:attribute:: Map.sub + Note that :js:attr:`Map.beg` is also available for compatibility. + +.. js:attribute:: Map._sub See the HAProxy configuration.txt file, chapter "Using ACLs and fetching samples" ans subchapter "ACL basics" to understand this pattern matching method. -.. js:attribute:: Map.dir + Note that :js:attr:`Map.sub` is also available for compatibility. + +.. js:attribute:: Map._dir See the HAProxy configuration.txt file, chapter "Using ACLs and fetching samples" ans subchapter "ACL basics" to understand this pattern matching method. -.. js:attribute:: Map.dom + Note that :js:attr:`Map.dir` is also available for compatibility. + +.. js:attribute:: Map._dom See the HAProxy configuration.txt file, chapter "Using ACLs and fetching samples" ans subchapter "ACL basics" to understand this pattern matching method. -.. js:a
Re: HAProxy Lua Map.end & reserved keywords
Hi. Just a quick message: I don't forget this bug, I'm just just very busy. Thierry Le 12 janvier 2017 10:54:42 AM "Robin H. Johnson" a écrit : On Wed, Jan 11, 2017 at 12:17:26PM +0100, Willy Tarreau wrote: On Mon, Jan 09, 2017 at 08:47:17PM +, Robin H. Johnson wrote: > Maybe Willy would considering changing the name of the matches to 'prefix' > & 'suffix' instead of 'beg' & 'end', and just keep beg/end as legacy. Another approach would be to have simple rules when mapping a namespace to another one. For example we could easily imagine that all "map_something" in haproxy are mapped to their exact equivalent name in Lua (thus we would have "map_end" instead of "map.end"), or that we could prefix all these words by "_" which would give "map._end" which is not much different from the haproxy keyword "map_end" and easy enough to remember. This is actually why I thought of Map.match_str, with a potential idea that at some point it MIGHT become a bitfield for additional behaviors (eg the output types per https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#7.3.1-map). The underscore is not sufficiently unique I think, but my knowledge of Lua is nowhere near as extensive as I'd like. -- Robin Hugh Johnson E-Mail : robb...@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: HAProxy Lua Map.end & reserved keywords
On Wed, Jan 11, 2017 at 12:17:26PM +0100, Willy Tarreau wrote: > On Mon, Jan 09, 2017 at 08:47:17PM +, Robin H. Johnson wrote: > > Maybe Willy would considering changing the name of the matches to 'prefix' > > & 'suffix' instead of 'beg' & 'end', and just keep beg/end as legacy. > Another approach would be to have simple rules when mapping a namespace > to another one. For example we could easily imagine that all "map_something" > in haproxy are mapped to their exact equivalent name in Lua (thus we would > have "map_end" instead of "map.end"), or that we could prefix all these > words by "_" which would give "map._end" which is not much different from > the haproxy keyword "map_end" and easy enough to remember. This is actually why I thought of Map.match_str, with a potential idea that at some point it MIGHT become a bitfield for additional behaviors (eg the output types per https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#7.3.1-map). The underscore is not sufficiently unique I think, but my knowledge of Lua is nowhere near as extensive as I'd like. -- Robin Hugh Johnson E-Mail : robb...@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: HAProxy Lua Map.end & reserved keywords
On Mon, Jan 09, 2017 at 08:47:17PM +, Robin H. Johnson wrote: > Maybe Willy would considering changing the name of the matches to 'prefix' > & 'suffix' instead of 'beg' & 'end', and just keep beg/end as legacy. It's convenient to keep short names there as they're commonly used in anonymous ACLs involving paths. Or maybe "pfx" and "sfx" ? Anyway given that they've been available for something like 10 years I'd say I don't feel much comfortable with renaming this "just" due to incompatibilities between multiple namespaces. This can get worse over time. Moreover, the Lua version already doesn't use exactly the same name as the haproxy variant. Another approach would be to have simple rules when mapping a namespace to another one. For example we could easily imagine that all "map_something" in haproxy are mapped to their exact equivalent name in Lua (thus we would have "map_end" instead of "map.end"), or that we could prefix all these words by "_" which would give "map._end" which is not much different from the haproxy keyword "map_end" and easy enough to remember. Regards, willy
Re: HAProxy Lua Map.end & reserved keywords
On Mon, Jan 09, 2017 at 07:49:40PM +0100, thierry.fourn...@arpalert.org wrote: > > I see two potential ways forward: > > a) Map['end'] # works right now, but ugly > > b) Map.match_end # intent is much clearer > Hi, thank for you comment ! You're absolutely right. This keyword > doesn't run because it is reserved. The good news is that I can change > the API because, obviously, nobody use this keyword :) Nobody used it until me it seems :-). > I agree, the solution "a" is ugly, but it is working now. I dont like > the solution "b", because the form of the word is different than other. > > Maybe "suffix" in place of "end", but I prefer the same word that the > word used in haproxy configs. > > I think that I will rename all the match keywords with the prefix > "match_", and keep the old names available, but undocumented for the > backward compatibility. Maybe Willy would considering changing the name of the matches to 'prefix' & 'suffix' instead of 'beg' & 'end', and just keep beg/end as legacy. -- Robin Hugh Johnson E-Mail : robb...@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 signature.asc Description: Digital signature
Re: HAProxy Lua Map.end & reserved keywords
On Mon, 9 Jan 2017 18:22:56 + "Robin H. Johnson" wrote: > TL;DR: > 'end' is a reserved Lua keyword, and cannot be used as a structure > member as in Map.end. Need to change the naming of constants maybe? > > http://www.arpalert.org/src/haproxy-lua-api/1.7/index.html#map-class > > -- Create and load map > > geo = Map.new("geo.map", Map.ip); > > Now if you want to use the match method 'end', the docs say to use > 'Map.end'. > > This is not legal Lua, because 'end' is a reserved keyword. > > I see two potential ways forward: > a) Map['end'] # works right now, but ugly > b) Map.match_end # intent is much clearer Hi, thank for you comment ! You're absolutely right. This keyword doesn't run because it is reserved. The good news is that I can change the API because, obviously, nobody use this keyword :) I agree, the solution "a" is ugly, but it is working now. I dont like the solution "b", because the form of the word is different than other. Maybe "suffix" in place of "end", but I prefer the same word that the word used in haproxy configs. I think that I will rename all the match keywords with the prefix "match_", and keep the old names available, but undocumented for the backward compatibility. All the ideas are welcome. Thierry > -- > Robin Hugh Johnson > E-Mail : robb...@orbis-terrarum.net > Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 > ICQ# : 30269588 or 41961639 > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 >
HAProxy Lua Map.end & reserved keywords
TL;DR: 'end' is a reserved Lua keyword, and cannot be used as a structure member as in Map.end. Need to change the naming of constants maybe? http://www.arpalert.org/src/haproxy-lua-api/1.7/index.html#map-class > -- Create and load map > geo = Map.new("geo.map", Map.ip); Now if you want to use the match method 'end', the docs say to use 'Map.end'. This is not legal Lua, because 'end' is a reserved keyword. I see two potential ways forward: a) Map['end'] # works right now, but ugly b) Map.match_end # intent is much clearer -- Robin Hugh Johnson E-Mail : robb...@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85