Re: [webkit-dev] Running the GTK port on macOS with Docker

[Philippe Normand via webkit-dev]

Hi,

I found out that disk I/O is terribly slow on Docker for macOS. I had to
give up on my build after several hours because of that. So I tried
"Mutagen", wasn't able to make it work, and kind of gave up and moved to
the next thing on the pile of things to do... 

Today I just found one possible workaround, involving docker-sync. I'll
give this a try and report back.

Philippe

On 2021-11-23 06:02, Jean-Yves Avenard wrote:
> Hi
> 
> How is that effort going ?
> 
> Having a way to build the GTK port today would have saved me a lot of
> time. Instead I had to keep uploading patches to bugzilla to find
> compilation errors.
> 
> Jean-Yves
> 
>> On 15 Oct 2021, at 10:33 pm, Philippe Normand  wrote:
>>
>> On Fri, 2021-10-15 at 10:04 +1100, Jean-Yves Avenard wrote:
>>> Hi.
>>>
>>> Personally, I would love a way to quickly build for GTK on my Mac, as
>>> for now I had to rely on pushing to the EWS, wait for compilation
>>> errors and fix them as I went.
>>>
>>> So something running in docker using my local tree would be ideal.
>>>
>>
>> Alright, thanks for answering Jean-Yves :) I'll clean-up the experiment
>> a bit, document it and ping you for testing when it's ready.
>>
>> Philippe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] How to set up Intellisense-ish code completion/suggestions for editing WebKit sources on macOS?

[Philippe Normand via webkit-dev]

Hi Mike,

About ccls, some of us Igalians use it on Linux, I compiled a few
tips&tricks:

https://trac.webkit.org/wiki/WebKitEmacsTips

Nowadays trunk includes a .ccls file, is it not working for you?

Alicia recently blogged about setting up clangd/VSCode, that's on Linux,
but maybe some parts apply for macOS too:

https://blogs.igalia.com/aboya/2021/10/02/setting-up-visualstudio-code-to-work-with-webkitgtk-using-clangd/

Philippe

On 2021-11-11 01:48, Michael[tm] Smith via webkit-dev wrote:
> Can anyone recommend a combination of text-editor/IDE, plugins/tooling
> (e.g., language server), and settings/config that’ll enable me to have
> usable code-(auto)completion/suggestions (like Intellisense, etc.) when
> editing WebKit sources in a macOS environment?
> 
> Specifically, I mean the particular type of code completion you get when
> you type the name of some instance of an object in your editor, and then
> a dot, and the editor then shows you a popup with the names of all the
> available member functions and data members you can use with that object.
> 
> Over the last several days, I have been trying (and failing) in multiple
> text editors to get working code completion like that set up for editing
> WebKit sources.
> 
> A big reason it doesn’t work with the WebKit sources is that all the text
> editors and tooling don’t seem to be able to find the header files
> referenced in the various .cpp sources — beginning with #include "config.h",
> but others as well.
> 
> I’m a diehard vim user, so I started out trying the available vim plugins
> that integrate with clangd. And the big problem I ran into there was that
> clangd relies on having a compile_commands.json file to work from — which
> (as far as I understand) essentially can’t be generated from the WebKit
> sources when building the macOS port (I have gleaned that’s in part due
> to the fact it’s a Unified build, which confuses clangd).
> 
> So the next thing I tried was integrating with ccls. That seems to work to
> the point of ccls successfully generating an index of sources — but then
> when I open a file to edit, I immediately get an error about ccls not being
> able to resolve the #include “config.h” reference — and the multiple errors
> about macro references it can’t resolve.
> 
> ...And then, ultimately, no completion suggests when I put a dot after a
> particular object name I want to get the function and data-member
> suggestions for. (It seems to work for some objects, but not others.)
> 
> I like ccls though, and I think (hope) it may be that if I set up my .ccls
> file with the right options for helping it find the header files it needs,
> it may actually end up working. But my current .ccls isn’t doing that.
> 
> Anyway, the last thing I’ve been trying is Visual Studio Code. In that I
> tried with both the clangd extension and the ccls extension, but ended up
> having basically the same problems I have with the vim integrations.
> 
> So I switched back to trying the Microsoft-provided C/C++ Intellisense
> extension (cpptools), and found that seems to work better than the clangd
> or ccls extensions — at least so far as it seems to be able to at last
> partially resolve the header include references. But then it too seems to
> stumble on not being able to find some headers it needs.
> 
> For example, I think I’ve been able to make it figure out #include "config.h" 
> —
> but then the next problem I hit is stuff like this:
> 
>   cannot open source file "JavaScriptCore/JSExportMacros.h"
> (dependency of "config.h")
> 
> ...And then anyway, again, ultimately, no completion suggests when I put a dot
> after a particular object name I want to get the function and data-member
> suggestions for. (It seems to work for some objects, but not others.)
> 
> So I’m hoping others here might have something working successfully in
> their environments that gives them proper completion suggestions on member-
> function names and data-member names.
> 
>   –Mike
> 
> ___
> 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] Running the GTK port on macOS with Docker

[Philippe Normand via webkit-dev]

On Fri, 2021-10-15 at 10:04 +1100, Jean-Yves Avenard wrote:
> Hi.
> 
> Personally, I would love a way to quickly build for GTK on my Mac, as
> for now I had to rely on pushing to the EWS, wait for compilation
> errors and fix them as I went.
> 
> So something running in docker using my local tree would be ideal.
> 

Alright, thanks for answering Jean-Yves :) I'll clean-up the experiment
a bit, document it and ping you for testing when it's ready.

Philippe

> Jean-Yves
> 
> > On 15 Oct 2021, at 1:21 am, Philippe Normand via webkit-dev
> >  wrote:
> > 
> > Hi,
> > 
> > The WPE/GTK ports nowadays rely on a SDK that provides all the
> > tools
> > needed for development, it's used on the bots as well. Currently we
> > run
> > it with Flatpak, but technically, Docker can also be used.
> > 
> > I've actually checked that a GTK MiniBrowser build downloaded from
> > the
> > bots can run on macOS with Docker, that involves setting up
> > XQuartz,
> > it's not great, but for quick testing, I wonder if that could be
> > useful
> > for the Apple folks?
> > 
> > The GTK port could also be built on macOS using this docker setup,
> > the
> > SDK includes the GCC and clang versions used on the bots.
> > 
> > You can already do this with a VM, but then if you want to use the
> > SDK
> > it adds another lever of virtualization, which is not great. So
> > directly using the SDK through Docker seems more appealing, to me
> > at
> > least :)
> > 
> > WPE can't run, I haven't managed to start Weston with its X11
> > backend
> > in XQuartz... Ideally I'd prefer a native Wayland compositor for
> > macOS
> > but that doesn't seem to exist yet.
> > 
> > Anyway, please let me know if some folks are interested.
> > 
> > Philippe
> > ___
> > 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] Running the GTK port on macOS with Docker

[Philippe Normand via webkit-dev]

Hi,

The WPE/GTK ports nowadays rely on a SDK that provides all the tools
needed for development, it's used on the bots as well. Currently we run
it with Flatpak, but technically, Docker can also be used.

I've actually checked that a GTK MiniBrowser build downloaded from the
bots can run on macOS with Docker, that involves setting up XQuartz,
it's not great, but for quick testing, I wonder if that could be useful
for the Apple folks?

The GTK port could also be built on macOS using this docker setup, the
SDK includes the GCC and clang versions used on the bots.

You can already do this with a VM, but then if you want to use the SDK
it adds another lever of virtualization, which is not great. So
directly using the SDK through Docker seems more appealing, to me at
least :)

WPE can't run, I haven't managed to start Weston with its X11 backend
in XQuartz... Ideally I'd prefer a native Wayland compositor for macOS
but that doesn't seem to exist yet.

Anyway, please let me know if some folks are interested.

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

Re: [webkit-dev] WebKit Transition to Git

[Philippe Normand]

This is great!

On Fri, 2020-10-02 at 09:43 -0700, Jonathan Bedard wrote:
> Hello WebKit Contributors,
> 
> This year, Apple would like to push WebKit’s source code management
> off of Subversion and onto git. Our rationale for this is the rest of
> the industry has settled on git as their source code management
> solution.  We’re also interested in moving to a hosted Git solution
> (namely, GitHub) to make it easier for new contributors to interact
> with the project. I would like to outline our plan so far, and
> solicit feedback from our contributors about some of the pieces we’re
> still discussing.
> 
> Monotonic Commit Identifiers
> Of great interest to Apple’s engineers has been retaining some kind
> of ordered tag we can use to refer to commits to make defending CI
> and bisection easier. We’ve developed a scheme for this that assigns
> commits an ordered identifier per-branch, outlined in 
> https://trac.webkit.org/wiki/commit-identifiers, designed to be used
> alongside git hashes. These identifiers can be used in our current
> Subversion repository, and we would like to start using them before
> the project has transitions to git.
> 

Have you seen how this was handled in LLVM?
https://releases.llvm.org/9.0.0/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git

Would you also consider preventing merge commits in order to keep a
clean mainline branch?

Philippe

> Hosting the Repository
> We're most likely going to be hosting the repository in public
> GitHub. The rationale for choosing GitHub over alternatives (namely,
> GitLab) is that GitHub has a far more active community, and Apple
> would like WebKit to be more connected to the open source community.
> For this reason, we prefer to place the canonical WebKit repository
> on public GitHub so the project is more accessible to new
> contributors, although some concerns have been raised about GitHub’s
> terms and conditions, which contributors of WebKit would need to
> agree to in addition to the terms and conditions of the WebKit
> project. We are interested in what our current community of
> contributors thinks about this, and what preferences contributors may
> have.
> 
> Patches to Pull Requests
> In the coming months, more automation will start using the git
> version of the repository instead of the Subversion version. Even
> immediately after we switch, the patch review workflow will remain
> what it is now (EWS bots mostly already use a git clone as their
> checkout). We do, however, intend to switch from a system of patch
> review to a system of pull requests. This process will be incremental
> and the patch review system will remain alive as long as Bugzilla
> does.
> 
> GitHub Issues
> The last part of transitioning away from Subversion is to re-evaluate
> our bug tracker. Bugzilla has served us well, but seems to be an
> impediment to engaging with the open source community. We are
> interested in moving away from Bugzilla and to GitHub Issues,
> allowing new developers to work with a system they are likely already
> familiar with and to allow us closer integration with repositories
> managed by W3C. Although GitHub Issues has had performance problems
> in the past with projects that have many bugs, these performance
> problems have been resolved to the satisfaction of a few large
> projects hosted on GitHub that are of a comparable scale to WebKit.
> The biggest blocker we are aware of is managing security bugs, since
> the security advisory system used by GitHub is essentially the
> opposite of how WebKit security bugs work. Moving to GitHub Issues,
> if it happens, will be the last part of this transition, and we are
> interested in soliciting feedback from our contributors on what the
> WebKit project’s integration with GitHub Issues should look like.
> 
> Look forward to hearing from all of you,
> 
> Jonathan Bedard
> WebKit Operations
> ___
> 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] PSA: Flatpak WPE/GTK SDK upgrade to version 0.3

[Philippe Normand]

Hi,

This mail is mostly for WPE/GTK port developers. Feel free to skip if
you're not part of that group.

In r266455[0] the SDK build definitions were updated along with a major
upgrade to the FDO SDK version 20.08. Compared with 19.08, this new
version breaks ABI, that means applications built for 19.08 will not
work in 20.08 and need to be rebuilt. So if you are working with the
GTK and/or WPE ports and using the Flatpak SDK, you will need to remove
your local build directories after this patch lands:

https://bugs.webkit.org/show_bug.cgi?id=216073

Additionally, you will need to run `Tools/Scripts/update-webkitgtk-
libs` or `Tools/Scripts/update-webkitwpe-libs` so that version 0.3 is
locally installed on your workstation.

We plan to land this patch soon, during the early European morning, in
order to avoid major service disruption on the bots and EWS.

Philippe

[0] https://trac.webkit.org/r266455

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

Re: [webkit-dev] Generating compile_commands.json when building WebKit on MacOS

[Philippe Normand]

