>>>> "Aidan" == Aidan Kehoe
Aidan> My local ad-hoc workspace setup seems to have subtly broken
Aidan> when tags are imported. I imagine this is a hangover from
Aidan> your import of the Xft branch.
Could be. My experience with CVS is that it's a very bad idea to use
tags in any way other than at checkout, and in "cvs update -j TAG -j TAG".
Aidan> Oops. (How does git handle interfacing with CVS? Well?
So far they've been quite independent. Put "CVS" in .gitignore, put
".git*" in .cvsignore, and you're basically there. In fact, "git
reset" is so reliable and fast that I'm considering putting CVS under
git control too, which would allow me to recover the exact state of my
integration workspace, including its correspondence to CVS. Merges
don't seem to bother git (except for ChangeLogs, but those are always
trivial), and I avoid stressing CVS, obviously. ;-)
> I personally think that EXFUNing anywhere but in lisp.h is a
> bad idea. It's not clear to me that it's a good idea to be
> calling Lisp functions from this code. Lisp may signal if it
> doesn't like the arguments, or randomly collect garbage, and
> other antisocial habits.
Aidan> Functions callable from Lisp are not quite the same thing
Aidan> as Lisp functions, with our current Unicode infrastructure
Aidan> unicode-to-char and char-to-unicode will *never, in any
Aidan> possible universe* call Lisp. Fcharset_name, equally, I
I wish that were true, but all those functions eventually do
sanity-checking on their arguments using "CHECK_<type>" macros. They
can signal, and if they can signal they can be condition-cased, and
arbitrary Lisp code can get executed, as well as garbage collection.
You may be able to prove that can't happen in your usage, but then
wouldn't it be preferable to call the implementation directly, without
the overhead of the argument checking?
There are very few Lisp primitives and accessor macros that don't have
that property. Personally, I avoid using Lisp primitives in C code
unless I want that checking, etc. YMMV, that's just my opinion.
> It's not clear to me that it's a good idea to use CCL at
> If we are going to continue to do so, we should change the
> source language to Lisp and just signal an error if the
> compilation fails (optionally we could allow a Lisp program
> wherever a CCL program is permitted).
That would be hard, I guess.
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.