[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Invalid function error when loading elisp through native compilation
From: |
tpeplt |
Subject: |
Re: Invalid function error when loading elisp through native compilation |
Date: |
Sun, 03 Mar 2024 20:22:43 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
tpeplt <tpeplt@gmail.com> writes:
>
> 1. The URL you provided does not give access to the file
> ‘my-repo-pins.el’ within Emacs. Here is a URL that other readers should
> be able to use in order to view your source file:
>
> https://raw.githubusercontent.com/picnoir/my-repo-pins/master/my-repo-pins.el
>
> 2. After downloading your source file, I loaded it into Emacs using:
>
> $ emacs -Q my-repo-pins.el
>
> 3. I then byte-compiled the file and loaded it into Emacs using the
> ‘Emacs-Lisp’ menu entry ‘Byte compile and Load’. (There were a number
> of warnings about the use of single quotes in several functions’
> docstrings due to a new syntax requirement, but those can be ignored for
> this discussion.)
>
> 4. I switched to the *scratch* buffer and evaluated the following
> expression using C-x C-e:
>
> (my-repo-pins--clone-project "test/test")
>
> This caused the debugger to be triggered and a stack trace ("backtrace")
> of function calls was generated. That backtrace is included at the end
> of this message in case you or any readers might be able to follow it to
> point out some error(s).
>
> Note that I did NOT compile the elisp file natively. The error was
> generated after byte-compiling the file only. The positive point from
> this is that backtrace might be useful for finding the source of the
> problem, and eliminating it from the natively-compiled version, too.
>
The stack trace above is repeatable if these steps above are followed
(and using Emacs 29.2 on GNU/Linux). And it is repeatable if step 4 is
followed after exiting the debugger and re-evaluating the expression.
However, if the function ‘my-repo-pins--query-forge-fetchers’ is
instrumented, and the expression
(my-repo-pins--clone-project "test/test")
is evaluated, then the debugger is NOT triggered and the expression
returns the result
(#<buffer *http api.github.com:443*-280838> nil nil #<buffer *http
codeberg.org:443*-939883>)
is returned. Before it is returned, the code displays a buffer with a
prompt:
"Please select the forge we should clone the project from.
Press q to close this window."
After type ‘q’, the result above is returned.
What does it mean that there are different results depending on whether
the elisp code has been byte-compiled or has been instrumented? Is this
an indication of an error in the byte-compiler?
--