Re: [webkit-dev] [cmake] Proposal: Move commonly used platform-dependent files in WebCore to .cmake include files.

[Michael Catanzaro]

I'm curious what Martin and Alex think about this. It seems fine to me;
the downside is there are more CMake files to maintain, the upside is
the big ones should be slightly smaller, and we can reduce duplication
between PlatformEFL.cmake and PlatformGTK.cmake.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Web inspector images

[Timothy Hatcher]

Hi Michael,

I am looking into our options for the license of the images. Stay tuned.

— Timothy Hatcher

> On Feb 6, 2016, at 8:23 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> I'd like to address the problem with the license for the web inspector
> images. The background on this is that a WebKitGTK+ release was
> rejected by the legal department of one of our distributors after it
> discovered the file Source/WebInspectorUI/APPLE_IMAGES_LICENSE.rtf,
> which covers the images under
> Source/WebInspectorUI/UserInterface/Images. From a cursory glance at
> the license, it's clear that not only is this license not open source
> compatible (and therefore not compatible with the acceptable content
> policies of major WebKitGTK+ distributors), the images are also not
> distributable. I don't believe this is consistent with the values of
> the WebKit open source project.
> 
> In response to this issue, we created similar but freely-licensed
> replacement images under
> Source/WebInspectorUI/UserInterface/Images/gtk, took down our hosted
> tarballs for several previous WebKitGTK+ releases, reissued those
> tarballs with the images replaced, and posted a notice to alert some of
> our distributors to the issue. This was sufficient for our port, so we
> just... stopped at that. But it would be good if other ports did not
> have to address this problem individually, especially since there is no
> obvious warning when downloading WebKit as to the legal status of this
> content.
> 
> Since the images are not usable except by Apple, it would be nice to
> remove these images from the public repository to reduce the risk of
> other ports accidentally including these image files. Therefore, I
> propose to simply overwrite the images under Images with the images
> under Images/gtk. As part of this, we would need to create a few new
> images that do not currently exist under Images/gtk. Also, Apple's
> internal build process would need to be modified to include the Apple
> images from elsewhere.
> 
> If I am remembering correctly, I spoke to Joe Pecoraro about this at
> the WebKit Contributors Meeting, and he liked this idea. Would anyone
> object to this change?
> 
> A couple alternative solutions:
> 
>  * Apple could relicense its images. I suspect the set of similar but
> freely-licensed gtk images defeats the purpose of using a restrictive
> license for the Apple images. This would be the best solution.
> Possible?
> 
> * We could move the license file up from WebInspectorImages to the
> toplevel project directory. This would make it very difficult to
> accidentally distribute the Apple images without knowing the license.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Fwd: Some text about the B3 compiler

[Ryosuke Niwa]

-- Forwarded message --
From: Ryosuke Niwa 
Date: Wed, Feb 3, 2016 at 4:18 PM
Subject: Re: [webkit-dev] Some text about the B3 compiler
To: Carlos Alberto Lopez Perez 


On Tue, Feb 2, 2016 at 4:56 PM, Carlos Alberto Lopez Perez
 wrote:
> On 02/02/16 19:58, Ryosuke Niwa wrote:
>> On Tue, Feb 2, 2016 at 10:42 AM, Carlos Alberto Lopez Perez
>>> But this script seems focused on comparing the performance between
>>> different browsers (safari vs chrome vs firefox) rather than in testing
>>> and comparing the performance between different revisions of WebKit.
>>
>> Not at all.  It simply supports running benchmark in other browsers.
>>
>>> Do you think it makes any difference (from the point of view of
>>> detecting failures, not from the performance PoV) to run this tests in a
>>> full-fledged browser like Safari rather than in WebKitTestRunner ?
>>
>> Yes. There are many browser features that can significantly impact the
>> real world performance.
>>
>
> I'm specifically not asking about performance, but about correctness.

WebKitTestRunner and Safari load pages differently so I wouldn't be
surprised even if there were differences.

