4

I'm thinking of writing one so that when I get those horrible tracebacks from bytecode files, I can better see where I was at.

Is there one already?

Are there any other tools for showing an error traceback in more Elisp programmer terms rather than computer- (not-human)-oriented elisp bytecode?

Edit: For what it's worth, I've started this on github

It seems to work find on the subset of things I've put in so far. So the two major items are to fill it out more which I have been doing slowly, and covert it all to Emacs Lisp from Python. (That too seems straightforward, just a bit of work.)

phils
  • 50,977
  • 3
  • 79
  • 122
rocky
  • 898
  • 7
  • 26
  • Have a look at disassemble. – Tobias Sep 10 '17 at 06:33
  • Um, I said decompile not "disassemble". However decompilers generally start off with a disasembly. See https://en.wikipedia.org/wiki/Decompiler – rocky Sep 10 '17 at 07:37
  • Personally, I believe that for the usecase of showing decent backtraces you'd be better off fixing Emacs than writing a decompiler. – wasamasa Sep 10 '17 at 08:56
  • 2
    Not yet, as far as I know. But I think they're working on providing this in an upcoming Emacs release (26.1?). See this and subsequent messages in Emacs bug #25295 thread. – Drew Sep 10 '17 at 15:04
  • @wasamasa there are only two alternatives. Either in the compilation step you change the way information is recorded, or you don't and do a decompile. So one approach to "fixing" emacs is having the decompile built in. As for changing the way information is recorded, I've been down that road many many times unsuccessfully. And I get it. Changing the whole compilation is a big task and is error prone. Decompiling can be an independent separate process so it is isn't disruptive. – rocky Sep 10 '17 at 21:45
  • @Drew the thrust as I gather is to allow the print routine to be customizable. How you make use of the customization is another matter. It is conceivable that EIEIO has a way to record decent backtrace information. I don't see details of that in the thread. It is possible the unspecified print routine can be used outside of EIEIO. I'll ask stephan monier directly. – rocky Sep 10 '17 at 21:49
  • 1
    Yes, that thread does not explicitly say that they plan to use what is discussed there to make backtrace parts that currently show byte-code be human-readable. Good idea to ask Stefan. But perhaps see also bug #6991. – Drew Sep 11 '17 at 00:29
  • @Drew In other places it seems that they are just going to strip out control characters. Thanks for the links. – rocky Sep 11 '17 at 01:09
  • In case you are interested in seeing whether an autoloaded function has been processed yet, see: https://emacs.stackexchange.com/a/32114/2287 In my case, I wanted to see what was calling a library relating to an autoloaded function ... I have this running 24/7 so that I can always see when a new library is being loaded pursuant to an autoloaded function. – lawlist Sep 28 '17 at 01:58
  • I'd say disassemble is a good place to start... then follow a guide on how to grok the bytecode that Elisp uses, such as this one. In fact, reading a disassembly rather than the source code will give you a more honest view of what's really going on. – GDP2 Sep 28 '17 at 18:49
  • @GDP2 WRT "In fact, reading a disassembly rather than the source code": while that is true, most emacs users barely know elisp let alone byte code, and that is why Emacs has gotten away with such largely undocumented bytecode. Deparsing (when it is correct) is every bit as honest. And all emacs programmers know that. When I try to understand LAP, the first thing I have to do is basically what the decompiler does. This kinds of tedium is exactly the thing that computers are best suited for. They also do it much faster than I as well. – rocky Sep 30 '17 at 20:01
  • @rocky Sure, I agree with everything you're saying. I just figured learning to read byte-code would be easier than creating a decompiler. But hey if you want to put in the effort to make it, go for it! Sounds really cool and it sure would be interesting to see how you implement it. – GDP2 Sep 30 '17 at 20:32
  • @GDP2 Yes, it is really cool and I'm probably one of the very few people who would know how to do it in a not-hacky fashion. WRT " would be interesting to see how you implement it" there's no mystery there. See the github project cited and make sure you star it ;-) That has links where I describe the technology. https://gist.github.com/rocky/abc7b8ba12cfe50af32d785a1fdd0261 is a nontrivial work in process example. I wonder how long it would take you to reconstruct this knowing LAP. (A computer does it in a second or so). Wish I could figure out how to make a living from this. – rocky Oct 02 '17 at 21:34
  • @rocky Thanks for the info and the links. Definitely something to keep an eye on and maybe contribute to if I have time... Re: "Wish I could figure out how to make a living from this." -- Don't we all, brother. – GDP2 Oct 02 '17 at 22:40
  • @GDP2 and others: please do contribute if you have the time. There still is much to do, but the work spent here might be repaid in time saved that you spend trying to understand what's going on in LAP code. The more I see what that's about the more I am convinced that most people have only a vague idea how it works. Just documenting what the opcodes done as is done say for Python bytecodes https://docs.python.org/3.6/library/dis.html#python-bytecode-instructions would be a big service to emacs users. – rocky Oct 03 '17 at 14:49

0 Answers0