Re: hash-fold

[Marius Vollmer]

Mikael Djurfeldt <[EMAIL PROTECTED]> writes:

> Keisuke Nishida <[EMAIL PROTECTED]> writes:
> 
> > The following code makes an error.  Is this a feature or a bug?
> > 
> > guile> (hash-fold acons () (make-vector 5))
> 
> It's a bug in the above expression.  (make-vector 5) makes a vector
> with # as elements.  This is not a hash table.
> 
> Instead, try
> 
>   (hash-fold acons '() (make-vector 5 '()))

Why not use `make-hash-vector'?

Re: Crash in scm_boot_guile if stdin isn't open.

[Marius Vollmer]

Jon K Hellan <[EMAIL PROTECTED]> writes:

> Build it, and run it with stdin closed:
> % ./prog <&-1
> Segmentation fault (core dumped)
> 
> (gdb) bt

How did scm_init_fluids sneek into your backtrace?  Mine looks like:

% gdb guile
GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-pc-linux-gnu"...
(gdb) r <&-1
Starting program: /usr/local/bin/guile <&-1

Program received signal SIGSEGV, Segmentation fault.
0x40060543 in scm_ithrow (key=1075107536, args=1075141056, noreturn=1) at throw.c:635
635 }
(gdb) bt
#0  0x40060543 in scm_ithrow (key=1075107536, args=1075141056, noreturn=1) at 
throw.c:635
#1  0x40026b85 in scm_error (key=1075107536, subr=0x4007a000 "scm_fport_buffer_add", 
message=0x40079259 "~A", args=1075141032, 
rest=1075141016) at error.c:82
#2  0x40026e11 in scm_syserror () at error.c:135
#3  0x400351e8 in scm_fport_buffer_add (port=1075141008, read_size=-1, write_size=-1) 
at fports.c:86
#4  0x4003584d in scm_fdes_to_port (fdes=0, mode=0x4007a706 "r", name=1075141000) at 
fports.c:388
#5  0x4003ceee in scm_standard_stream_to_port (fdes=0, mode=0x4007a706 "r", 
name=0x4007a6f4 "standard input") at init.c:255
#6  0x4003cf50 in scm_init_standard_ports () at init.c:278
#7  0x4003d2b8 in scm_boot_guile_1 (base=0xbbd4, closure=0xbbd8) at init.c:518
#8  0x4003d0c0 in scm_boot_guile (argc=2, argv=0xbc54, main_func=0x80488ec 
, closure=0x0) at init.c:392
#9  0x8048931 in main (argc=2, argv=0xbc54) at guile.c:76

The segmentation fault only occurs when libguile has been compiled
with optimizations.

When libguile is compiled without optimizations, it produces a clean
`abort' in scm_ithrow:642 in this situation because it wants to throw
an EBADF error about fd 0 but is not yet prepared to handle such
errors.

I don't know why it segfaults when compiled with optimizations.

> Why I care: Gnome object activation closes fd 0 as part of the
> daemonizing procedure. Gnumeric embeds guile, and crashes if it's
> activated via the Gnome Object Activation service.
> 
> We can work around this if we have to. But shouldn't guile be
> prepared for this situation.

I think Guile should not produce a segmentation fault, but I also
think that one never ever should expect a program to run with a
invalid fd 0.  Instead, one should hook fd 0 to /dev/null or
something.  The standard streams should always be valid (IMO).

- Marius

Re: Crash in scm_boot_guile if stdin isn't open.

[Marius Vollmer]

Jon K Hellan <[EMAIL PROTECTED]> writes:

> Anyway, it's better that guile works around it than that all apps
> which embed it each have to make a workaround.

I have now committed a workaround.  Please test it.

2000-03-12  Marius Vollmer  <[EMAIL PROTECTED]>

* init.c (scm_standard_stream_to_port): Check whether the file
descriptor is valid and substitute "/dev/null" when not.

Re: Crash in scm_boot_guile if stdin isn't open.

[Marius Vollmer]

Gary Houston <[EMAIL PROTECTED]> writes:

> It's quite interesting, it seems like a bug in gcc.
> 
> Please compile this with -O2 and -O2 -fno-gcse and check my sanity:

You are sane:

% gcc -o bug bug.c
% ./bug 
Aborted (core dumped)
% gcc -o bug -O2 bug.c
% ./bug 
Segmentation fault (core dumped)
% gcc -o bug -O2 -fno-gcse bug.c
% ./bug 
Aborted (core dumped)
% gcc --version
2.95.1
% uname -m
i586

Re: Crash in scm_boot_guile if stdin isn't open.

[Marius Vollmer]

Gary Houston <[EMAIL PROTECTED]> writes:

> I think I'll add something to configure to use the -fno-gcse flag if it's
> supported.

With proper benchmarking the effect, of course. ;-)

Re: autogen.sh broken for guile-readline

[Marius Vollmer]

thi <[EMAIL PROTECTED]> writes:

> a while ago, i submitted a small patch to address the situation
> where aclocal and libtool are installed w/ different PREFIX.
> perhaps this is the problem (still)?  (insert standard grumble about
> dropped patches here.)

I'm not opposed to this change, but I generally think that a package
should not try too hard to workaround misinstalled auxiliary packages.

Is there a some situation where one absolutely has to use this hack?

Re: autogen.sh broken for guile-readline

[Marius Vollmer]

thi <[EMAIL PROTECTED]> writes:

> i don't believe installation of tools using different prefixes is really
> considered a misinstallation.

Agreed.  "misinstallation" was probably the wrong word.  In any case
and my view, the problem lies entirely with automake and libtool and
not with how Guile uses them.  When you install automake and libtool
with different prefixes, they just don't work together without the
user being aware of the differing prefixes and fighting them.

This can be seen as either a bug with automake, libtool, both, or the
way they have been installed.  I don't see it as a bug in Guile.