On Wed, 2020-07-22 at 08:24 -0500, Michael Catanzaro wrote:
> On Wed, Jul 22, 2020 at 11:15 am, shriva...@firemail.cc wrote:
> > DerivedSources/ForwardingHeaders/JavaScriptCore/JSContext.h:40:1: 
> > error: duplicate interface definition for class 'JSContext'
> > @interface JSContext : NSObject
> > ^
> > ../../Source/JavaScriptCore/API/JSContext.h:40:12: note: previous 
> > definition is here
> > @interface JSContext : NSObject
> >^
> > 
> > Your assistance would be much appreciated.
> 
> It might be time to simply remove support for building WebKitGTK on 
> macOS. I imagine it's been many years since anyone has successfully 
> built it.
> 

jmercouris on IRC reported yesterday that he got it to build on macOS.
IIUC he's working on the macports project.

Philippe

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

Re: [webkit-dev] PSA: Changes in the recommended GTK/WPE developer workflow

[Philippe Normand]

Hi,

A few updates about this topic. Read below!

On Tue, 2020-03-17 at 17:31 +, Philippe Normand wrote:
> Hi,
> 
> Until now the most recommended way to work on the GTK and WPE ports
> was
> to use a custom JHBuild[0] moduleset ([1][2]) for build/runtime
> dependencies. This setup was deployed almost 10 years ago [3] and
> while
> it is an opt-in approach, it is highly recommended, especially if you
> want to run layout tests locally.
> 
> If you ever executed Tools/Scripts/update-webkitgtk-libs or
> Tools/Scripts/update-webkitwpe-libs it means you currently have a
> DependenciesGTK and/or DependenciesWPE folder in WebKitBuild/ and
> that
> your workflow is JHBuild-based.
> 
> JHBuild has various shortcomings, even though it served us well all
> these years:
> 
> - if the moduleset is modified, the bots remove the whole
> Dependencies{GTK,WPE} folders and rebuild everything from scratch
> - no cross-compilation support
> - no clear separation between the host system and the JHBuild-based
> sysroot
> - poor system requirements management (See the install-dependencies
> scripts in Tools/{wpe,gtk})
> - time lost rebuilding the dependencies (can take up to an hour on my
> build machine)
> 
> So in order to improve our lives a bit, we decided to try a new
> workflow, this time based on Flatpak[4]. Instead of having every
> developer locally build the dependencies, the built sysroot will be
> packaged in a Flatpak SDK/Runtime and downloaded to the developer
> machine. Currently the SDK is built for X86_64 but additional
> architectures can be supported (ARMv7, Aarch64 at least).
> 
> The advantages of this new approach:
> 
> - cross-compilation can easily be achieved
> - clear separation between the host system and the SDK sysroot
> - the SDK runs in a sandbox
> - unified toolchain for WebKit build (currently both GCC 9.2.0 and
> clang 8.0.1)
> - no time lost rebuilding dependencies :)
> - consistent layout tests coverage across different hosts
> - separate build directories for each port (example:
> WebKitBuild/GTK/Release
>   mounted as /app/WebKit/WebKitBuild/Release in the SDK sandbox)
> 
> As a bonus, this setup allows for:
> 
> - integration with sccache, for faster WebKit builds
> - builtin IceCC support without additional manual steps (you still
> need
> a scheduler running on the host system though)
> 
> The only disadvantage of this new approach is that hacking on
> dependencies is currently not trivial to accomplish. We plan to
> enable
> this most likely via the Flapjack[5] tool.
> 

Flapjack was discarded, for now, because Buildstream provides a good
workflow already.

> Once the patch from bug#205658 [6] lands, this workflow will be
> available. How do I use it? Easy:
> 
> 1. Make sure your flatpak version is recent enough, 1.4.4 is the
> minimum version we support. Backports for Debian stable are available
> and for Ubuntu LTS, a PPA is available. See the Flathub instructions
> (though you don't need to manually add the flathub remote) [7].
> 
> 2. Run update-webkitgtk-libs or update-webkitwpe-libs as usual. This
> will download and install the SDK in WebKitBuild/UserFlatpak/
> 
> 3. Run build-webkit as usual
> 
> The SDK will be used when running the tests (API, layout, webkitpy,
> etc) and the MiniBrowser.
> 
> For the time being we keep the JHBuild workflow in the SVN, although
> if
> everything goes well, it will be removed in the coming months. Hence
> we
> encourage all GTK/WPE developers to try this new workflow!
> 
> If you still want to keep using JHBuild, make sure to set the
> WEBKIT_JHBUILD=1 environment variable in your shell. But keep in mind
> that we intend to remove support for JHBuild if Flatpak works as
> expected (so please try to test it, and report any issue with it).
> The
> GTK/WPE buildbots and EWS are currently running with JHBuild and will
> be switched one-by-one to Flatpak soon.
> 

The bots now use the SDK, thanks to Diego Pino, Lauro Mauro and Carlos
López. Many thanks to them :)

> The SDK sources are currently hosted on Github[8], but we might move
> them to WebKit's SVN.
> 

This is done now, as of:
https://trac.webkit.org/r261274

Philippe


> Philippe
> 
> [0] https://developer.gnome.org/jhbuild/stable/
> [1] https://trac.webkit.org/browser/trunk/Tools/gtk/jhbuild.modules
> [2] https://trac.webkit.org/browser/trunk/Tools/wpe/jhbuild.modules
> [3] https://bugs.webkit.org/show_bug.cgi?id=73425
> [4] https://flatpak.org/
> [5] https://github.com/endlessm/flapjack
> [6] https://bugs.webkit.org/show_bug.cgi?id=205658
> [7] https://flatpak.org/setup/
> [8] https://github.com/igalia/webkit-flatpak-sdk
> 
> ___
> 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] PSA: Changes in the recommended GTK/WPE developer workflow

[Philippe Normand]

On Tue, 2020-03-17 at 17:31 +, Philippe Normand wrote:

> The only disadvantage of this new approach is that hacking on
> dependencies is currently not trivial to accomplish. We plan to
> enable
> this most likely via the Flapjack[5] tool.
> 

I forgot to mention (quoting the ChangeLog):

As an additional commodity, the new environment supports the
GStreamer gst-build-based workflow. Just set the GST_BUILD_PATH
environment variable to your gst-build path. This feature was
contributed by Thibault Saunier.

> Once the patch from bug#205658 [6] lands, this workflow will be
> available. 

The patch landed in r258626.

Happy hacking!
Philippe

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

[webkit-dev] PSA: Changes in the recommended GTK/WPE developer workflow

[Philippe Normand]

Hi,

Until now the most recommended way to work on the GTK and WPE ports was
to use a custom JHBuild[0] moduleset ([1][2]) for build/runtime
dependencies. This setup was deployed almost 10 years ago [3] and while
it is an opt-in approach, it is highly recommended, especially if you
want to run layout tests locally.

If you ever executed Tools/Scripts/update-webkitgtk-libs or
Tools/Scripts/update-webkitwpe-libs it means you currently have a
DependenciesGTK and/or DependenciesWPE folder in WebKitBuild/ and that
your workflow is JHBuild-based.

JHBuild has various shortcomings, even though it served us well all
these years:

- if the moduleset is modified, the bots remove the whole
Dependencies{GTK,WPE} folders and rebuild everything from scratch
- no cross-compilation support
- no clear separation between the host system and the JHBuild-based
sysroot
- poor system requirements management (See the install-dependencies
scripts in Tools/{wpe,gtk})
- time lost rebuilding the dependencies (can take up to an hour on my
build machine)

So in order to improve our lives a bit, we decided to try a new
workflow, this time based on Flatpak[4]. Instead of having every
developer locally build the dependencies, the built sysroot will be
packaged in a Flatpak SDK/Runtime and downloaded to the developer
machine. Currently the SDK is built for X86_64 but additional
architectures can be supported (ARMv7, Aarch64 at least).

The advantages of this new approach:

- cross-compilation can easily be achieved
- clear separation between the host system and the SDK sysroot
- the SDK runs in a sandbox
- unified toolchain for WebKit build (currently both GCC 9.2.0 and
clang 8.0.1)
- no time lost rebuilding dependencies :)
- consistent layout tests coverage across different hosts
- separate build directories for each port (example:
WebKitBuild/GTK/Release
  mounted as /app/WebKit/WebKitBuild/Release in the SDK sandbox)

As a bonus, this setup allows for:

- integration with sccache, for faster WebKit builds
- builtin IceCC support without additional manual steps (you still need
a scheduler running on the host system though)

The only disadvantage of this new approach is that hacking on
dependencies is currently not trivial to accomplish. We plan to enable
this most likely via the Flapjack[5] tool.

Once the patch from bug#205658 [6] lands, this workflow will be
available. How do I use it? Easy:

1. Make sure your flatpak version is recent enough, 1.4.4 is the
minimum version we support. Backports for Debian stable are available
and for Ubuntu LTS, a PPA is available. See the Flathub instructions
(though you don't need to manually add the flathub remote) [7].

2. Run update-webkitgtk-libs or update-webkitwpe-libs as usual. This
will download and install the SDK in WebKitBuild/UserFlatpak/

3. Run build-webkit as usual

The SDK will be used when running the tests (API, layout, webkitpy,
etc) and the MiniBrowser.

For the time being we keep the JHBuild workflow in the SVN, although if
everything goes well, it will be removed in the coming months. Hence we
encourage all GTK/WPE developers to try this new workflow!

If you still want to keep using JHBuild, make sure to set the
WEBKIT_JHBUILD=1 environment variable in your shell. But keep in mind
that we intend to remove support for JHBuild if Flatpak works as
expected (so please try to test it, and report any issue with it). The
GTK/WPE buildbots and EWS are currently running with JHBuild and will
be switched one-by-one to Flatpak soon.

The SDK sources are currently hosted on Github[8], but we might move
them to WebKit's SVN.

Philippe

[0] https://developer.gnome.org/jhbuild/stable/
[1] https://trac.webkit.org/browser/trunk/Tools/gtk/jhbuild.modules
[2] https://trac.webkit.org/browser/trunk/Tools/wpe/jhbuild.modules
[3] https://bugs.webkit.org/show_bug.cgi?id=73425
[4] https://flatpak.org/
[5] https://github.com/endlessm/flapjack
[6] https://bugs.webkit.org/show_bug.cgi?id=205658
[7] https://flatpak.org/setup/
[8] https://github.com/igalia/webkit-flatpak-sdk

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

Re: [webkit-dev] Moving to Python 3

[Philippe Normand]

Hi folks,

Now that Catalina is released, can we move on to some of the proposed
changes discussed in this thread?

Philippe

On Fri, 2019-07-12 at 12:18 -0700, Jonathan Bedard wrote:
> Hello WebKit developers,
> 
> Now that the Catalina developer seeds are available, it is official
> that the new Mac developer tools come with Python 3. As a result, we
> need to continue the ongoing discussion about migrating our Python
> 2.7 scripts to Python 3.
> 
> I propose that, over the next 9 months, we do the following:
> 
> 1. Make any no-cost Python 3 compatibility changes, in particular
> - print foo -> print(foo)
> - import .foo -> import webkitpy.foo
> 2. Convert any scripts not used in automation to Python 3 ASAP
> (scripts like bisect-builds, block-spammers, compare-results)
> 3. Make most Python 3 compatibility changes which sacrifice
> efficiency, subject to a case-by-case audit. These would be things
> like:
> - dict.iteritems() -> dict.items()
> - dict.items() -> list(dict.items())
> 4. Install Python 3 on macOS Sierra and Mojave bots
> 5. Convert peripheral automation scripts to Python 3 1-by-1 (scripts
> like clean-webkit, merge-results-json, webkit-patch)
> 6. Convert testing scripts and webkitpy to Python 3 in a single
> change
> 
> The trouble I foresee us encountering with any scheme which attempts
> a conversion which retains both Python 2.7 and Python 3 compatibility
> is code like this:
> 
> for expectation_string, expectation_enum in
> test_expectations.TestExpectations.EXPECTATIONS.iteritems():
> ...
> 
> In this code, the EXPECTATIONS dictionary is thousands of elements
> long. In Python 2.7, iteritems() gives us an iterator instead of
> creating a new list, like items() would. In Python 3, iteritems()
> doesn’t exist, but items() does, and now gives us an iterator instead
> of creating a new list. The trouble here is that, in this case,
> creating a new list will be very expensive, expensive enough that we
> might manage to impact the testing run. There isn’t really an elegant
> way around this problem if we want to support both Python 2.7 and
> Python 3, other than defining different code paths for each language.
> 
> There are other small gotchas as well. For example, ‘%’ is no longer
> a protected character, which can actually change the behavior of
> regexes. That’s why I think it’s better to just try and directly
> convert things instead of attempting to be compatible with both
> Python 2.7 and Python 3.
> 
> Jonathan
> ___
> 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] Moving to Git

