I don’t know if any bugs contribute to this but this in the intel case but it has been very common historically for subnormal performance to be lower on many processors, and things like the Alpha required you to handle them in software if the COU fired a trap.
I don’t mean this to sound harsh, but this post comes across a little like you already assume you deserve to win such a prize and it’s just those fickle judges standing in your way.
I looked at your sample chapter and immediately bounced off a police officer in Maine calling in a murder as a 187 (California penal code).
I’m okay with that. I’ve been a huge fan of Ballard and Priest for years, and got into Nina Allan’s work more recently and this book was a brilliant but heartbreaking read.
Having maintained internal forks, and having needed to pull in and rebase upstream changes I do read a lot of commits. Projects that take care with their commits are much easier to work with.
This is also true when creating with security patches and other things that need to be backported to multiple releases.
I think the thing that stops me from running more processes inside emacs is that a large diff parse from magit or similar can block everything, and so I end up keeping a separate terminal around anyway.
Huh is that true? Does running a command in a terminal buffer block all of EMacs? That's extremely surprising, the main use of these kinds of integrated terminals for me is to compile and run which means long running commands. Is this use case fundamentally not supported due to EMacs's architecture?
I'm confused, what emacs do you have in mind? For me, emacs is a lisp machine, hackable live, M-. all the way down, that kind of things, that's the whole point (again, subjective opinion, and I'm interested in yours).
What language do you have in mind?
If you're worried about performance, Common Lisp is a compiled language. It's about the best performing dynamic language there is, and not too far behind Zig, Rust and the likes.
Fair enough. FWIW, I know several lifelong Emacs users who never wrote or read a line of lisp.
But for those who do choose Emacs for its supreme hackability, I got a hunch that their profile is very similar to those who choose lisp for its unmatched meta-programming ; they're also very similar to the OG lispers who actually rejected M-expression, the normal, more mathy syntax with less parens, and embraced S-Expressions, precisely because (= code CST AST) is what gives lisp its simplicity and powers in the first place. It's not that we are stuck with parens anyway, the initial vision of lisp, with far fewer parens, has been implemented in Rhombus for example; and we don't even have to change language, 1 or 2 days of writing macros is all it takes to get your favorite lisp to understand many expressions without brackets, and even remove many brackets from existing code; for example, I'm using something close to
https://www.reddit.com/r/lisp/comments/18b6hf/comment/c8d8wt...
to write your example as (Too $ many $ god $ damn $ brackets), which btw, doesn't use any less brackets in an Algol language: Too(many(god(damn(brackets()))))
(but yeah, in many circumstances, we do use more).
This is why I have a hard time imagining an "emacs spawn" not written in lisp. Before even considering that many Emacs concepts are most easily transcribed in a lisp, who would be interested in writing and using it in the first place? (genuine question)
It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic.
Okay. I gave it another read and I think we agree in general, but maybe disagree on how much memory model strangeness is acceptable, and how wide the gap between, “The behaviour can be understood by a developer,” and, “it should be possible to write a sequential JS program that creates an indistinguishable heap,” is likely to be.
The lower level bits round the object model etc. all look very solid.
Although structs may not be necessary to make JS concurrent their limitations might help in reducing where memory model strangeness could creep in.
Although the work being done to enable multiple threads in JS is impressive I think it will be hard to make robust in many casss without locks, or fairly strict limits what operations can be performed on objects shared between threads.
The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of accessor properties. Enabling it in multithreaded implementations is tricky without opening up deadlocks when modifying property collections, and even with that could likely be broken by some suitably evil code. Ive worked on more than one implementation that offered some degree of multithreaded access and it’s generally only safe when limited to simple properties.
Async / await avoids those issues because none of the places where user code can be executed allow async code, so there is no opportunity for the world to be changed under your feet during something like property access.
It is a book that plenty think it has Java in it, no it has Smalltalk and C++ and was published before Java came to be as you point out.
The decade was about the book publishing date, rather all the C++ frameworks that came to the market since CFront 2.0 was made available in 1989, and yes it was exactly 7 years, if being pedantic.
Have a look at https://en.wikipedia.org/wiki/Subnormal_number for some context.
reply