One of the most important difference is that WebKitTestRunner is
hidden outside the viewport by default
but any graphics benchmark ran this way may not accurately measure the
performance since GPU
may not be pushing anything to the screen and avoiding to do some work.

However, the primary use of benchmarks is to keep track of performance,
and for that purpose, WebKitTestRunner is not adequate for our purpose.

> This discussion was started because Filip said that running JS tests on
> a browser catches many failures that are not cached when running the
> tests from the terminal.
>
> So, I'm wondering if running the JS tests on WTR or Safari makes any
> difference when catching failures.

For that purpose, WebKitTestRunner is probably good enough.

You can probably add a new driver code in benchmark_runner code to
support it easily
since the framework is designed to be generic enough to even support
other non-WebKit-based browsers.

>>> We already have a performance test bot running tests inside WTR.
>>> And I see that the current set of tests executed on this bot already
>>> includes Speedometer, and that JetStream and Sunspider are skipped on
>>> PerformanceTests/Skipped.
>>>
>>> So I see some options going forward:
>>>
>>>  - Fix the JetStream and Sunspider tests so they can be run as part of
>>> the current run-perf-tests script that the performance bots execute.
>>
>> We should use run-benchmark instead since run-benchmark spits out the
>> JSON file that's compatible with run-pref-tests.
>>
>
> I'm a bit lost here. Are you planning to deprecate run-perf-tests with
> run-benchmark? What is wrong with run-perf-tests?

No.  run-perf-tests will be maintained to keep running our micro perf
tests as they have proven to be useful for keeping track of some
performance.  run-benchmark is a new tool that allows us to easily run
third-party benchmarks which doesn't require the use of runner.js
script or WebKitTestRunner features.

>>>  - Implement support on the script run-benchmark to run the tests inside
>>> WTR, and create a new step running this script that will be executed on
>>> the test bots.
>>
>> I don't see a point in doing this.   Why is it desirable to run these
>> benchmarks inside WebKitTestRunner?
>>
>
> Less dependencies: WTR (or the MiniBrowser) is something that is
> currently built by the bots on each build.
> If we want to use Epiphany (for example) for the performance tests, is
> another thing we have to take care of building before each run. Not a
> big deal, but I wonder if is really worth.

I see.  You can easily write a new browser driver for MiniBrowser or
WebKitTestRunner.

>>>  - Deploy a new bot that runs run-perf-tests on a full-fledged browser
>>> like Safari or Epiphany.
>>
>> We should just do this.
>>
>>> I wonder what you think is the best option or if there is some option
>>> not viable.
>>>
>>> From my PoV, the option #1 has the advantage of reusing the current
>>> infrastructure that collects and draws performance data at
>>> https://perf.webkit.org
>>
>> We have an internal instance of the same dashboard to which we're
>> reporting results of run-benchmark script.
>>
>
> What about making this public? We will happily contribute with a
> GTK+/Linux buildbot for it.

We can't since it contains proprietary data.

However, the perf dashboard we use internally is identical to the one
deployed at perf.webkit.org so we should be able to submit results to
perf.webkit.org from run-benchmark easily.  (we probably just need to
copy & paste some code in run-perf-tests).

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [cmake] Proposal: Move commonly used platform-dependent files in WebCore to .cmake include files.

[Alex Christensen]

Let’s go for it.  Less duplication is a good thing.  The only downside is the 
occasional “Which CMake file do I add this to?” but that should be just as 
straightforward as adding the file to multiple platform cmake files, if not 
more.
> On Feb 9, 2016, at 10:44 AM, Michael Catanzaro  wrote:
> 
> I'm curious what Martin and Alex think about this. It seems fine to me;
> the downside is there are more CMake files to maintain, the upside is
> the big ones should be slightly smaller, and we can reduce duplication
> between PlatformEFL.cmake and PlatformGTK.cmake.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Change WTFCrash to not trash the crash site register state.

[Geoffrey Garen]

I like this change.

Perhaps all ports can adopt this behavior. 

Geoff