[Philippe Normand]

On Wed, 2019-02-20 at 09:40 -0800, Ryosuke Niwa wrote:
> 
> On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker <
> bug.tracking.acco...@protonmail.com> wrote:
> > I was curious about the status of the proposal for migrating from
> > SVN to Git (https://trac.webkit.org/wiki/Moving%20to%20Git).
> > 
> > The relevant page on the Trac wiki hasn't been updated for over 5
> > years and since then Git has become much more popular (the de facto
> > standard for new projects, more or less), while:
> > SVN support is diminishing (e.g. in Xcode).
> > Git support on Windows is much better than 5 years ago.
> > It's difficult to find free robust SVN clients / UIs, unlike the
> > plethora of options available for Git.
> > Most young and relatively new developers (with less than 10 years
> > of experience, like myself) are much more comfortable with Git and
> > maybe have not even used SVN before, so moving to Git could
> > encourage more users and contributors.
> > 
> > Is there any progress in this direction?
> > 
> 
> No progress has been made as far as I can tell. Every other year or
> so, this topic comes up on webkit-dev, and the outcome is always the
> same.
> 
> We need a monotonically increasing revision number to track down perf
> regressions, etc... yet nobody has put the time & effort to create a
> solution with Git. 

Quoting the wiki page linked above:

Some previously svn projects have worked around this. For example,
Haiku uses automatic linear tags on each push. 
http://cgit.haiku-os.org/haiku/log/

Philippe

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

Re: [webkit-dev] Freenode spam counter-measure

[Philippe Normand]

Also the WKR and webkitbot bots will need to be registered with NickServ, 
otherwise their notifications in the channel won’t be delivered :)

Philippe

> On 6 Aug 2018, at 16:18, Philippe Normand  wrote:
> 
> 
> 
>> On 6 Aug 2018, at 16:12, Darin Adler  wrote:
>> 
>>> On Aug 6, 2018, at 5:22 AM, Konstantin Tokarev  wrote:
>>> 
>>>>> On Aug 5, 2018, at 2:38 AM, Philippe Normand  wrote:
>>>>> 
>>>>> Can one of the #webkit admin please set the +r mode on? This would help 
>>>>> reducing spam. Only messages from registered nicks would come through.
>>>> 
>>>> I tried this by typing this:
>>>> 
>>>>   /msg ChanServ set #webkit restricted on
>>> 
>>> This command works differently from +r: it forbids join for people who are 
>>> not in access list, instead of simply forbidding unregistered users.
>> 
>> What’s the ChanServ function for setting +r?
>> 
> 
> I think it is:
> 
> /msg chanserv set #webkit mlock +r
> 
> Philippe
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <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] Freenode spam counter-measure

[Philippe Normand]

> On 6 Aug 2018, at 16:12, Darin Adler  wrote:
> 
>> On Aug 6, 2018, at 5:22 AM, Konstantin Tokarev  wrote:
>> 
>>>> On Aug 5, 2018, at 2:38 AM, Philippe Normand  wrote:
>>>> 
>>>> Can one of the #webkit admin please set the +r mode on? This would help 
>>>> reducing spam. Only messages from registered nicks would come through.
>>> 
>>> I tried this by typing this:
>>> 
>>>/msg ChanServ set #webkit restricted on
>> 
>> This command works differently from +r: it forbids join for people who are 
>> not in access list, instead of simply forbidding unregistered users.
> 
> What’s the ChanServ function for setting +r?
> 

I think it is:

/msg chanserv set #webkit mlock +r

Philippe

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

[webkit-dev] Freenode spam counter-measure

[Philippe Normand]

Hi,

Can one of the #webkit admin please set the +r mode on? This would help 
reducing spam. Only messages from registered nicks would come through.

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

Re: [webkit-dev] how to enable waylandsink on webkit2?

[Philippe Normand]

Hi,

Please use the webkitgtk list next time, this is a topic specific to that port…

It is not advised to use a sink different to the one WebKit already uses 
internally. It should work fine without any change, the internal appsink should 
negotiate caps for GL texture-based rendering.

Please file a bug, providing GStreamer version and a log file produced with the 
following command:

$ GST_DEBUG=3,webkit*:6 GST_DEBUG_FILE=gst.log yourfancybrowser 

And try WebKitGTK 2.20.x.

Philippe

> On 17 May 2018, at 12:09, tugouxp <13824125...@163.com> wrote:
> 
> hi folks:
>i meet a problem when test the midori browser with   tag,  
> the player window was lost with nothing, 
> 
> but, from the pipeline message it seems the decoder pipeline goto the  state 
> pause, wating for the play trigger, so i guess it maybe something wrong with 
> the display part, from the log ,i know the default display sinker is 
> "webkit-gl-video-sink"
> not the waylandsink, which is our platfom supported!  
> 
> so my webkit version is 2.18.6, how can i enable the waylandsink by default 
> on it?  thanks for your kindly support.
> 
> Message tag received from element webkit-gl-video-sinkhandleMessage line 920.
> Message tag received from element webkit-gl-video-sinkhandleMessage line 920.
> Message tag received from element webkit-gl-video-sinkhandleMessage line 920.
> Message state-changed received from element webkit-gl-video-sinkhandleMessage 
> line 920.
> Message state-changed received from element bin0handleMessage line 920.
> Message state-changed received from element sinkhandleMessage line 920.
> Message state-changed received from element vbinhandleMessage line 920.
> Message state-changed received from element playsinkhandleMessage line 920.
> Message state-changed received from element playState: PAUSED, pending: 
> VOID_PENDINGNetwork State Changed from 2 to 3Ready State Changed from 0 to 
> 4Duration: 0:00:12.61200Position 0:00:00.0Position 0.
> Message async-done received from element playState: PAUSED, pending: 
> VOID_PENDINGdebug  : omx_vdec : *** call 
> SetVideoFbmBufAddress: pVideoPicture(0x2f662d8)
> 
> 
> 
> 
>  
> 
> ___
> 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] Status of GTK EWS bot?

[Philippe Normand]

Hi Darin,

The GTK EWS is back online. It wasn't properly rebooted after some
systems maintenance tasks at our office yesterday. Sorry about this :)

Philippe

On Mon, 2016-10-24 at 22:56 -0700, Darin Adler wrote:
> Hi folks.
> 
> As I am uploading patches to  =163876> for EWS processing I noticed that all the other platforms
> said “#1”, but gtk-wk2 said #85.
> 
> Is this just the bot falling a bit behind because of load, or is
> there a more serious problem? This is important to me because without
> the bot it is highly likely my patch will break the build for GTK; I
> normally update the GTK bindings code after the build failures on EWS
> expose which functions need updating.
> 
> — Darin
> ___
> 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] Are there any plans to upgrade SVN server on svn.webkit.org?

[Philippe Normand]

The commit-queue seems to be broken as well, one example:
https://bugs.webkit.org/show_bug.cgi?id=148524
:04 04 105f7e2febfadc8d1f550aa805ccd215e8f27c27
f3f1d4fa1265a983a518943e7e3a0f794477e6bd M  Source
Current branch master is up to date.
ERROR: Not all changes have been committed into SVN, however the
committed
ones (if any) seem to be successfully integrated into the working tree.

Please see the above messages for details.Seems to be a consequence of the git 
mirror sync bug.
Philippe
On Mon, 2016-06-20 at 13:29 +0900, Yusuke SUZUKI wrote:
> Great work, thanks.
> 
> I've just noticed that the ToT git revision in
> git://git.webkit.org/WebKit.git is r202198 while ToT SVN revision is
> r202223.
> 
> On Mon, Jun 20, 2016 at 3:30 AM, Lucas Forschler 
> m> wrote:
> > svn.webkit.org is back online.
> > Please let me know if you see any problems.
> > 
> > I will be doing minor additional maintenance later this week. I do
> > not expect the downtime to be nearly as significant as this
> > upgrade. I’ll send email with advance notice of additional
> > downtime.
> > Lucas
> > 
> > 
> > > On Jun 18, 2016, at 10:51 PM, Lucas Forschler 
> > > om> wrote:
> > > 
> > > Update: The svn data migration to the new format is currently
> > > about 1/3 of the way completed. I’ll post another progress update
> > > Sunday morning (Pacific time zone).
> > > Thanks,
> > > Lucas
> > > 
> > > 
> > > > On Jun 18, 2016, at 5:14 PM, Lucas Forschler 
> > > > com> wrote:
> > > > 
> > > > I’m starting this now. svn.webkit and build.webkit will be
> > > > going down shortly.
> > > > I’ll send an all-clear email when things are back online.
> > > > 
> > > > Lucas
> > > > 
> > > > > On Jun 18, 2016, at 9:54 AM, Lucas Forschler 
> > > > > e.com> wrote:
> > > > > 
> > > > > Hello Folks,
> > > > > 
> > > > > I plan on updating the svn repository from version 1.6.11 to
> > > > > 1.9.4 tonight. I will likely start this process sometime this
> > > > > late afternoon. svn.webkit.org will be down during this time.
> > > > > I will also be taking build.webkit.org offline, so our bots
> > > > > do not fail due to a missing svn server. 
> > > > > 
> > > > > I will also be taking this time to upgrade the backend
> > > > > datastore on svn.webkit.org. This process requires a full svn
> > > > > dump/load cycle, and takes a significant amount of time. I
> > > > > expect the the server to return online Sunday by end of day.
> > > > > 
> > > > > Please let me know if you have any questions.
> > > > > I’ll send another email before I take the servers offline.
> > > > > Lucas
> > > > > 
> > > > > 
> > > > > > On Apr 27, 2016, at 5:13 AM, Konstantin Tokarev 
> > > > > > ndex.ru> wrote:
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > According to [1], currently svn.webkit.org runs severely
> > > > > > outdated Subversion 1.6.11. Since then, there were 3
> > > > > > significant releases of Subversion, which brought lots of
> > > > > > performance improvements, most importantly brand new HTTP
> > > > > > protocol [3] and storage format improvements [4]. Also,
> > > > > > since 1.7 Apache 2.4 with MPM event is supported, which may
> > > > > > increase server throughput.
> > > > > > 
> > > > > > 
> > > > > > BTW, to improve performance of up to date Subversion client
> > > > > > (>= 1.8), it is needed to adjust Apache configuration[5]:
> > > > > > increase MaxKeepAliveRequests from default 100 to at least
> > > > > > 1000. This needs to be done regardless of Subversion server
> > > > > > upgrade.
> > > > > > 
> > > > > > 
> > > > > > [1] http://svn.webkit.org/repository/webkit/
> > > > > > [2] https://subversion.apache.org/docs/release-notes/1.7.ht
> > > > > > ml
> > > > > > https://subversion.apache.org/docs/release-notes/1.8.ht
> > > > > > ml
> > > > > > https://subversion.apache.org/docs/release-notes/1.9.ht
> > > > > > ml
> > > > > > [3] https://subversion.apache.org/docs/release-notes/1.7.ht
> > > > > > ml#httpv2
> > > > > > [4] https://subversion.apache.org/docs/release-notes/1.8.ht
> > > > > > ml#fsfs-enhancements
> > > > > >    https://subversion.apache.org/docs/release-notes/1.9.htm
> > > > > > l#fsfs-improvements
> > > > > > [5] https://subversion.apache.org/docs/release-notes/1.8.ht
> > > > > > ml#neon-deleted
> > > > > >    http://svn.haxx.se/dev/archive-2011-01/0320.shtml
> > > > > > 
> > > > > > ___
> > > > > > 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] Commit queue issues

[Philippe Normand]

