Also cool. I opted for GPS because I had a spare Pi and you can get dubious but perfectly adequate GPS modules for $3 off of Aliexpress, it's kind of an impulse buy. I also picked up a MAX7219-based LED display for another $2, so it's also going to be an over-engineered desk clock for $15 + some 3D printed parts (the other $10 is for a Pi Zero W I had left over from a different project).
I was a user of a very early version of Zortech C++ (one of the first native C++ compilers (late '80s); no running through cfront) and ran into a very subtle bug in the math routines: sometimes when doing math with 8 bit values the answers would be corrupted. Took a while for me to track down the bug but I eventually found it in the assembly output. Turns out that the math was actually being done with 16 bit registers and the high byte (AH) was not being cleared and this would sometimes set a carry (I think, my memory is fuzzy on the details).
Walter was quick with a fix. Sometimes it is the compiler, but usually it's not.
I was using a cross compiler for the 68000 around the same time period, and we ran into many compiler bugs. They were always quick to fix them once we could produce a small example program to demonstrate the problem, but it was a bit frustrating. Thankfully it has been many years since I ran into a true compiler bug.
A real shame that Forth wasn't included in the tested languages. Chuck Moore has been an advocate for more energy efficient computation for a while now.
> The tests come from the benchmark game. If you want to see Forth, implement the tests in Forth:
But perhaps archive your code elsewhere. Github? Lots of language communities participated in past versions of the game. Like gforth and bigforth on shootout.alioth.debian.org circa 2008. Now it seems little remains but a few archive.org snapshots without source. Though perhaps all of that code was archived somewhere else that I'm not quickly finding?
edit Now it seems little remains but for you to lift-that-shade and tell-everyone how amazing it is that someone took the trouble to archive those obscure old programs.
@igouy points out that while the old shootout site is gone, its language files are still available[1]. There are about 70 benchmarks, in about 70 languages. I remember them as interesting multilingual browsing.
Unlike the old shootout, adding languages directly to benchmarksgame.alioth.debian.org is not an option. "Because I know it will take more time than I choose. Been there; done that."[2] :) Instead, the code is available[3], and communities are invited to document their own benchmarksgame comparisons[2], such as Nim''s[4]. The OP used different code[5].
A brief glance at the current benchmarks, suggests there is some overlap with the old ones. Or at least an overlap of names - the requirements may have changed. So it might be possible to get started fairly easily? Perhaps even to do several languages...
If a summary of the test data is/were machine readable in the individual language repos, perhaps one could create an automated aggregation? A distributed/federated version of the old shootout. One with lower maintenance requirements. bendmarksgame-results.json?
The data would be crufty, of limited comparability. But combining easily browsable links to colorized source code, with "just for a rough feel" speed relative to C, might be sufficient for the use case of raising language awareness - "What is this C-speed-like language I've never heard of? Oh, that looks pretty! I think I'll explore this language's web page..."
Or alternately, use the language files on github to create a new, broader benchmarksgame. That is, distribute the work of benchmark revisions and makefile compiler options, but keep the testing centralized. I've no idea of the relative costs of those tasks, or of others. But a continuous integration shootout sounds intriguing.
I'd rather say it begun to be a focus with its latest processors because it's the only hope they have to sell Forth processors. I remember he mentioned introducing a lot of complexity in its previous design to achieve very high speed for exactly the same reason (the only hope we have to sell a Forth processor is to make it super-fast), which was a bit in contradiction with the reason why he moved from software to hardware - simplifying globally the hardware/software combo.
I love the idea of ref counting, but I'm unsure about the handling of memory cycles. In a plain ref counting implementation, these will not be cleaned up, resulting in a memory leak.
I didn't find anything on cycles in the linked page, maybe the problem is not relevant in most real-world clojure code?
I don't know about "pure" Clojure (as this is), but in "pure" Erlang (which has similar semantics), you simply can't make a reference cycle. Functional languages in general don't really allow them.
It goes into amazing detail on the history of the spacecraft and the events that made it possible. For example: the story of an intern figuring out the '3 body' problem and, from there, the concept of 'gravity assist' gave me goosebumps
I just installed GuixSD 0.12 last week on a Dell 13 7000. Went mostly smoothly (had to use Grub BIOS instead of UEFI, that's been fixed in 0.13) after I replaced the Intel WiFi card with an Atheros based one.
My needs are simple: emacs, Clojure (with Icedtea), Icecat and StumpWM. Plus all the guile goodness!
Just realized I'm living in a system with four Lisps front and center (guile, Common Lisp, elisp, and Clojure)
# cp [existing-thing] [new-thing]
# mv [existing-thing] [new-thing]
# ln -s [existing-thing] [new-thing]