On Fri, Sep 10, 2010 at 15:34, Nandan Bagchee <[email protected]> wrote:
>> I have compiled the sbcl and it is located in the /usr/local, and I
>> have purged all of the ubuntu sbcl packages. As far as I can tell, the
>> default configuration for the sbcl if it is compiled and not
>> downloaded as the deb package is to put the fasls into
>>
>> $HOME/.cache/common-lisp/sbcl-version/appropriate-path-to-compiled-lisp-packages...
>> and those I have removed with simple rm -r $HOME/.cache/common-lisp/
>>
>
> Are you sure that sbcl doesn't have copies of those fasls in /usr/local?
Yes, I'm positive. I've done
find . / |grep fasl
and only fasls before I have tried your fix were in the /usr/local/lib/sbcl
> It's been a while since I've used sbcl on debian..
> Another thing to check: do the fasls in ~/.cache get regenerated. If yes,
> that makes sense, if not, that indicates theres a cached copy elsewhere.
They get regenerated.
>
>>
>> I've tried to locate all of the fasls (as root) with find but at the
>> moment all of the fasls still remaining in my system are located in
>> the /usr/local/lib/sbcl as part of the sbcl packages.
>
> But not the clbuild packages I hope!
:-) No, just the sbcl stuff - asdf, asdf-install, sb-aclrepl,
sb-bsd-sockets, sb-cltl2 and other sbcl specific stuff, and of course,
sbcl.core. No weblocks, or any of the other stuff. I'm using stumpwm,
and even that is not there, only in $HOME/.cache/common-lisp. Well, it
was before I have deleted all of the common-lisp directory content
with rm -r. :-)
>
>>
>> About an month ago I've tried the weblocks demo for the first time,
>> and it did work. I was using an version of the sbcl prior the 1.0.42,
>> and latest stable weblocks, so my guess is that either I have
>
> So did you clbuild update the packages? And can you check if the
> clbuild/systems link for weblocks.asd is correct?
I've done yesterday the last clbuild update of all the packages I have
installed, exactly because I was receiving this error. Including
cl-who and parenscript. I thought, perhaps someone fixed something in
the meanwhile... It says there is no need to update any of them, nor
the other weblocks dependency packages. Before that, I have updated
all of the packages a week ago, but like I said, I haven't tried
anything with weblocks for at least a month, and only did update and
compile the sbcl and stumpwm to the latest version. Other stuff I just
updated and left it that way "for the time when I get some more time
to try weblocks a bit more".
The weblocks.asd link is correct.
>
>>
>> misconfigured something, or perhaps the sbcl guys have either created
>> an bug, or made the sbcl more strict about packages in some way. Or,
>> perhaps CL-WHO or PARENSCRIPT teams had made some changes?
>
> I think that's what's happened. But Leslie reported a few days ago that this
> error only happens with weblocks-stable.
> Can you try this? To src/package.lisp add another shadowing-import line like
> this:
> (:shadowing-import-from :cl-who #:str)
> Does that fix the problem?
Well, it did fix this problem, but now I have another one. :-D This is
the error I receive now, and the request-handler.fasl in question is
not created, and the ASDF-TMP-request-handler.fasl is as it seems when
I take a look into the clbuild/source/weblocks/src deleted:
; compiling (DEFUN REMOVE-SESSION-FROM-URI ...)
; compiling (DEFUN REMOVE-ACTION-FROM-URI ...)
; compiling (DEFPARAMETER *STYLE-WARN-ON-CIRCULAR-DIRTYING* ...)
; compiling (DEFPARAMETER *STYLE-WARN-ON-LATE-PROPAGATION* ...)
; compiling (DEFUN RENDER-DIRTY-WIDGETS ...)
; compiling (DEFUN ACTION-TXN-HOOK ...)
; compiling (PUSHNEW (QUOTE ACTION-TXN-HOOK) ...)
;
/home/smilnovi/.cache/common-lisp/sbcl-1.0.42.35-linux-x86-64/home/smilnovi/lisp/clbuild/source/weblocks/src/ASDF-TMP-request-handler.fasl
written
; compilation finished in 0:00:00.319
WARNING:
COMPILE-FILE warned while performing #<COMPILE-OP NIL {10034CDF11}> on
#<CL-SOURCE-FILE "weblocks" "src" "request-handler">.
debugger invoked on a ASDF:COMPILE-FAILED in thread #<THREAD
"initial thread" RUNNING
{1002A9CEB1}>:
erred while invoking #<COMPILE-OP NIL {10034CDF11}> on
#<CL-SOURCE-FILE "weblocks" "src" "request-handler">
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [TRY-RECOMPILING] Try recompiling request-handler
1: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL {10034CDF11}> on
#<ASDF:CL-SOURCE-FILE
"weblocks" "src" "request-handler">.
2: [ACCEPT ] Continue, treating #<ASDF:COMPILE-OP NIL {10034CDF11}>
on
#<ASDF:CL-SOURCE-FILE
"weblocks" "src" "request-handler">
as having been successful.
3: [ABORT ] Exit debugger, returning to top level.
((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE))
#<unavailable argument>
#<unavailable argument>
#<ASDF:COMPILE-OP NIL {10034CDF11}>
#<ASDF:CL-SOURCE-FILE "weblocks" "src" "request-handler">)
0]
The strange thing (well, for me at least) is that before that there
are no error messages whatsoever, only notes like this:
; note: forced to do GENERIC-< (cost 10)
; unable to do inline fixnum comparison (cost 3) because:
; The first argument is a RATIONAL, not a FIXNUM.
; unable to do inline fixnum comparison (cost 4) because:
; The first argument is a RATIONAL, not a FIXNUM.
; etc.
and similar stuff about coercing "doing signed word to integer
coercion", no sign of some specific error...
--
Poći ću s vama jer volim šalu, hoću da vidim ježa budalu.
Put u Japan - http://ofcan.wordpress.com
--
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en.
