Sorry, wrong address.
On Sat, Jul 12, 2014 at 10:55 AM, Eric Seidel wrote:
> I used to use http://isitup.org/ to watch the front page. It would be
> trivial to extend the QueueStatusServer code to provide easier patches
> for services like isitup to watch:
> https://github.com/W
I should clarify that although Blink is very interested in
implementing more of the DOM in JS, we haven't actually shipped any of
that yet:
https://docs.google.com/a/google.com/document/d/13cT9Klgvt_ciAR3ONGvzKvw6fz9-f6E0FrqYFqfoc8Y/edit#
We have to prove that it works (and can be made safe) first
As Maciej notes, this is not the right mailing list to ask these sorts
of things. But since the answer appears simple, here it is:
http://en.wikipedia.org/wiki/Safari_version_history claims that Safari
5.1.8 means WebKit 534.58.2
which theoretically comes from:
http://trac.webkit.org/browser/bran
FWIW, Blink is going through this right now too. We're attempting to
move completely away from prefixed development:
http://www.chromium.org/blink#vendor-prefixes
To do that, that requires making it possible enable/disable CSS
properties at runtime:
https://code.google.com/p/chromium/issues/detai
write their respective bindings generators in,
perhaps we'll end up using the same parser library.
Best of luck!
On Wed, Apr 10, 2013 at 3:36 PM, Eric Seidel wrote:
> I know some folks in our TOK office have expressed strong interest in
> re-writing it in python for Blink. Perhaps there i
I know some folks in our TOK office have expressed strong interest in
re-writing it in python for Blink. Perhaps there is an opportunity
for some x-project collaboration here.
On Wed, Apr 10, 2013 at 3:32 PM, Ryosuke Niwa wrote:
> Hi,
>
> Can we rewrite CodeGenerator*.pm in Ruby or Python? I fe
blem while also continuing to recognize the
> person within the project. It's symbolic, and it feels nicer than just
> wiping them from the system.
>
> The fact that it serves the purpose of supporting lookup (your point (2)) is
> good, also.
>
> -Filip
>
>
>
>
Unrelated to Dmitry's suggestion, but since I brought up "emeritus
contributors" earlier in the thread, I should explain my usage. The
"emeritus" class proposed in the ancient webkit-reviewers thread about
sunsetting was simply to answer the fact that committers.py has two
purposes:
1. It exists
Sorry. Wrong address again.
On Fri, Apr 5, 2013 at 12:09 AM, Eric Seidel wrote:
> Neither here nor there, but...
>
> I had interest in sunsetting committers/reviewers in the past. There
> are loads of folks listed in committers.py who haven't committed or
> reviewed in
Neither here nor there, but...
I had interest in sunsetting committers/reviewers in the past. There
are loads of folks listed in committers.py who haven't committed or
reviewed in 5+ years. I believe there are some old threads on
webkit-reviewers about such.
I believe the timeout for sunsetting
Resent from the right address.
On Thu, Apr 4, 2013 at 1:09 PM, Eric Seidel wrote:
> We're ready to turn down the cr-linux EWS bots at your command.
>
> Just let us know (via email or #webkit). Thanks!
>
> On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen wrote:
>> To
We're ready to turn down the cr-linux EWS bots at your command.
Just let us know (via email or #webkit). Thanks!
On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen wrote:
> To clarify:
>
> (1) The EWS bots are still running.
>
> (2) The mac and mac-wk2 EWS bots are running tests, and passing.
>
>
We'll be in #webkit and happy to be helpful in any way we can.
I considered posting patches to remove *Chromium files yesterday
afternoon, but then abarth reminded me that the commit-queue currently
uses chromium-linux. I spoke with rniwa at some length yesterday in
#webkit about transitioning th
I’m writing to say thank you, personally, and on behalf of the Chromium project.
Chromium could not have happened without WebKit and the help of its
contributors.
As you likely have seen, Adam just posted
http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html
announcing Blink,
things we have (ex. the 600 template expansions from StyleBuilder)
>
>
> On Fri, Mar 22, 2013 at 5:22 AM, Eric Seidel wrote:
>>
>> It seems like it should be trivial to set up an EWS bot to track size
>> changes.
>>
>> It would (sadly) need to clobber, as m
It seems like it should be trivial to set up an EWS bot to track size changes.
It would (sadly) need to clobber, as my understanding is that
incremental builds are not deterministic in their sizes:
https://code.google.com/p/chromium/issues/detail?id=110002
(our bug about this for Chromium Try serv
Thank you very much for making the uploads (and thus the flaky test
reporter) work again!
On Thu, Mar 21, 2013 at 2:52 PM, Ryosuke Niwa wrote:
> On Thu, Mar 21, 2013 at 2:50 PM, Eric Seidel wrote:
>>
>> I think to expect folks to use these results, we're going to need to
>
I think to expect folks to use these results, we're going to need to
give them nice tools, like:
https://bugs.webkit.org/show_bug.cgi?id=92033
On Thu, Mar 21, 2013 at 10:55 AM, Ryosuke Niwa wrote:
> Fixed it in http://trac.webkit.org/changeset/146443.
>
> So yeah, don't add entries for rebaseline
Thanks for following up Philip. I don't feel like this thread met
much consensus, more just went off into the weeds.
Given the history of that page, I'm not sure it truly reflects the
consensus of the project:
https://trac.webkit.org/wiki/CreatingLayoutTests?action=history
> Regardless of wheth
May our generated content (and general render safety and speed) live
long and prosper. :)
Grats Elliot!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
As of http://trac.webkit.org/changeset/144719
--profile and --profiler= work in run-webkit-tests, just like they do in
run-perf-tests.
For example you can find out why your/favorite/tests are so slow with:
run-webkit-tests your/favorite/tests --profile
RWT will sample each DRT instance and print
Nice to have another hand for SVG reviews. :)
Grats to pdr!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
I've noticed as of late several different approaches being used when
adding/changing LayoutTests which need rebaselining on other platforms.
Obviously we cannot expect developers to test/rebaseline on all platforms
before landing given our current infrastructure.
But what should we expect them to
I have no objection to us using this compiler feature.
On Fri, Feb 22, 2013 at 2:35 PM, Julien Chaffraix wrote:
> Hi WebKit folks,
>
> over several reviews, I have been saying that the following line is a
> coding style violation:
>
> firstVariable = secondVariable = 0;
>
> For a concrete example
On Sun, Feb 17, 2013 at 10:07 PM, Eric Seidel wrote:
> On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak wrote:
>>
>> There's probably proportionately more people using Git. Making these web
>> surveys is a pain, so I'd rather not do it again if we don't n
ons. It just crossed my mind for whatever reason
again this evening.
> (For current svn users I assume using svn would become effectively
> impossible; the only tool I could find to do this is server-side and
> essentially maintains git and svn repositories in parallel.)
>
> - M
I wonder if the git-taking-over-the-project trend has continued a year later.
I'm also glad to see efforts like
https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing
on a simpler git workflow. :)
Thanks again for running the survey.
On Sat, Apr 7, 2012 at 4:58 PM, Maciej Stachowia
st was
found to be using too much memory and was terminated. This is likely
to cause a new process to be used for the next request to your
application. If you see this message frequently, you may have a memory
leak in your application.
On Sun, Feb 17, 2013 at 9:31 AM, Eric Seidel wrote:
>
App engine error perhaps?
http://webkit-commit-queue.appspot.com/active-bots
On Sun, Feb 17, 2013 at 4:15 AM, Mike West wrote:
> (Resending from the right address, sorry...)
>
> Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots
> apparently died about 13 hours ago: http:/
We've had this come up before, but I figure I should ask on webkit-dev
to see if we have a solution. :)
Right now the Tools/DumpRenderTree/DumpRenderTree.vcxproj/DumpRenderTree.sln
file is in some sort of bad state such that my Git checkout can't seem
to not-modify the file.
I'm not sure if it's
He's dead, Jim:
https://bugs.webkit.org/show_bug.cgi?id=107522
On Thu, Jan 17, 2013 at 5:54 PM, Maciej Stachowiak wrote:
>
> I think it's fine to shoot it in the head now. We do still want to come back
> to it eventually, but it's now apparent that we won't in the next 1.5 months.
>
> - Maciej
This entire email thread makes me sad.
I'm sad because we did this to ourselves (our porting systems/policies
are lacking), we did this very abruptly (the last port we kicked out
of webkit.org took a year?), and we don't have any clear policy for
this sort of thing (adding/removing ports in webkit
Having just spent all day removing NEW_XML cruft, I'm glad to see this
unused code go sooner rather than later. :)
On Mon, Feb 11, 2013 at 3:44 PM, Nico Weber wrote:
> Going once, going twice…
>
> https://bugs.webkit.org/show_bug.cgi?id=109501
>
> On Sat, Feb 2, 2013 at 3:09 PM, Sam Weinig wrot
I'm curious if YAML was ever considered? I have very limited
experience with YAML, except for Google App Engine config files.
It's very python parse-able? :)
On Tue, Feb 5, 2013 at 11:55 AM, Mark Mentovai wrote:
> You’re not supposed to use arbitrary Python, it’s highly discouraged. We
> have a
On Thu, Jan 31, 2013 at 4:16 AM, Alexis Menard wrote:
> On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel wrote:
>> I wish we only had one build system (it were easy to add/remove/move files).
>>
>> I believe changes like http://trac.webkit.org/changeset/74849 are an
>> unh
On Wed, Jan 30, 2013 at 3:24 PM, Patrick Gansterer wrote:
> Hi,
>
> Am 30.01.2013 um 22:28 schrieb Eric Seidel:
>
> I wish we only had one build system (it were easy to add/remove/move files).
>
>
> I've created CMake files for two different ports at [1] and [2] alre
On Wed, Jan 30, 2013 at 2:11 PM, Xan Lopez wrote:
> Hi Eric,
>
> On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel wrote:
>> I wish we didn’t have to worry about platforms we couldn’t test.
>>
>> It can’t be the job of the core maintainers to care about all the periphera
On Wed, Jan 30, 2013 at 1:57 PM, Maciej Stachowiak wrote:
>
> Hi Eric,
>
> These are great thoughts. I agree with you on all points. One informative
> comment below:
>
> On Jan 30, 2013, at 1:28 PM, Eric Seidel wrote:
>
> I wish we only had one build system (it were ea
On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo wrote:
> Thanks for sharing this.
>
> On Jan 30, 2013, at 1:28 PM, Eric Seidel wrote:
>
> I wish we only had one build system (it were easy to add/remove/move files).
>
> I believe changes like http://trac.webkit.org/changeset/748
WebCore
should ever be exported from WebKit on any port besides "Internals" symbols.
On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel wrote:
> What I've learned from this thread, is that AppleWin and AppleMac are the
> only two ports which require lists of exported symbols.
What I've learned from this thread, is that AppleWin and AppleMac are the
only two ports which require lists of exported symbols. If both were to
convert to using EXPORT decorators instead, then we could remove needs for
fixing export lists.
Please correct me if I've misunderstood.
Other ports (
+1
Ninja is beyond-words amazing. http://martine.github.com/ninja/ For
better or worse, it is not designed to use human-editable build files,
but rather to be used by a meta build system, like GYP or CMake. So
using ninja is really an orthogonal discussion to the "single build
system" discussio
I believe that it's a design mistake for WebCore to need to know
anything about it's embedder, more than that there is a defined set of
platform APIs and callbacks which it talks to (which should be the
exact same for every embedder).
(The export dependency dates back to the WebCore/WebKit separat
*I wish we only had one build system (it were easy to add/remove/move
files).*
*
I believe changes like http://trac.webkit.org/changeset/74849 are an
unhealthy sign for the project. Adam is not the only person who has chosen
to empty files instead of removing them. The pain of updating 8 build
sy
The future! Is now! :)
Very exciting. I hope some day we can use C++11 for the rest of WebCore too.
On Wed, Jan 30, 2013 at 12:17 PM, Anders Carlsson wrote:
> Hello!
>
> This is just a friendly heads-up that the Mac specific parts of WebKit2 will
> soon start requiring C++11 features (move se
Thank you for sharing!
It appears that unless you're logged into WordPress (I had to go dig
up my credentials) you just get a 404.
On Tue, Jan 29, 2013 at 6:17 PM, Dean Jackson wrote:
> Related: when the unprefixed transitions are enabled by default, we plan
> to make a long-overdue blog post o
This question came up in:
https://bugs.webkit.org/show_bug.cgi?id=92393
Do any ports still disable SVG? Should we be removing the ENABLE_SVG
defines (and potentially unifying SVG and HTML style resolve more
closely)?
___
webkit-dev mailing list
webkit-d
I'm surprised that chromium mac is 3x the size of Apple Mac... debug
even! Chromium build output should be much smaller... at least as of
late.
On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wrote:
> Here are the largest results sets on the master in GB. We currently store
> 6.8TB of total r
I can't easily rebase
on top of that, but that's a start.
On Thu, Jan 17, 2013 at 4:00 AM, Dominik Röttsches
wrote:
> On 01/16/2013 10:07 PM, Eric Seidel wrote:
>
> Do we know if there is a way to re-write our existing forks w/o
> pulling the whole repo down, just to push it bac
t; On Thu, Jan 17, 2013 at 11:50 AM, Eric Seidel wrote:
>> I believe the queue was actually cleared when they were brought
>> online. As Ossy notes, this is "expected behavior".
>>
>> Every time the feeder queue boots up (which is every 2 hours), it
&
I believe the queue was actually cleared when they were brought
online. As Ossy notes, this is "expected behavior".
Every time the feeder queue boots up (which is every 2 hours), it
sends *all* patches marked for review to queues.webkit.org.
queues.webkit.org makes sure that each individual EWS
Sorry. webkit-patch upload does not have very good error handling:
https://bugs.webkit.org/show_bug.cgi?id=72863
On Thu, Jan 17, 2013 at 10:49 AM, Raymond Toy wrote:
> Hmm. I have a git checkout of webkit so svn-create-patch doesn't want to
> work.
>
> Yeah, the patch is probably too big. The p
Do we know if there is a way to re-write our existing forks w/o
pulling the whole repo down, just to push it back up again? :)
On Wed, Jan 16, 2013 at 11:51 AM, Adam Barth wrote:
> If you were using GitHub to contribute to WebKit previously, you might
> want to delete your fork of https://github.
I believe https://bugs.webkit.org/show_bug.cgi?id=91237 is the bug
you're looking for.
I've CC'd relevant chrome folks.
As Maciej notes, webkit-dev isn't really the place for bug reports. :)
It's a mailing list of over 2000 people. Most of whom don't care
about specific SVG bugs.
Regardless, t
mple, would still be done entirely on
the main thread. I would imagine that when we were to land this on
trunk it would be behind a feature flag and ports could opt-in to the
threaded-parsing path, as we must maintain the main-thread parsing
ability for innerHTML anyway.
> --Oliver
>
> On
We're planning to move parts of the HTML Parser off of the main thread:
https://bugs.webkit.org/show_bug.cgi?id=106127
This is driven by our testing showing that HTML parsing on mobile is
be slow, and long (causing user-visible delays averaging 10 frames /
150ms).
https://bug-106127-attachments.we
ots down in the future.
Thanks.
On Wed, Dec 19, 2012 at 10:12 PM, Kiran Muppala wrote:
> Yup, the restart definitely fixed the issue. My patch progressed through
> the queue and landed.
>
> Thanks,
> Kiran
>
> On Dec 19, 2012, at 9:09 PM, Eric Seidel wrote:
>
> I did
No problem. Thanks for looking into it so quickly.
>
> - Kiran
>
> On Dec 19, 2012, at 8:55 PM, Eric Seidel wrote:
>
> The Feeder queue is down (and thus likely sherrifbot and the style-queue
> which are also hosted on the same EC2 instance). I'll see if I can restart
> it
The Feeder queue is down (and thus likely sherrifbot and the style-queue
which are also hosted on the same EC2 instance). I'll see if I can restart
it.
Thanks for letting me know.
On Wed, Dec 19, 2012 at 8:53 PM, Eric Seidel wrote:
> This time from @webkit.
>
>
> On Wed, Dec
This time from @webkit.
On Wed, Dec 19, 2012 at 8:52 PM, Eric Seidel wrote:
> Ouch. I'll take a look.
>
>
> On Wed, Dec 19, 2012 at 8:49 PM, Kiran Muppala wrote:
>
>> Hi folks,
>>
>> All the bots on WebKit commit queue are in a loop of "Starting Q
ueue". Because of this, no patches are being processed. Eric Seidel and
> Adam Barth, who usually manage the queue, I am told might be on vacation.
> if theres anyone else who can take a look at the commit queue bots, please
> do so.
>
> Thanks,
> Kiran
>
>
I recently added a --profile option to run-perf-tests to make it
easier to acquire cpu-profiles of PerformanceTests.
The option is available on Linux, Mac and Chromium Android.
You can see some minimal documentation here:
https://trac.webkit.org/wiki/Performance%20Tests#ProfilingPerformanceTests
tp://trac.webkit.org/changeset/137375
On Tue, Dec 11, 2012 at 3:33 PM, Eric Seidel wrote:
> This is now complete:
> http://trac.webkit.org/changeset/137371
>
> I'm watching the bots. Please contact me if you have any trouble.
>
> Thank you all for your feedback.
>
> On Mon, De
This is now complete:
http://trac.webkit.org/changeset/137371
I'm watching the bots. Please contact me if you have any trouble.
Thank you all for your feedback.
On Mon, Dec 10, 2012 at 10:11 AM, Dirk Pranke wrote:
> On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger wrote:
>> Will the buildbots
g. MSVS only after we
> roll the WebKit deps in chromium and one of the MSVS bots starts failing.
>
> Otherwise, I'm all for switching to ninja.
>
> best
> -jochen
>
> On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel wrote:
>>
>> If you don't work on the Ch
If you don't work on the Chromium port, feel free to ignore.
If you work on the Chromium port of WebKit and do not use Ninja as you
build system (GYP_GENERATORS='ninja' or update-webkit --chromium
--ninja) I want to hear from you!
As far as I can tell, the vast majority of Chromium contributors
clean -dxf
>> git pull
>>
>> These lines always helped me if something went wrong on my git repository.
>>
>> Ossy
>>
>> Eric Seidel írta:
>>
>>> An example of the git failures can be found here:
>>> http://queues.webkit.org/results/15120956
On Tue, Dec 4, 2012 at 12:39 PM, Eric Seidel wrote:
> An example of the git failures can be found here:
> http://queues.webkit.org/results/15120956
>
> (For any with git-knowledge who might know what's wrong.)
>
> On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth wrote:
>&
An example of the git failures can be found here:
http://queues.webkit.org/results/15120956
(For any with git-knowledge who might know what's wrong.)
On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth wrote:
> There's some problem with the commit-queue failing with some git
> error. I'm taking it offl
> In any case, if the github repo is the way to go now, then we will do the
> transition...
>
> Thanks,
> Gergely
>
>
>
> On Sat, Nov 24, 2012 at 10:48 PM, Eric Seidel wrote:
>>
>> This has come up in the past. I believe the current recommended path
This has come up in the past. I believe the current recommended path
is to use the github.com SHAs and just live in a github-only world.
https://lists.webkit.org/pipermail/webkit-dev/2012-March/020002.html
has some discussion.
https://trac.webkit.org/wiki/UsingGitHub
I am not aware of any plan t
RenderArena was a perf optimization for the rendering tree, which
hyatt imported from Mozilla 10 years ago:
http://trac.webkit.org/changeset/2635
The prevailing lore has long been that RenderArena is no longer
useful, ugly, and should be killed!
http://www.mail-archive.com/webkit-dev@lists.webkit.
Does seem pretty simple.
is even shorter. :)
I support getting rid of pixel tests. I suspect that some very dumb
scripts could turn large chunks of these existing pixel-tests into
ref-tests. I doubt that those would be the interesting ones though
(where platforms have divergent results)
Entertainingly, Adam taught me to reach GOM through TestFailures:
http://build.webkit.org/TestFailures/garden-o-matic.html
On Mon, Nov 5, 2012 at 12:52 PM, Simon Fraser wrote:
> I use it from time to time, but I think we really need merge it with
> garden-o-matic; they do much of the same stuff.
My understanding was that *Inlines/*InlineMethods were more about
limiting includes in the main header. Maybe that's just a happy side
effect. :)
I also prefer the *Inlines naming. :)
On Fri, Nov 2, 2012 at 5:48 PM, Mark Lam wrote:
> FYI, some time in the near future (maybe this weekend), I pla
Now with feeling.
On Wed, Oct 24, 2012 at 12:51 PM, Eric Seidel wrote:
> We used to upload zips to bugs. But there is a built-in cutoff on
> that feature. I suspect that the zip size from the bots has just
> ballooned above that cut-off and fixing LayoutTestResults to only
>
oming little
>>> difficult to figure out whats the failure and whether its platform specific
>>> or not (i'm using Qt-linux and Windows).
>>>
>>>
>>> On Fri, Oct 5, 2012 at 11:20 PM, Eric Seidel wrote:
>>>>
>>>> I think t
Thank you both for the clarification.
On Sun, Oct 21, 2012 at 2:21 PM, Dirk Pranke wrote:
> On Sun, Oct 21, 2012 at 2:17 PM, Maciej Stachowiak wrote:
>>
>> Apple did not ship the last release of Safari to SnowLeopard and we have no
>> plans to maintain SnowLeopard support on trunk. We haven't a
Is Snow Leopard deprecated?
Dave (WebKit's MathML guy) is reporting trouble building the Apple Mac
port on Snow Leopard. We don't seem to have a Snow Leopard bot on:
http://build.webkit.org/console?category=AppleMac
so it seems totally concievable that it's broken.
If it is deprecated, I'm happy
Bill and I have talked about this in the past. I don't remember what
the outcome was. Right now webkit-patch just uses Mechanize:
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/net/bugzilla
We also might get some of this as part of the upgrade:
https://bugs.webkit.org/show_bug
Does that mean our fallback graph is now finally a tree?? :)
https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit
On Wed, Oct 17, 2012 at 8:15 PM, Dirk Pranke wrote:
> All of the Chromium ports will use baselines in their port-specific
> directories, then fall bac
I think that's an interesting idea. The bots don't have a mail
server. :) But we could presumably wire up some sort of service for
them.
On Thu, Oct 4, 2012 at 6:41 PM, Emil A Eklund wrote:
> What if we mail the zip files to the person that uploaded the patch?
> That way the responsibility of m
Done.
On Fri, Oct 5, 2012 at 7:49 AM, Mihai Balan wrote:
> Hello,
>
> Can anyone help me adding a new BugZilla keyword (as those over at
> https://bugs.webkit.org/describekeywords.cgi )? We’d like it named
> AdobeTracked. I need it for marking bugs that Adobe contributors are
> actively working o
t is confusing the
>> code that finds the path to run-webkit-tests. Does
>> /Users/darin/Safari/Internal/Tools/Scripts/../../../OpenSource/Tools/Scripts/run-webkit-tests
>> actually exist or is that path incorrect?
>
> That path is correct, although I don’t know where it’s co
at 9:19 AM, Eric Seidel wrote:
> That stack is confusing.
>
> It looks like it's in Mac._build_java_test_support:
>
> http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/mac.py#L133
>
> But that shouldn't be trying to execute run-webkit-tests?
That stack is confusing.
It looks like it's in Mac._build_java_test_support:
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/mac.py#L133
But that shouldn't be trying to execute run-webkit-tests?
Perhaps make is missing? or the java directory its trying to build is
I would agree with Adam, and the more we can move to window.internals,
the less technical debt we incur with each new DRT feature.
I would love to see overridePreferences go away (or only be used for
preferences which need to test the WebKit-side plumbing).
TestExpectation files on all ports are
When overridePreferences was added back in the day:
http://trac.webkit.org/changeset/39212
The contract was that DRT would call resetDefaults between tests. I
don't know what the current status of resetToDefaults implementations
in other ports or in non-WK1 architectures.
On Wed, Sep 26, 2012 at
My understanding is that a name collision would only affect the
ability of existing software to use the new Path. It would not break
existing software. window.Path would just be aliased by the page, no?
On Mon, Sep 24, 2012 at 3:02 PM, Maciej Stachowiak wrote:
>
> I'm not hung up on the name. B
I was noticing today that http://www.webkit.org/ is quite old and out
of date. What xenon built 6 years ago, has stood up remarkably well,
but it may be time for a refresh.
(It also has no high-dpi support.)
I'm aware that I have the ability to change it. But I'm also inviting
others to do so:
h
On Mon, Sep 17, 2012 at 6:35 PM, Benjamin Poulain wrote:
> On Mon, Sep 17, 2012 at 4:11 PM, James Hawkins
> wrote:
>>
>> A few details:
>> * Google will front the cost of the license (non-zero...very far from
>> zero) and the infrastructure.
>> * I'd leave it up to the WebKit leadership to decide
I wish to subscribe to this product and or service. Count me in.
I'm not particularly worried about who has access. But maybe I should
be? Its not like the bad-guys can't run coverity themselves.
On Mon, Sep 17, 2012 at 6:11 PM, James Hawkins wrote:
> Hey folks,
>
> TL;DR - If you have opinio
The cr-linux bots used to upload the results to the bug itself. Maybe
that changed?
On Tue, Sep 11, 2012 at 3:20 PM, Adam Barth wrote:
> Currently, there's no way to get results from the bots. You might
> need to land your patch and see what the bots on build.webkit.org tell
> you.
>
> Adam
>
>
The wiki might also note that:
String bar = ASCIILiteral("foo");
is not free. :) There is still a malloc() of a StringImpl under there.
On Mon, Aug 27, 2012 at 12:26 PM, Benjamin Poulain wrote:
> On Sun, Aug 26, 2012 at 10:15 AM, Ojan Vafai wrote:
>>
>> So, is the rule something like "Use ASC
Checking back in:
Curious if this effort is still underway. Adam and I would like to
delete the New XML Parser if it's not needed in order to simplify the
HTML 5 Parser again. :)
On Thu, Mar 15, 2012 at 1:58 PM, Maciej Stachowiak wrote:
>
> On Mar 15, 2012, at 1:29 PM, Eric S
Sorry, I was unclear. I haven't seen someone create a new enum using
E in years. LineBreakType or similar would be better than
ELineBreakType.
On Thu, Aug 23, 2012 at 11:57 PM, Eric Seidel wrote:
> E is an old style from KHTML.
>
> We should update our style guide to say mor
E is an old style from KHTML.
We should update our style guide to say more than it does. :)
"Enum members should user InterCaps with an initial capital letter.
[names-enum-members]"
On Thu, Aug 23, 2012 at 11:53 PM, Glenn Adams wrote:
> I'm implementing a patch for [1], namely to support the CS
I'm attempting to fix some repaint bugs in WebKit, thus I'm using the
--pixel tests.
run-webkit-tests -p fast/repaint
shows a bunch of failures on my Mac Lion box.
I'd like to fix those failures, but I'm not sure what the proper procedure is.
run-webkit-tests -p fast/repaint --reset-results
c
Do we know what ports have CSS3_FLEXBOX enabled?
On Fri, Aug 17, 2012 at 6:47 PM, Ojan Vafai wrote:
> Next week we plan to remove the CSS3_FLEXBOX define again. We had added it
> back in because the spec was about to change a lot (mostly renaming). At
> this point the spec is stable and has been
Since it sounds like it doesn't do anything, then yes. Removing it
sounds like the correct course of action. Someone who later
implements ::marker or lands CSS3-list tests, can revert your patch.
On Wed, Aug 15, 2012 at 2:29 PM, Elliott Sprehn wrote:
> WebKit is the only browser that implements
1 - 100 of 926 matches
Mail list logo
