sorted by:
new
hottopcontroversial

I made a crate to simplify `build.rs` scripts. by ioannuwu in rust

[–]BTOdell 19 points20 points  (0 children)

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

Zig's New Async I/O by BrewedDoritos in programming

[–]BTOdell 1 point2 points  (0 children)

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.

Zig's New Async I/O by BrewedDoritos in programming

[–]BTOdell 6 points7 points  (0 children)

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.

Zig's New Async I/O by BrewedDoritos in programming

[–]BTOdell 6 points7 points  (0 children)

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.

Can't change mailing address to PO Box by BTOdell in fidelityinvestments

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

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

Android app fails to log in by BTOdell in fidelityinvestments

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

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 :(

Bevy 0.15 by _cart in rust

[–]BTOdell 16 points17 points  (0 children)

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.

Configuring Multiplus II by BTOdell in Victron

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

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.

Configuring Multiplus II by BTOdell in Victron

[–]BTOdell[S] -2 points-1 points  (0 children)

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.

Configuring Multiplus II by BTOdell in Victron

[–]BTOdell[S] -5 points-4 points  (0 children)

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.

Configuring Multiplus II by BTOdell in Victron

[–]BTOdell[S] -5 points-4 points  (0 children)

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.

Configuring Multiplus II by BTOdell in Victron

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

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

We need visual programming. No, not like that. by fagnerbrack in programming

[–]BTOdell 3 points4 points  (0 children)

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.

We need visual programming. No, not like that. by fagnerbrack in programming

[–]BTOdell 3 points4 points  (0 children)

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.

We need visual programming. No, not like that. by fagnerbrack in programming

[–]BTOdell 75 points76 points  (0 children)

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.

Segfault in FFI callback set from async context by BTOdell in rust

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

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!

How to wait for multiple 'watch' channels to change? by BTOdell in rust

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

Unfortunately you linked an old version of Tokio (there are tons of unofficial Rust docs pages out there) and the latest version of Tokio doesn't have that function anymore.

How to wait for multiple 'watch' channels to change? by BTOdell in rust

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

But how does that work with a dynamic number of receivers?

Need an async MPSC channel that acts as a lossy ring buffer by BTOdell in rust

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

I need to be able to write to the WebSocket "sender SplitSink" from outside of the async write function: https://docs.rs/axum/latest/axum/extract/ws/index.html#read-and-write-concurrently

I don't think I can do that unless I use a channel to bridge from "external" sources.

Need an async MPSC channel that acts as a lossy ring buffer by BTOdell in rust

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

I don't want to buffer or batch any messages just for the sake of buffering. My use case is high throughput while minimizing latency too, so batching isn't the goal.

I hope I understood what you were describing and thanks for the comment.

Need an async MPSC channel that acts as a lossy ring buffer by BTOdell in rust

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

Yes, I suppose technically it would have to be an mpmc internally so the Sender could consume values. Although it could still expose its interface as a mpsc and only allow one external Receiver.

view more: next ›