A couple weeks ago I wrote a blog post about how you can wrap a native library instead of rewriting it from scratch (see How to not RiiR). Now I'd like to write the opposite, how to incrementally migrate a C library to Rust.
Are there any native libraries you use often which you'd like to see written in Rust?
If possible, I'm looking for a C (or C++) library of a reasonable size (say 1000-5000 loc) where I can translate a decent amount of it to Rust in one article/weekend.
Any of the coreutils, especially those not covered by oreutils (coreutils without the C 
) would probably be a good target for such an article.
tinyvm might be neat 1000 lines, 2 really small programs using the library (interpreter/debugger) and that is including the examples with c/asm/tinyvm implementations for comparison
Edit: oops, commonly used.
I originally was going to suggest assimp, due to the recent thread about 3d animation export. But it is at least 12k lines for it's common core. I think it is probably more than a weekender, to wrap ones head around the separation of the core from all the individual file formats.
I miss ability to write MP4 files from Rust. I've tried to make OpenH264 usable in Rust, but it outputs "NAL"s, and to make a video file out of it I need an mp4 serializer. All existing ones are in C and usually part of a larger project.
Another library that's missing in the Rust world is ICC color profile handling. I've created a nice wrapper for lcms2, but it'd be nice to RiiR a library like that.
I think KissFFT would be interesting. FFTW would not be worth translating, but a simple fft could be nice.
I read through some of the documentation for lcms2 and its website, but wasn't able to figure out what it actually does. What's the difference between "colour profile handling" and, for example, C#'s System.Drawing.Color? Is it just an alternative way of defining colours?
Looking at tinyvm's source code it seems about what I'm targeting. The code is split up quite nicely so we could easily oxidise things one object file at a time. Plus VMs and implementing programming languages has always been an interest of mine 
"RGB color" is technically meaningless, as there are many flavors of RGB that look different, such as sRGB (most monitors), Adobe 98, P3 (newer monitors), bt 601 (old TV), rec 709 (HDTV). On top of that some digital cameras, scanners, and other devices have their own unique flavors of RGB that don't match any output device. These are described by ICC profile files, and a library is needed to interpret these files and convert between the variants of RGB. In practice processing of these profiles is required load images and display or convert them without having problems with desaturation, darkening, or weird green or red tint.
An analogy would be character encodings. u8 "character" meaningless. You need to know if it's some Unicode encoding, ISO 8859-x encoding, DOS codepage, or whatever. And you need a library to convert between them to avoid mojibake.
That's not a task for someone who doesn't know about color profiles.
If you use type for storing color information, you should have some notion of what colors you may have and what is the exact value of data you have.
Knowing that some color is red without knowing what profile is used doesn't tell you anything and doesn't represent color accurately. For example if something is "max red" (r=1, g=0, b=0), what color will you see will depend on a device, because every device will have different "max red" it can show,
therefore copying data from system a to system b will produce completely different colors. Or won't produce anything at all because some color range from device a is impossible to show on device b.
Most system using colors either work with implied profile or attach profile information to data and convert them as accurately as possible, you have to be explicit though whenever you transfer data to/from something else.
Another example: let say you look at webpage that shows two images, both created with different color profiles. Color management will ensure that both are mapped to profile of your screen,
and that a screenshot you may save won't be garbage when sent to your coworker.
Amusingly, while I was trying to implement this I found several memory bugs in tinyvm. For example, if you have nested includes (e.g. top_level.vm includes nested.vm which includes really_nested.vm) it'll segfault due to something in malloc (double free?). Originally I thought it was my code or I was setting up my tests incorrectly, but I found the same thing in the original tvmi.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
