Re: [dev-servo] RFC: Require rustup.rs to build Servo with mach

I'm all for it, though I seem to recall there was some issue about needing two versions of Rust? How will we support the two different pinned versions (one for ./mach build and one for ./mach build-geckolib)? jack. On Tue, Nov 14, 2017 at 3:41 AM, Simon Sapin wrote: > In https://github.com/servo

Re: [dev-servo] Let's merge core-foundation-rs, core-text-rs, and core-graphics-rs

rs, core-text-rs, and > core-graphics-rs into the cocoa-rs repository (while keeping the crates > separate), and just leave it named cocoa-rs. This is similar to the > html5ever repository encapsulating html5ever, xml5ever, and markup5ever. > > On 10/25/17 3:23 PM, Jack Moffitt wrot

Re: [dev-servo] Let's merge core-foundation-rs, core-text-rs, and core-graphics-rs

winapi works similarly right? What do you propose as the new crate name? macos? apple? jack. On Wed, Oct 25, 2017 at 2:17 PM, Josh Matthews wrote: > Considering how intertwined these three crates are (in that there's always a > fun dance to update their dependencies when one of them changes), it

Re: [dev-servo] RFC: Require Python 2.7.9+ (for TLS Server Name Indication)

Can we make the script fail with an error if they don't have the right version? Maybe with --use-older-python-and-pray they can use to try anyway. If we just warn they are likely to miss the warning and just notice it doesn't work, whereas if we fail first, they'll at least know something is wrong,

Re: [dev-servo] Servo running on Ryzen

I assume this just works as Ryzen CPUs are still x86-64. One way to check would be to write a quick program using https://github.com/seanmonstar/num_cpus and see what it reports. If it reports the right number it should be fine. Servo's threadpools scale off this number, and so CSS styling and layo

Re: [dev-servo] [stylo-team] Mozilla central backout support arriving to Servo later this week

Thank for everyone's efforts here. There never seems to be a perfect solution in technology, but I am happy we've found a solution that satisfies most of the constraints and were able to deploy it in time. For anyone that didn't already see it, glob wrote about the design here: https://blog.glob.c

[dev-servo] Fwd: Incremental compilation and other compile time tricks

-- Forwarded message -- From: Nicholas Nethercote Date: Wed, Apr 5, 2017 at 8:35 PM Subject: Re: [dev-servo] Incremental compilation and other compile time tricks To: "dev-servo@lists.mozilla.org" `mach cargo check` is worth listing in Servo's README.md, IMO! Nick On Sat, Apr

[dev-servo] supporting browser benchmark suites

We'd like to be able to compare Servo's performance on well known browser benchmarks. I suggest we focus on Speedometer[1], JetStream[2], MotionMark[3], and EmberPerf[4]. Servo is not currently able to run any of these. Our first task is to attempt to run Servo on all these and get bugs filed for

Re: [dev-servo] seanmonstar and hyper are really great!

> Thanks Sean! Both you and hyper are a pleasure to work with on a regular > basis. I second this whole-heartedly. Hyper provides a large amount of value to us, but also to the whole Rust ecosystem. Thank you! jack. ___ dev-servo mailing list dev-servo@

Re: [dev-servo] Incremental compilation and other compile time tricks

C has less dependency info than rust. So there is hope that this time will be different :) jack. On Fri, Mar 31, 2017 at 14:56 Simon Sapin wrote: > On 31/03/17 20:25, Keith Yeung wrote: > > If this becomes an occasional problem, can we simply just connect to the > CI > > build machines and run `

Re: [dev-servo] Plans for implementing progressive web metrics

> Together, these metrics will give us information on the graphical timeline > showing: > * how long after a page was requested before the first visual change > occurred > * how long after that before the first nontrivial visual content appeared > * how long after the page was requested before it w

Re: [dev-servo] Partial layout flushes

> How would it handle the common failure mode I'd really like to address, > where a page does: > > 1) Modify style. > 2) Ask for layout data. > 3) Modify style. > 4) Ask for layout data. > > At step 4, will we just need to wait for the layout from step 2 to complete > before we can start the ne

Re: [dev-servo] Partial layout flushes

Responses to layout queries are just sent messages (if layout needed invoking to answer them). It is possible to send them early as soon as the relevant data has been computed. Servo does not do this currently though. An initial implementation could just reply with the answer and then keep running

Re: [dev-servo] Servo Build failing on Linux

Awesome! Glad it worked out. Welcome to the bleeding edge :) jack. On Fri, Mar 17, 2017 at 3:48 PM, wrote: > On Friday, March 17, 2017 at 2:31:49 PM UTC-4, Jack Moffitt wrote: >> I suspect something got messed up in a previous aborted build. Please >> try mach clean and rebuild

Re: [dev-servo] Servo Build failing on Linux

I suspect something got messed up in a previous aborted build. Please try mach clean and rebuilding. jack. On Fri, Mar 17, 2017 at 12:11 PM, wrote: > On Friday, March 17, 2017 at 12:59:19 PM UTC-4, Jack Moffitt wrote: >> At the terminal if you type "pip" does it print o

Re: [dev-servo] Servo Build failing on Linux

At the terminal if you type "pip" does it print out the help text or does it say command not found? Servo is expecting this to be in your PATH. jack. On Fri, Mar 17, 2017 at 10:54 AM, wrote: > On Friday, March 17, 2017 at 12:40:52 PM UTC-4, Emilio Cobos Álvarez wrote: >> Seems like you don't ha

Re: [dev-servo] Proposal: remove testing of and support for MinGW builds

I don't think this removal will affect much in the current Quantum plans. rustc itself is not removing the mingw target, so individual pieces will probably still work. We don't really have the resources to keep this alive longer than necessary, and it mostly affects bootstrapping and the final bina

Re: [dev-servo] Error while building servo in Windows

How much RAM does your machine have? I assume you mean RAM and not disk space. Although if you are out of RAM it might start to use disk for swap and if there's not much left I can see how that would happen. Generally on linux/mac it has required 4GB of memory to compile Servo. If you have less th

Re: [dev-servo] Error while building servo in Windows

It appears you do not have /c/Python27 in your path. Can you `echo $PATH` and see if it's missing? I would also suggest trying to build the MSVC version instead of the GNU toolchain version, but that also requires Python in the Windows path. jack. On Thu, Mar 16, 2017 at 8:07 AM, Malsha Ranawaka

Re: [dev-servo] Android support

> - glutin may not be something we want to keep using. I haven't looked in > details yet but glutin may be too high level an opinionated for us in this > context (eg. can glutin let us display several ServoViews?). > > So my current plan of action is to verify whether glutin is suitable or not > on

Re: [dev-servo] Please avoid @-mentioning people in commit or PR messages

I agree that seems noisy and irrelevant I could have sworn we previously had a patch to homu to remove the template. Did this regress or am I misremembering? jack. On Wed, Mar 1, 2017 at 10:29 AM, Emilio Cobos Álvarez wrote: > On Wed, Mar 01, 2017 at 08:13:36AM -0700, Jack Moffitt wrote: &g

Re: [dev-servo] Please avoid @-mentioning people in commit or PR messages

It contains a cohesive description of the entire set of changes. It would be a shame to omit it. In the cases of a PR with a single commit, this is the same as the commit message by default I think, but perhaps we detect that and don't duplicate. jack. On Wed, Mar 1, 2017 at 7:41 AM, Kartikaya Gu

Re: [dev-servo] NC State Team working on "Tracking intermittent failures over time project"

Welcome! I think it's hard to understate the pain that intermittents cause, and we're very grateful for the work you are undertaking to help address them. jack. On Tue, Feb 28, 2017 at 9:46 AM, Erika Eill wrote: > Hello! > > We are a team of three NC State graduate students in an Object Oriented

Re: [dev-servo] Quantum CSS (stylo) builds now on m-c

> Firefox itself will run CI as usual so Firefox can't introduce bugs. Servo > may uncover a bug that needs Firefox changes to fix, in which case you have > to submit the unified change via the Firefox contribution process. We are hoping this case will be very rare, and Manish and others are willi

Re: [dev-servo] Proposal: move the source code for rust-selectors into servo/servo

To followup, the core team is in favor of this change, and since it already landed, there's nothing more to do. I do think it's useful to decide what to do about the old repo. Do we put a big sign on it pointing to servo/servo? Or do we keep up synced to take PRs? jack. On Thu, Feb 9, 2017 at 10

Re: [dev-servo] Proposal: move the source code for rust-selectors into servo/servo

I think the complexity of the wpt-style setup is overkill, but I think we could do something to alleviate the community participation issue. We could perhaps keep the rust-selectors repo around and following the Servo in-tree one. PRs could still be done by external contributors the rust-selectors

Re: [dev-servo] Proposal: move the source code for rust-selectors into servo/servo

> In general, I posit that Mozilla completely, utterly, lost against V8 in the > embedded department in a huge part because of this mono-repository thing > where everything is muddled together. I don't think anyone is disagreeing with you on this point. The plan is as it always has been - to spl

Re: [dev-servo] Proposal: move the source code for rust-selectors into servo/servo

Let's allow until Friday afternoon for feedback to come in, but I don't think it makes sense to delay this decision. jack. On Wed, Feb 8, 2017 at 12:23 PM, Simon Sapin wrote: > On 08/02/17 19:42, Bobby Holley wrote: >> >> Won't they need to do this anyway? At least assuming we accept your >> pro

Re: [dev-servo] DOM goals for 2017

The only missing piece to this is the performance work / magic dom exploration. I am already excited for next year :) jack. On Wed, Dec 14, 2016 at 10:09 AM, Patrick Walton wrote: > These seem like exactly the goals I'd come up with, as an occasional > contributor to the DOM. +1! > > Patrick > >

Re: [dev-servo] Moz2d rendering backend

> My preference is to remove the azure code from git - it seems unlikely we'll > be working on printing any time soon, and we will always have the history in > git. This is my preference as well. I think when we want to work on printing, there may be better ways than what we have now anyway. I thi

Re: [dev-servo] Servo testing as part of PhD dissertation

> In addition to feeling less novel, QuickChecking JS > APIs doesn't feel quite as useful for Servo testing (based on the > assumption that Servo will be re-using *Monkey). Most of the JS APIs are part of the DOM and not the built in objects. These are implemented in the browser itself, not in Spi

Re: [dev-servo] Proposal: remove mingw Servo builds in favor of msvc

> Do people have opinions one way or another on this? I'm not dead-set > on removing it, and could definitely be convinced to just switch the > default to MSVC and hide the mingw documentation but keep testing it > if there are compelling reasons to do so. I'm in favor of removing it, but don't we

Re: [dev-servo] Proposal: TLS library for Servo

> Also, brand new-ness is not just a bad thing; > it also means that rustls can take advantage of modern knowledge on > what areas of TLS are more or less important and more or less > vulnerable. Several people heavily involved in the TLS standards process are at Mozilla and work on NSS. NSS and B

Re: [dev-servo] Proposal: TLS library for Servo

> Outside of the NSS team, who has more confidence in NSS than *ring* + > webpki + Rustls, BoringSSL, or OpenSSL? And, what is the reasoning? I think the assumption here is that many people outside the current Rust community would have more confidence in NSS, BoringSSL, or OpenSSL than Ring + rust

Re: [dev-servo] Servo testing as part of PhD dissertation

> I haven't quite settled on my dissertation topic, but my top contender at > the moment involves property-based (i.e. QuickCheck style) generation of > random web pages/stylesheets. A sort of subtask of this which would be extremely useful is taking a known rendering problem and producing a minim

Re: [dev-servo] Proposal: TLS library for Servo

> NSS doesn’t currently support building as static libraries. Do you think it > would be better to try to use the system NSS or ship the libraries? Depending on the system one exclusively is one reason why our OpenSSL bindings suck. So we have to have it built by Cargo as a fallback. jack. _

Re: [dev-servo] Proposal: TLS library for Servo

> You seem to have a lot of confidence in MoCo's ability to support a > project on its own, and very little confidence in the Rust ecosystem > to maintain its chosen solutions. It seems very unlikely that Rust > projects will move to NSS over OpenSSL or *ring* once bindings for NSS > are available

Re: [dev-servo] Proposal: TLS library for Servo

> One thing I’m also looking at is how it could be possible to make the Servo > crypto library interchangeable via traitization (I might be making up words > now). That way, people who want to use Rust crypto can do so, and people who > would prefer a wrapper of a more established library can do

Re: [dev-servo] Proposal: TLS library for Servo

> So, got any good research papers on networking? My undestanding is that I/O is the bottleneck for networking, not the CPU. So research here tends to focus on elimination of network requests, optimizations to solve overhead (pipelining, keepalive), more efficient protocols, or better data compres

Re: [dev-servo] Proposal: TLS library for Servo

> I'm in agreement with Brian that *ring* and rustls seem like the way to go > first. Second, I would suggest rust-native-tls as a backup if it doesn't > work out. rusttls doesn't seem to support TLS 1.1, which seems like a non-starter. We'll probably want to dig up some data on how much of the we

Re: [dev-servo] Moving style out of tree as an alternative to frankenbuild?

> Your proposal scares me in the sense that (if I read it well) it would > be at least temporarily allowing changing the style system without > gating on Servo. There are architectural changes to the style system > that work for Gecko, but would completely break Servo. This would obviously be a fa

Re: [dev-servo] Moving style out of tree as an alternative to frankenbuild?

> The downsides of this model are: > > Servo has to periodically sync with style and resolve conflicts. I volunteer > as tribute to do these. I suspect they won't be too bad, and once stylo > settles down a bit there won't be many breaking changes. The other proposal includes making sure Gecko rel

Re: [dev-servo] The size of the tests/ directory

Do you both object just as much if ./mach puts the tests in tree via another mechanism than git clone of servo/servo? If we combined this with having our _mozilla tests in servo/servo until they are upstreamed, this would make contributing new tests just as easy as it is now and fix the repo integr

Re: [dev-servo] Mentors needed (on IRC)

Also, if anyone has new E-easy's, it would be good to get them filed before this event so that the group has a reasonable amount to work on. jack. On Tue, Aug 23, 2016 at 3:13 AM, Shing Lyu wrote: > Hi, > > I'll attend a bootcamp called "Taiwan Code Sprint", which is aimed to > introducing newco

Re: [dev-servo] How to smup?

> When does bindgen get called? Do I run it myself or is there an > orchestrating script or something? It's done manually and you need to do it once on every platform we support. It's not very fun. jack. ___ dev-servo mailing list dev-servo@lists.mozill

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

> Actually (though I've been busy implementing other things), I've been > planning a somewhat different way to solve the scalability problems that I > called "auto rollup." This is more or less the direction I've thought we'd move in as well. Basically try in bigger batches but have blame pinpoint

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

> My point is that I believe it's possible to create a setup doing full > pre-commit testing -- with all the advantages it brings over post-commit > testing -- while avoiding the scalability problems of the existing setup > is Servo. It depends what you mean by scalability. Doesn't pipelining the

Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

the benefits. Or perhaps an additional one for low-security ones > such as ads (perhaps based on tracking blocking lists). > > On Wed, Aug 3, 2016 at 5:43 AM, Jack Moffitt wrote: > >> Each process is a sandboxing boundary. Without security as a concern >> you would just have

Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

to one process. Maybe two, one for > high-security sites and one for all other sites. > > Patrick > > > On Aug 2, 2016 6:47 PM, "Paul Rouget" wrote: >> >> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote: >> >> First, is multiprocess and sandbo

Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

> First, is multiprocess and sandboxing actively supported? I tested this right before the nightly release, and it was working fine and didn't seem to have bad performance. Note that you can run -M or -M and -S, but not -S by itself (which doesn't make sense). Also note that -M and -S probably don

Re: [dev-servo] Blink's new layout proposal

It looks like they've refactored how the layout algorithm works, which is pretty interesting. Down in the performance section however, there seems to be a mix of ideas and very few of them involve parallelism. For example, they want to enable speculative layout to precalculate future animation fram

[dev-servo] intermittent triage

We have some data on which intermittents are causing the most problems. I've collected this data on this meta bug: https://github.com/servo/servo/issues/12424 Many of the worst intermittents are already disabled, but some are not. I propose: 1) We immediately disable the listed tests. It is not o

Re: [dev-servo] Servo contributor map

This is really cool! Also, "Right behind you" is the best location ever. It seems like we should pick one of these and include it on some future contributor stats page. Also, ,this is a nice screenshot for TWiS next week :) jack. On Wed, Jul 6, 2016 at 8:15 PM, Shing Lyu wrote: > Hi all, > > I'

Re: [dev-servo] Stacks reported in automated panic reports cannot be trusted

Is it possible to get the correct stack somehow? jack. On Sat, Jul 2, 2016 at 3:33 PM, Josh Matthews wrote: > Hi everyone! To my dismay, I have realized that the stack traces for > automated crash reports cannot be trusted for the purposes of marking issues > as duplicates or fixed by a more rec

Re: [dev-servo] Intro from one-half of RGSoC Team JaM

Welcome! jack. On Fri, Jul 1, 2016 at 11:47 AM, Malisa Smith wrote: > Hi everyone, > > Just wanted to introduce myself (@malisas7) as one-half of Team JaM, with > Jeena Lee (@theJeenaLee) as the other half. > > Our Rails Girls Summer of Code project is to implement the fetch API: > https://gith

Re: [dev-servo] Intro from the other half of Rails Girls Summer of Code (RGSoC) 2016

Welcome to the project! jack. On Fri, Jul 1, 2016 at 12:14 PM, Jeena Lee wrote: > Hi everyone, > > I am Jeena, the other half of this year's RGSoC. We will be working on the > Fetch API[0], and its issue page is here[1]. Many thanks in advance to the > Rust and Servo communities for helping us

[dev-servo] servo nightlies are live

Thanks everyone who helped; it was quite the long home stretch! Blog post: https://blog.servo.org/2016/06/30/servo-nightlies/ Demo video: https://www.youtube.com/watch?v=jJXW072MatI Enjoy, the servo team ___ dev-servo mailing list dev-servo@lists.mozill

Re: [dev-servo] New github milestone: Tech Demo

We've been using Paul's list to keep track of things thus far: http://paulrouget.com/bhtml-servo-issues/ jack. On Wed, Jun 29, 2016 at 4:59 AM, Manish Goregaokar wrote: > I've created a new milestone on GitHub, Tech Demo > . Please use it fo

Re: [dev-servo] Standardizing upgrade procedures for crates.io dependencies for servo/servo

I thought we had CI checks for duplicate packages, but it seems that is not the case? Or at least I did not seem them in .etc/ci. I can't even find an issue for it now :( In any case, I think this can be automated by CI to catch the problem. In general this is allowed by Cargo but we probably only

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

> Does this also mean servo is going to move off of homu, and lose pre-commit > testing? How is the contributor experience going to be impacted by the > change? Servo's own tests will still run pre-commit for both Servo and Gecko changes. Some subset of Gecko test will run post commit. If you chan

Re: [dev-servo] How to efficiently react to an element changing visibility status from DOM code?

> The problem is that you want notifications ahead of time that an element is > predicted to become visible, so you can decode images/video etc hopefully > in time to render the element the moment it becomes visible. Does this mean you need scroll velocity and other such data to make such a predic

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

> The API is probably fine, but there will be a *ton* of coordinated changes > across Firefox/WR here. Shader tuning, implementation bug fixing, etc. None > of these changes will be tested by the autolander in the context of Firefox > if WR is a separate repo, so they will have to get "bounced"

Re: [dev-servo] How to efficiently react to an element changing visibility status from DOM code?

How is this done in Gecko? We learn something is not visible during one of the various cullings of WebRender. So I guess the idea would be to have some notification you send when something goes from visible previously to invisible. I suppose there is an analog when doing flow construction that you

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

> 2) Move webrender and webrender_traits back into the Servo repository. > > Because WebRender and Stylo are the two biggest projects that will > need to be worked on in a cross-cutting way across Firefox and Servo, > we'd like to have them out of a separate GitHub repo (with its "update > version,

Re: [dev-servo] Servo without Bluetooth

> It would be nice if you can "drop in" features from above without requiring > daisy chaining, but AFAICT that's not always doable. > > It is possible currently to do `cargo build --features > net/devices/nameoffeature` without polluting cargo.tomls, but IIRC this > isn't always supposed to work (

Re: [dev-servo] Servo without Bluetooth

> Doing it via Cargo features sounds like the better option to me. I'm fine > with enabling building Servo without bluetooth support. +1. We've had environment variable hacks before, and while convenient, we usually end up regretting and removing them. jack. __

Re: [dev-servo] How to disable Rust download and force use of pre-installed Rust?

> Second, I was looking for a way to completely bypass Rust download at build > time. I do have Rust 1.8.0 version which works on Power8/LE and I want to use > the pre-installed Rust version instead of downloaded one. You can control this behavior by customizing the servobuild file. See https://

Re: [dev-servo] Pull request template

I'm willing to give it a try. I'd suggest shortening up the text of the third one, and for the fourth one, add a "because:" so that they have to justify their lack of tests. jack. On Fri, May 6, 2016 at 9:13 AM, Josh Matthews wrote: > Github introduced templates for issues and pull requests a co

Re: [dev-servo] when to switch to webrender by default

> So is the idea that people without the ability to use webrender would need > to use the -c flag? The linux machine I use for Servo development yields the > "GL context creation failed" error, so if there were a way to make this > happen transparently that would be pretty great. Yes. I expect the

Re: [dev-servo] Proposal: cancel the weekly meeting

I hear no objections, so I'm canceling the standing meeting. jack. On Sun, Apr 17, 2016 at 11:31 AM, Lars Bergstrom wrote: > On Thu, Apr 14, 2016 at 2:46 PM, Manish Goregaokar > wrote: >> >> So yeah, +1 for cancelling. I do look forward to the meetings, since they >> give a nice overview of wha

Re: [dev-servo] when to switch to webrender by default

On Mon, Mar 28, 2016 at 11:33 AM, wrote: > On Monday, March 21, 2016 at 11:45:06 AM UTC-5, Jack Moffitt wrote: >> I propose the following straw man transition plan: >> >> 1. Keep -c, -g, -w command line options as they are, but switch the >> default setting to WebRe

[dev-servo] servo meeting canceled today

We have an empty agenda again, so keep hacking! jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] servo meeting canceled 4/4

Today's meeting is canceled as there is very little agenda. Lars encourages everyone to use the extra time to help him with TWiS :) jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] today's meeting canceled

There was no agenda to discuss, so we'll forgo today's meeting. See you all in IRC :) jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] when to switch to webrender by default

Now that WebRender has landed and been tested a bit, I'd like to start a discussion of when to switch to this backend as our default. Are there issues that people see as blockers to this? If possible, I'd like to do this sometime in Q2. I propose the following straw man transition plan: 1. Keep -

[dev-servo] servo meeting canceled today

The agenda was very light so we decide we'd just discuss that issue on the mailing list. Enjoy your hopefully now meeting free afternoon! jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Please don't leave PRs without an assignee

On Wed, Mar 9, 2016 at 8:25 AM, Josh Matthews wrote: > Hi reviewers of Servo! As you've noticed, we recently started assigning > reviewers to new PRs by random selection. Sometimes this means that a > reviewer ends up assigned to a PR which they don't feel comfortable > reviewing, which is totally

[dev-servo] today's servo meeting canceled

Some of the team is together in Portland this week, and there was nothing on the agenda, so I've cancel the meeting today so everyone can keep working. If there is anything that needs attention, please ping us in IRC. jack. ___ dev-servo mailing list de

[dev-servo] servo meeting canceled today

Since it is a holiday in US and Canada, we're canceling the meeting today. See everyone next week. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] servo meeting time change (late meeting)

Based on feedback from everyone, we've decided to move the late Servo meeting to 2pm Pacific (2 hour earlier than it currently is). I've updated the meeting in the calendar, but if you don't use that, please made adjustments accordingly. The next meeting is the early meeting on Monday, so this me

[dev-servo] 1/18 meeting canceled for MLK day

As 1/18 is a holiday in the US, I'm canceling the late meeting Monday. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] servo weekly meeting timeslot polls

As discussed before the Monday afternoon (Pacific) meeting is not working out for us since neither Josh nor Lars can participate then. I've created two polls, one for each timeslot, to help us select new times that work for more people. The end goal is to try to find a pair of times that work on t

[dev-servo] holiday meetings canceled

I'm canceling the meetings today and next week for the holidays. Many of the team is out (especially next week). Please use the meeting time to review some PRs if you are still around :) Happy holidays everyone! jack. ___ dev-servo mailing list dev-serv

Re: [dev-servo] IndexDB project

ub.com/spacejam/rust-rocksdb?) > > -Manish Goregaokar > > On Tue, Dec 15, 2015 at 8:57 AM, Jack Moffitt wrote: >> >> Probably the easiest way to start is to get the database backend >> sorted. We've talked about using LevelDB for this in the past, but I'm &g

Re: [dev-servo] IndexDB project

Probably the easiest way to start is to get the database backend sorted. We've talked about using LevelDB for this in the past, but I'm not sure if there is an existing Rust wrapper for that or not. If not, creating one might be a good way to get started. jack. On Mon, Dec 14, 2015 at 8:20 PM, Sh

[dev-servo] Servo meeting canceled today

Our heads being full of Mozlando meetings, I think there is little new to talk about. I've canceled today's meeting, but ping in IRC if there is anything that can't wait until next week. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https:

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

> One of the largest performance bottlenecks in Element.getAttribute (and I > suspect a bunch of other webidl bindings 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 ch

[dev-servo] meeting time change

Since we were unable to find a nearby time that worked for the few with conflicts for the asian-timed meeting, I am leaving it in the same spot. I did however move it from Korean time to US Pacific time for consistency. Also, the meeting will now be in the normal Servo vidyo room instead of the ol

Re: [dev-servo] "Hacking Servo for noobs" moving it to servo repo or to wiki?

HACKING_QUICKSTART.md ? On Thu, Oct 22, 2015 at 8:36 AM, Simon Sapin wrote: > On 22/10/15 20:35, Josh Matthews wrote: >> >> I'd prefer a separate file. There's a lot of information in Paul's >> guide, and CONTRIBUTING.md should be a curated overview of only what is >> immediately relevant to a ne

Re: [dev-servo] new project meeting schedule proposal

> Does the early meeting need to move at all? I thought what promted this was > conflicts with the late meeting time. Not necessarily, but there was interest in having both times on the same day to reduce confusion. jack. ___ dev-servo mailing list dev-

Re: [dev-servo] new project meeting schedule proposal

Moving the meeting later is not great since it needs to be early for the comfort of people in Europe. Is Wednesday better? Yours was the only conflict brought to my attention. jack. On Tue, Sep 29, 2015 at 12:38 PM, Josh Matthews wrote: > On 2015-09-29 11:38 AM, Jack Moffitt wrote: >&

[dev-servo] new project meeting schedule proposal

As discussed on yesterday's call, I'd like to propose moving the meeting times to Tuesdays (in the US) as there are some conflicts with the current times. I'd also like to switch the afternoon time slot to follow US daylight savings time like the other slot, so that both meetings move together. Th

[dev-servo] PSA: try builds are working

I've been meaning to debug and fix try builds for a while, and decided to look into them today. It turns out that recent changes we've made to CI infrastructure have fixed them already. To do a try build, just use "@bors-servo try". I think only reviewers can do this. jack. __

[dev-servo] whether to move asian meeting time slot

As needs of our community change, so too must meeting times. A few people have brought to my attention that they have conflicts with the Asian meeting time and I thought it might be useful to change it since Glenn is the only regularly attendee that can only attend in that time slot. Would 2 hours

[dev-servo] monday servo meeting canceled for labor day

If there's anything urgent, please bring it up here on list or ping people. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] PSA: import blocks are now sorted

> I’m in favor of a single alphabetical-order group. Nicholas's points are all valid, and while I kind of like the groupings, I have no objection to a single alphabetical list. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.m

Re: [dev-servo] Multiprocess safety

For the memory profiler, it seems like some socket abstraction would work fine. The master process can just listen on a IPC socket and the messages can get broadcast to it. jack. On Thu, Jun 18, 2015 at 6:50 PM, Nicholas Nethercote wrote: > On Thu, Jun 18, 2015 at 5:45 PM, Patrick Walton wrote:

[dev-servo] rust-geom has been renamed to euclid

We got a request to publish rust-geom on crates.io, but someone had already put their geom library there. We made the decision to find a new name for our library and settled on euclid. The repo has been renamed and is now published on crates.io (https://crates.io/crates/euclid). Servo is not yet

[dev-servo] Use bors-servo to merge all repos

We are switching Servo's dependencies to be managed by Homu instead of manually merged. Please use `@bors-servo: r+` on all Servo organization repos from now on. Not all repos are yet converted however, but just pretend they are and if you fail to see Homu immediately start working, let someone kn

Re: [dev-servo] Best way to work on multiple branches concurrently?

Cargo target-dir sharing (soon to be enabled by https://github.com/servo/servo/pull/6306) will also not rebuild dependencies that haven't changed. We could add the ability to put the target directory outside of the servo tree (it's a trivial change, and cargo already supports this). It actually may

  1   2   >