guile-oops compile error on SuSE9.0

Hi,
In vain i tried to install guile-oops on my SuSE9.0 prof box.
response to make attached. what can i do ?

guile-snarf -DHAVE_SCM_SIMPLE_FORMAT=1 -DHAVE_SCM_SHARED_ARRAY_ROOT=1  -I. -I.    -g -O2  -Wall
-Wpointer-arith -Wmissing-prototypes goops.c > goops.x \
|| { rm goops.x; false; }
In file included from goops.c:55:
goops.h:105:1: warning: "SCM_METHOD" redefined
In file included from /usr/include/libguile.h:81,
                 from goops.c:50:
/usr/include/libguile/goops.h:97:1: warning: this is the location of the previous definition
In file included from goops.c:55:
goops.h:131:1: warning: "SCM_ACCESSORS_OF" redefined
In file included from /usr/include/libguile.h:81,
                 from goops.c:50:
/usr/include/libguile/goops.h:123:1: warning: this is the location of the previous definition
In file included from goops.c:55:
goops.h:136:1: warning: "SCM_INSTANCEP" redefined
In file included from /usr/include/libguile.h:81,
                 from goops.c:50:
/usr/include/libguile/goops.h:132:1: warning: this is the location of the previous definition
In file included from goops.c:55:
goops.h:139:1: warning: "SCM_PUREGENERICP" redefined
In file included from /usr/include/libguile.h:81,
                 from goops.c:50:
/usr/include/libguile/goops.h:136:1: warning: this is the location of the previous definition
In file included from goops.c:55:
goops.h:140:1: warning: "SCM_SIMPLEMETHODP" redefined

Re: guile-oops compile error on SuSE9.0

joop renes <jj.renes <at> hccnet.nl> writes:

> In vain i tried to install guile-oops on my SuSE9.0 prof box.
> response to make attached. what can i do ?

You probably already have GOOPS included in Guile and do not need to
compile guile-goops at all.  Guile includes GOOPS since version 1.6.0.
Check with "guile --version".

--

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

guile segfaults

Version: guile--1.6.4

Guile segfaults when given the following code:

   (define a (make-uniform-array 1/3 3 3))
   (uniform-array-set1! a 5.0 (cons 0 0))

This was during my attempt to set the (0, 0) entry of the two-dimensional
array a to 5.0.

As it happens, the syntax is incorrect.  The second line should
have been:

   (uniform-array-set1! a 5.0 '(0 0))

Nevertheless, guile shouldn't have segfaulted on wrong input.

Just wanted to let you know.

--

-- 
Rouben Rostamian

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: another symbol-printing fix

I wrote:
> 	* print.c (scm_print_symbol_name): Handle #{`foo}#, #{,foo}#,
> 	and #{.}# specially.
>
> This is still not complete, though.  There are still problem cases
> like #{0.0}#, #{-i}#, etc.

This patch handles those numeric cases.  It incorporates and overrides
my earlier patch.  After this, there are no remaining buggy cases to
solve, AFAIK: any symbol, no matter how strange, should be able to be
written and re-read, resulting in the same symbol.

	* print.c (scm_print_symbol_name): Handle #{`foo}#, #{,foo}#,
	#{.}#, and all numeric strings specially.

paul

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

patch to build guile CVS on Mac OS X

Hi all, 

These changes made guile CVS build for me on Mac OS X.  Non-scientific
testing (ran some of my programs) seems to show that it's working.

I'd appreciate it if this, or something like it, could get applied.

BTW, on 12/30 I submitted a patch to bug-guile for a problem with
ice-9/q.scm and haven't gotten an ACK from anyone about it.  Should I
re-submit after a while, or ...?

Summary of changes: 

1) Mac OS X has a funny quirk about getting to the
environment from shared libs.  Patches exactly like what I'm
submitting were applied to many other programs (like python and tcl)
for this exact issue.  posix.c and stime.c were hit.

2) The SCM_MUTEX_MAX_SIZE was too small.  I also added to the error
message in threads-plugin.c, so that it tells you what the size should
be.  This was faster than getting to that point in a debugger!  It may
be that you'd want to just raise the size for all platforms, but I
took the conservative approach and just raised it for __APPLE__.

3) numbers.c defined s_bignum but did not use it, and guile compiles
such that this was an error.  Maybe it'd be right to just get rid of
it...but to get this to work I just #ifdef'ed it out for __APPLE__

