[hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X

[Lou Vanek]

On Wed, Mar 16, 2011 at 10:10 AM, Oleg Sivokon <olegsivokon at gmail.com> wrote:
> Thank you for responses. I didn't intend to make it look as if I'm blaming
> Hunchentoot developers for anything I mentioned above. Sorry if that how it
> looks.

I am not a hunchentoot committer. Your notes address issues that only
tangentially involve hunchentoot. I was serious when I said that if you
want to improve your situation you should direct your inquiries to those
most interested in resolving them. This ML's primary focus is hunchentoot,
not packages that hunchentoot may or may not be using, or SBCL
issues.


> My question was rather: is this an average path for someone to get
> things working?

No. You have likely screwed something up but since you provide
so few specific details it's hard to tell.

I have four CL implementations installed -- and that's on just one
of my VMs. When things go south sometimes I'm forced to experiment
until a pattern emerges. That often means that I have to expend
energy trying to figure out what's going on.


> In attempt to study the subject myself I came across a lot
> of information, and being new I have sometimes no idea of whether the
> information is of any real value.
> For example, my choice of SBCL of all CL variety was based upon comments on
> Stack Overflow site. I did not try all other kinds. Now, this is not a
> complaint, I really want to know, if my final goal is to use Hunchentoot, is
> SBCL a good choice or not?

SBCL should work with all the common packages that are installed
beside hunchentoot, yes, as long as it's a relatively recent SBCL.


> In my experience "more forgiving" tends to give
> more problems in the end,

Not in this case. You don't have much experience.


> but I'm not sure what that would meant in given
> context.

No, you don't.


> Regarding installations - as per my experience with other environments,
> automatic tools rarely work (Ruby gems would be another perfect example!).
> Yet I don't know enough to make installations completely by hand, I would
> much prefer to see this sort of instructions. Again, per my experience, most
> often an "installation" would scale down to unpacking an archive to several
> folders and defining several environmental variables,

That's pretty much about it. To install a package that comes with an .asd file,
all you have to do is download it, unzip/untar/git/pull/get/whatever the source
code and place in a directory. Usually this is a common directory where all
lisp library code is stored. It's not important where it is located,
just as long
as it is readable. Probably a good idea to change permissions of any of
these files to anything other than root, preferably to the owner who is going
to run CL.

Then there is usually one directory where you place all your .asd links.
This directory may be called something like site-systems. When ASDF
wants to load one of the asdf packages it looks in this directory for a link
back to the .asd file that you just installed.

So, if you just installed package1 in /var/lib/cl/package1
you would want to add a link to its asd file by doing something like
ln -s ../package1/*.asd .
assuming that the cwd is /var/lib/cl/site-systems.
Make sure that the asdf central repository can be found by asdf:
(push "/var/lib/cl/site-systems/" asdf:*central-registry*)
This is usually placed in your CL initialization file. For sbcl,
this file is called .sbclrc. That's it. Or you could do what
others have been advocating and use quicklisp.


> however, I simply
> don't know which files should go where, and what environmental variables to
> set,

Usually there are no env vars that require setting. If there are, they
are usually
set in code when the package loads.

> if I wanted to make sure there was not an error on my side. This also
> leaves me in the situation when I'm clueless as to who to blame for broken
> installation...

Look at the compilation messages and look for the package where the
errors occur. That package maintainer should be contacted if you are
having problems with that package.


> I don't even know how the properly working environment looks
> like...

If you can do a (list-all-packages) and see the package you tried
to install, and you didn't see any errors during installation, then
that is a properly working environment. Many packages include
tests that you can run, also. Each package has a unique method
of running the tests, however, so you have to look through the
package to see how to run the tests. Many times just loading
a test package defined for that package will invoke the tests.
And in order for that to work you would, again, have to have
an .asd link defined between your asdf central repository directory
and the asd file that defines the test package.


> Another reason for asking here is that, again, knowing how it happens with
> other technologies, it's worth at least to try to figure out if what I'm
> facing is not some sort of known problem. For instance, I came across a
> notion of Hunchentoot not installing on SBCL, it was filed against some
> clone of SBCL on github under category "wishes and future improvements" in
> April last year. It is unresolved so far. This information helps
> understanding that there was a problem, yet I cannot figure out if it was
> ever fixed, and even if it has anything to do with my setup.
> That's why I asked about bug tracker. It would be ultimately helpful to
> search some source being certain that the information found may be trusted.
>
> This may sound again a silly question... but how would I log what happens
> during package installation? Often times the console capacity is not enough
> to accommodate all messages displayed during compile,

You don't say how you are running SBCL. If you are running from a command
line you can simply increase the history that is saved by your shell. Check the
documentation for your shell to see how that can be increased.

Another -- preferred -- way to handle this would be to install emacs and
slime and do your work in that environment. Emacs saves history and
compilation messages when compiling/loading with slime. The internet
is full of docs explaining how to set this up.


> but I cannot just
> redirect the output to a file, because I would miss the restarts etc...
> Thank you.
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>