[xcvb-devel] Installation problem

[Faré]

Honorable Senator,

> Hi again, I'm still alive :)
Glad the reavers didn't get you...

> I will try the latest release soon. The stuff I'm talking about here
> is still 0.357 only.
A lot of big and small bugs have been fixed in .366 including many
issues with the packaging of the release tarball.

> 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.
>
Oops. I'm adding this paragraph to the README under `Compiling with XCVB`_:

Note that you need to properly setup your `Search Path`_ with ``XCVB_PATH``,
or specify it with option ``--xcvb-path``.
Also, XCVB will assume that the specified implementation,
``sbcl`` or otherwise, is in your ``PATH``, though you may override with
``--lisp-binary-path``.
If needed, make sure you export the proper
``SBCL_HOME`` or ``CCL_DEFAULT_DIRECTORY``, etc.,
or that some wrapper script to your Lisp binary does.



> 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).
[...]
>    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")

Oops. This means that the installed XCVB is not in your XCVB_PATH.
I'm adding this to the README under `Search Path`_:

Importantly, an installed version of XCVB itself
(at least its ``build.xcvb`` and ``driver.lisp`` in the same directory)
must be present under the search path
since XCVB will look for the module ``/xcvb/driver``
to be included in the target Lisp image as a necessary prelude to any build.

In a good installation of XCVB, this should be the case by default,
and users would use ``!`` in their search path specifications
to inherit this default;
however, until XCVB comes packaged with your system,
you shouldn't trust these defaults until you have verified them.

> I think I will try and bring up a REPL and slime debugger first.
Don't bother, I understand the issue.
Hopefully, XCVB .366 has more informative error message, too.

> 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?
>
This is a problem that XCVB can't directly help you with.

XCVB will help you easily have multiple versions in multiple images,
by having a different XCVB_PATH.

To have the SAME lisp image use multiple versions of a library,
you need to be able to load them at the same time, which at the very least
would require you to play tricks with RENAME-PACKAGE to rename the
code from one version before you load the code from another.
Then again, client code can only be compiled with one version of the
server code, so you may have to duplicate and rename not just the
one package, but each and every package after it -- which wouldn't
give you much more than having multiple images.

NOW, *if* you only want to switch between a few identified run-time
things that happen to be functions and/or variables, whereas you trust
all the macros to be functionally the same, then you could indeed do
tricks with something that would walk the package for bound and fbound
symbols and do a switcheroo between two versions of them. But that's
assuming a lot, and still doing stuff that CL isn't helping you with.
And XCVB currently has no support for such thing (though it could be
added with no more difficulty to XCVB than to ASDF).

>> 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.
>
Or maybe we should all switch to R7RS.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Genius is one percent inspiration and ninety-nine percent perspiration.
		-- Thomas Alva Edison