SimonSapin

https://wiki.mozilla.org/Oxidation#Rust_Components is probably the most up to date

There’s things like finding an agreement over https://uspto.report/TM/87796973 and setting up everything in https://servo.org/governance/. And on the technical side, although it’s not a blocker for announcing: https://github.com/servo/project/issues/25

I don’t recall that disk size was ever something we’ve optimized or tracked. Why is it important?

The C API has JNI bindings, which is relevant to Android. https://github.com/servo/servo/tree/master/ports/libsimplese...

Setting priorities and direction is the responsibility of the Technical Steering Committee: https://servo.org/governance/

The plan is to later have a Board responsible for financial decisions. Paid sponsorship to Servo (not just to LF) can grant a seat on the Board but not on the TSC.

Despite the name the Linux kernel is only one of many projects hosted by the Linux Foundation these days. Browser engine to operating system relationships haven’t changed with this move.

The Linux Foundation is a legal and fiscal host for many projects, not just the kernel: https://www.linuxfoundation.org/projects/

For what it’s worth, these days WebRender is mostly being worked on by the Firefox graphics team at Mozilla.

Yes, I've had Rust code and C++/mbed code in the same program. But C++ is still an issue, I wrote a C wrapper for the one C++ method I was using. Doing so for all of mbed would be very tedious and fragile.

Servo's fork of rust-bindgen https://github.com/servo/rust-bindgen has some C++ support and might be able to generate bindings for all(?) of mbed (at least for a given hardware configuration), but I haven't tried.

Looks like it would help get libcore for your target more easily, yes.

Still, I'd like similar functionality to get in standard Cargo eventually.

Is it important, when there is no other thread or process that could use any resource you're holding?

I now have a "more real" panic_fmt in the repository:

    #[lang = "panic_fmt"]
    extern fn panic_fmt(details: ::core::fmt::Arguments, file: &'static str, line: u32) -> ! {
        println!("Panic at {}:{}, {}", file, line, details);
        let row_2 = ::gpio::Pin::output(::pins::ROW_2);
        let col_3 = ::gpio::Pin::output(::pins::COL_3);
        row_2.set_high();
        loop {
            col_3.set_low();
            ::busy_loop::wait_approx_ms(5);
            col_3.set_high();
            ::busy_loop::wait_approx_ms(200);
        }
    }

Note that println! is a macro I defined myself, it writes to the serial port.

I still don’t know about eh_personality, though.

Mach is what you interact with when doing stuff in Servo, but all the build-* sub-commands end up calling Cargo, which is what does the heavy lifting.

The typical `./mach build` command will download known-good versions of Rust Nightly and Cargo (unless that’s already done), call `cargo build` with some flags, then show a system notification when it’s done. That’s it.

Servo does this by default. (People who tried Servo but don’t otherwise develop in Rust didn’t like having random files in their home directory.)

Short answer: `extern crate foo;` doesn’t work if `foo` is an indirect dependency. So you cannot accidentally use something without declaring it in `Cargo.toml`.

Longer answer: when running rustc, Cargo passes individual `--extern bar=/path/to/bar.rlib` options for each direct dependency, not just a path to a directory with everything. You can see the exact command with `cargo build --verbose` or `cargo build -v`.

It was a happy day when Servo ditched a big hairy pile of makefiles + git submodules and switched to Cargo :)

Patrick refers to parallel layout here: in a text with many paragraphs for example, the contents of each paragraph can be laid out in parallel with other paragraphs. Then you only need to sum up the heights of earlier paragraphs to find the vertical position of each.

When printing though, you don’t know where to start page 10 until you’ve done the layout of earlier pages. There may still be some parallelism opportunity, but less than on screen.

If you want to preserve unpaired surrogates that are hex-encoded in JSON strings, WTF-8 could help. But it’s unclear to me that you should: https://tools.ietf.org/html/rfc7159#section-8.2

That’s roughly how UTF-8 works, with some tweaks to make it self-synchronizing. (That is, you can jump to the middle of a stream and find the next code point by looking at no more than 4 bytes.)

As to running out of code points, we’re limited by UTF-16 (up to U+10FFFF). Both UTF-32 and UTF-8 unchanged could go up to 32 bits.

No. This is an internal implementation detail, not to be used on the Web.

As to draconian error handling, that’s what XHTML is about and why it failed. Just define a somewhat sensible behavior for every input, no matter how ugly.

On further thought I agree. https://github.com/SimonSapin/wtf-8/commit/51abeef717a161ba9...

Opinions: no it’s not worth the hassle. Yes, "fixed length" is misguided. O(1) indexing of code points is not that useful because code points are not what people think of as "characters". (See combining code points.) http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/

See also http://tools.ietf.org/html/rfc6919

Every term is linked to its definition. https://simonsapin.github.io/wtf-8/#terminology Does this help?

This is actually where the name is from, I found it too funny to pass up: https://simonsapin.github.io/wtf-8/#acknowledgments https://twitter.com/koalie/status/506821684687413248

Sorry for hijacking it!

Yes. For example, this allows the Rust standard library to convert &str (UTF-8) to &std::ffi::OsStr (WTF-8 on Windows) without converting or even copying data.

This is intentional. I wish we didn’t have to do stuff like this, but we do and that’s the "what the fuck". All because the Unicode Committee in 1989 really wanted 16 bits to be enough for everybody, and of course it wasn’t.

I also gave a short talk at !!Con about this, with some Unicode history background: http://exyr.org/2015/!!Con_WTF-8/slides.pdf

http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ is a nice comparison of Python’s (2 and 3) and Rust’s Unicode handling.

Has (either in Go or in Rust) some kind of hysteresis behavior been considered, to deal with hot splits / stack trashing? For example: when a stack segment becomes unused, don’t free it immediately, but keep one (or N) "spare" in case it’ll grow again soon.

https://en.wikipedia.org/wiki/Hysteresis