Re: [dev-servo] Merging mozjs and rust-mozjs

[Manish Goregaokar]

This seems good to me.


On Fri, Jan 10, 2020, 9:59 PM Josh Matthews  wrote:

> Given how closely intertwined the two repositories are, and especially
> given we can no longer publish them to crates.io and have a pinned git
> revision in rust-mozjs's Cargo.toml, I propose that we merge the
> servo/mozjs and servo/rust-mozjs repositories into servo/mozjs. We can
> follow
>
> https://saintgimp.org/2013/01/22/merging-two-git-repositories-into-one-repository-without-losing-file-history/
> to retain the file history of rust-mozjs.
>
> I would like to initiate this merge as soon as the current SpiderMonkey
> upgrade that nox is working on is complete. Any objections?
>
> Cheers,
> Josh
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] The future of irc.mozilla.org/#servo

[Manish Goregaokar]

My main concern is that I would rather not have to run Yet Another electron
app, especially given the terrible battery life my laptop has on Linux.

It seems like I should be able to bridge with irssi, or perhaps try out a
web based client, so I'm fine with switching, but i'm also okay with
staying.

-Manish Goregaokar


On Thu, Dec 19, 2019 at 10:27 AM Alan Jeffrey  wrote:

> 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
> luck there may be off-the-shelf solutions, we won't be the only
> github-based software project wanting a matrix bot!
>
> A.
>
> On Thu, Dec 19, 2019 at 12:20 PM Simon Sapin  wrote:
>
> > I’ve been mostly happy with IRC, but for #servo I think I’d like to try
> > out Matrix
> > since many Mozillians will need it anyway.
> >
> > https://view.matrix.org/ can presumably fulfill public logging (and
> might
> > be
> > maintained by more than one person).
> >
> > Porting bots to a different protocol would take some work but seems
> doable.
> >
> > --
> > Simon Sapin
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Last week for testing potential IRC replacements

[Manish Goregaokar]

I never used it, I have a screen session on a server running irssi.

I wouldn't recommend it unless you like terminal UIs.

On Wed, Oct 9, 2019, 4:40 AM Paul Rouget  wrote:

> Now that irccloud is gone, what do you people do? Use a IRC client? Moved
> to one of these platforms?
>
> On Fri, Oct 4, 2019 at 4:05 PM Josh Bowman-Matthews  >
> wrote:
>
> > Freenode is still a candidate for us. The candidates listed here
> > require actual feedback because they are different from IRC; Freenode is
> > more of the same, so it doesn't require explicit testing.
> >
> > On 10/4/19 9:01 AM, Anthony Ramine wrote:
> > > Why isn't Freenode a candidate for the switch? The Daala team hangs
> > there so it's not like there is no precedent.
> > >
> > >> Le 3 oct. 2019 à 18:28, Josh Bowman-Matthews 
> a
> > écrit :
> > >>
> > >> If anybody is having trouble accessing the document, here's the
> > relevant information:
> > >>
> > >> Our Matrix/Riot.IM instance is here: https://mozilla-test.riot.im/
> > >> client apps: https://about.riot.im/
> > >> "homeserver" for client: https://mozilla-test.modular.im/
> > >>
> > >> Our Mattermost test instance is here:
> > https://mattermost-test.allizom.org/
> > >> client apps: https://mattermost.com/download/#mattermostApps
> > >>
> > >> Our Rocket.Chat test instance is here:
> > https://rocketchat-test.allizom.org/
> > >> client apps: https://rocket.chat/install
> > >>
> > >> On each of these servers, we'll be taking feedback in the
> > #synchronicity channels as well as in this thread, and of course you can
> > always email mh...@mozilla.com directly.
> > >>
> > >> On 10/3/19 12:25 PM, Josh Bowman-Matthews wrote:
> > >>> I've created Servo channels on each of the test instances. I
> encourage
> > you to join them and experiment with the features of the platform -
> > replying to messages; using threads; using rich message content like
> > images, links, emoticons, etc.
> > >>> On 10/3/19 12:15 PM, Josh Bowman-Matthews wrote:
> >  Hi everyone! Mozilla is currently testing out three different
> > replacements for IRC. irc.mozilla.org is going to go away in early 2020,
> > so our synchronous text chat home will need to change. If you would like
> to
> > have input into this decision, please try out the test instances listed
> in
> >
> https://docs.google.com/document/d/15JyYWOuP1geAwQPMFzJbRtxJG4tZwFJ2GYK7wSvvcVs/edit#
> > before October 9 and add your feedback to that document. If there is
> > Servo-specific feedback you have, feel free to reply to this message with
> > it.
> > 
> >  Cheers,
> >  Josh
> > >>
> > >> ___
> > >> dev-servo mailing list
> > >> dev-servo@lists.mozilla.org
> > >> https://lists.mozilla.org/listinfo/dev-servo
> > >
> >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Question About the Merging Process

[Manish Goregaokar]

Yep!

On Mon, Apr 29, 2019, 4:33 PM Maria Sable  wrote:

> Hi Manish,
>
> Thank you! By ping, do you mean @them in the pull request conversation?
>
> Kind regards,
> Maria Sable
>
> On Mon, Apr 29, 2019 at 7:26 PM Manish Goregaokar 
> wrote:
>
> > The reviewer has to leave a comment saying `@bors-servo r+` to inform our
> > bot that the pull request needs merging. Once that happens, you can wait.
> >
> > If you have an approving Github review but no r+, make sure you've
> > addressed any straggling issues and ping the reviewer.
> >
> > -Manish Goregaokar
> >
> >
> > On Mon, Apr 29, 2019 at 4:24 PM Maria Sable  wrote:
> >
> > > Hi all,
> > >
> > > Sorry if this is a dumb question. I looked at the Contributing page on
> > the
> > > Servo wiki and was not able to find an answer for it.
> > >
> > > Once I have a pull request with an approving review, do I need to take
> > any
> > > additional steps to get it merged into master? Or will the person who
> > > reviewed it merge it?
> > >
> > > Kind regards,
> > > Maria Sable
> > > ___
> > > dev-servo mailing list
> > > dev-servo@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-servo
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Question About the Merging Process

[Manish Goregaokar]

The reviewer has to leave a comment saying `@bors-servo r+` to inform our
bot that the pull request needs merging. Once that happens, you can wait.

If you have an approving Github review but no r+, make sure you've
addressed any straggling issues and ping the reviewer.

-Manish Goregaokar


On Mon, Apr 29, 2019 at 4:24 PM Maria Sable  wrote:

> Hi all,
>
> Sorry if this is a dumb question. I looked at the Contributing page on the
> Servo wiki and was not able to find an answer for it.
>
> Once I have a pull request with an approving review, do I need to take any
> additional steps to get it merged into master? Or will the person who
> reviewed it merge it?
>
> Kind regards,
> Maria Sable
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] How to Run Servo/Media/Examples?

[Manish Goregaokar]

Wait, are you using WSL or directly developing on Windows?

What did you use to install gstreamer?

On Sat, Apr 27, 2019, 4:28 PM Balaji Janakarajan Hari 
wrote:

> Hi Maria
> I had similar issues in the servo/media on Windows build. Ultimately I
> resorted to running a Ubuntu 16.04 on Orcale VirtualBox. The environmental
> variables and updated dependencies are very particular when it comes to
> build process. The Linux subsystem for Windows may not work as well for
> this purpose.
>
> On Sat, Apr 27, 2019, 7:11 PM Maria Sable  wrote:
>
> > Hi Manish,
> >
> > Thank you. I will try to make a StereoPannerNode example based off the
> > params.rs.
> >
> > However, I am still having trouble getting any of the examples in
> > media/target/debug to run. I tried renaming the files in
> > my C:\gstreamer\1.0\x86_64\lib folder to match the errors I am getting
> (it
> > says the files are not found) but I am still get the same errors. I have
> > gstreamer 1.14 installed (because gstreamer 1.15 changed some file names
> > and gave other errors when I initially set up the servo project). I am on
> > Windows and installed gstreamer via the binaries from the gstreamer
> project
> > website and set the PKG_CONFIG_PATH environment variable by following
> these
> > instructions:  https://github.com/sdroege/gstreamer-rs#installation . I
> > did
> > not see anyone reporting similar issues on servo/media.
> >
> > Do you have any suggestions on how to fix this?
> >
> > Kind regards,
> > Maria
> >
> > On Sat, Apr 27, 2019 at 3:54 PM Manish Goregaokar  >
> > wrote:
> >
> > > Ah. The params.rs test sets up a gain node and sends it a bunch of
> > things.
> > > You can do something similar with the StereoPannerNode, though you
> don't
> > > have to send it as many different messages. A simple SetValue message
> > > followed by a couple linear RampToValueAtTimes would be enough.
> > >
> > > Thanks,
> > > -Manish Goregaokar
> > >
> > >
> > > On Sat, Apr 27, 2019 at 12:24 PM Maria Sable  wrote:
> > >
> > > > Hi Manish,
> > > >
> > > > Where is the GainNode example? I don't see it in
> servo/media/examples.
> > > >
> > > > Also, when I try to run "cargo ex panner" in servo/media, I get some
> > > errors
> > > > that the following files were not found: libglib-2.0-0.dll,
> > > > libgobject-2.0-0.dll, libgstreamer-1.0-0.dll, and
> libgstsdp-1.0-0.dll.
> > > > However, I remember installing gstreamer as needed to build the
> > > servo/servo
> > > > project, and the "mach.bat build --dev" command works fine for that.
> > Do I
> > > > need to do something different to get it work with servo/media? When
> I
> > > run
> > > > "cargo build" in servo/media, it works fine.
> > > >
> > > > Kind regards,
> > > > Maria
> > > >
> > > > On Sat, Apr 27, 2019 at 3:13 PM Manish Goregaokar <
> > manishsm...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > `cargo ex name_of_example`
> > > > >
> > > > > In the case of StereoPannerNode you should probably look at the
> > > GainNode
> > > > > code and examples instead, StereoPannerNode is a simple node with a
> > > > single
> > > > > parameter that runs an algorithm based on that parameter, much like
> > > > > GainNode. PannerNode is a lot more complicated.
> > > > >
> > > > > Thanks,
> > > > > -Manish Goregaokar
> > > > >
> > > > >
> > > > > On Sat, Apr 27, 2019 at 12:06 PM Maria Sable 
> > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I'm working on finishing up our final project at NCSU, and I need
> > to
> > > > > create
> > > > > > a runnable example for StereoPannerNode based on the example for
> > > > > > PannerNode. However, it would be immensely helpful to know how to
> > > > > actually
> > > > > > run the existing PannerNode example, but I can't find any
> > > instructions
> > > > in
> > > > > > the readme (I'm on Windows if it matters). Thanks for your help!
> > > > > >
> > > > > > Kind regards,
> > > > > > Maria
> &

Re: [dev-servo] How to Run Servo/Media/Examples?

[Manish Goregaokar]

I'm not really sure, I don't develop on Windows. A clean reinstall may help.

It definitely shouldn't need files to be renamed -- did you install the
right package?

On Sat, Apr 27, 2019, 4:11 PM Maria Sable  wrote:

> Hi Manish,
>
> Thank you. I will try to make a StereoPannerNode example based off the
> params.rs.
>
> However, I am still having trouble getting any of the examples in
> media/target/debug to run. I tried renaming the files in
> my C:\gstreamer\1.0\x86_64\lib folder to match the errors I am getting (it
> says the files are not found) but I am still get the same errors. I have
> gstreamer 1.14 installed (because gstreamer 1.15 changed some file names
> and gave other errors when I initially set up the servo project). I am on
> Windows and installed gstreamer via the binaries from the gstreamer project
> website and set the PKG_CONFIG_PATH environment variable by following these
> instructions:  https://github.com/sdroege/gstreamer-rs#installation . I
> did
> not see anyone reporting similar issues on servo/media.
>
> Do you have any suggestions on how to fix this?
>
> Kind regards,
> Maria
>
> On Sat, Apr 27, 2019 at 3:54 PM Manish Goregaokar 
> wrote:
>
> > Ah. The params.rs test sets up a gain node and sends it a bunch of
> things.
> > You can do something similar with the StereoPannerNode, though you don't
> > have to send it as many different messages. A simple SetValue message
> > followed by a couple linear RampToValueAtTimes would be enough.
> >
> > Thanks,
> > -Manish Goregaokar
> >
> >
> > On Sat, Apr 27, 2019 at 12:24 PM Maria Sable  wrote:
> >
> > > Hi Manish,
> > >
> > > Where is the GainNode example? I don't see it in servo/media/examples.
> > >
> > > Also, when I try to run "cargo ex panner" in servo/media, I get some
> > errors
> > > that the following files were not found: libglib-2.0-0.dll,
> > > libgobject-2.0-0.dll, libgstreamer-1.0-0.dll, and libgstsdp-1.0-0.dll.
> > > However, I remember installing gstreamer as needed to build the
> > servo/servo
> > > project, and the "mach.bat build --dev" command works fine for that.
> Do I
> > > need to do something different to get it work with servo/media? When I
> > run
> > > "cargo build" in servo/media, it works fine.
> > >
> > > Kind regards,
> > > Maria
> > >
> > > On Sat, Apr 27, 2019 at 3:13 PM Manish Goregaokar <
> manishsm...@gmail.com
> > >
> > > wrote:
> > >
> > > > `cargo ex name_of_example`
> > > >
> > > > In the case of StereoPannerNode you should probably look at the
> > GainNode
> > > > code and examples instead, StereoPannerNode is a simple node with a
> > > single
> > > > parameter that runs an algorithm based on that parameter, much like
> > > > GainNode. PannerNode is a lot more complicated.
> > > >
> > > > Thanks,
> > > > -Manish Goregaokar
> > > >
> > > >
> > > > On Sat, Apr 27, 2019 at 12:06 PM Maria Sable 
> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I'm working on finishing up our final project at NCSU, and I need
> to
> > > > create
> > > > > a runnable example for StereoPannerNode based on the example for
> > > > > PannerNode. However, it would be immensely helpful to know how to
> > > > actually
> > > > > run the existing PannerNode example, but I can't find any
> > instructions
> > > in
> > > > > the readme (I'm on Windows if it matters). Thanks for your help!
> > > > >
> > > > > Kind regards,
> > > > > Maria
> > > > > ___
> > > > > dev-servo mailing list
> > > > > dev-servo@lists.mozilla.org
> > > > > https://lists.mozilla.org/listinfo/dev-servo
> > > > >
> > > > ___
> > > > dev-servo mailing list
> > > > dev-servo@lists.mozilla.org
> > > > https://lists.mozilla.org/listinfo/dev-servo
> > > >
> > > ___
> > > dev-servo mailing list
> > > dev-servo@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-servo
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Doubts regarding the subsequent steps.

[Manish Goregaokar]

Yeah, please leave a todo comment. Currently there's no way to validate
this, in the future the DOM side will also have a timeline struct so that
it can do this.

Thanks,
-Manish Goregaokar


On Sat, Apr 27, 2019 at 6:52 AM Josh Bowman-Matthews 
wrote:

> It's not clear to me how to obtain the information about whether a value
> curve is active. I recommend making a pull request with the rest of the
> changes and adding a TODO comment about the missing check.
>
> On 4/26/19 6:01 PM, Srivatsan Narasimhan wrote:
> > Hi Josh,
> > I wrote the two methods with the help of the links you gave before and it
> > is building without anu errors. Now i have some doubts regarding the
> > NotSupportedError message. I am not sure when to call that because in the
> > method description it says that it should be thrown if any of the
> > attributes have any automation curve set using setValueCurveAtTime() and
> i
> > am not sure how to handle that. Can you help me with that?
> > Thanks
> > Srivatsan Narasimhan
> >
> > On Fri, Apr 26, 2019 at 1:37 AM Srivatsan Narasimhan 
> > wrote:
> >
> >> Hi Josh,
> >> This is Srivatsan Narasimhan from NCSU currently working on this issue
> >> https://github.com/servo/servo/issues/22898  along with my team mates
> >> akhilesh, balaji and arjun as a part of the course OODD. I uncommented
> the
> >> methods in the  AudioListener.webidl and currently i am having some
> >> issues on writing the methods. I am getting problems with making the two
> >> functions  a member of the  trait AudioListener methods.Is there any
> >> reference or a guide that could help me with this?
> >> Thanks
> >> Srivatsan Narasimhan
> >>
>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] How to Run Servo/Media/Examples?

[Manish Goregaokar]

Ah. The params.rs test sets up a gain node and sends it a bunch of things.
You can do something similar with the StereoPannerNode, though you don't
have to send it as many different messages. A simple SetValue message
followed by a couple linear RampToValueAtTimes would be enough.

Thanks,
-Manish Goregaokar


On Sat, Apr 27, 2019 at 12:24 PM Maria Sable  wrote:

> Hi Manish,
>
> Where is the GainNode example? I don't see it in servo/media/examples.
>
> Also, when I try to run "cargo ex panner" in servo/media, I get some errors
> that the following files were not found: libglib-2.0-0.dll,
> libgobject-2.0-0.dll, libgstreamer-1.0-0.dll, and libgstsdp-1.0-0.dll.
> However, I remember installing gstreamer as needed to build the servo/servo
> project, and the "mach.bat build --dev" command works fine for that. Do I
> need to do something different to get it work with servo/media? When I run
> "cargo build" in servo/media, it works fine.
>
> Kind regards,
> Maria
>
> On Sat, Apr 27, 2019 at 3:13 PM Manish Goregaokar 
> wrote:
>
> > `cargo ex name_of_example`
> >
> > In the case of StereoPannerNode you should probably look at the GainNode
> > code and examples instead, StereoPannerNode is a simple node with a
> single
> > parameter that runs an algorithm based on that parameter, much like
> > GainNode. PannerNode is a lot more complicated.
> >
> > Thanks,
> > -Manish Goregaokar
> >
> >
> > On Sat, Apr 27, 2019 at 12:06 PM Maria Sable  wrote:
> >
> > > Hi all,
> > >
> > > I'm working on finishing up our final project at NCSU, and I need to
> > create
> > > a runnable example for StereoPannerNode based on the example for
> > > PannerNode. However, it would be immensely helpful to know how to
> > actually
> > > run the existing PannerNode example, but I can't find any instructions
> in
> > > the readme (I'm on Windows if it matters). Thanks for your help!
> > >
> > > Kind regards,
> > > Maria
> > > ___
> > > dev-servo mailing list
> > > dev-servo@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-servo
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] How to Run Servo/Media/Examples?

[Manish Goregaokar]

`cargo ex name_of_example`

In the case of StereoPannerNode you should probably look at the GainNode
code and examples instead, StereoPannerNode is a simple node with a single
parameter that runs an algorithm based on that parameter, much like
GainNode. PannerNode is a lot more complicated.

Thanks,
-Manish Goregaokar


On Sat, Apr 27, 2019 at 12:06 PM Maria Sable  wrote:

> Hi all,
>
> I'm working on finishing up our final project at NCSU, and I need to create
> a runnable example for StereoPannerNode based on the example for
> PannerNode. However, it would be immensely helpful to know how to actually
> run the existing PannerNode example, but I can't find any instructions in
> the readme (I'm on Windows if it matters). Thanks for your help!
>
> Kind regards,
> Maria
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] println!("Hello from NCSU");

[Manish Goregaokar]

Yes, that is correct. This is mostly a matter of hooking up your new
servo-media additions into the JS DOM apis.
-Manish Goregaokar


On Sat, Apr 6, 2019 at 2:02 PM BAlaji  wrote:

> Hi Josh
> Appears to be libgstreamer0.10-dev is outdated in Ubuntu 18.04.
>
> Running the below in terminal fixed the problem. The build succeeds with
> rust toolchain being setup as nightly.
> sudo apt -y install libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
>
> We would working on the next issue in the same project  I guess. Going by
> the open issues, I guess we should start on
>
> https://github.com/servo/servo/issues/22897 (JS API for value curves). Is
> this correct?
>
> Thanks
> Balaji
>
>
>
> From: BAlaji
> Sent: Friday, April 5, 2019 6:30 PM
> To: dev-servo@lists.mozilla.org
> Subject: RE: [dev-servo] println!("Hello from NCSU");
>
> Hi Josh
> Unfortunately that didn’t solve the problem but I was able to downgrade to
> OpenSSL 1.0.2 and still cargo was running with issues. So I moved to VM and
> used Xubuntu 16.04 LTS hoping that I should have all the fix in place but
> appears to be the gsteamer issue is plaguing up
>
>
> warning: /home/j/NCSU/p4/media/Cargo.toml: unused manifest key:
> workspace.license
>Compiling gstreamer-sys v0.7.0
> error: failed to run custom build command for `gstreamer-sys v0.7.0`
> process didn't exit successfully:
> `/home/j/NCSU/p4/media/target/debug/build/gstreamer-sys-07f3047be42c0db3/build-script-build`
> (exit code: 1)
> Requested 'gstreamer-1.0 >= 1.14' but version of GStreamer is 1.8.3
>
>
> So by reading the last line I fail to understand that I have a version
> higher than it required. Any advice?
>
>
> Thanks
> Balaji Janakarajan Hari
> Graduate Student - IMSE Program
> NC State
> linkedin/com/in/jhbalaji
> 903.600.0091
>
> From: Josh Bowman-Matthews
> Sent: Tuesday, April 2, 2019 10:03 AM
> To: dev-servo@lists.mozilla.org
> Subject: Re: [dev-servo] println!("Hello from NCSU");
>
> Try running `cargo update -p hyper-openssl` and see if that makes any
> difference.
>
> On 4/1/19 7:00 PM, Balaji Janakarajan Hari wrote:
> > Hi Josh
> > I just moved to xbunutu 18.1.10. Appears to no support for new OpenSSL of
> > 1.1.1 and greater. Any idea how to fix it?
> >
> > warning: unused manifest key: workspace.license
> > Compiling idna v0.1.5
> >
> >
> >
> >
> > Compiling h2 v0.1.13
> >
> >
> >
> >
> > Compiling env_logger v0.5.12
> >
> >
> >
> >
> > Compiling serde v1.0.80
> >
> >
> >
> >
> > Compiling wayland-sys v0.21.4
> >
> >
> >
> >
> > Compiling freetype v0.4.0
> >
> >
> >
> >
> > Compiling andrew v0.1.4
> >
> >
> >
> >
> > Compiling openssl v0.9.24
> >
> >
> >
> >
> > error: failed to run custom build command for `openssl v0.9.24`
> >
> >
> >
> >
> > process didn't exit successfully:
> >
> `/home/j/NCSU/Spring19/CSC517/media/target/debug/build/openssl-4074b2152e200c57/build-script-build`
> > (exit code: 101)
> > --- stderr
> > thread 'main' panicked at 'Unable to detect OpenSSL version',
> > /home/j/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/
> build.rs:16
> > :14
> > note: Run with `RUST_BACKTRACE=1` for a backtrace.
> > s
> > warning: build failed, waiting for other jobs to finish...
> > error: build failed
> >
> >
> >
> >
> > j@p50:~/NCSU/Spring19/CSC517/media$
> >
> >
> >
> >
> > Sincerely
> > Balaji Janakarajan Hari
> > Graduate Student - IMSE Program
> > NC State University
> >
> > linkedin.com/in/jhbalaji
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] rust-webvr and media repositories now use homu

