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
(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
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.
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
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
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
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).
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
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
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
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
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
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
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
+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
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
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
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
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
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:
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
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
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
23 matches
Mail list logo
