[webkit-dev] run-webkit-tests and run-perf-tests scripts now use WebKitTestRunner by default

2015-03-05 Thread Chris Dumez
Hi,

I just wanted to let you know that run-webkit-tests and run-perf-tests now use 
WebKitTestRunner by default after [1].
Passing —webkit-test-runner or -2 to these scripts is no longer needed (and no 
longer works).

If you wish to run DumpRenderTree, you should pass —dump-render-tree or -1 to 
these scripts.

Kr,
--
 Chris Dumez - Apple Inc. - Cupertino, CA


[1] https://trac.webkit.org/r181093
 https://trac.webkit.org/r181093___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] “createMediaStreamSource” of “AudioContext” is undefined using Safari browser !

2015-03-05 Thread Sasi San
Hi-

I am using Temasys’ Free WebRTC Plugin in my project with web audio APIs to
get the audio stream. It works on all the browsers except Safari which is
complaining about “createMediaStreamSource” of “AudioContext” is undefined.

Please let me know when this API will be available for Safari. or Is there
any other API available to capture the audio stream from onAudioProcess
function.

Thanks,

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


[webkit-dev] NEON_INTRINSICS

2015-03-05 Thread Carlos Garcia Campos
Yesterday a patch was submitted to fix the build with NEON_INTRINSICS,
and Ossy pointed out that the build has been broken since r170433, and
nobody has noticed it until now. So that makes me wonder if anybody is
actually using that and if it even works, because otherwise we should
probably remove the NEON_INTRINSICS code. 

So, is there anybody actually using that (I guess patched downstream)?


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


Re: [webkit-dev] Unused parameter warnings / errors / warning fixes

2015-03-05 Thread Osztrogonác Csaba

Hi again,

it seems opinions are dived about how and what should we do.

I agree that turning on errors for unused parameter for Objective-C
files is undesirable, because we can't omit the parameter name.
Additionally it isn't easy (or maybe it is impossible) to build only
Objective-C sources with -Wno-unused-parameter setting.

I tried to add -Wno-unused-parameter COMPILER_FLAGS to the pbxproj
file for an Objective-C file, but unfortunately -Wall and -Wextra
in WARNING_CFLAGS in *.xcconfig files is stronger, because it is
added later to the compiler argument list.

First and last, I suggest that cmake ports should switch on error
for unused parameters except in WebKit2, where I propose simply
suppressing the warning. This would match the actual Mac settings.

I closed the original bug as wontfixed:
https://bugs.webkit.org/show_bug.cgi?id=140764

and filed a new bug report for cmake fix:
https://bugs.webkit.org/show_bug.cgi?id=142338

br,
Ossy


Osztrogonác Csaba írta:

I noticed many patches to fix newly introduced unused
parameter warnings on GTK and EFL ports nowadays.
(ToT EFL WebKit is warning free right now.)

CMake ports now handle unused parameters as warnings, not build
errors everywhere. (-Werror and -Wno-error=unused-parameter )
Mac port handles them as build errors, except in WebKit, WebKit2
and WebInspectorUI, where it is disabled (-Wno-unused-parameter)
WebInspectorUI  is warning free now, but there are zillion warnings
in WebKit and Webkit2.

It would be great if we can handle unused parameters in the same way:
- treat them as errors
- treat them as warnings and fix sometimes
- disable them and don't try to fix again and again
  (and maybe remove zillion UNUSED_PARAM warning fixes )

I played a little bit to see if it is possible to get rid these warnings
easily on Mac too and then handle the new ones as build failres:
https://bugs.webkit.org/show_bug.cgi?id=140764

But I'm not sure if treating unused parameters as errors would be good
idea, because many of them depend on different feature ifdef guards
and it might cause more frequent build failures. Maybe disabling them
would be better.

Ideas, opinions, concerns and suggestions are welcome.

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