weblocks-stores-20150407-git/src/store/store-utils.lisp
has a defmethod print-object
that appears to modify something in package 'common-lisp or 'clos, which are locked in clisp.
----
** - Continuable Error
DEFMETHOD((PRINT-OBJECT NIL STANDARD-OBJECT T)):
(#<PACKAGE CLOS> #<PACKAGE COMMON-LISP> #<PACKAGE COMMON-LISP>
#<PACKAGE COMMON-LISP>)
is locked
If you continue (by typing 'continue'): Ignore the lock and proceed
----
I don't think you're supposed to be able to modify those packages, but I could be wrong.
at any rate,
1) clisp can't (start-weblocks) because of this
2) ecl exceeds its stack and other memory limits because of it. (even if you "continue", weblocks never starts).
deleting that method definition fixed both issues for me.
--------
further, to get clisp to run weblocks, you also need to define #'md5:md5-string.
one way is by using ironclad:
$ LANG=en_US.UTF-8 clisp
(ql:quickload 'ironclad)
(ql:quickload 'md5)
(defun md5:md5sum-string (s)
(ironclad:digest-sequence :md5 (ironclad:ascii-string-to-byte-array s)))
(ql:quickload 'weblocks)
--------
lastly, for clisp:
you can't name your webapp the same as your asdf system, else weblocks tries to (probe-file "pub/") which is a dir, and clisp's probe-file doesn't accept dirs.
i.e. if your asdf system is "mywebapp", you can't (defwebapp mywebapp).
ideally weblocks would use a portability layer over the many compliant but incompatible probe-file implementations.
(such as
http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html)
in the meantime, a workaround is to explicity set the public-files-path:
(defwebapp mywebapp :public-files-path #p"/path/to/pub/")