danigm.net - programming

LMDB: Cache database in memory

danigm — Sat, 30 Jun 2018 00:00:00 +0200

Some days ago I was in a meeting talking about the E2E implementation for Fractal, to know the current implementation state and to talk with other developers. This meeting was promoted by Puri.sm people, because they want to use Fractal for the Librem5 phone and they want to have E2E. There's people working in the E2E and I think we can have this on Fractal at the end of the year, but this is not what I want to talk about today.

In this meeting there was Fractal developers but we've also other people, like the nheko developer, mujx (nheko is a Qt matrix client). During the meeting, mujx ask us about the cache storage that we're using, because for the E2E is too important to don't lose any key, because that'll be catastrophic, you won't be able to read room messages. So it's important to have a transactional database storage for this information. They are using LMDB, I didn't know nothing about LMDB so after this meeting I start to about it.

LMDB

Lightning Memory-Mapped Database Manager (LMDB) is a key-value database, it's memory mapped so it's fast, and also uses filesystem storage so we've persistence. This database has transactions so it's safe to read/write from different threads or process.

In Fractal we're using a simple json file for cache, but this doesn't support transactions and if the app crash or if something bad happens, we can lose data. This method is simple, but is slow and insecure, so using LMDB will improve Fractal in several ways.

But LMDB is in memory and in Fractal we've a lot of interface code sharing the app state, so we're passing the state between threads with copies and complex data sharing. This can simplify the interface code because using LMDB for the application global state will make this state accesible from different threads.

Testing LMDB

Fractal is written in Rust so I want to write some tests before start to use this on Fractal. There's a simple LMDB rust crate, and I've been writting an example lib to test it.

Basically what I've done is to write a simple trait that you can implement for simple Rust structs so that struct can be stored and recover from the cache with a simple method:

#[derive(Serialize, Deserialize, Debug)]
struct B {
    pub id: u32,
    pub complex: Vec<String>,
}
impl Cacheable for B {
    fn db() -> &'static str { "TESTDB" }
    fn key(&self) -> String {
        format!("b:{}", self.id)
    }
}

The struct should be serializable/deserializable with serde because in this example I'm using bincode to convert structs to [u8].

The Cacheable trait only have two required methods, the db and the key. The db is the db name to use to store this struct instances and the key is the key to use when storing a concrete instance.

With this, we can store in the cache and query from the cache, using the key:

let db = &format!("{}-basic", DB);
let mut cache = Cache::new(db).unwrap();

let b = B{ id: 1, complex: vec![] };
let r = b.store(&mut cache);
assert!(r.is_ok());

let b1: B = B::get(&mut cache, "b:1").unwrap();
assert_eq!(b1.id, b.id);
assert_eq!(b1.complex.len(), 0);
b1.complex.push("One string".to_string());
b1.complex.push("Second string".to_string());
b1.store(&mut cache);

let b2: B = B::get(&mut cache, "b:1").unwrap();
assert_eq!(b2.id, b.id);
assert_eq!(b2.complex.len(), 2);
assert_eq!(&b2.complex[0][..], "One string");

This is thread safe, so we can read from the cache from different threads and we'll always get the last version in the database.

LMDB is a key-value database, so we don't have relations. This is not a real problem for us because we can model the relations in the keys, for example, we can store Room messages with keys like this "message:ROOMID:messageID" and then we can iterate over all objects with this prefix: "message:ROOMID" that will give us all room messages. Something like this should work:

let prefix = format!("message:{}", room.id);
Message::iter(&mut cache, &prefix, |m| {
    // m is a Message struct fetched from the database, we can do
    // what we want here
    // ...
    Continue(true)
});

LMDB in Fractal data model

We're thinking about moving the Fractal data model from the AppOp struct to a new crate, independent of the UI, to simplify the UI code and to be able to use the same data model from different UIs (we wan't to split fractal in two different apps), Julian wrote about this.

I think that we can use the LMDB cache to store this new app state that we want to have and this will simplify a lot our code, because we will share the same state and this state will be persisted in filesystem.

I'll start to write a new crate for Fractal to start to move all the app state to this new crate. I think I can write a generic tool to simplify the LMDB use, maybe I'll publish another crate in crates.io and use that in Fractal, but I need to think a little more about the pattern to follow.

I write a lot of web code in my day to day work, and I've been working with react+redux. This LMDB cache thing in Fractal reminds me a lot to the redux store and I want to follow a similar pattern so we can have only an app state and only a way to update this state.

Stickers in Riot

danigm — Sat, 19 May 2018 00:00:00 +0200

Yesterday I read a blog post about the new Riot.im Stickers. This is not a matrix.org feature, it's implemented as a widget, when you send an sticker you're sending a new event with the type "m.sticker", which is similar to the "m.image" event.

The matrix.org protocol is flexible so this is a good example of how to add new features to the clients that uses matrix without the need to change the protocol.

This is not a core feature because you can send images, but I think this is great and add a simple way to show reactions for the users, so as I was reading I thought that we can add this to Fractal, so I started to read how we can add support for this.

Reading the doc

The first thing to implement a feature is to read the specifications or the technical documentation so we can know what is needed... But there's no documentation yet about Stickers or widgets yet.

This is a problem because we can't implement a feature if we don't know what we should do. But free software give us a great opportunity when this happens, we've the Riot source code so we can look at the code and learn what they are doing.

Reading the code

Riot web is a javascript application that uses AJAX to communicate with different server APIs so the first thing that I did to start to understand the stickers thing was to open the firefox debugger and view how riot is communicating with the server.

From here I've learned that for stickers riot is asking to the scalar.vector.im server. But I don't understand the whole thing with the requests because riot does a lot of request to different APIs and I can't isolate the stickers thing easily.

To fill my understanding gap I go to the matrix-js-sdk and matrix-react-sdk and I did a quick grep to the source code looking for the API calls that I've view in firefox. With this I can understand the full stickers process.

Writing an example

To say that I know how this is working, it's not enough the code reading. To make sure that I've understood the whole process I need to write a simple program that does all the process and then I can say that I understand this.

So I started to write a simple python script using requests. This simple script does the request to the server and list all the stickers json so I can say that I'm able to communicate with the API.

Stickers in Fractal

After this small research I'm able to implement an initial sticker support for Fractal. I'll try to add a simple way to show and use stickers and a way to render stickers in the messages history.

If there's no secret problems we'll have a basic stickers support in Fractal soon.

Fractal Hackfest, Strasbourg (day 2)

danigm — Sat, 12 May 2018 00:00:00 +0200

The second day of Fractal hackfest was really productive, we talk about a lot of topics and takes some important decisions.

E2E Encryption

The encryption is a needed feature but encryption is hard to do in rooms. Matrix uses public-key cryptography, for rooms they are using Megolm, that's a protocol to exchange encrypted messages with more than one and share that message keys in a one-to-one secure communication.

I don't know a lot about this E2E because for me it's more important to have the client working with a basic functionality before the encryption. So you should read the official doc because maybe this that I'm writing here is completely wrong.

To do all this E2E key sharing, client side encryption and communication, Riot has three different implementations of the same lib, so they have this code in the JavaScript SDK, the same ported to iOS version in ObjectiveC and the same ported to Android in Java. Below this lib there's the libolm that does the real encryption.

For the future it should be a good solution to have only one lib that does the encryption thing, so we need to push in that direction and maybe matrix.org and Purism can pay for that work to be done.

From Fractal, we've two options or wait until we've the official E2E C/C++-lib or something, or try to port the iOS lib to Rust or C to use in our codebase. I think that the best solution is the first one, in any case, we'll need to wait some time to view E2E in Fractal.

Calls

Calls are easy compared to the Encryption thing, the protocol is well documented and it's really simple. The hard part here is that the call is implemented using the webRTC and that is a web protocol... But it seems that there's something done in this case with GStreamer working with webRTC.

Multiple accounts

We was talking yesterday about the multiple accounts problem, if we want to support and in that case what solution we should take.

We've two possible solutions, one is to support multiple accounts at the same time and a way to change between accounts, and the other one is to open a window for each account.

At the end we think that the best solution could be to open a separated window for each account so if you've multiple accounts, at first you should choose what account you want to open and then from the menu you can open a new window and go to the account selection menu again.

We need to work in the design of this feature and it's not confirmed but I think that this was the best solution, because it's simple and powerful.

Communities

Communities are something really new in the Matrix.org protocol and it's not well documented yet and there's some functionality that is not implemented so we decide to wait until this functionality is more mature to view how we can integrate this in Fractal.

Communities today are a group of rooms and a group of people and a full html description to show in the community page. There's other features like show a label for each member of the community or group, so I think these features are cool. We'll need to support some parts of the communities protocol soon.

Google Summer of Code

As I said this year we've two students working on Fractal thanks to Google, as part of the GNOME organization, and both students comes to the Hackfest so thank you Julian and Eisha for coming and for the work done before the GSoC and for sure for the work you'll be doing during the summer.

We're talking about how we'll be organizing, I'm the mentor of both but we'll have the help from Tobias Bernard and from Alexandre Franke so we'll have a summer hacking group to improve Fractal a lot.

We'll have a weekly meeting to talk about what we're doing and what to do in the next week.

For this first week we'll start with two needed features. Julian will be working in the user preference dialog and Eisha will start to work in the internationalization (i18n) because it's not easy to use gettext in rust and we want to translate the app to make it more accessible for everyone in the world.

Hacking a bit

In the meantime, between functionality discussion I was working in a way to use Fractal without SecretService, so if you're using Fractal outside GNOME or KDE you can configure it to store password and token in a plain text. We shouldn't store passwords in a clear text file, but I think that this will simplify the day for many people that wants to use Fractal but don't want to write the user and password every time.

This is not finished yet, but we'll have this very soon, and with this it's possible to implement other password & token storage services and make it configurable, so maybe in the future someone implements the storage for MacOS or something.

Holidays

This was my last day in the hackfest, I've the travel back to Spain the Sunday but I'll do some tourism here so I need to leave the people, they will continue working the Saturday and the Sunday.

This have been the first Fractal hackfest and it was a great experience, to meet other people working on it and to talk about the future of the application. It's really cool that with less than a year project we've now a big community, so thank you all form coming and see you on GUADEC.

There's a lot of work to do, but we're lucky because we're two students working in Fractal this summer and the people from Matrix.org and Purism are working with us, so thank you all.

I want to thank again the GNOME foundation and GNOME people for make this possible and to my company Wadobo, for let me spend some time working on this great project.

Fractal Hackfest, Strasbourg (day 1)

danigm — Fri, 11 May 2018 00:00:00 +0200

Yesterday was the first day in the first Fractal Hackfest. I'll try to write an small blog post every day to share the development with the world.

My travel to Strasbourg was not an easy travel because I've to take two flights to get here from Málaga so a long day travelling.

I met with Mathew from Matrix.org at the London airport because we took the same flight to here and it was really cool to meet him in person and we talk a little about the current Matrix situation.

I've met the other Fractal people and collaborators at the event, and it's great that people from Purism, Matrix, Gnome and the two GSoC students come here to work together in this great application.

Barbecue and Banquet

We've spend almost all the day talking about the different uses cases for the messaging problem and Tobias has come with a proposal for split the current application in two because the use case is totally different.

We've the first case when you use the app to talk to family, friends and small groups of people where all conversations are private and you want to read almost every message there, we call that situation the "Barbecue".

The second case is the one where you use the messaging app to talk in a public or private room with a lot of people, where you are receiving a lot of messages but you don't want to follow the full conversation you'll talk with someone or read a topic conversation, we call this one the "Banquet".

Currently Matrix clients are more oriented to the Banquet use case so there's a lot of people and communities using it for this. The idea behind this split is to provide two apps to the user to make both cases possible.

We need to work on this idea but it seems that is the correct way to go.

Initial Syn speed up

At the afternoon. We've reviewing the current initial sync filter and detect some points to speedup.

I changed the filter and the initial sync goes a lot faster. I've removed the member events from the initial sync so there's a lot of less information to retrieve from the server.

This little change breaks the one to one room name and default avatars because that name is calculated using the members in the room so I need to fix that making the name calculation a backend process. So now if a room has no name, We'll ask for the room member list and when we've that we'll calculate the room name with the same algorithm, if there're only two people, we'll use the other person username, if there's three people we'll use "one and another" and if there're more we'll use "one and others".

Gnome dinner

We've a good dinner sponsored by the gnome foundation. Thank you so much.

GNOME 💙 Rust Hackfest in Madrid

danigm — Thu, 26 Apr 2018 00:00:00 +0200

The last week was the GNOME 💙 Rust hackfest in Madrid. I was there, only for the first two days, but was a great experience to meet the people working with Rust in GNOME a great community with a lot of talented people.

The event was in the OpenShine office, that was a great place and the OpenShine people was very friendly too so thank you very much to OpenShine for support this kind of events.

What I did during the Hackfest

I arrive at 10:30, more or less, and there are some people there, but two or three comes after the lunch, so the first morning we started to work, each one in their project.

I've some patches for Fractal to review and I was working on the glade file splitting. After that I downloaded the gnome-class code and started to read and try to understand the code because I want to help in the gnome-class development during the Hackfest.

After the lunch, the missing people from the morning was there so we did an official "Hackfest presentation" everyone did a little presentation about his work and what want to do during the event.

Gnome-class was the main project to join GNOME and Rust, and it's still in a early alpha stage so Federico give us a little talk about what's gnome-class and its parts.

Gnome-class

Gnome-class is basically a compiler that translate custom syntax to Gobject binary compatible Rust code. Using the proc-macro, gnome-class parses a Gobject like declaration and creates all the Rust code needed to use the Glib so we can have binary code that can be called from C or from Rust. With this we can do Object Oriented programming in Rust using the Gobject library and types.

So we've three parts in gnome-class, the parser, the High-level Internal Representation (HIR) and the code generation.

gobject_gen! {
    class Counter {
      f: Cell<u32>,
    }

    impl Counter {
        pub fn add(&self, x: u32) -> u32 {
            self.get_priv().f.set(self.get() + x);
            self.get()
        }

        pub fn get(&self) -> u32 {
            self.get_priv().f.get()
        }
    }
}

#[test]
fn test() {
    let c: Counter = Counter::new();

    println!("Counter has value: {}", c.get());

    c.add(2);
    c.add(20);
    assert_eq!(c.get(), 22);

    println!("Counter has value: {}", c.get());
}

This is Rust code with gnome-class, here we're creating a new Class called Counter with two public methods, then we've a test that use this. Behind this code, gnome-class generates a lot of ugly code with pointers and so to make all of this C-Compatible and generate all the needed binary using the GObject data scheme.

My work in gnome-class

Properties declaration was not supported in gnome-class so took that task. There was a proposed syntax and I started to work in the parser to try to support that syntax and convert all the relevant information into a Rust struct in the HIR tree.

To parse that I needed to learn syn that's a parser based in nom. That was not easy, but there's a lot of code in gnome-class so I can read and learn from that and at the end of the day I had a working properties parser.

The second day I continue with my work and started to generate code. Here I have more problems because the code generated is too low level and I didn't now much about the GObject internals so I was playing around types conversions.

I've to go just after the lunch, but during the back to home train trip I was able to create a Merge Request with all the work I've done.

I've work to do during the week so I can't continue working on properties support in gnome-class. But this week I've more time and I've been working to complete the code generation, so now we've this test working:

#![feature(proc_macro)]

extern crate gobject_gen;

#[macro_use]
extern crate glib;
use gobject_gen::gobject_gen;

use std::cell::Cell;

gobject_gen! {
    class ClassWithProps {
        p: Cell<u32>,
        p2: Cell<u32>,
    }

    impl ClassWithProps {
        pub fn get(&self) -> u32 {
            self.get_priv().p.get() +
            self.get_priv().p2.get()
        }

        property MyProp: T where T: u32 {
            get(&self) -> T {
                let private = self.get_priv();
                return private.p.get();
            }

            set(&self, value: T) {
                let mut private = self.get_priv();
                private.p.set(value);
            }
        }

        property Prop2: T where T: u32 {
            get(&self) -> T {
                let private = self.get_priv();
                return private.p2.get();
            }

            set(&self, value: T) {
                let mut private = self.get_priv();
                private.p2.set(value);
            }
        }
    }
}

#[test]
fn test_props() {
    let obj: ClassWithProps = ClassWithProps::new();
    assert_eq!(obj.get(), 0);

    assert_eq!(obj.get_property_prop2(), 0);
    obj.set_property_prop2(42);
    assert_eq!(obj.get(), 42);
    assert_eq!(obj.get_property_prop2(), 42);

    obj.set_property_myprop(58);
    assert_eq!(obj.get_property_myprop(), 58);
}

My first GNOME hackfest

This was my first GNOME hackfest. I've been in different GUADECs and other events with GNOME devs, but this was the first time that I travel to work on a specific project and not just to meet the people and view talks from the distance.

It was a great experience. Rust is really new in the desktop development, but there's a lot of people working so it's great.

The next milestone is the Fractal Hackfest, we'll be in Strasbourg four days working.

I want to thank all the great GNOME community that makes collaboration so easy, it's a great community.

Currently all of my work on this is voluntary so I need to thank my coworkers at Wadobo, because I'm spending some work time in this. I can do this because my company is great.

Rust: Rust+C (parte 2), Llamando código C desde Rust

danigm — Sun, 30 Apr 2017 00:00:00 +0200

En el artículo anterior hablamos sobre la integración de Rust con C, sobre cómo llamar a código Rust desde C. Este artículo es la segunda parte sobre integración de Rust con C, donde veremos cómo hacer la operación inversa, llamar código C desde Rust.

