Removing support for Emacs unexec from Glibc
lwn.net
lwn.net
https://sourceware.org/bugzilla/show_bug.cgi?id=6527
Basically for many years now glibc has been knowingly doing the wrong thing just to keep malloc_set_state/malloc_get_state working. Which as far as anyone knows, is used only by emacs. Keeping this interface alive for the sole benefit of an emacs optimization when it is blocking the fixes for fairly serious bugs is a pretty big bar to meet for justification.
In the end this is largely a non-issue as an Emacs developer noted that their configure script probes for the special glibc malloc API and if it doesn't exist then emacs will use its own malloc implementation. The conclusion is that once the glibc devs get their changes up, everyone can meet up again to make sure existing emacs binaries still run and that the API detection in the emacs configure script works right.
So props to Paul Eggert for being the only sane man in the room and pointing out that the drama was all for nothing.
1: http://git.savannah.gnu.org/cgit/emacs.git/tree/src/unexsol....
2: https://docs.oracle.com/cd/E19455-01/806-0627/6j9vhfmop/inde...
There's no reason emacs needs to use the glibc's malloc implementation though, especially given emacs has it's own built-in (and probably neglected) malloc for other platforms.
"According to Paul Eggert, making unexec more portable has been on the to-do list for a while, "and this will light more of a fire under it". Concerns that Emacs might not build using a new Glibc API (which has not even been written yet) that came up earlier in the thread are not a problem, he said. "Emacs should still build and run even if the glibc API is changed, as Emacs ./configure probes for the glibc malloc-related API and falls back on its own malloc implementation otherwise.""
And there's the dreaded autoconf doing it's job.
This is just an example of technical debt handled well actually. The loan came due and now the emacs devs are doing the right thing and paying it off.
So, it turns out that unexec has not made it into the standards, and now is causing more problems than it’s solving, and the glibc maintainers are going to remove it.
This would not be an interesting story, except that it involves Emacs, Stallman, and the appropriate use of mailing lists. Still, the conclusion of the article is that the process works and everything’s just going fine.
I'm not advocating that this should be the norm, simply noting that there are cases where you need to be.
Otherwise you can't achieve smooth 60 or 30fps, without tearing, popping (audio, streaming, models), etc.
This method will presumably be used to carry the old malloc implementation around for older emacs binaries that rely on it (whereas newly linked binaries will see the new API and ABI).
If I remember correctly TeX uses the same trick. I don't know if it depends on unexec() though.
I really like editing in VIM but I moved to Emacs using Spacemacs to try and get the best of both worlds (org mode for scientific research seems a really cool approach).
Still I see Emacs as being quite more bug prone than VIM and VIM than NeoVIm.
Perhaps this is what's needed for someone to start a complete refactor of Emacs and bring it (I mean the code not the editor) to the modern age.
If you encounter bugs you should submit bug reports.
FWIW, I think that's entirely the wrong direction to go. Emacs should be ported to Common Lisp, with an elisp compatibility layer.
Scheme's a neat didactic tool, but anyone who wants to produce production-level software in Lisp should write it in Common Lisp. Heck, even Schemers recognise that, which is why the RnRS controversy exists.
Modern Schemes are fully as production-ready as CL. The view of Scheme as merely an educational tool is outdated, and usually based on limited experience with ancient, bare-bones Scheme implementations such as MIT Scheme.
Modern Schemes like Chicken have fairly extensive collections of practical libraries and features that barebones Scheme implementations lack. To add to that, Scheme is far more elegant than CL, and doesn't contain all of the ancient crud of CL, so is far more pleasant and easy to program in.
I'm not thrilled that Guile (rather than Chicken) is the Scheme of choice for Emacs, but it's a far better choice than CL.
That said, even CL would have been an enormous improvement over elisp. So the sooner the migration from elisp starts (whether to Scheme or CL), the better.
Modern Scheme still doesn't have hash tables (c.f. R7RS[1]; of course Lisp has them). That, right there, prevents it from being a production-ready language. I could omit the rest of this post and I'd be right.
Scheme does have continuable exceptions, but it's still a far cry from Lisp's conditions and restarts.
Scheme's type system is extraordinarily lightweight. There's no way for the user to define new types, nor even a lightweight way to query for an object's type (unless I've missed something, one must use the various type predicates one-by-one).
Relatedly, there's no way to declare variable or function types; no way to pass that information on to an optimising compiler. There are no compiler macros. Indeed, compilation in general is woefully underspecified.
There's no object-orientation: no classes, no generic functions, none of that. One has to roll one's own if one wishes to.
Although it does have cond-expand, unlike Lisp Scheme doesn't specify READ-SUPRESS which works in conjunction with #+ and #- to skip variant syntax supported by other implementations.
This raises the issue of the reader in general. Scheme's reader is not extensible; it lacks reader macros. It provides no access to the current readtable, or any way to manipulate it.
Scheme doesn't even have a general (i.e., unhygienic) macro facility! Its hygienic macros are sufficient for many use cases, but not all — e.g. anaphoric macros.
Its iteration construct (yes, singular!) is severely limited. There's no general facility like LOOP.
It lacks settable places (this is the capability in Lisp of writing `(setf (getf 'foo bar) 'baz)`).
Scheme does finally have dynamic variables, although they are more unwieldy to use than Lisp's specials.
I do like its well-specified numeric tower.
> Modern Schemes like Chicken have fairly extensive collections of practical libraries and features that barebones Scheme implementations lack.
But they require that for even very basic functionality (like hashtables!). One of Common Lisp's downfalls is having to use implementation-specific functionality; Scheme is worse.
A related problem with Lisp is that Gray streams aren't part of the standard. But Scheme's ports are even less-specified than Lisp's streams.
> To add to that, Scheme is far more elegant than CL, and doesn't contain all of the ancient crud of CL, so is far more pleasant and easy to program in.
You know what I find pleasant? A language which anticipates my needs and my problems, and has already solved them. Time and time again I find that Common Lisp has done exactly that.
I'll certainly admit that there are parts of Lisp I'd change (the default upcasing is hideous; some of the function names are ugly; the varying argument order between similar functions is beyond lame). But I'd never want to use a language which treats NIL as true!
Scheme's not really a toy: it's clay which can be used by thinkers as well as students to play with problems. But it's not suitable for writing portable, high-performance, industrial-strength, real-world problems. Common Lisp is.
kinda shitty
Links to LWN subscriber content appear on HN from time to time - not too often, and I would guess they do more good than harm to them.
> Where is it appropriate to post a subscriber link?
> Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared.
Also, if I'm screwing with my .emacs it's nice to have instant feedback beyond eval'ing any changes I make as I go.
That said, though, if I was accustomed to one of my primary tools taking a half-second to start, I think I'd miss it pretty bad if it went away.
Just the fact that people on both sides (glibc and emacs) are treating this so seriously seems to indicate a rather admirable dedication to keeping the quality of the software as high as possible.
A 5 second startup time for a text editor is extremely annoying when all you want to do is, say, type some small commit message.
For remote files there's tramp.
But, I do agree that any sysadmin should know enough basic vi[m] to get around, because vi is almost always available on any unix system. Emacs (or nano) might not be installed.