Dan Kogai <dankogai(_at_)dan(_dot_)co(_dot_)jp> writes:
Nicholas,
On 2002.01.31, at 05:23, Nicholas Clark wrote:
I've not been closely following the Encode stuff, except to notice that
Dan
Kogai is putting a lot of work into making Japanese work more smoothly
than
it was. (Thanks). (Building on the work Nick I-S did. Thanks Nick)
Hence I'm not quite sure if I've got the cause of this problem correct,
but
it appears that Encode and Encode::EUC_JP both define
Encode_XS_Encoding:
A kludge I chucked in late Tuesday night. It is a hunk of code that
creates a bless ref to an IV holding a pointer to the C struct,
and then perl_call_sv()'s Enocde::define_encoding.
It was a little too big for me to be happy with it as a #define.
It could be static - or it could live in Encode.xs and we could
use the Tk/DBI like "function pointer in a perl scalar" trick to
get at it. Or we could have XS side poke encodings into and package array
and have .pm file do the call or ...
For a quick fix make it static in 'compile'.
(What should we call that script - compile_encoding ?)
Yes. That particular part is hard-coded in the compile script. It
should be easy to mend this problem by making compile a little bit
smarter. But....
Static linking all CJK modules is definitely a nightmare considering
the sizes they take.
They are not that big on modern machines but I agree most westerners
would not want 'em.
To keep the static perl small we have to
externally keep the conversion tables (Like Encode::Tcl). Hmm....
The other option (which I considered for a while) is to make compiled
encodings binary files which something reads. The main pain is the
pointer chains in the carruent form - I decided that making them
loadable objects was the best way.
Dan
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
