- cl-ppcre-devel@lists.common-lisp.net - mailman3.common-lisp.net

[cl-ppcre-devel] report a bug
by Xiangjun Wu 25 Jun '09

25 Jun '09

In order to fix issue of montezuma, http://code.google.com/p/montezuma/issues/detail?id=3, I suppose I found a bug of cl-ppcre. CL-USER> (cl-ppcre:scan (cl-ppcre:create-scanner "(\\w+)*\\@\\w+") "______________________________________" :start 0) ;; Evaluation aborted. It hangs when the number of underscore hit a critical value. I speculate that '\w' includes underscore in regular expression would account for this bug. and replace with other character of '\w' also has this problem. CL-USER> (cl-ppcre:scan (cl-ppcre:create-scanner "(a\\w+)*\\@\\w+") "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" :start 0) ;; Evaluation aborted. but if I eliminate the last \w, it is OK. CL-USER> (cl-ppcre:scan (cl-ppcre:create-scanner "(_\\w+)*\\@") "_______________________________________" :start 0) NIL I also check it in perl, Maybe perl is more efficient in regular expression operation, I raise the number of underscores, but it is OK. $str = "john._______________________________________ __________________________________"; if ($str =~ m/(_*\w+)*\@\w+/) { print "ok\n"; } Please check it and give your comment. 片云天共远永夜月同孤

2 1

[cl-ppcre-devel] RPM Spec File
by Robert Uhl 19 Jun '09

19 Jun '09

I've created a spec file which can be used to build an RPM for CL-PPCRE; it uses common-lisp-controller and _should_ work on any clc-supporting Fedora Lisp. I'm willing to volunteer to maintain the spec file and figure out how to submit RPMs to the Fedora Project; is that okay? -- Robert Uhl <http://public.xdi.org/=ruhl>

2 2

Re: [cl-ppcre-devel] cl-ppcre's use of boolean type
by Edi Weitz 02 Feb '09

02 Feb '09

On Mon, Feb 2, 2009 at 12:19 PM, Derrell Piper <ddp(a)electric-loft.org> wrote: > % grep boolean specials.lisp > (declaim (boolean *extended-mode-p*)) > > Clozure (OpenMCL) doesn't like this: > > ; Warning: Unknown declaration specifier(s) in (BOOLEAN *EXTENDED-MODE-P*) > ; While executing: PROCLAIM, in process listener(1). > > ...because it doesn't have a boolean base type. The HyperSpec seems to > imply in Section 4.4 (The Types and Classes Dictionary) that boolean is a > type, but it isn't in 4.2.3 (Type Specifiers), so I'm not sure what to make > of that. In any case, while SBCL does have a deftype for boolean, it's part > of its built-in FFI support. Please use the mailing list (see Cc) for bug reports. This is a bug in CCL that has been fixed in their development version: http://trac.clozure.com/openmcl/changeset/10606 Thanks, Edi.

1 0

[cl-ppcre-devel] Questions regarding cl-unicode
by Juan Jose Garcia-Ripoll 15 Jan '09

15 Jan '09

Hi, I just subscribed to this mailing list, which I believe is not only for cl-ppcre but also for cl-unicode. If I am wrong, please point me in the right direction :-) My name is Juanjo and I am the maintainer of ECL (http://ecls.sourceforge.net) I am currently interested on completing the support for Unicode in ECL which is, more or less, at the level of what SBCL provides and, in my opinion, far from optimal. I have been pondering several options, but all of them seem like reinventing the wheel, so I finally came to the conclusion that the most sensible strategy would be to turn cl-unicode into a full (optional) replacement of the ANSI Common Lisp functions for dealing with characters and strings, and hope that this would become a de-facto standard. Perhaps that is a too ambitious goal, or maybe it is even futile, given the level of adoption of Unicode among lispers. My concerns are now centered about several questions. 1) Optimize the database information that is built into cl-unicode. ECL currently uses the SBCL procedure for compressing the database and I believe this can be even optimized further. Instead of binary trees or hashes, this leads to two-stages byte table that encodes the currently 209 different combinations of properties. This is important for ECL because we need it to stay lean and simple and because our procedures for exporting data structures in compiled code are not efficient, due to contrants in C compilers. One possibility is that CL-UNICODE reuses the SBCL and ECL databases. Other possibility is to look for even more efficient data stuctures. 2) Add support for the most important Unicode algorithms, which are canonical decomposition of strings, string upper/lower/titlecasing, and string collation. Ideally this should be transparently incorporated into new Common-Lisp functions that can be used to replace the old ones, such as char-upcase, string-equal, etc. Of course, due to the differences between Unicode and ANSI CL, the specifications would change. 3) Add support for the locales database provided by the Unicode consortium. This is essential for implementing string collation, since the ordering of characters is locale dependent. 4) Integration and shipping of cl-unicode with different implementations, if possible. I would be interested on having CL-UNICODE as a contributed package in the ECL source tree, so that it can be activated with a simple configuration option. I believe there are no license issues, and there is only the problem that CL-UNICODE depends on CL-PPCRE (is this dependency essential? could it be eliminated?) Well, maybe this is all BS, but I would like to read your opinions on the topic. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28009 (Spain) http://juanjose.garciaripoll.googlepages.com

2 2

[cl-ppcre-devel] Strange parsing
by Ken Harris 04 Dec '08

04 Dec '08

Hi, all, When playing around with cl-ppcre 2.0.1, I've discovered this: (cl-ppcre::parse-string "?") -> :QUESTION-MARK I found this odd, since :QUESTION-MARK isn't part of the parse-tree grammar in the docs. Two or more ("??", "???", etc.) also leave a :QUESTION-MARK in the parse-tree. I took a quick look at the source code, and it looks like :QUESTION-MARK is used by the lexer (with other keywords like :CLOSE-PAREN), but that it seems to expect them to be replaced by the time you end up with a parse-tree. In comparison, if you try to use ")", like (cl-ppcre::parse-string ")"), it signals a condition in parse-string. I can't find any way to get :CLOSE-PAREN in the output. It's a little weird that it can parse "??" but then signals if you try to use it. If I try to cl-ppcre:scan anything with one of these, I get a ppcre-syntax-error, "Unknown token QUESTION-MARK in parse tree". I don't know if this is a bug or not, and I don't think I'm going to run into a situation where this matters, but there you go. :-) cheers, - Ken

2 1

[cl-ppcre-devel] Matching on very long strings.
by Matthew D. Swank 29 Sep '08

29 Sep '08

I wrote a small character based regex engine specifically to support a lexer. However, the last thing lisp needs is another regex package. cl-ppcre is so nice I would like to adopt it instead. However, since scanners try to find the first place in a string that provides a match, it can be impractical to use on very long strings. Is it possible to create a scanner that only matches at the start index? Matt -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein.

5 10

[cl-ppcre-devel] New release 2.0.1
by Edi Weitz 02 Sep '08

02 Sep '08

ChangeLog: Version 2.0.1 2008-09-02 Fixed faulty declaration (caught by Brent Fulgham) Download: http://weitz.de/files/cl-ppcre.tar.gz

1 0

[cl-ppcre-devel] Question about a strange behavior of cl-ppcre
by 張　漢秀 15 Aug '08

15 Aug '08

Hello, I post this question because the description of this mailing list says that this is the place to post a question about cl-ppcre. I am a user of cl-ppcre on sbcl. I just re-installed cl-ppcre on sbcl, so I guess the version of cl-ppcre is the newest one. I found a strange behavior as below. CL-USER> (format t "~A" (cl-ppcre:regex-replace "a" "a" "\\")) \ CL-USER> (format t "~A" (cl-ppcre:regex-replace "a" "a" "\\\\")) \ CL-USER> (format t "~A" (cl-ppcre:regex-replace "a" "a" "\\\\\\\\")) \\ For me, it is very difficult to figure out what's going on. Would someone kindly help me understand this problem? Han-Soo

2 1

[cl-ppcre-devel] New CL-UNICODE release 0.1.1
by Edi Weitz 24 Jul '08

24 Jul '08

ChangeLog: Version 0.1.1 2008-07-24 Make ADD-HANGUL-NAMES faster for ClozureCL Download: http://weitz.de/files/cl-unicode.tar.gz Edi.

5 9

[cl-ppcre-devel] CL-PPCRE 2.0.0, CL-INTERPOL 0.2.0, CL-UNICODE 0.1.0
by Edi Weitz 23 Jul '08

23 Jul '08

This is a joint announcement for two significant updates and one brand-new library which are all somehow related. See the changelogs for all the details. http://weitz.de/cl-ppcre/ http://weitz.de/cl-unicode/ http://weitz.de/cl-interpol/ Edi.

1 0