atgreen

7 ms·

1.
by atgreen 6d ago
I worked on this years ago. Gcj did support loading and interpreting bytecode alongside the AOT-compiled code. libffi's closures were originally implemented to support calling interpreted methods from AOT-compiled code, because a cla
2.
by atgreen 2mo ago
VISA open sourced an expense-to-run harness they developed under glasswing, and I used that as the basis of a skill that I've found to be pretty effective with Claude Code: https://github.com/atgreen/secscan-skill
3.
by atgreen 3mo ago
TBH, the complexity of this step grew over time, and the overhead snuck up on us. The prep step does useful work (eg. determine stack space requirements). It's just that we don't have to do it again. Something I should have ment
4.
by atgreen 3mo ago
Yes, that's part of what was done here. So, create a plan, and then for some subset of plans, create AOT-compiled templates. The analogies are: a) original implementation is like interpreting via walking a syntax tree b) building&#x
5.
Performance improvements in libffi(atgreen.github.io)
48 points by atgreen 3mo ago|9 comments
6.
by atgreen 4mo ago
Here's another option.. I created an optimizing eBPF compiler in Common Lisp for a lisp-ish DSL. It's nice because you can compile and load your eBPF code all in-process in lisp (even from your REPL) without any external tooling
7.
by atgreen 4mo ago
No, they are different. I just bundled them together for convenience in this POC. The only real thing in common is that they both use eBPF.
8.
by atgreen 4mo ago
Have a look at https://github.com/atgreen/rhel-block-copyfail
9.
by atgreen 4mo ago
Don't disagree, but there are eBPF mitigations that work as alternatives to unloading kernel modules.
10.
by atgreen 5mo ago
I created something similar earlier today: https://github.com/atgreen/block-copyfail
11.
by atgreen 5mo ago
This is not my experience. I've been experimenting with something very similar to vera. However my language transpiles into multiple languages (Java, Typescript, Common Lisp, Rust, C++, Python, C# and Swift). The transpiler is writt
12.
by atgreen 6mo ago
I enjoyed reading this. Thank you for sharing. I learned Common Lisp years ago while working in the AI lab at the University of Toronto, and parts of this article resonated strongly with me. However, if you abandon the idea of REPL-driven
13.
by atgreen 6mo ago
Thank you!
14.
by atgreen 6mo ago
The whistler code you inline with your common lisp is an s-expression based DSL. So you can use common lisp macros, but those macros are generating something that will look familiar to CL devs but is restricted based on the eBPF archictect
15.
Show HN: Whistler – a Lisp that compiles to eBPF(github.com)
3 points by atgreen 6mo ago|0 comments
16.
by atgreen 6mo ago
They are much better these days.
17.
by atgreen 6mo ago
256k is just's just a placeholder for now. The default will get reduced as we get more experience with the draft implementation. The proposal isn't complete yet.
18.
by atgreen 6mo ago
I haven't really looked into it, but I'm hopeful it can be made to work.
19.
by atgreen 6mo ago
No. I have yet to propose the patches formally. The SBCL maintainers are reviewing the high-level proposal (on my blog) first. You can try the implementation, however. There's a pointer to the repo/branch on my blog. I need
20.
by atgreen 6mo ago
This very website that you are using right now, Hacker News, runs on sbcl.
21.
by atgreen 6mo ago
I'm the author. https://atgreen.github.io/repl-yell/posts/sbcl-fibers/
22.
by atgreen 7mo ago
I set out to create a better text repl experience for Common Lisp couple of months ago, but was inspired by the pharo interface and built something much larger: https://atgreen.github.io/icl/ I use it all the time.
23.
by atgreen 7mo ago
It's like Dr Ian Malcolm says.. "Your developers were so preoccupied with whether or not they could, they didn't stop to think if they should" - Jurrasic Park (almost)
24.
by atgreen 7mo ago
Here's something I wrote about this work: https://atgreen.github.io/repl-yell/posts/cl-kawa/
25.
by atgreen 7mo ago
If you are interested in this, you might also be interested to learn that I also got clojure running on SBCL via OpenLDK. See https://github.com/atgreen/cl-clojure . Regarding LLM-usage, the bulk of OpenLDK was written
26.
Bending the CLOS Mop for Java-Style Single Dispatch(atgreen.github.io)
8 points by atgreen 7mo ago|2 comments
27.
by atgreen 7mo ago
I managed to get a clojure REPL running on Common Lisp (SBCL) via OpenLDK, my Java JIT compiler and runtime on Common Lisp. This blog post gives an overview on how I manipulated CLOS's method dispatch to improve performance for single
28.
by atgreen 9mo ago
Hey pjmlp -- your comment inspired me to do some additional work. From the text console, you can run the ,brower command and it will open up your browser with a REPL on the same lisp image. The browser-based REPL has many interesting feat
29.
by atgreen 9mo ago
No, but now that I've looked, I'm hacking down another rabbit hole...
30.
by atgreen 9mo ago
Thanks, vinderal. Since you wrote this the other day, I've improved the auto-completion so it is more context-aware. For instance, it will auto-complete using your filesystem when it is reasonably sure that you are trying to reference

More ›