hello,
I'm experiencing some problems with XMLisp. I believe those problems
are caused by my insufficient knowledge of lisp :)
If I understand the site (http://agentsheets.com/lisp/XMLisp/)
correctly, XMLisp currently supports only these lisp "environments":
MCL 5, 5.1, LispWorks 4.3, OpenMCL 0.13.2, SBCL.
I use Debian GNU/Linux, and untill now I've worked with CLISP.
Apparantly, XMLisp and CLISP aren't very good friends:
·····@intuxicator:/home/docs/bordeaux_werk/xmlisp/XML$ clisp
Load-XMLisp.lisp
;;; loading "xml-utilities"
;;; loading "element-definition"
;;; loading "xml-tag-definitions"
;;; loading "element-implementation"
;;; loading "name-character-check"
;;; loading "xml-parser"
;;; loading "xml-writer"
;;; loading "XMLisp"
WARNING:
Replacing method #<STANDARD-METHOD (#<BUILT-IN-CLASS T>
#<BUILT-IN-CLASS T> #<BUILT-IN-CLASS T>)> in #<GENERIC-FUNCTION
PRINT-TYPED-ATTRIBUTE-VALUE>
*** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER
#P"/home/docs/bordeaux_werk/xmlisp/XML/XMLisp.lisp" @1156>: macro
character definition for #\< may not return 2 values, only one value.
Quite frankly, I have no idea what this error means. I've also
installed SBCL, but I don't find how to run the program. I've found an
explanation on the internet (that SBCL has no interpreter) and
compiling the file with SBCL works, but I don't know what to do next.
Can anyone help me out?
Thanks
Nitro
Nitro wrote:
> I use Debian GNU/Linux, and untill now I've worked with CLISP.
> Apparantly, XMLisp and CLISP aren't very good friends:
XMLisp uses the Metaobject Protocol (MOP) to mess with the internals of
CLOS, but this isn't trivially portable. The problem is that different
implementations implement the MOP differently, and put it in different
packages. And that is why XMLisp won't run on CLISP without a little
porting.
This probably has nothing to do with the error you posted, but it's a
problem that will come up eventually even if you fix this error.
> Quite frankly, I have no idea what this error means. I've also
> installed SBCL, but I don't find how to run the program. I've found
an
> explanation on the internet (that SBCL has no interpreter) and
> compiling the file with SBCL works, but I don't know what to do next.
SBCL has no interpreter (yet), but its compiler pretends to be one.
Just use it as you would use CLISP and you should be fine. Run it in
emacs, look at the REPL, use the REPL.
-Peter
Nitro wrote:
> I'm experiencing some problems with XMLisp. I believe those problems
> are caused by my insufficient knowledge of lisp :)
>
> If I understand the site (http://agentsheets.com/lisp/XMLisp/)
> correctly, XMLisp currently supports only these lisp "environments":
> MCL 5, 5.1, LispWorks 4.3, OpenMCL 0.13.2, SBCL.
>
> I use Debian GNU/Linux, and untill now I've worked with CLISP.
> Apparantly, XMLisp and CLISP aren't very good friends:
not yet but it would be great if they could be and I will be happy to
help, however, I do not have access to CLISP. Nonetheless, I think it
should not be hard to get this working and add CLISP to the list.
> WARNING:
> Replacing method #<STANDARD-METHOD (#<BUILT-IN-CLASS T>
> #<BUILT-IN-CLASS T> #<BUILT-IN-CLASS T>)> in #<GENERIC-FUNCTION
> PRINT-TYPED-ATTRIBUTE-VALUE>
good one. There was a redundant method definition. Just deleted it.
This was only a warning.
> *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER
> #P"/home/docs/bordeaux_werk/xmlisp/XML/XMLisp.lisp" @1156>: macro
> character definition for #\< may not return 2 values, only one value.
This one does not make a lot of sense to me:
The macro char is set in XMLisp.lisp:
(set-macro-character #\< #'element-reader t)
I have two ideas how to approach this:
1) CLISP set-maro-character function cannot deal with the optional
boolean parameter. Not likely and this would be a strange way of
reporting this.
2) CLISP's compiler is pretty eager and detects (wow) that the reader
function indeed could return two values. This should not be a problem
but let's see if this make the difference. Replace:
(defun ELEMENT-READER (Stream Char)
(declare (ignore Char))
;; may not be an XML element after all, e.g., common-lisp functions
<, <=
(let ((Next-Char (read-char Stream nil nil)))
;; dange zone: may not catch all the cases.
;; Probably better approach: if next-char is not a valid first
character of a XML element name then
;; finish reading the symbol and return it
(case Next-Char
(#\space (return-from element-reader (intern "<")))
(#\= (return-from element-reader (intern "<="))))
(unread-char Next-Char Stream))
;; lets read XML
(skip-xml-header Stream) ;; this only needs to be done once
(read-xmlisp-element (read-name-and-make-instance Stream) Stream))
with:
(defun ELEMENT-READER (Stream Char)
(declare (ignore Char))
;; may not be an XML element after all, e.g., common-lisp functions
<, <=
(let ((Next-Char (read-char Stream nil nil)))
;; dange zone: may not catch all the cases.
;; Probably better approach: if next-char is not a valid first
character of a XML element name then
;; finish reading the symbol and return it
(case Next-Char
(#\space (return-from element-reader (values (intern "<"))))
(#\= (return-from element-reader (values (intern "<=")))))
(unread-char Next-Char Stream))
;; lets read XML
(skip-xml-header Stream) ;; this only needs to be done once
(read-xmlisp-element (read-name-and-make-instance Stream) Stream))
this wraps up (intern ...) with (values ...) to drop the second value.
In most lisps this should not be necessary but all we do here anyway is
to suppress a warning.
I THINK this should fix the warnings. Do let me know. Now comes the MOP
part. We need some CLISP/MOP person in the loop. In XMLisp.lisp at the
top you find (and yes i will move this into a separate file):
(eval-when (:compile-toplevel :load-toplevel :execute)
#+:mcl
(import '(ccl:slot-definition-name ccl:slot-definition-type
ccl:slot-definition-initform))
#+:ccl-5.1
(import '(ccl:class-slots))
#+:common-lispworks
(import '(harlequin-common-lisp:class-slots
harlequin-common-lisp:slot-definition-name
harlequin-common-lisp:slot-definition-type
harlequin-common-lisp:slot-definition-initform)))
Sadly the MOP is not standardized yet. Each Lisp has it's own package
etc. XMLisp uses as little MOP as possible. All you need is to make
sure that in package :xml you have access to the following MOP
functions: (class-slots slot-definition-name slot-definition-type
slot-definition-initform) Assuming CLISP has a MOP find out what where
one should import these MOP functions from. Add an import list to the
list using a CLISP feature, e.g., #+:CLISP (just a guess).
If you get this going I'd be happy to add your name to the contribution
list and wrap your mod into the next version.
Alex
>
> If you get this going I'd be happy to add your name to the contribution
> list and wrap your mod into the next version.
>
Haha, that's a lot of pressure :)
Thank you for your contribution, I'll report my results back here as
soon as possible (see below)
I'll certainly take a shot at it, but as said before, I'm new to LISP,
and I'm just trying to understand XMLisp. Of course, this is a pretty
nice way to learn the language.
Hopefully, by tomorrow I understand XMLisp to the last bit, and than
I'll take a look at the other stuff.
Anyway, thanks a lot for the help, and keep it coming!
Nitro
> > I use Debian GNU/Linux, and untill now I've worked with CLISP.
> > Apparantly, XMLisp and CLISP aren't very good friends:
>
> not yet but it would be great if they could be and I will be happy to
> help, however, I do not have access to CLISP. Nonetheless, I think it
> should not be hard to get this working and add CLISP to the list.
Let me correct myself here first: CLisp in Debian and XMLisp aren't
good friends. On the IRC channel #lisp they told me that the version
in Debian is too old. That means that CLOS isn't properly supported.
After a couple days of screwing around, I've discovered #lisp. I've
compiled the latest cvs yesterday, and it works like a charm now. See
my adjustments below.
> > WARNING:
> > Replacing method #<STANDARD-METHOD (#<BUILT-IN-CLASS T>
> > #<BUILT-IN-CLASS T> #<BUILT-IN-CLASS T>)> in #<GENERIC-FUNCTION
> > PRINT-TYPED-ATTRIBUTE-VALUE>
>
> good one. There was a redundant method definition. Just deleted it.
> This was only a warning.
OK
> > *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER
> > #P"/home/docs/bordeaux_werk/xmlisp/XML/XMLisp.lisp" @1156>: macro
> > character definition for #\< may not return 2 values, only one value.
>
<snip>
Yes, your replacement-code did the trick, thanks for that.
Now than, my adjustments to the code are very little:
First of all: I replaced the function with the function you provided
Second of all: I imported the necessary functions (wouldn't work with
the old clisp, but piece of cake with the new one):
#+:clisp
(import '(clos:class-slots clos:slot-definition-name
clos:slot-definition-type clos:slot-definition-initform))
Hopefully, this helps other people too (i really like clisp :))
Nitro
Nitro wrote:
> Now than, my adjustments to the code are very little:
>
> First of all: I replaced the function with the function you provided
> Second of all: I imported the necessary functions (wouldn't work with
> the old clisp, but piece of cake with the new one):
>
> #+:clisp
> (import '(clos:class-slots clos:slot-definition-name
> clos:slot-definition-type clos:slot-definition-initform))
>
>
> Hopefully, this helps other people too (i really like clisp :))
>
> Nitro
Thanks Nitro!
I will wrap that into the next version of XMLisp.
Alex
······@gmail.com (Nitro) writes:
> *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER
> #P"/home/docs/bordeaux_werk/xmlisp/XML/XMLisp.lisp" @1156>: macro
> character definition for #\< may not return 2 values, only one value.
This means that CLISP complains that a read macro function returns
multiple values when it's expected by CLISP's interpretation of the
Common Lisp standard to return exactly one value (see multiple values
in the standard).
I thought the error message would lead to a variable in CLISP that one
could set to get past this error. Please ask the clisp-mailing list
for further help on that error.
WRT sbcl, you could use (compile-file"foo"), then (load"foo")
Regards, [sorry, must go home]
Jorg Hohle
Telekom/T-Systems Technology Center