Hello,
I was compiling CXML, in SBCL 0.9.15. I noticed that the compiler kept "getting stuck", when compiling the file xml-name-rune-p. Upon looking at the file, it appeared that the 'getting stuck' behavior may have had something to do with the #. form in the file.
With some simple reformatting on the forms in that file, I was able to define a set of forms effectively comparable to those under the #. form -- using the same code, essentially, though by a slightly different approach. I've used a number of DEFVAR calls to hold the predicate values, as well as a DEMACRO call defining a 'defpredicate' macro -- the lot of those calls being wrapped in a form like EVAL-WHEN :COMPILE-TOPLEVEL. The code in the file's toplevel calls the 'defpredicate' macro, to define each of the two predicate functions. The patched code still uses the thing-code-onto-bit-vector comparison.
The patch for it is attached to this message. The patched code compiles, successfully, in SBCL 0.9.15.
The patch affects the definitions of the functions `name-rune-p' and `name-start-p'. I've tested the redefined name-rune-p, in calling it on one ASCII alphabetic charater; it works.
Absent of adverbs,
-- Sean Champ
Begging your pardon, but I've been dazing at the end of the shift, here.
The previous patch I'd submitted on this line, it had a typo and a misnamed form, in it.
The patch attatched to this message would serve to obsolete the prior patch.
In this patch, those quirks of the prior patch are resolved: DECALRE => DECLARE NAME-START-P => NAME-START-RUNE-P
-- Sean Champ
Begging your pardon, again. I'm still at the end of the night/day's shift, here. That appears to have affected a behavior of being "too quick to the draw", at the patch-making.
Presently, I would like to withdraw the patch that was presented in this thread of messages. (NAME-RUNE-P #\T) sure works, but the patched code, in parsing, does not work.
-- Sean CHamp
Quoting Sean Champ (gimmal@gmail.com):
I was compiling CXML, in SBCL 0.9.15. I noticed that the compiler kept "getting stuck", when compiling the file xml-name-rune-p. Upon looking at the
Give it time. It will finish eventually.
file, it appeared that the 'getting stuck' behavior may have had something to do with the #. form in the file.
You are probably compiling with a high DEBUG setting, causing SBCL to enable step-instrumentation. Solution: Use a lower DEBUG setting.
d.
Attached to ths email is the final, corrected version of the patch. I had been using OR where AND is required.
On 08-16-06, David Lichteblau wrote:
Quoting Sean Champ (gimmal@gmail.com):
I was compiling CXML, in SBCL 0.9.15. I noticed that the compiler kept "getting stuck", when compiling the file xml-name-rune-p. Upon looking at the
Give it time. It will finish eventually.
Obviosly, it is your projects' codebase. I'd like to voice the assertion, however: It compiles quite quickly, with this patched code.
file, it appeared that the 'getting stuck' behavior may have had something to do with the #. form in the file.
You are probably compiling with a high DEBUG setting, causing SBCL to enable step-instrumentation. Solution: Use a lower DEBUG setting.
Inded, I am compiling with a high debug quality -- (debug 3) -- but I have disabled the insertion of step conditions -- (sb-c:insert-step-conditions 0) in the compiler policy.
-- Sean Champ
I took a stab at the same bit of code a little while back trying to merge characters.lisp and xml-name-rune-p.lisp and came up with some (I thought) cleaner code that compiled quite a bit faster than what was there. If you want to compare: http://common-lisp.net/pipermail/cxml-devel/2006-June/000051.html. From quickly skimming your patch it looks pretty similar :-)
Nathan Bird
Sean Champ wrote:
Attached to ths email is the final, corrected version of the patch. I had been using OR where AND is required.
On 08-16-06, David Lichteblau wrote:
Quoting Sean Champ (gimmal@gmail.com):
I was compiling CXML, in SBCL 0.9.15. I noticed that the compiler kept "getting stuck", when compiling the file xml-name-rune-p. Upon looking at the
Give it time. It will finish eventually.
Obviosly, it is your projects' codebase. I'd like to voice the assertion, however: It compiles quite quickly, with this patched code.
file, it appeared that the 'getting stuck' behavior may have had something to do with the #. form in the file.
You are probably compiling with a high DEBUG setting, causing SBCL to enable step-instrumentation. Solution: Use a lower DEBUG setting.
Inded, I am compiling with a high debug quality -- (debug 3) -- but I have disabled the insertion of step conditions -- (sb-c:insert-step-conditions 0) in the compiler policy.
-- Sean Champ
-
David Lichteblau -
Nathan Bird -
Sean Champ