I so miss bazaar's UI around merges/commits/branches. I feel like most of the push for squashing is a result of people trying to work around git's poor UI here.
The 650 main memory was a drum; but what IBM called Random Access Memory (and RAM) for this machine was a hard drive. As described in the Manual of Operation linked above. Here are a few quotes:
"Records in the IBM Random Access Memory Unit are stored on the faces of magnetic disks."
"The stored data in the Random Access Memory Unit are read and written by access arms."
"The IBM 355 RAM units provide extemely large storage capacity for data... Up to four RAM units can be attached to the 650 to provide 24,000,000 digits of RAM storage."
The main memory on the other hand:
"The 20,000 digits of storage, arranges as 2000 words of memory on the magnetic drum..."
Given that the actual vulnerability seems relatively niche along with it being such a popular library officially maintained by the Python foundation, the scariest line in the advisory is almost certainly:
The vulnerability was originally reported to the library maintainers on September 12, 2024, but no fix is available.
Just a clarifying note, Craig Reynolds is the original researcher for Boids, and he did have a Java applet implementation in the above page. But the original Boids simulation was from 1986, almost a decade prior to Java applets.
The original paper, published in 1987, is "Flocks, herds and schools: A distributed behavioral model"[1]. The implementation was done in Lisp on a Symbolics 3600 Lisp Machine.
Edit: One quite interesting paragraph from the paper regarding performance:
The boid software has not been optimized for speed. But
this report would be incomplete without a rough estimate of the actual performance of the system. With a flock of 80 boids, using the naive O(N²) algorithm (and so 6400 individual boid-to-boid comparisons), on a single Lisp Machine without any special hardware accelerators, the simulation ran for about 95 seconds per frame. A ten-second (300 frame) motion test took about eight hours of real time to produce.
Once again, amazing how far hardware has advanced.
I've had a lot of fun playing with BBC Microbot (https://bbcmic.ro/). If you add &experimental=true to the URL it will add a rocket ship button underneath the display. Clicking it sends the code off to beebjit and runs it for 10,000 seconds instantly, allowing you to do unreasonable things such as this: https://bbcmic.ro/?t=bC9Go (not mine)
I'm pretty positive that is showing the reverse, i.e. how much a given "location" is moving using gps coordinates. Not adjusting the gps coordinates to refer to a constant "location".
For those further interested in PEG vs LL(1) parsers. The first few sections of the Python PEP[1] where they switched from an LL(1) to PEG parser for CPython has a nice short introduction to both and their rationale for switching from LL(1) to PEG.
It still seems to me the PEG revolution hasn't arrived.
PEG has the possibility for composable grammars (why not smack some SQL code in the middle of Python?) but it needs a few more affordances, particularly an easy way to handle operator precedence.
I think current parser generators suck and that more programmers would be using them if anybody cared about making compiler technology easier to use but the problems are: (1) people who understand compiler technology can get things done with the awful tools we have now and (2) mostly those folks think it is performance über alles.
With the right tools the "Lisp is better because it is homoiconic" would finally die. With properly architected compilers adding
unless(X) { .. } -> if(!X) { ... }
to Java would just one grammar production, one transformation operator and maybe a new class in the AST (which might be codegenned), that and something to tell the compiler where to find these things. Less code than the POM file.
I gave up on Restructured text because it didn't support unparsing: I could picture all kinds of scenarios where I'd want to turn something else into RST or take RST and mix it up against other data and turn it back to RST; RST had the potential to work with or without a schema but it never got realized.
- Lisp is better because it manipulates the same data that the program code is represented in (car works on a data list, and it works on a code list as well).
- Lisp is better (at least, Common Lisp) because of image-and-REPL-driven development. Good luck finding exactly that level of flexibility in other REPL-ful languages.
- Lisp is better because of hot code reloading and restarts. Only Elixir/Erlang have a similar mechanism.
- Lisp is better because of structural editing (e.g., paredit). No more character-level editing.
I could go on but just wanted to point out that homoiconicity isn't the entire deal with Lisp.
>- Lisp is better because it manipulates the same data that the program code is represented in (car works on a data list, and it works on a code list as well).
Yeah, but I wanted to emphasize that homoiconicity isn't just some superficial "nice thing" to have, it literally is why we can have powerful macros in Lisp.
I went through quite a few stages of grief reading Graham's On Lisp starting with "this is so awesome" to nitpicking details like "he defined everything else but he didn't define nconc" to "if we was using Clojure he wouldn't be having these problems with nconc" to "funny I can write 80%+ of his examples in Python because most of the magic is in first-class functions and macros are a performance optimization except for that last bit about continuations... and Python has async anyway!"
Notably he doesn't do any interesting tree transformations on the code because tree structures in list are just a collection of twisty nameless tuples that all look alike. If you were trying to do nontrivial transformations on code you'd be better off with an AST in a language like Java or Typescript. In the end the dragon book is On Lisp squared or cubed, that is, games people play with macros are a pale shadow of what you can do if you actually understand how compilers work.
Yes. The best example of something that is popular and homoiconic is Bash. Bash keeps your functions in source code form, though comments may be lost, and they get reformatted. You can see the code when you type "set all", and can copy and paste the definitions back into Bash.
In Common Lisp, the homoiconic feature is the ed function which allows you to edit the source code of a function. Support for ed is implementation-defined!
It may be absent (e.g. in a Common Lisp that compiles everything to machine code). A Common Lisp that compiles all forms and doesn't support the ed function isn't homoiconic.
The current 4h12m hour record is for 100% (where you have to get every single achievement in the game, in the one run), any% (where you just need to launch a rocket) is under 2 hours (1h42 for the latest factorio v2.x, 1h18 for v1.x). There are a few other differences between the categories regarding map selection and blueprint use as well.
The last commit[0] is a fix for date parsing to bring it in line with the GNU semantics, which seems like a pretty good candidate.
Edit: Or not, see evil-olive's comment[1] for a more likely candidate.
0: https://github.com/uutils/coreutils/commit/0047c7e66ffb57971...
1: https://news.ycombinator.com/item?id=45687743