On Fri, Sep 3, 2010 at 3:19 PM, Jian Li jia...@google.com wrote:
Some parts of changes are due to the File API work I have worked on.
On Fri, Sep 3, 2010 at 2:50 PM, Adam Barth aba...@webkit.org wrote:
I was looking at SecurityOrigin.cpp today and I saw a bunch of code
relating to Blob URLs
On Fri, Sep 3, 2010 at 4:02 PM, Jian Li jia...@chromium.org wrote:
On Fri, Sep 3, 2010 at 3:43 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Sep 3, 2010 at 3:19 PM, Jian Li jia...@google.com wrote:
The reason that we skip the unique origin check here is to allow a local
running worker
On Fri, Sep 3, 2010 at 4:16 PM, Jian Li jia...@chromium.org wrote:
On Fri, Sep 3, 2010 at 4:08 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Sep 3, 2010 at 4:02 PM, Jian Li jia...@chromium.org wrote:
On Fri, Sep 3, 2010 at 3:43 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Sep 3, 2010
On Fri, Sep 3, 2010 at 4:21 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Sep 3, 2010 at 4:16 PM, Jian Li jia...@chromium.org wrote:
On Fri, Sep 3, 2010 at 4:08 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Sep 3, 2010 at 4:02 PM, Jian Li jia...@chromium.org wrote:
On Fri, Sep 3, 2010
On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote:
Yes. The file-related stuff should all be in one directory, I think.
Ok. I moved the files from WebCore/html to WebCore/fileapi.
On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote:
We have bunch of FileSystem (which is a
Based on some feedback, I'm going to try to improve the line-by-line
review tool. I've landed the first iteration of the new design, which
should be usable and have roughly the same functionality as the old
design. I'll be adding new features shortly.
The main difference is you now access the
and only includes
a single line of context.
--Oliver
On Aug 29, 2010, at 11:13 AM, Adam Barth wrote:
Based on some feedback, I'm going to try to improve the line-by-line
review tool. I've landed the first iteration of the new design, which
should be usable and have roughly the same
On Sun, Aug 29, 2010 at 5:07 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 29, 2010, at 4:39 PM, Adam Barth wrote:
I'm happy to build this off in a silo and then convince everyone how
awesome it is once it actually is more awesome than the current tools.
I suggest you start by making
On Sat, Aug 28, 2010 at 7:44 AM, Chris Marrin cmar...@apple.com wrote:
That's why I still think this should all go into a branch for now. It will
help us all see the results without having to deal with the issues of (2)
right now.
An alternative to a branch is to use a run-time setting.
Looking through WebCore/html I noticed the files below. I'm not sure
they belong in WebCore/html because they don't appear to be
HTML-specific. Rather, they seem like generic web platform APIs
(e.g., they could be exposed to SVG or whatever other markup languages
we choose to support in the
On Fri, Aug 27, 2010 at 4:08 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 27, 2010, at 3:55 PM, Adam Barth wrote:
Looking through WebCore/html I noticed the files below. I'm not sure
they belong in WebCore/html because they don't appear to be
HTML-specific. Rather, they seem like
What is XBL? As far as I can tell, there's no way this code can even
build. It's incredibly stale. Can we remove it?
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Sorry for the late-night webkit-dev spam, but in deploying adoptPtr,
I've noticed a number of places where have a HashMap that owns its
values as OwnPtrs. Unfortunately, this very clumsy currently. Each
instance of this pattern has its own way of hacking around the
problem, which might or might
The existing code is very confused. For example, it doesn't seem to
know that RefCounted objects start with an initial ref. My guess is
that it was written a long time ago and then was abandoned. As the
project moved forward, this code got left behind.
Adam
On Wed, Aug 25, 2010 at 9:26 AM,
On Wed, Aug 25, 2010 at 7:09 AM, Stephan Assmus supersti...@gmx.de wrote:
Am 24.08.2010 19:46, schrieb Adam Barth:
One thing Darin and I discussed at WWDC (yes, this email has been a
long time coming) is better programming patterns to prevent memory
leaks. As I'm sure you know, whenever you
There seem to be a bunch of files missing too. For example, I can't
find XBLDocument or XMLBindingsManager.
I don't mean to hate on XBL, I just started looking at it when
deploying adoptPtr and was surprised by what I found, that's all.
Adam
On Wed, Aug 25, 2010 at 10:13 AM, Darin Adler
Ok. I've posted a patch:
https://bugs.webkit.org/show_bug.cgi?id=44621
Adam
On Wed, Aug 25, 2010 at 10:17 AM, Adam Barth aba...@webkit.org wrote:
There seem to be a bunch of files missing too. For example, I can't
find XBLDocument or XMLBindingsManager.
I don't mean to hate on XBL, I
On Wed, Aug 25, 2010 at 2:31 PM, Stephan Assmus supersti...@gmx.de wrote:
Am 25.08.2010 18:35, schrieb Adam Barth:
On Wed, Aug 25, 2010 at 7:09 AM, Stephan Assmussupersti...@gmx.de
wrote:
Am 24.08.2010 19:46, schrieb Adam Barth:
One thing Darin and I discussed at WWDC (yes, this email has
On Mon, Aug 16, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote:
On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak m...@apple.com wrote:
1) It means the access control goes in fewer places - we don't have to have
access control on
Eric and I discussed this recently. We think the easiest path forward
is to try to remove build systems incrementally. Each build system we
remove makes it easier to hack on the project because you have one
less build system to worry about. The easiest build system to remove
is probably the
This sounds related to the recent addition of
[RequiresAllArguments=Raise]. Historically, we've been lax about
missing arguments. I think the specs want us to be stricter, but last
time we discussed the topic, the read I got was that the compatibility
pain might not be worth the benefit.
Adam
On Tue, Aug 10, 2010 at 11:26 AM, Xan Lopez x...@gnome.org wrote:
as we all know, when writing DOM bindings on top of WebKit we are
supposed to use the IDL files it ships as the source of the structure
and behavior of the DOM. At first I had assumed that to figure out
which events apply to
On Tue, Aug 10, 2010 at 12:16 PM, Alexey Proskuryakov a...@webkit.org wrote:
10.08.2010, в 11:51, Eric Seidel написал(а):
Why do we want to be running these 6000 tests and slowing down our
builds. I was talking with jamesr, and he seemed to think it adds
little value to run it every time?
On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak m...@apple.com wrote:
On Aug 4, 2010 4:30:01 PM PDT, Darin Adler da...@apple.com wrote:
On Aug 4, 2010, at 3:48 PM, Ryosuke Niwa wrote:
I think the kind of crashes Ojan is talking about are ones caused by
DOM mutation events.
snip
It’s
Trying to land the same patch multiple times is expected behavior.
That happens when it can't decide whether the patch is good or bad
(e.g., because the tree is broken or because it's checkout gets out of
date before it's able to actually commit).
Adam
On Wed, Aug 4, 2010 at 6:11 AM, Satish
I'd be happy to write more posts for Surfin' Safari, but I don't know
if I need approval, etc.
Adam
On Mon, Aug 2, 2010 at 1:31 PM, Eric Seidel e...@webkit.org wrote:
Woh. I think that's an awesome idea. :)
Would also make sure that all reviewers are blog-enabled.
Might be a bit to ask of
You can do it with git revert. You'll need to clean up the commit
message and ChangeLog entries before actually landing it through. Using
git rebase -i you can decide whether to land the rollout in one
commit or several. Alternatively, you can try webkit-patch rollout
on each revision in
today.
On Thu, Jul 29, 2010 at 11:19 PM, Adam Barth aba...@webkit.org wrote:
WebCore::LayoutTestController would be exposed to JavaScript running
in LayoutTests directly (like the DOM), so we can skip the type
conversions.
On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath sat...@google.com wrote
On Fri, Jul 30, 2010 at 2:56 AM, Steve Block stevebl...@google.com wrote:
WebCore::LayoutTestController would be exposed to JavaScript running
in LayoutTests directly (like the DOM), so we can skip the type
conversions.
There might still be the need for some plumbing though. In the case of
On Fri, Jul 30, 2010 at 1:10 PM, Darin Adler da...@apple.com wrote:
It’s come to my attention that some webkit-patch or some other script
requires that patches without review contain the string “Unreviewed”
somewhere in their change log message. I personally think this is not
helpful. In my
On Fri, Jul 30, 2010 at 3:57 PM, Darin Adler da...@apple.com wrote:
It’s in non-bot contexts that I think it’s not good. I think that means I
agree with you both who said that running webkit-patch on the command line
shouldn't require it. We can have the commit bot use an option to tell
On Fri, Jul 30, 2010 at 7:55 PM, Eric Seidel e...@webkit.org wrote:
On Fri, Jul 30, 2010 at 5:42 AM, Jeremy Orlow jor...@chromium.org wrote:
Why wasn't it done that way originally? That sounds (to my uneducated ear)
much better than what's done today.
The world was very different back then.
Thanks for bring this question to the list. I don't have a strong
opinion here, but I want to make sure we think project-wide and pick
something scalable.
This discussion is also related to the discussion about adding
something like a layoutTestController object to WebCore. Plumbing
this mock
in
WebKit to convert the call parameters from WebKit types (which DRT uses) to
WebCore types (which the mocks may use) ? If yes seems like we need wrappers
to proxy the mock calls anyway on different platforms..
Cheers
Satish
On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth aba...@webkit.org wrote
Awesome. Thanks.
Adam
On Wed, Jul 28, 2010 at 6:06 AM, Stephanie Lewis sle...@apple.com wrote:
I measure it as a 1% win on the PLT.
-- Stephanie
On Jul 26, 2010, at 12:36 PM, Stephanie Lewis wrote:
I can do this.
-- Stephanie Lewis
On Jul 26, 2010, at 5:57 AM, Adam Barth wrote
On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak m...@apple.com wrote:
On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:
I measure it as a 1% win on the PLT.
Might be a good idea to test HTML iBench as well.
Sure. I'd be happy to. Is that benchmark available publicly?
Adam
slewis++
On Thu, Jul 29, 2010 at 3:15 AM, Stephanie Lewis sle...@apple.com wrote:
I believe it is somewhere, but the setup is a hassle, so I'll run it tomorrow
for you.
-- Stephanie
On Jul 28, 2010, at 8:13 PM, Adam Barth wrote:
On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak m
)
, m_fragmentScriptingPermission(FragmentScriptingAllowed)
On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth aba...@webkit.org wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once
we do that, we'll have the core of the HTML5 parsing algorithm turned
on, including SVG-in-HTML
Thanks!
On Mon, Jul 26, 2010 at 9:36 PM, Stephanie Lewis sle...@apple.com wrote:
I can do this.
-- Stephanie Lewis
On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:
Would someone from Apple be willing to run the patch below though the
PLT? We're doing well on our parsing benchmark (4
That looks similar to the dom2string library from HTML5lib.
dom2string makes DOM dumps that look like the following:
!DOCTYPE htmllihelloliworldulhowlido/ulyou/body!--do--
| !DOCTYPE html
| html
| head
| body
| li
| hello
| li
| world
| ul
| how
| li
On Fri, Jul 23, 2010 at 5:27 PM, Oliver Hunt oli...@apple.com wrote:
On Jul 23, 2010, at 4:50 PM, Leo Meyerovich wrote:
I wasn't entirely sure what OP was after of if the reply below
adequately addressed his interests.
WebKit2 seems to have little to do with taking advantage of parallel
On Mon, Jul 19, 2010 at 2:04 AM, Adam Barth aba...@webkit.org wrote:
On Sun, Jul 18, 2010 at 2:06 PM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
Am 18.07.2010 um 18:36 schrieb Adam Barth:
I'm not sure it's working properly. It says:
SUCCESS: Build 17401 (r63531
We're getting close to enabling the HTML5 tree builder on trunk. Once
we do that, we'll have the core of the HTML5 parsing algorithm turned
on, including SVG-in-HTML. There are still a bunch of details left to
finish (such as fragment parsing, MathML entities, and better error
reporting), but
On Sun, Jul 18, 2010 at 2:06 PM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
Am 18.07.2010 um 18:36 schrieb Adam Barth:
I'm not sure it's working properly. It says:
SUCCESS: Build 17401 (r63531) was the first to show failures:
set([u'svg/filters/filter-empty-g.svg
A test has been crashing Leopard Intel Debug (Tests) for 24 hours. I
tried to look back on buildbot to see when the issue started, but it's
past the end of the waterfall (much like a rainbow). If you touched
SVG filters recently, would you be willing to investigate?
Thanks,
Adam
Tests that
:
Won't webkit-patch failure-reason tell you when it started? It
knows how to handle looking past the end of the waterfall.
-eric
On Sun, Jul 18, 2010 at 8:48 AM, Adam Barth aba...@webkit.org wrote:
A test has been crashing Leopard Intel Debug (Tests) for 24 hours. I
tried to look back
On Sat, Jul 10, 2010 at 6:28 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 10, 2010, at 11:10 AM, Sausset François wrote:
I just saw that when looking at the code by myself.
What do you exactly mean by a prefix tree?
The data structure commonly called a Trie is a prefix tree:
On Sat, Jul 10, 2010 at 4:49 AM, Maciej Stachowiak m...@apple.com wrote:
On Jul 10, 2010, at 3:47 AM, Sausset François wrote:
I'm currently working on the MathML3 implementation and I noticed that new
XML entities have been defined by the W3C:
http://www.w3.org/TR/xml-entity-names/
They are
/named-character-references.html#named-character-references
and the prefix tree.
Adam
Le 10 juil. 2010 à 21:00, Adam Barth a écrit :
Implementing MathML entities is not as easy as adding them to
HTMLEntityNames.gperf. The problem is our entity parsing code (both
the legacy entity parser
On Fri, Jul 9, 2010 at 6:19 PM, David Kilzer ddkil...@webkit.org wrote:
On Jul 9, 2010, at 7:34 AM, Adam Roben aro...@apple.com wrote:
On Jul 9, 2010, at 6:23 AM, Alex Milowski wrote:
Should we keep the master bug?
Should we use it only for our implementation efforts and not
make it
On Wed, Jul 7, 2010 at 7:29 PM, Maciej Stachowiak m...@apple.com wrote:
One negative externality is that it
sometimes makes people excessively upset about tree redness, and sometimes
makes them want to fix redness in a way that papers over problems (e.g. by
adding to the skipped list).
If
On Thu, Jul 8, 2010 at 10:58 AM, Xan Lopez x...@gnome.org wrote:
On Thu, Jul 8, 2010 at 7:54 PM, Adam Barth aba...@webkit.org wrote:
2) Currently the commit-queue only lands if it gets a 100% passing run
of all the tests. We could instead change it to land if there are no
new test failures
On Thu, Jul 8, 2010 at 11:05 AM, Darin Adler da...@apple.com wrote:
On Jul 8, 2010, at 10:58 AM, Xan Lopez wrote:
Oh, and might this serve as a ping for whoever set the trees on fire... at
least some of it seems related to the refPtr work that's been going on (see
If you're tired of my complaining about the tree being red, you can
skip this message.
Today Alexey checked in http://trac.webkit.org/changeset/62576,
which broke two tests on every port. 12 hours later, these failures
remained in the tree until I cleaned them up. This mess could have
been
Sorry for singling you out Alexey. I was just frustrated last night.
On Wed, Jul 7, 2010 at 8:58 AM, Alexey Proskuryakov a...@webkit.org wrote:
07.07.2010, в 00:47, Adam Barth написал(а):
If you're tired of my complaining about the tree being red, you can
skip this message.
I understand
I think Yaar might be a good contact person.
Adam
On Wed, Jul 7, 2010 at 12:40 PM, Darin Adler da...@apple.com wrote:
Who has the knowledge and access needed to fix problems like this?
svn: Working copy
The interface between JavaScript and the DOM is in
WebCore/bindings/js. Much of it is autogenerated from IDL files. The
DOM tree is constructed by the parser. You can look at
LegacyHTMLTreeBuilder to see how that works. We're current in the
process of replacing the tree builder with
I'm not sure if there's a short-cut, but you essentially want a
JavaScript engine that uses continuation-passing style:
http://en.wikipedia.org/wiki/Continuation-passing_style
Certainly doable but likely difficult.
Adam
On Mon, Jun 28, 2010 at 1:30 AM, Srinivasa Rao Edara
On Mon, Jun 28, 2010 at 1:43 PM, Kenneth Christiansen
kenneth.christian...@openbossa.org wrote:
6) Add validator rules that make invocation of the new operator legal
only inside adoptRef and adoptPtr function calls.
That is probably going to be a problem for Qt code on the WebKit API
Sounds great. Let me know how I can help.
Do we need an exception for statics that we intend to leak at
shutdown? Maybe leakPtr(new Foo)?
Adam
On Mon, Jun 28, 2010 at 1:39 PM, Darin Adler da...@apple.com wrote:
Hi folks.
I’d like to use our smart pointers more consistently to decrease the
The snow leopard bot is having some trouble. For roughly half the
runs, all the tests time out:
(Jun 19 00:35) rev=[61470] failure #11969: failed Exiting early after
20 failures. 20 tests run. 20 test cases (100%) timed out
The only plausible change in near the regression window is
Intel Release (Tests)
bots itself is sick, apple-xserve-6 is the culprit.
I think it needs a kick to make commit queue happier.
br,
Ossy
Adam Barth írta:
The snow leopard bot is having some trouble. For roughly half the
runs, all the tests time out:
(Jun 19 00:35) rev=[61470] failure
On Fri, Jun 18, 2010 at 1:22 PM, Adam Roben aro...@apple.com wrote:
I've been looking into these. I got the Windows bots down from 11 failures
to 3 failures on Wednesday.
The main difficulty I have with the windows bots is that they get
really behind. Is there something stopping us from
On Fri, Jun 18, 2010 at 1:33 PM, Darin Adler da...@apple.com wrote:
On Jun 18, 2010, at 1:28 PM, Adam Barth wrote:
On Fri, Jun 18, 2010 at 1:22 PM, Adam Roben aro...@apple.com wrote:
I've been looking into these. I got the Windows bots down from 11 failures
to 3 failures on Wednesday
it on?
Cameron
On Jun 16, 2010, at 8:32 AM, Adam Barth aba...@webkit.org wrote:
Apologies for the red tree. There are still a handful of LayoutTests
we're trying to understand. Hopefully we'll have everything cleared
up by noon.
Thanks,
Adam
On Wed, Jun 16, 2010 at 2:20 AM, Eric Seidel e
People of WebKit,
As mentioned recently on webkit-dev, Eric, Tonyg, and I have been
working on implementing the HTML5 parsing algorithm in WebKit:
http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11472.html
We're now ready to turn the new tokenization algorithm on by default
(probably
On Thu, Jun 10, 2010 at 10:46 AM, Peter Kasting pkast...@google.com wrote:
On Thu, Jun 10, 2010 at 8:34 AM, Antonio Gomes (:tonikitoo)
toniki...@gmail.com wrote:
Ideally, patches in feedback? status should also be easier to
review/validate, and the author would be sure it is taking the right
I'd like to help you, but I don't know what you mean by the
document's URL will be reported as. Reported to whom via what?
Adam
On Mon, Jun 7, 2010 at 12:37 PM, Chris Fleizach cfleiz...@apple.com wrote:
Hello,
I need to write a layout test where the document's URL will be reported as
Wow, that's pretty awesome. Thanks Ojan.
Adam
On Mon, Jun 7, 2010 at 1:25 PM, Ojan Vafai o...@chromium.org wrote:
I sure am.
I wrote a Chrome extension that adds autocomplete to bugzilla email input
boxes based off the data
in
On Fri, Jun 4, 2010 at 1:54 AM, Mikhail Naganov mnaga...@chromium.org wrote:
On Fri, Jun 4, 2010 at 05:57, Sam Weinig sam.wei...@gmail.com wrote:
I should note, I don't think this is possible for JS objects, it certainly
would not be possible for arbitrary WebCore/WebKit objects. I noticed the
[+fishd]
I believe this is a common pattern in the Chromium WebKit API. fishd
can speak to why this works the way it does in more detail. I believe
these enums exist to encapsulate WebCore types in the interface.
Adam
On Fri, Jun 4, 2010 at 9:40 AM, Chris Fleizach cfleiz...@apple.com wrote:
I haven't looked into the details, but, in general, side channel
information is a rich area for unintentional disclosure. For example,
timing information leaks a ton of information.
Here's a recent paper that shows a bunch of stuff you can use from the
sizes of things. In this case, they're
Hi webkit-dev,
As some of you know, Eric and I have been working on implementing the
HTML5 parsing algorithm in WebKit. This morning, at 5:58am, we
reached an important milestone: we got Gmail working. :)
The HTML5 parsing algorithm actually consists of two algorithms: a
tokenizer, which
Mr. ggaren,
http://build.webkit.org/results/GTK%20Linux%2032-bit%20Debug/r60245%20(6166)/fast/js/deep-recursion-test-stderr.txt
ASSERTION FAILED: m_value
(../../JavaScriptCore/assembler/MacroAssemblerCodeRef.h:105
JSC::ReturnAddressPtr::ReturnAddressPtr(void*))
Was the failure above caused by
On Wed, May 19, 2010 at 10:27 AM, Darin Adler da...@apple.com wrote:
Not sure where to put these. A while ago people were talking about changes
needed to webkit-patch. Here are some of the basics for me for one command,
webkit-patch upload. When I use webkit-patch upload to create a patch in
On Wed, May 19, 2010 at 10:41 AM, Darin Adler da...@apple.com wrote:
Lets say I just did webkit-patch upload and I am Subversion user and I now
want the patch out of my tree. Does webkit-patch have a command to help me do
it? I can’t just use svn revert because that doesn’t handle things like
On Wed, May 19, 2010 at 11:04 AM, Darin Adler da...@apple.com wrote:
On May 19, 2010, at 10:52 AM, Adam Barth wrote:
Thanks for the feedback. Webkit-patch already respects the EDITOR
environment variable. It should be a simple change to support the
CHANGE_LOG_EDIT_APPLICATION environment
On Wed, May 19, 2010 at 11:06 AM, Darin Adler da...@apple.com wrote:
On May 19, 2010, at 10:56 AM, Adam Barth wrote:
On Wed, May 19, 2010 at 10:41 AM, Darin Adler da...@apple.com wrote:
Lets say I just did webkit-patch upload and I am Subversion user and I
now want the patch out of my tree
On Wed, May 19, 2010 at 11:25 AM, Darin Adler da...@apple.com wrote:
It’s not obvious to me how to take a tool primarily designed for the git
users and make it great for me, although it seems tantalizingly close.
:)
It's funny how the git users also tell me that the tool doesn't fit
their
The same test is failing on essentially all the bots:
fast/files/file-reader.html
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r59670%20(10305)/fast/files/file-reader-pretty-diff.html
The blame list computed by the bots is as follows:
My understanding is that we almost always use the explicit keyword
unless we explicitly want implicit construction. For example,
AtomicString has a non-explicit constructor that takes a String on
purpose (or at least controlled by NO_IMPLICIT_ATOMICSTRING).
Adam
On Mon, May 17, 2010 at 12:39
On Mon, May 17, 2010 at 5:28 PM, Chris Jerdonek cjerdo...@webkit.org wrote:
On Mon, May 17, 2010 at 3:11 PM, Darin Adler da...@apple.com wrote:
I think the best way for us to clarify our guideline for this would be to
discuss a few individual cases where we have a non-explicit constructor. We
On Sat, May 15, 2010 at 9:14 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I'm glad to say that WebKit-EFL was finally merged as the last but
definitely bit, the build system, was merged into tree today. Many,
many thanks to all the friends that helped with this painful task,
One of the least fun things in the project is to pour a bunch of
effort into writing a patch only to see it sit forever waiting for
review. In the past, I've tried to single-handedly tackle the patches
that have been up for review for more than a month. That approach is
less than ideal because
On Mon, May 10, 2010 at 11:39 PM, Eric Seidel esei...@google.com wrote:
On Mon, May 10, 2010 at 2:30 PM, Geoffrey Garen gga...@apple.com wrote:
2) Your patch can be vetted by the various bots that analyze patches
posted for review.
True, if what you're really asking for is not just a bug
On Tue, May 11, 2010 at 2:11 PM, Geoffrey Garen gga...@apple.com wrote:
For fun, I scrolled back through WebCore/ChangeLog looking for a
non-build fix that was missing a bug link. The first one I found was
160 revs ago. I suspect the vast majority of patches already have bug
reports.
Did
On Mon, May 10, 2010 at 2:09 PM, Peter Kasting pkast...@google.com wrote:
On Mon, May 10, 2010 at 2:05 PM, Adam Barth aba...@webkit.org wrote:
On Mon, May 10, 2010 at 1:30 PM, Peter Kasting pkast...@google.com
wrote:
I agree that a 1:1 association between patches and bugs (which has been
On Mon, May 10, 2010 at 2:31 PM, Geoffrey Garen gga...@apple.com wrote:
If you'll allow me to climb higher on my horse, I'll advocate for
landing patches like this through the commit queue.
Personally, I find the output of the commit queue incredibly confusing, since
it claims that Eric
Can we hide this in the UI? My understanding is that it will be used
only by the tools.
Adam
On Mon, May 10, 2010 at 4:37 PM, Eric Seidel e...@webkit.org wrote:
As part of https://bugs.webkit.org/show_bug.cgi?id=38866 I've added a
new flag to bugzilla patches called in-rietveld.
This flag
On Mon, May 10, 2010 at 6:04 PM, Brent Fulgham bfulg...@gmail.com wrote:
On Mon, May 10, 2010 at 2:44 PM, Adam Barth aba...@webkit.org wrote:
On Mon, May 10, 2010 at 2:30 PM, Geoffrey Garen gga...@apple.com wrote:
2) Your patch can be vetted by the various bots that analyze patches
posted
On Thu, Apr 29, 2010 at 9:44 AM, Alexey Proskuryakov a...@webkit.org wrote:
On 26.04.2010, at 22:06, Adam Barth wrote:
If you make changes to CodeGenerator*.pm, please test your
change using the following command:
~/git/webkit$ ./WebKitTools/Scripts/run-bindings-tests
I don't understand
On Thu, Apr 29, 2010 at 10:54 AM, Adam Barth aba...@webkit.org wrote:
On Thu, Apr 29, 2010 at 10:39 AM, Alexey Proskuryakov a...@webkit.org wrote:
On 29.04.2010, at 10:27, Jeremy Orlow wrote:
It's great to test end-to-end behavior, and unit tests can also also
useful sometimes, but why test
IMHO, run-webkit-tests should run all the various webkit testing
scripts and we should have a run-layout-tests script that does what
run-webkit-tests does today.
I'd also settle for a run-tests scripts that was the ASAD testing script.
Adam
On Thu, Apr 29, 2010 at 12:16 PM, David Levin
On Thu, Apr 29, 2010 at 12:43 PM, Maciej Stachowiak m...@apple.com wrote:
To repeat, I think this is a useful tool, but not necessarily as a test.
The mode of operation is that when you run this test, if the generated
bindings for the text IDL file change in any way, it reports a failure. Then
People of webkit-dev:
We now have a testing harness in place for CodeGeneratorJS.pm and
friends. If you make changes to CodeGenerator*.pm, please test your
change using the following command:
~/git/webkit$ ./WebKitTools/Scripts/run-bindings-tests
If you add a new feature to CodeGenerator*.pm,
On Thu, Apr 22, 2010 at 11:23 AM, Adam Roben aro...@apple.com wrote:
On Apr 22, 2010, at 2:19 PM, Adam Roben wrote:
The svn step of the test builders takes about 4.5 minutes, compared to
about 15 minutes to run the tests. I don't know if having to update two
different source trees is the
One of the other demos put together at the hackathon let you drag on
the patch to select how much context you wanted when making your
comment. I can try to make that work.
Adam
On Thu, Apr 22, 2010 at 1:09 PM, Adam Barth aba...@webkit.org wrote:
How would you like me to address this issue
. Other issues seem like iterative refinements
we could do over time.
- Maciej
On Apr 22, 2010, at 1:09 PM, Adam Barth aba...@webkit.org wrote:
How would you like me to address this issue?
Adam
On Thu, Apr 22, 2010 at 1:01 PM, Darin Adler da...@apple.com wrote:
I’m having trouble
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
the current review system. I don't think we need to choose one
vs. another (at least not in the short term). Not that you were suggesting
that.
Ojan
On Mon, Apr 19, 2010 at 4:06 PM, Adam Barth aba...@webkit.org wrote:
+scherkus
On Mon, Apr 19, 2010 at 4:01 PM, Maciej Stachowiak m...@apple.com
801 - 900 of 1121 matches
Mail list logo
