pure-fns in byte-opt.el

pure-fns in byte-opt.el

[Mark Oteiza]

Hi,

I was curious about what other functions might be pure and could be
added to this list.  While I seem to have guessed correctly on some,
I am perplexed why adding string-to-char breaks things:

16288064 of 33554432 static heap bytes used
97335 pure bytes used
mv -f emacs bootstrap-emacs
make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[2]: Entering directory '/tmp/makepkg/emacs-git/src/emacs/lisp'
  ELC      emacs-lisp/byte-opt.elc
make[2]: Leaving directory '/tmp/makepkg/emacs-git/src/emacs/lisp'
make -C ../lisp autoloads EMACS="../src/bootstrap-emacs"
make[2]: Entering directory '/tmp/makepkg/emacs-git/src/emacs/lisp'
make -C ../leim all EMACS="../src/bootstrap-emacs"
make[3]: Entering directory '/tmp/makepkg/emacs-git/src/emacs/leim'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/tmp/makepkg/emacs-git/src/emacs/leim'
make -C ../admin/grammars all EMACS="../../src/bootstrap-emacs"
make[3]: Entering directory '/tmp/makepkg/emacs-git/src/emacs/admin/grammars'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/tmp/makepkg/emacs-git/src/emacs/admin/grammars'
Directories for loaddefs: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
  GEN      loaddefs.el
make[2]: Leaving directory '/tmp/makepkg/emacs-git/src/emacs/lisp'
make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[2]: Entering directory '/tmp/makepkg/emacs-git/src/emacs/admin/unidata'
  GEN      ../../lisp/international/uni-decomposition.el
Wrong type argument: listp, "頩"
make[2]: *** [Makefile:91: ../../lisp/international/uni-decomposition.el] Error 255
make[2]: Leaving directory '/tmp/makepkg/emacs-git/src/emacs/admin/unidata'
make[1]: *** [Makefile:502: ../lisp/international/charprop.el] Error 2
make[1]: Leaving directory '/tmp/makepkg/emacs-git/src/emacs/src'
make: *** [Makefile:416: src] Error 2

Re: pure-fns in byte-opt.el

[Andreas Schwab]

On Jul 24 2017, Mark Oteiza <mvoteiza@udel.edu> wrote:

> I was curious about what other functions might be pure and could be
> added to this list.  While I seem to have guessed correctly on some,
> I am perplexed why adding string-to-char breaks things:

Strings are not immutable.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: pure-fns in byte-opt.el

[Stefan Monnier]

>> I was curious about what other functions might be pure and could be
>> added to this list.  While I seem to have guessed correctly on some,
>> I am perplexed why adding string-to-char breaks things:
> Strings are not immutable.

I agree that string-to-char is not a pure function, according to my
understanding of the meaning of "pure" in such a context.  Yet, I can't
see why it leads to that error (AFAIK the purity is only used in order
to either get rid of the code when the result is not used (which is OK
for string-to-char), or to pre-evaluate the result when all args are
constants, which should be OK unless the function is called with an
immediate string that is later modified, which seems rather unlikely).


        Stefan

Re: pure-fns in byte-opt.el

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Di., 25. Juli 2017 um
16:21 Uhr:

> >> I was curious about what other functions might be pure and could be
> >> added to this list.  While I seem to have guessed correctly on some,
> >> I am perplexed why adding string-to-char breaks things:
> > Strings are not immutable.
>
> I agree that string-to-char is not a pure function, according to my
> understanding of the meaning of "pure" in such a context.


Why? Its return value clearly only depends on its argument, and it doesn't
change any global state. It's the poster child of a pure function!

[-- Attachment #2: Type: text/html, Size: 934 bytes --]

Re: pure-fns in byte-opt.el

[Stefan Monnier]

> Why? Its return value clearly only depends on its argument, and it doesn't
> change any global state. It's the poster child of a pure function!

  (let ((s (make-string 5 ?a)))
    (list (string-to-char s)
          (progn
            (aset s 0 ?b)
            (string-to-char s))))

If string-to-char were a pure function, it would return the same value
in both calls (since the arguments are `eq').


        Stefan

Re: pure-fns in byte-opt.el

[Clément Pit-Claudel]

Hi Stefan,

On 2017-07-25 23:27, Stefan Monnier wrote:
> If string-to-char were a pure function, it would return the same
> value in both calls (since the arguments are `eq')
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What do you mean by this?

Clément.

Re: pure-fns in byte-opt.el

[Stefan Monnier]

>> If string-to-char were a pure function, it would return the same
>> value in both calls (since the arguments are `eq')
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> What do you mean by this?

That the argument passed to the first call is `eq` with the argument
passed to the second call.


        Stefan

Re: pure-fns in byte-opt.el

[Clément Pit-Claudel]

On 2017-07-26 02:08, Stefan Monnier wrote:
>>> If string-to-char were a pure function, it would return the same
>>> value in both calls (since the arguments are `eq')
>>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> What do you mean by this?
> 
> That the argument passed to the first call is `eq` with the argument
> passed to the second call.

I see.  That's not what I understood to be usually meant by "pure": although both arguments are pointers to the same address in memory, the contents of that address have been modified in the meantime.  In that sense, haven't the two calls to string-to-char been passed different values (albeit stored in the same memory location)?

In other words, I don't see your example as proving that string-to-char is impure; instead, it just looks like a pure function that's passed two different values.  As a concrete example, is the following a proof that string-to-syntax is impure? If so, it should be removed from our list of pure functions :)

  (let ((s (make-string 1 ?w)))
    (list (string-to-syntax s)
          (progn
            (aset s 0 ?_)
            (string-to-syntax s))))

The same argument seems to apply to *all* functions marked pure in byte-opt.el, except `symbol-name' (namely `concat', `regexp-opt', `regexp-quote', and `string-to-syntax'). Under your definition, neither the `length' nor the `car' function on lists are pure. In fact, if I understand it correctly, your definition seems to imply that any function that reads mutable data is (by definition) impure.  Is that right?  This seems very restrictive, and it seems to be contradicted by existing 'pure' annotations in our codebase.  How do we call the property shared by `concat', `length', and `string-to-chars'? in ELisp land, if it's not "pure"?

In byte-opt we say this:

;; pure functions are side-effect free functions whose values depend
;; only on their arguments. For these functions, calls with constant
;; arguments can be evaluated at compile time. This may shift run time
;; errors to compile time.

I tried to get inspiration from looking at other `pure' annotations in lisp/ but the examples I found were confusing.  All four examples of (pure t) functions in smie.el take lists as input, for example:

(defun smie-precs->prec2 (precs)
  "Compute a 2D precedence table from a list of precedences. …
  (declare (pure t))

and indeed:

  (let ((s '((left "+") (right "*"))))
    (list (smie-precs->prec2 s)
          (progn
            (setf (caar s) 'right)
            (smie-precs->prec2 s))))

Can you point out where I went wrong? To me it just looks like Mark ran into a bug.

Clément.

Re: pure-fns in byte-opt.el

[Stefan Monnier]

> I see.  That's not what I understood to be usually meant by "pure":
> although both arguments are pointers to the same address in memory,
> the contents of that address have been modified in the meantime.
> In that sense, haven't the two calls to string-to-char been passed
> different values (albeit stored in the same memory location)?

If you think of Haskell types:

    string-to-char :: String -> IO Char

and that's because in order to implement string-to-char, you need to use

    aref :: Array α -> Int -> IO α

> In other words, I don't see your example as proving that
> string-to-char is impure; instead, it just looks like a pure function
> that's passed two different values.  As a concrete example, is the
> following a proof that string-to-syntax is impure? If so, it should be
> removed from our list of pure functions :)

There are different notions of purity, indeed.  Which is why I replied
to Andreas saying that just because string-to-char is not strictly
speaking pure, I don't see why adding it to pure-fns would
break anything.


        Stefan

Re: pure-fns in byte-opt.el

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Di., 25. Juli 2017 um
23:27 Uhr:

> > Why? Its return value clearly only depends on its argument, and it
> doesn't
> > change any global state. It's the poster child of a pure function!
>
>   (let ((s (make-string 5 ?a)))
>     (list (string-to-char s)
>           (progn
>             (aset s 0 ?b)
>             (string-to-char s))))
>
> If string-to-char were a pure function, it would return the same value
> in both calls (since the arguments are `eq').
>
>
Hmm. I get the argument, but wouldn't that mean that only a tiny set of
builtins were pure? If the definition is "A function is pure if applying it
to the same objects (in the sense of `eq') always gives the same result",
then I think only eq, eql, null, and the type predicates (integerp etc.)
are pure. Even the arithmetic functions aren't pure because they can act on
(mutable) markers. The list in byte-opt, however, is noticeably different,
and none of the functions marked pure there are actually pure. The same
applies to third-party libraries such as dash.el.
In any case, the precise definition of "pure" and "side effect free" needs
to be in the manual, and functions that are wrongly declared as pure or
side effect free need to be fixed.

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

Re: pure-fns in byte-opt.el

[Stefan Monnier]

> Hmm.  I get the argument, but wouldn't that mean that only a tiny set of
> builtins were pure?

Indeed, according to that definition of pure, very few Elisp
functions qualify.

Which is why this is not exactly the definition used for pure-fns.


        Stefan

Re: pure-fns in byte-opt.el

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Fr., 28. Juli 2017 um
19:50 Uhr:

> > Hmm.  I get the argument, but wouldn't that mean that only a tiny set of
> > builtins were pure?
>
> Indeed, according to that definition of pure, very few Elisp
> functions qualify.
>
> Which is why this is not exactly the definition used for pure-fns.
>
>
So what is then the actual definition? Is it in the manual?

[-- Attachment #2: Type: text/html, Size: 725 bytes --]

Re: pure-fns in byte-opt.el

[Stefan Monnier]

> So what is then the actual definition? Is it in the manual?

The only definition I've seen just says that it means that the compiler
can precompute the calls if it knows the arguments's values.


        Stefan

Re: pure-fns in byte-opt.el

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Sa., 29. Juli 2017 um
00:21 Uhr:

> > So what is then the actual definition? Is it in the manual?
>
> The only definition I've seen just says that it means that the compiler
> can precompute the calls if it knows the arguments's values.
>
>
Can we find a definition that allows authors of functions to derive their
"pure" and "side-effect-free" status by only looking at their interface and
implementation? It seems like these attributes would both be useful for
documentation purposes as well as for optimization, and they have seen some
use outside of Emacs core (e.g. in dash.el), so their semantics should be
formalized and documented. How about something like this:

A side-effect-free function is one where all of the following is true:
- After exiting the function (whether normally or nonlocally), the
`match-data' are `equal' to the `match-data' before entering the function.
- After exiting the function, all dynamic variables, their default values,
their symbol cells, etc., are `eq' to the respective values before entering
the function. Exceptions are variables only used for debugging/tracing,
such as `cons-cells-consed'.
- All buffer contents, markers, point values etc. are
`equal-including-properties' to their previous values.
- The same buffers and threads still exist.

A side-effect-free-and-error-free function is one that is side-effect-free
and also doesn't signal any errors except `memory-full'.

A pure function is a side-effect-free function with the following
additional properties:
- The function recursively only accepts and returns numbers, symbols,
lists, vectors, hashtables, and strings; not buffers or processes since
they are naturally stateful.
- Two invocations with arguments that are pairwise
`equal-including-properties' (or, in the case of hashtables, have keys and
values that are `equal-including-properties') will either both exit
nonlocally or return values that are again `equal-including-properties'.

[-- Attachment #2: Type: text/html, Size: 2564 bytes --]

Re: pure-fns in byte-opt.el

[Stefan Monnier]

> A side-effect-free function is one where all of the following is true:
> - After exiting the function (whether normally or nonlocally), the
> `match-data' are `equal' to the `match-data' before entering the function.
> - After exiting the function, all dynamic variables, their default values,
> their symbol cells, etc., are `eq' to the respective values before entering
> the function. Exceptions are variables only used for debugging/tracing,
> such as `cons-cells-consed'.
> - All buffer contents, markers, point values etc. are
> `equal-including-properties' to their previous values.
> - The same buffers and threads still exist.

I don't think we want to enumerate all the manners that side-effects can
occur, since we will inevitably forget some (and the list will get out
of date).

I think we should define it more as something like:

    side-effect-free means: if the result of the function is not used,
    calling the function or not does not affect the behavior of the program,
    except that the function may signal an error.

    side-effect-and-error-free means: like side-effect-free but cannot
    signal an error.  This means that the optimizer can eliminate calls
    to those functions if the result is not used.

    pure: like side-effect-free but additionally, the function always
    returns the same value when called with the same arguments, so the
    compiler can precompute the call if it knows the arguments.


-- Stefan

Re: pure-fns in byte-opt.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

      > pure: like side-effect-free but additionally, the function always
      > returns the same value when called with the same arguments, so the
      > compiler can precompute the call if it knows the arguments.

It may be necessary to define "same" more precisely.
Does it mean equal?  eq?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: pure-fns in byte-opt.el

[Stefan Monnier]

>> pure: like side-effect-free but additionally, the function always
>> returns the same value when called with the same arguments, so the
>> compiler can precompute the call if it knows the arguments.
> It may be necessary to define "same" more precisely.
> Does it mean equal?  eq?

Both/neither?  The compiler doesn't test it in any way (it only has the
known arguments, and no "others" to compare it with).  I guess `equal`
is closer to what typically happens, but I don't think this precision is
of any use.  The only *real* definition is the last part: "the compiler
can precompute the call if it knows the arguments" (where "can" should
probably be replaced with "may", actually).


        Stefan

Re: pure-fns in byte-opt.el

[Philipp Stephani]

Am Di., 26. Sept. 2017 um 02:26 Uhr schrieb Stefan Monnier
<monnier@iro.umontreal.ca>:
>
> >> pure: like side-effect-free but additionally, the function always
> >> returns the same value when called with the same arguments, so the
> >> compiler can precompute the call if it knows the arguments.
> > It may be necessary to define "same" more precisely.
> > Does it mean equal?  eq?
>
> Both/neither?  The compiler doesn't test it in any way (it only has the
> known arguments, and no "others" to compare it with).  I guess `equal`
> is closer to what typically happens, but I don't think this precision is
> of any use.  The only *real* definition is the last part: "the compiler
> can precompute the call if it knows the arguments" (where "can" should
> probably be replaced with "may", actually).
>


That's not a very useful definition, though, or rather, not a
definition at all, but a consequence of an as-yet hidden definition.
It has to be possible to decide whether a function is pure by looking
at its observable behavior and its definition. Otherwise, how are
programmers to apply the "pure" and "side-effect-free" attributes to
their functions? The behavior of the byte compiled needs to follow
from the definition, not the other way round.
(I know this thread is 3 years old, but the same topic has been
discussed in another thread as well recently, so it's not resolved.
yet)

Re: pure-fns in byte-opt.el

[Stefan Monnier]

>> of any use.  The only *real* definition is the last part: "the compiler
>> can precompute the call if it knows the arguments" (where "can" should
>> probably be replaced with "may", actually).
> That's not a very useful definition, though, or rather, not a
> definition at all, but a consequence of an as-yet hidden definition.

I don't see why you think so.

> It has to be possible to decide whether a function is pure by looking
> at its observable behavior and its definition.

The above "definition" seems to allow that: based on looking at the code
you should be able to assess whether it's safe to allow the compiler (or
anything else for that matter) to precompute the call.

> The behavior of the byte compiled needs to follow
> from the definition, not the other way round.

I don't see how the above definition fails this constraint.


        Stefan

Re: pure-fns in byte-opt.el

[Philipp Stephani]

Am Sa., 25. Juli 2020 um 21:58 Uhr schrieb Stefan Monnier
<monnier@iro.umontreal.ca>:
>
> >> of any use.  The only *real* definition is the last part: "the compiler
> >> can precompute the call if it knows the arguments" (where "can" should
> >> probably be replaced with "may", actually).
> > That's not a very useful definition, though, or rather, not a
> > definition at all, but a consequence of an as-yet hidden definition.
>
> I don't see why you think so.

