Today I added caching to my gitlab CI since i keep on running low on minutes. This was annoyly challening for a few reasons.

• Gitlab only caches data in the build directory, so if you want to cache $HOME/.cargo you can't. So you must redefine $CARGO_HOME.
• There's a bug in cargo where it uses the wrong linker that seemd to pop-up when redefining $CARGO_HOME and cross compiling.

The error I was recieving was the following for each compiled object.

Relocations in generic ELF (EM: 40)
Relocations in generic ELF (EM: 40)
Relocations in generic ELF (EM: 40)
Relocations in generic ELF (EM: 40)
Relocations in generic ELF (EM: 40)
...
error adding symbols: File in wrong format

I want to share a small utility for PostgreSQL that I use regularly for debugging. It is not a unique utility, there are many others like it, but this one is mine, ... and it's written in Rust!

Recently I ran into a bug in my code; hey, it happens. The bug was that I had a struct which could serialize into json, but could not deserialize from its own json. The struct holds a value for a mac address, which is 48-bit integer (that i store in a u64), but it is serialized using the network interface name. For example on my mac, i have a network interface named en1 with the mac address of 20:c9:d0:b0:a4:71:

In my previous post, I described taking a simple enum and creating a custom type in diesel. This post will take that same enum and implement deserialize.

I often get tripped up by the mechanics of deserializing so this simple enum makes for a good example. Again, this is to benefit anyone looking for more examples of Serde's Deserialize as well as for myself, so I can remember next time I need to do this.

I've been working with diesel and serde. I use diesel for my postgres datastore, and serde for serializing/deserializing data to the web. Recently I came across a situation where I needed to define my type in diesel as well as implement deserialize in serde. The example below is a fairly simple so it makes for a good example to share so others can learn (and so I can remember how all this works next time I need it).

Rust + Diesel + GitLab + CI🔗

The folks over at GitLab give away some free compute power to allow users to have CI builds of their project. It is very straightforward to get Rust projects to build within a CI environment. This post is going to take that build process one small step further, we’re going to build a Rust project that uses the Diesel ORM. This adds a step of complexity since to compile a Diesel project you need to have a postgresql database accessible if you’re using the infer_schema!() macro.

Note: diesel has instructions for using diesel print-schema instead of using infer_schema!() in version 1.3.x. It has been proposed to move away from infer_schema!(), but that issues was closed because infer_schema!() is still useful. A redditor commented that infer_schema!() has been deprecated in diesel 1.3.

Actix::From(Rocket)🔗

I was inspired by Nick’s post to migrate my code from Rocket to Actix. I have also been nagged by recent struggles with the nightly compiler and its compatibility with all the other crates that I use and other the platforms that I use; my code runs on 32/64 bit arm and 32/64 bit x86. When I started using Rocket around a year ago, the nightly compiler was just as stable as the stable compiler, but things have changed as rust is a growing eco system.

The above post stated how far actix has come regarding ergonomics and that migrating from Rocket to Actix was painless. I had a little bit of a struggle, and I think is worthwhile sharing for anyone else wishing to make this move.