[Manish Goregaokar]

The webhooks weren't set up. Fixed.
-Manish Goregaokar


On Thu, Feb 21, 2019 at 2:07 AM Fernando Jiménez Moreno <
ferjmor...@gmail.com> wrote:

> It does not seem to be working for servo/media. The queue is empty while
> there's an open PR [1]. And bors-servo does not seem to be working [2].
>
> [1] https://build.servo.org/homu/queue/media
> [2] https://github.com/servo/media/pull/182#issuecomment-465936001
>
> On Tue, Feb 19, 2019 at 6:23 PM Josh Bowman-Matthews <
> j...@joshmatthews.net>
> wrote:
>
> > No matter how attractive that green merge button looks, please refrain
> > from clicking it and use the homu commands for the servo/rust-webvr and
> > servo/media repositories. Otherwise, nothing else has changed.
> >
> > Cheers,
> > Josh
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Error during compilation

[Manish Goregaokar]

Not in the example you're using.
-Manish Goregaokar


On Thu, Dec 6, 2018 at 5:09 PM Avanthikaa Ravichandran 
wrote:

> Is it necessary to send any message to the GainNode?
>
> > On Dec 6, 2018, at 11:04 AM, Manish Goregaokar 
> wrote:
> >
> > Sorry, to clarify: this was a bug in the existing code, not your code.
> > -Manish Goregaokar
> >
> >
> > On Thu, Dec 6, 2018 at 11:04 AM Manish Goregaokar  >
> > wrote:
> >
> >> I pushed a fix, please rebase your pull request to master to pull it in.
> >>
> >> Thanks,
> >> -Manish Goregaokar
> >>
> >>
> >> On Wed, Dec 5, 2018 at 10:08 PM Avanthikaa Ravichandran <
> aravi...@ncsu.edu>
> >> wrote:
> >>
> >>> We pushed the final changes in the code and we have the same issue
> still.
> >>> On running with backtrace, I got the following output:
> >>>
> >>> RUST_BACKTRACE=1 ./target/debug/constant_source
> >>> thread 'AudioRenderThread' panicked at 'index 128 out of range for
> slice
> >>> of length 0', libcore/slice/mod.rs:1932:5
> >>> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
> >>> verbose backtrace.
> >>> stack backtrace:
> >>>   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
> >>> at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
> >>>   1: std::sys_common::backtrace::print
> >>> at libstd/sys_common/backtrace.rs:71
> >>> at libstd/sys_common/backtrace.rs:59
> >>>   2: std::panicking::default_hook::{{closure}}
> >>> at libstd/panicking.rs:211
> >>>   3: std::panicking::default_hook
> >>> at libstd/panicking.rs:227
> >>>   4: std::panicking::rust_panic_with_hook
> >>> at libstd/panicking.rs:477
> >>>   5: std::panicking::continue_panic_fmt
> >>> at libstd/panicking.rs:391
> >>>   6: rust_begin_unwind
> >>> at libstd/panicking.rs:326
> >>>   7: core::panicking::panic_fmt
> >>> at libcore/panicking.rs:77
> >>>   8: core::slice::slice_index_len_fail
> >>> at libcore/slice/mod.rs:1932
> >>>   9:  as
> >>> core::slice::SliceIndex<[T]>>::index
> >>> at libcore/slice/mod.rs:2097
> >>>  10: core::slice:: for [T]>::index
> >>> at libcore/slice/mod.rs:1914
> >>>  11:  as core::ops::index::Index>::index
> >>> at liballoc/vec.rs:1725
> >>>  12: servo_media_audio::block::Block::data_chan
> >>> at audio/src/block.rs:166
> >>>  13: servo_media_audio::param::Param::update
> >>> at audio/src/param.rs:100
> >>>  14: servo_media_audio::gain_node::GainNode::update_parameters
> >>> at audio/src/gain_node.rs:34
> >>>  15:  >>> servo_media_audio::node::AudioNodeEngine>::process
> >>> at audio/src/gain_node.rs:55
> >>>  16: servo_media_audio::graph::AudioGraph::process
> >>> at audio/src/graph.rs:436
> >>>  17: >::process
> >>> at ./audio/src/render_thread.rs:226
> >>>  18:
> >::event_loop
> >>> at ./audio/src/render_thread.rs:312
> >>>  19: >::start
> >>> at ./audio/src/render_thread.rs:159
> >>>  20: >::new::{{closure}}
> >>> at ./audio/src/context.rs:137
> >>> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
> >>> RecvError', libcore/result.rs:1009:5
> >>> stack backtrace:
> >>>   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
> >>> at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
> >>>   1: std::sys_common::backtrace::print
> >>> at libstd/sys_common/backtrace.rs:71
> >>> at libstd/sys_common/backtrace.rs:59
> >>>   2: std::panicking::default_hook::{{closure}}
> >>> at libstd/panicking.rs:211
> >>>   3: std::panicking::default_hook
> >>> at libstd/panicking.rs:227
> >>>   4: std::panicking::rust_panic_with_hook
> >>> at libstd/panicking.rs:477
> >>>   5: std::panicking::continue_panic_fmt
> >>> at libstd/panicking.rs:391
> >>>   6: rust_be

Re: [dev-servo] Error during compilation

[Manish Goregaokar]

Sorry, to clarify: this was a bug in the existing code, not your code.
-Manish Goregaokar


On Thu, Dec 6, 2018 at 11:04 AM Manish Goregaokar 
wrote:

> I pushed a fix, please rebase your pull request to master to pull it in.
>
> Thanks,
> -Manish Goregaokar
>
>
> On Wed, Dec 5, 2018 at 10:08 PM Avanthikaa Ravichandran 
> wrote:
>
>> We pushed the final changes in the code and we have the same issue still.
>> On running with backtrace, I got the following output:
>>
>> RUST_BACKTRACE=1 ./target/debug/constant_source
>> thread 'AudioRenderThread' panicked at 'index 128 out of range for slice
>> of length 0', libcore/slice/mod.rs:1932:5
>> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
>> verbose backtrace.
>> stack backtrace:
>>0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
>>  at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
>>1: std::sys_common::backtrace::print
>>  at libstd/sys_common/backtrace.rs:71
>>  at libstd/sys_common/backtrace.rs:59
>>2: std::panicking::default_hook::{{closure}}
>>  at libstd/panicking.rs:211
>>3: std::panicking::default_hook
>>  at libstd/panicking.rs:227
>>4: std::panicking::rust_panic_with_hook
>>  at libstd/panicking.rs:477
>>5: std::panicking::continue_panic_fmt
>>  at libstd/panicking.rs:391
>>6: rust_begin_unwind
>>  at libstd/panicking.rs:326
>>7: core::panicking::panic_fmt
>>  at libcore/panicking.rs:77
>>8: core::slice::slice_index_len_fail
>>  at libcore/slice/mod.rs:1932
>>9:  as
>> core::slice::SliceIndex<[T]>>::index
>>  at libcore/slice/mod.rs:2097
>>   10: core::slice:: for [T]>::index
>>  at libcore/slice/mod.rs:1914
>>   11:  as core::ops::index::Index>::index
>>  at liballoc/vec.rs:1725
>>   12: servo_media_audio::block::Block::data_chan
>>  at audio/src/block.rs:166
>>   13: servo_media_audio::param::Param::update
>>  at audio/src/param.rs:100
>>   14: servo_media_audio::gain_node::GainNode::update_parameters
>>  at audio/src/gain_node.rs:34
>>   15: > servo_media_audio::node::AudioNodeEngine>::process
>>  at audio/src/gain_node.rs:55
>>   16: servo_media_audio::graph::AudioGraph::process
>>  at audio/src/graph.rs:436
>>   17: >::process
>>  at ./audio/src/render_thread.rs:226
>>   18: >::event_loop
>>  at ./audio/src/render_thread.rs:312
>>   19: >::start
>>  at ./audio/src/render_thread.rs:159
>>   20: >::new::{{closure}}
>>  at ./audio/src/context.rs:137
>> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
>> RecvError', libcore/result.rs:1009:5
>> stack backtrace:
>>0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
>>  at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
>>1: std::sys_common::backtrace::print
>>  at libstd/sys_common/backtrace.rs:71
>>  at libstd/sys_common/backtrace.rs:59
>>2: std::panicking::default_hook::{{closure}}
>>  at libstd/panicking.rs:211
>>3: std::panicking::default_hook
>>  at libstd/panicking.rs:227
>>4: std::panicking::rust_panic_with_hook
>>  at libstd/panicking.rs:477
>>5: std::panicking::continue_panic_fmt
>>  at libstd/panicking.rs:391
>>6: rust_begin_unwind
>>  at libstd/panicking.rs:326
>>7: core::panicking::panic_fmt
>>  at libcore/panicking.rs:77
>>8: core::result::unwrap_failed
>>  at libcore/macros.rs:26
>>9: >::unwrap
>>  at libcore/result.rs:808
>>   10: >::close
>>  at ./audio/src/macros.rs:24
>>   11: constant_source::run_example
>>  at examples/constant_source.rs:82
>>   12: constant_source::main
>>  at examples/constant_source.rs:88
>>   13: std::rt::lang_start::{{closure}}
>>  at libstd/rt.rs:74
>>   14: std::panicking::try::do_call
>>  at libstd/rt.rs:59
>>  at libstd/panicking.rs:310
>>   15: __rust_maybe_catch_panic
>>  at libpanic_unwind/lib.rs:103
>>   16: std::rt::lang_start_internal
>>  at libstd/panicking.rs:289
>>  at libstd/panic.rs:392
>

Re: [dev-servo] Error during compilation

[Manish Goregaokar]

I pushed a fix, please rebase your pull request to master to pull it in.

Thanks,
-Manish Goregaokar


On Wed, Dec 5, 2018 at 10:08 PM Avanthikaa Ravichandran 
wrote:

> We pushed the final changes in the code and we have the same issue still.
> On running with backtrace, I got the following output:
>
> RUST_BACKTRACE=1 ./target/debug/constant_source
> thread 'AudioRenderThread' panicked at 'index 128 out of range for slice
> of length 0', libcore/slice/mod.rs:1932:5
> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
> verbose backtrace.
> stack backtrace:
>0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
>  at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
>1: std::sys_common::backtrace::print
>  at libstd/sys_common/backtrace.rs:71
>  at libstd/sys_common/backtrace.rs:59
>2: std::panicking::default_hook::{{closure}}
>  at libstd/panicking.rs:211
>3: std::panicking::default_hook
>  at libstd/panicking.rs:227
>4: std::panicking::rust_panic_with_hook
>  at libstd/panicking.rs:477
>5: std::panicking::continue_panic_fmt
>  at libstd/panicking.rs:391
>6: rust_begin_unwind
>  at libstd/panicking.rs:326
>7: core::panicking::panic_fmt
>  at libcore/panicking.rs:77
>8: core::slice::slice_index_len_fail
>  at libcore/slice/mod.rs:1932
>9:  as
> core::slice::SliceIndex<[T]>>::index
>  at libcore/slice/mod.rs:2097
>   10: core::slice:: for [T]>::index
>  at libcore/slice/mod.rs:1914
>   11:  as core::ops::index::Index>::index
>  at liballoc/vec.rs:1725
>   12: servo_media_audio::block::Block::data_chan
>  at audio/src/block.rs:166
>   13: servo_media_audio::param::Param::update
>  at audio/src/param.rs:100
>   14: servo_media_audio::gain_node::GainNode::update_parameters
>  at audio/src/gain_node.rs:34
>   15:  servo_media_audio::node::AudioNodeEngine>::process
>  at audio/src/gain_node.rs:55
>   16: servo_media_audio::graph::AudioGraph::process
>  at audio/src/graph.rs:436
>   17: >::process
>  at ./audio/src/render_thread.rs:226
>   18: >::event_loop
>  at ./audio/src/render_thread.rs:312
>   19: >::start
>  at ./audio/src/render_thread.rs:159
>   20: >::new::{{closure}}
>  at ./audio/src/context.rs:137
> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
> RecvError', libcore/result.rs:1009:5
> stack backtrace:
>0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
>  at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
>1: std::sys_common::backtrace::print
>  at libstd/sys_common/backtrace.rs:71
>  at libstd/sys_common/backtrace.rs:59
>2: std::panicking::default_hook::{{closure}}
>  at libstd/panicking.rs:211
>3: std::panicking::default_hook
>  at libstd/panicking.rs:227
>4: std::panicking::rust_panic_with_hook
>  at libstd/panicking.rs:477
>5: std::panicking::continue_panic_fmt
>  at libstd/panicking.rs:391
>6: rust_begin_unwind
>  at libstd/panicking.rs:326
>7: core::panicking::panic_fmt
>  at libcore/panicking.rs:77
>8: core::result::unwrap_failed
>  at libcore/macros.rs:26
>9: >::unwrap
>  at libcore/result.rs:808
>   10: >::close
>  at ./audio/src/macros.rs:24
>   11: constant_source::run_example
>  at examples/constant_source.rs:82
>   12: constant_source::main
>  at examples/constant_source.rs:88
>   13: std::rt::lang_start::{{closure}}
>  at libstd/rt.rs:74
>   14: std::panicking::try::do_call
>  at libstd/rt.rs:59
>  at libstd/panicking.rs:310
>   15: __rust_maybe_catch_panic
>  at libpanic_unwind/lib.rs:103
>   16: std::rt::lang_start_internal
>  at libstd/panicking.rs:289
>  at libstd/panic.rs:392
>  at libstd/rt.rs:58
>   17: std::rt::lang_start
>  at libstd/rt.rs:74
>   18: main
>   19: __libc_start_main
>   20: _start
>
>
> The GitHub issue I referred to earlier is :
> https://github.com/servo/media/pull/122 <
> https://github.com/servo/media/pull/122>
> Please let me know what we can do to fix it. I also want to know if is it
> necessary to send any message to the gain node.
>
> Thank you
>
> > On Nov 30, 2018, at 10:22 AM, Manish Goregaokar 
> wrote:
> >
> > It 

Re: [dev-servo] Implementing periodic wave options for Oscillator node

[Manish Goregaokar]

It doesn't matter for normalization.

The second half of that segment is what's relevant: you need to calculate
the maximum value of a single cycle of the wave, and then scale the wave
down by that. No need to worry about N.

It's fine if you don't implement this for now, though.

Thanks,
-Manish Goregaokar


On Tue, Nov 27, 2018 at 4:54 PM Avanthikaa Ravichandran 
wrote:

> Hi,
> We are implementing the periodic wave options for the oscillator node and
> the formula as mentioned in the link below uses a 'N' which is said to be a
> power of 2. How do we know what the value of N is? Is this set by the user
> or do we assume it to be some arbitrary power of 2 > 0?
> https://webaudio.github.io/web-audio-api/#dictdef-periodicwaveoptions
>
> Thank you
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Mozilla Servo Media - Implementing WebAudio Nodes

[Manish Goregaokar]

> However, for channelsum.rs and channel.rs, clone() is not allowed since
options is created with Default::default();

This is because of inference, use OscillatorOptions::default() instead,
*or* just construct it twice instead of reusing it
-Manish Goregaokar


On Sat, Nov 17, 2018 at 4:15 PM Avanthikaa Ravichandran 
wrote:

> Hi,
> So I tried removing Copy from the OscillatorNodeOptions type but after
> removing it, the other files that create the context do not allow the
> options to be used since they need a copy to create the context object.
> Refer the following code:
> let osc1 = context.create_node(AudioNodeInit::OscillatorNode(options),
> Default::default());
> This line throws an error for options when I remove copy.
>
> To fix this, I modified it as
> let osc1 =
> context.create_node(AudioNodeInit::OscillatorNode(options.clone()),
> Default::default());
> However, for channelsum.rs and channel.rs, clone() is not allowed since
> options is created with Default::default();
> Could you suggest any other solution?
>
> Thank you.
>
>
>
>
> On Thu, Nov 15, 2018 at 7:30 PM Manish Goregaokar 
> wrote:
>
> > Just remove the Copy requirement on the OscillatorOptions type, it's not
> > necessary.
> >
> > -Manish Goregaokar
> >
> >
> > On Thu, Nov 15, 2018 at 4:15 PM Avanthikaa Ravichandran <
> aravi...@ncsu.edu
> > >
> > wrote:
> >
> > > Thank you so much.
> > > We are also trying to implement the periodic wave option for the
> > oscillator
> > > node. The sizes of the real and imag arrays in the PeriodicWaveOptions
> > > structure are not fixed during compile time and need to be generated
> > based
> > > on the input terms.
> > > For this, we thought of using a vector but the vector type does not
> > > implement copy. We tried to use clone() during the oscillator node
> object
> > > creation but many of the other types of waves (like channelsum) derive
> > the
> > > oscillator node and they cannot implement clone/require that copy be
> > > derived. Can you suggest what we can do to overcome this? Do we assume
> an
> > > outer limit to the size of the array and create an array of that size
> or
> > is
> > > there a way to still dynamically set the array size without the copy
> > > conflict?
> > >
> > >
> > >
> > > On Thu, Nov 15, 2018 at 6:16 PM Manish Goregaokar <
> manishsm...@gmail.com
> > >
> > > wrote:
> > >
> > > > Yes, it's f(x) = k.
> > > >
> > > > Note that `k` here is an AudioParam, so it's not always a constant --
> > > > similar to how frequency in OscillatorSourceNode or gain in GainNode
> > can
> > > > vary per frame.
> > > > -Manish Goregaokar
> > > >
> > > >
> > > > On Thu, Nov 15, 2018 at 2:48 PM Avanthikaa Ravichandran <
> > > aravi...@ncsu.edu
> > > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > We are working on implementing the missing WebAudio nodes in
> > > servo-media.
> > > > > One of the initial steps says* ‘implement the missing
> ConstantSource
> > > node
> > > > > type that produces a constant tone based on a stored value that can
> > be
> > > > > modified using the GainNode implementation as a model*'.
> > > > >
> > > > > Am I right in understanding that this requires implementing a wave
> > > f(x) =
> > > > > k, where k is a constant that is determined by the stored value?
> And
> > > the
> > > > > working of this wave is similar to sine, sawtooth, etc., with the
> > only
> > > > > difference being the wave formula?
> > > > > ___
> > > > > dev-servo mailing list
> > > > > dev-servo@lists.mozilla.org
> > > > > https://lists.mozilla.org/listinfo/dev-servo
> > > > >
> > > > ___
> > > > dev-servo mailing list
> > > > dev-servo@lists.mozilla.org
> > > > https://lists.mozilla.org/listinfo/dev-servo
> > > >
> > > ___
> > > dev-servo mailing list
> > > dev-servo@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-servo
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Mozilla Servo Media - Implementing WebAudio Nodes

