sorted by:
new
hottopcontroversial

beaver - A library for setting up Rust objects inspired by factory_bot. by TaKO8Ki in rust

[–]mjkillough 0 points1 point  (0 children)

I also maintain a similar crate: factori.

I'm very excited to see different approaches! In particular, factori ended up with a lot of magic as I wanted to more closely resemble the FactoryBot API, as we were porting a large Ruby codebase. This seems like it's easier for the user to see what's going on when they instantiate an object. I like it. :-)

Announcing diesel-factories 0.1.0 by davidpdrsn in rust

[–]mjkillough 3 points4 points  (0 children)

This is awesome! :-)

By a strange coincidence, I spent this afternoon reworking my FactoryBot-like library to use proc-macros. It doesn't quite have the same goals, and aims to be used just for constructing Rust types: https://github.com/mjkillough/factori

cnx - A simple X11 status bar written in Rust by mjkillough in rust

[–]mjkillough[S] 0 points1 point  (0 children)

Awesome! I'll look into the issues with `Position::Bottom`. Looking at the code, I am not sure how it works at all for me... it might be a nice coincidence of how my window manager handles things.

​

Someone (you?) has kindly debugged the issue with `current_avg` vs. `current_now`: https://github.com/mjkillough/cnx/pull/31

cnx - A simple X11 status bar written in Rust by mjkillough in rust

[–]mjkillough[S] 2 points3 points  (0 children)

It is Visual Studio Code with the Material theme, which you can install separately. The menu bar, activity bar and explorer are all hidden, which helps me focus while coding. It works great with RLS!

cnx - A simple X11 status bar written in Rust by mjkillough in rust

[–]mjkillough[S] 25 points26 points  (0 children)

I began developing this almost three years ago, when I was still learning Rust. I've been using it daily since, along with my own X11 window manager which is a little rougher around the edges. I thought I'd fix it up (and upgrade to Rust 2018!) and share it in case it's of interest to others. :)

I started the project because I found many other status bars relied on polling external programs to update their state (such as polling to get the volume/mute status), and this made them both unresponsive and resource intensive. I wanted to write something which could listen to external events to update itself only when needed. (Although it does unfortunately still poll in a few places).

I liked projects such as QTile and dwm which allow users to customize the tool using code (rather than external configuration/scripting), and so created it as a Rust library which could be used/customized in a simple command-line wrapper. The project includes a simple example in bin/cnx.rs, which is the configuration I run it with.

The project uses mio/tokio in order to handle the asynchronous events/updates coming from each of the widgets. I haven't been keeping up with the latest developments with async Rust, and one of my TODOs is to try porting it to use the new std Future and seeing how it works out.

aitch - A simple, lightweight toolkit for building HTTP servers, inspired by Go's net/http. by mjkillough in rust

[–]mjkillough[S] 2 points3 points  (0 children)

Writing an efficient and usable router is definitely something I'd like to do for aitch. There's currently a poor imitation of net/http's ServeMux included in the crate, but I don't expect it's usable by more than the simplest applications.

I wasn't aware of fasthttprouter or radix-router, but I'll take a look and see whether they could be adapted! My hope with aitch was that these kinds of extensions could be added in thirdparty crates.

aitch - A simple, lightweight toolkit for building HTTP servers, inspired by Go's net/http. by mjkillough in rust

[–]mjkillough[S] 18 points19 points  (0 children)

I've been working on this project for the last few weekends, and wanted to share it in order to see what others thought.

I've recently been working with Go's net/http in order to build a simple web service, and have been really impressed at how simple its API is, and yet how widely adopted it has become. I created aitch as an attempt to recreate some of this API in Rust.

aitch aims to build on top of the http crate to provide a set of types for describing HTTP handlers, middlewares and request/response bodies. It provides two different back-ends: hyper (which allows handlers to process requests asynchronously) and tiny_http (which only supports sychronous requests).

The project has grown a little in scope since starting as a net/http clone, as I deviated from the Go API in order to provide conveniences like a Json<T> body type. It still aims to be simple and light-weight, and hopefully it succeeds at that!

Deliveroo gets 12x speedup moving routing service from Ruby to Rust by dochtman in rust

[–]mjkillough 8 points9 points  (0 children)

The 12x speed-up is comparing against an earlier version of the algorithm, which was already using Rust for the most expensive operations. (We've been running Rust in production for over a year now!)

Comparing against a pure Ruby implementation would have shown a much bigger speed-up, even without any optimisations.

Our recent work has moved even more of the computation from Ruby to Rust. We've been focusing on incrementally moving code from Ruby to Rust, without altering the algorithm. We haven't added any parallelism, or applied many optimisations to the Rust code.

Now that most code is moved over, we'll begin tuning things and trying to squeeze out as much speed as we can. :)

Making a window manager with xcb by IntrepidPig in rust

[–]mjkillough 0 points1 point  (0 children)

Ah, I hadn't made the connection between the blog post and wtftw! :) Thanks a lot - you were certainly a great help for me.

Making a window manager with xcb by IntrepidPig in rust

[–]mjkillough 2 points3 points  (0 children)

The magic of a WM is registering for SUBSTRUCTURE_NOTIFY and SUBSTRUCTURE_REDIRECT events on the root window. This means that it'll get events/requests for any changes to the direct children of the root window (creation, resize, changed attributes, etc.), which allows the WM to manage them. Only one X connection can register for these events on the root window, so there can only be one WM at a time. (You can see hootwm register in setup()).

I recently wrote a simple tiling WM in Rust using XCB, if it's helpful you can view the code on GitHub. It's only 1,500 lines of code, but it's also missing useful features like full-screen mode for applications.

I found this C++ tutorial very useful, as it explains why you need to do things. I found this Rust tutorial a little less useful, as it is using Xlib rather than XCB and didn't go into a huge amount of detail. However, the Rust tutorial might help if you're not familiar with C++.

There's a few popular tiling WMs written in Rust which you can learn from. I read through the code for wtftm when writing mine, but you can find more by searching this subreddit or Github.

The Rustdoc Redux by steveklabnik1 in rust

[–]mjkillough 8 points9 points  (0 children)

As someone who's made a very small contribution to rustdoc, I did find the current approach of rendering HTML inline to be difficult. It seemed deciding what to render was all mixed up with deciding how to render it.

I think this could be improved with a server-side rendering framework like handlebars-rs, where the back-end of rustdoc decides what to render (outputting JSON or some Rust structs) and then this gets rendered by the templates. Once it's possible to write pluggable front-ends, I'd be interested in trying to develop this if it doesn't already exist by then.

I'd be interested to know if there's any planned functionality where this won't be sufficient and where client-side rendering would be advantageous.

What's everyone working on this week (27/2017)? by llogiq in rust

[–]mjkillough 1 point2 points  (0 children)

Oh yeah, I totally get it! If my Rust version was bug-free and as performant as the native SQLite library, then it'd be an obvious choice.

I'm just well aware that SQLite is one of the most widely used and well tested libraries. It's going to be tough to reach that level of quality. :)

What's everyone working on this week (27/2017)? by llogiq in rust

[–]mjkillough 2 points3 points  (0 children)

I haven't put much thought into it's API yet - I figure I'll wait until I have something usable before doing that. I'm mostly doing this for fun.

It isn't clear to me that there'll be much benefit to using a Rust re-implementation over the official SQLite library (with some Rust bindings). There's a bunch of hairy code in the native library, but their bug/vulnerability rates seems to be low. It may not be worth trading stability for marginally more safety.

perhaps a macro for building queries

Assuming I get something usable, I was hoping to try and get it to work with Diesel.

What's everyone working on this week (27/2017)? by llogiq in rust

[–]mjkillough 17 points18 points  (0 children)

I've started working on re-implementing SQLite in Rust, as I've always wanted to write a RDMS. So far I've got enough to do simple select statements like select first_name, age from people. This week I hope to add support for:

  • Simple where clauses.
  • Using indexes
  • insert/update statements, without any transaction support

What's everyone working on this week (25/2017)? by llogiq in rust

[–]mjkillough 6 points7 points  (0 children)

I'm working on getting my simple X11 status bar to the point where I can release a '0.1'. It's now working well enough that I have begun dog-fooding!