That is probably referring to System Management Mode (privilege level/ring -2) and Intel Management Engine (privilege level/ring -3). Two very terrible things.
4,347 karma · joined June 6, 2009
There are two public lists where specific proposals are collected:
https://cliki.net/Proposed%20ANSI%20Changes
https://cliki.net/Proposed%20Extensions%20to%20ANSI
And a page for more speculative proposals:
https://cliki.net/Lisp%20-%20Next%20Generation
Please feel free to add your ideas there.
> ways to alloc without gc
Do you mean something between DYNAMIC-EXTENT and https://gitlab.common-lisp.net/vsedach/Thinlisp-1.1 ?
At this point it is about consensus among implementations. phoe got package local nicknames into all implementations, and that is a very major revision to the standard. So in practice it is happening.
You can build GNU Emacs for X with Lucid instead. Motif too, but that is getting removed soon.
This never happened. You are confusing functional with the 2000s "X is a good enough Lisp" controversy, which had nothing to do with functional programming.
> “Functional” means “functions are first-class citizens in the language”
No, the word function has a clearly defined meaning. I don't know where you get your strange ideas from - you need to look at original sources. The word "functional" did not become part of the jargon until the 1990s. Even into the 1980s most people referred to this paradigm as "applicative" (as in procedure application), which is a lot more appropriate. The big problem with the Lisp community is that early on, when everyone used the words "procedures" or "subroutines," they decided to start calling them "functions," even though they could have side effects. This is probably the reason why people started trying to appropriate "functional" as an adjective from the ML and Haskell communities into their own languages. A lot of people assume that if you can write a for loop as a map, it makes it "functional." What you end up with is a bunch of inappropriate cargo-culting by people who do not understand the basics of functional programming.
¹ https://www.rfc-editor.org/rfc/rfc4287.txt
² https://gist.github.com/tjdett/4617547
³ http://xmlsoft.org/xmllint.html
⁴ https://github.com/rrthomas/recode/
⁶ https://oneofus.la/have-emacs-will-hack/files/current/Makefi...
The poster unfortunately did not. "Needling" aka "dry needling" aka "Western acupuncture" is re-branded acupuncture. Like acupuncture, it is quackery and an unsafe scam. Even the acupuncturists agree: "Dry needling is acupuncture and physical therapists are practicing it without a license and putting patients at risk"
https://www.healthline.com/health-news/acupuncturists-declar...
Mark Crislip had a good podcast that covers acupuncture and other medical fraud:
http://quackcast.com/spodcasts/page6.html
If you feel like you need help for "years of sitting at the computer" I recommend Jolie Bookspan's books. The best, most effective information I have come across so far.
On any PC keyboard, just swap parentheses with square or curly brackets. That is way more useful even if you never program in Lisp. One of several things the Lisp Machine keyboard layouts did well.
http://www.faqs.org/faqs/internet-services/access-via-email/
https://archive.org/details/internetbyemail00shir
https://web.archive.org/web/20001109163400/http://www.expita...
Why don't you try to actually build a reproduction Symbolics keyboard (I did), and see how much time and money it is going to cost you.
Please don't part out keyboards from old computer systems so you can use them with your Macbook. Give them to people who are actually working on collecting and preserving the old systems.
Or you could just be wasting cycles on profiling overhead and recompiling things for no reason.
> A JIT could compile several optimized versions for different argument types and choose the best fit one at compile time.
That's... a compile time optimization.
> A JIT could do inlining code based on statistical information and select at runtime optimized functions with additional inlining.
Tracing is very close to self-modifying code. What happens when you redefine a function? What happens when you redefine a function at a breakpoint? There is a lot of runtime overhead (profiling, bookkeeping to back out of inlining) and it is very hard to debug. And it is never going to be as fast as static inlining and dispatching (sealing) at compile time.
> A JIT could remove runtime dispatch for often used code parts and provide versions for that.
That's what dispatch caching already does.
I think you and other people in this thread bought into the marketing hype for 10 year old tracing JavaScript implementations and now think that "JIT" is some kind of magic runtime optimization. The optimizations are all orthogonal to JIT (in fact GNU Lightning does none of the ones you alluded to). Adding tracing to any of the existing Common Lisp implementations would be a huge waste of time when there are easier and more effective things that can be done (like say converting an existing implementation to use SSA).
> Then basically most COMPILE implementations in Common Lisp implementations would be a JIT.
Yes.
> Is there anything that ECL's COMPILE function makes it special?
ECL uses GCC. If you read the original question, this was asking about libgccjit.
SBCL's original "interpreter" is %simple-eval, which just calls the compiler. SB!EVAL was added sometime around 2008, but as you point out it is not used unless you set evaluator-mode to something other than :compile. The default code path goes through %simple-eval and the compiler. I have been using SBCL since before SB!EVAL was added, and I have never used the interpreter.
> ECL has three ways to run code: an interpreter, a byte code engine and a Lisp-to-C compiler
The confusing thing about ECL is that someone decided to call their bytecode VM an "interpreter." ECL has no interpreter - eval_nontrivial_form just calls the bytecode compiler.
All that is irrelevant to the fact that ECL uses GCC as a JIT.
> In theory one could use a JIT to compile the byte codes to native code at runtime.
Which would be completely pointless because GCC (or clang or MVCC, but the original question was about libgccjit) is already there and does better optimization.
> Some experiments of improving CLOS speed at runtime (similar to what Julia does) might be considered to be a moral equivalent of a JIT
Like half of the PCL is devoted to various kinds of caching that are in fact adaptive optimization. It is not a big step from that to inline caching. But again, why would you do that when you don't need to?
https://github.com/guicho271828/inlined-generic-function https://github.com/marcoheisig/fast-generic-functions
There is a reason Mozilla went from tracing (TraceMonkey) to inline caching (JägerMonkey) to type specialization (IonMonkey). JavaScript JITs have moved closer to Lisp compilers, not vice-versa.
I have covered other misconceptions that you have listed elsewhere in this thread.
You have machine code generation at run-time, you can then make arbitrary decisions for when to do the code generation. Explain how this is not a JavaScript JIT compiler when you run it in ECL: https://github.com/akapav/js/blob/master/js.lisp#L72
> That's why I said SBCL's LOAD and REPL (which decides between interpreting and compiling) is arguably JIT.
SBCL does not really have an interpreter (it started out without any kind of interpreter at all), it only has a compiler. No wonder you misunderstood my point about SBCL.
> that doesn't meet the bar for being a JIT anymore than a C program that distributes plugins as source and compiles them to load the .so is.
Let's try to rephrase that a little bit: "that doesn't meet the bar for being a JIT anymore than a [web browser] program that distributes [loads] plugins [JavaScript] as source and compiles them to load the .so [machine code] is."
Again, look at the code and explain how that is not JIT: https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop...
This is probably what confuses a lot of people into thinking that program distribution has anything to do with JIT. JavaScript is the only programming language for which the main method of program distribution is source-code-only, and why all the trade-offs of adaptive optimization seem necessary, to the point that now people are making its necessity into a virtue. Likewise for Java stealing credit for popularizing portable bytecode as the main method of program distribution - although Gosling coined the term JIT years before Java had a JIT compiler.
> If (for instance) I write a script in c and run it with tcc -run
And what happens when you use libtcc?
> Compilation should occur concurrently with execution
Execution of what? You do not need an interpreter or a bytecode VM to have a JIT compiler.
> usually accompanied by some heuristic for deciding what to compile first (e.g. tracing)
That is adaptive optimization, and is orthogonal to compiling (you can have adaptive optimizations in an interpreter or a bytecode VM). Tracing (which is not a heuristic btw) is a variation of profile-guided optimization, which is orthogonal to JIT.
> Even if it is not, however, ECL does not JIT c, but produces it statically.
I posted this elsewhere in this thread:
https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop...
Can you explain why you think that is not a JIT.
By that definition using the REPL or loading source files in SBCL qualifies as a JIT.
> https://en.wikipedia.org/wiki/Dynamic_compilation discusses Dynamic Compilation vs Incremental Compilation.
That article just seems to perpetuate the confusion: "Runtime environments using dynamic compilation typically have programs run slowly for the first few minutes, and then after that, most of the compilation and recompilation is done and it runs quickly."
This could be talking about adaptive optimization, or dynamic recompilation, or even dispatch caching. You can do adaptive optimization in an interpreter or bytecode VM. Dispatch caching does not involve anything that looks like a compiler at all unless you are doing inlining.
Most importantly, none of those things is what GNU Lightning or libgccjit does. All they do is generate machine code, at run-time. That is what a JIT is.
And JavaScript programs almost never change after a website is loaded. That has nothing to do with whether the programs are compiled.
> you only have to recompile a few files. The elisp isn't being JITed, it's being compiled into shared objects which are cached aggressively
You do not need any files to compile Elisp code, and you do not have to save the bytecode anywhere.
> Completely different kettle of fish.
What exactly is your definition of JIT? I think you might be confusing "JIT" with dynamic recompilation.
> ECL compiles to c.
Ok, and what do you think happens to C?
https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop...
What is the difference?
Well the most high-profile project using libgccjit right now is Elisp (feature/native-comp GNU Emacs branch, which by all indications will eventually make it into the official release), and using GCC as a JIT compiler is how Embeddable Common Lisp has always worked.
Today libgccjit seems like a much better alternative for this kind of application than GNU Lightning.
You can get an APL keycap set for your existing Unicomp keyboard, or do a custom order for any of their models. They will even print you custom keycap sets: https://www.pckeyboard.com/page/category/Buttons
The trackball Unicomp is IMO the best keyboard being manufactured (right now they are out of stock until Q3 2021): https://www.pckeyboard.com/page/category/ClassicTrackball
Buckling spring is just a superior (although less durable) key switch technology than the Honeywell switches used in Symbolics keyboards (and most other keyboard switch mechanisms as well). One thing that the Symbolics keyboards did right is having both the APL and Greek legends on keycaps.
But none of this matters if you do not have the right software. GNU Emacs greek and TeX input-methods, and the C-x 8 iso-transl keymap (which you can extend) makes writing mathematical symbols really easy.
OpenBSD routing domains make this really easy.