It’s almost Christmas. Are you still rusting?
Yes. Mostly paperwork again, though :).
Working on a CachedValue type, (see first try: https://gist.github.com/dns2utf8/d1db02cd530bd809371b) that will automaticly update its value after a timeout.
This week marks a big change for the book.
Historically, I always had a vision for the docs, but with 1.0 coming, it was a struggle to just get everything documented and keep it from breaking, let alone put things together in the way that I wanted.
One way in which this manifested is in the split: https://doc.rust-lang.org/book/
After reading this introduction, you’ll want to dive into either ‘Learn Rust’ or
‘Syntax and Semantics’, depending on your preference: ‘Learn Rust’ if you want
to dive in with a project, or ‘Syntax and Semantics’ if you prefer to start
small, and learn a single concept thoroughly before moving onto the next.
Copious cross-linking connects these parts together.
Two paths through one book isn’t good. And “Learn Rust” never really came together in the way that I wanted it to. It only even came into existence the week before 1.0! I just didn’t have time to make things right. And then, it was time to work on API docs…
So, after doing a lot of chatting with a lot of people, including at the work week last week, I’ve come up with a reorganization of the book that makes me happy. It’s going to be great. I’m really excited about it. But it also means that there’s gonna be a lot of change, and things might not be coherent in the meantime. I don’t want to land a PR to change 300 pages of docs!
As such, I’ve made https://github.com/rust-lang/book. I’m going to be working on the book in that repo. Right now, it’s empty. But that won’t last long. This will let me work on things without screwing up the existing book for people, in the meantime.
You’ll notice one more thing: I’m using mdBook. This may be for good, or it may just be for development, but I’d like to think that it’s for good. We would have to sort out how to make it work with the build process. Or, the book might end up living in this repository permanently. There are still some unanswered questions. But in the worst case, things will just stay the same: once we’re happy with the new state of the book, we can import it back into tree, and things should Just Work. But maybe we can make them better, too.
Oh, and this also means I’m going to be a bit more liberal with pull requests to the book itself, as it’s a bit less important that the markdown be perfect, that it absolutely not introduce new forward references, or anything else.
Finally, it’d be nice to eventually move translations into the official docs as well. I’ve made
to chat about it.
I’m still trying to get palette ready for release, since last week was too crowded with other things. There are still things to document, a readme to write and I have to decide what to do with the great multitude of constructors for the
Rgb type. They are a bit of a combinatoric nightmare…
By the beginning of this week I at last finished with systemd-cron-next. Now it’s in release candidate state, and needs testing. It works for me (at least to my machines use it: my home server and a handful of cron jobs, and my work laptop with a couple of cron jobs from installed packages), but before I announce stable release, I would like to see more wide-spread testing. So if you guys are interested in it, I would very welcome you to test it, so this week I can fix as many bugs in it as possible. Thank you in advance!
Upd: fixed link
Continued working on rustlearn and added bindings to libsvm, a library for fitting support vector machines. Dealing with C/C++ when writing the bindings made me doubly grateful for all of Rust’s conveniences.
Did some clippy runs, so I replaced a bunch of
to_string calls, found out that
map_or is seriously underused and discovered there quite a few unelided lifetimes out there.
I made my first publicly released (attempt at a) game for Ludum Dare and found that my game engine is pretty bad and clashes with Rust’s strength’s and weaknesses in a way that makes it hard to use. I think I’m going to have to throw out a lot of my past game dev experience and figure out “the right way” to make games in Rust.
A few people say that
rustc_serialize is no longer active maintained, and there was a discussion about this on /r/rust last weekend. So I have been working on a handlebars-rust branch that uses
serde_json as type system, and will eventually sunset current rustc_serialize based implementation.
Working on a distributed string fuzzy matching application. I couldn’t find a great string fuzzy matching library so I starting one https://github.com/hamersaw/ruzzy with a few trivial implementations. Trying to make a generic dht library so users can not have to worry about the plumbing of the system with my rustdht project. It’s very elementary right now and I’m hoping to have some time to work on it over my break from school. The actual fuzzy matching application is https://github.com/hamersaw/fuzzydb, It’s a start to a project and really my first of substance using rust. I’m loving learning the language.
I’m working on Curtain - A responsive data administration tool for PostgreSQL.
Here is a screenshot:
Thanks! I have almost finished. serde_json’s
Value is pretty much similar to rustc’s
Json. The transition is quite smooth.
Working on the side on the hwloc-rs bindings to get it closer to completion and now figuring out how to deal with concurrency and *mut/*const and proper send/sync semantics.
This looks really nice, but when I click “connect”, it doesn’t do anything.
In the last week, I have completed cargo-fmt, now I’m working on further improvements.
I just updated the client side code, I must have used a local default DB_URL. Now, i’m using the DB_URL of my heroku free instance database. It should now work, if not, then the server must have reach its limit.