In terms of features, I imagine they are about the same. Here is why I think this. Maxima's function organization seems to follow and refers to the NIST Digital Library of Mathematical Functions https://dlmf.nist.gov/
Mathematica and Sympy also seem to follow this organization.
My take: I blame compatibility on the NIST Digital Library of Mathematical Functions.
Actually, no, shortening names won't speed bytecode up in the way you seem to be suggesting. Variables "are" indexed by position in some arrays like co_varnames, co_names, co_const and so on. See for example https://docs.python.org/3.8/library/dis.html?highlight=co_na...
There are maps in the code object that will turn the index back into a name, but that's only used when some sort of introspection occurs, such as you might find in a debugger or traceback.
The names found in an "import" of course is a string so there might some small advantage there in a shorter name.
As for round-tripping, I make use of that idea in testing the decompiler and/or looking for bugs (which are numerous). Python has an extensive test suite for its many library programs (in later versions in excesss of 800) which are largely written in Python.
The cool thing about a unit test program is that it is self checking.
uncompyle6 is far from perfect, so no, it doesn't roundrip all of the unit test programs that it could. (There are some unit test programs that are too fragile, like those that expect the line number to be exactly the same which might occur in tests testing a debugger).
The biggest problem as I've said many times is handling control flow properly. However that could be solved much better if someone who had more time to spend on this wanted to.
Yes and no. If you are sure that you start out with something generated by Python, then assuming the Python compiler is faithful, then of course you can always produces source code that doesn't have goto's in it. If instead someone crafts custom bytecode, like I did here: http://rocky.github.io/pycon2018-light.co/#/ it might not have a high-level Python translation.
When there is a translation, is it always unambiguous? No. The same bytecode could get decompiled "a and b" or as "if a: b".
Why this happens less often in Python, especially earlier versions fo Python, is that it's code generation is very much template driven and there very little in the way of the kinds of compiler optimization that would make decompiling control flow otherwise harder.
Using the example given above, I believe earlier versions of Python would always enclose the "then" statement/expression with "push_block", "pop_block" pairs. Even though in certain situations (no new variables are introduced in the "then" block) this isn't needed. But the fact that those two additional instructions are there can then distinguish between those two different constructs.
It is sort of like matching ancestry based on the largely "junk" DNA strands that exist in a person.
Finally, I should note that Python with its control structures with "else" clauses like "for/else" "while/else" and "try/else" make control flow detection much harder. And this is the major weakness of uncompyle6.
That's why I started https://github.com/rocky/python-control-flow to try to address this. In contrast, the current python uncompyle6 code which has a lot of hacky control flow detection, this creates a control flow graph, computes dominators and reverse domninators in support of distinguishing these high-level structures better.
Instead of taking a quick look at the description of how it works, why not instead spend a little more time to understand more, before passing judgement? I have written http://rocky.github.io/Deparsing-Paper.pdf to help people who want understand how this fits into the conventional decompiler landscape, and how things are a little different here.
Spoiler alert: no is it no more a glorified pattern-matching approach any more than a dragon-book-style compiler is.
The v8 debugger protocol rocks. The standard cli interface to it less so. For example, missing is simple frame-motion commands like "up", "down", with attendant evaluation in that context are possible from the protocol.
This tradition of cool debugger protocols with crappy CLI interfaces I first noticed in jdb. Creating a decent CLI isn't all that hard.
You might think well, no one uses CLI interfaces any more. As I watch my colleagues work, especially those who work in cloud and container-based systems, I am seeing that they are still using command-line interfaces quite a bit.
Finally, for those would-be command-line debugger interface writers, instead of inventing a new interface, why not pick an existing one to work off of? Here I selected gdb (as I've done in the 6 or so other debuggers I've done).
By doing this, as you learn any of the debuggers, you'll most likely be able to apply to the other debuggers, including gdb and vice versa.
What I have come to learn, especially with the stock node inspect, is that most people don't really know how to use the full power of what's already there. This is partly due to its differentness. But it is also partly due to its sparse documentation
Author here. Recently incorporated this into Python's traceback module: https://pypi.python.org/pypi/loctraceback
and have used this idea in Perl (which from the help of perlmonks is where I got the idea).
I am curious if it has been used in other programming languages as well.
Author here: In the last 3 years or so I've been working on a decompiler, and it is like a compiler in complexity, engineering, and testing. But different.
Since that URL is to a wiki, this is a better forum for comments. So I am happy to take comments and corrections here.
> There are many exciting developments in compiler technology but they do seem to me to be fragmentary and not yet put together
I think the same thing could have been said back in 1977, and the dragon book pulled all of these things together. What's needed is someone today doing the same kind of thing with current technology. (Publishers, if you are reading and think there's a market contact me ;-)
By the way... the person who wrote Turbo Pascal, Anders Hejlsberg, in fact went to Microsoft and was the principle architect behind Microsoft's J++, C#, probably the .NET runtime system. He is a lead architect there. See https://en.wikipedia.org/wiki/Anders_Hejlsberg
One of the things that I did notice in the 2nd edition is its preference to cite GCC in references.
What I don't know how to do, if you could help is register in Perl that I want my routine called when Perl hits an error, so that I can do the deparse and spit out a more detailed location message. Thanks!
Yeah, you win a few and lose a lot. I guess it all evens out.
Judging by github ratings, the debugger for zsh (zshdb) is more popular than I would have expected. And that means I have had to know more about zsh than I would have otherwise. Like bashdb, zshdb is packaged in Debian/Ubuntu; recently the debian maintainer asked me to update this for more recent zsh releases, which I've done.
By the way, I use github ratings to decide which of several projects to work on when there is a choice. remake ratings have shot up quite a bit by this post, so I guess I'll have to beef it up: add a screenshot of profiling and update the older versions of GNU make for more recent changes.
My recent focus has been on using decompilation as a means of getting more accurate position information. See https://github.com/rocky/python-uncompyle6/wiki/Deparsing-Pa... Sure, I use this in my debuggers, but it would be probably as or more valuable in tracebacks.
For example there is a decent decompiler in Perl for example: https://metacpan.org/pod/B::DeparseTree . I would love to figure out how to hook into Perl's traceback (not Carp, but the one for Perl) to augment that to give this more accurate position information.
I looked on my disk and I don't see a copy of the video. Or the notes I used to make the video. A shame because this was probably the more practical (day-to-day use) of the two. The closest I can find that is like an outline is what I covered in the 2007 talk I gave at UbuntuCon: https://wiki.ubuntu.com/DebuggerTalk
I will contact the showmedo person who asked for the video to see if he can pull off a copy.
Of course I am partial to savannah gnu and nongnu for its philosophy. However over the years there have been too many outages that made me switch one my projects from savannah to github.
Since beggars shouldn't be too picky, I don't fault savannah: it is seriously understaffed by volunteers. But still I switched to github (for some things) mostly from a pragmatic point of view. And to reduce my frustration level during the outages.
You are correct. At the time this was started there was no github; or git for that matter. I think I joined github around 2006 or so, and sometime after that converted either the CVS or svn repo to git.
And I was a bit lazy in setting up the project since I didn't know at the time how long it would last. So it is under the mostly unrelated bashdb project that I started earlier. (The tenuous relationship was that I wanted to debug autoconf configure scripts, and having done that I then realized I often also needed to debug the Makefiles that automake produced. Okay I tried to motivate that, but really it was laziness.)
As for sourceforge or github, there are a couple of things. As others have mentioned, sourceforge has a file release section. That is very useful for those who want to work off of release tarballs, rather than git tags. And the download stats can be ordered by both OS of downloading browser and Geography.
https://sourceforge.net/projects/bashdb/files/remake/stats/t... says mostly downloaded in US with MS Windows. Looks like the SF mapping function is broken, but I used to find it fun to see country distribution. Continent-wise, Africa has always been the lowest in activity.
Over the years sourceforge has proved very reliable and has done lots of people a great service.
In the early days I admired how good it was. Yes, it is unfortunate that they couldn't figure out how to monetize the good work they had done. Well, I have the same problem too. I'm not one to forget the good work they have accrued in the past. However, as you saw, I did switch to github for day-to-day use and use sourceforge for released tarballs, and mailing lists.
I don't see anything wrong with using multiple providers. I also use Travis, CircleCI and Appveyor for continuous integration testing.
We are looking for a someone who is passionate about devops [1] and will get us to the next level growing computer operations at MyPizza.
...
About us:
We are MyPizza, the best way to order local, independent pizza online and we bring technology to pizza places and pizza-oriented restaurants.
In devops, we are constantly are looking for ways to improve our computer operations using a devops orientation. We are constantly looking to automate ourselves out of a job. We are always looking for flaws in our system. ...
Mathematica and Sympy also seem to follow this organization.
My take: I blame compatibility on the NIST Digital Library of Mathematical Functions.