On Dec 14, 2010, at 4:57 AM, Steve Block wrote:
>> On the one hand, getting rid of ifdefs is good. On the other hand, it seems
>> to me there are some downsides to moving ports over to the client-based
>> approach:
> The motivation is much more than removing ifdefs. The original
> Geolocation i
On Dec 14, 2010, at 5:24 PM, Jake wrote:
> And secondly I changed all = 0 errors to = nullptr (approximately 450
> instances).
We should look for another way to make things compile with Visual Studio 2010
that does not require this.
-- Darin
___
Hello,
I've made some changes to the webkit trunk that allows me to build webkit
(more specifically QtWebkit) with Visual Studio 2010. I had to make several
changes to handle the ambiguous operator = error from NullPtr.h.
To get the build to work I made two primary changes:
First, NullPtr.h
#if
I've landed the patch which makes webkit-patch warn if you're using a
32-bit git on a 64-bit Mac. If anyone finds it too spammy, please let
me know and either I can find a way to lessen the log spam, or just
remove the warning entirely.
-eric
On Wed, Dec 8, 2010 at 2:20 PM, Eric Seidel wrote:
>
With 3 queues, a bunch of distcc processes, Chrome and several levels
of scripts, it's possible I'm hitting kern.maxprocperuid. I'll try
bumping it up from it's current 266 I guess.
-eric
On Tue, Dec 14, 2010 at 1:05 PM, Eric Seidel wrote:
> /Developer/usr/bin/../libexec/gcc/i686-apple-darwin10
/Developer/usr/bin/../libexec/gcc/i686-apple-darwin10/4.2.1/as: can't
fork a new process to execute:
/Developer/usr/bin/../libexec/gcc/darwin/x86_64/as (Resource
temporarily unavailable)
/Projects/CommitQueue/WebKitBuild/Release/DerivedSources/WebCore/JSHTMLAnchorElement.cpp:528:
fatal error: error
James Robinson and I* have been working on updating the pixel
baselines in platform/mac so that they pass on Snow Leopard (we've
been moving existing baselines to platform/mac-leopard so that things
still work on Leopard too). Having up to date pixel baselines is
helpful when making layout code cha
> On the one hand, getting rid of ifdefs is good. On the other hand, it seems
> to me there are some downsides to moving ports over to the client-based
> approach:
The motivation is much more than removing ifdefs. The original
Geolocation implementation was provided in WebCore/platform,
presumabl
> Just a general question as to why the decision was made to put the mock
> implementation classes (DeviceOrientationClientMock, GeolocationServiceMock
> and SpeechInputClientMock) beneath WebCore/platform.
I added the first mock class, GeolocationServiceMock , to allow
Geolocation to be tested in
On Tue, Dec 14, 2010 at 07:19, Kenneth Russell wrote:
> Hi all,
>
> Trying to check out a fresh WebKit tree on Windows using svn 1.6.6
> (also tried 1.6.1), I'm consistently getting the following error:
>
> svn: PROPFIND of
> '/repository/webkit/!svn/bc/19963/trunk/LayoutTests/fast/xpath/4XPath/Co
10 matches
Mail list logo
