- cxml-devel - mailman3.common-lisp.net

[cxml-devel] Problem compiling current git version
by Ralf Mattes 20 May '08

20 May '08

Hello list, this error occurs after a fresh git-clone: -+ Errors (1) `-- SB-INT:SIMPLE-READER-PACKAGE-ERROR at 5492 (line 123, column 30) on #<SB-SYS:FD-STREAM for "file /LISP/cxml/xml/unparse.lisp" {C538FC9}>: Symbol "FIND-OUTPUT-ENCODING" not found in the RUNES package. This is with sbcl-1.0.15 / Ubuntu w. CLC and (CVS) slime. Cheers, RalfD

2 3

[cxml-devel] cxml dependency in closure-html
by Nathan Bird 19 May '08

19 May '08

closure-html/src/parse/unparse.lisp line 33 has a reference to cxml::find-output-encoding. The closure-html.asd doesn't specify cxml as a dependency. From what I understand of the desired layout we don't want it to, so maybe that function should move up to closure common? Hope that helps, Nathan

2 1

[cxml-devel] Error in ystream.lisp while loading closure-common
by Chaitanya Gupta 17 May '08

17 May '08

Hi, I just installed the latest git snapshot of closure-common. I ran into the following error while loading it - -- x -- (LAMBDA (RUNES:ROD RUNES::INDEX) (BLOCK RUNES:RUNE (CHAR RUNES:ROD RUNES::INDEX))) is not a valid function spec [Condition of type TYPE-ERROR] Restarts: 0: [NIL] retry the compilation of /Users/chaitanya/lisp/libs/site/closure-common/ystream.lisp 1: [NIL] continue compiling /Users/chaitanya/lisp/libs/site/closure-common/ystream.lisp but generate no output file 2: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL @ #x113a195a> on #<CLOSURE-COMMON-SYSTEM::CLOSURE-SOURCE-FILE "ystream" @ #x103f0822>. 3: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL @ #x113a195a> on #<CLOSURE-COMMON-SYSTEM::CLOSURE-SOURCE-FILE "ystream" @ #x103f0822> as having been successful. 4: [ABORT-REQUEST] Abort handling SLIME request. 5: [ABORT] Abort entirely from this (lisp) process. Backtrace: 0: (SWANK::DEBUG-IN-EMACS #<TYPE-ERROR @ #x114e80b2>) 1: (SWANK:SWANK-DEBUGGER-HOOK #<TYPE-ERROR @ #x114e80b2> #<Function SWANK-DEBUGGER-HOOK>) 2: (ERROR TYPE-ERROR :DATUM #1=(LAMBDA (RUNES:ROD RUNES::INDEX) (BLOCK RUNES:RUNE (CHAR RUNES:ROD RUNES::INDEX))) :EXPECTED-TYPE EXCL::FUNCTION-NAME :FORMAT-CONTROL "~s is not a valid function spec" :FORMAT-ARGUMENTS (#1#)) 3: (FBOUNDP (LAMBDA (RUNES:ROD RUNES::INDEX) (BLOCK RUNES:RUNE (CHAR RUNES:ROD RUNES::INDEX)))) 4: (SYSTEM:FUNCTION-INFORMATION (LAMBDA (RUNES:ROD RUNES::INDEX) (BLOCK RUNES:RUNE (CHAR RUNES:ROD RUNES::INDEX))) #<Augmentable COMPILER environment 1 1 1 1 1 15>) 5: (GET-SETF-EXPANSION ((LAMBDA (RUNES:ROD RUNES::INDEX) (BLOCK RUNES:RUNE #)) RUNES::TMP 0) #<Augmentable COMPILER environment 1 1 1 1 1 15>) 6: (SETF (SETF (RUNES:RUNE RUNES::TMP 0) RUNES:RUNE) #<Augmentable COMPILER environment 1 1 1 1 1 15>) 7: (FUNCALL #<Function SETF @ #x100dce22> (SETF (RUNES:RUNE RUNES::TMP 0) RUNES:RUNE) #<Augmentable COMPILER environment 1 1 1 1 1 15>) 8: (COMPILER::PA-COMPILE (SETF (RUNES:RUNE RUNES::TMP 0) RUNES:RUNE) NIL) -- x -- The error occurred while Lisp was compiling YSTREAM-WRITE-ESCAPABLE-RUNE in ystream.lisp. To me the problem seems that RUNE is defined as a compiler-macro and its also being used as a SETF form. I am not sure whether its a problem with my Lisp or closure-common. I am using ACL 8.0 on Intel Mac OS X. It loads fine on SBCL, but DEFINLINE doesn't define any compiler macros in SBCL. Maybe that's why it loads fine here and breaks on ACL? Chaitanya

2 2

[cxml-devel] Cxml-rng and allegro issue
by Prashanth 15 May '08

15 May '08

Hi David Lichteblau, I am using cxml-rng in allegro 8.0 and I am unable to load the package, can you help me in fixing the issue? when i try to load this is the error message i get "`NIL' is not of the expected type `CHARACTER'". -- regards, Prashanth http://munichlinux.blogspot.com

