From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keisuke Nishida <kxn30@po.cwru.edu>
To: guile-emacs@sourceware.cygnus.com
Subject: Re: import-lisp-macro
Date: Sat, 18 Mar 2000 10:08:00 -0000
Message-id: <m3ln3gf8x0.fsf@kei.cwru.edu>
References: <m33dppijgl.fsf@kei.cwru.edu> <87hfe4mr29.fsf@PC486.Niemitalo.LAN>
X-SW-Source: 2000-q1/msg00041.html

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> > It seems this version has some GC-related bugs
> 
> Is there a way to fix them?

I think so, but I have not investigated it yet.

bash$ gdb emacs core
GNU gdb 4.18
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 "i386-redhat-linux"...

warning: exec file is newer than core file.
Core was generated by `emacs'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libXaw.so.6...done.
Reading symbols from /usr/X11R6/lib/libXmu.so.6...done.
Reading symbols from /usr/X11R6/lib/libXt.so.6...done.
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /usr/lib/libncurses.so.4...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /usr/local/lib/libguile.so.7...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
#0  0x401fb4e1 in __kill () from /lib/libc.so.6
DISPLAY = :0
TERM = dumb
Breakpoint 1 at 0x8093dc7: file emacs.c, line 277.
Breakpoint 2 at 0x8085f6e: file xterm.c, line 5335.
(gdb) bt
#0  0x401fb4e1 in __kill () from /lib/libc.so.6
#1  0x8093db6 in fatal_error_signal (sig=11) at emacs.c:249
#2  0x401fb408 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#3  0x40319067 in scm_make_stack (args=10612) at stacks.c:467
#4  0x403206a9 in ss_handler (data=0x0, tag=1077217144, throw_args=1077803392)
    at throw.c:315
#5  0x40320d19 in scm_ithrow (key=1077217144, args=1077803392, noreturn=1)
    at throw.c:683
#6  0x402eb036 in scm_error (key=1077217144, subr=0x0, 
    message=0x403388a0 "Unbound variable: ~S", args=1077803408, rest=8564)
    at error.c:82
#7  0x402ec17e in scm_lookupcar (vloc=1077808224, genv=1077814064, check=1)
    at eval.c:349
#8  0x402ec288 in scm_eval_car (pair=1077808224, env=1077814064) at eval.c:434
#9  0x402ecce4 in iqq (form=1077808232, env=1077814064, depth=1) at eval.c:847

Well, this might not be a GC bug...

> > An important change has been made.  All imported lisp functions now
> > returns a kind of pointer to a lisp value.
> 
> I think this is bad.  A function like buffer-substring should
> return a Scheme string directly, because that's what it will do
> in a Guile-based Emacs.  There could be a separate function
> buffer-substring-lispref for cases where the Lisp reference is
> needed.

Yes, we can do that by defining this:

  (import-lisp-function buffer-substring buffer-substring-lispref)

  (define (buffer-substring . args)
    ((apply buffer-substring-lispref args)))

My point is lisp-eval should have this change for completeness.
And that's why I think we need to develop a new set of functions
for Scheme programs.

-- Kei