From: Jonathon McKitrick
Subject: Problem with CLSQL on Mac
Date: 
Message-ID: <1149820770.802971.307070@y43g2000cwc.googlegroups.com>
I finally got a working installation of postgresql and I'm trying to
get CLSQL to work with it.

It's currently not finding 'postgresql-loader' or any of the libraries
it needs.

The version of the libraries in /sw/lib have a suffix attached to them,
like 'libpq.4.dylib.'

I'm new to Mac OS X but I have it running on Linux.

From: billc
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <1149826610.661860.306260@g10g2000cwb.googlegroups.com>
Jonathon McKitrick wrote:
> I finally got a working installation of postgresql and I'm trying to
> get CLSQL to work with it.
>
> It's currently not finding 'postgresql-loader' or any of the libraries
> it needs.
>
> The version of the libraries in /sw/lib have a suffix attached to them,
> like 'libpq.4.dylib.'
>
> I'm new to Mac OS X but I have it running on Linux.

Did you try what I suggested when you posted this very same question a
week ago?
http://groups.google.com/group/comp.lang.lisp/msg/fe5813a8b77c27db

You didn't reply to my post or to the other person who responded to you
then.

- Bill
From: Jonathon McKitrick
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <1149853379.237389.52160@h76g2000cwa.googlegroups.com>
billc wrote:
> Did you try what I suggested when you posted this very same question a
> week ago?
> http://groups.google.com/group/comp.lang.lisp/msg/fe5813a8b77c27db
>
> You didn't reply to my post or to the other person who responded to you
> then.

I've been fighting with Postgresql on various levels for a week or so.
Everything from shared memory limits, missing 'postgres' database and
non-functioning spinlocks to CLSQL not being able to find the pg
library.  I'm so frustrated at this point I'm not even sure where to
start installing: plain vanilla source build, druware's mac osx disk
image, fink's version, or something else altogether.

