Guile-PG 0.91 - what am I doing wrong?

Guile-PG 0.91 - what am I doing wrong?

[Chris Hall]

[-- Attachment #1.1: Type: text/plain, Size: 3318 bytes --]

I've downloaded built and installed Guile-PG 0.19, but I can't seem to
get it working.

Debian Woody, kernel 2.4.18bf,  GCC 3.0.4, GNU make 3.79.1.

Guile 1.6.4 obtained from Savannah and built using GCC 3.0.4.  Guile
installed into /usr/local.

Postgres 7.3.4 obtained from postgresql.org and built 3 days ago.

Configured guile-pg with ./configure --with-pg=/usr/local/pgsql.

The build went OK, and the install _seemed_ to - turns out (after a
couple of hours of reading manuals, poking around in the system, etc.)
that 'make install' put the libs in '/site' *not*
/usr/local/lib/guile/site, and the scripts in /database *not* in
/usr/local/share/guile/site.

OK, fine, let's move them to where they should have been, and update my
GUILE_LOAD_PATH to point to /usr/local/share/guile/site, my
LTDL_LIBRARY_PATH and LD_LIBRARY_PATH to
"/usr/local/pgsql/lib:/usr/local/lib/guile/site".  (I also tried with
"/usr/local/lib/guile/site/database" with the same dismal results).

(use-modules (database postgres)) complains; postgres.scm barfs with 'no
code for (database postgres-sup)'.

Sure enough, no postgres-sup.scm anywhere on the system - not even in
the tarball - though there *are* the postgres-sup* libs in
/usr/local/lib/guile/site/database.  I guess this is where they should
be, but at this point, I have absolutely no confidence in that. :-}

Also, I spent quite some time in the guile reference info - I'm guessing
that postgres-sup.scm, if it exists somewhere, is where 'load-extension'
gets called?

I'm new to guile, but isn't 'load-extension' *required* to load a
dynamic library?  I did a grep, and no load-extension was found anywhere
in database/.

So, what obvious, stupid mistake have I made, or what glaringly obvious
thing am I overlooking?  Has anybody gotten this working?

I had tried guile-pg-0.17 (or was it 0.18?) a few days ago, and it
wouldn't compile, using the exact same setup.

FWIW, I recently built clisp 2.33 against the same Postgres build, and
the clisp postgres support worked flawlessly.  The default Debian
guile-pg (for guile version 1.4) worked fine too, but I wanted to
upgrade to guile1.6, and the Debian testing package would require me to
upgrade my glibc - a bit much for me to risk this point, since I am
getting ready to move and I can't afford to have my computer borked.

Should I go back to guile1.4?  I'm kinda busy and can't really afford to
spend a lot more time on this, but if I am almost there I'd hate to
waste the time I've already spent, though it has been educational.

Thanks for any suggestions,
+Chris

P.S.  On Debian, guile1.4-pg is separate executable, but for 1.6 has
anyone considered having 'make' generate a shell script with the
appropriate path statments already in the environment?

P.P.S I've also tried to build guile-pgsql, but it complains about not
finding 'c2x' - what on earth is *that* and where do I get it?  My
guile1.6.4 has nothing of the sort, and it is not mentioned in the
reference, but if it helps me get connected to postgres, I'll use it.

I just want to get at postgres from guile, I'm not too fussy about what
tool I use - is there one *known* to work with 1.6.4 that I don't have
to spend two days mucking about with in order to get working?

-- 
If you speak the truth, have a foot in the stirrup.
-- Turkish proverb


[-- Attachment #1.2: Type: application/pgp-signature, Size: 231 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile-PG 0.91 - what am I doing wrong?

[Greg Troxel]

  The build went OK, and the install _seemed_ to - turns out (after a
  couple of hours of reading manuals, poking around in the system, etc.)
  that 'make install' put the libs in '/site' *not*
  /usr/local/lib/guile/site, and the scripts in /database *not* in
  /usr/local/share/guile/site.

Try 'make check' in the build dir.

  OK, fine, let's move them to where they should have been, and update my
  GUILE_LOAD_PATH to point to /usr/local/share/guile/site, my
  LTDL_LIBRARY_PATH and LD_LIBRARY_PATH to
  "/usr/local/pgsql/lib:/usr/local/lib/guile/site".  (I also tried with
  "/usr/local/lib/guile/site/database" with the same dismal results).

Looking at auto* stuff, it seems the install is trying to put bits in
sensible places but ending up with bad paths, I think because it is
using a ttn-1.4 added config feature.  I got the same problems as you
with 0.19.

I just tried 0.16 again, and had to add -R/usr/pkg/lib to
config.status's pq lib line to get rpath in the libpostgres.so
installed by guile-pg.  I also has to add (current-module) to the eval
in the lo check script.  Then 'make check' worked.

This is with guile 1.6.4 on NetBSD currentish with pg 7.3.4.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile-PG 0.91 - what am I doing wrong?

[Chris Hall]

[-- Attachment #1.1: Type: text/plain, Size: 1283 bytes --]

Greg Troxel <gdt@ir.bbn.com> writes:
>
> I just tried 0.16 again, and had to add -R/usr/pkg/lib to
> config.status's pq lib line to get rpath in the libpostgres.so
> installed by guile-pg.  I also has to add (current-module) to the eval

Thank you, thank you, thank you!

I grabbed a copy of 0.16, and your '-rpath' hint seems to do the trick.
However, what I did was eyeball the Makefile after running configure,
and put (I hoped) appropriate -rpaths wherever (it seemed) appropriate.

I haven't bothered with the tests just yet - so I haven't tried
'(current-module)' yet - but I plan to, out of curiosity, if nothing
else. ;-) (Seriously, I do need to run the tests before I can even
consider using this in production.)

For now, though, I can at long, long last connect to and query my
postgres server from Guile1.6.4. - I've tried it.  Woohoooo! :-D

Too, I had to clean up the broken 0.19 install by hand - I had moved the
mis-placed directories, so 'make uninstall' didn't work properly in the
0.19 build.  That slowed me down for a while, because the old stuff,
being earlier in the default %load-path, kept loading and baffling
me. ;-}

Thanks again, (and whew!),
+Chris

-- 
We hang the petty thieves and appoint the great ones to public office.
-- Aesop (620 BC - 560 BC)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 231 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile-PG 0.91 - what am I doing wrong?

[Chris Hall]

[-- Attachment #1.1: Type: text/plain, Size: 210 bytes --]

FTR, the tests worked.
+Chris

-- 
In the USSR, the State owned industry, and corrupted its house to
death.
In the US, industry owns the State, and is corrupting its house to
death.
-- fnj (64210) on Slashdot


[-- Attachment #1.2: Type: application/pgp-signature, Size: 231 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile-PG 0.91 - what am I doing wrong?

[Chris Hall]

Hmmm.  I just installed guile-pg-0.17 on teo BSD boxes, and all I had to
do was change line 43 in share/guile/database/postgres.scm

     (format #f "~A/guile-pg/0.16/libpostgres.so" "/home/cjh/lib")
;;             (assq-ref %guile-build-info 'libdir))

"/home/cjh/lib" is where guile/0.16/libpostgres.so etc. were installed.

Didn't have to do any of that other stuff we did before!

Once I exported GUILE_LOAD_PATH=/home/cjh/share/guile,
(use-modules (database postgres)) worked just fine.

Woot!

-- 
America's one of the finest countries anyone ever stole.
-- Bobcat Goldthwaite




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile-PG 0.91 - what am I doing wrong?

[Thien-Thi Nguyen]

   From: Chris Hall <hall.cj@verizon.net>
   Date: Thu, 03 Jun 2004 03:06:09 -1000

   Debian Woody, kernel 2.4.18bf,  GCC 3.0.4, GNU make 3.79.1.

   Guile 1.6.4 obtained from Savannah and built using GCC 3.0.4.  Guile
   installed into /usr/local.

if you're installing guile anyway, you might as well try 1.4.1.98,
with which guile-pg 0.19 was tested, available in directory:

  http://www.glug.org/alt/

(works for me under debian woody w/ gcc 2.95.4.)  you can use the
configure option `--prefix /tmp/eval-local' if unsure.  after
installation, add /tmp/eval-local/bin to the head of PATH and try
"make installcheck".

if all goes well, keep PATH=/tmp/eval-local/bin:....  and install
guile-pg with the same prefix.  other packages that have been tested
with guile 1.4.1.98 are listed in file:

  http://www.glug.org/alt/guile-1.4.1.98.TESTED

(btw, thanks for motivating me to write that file.)  you can browse
installed modules that are either part of guile 1.4.1.98 or work with
guile 1.4.1.98 by visiting:

  http://www.muppetslab.org:8001/

if all does NOT go well, you can do "rm -rf /tmp/eval-local".  there is
a convenient script for guile-sdl that outlines the basic eval process:

  http://www.glug.org/people/ttn/software/guile-sdl/QUICK-START

alternatively, if you can provide patches for guile-pg to make it work
w/ guile 1.6.x w/o breaking builds using guile 1.4.x, i will be happy to
look them over and give you feedback.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile-PG 0.91 - what am I doing wrong?

[Chris Hall]

[-- Attachment #1.1: Type: text/plain, Size: 6877 bytes --]

On Sun, Jun 06, 2004 at 05:21:06AM +0200, Thien-Thi Nguyen wrote:
> 
> if you're installing guile anyway, you might as well try 1.4.1.98,
> with which guile-pg 0.19 was tested, available in directory:
> 
>   http://www.glug.org/alt/

Thanks, I was wondering where this was!


> (works for me under debian woody w/ gcc 2.95.4.)  you can use the
>

I've got both gcc 2.95.4 and 3.0.4 on debian woody, so this is good to
know.


>   http://www.glug.org/alt/guile-1.4.1.98.TESTED
>

Again, very good information to have.


> 
>   http://www.muppetslab.org:8001/

That's an impressive amount of software!


> alternatively, if you can provide patches for guile-pg to make it work
> w/ guile 1.6.x w/o breaking builds using guile 1.4.x, i will be happy to
> look them over and give you feedback.
> 
> thi

Cool - as soon as I get settled (I'm moving soon) I'll look into doing
just that.

I'm new to guile and and the guile newsgroup, and I really appreciate
your taking the time to respond.

I imagine you get asked this a lot, and I'll understand if you are
hesitant to answer (Eeek! A flame war!), but may I ask what reason(s)
led to you taking on the immense effort of maintaining a separate Guile
distribution?

If you'd like, we can take this off-list, and I'll promise to keep
anything you tell me confidential (I also realize what a leap of faith
that would be on your part!).

I've downloaded and unpacked the distribution and looked at the README,
docs/, etc., but couldn't find any explanation - perhaps I missed it?  I
also couldn't seem to find anything on your web site.

I've been developing software professionally for a long time (a few
years longer than you, going by your web page), so I have some idea what
is involved in an undertaking such as yours.  Personally speaking, it
would have to be a *seriously* major issue - something like the original
maintainers stopping work on the project, or the entire purpose/basis of
the project changed, or something like that, and I had clients whose
businesses depended on the software and its features.

I've asked a few people on the list, and my sense is that everyone is
highly appreciative of your upgrading and maintaining so many guile
extensions, a bit awed by how productive you seem to be, and generally
feeling miserable about the whole situation.  In short, they seem to
love Guile, respect you and speak well of you, but they really wish
there was only one version of Guile.

And no one seems to really know much about or understand *why* there
are two somewhat incompatible versions of Guile, other than that there
was some sort of falling out.

The most detailed explanation I've received so far mentioned rather
tentatively something about 'bound?' and C-only modules.  Based on my
research there seem to exist fairly reasonable, straightforward
work-arounds for these - I saw a procedure for searching the
environment's symbol table on comp.lang.scheme just last night,
<r7tsb05sgas23epfm0jn61j3tcckrehkik@4ax.com>, and surely
'load-extension' isn't all _that_ much bother.

So, speaking as a newbie, and for potential other newbies, how is one
supposed to go about choosing which version to use?  Realistically,
what information do we have to base our decision on?

One the one hand, we see the 'official' Guile 1.6.4, backed by the
FSF/GNU Project, and presumably blessed by RMS - who after all, got
the whole Guile effort rolling 'in the beginning'. ;-)

On the other hand, we see the self-described 'dissident Guile
hackers', http://www.glug.org/alt/, hinting at some sort of censorship
as being the reason behind the 'dissident' version 1.4.1 - and no
further information at all, at least that I have been able to find so
far.  Nary a mention that I could find on the FSF site, either.

The consequence being that we newbies cannot easily (if at all)
determine how the two versions differ, or why, and thus cannot
possibly be expected to be able to make an informed choice between the
two distributions.

As a consultant, when I am faced with situations of this sort I
usually recommend the more 'reputable' vendor, all other things being
equal.  In this case, that would almost _have_ to be the FSF.  Nothing
personal - you have been responsive to me, you are demonstrably very
dedicated to Guile, and pretty obviously feel strongly about it and
are committed to furthering its usefulness and 'audience'.  But I
think most clients would probably settle on FSF Guile as the 'better
bet', unless they had other information available to them - e.g.,
distinguishing (and compelling?) technical differences, performance or
reliablity improvements, etc.

The truly awkward bit, from both a client's perspective and a
user/programmer's (my own) point of view, is that by far the 'lion's
share' of active development, at least in the extension arena, is done
by the 'dissident' movement, incompatibilities are becoming increasingly
troublesome, and thus the need to choose is becoming more important,
more painful and more difficult.

So I really appreciate your willingness to consider patches that would
allow the distributions to continue 'sharing' extensions.

To my mind, though, this strategy seems far from optimal for either of
the parties involved - and even as a newbie I seem to sense that the
time of uneasy coexistence is nearing its end as the differences between
the distributions increase.

Scheme is Scheme is Scheme, and there are many implementations that
can more or less share code - Scheme seems better, in this respect,
than Lisp, though I don't really know.

Guile is simply an implementation of Scheme specialized and optimized
for use as an extension language, so perhaps there is a middle ground we
could find here, so that we can continue to share extensions?  I.e.,
could differences be isolated to specific modules/locations/idioms and
thus allow a generalized build mechanism for the extensions so that
build adapts to the host version of Guile?  Of course, the respective
camps would be responsible for supplying and testing the respective
build steps.

If something along these lines were possible, multiple benefits would
accrue:

 * your work with extensions would be useful to many more people,

 * other people could write extensions usable by either Guile version,

 * confusion as to what runs where would be considerably reduced,

 * people could select the Guile version most appropriate to their
   applications' requirements,

 * _all_ of us could feel better about things! :-D

At the very least, could the information as to how and why the
different Guile versions differ be made generally available?

Thanks again, and Aloha!,
+Chris

__
No single drop of water thinks it is responsible for the flood.
-- Old adage

-- 
Don't you wish there were a knob on the TV to turn up the
intelligence? There's one marked 'Brightness,' but it doesn't work.
-- Gallagher


[-- Attachment #1.2: Type: application/pgp-signature, Size: 231 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user