From: Aemon Cannon <aemoncannon@gmail.com>
To: Aidan Kehoe <kehoea@parhasard.net>
Cc: emacs-devel@gnu.org, Miles Bader <miles@gnu.org>
Subject: Re: Difficulties byte-compiling very large .el file
Date: Tue, 1 Sep 2009 18:41:27 -0400 [thread overview]
Message-ID: <794057160909011541u11a42bcg8012a4a2d261a087@mail.gmail.com> (raw)
In-Reply-To: <794057160908250804j2eb49424md39f1c71f403516@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]
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 <aemoncannon@gmail.com>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 <kehoea@parhasard.net> wrote:
>
>>
>> Ar an cúigiú lá is fiche de mí Lúnasa, scríobh Miles Bader:
>>
>> > Aidan Kehoe <kehoea@parhasard.net> 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?
>>
>
>
[-- Attachment #2: Type: text/html, Size: 4394 bytes --]
next prev parent reply other threads:[~2009-09-01 22:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 21:49 Difficulties byte-compiling very large .el file Aemon Cannon
2009-08-20 8:27 ` Andreas Schwab
2009-08-20 13:07 ` Aemon Cannon
2009-08-20 13:23 ` Andreas Schwab
2009-08-20 14:29 ` Aemon Cannon
2009-08-20 18:30 ` Eli Zaretskii
2009-08-25 10:16 ` Aidan Kehoe
2009-08-25 11:07 ` Miles Bader
2009-08-25 11:50 ` Aidan Kehoe
2009-08-25 15:04 ` Aemon Cannon
2009-09-01 22:41 ` Aemon Cannon [this message]
2009-08-29 0:37 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=794057160909011541u11a42bcg8012a4a2d261a087@mail.gmail.com \
--to=aemoncannon@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=kehoea@parhasard.net \
--cc=miles@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.