Esto puede ser muy útil si tenemos librerías de terceros que tenemos que usar, así podemos hacer un wrapper en Rust fácilmente. En cuanto a rendimiento no es muy útil, ya que en Rust se puede escribir código tan eficiente o más que en C.

Llamando a código C desde Rust

Supongamos que tenemos una función en C, que queremos llamar desde nuestro código en Rust:

#include <stdio.h>


void repeat(char *str, int n) {
    int i;

    for (i=0; i<n; i++) {
        printf("%s\n", str);
    }
}

En el primer artículo se habla sobre cómo pasar tipos de datos más complejos, de momento, para este ejemplo tenemos tipos básicos, como un puntero a char y un int, que se traducen en Rust como *const u8 y i32.

Esta función la podemos llamar desde nuestro código Rust de la siguiente manera:

extern crate libc;

#[link(name = "cffi")]
extern {
    fn repeat(s: *const u8, n: i32);
}

fn main() {
    unsafe {
        repeat("Salida desde C\0".as_ptr(), 5);
    }
}

Lo primero a resaltar de este código Rust es el atributo "link". Esto le dice al compilador de Rust que tiene que enlazar con la biblioteca libcffi. La otra cosa que hay que tener en cuenta es el uso de unsafe. Cuando llamamos a una función en C, siempre tendremos que usar usanfe, porque ese código no está controlado por el compilador Rust y por tanto no podemos considerarlo seguro.

Si queremos limitar el uso de unsafe, la práctica recomendada es la creación de una interfaz segura:

extern crate libc;

#[link(name = "cffi")]
extern {
    fn repeat(s: *const u8, n: i32);
}

fn safe_repeat(s: &str, n: i32) {
    let st = String::from(s) + "\0";
    unsafe {
        repeat(st.as_ptr(), n);
    }
}

fn main() {
    unsafe {
        repeat("Salida desde C\0".as_ptr(), 5);
    }

    safe_repeat("Safe", 10);
}

Para este ejemplo podemos convertir la cadena a una cadena de C, terminada en \0, además de ocultar la función no segura.

Compilando código C con Cargo

Para compilar código C utilizando Cargo se puede utilizar el crate gcc, que ofrece una interfaz Rust para llamar a gcc, en combinación con el script de compilación build.rs, que es llamado por cargo por defecto antes de compilar.

Por ejemplo, si tenemos un fichero 'lib.c' y queremos que se compile cuando ejecutamos cargo build, sólo tenemos que añadir lo siguiente a los ficheros build.rs y Cargo.toml:

# Cargo.tolm
...
[build-dependencies]
gcc = "0.3"
...

/// build.rs
extern crate gcc;

fn main() {
    gcc::compile_library("libcffi.a", &["src/lib.c"]);
}

Todo el código de ejemplo se puede encontrar en github.

Integración con otros lenguajes

Esta integración con C tan sencilla por parte de Rust nos permite utilizar el gran catálogo de bibliotecas que hay en C. Pero además de esto, dado que C es el lenguaje común entre casi todos los lenguajes modernos, podemos llamar a código Rust fácilmente desde casi cualquier lenguaje, simplemente creando una interfaz C y compilando a una biblioteca en formato C.

Hay un repositorio en github donde se pueden encontrar una serie de ejemplos sencillos de integración de Rust con Python, Perl, Ruby, Haskell, etc.

Rust: Rust+C (parte 1), Llamando código Rust desde C

danigm — Sat, 22 Apr 2017 00:00:00 +0200

Rust es un lenguaje cuyo objetivo principal es sustituir o reemplazar código escrito en C o C++ con código más seguro e igual de eficiente a nivel de rendimiento.

Sin embargo, no es fácil tomar la decisión de migrar todo un proyecto escrito en C/C++ a Rust, de la noche a la mañana. En proyectos pequeños o con poca actividad, quizás sí sea fácil hacer una reescritura completa, pero en la mayoría de proyectos no es viable.

Sin embargo con Rust se puede hacer una migración incremental, implementar la nueva funcionalidad en Rust, o implementar tan sólo las partes que requieran una seguridad extra en la gestión de memoria, y esto es posible gracias a que Rust se puede integrar muy fácilmente con C y C++ con el llamado ffi o Foreign Function Interface.

Llamando a código Rust desde C

Empecemos por lo más sencillo. Supongamos que tenemos una base de código en C, y queremos comenzar una migración, reimplementando algunas partes, o alguna biblioteca interna con Rust. Esto es realmente sencillo siempre y cuando las funciones Rust sean independientes, ya que se pueden llamar directamente.

//lib.rs

#[no_mangle]
pub extern fn suma(a: i32, b: i32) -> i32 {
    println!("sumando dentro de rust {} + {}", a, b);
    a + b
}

Para poder acceder desde C a estas funciones debemos añadir algunos detalles, como el atributo "#[no_mangle]", y el modificador extern en la definición de la función.

Supongamos ahora que tenemos un código en C donde queremos hacer uso de esta función definida en Rust:

// example1.c

#include <stdio.h>

int suma(int a, int b);

int main(int argc, char **argv) {
    int a = 3, b = 2, s = 0;

    s = suma(a, b);
    printf("%d + %d = %d", a, b, s);
    return 0;
}

Como vemos, declaramos la función, suma en el código C, pero no añadimos la implementación, ya que usaremos la implementación Rust.

Para poder compilar este código C, tenemos que tener el código Rust compilado en forma de biblioteca compatible con C, podemos hacerlo como staticlib (.a) o como cdylib (.so).

$ rustc --crate-type staticlib lib.rs -o librust.a

Con esto tenemos el fichero .a compilado con la implementación de la función suma, ahora tan sólo tenemos que compilar nuestro fichero C para que haga uso de esta implementación:

$ gcc -Wl,--gc-sections -lpthread example1.c librust.a -o example1
$ ./example1

sumando dentro de rust 3 + 2
3 + 2 = 5

Devolución de tipos más complejos, structs

Trabajar con enteros es muy sencillo, ya que tenemos compatibilidad de tipos, i32 e int. Sin embargo normalmente tendremos otros tipos más complejos que querremos pasar a nuestras funciones Rust, o que querremos devolver.

En Rust se pueden definir estructuras compatibles con C añadiendo un atributo, al igual que en las definiciones de funciones, pero en este caso sería "#[repr(C)]".

use std::slice;
use std::str;

#[repr(C)]
pub struct Dato {
    n: i32,
    cadenac: *const u8,
    cadenarust: String,
    vec: Vec<i32>,
}

#[no_mangle]
pub extern fn dato_crear(n: i32, cadenac: *const u8, l: usize) -> *mut Dato {
    let mut s = unsafe {
        String::from(str::from_utf8(slice::from_raw_parts(cadenac, l)).unwrap())
    };
    s = s + ", desde Rust";
    let v = vec![n, n, n];
    let dato = Dato{n: n, cadenac: cadenac, cadenarust: s, vec: v};

    Box::into_raw(Box::new(dato))
}

#[no_mangle]
pub extern fn dato_print(dato: *mut Dato) {
    unsafe {
        println!("cadena: {}", (*dato).cadenarust);
        println!("vec: {:?}", (*dato).vec);
    }
}

#[no_mangle]
pub extern fn dato_destruir(dato: *mut Dato) {
    unsafe {
        let _ = Box::from_raw(dato);
    }
}

En este ejemplo definimos una estructura, Dato, que tiene varios campos, algunos compatibles con C, n y cadenac, y otros que no, cadenarust y vec.

Además definimos una serie de funciones que nos permitirán trabajar con esta estructura desde C, para la creación dato_crear, para acceder a elementos Rust del dato dato_print y para liberar la memoria dato_destruir.

Hay que tener en cuenta que para poder trabajar en C con esta estructura, en la creación del dato no devolvemos el dato creado, sino un puntero a este *mut Dato y además, para evitar que Rust elimine la memoria asociada a esta estructura y podamos acceder desde C, la metemos en un Box y lo convertimos a puntero into_raw.

El meter el dato en un Box, lo que hacemos es alojar esta memoria en el heap en lugar de en el stack. Luego, usando el into_raw, Rust se olvida de esta memoria y nos devuelve un puntero, así que a partir de ahora, nosotros seremos responsables de esta memoria y tenemos que tener especial cuidado, porque podremos tener memory leaks si no liberamos esto.

Para liberar esta memoria que ahora gestionamos manualmente desde Rust, podemos utilizar la operación inversa al into_raw, que es el from_raw, que hace justamente lo contrario, recibe un puntero y nos devuelve un Box, y cuando Rust elimine esta variable, la memoria se liberará, de ahí el uso de esta función en dato_destruir.

A parte de la creación y destrucción usando Box, también se define una función intermedia en Rust, que hace uso de esta estructura en código Rust, en este caso, para imprimir la cadena y el vector.

Este código está englobado dentro de un bloque unsafe, porque cada vez que dereferenciamos un puntero, el código es inseguro, y debemos marcarlo como tal. El código es inseguro, porque el compilador no puede asegurar que ese puntero que recibimos apunte realmente a memoria válida, y en esas partes dentro de unsafe es donde podríamos encontrarnos los problemas de segmentation fault y demás.

// example2.c

#include <stdint.h>
#include <stdio.h>
#include <string.h>

struct Dato {
    int n;
    char *cadenac;
};

extern struct Dato* dato_crear(int, char*, int);
extern void dato_print(struct Dato*);
extern void dato_destruir(struct Dato*);

int main (int argc, char **argv) {
    int n = 5;
    char *cadena = "Esto es una cadena C";
    struct Dato *dato = dato_crear(n, cadena, strlen(cadena));

    printf("dato: %s\n", dato->cadenac);
    dato_print(dato);

    dato_destruir(dato);
    return 0;
}

Desde C es trivial usar esta estructura y estas nuevas funciones que nos hemos definido. Tan sólo tendríamos que definir una estructura similar en código C y definir las cabeceras de las funciones. Desde C podemos acceder a los parámetros de la estructura compatibles.

Un detalle interesante es que en C no definimos todos los parámetros de la estructura original de Rust, ya que no vamos a acceder a la cadena Rust ni al vector, esto funciona porque hemos definido los parámetros compatibles primero y por tanto al acceder a la memoria es completamente compatible la estructura Rust y la estructura C.

Para la interoperabilidad entre C y Rust, existe un crate llamado libc, que define una serie de tipos que se pueden usar en Rust cuando se hace una interfaz hacia C. En los ejemplos no he utilizado el crate libc, pero sería recomendable si queremos mantener un código compatible con el mayor número de plataformas.

Todo el código de ejemplo se puede encontrar en github, con un Makefile para poder compilarlo fácilmente.

Rust: Concurrencia

danigm — Sat, 08 Apr 2017 00:00:00 +0200

La programación concurrente es algo básico a día de hoy para poder sacar el máximo rendimiento a los ordenadores modernos con múltiples cores. Sin embargo es también de lo más complejo programar cualquier cosa compartiendo memoria, hay que tener mucho cuidado y añadir semáforos y gestionar manualmente el acceso a memoria compartida, cualquier despiste puede ser un gran problema.

Rust facilita la programación concurrente con las comprobaciones que se hacen en tiempo de compilación y con la gestión de memoria que realiza, el sistema de propiedad de la memoria que implementa Rust nos asegura que no ocurrirán "data race" y esto es válido también para la programación concurrente, por lo que una vez compilado tenemos la certeza de que la gestión de la memoria compartida es correcta y que no habrá ningún "segmentation fault" porque un hilo se ejecute antes que otro y elimine la memoria compartida, etc.

Hilos

Empecemos con un ejemplo muy básico con el uso de hilos en Rust y vayamos viendo el tratamiento de las variables compartidas según lo complicamos.

use std::thread;

fn main() {
    thread::spawn(|| {
        println!("Hello from a thread!");
    });
}

ejecutar

En este ejemplo básico creamos un hilo con thread::spawn, que recibe un closure y se lanza justo al definirlo. Si ejecutamos este ejemplo no saldrá nada por pantalla, ya que el proceso inicial termina antes de que el hilo llegue a ejecutarse e imprimir. Para esperar a que un hilo termine se puede utilizar el método join.

use std::thread;

fn main() {
    let child = thread::spawn(|| {
        println!("Hello from a thread!");
    });
    let _ = child.join();
}

ejecutar

Podemos lanzar varios hilos dentro de un bucle:

use std::thread;

fn main() {
    let mut childs = vec![];

    for i in 0..10 {
        let child = thread::spawn(move || {
            println!("Hello from a thread! {}", i);
        });
        childs.push(child);
    }

    for c in childs {
        let _ = c.join();
    }
}

ejecutar

En este ejemplo ya hay varias cosas que hay que explicar, porque empezamos a compartir memoria. Creamos un Vec donde metemos todos los hilos para luego poder hacer un join y esperar a que todos terminen. Dentro del hilo imprimimos por pantalla el índice de la iteración.

Hemos tenido que añadir move en el closure del hilo, ya que si no lo usamos, el compilador se quejará de que el closure puede vivir más allá de i. Al poner el move lo que hacemos es que en lugar de borrow se hace move de las variables utilizadas dentro del closure, y en este caso nos permite utilizar i dentro del hilo.

Al ser i un entero, el move nos vale perfectamente, porque se copia la memoria, y podríamos acceder al valor de i después de lanzar el hilo sin problemas. Sin embargo si queremos compartir un String, no sería posible ya que para el siguiente hilo la cadena se ha movido.

use std::thread;

fn main() {
    let mut childs = vec![];
    let shared = String::from("Shared string");

    for i in 0..10 {
        let child = thread::spawn(move || {
            println!("Hello from a thread! {} - {}", shared, i);
        });
        childs.push(child);
    }

    for c in childs {
        let _ = c.join();
    }
}

error[E0382]: capture of moved value: `shared`
 --> src/main.rs:9:54
  |
8 |         let child = thread::spawn(move || {
  |                                   ------- value moved (into closure) here
9 |             println!("Hello from a thread! {} - {}", shared, i);
  |                                                      ^^^^^^ value captured here after move
  |
  = note: move occurs because `shared` has type `std::string::String`, which does not implement the `Copy` trait

Esto se puede solucionar clonando la cadena antes, y en este caso, no compartiremos memoria, sino que estamos usando una variable diferente para cada hilo.

Si queremos compartir realmente una referencia a memoria entre hilos tenemos que usar los tipos Arc y Mutex en combinación.

Arc / Mutex

use std::thread;
use std::sync::{Arc, Mutex};

fn main() {
    let mut childs = vec![];
    let shared = Arc::new(Mutex::new(String::from("")));

    for i in 0..10 {
        let s = shared.clone();
        let child = thread::spawn(move || {
            println!("In thread {}", i);

            let out = String::from("Thread ") + &i.to_string() + "\n";
            s.lock().unwrap().push_str(&out);
        });
        childs.push(child);
    }

    for c in childs {
        let _ = c.join();
    }

    println!("\nOutput:\n{}", *(shared.lock().unwrap()));
}

ejecutar

En este ejemplo definimos la cadena dentro de un Mutex y este dentro de un Arc, así podemos compartir realmente la memoria entre hilos.

Arc es un contador de referencias que se puede compartir entre hilos, por lo tanto, el clone no copia la memoria, sino que crea una nueva referencia.

Mutex implementa el bloqueo asociado a la variable en concreto, por lo tanto para acceder a esta variable es necesario llamar al método lock, que nos asegura que podemos leer o modificar esta variable sin que haya condiciones de carrera entre hilos.

A diferencia de otros lenguajes, el Mutex asociado a los datos hace más simple el acceso y nos asegura que no hay condiciones de carrera, ya que si no utilizamos estos tipos e intentamos compartir memoria entre hilos el compilador se quejará.

Canales

Además de compartir variables con Arc/Mutex, hay otra forma de comunicar diferentes hilos de forma relativamente sencilla, usando canales.

use std::thread;
use std::sync::mpsc;

fn main() {
    let (tx, rx) = mpsc::channel();
    let mut childs = vec![];

    for i in 0..10 {
        let tx = tx.clone();
        let child = thread::spawn(move || {
            println!("In thread {}", i);

            let out = String::from("Thread ") + &i.to_string();
            tx.send(out).unwrap();
        });
        childs.push(child);
    }

    for c in childs {
        let _ = c.join();
    }

    println!("\nOutput:");
    loop {
        match rx.try_recv() {
            Ok(x) => println!("{}", x),
            Err(_) => break
        }
    }
}

ejecutar

Con channel creamos un transmisor, tx, y un receptor, rx, en cada hilo, clonamos el transmisor y escribimos ahí nuestra salida, en el send podemos enviar cualquier tipo de dato según se cree el channel, no se pueden enviar diferentes tipos de datos por el mismo canal.

Usando el receptor se puede leer del canal, en este ejemplo leemos cuando todos los hilos han terminado, pero el método recv se puede usar en cualquier momento y bloqueará la ejecución hasta que se envíe algo por el canal.

Bibliotecas externas

Además de usar los threads básicos de Rust, existen otras muchas bibliotecas que nos ofrecen otras formas de hacer programación concurrente, aquí pongo algunos enlaces:

Rust: Macros

danigm — Sat, 01 Apr 2017 00:00:00 +0200

Rust tiene un sistema de macros muy potente que hacen que el lenguaje sea mucho más dinámico y permite reutilizar mucho código.

Una macro no es más que una "función" que define cómo se generará código, todas las macros se ejecutarán en una primera fase de la compilación, generando el código final Rust que se compilará realmente. Una macro no se traduce directamente a código máquina, sino que se expande en código fuente que luego se compila a código máquina.

Si vienes de C, habrás utilizado macros para definir funciones con un número de argumentos variables y para eso mismo se pueden usar en Rust, además de para muchos otros casos de uso.

Sintaxis

fn main() {
    println!("Hola!");
}

Si has hecho un hola mundo en Rust, ya has usado una macro. El signo de exclamación que se puede ver tras println detona que no es una función cualquiera, sino que es una macro. Gracias a esta sintaxis podemos diferenciar fácilmente lo que es una macro de lo que es una función cualquiera.

Definición de macros

Una macro se define con la palabra clave macro_rules! y contiene una sintaxis diferente al código normal de Rust.

macro_rules! imprimir {
    ($($x: expr),*) => {
        {
            $(
                print!("{}, ", $x);
            )*
            println!("");
        }
    };
}

imprimir!("hola", "mundo!"); // -> hola, mundo!,

Esta macro lo único que hace es imprimir todos los parámetros que recibe, separados por comas.

No es muy fácil de entender a primera vista, pero la definición de una macro se puede dividir en tres partes:

Definición
Matching / Parámetros
Expansión

Definición

macro_rules! imprimir {

Aquí decimos que vamos a definir una macro llamada imprimir, nada más, así se comienza la definición de una macro.

Matching / Parámetros

    ($($x: expr),*) => {

Aquí definimos los parámetros que recibe la macro. Es similar a un match, por lo que se pueden definir varios match diferentes, por ejemplo:

macro_rules! mimacro {
    () => { ... };
    ($x: expr) => { ... };
    ($x: expr, $y: expr) => { ... };
}

En este ejemplo, se define una macro que puede recibir 0, 1 o 2 parámetros, y se definiría una expansión diferente para cada uno, en este caso he omitido la expansión, porque ahora mismo no es relevante.

Si entramos en la definición de cada match, vemos que la definición de los parámetros de la macro es algo parecida a la definición de los parámetros de una función, se define un nombre $x y tras los dos puntos se define un tipo expr. Hay una serie de tipos definidos que se pueden usar en las macros:

item
block
stmt
pat
expr
ty
ident
path
tt
meta

Hay más información sobre esto en la documentación de Rust.

De momento nosotros hemos usado expr en nuestro ejemplo, que define una expresión, y esto es válido para recibir variables.

También es posible definir un número indeterminado de argumentos, osea, repetición de argumentos, con la expresión:

$(...),*

Con eso podemos decir que esperamos de 0 a n parámetros, por ejemplo:

$($x: expr),* // de 0 a n expresiones
$($x: expr, $y: expr),* // de 0 a n pares de expresiones
$($x: expr),+ // de 1 a n expresiones

Para más detalle sobre la repetición en macros, se puede consultar la sección correspondiente del libro de rust.

Expansión

Después de definir los parámetros de nuestra macro, lo que realmente nos interesa es definir la expansión, que es en lo que se va a traducir esa llamada.

macro_rules! mimacro {
    () => { println!("sin parámetros"); };
    ($x: expr) => { println!("un parámetro: {}", $x); };
    ($x: expr, $y: expr) => { println!("dos parámetros: {}, {}", $x, $y); };
}

mimacro!(); // sin parámetros
mimacro!(1); // un parámetro: 1
mimacro!(1, "hola"); // dos parámetros: 1, hola

En este simple ejemplo se puede ver que entre las llaves escribimos código Rust directamente, la llamada a la macro se transformará en el código contenido entre las llaves, dependiendo del matching de los parámetros. Lo único extraño en este ejemplo es el uso de $x y $y, que son los parámetros de la macro y que se pueden usar de esta manera en la definición de la expansión.

Volvamos al ejemplo inicial ahora:

macro_rules! imprimir {
    ($($x: expr),*) => {
        {
            $(
                print!("{}, ", $x);
            )*
            println!("");
        }
    };
}

imprimir!("hola", "mundo!"); // -> hola, mundo!,

Aquí la expansión es más compleja, en este caso, la llamada se expandirá a lo siguiente:

{
    print!("hola, ");
    print!("mundo!, ");
    println!("");
}

Las llaves y el println son directos, ahí no hay nada extraño, pero las otras dos líneas se expanden a partir de la repetición de parámetros definida con $(...)*.

Se utiliza una sintáxis similar en la expansión, para iterar sobre todos los parámetros de entrada:

$(
    print!("{}, ", $x);
)*

Esto hace que se repita lo que ha entre los paréntesis tantas veces como parámetros haya, además $x tendrá el valor del parámetro correspondiente a cada iteración.

Ámbito de las macros, importación y exportación

Las macros se expanden al principio de la compilación, por lo tanto no se ha aplicado la resolución de nombres, las importaciones y demás, así que la importación de módulos funciona un poco diferente para las macros.

Una macro es visible justo después de su definición en el mismo módulo donde se define y en todos los módulos hijos de este.

También se puede ampliar esta visiblidad usando el atributo macro_use, con el que podemos hacer visible una macro para el módulo padre.

#[macro_use]
mod mimodulo;

En el libro se puede ver un ejemplo de código con la visibilidad de las macros.

macro_rules! m1 { () => (()) }

// Visible here: `m1`.

mod foo {
    // Visible here: `m1`.

    #[macro_export]
    macro_rules! m2 { () => (()) }

    // Visible here: `m1`, `m2`.
}

// Visible here: `m1`.

macro_rules! m3 { () => (()) }

// Visible here: `m1`, `m3`.

#[macro_use]
mod bar {
    // Visible here: `m1`, `m3`.

    macro_rules! m4 { () => (()) }

    // Visible here: `m1`, `m3`, `m4`.
}

// Visible here: `m1`, `m3`, `m4`.

Cuando esta biblioteca se carga con

#[macro_use]
extern crate testlib;

Sólo se importará la macro m2.

Depuración de macros

Las macros se traducen a código Rust, por lo tanto, podemos encontrarnos con problemas de código no esperados, si tenemos un error en una macro. Para encontrar estos problemas, se puede usar la opción del compilador rustc --pretty expanded para ver cómo queda el código con las macros expandidas.

Ejemplo de macro

En python existen los decoradores, que no son más que funciones que reciben como parámetro una función y devuelven otra función como salida. Esto se puede usar para modificar el comportamiento de las funciones, añadiendo código que se ejecute antes, como comprobaciones de los parámetros, permisos, etc y es bastante útil para extender el comportamiento de cualquier función de manera fácil.

Podemos usar las macros para definirnos un decorador en Rust, que añada por ejemplo un mensaje de depuración para saber cuánto tiempo ha tardado esa llamada.

use std::time::Instant;

macro_rules! timeit {
    ($f: ident, $($x: ident : $p: ty),*) => {
        |$($x: $p, )*| {
            println!("Llamando a la función...");

            let now = Instant::now();
            let r = $f($($x,)*);
            let elapsed = now.elapsed();

            println!("Finalizado");

            let msecs = (elapsed.as_secs() * 1_000) + (elapsed.subsec_nanos() / 1_000_000) as u64;
            println!("Duración: {} ms", msecs);

            r
        };
    };
}

fn fib(x: i32) -> i32 {
    match x {
        0 => 0,
        1 => 1,
        n => fib(n - 1) + fib(n - 2),
    }
}

let nf = timeit!(fib, x: i32);
let v = nf(40);
println!("{}", v);

// Salida:
// Llamando a la función...
// Finalizado
// Duración: 685 ms
// 102334155

En este ejemplo, se recibe un primer parámetro, que es de tipo identificador, que será el nombre de la función a decorar, y luego un número indefinido de pares, identificador, :, tipo, de tal forma que definamos los parámetros que recibe esa función.

Luego la macro genera un closure, con esos mismos parámetros, y llama a la función, parándole todos los parámetros recibidos, se calcula el tiempo que pasa durante la llamada a la función y finalmente devuelve la respuesta de esta.

Con este ejemplo se puede ver el uso de diferentes tipos de parámetros para las macros, como los identificadores o los tipos, además de generar código que se puede asignar a una variable, en este caso se genera un closure.

Conclusiones

Las macros son muy potentes, pero no hay que olvidar que complican la lectura del código y también la depuración del mismo, pudiendo esconder errores, así que se deben usar con moderación y sólo cuando lo que queremos hacer no se pueda generalizar con funciones normales, ya que en la mayoría de los casos será mucho más fácil de depurar si hay algún comportamiento extraño y además, será mucho más fácil de entender el código.

Rust: Implementación de estructuras complejas (Grafo)

danigm — Sat, 25 Mar 2017 00:00:00 +0100

Con el cambio de paradigma que supone la gestión de memoria de Rust, una de las cosas que pueden resultar más difíciles al principio es la definición de estructuras de datos "complejas", con el concepto de propiedad de memoria y referencias, definir cosas como una lista enlazada no es tan "sencillo" como en C.

Por supuesto esto no es sencillo porque definir este tipo de estructuras de forma segura es muy complejo, en C es muy fácil definir lo básico, con punteros, pero también es muy fácil que una lista enlazada apunte a un nodo eliminado, etc.

Voy a explicar diferentes aproximaciones para implementar una estructura cíclica en Rust, en este caso, vamos a definir un grafo.

He creado un repositorio en github con el código para que se pueda estudiar. En este artículo pondré partes del código para mostrar lo básico de la implementación, pero sobretodo me centraré en explicar la teoría detrás de cada solución.

Problema

Queremos implementar una estructura de datos sencilla para manejar grafos dirigidos.

Un grafo no es más que una lista de vértices conectados entre sí. Cada nodo tiene un valor, y una lista de nodos a los que apunta.

Podemos pensar en una primera implementación donde definamos cada nodo, con su valor y que tenga una lista de nodos hijos.

struct GraphNode<T> {
    value: T,
    childs: Vec<GraphNode<T>>,
}

Pero dada la gestión de memoria que se hace en Rust, esta estructura no nos valdría de mucho, ya que tendríamos que tener una copia diferente de un nodo para cada referencia, añadimos un nodo a otro, y luego intentamos usarlo, no podremos, porque será el nodo padre el que tenga la propiedad de sus hijos.

Con esta solución en realidad cada nodo es independiente, no se reutilizan, por lo que deja de ser útil para nuestro caso.

Lo primero que se nos ocurre para solucionar este problema es usar referencias:

struct GraphNode<T> {
    value: T,
    childs: Vec<&GraphNode<T>>,
}

Pero esto no compila, al usar referencias el compilador nos pide que definamos el lifetime de estas referencias, y al ser una estructura recursiva, se complica mucho el tema, los nodos se deben almacenar en alguna parte y ser referenciados entre sí, además, dado que en rust no es compatible tener referencias no mutables a la vez que una referencia mutable, no podríamos modificar estos nodos hijos por la referencia.

Usando punteros, unsafe

Una primera solución que se nos puede ocurrir es tirar directamente de punteros tipo C. Rust nos da la posibilidad de acceder a la memoria como en C, con punteros, de esta forma nos podemos saltar las limitaciones del compilador de Rust, pero esto implica que también perdemos la gestión de memoria, por lo que tendremos que controlar nosotros la memoria y perdemos la seguridad que nos proporciona el compilador.

El uso de punteros en Rust nos obliga a usar el calificador unsafe, para poder diferenciar de forma rápida el código seguro, donde la gestión de memoria se comprueba en tiempo de compilación, del código inseguro, que es código donde la memoria se gestiona de manera manual.

pub struct GraphNode<T> {
    pub value: T,
    pub childs: Vec<*mut GraphNode<T>>,
}

El tipo de dato Box nos permite convertir a puntero o desde puntero de forma sencilla con los métodos into_raw y from_raw.

pub fn add_child(&mut self, node: &mut GraphNode<T>, value: T) -> *mut GraphNode<T> {
    let n = Box::new(GraphNode::new(value));
    let pointer = Box::into_raw(n);
    node.childs.push(pointer);
    pointer
}

Y podemos acceder al valor de un puntero utilizando el operador * para deferenciar el puntero.

unsafe {
    (*node).value
}

Con into_raw Rust deja la gestión de la memoria en nuestras manos, por lo que para evitar memory leaks tenemos que destruir esa memoria en algún momento, y para ello podemos usar el from_raw que hace la operación inversa y devuelve a Rust la gestión de esa memoria.

Usando referencias, Rc<RefCell<Node>>, Arc<Mutex<Node>>

El uso de punteros es algo de lo que queremos huir cuando usamos Rust, ya que es código menos seguro. Por eso debemos dejar el uso de punteros sólo para momentos en los que necesitemos eficiencia a nivel de memoria o velocidad y sepamos exactamente lo que estamos haciendo.

En Rust hay una estructura que nos ofrece la posibilidad de implementar algo similar a los punteros, el contador de referencias. El patrón básico para permitir modificaciones de elementos interiores, es la composición Rc<RefCell<T>>.

use std::cell::RefCell;
use std::rc::Rc;

type GraphNodeRef<T> = Rc<RefCell<GraphNode<T>>>;

pub struct GraphNode<T> {
    pub value: T,
    pub childs: Vec<GraphNodeRef<T>>,
}

De esta forma podemos hacer un uso exactamente igual al de los punteros, pero con la seguridad de que no tendremos problemas de seguridad de memoria.

pub fn add_child(&mut self, node: GraphNodeRef<T>, value: T) -> GraphNodeRef<T> {
    let n = GraphNode::new(value);
    let rnode = Rc::new(RefCell::new(n));
    node.borrow_mut().childs.push(rnode.clone());
    rnode
}

En lugar de usar * para deferenciar los punteros, en este caso usamos borrow y borrow_mut para obetener una referencia. Con el método clone, el tipo Rc crea una referencia nueva, no duplica la información en sí, y cuando se queda sin referencias es cuando se elimina el contenido.

Esta solución nos permite hacer algo muy parecido a lo que hacemos con punteros, pero sin preocuparnos de tener que eliminar la memoria o de que hay overflow o lo que sea.

Sin embargo, esto no es la panacea, hay un problema si se generan ciclos, ya que las referencias cíclicas no se eliminarán nunca, no es algo muy grave, pero hay que tenerlo en cuenta, aunque ya hay alguien que ha implementado un recolector de basura para estos casos.

De forma similar, en caso de querer que sea thread safe, se puede usar Arc<Mutex<T>>.

Usando una estructura básica e identificadores de nodos, Vec, HashMap

Otra posible aproximación puede ser usar una estructura básica de Rust, como un Vec o un HashMap, para almacenar todos los elementos, y luego definir las referencias de los nodos usando índices a esta estructura.

Por ejemplo podríamos definir un vector con todos los nodos de nuestro grafo, y cada nodo define sus hijos como índices en ese vector, números enteros.

pub struct Graph<T> {
    pub nodes: Vec<GraphNode<T>>,
    pub idx: u32,
}

pub struct GraphNode<T> {
    pub value: T,
    pub childs: Vec<u32>,
}

En el código de ejemplo he usado HashMap en lugar de Vec, porque si por ejemplo queremos poder eliminar un nodo de forma fácil, en un Vec tendríamos que recorrer todo el vector y cambiar los indices de todos los nodos con cada cambio.

use std::collections::HashMap;

pub struct Graph<T> {
    pub nodes: HashMap<u32, GraphNode<T>>,
    pub idx: u32, // índice del siguiente nodo que se añada
}

pub struct GraphNode<T> {
    pub value: T,
    pub childs: Vec<u32>,
}

Con esta implementación, para nosotros los nodos serán enteros, y nos podemos definir los métodos que hagan uso de estos índices.

pub fn add_child(&mut self, node: u32, value: T) -> u32 {
    let n = GraphNode::new(value);
    let idx = self.idx;

    self.nodes.insert(idx, n);
    self.idx += 1;

    self.nodes.get_mut(&node).unwrap().childs.push(idx);
    idx
}

De esta forma, todo el código será seguro y además no utilizamos referencias, simplemente nos estamos implementando nuestros propios punteros. Aquí tenemos el compilador que comprueba la seguridad de la memoria, pero si no manejamos correctamente los índices enteros, podemos tener algún que otro panic, aunque siempre es mejor un panic que un segmentation fault, un painc es algo controlable y no da los mismos problemas que podría dar un overflow.

Conclusiones

Este ejemplo nos sirve para conocer diferentes formas de resolver un problema, con las herramientas que nos da Rust, pero también nos muestra que no sólo hay una solución correcta a un problema, se puede pensar de manera diferente e implementar.

Para mi, en principio la manera más natural es la de Rc<RefCell>>, viniendo de usar C y C++ y pensando en no usar punteros, pero después de investigar, veo que la opción de usar el HashMap no me parece ninguna locura, y se me ocurren otras formas de almacenar un grafo en memoria.

Por supuesto no soy un experto en este tipo de implementaciones y quizás esté haciendo alguna locura, si ese es el caso, no dudes en comentar y corregir cualquier gazapo.

Rust: Documentación

danigm — Sat, 18 Mar 2017 00:00:00 +0100

He hablado en este blog sobre casi todas las partes importantes de Rust, he puesto muchos ejemplos de código y con esta información, cualquiera podría empezar a escribir código que funcione. Pero a la hora de hacer algo de verdad, de escribir una biblioteca o un programa que pueda ser usado por otra persona o mantenido en un futuro es imprescindible la documentación y por supuesto los tests unitarios.

Podemos escribir código sin documentación y sin tests, pero mantener ese código es mucho más difícil y que otra persona lo use también, ya que si no está debidamente documentado tendrá que irse al código y entender qué es lo que hace cada función.

Rust ofrece por defecto una forma de documentar y de implementar tests bastante simple, además, la norma de un buen código Rust requiere que todo método público esté documentado, por lo que si seguimos esta norma, tendremos un código más mantenible. El tener la documentación y los tests tan bien definidos desde el inicio ha provocado que la mayoría de las bibliotecas existentes a día de hoy estén bien documentadas y tengan una serie de tests definidos, y todo ello va junto con el código fuente siempre.

La documentación en Rust se genera a partir de comentarios en el código, comparado con python, sería algo similar a los docstrings. Se escribe en formato Markdown y con herramientas como cargo se pueden generar la documentación en html fácilmente.

Documentando

Los comentarios de documentación en Rust no son iguales que los comentarios normales de código. Los comentarios normales son similares a los comentarios en C, pero se definen otros comentarios definidos con /// y con //!, que sí son documentación.

La diferencia entre //! y /// es que el primero se documenta el elemento que lo engloba, mientras que el segundo documenta el elemento que viene justo después. Normalmente se usa el primero para documentar módulos, ya que se suele escribir ese comentario al principio del fichero, y las estructuras y métodos se documentan con /// poniendo la documentación justo antes de la implementación.

Generando la documentación con cargo

Con cargo se puede generar la documentación muy fácilmente, simplemente hay que lanzar el comando cargo doc y esto generará toda la documentación en HTML en el directorio target/doc

$ cargo doc
$ ls target/doc

Documentación de módulos

Si tenemos un módulo definido en un fichero, se puede documentar tal que así:

/// Módulo de ejemplo para explicar cómo funciona la documentación
/// en Rust.
pub mod ejemplo {
    ...
}

Sin embargo, normalmente los módulos se definen en ficheros independientes y la documentación se suele poner al principio de cada módulo:

//! Módulo de ejemplo para explicar cómo funciona la documentación
//! en Rust.

fn funcion() {
    ...
}
...

Secciones en la documentación

En la documentación se pueden definir diferentes secciones, para separar la documentación y que se muestre de manera diferente. Estas secciones se definen como encabezados Markdown (# Examples), y lo que viene debajo pertenece a esa sección.

Estas son las secciones especiales que se definen en Rust:

Panics, si pueden ocurrir errores que no son recuperables, osea, que terminan la ejecución.
Errors, cuando se devuelve un Result, es conveniente documentar qué tipos de errores se pueden devolver y cuando.
Safety, esto es más raro de encontrar, pero si una función es unsafe es conveniente explicar el porqué.
Examples, esto es lo más común y recomendable en todo método. Aquí se pueden definir ejemplos de código, que además funcionarán como tests unitarios.

No es obligatorio, pero sí recomendable el rellenar cada una de estas secciones, siempre y cuando tenga sentido, en la documentación de tus métodos, ya que facilitará la tarea a futuros usuarios.

Tests en la documentación

Como hemos visto, la sección Examples sirve para definir ejemplos de código que se verán en la documentación, bien formateados, pero que además sirven como tests unitarios.

/// Comprueba si un número es mayor que 3
///
/// Se devuelve verdadero si *x* es mayor que 3,
/// en otro caso se deuvelve falso.
///
/// # Examples
///
/// Ejemplo básico
///
/// ```
/// use geometry::mayor3;
/// assert_eq!(mayor3(2), false);
/// assert_eq!(mayor3(3), false);
/// assert_eq!(mayor3(4), true);
/// ```
///
/// Más ejemplos
///
/// ```
/// use geometry::mayor3;
/// let mut n = 1;
/// assert_eq!(mayor3(n), false);
/// while !mayor3(n) {
///     n += 1;
/// }
/// assert_eq!(n, 4);
/// ```
pub fn mayor3(x: i32) -> bool {
    x > 3
}

En este ejemplo se puede ver cómo se documenta una función, con un par de ejemplos.

Podemos ver cómo quedaría esta documentación en el HTML generado:

Ejecutando los tests con cargo

Como he comentado anteriormente, los ejemplos de código definidos en la documentación también hacen la función de tests unitarios. Para ejecutar los tests tan sólo hay que usar la herramienta cargo test:

$ cargo test
    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
     Running target/debug/deps/geometry-d942cf2b29083ab0

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

   Doc-tests geometry

running 2 tests
test mayor3_0 ... ok
test mayor3_1 ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured

Si eres buen observador, habrás visto que en los tests se mete la importación del módulo en concreto, use geometry::mayor3, esto es así porque para ejecutar los tests de la documentación, lo que hace cargo es crear un nuevo fichero rust con ese código, y lo mete todo dentro de un fn main, si no está definido. Por lo tanto, todo el código que se escriba en un test ha de estar como si estuviera en un fichero independiente.

En ocasiones no queremos mostrar en la documentación todas las importaciones, o definiciones, sólo la parte importante, pero si hacemos eso, los tests no funcionarán. Para esos casos, se puede comenzar cada línea de código a ocultar en la documentación con #, de tal forma que se ejecutará en los tests, pero no aparecerá en la documentación, por ejemplo:

/// ```
/// # use geometry::mayor3;
/// let mut n = 1;
/// assert_eq!(mayor3(n), false);
/// # while !mayor3(n) {
/// #     n += 1;
/// # }
/// # assert_eq!(n, 4);
/// ```
pub fn mayor3(x: i32) -> bool {
...

Con esta documentación, el test seguiría siendo el mismo, pero sólo se muestra en la documentación generada lo que no está "comentado", quedando tal que así:

Extra: Esconder la documentación en vim

Con la documentación y los tests incluidos, los ficheros de código se vuelven muy grandes rápidamente y navegar por ellos se vuelve un poco complejo.

Creo que viene muy bien que la documentación y el código estén en el mismo fichero, y juntos, ya que si se cambia el código no nos olvidaremos de cambiar la documentación y por tanto es mucho más fácil mantener esta documentación consistente. Además para cualquiera que lea el código, y no sea un desarrollador avanzado, le vendrá muy bien esa documentación.

Sin embargo, cuando ya conoces un código y estás modificando un fichero cualquiera, tener que navegar por todo el fichero con tantos comentarios, es un poco engorroso, normalmente quieres ocultar esos comentarios para centrarte en el código.

Para ello tengo definido en el vim una función para que agrupe los comentarios con fold:

setlocal foldmethod=expr
setlocal foldexpr=GetRustFold(v:lnum)

function! IndentLevel(lnum)
    return indent(a:lnum) / &shiftwidth
endfunction

function! GetRustFold(lnum)
    if getline(a:lnum) =~? '\v^\s*$'
        return '-1'
    endif

    let this_indent = IndentLevel(a:lnum)

    if getline(a:lnum) =~? '^\s*///.*$'
        if this_indent == '0'
            return '1'
        endif
        return this_indent
    endif

    if getline(a:lnum) =~? '^\s*//!.*$'
        if this_indent == '0'
            return '1'
        endif
        return this_indent
    endif

    return '0'
endfunction

Por ejemplo, si abro el fichero de string.rs:

Y puedo desplegar o contraer los comentarios a mi gusto con za.

Conclusiones

Hay muchas cosas sobre documentación en Rust que no he comentado por aquí y que se pueden encontrar en la documentación oficial. Lo que he contado es lo básico y la forma más sencilla de empezar a documentar y a probar el código.

Como ejemplo de documentación más completa, se puede mirar cualquier crate de Rust, en github hay mucho código Rust, que está documentado de esta manera. Por ejemplo la biblioteca para leer epubs que yo mismo he implementado define la documentación y los tests de esta forma.

Y como resultado de la documentación, pues se puede mirar la documentación de std de Rust, por ejemplo, se puede mirar el código de String y comparar con la documentación html.

Rust: Pattern Matching

danigm — Sat, 11 Mar 2017 00:00:00 +0100

En Rust se utiliza mucho la búsqueda de patrones, más conocida como pattern matching. Es una estructura lógica en el código que permite hacer varias cosas diferentes de una forma muy sencilla. Se puede usar por ejemplo para hacer algo similar al switch de lenguajes como C/C++, pero también se puede usar para asignaciones complejas, descomposición de estructuras comprobación de errores, etc.

Con el pattern matching lo que se hace, básicamente, es definir condiciones o asignaciones en función de un patrón. Se podría decir que es algo similar a las expresiones regulares, pero más simple, y aplicado a la escritura de código.

En este artículo definiré el uso principal en Rust, que es el uso dentro de los match, y también otros usos, como la asignación o la asignación condicional.

Match

Match es una expresión condicional en Rust. Se aplica sobre una variable y se definen una serie de patrones, y sólo se ejecuta el código correspondiente al patrón que concuerde con la variable.

El uso principal que se le puede dar a match es el de condición múltiple, tenemos una estructura if/else if/else if, que podemos simplificar con una sola expresión.

let x = 5;
match x {
    1 => println!("uno"),
    2 => println!("dos"),
    3 => println!("tres"),
    4 => println!("cuatro"),
    5 => println!("cinco"),
    _ => println!("> 5"),
}

ejecutar

Con este match, tenemos la condición múltiple, comprobamos un entero y según el que sea se imprime ese número en texto.

Como se puede ver en el ejemplo, se usa el operador => para diferenciar el patrón y lo que se ejecuta si se cumple. Lo que se ejecuta no tiene por qué ser una sola línea, se pueden ejecutar varias sentencias englobándolo en unas llaves.

let x = 5;
match x {
    1 => println!("uno"),
    2 => println!("dos"),
    3 => println!("tres"),
    4 => println!("cuatro"),
    5 => {
        println!("cinco");
        println!("el valor es {}", x);
    }
    _ => println!("> 5"),
}

El match también es muy usado para asignaciones, devuelve lo que se devuelva dentro de las condiciones, por lo tanto se puede usar en una asignación let.

let x = 5;
let number = match x {
    1 => "uno",
    2 => "dos",
    3 => "tres",
    4 => "cuatro",
    5 => {
        println!("detro del match");
        "cinco"
    }
    _ => "> 5",
};
println!("{:?}", number);

ejecutar

Además de patrones simples de enteros o cadenas, en el match se pueden usar Enums, estructuras y otras composiciones que lo hacen bastante más potente, veamoslo con más detalle en el apartado de Patrones.

Hay que tener en cuenta que los patrones han de ser completos, es decir, han de cubrir todas las posibilidades de la variable sobre la que se hace match. Otra cosa importante es que se ejecutan de arriba hacia abajo, por lo que la definición ha de ser de más concreto a más genérico siempre, ya que si no, el compilador se quejará porque existen patrones que nunca se alcanzarán.

Patrones

Como hemos visto con el match, los patrones se pueden definir con literales directamente, y el caso de _, que se explica más adelante.

Además de la comprobación con literales, los patrones pueden definir nuevas variables, que se pueden usar dentro del match.

let x = 5;
match x {
    n => println!("El valor de x es {}", n)
}

En este caso, al no poner un literal en la parte izquierda de la expresión, en el patrón, se hace el matching y se asigna el valor de x a n. Hay que tener cuidado con esto, porque es lo mismo que una asignación con let, en el caso de que el tipo implemente Copy se hará una copia, en otro caso se hará un move. Para modificar estos comportamientos se pueden usar ref y ref mut, pero eso lo veremos más adelante.

Múltiples patrones

Se pueden definir múltiples patrones que ejecuten la misma secuencia, esto podría verse como algo similar a lo que se hace en los switch cuando se deja un case vacío, que sabes que se ejecutará lo mismo para este y para el siguiente.

let x = 5;
match x {
    1 | 2 => println!("uno o dos"),
    _ => println!("otro número"),
}

Se utiliza el operador | para definir patrones múltiples. Se intenta hacer matching con la primera parte del | y si no, se intenta con la segunda, si alguno de los dos patrones concuerdan con el valor, se ejecuta la sentencia.

Descomposición

El pattern matching es muy útil cuando estamos usando estructuras más o menos complejas o enums, ya que permite descomponer el valor de forma fácil y acceder a componentes de estas estructuras de forma directa.

struct Complex {
    real: i32,
    img: i32,
};

let x = Complex{real: 5, img: 3};
match x {
    Complex{real: _, img: 0} => println!("parte imaginaria es 0"),
    Complex{real: r, img: i} => println!("{},{}i", r, i),
}

ejecutar

En este ejemplo se define una estructura compleja, con dos valores enteros, y en el match se puede ver cómo se descompone, pudiendo acceder de forma rápida y sencilla a los valores correspondientes. En el primer patrón se ignora la parte real y se obliga a que la parte imaginaria sea 0, y en el segundo patrón entraría cualquier otra cosa, y tenemos acceso a r e i con los valores en concreto del valor de x.

La descomposición se puede usar para gestión de errores con los enums Option y Result, teniendo expresiones del tipo:

match x.get(0) {
    Some(v) => println!("valor {}", v),
    None => println!("no existe"),
}
match somecall() {
    ok(v) => println!("resultado {}", v),
    err(_) => println!("ha ocurrido un error"),
}

Ignorando variables o componentes

En los ejemplos anteriores ya hemos ignorado algunas variables, que en un caso concreto no nos interesan dentro del match, para ello se usa el operador _.

En otras ocasiones, dentro de una descomposición, por ejemplo, queremos ignorar todos los elementos de este, o una parte y para eso existe el operador ...

struct Complex {
    real: i32,
    img: i32,
};

let x = Complex{real: 5, img: 3};
match x {
    Complex{real: _, img: 0} => println!("parte imaginaria es 0"),
    Complex{..} => println!("Cualquier complejo"),
}

El operador .. se puede usar como en el ejemplo, para ignorar todo, o para ignorar sólo parte, si tuviéramos una estructura más compleja, con 5 variables, por ejemplo, y sólo nos interesa una:

struct SuperComplex {
    real: i32,
    img: i32,
    real1: i32,
    img1: i32,
    real2: i32,
    img2: i32,
};

let x = SuperComplex{real: 5, img: 3, real1: 6, img1: 4, real2: 2, img2: 8};
match x {
    SuperComplex{img1: 0, ..} => println!("parte imaginaria 1 es 0"),
    SuperComplex{..} => println!("Cualquier complejo"),
}

Referencias (ref, ref mut)

Cuando se definen nuevos nombres en el match, se crean nuevas variables, de forma similar a cuando se hace un let, y por lo tanto, entra en juego la gestión de memoria. Por defecto se hace un move, pero habrá ocasiones en las que no queramos eso, sino que queramos una referencia, para evitar que la variable se destruya tras el match. Para eso se pueden usar las palabras clave ref y ref mut.

struct Complex {
    real: i32,
    img: i32,
};

let x = Complex{real: 5, img: 3};
match x {
    Complex{real: _, img: 0} => println!("parte imaginaria es 0"),
    ref a => println!("Cualquier complejo {}, {}i", a.real, a.img),
}

println!("parte real: {}", x.real);

En este ejemplo definimos el patrón ref a, por lo tanto, a es del tipo &Complex y al ser una referencia, se puede usar x después del match sin problemas. Si eliminamos el ref, el compilador nos daría un error, ya que en el match se movería el valor de x a a y por tanto ya no se podría usar x después del match.

Rangos (Ranges)

Con el uso de literales enteros y caracteres existe una definición que permite definir de forma simple un rango de valores, para ello se usa el operador ....

let x = 5;
match x {
    1 ... 10 => println!("entre uno y diez"),
    _ => println!("mayor que diez"),
}

let x = 'A';
match x {
    'a' ... 'z' => println!("minúscula"),
    'A' ... 'Z' => println!("mayúscula"),
    _ => println!("otra cosa"),
}

Enlaces (Bindings)

Se pueden asignar variables a patrones, no sólo como hemos visto en la descomposición, sino de manera global, ya sea a patrones literales, o al global de una descomposición, y para ello se usa el operador @:

let n = 5;
match n {
    i @ 1 ... 9 => println!("{} es menor de 10", i),
    _ => println!("mayor de 10"),
}

struct Complex {
    real: i32,
    img: i32,
};

let x = Complex{real: 5, img: 3};
match x {
    Complex{real: _, img: 0} => println!("parte imaginaria es 0"),
    ref a @ Complex{..} => println!("Cualquier complejo {}, {}i", a.real, a.img),
}

println!("parte real: {}", x.real);

Hay que tener en cuenta que si se usan múltiples condiciones con |, el binding se aplica a una parte, no al conjunto:

let x = 5;
match x {
    i @ 1 | i @ 2 => println!("{}: uno o dos", i),
    _ => println!("otro número"),
}

Condicionales (Guards)

En los patrones también se pueden definir condicionantes, de tal forma que sólo se ejecute la sentencia correspondiente si se aplica el match y además si se cumple cierta condición.

let x = 5;

match x {
    i if i < 5 => println!("{}: es menor que 5", i),
    _ => println!("otro número"),
}

Los condicionales se definen con if y detrás la condición que se quiera comprobar, además se pueden usar las variables que defina el patrón para la condición, por lo que nos proporcionan una gran potencia a la hora de definir patrones.

En las condiciones múltiples con | el if se aplica sobre las dos partes de la condición, por lo tanto no se pueden definir varios if en un mismo patrón.

Otros usos de los patrones

Además de para el match, los patrones se usan en Rust en diferentes partes.

If let

En muchas ocasiones, nos encontramos con variables que son del tipo Option o Result y queremos hacer algo, sólo si tienen un valor, por ejemplo:

if x.is_some() {
    println!("{}", x.unwrap());
}

Para simplificar este caso existe el if let que unifica la asignación y el condicional en una sola línea, teniendo algo que sólo se ejecuta si el patrón se aplica correctamente:

if let Some(v) = x {
    println!("{}", v);
}

Asignación

Los patrones también se pueden usar directamente en las asignaciones con let. Esto es realmente útil cuando lo combinamos con una descomposición de una lista o una estructura:

let (a, b) = (1, 2);

struct Complex {
    real: i32,
    img: i32,
};

let x = Complex{real: 5, img: 3};

let Complex{real: r, ..} = x;
println!("parte real: {}", r);

Como se puede ver, el pattern matching es algo muy utilizado en Rust y bastante potente, con lo que se puede escribir código simple que haga cosas increíbles.

Rust: Tipos nulos (Option) y gestión de errores (Result)

danigm — Sat, 04 Mar 2017 00:00:00 +0100

Option, Tipos nulos

En rust no existe el tipo especial null, como en C/C++, y al ser fuertemente tipado, no se puede asignar algo de diferente tipo a una variable, por lo tanto no es posible tener variables declaradas de un tipo, por ejemplo File y que valga null si no está inicializado o algo así, ni tampoco se puede devolver null o algo así, como se haría en C++, en una función que declara como valor de retorno un tipo, y por alguna razón no tiene sentido para una entrada determinada.

Lo que se usa en rust para solucionar este tipo de problemas y poder asignar valores nulos a variables o en devoluciones es el enum Option, que se define como:

pub enum Option<T> {
    None,
    Some(T),
}

None sería el tipo nulo en rust, y Some(T) sería cuando tenemos un valor. Por lo tanto, si queremos declarar una variable que en principio pueda ser nula, la declararemos como Option:

struct User<'a> {
    username: &'a str,
    email: Option<&'a str>,
}

fn send_email(u: &User) {
    match u.email {
        Some(email) => println!("correo para {}", email),
        None => println!("{} no tiene correo asignado", u.username)
    }
}

fn main() {
    let mut u = User{ username: "danigm", email: None };
    send_email(&u);

    u.email = Some("danigm@wadobo.com");
    send_email(&u);
}

ejecutar

En este ejemplo, declaramos una estructura con dos atributos, el nombre de usuario que es de tipo &str y el email, que es de tipo Option<&str>, para poder tener usuarios que no tengan email asociado.

En la función send_email se utiliza el match para diferenciar si el valor es None o si tiene una cadena asociada y se actúa en consecuencia.

Además de poder diferenciar el tipo Option con patter matching, también dispone de algunos métodos que se pueden llamar para ver si tiene un valor o no:

if u.email.is_some() {
    println!("email definido: {}", u.email.unwrap());
}

if u.email.is_none() {
    println!("email no definido");
}

println!("email: {}", u.email.unwrap_or("no definido"));

En este ejemplo se usan los métodos is_some e is_none, que te devuelven un bool si el tipo es lo que preguntamos, y también se usan el unwrap, que lo que hace es devolver el valor dentro del Some, por lo que daría un panic si el Option es None. Y por último también se usa el unwrap_or, que es similar al unwrap, pero que no fallaría en caso de ser None, sino que devolvería el valor definido.

En la documentación de Option vienen todos los métodos y es recomendable echarle un vistazo porque hay muchos que son muy interesantes.

Result, Gestión de errores

En rust no existen excepciones, como en python y otros lenguajes, para gestionar los errores, ni tampoco se hace como C, que realmente no tiene gestión de errores alguna, sino que se usa el valor de retorno para indicar errores, devolviendo números negativos, por ejemplo, o 0, o algo similar.

En rust la gestión de errores se hace usando el tipo de retorno, pero no devolviendo un valor determinado, sino devolviendo un tipo Result, que te obliga a comprobar si ha funcionado bien antes de poder usar el valor devuelto, evitando así problemas de uso de variables no inicializadas y demás.

El tipo Result es muy similar al Option, que hemos visto anteriormente, la única diferencia es que el Result se define con dos tipos genéricos, el de la respuesta y el del error, para poder especificar el tipo de error:

pub enum Result<T, E> {
    Ok(T),
    Err(E),
}

Es un simple enum, por lo tanto un Result puede ser o un Ok(T) o un Err(E)

struct User<'a> {
    username: &'a str,
    email: Option<&'a str>,
}

fn transform_email(u: &User) -> Result<String, String> {
    match u.email {
        Some(email) => {
            let s = email.split('@').nth(0).unwrap();
            Ok(String::from(s) + "@newdomain.com")
        },
        None => Err(String::from("email no definido"))
    }
}

fn main() {
    let mut u = User{ username: "danigm", email: None };

    let ret = transform_email(&u);
    match ret {
        Ok(email) => println!("Este es el nuevo email: {}", email),
        Err(error) => println!("Error: {}", error)
    }

    u.email = Some("danigm@wadobo.com");
    if let Ok(email) = transform_email(&u) {
        println!("Nuevo email: {}", email);
    }
}

ejecutar

En este ejemplo se define la función transform_email, que devuelve un Result con el tipo String para el Ok y también para el Err. En este caso he usado este tipo para los dos posibles valores, pero normalmente el tipo de error implementa el trait Error.

En la función lo único que hacemos es mirar si está definido, haciendo un match al email y en caso de estar definido devolvemos Ok(...) con la cadena transformada, y en el caso de error devolvemos Err(...) con un mensaje de error.

Luego a la hora de usarlo, al ser el valor devuelto de tipo Result y no de tipo String, nos obliga a comprobar si la llamada ha sido correcta antes de poder usar el valor de retorno real. Por lo tanto hay que hacer un pattern matching y actuar en consecuencia si es un error o si es un valor correcto.

Al igual que el Option, el tipo Result tiene métodos similares definidos, como el is_ok, is_err, unwrap, unwrap_or, etc.

Propagación de errores

Esta forma de gestionar errores es muy simple, pero al obligarte a comprobar el tipo de respuesta de cada llamada que devuelve un Result, hace que se introduzca mucho código de comprobación de errores en todas las funciones, y normalmente lo que queremos es que si va bien continuamos y si va mal, devolvemos un error, osea, propagamos el error hacia arriba, como se haría en python con un raise, como funcionan las excepciones.

Para eso existe la macro "try!" en Rust que simplifica el código, y recientemente también han añadido el nuevo operador ? que hace lo mismo que la macro try!, pero a nivel de compilador, por lo que es recomendable usar este último. Sin embargo voy a mostrar código con las dos posibilidades, porque supongo que aún habrá mucho código rust por ahí que usa la macro try!.

use std::slice::Iter;

struct User<'a> {
    username: &'a str,
    email: Option<&'a str>,
}

fn transform_email(u: &User) -> Result<String, String> {
    match u.email {
        Some(email) => {
            let s = email.split('@').nth(0).unwrap();
            Ok(String::from(s) + "@newdomain.com")
        },
        None => Err(String::from("email no definido"))
    }
}

fn transform_all_emails(users: Iter<&User>) -> Result<(), String> {
    for u in users {
        let new = transform_email(u)?;
        println!("{} new email: {}", u.username, new);
    }

    Ok(())
}

fn main() {
    let mut u = User{ username: "danigm", email: None };
    let u2 = User{ username: "user2", email: Some("user2@wadobo.com") };

    if let Err(e) = transform_all_emails(vec![&u, &u2].iter()) {
        println!("Error: {}", e);
    }

    u.email = Some("danigm@wadobo.com");
    if let Err(e) = transform_all_emails(vec![&u, &u2].iter()) {
        println!("Error: {}", e);
    }
}

ejecutar

En este ejemplo, además de lo anterior, he definido otra función que transforma todos los emails de una lista de usuarios y devuelve un Result con la lista vacía si todo ha ido bien, o con un mensaje de error si algo ha fallado. Dentro de esta función no hay un return Err por ninguna parte, sin embargo se hace en la línea:

    let new = transform_email(u)?;

El operador ? lo que hace es básicamente un match de la respuesta, si es Ok(t), devuelve t, si es un Err(e), hace un return Err(e), por lo que el error se propaga hacia arriba, y el código que hay detrás puede suponer que el valor de new es un String.

Como he comentado antes, el operador ? es relativamente nuevo, el mismo código usando la macro try! sería:

    let new = try!(transform_email(u));

El operador ? sólo se puede usar dentro de funciones de devuelvan un Result y que tengan como tipo de error el mismo o compatible con las funciones que lo usan, ya que se va a hacer un return directamente del error devuelto y por tanto esos tipos tienen que coincidir.

Propagación de errores con Option

El operador ? sólo vale para el tipo Result, sin embargo, el tipo Option es muy similar y es muy típico que en una función o método sólo se pueda continuar si el Option tiene valor, es decir, si no es None, por lo tanto, puede ser interesante poder propagar los errores de forma sencilla sin tener que hacer el match y el return.

Para eso se puede utilizar el método ok_or del tipo Option, que lo que hace es devolverte un Result con el valor si es Some(t) y en caso de ser None te devolverá Err(e), siendo e la variable que se pasa como único argumento al método.

...

fn print_all_emails(users: Iter<&User>) -> Result<(), String> {
    for u in users {
        let em = u.email.ok_or(String::from(u.username) + " sin email")?;
        println!("{}", em);
    }

    Ok(())
}

...
    if let Err(e) = print_all_emails(vec![&u, &u2].iter()) {
        println!("Error: {}", e);
    }
...

Rust: Funciones y closures

danigm — Sat, 25 Feb 2017 00:00:00 +0100

En Rust se pueden definir funciones, a nivel global, como parte de una implementación de una estructura o como parte de una interfaz o trait, además, se pueden pasar como parámetros a otras funciones, se puede decir que una función también define un nuevo tipo.

La estructura de una definición simple es la siguiente:

fn nombre_funcion(arg1: i32, arg2: &Vec<i32>) -> i64 {
    // cuerpo de la función
}

Se usa la palabra clave "fn", después va el nombre de la función, que normalmente se usa notación en minúsculas y con separando palabras con guión bajo, el llamado "snake_case". Entre paréntesis van todos los argumentos, separados por coma. Después si la función devuelve algo, va el operador "->" y luego se define el tipo de retorno.

Tanto la lista de argumentos como el retorno son opcionales, pudiendo definir funciones que no reciben argumentos y no devuelven nada:

fn nombre_funcion() {
    // cuerpo
}

Las funciones se pueden definir dentro de cualquier scope y serán visibles sólo durante ese scope, por tanto en Rust se pueden definir funciones a nivel global, dentro de una función, o dentro de otro scope, cualquiera. En ese sentido es muy similar a como se pueden definir las funciones en Python.

Argumentos

La definición de argumentos en las funciones en Rust no difiere mucho de otros lenguajes, como C o C++. Se definen como pares, identificador: tipo. El identificador es el nombre de la variable, y como Rust es fuertemente tipado, hay que definir el tipo de todo argumento. El tipo puede llevar modificadores & o &mut para modificar la forma en la que se pasan esas funciones, y el identificador puede llevar el modificador mut, que sería similar al funcionamiento en una asignación let.

fn add_element(mut a: Vec<i32>) -> Vec<i32> {
        a.push(1);
        a
}

let v = vec![];
let v2 = add_element(v);
println!("{:?}", v2);

En este ejemplo se ve cómo se pasa un vector como parámetro, y con el modificador mut es editable dentro de la función, al no llevar modificadores el tipo, el valor se mueve, por lo que en este ejemplo, v no se puede usar después de la llamada a la función, ya que el propietario de la memoria pasa a la variable a de la función, y luego al devolverse, se pasa a la variable v2. Si no devolviéramos nada en la función, el vector se liberaría al finalizar la llamada a la función.

El compilador da bastante información en caso de que intentáramos usar v después de la llamada a la función:

error[E0382]: use of moved value: `v`
 --> src/main.rs:9:27
  |
8 |     let v2 = add_element(v);
  |                   - value moved here
9 |     println!("{:?} {:?}", v, v2);
  |                           ^ value used here after move
  |
  = note: move occurs because `v` has type `std::vec::Vec<i32>`, which does not implement the `Copy` trait

Para poder seguir usando v lo suyo es pasar el argumento como una referencia, para hacer un borrow en lugar de un move.

fn add_element(v: &mut Vec<i32>, el: i32) {
    v.push(el);
}

let mut v = vec![1,2];
add_element(&mut v, 3);
println!("{:?}", v);

Aquí se pasa una referencia & editable mut, por lo que se hace un borrow de la memoria, durante la llamada, y por tanto, al terminar la llamada, se puede volver a usar v.

Devolución

El tipo de la devolución de una función, como he explicado antes, se define con "->" y a diferencia de los argumentos, no es necesario especificar un identificador, sólo el tipo.

En una función en Rust, la última línea, si no termina en ";" es lo que se devuelve, aunque también se puede hacer un return explícito, para que quede más claro o para los early returns, por ejemplo, estas dos definiciones son similares:

fn f1() -> Vec<i32> {
    let v = vec![];
    v.push(1);
    v.push(2);
    v
}

fn f2() -> Vec<i32> {
    let v = vec![];
    v.push(1);
    v.push(2);
    return v;
}

En Rust sólo es posible devolver un elemento, aunque se puede simular la devolución múltiple devolviendo una tupla y haciendo la asignación con patter matching:

fn dos_ultimos(v: &mut Vec<i32>) -> (i32, i32) {
    (v[v.len() - 2], v[v.len() - 1])
}

let mut v: Vec<i32> = vec![1,2,3,4,5];
let (x, y) = dos_ultimos(&mut v);
println!("{} {}", x, y);

El tipo de devolución, al igual que los argumentos, se mueven por defecto, pero se puede devolver una referencia, &, o una referencia mutable &mut, para que sea un borrow.

fn addel(v: &mut Vec<i32>, el: i32) -> &mut Vec<i32> {
    v.push(el);
    v
}

let mut v2 = addel(&mut v, 6);
let v3 = addel(&mut v2, 7);
println!("{:?}", v3);

Tipos genéricos y traits

Las funciones también pueden recibir tipos genéricos, para poder definir funciones que valgan para diferentes tipos:

fn fn_generica<T, K>(x: T, y: T, z: K) -> K {
    // definición
}

let ret: Vec<i32> = fn_generica(3, 5, vec![1, 2, 3]);

En esta función de ejemplo se definen dos tipos genéricos, T y K, y se ve el uso en los argumentos, x e y son de tipo T y z y el valor de retorno son de tipo K. Esta función acepta cualquier tipo para T y K, en el ejemplo se hace la llamada con T = i32 y K = Vec<i32>.

Así tal cual, no se puede hacer gran cosa con sólo tipos completamente genéricos, se pueden crear estructuras con estos tipos y poco más, porque al ser completamente genéricos no se puede acceder a ningún atributo o método de estos tipos.

Para un uso más específico se pueden usar los traits, de forma similar a los tipos genéricos, para poder definir funciones genéricas que hagan uso de esas interfaces:

extern crate core;
use core::cmp::Ordering;

fn main() {
    fn mayor<T: Ord>(x: T, y: T) -> T {
        match x.cmp(&y) {
            Ordering::Less => y,
            _ => x
        }
    }
    println!("{:?}", mayor(3, 6));
}

También existe una sintaxis más clara, para cuando hay muchos tipos genéricos, no tener que especificar todos los tipos entre el nombre de la función y la lista de argumentos, sólo los nombres de los tipos. Para esto se usa la palabra clave where:

fn mayor<T, K, L, H>(x: T, y: &K, z: &mut L) -> Option<H>
    where T: Ord,
          K: Iterator,
          L: Clone + Debug,
          H: Default {
    // cuerpo de la función
}

En esta cabecera de ejemplo se definen cuatro tipos genéricos, el primero tiene que implementar Ord, el segundo Iterator, el tercero Clone y Debug y el cuarto Default.

Lifetimes

Además de los tipos genéricos, dentro del mayor/menor, <>, puede ir información relativa a los tiempos de vida. El ejemplo típico es una función que recibe dos referencias y devuelve una referencia, todo del mismo tipo, el compilador no tiene información suficiente para saber con qué variable se relaciona la referencia devuelta, por lo que hay que anotar la función, el mismo compilador te dirá cuando no sea capaz de inferir los lifetimes:

fn skip_prefix(x: &str, y: &str) -> &str {
    return x.trim_left_matches(y)
}

println!("{}", skip_prefix("hola", "ho"));

error[E0106]: missing lifetime specifier
 --> src/main.rs:2:41
  |
2 |     fn skip_prefix(x: &str, y: &str) -> &str {
  |                                         ^ expected lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`

Así que es necesario añadir el lifetime:

fn skip_prefix<'a>(x: &'a str, y: &str) -> &'a str {
    x.trim_left_matches(y)
}

println!("{}", skip_prefix("hola", "ho"));

Los lifetimes se definen con letras en minúsculas y con un apóstrofe, en este ejemplo se define el lifetime 'a, pero se pueden definir tantos lifetimes como sean necesarios. En este caso, como devolvemos una subcadena de x, pues tiene que coincidir el lifetime de estos dos, si intentamos definir el lifetime con y en lugar de con x, el compilador se nos quejará:

fn skip_prefix<'a>(x: &str, y: &'a str) -> &'a str {
    return x.trim_left_matches(y)
}

error[E0495]: cannot infer an appropriate lifetime for autoref due to conflicting requirements
 --> src/main.rs:3:18
  |
3 |         return x.trim_left_matches(y)
  |                  ^^^^^^^^^^^^^^^^^
  |
help: consider using an explicit lifetime parameter as shown: fn skip_prefix<'a>(x: &'a str, y: &'a str) -> &'a str
 --> src/main.rs:2:5
  |
2 |       fn skip_prefix<'a>(x: &str, y: &'a str) -> &'a str {
  |  _____^ starting here...
3 | |         return x.trim_left_matches(y)
4 | |     }
  | |_____^ ...ending here

Como se puede ver en el mensaje de error, el compilador es bastante inteligente en este caso y nos da incluso una definición que sería válida para nuestro caso.

Closures

Se pueden definir funciones que reciban una función como parámetro, estas funciones se llaman closures y se definen de forma similar a los tipos genéricos y los traits:

fn apply<T, K, F>(f: F, x: T) -> K
    where F: Fn(T) -> K {
    f(x)
}
println!("{}", apply(|x: i32| x + 1, 3));

En este ejemplo hay dos cosas claves que no he explicado hasta ahora, el primero es el tipo F, que se define como Fn(T) -> K, con esta sintaxis definimos que F tiene que ser una función o closure que reciba un parámetro de tipo T y devuelva un tipo K.

La segunda sintaxis extraña está dentro de la llamada a apply, como primer argumento debe recibir la función de tipo F y le pasamos |x: i32| x + 1, que en realidad es esa definición.

Un closure se define con las barras verticales, para definir los argumentos y sus tipos, y después se define el cuerpo de la función, pudiendo obviar los corchetes cuando es una definición muy simple, como en el ejemplo.

También se puede asignar un closure a una variable para luego pasarlo en la llamada:

let c = |x: Vec<i32>| {
    for (i, l) in x.iter().enumerate() {
        if *l == 5 {
            return Some(i);
        }
    }
    None
};
println!("{:?}", apply(c, vec![1,5,3]));

En este caso, es lo mismo que definir la función de forma normal y luego pasarla por parámetro:

fn c(x: Vec<i32>) -> Option<i32> {
    for (i, l) in x.iter().enumerate() {
        if *l == 5 {
            return Some(i as i32);
        }
    }
    None
};

println!("{:?}", apply(c, vec![1,5,3]));

Por lo que asignar closures a variables tiene poco sentido, en realidad son útiles cuando se definen directamente en la llamada, para no tener que definir una función con nombre para algo que sólo se llamará una vez.

Move en closures

Cuando se define un closure se pueden usar variables que estén en el ámbito, y por defecto se cogen como borrow, por lo que el closure estará ligado a las variables que use.

let mut num = 5;
let plus_num = |x: i32| x + num;
let y = &mut num;

Este código, sacado de la doc de Rust, no compila, porque se intenta hacer una referencia mutable en la asignación de y, cuando ya existe una referencia a num dentro del closure.

Para evitar este problema se usa el move, que funciona igual que el paso de argumentos sin modificadores, es decir, para los tipos que implementen el trait copy se copiará el valor, para los demás, se hará move de la propiedad de la memoria.

let mut num = 5;
let plus_num = move |x: i32| x + num;
let y = &mut num;

Un caso típico de move en closure es cuando se lanza un hilo:

use std::thread;

fn main() {
    let mut threads: Vec<thread::JoinHandle<()>> = vec![];
    for i in 1..10 {
        let t = thread::spawn(move || {
            println!("Hilo {}", i);
        });
        threads.push(t);
    }

    for t in threads {
        t.join();
    }
}

En este ejemplo se lanzan 9 hilos, la variable i se usa dentro del closure, que al definirse con move será una copia, ya que es un i32 y este tipo implementa Copy, si no se pone el move, el compilador se quejará, ya que la variable i sólo existe en el scope del bucle, y el otro hilo puede existir más allá del bucle.

Devolución de closures

También se pueden devolver closures, pero no es algo trivial, hay que encapsularlas en un Box para que se pueda devolver y para evitar los problemas con la gestión de la memoria de Rust.

Rust: Structs y Traits

danigm — Sun, 19 Feb 2017 00:00:00 +0100

Rust ofrece por defecto los tipos de datos básicos que ofrece cualquier lenguaje de programación, pero al igual que en otros lenguajes, se pueden definir tipos propios más complejos con struct.

Rust no es un lenguaje orientado a objetos, y en su documentación no se encuentra nada sobre clases, objetos, instancias, etc. Sin embargo, hay conceptos similares cuando nos adentramos en la definición de nuevos tipos con struct y también con los traits, donde sí tenemos cosas como la herencia.

Structs, "Estructuras" y tipos de datos complejos

Los tipos de datos propios en Rust se definen con la palabra clave struct. Para quien venga de C/C++ todo este código le será familiar.

struct Point {
    x: i32,
    y: i32,
}

fn main() {
    let p = Point{x: 0, y: 0};
    println!("Punto: ({}, {})", p.x, p.y);
}

ejecutar

También existen estructuras de tipo tupla, Tuple Structs, que no son más que estructuras donde los atributos van sin nombre, por índice.

struct Point(i32, i32);

fn main() {
    let p = Point(0, 0);
    println!("Punto: ({}, {})", p.0, p.1);
}

ejecutar

Los atributos de las estructuras son privados por defecto, esto quiere decir que no son accesibles cuando se usan desde un módulo diferente al de su definición, en el módulo de su definición, todos los atributos son accesibles. Para hacer un atributo accesible a todo el mundo tan sólo hay que añadir la palabra clave pub delante, en la definición.

struct Point {
    pub x: i32,
    pub y: i32,
}

Métodos

Además de los atributos normales de las estructuras, también se pueden definir métodos que implementa esta estructura. Esto es muy similar a los métodos de la programación orientada a objetos, y en realidad serán llamados de forma similar, con el ".".

Para implementar métodos para una estructura se utiliza la palabra clave impl.

struct Point {
    x: i32,
    y: i32,
}

impl Point {
    fn new() -> Point {
        Point{x: 0, y: 0}
    }

    fn distance(&self, p: &Point) -> f32 {
        let d1 = (self.x - p.x).pow(2);
        let d2 = (self.y - p.y).pow(2);

        f32::sqrt((d1 + d2) as f32)
    }
}

impl Point {
    fn moveup(&mut self) {
        self.y += 1;
    }
}

fn main() {
    let mut p1 = Point::new();
    p1.moveup();

    let p2 = Point{x: 24, y: -30};

    println!("distancia: {}", p2.distance(&p1));
}

ejecutar

En este ejemplo hay varias cosas interesantes. Lo primero es el método new, que es un método estático, osea, no se llama desde una estructura instanciada, sino con el nombre de la estructura y el operador ::. En este caso se usa como un constructor.

Luego se implementa el método para calcular la distancia, que recibe un primer parámetro sin tipo, pero llamado self, este parámetro es la estructura en sí, y como en python es explícito, hay que ponerlo en la lista de argumentos. En este caso se define como una referencia, pero al igual que todas las definiciones de variables en Rust dependerá del uso que queramos darle, si vamos a modificar debería ser un &mut self o si queremos que vaya por copia/movimiento un simple self.

La otra cosa interesante de este ejemplo es que hay dos declaraciones de impl para la estructura Point, y en realidad puede haber cuantas se quiera, incluso se pueden añadir métodos a estructuras desde módulos diferentes, pero no desde crates diferentes.

Con esto casi podríamos decir que tenemos lo mismo que en otros lenguajes orientados a objetos, pero no tenemos herencia, polimorfismo ni nada de eso, para ello existen los Traits.

Traits, "Rasgos" de tipos

Los traits no son más que una lista de métodos con o sin implementación que las estructuras o los tipos deben implementar para cumplir ese trait.

Se definen con la palabra clave trait y una lista de funciones que definen la interfaz y luego se implementa con la construcción impl TRAIT for TYPE.

struct Point {
    x: i32,
    y: i32,
}

trait Distance {
    fn distance(&self, p: &Point) -> f32;
}

impl Distance for Point {
    fn distance(&self, p: &Point) -> f32 {
        let d1 = (self.x - p.x).pow(2);
        let d2 = (self.y - p.y).pow(2);

        f32::sqrt((d1 + d2) as f32)
    }
}

fn main() {
    let p1 = Point{x: 0, y: 0};
    let p2 = Point{x: 24, y: -30};

    println!("distancia: {}", p2.distance(&p1));
}

ejecutar

Los traits se pueden usar en las definiciones de las funciones o de las estructuras, en lugar de los tipos, para implementar funciones o tipos genéricos, con la sintaxis de tipo genérico <T: TRAIT>.

También se pueden definir implementaciones por defecto en los métodos de los traits, por lo que no es obligatorio ofrecer una implementación para esos métodos, si se ofrece una implementación estaremos sobreescribiendo ese método, si no se utilizará la implementación por defecto.

Por ejemplo, podemos definir un trait para tipos que tengan posición en un plano 2D, HasPosition, y podemos definir la distancia del trait Distance como un método que recibe un tipo que tiene posición como segundo argumento.

struct Point {
    x: i32,
    y: i32,
}

struct Circle {
    x: i32,
    y: i32,
    r: i32,
}

trait HasPosition {
    fn getx(&self) -> i32;
    fn gety(&self) -> i32;

    fn pos(&self) -> Point {
        Point { x: self.getx(), y: self.gety() }
    }
}

impl HasPosition for Circle {
    fn getx(&self) -> i32 { self.x }
    fn gety(&self) -> i32 { self.y }
}

impl HasPosition for Point {
    fn getx(&self) -> i32 { self.x }
    fn gety(&self) -> i32 { self.y }
}

trait Distance {
    fn distance<T: HasPosition>(&self, p: &T) -> f32;
}

impl Distance for Point {
    fn distance<T: HasPosition>(&self, p: &T) -> f32 {
        let d1 = (self.x - p.pos().x).pow(2);
        let d2 = (self.y - p.pos().y).pow(2);

        f32::sqrt((d1 + d2) as f32)
    }
}

fn main() {
    let p1 = Point{x: 0, y: 0};
    let p2 = Circle{x: 24, y: -30, r: 1};

    println!("distancia: {}", p1.distance(&p2));
}

ejecutar

En este ejemplo se definen dos estructuras, Point y Circle y dos traits, HasPosition y Distance, así podemos comparar distancias no sólo entre puntos, sino que también entre puntos y círculos, ya que estas dos estructuras implementan el trait HasPosition.

Los métodos getx y gety se tienen que implementar obligatoriamente, ya que no se ofrece una implementación por defecto, sin embargo, el método pos no se está sobreescribiendo en ninguna de las dos estructuras, y por lo tanto se usa la implementación por defecto del trait.

Combinación de Traits

En ocasiones queremos que un tipo implemente varios traits y esto se puede definir utilizando el símbolo "+":

fn f<T, K>(x: &T, y: &K) -> K
    where T: HasPosition,
          K: HasPosition + Distance + Clone {
    // Implementación de la función
}

En esta definición se puede ver cómo el tipo K tiene que implementar tres traits mientras que el tipo T sólo ha de implementar uno. Aquí también introduzco el uso de where para que la cabecera de la función quede más clara.

Herencia

Como he comentado antes, Rust no es un lenguaje orientado a objetos como tal, los structs y los traits no son clases, aunque el código pueda ser similar.

Aún así, con los traits se puede hacer algo similar a la herencia, utilizando el operador ":". Con esta definición se obliga a que si se implementa un trait también se tengan que implementar el resto de traits.

trait Distance: HasPosition {
    fn distance<T: HasPosition>(&self, p: &T) -> f32 {
        let p1 = self.pos();
        let p2 = p.pos();
        let d1 = (p1.x - p2.x).pow(2);
        let d2 = (p1.y - p2.y).pow(2);

        f32::sqrt((d1 + d2) as f32)
    }
}

impl Distance for Point {}
impl Distance for Circle {}

En este ejemplo se define el trait Distance, que depende del trait HasPosition.

En la herencia también se puede utilizar la combinación de traits con el operador "+".

Pero en realidad, no se puede considerar esto como herencia, ya que no hay posibilidad de llamar al método padre, por lo que no es posible encadenar llamadas de métodos por defecto cuando una estructura implementa un trait. Si se sobreescribe un método de un trait se tiene que escribir todo el código, no es posible utilizar la implementación por defecto para sobreescribir el método.

Conclusiones

Con las estructuras y los traits se puede escribir código reutilizable, definiendo funciones que reciban tipos genéricos que implementen una serie de interfaces (traits) de tal forma que el mismo código sirva para diferentes tipos.

En Rust todo el código de la librería estándar está fuertemente basado en traits y por lo tanto hay una serie de traits que es necesario conocer, porque sirven para implementar funcionamiento básico, como por ejemplo, Iterator, Copy, Clone, Debug.

Cargo: Dependencias, crates y módulos en Rust

danigm — Sat, 11 Feb 2017 00:00:00 +0100

Cargo

Rust viene con una herramienta por defecto para gestionar dependencias, crear proyectos y realizar otras tareas comunes, esta herramienta se llama Cargo.

Esta herramienta ofrece algo similar a lo que sería pip y virtualenv en python, pero además realiza otras tareas como los test y la generación de documentación.

Por lo tanto Cargo sirve para:

Crear nuevos proyectos Rust a partir de templates (new, init)
Compilar el proyecto actual (run, build, install)
Gestionar dependencias del proyecto (search, update)
Publicar el proyecto en crates.io (publish)
Generar la documentación del proyecto (doc)
Ejecutar los tests (test, bench)

Es una herramienta genial que engloba casi todas las utilidades para llevar un proyecto de forma sencilla. Cuando empecé a trastear con Rust es una de las cosas que más me gustó, porque te simplifica la vida a la hora de usar el lenguaje y en crates.io cada vez hay más módulos, lo que enriquece a Rust, ya que puedes encontrar fácilmente bibliotecas para casi todo.

Creando un proyecto

Con Cargo se pueden crear por defecto dos tipos de proyectos, un ejecutable o una biblioteca. La diferencia básica es el punto de entrada, por defecto el fichero src/main.rs es el punto de entrada, lo que se ejecuta, para los proyectos ejecutables, y el fichero src/lib.rs es el punto de entrada para las bibliotecas.

$ cargo new --bin ejemplo
     Created binary (application) `ejemplo` project

Esto nos crea un directorio ejemplo con los ficheros básicos:

$ tree ejemplo
ejemplo/
├── Cargo.toml
└── src
    └── main.rs

El comando además de estos ficheros también nos crea, por defecto, un repositorio git, por lo tanto existen los ficheros ocultos .git y .gitignore. Este comportamiento se puede modificar con la configuración --vcs, que puede ser: git, hg o none.

$ ls -la ejemplo/
total 8
drwxr-xr-x. 4 danigm danigm 120 feb 11 08:59 .
drwxr-xr-x. 3 danigm danigm  60 feb 11 08:59 ..
-rw-r--r--. 1 danigm danigm 117 feb 11 08:59 Cargo.toml
drwxr-xr-x. 6 danigm danigm 180 feb 11 08:59 .git
-rw-r--r--. 1 danigm danigm   7 feb 11 08:59 .gitignore
drwxr-xr-x. 2 danigm danigm  60 feb 11 08:59 src

Aparte del vcs, se crean dos ficheros, el fichero Cargo.toml, que es el fichero de configuración, y el fichero src/main.rs, que es donde va el código, el punto de entrada que se usará para generar el binario.

$ cat ejemplo/Cargo.toml
[package]
name = "ejemplo"
version = "0.1.0"
authors = ["Daniel García Moreno <danigm@wadobo.com>"]

[dependencies]

Como vemos en el fichero de configuración por defecto van una serie de variables básicas con el nombre, la versión y los autores, aunque hay muchas más cosas que se pueden especificar aquí.

También está aquí el listado de dependencias, que por defecto está vacío, pero que iremos rellenando según vayamos necesitando módulos externos y Cargo se encargará de descargar esas dependencias y compilarlas por nosotros.

Primera ejecución

Una vez creado el proyecto, ejecutarlo es tan fácil como:

$ cd ejemplo
$ cargo run
   Compiling ejemplo v0.1.0 (file:///tmp/cargo/ejemplo)
    Finished debug [unoptimized + debuginfo] target(s) in 0.38 secs
     Running `target/debug/ejemplo`
Hello, world!

Esto compila el proyecto y lo ejecuta, si no ha cambiado, simplemente lo ejecuta, no se pierde el tiempo compilando.

Como se puede ver, lo que ejecuta es lo que hay dentro del fichero src/main.rs:

fn main() {
    println!("Hello, world!");
}

El comando run compila en modo debug, esto quiere decir que no está optimizado el ejecutable que se genera. Para generar un ejecutable final se puede usar el comando:

$ cargo build --release
   Compiling ejemplo v0.1.0 (file:///tmp/cargo/ejemplo)
    Finished release [optimized] target(s) in 0.15 secs

Los binarios se generan en el directorio target, en su correspondiente carpeta según sean de debug o release, target/debug/ejemplo y target/release/ejemplo.

Usando dependencias externas

Como hemos visto antes, el listado de dependencias está vacío por defecto. Vamos a añadir alguna:

# fichero Cargo.toml
...
[dependencies]
time = "*"
regex = "0.2"

Es muy fácil añadir dependencias, que se pueden buscar con el comando cargo search o directamente en la web crates.io, y además, cargo soporta una sintaxis rica para especificar números de versión, además de poder especificar otras fuentes para descargar las dependencias, por si son privadas o no están en crates.io.

Si ejecutamos ahora cargo build, se descargarán las dependencias y se compilarán.

$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading aho-corasick v0.6.2
   Compiling libc v0.2.20
   Compiling utf8-ranges v1.0.0
   Compiling void v1.0.2
   Compiling regex-syntax v0.4.0
   Compiling unreachable v0.1.1
   Compiling memchr v1.0.1
   Compiling time v0.1.36
   Compiling thread-id v3.0.0
   Compiling thread_local v0.3.2
   Compiling aho-corasick v0.6.2
   Compiling regex v0.2.1
   Compiling ejemplo v0.1.0 (file:///tmp/cargo/ejemplo)
    Finished debug [unoptimized + debuginfo] target(s) in 11.35 secs

El fichero Cargo.lock contiene la información de todas las dependencias descargadas y su versión, permitiendo así compilaciones exactamente iguales.

Crates

Hemos hablado de dependencias y crates y hemos visto cómo cargo gestiona e instala las dependencias de forma sencilla.

Crate es como se llaman a las bibliotecas en Rust. Traducido literalmente significa Cajón, y se podría decir que un crate es un proyecto Rust completo, un fichero Cargo.toml que especifica su nombre, versión, etc y una serie de ficheros en src donde se definen los diferentes módulos.

Para usar un crate en nuestro proyecto se usa extern crate XXX, así podemos usar las dependencias que hemos añadido anteriormente, sería algo similar al import de python o al include de C o C++.

extern crate time;

fn main() {
    if let Ok(now) = time::strftime("%c", &time::now()) {
        println!("Hello, world! {}", now);
    }
}

En el momento en el que declaramos el extern crate time ya es posible utilizar el módulo time.

Además del uso de extern crate, en Rust existe otra palabra clave para importar módulos o funciones externas en el ámbito local, algo similar a lo que en python se hace con from X import Y. En Rust la sintaxis utilizada es use, por ejemplo en nuestro caso podríamos tener:

extern crate time;

use time::{now, strftime};

fn main() {
    if let Ok(n) = strftime("%c", &now()) {
        println!("Hello, world! {}", n);
    }
}

Hemos usado aquí una sintaxis compacta, pero se puede definir uno por línea o incluso todo a la vez:

use time::now;
use time::strftime as format_date;
use time::*;

Módulos

Como hemos visto, en Rust las bibliotecas se llaman crates y en estas bibliotecas puede haber diferentes agrupaciones que se llaman modules, o módulos en español. Así que tenemos un cajón que tiene uno o más módulos dentro.

El módulo por defecto se define en el fichero src/lib.rs, donde se pueden definir directamente funciones, estructuras, etc. o submódulos.

Por defecto en Rust todo es privado, por lo que si queremos que desde fuera de un módulo se pueda usar algo definido dentro, debemos usar la palabra clave pub.

Podemos definir un par de funciones en un nuevo fichero src/lib.rs, para usar después en src/main.rs:

extern crate time;

pub fn fecha() -> String {
    let mut fecha = String::from("");
    if let Ok(n) = time::strftime("%d/%m/%Y", &time::now()) {
        fecha = n.clone();
    }
    fecha
}

pub fn hora() -> String {
    let mut hora = String::from("");
    if let Ok(n) = time::strftime("%H:%M", &time::now()) {
        hora = n.clone();
    }
    hora
}

En nuestro proyecto de ejemplo, tenemos el crate, que es el proyecto en sí, y el módulo por defecto, que es src/lib.rs, donde hemos definido dos funciones públicas, fecha y hora. Esto lo podemos utilizar en nuestro ejecutable, exactamente igual que usamos una dependencia externa, con el uso de extern crate.

extern crate ejemplo;

fn main() {
    println!("fecha: {}", ejemplo::fecha());
    println!("hora: {}", ejemplo::hora());
}

Submódulos

En el ejemplo anterior hemos visto cómo se define el módulo por defecto de un crate, que no es más que el fichero src/lib.rs. Pero en cualquier proyecto que no sea un ejemplo habrá que definir más de un módulo, no puede estar todo junto en el mismo.

Para definir submódulos en Rust se puede usar mod, que sirve exactamente para definir submódulos:

// fichero src/lib.rs
pub mod fecha {
    extern crate time;
    pub fn ahora() -> String {
    //...
    }
}

pub mod hora {
    extern crate time;
    pub fn ahora() -> String {
    //...
    }
}

En este ejemplo se definen dos módulos, fecha y hora. La única diferencia con el caso anterior es que ahora podemos agrupar en módulos las diferentes funciones que definamos. También hay que tener en cuenta que en cada módulo en ámbito es diferente, de ahí la necesidad de hacer el extern crate time en los dos módulos, aunque estén en el mismo fichero.

El uso en el main.rs sería similar:

extern crate ejemplo;

fn main() {
    println!("fecha: {}", ejemplo::fecha::ahora());
    println!("hora: {}", ejemplo::hora::ahora());
}

Módulos en ficheros separados

Pero este uso tiene poca utilidad real, normalmente los módulos han de ir en ficheros separados o incluso en carpetas, creando una jerarquía de ficheros que simboliza exactamente la jerarquía de los módulos.

En nuestro ejemplo, podemos crear un nuevo fichero con el contenido del módulo fecha, un fichero llamado src/fecha.rs.

// fecha.rs
extern crate time;
pub fn ahora() -> String {
    //...
}

Se puede observar que ya no es necesario el uso de mod, puesto que al estar en un fichero separado, es implícito.

Y en el fichero módulo por defecto sólo tendremos que declarar este módulo como público para que sea accesible desde main.rs.

// lib.rs
pub mod fecha;
pub mod hora;

De esta forma ya tenemos nuestros módulos en ficheros diferentes y son accesibles desde fuera.

Además de ficheros con el nombre del módulo, en Rust se pueden declarar carpetas, y dentro de esa carpeta debe existir el fichero mod.rs, sería algo similar a los ficheros init.py en los módulos python.

Podríamos tener una estructura de ficheros tal que así:

ejemplo/
├── Cargo.toml
└── src
    ├── main.rs
    ├── lib.rs
    ├── fecha.rs
    └── hora
        ├── mod.rs
        ├── local.rs
        └── utc.rs

main.rs es el ejecutable, si estamos hablando de una biblioteca, no existiría este fichero.
lib.rs define el módulo principal, este fichero puede no existir si estamos hablando de un crate ejecutable, sin módulos propios.
fecha.rs un módulo más del proyecto, que para ser accesible debe debe estar declarado en el módulo por defecto.
hora es una carpeta que contiene otro módulo, que al igual que fecha.rs debe estar definido en lib.rs para ser accesible.
mod.rs definición del módulo hora.
local.rs y utc.rs submódulos de hora, que deben estar definidos en mod.rs para ser accesibles.

Además del uso de módulos desde fuera, por ejemplo en el main.rs o si lo usamos como dependencia en otro proyecto, pueden existir módulos internos en el proyecto, que no exportemos como públicos, y que sólo se usen de manera interna. Por defecto las importaciones son relativas al módulo por defecto:

use fecha; // -> importación relativa al módulo actual
use ::fecha; // -> importación absoluta, llevaría a src/fecha.rs
use self::fecha; // -> relativo al módulo actual, por ejemplo no funcionaría
         // -> si se usara esto dentro de *hora/mod.rs*, aunque sí
         // -> en otro módulo al nivel de fecha.rs
use super::fecha; // -> con super se puede acceder al módulo padre

Con estas declaraciones podemos hacer uso de unos módulos en otros, variará lo que tengamos que usar según nuestra estructura de ficheros.

También se puede cambiar el nombre de un módulo en una declaración use, para evitar conflictos de nombres, con la palabra reservada as:

extern crate ejemplo;

use ejemplo::fecha::ahora as fecha;
use ejemplo::hora::ahora as hora;

fn main() {
  println!("{} - {}", fecha(), hora());
}

La verdad es que el sistema de módulos de Rust es muy parecido al de python, podríamos decir que self sería el from . import de python y el super podría ser from .. import.

Rust: Introducción a la gestión de memoria

danigm — Sat, 04 Feb 2017 00:00:00 +0100

Gestión de memoria sin recolector de basura

Una de las características principales de Rust es la seguridad de la memoria, que se comprueba en tiempo de compilación, sin recolector de basura.

En teoría, con Rust no es posible que ocurra un segmentation fault, porque no hay manera de que se acceda a una posición de memoria inválida y además, tampoco es posible que haya memory leaks, y esto se verifica en tiempo de compilación, por lo que no es necesario un recolector de basura y por lo tanto, el rendimiento es similar al de lenguajes como C.

Esto se consigue en Rust con el concepto de propiedad de la definición de las variables.

Concepto de propiedad de la memoria (ownership)

En Rust cada declaración de variable asigna la propiedad de el valor a esa variable, así cuando la variable sale del ámbito, la memoria se libera.

Para garantizar la seguridad de la memoria sólo puede existir un propietario de una zona de memoria, porque si no, el compilador no sabe cuándo debe liberar esa memoria y podría existir en el tiempo una variable apuntando a una zona de memoria inválida.

fn foo() {
    let v = vec!(1, 2, 3);
}

Por ejemplo, esta asignación crea un vector en memoria con tres elementos, y asigna la propiedad de ese vector a la variable v. Como está dentro de la función foo, esa variable existirá hasta el final de esa función, y cuando se sale de la función, se elimina de la memoria el vector.

Mover, copiar y clonar (Copy, Clone)

Mover

Como he comentado antes, Rust se asegura de que una zona de memoria sólo es propiedad de una única variable, para poder asegurar en tiempo de compilación que no se accede a memoria liberada.

let v = vec!(1, 2, 3);
let v2 = v;

¿Qué ocurre entonces en este caso? Tenemos el vector cuyo propietario es v, pero declaramos otra variable, v2 a la que le asignamos el valor de v, por lo tanto, tendríamos dos variables apuntando a la misma zona de memoria. Pero este caso lo resuelve Rust con el movimiento del valor, osea, la propiedad pasa de v a v2 en esta asignación, asegurando así que sólo hay un propietario de ese valor, y por tanto, el vector se eliminará cuando v2 salga del ámbito.

Pero claro, esto podría crear inconsistencias, porque si v2 se elimina antes que v, hay un instante de tiempo en el que tenemos a alguien apuntando a una zona no válida de memoria. Y esto lo resuelve el compilador no dejándote acceder a v:

let v = vec!(1, 2, 3);
let v2 = v;
println!("v[0] is: {}", v[0]);
// error: use of moved value: `v`
// println!("v[0] is: {}", v[0]);
//                         ^

ejecutar

No podemos acceder al vector usando v, después de haber movido el valor, porque ya no es el propietario. En este caso sólo podríamos acceder con v2.

Esto también ocurre cuando se pasa la variable a una función:

fn take(v: Vec<i32>) {
    // lo que ocurre aquí dentro no es relevante
}
fn main() {
    let v = vec!(1, 2, 3);
    take(v);
    println!("v[0] is: {}", v[0]);
}

ejecutar

Esto nos dará el mismo error, en este caso, la propiedad pasa de la variable v declarada en el ámbito de main al atributo v declarado en la función take. Por lo tanto, el vector se eliminará después de la llamada a take, se ha movido el valor, así que si el compilador nos dejara acceder a v[0], tendríamos acceso a memoria ya liberada, de ahí la importancia de la propiedad en Rust, nos asegura que la memoria se libera y que no hay ninguna variable apuntando a donde no debe en ningún momento.

Copiar

Sin embargo, esto no ocurre con los tipos básicos, ya que en lugar de moverse, estos se copian. Existe un trait llamado Copy, que implementan los tipos básicos y que hace que en lugar de mover los valores en una asignación se haga una copia completa. Por lo tanto todo tipo que implemente Copy se copiará y por tanto nos permite asignar a diferentes variables, porque realmente son zonas de memoria distintas e independientes.

fn double(x: i32) -> i32 {
    x * 2
}

fn main() {
    let v = 2;
    let v2 = double(v);
    println!("v: {}, v2: {}", v, v2);
    // v: 2, v2: 4
}

ejecutar

En este caso, podemos acceder al valor de v en el println porque el tipo i32 implementa Copy, por lo tanto en la llamada a double se copia el valor, no se mueve, x existe sólo durante el ámbito de double y tiene el valor 2 copiado de v, ambas son accesibles en sus diferentes ámbitos en independientes.

Clonar

Existe otra forma de copiar variables en Rust, en lugar de copiar lo que hacemos es clonar. Es básicamente lo mismo salvo que el copiado es implícito y el clonado es explícito. Además, en Rust no está permitido reimplementar el copiado, siempre será una copia literal de memoria, sin embargo, el clonado sí que se puede reimplementar y hacer un copiado más ligero o ejecutar cualquier código para gestionar el tipo.

fn take(v: Vec<i32>) {
    // lo que pase aquí es irrelevante
}

fn main() {
    let v = vec!(1, 2, 3);
    take(v.clone());
    println!("v[0]: {}", v[0]);
    // v[0]: 1
}

ejecutar

Volviendo al ejemplo anterior, donde la llamada a una función movía el vector y por tanto lo hacía inaccesible, podemos solucionarlo usando clone, ya que el tipo Vec implementa Copy, así en la función take tenemos una copia del vector, son dos vectores diferentes.

Tomar prestado y referencias (borrow)

Con el copiado y el clonado, podemos hacer uso de las diferentes variables en llamadas a métodos y demás, pero esto no es nada eficiente si tenemos estructuras de datos grandes, ya que estamos copiando constantemente y no nos permite modificar una variable dentro de una función, todo cambio debería hacerse en valor de devolución, si queremos añadir un elemento a un vector, tendríamos que copiar el vector, añadir el elemento y devolver el nuevo vector, en lugar de añadirlo directamente.

fn addone(mut w: Vec<i32>, element: i32) -> Vec<i32> {
    w.push(element);
    w
}

fn main() {
    let v = vec!(1, 2, 3);
    let v2 = addone(v.clone(), 4);
    println!("{:?}", v);
    println!("{:?}", v2);
}

ejecutar

Para evitar copiar el vector, en Rust existen las referencias "&". Cuando se crea una referencia a un valor, en lugar de mover o copiar ese valor, tenemos realmente dos variables apuntando a la misma zona de memoria. Sin embargo, hemos dicho que esto no es posible si queremos mantener la seguridad de la memoria... Y para solucionar esto, el concepto que añade Rust es el de borrowing o tomar prestado.

Una zona de memoria sólo tiene un propietario, pero puede que alguna otra variable quiera acceder a esa zona de memoria, por lo tanto la pide prestada, "borrow", y ya es como si en ese momento fuera el propietario.

let v = vec!(1, 2, 3);
let v2 = &v;
println!("v[0]: {}, v2[0]: {}", v[0], v2[0]);

En este caso, tenemos que la variable v2 es una referencia a v y por tanto lo que hace es pedir prestado el vector, haciendo accesible tanto a v como v2.

Estas referencias son inmutables, lo que no nos permite modificar la zona de memoria, por lo tanto, podemos Rust nos permite tener tantas referencias inmutables como queramos a una zona de memoria, siempre y cuando estas referencias no estén en un ámbito superior al propietario, es decir, que no pueden existir las referencias más allá que el propietario, ya que cuando el propietario salga del ámbito, la memoria se liberará.

Para poder modificar los valores por referencia hay que hacer uso de las referencias mutables "&mut". A diferencia de las referencias inmutables, sólo está permitido que exista una referencia mutable para un valor determinado. Esto es así para evitar que una zona de memoria sea modificada por dos variables a la vez.

No sólo no es posible tener más de una referencia mutable a un valor, sino que una vez que se hace una referencia mutable, no es posible hacer ninguna referencia inmutable, es decir, que mientras que exista una referencia mutable no puede existir ninguna otra referencia.

let mut x = 5;
{
    let y = &mut x;
    *y += 1;
}
println!("{}", x);

ejecutar

En este ejemplo se puede ver el uso de una referencia mutable. Para que el compilador no se queje en la llamada a prinlnt, hay que añadir las llaves, que crean un ámbito nuevo. La variable y sólo existe en ese ámbito, por lo tanto, al salir nos permite llamar a println con x.

El "*" se usa en este ejemplo para hacer una derreferencia explícita y poder modificar realmente el valor que estamos referenciando y no la referencia en sí, ya que y no es realmente del tipo i32, sino que es del tipo &mut i32.

Con las referencias mutables podemos simplificar el ejemplo anterior de añadir un elemento a un vector:

fn addone(w: &mut Vec<i32>, element: i32) {
    w.push(element);
}

fn main() {
    let mut v = vec!(1, 2, 3);
    addone(&mut v, 4);
    println!("{:?}", v);
}

ejecutar

En este caso no es necesario añadir las llaves para crear un ámbito nuevo para la referencia mutable, ya que ésta sólo existe en el ámbito de la función addone, por lo tanto, después de la llamada no existe ninguna referencia a v y por tanto esta es accesible de nuevo.

Tiempo de vida (lifetimes)

No voy a entrar en detalle con respecto a los tiempos de vida de las variables, en este artículo introductorio, pero sí voy a comentar lo básico para saber qué significa y cómo se usa.

Cuando se hace una referencia, tenemos dos variables apuntando a una misma zona de memoria, y como he comentado anteriormente, una referencia no puede existir más allá que el propietario de la memoria.

Normalmente el compilador es capaz de determinar la vida de las variables y las referencias para asegurarse de que esta regla se cumple, pero hay ocasiones en las que el compilador no es capaz de determinar si una referencia dura más o menos, por lo que hay que especificarlo.

Esto se da normalmente en definiciones de funciones que reciben varias referencias y devuelven otra referencia. El compilador no sabe a cuál parámetro de entrada está ligada esta referencia, por lo que hay que especificarlo con una nueva sintaxis:

fn skip_prefix<'a, 'b>(line: &'a str, prefix: &'b str) -> &'a str {
    // ...
  line
}

let line = "lang:en=Hello World!";
let lang = "en";

let v;
{
    let p = format!("lang:{}=", lang);  // -+ `p` comes into scope.
    v = skip_prefix(line, p.as_str());  //  |
}                                       // -+ `p` goes out of scope.
println!("{}", v);

ejecutar

En este ejemplo se definen dos tiempos de vida, en la declaración de skip_prefix, a y b. La primera referencia tiene el ámbito a y la segunda el ámbito b, y se devuelve una referencia que tiene el ámbito a. Si no definimos los tiempos de vida, el compilador se quejará, porque no sabría a qué refiere el valor de retorno.

El tiempo de vida también puede ser necesario definirlo en estructuras que tengan referencias. Normalmente no te tienes que preocupar de esto hasta que el compilador no se queje, si no es capaz de inferir los tiempos de vida te lo dirá y tendrás que especificarlo en el código.

Uso básico de referencias, Rc/RefCell y Arc/Mutex

Debido a las restricciones del uso de memoria de Rust la gestión de referencias, los tiempos de vida y demás nos pueden complicar un poco la vida. Sin embargo existen unos tipos que nos permiten hacer uso de referencias de una forma mucho más simple y manteniendo la seguridad de memoria que nos ofrece Rust en tiempo de compilación, estoy hablando de Rc y RefCell.

Cell y RefCell, tipos mutables a través de referencias

Como hemos visto antes, sólo puede haber una referencia mutable a un valor, los tipos Cell y RefCell nos permiten modificar valores con una referencia no mutable, por lo que podemos tener varias referencias a un Cell y en cualquier momento editar el contenido.

Cell sólo es compatible con los tipos que soporta Copy, en otro caso hay que utilizar RefCell. Con Cell podemos modificar o acceder al contenido llamando a los métodos set y get, con RefCell tenemos que hacer un borrow_mut() para obtener una referencia mutable.

use std::cell::Cell;
use std::cell::RefCell;

fn main() {
    let v = 1;
    let v2 = Cell::new(v);
    v2.set(3);
    println!("v: {}, v2: {}", v, v2.get());

    // RefCell
    let v3 = RefCell::new(5);
    {
        let mut v4 = v3.borrow_mut();
        *v4 = 7;
        println!("v4: {}", *v4);
    }
    let v5 = v3.borrow();
    println!("v3: {}, v5: {}", *v3.borrow(), *v5);
}

ejecutar

Lo realmente interesante de este ejemplo es el uso de RefCell, ya que con Cell tenemos una copia, lo único extra que tenemos es que nos evitamos el mut en la declaración de v2.

En un RefCell podemos hacer tantos borrow como queramos, pero sólo puede existir un borrow_mut en el ámbito, ya que estamos en las mismas, la función borrow fallará si existe un borrow_mut, de ahí las llaves de este ejemplo, para añadir un nuevo ámbito para v4.

Estos tipos no nos ofrecen nada extraordinario, porque este mismo código lo podemos tener con referencias básicas con algo así:

let mut v3 = 5;
{
    let mut v4 = &mut v3;
    *v4 = 7;
    println!("v4: {}", *v4);
}
let v5 = &v3;
println!("v3: {}, v5: {}", v3, *v5);

Estos tipos son útiles en combinación con los tipos Rc.

Rc, punteros con contador de referencias

El tipo Rc<T> nos ofrece una propiedad compartida del valor de tipo T. Podemos llamar la función clone para crear una nueva referencia al mismo valor en memoria. El propio tipo se encarga de decrementar el número de referencias cuando salen del ámbito y de liberar la memoria cuando ya no hay ninguna referencia.

Rc no permite editar los valores, ya que las referencias no son mutables. Para poder editar los valores compartidos con un Rc, se puede usar en combinación con RefCell.

use std::rc::Rc;
use std::cell::RefCell;

fn main() {
    let v = Rc::new(RefCell::new(vec!(1, 2, 3)));
    let v1 = v.clone();
    v1.borrow_mut().push(4);
    println!("v: {:?}", v.borrow());
}

ejecutar

En este ejemplo se puede ver cómo tenemos una referencia compartida al vector, que además es editable a través de borrow_mut. En la declaración de v1 se llama a clone, pero realmente no se copia la memoria del vector, la edición en la línea siguiente modifica el vector original.

Como he comentado antes, no es posible tener más de un borrow_mut en el mismo ámbito, en este caso, como el borrow_mut no se asigna a ninguna variable, sólo existe en esa línea, por lo que el borrow que hay en el print funcionará.

Con el uso de Rc se pueden crear ciclos, con tipos que se referencian a sí mismos y para evitar estos ciclos existe otro tipo que es Weak, que es una referencia, pero que no cuenta a la hora de eliminar el valor de memoria, por lo tanto pueden existir referencias tipo Weak que apunten a memoria ya liberada, y por esto el tipo Weak no se derreferencia automáticamente, hay que llamar al método upgrade que devuelve un Option<Rc>, y si la memoria ya se ha liberado será None.

Arc y Mutex, Rc y RefCell pero thread-safe

La combinación Rc<RefCell<T>> nos permite tener varias referencias a la misma zona de memoria, y modificarla, pero no es posible pasar estos tipos entre hilos. Rust ofrece un par de tipos similares, pero que sí son thread-safe, lo que quiere decir que nos asegura que no hay data race, es decir, que la memoria siempre es consistente, aunque usemos diferentes hilos para leer y modificar estas variables.

Para esto podemos usar la combinación Arc<Mutex<T>> que se usa de forma similar a Rc<RefCell>, pero que nos asegura que es seguro usar entre diferentes hilos:

use std::sync::{Arc, Mutex};

fn main() {
    let v = Arc::new(Mutex::new(vec!(1,2,3)));
    let v1 = v.clone();
    v1.lock().unwrap().push(4);
    println!("v[3]: {}", v.lock().unwrap()[3]); // -> 4
}

ejecutar

En este ejemplo no hay ningún hilo, pero vale como ejemplo, similar al ejemplo anterior. Aquí hay que hacer el unwrap después del lock, porque esta llamada puede fallar, en este ejemplo no se controlan los errores, pero en código de producción no se debería hacer el unwrap directamente, sino que se debería controlar el Result que devuelve, si es del tipo Ok o Err.

Monkey Patching

danigm — Thu, 02 Feb 2017 00:00:00 +0100

Qué es el Monkey Patching

El Monkey Patching es una técnica de programación de los lenguajes dinámicos que consiste en modificar el código en tiempo de ejecución.

Esto quiere decir que en lugar de modificar el código fuente de una clase, por ejemplo, en tiempo de ejecución asignamos otra función a ese método y todas las llamadas posteriores en lugar de ejecutar el código definido en la clase ejecutarán el código "parcheado".

Esto está relacionado con el llamado Duck typing, que viene a decir que si nada como un pato y suena como un pato, esto es un pato. Y esto del pato hace referencia a que los tipos no tienen que cumplir una interfaz estricta, simplemente, si se comportan como tal, es el tipo esperado. Y con el Monkey Patching podemos hacer que un perro haga cuak como un pato, modificando el objeto perro en tiempo de ejecución.

If it walks like a duck and talks like a duck, it’s a duck, right? So if this duck is not giving you the noise that you want, you’ve got to just punch that duck until it returns what you expect.

-- Patrick Ewing

Qué hay que tener en cuenta para el Monkey Patching

Para poder hacer Monkey Patching necesitamos, tipado dinámico, ya que si un método espera un objeto tipo pato y le pasamos uno tipo perro, pero "parcheado", el método no debe quejarse.

También tenemos que tener en cuenta la vida útil de los módulos y objetos. Si parcheamos un módulo, es necesario conocer el alcance de esas modificaciones, si sólo afectarán a mi módulo o si pueden afectar a otros módulos que lo importen, o si parcheamos una instancia, es necesario conocer hasta dónde llegarán esas modificaciones.

Y por supuesto también es necesario tener acceso a las partes del código que se quieran modificar, si vamos a modificar un objeto con métodos privados.

Por suerte, en Python no tenemos métodos privados realmente, se suele usar el guión bajo (_metodo), que según la herramienta lo oculta como privado, pero en realidad en Python todo es accesible y por tanto podemos parchear lo que queramos.

Algunos ejemplos

Veamos el ejemplo que viene en la wikipedia:

>>> import math
>>> math.pi
3.141592653589793
>>> math.pi = 3
>>> math.pi
3

En este ejemplo se ve que se importa el módulo math y se modifica el valor de math.pi. Fácil y sencillo. No tiene mucho sentido este cambio, pero si lo hacemos en nuestro código, ya todo el código que venga después y use math.pi recibirá como valor 3, y esto afecta incluso a librerías de terceros.

Algo más práctico con código Django:

from django import shortcuts

old_render = shortcuts.render

def custom_render(*args, **kwargs):
    t1 = time.time()
    resp = old_render(*args, **kwargs)
    s = time.time() - t1
    print("Render time: %s seconds" % s)
    return resp

shortcuts.render = custom_render

En este ejemplo modificamos el comportamiento por defecto de la función render de django. Reemplazamos esta función por otra que lo único que hace es medir el tiempo que se tarda en la llamada a la función inicial y sacarlo por pantalla.

Otro ejemplo con Django:

def password_logger(self, newp):
    send_to_hacker_email(self.username + ":" + newp)
    self.real_set_password(newp)

user = User.objects.get(username="admin")
user.real_set_password = user.set_password
user.set_password = password_logger

Aquí se muestra cómo se puede modificar una instancia. En este ejemplo se modifica el método set_password del usuario admin, para que cuando se llame a este método se envíe la nueva contraseña por email a un presunto hacker.

En el caso de los modelos de django no tiene mucho sentido modificar la instancia, mejor sería modificar el modelo, la definición de la clase, pero vale como ejemplo.

Cuándo usar el Monkey Patching

El Monkey Patching es una herramienta muy poderosa, pero a la vez, es algo tremendamente peligroso, ya que hace que una clase o un módulo no se ejecuten como se espera, como dice su definición y por tanto puede dar más de un dolor de cabeza.

Un gran poder conlleva una gran responsabilidad

-- Ben Parker

Por esto hay que saber cuándo usar el Monkey Patching y cuando no.

Cuando SÍ:

Depuración o ejecución paso a paso: pdb, ipdb, mientras depuramos un código para que nos saque información por pantalla, etc.
Testing: Para reemplazar métodos, atributos o funciones en tiempo de ejecución en los tests, por ejemplo una función que genera números aleatorios la podemos transformar en algo predecible para testear otros métodos relacionados, o podemos reemplazar funciones que tarden mucho tiempo debido a sistemas externos, para que los tests se puedan ejecutar rápidamente.
Fixs o arreglos de libs externas: Para aplicar un parche o un arreglo de una biblioteca externa en una versión que aún no ha sido parcheada oficialmente.

Cuando NO:

En la mayoría de las ocasiones, no es recomendable usar Monkey Patching. Por lo tanto, si hay otra forma de hacer lo que queremos hacer, seguramente sea mejor idea que el Monkey Patching.

Como he comentado antes, el Monkey Patching hace que el código que se ejecuta sea diferente del descrito en la definición de la clase o módulo, por tanto, hay que evitarlo y cuando se use hay que documentarlo muy bien, porque si no, puede enmascarar problemas o hacer que futuras modificaciones al código original no tengan efecto.

Resumiendo, el Monkey Patching está muy guay, pero úsalo bajo tu propia responsabilidad.

Rust

danigm — Tue, 24 Jan 2017 00:00:00 +0100

El lenguaje de programación

Llevaba ya algún tiempo escuchando hablar de Rust, en diferentes círculos. La primera vez que escuché hablar de él fue en un FOSDEM, hace ya unos años, cuando estaban empezando con servo, pero ahí no le presté demasiada atención. Luego he visto varios comentarios por diferentes redes sociales gente a la que sigo y cuya opinión sobre tecnología valoro bastante y entonces me empezó a llamar más la atención.

Pero realmente lo que me hizo interesarme de verdad por este lenguaje fue el enlace que me apareció un día en mi firefox. Firefox pone de vez en cuando mensajes y enlaces en la página de búsqueda por defecto y hace unos días vi que hablaban de servo y pinché en el enlace.

Y a partir de ahí empecé a leer sobre rust. Me interesó y me leí el The Rust Programming Language y me empezó a gustar. La sintaxis, la gestión de memoria, la compatibilidad con C... Estuve jugando un poco con el lenguaje, haciendo algunos ejemplos y programando. Y ya que estaba interesado, también me leí el libro Why Rust?.

Jugando con Rust

Para aprender a programar con un nuevo lenguaje no basta tan sólo con leerse la documentación, lo más importante es ponerlo en práctica. Y para eso, pensé en resolver algunos problemas matemáticos sencillos, y empecé a resolver problemas de Project Euler con rust.

Con este proyecto empecé a trastear con la herramienta Cargo, que es una de las cosas geniales de Rust, estuve tratando con los módulos, la documentación y los tests. Pero realmente estos problemas son simples problemas matemáticos, que no requieren de estructuras complejas y de más de una o dos funciones, por lo que a nivel de programación, no me encontré con ningún problema, ni estaba viendo lo realmente diferente de Rust con respecto a otros lenguajes como C o C++.

Así que decidí hacer algo un poco más grande, y ya que estaba, pues hacer algo útil. Estuve valorando unos días, qué herramienta podría implementar, y un día, explorando los crates publicados en crates.io, vi que no había gran cosa sobre lectura de EPUB, así que me decidí a implementar algo sencillo, ya que había estado trasteando con este formato para integrarlo en gnome.

Un EPUB no es más que un zip con ficheros XML dentro, por lo que para un parseo básico se necesitan pocas dependencias. La parte de zip fue fácil, porque el crate zip provee la lectura básica de ficheros. Donde me encontré con problemas reales fue a la hora de parsear los XML y sacar la información del documento.

En un EPUB hay un documento XML donde se especifica toda la información del libro, los metadatos, una lista de recursos y una lista con los "capítulos", que no son más que referencias a recursos XML definidos anteriormente. Mi objetivo era parsear este XML y poder acceder a diferentes elementos y atributos de forma más o menos fácil. El crate de XML que usé me daba una forma de parsear un XML, pero de manera secuencial, no me devolvía ningún tipo de dato con la estructura del árbol XML, así que me lo implementé.

La implementación es algo sencillo, un nodo, que tiene una lista de nodos hijos, y que puede tener un padre, para poder recorrerlo arriba y abajo.

Y al implementar esta estructura en Rust me encontré con el borrow checker y la gestión de memoria de Rust. Voy recorriendo el XML y creando los nodos conforme me los voy encontrando, luego hay que añadir el nodo hijo al padre y referenciar el padre en el hijo. Y eso me costó bastante. Hasta que finalmente comprendí como va el tema de las referencias en Rust y la "propiedad" de la memoria y variables. Esto está muy bien explicado en el libro Why Rust?.

Subí el repo epub-rs a github y creé el crate correspondiente, con la documentación generada automáticamente, que además son tests unitarios.

Lo malo de Rust

La sintaxis en algunos casos es demasiado ofuscada, lo que hace a primera vista sea "feo", el uso de "!" para macros, el "&", "*", "->", "=>", "::", ":", "<<>>", "| |", muchos símbolos de puntuación en el código.

Las conversiones y transformaciones implícitas, hacen que muchas veces no tengas que poner el "*" pero realmente se esté haciendo la dereferencia y cosas similares. Viniendo de python, tengo bastante claro que siempre es mejor explícito que implícito, porque siendo implícito tienes que conocer al detalle el lenguaje para poder leerlo sin ambigüedad, y siendo explícito, todo es mucho más coherente, sin tener que conocer detalles internos.

Lo bueno de Rust

Cargo: Un gestor de paquetes, compilador, generador de documentación, etc. Engloba todo lo básico para gestionar cualquier proyecto rust de forma fácil.
Tests en la documentación: Esto es genial, en python están los doctest, pero en Rust esto es lo recomendado para documentar y la verdad es que unificar documentación y tests unitarios es lo mejor para que la documentación siempre sea coherente con la implementación.
Compatibilidad con C gratis: Es trivial que una biblioteca Rust se pueda usar desde C y viceversa, por lo que en Rust tienes todo lo de C.

Conclusiones

Rust es un lenguaje genial. Me he sentido muy cómodo programando en Rust, en casi todo momento, excepto en las ocasiones en las que me he tenido que pelear con el borrow checker, pero en teoría eso es lo que le da la seguridad al lenguaje, así que mejor corregir los problemas en tiempo de compilación que en lugar de encontrarte con segmentation faul o memory leaks meses después.

La comunidad que hay alrededor de Rust es bastante impresionante, teniendo en cuenta es un lenguaje moderno, nacido en 2010, y parece su uso se está extendiendo rápidamente.

Por lo tanto, y a riesgo de equivocarme estrepitosamente, apostaría a que Rust será en el corto/medio plazo uno de los lenguajes de programación más importantes y habrá muchas cosa grandes y pequeñas hechas con Rust, empezando por firefox.

Principalmente programo en Python y de momento este lenguaje será mi primera opción a la hora de resolver cualquier problema. Pero Rust no está tan lejos de Python, por lo que será mi opción siempre que me encuentre con el problema del rendimiento. En cualquier caso, no descarto reemplazar Python por Rust como mi lenguaje para "todo" en un futuro, lo que sí tengo claro es que a día de hoy elegiría Rust por delante de C, C++, java, go y scala.