Error on Emacs 26.1

[zzamboni]

Hi,

Based on this blog post, I've been trying to optimize my Emacs startup time, and I wanted to give esup a try - it looks like a very interesting tool.

When I run esup, I get the following messages:

esup process started on port 53850
at 1
error in process sentinel: eieio-oref: Wrong type argument: (or eieio-object class), nil, obj
error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj

In addition, I get three *esup- buffers, with the following contents:

*esup-log*: https://gist.github.com/zzamboni/16e989ea5173a1c47327bcb5fdb86411 *esup-child*: empty *esup-results*: https://gist.github.com/zzamboni/146c03d4d4b3feff50b35ea2b13ff901

I am running Emacs 26.1-pre1 from Homebrew, the full output of (emacs-version) is GNU Emacs 26.1 (build 1, x86_64-apple-darwin17.4.0, NS appkit-1561.20 Version 10.13.3 (Build 17D102)) of 2018-04-22.

For reference, my current configuration file is here: https://github.com/zzamboni/dot-emacs/blob/20686af45a3b33629480713018ea88b1164b6b79/init.el

[serycjon]

Same here

[azzamsa]

Same here

error in process sentinel: eieio-oref: Wrong type argument: (or eieio-object class), nil, obj
error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj

with

GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-15, modified by Debian

[casouri]

51, #52 and #54 are the same, should we close the latter and keep only #51?

[CeleritasCelery]

same issue. Interestingly, I don't always get this, but I can't seem to figure out why it happens.

[ckeschnat]

I accidentally posted this on #51, which is closed. So I'll repeat this here:

I also stumbled upon this after trying to switch to straight.el which compiles everything. After reverting to package.el (and not having any *.elc) esup worked again.

GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30 Windows 10 esup-20180727.342

[maindoor]

Same problem here.

[mddavila]

me too:

error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj [2 times]

[ckeschnat]

me too:

error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj [2 times]

Haven't tried, but here might be a solution: https://github.com/raxod502/straight.el/issues/332

[jschaf]

Hey all, I mostly use IntelliJ (Java pays the bills) these days. I'd be happy to mentor someone through the code but I don't have a ton of time to investigate this particular bug.

This could be a few things:

1. elc files for a different version of Emacs. Emacs byte-code (.elc) is not stable between major version.

2. An esup bug. Esup isn't that smart about how it does profiling and it turns out the Emacs load sequence is somewhat complicated.

3. straight.el might monkey-patch loading which causes esup to get confused.

[samangh]

I've been having the same exact problem. Clearing my elpa/ folder fixed this issue. So it seems that that it's reason 1 (i.e. incompatibility between Emacs byte-code), at least in my case.

[lockie]

Same problem here using use-package:

error in process sentinel: slot-value: Wrong type argument: (or eieio-object class), nil, obj
error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj

Emacs 26.3, Linux.

[Digicrat]

Same here. I also have use-package and am running Emacs 25.2.2 in an Ubuntu WSL installation.

Interestingly, running esup under Windows-Native 26.3 (with the same emacs init file) gives no error.

[Digicrat]

I just found a case where changing one line causes the sentinel error to appear on my Windows-Native 26.3. (I've managed to reduce 1.5s from my load time using the esup results so far, rerunning esup several times before discovering this)

(use-package org
 ;; :mode "\\.org\\'"  ;; If I uncomment this line, then esup gives the sentinel error
  :ensure org-plus-contrib
  :pin org)

Of course, I subsequently discovered that setting that :mode line caused other issues, but hopefully the fact it's also causing the sentinel issue is a clue of some sort.

[0xtmphey]

I faced the same problem and for me it was cider. When I comment out (use-package cider) esup works just fine.

[dinkonin]

Same for me but the package was evil-collection.

[zzamboni]

FWIW, I hadn't tried esup in a while, but I am now on Emacs 26.3, and it works fine with the same config as before.

[spacekitteh]

Same error on 27.0.91.

[anildigital]

Starting esup...
esup process started on port 59023
Unable to load color "unspecified-fg" [2 times]
at 1
error in process sentinel: slot-value: Wrong type argument: (or eieio-object class), nil, obj
error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj

Emacs 27.0.91 macOS

I have added following to load esup using use-package

(use-package esup
  :ensure t
  ;; To use MELPA Stable use ":pin mepla-stable",
  :pin melpa
  :commands (esup))

[DarkBuffalo]

Same error on GNU Emacs 26.3 error in process sentinel: slot-value: Wrong type argument: (or eieio-object class), nil, obj error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj

[thdox]

same error here, emacs 26.1

[benley]

This seems to help:

;; Work around a bug where esup tries to step into the byte-compiled
;; version of `cl-lib', and fails horribly.
(setq esup-depth 0)

(found in https://github.com/raxod502/radian/blob/c4246176155873d3937ff997965279048dabbc01/emacs/radian.el#L4423-L4476)

[nettoyoussef]

This seems to help:

;; Work around a bug where esup tries to step into the byte-compiled
;; version of `cl-lib', and fails horribly.
(setq esup-depth 0)

(found in https://github.com/raxod502/radian/blob/c4246176155873d3937ff997965279048dabbc01/emacs/radian.el#L4423-L4476)

This worked for me. And, from the likes, probably for several others. Just to highlight it if anybody else stumbles on this.

[salexan2001]

The workaround proposed by @nettoyoussef also works for me.

[applePrincess]

same-ish here with init file

(require 'package)

and emacs version

"GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)"

EDIT: sorry I did not read the depth workaround, this works with (require 'package).

[KevOrr]

Reposting from #85, since now that issue seems it might be a duplicate of this one, though this issue could benefit from a more descriptive title to aid discovery.

Looks like *esup-results* contains one entry that looks like

;;ESUP-RESULT-SEPARATOR;;
(list
  )

This gets parsed as nil in esup-read-results, which makes (slot-value result 'expression-string) choke in esup-fontify-results. I've fixed it locally by changing

diff --git a/esup.el b/esup.el
index 737b3aa..0b5fbe1 100644
--- a/esup.el
+++ b/esup.el
@@ -592,7 +592,8 @@ current lexical context."
       (message "at %s" esup-last-result-start-point)
       (unless (eobp)
         (while (setq sep-end-point (esup-next-separator-end-point))
-          (setq results (cons (car (esup-read-result (point))) results))
+          (when-let ((result (car (esup-read-result (point)))))
+            (push result results))
           (setq esup-last-result-start-point sep-end-point)
           (goto-char esup-last-result-start-point))))
     (nreverse results)))

but possibly esup-fontify-results and other functions that consume that list should do nil checking as well. The root cause does seem to do something with bytecode, around the (benchmark-run (eval sexp)) call in esup-child-profile-string.

My root cause was that I had coincidentally misconfigured my PATH, so one emacs version was using bytecode compiled for a slightly different emacs version. However, since this error (choking on a nil) seems to crop up in many ways, the suggested changes, or similar changes, will help esup be more robust.

[zhangshenhua]

same with GNU Emacs 26.2 (build 1, x86_64-w64-mingw32)

[siraben]

Ran into this as well, GNU Emacs 28.0.60 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H1417)). Setting esup-depth to 0 fixed it.