Re: [webkit-dev] Swift in WebKit
On Jul 28, 2014, at 8:44 PM, David Farler dfar...@apple.com wrote: On Jul 28, 2014, at 17:10, Ryosuke Niwa rn...@webkit.org wrote: In particular see Maciej's response in https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html. From the second e-mail: In conclusion, I think we should be very hesitant to introduce new languages for tools unless there are massive benefits that cannot be achieved with any of the languages that the WebKit project already uses.” I myself am hesitant, hence the e-mail, but I think there is more to the picture here regarding the two languages which I outline below. I think Swift is worth considering, but I think my argument in that email still holds. Any new language added increases the number of languages you have to potentially understand to work on WebKit, a number which is already quite high (C, C++, Objective-C, Objective-C++, Perl, Python, Ruby, shell scripts, probably others). I feel like there’s not a great basis for approving of Swift when I objected to Go, so for consistency’s sake I have to at least mildly object. For everyday automation tasks, I agree that we should continue to converge on Python because of its coverage across platforms, one-way-to-do-it-ness, strong style guidelines, large standard library, popularity, easy to learn, etc. It’s one of my goals to do just that and create a strong, unified, hackable, well-documented tools platform. I wouldn't advocate that automation be written in Swift. Why would this tool be an exception to the general approach of using Python for tools? Is it just because of the bindings to the CoreSimulator framework? Would ObjC be your only alternative? I have a hard time understanding the rest of your message because it’s all about comparing Objective-C to Swift, but we don’t normally use ObjC as a tools language. [snip] Fine, twist my arm. :) In comparison to Objective-C, I don’t think it’s a stretch to think of these as major achievements: - Modern type inference (although it could’ve gone a few steps further, IMO) - Static types - Sum types - Enforced optional/maybe type - Promotion of immutability - Safer usage or downright omission of pointers - Better numeric type conversion (IMO) - Enforced initialization of objects - Nice Unicode string primitives - Low resistance to reasonable functional programming patterns - Generics with constraints - Pretty fast - Terse syntax - String interpolation with expressions - No class prefixes needed Why is Objective-C the relevant point of comparison here? We don’t use much Obj-C in WebKit. It’s basically limited to the glue needed to be a public framework on OS X and iOS, and to call system APIs that are only offered in Obj-C, often mingled with C++ code. Unfortunately it’s not possible at this time to replace Obj-C with Swift for either of these uses. I do think it is possible that someday Swift will support that and that WebKit would likely make use of it. Also worth noting: anyone could make a similarly long list of bullet points for their preferred language of choice. It would be a bad precedent to accept such an argument or we’ll end up with even more different programming languages used for our tools. Cheers, Maciej ___ 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
Hi everyone, I have some updates regarding my enabling of media_stream and some new question. I managed to build the project with the following options ON: ENABLE_MEDIA_CAPTURE ENABLE_MEDIA_CONTROLS_SCRIPT ENABLE_MEDIA_SOURCE ENABLE_MEDIA_STATISTICS ENABLE_MEDIA_STREAM ENABLE_VIDEO ENABLE_VIDEO_TRACK For this I had to: 1) copy the content of these folders WebKit/WebKitBuild/Debug/DerivedSources/WebCore WebKit/WebKitBuild/Release/DerivedSources/WebCore into DerivedSources/WebCore 2) Add some header and source files to the Xcode projects. The files were present in the repo, but not added to the projects. 3) Add some headers to be copied into WebCore.framework Given those changes, I was able to build the project with both Xcode and the build script; I tried running a very basic test that only calls navigator.webkitGetUserMedia, but the call fails with the folioing error: [Error] NotSupportedError: DOM Exception 9: The implementation did not support the requested type of object or operation. I went into the code with Xcode’s debugger and found that the error happens in NavigatorUserMedia::webkitGetUserMedia (basically the function’s entrance). My understanding is that the NavigatorUserMedia is trying to get the content of a “supplement” for the key “UserMediaController The access to the supplement itself is fine, but its map only contains one object with a key value set to NULL. Therefore the supplement returns NULL, and the NavigatorUserMedia triggers an error. There are some comments in the code about how supplements work, but not what they are for. Can anyone enlighten me about this? Did I miss an initialisation somewhere? This was what is blocking me now. I also have a couple of more generic questions about the project: 1) When I build with the script and then with Xcode, Xcode starts from the beginning, generates new binaries and links against them. Why are the script and Xcode not using the same files? It feels like a waste of time and space. 2) I had to do a number of modifications to the project to get here. At some point I will send pull requests, but I understand most of the people do not want to have media_stream enabled by default. Does that mean that for each pull request, I will have to remove my changes, send the pull request and do them again?What is the right way of handling this situation? Regards, J-O H -- Haché Jacques-Olivier RD Engineer at Temasys Communications Pte Ltd Fr : 06 45 85 48 80 Sg : 9086 3673 On 23 Jul 2014, at 16:49, Alexandre GOUAILLARD agouaill...@gmail.com wrote: Hi benjamain, thanks for the answers, Cmake is not a build system in itself, it is a cross platform build generator. i.e. you can generate a make file, an VS solution file and a Xcode file from CMakeLists.txt (cmake -G). So you mean to say that the committed make files and Xcode files are not generated from CMake, is that correct? Also, do you have any insight what the people using cmake end up using for building (is it make/gcc/ld, make/clang/ld, other flavors of build/compiler/linker) ? regards, Alex. On Wed, Jul 23, 2014 at 4:24 PM, Benjamin Poulain benja...@webkit.org wrote: On 7/22/14, 12:48 AM, Jacques-Olivier wrote: HI Benjamin, Thanks for you answer. I just deleted the XCodeBuild folder and added a couple of files in the project manually. My computer is re-building the project, I will see how it goes. A couple of extra questions: 1) After deleting the XCodeBuild folder, I cannot make my first build using Xcode. I end up with a file not found on #include llvm-c/Analysis.h in JavaScriptCore/llvm/LLVMHeaders.h I actually had the same issue on my first build. After a successful build from build-webkit, I can build again using Xcode (not clean and build). Any lead regarding why? No idea, I only use build-webkit and make for building. A lot of people use Xcode so there must be a way to get it to work. 2) The Xcode projects is versioned on the repo. Is there anyway to re-generate it automatically? Having the Xcode project shared sounds very unsafe. What is someone introduces a bug in it someday? The Xcode project files are not generated, they are real project files created by Xcode. WebKit contributors maintain 3 build systems in parallel: Xcode, CMake, and VS. Regards, J-O H -- Haché Jacques-Olivier RD Engineer at Temasys Communications Pte Ltd Fr : 06 45 85 48 80 Sg : 9086 3673 On 22 Jul 2014, at 15:16, Benjamin Poulain benja...@webkit.org wrote: Quick answers inline: On 7/21/14, 9:22 PM, Jacques-Olivier wrote: Note: I already sent this email, but I didn’t get any answer, nor can I see the thread in the archives. Therefore I think it was blocked, maybe because of the attachment that I remove this time. 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
Re: [webkit-dev] Swift in WebKit
On Jul 29, 2014, at 00:14, Maciej Stachowiak m...@apple.com wrote: On Jul 28, 2014, at 8:44 PM, David Farler dfar...@apple.com wrote: On Jul 28, 2014, at 17:10, Ryosuke Niwa rn...@webkit.org wrote: In particular see Maciej's response in https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html. From the second e-mail: In conclusion, I think we should be very hesitant to introduce new languages for tools unless there are massive benefits that cannot be achieved with any of the languages that the WebKit project already uses.” I myself am hesitant, hence the e-mail, but I think there is more to the picture here regarding the two languages which I outline below. I think Swift is worth considering, but I think my argument in that email still holds. Any new language added increases the number of languages you have to potentially understand to work on WebKit, a number which is already quite high (C, C++, Objective-C, Objective-C++, Perl, Python, Ruby, shell scripts, probably others). I feel like there’s not a great basis for approving of Swift when I objected to Go, so for consistency’s sake I have to at least mildly object. For everyday automation tasks, I agree that we should continue to converge on Python because of its coverage across platforms, one-way-to-do-it-ness, strong style guidelines, large standard library, popularity, easy to learn, etc. It’s one of my goals to do just that and create a strong, unified, hackable, well-documented tools platform. I wouldn't advocate that automation be written in Swift. Why would this tool be an exception to the general approach of using Python for tools? Is it just because of the bindings to the CoreSimulator framework? Would ObjC be your only alternative? I have a hard time understanding the rest of your message because it’s all about comparing Objective-C to Swift, but we don’t normally use ObjC as a tools language. [snip] In this particular case, Obj-C is the only alternative. I originally started this effort with PyObjC and after discussing it more with the framework's author I was sufficiently convinced it wouldn't be a good idea after some technical problems. Fine, twist my arm. :) In comparison to Objective-C, I don’t think it’s a stretch to think of these as major achievements: - Modern type inference (although it could’ve gone a few steps further, IMO) - Static types - Sum types - Enforced optional/maybe type - Promotion of immutability - Safer usage or downright omission of pointers - Better numeric type conversion (IMO) - Enforced initialization of objects - Nice Unicode string primitives - Low resistance to reasonable functional programming patterns - Generics with constraints - Pretty fast - Terse syntax - String interpolation with expressions - No class prefixes needed Why is Objective-C the relevant point of comparison here? We don’t use much Obj-C in WebKit. It’s basically limited to the glue needed to be a public framework on OS X and iOS, and to call system APIs that are only offered in Obj-C, often mingled with C++ code. Unfortunately it’s not possible at this time to replace Obj-C with Swift for either of these uses. I do think it is possible that someday Swift will support that and that WebKit would likely make use of it. Also worth noting: anyone could make a similarly long list of bullet points for their preferred language of choice. It would be a bad precedent to accept such an argument or we’ll end up with even more different programming languages used for our tools. Cheers, Maciej OK. It sounds like there isn't enough interest so I will rework the patch. Thanks, David___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Updating and Enabling the CSS Font Loading Spec
Hi All, WebKit has support for an older version of the CSS Font Loading Specification [1], implemented back in 2013 [2]. I would like to bring this work in line with the current version of the specification, and enable it by default in the nightlies. The specification provides support for coordinating font loading: querying if fonts have loaded, requesting specific fonts to load, and providing notifications as fonts are loading. Other browsers have a positive outlook on the feature. Chrome has already shipped it [3], and Mozilla is in the process of implementing it [4]. Please let me know if you have any questions, comments, or concerns. -Bear [1] http://dev.w3.org/csswg/css-font-loading/ [2] https://bugs.webkit.org/show_bug.cgi?id=98395 [3] http://www.chromestatus.com/features/6244676289953792 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=835247 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updating and Enabling the CSS Font Loading Spec
On Jul 29, 2014, at 7:42 PM, Bear Travis betra...@adobe.com wrote: Hi All, WebKit has support for an older version of the CSS Font Loading Specification [1], implemented back in 2013 [2]. I would like to bring this work in line with the current version of the specification, and enable it by default in the nightlies. The specification provides support for coordinating font loading: querying if fonts have loaded, requesting specific fonts to load, and providing notifications as fonts are loading. Other browsers have a positive outlook on the feature. Chrome has already shipped it [3], and Mozilla is in the process of implementing it [4]. Do you want to implement it behind a compile time flag? IMO it is an important and great API. However, Cameron filed a lot of specifications but reports while implementing it [1]. So there might still be some issues to discover. I strongly support the implementation though. Greetings, Dirk [1] http://lists.w3.org/Archives/Public/www-style/2014Jun/ Please let me know if you have any questions, comments, or concerns. -Bear [1] http://dev.w3.org/csswg/css-font-loading/ [2] https://bugs.webkit.org/show_bug.cgi?id=98395 [3] http://www.chromestatus.com/features/6244676289953792 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=835247 ___ 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] Updating and Enabling the CSS Font Loading Spec
On 7/29/14, 11:38 AM, Dirk Schulze wrote: On Jul 29, 2014, at 7:42 PM, Bear Travis betra...@adobe.com wrote: Hi All, WebKit has support for an older version of the CSS Font Loading Specification [1], implemented back in 2013 [2]. I would like to bring this work in line with the current version of the specification, and enable it by default in the nightlies. The specification provides support for coordinating font loading: querying if fonts have loaded, requesting specific fonts to load, and providing notifications as fonts are loading. Other browsers have a positive outlook on the feature. Chrome has already shipped it [3], and Mozilla is in the process of implementing it [4]. Do you want to implement it behind a compile time flag? IMO it is an important and great API. However, Cameron filed a lot of specifications but reports while implementing it [1]. So there might still be some issues to discover. I strongly support the implementation though. +1. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updating and Enabling the CSS Font Loading Spec
On 7/29/14, 12:26 PM, Benjamin Poulain benja...@webkit.org wrote: On 7/29/14, 11:38 AM, Dirk Schulze wrote: On Jul 29, 2014, at 7:42 PM, Bear Travis betra...@adobe.com wrote: Hi All, WebKit has support for an older version of the CSS Font Loading Specification [1], implemented back in 2013 [2]. I would like to bring this work in line with the current version of the specification, and enable it by default in the nightlies. The specification provides support for coordinating font loading: querying if fonts have loaded, requesting specific fonts to load, and providing notifications as fonts are loading. Other browsers have a positive outlook on the feature. Chrome has already shipped it [3], and Mozilla is in the process of implementing it [4]. Do you want to implement it behind a compile time flag? IMO it is an important and great API. However, Cameron filed a lot of specifications but reports while implementing it [1]. So there might still be some issues to discover. I strongly support the implementation though. +1. Yep, the implementation will be behind a compile time flag (the old implementation already is). That said, I would like to have it enabled by default in dev builds and the nightlies, both to get it into users’ hands for testing and to keep the bots running the tests. -Bear ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updating and Enabling the CSS Font Loading Spec
On 7/29/14, 3:33 PM, Bear Travis wrote: On 7/29/14, 12:26 PM, Benjamin Poulain benja...@webkit.org wrote: On 7/29/14, 11:38 AM, Dirk Schulze wrote: On Jul 29, 2014, at 7:42 PM, Bear Travis betra...@adobe.com wrote: Hi All, WebKit has support for an older version of the CSS Font Loading Specification [1], implemented back in 2013 [2]. I would like to bring this work in line with the current version of the specification, and enable it by default in the nightlies. The specification provides support for coordinating font loading: querying if fonts have loaded, requesting specific fonts to load, and providing notifications as fonts are loading. Other browsers have a positive outlook on the feature. Chrome has already shipped it [3], and Mozilla is in the process of implementing it [4]. Do you want to implement it behind a compile time flag? IMO it is an important and great API. However, Cameron filed a lot of specifications but reports while implementing it [1]. So there might still be some issues to discover. I strongly support the implementation though. +1. Yep, the implementation will be behind a compile time flag (the old implementation already is). That said, I would like to have it enabled by default in dev builds and the nightlies, both to get it into users’ hands for testing and to keep the bots running the tests. That's okay. The flags are useful to disable unfinished features when shipping (until they are ready). You can enable a flag in nightly if the code is stable and has good test coverage, the feature does not need to be complete. Successful examples are CSS Grid Layout and the Picture Element. Both are work in progress, they are enabled in Nightly, but none of that code is compiled into the released WebKit. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
