[Gsll-devel] Build error (fsbv)

A.J. Rossini blindglobe at gmail.com
Sat Jul 4 19:50:40 UTC 2009


On Sat, Jun 27, 2009 at 7:23 PM, Liam Healy<lhealy at common-lisp.net> wrote:
> On Fri, Jun 26, 2009 at 3:35 AM, A.J. Rossini<blindglobe at gmail.com> wrote:
>> I had problems with newer GSLL compilation until I pulled a new CFFI
>> from DARCS (and some of the deendences, I think babel OR alexandria),
>> cleaned out FASLs, and then everything "worked".
>>
>> (running Debian unstable, bleeding/hemorraging all the way).
>>
>> best,
>> -tony
>
> Tony,
>
> Excellent point.  It is necessary to pull a new CFFI, at least 0.10.5,
> which is stated in documentation/index.html (which is also on
> http://common-lisp.net/project/gsll/).
>
> I routinely wipe out all my fasls when I am testing to make sure
> everything builds cleanly.  In order to make this easy in
> common-lisp-controller I wrote a shell script called
> `clc-make-clean' as follows:

Thanks, much appreciated!  I have to add that to the general CL
utilities I've got (esp as part of a release testing strategy).

> On another subject, I notice you have been doing a lot of work on Lisp
> interfaces to other science/engineering/math libraries, like R.  My
> intent in building GSLL was that it would become part of a collection
> of systems that would have consistent use and interchange of data
> between different libraries.  So for example, you would be able to
> make an object representing an array, call a GSLL function, then pass
> the resulting array to R.  There are a lot of aspects of this problem,
> but I'm thinking about array standardization as a start.  Do you have
> any thoughts on this?

The RCLG package has some stuff in the right direction (Rif wrote it,
I'm maintaining it).  RCL and CLSR, 2 others, have respectively,
better lispy interfaces and some better internals (roundtrip and
better object mapping).  I'd look at Cyrus Harmon's CLSR as a start,
as much as I'd love to have you contribute to RCLG.

We ought to be able to seemlessly use R's S4 object systems right out
of CL, it's just CLOS reinvented poorly (so have to add some bugs to
get the proper mapping, but sigh, you get the point).

So yes, I've got lots of thoughts on this, but I'm not nearly a good
enough lisp programmer to make enough progress on what I want to do,
and I need to get a few working pieces before heading back to
integration.

And BTW, I am working to see about using GSLL as a feasible backend
for the lisp-matrix stuff, as you've done a fine job on the overall
system development and internals, as well as for some of the other
numerical stuff -- however, it would be great to have a robust and
consistent front end to many different numerical libraries for testing
numerical stability and comparability.

All this just to be able to wrap a sensible statistical DSL directly
on top of CL, keeping all of CL around, so that I can once and for all
forget about R's annoying syntax burps.

(I do like R, having been responsible for many user-level innovations
and demonstrations with it, but it truly sucks as a platform for
statistical computing research; it's great for just "computing
statistical stuff").

Let me know if there is anything I can do to help out (I don't have
much time, but it'll help me in the long run).

best,
-tony

blindglobe at gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee:  Do stupid things faster with more energy!




More information about the gsll-devel mailing list