[Manish Goregaokar]

Just remove the Copy requirement on the OscillatorOptions type, it's not
necessary.

-Manish Goregaokar


On Thu, Nov 15, 2018 at 4:15 PM Avanthikaa Ravichandran 
wrote:

> Thank you so much.
> We are also trying to implement the periodic wave option for the oscillator
> node. The sizes of the real and imag arrays in the PeriodicWaveOptions
> structure are not fixed during compile time and need to be generated based
> on the input terms.
> For this, we thought of using a vector but the vector type does not
> implement copy. We tried to use clone() during the oscillator node object
> creation but many of the other types of waves (like channelsum) derive the
> oscillator node and they cannot implement clone/require that copy be
> derived. Can you suggest what we can do to overcome this? Do we assume an
> outer limit to the size of the array and create an array of that size or is
> there a way to still dynamically set the array size without the copy
> conflict?
>
>
>
> On Thu, Nov 15, 2018 at 6:16 PM Manish Goregaokar 
> wrote:
>
> > Yes, it's f(x) = k.
> >
> > Note that `k` here is an AudioParam, so it's not always a constant --
> > similar to how frequency in OscillatorSourceNode or gain in GainNode can
> > vary per frame.
> > -Manish Goregaokar
> >
> >
> > On Thu, Nov 15, 2018 at 2:48 PM Avanthikaa Ravichandran <
> aravi...@ncsu.edu
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > We are working on implementing the missing WebAudio nodes in
> servo-media.
> > > One of the initial steps says* ‘implement the missing ConstantSource
> node
> > > type that produces a constant tone based on a stored value that can be
> > > modified using the GainNode implementation as a model*'.
> > >
> > > Am I right in understanding that this requires implementing a wave
> f(x) =
> > > k, where k is a constant that is determined by the stored value? And
> the
> > > working of this wave is similar to sine, sawtooth, etc., with the only
> > > difference being the wave formula?
> > > ___
> > > dev-servo mailing list
> > > dev-servo@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-servo
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Rustfmt now checked on CI

[Manish Goregaokar]

Directly run rustfmt on the file, with `rustfmt foo.rs`. you may need to
install it with `rustup component add rustfmt`

On Thu, Nov 8, 2018, 6:50 PM Avanthikaa Ravichandran  We are working on the media crate for servo and we were asked to run the
> rustfmt to format the code. However, in the servo/media repo that we worked
> on, we cannot run the ./mach command. Are we expected to integrate it with
> the main servo repository? How do we run rustfmt on our file otherwise?
>
> Thank you
>
> On Wed, Nov 7, 2018, 2:25 PM Keith Yeung 
> > Woohoo! Great work everyone!
> > On Wed, Nov 7, 2018 at 11:22 AM Josh Bowman-Matthews
> >  wrote:
> > >
> > > Thank you for all your help in formatting the existing code and
> enabling
> > > rustfmt in CI! I'm very pleased that we've adopted rustfmt and that we
> > > now have consistent formatting with the rest of the Rust ecosystem.
> > >
> > > Cheers,
> > > Josh
> > >
> > > On 11/7/18 1:51 PM, Pyfisch wrote:
> > > > Hi Everyone,
> > > >
> > > > Servo source code is now formatted with rustfmt [1]. Style checking
> is
> > > > part of ./mach test-tidy and enforced on CI. To automatically format
> > > > your code run ./mach fmt before commiting. Import order was changed
> but
> > > > ./mach fmt will fix
> > > > any issues. Please ask any questions you may have.
> > > >
> > > > Regards
> > > > Pyfisch
> > > >
> > > > [1]: https://github.com/servo/servo/pull/22126
> > > >
> > > >
> > >
> > > ___
> > > dev-servo mailing list
> > > dev-servo@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-servo
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Query regarding WebAudio node API - Implementing periodic wave options

[Manish Goregaokar]

No, that creates an empty (silent) buffer for the oscillator generation to
write to.

The code that needs rewriting is the code that calls sin().

-Manish Goregaokar


On Wed, Nov 7, 2018 at 3:27 PM Avanthikaa Ravichandran 
wrote:

> Thank you for your response.
> I was also wondering if the statement
> inputs.blocks.push(Default::default());
> in "oscillator_node.rs" is the one setting default values for the
> oscillator node wave? What exactly does this statement push into the input
> blocks? From my understanding, this needs to be rewritten in order to
> implement all the possible oscillator types of the node (Sine, Sawtooth
> etc). Is this correct?
>
> Thank you
>
> On Wed, Nov 7, 2018 at 8:11 AM Josh Bowman-Matthews  >
> wrote:
>
> > Yes, if there are types that derive Copy right now that are being
> > modified in ways that forbid that (such as adding a Vec member), feel
> > free to remove the derivation.
> >
> > Cheers,
> > Josh
> >
> > On 11/6/18 8:09 PM, Avanthikaa Ravichandran wrote:
> > > Hi,
> > > I am trying to write an implementation for the PeriodicWaveOptions in
> the
> > > oscillator node. The parameters for this - real and imaginary, do not
> > have
> > > fixed sizes at compile time since they depend on the user input
> options.
> > > This requires the use of the Vec datatype. However, vectors do not
> derive
> > > copy and this means that the constructor does not have the derive.
> > > Correspondingly, the OscillatorNodeOptions also cannot derive copy.
> Does
> > > this mean the "derive copy" can be removed wherever necessary? If not,
> > what
> > > other datatype can be used for declaring the size at runtime?
> > >
> > > Thank you
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
>
> [image: Mailtrack]
> <
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> >
> Sender
> notified by
> Mailtrack
> <
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> >
> 11/07/18,
> 6:22:28 PM
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Query regarding WebAudio node API - Implementing periodic wave options

[Manish Goregaokar]

Yeah, it is fine to remove the Copy.

On Tue, Nov 6, 2018, 5:09 PM Avanthikaa Ravichandran  Hi,
> I am trying to write an implementation for the PeriodicWaveOptions in the
> oscillator node. The parameters for this - real and imaginary, do not have
> fixed sizes at compile time since they depend on the user input options.
> This requires the use of the Vec datatype. However, vectors do not derive
> copy and this means that the constructor does not have the derive.
> Correspondingly, the OscillatorNodeOptions also cannot derive copy. Does
> this mean the "derive copy" can be removed wherever necessary? If not, what
> other datatype can be used for declaring the size at runtime?
>
> Thank you
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Trychooser support now live!

[Manish Goregaokar]

The `build` chooser has been renamed `linux`, and we now have a `mac` and
`windows` chooser. Each one of these uses a builder that builds and runs
unit tests (but not heavy things like WPT).

I didn't think "just test a mac build" would be something we'd need, but I
ended up needing that yesterday when doing infra upgrades.

Thanks,
-Manish Goregaokar


On Thu, Aug 9, 2018 at 3:31 PM Manish Goregaokar 
wrote:

>
> Trychooser support <https://github.com/servo/homu/pull/167> is now live
> on homu!
>
> This means that instead of `@bors-servo try`, you can run `@bors-servo
> try=wpt` to just run linux-rel-wpt and linux-rel-css. This is preferable to
> a full try; which runs all the builders and is wasteful. It additionally
> clogs up the queue since we have a finite number of build machines. Please
> try to use this whenever possible.
>
> The current try options are:
>
>- build: Just test the build (linux-dev). This may not be too useful
>since travis gets us the same thing.
>- wpt: Ensure we pass wpt on one platform (linux-rel-wpt,
>linux-rel-css)
>- android: Ensure we compile on android (android, android-x86)
>
> If you'd like to add more, make a pull request updating the
> servo_try_choosers
> <https://github.com/servo/saltfs/blob/f17dde95a4944a3879f800841cff0947b706cf95/homu/map.jinja#L5-L9>
> key for homu's salt template config. Deploying this is a bit tricky since
> you need to run a full highstate as well as reload buildbot's config, see 
> Buildbot
> administration
> <https://github.com/servo/servo/wiki/Buildbot-administration#dealing-with-troubles>
> for more details (or just ping me)
>
> Let me know if there are any issues!
>
> Thanks,
> -Manish Goregaokar
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Trychooser support now live!

[Manish Goregaokar]

Trychooser support <https://github.com/servo/homu/pull/167> is now live on
homu!

This means that instead of `@bors-servo try`, you can run `@bors-servo
try=wpt` to just run linux-rel-wpt and linux-rel-css. This is preferable to
a full try; which runs all the builders and is wasteful. It additionally
clogs up the queue since we have a finite number of build machines. Please
try to use this whenever possible.

The current try options are:

   - build: Just test the build (linux-dev). This may not be too useful
   since travis gets us the same thing.
   - wpt: Ensure we pass wpt on one platform (linux-rel-wpt, linux-rel-css)
   - android: Ensure we compile on android (android, android-x86)

If you'd like to add more, make a pull request updating the
servo_try_choosers
<https://github.com/servo/saltfs/blob/f17dde95a4944a3879f800841cff0947b706cf95/homu/map.jinja#L5-L9>
key for homu's salt template config. Deploying this is a bit tricky since
you need to run a full highstate as well as reload buildbot's config,
see Buildbot
administration
<https://github.com/servo/servo/wiki/Buildbot-administration#dealing-with-troubles>
for more details (or just ping me)

Let me know if there are any issues!

Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] ./mach build vs. cargo build

[Manish Goregaokar]

IMO those reasons do not apply to toplevel flags; and given that Cargo
profiles are a thing we really should have a rustflags key there. I've
always had trouble with getting IDEs working with servo because of this.

-Manish Goregaokar

On Wed, Apr 4, 2018 at 6:12 AM, Lars Bergstrom <larsb...@mozilla.com> wrote:

> Cargo has traditionally not wanted to add full support for arbitrary
> RUSTFLAGS, for reasonable reasons:
> https://github.com/rust-lang/cargo/issues/60#issuecomment-51705597
>
> What we've done in the past is for each flag that we needed exposed opened
> a specific Issue or PR to Cargo to have just that one feature either added
> to the allowed flags list or as a new toplevel item in the profile. I'd at
> least check those out first before regressing link performance
> significantly or adding a local development footgun (only checking certain
> warnings in CI and requiring people to take an extra trip through the homu
> queue to find out things they could have tested locally).
>
> FWIW, I agree totally - any reasonable IDE is not going to respect usage of
> `mach` to set env vars and we'd LOVE to have all this stuff in Cargo
> configs. The use of RUSTFLAGS in mach has traditionally been a staging area
> for features not yet turned on by default in rustc or not yet supported for
> configuration in cargo (especially in the dark old days of cross
> compilation woes - much better now!).
> - Lars
>
>
> On Tue, Apr 3, 2018 at 4:44 PM, Simon Sapin <simon.sa...@exyr.org> wrote:
>
> > On 03/04/18 23:30, Emilio Cobos Álvarez wrote:
> >
> >> or the bit to use the gold linker.
> >>
> >
> > The best outcome IMO would be to make that the default:
> > https://github.com/rust-lang/rust/issues/30783
> >
> > This was implemented and then reverted because of Debian Wheezy
> > (oldoldstable), whose LTS ends next month in May.
> >
> > My pings on the issue a few months ago did not get a response, so the
> next
> > step is probably sending a PR and picking someone on the compiler team to
> > nag for review.
> >
> > --
> > Simon
> >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

We can explicitly call `cargo +stable build` for geckolib, and have a min
version check in mach.

We'll only get the rust-toolchain file pinning for one of the two and will
have to build some mach stuff for the other, but it will be considerably
simpler than what we have right now.

I think we should do this; with geckolib having the
slightly-more-complicated build because it doesn't _require_ stable so
doing just "cargo build" will work as well.

On Nov 14, 2017 8:22 AM, "Jack Moffitt"  wrote:

> 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/servo/issues/11361 we’ve discussed using
> > rustup.rs to bootstrap Rust and Cargo.
> >
> > With https://github.com/servo/servo/pull/19213 landing soon, I think the
> > last blocker is resolved.
> >
> > One proposal has been to use rustup when available, and fall back to our
> > existing mechanism when not. However I think rustup is well-established
> > enough these days and I’d like to go further: make it a requirement and
> > remove our code that duplicates rustup’s functionality: downloading and
> > extracting tarballs, juggling toolchain versions, etc.
> >
> > mach would make sure to run cargo/rustc/etc. through rustup
> > (https://github.com/rust-lang-nursery/rustup.rs/issues/1293), and set
> the
> > $RUSTUP_TOOLCHAIN environment variable to select the appropriate
> toolchain
> > version. Recent versions of rustup now download missing toolchains
> > automatically.
> >
> > We’d document instructions for installing rustup in our README, and
> again an
> > error message when mach cannot find a `rustup` executable.
> >
> > The `system-rust = true` configuration would remain available and run
> plain
> > `cargo` or `rustc` like before.
> >
> > Thoughts?
> >
> > --
> > Simon Sapin
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Should commits landed in servo individually pass all tests?

[Manish Goregaokar]

> "Always been the case" = I remember back in 2015 that reviewers often
asked me whether intermediate commits were building properly. Maybe that
was just out of curiosity, but to me it sounded like something we should
strive for.

To be clear; I'm talking about *passing all tests*, not building. It should
always build. Most of the comments you've made seem to be in the context of
building.

(I think tidy should be included in "passing all tests" too mostly because
I can't envision a case where we'd ever want to bisect on tidy; and
currently tidy is oversensitive about import order to an extent that makes
it a disproportionate amount of work to retroactively enforce tidy on each
commit.)

> In addition to commits prior to such changes being probably broken, such
commits ("fix unit tests") also mean you sometimes lose a good way to track
breaking changes in an API in pull requests with a lot of commits.

"Fix unit tests" was a mistake, sorry about that. I meant to fold that in
and forgot. It's the other one ("update test expectations" or whatever I
called it) that I'm talking about. Also the intermediate commits being
incomplete fluctuate between failing a bunch of transform css-tests. Having
that history checked in is not helpful at all. The only option is to squash
the entire pull requests.


Though I ... don't really see your point here. You're advocating squashing
the entire pull request in this thread; that has approximately the same
effect as a separate "fix unit tests" commit vis a vis tracking breaking
changes in an API? With a separate commit you have to go back to the pull
request and look at the full diff or guess which commit introduced the
change. When the entire pull request is a single squashed commit you have
the same problem, except now you have no way of looking at the big commit
aside from all at once.

> And by wrong I mean "I respectfully disagree, here are a list of pull
requests I wrote that didn't need to be a single commit".

I wasn't saying "all large refactorings", I was saying "many". I've done
those too.

> I just don't want to hear "shrug, I don't have time for this" (which is
something I've already encountered in the past).

To be clear; that's not what I was doing for the transforms PR. I could
have squashed it in a second; however I was of the opinion it shouldn't be
squashed since otherwise there's just too much going on in a single commit.
I'd also been structuring the commits so as to be eventually landable as-is
as far as building and logical structure is concerned. I made exactly that
tradeoff; I felt bisectability within the PR was not worth having a giant
commit that changes everything at once.

> That bisect can work over first-parent doesn't mean you shouldn't strive
to have all commits building.

Again, I'm talking about running tests, not building; and I'd like to see
some rationale here; because as it stands first-parent bisect is the
tradeoff-breaker here, it lets us have working bisects *and* it lets us
have bite-sized commits that may fail tests but do build in our PRs.