Which does not mean that we can't install your workaround.  But I
think we should be reluctant to do so.  Too many workarounds do not
make for good maintainability, because their `reasons-of-existence'
are usually ill-defined and dependent on random external curiosities,
which might turn into completely different curiosities without notice.
I don't think people will be happy to maintain bug-compatability
because of the many workarounds that have been installed elsewhere.

Anyway, back to this specific workaround, I think it has a special
audience that might make me reconsider my position.  they way I
understand the situation, it should help people most who want to
compile Guile from CVS, but are not really doing development on Guile.
I think we want to encourage people to compile from CVS because we
then don't have to release a tarball so often. [Do the nightly
snapshots still exists?]

In that light, we should make it easy to compile from CVS.  The next
question then is: how common is this automake/libtool problem?  I
think it's quite common, it has happened to me on all platforms and
all projects.  How hard is it to fix this problem without hacking
automake, libtool, or Guile?  Not too hard, I'd say.  You just need to
install automake and libtool with a common prefix and use them instead
of the old ones.  I found that I had to do that in the end anyway,
because I don't want to depend on the versions installed by vendors.
Installation from source is very easy for both automake and libtool.

But I agree that it would be much more convenient when it would just
work.  Therefore, your patch is probably the right thing, anyway.  But
we should make sure that it is consistent.  One thing I'm aware of is
that the "-I" options are only passed to aclocal when it is invoked
from autogen.sh, but not when invoked from make.  We should probably
also set ACLOCAL_AMFLAGS in the relevant Makefile.am files.  Could you
update your patch to do that?

In addition to this workaround, we shuld also be approaching the
autoconf/automake/libtool guys with this problem and ask for their
opinion.  Maybe they have a superior solution that would help all
packages that use automake/libtool and not just Guile.  Or maybe we
can help them develop one.

- Marius

Re: assoc-ref broken?

[Marius Vollmer]

thi <[EMAIL PROTECTED]> writes:

> something is weird w/ assoc-ref  this is w/ latest cvs guile.
>
> guile> (assoc 3 '((1 . 2) (3 . 4) (5 . 6)))
> (3 . 4)
> guile> (assoc-ref 3 '((1 . 2) (3 . 4) (5 . 6)))
> #f

Use

guile> (assoc-ref '((1 . 2) (3 . 4) (5 . 6)) 3)
4

instead.  Arguments for assoc-ref are the other way around from assoc.
Also note that it does return the value and not the cell.  Both things
are to make assoc-ref rhyme with vector-ref, string-ref, list-ref,
etc.

sig11 puts Guile in a loop

[Marius Vollmer]

Hi,

after this function

SCM_PROC(s_segfault, "segfault", 0, 0, 0, sim_segfault);

SCM
sim_segfault ()
{
  *(int *)0 = 0;
  return SCM_UNSPECIFIED;
}

has been added to libguile, I get this behaviour

guile> (segfault)


Guile is in a loop, calling take_signal, marking the signal_async, and
then returning from the signal handler only to get the sig11 again,
without making any progress.

I don't know enough about Unix signals, and much less about how Guile
handles Unix signals, to know what to do about this.  I don't think
that Guile has always behaved in this way, but I can't say for sure.

I think that Guile should not return from its signal handler for
non-continueable signals, like SIGSEGV, SIGILL and SIGBUS.  It should
directly throw to wherever is appropriate.

Re: sig11 puts Guile in a loop

[Marius Vollmer]

Gary Houston <[EMAIL PROTECTED]> writes:

> This behaviour can be got back by explicitly calling SCM_ASYNC_TICK from
> the handler, but I'm not sure if this was what you wanted to avoid with
> the posix threads change:

Intuitively, I would like to call SCM_ASYNC_TICK from take_signal, but
I don't know the consequences.  Mikael?

Maybe it would be OK to just call SCM_ASYNC_TICK for signals that can
not be ignored (that is, replace the call to raise with SCM_ASYNC_TICK
in Gary's second variant).

I want Guile to handle signals that happen in dynamically linked C
code as gracefully as possible.  My situation is this: I have a
simulation engine written in Guile that can dynamically load
user-written simulation models.  These models are written in C++.  I
don't want a bug in such a module to take down the simulator.  I know
that this desire is quite naive, but I'd like to get as close as
possible.

Re: libguile/scmsigs.c (orig_handlers): function returns array

[Marius Vollmer]

Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes:

> static SIGRETTYPE (*orig_handlers)(int)[NSIG];
> 
> This defines a pointer to a function returning an array, which
> isn't allowed in C.  I believe the purpose was to define an array
> of pointers to functions:
> 
> static SIGRETTYPE (*orig_handlers[NSIG])(int);

Thanks!

However, I can't test this change because I HAVE_SIGACTION.

2000-05-03  Marius Vollmer  <[EMAIL PROTECTED]>

* scmsigs.c (orig_handlers) [HAVE_SIGACTION]: Fix declaration to
be an array of function pointers instead of being a pointer to an
array returning function.  Thanks to Kalle Olavi Niemitalo!

Re: guile-core (cvs version) -qt in INSTALL

[Marius Vollmer]

Bill Schottstaedt <[EMAIL PROTECTED]> writes:

> line 73 of the cvs guile-core INSTALL file says "-qt"
> but I think it means "-lqt".

Thanks!  INSTALL seems to be somewhat outdated in general.  I will
look over it.

Re: sig11 puts Guile in a loop

[Marius Vollmer]

Mikael Djurfeldt <[EMAIL PROTECTED]> writes:

> What you could, and probably should, do is to call SCM_TICK in longer
> loops in your simulator code.

Yes, that's a good suggestion.  However, the problem is that once a
segv occured, and the handler for SIGSEGV simply returns, the program
just reexecutes the instruction that caused the segv.  No SCM_TICK can
help here.

Re: sig11 puts Guile in a loop

[Marius Vollmer]

Mikael Djurfeldt <[EMAIL PROTECTED]> writes:

> But, as you previously suggested, it is not sensible to try to
> continue executing code after a segv.  That *kind* of signals should
> cause immediate abort, I think.

Ok, I'll implement something to that effect.  I'm not sure if I canb
get it completely right the first time, but asnything is probably
better than looping endlessly.

format: the difference between ~A and ~S.

[Marius Vollmer]

Look at the following Guile behaviour:

guile> (format #t "~A\n" '("x"))
(x)
guile> (format #t "~S\n" '("x"))
("x")
guile> (use-modules (ice-9 format))
guile> (format #t "~A\n" '("x"))
("x")
#t
guile> (format #t "~S\n" '("x"))
("x")
#t
guile> 

I think it is wrong that the builtin format and the extended format
behave differently.  In my opinion, the builtin format is correct (and
agrees with Common Lisp format).

The problem with ice-9/format is that it doesn't pass its `slashify'
parameter when recursing to print the elements of a list.  It always
sets `slashify' to #t when recursing.

If nobody objects, I'll fix ice-9/format.scm to behave like the
builtin format.

Re: sig11 puts Guile in a loop

[Marius Vollmer]

Ole Myren Rohne <[EMAIL PROTECTED]> writes:

> I think which signals belong to "That *kind* of signals" should be
> application specific:
> 
> I use guile to interactively control a pci-to-vme bridge that gives
> SIGBUS in a lot of non-fatal situations: vme-crate is not switched
> on, no data available in fifo of a vme-card etc.

Hmm, can you try the recent change that I made?  I think it should
work for you as is (and Gule shouldn't work for you without this
change).

What happens when you ignore a SIGBUS?  Does the instruction that
caused the exception (like reading from an empty fifo register) get
re-executed?

Re: Typo in reference manual

[Marius Vollmer]

Eric Hanchrow <[EMAIL PROTECTED]> writes:

> All instances of `disble', above, should of course be changed to
> `disable'.

This has already been fixed in CVS.  Anyway: thanks!

Re: cvs guile on linuxppc 2000 and old sgi (irix 5.3)

[Marius Vollmer]

Mikael Djurfeldt <[EMAIL PROTECTED]> writes:

> Bill Schottstaedt <[EMAIL PROTECTED]> writes:
> 
> > on sgi irix 5.3, the new makefiles use a construct something
> > like DEPS_MAGIC... (line 551 of libguile/Makefile for example);
> > all of these cause a syntax error in this version of make.
> > If you need fuller details, let me know.
> 
> Yes please.  This is a problem with automake, but we'll forward it to
> the proper people.

If I remember correctly, automake requires GNU make when you are in
`developer mode'.  Only the destribution tarballs should be portable
across makes.  When you check out the sources out of CVS, you are in
`developer mode'.

Check "Automatic dependency tracking" in the automake documentation.

Re: Guile-1.3.5pre2 Dynamic linking looking for .la.la, .la.so files?

[Marius Vollmer]

"Greg J. Badros" <[EMAIL PROTECTED]> writes:

> open("./cassowary/libconstraints.la.la", O_RDONLY) = -1 ENOENT (No such file or 
>directory)
> open("./cassowary/libconstraints.la.so", O_RDONLY) = -1 ENOENT (No such file or 
>directory)
> 
> Any ideas what is going on in the last couple lines?

This probably happens because Guile now uses lt_dlopenext to load
shared libraries. lt_dlopenext tries some extensions on its own.

I'm in general not too happy with ltdl.  It is the right thing to use,
but it could take some improvements, which I'm too lazy to do...

Re: rl_pre_input_hook checked as code when it is data

[Marius Vollmer]

Marko Kohtala <[EMAIL PROTECTED]> writes:

> guile-readline/configure in guile-1.4 checks for rl_pre_input_hook in
> libreadline. However, it checks it as a function while it actually is a
> function pointer variable. This does not go through all linkers. I
> noticed this on HP-UX 10.20.

Can you check the attached patch to guile-readline/configure.in?  If
it works, I'll commit it to CVS.

> Btw. your page at http://www.gnu.org/software/guile/guile.html seems to
> lag behind.

Doesn't the whole web? ;)

Index: configure.in
===
RCS file: /cvs/guile/guile/guile-core/guile-readline/configure.in,v
retrieving revision 1.8
diff -c -r1.8 configure.in
*** configure.in2000/06/19 01:11:28 1.8
--- configure.in2000/07/17 19:11:32
***
*** 18,24 
AC_MSG_WARN([libreadline was not found on your system.])
  fi
  
! AC_CHECK_FUNCS(siginterrupt rl_clear_signals rl_cleanup_after_signal 
rl_pre_input_hook)
  
  
  AC_MSG_CHECKING(if readline clears SA_RESTART flag for SIGWINCH)
--- 18,44 
AC_MSG_WARN([libreadline was not found on your system.])
  fi
  
! AC_CHECK_FUNCS(siginterrupt rl_clear_signals rl_cleanup_after_signal)
! 
! dnl Check for rl_pre_input_hook.  This is more complicated because on
! dnl some systems (HP/UX), the linker wont let us treat
! dnl rl_pre_input_hook as a function when it really is a function
! dnl pointer.
! 
! AC_MSG_CHECKING([for rl_pre_input_hook])
! AC_CACHE_VAL(ac_cv_func_rl_pre_input_hook,
! [AC_TRY_LINK([
! #include 
! #include 
! ], [
! rl_pre_input_hook();
! ], eval "ac_cv_func_rl_pre_input_hook=yes", eval "ac_cv_func_rl_pre_input_hook=no")])
! if eval "test \"`echo '$ac_cv_func_'rl_pre_input_hook`\" = yes"; then
!   AC_MSG_RESULT(yes)
!   AC_DEFINE_UNQUOTED(HAVE_RL_PRE_INPUT_HOOK)
! else
!   AC_MSG_RESULT(no)
! fi
  
  
  AC_MSG_CHECKING(if readline clears SA_RESTART flag for SIGWINCH)

Re: Bug in scm_call_catching_errors

[Marius Vollmer]

Dirk Herrmann <[EMAIL PROTECTED]> writes:

> 1) Is this function used at all?  If not, we should deprecate it.

Make it deprecated, I say.

Re: segfault from backtrace of do () with unbound variable

[Marius Vollmer]

Bill Schottstaedt <[EMAIL PROTECTED]> writes:

> Backtrace:
> 0* [hi 2]
> 1  Segmentation fault (core dumped)

Fixed.  Thanks!

2000-07-17  Marius Vollmer  <[EMAIL PROTECTED]>

* eval.c (unmemocopy): Don't rely on V being a list of at least
one element.  Thanks to Bill Schottstaedt!

Re: Bug in assq/v/oc-remove! primitives (with patch)

[Marius Vollmer]

Neil Jerram <[EMAIL PROTECTED]> writes:

> I think I've found a bug in assq-remove! and friends.  My
> understanding is that
> 
> (assq/v/oc-remove! alist key1)
> 
> should remove all entries from the alist whose *key* is
> eq?/eqv?/equal? to key1.
> 
> In fact, with the current CVS implementation, the effect is to
> remove all entries where the *whole entry* (key . value) is
> eq?/eqv?/equal?  to the first entry whose key is eq?/eqv?/equal? to
> key1.

Thanks!  I have applied this.

The behaviour after your patch is certainly `more' right than before,
but I'm not sure if it is the most right behaviour.

