Hi,
I hope I make myself clear, but i am sorry for my poor English.
I am trying to build the JavaScriptCore (a piece of webkit) as a shared
object to use in my Android Application.
I got a lot of errors and i corrected them by configuring my Android.mk
file.
But, now i am getting the following
Hi,
ThreadSpecific contains the platform dependent TLS (Thread Local Storage)
implementation for WebKit.
In Platform.h:
#if PLATFORM(ANDROID)
#define WTF_USE_PTHREADS 1
...
Thus, Android should use pthread.h (Please check this line in your
Source/JavaScriptCore/wtf/Platform.h)
You could try
From: Alex Russell slightly...@chromium.org
We observe that web developers are attempting to use DOM in both structural
(semantic or component-oriented) and visual ways inside the same
document.
I would like to understand what you mean here: can you suggest an
example or other place to read?
On Thu, Jun 30, 2011 at 4:22 PM, John J. Barton johnjbar...@johnjbarton.com
wrote:
From: Alex Russell slightly...@chromium.org
We observe that web developers are attempting to use DOM in both
structural
(semantic or component-oriented) and visual ways inside the same
document.
I would
On 6/30/2011 8:52 AM, Alex Russell wrote:
On Thu, Jun 30, 2011 at 4:22 PM, John J. Barton
johnjbar...@johnjbarton.com mailto:johnjbar...@johnjbarton.com wrote:
From: Alex Russell slightly...@chromium.org
mailto:slightly...@chromium.org
How can one work with the DOM as a visual
Hi there!
I'm currently working on Chromium's new tab page, which amongst other things
requires page favicons in different sizes than 16x16. And while the WhatWG
spechttp://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#rel-iconsupports
multiple link rel=icon... elements, webkit
According to https://bugs.webkit.org/show_bug.cgi?id=34984, there are
only two remaining blocking issues:
1) Teaching new-run-webkit-tests to understand the difference between
WebProcess crashes and other sorts of crashes in WebKit2.
2) Fixing some issues with the Apple Windows port.
Once we get
Improving our support for favicons to better match HTML5 sounds like a
good idea. I'd recommend filing a bug and uploading a patch. :)
Adam
On Thu, Jun 30, 2011 at 11:39 AM, Rachel Blum gr...@chromium.org wrote:
Hi there!
I'm currently working on Chromium's new tab page, which amongst other
Hi Sam!
On Wed, Jun 29, 2011 at 7:50 PM, Sam Weinig wei...@apple.com wrote:
Hi Dimitri,
First of all, nice work on getting to this point!
Thanks, it's been a nice, long slog :)
It is not clear to me why we wouldn't stick with XBL2 for now, at least until
there is more community consensus
I'd like to propose that WebKit commit messages start with a one-line summary
of the change.
This change would have two benefits:
1) It would make it much easier to understand at a glance what the change
actually does.
Our commit logs usually include a bug title, but the bug title only tells
Sounds good to me, except I wonder how often you'd get Fixed bug
where where XXX is the bug summary.
-- Dirk
On Thu, Jun 30, 2011 at 1:28 PM, Adam Roben aro...@apple.com wrote:
I'd like to propose that WebKit commit messages start with a one-line summary
of the change.
This change
On 2011-06-30, at 13:28, Adam Roben wrote:
I'd like to propose that WebKit commit messages start with a one-line summary
of the change.
This change would have two benefits:
1) It would make it much easier to understand at a glance what the change
actually does.
Our commit logs
On Jun 30, 2011, at 5:10 PM, Mark Rowe wrote:
Most ChangeLog entries already have a one-line summary immediately after the
Reviewed by line. I'm not sure that there's any benefit to reordering
these parts of the ChangeLog.
Most ChangeLog entries have the bug title after the Reviewed by
On Jun 30, 2011, at 5:00 PM, Dirk Pranke wrote:
Sounds good to me, except I wonder how often you'd get Fixed bug
where where XXX is the bug summary.
I think this is something that reviewers would have to encourage authors not to
do, just like reviewers should be encouraging authors to
I don’t think it’s a good idea to add yet another thing to every change log
entry.
I do think that given the tools behavior you described, we should move the
reviewer text after the bug title and patch description paragraph, even though
you explicitly said that’s not what you are proposing.
On Thu, Jun 30, 2011 at 4:52 PM, Darin Adler da...@apple.com wrote:
I don’t think it’s a good idea to add yet another thing to every change log
entry.
I do think that given the tools behavior you described, we should move the
reviewer text after the bug title and patch description paragraph,
On Thu, Jun 30, 2011 at 4:57 PM, Ryosuke Niwa rn...@webkit.org wrote:
We should just fix webkit-patch so that it uses the right commit message.
Go for it:
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/checkout/checkout.py#L117
Adam
17 matches
Mail list logo
