Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Servo Nightly Builds Available

blog.servo.org

Post reply on HN
Print view View original

131–140 of 246 posts

Re: Servo Nightly Builds Available

#131

Post by gsnedders »

larsberg wrote: post #121
gsnedders wrote: post #92

Earlier quoted context omitted.

> By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible. It's a two sided coin: HTML now defines a lot of the basic web platform parts in enough detail that you can just implement the spec and have a web browser that works , whereas in the 90s (and most of the 00s) browsers spent huge amounts of resources on reverse-engineering each other. Pre…

> you can just implement the spec and have a web browser that works Don't forget the amazing work being done at http://testthewebforward.org/ with the Web Platform Tests and your own work on the CSSWG tests! Beyond the specs, having a cross-browser set of tests that have especially good coverage on newer specs has been a huge leg-up for Servo! It not only helps us ensure interop for those features that are tested, bu…

To be fair, having tests somewhat relies on having a spec. OK, so in theory we could've had a cross-browser set of tests with some requirement along the lines of "this web page relies on this behaviour", but ultimately you'd still end up with contradictory tests. :)

I wonder if it's worthwhile to spend some time working on the 2.1 testsuite to try and improve coverage at some point. Probably? Unlikely to find so many bugs in mature implementations, hence why so much effort has been spent elsewhere.

Re: Servo Nightly Builds Available

#132

Post by frewsxcv »

WasimBhai wrote: post #113
Manishearth wrote: post #80

Earlier quoted context omitted.

Yeah; we've mostly ignored the network stack. So there's some extra copying in the IPC, and no speculative parsing, which can slow things down, among other factors. Can be fixed, but priorities :)

I will absolutely love to contribute toward the network stack. Can you provide me any pointers?

In case you're looking for a place to jump in:

The thread that handles all the resources (http://, chrome://, file://, etc):

https://github.com/servo/servo/blob/master/components/net/re...

And here's the file that handles HTTP requests:

https://github.com/servo/servo/blob/master/components/net/ht...

Re: Servo Nightly Builds Available

#133

Post by ZoF »

Sylos wrote: post #37
anirudhan wrote: post #9

Congratulations on the release. Running ./servo gives me this error. "./servo: error while loading shared libraries: libEGL.so.1: cannot open shared object file: No such file or directory" I guess it should be an easy fix. But if there are instructions to copy/paste that would really help. If someone has an answer, it would be great if you can please post it here. Edit 1: I think the problem is because I am trying to…

I get the same error, except that the library missing for me is "libssl.so.1.0.0". That is on Fedora 23, and what's really strange to me, is that I compiled Servo about a week ago myself and that build works.

Ha, I have a VM with Fedora 23 and one on Debian 8, I got both of these errors before coming to the comments to check

Re: Servo Nightly Builds Available

#134

Post by AlisdairO »

tinco wrote: post #91
Manishearth wrote: post #79

Earlier quoted context omitted.

By crashes we mean panics. We still panic in various places in the code when something goes wrong.

To clarify, a panic in rust is the result of an unhandled exception. Usually this is due to laziness rather than a real bug. For example Servo might encounter an IMG tag, start to load the body. The result might be stored in an option because something could have gone wrong during loading (peer disconnected etc.) but the developer didn't feel like implementing robust image handling that day and instead called .expect…

It would be quite nice if there was a synonym for expect (say unimplemented_expect) that meant 'I haven't bothered to implement the proper error handling yet' rather than 'error handling shouldn't be required'. That would really enhance auditability of in-progress code.

Re: Servo Nightly Builds Available

#135

Post by Eridrus »

Manishearth wrote: post #83
epidemian wrote: post #78

Earlier quoted context omitted.

Kudos on this milestone! A very general question: what's the high-level plan for Servo regarding Firefox? I see a lot of requests/issues dealing with stuff that doesn't seem related to a layout engine. Is the plan to have browser.html as a temporary incubator for Servo and eventually migrate it to replace FF's layout engine, or is it to "grow" an entire new browser around this new engine?

https://wiki.mozilla.org/Oxidation There are efforts to make various components work in Firefox. The largest effort is "Stylo", which replaces Firefox's selector matching with ours. I'm not sure what the future is on Firefox using Webrender or our layout; though I suspect it depends on how well stylo works. The plan seems to be to let Servo continue to evolve as a testbed for new ideas (like webrender), and share com…

I feel like mobile (Android, really) needs a fast, secure and extensible browser, I hope that Servo can help Firefox achieve those first two goals so that it could be my browser of choice

Re: Servo Nightly Builds Available

#136

Post by RubyPinch »

pilif wrote: post #81

It's amazing to see actual effort taking place to build a new browser engine from scratch. I would say that since the late 90ies, there hasn't been a single new engine being made. Everything we have now is a development based on KHTML, Gecko, Presto or Trident. By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible. The existing engines have it…

There are some smaller groups that are working on their own engines (slowly but surely)

https://gngr.info/ comes to mind

Re: Servo Nightly Builds Available

#137

Post by tedmiston »

AlisdairO wrote: post #134
tinco wrote: post #91

Earlier quoted context omitted.

To clarify, a panic in rust is the result of an unhandled exception. Usually this is due to laziness rather than a real bug. For example Servo might encounter an IMG tag, start to load the body. The result might be stored in an option because something could have gone wrong during loading (peer disconnected etc.) but the developer didn't feel like implementing robust image handling that day and instead called .expect…

It would be quite nice if there was a synonym for expect (say unimplemented_expect) that meant 'I haven't bothered to implement the proper error handling yet' rather than 'error handling shouldn't be required'. That would really enhance auditability of in-progress code.

Python has a nice built-in exception for this: NotImplementedError. It's intended usage was related to abstract base classes, but it's taken on this secondary use case recently.

Re: Servo Nightly Builds Available

#139

Post by metajack »

pilif wrote: post #81

It's amazing to see actual effort taking place to build a new browser engine from scratch. I would say that since the late 90ies, there hasn't been a single new engine being made. Everything we have now is a development based on KHTML, Gecko, Presto or Trident. By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible. The existing engines have it…

> By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible.

One important mitigating factor is that newer standards often generalize older ones. For example, originally all the list elements had special case handling (and still might in other engines), but now it's possible to do all that with the user agent style sheet with new additions to CSS that generalized these things.

It saves an enormous amount of work to implement the web at a particular point in time as opposed to starting at the beginning and keeping up with the changes until that same point in time. Not only that, but all the failed branches that were already explored mean that a new engine avoids quite a bit of technical debt.

It's still quite hard. Here's a nice example of a layout bug on HN we thought would be simple to fix for the release, but turned ugly fast: https://github.com/servo/servo/issues/11821

Re: Servo Nightly Builds Available

#140

Post by jgraham »

gsnedders wrote: post #131
larsberg wrote: post #121

Earlier quoted context omitted.

> you can just implement the spec and have a web browser that works Don't forget the amazing work being done at http://testthewebforward.org/ with the Web Platform Tests and your own work on the CSSWG tests! Beyond the specs, having a cross-browser set of tests that have especially good coverage on newer specs has been a huge leg-up for Servo! It not only helps us ensure interop for those features that are tested, bu…

To be fair, having tests somewhat relies on having a spec. OK, so in theory we could've had a cross-browser set of tests with some requirement along the lines of "this web page relies on this behaviour", but ultimately you'd still end up with contradictory tests. :) I wonder if it's worthwhile to spend some time working on the 2.1 testsuite to try and improve coverage at some point. Probably? Unlikely to find so many…

For too long it was considered OK to have a spec with either no tests, or tests that focused on the wrong thing ("is it possible to implement this spec" vs "do implementations behave in compatible ways"). It is still considered too OK for browser vendors to write their own tests for a feature and not share them with the rest of the community. However, pressure from other platforms is changing attitudes here as it becomes increasingly apparent that without a stronger degree of interoperability, developers will vote with their feet and target platforms with fewer bugs to trip over.

Post reply on HN