We always talk about adding some devtools that give performance advice.
This would be visible to web developers, who are end users of the browser
in its role as a development tool. It's also visible to non-developer users
in that more and more sites will take full advantage of Servo's
I've been working on a new string type which will solve various problems in
html5ever, and which may be useful more widely in the Servo ecosystem. You
can find the design rationale here:
https://github.com/kmcallister/tendril#readme
as well as preliminary API docs:
How would you create a `JST` on the stack?
I'll provide some context. I'm designing the HTML parser API to be compatible
with different DOM representations. This is desirable for a few reasons:
- I want the library to be useful outside of Servo. It will have the
ability to output
A collision in a widely used cryptographic hash would be a major,
publishable security advance.
That's true for SHA-256 itself. But I ran the numbers, and it turns out brute
force search for a collision on a 128-bit hash (even with no algorithmic
weakness) is feasible. I wrote more on the
You could use a rope where individual chunks can be either UTF-8 or UCS-2.
UTF-8 strings would also record whether they happen to be 7-bit ASCII, and
UCS-2 strings would record whether they contain any surrogates (and also maybe
whether all surrogates are correctly paired according to UTF-16).
The JS folks are very
interested in trying to move away from pure-UCS-2, for memory reasons...
That's very interesting. Servo seems like a good place to prototype that with
a DOM to match.
Who should I talk to about JS string representation changes?
keegan
Or store the metadata immediately before the code, as GHC does for thunk entry
code.
keegan
- Original Message -
From: Niko Matsakis nmatsa...@mozilla.com
To: Patrick Walton pcwal...@mozilla.com
Cc: dev-servo@lists.mozilla.org
Sent: Monday, March 31, 2014 3:10:39 AM
Subject: Re:
Unfortunately I’d be less surprised if someone relies on having the two
halves of a surrogate pair in separate document.write() call, as this
seems more interoperable:
data:text/html,scriptdocument.write(\uD83D);document.write(\uDCA9)/script
The tokenizer's input is a queue of buffers, and
Should we implement character encoding detection [1] at the same time as the
rest of the HTML parser? It seems to be separable; the only design
interactions I see are:
- The character decoder and script APIs can write into the same input stream
- The encoding can change during parsing [2],
OK. It looks like writing a new parser directly in Rust (possibly using a
translated Tokenizer.java as a tokenizer starting point) is the sensible way
forward. I'm sorry about wasting your time with the translator.
Not at all :) It was an interesting project and definitely an approach worth
(replies inline to multiple messages)
I think the biggest unknown is memory management.
Is this the only thing that's blocking compilation
Unfortunately it's not. Some other problems I ran into:
- The Java code has static data with non-constant initializers that depend on
each other. For
2. Investigate if there's some way to hack around it (using RGB pixmaps
but somehow storing and reconstructing the alpha channel maybe?)
This sounds pretty workable to me. We can send alpha as the R channel of a
second pixmap/texture and the compositor can extract it within a fragment
This week I've been working on porting Servo to the current-ish version of
Rust. What I have so far is available at
https://github.com/kmcallister/servo/tree/rust-upgrade
The submodule commits should exist on https://github.com/mozilla-servo (some
only in pull requests at the moment).
I
At minimum we should newtype more of the integer IDs, to prevent mixing them up
with other integers.
keegan
- Original Message -
From: Robert O'Callahan rob...@ocallahan.org
To: Patrick Walton pwal...@mozilla.com
Cc: dev-servo@lists.mozilla.org
Sent: Monday, July 15, 2013 4:44:43 PM
14 matches
Mail list logo
