Re: [webkit-dev] WinCairo 64-bit Bot Failures
Hi, the bot is persistently broken due to the SVN errors since 3 days: https://build.webkit.org/builders/WinCairo%2064-Bit%20Release?numbuilds=200 Is it maintained by anybody? Or it is just to increase the network traffic with continuous svn checkouts? Please fix the bot or stop it not to increase the network traffic and generate useless buildlogs. br, Ossy Osztrogonác Csaba írta: Hi, is this brand new bot really maintained? I haven't seen any green build, but zillion flakiness on it. It seems the WinCairo bot still has many issues, for example: - failed svn - still suffering with different magic errors: svn: E120106: ra_serf: The server sent a truncated HTTP response body. svn: E155009: Failed to run the WC DB work queue associated with '/home/webkitbot/win-cairo-release/build/LayoutTests/fast/encoding/resources', work item 6962 (file-install LayoutTests/fast/encoding/resources/099.html 1 0 1 1) svn: E02: Can't open file '/home/webkitbot/win-cairo-release/build/.svn/pristine/05/052b58d5be5cf247e2642516c4e4a6bd7211cf08.svn-base': No such file or directory could not find 'svn' ... - failed jscore tets command timed out: 1200 seconds without output - failed webkitpy tests https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/43365/steps/webkitpy-test/logs/stdio - failes webkitperl tests https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/43365/steps/webkitperl-test/logs/stdio - random failed compile webkit detail can be found here: https://build.webkit.org/builders/WinCairo%2064-Bit%20Release?numbuilds=200 PS: It would be great to have admin name and mail here: https://build.webkit.org/buildslaves/wincairo-1 br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebRTC in WebKit
Hi Benjamin Thanks for you feedback. Please see answers inline. On 28/01/15 20:14, Benjamin Poulain wrote: Getting WebRTC working on WebKitGTK sounds awesome. I am a little concerned with the use of an abstraction layer as a backend. I am afraid this could lead to weird abstractions. Typically in WebKit we try to have baseline code in C++ that handles everything that can be shared between ports, and platform abstractions for everything port and/or platform specific. Using OpenWebRTC, there would be no abstractions and WebCore would just be a bridge between JavaScript and OpenWebRTC. Is that correct? There will surely be a generic abstraction layer hiding OpenWebRTC from WebCore. We want to implement the API specification in WebCore to make it sharable between ports and even WebRTC backends, very much in line with what you describe above. This involves replacing parts of the current WebKit WebRTC infrastructure where API calls often go directly out to the backend. Where the platform gets involved, the intention is to have abstract representation of real-time media sources, media endpoints (peers capable sending/receiving media/data) and channels for generic data. An example would be that you configure a (platform) media endpoint how to send and receive allowing multiple variants, and future versions, of JS APIs to provide that information. For example: RTCPeerConnection | MediaEndpoint | OWRMediaEndpoint Could you explain a bit why you chose to use an abstraction layer at the WebRTC level instead of interfacing directly with GStreamer at the platform abstraction level? The abstraction layer we aim for is not really at the WebRTC layer. I mean it's not on a JS API layer as RTCPeerConnection. But on the other hand, using GStreamer directly would duplicate a lot of functionality that has been built in to OpenWebRTC to present a friendlier bundle to developers who wants to develop both Web and native WebRTC apps. One way to describe OpenWebRTC is as a communication framework compatible with WebRTC on protocol and media level. /Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pattern for singleton classes instance getters
Hi all, Thanks for the feedback. I submitted a coding style update proposal at Bug 141040 https://bugs.webkit.org/show_bug.cgi?id=141040. Based on the mailing list feedback, the proposal is to use a static member function named singleton()”. I will also upload a patch to align our existing code unless there is any objection. Kr, -- Chris Dumez - Apple Inc. Cupertino, CA On Jan 28, 2015, at 9:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jan 28, 2015 at 9:19 PM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com wrote: This may be a question of what jargon we’ve encountered, but to me, “singleton clearly means the one unique instance of this class while “instance means any instance of this class. If I hadn’t seen this thread, I would interpret Class::instance() to mean “create a brand new instance of this class” rather than “return the unique singleton instance of this class, creating if necessary. Agreed. I also prefer Class::singleton() over Class::instance(). - 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
