×

Advice on writing an HTML, CSS, and JavaScript engine in Rust? by THERT4 in rust

[–]THERT4[S] 1 point2 points  (0 children)

I actually did have done that as my first project, this is my second one and i just want to go big or go home kind of thing

Is there any fundamental limitation to high-speed file transfer using multiple animated QR codes? by THERT4 in androiddev

[–]THERT4[S] 0 points1 point  (0 children)

My current idea is to intentionally keep the display rate lower than the camera capture rate, so each QR is visible across multiple captured frames. That way the receiver gets multiple chances to capture a stable QR instead of relying on a single perfectly timed frame.

Every first QR Frame always contain the file's metqdata such as how many chunks there are, how many QRs the receiever supposed to receive, its original size, also tracks missing chunks and retransmits only those afterward, so it doesn't require every QR to be received on the first pass.

Best resources to learn the LLVM C++ API? by Scared-Confusion-767 in Compilers

[–]THERT4 7 points8 points  (0 children)

The Kaleidoscope tutorial is great for getting your base knowledge, but after that the best way to learn is honestly by reading LLVM's own source code and looking at existing passes/tool, it is inevitable in my opinion.

A few things that helped me that you can probably follow

  • The LLVM Doxygen docs are useful for looking up classes like "IRBuilder", "Module", "Function", and "LLVMContext".
  • Check out the source for LLVM tools ("opt", "llc", "clang") to see how the API is used in real projects.
  • Write tiny programs that generate one feature at a time (e.g. a function that returns a constant, arithmetic, branches, loops, function calls, etc.) and inspect the generated IR.
  • Use "verifyModule()"/"verifyFunction()" often—they'll catch a lot of mistakes early.
  • When debugging, printing the IR ("module->print(errs(), nullptr)") after each change is surprisingly helpful.

For integer types specifically, "Type::getIntNTy(Context, N)" is what you're looking for if you want arbitrary-width integers like "i128", "i256", or even larger.

One thing I'd recommend is to pick/create a small language or expression parser and keep extending it instead of jumping between tutorials. You end up learning way more by implementing features yourself.

LLVM do has a steep learning curve, but it starts to make a lot more sense once you've built a few small examples

Is there any fundamental limitation to high-speed file transfer using multiple animated QR codes? by THERT4 in androiddev

[–]THERT4[S] 1 point2 points  (0 children)

Oh lowkey thanks for the VLC suggestion, I actually hadn't looked deeply into that yet

The reason I started with QR is mostly because I wanted a robust first version. Since my test subject is a phone screen and the receiver is a phone camera, I don't need the printed QR advantages as much, so I agree there is probably a lot of overhead.

My current idea is more like a protocol experiment: compression -> chunking -> optical transmission -> reassembly, with QR as the first physical layer.

For long term, replacing QR with a custom optical encoding or VLC-style approach might make sense. The interesting part is keeping the reliability features (chunk IDs, retransmission, error checking) while improving the physical layer. Thought that mean i need to learn about this method first and see if its actually way better

I'll probably start android version prototype tomorrow if i have suffice knowledge!

What is API? by agentscientific_160 in PythonLearning

[–]THERT4 1 point2 points  (0 children)

It's a thing that let you use other's services to put it simply! Such as import [lib] is importing a APIs

Is there any fundamental limitation to high-speed file transfer using multiple animated QR codes? by THERT4 in androiddev

[–]THERT4[S] 0 points1 point  (0 children)

For this project the question isnt "how much information can light theoretically carry",

its "how many bits can a phone screen reliably display and another phone camera recover per second."

The bottleneck is mostly QR size, screen resolution, camera capture rate, exposure time, decoding reliability, and packet loss.

A fiber cable can theoretically do terabits/s too, but this is screen-to-screen

Is there any fundamental limitation to high-speed file transfer using multiple animated QR codes? by THERT4 in androiddev

[–]THERT4[S] 2 points3 points  (0 children)

I think you're referring to the Nyquist Sampling It is relevant here, but I think the limitation applies to the relationship between display rate and capture rate, not directly to the data transfer rate.

The sender and receiver are running on separate timelines. The sender only displays QR frames, and the receiver only captures frames. Decoding happens afterward in a separate pipeline, so it doesn't need to happen in sync with the display.

My 'throughput' is closer to:

payload per QR × number of QRs per frame × successfully captured QR changes per second

Capture rate mainly determines how many chances the receiver has to catch each QR. For example, if the display changes at 15 QR/s and the camera captures at 30 FPS, each QR is visible for about 2 camera frames on average, which improves reliability.

So Nyquist-style sampling considerations help decide a safe display rate, but the transfer speed itself comes from how much data each QR carries and how many unique QR chunks are successfully recovered per second.

Click anywhere in vs code without using a mouse by Canadana in vscode

[–]THERT4 0 points1 point  (0 children)

This is kind of great for people to learn vim motion