Re: I get unknown immediate error in guile 1.7

Re: I get unknown immediate error in guile 1.7

[Roland Orre]

I found the problem. It seems as linking (at least for me) is not done
in the right way for modules, neither for 1.6 or 1.7. Explanation below.

On Thu, 2004-01-08 at 08:11, Roland Orre wrote:
> I've tried to get guile 1.7 work but I seem to have a problem with
> loadable modules. As soon as I call a function in them I get an
> "unknown-immediate" error. This possibly sounds like some include
> problem but as far as I know tag principles has not changed between
> 1.6 and 1.7.
> 
> The most basic is readline of course as I haven't recompiled other
> modules yet. About readline, the file "libtool" was not created by
> autogen.sh in guile-readline so I linked to ../libtool instead.
> 
> If I load an old (1.6) libguilereadline I get segmentation fault, which
> indicates some significant change. When I load the 1.7 libguilereadline
> I get the errors below after (activate-readline), any ideas?
> I've used gcc 3.3.2.

The problem showed to be that guile loaded wrong libraries, which was
caused by the the correct library files not having been created. Guile
had been reading wrong libguilereadline.la all the time. I noticed this
when I deinstalled the (debian distributed) guile-1.6. Then the
libguilereadline.la library was not found for my locally compiled
guile-1.6 either, despite that I had included both
/usr/local/guile/guile-1.6.0/lib
/usr/local/guile/guile-1.6.0/guile-readline in the LTDL_LIBRARY_PATH.

I then relinked the readline.o file under guile-readline with
the settings I use for my own modules, then it worked. The make
script is at the end. The correct guile-1.6 libguilereadline
file was read and the same procedure worked for guile-1.7 as well.
The problem probably has to do with the guile-readline autogen.sh
but how this script works is above my head.

The fundamental problem seems to be that the installation linking
is not done in the right way. None of the .la files under the
lib directory (${exec_prefix}/lib) contains any library references.
Observe that I used the name "libgreadline" in the script.

Here are the error messages given.
After a normal make install, where LTDL library is set as:
export LTDL_LIBRARY_PATH=/usr/local/guile/guile-1.7/lib

I get the following (empty) error message:
  /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
  In procedure dynamic-link in expression 
  (load-extension "libguilereadline" "scm_init_readline"):
  /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
  file: "libguilereadline", message: ""

If I then also include /usr/local/guile/guile-1.7/guile-readline
first in the LTDL path, then I get the following error message:
 /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
 In procedure dynamic-link in expression
 (load-extension "libguilereadline" "scm_init_readline"):
 /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
 file: "libguilereadline", message: "|o\"@àÌ\x11\x08readline.a:
 cannot open shared object file: No such file or directory"

If I then run the make script below under guile-readline then
it works. This newly created .la files contains library references
to the .so files created under .libs. 
I also included my configuration parameters below.

Have I done anything obviously wrong in the configuration?

=============================================================
# This make file generates a working libguilereadline

top_builddir = /usr/local/guile/guile-1.6.0
libdir=/usr/local/guile/guile-latest/guile-readline/..//lib
LIBS=../libguile/libguile.la -lreadline -lncurses
EXTRA=-version-info 10:0:0 -export-dynamic -no-undefined
CC=gcc

all: libgreadline

libgreadline: readline.o
	sh ${top_builddir}/libtool --mode=link $(CC) $^ $(EXTRA) $(LIBS) \
-rpath $(libdir) -o libgreadline.la

=============================================================

#These are my configuration parameters:

GUILEROOT=`pwd`
echo ${GUILEROOT}

./configure --with-threads --with-readline \
 --prefix=${GUILEROOT}                  \
 --build=i686                           \
 --exec-prefix=${GUILEROOT}             \
 --bindir=${GUILEROOT}/bin              \
 --sbindir=${GUILEROOT}/bin             \
 --sysconfdir=${GUILEROOT}/etc          \
 --datadir=${GUILEROOT}                 \
 --sharedstatedir=${GUILEROOT}/com      \
 --localstatedir=${GUILEROOT}/var       \
 --includedir=${GUILEROOT}/include      \
 --oldincludedir=/usr/include           \
 --mandir=/usr/local/man                \
 --infodir=/usr/local/info              \
 --enable-maintainer-mode               \
 --enable-ltdl-install




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

Re: I get unknown immediate error in guile 1.7

[Roland Orre]

Sorry all, the problem was my fault. I had given to many (and obviously
some erroneous) parameters to configure. When I gave only a few
necessary parameters it worked very well, all module .so files were
created.
	Best regards
	Roland


On Fri, 2004-01-09 at 00:16, Roland Orre wrote:
> I found the problem. It seems as linking (at least for me) is not done
> in the right way for modules, neither for 1.6 or 1.7. Explanation below.
<snip>
> =============================================================
> 
> #These are my configuration parameters:
> 
> GUILEROOT=`pwd`
> echo ${GUILEROOT}
> 
> ./configure --with-threads --with-readline \
>  --prefix=${GUILEROOT}                  \
>  --build=i686                           \
>  --exec-prefix=${GUILEROOT}             \
>  --bindir=${GUILEROOT}/bin              \
>  --sbindir=${GUILEROOT}/bin             \
>  --sysconfdir=${GUILEROOT}/etc          \
>  --datadir=${GUILEROOT}                 \
>  --sharedstatedir=${GUILEROOT}/com      \
>  --localstatedir=${GUILEROOT}/var       \
>  --includedir=${GUILEROOT}/include      \
>  --oldincludedir=/usr/include           \
>  --mandir=/usr/local/man                \
>  --infodir=/usr/local/info              \
>  --enable-maintainer-mode               \
>  --enable-ltdl-install




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

Re: First look at Guile Std Library available

[Richard Todd]

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

On Sun, Jan 04, 2004 at 02:49:01AM +0100, Thien-Thi Nguyen wrote:
> i like the idea of providing a framework, but caution you against
> getting stuck on the implementation details.  for slib (for example), if
> the bridging is as easy as another poster has intimated, why preclude
> that from your plans? 

