I was having a problem with serializing to a character stream (rather than string or octets) on SBCL 0.9.7.
CL-USER> (let* ((dom (cxml-dom:create-document)) (string (with-output-to-string (stream) (dom:map-document (cxml:make-character-stream-sink stream :indentation 4 :canonical nil) dom )))) (values string (length string)))
"<?xml version=\"1.0\" encoding=\"UTF-8\"?>^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@ .... (I've actually typed these in since I can't paste them) ..... ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@............." 1024
It was looking an awfully lot like it was trying to write out buffer that wasn't filled.
Tracked it down to
(defmethod flush-ystream ((ystream character-stream-ystream)) (write-string (ystream-in-buffer ystream) (ystream-target-stream ystream) ;;this end argument had been missing. :end (ystream-in-ptr ystream)) (setf (ystream-in-ptr ystream) 0))
Patch attached.
Nathan Bird
BTW, I've been playing around with using CXML to generate XUL, since it mixes with HTML and namespaces matter and all that jazz. As an interesting comparison I tried generating and serializing out through UnCommon Web a big html table with a lot of dynamic generated strings in it. It looks like doing it with CXML is about 2.5 times faster than doing the equivalent with UCW's own tool-- yaclml. Sweet!
Quoting Nathan Bird (nathan@acceleration.net):
;;this end argument had been missing. :end (ystream-in-ptr ystream))
Oops, thank you. Committed to CVS.
BTW, I've been playing around with using CXML to generate XUL, since it mixes with HTML and namespaces matter and all that jazz. As an interesting comparison I tried generating and serializing out through UnCommon Web a big html table with a lot of dynamic generated strings in it. It looks like doing it with CXML is about 2.5 times faster than doing the equivalent with UCW's own tool-- yaclml. Sweet!
That's good to know. My own changes have been more about correctness and features, but it's obvious that Gilbert put some thought into optimizations.
(Although the DOM functions are inherently complex and rather slow compared to the actual parser. For example, parsing with xmls-compat is dramatically faster than parsing into DOM.)
David
For some reason after I updated to get the patches I had just submitted I ran into a new problem-- curious.
In runes/ystream.lisp line the reader macro #/ is used, which I tracked down to being defined in runes/syntax.lisp. I added this dependency to cxml.asd and now it works fine for me. Not sure why this just came up and I (or anyone else) didn't run across this sooner.
Here's a patch for it. After I recorded the patch I reverted and tried it again, this time I didn't have any problem. I deleted all the fasls, still didn't have a problem. Very curious.
The dependency still exists between runes/ystream.lisp and runes/syntax.lisp so I think this is still good to state explicitly in the asd rather than getting lucky on the order it loads.
Nathan
-----Original Message----- From: David Lichteblau [mailto:david@lichteblau.com] Sent: Monday, January 23, 2006 5:12 PM To: Nathan Bird Cc: cxml-devel@common-lisp.net Subject: Re: [cxml-devel] flush-ystream on character-stream-yestream
Quoting Nathan Bird (nathan@acceleration.net):
;;this end argument had been missing. :end (ystream-in-ptr ystream))
Oops, thank you. Committed to CVS.
BTW, I've been playing around with using CXML to generate XUL, since it mixes with HTML and namespaces matter and all that jazz. As an interesting comparison I tried generating and serializing out through UnCommon Web a
big
html table with a lot of dynamic generated strings in it. It looks like doing it with CXML is about 2.5 times faster than doing the equivalent
with
UCW's own tool-- yaclml. Sweet!
That's good to know. My own changes have been more about correctness and features, but it's obvious that Gilbert put some thought into optimizations.
(Although the DOM functions are inherently complex and rather slow compared to the actual parser. For example, parsing with xmls-compat is dramatically faster than parsing into DOM.)
David
Quoting Nathan Bird (nathan@acceleration.net):
Not sure why this just came up and I (or anyone else) didn't run across this sooner.
Partly because it's a brand new file, I guess.
The dependency still exists between runes/ystream.lisp and runes/syntax.lisp so I think this is still good to state explicitly in the asd rather than getting lucky on the order it loads.
I'm lazy, so I've simply put a :serial t into that system for now. Declaring dependencies manually is not too good an idea anyway in my experience; that's something that "should" be autogenerated from xref info. Lacking a tool to do that, :serial seems the most robust solution.
Thanks, David
-
David Lichteblau -
Nathan Bird