It requires the user to know how the byte optimizer operates (or at
least, how it can operate in theory).

>
> > It has to be possible to decide whether a function is pure by looking
> > at its observable behavior and its definition.
>
> The above "definition" seems to allow that: based on looking at the code
> you should be able to assess whether it's safe to allow the compiler (or
> anything else for that matter) to precompute the call.

I wouldn't know how that should be possible without knowing how the
compiler operates (or what it "knows" or can know).

>
> > The behavior of the byte compiled needs to follow
> > from the definition, not the other way round.
>
> I don't see how the above definition fails this constraint.
>

It relies on some (rather vague) terms about the compiler, such as
"precompute" and "know". What if we change the compiler significantly
so that it "knows" much more? Wouldn't that suddenly change the
possible set of pure functions?

Re: pure-fns in byte-opt.el

[Stefan Monnier]

>> The above "definition" seems to allow that: based on looking at the code
>> you should be able to assess whether it's safe to allow the compiler (or
>> anything else for that matter) to precompute the call.
> I wouldn't know how that should be possible without knowing how the
> compiler operates (or what it "knows" or can know).

Why would you need to know that?
As mentioned between parentheses it's not specific to a compiler.
Is it that you find "precompute" unclear?

> It relies on some (rather vague) terms about the compiler, such as
> "precompute" and "know". What if we change the compiler significantly
> so that it "knows" much more?

Doesn't make a difference: it will just make it possible for the compiler
to precompute more often, whereas what this flag says is "when the
compiler is *able* to precompute the call, should it be *allowed* to do
so".


        Stefan

Re: pure-fns in byte-opt.el

[Philipp Stephani]

Am Sa., 25. Juli 2020 um 22:59 Uhr schrieb Stefan Monnier
<monnier@iro.umontreal.ca>:
>
> >> The above "definition" seems to allow that: based on looking at the code
> >> you should be able to assess whether it's safe to allow the compiler (or
> >> anything else for that matter) to precompute the call.
> > I wouldn't know how that should be possible without knowing how the
> > compiler operates (or what it "knows" or can know).
>
> Why would you need to know that?
> As mentioned between parentheses it's not specific to a compiler.
> Is it that you find "precompute" unclear?

Yes, but also referring to a compiler, whether the current
implementation or some abstract one. We should be able to define the
semantics of Emacs Lisp without referring to implementation details
such as byte compilation. The current manual already attempts to do
that, it's just not 100% complete and correct.

>
> > It relies on some (rather vague) terms about the compiler, such as
> > "precompute" and "know". What if we change the compiler significantly
> > so that it "knows" much more?
>
> Doesn't make a difference: it will just make it possible for the compiler
> to precompute more often, whereas what this flag says is "when the
> compiler is *able* to precompute the call, should it be *allowed* to do
> so".
>
>
>         Stefan
>

Re: pure-fns in byte-opt.el

[Stefan Monnier]

>> Why would you need to know that?
>> As mentioned between parentheses it's not specific to a compiler.
>> Is it that you find "precompute" unclear?
>
> Yes, but also referring to a compiler, whether the current
> implementation or some abstract one.

The reference to a compiler is only there to help the reader understand
the circumstance where one might want to precompute the result of
a call.


        Stefan

RE: pure-fns in byte-opt.el

[Drew Adams]

> A side-effect-free function is one where all of the following
> is true:
> - After exiting the function (whether normally or nonlocally),
>   the `match-data' are `equal' to the `match-data' before
>   entering the function.
> - After exiting the function, all dynamic variables, their
>   default values, their symbol cells, etc., are `eq' to the
>   respective values before entering the function.

Not sure what you intend by the "symbol cells" of dynamic
variables.  Do you mean only their `symbol-value' values?

Or do you mean all properties of the symbols that serve as
dynamic variables?

Or do you perhaps mean all properties of all symbols (dynamic
variable or not)?

>   Exceptions are variables only used for debugging/tracing,
>   such as `cons-cells-consed'.
> - All buffer contents, markers, point values etc. are
>   `equal-including-properties' to their previous values.
> - The same buffers and threads still exist.

There are tons of other kinds of side effects possible in
Lisp, of course.  A "side-effect-free function" per your
definition can perform any number of other such side effects.

It can affect symbol properties, string properties, buffer
properties, cons cells,....

What's the intended purpose of your "side-effect-free"
function?

If your definition of it is sufficient for that purpose
then please consider using some other name for the quality
you define, as it is really quite far from characterizing
a side-effect-free Lisp function, i.e., far from indicating
that a given Lisp function (so-called) performs no side
effects.

> A pure function is a side-effect-free function with the
> following additional properties:
> - The function recursively only accepts and returns numbers,
>   symbols, lists, vectors, hashtables, and strings; not
>   buffers or processes since they are naturally stateful.

Just accepts and returns?  What about modifying buffers or
processes without accepting them as arguments or returning
them?

A Lisp function invocation exists in an environment that
goes far beyond the current values and definitions of the
current set of variables and functions.

The behavior of such an invocation can be affected by any
number of aspects of that environment, and it can (side-)
effect any number of them.

> - Two invocations with arguments that are pairwise
>   `equal-including-properties' (or, in the case of hashtables,
>   have keys and values that are `equal-including-properties')
>   will either both exit nonlocally or return values that are
>   again `equal-including-properties'.

In Lisp, "functions" are not just about arguments and return
values.  Lisp is as procedural and imperative as Fortran, C,
or assembler.

But again, maybe your intended use of "pure" Lisp functions,
following your definition, does not really require actually
pure functions.  If so, please consider using some other name
for the quality you are calling "pure", as it is really quite
far from characterizing a pure function.

Re: pure-fns in byte-opt.el

[Mark Oteiza]

On 25/07/17 at 10:14am, Andreas Schwab wrote:
>On Jul 24 2017, Mark Oteiza <mvoteiza@udel.edu> wrote:
>
>> I was curious about what other functions might be pure and could be
>> added to this list.  While I seem to have guessed correctly on some,
>> I am perplexed why adding string-to-char breaks things:
>
>Strings are not immutable.

Right, thanks.  Elisp lacks immutable strings, and string literals
aren't eq.  Marking string-to-char would result in sexps turning into
string literals--I just don't know what's happening in bootstrap.

The "listp" in the error makes me wonder if the byte compiler is
perhaps turning a quoted form into a string.

Re: pure-fns in byte-opt.el

[Eli Zaretskii]

> Date: Tue, 25 Jul 2017 21:00:00 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: emacs-devel@gnu.org
> 
> The "listp" in the error makes me wonder if the byte compiler is
> perhaps turning a quoted form into a string.

If you could run the offending command under a debugger and show both
C-level and Lisp-level backtrace from the error, maybe we could become
wiser.  (Let me know if you need help in staging the experiment and/or
collecting the data after you catch the error.)

Thanks.

Re: pure-fns in byte-opt.el

[Mark Oteiza]

On 26/07/17 at 05:33pm, Eli Zaretskii wrote:
>> Date: Tue, 25 Jul 2017 21:00:00 -0400
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Cc: emacs-devel@gnu.org
>>
>> The "listp" in the error makes me wonder if the byte compiler is
>> perhaps turning a quoted form into a string.
>
>If you could run the offending command under a debugger and show both
>C-level and Lisp-level backtrace from the error, maybe we could become
>wiser.  (Let me know if you need help in staging the experiment and/or
>collecting the data after you catch the error.)

Here is the point during the build the error happens:

"../../src/bootstrap-emacs" -batch --no-site-file --no-site-lisp -L . -l
unidata-gen \
  -f unidata-gen-file ../../lisp/international/uni-decomposition.el .
  Loading macroexp.elc...
  Wrong type argument: listp, "頩"

I set a breakpoint at wrong_type_argument

Thread 1 "bootstrap-emacs" hit Breakpoint 4, wrong_type_argument (
predicate=XIL(0x8550), value=XIL(0x3dee414)) at data.c:154
154       xsignal2 (Qwrong_type_argument, predicate, value);
(gdb) xbacktrace
"unidata-gen-table-word-list" (0xffffb690)
"unidata-gen-table-decomposition" (0xffffbb20)
"unidata-gen-file" (0xffffc108)
"funcall" (0xffffc100)
"if" (0xffffc2c0)
"cond" (0xffffc430)
"let*" (0xffffc5d0)
"while" (0xffffc760)
"let*" (0xffffc900)
"progn" (0xffffca30)
"if" (0xffffcb70)
"let" (0xffffcd50)
"let" (0xffffcf30)
"command-line-1" (0xffffd0b0)
"command-line" (0xffffd300)
"unwind-protect" (0xffffd4f0)
"let" (0xffffd6d0)
"if" (0xffffd840)
"normal-top-level" (0xffffd9c0)

I would need help with digging deeper.  Also, I made an error in my
OP--it is make-vector being marked pure that's a problem:

diff --git a/lisp/emacs-lisp/byte-opt.el b/lisp/emacs-lisp/byte-opt.el
index 962a7ae5cd..297e43884f 100644
--- a/lisp/emacs-lisp/byte-opt.el
+++ b/lisp/emacs-lisp/byte-opt.el
@@ -1281,7 +1281,8 @@ byte-optimize-set
 ;; errors to compile time.
 
 (let ((pure-fns
-       '(concat symbol-name regexp-opt regexp-quote string-to-syntax)))
+       '(concat symbol-name regexp-opt regexp-quote string-to-syntax
+         make-vector)))
   (while pure-fns
     (put (car pure-fns) 'pure t)
     (setq pure-fns (cdr pure-fns)))

Re: pure-fns in byte-opt.el

[Stefan Monnier]

> (let ((pure-fns
> -       '(concat symbol-name regexp-opt regexp-quote string-to-syntax)))
> +       '(concat symbol-name regexp-opt regexp-quote string-to-syntax
> +         make-vector)))

Ah, now that makes a lot more sense: make-vector is much less pure than
string-to-char.  The above will cause the compiler to replace

   (make-vector 2 ?a)

with

   [?a ?a]

so you end with a single immediate vector being re-used over and over,
instead of having a new vector created each time.


        Stefan

Re: pure-fns in byte-opt.el

[Mark Oteiza]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (let ((pure-fns
>> -       '(concat symbol-name regexp-opt regexp-quote string-to-syntax)))
>> +       '(concat symbol-name regexp-opt regexp-quote string-to-syntax
>> +         make-vector)))
>
> Ah, now that makes a lot more sense: make-vector is much less pure than
> string-to-char.  The above will cause the compiler to replace
>
>    (make-vector 2 ?a)
>
> with
>
>    [?a ?a]
>
> so you end with a single immediate vector being re-used over and over,
> instead of having a new vector created each time.

But reading a literal vector still generates a new vector, no?

Re: pure-fns in byte-opt.el

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sat, 29 Jul 2017 12:43:51 -0400
> Cc: emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> (let ((pure-fns
> >> -       '(concat symbol-name regexp-opt regexp-quote string-to-syntax)))
> >> +       '(concat symbol-name regexp-opt regexp-quote string-to-syntax
> >> +         make-vector)))
> >
> > Ah, now that makes a lot more sense: make-vector is much less pure than
> > string-to-char.  The above will cause the compiler to replace
> >
> >    (make-vector 2 ?a)
> >
> > with
> >
> >    [?a ?a]
> >
> > so you end with a single immediate vector being re-used over and over,
> > instead of having a new vector created each time.
> 
> But reading a literal vector still generates a new vector, no?

Why do you assume it will be read?

Re: pure-fns in byte-opt.el

[Mark Oteiza]

On 29/07/17 at 08:22pm, Eli Zaretskii wrote:
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Date: Sat, 29 Jul 2017 12:43:51 -0400
>> Cc: emacs-devel@gnu.org
>>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>> >> (let ((pure-fns
>> >> -       '(concat symbol-name regexp-opt regexp-quote string-to-syntax)))
>> >> +       '(concat symbol-name regexp-opt regexp-quote string-to-syntax
>> >> +         make-vector)))
>> >
>> > Ah, now that makes a lot more sense: make-vector is much less pure than
>> > string-to-char.  The above will cause the compiler to replace
>> >
>> >    (make-vector 2 ?a)
>> >
>> > with
>> >
>> >    [?a ?a]
>> >
>> > so you end with a single immediate vector being re-used over and over,
>> > instead of having a new vector created each time.
>>
>> But reading a literal vector still generates a new vector, no?
>
>Why do you assume it will be read?

I guess because I don't understand how bytecode is executed.

Re: pure-fns in byte-opt.el

[Andreas Schwab]

On Jul 29 2017, Mark Oteiza <mvoteiza@udel.edu> wrote:

> On 29/07/17 at 08:22pm, Eli Zaretskii wrote:
>>> From: Mark Oteiza <mvoteiza@udel.edu>
>>> Date: Sat, 29 Jul 2017 12:43:51 -0400
>>> Cc: emacs-devel@gnu.org
>>>
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>
>>> >> (let ((pure-fns
>>> >> -       '(concat symbol-name regexp-opt regexp-quote string-to-syntax)))
>>> >> +       '(concat symbol-name regexp-opt regexp-quote string-to-syntax
>>> >> +         make-vector)))
>>> >
>>> > Ah, now that makes a lot more sense: make-vector is much less pure than
>>> > string-to-char.  The above will cause the compiler to replace
>>> >
>>> >    (make-vector 2 ?a)
>>> >
>>> > with
>>> >
>>> >    [?a ?a]
>>> >
>>> > so you end with a single immediate vector being re-used over and over,
>>> > instead of having a new vector created each time.
>>>
>>> But reading a literal vector still generates a new vector, no?
>>
>>Why do you assume it will be read?
>
> I guess because I don't understand how bytecode is executed.

This has nothing to do with bytecode.  Try this:

(let ((i 0) r)
  (while (< i 2)
    (let ((v (make-vector 2 0)))
      (aset v i i)
      (push v r))
    (setq i (1+ i)))
  r)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: pure-fns in byte-opt.el

[Mark Oteiza]

On 29/07/17 at 10:03pm, Andreas Schwab wrote:
>On Jul 29 2017, Mark Oteiza <mvoteiza@udel.edu> wrote:
>
>> On 29/07/17 at 08:22pm, Eli Zaretskii wrote:
>>>> From: Mark Oteiza <mvoteiza@udel.edu>
>>>> Date: Sat, 29 Jul 2017 12:43:51 -0400
>>>> Cc: emacs-devel@gnu.org
>>>>
>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>
>>>> >> (let ((pure-fns
>>>> >> -       '(concat symbol-name regexp-opt regexp-quote string-to-syntax)))
>>>> >> +       '(concat symbol-name regexp-opt regexp-quote string-to-syntax
>>>> >> +         make-vector)))
>>>> >
>>>> > Ah, now that makes a lot more sense: make-vector is much less pure than
>>>> > string-to-char.  The above will cause the compiler to replace
>>>> >
>>>> >    (make-vector 2 ?a)
>>>> >
>>>> > with
>>>> >
>>>> >    [?a ?a]
>>>> >
>>>> > so you end with a single immediate vector being re-used over and over,
>>>> > instead of having a new vector created each time.
>>>>
>>>> But reading a literal vector still generates a new vector, no?
>>>
>>>Why do you assume it will be read?
>>
>> I guess because I don't understand how bytecode is executed.
>
>This has nothing to do with bytecode.  Try this:
>
>(let ((i 0) r)
>  (while (< i 2)
>    (let ((v (make-vector 2 0)))
>      (aset v i i)
>      (push v r))
>    (setq i (1+ i)))
>  r)

I see.  Thanks Andreas.

Re: pure-fns in byte-opt.el

[Eli Zaretskii]

> Date: Wed, 26 Jul 2017 22:36:08 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: schwab@suse.de, emacs-devel@gnu.org
> 
> >If you could run the offending command under a debugger and show both
> >C-level and Lisp-level backtrace from the error, maybe we could become
> >wiser.  (Let me know if you need help in staging the experiment and/or
> >collecting the data after you catch the error.)
> 
> Here is the point during the build the error happens:
> 
> "../../src/bootstrap-emacs" -batch --no-site-file --no-site-lisp -L . -l
> unidata-gen \
>   -f unidata-gen-file ../../lisp/international/uni-decomposition.el .
>   Loading macroexp.elc...
>   Wrong type argument: listp, "頩"
> 
> I set a breakpoint at wrong_type_argument
> 
> Thread 1 "bootstrap-emacs" hit Breakpoint 4, wrong_type_argument (
> predicate=XIL(0x8550), value=XIL(0x3dee414)) at data.c:154
> 154       xsignal2 (Qwrong_type_argument, predicate, value);
> (gdb) xbacktrace
> "unidata-gen-table-word-list" (0xffffb690)
> "unidata-gen-table-decomposition" (0xffffbb20)
> "unidata-gen-file" (0xffffc108)
> "funcall" (0xffffc100)
> "if" (0xffffc2c0)
> "cond" (0xffffc430)
> "let*" (0xffffc5d0)
> "while" (0xffffc760)
> "let*" (0xffffc900)
> "progn" (0xffffca30)
> "if" (0xffffcb70)
> "let" (0xffffcd50)
> "let" (0xffffcf30)
> "command-line-1" (0xffffd0b0)
> "command-line" (0xffffd300)
> "unwind-protect" (0xffffd4f0)
> "let" (0xffffd6d0)
> "if" (0xffffd840)
> "normal-top-level" (0xffffd9c0)
> 
> I would need help with digging deeper.

Is this still relevant, i.e. do you still want to understand the
details of the problem?  If so, please show the C-level backtrace (the
result of the "bt" command), and I will try to tell you where to look
for those details.

Thanks.

Re: pure-fns in byte-opt.el

[Mark Oteiza]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

On 27/07/17 at 08:06pm, Eli Zaretskii wrote:
>> Date: Wed, 26 Jul 2017 22:36:08 -0400
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Cc: schwab@suse.de, emacs-devel@gnu.org
>>
>> >If you could run the offending command under a debugger and show both
>> >C-level and Lisp-level backtrace from the error, maybe we could become
>> >wiser.  (Let me know if you need help in staging the experiment and/or
>> >collecting the data after you catch the error.)
>>
>> Here is the point during the build the error happens:
>>
>> "../../src/bootstrap-emacs" -batch --no-site-file --no-site-lisp -L . -l
>> unidata-gen \
>>   -f unidata-gen-file ../../lisp/international/uni-decomposition.el .
>>   Loading macroexp.elc...
>>   Wrong type argument: listp, "頩"
>>
>> I set a breakpoint at wrong_type_argument
>>
>> Thread 1 "bootstrap-emacs" hit Breakpoint 4, wrong_type_argument (
>> predicate=XIL(0x8550), value=XIL(0x3dee414)) at data.c:154
>> 154       xsignal2 (Qwrong_type_argument, predicate, value);
>> (gdb) xbacktrace
>> <snip>
>>
>> I would need help with digging deeper.
>
>Is this still relevant, i.e. do you still want to understand the
>details of the problem?  If so, please show the C-level backtrace (the
>result of the "bt" command), and I will try to tell you where to look
>for those details.

Yes, I'd like to better understand what is going on here.  Looking at
Fmake_vector and read_vector, I see that calling make-vector and reading
a literal vector do very different things, but how this ultimately
results in the error is not obvious to me.


[-- Attachment #2: btfull.txt --]
[-- Type: text/plain, Size: 39128 bytes --]

#0  0x00000000005eb363 in wrong_type_argument (predicate=XIL(0x8550), value=XIL(0x3df5914)) at data.c:154
#1  0x000000000065ed98 in exec_byte_code (bytestr=XIL(0x2d8cb34), vector=XIL(0x17aec35), maxdepth=make_number(13), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:512
        op = 64
        type = CATCHER
        targets = 
          {0x662c4e <exec_byte_code+17943>, 0x662cb3 <exec_byte_code+18044>, 0x662cb5 <exec_byte_code+18046>, 0x662cb7 <exec_byte_code+18048>, 0x662cb9 <exec_byte_code+18050>, 0x662cb9 <exec_byte_code+18050>, 0x662d36 <exec_byte_code+18175>, 0x662dc5 <exec_byte_code+18318>, 0x65eb5a <exec_byte_code+1315>, 0x65eb5c <exec_byte_code+1317>, 0x65eb5e <exec_byte_code+1319>, 0x65eb60 <exec_byte_code+1321>, 0x65eb62 <exec_byte_code+1323>, 0x65eb62 <exec_byte_code+1323>, 0x65eb6b <exec_byte_code+1332>, 0x65eb17 <exec_byte_code+1248>, 0x65ef9f <exec_byte_code+2408>, 0x65efa1 <exec_byte_code+2410>, 0x65efa3 <exec_byte_code+2412>, 0x65efa5 <exec_byte_code+2414>, 0x65efa7 <exec_byte_code+2416>, 0x65efa7 <exec_byte_code+2416>, 0x65eff1 <exec_byte_code+2490>, 0x65efb0 <exec_byte_code+2425>, 0x65f1ff <exec_byte_code+3016>, 0x65f201 <exec_byte_code+3018>, 0x65f203 <exec_byte_code+3020>, 0x65f205 <exec_byte_code+3022>, 0x65f207 <exec_byte_code+3024>, 0x65f207 <exec_byte_code+3024>, 0x65f19e <exec_byte_code+2919>, 0x65f1be <exec_byte_code+2951>, 0x65f2e5 <exec_byte_code+3246>, 0x65f2e7 <exec_byte_code+3248>, 0x65f2e9 <exec_byte_code+3250>, 0x65f2eb <exec_byte_code+3252>, 0x65f2ed <exec_byte_code+3254>, 0x65f2ed <exec_byte_code+3254>, 0x65f284 <exec_byte_code+3149>, 0x65f2a4 <exec_byte_code+3181>, 0x65f3d3 <exec_byte_code+3484>, 0x65f3d5 <exec_byte_code+3486>, 0x65f3d7 <exec_byte_code+3488>, 0x65f3d9 <exec_byte_code+3490>, 0x65f3db <exec_byte_code+3492>, 0x65f3db <exec_byte_code+3492>, 0x65f372 <exec_byte_code+3387>, 0x65f392 <exec_byte_code+3419>, 0x65fe1c <exec_byte_code+6117>, 0x65fce4 <exec_byte_code+5805>, 0x65fcd8 <exec_byte_code+5793>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x6600b6 <exec_byte_code+6783>, 0x6601c7 <exec_byte_code+7056>, 0x660246 <exec_byte_code+7183>, 0x6602c6 <exec_byte_code+7311>, 0x660347 <exec_byte_code+7440>, 0x65edd6 <exec_byte_code+1951>, 0x65ee76 <exec_byte_code+2111>, 0x6603e0 <exec_byte_code+7593>, 0x65ed2e <exec_byte_code+1783>, 0x65eef6 <exec_byte_code+2239>, 0x660467 <exec_byte_code+7728>, 0x6604e7 <exec_byte_code+7856>, 0x660541 <exec_byte_code+7946>, 0x6605c1 <exec_byte_code+8074>, 0x660628 <exec_byte_code+8177>, 0x660732 <exec_byte_code+8443>, 0x66078c <exec_byte_code+8533>, 0x66080c <exec_byte_code+8661>, 0x6608af <exec_byte_code+8824>, 0x660909 <exec_byte_code+8914>, 0x660963 <exec_byte_code+9004>, 0x6609e3 <exec_byte_code+9132>, 0x660a63 <exec_byte_code+9260>, 0x660ae3 <exec_byte_code+9388>, 0x660b86 <exec_byte_code+9551>, 0x660bed <exec_byte_code+9654>, 0x660c54 <exec_byte_code+9757>, 0x660d5e <exec_byte_code+10023>, 0x660df3 <exec_byte_code+10172>, 0x660e88 <exec_byte_code+10321>, 0x661072 <exec_byte_code+10811>, 0x6610f7 <exec_byte_code+10944>, 0x66117c <exec_byte_code+11077>, 0x661201 <exec_byte_code+11210>, 0x661286 <exec_byte_code+11343>, 0x6612ed <exec_byte_code+11446>, 0x661386 <exec_byte_code+11599>, 0x6613ed <exec_byte_code+11702>, 0x661454 <exec_byte_code+11805>, 0x6614bb <exec_byte_code+11908>, 0x661609 <exec_byte_code+12242>, 0x65fb1c <exec_byte_code+5349>, 0x661679 <exec_byte_code+12354>, 0x6616d3 <exec_byte_code+12444>, 0x6617d5 <exec_byte_code+12702>, 0x661850 <exec_byte_code+12825>, 0x6618c0 <exec_byte_code+12937>, 0x66191a <exec_byte_code+13027>, 0x661972 <exec_byte_code+13115>, 0x6619ca <exec_byte_code+13203>, 0x661a2a <exec_byte_code+13299>, 0x662c4e <exec_byte_code+17943>, 0x661a94 <exec_byte_code+13405>, 0x661aec <exec_byte_code+13493>, 0x661b44 <exec_byte_code+13581>, 0x661b9c <exec_byte_code+13669>, 0x661bf4 <exec_byte_code+13757>, 0x661c4c <exec_byte_code+13845>, 0x65fb1c <exec_byte_code+5349>, 0x662c4e <exec_byte_code+17943>, 0x661ca6 <exec_byte_code+13935>, 0x661d0d <exec_byte_code+14038>, 0x661d67 <exec_byte_code+14128>, 0x661dc1 <exec_byte_code+14218>, 0x661e41 <exec_byte_code+14346>, 0x661ec1 <exec_byte_code+14474>, 0x661f1b <exec_byte_code+14564>, 0x662030 <exec_byte_code+14841>, 0x6620b0 <exec_byte_code+14969>, 0x662130 <exec_byte_code+15097>, 0x6621b0 <exec_byte_code+15225>, 0x662208 <exec_byte_code+15313>, 0x662c4e <exec_byte_code+17943>, 0x65fa1d <exec_byte_code+5094>, 0x65f4ab <exec_byte_code+3700>, 0x65ec7b <exec_byte_code+1604>, 0x65f59a <exec_byte_code+3939>, 0x65f63f <exec_byte_code+4104>, 0x65f6e1 <exec_byte_code+4266>, 0x65f9bf <exec_byte_code+5000>, 0x65f9d7 <exec_byte_code+5024>, 0x65f136 <exec_byte_code+2815>, 0x65fac7 <exec_byte_code+5264>, 0x65fb5f <exec_byte_code+5416>, 0x65fbfc <exec_byte_code+5573>, 0x65fc51 <exec_byte_code+5658>, 0x65fe74 <exec_byte_code+6205>, 0x65ff03 <exec_byte_code+6348>, 0x65ffa6 <exec_byte_code+6511>, 0x66001b <exec_byte_code+6628>, 0x65f44e <exec_byte_code+3607>, 0x662262 <exec_byte_code+15403>, 0x662305 <exec_byte_code+15566>, 0x66235f <exec_byte_code+15656>, 0x6623b9 <exec_byte_code+15746>, 0x662413 <exec_byte_code+15836>, 0x66246d <exec_byte_code+15926>, 0x6624ed <exec_byte_code+16054>, 0x66256d <exec_byte_code+16182>, 0x6625ed <exec_byte_code+16310>, 0x66266d <exec_byte_code+16438>, 0x6627d8 <exec_byte_code+16801>, 0x662858 <exec_byte_code+16929>, 0x6628d8 <exec_byte_code+17057>, 0x662932 <exec_byte_code+17147>, 0x6629b2 <exec_byte_code+17275>, 0x662a32 <exec_byte_code+17403>, 0x662a8c <exec_byte_code+17493>, 0x662ae6 <exec_byte_code+17583>, 0x661522 <exec_byte_code+12011>, 0x661589 <exec_byte_code+12114>, 0x662b4d <exec_byte_code+17686>, 0x662bce <exec_byte_code+17815>, 0x662c4e <exec_byte_code+17943>, 0x65f783 <exec_byte_code+4428>, 0x65f7a9 <exec_byte_code+4466>, 0x65f830 <exec_byte_code+4601>, 0x65f8b7 <exec_byte_code+4736>, 0x65f93b <exec_byte_code+4868>, 0x66068f <exec_byte_code+8280>, 0x660cbb <exec_byte_code+9860>, 0x661732 <exec_byte_code+12539>, 0x662e7f <exec_byte_code+18504>, 0x662f09 <exec_byte_code+18642>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662fc0 <exec_byte_code+18825>, 0x663071 <exec_byte_code+19002>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x663277 <exec_byte_code+19520> <repeats 64 times>}
        const_length = 69
        bytestr_length = 853
        vectorp = 0x17aec38 <bss_sbrk_buffer+11202424>
        quitcounter = 140 '\214'
        stack_items = 14
        sa_avail = 15419
        sa_count = 62
        sa_must_free = false
        stack_base = 0x7fffffffae70
        stack_lim = 0x7fffffffaee0
        top = 0x7fffffffae78
        void_stack_lim = 0x7fffffffaee0
        bytestr_data = 0x7fffffffaee0 "\306\307!\310Cȉ\211\211\211\211\211\211\211\211\030\031\032\033\034\035\036,\036-\036.\036/\036\060\036\061\016\062\025\311\026,\r\203\352\001\r@\024\rA\025\f@\023\016\063\016\064\f8!\211\022:\203\276"
        pc = 0x7fffffffb17a "\211\024\250\203\244\002\f\202\251\002\f\016\060\236A\026C\r\346\016C!\240\210\rA\211\025\204\230\002\016:\016=\347\350\016:\016=H\351#I\210+\016=T\211\026=\202u\002*\331\016\061\t\211\325\\B\347\350\016:\351##\210*\016=T\211\026=\202S\002*\335\016.G\310\"\026-\330\021\016.\310\034\211\036?\203<\003\016?@\211\024A\310\036D\211\036?\203(\003\016?@\026D\331\016\061\016D\tT#\210\016?A\211\026?\204\021\003*\016-\t\f@I\210\tT\021\016?A\211\026?\204\002\003*\352\016\061\330\016\065#\210\352\016\061\353\016/\016-B#\210\016\061.\f\207"
        count = 62
        result = XIL(0x7fffffffb4c0)
#2  0x000000000060fe4d in funcall_lambda (fun=XIL(0x17aee65), nargs=3, arg_vector=0x17aec35 <bss_sbrk_buffer+11202421>) at eval.c:3023
        val = XIL(0x20b1040)
        syms_left = XIL(0)
        next = XIL(0x20abfb0)
        lexenv = XIL(0)
        count = 59
        i = 3
        optional = false
        rest = false
        previous_optional_or_rest = false
#3  0x000000000060f09b in Ffuncall (nargs=4, args=0x7fffffffb688) at eval.c:2742
        fun = XIL(0x17aee65)
        original_fun = XIL(0x20b0da0)
        funcar = XIL(0xce8cc0)
        numargs = 3
        val = make_number(897379714801469509)
        count = 58
#4  0x000000000065f327 in exec_byte_code (bytestr=XIL(0x2d8e2f4), vector=XIL(0x17b0ebd), maxdepth=make_number(4), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:629
        op = 3
        type = CATCHER
        targets = 
          {0x662c4e <exec_byte_code+17943>, 0x662cb3 <exec_byte_code+18044>, 0x662cb5 <exec_byte_code+18046>, 0x662cb7 <exec_byte_code+18048>, 0x662cb9 <exec_byte_code+18050>, 0x662cb9 <exec_byte_code+18050>, 0x662d36 <exec_byte_code+18175>, 0x662dc5 <exec_byte_code+18318>, 0x65eb5a <exec_byte_code+1315>, 0x65eb5c <exec_byte_code+1317>, 0x65eb5e <exec_byte_code+1319>, 0x65eb60 <exec_byte_code+1321>, 0x65eb62 <exec_byte_code+1323>, 0x65eb62 <exec_byte_code+1323>, 0x65eb6b <exec_byte_code+1332>, 0x65eb17 <exec_byte_code+1248>, 0x65ef9f <exec_byte_code+2408>, 0x65efa1 <exec_byte_code+2410>, 0x65efa3 <exec_byte_code+2412>, 0x65efa5 <exec_byte_code+2414>, 0x65efa7 <exec_byte_code+2416>, 0x65efa7 <exec_byte_code+2416>, 0x65eff1 <exec_byte_code+2490>, 0x65efb0 <exec_byte_code+2425>, 0x65f1ff <exec_byte_code+3016>, 0x65f201 <exec_byte_code+3018>, 0x65f203 <exec_byte_code+3020>, 0x65f205 <exec_byte_code+3022>, 0x65f207 <exec_byte_code+3024>, 0x65f207 <exec_byte_code+3024>, 0x65f19e <exec_byte_code+2919>, 0x65f1be <exec_byte_code+2951>, 0x65f2e5 <exec_byte_code+3246>, 0x65f2e7 <exec_byte_code+3248>, 0x65f2e9 <exec_byte_code+3250>, 0x65f2eb <exec_byte_code+3252>, 0x65f2ed <exec_byte_code+3254>, 0x65f2ed <exec_byte_code+3254>, 0x65f284 <exec_byte_code+3149>, 0x65f2a4 <exec_byte_code+3181>, 0x65f3d3 <exec_byte_code+3484>, 0x65f3d5 <exec_byte_code+3486>, 0x65f3d7 <exec_byte_code+3488>, 0x65f3d9 <exec_byte_code+3490>, 0x65f3db <exec_byte_code+3492>, 0x65f3db <exec_byte_code+3492>, 0x65f372 <exec_byte_code+3387>, 0x65f392 <exec_byte_code+3419>, 0x65fe1c <exec_byte_code+6117>, 0x65fce4 <exec_byte_code+5805>, 0x65fcd8 <exec_byte_code+5793>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x6600b6 <exec_byte_code+6783>, 0x6601c7 <exec_byte_code+7056>, 0x660246 <exec_byte_code+7183>, 0x6602c6 <exec_byte_code+7311>, 0x660347 <exec_byte_code+7440>, 0x65edd6 <exec_byte_code+1951>, 0x65ee76 <exec_byte_code+2111>, 0x6603e0 <exec_byte_code+7593>, 0x65ed2e <exec_byte_code+1783>, 0x65eef6 <exec_byte_code+2239>, 0x660467 <exec_byte_code+7728>, 0x6604e7 <exec_byte_code+7856>, 0x660541 <exec_byte_code+7946>, 0x6605c1 <exec_byte_code+8074>, 0x660628 <exec_byte_code+8177>, 0x660732 <exec_byte_code+8443>, 0x66078c <exec_byte_code+8533>, 0x66080c <exec_byte_code+8661>, 0x6608af <exec_byte_code+8824>, 0x660909 <exec_byte_code+8914>, 0x660963 <exec_byte_code+9004>, 0x6609e3 <exec_byte_code+9132>, 0x660a63 <exec_byte_code+9260>, 0x660ae3 <exec_byte_code+9388>, 0x660b86 <exec_byte_code+9551>, 0x660bed <exec_byte_code+9654>, 0x660c54 <exec_byte_code+9757>, 0x660d5e <exec_byte_code+10023>, 0x660df3 <exec_byte_code+10172>, 0x660e88 <exec_byte_code+10321>, 0x661072 <exec_byte_code+10811>, 0x6610f7 <exec_byte_code+10944>, 0x66117c <exec_byte_code+11077>, 0x661201 <exec_byte_code+11210>, 0x661286 <exec_byte_code+11343>, 0x6612ed <exec_byte_code+11446>, 0x661386 <exec_byte_code+11599>, 0x6613ed <exec_byte_code+11702>, 0x661454 <exec_byte_code+11805>, 0x6614bb <exec_byte_code+11908>, 0x661609 <exec_byte_code+12242>, 0x65fb1c <exec_byte_code+5349>, 0x661679 <exec_byte_code+12354>, 0x6616d3 <exec_byte_code+12444>, 0x6617d5 <exec_byte_code+12702>, 0x661850 <exec_byte_code+12825>, 0x6618c0 <exec_byte_code+12937>, 0x66191a <exec_byte_code+13027>, 0x661972 <exec_byte_code+13115>, 0x6619ca <exec_byte_code+13203>, 0x661a2a <exec_byte_code+13299>, 0x662c4e <exec_byte_code+17943>, 0x661a94 <exec_byte_code+13405>, 0x661aec <exec_byte_code+13493>, 0x661b44 <exec_byte_code+13581>, 0x661b9c <exec_byte_code+13669>, 0x661bf4 <exec_byte_code+13757>, 0x661c4c <exec_byte_code+13845>, 0x65fb1c <exec_byte_code+5349>, 0x662c4e <exec_byte_code+17943>, 0x661ca6 <exec_byte_code+13935>, 0x661d0d <exec_byte_code+14038>, 0x661d67 <exec_byte_code+14128>, 0x661dc1 <exec_byte_code+14218>, 0x661e41 <exec_byte_code+14346>, 0x661ec1 <exec_byte_code+14474>, 0x661f1b <exec_byte_code+14564>, 0x662030 <exec_byte_code+14841>, 0x6620b0 <exec_byte_code+14969>, 0x662130 <exec_byte_code+15097>, 0x6621b0 <exec_byte_code+15225>, 0x662208 <exec_byte_code+15313>, 0x662c4e <exec_byte_code+17943>, 0x65fa1d <exec_byte_code+5094>, 0x65f4ab <exec_byte_code+3700>, 0x65ec7b <exec_byte_code+1604>, 0x65f59a <exec_byte_code+3939>, 0x65f63f <exec_byte_code+4104>, 0x65f6e1 <exec_byte_code+4266>, 0x65f9bf <exec_byte_code+5000>, 0x65f9d7 <exec_byte_code+5024>, 0x65f136 <exec_byte_code+2815>, 0x65fac7 <exec_byte_code+5264>, 0x65fb5f <exec_byte_code+5416>, 0x65fbfc <exec_byte_code+5573>, 0x65fc51 <exec_byte_code+5658>, 0x65fe74 <exec_byte_code+6205>, 0x65ff03 <exec_byte_code+6348>, 0x65ffa6 <exec_byte_code+6511>, 0x66001b <exec_byte_code+6628>, 0x65f44e <exec_byte_code+3607>, 0x662262 <exec_byte_code+15403>, 0x662305 <exec_byte_code+15566>, 0x66235f <exec_byte_code+15656>, 0x6623b9 <exec_byte_code+15746>, 0x662413 <exec_byte_code+15836>, 0x66246d <exec_byte_code+15926>, 0x6624ed <exec_byte_code+16054>, 0x66256d <exec_byte_code+16182>, 0x6625ed <exec_byte_code+16310>, 0x66266d <exec_byte_code+16438>, 0x6627d8 <exec_byte_code+16801>, 0x662858 <exec_byte_code+16929>, 0x6628d8 <exec_byte_code+17057>, 0x662932 <exec_byte_code+17147>, 0x6629b2 <exec_byte_code+17275>, 0x662a32 <exec_byte_code+17403>, 0x662a8c <exec_byte_code+17493>, 0x662ae6 <exec_byte_code+17583>, 0x661522 <exec_byte_code+12011>, 0x661589 <exec_byte_code+12114>, 0x662b4d <exec_byte_code+17686>, 0x662bce <exec_byte_code+17815>, 0x662c4e <exec_byte_code+17943>, 0x65f783 <exec_byte_code+4428>, 0x65f7a9 <exec_byte_code+4466>, 0x65f830 <exec_byte_code+4601>, 0x65f8b7 <exec_byte_code+4736>, 0x65f93b <exec_byte_code+4868>, 0x66068f <exec_byte_code+8280>, 0x660cbb <exec_byte_code+9860>, 0x661732 <exec_byte_code+12539>, 0x662e7f <exec_byte_code+18504>, 0x662f09 <exec_byte_code+18642>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662fc0 <exec_byte_code+18825>, 0x663071 <exec_byte_code+19002>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x663277 <exec_byte_code+19520> <repeats 64 times>}
        const_length = 14
        bytestr_length = 40
        vectorp = 0x17b0ec0 <bss_sbrk_buffer+11211264>
        quitcounter = 1 '\001'
        stack_items = 5
        sa_avail = 16304
        sa_count = 58
        sa_must_free = false
        stack_base = 0x7fffffffb680
        stack_lim = 0x7fffffffb6a8
        top = 0x7fffffffb688
        void_stack_lim = 0x7fffffffb6a8
        bytestr_data = 0x7fffffffb6a8 "\304\b\t\305#\032\306\n\307\"\033\310\311\312\"\210\313\n\314\311K#\210\313\n\315\312K#\210\313\n\307\v@#\210\n*\207 \272\377\377\377\177"
        pc = 0x7fffffffb6ad "\032\306\n\307\"\033\310\311\312\"\210\313\n\314\311K#\210\313\n\315\312K#\210\313\n\307\v@#\210\n*\207 \272\377\377\377\177"
        count = 58
        result = XIL(0x5599e1)
#5  0x000000000060fe4d in funcall_lambda (fun=XIL(0x17b0f35), nargs=4, arg_vector=0x17b0ebd <bss_sbrk_buffer+11211261>) at eval.c:3023
        val = XIL(0x3dbdab3)
        syms_left = XIL(0)
        next = XIL(0xe83d0)
        lexenv = XIL(0)
        count = 55
        i = 4
        optional = false
        rest = true
        previous_optional_or_rest = false
#6  0x000000000060f09b in Ffuncall (nargs=5, args=0x7fffffffbb18) at eval.c:2742
        fun = XIL(0x17b0f35)
        original_fun = XIL(0x20ab1f0)
        funcar = XIL(0xce8cc0)
        numargs = 4
        val = XIL(0x104000)
        count = 54
#7  0x000000000065f327 in exec_byte_code (bytestr=XIL(0x2d8f8f4), vector=XIL(0x17bdc35), maxdepth=make_number(10), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:629
        op = 4
        type = CATCHER
        targets = 
          {0x662c4e <exec_byte_code+17943>, 0x662cb3 <exec_byte_code+18044>, 0x662cb5 <exec_byte_code+18046>, 0x662cb7 <exec_byte_code+18048>, 0x662cb9 <exec_byte_code+18050>, 0x662cb9 <exec_byte_code+18050>, 0x662d36 <exec_byte_code+18175>, 0x662dc5 <exec_byte_code+18318>, 0x65eb5a <exec_byte_code+1315>, 0x65eb5c <exec_byte_code+1317>, 0x65eb5e <exec_byte_code+1319>, 0x65eb60 <exec_byte_code+1321>, 0x65eb62 <exec_byte_code+1323>, 0x65eb62 <exec_byte_code+1323>, 0x65eb6b <exec_byte_code+1332>, 0x65eb17 <exec_byte_code+1248>, 0x65ef9f <exec_byte_code+2408>, 0x65efa1 <exec_byte_code+2410>, 0x65efa3 <exec_byte_code+2412>, 0x65efa5 <exec_byte_code+2414>, 0x65efa7 <exec_byte_code+2416>, 0x65efa7 <exec_byte_code+2416>, 0x65eff1 <exec_byte_code+2490>, 0x65efb0 <exec_byte_code+2425>, 0x65f1ff <exec_byte_code+3016>, 0x65f201 <exec_byte_code+3018>, 0x65f203 <exec_byte_code+3020>, 0x65f205 <exec_byte_code+3022>, 0x65f207 <exec_byte_code+3024>, 0x65f207 <exec_byte_code+3024>, 0x65f19e <exec_byte_code+2919>, 0x65f1be <exec_byte_code+2951>, 0x65f2e5 <exec_byte_code+3246>, 0x65f2e7 <exec_byte_code+3248>, 0x65f2e9 <exec_byte_code+3250>, 0x65f2eb <exec_byte_code+3252>, 0x65f2ed <exec_byte_code+3254>, 0x65f2ed <exec_byte_code+3254>, 0x65f284 <exec_byte_code+3149>, 0x65f2a4 <exec_byte_code+3181>, 0x65f3d3 <exec_byte_code+3484>, 0x65f3d5 <exec_byte_code+3486>, 0x65f3d7 <exec_byte_code+3488>, 0x65f3d9 <exec_byte_code+3490>, 0x65f3db <exec_byte_code+3492>, 0x65f3db <exec_byte_code+3492>, 0x65f372 <exec_byte_code+3387>, 0x65f392 <exec_byte_code+3419>, 0x65fe1c <exec_byte_code+6117>, 0x65fce4 <exec_byte_code+5805>, 0x65fcd8 <exec_byte_code+5793>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x6600b6 <exec_byte_code+6783>, 0x6601c7 <exec_byte_code+7056>, 0x660246 <exec_byte_code+7183>, 0x6602c6 <exec_byte_code+7311>, 0x660347 <exec_byte_code+7440>, 0x65edd6 <exec_byte_code+1951>, 0x65ee76 <exec_byte_code+2111>, 0x6603e0 <exec_byte_code+7593>, 0x65ed2e <exec_byte_code+1783>, 0x65eef6 <exec_byte_code+2239>, 0x660467 <exec_byte_code+7728>, 0x6604e7 <exec_byte_code+7856>, 0x660541 <exec_byte_code+7946>, 0x6605c1 <exec_byte_code+8074>, 0x660628 <exec_byte_code+8177>, 0x660732 <exec_byte_code+8443>, 0x66078c <exec_byte_code+8533>, 0x66080c <exec_byte_code+8661>, 0x6608af <exec_byte_code+8824>, 0x660909 <exec_byte_code+8914>, 0x660963 <exec_byte_code+9004>, 0x6609e3 <exec_byte_code+9132>, 0x660a63 <exec_byte_code+9260>, 0x660ae3 <exec_byte_code+9388>, 0x660b86 <exec_byte_code+9551>, 0x660bed <exec_byte_code+9654>, 0x660c54 <exec_byte_code+9757>, 0x660d5e <exec_byte_code+10023>, 0x660df3 <exec_byte_code+10172>, 0x660e88 <exec_byte_code+10321>, 0x661072 <exec_byte_code+10811>, 0x6610f7 <exec_byte_code+10944>, 0x66117c <exec_byte_code+11077>, 0x661201 <exec_byte_code+11210>, 0x661286 <exec_byte_code+11343>, 0x6612ed <exec_byte_code+11446>, 0x661386 <exec_byte_code+11599>, 0x6613ed <exec_byte_code+11702>, 0x661454 <exec_byte_code+11805>, 0x6614bb <exec_byte_code+11908>, 0x661609 <exec_byte_code+12242>, 0x65fb1c <exec_byte_code+5349>, 0x661679 <exec_byte_code+12354>, 0x6616d3 <exec_byte_code+12444>, 0x6617d5 <exec_byte_code+12702>, 0x661850 <exec_byte_code+12825>, 0x6618c0 <exec_byte_code+12937>, 0x66191a <exec_byte_code+13027>, 0x661972 <exec_byte_code+13115>, 0x6619ca <exec_byte_code+13203>, 0x661a2a <exec_byte_code+13299>, 0x662c4e <exec_byte_code+17943>, 0x661a94 <exec_byte_code+13405>, 0x661aec <exec_byte_code+13493>, 0x661b44 <exec_byte_code+13581>, 0x661b9c <exec_byte_code+13669>, 0x661bf4 <exec_byte_code+13757>, 0x661c4c <exec_byte_code+13845>, 0x65fb1c <exec_byte_code+5349>, 0x662c4e <exec_byte_code+17943>, 0x661ca6 <exec_byte_code+13935>, 0x661d0d <exec_byte_code+14038>, 0x661d67 <exec_byte_code+14128>, 0x661dc1 <exec_byte_code+14218>, 0x661e41 <exec_byte_code+14346>, 0x661ec1 <exec_byte_code+14474>, 0x661f1b <exec_byte_code+14564>, 0x662030 <exec_byte_code+14841>, 0x6620b0 <exec_byte_code+14969>, 0x662130 <exec_byte_code+15097>, 0x6621b0 <exec_byte_code+15225>, 0x662208 <exec_byte_code+15313>, 0x662c4e <exec_byte_code+17943>, 0x65fa1d <exec_byte_code+5094>, 0x65f4ab <exec_byte_code+3700>, 0x65ec7b <exec_byte_code+1604>, 0x65f59a <exec_byte_code+3939>, 0x65f63f <exec_byte_code+4104>, 0x65f6e1 <exec_byte_code+4266>, 0x65f9bf <exec_byte_code+5000>, 0x65f9d7 <exec_byte_code+5024>, 0x65f136 <exec_byte_code+2815>, 0x65fac7 <exec_byte_code+5264>, 0x65fb5f <exec_byte_code+5416>, 0x65fbfc <exec_byte_code+5573>, 0x65fc51 <exec_byte_code+5658>, 0x65fe74 <exec_byte_code+6205>, 0x65ff03 <exec_byte_code+6348>, 0x65ffa6 <exec_byte_code+6511>, 0x66001b <exec_byte_code+6628>, 0x65f44e <exec_byte_code+3607>, 0x662262 <exec_byte_code+15403>, 0x662305 <exec_byte_code+15566>, 0x66235f <exec_byte_code+15656>, 0x6623b9 <exec_byte_code+15746>, 0x662413 <exec_byte_code+15836>, 0x66246d <exec_byte_code+15926>, 0x6624ed <exec_byte_code+16054>, 0x66256d <exec_byte_code+16182>, 0x6625ed <exec_byte_code+16310>, 0x66266d <exec_byte_code+16438>, 0x6627d8 <exec_byte_code+16801>, 0x662858 <exec_byte_code+16929>, 0x6628d8 <exec_byte_code+17057>, 0x662932 <exec_byte_code+17147>, 0x6629b2 <exec_byte_code+17275>, 0x662a32 <exec_byte_code+17403>, 0x662a8c <exec_byte_code+17493>, 0x662ae6 <exec_byte_code+17583>, 0x661522 <exec_byte_code+12011>, 0x661589 <exec_byte_code+12114>, 0x662b4d <exec_byte_code+17686>, 0x662bce <exec_byte_code+17815>, 0x662c4e <exec_byte_code+17943>, 0x65f783 <exec_byte_code+4428>, 0x65f7a9 <exec_byte_code+4466>, 0x65f830 <exec_byte_code+4601>, 0x65f8b7 <exec_byte_code+4736>, 0x65f93b <exec_byte_code+4868>, 0x66068f <exec_byte_code+8280>, 0x660cbb <exec_byte_code+9860>, 0x661732 <exec_byte_code+12539>, 0x662e7f <exec_byte_code+18504>, 0x662f09 <exec_byte_code+18642>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662fc0 <exec_byte_code+18825>, 0x663071 <exec_byte_code+19002>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x662c4e <exec_byte_code+17943>, 0x663277 <exec_byte_code+19520> <repeats 64 times>}
        const_length = 73
        bytestr_length = 337
        vectorp = 0x17bdc38 <bss_sbrk_buffer+11263864>
        quitcounter = 1 '\001'
        stack_items = 11
        sa_avail = 15959
        sa_count = 34
        sa_must_free = false
        stack_base = 0x7fffffffbb10
        stack_lim = 0x7fffffffbb68
        top = 0x7fffffffbb18
        void_stack_lim = 0x7fffffffbb68
        bytestr_data = 0x7fffffffbb68 "\b\204 "
        pc = 0x7fffffffbc58 "\026A\016D\203\021\001\346\016DK!\204\t\001\347\016D!\210\016DK\026D\350\016A\342\016D#\210\351\352\016H\016A\016E$c\210.\b\016@A\211\026@\204\224"
        count = 34
        result = XIL(0)
#8  0x000000000060fe4d in funcall_lambda (fun=XIL(0x17bbec5), nargs=0, arg_vector=0x17bdc35 <bss_sbrk_buffer+11263861>) at eval.c:3023
        val = XIL(0)
        syms_left = XIL(0)
        next = XIL(0x141f5b0)
        lexenv = XIL(0)
        count = 30
        i = 0
        optional = true
        rest = false
        previous_optional_or_rest = false
#9  0x000000000060f09b in Ffuncall (nargs=1, args=0x7fffffffc100) at eval.c:2742
        fun = XIL(0x17bbec5)
        original_fun = XIL(0x20b2720)
        funcar = XIL(0xcdc060)
        numargs = 0
        val = XIL(0x1ad2313)
        count = 29
#10 0x000000000060d8f5 in eval_sub (form=XIL(0x1ad2323)) at eval.c:2187
        vals = 0x7fffffffc100
        argnum = 1
        sa_avail = 16376
        sa_count = 29
        sa_must_free = false
        args_left = XIL(0)
        numargs = make_number(1)
        fun = XIL(0xc67d9d)
        val = XIL(0x8)
        original_fun = XIL(0x6600)
        original_args = XIL(0x1ad2313)
        funcar = XIL(0x19e8c03)
        count = 28
        argvals = {XIL(0x7fffffffc1d0), XIL(0x60bdfd), XIL(0x1c), XIL(0x1d8a483), XIL(0xcdc060), XIL(0x616f33), XIL(0xcdc060), XIL(0)}
#11 0x0000000000609db0 in Fprogn (body=XIL(0x1ad22e3)) at eval.c:442
        val = XIL(0)
#12 0x0000000000609cc9 in Fif (args=XIL(0x1ad23c3)) at eval.c:400
        cond = XIL(0)
#13 0x000000000060d6b6 in eval_sub (form=XIL(0x19e8c13)) at eval.c:2169
        args_left = XIL(0x1ad23c3)
        numargs = make_number(3)
        fun = XIL(0xc6773d)
        val = XIL(0x20b2720)
        original_fun = XIL(0x7260)
        original_args = XIL(0x1ad23c3)
        funcar = XIL(0x19e8dd3)
        count = 27
        argvals = {XIL(0), XIL(0x7fffffffc340), XIL(0x1b), XIL(0x1d8a483), XIL(0xcdc060), XIL(0x7fffffffc360), XIL(0xcdc060), XIL(0x19e8db3)}
#14 0x0000000000609db0 in Fprogn (body=XIL(0x1ad22d3)) at eval.c:442
        val = XIL(0x20b2720)
#15 0x0000000000609d50 in Fcond (args=XIL(0x1b68183)) at eval.c:424
        clause = XIL(0x1b74533)
        val = XIL(0x19e8db3)
#16 0x000000000060d6b6 in eval_sub (form=XIL(0x1b256e3)) at eval.c:2169
        args_left = XIL(0x1b681a3)
        numargs = make_number(18)
        fun = XIL(0xc6776d)
        val = XIL(0x2d70714)
        original_fun = XIL(0xcfe40)
        original_args = XIL(0x1b681a3)
        funcar = XIL(0xd36d50)
        count = 26
        argvals = {XIL(0x5599e1), XIL(0xffffc4b0), XIL(0xcdc060), make_number(1404138), XIL(0), XIL(0x1d8a483), XIL(0xcdc060), XIL(0x559c7f)}
#17 0x0000000000609db0 in Fprogn (body=XIL(0x1b256f3)) at eval.c:442
        val = XIL(0x2d70714)
#18 0x000000000060abff in FletX (args=XIL(0x1a6d433)) at eval.c:891
        varlist = XIL(0)
        var = XIL(0x6876a0)
        val = XIL(0)
        elt = XIL(0x6876a0)
        lexenv = XIL(0x1dd8f83)
        count = 25
#19 0x000000000060d6b6 in eval_sub (form=XIL(0x1a6d4a3)) at eval.c:2169
        args_left = XIL(0x1a6d433)
        numargs = make_number(5)
        fun = XIL(0xc679dd)
        val = XIL(0)
        original_fun = XIL(0x8280)
        original_args = XIL(0x1a6d433)
        funcar = XIL(0x1dd8f83)
        count = 24
        argvals = {XIL(0xd49405), XIL(0x78f0), XIL(0x1dd8f83), XIL(0), XIL(0), XIL(0x66aa5ad475711600), XIL(0xcdc060), XIL(0)}
#20 0x0000000000609db0 in Fprogn (body=XIL(0x1a6d4d3)) at eval.c:442
        val = XIL(0)
#21 0x0000000000609dee in prog_ignore (body=XIL(0x1a6d4d3)) at eval.c:454
#22 0x000000000060b066 in Fwhile (args=XIL(0x1a6d4c3)) at eval.c:975
        test = XIL(0xe069e0)
        body = XIL(0x1a6d4d3)
#23 0x000000000060d6b6 in eval_sub (form=XIL(0x1a6d4b3)) at eval.c:2169
        args_left = XIL(0x1a6d4c3)
        numargs = make_number(2)
        fun = XIL(0xc67a3d)
        val = XIL(0)
        original_fun = XIL(0xcf7d0)
        original_args = XIL(0x1a6d4c3)
        funcar = XIL(0x1ad0d63)
        count = 23
        argvals = {XIL(0x5599e1), XIL(0xffffc7e0), XIL(0xcdc060), make_number(1404138), XIL(0), XIL(0x1dd8f83), XIL(0xcdc060), XIL(0x559c7f)}
#24 0x0000000000609db0 in Fprogn (body=XIL(0x1a6d4e3)) at eval.c:442
        val = XIL(0)
#25 0x000000000060abff in FletX (args=XIL(0x1a6d553)) at eval.c:891
        varlist = XIL(0)
        var = XIL(0xeaa980)
        val = XIL(0x1dd8fa3)
        elt = XIL(0x1ad0d53)
        lexenv = XIL(0x1daadd3)
        count = 22
#26 0x000000000060d6b6 in eval_sub (form=XIL(0x1a6d5c3)) at eval.c:2169
        args_left = XIL(0x1a6d553)
        numargs = make_number(4)
        fun = XIL(0xc679dd)
        val = XIL(0xce8cc0)
        original_fun = XIL(0x8280)
        original_args = XIL(0x1a6d553)
        funcar = XIL(0x5ecafc)
        count = 21
        argvals = {XIL(0x5599e1), XIL(0xffffc980), XIL(0x7fffffffc9a0), make_number(1404138), XIL(0), XIL(0), XIL(0xcdc060), XIL(0)}
#27 0x0000000000609db0 in Fprogn (body=XIL(0x1a6d5e3)) at eval.c:442
        val = XIL(0)
#28 0x000000000060d6b6 in eval_sub (form=XIL(0x1a6d5d3)) at eval.c:2169
        args_left = XIL(0x1a6d5e3)
        numargs = make_number(1)
        fun = XIL(0xc6779d)
        val = XIL(0x7fffffffcad0)
        original_fun = XIL(0xa6e0)
        original_args = XIL(0x1a6d5e3)
        funcar = XIL(0x66aa5ad475711600)
        count = 20
        argvals = {XIL(0), XIL(0x7fffffffcab0), XIL(0x5599e1), XIL(0xffffcac0), XIL(0x7fffffffcae0), make_number(1404138), XIL(0xcdc060), XIL(0x1a6d613)}
#29 0x0000000000609cab in Fif (args=XIL(0x1a6d603)) at eval.c:399
        cond = XIL(0x1bf3c73)
#30 0x000000000060d6b6 in eval_sub (form=XIL(0x1a6d5f3)) at eval.c:2169
        args_left = XIL(0x1a6d603)
        numargs = make_number(2)
        fun = XIL(0xc6773d)
        val = XIL(0x7fffffffcc30)
        original_fun = XIL(0x7260)
        original_args = XIL(0x1a6d603)
        funcar = XIL(0xeaa8c0)
        count = 19
        argvals = {XIL(0xcdc060), XIL(0x7fffffffcbf0), XIL(0), XIL(0x7fffffffcc00), XIL(0x100cdc060), XIL(0x1bf3c73), XIL(0xcdc060), XIL(0x1ae2a40)}
#31 0x0000000000609db0 in Fprogn (body=XIL(0x1a6d623)) at eval.c:442
        val = XIL(0)
#32 0x000000000060afd0 in Flet (args=XIL(0x1a6d693)) at eval.c:956
        temps = 0x7fffffffcc70
        tem = XIL(0x1bf3c73)
        lexenv = XIL(0x1daadd3)
        elt = XIL(0x1acc893)
        varlist = XIL(0)
        count = 18
        argnum = 1
        sa_avail = 16376
        sa_count = 18
        sa_must_free = false
#33 0x000000000060d6b6 in eval_sub (form=XIL(0x1a6d703)) at eval.c:2169
        args_left = XIL(0x1a6d693)
        numargs = make_number(2)
        fun = XIL(0xc67a0d)
        val = XIL(0x7fffffffcdb0)
        original_fun = XIL(0x8250)
        original_args = XIL(0x1a6d693)
        funcar = XIL(0)
        count = 17
        argvals = {XIL(0x5599e1), XIL(0), XIL(0x7fffffffce00), XIL(0x6105e5), XIL(0x100cdc060), XIL(0x1daadd3), XIL(0xcdc060), XIL(0xce3950)}
#34 0x0000000000609db0 in Fprogn (body=XIL(0x1a6d713)) at eval.c:442
        val = XIL(0)
#35 0x000000000060afd0 in Flet (args=XIL(0x1be3a43)) at eval.c:956
        temps = 0x7fffffffce50
        tem = XIL(0)
        lexenv = XIL(0x1daadd3)
        elt = XIL(0x1acc913)
        varlist = XIL(0)
        count = 16
        argnum = 1
        sa_avail = 16376
        sa_count = 16
        sa_must_free = false
#36 0x000000000060d6b6 in eval_sub (form=XIL(0x1be3ab3)) at eval.c:2169
        args_left = XIL(0x1be3a43)
        numargs = make_number(6)
        fun = XIL(0xc67a0d)
        val = XIL(0)
        original_fun = XIL(0x8250)
        original_args = XIL(0x1be3a43)
        funcar = XIL(0x3c00)
        count = 15
        argvals = {XIL(0x5599e1), XIL(0), XIL(0x7fffffffcfe0), XIL(0x6105e5), XIL(0x100cdc060), XIL(0x1daadf3), XIL(0xcdc060), XIL(0xce3950)}
#37 0x0000000000609db0 in Fprogn (body=XIL(0x1be3ac3)) at eval.c:442
        val = XIL(0)
#38 0x000000000060fdbc in funcall_lambda (fun=XIL(0x1be3403), nargs=1, arg_vector=0x0) at eval.c:3016
        val = XIL(0x1bf3c73)
        syms_left = XIL(0)
        next = XIL(0xeaa8c0)
        lexenv = XIL(0x1daadf3)
        count = 14
        i = 1
        optional = false
        rest = false
        previous_optional_or_rest = false
#39 0x000000000060f806 in apply_lambda (fun=XIL(0x1be3413), args=XIL(0x1a5b7b3), count=13) at eval.c:2877
        args_left = XIL(0)
        i = 1
        numargs = 1
        arg_vector = 0x7fffffffd0b0
        tem = XIL(0x1bf3c73)
        sa_avail = 16376
        sa_count = 14
        sa_must_free = false
#40 0x000000000060deba in eval_sub (form=XIL(0x1941403)) at eval.c:2291
        fun = XIL(0x1be3413)
        val = XIL(0x1daae13)
        original_fun = XIL(0xceaaa0)
        original_args = XIL(0x1a5b7b3)
        funcar = XIL(0x3c00)
        count = 13
        argvals = {XIL(0x1f9e10), XIL(0x1f03ad3), XIL(0x7fffffffd230), XIL(0x6105e5), XIL(0x100cdc060), XIL(0x1944de3), XIL(0xcdc060), XIL(0xce3950)}
#41 0x0000000000609db0 in Fprogn (body=XIL(0x16ae9e3)) at eval.c:442
        val = XIL(0x1daae13)
#42 0x000000000060fdbc in funcall_lambda (fun=XIL(0x16e7663), nargs=0, arg_vector=0x0) at eval.c:3016
        val = XIL(0x16e7663)
        syms_left = XIL(0)
        next = XIL(0x5599e1)
        lexenv = XIL(0x1944de3)
        count = 12
        i = 0
        optional = false
        rest = false
        previous_optional_or_rest = false
#43 0x000000000060f806 in apply_lambda (fun=XIL(0x16e7643), args=XIL(0), count=11) at eval.c:2877
        args_left = XIL(0)
        i = 0
        numargs = 0
        arg_vector = 0x7fffffffd300
        tem = XIL(0x110060d348)
        sa_avail = 16384
        sa_count = 12
        sa_must_free = false
#44 0x000000000060deba in eval_sub (form=XIL(0x1b26503)) at eval.c:2291
        fun = XIL(0x16e7643)
        val = XIL(0)
        original_fun = XIL(0xd3caa0)
        original_args = XIL(0)
        funcar = XIL(0x3c00)
        count = 11
        argvals = {XIL(0x5599e1), XIL(0xffffd440), XIL(0x7fffffffd460), make_number(1404138), XIL(0), XIL(0), XIL(0x55b258), XIL(0x66aa5ad475711600)}
#45 0x000000000060b4bd in Funwind_protect (args=XIL(0x1a86803)) at eval.c:1178
        val = XIL(0xcf890)
        count = 10
#46 0x000000000060d6b6 in eval_sub (form=XIL(0x1a86813)) at eval.c:2169
        args_left = XIL(0x1a86803)
        numargs = make_number(7)
        fun = XIL(0xc67afd)
        val = make_number(1402956)
        original_fun = XIL(0xcf890)
        original_args = XIL(0x1a86803)
        funcar = XIL(0)
        count = 9
        argvals = {XIL(0x5599e1), XIL(0), XIL(0x7fffffffd5a0), XIL(0x6105e5), XIL(0x100cdc060), XIL(0x1bfadb3), XIL(0xcdc060), XIL(0xce3950)}
#47 0x0000000000609db0 in Fprogn (body=XIL(0x1b41af3)) at eval.c:442
        val = XIL(0)
#48 0x000000000060afd0 in Flet (args=XIL(0x1b41a83)) at eval.c:956
        temps = 0x7fffffffd5f0
        tem = XIL(0x1f048f3)
        lexenv = XIL(0x1bfadb3)
        elt = XIL(0x1b26553)
        varlist = XIL(0)
        count = 8
        argnum = 1
        sa_avail = 16376
        sa_count = 8
        sa_must_free = false
#49 0x000000000060d6b6 in eval_sub (form=XIL(0x1b41a03)) at eval.c:2169
        args_left = XIL(0x1b41a83)
        numargs = make_number(2)
        fun = XIL(0xc67a0d)
        val = XIL(0x2d6ef94)
        original_fun = XIL(0x8250)
        original_args = XIL(0x1b41a83)
        funcar = XIL(0x3c00)
        count = 7
        argvals = {XIL(0xd3430), XIL(0x1f3610), XIL(0x1c419f3), XIL(0x5f), XIL(0xcdc060), XIL(0), XIL(0xcdc060), XIL(0x7fffffffd780)}
#50 0x0000000000609db0 in Fprogn (body=XIL(0x1b419e3)) at eval.c:442
        val = XIL(0x2d6ef94)
#51 0x0000000000609cc9 in Fif (args=XIL(0x1b5bab3)) at eval.c:400
        cond = XIL(0)
#52 0x000000000060d6b6 in eval_sub (form=XIL(0x1b5bac3)) at eval.c:2169
        args_left = XIL(0x1b5bab3)
        numargs = make_number(15)
        fun = XIL(0xc6773d)
        val = XIL(0xdc)
        original_fun = XIL(0x7260)
        original_args = XIL(0x1b5bab3)
        funcar = XIL(0)
        count = 6
        argvals = {XIL(0x5599e1), XIL(0), XIL(0x7fffffffd8f0), XIL(0x6105e5), XIL(0x100cdc060), XIL(0x124e5d3), XIL(0xcdc060), XIL(0xce3950)}
#53 0x0000000000609db0 in Fprogn (body=XIL(0x1b13063)) at eval.c:442
        val = XIL(0x1a18404)
#54 0x000000000060fdbc in funcall_lambda (fun=XIL(0x1b6ef23), nargs=0, arg_vector=0x0) at eval.c:3016
        val = XIL(0x1b6ef23)
        syms_left = XIL(0)
        next = XIL(0x5599e1)
        lexenv = XIL(0x124e5d3)
        count = 5
        i = 0
        optional = false
        rest = false
        previous_optional_or_rest = false
#55 0x000000000060f806 in apply_lambda (fun=XIL(0x1b6ef13), args=XIL(0), count=4) at eval.c:2877
        args_left = XIL(0)
        i = 0
        numargs = 0
        arg_vector = 0x7fffffffd9c0
        tem = XIL(0x110060d348)
        sa_avail = 16384
        sa_count = 5
        sa_must_free = false
#56 0x000000000060deba in eval_sub (form=XIL(0x129e2d3)) at eval.c:2291
        fun = XIL(0x1b6ef13)
        val = XIL(0xcdb7a0)
        original_fun = XIL(0xd97730)
        original_args = XIL(0)
        funcar = XIL(0x3c00)
        count = 4
        argvals = {XIL(0x12170a0), XIL(0xce3950), XIL(0x55b08f), XIL(0x12170a0), XIL(0x7fffffffdb40), make_number(1589789), XIL(0), XIL(0x78f0)}
#57 0x000000000060d0f0 in Feval (form=XIL(0x129e2d3), lexical=XIL(0)) at eval.c:2038
        count = 3
#58 0x0000000000562e78 in top_level_2 () at keyboard.c:1123
#59 0x000000000060b9d6 in internal_condition_case (bfun=0x562e55 <top_level_2>, handlers=XIL(0x51f0), hfun=0x5628db <cmd_error>) at eval.c:1319
        val = XIL(0x5599e1)
        c = 0x2d67800
#60 0x0000000000562ebd in top_level_1 (ignore=XIL(0)) at keyboard.c:1131
#61 0x000000000060b292 in internal_catch (tag=XIL(0xc6c0), func=0x562e7a <top_level_1>, arg=XIL(0)) at eval.c:1084
        val = XIL(0x7fffffffdc60)
        c = 0x2d676e0
#62 0x0000000000562da7 in command_loop () at keyboard.c:1092
#63 0x00000000005624ad in recursive_edit_1 () at keyboard.c:699
        count = 1
        val = XIL(0x7fffffffdcc0)
#64 0x000000000056262e in Frecursive_edit () at keyboard.c:770
        count = 0
        buffer = XIL(0)
#65 0x00000000005600ed in main (argc=12, argv=0x7fffffffdec8) at emacs.c:1706
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = true
        dumping = false
        skip_args = 2
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0
        disable_aslr = false
        rlim = {
          rlim_cur = 10022912, 
          rlim_max = 18446744073709551615
        }
        sockfd = -1
        module_assertions = false

Lisp Backtrace:
"unidata-gen-table-word-list" (0xffffb690)
"unidata-gen-table-decomposition" (0xffffbb20)
"unidata-gen-file" (0xffffc108)
"funcall" (0xffffc100)
"if" (0xffffc2c0)
"cond" (0xffffc430)
"let*" (0xffffc5d0)
"while" (0xffffc760)
"let*" (0xffffc900)
"progn" (0xffffca30)
"if" (0xffffcb70)
"let" (0xffffcd50)
"let" (0xffffcf30)
"command-line-1" (0xffffd0b0)
"command-line" (0xffffd300)
"unwind-protect" (0xffffd4f0)
"let" (0xffffd6d0)
"if" (0xffffd840)
"normal-top-level" (0xffffd9c0)

Re: pure-fns in byte-opt.el

[Eli Zaretskii]

> Date: Thu, 27 Jul 2017 20:24:48 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: schwab@suse.de, emacs-devel@gnu.org
> 
> #0  0x00000000005eb363 in wrong_type_argument (predicate=XIL(0x8550), value=XIL(0x3df5914)) at data.c:154
> #1  0x000000000065ed98 in exec_byte_code (bytestr=XIL(0x2d8cb34), vector=XIL(0x17aec35), maxdepth=make_number(13), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:512
>         op = 64
>         type = CATCHER
>         targets = 

Hmm... exec_byte_code directly above wrong_type_argument is a bit
unfortunate.  But let's try to see what we can:

> #3  0x000000000060f09b in Ffuncall (nargs=4, args=0x7fffffffb688) at eval.c:2742
>         fun = XIL(0x17aee65)
>         original_fun = XIL(0x20b0da0)
>         funcar = XIL(0xce8cc0)
>         numargs = 3
>         val = make_number(897379714801469509)
>         count = 58

In this frame #3, what are the values of the important variables?

  (gdb) frame 3
  (gdb) pp original_fun
  (gdb) pp args[1]
  (gdb) pp args[2]
  (gdb) pp args[3]
  (gdb) pp fun
  (gdb) pp funcar

(If "pp" doesn't work, make sure src/.gdbinit was read by GDB.)

Re: pure-fns in byte-opt.el

[Mark Oteiza]

On 28/07/17 at 10:02am, Eli Zaretskii wrote:
>> Date: Thu, 27 Jul 2017 20:24:48 -0400
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Cc: schwab@suse.de, emacs-devel@gnu.org
>>
>> #0  0x00000000005eb363 in wrong_type_argument (predicate=XIL(0x8550), value=XIL(0x3df5914)) at data.c:154
>> #1  0x000000000065ed98 in exec_byte_code (bytestr=XIL(0x2d8cb34), vector=XIL(0x17aec35), maxdepth=make_number(13), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:512
>>         op = 64
>>         type = CATCHER
>>         targets =
>
>Hmm... exec_byte_code directly above wrong_type_argument is a bit
>unfortunate.  But let's try to see what we can:
>
>> #3  0x000000000060f09b in Ffuncall (nargs=4, args=0x7fffffffb688) at eval.c:2742
>>         fun = XIL(0x17aee65)
>>         original_fun = XIL(0x20b0da0)
>>         funcar = XIL(0xce8cc0)
>>         numargs = 3
>>         val = make_number(897379714801469509)
>>         count = 58
>
>In this frame #3, what are the values of the important variables?
>
>  (gdb) frame 3
>  (gdb) pp original_fun

unidata-gen-table-word-list

>  (gdb) pp args[1]
>  (gdb) pp args[2]
>  (gdb) pp args[3]

decomposition
5
unidata-split-decomposition

>  (gdb) pp funcar
>  (gdb) pp fun

#<INVALID_LISP_OBJECT 0x00ce8cc0>
A\x15\f@\x13\x0e3\x0e4\f8!‰\x12:ƒ¾\0\x0e5Ê=ƒ¾\0
@Ë=ƒW\0
A@Ì=„l\0\vÍYƒ¾\0
@Î=ƒ¾\0
A@Ï=ƒ¾\0
@
@‰\x14@\x13\x0e3\x0e4\f8!‰\x12ƒª\0
:Ļ\0\x0e8
@=Ļ\0\x0e7
A‰\x15‚y\0\x0e6\x0e,B\x13\x0e8Ë=ƒ»\0Ђ¼\0Ñ\x12+\v:ƒî\0
ƒ'\0
\x0e.ž\x18\v@\vAB‰\x13A\x16ƒâ\vC¤ˆ‚ê\0
\x1e8Ö\x1e:ȉ\x1e;\x1e
È\x1e<\x0e6\x0e,Xƒ\x1f\x01\x0e1\v\x0e4\f8Iˆ‚å\x01
ƒ,\x01\x0e:\v\x0e6Z
@‰\x14@‰\x13ƒ^\x01\v¨ƒ^\x01\v\x0e9Xƒ^\x01\x0e3\x0e4\f8!‰\x12ƒW\x01\x0e:\v\x0e6Z
A‰\x15„˜\x02\x0e:\x0e=çè\x0e:\x0e=Hé#Iˆ+\x0e=T‰\x16=‚u\x02*Ù\x0e1	‰Õ\\Bçè\x0e:é##ˆ*\x0e=T‰\x16=‚S\x02*Ý\x0e.GÈ\"\x16-Ø\x11\x0e.È\x1c‰\x1e?ƒ<\x03\x0e?@‰\x14AÈ\x1eD‰\x1e?ƒ(\x03\x0e?@\x16DÙ\x0e1\x0eD	T#ˆ\x0e?A‰\x16?„\x11\x03*\x0e-	\f@Iˆ	T\x11\x0e?A‰\x16?„\x02\x03*ê\x0e1Ø\x0e5#ˆê\x0e1ë\x0e/\x0e-B#ˆ\x0e1.\f‡" [slot idx val range elt tail make-char-table char-code-property-table nil -1 name CJK COMPATIBILITY 917760 VARIATION SELECTOR CJK\ COMPATIBILITY\ IDEOGRAPH VARIATION\ SELECTOR lsh -7 7 127 ["\0\0\0\0頩" "\x01\x14\x01\x12𩖶" "\x02\x02飢" "\0\x01\x12䬳" "\0\x02餩" "\x01\x12馧" "\x02駂" "\x02駾" "\x02䯎" "\x02𩬰" "\x02鬒" "\x02鱀" "\x02鳽" "\x02䳎" "\x02䳭" "\x02鵧" "\x02𪃎" "\x02䳸" "\x02𪄅" "\x02𪈎" "\x02𪊑" "\x02麻" "\x02䵖" "\x02黹" "\x02黾" "\x02鼅" "\x02鼏" "\x02鼖" "\x02鼻" "\x02𪘀" "\x02\0菧" "\0\0\0\x01\x12著" "\0\x01\x14\x02荓" "\0\0\x01\x12菊" "\x01\x14\x02菌" "\0\x01\x12菜" "\0\x02𦰶" "\x01\x12𦵫" "\x02𦳕" "\x02䔫" "\x02蓱" "\x02蓳" "\x02蔖" "\x02𧏊" "\x02蕤" "\x02𦼬" "\x02䕝" "\x02䕡" "\x02𦾱" "\x02𧃒" "\x02䕫" "\x02虐" "\x02虜" "\x02虧" "\x02虩" "\x02蚩" "\x02蚈" "\x02蜎" "\x02蛢" "\x02蝹" "\x02蜨" "\x02蝫" "\x02螆" "\x02䗗" "\x02蟡" "\x02蠁" "\x02䗹" "\x02衠" "\x02衣" "\x02𧙧" "\x02裗" "\x02裞" "\x02䘵" "\x02裺" "\x02㒻" "\x02𧢮" "\x02𧥦" "\x02䚾" "\x02䛇" "\x02誠" "\x02諭" "\x02變" "\x02豕" "\x02𧲨" "\x02貫" "\x02賁" "\x02贛" "\x02起" "\x02𧼯" "\x02𠠄" "\x02跋" "\x02趼" "\x02跰" "\x02𠣞" "\x02軔" "\x02輸" "\x02𨗒" "\x02𨗭" "\x02邔" "\x02郱" "\x02鄑" "\x02𨜮" "\x02鄛" "\x02鈸" "\x02鋗" "\x02鋘" "\x02鉼" "\x02鏹" "\x02鐕" "\x02𨯺" "\x02開" "\x02䦕" "\x02閷" "\x02𨵷" "\x02䧦" "\x02雃" "\x02嶲" "\x02霣" "\x02𩅅" "\x02𩈚" "\x02䩮" "\x02䩶" "\x02韠" "\x02𩐊" "\x02䪲" "\x02𩒖" "\x02頋" "\0\0\0\0\x01\x11"] unidata-word-list-compress 0 set-char-table-range sort #[(x y) A	AV‡" [x y] 2] 3 make-vector decomposition 32 error "Too many symbols in decomposition data" 8704 128 vectorp "\0" string mapconcat identity "" set-char-table-extra-slot 4 block-end block-word-table block-list word-table word-list table unidata-list val-func prop-idx prop start second first limit vec c len i --dotimes-limit-- --dolist-tail-- v p v code e] 13]

Re: pure-fns in byte-opt.el

[Eli Zaretskii]

> Date: Fri, 28 Jul 2017 21:24:07 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: emacs-devel@gnu.org
> 
> >> #3  0x000000000060f09b in Ffuncall (nargs=4, args=0x7fffffffb688) at eval.c:2742
> >>         fun = XIL(0x17aee65)
> >>         original_fun = XIL(0x20b0da0)
> >>         funcar = XIL(0xce8cc0)
> >>         numargs = 3
> >>         val = make_number(897379714801469509)
> >>         count = 58
> >
> >In this frame #3, what are the values of the important variables?
> >
> >  (gdb) frame 3
> >  (gdb) pp original_fun
> 
> unidata-gen-table-word-list
> 
> >  (gdb) pp args[1]
> >  (gdb) pp args[2]
> >  (gdb) pp args[3]
> 
> decomposition
> 5
> unidata-split-decomposition
> 
> >  (gdb) pp funcar
> >  (gdb) pp fun
> 
> #<INVALID_LISP_OBJECT 0x00ce8cc0>

Thanks.

So I think the problem happens in unidata-word-list-compress, and it
happens because make-vector, which that function calls always returns
the same vector, so the vectors used by that function and created by
it are all messed up.

Re: pure-fns in byte-opt.el

[Mark Oteiza]

On 29/07/17 at 10:24am, Eli Zaretskii wrote:
>> Date: Fri, 28 Jul 2017 21:24:07 -0400
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Cc: emacs-devel@gnu.org
>>
>> >> #3  0x000000000060f09b in Ffuncall (nargs=4, args=0x7fffffffb688) at eval.c:2742
>> >>         fun = XIL(0x17aee65)
>> >>         original_fun = XIL(0x20b0da0)
>> >>         funcar = XIL(0xce8cc0)
>> >>         numargs = 3
>> >>         val = make_number(897379714801469509)
>> >>         count = 58
>> >
>> >In this frame #3, what are the values of the important variables?
>> >
>> >  (gdb) frame 3
>> >  (gdb) pp original_fun
>>
>> unidata-gen-table-word-list
>>
>> >  (gdb) pp args[1]
>> >  (gdb) pp args[2]
>> >  (gdb) pp args[3]
>>
>> decomposition
>> 5
>> unidata-split-decomposition
>>
>> >  (gdb) pp funcar
>> >  (gdb) pp fun
>>
>> #<INVALID_LISP_OBJECT 0x00ce8cc0>
>
>Thanks.
>
>So I think the problem happens in unidata-word-list-compress, and it
>happens because make-vector, which that function calls always returns
>the same vector, so the vectors used by that function and created by
>it are all messed up.

I don't follow: why does it always return the same vector?  That
particular call to make-vector should be unaffected by make-vector being
marked pure, because its arguments aren't constants.  OTOH, the form
(make-vector 128 nil) would indeed get byte-compiled into the constant
[nil nil … nil]

Re: pure-fns in byte-opt.el

[Eli Zaretskii]

> Date: Sat, 29 Jul 2017 12:34:46 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: emacs-devel@gnu.org
> 
> >So I think the problem happens in unidata-word-list-compress, and it
> >happens because make-vector, which that function calls always returns
> >the same vector, so the vectors used by that function and created by
> >it are all messed up.
> 
> I don't follow: why does it always return the same vector?

That's how I understand what the byte compiler does when you declare
that function "pure".

> That
> particular call to make-vector should be unaffected by make-vector being
> marked pure, because its arguments aren't constants.

Sorry, I meant the make-vector call in unidata-gen-table-word-list,
whose result is passed to unidata-word-list-compress.

> OTOH, the form
> (make-vector 128 nil) would indeed get byte-compiled into the constant
> [nil nil … nil]

The problem, I think, is not with a single call, but with that call
being in a loop, and the code expects each iteration to produce a new
vector.

Re: pure-fns in byte-opt.el

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Sa., 29. Juli 2017 um 19:22 Uhr:

> > Date: Sat, 29 Jul 2017 12:34:46 -0400
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Cc: emacs-devel@gnu.org
> >
> > >So I think the problem happens in unidata-word-list-compress, and it
> > >happens because make-vector, which that function calls always returns
> > >the same vector, so the vectors used by that function and created by
> > >it are all messed up.
> >
> > I don't follow: why does it always return the same vector?
>
> That's how I understand what the byte compiler does when you declare
> that function "pure".
>

That sounds like a bug. Optimization shouldn't change semantics. Either we
need to change the definition of "pure" to something far more restrictive,
or we should fix the optimizer.

[-- Attachment #2: Type: text/html, Size: 1286 bytes --]

Re: pure-fns in byte-opt.el

[Stefan Monnier]

>> > >So I think the problem happens in unidata-word-list-compress, and it
>> > >happens because make-vector, which that function calls always returns
>> > >the same vector, so the vectors used by that function and created by
>> > >it are all messed up.
>> > I don't follow: why does it always return the same vector?
>> That's how I understand what the byte compiler does when you declare
>> that function "pure".
> That sounds like a bug.

Yes, it's a bug to say that `make-vector' is pure.


        Stefan

Re: pure-fns in byte-opt.el

[John Wiegley]

>>>>> "PS" == Philipp Stephani <p.stephani2@gmail.com> writes:

PS> That sounds like a bug. Optimization shouldn't change semantics. Either we
PS> need to change the definition of "pure" to something far more restrictive,
PS> or we should fix the optimizer.

Agreed, optimization should mean only making things faster or more efficient,
not ever changing the answer or the behavior.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2