Dan Kogai <[EMAIL PROTECTED]> 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/
