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
architectural
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:
https://kmcallister.gi
I have a proposal for the next evolution of zero-copy strings in html5ever:
https://github.com/kmcallister/tendril
This would contribute towards a number of goals including document.write,
non-UTF-8 content (~15% of the Web), reducing memory usage, and perhaps
speeding up text shaping / paint
I made a graph of our efforts porting Servo to new Rust versions, since January
2013.
SVG: http://people.mozilla.org/~mbrubeck/servo-rust-updates.svg
PNG: http://i.imgur.com/MMfy5Nr.png
Thanks to mbrubeck for hosting the SVG.
keegan
___
dev-servo mail
> How would you create a `JS` 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
>From js.rs:
/// A rooted, JS-owned value. Must only be used as a field in other
JS-owned types.
pub struct JS {
What happens if I break this rule and allocate a JS on the stack, or return
one from a function? Is that a memory safety violation?
keegan
- Original Message -
Fro
le for the rest seems promising,
though.
I also liked the idea of using Gecko to gather information about interned
strings.
keegan
- Original Message -
From: "Keegan McAllister"
To: "Patrick Walton"
Cc: danielmi...@gmail.com, dev-servo@lists.mozilla.org, "edy
> 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
- Original Message -----
From: "Robert O'Callahan"
To: "Keegan McAllister"
Cc: dev-servo@lists.mozilla.org
Sent: Wednesday, April 23, 2014 5:35:29 PM
Subject: Re: [dev-servo] Table-less string interning
It seems like it would be a good idea to instrument Gecko to gather
I opened this as a GitHub issue (https://github.com/mozilla/servo/issues/2217)
but I thought I'd mention it here as well.
The traditional approach for string interning is:
* Interned strings are pointers
* To intern a string, look in a hash table mapping strings to pointers
* If it's not found,
/html5/blob/sse/src/tokenizer/buffer_queue.rs#L182-L252
- Original Message -
From: "Keegan McAllister"
To: "Luke Wagner"
Cc: "Henri Sivonen" , "Boris Zbarsky" ,
mozilla-dev-se...@lists.mozilla.org, "Robert O'Callahan"
, "Eddy B
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
> 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,document.write("\uD83D");document.write("\uDCA9")
The tokenizer's input is a queue of buffers, and I'm
Or store the metadata immediately before the code, as GHC does for thunk entry
code.
keegan
- Original Message -
From: "Niko Matsakis"
To: "Patrick Walton"
Cc: dev-servo@lists.mozilla.org
Sent: Monday, March 31, 2014 3:10:39 AM
Subject: Re: [dev-servo] Crazy idea: CSS selector JITting
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], whic
> 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. F
Gecko's HTML5 parser is based on machine-translating the validator.nu parser
from Java into C++. We are developing [1] a Rust translation for use in Servo.
I've been working on that recently and I have some doubts about this approach.
Java and C++ share some features that Rust does not have.
> 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
shad
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 t
Likewise.
- Original Message -
From: "Brian Anderson"
To: "Jack Moffitt"
Cc: dev-servo@lists.mozilla.org
Sent: Wednesday, July 31, 2013 11:32:47 AM
Subject: Re: [dev-servo] new servo project meeting proposal
On 07/31/2013 08:35 AM, Jack Moffitt wrote:
> The following proposal only affec
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"
To: "Patrick Walton"
Cc: dev-servo@lists.mozilla.org
Sent: Monday, July 15, 2013 4:44:43 PM
Subject: Re: [dev-servo] Safe abstract
23 matches
Mail list logo
