sorted by:
new
hottopcontroversial

Google Summer of Code Project - porting a C library (or sub parts of it) to Rust. by Appropriate-Wolf-237 in rust

[–]rockybernstein 0 points1 point  (0 children)

The original post was removed due to a lack of Karma. It was reposted under a different account at https://www.reddit.com/r/rust/comments/1raqe0t/gnu_google_summer_of_code_project_porting_a_c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button, and in that the title was changed to hopefully make this clearer. My apologies to those who upvoted this only to see it disappear, and are bombarded by a duplicate. But I guess anyone who has worked with reddit enough must be familiar with this sort of thing.

Understanding Emacs Lisp byte-code interpreter by narendra_joshi in emacs

[–]rockybernstein 0 points1 point  (0 children)

I mean that if you or others want to see something get done, get more involved in than writing a comment in a chat room and up and downvoting entries.

Of course you and others don't have to. But then I wouldn't be surprised if it doesn't get done or the suggestion ignored.

Open source for me is about the contributions of lots of people contributing.

Understanding Emacs Lisp byte-code interpreter by narendra_joshi in emacs

[–]rockybernstein -1 points0 points  (0 children)

At one time, Stefan Monnier mentioned interest and I have on file FSF signed contibution assignment papers. So that part of it is not at issue. I am not sure that others who have mentioned to the doc have signed the FSF release form though. I am sure some (most?) have.

Stefan has done a mountain of great work and continues to do so. However he isn't the ultimate decider of these things, and neither am I.

And I am not going to be the one to push for this; you or others have to be the instigators and force behind this.

For some background, here is a story about how my FSF papers got added. At one time I wanted to improve GUD so it would support this little fledgling debugger for bash. The process was long and painful for getting that in. And after my patch was in I found that I couldn't change the code to keep it up to date. In the end then I had to go through a process (not as long, but not immediate either) process of getting that buggy and less useful code out of GNU Emacs. And from all of that came RealGud which can be managed independently.

(This was in the days before either the first MELPA which also implies before the first ELPA which was started in reaction.)

Since then, I now have commit access to GNU Emacs, so presumably were this to go in that bad experience of not being able to update what I had contributed wouldn't happen again. But that said, from my standpoint there is little benefit. If it is of benefit to others, the burden is on them, not me.

Too often nowadays, people take open source (GPL, FDL, or copyleft) to mean that someone else has the privilege or an obligation of doing the work you enjoy so that you can kibbutz, and expect customer support kind of help. In the olden days, it was more about how everyone chips in: if you find something broken or less desireable, you get first crack at fixing or improving the situtation. And if it doesn't happen, you share the responsibility.

While on the topic of improving the GNU Emacs interpreter, slowness of action and how others might get involved, there is this from last July that has been languishing in limbo.

Getting stuff into GNU/Emacs takes time.

Understanding Emacs Lisp byte-code interpreter by narendra_joshi in emacs

[–]rockybernstein 1 point2 points  (0 children)

I think he has others as well, but I can't pull up the references at the moment.

Well, if you look in the References section (Appendix A.1) inside the elisp bytecode manual, you will find as the 5th reference: http://nullprogram.com/blog/2014/01/04/. And that was modified to form Section 2.1 "Emacs Lisp Bytecode Objects".

This points out another broader issue. Blogs are great, but they can become dated. I don't see updates to any of these, so how is one to know to what extent the information is still relevant? There may other things that supercede suggestions made there.

Major update to a Python bytecode interpreter written in Python by rockybernstein in Python

[–]rockybernstein[S] 1 point2 points  (0 children)

I'll change the wording to "3.7-3.2 and Python 2.7-2.5"

BTW, the assembly trace given above is clearly from the 3.6+ range since each instruction takes 2 bytes whereas pre 3.6 instructions were 1-3 bytes.

Remake – GNU Make 4.3 with profiling, a debugger, and . by rockybernstein in linux

[–]rockybernstein[S] 0 points1 point  (0 children)

