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

[Lou Vanek]

Oleg,

It would help if you were to include what type of machine(s) you are
installing on
when submitting these types of notes. For example, is it Intel,
Intel/Mac, PPC (Power PC),
Sun, ARM, etc.

At the REPL, enter *features* to see what type of machine CL thinks
you are trying
to compile your packages into. If you are not using a Power PC then
you shouldn't
see PPC as one of the features, for example. If you do see an anomaly
such as this
that would explain some of the bizarre problems you are having.

I can't see a single thing in your writing that directly relates to
Hunchentoot. Yes, you
had problems, but they relate to the CL and auxiliary packages, not to
Hunchentoot.
If you want things to change for the better you should be directing
your concerns to
those package maintainers whose packages gave you trouble. Of all the points you
make below, not one stems from a problem in Hunchentoot code.

When installing Hunchentoot it helps to have the latest versions of
the packages it
uses, especially if the support packages are also written by Edi. That
may explain
some of the problems you had, but I suspect there are deeper issues.


On Tue, Mar 15, 2011 at 6:56 PM, Oleg Sivokon <olegsivokon at gmail.com> wrote:
> Hello.
>
> Please forgive me asking questions with probably obvious answers. I'm new to
> the Lisp world in general, and to using Hunchentoot too.
> Since I'm new, I had a lot of problems installing Hunchentoot... I had
> successfully did it on two Ubuntu 10.4 machines, one 32 bit and another 64
> bit both running last SBCL available from Ubuntu PPA. I had also tried to
> record my experience so I could explain it to anyone who asked.

If you recorded your experience with specific package versions and error
messages that would be useful (not to this ML but to the package maintainers).

> I'm
> effectively writing a mock-up server to do testing for the project that
> otherwise runs in a different environment, yet, at some point I would like
> other people to be also able to replicate my steps on installing the server
> and running my code.

One option is you might be able to provide the Lisp image that you have built
so that they do not have to build it themselves. If they are using the same
architecture and OS this should work, assuming you can make your CL image
available.


> Major problems I encountered:
> - ASDF does not update... (I know, you have nothing to do with this, yet
> whenever the manual on the site mentions ASDF, it would be great if it would
> take in account that ASDF not only may do things wrong, it most probably
> will...). Long story short, I've tried to update ASDF following manual on
> their site - never worked due to some missing methods or just reverting to
> the last version w/o any notion.

ASDF comes bundled with most of the free CLs. You do not need to install
this yourself. In fact, it's better if you don't if it comes with your
CL because it's
easy to mess up the ASDF installation unless you know exactly how your CL
distro installed ASDF.


> I've also tried building SBCL from sources.
> The last version in development comes with latest ASDF version (2.0), yet
> the installation instructions are bizarre and contradict themselves... At
> the most successful point I could install what compiles from trunk, but in
> order to run that version as root, I would need to specify the sbcl.core on
> launch.

You should file a bug report with SBCL and ask them to clarify the install
process at those areas where you had trouble. If you know what the solutions
to your problems are, write them down and submit them to SBCL and maybe
they will include them in their install instructions. I don't know why
you mention
this on a Hunchentoot ML.


> I could also install Hunchentoot into this version of SBCL, but it
> had problems with UFFI (separate story below).

My version of Hunchentoot doesn't load UFFI, but it loads CFFI instead.
No problems.


> Various other packages in
> this mode would report missing files or non-existing functions and so on.

If you are referring to SLIME, non-existent functions are not errors or even
warnings. SLIME is used by a large number of Lisps and not all Lisps
support all of SLIME's API. Those are developer notes that can be ignored
(if these are SLIME notes).

If this is not SLIME, you should get in contact with the package maintainers.
I have never seen these types of messages for Hunchentoot.

> It
> proved to be unusable.
> - ASDF-INSTALL, similarly, trying to install from archive or from site
> (clicky) were subsequently unsuccessful.

I don't use ASDF-INSTALL since I like to install everything myself. It's
actually quite simple: download the package and add one link (in most cases)
to the .asd file.


> Having only clean SBCL install,
> ASDF-INSTALL would break at random trying to solve dependencies. I couldn't
> find the pattern. By trial and error I found, that the combination of having
> CL-PPCRE, USOCKET, CLOSER-MOP and CXML (!) would most of the time lead to
> that Hunchentoot would be able to find all dependencies during install. This
> happened 2 times out of maybe 8...

