Re: [webkit-dev] git.webkit.org problem
Here are some things that may help; *#1 svn server overloading when all the slaves bootstrap at the same time* The only good work around is to keep an internal read-only svn-mirror that the slaves use instead of the real svn server. This means that builds must be triggered on the svn-mirror, which may incurs a delay of a few seconds, due to svnsync polling. My hypothesis is that svn has repo-wide locks while committing, so when there are a lot of readers, they are all starved whenever some action is happening. Doing the svn-mirror trick helped us to scale in the range past *several hundreds of simultaneous active connections*. As a guidance, gclient sync does 8 svn connections per slave by default. Scale that to hundreds of slaves waking up at the same time... Also, serving the read-only svn server from a set of apache frontends helps. We do that with src.chromium.org. To be clear, above I was talking about a DMZ-only mirror. It is a different one from the apache frontends. Implementing both has the biggest benefit. *#2 Using Chromium's git svn clone of webkit* We have a few read only git frontends that are relatively speedy. I just verified and both master@HEAD matches: git remote add chromium http://git.chromium.org/external/Webkit.git git fetch chromium Once you verified that the hash matches locally with: git fetch --all git log -1 origin/master git log -1 chromium/master Then you may want to; git config remote.chromium.fetch +refs/heads/*:refs/remotes/origin/* git branch -r -D chromium/master I give no guarantee what-so-ever about freshness, lack of corruption, consistent performance, availability, YMMV, etc. Note the url has a lower K! Note that we also have WebKit_trimmed.git (note the upper case K!) that is much smaller due to removal of many files chromium developers don't need but it has invalid hashes so *do not fetch this one in your current webkit git-svn clone*. *#3 Buildbot's (absence of) performance* Stefan (cc'ed) is also looking at this and has been profiling our slowest masters for a while. In our case, we are CPU-bound and it looks like we have to tune our caching. Stefan can explain it better than me. You guys probably want to talk together. Hope this is useful, M-A Le 29 février 2012 21:50, William Siegrist wsiegr...@apple.com a écrit : We're back to the slaves overloading svn. The Apple slaves are blocked temporarily while everyone else catches up. Sorry for the inconvenience. -Bill ___ 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] cr-mac-ews
You need to use --force on automated testing. We didn't have to clobber any slave. M-A Le 5 décembre 2010 12:57, Adam Barth aba...@webkit.org a écrit : maruel mentioned something about command-line flags we can pass to gclient to make it more robust. Adam On Sun, Dec 5, 2010 at 9:49 AM, Dimitri Glazkov dglaz...@chromium.org wrote: You need to rm -rf /Projects/CrMacEWS/WebKit/chromium/third_party. We had to do the same for build.webkit.org builders this week. You're right, the dependency management -- the underlying cause of all cr-specific build pain -- has gotten pretty hairy. :DG On Sat, Dec 4, 2010 at 5:39 PM, Eric Seidel e...@webkit.org wrote: Has been broken for days. http://queues.webkit.org/queue-status/cr-mac-ews Any thoughts from Chromium peeps how it's supposed to be fixed? We seem to be having increasing trouble keeping the Cr EWS bots running w/o hand-holding. -eric ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How can I stop getting buildbot ChromeOS failure mails?
We found who started the master and shut it down so this has been fixed, I'm really sorry about the spam and will make changes so nobody can make this spam again (+ a filter on non chromium/google email addresses). M-A Le 4 août 2010 13:17, Darin Adler da...@apple.com a écrit : I got a large mail that started with this: http://build.chromium.org/buildbot/chromiumos/ Automatically closing tree for build image on x86 slab full I don’t want to receive these mails. I don’t understand them. They are full of hex numbers that probably relate to git and check-ins in Chromium and I don’t work on that project. And I have no idea who to write to since the mail comes from nob...@example.com. -- Darin ___ 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] [webkit meeting notes] build systems
2010/4/21 Kevin Ollivier kev...@theolliviers.com Hi Marc-Antoine, On Apr 18, 2010, at 10:47 AM, Marc-Antoine Ruel wrote: 2010/4/17 Kevin Ollivier kev...@theolliviers.com Hi Marc-Antoine, On Apr 17, 2010, at 11:26 AM, Marc-Antoine Ruel wrote: Like this? http://trac.webkit.org/browser/trunk/WebCore/WebCore.gypi - It is currently not JSON compliant. It's in fact a python file but that can be fixed: s/'//g and removing the extra commas *should* be sufficient. BTW, there is no way to make it JSON-compliant after all. Sorry for the misleading comment. mac, qt, gtk, wx, symbian and even some JSC files are listed. I'm 100% sure the lists aren't complete and I'll need to fix them along the way, especially JSC stuff which *is* a show stopper. .gypi files are header files. They can be imported by other .gypi or a .gyp file. Each .gyp file will generate a .sln, .xcodeproj, Makefile or SConstruct, depending on the selected build system. Each target inside a .gyp will generate a .vcproj or .scons. The regex logic lives in inside sources entries inside a target. You can have a list of file names, 'include' or 'exclude' with an array of regexp. Please take a look at the very bottom of this file for an example: http://trac.webkit.org/browser/trunk/WebCore/WebCore.gyp/WebCore.gyp May I ask why it is being done this way, that is, having one really large list of build files and using include / exclude regexs to trim the list? i.e. why is there not a WebCoreCommon.gypi, WebCoreWinCommon.gypi, WebCoreChromium.gypi, etc.? Are you guys using scripts to create WebCore.gypi? We do that for chromium, it already to support different platforms so I guess since there was already regexp done, these were simply reused. A good question, cc'ing people more knowledgeable than me. Anyway, the fact that this file is actually Python (I had forgotten the format was JSON-like rather than straight JSON) makes things even better, as we only really need to handle export now, and not parse some import file list. i.e. for WebKitTools/Scripts/update-sources-list.py, getWebCoreFilesDict() basically becomes a very small script that execfile's the gypi file, then we run whatever filtering mechanism on it (waf has a list of ports we could use to do the filtering that I could probably move into WebKitTools/Scripts, if we don't have a pre-made Chromium solution here), and then passes the final source list along to generateWebCoreSourcesGTKandQT to generate the sources / includes for those platforms, and actually this solution should work for Android.mk and possibly jam too, as their syntax looks largely similar. Then we'd add some XML parsing code to grab the node for common file groups and update them for the MSVC projects, and then I think that mostly leaves XCode, which I think would be pretty similar in nature. For MSVC and XCode, it makes more sense to use the native gyp support since it makes really clean projects. FYI, VS2010 is not supported for now. Yes, if all MSVC and XCode projects are planning to switch over anyway, it's probably not worth bothering with. Though if some choose not to, we could actually re-use the chunk of Gyp code that creates the file lists and just inject that into the project file. Whatever works for people and is implemented. -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
2010/4/20 par...@paroga.com On Tue, 20 Apr 2010 10:53:55 -0700, Peter Kasting pkast...@google.com wrote: AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio to correctly understand dependencies itself so that incremental builds from inside the IDE (which is where most Windows Chromium developers do their builds) work correctly and are as fast as possible (e.g. the null build should take close to zero time and not have to rerun steps or relink executables). I have an other big project running with CMake, but I didn't see such a problem. When you declare the correct dependencies CMake does a nerly perfect job IMHO. No rebuild time when nothing changed and no outdated objectfiles. Are the sources under an open source license? I'd like to take a look if so. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
2010/4/17 Kevin Ollivier kev...@theolliviers.com Hi Marc-Antoine, On Apr 17, 2010, at 11:26 AM, Marc-Antoine Ruel wrote: 2010/4/17 Kevin Ollivier kev...@theolliviers.com Hi Maciej, On Apr 16, 2010, at 3:34 PM, Maciej Stachowiak wrote: On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. Besides adding, removing and renaming, the other thing that's really hard is adding a new generated source rule. Although this is not needed as frequently, I think anyone adding a new code generator script that has to work across all WebKit ports would have a hellish time of it right now. If I had to do it myself, I would just skip any ports that don't use DerivedSources.make. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $$SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. I think the proposal above does not handle the derived sources problem. It also doesn't handle files that are shared between multiple ports but not all ports. It also doesn't provide project files that are directly usable by IDEs, on platforms where that is the standard way to do development. Converting, say, a JSON list of files to some XML-based output format would not be difficult at all (and I Like this? http://trac.webkit.org/browser/trunk/WebCore/WebCore.gypi - It is currently not JSON compliant. It's in fact a python file but that can be fixed: s/'//g and removing the extra commas *should* be sufficient. - It is currently chromium specific, that's what I meant by de-chromification of the gyp files. It's mainly adding more stuff and fixing the regexp if I'm not mistaken. I don't mind if it doesn't become the golden file, the goal is just to hopefully reduce the number of build system, nothing more. Yes, precisely why I mentioned JSON and later gyp, though I don't know if Chromium-specific is the right word here. It even has wx port files in it, which I don't think are built by Chromium. :) I suppose you somehow filter out which ones Chromium should build after the fact? If so, where does that logic reside? mac, qt, gtk, wx, symbian and even some JSC files are listed. I'm 100% sure the lists aren't complete and I'll need to fix them along the way, especially JSC stuff which *is* a show stopper. .gypi files are header files. They can be imported by other .gypi or a .gyp file. Each .gyp file will generate a .sln, .xcodeproj, Makefile or SConstruct, depending on the selected build system. Each target inside a .gyp will generate a .vcproj or .scons. The regex logic lives in inside sources entries inside a target. You can have a list of file names, 'include' or 'exclude' with an array of regexp. Please take a look at the very bottom of this file for an example: http://trac.webkit.org/browser/trunk/WebCore/WebCore.gyp/WebCore.gyp The main gyp caveat is some of its shortcut notation like /, ! and +++. Please see the documentationhttp://code.google.com/p/gyp/wiki/InputFormatReferencefor more info if interested. WebCore.gyp already brings a lot of conditions which can make the whole thing messy as the number of platforms increases but these can be moved off individual .gypi files to keep the whole thing bearable. In the end, it may even not make sense to share the gyp files accross platform if they don't share enough build logic, it's no big deal as long as people can add and remove files easily. BTW, I don't why WebCore.gypihttp://trac.webkit.org/browser/trunk/WebCore/WebCore.gypilists the idl, svg idl, source files, webinspector and images as individual lists since they all have
Re: [webkit-dev] [webkit meeting notes] build systems
2010/4/17 Kevin Ollivier kev...@theolliviers.com Hi Maciej, On Apr 16, 2010, at 3:34 PM, Maciej Stachowiak wrote: On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. Besides adding, removing and renaming, the other thing that's really hard is adding a new generated source rule. Although this is not needed as frequently, I think anyone adding a new code generator script that has to work across all WebKit ports would have a hellish time of it right now. If I had to do it myself, I would just skip any ports that don't use DerivedSources.make. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $$SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. I think the proposal above does not handle the derived sources problem. It also doesn't handle files that are shared between multiple ports but not all ports. It also doesn't provide project files that are directly usable by IDEs, on platforms where that is the standard way to do development. Converting, say, a JSON list of files to some XML-based output format would not be difficult at all (and I Like this? http://trac.webkit.org/browser/trunk/WebCore/WebCore.gypi - It is currently not JSON compliant. It's in fact a python file but that can be fixed: s/'//g and removing the extra commas *should* be sufficient. - It is currently chromium specific, that's what I meant by de-chromification of the gyp files. It's mainly adding more stuff and fixing the regexp if I'm not mistaken. I don't mind if it doesn't become the golden file, the goal is just to hopefully reduce the number of build system, nothing more. believe we can automatically convert the XCode project files from binary to plist and back, though IIRC there might be some UUID handling issues to consider), so we could patch the IDE files much like we patch the other ports. As for the other cases, such as additions / removals of things shared by multiple ports and the derived sources problem (that one probably would indeed need some 'template' to insert into project files), I think these could be added over time if we feel it'd bring a large benefit, but I think even just covering the common case of cross-platform source file maintenance is already a huge win for the project. I maintained Bakefile projects for years, and I'd say 80-90% of the time when a change broke my build, it was one of these common source file additions / removals. And it usually happened several times every week. I personally think the way to look at it is to start by solving the simple stuff that could be solved quickly, as in my experience that makes it far more likely to actually get done. If, say, gyp - Gtk / Qt / MSVC (/ XCode?) build file lists could be done in a weekend of hacking and some devs are interested in working on it, why not? Once we start solving problems like that, I suspect we end up with something closer in complexity to Gyp or CMake. True, but I think the real problem that we're not addressing in this discussion is that different ports have different sets of requirements, meaning their own evaluation process would lead them to choose different tools. If we want a 'one size fits all' build system, the first step is getting each port to come together and I don't think anyone wants that. It's just too involved. consolidate the requirements, and there will most likely need to be some compromises involved as some ports may have to agree to move to a tool that's not really as well suited for their project as the one they're using now. For example, a
Re: [webkit-dev] [webkit meeting notes] build systems
Please guys, No need to speculate here on what I proposed at the session since Evan somehow left some details out and let me reinforce some points. For those who missed the session, please understand that what's Peter said isn't exactly what we agreed on. Here's some data points: - No plan to generate qtmake or makefile.am or whatever else - No plan to force anyone to switch - No plan (for now) to get any automatic file list for the checkout (some build system do that) - No plan for any template based project generation - Making a new fully functional backend to gyp *is* involved. It's a big deal. There's no use in a 95% done build system. The rough proposal is: - De-chromify most .gyp and .gypi files currently living in webkit.org, split the files off as necessary in the process to untangle conditions. - With coordination with aroben, look at implementing a faithful copy of apple's win port, with a potential switch over *if it works out*. No guarantee. - Some people expressed interest into generating the file list to their build system and having the build system import the generated project files. That wouldn't be a complete backend implementation. Obviously, complete backend implementation at http://code.google.com/p/gyp are welcome as long as they have unit tests. What you can do *only if you want*: - Extract the file list of your port project into a single simple file and have your build system import this file. I'm not talking about pushing anyone's back and I have *no intention* to. So unless you want to actively submit patches towards the proposal, please let this thread die, it's an unproductive use of my time. I don't plan to do that in the very short term as I have other things on my plate, I'll definitely do this incrementally. M-A 2010/4/16 Peter Kasting pkast...@google.com On Fri, Apr 16, 2010 at 8:42 AM, Kevin Ollivier kev...@theolliviers.comwrote: Perhaps, but in any case, I think the first step there is for the Gyp developers to try implementing support and see how it goes. However, from that perspective, until Gyp has support for those formats, isn't a discussion about switching for other ports a bit premature on the WebKit side? i.e. that would be next steps for Gyp, not next steps for WebKit. I'd think Gyp would implement support for those formats and then come here and ask people to consider a switch. Which is basically what we're proposing here. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
2010/4/16 Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de Am 16.04.2010 um 19:14 schrieb Marc-Antoine Ruel: Please guys, No need to speculate here on what I proposed at the session since Evan somehow left some details out and let me reinforce some points. For those who missed the session, please understand that what's Peter said isn't exactly what we agreed on. What you can do *only if you want*: - Extract the file list of your port project into a single simple file and have your build system import this file. I'm not talking about pushing anyone's back and I have *no intention* to. So unless you want to actively submit patches towards the proposal, please let this thread die, it's an unproductive use of my time. I don't plan to do that in the very short term as I have other things on my plate, I'll definitely do this incrementally. This thread is not only about what you may have proposed in the meeting. Please reread the other mails of the thread. I'm really a bit astonished, reading statments like your last sentences above. It's not very polite to state you don't care about other opinions and call that an unproductive use of your time. Cheers, Niko Sorry, I didn't mean to be blunt but we did wear the PM hat and decide AI at the session. Chromium folks did look at CMake in the past, I'll add comments related to this build system to the other thread. -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Thanks Nico for digging up the archive. As I said in the other thread, the people at the session mostly looked about reducing the number of build system, not forcing anyone to use any tool. If some teams wants to switch to CMake, prefect as long as the number of build tool reduces. Nobody seemed willing to switch to qtmake. Nobody at the meeting advocated for CMake. I don't have first-hand experience about CMake but from I only heard midly negative comments. The generated xcodeproj and vcproj are far from 'native' and from f2f discussion, at least one llvm guy isn't happy about CMake and would rather move it off. The 'native' IDE feel was very high in our priority list, especially in XCode in fact. 2010/4/16 Adam Treat tr...@kde.org On Friday 16 April 2010 09:58:17 pm Bill Hoffman wrote: Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. To be clear, it just has to be in the path, right? Which I think could be managed ;) I don't know if anyone really cares about the requirement of having another tool installed on the system or not as an hinderance, I don't mind. So in the end, if some team want to switch to CMake, just check-in stuff. :) Not that my opinion counts at all. -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] ReviewTool
https://trac.webkit.org/wiki/ReviewTool There was a fair level of interest but apparent lack of empowerment. :) As Darin Alder said, bugzilla is basically a perl web application so it's easy to plug in modules to add functionality. In contrary, a brand new review tool is definitely a daunting task, caveats must be explicitly understood first. M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] minimum python version to support
FYI, Chromium folks on Windows will be on python 2.6 real soon(tm). The CL to bug them to upgrade should be committed within the next few minutes. [Thread hijack] If you're not a Chromium-Webkit committer running on Windows, please ignore the rest of this email. Otherwise, please del depot_tools\python.bat and run gclient. Thanks, M-A 2010/3/19 Adam Barth aba...@webkit.org: Awesome! /me goes and comments on the bug. Adam On Fri, Mar 19, 2010 at 9:57 AM, Chris Jerdonek cjerdo...@webkit.org wrote: Mechanize (and ClientForm on which it depends) does work with Python 2.4: http://wwwsearch.sourceforge.net/mechanize/ (See the section on compatibility.) On Fri, Mar 19, 2010 at 9:19 AM, Adam Barth aba...@webkit.org wrote: My understanding is that some of the libraries we use, like Mechanize, don't work in Python 2.4. My complaint in Bug 36063 is that we're re-implementing Mechanize poorly. I'd rather we just upgraded the machines that need to run-webkit-tests to a more modern version of Python. Adam On Fri, Mar 19, 2010 at 7:41 AM, Chris Jerdonek cjerdo...@webkit.org wrote: No one responded back with a summary of the Python 2.4 discussion, so I'll attempt a summary of my own after reading-- https://bugs.webkit.org/show_bug.cgi?id=35584 (If you recall, we are trying to decide what Python code we write needs to work with Python 2.4.) The Chromium project still uses Python 2.4 in a significant way. Some Chromium bots run new-run-webkit-tests using 2.4, and a number of developers use 2.4 in their development environments. Generally speaking, people support upgrading, but no one is spearheading an upgrade and there is no ETA. For the time being, because of the bots, it seems like new-run-webkit-tests definitely needs to keep working with 2.4. But for the tools used more in the development environment (webkit-patch, etc), it seems like people would be willing to find a way to make things work with 2.5+. It would be pretty easy to get all of our Python code working with 2.4 (we had a patch for this a couple weeks ago), but going back wouldn't let us use some of the nicer constructs. And we would have to contend with at least one bug in 2.4. (End of summary.) Plainly, the options seem to be-- (1) All Python 2.5+ (2) All Python 2.4 (3) Some combination of (1) and (2) (e.g. new-run-webkit-tests 2.4, everything else 2.5) However, (1) does not seem to be an option. Personally, I'm starting to lean more toward to (2). One reason is that we are already starting to see a case of re-implementing in Python 2.4 (for new-run-webkit-tests) code that was already written in 2.5: https://bugs.webkit.org/show_bug.cgi?id=36063#c4 I also think it would be helpful if we did not need to have this discussion for each new script we decide to write in Python. I would be willing to update the patch from a couple weeks ago that adjusts things for 2.4. --Chris On Sun, Mar 7, 2010 at 4:18 PM, Chris Jerdonek cjerdo...@webkit.org wrote: On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer ddkil...@webkit.org wrote: On Thu, March 4, 2010 at 5:35:08 PM, William Siegrist wrote: Since I have a Tiger machine handy, I tested this and was able to build python 2.5.5 from MacPorts on a PowerPC. It takes a while, but it worked. I did not try python 2.6. I've installed python 2.6.4 using MacPorts on my PowerBook G4 running Tiger 10.4.11, and it's worked find with webkit-patch the one or two times I tried it. That sounds great. Thanks a lot, Dave and Bill. So does it seem safe to say, then, that folks on 2.3 can upgrade if it ever becomes necessary to use one of the tools? As for Python 2.4, I haven't been following the discussion as closely since it seems to affect Chromium developers more. Can someone summarize the state of the discussion there -- does it seem like there is a consensus? --Chris ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building Win32/Release WebKit: linker error LNK1106
You didn't say on what flavor. I assume you are doing a release build. If so, you probably need a x64 OS to link the static library. You may want to install a few hotpatches from Microsoft, http://dev.chromium.org/developers/how-tos/build-instructions-windows lists a fews in addition to the ones listed at http://webkit.org/building/tools.html. This is especially necessary with the SDK 7 + VS2005 configuration. Also, you may be interested in the workaround listed at http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=521439 In short; use /expectedoutputsize:12000 M-A 2010/1/25 wupei pei...@archermind.com: Hi,All: I am trying to build WebKit-r53371 on windows. But now i am blocked with this error when build the webcore project: Performing Pre-Link Event... Creating library... C:\cygwin\home\wupei\WebKit-r53371\webkitbuild\lib\WebCore.lib : fatal error LNK1106: invalid file or disk full: cannot seek to 0x5254F4AC Project : warning PRJ0018 : The following environment variables were not found: $(PRODUCTION) $(DXSDK_DIR) When I monitored the webcore.lib in the disk space, when Creating library... is in progress, WebKitBuild/lib/WebCore.lib is created and rapidly grows from a couple of megs to 128M, then to 256M, and at last to 512M, 1G. After LNK1106 error is displayed, the file is removed. Frist, The disk has more than 10GB free space when build the webkit, so I think it isn't because of the free space. Second, I have seen the Bug 19743 - Release build fails on 32-bit Windows (https://bugs.webkit.org/show_bug.cgi?id=19743), but my version is newer than the bug fixed one. Third, I have done update-webkit before build-webkit. And I also seen someone met the same problem in the network, but I can't search the solution. Dose anyone meet the same problem and have solved it? Will be appreciated for any comments. WuPei ___ 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] Plugin Printing Behavior
On Fri, Dec 18, 2009 at 1:51 AM, Brent Fulgham bfulg...@gmail.com wrote: I've recently written an in-house NPAPI plugin for use with WebKit in an application I'm working on. One of the primary functions of this tool is to generate printed output, so naturally I was dismayed to discover that my plugin's NPP_Print implementation was not getting called during WebKit page print operations. So, the bulk of the page prints fine, leaving a big blank rectangle where the plugin should be. I attempted to test printing of production quality plugins (Adobe Acrobat Reader, Flash, SWF, and Quicktime) on Windows using Safari, Chrome, and Firefox as well as Safari on the Mac. Adobe's PDF plugin does not produce printed output on Windows in Safari or Google Chrome, but does seem to work on the Mac. Firefox seems to work on Windows as well. I'm not that surprised that the video plugins produce no print output, but did not have any other installed plugin examples to choose from. Before I exert too much effort trying to reduce this to a reasonable test case, I was wondering if this was a known issue. I didn't see much in Bugzilla, though I must admit to not spending more than a few minutes running queries. The closest I could find was a bug from 2007 related to display of PDFs in Safari, which isn't quite the same as my problem. If anyone else is aware of this issue, please let me know. Otherwise I'm going to see if I can track down the issue. Thanks, -Brent I spent a significant effort on getting plugin printing working on Google Chrome in early 2008 for the windows port. Please forgive me if there is factual errors on the following. At the time, Safari wasn't printing plugins either. First, a small recall about how Firefox and IE print: If we compare Firefox3.0 to IE7 on Windows, Firefox is getting better plugin printouts than IE. Why? Because it's doing vectorial based drawing, like flash charts, are rendered vectorially in NPP_Print. In IE, surprisingly, a bitmap screen shot is taken instead. Firefox is handing out the printer device context handle(HDC) directly to the plugin for it to render so the GDI calls are done in at the right resolution. Let me explain the Google Chrome and Windows-specific situation: In our case, the plugin runs in a separate process so it doesn't have access to the actual HDC. So there is two remaining ways: - Take a display snapshot, ala IE7, with NPP_HandleEvent + WM_PAINT into a EMF metafile HDC. - Create a EMF metafile HDC for it to print into and hand it to NPP_Print. The main issue is that I wasn't able to get consistent results with an EMF metafile. If I take Flash as an example, it has some expectation when querying the device context that the EMF buffer doesn't fulfill. The EMF HDC doesn't have margins or anything like that. I tried faking them with clipping rect but that didn't work; this created drawing elements going out of the plugin rect, like a line going all over the page, or shifted rendering in one or two axis by roughly a paper margin. I don't recall why I ditched the display snapshot implementation, I recall having the implementation done but recall some issues with it. Since Safari wasn't printing plugins either, which means the webkit code paths weren't exercised, I decided to go the safer route by disabling it altogether. Hope this sheds some light on the challenges. M-A PS (not to you specifically): patches are welcome :) http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/webplugin_delegate_stub.cc?revision=34596view=markup still has a OnPrint implementation. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: Whitespace changes
On Thu, Aug 27, 2009 at 4:28 PM, Darin Fisherda...@google.com wrote: On Thu, Aug 27, 2009 at 1:18 PM, Eric Seidel e...@webkit.org wrote: On Thu, Aug 27, 2009 at 11:55 AM, Peter Kasting pkast...@google.com wrote: Maintaining a cultural attitude that is widely positive towards cleanup makes people feel less reticent about cleaning up, and taking ownership of, code; frowning on certain types of cleanup makes people less likely to do _any_ cleanup. +1 I'd love to have perfectly style conferment code at the cost of a few extra svn revisions. For this particular change: http://trac.webkit.org/changeset/47808, I wasn't aware we had a policy regarding trailing whitespace. It seems such a policy will be hard to keep since XCode doesn't support removing trailing whitespace. :( -eric commit hook :) presubmit check [trolling alert] I wonder if people complaining about svn blame being noisier are the same that complains about ChangeLog... :P M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building release on Windows Vista
One workaround is to use a x64 OS to increase the available address space. On Fri, Aug 21, 2009 at 12:19 PM, Yong Liyong...@torchmobile.com wrote: I guess you've enabled link time optimization. The lib file is too big. The solution suggested by MS is to split the project. - Original Message - From: Anton Muhin ant...@chromium.org To: webkit-dev Development webkit-dev@lists.webkit.org Sent: Friday, August 21, 2009 12:03 PM Subject: [webkit-dev] Building release on Windows Vista Dear WebKit gurus, is it possible to build WebKit on Windows Vista in Release configuration? Both build from Cygwin and VS dies with: c:\WebKit\WebKit\WebKitBuild\lib\WebCore.lib : fatal error LNK1106: invalid file or disk full: cannot seek to 0x44DA4146 Clean build (wiping off WebKitBuild) has been tried. I git clone'ed rather recent version of WebKit (something two or three hours long from the time this message has been sent). Debug could be built fine from cygwin. Any hints are most appreciated. tia and yours, anton. ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Chrome build bot
An hypothetical chromium builder should sync to http://chromium-status.appspot.com/lkgr instead of HEAD. That'd fix most of the builder failed to compile because chromium tree is broken. lkgr stands for *last known good revision* in its weakest meaning. If curious, more info at http://dev.chromium.org/developers/try-server-usage#TOC-LKGR M-A On Tue, Jul 7, 2009 at 2:11 PM, Darin Fisher da...@chromium.org wrote: We are working on it. It is taking more time than we'd like :-( For now, we only have an integration builder that tests tip-of-tree WebKit in a Chromium build environment: http://tinyurl.com/l9mops That's a big help to Chromium developers, but it isn't something well suited for the WebKit community since it may turn red due to non-WebKit related changes. Thanks for thinking of us! -Darin On Tue, Jul 7, 2009 at 8:56 AM, Eric Carlson eric.carl...@apple.comwrote: Chrome hackers - When do you plan to have a build bot on build.webkit.org? I broke your build yesterday with http://trac.webkit.org/changeset/45572, but didn't realize it so Albert had to clean up after me (again, thanks Albert). I *try* not to break other builds but the media element backends are, by definition, platform specific it is easy to miss something. I always watch the build bots after a check-in so I can fix things, but that doesn't help me with your builds. eric ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [win] VS2008? (was: Building WebToolKit)
FYI, Chromium port of webkit builds fine with VS2008. I'm pretty sure it would be trivial for other ports. Did you try fixing the build script by yourself? M-A On Wed, Apr 1, 2009 at 2:47 AM, Thomas Brodt thomas.br...@porabo.ch wrote: BTW: How are the chances that VS2008 will be supported somewhen in the future? Are there any plans? Or is it a greater challenge to do that? I'm not a genuine C++ developer, so I'm pretty clueless about that. The reason behind that question: Microsoft has announced that support and download availablity for the VS2005 version is stopped as of today. And I have 2008 already installed because of another project. Thomas Angrez Singh schrieb: Thanks Adam for your reply Yes, that sounds like a good change to make. Would you be willing to file a bug at http://webkit.org/new-bug (and maybe even make a patch)? I'll file the bug, I can create the patch but it will take some time as I haven't worked much with perl. Regards, Angrez ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: Getting more buildbots green
Idea One of the advantages of keeping the tree green is to enable the implementation of a try server. We've been using that for a while and even with its caveat, it's particularly useful when multiple platforms are supported by a code base. You can see it in action there: http://build.chromium.org/buildbot/try-server/waterfall How we use it When someone uploads a patch to our code review toolhttp://codereview.chromium.org/with gcl.py, it also implicitly calls trychange.py to send it to the try server. The try server has 2 communication methods, a svn server to hold the .diff files (which enable access control and logging) or direct HTTP connection (a bit faster). Try jobs can also be manually called. In webkit's case, it'd look like this: trychange.py --url https://bugs.webkit.org/attachment.cgi?id=26067 --patchlevel 1 It then sends back an email for each platform with the equivalent waterfall strip for the build. I attached an example at the end of this email. Sources The try server master.cfghttp://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/config/master.tryserver/ and its related scriptshttp://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/ . trychange.py, gcl.py and gclient.pyhttp://src.chromium.org/viewvc/chrome/trunk/depot_tools/src/release/ . gclient needs to be used to do a functional try server checkout. (sorry) The commands are: gclient config http://src.chromium.org/svn/trunk/tools/buildbot/config/master.tryserver/ gclient sync Our code review tool sourceshttp://rietveld.googlecode.com/svn/branches/chromium/. Not directly related, just FYI. Applied on webkit In the webkit case, we could probably extract something much simpler. It doesn't need gclient, gcl or the code review tool. Only something similar to trychange.py and the try server scripts. I attached a sample try result email. M-A CUT HERE http://build.chromium.org/buildbot/try-server/ TRY FAILED http://build.chromium.org/buildbot/try-server/builders/win/builds/1106 win Build 1106http://build.chromium.org/buildbot/try-server/builders/win/builds/1106 'maruel: disconnect' try job svnkill stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/shell/logs/stdioupdate scripts stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/shell_2/logs/stdiotaskkill stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/shell_3/logs/stdioupdate patchhttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/gclient/logs/patch stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/gclient/logs/stdio compile stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/compile/logs/stdioStart Crash Handler stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/Start%20Crash%20Handler/logs/stdioipc_tests stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/ipc_tests/logs/stdioinstaller_unittests stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/installer_unittests/logs/stdiounit_tests 13 disabled stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/unit_tests/logs/stdiodebugger_test stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/debugger_test/logs/stdioui_tests crashed or hung stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/ui_tests/logs/stdiotest_shell_tests 1 disabled stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/test_shell_tests/logs/stdio base_unittests 1 disabled stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/base_unittests/logs/stdionet_unittests 9 disabled stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/net_unittests/logs/stdiomedia_unittests stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/1106/steps/media_unittests/logs/stdio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Re: WebKit graphics
Hi Alp, About bug 16095 http://bugs.webkit.org/show_bug.cgi?id=16095, you wrote: « The added feature seems unusable since, even if the classes are subclassed, there is still static code instantiating the base class in GraphicsContext. In light of this, I think this patch is incomplete or wrong. » The thing is that GraphicsContext is never subclassed but specialized Cairo, CG, Qt, Wx, etc. Every specialization have this kind of constructor: --- GraphicsContext::GraphicsContext(PlatformGraphicsContext* context) : m_common(createGraphicsContextPrivate()) , m_data(new GraphicsContextPlatformPrivate) --- What this patch intends to do is to remove the need of m_data (at least for most platforms) since the constructor could implement a subclass of GraphicsContextPrivate (not GraphicsContext!), set the pointer in m_common and not need a second memory allocation (m_data). I hope it clears things up. M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
