What’s everyone working on this week? (Week 37, 2015)

New week, new luck! What are you up to?

3 Likes

I've published Chrono 0.2.16 yesterday. I'm slowly working towards the initial TzRule time zone implementation for keeping with daylight saving time (DST).

1 Like

@Manishearth This topic looks a bit strange when pinned, because the first post is content and not describing what the topic is a about (but that's what you see globally).

2 Likes

I just changed the content. Now it should be OK.

cc @Manishearth

Oh, and my entry:

  • Last week, I wanted to work on Turbine, but other stuff got in the way. It's still on my list
  • I have another PR for Rust based on clippy suggestions. Perhaps I'll also try clippy on some other projects
  • I'd like to extend my shadow_unrelated lint in clippy with a note showing the previous definition. Perhaps I'm going to write some more lints, too.
  • Keep up the "Crate of the week" effort I started last week.
  • Work, work, work.

I'm working on benchmarking various NaCl implementations (repository for benchmark). So far, things are looking grim for my pure rust translation of tweetnacl. It looks like it ranges from 6x to 14x slower than the pure C versions of the library. :frowning: I'm right now trying to simplify the rust translation and identify bottlenecks.

I will be sad if I need to use unsafe code to optimize the core, since the point of a pure rust version was to write core cryptographic code in rust for safety, which is undermined if said code must be written unsafely in rust. It may be that NaCl is fast enough that an order of magnitude slowdown is still "fast enough." But really, CPU use comes down to battery use (in many cases), and I want to keep that as low as possible.

Last week I submitted a PR to cargo to add a subcommand that prints the locations of each crate's source, which will make cargo-open super simple since it can just use the output of the new subcommand (and other things can make use of that information too!)

I also submitted another PR to fix a pet peeve of mine regarding git init when you're in a subdirectory of a git repo.

So this week I'll be shepherding those through the code review process, and since I've got a decent amount of cargo's inner workings in my head at the moment, I might try my hand at a few more open issues :slight_smile:

3 Likes

I finally finished reading through the Rust book and am starting my first project, a network traffic analyzer for Dota 2. I don't really have much programming experience, I'm self taught for the most part and have only written a couple thousand lines of code, primarily in C and Python. I want to dive head first into Rust, so I'm trying to use it for parts of my program that could potentially be done simpler another way, my first task is trying to add more parsers to procinfo so I can find information such as available network devices, default route, udp ports being used to contact the game server, etc.

I'm really excited to finally get a chance to do something with Rust, I've probably read through the book ~3 times because something always seems to pop up and I forget everything I've learned before I can cement it into my memory :cry: I'm hoping that eventually I'll be able to start using Rust in my day job as a penetration tester. One of our primary rules is to not leave a host more vulnerable than you found it, so I'd like to start using Rust to write tools for my team to increase my productivity (once I actually get comfortable with the language :blush:) and to have compile time safety checks to keep me from making too many stupid mistakes :slight_smile:

I'm implementing a part of the oldest unimplemented RFC: RFC 16 - Attributes in more places. My patch allows attributes on statements, but they still need to find their way to the HIR and the rest of the compiler.

I'm still working on "named wildcards" or "recursive path variables" or "sequence variables" (they are in need of a better name than just "recursive wildcards") in Rustful. I had to rewrite the TreeRouter testing utilities to make everything properly testable (about time!) and I have yet to write the actual tests. I will also have to adjust the way hyperlinks are represented, now when every type of segment can have a label. The PR can be found here if anyone is interested or happens to have any ideas for what the variable types should be called.

I'm also planning to add some kind of crude congestion control (issue #65) to prevent open keep-alive connections from taking up the whole thread pool. These are only temporary measures until Hyper gets asynchronous IO.

I've been working on a simple microservice framework, nothing that will set the world alight but it's been teaching me a lot about macro syntax.

@droundy: For security reasons (side-channel attacks, mostly timing attacks) you should write parts of any crypto library in Assembler (and thus unsafe). Not using ASM will break your crypto.

@YBRyn: My impression was that if you never use secret data to either make a branch or index an array then you ought to be safe from that sort of attack. Isn't that why tweetnacl is considered secure (if slow)?

@droundy: That is ok to my knowledge. I don't know about tweetnacl. But it is hard to implement everything without branching on the secret data. And on some place you will have to do that, so you need ASM, right?

Are you comparing tweetrust and tweetnacl? It seems to me that they're approximately the same speed (never more than a 2× difference).

Optimisations can defeat this: there's no guarantee a compiler will not convert branchless code into branchy code.

1 Like

Keeping an eye on my notify library, and probably improving cargo-watch for running arbitrary commands, not just arbitrary cargo commands,

Yes indeed, I am completing those two, and they are now about the same. I previously had a bug and was comparing with NaCl when I thought I was comparing with TweetNaCl.

Regarding the optimizations introducing branches, what kind of optimization would introduce a branch based on the values involved in integer arithmetic?! Or cause a loop to run a different number of times based on what arithmetic is done in the loop?

I'm writing a Rust presentation for my team at work (I'm part of rendering team working on the Frostbite Engine which is used in games like Battlefield 4, Dragon Age: Inquisition and more)

6 Likes

I don't know all that much about computer science, or programming in general.
As a silly project to help me learn, I'm experimenting with making a library that efficiently stores the representation of a genome by cramming 4 nucleotides into a single byte. I figure since there are only 4 variants of a nucleotide, only 2 bits are needed to represent one.

It was easy enough to implement, but I'm not sure if it is done the optimal way with the best coding practices, so any feedback on what I've written thus far is hugely appreciated.

1 Like

It's quite rusty already. In the Display implementation, I would use the match as an expression and remove the duplicated write!(f, ..) calls: Rust Playground

1 Like