> On Feb 8, 2016, at 11:55 AM, Mark Lam  wrote:
> 
> Hi WebKit folks,
> 
> For non-debug OS(DARWIN) builds, I would like to change WTFCrash()’s 
> implementation into an inlined function that has a single inlined asm 
> statement that issues a breakpoint trap.  The intent is to crash directly in 
> the caller’s frame and preserve the register values at the time of the crash. 
>  As a result, for non-debug OS(DARWIN) builds, crashes due to failed 
> RELEASE_ASSERTs will now show up in crash reports as crashing due to 
> EXC_BREAKPOINT (SIGTRAP) instead of a EXC_BAD_ACCESS (SIGSEGV) on address 
> 0xbbadbeef.
> 
> This is in contrast to the current implementation where WTFCrash() is a 
> function that calls a lot of handler / callback functions before actually 
> crashing.  As a result, by the time it crashes, the caller’s register values 
> has most likely been trashed by all the work that the WTFCrash and the 
> handlers / callbacks do.  The register values in the captured crash report 
> will, therefore, no longer be useful for crash site analysis. 
> 
> You can find the patch for this change at 
> https://bugs.webkit.org/show_bug.cgi?id=153996.  This change will only be 
> applied for non-debug OS(DARWIN) builds for now.  I’m leaving all other build 
> build configurations with the existing WTFCrash() implementation and behavior.
> 
> Does anyone have any opinion / feedback on this change?
> 
> Thanks.
> 
> Regards,
> Mark
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] [cmake] Proposal: Move commonly used platform-dependent files in WebCore to .cmake include files.

[Konstantin Tokarev]

Hello WebKit,

Currently there is a number of files in WebCore that a shared between 2 or more 
ports (but not all of them). Here are a few examples:

* texmap, gstreamer, openwebrtc, soup, stuff in platform/linux - shared between 
GTK and Efl
* cairo, image-decoders - shared between GTK, Efl, and WinCairo

I propose to move code related to these subsystems from Platform*.cmake files 
to separate CMake files included into those, like this:

platform/texmap.cmake
platform/gstreamer.cmake
platform/image-decoders.cmake
platform/linux.cmake
...

Alternatively, this code could be moved into main CMakeLists.txt of WebCore, 
however I believe this approach is inferior since it will add unnecessary 
clutter to CMakeLists.txt while not all ports need this code.

What do you think? If no objections, I'm going to submit patches implementing 4 
files listed above.

Proposals on better file placement/naming would be highly welcome.

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Eric Wing]

On 2/7/16, Konstantin Tokarev  wrote:
> Please try updated version of my branch, it now does not use LLVM unless you
> enable USE_LLVM_DISASSEMBLER.

I merged your branch. That seemed to build and work.
So what would USE_LLVM_DISAAEMBLER get me if I could build it?
Also, are there things I can do to shrink JavaScriptCore? It's now
over 20MB. I know ICU is a big part of that, but JSC itself seems to
keep getting bigger too.

To respond to a prior suggestion about ICU size, I am familiar with
the data archive option. However, there are several challenges with
that:
- I don't know what parts JSC actually needs to know what I can safely remove
- I don't know how ICU/JSC load the data archive. Android APK file
semantics are pretty terrible and you have to send around a Java
AsssetManager to access everything. Standard file library calls don't
'just work'.
- I really need to build as a static library because since it is a
private implementation detail of JSC. There are problems if somebody
downstream of me wants to use ICU, with a potentially different
version. If I dynamically link and use data archives, I open up a lot
of conflict issues. Similarly, Android itself may use ICU internally
and I've been warned of conflict problems by others. Static linking
avoids these headaches. Also, I haven't figured out if data archive
and static libraries are compatible.
- I did notice Apple has a modified, stripped down version of ICU as
part of Darwin. I was unable to figure out how to get it built. It was
a pretty complicated Makefile.


Thanks,
Eric

P.S.
Here is an indentation fix for my previous ICU patch.
https://github.com/ewmailing/webkit/commit/e2c94e8b126143402b4e17cc514c4df412de5ace
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev