- Debugger: Getting mixed signals
- 'Packaging Infrastructure' Contract Weekly Report #4
- Haiku monthly activity report - 06/2015
- 'Packaging Infrastructure' Contract Weekly Report #3
- 'Packaging Infrastructure' Contract Weekly Report #2
- GCI 2014 winners trip report (mentor side)
- TeX Live and LyX; Changes to the boot code
- 'Packaging Infrastructure' Contract Weekly Report #1
- Beginning of 'Packaging Infrastructure' Contract
- Haiku monthly activity report - 05/2015
WebKit weekly report #3
Hello again, it's time for another report !
I made pretty good progress this week.
The issues I had last week with POST data are fixed. I had removed a non-working piece of code but replaced it with another that was broken in a different way. The problem was the way POST data was added to the http request. Fixing this properly required some changes to the Services Kit API. I removed some classes to make things simpler and introduced a stub for the central BUrlProtocolHandler class, which takes an Url as a parameter and builds a request for it using the appropriate protocol. The BUrlProtocolHttp class was renamed to BHttpRequest, and the API was tweaked to use multiple methods to configure it, instead of a single SetOption(option_name, value) method. This allows seting options with multiple parameters, and is more type-safe.
I started writing some documentation in the Haiku book, for both the Service Kit and the new Network Kit. BeOS already had a Network Kit, and the same API is available in Haiku, but we also have a newer, more flexible and more powerful API. Unfortunately it is undocumented (and unfinished), so there is not a lot of users for it. I hope the documentation will help change that. I'm far from done, however, with just 3 classes available in the Haiku Book (http://api.haiku-os.org).
I finally uploaded WebKit dependencies to the package manager. So, with a recent nightly build, it will be even easier to get started with building WebKit. As I had them around, I also added packages for vim and Caya.
With all this set, I can log in to gmail/google mail again. This means things are working rather well. I even got the web chat to show my online contacts, something that isn't working in the current versions of Web+. I'm also able to log into github, and I found another set of non-working things there (most of them were already broken in older Web+).
I'm now trying to run the tests from http://testsuites.opera.com/cookies. These will help me find and fix some more bugs with cookies management. I already found that cookies set to expire before 1970 would stay forever, because of a bug in the BDateTime class from Support Kit. There are some other issues detected by this test, and it does not make much requests, which makes it easier to debug than an actual production website.
No preview build this week yet, but I'll try to update the WebKit recipe at haikuports so I can cook a package for you to try.
Oh, I forgot to mention our patches to CMake were upstreamed. Version 2.8.13 will have all of them and should build out of the box on Haiku. Also, augiedoggie provided me with a most package, so I can cross that out the TODO list (which is here: https://gist.github.com/pulkomandy/6685664#file-bnetapi-webkit-bugs-md)
- PulkoMandy's blog
- Login or register to post comments
Comments
Re: WebKit weekly report #3
Nice work :)
Re: WebKit weekly report #3
How about adding http://mozilla.github.io/shumway/ as a plugin?
Shumway is a javascript flash interpreter? Seems like a easy way to implement a dying technology ;)
Re: WebKit weekly report #3
We have no extension/plugin support yet. I have no idea what's the best flash interpreter out there now. Gnash ? Shumway ? are there others ?
Re: WebKit weekly report #3
it's a nice surprise to see already in that early stage good progress.
If you have time, would you like to take a look at v8 javascript engine which was ported i guess last year by hamish?
The port of hamish is here: https://github.com/hamishm/v8
as far as i remember, all tests passed, with the exception of a single one (perhaps in the meantime also this one passing).
What is missing is a recipe / package so that we can install it with the packagemanager.
Re: WebKit weekly report #3
It's not as easy as you make it sound. WebKit currently links the Js engine statically. So the entire WebKit has to be recompiled against V8. Moreover, after the Blink fork from Google, recent versions of WebKit removed the v8 support.
So, if we want a browser using V8, we would have to switch to Blink, and adopt the "Chrome way" of doing things, with their multi-process rendering system and so on.
On the other hand, the WebKit code is more universal, because of the many different ports of it (on Tizen/EFL, on blackBerry, on Windows CE, and iOS, Mac OS X, Qt and GTK and wxWidgets - I think I forgot some again).
Anyway, I don't think JavaScript performance is our main concern with the browserr slowness. I think we should first get the network backend optimized as much as we can. There are still a lot of things that are done in suboptimal ways in Service Kit, for example, all network transfers are done in small 1Kbyte chunks, which is smaller than an ethernet packet, so we waste a lot of time in calling the write() or read() syscall. HTTP 1.1 allows to use the same connection for multiple HTTP requests, but we don't do that. So each request has to do its own DNS resolution, TCP handshake, opening a new socket on a new port number, and allocating some C++ objects. This adds up quite fast, sometimes more than the actual networn transfer time ! And I didn't even mention the memory leaks: there is no documentation of the Service Kit, so it is not clear which methods take ownership of pointers passed as parameters, and which don't (and make a copy of the data, for example). For some of the methods, this was even changed in different Service Kit versions, or, even worse, it depends how you call them, what you did with the object in the past, or what you will do with it in the future. I plan to review all of this.
Also, I wanted to point out that we're already 2 weeks into october, and there are only 3 left. I don't know if Haiku will be able to keep the contract running in november yet. So time is running quite fast, actually. I'm trying to get this working well enough for a merge, so people start using it and we can find all the remaining bugs. But we want basic functionality to be there and work at least as well as before.
Re: WebKit weekly report #3
related to memory leaks, and ownership:
Perhpas instead of documenting the ownership, it is a better idea, to try to rewrite it in terms of c++11 where you can make use of the different smart pointers.
Re: WebKit weekly report #3
Unfortunately we have to stay compatible with gcc2 for the Service Kit, so C++11 is not an option. However, we have BReferenceable which is basically the same and could be used in some places. I don't think it's needed everywhere, for example BView->AddChild takes ownership of the child and that never was a problem. There are some other things I may change like using the Observer/Listener pattern already planned in the BeAPI (StartWatching, StopWatching and friends) instead of a custom one dedicated to the Service Kit.
Re: WebKit weekly report #3
does the services kit really need to be gcc2 compatible? Anyway webpositive uses gcc4, and newer applications are also usually compiled with gcc4.
Re: WebKit weekly report #3
Yes. It's part of the Haiku API like the Locale Kit and the Layout Kit, and remember that R2 will support running apps built for R1-gcc2, but not apps for R1-gcc4. This is the only officially supported ABI on x86 (other platforms, including x86_64, will of course use gcc4).
Moreover, I don't think it's a good fit to the Be API to use C++11 smart pointer types, it would feel alien to the rest of the API. This is something that can be done in R2 (or maybe we will use C++14 by then), but not in R1.
I still develop and distribute many applications using the official gcc2 API. This includes fRiSS, and I contributed to others such as Caya, to add gcc2 support (this was less than 1 hour of work). Using and supporting gcc2 is not as big a problem as most people think, unless you do very advanced C++. WebKit is such one case.
Of course, with the move to C++11 we're going to require gcc4 for more and more 3rd party stuff. But for the core system I think we should still support gcc2.
Re: WebKit weekly report #3
Related to keeping the project running in November, How much is needed per month to keep you on fixing/documenting the services kit in addition to making the webkit port work?
V8 support would be nice, however it's not 100% necessary... there are a lot of interpreters that can handle node.js which is a very complex framework (or library depending on how you use it).
I've dumped a small donation ($500) into the kitty, and hope to do another by the end of the week. Not sure how these funds are distributed internally with haiku-inc tho...
Great progress, and thanks for helping out on the services kit... I'm way the hell too busy to get anything meaningful done this year or next. 96 hour weeks leave no spare time for me to contribute 87(
Re: WebKit weekly report #3
Ah, nice donation :)
We are pondering the contract continuations based on donation estimates - so this will help us with our planning.
Re: WebKit weekly report #3
That's the goal 87)
Re: WebKit weekly report #3
The Haiku, Inc. website has more data about the donations and the way they are used.
http://haiku-inc.org/donations-analysis.php
http://haiku-inc.org/funded-infrastructure.html - Server hosting, domain names, SSL certificates, ...
http://haiku-inc.org/funded-development.html - Development contracts
http://haiku-inc.org/documents/haiku_inc-budget-2012.pdf - 2012 planned budget (I don't know if there is/will be a similar document for 2013 and onwards)
Re: WebKit weekly report #3
Dumped in another small donation, this one will be my final for this year (unless something freaking awesome happens to the economy at large)
This should take me into the $1000 range (I would love to do more... take that google!)
Re: WebKit weekly report #3
I was meaning, just to write the recipe that builds v8 from the github of hamish. Not to use it in webpositive. Just to have the v8 package, so that one can install it with the packagemanager.
I'm planning to use it in my documentviewer (I didn't work on it since a long time, and I think in the next month I will start again doing some improvements), which is missing "form filling", etc.. for pdf.
The problem is, haiku doesn't run on my laptop, and I don't really want to try compiling v8 (since it's huge) in a virtual machine (i think i even tried it once in vm, but i ran out of memory, i'm not sure anymore).
And yes, later at a later point... it could be also useful for somebody wanting to try to use v8 in webpositive.