# [gambit-list] Re: gambc40b12 failed TEST 7 check on Linux RHEL 3.0 clone

Bill Richter richter at math.northwestern.edu
Mon Jan 10 14:17:07 EST 2005

   > I'm not a great programmer, but [...]

My guess at this point is that my latest modifications of the
C-interface must be causing a problem when a garbage collection
occurs during a Scheme to C call.  I'm looking into it.

Thanks, Marc!  I've been having a crazy Emacs problem all morning, I
wonder if anyone else ever got that.  Finally I saw the problem in
DrScheme, and how to fix it with some Emacs. Possibly it was caused by
quack.el, but switching over to gambit.el didn't fix it.

So here's a simple file "hatA":

(define (memfÂ p alox)
(if (null? alox)
#f
(if (p (car alox))
alox
(memfÂ p (cdr alox)))))

(write (memf odd? '(2 8 2 3 5 4 1 2 3 4)))
(write (memf odd? '(2 8 2 30 50 4 10 2 30 4)))

(banach)lambdaGambit> gsi hatA
*** ERROR IN "hatA"@8.9 -- Unbound variable: memf

By looking at the file in DrScheme, I saw I have a \hat{A} character
after memf.  I can see the \hat{A} character in this mail buffer.

I asked someone here, and he noted that my modeline was reading "u" on
the far left.  The Emacs manual (s' for "mode line") in the node
"Coding Systems" says type C-h C RET, and I see I'm using "u --
mule-utf-8 (alias: utf-8)".  Durn!  Reading more of the manual, I see
to try M-x find-file-literally, and I backspace over the 2 \hat{A}
characters, and the "space" in front of it.  I can see by C-s that
there are only 2 such "space"s in the whole file.  And now it's fine:

(banach)lambdaGambit> gsi hatA
(3 5 4 1 2 3 4)#f

Whew!  Anyone has a tip to stay out of this problem in the future?
`