Hi Brock,
I Tried the other approach also (as used in ParseError) :
--- a/src/modules/query_parser.py Fri Jul 24 11:09:25 2009 -0700
+++ b/src/modules/query_parser.py Mon Jul 27 13:54:32 2009 +0530
@@ -122,7 +122,10 @@
return t
def t_error(self, t):
- raise RuntimeError("%s is a unparseable character")
+ line_break = "\n"
+ raise RuntimeError(line_break.join(["Unable to parse
query.",
+ "%s has an unparseable character" %
self.get_string(),
+ "%s" % (" " * self.get_pos() + "^")])
and this prints error as :
1) pkg search aaaaaaababaaa
.......
File "/usr/lib/python2.4/vendor-packages/pkg/query_parser.py", line 128,
in t_error
raise RuntimeError(line_break.join(["Could not parse query.",
RuntimeError: Could not parse query.
aaaaaaababaaa has an unparseable character
^
2) pkg search aaaaaaaabaaa
......
File "/usr/lib/python2.4/vendor-packages/pkg/query_parser.py", line 128,
in t_error
raise RuntimeError(line_break.join(["Could not parse query.",
RuntimeError: Could not parse query.
aaaaaaaabaaa has an unparseable character
^
I too felt that this approach is much cleaner for user (please provide
you comments).
Apart do let me know about the 2 questions I have asked in previous mail.
Thanks,
~Saurabh
Saurabh Vyas wrote:
Thanks again Brock, so here is another try for this fix :
gladiator@/mypool/Learnings/IPS/new-fix/fix-9693 $ hg pdiffs
diff -r a4a5c41ce199 src/modules/query_parser.py
--- a/src/modules/query_parser.py Fri Jul 24 11:09:25 2009 -0700
+++ b/src/modules/query_parser.py Mon Jul 27 11:35:08 2009 +0530
@@ -122,7 +122,9 @@
return t
def t_error(self, t):
- raise RuntimeError("%s is a unparseable character")
+ raise RuntimeError("%s has an unparseable character
:%s "
+ "at position %d" % (self.get_string(),
t.value[0],
+ self.get_pos()))
def build(self, **kwargs):
self.lexer = lex.lex(object=self, **kwargs)
and the o/p for this (I took 3 results) are :
*1) $ pkg search aaaaaabbbaaa*
.....
File "/usr/lib/python2.4/vendor-packages/pkg/query_parser.py", line
127, in t_error
raise RuntimeError("%s has an unparseable character : %s at
position : %d" % (self.get_string(), t.value[0], self.get_pos() + 1))
RuntimeError: aaaaaabbbaaa has an unparseable character : b at
position : 7
*2) pkg search aaaaaaabbaaa
*.....
File "/usr/lib/python2.4/vendor-packages/pkg/query_parser.py", line
127, in t_error
raise RuntimeError("%s has an unparseable character : %s at
position : %d" % (self.get_string(), t.value[0], self.get_pos() + 1))
RuntimeError: aaaaaaabbaaa has an unparseable character : b at
position : 8
*3) pkg search aaaaaaaabaaa*
.......
File "/usr/lib/python2.4/vendor-packages/pkg/query_parser.py", line
127, in t_error
raise RuntimeError("%s has an unparseable character : %s at
position : %d" % (self.get_string(), t.value[0], self.get_pos() + 1))
RuntimeError: aaaaaaaabaaa has an unparseable character : b at
position : 9
Please let me know if this approach is fine (printing the offending char)
Apart I have 2 questions :
- Is the coding convention I have followed (breaking the ling as it
was crossing 80 chars) correct ?
- Will this error message need localization ? (like we are doing the
same at other places) ?
Thanks,
~Saurabh
Brock Pytlik wrote:
I like this a lot better. I do think we should show the user the
character though, as well as the other information. If you don't want
to put the little carrot under the offending character like
ParseError does, then I'd suggest printing it in the error message.
If someone ever saw ... has an unparseable cahracter at position 123,
and that was all, I think they'd be rightly angry at having to count
out 123 characters.
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