Hi,

It seems the commit queue cannot land patches?

https://bugs.webkit.org/show_bug.cgi?id=148702

Philippe


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] what command used to install compiled webkitgtk?

[Philippe Normand]

> On 26 Aug 2015, at 19:58, Konovalov, Vadim  wrote:
> 
> after
> 
>   build-webkit --gtk --prefix=/foo/bar
> 
> then I want to install so installation goes to the said prefix, how should I 
> do that?
> (I've searched but haven't found the answer)

This mailing list isn’t for WebKitGTK users help, please use the webkit-gtk 
list next time.

build-webkit installs everything to WebKitBuild/. This tool is for developers, 
not end-users. If you need to build and install WebKitGTK in a custom directory 
you should directly use CMake.

First hit on Google :)
http://www.linuxfromscratch.org/blfs/view/svn/x/webkitgtk.html 


Philippe


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Svn server is very slow to get full code.

[Philippe Normand]

Same for the git mirror. Very slow from Spain, at least.

Philippe

On Tue, 2015-08-25 at 12:33 +0900, Gyuyoung Kim wrote:
> Some my PCs also have same problem when using svn. I don't know why 
> it is too slow suddenly.
> 
> Gyuyoung. 
> 
> On Tue, Aug 25, 2015 at 12:27 PM, 조진철  
> wrote:
> > Hi webkit-dev.
> > 
> > I am getting webkit full source through svn.
> > But the svn server is so slow that I cannot get it.
> > It looks like something wrong. 
> > 
> > WebKit-Git works as well.
> > 
> > Could anybody check it?
> > 
> > Thanks.
> > ___
> > 
> > Jincheol Jo
> > Naver Labs / Software Engineer.
> > 
> > 
> > 
> > ___
> > 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] migrating from 2.4.6 to 2.8.1

[Philippe Normand]

Hi Jerry,

Please use webkit-...@lists.webkit.org for WebKitGTK topics.

On Mon, 2015-05-04 at 10:43 -0400, Jerry Geis wrote:
> I am migrating from 2.4.6 to 2.8.1...
> 
> 
> under 2.4.6 there was a ./configure script - that appears to be gone.
> (Not sure why, thought that was a standard thing).
> 

We moved to CMake for the build.

> 
> So then I searched for building webkit and I found 
> Tools/Scripts/build-webkit
> 
> 
> So I looked in that directory in 2.8.1 and that file is not present.
> 

build-webkit should only be used when building a development version of
WebKitGTK. For releases please use CMake:

cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=Release .

Philippe

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

Re: [webkit-dev] gtk failure

[Philippe Normand]

Hi Said,

Can you please resubmit your patch? The EWS build directory was
cleaned-up.

Philippe

On Fri, 2014-10-31 at 09:55 -0700, Said Abou-Hallawa wrote:
> I submitted a patch for the bug https://bugs.webkit.org/show_bug.cgi?id=137132
> The build failed for gtk-wk2 but passed for mac and mac-wk2.  Here is the 
> failure.
> 
> Last 500 characters of output:
> e/CMakeFiles/WebCore.dir/rendering/style/RenderStyle.cpp.o -c 
> ../../Source/WebCore/rendering/style/RenderStyle.cpp
> ../../Source/WebCore/rendering/style/RenderStyle.cpp: In member function 
> 'WebCore::Color WebCore::RenderStyle::colorIncludingFallback(int, bool) 
> const':
> ../../Source/WebCore/rendering/style/RenderStyle.cpp:1525:10: error: 
> 'CSSPropertyWebkitColumnRuleColor' was not declared in this scope
>  case CSSPropertyWebkitColumnRuleColor:
> 
> 
> In the patch I have the following change 
> 
> 
> Source/WebCore/rendering/style/RenderStyle.cpp
> @@Color RenderStyle::colorIncludingFallbac
> 15221522 case CSSPropertyOutlineColor:
> 15231523 result = visitedLink ? visitedLinkOutlineColor() :
> outlineColor();
> 15241524 break;
> 
> 1525  case CSSPropertyWebkitColumnRuleColor:
>  1525 case CSSPropertyColumnRuleColor:
> 
> 15261526 result = visitedLink ? visitedLinkColumnRuleColor() :
> columnRuleColor();
> 15271527 break;
> 15281528 case CSSPropertyWebkitTextDecorationColor:
> 
> 
> 
> 
> I am un-prefixing the column rule color property.  So I replaced
> CSSPropertyWebkitColumnRuleColor with CSSPropertyColumnRuleColor.  But
> the failure is saying the prefixed property is not defined.  
> 
> 
> How can for gtk-wk2 only, the patch is not applied in RenderStyle.cpp
> but is applied with other files and is applied also for all files for
> the mac platform?
> 
> 
> Thanks,
> Said
> ___
> 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] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

[Philippe Normand]

Hi!

I'm using the XML-RPC API (via git-bz) and when attaching a patch to a
bug I get the following error:

There was an error sending mail from 'bugzilla-daemon@webkit.org'
to 'zandobersek@gmail.com': 
Couldn't connect to bz.apple.com 

Before the Bugzilla upgrade the smtp server was mail.webkit.org. Any
chance to restore it?

I would have opened a new bug in bugzilla but this error would prevent
it :)

Philippe

On Thu, 2014-10-16 at 01:48 -0700, David Kilzer wrote:
> Hi,
> 
> 
> We’re planning on upgrading Bugzilla (bugs.webkit.org) from 3.2.3 to
> 4.2.11 on Thursday, October 16 from 8-10 AM PDT.
> 
> 
> Sorry for the short notice.  I sent this message from the wrong
> address, and didn't see he bounce message until now.
> 
> 
> Please let me know if you have questions or concerns.  Thanks!
> 
> 
> Dave
> 
> 
> ___
> 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] Trying to turn WebRTC's code on - MEDIA_STREAM flags

[Philippe Normand]

On Wed, 2014-07-30 at 17:51 +0800, Jacques-Olivier wrote:
> Hi everyone, me again,
> 
> 
> I kept working on getting media_stream to work. I think my
> understanding of what is happening improved, but I’m still stuck at
> the same point:
> 
> 
> I read some more code and did some research about the Supplement and
> Supplementable classes.
> I mainly found this page which explains that Supplements are used to
> extract code from “massive” classes and make then more manageable and
> maintainable.
> Please correct me if I am wrong.
> 
> 
> Anyway, it doesn’t change that my program has no Supplement for the
> key “UserMediaController”.
> It looks like most of the supplements are being provided in two
> places:
>   * WebKit::WebView::_commonInitializationWithFrameName
>   * WebKit2::WebPage ’s constructor
> is there any other place where it should be done?
> 
> 
> WebView actually contains a call to WebCore::provideUserMediaTo which
> creates a supplement, but my debugging show that
> _commonInitializationWithFrameName is never called.
> WebPage’s constructor does not generate a UserMediaController
> supplement.
> 
> 
> My understanding of the WebView is that it is the rectangle in which
> the webpages are rendered. Is this assumption correct?
> I don’t understand why _commonInitializationWithFrameName is never
> called when browsing. From the name of the function, I would expect it
> to be called right after the memory allocation.
> 
> 
> This leaves me with 2 options:
> 1) Find a way to trigger _commonInitializationWithFrameName.
> I have no idea of how to do that at the moment
> 
> 
> 2) Duplicate the call to WebCore::provideUserMediaTo in
> WebKit2::WebPage.
> I understand this is what is being done for the geolocation
> supplement.
> I started to implement this solution, but it requires to translate
> Objective-C++ code into C++, and I am afraid that the file inclusion
> might never end.
> 

You might be interested to check this bug:
https://bugs.webkit.org/show_bug.cgi?id=123158

Philippe


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

Re: [webkit-dev] WinCairo video

[Philippe Normand]

On Thu, 2014-04-24 at 11:21 -0600, Alex Christensen wrote:
> I know there are several companies who don't even want to mess with
> the licenses of GStreamer or FFmpeg.  GStreamer's license isn't a
> problem, but I'm not sure how legally safe the plugins are. 

That's right. If you need support for those problematic codecs there are
some companies that can provide them.
 
>  They certainly don't have an indemnification clause in their
> licenses.  The dlls are still large compared to WebKit, and I've had
> trouble compiling them from source and debugging them on Windows.  The
> distributed versions from freedesktop.org also use a version of
> libsoup that is too old to use as the network backend for WebKit.  I'd
> also like to remove the requirement of installing GStreamer to build
> and run the unmodified WinCairo port to make it easier for people who
> don't know much about WebKit to build and run it.
> 

Those issues can likely be fixed. A lot of effort was invested in easing
the build of GStreamer for windows and Mac OSX. There are still some
bugs to iron out though.

> I'm not saying that GStreamer is out of the question in the future,
> but I think there are more reasons to switch than to stay right now.
> 

That's alright I understand your concerns.

Philippe

> 
> Alex Christensen
> 
> 
> On Thu, Apr 24, 2014 at 12:19 AM, Philippe Normand 
> wrote:
> On Wed, 2014-04-23 at 18:29 -0600, Alex Christensen wrote:
> > I'm working on a Media Foundation implementation of
> MediaPlayerPrivate
> > to replace the GStreamer-based one we're currently using.
>  Media
> > Foundation avoids the licensing issues of GStreamer
> 
> 
> Which licensing issues? You'd be surprised to know the actual
> number and
> variety of products that use GStreamer nowadays.
> 
> >  and the ~100MB of GStreamer dlls which need to be installed
> in a
> > certain directory.  MediaFoundation is included since
> Windows Vista.
> >
> 
> 
> Those dlls can certainly be reduced. I'm no Windows expert but
> there are
> ways to reduce the size of the gst shared libs in Linux
> (disabling debug
> is one).
> 
> >
> > I'm pretty sure I'm the only one working on or using
> WinCairo video,
> > but I hope to make the switch later this week unless someone
> wants to
> > maintain GStreamer on Windows.
> >
> 
> 
> Philippe
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> 
> 
> 
> -- 
> 
> 
>  
> 
> Alex Christensen
> 
> FlexSim Software Products, Inc.
> 
> 1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097
> 
> Voice: 801-224-6914 | Fax: 801-224-6984
> 
> Email: al...@flexsim.com
> 
> URL: www.flexsim.com
> 
>  
> 
> 
>  
> This message may contain confidential information, and is intended
> 
> only for the use of the individual(s) to whom it is addressed. 
> 
> 
> 


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

Re: [webkit-dev] WinCairo video

[Philippe Normand]

On Wed, 2014-04-23 at 18:29 -0600, Alex Christensen wrote:
> I'm working on a Media Foundation implementation of MediaPlayerPrivate
> to replace the GStreamer-based one we're currently using.  Media
> Foundation avoids the licensing issues of GStreamer

Which licensing issues? You'd be surprised to know the actual number and
variety of products that use GStreamer nowadays.

>  and the ~100MB of GStreamer dlls which need to be installed in a
> certain directory.  MediaFoundation is included since Windows Vista.
> 

Those dlls can certainly be reduced. I'm no Windows expert but there are
ways to reduce the size of the gst shared libs in Linux (disabling debug
is one).

> 
> I'm pretty sure I'm the only one working on or using WinCairo video,
> but I hope to make the switch later this week unless someone wants to
> maintain GStreamer on Windows.
> 

Philippe


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

Re: [webkit-dev] Remove ENABLE_NETWORK_INFO ?

[Philippe Normand]

I mean, https://bugs.webkit.org/show_bug.cgi?id=131841 :)

Philippe

On Fri, 2014-04-18 at 18:43 +0900, Gyuyoung Kim wrote:
> Hi Philippe,
> 
> 
> Sad to remove the feature. However, Network Information API spec. has
> still many issues to support bandwidth and with providing useful
> information. So, I should agree to remove it. However, if the
> specification is resurrected in future, I would like to support it
> again.
> 
> 
> Gyuyoung.
> 
> 
> On Fri, Apr 18, 2014 at 5:43 PM, Philippe Normand 
> wrote:
> Hi,
> 
> I think that feature should be removed from WebKit. The
> spec[1] clearly
> states:
> 
> "Work on this document has been discontinued and it should not
> be
> referenced or used as a basis for implementation."
> 
> Anyone against removing the networkinfo Module? It seems this
> feature
> was initially implemented for the EFL port.
> 
> Philippe
> 
> [1]
> https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html
> 
> ___
> 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] Remove ENABLE_NETWORK_INFO ?

