On Friday, April 05, 2013 09:24:59 AM Geoffrey Garen wrote:
> Hi Mario.
>
> > First of all, let me say upfront that I see all the potential advantages
> > of
> > sticking to just one JS engine, and also perfectly understand the points
> > that most of the people here have made on favour of not sup
On Apr 5, 2013, at 5:25 AM, Mario Sanchez Prada wrote:
>
> Also, my mail was not really a formal request to keep the V8 bits around in
> the long term, but just a quick reply to the following comment from Maciej:
>
> """
> Geoff posted the list in part because we'd like to know
> If any of
On Friday 05 April 2013, Max Stepin wrote:
> > To me it looks more like it requires 0.3.0 to enable color correction.
> > Older ABIs are still supported.
>
> Yes, but some WebP images (created with 0.3.0) will not work.
> I tried, not even the first frame is displayed.
>
> Would it be OK to just
> To me it looks more like it requires 0.3.0 to enable color correction.
> Older ABIs are still supported.
Yes, but some WebP images (created with 0.3.0) will not work.
I tried, not even the first frame is displayed.
Would it be OK to just take future WEBPImageDecoder.cpp updates from Chromium?
_
On Friday 05 April 2013, Max Stepin wrote:
> Also, WebP project is unfinished state right now. This changeset requires
> libwebp version 0.3.0:
> https://trac.webkit.org/changeset/147048
>
To me it looks more like it requires 0.3.0 to enable color correction. Older
ABIs are still supported.
`All
Hi Mario.
> First of all, let me say upfront that I see all the potential advantages of
> sticking to just one JS engine, and also perfectly understand the points
> that most of the people here have made on favour of not supporting multiple
> engines.
>
> Also, my mail was not really a formal req
Also, WebP project is unfinished state right now. This changeset requires
libwebp version 0.3.0:
https://trac.webkit.org/changeset/147048
But version 0.3.0 also supports animated webp, and google doesn't have the
code for animation support in WEBPImageDecoder.cpp yet, not even in
Chromium.
So thi
On Qui, 2013-04-04 at 18:46 +0200, Balazs Kelemen wrote:
> >> FWIW, mrobinson has been working on a GYP build for the GTK port, so I
> >> wouldn't delete all of the .gyp files (at least not w/o them weighing
> >> in on it). I thought there was some interest at Apple in also using
> >> GYP, but perh
Hi Geoff,
First of all, let me say upfront that I see all the potential advantages of
sticking to just one JS engine, and also perfectly understand the points
that most of the people here have made on favour of not supporting multiple
engines.
Also, my mail was not really a formal request to keep
Hi,
The Qt port of WebKit (based on Qt 5.x) does not use v8.
(Qt 5.x uses v8 in other places, but that is not relevant to the WebKit project
and this discussion)
Simon
Markus wrote:
> For the record though I don't think Qt is using any of that those.
Qt 5.x uses V8.
___
On Apr 4, 2013, at 4:54 PM, Per Bothner wrote:
> On 04/04/2013 10:21 AM, Oliver Hunt wrote:
>> Supporting V8 places a considerable burden on webkit, there are a number of
>> large, cumbersome and expensive abstractions required for to support multiple
>> JS engines (see the original discussions
On Thu, Apr 4, 2013 at 6:01 PM, Markus wrote:
> > For the record though I don't think Qt is using any of that those.
>
> Qt 5.x uses V8.
QML uses V8. That does not matter for WebKit.
QtWebKit uses exclusively JSC.
Benjamin
___
webkit-dev mailing list
> For the record though I don't think Qt is using any of that those.
Qt 5.x uses V8.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Supporting multiple JS engines is a major burden, and prevents us from doing
optimizations that more seamlessly bridge the gap between DOM and JSC. I
suspect we won't want to continue supporting multiple JS engines like we did
when the Chrome folks used WebKit with V8.
-Filip
On Apr 4, 2013,
On 04/04/2013 10:21 AM, Oliver Hunt wrote:
Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the original discussions on the topic from many years ago).
We at Oracle are worki
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.
>
> (3) The cr-linux bots are running tests, and failing.
>
> If we're OK with item (3), we can go ahead with cleaning
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 clarify:
>>
>> (1) The EWS bo
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.
>
>
Hi,
On Apr 4, 2013, at 12:50 PM, Geoffrey Garen wrote:
> (3) The cr-linux bots are running tests, and failing.
>
> If we're OK with item (3), we can go ahead with cleaning house, and break the
> cr-* EWS bots entirely, while we work on making the mac and mac-wk2 EWS bots
> faster.
+1
-Brent
On Thu, Apr 4, 2013 at 1: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.
>
> (3) The cr-linux bots are running tests, and failing.
>
> If we're OK with item (3), we can go ahead with cleaning h
To clarify:
(1) The EWS bots are still running.
(2) The mac and mac-wk2 EWS bots are running tests, and passing.
(3) The cr-linux bots are running tests, and failing.
If we're OK with item (3), we can go ahead with cleaning house, and break the
cr-* EWS bots entirely, while we work on making t
On Thu, Apr 4, 2013 at 1:44 PM, Filip Pizlo wrote:
> Sent from my PDP-11
>
11/20? 11/40? RSX-11? RT-11? Love the split I/D memory on 11/70s.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
I think everyone is agreeing that we should have a suitable replacement for
EWS.
But I also want to see us move forward with clean ups. I think such clean ups
will bring clarity to what we would want our EWS testing to look like since
we'll have fewer configurations to test.
I like the appro
Hi folks,
I definitely do not want to see the EWS system go away. But in the short term ,
I would be in favor of manual commits and manual testing.
We still have the build bots running tests, so it's not like we lose all
coverage.
Thanks,
-Brent
Sent from my iPhone
On Apr 4, 2013, at 11:56
On Thu, Apr 4, 2013 at 12:56 PM, Geoffrey Garen wrote:
> I'd also suggest purging the chromium layout tests ASAP so we can enjoy
>> the much-reduced archive sync costs.
>>
>
> We really need to get the Mac or Win EWS performing tests by default and
> reliably before doing this. At present, only t
> I'd also suggest purging the chromium layout tests ASAP so we can enjoy the
> much-reduced archive sync costs.
>
> We really need to get the Mac or Win EWS performing tests by default and
> reliably before doing this. At present, only the chromium-linux EWS bot has
> been consistently running
On Thu, Apr 4, 2013 at 11:03 AM, Brent Fulgham wrote:
> I'd also suggest purging the chromium layout tests ASAP so we can enjoy
> the much-reduced archive sync costs.
>
We really need to get the Mac or Win EWS performing tests by default and
reliably before doing this. At present, only the chrom
On Apr 4, 2013, at 10:37 AM, Martin Robinson wrote:
> On Thu, Apr 4, 2013 at 10:34 AM, Geoffrey Garen wrote:
>> What would it take for WebKitGTK+ to adopt the JSC bindings?
>
> Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems
> there are some external branches/forks using V8
Hi Martin.
> Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems
> there are some external branches/forks using V8. In the past, we've
> rejected proposals to add V8 support to WebKitGTK+.
OK, I think that pretty much confirms that no WebKit contributors are
maintaining the v8 bi
> Is the process described in the
> DeprecatingFeatures article on the wiki still going to be followed?
Yes.
I'm generally talking about features that will fall under the "Cold turkey"
approach, based on rough consensus that they are either unsupported or unused.
Geoff
_
On Thu, Apr 4, 2013 at 10:34 AM, Geoffrey Garen wrote:
> What would it take for WebKitGTK+ to adopt the JSC bindings?
Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems
there are some external branches/forks using V8. In the past, we've
rejected proposals to add V8 support to Web
Hi Mario.
> Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
> only ones doing it, so it would be great to keep those guards there.
I've heard from others on the list, and I'd like to get your take on this, too.
Who do you envision maintaining the v8 bindings going forwar
Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the original discussions on the topic from many years ago).
Additionally we will only be supporting JSC in WebKit2, so I don't
On Apr 4, 2013, at 10:03 AM, Brent Fulgham wrote:
> I would strongly suggest purging V8, for the many performance and code
> complexity reasons Google is removing JSC from blink. (See
> www.chromium.org/blink/developer-faq)
+1
>
> I'd also suggest purging the chromium layout tests ASAP so
I would strongly suggest purging V8, for the many performance and code
complexity reasons Google is removing JSC from blink. (See
www.chromium.org/blink/developer-faq)
I'd also suggest purging the chromium layout tests ASAP so we can enjoy the
much-reduced archive sync costs.
-Brent
Sent from
On Apr 4, 2013, at 2:01 AM, Raphael Kubo da Costa wrote:
> Geoffrey Garen writes:
>
>> Also:
>> Adopt libc++
>
> My FreeBSD hat appreciates that, but can you elaborate? Is there
> something specific to libc++ not present in, say, libstdc++, that is
> going to be used?
I think this shoul
On Thu, Apr 4, 2013 at 3:56 AM, Mario Sanchez Prada wrote:
> > On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen
> wrote:
> > [...]
> > #if USE(V8)
> > #if !USE(JSC)
>
> Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
> only ones doing it, so it would be grea
On 04/04/2013 03:15 PM, Gustavo Noronha Silva wrote:
Hey,
On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote:
FWIW, mrobinson has been working on a GYP build for the GTK port, so I
wouldn't delete all of the .gyp files (at least not w/o them weighing
in on it). I thought there was some inter
Geoffrey Garen writes:
> Concepts we plan to remove:
> Features #defines that haven't gained traction
Do you already have anything in mind? Is the process described in the
DeprecatingFeatures article on the wiki still going to be followed?
--
Intel Finland Oy
Open Source Technology Center
> From: webkit-dev-boun...@lists.webkit.org
> [webkit-dev-boun...@lists.webkit.org] on behalf of Eric Seidel
> [e...@webkit.org]
> Sent: Thursday, April 04, 2013 9:41 AM
> To: Geoffrey Garen
> Cc: webkit-dev@lists.webkit.org Development
> Subject: Re: [webkit-dev]
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
Hey,
On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote:
> FWIW, mrobinson has been working on a GYP build for the GTK port, so I
> wouldn't delete all of the .gyp files (at least not w/o them weighing
> in on it). I thought there was some interest at Apple in also using
> GYP, but perhaps thin
Hi,
> On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen
wrote:
> [...]
> #if USE(V8)
> #if !USE(JSC)
Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
only ones doing it, so it would be great to keep those guards there.
> Geoff posted the list in part because
GoogleURL seems Chromium-specific, i.e. WTF_USE_GOOGLEURL is only defined
for Chromium in Source/WebCore/config.h.
Regards,
-Z
On Thu, Apr 4, 2013 at 10:50 AM, Maciej Stachowiak wrote:
>
> On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen
> wrote:
>
> On Thursday 04 April 2013, Geoffrey Garen
Geoffrey Garen writes:
> Also:
> Adopt libc++
My FreeBSD hat appreciates that, but can you elaborate? Is there
something specific to libc++ not present in, say, libstdc++, that is
going to be used?
--
Intel Finland Oy
Open Source Technology Center
On Thursday 04 April 2013, jpe...@gmx.at wrote:
> BlackBerry is moving away from Skia, a removal wouldn't hurt us at this
> point. With EFL being on cairo, it seems like that item can stay on the
> list.
>
Ah, right. Sorry for the confusion. I had the impression with all the places
Skia specific
On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen wrote:
> On Thursday 04 April 2013, Geoffrey Garen wrote:
>> Hi folks.
>>
>> Since we no longer need to support the Chromium port, let's take the
>> opportunity to streamline. Hopefully, this will make development easier
>> and more coherent for
BlackBerry is moving away from Skia, a removal wouldn't hurt us at this point. With EFL being on cairo, it seems like that item can stay on the list.- Jakob
@lists.webkit.org
Subject: Re: [webkit-dev] Cleaning House
On Thursday 04 April 2013, Geoffrey Garen wrote:
> Hi folks.
>
> Since we no longer need to support the Chromium port, let's take the
> opportunity to streamline. Hopefully, this will make development easier
> and more coheren
On Thursday 04 April 2013, Geoffrey Garen wrote:
> Hi folks.
>
> Since we no longer need to support the Chromium port, let's take the
> opportunity to streamline. Hopefully, this will make development easier
> and more coherent for everyone. Adam and Eric offered to do some of this
> cleanup, but
On Thu, Apr 4, 2013 at 12:30 AM, Geoffrey Garen wrote:
> Hi folks.
>
> Since we no longer need to support the Chromium port, let's take the
> opportunity to streamline. Hopefully, this will make development easier and
> more coherent for everyone. Adam and Eric offered to do some of this
> cleanu
Hi folks.
Since we no longer need to support the Chromium port, let's take the
opportunity to streamline. Hopefully, this will make development easier and
more coherent for everyone. Adam and Eric offered to do some of this cleanup,
but I think it's healthier for people who will continue to be
52 matches
Mail list logo
