[Bese-devel] Re: Loading UCW with ucwctl, cl-launch etc

[Luca Capello]

Hello!

On Thu, 13 Apr 2006 03:34:41 +0200, Nathan Bird wrote:
> Trying to keep the length down, but we have a couple of topics going
> on simultaneously here.

Finally someone who writes long mails like me ;-)

>> I'd like to note that my patch doesn't depend on any Debian
>> package.  The problem about cl-launch vs cl-launch.sh was a very
>> stupid one.  The SLIME problem with cl-launch has nothing to do
>> with Debian, in fact the Debian cl-swank package adopted a
>> different workaround.
>
> Ok, you are correct. I had gotten this from detachtty, which was
> ALREADY a requirement that I had installed it with apt.

Yes, I forgot that detachtty was primarily developed for Debian :-(

> As a note I haven't been using the common-lisp-controller,

I tested my patch various time with and without the c-l-c: except the
cl-launch + SLIME bug, AFAIK no other problems.

> I take it some of this work is to get UCW into a Debian system?

Well, my final aim is to get UCW into Debian, but I tried to be as
most Debian-unrelated as possible.  The first step was to avoid manual
modification of the sources to configure UCW, which is IMHO a
requirement for a newbie (not only a Debian user).

> Is there any way to use a ucwctl.conf that isn't at /etc/ucw? I am
> going to have to specify at least configfile and var every time.

Ok, I think I need to implement another option for ucwctl, which will
be -u or --ucwctl-config and will default to /etc/ucw/ucwctl.conf if
empty.  Moreover, this won't be a mandatory option, as all ucwctl.conf
values can be overridden by the other command line options.

I think that --config-file should still refer to the conf.lisp, so the
UCW config file, not the ucwctl one, otherwise we should change every
file option, something like

    --config-file   --->   --ucw-config-file
    --start-file    --->   --ucw-start-file

Moreover, as of [1], in the next few days I'll submit the patch to
stop UCW via a stop.lisp file, which will be option -k or --kill-file
(well, we can't use -s, but maybe --stop-file is better).

> What is the intention of ASDFROOT? Is this a replacement/standin for
> any asd setup the lisp or lisp-init-file had been doing previously?

Imagine that you've some ASDF files in ~/.sbcl/systems/ and others in
~/systems: the former is by default picked up when you fire up SBCL,
the latter needs to be added by hand.  In this case, you specify
$ASDFROOT for ~/systems.

Obviously, the same can be done specifying the paths in ~/.sbclrc, but
$ASDFROOT is simpler if you want to test different version libraries.

> The frustration is in having to specify several command line
[...]
> that yesterday. (Thanks everyone)

As I posted yesterday [2], now you can load the start.lisp file
directly with `sbcl --load start.lisp`.

Moreover [3], you can specify any parameter you want in that file, too
(just do it before the `:ucw.default' system is loaded up).

>> BTW, as Marco suggested on private conversation, ucw_dev/bin/etc
>> should be probably moved to ucw_dev/etc.
>
> I like the idea of ucw_dev/etc.

I'll do that adding an INSTALL file, too, and maybe updating the
README ;-)

> Is there a reason you don't like having all of the configuration
> wrapped up into UCW? If the files are being distributed in
> ucw_dev/etc it is more intuitive to me to have the defaults point
> there.

I always thought about UCW as something you need to install, with the
configuration separated from the sources.

One possible "developer" solution will be to provide a ucwctl.dev,
which defaults to ucw_dev/etc.

Or, from a local user POV, defaulting to /usr/local/etc (which I don't
like at all).

> I'm (attempting to) suggest we have the defaults make UCW work out
> of the box... you know after forcing the guy to fetch a dozen
> different dependencies :-)

At least in my opinion, out-of-the-box means after something like a
`make install` (as root or local).  I've some ideas how to solve it
even without a `make install`, I'll try to work on.

Thx, bye,
Gismo / Luca

[1] http://common-lisp.net/pipermail/bese-devel/2006-April/001862.html
[2] http://common-lisp.net/pipermail/bese-devel/2006-April/001924.html
[3] http://common-lisp.net/pipermail/bese-devel/2006-April/001925.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20060413/e83c8b57/attachment.sig>