[Philippe Normand]

See https://bugs.webkit.org/show_bug.cgi?id=131562

Philippe

On Fri, 2014-04-18 at 18:43 +0900, Gyuyoung Kim wrote:
> Hi Philippe,
> 
> 
> Sad to remove the feature. However, Network Information API spec. has
> still many issues to support bandwidth and with providing useful
> information. So, I should agree to remove it. However, if the
> specification is resurrected in future, I would like to support it
> again.
> 
> 
> Gyuyoung.
> 
> 
> On Fri, Apr 18, 2014 at 5:43 PM, Philippe Normand 
> wrote:
> Hi,
> 
> I think that feature should be removed from WebKit. The
> spec[1] clearly
> states:
> 
> "Work on this document has been discontinued and it should not
> be
> referenced or used as a basis for implementation."
> 
> Anyone against removing the networkinfo Module? It seems this
> feature
> was initially implemented for the EFL port.
> 
> Philippe
> 
> [1]
> https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html
> 
> ___
> 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] Remove ENABLE_NETWORK_INFO ?

[Philippe Normand]

Hi,

I think that feature should be removed from WebKit. The spec[1] clearly
states:

"Work on this document has been discontinued and it should not be
referenced or used as a basis for implementation."

Anyone against removing the networkinfo Module? It seems this feature
was initially implemented for the EFL port.

Philippe

[1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

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

Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

[Philippe Normand]

On Mon, 2014-03-10 at 10:35 -0700, Lucas Forschler wrote:
> Hello Webkit developers,
> 
> Apple will be upgrading our network infrastructure starting Tuesday morning 
> at 8am.
> The webkit.org services will be affected for approximately 4 hours.
> 
> This includes all *.webkit.org domains.  We expect them to be back online 
> before 12.
> 

BTW I've been wondering if a Bugzilla upgrade is planned?

We currently use 3.2.3 but the latest release seems to be 4.2.

If at least we could have a nice CSS like in bugzilla.mozilla.org it'd
be great :)

Philippe

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

[webkit-dev] Sergio Villar Senin is now a WebKit reviewer!

[Philippe Normand]

Hi,

I'm happy to announce that Sergio (svillar) is now a WebKit reviewer! 

Sergio's areas of expertize span from WebCore (CSS Grid Layout, Parser,
editing) to WebKit2 with a special dedication to the GTK port. Sergio
also spends a lot of efforts on the libsoup networking backend.

Thanks Sergio for all the work you have done so far and congratulations!

Philippe

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

Re: [webkit-dev] MAC :: building gstreamer by WebKit but without CAIRO

[Philippe Normand]

I think https://bugs.webkit.org/show_bug.cgi?id=124861 is about fixing
this issue.

Philippe

On Wed, 2013-11-27 at 22:47 +0100, Pascal Brianceau wrote:
> Files shared by Hugo raised the same issue on my side. Did anyone make
> a step forward ? Any tip Philippe ?
> 
> 
> /* Pascal */
> 
> 
> On Mon, Nov 25, 2013 at 9:52 AM, Hugo Machefer
>  wrote:
> Indeed: I didn't solve this yet; I can only say that the
> following line is "responsible for" these unresolved symbols:
> 
> 
> GOwnPtr error;
> 
> 
>   -- hmachefe
> 
> 
> On Sun, Nov 24, 2013 at 10:04 PM, gstreamer MACOSX
>  wrote:
> I managed to restore < ImageGStreamerCG.cpp> however
> LINK fails :
> 
> 
>   "__ZN3WTF13freeOwnedGPtrI7_GErrorEEvPT_", referenced
> from:
> 
> 
> __ZN7WebCore27MediaPlayerPrivateGStreamer13handleMessageEP11_GstMessage in 
> MediaPlayerPrivateGStreamer.o
>   __ZN7WebCore19initializeGStreamerEv in
> GStreamerUtilities.o
> 
> 
>   -- gstreamermacosx
> 
> 
> PS: special thanks to hmachefe for precious
> restoration tips and to Philippe of course
> 
> 
> 
> On Sat, Nov 23, 2013 at 9:59 AM, Philippe Normand
>  wrote:
> The ImageGStreamerCG implementation was
> removed in
> http://trac.webkit.org/changeset/118610
> 
> Philippe
> 
> On Sat, 2013-11-23 at 00:44 +0100, Urbain EGIS
> wrote:
> > I compiled most of
> Source/WebCore/platform/graphics/gstreamer
> apart
> > from  which has a
> strong dependency on CAIRO.
> >
> >
> > It seems to be "overkill" to build WebKit by
> enabling CAIRO... Because
> > (only ;-) "one" file 
> requires a specific CAIRO
> > surface.
> >
> >
> > So What would be the best strategy in case
> of MAC ?
> > 1° activate CAIRO by WebKit and generate it
> again (+gstreamer) ... ?
> > Really ?
> > 2° get rid of CAIRO and find an alternative
> by CF/CG rather in terms
> > of surface
> >
> >
> > -- Egis
> >
> 
> >
> ___
> > 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 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 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] MAC :: building gstreamer by WebKit but without CAIRO

[Philippe Normand]

The ImageGStreamerCG implementation was removed in
http://trac.webkit.org/changeset/118610

Philippe

On Sat, 2013-11-23 at 00:44 +0100, Urbain EGIS wrote:
> I compiled most of Source/WebCore/platform/graphics/gstreamer apart
> from  which has a strong dependency on CAIRO.
> 
> 
> It seems to be "overkill" to build WebKit by enabling CAIRO... Because
> (only ;-) "one" file  requires a specific CAIRO
> surface.
> 
> 
> So What would be the best strategy in case of MAC ? 
> 1° activate CAIRO by WebKit and generate it again (+gstreamer) ... ?
> Really ?
> 2° get rid of CAIRO and find an alternative by CF/CG rather in terms
> of surface
> 
> 
> -- Egis
> 
> ___
> 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] [WinCairo] : ENABLE_VIDEO => how to activate HTML5 video tag ?

[Philippe Normand]

On Mon, 2013-10-14 at 22:09 +0530, Mital Vora wrote:
> Hi,
> 
> 
> I have few questions regarding move to Gstreamer. 
> 
> 
> * are we gonna replace the existing openssl and curl with libsoup ?
> 

1. GStreamer doesn't depend on those libraries.
2. For HTTP(S) media access we have a dedicated source element in WebKit
that uses the WebCore ResourceLoader to fetch data.

> 
> * are we considering any other possibilities besides gstreamer like
> ffmpeg (http://www.ffmpeg.org/) or any other. 
> 

Feel free to provide a MediaPlayerPrivateFFMpeg if you want. But be
ready to maintain it too :)

> 
> By moving to gstreamer would increase dependencies size a lot as the
> all GTK base libraries would be included by default and this would be
> concern to atleast few of us who does not want to increase the webkit
> base dependencies library by huge amount. 
> 
> 
> I may be missing something here..  can anybody clarify the advantages
> of moving to gtk based gstreamer over the other side like the binary
> size increase. 
> 
> 

> 
> 
> 
> Regards,
> 
> Mital Vora.
> 
> 
> On Mon, Oct 14, 2013 at 9:54 PM, Brendan Long 
> wrote:
> On 10/14/2013 04:14 AM, gstreamer MACOSX wrote:
> 
> > Exactly, Philippe: I searched everywhere by D:\Users
> > \gstreamermacosx\webkit\Source but without any success.  
> > I applyed this command like my counterparts ... :
> > > git clone http://git.igalia.com/webkit.git 
> > Is it correct ? In fact, there is not even any Source/WTF
> > sub-folder.
> I think he meant you should use the normal repo:
> git clone git://git.webkit.org/WebKit.git
> (Or use SVN if you're into that?)
> 
> Rebasing a patch from a 3-year-old checkout would be extremely
> difficult, so it's easier to figure out what the patch does,
> and re-apply it manually on a new checkout.
> 
> 
> ___
> 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] [WinCairo] : ENABLE_VIDEO => how to activate HTML5 video tag ?

[Philippe Normand]

On Mon, 2013-10-14 at 12:14 +0200, gstreamer MACOSX wrote:
> Exactly, Philippe: I searched everywhere by D:\Users\gstreamermacosx
> \webkit\Source but without any success. 
> I applyed this command like my counterparts ... :
> > git clone http://git.igalia.com/webkit.git
> Is it correct ? In fact, there is not even any Source/WTF sub-folder.
> 

Like I said earlier, that repository is 3 years old, a lot of changes
were made, including the move of wtf from JavascriptCore/ to Source/

Seriously, get in touch with Alexander. IIUC he got the patches updated
for trunk already...

Philippe

> 
> -- gstreamerForEver
> 
> 
> On Mon, Oct 14, 2013 at 11:59 AM, Philippe Normand 
> wrote:
> On Mon, 2013-10-14 at 11:51 +0200, gstreamer MACOSX wrote:
> > Unless we missed something, sources tied to GSTREAMER (like
> wtf
> > \gobject\GlibUtilities.cpp) appear, sort of, unobtainable.
> Anyone
> > under position to shed lights on these missing .CPP files
> required by
> > Webkit  ?
> 
> 
> Have you actually searched in source tree?
> See Source/WTF/wtf/gobject/GlibUtilities.cpp ...
> 
> Philippe
> 
> >
> >
> > -- gstreamerForEver
> >
> >
> > > On Sun, 2013-10-13 at 14:22 +0200, Urbain EGIS wrote:
> > > Probably a painful and hackful job in sight, as we have
> been told.
> > And
> > > as a prototype, to start with. Your forewords are
> appreciate of
> > > course.
> > > Would you mind providing some guidance to where/how to
> source files
> > > may be located. Example : \wtf\gobject\GlibUtilities.cpp
>     > > Thanks in advance, Philippe.
> > >
> > > Regards,
> > >
> > >
> > > EGIS
> > >
> > >
> > > On Sat, Oct 12, 2013 at 3:59 PM, Philippe Normand
> 
> > > wrote:
> > > On Sat, 2013-10-12 at 14:53 +0200, Urbain EGIS
> wrote:
> > > > Of course, I'm part of the challenge, Hugo. I
> started to
> > > analyse .diff
> > > > files gently provided by Alex. Let's focus on
> one
> > example :
> > > >
> > > >
> > > > --- Source/WTF/WTF.vcxproj/WTF.vcxproj
> (revision
> > > 156730)
> > > > +++ Source/WTF/WTF.vcxproj/WTF.vcxproj
> (working
> > > copy)
> > > > @@ -73,6 +73,9 @@
> > > > ...
> > > > +
> > > > ...
> > > >
> > > >
> > > > Then my question is :
> > > > where can I find this CPP file wtf
> \gobject
> > > \GlibUtilities.cpp ?
> > > > I have done: git clone
> > > http://git.igalia.com/webkit.git
> > > > but is it the right way to get
> GSTREAMER-centric
> > > source files
> > > > for/by WebKit ? It seems it's not
> enough/accurate
> > > >
> > >
> > >
> > > Please don't forget that branch is more than 3
> years old. A
> > > lot of code
> > > changed in WebKit since then. And most of the
> commits in
> > that
> > > branch
> > > were not really ready to be upstreamed as it was
> mostly a
> > > proof-of-concept.
> > >
> > > Philippe
> > >
> > > >
> > > > On Fri, Oct 11, 2013 at 11:05 PM, Hugo Machefer
> > > >  wrote:
> > > > Utterly, I'd be glad to take a serious
> and deep
> > step
> > > forwards
> > > > into this direction. Therefore, on both
> Bren

Re: [webkit-dev] [WinCairo] : ENABLE_VIDEO => how to activate HTML5 video tag ?

[Philippe Normand]

On Mon, 2013-10-14 at 11:51 +0200, gstreamer MACOSX wrote:
> Unless we missed something, sources tied to GSTREAMER (like wtf
> \gobject\GlibUtilities.cpp) appear, sort of, unobtainable. Anyone
> under position to shed lights on these missing .CPP files required by
> Webkit  ?

