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

Re: [cl-ppcre-devel] Bug when loading file in SBCL x86-64
by Edi Weitz 06 Feb '05

06 Feb '05

Liam Healey wrote: > debugger invoked on a TYPE-ERROR in thread 24956: > The value NIL is not of type HASH-TABLE. > > Consensus is that it's a bug in cl-ppcre Hi! Which version are you using? I think this was fixed in 1.2.2, 1.2.3 is current. Cheers, Edi.

2 3

[cl-ppcre-devel] Bug when loading file in SBCL x86-64
by Liam M. Healy 05 Feb '05

05 Feb '05

See http://paste.lisp.org/display/5474. This simple form fails to load correctly in SBCL x86-64. There is no problem with the 32 bit compiler. (defun test (line) (cl-ppcre:scan-to-strings "Location:.*( \\d+\\.\\d+) *(\\w).*( \\d+\\.\\d+) *(\\w)" line)) Compile, load the file: debugger invoked on a TYPE-ERROR in thread 24956: The value NIL is not of type HASH-TABLE. Consensus is that it's a bug in cl-ppcre (11:03:28) Xof: LiamH: bug in cl-ppcre; please report it to edi weitz (11:09:08) Xof: "Works fine in sbcl/ia32 and ACL/ia32.", hmm, maybe it's not a bug in cl-ppcre (11:09:57) chavatar: Xof: if you read the backtrace, the object-not-hashtable problem is coming from PCL guts (11:10:30) chavatar: .. or maybe not (11:10:46) chavatar: it could be either PCL or CL-PPCRE (11:13:53) Xof: no, the object-not-hashtable is coming from the :after char-class method which does hash-table-count on (getf :hash args) (11:14:21) chavatar: ok (11:17:26) Xof: if it helps, it's failing on the sixth initialization of a char-class object (11:18:11) Xof: and, um, indeed I'm sure now (11:18:38) Xof: because the second call to make-instance 'char-class in CONVERT-AUX can explicitly pass :hash nil (11:18:42) Xof: so, bug in cl-ppcre Thanks, Liam

1 0

[cl-ppcre-devel] Bug when loading file in SBCL x86-64
by Liam M. Healy 05 Feb '05

05 Feb '05

See http://paste.lisp.org/display/5474. This simple form fails to load correctly in SBCL x86-64. There is no problem with the 32 bit compiler. (defun test (line) (cl-ppcre:scan-to-strings "Location:.*( \\d+\\.\\d+) *(\\w).*( \\d+\\.\\d+) *(\\w)" line)) Compile, load the file: debugger invoked on a TYPE-ERROR in thread 24956: The value NIL is not of type HASH-TABLE. Consensus is that it's a bug in cl-ppcre (11:03:28) Xof: LiamH: bug in cl-ppcre; please report it to edi weitz (11:09:08) Xof: "Works fine in sbcl/ia32 and ACL/ia32.", hmm, maybe it's not a bug in cl-ppcre (11:09:57) chavatar: Xof: if you read the backtrace, the object-not-hashtable problem is coming from PCL guts (11:10:30) chavatar: .. or maybe not (11:10:46) chavatar: it could be either PCL or CL-PPCRE (11:13:53) Xof: no, the object-not-hashtable is coming from the :after char-class method which does hash-table-count on (getf :hash args) (11:14:21) chavatar: ok (11:17:26) Xof: if it helps, it's failing on the sixth initialization of a char-class object (11:18:11) Xof: and, um, indeed I'm sure now (11:18:38) Xof: because the second call to make-instance 'char-class in CONVERT-AUX can explicitly pass :hash nil (11:18:42) Xof: so, bug in cl-ppcre Thanks, Liam

1 0

[cl-ppcre-devel] Bug when loading file in SBCL x86-64
by Liam M. Healy 05 Feb '05

05 Feb '05

See http://paste.lisp.org/display/5474. This simple form fails to load correctly in SBCL x86-64. There is no problem with the 32 bit compiler. (defun test (line) (cl-ppcre:scan-to-strings "Location:.*( \\d+\\.\\d+) *(\\w).*( \\d+\\.\\d+) *(\\w)" line)) Compile, load the file: debugger invoked on a TYPE-ERROR in thread 24956: The value NIL is not of type HASH-TABLE. Consensus is that it's a bug in cl-ppcre (11:03:28) Xof: LiamH: bug in cl-ppcre; please report it to edi weitz (11:09:08) Xof: "Works fine in sbcl/ia32 and ACL/ia32.", hmm, maybe it's not a bug in cl-ppcre (11:09:57) chavatar: Xof: if you read the backtrace, the object-not-hashtable problem is coming from PCL guts (11:10:30) chavatar: .. or maybe not (11:10:46) chavatar: it could be either PCL or CL-PPCRE (11:13:53) Xof: no, the object-not-hashtable is coming from the :after char-class method which does hash-table-count on (getf :hash args) (11:14:21) chavatar: ok (11:17:26) Xof: if it helps, it's failing on the sixth initialization of a char-class object (11:18:11) Xof: and, um, indeed I'm sure now (11:18:38) Xof: because the second call to make-instance 'char-class in CONVERT-AUX can explicitly pass :hash nil (11:18:42) Xof: so, bug in cl-ppcre Thanks, Liam

1 0

[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] New versions 1.2.2/1.2.3
by Edi Weitz 02 Feb '05

02 Feb '05

Changelog: Version 1.2.3 2005-02-02 Wrapped WITH-COMPILATION-UNIT around loop in load.lisp Version 1.2.2 2005-02-02 Fixed bug in hash table optimization (introduced in 1.1.0) Download: <http://weitz.de/files/cl-ppcre.tar.gz> Cheers, Edi.

1 0

[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