#16 loc.s does not work in the Python module

[Jérôme M. Berger]

According to the documentation and the examples, loc.s should be an integer representing a position in loc.buf. However, it is instead a very large integer that does not represent anything.

To be precise, it is an integer representation of a char* that points to the location inside the input string. This is completely useless in Python, especially since we do not have access to the pointer representing the beginning of the string.

I do not know enough SWIG to fix it properly. In the meantime, I am using the following quick patch, which turns loc.s into a string containing a copy of buf starting at the location.

diff -ru d.ref/python/dparser.i d/python/dparser.i
--- d.ref/python/dparser.i 2010-10-02 18:36:54.000000000 +0200
+++ d/python/dparser.i 2011-03-19 08:10:03.000000000 +0100
@@ -6,8 +6,7 @@
%include "pydparser.h"

typedef struct d_loc_t {
- long int s;
- char *pathname, *ws;
+ char *s, *pathname, *ws;
int col, line;
} d_loc_t;

[ptizoom]

Hi, shame yo do not know enough about SWIG, I think the long-int is a nice way of naming a pointer! (not).

your patch is correct since dparse_tables.h has this declaration for d_loc_t.

If you like to accept your challenge, this is to SWIG-ify the dparser and replacing this typedef of d_loc_t ... by ...
..
%include dparse_tables.h
...
but there will be more problems on the way.

I am working on this branch: "autoconf_perl_exp" if you are interested.

the python modules is in need a bit of TAC.

[John Plevyak]

Unfortunately that is going to be pretty inefficient. The problem is that *s is the remaining input, and constructing the python object would require a strlen() of s each time. This would add an O(n^2) component to the cost of parsing. I am not a swig expert, but perhaps someone else can comment.

[John Plevyak]

I changed the definition to "void *s" instead of "long int s" which at least makes it clear that it is a pointer, but doesn't involve a conversion to a python string....

[Jérôme M. Berger]

Yes, the problem is that keeping it as a long int or changing it to a void* renders it useless since we do not have access to the start of the string from the Python code. OTOH, changing it to a char* like I did involves a lot of copies.

IMO, the right way to fix it would be to make it follow the doc, i.e loc.s should be an int giving the index of the current position in the input string. That is what I meant when I said that I do not know enough SWIG to fix it properly.