bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[arthur.miller]

After I updated source from git and rebuild emacs, I am getting
"void-function subr-native-lambda-list" error on lots of external
packages when I try to load my init file. I tried both -O3 and -O2 with
same (un)success. 

My eln-cache is since 18. and 21. august, do I need to delete old eln
files manually? Or do I need to add some extra path to my init file?

Used to work without problems in earlier builds :-). Thankfull for the
help.

best regards
/a



In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3)
 of 2020-09-07 built on pascal
Repository revision: eb8742598874d9bd4c84ff54730527c52d29d7ff
Repository branch: feature/native-comp
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Arch Linux

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2

Important settings:
  value of $LANG: sv_SE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-cue hides /usr/local/share/emacs/site-lisp/emms/emms-cue
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-info-ogginfo hides /usr/local/share/emacs/site-lisp/emms/emms-info-ogginfo
/home/arthur/.emacs.d/elpa/emms-20200716.1815/later-do hides /usr/local/share/emacs/site-lisp/emms/later-do
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-mark hides /usr/local/share/emacs/site-lisp/emms/emms-mark
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-last-played hides /usr/local/share/emacs/site-lisp/emms/emms-last-played
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-player-mpg321-remote hides /usr/local/share/emacs/site-lisp/emms/emms-player-mpg321-remote
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-score hides /usr/local/share/emacs/site-lisp/emms/emms-score
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-player-mpd hides /usr/local/share/emacs/site-lisp/emms/emms-player-mpd
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-show-all hides /usr/local/share/emacs/site-lisp/emms/emms-show-all
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-setup hides /usr/local/share/emacs/site-lisp/emms/emms-setup
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-playlist-sort hides /usr/local/share/emacs/site-lisp/emms/emms-playlist-sort
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms hides /usr/local/share/emacs/site-lisp/emms/emms
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-info-mp3info hides /usr/local/share/emacs/site-lisp/emms/emms-info-mp3info
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-source-playlist hides /usr/local/share/emacs/site-lisp/emms/emms-source-playlist
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-cache hides /usr/local/share/emacs/site-lisp/emms/emms-cache
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-volume hides /usr/local/share/emacs/site-lisp/emms/emms-volume
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-playing-time hides /usr/local/share/emacs/site-lisp/emms/emms-playing-time
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-tag-editor hides /usr/local/share/emacs/site-lisp/emms/emms-tag-editor
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-source-file hides /usr/local/share/emacs/site-lisp/emms/emms-source-file
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-bookmarks hides /usr/local/share/emacs/site-lisp/emms/emms-bookmarks
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-player-simple hides /usr/local/share/emacs/site-lisp/emms/emms-player-simple
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-player-xine hides /usr/local/share/emacs/site-lisp/emms/emms-player-xine
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-librefm-stream hides /usr/local/share/emacs/site-lisp/emms/emms-librefm-stream
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-browser hides /usr/local/share/emacs/site-lisp/emms/emms-browser
/home/arthur/.emacs.d/elpa/emms-20200716.1815/jack hides /usr/local/share/emacs/site-lisp/emms/jack
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-playlist-mode hides /usr/local/share/emacs/site-lisp/emms/emms-playlist-mode
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-url hides /usr/local/share/emacs/site-lisp/emms/emms-url
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-streams hides /usr/local/share/emacs/site-lisp/emms/emms-streams
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-info-opusinfo hides /usr/local/share/emacs/site-lisp/emms/emms-info-opusinfo
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-mode-line hides /usr/local/share/emacs/site-lisp/emms/emms-mode-line
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-player-mplayer hides /usr/local/share/emacs/site-lisp/emms/emms-player-mplayer
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-maint hides /usr/local/share/emacs/site-lisp/emms/emms-maint
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-info hides /usr/local/share/emacs/site-lisp/emms/emms-info
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-librefm-scrobbler hides /usr/local/share/emacs/site-lisp/emms/emms-librefm-scrobbler
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-info-libtag hides /usr/local/share/emacs/site-lisp/emms/emms-info-libtag
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-info-metaflac hides /usr/local/share/emacs/site-lisp/emms/emms-info-metaflac
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-metaplaylist-mode hides /usr/local/share/emacs/site-lisp/emms/emms-metaplaylist-mode
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-compat hides /usr/local/share/emacs/site-lisp/emms/emms-compat
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-volume-pulse hides /usr/local/share/emacs/site-lisp/emms/emms-volume-pulse
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-player-mpv hides /usr/local/share/emacs/site-lisp/emms/emms-player-mpv
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-playlist-limit hides /usr/local/share/emacs/site-lisp/emms/emms-playlist-limit
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-history hides /usr/local/share/emacs/site-lisp/emms/emms-history
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-player-vlc hides /usr/local/share/emacs/site-lisp/emms/emms-player-vlc
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-mode-line-icon hides /usr/local/share/emacs/site-lisp/emms/emms-mode-line-icon
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-lyrics hides /usr/local/share/emacs/site-lisp/emms/emms-lyrics
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-stream-info hides /usr/local/share/emacs/site-lisp/emms/emms-stream-info
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-volume-amixer hides /usr/local/share/emacs/site-lisp/emms/emms-volume-amixer
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-i18n hides /usr/local/share/emacs/site-lisp/emms/emms-i18n
/home/arthur/.emacs.d/elpa/org-20200907/ob-processing hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-processing
/home/arthur/.emacs.d/elpa/org-20200907/ox-html hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-html
/home/arthur/.emacs.d/elpa/org-20200907/ox-ascii hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-ascii
/home/arthur/.emacs.d/elpa/org-20200907/org-id hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-id
/home/arthur/.emacs.d/elpa/org-20200907/ob-ditaa hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-ditaa
/home/arthur/.emacs.d/elpa/org-20200907/org-macro hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-macro
/home/arthur/.emacs.d/elpa/org-20200907/ol-rmail hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-rmail
/home/arthur/.emacs.d/elpa/org-20200907/ob-fortran hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-fortran
/home/arthur/.emacs.d/elpa/org-20200907/org-mouse hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-mouse
/home/arthur/.emacs.d/elpa/org-20200907/ob-gnuplot hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-gnuplot
/home/arthur/.emacs.d/elpa/org-20200907/org-element hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-element
/home/arthur/.emacs.d/elpa/org-20200907/org-ctags hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-ctags
/home/arthur/.emacs.d/elpa/org-20200907/org-crypt hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-crypt
/home/arthur/.emacs.d/elpa/org-20200907/ol hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol
/home/arthur/.emacs.d/elpa/org-20200907/org-macs hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-macs
/home/arthur/.emacs.d/elpa/org-20200907/ol-docview hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-docview
/home/arthur/.emacs.d/elpa/org-20200907/ob-calc hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-calc
/home/arthur/.emacs.d/elpa/org-20200907/ob-plantuml hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-plantuml
/home/arthur/.emacs.d/elpa/org-20200907/ob-css hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-css
/home/arthur/.emacs.d/elpa/org-20200907/ob-exp hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-exp
/home/arthur/.emacs.d/elpa/org-20200907/org-indent hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-indent
/home/arthur/.emacs.d/elpa/org-20200907/org-lint hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-lint
/home/arthur/.emacs.d/elpa/org-20200907/org-keys hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-keys
/home/arthur/.emacs.d/elpa/org-20200907/ob-clojure hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-clojure
/home/arthur/.emacs.d/elpa/org-20200907/ob-ebnf hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-ebnf
/home/arthur/.emacs.d/elpa/org-20200907/ob-groovy hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-groovy
/home/arthur/.emacs.d/elpa/org-20200907/ob-lob hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-lob
/home/arthur/.emacs.d/elpa/org-20200907/ob-asymptote hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-asymptote
/home/arthur/.emacs.d/elpa/org-20200907/ob-picolisp hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-picolisp
/home/arthur/.emacs.d/elpa/org-20200907/org-timer hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-timer
/home/arthur/.emacs.d/elpa/org-20200907/org-archive hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-archive
/home/arthur/.emacs.d/elpa/org-20200907/org-mobile hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-mobile
/home/arthur/.emacs.d/elpa/org-20200907/ob-abc hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-abc
/home/arthur/.emacs.d/elpa/org-20200907/ob-python hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-python
/home/arthur/.emacs.d/elpa/org-20200907/ol-w3m hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-w3m
/home/arthur/.emacs.d/elpa/org-20200907/ob hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob
/home/arthur/.emacs.d/elpa/org-20200907/ol-gnus hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-gnus
/home/arthur/.emacs.d/elpa/org-20200907/ob-coq hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-coq
/home/arthur/.emacs.d/elpa/org-20200907/ob-J hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-J
/home/arthur/.emacs.d/elpa/org-20200907/ob-forth hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-forth
/home/arthur/.emacs.d/elpa/org-20200907/ob-vala hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-vala
/home/arthur/.emacs.d/elpa/org-20200907/org-faces hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-faces
/home/arthur/.emacs.d/elpa/org-20200907/ol-irc hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-irc
/home/arthur/.emacs.d/elpa/org-20200907/org-entities hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-entities
/home/arthur/.emacs.d/elpa/org-20200907/ox-beamer hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-beamer
/home/arthur/.emacs.d/elpa/org-20200907/ob-sed hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-sed
/home/arthur/.emacs.d/elpa/org-20200907/ob-mscgen hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-mscgen
/home/arthur/.emacs.d/elpa/org-20200907/ob-tangle hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-tangle
/home/arthur/.emacs.d/elpa/org-20200907/ob-comint hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-comint
/home/arthur/.emacs.d/elpa/org-20200907/ob-lisp hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-lisp
/home/arthur/.emacs.d/elpa/org-20200907/org-colview hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-colview
/home/arthur/.emacs.d/elpa/org-20200907/ol-bibtex hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-bibtex
/home/arthur/.emacs.d/elpa/org-20200907/org-attach hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-attach
/home/arthur/.emacs.d/elpa/org-20200907/org-habit hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-habit
/home/arthur/.emacs.d/elpa/org-20200907/ol-eww hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-eww
/home/arthur/.emacs.d/elpa/org-20200907/ox-texinfo hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-texinfo
/home/arthur/.emacs.d/elpa/org-20200907/ob-sql hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-sql
/home/arthur/.emacs.d/elpa/org-20200907/ob-perl hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-perl
/home/arthur/.emacs.d/elpa/org-20200907/ob-octave hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-octave
/home/arthur/.emacs.d/elpa/org-20200907/ol-eshell hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-eshell
/home/arthur/.emacs.d/elpa/org-20200907/ox hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox
/home/arthur/.emacs.d/elpa/org-20200907/ob-shell hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-shell
/home/arthur/.emacs.d/elpa/org-20200907/ob-ocaml hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-ocaml
/home/arthur/.emacs.d/elpa/org-20200907/org-footnote hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-footnote
/home/arthur/.emacs.d/elpa/org-20200907/ob-lilypond hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-lilypond
/home/arthur/.emacs.d/elpa/org-20200907/org-tempo hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-tempo
/home/arthur/.emacs.d/elpa/org-20200907/org-datetree hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-datetree
/home/arthur/.emacs.d/elpa/org-20200907/org-duration hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-duration
/home/arthur/.emacs.d/elpa/org-20200907/ob-dot hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-dot
/home/arthur/.emacs.d/elpa/org-20200907/ob-core hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-core
/home/arthur/.emacs.d/elpa/org-20200907/ol-info hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-info
/home/arthur/.emacs.d/elpa/org-20200907/ol-mhe hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-mhe
/home/arthur/.emacs.d/elpa/org-20200907/org-agenda hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-agenda
/home/arthur/.emacs.d/elpa/org-20200907/org hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org
/home/arthur/.emacs.d/elpa/org-20200907/ol-bbdb hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ol-bbdb
/home/arthur/.emacs.d/elpa/org-20200907/ob-java hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-java
/home/arthur/.emacs.d/elpa/org-20200907/org-attach-git hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-attach-git
/home/arthur/.emacs.d/elpa/org-20200907/ob-R hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-R
/home/arthur/.emacs.d/elpa/org-20200907/ob-ledger hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-ledger
/home/arthur/.emacs.d/elpa/org-20200907/org-pcomplete hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-pcomplete
/home/arthur/.emacs.d/elpa/org-20200907/ox-odt hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-odt
/home/arthur/.emacs.d/elpa/org-20200907/ob-io hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-io
/home/arthur/.emacs.d/elpa/org-20200907/ox-latex hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-latex
/home/arthur/.emacs.d/elpa/org-20200907/ob-makefile hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-makefile
/home/arthur/.emacs.d/elpa/org-20200907/ox-man hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-man
/home/arthur/.emacs.d/elpa/org-20200907/org-compat hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-compat
/home/arthur/.emacs.d/elpa/org-20200907/ob-sass hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-sass
/home/arthur/.emacs.d/elpa/org-20200907/org-goto hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-goto
/home/arthur/.emacs.d/elpa/org-20200907/ob-matlab hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-matlab
/home/arthur/.emacs.d/elpa/org-20200907/org-src hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-src
/home/arthur/.emacs.d/elpa/org-20200907/ob-lua hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-lua
/home/arthur/.emacs.d/elpa/org-20200907/ob-hledger hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-hledger
/home/arthur/.emacs.d/elpa/org-20200907/ox-publish hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-publish
/home/arthur/.emacs.d/elpa/org-20200907/ob-eshell hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-eshell
/home/arthur/.emacs.d/elpa/org-20200907/ob-ruby hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-ruby
/home/arthur/.emacs.d/elpa/org-20200907/org-plot hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-plot
/home/arthur/.emacs.d/elpa/org-20200907/org-num hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-num
/home/arthur/.emacs.d/elpa/org-20200907/ob-maxima hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-maxima
/home/arthur/.emacs.d/elpa/org-20200907/ob-sqlite hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-sqlite
/home/arthur/.emacs.d/elpa/org-20200907/ob-scheme hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-scheme
/home/arthur/.emacs.d/elpa/org-20200907/ob-emacs-lisp hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-emacs-lisp
/home/arthur/.emacs.d/elpa/org-20200907/ob-awk hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-awk
/home/arthur/.emacs.d/elpa/org-20200907/org-install hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-install
/home/arthur/.emacs.d/elpa/org-20200907/org-version hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-version
/home/arthur/.emacs.d/elpa/org-20200907/ob-latex hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-latex
/home/arthur/.emacs.d/elpa/org-20200907/org-feed hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-feed
/home/arthur/.emacs.d/elpa/org-20200907/ob-js hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-js
/home/arthur/.emacs.d/elpa/org-20200907/org-capture hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-capture
/home/arthur/.emacs.d/elpa/org-20200907/org-inlinetask hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-inlinetask
/home/arthur/.emacs.d/elpa/org-20200907/ob-org hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-org
/home/arthur/.emacs.d/elpa/org-20200907/ob-eval hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-eval
/home/arthur/.emacs.d/elpa/org-20200907/ox-org hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-org
/home/arthur/.emacs.d/elpa/org-20200907/org-loaddefs hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-loaddefs
/home/arthur/.emacs.d/elpa/org-20200907/ox-md hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-md
/home/arthur/.emacs.d/elpa/org-20200907/ob-stan hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-stan
/home/arthur/.emacs.d/elpa/org-20200907/org-table hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-table
/home/arthur/.emacs.d/elpa/org-20200907/ob-haskell hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-haskell
/home/arthur/.emacs.d/elpa/org-20200907/ob-C hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-C
/home/arthur/.emacs.d/elpa/org-20200907/ob-table hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-table
/home/arthur/.emacs.d/elpa/org-20200907/ob-shen hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-shen
/home/arthur/.emacs.d/elpa/org-20200907/ob-ref hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-ref
/home/arthur/.emacs.d/elpa/org-20200907/ox-icalendar hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ox-icalendar
/home/arthur/.emacs.d/elpa/org-20200907/org-protocol hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-protocol
/home/arthur/.emacs.d/elpa/org-20200907/org-clock hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-clock
/home/arthur/.emacs.d/elpa/org-20200907/ob-screen hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/ob-screen
/home/arthur/.emacs.d/elpa/org-20200907/org-list hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/org/org-list
/home/arthur/.emacs.d/elpa/hierarchy-20190425.842/hierarchy hides /home/arthur/repos/emacs-related/emacssrc/emacs/lisp/emacs-lisp/hierarchy
/home/arthur/.emacs.d/elpa/use-package-20200721.2156/use-package hides /home/arthur/.emacs.d/lisp/use-package
/home/arthur/.emacs.d/elpa/key-chord-20160227.1238/key-chord hides /home/arthur/.emacs.d/lisp/key-chord
/home/arthur/.emacs.d/elpa/memoize-20200103.2036/memoize hides /home/arthur/.emacs.d/lisp/memoize
/home/arthur/.emacs.d/elpa/lively-20171005.754/lively hides /home/arthur/.emacs.d/lisp/lively
/home/arthur/.emacs.d/elpa/ov-20200326.1042/ov hides /home/arthur/.emacs.d/lisp/ov
/home/arthur/.emacs.d/elpa/company-20200831.2016/company-cmake hides /home/arthur/.emacs.d/lisp/company-cmake
/home/arthur/.emacs.d/elpa/emms-20200716.1815/emms-player-mpv hides /home/arthur/.emacs.d/lisp/emms-player-mpv
/home/arthur/.emacs.d/elpa/clang-format-20191121.1708/clang-format hides /home/arthur/.emacs.d/lisp/clang-format
/home/arthur/.emacs.d/elpa/bind-key-20200805.1727/bind-key hides /home/arthur/.emacs.d/lisp/bind-key

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date help-fns
radix-tree cl-print debug backtrace help-mode find-func advice info
edmacro kmacro helm-easymenu rx realgud-recursive-autoloads package
easymenu browse-url url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 92974 51573)
 (symbols 48 11031 36)
 (strings 32 33262 8092)
 (string-bytes 1 1352843)
 (vectors 16 15446)
 (vector-slots 8 208577 68090)
 (floats 8 35 364)
 (intervals 56 355 211)
 (buffers 992 14))

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

arthur.miller@live.com writes:

> After I updated source from git and rebuild emacs, I am getting
> "void-function subr-native-lambda-list" error on lots of external
> packages when I try to load my init file. I tried both -O3 and -O2 with
> same (un)success. 
>
> My eln-cache is since 18. and 21. august, do I need to delete old eln
> files manually? Or do I need to add some extra path to my init file?
>
> Used to work without problems in earlier builds :-). Thankfull for the
> help.
>
> best regards
> /a
>
>
>
> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3)
>  of 2020-09-07 built on pascal
> Repository revision: eb8742598874d9bd4c84ff54730527c52d29d7ff
> Repository branch: feature/native-comp
> Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
> System Description: Arch Linux
>
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
> INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
> TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
> PDUMPER LCMS2

Hi Arthur,

is it possible that the Emacs you are using is not compiled activating
the native compiler (--with-nativecomp)?  We should see NATIVE_COMP
within the "Configured features:" above.

OTOH this is telling that compiling the native-comp branch without
activating the native compiler has a problem there.  I'll fix it.

Thanks

  Andrea

bug#43255: Sv: bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[arthur miller]

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

Thanks for the anser; it can be problem to my machine.

I have a shell script that does build native for me, but it seems like after latest system update libgccjit does not pass the test in configure-script. My shell script goes to build after configure automatically, so I haven't noticed untill I just tried manually. I am not sure if that is the problem but it could be, I will see how Emacs builds after libgccjit is rebuilt (usually takes a while on my comp, so I am not sure I will have it today).

regards
/arthur
________________________________
Från: Andrea Corallo <akrl@sdf.org>
Skickat: den 7 september 2020 14:39
Till: arthur.miller@live.com <arthur.miller@live.com>
Kopia: 43255@debbugs.gnu.org <43255@debbugs.gnu.org>
Ämne: Re: bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

arthur.miller@live.com writes:

> After I updated source from git and rebuild emacs, I am getting
> "void-function subr-native-lambda-list" error on lots of external
> packages when I try to load my init file. I tried both -O3 and -O2 with
> same (un)success.
>
> My eln-cache is since 18. and 21. august, do I need to delete old eln
> files manually? Or do I need to add some extra path to my init file?
>
> Used to work without problems in earlier builds :-). Thankfull for the
> help.
>
> best regards
> /a
>
>
>
> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3)
>  of 2020-09-07 built on pascal
> Repository revision: eb8742598874d9bd4c84ff54730527c52d29d7ff
> Repository branch: feature/native-comp
> Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
> System Description: Arch Linux
>
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
> INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
> TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
> PDUMPER LCMS2

Hi Arthur,

is it possible that the Emacs you are using is not compiled activating
the native compiler (--with-nativecomp)?  We should see NATIVE_COMP
within the "Configured features:" above.

OTOH this is telling that compiling the native-comp branch without
activating the native compiler has a problem there.  I'll fix it.

Thanks

  Andrea

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

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Arthur Miller]

Andrea Corallo <akrl@sdf.org> writes:

> arthur.miller@live.com writes:
>
>> After I updated source from git and rebuild emacs, I am getting
>> "void-function subr-native-lambda-list" error on lots of external
>> packages when I try to load my init file. I tried both -O3 and -O2 with
>> same (un)success. 
>>
>> My eln-cache is since 18. and 21. august, do I need to delete old eln
>> files manually? Or do I need to add some extra path to my init file?
>>
>> Used to work without problems in earlier builds :-). Thankfull for the
>> help.
>>
>> best regards
>> /a
>>
>>
>>
>> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3)
>>  of 2020-09-07 built on pascal
>> Repository revision: eb8742598874d9bd4c84ff54730527c52d29d7ff
>> Repository branch: feature/native-comp
>> Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
>> System Description: Arch Linux
>>
>> Configured features:
>> XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
>> INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
>> TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
>> PDUMPER LCMS2
>
> Hi Arthur,
>
> is it possible that the Emacs you are using is not compiled activating
> the native compiler (--with-nativecomp)?  We should see NATIVE_COMP
> within the "Configured features:" above.
>
> OTOH this is telling that compiling the native-comp branch without
> activating the native compiler has a problem there.  I'll fix it.
>
> Thanks
>
>   Andrea

I am sorry, it was a false alarm. The problem was libgccjit. I have
rebuild it now, and native Emacs afterwards, and everything works great.

sorry and thanks
/a

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Arthur Miller <arthur.miller@live.com> writes:

> I am sorry, it was a false alarm.

Well actually you highlighted a real issue :)

d344e79be9 * src/data.c (subr-native-lambda-list): Defined it unconditionally (bug#43255)

address that so I'm closing.

I'm wondering if we should put the information that the running Emacs is
native compiler based in the splash screen too (via the `emacs-verion'
function).  Other important feature are already listed there.

Ccing Eli to get his opinion on this.

Thanks

  Andrea

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 43255-done@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 07 Sep 2020 16:34:14 +0000
> 
> I'm wondering if we should put the information that the running Emacs is
> native compiler based in the splash screen too (via the `emacs-verion'
> function).  Other important feature are already listed there.
> 
> Ccing Eli to get his opinion on this.

Yes, I think it should be in system-configuration-features.

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 43255-done@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>> Date: Mon, 07 Sep 2020 16:34:14 +0000
>> 
>> I'm wondering if we should put the information that the running Emacs is
>> native compiler based in the splash screen too (via the `emacs-verion'
>> function).  Other important feature are already listed there.
>> 
>> Ccing Eli to get his opinion on this.
>
> Yes, I think it should be in system-configuration-features.

We already add the information there.  I was wondering if is also worth
having the information rendered by `about-emacs'.  Otherwise (as in this
case) may not be very evident to the user what is going on underneath.

On my system I already have informations about GTK and cairo there,
these should be coming from `emacs-version' the function.

Thanks

  Andrea

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: arthur.miller@live.com, 43255@debbugs.gnu.org
> Date: Mon, 07 Sep 2020 17:19:12 +0000
> 
> > Yes, I think it should be in system-configuration-features.
> 
> We already add the information there.  I was wondering if is also worth
> having the information rendered by `about-emacs'.  Otherwise (as in this
> case) may not be very evident to the user what is going on underneath.
> 
> On my system I already have informations about GTK and cairo there,
> these should be coming from `emacs-version' the function.

That's different.  GTK and Cairo have profound effects on how Emacs
presents itself to the UI.  I don't think native compilation is
similar, or maybe I'm missing something.  What exactly did you think
will not be evident to the user, and why should it be evident?

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> That's different.  GTK and Cairo have profound effects on how Emacs
> presents itself to the UI.  I don't think native compilation is
> similar, or maybe I'm missing something.  What exactly did you think
> will not be evident to the user, and why should it be evident?

No you are correct, it is essentially transparent to the user.

And this is why is not the first time that a user miss the fact that
Emacs was compiled with the native compiler or vice versa.  Therefore I
thought was maybe useful to give some visual feedback in the "*About GNU
Emacs*" buffer.

If that string is dedicated to feature with UI effect then the native
compiler does not qualify tho.

Thanks

  Andrea

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: arthur.miller@live.com, 43255@debbugs.gnu.org
> Date: Mon, 07 Sep 2020 19:24:17 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's different.  GTK and Cairo have profound effects on how Emacs
> > presents itself to the UI.  I don't think native compilation is
> > similar, or maybe I'm missing something.  What exactly did you think
> > will not be evident to the user, and why should it be evident?
> 
> No you are correct, it is essentially transparent to the user.
> 
> And this is why is not the first time that a user miss the fact that
> Emacs was compiled with the native compiler or vice versa.  Therefore I
> thought was maybe useful to give some visual feedback in the "*About GNU
> Emacs*" buffer.

Why is it important for the user to know about the native compiler?
E.g., how is it different from the C compiler switches used to build
Emacs?

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: arthur.miller@live.com, 43255@debbugs.gnu.org
>> Date: Mon, 07 Sep 2020 19:24:17 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > That's different.  GTK and Cairo have profound effects on how Emacs
>> > presents itself to the UI.  I don't think native compilation is
>> > similar, or maybe I'm missing something.  What exactly did you think
>> > will not be evident to the user, and why should it be evident?
>> 
>> No you are correct, it is essentially transparent to the user.
>> 
>> And this is why is not the first time that a user miss the fact that
>> Emacs was compiled with the native compiler or vice versa.  Therefore I
>> thought was maybe useful to give some visual feedback in the "*About GNU
>> Emacs*" buffer.
>
> Why is it important for the user to know about the native compiler?
> E.g., how is it different from the C compiler switches used to build
> Emacs?
Just as important as x86_64 or linux-gnu :-).

Currently when I press C-h C-a, I get this info (amongst other):

GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3)
 of 2020-09-07

I think it would be handy if there was a bit more info on that page.
I would prefer x64-native GNU/Linux. Why is it less important to know
about non-gui features? For me who has turned off most of gui stuff, GTK
and Cairo versions are not really what I care about. I have them just to
get better font rendering, but now I can maybe compile without at least
Gtk? I mean I don't need to know that it is compiled for GNU/Linux; I
know I am running on a GNU/Linux OS, or that it is a 64-bit OS, yet info
is there.

In my case I would have seen that I didn't compile with native compiler
support even though I intended (since the configure script failed wihout
me noticing).

I also wouldn't mind more info about compiler switches used to build the
version as well as features/packages built-in. I don't know what is
essential more and I don't have any philosophical argument, more than it
is sometimes useful.

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Eli Zaretskii]

On September 8, 2020 7:26:12 AM GMT+03:00, Arthur Miller <arthur.miller@live.com> wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrea Corallo <akrl@sdf.org>
>>> Cc: arthur.miller@live.com, 43255@debbugs.gnu.org
>>> Date: Mon, 07 Sep 2020 19:24:17 +0000
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>> Why is it important for the user to know about the native compiler?
>> E.g., how is it different from the C compiler switches used to build
>> Emacs?
>Just as important as x86_64 or linux-gnu :-).
>
>Currently when I press C-h C-a, I get this info (amongst other):
>
>GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23,
>cairo version 1.17.3)
> of 2020-09-07
>
>I think it would be handy if there was a bit more info on that page.
>I would prefer x64-native GNU/Linux. Why is it less important to know
>about non-gui features? For me who has turned off most of gui stuff,
>GTK
>and Cairo versions are not really what I care about. I have them just
>to
>get better font rendering, but now I can maybe compile without at least
>Gtk? I mean I don't need to know that it is compiled for GNU/Linux; I
>know I am running on a GNU/Linux OS, or that it is a 64-bit OS, yet
>info
>is there.
>
>In my case I would have seen that I didn't compile with native compiler
>support even though I intended (since the configure script failed
>wihout
>me noticing).
>
>I also wouldn't mind more info about compiler switches used to build
>the
>version as well as features/packages built-in. I don't know what is
>essential more and I don't have any philosophical argument, more than
>it
>is sometimes useful.

That's a different issue.  The original question was about the splash screen and specifically about emacs-version.  I see no reason whatsoever to show information about the native compilation there, as it's a minor feature that moreover has no effect at all until some Lisp files are compiled with it.  Besides, the splash screen is already too crowded.

If you are saying that the "About Emacs" display should be redesigned (to make it look differently from the splash screen), I might agree, but then (a) please show a more detailed proposal, and (b) such a display doesn't need the change to be in emacs-version, it can use the other variables which divulge the details of the build and its configuration.

Btw, in line with the recent "let's be like other apps" trend, I suggest to look at what other apps do in their "About" display: I have the impression that this fashion is on its way out.

Bottom line: you've effectively changed the subject, so I suggest to do that explicitly, and start a new thread/issue.

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I see no reason whatsoever to show information about the native
> compilation there,

Agreed.

> as it's a minor feature that moreover has no effect at all until some
> Lisp files are compiled with it.

AFAICT, when using the native-comp branch, Lisp files are automatically
compiled without me having to do anything.

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

As suggested opening a new issue to keep on discussing what came-up from

https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00637.html

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> That's a different issue.  The original question was about the splash
> screen and specifically about emacs-version.  I see no reason
> whatsoever to show information about the native compilation there, as
> it's a minor feature that moreover has no effect at all until some
> Lisp files are compiled with it.

For completeness: ATM all code that was byte compiled gets native
compiled automatically.  For this reason it *has* an effect since Emacs
starts.

It is true that from a user perspective everything is going on
transparently but the side effect of the native compilation is the exact
reason why people are using it (read depending on the workload it can be
noticeably faster).

If it's more or less important than say using Cairo that's very much a
POV I think, as I believe is classifying it as "minor feature" (reason
why I'd avoid).

Thanks

  Andrea

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

> On September 8, 2020 7:26:12 AM GMT+03:00, Arthur Miller <arthur.miller@live.com> wrote:
>>Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Andrea Corallo <akrl@sdf.org>
>>>> Cc: arthur.miller@live.com, 43255@debbugs.gnu.org
>>>> Date: Mon, 07 Sep 2020 19:24:17 +0000
>>>> 
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>> 
>>> Why is it important for the user to know about the native compiler?
>>> E.g., how is it different from the C compiler switches used to build
>>> Emacs?
>>Just as important as x86_64 or linux-gnu :-).
>>
>>Currently when I press C-h C-a, I get this info (amongst other):
>>
>>GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23,
>>cairo version 1.17.3)
>> of 2020-09-07
>>
>>I think it would be handy if there was a bit more info on that page.
>>I would prefer x64-native GNU/Linux. Why is it less important to know
>>about non-gui features? For me who has turned off most of gui stuff,
>>GTK
>>and Cairo versions are not really what I care about. I have them just
>>to
>>get better font rendering, but now I can maybe compile without at least
>>Gtk? I mean I don't need to know that it is compiled for GNU/Linux; I
>>know I am running on a GNU/Linux OS, or that it is a 64-bit OS, yet
>>info
>>is there.
>>
>>In my case I would have seen that I didn't compile with native compiler
>>support even though I intended (since the configure script failed
>>wihout
>>me noticing).
>>
>>I also wouldn't mind more info about compiler switches used to build
>>the
>>version as well as features/packages built-in. I don't know what is
>>essential more and I don't have any philosophical argument, more than
>>it
>>is sometimes useful.
>
> That's a different issue. The original question was about the splash screen and
> specifically about emacs-version.
Sorry; wasn't careful. Personally I don't care much about at all for
splash-screen, I don't even see it. I do use "about emacs-version".
Since I run Emacs directly from it's source folder, I usually do C-h C-a
to confirm it compiled

> I see no reason whatsoever to show information
> about the native compilation there, as it's a minor feature that moreover has no
> effect at all until some Lisp files are compiled with it. Besides, the splash
> screen is already too crowded.
I have no opinion for splash-screen whatsoever; mine is disabled anyway
:-).

> If you are saying that the "About Emacs" display should be redesigned (to make
> it look differently from the splash screen), I might agree, but then (a) please
> show a more detailed proposal, and (b) such a display doesn't need the change to
> be in emacs-version, it can use the other variables which divulge the details of
> the build and its configuration.
Ok. I'll think about, but I don't promise.

> Btw, in line with the recent "let's be like other apps" trend, I suggest to look
> at what other apps do in their "About" display: I have the impression that this
> fashion is on its way out.
I agree; I never look at those screens myself; so it is not so much
about "being like other apps". To me it is usefull to quickly see
compilation date of Emacs after the compile. I don't longer install
Emacs in system dir (no make install); I configured my system to run Emacs
directly from the "src" folder, so for me it is informational to see I
have restarted newly compiled version.

> Bottom line: you've effectively changed the subject, so I suggest to
> do that explicitly, and start a new thread/issue.
Yes sorry about that. If I get to make a proposal for new looks; I will
make a suggestion thread. For the now, you can let it die :).

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 8 Sep 2020 00:47:04 -0700
> Cc: 43255@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
> 
> > as it's a minor feature that moreover has no effect at all until some
> > Lisp files are compiled with it.
> 
> AFAICT, when using the native-comp branch, Lisp files are automatically
> compiled without me having to do anything.

That'd be a misfeature, I think: it means that users who build their
own Emacs will have their build take hours.  I'd prefer to have an
option to delay native compilation to some later time, ideally have it
JIT-compiled, like Guile does.

Is this possible?

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Arthur Miller <arthur.miller@live.com>, bug-gnu-emacs@gnu.org
> Date: Tue, 08 Sep 2020 08:03:06 +0000
> 
> As suggested opening a new issue to keep on discussing what came-up from
> 
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00637.html
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [...]
> 
> > That's a different issue.  The original question was about the splash
> > screen and specifically about emacs-version.  I see no reason
> > whatsoever to show information about the native compilation there, as
> > it's a minor feature that moreover has no effect at all until some
> > Lisp files are compiled with it.
> 
> For completeness: ATM all code that was byte compiled gets native
> compiled automatically.  For this reason it *has* an effect since Emacs
> starts.

As mentioned on the bug list, I'd prefer if user could defer native
compilation to some later time, so as to avoid making the Emacs build
take hours, especially on slow and low-end machines.

> If it's more or less important than say using Cairo that's very much a
> POV I think, as I believe is classifying it as "minor feature" (reason
> why I'd avoid).

Maybe Cairo is also not important enough, and should be removed.  GTK
(or the toolkit in general) _is_ important, as it has radical effect
on the GUI appearance.

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Tue, 8 Sep 2020 00:47:04 -0700
>> Cc: 43255@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
>> 
>> > as it's a minor feature that moreover has no effect at all until some
>> > Lisp files are compiled with it.
>> 
>> AFAICT, when using the native-comp branch, Lisp files are automatically
>> compiled without me having to do anything.
>
> That'd be a misfeature, I think: it means that users who build their
> own Emacs will have their build take hours.  I'd prefer to have an
> option to delay native compilation to some later time, ideally have it
> JIT-compiled, like Guile does.
>
> Is this possible?

The only files that is mandatory to have compiled Ahead of Time are the
one dumped, the rest of emacs is up to the user to do them Aot or not.

Right I'm gonna set the default so that the bare minimum is compiled
AoT.

That said I think what Stefan meant is precisely that compilation is
happening automatically Jit like with no user intervention.

  Andrea

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>, arthur.miller@live.com,
>         43255@debbugs.gnu.org
> Date: Tue, 08 Sep 2020 14:54:31 +0000
> 
> >> AFAICT, when using the native-comp branch, Lisp files are automatically
> >> compiled without me having to do anything.
> >
> > That'd be a misfeature, I think: it means that users who build their
> > own Emacs will have their build take hours.  I'd prefer to have an
> > option to delay native compilation to some later time, ideally have it
> > JIT-compiled, like Guile does.
> >
> > Is this possible?
> 
> The only files that is mandatory to have compiled Ahead of Time are the
> one dumped

Why do these have to be compiled ahead of time?

> That said I think what Stefan meant is precisely that compilation is
> happening automatically Jit like with no user intervention.

And that can be turned on and off as the user sees fit?  If so, that's
why I said that the native-compilation part is not important to have
in the version description, only in the set of supported features.

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Stefan Kangas <stefankangas@gmail.com>, arthur.miller@live.com,
>>         43255@debbugs.gnu.org
>> Date: Tue, 08 Sep 2020 14:54:31 +0000
>> 
>> >> AFAICT, when using the native-comp branch, Lisp files are automatically
>> >> compiled without me having to do anything.
>> >
>> > That'd be a misfeature, I think: it means that users who build their
>> > own Emacs will have their build take hours.  I'd prefer to have an
>> > option to delay native compilation to some later time, ideally have it
>> > JIT-compiled, like Guile does.
>> >
>> > Is this possible?
>> 
>> The only files that is mandatory to have compiled Ahead of Time are the
>> one dumped
>
> Why do these have to be compiled ahead of time?

Nothing technically prevents to have the native compiler at disposal on
a system that is entirely and exclusively byte compiled, is just a
configuration that ATM we do not expose (I think we'll do it).

It can be useful (actually *it is* every time the native compiler fails
to boo-strap) but is not something an average user would want to use.

>> That said I think what Stefan meant is precisely that compilation is
>> happening automatically Jit like with no user intervention.
>
> And that can be turned on and off as the user sees fit?  If so, that's
> why I said that the native-compilation part is not important to have
> in the version description, only in the set of supported features.

The user can turn deferred compilation off (by default is on).
According to this metric any feature that can be partially or completely
disabled is not worth to be mentioned there, even if is a rework of the
execution engine.  That's maybe correct, if you like to suggest a more
appropriate place to put this information that is evident to the user I
would be appreciated that.  I've opened #43269 to discuss this.

Thanks!

  Andrea

bug#43255: 28.0.50; feature/native-comp void-function subr-native-lambda-list

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: stefankangas@gmail.com, arthur.miller@live.com, 43255@debbugs.gnu.org
> Date: Tue, 08 Sep 2020 16:02:01 +0000
> 
> The user can turn deferred compilation off (by default is on).
> According to this metric any feature that can be partially or completely
> disabled is not worth to be mentioned there, even if is a rework of the
> execution engine.  That's maybe correct, if you like to suggest a more
> appropriate place to put this information that is evident to the user I
> would be appreciated that.  I've opened #43269 to discuss this.

I think we already have a suggestion: to redesign the "About Emacs"
screen, so that instead of showing the splash screen again, it could
say something more detailed about the build and the features that this
build supports.

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[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. ]]]

  > As mentioned on the bug list, I'd prefer if user could defer native
  > compilation to some later time, so as to avoid making the Emacs build
  > take hours, especially on slow and low-end machines.

I wonder if I would ever see any benefit form the speedup of native
compilation.  I hardly ever notice waiting for Emacs to do computation.
But I would find a big slowdown in building to be a pain.

Maybe I would prefer to turn off native compilation, pure and simple.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > As mentioned on the bug list, I'd prefer if user could defer native
>   > compilation to some later time, so as to avoid making the Emacs build
>   > take hours, especially on slow and low-end machines.
>
> I wonder if I would ever see any benefit form the speedup of native
> compilation.  I hardly ever notice waiting for Emacs to do computation.
> But I would find a big slowdown in building to be a pain.

Hi Richard,

It is certainly very workflow dependent.  I think too many don't need
it, for others is the opposite.

> Maybe I would prefer to turn off native compilation, pure and simple.

ATM even in the feature branch this is off by default, must be activated
with a configure switch otherwise just vanilla Emacs is built.

Regards

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: akrl@sdf.org, arthur.miller@live.com, 43269@debbugs.gnu.org
> Date: Tue, 08 Sep 2020 23:45:06 -0400
> 
>   > As mentioned on the bug list, I'd prefer if user could defer native
>   > compilation to some later time, so as to avoid making the Emacs build
>   > take hours, especially on slow and low-end machines.
> 
> I wonder if I would ever see any benefit form the speedup of native
> compilation.  I hardly ever notice waiting for Emacs to do computation.
> But I would find a big slowdown in building to be a pain.
> 
> Maybe I would prefer to turn off native compilation, pure and simple.

I share some of these feelings, FWIW.  Andrea's work is, of course,
commendable and the results will be very welcome when they land on
master, but I'm disappointed by the high price we need to pay for this
feature, both in complexity (notice the long discussions of where and
how to store the *.eln files, and how to handle recompilation and
reloading), and in compilation times.  Having the single-core
compilation times increase from 10-15 min to several hours is
... extreme.  (And before you say no one runs this on a single core: I
sometimes do, when parallel builds get in the way of debugging some
problem.)  And we will probably bump into additional issues down the
road.

(How come it's so easy and seamless in Guile?)

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, arthur.miller@live.com,
>         43269@debbugs.gnu.org
> Date: Wed, 09 Sep 2020 07:46:23 +0000
> 
> > I wonder if I would ever see any benefit form the speedup of native
> > compilation.  I hardly ever notice waiting for Emacs to do computation.
> > But I would find a big slowdown in building to be a pain.
> 
> Hi Richard,
> 
> It is certainly very workflow dependent.  I think too many don't need
> it, for others is the opposite.

I very much doubt that anyone will give up this feature, unless they
have some serious problem with using it (such as that a single Emacs
build needs to run for hours).

> > Maybe I would prefer to turn off native compilation, pure and simple.
> 
> ATM even in the feature branch this is off by default, must be activated
> with a configure switch otherwise just vanilla Emacs is built.

When this lands on master, we almost certainly will make the configure
script probe the system, and turn this feature on if the prerequisites
are detected.  Like we do with most other important features.

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Cc: akrl@sdf.org, arthur.miller@live.com, 43269@debbugs.gnu.org
>> Date: Tue, 08 Sep 2020 23:45:06 -0400
>> 
>>   > As mentioned on the bug list, I'd prefer if user could defer native
>>   > compilation to some later time, so as to avoid making the Emacs build
>>   > take hours, especially on slow and low-end machines.
>> 
>> I wonder if I would ever see any benefit form the speedup of native
>> compilation.  I hardly ever notice waiting for Emacs to do computation.
>> But I would find a big slowdown in building to be a pain.
>> 
>> Maybe I would prefer to turn off native compilation, pure and simple.
>
> I share some of these feelings, FWIW.  Andrea's work is, of course,
> commendable and the results will be very welcome when they land on
> master, but I'm disappointed by the high price we need to pay for this
> feature, both in complexity (notice the long discussions of where and
> how to store the *.eln files, and how to handle recompilation and
> reloading), and in compilation times.  Having the single-core
> compilation times increase from 10-15 min to several hours is
> ... extreme.  (And before you say no one runs this on a single core: I
> sometimes do, when parallel builds get in the way of debugging some
> problem.)  And we will probably bump into additional issues down the
> road.
>
> (How come it's so easy and seamless in Guile?)
>

Hi Eli,

the native compiler improved considerably the compilation speed with
time.  I just took a measure at today's status native compiling only the
dumped image (what is going to be default when native compiling).

On my dev machine vanilla Emacs uses 12m tot CPU time for a compilation
from a fresh repo. The same native compiling takes 30m tot CPU time so
IMO it is not terrible.

Regarding the complexity I don't know, I guess it took some message to
decide how to have it working but now we are there.  It looks to me way
simpler then deciding Emacs defaults :)

For Guile I have no idea if it was simpler to implement or discuss.  I'm
not a Guile expert so I may be inaccurate but I think they can native
compile with a simple lightening based jitter.  This let me think they
can't save or reuse the compilation output, nor dump it given everything
happens in memory.

Regards

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: rms@gnu.org,  arthur.miller@live.com,  43269@debbugs.gnu.org
> Date: Wed, 09 Sep 2020 15:19:58 +0000
> 
> the native compiler improved considerably the compilation speed with
> time.  I just took a measure at today's status native compiling only the
> dumped image (what is going to be default when native compiling).
> 
> On my dev machine vanilla Emacs uses 12m tot CPU time for a compilation
> from a fresh repo. The same native compiling takes 30m tot CPU time so
> IMO it is not terrible.

Is this with "make" or with "make -jN"? if the latter, what value of N
was used?

> For Guile I have no idea if it was simpler to implement or discuss.

I'm talking from the POV of a Guile user: it is simply seamless.

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: rms@gnu.org,  arthur.miller@live.com,  43269@debbugs.gnu.org
>> Date: Wed, 09 Sep 2020 15:19:58 +0000
>>
>> the native compiler improved considerably the compilation speed with
>> time.  I just took a measure at today's status native compiling only the
>> dumped image (what is going to be default when native compiling).
>>
>> On my dev machine vanilla Emacs uses 12m tot CPU time for a compilation
>> from a fresh repo. The same native compiling takes 30m tot CPU time so
>> IMO it is not terrible.
>
> Is this with "make" or with "make -jN"? if the latter, what value of N
> was used?

$ git clean -xfd && ./autogen.sh && ./configure --without-x --with-nativecomp  && time make NATIVE_FAST_BOOT=1 -j16
[...]
real    4m19.570s
user    28m59.958s
sys     0m48.797s
$

I guess -j1 may even score slightly less user time.

>> For Guile I have no idea if it was simpler to implement or discuss.
>
> I'm talking from the POV of a Guile user: it is simply seamless.

Well I think from a user prespective now with our native-compiler should
be the same, it does not require any user intervention.

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> For Guile I have no idea if it was simpler to implement or discuss.
>
> I'm talking from the POV of a Guile user: it is simply seamless.

FWIW, I have been using the native-comp branch for the last few weeks,
and my experience has been mostly seamless.  The only bug I've
personally seen in that time has been fixed (keymaps showing up as
undefined).

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: rms@gnu.org,  arthur.miller@live.com,  43269@debbugs.gnu.org
> Date: Wed, 09 Sep 2020 16:32:58 +0000
> 
> > Is this with "make" or with "make -jN"? if the latter, what value of N
> > was used?
> 
> $ git clean -xfd && ./autogen.sh && ./configure --without-x --with-nativecomp  && time make NATIVE_FAST_BOOT=1 -j16
> [...]
> real    4m19.570s
> user    28m59.958s
> sys     0m48.797s
> $
> 
> I guess -j1 may even score slightly less user time.

So what do you have there, an i9 CPU?  In any case, 4 min with -j16 is
quite a lot.

And what does NATIVE_FAST_BOOT=1 do? what kind of compiler
optimizations does it imply?

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: rms@gnu.org,  arthur.miller@live.com,  43269@debbugs.gnu.org
>> Date: Wed, 09 Sep 2020 16:32:58 +0000
>> 
>> > Is this with "make" or with "make -jN"? if the latter, what value of N
>> > was used?
>> 
>> $ git clean -xfd && ./autogen.sh && ./configure --without-x
>> --with-nativecomp && time make NATIVE_FAST_BOOT=1 -j16
>> [...]
>> real    4m19.570s
>> user    28m59.958s
>> sys     0m48.797s
>> $
>> 
>> I guess -j1 may even score slightly less user time.
>
> So what do you have there, an i9 CPU?  In any case, 4 min with -j16 is
> quite a lot.

It's Xeon from three yeas ago (8 real cores).  It's 4 mins because our
build is not very parallel.

But that said I think what matters it the total CPU time (here ~30min)
to be compared against the same for the vanilla build (~12min).  This is
about what one would get at -j1.

This indicates a 2.5x.

> And what does NATIVE_FAST_BOOT=1 do? what kind of compiler
> optimizations does it imply?

It's just the current way to say not to compile AoT all the Emacs
distribution but only what goes into the dump.  Is going to to be the
default soon as agreed.

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: rms@gnu.org,  arthur.miller@live.com,  43269@debbugs.gnu.org
> Date: Wed, 09 Sep 2020 18:15:51 +0000
> 
> > So what do you have there, an i9 CPU?  In any case, 4 min with -j16 is
> > quite a lot.
> 
> It's Xeon from three yeas ago (8 real cores).  It's 4 mins because our
> build is not very parallel.
> 
> But that said I think what matters it the total CPU time (here ~30min)
> to be compared against the same for the vanilla build (~12min).  This is
> about what one would get at -j1.

No, what matters to users is the elapsed time.  And that cannot be
simply estimated as the total CPU time.

Anyway, thanks for the data (and all your hard work on this).

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: rms@gnu.org,  arthur.miller@live.com,  43269@debbugs.gnu.org
>> Date: Wed, 09 Sep 2020 18:15:51 +0000
>> 
>> > So what do you have there, an i9 CPU?  In any case, 4 min with -j16 is
>> > quite a lot.
>> 
>> It's Xeon from three yeas ago (8 real cores).  It's 4 mins because our
>> build is not very parallel.
>> 
>> But that said I think what matters it the total CPU time (here ~30min)
>> to be compared against the same for the vanilla build (~12min).  This is
>> about what one would get at -j1.
>
> No, what matters to users is the elapsed time.  And that cannot be
> simply estimated as the total CPU time.

To my knowledge and for my experience with this workload this is a
decent estimation of the conversion factor.

It should be said that, as we have improved compilation speed already by
about a factor five, we may be able to improve it further.  But this is
where we stand today.

> Anyway, thanks for the data (and all your hard work on this).

Welcome, I really enjoy to work on this with you all.

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: rms@gnu.org,  arthur.miller@live.com,  43269@debbugs.gnu.org
> Date: Wed, 09 Sep 2020 21:51:53 +0000
> 
> It should be said that, as we have improved compilation speed already by
> about a factor five, we may be able to improve it further.  But this is
> where we stand today.

Needless to say, I think that making this faster is very important.

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Lars Ingebrigtsen]

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:
> $ git clean -xfd && ./autogen.sh && ./configure --without-x
> --with-nativecomp && time make NATIVE_FAST_BOOT=1 -j16
> [...]
> real    4m19.570s
> user    28m59.958s
> sys     0m48.797s

Just another data point -- on my AMD Ryzen 7 3700X 8-Core Processor,

$ make bootstrap-clean; ./configure; time make NATIVE_FAST_BOOT=1 -j16

real	1m51.603s
user	11m27.197s
sys	0m38.004s

$ make bootstrap-clean; ./configure --with-nativecomp; time make NATIVE_FAST_BOOT=1 -j16 

real	3m44.636s
user	27m15.699s
sys	0m53.677s

So it takes about 2x the time to build Emacs on this machine with native
compilation, which isn't so bad.  (And the result is a really snappy and
responsive Emacs. :-))

Of course, the non-native compilation spends a lot of time being
single-threaded, and there's room for improvement there.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Reviewing this bug; IIRC the suggestion that came-up on another thread
on the subject of this bug was to rework `about-emacs' so it could host
additional information, is this correct?

Thanks

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Lars Ingebrigtsen]

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Reviewing this bug; IIRC the suggestion that came-up on another thread
> on the subject of this bug was to rework `about-emacs' so it could host
> additional information, is this correct?

Possibly...  but "being natively compiled" isn't a binary thing, though:
I mean, you could have --with-nativecomp, but still be using .elc files
instead of .eln files.  Or a mixture, which I think would be normal for
many years.

But I guess that's a detail that wouldn't be that important for most
people.  I mean, most people are using distributed versions of Emacs,
and presumably if it has support for native compilation, then the vast
majority of the Lisp file will also be natively compiled.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
>
>> Reviewing this bug; IIRC the suggestion that came-up on another thread
>> on the subject of this bug was to rework `about-emacs' so it could host
>> additional information, is this correct?
>
> Possibly...  but "being natively compiled" isn't a binary thing, though:
> I mean, you could have --with-nativecomp, but still be using .elc files
> instead of .eln files.  Or a mixture, which I think would be normal for
> many years.
>
> But I guess that's a detail that wouldn't be that important for most
> people.  I mean, most people are using distributed versions of Emacs,
> and presumably if it has support for native compilation, then the vast
> majority of the Lisp file will also be natively compiled.

Correct, especially considering that unless what is now
`comp-deferred-compilation' is tweaked out of default all files will be
native compiled anyway regardless the fact that they are distributed
already native compiled or not.

That said honestly I've not much idea on how to rework `about-emacs' and
my understanding was that this is a general suggestion not strictly
native-comp related.  If that's the case I'd be for closing this bug as
I think is out of scope for the feature branch, or if I'm wrong here and
there's some suggestion I'm happy to put some effort into as well :)

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

> That said honestly I've not much idea on how to rework `about-emacs' and
> my understanding was that this is a general suggestion not strictly
> native-comp related.  If that's the case I'd be for closing this bug as
> I think is out of scope for the feature branch, or if I'm wrong here and
> there's some suggestion I'm happy to put some effort into as well :)

The line that says

GNU Emacs 28.0.50 (build 85, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
 of 2020-10-17

(which should perhaps be folded better) could have a ", natively
compiled" in there somewhere.

I think nativecomp is a big enough thing to be called out here -- at
least for a couple of Emacs versions.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> That said honestly I've not much idea on how to rework `about-emacs' and
>> my understanding was that this is a general suggestion not strictly
>> native-comp related.  If that's the case I'd be for closing this bug as
>> I think is out of scope for the feature branch, or if I'm wrong here and
>> there's some suggestion I'm happy to put some effort into as well :)
>
> The line that says
>
> GNU Emacs 28.0.50 (build 85, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
>  of 2020-10-17
>
> (which should perhaps be folded better) could have a ", natively
> compiled" in there somewhere.
>
> I think nativecomp is a big enough thing to be called out here -- at
> least for a couple of Emacs versions.

This was my original proposition but IIRC Eli had a different idea on
that.

Unfortunatelly I think the discussion happend on a different thread and
I cannot find it ATM so I may be wrong.

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> That said honestly I've not much idea on how to rework `about-emacs' and
>>> my understanding was that this is a general suggestion not strictly
>>> native-comp related.  If that's the case I'd be for closing this bug as
>>> I think is out of scope for the feature branch, or if I'm wrong here and
>>> there's some suggestion I'm happy to put some effort into as well :)
>>
>> The line that says
>>
>> GNU Emacs 28.0.50 (build 85, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
>>  of 2020-10-17
>>
>> (which should perhaps be folded better) could have a ", natively
>> compiled" in there somewhere.
>>
>> I think nativecomp is a big enough thing to be called out here -- at
>> least for a couple of Emacs versions.
>
> This was my original proposition but IIRC Eli had a different idea on
> that.
>
> Unfortunatelly I think the discussion happend on a different thread and
> I cannot find it ATM so I may be wrong.

I've found the original discussion, I link it here for completeness

<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00690.html>

Sorry for this threads being a little messy :/

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 43269@debbugs.gnu.org
> Date: Sat, 17 Oct 2020 06:35:22 +0000
> 
> Reviewing this bug; IIRC the suggestion that came-up on another thread
> on the subject of this bug was to rework `about-emacs' so it could host
> additional information, is this correct?

Yes, AFAIU.

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 43269@debbugs.gnu.org
>> Date: Sat, 17 Oct 2020 06:35:22 +0000
>> 
>> Reviewing this bug; IIRC the suggestion that came-up on another thread
>> on the subject of this bug was to rework `about-emacs' so it could host
>> additional information, is this correct?
>
> Yes, AFAIU.

The summary is that ATM options on the table are:

1- rework `emacs-version' so it adds the information there (it should
   reflect on `about-emacs' too), this is suggested by Lars too.

2- close the bug as non related to feature/native-comp.

3- rework `about-emacs' in some other way (I've really no precise idea
   how).

This list is sorted using my preference as a metric :)

I'll go for 1 unless there's no agreement on.

  Andrea

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 43269@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 17 Oct 2020 10:25:50 +0000
> 
> The summary is that ATM options on the table are:
> 
> 1- rework `emacs-version' so it adds the information there (it should
>    reflect on `about-emacs' too), this is suggested by Lars too.
> 
> 2- close the bug as non related to feature/native-comp.
> 
> 3- rework `about-emacs' in some other way (I've really no precise idea
>    how).
> 
> This list is sorted using my preference as a metric :)
> 
> I'll go for 1 unless there's no agreement on.

FWIW, I will repeat that my preference is 3.  This information doesn't
belong to the version, it belongs to the description of the build's
features, and thus to "about Emacs" (which needs to be revamped not to
show the same information as the splash screen).

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 43269@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Sat, 17 Oct 2020 10:25:50 +0000
>> 
>> The summary is that ATM options on the table are:
>> 
>> 1- rework `emacs-version' so it adds the information there (it should
>>    reflect on `about-emacs' too), this is suggested by Lars too.
>> 
>> 2- close the bug as non related to feature/native-comp.
>> 
>> 3- rework `about-emacs' in some other way (I've really no precise idea
>>    how).
>> 
>> This list is sorted using my preference as a metric :)
>> 
>> I'll go for 1 unless there's no agreement on.
>
> FWIW, I will repeat that my preference is 3.  This information doesn't
> belong to the version, it belongs to the description of the build's
> features, and thus to "about Emacs" (which needs to be revamped not to
> show the same information as the splash screen).

Could about-screen use org-mode or outline mode and have a collapsed
list fetures, like compile options, included packages (dired, gnus, org
etc ...)?

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: Andrea Corallo <akrl@sdf.org>,  larsi@gnus.org,  43269@debbugs.gnu.org
> Date: Sat, 17 Oct 2020 20:48:53 +0200
> 
> > FWIW, I will repeat that my preference is 3.  This information doesn't
> > belong to the version, it belongs to the description of the build's
> > features, and thus to "about Emacs" (which needs to be revamped not to
> > show the same information as the splash screen).
> 
> Could about-screen use org-mode or outline mode and have a collapsed
> list fetures, like compile options, included packages (dired, gnus, org
> etc ...)?

It already has links, so it definitely could have more of them.

Why would we want to display that in Org is not immediately clear to
me.  It sounds like this will make the About display harder to use for
newbies who aren't familiar with Org.  What's wrong with simple links?
everybody is familiar with that nowadays.

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Corwin Brust]

On Sat, Oct 17, 2020 at 6:18 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Andrea Corallo <akrl@sdf.org>
> > Cc: 43269@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Sat, 17 Oct 2020 10:25:50 +0000
> >
> > The summary is that ATM options on the table are:
> FWIW, I will repeat that my preference is 3.  This information doesn't
> belong to the version, it belongs to the description of the build's
> features, and thus to "about Emacs" (which needs to be revamped not to
> show the same information as the splash screen).

It might be nice to show also whether we are using eln or elc (or el?)
for individual packages, e.g. from describe-package if not in
describe-function and friends.

Does that seem useful to others?.

Corwin

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Andrea Corallo <akrl@sdf.org>,  larsi@gnus.org,  43269@debbugs.gnu.org
>> Date: Sat, 17 Oct 2020 20:48:53 +0200
>> 
>> > FWIW, I will repeat that my preference is 3.  This information doesn't
>> > belong to the version, it belongs to the description of the build's
>> > features, and thus to "about Emacs" (which needs to be revamped not to
>> > show the same information as the splash screen).
>> 
>> Could about-screen use org-mode or outline mode and have a collapsed
>> list fetures, like compile options, included packages (dired, gnus, org
>> etc ...)?
>
> It already has links, so it definitely could have more of them.
>
> Why would we want to display that in Org is not immediately clear to
> me.
Thought just that we could get listing of all the stuff and hide in
folded org headline, so it is a bit prettier to look at; like "Show
more" buttons on some about screens. Maybe if we change from * to > or
some unicode emoji for triangle or something or SVG button as
demonstrated on /s/reddit yesteray that says "show more" and that
unfolds the list.

> It sounds like this will make the About display harder to use for
> newbies who aren't familiar with Org.  What's wrong with simple links?
> everybody is familiar with that nowadays.
See above, just for prettier looks; it would be big list of links if we
print all features included.

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: akrl@sdf.org,  larsi@gnus.org,  43269@debbugs.gnu.org
> Date: Sat, 17 Oct 2020 21:21:26 +0200
> 
> > It sounds like this will make the About display harder to use for
> > newbies who aren't familiar with Org.  What's wrong with simple links?
> > everybody is familiar with that nowadays.
> See above, just for prettier looks; it would be big list of links if we
> print all features included.

I'm sorry, but I don't think Org necessarily looks prettier than
normal text with links.

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: akrl@sdf.org,  larsi@gnus.org,  43269@debbugs.gnu.org
>> Date: Sat, 17 Oct 2020 21:21:26 +0200
>> 
>> > It sounds like this will make the About display harder to use for
>> > newbies who aren't familiar with Org.  What's wrong with simple links?
>> > everybody is familiar with that nowadays.
>> See above, just for prettier looks; it would be big list of links if we
>> print all features included.
>
> I'm sorry, but I don't think Org necessarily looks prettier than
> normal text with links.
I wanted the list to be folded, so either Org or Outline mode enabled;
I didn't ment that links themselves are prettier in Org :-). I am
talking about the structure of the text on the screen, but sure it can
be one link that open another buffer ...

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Corwin Brust <corwin@bru.st> writes:

> On Sat, Oct 17, 2020 at 6:18 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > From: Andrea Corallo <akrl@sdf.org>
>> > Cc: 43269@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
>> > Date: Sat, 17 Oct 2020 10:25:50 +0000
>> >
>> > The summary is that ATM options on the table are:
>> FWIW, I will repeat that my preference is 3.  This information doesn't
>> belong to the version, it belongs to the description of the build's
>> features, and thus to "about Emacs" (which needs to be revamped not to
>> show the same information as the splash screen).
>
> It might be nice to show also whether we are using eln or elc (or el?)
> for individual packages, e.g. from describe-package if not in
> describe-function and friends.
>
> Does that seem useful to others?.

I think is worth considering that:

- the compilation goes by file granularity not package

- unless tweaked out of default all sources gets compiled (before or
  later).  I expect (may be wrong) most people are going to use it this
  way as is the default behavior

You probably know it already but we get this information about single
functions with C-h f.

  Andrea
  

bug#43269: 28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

>> That's a different issue.  The original question was about the splash
>> screen and specifically about emacs-version.  I see no reason
>> whatsoever to show information about the native compilation there, as
>> it's a minor feature that moreover has no effect at all until some
>> Lisp files are compiled with it.

Skimming the thread here, I think the conclusion here was no vital
reason to say something about nativecomp on the welcome screen, so I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no