bbatsov
commented
3 years ago Seems that the EDN parser is struggling with something in your config. @plexus might have a better idea what exactly the problem is.
Closed evanlouie closed 3 years ago
bbatsov
commented
3 years ago Seems that the EDN parser is struggling with something in your config. @plexus might have a better idea what exactly the problem is.
plexus
commented
3 years ago Quite bizarre, did you upgrade your emacs recently? it seems like cl-case is misbehaving
(defun parseclj-lex--leaf-token-value (token)
"Parse the given leaf TOKEN to an Emacs Lisp value."
(cl-case (parseclj-lex-token-type token)
(:number (string-to-number (alist-get :form token)))
(:nil nil)
(:true t)
(:false nil)
(:symbol (intern (alist-get :form token)))
(:keyword (intern (alist-get :form token)))
(:string (parseclj-lex--string-value (alist-get :form token)))
(:character (parseclj-lex--character-value (alist-get :form token)))))It's treating that :number as a function call, rather than a value to match against.
evanlouie
commented
3 years ago @plexus
did you upgrade your emacs recently? it seems like cl-case is misbehaving
Sort of. I was using emacs-plus@27 for a while and everything was working fine. But then decided to give compiling gccemacs a go but that was just buggy in general. So I then reverted back to emacs-plus@27, and then this error started. I've since switched emacs-mac, but the error is still persisting.
I've also been able to recreate this issue on a newly formatted MacOS 11.1 machine with emacs-mac 27.1 running doom-emacs@develop.
evanlouie
commented
3 years ago Just recreated the the bug again on Ubuntu. Same setup, emacs@27.1 , doom-emacs@develop. For recreation, you can any of:
evanlouie
commented
3 years ago After some more digging I've found that this issue seems to be related to doom-emacs as it doesn't occur with spacemacs. I'll close this issue and open it on on the doom repo.
aiba
commented
3 years ago I just started hitting this same error. I'm using emacs-mac 27.2.
I think parseedn may be busted. When I evaluate (parseedn-read-str "{:a 1}") I get this stacktrace:
Debugger entered--Lisp error: (void-function :number)
:number(0)
parseclj-lex--leaf-token-value(((:token-type . :keyword) (:form . ":a") (:pos . 2)))
parseedn-reduce-leaf((((:token-type . :lbrace) (:form . "{") (:pos . 1))) ((:token-type . :keyword) (:form . ":a") (:pos . 2)) ((:tag-readers)))
parseclj-parser(parseedn-reduce-leaf parseedn-reduce-branch ((:tag-readers)))
parseedn-read(nil)
parseedn-read-str("{:a 1}")
eval((parseedn-read-str "{:a 1}") nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
vemv
commented
3 years ago Last batch of parseedn problems were fixed with https://github.com/clojure-emacs/cider/pull/3060 , are you running a recent cider.el snapshot?
If the problem persists, it would be helpful to know if it can also be observed with https://emacsformacosx.com/ which is much more vanilla than emacs-mac (of course trying it is just a one-off thing)
aiba
commented
3 years ago Same error with emacsformacosx (GNU Emacs 27.2 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95)) of 2021-03-27).
I think I'm using the latest cider.el snapshot: CIDER 1.2.0snapshot (package: 20211003.947)
When you run (parseedn-read-str "{:a 1}"), you don't get that error?
vemv
commented
3 years ago When you run (parseedn-read-str "{:a 1}"), you don't get that error?
I can't help much here but perhaps something comes to mind to @plexus or @bbatsov ?
bbatsov
commented
3 years ago Probably deleting the installed packages CIDER, parseclj and parseedn and installing CIDER again is the best course of action at this point.
danjohansson
commented
3 years ago I'm having this problem as well. Downgrading parseedn and parseclj to 0.2.0 and the problem goes away. Upgrading and it comes back. Code to reproduce:
(require 'parseedn)
(parseedn-read-str "1")It is reproducable in doom vanilla emacs sandbox too.
GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.17.4) of 2021-03-26
plexus
commented
3 years ago As I've hinted at above this seems to be an Emacs regression in cl-case. The only fix we can do is rewrite the parseedn logic to not rely on cl-case.
plexus
commented
3 years ago I've opened PRs for parseclj and parseedn (parseedn relies on parseclj).
@evanlouie @aiba @danjohansson would be great if you could confirm that on your Emacs version, using parseclj/parseedn from git branch cl-case-to-cond, this works:
(require 'parseedn)
(parseedn-read-str "1")
;; => 1@plexus I still have the same problem.
The cl-case that gives the error in parseclj-lex--leaf-token-value has not changed in that branch?
danjohansson
commented
3 years ago If it helps: Running (parseclj-lex--leaf-token-value '((:token-type . :number) (:form . "1") (:pos . 1))) gives me the same error.
But if I evaluate the function manually and run it again it works.
Can it be something with dynamic binding or evaluation order? @plexus
plexus
commented
3 years ago 
plexus
commented
3 years ago This is what parseclj-lex--leaf-token-value looks like now. If it still hase a cl-case then you are not on the right version.
(defun parseclj-lex--leaf-token-value (token)
"Parse the given leaf TOKEN to an Emacs Lisp value."
(let ((token-type (parseclj-lex-token-type token)))
(cond
((eq :number token-type) (string-to-number (alist-get :form token)))
((eq :nil token-type) nil)
((eq :true token-type) t)
((eq :false token-type) nil)
((eq :symbol token-type) (intern (alist-get :form token)))
((eq :keyword token-type) (intern (alist-get :form token)))
((eq :string token-type) (parseclj-lex--string-value (alist-get :form token)))
((eq :character token-type) (parseclj-lex--character-value (alist-get :form token)))
((eq :symbolic-value token-type) (intern (substring (alist-get :form token) 2))))))@plexus sorry, I only checked out parseedn. My bad.
plexus
commented
3 years ago No worries, I'll try to cut a release soon, but would be great if at least one person could confirm that this a) fixes the issue, and b) still seems to work in general :D
plexus
commented
3 years ago The split into two libraries is unfortunate, it should really be one code base, but it was one of the things we had to do to be considered for inclusion in MELPA.
danjohansson
commented
3 years ago With those fixes in place I get a different error: (I will double check my setup...)
Debugger entered--Lisp error: (void-function key)
key((inst uuid))
parseclj-alist-merge(((inst . #f(compiled-function (s) #<bytecode 0x156f1be68819>)) (uuid . #f(compiled-function (s) #<bytecode 0x156f1be6f629>))) nil)
parseedn-reduce-branch(nil ((:token-type . :root) (:form . "") (:pos . 1)) (1) ((:tag-readers)))
parseclj-parser(parseedn-reduce-leaf parseedn-reduce-branch ((:tag-readers)))
parseedn-read(nil)
parseedn-read-str("1")
eval((parseedn-read-str "1") nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
eros-eval-last-sexp(nil)
funcall-interactively(eros-eval-last-sexp nil)
call-interactively(eros-eval-last-sexp nil nil)
command-execute(eros-eval-last-sexp)Does this work for you? Do a and b show up in the messages buffer?
(require 'seq)
(let ((keys '(a b)))
(seq-doseq (key keys)
(message "%S" key)))Yes that works... :thinking:
plexus
commented
3 years ago Then I'm out of ideas... this is exactly what that code does. :/
https://github.com/clojure-emacs/parseclj/blob/master/parseclj-alist.el#L83-L89
plexus
commented
3 years ago I've replaced the seq-doseq with a mapcar, how about now?
danjohansson
commented
3 years ago Yeah the feeling I get is that some core functionality has been overriden by something. But I don't know elisp very well. I will see if I can get some time to dig a little deeper.
Thanks for the help so far! :+1:
danjohansson
commented
3 years ago @plexus I will give it a go
danjohansson
commented
3 years ago @plexus that did the trick! :)
plexus
commented
3 years ago Effing emacs... Emacs lisp is bad enough as it is, but stuff just randomly not working on some builds is absolutely infuriating. Anyway glad this works now, I'll release new parseclj/parseend versions.
plexus
commented
3 years ago Moral of the story, don't use any macros from cl-lib, seq, or map. It may seem convenient but it will come to bite you.
danjohansson
commented
3 years ago Thanks for the help! :+1:
aiba
commented
3 years ago Wow, thank you guys for tracking this down! Good to know about avoiding those elisp libs.
plexus
commented
3 years ago It's a real shame because these are the libs that make elisp bearable, but this is the second issue we have like this, first with cl-case and now with seq-doseq where part of a macro form is interpreted as a function call, but only for some people. It's really puzzling, and I'm not sure if it's an emacs regression/bug, a particular interplay with other packages, or if we're holding it wrong. Happy there are workarounds but it adds to the frustration of dealing with elisp.
plexus
commented
3 years ago Released in parseclj / parseedn v1.0.6
vemv
commented
3 years ago Should we bump the minimum requirement in cider.el?
plexus
commented
3 years ago yes, that would be a good idea.
This error started a couple days ago.
Expected behavior
When in a shadow-cljs project, I should be able to run:
C-c C-x j mshadowActual behavior
After running
C-c C-x j mand selectingshadowan errors is printed:When
toggle-debug-on-erroris enabled, the following is dumped:Steps to reproduce the problem
Project Setup:
Run it with either of:
C-c C-x C-c s:npx shadow-cljs watch appC-c C-x C-c s, selectlocalhost, select the shown port, selectshadowC-c C-x j mC-c C-x C-c sin the projectEnvironment & Version information
Mac:
Linux:
Both running doom-emacs@develop
CIDER version information
C-c -C-x j msuccessfully starts a Clojure repl before erroringEmacs version
GNU Emacs 27.1 (build 1, x86_64-apple-darwin20.2.0, Carbon Version 164 AppKit 2022.2) of 2021-01-14Operating system
Pop!_OS 20.04macOS 11.1