January 2005 - cl-ppcre-devel@common-lisp.net

[cl-ppcre-devel] Using cl-ppcre in a text editor
by Lawrence Mitchell 03 Feb '05

03 Feb '05

Hello there, I'm looking at trying to use cl-ppcre to add regular expression support to the Climacs editor (<URL: http://common-lisp.net/project/climacs/>). A few things spring to mind: o Licensing differences. Climacs is released under the LGPL, while cl-ppcre is under as BSD-style license. I don't think this is a problem (as far as I can tell from reading the licenses), but if you know otherwise, I'd be grateful to hear. o How to best match up cl-ppcre's matching on strings with climacs' idea of a buffer. A climacs buffer is a sequence of objects (which may or may not be characters, but we'll ignore that for the moment). Now, I can easily generate a string of the contents of the buffer, and call SCAN (or whatever) on the string. However, this is going to be slow for large buffers (especially if we find something just after point, we've still constructed the whole buffer-string). The "obvious" solution to this is to use streams instead (probably), so, I wonder if cl-ppcre would be amenable to something like this? On another, somewhat unrelated note. One thing that one would like to do is regexp search and replace, now, if I know how many groups the user is going to input into their regexp before the fact, I can use REGISTER-GROUPS-BIND to get at the substring matches via variables. I guess there isn't any way to do this without knowing the input beforehand. So is the idea then just to use SCAN and then manually grab the substrings via REG-STARTS and REG-ENDS, or have I missed something obvious? Cheers, Lawrence -- Lawrence Mitchell <wencel(a)gmail.com>

2 3

[cl-ppcre-devel] Need help with a slow regexp
by pete-cl-ppcre＠kazmier.com 25 Jan '05

25 Jan '05

Hello, Not sure if this is the appropriate forum as the email is not related to the development of cl-ppcre, but I did not find a list for users. Please feel free to redirect me elsewhere. I could use some help in figuring out why this regexp is so slow. As far as I can tell, there is nothing abnormal about it. I currently use the same regexp in python and its blazes through the input file. Bear in mind, this is the first time that I've used cl-ppcre. It is was an experiment to see if I could lisp for this little application. Here is the regexp (at least a small portion of it that exhibits the behavior I am seeing): ^(?:\\S+ ){7}(\\S+)\\s+- commAlarm Here is the input line it is matching against (note: this is a single line albeit a long one): 1105243660 11 Sun Jan 09 04:07:40 2005 sclax02.ibasis.net - commAlarm ovnyc00p.ov.i\vanet.net [1] private.enterprises.2496.1.1.5.5.1.0 (Integer): 0 [2] private.enterprises.\2496.1.1.5.5.2.0 (Integer): 115 [3] private.enterprises.2496.1.1.5.5.3.0 (OctetString): \ISUP: UNEX ANM [4] private.enterprises.2496.1.1.5.5.4.0 (OctetString): ISDN User Part Un\expected ANM [5] private.enterprises.2496.1.1.5.5.5.0 (Integer): 2 [6] private.enterpri\ses.2496.1.1.5.5.6.0 (Integer): 1 [7] private.enterprises.2496.1.1.5.5.7.0 (Integer): 1 \ [8] private.enterprises.2496.1.1.5.5.8.0 (Integer): 2 [9] private.enterprises.2496.1.1.\1.1.1.1.1.1.1.1376258 (Integer): 1376258 [10] private.enterprises.2496.1.1.1.1.1.1.1.1.2\.1376258 (Integer): 21 [11] private.enterprises.2496.1.1.1.1.1.1.1.1.4.1376258 (OctetStr\ing): ss7path-att [12] private.enterprises.2496.1.1.1.1.1.1.1.1.5.1376258 (OctetString):\ SS7 Path For ATT and NGT DPC 5.21.39 [13] private.enterprises.2496.1.1.1.1.1.1.1.1.3.13\76258 (Integer): 1245188 [14] private.enterprises.2496.1.1.5.5.9.0 (Integer): 1105243880\;1 .1.3.6.1.4.1.2496.1.1.4.1 0 Stuff 51 of those lines above into a into a file and try to match on that regexp and I get the following results: PGW> (time (parse-file "/tmp/sample")) Evaluation took: 2.984 seconds of real time 1.81 seconds of user run time 1.12 seconds of system run time 0 page faults and 228,191,424 bytes consed. I am hoping to parse a file that has close to 75,000 lines in that format. At this rate, I will never make it in a reasonable amount of time. Here is the PARSE-FILE function I am using: (defun parse-file (file) (with-open-file (in file) (do ((line (read-line in nil :eof) (read-line in nil :eof))) ((eql line :eof) t) (do-register-groups ((#'intern host)) ("^(?:\\S+ ){7}(\\S+)\\s+- commAlarm" line) (format t "Found host ~A~%" host))))) I've also read the docs and I am unable to find anything to help identify the problem with my regexp. I have tried single-line mode, however the results were very similiar. My platform is SBCL 0.8.18.23 and version 1.0 of cl-ppcre. Any help would be appreciated. Thanks, Pete

2 9

[cl-ppcre-devel] New release 1.2.1
by Edi Weitz 25 Jan '05

25 Jan '05

I blew it twice this time because I was in a hurry - my apologies. Changelog: Version 1.2.1 2005-01-25 There was a wrong read-time conditional in api.lisp, sorry Download: <http://weitz.de/files/cl-ppcre.tar.gz> Cheers, Edi.

1 0

[cl-ppcre-devel] error loading 1.1.0 under CMUCL 19a
by Jim Prewett 24 Jan '05

24 Jan '05

Hello, I'm having problems loading CL-PPCRE 1.1.0 under CMUCL 19a under FreeBSD. Lisp spews the following when I ask it to load cl-ppcre: bash-2.05b$ lisp -eval '(load "cl-ppcre-1.1.0/load.lisp")' ; Loading #p"/usr/home/dl/logs/cl-ppcre-1.1.0/load.lisp". ; In: LET ((CL-PPCRE-BASE-DIRECTORY #) MUST-COMPILE) ; (DOLIST (FILE '# #)) ; --> DO* BLOCK LET* TAGBODY ; ==> ; (LET (#) ; (TAGBODY)) ; Note: Variable FILE defined but never used. Error in function LISP::%ENUMERATE-MATCHES: Cannot supply a type without a name: #<Unprintable pathname, Host=#<LISP::UNIX-HOST>, Device=NIL, Directory=(:ABSOLUTE "usr" "home" "dl" "logs" "cl-ppcre-1.1.0"), Name=NIL, Type="x86f", Version=:UNSPECIFIC> [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Return NIL from load of "cl-ppcre-1.1.0/load.lisp". 1: [ABORT ] Skip remaining initializations. Debug (type H for help) (LISP::%ENUMERATE-MATCHES #<Unprintable pathname, Host=#<LISP::UNIX-HOST>, Device=NIL, Directory=(:ABSOLUTE "usr" "home" "dl" "logs" ...), Name=NIL, Type="x86f", Version=:UNSPECIFIC> T T #<Closure Over Function (FLET #:G5 #) {48032DD9}>) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/filesys.lisp. 0] 0 ; CMU Common Lisp 19a, running on spacebrain.hpc.unm.edu With core: /usr/local/lib/cmucl/lib/lisp.core Dumped on: Tue, 2004-08-03 10:19:33-06:00 on snapdragon.csl.sri.com See <http://www.cons.org/cmucl/> for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 * (quit) James E. Prewett Systems Team Leader 505.277.8210 Designated Security Officer download(a)hpc.unm.edu Jim(a)Prewett.org HPC Systems Engineer III @ HPC@UNM OpenPGP key: pub 1024D/31816D93

2 1

[cl-ppcre-devel] New release 1.2.0
by Edi Weitz 24 Jan '05

24 Jan '05

Changelog: Version 1.2.0 2005-01-24 AllegroCL compatibility mode Fixed broken load.lisp file (caught by Jim Prewett and Zach Beane) Download: <http://weitz.de/files/cl-ppcre.tar.gz>

1 0

[cl-ppcre-devel] New version 1.1.0
by Edi Weitz 23 Jan '05

23 Jan '05

Changelog: Version 1.1.0 2005-01-23 Cleaned up load.lisp and cl-ppcre.asd Make large hash tables smaller, if possible Correct treatment of constant regular expressions in DO-SCANS Download: <http://weitz.de/files/cl-ppcre.tar.gz> Have fun, Edi.

1 0

[cl-ppcre-devel] Re: [Sbcl-devel] unicode and cl-ppcre performance
by Edi Weitz 21 Jan '05

21 Jan '05

On Fri, 21 Jan 2005 07:24:06 +0000, Christophe Rhodes <csr21(a)cam.ac.uk> wrote: > Also, does setting cl-ppcre:*regex-char-code-limit* to 128 before > making your parser function make any difference? That does the trick, thanks. I should have thought about this myself, sorry. Could you explain, for a Unicode ignorant like me, why CHAR-CODE-LIMIT is so high in SBCL and CLISP? Does Unicode really define 1114112 characters? Thanks, Edi.

1 0