I'm not precluding it--but I'm trying to think through other options,
since I think the coherence of the whole library would suffer.  Maybe
not as much as I worry, but it would have to.  Let's say we take in a
logging framework, and then find some other code that does syslogging.
What are our options:

  1) We could include that code too.  So now there are two logging
mechanisms in the library.  With potentially very different styles of
interfaces, and different naming conventions.  In one all functions
are log:xxx and log:yyy, but in the other all the function names are
write-syslog.

  2) We could make the needed modifications to fit the new syslogging
behavior into the logging framework (leading to bit-rot if the
syslogger is updated and I don't take those changes right away).

The situation can be even more complicated, like if both allow you to
filter the logs by regexp, but use two different regexp libraries with
different capabilities.  Now there's another decision point.

Another example would be slib minimize.scm, which has one method for
minimization in it.  If I find another lib with four more methods in
it, should I combine them into a single, coherent module, or leave two
modules out there (possibly with contrived names so that they are
different)--one with one function and one with four?  Or wrap them in
a third module that re-exports all the methods, and attempt to keep
the two 'base' madules private?

This type of problem will show up time and again.  I have been leaning
towards the option that produces the most coherent product so far, but
like all complicated decisions, there are downsides to it.  


Another option for the project would be to actively avoid things
that are already in SLIB, Guile-core, or wherever else, and just 'fill
in the gaps.'  I'm having trouble taking that road, because it's
asking users to look 5 places for everything they think might be
available, and deal with all the variations and overlap inherent in
it.  And, though people may get tired of me waving the python standard
around, you just don't have this problem with other languages.  Sure,
there are lots of independent libraries out there, but the basics are
covered 'out of the box'.

And this is exactly the kind of discussion I'd like to have and
resolve before I put too much effort into this.  I'd like everyone to
be happy with the outcome, and contribute to a successful project.


> btw, i consider "generic library" high (and deserved) praise for slib.

I'm not knocking it for being generic--I'm saying no major scheme
implementation that I know of just points you to SLIB..  they all have
libraries of their own.


> (define-module (net email sendmail)
>   #:use-module (ttn parse-rfc822)            ; for auto-reply
>   #:use-module (j-r-hacker mail-utils)       ; for compose-mail
>   ...)
> 
> (define (auto-reply ...) ...)
> (define (compose-mail ...) ...)
> 
> and so on.  it could be that people are doing this already, but more
> locally than not (and w/ little fanfare or further distribution).  who
> knows?  who cares?

I care, because building an infrastructure that others can build on is
an important part of making guile useful in the real world.  If lots
of people are out there quietly cobbling together email packages out
of fragments of people's pet projects, then we are not acting in a
very efficient manner.

Richard Todd
richardt at vzavenue dot net

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

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

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

Re: First look at Guile Std Library available

[Thien-Thi Nguyen]

   From: Richard Todd <richardt@vzavenue.net>
   Date: Sat, 3 Jan 2004 21:50:22 -0600

   I'm trying to think through other options,
   since I think the coherence of the whole library would suffer.

from lurking on the emacs-devel mailing list, i've come to understand
the word "coherence" in an application context (app == emacs) to be
definition 1b from webster's[1], the operative word being "integration".
in a library context, what kind of integration are we talking about?  if
integration is actually not what you mean, could you explain how would
"coherence of the whole library" be measured?

   1) We could include that code too.  [...]
   2) We could make the needed modifications [...]

   The situation can be even more complicated, like if both allow you to
   filter the logs by regexp, but use two different regexp libraries with
   different capabilities.

here are two decisions you can make early on:

(a)
what is the policy re proliferation of work-alike (but not exactly
identical) interfaces?  one-size-fits-all vs pluralistic-menu.  for
the latter, you would probably want to specify "adapter" modules to
reduce interface complexity from NxM to N+M.  for the former, the
proliferation problem is defined away but the immediate usefulness of
the library is reduced for some users, who would be forced to do the
adaptation outside the library (probably in isolation, without
further distribution) -- same boat as the *-pers-scheme approach,
basically.

(b)
what is the policy for changing an interface wrt backwards
compatibility?  if you allow backward-incompatible changes, users
will learn to not trust the library (or at least allocate trust to
those elements that have changed in this way very begrudgingly).  if
you disallow backward-incompatible changes, you need to be supremely
careful when defining interfaces for one-size-fits-all approach,
slightly less careful for pluralistic-menu.

figure out (a) and (b) and a maintenance strategy will probably
present itself naturally.

   Another example would be slib minimize.scm [...]  Or wrap them in
   a third module that re-exports all the methods, and attempt to
   keep the two 'base' madules private?

perhaps figuring out the maintenance axioms can help answer this.
certainly, separating the design of the interface from that of the
implementation allows you some flexibility.

   Another option for the project would be to actively avoid things
   that are already in SLIB, Guile-core, or wherever else, and just
   'fill in the gaps.'  I'm having trouble taking that road, because
   it's asking users to look 5 places for everything they think might
   be available, and deal with all the variations and overlap
   inherent in it.  And, though people may get tired of me waving the
   python standard around, you just don't have this problem with
   other languages.  Sure, there are lots of independent libraries
   out there, but the basics are covered 'out of the box'.

i think it would be a mistake to willfully ignore what is out there,
but that doesn't mean you can't provide a valuable bundling service.
much depends on how you feel about not being the only such service.

   I care, because building an infrastructure that others can build
   on is an important part of making guile useful in the real world.
   If lots of people are out there quietly cobbling together email
   packages out of fragments of people's pet projects, then we are
   not acting in a very efficient manner.

IME as a "user" of programming languages, tools, and employees,
useful trumps standard trumps efficient.  in practice, efficiency is
such a fuzzy concept, it is often measured in terms of usefulness!

thi