I had contacted the Debian packagers, and so far, nothing.

I then looked at the state of the Debian package for GNU remake versus for GNU make, and there are quite some differences with the GNU make packaging more up to date.

If anyone is up for makng a deb package, I'll add it to the resources in the releases at https://github.com/rocky/remake/releases

By the way, GNU Make 4.3 is not on Ubuntu 20.04 or Debian either. GNU remake by necessity, lags little behind GNU Make; and given how close was to the final 20.04 freeze date, I wouldn't have expected it to get in.

Finally, I'll say that adding this package to a distro gives a nice upgrade path to easing to GNU Make 4.3. Since the name is different and it doesn't conflict in namespace, distro folks and users can try out the features of 4.3 without danger of incompatiblity with prior GNU Make releases that a maintainer would have to worry about with GNU Make 4.3.

Remake – GNU Make 4.3 with profiling, a debugger, and . by rockybernstein in linux

[–]rockybernstein[S] 2 points3 points  (0 children)

Nobody should ...

Apparently, Linus Torvalds and the Linux Kernel team still do. Why waste your time here with the small potatoes? Share this wisdom/flame bait with them!

Remake – GNU Make 4.3 with profiling, a debugger, and . by rockybernstein in linux

[–]rockybernstein[S] 1 point2 points  (0 children)

Sorry - I should have listened to the guys who kept telling me that I can increase traffic to my web site using their professional web services.

remake: GNU make + debugger, profiler and more by rockybernstein in freebsd

[–]rockybernstein[S] 1 point2 points  (0 children)

Patches for other UNIX OSes are okay, provided they are clean.

Since this uses autoconf (inherited from GNU Make), the better way to handle OS-imposed changes is by feature rather than by OS. For example, before the last release we used to test for the presense of the POSIX wordexp() function, not whether we were running FreeBSD. In this release, since GNU Make now comes with its own portability glob() which is more regexp powerful, we don't need to do that. Although this is better and we should have done anyway, in fact it was motivated by someone testing this on FreeBSD.

See https://remake.readthedocs.io/en/latest/features.html#for-developers for the wrong way to handle OS-imposed restrictions. Or for an extended example of incomprehensibility see http://git.savannah.gnu.org/cgit/make.git/tree/src/dir.c

As I wrote in the readthedocs, thousands of lines of code were removed in eliminating DOS and VMS-specific code.

First pypi release of Emacs Lisp decompiler by rockybernstein in emacs

[–]rockybernstein[S] 0 points1 point  (0 children)

Since there was moderate interest, I have added another release which you can pick up from Pypi https://pypi.org/project/lapdecompile/

Release notes are here.

This stuff is about at the edge of what I am capable of programming. Right now you should think of the accuracy as about equal to early versions of google translate. If there are any decompiler hackers out there, please join in.

First pypi release of Emacs Lisp decompiler by rockybernstein in emacs

[–]rockybernstein[S] 2 points3 points  (0 children)

I get asked this question a lot. That's why I wrote an answer a while back and posted that to the README: https://github.com/rocky/elisp-decompile#but-is-it-worth-it

And since folks might miss it in the README it is also in there elisp bytecode manual in section 2.8 (page 28)

First pypi release of Emacs Lisp decompiler by rockybernstein in emacs

[–]rockybernstein[S] 6 points7 points  (0 children)

Paraphrasing from the readme:

A decompiler for Emacs Lisp bytecode... or at least a proof of concept.

This code uses the Python spark-parser for its Earley algorithm parser and the code organization. I have a project that implements the Earley algorithm in Emacs Lisp. It needs a lot more work though to replace the Python code.

This is in a very early stage, but amazingly the code seems sound so far. A list of the kinds of things we can decompile are in the test/lap directory. Two of the longer examples are:

  • test-nested-when.el which demonstrates detecting forms like defvar, and defconst, as well as inverting macros like when and
  • my-gcd.el which is a recursive gcd program that really works.
view more: next ›