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

[Luca Capello]

Hello!

On Wed, 12 Apr 2006 01:40:42 +0200, Nathan Bird wrote:
> What? How? Seriously, I'm lost here.

And I'm here to save you :-D

> I spent a while earlier today trying to get this installed. I got
> cl-launch, the custom version of detachtty the works (I thought), no
> dice :-(.

Output?  Log?  Lisp implementation?  Without any more details I cannot
improve the ucwctl system :-(

BTW, I tested my patch on 3 different machines: a Debian one (with
c-l-c and all the packets present in Debian, like cl-arnesi and so
on) and on two others Debian-based (but with no c-l-c and all the
software manually installed, different SBCL versions).

> I'm not even particularly sure what all I'm missing. For the time
> being I've just rolled back to before these patches so that I can
> continue working.

Yes, this was Marco's advice before finding a solution.

> Here are a few of the things that caused problems for me (and at
> least one fellow newbie in #ucw today).
                             ^^^^
Usually, I'm most of the time there, but to be sure to reach me send a
private message ;-)

> *	There is big benefit to using start.lisp.

I see...

> Depending on debian packages and such makes that harder for anyone
> to get it going there.

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.

> *	Multiple instances of UCW. Because I work at a windows shop,
> we are developing on UCW on a shared linux server. We each have our
> own instance of UCW on this server. Installing stuff to /etc doesn't
> work in this case.

Nothing needs to be installed, as for the ucwctl command line
arguments...  But I agree that having multiple shell scripts just to
start multiple ucwctl instances with different parameters is not the
best thing.

> *	Defaulting to locations that don't exist (/etc/ucw/ucwctl.conf).
> Defaulting to locations inside UCW is a bit easier (especially on people
> getting UCW for the first time and just wanting to see what is going on).
> Can we instead default to ucw_dev/bin/etc/* ? 

I should say that the other idea was to implement something like a
`make install` command...

I'm against defaulting to ucw_dev/bin/etc/*, but if this is the common
decision, I'll agree on that.

BTW, as Marco suggested on private conversation, ucw_dev/bin/etc
should be probably moved to ucw_dev/etc.

> *	What are the different configuration files?
[...]
> *	ANYTHING in the readme?

Maybe I didn't sponsor it, but there a manual page for ucwctl:

  $ cd /path/to/ucw_dev
  $ cd bin
  $ man ./ucwctl.1

The README should absolutely be updated, I know, but free time is
always a problem here.

> There are distributed comments to this effect, but if we are
> supposed to be copying and editing a bunch of stuff an installation
> guide would be incredibly handy.

This could be in the README or, better, in a INSTALL file, agreed.

> *	"ucwctl -help" reports the option as -config-file, whereas the
> script appears to actually parse -config

Sorry, really a stupid mistake already corrected.

> I hope this helps out, please don't take it negatively, I do
> understand I am working with bleeding edge beta software here. :-D

No problem, I was quite impressed that no one complains before ;-)

Thx, bye,
Gismo / Luca
-------------- 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/20060412/e3ffdf73/attachment.sig>