[webkit-dev] The great commit queue experiment

[Geoffrey Garen]

Hi folks.

A bunch of us at the WebKit Contributors Meeting decided that we will spend the 
next week landing 100% of our patches through the commit queue. Please feel 
free to play along at home.

If we see problems, we’ll document our experiences here:

This is why I love or hate the commit queue
https://bugs.webkit.org/show_bug.cgi?id=151239

Hopefully this will help us prioritize improvements in the commit queue, if any 
are needed.

Regards,
Geoff
___
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

[Eric Carlson]

> On Jul 18, 2014, at 3:17 AM, Jacques-Olivier  wrote:
> 
> I’m new on this mailing so I’ll start by introducing myself:
> My name Jacques-Olivier Haché (J-O), I’m working for Temasys Communication, 
> and I’m entering the WebKit project to work on the implementation of WebRTC 
> inside WebKit.
> For those who would be following the WebRTC’s news, I’m also the main 
> developer of the WebRTC plugin released by Temasys.
> 

  Welcome to the WebKit community!

> I am now trying to enable the WebRTC related features to get a better 
> understanding of the current state of this part of the project. 
> I have to say that I faced a lack of documentation on this area. I found the 
> features list , a document about 
> how to add a new feature  but 
> nothing about how to turn a feature on and off (there is actually a TODO 
> about that in the second link).
> 
> I looked into the files that one needs to change to add a new feature and 
> found two interesting files:
> Source/WTF/wtf/FeatureDefines.h - where the WebRTC related contants were set 
> to 0 instead of 1
> Source/cmake/WebKitFeatures.cmake - where the contants were set to OFF
> I listed the following definitions that look related to WebRTC
> ENABLE_MEDIA_CAPTURE
  This flag is for features in the HTML Media Capture spec: 
http://www.w3.org/TR/html-media-capture/

> ENABLE_MEDIA_CONTROLS_SCRIPT
  This is for the JavaScript-based  and  controls some ports us.

> ENABLE_MEDIA_SOURCE
  This is for the Media Source Extension spec: 
http://www.w3.org/TR/media-source/
  
> ENABLE_MEDIA_STATISTICS
  This is for an experimental HTMLMediaElement statistics feature enabled by 
some ports.

> ENABLE_MEDIA_STREAM
  This is for the Media Capture and Streams spec: 
http://w3c.github.io/mediacapture-main/
> ENABLE_VIDEO
  This is for  and  in general.

> ENABLE_VIDEO_TRACK
  This is for WebVTT.

  You should not need to change any of these flags to build for the Mac.


> I turned those definitions to 1 and ON in the respective file and tried to 
> build.
> The code in the header WebCore/Modules/mediastream/mediastream.h could not 
> compile apparently because the observer did not have a destructor. I created 
> one:
> class Observer {
> public:
> virtual void didAddOrRemoveTrack() = 0;
>   virtual ~Observer() {};
> };
> 
  It sounds like your sources are not up to date, I fixed this in 
https://trac.webkit.org/r175066

> 
> I now have a linking error that I do not understand when building WebCore 
> with Xcode. 
> 
> Ld 
> 
> Undefined symbols for architecture x86_64:
>   "__ZN7WebCore11JSNavigator18webkitGetUserMediaEPN3JSC9ExecStateE", 
> referenced from:
>   
> __ZN7WebCore46jsNavigatorPrototypeFunctionWebkitGetUserMediaEPN3JSC9ExecStateE
>  in JSNavigator.o
>   "__ZN7WebCore15RTCOfferOptions6createERKNS_10DictionaryERi", referenced 
> from:
>  
> __ZN7WebCore17RTCPeerConnection11createOfferEN3WTF10PassRefPtrINS_29RTCSessionDescriptionCallbackEEENS2_INS_30RTCPeerConnectionErrorCallbackEEERKNS_10DictionaryERi
>  in RTCPeerConnection.o
>   
> "__ZN7WebCore20MediaConstraintsMock17verifyConstraintsEN3WTF10PassRefPtrINS_16MediaConstraintsEEE",
>  referenced from:
>   
> __ZN7WebCore21MockMediaStreamCenter26validateRequestConstraintsEN3WTF10PassRefPtrINS_25MediaStreamCreationClientEEENS2_INS_16MediaConstraintsEEES6_
>  in MockMediaStreamCenter.o
>   
> __ZN7WebCore21MockMediaStreamCenter17createMediaStreamEN3WTF10PassRefPtrINS_25MediaStreamCreationClientEEENS2_INS_16MediaConstraintsEEES6_
>  in MockMediaStreamCenter.o
>   "__ZN7WebCore21RTCOfferAnswerOptions6createERKNS_10DictionaryERi", 
> referenced from:
>   
> __ZN7WebCore17RTCPeerConnection12createAnswerEN3WTF10PassRefPtrINS_29RTCSessionDescriptionCallbackEEENS2_INS_30RTCPeerConnectionErrorCallbackEEERKNS_10DictionaryERi
>  in RTCPeerConnection.o
>   
> "__ZN7WebCore4toJSEPN3JSC9ExecStateEPNS_17JSDOMGlobalObjectEPNS_16RTCConfigurationE",
>  referenced from:
>   
> __ZN7WebCore52jsRTCPeerConnectionPrototypeFunctionGetConfigurationEPN3JSC9ExecStateE
>  in JSRTCPeerConnection.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
  I don’t get these errors when I build, I suspect they will go away for you 
when you update your sources to TOT.


> 
> Is anyone used to turn the WebRTC code on and off?
> 

  WebKit’s WebRTC implementation is currently in a state of flux, moving from a 
platform API that maps closely to the RTC JavaScript API to a more abstract 
interface will make it easier to use different backend libraries. See bugs 
https://webkit.org/b/150165 and https://webkit.org/b/150166 for example.

eric


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

[webkit-dev] Protect promise capabilities from being vended again

[Xabier Rodríguez Calvar]

Hello,

When you create a promise capability, there's nothing preventing you
from calling again @resolve and @reject on the capability to vend the
promise twice. In the case of the Streams implementation to create
capabilities are are already vended, we do it as { @promise: @Promise.@
resolve } or @reject and those capability objects don't have the
@resolve and @reject slots so calling them would obviously fail.

Vending a promise twice means probably an issue in the algorithm that
you are implementing and if it were properly designed that shouldn't
happen. Software and specs can have bugs though and we could end up
hitting those unexpected cases.

For that I think we could change the internal promise capabilities to
use the newly added @assert when they are vended twice and also add two
functions to create those vended capabilities in a single call.

Any comments?

-- 
Xabier Rodríguez Calvar
Software Engineer
IGALIA http://www.igalia.com



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