fweimer

I think with CLOS, you can go back to using single verbs for function names. However, this has a performance cost. Encoding the receiver type in the function names makes the call much easier to optimize.

What remains is field access. Curiously, first-edition K&R C actually required similar type-encoding in field names because field names were global:

https://usenet.trashworldnews.com/?thread=288637

Same for ML, which is roughly of the same age, except that it took much longer for ML-derived languages to lift this restriction.

On the other hand, every time I wrote down examples that I think should look really bad in prefix notation, like this one:

    p3.x := (p1.x + p2.x) / 2;

It is actually not so terrible with a sufficiently streamlined prefix syntax:

    (setf x p3 (/ (+ (. x p1) (. x p2)) 2))

But maybe there should be a mechanism that the reader transforms p1.x to (. x p1), in the same way that it transforms 's into (quote s). Then we get this:

    (setf x p3 (/ (+ p1.x p2.x 2)))

Or if there is a concept of a place:

    (set p3.x (/ (+ p1.x p2.x 2)))

But that probably needs static typing for an efficient implementation (or set needs to deconstruct its first argument during compilation).

Where in Italy would you put reactors?

https://maps.eu-risk.eucentre.it/map/european-seismic-risk-i...

Sardinia?

When emulated on today's hardware. But the hardware actually available at the time was pretty unreliable by modern standards, I think.

Exfiltrating many binaries gives you the right to their source code, or at least triggers attribution requirements for licensing compliance.

But perhaps Meta did the smart thing and put the source code into the VM, too. That would be a very reliable indicator that they expected exfiltration, and this is in fact working as intended.

I'm pretty sure people said this about the early COBOL compilers, too. They were buggy, the API had terrible uptime, and was slow to respond.

Overall, this whole approach to programming seems to align really well with the original premise of COBOL. I wonder when people will start putting

# Identification Division

into their Markdown files.

There's probably still value (if you want to call it that) in it as a proxy, both to bypass IP address rate limits and to add necessarily credentials.

There's also another aspect Quite a few API providers provide automatic renewal for MCP server registrations, but not for personal access tokens. This may be less relevant when models just drive the user's browser.

Likely a reference to ELIZA: https://en.wikipedia.org/wiki/ELIZA

It's just a compiler barrier (signal fence), not a memory barrier that concerns the CPU. The CPU is free to reorder loads and stores.

Was the public key directory even operational in 2012? What about revocation checking?

I think processing that information is mandatory now, but probably was optional/largely unimplemented in 2012. But maybe I'm off by five years or so?

I expect that UD2 stops instruction fetching (beyond the current block) and conversion to µops. A software interrupt or supervisor call should probably do neither because most of the time, these instructions eventually return and continue executing the next instruction.

The leakage wouldn't be from training, but from other uses of Personal Data.

As far as I understand it, users can opt out from the training aspect, but they cannot stop their conversations (“User Content”) being used “[t]o improve and develop our Services and conduct research, for example to develop new features”.

If it actually exists, the protection would like go into the other direction: prevent playback of arbitrary MIDI files on the digital piano, instead of protecting the MIDI data against playback on other devices.

Public email and IRC archives/logs usually work just fine without Javascript.

ihtabs preserve iteration order and have performance competitive with swiss tables (while not requiring as high a load factor): https://github.com/vnmakarov/ihtab

As far as I understand it, the other efforts have not reported most of their findings to upstream developers, focusing on critical findings only.

This is understandable because upstream interactions at scale are difficult.

It's still beneficial on some x86-64 implementations to rewrite indirect jumps (as used in PLT stubs) to direct jumps when feasible. For example, AMD says this about the Zen 4 architecture:

> Only a limited number of indirect targets that cross a 64MB aligned boundary relative to the branch address can be tracked in the indirect target predictor. Software should limit the number of indirect branch targets that cross such a boundary.

And one way doing this is to replace the indirect branch with a direct branch, which supports a 32-bit signed displacement.

Why do you think these volunteers supported the attack? I don't think there's a published statement to the effect. Even the U.S. government does not claim that (at least not in its written communication).

The perpetrators very likely used Apple and Google services, too, and no one views that as some sort of endorsement by the companies.

> It doesn’t fully explain why Congress has allowed the expansion of executive power for nearly a century, resulting in more and more major issues being pushed to the Supreme Court.

It's not just about executive power. In recent times, Congress failed to adjust the written law when societal consensus shifted, and the discrepancy was resolved the courts, and ultimately the Supreme Court. I don't think Congress would pass something like the Civil Rights Act under the current circumstances. This isn't good for a democracy because the political debate that is part of the regular legislative process is lost.

The TUI version of Claude Code just isn't very good, though. The default keybindings do not work in the majority of terminals (because they generate the same byte sequences for key sequences assigned to different commands). Editing large prompts is rather painful because there doesn't seem to be in-prompt search commands. There is no source code browser, so source code references cannot checked by the users without a separate tool. Diffs cannot be copied directly because they are indented by spaces (even though some tools strip indentation from patches, it's still ugly). Switching between conversations is somewhat discouraged by the interface, which makes it harder to keep the context clean.

I think it's possible to have a better TUI, with something that isn't modeled after a shell prompt. Apparently, recent updates move in that direction. The GUI version of Claude Code seems to be coming to Linux, too.

These builtins of course exist, it's how compilers keep track of the behavior of these functions.

For GCC, there is -minline-all-stringops:

https://gcc.gnu.org/onlinedocs/gcc-16.2.0/gcc/x86-Options.ht...

It does what it says, but the results may not be what you expect.

Cases are infrequent, but not extremely unlikely. There's even a term for it, airport malaria:

https://www.eurosurveillance.org/content/10.2807/1560-7917.E...

Are you sure this is actually makes a difference in your build?

Mine doesn't have the SB-INTERPRETER package, so I doubt binding the variable has an effect.

Compiling to bytecode is still compilation. An interpreter would operate directly on the S-expressions. Obviously, this makes some constructs (such as TAGBODY) very inefficient.

But 2 isn't a list, and the argument to unqoute-splicing must be a list:

> If an (unquote-splicing <expression> ...) form appears inside a <qq template>, then the <expression>s must evaluate to lists; the opening and closing parentheses of the lists are then “stripped away” and the elements of the lists are inserted in place of the unquote-splicing form.

Isn't at least one of them undefined? `(1 ,@2)

It's always surprising to me how many things Scheme leaves undefined. Other examples are evaluation order (in some rather surprising places) or the value of: (make-bytevector 4)

I wonder what the intent is behind releasing the weights under a CC-BY-NC license. Is it about restricting any commercial use of the weights, including for inference?

Not in typical builds of SBCL: all code is compiled before evaluation.

I think we'd need something different to make that a reality today. It's likely that decentralized compute eventually wins out here as well. It usually does. But without architectural changes, it will take a couple of years before the current single-conversation flow is truly usable on consumer-grade hardware.

Centralized inference can easily increase batch size, leading to huge efficiency gains in the usual scenario where most users have just one or very few session. Using local resources efficiently requires some way to increase the batch size. I'm not sure if we are there yet.

This is the relevant law: https://www.buzer.de/8_TDDDG.htm (It used to be §90 TKG.)

It's specifically about bug-like devices which transmit the recording. A typical consumer camera does not provide simultaneous uploading, I think. A device that is just recording for storage is not regulated this way.

The law has been applied to baby monitors disguised as toys, which makes some sense to me. Smart watches and phones where the microphone can be controlled remotely, with that capability being marketed specifically for monitoring purposes, have also been targeted.