dgtized
Error When Cloning: `void-variable cl--nm`
Possibly related to native compilation?
Reproduction
-
M-x github-clone - Choose a repo—doesn't seem to matter whether it's in url or username/repo format.
- Choose a directory.
Error Message
Debugger entered--Lisp error: (void-variable cl--nm)
#f(compiled-function (&rest args) #<bytecode -0x155fd4ec0f8dd2f6>)()
#f(compiled-function (cl--cnm api &rest args) #<bytecode 0x171ba23de7cb8816>)(#f(compiled-function (&rest args) #<bytecode -0x155fd4ec0f8dd2f6>) #<gh-repos-api gh-repos-api-157c081e68ea> nil)
apply(#f(compiled-function (cl--cnm api &rest args) #<bytecode 0x171ba23de7cb8816>) #f(compiled-function (&rest args) #<bytecode -0x155fd4ec0f8dd2f6>) (#<gh-repos-api gh-repos-api-157c081e68ea> nil))
#f(compiled-function (&rest cl--args) #<bytecode 0xafaf87c3cc877a4>)(#<gh-repos-api gh-repos-api-157c081e68ea> nil)
apply(#f(compiled-function (&rest cl--args) #<bytecode 0xafaf87c3cc877a4>) #<gh-repos-api gh-repos-api-157c081e68ea> nil)
initialize-instance(#<gh-repos-api gh-repos-api-157c081e68ea> nil)
#f(compiled-function (class &rest slots) "Default constructor for CLASS `eieio-default-superclass'.\nSLOTS are the initialization slots used by `initialize-instance'.\nThis static method is called when an object is constructed.\nIt allocates the vector used to represent an EIEIO object, and then\ncalls `initialize-instance' on that object." #<bytecode -0x197004fac24923e3>)(gh-repos-api)
apply(#f(compiled-function (class &rest slots) "Default constructor for CLASS `eieio-default-superclass'.\nSLOTS are the initialization slots used by `initialize-instance'.\nThis static method is called when an object is constructed.\nIt allocates the vector used to represent an EIEIO object, and then\ncalls `initialize-instance' on that object." #<bytecode -0x197004fac24923e3>) gh-repos-api nil)
make-instance(gh-repos-api)
apply(make-instance gh-repos-api nil)
gh-repos-api()
github-clone-info("abbreviatedman" "dangerroom")
github-clone("abbreviatedman/dangerroom" "~/Documents/side-projects/")
funcall-interactively(github-clone "abbreviatedman/dangerroom" "~/Documents/side-projects/")
command-execute(github-clone record)
execute-extended-command(nil "github-clone" nil)
funcall-interactively(execute-extended-command nil "github-clone" nil)
command-execute(execute-extended-command)
Yea I can confirm that is happening, and am also using native compilation, but unsure what would trigger it. I suspect this is more of an issue with either gh.el or native compilation support for eieio? Possibly related to https://github.com/sigma/gh.el/issues/109?
I'll take a look at gh.el at some point soon, but I'm not certain I'm up to rebuild all of that just to support this package if upstream is no longer functioning. Maybe there is a quick fix there?
Another option, which I'm not sure about, is I know magit forge needs to interact with the github api, so maybe there is something that could be leveraged there as an alternative? Or maybe it's now covering this use case, I haven't explored that recently.
Sorry I don't have a good answer here, I'll see if I can take a look in the next week.
