Teaser: CL-Torch!

3

u/Steven1799 18d ago

Nice work Scott. Will any of the C++ wrapping work help with integration of other C++ libraries (other than Torch) ?

2

u/ScottBurson 18d ago

I think it will help a lot, though the only way to be sure is to try it.

I don't know what the deal is with Pavel, but he doesn't seem to have any time to work on Claw at the moment. It needs better documentation, at the very least. I have something else I want to work on for the next few months, but once I get back to CL-Torch, maybe I can also do more work on Claw. I don't really want to own it, but it does have potential, and if Pavel can't do anything else on it, maybe I will feel compelled to try. (Actually, I would probably start by making some improvements to LibClang, which Claw uses to access the Clang AST.)

6

u/borodust 18d ago

I'm busy on Pozzo and libgodot at the moment - gamedev is my main focus. claw PRs require proper attention, since the machinery is intricate and people regularly have different idea from mine how it shall work. I'll get to it eventually.

1

u/licjon 17d ago

It seems like working on CL-Torch could be a full-time job, let alone claw and other things. I think if someone were to take up the torch (pun recognized if not intended), then they might look into how PyTorch does things using torchgen. Perhaps working on a DSL that defines the shape of things. I don't know... just naively spitballing here.

1

u/ScottBurson 17d ago

I didn't look at the torchgen code, but I did write a similar thing for CL, that reads native_functions.yaml and generates API functions from it. It's not complete, but it works in many cases.

1

u/borodust 17d ago

btw, if you decide to patch libclang to get to the their C++ AST for some features, have a look into c2ffi first: * It is a wrapper over Clang's C++ AST * It's better focused project than maintaining patched general-purpose libclang

I'm talking from experience, since I've got rid of my custom libclang for libresect very recently. Building LLVM/Clang is an exercise in patience. It is resource hungry. Static libclang cross-platform build is a largely forgotten prehistoric well kept secret craft.

And finally, as the project maintainer, my guarantee is that libresect will never use custom libclang ever again.

1

u/ScottBurson 17d ago

I didn't even know you had patched LibClang.

Anyway, if I were to modify it, my intention would be to get the changes into the LLVM tree. I agree — maintaining a locally patched version doesn't sound like a good idea. Of course, I can't guarantee my changes would be accepted, but I think the odds are good, as other FFI-wrapper projects would also benefit.

1

u/ScottBurson 17d ago

I actually tried C2FFI first, but at that point I really didn't know what I was doing, so when I found your Claw-Torch, I thought that looked like an easier path. In retrospect, I probably gave up on C2FFI too easily, but I would surely have had to make improvements to it as well, for the exception handling if nothing else. So I'm not sure that in the end there would have been a big difference in the effort required to use C2FFI vs. Claw.

2

u/borodust 17d ago

The effort itself would probably have been substantial. What I've meant is purely preferring patching c2ffi vs patching libclang.

The relevant historical note: `claw` eons ago (now `claw-legacy` project) was born as a fork of cl-autowrap with my PRs merged. Since then there's nothing left of the original cl-autowrap, of course.

1

u/ScottBurson 15d ago

I've fixed a couple of things and gotten it to build on macOS. If you tried it and found it too broken, try again. You will need the latest version of my Claw fork.

3

u/borodust 18d ago edited 18d ago

Just avoid using claw for C++ projects unless you can sustain chronic pain of working with C++ which you would think defeats the purpose of using an autowrapper and it slightly does.

Every single project I wrapped (a lot, and as the author mentioned, that includes libtorch - this was a wrapping test, not a proper wrapper to use) brings some obscure C++ feature into the mix - it's never ending spring of cruft. And on top of the existing cruft, C++ dumps even more craziness with each standard release. It's exhausting to keep up with.

The experience of the author wrapping C++ lib resembles mine. 1) You get it mostly wrapped 2) You find some obscure C++ corner case 3) Patch resect/claw 4) Rinse, repeat

It's likely you will keep more of your sanity, if you ask LLM to generate the wrapper, to be honest. Or just write the C-shim yourself for the functions you need - it's not as scary as you might first think, especially since you likely to dip your toes into that pit with claw anyway. Or maybe use clasp.

3

u/ScottBurson 17d ago

There was definitely a point at which I thought I had wasted my time on Claw, that I should have just used an LLM. But then I realized that LibTorch was going to throw C++ exceptions, which I was going to have to catch and signal as Lisp errors. At that point, it felt like all I had learned about Claw internals paid off, as I was able to modify it to do that. I'm not sure I could have gotten an LLM to generate that code correctly.

Anyway, at least for the parts of LibTorch I care about, Claw seems to have pretty well converged — I haven't had to do as much to it lately. And LibTorch is a pretty stringent test case. My guess is that Claw, with my changes, will probably work a lot more easily on other libraries. Of course, I don't know this for sure.

As for my sanity, that went out the window a long time ago 🤣

3

u/borodust 17d ago

claw in its current state converged on every library I wrapped to use. I thought Filament (Google's engine) covered C++ features well. Then I thought crufty PhysX enterprise grade software would certainly cover the most features. After I wrapped Skia I thought there's just no way more insanity possible - this is the decades old project with all levels of legacy C++ used innone of the most used application - browser. I gave up chasing the C++ wrapping graal of covering enough features at wxwidgets wrapper - what possibly can go wrong when the ptoject is seemingly C++98? Then you came with LibTorch. The journey continues...

1

u/Soft_Reality6818 14d ago

This is what I always think about Jank (Clojure targeting C++), I cannot even imagine how much work and effort goes into it.

2

u/kchanqvq 18d ago

bravo!

3

u/Soft_Reality6818 14d ago

Super cool! Always wanted to make CL torch bindings and was fiddling with Claw a year and half ago too.

I just recently released a Libtorch wrapper for Clojure using the JavaCPP preset. https://github.com/antlobach/clorch

1

u/ScottBurson 14d ago

Oh, very nice! You're much farther along than I am.

Since I'm out of time to work on CL-Torch for the moment, I wouldn't mind having some help on it, if you felt like pitching in. You clearly know more about LibTorch than I do.

1

u/licjon 18d ago edited 18d ago

I saw an earlier github version of this that helped me choose claw. I used the quicklisp version though with C2FFI as the backend, and the library I'm wrapping (llama.cpp) is extern "C" for its entire public API. Where I did have to build something is a post-processing step that renames claw's anonymous/numeric-ID struct and union types to something readable, fixes up their exports, strips a fabricated result-struct parameter that comes from claw's SRET convention, and dedupes a couple of case-collision parameter names.

After reading about your issues, I am hoping soon there will be a library that combines all these fixes and whatever else still lurks out there in the murky corners of C++.

2

u/ScottBurson 18d ago

You might want to give the current Claw a try — the Quicklisp one is very old. You could try my fork, though I don't recall fixing anything C-related.

You are about to leave Redlib