I also think that if we care so strongly about tests passing per-commit we
should be testing that (though that's also expensive); because as-is I'm
quite certain that bisect without first-parent would *regularly* break
tests on the way; and that's not just because *I*'ve not been following
that rule. I'm pretty sure nobody runs try on every commit they make; so
I'd expect to see lots of test-broken commits in our history; enough to
break the ability to bisect over all tests.

Thanks,

-Manish Goregaokar

On Fri, Nov 3, 2017 at 6:58 AM, Anthony Ramine <aram...@mozilla.com> wrote:

> Let me add some necessary additions to this quite rude email...
>
> I am sorry, Manish.
>
> > Le 3 nov. 2017 à 10:33, Anthony Ramine <n.ox...@gmail.com> a écrit :
> >
> >
> >> Le 3 nov. 2017 à 01:00, Manish Goregaokar <manishsm...@gmail.com> a
> écrit :
> >>
> >> So I and emilio were discussing whether or not to squash
> >> https://github.com/servo/servo/pull/18750 and it seemed like we have
> >> different ideas of how "atomic" commits should be before landing.
> >
> > It should definitely have been squashed, this is not the first time such
> a thing is discussed.
>
> But past discussions were on IRC, so you probably can't find them anymore,
> teehee!
>
> This is a debate that comes back from times to times on the channel,
> mostly when Emilio or I or someone else see a PR with commits that should
> be squashed.
>
> > "Fix unit tests" is not a commit I want to see in master *ever*.
>
> In addition to commits prior to such changes being probably broken, such
> commits ("fix unit tests") also mean you sometimes lose a go

[dev-servo] Should commits landed in servo individually pass all tests?

[Manish Goregaokar]

So I and emilio were discussing whether or not to squash
https://github.com/servo/servo/pull/18750 and it seemed like we have
different ideas of how "atomic" commits should be before landing.

When we land pull requests in servo/servo we like individual commits to
build so that git bisect works.

Do we require them to pass all tests as well? If not, should we? I don't
*think* we do, I'm pretty sure we didn't back in 2014, but emilio pointed
out we ask for this in CONTRIBUTING.md and I'm confused now


In my opinion we should not require tests to pass on individual commits
(just the PR), for a variety of reasons:

   - git blame is used a lot more than git bisect IME . It is very helpful
   to have as-tiny-as-possible commits for git blame.
   - I don't think we ever bisect with the entire testsuite ; it's usually
   just a couple tests
   - you *can* bisect over first-parent (it's tricky, but there are
   commands out there you can copy) making this whole thing moot. However when
   squashing a large pull request you're effectively losing all that
   information, and that's not something you can work around
   - This basically forces large refactorings to be a single commit


Thoughts?

-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Memory reporting in Servo: the next step

[Manish Goregaokar]

If we do impls in the mallocsizeof crate is we can't make use of the custom
derive functionality and have to manually write out impls (which in many
cases won't be possible).

So I'm not sure if we can completely get rid of the dependency problem.


-Manish Goregaokar

On Thu, Oct 5, 2017 at 10:11 PM, Simon Sapin <simon.sa...@exyr.org> wrote:

> On 06/10/2017 06:05, Nicholas Nethercote wrote:
>
>> If we went with the second option from my original mail (i.e. stop using
>> heapsize) then it would probably make sense to deprecate heapsize
>> entirely,
>> stop those crates from depending on it, and implement the MallocSizeOf
>> trait for those crates' types within Servo.
>>
>
> I’m in favor of this.
>
> It does create a contention point in the dependency graph (malloc_size_of
> depends on many crates, and many other crates depend on malloc_size_of).
> But the current heapsize situation (crates in many repositories depend on
> heapsize) is also a pain whenever we want to make breaking changes to
> heapsize.
>
> --
> Simon Sapin
>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Memory reporting in Servo: the next step

[Manish Goregaokar]

> or it could be a different crate

FWIW, it can't. Rust enforces that either the trait or the type being impld
come from the current crate (with generics it gets more complicated).


I kinda feel like upgrading HeapSizeOf to have a generic second trait-bound
argument that we substitute MallocSizeOfOps as would be good.


-Manish Goregaokar

On Thu, Oct 5, 2017 at 9:05 PM, Nicholas Nethercote <n.netherc...@gmail.com>
wrote:

> On Fri, Oct 6, 2017 at 2:33 PM, Xidorn Quan <m...@upsuper.org> wrote:
>
> >
> > There are multiple Servo dependencies on crates.io depend on heapsize.
> > [1] How are they handled at the moment? And what would we do to them in
> > the future with the second option?
> >
> > [1] https://crates.io/crates/heapsize/reverse_dependencies
> >
>
> Good question.
>
> There are two ways for the HeapSizeOf trait to be implemented for a type
> Foo.
>
> (1) Foo's crate depends on heapsize, in which case Foo's crate can
> implement HeapSizeOf itself. The crates at that link above (app_units,
> euclid, url) are examples. The advantage of this option is that the
> HeapSizeOf trait can access non-public fields of types.
>
> (2) Foo's crate doesn't depend on heapsize, in which case a different crate
> must implement HeapSizeOf for Foo. This could be the heapsize crate itself
> -- as is done for all the standard types like Vec and HashMap -- or it
> could be a different crate. The advantage of this option is that you don't
> depend on heapsize.
>
> If we went with the second option from my original mail (i.e. stop using
> heapsize) then it would probably make sense to deprecate heapsize entirely,
> stop those crates from depending on it, and implement the MallocSizeOf
> trait for those crates' types within Servo.
>
> Nick
>
>
>
> Nick
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Categorizing Stylo reftest failures

[Manish Goregaokar]

https://gist.github.com/Manishearth/086118c940ff86a6cfc573f53c508279

I've now gone through the failures and categorized them as yes/no/maybe
based on whether they should block shipping. I've filed bugs for and
partially investigated all of the "yes" ones (and fixed some of them). Some
of these bugs are unassigned; feel free to pick them up!

The "maybe" ones are ones which I don't *think* are important but I haven't
had a chance to properly investigate yet. I will do that soon.


We're looking pretty good on this front, only a couple of "yes" failures
left.

There may have been additional failures introduced since I generated this
doc (I removed new passes but did not add new failures), which  I also
intend to go through at some point.


Thanks,
-Manish
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Zhitin Zhu's intern presentation on Magic DOM

[Manish Goregaokar]

Update: Simran's presentation is now at 3:15pm – 3:30pm PDT

-Manish Goregaokar

On Tue, Jul 25, 2017 at 3:37 PM, Manish Goregaokar <manishsm...@gmail.com>
wrote:

> Servo has a whole block of intern presentations then!
>
> Starting at 2PM PDT:
>
>
>- 2PM: Liz Lucas on detecting interstitials via machine learning
>- 2:15PM: Simran Gujral on TLS in Servo
>- 2:30PM: Zhiting Zhu on Magic DOM
>
> Hope you join us for all of these!
>
> Thanks,
>
> -Manish Goregaokar
>
> On Tue, Jul 25, 2017 at 3:18 PM, Nick Fitzgerald <nfitzger...@mozilla.com>
> wrote:
>
>> Hello Servo aficionados!
>>
>> On Thursday August 3rd at 2:30pm (PDT), Zhiting will be presenting his
>> work
>> on the ~*~ Magic DOM ~*~ project! Join us on https://air.mozilla.org/ to
>> tune in :)
>>
>> See you there!
>>
>> Nick
>> ___
>> dev-servo mailing list
>> dev-servo@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-servo
>>
>
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Zhitin Zhu's intern presentation on Magic DOM

[Manish Goregaokar]

Servo has a whole block of intern presentations then!

Starting at 2PM PDT:


   - 2PM: Liz Lucas on detecting interstitials via machine learning
   - 2:15PM: Simran Gujral on TLS in Servo
   - 2:30PM: Zhiting Zhu on Magic DOM

Hope you join us for all of these!

Thanks,

-Manish Goregaokar

On Tue, Jul 25, 2017 at 3:18 PM, Nick Fitzgerald <nfitzger...@mozilla.com>
wrote:

> Hello Servo aficionados!
>
> On Thursday August 3rd at 2:30pm (PDT), Zhiting will be presenting his work
> on the ~*~ Magic DOM ~*~ project! Join us on https://air.mozilla.org/ to
> tune in :)
>
> See you there!
>
> Nick
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Categorizing Stylo reftest failures

[Manish Goregaokar]

We aren't! I'm just not seeing that bug in the reftests outside of
audio and video, and TYLin is already looking into it anyway.

Thanks,

-Manish Goregaokar


On Mon, Jul 24, 2017 at 8:20 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 7/24/17 1:53 AM, Manish Goregaokar wrote:
>>
>> and the styloVsGecko / issue (which does not block landing
>> since it's a
>> slight discrepancy between stylo and gecko)
>
>
> Looks like it's a difference in vertical alignment.  How sure are we that
> this won't affect web pages outside of media controls?
>
>
> -Boris
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Categorizing Stylo reftest failures

[Manish Goregaokar]

Now that we've fixed most of these I went through it again and checked
stuff. Filtering out scoped style and web components failures we only
have a hundred tests left

I recategorized most of them:
https://gist.github.com/Manishearth/086118c940ff86a6cfc573f53c508279

The major issues right now are first-line and the styloVsGecko
/ issue (which does not block landing since it's a
slight discrepancy between stylo and gecko)
-Manish Goregaokar


On Thu, May 11, 2017 at 5:19 PM, Manish Goregaokar
<manishsm...@gmail.com> wrote:
> And, it's done! All reftest failures classified.
>
> Permalink to current revision:
> https://gist.github.com/Manishearth/086118c940ff86a6cfc573f53c508279/a181e327a4e2d83d75e28862d1fc01e121923bff
>
> Bear in mind that the try run this is based on is a few days old so some of
> the things there may be fixed in master. I've been making drive-by patches
> for many of the things I come across.
>
> I'll soon do a separate analysis of the HasAuthorSpecifiedRules stuff to see
> what's still failing since Matt's patches have landed. There are 913 tests
> marked as HasAuthorSpecified in that file, and Matt's patches fixed 530, so
> we still have some input widget bugs floating around.
>
>
> I will also be removing now-passing tests if I see them, but don't rely on
> that being true. I don't intend to put too much time into maintaining this
> list; the main point was to get an idea of what needs to be fixed. I will
> try to investigate things which still fail when their corresponding bug
> lands.
>
>
> Thanks,
>
> -Manish Goregaokar
>
> On Wed, May 10, 2017 at 5:14 PM, Manish Goregaokar <manishsm...@gmail.com>
> wrote:
>>
>> So I took a try push with all expectations set as passing and went about
>> categorizing the reftest failures.
>>
>> I'm halfway done. This is pre-HasAuthorSpecifiedRules and there are lots
>> of related failures. At some point I'll extract all the HASR-marked failures
>> and have a second look at the ones which are still not passing after the
>> HASR bug lands.
>>
>> https://gist.github.com/Manishearth/086118c940ff86a6cfc573f53c508279
>>
>> While I've investigated many of these, many others still don't have well
>> known reasons.
>>
>> It would be quite helpful if everyone could help investigate. Ctrl-F
>> "unknown" on that page, anything with "unknown" in the explanation needs
>> more investigation.
>>
>> If you do file bugs (or find existing bugs), please let me know so that I
>> can update the page. I haven't yet had time to really file bugs for each
>> failure, and I intend to do this once done with the rest, but help now would
>> be appreciated!
>>
>> There are also some possibly-low-hanging-fruit failures where I've
>> investigated the reason and mentioned it, but not yet filed an issue.
>>
>> I'll continue to push more reftest failure categorizations as I get
>> through, and I intend to write some scripts that let me keep this doc
>> somewhat up to date as major groups of failures get fixed.
>>
>> Thanks,
>> -Manish Goregaokar
>
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] All properties implemented in Stylo!

[Manish Goregaokar]

As of this week, all supported Firefox properties, including internal-only
properties, have been implemented in Stylo.

https://manishearth.github.io/css-properties-list/?stylo=hide=show=only=show=false=false

Some of these properties are still incomplete in their implementation (the
basic property is supported but not some specific value), or may have bugs,
but that will get fixed as we attack the reftests.


Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Categorizing Stylo reftest failures

[Manish Goregaokar]

And, it's done! All reftest failures classified.

Permalink to current revision:
https://gist.github.com/Manishearth/086118c940ff86a6cfc573f53c508279/a181e327a4e2d83d75e28862d1fc01e121923bff

Bear in mind that the try run this is based on is a few days old so some of
the things there may be fixed in master. I've been making drive-by patches
for many of the things I come across.

I'll soon do a separate analysis of the HasAuthorSpecifiedRules stuff to
see what's still failing since Matt's patches have landed. There are 913
tests marked as HasAuthorSpecified in that file, and Matt's patches fixed
530, so we still have some input widget bugs floating around.


I will also be removing now-passing tests if I see them, but don't rely on
that being true. I don't intend to put too much time into maintaining this
list; the main point was to get an idea of what needs to be fixed. I will
try to investigate things which still fail when their corresponding bug
lands.


Thanks,

-Manish Goregaokar

On Wed, May 10, 2017 at 5:14 PM, Manish Goregaokar <manishsm...@gmail.com>
wrote:

> So I took a try push with all expectations set as passing and went about
> categorizing the reftest failures.
>
> I'm halfway done. This is pre-HasAuthorSpecifiedRules and there are lots
> of related failures. At some point I'll extract all the HASR-marked
> failures and have a second look at the ones which are still not passing
> after the HASR bug lands.
>
> https://gist.github.com/Manishearth/086118c940ff86a6cfc573f53c508279
>
> While I've investigated many of these, many others still don't have well
> known reasons.
>
> It would be quite helpful if everyone could help investigate. Ctrl-F
> "unknown" on that page, anything with "unknown" in the explanation needs
> more investigation.
>
> If you do file bugs (or find existing bugs), please let me know so that I
> can update the page. I haven't yet had time to really file bugs for each
> failure, and I intend to do this once done with the rest, but help now
> would be appreciated!
>
> There are also some possibly-low-hanging-fruit failures where I've
> investigated the reason and mentioned it, but not yet filed an issue.
>
> I'll continue to push more reftest failure categorizations as I get
> through, and I intend to write some scripts that let me keep this doc
> somewhat up to date as major groups of failures get fixed.
>
> Thanks,
> -Manish Goregaokar
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Categorizing Stylo reftest failures

[Manish Goregaokar]

First link in the file!

https://treeherder.mozilla.org/#/jobs?repo=try=bff0878649f10db8946d50e760b0d13f0f3be9be

Also, each section in the file already links to the analyzer results for
that subset of the tests.

-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

FWIW gps planned to strip @mentions in the autosync service, so most of the
pain here could go away. It already strips the boilerplate.

-Manish Goregaokar

On Wed, Mar 1, 2017 at 9:35 AM, Jack Moffitt <j...@metajack.im> wrote:

> 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 <emi...@crisal.io>
> wrote:
> > On Wed, Mar 01, 2017 at 08:13:36AM -0700, Jack Moffitt wrote:
> >> It contains a cohesive description of the entire set of changes. It
> >> would be a shame to omit it.
> >
> > I think the reality is really far away from this. At least, we should
> > strip the PR template boilerplate, the HTML comments meant to indicate
> > new contributors what to fill, and the reviewable boilerplate too.
> >
> > Commit messages like [1] seem mostly noise to me.
> >
> >  -- Emilio
> >
> > [1]: https://github.com/servo/servo/commit/
> 261df34ced0bdcb8126994c8653ac101d1172085
> >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Useful tools for current Stylo workflow

[Manish Goregaokar]

I updated some of my scripts to the latest workflow, thought I would share
them.

To take a cinnabar servo branch based on `tip`, and remove all changes
related to servo, run these two commands in succession:

   - git filter-branch --index-filter 'git reset @ servo && git checkout @
   -- servo' --prune-empty -f -- tip..
   - g rebase -i tip -x "git reset @^ servo && git checkout @^ -- servo &&
   git add -u servo && git commit --amend -C @"

I'm not sure why the second is necessary, the first one works for all
commits but the first in the series, and the second one is able to handle
that. Just the second one won't work because it will cause merge conflicts;
rebase -x needs to be able to make the commit before you modify it, while
filter-branch modifies commits in-progress.


I also have
https://gist.github.com/Manishearth/1d1da99296dbff10c003bd3db4bf6e58 for
quickly setting test expectations. You can just copy the error summary into
a file and feed it to the script, which will update all the relevant list
files.


-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

I think the plan is eventually that only a subset of changes go through
Firefox CI, but this may not be the case when starting up. edunham would
know.

I think Firefox CI takes 2 hours or so, modulo coalescing. Not sure if we
plan to reduce the tests run for pure-servo changesets.

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.

-Manish Goregaokar

On Mon, Feb 13, 2017 at 1:40 PM, Anthony Ramine <n.ox...@gmail.com> wrote:

> I have a few questions:
>
> Which changes will need to go through Firefox CI?
>
> How long does Firefox CI take to run all the tests?
>
> What happens if the bug is on Firefox's side?
>
> > Le 13 févr. 2017 à 20:50, Bobby Holley <bobbyhol...@gmail.com> a écrit :
> > 
>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

[Manish Goregaokar]

I was actually intending to expand that set as necessary, a lot of the
owned and arc types could use this trick too. A lot of this was held back
on the Rust compiler losing inline drop flags (which happened recently).


I'm okay with splitting it again, but would prefer to avoid as much as
possible :)

-Manish Goregaokar

On Thu, Dec 15, 2016 at 12:50 AM, Xidorn Quan <m...@upsuper.org> wrote:

> Oh, I see what did you mean. ElementData and AtomicRefCell would be a
> problem. I don't see anything else, though.
>
> - Xidorn
>
> On Thu, Dec 15, 2016, at 05:29 PM, Manish Goregaokar wrote:
> > The sugar stuff is just helpers. The crossover happens in the bindings
> > file
> > itself, where  gets replaced with , etc.
> >
> > On Dec 14, 2016 5:13 PM, "Xidorn Quan" <m...@upsuper.org> wrote:
> >
> > > On Thu, Dec 15, 2016, at 12:01 PM, Manish Goregaokar wrote:
> > > > They used to be a different crate. I merged them so that we can do
> > > > replacements with safer wrappers and have fewer coherence issues.
> > >
> > > It doesn't seem to me the safer wrappers (I suppose the ones in
> > > gecko_bindings/sugar?) needs the bindings to stay in the style
> > > component. We can still leave gecko mod in style component, and just
> > > split out the bindings mods. That shouldn't cause much trouble I
> > > suppose.
> > >
> > > > Perhaps we can make triggering local build time bindgen regen more
> > > > explicit?
> > >
> > > You mean, probably not listing that many files in
> > > cargo:rerun-if-changed? That probably works I guess.
> > >
> > > - Xidorn
> > > ___
> > > dev-servo mailing list
> > > dev-servo@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-servo
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

[Manish Goregaokar]

Yes, this could be done. I would like to have more automated checks here
however if we were to do this.

At one point I had considered letting the generated bindings be super
unsafe and then for each servo_*/gecko_* function have a safe wrapper that
is generated (or handwritten?) that forwards to it with the types replaced.

Generating it would still require the bindings build step to write code for
the style crate however. I wasn't sure if we could trust manually writing
it.

On Dec 14, 2016 10:45 PM, "Simon Sapin" <simon.sa...@exyr.org> wrote:

> On 15/12/16 02:01, Manish Goregaokar wrote:
>
>> They used to be a different crate. I merged them so that we can do
>> replacements with safer wrappers and have fewer coherence issues.
>>
>
> Could the code generated by bindgen be separated from the wrappers? That
> way wrappers could be wherever impl coherence require them to be, while
> keeping the bindgen-using build script in a dedicated crate.
>
> --
> Simon Sapin
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

[Manish Goregaokar]

The sugar stuff is just helpers. The crossover happens in the bindings file
itself, where  gets replaced with , etc.

On Dec 14, 2016 5:13 PM, "Xidorn Quan" <m...@upsuper.org> wrote:

> On Thu, Dec 15, 2016, at 12:01 PM, Manish Goregaokar wrote:
> > They used to be a different crate. I merged them so that we can do
> > replacements with safer wrappers and have fewer coherence issues.
>
> It doesn't seem to me the safer wrappers (I suppose the ones in
> gecko_bindings/sugar?) needs the bindings to stay in the style
> component. We can still leave gecko mod in style component, and just
> split out the bindings mods. That shouldn't cause much trouble I
> suppose.
>
> > Perhaps we can make triggering local build time bindgen regen more
> > explicit?
>
> You mean, probably not listing that many files in
> cargo:rerun-if-changed? That probably works I guess.
>
> - Xidorn
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

[Manish Goregaokar]

They used to be a different crate. I merged them so that we can do
replacements with safer wrappers and have fewer coherence issues.

Perhaps we can make triggering local build time bindgen regen more explicit?

On Dec 14, 2016 2:57 PM, "Xidorn Quan"  wrote:

> I'm thinking about splitting those parts into a separate crate because
> currently servo/style component's build script is doing two different
> things: 1. generate property code, 2. do bindgen. And mixing these
> things may lead to many unnecessary rebuild.
>
> In the current build-time bindgen code, all headers directly or
> indirectly included by header processed are listed as
> "cargo:rerun-if-changed", but majority of them may not actually affect
> the output of bindgen, and in that case, we don't really need to rebuild
> the style crate and anything depends on it.
>
> For solving that problem, I filed an issue [1] to cargo suggesting that
> we should have a mechanism for build script to inform cargo not to
> rebuild the crate simply because of build script. With that mechanism,
> we can compare the output of bindgen and see whether it is same as the
> existing code, and tell cargo not to rebuild if the code doesn't change.
>
> However, even if we have that mechanism, we cannot really tell whether
> rebuild is necessary for build script of style component, because we
> also generate property code there, and it seems to me detecting whether
> that code changes costs more work and doesn't make much sense, because
> unlike bindings generated from C++ code, changes to the template or
> property data likely actually need a rebuild.
>
> Given these, I guess the best solution would be to split the gecko
> binding things out into a separate crate with its own build script.
>
> Thoughts?
>
> [1] https://github.com/rust-lang/cargo/issues/3404
>
> - Xidorn
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] CSSOM ownership woes

[Manish Goregaokar]

On Mon, Nov 14, 2016 at 5:11 PM, Xidorn Quan <m...@upsuper.org> wrote:
> I guess it is probably doable, but that means parsing and traversing the
> tree would involve lots of additional FFI calls to build and access the
> tree in Gecko side.


It also can't be done lazily if it's a single tree. My current
Servo-side implementation maintains a parallel tree and is lazy, which
works well.

> But I don’t know if there is much to share anyway

Parsing and serialization basically. A lot of the serialization code
hasn't been implemented yet but we can do that easily. Parsing may
need to be wrapped in a cleaner API (haven't had a chance to properly
look through that yet, and most of the parsing is just parsing of
PropertyDeclarationBlocks).


-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] CSSOM ownership woes

[Manish Goregaokar]

> Or probably asserting that we're not in a Servo Layout thread when we
> `borrow_mut`? Not perfect, but...


Extra runtime check and I'm not fond of this solution in general,
since it's runtime. The token thing is a pure compile time option.
Making it !Send+!Sync means that it's hard to make it accidentally end
up in the layout thread.


