[webkit-dev] ExceptionCode cleanup.
Over the course of a few patches[1], I've refactored exception handling in twoish ways: 1. Call sites which ASSERT that no exception occurred have been replaced with the ASSERT_NO_EXCEPTION macro[2]. 2. A new IGNORE_EXCEPTION macro is now available, intended to make it clear that a method's potential exception is being explicitly and intentionally ignored[3]. It should now be the case that any instantiation of an ExceptionCode in WebCore is followed by some usage of the variable other than simply passing it into a method. WebCore's current usage is a bit haphazard, however: we assert that no exception occurs at 168 call sites, and we ignore exceptions at 274 call sites. There's no real rhyme or reason to it... I believe that many of the sites currently ignoring exceptions should probably be asserting (or replaced with new, ExceptionCode-less APIs), but I didn't feel comfortable making that change. If you have some free time, it might be worthwhile to grep through code you're familiar with to see if making that change would be reasonable. Thanks! [1]: https://bugs.webkit.org/show_bug.cgi?id=108180 [2]: https://bugs.webkit.org/show_bug.cgi?id=109044 [3]: Most notably https://wkrev.com/142375 and http://wkrev.com/142271 -mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can Qt use some of the common DRT code?
On Monday 11 February 2013, Benjamin Poulain wrote: One of the differences is the way the Qt port works. Instead of using the JSC binding APIs, it uses its own JS Qt bindings. Would it be possible for Qt to move to the common code? It would make future refactoring easier as there would be one less difference to care about. I guess that would be possible, and if you continue to add more testrunner methods using continuation passing style, we may need to, since I do not think we currently have an easy way to pass a method through the Qt bindings. That said, Qt has the most convinient interface of all the DRT implementations with the bindings automatically derived from the C++ declarations. I would hate to see that go, and since adding a method to Qt DRT is just adding the C++ method and nothing else, it is no worse than adding an empty implementation to all the ports that are using the common code. `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Chromium's TestRunner library is now a component!
Hi, the TestRunner library used by chromium's DumpRenderTree is now a component (i.e. it builds as a DLL on Windows). It defines all the test runner objects such as testRunner or eventSender and is implemented entirely in terms of the public chromium WebKit API (i.e. it has no dependencies on WTF or WebCore, nor chromium's webkit_support for that matter). If you need to add a method to e.g. eventSender, and it's only using the public WebKit API, you can just add it to Tools/DumpRenderTree/chromium/TestRunner/src/EventSender.cpp. If your method needs to interact with a WebFrameClient or WebViewClient callback or return a mock from such a callback, you can modify the WebTestProxy, a template that is injected between the WebView / WebFrame and the actual implementation in TestShell / ContentShell. If you want to add something that depends on interactions with the embedder (TestShell / ContentShell), you should add a callback to the WebTestDelegate. best -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] A catalog of iOS-specific changes related to the WebThread
Thanks for the heads up! -Darin On Sun, Feb 10, 2013 at 1:53 PM, Maciej Stachowiak m...@apple.com wrote: Here is a list all iOS-specific changes in WebCore and below that are due to the iOS WebKit threading model, from an exhaustive review of diffs to the downstream source. I'm not sure anyone needs this to make a decision any more, but it may be helpful to people to know what's coming as we merge, and to provide input about specific items if they care to. Key: - Probably has to be upstreamed for the WebThread to work in the open source tree = Probably has to be upstreamed, but only affects files specific to the iOS port and/or the Mac port + Can likely be removed before upstreaming % Can probably be removed sooner than other differences (these things are needed for a non-WebKit use on the system which is likely to go away) ? I'm not sure what status this is In WTF: - Changing WTF::MainThread to recognize either the web thread of the main thread - Changes to ThreadRestrictionVerifier to deal with web thread vs main thread - Changing the assert in StringStatics.cpp to assert the true main thread, not isMainThread() (probably not strictly necessary) - Change the StackBounds consistency check to adapt to main thread vs Web thread (this is a class used by JSC for conservative stack scanning) - Sharing of the JSC identifier table (but no locking for that) % Locking and sharing for AtomicString (possibly removable; was added to avoid a crash on exit) In JSC, one change total: - A trick to avoid creating the GC timer on the wrong thread In WebCore: - In JSDOMWindowBase.cpp, arrange for JSC to handle the Web thread correctly - A change to get ThreadGlobalData to be the same on the web thread and the main thread - ScriptDebugServer.cpp, drop and reacquire the web thread lock around a nested run loop in ScriptDebugServer - The Web thread messages the main thread about some events via WKContentObservation = The actual implementation of the Web Thread and associated locking and messaging mechanisms = Not initializing threading in SharedBufferMac.mm +initialize (to avoid initializing on the wrong thread) = Not initializing threading in WebScriptObject.mm +initialize (to avoid initializing on the wrong thread) = The iOS implementation of SharedTimer operates on the WebThread run loop and messages the WebThread = Taking the Web thread lock in an iOS-specific accessibility implementation file = Locking around the ObjC DOM wrapper cache = Schedule CFNetwork callbacks on the Web thread runloop rather than the main runloop = The iOS tile cache implementation uses locking and messaging between the web thread and main thread much like the tile cache in the open source tree does it between the main thread and the scrolling thread = CALayer implementations sometimes grab the global lock and/or message to the WebThread from the main thread (affects WebLayer, PlatformCALayer, and a special layer that exists for text tracks) = An iBooks-specific workaround to target the main thread in LayerFlushSchedulerMac = Some messaging from the web thread to the main thread due to the weird way HTML5 video is implemented on iOS, in CA-specific files = WebCoreMotionManager (a new file that does not exist upstream) uses WebThread primitives + Some places that check isMainThread() || pthread_main_np(), which I expect will not be needed with the isMainThread() change and will likely be fixed before upstreaming; we're changing isMainThread() specifically to avoid sprinkling these diffs all over WebCore + In several places, avoid asserting m_thread == currentThread() (these diffs can probably be eliminated as by introducing an isCurrentThread() function) + An iOS-specific extra ASSERT in ThreadTimers.cpp (probably not needed) + Apparently obsolete includes of WebCoreThread.h in some files (e.g. TextBreakIteratorICU.cpp) + Apparently obsolete code to include WebCoreThreadMessage.h in some generated bindings (seems unused) + Apparently obsolete code to include WebCoreThreadMessage.h in some files (e.g. DOMHTML.mm) + An iOS-specific DiskImageCache in WebCore/loader uses threading in a non-portable way - it directly uses libdispatch and messages the WebThread. We can likely either remove it or rewrite it to do its threading in a more portable way. % A mutex in FontCache.cpp around access to the font cache (needed for a non-WebKit use of WebCore that's likely to be phased out a fair bit sooner than the Web thread) ? Make ScriptController::initializeThreading a no-op (no idea why this is needed) ? Make HTMLParserScheduler yield if it is at a yield candidate point and the main thread is waiting on the web thread lock (this was done long ago for responsiveness, but we need to retest) ? A mutex to guard creation and pausing of the database thread (I don't understand why this is needed) ___ webkit-dev mailing list
Re: [webkit-dev] Is the wxWidgets port maintained?
Hi Benjamin, On Feb 10, 2013, at 7:23 PM, Benjamin Poulain wrote: Hi again, While looking into DRT changes, I notice there is zero activity on the wxWidgets implementation. Looking at WebCore/WebKit, excluding general changes, the last commit for wxWidgets is 6 months old: http://trac.webkit.org/changeset/126457 So...is the port still active? Maybe it should live outside webkit.org like the Haiku port? The project is not dead per-se, but it's true that it's not very active these days. Recently, I haven't had a lot of time to devote to the port. The other big factor has been that I've been the only active contributor to the port pretty much since its inception, which has made patch submission pretty difficult due to the challenge of finding a reviewer with knowledge of the wx code. As a result, the wx activity on trunk will look pretty sparse since I'm making most of my changes on the wx port's git repo on gitorious.org rather than submitting patches for trunk. When it comes to trunk, I basically just periodically submit build fixes for any build breakages in order to merge and update my git mirror. I actually have recently been working on a patch to get trunk building again, though. The path of least resistance for me would simply be to ask people to ignore the wx port in their changes, but leave it in the tree. git is much better about these things, but I still remember what a pain it was to maintain the entire port in an svn branch back in the day, and I'd rather not re-try that experiment unless I really have to. If people feel strongly that I should approach things another way, though, I'm certainly open to ideas. Thanks, Kevin Benjamin ___ 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] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.comwrote: I actually have recently been working on a patch to get trunk building again, though. The path of least resistance for me would simply be to ask people to ignore the wx port in their changes, but leave it in the tree. git is much better about these things, but I still remember what a pain it was to maintain the entire port in an svn branch back in the day, and I'd rather not re-try that experiment unless I really have to. If people feel strongly that I should approach things another way, though, I'm certainly open to ideas. Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. Looking at the history of wx's WebKit and platform code, the vast majority of changes are from Apple/Google. I think it is unfair to have many people maintain your code while you develop the project outside of the tree. Given the data, I am in favor of removing the wx port from webkit.org and have it be a separate tree on Gitorious or GitHub. What are the main pain points of developing outside webkit.org for you? Is there anything that can be done in the structure to simplify such changes? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.com wrote: The project is not dead per-se, but it's true that it's not very active these days. Recently, I haven't had a lot of time to devote to the port. The other big factor has been that I've been the only active contributor to the port pretty much since its inception, which has made patch submission pretty difficult due to the challenge of finding a reviewer with knowledge of the wx code. As a result, the wx activity on trunk will look pretty sparse since I'm making most of my changes on the wx port's git repo on gitorious.org rather than submitting patches for trunk. When it comes to trunk, I basically just periodically submit build fixes for any build breakages in order to merge and update my git mirror. Regardless of whether the Wx port stays in the tree, I think you should consider changing your build system. I believe the only port that uses waf is Wx, so using cmake or gyp will make your work a lot easier. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 12:27 PM, Benjamin Poulain wrote: On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.com wrote: I actually have recently been working on a patch to get trunk building again, though. The path of least resistance for me would simply be to ask people to ignore the wx port in their changes, but leave it in the tree. git is much better about these things, but I still remember what a pain it was to maintain the entire port in an svn branch back in the day, and I'd rather not re-try that experiment unless I really have to. If people feel strongly that I should approach things another way, though, I'm certainly open to ideas. Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. Looking at the history of wx's WebKit and platform code, the vast majority of changes are from Apple/Google. I think it is unfair to have many people maintain your code while you develop the project outside of the tree. Given the data, I am in favor of removing the wx port from webkit.org and have it be a separate tree on Gitorious or GitHub. What are the main pain points of developing outside webkit.org for you? Is there anything that can be done in the structure to simplify such changes? My big concern is not losing history while moving the wx files out of the tree and into a git branch, and also at the same time not losing the ability to merge the rest of trunk safely. Though I haven't investigated the process yet, so I don't know how easy or hard it may be. Thanks, Kevin Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
Hi Martin, On Feb 11, 2013, at 12:47 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.com wrote: The project is not dead per-se, but it's true that it's not very active these days. Recently, I haven't had a lot of time to devote to the port. The other big factor has been that I've been the only active contributor to the port pretty much since its inception, which has made patch submission pretty difficult due to the challenge of finding a reviewer with knowledge of the wx code. As a result, the wx activity on trunk will look pretty sparse since I'm making most of my changes on the wx port's git repo on gitorious.org rather than submitting patches for trunk. When it comes to trunk, I basically just periodically submit build fixes for any build breakages in order to merge and update my git mirror. Regardless of whether the Wx port stays in the tree, I think you should consider changing your build system. I believe the only port that uses waf is Wx, so using cmake or gyp will make your work a lot easier. Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machines it might be a couple seconds. For me, it's negligible given the benefit I get from it. As an example, I'm still at the linking phase right now on Mac (dealing with the removal of the libWebKitLibrarySnowLeopard.a and a couple other things), but my patch so far to catch up with 6 months of changes in trunk is right now at 19KB, and about 30 lines or so of that is actually the build system changes. The number of exceptions I needed to add to the build over that time is 4, and I added about as many build directories to the list as well. I suspect if we were to accumulate the changes to cmake and gyp files over those 6 months, it will probably be well above 30-40 lines. Sure, I wouldn't have written all those lines myself, but sharing work with other developers is still more work for any individual developer than having the computer do the work for you. :) Everyone tells me how great cmake and gyp is, but I'm not sure any of them have taken any time out to actually investigate whether or not waf is as good as or better than their preferred tool. (It's not as good as auto-generating project files, but it's also in Python so integrating it with gyp would probably be a simple task.) I've often wanted to take some time out to get other ports building with it, as it probably would take a day or two at most, but I lack both the time and expertise in other ports to spend much time on that. Much of the code in there already is port-agnostic, with most wx-specific bits in a port_name == wx check, but of course there's the issue of the various port-specific build configurations and such for each port. Regards, Kevin --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 1:34 PM, Kevin Ollivier kev...@theolliviers.comwrote: On Feb 11, 2013, at 12:27 PM, Benjamin Poulain wrote: On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.comwrote: I actually have recently been working on a patch to get trunk building again, though. The path of least resistance for me would simply be to ask people to ignore the wx port in their changes, but leave it in the tree. git is much better about these things, but I still remember what a pain it was to maintain the entire port in an svn branch back in the day, and I'd rather not re-try that experiment unless I really have to. If people feel strongly that I should approach things another way, though, I'm certainly open to ideas. Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. Looking at the history of wx's WebKit and platform code, the vast majority of changes are from Apple/Google. I think it is unfair to have many people maintain your code while you develop the project outside of the tree. Given the data, I am in favor of removing the wx port from webkit.org and have it be a separate tree on Gitorious or GitHub. What are the main pain points of developing outside webkit.org for you? Is there anything that can be done in the structure to simplify such changes? My big concern is not losing history while moving the wx files out of the tree and into a git branch, and also at the same time not losing the ability to merge the rest of trunk safely. Though I haven't investigated the process yet, so I don't know how easy or hard it may be. I kindly ask you to let us remove it from trunk in that case. Given that we have 400+ contributors, having a port that's only maintained by a single person on trunk imposes a significant maintenance burden on others even if you said that people can break Wx port because not everyone reads this thread and wouldn't necessarily know your intent. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
I'll add that now that https://github.com/WebKit/webkit uses the same hashing as git.webkit.org, it'll be trivial for folks wanting to have their own ports to fork on github and maintain svn history. Maybe we should even encourage that for new ports: initially forking WebKit on github to create their port and then wait until it gets enough tractions to land it on trunk. Meanwhile, are there anything we can do as the WebKit community to help maintaing a one-man port like Wx in the future? e.g. rebumping build systems, etc... - R. Niwa On Mon, Feb 11, 2013 at 1:51 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 11, 2013 at 1:34 PM, Kevin Ollivier kev...@theolliviers.comwrote: On Feb 11, 2013, at 12:27 PM, Benjamin Poulain wrote: On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.com wrote: I actually have recently been working on a patch to get trunk building again, though. The path of least resistance for me would simply be to ask people to ignore the wx port in their changes, but leave it in the tree. git is much better about these things, but I still remember what a pain it was to maintain the entire port in an svn branch back in the day, and I'd rather not re-try that experiment unless I really have to. If people feel strongly that I should approach things another way, though, I'm certainly open to ideas. Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. Looking at the history of wx's WebKit and platform code, the vast majority of changes are from Apple/Google. I think it is unfair to have many people maintain your code while you develop the project outside of the tree. Given the data, I am in favor of removing the wx port from webkit.organd have it be a separate tree on Gitorious or GitHub. What are the main pain points of developing outside webkit.org for you? Is there anything that can be done in the structure to simplify such changes? My big concern is not losing history while moving the wx files out of the tree and into a git branch, and also at the same time not losing the ability to merge the rest of trunk safely. Though I haven't investigated the process yet, so I don't know how easy or hard it may be. I kindly ask you to let us remove it from trunk in that case. Given that we have 400+ contributors, having a port that's only maintained by a single person on trunk imposes a significant maintenance burden on others even if you said that people can break Wx port because not everyone reads this thread and wouldn't necessarily know your intent. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machine s it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. The situation we have now is that we have many build systems, so we probably need to think about discarding some awesome ones [1] for ones that are popular with our peers. If the Wx port were to move out of the tree, obviously this isn't a huge deal -- just a suggestion. 1. All things being equal, waf looks to be the best replacement for autotools for WebKitGTK+. I've heard it's faster than both scons and cmake and it supports 'make install' and 'make dist.' Sadly, not all things are equal at svn.webkit.org, so gyp or cmake are the best hope at the moment. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
Hi Everyone, On Mon, Feb 11, 2013 at 1:51 PM, Ryosuke Niwa rn...@webkit.org wrote: Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. My big concern is not losing history while moving the wx files out of the tree and into a git branch, and also at the same time not losing the ability to merge the rest of trunk safely. Though I haven't investigated the process yet, so I don't know how easy or hard it may be. I kindly ask you to let us remove it from trunk in that case. Given that we have 400+ contributors, having a port that's only maintained by a single person on trunk imposes a significant maintenance burden on others even if you said that people can break Wx port because not everyone reads this thread and wouldn't necessarily know your intent. I would be sad if the WebKit project started to exclude ports simply because they were (largely) maintained by a single person. I do agree that it's not fair to other ports if the primary developer is not working to keep the port building, but life happens and sometimes a lone developer cannot stay on top of the rapidly-changing source base. Having these ports in the main tree is a good thing, in my opinion, because it helps avoid fragmentation, and often the refactoring required to enable these ports provides architectural benefits to the project as a whole. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 1:34 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 12:27 PM, Benjamin Poulain wrote: On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.com wrote: I actually have recently been working on a patch to get trunk building again, though. The path of least resistance for me would simply be to ask people to ignore the wx port in their changes, but leave it in the tree. git is much better about these things, but I still remember what a pain it was to maintain the entire port in an svn branch back in the day, and I'd rather not re-try that experiment unless I really have to. If people feel strongly that I should approach things another way, though, I'm certainly open to ideas. Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. Looking at the history of wx's WebKit and platform code, the vast majority of changes are from Apple/Google. I think it is unfair to have many people maintain your code while you develop the project outside of the tree. Given the data, I am in favor of removing the wx port from webkit.org and have it be a separate tree on Gitorious or GitHub. What are the main pain points of developing outside webkit.org for you? Is there anything that can be done in the structure to simplify such changes? My big concern is not losing history while moving the wx files out of the tree and into a git branch, and also at the same time not losing the ability to merge the rest of trunk safely. Though I haven't investigated the process yet, so I don't know how easy or hard it may be. If you create a github repository by forking from the canonical webkit github repository, you'll have history for all the wx files and a good way to merge from trunk at times that you find convenient. I think that's the motivation behind the suggestion. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 2:13 PM, Brent Fulgham bfulg...@gmail.com wrote: On Mon, Feb 11, 2013 at 1:51 PM, Ryosuke Niwa rn...@webkit.org wrote: Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. My big concern is not losing history while moving the wx files out of the tree and into a git branch, and also at the same time not losing the ability to merge the rest of trunk safely. Though I haven't investigated the process yet, so I don't know how easy or hard it may be. I kindly ask you to let us remove it from trunk in that case. Given that we have 400+ contributors, having a port that's only maintained by a single person on trunk imposes a significant maintenance burden on others even if you said that people can break Wx port because not everyone reads this thread and wouldn't necessarily know your intent. I would be sad if the WebKit project started to exclude ports simply because they were (largely) maintained by a single person. I do agree that it's not fair to other ports if the primary developer is not working to keep the port building, but life happens and sometimes a lone developer cannot stay on top of the rapidly-changing source base. Having these ports in the main tree is a good thing, in my opinion, because it helps avoid fragmentation, and often the refactoring required to enable these ports provides architectural benefits to the project as a whole. I'm not opposed to keeping those refactoring in trunk. As I said on https://lists.webkit.org/pipermail/webkit-dev/2013-January/023563.html, the problem is the ratio of contribution each port makes to the core code vs. the cost it imposes on the project. Having hundreds, if not thousands, of engineers sync Wx code in WebKit trunk whenever they run svn up or git fetch is a significant cost on its own, and we need a good justification for it. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 2:13 PM, Brent Fulgham wrote: Hi Everyone, On Mon, Feb 11, 2013 at 1:51 PM, Ryosuke Niwa rn...@webkit.org wrote: Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. My big concern is not losing history while moving the wx files out of the tree and into a git branch, and also at the same time not losing the ability to merge the rest of trunk safely. Though I haven't investigated the process yet, so I don't know how easy or hard it may be. I kindly ask you to let us remove it from trunk in that case. Given that we have 400+ contributors, having a port that's only maintained by a single person on trunk imposes a significant maintenance burden on others even if you said that people can break Wx port because not everyone reads this thread and wouldn't necessarily know your intent. I would be sad if the WebKit project started to exclude ports simply because they were (largely) maintained by a single person. I do agree that it's not fair to other ports if the primary developer is not working to keep the port building, but life happens and sometimes a lone developer cannot stay on top of the rapidly-changing source base. Having these ports in the main tree is a good thing, in my opinion, because it helps avoid fragmentation, and often the refactoring required to enable these ports provides architectural benefits to the project as a whole. FWIW, I think it'd be pretty simple to add a generic rule that if you want your port to benefit from shared maintenance, you must set up a build bot on the waterfall and/or an EWS bot. In fact, I personally think this ought to be a rule regardless of what happens to the wx port, as IMHO it's pretty much a pre-requisite for allowing people contributors on other ports to make changes to your code safely. Thanks, Kevin -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 1:55 PM, Ryosuke Niwa rn...@webkit.org wrote: Meanwhile, are there anything we can do as the WebKit community to help maintaing a one-man port like Wx in the future? e.g. rebumping build systems, etc... I think the recent discussions about standardizing on something like gyp seems like a really good first step. That would greatly reduce the burden caused by various build systems. Many common cases that break builds now might not ever be a problem using something like gyp. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Hi Martin, On Feb 11, 2013, at 12:47 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.com wrote: The project is not dead per-se, but it's true that it's not very active these days. Recently, I haven't had a lot of time to devote to the port. The other big factor has been that I've been the only active contributor to the port pretty much since its inception, which has made patch submission pretty difficult due to the challenge of finding a reviewer with knowledge of the wx code. As a result, the wx activity on trunk will look pretty sparse since I'm making most of my changes on the wx port's git repo on gitorious.org rather than submitting patches for trunk. When it comes to trunk, I basically just periodically submit build fixes for any build breakages in order to merge and update my git mirror. Regardless of whether the Wx port stays in the tree, I think you should consider changing your build system. I believe the only port that uses waf is Wx, so using cmake or gyp will make your work a lot easier. Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machine s it might be a couple seconds. For me, it's negligible given the benefit I get from it. As an example, I'm still at the linking phase right now on Mac (dealing with the removal of the libWebKitLibrarySnowLeopard.a and a couple other things), but my patch so far to catch up with 6 months of changes in trunk is right now at 19KB, and about 30 lines or so of that is actually the build system changes. The number of exceptions I needed to add to the build over that time is 4, and I added about as many build directories to the list as well. I suspect if we were to accumulate the changes to cmake and gyp files over those 6 months, it will probably be well above 30-40 lines. Sure, I wouldn't have written all those lines myself, but sharing work with other developers is still more work for any individual developer than having the computer do the work for you. :) Everyone tells me how great cmake and gyp is, but I'm not sure any of them have taken any time out to actually investigate whether or not waf is as good as or better than their preferred tool. (It's not as good as auto-generating project files, but it's also in Python so integrating it with gyp would probably be a simple task.) I've often wanted to take some time out to get other ports building with it, as it probably would take a day or two at most, but I lack both the time and expertise in other ports to spend much time on that. Much of the code in there already is port-agnostic, with most wx-specific bits in a port_name == wx check, but of course there's the issue of the various port-specific build configurations and such for each port. I have to admit, I thought waf was more like scons and less like cmake and gyp, i.e., I thought it was a portable build system rather than a meta-build system (and had never looked at it in detail accordingly). I am taking another look at it now :) -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machin es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. Plus, my overarching reason for switching away from a tool like gyp or bakefile was to get away from using domain-specific languages for build tools. In short, waf doesn't have a syntax, it has an API. With waf and Python, I don't have to worry about fitting my design goals into some project file format built perhaps by someone with a different set of needs than mine. If I need it, I just code it. On-demand automated dependency download is one example of this. Another thing on my TODO list, actually, is to integrate in a little tool I have started coding up called 'gattai', http://sf.net/projects/gattai, which aims to be able to pull and, if necessary, build the various deps a project needs in source or binary form. And yet another thing I wanted to play with actually was having it dynamically generate AllInOne.cpp files for various directories and profile how much of a speed change there is in the builds by doing so. I suspect that we could squeeze out some considerable gains that way. Anyway, those are just some examples. Just wanted to say that for me, the rule-based compilation is certainly one of the most used features of waf, but it's far from the only thing I chose it for. The situation we have now is that we have many build systems, so we probably need to think about discarding some awesome ones [1] for ones that are popular with our peers. If the Wx port were to move out of the tree, obviously this isn't a huge deal -- just a suggestion. 1. All things being equal, waf looks to be the best replacement for autotools for WebKitGTK+. I've heard it's faster than both scons and cmake and it supports 'make install' and 'make dist.' Sadly, not all things are equal at svn.webkit.org, so gyp or cmake are the best hope at the moment. Yes, it's light years faster than Scons, and I don't know about cmake but honestly, I have a hard time thinking my build could get much faster than waf makes it, aside from speeding up the compiler itself. Efficient use of multiple cores, and smart dependency tracking both help considerably. Anyway, I do understand your point about adoption, and it's the primary reason I don't really say much on the issue. I think waf has a lot of things going for it, some of which I feel are pretty well-suited to a project like WebKit, but if people already have their minds set on other tools, that's pretty much the end of the conversation. Thanks, Kevin --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machi n es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. There's two different things going on here: ease of maintenance, and reproducibility. Using wildcards in the (meta-)build file itself can make things easier but make it harder to get reproducible builds since you might accidentally include files in the tree you didn't want. When you're on a minority port, having wildcards certainly makes your life easier because you don't have to track every change we make explicitly, and it's probably easier for you to ensure you're doing things correctly in your own checkouts, so you don't have to worry about reproducibility as much. On the other hand, if you were to convert to using the same gypi files we were using, then you wouldn't have to track every change we make, either; you'd get them for free. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier kev...@theolliviers.comwrote: On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machin es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. We do! WebCore.gypi just lists all files and http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.gyp/WebCore.gypdefines what gets built on each platform. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing ENABLE(WEB_INTENTS) code
Going once, going twice… https://bugs.webkit.org/show_bug.cgi?id=109501 On Sat, Feb 2, 2013 at 3:09 PM, Sam Weinig wei...@apple.com wrote: Sounds good to me as well. -Sam On Jan 30, 2013, at 3:54 PM, Nico Weber tha...@chromium.org wrote: Hi, I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know, nobody ever shipped this and nobody intents to. Please speak up if you'd like that code to stick around. Nico ___ 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] Removing ENABLE(WEB_INTENTS) code
Having just spent all day removing NEW_XML cruft, I'm glad to see this unused code go sooner rather than later. :) On Mon, Feb 11, 2013 at 3:44 PM, Nico Weber tha...@chromium.org wrote: Going once, going twice… https://bugs.webkit.org/show_bug.cgi?id=109501 On Sat, Feb 2, 2013 at 3:09 PM, Sam Weinig wei...@apple.com wrote: Sounds good to me as well. -Sam On Jan 30, 2013, at 3:54 PM, Nico Weber tha...@chromium.org wrote: Hi, I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know, nobody ever shipped this and nobody intents to. Please speak up if you'd like that code to stick around. Nico ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Controlling use of Deletion UI with ENABLE_DELETION_UI
On Mon, Feb 11, 2013 at 3:53 PM, Enrica Casucci enr...@apple.com wrote: with http://trac.webkit.org/changeset/142533 I've added the ability to control the use of the Deletion UI. I've explicitly enabled the feature for MAC and disabled it for iOS but I left in on by default for all the other ports, since I wasn't sure if how other WebKit clients were using it. I suspect many ports use it only in the tests. If this is the case I would encourage every port to take explicit action and decide whether this is something you want or not. You forgot to mention that you did this as a part of upstreaming iOS code :) I'm going to move delete button controller tests to platform/mac and delete corresponding code in non-Mac ports. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 3:33 PM, Dirk Pranke wrote: On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower mach in es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. There's two different things going on here: ease of maintenance, and reproducibility. Using wildcards in the (meta-)build file itself can make things easier but make it harder to get reproducible builds since you might accidentally include files in the tree you didn't want. When you're on a minority port, having wildcards certainly makes your life easier because you don't have to track every change we make explicitly, and it's probably easier for you to ensure you're doing things correctly in your own checkouts, so you don't have to worry about reproducibility as much. If the filesystem always follows clearly defined rules, then I'd argue that reproducibility would not be an issue, though. WebKit currently doesn't always, but the vast majority of times it does. The cases where it doesn't are few and far between, and I don't think fixes would be all that difficult. You can always create specific locations, like perhaps a Shared directory, for any special cases that should explicitly be added by more than one, but a subset of, ports, and can't be properly encapsulated into a feature or use define. (For example, the WhateverNone.cpp are one of the special exceptions I have to account for, and they could go in there.) I think the concern is really that this approach seems 'implicit' rather than 'explicit'. With clear filesystem rules, though, it's not actually implicit. A file going into one of the directories listed as a primary build dir means it is to be built by all ports. So long as the project defines said rules, the act of putting it there is explicit, and expresses intent. This also, BTW, addresses the problem of old stuff being left in the tree. To remove it from the build, you have to remove it, so you can just leave it sitting in the tree for someone to stumble across later. (I'm pretty sure a number of the exceptions I define in waf are actually examples of this.) On the other hand, if you were to convert to using the same gypi files we were using, then you wouldn't have to track every change we make, either; you'd get them for free. Yes, but this mechanism relies on WebKit's policies about fixing others' build systems to be effective. waf, on the other hand, removes that task almost entirely. Plus, see my other comments about all the other benefits of using a meta-build system. (And BTW, on that topic, in newer versions of waf there is even a build system kit that provides a starting point for building your own build system off of waf. :) Thanks, Kevin -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 3:37 PM, Ryosuke Niwa wrote: On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machin es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. We do! WebCore.gypi just lists all files and http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.gyp/WebCore.gyp defines what gets built on each platform. Sorry if I wasn't clear, but by rule-based compilation, I mean not having a WebCore.gypi to maintain at all. waf needs no such file because it checks the filesystem with a set of rules to determine what sources to build. Thanks, Kevin - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 4:30 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 3:33 PM, Dirk Pranke wrote: On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower mac hin es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. There's two different things going on here: ease of maintenance, and reproducibility. Using wildcards in the (meta-)build file itself can make things easier but make it harder to get reproducible builds since you might accidentally include files in the tree you didn't want. When you're on a minority port, having wildcards certainly makes your life easier because you don't have to track every change we make explicitly, and it's probably easier for you to ensure you're doing things correctly in your own checkouts, so you don't have to worry about reproducibility as much. If the filesystem always follows clearly defined rules, then I'd argue that reproducibility would not be an issue, though. WebKit currently doesn't always, but the vast majority of times it does. The cases where it doesn't are few and far between, and I don't think fixes would be all that difficult. You can always create specific locations, like perhaps a Shared directory, for any special cases that should explicitly be added by more than one, but a subset of, ports, and can't be properly encapsulated into a feature or use define. (For example, the WhateverNone.cpp are one of the special exceptions I have to account for, and they could go in there.) I think the concern is really that this approach seems 'implicit' rather than 'explicit'. With clear filesystem rules, though, it's not actually implicit. A file going into one of the directories listed as a primary build dir means it is to be built by all ports. So long as the project defines said rules, the act of putting it there is explicit, and expresses intent. This also, BTW, addresses the problem of old stuff being left in the tree. To remove it from the build, you have to remove it, so you can just leave it sitting in the tree for someone to stumble across later. (I'm pretty sure a number of the exceptions I define in waf are actually examples of this.) I'm not sure we're talking about the same sort of concerns. The case I'm talking about when you have a makefile that says something like SRCS=*.cpp. Then, I have to remember to save a local copy of a file as foo.cpp.orig rather than foo_orig.cpp, and if I want to rename a file I have to actually rename it rather than copy it (or at least remember to delete it). I think you're talking more about conventions over which directories contain files for each port? On the other hand, if you were to convert to using the same gypi files we were using, then you wouldn't have to track every change we make, either; you'd get them for free. Yes, but this mechanism relies on WebKit's policies about fixing others' build systems to be effective. waf, on the other hand, removes that task almost entirely. Plus, see my other comments about all the other benefits of using a meta-build system. (And BTW, on that
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 4:53 PM, Kevin Ollivier kev...@theolliviers.comwrote: I know you're speaking more in general here, but just to be clear, over the past 6 months, the data hit that WebKit engineers have taken on account of the wx port is close to 0 bytes. The only time svn up or git fetch has pulled anything related to wx is when other developers attempted to update the wx port based on changes made to common code. As things stand, I'd not only be okay with, but actually prefer, that no other port maintainers do anything to try and fix the wx build. This way the port is not causing anyone else a burden except occasionally when I do land some fixes. As I said in my reply to Brent, I think a no build bot / no shared maintenance project rule is not only reasonable, as a practical matter it is required. I'd argue that others contributors having to know to ignore Wx port's code is the most significant cost. How is a new contributor supposed to know to ignore Wx port code? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Controlling use of Deletion UI with ENABLE_DELETION_UI
On Mon, Feb 11, 2013 at 5:11 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 11, 2013, at 4:23 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 11, 2013 at 3:53 PM, Enrica Casucci enr...@apple.com wrote: with http://trac.webkit.org/changeset/142533 I've added the ability to control the use of the Deletion UI. I've explicitly enabled the feature for MAC and disabled it for iOS but I left in on by default for all the other ports, since I wasn't sure if how other WebKit clients were using it. I suspect many ports use it only in the tests. If this is the case I would encourage every port to take explicit action and decide whether this is something you want or not. You forgot to mention that you did this as a part of upstreaming iOS code :) I'm going to move delete button controller tests to platform/mac and delete corresponding code in non-Mac ports. Would it be worthwhile to make the editing deletion UI runtime switchable instead, so the behavior with it on and off can be tested on all ports? That's the status quo but I don't think that's useful given no other port ships it. A lot of refactoring we want to do in this area will be much easier if non-Mac ports such as Qt and Chromium didn't enable the feature just to pass layout tests. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Controlling use of Deletion UI with ENABLE_DELETION_UI
On Feb 11, 2013, at 5:16 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 11, 2013 at 5:11 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 11, 2013, at 4:23 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 11, 2013 at 3:53 PM, Enrica Casucci enr...@apple.com wrote: with http://trac.webkit.org/changeset/142533 I've added the ability to control the use of the Deletion UI. I've explicitly enabled the feature for MAC and disabled it for iOS but I left in on by default for all the other ports, since I wasn't sure if how other WebKit clients were using it. I suspect many ports use it only in the tests. If this is the case I would encourage every port to take explicit action and decide whether this is something you want or not. You forgot to mention that you did this as a part of upstreaming iOS code :) I'm going to move delete button controller tests to platform/mac and delete corresponding code in non-Mac ports. Would it be worthwhile to make the editing deletion UI runtime switchable instead, so the behavior with it on and off can be tested on all ports? That's the status quo but I don't think that's useful given no other port ships it. A lot of refactoring we want to do in this area will be much easier if non-Mac ports such as Qt and Chromium didn't enable the feature just to pass layout tests. Also, the use of DeleteButtonController comes with a cost even when the client is not interested in the DeletionUI. The delegate call takes as parameter the 'deletable' element which needs to be computed before figuring out that the client is not interested in using it. As an example this is computed for every selection change. The next step is to improve it for ports like Mac where we want to use this but not on every client. Enrica - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 5:03 PM, Dirk Pranke wrote: On Mon, Feb 11, 2013 at 4:30 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 3:33 PM, Dirk Pranke wrote: On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower ma chin es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. There's two different things going on here: ease of maintenance, and reproducibility. Using wildcards in the (meta-)build file itself can make things easier but make it harder to get reproducible builds since you might accidentally include files in the tree you didn't want. When you're on a minority port, having wildcards certainly makes your life easier because you don't have to track every change we make explicitly, and it's probably easier for you to ensure you're doing things correctly in your own checkouts, so you don't have to worry about reproducibility as much. If the filesystem always follows clearly defined rules, then I'd argue that reproducibility would not be an issue, though. WebKit currently doesn't always, but the vast majority of times it does. The cases where it doesn't are few and far between, and I don't think fixes would be all that difficult. You can always create specific locations, like perhaps a Shared directory, for any special cases that should explicitly be added by more than one, but a subset of, ports, and can't be properly encapsulated into a feature or use define. (For example, the WhateverNone.cpp are one of the special exceptions I have to account for, and they could go in there.) I think the concern is really that this approach seems 'implicit' rather than 'explicit'. With clear filesystem rules, though, it's not actually implicit. A file going into one of the directories listed as a primary build dir means it is to be built by all ports. So long as the project defines said rules, the act of putting it there is explicit, and expresses intent. This also, BTW, addresses the problem of old stuff being left in the tree. To remove it from the build, you have to remove it, so you can just leave it sitting in the tree for someone to stumble across later. (I'm pretty sure a number of the exceptions I define in waf are actually examples of this.) I'm not sure we're talking about the same sort of concerns. The case I'm talking about when you have a makefile that says something like SRCS=*.cpp. Then, I have to remember to save a local copy of a file as foo.cpp.orig rather than foo_orig.cpp, and if I want to rename a file I have to actually rename it rather than copy it (or at least remember to delete it). I think you're talking more about conventions over which directories contain files for each port? Yes, that was what I was talking about. I tend to avoid making copies of files like what you describe so as not to clutter my local tree. If I'm going to make substantial or more experimental changes, I just move it onto a git branch so I can just wipe everything if it doesn't pan out. On the other hand, if you were to convert to using the same gypi files we were
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 5:20 PM, Benjamin Poulain wrote: On Mon, Feb 11, 2013 at 5:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 11, 2013 at 4:53 PM, Kevin Ollivier kev...@theolliviers.com wrote: I know you're speaking more in general here, but just to be clear, over the past 6 months, the data hit that WebKit engineers have taken on account of the wx port is close to 0 bytes. The only time svn up or git fetch has pulled anything related to wx is when other developers attempted to update the wx port based on changes made to common code. As things stand, I'd not only be okay with, but actually prefer, that no other port maintainers do anything to try and fix the wx build. This way the port is not causing anyone else a burden except occasionally when I do land some fixes. As I said in my reply to Brent, I think a no build bot / no shared maintenance project rule is not only reasonable, as a practical matter it is required. I'd argue that others contributors having to know to ignore Wx port's code is the most significant cost. How is a new contributor supposed to know to ignore Wx port code? It looks like everyone agree wx would be better maintained outside webkit.org. Kevin just need to find a technical solution to the problem of maintaining the history. I will make a patch removing wxWidgets from the tree. Kevin, can you communicate when you are ready for the transition? I'd like to do that this week if that is okay with you. To be honest, I think I know more about the wx port, and would probably be better able to cleanly remove it from the tree, than you would. As I've said from the start, I'll remove it if that's what people want, but I do think the severity of this problem is being exaggerated, and going from posing the question of project status to giving a one week eviction notice in less than 24 hours seems a bit rash to say the least. I wish I could get paid good money to spend my time doing things like creating patches to remove inactive files from source trees. :) As it stands, though, this wasn't exactly on my TODO list for this week as of, say, this morning, and I do have plenty on it right now. I'm already even regretting how much time I've put into this discussion. To think, it was wx and GTK that started the whole WebKit porting experiment in the first place, thanks to the gracious help of the WebKit community, and particularly Eric, and now I feel like the project can't push me out the door fast enough. ;-) Please be patient, I will take care of it, but I doubt I will manage it this week. Regards, Kevin Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 6:17 PM, Kevin Ollivier kev...@theolliviers.comwrote: To be honest, I think I know more about the wx port, and would probably be better able to cleanly remove it from the tree, than you would. As I've said from the start, I'll remove it if that's what people want, but I do think the severity of this problem is being exaggerated, and going from posing the question of project status to giving a one week eviction notice in less than 24 hours seems a bit rash to say the least. I wish I could get paid good money to spend my time doing things like creating patches to remove inactive files from source trees. :) As it stands, though, this wasn't exactly on my TODO list for this week as of, say, this morning, and I do have plenty on it right now. I'm already even regretting how much time I've put into this discussion. I am sorry, I should have given more context. There is visibly a growing discontent in the community about the cost imposed from small ports. Just two weeks ago, there were 2 threads discussing the cost of peripheral ports. I am convinced a part of this is technical. The project has not changed its policies while the number of ports was growing. While duplicated code and interfaces was okay when there were only 3 ports, it has become a pain when we have 7+ ports to updates. This weekend, I was looking at technical ways to reduce the problems, and the wx port looks like one of the issue. Everyone with whom I have discussed that today seems to agree. You said yourself As things stand, I'd not only be okay with, but actually prefer, that no other port maintainers do anything to try and fix the wx build.. The best way to achieve that and reduce the maintenance for everyone is to have the wx port developed outside the tree. Which is why I propose to do the change. To think, it was wx and GTK that started the whole WebKit porting experiment in the first place, thanks to the gracious help of the WebKit community, and particularly Eric, and now I feel like the project can't push me out the door fast enough. ;-) Please be patient, I will take care of it, but I doubt I will manage it this week. In his email WebKit Wishes, Eric said It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. I also think it is just not fair having hundred of peoples taking care of updating the port. There is no rush to move the port out of the tree. I suggested this week in order to have a definite timeline but there is no urgency. If there is interest in the wxWidgets community to make the port actively developed, that would be a great solution too. You do not have to do the change by yourself. I'd be happy to start if that helps you, and you can refine the changes. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
This entire email thread makes me sad. I'm sad because we did this to ourselves (our porting systems/policies are lacking), we did this very abruptly (the last port we kicked out of webkit.org took a year?), and we don't have any clear policy for this sort of thing (adding/removing ports in webkit.org). I think this, and many recent threads on the subject, are symptoms of the same problem: We are at a point in WebKit (and have been for a long time) where we are focused less on the Web Platform (via WebKit) being everywhere, and more on that Web Platform being awesome. Maybe it's time we clarified this in our goals doc? Our (my!) previous platform-abstraction mistakes have also left us in an awkward position where it is difficult for us to support 7+ ports with separate build systems, and separate sets of constraints (however minor) on WebCore. I think it is the right decision to de-couple all ports from the core code, but doing that is going to take us a very long time. I think that moving closer to one build system will help, but won't help those trying to advance WebCore from having to deal with 8 different port APIs, 5 different networking libraries, 2 different XML parser, 4 different GraphicsContext implementations, and countless other configuration options! I guess the point of this all is that I'm sorry. I'm sorry to Kevin, and all the other ports that I've helped integrate with WebKit, that I and others didn't sit down years ago and design better, more maintainable porting systems for WebKit. I think if we as a community are actively interested in maintaining as many ports as we have (and welcoming new ones) we need to come up with better ways to do so. And clearer policies for what it means to be a port in WebKit. In the specific case of Wx, I am reluctantly agreed that code with only one(?) maintainer is pretty close to dead and thus per WebKit's long-standing dead/commented-out code policies should be removed. :( Kevin has been with us a long time, and asking him to leave in this manner is saddening. Of course saying Wx is dead code, begs the question as to what is needed for a port to be considered live in WebKit.org? With our current porting architecture, I would argue that at least 3 full time people are probably needed, and that this should be considered before accepting new ports. I'm not in any rush to see Wx removed, and I agree it makes sense to let Kevin write the patches as much as he's willing. I think certainly having to wake up one day to see that one of your Open Source projects is kicking you out, is pretty jaring. :( I hope we can do this better next time, and maybe we should have a separate discussion about what it means to be a supported port in WebKit.org and what new/existing ports need to do to meet that bar. As for the future of WebKit on Wx: I don't know enough about WebKit2 to know if it has a more easily portable/maintainable architecture. For the port I work on (chromium), others haven't really ported in WebKit.org, but rather port at a higher level -- Chromium's Content layer or https://code.google.com/p/chromiumembedded/. Maybe one of those options are a better solution for a port like Wx with limited resources? Again, my apologies to you Kevin for my part in all this. On Mon, Feb 11, 2013 at 7:44 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Feb 11, 2013 at 6:17 PM, Kevin Ollivier kev...@theolliviers.com wrote: To be honest, I think I know more about the wx port, and would probably be better able to cleanly remove it from the tree, than you would. As I've said from the start, I'll remove it if that's what people want, but I do think the severity of this problem is being exaggerated, and going from posing the question of project status to giving a one week eviction notice in less than 24 hours seems a bit rash to say the least. I wish I could get paid good money to spend my time doing things like creating patches to remove inactive files from source trees. :) As it stands, though, this wasn't exactly on my TODO list for this week as of, say, this morning, and I do have plenty on it right now. I'm already even regretting how much time I've put into this discussion. I am sorry, I should have given more context. There is visibly a growing discontent in the community about the cost imposed from small ports. Just two weeks ago, there were 2 threads discussing the cost of peripheral ports. I am convinced a part of this is technical. The project has not changed its policies while the number of ports was growing. While duplicated code and interfaces was okay when there were only 3 ports, it has become a pain when we have 7+ ports to updates. This weekend, I was looking at technical ways to reduce the problems, and the wx port looks like one of the issue. Everyone with whom I have discussed that today seems to agree. You said yourself As things stand, I'd not only be okay with, but actually prefer, that no