Re: [webkit-dev] IndexedDB API
Hm. Now that I look closer, I think the only actual conflict is in the Database interface. It still seemed worth the webapps email though. On Thu, Jan 21, 2010 at 11:40 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jan 21, 2010 at 11:14 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 21, 2010, at 9:53 PM, Jeremy Orlow wrote: A couple of us at Google are starting to look at implementing the IndexedDB API [1] in WebKit. We thought a good first step would be to create the IDL files. The first thing I noticed is that it and the Web SQL Database API [2] have quite a few conflicts in terms of their interface names. I'm wondering how we can work around this. It seems like this is something that should be fixed in the IndexedDB spec. One idea I had was to just add a prefix to every IndexedDB interface. Maybe something like IDB? I'd probably go ahead and give all the indexed database API files a IDB prefix just to make it clear which files are connected to that API. Does this sound good? Even if you rename the files, having multiple interfaces with the same interface name will still cause problems. I don't think it will even compile. We could do some interim thing but we really need to get the spec fixed. I meant prefixing both the interfaces and the files with IDB which I believe would solve the problem. That said, I agree the correct solution is fixing one or both of the specs. I'll probably try the prefix solution tomorrow though to see if it'd even work. Like I said, we're _just_ getting started. Once we've got the basics down (like the IDL files) we'll probably be writing up a design doc to get feedback on an end-to-end design and/or soliciting more advice on webkit-dev. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] IndexedDB API
(I had forgotten that many of the sql interfaces are prefixed by SQL. So IndexedDB's Transaction interface doesn't actually conflict because SQL's is named SQLTransaction.) On Fri, Jan 22, 2010 at 12:04 AM, Jeremy Orlow jor...@chromium.org wrote: Hm. Now that I look closer, I think the only actual conflict is in the Database interface. It still seemed worth the webapps email though. On Thu, Jan 21, 2010 at 11:40 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Jan 21, 2010 at 11:14 PM, Maciej Stachowiak m...@apple.comwrote: On Jan 21, 2010, at 9:53 PM, Jeremy Orlow wrote: A couple of us at Google are starting to look at implementing the IndexedDB API [1] in WebKit. We thought a good first step would be to create the IDL files. The first thing I noticed is that it and the Web SQL Database API [2] have quite a few conflicts in terms of their interface names. I'm wondering how we can work around this. It seems like this is something that should be fixed in the IndexedDB spec. One idea I had was to just add a prefix to every IndexedDB interface. Maybe something like IDB? I'd probably go ahead and give all the indexed database API files a IDB prefix just to make it clear which files are connected to that API. Does this sound good? Even if you rename the files, having multiple interfaces with the same interface name will still cause problems. I don't think it will even compile. We could do some interim thing but we really need to get the spec fixed. I meant prefixing both the interfaces and the files with IDB which I believe would solve the problem. That said, I agree the correct solution is fixing one or both of the specs. I'll probably try the prefix solution tomorrow though to see if it'd even work. Like I said, we're _just_ getting started. Once we've got the basics down (like the IDL files) we'll probably be writing up a design doc to get feedback on an end-to-end design and/or soliciting more advice on webkit-dev. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches
Thanks a lot, Maciej. yours, anton. On Fri, Jan 22, 2010 at 5:57 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 21, 2010, at 3:37 AM, Anton Muhin wrote: On Thu, Jan 21, 2010 at 10:58 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 20, 2010, at 8:18 AM, Darin Adler wrote: Hi folks. We’ve never formalized this, but I believe that patches tagged with a particular platform name such as [Qt] Add new API for fluffy bunnies should be limited to one particular platform’s code. If the patch changes more than a trivial bit of platform-independent code, even if the change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. Makes sense to me. I would also like to suggest that people should *not* use the bracket convention for things besides platform, like [dom] or [style-queue]. Some people (e.g. me) use queries to split bracket-prefix patches into a separate list, and it's better not to hide general-purpose patches. Sorry for using those, tried to be a good citizen :) Should be tags like dom, v8 omitted completely or is there some other way to communicate the system? Tagging with [v8] is fine since that's essentially a port-specific component that many reviewers are not knowledgable about. But [dom] is not necessary. If you wan to indicate the component, you can use the component field in the bug. Or just mention the DOM in the bug title. It's not super important either way. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] statement is unreachable warnings
RVCT reports a statement is unreachable warning in this case:
while (true) {
// no break in the loop
...
return someValue;
...
return someValue;
}
ASSERT_NOT_REACHED();
return someValue;
I understand that if we remove the last return statement, some compilers
will complain that not all paths return a value.
So how about adding a macro UNREACHABLE_RETURN(valueToReturn)?
Like this:
#if COMPILER(RVCT)
#define UNREACHABLE_RETURN(valueToReturn) // nothing here
#else
#define UNREACHABLE_RETURN(valueToReturn) \
ASSERT_NOT_REACHED(); \
return valueToReturn;
#endif
-Yong
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DOM Serialization?
Is it possible to save the DOM resulting from the parsing of HTML / CSS into a file and then read it back instead of re-parsing the HTML (similar to Java object serialization). Does it save any time or is it a wash? I know there is a dump render tree function but does it save everything you need so that you can re-render the HTML page w/o the original HTML / CSS files? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Serialization?
On Jan 22, 2010, at 7:16 AM, Christopher White wrote: Is it possible to save the DOM resulting from the parsing of HTML / CSS into a file and then read it back instead of re-parsing the HTML (similar to Java object serialization). WebKit has a feature called web archives that does something like this. Does it save any time or is it a wash? Save time when doing what? I know there is a dump render tree function but does it save everything you need so that you can re-render the HTML page w/o the original HTML / CSS files? The render tree dumping is unrelated to this. The render tree is an internal data structure, and it’s useful to dump it for regression testing, but it has nothing to do with serialization or re-rendering a page. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Serialization?
On Friday 22 January 2010 12:09:14 pm Darin Adler wrote: On Jan 22, 2010, at 7:16 AM, Christopher White wrote: Is it possible to save the DOM resulting from the parsing of HTML / CSS into a file and then read it back instead of re-parsing the HTML (similar to Java object serialization). WebKit has a feature called web archives that does something like this. Correct me if I'm wrong, but he said without re-parsing. The WebArchive definitely needs to be reparsed, right? Christopher White: I don't think what you are asking for exists. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Serialization?
On Jan 22, 2010, at 9:12 AM, Adam Treat wrote: Correct me if I'm wrong, but he said without re-parsing. The WebArchive definitely needs to be reparsed, right? You’re right. I was wrong. I guess the idea boils down to inventing a new serialization for HTML besides HTML and XHTML, a binary one that would be more efficient in some way. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] statement is unreachable warnings
On Jan 22, 2010, at 7:08 AM, Yong Li wrote: So how about adding a macro UNREACHABLE_RETURN(valueToReturn)? I like that idea. I don’t think it’s only the RVCT compiler that has this issue. I seem to recall something similar with the Visual Studio compiler. Obviously in any compiler that knows the code is unreachable we’d like to not omit the code there. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lots of “BREW” patches up for r eview
Based on this, it sounds like all [BREW] patches should be r-'ed and appropriate BREW_MP ones submitted? On Sun, Jan 17, 2010 at 6:23 PM, KwangYul Seo kwangyul@gmail.comwrote: [1] NDA I checked the issue with Qualcomm and drew two conclusions: 1) For BREW MP, we can open source our code without any limitation. 2) For BREW, it is not clear if we can open source our code or not due to the NDA with Qualcomm. Hosting and distributing the code can cause a potential problem. This situation is interesting because BREW and BREW MP shares most of the API. I should change the official port name to BREW MP. [2] DumpRenderTree We are actively working on DumpRenderTree, but it is not ready yet. We plan to open it next month. On Fri, Jan 15, 2010 at 10:26 AM, Eric Seidel e...@webkit.org wrote: I don't feel like this question was ever answered. Folks seem to be moving forward with setting up infrastructure for a real port (which is good), but at least this question still remains. Also, does the BREW port already have a DumpRenderTree implementation? When should we expect such? -eric On Wed, Jan 13, 2010 at 1:27 PM, Holger Freyther ze...@selfish.org wrote: On Wednesday 13 January 2010 18:23:21 Darin Adler wrote: Someone is porting WebKit to Qualcomm’s BREW. And there are many patches for that port; now a significant fraction of the unreviewed WebKit patches. Who’s going to review these? Is this a one-time code drop or is there an intent to maintain this port ongoing? Does the test suite work on the BREW platform yet? Will someone maintain a buildbot? I won’t be reviewing these patches myself until I know the answers to some of those questions. Last time I checked one needs to have a contract with Qualcomm (NDA) to get information (header files, documentation) that is beyond marketing bla bla. I would be interested if we are allowed to host and distribute the sourcecode that has used information which is under a NDA. ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Serialization?
Yes. What I am looking into is creating a binary version of the document (i.e. DOM including all rendering information). That way, when viewing the content, I can skip the parse step and just put the DOM into memory and start the layout. Time wash question? So I am trying to save time loading the doc. So my question is if there is a way to create a binary representation of the DOM with all the needed info (content and rendering), will the time saved skipping the parse step be substantial (if any at all) over reading a file which has a binary representation of the DOM, resurrecting the in-memory DOM and starting the layout process. Thanks! Chris On Fri, Jan 22, 2010 at 9:19 AM, Darin Adler da...@apple.com wrote: On Jan 22, 2010, at 9:12 AM, Adam Treat wrote: Correct me if I'm wrong, but he said without re-parsing. The WebArchive definitely needs to be reparsed, right? You’re right. I was wrong. I guess the idea boils down to inventing a new serialization for HTML besides HTML and XHTML, a binary one that would be more efficient in some way. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] pep8 style for python code
If you don't care about coding style, you can ignore this message. We're starting to grow a bunch of python code in the project. I'd like to propose that we use the PEP8 style guide for this python code: http://www.python.org/dev/peps/pep-0008/ PEP8 is more or less the official style guide for Python. The main differences between PEP8 and our style guide in other languages are: 1) use of unix_hack_style identifier names for methods and variables (but not class names), and 2) a maximum line length of 79 characters. I'd rather take PEP8 as a whole instead of picking a choosing various requirements. There's a handy automatic style checker that will help us bring our existing code into compliance: http://github.com/jcrocholl/pep8 Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] pep8 style for python code
I support not inventing a new style and making the global python style (PEP8) WebKit's official python style (it's been our defacto style for a while). We need to update the coding-style.html page to note this. On Fri, Jan 22, 2010 at 12:33 PM, Adam Barth aba...@webkit.org wrote: If you don't care about coding style, you can ignore this message. We're starting to grow a bunch of python code in the project. I'd like to propose that we use the PEP8 style guide for this python code: http://www.python.org/dev/peps/pep-0008/ PEP8 is more or less the official style guide for Python. The main differences between PEP8 and our style guide in other languages are: 1) use of unix_hack_style identifier names for methods and variables (but not class names), and 2) a maximum line length of 79 characters. I'd rather take PEP8 as a whole instead of picking a choosing various requirements. There's a handy automatic style checker that will help us bring our existing code into compliance: http://github.com/jcrocholl/pep8 Adam ___ 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] Transforming Content MathML?
One of the things I need to research is how I'm going to handle content MathML. Typically, content MathML is transformed into presentation MathML for display and this is often done with an XSLT transformation. When WebKit encounters some MathML, I'd like to follow this process: * the content MathML is transformed into a chunk of presentation MathML. * the presentation MathML's rendering object tree is constructed * that rendering tree is used in place of the content MathML. Have a complete severed subtree of content MathML seems like the wrong way to go about this. What options do I have for dealing with this multiple layers of transformation (e.g. content MathML - presentation MathML - render tree)? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] pep8 style for python code
+1. Note that the pep8 package is available on pypi and easy_install's: http://pypi.python.org/pypi/pep8/ -- Dirk On Fri, Jan 22, 2010 at 12:33 PM, Adam Barth aba...@webkit.org wrote: If you don't care about coding style, you can ignore this message. We're starting to grow a bunch of python code in the project. I'd like to propose that we use the PEP8 style guide for this python code: http://www.python.org/dev/peps/pep-0008/ PEP8 is more or less the official style guide for Python. The main differences between PEP8 and our style guide in other languages are: 1) use of unix_hack_style identifier names for methods and variables (but not class names), and 2) a maximum line length of 79 characters. I'd rather take PEP8 as a whole instead of picking a choosing various requirements. There's a handy automatic style checker that will help us bring our existing code into compliance: http://github.com/jcrocholl/pep8 Adam ___ 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] Lots of “BREW” patches up for r eview
Ok, so my reading of this thread is that WebKit is ready to accept a BREW/BREW-MP port. I'm not sure how much the platform defines (BREW vs. BREWMP) matter, but it's fine to change them to match whatever the official port is. Sounds like you have an in-progress DRT implementation. Can we expect it to move to webkit.org soon? I'm glad to see you already have build instructions: http://trac.webkit.org/wiki/BREW Have any of the BREW folks started work on a buildbot slave? No huge rush, but until the port has a builder at build.webkit.org it will likely break daily. :) http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/build.webkit.org-config I would also encourage you to read (and update!): http://trac.webkit.org/wiki/SuccessfulPortHowTo Thanks! -eric On Fri, Jan 22, 2010 at 3:04 PM, KwangYul Seo kwangyul@gmail.com wrote: I will update the patches with BREW_MP tag. Thanks, Kwang Yul Seo On Sat, Jan 23, 2010 at 3:00 AM, David Levin le...@chromium.org wrote: Based on this, it sounds like all [BREW] patches should be r-'ed and appropriate BREW_MP ones submitted? On Sun, Jan 17, 2010 at 6:23 PM, KwangYul Seo kwangyul@gmail.com wrote: [1] NDA I checked the issue with Qualcomm and drew two conclusions: 1) For BREW MP, we can open source our code without any limitation. 2) For BREW, it is not clear if we can open source our code or not due to the NDA with Qualcomm. Hosting and distributing the code can cause a potential problem. This situation is interesting because BREW and BREW MP shares most of the API. I should change the official port name to BREW MP. [2] DumpRenderTree We are actively working on DumpRenderTree, but it is not ready yet. We plan to open it next month. On Fri, Jan 15, 2010 at 10:26 AM, Eric Seidel e...@webkit.org wrote: I don't feel like this question was ever answered. Folks seem to be moving forward with setting up infrastructure for a real port (which is good), but at least this question still remains. Also, does the BREW port already have a DumpRenderTree implementation? When should we expect such? -eric On Wed, Jan 13, 2010 at 1:27 PM, Holger Freyther ze...@selfish.org wrote: On Wednesday 13 January 2010 18:23:21 Darin Adler wrote: Someone is porting WebKit to Qualcomm’s BREW. And there are many patches for that port; now a significant fraction of the unreviewed WebKit patches. Who’s going to review these? Is this a one-time code drop or is there an intent to maintain this port ongoing? Does the test suite work on the BREW platform yet? Will someone maintain a buildbot? I won’t be reviewing these patches myself until I know the answers to some of those questions. Last time I checked one needs to have a contract with Qualcomm (NDA) to get information (header files, documentation) that is beyond marketing bla bla. I would be interested if we are allowed to host and distribute the sourcecode that has used information which is under a NDA. ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] The tree is on fire
Ever since this change: http://trac.webkit.org/changeset/53722 The Leopard and SnowLeopard tests have been failing fast/dom/Window/window-property-descriptors.html. Ironically, it looks like that patch landed new results in an attempt to fix that test, but it looks to me like the new results are broken. Please fix ASAP. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XSLT serialize/parse
I'm surprised to see that documents have to be serialized and parsed whenever XSLT is used. Looking at the way libxslt works, I don't see any way for this to change. Has anyone considered using the C++ version of Xalan? This would allow direct interoperability between the DOM and XSLT as well as the possibility for incrementally rendering the result. The performance should be better just by removing serialize and parse steps. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The tree is on fire
Ok, I believe r53727 and r53738 are going to fix Leopard and SnowLeopard (and improve Windows) test runs. Keeping an eye on it... ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The tree is on fire
I'm learning to email. On Fri, Jan 22, 2010 at 5:03 PM, Eric Seidel esei...@google.com wrote: https://bugs.webkit.org/show_bug.cgi?id=33948 also broke leopard. On Fri, Jan 22, 2010 at 4:34 PM, Maciej Stachowiak m...@apple.com wrote: Ever since this change: http://trac.webkit.org/changeset/53722 The Leopard and SnowLeopard tests have been failing fast/dom/Window/window-property-descriptors.html. Ironically, it looks like that patch landed new results in an attempt to fix that test, but it looks to me like the new results are broken. Please fix ASAP. 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
Re: [webkit-dev] The tree is on fire
Thanks dimich for fixing this debug-only test failure. The buildbot seems to be improving a lot now. Sorry for the failures caused by r53722. I have fixed all related failures on Mac and Qt. The Gtk results seem not be updated for quite some time. So I do not touch them. If there is anything else I need to address, please ping me. There is another show stopper caused by http://trac.webkit.org/changeset/53740. On Fri, Jan 22, 2010 at 5:03 PM, Eric Seidel e...@webkit.org wrote: I'm learning to email. On Fri, Jan 22, 2010 at 5:03 PM, Eric Seidel esei...@google.com wrote: https://bugs.webkit.org/show_bug.cgi?id=33948 also broke leopard. On Fri, Jan 22, 2010 at 4:34 PM, Maciej Stachowiak m...@apple.com wrote: Ever since this change: http://trac.webkit.org/changeset/53722 The Leopard and SnowLeopard tests have been failing fast/dom/Window/window-property-descriptors.html. Ironically, it looks like that patch landed new results in an attempt to fix that test, but it looks to me like the new results are broken. Please fix ASAP. 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The tree is on fire
Fixed in http://trac.webkit.org/changeset/53743 -steve On Jan 22, 2010, at 5:37 PM, Jian Li wrote: There is another show stopper caused by http://trac.webkit.org/changeset/53740. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lots of “BREW” patches up for review
I changed the platform defines from BREW to BREWMP to match the official port name. As BREWMP is backward compatible with BREW, there is no much differences. As Eric mentioned, a port without the DRT and a working buildbot is too fragile We will upstream the DRT implementation to webkit.org ASAP once it is ready and will setup a build bot. I will update the Wiki page with detailed schedule and todo list. Thanks, Kwang Yul Seo On Sat, Jan 23, 2010 at 8:36 AM, Eric Seidel e...@webkit.org wrote: Ok, so my reading of this thread is that WebKit is ready to accept a BREW/BREW-MP port. I'm not sure how much the platform defines (BREW vs. BREWMP) matter, but it's fine to change them to match whatever the official port is. Sounds like you have an in-progress DRT implementation. Can we expect it to move to webkit.org soon? I'm glad to see you already have build instructions: http://trac.webkit.org/wiki/BREW Have any of the BREW folks started work on a buildbot slave? No huge rush, but until the port has a builder at build.webkit.org it will likely break daily. :) http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/build.webkit.org-config I would also encourage you to read (and update!): http://trac.webkit.org/wiki/SuccessfulPortHowTo Thanks! -eric On Fri, Jan 22, 2010 at 3:04 PM, KwangYul Seo kwangyul@gmail.com wrote: I will update the patches with BREW_MP tag. Thanks, Kwang Yul Seo On Sat, Jan 23, 2010 at 3:00 AM, David Levin le...@chromium.org wrote: Based on this, it sounds like all [BREW] patches should be r-'ed and appropriate BREW_MP ones submitted? On Sun, Jan 17, 2010 at 6:23 PM, KwangYul Seo kwangyul@gmail.com wrote: [1] NDA I checked the issue with Qualcomm and drew two conclusions: 1) For BREW MP, we can open source our code without any limitation. 2) For BREW, it is not clear if we can open source our code or not due to the NDA with Qualcomm. Hosting and distributing the code can cause a potential problem. This situation is interesting because BREW and BREW MP shares most of the API. I should change the official port name to BREW MP. [2] DumpRenderTree We are actively working on DumpRenderTree, but it is not ready yet. We plan to open it next month. On Fri, Jan 15, 2010 at 10:26 AM, Eric Seidel e...@webkit.org wrote: I don't feel like this question was ever answered. Folks seem to be moving forward with setting up infrastructure for a real port (which is good), but at least this question still remains. Also, does the BREW port already have a DumpRenderTree implementation? When should we expect such? -eric On Wed, Jan 13, 2010 at 1:27 PM, Holger Freyther ze...@selfish.org wrote: On Wednesday 13 January 2010 18:23:21 Darin Adler wrote: Someone is porting WebKit to Qualcomm’s BREW. And there are many patches for that port; now a significant fraction of the unreviewed WebKit patches. Who’s going to review these? Is this a one-time code drop or is there an intent to maintain this port ongoing? Does the test suite work on the BREW platform yet? Will someone maintain a buildbot? I won’t be reviewing these patches myself until I know the answers to some of those questions. Last time I checked one needs to have a contract with Qualcomm (NDA) to get information (header files, documentation) that is beyond marketing bla bla. I would be interested if we are allowed to host and distribute the sourcecode that has used information which is under a NDA. ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