> Can you move the same CSSRuleList to a different owner? If you can, this
> wouldn't work, right?

I don't think you can.

e this will also need it's own RwLock in order to mutate the
> list, right? If that's the case, probably something like
> Arc, where CSSRuleList(Vec) is probably
> nicer.

Yep. I'm implementing an immutable cssom first, and will revisit the
exact positions of the rwlocks later.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] CSSOM ownership woes

[Manish Goregaokar]

This is basically the gist of a discussion that I and xidorn were
having, pertaining to CSSOM in both Servo and Stylo. We mostly wrapped
it up, but there are loose ends and I'm not sure if the choices made
are correct.

In CSSOM, you basically have a StyleSheetList holding many StyleSheets
holding a CSSRuleList holding many CSSRules. You can
index/insert/delete on the lists and CSSRule can be manipulated in a
bunch of ways.

One invariant that's not *exactly* specified by the spec (but is sort
of hinted at, and implemented by browsers) is that these lists should
yield the same underlying JS object when you access the same
conceptual rule/stylesheet in a list (even if the rest of the list was
mutated). So the DOM indexing methods cannot just create
rule/stylesheet JS objects on the fly, they need to cache them somehow
and update them when the list is updated.

Servo currently has a style tree (stylesheets->rulelist->rules->other
rules and rule lists) in style::Stylesheet[1], and this is shared with
the DOM via Arcs. As I understand it, Gecko, on the other hand, just
uses the CSSOM DOM tree and has no "style tree" otherwise. Reading
rules in Gecko requires traversing through CSSOM objects. This is a
straightforward solution to the same-object restriction; if your style
tree is made up of these objects in the first place there's nothing to
worry about.

Servo can't use this solution. Trying to thread style through the DOM
will mean merging the style and script crates, and it will be quite
complicated to make Servo's style system generic over CSSOM
implementations for stylo to work.

A possible solution is to have a opaquish DOM backpointer to
corresponding rule objects in the style tree and have it call some
update function to update the DOM when mutating. This isn't a great
solution IMO.

The one that we seem to prefer is maintaining the style tree and the
CSSOM tree in parallel, with references from the CSSOM tree to the
style tree, but not vice versa. Only the DOM mutates the style tree.
This could possible be enforced by wrapping all interior mutability in
the style tree with a type that requires a zero-sized token to be
passed in to the borrow_mut/write method; a token which can't be
created normally but can be obtained via a method on dom::Reflectable
(within arms reach for most DOM code). Stylo code can FFI call into
functions using a similar mechanism.

So far this seems good (though very open to other ideas or suggestions
for improvement).

However, in this model the DOM still needs to hold Arcs to the
corresponding style system objects. In some cases, this is
straightforward. dom::StyleSheet holds an arc to a style::Stylesheet.
dom::CSSRule contains a style::CSSRule (which is a cheaply cloneable
enum of Arcs).

In the case of CSSRuleList, we have a bit of an issue. There's no
corresponding arc'd style:: type for CSSRuleList. There's just
`Vec`, which is used in Stylesheet[1], MediaRule[2],
and @supports rules (not supported in servo yet).

Now, we could just put the Vec in an Arc. I'm not sure if we want to
with the extra indirection, but it's a simple solution. An alternative
is to recognize that the `Vec` is always going to be stored
within larger Arc'd objects, and just use those, by storing an

enum RuleListOwner {
Sheet(Arc),
Media(Arc),
// ..
}

This is great for the Rust code -- easy to abstract over and no extra perf cost.

However, this can't be easily passed over to C++ for stylo. There's no
way to write a corresponding C++ type that takes up the same
space/alignment as a Rust enum. We could hardcode the size and have
sizeof assertions in the tests, but that may not solve alignment
issues, especially with the unspecified Rust ABI. We could also store
an explicit tag/pointer pair which we have unsafe wrappers for on the
Rust side. Ick.

Personally I think just sticking the vec into an Arc is fine and won't
impact us much. But I don't know.

Overall, I think we need to map out the ownership graph of CSSOM in
both Servo and Stylo before starting work on it.


[1]: https://doc.servo.org/style/stylesheets/struct.Stylesheet.html
[2]: https://doc.servo.org/style/stylesheets/struct.MediaRule.html

Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Servo is a featured project on Hacktoberfest!

[Manish Goregaokar]

Every year DigitalOcean runs a program called Hacktoberfest where folks are
encouraged to make open source contributions in the form of pull requests.
As part of this, they help with discovery by featuring various projects
<https://hacktoberfest.digitalocean.com/#featured-projects> for folks to
contribute to.

I got Servo added to the list -- expect an uptick in new contributors in
this month. I'll start filing more easy issues.

Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Weekly status updates

[Manish Goregaokar]

I've always liked the idea of standu.ps with the IRC bot reporting.

Large tasks may become tricky with standups. AIUI you ping the
standups bot when you finish a task, but for long running tasks (large
PRs, etc) you can't do this so easily. With statusupdates I just add
an entry "worked more on X", with standups this might become
cluttered. But this is minor, and probably could be fixed by being
more descriptive of the subtasks.

Thanks,
-Manish Goregaokar


On Thu, Sep 22, 2016 at 9:37 PM, Lars Bergstrom <larsb...@mozilla.com> wrote:
> I've noticed that while some people are still submitting their weekly
> status updates on http://statusupdates.dev.mozaws.net/ (thank you!),
> it's both not everybody and we're missing a bunch of the more active
> community members who might like to highlight their work.
>
> I'd love to either get that moving again or move to something that
> people like more (e.g., edunham suggested http://standu.ps/ ).
>
> I find this really useful on the team so that we all know what each
> other are working on, especially since we cancelled the weekly
> meeting. It's also included externally in "This Week in Servo" so
> others get a sense for what's in progress but not yet landing.
> Finally, internally it's helpful for people funding the project to
> have a general sense for what everybody's doing without having to ask
> myself or Jack :-)
>
> Opinions? I'm also open to pushback here that status reporting is too
> much work and larsberg should just be scraping scraping harder on
> GitHub.
>
> Thanks,
> - Lars
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Filterable list of all CSS properties and their syntax

[Manish Goregaokar]

I included the Alexa numbers (these are not exactly accurate because
heycam's list counts property-value pairs, not properties, I need to write
a better script for extracting these correctly).

I also added a dashboard thingy that shows all the useful property counts
in the corner.

-Manish Goregaokar

On Mon, Aug 29, 2016 at 4:41 PM, Manish Goregaokar <manishsm...@gmail.com>
wrote:

> On Mon, Aug 29, 2016 at 2:23 PM, Chris Peterson <cpeter...@mozilla.com>
> wrote:
> > Stylo has implemented exactly one property Gecko has not: column-width.
>
> Oh, that's because Firefox implements it as -moz-column-width. I
> haven't tried merging the prefixes -- this information can be scraped
> from MDN, but it's only an issue for very few properties so I didn't
> work on that.
>
> The Chrome/Firefox implementation info is just what getComputedStyle
> contains. The Servo/Stylo implementation info is gotten by having the
> mako templates print the longhand names (this ignores any mapping to
> prefixed values that we do in stylo).
>
> I'll be sure to keep this up to date. While the MDN scraping script is
> in the repo behind that page, the way of getting property data from
> servo/stylo is a bit fiddly right now. I'll try to clean that up and
> check in patches to that repo, but I'm fine with just doing the
> updating myself.
>
> I'll also add counters to the page listing how many properties each
> one implements, and note down if it's a top 500 property.
>
> Do you plan on prioritizing these properties (like how the Wikipedia
> ones were prioritized)? I was thinking of adding a priority field, but
> I didn't because I don't know how to prioritize most of these
> properties. The Alexa numbers will certainly help, though.
>
> Thanks,
> -Manish Goregaokar
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Filterable list of all CSS properties and their syntax

[Manish Goregaokar]

On Mon, Aug 29, 2016 at 2:23 PM, Chris Peterson <cpeter...@mozilla.com> wrote:
> Stylo has implemented exactly one property Gecko has not: column-width.

Oh, that's because Firefox implements it as -moz-column-width. I
haven't tried merging the prefixes -- this information can be scraped
from MDN, but it's only an issue for very few properties so I didn't
work on that.

The Chrome/Firefox implementation info is just what getComputedStyle
contains. The Servo/Stylo implementation info is gotten by having the
mako templates print the longhand names (this ignores any mapping to
prefixed values that we do in stylo).

I'll be sure to keep this up to date. While the MDN scraping script is
in the repo behind that page, the way of getting property data from
servo/stylo is a bit fiddly right now. I'll try to clean that up and
check in patches to that repo, but I'm fine with just doing the
updating myself.

I'll also add counters to the page listing how many properties each
one implements, and note down if it's a top 500 property.

Do you plan on prioritizing these properties (like how the Wikipedia
ones were prioritized)? I was thinking of adding a priority field, but
I didn't because I don't know how to prioritize most of these
properties. The Alexa numbers will certainly help, though.

Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

> 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.

> Right now landing a change like this means being sure you're able to
> generalize enough so it works for both layout systems. If we don't gate
> on Servo, this phase would get postponed, and I think that's extremely
> dangerous.


As Jack said, this will still be a factor in the review process. AIUI
we can pull in things
from Github in try builds, and we can have a non-gating servo build
that is only run on
try. Most such architectural changes will go through this. (We can
have a hash-pinning
system if we need)

Note that I'm proposing keeping most of ports/geckolib in the new
style repo too.


> I agree that there are challenges with mirroring the root Servo
> repository into m-c, but I'd like to make sure we mention some of the
> positives that we get from it


Oh, yes. I'm not sure if this was clear already, but as someone who
will be spending
most of his time on stylo for the forseeable future, vendoring servo in-tree is
the best solution as far as my personal workflow is concerned. But I'm
trying to look
for alternatives that work for everyone, since there's a lot of
backlash on the testing
thing.

Good point on gecko-giving-back-to-servo.

> After some brainstorming, one idea that came up is that we could leave
> the tests in the servo repository, but in the mirrored copy in m-c,

I like this idea.

We could just vendor the metadata in tree (but not the tests) to fix
the expectations issue.
Feels hacky though, and might lead to something getting lost accidentally.



> And I think that having a "you should also have a Servo PR
> open" ideal is not going to fly. You might as well rename Servo to
> ThunderServo :-) Even if everybody comes into this with the best
> intentions, we do not have the tooling, process, or culture to support
> that kind of workflow on a highly unstable module like that.

Yeah, that makes sense. You're right, comm-central had a model with similar
drawbacks, and that didn't work well.


-

It seems like there's general agreement
that vendoring servo in-tree is better than this model?


I think in that case we should probably brainstorm a bit about making
it easier for Servo contributors to contribute to m-c. While the current
model still keeps it easy for people to contribute to Servo, it seems like
in the future Servo will be more closely tied to Gecko and working through
m-c might become more common. Preparing for that would be nice, and
there's plenty of time to do so.

This may involve tweaking m-c's model and/or tooling (e.g. allowing
PRs to gecko-dev, which hook into mozreview instead of getting
directly merged on gh, or making mozreview work with non-cinnabar clones
of gecko-dev). I'm also planning to dip my toes in mentoring Firefox/Gecko
bugs again, and see what the new contributor experience is like now
and how it can be improved. I already have rough ideas for this
(and a general sense of where the problems are), but that's getting
a bit off-topic for this thread.


Thanks,
-Manish
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

> The other proposal includes making sure Gecko related stylo changes
> don't break Servo, but this does not. It seems easy enough to add
> Servo's test suite to the m-c side CI, so I would propose to add that
> to your proposal. That means we only have to resolve conflicts until
> CI is fully baked instead of forever.
>
>
This brings up the issue that changes to m-c's vendor may require changes
to servo/servo,
which has the same set of problems, bringing us back to square 1 where we
just vendor
all the things.

Not gating on Servo's CI means that we can just handle it during the sync.

(Optional non-gated CI sounds nice to have though)


Bobby's claim was that almost all changes are breaking ones. If that's
> true, I don't see how we're going to avoid people needing to fix up
> the Gecko side. But at least with your proposal that more explicitly
> limited to the style system. While in theory that shouldn't make a
> difference, I think this will make it easier to deal with problems
> like intermittents. For example, there's no way a change to
> servo/servo itself could trigger intermittents on the Gecko side.
>
>
Temp-branching until a weekly sync is a solution here. Such a solution isn't
available in frankenbuild at all -- style-api-breaking-changes must be
coordinated
across repos.

Though I guess part of this depends on where ports/geckolib will live -- in
m-c only, or
in the style repo (which itself is vendored in m-c)?

If it lives in the style repo, I don't think we'll have many breaking
changes since
you can fixup geckolib when making PRs to style. Workflow for working on
stylo
is unchanged since everything is vendored anyway.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

Hi,

The current situation with the m-c vendoring for stylo is to put all of
stylo in-tree and have an autolander dance between homu (or at least Servo
buildbot) and the Gecko autolander that ensures that changes to servo/servo
or m-c are always mirrored and fully tested, on both ends.

There are a lot of issues with this. It increases cycle times for Servo
PRs. We'd need to move wpt out of tree, which discourages people from
writing tests (see the thread about tests/). Backouts on m-c tip may cause
worse problems.

An alternate solution is to break style/, tests/unit/style, and
style_traits/ (and perhaps util/) into a separate git repo, used in servo
as a git dep (We could publish on crates.io, but I don't think we need to).

It gets vendored into m-c using the same plan as servo; using autolander
voodoo to keep github.com/servo/style and m-c/some-dir/style up to date.
The downsides get limited to style, and the tests/ issue goes away. The
voodoo is also significantly less voodoo-y -- style has a smaller set of
tests which could be run in-tree from m-c itself.

(An alternate way of syncing is to use the wpt-like manually-initiated
two-way sync for style, which would further improve cycle times, but would
shift the collective burden to the person doing the sync. I'm open to this
too.)

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.
   - Landing simultaneous changes to style/ and layout/ becomes harder. We
   have path deps to simplify working on these, and landing them is two-step
   now, something we're already used to for other crates (and it's easier for
   style because it will be a git dep, not crates.io). There is the issue
   of changes to style and layout that change style's public API or otherwise
   break m-c. I'd like to avoid forcing style contributors to have an m-c
   clone handy to work on these. A simple solution is to temporarily fork into
   a branch on the style repo, and have it dealt with in the next sync. While
   this is pretty bad it's not much worse than the situation for contributing
   to style in the frankenbuild world anyway.
   - We may need to frankenbuild anyway for layout if gecko ever wants to
   use that. Though afaict that's in the far future if it ever happens, and
   the solution space will probably have changed by then. Layout could
   probably be split out if necessary (the layout logic, not the RPC/IPC
   glue), since it mainly only talks to style.
   - Style can no longer pin to deps -- it's possible that Servo's lockfile
   and Gecko's vendoring diverge. As long as semver gets followed in the deps,
   this won't be an issue. This is probably not going to be the case, but it
   shouldn't be something which we can't handle.


I personally feel that the downsides aren't that bad, compared to the
frankenbuild. It also isolates the downsides to one crate, a crate which
would anyway be tricky to work with in the frankenbuild world.

What do you think?
Thanks,
-Manish
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Problem compiling servo

[Manish Goregaokar]

