[xcvb-devel] Installation problem

[Faré]

Honorable Senator Zergling,

thanks a lot for taking the time and trouble to beta-test our software.

After your previous email, I've tried my best to address your legitimate
concerns about being able to use an SBCL at a non-standard location, and
the latest release of XCVB (0.360) should include provisions to let you
use whichever SBCL is properly installed to a directory in your $PATH.
So make sure that "sbcl" works at your shell prompt (don't try to run
it uninstalled from its source directory -- that's painful).
If the autodetection fails, please report a bug again.

I recommend using SBCL 1.0.30.4 or later (1.0.31.0 is due RSN), which will
have the advantage of providing your with CFASL support in addition to
being something with which we have tested our software.

.360 also includes the same verbosity patch as you wrote (as I found
the bug and its fix independently). It was tested on a multi-system build
(exscribe and all dependencies but disabling cl-typesetting), but not yet
on QRes. So hopefully it will work for you.

> However, at the moment, I still couldn't get make-makefile to run:
>
> tyc20 at binks:~/hda/code/lisp/my-first-xcvb-test$ xcvb make-makefile --build .
> end of file on #<SB-SYS:FD-STREAM for "file
> /home/tyc20/hda/code/lisp/my-first-xcvb-test/obj/target-properties.lisp-expr"
> {AB591F1}>
> 0:
> unhandled PRINT-NOT-READABLE: #<error printing object> cannot be
> printed readably.
>
> Argh! error within --disable-debugger error handling
Ouch. Which target lisp implementation are you using?
If that still happens with the latest SBCL, can you trace how xcvb
invokes the target lisp to extract its properties,
and what makes the target lisp choke?

> Ignore the .fas .lib stuff. I think they were leftover from a previous
> attempt (that's clisp, not SBCL). Is target-properties.lisp-expr
> supposed to ever be empty? What is read-first-file-form supposed to
> return for empty files (instead of read with errorp t), nil?  In both
> places that use it, there are some checks, eg read-target-properties:
>
It is indeed a bug that target-properties.lisp-expr should ever be empty,
and a bug that read-first-file-form should not handle a file without a form
(I will look for a fix RSN). If the problem persists when you remove
this file, then there's an important bug in xcvb.

> (let* ((file (target-properties-file))
>       (form (read-first-file-form file)))
>  (unless (and (consp form) (eq 'setf (car form)))
>    (error "Malformed target properties file ~S" file))
>  ...)
>
> so (read in nil nil) could work. Or have I not got the right things in
> the target file?
>
Yes. .361 will have (read in nil nil). Thanks for this fix.


>>> (mapc (lambda (x) (load (compile-file (append-path x))))
>>>      '("driver" "pkgdcl" "macros" ...))
>>>
>>> Could be automated somewhat by direct extraction of the form in
>>> xcvb.asd.
>>>
>> Nope. XCVB is a binary that has to be created by cl-launch somehow and
>> be in your $PATH.
>
> So do that mapc thing (and asdf load dependencies), then save-image
> and resave image with cl-launch? Although if xcvb can do some of the
> building instead of using make, that could be easier too.
>
Yes, you could do that. But indeed the Makefile should do it for you
already. If it doesn't that's a bug. Note that you may bootstrap with:
         make xcvb-using-asdf

> Next time, I'm gonna try and run MAKE-MAKEFILE, REMOVE-XCVB-COMMAND
> (in main.lisp) etc on the REPL. Is that how you are all using it at
> the moment?
At the moment, I am using it at the shell prompt, though sometimes
indeed I use the repl for debugging -- particularly with
	C-u M-x slime env LISP_FASL_CACHE=NIL XCVB_PATH=... xcvb repl

> Thanks for the help, I will continue to explore when I find time.
Thank you so much for your testing.

My apologies for the trouble you're having.
I'm definitely committed to make XCVB a usable tool for everyone and
not just something that merely works for me in my particular setting.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The trouble with opportunity is that it always comes disguised as hard work.
		-- Herbert V. Prochnow