[I apoligize for any oddities in this document -- I have doubts about this
mail agent's reliability. Please put "TO JULIAN" or the like within
the subject line of a reply.]
Greetings. There are four sections to this email, and they are
titled by lines beginning with "***".
The Four Sections:
* The fold-matches bugs
* The file name "and-let*.scm"'s portability
* UMB Scheme and rational numbers
* call-with-current-continuation badness
The attached file is a gzipped patch to one of the bugs described in
the first section.
*** The fold-matches bugs:
The NEWS entry where fold-matches and list-matches are described
ends with this line:
If present, FLAGS is passed as the FLAGS argument to regexp-exec.
The regex.scm code agrees with this, but unless there are undocumented
flags to regexp-exec, both are wrong. I initially read this as "to
make-regexp", and immediately discovered a bug caused by this mistake:
regexp-exec errors on the flags list passed to it. I "fixed" this bug
by adding a check on the length of the flags list in fold-matches and
gave an alternate calling of regexp-exec which used the car of the
flags list.
To my current surprise, regexp-exec didn't mind the argument, since
the flags meant for make-regexp are integers and regexp-exec does
something positively mysterious (nothing at all?) with its fourth
integer argument. My surprise at the time was that list-matches,
given regexp/icase, didn't match everything it should have, and later
that regexp-exec also failed to use regexp/icase correctly. I then
re-checked the documentation, compiled a regular expression with
make-regexp and regexp/icase, and re-checked regex.scm.
The patch included changes fold-matches of ice-9/regex.scm to pass its
flags to make-regexp instead of regexp-exec.
There is, unfortunately, a worse bug: list-matches sometimes ignores
its flag, and sometimes it doesn't. I don't know why. The following
was produced by first typing in the input and then repeatedly hitting
Return and Control-P.
guile> (list-matches "a.b" "Acb acb adb" regexp/icase)
(#("Acb acb adb" (0 . 3)) #("Acb acb adb" (4 . 7)) #("Acb acb adb" (8
. 11)))
guile> (list-matches "a.b" "Acb acb adb" regexp/icase)
(#("Acb acb adb" (4 . 7)) #("Acb acb adb" (8 . 11)))
guile> (list-matches "a.b" "Acb acb adb" regexp/icase)
(#("Acb acb adb" (0 . 3)) #("Acb acb adb" (4 . 7)) #("Acb acb adb" (8
. 11)))
guile> (list-matches "a.b" "Acb acb adb" regexp/icase)
(#("Acb acb adb" (4 . 7)) #("Acb acb adb" (8 . 11)))
guile> (list-matches "a.b" "Acb acb adb" regexp/icase)
(#("Acb acb adb" (4 . 7)) #("Acb acb adb" (8 . 11)))
guile> (list-matches "a.b" "Acb acb adb" regexp/icase)
(#("Acb acb adb" (0 . 3)) #("Acb acb adb" (4 . 7)) #("Acb acb adb" (8
. 11)))
My system is:
Guile version 1.4.1
Linux 2.2.14 on a Pentium processor
gcc version 2.95.2 19991024 (release)
GNU libc version 2.1.2
configure was called as:
CFLAGS='-O3 -march=pentium' ./configure --with-threads
*** The file name "and-let*.scm"'s portability:
The file name of ice-9/and-let*.scm is unportable, according to
both the GNU sh-utils program pathchk and empirical evidence: I had to
use cvs.exe on a Win95 machine to checkout guile-core, and it (or
WinZip?) completely ignored and-let*.scm. You could fix this by
renaming and-let*.scm to and-letSTAR.scm and then adding this target
to ice-9/Makefile:
and-let\*.scm:
mv and-letSTAR.scm and-let\*.scm
*** UMB Scheme and rational numbers:
UMB Scheme is a Scheme implementation licensed under the GNU
General Public License. I don't know where it may be found (it came
with my distribution of Linux) but if you can find it, UMB Scheme
supports rationals.
I'm not aware of the reason Guile does not as yet really support
rationals and I am aware of Guile's astonishing problem with using
GPL'd software, but maybe you can make something of this.
*** call-with-current-continuation badness:
Right before sending this email, I discovered this bug.
guile> (define foo #f)
guile> (+ 1 (call-with-current-continuation
(lambda (k)
(set! foo k)
(+ 2 (k 3)))))
4
guile> (foo 2)
ERROR: In procedure + in expression (+ 1 (call-with-current-continuation
#)):
ERROR: Wrong type argument: (((proc) #<procedure (k)>))
ABORT: (wrong-type-arg)
Obviously, (foo 2) should have returned 3. I worked some more on this. The
bug
disappears if -O3 -fno-inline-functions -march=pentium is given instead of
the
CFLAGS defined above. I haven't investigated to see what goes wrong when
gcc tries
to inline functions. (Note: the sometimes-works/sometimes-doesn't bug with
list-matches is not affected by -fno-inline-functions.)
Thank you,
Julian Fondren
ps: 1.4 is, indeed, the one I've been waiting for =)
regex-jrf.patch.gz
