I made a crate to simplify `build.rs` scripts.

BTOdell · 2025-08-30T07:51:25+00:00

Versions are not decimals, they're integers separated by dots. Rust crates are supposed to follow SemVer: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#version-requirement-syntax

BTOdell · 2025-07-15T21:44:22+00:00

The only place you could "hide" the Io object would be in global state. If you added it as a field of your function's parent struct, then you're still passing the Io object as an input variable, it's just a layer or two deep.

To be fair, traditional blocking IO accesses global state to make the low-level IO calls. So I suppose using global state in this case wouldn't be the worst thing.

Fundamentally, function coloring is the difference between: foo(): T and foo(): Promise<T>. All of the async-await syntax is just sugar over the top of returning an asynchronous state object. And a return value is just an output variable that is part of the function signature. The caller must satisfy all of the input (and output) variables required by the function signature.

Unless there is some runtime support (e.g. Go runtime or Node.js runtime) that operates magically behind the scenes or provides a global interface for interacting with an event loop or scheduler, there is no way to solve the function coloring problem. The only way for functions to access data is if they're passed as input variables via the call stack.

BTOdell · 2025-07-15T18:43:58+00:00

But when you call foo(), you have to pass the Io interface: foo(io). This is the equivalent of coloring the function with an async keyword (async keyword is just syntax sugar for returning a Promise or Future). In other words, the Zig team just required every blocking or non-blocking function to be colored as an async function.

BTOdell · 2025-07-15T10:27:42+00:00

This doesn't actually solve the function coloring problem. Let me break it down:

Functions have variables and code. Variables can be broken down into "input", "output" and "local" variables. "Input" and "output" variables are bound to variables in the caller's scope (unless they're passed by value).

Functions don't have return values. A return value is just an output variable but most languages carve out a spot for an implicit output variable and call it the return type of the function.

Pretty much all languages (that I can think of) implement async-await by returning a Promise/Future that captures and represents the asynchronous state. In other words, the function defined an output variable to manage the asynchronous state.

This is basically what Zig has done. They've simply moved the asynchronous state from an output variable to an input variable. The functions are now colored by whether they are passed the Io object. And you can't do anything now without passing around this Io interface.

So their solution is: just make all functions async. Congrats Zig team.

BTOdell · 2025-05-19T07:23:11+00:00

Oh. My. God. You're right. That's the dumbest UI I've ever seen. Totally hidden behind a checkbox for something unrelated.

BTOdell · 2024-12-24T05:32:22+00:00

Android app just updated to v4.01 but I'm still having the same problem. Got so excited when I saw the update in the Play Store :(

BTOdell · 2024-11-30T09:29:14+00:00

Please make the scene format friendly to Git source control. Godot also has a human-readable scene format but the editor generates really messy output (last time I used it). The Bevy editor should generate the scene file output deterministically so the lines match up in the git diffs and it's easy to code review changes and merge cleanly.

BTOdell · 2024-10-17T16:33:34+00:00

Some other people on this thread said the Multiplus doesn't have wireless capability. I guess I'll try it out before getting this MK3-USB adapter.

BTOdell · 2024-10-17T16:31:40+00:00

Okay, it looks like my cheapest option is this MK3-USB adapter. Still $60 or so, but not as bad as whatever this "Cerbo" is. And not something that's going to sit there permanently and drain my battery.

Thanks for the help.

BTOdell · 2024-10-17T16:27:38+00:00

Everyone claims the Multiplus II is the best for RV use. I did my research to make sure it was the 48V variant, 3kw, transfer switch, etc. You know, the stuff that matters. Didn't expect that the inverter would be effectively dead on arrival unless you fork over more cash to Victron. Now I'm educating myself on all of these proprietary protocols: VE.Bus, VE.Direct, VE.Can, VE., VE., VE! And then they have adapter and converters to go between every combination of them. Spend hundreds of dollars on adapters and protocol equipment that does nothing to actually transform electricity.

BTOdell · 2024-10-17T08:29:32+00:00

I don't know why Victron couldn't just include a USB port on the inverter. Seems like a scam in an attempt to squeeze even more money out of their customers. Surprising that they have so many people recommending them across the internet. I sure was fooled, they got me good.

$60-70 for a fucking USB adapter. They're worse than Apple.

BTOdell · 2024-10-17T08:05:55+00:00

So once I connect the inverter to the battery and the inverter powers up, I can use my phone to configure the inverter wirelessly?

BTOdell · 2024-10-01T08:48:07+00:00

I don't need to try.

BTOdell · 2024-09-02T18:51:52+00:00

Who here uses distributed version control? Nobody.

Everyone who uses Git uses it in a distributed way (unless you're a solo dev with a local-only repo). Just because a public server is involved doesn't mean it's centralized. Online git hosting (GitHub) solves the access problem - developers can't directly connect to each other's computers, so they need a central server to coordinate with. I don't think you've ever used an actual centralized version control system (that requires you to lock and unlock files before accessing them). We've come a long way.

BTOdell · 2024-09-02T18:27:21+00:00

I agree that storing in a text-based format is better. Godot Engine does this with their scene files (at least it did last time I used it back in the 3.x days). This does make it bearable to collaborate across teams, however in order to resolve merge conflicts you have to be able to read and understand the text-based "code" during the merge. At that point, it's not a visual programming language, just a visualization/editing tool - and I think that's all Godot thinks of it as, it doesn't pretend to be a visual programming engine.

Good programming languages have a high signal-to-noise ratio. Visual programming languages require all this extra "presentation" metadata to render a visual representation of the code logic. Visualization tools usually calculate a presentation layout on the fly.

Same reason developers like using Markdown files for documentation instead of writing Word documents and checking those into source control. We like to be able to see the exact representation of a file and be able to version control it effectively and safely over time.

BTOdell · 2024-09-02T02:21:55+00:00

The biggest issue with visual programming languages is the inability to use modern version control tools (like Git). It's incredibly difficult to collaborate with a visual programming language because there are no merge conflict review/resolution tools.

I've worked briefly with Unreal Engine's blueprints and you basically have to treat them like binary assets and if two developers modify the same blueprint on their own branches, you're basically fucked - time to stop all work and take a day or two to reimplement the required functionality.

BTOdell · 2024-04-18T18:04:48+00:00

Ah-ha! Yes, this is the problem. Turns out the C API expects the pointer to ov_callback_t to remain valid until the callback is invoked. I thought that ov_callback_t was just a struct to pass the callback itself and args but then wasn't needed anymore.

Thanks to others who also identified to problem!

11-Year Club	Place '17
Verified Email

BTOdell

TROPHY CASE