[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Difficulties byte-compiling very large .el file

From: Aemon Cannon
Subject: Re: Difficulties byte-compiling very large .el file
Date: Tue, 1 Sep 2009 18:41:27 -0400

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")))
       (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:
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)))


(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)))


(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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]