Hello everybody,
to make it easier to see how/where a RE does (or does not) match I've started a branch on github:
https://github.com/phmarek/cl-ppcre/tree/debugging
During compile-time cl-ppcre::*do-debug* decides whether some tracing output is returned by the compiled match function.
Example for a successful match:
(cl-ppcre:scan-to-strings #?r(^abc(d|(e+)|fff)[xyz]+) "abcfffzzxzx")
*string*: "abcfffzzxzx" SEQ [ 0 0[ ANCHOR [ 0 0[ ANCHOR STR [ 0 3[ "abc" REGISTER [ 3 3[ $1 ALTERNATION [ 3 3[ STR [ 3 3[ "" REGISTER [ 3 3[ $2 SEQ [ 3 3[ STR [ 3 3[ "" STR [ 3 6[ "fff" CHAR-CLASS [ 6 7[ [#<CLOSURE (LAMBDA (CHAR) ... REPETITION [ 7 11[ "abcfffzzxzx" #("fff" NIL)
Example for a non-matching try:
(cl-ppcre:scan-to-strings #?r(^abc(d|(e+)|fff)[xyz]+) "abcffffz")
*string*: "abcffffz" SEQ [ 0 0[ ANCHOR [ 0 0[ ANCHOR STR [ 0 3[ "abc" REGISTER [ 3 3[ $1 ALTERNATION [ 3 3[ STR [ 3 3[ "" REGISTER [ 3 3[ $2 SEQ [ 3 3[ STR [ 3 3[ "" STR [ 3 6[ "fff" CHAR-CLASS NO MATCH [#<CLOSURE (LAMBDA (CHAR) :IN ... NIL
I think this might be useful for other people, so please provide some feedback.
Is the documentations' source doc/index.html? Then I'd provide some text there, too.
Regards,
Phil
Phil,
your change seems useful, but I wonder why you added an extra lambda layer instead of doing the binding in the function returned by create-scanner-aux match-fn. Is there a reason for that?
The html document is the source for the documentation. I'd give the symbol that enables debugging a more specific name which contains the fact that match debugging is enabled and export it from the :cl-ppcre package.
-Hans
On Sun, Sep 30, 2012 at 9:53 AM, Philipp Marek philipp@marek.priv.at wrote:
Hello everybody,
to make it easier to see how/where a RE does (or does not) match I've started a branch on github:
https://github.com/phmarek/cl-ppcre/tree/debugging
During compile-time cl-ppcre::*do-debug* decides whether some tracing output is returned by the compiled match function.
Example for a successful match:
(cl-ppcre:scan-to-strings #?r(^abc(d|(e+)|fff)[xyz]+) "abcfffzzxzx")
*string*: "abcfffzzxzx" SEQ [ 0 0[ ANCHOR [ 0 0[ ANCHOR STR [ 0 3[ "abc" REGISTER [ 3 3[ $1 ALTERNATION [ 3 3[ STR [ 3 3[ "" REGISTER [ 3 3[ $2 SEQ [ 3 3[ STR [ 3 3[ "" STR [ 3 6[ "fff" CHAR-CLASS [ 6 7[ [#<CLOSURE (LAMBDA (CHAR) ... REPETITION [ 7 11[ "abcfffzzxzx" #("fff" NIL)
Example for a non-matching try:
(cl-ppcre:scan-to-strings #?r(^abc(d|(e+)|fff)[xyz]+) "abcffffz")
*string*: "abcffffz" SEQ [ 0 0[ ANCHOR [ 0 0[ ANCHOR STR [ 0 3[ "abc" REGISTER [ 3 3[ $1 ALTERNATION [ 3 3[ STR [ 3 3[ "" REGISTER [ 3 3[ $2 SEQ [ 3 3[ STR [ 3 3[ "" STR [ 3 6[ "fff" CHAR-CLASS NO MATCH [#<CLOSURE (LAMBDA (CHAR) :IN ... NIL
I think this might be useful for other people, so please provide some feedback.
Is the documentations' source doc/index.html? Then I'd provide some text there, too.
Regards,
Phil
cl-ppcre-devel site list cl-ppcre-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cl-ppcre-devel
In addition to what Hans said I'd consider using a special variable like *debug-stream* instead of *do-debug* so that you can direct debugging information to a particular stream.
Also, not only the HTML documentation should be patched, all newly-introduced functions should also have meaningful docstrings, and the docstrings for the new special variables should adhere to the style rules of the rest of the code - use whole sentences, don't start with lower-case chars, don't use abbreviations, etc.
Finally, the documentation should explain that the debugging output will not always reflect the regular expression that was originally entered because the regex engine might have optimized it before debugging kicks in.
Thanks, Edi.
On Sun, Sep 30, 2012 at 10:52 AM, Hans Hübner hans.huebner@gmail.com wrote:
Phil,
your change seems useful, but I wonder why you added an extra lambda layer instead of doing the binding in the function returned by create-scanner-aux match-fn. Is there a reason for that?
The html document is the source for the documentation. I'd give the symbol that enables debugging a more specific name which contains the fact that match debugging is enabled and export it from the :cl-ppcre package.
-Hans
On Sun, Sep 30, 2012 at 9:53 AM, Philipp Marek philipp@marek.priv.at wrote:
Hello everybody,
to make it easier to see how/where a RE does (or does not) match I've started a branch on github:
https://github.com/phmarek/cl-ppcre/tree/debugging
During compile-time cl-ppcre::*do-debug* decides whether some tracing output is returned by the compiled match function.
Example for a successful match:
(cl-ppcre:scan-to-strings #?r(^abc(d|(e+)|fff)[xyz]+) "abcfffzzxzx")
*string*: "abcfffzzxzx" SEQ [ 0 0[ ANCHOR [ 0 0[ ANCHOR STR [ 0 3[ "abc" REGISTER [ 3 3[ $1 ALTERNATION [ 3 3[ STR [ 3 3[ "" REGISTER [ 3 3[ $2 SEQ [ 3 3[ STR [ 3 3[ "" STR [ 3 6[ "fff" CHAR-CLASS [ 6 7[ [#<CLOSURE (LAMBDA (CHAR) ... REPETITION [ 7 11[ "abcfffzzxzx" #("fff" NIL)
Example for a non-matching try:
(cl-ppcre:scan-to-strings #?r(^abc(d|(e+)|fff)[xyz]+) "abcffffz")
*string*: "abcffffz" SEQ [ 0 0[ ANCHOR [ 0 0[ ANCHOR STR [ 0 3[ "abc" REGISTER [ 3 3[ $1 ALTERNATION [ 3 3[ STR [ 3 3[ "" REGISTER [ 3 3[ $2 SEQ [ 3 3[ STR [ 3 3[ "" STR [ 3 6[ "fff" CHAR-CLASS NO MATCH [#<CLOSURE (LAMBDA (CHAR) :IN ... NIL
I think this might be useful for other people, so please provide some feedback.
Is the documentations' source doc/index.html? Then I'd provide some text there, too.
Regards,
Phil
cl-ppcre-devel site list cl-ppcre-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cl-ppcre-devel
cl-ppcre-devel site list cl-ppcre-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cl-ppcre-devel
Hello Edi, hello Hans,
thank you very much for your feedback. I've done nearly all of the requested changes, and wrote some documentation, too.
The points that are still open are * I can't get the (with-trace-output) macro working (see last commit on my branch) - does (eval-when) stop working as expected when it's not in a top-level form? * In practical use I've seen a few errors - wrong indizes, and some other error. Will try to fix, but help is appreciated, of course.
your change seems useful, but I wonder why you added an extra lambda layer instead of doing the binding in the function returned by create-scanner-aux match-fn. Is there a reason for that?
Is this question about the
(let ((scanner (create-scanner-aux match-fn
line? If it is, then I put the (lambda) below to get a minimal diff.
If the question is "why is that not in (create-matcher-aux)" - because *debug-results* and *ppcre-debug-depth* have to be bound _outside_ the create-matcher-aux calls, and not re-bound within.
Or am I misunderstanding your question, still? Then please clarify.
Thank you very much!
Regards,
Phil
On Mon, Oct 1, 2012 at 9:10 AM, Philipp Marek philipp@marek.priv.at wrote:
Is this question about the
(let ((scanner (create-scanner-aux match-fn
line? If it is, then I put the (lambda) below to get a minimal diff.
Minimal diff is not a goal. You can accompany your patch submission with a comment that there are whitespace changes so that reviewers remember to use "diff -w".
-Hans
Hello Hans,
thanks for your answer.
Is this question about the
(let ((scanner (create-scanner-aux match-fn
line? If it is, then I put the (lambda) below to get a minimal diff.
Minimal diff is not a goal.
Well, it was for me, to show the (minimal) difference.
You can accompany your patch submission with a comment that there are whitespace changes so that reviewers remember to use "diff -w".
Yes, but who reads commit messages? ;)
I tried to do as you suggested, folding the LAMBDA back to avoid the extra LET; please take a look at the last commit of my branch, because that gives me a
The variable CL-PPCRE::END-STRING-OFFSET is unbound.
error, although this special variable should be bound as before -- in the LET*.
This is with SBCL 1.0.58.0.debian, in case that makes a difference.
Regards,
Phil
cl-ppcre-devel@common-lisp.net
-
Edi Weitz -
Hans Hübner -
Philipp Marek