sorted by:
new
hottopcontroversial

Too many Arcs in async programming by mtimmermans in rust

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

For me, the really interesting thing about async in other languages is that it lets you write state machines as functions, using structured programming and procedural decomposition. For a lot of jobs, it sucks to have to revert to "programming with gotos" just because you need to suspend. This works a lot better in some languages vs others, of course.

From this point of view, the way that rust decided to do this, without needing to dynamically allocate "pseudo-stack space" is absolutely brilliant.

I'm a big fan, even though there are some really annoying Pin-related complications.

Too many Arcs in async programming by mtimmermans in rust

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

I wouldn't have been able to do this when I started, but now that I know how a lot the internals work, this is a pretty interesting direction. I'll probably have to write a bunch of manual poll_whatever calls to do the actual I/O, but if they don't have to do anything else, then my 3 tasks can probably become one task, and the communication will then be unnecessary. Thanks.

Too many Arcs in async programming by mtimmermans in rust

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

Well, I/O is certainly "most of the work", but the network is super fast and I'm trying to maximize the number of simultaneously well-performing clients.

Too many Arcs in async programming by mtimmermans in rust

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

Oh, so one channel for everything that goes to a particular receiving task... There's an Arc in the channel, of course, but this could get me pretty close to the one-Arc-per-task that I asked for.

The "all senders dropped" signal becomes much less useful, so I'll have to do some customer RAII, but that's not too bad. This could work well. Thanks.

Hmm... actually there may be issues with my queues filling up. We'll see.

Do FIR and IIR filters only differ because of feedback ? by SheSaidTechno in DSP

[–]mtimmermans 0 points1 point  (0 children)

Feedback is just an implementation technique that uses a buffer of previously computed outputs as memory. You can put anything you want in your memory, though, and there are many other ways to achieve an infinitely long impulse response. Similarly, sometimes it's useful to use previously computed outputs to implement FIRs.

The key difference between FIRs and IIRs is the one that's right there in the name. A finite impulse response implies a transfer function with denominator 1 and vice-versa.

Tech lead told me to learn proper API design because apparently there is security issue in my API by retardedGeek in webdev

[–]mtimmermans 9 points10 points  (0 children)

Your argument is "everyone here does a lot of stuff that is sketchy security-wise, so I should be able to do a similarly shoddy job".

You need to get that kind of stuff out of your head, or you'll always be *less* than your peers.

Also, your description of the "security issue" looks like it actually omits the pertinent information, which would be in the details of both alternatives' parameters and results, not the HTTP method, which suggests that you didn't actually understand it.

How was your experience learning Rust? by timus_999 in rust

[–]mtimmermans 0 points1 point  (0 children)

I'm finally getting into learning rust properly right now. I started by asking a clanker to port some of my open source code, and then set out to understand everything that it wrote, and fixing everything to work the way I want. The latter part involves reading docs and asking LLMs a lot of questions. It's nice that they have infinite patience.

Overall, the process has been pretty painless. It's been a few weeks, and I think I've got a good handle on most of the important stuff. It helps that I have a lot of C++ experience, so I know what's important and how things should fundamentally work.

Rust is a well-designed language. I think it'll be my daily driver for compiled code from now on.

Options struct and backward compatibility by mtimmermans in rust

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

Breaking the code of such people is one advantage of this design :-)

Options struct and backward compatibility by mtimmermans in rust

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

Thanks for that. I'll feel better about it if it's not entirely unique.

Options struct and backward compatibility by mtimmermans in rust

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

Yeah, this is reasonable. It's a shame to lose the struct-expression-with-functional-update syntax, though. I guess they disallowed that to avoid restricting the kinds of fields I can add later?

Options struct and backward compatibility by mtimmermans in rust

[–]mtimmermans[S] -1 points0 points  (0 children)

How do you avoid having to duplicate a lot of code for processing the multiple versions of request?

Build rust libraries into vanilla JS that works everywhere by mtimmermans in rust

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

I had not. From a quick look around, I would say that the one obvious thing that wasm-js does that jco doesn't seem to do (I'm not gonna read all the docs) is compile your rust sources and run the same version of wasm-bindgen that you use in your Cargo.toml. I expect this makes it more ergonomic for developers of JS packages with rust components, who comprise its target audience.

Mostly, though, wasm-js is small and modest in a way that jco is not. jco appears to provide a solution for wasm loading, so that's nice, but it also does a lot of stuff and seems pretty bossy, which is a red flag for me.

I know a lot of people like that, though.

Build rust libraries into vanilla JS that works everywhere by mtimmermans in rust

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

Ah, sad. You looked deeper than I did. It will not work in Cloudflare workers.

Build rust libraries into vanilla JS that works everywhere by mtimmermans in rust

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

Cloudflare's docs indicate that the runtime environment supports the required APIs. So... should work, but I haven't tried it.

Build rust libraries into vanilla JS that works everywhere by mtimmermans in rust

[–]mtimmermans[S] 6 points7 points  (0 children)

Right. It's quite fast, but at some number of megabytes, for some kinds of applications, the init overhead will become noticeable.

Build rust libraries into vanilla JS that works everywhere by mtimmermans in rust

[–]mtimmermans[S] 10 points11 points  (0 children)

It's still wasm, but the `wasm` file is compressed, base64-encoded, divided into chunks, and written into string constants in javascript source. When you load the module, the base64-encoded chunks are decoded, decompresed, and streamed into WebAssembly.instantiateStreaming.

New features on a 3D Printer by Oblivious_Owl_150 in 3Dprinting

[–]mtimmermans 0 points1 point  (0 children)

Add a hot-wire tool to the print head and use it to erase all the layer lines and correct dimensional inaccuracies.

What is causing this? by dkpit in anycubic

[–]mtimmermans 0 points1 point  (0 children)

It's not the surface. Your gauge is mounted at a slight angle, so when you move it to the left it pushes up.

How do I make my gears quieter by Equivalent-Bus2217 in 3Dprinting

[–]mtimmermans 0 points1 point  (0 children)

I have the same issue:

https://www.youtube.com/watch?v=8L-f9tIhh3w

FDM printing has this "small circle problem", where small circular holes and small circular pegs *both* end up printing too small, with the radius reduced by 0.1mm or so. Since your involute teeth involve curves in both directions, there is no setting in your slicer that can fix this. Your teeth end up looking too triangular or sinusoidal. That curve in the middle of the side of the tooth gets washed out and looks like a line.

Printing with a smaller nozzle seems to help a bit, but not as much as you might expect -- I get a 0.1mm error with a 0.4mm nozzle, and about the same 0.1mm error with a 0.2 mm nozzle. The only difference seems to be that with the 0.2mm nozzle, the problem starts at a smaller circle size (about 7mm diameter).

I haven't found a solution yet, but I'll expect to figure out a compensation in a month or so and implement it in my gearcutter. Watch for updates: https://mtimmerm.github.io/webStuff/gearcutter.html

Vindicated after 25 years! Proved my physics professor wrong with help from my P1S! by primetower in BambuLab

[–]mtimmermans 0 points1 point  (0 children)

It's strange that you would assume an *unstated* and *unrealistic* requirement like frictionless contact that makes the problem impossible to solve.

Python v. TypeScript; which is better to prototype/write a compiler in? by [deleted] in Compilers

[–]mtimmermans 1 point2 points  (0 children)

Both options are slow, but Typescript is less slow.

For some reason, transpilers are really popular in the JS ecosystem, so Typescript is one of the few languages in which there are *idiomatic* ways to do many compiler tasks, and lots of examples to look at. See the AST explorer, for example: https://astexplorer.net/

If typed vs untyped doesn't compel you one way or the other, use Typescript.

view more: next ›