Per Bothner <xxxxxx@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