Have you actually searched in source tree?
See Source/WTF/wtf/gobject/GlibUtilities.cpp ...

Philippe

> 
> 
> -- gstreamerForEver
> 
> 
> > On Sun, 2013-10-13 at 14:22 +0200, Urbain EGIS wrote:
> > Probably a painful and hackful job in sight, as we have been told.
> And
> > as a prototype, to start with. Your forewords are appreciate of
> > course.
> > Would you mind providing some guidance to where/how to source files
> > may be located. Example : \wtf\gobject\GlibUtilities.cpp
> > Thanks in advance, Philippe.
> >
> > Regards,
> >
> >
> > EGIS
> >
> >
> > On Sat, Oct 12, 2013 at 3:59 PM, Philippe Normand 
> > wrote:
> > On Sat, 2013-10-12 at 14:53 +0200, Urbain EGIS wrote:
> > > Of course, I'm part of the challenge, Hugo. I started to
> > analyse .diff
> > > files gently provided by Alex. Let's focus on one
> example :
> > >
> > >
> > > --- Source/WTF/WTF.vcxproj/WTF.vcxproj (revision
> > 156730)
> > > +++ Source/WTF/WTF.vcxproj/WTF.vcxproj (working
> > copy)
> > > @@ -73,6 +73,9 @@
> > > ...
> > > +
> > > ...
> > >
> > >
> > > Then my question is :
> > > where can I find this CPP file wtf\gobject
> > \GlibUtilities.cpp ?
> > > I have done: git clone
> > http://git.igalia.com/webkit.git
> > > but is it the right way to get GSTREAMER-centric
> > source files
> > > for/by WebKit ? It seems it's not enough/accurate
> > >
> >
> >
> > Please don't forget that branch is more than 3 years old. A
> > lot of code
> > changed in WebKit since then. And most of the commits in
> that
> > branch
> > were not really ready to be upstreamed as it was mostly a
> > proof-of-concept.
> >
> > Philippe
> >
> > >
> > > On Fri, Oct 11, 2013 at 11:05 PM, Hugo Machefer
> > >  wrote:
> > > Utterly, I'd be glad to take a serious and deep
> step
> > forwards
> > > into this direction. Therefore, on both Brendan &
> > Alex's
> > > instructions I'm gona opt for GSTREAMER as a
> default
> > player,
> > > oviously. Urbain, are you with me/us ? The more,
> the
> > merrier,
> > > you know ;-) First, as mentionned earlier, check
> > > with ENABLE(VIDEO) => shall be disclosing as a
> > > consequence many CPP files impacted.
> > >
> > >
> > > On my side, I am gona set WTF_USE_GSTREAMER, and
> > look closely
> > > at previous clues
> > > by
> >
> http://git.igalia.com/cgi-bin/gitweb.cgi?p=webkit.git;a=shortlog;h=refs/heads/win-gst.
>  Of course, Alex, any piece of your updated code (off of the webkit-dev list) 
> will be more than welcome.
> > >
> > >
> > > On Fri, Oct 11, 2013 at 10:34 PM, Alex Christensen
> > >  wrote:
> > > I would like WinCairo to have video
> enabled,
> > also, but
> > > it would take some work.  This was done
> > successfully a
> > > few years ago by Phillippe Normand, but
> his
> > code needs
> > > to be updated.  I got it compiling a few
> > days ago, but
> > > something was wrong with my GStreamer
> > installation.
> > >
> > >
> > > Here's Phillippe's
> > > branch:
> >
> http://git.igalia.com/cgi-bin/gitweb.cgi?p=webkit.git;a=shortlog;h=refs/heads/win-gst
> > >
> > >

Re: [webkit-dev] [WinCairo] : ENABLE_VIDEO => how to activate HTML5 video tag ?

[Philippe Normand]

On Sat, 2013-10-12 at 14:53 +0200, Urbain EGIS wrote:
> Of course, I'm part of the challenge, Hugo. I started to analyse .diff
> files gently provided by Alex. Let's focus on one example :
> 
> 
> --- Source/WTF/WTF.vcxproj/WTF.vcxproj (revision 156730)
> +++ Source/WTF/WTF.vcxproj/WTF.vcxproj (working copy)
> @@ -73,6 +73,9 @@
> ...
> +
> ...
> 
> 
> Then my question is :
> where can I find this CPP file wtf\gobject\GlibUtilities.cpp ?
> I have done: git clone http://git.igalia.com/webkit.git 
> but is it the right way to get GSTREAMER-centric source files
> for/by WebKit ? It seems it's not enough/accurate
> 

Please don't forget that branch is more than 3 years old. A lot of code
changed in WebKit since then. And most of the commits in that branch
were not really ready to be upstreamed as it was mostly a
proof-of-concept.

Philippe

> 
> On Fri, Oct 11, 2013 at 11:05 PM, Hugo Machefer
>  wrote:
> Utterly, I'd be glad to take a serious and deep step forwards
> into this direction. Therefore, on both Brendan & Alex's
> instructions I'm gona opt for GSTREAMER as a default player,
> oviously. Urbain, are you with me/us ? The more, the merrier,
> you know ;-) First, as mentionned earlier, check
> with ENABLE(VIDEO) => shall be disclosing as a
> consequence many CPP files impacted.
> 
> 
> On my side, I am gona set WTF_USE_GSTREAMER, and look closely
> at previous clues
> by 
> http://git.igalia.com/cgi-bin/gitweb.cgi?p=webkit.git;a=shortlog;h=refs/heads/win-gst.
>  Of course, Alex, any piece of your updated code (off of the webkit-dev list) 
> will be more than welcome.
> 
> 
> On Fri, Oct 11, 2013 at 10:34 PM, Alex Christensen
>  wrote:
> I would like WinCairo to have video enabled, also, but
> it would take some work.  This was done successfully a
> few years ago by Phillippe Normand, but his code needs
> to be updated.  I got it compiling a few days ago, but
> something was wrong with my GStreamer installation.
> 
> 
> Here's Phillippe's
> branch: 
> http://git.igalia.com/cgi-bin/gitweb.cgi?p=webkit.git;a=shortlog;h=refs/heads/win-gst
> 
> 
> If anyone wants to look at my updated code, let me
> know and I'll email a diff off of the webkit-dev list.
> 
> 
> Alex Christensen
> 
> 
> On Fri, Oct 11, 2013 at 2:25 PM, Brendan Long
>  wrote:
> 
> On 10/11/2013 02:13 PM, Urbain EGIS wrote:
> 
> > "Playing" a bit with WebKit sources for
> > Windows (using WinCairo port) I expected to
> > activate HTML5 video tag. I just simply
> > put : #define ENABLE_VIDEO 1 and rebuilt
> > everything. But I realized that only few
> > files are concerned by USE(ENABLE_VIDEO) and
> > are not even .CPP files.
> It would be ENABLE(VIDEO), not
> USE(ENABLE_VIDEO).
> 
> 
> > So something may have been falling through
> > the net... But what ? What is missing from
> > Visual Studio generation ? Which procedure
> > shall be applied to get .CPP files included
> > into MS projects ?
> > 
> Most likely you need to specifiy which media
> player to use. For example, to use GStreamer
> you would define WTF_USE_GSTREAMER. I don't
> see a DirectShow media player, so GStreamer is
> probably your best bet.
> 
> You can look through the players by looking at
> file starting with "MediaPlayerPrivate", for
> example:
>   * AV Foundation (Mac)
>   * Blackberry
>   * GStreamer
>   * QTKit (QuickTime?)
>   * WinCE
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
>  

Re: [webkit-dev] Announcing new port: Nix

[Philippe Normand]

On Wed, 2013-09-11 at 17:43 -0300, Luciano Wolf wrote:

> The most recent effort from our side is to provide WebRTC support.
> Thiago Lacerda is talking with Eric Carlson and they are coordinating
> the merge of Blink patches as well as planning the development of
> missing features. So, I believe we are in the right path to become a
> mainstream port.
> 

Where is this discussion happening? I'd be interested to follow it.

I also plan to work on WebRTC support at the platform (GStreamer) level
if no one else steps up in bug #87514 :)

Philippe

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

Re: [webkit-dev] Ports not building as C++11?

[Philippe Normand]

FWIW the GTK+ port also builds with C++11 support.
Philippe

On Fri, 2013-07-26 at 09:04 -0700, Anders Carlsson wrote:
> Hi everyone,
> 
> when Oliver landed his “let’s break everything” patches in JSC the other day, 
> I noticed that some of the follow-up build fixes by other ports were removing 
> use of C++11 features (mainly nullptr).
> 
> Are there any ports that aren’t building as C++11? If so, why not?
> 
> - Anders
> 
> ___
> 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] Media Server Development

[Philippe Normand]

You should write a new MediaPlayerPrivate backend instead of hacking the
MediaPlayerPrivateGStreamer one.

Philippe

On Thu, 2013-01-31 at 23:04 +0530, Kiran K wrote:
> HI All,
> 
> I am working on QtWebKit  on Media Server development. Basic Idea is
> to run Gstreamer in seperate process which acts like a Media server.
> The calls  from WebKit in MediaPlayerPrivateGStreamer.cpp are routed
> to Media Server via DBUS. Media Server implements the methods in
> MediaPlayerPrivateGStreamer class. I am basically doing this to have
> control over the resources like maximum playback instances, hw codec
> control etc. I am able to do achieve playback to some extent. I am
> facing some problems  (race conditions) especially when deleting
> playback instance. From the logs i concluded that when duration()
> function is made  and is waiting for response from server,
> ~MediaPlayerPrivateGStreamer destructor is getting called. (some times
> vice versa too). I am suspecting that the MediaPlayer object is being
> shared between two threads (or across timers). Can anybody give me
> some pointers about HTMLMediaElement  and the timers involved? Any
> help is appreciated.
> 
> Thanks,
> Arun
> 
> ___
> 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] PSA: Migration plan to GStreamer 1.x

[Philippe Normand]

Hi,

This mail is mainly for the GTK, Qt and EFL port maintainers, I decided
to post here instead of cross-posting to three mailing lists :)

So there's been work to port the MediaPlayer and WebAudio GStreamer
backends to the new GStreamer 1.x APIs. At the moment you can choose
(well, for the GTK port at least) at build time if you want to use the
0.10 or 1.x APIs.

The issue is that GStreamer 0.10 is no longer actively maintained and
the GStreamer developers/maintainers entirely focus on GStreamer 1.x.

Moreover we currently don't have the manpower to maintain the 2 code
paths in the WebKit/GStreamer platform layer. The GTK port buildbots
already switched to 1.0 last month and I encourage Qt and EFL to do the
same ASAP, at least for their buildbots.

I'd like to propose we drop the GStreamer 0.10 support from WebKit once
the next stable branch of GStreamer is released, it will be 1.2,
scheduled somewhere around February.

Opinions welcome :)

Philippe

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

Re: [webkit-dev] svns...@macosforge.org ?

[Philippe Normand]

On Wed, 2012-08-08 at 13:52 -0700, Adam Barth wrote:
> I noticed today that some patches are authored by svns...@macosforge.org:
> 
> http://trac.webkit.org/search?q=svnsync
> 
> Is this behavior expected?
> 

I guess this is a bug in one of the SVN commit hooks?

Philippe

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

Re: [webkit-dev] Not authorized to access Bugzillia

[Philippe Normand]

This is a security bug. Only some people can access those, typically the
security team members at least.

Philippe

On Wed, 2012-08-08 at 16:32 +0800, talking1...@gmail.com wrote:
> When I try to access https://bugs.webkit.org/show_bug.cgi?id=41482, it
> show me follow information, so if I want to check some bug, it need
> send an email for request to grant the permissions?
> 
> 
> "You are not authorized to access bug #41482."
> 
> --
> BGs/Felix Shi
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] GTK+ port's help needed to get rid of FAIL test expectation

[Philippe Normand]

On 2012-06-10 19:09, Žan Doberšek wrote:

I think it would suffice to replace all the FAIL occurrences with
TEXT, except for the failing reftests - those should have FAIL turned
into IMAGE. Gtk bots don't run pixel tests yet so any other IMAGE
failures could perhaps be addressed at later time.



