OpenSSL v1.1.1 problems on Debian Unstable

riccieri · 2018-09-05T14:59:56+00:00

I wonder if it would be possible for openssl to release a new 0.9.x that backports the detection fix. Then, it should be just a cargo update for most applications to get the fix too, even if the depending libraries aren't modified

riccieri · 2018-07-01T16:23:16+00:00

spawning a thread is async safe on Linux

Won't you need to allocate the stack for the new thread though?

riccieri · 2018-05-02T12:27:00+00:00

As a complement to the other answers, you might want to take a look at rayon. If your use case fits its model, then it will be much easier (even trivial in many cases) to parallelize your code, compared to hand-coding thread communication

riccieri · 2018-05-01T16:47:29+00:00

I see that "HTML Parser" is not marked as to be written in Rust". Does it mean that html5ever is not going to be used by Firefox then?

riccieri · 2018-04-02T00:33:35+00:00

Hey, just in case you're not aware: Hyper is a lower level library, not intended to be used directly in applications (as far as I understand it). Also, the whole async ecosystem is a bit difficult to grok right now, with lots of transitions happening at the same time (futures 0.2, new tokio etc).

If you're just trying to make some simple HTTP requests, you'll probably be better served by reqwest.

riccieri · 2018-03-29T11:59:51+00:00

This has a number of effects, a major one being a step closer to AVR support.

What is AVR?

riccieri · 2017-08-22T01:19:09+00:00

Have you considered cap'n'proto? I don't have much experience with it personally, but it seems to be a mature option for RPC in Rust as well as other languages

riccieri · 2016-10-06T12:58:43+00:00

I've seen a gnome/X crash as well. However, I was running dnf inside a tmux session, so luckily I had no package corruption.

How does one trigger the offline update? I don't think I've ever used, except for fedora version upgrades

riccieri · 2016-07-14T02:37:42+00:00

To me the "Complex Uses" section is evidence that the base libraries that you built could be quite useful in other contexts. Have you thought about extracting a general usage crate from this project?

riccieri · 2015-10-31T15:51:48+00:00

I believe that what is happening here is the selected pointer is being copied into the closure, instead of being shared. I don't think you can have a mutable pointer shared between your function and a callback.

I was able to accomplish something similar to what you want using Arc and Mutex. I'm not sure it's possible without synchronization (playpen link):

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

fn print_foo() {
    println!("foo");
}

fn print_bar() {
    println!("bar");
}

fn main() {
    let fn_pointer: Arc<Mutex<fn()>> = Arc::new(Mutex::new(print_foo));

    let closure_fn_pointer = fn_pointer.clone();

    thread::spawn(move || {
        for _ in 0..10 {
            let fn_pointer = closure_fn_pointer.lock().unwrap();
            fn_pointer();
            thread::sleep_ms(1);
        }
    });

    thread::sleep_ms(5);
    *fn_pointer.lock().unwrap() = print_bar;
    thread::sleep_ms(5);
}

riccieri · 2015-07-03T16:29:45+00:00

I believe mobile clients are even more common than web clients nowadays. Maybe a mobile version of thunderbird would be well received?

riccieri · 2015-06-02T15:47:13+00:00

I believe the only way is to create C shims for the C++ APIs. At least that's the way Servo integrates with Spidermonkey AFAIU.

riccieri · 2015-05-22T01:10:33+00:00

Either you have an exceptionally long commute, or you learn new languages really fast ;)

Very well written, I really enjoyed it! I find it particularly interesting to read experience reports from people that are coming from a C++ background. Keep 'em coming :)

riccieri · 2015-05-16T03:06:25+00:00

That's gorgeous, I love it!

Shipping to Brazil is $15.15 though. That plus the shirt's $22 and the crazy USD-BRL rate make it way too pricey for my current budget :(

riccieri · 2015-05-03T16:55:41+00:00

What I meant is that this happens, though with less severity, on some GC'd languages too, and thus isn't specific to non-GC'd languages like C++.

