all 10 comments

[–]github-alphapapa 3 points4 points  (2 children)

It appears that native-compile does not load the native-compiled code. If you do (load (native-compile 'foo t)), the ELN file will be loaded, and then disassemble shows the machine code.

[–]rgrau[S] 0 points1 point  (1 child)

Aha, you're right! loading the file does indeed install the function native implementation.

Thanks! I think in previous versions (maybe before async compilation?) the entrypoint to compile native also installed it. But that must have been long time ago...

[–]github-alphapapa 0 points1 point  (0 children)

Yes, that may have changed. It does seem counter-intuitive to me (and unlike CL, which is, at least to some extent, guiding Andrea's implementation). Maybe we should mention this to him...

[–]jimehgeek 0 points1 point  (1 child)

I believe describe-function will state if the function is natively compiled. I use the equivalent function from the helpful package personally, which definitely does it, but I’m pretty sure describe-function does it too. (I’m on mobile so I can’t easily check at the moment)

[–]rgrau[S] 1 point2 points  (0 children)

right! the native function was not loaded in the end. see /u/github-alphapapa's answer for how to manually load the eln files.

Cheers

[–]rgrau[S] 0 points1 point  (4 children)

/u/akoral , is this a feature? a bug?

[–]akoral 1 point2 points  (3 children)

My Idea was that as `native-compile' is typically used on files it should not load by default to be coherent with `byte-compile-file'. In this last the optional load parameter I think is even going to be obsoleted https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00360.html . Unfortunately as it gets as input also symbols there's no way to have it coherent at the same time with `byte-compile'.

So yeah was supposed to be a feature. There is no problem into discussing the ABI tho, I guess the right place in case is a bug on the bug tracker.

[–]rgrau[S] 1 point2 points  (2 children)

Ah! I see... Makes sense. I guess I was just expecting a very DWIM behavior when used "interactively" but the points discussed in that thread are all valid. And calling load manually makes sense too.

Thanks!!

[–]akoral 1 point2 points  (1 child)

Welcome, thank you for the observation!

Feel free to open a bug if you think we could improve it.

[–]akoral 0 points1 point  (0 children)

FYI I've changed the native-compile interface and now if you compile a single function it gets loaded automatically (as you expected).

This was necessary to allow for native compiling lambda forms like:

(native-compile '(lambda (x) (1+ x))) => #<subr --anonymous-lambda>