Re: [webkit-dev] WebCore/platform standalone library
El mié, 18-03-2015 a las 21:43 -0700, Myles C. Maxfield escribió: Hello, all, I’d like to announce that I intend to create a standalone static library from the current contents of WebCore/platform over the coming months. This will involve creating a “Platform top-level directory and moving source files into it, one by one. Yes! There are a few reasons for this: 1. Enforcing the layering between Platform and WebCore. Moving Platform into its own target/directory can guarantee that nothing inside it knows about anything in WebCore. 2. Being able to test code in the Platform directory with TestWebKitAPI (without exporting Platform symbols from the WebCore library) 3. Managing conceptual complexity. Does anyone have any thoughts or feedback? This has always been blocked by the existing layering violations, what are your plans for that? I guess we will have WebCore/platform and Platform at the same time for a while until all layering violations are fixed? See the tracking bug: https://bugs.webkit.org/show_bug.cgi?id=21354 But there are more, I wrote a script to get the list of violations, it's in Tools/Scripts/check-for-platform-layering-violations Thanks, Myles ___ 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] WebCore/platform standalone library
I think JavaScriptCore will need access to 'platform', too, to implement some ES6 features. Saam On Thu, Mar 19, 2015 at 2:50 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote: On 3/18/15 9:43 PM, Myles C. Maxfield wrote: Hello, all, I’d like to announce that I intend to create a standalone static library from the current contents of WebCore/platform over the coming months. This will involve creating a “Platform top-level directory and moving source files into it, one by one. There are a few reasons for this: 1. Enforcing the layering between Platform and WebCore. Moving Platform into its own target/directory can guarantee that nothing inside it knows about anything in WebCore. 2. Being able to test code in the Platform directory with TestWebKitAPI (without exporting Platform symbols from the WebCore library) 3. Managing conceptual complexity. Does anyone have any thoughts or feedback? That's an awesome project. That's gonna be a lot of work. How do you plan to do the interface between WebCore and Platform? Between WebCore and WebKit, we use interfaces with pure virtual functions that are implemented by the clients. Between WebCore and the platform, we have headers and each port has its own implementation of that interface. Do you plan to move Platform behind a public interface or keep the current model? I don’t think we need a model like the WebCore/WebKit interface. WTF is essentially like the proposed Platform library already, and it just exposes normal C++ headers and implementation files. I think the main benefit here is cleaning up the layering, as opposed to adding more abstraction. In fact, you could sort of think of WTF and Platform as logically the same library, with WTF being only the parts needed by JavaScriptCore, plus things that are logically at the same level (so basically non-GUI and no networking code). This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. Regards, Maciej ___ 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] WebCore/platform standalone library
On Mar 19, 2015, at 3:44 PM, saam barati saambara...@gmail.com wrote: I think JavaScriptCore will need access to 'platform', too, to implement some ES6 features. Anything needed for JavaScriptCore should go to WTF. Otherwise there is no point having a separation. - Maciej Saam On Thu, Mar 19, 2015 at 2:50 PM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com wrote: On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote: On 3/18/15 9:43 PM, Myles C. Maxfield wrote: Hello, all, I’d like to announce that I intend to create a standalone static library from the current contents of WebCore/platform over the coming months. This will involve creating a “Platform top-level directory and moving source files into it, one by one. There are a few reasons for this: 1. Enforcing the layering between Platform and WebCore. Moving Platform into its own target/directory can guarantee that nothing inside it knows about anything in WebCore. 2. Being able to test code in the Platform directory with TestWebKitAPI (without exporting Platform symbols from the WebCore library) 3. Managing conceptual complexity. Does anyone have any thoughts or feedback? That's an awesome project. That's gonna be a lot of work. How do you plan to do the interface between WebCore and Platform? Between WebCore and WebKit, we use interfaces with pure virtual functions that are implemented by the clients. Between WebCore and the platform, we have headers and each port has its own implementation of that interface. Do you plan to move Platform behind a public interface or keep the current model? I don’t think we need a model like the WebCore/WebKit interface. WTF is essentially like the proposed Platform library already, and it just exposes normal C++ headers and implementation files. I think the main benefit here is cleaning up the layering, as opposed to adding more abstraction. In fact, you could sort of think of WTF and Platform as logically the same library, with WTF being only the parts needed by JavaScriptCore, plus things that are logically at the same level (so basically non-GUI and no networking code). This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. Regards, Maciej ___ 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] WebCore/platform standalone library
On Mar 19, 2015, at 5:19 PM, Anders Carlsson ander...@apple.com wrote: On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I think putting platform code in a separate namespace would be a good first step. Then we can weed out the layering violations and ultimately move everything to a separate library. I think it would also be fine to start by moving every file that doesn’t contain a layering violation and then fix the remainder. Moving the files could be done together with changing the namespace, or as a separate pass. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
On 3/19/15 2:49 PM, Maciej Stachowiak wrote: On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote: On 3/18/15 9:43 PM, Myles C. Maxfield wrote: Hello, all, I’d like to announce that I intend to create a standalone static library from the current contents of WebCore/platform over the coming months. This will involve creating a “Platform top-level directory and moving source files into it, one by one. There are a few reasons for this: 1. Enforcing the layering between Platform and WebCore. Moving Platform into its own target/directory can guarantee that nothing inside it knows about anything in WebCore. 2. Being able to test code in the Platform directory with TestWebKitAPI (without exporting Platform symbols from the WebCore library) 3. Managing conceptual complexity. Does anyone have any thoughts or feedback? That's an awesome project. That's gonna be a lot of work. How do you plan to do the interface between WebCore and Platform? Between WebCore and WebKit, we use interfaces with pure virtual functions that are implemented by the clients. Between WebCore and the platform, we have headers and each port has its own implementation of that interface. Do you plan to move Platform behind a public interface or keep the current model? I don’t think we need a model like the WebCore/WebKit interface. WTF is essentially like the proposed Platform library already, and it just exposes normal C++ headers and implementation files. I think the main benefit here is cleaning up the layering, as opposed to adding more abstraction. In fact, you could sort of think of WTF and Platform as logically the same library, with WTF being only the parts needed by JavaScriptCore, plus things that are logically at the same level (so basically non-GUI and no networking code). This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. Have you seen the clean interface of ResourceHandle? :) The client layers tend to get cleaner over time while the lower layers tends to become messier. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I think putting platform code in a separate namespace would be a good first step. Then we can weed out the layering violations and ultimately move everything to a separate library. - Anders (who’s not going to propose any namespace names) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Modern image formats for WebKit
Are there no existing libraries that can be conditionally linked with for supporting these formats? In the long term, it seems like bad design to have WebKit have its own custom decoders. If that isn't an option, it seems fine to me provided that the decoders' sources are all close together (for some definition of close) and not peppered throughout WebKit. On Mar 19, 2015, at 9:38 PM, ChangSeok Oh changseok...@collabora.com wrote: Hi WebKittens. I just saw apng support landed on webkit main stream. [1] (even it works for gtk port only now) So I suddenly wonder if webkit community is getting interested in bringing other modern image formats like webp or jpeg-xr into webkit. If so, I can lend my hands for it. For webp support, as you know, we can reuse blink's codebase. [2] For jpeg-xr supprot, I have a rough sketch for it [3] (it might be outdated or not fit tot of webkit though, bringing it to webkit is just a piece of cake. ;)) My intention is not to argue which format is better, just to ask community's thoughts, preferences or like that. [1] https://bugs.webkit.org/show_bug.cgi?id=17022 [2] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cppq=webpimasq=package:chromiuml=1 [3] http://cgit.collabora.com/git/user/kevino/Blink.git/commit/?h=jxr-supportid=2ac58312a5aae502aacc1c55c0bfdff767ab82a2 BR. -- ChangSeok ___ 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] Modern image formats for WebKit
Hi WebKittens. I just saw apng support landed on webkit main stream. [1] (even it works for gtk port only now) So I suddenly wonder if webkit community is getting interested in bringing other modern image formats like webp or jpeg-xr into webkit. If so, I can lend my hands for it. For webp support, as you know, we can reuse blink's codebase. [2] For jpeg-xr supprot, I have a rough sketch for it [3] (it might be outdated or not fit tot of webkit though, bringing it to webkit is just a piece of cake. ;)) My intention is not to argue which format is better, just to ask community's thoughts, preferences or like that. [1] https://bugs.webkit.org/show_bug.cgi?id=17022 [2] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cppq=webpimasq=package:chromiuml=1 [3] http://cgit.collabora.com/git/user/kevino/Blink.git/commit/?h=jxr-supportid=2ac58312a5aae502aacc1c55c0bfdff767ab82a2 BR. -- ChangSeok ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
I do not intend on changing any interfaces or semantics. I only intend to change where code lives and library boundaries. There is no need to increase the scope of this project. Also, I do not intend on making up a comical name. --Myles On Mar 19, 2015, at 3:03 PM, Benjamin Poulain benja...@webkit.org wrote: On 3/19/15 2:49 PM, Maciej Stachowiak wrote: On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote: On 3/18/15 9:43 PM, Myles C. Maxfield wrote: Hello, all, I’d like to announce that I intend to create a standalone static library from the current contents of WebCore/platform over the coming months. This will involve creating a “Platform top-level directory and moving source files into it, one by one. There are a few reasons for this: 1. Enforcing the layering between Platform and WebCore. Moving Platform into its own target/directory can guarantee that nothing inside it knows about anything in WebCore. 2. Being able to test code in the Platform directory with TestWebKitAPI (without exporting Platform symbols from the WebCore library) 3. Managing conceptual complexity. Does anyone have any thoughts or feedback? That's an awesome project. That's gonna be a lot of work. How do you plan to do the interface between WebCore and Platform? Between WebCore and WebKit, we use interfaces with pure virtual functions that are implemented by the clients. Between WebCore and the platform, we have headers and each port has its own implementation of that interface. Do you plan to move Platform behind a public interface or keep the current model? I don’t think we need a model like the WebCore/WebKit interface. WTF is essentially like the proposed Platform library already, and it just exposes normal C++ headers and implementation files. I think the main benefit here is cleaning up the layering, as opposed to adding more abstraction. In fact, you could sort of think of WTF and Platform as logically the same library, with WTF being only the parts needed by JavaScriptCore, plus things that are logically at the same level (so basically non-GUI and no networking code). This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. Have you seen the clean interface of ResourceHandle? :) The client layers tend to get cleaner over time while the lower layers tends to become messier. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
Sorry, I missed some of this thread before sending my reply. First, I'm going to try to get as far as I can by only moving over the non-layer-violating code. Therefore, for the interim, we will have both old and new directories. Then I will work on removing layering violations, one by one. These things will be taken on a case by case basis. --Myles On Mar 19, 2015, at 10:07 PM, Myles C. Maxfield mmaxfi...@apple.com wrote: I do not intend on changing any interfaces or semantics. I only intend to change where code lives and library boundaries. There is no need to increase the scope of this project. Also, I do not intend on making up a comical name. --Myles On Mar 19, 2015, at 3:03 PM, Benjamin Poulain benja...@webkit.org wrote: On 3/19/15 2:49 PM, Maciej Stachowiak wrote: On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote: On 3/18/15 9:43 PM, Myles C. Maxfield wrote: Hello, all, I’d like to announce that I intend to create a standalone static library from the current contents of WebCore/platform over the coming months. This will involve creating a “Platform top-level directory and moving source files into it, one by one. There are a few reasons for this: 1. Enforcing the layering between Platform and WebCore. Moving Platform into its own target/directory can guarantee that nothing inside it knows about anything in WebCore. 2. Being able to test code in the Platform directory with TestWebKitAPI (without exporting Platform symbols from the WebCore library) 3. Managing conceptual complexity. Does anyone have any thoughts or feedback? That's an awesome project. That's gonna be a lot of work. How do you plan to do the interface between WebCore and Platform? Between WebCore and WebKit, we use interfaces with pure virtual functions that are implemented by the clients. Between WebCore and the platform, we have headers and each port has its own implementation of that interface. Do you plan to move Platform behind a public interface or keep the current model? I don’t think we need a model like the WebCore/WebKit interface. WTF is essentially like the proposed Platform library already, and it just exposes normal C++ headers and implementation files. I think the main benefit here is cleaning up the layering, as opposed to adding more abstraction. In fact, you could sort of think of WTF and Platform as logically the same library, with WTF being only the parts needed by JavaScriptCore, plus things that are logically at the same level (so basically non-GUI and no networking code). This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. Have you seen the clean interface of ResourceHandle? :) The client layers tend to get cleaner over time while the lower layers tends to become messier. ___ 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] A quick note on Ref and RefPtr changes
On 17/02/15 10:28, Adam Bergkvist wrote: On 15/12/14 19:59, Andreas Kling wrote: PS. Once the kinks are ironed out, I’ll also be updating the RefPtr documentation on webkit.org. Any progress on this particular part? Bump. /Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Running new/modified tests on EWS bots
On 19/03/15 16:46, youenn fablet wrote: Hi, Related to the webkit contributor meeting discussion related to ports, I would find it useful if EWS bots (gtk, efl, win, ios) were running the tests that are modified/created by a patch. The idea would be to turn yellow the port bubble whenever one of these tests do not pass. Results would be uploaded to bugzilla. This would give an incentive for patch developers to try fixing the tests on these ports. That may reduce (slightly? noticeably?) port maintainers gardening effort. That would also be valuable when importing test suites. Any potential issue? objection to move that forward? Anyone willing to help? Thoughts? I think that having an EWS running only the tests that the patch touches is of limited value because a patch can break unrelated tests. However running all the tests requires to have the tree green and this is not possible for GTK or EFL because it will require more manpower than the currently available. An idea that comes to mind for running all the tests without requiring to have the tree green is the following: 1) EWS either run all the tests without the patch or download from https://build.webkit.org/results the results from the bot for the revision if they are available. 2) EWS run all the tests with the patch. 3) EWS gets the diff from 1. and 2. 4) EWS runs only the tests that broke from 1 to 2 several times, in order to discard the ones that are flaky and only report the ones that on every run fail now. If I'm not overlooking something, I think that this would allow to identify what tests a given patch breaks and it won't require to have the tree green, neither it will be affected by flaky tests. signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Safari browser on Mac OSX complains AudioContext.createMediaStreamSource is undefined !
Jer or Eric would know more about this but
AudioContext.createMediaStreamSource() is behind a MEDIA_STREAM compile-time
flag. It appears the mac port does not turn this flag on so Safari does not
currently support the Media Stream API.
Kr,
--
Chris Dumez - Apple Inc. - Cupertino, CA
On Mar 19, 2015, at 9:35 AM, Sasi San sasikumar.gan...@gmail.com wrote:
Hi-
I am trying to get the live audio input from microphone using AudioContext.
Safari browser complains that the createMediaStreamSource is undefined.
here is my sample of JavaScript code. It's not able to create Audio source
node. So I am not able to get the audio sample from microphone in the
OnAudioProcess event handler.
var micGain = audioContext.createGain();
if(!audioContext.createScriptProcessor){
micAudioProcessor = audioContext.createJavaScriptNode(bufferSize,
1, 1);
console.log('createJavaScriptNode Done');
} else {
micAudioProcessor =
audioContext.createScriptProcessor(bufferSize, 1, 1);
console.log('createScriptProcessor Done');
}
// Create an AudioNode from the stream.
if(typeof(audioContext.createMediaStreamSource) === 'function') {
micInput = audioContext.createMediaStreamSource(inAudioStream);
micInput.connect(micGain);
}
else {
console.log('method createMediaStreamSource unavailable');
}
Please let me know why Safari is complaining on this API
createMediaStreamSource . Is there any other way I can get the live audio
sample from microphone on Safari browser???
Thanks,
Sasi
___
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] Safari browser on Mac OSX complains AudioContext.createMediaStreamSource is undefined !
Thanks Chris. Is there any other way I can turn that flag? or Do you any
idea whether it will be supported in the near furture?
Sasi
On Thu, Mar 19, 2015 at 11:12 AM, Chris Dumez cdu...@apple.com wrote:
Jer or Eric would know more about this but
AudioContext.createMediaStreamSource() is behind a MEDIA_STREAM
compile-time flag. It appears the mac port does not turn this flag on so
Safari does not currently support the Media Stream API.
Kr,
--
Chris Dumez - Apple Inc. - Cupertino, CA
On Mar 19, 2015, at 9:35 AM, Sasi San sasikumar.gan...@gmail.com wrote:
Hi-
I am trying to get the live audio input from microphone using
AudioContext. Safari browser complains that the createMediaStreamSource
is undefined. here is my sample of JavaScript code. It's not able to create
Audio source node. So I am not able to get the audio sample from microphone
in the OnAudioProcess event handler.
var micGain = audioContext.createGain();
if(!audioContext.createScriptProcessor){
micAudioProcessor =
audioContext.createJavaScriptNode(bufferSize, 1, 1);
console.log('createJavaScriptNode Done');
} else {
micAudioProcessor =
audioContext.createScriptProcessor(bufferSize, 1, 1);
console.log('createScriptProcessor Done');
}
// Create an AudioNode from the stream.
if(typeof(audioContext.createMediaStreamSource) === 'function') {
micInput = audioContext.createMediaStreamSource(inAudioStream);
micInput.connect(micGain);
}
else {
console.log('method createMediaStreamSource unavailable');
}
Please let me know why Safari is complaining on this API
createMediaStreamSource . Is there any other way I can get the live audio
sample from microphone on Safari browser???
Thanks,
Sasi
___
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] WebCore/platform standalone library
On 3/18/15 9:43 PM, Myles C. Maxfield wrote: Hello, all, I’d like to announce that I intend to create a standalone static library from the current contents of WebCore/platform over the coming months. This will involve creating a “Platform top-level directory and moving source files into it, one by one. There are a few reasons for this: 1. Enforcing the layering between Platform and WebCore. Moving Platform into its own target/directory can guarantee that nothing inside it knows about anything in WebCore. 2. Being able to test code in the Platform directory with TestWebKitAPI (without exporting Platform symbols from the WebCore library) 3. Managing conceptual complexity. Does anyone have any thoughts or feedback? That's an awesome project. That's gonna be a lot of work. How do you plan to do the interface between WebCore and Platform? Between WebCore and WebKit, we use interfaces with pure virtual functions that are implemented by the clients. Between WebCore and the platform, we have headers and each port has its own implementation of that interface. Do you plan to move Platform behind a public interface or keep the current model? Thanks, Myles ___ 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] WebCore/platform standalone library
On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote: On 3/18/15 9:43 PM, Myles C. Maxfield wrote: Hello, all, I’d like to announce that I intend to create a standalone static library from the current contents of WebCore/platform over the coming months. This will involve creating a “Platform top-level directory and moving source files into it, one by one. There are a few reasons for this: 1. Enforcing the layering between Platform and WebCore. Moving Platform into its own target/directory can guarantee that nothing inside it knows about anything in WebCore. 2. Being able to test code in the Platform directory with TestWebKitAPI (without exporting Platform symbols from the WebCore library) 3. Managing conceptual complexity. Does anyone have any thoughts or feedback? That's an awesome project. That's gonna be a lot of work. How do you plan to do the interface between WebCore and Platform? Between WebCore and WebKit, we use interfaces with pure virtual functions that are implemented by the clients. Between WebCore and the platform, we have headers and each port has its own implementation of that interface. Do you plan to move Platform behind a public interface or keep the current model? I don’t think we need a model like the WebCore/WebKit interface. WTF is essentially like the proposed Platform library already, and it just exposes normal C++ headers and implementation files. I think the main benefit here is cleaning up the layering, as opposed to adding more abstraction. In fact, you could sort of think of WTF and Platform as logically the same library, with WTF being only the parts needed by JavaScriptCore, plus things that are logically at the same level (so basically non-GUI and no networking code). This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Running new/modified tests on EWS bots
Hi, I'd like this idea basically, it would be great if you or somebody else could work on it. One of my former collegue started to investigate the same thing 1.5 years before, but it was lost among many tasks with higher priorities. Feel free to reuse these bugs and WIP patches: (or file new ones) - https://bugs.webkit.org/show_bug.cgi?id=117831 - and bugs in its depends on list In my opinion red tree and flakey tets could cause many problems, because EWS is designed primarily for green tree. But unfortunately only Mac (and now Win release) bots are green almost all the time. I can't remember if EFL or GTK bots were green in the last 1-2 years ever. :-/ Now the tester EWS bots (Mac WK1 and WK2) run all tests. If all tests pass, there is no problem. But if there is only one failure, it tries to build and run tests without the patch. If all tests pass, the patch caused the regression. If there are exactly the same failures on the trunk and with the patch, the bubble becomes green. But flakey failures on the trunk can make EWS crazy. I remember that EWS wasn't able to process any patch for days because of 1-2 flakey failures on the trunk. If we enabled full or partial testing on unstable EWSs, they would become very slow, unstable and we would lost the very quick and stable builder EWSs. Maybe we should have separated builder and builder-and-tester EWS bots to avoid this kind of problems, but we would need more hardware for it. Anyway it would be great if EFL and GTK maintainers could keep the tester bots green almost all the time. I know it isn't an easy task and would need more resource. I remember from the QtWebKit era that 1-2 full-time gardener can be enough to keep the tree green, but it means only minor buildfixes, expected updates, new bug reports and skipping/marking new failures time to time. To increase the stabilility, fix regressions, decrease the number of skipped tests would need much more resource. Of course, I willingly help you, but unfortunately I don't have too much time for this topic nowadays. But feel free to cc me to related bugs and I'll try to help if I can. br, Ossy youenn fablet írta: Hi, Related to the webkit contributor meeting discussion related to ports, I would find it useful if EWS bots (gtk, efl, win, ios) were running the tests that are modified/created by a patch. The idea would be to turn yellow the port bubble whenever one of these tests do not pass. Results would be uploaded to bugzilla. This would give an incentive for patch developers to try fixing the tests on these ports. That may reduce (slightly? noticeably?) port maintainers gardening effort. That would also be valuable when importing test suites. Any potential issue? objection to move that forward? Anyone willing to help? Thoughts? Thanks, Youenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Running new/modified tests on EWS bots
Hi, Related to the webkit contributor meeting discussion related to ports, I would find it useful if EWS bots (gtk, efl, win, ios) were running the tests that are modified/created by a patch. The idea would be to turn yellow the port bubble whenever one of these tests do not pass. Results would be uploaded to bugzilla. This would give an incentive for patch developers to try fixing the tests on these ports. That may reduce (slightly? noticeably?) port maintainers gardening effort. That would also be valuable when importing test suites. Any potential issue? objection to move that forward? Anyone willing to help? Thoughts? Thanks, Youenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Safari browser on Mac OSX complains AudioContext.createMediaStreamSource is undefined !
Hi-
I am trying to get the live audio input from microphone using AudioContext.
Safari browser complains that the createMediaStreamSource is undefined.
here is my sample of JavaScript code. It's not able to create Audio source
node. So I am not able to get the audio sample from microphone in the
OnAudioProcess event handler.
var micGain = audioContext.createGain();
if(!audioContext.createScriptProcessor){
micAudioProcessor =
audioContext.createJavaScriptNode(bufferSize, 1, 1);
console.log('createJavaScriptNode Done');
} else {
micAudioProcessor =
audioContext.createScriptProcessor(bufferSize, 1, 1);
console.log('createScriptProcessor Done');
}
// Create an AudioNode from the stream.
if(typeof(audioContext.createMediaStreamSource) === 'function') {
micInput = audioContext.createMediaStreamSource(inAudioStream);
micInput.connect(micGain);
}
else {
console.log('method createMediaStreamSource unavailable');
}
Please let me know why Safari is complaining on this API
createMediaStreamSource . Is there any other way I can get the live audio
sample from microphone on Safari browser???
Thanks,
Sasi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Running new/modified tests on EWS bots
O Xov, 19-03-2015 ás 16:46 +0100, youenn fablet escribiu: Related to the webkit contributor meeting discussion related to ports, I would find it useful if EWS bots (gtk, efl, win, ios) were running the tests that are modified/created by a patch. The idea would be to turn yellow the port bubble whenever one of these tests do not pass. Results would be uploaded to bugzilla. AFAIK, the only EWS bots running all tests are the Mac ones. It is ok to have EWS running the at least the affected tests and I guess that shouldn't take that much computation power (maybe some development to know which tests need to be run). What would be really nice is having all tests run, but for that I guess tests bots need to be green, which is a pace very difficult to maintain for smaller ports. Br. 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