I agree with that approach.

Philippe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] can I replace webkitwebsrc with souphttpsrc?

[Philippe Normand]

On Sun, 2012-06-03 at 11:31 +0800, ZiQiangHuan wrote:
> Hi,
> 
> For support to html5 video on my device, I am doing something with
> webkit+gstreamer recently. But I found that there are custom plugins
> "webkitsrc" and "webkitsink" in webkit's gstreamer backend source
> code.For my device I have to replace webkitsink with my videosink. I
> met some trouble with "webkitsrc", and for example I cannot play mp4
> files if their size is too big.

A bug report describing the issue would be very welcome.

>  Then I test it when I replace webkitsrc with gstreamer's plugins
> souphttpsrc, the trouble disappears. So my question is that if I
> replace webkitsrc with souphttpsrc, any trouble I will meet? any
> functions I will loss?
> 

Yes. If you don't use the webkitwebsrc element you'll need to manually
set the user-agent, referer and HTTP cookies. I believe they can't be
set using GObject properties on the element.


> By the way, any introductions for webkit's streaming media policy I
> can learn?

I don't understand this question, please elaborate :)

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How can I get some debug infomation in MediaPlayerPrivateGStreamer.cpp

[Philippe Normand]

On Fri, 2012-04-20 at 10:42 +0800, ZiQiangHuan wrote:
> hi，
> 
> I build webkit with gstreamer support, but  I encountered a problem
> when I test with it. When I write a simple statement "printf("*
> \n")" in the function isAvailable() of
> MediaPlayerPrivateGStreamer.cpp, I got nothing output. When I do the
> same thing with the function create of
> MediaPlayerPrivateGStreamer.cpp, I got nothing output too. So I want
> to know if I want to get some debug info in these functions, what
> should I do? anyone has some experience with this? And I don't know
> why this happen.
> 

That's odd, the stdout buffer should be flushed since you insert a new
line. Try to force a fflush() call maybe?

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

[Philippe Normand]

On Thu, 2012-03-08 at 14:10 -0300, Alexis Menard wrote:
> On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa  wrote:
> > On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian 
> > wrote:
> >>
> >> In the light of discovering that some SVN scripts have fallen behind in
> >> terms of maintenance[1] and WebKit's strong Git support and infrastructure,
> >> against my better judgement, I'd like to distract you from being productive
> >> by bringing up this topic (again).
> >>
> >> The wiki page of the same name[2] was created 3 years ago and hardly
> >> updated since[3]. I know we're all busy with more important things, but 
> >> IMHO
> >> I think we can at least update the wiki and perhaps vote on when/how we
> >> should do the eventual transition.
> >>
> >> I understand that while this type of work isn't necessarily very
> >> productive, maintaining two repositories and sets of scripts (with their
> >> docs and issues) has a very real cost as well. I'm proposing we reevaluate
> >> the situation and act accordingly.
> >
> >
> > Re-evaluating the situation is good, but I'm still opposed.
> 
> I don't use svn but the only benefit I see of WebKit using svn is the
> linear history, clean, easy to read and to explore. Git repos tend to
> have merging commits a lot and it leads to make bisecting/history
> browsing harder (my taste).
> 

We just need to keep the history linear. With good practices it's
possible :)

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] git.webkit.org is offline

[Philippe Normand]

I still can't use the git mirror here and build.webkit.org doesn't
respond either, looks like an issue with the web server.

Philippe

On Wed, 2012-02-15 at 16:04 -0800, William Siegrist wrote:
> git.webkit.org is back up on faster/less-broken storage. 
> 
> -Bill
> 
> 
> 
> On Feb 15, 2012, at 1:29 PM, William Siegrist  wrote:
> 
> > We're still having problems. Git is currently down. I am making adjustments 
> > so I can bring it up and hopefully keep it up soon. 
> > 
> > -Bill
> > 
> > 
> > On Feb 15, 2012, at 11:29 AM, William Siegrist  wrote:
> > 
> >> All services are back.
> >> 
> >> -Bill
> >> 
> >> 
> >> On Feb 15, 2012, at 8:55 AM, William Siegrist wrote:
> >> 
> >>> That server (which includes git, build, nightly, and lists) is having 
> >>> trouble keeping up with load, probably due to a disk array problem. I 
> >>> will be rebooting it one more time in an hour or two to try to clear up 
> >>> the problem. 
> >>> 
> >>> -Bill
> >>> 
> >>> 
> >>> On Feb 15, 2012, at 6:38 AM, Osztrogonac Csaba wrote:
> >>> 
>  Hi,
>  
>  It seems git.webkit.org is offline.
>  Could you check what happened?
>  
>  br,
>  Ossy
>  ___
>  webkit-dev mailing list
>  webkit-dev@lists.webkit.org
>  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>> 
> >>> ___
> >>> webkit-dev mailing list
> >>> webkit-dev@lists.webkit.org
> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >> 
> > 
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] GTK 64-bit Debug slave is offline

[Philippe Normand]

The buildslave is back and kicking.
Thanks!
Philippe

On Fri, 2012-02-10 at 07:45 -0800, William Siegrist wrote:
> The master has been restarted. 
> 
> -Bill
> 
> 
> On Feb 10, 2012, at 3:37 AM, Philippe Normand wrote:
> 
> > Hi!
> > 
> > We can't start the 64-bit GTK Debug slave anymore, the error we get is:
> > 
> > 2012-02-10 03:27:55-0800 [Broker,client]
> > ReconnectingPBClientFactory.failedToGetPerspective
> > 2012-02-10 03:27:55-0800 [Broker,client] Unhandled Error
> > Traceback from remote host -- Traceback unavailable
> > 
> > It seems that means we get an authentication error. Can the buildmaster
> > admin please check this on their side?
> > 
> > Thanks!
> > Philippe
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] GTK 64-bit Debug slave is offline

[Philippe Normand]

Hi!

We can't start the 64-bit GTK Debug slave anymore, the error we get is:

2012-02-10 03:27:55-0800 [Broker,client]
ReconnectingPBClientFactory.failedToGetPerspective
2012-02-10 03:27:55-0800 [Broker,client] Unhandled Error
Traceback from remote host -- Traceback unavailable

It seems that means we get an authentication error. Can the buildmaster
admin please check this on their side?

Thanks!
Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Gstreamer libraries not linking?

[Philippe Normand]

> 
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_app_src_push_buffer'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_app_src_get_type'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_missing_element_message_new'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_video_parse_caps_pixel_aspect_ratio'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_app_src_set_stream_type'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_app_src_set_emit_signals'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_video_sink_get_type'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_video_format_parse_caps'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_app_src_end_of_stream'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_app_src_set_caps'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_app_src_set_max_bytes'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_app_src_set_callbacks'
> ./.libs/libwebkitgtk-1.0.so: undefined reference to
> `gst_app_src_set_size'
> collect2: ld returned 1 exit status
> make[1]: *** [Programs/GtkLauncher] Error 1
> make[1]: Leaving directory
> `/home/akg2136/JSH/WebKit-HashTab/WebKitBuild/Release'
> make: *** [all] Error 2
> 
> 

> 
> Looking these libraries up, I found that they are located in
> libgstinterfaces, but I can't seem to get the -l command into the
> build. My env is: 
> 
> 
> GSTREAMER_LIBS=-pthread -lgstbase-0.10 -lgstreamer-0.10 -lgobject-2.0
> -lgmodule-2.0 -lxml2 -lgthread-2.0 -lrt -lglib-2.0
>  -lgstinterfaces-0.10

> Am I missing something?
> 

Looks like something is wrong with your gstreamer installation.
You miss -lgstapp-0.10 -lgstpbutils-0.10 -lgstvideo-0.10 at least.

./configure checks for the following packages:

   PKG_CHECK_MODULES([GSTREAMER],
 [gstreamer-$GST_API_VERSION >=
$GSTREAMER_REQUIRED_VERSION
 gstreamer-app-$GST_API_VERSION
 gstreamer-audio-$GST_API_VERSION
 gstreamer-base-$GST_API_VERSION
 gstreamer-interfaces-$GST_API_VERSION
 gstreamer-pbutils-$GST_API_VERSION
 gstreamer-plugins-base-$GST_API_VERSION >=
$GSTREAMER_PLUGINS_BASE_REQUIRED_VERSION
 gstreamer-video-$GST_API_VERSION],
 [have_gstreamer=yes])

Philippe



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] About code reviews outside bugzilla

[Philippe Normand]

On Tue, 2012-01-10 at 14:48 +, Peter Beverloo wrote:
> The bugzilla bug is here, it's just not referenced in the message
> (which it should be):
> https://bugs.webkit.org/show_bug.cgi?id=75956
> 

Ah, thanks Peter!
Too bad the EWS wasn't not used though :(

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] About code reviews outside bugzilla

[Philippe Normand]

Hi,

I thought any substantial code contribution was to be reviewed in a
proper bugzilla entry?

This commit broke the WebKit2 build earlier today:

http://trac.webkit.org/changeset/104557

No mention of a bugzilla entry...

Hopefully Kenneth was quick coming up with a build fix, but please let's
use Bugzilla... In the case of this patch, the build breakage would have
been detected upfront by the EWS.

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory

[Philippe Normand]

On Mon, 2011-12-26 at 21:45 -0800, sachin nikam wrote:
> I synced up the latest webkit code base and am trying to build webkit
> gtk on ubuntu 11.10 with 4gb of RAM and 4 CPUs
> 
> I tried with --makeargs="-j2" but still got "ld process terminated
> signal[9]" error  which indicates that it ran out of memory.
> I suspect i will still the get the same error with --makeargs="-j1".
> Is there any other flag where we can restrict the memory usage?
> Regards
> Sachin

Can you try with the GNU Gold linker? We use it on the GTK Debug bot.

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [GTK] Buildslave changes

[Philippe Normand]

The bot is now deployed and so far, working well :)
Thanks Adam for the help!

Philippe

On Wed, 2011-11-30 at 17:03 -0500, Adam Roben wrote:
> On Nov 30, 2011, at 4:34 PM, Philippe Normand wrote:
> 
> > Can we get new buildbot credentials for the new slave or can we reuse
> > the 32-bits Debug ones? It'd be great if we can coordinate on this
> > migration soon :)
> 
> Credentials are a slave name/password pair. If you're using the old slave 
> name for the new machine then you should use the old password too.
> 
> If you're adding a new slave name, you should post a patch to bugs.webkit.org 
> to do so and CC me. Once the patch lands I'll update the master and send you 
> a password.
> 
> -Adam
> 
> 
> 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] [GTK] Buildslave changes

[Philippe Normand]

Hi!

Igalia recently purchased new hardware to improve the GTK Debug bots
situation. Here's the plan:

- Drop 32-bits Debug
- Keep current 64-bits Debug
- Add a 64-bits Release (which will run on the new hardware)

A full build on the new machine takes at most 7:30 minutes and tests
using NRWT run in about 3 minutes :)

Can we get new buildbot credentials for the new slave or can we reuse
the 32-bits Debug ones? It'd be great if we can coordinate on this
migration soon :)

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ping-pong with fast/files/create-blob-url-crash-expected.txt

[Philippe Normand]

On Wed, 2011-08-31 at 07:28 -0700, David Levin wrote:
> On Wed, Aug 31, 2011 at 5:57 AM, Philippe Normand 
> wrote:
> Sorry for the last one. 
> Looks like the patch in
> https://bugs.webkit.org/show_bug.cgi?id=66045
> is intended to fix this issue for both JSC and V8 code
> generators, if I
> understood correctly.
> 
> 
> Short story: http://trac.webkit.org/changeset/94023 is correct and we
> should fix the result that in there now.
> 
> 
> More:
> In general, when JSC and V8 disagree, we've gone with JSC in the
> platform independent file.
> 
> 
> http://trac.webkit.org/changeset/93713
> and http://trac.webkit.org/changeset/94168 didn't do this so they
> aren't following what is standard practice.
> 

I'll revert the involved part of r94168.
Philippe



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

Re: [webkit-dev] ping-pong with fast/files/create-blob-url-crash-expected.txt

[Philippe Normand]