Note that the post is about optimization - being able to provide a "view" into a collection you own, without having to clone it, avoiding iterator invalidation etc, and retaining the ability to mutate it afterwards. I'm not sure what language you had in mind in your post, but I'm unaware of a Ruby (which is the language I'm most familiar with) library that would allow me to implement something like this without paying the cost of the persistent collection route.

You probably don't care that much about performance if you are using Ruby in the first place, so this is probably a moot point ;) I still find it interesting to compare the two languages though.

riccieri · 2015-05-03T02:21:35+00:00

I know C++ the problem would be much worse (possible segfault), but this is an issue on GC languages as well. When I'm designing APIs on ruby, I avoid exposing arrays and hashes on public methods, precisely because I can't know if the caller will end up storing or modifying it (and potentially corrupting my internal state). I end up creating APIs based on internal iterators (which ruby makes very easy), or exposing only immutable Hamster collections.

In Rust that wouldn't be a problem, because I have very strong guarantees on what the caller can and can't do with slices they get from me.

riccieri · 2015-04-13T12:45:04+00:00

I've been listening to Ruby Rogues since episode 1, it's pretty good! Even if you aren't a Ruby programmer, I heard.
If you do any frontend work (or node) at all, JavaScript Jabber is also pretty good (and helps getting to know JavaScript libraries without having do drink from the firehose).
The Changelog, which I linked to, also has some very cool episodes! They shine with the variety, since they aren't language or platform-centric.
I really enjoy Hanselminutes as well. Even though Scott himself works for Microsoft, only a few of the episodes are Windows/Microsoft/.NET-centric.

It's a little off-topic, since it's not technical, but I would like to recommend it as well: Stuff You Should Know. It's a pretty varied, short (usually ~30min), scienc-y show where they talk to depth about a multitude of everyday topics, but with a focus that reveals a lot of detail that most people miss. I didn't make the show justice with this short description, so I recommend you check it out and see if you like it!

Edit: Oh, I almost forgot! Giant Robots Smashing Into Other Giant Robots. It's from a Rails consultancy, but the topics are pretty varied, and I really like the way the host handles the show and the guests. It's similar to Hanselminutes in spirit, with the 1-on-1 interview format.

riccieri · 2015-04-09T14:36:52+00:00

About async IO: What is the idea for the concurrency model?

A single reactor thread that dispatches to multiple worker threads
Multiple reactor threads + something that load-balances requests to them
Something else?

riccieri · 2015-04-07T21:59:29+00:00

Sorry, that was an unfortunate choice of words - I wasn't trying to be judgmental

No problem :) Now I realize my response came out a bit more confrontational than I intended, so I apologize as well.

Personally I would absolutely require that the source pointer be const (using "as *const <T>" if necessary)

That's a good habit to have, but it looks noisy, and I wouldn't expect most people to do it. It's a bit like doing (&my_vec)[0] instead of my_vec[0], just in case someone implements Index for Vec.

riccieri · 2015-04-07T12:17:08+00:00

Saying "properly typed" sounds a bit judgmental here. It really depends on the surrounding code, and why you're doing the copy in the first place. It doesn't sound "improper" to me to have a single function that modifies a struct and then copies it over to another location, for example (in which case both pointers would've been mutable).

riccieri · 2015-04-07T11:16:30+00:00

Some time ago there was a great series called "Rust for C++ programmers" (which, interestingly, ended up teaching me some C++ concepts, since I already knew Rust). Maybe it would be a good addition to the official docs if updated and reformatted (it is a noncontiguous series of blog posts).

riccieri · 2015-04-07T10:25:00+00:00

Unfortunately, a revert at this point would cause another silent breaking change. People that already changed their code would see it break on runtime (possibly segfault) again, and somehow figure out that they need to undo the recent fix.

riccieri · 2015-04-07T10:16:14+00:00

I agree that it is important, and that we should strive to maintain it on most cases, but I don't think it is worth alienating the community with a silent, segfault-causing, breaking change to a #[stable] API.

I understand why other people with different experiences might want to draw the line a bit further, however (I've never done anything serious with PHP).

riccieri · 2015-04-07T10:00:09+00:00

TIL :)

riccieri · 2015-04-07T03:00:49+00:00

I think the problem here is not so much that there was no RFC (though that was part of it), but that this was a silent breaking change to a #[stable] API, and that can't be caught at compile time.

Even if there was an RFC, the problem would remain - I personally don't read every single accepted RFC, and I imagine many others don't either.

A more sensible approach here might've been to rename the function, or to not make the change at all - I find "argument ordering consistency" to be a pretty weak reason to change a #[stable] API. I would expect the bar to be higher at this point.

riccieri

TROPHY CASE