I think you are supposed to consistently use assoc-set! with
assoc-remove!, for example, and assoc-set! will not produce two cells
with an equal key.  Thus, there is always at most one cell for
assoc-remove! to remove.  Therefore, it would make sense to define
assoc-remove! et al to only remove the first cell with an appropriate
key, which allows them to do less work.

Re: Bug in assq/v/oc-remove! primitives (with patch)

[Marius Vollmer]

Neil Jerram <[EMAIL PROTECTED]> writes:

> I agree.  Would you like a further patch for this, or will you just
> change the 3 "while"s back to "if"s?

Yep, I'll do the changes myself.  The final patch then looks like a
bug fix, where scm_delv_x and scm_delete_x is merely replaced by
scm_delq_x, right?

Re: Bug in assq/v/oc-remove! primitives (with patch)

[Marius Vollmer]

Mikael Djurfeldt <[EMAIL PROTECTED]> writes:

> I'm not up-to-date on what you're talking about, but since you mention
> removing *one* item, it seems like you should use scm_delq1_x instead
> of scm_delq_x.

Yep, right.  I though scm_delq_x would only remove one item.  Wasn't
that the case some time ago?  I think I remember writing my own
verison of delq! because delq! didn't remove all matching elements...

Re: Named let

[Marius Vollmer]

Keisuke Nishida <[EMAIL PROTECTED]> writes:

> Hello,
> 
> Is this a bug?
> 
>   % guile
>   guile> (let loop ((foo loop)) foo)
>   #
> 
> R5RS says  is bound within .

You did expect it to be bound _only_ in , not in the
initialization expressions of the , right?

According to the formal semantics in R5RS, the named let expression
above is equivalent to

(letrec ((loop (lambda (foo) foo))) (loop loop))

As you can see, the initialization expressions are evaluated in the
body of the `letrec', and `loop' is clearly bound there.

So I would say that your observation is not a bug.  You can get a more
`official' answer on comp.lang.scheme, probably.

Re: Missing headers in iselect.c

[Marius Vollmer]

Bertrand Petit <[EMAIL PROTECTED]> writes:

>   The file iselect.c does not include delcarations for the
> select system call in release 1.4 and CVS file version 1.22. The
> following three includes should be added:
> 
> #include 
> #include 
> #include 

Thanks for the report!  The header files  and
 are taken care of in the file "iselect.h" already.
 should be included, tho.

2000-08-05  Marius Vollmer  <[EMAIL PROTECTED]>

* iselect.c: Include .  Thanks to Bertrand Petit!

Re: Named let

[Marius Vollmer]

Marius Vollmer <[EMAIL PROTECTED]> writes:

> Keisuke Nishida <[EMAIL PROTECTED]> writes:
> 
> > Hello,
> > 
> > Is this a bug?
> > 
> >   % guile
> >   guile> (let loop ((foo loop)) foo)
> >   #
> > 
> > R5RS says  is bound within .
> 
> [rubish]

Sorry, I did not look close enough what R5RS _really_ said.  The
correct expansion of the above expression is

((letrec ((loop (lambda (foo) foo))) loop) loop)

So Guile's behaviour is a bug.  I'll investigate it.

Re: bug in modules?

[Marius Vollmer]

[ Please post bug reports to <[EMAIL PROTECTED]>. ]

Ivan Toshkov <[EMAIL PROTECTED]> writes:

> Here is the test module, with missing closing paren:
> 
> ---
> (define-module (test))
> 
> (define (some-buggy-proc a)
>   a
> 
> ---
> 
> $ guile
> guile> (version)
> "1.4"
> guile> (use-modules (test))
> ERROR: In procedure list:
> ERROR: end of file in

I think the most useful thing to add here is the name of the file that
has the premature end.  This name might not be apparent when loading
modules.  I have done this.

> ABORT: (misc-error)
> guile> (use-modules (test))

It is a consequence of how the module system works that you do not
receive a second error message here.  The module is already loaded
(although not completely) and it will not be loaded again when you
request it another time.

One error message should be enough, I think.

Re: set-procedure-property! doesn't do proper type check on first arg

[Marius Vollmer]

Mikael Djurfeldt <[EMAIL PROTECTED]> writes:

> set-procedure-property! doesn't do proper type check on first arg

Incidentally, I'm in favour of unifying object and procedure
properties.  That is, there would be only object properties, and the
`object-property' functions can be used to access them, including on
procedures, which would be nothing special.

Underneath, procedures would store their properties directly, while
other objects might have to use a global hash table.  The
`object-property' functions would hide this implememtation detail from
the user.

The `procedure-property' functions could be seen as optimized
accessors that work only on procedures, but faster.  However, they
might not really be faster since they have to check the type of their
argument anyway.

Looking closer into procprops.c, I would say that unifying procedure
and object properties would be an improvement anyway, because we could
remove that scm_stand_in_scm_proc ickyness.

ObBUG: set-procedure-properties! does the same wrong thing.  Are you
going to fix it, Mikael?

Re: Problem with current validate macros

[Marius Vollmer]

Mikael Djurfeldt <[EMAIL PROTECTED]> writes:

> If we could, somehow, store the signature with the primitives, and
> look it up at errors, that would be even better.

Isn't that information contained in the online docs?

Re: allow-other-keys typo in optargs.scm