______________________________
[1] M-x dict sez:
    Main Entry: co·her·ence # #
    Pronunciation: kO-'hir-&n(t)s, -'her-
    Function: noun
    Date: 1580
    1 : the quality or state of cohering : as a : systematic or
    logical connection or consistency b : integration of diverse
    elements, relationships, or values
    2 : the property of being coherent


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

Re: First look at Guile Std Library available

[Richard Todd]

(writing from my windows machine, so not set up to gpg sign it, but it's 
me I promise!)

Thien-Thi Nguyen wrote:
> here are two decisions you can make early on:
> 
> (a)
> what is the policy re proliferation of work-alike (but not exactly
> identical) interfaces?  one-size-fits-all vs pluralistic-menu.  for
> the latter, you would probably want to specify "adapter" modules to
> reduce interface complexity from NxM to N+M.  for the former, the
> proliferation problem is defined away but the immediate usefulness of
> the library is reduced for some users, who would be forced to do the
> adaptation outside the library (probably in isolation, without
> further distribution) -- same boat as the *-pers-scheme approach,
> basically.

I thought that's what I was trying to ask in my post, via the examples I 
gave.  I'm looking for input on what the community wants, and (more 
importantly) would help contribute to.  I don't want to go this alone, 
and in fact I think it would be ridiculous to generate a 'standard' 
library in isolation!

I don't follow why one-size-fits-all would reduce the immediate 
usefulness of the libarary for some users.  Are you are talking about a 
user who was already using an interface from another library that I 
incorporated and changed?  Compared to the benefit to new users who 
would not be faced with several disjoint interfaces, I think this is 
insignificant (especially since they can keep on using the old lib if 
they want).


> (b)
> what is the policy for changing an interface wrt backwards
> compatibility?  if you allow backward-incompatible changes, users
> will learn to not trust the library (or at least allocate trust to
> those elements that have changed in this way very begrudgingly).  if
> you disallow backward-incompatible changes, you need to be supremely
> careful when defining interfaces for one-size-fits-all approach,
> slightly less careful for pluralistic-menu.

I agree with Dale Mellor's response.  It's standard practice to stay 
compatible along minor version numbers, and OK to break backwards 
compatibility across major version numbers.  This code base should grow 
over time, and the ideal organization and interface to the modules will 
certainly shift, even if we do get it perfect in the first place (which 
we won't, of course).

What do you think of (std ...) => (std2 ...) as a means of letting older 
code run forever?  I've read c++ is considering this approach.  I don't 
think it should happen but every 5 years or so, and only then if 
backwards compatibility has become a burden.

As for 'supremely careful', this is why I have released work so early, 
and plan for all of us working on the project to do the same.  I want 
the time between now and June to be the period where people attempt to 
use and criticize what's out there.  Anything that is still 
controversial will be left out of the first release.

I'm a little disappointed that all the response I've gotten has been 
about the library concept, and no one has yet appeared to be interested 
in the code I've put out there to date.  Do you like it?  Hate it? 
Don't care about it?  Can it be that only Java/Python/Perl/Ruby need 
logging services, and scheme does not?


> > Another example would be slib minimize.scm [...]  Or wrap them in
> > a third module that re-exports all the methods, and attempt to
> > keep the two 'base' madules private?
 >
> perhaps figuring out the maintenance axioms can help answer this.
> certainly, separating the design of the interface from that of the
> implementation allows you some flexibility.

Again, yes, figuring that stuff out would help, and that's why I brought 
it up.  I'm looking for input.  Much of your post seems to be re-asking 
the same questions I was asking.

I can answer these questions on my own (and I think I mostly have done 
so by way of releasing code that has a certain slant to it), but I am 
trying to get a feel for what others think is best for guile.  I think 
we all at least agree that having _something_ is desireable.


> i think it would be a mistake to willfully ignore what is out there,
> but that doesn't mean you can't provide a valuable bundling service.
> much depends on how you feel about not being the only such service.

I am trying to start a project, but it's not about me, or being the only 
service.  It's a question of whether we want a bundle or a framework.

I have said, and do believe, that it would be good to have a single 
library that provides the baseline infrastructure for doing useful work. 
  Would everyone be satisfied if we grouped 6 packages and made sure 
they all 'configure && make install' properly, or do people want 
something more than that?  I was imagining they would want more, but now 
would be the best time to find out I'm wrong about that.

Where are the other such services, anyway?

>  > I care, because building an infrastructure that others can build
>  > on is an important part of making guile useful in the real world.
>  > If lots of people are out there quietly cobbling together email
>  > packages out of fragments of people's pet projects, then we are
>  > not acting in a very efficient manner.
> 
> IME as a "user" of programming languages, tools, and employees,
> useful trumps standard trumps efficient.  in practice, efficiency is
> such a fuzzy concept, it is often measured in terms of usefulness!

Regardless of which trumps which, what is 'useful', 'standard', *OR* 
'efficient' about what a guile user has today?  When I download the JDK 
I have a ton of 'useful', 'standard', *AND* 'efficient' components from 
which I can start useful work.  There is no comparison, even if you 
start with (+ guile ice-9 slib).

I've had a serious suggestion that I redirect this effort to SLIB, and 
I'm mulling that over.  I would have to make serious changes, since I've 
been freely using guile-specific code so far (such as goops classes). 
I'm also not thrilled with the way slib is organized, but there would be 
some benefits to going that way.  We could still produce a (use-modules) 
interface to the entire SLIB library, which I think makes sense in any 
case.  Any thoughts?

Richard Todd




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

Re: First look at Guile Std Library available

[Andreas Rottmann]

Richard Todd <richardt@vzavenue.net> writes:

>> (b)
>> what is the policy for changing an interface wrt backwards
>> compatibility?  if you allow backward-incompatible changes, users
>> will learn to not trust the library (or at least allocate trust to
>> those elements that have changed in this way very begrudgingly).  if
>> you disallow backward-incompatible changes, you need to be supremely
>> careful when defining interfaces for one-size-fits-all approach,
>> slightly less careful for pluralistic-menu.
>
> I agree with Dale Mellor's response.  It's standard practice to stay
> compatible along minor version numbers, and OK to break backwards
> compatibility across major version numbers.  This code base should
> grow over time, and the ideal organization and interface to the
> modules will certainly shift, even if we do get it perfect in the
> first place (which we won't, of course).
>
> What do you think of (std ...) => (std2 ...) as a means of letting
> older code run forever?  I've read c++ is considering this approach.
> I don't think it should happen but every 5 years or so, and only then
> if backwards compatibility has become a burden.
>
Hmm, I always kind of disliked that approach. 

1) It's probably very hard for a standard library (which presumably
   consists of lots of modules) to stay API-compatible over an
   longer period of time. Consider the GNOME project -- they have
   the concept of the "GNOME developer platform", which will, given a
   constant *minor* release number stay API compatible, but may (and
   mostly will) break API every minor release number change, which
   happens about every six months.

