Re: [webkit-dev] MD5 in WebCore
Thanks for suggestion.
I'll add MD5 implementation in WTF, based on chrome's base/md5, which seems
came from sqlite public domain code. I believe this would be a
platform-independent implementation.
--
ukai
On Wed, Apr 21, 2010 at 04:58, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2010, at 11:48 AM, Michael Nordman wrote:
In webcore, should we use the same impl on all platforms rather than use
cryptdll on windows and md5.cc elsewhere?
For chrome, I don't think we can have a dependency between
WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
doesn't work. How can we avoid replicating the code? I guess having
webcore's MD5 be platform specific could help us along those lines?
I'd rather use a platform-independent MD5 implementation in WebCore if
possible.
Since the MD5 code itself has (presumably) minimal dependencies, perhaps we
could put it in WTF. I don't know if that would help Chromium's dependency
issues.
Regards,
Maciej
On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
I'm implementing new protocol of WebSocket (
http://www.whatwg.org/specs/web-socket-protocol/ ).
Since it now requires MD5 in handshake, I wonder how I could add MD5 in
WebCore. For now, there is no MD5 in WebCore. It is in
WebKitTools/DumpRenderTree to get message digest of image file.
I'm thinking to add new header file as WebCore/platform/MD5.h, which
provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
In Windows platform, it is implemented using Cryptdll.dll. Is it ok to
copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
or move?
In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
#define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this in
WebCore/platform/chromium, or add dependency to base from WebCore?
How about other ports? is it ok to link openssl or some other library?
(or use implementation used in chromium?)
I'm also wonder I need to put these functions in namespace WebCore.
If you put this code in WebCore, it should go in the WebCore namespace. I
think it would also be a good idea to turn the API into something more
WebCore-ish, something like:
namespace WebCore {
class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
or maybe this should take a Vectoruint8_t?
Vectoruint8_t, 16 checksum(); // what was MD5_Final
};
}
(The key point being to match the coding style guidelines for names, but
it also seems better to use a class here instead of a struct and functions
that take a pointer to it.)
Regards,
Maciej
___
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] Is it possible to use gordon in webkit ?
Hi all, gordon is An open source Flash™ runtime written in pure JavaScript mre details are available here:http://wiki.github.com/tobeytailor/gordon http://wiki.github.com/tobeytailor/gordon/I wonder whether is it possible to make webkit use it to play swf files. regards. Haithem. -- Say: He is God, the One and Only; God, the Eternal, Absolute; He begetteth not, nor is He begotten; And there is none like unto Him. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is it possible to use gordon in webkit ?
Hi all, It seems that the gordon demos links @jancona.com are not working here you find some working ones. http://paulirish.com/work/gordon/demos sorry for the inconvenience regards. On Wed, Apr 21, 2010 at 10:05 AM, Ted Wood coolfac...@mac.com wrote: Did your posting of this crash the demo site for Gordon (at jancona.com)? It's not loading. ~Ted On 2010-04-21, at 12:42 AM, haithem rahmani wrote: Hi all, gordon is An open source Flash™ runtime written in pure JavaScript mre details are available here:http://wiki.github.com/tobeytailor/gordon http://wiki.github.com/tobeytailor/gordon/I wonder whether is it possible to make webkit use it to play swf files. regards. Haithem. -- Say: He is God, the One and Only; God, the Eternal, Absolute; He begetteth not, nor is He begotten; And there is none like unto Him. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Say: He is God, the One and Only; God, the Eternal, Absolute; He begetteth not, nor is He begotten; And there is none like unto Him. ___ 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] [webkit meeting notes] build systems
On Wed, Apr 21, 2010 at 9:23 AM, Marc-Antoine Ruel mar...@chromium.org wrote: 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 did this to optimize for writes (http://diveintomark.org/archives/2007/12/28/receipts). With one file, it's a no-brainer to add new files to the build. The maintainers of the ports can then use regexps and explicit lists to exclude builds as needed. It's worked pretty well for us. :DG ___ 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] CMake vs. Apple's build farm
Can someone from Apple comment on whether it is possible to include the sources to CMake and then the CMake could bootstrap itself with only dependency on the compiler? This would seem an acceptable solution, no? Adam On Tuesday 20 April 2010 01:06:43 pm Bradley Nelson wrote: Would prebuilt checked-in binaries be an option? Can cmake run out of an arbitrary directory? -BradN On Tue, Apr 20, 2010 at 5:25 AM, Bill Hoffman bill.hoff...@kitware.comwrote: On 4/20/2010 5:13 AM, Maciej Stachowiak wrote: 1) None of the Mac builders have CMake installed. 2) The organization that maintains the Mac builders is not willing to let teams use any build systems to build that do not come with the OS, or to install any custom binaries on the builders, because builds need to be reproducible. So, long term is there a way for CMake to come with the OS? I mean gmake is part of the OS, python seems to be OK, how does a tool get promoted to such a level? 3) CMake is not part of the standard Mac OS X install for any shipping version of Mac OS X. 4) LLVM compiles using a separate Makefile-based (and apparently autoconf and autogen based) build system in OS builds. 5) LLVM uses CMake to build on Windows. 6) The build organization is more willing to install custom tools on Windows builders. I think this rules out using CMake to build the mac port. Even if we got it set up, we'd need to maintain some kind of parallel build system for production builds via the build farm, which would negate the benefit. It might be possible to use CMake for Apple's Windows port, but if we switch away from native project formats at all, ideally we'd like to switch both ports to the same build system. I am wondering if you could include the sources to CMake inside the source tree for the Mac build farms. CMake really only depends on the C++ compiler, and that is part of the OS. You could use CMake's bootstrap script to build it. Then run that CMake to generate the build. I could help you create a lean CMake that would only build the features used for the build of WebKit. Since gyp does not require any special software to be installed merely to build, it seems like a more plausible option at the moment. Note: this is not to hate on CMake, I just don't want to end up in a position where we have to maintain two parallel build systems for the Mac port, or fight with other organizations about the operation of the build farm. Requiring CMake to be installed at build time seems like a showstopper from that point of view. So, rather than install one program, Apple would rather have one of its developers maintain a forked build system. I would of course like to see this change. I would think it would be possible to change this. I suppose if enough tools that Apple uses move to CMake, it would become OK. Anyway, what do think about building CMake with the project? -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] CMake as a build system?
On Wed, 21 Apr 2010 12:36:17 -0400, Marc-Antoine Ruel mar...@chromium.org wrote: Are the sources under an open source license? I'd like to take a look if so. I'm sorry, they are closed source. :-( But I have working CMake files for JSC on Windows already. I'd like to clean them up an try to get them run on other platform too before I post a patch at bugs.webkit.org. If you can't wait, I can send you my current files. You can see there for example how the the additional build steps like bison, hashtable generation, ... work. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake vs. Apple's build farm
On Apr 21, 2010, at 9:45 AM, Adam Treat wrote: Can someone from Apple comment on whether it is possible to include the sources to CMake and then the CMake could bootstrap itself with only dependency on the compiler? This would seem an acceptable solution, no? Hard to comment on something that’s hypothetical, but given the high level description, it’s not impossible. Part of this depends on the license for CMake. And it will be a lot of work for someone at Apple. The platforms where this sort of thing is most difficult are older ones where WebKit is built with old versions of development tools. Even small changes to the build system create challenges for my team here at Apple. We do our best to hide this complexity and prevent it from directly affecting the others working on WebKit. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake vs. Apple's build farm
CMake is BSD style license so I don't think that is a problem. I understand that a lot of this is hypothetical and the last thing we want is to make life more difficult for our developers. I'm just trying to understand up front whether or not there are legitimate show stoppers before people go through a lot of effort trying to convert Apple's Windows port to a CMake build for demo. Adam On Wednesday 21 April 2010 02:24:26 pm Darin Adler wrote: On Apr 21, 2010, at 9:45 AM, Adam Treat wrote: Can someone from Apple comment on whether it is possible to include the sources to CMake and then the CMake could bootstrap itself with only dependency on the compiler? This would seem an acceptable solution, no? Hard to comment on something that’s hypothetical, but given the high level description, it’s not impossible. Part of this depends on the license for CMake. And it will be a lot of work for someone at Apple. The platforms where this sort of thing is most difficult are older ones where WebKit is built with old versions of development tools. Even small changes to the build system create challenges for my team here at Apple. We do our best to hide this complexity and prevent it from directly affecting the others working on WebKit. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JSC String re-factorings are hosing the tree.
A large portion of the tree redness in the last 3 days is due to JSC string re-factoring. We need to build some better tools, or find some better method to land these changes w/o hosing the tree. I'm happy to help with building of said tools if folks have requests/suggestions. Broken in 58001 Fixes: 58003, 58006, 58007, 58008, 58010 Time: 55m Broken in 57904 Fixes: 57908, 57911, 57912, 57917 Time 1hr 45m Broken in 57829 Attempted fix: 57835, Rolled out in:57853 Time: 3h 21m Re-broke in 57879 Fixes: 57883, 57884 Time: 3h 3m Getting 57829 landed resulted in nearly a full work-day of tree redness. :( Also, even once a change is fixed, it will take 15 mins or so for all the bots to cycle green. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CMake buildsystem for JSC
Hi, I created an example how the CMake files might look for WebKit. Since WebKit is a huge project I've done the task only for WTF, JavaScriptCore library and application. You can find this patch at https://bugs.webkit.org/show_bug.cgi?id=37945. If there is a real chance to use CMake as the main buildsystem (or at least get it into trunk) I will add the remaining projects (WebCore, DRT, ...) and improve it further. I only tried to build it on Win32 with CFLite and ICU. At the moment the CMakeLists.txt file in the root directory is hard coded for this port. A final version will detect the available platform features and create a cmakeconfig.h like the autotoolsconfig.h. The other CMakeLists.txt files are nearly finished. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSC String re-factorings are hosing the tree.
Hi Eric, Many apologies for the redness. These changes are pretty much complete now, so hopefully there shouldn't be any more big file moves like this too soon. One thing that was hugely useful in minimizing the breakage as much as possible while making these changes was the ews bots – these generally helped me to get my patches building cleanly on all platforms bar Windows before committing. It is a real shame that an ews bot isn't available for Windows, since this would be particularly useful - JSC changes frequently break Windows builds due to the .def files. I believe a big problem that caused the extended periods of redness was the slowness of the Windows test queues. These can lag badly behind the builds, making failures here very are easy to miss - having landed a large change, and waited to watch the waterfall stay green for an extended period of time, it was easy to be under the misapprehension that everything was okay. Only later would I discover windows test had started to fail. Clearly there is a lesson I've learned here, but maybe we can find some more hardware to throw at these queues, to help them avoid getting quite so far behind. cheers, G. On Apr 21, 2010, at 1:39 PM, Eric Seidel wrote: A large portion of the tree redness in the last 3 days is due to JSC string re-factoring. We need to build some better tools, or find some better method to land these changes w/o hosing the tree. I'm happy to help with building of said tools if folks have requests/suggestions. Broken in 58001 Fixes: 58003, 58006, 58007, 58008, 58010 Time: 55m Broken in 57904 Fixes: 57908, 57911, 57912, 57917 Time 1hr 45m Broken in 57829 Attempted fix: 57835, Rolled out in:57853 Time: 3h 21m Re-broke in 57879 Fixes: 57883, 57884 Time: 3h 3m Getting 57829 landed resulted in nearly a full work-day of tree redness. :( Also, even once a change is fixed, it will take 15 mins or so for all the bots to cycle green. -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
Re: [webkit-dev] JSC String re-factorings are hosing the tree.
That said, the Tiger bot is often lacking behind as well, which I'm not sure should be acceptable for core builders. Kenneth On Wed, Apr 21, 2010 at 7:27 PM, Gavin Barraclough barraclo...@apple.com wrote: Hi Eric, Many apologies for the redness. These changes are pretty much complete now, so hopefully there shouldn't be any more big file moves like this too soon. One thing that was hugely useful in minimizing the breakage as much as possible while making these changes was the ews bots – these generally helped me to get my patches building cleanly on all platforms bar Windows before committing. It is a real shame that an ews bot isn't available for Windows, since this would be particularly useful - JSC changes frequently break Windows builds due to the .def files. I believe a big problem that caused the extended periods of redness was the slowness of the Windows test queues. These can lag badly behind the builds, making failures here very are easy to miss - having landed a large change, and waited to watch the waterfall stay green for an extended period of time, it was easy to be under the misapprehension that everything was okay. Only later would I discover windows test had started to fail. Clearly there is a lesson I've learned here, but maybe we can find some more hardware to throw at these queues, to help them avoid getting quite so far behind. cheers, G. On Apr 21, 2010, at 1:39 PM, Eric Seidel wrote: A large portion of the tree redness in the last 3 days is due to JSC string re-factoring. We need to build some better tools, or find some better method to land these changes w/o hosing the tree. I'm happy to help with building of said tools if folks have requests/suggestions. Broken in 58001 Fixes: 58003, 58006, 58007, 58008, 58010 Time: 55m Broken in 57904 Fixes: 57908, 57911, 57912, 57917 Time 1hr 45m Broken in 57829 Attempted fix: 57835, Rolled out in:57853 Time: 3h 21m Re-broke in 57879 Fixes: 57883, 57884 Time: 3h 3m Getting 57829 landed resulted in nearly a full work-day of tree redness. :( Also, even once a change is fixed, it will take 15 mins or so for all the bots to cycle green. -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 -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSC String re-factorings are hosing the tree.
On Wed, Apr 21, 2010 at 3:27 PM, Gavin Barraclough barraclo...@apple.comwrote: I believe a big problem that caused the extended periods of redness was the slowness of the Windows test queues. These can lag badly behind the builds, making failures here very are easy to miss - having landed a large change, and waited to watch the waterfall stay green for an extended period of time, it was easy to be under the misapprehension that everything was okay. Only later would I discover windows test had started to fail. Clearly there is a lesson I've learned here, but maybe we can find some more hardware to throw at these queues, to help them avoid getting quite so far behind. I also have had this problem many times. Throwing more hardware at it would be great. Also, maybe we could use one of the Windows test bots for the initial trial of new-run-webkit-tests. Do we know how may cores are on those windows machines? The improvement in running the tests will be roughly proportional to the number of cores on the machine. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Tue, Apr 13, 2010 at 1:49 PM, Simon Fraser simon.fra...@apple.comwrote: dumpAsText also turns off pixel results, which seems like a loss of useful testing. What's the plan there? The hope is that the dumpRenderTree tests will be sufficient testing for pixel results. On Tue, Apr 13, 2010 at 2:55 PM, Dirk Pranke dpra...@chromium.org wrote: I worry that making dumpAsText the default may lead to somewhat counter-intuitive tests being written. To echo what Maciej seemed to say earlier, you can write a rendertree test or a pixel test using vanilla HTML and CSS, but a text-only test almost by definition requires some amount of JS in the test. At which point, inserting a dumpAsText() call is no big deal and clearly indicates the intent. However, having to add DontDumpAsText() as the only script in the test seems a little silly. I don't see why this is silly. Adding the following to an otherwise HTML/CSS-only a test seems totally reasonable to me: script if (window.layoutTestController) window.layoutTestController.dumpRenderTree(); /script If we did this, we'd probably whitelist some whole directories to default to dumpRenderTree though. Specifically, I'm thinking of external tests that we'd like to modify as little as possible (e.g. CSS2.1). It would also allow us to avoid modifying some external tests that we currently have modified to be dumpAsText (e.g. the dom tests). Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Implementing HTML5 context menus
Has anyone done any work/investigation towards implementing the context menu support in HTML5 (the contextmenu attribute and menu elements with type=contextMenu) as described here: http://www.w3.org/TR/html5/interactive-elements.html#context-menus ? I didn't see anything from a quick browse through the source code, and also haven't seen much traffic on webkit-dev on the subject. The spec itself seems to be at Last call for comments so it seems like it should be stable enough to start implementation. One of the members of my team has expressed some interest in working on this if there's no implementation already underway. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSC String re-factorings are hosing the tree.
I'll work on finishing the Windows EWS. The remaining blocking issue is working around the case insensitivity of the Windows file system. Adam On Wed, Apr 21, 2010 at 3:27 PM, Gavin Barraclough barraclo...@apple.com wrote: Hi Eric, Many apologies for the redness. These changes are pretty much complete now, so hopefully there shouldn't be any more big file moves like this too soon. One thing that was hugely useful in minimizing the breakage as much as possible while making these changes was the ews bots – these generally helped me to get my patches building cleanly on all platforms bar Windows before committing. It is a real shame that an ews bot isn't available for Windows, since this would be particularly useful - JSC changes frequently break Windows builds due to the .def files. I believe a big problem that caused the extended periods of redness was the slowness of the Windows test queues. These can lag badly behind the builds, making failures here very are easy to miss - having landed a large change, and waited to watch the waterfall stay green for an extended period of time, it was easy to be under the misapprehension that everything was okay. Only later would I discover windows test had started to fail. Clearly there is a lesson I've learned here, but maybe we can find some more hardware to throw at these queues, to help them avoid getting quite so far behind. cheers, G. On Apr 21, 2010, at 1:39 PM, Eric Seidel wrote: A large portion of the tree redness in the last 3 days is due to JSC string re-factoring. We need to build some better tools, or find some better method to land these changes w/o hosing the tree. I'm happy to help with building of said tools if folks have requests/suggestions. Broken in 58001 Fixes: 58003, 58006, 58007, 58008, 58010 Time: 55m Broken in 57904 Fixes: 57908, 57911, 57912, 57917 Time 1hr 45m Broken in 57829 Attempted fix: 57835, Rolled out in:57853 Time: 3h 21m Re-broke in 57879 Fixes: 57883, 57884 Time: 3h 3m Getting 57829 landed resulted in nearly a full work-day of tree redness. :( Also, even once a change is fixed, it will take 15 mins or so for all the bots to cycle green. -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] JSC String re-factorings are hosing the tree.
On Wed, Apr 21, 2010 at 3:35 PM, Ojan Vafai o...@chromium.org wrote: Also, maybe we could use one of the Windows test bots for the initial trial of new-run-webkit-tests. Do we know how may cores are on those windows machines? The improvement in running the tests will be roughly proportional to the number of cores on the machine. We'll be starting NRWT testing on the bots tonight. However, I don't think NRWT works on Windows yet. Adam Roben had some half-working patches to that affect, but I don't think they're done yet. Mostly they involve ripping out chromium-specific windows assumptions. :) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing HTML5 context menus
On Apr 21, 2010, at 5:06 PM, Drew Wilson wrote: Has anyone done any work/investigation towards implementing the context menu support in HTML5 (the contextmenu attribute and menu elements with type=contextMenu) as described here: http://www.w3.org/TR/html5/interactive-elements.html#context-menus ? I didn't see anything from a quick browse through the source code, and also haven't seen much traffic on webkit-dev on the subject. The spec itself seems to be at Last call for comments so it seems like it should be stable enough to start implementation. One of the members of my team has expressed some interest in working on this if there's no implementation already underway. No one has started on this yet. This part of the spec has never been implemented by anyone, so I suspect that if WebKit does the first implementation, we will likely need to give input to the relevant standards groups, and I suspect that we'll probably run into issues that require changes to the spec. That's not to say we shouldn't do it, but rather, whoever is working on this should be prepared to communicate with the standards groups on this feature. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing HTML5 context menus
OK, we'll start looking into this and float out an implementation proposal/design doc once we understand what needs to be done. Thanks, -atw On Wed, Apr 21, 2010 at 5:46 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2010, at 5:06 PM, Drew Wilson wrote: Has anyone done any work/investigation towards implementing the context menu support in HTML5 (the contextmenu attribute and menu elements with type=contextMenu) as described here: http://www.w3.org/TR/html5/interactive-elements.html#context-menus ? I didn't see anything from a quick browse through the source code, and also haven't seen much traffic on webkit-dev on the subject. The spec itself seems to be at Last call for comments so it seems like it should be stable enough to start implementation. One of the members of my team has expressed some interest in working on this if there's no implementation already underway. No one has started on this yet. This part of the spec has never been implemented by anyone, so I suspect that if WebKit does the first implementation, we will likely need to give input to the relevant standards groups, and I suspect that we'll probably run into issues that require changes to the spec. That's not to say we shouldn't do it, but rather, whoever is working on this should be prepared to communicate with the standards groups on this feature. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