[Marius Vollmer]

Bill Schottstaedt <[EMAIL PROTECTED]> writes:

> I think the line (209 in optargs.scm)
> 
>   ((allow-other-keys) #:allow-other-keys-value)
> 
> should be
> 
>   ((allow-other-keys) #:allow-other-keys)

Thanks!  I fixed this.

> Also, as I'm sure you guys know already (I'm not on this
> mailing list), (use-modules (ice-9 syncase)) dies in the
> current guile with a segfault.

Hmm, it works for me.  Can you try the latest CVS version and give
detailed instructions to make it crash?

Re: allow-other-keys typo in optargs.scm

[Marius Vollmer]

Bill Schottstaedt <[EMAIL PROTECTED]> writes:

> > > Also, as I'm sure you guys know already (I'm not on this
> > > mailing list), (use-modules (ice-9 syncase)) dies in the
> > > current guile with a segfault.
> >
> > Hmm, it works for me.  Can you try the latest CVS version and give
> > detailed instructions to make it crash?
> 
> Yesterday's version works fine -- I don't know what the
> problem was over the weekend.

OK!  Thanks for reporting this, anyway.

[Bug-guile] Re: Numerical (parser?) bug

[Marius Vollmer]

"Ivan Toshkov" <[EMAIL PROTECTED]> writes:

> $ uname -psmr
> Linux 2.2.14-5.0 i686 unknown
> $ guile
> guile> (version)
> "1.4.1"
> guile> 5e-308
> 5.0e-308
> guile> 5e-309
> ERROR: In expression 5e-309:
> ERROR: Unbound variable: 5e-309
> ABORT: (unbound-variable)
> 
> Type "(backtrace)" to get more information or "(debug)" to enter the debugger.
> guile> 

Yes, I think it's a bug.  The number reading code is trying to be too
clever in my opinion.  I'll look into this more fully...
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: [Bug-guile] Generated files in cvs

[Marius Vollmer]

"Dale P. Smith" <[EMAIL PROTECTED]> writes:

> Not a big thing, but if guile-core was cleaned up, other modules
> should be cleaned up too.

Yep, right.  I'll look into this.


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: eq? and friends accept more than two parameters

[Marius Vollmer]

Dirk Herrmann <[EMAIL PROTECTED]> writes:

> If I understand R5RS correctly, then eq?, eqv? and equal? should
> accept exactly two parameters.  The current CVS guile, however,
> accepts more parameters as well.  On the one hand, this seems to be
> a sensible extension, but it should somehow be possible to be
> strictly R5RS compliant.

Yep, please change them to be R5RS compliant, but leave the current
code in there (commented out).  We might want to reactivate it when
we can select to be pure R5RS.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: C++ reserved words in header files

[Marius Vollmer]

Martin Baulig <[EMAIL PROTECTED]> writes:

> please don't use C++ reserved words such as `destructor' in
> installed header files; I'm using GNU C 2.95.2 on Debian woody
> and I got a syntax error in line 200 in coop-defs.h because of
> this.

Can you prepare a patch that covers all instances of this problem?  If
it is just the single occurence in coop-defs.h just say so.

Thanks!


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: C++ reserved words in header files

[Marius Vollmer]

Martin Baulig <[EMAIL PROTECTED]> writes:

> > Can you prepare a patch that covers all instances of this problem?  If
> > it is just the single occurence in coop-defs.h just say so.
> 
> I think it is; at least that was the only place I got an error message
> and running grep over all header files also didn't give me any other
> place.

Ok, fixed.  Thanks!

2000-10-02  Marius Vollmer  <[EMAIL PROTECTED]>

* coop-defs.h (coop_key_create): Don't use the C++ keyword
`destructor' in prototype.  Thanks to Martin Baulig!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: [Patch] Install guile-procedures.txt in version-specific directory

[Marius Vollmer]

Matthias Koeppe <[EMAIL PROTECTED]> writes:

> 2000-10-28  Matthias Koeppe  <[EMAIL PROTECTED]>
> 
>   * Makefile.am: Install guile-procedures.txt in version-specific
>   directory to enable multiple installed guile versions.
>   Suggested by Karl M. Hegbloom <[EMAIL PROTECTED]>.

Applied!  (After I professionally waited quite some time for any
objections... ;-)

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Doc patches

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> I have looked through the top-level doc files of guile-core, mainly to
> correct references to CVS repository locations, mailing lists etc.,
> and corrected everything I found.

Thanks!  I have applied your patch.

Mikael, since you know the most about lsh, can you update HACKING to
talk about lsh instead of ssh?

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: display-error segmentation fault

[Marius Vollmer]

Neil Jerram <[EMAIL PROTECTED]> writes:

> This is with a current CVS Guile (on a GNU/Linux system).
> 
> [neil@ossau neil]$ guile
> guile> (display-error #f #f #f #f #f #f)
> Segmentation fault (core dumped)
> [neil@ossau neil]$ 
> 
> The problem arises because scm_display_error does not check that its
> port argument actually is a port.

I think there is little reason why display-error should not check its
arguments like every other function.  We have to be careful to not
generate an infinite loop when trying to signal an error from within
the error reporting machinery.  Aborting is probably OK, but in a more
controlled way than waiting for the segv.


Anyone interested in fixing this?

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Guile webpages [still] unreadable

[Marius Vollmer]

I think we already have discovered this, right?  But it looks like we
didn't fix it.  What's the procedure for getting the Web pages
changed?




Subject: [[EMAIL PROTECTED]: Guile webpages unreadable]
bcc: [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
--text follows this line--
Please DTRT.

--- Start of forwarded message ---
Sender: [EMAIL PROTECTED]
Date: Fri, 19 Jan 2001 16:17:06 +0100
From: =3D?iso-8859-1?Q?=3DD6rjan?=3D Ekeberg <[EMAIL PROTECTED]>
Organization: Royal Institute of Technology, Stockholm
X-Accept-Language: sv, en
To: [EMAIL PROTECTED]
Subject: Guile webpages unreadable
Content-Type: multipart/mixed;
 boundary=3D"F0F35C80DD152AC1E1F7592F"
Content-Length: 1609

This is a multi-part message in MIME format.
- --F0F35C80DD152AC1E1F7592F
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit

Hello,

This is a bug-report regarding the (otherwise excellent) web pages for
Guile, i.e.

http://www.gnu.org/software/guile/*

All the pages I have looked at there specifies the background color
(bgcolor) to #FFF
which is an illegal value!  Note that there are seven F's.  I presume
that the background is
supposed to be white, i.e. #FF.

Netscape seems to fall back to some default color which makes the page
readable.
Konqueror (the free web browser in KDE), however, replaces the erroneous
value with zero
which happens to mean black.  Black text on a black background is, of
course, unreadable.
It took me a while to find the reason behind this strange behavior.

To fix this bug, simply replace all "bgcolor=3D#FFF" with
"bgcolor=3D#FF"
in the Guile pages.

/Orjan


- --F0F35C80DD152AC1E1F7592F
Content-Type: text/x-vcard; charset=3Dus-ascii;
 name=3D"orjan.vcf"
Content-Description: Card for =D6rjan Ekeberg
Content-Disposition: attachment;
 filename=3D"orjan.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard=20
tel;fax:+46 8 790 0930
tel;work:+46 8 790 6901
x-mozilla-html:FALSE
fn;quoted-printable:=3DD6rjan Ekeberg
org:Royal Institute of Technology;Numerical Analysis and Computer Scien=
ce
n;quoted-printable:Ekeberg;=3DD6rjan
version:2.1
email;internet:[EMAIL PROTECTED]
title:Assoc Prof.
adr;quoted-printable:;;Nada=3D0D=3D0AKTH;Stockholm;;10044;Sweden
x-mozilla-cpt:;11808
end:vcard

- --F0F35C80DD152AC1E1F7592F--
--- End of forwarded message ---

Re: Guile webpages [still] unreadable

[Marius Vollmer]

thi <[EMAIL PROTECTED]> writes:

> ... ok, fixed.  (find-grep-dired for "FFF" (seven Fs) is clean.)

Thanks!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: cvs smob doc update

[Marius Vollmer]

"Dale P. Smith" <[EMAIL PROTECTED]> writes:

> Here is a patch that uses SCM_SMOB_DATA instead of SCM_CDR.  Also things
> like SCM_SMOB_PREDICATE and SCM_NEWSMOB.

Thanks, applied!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: make-vector/vector-length disagree for large vectors.

[Marius Vollmer]

Dirk Herrmann <[EMAIL PROTECTED]> writes:

> The bug with the missing boundary checking is easy to fix.  Whether
> vectors should be changed to allow for more than 2^24 elements is up to
> the maintainers.

Allowing only 2^24 elements is OK, but the boundary check should be
correct, of course.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Properly handling smobs in macros.c

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> Hi all,
> 
> this is not really a bug, but I think the attached change should be
> made for the sake of consistency.
> 
> 2001-02-08  Martin Grabmueller  <[EMAIL PROTECTED]>
> 
>   * macros.c (scm_macro_name, scm_macro_transformer): Use
>   SCM_SMOB_DATA instead of SCM_CDR.

Thanks!  (I have applied this locally, but not yet comitted because of
the papers...)

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile compile error

[Marius Vollmer]

"Rigel" <[EMAIL PROTECTED]> writes:

> Running RH7 on i586.  got a compile error from standard make:
> net_db.c:85: conflicting types for `inet_aton'
> /usr/include/arpa/inet.h:69: previous declaration of `inet_aton'
> make[1]: *** [net_db.lo] Error 1
> make[1]: Leaving directory `/usr/local/src/guile-1.4/libguile'
> make: *** [all-recursive] Error 1
> 
> I merely commented out the definition for inet_aton in net_db.c and
> it seems to compile now.

