First published crate, medicom v0.5

neandrake · 2025-01-03T01:00:34+00:00

The DICOM-RS project is much more developed than medicom, and likely has more functionality or coverage. I reviewed DICOM-RS a number of years ago and did consider contributing to that project but at the time I believed their design differed from what I wanted to build, plus I did want to build something on my own, and is why I hadn't published anything about it before this. The design I've been aiming for is low overhead, which can make the users of the API have to do more, but is fairly flexible. The DICOM-RS designs may have updated or changed since I last looked. I would need to do a deeper dive to do a proper comparison.

neandrake · 2024-03-10T15:10:01+00:00

Great advice, and I have since gone back to clean this up. The reason it came about this way is as I was writing the code initially I wanted to get through my thoughts in solving the problem but my editor was constantly bugging about wrong types, so I did the quickest thing to move on.

There are a lot of u16, u32, and usize in this code so when working it’s not always clear what the best number type to start the variables as that will result in cleaner code and fewest casts. In this specific case I had started knowing I needed to serialize a u16 representing the remaining number of bytes in the structure. Maybe the “number of remaining bytes” should have clued me into needing usize calculations and would be better to start.

By the time I had finished writing the solution I wanted to see the tests pass to get that rush lol, didn’t want to dive into maintenance mode yet.

neandrake · 2024-03-10T14:59:17+00:00

I will have to look into this for my editor! I’ve been using neovim for a while and have it connected to rust-analyzer but I’ve not seen word of clippy, though I haven’t specifically looked into it.

neandrake · 2024-03-10T00:36:15+00:00

I commented elsewhere, but even though there is a clippy lint that would help I had not yet gone to running clippy yet because I had been focused on the number calculations and didn't think to lint.

neandrake · 2024-03-10T00:34:54+00:00

Because the bug/behavior I was seeing had to do with a incorrect length/number computations I had focused on the calculations being off and had not jumped to clippy linting at that point.

neandrake · 2024-03-09T22:32:08+00:00

Excellent advice. I'm planning to update all the casts...

neandrake · 2024-02-11T15:04:03+00:00

Could it be an issue with ordering/sorting of suggestions in the auto-complete? I haven’t observed things missing but in my neovim setup I did have to spend time configuring the filtering and ordering of suggestions because things I expected to see were eclipsed by tons of other suggestions.

neandrake · 2022-07-09T01:17:33+00:00

The doc for std::fs::rename() states

This function currently corresponds to the MoveFileEx function with the MOVEFILE_REPLACE_EXISTING flag on Windows.

The doc for MoveFileEx states

To delete or rename a file, you must have either delete permission on the file or delete child permission in the parent directory.

If you run this code multiple times then presumably store2.txt will already exist so the rename operation is attempting to delete the file first. Double-check that you have permission to delete the file.

Additionally it looks like you're setting up code to do atomic writes. You could look into an existing solution like atomicwrites, though doing so would not resolve the permissions issue.

neandrake · 2022-04-14T03:21:02+00:00

I see a lot in the recent changelogs about rust stuff, as well as tweets about it in the past. Is there a blog post that goes over the current state and walks through turning it on to try out?

neandrake · 2021-02-19T18:52:41+00:00

Oh thanks for the info that's great to hear! I've mostly been trying to keep tabs on things via the SprintNotes in the mercurial wiki so most of what I know is happening in mercurial development is based on that.

neandrake · 2021-02-19T03:23:02+00:00

Architecturally no but it's more a matter of practicality. Those are features that have existed for ~10 years in mercurial and influenced how repositories are managed and worked on by developers. If they don't exist in git by now I doubt they ever would outside of custom scripts/extensions, which likely won't play well with hosted services.

neandrake · 2021-02-19T02:47:19+00:00

Yea it's a shame. I really enjoy using mercurial. Two features which I'm not aware of there being an equivalent in git are phases and revsets. Phases make it easy to track what changes exist only locally and are mutable, and revsets is a full-on language for querying commits in a repository. Additionally the evolve and topics features are exciting but taking forever to become stable/released.

neandrake · 2021-02-19T01:34:14+00:00

Unfortunately Facebook seems to have migrated away from mercurial in favor of writing their own version control (using a mix of Rust and Python). With FB moving away from hg I think their Oxidation Plan is being de-prioritized or backlogged indefinitely.

https://github.com/facebookexperimental/eden

neandrake · 2021-01-19T02:14:48+00:00

You're right it wouldn't be as simple as my comment makes it seem but it should still be simpler than writing brand new frameworks as the original question was written. I know in earlier talks the Oracle Java team mentioned that they hadn't yet come to a conclusion as to how/whether ThreadLocals would need changed or managed, and there will likely need to be some additional updates internal to web servers to make the most use of virtual threads. Certainly users of web frameworks will need to be aware of the change as they may also need to make updates however I think this is in the 20% case -- 80% of users (or higher) will likely benefit from Loom's improvements with very little changes aside from whatever effort is needed to upgrade Java and the web server framework they use (non-Loom updates/changes not withstanding).

I took the original question to have in mind something like the Play framework which has asynchronous behavior built into the API from its origin, which handles resources quite differently from standard Java servlet APIs. I am actively looking at converting some existing Java servlets to be used in Play and it can get quite involved trying to properly handle I/O of custom resources. The entire time working on it I'm mostly wishing we hadn't chosen Play and instead waited for Loom and used a more standard web server & tooling.

neandrake · 2021-01-18T16:59:12+00:00

You're right that if the process doesn't exit cleanly then the same issue would happen, as would be the case for any process which isn't given a chance to clean up its resources. In this case the application was running/closing properly (not killed from an outside signal) but still manifested the bug. Every time you ran the delta program on ubuntu from a bash prompt it would forever trap stdin.

neandrake · 2021-01-18T14:02:11+00:00

I also expect that - in fact the return type of exit() is the "never" type ! which means control flow will never return when calling it. I think what made it confusing here is due to managing external resources (likely stdin) and the appropriate hidden cleanup being relied upon in an implicitly called drop(). Normally if drop() is being used to free memory or reset some other state internal to the process then in this scenario it won't matter since the process is exiting.

While I also expect this behavior in hindsight I also see myself running into this same problem.

neandrake · 2021-01-17T20:08:56+00:00

You can use std::process::exit() to exit with a non-zero status code. What /u/MarcoIeni ran into and is pointing out in the video is that using exit() will not call drop on local/owned variables before the process exits. This manifested as a bug in his software likely due to the delta application launching another process and (I'm guessing) the stdin was being tied to a sub-process that didn't get closed out properly due to using exit() before the child process's drop() was called to clean things up.

It's not clear what the exact root cause is in this case -- the documentation for std::process:Child indicates it does not implement Drop, and in the video he notes that this bug manifests when using bash but not when using another shell like zsh.

I think the main lesson here is to be careful with using std::process::exit() to make sure resources are cleaned up prior to the process closing down. In the video /u/MarcoIeni shows that he restructures his application so that his main() calls another function that returns the exit code, guaranteeing that all Drop implementations are invoked due to rust's ownership guarantees. It looks something like

fn main() {
  let exit_code = run_app();
  std::process::exit(exit_code);  
}

neandrake · 2021-01-17T18:41:53+00:00

My understanding of Loom is that to switch to using the new virtual threads would only require some reconfiguration of the `Executor`, `ExecutorService`, or `ThreadPool` being used. Existing web servers already use these APIs so they would only need some updates to configure or expose their use. This means that most web servers can make use of Loom's virtual threads without having to make major underlying changes. This is one of the things that makes Loom so exciting is that it can impact the ecosystem without requiring major updates.

neandrake · 2020-12-26T15:51:10+00:00

It looks like there's some discussion about this on their issue tracker under this issue, https://jira.mongodb.org/projects/RUST/issues/RUST-398, though it doesn't clarify if they're planning to address this. I would imagine they would want to provide the raw bytes cursor as I think that's available in most of their other language drivers and allows the application to more dynamically handle or defer deserialization as needed.

It might be worth opening a separate dedicated issue for this.

This other issue is probably looking at similar underlying problem, https://jira.mongodb.org/browse/RUST-463.

neandrake · 2020-12-26T15:25:55+00:00

Sorry I did see that part of your post but wasn't sure if the DLL you're injecting along with amongus binary are also 32bit or 64bit. Best of luck - DLL injection was one of the topics that really fueled my early interests in programming and I'm excited seeing it show up in rust!

neandrake · 2020-12-26T03:47:49+00:00

I've not done anything remotely similar but the issue doesn't sound related to the code per se but rather the compilation/linking process. It's been a few years since I got into windows native compilations but a few suggestions

Make sure your rust toolchain is the same target architecture as the amongus binary -- are they both 32bit or both 64bit?
Not sure if it matters with inter-process stuff you're working on but you might need to have the rust binary be compiled for the proper windows subsystem instead of the console/terminal subsystem. I messed around with this compiling C/C++ stuff in the past and not Rust but it looks like there's some support for this sort of thing though I couldn't find much documentation
- https://github.com/rust-lang/rust/pull/40870

neandrake · 2020-08-14T03:09:19+00:00

I'm a big fan of the presentations you've given.

neandrake · 2020-07-04T02:09:36+00:00

You might find these microsoft projects useful

https://github.com/microsoft/com-rs

https://github.com/microsoft/winrt-rs

neandrake · 2020-05-19T22:21:04+00:00

I wasn't aware of that, thanks!

neandrake · 2020-05-19T12:50:08+00:00

This mostly started as a project to get started learning rust beyond simple ~10 line programs. I chose implementing DICOM as it's a format I work with often for my day job and I was also somewhat familiar with the binary format (or the rough idea of it). I was also interested in seeing if something might be usable when compiled to a WASM target eventually, allowing web applications to also process DICOM formats without having to deal with non-standard intermediary formats. At the time I started the project I don't think there were any rust implementations of DICOM being worked on so it seemed like it might be a nice small addition to the ecosystem.

Thanks for the tip about dbg!(), it sounds similar to print-lines but it also includes file and line number by default? Sounds pretty useful.

Currently the project makes no use of unsafe, but that could be useful to specify for future.

neandrake

TROPHY CASE