2) Presumed the need for API-breaking changes are needed, in turn not
   to hinder development of the library itself, in intervals quite
   smaller than 5 years, it would be more of a annoyance to developers
   regularly adapting to the API changes (which indeed should only be
   "major" in the sense that they require a lot of adaption to
   existing code accross major version changes) to require changing
   all their code to use stdY instead of stdX.

> I'm a little disappointed that all the response I've gotten has been
> about the library concept, and no one has yet appeared to be
> interested in the code I've put out there to date.  Do you like it?
> Hate it? Don't care about it?  Can it be that only
> Java/Python/Perl/Ruby need logging services, and scheme does not?
>
I just skimmed a bit over your code, and it seems quite OK. A few bits
I've noticed:

------- (logging logger) -----------

1)

,----
| (define (register-logger! str lgr)
|   (if (not (string? str))
|       (throw 'bad-type "Expected a string for the log registration"))      
|   (hash-set! all-loggers str lgr))
`----

Why not make GOOPS care for type-checking (given GOOPS is used)?


2) Have you considered the need for a "log domain" as in GLib? This
   can be useful e.g. for an application to dump most logs including
   all those generated by libraries into a file and present all logs
   messages from its own domain and above a certain level in a special
   way (e.g. message dialog).

Regards, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.


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

Re: First look at Guile Std Library available

[Richard Todd]

Andreas Rottmann wrote:
> Hmm, I always kind of disliked that approach. 
> 

<snip>

> 2) Presumed the need for API-breaking changes are needed, in turn not
>    to hinder development of the library itself, in intervals quite
>    smaller than 5 years, it would be more of a annoyance to developers
>    regularly adapting to the API changes (which indeed should only be
>    "major" in the sense that they require a lot of adaption to
>    existing code accross major version changes) to require changing
>    all their code to use stdY instead of stdX.

You could be right.  I was thinking along these lines:

There is a lot that can be done to preserve compatibility over a period 
of time, that essentially builds up cruft in the library.  Things like 
leaving the old function name _and_ the new function name in.  Things 
like moving the module _and_ leaving a module in the original location 
to load it, too.  Things like adding the second XML processing module 
but leaving the original one there too.

Then, (I was hoping only once every few years), you have to say 
"Enough!" and break with the past.

It could be that it's best to do something in-between, and let small 
incompatibilities in over time, and reserve std2 for a massive 
reorganization.  Some people do a "deprecate-for-1-major-release" 
strategy, after which deprecated things disappear.  That might be an 
option also.

> 1)
> 
> ,----
> | (define (register-logger! str lgr)
> |   (if (not (string? str))
> |       (throw 'bad-type "Expected a string for the log registration"))      
> |   (hash-set! all-loggers str lgr))
> `----
> 
> Why not make GOOPS care for type-checking (given GOOPS is used)?

Good question!  I'll do this.

> 2) Have you considered the need for a "log domain" as in GLib? This
>    can be useful e.g. for an application to dump most logs including
>    all those generated by libraries into a file and present all logs
>    messages from its own domain and above a certain level in a special
>    way (e.g. message dialog).
Not familiar with GLib, but if you mean that different parts of the 
program talk to different named 'domains', then that you should be able 
to get something similar with the register-logger! mechanism, right? 
You could log to as many named loggers as you want.  You can even assign 
the same handlers to different named loggers.  So, your "gtk" logger 
could be sending its logs to the same files as your "app" logger, for 
instance.  I may not fully understand the domain concept, yet, though.

thanks,
Richard





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

Re: First look at Guile Std Library available

[Robert Uhl]

Richard Todd <richardt@vzavenue.net> writes:
> 
> Then, (I was hoping only once every few years), you have to say
> "Enough!" and break with the past.

I'm not certain about that--after all, libc has stayed pretty much the
same for decades.  Heck, we still have gets(), for the truly perverse.

Standard libraries should, as a rule, not change their interfaces.
Given the right thought into their APIs at the outset, it's not needed.
Even where it would be nice, it must be weighed against the need to
maintain compatibility.

I can still pick up little C progs from the clory days and have a _very_
good chance of compiling them; that would not be possible of libc kept
changing.

-- 
Robert Uhl <ruhl@4dv.net>
What parts of `shall make no law,' `shall not be infringed,' and `shall
not be violated' don't you understand?


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

Re: First look at Guile Std Library available

[Richard Todd]

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

On Mon, Jan 05, 2004 at 09:03:52AM -0700, Robert Uhl wrote:
> Richard Todd <richardt@vzavenue.net> writes:
> > 
> > Then, (I was hoping only once every few years), you have to say
> > "Enough!" and break with the past.
> 
> I'm not certain about that--after all, libc has stayed pretty much the
> same for decades.  Heck, we still have gets(), for the truly perverse.

The basis of the proposal was that you'd still have whatever schemely
'gets' we were living with, but it would stay in (std xxx).  We would
be encouraging the new development to move to (std2 xxx).  The C
language doesn't have a similar mechanism to make such a clean break.

We're also presuming there's sufficient legacy code to save that it is
worth saving.  In a few years, when std2 may become desireable, we can
look around.  If there is still very little guile use, we may just say
to ourselves, "why bother?" and make the incompatible cleanups.

At the other end of the spectrum, where we have grown to C-like
popularity, then we will certainly care a lot more about compatibility
than fixing a few warts.

I'm hoping it ends up in-between, where we care enough to leave 
(std ...) behind.  Maybe indefinitely.  Maybe for a couple years, so
people can upgrade old code.  Who knows?  I don't want to argue about
a hypothetical library cleanup for a library that doesn't exist yet.
I would like to put some effort into producing that library.

(also, lets look at our peers.  Python (to take one example) has changed
its libraries over time, and I hear very few complaints.  It certainly
hasn't hurt its popularity)

Richard Todd

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

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

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

Re: First look at Guile Std Library available

[Robert Uhl]

Richard Todd <richardt@vzavenue.net> writes:
> 
> I'm hoping it ends up in-between, where we care enough to leave (std
> ...) behind.  Maybe indefinitely.  Maybe for a couple years, so people
> can upgrade old code.

The nice thing about permanent interfaces is that one can always compile
against them--which is why C code written by college students in the
early 80s is often still useful.  Or at least can be made to be so,
anyway:-)

