Re: [Gsll-devel] extra info in the example section
On Wed, Apr 28, 2010 at 8:17 AM, Mirko Vukovic wrote: > See below: > > On Tue, Apr 27, 2010 at 9:22 PM, Liam Healy wrote: >> I'm not sure what you're looking for here, but I've never >> had "GSL libraries not loadable" (not sure what you mean >> here; not found in the path?). Doesn't the form >> (cffi:use-foreign-library libgsl) >> at the end of init/init.lisp fail with some kind of reasonable >> error message if it doesn't find the libraries? What else >> is needed? >> >> Liam >> >> On Tue, Apr 27, 2010 at 8:56 AM, Mirko Vukovic >> wrote: >> ... >>> >>> Good idea. Here is another one that would be useful even for the >>> pros. A gsll-probe, that would probe the system to make sure that >>> gsll is loadable. The main thing that comes to mind, and that can >>> look scary to a newbie is if the gsl libraries are not loadable. > > I was thinking of absolute Newbies who get horrified when lisp drops > into a debugger. A way to deal with that might be to use exception > handling with `gentler' messages. That's OK, provided it can be turned off. I'm not sure there's a general way to provide a global handler in CL though. > > And other than finding libraries, sometimes the libraries are not > loadable: with SBCL1.0.34, I got an `offset' error (don't remember > exactly what), and with 1.0.37, I could not load 64-bit libraries. Weird. I have no idea where that comes from, and I'm using a fairly recent SBCL and I've been using 64 bit for years. > > Anyways, I don't mean to throw this task to you. I'll think about an > implementation, and if I come up with something sensible, I will post > it here. OK, sounds good. > > Mirko > ___ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
Re: [Gsll-devel] extra info in the example section
On Wed, Apr 28, 2010 at 4:02 AM, N J wrote:
> On Wed, Apr 28, 2010 at 3:22 AM, Liam Healy wrote:
>> I'm not sure what you're looking for here, but I've never
>> had "GSL libraries not loadable" (not sure what you mean
>> here; not found in the path?). Doesn't the form
>> (cffi:use-foreign-library libgsl)
>> at the end of init/init.lisp fail with some kind of reasonable
>> error message if it doesn't find the libraries? What else
>> is needed?
>
> I am a beginner of both lisp and lisp packages and I remember that I
> got a very puzzled when I just started using gsll. After testing
> different combination of packages (stable and unstable) I finally
> managed to installed all the packages successfully (gentoo). Then I
> tried the
>
> (asdf:operate 'asdf:load-op :gsll)
>
> in sbcl. And I got tons of messages and error messages:
>
> *put last in email for readability
Generally speaking in any programming language, you should look
at the *first* error message and try to figure out what caused it. Granted,
that's not always easy to find, but in your case it is actually coming from
gcc,
> error: ffi.h: No such file or directory
which indicates that it can't find the path to the libffi header file, used
by FSBV. This is a common problem unfortunately. I threw up my
hands at trying to solve this in general. If anyone has any ideas,
I'd like to know it.
As for stopping the run-on error messages so that it's easier
to find the first one, it would be nice, but
again, I don't know how to do that. Perhaps the CFFI mailing
list would help.
>
> And because there were so much information (compile messages and error
> messages) I had no clue how to continue. Either I hadn't really
> installed the packages correctly (gentoo) or I had a problem with
> gsll. Then, when I finally got it to compile (with the help from here
> by the way, thanks) it was not really obvious for me that everything
> was successful.
That does take some getting used to. Unfortunately that's more
a product of the compiler and not really anything GSLL can do.
Some compilers and environments are better than others.
>
> So, maybe it is redundant for most people but it would be very helpful
> to have some sort of checklist / getting started, on the web page, to
> be able to see what is working and not. Especially as there are 4-5
> packages that needs to be installed, and people are using different
> systems (Ubuntu, Debian, Gentoo or just git) and will end up with
> different versions.
>
> Or maybe, a summery at the very end of the (asdf:operate 'asdf:load-op
> :gsll), saying that everything went as expected or which part that
> went wrong.
I'm not sure what you mean here. A checklist of what?
"Getting started" in general is hard because of the tremendous
variety of implementations and operating systems, where
output looks very different. You can see on the web page
I provided installation
instructions, and I'm going to remove most of it because it
is incomplete and too hard to make complete. It is also
unwise to rely on features that may change or be unsupported
because then it's a headache to maintain.
I sympathize with the difficulty of interpreting output from
an unfamiliar system, and distinguishing success from
failure, but I don't see how GSLL can overcome that.
I can't think of any other CL system that does something
like think; if someone knows of something, we could copy it and
adapt it to GSLL.
Liam
>
> // NIK
>
> *
> ; loading system definition from /usr/share/common-lisp/systems/c-array.asd
> ; into #
> ; registering # as C-ARRAY
> ; compiling file "/usr/share/common-lisp/source/fsbv/init.lisp"
> (written 01 MAR 2010 11:39:35 PM):
> ; compiling (IN-PACKAGE :COMMON-LISP-USER)
> ; compiling (DEFPACKAGE :FOREIGN-STRUCTURES-BY-VALUE ...)
> ; compiling (CFFI:LOAD-FOREIGN-LIBRARY "libffi.so")
> ; compiling (PUSHNEW :FSBV ...)
>
> ;
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/init.fasl
> written
> ; compilation finished in 0:00:00
> ; cc -m64 -fPIC -o
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c
>
> debugger invoked on a SIMPLE-ERROR in thread # RUNNING {10023F6A01}>:
> External process exited with code 1.
> Command was: "cc" "-m64" "-fPIC" "-o"
> "/home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix"
> "/home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c"
> Output was:
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:7:17:
> error: ffi.h: No such file or directory
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:
> In function ‘main’:
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40:
> error: ‘
Re: [Gsll-devel] extra info in the example section
See below: On Tue, Apr 27, 2010 at 9:22 PM, Liam Healy wrote: > I'm not sure what you're looking for here, but I've never > had "GSL libraries not loadable" (not sure what you mean > here; not found in the path?). Doesn't the form > (cffi:use-foreign-library libgsl) > at the end of init/init.lisp fail with some kind of reasonable > error message if it doesn't find the libraries? What else > is needed? > > Liam > > On Tue, Apr 27, 2010 at 8:56 AM, Mirko Vukovic > wrote: > ... >> >> Good idea. Here is another one that would be useful even for the >> pros. A gsll-probe, that would probe the system to make sure that >> gsll is loadable. The main thing that comes to mind, and that can >> look scary to a newbie is if the gsl libraries are not loadable. I was thinking of absolute Newbies who get horrified when lisp drops into a debugger. A way to deal with that might be to use exception handling with `gentler' messages. And other than finding libraries, sometimes the libraries are not loadable: with SBCL1.0.34, I got an `offset' error (don't remember exactly what), and with 1.0.37, I could not load 64-bit libraries. Anyways, I don't mean to throw this task to you. I'll think about an implementation, and if I come up with something sensible, I will post it here. Mirko ___ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
Re: [Gsll-devel] extra info in the example section
I'm not sure what you're looking for here, but I've never had "GSL libraries not loadable" (not sure what you mean here; not found in the path?). Doesn't the form (cffi:use-foreign-library libgsl) at the end of init/init.lisp fail with some kind of reasonable error message if it doesn't find the libraries? What else is needed? Liam On Tue, Apr 27, 2010 at 8:56 AM, Mirko Vukovic wrote: ... > > Good idea. Here is another one that would be useful even for the > pros. A gsll-probe, that would probe the system to make sure that > gsll is loadable. The main thing that comes to mind, and that can > look scary to a newbie is if the gsl libraries are not loadable. > > Along those lines, I was wandering if the gsll setup would be easier > if the user were required to set-up a feature *gsll-user* (or some > other such name. This symbol would have in its plist the gsl library > location. > > Mirko ___ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
Re: [Gsll-devel] extra info in the example section
Good idea. I'll try to remember to do something like this. On Tue, Apr 27, 2010 at 6:40 AM, N J wrote: > Hey, > > I have a suggestion that might be obvious for all experts but > nonetheless a little help for newbies like myself. Especially since > gsll might be the first lisp package they (like me) want to try out. > > In the example section in the web page, would it be possible to add a > small "getting started". Maybe it can be combined with the first > example. For example. > > Getting started > > Make sure that your are able to load the system. > > (asdf:operate 'asdf:load-op :gsll) > > This should load up the system without errors. The last lines should > be looking something like: > > ; registering # as GRID > ; loading system definition from /usr/share/common-lisp/systems/c-array.asd > ; into # > ; registering # as C-ARRAY > NIL > * > > Then make sure that you use the gsll package, run the following > > (in-package :gsl) > > This should tell you that the gsll package is ready with the following line: > > # > > Now you are ready to try out one of the many gsl functions > > (jacobian-elliptic-functions 0.2d0 0.81d0) > > which should give you something like this: > > 0.19762082367187703d0 > 0.9802785369736752d0 > 0.9840560289645665d0 > > If the above steps have worked successful, you are ready to jump into > the amazing world of gsll. > > ___ > Gsll-devel mailing list > Gsll-devel@common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel > ___ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
Re: [Gsll-devel] extra info in the example section
On Tue, Apr 27, 2010 at 6:40 AM, N J wrote: > Hey, > > I have a suggestion that might be obvious for all experts but > nonetheless a little help for newbies like myself. Especially since > gsll might be the first lisp package they (like me) want to try out. > > In the example section in the web page, would it be possible to add a > small "getting started". Maybe it can be combined with the first > example. For example. stuff deleted... Good idea. Here is another one that would be useful even for the pros. A gsll-probe, that would probe the system to make sure that gsll is loadable. The main thing that comes to mind, and that can look scary to a newbie is if the gsl libraries are not loadable. Along those lines, I was wandering if the gsll setup would be easier if the user were required to set-up a feature *gsll-user* (or some other such name. This symbol would have in its plist the gsl library location. Mirko ___ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
