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

91–100 of 246 posts

Re: Servo Nightly Builds Available

#91

Post by tinco »

Manishearth wrote: post #79
IanCal wrote: post #77

Earlier quoted context omitted.

No language can fix missing functionality, that seems pretty clear. Your compiler doesn't know what you're trying to do, so you can't prevent all bugs. That leaves crashes, and ... well it may also depend on what you mean by a crash. The UI becomes unresponsive? Might have absolutely nothing to do with memory issues or even code written in rust. Maybe your rust code is fine but you're trying to open and write to the…

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 to extract the image. This throws a panic and exits the application if the image is not there.

This is just a hypothetical example, I bet image loading is one of the things Servo does fine. Just to give you an idea of when Rust might panic.

Re: Servo Nightly Builds Available

#92

Post by gsnedders »

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.

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. Pretty much the only way to be web compatible then was to start with something already mostly web compatible (consider the fact that Apple's first two or three years of work on WebKit were essentially spent pretty much just fixing web compat bugs!).

Re: Servo Nightly Builds Available

#93

Post by [deleted] »

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…

[deleted]

Re: Servo Nightly Builds Available

#94

Post by reddotX »

pcwalton wrote: post #2

Happy to answer questions (when I wake up; getting this ready has been a lot of work, needless to say) :) It goes without saying, but as this is the very first nightly (not by any means a full-fledged release), expect severe bugs, crashes, and missing functionality. Many of your favorite sites will be broken. Don't expect to use this as your everyday browser. We'd love feedback on what issues folks hit the most, so w…

any change of a snap or flatpak for linux?

Re: Servo Nightly Builds Available

#96

Post by Morgawr »

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…

I do things like this all the time in Haskell when quickly prototyping new code and then swiftly kick myself because of it. Safe languages are nice, but there's really no way to prevent a developer from saying "Yeah fuck it, this case will never happen anyway" and then calling a fromJust on a Maybe monad which turns out was a Nothing and throws a runtime exception.

Re: Servo Nightly Builds Available

#97

Post by Manishearth »

gsnedders wrote: post #92
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. 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…

Well, we still do lots of reverse-engineering, because the specs are often wrong :)

Re: Servo Nightly Builds Available

#98

Post by Manishearth »

kibwen wrote: post #86
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?

browser.html is just the browser chrome (er, not to be confused with the browser Chrome), it's an independent Mozilla project to create a frontend entirely in web technologies, which, since these are all standardized, should theoretically work with any browser engine, not just Servo. As for Firefox, later on this year we should see the integration of Servo's style engine ("Stylo") into Gecko, and going forward we sho…

> theoretically work with any browser engine, not just Servo.

Well, it depends on some privileged APIs, of course. But we've tried to keep that API surface minimal.

Re: Servo Nightly Builds Available

#99

Post by k_bx »

Manishearth wrote: post #7
mjs wrote: post #4

The OS X binary isn't signed, and the download URL is HTTP. Is there a version available on a more secure distribution channel anywhere?

We're switching the download link over to HTTPS. Is there a reason the OSX binary needs to be signed? We don't do anything special. Edit: HTTPS up: https://servo-builds.s3.amazonaws.com/index.html (This comment written in Servo :P )

If you install Servo as of now and try to launch it you'll get a pop-up saying it's not signed (and it won't launch). So, to launch, you need to go to Applications, right-click on servo and choose "launch". Then it'll let you say "yes, run this unsafe executable". Might reduce number of users who can figure this out.

Re: Servo Nightly Builds Available

#100

Post by Manishearth »

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…

Heh.

Earlier in this thread, someone did indeed find a bug in our image loading: https://news.ycombinator.com/item?id=12014108

We were basically panicking when an invalid URL was given to us. There was a comment there noting this -- which means that this was probably written when it wasn't so important to handle all the cases, and more important to handle some cases so that we can test out various ideas. We're still sort of in that stage, and you may see other comments like this throughout the code :)

Post reply on HN