> I don't want to argue about a hypothetical library cleanup for a
> library that doesn't exist yet.  I would like to put some effort into
> producing that library.

Naturally; it's very silly to care about supporting something which
doesn't even exist yet.  But it does make sense to consider what a good
usable design would entail ahead of time, so that no
backwards-incompatible changes to the API are needed in the future.
Scheme is nicer than C in this regard, of course, as optional & rest
parameters give one a certain flexibility.

Anyway, what's the URL again?  I really should try my hand at it.
Although my one true project is to figure out number->string well enough
to make it Do the Right Thing for decimals in bases other than 10 (I'm a
big fan of duodecimal).

-- 
Robert Uhl <ruhl@4dv.net>
According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery.  These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands.  Three times as many were injured if
they used other means of resistance.
          --G. Kleck, Policy Lessons from Recent Gun Control Research


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

number->string radix patch (Was Re: First look at Guile Std Library available)

[Richard Todd]

[-- Attachment #1.1.1: Type: text/plain, Size: 1354 bytes --]

On Mon, Jan 05, 2004 at 06:36:07PM -0700, Robert Uhl wrote:
> Although my one true project is to figure out number->string well enough
> to make it Do the Right Thing for decimals in bases other than 10 (I'm a
> big fan of duodecimal).

I've seen this wish twice from you in the short time I've been
watching guile-user, so I took a crack at it.  You are right, the
algorithm is hard to follow, but I think I worked it out.  I only
tested it by typing in random numbers and eyeballing the results, so
if you don't mind try it out and let me know if you get bad answers.

The patch should apply to CVS guile.
(supports the full 2 -> 36 radix range that integers enjoyed)

(PS I used CAPS for the letters since, as the last two examples show,
you need a way to differentiate the 'e' and 'i' from the digits in the
number.  Should this patch ever make it into guile, maybe all
string->number operations should switch to uppercase.)

Example:
guile> (number->string 35.25 36)
"Z.9"
guile> (number->string 0.25 2)
"0.01"
guile> (number->string 255.0625 16)
"FF.1"
guile> (number->string (/ 1 3) 3)
"1/10"
guile> (number->string 11.33333333333333333 12)
"B.4"
guile> (number->string 11.33333333333333333+23i 12)
"B.4+1B.0i"
guile> (number->string 1.324e44 16)
"5.EFE0A14FAFEe24"


Richard Todd 
richardt at vzavenue dot net

[-- Attachment #1.1.2: radix.patch --]
[-- Type: text/plain, Size: 7797 bytes --]

Index: libguile/numbers.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/numbers.c,v
retrieving revision 1.220
diff -u -r1.220 numbers.c
--- libguile/numbers.c	3 Jan 2004 21:38:38 -0000	1.220
+++ libguile/numbers.c	6 Jan 2004 18:13:50 -0000
@@ -91,7 +91,7 @@
 /* FLOBUFLEN is the maximum number of characters neccessary for the
  * printed or scm_string representation of an inexact number.
  */
-#define FLOBUFLEN (10+2*(sizeof(double)/sizeof(char)*SCM_CHAR_BIT*3+9)/10)
+#define FLOBUFLEN (40+2*(sizeof(double)/sizeof(char)*SCM_CHAR_BIT*3+9)/10)
 
 #if defined (SCO)
 #if ! defined (HAVE_ISNAN)
@@ -1848,19 +1848,71 @@
 #undef FUNC_NAME
 
 /*** NUMBERS -> STRINGS ***/
-int scm_dblprec;
-static const double fx[] =
-{  0.0,  5e-1,  5e-2,  5e-3,   5e-4, 5e-5,
-  5e-6,  5e-7,  5e-8,  5e-9,  5e-10,
- 5e-11, 5e-12, 5e-13, 5e-14,  5e-15,
- 5e-16, 5e-17, 5e-18, 5e-19,  5e-20};
+#define SCM_MAX_DBL_PREC  60
+#define SCM_MAX_DBL_RADIX 36
+
+/* this is an array starting with radix 2, and ending with radix SCM_MAX_DBL_RADIX */
+static int scm_dblprec[SCM_MAX_DBL_RADIX - 1];
+static double fx_per_radix[SCM_MAX_DBL_RADIX - 1][SCM_MAX_DBL_PREC];
+
+static
+void init_dblprec(int *prec, int radix) {
+   /* determine floating point precision by adding successively
+      smaller increments to 1.0 until it is considered == 1.0 */
+   double f = ((double)1.0)/radix;
+   double fsum = 1.0 + f;
+
+   *prec = 0;
+   while (fsum != 1.0)
+   {
+      if (++(*prec) > SCM_MAX_DBL_PREC)
+         fsum = 1.0;
+      else
+      {
+         f /= radix;
+         fsum = f + 1.0;
+      }
+   }
+   (*prec) -= 1;
+}
+
+static
+void init_fx_radix(double *fx_list, int radix)
+{
+  /* initialize a per-radix list of tolerances.  When added
+     to a number < 1.0, we can determine if we should raund
+     up and quit converting a number to a string. */
+   int i;
+   fx_list[0] = 0.0;
+   fx_list[1] = 0.5;
+   for( i = 2 ; i < SCM_MAX_DBL_PREC; ++i ) 
+     fx_list[i] = (fx_list[i-1] / radix);
+}
+
+/* use this array as a way to generate a single digit */
+static const char*number_chars="0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
 
 static size_t
-idbl2str (double f, char *a)
+idbl2str (double f, char *a, int radix)
 {
-  int efmt, dpt, d, i, wp = scm_dblprec;
-  size_t ch = 0;
-  int exp = 0;
+   int efmt, dpt, d, i, wp;
+   double *fx;
+#ifdef DBL_MIN_10_EXP
+   double f_cpy;
+   int exp_cpy;
+#endif /* DBL_MIN_10_EXP */
+   size_t ch = 0;
+   int exp = 0;
+
+   if(radix < 2 || 
+      radix > SCM_MAX_DBL_RADIX)
+   {
+      /* revert to existing behavior */
+      radix = 10;
+   }
+
+   wp = scm_dblprec[radix-2];
+   fx = fx_per_radix[radix-2];
 
   if (f == 0.0)
     {
@@ -1870,7 +1922,6 @@
       if (sgn < 0.0)
 	a[ch++] = '-';
 #endif
-
       goto zero;	/*{a[0]='0'; a[1]='.'; a[2]='0'; return 3;} */
     }
 
@@ -1896,10 +1947,15 @@
 
 #ifdef DBL_MIN_10_EXP  /* Prevent unnormalized values, as from 
 			  make-uniform-vector, from causing infinite loops. */
-  while (f < 1.0)
+  /* just do the checking...if it passes, we do the conversion for our
+     radix again below */
+  f_cpy = f;
+  exp_cpy = exp;
+
+  while (f_cpy < 1.0)
     {
-      f *= 10.0;
-      if (exp-- < DBL_MIN_10_EXP)
+      f_cpy *= 10.0;
+      if (exp_cpy-- < DBL_MIN_10_EXP)
 	{
 	  a[ch++] = '#';
 	  a[ch++] = '.';
@@ -1907,10 +1963,10 @@
 	  return ch;
 	}
     }
-  while (f > 10.0)
+  while (f_cpy > 10.0)
     {
-      f *= 0.10;
-      if (exp++ > DBL_MAX_10_EXP)
+      f_cpy *= 0.10;
+      if (exp_cpy++ > DBL_MAX_10_EXP)
 	{
 	  a[ch++] = '#';
 	  a[ch++] = '.';
@@ -1918,25 +1974,27 @@
 	  return ch;
 	}
     }
-#else
+#endif
+
   while (f < 1.0)
     {
-      f *= 10.0;
+      f *= radix;
       exp--;
     }
-  while (f > 10.0)
+  while (f > radix)
     {
-      f /= 10.0;
+      f /= radix;
       exp++;
     }
-#endif
-  if (f + fx[wp] >= 10.0)
+
+  if (f + fx[wp] >= radix)
     {
       f = 1.0;
       exp++;
     }
  zero:
-#ifdef ENGNOT
+#ifdef ENGNOT 
+  /* adding 9999 makes this equivalent to abs(x) % 3 */
   dpt = (exp + 9999) % 3;
   exp -= dpt++;
   efmt = 1;
@@ -1963,15 +2021,15 @@
     {
       d = f;
       f -= d;
-      a[ch++] = d + '0';
+      a[ch++] = number_chars[d];
       if (f < fx[wp])
 	break;
       if (f + fx[wp] >= 1.0)
 	{
-	  a[ch - 1]++;
+          a[ch - 1] = number_chars[d+1]; 
 	  break;
 	}
-      f *= 10.0;
+      f *= radix;
       if (!(--dpt))
 	a[ch++] = '.';
     }
@@ -2006,26 +2064,25 @@
 	  exp = -exp;
 	  a[ch++] = '-';
 	}
-      for (i = 10; i <= exp; i *= 10);
-      for (i /= 10; i; i /= 10)
+      for (i = radix; i <= exp; i *= radix);
+      for (i /= radix; i; i /= radix)
 	{
-	  a[ch++] = exp / i + '0';
+          a[ch++] = number_chars[exp / i];
 	  exp %= i;
 	}
     }
   return ch;
 }
 
