From edi at agharta.de Wed Feb 2 18:40:05 2005 From: edi at agharta.de (Edi Weitz) Date: Wed, 02 Feb 2005 19:40:05 +0100 Subject: [cl-ppcre-devel] New versions 1.2.2/1.2.3 Message-ID: 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: Cheers, Edi. From wencel at gmail.com Thu Feb 3 22:12:04 2005 From: wencel at gmail.com (Lawrence Mitchell) Date: Thu, 3 Feb 2005 22:12:04 +0000 Subject: [cl-ppcre-devel] Using cl-ppcre in a text editor In-Reply-To: References: <2b1f8a5b0501290816133a2b82@mail.gmail.com> Message-ID: <2b1f8a5b05020314123746f10a@mail.gmail.com> Hi Edi, thanks for your response. Edi Weitz wrote: [...] > Now, using another kind of structures (like, say, your buffers) that > aren't strings but are random-access - that wouldn't be /too/ hard. > It would involve going through three or four files and change SCHAR to > something else but basically I don't really see a problem. However, > as CL-PPCRE has a reputation for being quite fast I wouldn't want to > sacrifice this for greater flexibility (buffers instead of strings, > arbitrary objects instead of characters - you name it). I think the > right way to do it would be to offer the ability to build different > versions of CL-PPCRE based on *FEATURES*, i.e. at compile time you > decide whether you want a fast regex engine for strings or if you want > a not-so-fast regex engine for, say, buffers. Would that be OK for > you? That sounds good from this end. I'll look at this over the weekend, since hopefully it shouldn't be too much effort. If the patches aren't too invasive, would you want them? Otherwise, we'll just try and keep a version of cl-ppcre in climacs, and update it as and when. Thanks again, Lawrence From edi at agharta.de Thu Feb 3 22:36:25 2005 From: edi at agharta.de (Edi Weitz) Date: Thu, 03 Feb 2005 23:36:25 +0100 Subject: [cl-ppcre-devel] Using cl-ppcre in a text editor In-Reply-To: <2b1f8a5b05020314123746f10a@mail.gmail.com> (Lawrence Mitchell's message of "Thu, 3 Feb 2005 22:12:04 +0000") References: <2b1f8a5b0501290816133a2b82@mail.gmail.com> <2b1f8a5b05020314123746f10a@mail.gmail.com> Message-ID: On Thu, 3 Feb 2005 22:12:04 +0000, Lawrence Mitchell wrote: > That sounds good from this end. I'll look at this over the weekend, > since hopefully it shouldn't be too much effort. If the patches > aren't too invasive, would you want them? Yes, I'd be pleased to incorporate them. If you need any help with this let me know and I'll try to give a hand if time permits. (Also, have a look at the note about simple strings in the docs - this will most likely be relevant to your modifications but if all goes well it's just a matter of changing one macro.) > Otherwise, we'll just try and keep a version of cl-ppcre in climacs, > and update it as and when. That would certainly be a kludge somehow so I'd be more satisfied with a synced solution. License-wise this is not a problem, of course. Cheers, Edi. From lnp at healy.washington.dc.us Sat Feb 5 22:31:30 2005 From: lnp at healy.washington.dc.us (Liam M. Healy) Date: Sat, 05 Feb 2005 22:31:30 -0000 Subject: [cl-ppcre-devel] Bug when loading file in SBCL x86-64 Message-ID: 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 From edi at agharta.de Sun Feb 6 06:09:58 2005 From: edi at agharta.de (Edi Weitz) Date: Sun, 06 Feb 2005 07:09:58 +0100 Subject: [cl-ppcre-devel] Bug when loading file in SBCL x86-64 In-Reply-To: Liam M. Healy's message of "(unknown date)" Message-ID: 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. From lnp at healy.washington.dc.us Sun Feb 6 15:18:05 2005 From: lnp at healy.washington.dc.us (Liam M. Healy) Date: Sun, 6 Feb 2005 10:18:05 -0500 Subject: [cl-ppcre-devel] Bug when loading file in SBCL x86-64 In-Reply-To: References: Message-ID: <16902.13613.51589.676579@yaxkin.local> Looks like I'm up to date-- dpkg -l cl-ppcre Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=====================-=====================-========================================================== ii cl-ppcre 1.2.3-1 Portable Regular Express Library for Common Lisp >>>>> "Edi" == Edi Weitz writes: Edi> 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 Edi> Hi! Edi> Which version are you using? I think this was fixed in 1.2.2, 1.2.3 Edi> is current. Edi> Cheers, Edi> Edi. From edi at agharta.de Sun Feb 6 16:44:25 2005 From: edi at agharta.de (Edi Weitz) Date: Sun, 06 Feb 2005 17:44:25 +0100 Subject: [cl-ppcre-devel] Bug when loading file in SBCL x86-64 In-Reply-To: <16902.13613.51589.676579@yaxkin.local> (Liam M. Healy's message of "Sun, 6 Feb 2005 10:18:05 -0500") References: <16902.13613.51589.676579@yaxkin.local> Message-ID: On Sun, 6 Feb 2005 10:18:05 -0500, "Liam M. Healy" wrote: > Looks like I'm up to date-- > > dpkg -l cl-ppcre > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) > ||/ Name Version Description > +++-=====================-=====================-========================================================== > ii cl-ppcre 1.2.3-1 Portable Regular Express Library for Common Lisp OK, so do I understand correctly that you only see this on a 64bit machine? I don't have one and can't reproduce the error here. Can you send me a backtrace? Do you see the same symptoms if you define TEST at the REPL and then compile it? FWIW, I see exactly the error message you reported if I use CL-PPCRE 1.2.1. Are you really sure you're using 1.2.3 and not by accident an older version? Thanks, Edi. From lnp at healy.washington.dc.us Sun Feb 6 17:07:10 2005 From: lnp at healy.washington.dc.us (Liam M. Healy) Date: Sun, 6 Feb 2005 12:07:10 -0500 Subject: [cl-ppcre-devel] Bug when loading file in SBCL x86-64 In-Reply-To: References: <16902.13613.51589.676579@yaxkin.local> Message-ID: <16902.20158.544909.683579@yaxkin.local> I think you're right. I do not get the error now. Apparently I was using an older version of cl-ppcre when I got the error. Since I upgrade daily (usually), the version information below is correct currently but not when I got the error. Thanks for the information. Liam >>>>> "Edi" == Edi Weitz writes: Edi> On Sun, 6 Feb 2005 10:18:05 -0500, "Liam M. Healy" wrote: >> Looks like I'm up to date-- >> >> dpkg -l cl-ppcre >> Desired=Unknown/Install/Remove/Purge/Hold >> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed >> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) >> ||/ Name Version Description >> +++-=====================-=====================-========================================================== >> ii cl-ppcre 1.2.3-1 Portable Regular Express Library for Common Lisp Edi> OK, so do I understand correctly that you only see this on a 64bit Edi> machine? I don't have one and can't reproduce the error here. Can Edi> you send me a backtrace? Edi> Do you see the same symptoms if you define TEST at the REPL and then Edi> compile it? Edi> FWIW, I see exactly the error message you reported if I use CL-PPCRE Edi> 1.2.1. Are you really sure you're using 1.2.3 and not by accident an Edi> older version? Edi> Thanks, Edi> Edi. From lnp at healy.washington.dc.us Sat Feb 5 22:31:30 2005 From: lnp at healy.washington.dc.us (Liam M. Healy) Date: Sat, 05 Feb 2005 22:31:30 -0000 Subject: [cl-ppcre-devel] Bug when loading file in SBCL x86-64 Message-ID: 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 From lnp at healy.washington.dc.us Sat Feb 5 22:31:30 2005 From: lnp at healy.washington.dc.us (Liam M. Healy) Date: Sat, 05 Feb 2005 22:31:30 -0000 Subject: [cl-ppcre-devel] Bug when loading file in SBCL x86-64 Message-ID: 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