What does configure say about inet_aton?  Normally, when your system
has inet_aton (RH should have it), the prototype in net_db.c should
not be processed.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Trying to get guile-oops to compile on rh7

[Marius Vollmer]

[EMAIL PROTECTED] writes:

> I can not get either cvs guile-oops or guile-oops-0.1.8.tar.gz
> to compile on this machine.

Guile-oops has been integrated into guile-core, so I don't think you
need to compile guile-oops with cvs guile-core.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: cond

[Marius Vollmer]

Helmut Eller <[EMAIL PROTECTED]> writes:

> I get a segmentation fault for the following (incorrect) program: 
> 
>  (cond (1 => (lambda (x y) y)))
> 
> I observed this for guile 1.3, guile 1.4 and the cvs version (updated
> today).  Stacktrace follows.

Thanks for the bug report!  This should be fixed in CVS now.

2001-02-21  Marius Vollmer  <[EMAIL PROTECTED]>

* eval.c (scm_ceval, scm_deval): Check for wrong number of args
before applying arrow procedure in `cond' and before applying
receiver procedure in call-with-current-continuation.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Guile 1.4 compilation bugs (and patches) under Cray UnicosMk

[Marius Vollmer]

"Steven G. Johnson" <[EMAIL PROTECTED]> writes:

> !   SCM_BIGDIG zdigs [SCM_DIGSPERLONG];

Fixed, thanks!

> ! #include 

This has already been fixed in CVS previously.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: coredump in Guile 1.4 on Cray T3E

[Marius Vollmer]

"Steven G. Johnson" <[EMAIL PROTECTED]> writes:

> Compiling it with -g and running it under Cray's TotalView debugger
> (ugh), I get the stack trace attached below.  The Guile code at this
> point is a little hairy, and I'm not entirely sure what is going on.
> Can someone suggest something to look at or try?  Let me know if you
> want any more info.

Hmm, I'd suggest to try the latest version from CVS if you can do
that.  There might already be some fixes in there.

Other than that, assuming that your debugger gives accurate
information, you would need to pin down exactly why the process
receives the signal.  What is the value of `x' and why doesn't
SCM_STRUCT_VTABLE_DATA succeed.  After we know that, we can try to
find out what has gone wrong.  The `structs' of Guile are hairy...

> PEs 0: signal SIGORE (Operand range error) in scm_ceval at line 2505 in
> file "eval.c"
> 2505 *scm_bits_t vcell = SCM_STRUCT_VTABLE_DATA (x)
> [scm_vtable_index_vcell];

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Guile 1.4 compilation bugs (and patches) under Cray UnicosMk

[Marius Vollmer]

"Steven G. Johnson" <[EMAIL PROTECTED]> writes:

> Thanks; it looks like you only applied half of the patch, though.

Oops. sorry.  I should make it a habit to use "emerge" even for small
patches...

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Guile problem

[Marius Vollmer]

<[EMAIL PROTECTED]> writes:

> Is there any solution for this problem? I really needed to compile
> those programs and start working with them (otherwise I will have to
> go back to Windows - blaargh)

I think you will be better off to asking the authors of the other
packages (snd, lilypond, etc) for help.  The problem seems to be with
the way they look for Guile.

Independent from that, does Guile work for you on its own?  That is,
can you run "guile" and get a prompt?  What does

$ guile-config info

print?

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: duplicate bindings in let*

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> > perhaps caused by the two "flags" in build-link?
> 
> Correct, but the bug is not in let*, but in guile-config.  Recently,
> let* was changed to detect this error.

No, no, no.  `let*' can tolreate duplicate bindings.  I just wasn't
thinking clearly when fixing `let' to detect duplicate bindings and
made `let*' do the checking as well.

Mikael already found my duplicate bug fix and fixed it.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Problem with __USE_XOPEN

[Marius Vollmer]

Keisuke Nishida <[EMAIL PROTECTED]> writes:

> What would be the best solution?

We should add

#define _GNU_SOURCE

at the top of "posix.c".  __USE_XOPEN is the wrong macro to use, it
should be one of the _FOO_SOURCE macros.  _GNU_SOURCE is the catch all
and might be too broad, but _POSIX_SOURCE didn't work and I didn't
feel like prodding further.

I'll commit the fix any minute.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Missing declaration of `scm_debug_check_freelist'

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> I suppose it's just a 
> 
>   static int scm_debug_check_freelist = 0;
> 
> missing, but maybe someone else kows more about it.

I don't.  Please do what you think is the Right Thing.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: ./check-guile: test: argument expected

[Marius Vollmer]

Alexander Klimov <[EMAIL PROTECTED]> writes:

> Hi.
> 
> According to `man test' on Solaris 2.6 there is no `-e' primitive for sh,
> but only for ksh. It also exists in bash.
> 
> There is an error in check-guile:36
> 
> if [ ! -e guile-procedures.txt ]; then
>   ^^^
> which produces the error message shown in subject. The line should be
> substituted with 
> if [ ! -f guile-procedures.txt ]; then

The problem with -f is that it checks for a regular file, while
guile-procedures.txt will be a symlink when it exists.  Would

  if [ ! -f guile-procedures.txt -a ! -h guile-procedures.txt ]; then

work?

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: ./check-guile: test: argument expected

[Marius Vollmer]

Alexander Klimov <[EMAIL PROTECTED]> writes:

> Actully, documentation said that all commands follow simbolic links, so
> `-f' means that after it resolve symbolic links it found `regular file'.