-
 static size_t
-iflo2str (SCM flt, char *str)
+iflo2str (SCM flt, char *str, int radix)
 {
   size_t i;
   if (SCM_REALP (flt))
-    i = idbl2str (SCM_REAL_VALUE (flt), str);
+    i = idbl2str (SCM_REAL_VALUE (flt), str, radix);
   else
     {
-      i = idbl2str (SCM_COMPLEX_REAL (flt), str);
+      i = idbl2str (SCM_COMPLEX_REAL (flt), str, radix);
       if (SCM_COMPLEX_IMAG (flt) != 0.0)
 	{
 	  double imag = SCM_COMPLEX_IMAG (flt);
@@ -2033,7 +2090,7 @@
 	     NaN.  They will provide their own sign. */
 	  if (0 <= imag && !xisinf (imag) && !xisnan (imag))
 	    str[i++] = '+';
-	  i += idbl2str (imag, &str[i]);
+	  i += idbl2str (imag, &str[i], radix);
 	  str[i++] = 'i';
 	}
     }
@@ -2114,7 +2171,7 @@
   else if (SCM_INEXACTP (n))
     {
       char num_buf [FLOBUFLEN];
-      return scm_mem2string (num_buf, iflo2str (n, num_buf));
+       return scm_mem2string (num_buf, iflo2str (n, num_buf, base));
     }
   else
     SCM_WRONG_TYPE_ARG (1, n);
@@ -2129,7 +2186,7 @@
 scm_print_real (SCM sexp, SCM port, scm_print_state *pstate SCM_UNUSED)
 {
   char num_buf[FLOBUFLEN];
-  scm_lfwrite (num_buf, iflo2str (sexp, num_buf), port);
+  scm_lfwrite (num_buf, iflo2str (sexp, num_buf, 10), port);
   return !0;
 }
 
@@ -2138,7 +2195,7 @@
 
 {
   char num_buf[FLOBUFLEN];
-  scm_lfwrite (num_buf, iflo2str (sexp, num_buf), port);
+  scm_lfwrite (num_buf, iflo2str (sexp, num_buf, 10), port);
   return !0;
 }
 
@@ -5538,13 +5595,12 @@
 #undef FUNC_NAME
 
 #endif
-
 void
 scm_init_numbers ()
 {
+  int i;
   abs_most_negative_fixnum = scm_i_long2big (- SCM_MOST_NEGATIVE_FIXNUM);
   scm_permanent_object (abs_most_negative_fixnum);
-
   mpz_init_set_si (z_negative_one, -1);
 
   /* It may be possible to tune the performance of some algorithms by using
@@ -5559,25 +5615,17 @@
   scm_add_feature ("complex");
   scm_add_feature ("inexact");
   scm_flo0 = scm_make_real (0.0);
+
+  /* determine floating point precision */
+  for(i=2; i <= SCM_MAX_DBL_RADIX; ++i)
+    {
+      init_dblprec(&scm_dblprec[i-2],i);
+      init_fx_radix(fx_per_radix[i-2],i);
+    }
 #ifdef DBL_DIG
-  scm_dblprec = (DBL_DIG > 20) ? 20 : DBL_DIG;
-#else
-  {				/* determine floating point precision */
-    double f = 0.1;
-    double fsum = 1.0 + f;
-    while (fsum != 1.0)
-      {
-	if (++scm_dblprec > 20)
-	  fsum = 1.0;
-	else
-	  {
-	    f /= 10.0;
-	    fsum = f + 1.0;
-	  }
-      }
-    scm_dblprec = scm_dblprec - 1;
-  }
-#endif /* DBL_DIG */
+  /* hard code precision for base 10 if the preprocessor tells us to... */
+      scm_dblprec[10-2] = (DBL_DIG > 20) ? 20 : DBL_DIG;
+#endif
 
 #ifdef GUILE_DEBUG
   check_sanity ();

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

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

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

Re: number->string radix patch (Was Re: First look at Guile Std Library available)

[Robert Uhl]

Cool!  It's always annoyed me how broken number->string was.

Of course, now my one idea for how to contribute to Guile is gone.  And
you managed to figure out the conversion code, too.  I've taken a look
at it before, but was never able to figure out how to hook in the Right
Thing.  Says something about my programming skills:-)

Seriously, thanks very much.  I really do hope that this makes it into
the main branch.

-- 
Robert Uhl <ruhl@4dv.net>
OTOH there are some of us in .UK who would rather like NAFTA to
become the North Atlantic Free-Trade Area, and for .UK to sign
up to it instead of us piddling around on the periphery of some
wannabe second-rate-superpower European bureaucracy that, in all
honesty, couldn't come to a consensus on how many primary colours
there are.                                               --Tanuki


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

Re: number->string radix patch (Was Re: First look at Guile Std Library available)

[Richard Todd]

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

On Tue, Jan 06, 2004 at 09:04:03PM -0700, Robert Uhl wrote:
> Cool!  It's always annoyed me how broken number->string was.
> 
> Of course, now my one idea for how to contribute to Guile is gone. 

There's plenty of things that people can do!  And they definitely
don't have to be in libguile.  (I've been arguing for the last few
days that the most important work right now is actually _outside_, in
the reusable module arena).