2 1

[cxml-devel] ystream-unicode-p errors when serializing to character-stream
by Nathan Bird 09 May '08

09 May '08

With git head I get an error with the following: (with-output-to-string (stream) (let ((doc (dom:create-document 'rune-dom:implementation nil nil (dom:create-document-type 'rune-dom:implementation "html" "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd")))) (dom:map-document (chtml:make-character-stream-sink stream) doc :include-xmlns-attributes nil :include-doctype :full-internal-subset ))) The error as far as I've been able to track it down, is that the ystream created has a encoding slot, that is never filled. Then #'runes::ystream-unicode-p chokes when trying to inspect the encoding. We solved the error by testing the target stream when the encoding slot is null: (defun ystream-unicode-p (ystream) (let ((enc (ystream-encoding ystream))) (if enc (or (eq enc :utf-8) (eq (babel-encodings:enc-name enc) :utf-16)) #+rune-is-character (eq 'character (stream-element-type (ystream-target-stream ystream)))))) But I'm not sure that it is sound, and that function looks kind of strange anyways: what if encoding was the symbol :utf-16 or a babel-encoding object with the name :utf-8? It looks like the shift to babel-encodings is still somewhat a work-in-progress, does this help? We found this today when we switched from asdf-installed version to git HEAD because there was a problem with & getting escaped that looks like it is already fixed in git.

2 1

[cxml-devel] cxml moved to git
by David Lichteblau 13 Apr '08

13 Apr '08

Hi, in preparation for the next cxml release, both cxml itself and closure-common have been moved from CVS to git. (Until that release is done, CVS will still be available, but new development happens in git.) Mirror URLs: git clone git://repo.or.cz/cxml.git git clone git://repo.or.cz/cxml-common.git Gitweb: http://repo.or.cz/w/cxml.git http://repo.or.cz/w/closure-common.git d.

2 1

[cxml-devel] flexml: a new document model i'm playing with
by Attila Lendvai 01 Mar '08

01 Mar '08

hi! i've playing with an document builder that may be interesting for the list. the basic idea is to parse the xml into CLOS objects with their own class, so that method dispatch can be used to process the document. i need this for verrazano, to process the gccxml output. the first part of the file contains the generic flexml document builder and at the end there's some specialized code for gccxml. how it works: you can give it a default lisp package and also register namespace-uri->lisp-package mappings. when a node is encountered then a symbol is looked up in the appropriate package and make-instance is used to make the node. there's also a slot-missing specialization on it, so that it can store random slots (attributes) in a hashtable. features currently: - can resolve crossreferences, see cross-referenced-node slot type and friends - handles some slot types specially: cross-referenced-node, cross-referenced-nodes, integer, boolean, etc - can store attributes in a mixed slot/hashtable mode where simple attributes can go into the hashtable and special ones can be full-featured slots the code for now is only a proof of concept, but i wonder if there would be a place for it somewhere in a repo around cxml? it won't be bigger then a few pages so i think the most practical distribution would be to have its own .asd/package in the cxml repo/directory. but i don't want to run ahead... it even could be that i'm doing duplicate work with this. opinions? -- attila

3 6

Re: [cxml-devel] Parsing from a stream
by David Lichteblau 19 Feb '08

19 Feb '08

Quoting Chaitanya Gupta (mail(a)chaitanyagupta.com) > CL-USER> (flexi-streams:with-input-from-sequence (s *x) > (cxml:parse s (cxml-dom:make-dom-builder))) [...] > Only file streams are supported? Thanks for the report. That was a bug in PARSE, which should be fixed in cxml CVS now. (You could also use the older function CXML:PARSE-STREAM instead of the new interface CXML:PARSE. The former doesn't have the bug.) > No. The reason I am asking is because I get a (huge) XML over a socket; I > think parsing directly from the socket stream should be much more efficient > than first reading the XML into a string, and then parsing the string (is > this assumption correct?). Sure, parsing from a socket directly is the natural solution, and needs only constant space rather than O(n) space with the length of the input. (Not taking into account that the DOM tree obviously needs O(n) space.) For now, you'd have to open the socket using :element-type '(unsigned-byte 8), or take advantage of bivalent streams on Lisps that provide them. In the long term, I'll try to add support for character streams. (But note that cxml will detect the encoding declared in the XML declaration when parsing from binary streams. It won't be able to do that when the Lisp is already handling the external-format conversion in the stream. That's the primary reason binary streams are better for XML parsing.) d.

2 1

[Fwd: Re: [cxml-devel] Parsing from a stream]
by Chaitanya Gupta 19 Feb '08

19 Feb '08

Sorry, forgot to reply to the list...

1 0

[cxml-devel] Parsing from a stream
by Chaitanya Gupta 19 Feb '08

19 Feb '08

Hi, I am tring to parse an XML from a stream using CXML:PARSE. I get an error when I try that. Here's the input form and the backtrace. --- CL-USER> (with-input-from-string (s "<foo>bar</foo>") (cxml:parse s (cxml-dom:make-dom-builder))) ; Evaluation aborted can't read-byte from a string stream: #<STRING-INPUT-SIMPLE-STREAM "<foo>bar</foo>" pos 0 @ #x1108e69a> [Condition of type TYPE-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Abort entirely from this (lisp) process. Backtrace: 0: (SWANK::DEBUG-IN-EMACS #<TYPE-ERROR @ #x110fb1f2>) 1: (SWANK:SWANK-DEBUGGER-HOOK #<TYPE-ERROR @ #x110fb1f2> #<Function SWANK-DEBUGGER-HOOK>) 2: (ERROR TYPE-ERROR :DATUM #1=#<STRING-INPUT-SIMPLE-STREAM "<foo>bar</foo>" pos 0 @ #x1108e69a> :EXPECTED-TYPE STREAM :FORMAT-CONTROL "can't read-byte from a string stream: ~s" :FORMAT-ARGUMENTS (#1#)) 3: ((METHOD RUNES::FIGURE-ENCODING (STREAM)) #<STRING-INPUT-SIMPLE-STREAM "<foo>bar</foo>" pos 0 @ #x1108e69a>) 4: (RUNES:MAKE-XSTREAM #<STRING-INPUT-SIMPLE-STREAM "<foo>bar</foo>" pos 0 @ #x1108e69a> :SPEED 8192) 5: (CXML:PARSE #<STRING-INPUT-SIMPLE-STREAM "<foo>bar</foo>" pos 0 @ #x1108e69a> #<RUNE-DOM::DOM-BUILDER @ #x110fb1b2>) --- I tried this on ACL 8.0 and CXML is from CVS. Shouldn't string streams be parseable? Chaitanya

2 1