Re: [webkit-dev] Changes in QtWebKit development
Hi Benjamin, On Sep 13, 2013, at 7:22 PM, Benjamin Poulain wrote: > This is sad. I can understand very well, that you are not very happy about this. And I don't think anybody here took this decision lightly. > > When "modules" of Qt are put on "maintenance", it is basically a synonym to > "it's unmaintained, just let it die". I am very unexcited about having one of > those in the tree along the live development from everyone else. > It is unfair for all the ports who put real efforts in the WebKit opensource > project. Real efforts is not something that can be define that simple, i think. It depends a lot on available resources as well. However, I think we are doing exactly what you are asking for. With the pieces that we do not have enough people working on, we are getting out of the way, and will maintain it through our own gerrit. For the builds we have actively people working on, we remain working upstream. - Zeno -- Zeno Albisser Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: run-webkit-tests now generates pixel results in retry
As far as I am informed we (Qt) are not running tests on EWS, due to limited resources. Therefore you would still not be able to receive the -expected.png files before landing your patch. But just right afterwards with the first bot failing. May be we need to consider changing our Qt-EWS? - Zeno On Sun, Mar 24, 2013 at 9:02 AM, Ryosuke Niwa wrote: > On Sat, Mar 23, 2013 at 10:25 PM, Robert Hogan wrote: > >> > This will allow us to rebaseline BOTH test and image expected results >> PRIOR to landing patches. >> > >> > You're welcome. >> > >> >> Great stuff. Thanks for doing this! >> >> A question for the Qt/gtk/efl ports: do you plan to put some testers on >> the EWS queue? If not, I think you should shout if you do not want authors >> to add just the text part of new results and advise what they should do >> instead. >> > Qt, GTK+, and EFL builders on build.webkit.org also generate image > results on retries, meaning that as long as test unexpectedly fails, you > can grab new -expected.png off of those builders. > > Given that, I'm not sure why you're asking this. > > - R. Niwa > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen wrote: > > You also need IPC because the NetworkProcess serves the needs of the web > process. Could you describe why a network thread in the UI process fit your > needs bettter? Is it to support API's related to networking or does it have > other advantages? > > Yes, that was slightly ambiguous. Let me rephrase that. Currently the IPC for the NetworkProcess is setup by ChildProcess::initialize(). Since we would not need to create a whole new process in our case, we would just spin of a thread and create the appropriate IPC connections ourselves. That could be an implementation detail of our NetworkThread implementation. For prototyping i even reused the whole ChildProcess code with a few minor changes. But it would feel wrong to have instances of ChildProcess in something that is a thread of the same process. One of the main advantages of having networking in the UIProcess for our port is, that we could support some features such as Application URL Schemes without going through the WebKit2 API. This is a very Qt specific use case, that IMHO does not fit very nicely into the rest of the WebKit2 API. It is Qt specific because Qt makes heavy use of qrc files to embed content. And Application URL Schemes was the solution to allow for qrc content in a QQuickWebView. - Zeno ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] NetworkProcess / NetworkThread in the UIProcess
Hi, I have been looking into the NetworkProcess code that has recently been added to WebKit2. For Qt we are considering moving all the networking into a separate thread within the UIProcess. Do you guys think that the NetworkProcess code could be designed in a way to allow running in a separate thread of the UIProcess instead of in a separate process? We are convinced that this design would be a very good fit for our needs. Also in the light of the currently ongoing effort of cleaning up our Qt-bits and pieces in WebKit2. After a quick look it seems to me that this could be achieved with fairly minor modifications: * Instead of relying on RunLoop::main() within NetworkProcess, a different function would need to be introduced to retrieve a "networking RunLoop". This would allow to process networking related events in the network thread. Depending on the platform, this could of course return a pointer to the main-RunLoop, for the cases where networking is indeed executed in a separate process. * Splitting the NetworkProcess class in two pieces. The child process and IPC setup remaining in NetworkProcess, and the actual networking code in a separate class (e.g. called NetworkThread). Provided the IPC (between threads in our case) would be setup upfront this would allow running the code provided by NetworkThread in a separate thread. Would patches aiming such a direction generally be accepted? Thanks, - Zeno ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] distributed build for WebKit on Mac OS 10.8
Hi, On Mon, Jan 21, 2013 at 5:53 PM, Alexis Menard wrote: > On Mon, Jan 21, 2013 at 1:41 PM, Mihai Maerean wrote: > > How can the build of WebKit be distributed on all the Macs in the LAN to > > fully utilize the computing power? > > > > https://github.com/icecc/icecream > > I've been experimenting with icecream and distcc. Icecream is super powerful on Linux. Especially because it has a central scheduler that distributes the jobs according to available resources. But unfortunately I did not have any luck with it on Mac, due to the packaging of the compiler. Icecream actually ships the compiler in an archive to all the clients participating in a compile job. I was more successful using distcc from: http://www.opensource.apple.com/source/distcc/ This one seemed to work fairly well. The only problem I had was that Qt is not actually using xcodebuild. Therefore I could not make use of any bonjour service to update my hosts list and had to do that manually. But if you know the machines in your network and can rely on them being available, keeping a static list might be an option. - Zeno > I know for fact that it works fine on linux but it claims to to work > on Mac OS too and according to git log it seems that clang support is > possible. > > Let me know if it works for you, I haven't had time to try yet. > > > > > > > Mihai > > > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo/webkit-dev > > > > -- > Software Engineer @ > Intel Open Source Technology Center > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
On Fri, Mar 23, 2012 at 11:14 AM, John Yani wrote: > > This even affects 64bit systems with 12GB of ram. :-| > > So you're saying that you've tried to build webkit on 64bit system > with 12GiB of RAM and failed? How much memory is used when build is > not running? > Yes, this is a bug or undocumented limitation in ranlib/libtool i believe. I can reproduce it with any static library/archive that is >4GB. While building the archive itself works fine, ranlib fails to build a symbol table for the archive. So why is that not a problem for the Apple port? - Simple answer: They are building WebCore as a framework (dynamic library). :-) The available memory is for sure not the problem in my case. Because even when building/linking i still have about 6GB free (free+inactive). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
Hi Sanjeet, I can confirm that the memory is most likely the problem. Especially WebKit/WebCore is growing steadily, whenever code is being added. And with WebCore we (Qt) had the problem on mac of crossing the 4GB boundary just a few days ago. So it is very likely that other ports will experience similar problems. In our case we had to make use of some of the *AllInOne files. Because we are building WebCore as a static library. And on mac you currently can't build static libs >4GB at all it seems. Ranlib always crashes when trying to build the symbol table. This even affects 64bit systems with 12GB of ram. :-| Best Regards, Zeno On Fri, Mar 23, 2012 at 11:03 AM, Sanjeet Pratap Singh < sanjeetpratapsi...@gmail.com> wrote: > Hi John, Thanks for your instant response. > But, I had been compiling webkit in debug mode earlier, with the same > configurations with no such any error. > And thats why I doubt whether increasing the RAM, is an proper and generic > solution. > > Thanks, > Sanjeet > > On Fri, Mar 23, 2012 at 3:18 PM, John Yani wrote: > >> I think you have to have at least 8 GiB of RAM (16 GiB is recommended) >> and 64-bit OS to compile webkit in debug mode. >> > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory
Hi Sachin, We had the same/a similar problem with QtWebKit. Ranlib ran out of memory on a 32bit system when building debug, because the library got bigger than 4GB. I dont think there is a proper solution for this problem. The only thing that would help would be to reduce the size of WebCore. For now we just disabled debug builds on 32bit systems. I heard some people managed to build debug by disabling SVG. - never tried it myself though. Best Regards -- Zeno On Dec 27, 2011, at 6:45 AM, sachin nikam wrote: > I synced up the latest webkit code base and am trying to build webkit > gtk on ubuntu 11.10 with 4gb of RAM and 4 CPUs > > I tried with --makeargs="-j2" but still got "ld process terminated > signal[9]" error which indicates that it ran out of memory. > I suspect i will still the get the same error with --makeargs="-j1". > Is there any other flag where we can restrict the memory usage? > Regards > Sachin > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