> Seriously, thanks very much.  I really do hope that this makes it into
> the main branch.

You are welcome!  I took a couple days off to have my wisdom teeth
pulled, so I've had an odd combination of free time and poinkillers
for the last couple days.  Your mail got my attention last night, and
I couldn't resist giving it a try.

Please, if you haven't, do try this patch and tell me if you see any
problems with the conversions.  Once you agree that it seems to be
working, I'll clean it up and see if the maintainers want the change.

Richard 

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

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

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

Re: number->string radix patch (Was Re: First look at Guile Std Library available)

[Robert Uhl]

Richard Todd <richardt@vzavenue.net> writes:
>
> > Of course, now my one idea for how to contribute to Guile is gone. 
> 
> There's plenty of things that people can do!

Perhaps I should better have written, 'the one area I might have had
something to contribute in is now gone.'  I'm not very good at
programming, I'm afraid, despite how much I like it.  Sad but true.

The general radix conversion algorithm was the one thing I though I
might have a chance at.  Of course, I couldn't wrap my head around the
_old_ code, so that's really rather doubtful.

> Please, if you haven't, do try this patch and tell me if you see any
> problems with the conversions.

I'm afraid that I don't actually have an up-to-date guile installation
to test against.  Maybe this'll give me an incentive to do it.

The one thought I had was that it should be possible to do away with the
static array initialisation.  Maybe someday I'll be able to work on
_that_:-)

Once again, thanks for the good work.

-- 
Robert Uhl <ruhl@4dv.net>
The power of Satan is as nothing before the might of the Lord, so don't
go getting any ideas.                             --I Abyssinians 20:20


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

I get unknown immediate error in guile 1.7

[Roland Orre]

I've tried to get guile 1.7 work but I seem to have a problem with
loadable modules. As soon as I call a function in them I get an
"unknown-immediate" error. This possibly sounds like some include
problem but as far as I know tag principles has not changed between
1.6 and 1.7.

