Yes, it is too large a term to compile. The problem is that
it requires too many local variables. The byte-code format
limits the number of local variables to 255 (well 253
actually, since 2 are used for other pointers.) The
compiler did not complain about too many local variables,
but simply generated bad code. I've now added a check for
too many local variables and so now the compiler will give
an error message and abort (as it does when too many
registers are required) if this situation arises. I'll
commit the change when Terry has made his changes to improve
the I/O.
I admit this doesn't really help you. We're not planning to
change the byte-code format any time soon, so we're stuck
with that max. But I'm not sure why the clause you're
compiling should need that many local variables. I'll try
to look into that (but that's hairy compiler code and I
don't hold out much hope of help here either.)
Sorry,
-David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=13069
What attachment?
Logged In: YES
user_id=12609
Sorry,
I forgot to attach it again!
The problem is the same as in another, related report.
XSB crashes on large terms.
Just type
xsb -e "[changbug2]."
and see what happens.
A query with a large term inside
Logged In: YES
user_id=12609
Sorry,
I forgot to attach it again!
The problem is the same as in another, related report.
XSB crashes on large terms.
Just type
xsb -e "[changbug2]."
and see what happens.
A query with a large term inside
Logged In: YES
user_id=13069
Yes, it is too large a term to compile. The problem is that
it requires too many local variables. The byte-code format
limits the number of local variables to 255 (well 253
actually, since 2 are used for other pointers.) The
compiler did not complain about too many local variables,
but simply generated bad code. I've now added a check for
too many local variables and so now the compiler will give
an error message and abort (as it does when too many
registers are required) if this situation arises. I'll
commit the change when Terry has made his changes to improve
the I/O.
I admit this doesn't really help you. We're not planning to
change the byte-code format any time soon, so we're stuck
with that max. But I'm not sure why the clause you're
compiling should need that many local variables. I'll try
to look into that (but that's hairy compiler code and I
don't hold out much hope of help here either.)
Sorry,
-David