[xcvb-devel] Installation problem

Wed Sep 2 13:37:30 UTC 2009

Hi again, I'm still alive :)

On 8/25/09, Faré <fahree at gmail.com> wrote:
> thanks a lot for taking the time and trouble to beta-test our software.

No problem. There're some interesting ideas on the docs, so I was
attracted to check this out :)

> 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

I will try the latest release soon. The stuff I'm talking about here
is still 0.357 only.

> 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.

Right, I see that actually installing will put the content of the
contribs dir and the sbcl.core in the same folder in
<installdir>/lib/sbcl/ so SBCL_HOME works as expected. I have
successfully rebuilt xcvb with the new path. It was quite muddled, and
unfortunately, I cannot retrace the steps/minor changes I made to get
everything to run, but I will probably need to check with 0.360 or
later versions anyway.

> 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.

I have not tried the latest SBCL yet.

>> 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?

In the end, I traced this to query-target-lisp-helper which calls
asdf:run-shell-command with something like

sbcl ... > some-file

My trouble arose from the 'sbcl' and path issue, where the exec
silently dies. This is confirmed by piping 2> to a file instead, where
I find

    fatal error encountered in SBCL pid 7972:
    can't find core file at
/home/tyc20/hda/sbcl/sbcl-1.0.29-x86-linux/contrib//sbcl.core

I fixed this by setting PATH and SBCL_HOME appropriately. I also
needed to set XCVB_PATH to my current module location to get a build
to run. None of this is very "referentially transparent" (if I may
abuse that terminology), since there are lots of hidden variables.

So I think I'm set, and right now, I'm stuck on this error:

    There is no applicable method for the generic function
     #<STANDARD-GENERIC-FUNCTION FULLNAME (4)>

    when called with arguments
      (NIL).
    0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {AD559BD}>)[:EXTERNAL]
    1: (SB-DEBUG:BACKTRACE
        536870911
        #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {9098821}>)
    2: (XCVB-DRIVER::PRINT-BACKTRACE
        #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {9098821}>)
    3: (XCVB-DRIVER::BORK #<SIMPLE-ERROR {AD50321}>)
    4: (SIGNAL #<SIMPLE-ERROR {AD50321}>)[:EXTERNAL]
    5: (ERROR
        "~@<There is no applicable method for the generic function ~2I~_~S~
              ~I~_when called with arguments ~2I~_~S.~:>")[:EXTERNAL]
    6: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T))
        #<unavailable argument>
        #<unavailable argument>
        #<STANDARD-GENERIC-FUNCTION FULLNAME (4)>)[:EXTERNAL]
    7: (XCVB::GRAPH-FOR-LISP-MODULE
        #<XCVB::STATIC-TRAVERSAL (:GRAIN-NAMES
                                  ((:LISP "/xcvb/driver") (:IMAGE "/_")
                                   (:FASL "/test-module/module1"))
                                  XCVB::DEPENDENCIES-R NIL
                                  XCVB::INCLUDED-DEPENDENCIES NIL
                                  XCVB::LOAD-COMMANDS-R NIL)>
        "/xcvb/driver")
    8: (XCVB::CALL-WITH-GRAIN-REGISTRATION
        (:LISP "/xcvb/driver")
        #<CLOSURE (LAMBDA #) {ACE5485}>)[:EXTERNAL]
    9: (XCVB::GRAPH-FOR*
        #<XCVB::STATIC-TRAVERSAL (:GRAIN-NAMES
                                  ((:IMAGE "/_") (:FASL "/test-module/module1"))
                                  XCVB::DEPENDENCIES-R NIL
                                  XCVB::INCLUDED-DEPENDENCIES NIL
                                  XCVB::LOAD-COMMANDS-R NIL)>
        ((:LISP "/xcvb/driver")))
    ... etc ...

I think I will try and bring up a REPL and slime debugger first. This
will be interesting. Part of the reason I am looking at xcvb is
because I have lots of issues with multiple versions of (often
incompatible) Lisps, individual projects, slime, boxsets (&
dependencies) etc. I wonder if there's a way to have multiple versions
of modules all run seamlessly? In other words, how can I run two
different versions of the same library simultaneously in the same Lisp
image, switching between the two as I see fit? Perhaps library
implementors might have to give up asdf & defpackage, and use some new
constructs for system definitions and dependency management instead?

>> 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.

No apology required. I knew what I was up against the moment I saw all
the Makefiles...

I'm only testing this out, so there is no urgency or any great need
for xcvb (for now) on my part.

> 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.

Good to hear. Hopefully, xcvb can one day be the tide that lifts all
Lisp projects upwards through a useful module system.

> [ 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
>