Here's a tip: try loading Hunchentoot-dependent packages prior to Hunchentoot
by REQUIREing them in a file and evaluating this file.
This way you can pre-load your packages and if there are any problems you can
see exactly which package is giving you trouble.


> - There's some package, which during installation would break the display in
> console... (the console will start displaying random non-printable
> characters) It would also stop during compile offering different restarts,
> where you are forced to play pitch-n-toss :) And if you are lucky, then the
> console will recover.

Don't know what's going on there. Never seen this. It could be tests,
but unlikely.


> - Finally, the most sure way I found was to just (require :hunchentoot)
> using ASDF v 1 and resolve missing dependencies by hand.

Don't do this be hand; put the dependencies in a file and evaluate it
prior to loading hunchentoot.


> It would sometimes
> break when trying to install CL-PPCRE,

I have never had a problem loading cl-ppcre. Maybe your packages are
out of date.


> presumably due to another dependency
> having something to do with Unicode, but it succeeded more often then
> failed.
> - UFFI - for all I tried it failed to compile and install properly always.
> It looks like the errors are in *insignificant* tests, yet for an
> unexperienced user this looks scary (mistyped pointers?!) :) Often the
> errors when compiling this package will also break the installation started
> by ASDF - it will not offer to skip the failed compilation, or so I
> understood what happened. (I also saw some messages regarding omission of
> "dead" code, while compiling this package - this also looks suspicious, why
> would anyone release such code, and may there be any connection between
> that, and that the code failed to compile in the end?)
> Some weird things I saw during installation: an attempt was made to install
> SLIME.

I can't think of any package that would try to install SLIME. By looking at the
compilation notes you should be able to see what package is trying to do this.


> It somehow got into dependency list of Hunchentoot... I've
> encountered several times notion of 64-bit processor architecture in
> different libraries related to Common Lisp as "PPC" - I never heard of this
> abbreviation before in this context, (no pun intended), what does it mean?

Power PC, the CPU Apple used prior to switching to Intel. If you are on an
Intel machine and you have PPC in your lisp features then that would
likely cause
a lot of problems.


> This was one of really confusing places when reading the documentation (I
> would assume it to be Apple Motoralla processor from 10 years ago). For
> whatever other arcane reason Ubuntu / Debian tech papers call supported
> 64-bit processors AMD86 or AMD8664 (some of them having nothing to do with
> AMD!).

32-bit Ubuntu/Debian will work with all modern 32-bit Intel and AMD CPUs.
Likewise for 64-bit. Last time I checked, everything above a 386 was supported.
For the most part, Intel and AMD have the same instruction set so
there shouldn't
be a problem using either vendor.


> Now, my question is, is my experience something you would expect a user to
> undergo? Is SBCL an experimental brunch of Common Lisp, and, would I want to
> develop in more stable environment, do I have to switch to another version
> of CL?

SBCL is not experimental, but it does have trouble compiling a couple
of packages.
I find Clozure Common Lisp (CCL) to be more forgiving than SBCL.


> (Back in the days I've used CMUCL on Windows, albeit very shortly,
> but I don't recall that many problems...) Or are Hunchentoot and SBCL not
> really compatible, and the attempt to put them together makes it so
> difficult?

>From your notes it appears that Hunchentoot has next to nothing to do with
your problems. It's the other packages that seem to be giving you problems.


> Of course, most chances are I am doing something wrong :) Yet it would be
> nice if someone more experience commented.
>
> Oh, and btw, I've managed to then install CL-GD and use it with Hunchentoot,
> for that I had to, again, delete some shared libraries in system folders and
> rewrite Make file... It worked, as I said, but, again, I've a feeling I do
> things the wrong way and it shouldn't be this difficult...
>
> And, one last thing, if there are bugs filed against the server, is it
> possible to view them somewhere? I've found few bug-trackers during my setup
> exercises :) however, I'm not sure which is an official one.
>
> Thank you.
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>

If you are interested in getting this fixed, break the problem down
into small chunks
and try to identify individual problems, providing version numbers (or
dates) so that
other people can try to reproduce these issues.
You should also direct your email to those who are most likely to be
in a position to fix
them. Since you weren't able to specify a single Hunchentoot problem,
this ML is the
wrong place to post if you expect people to try to solve any of the
problems you had.

But since you had so many bizarre problems the odds are the problem is
on your end.
As previously stated, notes such as what you submitted are not of much use.
They are not specific and don't appear to be addressed to the appropriate MLs.
There are a couple of ways you can be more specific without making
your email too
long. You can use paste.lisp.org to save technical output that shows
the errors, or you
can submit bug reports.