天空вℓσи∂ [Unemployed edition] @skyblond@social.cleverlibre.org

Several days ago I was suffering from jextract and the new project Panama things. Since it's new, there is not much useful documentation and can't get it work in a frustrating day. I was thinking maybe I'm not good at java stuff and should quit and become a Uber eat delivery guy or something. (I blame HR for those negative thoughts)

After several days of suffering and trying, I kind of know how it works and now I'm even writing win32 library in C++. I
m amazing

Can't imagine now I'm writing C++ and using windows api. I almost reject everything that cannot run on JVM.

Yesterday I thought I'm going to give up during configure the project or compile with MSVC. But appallingly, I get it working and go those far.

Life is full of surprise.

Never though I'm going to dive so deep in this Win32 rabbit hole.

I was originally thinking just wrote a simple wrapper of win32's tape API, but then I realized that the encryption is missing. With Win32's tape api, you can basically implement something like `/dev/st0` (simple read and write) amd `mt` command (rewind, seek, set compression, etc.). I was thinking just use LTOEnc for encryption control.

But that software can only read the encryption key from a file, which, to me, is a big security hole: I can do that in memory, why write to the disk temporarily?

So I start reading LTOEnc's code. I found Microsoft really don't want you to directly talk to SCSI. I read their documents, they never said about IOCTL_SCSI_PASS_THROUGH_DIRECT. They are recommending something like IOCTL_CDROM or something that is not so lower level.

Anyway, thanks to LTOEnc, and Oracle's helpdesk generously providing HPE product's tech ref manual, I now can implement the encryption control in my win32 lib. And soon I can do that in Java.

To play with Project Panama, llama.cpp seems too big to play.

So I'm wondering if I can get something small but interesting and meaningful. I think a tape drive controller is good. Read and write data using Java on Windows would just as easy as you work with the `/dev/st0` on linux.

I would say win32 api is actually not bad. Despite the fact that I don't know how to write C and CPP in a proper way, meaning not just submit the code to get an "AC", but an actual project, where you build something for people to actually use, either lib or executable.

Microsoft did a decent job with the documentation. The cmake side needs a bit of work. Yeah, I don't know how to properly config it. Thanks to Google, I still don't know how, but it's working.

Now JetBrains joined the AI hype, they start forcing users to try out their new stupid AI plugin. And the quality of their products has degraded too.

Just read the reviews: https://plugins.jetbrains.com/plugin/22282-ai-assistant/reviews

And the most annoying part is the dollar signs used in jextract.

To access a field in a structure, you have to use `llama_grammar_element.type$get(obj)`. And the dollar sign is a keyword in Kotlin. You can't use it in function names, unless you quote it with "`", like "llama_context_params.`seed$get`(contextParams)". And to make things worse, IDEA's auto completion is broken when involving this "`" sign.

I blame c++ for my degraded sleep quality.

While jextract makes the header translation much easier compared to JNA and JNR, but win32 api still does not work, and c++ support is not good.

The standard header from llama.cpp is working, but other functionalities like grammar parsing and sampling init is not included. They shipped as a common component in the example codes. While I want to compile the example code as a shared lib and invoke them from Java, the jextract has some problems with C++ headers and not happy with it.

For wintun, it uses win32 headers in its header files, which let jextract to process (almost) the whole win32 lib. The pointer size seems to be a problem. One said it should be 32 bits but another said 64 bits.

No wonder it's still in preview stage.

11am, but still sleepy

So hard to get up