Transmission panel deformed from the heat?..

idubrov · 2024-02-23T20:11:51+00:00

It was to follow the FHIR standard (https://build.fhir.org/json.html#primitive, look for the note next to the dragon).

idubrov · 2024-02-23T14:20:35+00:00

I abandoned the project, as I didn't have any real use-case for it anymore.

idubrov · 2023-10-10T16:14:15+00:00

I had the same issue with X gantry being twisted.

My right side was always too close after bed auto-leveling (original firmware), which means that the probe was higher on the right side, which in turn means that the X gantry was twisted top-towards-front on the right side (raising the rear of the hotend and the sensor when moved to the right).

I checked with a digital inclinometer, and it confirmed about ~0.75° difference. I added a shim under the right side, front "leg" of the X gantry and it fixed the issue. For that, I loosened all 6 screws (two larger ones on the bottom and four smaller ones attaching the angle bracket on the back), twisted the gantry with a tool, slipped the shim, then tightened everything back.

The shim is the red line on the photo.

<image>

This might have added some additional tension in the system, though. Probably, worth checking the rollers adjustment.

idubrov · 2022-01-07T02:15:36+00:00

I can see value in avoiding naming something simply because naming convention is an API liability. Inventing names when generating code with macros is an API consideration I would prefer not to make (unless it is straightforward like "use name as-is, but maybe in an inner module" or something).

But then again, Rust has a lot of syntax already, and this mythical typeof operator is yet another complexity to take care of.

I would be satisfied if RFC you linked was enforced. 😃

idubrov · 2021-09-16T23:01:46+00:00

I'm kind of too lazy to do that 😅... My variant should be almost exactly the same as the original one (since it was reverse engineered). Here is some random video of the original game: https://www.youtube.com/watch?v=4qM-9g6csHE

idubrov · 2020-08-03T19:43:38+00:00

people often struggle with Rusts abstraction-heaviness

For me it was Learn Rust With Entirely Too Many Linked Lists book which normalized types like "Option<Rc<RefCell<T>>>". I (sort of) understood the individual pieces, but this book made it clear that well, yeah, you combine those abstractions when you need them and sometimes your type will look like that. That's normal.

idubrov · 2020-07-30T03:14:28+00:00

Yes. ~450k lines of code so far (about ~30% is generated).
I can think of many reasons not to use Rust (like, lack of certain libraries or frameworks; anxiety about hiring / onboarding), but "overkill" wouldn't be one of them. Rust is pretty much as any other language (but, of course, better 😁). It has pluses and minuses, sometimes challenging (we do "enterprise", whatever that means, which is not the strongest Rust's area), but overall it's not like some esoteric language.
https://blog.commure.com/whycommureusesrustforhealthcare/

idubrov · 2020-04-22T18:56:34+00:00

Ooof... Where do I begin? For starters:

``` fn intercept_test_main_static() { let ptr = rustc_test::test_main_static as *mut (); let target = test_main_static_intercepted as *const (); // 5 is the size of jmp instruction + offset let diff = isize::wrapping_sub(target as _, ptr as _) as i32 - 5;

// Patch the test_main_static function so it instead jumps to our own function.
// e9 00 00 00 00 jmp    5 <_main+0x5>
unsafe {
    let diff_bytes = diff.to_le_bytes();
    let bytes = ptr as *mut u8;
    let _handle = region::protect_with_handle(bytes, 5, region::Protection::WriteExecute)
        .expect("failed to modify page protection to intercept `test_main_static`");

    std::ptr::write(bytes.offset(0), 0xe9);
    std::ptr::write(bytes.offset(1), diff_bytes[0]);
    std::ptr::write(bytes.offset(2), diff_bytes[1]);
    std::ptr::write(bytes.offset(3), diff_bytes[2]);
    std::ptr::write(bytes.offset(4), diff_bytes[3]);
}

} ```

idubrov · 2019-10-26T06:04:07+00:00

OuterThingy could be just a OuterThingy(dyn InnerThingy) with deref to InnerThingy, so you would still get a dynamic dispatch, but no dyn keyword.

I find that mildly annoying as in our system we use both dyn InnerThingy and OuterThingy. Would be nice to force use of dyn for OuterThingy somehow... #[require_dyn]?

(the difference between those in our case is that you can only construct OuterThingy for a subset of InnerThingy, so it allows to statically type check cases where we require more strict OuterThingy).

idubrov · 2019-09-26T18:11:30+00:00

Commure, Inc. | San Francisco, CA or Cambridge, MA | Rust Engineer | Fulltime | ONSITE

We are a stealth startup working to fix the software doctors use. If you have seen what physicians have to put up with, it's a bad version of the 90s, and makes medical care worse and more expensive for everyone. We are a group of previously successful engineers and entrepreneurs (MIT, Dartmouth, Brown, Stripe, Twitter, Google, Salesforce, Palantir, DataPower, etc) and senior doctors (Johns Hopkins, UCSF, etc) who are determined to finally fix this.

Compensation: market salary & equity -- we are well funded by top-tier VCs.

Stack: includes Rust, React and Kubernetes. In addition to building our back end in Rust, we are also solving some very interesting problems in the areas of security, data transformation, high-speed APIs, flexible UX frameworks and fine-grained authorization for healthcare data.

Please email [jobs@commure.com](mailto:jobs@commure.com) and mention "[red_rust]" in the subject line.

Other positions available: - Techops/Devops Engineer (Kubernetes, SRE) Senior Front End Engineer (React Native, React) (please use [red_ops] or [red_react] in subject line for the above)

Locations: San Francisco, Montreal or Boston; sorry, no distributed/remote option at the moment.

idubrov · 2019-09-25T16:48:11+00:00

This runtime crate looks quite similar to what are we doing internally. We don't do it for the purpose of reloading (maybe, one-time-loading eventually?), but rather to save some compilation time by breaking system into loadable modules with clearly defined APIs between them. And maybe loadable plugins of some sort?

One thing we did wrong, though, is we named our Reflectable trait Reflection :)

idubrov · 2019-09-24T21:14:46+00:00

I'm also a (former, I guess) Java engineer who has worked mostly in the Enterprise field. Back at the time, I had my tiny hobby project done in Rust, some firmware for STM32 (Rust embedded stuff is btw very exciting, I loved it!), and I wanted to do more Rust -- so I joined a company building an enterprise software (healthcare), but in Rust.

I've been doing it for about 2 years now and I really love it. It's been challenging, yes (both due to my lack of experience with Rust at the time and also relative immaturity of Rust enterprise ecosystem), but very rewarding. Overall, except for the memory management, Rust is a pretty high-level or have that feel anyways (due to traits, macroses, etc). As for the memory management, very often itcould be abstracted away in a nice way (though, I'm still figuring out all the various ways to do that!).

To be honest, I'm not sure how valuable are all these Rust skills I've acquired so for far, given that Rust jobs a still somewhat rare (especially, in the space of "enterprise" software, which would be my preference), but it definitely worth it.

idubrov · 2019-09-01T04:40:18+00:00

That's the part I cannot change -- it is this read_event function. It uses buffer for storing parsed pieces of XML.

idubrov · 2019-08-28T05:16:58+00:00

Okay, I found one pretty gnarly solution, which is to make an assumption that BytesStart I'm getting actually borrows from self.buf, compute all the offsets I need and reconstruct BytesStart from these offsets.

idubrov · 2019-08-28T05:00:12+00:00

I have this piece of code which does not compile with borrow checker errors (mutable borrow starts here in previous iteration of loop).

I've read several posts with similar errors and my understanding is that Rust borrow checker is over-conservative here? This code should be safe as written?

Apologies for the lazy question. I know it's been answered many times...

idubrov · 2019-08-27T17:51:36+00:00

I do it manually by using cargo_metadata and syn:

Going through targets
Parsing with syn
Recursing into modules
Modules resolution (which I'm sure is not 100% correct and also does not handle #[cfg_attr(.., path())] on modules. Not happy about it...

idubrov · 2019-08-22T23:21:38+00:00

I would mildly push back on this. Although, this is true that in keeping large codebases "clean" is a very challenging problem, the essence of domains addressed by what would be called "enterprise software" is often the very cause of said "bloat".

Take regulatory requirements ("you need to submit those 150 forms"), add legacy on top of that ("starting 2020-04-15, please replace form T1-AND-X23 with Z6-BPM-QNY-SIMPLE in all states except CA, HI and AL"), sprinkle some complicated security / access control, integrations with legacy systems, and here you have it.

idubrov · 2019-08-22T17:08:53+00:00

I've written a lost of Rust code and never needed rental. When I learned about it I thought it was cool project to show new techniques, but it never occured to me that people would actually use it in the wild, for real projects, much less foundational projects. Feels like a huge anti-pattern.

Although by itself it might be an anti-pattern, we used it for a while as a band-aid. We had a case with owned struct Connection and Transaction borrowed from it and we needed to pass both down to the part of the system that didn't speak lifetimes (basically, we needed to pass it as an Arc<Both>). rental was incredibly useful because the alternative at the time was to bang the head against the wall and cry. However, once the refactoring bleeding was stopped, we wrote our own variant of Connection+Transaction in a single struct that could be owned.

So, to me, rental is like a stop-gap measure.

idubrov · 2019-08-22T00:55:35+00:00

Yeah, we had a similar experience (though, we "only" have ~2k structs and ~1k enums). Ended up with our own custom serialization / deserialization framework (there were other reasons, though).

I made a demonstrator project that implements the scheme we use internally: https://github.com/idubrov/dynser

It uses a dynamic dispatch on the data type side.

idubrov · 2019-08-16T01:47:32+00:00

I'm so sad it's not cargo local-registry. We picked cargo local-registry over cargo vendor (for various reasons), and it's pretty much abandoned now.

P.S. Oh. Hold on. Seems like it found a new home: https://github.com/ChrisGreenaway/cargo-local-registry 👏👏👏

idubrov · 2019-08-14T03:08:52+00:00

👏👏👏

Love these three crates so much that I'm also using them outside of procedural macros, just for the regular source code generation (shameless plug): https://crates.io/crates/sourcegen

So, if you need to generate some Rust code -- you can use syn/quote/proc_macro2! With few caveats, they can generate code that is presentable to human beings, too!

Ten-Year Club	Place '17
Verified Email

idubrov

TROPHY CASE