Closed cydparser closed 4 years ago
@cydparser can you turn on toggle-debug-on-error
and see if you get a similar callstack as below? Just trying to get more information to see if I'm experiencing the same problem.
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
dante-set-state(ready)
dante-schedule-next(#<buffer *dante::all:~/src/shajra/example-nix/tutorials/2-haskell/*>)
#f(compiled-function (input) #<bytecode 0x131eefd>)("e|")
#f(compiled-function (input) #<bytecode 0x131ef21>)("e|")
#f(compiled-function (process string) #<bytecode 0x1308215>)(#<process dante> "e|")
Okay, just more information. I am seeing this problem on both Emacs 26 and 27 introduced with commit 3c50fa4. I reverted to the commit right before (dd0f460) and the problem goes away.
My stacktrace from toggle-debug-on-error
looks a little different from the one I got before, though:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
set-buffer(nil)
(save-current-buffer (set-buffer (dante-buffer-p)) (set (make-local-variable 'dante-state) state))
dante-set-state(ready)
(if req (funcall req buffer) (dante-set-state 'ready))
(let ((req (car-safe (prog1 dante-queue (setq dante-queue (cdr dante-queue)))))) (if req (funcall req buffer) (dante-set-state 'ready)))
(if lcr-process-callback (force-mode-line-update t) (let ((req (car-safe (prog1 dante-queue (setq dante-queue (cdr dante-queue)))))) (if req (funcall req buffer) (dante-set-state 'ready))))
(save-current-buffer (set-buffer buffer) (if lcr-process-callback (force-mode-line-update t) (let ((req (car-safe (prog1 dante-queue (setq dante-queue ...))))) (if req (funcall req buffer) (dante-set-state 'ready)))))
dante-schedule-next(#<buffer *dante::example-haskell-lib:~/src/shajra/example-nix/tutorials/2-haskell/*>)
(closure ((buffer . #<buffer *dante::example-haskell-lib:~/src/shajra/example-nix/tutorials/2-haskell/*>) (cont closure ((atom592) (atom588) (atom585) (atom582) (rest . "\nOk, two modules loaded.\nCollecting type info for ...") (atom581) (m) (atom580) (i) (atom579) (atom578 . t) (while577 closure #18 nil (let (...) (if atom578 ... ...))) (result ok nil "Prelude Lib") (err-regexp . "^\\([A-Z]?:?[^ \n:][^:\n\15]+\\):\\([0-9()-:]+\\): \\(.*\\)\n...") (progress . "^\\[\\([0-9]*\\) of \\([0-9]*\\)\\] Compiling \\([^ \n]*\\)...") (success . "^Ok, modules loaded:[ ]*\\([^\n ]*\\)\\( (.*)\\)?.\\|^Ok...") (atom576 . "^Ok, modules loaded:[ ]*\\([^\n ]*\\)\\( (.*)\\)?.\\|^Ok...") (atom575 . loading) (lcr--continuation closure ((atom562) (atom561 . #<buffer *dante::example-haskell-lib:~/src/shajra/example-nix/tutorials/2-haskell/*>) (buf . #<buffer Lib.hs>) (atom560 . #<buffer Lib.hs>) (v558 . "") (atom559 . ":set -fobject-code") (atom557) (atom556 . "/home/tnks/src/shajra/example-nix/tutorials/2-hask...") (atom555) (atom554 . 212) (atom552) (same-target . t) (atom551 . t) (buffer . #<buffer *dante::example-haskell-lib:~/src/shajra/example-nix/tutorials/2-haskell/*>) (v550 . #<buffer *dante::example-haskell-lib:~/src/shajra/example-nix/tutorials/2-haskell/*>) (fname . "/tmp/danterFkmb8.hs") (atom549 . "/tmp/danterFkmb8.hs") (src-fname . "/home/tnks/src/shajra/example-nix/tutorials/2-hask...") (atom548 . "/home/tnks/src/shajra/example-nix/tutorials/2-hask...") (unchanged) (atom547) (epoch . 212) (atom546 . 212) (lcr--continuation closure ... ... ...) (err-fn) (interpret) t) (v563) (let* (...) (let ... ...))) (err-fn) (err-msgs) (acc . "\nCollecting type info for 1 module(s) ... \n\4Prelud...") t) (v597) (let ((v596 (concat acc v597))) (let ((v595 ...)) (let (...) (lcr-yield while577))))) t) (input) (dante-debug 'inputs input) (funcall cont (s-replace "\15" "" input)) (dante-schedule-next buffer))("modules loaded.\nCollecting type info for 1 module(...")
#f(compiled-function (input) #<bytecode 0x17fd1b5>)("modules loaded.\nCollecting type info for 1 module(...")
#f(compiled-function (process string) #<bytecode 0x11afb49>)(#<process dante> "modules loaded.\nCollecting type info for 1 module(...")
One reason for the different stack trace might be because I deleted out dante.elc
. Not sure.
As probably makes sense, this problem can be avoided by reverting this hunk. I validated that this seems to work.
I don't know what we really lose by not setting Dante's state to "ready."
I do believe that this is fixed in master. Could you please take a second look?
I no longer see the error. Thanks!
This change causes an error for me when setting
dante-target
in .dir-locals.el`:The dante special buffer is already the current buffer when that line is evaluated.
dante-target
evaluates to nil, so the buffer name generated bydante-buffer-name
does not match.