Re: [dev-servo] RFC: bluetooth as optional feature
On 01/04/2018 07:25 AM, Fabrice Desre wrote: > On 12/27/2017 06:57 AM, Emilio Cobos Álvarez wrote: > >>> For what it's worth, I found the Bluetooth dependencies quite hard to >>> deal >>> with when I tried to get Servo to compile on (somewhat older) CentOS >>> VMs. >>> Maybe building without Bluetooth doesn't necessarily have to be a >>> supported >>> configuration, but could still be supported best-effort by interested >>> contributors? >> >> That's fair, but the way to do that IMO is stubbing the >> platform-specific bits. We used to have platforms where we didn't have a >> bluetooth back-end, and we used to mock them, see [1]. > > Does that mean that web pages see the api as exposed, but it doesn't > work? I guess the mock can "fail gracefully" and expect web sites to > process errors properly but in practice... Yes. You can additionally also disable the interface with a pref or something I guess, though. >> Doing it that way is way less intrusive (and adding an optional feature >> unconditionally opting into it is probably not much work). >> >> That's very different than what was proposed in this thread I think, >> which is compiling out all the DOM code in Servo related to >> WebBluetooth, which seems much more intrusive to me. > > That's true, but there are also reasons for giving more control on which > device apis are built as part of Servo: > - The embedder may want a minimal web renderer without increased api > surface. > - The embedder may want to limit on disk size and memory overhead. Well, the API surface is configurable already at runtime using prefs, isn't it? The code size argument is fair, but would need to be measured to be justified I guess. -- Emilio ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Old builds on CI machines take up increasing disk space
I just encountered a try build failure which contained: ar: libjs_static.a: No space left on device I logged into the build machine and checked, and there were 5mb left out of the 61gb disk. After checking that the machine was idle, I cleared out 34gb worth of old builds from the target/ directories of the various builder directories. What can we do to avoid repeating this exercise in the future? Cheers, Josh ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] RFC: bluetooth as optional feature
On 12/27/2017 06:57 AM, Emilio Cobos Álvarez wrote: For what it's worth, I found the Bluetooth dependencies quite hard to deal with when I tried to get Servo to compile on (somewhat older) CentOS VMs. Maybe building without Bluetooth doesn't necessarily have to be a supported configuration, but could still be supported best-effort by interested contributors? That's fair, but the way to do that IMO is stubbing the platform-specific bits. We used to have platforms where we didn't have a bluetooth back-end, and we used to mock them, see [1]. Does that mean that web pages see the api as exposed, but it doesn't work? I guess the mock can "fail gracefully" and expect web sites to process errors properly but in practice... Doing it that way is way less intrusive (and adding an optional feature unconditionally opting into it is probably not much work). That's very different than what was proposed in this thread I think, which is compiling out all the DOM code in Servo related to WebBluetooth, which seems much more intrusive to me. That's true, but there are also reasons for giving more control on which device apis are built as part of Servo: - The embedder may want a minimal web renderer without increased api surface. - The embedder may want to limit on disk size and memory overhead. Fabrice ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Infra FYI: Taskcluster status check, which you can ignore for now, coming to servo/servo repo
You will soon notice a "Taskcluster (pull_request)" status check showing up in your pull requests to the servo/servo repository on GitHub, alongside the TravisCI and Appveyor results. Taskcluster is Mozilla's solution to replacing BuildBot, so we're evaluating it as a way to add CI features such as reusing artifacts across build steps and improve integration with the main Mozilla build infrastructure. Right now, Homu is ignoring the results of the Taskcluster check. We are only running it so we can debug the infrastructure and identify when we've got it reliably reproducing the test results from our current infrastructure. As a developer, you can ignore the Taskcluster results until Lars, Aneesh, and I establish that they're performing as well as or better than the Buildbot infrastructure, at which point we'll send an update to this mailing list and add Taskcluster as a gated check in Homu. For more about Taskcluster and what we're doing with it, check out https://github.com/servo/servo/wiki/TaskCluster. Feel free to reach out to me by email or IRC if you have any questions about these changes! - edunham ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