Ahh, I see.  Sorry for not checking more thoroughly.  "-f" is the way
to go, then.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Strange error message for (apply car '())

[Marius Vollmer]

Hi,

this looks wrong:

guile> (apply car '())
ERROR: In procedure cdr:
ERROR: Wrong type argument in position 1: #

(I think I'm going to fix this myself.)

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-oops 1.0.2 won't configure on DU 4.0

[Marius Vollmer]

Alexandre Oliva <[EMAIL PROTECTED]> writes:

> The configure script contains a test command using the `==' operator.
> `==' is not portable.  Please change that to `='.  Thanks,

Please be more specific.  I can't find a test command using "==" in
configure.in.  The only occurences of "==" that I can find are in C
code.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-oops 1.0.2 won't configure on DU 4.0

[Marius Vollmer]

Alexandre Oliva <[EMAIL PROTECTED]> writes:

> On Mar 30, 2001, Marius Vollmer <[EMAIL PROTECTED]> wrote:
> 
> > Alexandre Oliva <[EMAIL PROTECTED]> writes:
> >> The configure script contains a test command using the `==' operator.
> >> `==' is not portable.  Please change that to `='.  Thanks,
> 
> > Please be more specific.  I can't find a test command using "==" in
> > configure.in.  The only occurences of "==" that I can find are in C
> > code.
> 
> configure.in, line 29:

Whoops, sorry, I had an old version of guile-oops.  Thanks!

2001-03-30  Marius Vollmer  <[EMAIL PROTECTED]>

* configure.in: Do not use "==" in test command, this is not
portable.  Thanks to Alexandre Oliva!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Vectors should not evaluate to themselves

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> But that's just a theory, which is by me and is completely mine...

:-)

Presenter: You have a new theory about the vector?

Martin: Can I just say here Chris that I have a new theory about the
   vector.

P: Exactly. (He gestures but Martin does not say anything).  What is it?

M: Where? (looks round)

P: No, no your new theory.

M: Oh, what is my theory.

P: Yes.

M: Oh what is my theory that it is.  Well Chris you may well ask me
   what is my theory.

P: I _am_ asking.

M: Good for you.  My word yes.  Well Chris, what is it that it is --
   this theory of mine.  Well this is what it is -- my theory that I
   have, that is to say, which is mine, is mine.

P: (beginning to show signs of exaspiration) Yes, I know it's yours,
   what is it?

M: Where?  Oh, what is my theory?  This is it. (clears throat at some
   length) My theory that belongs to my is as follows (clears throat
   at great length) This is how it goes.  The next thing I'm going to
   say is my theory.  Ready?

P: Yes.

M: My theory by M. Elk.  Brackets Sir, brackets.  This theory goes as
   follows and begins now.  Vectors are just like lists only they have
   a longer name and the names of their accessors are not the least
   weird.  That is my theory, it is mine, and belongs to me and I own
   it, and what it is too.

P: That's _it_, is it?

M: Spot on, Chris.

P: Well, er, this theory of yours appears to have hit the nail on the
   head.

M: And it's mine.

P: Yes, thank you very much for coming along the list.  Thank you.

M: My pleasure Chris...

P: Next week Guile's newest rats nest...

M: It's been a lot of fun.

P: Yes, thank you very much.

M: Saying what my theory is.

P: Yes, thank you.

M: And whose it is.

P: Yes, thank you -- that's all -- thank you  collapses next week.

M: I have another theory.

P: Yes.

M: Called my second theory, or my theory number two.

P: Thank you.  Guile's newest rats nest...

M: This second theory which was the one that I had said...

P: (the phone rings; he answers) Yes, no I'm trying...

M: Which I could expound without doubt.  This second theory which,
   with the one which I have said, forms the brace of theories which I
   own and which belong to me, goes like this...

   ...

[ Sorry folks.  So that nobody says we don't know our Python on the
  Guile lists. ]

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: numeric tests

[Marius Vollmer]

Bill Schottstaedt <[EMAIL PROTECTED]> writes:

> In case there's interest (some of the tests are a bit nutty),
> the file is at ccrma-ftp.stanford.edu/pub/Lisp/number-tests.scm.

Thanks!  I'll look into this.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Segfault connected with taking class-of memoized code?

[Marius Vollmer]

Neil Jerram <[EMAIL PROTECTED]> writes:

> > "Neil" == Neil Jerram <[EMAIL PROTECTED]> writes:
> 
> Neil> [...]
> Neil> debug> evaluate (class-of exp)
> Neil> Segmentation fault
> 
> A much simpler example is this:
> 
> neil@laruns:~$ guile -q
> guile> (class-of class-of)
> Segmentation fault
> neil@laruns:~$ 

This happens when you don't have loaded all of Goops yet.  A quick fix
is to `(use-modules (oop goops))', then class-of will magically start
to work.

I'll look into a real fix.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: values.h missing in libguile.h

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> I assume it is just a small mistake that values.h is not included in
> libguile.h, but I ask anyway because maybe the `multiple values C API'
> was only experimental.  If it is okay, I will add it.

It's OK!  Thanks!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: shell scripts in CVS source don't have runable permission

[Marius Vollmer]

Masao Uebayashi <[EMAIL PROTECTED]> writes:

> These have to have '0755' so that autogen.sh can run properly.

Is that a real problem in practice?  I think when you chmod them once,
CVS will keep the permissions across updates.  On the other hand, I'm
not sure that CVS will keep the permissions correctly in its
repository.

Hmm, do we have a residual CVS guru?  Jim?

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: CVS guile + module system broken

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> Hello list,
> 
> mgrabmue@tortoise (~/cvs/guile/x/guile-1.4.1/libguile): 
>GUILE_LOAD_PATH=~/cvs/guile/x/guile-1.4.1/ ./guile
> ERROR: In procedure set-current-module:
> ERROR: Wrong type argument in position 1: #f
> 
> 
> Is this because `set-current-module' and `current-module' are
> currently defined twice? (in boot-9.scm and modules.c)

Madre mia, I forgot to check in my changes to boot-9.scm!  Please try
again.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: GUILE_WARN_DEPRECATED_DEFAULT missing?

[Marius Vollmer]

Bill Schottstaedt <[EMAIL PROTECTED]> writes:

> I think this macro is missing from the CVS
> guile-core/libguile/deprecation.h.

No, it is supposed to be defined in "libguile/scmconfig.h".  You
probably didn't pick up the change yet in your build setup.  Try
rerunning "autogen.sh", "configure", etc.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Problems compiling guile on a Cobalt mips (qube 2)

[Marius Vollmer]

"Dale P. Smith" <[EMAIL PROTECTED]> writes:

> #2  0x2ad30308 in __libc_realloc (oldmem=0x2adde954, bytes=18000)
> at malloc.c:3097
> #3  0x2aafb028 in scm_must_realloc (where=0x100260b8, old_size=12000,
> size=18000, what=0x2aac93f0 "scm_subr_table") at gc.c:1931

This looks suspicious.  Compare OLDMEM with WHERE.  They should be
identical, shouldn't they?  (Well, __libc_realloc could have changed
the place where OLDMEM is stored...)

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: `-' and zero arguments

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

>  guile> (/)
>  :2:1: In procedure / in expression (/):
>  :2:1: Wrong type argument in position 1: #
>  ABORT: (wrong-type-arg)
> 
> I am not sure how to fix this, because of the generic function
> dispatch stuff.  Should there be a dispatch for a wrong number of
> arguments too, or just a call to SCM_WRONG_NUM_ARGS?

I fixed this by making SCM_WTA_DISPATCH_0 signal a `wrong num args'
error when the generic function hasn't been initialized yet.  I think
this is the right thing to do.

What I'm not sure about is: should we allow generic functions or
methods with zero arguments?  Is that useful?  You can have exactly
one method for the zero argument case.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: extra_dot_x_files in configure.in?

[Marius Vollmer]

Bill Schottstaedt <[EMAIL PROTECTED]> writes:

> I'm not sure that my copy of CVS guile-core/configure.in is actually
> up-to-date, but I think it needs something like:
> 
> EXTRA_DOT_X_FILES="`echo ${LIBOBJS} | sed 's/\.o/.x/g'`"
> 
> after the similar line for EXTRA_DOT_DOC_FILES, and the
> corresponding
> 
> AC_SUBST(EXTRA_DOT_X_FILES)
> 
> Or is this set somewhere further up the chain?

EXTRA_DOT_X_FILES should be there since

2001-03-17  Gary Houston  <[EMAIL PROTECTED]>

* configure.in: don't append threads.doc to EXTRA_DOT_DOC_FILES,
since EXTRA_DOT_DOC_FILES is redefined later.  define
EXTRA_DOT_X_FILES and hand it to AC_SUBST.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Guile (Developing and Contributing)

[Marius Vollmer]

Quetzalcoatl Bradley <[EMAIL PROTECTED]> writes:

> Repeatable bus error on MacOS X 10.0.2 with guile-1.4

Same on GNU/Linux (segfault instead of bus error, tho).

Thanks!

2001-05-10  Marius Vollmer  <[EMAIL PROTECTED]>

* ports.c (scm_port_revealed, scm_set_port_revealed_x): Only
accept open ports.  Thanks to Quetzalcoatl Bradley!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-1.3 ported to mips-compaq-nonstopux

[Marius Vollmer]

Tom Bates <[EMAIL PROTECTED]> writes:

> Just a note to say I've ported guile-1.3 to mips-compaq-nonstopux.
> I had to make some changes though.

Great!  To get your changes into mainstream Guile, you would have to
port the current CVS version and send us patches.  If the patches are
significant, we would also need some paper work from you so that we
can distribute your work.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: use-modules does not signal error on non-existing modules

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> Hello list,
> 
> I suppose this is related to the recent module system changes:
> 
> mgrabmue@tortoise (~/cvs/guile/guile-core/libguile): 
>GUILE_LOAD_PATH=/home/mgrabmue/cvs/guile/guile-core ./guile
> guile> (use-modules (definitely not installed module))
> guile> (use-modules (please signal a file-not-found error or something else))
> guile> 

Right, Guile used to issue a "no such module" error.  It doesn't
becvause `resolve-interface' construct a interface when the module
doesn't already have one.  I think the whole logic how it is decided
whether a module exists or not could need some clean up.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: `-' and zero arguments

[Marius Vollmer]

Dirk Herrmann <[EMAIL PROTECTED]> writes:

> [zero argument methods]
>
> It's not usefull, right.  But, does it do any harm?

I don't know.  Let's just leave it as it is.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: CVS Guile is core dumping

[Marius Vollmer]

Ariel Rios <[EMAIL PROTECTED]> writes:

> (gdb) run
> Starting program: /usr/local/bin/guile 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xff794f0 in scm_hash_fn_create_handle_x () at ../libguile/hashtab.x:21
> 21scm_make_gsubr (s_scm_hash_fold ,   3 ,   0 ,   0 , (SCM (*)()
> )
> scm_hash_fold );

Yes, this is known already.  The fix is to remove
"libguile/cpp_err_symbols.c" and "libguile/cpp_sig_symbols.c"


I'll annouce this more widely and check in a fix.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: gentemp deprecation

[Marius Vollmer]

"Dale P. Smith" <[EMAIL PROTECTED]> writes:

> gentemp is being deprecated, but is still used all over the
> place. Well, it's used in expect.scm, match.scm, psyntax.pp and
> psyntax.ss.  These should probably all be changed to use gensym
> instead.

Yes, thanks!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Uninterned symbols

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> > From: "Dale P. Smith" <[EMAIL PROTECTED]>
> >
> > BTW: gensym does not return unique symbols:
> > [...]
> > Wasn't this fixed a while back?  Or was that gentemp?
> 
> Well, it was noticed a while ago, but AFAICT, nobody fixed it.  I
> wanted to wait for Marius vcell patch, which affected symbols as
> well.

Yeah, I wanted to fix it along the way, but I didn't since there were
some open questions.

> The problem is that I can not imagine a way to safely create unique
> symbols, since the only functions left for creating symbols are
> 
>   extern SCM scm_mem2symbol (const char*, scm_sizet);
>   extern SCM scm_str2symbol (const char*);
> 
> which both enter the symbol into the global symbol hash table.  So it
> is always possible to create symbols (i.e. with string->symbol) eq? to
> symbols returned by gensym.  Can anyone else think of a solution here?

The canonical solution is to have uninterned symbols, i.e. symbols
that are not in the global hash table.

They are easy to provide, but we should also think about printing and
reading uninterned symbols then.  I think it's OK to print uninterned
symbols somewhat specially (and readably) and use the mechanism for
printing shared structure to identify `eq' uninterned symbols.

(Incidentally, can `read' cope with shared structures?  It doesn't
look like it can.  Things like `#0#' conflict with the array syntax
since the hash extension don't deal with e general number prefix.  One
more thing to fix...)

What about using some variant of #{...}# to print uninterned symbols?
Would be people feel comfortable about changing it incompatibly?  Or
should we invent a new hash dispatch, like `#~unique'?  Or a new
syntax altogether?

(The uninternedness of a symbol can be flagged by one bit of its
hashing value).

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Missing paren in goops.scm

[Marius Vollmer]

Oops.  The shame.  It's fixed.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Build probs under Solaris

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> I have just tried to build a fresh CVS Guile under Solaris, but got no
> luck.  After updating and a make clean, autogen.sh gave the following
> warnings:

This might be because we have removed the copy of libtool.m4 from
acinclude.m4.  Now aclocal needs to find the right libtool.m4 on your
box.  aclocal only looks into /share/aclocal, where 
is the installation `--prefix' of autoconf.  A common problem is that
aclocal looks into /usr/share/aclocal while third-party autoconf
macros are installed in /usr/local/share/aclocal.  You might want to
check this.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: (use-syntax (ice-9 syncase)) broke with --disable-deprecated

[Marius Vollmer]

"Dale P. Smith" <[EMAIL PROTECTED]> writes:

> guile> (use-syntax (ice-9 syncase))
> 
> : While evaluating arguments to fluid-set! in expression
> (fluid-set! scm:eval-transformer (module-transformer #)):
> : Unbound variable: scm:eval-transformer
> ABORT: (unbound-variable)

Thanks!  Fixed.  I even wrote a test-case...

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: awk portability

[Marius Vollmer]

"Golubev I. N." <[EMAIL PROTECTED]> writes:

> To allow guile work with native awk it needs at least one patch.

We already have a fix for SCO nawk in CVS.  Does it help?

2000-10-02  Michael Livshin  <[EMAIL PROTECTED]>

* guile-func-name-check.in: now should not confuse SCO nawk
anymore.  thanks to Bruce Korb for the fix!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: awk portability

[Marius Vollmer]

Michael Livshin <[EMAIL PROTECTED]> writes:

> looks like the awk script should be replaced as soon as possible...

Ok, and all of them, I suppose.  I would like it if they could be
replaced with Guile programs, even if that means a slightly more
contorted build procedure.  I don't have agood overview of what runs
when, but we only need guile-snarf (which doesn't use awk) to build
Guile, right?  The rest is for snarfing the docs, etc, which can be
done with the just built guile.  I hope.

That's also something for the after-1.6.0 boredom, I'd say.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: awk portability

[Marius Vollmer]

"Golubev I. N." <[EMAIL PROTECTED]> writes:

> But why do not I see this change neither in snapshot in
> 
> nor in `:pserver:anoncvs@source{ware.cygnus,s.redhat}.com:/cvs/guile'
> (which snapshot seems to be derived from)?

These are outdated places.  Please go to

http://savannah.gnu.org/projects/guile

for uptodate information.  Guile moved around a bit recently...

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: outdated places/Re: awk portability

[Marius Vollmer]

"Golubev I. N." <[EMAIL PROTECTED]> writes:

> > http://savannah.gnu.org/projects/guile
> 
> It does not contain `snapshot' word at all, but refers to
>  which still refers to
> .

Yes, I know, sorry.  Savannah has instructions for getting the latest
sources via anonymous CVS.

Snapshots are on www.glug.org and I hope to fix the html soon.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: !have mkstemp

[Marius Vollmer]

"Golubev I. N." <[EMAIL PROTECTED]> writes:

> Since `mkstemp' implementation should be highly portable (require
> nothing beyond posix), it may be reasonable to take one from gnu libc
> and do AC_REPLACE_FUNC.

I did that.  Please test.  Thanks!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: hash.c:101: pointers are not permitted as case values

[Marius Vollmer]

Alexander Klimov <[EMAIL PROTECTED]> writes:

> > If that helps, we will use that fix.
> Yes, the following patch solves the problem

Thanks!  Applied.

2001-06-05  Marius Vollmer  <[EMAIL PROTECTED]>

* hash.c (scm_hasher): Use SCM_UNPACK in the case labels so that
non-pointers are being compared.  Thanks to Alexander Klimov!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: scm_hash_fn_create_handle_x?

[Marius Vollmer]

Masao Uebayashi <[EMAIL PROTECTED]> writes:

