Live data from Hacker News

Servo Nightly Builds Available

blog.servo.org

191–200 of 246 posts

Re: Servo Nightly Builds Available

#191

Earlier quoted context omitted.

Servo is trying to be fast on mobile; there even has been some research work into the power efficiency of servo on mobile. Admittedly, android-specific efforts have slowed down in the past few months, but I believe it is still a goal :)

Given the fate of FirefoxOS and iOS' restrictions on browsers, is there any other mobile platform where Servo could actually be used?

Windows perhaps?

I mean, Servo-as-a-product isn't even planned yet, and may never be, so by the time that question is relevant the ios rules may have changed, too :)

Re: Servo Nightly Builds Available

#192

Earlier quoted context omitted.

Servo is trying to be fast on mobile; there even has been some research work into the power efficiency of servo on mobile. Admittedly, android-specific efforts have slowed down in the past few months, but I believe it is still a goal :)

Given the fate of FirefoxOS and iOS' restrictions on browsers, is there any other mobile platform where Servo could actually be used?

[deleted]

Re: Servo Nightly Builds Available

#193
post #129

Earlier quoted context omitted.

It's also still possible to panic.

Panic's implementation uses unsafe code, IIRC. But stuff like stack overflow can happen even without explicit unsafe code, I think.

Well ultimately any useful program will use a library that uses unsafe. All I/O is unsafe at the bare metal so while you can safely wrap it it still is unsafe internallly.

When talking about the usage of unsafe code in rust, we generally ignore encapsulated unsafe code in libstd since it has the same safety guarantees as tgr compiler itself. all unsafe code encapsulated in a safe API has these guarantees, but you trust libstd more :)

Re: Servo Nightly Builds Available

#194
post #123

Earlier quoted context omitted.

Sounds like it's based on Trident to me

Sounds like it's so rewritten compared to Trident, it's not even alike anymore.

This comment is a perfect example why arguing over proprietary software is mostly conjecture: nobody can look at the code and see what's different.

Re: Servo Nightly Builds Available

#195

Earlier quoted context omitted.

At the same time, depending on how the rewrite was carried out, it may be nothing like a completely new project. Rewriting function by function is different than rewriting component by component, which is also different than rewriting from scratch. Rewriting function by function will give you largely the same program using largely the same algorithms, but possibly with more or less bugs, or cleaned up code. Rewriting…

It's why I'm focusing on behavioral aspect: what does the software do ? A browser fork that behaves very differently from prior one to point you have to change existing code to get same effect is essentially a new app at behavioral level. However, it might have same name and lots of same code inside. At that level, it's old code in an old app. We largely define our components by their interfaces and behavior. So that…

Sure, but if it behaves significantly differently, then I think that precludes it from being a function by function rewrite. At the same time, a component by component rewrite can be a complete rewrite (but it depends a bit more on the details, I think). If the mainly user visible portions are rewritten, but much of the utility code and other components are not, it may appear behaviorally different, but but be largely the same code base. It's much harder to know, looking in from the outside.

For a simplistic example, say someone provides a "rewrite" of grep. Maybe the options are all different looking and sounding, so it may appear to be significantly different. But if the core of the matching algorithm and it's capabilities are largely unchanged, is it a that much of a rewrite? To the outside user it may superficially appear so, but to someone comparing the source from before and after, there may be an entirely different opinion, and even that may change if you come from a context of focusing on a particular aspect.

As applied to Trident/Edge, we may have a case where the person speaking was involved in a project to rewrite one major component of the browser, and so is speaking in that context. Maybe that component is responsible for about 60% of the code and functionality, but it still relies on a quite a bit of largely unchanged additional libraries. It's very subjective as to whether you think that qualifies as a rewrite of the project, and depends quite a bit on what was not rewritten, and what you think of that code.

Re: Servo Nightly Builds Available

#196

Earlier quoted context omitted.

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.

unimplemented!() exists

Yeah, I use that, but it obviously requires more work than a simple unwrap or expect, so the temptation is to just use those and think you'll remember to flesh it out later :-)

Re: Servo Nightly Builds Available

#197

Earlier quoted context omitted.

Servo is trying to be fast on mobile; there even has been some research work into the power efficiency of servo on mobile. Admittedly, android-specific efforts have slowed down in the past few months, but I believe it is still a goal :)

Given the fate of FirefoxOS and iOS' restrictions on browsers, is there any other mobile platform where Servo could actually be used?

[deleted]

Re: Servo Nightly Builds Available

#198

Just opened up the MacOS build. It is pretty impressive! But the autocomplete is just awful. Typing in " http://localhost:3000" at normal speed produced " http:///localhost:300000" . Especially while it's in such a primitive developer-oriented state it would be much more useful to disable that silly autocomplete. Edit: Additionally, it doesn't yet support native keybindings like Command left-right or Alt left-right.

There are several issues at play here, native keybindings for input fields has not being fully implemented in servo yet.

As of auto complete, few people have reported issues. In our testing we did not run into this issue. Right now we have an issue and a reproducible test case to tackle this issue: https://github.com/browserhtml/browserhtml/issues/1157

Feel flee to report more browser.html issues here: https://github.com/browserhtml/browserhtml

We'll do our best to get them resolved promptly.

Re: Servo Nightly Builds Available

#199

Earlier quoted context omitted.

Why not to try Linux? It's free. It's made by developers and for developers. Try Fedora Linux.

Thanks for the suggestion but I'm already using Linux where it makes sense for me (my website, Gitlab instance, etc). I asked about the Windows version since that's what I'm using most of the time being a .Net dev.

I can sell you few additional copies of Linux, so you will be able to run Servo right now.

Re: Servo Nightly Builds Available

#200
post #111

not working at all ./runservo (as per instructions) thread 'main' panicked at 'Failed to create window.: OsError("GL context creation failed")', ../src/libcore/result.rs:785 note: Run with `RUST_BACKTRACE=1` for a backtrace. ./servo welcome to servo, than it changes to a white window Debian 8

We've gotten several reports of this, and this is exactly why we wanted to get some wider testing. Hopefully we'll figure this out and get a patch in soon. In the meantime, the suggested workaround will get you going I think at the expense of some rendering performance.

Does this mean that Webrender should also work with OpenGL < 3.0? That would be nice.
Post reply on HN