gpderetta
gpderetta on Hacker News
you might have an untrusted sandboxed workload that is not supposed to communicate externally handling secrets, and a different sandboxed workload able to communicate with the external world, not handling secrets.
I use claude-code.el plus monet.el, but I have since had claude extend it in many ways, including exposing executeCode through monet /ide support.
I'm using claude-code.el. What am I missing? (Aside from integration with other models of course).
I have used gptel a while ago which was great for completion-like workflow, but abandoned when I moved to more agentic stuff.
that's like asking linux to drop posix :D
90% of everything is crap; also Sturgeon might have been an hopeless optimist.
I've been using emacs everyday for the last 25ish years. Although I do read elisp and occasionally write some, I'm far from fluent. You do not need to know lisp to use emacs (although it is funny you didn't pickup some just by osmosis).
It is is unreal how I can ask claude, from within emacs, to implement an extension for me on the fly, inject it into the running process, have it observe the results, and quickly iterate to a working solution.
Claude, the ultimate REPL.
"Any famous quote is eventually attributed to Albert Einstein"
-- Albert Einstein
similarly for plastic bags.
to synthesize an entirely new thing you have to start form the big bang. Everything else is derivative.
... as long as they still care about what we want and what we like.
Interesting. I have read that collection but I completely forgot about this story.
Blindsight also has augmented humans whose reasoning is beyond baseline human understanding and there are dedicated people that are there to bridge the communication.
>Architecture problem. Do your programs normally saturate a 40 gig network pipe?
yes
> 90% of performance is I/O bound, whether it be the disk, the network or whatever
funny you say that, because to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must. That reintroduces all the "fun" shared memory ordering issues, except trickier (you are talking with a PCI device, not just another core) and buggier.
Re disk, I'm sure someone will revive optane at some point, and we will be back with memory model issues in our disk I/O path.
The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
For better or worse, our current hardware architectures present a shared memory interface for intercore communication. So if you want a non-toy CSP programing language you have to implement with a programming language that support shared memory concurrency (for the OS at the very least).
And of course any sufficiently complicated message passing program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of shared memory and coherency[1].
[1] Yes, the reverse is also true.
Because then they wouldn't have contracts in C++.
they are literally meant to be better asserts, that can be shown on a function declaration.
Nothing to do with pthreads. As long as you want to use shared memory to communicate with concurrent processes, you need a memory model with compiler support. Even if you exclusively use mutexes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678At least some GCC devs claimed that the standard does not impose any requirements on these macros if a compiler does not claim strict ISO/IEC 6055 (aka IEE 754) conformance (which is still optional, and gcc and clang do not claim it).
Other devs disagree.
> So I run most development on a VM. But part of my test-suite and smoke-tests rely on runninng it directly on the host OS (which is not ideal). I'd love to hear suggestions to avoid this.
VFIO/GPU passthrough maybe?
No need to leave though, we have unlocked gene tailoring and we should we able to research glandular acclimatation now, right?
> how do you compete? What is the status?
energy and resources. Money was always a proxy for them anyway.
> I'm not against optimizations. I'm against optimizations that perform things unexpected by the programmer.
DWIM is not a spec.
well, yes, because those languages can statically or dynamically guarantee that behaviour that would be UB in C or C++ doesn't happen.
Usually it means GC, bound checking and no pointer forging.
s/as-is/as-if/
You are otherwise correct of course.
turns out it was just valgrind not handling a valid optimization correclty.