Last night I tried adding the '/sw/lib' path to clsql library paths
(that long variable from Edi's site) and still had no success.
From: billc
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <1149874053.122618.70570@f6g2000cwb.googlegroups.com>
Jonathon McKitrick wrote:
> billc wrote:
> > Did you try what I suggested when you posted this very same question a
> > week ago?
> > http://groups.google.com/group/comp.lang.lisp/msg/fe5813a8b77c27db
> >
> > You didn't reply to my post or to the other person who responded to you
> > then.
>
> I've been fighting with Postgresql on various levels for a week or so.
> Everything from shared memory limits, missing 'postgres' database and
> non-functioning spinlocks to CLSQL not being able to find the pg
> library.  I'm so frustrated at this point I'm not even sure where to
> start installing: plain vanilla source build, druware's mac osx disk
> image, fink's version, or something else altogether.
>
> Last night I tried adding the '/sw/lib' path to clsql library paths
> (that long variable from Edi's site) and still had no success.

I succeeded with Mac OS X (PPC), following the steps outlined in my
blog post which I referenced in my previous reply. Basically, I did the
following:

1. Installed standard Postgres (not the Fink one as you did) using the
instructions on the Apple site at:
http://developer.apple.com/internet/opensource/postgres.html
2. Installed CLSQL and the necessary pre-reqs.
3. Stuck the following chunk of code in my lisp init file:
#+clsql
(defmethod asdf:perform :after ((o asdf:load-op)
				(c (eql (asdf:find-system 'clsql))))
  (funcall (find-symbol (symbol-name '#:push-library-path)
			(find-package 'clsql))
	   #p"/usr/local/pgsql/lib/"))
4. Started up lisp, did the usual asdf load stuff and everything was
hunky-dory

Since you indicated that you are using an Intel-based Mac, there may be
some issues that you're encountering that I didn't. However, the above
worked for me. Perhaps if you try the above and report on what
(specifically) isn't working for you, you'll get more (or better)
advice. Also, you are more likely to get good advice if you post on the
CLSQL-Help mailing list(http://lists.b9.com/pipermail/clsql-help/).
Looking at the archives for May, I don't see any posts from you and
that is really your best source for help on CLSQL problems.

--
Bill Clementson
From: Jonathon McKitrick
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <1149882294.919996.168950@g10g2000cwb.googlegroups.com>
billc wrote:
> #+clsql
> (defmethod asdf:perform :after ((o asdf:load-op)
> 				(c (eql (asdf:find-system 'clsql))))
>   (funcall (find-symbol (symbol-name '#:push-library-path)
> 			(find-package 'clsql))
> 	   #p"/usr/local/pgsql/lib/"))

I got up to this point and started having trouble, though I was able to
get postgresql installed and running.

The above script as well as directly pushing my path onto the
foreign-libraries-path special did not work, unless I did it after
breaking into the debugger.

I'll try the mailing list as well.
From: Jonathon McKitrick
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <1149882381.211801.177880@g10g2000cwb.googlegroups.com>
billc wrote:
> #+clsql
> (defmethod asdf:perform :after ((o asdf:load-op)
> 				(c (eql (asdf:find-system 'clsql))))
>   (funcall (find-symbol (symbol-name '#:push-library-path)
> 			(find-package 'clsql))
> 	   #p"/usr/local/pgsql/lib/"))

I got up to this point and started having trouble, though I was able to
get postgresql installed and running.

The above script as well as directly pushing my path onto the
foreign-libraries-path special did not work, unless I did it after
breaking into the debugger.

I'll try the mailing list as well.
From: Anon
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <FI2dnc9-YL3FhxfZnZ2dnUVZ_v2dnZ2d@comcast.com>
"Jonathon McKitrick" <···········@bigfoot.com> wrote in 
·····························@y43g2000cwc.googlegroups.com:

> I finally got a working installation of postgresql and I'm trying to
> get CLSQL to work with it.
> 
> It's currently not finding 'postgresql-loader' or any of the libraries
> it needs.
> 
> The version of the libraries in /sw/lib have a suffix attached to them,
> like 'libpq.4.dylib.'
> 
> I'm new to Mac OS X but I have it running on Linux.
> 

IIRC, the way I have it in my FreeBSD box is either

export LD_LIBRARY_PATH=path-to-lib:$LD_LIBRARY_PATH

or

add path-to-lib  to /etc/ld.so.conf  and do an ldconfig

under FreeBSD path-to-lib is /usr/local/lib
under Linux is /usr/lib
in your case /sw/lib

You can also create a link to, for example to libpq.4.dylib, if the 
program
is looking for libpq.so as:

ln -s /sw/lib/libpq.4.dylib /sw/lib/libpq.so

which creates a link libpq.so --> libpq.4.dylib if it doesn't exist.

Also, for CLSQL I have this in the start file before loading
clsql-postgres:

(clsql:push-library-path "path-to-where-i-have-uffi")

because somehow it complains that it cannot find uffi.so
even though all the paths for asdf are all there.

You might want to work with these values and see if it
works for you.




 
From: Rob Warnock
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <lMGdncUv78oTghfZnZ2dnUVZ_rednZ2d@speakeasy.net>
Jonathon McKitrick <···········@bigfoot.com> wrote:
+---------------
| I finally got a working installation of postgresql and I'm trying to
| get CLSQL to work with it.
| It's currently not finding 'postgresql-loader' or any of the libraries
| it needs.
+---------------

Others have given you good suggestions, but just as another
data point and possible alternative...

I started using PostgreSQL with CMUCL about four years ago,
*not* with CLSQL, but using Eric Marsden's "PG" library
<http://www.cliki.net/Pg>:

    Pg is a socket-level interface to the PostgreSQL object-relational
    Database. The Library implements the client part of the
    frontend/backend protocol, so does not require interfacing with
    the "libpq" library. SQL types are converted to the equivalent
    Common Lisp types where possible. Supports large objects (BLOBs).

That is, it needs no FFI [other than whatever socket support your
Common Lisp has] or matching shared library versions, since it
speaks the PostgreSQL socket protocol directly.

I've been quite happy with it, and currently support several
(low-volume) web sites that use it behind a Lisp-based persistent
applications server.


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: billc
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <1149968452.673105.221690@u72g2000cwu.googlegroups.com>
Rob Warnock wrote:
> Jonathon McKitrick <···········@bigfoot.com> wrote:
> +---------------
> | I finally got a working installation of postgresql and I'm trying to
> | get CLSQL to work with it.
> | It's currently not finding 'postgresql-loader' or any of the libraries
> | it needs.
> +---------------
>
> Others have given you good suggestions, but just as another
> data point and possible alternative...
>
> I started using PostgreSQL with CMUCL about four years ago,
> *not* with CLSQL, but using Eric Marsden's "PG" library
> <http://www.cliki.net/Pg>:
>
>     Pg is a socket-level interface to the PostgreSQL object-relational
>     Database. The Library implements the client part of the
>     frontend/backend protocol, so does not require interfacing with
>     the "libpq" library. SQL types are converted to the equivalent
>     Common Lisp types where possible. Supports large objects (BLOBs).
>
> That is, it needs no FFI [other than whatever socket support your
> Common Lisp has] or matching shared library versions, since it
> speaks the PostgreSQL socket protocol directly.
>
> I've been quite happy with it, and currently support several
> (low-volume) web sites that use it behind a Lisp-based persistent
> applications server.

The alternative of using the socket protocol is a good point. This was
pointed out to me by Sven Van Caekenberghe and Francis Leboutte when I
first started trying to get CLSQL working with Postgres on a Mac.

You can also use the Postgres socket-level interface with CLSQL,
bypassing the need to use the native-level libraries. It should be
noted that UFFI is still needed even if you use the socket interface
(apparently only because functions in the clsql-postgresql-socket
system use some UFFI functions). But no need for the C libraries: "The
PostgreSQL Socket back-end needs no access to the PostgreSQL C client
library, since it communicates directly with the PostgreSQL server
using the published frontend/backend protocol, version 2.0. This eases
installation and makes it possible to dump CMU CL images  containing
CLSQL and this backend, contrary to backends which require FFI code."

--
Bill Clementson
From: Jonathon McKitrick
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <1149971602.134836.80880@g10g2000cwb.googlegroups.com>
billc wrote:
> You can also use the Postgres socket-level interface with CLSQL,
> bypassing the need to use the native-level libraries. It should be

This was *so* much easier and painless, I might go as far as rolling
the change into production.  If the socket is there for the postmaster
anyway, why not use it?
From: Rob Warnock
Subject: Re: Problem with CLSQL on Mac
Date: 
Message-ID: <k-6dnUZZMf6RdBHZnZ2dnUVZ_vadnZ2d@speakeasy.net>
billc <········@gmail.com> wrote:
+---------------
| Rob Warnock wrote:
| > I started using PostgreSQL with CMUCL about four years ago,
| > *not* with CLSQL, but using Eric Marsden's "PG" library...
| > [which] speaks the PostgreSQL socket protocol directly.
...
| You can also use the Postgres socket-level interface with CLSQL,
| bypassing the need to use the native-level libraries.
+---------------

Good to know, thanks!

Note that there were other reasons I used PG rather than CLSQL, the
main one being that neither the "functional" nor the "object-oriented"
interfaces provided in CLSQL seemed to match very well the needs of
the first big app I had to write, which required that *both* the
columns to SELECT *and* the match (WHERE) criteria had to be computed
at run-time[1] from data the user had input from an HTML form. That
is, the CLSQL:LOCALLY-ENABLE-SQL-READER-SYNTAX was useless unless I
wanted to build up a string and (EVAL (READ-FROM-STRING string)),
and if I wanted to do *that* I might as well just pass the equivalent
string directly to PostgreSQL [which is what I did]. Likewise, since
a majority of queries only needed a few of the *many* columns of each
table, the object-oriented interface would have resulted in much
unneeded data being read from the database into "objects", only
to be ignored (also putting more pressure on GC).

Had I been writing an app that modelled "business processes" with
queries known at compile time, I suspect the tradeoffs would have
been more favorable to CLSQL.


-Rob

[1] The LET* whose result is the desired query string is 45(!) lines
    of CL, finally ending with the following grotesque binding [in my
    defense, this was the first significant CL app I'd ever written]:

	(query (apply #'concatenate 'string
		      "SELECT "
		      (when editing-p "seq, vseq, ")
		      (when (eq query-use-type :comment)
			"coalesce(count(user_id),'0') AS \"items\", ")
		      adjusted-selections
		      " FROM contact_log"
		      (when (eq query-use-type :comment)
			" LEFT OUTER JOIN comments ON seq = user_id ")
		      " WHERE vact AND "
		      (if (eq query-use-type :comment)
			(append predicates
				(list " GROUP BY seq, vseq, "
				      adjusted-selections
				      " ORDER BY last, first"))
			predicates)))

    Only if the client user checked the "View Comments" button is
    the JOIN needed, but in that case we also need the "GROUP BY"
    since the "comments" table is a 1:N relation, and all we want
    here is the count of the number of comments about each "user_id".
    But that in turn requires that the "adjusted-selections" get
    merged into the "GROUP BY". *Blettch!*

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607