The problem I'm having with dependabot is that it opens PRs for upgrades
that won't pass CI without a lot of work, e.g. upgrading winit (
https://github.com/servo/servo/pull/26256), and as a result I treat emails
I get for dependabot PRs as quite likely to involve wasted effort.
The situation woul
Would the idea be to have two top-level dirs, `mozjs` and `mozjs_sys` each
of which has its own `Cargo.toml`? So the crates would be the same, it's
just the repos that are merging?
On Fri, Jan 10, 2020 at 10:31 AM Manish Goregaokar
wrote:
> This seems good to me.
>
>
> On Fri, Jan 10, 2020, 9:59
I've been using the IRC <-> Matrix bridge and the matrix client, and I've
been quite happy with them. I'd be in favour of moving to matrix, it seems
pretty decent, the ToS / CPG will be easier, and there's a certain weight
in numbers. The main effort would be updating the bots, but with a bit of
lu
at 7:15 PM Robert O'Callahan
wrote:
> On Wed, Jun 5, 2019 at 4:16 AM Alan Jeffrey wrote:
>
>> We're interested in doing the experiment of how to increase the amount of
>> determinism in a program like Servo where almost all the nondeterminism
>> that'
We're interested in doing the experiment of how to increase the amount of
determinism in a program like Servo where almost all the nondeterminism
that's observable by Servo has a single cause (in Servo's case selecting on
channels). There'll still be a lot of nondeterminism in the system (e.g.
depe
Excellent!
Alan.
On Wed, Sep 20, 2017 at 11:03 AM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> Hello friends of Servo!
>
> We're happy to announce the availability of a pre-alpha version of
> libservo, a Rust embedding API for Servo.
>
> You can find documentation for the API and a t
The other thing I learned the hard way is not to #N-mention any issues
that aren't to be closed when then PR is merged.
On Wed, Mar 1, 2017 at 9:13 AM, Jack Moffitt wrote:
> It contains a cohesive description of the entire set of changes. It
> would be a shame to omit it. In the cases of a P
Also agreed. Most weeks, I do my weekly update on Monday (OK, OK, not this
week) and I usually find it interesting scrolling through other people's
updates. Future me is also pleased with past me for doing it, when it comes
to writing "what the heck did you do last quarter/year/decade" summaries.
There will always be some single points of failure, e.g. the bhtml browsing
context, or the gfx context. The constellation is doing double duty, acting
as both the centralized message router, and the manager of browsing
contexts (e.g. navigation). We could try to separate out these two roles,
and h
We're currently testing -M but not -M -S, e.g. see:
https://github.com/servo/saltfs/blob/master/buildbot/master/files/config/steps.yml#L46
I don't think there's any great reason for not testing sandboxing as well
as multiprocess. We're testing multiprocess for Mac and Linux, not Windows
as multip
t throw away information about a crash, it's
> always been my experience that having the full story helps..
>
> On Sun, Jul 3, 2016 at 8:50 AM, Alan Jeffrey wrote:
>
> > There's already a PR to buffer up warnings for inclusion in the crash
> > report. Once that la
Yes, this sounds like a good idea, especially if we can migrate issues.
On Jul 5, 2016 06:03, "Manish Goregaokar" wrote:
> I like this idea
>
> -Manish Goregaokar
>
> On Mon, Jul 4, 2016 at 9:06 PM, Josh Matthews
> wrote:
>
> > While there can be advantages to having them integrated directly int
rt these errors in a
truncated form (single line with error contents and location), and bhtml
can either filter these out or include them in the error reporting box
until it gets a real backtrace
-Manish Goregaokar
On Sun, Jul 3, 2016 at 9:11 PM, Alan Jeffrey wrote:
> The problem is the mess
The problem is the messages can arrive to the constellation out of order.
The constellation passes then on to browser.html, which I believe just
reports the first one. We could try to be cleverer than that and batch them
up, and wait before reporting. Or, as Manish suggested, we could filter out
ch
Yay, excellent work tracking this down!
On Jun 24, 2016 20:06, "Shing Lyu" wrote:
> Hi all,
>
> Last week, we found that our average page loading time test has a 25%
> improvement. After carefully bisecting the commits, we found that PR #11513
> (https://github.com/servo/servo/pull/11513) by fdur
Another shot at an improved DOMString representation. This one uses one of
3 representations: either a String, an inlined string (for < 16 bytes) or
an interned string:
https://github.com/asajeffrey/servo/tree/domstring-use-atom-or-inlined-string
I did lots of hoop-jumping to get it to fit in the
0, and it has had a few refinements since
> then. Maybe some kind of caching would help Servo, too.
>
> Andrew
>
> On Wed, Dec 2, 2015 at 1:05 PM, Alan Jeffrey wrote:
>
> > Well, I tried eliminating the buffering, but I still didn't get any perf
> > be
Well, I tried eliminating the buffering, but I still didn't get any perf
benefit, if anything there was a degrade. Sigh.
https://github.com/asajeffrey/servo/commit/1533238eb822688572a04d5bd6eb8ac88297
On Wed, Dec 2, 2015 at 10:49 AM, Nick Fitzgerald
wrote:
> And there is also ArrayString[0]
dings as well) is copying (often very
> > small) SpiderMonkey strings into heap allocated DOMStrings.
>
> Alan Jeffrey has been investigating issues around string copying as
> well. Have you chatted with him to compare notes?
>
> jack.
> ___
19 matches
Mail list logo
