On 24/04/17 21:02, Konstantin Tokarev wrote:
>
> 24.04.2017, 21:10, "Alex Christensen" :
>> Thanks for the data, Carlos! This is a growing problem that is hurting
>> productivity. We’ve discussed it a bit and haven’t done enough about it.
>> Here are some of the ideas I’ve heard:
>>
>> 1) Reduce
For the macOS and iOS ports, we have the additional problem of overhead from
the build system. Our make+xcodebuild based system takes a surprisingly long
time even for a no-op build, or for a small incremental "just changed this one
implementation file" build.
There's also some indication that
24.04.2017, 21:10, "Alex Christensen" :
> Thanks for the data, Carlos! This is a growing problem that is hurting
> productivity. We’ve discussed it a bit and haven’t done enough about it. Here
> are some of the ideas I’ve heard:
>
> 1) Reduce #includes by doing more forward declaring and less i
> On Apr 24, 2017, at 11:15, JF Bastien wrote:
>
> 1) Reduce #includes by doing more forward declaring and less inlining. We
> would probably need link time optimization to not lose performance benefits
> of inlining functions in headers.
>
> https://include-what-you-use.org/
> ?
I did some
On Mon, Apr 24, 2017 at 11:10 AM, Alex Christensen
wrote:
> Thanks for the data, Carlos! This is a growing problem that is hurting
> productivity. We’ve discussed it a bit and haven’t done enough about it.
> Here are some of the ideas I’ve heard:
>
> 1) Reduce #includes by doing more forward dec
Thanks for the data, Carlos! This is a growing problem that is hurting
productivity. We’ve discussed it a bit and haven’t done enough about it. Here
are some of the ideas I’ve heard:
1) Reduce #includes by doing more forward declaring and less inlining. We
would probably need link time optim
Le 24/04/2017 à 17:57, Brady Eidson a écrit :
>> I do *not* support adding another client of the C API, even in the
>> interim.
>
> It would be easier for us to move to the new API after the port is
> upstream, since it will require refactorings in both ports GTK+ and WPE
> . So, we can simply re
Hello,
I am hopping in as a WPE user.
The WPE port is gaining momentum in the set-top box world, and mainly
within the RDK consortium, which gathers many cable/TV/network operators
and software vendors.
The company I work for plans to deploy WPE on hundreds of thousands
set-top boxes soon, an
On Mon, Apr 24, 2017 at 10:57 AM, Brady Eidson
wrote:
In the coming weeks I am actually likely to be changing and/or
removing at least a few functions from the C-API.
As long as the WPE upstreaming effort is comfortable with the idea
that I might be breaking them as they go… That’s fine.
Ye
Hi,
Inspired by a similar thread on the Chromium mailing lists [1], I have
measured the build times of WebKitGTK+ over the past 2.5 years.
I benchmarked two different compilers (GCC and Clang).
The summary is: since September 2014 the time for building WebKitGTK+
has increased in a 62% for GCC 4
> On Apr 24, 2017, at 2:31 AM, Carlos Garcia Campos wrote:
>
> El dom, 23-04-2017 a las 22:12 -0700, Brady Eidson escribió:
>>> On Apr 22, 2017, at 6:21 AM, Michael Catanzaro >> om> wrote:
>>>
>>> I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API
>>> would be much better for us.
El dom, 23-04-2017 a las 22:12 -0700, Brady Eidson escribió:
> > On Apr 22, 2017, at 6:21 AM, Michael Catanzaro > om> wrote:
> >
> > I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API
> > would be much better for us.
>
> I as long as the GTK and WPE ports like this plan (it appears
12 matches
Mail list logo