rm -rf target/*/build/mozjs* should do the trick.

There was a spidermonkey update and the old build artefacts mess the build
up.

Sorry!

-Manish Goregaokar

On Sat, Aug 13, 2016 at 7:18 PM, Peter Hall <peterj...@gmail.com> wrote:

> Hi,
> I upgraded OSX this week (to 10.11.6), but also it's been a while since I
> tried to compile servo. In any case, I get errors that I'm not sure how to
> solve.
>
> The first error is:
>
> error: failed to run custom build command for `mozjs_sys v0.0.0 (
> https://github.com/servo/mozjs#94eabc21)` process didn't exit
> successfully:
> `/Users/peter/dev/rust/servo/target/debug/build/mozjs_sys-
> 661d4efe7c7ca939/build-script-build`
> (exit code: 101)
>
> Any suggestions?
>
> The full errors are here:
> https://gist.github.com/peterjoel/98a871d68946b766baaa0e964a1ca9c3
>
>
> And:
>
> $ rustc --version --verbose
> rustc 1.12.0-nightly (8787a1233 2016-08-11)
> binary: rustc
> commit-hash: 8787a12334439d47e931be26fef53381ce337c3a
> commit-date: 2016-08-11
> host: x86_64-apple-darwin
> release: 1.12.0-nightly
>
>
>
> Peter
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

On Wed, Aug 10, 2016 at 6:47 AM, Lars Bergstrom <larsb...@mozilla.com>
wrote:

> But in this model, there's also "is this a failure from one of the N
> PRs before me?" which isn't a type of failure that is common (AFAIK)
> when contributing to OSS projects. Intermittents, especially when they
> lead to PR bitrot, already chase off users in Servo. I'm worried this
> extra failure mode will compound that problem.
>


Strongly agree -- this can be a huge pain point. When I was doing rollups
in Rust this used to be a major hurdle in getting the rollups merged;
finding
out which of the ~10 PRs caused a failure is not always straightforward
and there's often ambiguity. This was still fine because I was the only
one investigating these failures, but part of this effort will be multiplied
by 10 if there is no "sheriff" handling the rollups. Intermittents make the
problem worse, and we have many of those.


Note that we don't lose pre-commit testing in the proposed autoland model.
Our cycle times become 3 hours, though. There is a (expectedly rare)
failure mode where stylo-integration fails to merge cleanly into m-c; which
is a natural byproduct of trying to marry two opposite CI models together.
But like I said it's expected to be rare so it shouldn't be an issue.

Thanks,

-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Feature detector detector for Servo debugging

[Manish Goregaokar]

It triggers for all, but the python script filters for accesses to
properties that actually should be there. I wanted it to be easy to change
the filtering logic without recompiling everything.


-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Feature detector detector for Servo debugging

[Manish Goregaokar]

Feature detection is often a pain point when figuring out why a site
doesn't work in Servo -- regular JS errors are logged and detectable, but
feature detection is silent. JavaScript's awesome coercion rules cause
similar issues when a property evaluates to false when it's really
undefined.

To help find cases where feature detection is going on, I wrote a "feature
detector detector". Basically, it logs each time a property is accessed,
where that access evaluates to `undefined`.

Some results can be found here
<https://gist.github.com/Manishearth/d3534fb65c65e4ef86f2152cf3bd2c0f>,
both with and without spoofing the UA to be firefox.

To run, clone the "FDD" branch on my mozjs fork
<https://github.com/servo/mozjs/compare/master...Manishearth:FDD?expand=1>,
and set it as a path override (paths = ["/path/to/mozjs"] in
components/servo/.cargo/config). Building and running this on any site will
spew out tons of JSON output about each possible-feature-detection property
access. Run this output through parse.py
<https://gist.github.com/Manishearth/06583087c4001f45ed3a9e74c7848211#file-parse-py>
to filter it down to property accesses for properties that actually exist
in Firefox. The list of properties in parse.py is not 100% complete (see
the comment on gen.js. Also, Location is weird), but it's close enough.

Should be useful to help find and prioritize features to work on.

Firefox may also have interest in this, so I'm seeing if a cleaned-up
version of this might be something we can merge into the main codebase.

Let me know if there are sites you'd like to see this run against!

Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

This reminds me of the original system I proposed for Rust back when
it reached the point where PRs were coming in faster than we could
test them. It's similar to what Michael proposed, though a bit more
involved: https://gist.github.com/Manishearth/f2971973e164be03890a
(yes, it does allude to binary search :p)

At the time, Firefox's model wouldn't fit well because semantic
conflicts during merge are an issue -- not actual git merge conflicts,
but two changes which are compatible with their respective parents
but not with each other. These are less of an issue in Servo or Firefox,
because these aren't bootstrapping compilers :)

Rust finally went with manual rollups -- they used to be really time
consuming but now it's mostly okay. Intermittents were a big
problem then, too, and would have broken this model completely.
Currently Servo has a pretty high rate of intermittents,

-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

Right. I think we should do both -- Servo should report 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 <ajeff...@mozilla.com> wrote:

> 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
> channel errors, and hope that any channel error will have some other error
> that gets reported.
>
> Alan.
> On Jul 3, 2016 01:10, "Manish Goregaokar" <manishsm...@gmail.com> wrote:
>
>
> At one point we were silencing MPSC and IPC errors so that the main
> backtrace is the only thing you see. Perhaps we should do that again?
>
>
> dev-servo@lists.mozilla.org wrote:
> > Is it possible to get the correct stack somehow?
> >
> > jack.
> >
> > On Sat, Jul 2, 2016 at 3:33 PM, Josh Matthews <j...@joshmatthews.net>
> 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 recent PR. This is not to say that the
> >> stacks are incorrect in any way, merely that the panic reported is not
> >> guaranteed to be the first panic that occurred. This means that a stack
> like
> >> the one in https://github.com/servo/servo/issues/12183 may appear to be
> >> solved by the changes in https://github.com/servo/servo/pull/12030, but
> that
> >> reported panic only occurred because some other thread panicked first.
> >>
> >> Unfortunately, this means that the triage process is less
> straightforward
> >> than we might otherwise hope. Please avoid the temptation to close
> issues
> >> referring to unwrapping error values from sending or receiving over
> channels
> >> without reproducing the issue yourself - these always indicate a deeper
> >> problem that requires investigation first.
> >>
> >> Cheers,
> >> Josh
> >> ___
> >> dev-servo mailing list
> >> dev-servo@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-servo
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

At one point we were silencing MPSC and IPC errors so that the main backtrace 
is the only thing you see. Perhaps we should do that again?


dev-servo@lists.mozilla.org wrote:
> 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 recent PR. This is not to say that the
>> stacks are incorrect in any way, merely that the panic reported is not
>> guaranteed to be the first panic that occurred. This means that a stack like
>> the one in https://github.com/servo/servo/issues/12183 may appear to be
>> solved by the changes in https://github.com/servo/servo/pull/12030, but that
>> reported panic only occurred because some other thread panicked first.
>>
>> Unfortunately, this means that the triage process is less straightforward
>> than we might otherwise hope. Please avoid the temptation to close issues
>> referring to unwrapping error values from sending or receiving over channels
>> without reproducing the issue yourself - these always indicate a deeper
>> problem that requires investigation first.
>>
>> Cheers,
>> Josh
>> ___
>> dev-servo mailing list
>> dev-servo@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-servo
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] New github milestone: Tech Demo

[Manish Goregaokar]

I've created a new milestone on GitHub, Tech Demo
<https://github.com/servo/servo/milestones/Tech%20Demo>. Please use it for
issues or pull requests that are related to or must be landed before the
tech demo.

Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

Coordinating rollups across two repos will be a pain. The proposed
automation sounds better to me.

-Manish Goregaokar

On Thu, Jun 23, 2016 at 10:08 AM, Michael Howell <michaelhowell...@gmail.com
> wrote:

> If the model you're proposing is "almost isomorphic" to roll ups, then why
> not just use roll ups?
>
> On Wed, Jun 22, 2016, 09:58 Bobby Holley <bobbyhol...@gmail.com> wrote:
>
> > I just chatted with Manish a little bit to sort out some details and
> > misunderstandings, and I think we're much more on the same page now.
> >
> > A few high-level points worth emphasizing:
> > * Making the Homu queue take longer would be bad and we should avoid
> that.
> > I believe the proposal would actually significantly reduce landing
> latency.
> > * The proposal does not involve hooking servo/servo up to mozilla-inbound
> > and its associated churn. As long as gecko development uses the
> > mozilla-inbound model, servo/servo would be linked to a much-more-stable
> > "mozilla-servo" integration repo, which will have very few backouts and
> > should never be closed modulo infra issues.
> > * Updating the code in both repos "in lockstep" is central to the plan,
> > because it prevents divergent forks.
> > * The details of how/when tests are run involve a lot of tweakable
> > parameters, and I am optimistic that we can adjust them to solve any pain
> > points.
> >
> > In a bit more detail, there are basically 3 ways to manage CI:
> > (1) The mozilla-inbound model (land possibly-untested stuff, run CI
> > post-commit, perform backouts and close tree as necessary)
> > (2) The bors/homu model (run the full suite on the precise commit that
> will
> > be merged, and only merge it when green)
> > (3) The relaxed bors/homu model: Run CI in parallel on pending commits.
> Any
> > mergable commits with "recent enough" green CI runs can be merged. We do
> > additional periodic post-merge CI runs on the master branch to spot the
> > occasional intra-commit bustage.
> >
> > (1) obviously sucks and (2) doesn't scale well. The proposal is to do
> > something like (3) for both projects [1]. This is the long-term plan for
> > Gecko development anyway (i.e. mandatory pre-commit testing), and
> relaxing
> > the strict homu/bors model would significantly increase responsiveness
> and
> > throughput on the servo/servo side.
> >
> > The question of exactly which pre-commit tests should be run for which
> > commits is a heuristic one that we can tweak. For example, we may decide
> > that changes to components/style require pre-commit gecko test runs, but
> > version bumps on leaf-y dependencies are safe enough to leave to the
> > post-commit sanity checking. We can play with that as we go.
> >
> > [1] It's worth noting that (3) is _almost_ isomorphic to what Rust does
> > (merging rollups of commits with green CI), which the primary difference
> > being whether rollups are tested pre- or post-commit.
> >
> > On Wed, Jun 22, 2016 at 9:03 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> >
> > > On 6/22/16 11:17 AM, Manish Goregaokar wrote:
> > >
> > >> We don't close down the tree except for CI fires
> > >>
> > >
> > > Yes, I understand your model.  You don't have to explain it to me.
> > >
> > > I was just pointing out that for normal commits you prefer the model of
> > > test-each-thing, but for style system you would prefer the model of
> > > just-test-every-so-often.  I realize the reasons for that too, but I
> > think
> > > we have a different evaluation of the resulting costs.  In
> particular
> > >
> > > If the tests fail for a PR, it is taken out of the queue until it is
> > fixed
> > >> and
> > >> reapproved.
> > >>
> > >
> > > My question is what happens when a PR stalls like this for months
> because
> > > by the time it's fixed something else has broken.  I expect this to
> > happen
> > > every so often when the PR is the style system merge.
> > >
> > > m-c does not have this model, and I'd also like to prevent marrying our
> > CI
> > >> times to those of m-c, or being affected by m-c backouts.
> > >>
> > >
> > > I understand and sympathize with that.
> > >
> > > That's why I like the sync model, it concentrates all of the conflict
> in
> > >> one operation
> > >>
> > >
> > > At the cost of possibly making that operation impos

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

[Manish Goregaokar]

On Wed, Jun 22, 2016 at 7:38 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> As a matter of dealing with test breakage and how it's resolved, do you
> also prefer doing a bunch of commits and only then running tests, and if
> they fail closing down the tree until it's all resolved?  If not, how is
> this substantively different?  I realize it's different in a practical
> sense because the costs are higher than normal per-commit testing, of
> course.
>
>
We don't close down the tree except for CI fires (and in the past, large
bitrot-prone rustups). We currently have tests run on every approved PR
(one at a time) before they are merged. We like for individual commits to
pass tests for bisecting to work well but it is not a hard requirement. If
the tests fail for a PR, it is taken out of the queue until it is fixed and
reapproved. In the meantime, the next PR in the queue is tested. We also
have travis perform a reduced set of tests on PRs so you can catch some
things that may cause it to fail before approving. Additionally, we have
the ability to "try" a PR so that it will be tested against the full suite
but not merged. We never have backouts, because master always is green.

m-c does not have this model, and I'd also like to prevent marrying our CI
times to those of m-c, or being affected by m-c backouts. That's why I like
the sync model, it concentrates all of the conflict in one operation,
instead of distributing it everywhere and making every PR that touches
anything that affects style suffer. The syncing operation is also async
(ha!) -- while being performed other Servo work can continue. Sending PRs
which look like they need testing to gecko-try should catch most issues,
the only remaining issues are when a PR (like a wrong refactor, or
something) which wasn't sent through gecko-try breaks stylo, or when
something on Gecko's vendor dir managed to land between the time the Servo
PR was tested and landed. I postulate these two cases will be relatively
rare, and these will be the only times the sync fails.

In most cases, I envision the workflow on the servo side being like:


   1. Reviewer sees PR that may need stylo testing
   2. Reviewer goes through the review process
   3. When the process is nearly over (just nits left, or whatever)
   reviewer sends PR to gecko-try via a bors command (also perhaps servo-try)
   4. gecko-try says:
  1. OK:
 1. Reviewer approves PR
 2. Our autolander queues the PR up for testing and eventually
 merges it if it passes. If it fails, fix it. Goto 3 if necessary, else
 reapprove.
 3. Perhaps trigger a sync to avoid future conflicts. This can be
 fully automated.
 2. Failed:
 1. Bad luck, one of the "relatively rare" things happened. Perform
 a sync locally, manually fixing the errors.
 2. Rebase PR and goto 3


The gecko side keeps its current workflow, with the exception that:

   - PRs which may affect servo tick a servo-stylo option in the trychooser
   before their try run
   - After such PRs merge, attempt to trigger an automated sync. Not
   necessary, as before, depends on the situation.

This is actually pretty close to the proposed model in the doc, but it
gives a lot more leeway in when the sync should happen. The proposed model
is basically equivalent to this except syncs are mandatorily part of any PR
that affects style, and can make the queue clog up. Here based on various
factors you can choose not to sync (e.g. if the queue is already full; you
can wait to trigger the sync until it empties, or if the PR probably
doesn't need a sync). We can then by trial and error figure out the best
policy for when to sync and when not to sync balancing the need for fast CI
times and the need for things to not cause colossal merge conflicts.



> You make it sound like refactorings don't introduce bugs.  ;)
>

Sure they can, but they should be less likely to :)

We will still have the full CI run on a sync so these will get caught, just
not immediately.


-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

> This has one significant drawback: it places a pretty serious burden on
> whoever performs the sync.  In particular, in addition to merging the
> actual code (already needs some expertise), they become responsible for
> handling any test failures that arise as a result of changes in the "other"
> repo.
>
>
I personally prefer having to do a controlled tough sync every now and then
over the lockstep thing.

Also, we can alleviate part of this by doing syncs smartly. Just because
you *can* make a change without touching Gecko CI doesn't mean you should
:) If the reviewer thinks that a change to Servo style is expected to
affect Gecko, a gecko-try run should be made too with a sync applied (this
automation is easy enough to write). Once it merges, perform a sync if you
feel it necessary. This lets changes like refactorings, dependency updates,
etc become less of a pain, while actual changes affecting both will still
be tested. The reverse can also exist, as a checkbox in the trychooser
interface.



-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

On discussing this in IRC, it occurs to me that my alternate solution was
poorly worded. The idea is not *necessarily* to publish style as a crate.


As I understand it, crates like webrender/rust-url which Gecko would like
to directly use (but are not part of components/) will be vendored in tree,
with a wpt-like two-way sync, instead of lockstep evolution using
autolanders. Changes to webrender would be made in m-c or servo/webrender,
whichever is more convenient, and there is a periodic sync operation.

What I wish to do is to use this solution for style. If style stops
depending on servo-specific things (right now it depends on util, but we
can split those things out), then this same solution becomes viable for it.
It is not necessary to put style in a different repo or publish it as a
crate, though I am receptive to that idea too (others may not be). This
solution lets us use existing tooling (or, tooling that is going to exist
anyway, due to WR and rust-url) and existing practices without having to
tie our CI times to m-c's. As Ms2ger says below, we are very susceptible to
the effects of slow CI.

I think perhaps it might help to get some clarity on exactly which changes
will trigger a m-c CI build in Servo. Do lockfile changes cause this build?
What about edits to util?

Thanks,

-Manish Goregaokar

On Tue, Jun 21, 2016 at 4:16 PM, Manish Goregaokar <manishsm...@gmail.com>
wrote:

> My main issue is that backouts aren't addressed. They are reasonably
> common in m-c (admittedly, this was a few years ago; I haven't been
> watching Firefox dev lately) due to the model where tests run after merges.
> On the other hand, Servo's model never has backouts, and isn't well
> equipped to deal with them. Ignoring backouts makes the model much simpler,
> much like a Penrose tribar without the third edge :)
>
>
> Servo is used to making atomic changes, getting a quick-ish merge to
> master, and iterating off that. We often are blocked on someone else's PR
> landing, for example (perhaps due to the smaller team?). I suspect that our
> code has organically grown to make this easier, and as Lars mentioned last
> week, this has made the team care about CI cycle times a lot more. I was
> chatting with mystor about this last week, and it seems like Gecko is more
> used to the push-and-forget model, where you don't care about a patch once
> it is in inbound. This means that if the tree gets closed due to
> bustage/backouts, it's fine, even in a world without inbound.
>
> Most solutions for backouts will involve tree closing for Servo too, which
> breaks this workflow. Something has to give; I suspect we'll just have to
> learn to use `try` more and follow a similar r+-and-forget model :)
>
> An alternate solution is to just publish style as a crate. Bobby broke off
> a lot of the servo-specific dependencies when doing the geckolib stuff, now
> style just depends on util (and plugins for linting). We can publish
> style/util (the geckolib version) and ignore plugins (they're not
> safety-necessary for style). This makes it harder to contribute to servo
> style, but it makes it easier to bump Servo's dependencies without having
> to make a corresponding commit to m-c. Style depends on a lot of crates.io
> dependencies -- in the proposed system if one is bumped in Servo it will
> have to be bumped in m-c too.
>
> Playing around with git log
> <https://manishearth.pastebin.mozilla.org/8878551> (unscientifically)
> shows me that most commits to style touch other crates too, mostly script
> and then layout -- so it might be best to not split style out.
>
> Thanks,
>
> -Manish Goregaokar
>
> On Mon, Jun 20, 2016 at 8:31 PM, Lars Bergstrom <larsb...@mozilla.com>
> wrote:
>
>> As many of you may have seen from the document
>> (
>> https://docs.google.com/document/d/1uubYE7JXaVY10PoAY9BVx8A-T11ZxP1RYqNOrFJwdcU/edit
>> )
>> and discussions on dev-build and at the workweek, we have an
>> increasing desire to be able to try to develop and potentially ship
>> Servo code in Firefox. While this is exciting (yay, customers! yay,
>> faster Firefox!), it also means that we're going to be subject to some
>> growing pains as we around the requirements of our largest and best
>> customer.
>>
>> We'd like to hear your comments here (or privately, if you prefer)
>> about these proposed changes. We're trying to figure out all of the
>> details, so now is the right time to bring up objections or
>> requirements!
>>
>> 1) Move our CI testing for servo/servo off of buildbot and into releng.
>>
>> In order to ensure Servo changes do not break Firefox and vice-versa,
>> we are proposing unifying our autolanders and moving Servo's tests (as
>> Tier 1 - must pass to commit!) int

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

[Manish Goregaokar]

My main issue is that backouts aren't addressed. They are reasonably common
in m-c (admittedly, this was a few years ago; I haven't been watching
Firefox dev lately) due to the model where tests run after merges. On the
other hand, Servo's model never has backouts, and isn't well equipped to
deal with them. Ignoring backouts makes the model much simpler, much like a
Penrose tribar without the third edge :)


Servo is used to making atomic changes, getting a quick-ish merge to
master, and iterating off that. We often are blocked on someone else's PR
landing, for example (perhaps due to the smaller team?). I suspect that our
code has organically grown to make this easier, and as Lars mentioned last
week, this has made the team care about CI cycle times a lot more. I was
chatting with mystor about this last week, and it seems like Gecko is more
used to the push-and-forget model, where you don't care about a patch once
it is in inbound. This means that if the tree gets closed due to
bustage/backouts, it's fine, even in a world without inbound.

Most solutions for backouts will involve tree closing for Servo too, which
breaks this workflow. Something has to give; I suspect we'll just have to
learn to use `try` more and follow a similar r+-and-forget model :)

An alternate solution is to just publish style as a crate. Bobby broke off
a lot of the servo-specific dependencies when doing the geckolib stuff, now
style just depends on util (and plugins for linting). We can publish
style/util (the geckolib version) and ignore plugins (they're not
safety-necessary for style). This makes it harder to contribute to servo
style, but it makes it easier to bump Servo's dependencies without having
to make a corresponding commit to m-c. Style depends on a lot of crates.io
dependencies -- in the proposed system if one is bumped in Servo it will
have to be bumped in m-c too.

Playing around with git log
<https://manishearth.pastebin.mozilla.org/8878551> (unscientifically) shows
me that most commits to style touch other crates too, mostly script and
then layout -- so it might be best to not split style out.

Thanks,

-Manish Goregaokar

On Mon, Jun 20, 2016 at 8:31 PM, Lars Bergstrom <larsb...@mozilla.com>
wrote:

> As many of you may have seen from the document
> (
> https://docs.google.com/document/d/1uubYE7JXaVY10PoAY9BVx8A-T11ZxP1RYqNOrFJwdcU/edit
> )
> and discussions on dev-build and at the workweek, we have an
> increasing desire to be able to try to develop and potentially ship
> Servo code in Firefox. While this is exciting (yay, customers! yay,
> faster Firefox!), it also means that we're going to be subject to some
> growing pains as we around the requirements of our largest and best
> customer.
>
> We'd like to hear your comments here (or privately, if you prefer)
> about these proposed changes. We're trying to figure out all of the
> details, so now is the right time to bring up objections or
> requirements!
>
> 1) Move our CI testing for servo/servo off of buildbot and into releng.
>
> In order to ensure Servo changes do not break Firefox and vice-versa,
> we are proposing unifying our autolanders and moving Servo's tests (as
> Tier 1 - must pass to commit!) into releng. This would also mean
> running relevant Firefox tests against Servo.
>
> 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, PR, cargo publish, pull down, repeat" workflow) and in the
> one that is being tested and co-landed with Firefox. We plan to push
> webrender to crates.io to ensure it is still separately usable by
> other projects.
>
> 3) Get Stylo and WebRender onto stable Rust.
>
> It is the intention to ship Rust code in Firefox using only stable
> Rust features. That's not a hard requirement, but it means trying to
> either stabilize features or rip out any unstable/nightly-only
> features in use in either the Stylo or WebRender dependency graphs.
>
> Please provide feedback on these topics or any others that come to
> mind around these changes! Many of us across the company will be
> working hard in the coming weeks to get a concrete proposal and
> timelines in place for this work, so please reach out with your
> concerns ASAP.
>
> Thanks!
> - Lars
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo without Bluetooth

[Manish Goregaokar]

It seems like it's still checking the git repo for the feature. Might be
worth landing your devices changes and proceeding from there.

-Manish Goregaokar

On Thu, Jun 2, 2016 at 12:56 PM, Dirkjan Ochtman <dirk...@ochtman.nl> wrote:

> On Wed, Jun 1, 2016 at 10:53 AM, Manish Goregaokar
> <manishsm...@gmail.com> wrote:
> > It should be net/device/bluetooth. For some reason the crate is imported
> as
> > "device" instead of "devices" in net
>
> I'm somehow still running into trouble. Can someone spot the mistake?
>
> djc@dochtman-dev servo $ cat ~/.cargo/config
> paths = ["/home/djc/src/devices"]
> djc@dochtman-dev servo $ cat ~/src/devices/Cargo.toml
> [package]
> name = "device"
> version = "0.0.1"
> authors = ["The Servo Project Developers"]
>
> [features]
> default = ["bluetooth"]
> bluetooth = ["blurz"]
>
> [target.'cfg(target_os = "linux")'.dependencies]
> blurz = { version = "0.1.7", optional = true }
> djc@dochtman-dev servo $ ./mach build --dev
> error: Package `device v0.0.1
> (https://github.com/servo/devices#cac09521)` does not have these
> features: `bluetooth`
> Build completed in 0:00:01
>
> Cheers,
>
> Dirkjan
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo without Bluetooth

[Manish Goregaokar]

Oh, interesting. I have had strange errors when not fully specifying the
features but the reason might have been something else.

We should just do that, then, agreed.

-Manish Goregaokar

On Tue, May 31, 2016 at 8:21 PM, Simon Sapin <simon.sa...@exyr.org> wrote:

> On 31/05/16 16:40, Manish Goregaokar wrote:
>
>> My main issue with cargo features is that they would pollute all the
>> Cargo.tomls in the dependency tree between servo and devices, and if
>> another dependency is added (even amongst these crates) it would have to
>> be
>> added, or else we may get confusing compile errors.
>>
>> 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,
>>
>
>
> I think we can have something like this in components/servo/Cargo.toml :
>
> [features]
> no-bluetooth = ["net/devices/no-bluetooth"]
>
>
> but IIRC this
>> isn't always supposed to work (since all the other dependency paths do not
>> have it enabled). If this turns out to be working reliably I'd prefer to
>> do
>> this, though it may unexpectedly break in the future.
>>
>
> Why isn’t this supposed to work? Based on conversations with Alex, Cargo
> by design builds a crate with the union of all requested features. There is
> no need for all dependents to specify the same set of features and this
> isn’t an accident.
>
> --
> Simon Sapin
>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo without Bluetooth

[Manish Goregaokar]

My main issue with cargo features is that they would pollute all the
Cargo.tomls in the dependency tree between servo and devices, and if
another dependency is added (even amongst these crates) it would have to be
added, or else we may get confusing compile errors.

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 (since all the other dependency paths do not
have it enabled). If this turns out to be working reliably I'd prefer to do
this, though it may unexpectedly break in the future.

-Manish Goregaokar

On Tue, May 31, 2016 at 8:04 PM, Jack Moffitt <j...@metajack.im> wrote:

> > 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.
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Difficulty getting access to Rust nightly build while building Servo.

[Manish Goregaokar]

This is the folder you want:
https://static.rust-lang.org/dist/2016-05-14/index.html

-Manish Goregaokar

On Mon, May 16, 2016 at 3:17 PM, <sow...@gmail.com> wrote:

> Hi,
>
> I am trying to port Servo to Power8/LE platform (ref thread:
> https://groups.google.com/forum/#!topic/mozilla.dev.servo/iYRZBEGNUNQ).
>
> As pointed out by Michael Howell I need to use Rust nightly builds for
> building Servo. Since I do have an older version of Rust (1.8.0) available
> on Power8/LE, I thought of downloading the latest Rust code from the
> nightly build location (which I found in the build logs printed by Servo).
> I tried accessing
> https://static-rust-lang-org.s3.amazonaws.com/dist/2016-05-14/ from two
> different browsers but was unable to get access to it. Firefox gave me
> following XML:
>
> AccessDeniedAccess
> Denied00698F8B6442B6F9Yha0AvbNYr48m/HOdzmT9lRMs59xkjdey9+JycwHNAdMmDz3vCF0qDlTjTXxQTSYSgW9WHC1u5s=
>
> while IE gave me "HTTP 403 Forbidden" message with following error:
>
> The website declined to show this webpage
>
>   HTTP 403
>
> Most likely causes:
> •This website requires you to log in.
>
> Just to ensure if anonymous/guest login works, I tried to access
> static-rust-lang-org.s3.amazonaws.com using ftp, but the connection timed
> out. (I could ping this server successfully though).
>
> Any idea how I can access static-rust-lang-org.s3.amazonaws.com or any
> alternate server to get the source code associated with Rust nightly build
> used by Servo?
>
> Thanks,
> Atul.
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Pull request template

[Manish Goregaokar]

If this is required for all PRs it could break the workflow of those who
use `hub` to make PRs from the command line, but I'm sure that can be
hacked around.



Otherwise, +1 for the idea overall.

Might want to explicitly mention "(for DOM, CSS, or layout changes)" for
the third entry.

It might also be nice to have bors' approval message note travis failures
(only travis for now, appveyor isn't always passing) if a travis-failing PR
is approved.

-Manish Goregaokar

On Fri, May 6, 2016 at 8:43 PM, Josh Matthews <j...@joshmatthews.net> wrote:

> Github introduced templates for issues and pull requests a couple months
> ago [1]. I'm interested in making use of them to address common points in
> our process where new contributors often miss steps. For example, consider
> a pull request template that looked like this:
>
> ```
> Thanks for contributing to Servo! Please add an `X` inside each `[ ]` when
> the step is complete:
> - [ ] `./mach build` does not report any errors
> - [ ] `./mach test-tidy` does not report any errors
> - [ ] These changes modify existing tests or add new ones, or update
> expected results in `ini` files OR:
> - [ ] These changes do not require tests
>
> Pull requests that do not address these steps are welcome, but they will
> require additional verification as part of the review process.
> ```
>
> This addresses common themes of:
> - contributors not knowing about `./mach test-tidy`
> - reviewers r+ing without waiting for TravisCI results
> - reviewers r+ing without requiring tests
>
> I'm on the fence about whether we should accept PRs that remove this
> boilerplate, since it doesn't feel like a significant burden to fill out to
> me. Thoughts?
>
> Cheers,
> Josh
>
>
> [1] https://github.com/blog/2111-issue-and-pull-request-templates
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Moving away from merge commits

[Manish Goregaokar]

> I don't remember all the arguments; but the point that stuck with me was
> that such rebases are generally untested,
>

Nothing goes into master without being tested in the form master will be
post-merge


> Automatic patch merging works out surprisingly often -- but sometimes it
> doesn't. If there is a bad merge commit, `git bisect` will clearly point
> to it as the culprit; while problems introduced in a rebase will in no
> way indicate the rebase as the cause.
>

note that git bisect gets rather muddled with merge commits unless you
teach it to only bisect over merges.




-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Moving away from merge commits

[Manish Goregaokar]

Yeah, it does, that's what homu does currently.

-Manish Goregaokar

On Wed, Apr 27, 2016 at 9:08 PM, Nick Fitzgerald <nfitzger...@mozilla.com>
wrote:

> On Wed, Apr 27, 2016 at 8:34 AM, Matt Brubeck <mbrub...@mozilla.com>
> wrote:
>
> > On Wed, Apr 27, 2016 at 7:25 AM, Manish Goregaokar <
> manishsm...@gmail.com>
> > wrote:
> >
> > > Another reason I prefer merge commits is that it becomes very easy to
> > hunt
> > > down which PR caused a bug (after using blame or pickaxe).
> >
> >
> > We could potentially also make homu add this info (PR# and head commit)
> to
> > the commit message or headers when it pushes a PR to auto.  If it's
> > rebasing, then it's going to be rewriting commits anyways, so this
> > shouldn't cause any additional problems.
> >
>
> ​Does github automatically close pull requests when the commit message has
> "Fixes #12345"? I know that works for issues, but I don't know if it works
> for pull requests as well.​
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Moving away from merge commits

[Manish Goregaokar]

We actually support linear landing in homu, however since github has no way
of automarking PRs  as "merged" through the API (it only works if the PR
actually merged), the support is a bit flaky (it will edit the PR title to
say [merged] and close it). I hope this changes soon.

I personally prefer having the merge commit since it makes bisects more
reliable. Each merge commit is "known good", so bisecting over all merge
commits will make it possible to find broken PRs without false positives
coming in the way*. We try to ensure that no individual commit will fail to
build, but we don't test this on automation so there can always be
build/test failures hidden within the set of commits from a PR. In a linear
model these will cause problems unless we start testing on every commit
(which is unlikely).

Another reason I prefer merge commits is that it becomes very easy to hunt
down which PR caused a bug (after using blame or pickaxe). This can be done
by opening the commit in github too, but that feature doesn't always work.
Finding PRs from commits is something I find myself doing a lot more than
bisecting. This can be overcome using a dummy linear "merge commit" with PR
info, however.

(These aren't really strong preferences. I am okay with linear history too)

As far as syncing is concerned AIUI we can still sync after flattening the
history. But yeah, it's not ideal.

*Admittedly this is a bit fiddly to do with git, requires some use of
rev-list and skip. But it's possible; I recall doing this once.

Thanks,
-Manish Goregaokar

On Tue, Apr 26, 2016 at 11:50 PM, Gregory Szorc <g...@mozilla.com> wrote:

> Servo developers,
>
> I noticed that Servo and a number of other Servo related Git repos have
> tons of merge commits. This is the Git[Hub] way after all: create a merge
> commit for every pull request.
>
> The thing is, I'm not a huge fan of merge commits in version control,
> especially for large projects. I like having simple, linear history where
> any commit you land on is "good," can be built, and bisected on. This is
> more or less what we do in mozilla-central (ignore the merge commits for
> the integration repos - those were a necessary evil to deal with scaling
> issues 4+ years ago and are going away). There are other reasons to avoid
> merge commits too. See the giant wall of text I wrote in bug 1266863 on the
> subject.
>
> Thinking forward to a day when we start vendoring more Rust/Servo
> components into mozilla-central and the VCS "syncing" complications that
> arise from it, I would much rather be dealing with Servo repos with linear
> history because well, linear is simpler than the DAG spiderweb that merge
> commits produce (run `gitk` on the Servo repo to see what I'm talking
> about).
>
> May I propose Servo change its landing bot to rebase commits instead of
> merging them so that the repo history be linear so all the complexities
> around merge commits can go away?
>
> FWIW, other VCS hosting and landing services (like Gitlab and MozReview)
> have a button that rebases instead of merges for landings. Furthermore,
> Facebook rebases on many of their GitHub projects (they don't use the
> buttons/APIs on GitHub). So there is definitely precedence for rebasing
> instead of merging.
>
> Obviously you can't force every random Rust project on GitHub to adopt a
> linear commit model. All I'm asking is that Servo and its immediately
> related projects consider changing their ways. Who knows, perhaps by doing
> so you'll help convince GitHub that there are valid use cases for linear
> repos and they'll support rebasing in their web UI. At the rate they are
> copying good ideas from Gitlab and other hosting providers, I wouldn't be
> surprised if they were already considering it :)
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Questions about GSoC File Support project

[Manish Goregaokar]

-Manish Goregaokar

On Wed, Mar 16, 2016 at 1:37 AM, Manish Goregaokar <manishea...@gmail.com>
wrote:

>
> On Tue, Mar 15, 2016 at 3:13 PM, Zhen Zhang <izgz...@gmail.com> wrote:
>
>>
>> 1. About FileList API, It is said to be *at risk* to be replaced by
>> Array. <https://w3c.github.io/FileAPI/#filelist-section> Do we have to
>> take this into consideration?
>
>
> We still need to implement it, since the `files` attribute for form inputs
> is quite useful and the spec hasn't yet changed to make it an array. So no,
> not really, though if you'd like to not implement this and spend more time
> working on something else that's totally fine.
>
>
>> 2. Although I read nearly everything I can get from input element, form
>> element, Blob interface …, but I am still having a hard time trying to
>> understand *when a file on disk got read into the memory and used to
>> construct a Blob object*.
>>
>
> See https://w3c.github.io/FileAPI/#blob, especially the first three
> lines, as well as the first two lines and the blue box here
> <https://w3c.github.io/FileAPI/#file>. Basically, Blobs/Files can be
> in-memory blobs (our current Blob implementation handles this), but they
> can also refer to on-disk blobs which have not been read into memory. So,
> if a blob is to be constructed from on-disk data, the disk data is not read
> into memory at all, instead the blob will just contain an open file
> descriptor and a byte range, or something similar. If the file changes in
> the meantime, errors might be thrown
> <https://w3c.github.io/FileAPI/#ErrorAndException> (though I don't think
> this happens in practice except for permissions errors).
>
> You can test this by creating a simple HTML page with a file upload, and
> verifying that if the file changes in the filesystem, reading the File
> object (accessed via input_element.files[0], read via URL.createBlobURI)
> before and after the change will give different results even if the file
> object was not touched on the javascript side.
>
> (interestingly, blobs referring to on-disk data pin their `size` and
> `lastModified` fields to the values on creation, and this isn't updated at
> all even though an access of the data will get you up to date data)
>
>
>> 3. Drag & Drop <http://www.sitepoint.com/html5-file-drag-and-drop/> of
>> selecting files from file system — This looks related, but I don’t know if
>> we should pay more attention to it.
>>
>
> It's possible to do. However, this first needs regular dragdrop event
> support, which might not be as easy to implement. It additionally will need
> handling of file dragdrop in Glutin. This might take up a lot more time
> than we want it to.
>
>
>> 4. What is the idea behind using GenerationId
>> <https://doc.servo.org/script/dom/htmlformelement/struct.GenerationId.html>?
>> I am a bit confused because there is little doc about it.
>>
>
> It takes part in planned navigation
> <https://html.spec.whatwg.org/multipage/#planned-navigation>.  This
> basically handles cases where a form submit button is clicked once, but
> before the page navigates you quickly change one of the inputs and submit
> again. Each submission event is queued as part of "planned navigation", but
> the first submission event will have an outdated generation id (which is
> bumped every time the form is submitted), and only the second navigation
> event will happen.
>
> Thanks,
> -Manish Goregaokar
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] PSA: incoming Windows CI (AppVeyor)

[Manish Goregaokar]

This has been deployed.

https://github.com/servo/servo/pull/9884#issuecomment-192805671

The builder is called "status-appveyor" and behaves similar to Travis.

I'll be watching the queue today and tomorrow. Revert the salt deployment if 
anything goes wrong.

Thanks,

-Manish

larsb...@mozilla.com wrote:
> We are in the process of enabling Windows CI on the main Servo
> repository. We're using Homu + AppVeyor (http://appveyor.com/) to do
> the testing, in a similar manner to how we use Homu + Travis on other
> repositories. Current Linux and Mac builds will still be performed on
> our BuildBot configuration. Status and failures for Windows should be
> reported into the PR as usual.
>
> We have a Professional AppVeyor subscription with additional
> concurrent builders being enabled. The build times are shorter than
> our long-pole CI, and we can add more concurrent builders if enabling
> this has an impact on our PR landing times.
>
> If you need to test a build on an AppVeyor instance and do not have a
> Windows VM, There is a really neat trick for allowing you to RDP
> (Microsoft Remote Desktop) into a worker by editing the appveyor.yml
> file in your PR branch:
> http://www.appveyor.com/docs/how-to/rdp-to-build-worker
>
> Many thanks to Vlad for doing the initial Windows porting work, Manish
> for his work on the CI bits, and Jayflux, uk992, frewsxcv, and many
> others for additional debugging on the Windows builds themselves!
> - Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Fwd: Re: Suggested code review workflow

[Manish Goregaokar]

One thing that I've found pretty useful (at least when digging into the
history
of some Rust feature) is that the merge commits in both Rust and Servo
contain
the full contents of the pull request text (not comments, just the PR
message).
However, there still are "fixes #123" type PR messages since nobody wants to
retype what the issue says.


-Manish Goregaokar

On Sun, Feb 21, 2016 at 5:58 AM, Lars Bergstrom <larsb...@mozilla.com>
wrote:

> This may also be less of a big deal here at Mozilla, where there's
> (presumably?) only been one bug database since 1998 and will only be
> one forever, but when I was at MS, I had to make accessibility fixes
> in some code that was a bit more than 20 years old, and "fixes
> B1#2003" is really tough to track down, when the bug database for B1
> has long been retired and everybody who worked on it is either retired
> or Bill Gates (he wasn't retired yet).
>
> At least in Servo, I could certainly see a world where we move off of
> GitHub Issues some day, and telling people, "oh, you need to go to
> larsberg's git mirror of the old issues repo and use his hacked-up web
> frontend to look for the bug, but remember to subtract 1024, because
> he couldn't build nice UI..." is bad.
>
> So, just based on old battle wounds, I guess I'm more in the camp
> putting justification for a piece of code near the code itself, with a
> bug link mainly if there's some lengthy historical baggage, a comment
> thread that captures an old architecture war, etc.
> - Lars
>
>
> On Sat, Feb 20, 2016 at 6:02 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> > On 2/20/16 5:10 PM, Josh Matthews wrote:
> >>
> >> (as a random comment, I never read multiline comments for Gecko. Only
> the
> >> first line + the bug number. It is the bug where the relevant
> information
> >> needs to be available. Whether it it available also elsewhere is less
> >> important, IMHO.)
> >
> >
> > Having the info in a bug is nice, but having to read 30, or 150, or 500
> bug
> > comments to find it can be less nice...
> >
> > I think Gecko tends to rely to much on the "it's in the bug" crutch and
> not
> > put enough info into the commit message, personally.
> >
> > -Boris
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] IndexDB project

[Manish Goregaokar]

On Tue, Dec 15, 2015 at 9:39 AM, Robert O'Callahan <rob...@ocallahan.org>
wrote:

>
> FWIW I think this project falls into the category of "things we know will
> work in Servo". It might be more valuable to do a project from which we
> would learn more.


We should probably start implementing necessary things too, not only
focusing on new experiments :)

Thanks,

-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] IndexDB project

[Manish Goregaokar]

More or less. If you're going to pick leveldb it would be better to use
rocksdb (which is a leveldb fork, IIRC) since there is a Rust wrapper
that's in use by others.

-Manish Goregaokar

On Tue, Dec 15, 2015 at 11:03 AM, Shing Lyu <s...@mozilla.com> wrote:

> Thank you guys.
>
> So from what I've learn so far, I should start with
> 1. Choose a backend and write a Rust wrapper for it (options: LevelDB or
> SQLite4)
> 2. Talk to Gecko guys about how to implement quota management framewok
>
> Am I understanding it correctly?
>
> Regards,
> Shing
>
> 2015-12-15 12:27 GMT+08:00 Manish Goregaokar <manishsm...@gmail.com>:
>
>>
>> On Tue, Dec 15, 2015 at 9:39 AM, Robert O'Callahan <rob...@ocallahan.org>
>> wrote:
>>
>>>
>>> FWIW I think this project falls into the category of "things we know
>>> will work in Servo". It might be more valuable to do a project from which
>>> we would learn more.
>>
>>
>> We should probably start implementing necessary things too, not only
>> focusing on new experiments :)
>>
>> Thanks,
>>
>> -Manish Goregaokar
>>
>
>
>
> --
> Shing Lyu
> QA, Mozilla Taipei
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] IndexDB project

[Manish Goregaokar]

Apparently SQlite4 has a good kv store included, but nox knows it better
and understands the justification.

I think firefox uses sqlite (3?); it uses sqlite for everything.



-Manish Goregaokar

On Tue, Dec 15, 2015 at 9:12 AM, Jack Moffitt <j...@metajack.im> wrote:

> Why would we use a nearly full sql engine for a key value store? What
> do the other browsers use to back IndexDB?
>
> jack.
>
> On Mon, Dec 14, 2015 at 8:31 PM, Manish Goregaokar
> <manishsm...@gmail.com> wrote:
> > We were thinking of SQLite4, however there seem to be people using
> > rocksdb+rust in production (https://github.com/spacejam/rust-rocksdb?)
> >
> > -Manish Goregaokar
> >
> > On Tue, Dec 15, 2015 at 8:57 AM, Jack Moffitt <j...@metajack.im> 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
> >> 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, Shing Lyu <s...@mozilla.com> wrote:
> >> > Hi,
> >> >
> >> > I'm Shing from the Mozilla Taipei office. I asked Lars for interesting
> >> > but
> >> > not urgent (don't want to block critical feature) during the Mozlando
> >> > workweek, he suggest me to look into IndexDB support.
> >> >
> >> > I wonder if anyone can help me with
> >> > * Split it into smaller work items
> >> > * Point me to previous patches
> >> >
> >> > I also know some folks in the Taipei office are interested in
> >> > contributing
> >> > to Servo. So I think we might be able to form a small project group so
> >> > we
> >> > can help each other.
> >> >
> >> > Any suggestions or comments?
> >> >
> >> > Thank you.
> >> >
> >> > Regards,
> >> > Shing
> >> >
> >> > --
> >> > Shing Lyu
> >> > QA, Mozilla Taipei
> >> > ___
> >> > dev-servo mailing list
> >> > dev-servo@lists.mozilla.org
> >> > https://lists.mozilla.org/listinfo/dev-servo
> >> ___
> >> dev-servo mailing list
> >> dev-servo@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-servo
> >
> >
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Mozlando meeting notes

[Manish Goregaokar]

This workweek was quite fun and productive! Thanks, everyone!

Alan had some ideas for reducing rooting in the DOM. I've got a writeup here
<https://gist.github.com/Manishearth/014c92f8d27ee6a04eee> of the ideas we
fleshed out.
It's not something we need to look further into now since Magic DOM
probably will change the landscape.


-Manish Goregaokar

On Sat, Dec 12, 2015 at 11:41 PM, Anthony Ramine <n.ox...@gmail.com> wrote:

> > Le 12 déc. 2015 à 09:56, Lars Bergstrom <larsb...@mozilla.com> a écrit :
> >
> > Thanks to everybody for a fantastic workweek! I was impressed by how
> > well we did having a lot of hard conversations about long-pending
> > architectural changes, drilling into the open issues, and determining
> > the next steps to evaluate possible solutions. I've attempted to
> > format the notes from these meetings and put them up on the wiki, as
> > usual.
>
> It's not the DOM that is magic, it's the team. It was a real pleasure to
> finally put a face on all these IRC handles, see you next time!
>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Question about webidl files and old versions of servo

[Manish Goregaokar]

You should store imageData inside a JS pointer, like so (assuming ImageData
is also a #[dom_struct])


#[dom_struct]
 pub struct ImageRequest {
 reflector_: Reflector,
 state : ImageState,
 currentUrl : URL,
 imageData : JS,
}

See XMLHttpRequest::Upload
<https://github.com/servo/servo/blob/2dab0e15845f3ae625ca4b89facd62c2f2adb8b3/components/script/dom/xmlhttprequest.rs#L464>
for an example of this pattern being used in a getter. You can do the same
with the `url` attribute; however in this case it might be preferable to
store a parsed URL (url::Url <http://doc.servo.org/url/struct.Url.html>),
instead of a Javascript URL object (dom::url::URL
<http://doc.servo.org/script/dom/url/struct.URL.html>). You can use
URL::new_inherited() to create a JS URL from a regular one.


The reason it expects Root is because these are Javascript objects, and the
DOM structs are just the "Rust side of things"). Root/JS wraps around the
struct and includes things like how it interacts with the JS garbage
collector.

The only time you should be returning a non-Root type is if it's a
primitive, string, or a webidl-defined enum (e.g. WebSocket::BinaryType
<https://github.com/servo/servo/blob/2dab0e15845f3ae625ca4b89facd62c2f2adb8b3/components/script/dom/websocket.rs#L374>,
defined here
<https://github.com/servo/servo/blob/2dab0e15845f3ae625ca4b89facd62c2f2adb8b3/components/script/dom/webidls/WebSocket.webidl#L7>
).

Looking at your PR, you'll also need to add the webidl file (as well as a
dom module) for ImageData
<https://html.spec.whatwg.org/multipage/scripting.html#imagedata>.

Do you have a link to the spec for ImageRequest? I couldn't find it after
some quick searching.


Let me know if you need more help!

Thanks,


-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] PSA: Review delegation enabled for homu

[Manish Goregaokar]

Bit late to the party, but I think there are a couple of core issues
causing this debate:

There are actually two kinds of trust involved. First is the trust to not
botnet the CI, basically
everyone here (at least everyone with try) has that. But that's not the
actual one being discussed
here. The second is not really a form of "trust", rather it's the level of
familiarity involved in
the codebase to know the areas of code where small changes may cause big
problems. For example, I
would probably ask for re-review on rebases of my own changes to layout
code or bindings code. Often
a PR is to an area of code where stuff is straightforward and there's very
little chances for things
to mess up, which is where delegate+ comes in. Other times it may be in an
area which some things
need to be done precisely, and a rebase needs review -- but it's not always
possible to tell these
areas apart at first glance. Reviewers have the "trust" that they know when
review-carry is
appropriate. The debate boils down to whether or not everyone has this kind
of "trust". delegate+
lets reviewers mark a PR as being in an area of code where there's not much
that can be
inadvertently broken. (This sort of addresses bholley's point about "a
contributor is likely to find
themselves with carry privileges in some situations but not others")

The second issue is that reviewers themselves shouldn't be review-carrying
often in the first place.
We do it, but I don't think everyone agrees that we should, not as often at
least. In the past it
wasn't so necessary, either -- I don't recall seeing as many merge
conflicts in the past as I do
now. Most of the conflicts are due to import sorting, however, now that we
enforce stronger sorting
(i.e. within use declarations). It's also a workflow thing: most of us
don't seem to structure our
workflow to depend on existing PRs (if it hasn't landed yet, base your work
off the existing
changes, and rebase+PR when the first one lands). Folks like bholley
actively working cross- crate
can't use this workflow. Path overrides are useful in those cases, but
aren't as ergonomic.

Given that we've got a lot more merge conflicts and stuff happening these
days, I think we might
need to start being more liberal with review-carry, both as reviewers and
non-reviewers. As jdm
mentioned in the meeting, this codifies existing practice to not really
review rebases thoroughly.

FWIW I'm okay with being less restrictive with r+ privs and maintaining a
distinction between
reviewers and those-with-r+ (committers). Those-with-r+ should use it in
case of import rebases,
when a reviewer has said "r=me after rebase" or "r=me after nits", or in
other cases where it's
obvious that the rebase can't break anything.

-Manish
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] PSA: Review delegation enabled for homu

[Manish Goregaokar]

After some
<https://github.com/servo/servo/wiki/Meeting-2015-11-02#review-carry-over>
discussion
<http://logs.glob.uno/?c=mozilla%23servo=10+Nov+2015=10+Nov+2015=delegate#c298415>
I've landed <https://github.com/barosl/homu/pull/111> and enabled review
delegation for homu.

This means that any homu command containing `delegate=USER` will give that
user full reviewer status for the scope of that PR (i.e., they can use all
homu commands for that PR). You can also use `delegate+` as a shortcut to
delegate to the PR author. `delegate-` undoes delegation.

Reviewers: In case of "r=me with minor nit" situations (where the author is
trusted enough to not add our infra to a botnet or whatever), try to use
`@bors-servo delegate+` so that the author can finish up the PR on their
own. This should ease up the workflow for non-reviewers.

You can see it in action here <https://github.com/servo/saltfs/pull/160>.

Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling cases where the spec is inefficient and not followed by anyone

[Manish Goregaokar]

Oh, yeah, in that case we should just mimic the other browsers and file
bugs.

-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling cases where the spec is inefficient and not followed by anyone

[Manish Goregaokar]

On Wed, Nov 4, 2015 at 9:17 PM, Ms2ger <ms2...@gmail.com> wrote:

> I'm not sure why you scoped this to inefficient spec algorithms


Because inefficient or complexity-inducing specs cause problems, the rest,
less so.

If the spec isn't consistently implemented across the board, but
implementing the spec is low-effort (and doesn't hit perf) for us,
we can just implement it, file a spec bug, and reimplement if it ever gets
fixed. Whereas if it's something like the :target or
HTMLFormControlsCollection thing,we have to needlessly implement extra
functionality or refactor parts of DOM introducing inefficiencies,
and if the spec ever gets fixed, rip it all out.

I'd prefer to avoid diverging from the spec wherever possible -- even if
other browsers disagree (with the spec and with each other), implementing
what the spec says (rather than picking our favorite browser and mimicing
it) and filing a bug -- if it's not too hard to do so -- is what we should
do.

-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

[Manish Goregaokar]

We probably can't do it in an automated way; tests being converted to WPT
need to match spec and usually also need a spec link in the top.


We could, however, import them wholesale into Servo's
tests/wpt/mozilla/foo, and then manually pick through them.

-Manish Goregaokar

On Wed, Nov 4, 2015 at 6:25 AM, Robert O'Callahan <rob...@ocallahan.org>
wrote:

> On Wed, Nov 4, 2015 at 1:48 PM, Manish Goregaokar <manishsm...@gmail.com>
> wrote:
>
>> That sounds like a good idea. Perhaps we should do this on the
>> mozilla-central side; move things out of mochitest into WPT?
>>
>> Is there an easy way of identifying browser-agnostic mochitests?
>>
>
> Maybe grepping for the obvious showstoppers (SpecialPowers, EventUtils.js)
> and just trying to run the rest...
>
> Regexp-based mass conversion might be reasonable too, with some human
> review.
>
> Rob
> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Handling cases where the spec is inefficient and not followed by anyone

[Manish Goregaokar]

We've recently had two <https://github.com/servo/servo/pull/7845> cases
<https://github.com/servo/servo/issues/7720> where:

   - The spec suggests something which if implemented correctly, would lead
   to inefficiencies
   - Major browsers do not follow that portion of the spec and usually have
   a faster/cleaner implementation which isn't spec-conformant. They usually
   don't match on how it's done, either.
   - Spec bugs on the issue haven't really gotten anywhere

We have three choices here, we can wait indefinitely until the spec gets
fixed, we can implement the spec as is (which require major changes and
affect perf or complexity), or we can hope that nobody relies on this
behaviour (given that it's not followed by major browsers) and implement it
as logically as possible, keeping in line with other browsers (and leaving
a bug open about the spec issue).

Thoughts?
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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

[Manish Goregaokar]

CONTRIBUTING sgtm

-Manish Goregaokar

On Thu, Oct 22, 2015 at 4:51 PM, Paul Rouget <p...@mozilla.com> wrote:

> Maybe I could merge it into CONTRIBUTING.md? Or README.md?
> What would you recommend?
>
> On Thu, Oct 22, 2015 at 12:54 PM, Josh Matthews <j...@joshmatthews.net>
> wrote:
> > I'd like to move it into the repo.
> >
> > On 2015-10-22 1:02 AM, Tetsuharu OHZEKI wrote:
> >>
> >> Make sense!
> >>
> >> I think wiki would be nice.
> >>
> >> 2015-10-22 13:59 GMT+09:00 Paul Rouget <p...@mozilla.com>:
> >>>
> >>> You probably saw this guide I put together:
> >>> https://gist.github.com/paulrouget/2f00941e6e82aeecad23
> >>>
> >>> I'd like to move it to Servo's repository or to Servo's wiki.
> >>>
> >>> Does it make sense?
> >>>
> >>> I should probably rename it ("Hacking Servo: how to start") and remove
> >>> the "me" and "I" references.
> >>>
> >>> Should it go to the Wiki or directly inside the repo?
> >>>
> >>> I will need a technical review and an english review.
> >>> ___
> >>> dev-servo mailing list
> >>> dev-servo@lists.mozilla.org
> >>> https://lists.mozilla.org/listinfo/dev-servo
> >>
> >>
> >>
> >>
> >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] (no subject)

[Manish Goregaokar]

Servo uses a different version of euclid, so you're having a clash with
that. I might update Servo to the newer euclid sometime.

Rebase your changes on top of
https://github.com/servo/rust-layers/commit/5af8c6bb9801e4f8d337c6a74a0bb2641ab48e0e
and use Servo's rustc (./mach build, ./mach cargo, ./mach rustc) instead.


-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] WPT Tests

[Manish Goregaokar]

They should all eventually pass.

Subtests which are supposed to fail will use assert_not_equals and stuff,
however.

We do have one test, infrastructure/failing-test.html (./mach
test-wpt-failure), which is supposed to fail all the time. This is just to
ensure that WPT failures are caught by the CI (there was an incident when
this stopped working, IIRC). It's not an "actual" web platform test.


-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] (no subject)

[Manish Goregaokar]

Delete your Cargo.lock

-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] (no subject)

[Manish Goregaokar]

I'll get around to updating all of the deps to work with it later.

@Divya try a fresh checkout of rust-layers. I tweaked the crates so that
they don't need plugin support when being built standalone (since the
plugins are only needed for Servo integration to work)

-Manish Goregaokar

On Sun, Oct 18, 2015 at 9:21 AM, Erick Tryzelaar <erick.tryzel...@gmail.com>
wrote:

> Hello all,
>
> Just wanted to give you all a heads up that aster, quasi, and serde have
> all been updated.
>
> On Saturday, October 17, 2015, Simon Sapin <simon.sa...@exyr.org> wrote:
>
>> On 17/10/15 23:00, Manish Goregaokar wrote:
>>
>>> This is a known issue. aster needs to be updated to work with latest
>>> Rust.
>>>
>>> You can use Servo's Rust snapshot (here
>>> <
>>> http://servo-rust.s3.amazonaws.com/168a23ebe1729386138fa71643382fdd64fac205/rust-docs-1.5.0-dev-x86_64-unknown-linux-gnu.tar.gz
>>> >)
>>> in the meantime.
>>>
>>
>> If you also have a clone of the Servo repository, you can use its Rust
>> snapshot (which is downloaded automatically) by using e.g. `../servo/mach
>> cargo` instead of `cargo`.
>>
>> --
>> Simon Sapin
>> ___
>> dev-servo mailing list
>> dev-servo@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-servo
>>
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] (no subject)

[Manish Goregaokar]

This is a known issue. aster needs to be updated to work with latest Rust.

You can use Servo's Rust snapshot (here
<http://servo-rust.s3.amazonaws.com/168a23ebe1729386138fa71643382fdd64fac205/rust-docs-1.5.0-dev-x86_64-unknown-linux-gnu.tar.gz>)
in the meantime. multirust <https://github.com/brson/multirust> is a way of
maintaining multiple Rust installs in parallel, if you don't want to
uninstall your nightly.

I'll let you know when stuff is working again.

-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Turning on autoloader rebasing and/or autosquashing

[Manish Goregaokar]

Barosl just verified in chat that it makes an empty commit with the merge
information even when rebasing.

I'm now pretty ambivalent towards this. I don't mind linear histories, but
... I can handle graphy ones too.

-Manish Goregaokar

On Fri, Oct 16, 2015 at 2:08 AM, Manish Goregaokar <manishsm...@gmail.com>
wrote:

> I like having a linear history, but I still want the merge commit (you can
> have fast forward merge commits which have a single parent) with the PR and
> reviewer info. We should check that we still get that.
>
> I've not actually had trouble with nonlinear history -- traversal is easy
> and that's mostly what I've had to do.
>
> I've found the merge commit very important when trawling through rustc
> history, though.
>
> > Makes it harder to distinguish which commits go together, everything is
> linear so there are no "commits groups" anymore.
>
> Note that commit parents still work. `git log --topo-order` iirc does
> bunching of commits by parent chains (verses `git log --date-order`, which
> I *think* is the default).
>
>
>
> -Manish Goregaokar
>
> On Thu, Oct 15, 2015 at 7:17 PM, Anthony Ramine <n.ox...@gmail.com> wrote:
>
>> Le 15 oct. 2015 à 14:42, Lars Bergstrom <larsb...@mozilla.com> a écrit :
>>
>> > - Automatic rebasing
>> >
>> > Right now, our commit log history is somewhat mumbly-jumbly. The
>> autolander adds a commit for the pull request detailing who reviewed it,
>> etc., but the commit itself sits in the history wherever `master` was on
>> the commiter’s local machine when they did the work. This makes looking at
>> a given commit and figuring which PR it landed in require either some extra
>> tooling or git-fu that most users don’t have.
>>
>> I'm against this for the following reasons:
>>
>> - Makes it harder to distinguish which commits go together, everything is
>> linear so there are no "commits groups" anymore.
>>
>> - Makes it harder to bisect, we can't distinguish branch tips easily
>> anymore, so we can't skip internal commits easily when bisecting. Tests
>> aren't run on commits that were not branch tips, so bisecting could fail
>> for whatever reason at every step.
>>
>> - Makes it harder to see which local branches were merged through git
>> branch --merged (and similar commands) because all commits are now
>> cherry-picked by Homu.
>>
>> In general, I don't even buy the argument that "merges make the log
>> unreadable".
>>
>> ___
>> dev-servo mailing list
>> dev-servo@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-servo
>>
>
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Travis, Rust Nightlies Aster

[Manish Goregaokar]

That sounds doable. I'm open to helping maintain aster's nightlyness.

-Manish Goregaokar

On Thu, Aug 20, 2015 at 9:47 PM, Simon Sapin simon.sa...@exyr.org wrote:

 On 20/08/15 17:50, Ms2ger wrote:

 Hi all,

 Recently, homu has regularly rejected PRs to rust-layers because of a
 mismatch between the latest Rust nightly (which Travis uses by
 default), and Aster (which it depends on through euclid and
 serde_macros). This has been solved by locking the Rust nightly to a
 version that works with the latest version of Aster (at that point).
 However, when Aster is updated for the breaking changes in Rust, the
 build breaks again.

 Does anyone have ideas on how to avoid this issue in the future?


 If https://nightli.es/ or something like it is set up on aster and serde
 to notify of breaking changes in Rust Nightly and they are kept up-to-date
 then the problem is solved, isn’t it?

 Erickt has offered to give push access to some of us to help make this
 happen. I don’t mind doing it if nobody else wants to.

 --
 Simon Sapin

 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Allowing occasional rollups?

[Manish Goregaokar]

What's our stance on rollups? I know they mess up history, but should it be
okay to do them when the queue is backed up?

At the moment our build rate and PR rates are roughly equal -- fine for
most situations, but if the queue gets backed up it stays that way.

IMO having an occasionally less linear history is okay, especially when
most of the PRs being rolled up are minor ones.

Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] mac3

[Manish Goregaokar]

I think we should be removing mac3 builds as well.

I'll repeat what I proposed in IRC: We can instead have a nightly set of
builds, for stuff like this which would be too much to run every build.
This can include testing release builds, mac3, and future valgrind/android
tests. If something breaks, we can bisect if necessary.

-Manish Goregaokar

On Fri, Aug 7, 2015 at 3:10 PM, Ms2ger ms2...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi all,

 The last mac3 run (http://build.servo.org/builders/mac3/builds/829)
 took 1 hrs, 13 mins, 57 secs, of which it spent 45 minutes compiling.
 As long as we have test-css running on linux (where css and wpt
 together don't make to 30 minutes), does it make sense to have this
 builder nearly double our turnaround time?

 Ms2ger
 -BEGIN PGP SIGNATURE-

 iQEcBAEBAgAGBQJVxH0KAAoJEOXgvIL+s8n2d2wH/RsgXBnAaZA1W4Jw6bTp0kqL
 pf0cl1Sjc56GK7vSd1C3BxnPqXFWuGJryuTJd7PuPElFfWiGBPlqp+ZRrsujVA23
 zQvKjR8SurGev3Q1tdNClVAiJo+mtLlVzHx6Vptk1SFzhl232MYWci+jMspTq8p6
 PNONLJ9B83SIRMAV5M9kvAQZKnw1yqthAEHd3OHPUKSyRxO5AX9kcPeKyLNvN+qK
 Te13YXa9TeWB/8hXo//t0yNs5YV72mJ8exaIEiSVA2zkvQUZArOO5YEj7NfkT3BK
 ugXNdyQLs/iQF8uiaaaqYmBThuiH6HJt09w8npvOYVE9hqvuuB0ir2SpLMS7NR4=
 =SALA
 -END PGP SIGNATURE-
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] (Not) using wildcard version when declaring dependencies

[Manish Goregaokar]

Yes, I was talking about Crates crates too :)

My plan is to upgrade Rust often now that it's pretty stable, which
automatically keeps our libraries
 up to date too. But if we don't want to do that I guess pinning to semver
is okay.

-Manish Goregaokar

On Tue, Jun 16, 2015 at 2:52 AM, Simon Sapin simon.sa...@exyr.org wrote:

 On 15/06/15 23:03, Manish Goregaokar wrote:

  From what I've seen, semver isn't being used to it's full extent yet,
 especially with libraries
 working on nightly. Locking to particular versions tends to make rustups
 harder (and leads to
 multiple versions of the same package being used). The breaking changes
 in libraries seem less
 common and breaking than breaking changes in, say, plugins, so IMO we
 should stick to Cargo.lock for
 pinning and use `mach update-cargo -a` during rust upgrades.


 My previous message was about breaking changes in a library on crates.io,
 not in the standard library.

 Many crates follow Rust master. In the past, that meant that that any
 given version a library only worked with a narrow range of Rust
 version/commits. As a consequence, we mostly only updated Servo’s
 dependencies while doing Rust upgrades at the same time.

 But with 1.0 out this is less and less the case: many libraries can be
 updated without updating Rust, and a smaller number of libraries need to be
 updated when we update Rust. In time, there’ll be no reason to do both at
 the same time.

 --
 Simon Sapin

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo