Re: Difficulties byte-compiling very large .el file

[Aemon Cannon]

To followup:

I'm now working around the original issue by wrapping parts of the generated parser in in lambdas thusly:

(defmacro a3el-do-in-thunk (&rest body)
  (let ((thunk-name (gensym "thunk")))
    `(progn
       (setq ,thunk-name (lambda () ,@body))
       (funcall ,thunk-name))))

Works like a charm. 
Thanks to everyone for the help.

On Tue, Aug 25, 2009 at 11:04 AM, Aemon Cannon <address@hidden> wrote:

Aidan,
Thanks for pointing out the overflow issue. As you may have guessed, those constants are both max-value for a signed 32 bit integer, which is what ANTLR spits out in LL* situations (unbounded values for max-k). I may be able to specify the max value for elisp in the ANTLR template....

RE: My original problem,
I narrowed it down a bit and submitted a report at: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4251
I've since sent a followup with the following code, that also fails:
;;----------------

(defmacro many-forms ()
  (let ((body '()))
    (dotimes (i 20000)
      (setq body (cons '(message "more") body)))
    `(progn ,@body)))

(many-forms)

(if (eq 1 a)
    (message "dude")
  (message "else"))

;;--------------

I had assumed that the goto opcode used a 16 bit relative offset, but this snippet seems to indicate that it's not relative to the conditional itself. I also noticed in bytecode.c that the goto opcodes all use:
.....
stack.pc = stack.byte_string_start + op;
.....
where 'op' is a 16 bit int. This indicates that the jump is measured in relation to the top of the current byte_string, so if the conditional is in its own byte_string, it should work:
;;--------------------
(defmacro many-forms ()
  (let ((body '()))
    (dotimes (i 20000)
      (setq body (cons '(message "more") body)))
    `(progn ,@body)))

(many-forms)

(defun bar ()
  (if (eq 1 a)
      (message "dude")
    (message "else")))

;; ----------------------------

Which does work. Wrapping in lambda also works.

So now I'm thinking that as3_elispParser.el must have a single function body whose bytecode overflows the 16bit limit. As removing chunks of code from the top-level seems to alleviate the error (the lines with (a3el-parser-bitset ..) for instance), I'm guessing that the problematic byte_string corresponds to the top-level of the file.

I may be able to wrap this top-level setup code into smaller functions....

On Tue, Aug 25, 2009 at 7:50 AM, Aidan Kehoe <address@hidden> wrote:

 Ar an cúigiú lá is fiche de mí Lúnasa, scríobh Miles Bader:

 > Aidan Kehoe <address@hidden> writes:
 > > GNU Emacs has (IIRC) 27-bit integers on 32-bit platforms
 >
 > ``The range of values for integers in Emacs Lisp is -268435456 to
 > 268435455 (29 bits; i.e., -2**28 to 2**28 - 1) on most machines.''

Thanks for the correction. Aemon’s problem remains, though, independent of
that. Is there a good reason you don’t error on encountering integers the
emacs binary can’t represent? Portable code needs to be prepared for that
anyway.

--
¿Dónde estará ahora mi sobrino Yoghurtu Nghe, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?