[gambit-list] Re: gambc40b12 failed TEST 7 check on Linux RHEL 3.0 clone
Bill Richter
richter at math.northwestern.edu
Mon Jan 10 15:22:51 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?
More information about the Gambit-list
mailing list