Per Bothner <p...@bothner.com> writes: > This is indeed a very annoying bug/limitation in the JVM. Everyone > hates it, but the powers-that-be keep putting off fixing it. > Basically the length of the bytecode for a single method is limited to 64k. > (There are other 16-bit limitations, too.) > > This is also a Kawa bug: At the very least the compiler should abort with > an informative error message rather than create an excessively-big method. > Better would be to re-write the code to split the method into multiple > methods - but that is difficult. > In the case the problem i the "run" method generated for the formatst > class. > This corresponds to module-level actions of the module - which in this > case is almost all of it. When using my version of testing.zip it is > barely within the limit, at 60219 bytes. Your version pushes it above the > limit, > to 74710 bytes. I haven't looked at why yet - I assume your version generates > more "verbose" expansions of the macros.
I see, thanks for the explanation. Indeed it seems to work when I split formatst.scm into two files. Now I get the same number of unexpected failures from the whole 'make check' run as with the stock SRFI-64. I get 1 failure in the 'R7RS' suite and 7 in 'libs'. Can reproduce with the 2.0 tarball and SVN trunk. I can file a bug with more details if you wish, or are these known? Taylan