Richard Todd
richardt at vzavenue dot net

Re: patch to build guile CVS on Mac OS X

Richard Todd <richardt <at> vzavenue.net> writes:
>
> +#ifdef __APPLE__
> +#define SCM_MUTEX_MAXSIZE (12 * sizeof (long))

Hmm, I guess if that's what it takes.

For reference, how many bytes is the underlying actual mutex?

> +#else
>  #define SCM_MUTEX_MAXSIZE (9 * sizeof (long))
> +#endif

No, I think it should be increased for all systems.  I think it'll be
too hard to keep the conditionals right going forward otherwise.  (The
same size needs to be maintained for binary compatibility.)

PS. Matters like this relating only to the development code can be
raised on the guile-devel list.

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: patch to build guile CVS on Mac OS X

On Wed, Jan 07, 2004 at 09:02:19AM +1000, Kevin Ryde wrote:
> Richard Todd <richardt <at> vzavenue.net> writes:
> >
> > +#ifdef __APPLE__
> > +#define SCM_MUTEX_MAXSIZE (12 * sizeof (long))
> 
> Hmm, I guess if that's what it takes.
> 
> For reference, how many bytes is the underlying actual mutex?

Both normal and recursive mutexes are showing up as 44 bytes.  Either
it was the late night, or caution, but I upped it to 48 bytes.  I guess
I could have gotten by on 11*sizeof(long).

> No, I think it should be increased for all systems.  I think it'll be
> too hard to keep the conditionals right going forward otherwise.  (The
> same size needs to be maintained for binary compatibility.)

I thought you might prefer that, but I was trying to make the smallest changes
to other architectures as possible, and let you make that call.

Thanks for looking these over.

> PS. Matters like this relating only to the development code can be
> raised on the guile-devel list.

Got it, thanks.

Richard

Re: ice-9/q.scm bug fix

Richard Todd <richardt <at> vzavenue.net> writes:
>
> It appears to be a lisp-ism, where (not '()) was expected to return
> #t, and of course in scheme it does not.

Thanks, I applied your fix.

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: patch to build guile CVS on Mac OS X

On Wed, Jan 07, 2004 at 08:00:28AM +1000, Kevin Ryde wrote:
> Richard Todd <richardt <at> vzavenue.net> writes:
> >
> > +#if defined(__APPLE__) && defined(__DYNAMIC__)
> > +#include<crt_externs.h>
> > +static char ** environ;
> > +#else
> >  extern char ** environ;
> > +#endif 
> >  
> >  #ifdef HAVE_GRP_H
> >  #include <grp.h>
> >  <at>  <at>  -1735,6 +1740,10  <at>  <at> 
> >  void 
> >  scm_init_posix ()
> >  {
> > +#if defined(__APPLE__) && defined(__DYNAMIC__)
> > +  environ = *_NSGetEnviron();
> > +#endif
> > +
> 
> That's really weird.  I'd rather not do that if it can be avoided.

Yeah, that's why I pointed out in my mail that I've seen (via google)
that lots of patches along these lines have been made.  I didn't want
anyone to assume I was nuts!

As far as I can tell, it's part of their OS (with heritage going back
to NeXT), that the environment is not directly accessible to loaded
libraries (they're stored off in the crt0 bootstrap code and

Re: patch to build guile CVS on Mac OS X

Richard Todd <richardt <at> vzavenue.net> writes:
>
> +#if defined(__APPLE__) && defined(__DYNAMIC__)
> +#include<crt_externs.h>
> +static char ** environ;
> +#else
>  extern char ** environ;
> +#endif 
>  
>  #ifdef HAVE_GRP_H
>  #include <grp.h>
>  <at>  <at>  -1735,6 +1740,10  <at>  <at> 
>  void 
>  scm_init_posix ()
>  {
> +#if defined(__APPLE__) && defined(__DYNAMIC__)
> +  environ = *_NSGetEnviron();
> +#endif
> +

That's really weird.  I'd rather not do that if it can be avoided.

Surely they can't expect every library that accesses environ to get a
system-specific change?

Does it work to take the declaration of environ from <stdlib.h>
instead of giving an explicit "extern"?  The autoconf way is normally
to let the headers do the job where possible.

_______________________________________________