> I can avoid core dump by the following patch.
> This is not the best way, though.

The reason Guile dumps core is that it wants to output a deprecation
warning at a time when the deprecation mechanism has not been
initialized yet.  It tried to output that warning because a
automatically generated file hadn't been brought uptodate in your
sources yet, and was still using a deprecated function.

What we could do is abort more cleanly in that case.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: scm_hash_fn_create_handle_x?

[Marius Vollmer]

Masao Uebayashi <[EMAIL PROTECTED]> writes:

> % gmake
>  :
> (snip)
>  :
> Segmentation fault - core dumped

I recognize this.  Remove libguile/cpp_err_symbols.c and
libguile/cpp_sig_symbols.c and rebuild.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Bug in find-and-link-dynamic-module

[Marius Vollmer]

Thomas Wawrzinek <[EMAIL PROTECTED]> writes:

> When playing around with dynamically loadable modules written in
> pure C I found that on my Linux box guile tries to access weirdly
> named libraries (that do not exist), like libfoo.la.la or
> libfoo.so.la.

That code has been deprecated recently.  Does it cause real problems
for you?  If not, I'd rather not touch it.


What you should be doing instead is this (from NEWS):

** New concept of `Guile Extensions'.

A Guile Extension is just a ordinary shared library that can be linked
at run-time.  We found it advantageous to give this simple concept a
dedicated name to distinguish the issues related to shared libraries
from the issues related to the module system.

*** New function: load-extension

Executing (load-extension lib init) is mostly equivalent to

   (dynamic-call init (dynamic-link lib))

except when scm_register_extension has been called previously.
Whenever appropriate, you should use `load-extension' instead of
dynamic-link and dynamic-call.

*** New C function: scm_c_register_extension

This function registers a initialization function for use by
`load-extension'.  Use it when you don't want specific extensions to
be loaded as shared libraries (for example on platforms that don't
support dynamic linking).

** Auto-loading of compiled-code modules is deprecated.

Guile used to be able to automatically find and link a shared
library to satisfy requests for a module.  For example, the module
`(foo bar)' could be implemented by placing a shared library named
"foo/libbar.so" (or with a different extension) in a directory on the
load path of Guile.

This has been found to be too tricky, and is no longer supported.  The
shared libraries are now called "extensions".  You should now write a
small Scheme file that calls `load-extension' to load the shared
library and initialize it explicitely.

The shared libraries themselves should be installed in the usual
places for shared libraries, with names like "libguile-foo-bar".

For example, place this into a file "foo/bar.scm"

(define-module (foo bar))

(load-extension "libguile-foo-bar" "foobar_init")


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: CVS guile does not build

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> after the latest type renaming, Guile does not build anymore for me:

Fixed!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Problems building guile-readline

[Marius Vollmer]

"Dale P. Smith" <[EMAIL PROTECTED]> writes:

> configure: configuring in guile-readline
> configure: running /bin/sh './configure'  --disable-deprecated
> --with-gnu-ld --disable-static --enable-ltdl-convenience
> --cache-file=/dev/null --srcdir=.
> ./configure: line 893: syntax error near unexpected token
> `AM_INIT_AUTOMAKE($PACKAGE,'
> ./configure: line 893: `AM_INIT_AUTOMAKE($PACKAGE, $VERSION, no-define)'
> configure: error: /bin/sh './configure' failed for guile-readline
> sed: can't read confdefs.h: No such file or directory
> 
> I've just upgraded my box to Debian unstable, if that might have
> something to do wiht it.

It looks like autoconf didn't find a definition for AM_INIT_AUTOMAKE.
This can happen when autoconf and automake are installed in different
places?  Do you have one of them in /usr/local and the rest in /usr,
perchance?

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: uniform arrays & vectors

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> well, we all know that Guile's uniform vectors & arrays are strange,
> but the following is really buggy, isn't it? (taken from unif.c:315)

Yes, I can't figure it out, either.  The code (in toto) looks quite
complicated, but I'm not sure whether this is because of cleverness.

I think uniform arrays can be very useful.  If anyone wants to work on
them, that would be great.  Maybe a complete re-implementation is in
order.  The interface might need some work, too.  For example, I find
the "prototype" concept quite bogus.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: couldnt compile guile

[Marius Vollmer]

Martin Grabmueller <[EMAIL PROTECTED]> writes:

> But anyway, where did you download the snapshort from?  www.glug.org
> or www.red-bean.com.  The latter could be out of date, because it is
> (or was?) created from an outdated CVS repository, but I am not sure..

Yes, this seems to be the case.  I've mailed Jim about this, but he
seems to be fallen off the net...

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: make dist fails

[Marius Vollmer]

"Dale P. Smith" <[EMAIL PROTECTED]> writes:

> Current cvs fails on a "make dist" after "./autogen.sh; ./configure".
> 
> Here is the error:

Looks like a automake bug to me.  I have reported this to
<[EMAIL PROTECTED]>.


The following patch to automake seems to work, for the time being:

--- /usr/bin/automake   Mon Jun 11 07:29:36 2001
+++ /home/mvo/bin/automake  Thu Jun 28 21:56:10 2001
@@ -2003,8 +2003,7 @@
 . 's/\@VTEXI\@/' . $vtexi . '/g;'
 . 's,\@MDDIR\@,' . $conf_pat . ',g;'
 . 's,\@CONFIGURE_AC\@,' . $configure_ac . ',g;',
-'texi-vers')
-unless $done > 1;
+'texi-vers');
 
&push_phony_cleaners ($vti);
}

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: missing .x files

[Marius Vollmer]

"Dale P. Smith" <[EMAIL PROTECTED]> writes:

> I just tried to compile cvs guile on a cobalt Qube 3 (intel, 2.2.x
> kernel, hacked over RedHat distro) from a "make dist" that I made on my
> Debian unstable (latest auto* tools) machine.

Works for me.  That is, I can build a distro that I made with "make
dist" on one box on the same box ("make distcheck" works, too).  Can
you build your distro on Debian unstable?

> automake is 1.4
> autoconf is 2.13
> libtool is 1.3.4
> 
> Is there a problem with these tools?

Are these the tools on the Qube or on Debian?  It shouldn't really
matter what autostuff you have on the Qube.  On Debian unstable, you
should have the latest and greatest, I think.

We need the versions listed in HACKING, there is no way around that,
unfortunately.

> I can't really change them.  Well,
> I *could*, but I don't want to.

You could make a sandbox for guile development.  Install the tools
with their own prefix and add them to your path only when working on
Guile.  (Or make a sophisticated wrapper that selects version based on
the current working directory.)

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Problem building guile 1.4

[Marius Vollmer]

Andrew Koenig <[EMAIL PROTECTED]> writes:

> Following is the output from running "configure" -- look for the
> first line with "**" in it.

Please also show the contents of `guile-readline/config.log'.  The
test program for rl_getc_function did not compile, which could have
many causes besides the variable not being defined.  The file
config.log contains the error messages from the compiler.

Thanks!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Problem building guile 1.4

[Marius Vollmer]

Andrew Koenig <[EMAIL PROTECTED]> writes:

> The output seems to suggest that readline puts its header file
> somewhere that guile doesn't know about.

Right.  Where is it, then?  Guile makes no special efforts for finding
header files in non-standard locations.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Infinite loops with scm_read_0str and scm_eval_0str

[Marius Vollmer]

"Dale P. Smith" <[EMAIL PROTECTED]> writes:

> The deprecated functions are calling themselves instead of the new
> funcions.

Boy!  I'm s sloppy. :-(

Thanks!

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: NetBSD needs inttypes.h for uintptr_t

[Marius Vollmer]

Masao Uebayashi <[EMAIL PROTECTED]> writes:

> Without this, any file can't be compiled because of lack of the
> definition of uintptr_t.  uintptr_t is defined in inttypes.h on my
> NetBSD box, but I'm not sure if the proper entry point is it or not.

configure should check for the availability of uintptr_t.  What does
it find on your system?

We should also check for inttypes.h in addition to stdint.h, thus
making uintptr_t accessible on NetBSD, but I like to understand first
why it is failing to compile.

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile