New week, new Rust! What are you folks up to?
Currently working on
restor, trying to generalize, and remove unnecessary lifetimes, and overall improve usability. Also added concurrent versions of the storage to allow multithreaded allocation and borrowing using
RwLocks. Currently, I’m fighting with the fact that GATs don’t exist yet, so there’s some more lifetime juggling that needs to be done. Earlier, I ended up with a quite puzzling error:
let x = DynamicStorage::new(); x.get::<usize>(); //This returns a temporary //Error cannot drop `x` because it may still outlive the //temporary in the previous line.
I am a compsci eng student writing a paper on Rust and how it will save us all from bufferoverflow and other memory issues. So I am reading frantically trough the rust book while I make little snippets of code I can go back to.
The paper will go in depth on memory, concurrency and safety. My idea so far is to write a simple hash cat clone that spawns multiple threads for comparsion and hashing of wordlists.
I will be very interested to read that paper!
I will link it, however this time around it will be in Norwegian. Hopefully it translates ok trough google.
I am Afrikaans-speaking, so I might just understand with the help of Google Translate and my knowledge of Germanic languages Thanks!
I’ve been working on my own regex library and lexer generator as part of a greater ambition to learn more about PLT and compiler implementation.
A good chunk of the lexer generator is done. Probably about half, but it’s slow going because I can only allocate so much time to it. It’s been a great way to strengthen my general Rust skills: generics, macros, general structuring of modules.
My regex implementation strongly favors cache-friendly data layout. That’s fun to think about.
Going to be working on making this button work in FlowBetween:
That is, the onion skin display: that button has just toggled on and off without actually doing anything for too long now. I’ve put together a frame cache for storing the onion skin data, which uses the same format as the canvas stream sent to the HTTP UI: actual onion skins are generated by using the path sum functions I implemented in flo_curves - which I hope should cut down on the number of points to render and give them a good look, but is expensive to calculate, hence the cache.
I might also get time to look at an idea I’ve been thinking about for the eraser tool where it’s generated as an attachment to elements in the path of the brush stroke instead of a brush stroke in itself, which will look better when elements are moving relative to one another. That would also make it possible to actually delete elements when they’re entirely erased as we could detect when there are no more points left to display (instead of drawing everything and erasing it later). This all increases the cost of calculating the path quite a lot, so I developed the cache used for the onion skin in such a way that it can be used with actual elements as well if necessary in the future.
I’d love to read it too. I’m from Denmark, so I should be able to manage.
Heavily forging sauron
- Adding all the complete list of svg/html tags and attributes
- Porting the old elm-webclient in diwata to use sauron.
cgats is a CGATS color measurement file parsing and calculation library. CGATS is a standard for capturing color information in a format similar to CSV, but with some extras. I do a lot of ICC color profiling and measuring in the printing industry and this is the first really useful thing I’ve written in Rust that I think others may find useful as well. I included an example CLI application that I use all the time, mostly for averaging CGATS files generated by color measurement softwares.
deltae is a dependency of cgats and is a Delta E calculation library. Delta E (or Delta Error) is a method of quantifying the color difference between two color measurement samples. The library includes several Delta E calculation formulas including DE2000, DE1994, DECMC, and DE1976.
I’m new to Rust (and programming in general), so these are definitely works in progress, and there may or may not be some hacky things going on here. I haven’t really met anyone who is into these kinds of color software things the way that I am, so if you are, I’d love to hear from you.
I’ve just started working as a full-time Rust developer. We want to create our validator-stack with Rust, so I was looking into tokio, hyper, the futures-preview trying to make sense of (how in practice) does it work and postgres ( with tokio_postgres async client ).
Sadly no OSS(well technically the validator will be Open-source ) contributions and I’m pretty new to Rust so it’s a bit of a fight right now to learn and rise my productivity.
I’m really excited that finally I’ve started working with Rust, not only in my spare time!
I fixed a couple of things and rewrote the parser, so that more test scenes can be used as they are (without modifications) now:
I think I will do another release this week …
Increased code coverage for my game from 93.4% to 94.5% (a whole 1.1% ). Most of that was getting tests working for edge cases; now I’ll know when I break things.
Next task is to improve the character selection menu and map selection menus, so players know what they are doing.
Disassembling PNG files of scanned sheet music and reassembling with my own formatting options. Unbelievable how fast it works.
Still working on an upcoming Notify release, feat lots more options and better channels. This week I’ll be finishing off upgrading the event classification system.