help-gnu-emacs
[Top][All Lists]
Advanced

[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?

--



reply via email to

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