Sorry for the last one.
Looks like the patch in https://bugs.webkit.org/show_bug.cgi?id=66045
is intended to fix this issue for both JSC and V8 code generators, if I
understood correctly.

Philippe

On Wed, 2011-08-31 at 13:40 +0200, Osztrogonac Csaba wrote:
> Hi,
> 
> It seems you guys are playing ping-pong with this platform independent 
> expected file.
> Could you decide which one is the correct?
> 
> br,
> Ossy
> 
> http://trac.webkit.org/changeset/93713
> http://trac.webkit.org/changeset/93713/trunk/LayoutTests/fast/files/create-blob-url-crash-expected.txt
> -PASS: Not enough arguments
> +PASS: Type error
> 
> http://trac.webkit.org/changeset/94023
> http://trac.webkit.org/changeset/94023/trunk/LayoutTests/fast/files/create-blob-url-crash-expected.txt
> -PASS: Type error
> +PASS: Not enough arguments
> 
> http://trac.webkit.org/changeset/94168
> http://trac.webkit.org/changeset/94168/trunk/LayoutTests/fast/files/create-blob-url-crash-expected.txt
> -PASS: Not enough arguments
> +PASS: Type error
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 


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

Re: [webkit-dev] [webkit-changes] [83955] trunk

[Philippe Normand]

I think this rollout highlighted the need for crash reports in the GTK
Release bot. The issue being absent from the Debug bots, we had to build
WebKitGTK with debug symbols and optimizations turned on to get useful
stack-traces.

Oliver relanded the big patch with an additional workaround for a gcc
reordering bug that he found after a gdb-over-irc session with me, once
I managed to have a local build useful enough for debugging.

Philippe

On Fri, 2011-04-15 at 10:55 -0700, Adam Barth wrote:
> As everyone knows, I'm a proponent of rolling things out more
> frequently, but that change looks huge.  I think we should have a bias
> against rolling out large changes because they're much harder and
> disruptive to roll in and out than small changes.  (Of course, we
> should also have a bias against accepting large patches, but sometimes
> they're necessary, as I assume Oliver's change was.)
> 
> Adam
> 
> 
> On Fri, Apr 15, 2011 at 10:41 AM, Oliver Hunt  wrote:
> > Indeed, i missed the gtk release one, but the point stands that just 
> > rolling out a patch (which should not roll out the changelogs) without 
> > providing any information about the crash doesn't help anyone.
> >
> > --Oliver
> >
> > On Apr 15, 2011, at 10:30 AM, Adam Roben wrote:
> >
> >> On Apr 15, 2011, at 1:19 PM, Oliver Hunt wrote:
> >>
> >>> Don't roll out patches that don't break any core builders, without making 
> >>> some attempt to diagnose the problem or providing information that will 
> >>> make it possible to fix the problem.
> >>
> >> The GTK bots are core builders.
> >>
> >> -Adam
> >>
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Using Git for WebKit development

[Philippe Normand]

On Tue, 2011-01-18 at 11:26 +0300, Konstantin Tokarev wrote:
> Hi all,
> 
> When I'm trying to cherry-pick or rebase something in my WebKit git clone,
> I constantly end up with conflicts in changelog files
> 
> How do you fight this problem?
> 

Add in your .git/config:

[merge "changelog"]
driver = Tools/Scripts/resolve-ChangeLogs --merge-driver %O %A %
B

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkitpy test failures on GTK bots

[Philippe Normand]

On Fri, 2010-12-24 at 22:27 +0100, Philippe Normand wrote:
> The first failing 32-bits release build is:
> 
> http://build.webkit.org/builders/GTK%20Linux%2032-bit%
> 20Release/builds/9010
> 
> which includes:
> 
> http://trac.webkit.org/changeset/74632
> 
> Could it be an issue with that unittest?
> 

I rolled out that changeset and reopened the corresponding bug.
I'm having a look at the test but I'm not familiar with that code, it
seems the message-broker loop of the added test-case doesn't stop, for
some reason.


> Philippe
> 
> On Fri, 2010-12-24 at 11:38 -0800, Darin Adler wrote:
> > Hi folks.
> > 
> > The GTK bots have been red for a while now; not sure whether it’s been days 
> > or weeks. These are core builders, so should not be red for that long. 
> > Apparently the issue is that some Python tests can’t be run because there’s 
> > a Google python module of some sort that must be installed. Could someone 
> > fix this? Here are possible ways to fix it:
> > 
> > 1) Turn off these tests for GTK.
> > 2) Install that module on the bots, if that’s appropriate.
> > 3) Take the GTK bots out of the core set.
> > 4) Undo whatever change made this problem start to occur recently.
> > 
> > Anyone?
> > 
> > -- Darin
> > 
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> > 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkitpy test failures on GTK bots

[Philippe Normand]

The first failing 32-bits release build is:

http://build.webkit.org/builders/GTK%20Linux%2032-bit%
20Release/builds/9010

which includes:

http://trac.webkit.org/changeset/74632

Could it be an issue with that unittest?

Philippe

On Fri, 2010-12-24 at 11:38 -0800, Darin Adler wrote:
> Hi folks.
> 
> The GTK bots have been red for a while now; not sure whether it’s been days 
> or weeks. These are core builders, so should not be red for that long. 
> Apparently the issue is that some Python tests can’t be run because there’s a 
> Google python module of some sort that must be installed. Could someone fix 
> this? Here are possible ways to fix it:
> 
> 1) Turn off these tests for GTK.
> 2) Install that module on the bots, if that’s appropriate.
> 3) Take the GTK bots out of the core set.
> 4) Undo whatever change made this problem start to occur recently.
> 
> Anyone?
> 
> -- Darin
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Buildbots soon to require apache mod_bw

[Philippe Normand]

> Having said that, it just struck me that we have a few php scripts that
> are used by tests to cause intentional delays[0]. Perhaps we could use a
> similar pattern for this case too, and avoid this new requirement.
> 

Thanks for the hint Gustavo :)
Actually I found video-throttled-load.cgi which nearly is perfect fit
for my test. I just need to add Range requests support to it, having a
look now.

Philippe

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

[webkit-dev] Buildbots soon to require apache mod_bw

[Philippe Normand]

Hi,

The patch to be landed soon for
https://bugs.webkit.org/show_bug.cgi?id=45101

updates the apache config to require mod_bw. Can the buildbots admins
please install it? I contacted the GTK+ bots admins already.

The new test on this patch requires connection throttling but will run
only on the GTK bots and I'll give it a try on the Chromium bots too.

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Context menu testing

[Philippe Normand]

Hi,

I've been writing a patch to improve the context-menu of the media
elements and a layout test would be nice for this.

I can send a contextClick() event on the media element but then, how do
i know at which position to move the mouse to click on a specific item?

The mac EventSender::contextClick() returns an array of the menu items
titles but the GTK EventSender doesn't do so. And still, I'd need the
position/size of the menu items.

Any hints?

Philippe

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

Re: [webkit-dev] Nighties build scripts

[Philippe Normand]

cf https://bugs.webkit.org/show_bug.cgi?id=40469

Philippe

On Wed, 2010-06-09 at 15:56 +0200, Philippe Normand wrote:
> Hi,
> 
> I've been trying the Nighly build scripts without much success. I run
> build-launcher-app and build-launcher-dmg.
> 
> The build-launcher-app tries to copy Drosera.app, which doesn't seem to
> be supported anymore, http://trac.webkit.org/wiki/Drosera :
> 
> "Drosera has been replaced by an improved debugger built into the Web
> Inspector. The information this page still applies to Safari 3.1 and
> 3.0." ...
> 
> So I commented out the Drosera stuff and get a 9.5 Mb DMG (compared to
> 40Mb on the nightlies website). Anyway, trying to use that DMG I get a
> popup saying my version of Mac OS X (10.6) is not supported "yet" by the
> nightlies. If I download the latest nightly build it works fine.
> 
> Can someone, maybe bdash?, light my lantern? :)
> 
> Philippe
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 


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

[webkit-dev] Nighties build scripts

[Philippe Normand]

Hi,

I've been trying the Nighly build scripts without much success. I run
build-launcher-app and build-launcher-dmg.

The build-launcher-app tries to copy Drosera.app, which doesn't seem to
be supported anymore, http://trac.webkit.org/wiki/Drosera :

"Drosera has been replaced by an improved debugger built into the Web
Inspector. The information this page still applies to Safari 3.1 and
3.0." ...

So I commented out the Drosera stuff and get a 9.5 Mb DMG (compared to
40Mb on the nightlies website). Anyway, trying to use that DMG I get a
popup saying my version of Mac OS X (10.6) is not supported "yet" by the
nightlies. If I download the latest nightly build it works fine.

Can someone, maybe bdash?, light my lantern? :)

Philippe

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

Re: [webkit-dev] Volcano

[Philippe Normand]

Currently in 1195 Oak st but it closes at 5pm. Eric suggested Cafe Abir
on 1300 Fulton st.

I have to go tomorrow afternoon to Sunnyvale for a meeting but in the
morning I should be in the Cafe Abir :)

I'm open to any suggestion anyway! Currently staying in Haight st around
#800, I'd prefer to stay around if possible.

Philippe

On Tue, 2010-04-20 at 14:37 -0700, Evan Martin wrote:
> I am down for a post-gathering SF hackathon.  Name a cafe and time.  :)
> 
> On Tue, Apr 20, 2010 at 2:00 PM, Philippe Normand  wrote:
> > Hi,
> >
> > I'm stuck in SF until sunday, unless I can find a flight earlier...
> > Hacking from a café there on some GTK fullscreen video support :)
> >
> > Philippe
> >
> > On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote:
> >> I should have asked sooner...
> >>
> >> Are any folks stuck here after the WebKit conference due to the volcano?
> >>
> >> If so, drop me a line.  I'd like to at least offer lunch and possibly
> >> some in-person hack-time.
> >>
> >> -eric
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>
> >
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Volcano

[Philippe Normand]

Hi,

I'm stuck in SF until sunday, unless I can find a flight earlier...
Hacking from a café there on some GTK fullscreen video support :)

Philippe

On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote:
> I should have asked sooner...
> 
> Are any folks stuck here after the WebKit conference due to the volcano?
> 
> If so, drop me a line.  I'd like to at least offer lunch and possibly
> some in-person hack-time.
> 
> -eric
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Git meeting notes

[Philippe Normand]

On Mon, 2010-04-12 at 13:59 -0700, Benjamin wrote:
> Quick and dirty notes from the Git discussion.
> 
> - April 12th 2010 / Garage 2 /  10:15 - 11:15
> 
> Who was there: Rim, Nokia, Qualcomm, Sony, Apple, Google, Gtk guys
> (sorry I forgot which company you were from)
> 

Igalia :-)

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] +R mode on #webkit IRC channel

[Philippe Normand]

Maybe it was a countermeasure for yesterday's CTCP flood attacks?

Philippe

On Tue, 2010-01-19 at 10:25 +0200, Xan Lopez wrote:
> Hi,
> 
> I woke up this morning to find #webkit set up with mode +R
> (http://docs.dal.net/docs/modes.html#2.17), so basically you can't
> speak unless you have your nick registered on freenode. Is this a new
> policy or just some error or temporary measure that someone forgot to
> disable? If it's the latter it would be good to go back to normality.
> 
> Cheers,
> 
> Xan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 


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

Re: [webkit-dev] Style for Gtk/Qt code

[Philippe Normand]

On Mon, 2009-12-21 at 01:25 -0600, Eric Seidel wrote:
> The style-bot warns for style errors in all code in the webkit tree,
> but I'm not sure if that's correct.
> 
> Are there sections of gtk/qt/whatever code which should be in a different 
> style?
> 
> Sometimes these warnings are ignored.  Sometimes they produce strange
> reactions like this one:
> https://bugs.webkit.org/show_bug.cgi?id=32661

See  https://bugs.webkit.org/show_bug.cgi?id=32858

I will send a patch for this bug and revert the offending parts of the
patch of Bug 32661 :)

Philippe

> Can we get consensus on if the WebKit style applies to all sections of
> code?  And if it does not, what style applies to the code it does not?
> 
> 
> I vote that the WebKit coding style should apply to all code in the WebKit 
> tree.
> 
> -eric
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev