Re: HAProxy Lua Map.end & reserved keywords

[Willy Tarreau]

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

[Willy Tarreau]

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

[thierry . fournier]

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

[Willy Tarreau]

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

[thierry . fournier]

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 

Re: HAProxy Lua Map.end & reserved keywords

[Thierry Fournier]

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

[Robin H. Johnson]

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

[Willy Tarreau]

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

[Robin H. Johnson]

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

[thierry . fournier]

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
>