The most basic is readline of course as I haven't recompiled other
modules yet. About readline, the file "libtool" was not created by
autogen.sh in guile-readline so I linked to ../libtool instead.

If I load an old (1.6) libguilereadline I get segmentation fault, which
indicates some significant change. When I load the 1.7 libguilereadline
I get the errors below after (activate-readline), any ideas?
I've used gcc 3.3.2.

	Best regards
	Roland

guile-user> ERROR: In procedure apply:nconc2last:
ERROR: Wrong type argument in position 1: #<unknown-immediate 0x2974>
ABORT: (wrong-type-arg)
ERROR: In procedure %readline:
ERROR: readline is not reentrant
ABORT: (misc-error)
ERROR: In procedure %readline:
ERROR: readline is not reentrant
ABORT: (misc-error)
ERROR: In procedure %readline:
ERROR: readline is not reentrant
...



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

Re: I get unknown immediate error in guile 1.7

[Roland Orre]

I solved the problem. It seems as linking (at least for me) is not done
in the right way for modules, neither for 1.6 or 1.7. Explanation below.

On Thu, 2004-01-08 at 08:11, Roland Orre wrote:
> I've tried to get guile 1.7 work but I seem to have a problem with
> loadable modules. As soon as I call a function in them I get an
> "unknown-immediate" error. This possibly sounds like some include
> problem but as far as I know tag principles has not changed between
> 1.6 and 1.7.
> 
> The most basic is readline of course as I haven't recompiled other
> modules yet. About readline, the file "libtool" was not created by
> autogen.sh in guile-readline so I linked to ../libtool instead.
> 
> If I load an old (1.6) libguilereadline I get segmentation fault, which
> indicates some significant change. When I load the 1.7 libguilereadline
> I get the errors below after (activate-readline), any ideas?
> I've used gcc 3.3.2.

The problem showed to be that guile loaded wrong libraries, which was
caused by the the correct library files not having been created. Guile
had been reading wrong libguilereadline.la all the time. I noticed this
when I deinstalled the (debian distributed) guile-1.6. Then the
libguilereadline.la library was not found for my locally compiled
guile-1.6 either, despite that I had included both
/usr/local/guile/guile-1.6.0/lib
/usr/local/guile/guile-1.6.0/guile-readline in the LTDL_LIBRARY_PATH.

I then relinked the readline.o file under guile-readline with
the settings I use for my own modules, then it worked. The make
script is at the end. The correct guile-1.6 libguilereadline
file was read and the same procedure worked for guile-1.7 as well.
The problem probably has to do with the guile-readline autogen.sh
but how this script works is above my head.

The fundamental problem seems to be that the installation linking
is not done in the right way. None of the .la files under the
lib directory (${exec_prefix}/lib) contains any library references.
Observe that I used the name "libgreadline" in the script.

Here are the error messages given.
After a normal make install, where LTDL library is set as:
export LTDL_LIBRARY_PATH=/usr/local/guile/guile-1.7/lib

I get the following (empty) error message:
  /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
  In procedure dynamic-link in expression 
  (load-extension "libguilereadline" "scm_init_readline"):
  /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
  file: "libguilereadline", message: ""

If I then also include /usr/local/guile/guile-1.7/guile-readline
first in the LTDL path, then I get the following error message:
 /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
 In procedure dynamic-link in expression
 (load-extension "libguilereadline" "scm_init_readline"):
 /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
 file: "libguilereadline", message: "|o\"@àÌ\x11\x08readline.a:
 cannot open shared object file: No such file or directory"

If I then run the make script below under guile-readline then
it works. This newly created .la files contains library references
to the .so files created under .libs. 
I also included my configuration parameters below.

Have I done anything obviously wrong in the configuration?

=============================================================
# This make file generates a working libguilereadline

top_builddir = /usr/local/guile/guile-1.6.0
libdir=/usr/local/guile/guile-latest/guile-readline/..//lib
LIBS=../libguile/libguile.la -lreadline -lncurses
EXTRA=-version-info 10:0:0 -export-dynamic -no-undefined
CC=gcc

all: libgreadline

libgreadline: readline.o
	echo sh ${top_builddir}/libtool --mode=link $(CC) $^ $(EXTRA) $(LIBS)
-rpath $(libdir) -o libgreadline.la
	sh ${top_builddir}/libtool --mode=link $(CC) $^ $(EXTRA) $(LIBS) 
-rpath $(libdir) -o libgreadline.la

=============================================================

#These are my configuration parameters:

GUILEROOT=`pwd`
echo ${GUILEROOT}

./configure --with-threads --with-readline \
 --prefix=${GUILEROOT}                  \
 --build=i686                           \
 --exec-prefix=${GUILEROOT}             \
 --bindir=${GUILEROOT}/bin              \
 --sbindir=${GUILEROOT}/bin             \
 --sysconfdir=${GUILEROOT}/etc          \
 --datadir=${GUILEROOT}                 \
 --sharedstatedir=${GUILEROOT}/com      \
 --localstatedir=${GUILEROOT}/var       \
 --includedir=${GUILEROOT}/include      \
 --oldincludedir=/usr/include           \
 --mandir=/usr/local/man                \
 --infodir=/usr/local/info              \
 --enable-maintainer-mode               \
 --enable-ltdl-install




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

Re: I get unknown immediate error in guile 1.7

[Kevin Ryde]

Roland Orre <roland.orre@neurologic.se> writes:
>
> The problem showed to be that guile loaded wrong libraries, which was
> caused by the the correct library files not having been created. Guile
> had been reading wrong libguilereadline.la all the time.

I think I might have struck that too, but with debian guile 1.4
getting in the way of cvs guile.

I had an idea I thought the guile library search path ought to include
its configured $prefix/lib ahead of /usr/lib, but I forget exactly.

Library versioning is probably supposed to protect against some of
this sort of thing.  Dunno what the status on that currently is
though.


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