Re: [webkit-dev] Sunsetting committership and reviewership
Interesting. What privileges, if any, would you propose 'emeritus reviewers' to have? -Filip On Apr 9, 2013, at 2:54 PM, Dmitry Titov dim...@chromium.org wrote: How about creating an 'emeritus reviewer' status (no r+ power) and let people *voluntarily* move themselves to this status? I bet a lot of 'inactive reviewers' would do that, since everybody understands the issue of getting out of sync with current code base. It may have different vibe though than figuring some automatic time-based enforcement system... As an added bonus, this gives such people a good way to avoid being asked to review a patch for a colleague while keeping some ties with the project... On Mon, Apr 8, 2013 at 3:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com wrote: I think 6 months is fine for deactivating SVN accounts. And a full revoke of reviewer status after 2 years of no activity sounds reasonable to me. We could make it easier to get reviewer status again after a 2 year sunset if the person becomes active again and shows good judgment still. +1 to this. I think 2 years to revoke reviewer rights is too long. All the drive-by reviews that have caused problems were from reviewers that were inactive for less than 2 years. Nevertheless, 2 years is better than the current situation so it is a good start. We sometimes get low-quality drive-by reviews even from people who are active at the time. I feel like that's not the right basis for the time cutoff. If we do have a sunset period, we should think about it in terms of how long it takes to be so out of touch with the current state of the project that there's little chance you can give a useful review. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi, As far as I'm concerned WebCL would have serious security issues as it lets web app to provide OpenCL target code (which is really unsafe), besides its using requires OpenCL knowledge and hence might be too complex for a web developer. Good alternative could be enabling parallel calculations inside ECMAScript itself. For instance providing ParallelArray interface for map-reduce calculations, there is actually a proposal already at http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism . BR, Mikhail From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Jer Noble [jer.no...@apple.com] Sent: Tuesday, April 09, 2013 11:23 PM To: Benjamin Poulain Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Apr 9, 2013, at 10:47 AM, Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org wrote: I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges… There has also been interest in the WebAudio WG about using OpenCL/WebCL for custom audio processing. There are significant performance issues involved with doing custom audio processing in JavaScript, even in a Worker thread, but WebCL may offer performance and memory characteristics which would couple well with the requirements of realtime audio threads. -Jer - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
Unrelated to Dmitry's suggestion, but since I brought up emeritus contributors earlier in the thread, I should explain my usage. The emeritus class proposed in the ancient webkit-reviewers thread about sunsetting was simply to answer the fact that committers.py has two purposes: 1. It exists as a public Access Control List (ACL) for svn.webkit.org (since I know of no other public ACL). 2. It exists as a way for our tools to lookup Contributor objects based on name, irc nick, svn email etc. emeritus contributors (in my original proposal on webkit-reviewers years ago) only exist to serve the second purpose, not the first. This would be similar to the Contributor and Account superclasses which have (since that old thread) been added to committers.py to allow committers.py to list non-commiters and even bots which we might want to have in our CC list, but not give any privileges to. Again, my thoughts on this may bear no reflection to what Dmitry had in mind with his use of the word emeritus, so I should let him speak! On Tue, Apr 9, 2013 at 11:39 PM, Filip Pizlo fpi...@apple.com wrote: Interesting. What privileges, if any, would you propose 'emeritus reviewers' to have? -Filip On Apr 9, 2013, at 2:54 PM, Dmitry Titov dim...@chromium.org wrote: How about creating an 'emeritus reviewer' status (no r+ power) and let people *voluntarily* move themselves to this status? I bet a lot of 'inactive reviewers' would do that, since everybody understands the issue of getting out of sync with current code base. It may have different vibe though than figuring some automatic time-based enforcement system... As an added bonus, this gives such people a good way to avoid being asked to review a patch for a colleague while keeping some ties with the project... On Mon, Apr 8, 2013 at 3:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com wrote: I think 6 months is fine for deactivating SVN accounts. And a full revoke of reviewer status after 2 years of no activity sounds reasonable to me. We could make it easier to get reviewer status again after a 2 year sunset if the person becomes active again and shows good judgment still. +1 to this. I think 2 years to revoke reviewer rights is too long. All the drive-by reviews that have caused problems were from reviewers that were inactive for less than 2 years. Nevertheless, 2 years is better than the current situation so it is a good start. We sometimes get low-quality drive-by reviews even from people who are active at the time. I feel like that's not the right basis for the time cutoff. If we do have a sunset period, we should think about it in terms of how long it takes to be so out of touch with the current state of the project that there's little chance you can give a useful review. 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 ___ 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] Is there a plan for supporting multi-process and WebCL in webkit
Why not infer ParallelArrays automatically? What is the specific reason for requiring a new type? -Filip On Apr 10, 2013, at 12:16 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.com wrote: Hi, As far as I'm concerned WebCL would have serious security issues as it lets web app to provide OpenCL target code (which is really unsafe), besides its using requires OpenCL knowledge and hence might be too complex for a web developer. Good alternative could be enabling parallel calculations inside ECMAScript itself. For instance providing ParallelArray interface for map-reduce calculations, there is actually a proposal already at http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism . BR, Mikhail From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Jer Noble [jer.no...@apple.com] Sent: Tuesday, April 09, 2013 11:23 PM To: Benjamin Poulain Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Apr 9, 2013, at 10:47 AM, Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org wrote: I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges… There has also been interest in the WebAudio WG about using OpenCL/WebCL for custom audio processing. There are significant performance issues involved with doing custom audio processing in JavaScript, even in a Worker thread, but WebCL may offer performance and memory characteristics which would couple well with the requirements of realtime audio threads. -Jer - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ 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] Sunsetting committership and reviewership
I don't know if this is in line with what you and Dmitry were thinking, but here's what I like about a symbolic emeritus status: it takes care of the possible drive-by review problem while also continuing to recognize the person within the project. It's symbolic, and it feels nicer than just wiping them from the system. The fact that it serves the purpose of supporting lookup (your point (2)) is good, also. -Filip On Apr 10, 2013, at 12:37 AM, Eric Seidel e...@webkit.org wrote: Unrelated to Dmitry's suggestion, but since I brought up emeritus contributors earlier in the thread, I should explain my usage. The emeritus class proposed in the ancient webkit-reviewers thread about sunsetting was simply to answer the fact that committers.py has two purposes: 1. It exists as a public Access Control List (ACL) for svn.webkit.org (since I know of no other public ACL). 2. It exists as a way for our tools to lookup Contributor objects based on name, irc nick, svn email etc. emeritus contributors (in my original proposal on webkit-reviewers years ago) only exist to serve the second purpose, not the first. This would be similar to the Contributor and Account superclasses which have (since that old thread) been added to committers.py to allow committers.py to list non-commiters and even bots which we might want to have in our CC list, but not give any privileges to. Again, my thoughts on this may bear no reflection to what Dmitry had in mind with his use of the word emeritus, so I should let him speak! On Tue, Apr 9, 2013 at 11:39 PM, Filip Pizlo fpi...@apple.com wrote: Interesting. What privileges, if any, would you propose 'emeritus reviewers' to have? -Filip On Apr 9, 2013, at 2:54 PM, Dmitry Titov dim...@chromium.org wrote: How about creating an 'emeritus reviewer' status (no r+ power) and let people *voluntarily* move themselves to this status? I bet a lot of 'inactive reviewers' would do that, since everybody understands the issue of getting out of sync with current code base. It may have different vibe though than figuring some automatic time-based enforcement system... As an added bonus, this gives such people a good way to avoid being asked to review a patch for a colleague while keeping some ties with the project... On Mon, Apr 8, 2013 at 3:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com wrote: I think 6 months is fine for deactivating SVN accounts. And a full revoke of reviewer status after 2 years of no activity sounds reasonable to me. We could make it easier to get reviewer status again after a 2 year sunset if the person becomes active again and shows good judgment still. +1 to this. I think 2 years to revoke reviewer rights is too long. All the drive-by reviews that have caused problems were from reviewers that were inactive for less than 2 years. Nevertheless, 2 years is better than the current situation so it is a good start. We sometimes get low-quality drive-by reviews even from people who are active at the time. I feel like that's not the right basis for the time cutoff. If we do have a sunset period, we should think about it in terms of how long it takes to be so out of touch with the current state of the project that there's little chance you can give a useful review. 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 ___ 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] Sunsetting committership and reviewership
If we create an emeritus class in committers.py, we also have a whole bunch of old (long-webkit-retired) Apple committers/reviewers (ken, vicki, cblu, gramps, etc.) which should go there. :) Then the tools (including validate-committer-lists) would be less confused by their presence in ChangeLogs and commit messages. On Wed, Apr 10, 2013 at 12:41 AM, Filip Pizlo fpi...@apple.com wrote: I don't know if this is in line with what you and Dmitry were thinking, but here's what I like about a symbolic emeritus status: it takes care of the possible drive-by review problem while also continuing to recognize the person within the project. It's symbolic, and it feels nicer than just wiping them from the system. The fact that it serves the purpose of supporting lookup (your point (2)) is good, also. -Filip On Apr 10, 2013, at 12:37 AM, Eric Seidel e...@webkit.org wrote: Unrelated to Dmitry's suggestion, but since I brought up emeritus contributors earlier in the thread, I should explain my usage. The emeritus class proposed in the ancient webkit-reviewers thread about sunsetting was simply to answer the fact that committers.py has two purposes: 1. It exists as a public Access Control List (ACL) for svn.webkit.org (since I know of no other public ACL). 2. It exists as a way for our tools to lookup Contributor objects based on name, irc nick, svn email etc. emeritus contributors (in my original proposal on webkit-reviewers years ago) only exist to serve the second purpose, not the first. This would be similar to the Contributor and Account superclasses which have (since that old thread) been added to committers.py to allow committers.py to list non-commiters and even bots which we might want to have in our CC list, but not give any privileges to. Again, my thoughts on this may bear no reflection to what Dmitry had in mind with his use of the word emeritus, so I should let him speak! On Tue, Apr 9, 2013 at 11:39 PM, Filip Pizlo fpi...@apple.com wrote: Interesting. What privileges, if any, would you propose 'emeritus reviewers' to have? -Filip On Apr 9, 2013, at 2:54 PM, Dmitry Titov dim...@chromium.org wrote: How about creating an 'emeritus reviewer' status (no r+ power) and let people *voluntarily* move themselves to this status? I bet a lot of 'inactive reviewers' would do that, since everybody understands the issue of getting out of sync with current code base. It may have different vibe though than figuring some automatic time-based enforcement system... As an added bonus, this gives such people a good way to avoid being asked to review a patch for a colleague while keeping some ties with the project... On Mon, Apr 8, 2013 at 3:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com wrote: I think 6 months is fine for deactivating SVN accounts. And a full revoke of reviewer status after 2 years of no activity sounds reasonable to me. We could make it easier to get reviewer status again after a 2 year sunset if the person becomes active again and shows good judgment still. +1 to this. I think 2 years to revoke reviewer rights is too long. All the drive-by reviews that have caused problems were from reviewers that were inactive for less than 2 years. Nevertheless, 2 years is better than the current situation so it is a good start. We sometimes get low-quality drive-by reviews even from people who are active at the time. I feel like that's not the right basis for the time cutoff. If we do have a sunset period, we should think about it in terms of how long it takes to be so out of touch with the current state of the project that there's little chance you can give a useful review. 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 ___ 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] Is there a plan for supporting multi-process and WebCL in webkit
Why not infer ParallelArrays automatically? Sorry, did not get it. Could you please elaborate? I'm not insisting on this concrete proposal, my point is just that it would be more safe and natural to enhance ECMAScript (enable parallel calculations there) rather than make developers to introduce OpenCL snippets to their web apps. BR, Mikhail From: Filip Pizlo [fpi...@apple.com] Sent: Wednesday, April 10, 2013 10:37 AM To: Pozdnyakov, Mikhail Cc: Jer Noble; Benjamin Poulain; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Why not infer ParallelArrays automatically? What is the specific reason for requiring a new type? -Filip On Apr 10, 2013, at 12:16 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.commailto:mikhail.pozdnya...@intel.com wrote: Hi, As far as I'm concerned WebCL would have serious security issues as it lets web app to provide OpenCL target code (which is really unsafe), besides its using requires OpenCL knowledge and hence might be too complex for a web developer. Good alternative could be enabling parallel calculations inside ECMAScript itself. For instance providing ParallelArray interface for map-reduce calculations, there is actually a proposal already at http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism . BR, Mikhail From: webkit-dev-boun...@lists.webkit.orgmailto:webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.orgmailto:webkit-dev-boun...@lists.webkit.org] on behalf of Jer Noble [jer.no...@apple.commailto:jer.no...@apple.com] Sent: Tuesday, April 09, 2013 11:23 PM To: Benjamin Poulain Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Apr 9, 2013, at 10:47 AM, Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.orgmailto:benja...@webkit.org wrote: I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges… There has also been interest in the WebAudio WG about using OpenCL/WebCL for custom audio processing. There are significant performance issues involved with doing custom audio processing in JavaScript, even in a Worker thread, but WebCL may offer performance and memory characteristics which would couple well with the requirements of realtime audio threads. -Jer - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Wed, Apr 10, 2013 at 2:29 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.com wrote: Why not infer ParallelArrays automatically? Sorry, did not get it. Could you please elaborate? I'm not insisting on this concrete proposal, my point is just that it would be more safe and natural to enhance ECMAScript (enable parallel calculations there) rather than make developers to introduce OpenCL snippets to their web apps. Filip is saying that we should be able to auto-detect scripts that are using ParallelArrays implicitly instead of adding a new type and making Web developers use it. i.e. if it quacks like a duck, then optimize it as a duck. And I completely agree with Filip on this. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Thanks for clarification. I also agree that this is better :-) BR, Mikhail From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Wednesday, April 10, 2013 12:38 PM To: Pozdnyakov, Mikhail Cc: Filip Pizlo; Benjamin Poulain; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Wed, Apr 10, 2013 at 2:29 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.commailto:mikhail.pozdnya...@intel.com wrote: Why not infer ParallelArrays automatically? Sorry, did not get it. Could you please elaborate? I'm not insisting on this concrete proposal, my point is just that it would be more safe and natural to enhance ECMAScript (enable parallel calculations there) rather than make developers to introduce OpenCL snippets to their web apps. Filip is saying that we should be able to auto-detect scripts that are using ParallelArrays implicitly instead of adding a new type and making Web developers use it. i.e. if it quacks like a duck, then optimize it as a duck. And I completely agree with Filip on this. - R. Niwa - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert timb...@adobe.com wrote: Yes, leveraging multicore and the power of GPUs for general computations is great and very powerful but first, securing such kernels is hard, and authoring these would be pretty brutal to most web developers, I think this is what Benjamin was referring to. With WebCL, you are basically writing C style kernels that you load and run to drive the computations, initiatives like RiverTrail are more restrictive but way more approachable and closer to the web, exposing higher level primitives on top of WebCL (ParallelArray for example) and integrated at the language level, which makes a lot of sense. Security is a primary goal of WebCL, and both WebCL and OpenCL working groups are working together to ensure a safe parallel programming environment to the Web, as you can see in [1]. If you have specific concerns, please raise it in the Khronos working group mailing list ([2]) or file a bug ([3]) against the draft spec. [1] https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html#4 [2] http://www.khronos.org/webcl/public-mailing-list/ [3] https://www.khronos.org/bugzilla/enter_bug.cgi?product=WebCL ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 2:29 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.com wrote: Why not infer ParallelArrays automatically? Sorry, did not get it. Could you please elaborate? Normal JS arrays. You use them with pure computation. Profiler notices this. And then the same things that you have in the ParallelArrays proposal now work except you don't need a new type. I'm not insisting on this concrete proposal, my point is just that it would be more safe and natural to enhance ECMAScript (enable parallel calculations there) rather than make developers to introduce OpenCL snippets to their web apps. It's even more natural to not add yet another array type to ECMAScript. -F BR, Mikhail From: Filip Pizlo [fpi...@apple.com] Sent: Wednesday, April 10, 2013 10:37 AM To: Pozdnyakov, Mikhail Cc: Jer Noble; Benjamin Poulain; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Why not infer ParallelArrays automatically? What is the specific reason for requiring a new type? -Filip On Apr 10, 2013, at 12:16 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.commailto:mikhail.pozdnya...@intel.com wrote: Hi, As far as I'm concerned WebCL would have serious security issues as it lets web app to provide OpenCL target code (which is really unsafe), besides its using requires OpenCL knowledge and hence might be too complex for a web developer. Good alternative could be enabling parallel calculations inside ECMAScript itself. For instance providing ParallelArray interface for map-reduce calculations, there is actually a proposal already at http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism . BR, Mikhail From: webkit-dev-boun...@lists.webkit.orgmailto:webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.orgmailto:webkit-dev-boun...@lists.webkit.org] on behalf of Jer Noble [jer.no...@apple.commailto:jer.no...@apple.com] Sent: Tuesday, April 09, 2013 11:23 PM To: Benjamin Poulain Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Apr 9, 2013, at 10:47 AM, Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.orgmailto:benja...@webkit.org wrote: I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges… There has also been interest in the WebAudio WG about using OpenCL/WebCL for custom audio processing. There are significant performance issues involved with doing custom audio processing in JavaScript, even in a Worker thread, but WebCL may offer performance and memory characteristics which would couple well with the requirements of realtime audio threads. -Jer - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes toniki...@webkit.org wrote: Hi On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert timb...@adobe.comwrote: Yes, leveraging multicore and the power of GPUs for general computations is great and very powerful but first, securing such kernels is hard, and authoring these would be pretty brutal to most web developers, I think this is what Benjamin was referring to. With WebCL, you are basically writing C style kernels that you load and run to drive the computations, initiatives like RiverTrail are more restrictive but way more approachable and closer to the web, exposing higher level primitives on top of WebCL (ParallelArray for example) and integrated at the language level, which makes a lot of sense. Security is a primary goal of WebCL, and both WebCL and OpenCL working groups are working together to ensure a safe parallel programming environment to the Web, as you can see in [1]. If you have specific concerns, please raise it in the Khronos working group mailing list ([2]) or file a bug ([3]) against the draft spec. Particularly in terms of security, WebCL is to OpenCL as WebGL is to OpenGL. Introducing OpenGL (i.e. WebGL) to the web had similar security concerns, and yet... With that said, I totally agree that using intrinsic idioms and heuristics that is more webby would be nice. But at some point there will be use cases that do not translate and will require explicit developer control in one form (WebCL) or another (new ECMAScript idioms). Detecting and optimizing all variations of homogenous parallelable operations seamlessly inside the JS engine is hard, to put it mildly. [1] https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html#4 [2] http://www.khronos.org/webcl/public-mailing-list/ [3] https://www.khronos.org/bugzilla/enter_bug.cgi?product=WebCL ___ 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] Sunsetting committership and reviewership
On Wed, Apr 10, 2013 at 1:46 AM, Eric Seidel e...@webkit.org wrote: If we create an emeritus class in committers.py, we also have a whole bunch of old (long-webkit-retired) Apple committers/reviewers (ken, vicki, cblu, gramps, etc.) which should go there. :) Then the tools (including validate-committer-lists) would be less confused by their presence in ChangeLogs and commit messages. I like this. Shouldn't be hard to add a suggest-emeriti command to webkitpy. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 9:44 AM, Jarred Nicholls jar...@webkit.org wrote: On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes toniki...@webkit.org wrote: Hi On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert timb...@adobe.com wrote: Yes, leveraging multicore and the power of GPUs for general computations is great and very powerful but first, securing such kernels is hard, and authoring these would be pretty brutal to most web developers, I think this is what Benjamin was referring to. With WebCL, you are basically writing C style kernels that you load and run to drive the computations, initiatives like RiverTrail are more restrictive but way more approachable and closer to the web, exposing higher level primitives on top of WebCL (ParallelArray for example) and integrated at the language level, which makes a lot of sense. Security is a primary goal of WebCL, and both WebCL and OpenCL working groups are working together to ensure a safe parallel programming environment to the Web, as you can see in [1]. If you have specific concerns, please raise it in the Khronos working group mailing list ([2]) or file a bug ([3]) against the draft spec. Particularly in terms of security, WebCL is to OpenCL as WebGL is to OpenGL. Introducing OpenGL (i.e. WebGL) to the web had similar security concerns, and yet… OpenCL is fundamentally less safe than OpenGL+GLSL, so it not correct to say that the security concerns are similar. There is no part of GLSL that is overtly operating on raw memory with arbitrary pointer access, whereas in OpenCL such functionality is a core primitive. I am not saying that it will be impossible to make WebCL safe (after all OpenCL can trivially be kept on the cpu, which already has the assumption that it is running untrusted code), but whether you can keep it safe without completely compromising the programming and performance model remains to be seen. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo fpi...@apple.com wrote: On Apr 10, 2013, at 2:29 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.com wrote: Why not infer ParallelArrays automatically? Sorry, did not get it. Could you please elaborate? Normal JS arrays. You use them with pure computation. Profiler notices this. And then the same things that you have in the ParallelArrays proposal now work except you don't need a new type. Compiler writers have been chasing this problem for 50 years, with (AFAIK) very limited success for languages that don't give you compile-time annotations to help you along. I'm not aware of any work on JIT compilers doing this. Why do you think we could do better? (Honest question, I'm not trying to be snarky, nor am I an expert). ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
The parallel arrays apis aren't a magic make my code parallel wand.
They don't make general code parallel, they simply provide a bunch of functions
like map, etc where if you restrict your list of language features to a
specific subset, they'll vectorise it.
For instance
ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
would be vectorised
ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
wouldn't be.
This isn't solve autovectorisation, this is we've been given a specific
operation to perform on each element of an array, parallelise it if possible,
and what's possible is arbitrarily limited, and require a distinct type that
isn't an array.
--Oliver
On Apr 10, 2013, at 12:37 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo fpi...@apple.com wrote:
On Apr 10, 2013, at 2:29 AM, Pozdnyakov, Mikhail
mikhail.pozdnya...@intel.com wrote:
Why not infer ParallelArrays automatically?
Sorry, did not get it. Could you please elaborate?
Normal JS arrays. You use them with pure computation. Profiler notices this.
And then the same things that you have in the ParallelArrays proposal now
work except you don't need a new type.
Compiler writers have been chasing this problem for 50 years, with (AFAIK)
very limited success for languages that don't give you compile-time
annotations to help you along. I'm not aware of any work on JIT compilers
doing this. Why do you think we could do better? (Honest question, I'm not
trying to be snarky, nor am I an expert).
___
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] Is there a plan for supporting multi-process and WebCL in webkit
Right, I get how ParallelArrays would work. I was asking Filip how you
might infer that an array could be a ParallelArray.
-- Dirk
On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt oli...@apple.com wrote:
The parallel arrays apis aren't a magic make my code parallel wand.
They don't make general code parallel, they simply provide a bunch of
functions like map, etc where if you restrict your list of language
features to a specific subset, they'll vectorise it.
For instance
ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
would be vectorised
ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
wouldn't be.
This isn't solve autovectorisation, this is we've been given a specific
operation to perform on each element of an array, parallelise it if
possible, and what's possible is arbitrarily limited, and require a
distinct type that isn't an array.
--Oliver
On Apr 10, 2013, at 12:37 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo fpi...@apple.com wrote:
On Apr 10, 2013, at 2:29 AM, Pozdnyakov, Mikhail
mikhail.pozdnya...@intel.com wrote:
Why not infer ParallelArrays automatically?
Sorry, did not get it. Could you please elaborate?
Normal JS arrays. You use them with pure computation. Profiler notices
this. And then the same things that you have in the ParallelArrays proposal
now work except you don't need a new type.
Compiler writers have been chasing this problem for 50 years, with (AFAIK)
very limited success for languages that don't give you compile-time
annotations to help you along. I'm not aware of any work on JIT compilers
doing this. Why do you think we could do better? (Honest question, I'm not
trying to be snarky, nor am I an expert).
___
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] Is there a plan for supporting multi-process and WebCL in webkit
I'm not sure what you mean here: a parallel array is simply an array of
numbers; there is nothing magic about it.
If we _really_ wanted to be blunt about it, we could simply say (in Array.map)
if (length = giant function.isEasyPeasy() everything in the array is a
number)
return doHardcoreMap();
// carry on doing regular map
...
Understand that the parallel APIs have to do all of this as well, the only
thing they lose is the is everything a number check
--Oliver
On Apr 10, 2013, at 12:50 PM, Dirk Pranke dpra...@chromium.org wrote:
Right, I get how ParallelArrays would work. I was asking Filip how you might
infer that an array could be a ParallelArray.
-- Dirk
On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt oli...@apple.com wrote:
The parallel arrays apis aren't a magic make my code parallel wand.
They don't make general code parallel, they simply provide a bunch of
functions like map, etc where if you restrict your list of language features
to a specific subset, they'll vectorise it.
For instance
ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
would be vectorised
ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
wouldn't be.
This isn't solve autovectorisation, this is we've been given a specific
operation to perform on each element of an array, parallelise it if
possible, and what's possible is arbitrarily limited, and require a distinct
type that isn't an array.
--Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Right, you need some way to ensure that the functions applied to the array
are pure, the array doesn't mutate, etc. I thought perhaps your
ParallelArray() type would be ensuring this (e.g., by enforcing type
checking and freezing the array), but maybe I misunderstood you? Even then,
I'm not sure how easy ensuring the functions were pure would be.
Plus there's the problem of figuring how best to parallelize the
operations, which is also often non-trivial.
-- Dirk
On Wed, Apr 10, 2013 at 12:58 PM, Oliver Hunt oli...@apple.com wrote:
I'm not sure what you mean here: a parallel array is simply an array of
numbers; there is nothing magic about it.
If we _really_ wanted to be blunt about it, we could simply say (in
Array.map)
if (length = giant function.isEasyPeasy() everything in the array
is a number)
return doHardcoreMap();
// carry on doing regular map
...
Understand that the parallel APIs have to do all of this as well, the only
thing they lose is the is everything a number check
--Oliver
On Apr 10, 2013, at 12:50 PM, Dirk Pranke dpra...@chromium.org wrote:
Right, I get how ParallelArrays would work. I was asking Filip how you
might infer that an array could be a ParallelArray.
-- Dirk
On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt oli...@apple.com wrote:
The parallel arrays apis aren't a magic make my code parallel wand.
They don't make general code parallel, they simply provide a bunch of
functions like map, etc where if you restrict your list of language
features to a specific subset, they'll vectorise it.
For instance
ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
would be vectorised
ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
wouldn't be.
This isn't solve autovectorisation, this is we've been given a
specific operation to perform on each element of an array, parallelise it
if possible, and what's possible is arbitrarily limited, and require a
distinct type that isn't an array.
--Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 12:37 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo fpi...@apple.com wrote: On Apr 10, 2013, at 2:29 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.com wrote: Why not infer ParallelArrays automatically? Sorry, did not get it. Could you please elaborate? Normal JS arrays. You use them with pure computation. Profiler notices this. And then the same things that you have in the ParallelArrays proposal now work except you don't need a new type. Compiler writers have been chasing this problem for 50 years, with (AFAIK) very limited success for languages that don't give you compile-time annotations to help you along. Lets demystify this a bit. It's easy to say OMG they did things for 50 years, and we're all guilty of saying things like this sometimes, but, it's a bit more interesting to identify what these people did for those 50 years, where they got, and what the remaining problems are. It is already possible to autoparallelize loops, but there are challenges that remain that make it impractical for real code. The problems are with: A) Identifying loops that are candidates for sound parallelization. In formal-speak they look for the lack of loop-carried side-effects, i.e. something you'd do in one iteration that would be visible in a subsequent iteration - this represents a dependency that inhibits parallelization. But if you prove that no loop-carried side-effects exist, then you're off to a good start: you know that you could fork off some threads to run the loop's body in parallel, and the program would still be guaranteed to get identical results. (I'm oversimplifying a bit - if you tried to auto-parallelize a loop in a program that already had threads, you'd be in a world of hurt from a memory model standpoint - but we don't have that problem in JS because all code in JS is semantically serial and so the parallelization you did wouldn't interfere with existing uses of threads, since there aren't any.) B) Identifying loops that are candidates for profitable parallelization. Spinning up a thread carries a fixed cost. If you find a loop with no loop-carried side-effects, but that loop actually only executes for a short time, parallelizing it will be a performance regression - and likely a steep one at that. Finding which loops are profitable to parallelize is thought to be a hard problem. The traditional attempts to solve it centered around making threads cheaper (i.e. Cilk, CML, and similar), or having stronger inference of profitability (I think this is what http://ciao-lang.org does), or pushing parallelizability hints into the language (X10, OpenMP, and these ParallelArrays). (A) is not a problem that is solved by ParallelArrays. ParallelArrays guarantee sequential equivalence; i.e. ParallelArray.prototype.forEach() will behave like Array.prototype.forEach() if the closure you pass it has the equivalent of loop-carried side-effects. I.e. if you believe that (A) is not a solvable problem, then this constitutes an argument against ParallelArrays, and not against inferring that a normal array should behave like a ParallelArray. If you can do the inference that allows ParallelArrays.prototype.forEach() to soundly parallelize, then you can do that inference for Array.prototype.forEach(), as well. I happen to think that (A) is a big problem with ParallelArrays; I don't like it that these guys are proposing a language construct called ParallelArray but then secretly they will probably not parallelize a ton of code because the user didn't realize that storing to a global variable shafts their inference for side-effects. (B) is a problem that ParallelArrays attempt to solve. But here's what we know about the different approaches to solving (B): - Making threads faster hasn't really worked. Cilk's threads are fast enough that if you use them yourself, manually, you'll be really happy, sort of, except that it sort of sometimes doesn't work like you'd expect because you've got user-level scheduling - but the point is, they're not fast enough that you could spin them up for _any_ loop in a program. You'd get a regression if you did. - Stronger inference of profitability is a promising area, which isn't adequately explored, IMO. The approaches with which I'm most familiar focus too much on static inference. - Adding hints to the language results in programming models that nobody uses. Have you ever used OpenMP? Probably not, and if you have, you probably wanted to puke all over yourself. It's a disgusting programming model. There's something offensive about writing what looks like a serial loop, and then adding decorations to it to declare to the compiler what are the set of things it could do to the loop. Eventually these declarations get so sophisticated that you realize that you made a poor life decision by using them - you
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 1:15 PM, Filip Pizlo fpi...@apple.com wrote: On Apr 10, 2013, at 12:37 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo fpi...@apple.com wrote: On Apr 10, 2013, at 2:29 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.com wrote: Why not infer ParallelArrays automatically? Sorry, did not get it. Could you please elaborate? Normal JS arrays. You use them with pure computation. Profiler notices this. And then the same things that you have in the ParallelArrays proposal now work except you don't need a new type. Compiler writers have been chasing this problem for 50 years, with (AFAIK) very limited success for languages that don't give you compile-time annotations to help you along. Lets demystify this a bit. It's easy to say OMG they did things for 50 years, and we're all guilty of saying things like this sometimes, but, it's a bit more interesting to identify what these people did for those 50 years, where they got, and what the remaining problems are. It is already possible to autoparallelize loops, but there are challenges that remain that make it impractical for real code. The problems are with: A) Identifying loops that are candidates for sound parallelization. In formal-speak they look for the lack of loop-carried side-effects, i.e. something you'd do in one iteration that would be visible in a subsequent iteration - this represents a dependency that inhibits parallelization. But if you prove that no loop-carried side-effects exist, then you're off to a good start: you know that you could fork off some threads to run the loop's body in parallel, and the program would still be guaranteed to get identical results. (I'm oversimplifying a bit - if you tried to auto-parallelize a loop in a program that already had threads, you'd be in a world of hurt from a memory model standpoint - but we don't have that problem in JS because all code in JS is semantically serial and so the parallelization you did wouldn't interfere with existing uses of threads, since there aren't any.) B) Identifying loops that are candidates for profitable parallelization. Spinning up a thread carries a fixed cost. If you find a loop with no loop-carried side-effects, but that loop actually only executes for a short time, parallelizing it will be a performance regression - and likely a steep one at that. Finding which loops are profitable to parallelize is thought to be a hard problem. The traditional attempts to solve it centered around making threads cheaper (i.e. Cilk, CML, and similar), or having stronger inference of profitability (I think this is what http://ciao-lang.org does), or pushing parallelizability hints into the language (X10, OpenMP, and these ParallelArrays). (A) is not a problem that is solved by ParallelArrays. ParallelArrays guarantee sequential equivalence; i.e. ParallelArray.prototype.forEach() will behave like Array.prototype.forEach() if the closure you pass it has the equivalent of loop-carried side-effects. Sorry, to clarify: ParallelArray.prototype.forEach() will _always_ behave identically to Array.prototype.forEach(), and it is only if the runtime/compiler separately proves that there aren't loop-carried side-effects, that you get parallelism. Otherwise you just get a slower and more bulky implementation of foreach(). I.e. if you believe that (A) is not a solvable problem, then this constitutes an argument against ParallelArrays, and not against inferring that a normal array should behave like a ParallelArray. If you can do the inference that allows ParallelArrays.prototype.forEach() to soundly parallelize, then you can do that inference for Array.prototype.forEach(), as well. I happen to think that (A) is a big problem with ParallelArrays; I don't like it that these guys are proposing a language construct called ParallelArray but then secretly they will probably not parallelize a ton of code because the user didn't realize that storing to a global variable shafts their inference for side-effects. (B) is a problem that ParallelArrays attempt to solve. But here's what we know about the different approaches to solving (B): - Making threads faster hasn't really worked. Cilk's threads are fast enough that if you use them yourself, manually, you'll be really happy, sort of, except that it sort of sometimes doesn't work like you'd expect because you've got user-level scheduling - but the point is, they're not fast enough that you could spin them up for _any_ loop in a program. You'd get a regression if you did. - Stronger inference of profitability is a promising area, which isn't adequately explored, IMO. The approaches with which I'm most familiar focus too much on static inference. - Adding hints to the language results in programming models that nobody uses. Have
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 1:03 PM, Dirk Pranke dpra...@chromium.org wrote:
Right, you need some way to ensure that the functions applied to the array
are pure, the array doesn't mutate, etc. I thought perhaps your
ParallelArray() type would be ensuring this (e.g., by enforcing type checking
and freezing the array), but maybe I misunderstood you?
Ah - this is the key thing. ParallelArray requires the runtime and compiler to:
- Ensure that the closure passed to it is pure enough to parallelize (formally,
no loop-carried side-effects). If you already have the compiler do this
analysis then we might as well do it for any call to forEach().
- You're right that in one of the versions of the ParallelArray proposal, they
make ParallelArray immutable. But this doesn't help much. We already infer
that things are immutable in JS engines. If immutability helped, then we could
just infer it automatically. It would just be another kind of array inference.
All of the major JS inference already do array inference, and
purity/immutability is a particularly simple property to infer. But I don't
actually think you really need to prove that the array doesn't *ever* change -
proving that the closure doesn't change the array in bad ways is all that is
necessary, and that is even easier to detect since it's a property of the
closure (or more broadly, the loop body) and not the array itself.
-F
Even then, I'm not sure how easy ensuring the functions were pure would be.
Plus there's the problem of figuring how best to parallelize the operations,
which is also often non-trivial.
-- Dirk
On Wed, Apr 10, 2013 at 12:58 PM, Oliver Hunt oli...@apple.com wrote:
I'm not sure what you mean here: a parallel array is simply an array of
numbers; there is nothing magic about it.
If we _really_ wanted to be blunt about it, we could simply say (in Array.map)
if (length = giant function.isEasyPeasy() everything in the array is a
number)
return doHardcoreMap();
// carry on doing regular map
...
Understand that the parallel APIs have to do all of this as well, the only
thing they lose is the is everything a number check
--Oliver
On Apr 10, 2013, at 12:50 PM, Dirk Pranke dpra...@chromium.org wrote:
Right, I get how ParallelArrays would work. I was asking Filip how you might
infer that an array could be a ParallelArray.
-- Dirk
On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt oli...@apple.com wrote:
The parallel arrays apis aren't a magic make my code parallel wand.
They don't make general code parallel, they simply provide a bunch of
functions like map, etc where if you restrict your list of language features
to a specific subset, they'll vectorise it.
For instance
ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
would be vectorised
ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
wouldn't be.
This isn't solve autovectorisation, this is we've been given a specific
operation to perform on each element of an array, parallelise it if
possible, and what's possible is arbitrarily limited, and require a
distinct type that isn't an array.
--Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding LenientThis to WebKitIDL
Dear WebKit devs,
I would like to make console.log and related functions work without
requiring that this is set to the console object. This would make
debugging from Web Inspector easier, because console.log could be
passed directly to functions that require a callback, instead of
having to pass function(arg) { console.log(arg); }
In order to make this happen, I need a static method that shows up on
the console object (or its prototype). The closest thing I could find
in WebIDL is the [LenientThis] attribute. In WebIDL it's only intended
for attributes, but I think it would be very useful for methods.
If it makes a difference, Firefox supports using console.log without
this being the console object, and this feature has been requested
on the Chromium bug tracker, so it is useful to people other than
myself.
Before I embark on a quest to learn Perl so I can change the code
generator, I would like to check if this is worthwhile. Would a patch
along these lines be considered for WebKit? Is there another
established pattern for achieving my goal? (e.g. some form of const
attribute that returns a function?)
Thank you very much for your help,
Victor
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding LenientThis to WebKitIDL
You can also write a custom binding code instead of adding a new IDL
keyword for this specific use case.
- R. Niwa
On Wed, Apr 10, 2013 at 3:02 PM, Victor Costan cos...@gmail.com wrote:
Dear WebKit devs,
I would like to make console.log and related functions work without
requiring that this is set to the console object. This would make
debugging from Web Inspector easier, because console.log could be
passed directly to functions that require a callback, instead of
having to pass function(arg) { console.log(arg); }
In order to make this happen, I need a static method that shows up on
the console object (or its prototype). The closest thing I could find
in WebIDL is the [LenientThis] attribute. In WebIDL it's only intended
for attributes, but I think it would be very useful for methods.
If it makes a difference, Firefox supports using console.log without
this being the console object, and this feature has been requested
on the Chromium bug tracker, so it is useful to people other than
myself.
Before I embark on a quest to learn Perl so I can change the code
generator, I would like to check if this is worthwhile. Would a patch
along these lines be considered for WebKit? Is there another
established pattern for achieving my goal? (e.g. some form of const
attribute that returns a function?)
Thank you very much for your help,
Victor
___
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] Adding LenientThis to WebKitIDL
Thank you for the very quick response, Ryosuke!
My main concerns with custom binding code is that I'd like to cover
the related functions in console (debug, error, info, warn, dir,
dirxml, table, trace, count), and I think something like LenientThis
can be useful for making other functions more developer-friendly in
the future.
Should I still use custom bindings? I'm pretty sure it'll make this
patch easier for me :)
Thank you very much for your advice!
Victor
On Wed, Apr 10, 2013 at 6:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
You can also write a custom binding code instead of adding a new IDL keyword
for this specific use case.
- R. Niwa
On Wed, Apr 10, 2013 at 3:02 PM, Victor Costan cos...@gmail.com wrote:
Dear WebKit devs,
I would like to make console.log and related functions work without
requiring that this is set to the console object. This would make
debugging from Web Inspector easier, because console.log could be
passed directly to functions that require a callback, instead of
having to pass function(arg) { console.log(arg); }
In order to make this happen, I need a static method that shows up on
the console object (or its prototype). The closest thing I could find
in WebIDL is the [LenientThis] attribute. In WebIDL it's only intended
for attributes, but I think it would be very useful for methods.
If it makes a difference, Firefox supports using console.log without
this being the console object, and this feature has been requested
on the Chromium bug tracker, so it is useful to people other than
myself.
Before I embark on a quest to learn Perl so I can change the code
generator, I would like to check if this is worthwhile. Would a patch
along these lines be considered for WebKit? Is there another
established pattern for achieving my goal? (e.g. some form of const
attribute that returns a function?)
Thank you very much for your help,
Victor
___
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] Adding LenientThis to WebKitIDL
On Wed, Apr 10, 2013 at 3:24 PM, Victor Costan cos...@gmail.com wrote: Thank you for the very quick response, Ryosuke! My main concerns with custom binding code is that I'd like to cover the related functions in console (debug, error, info, warn, dir, dirxml, table, trace, count), and I think something like LenientThis can be useful for making other functions more developer-friendly in the future. I see. Adding a new keyword might be a way to go then. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Hi Patrick, A few questions I have about the CMake system, being someone who's never used it before. -I would like to keep all of the unified properties settings that the VS2010 property sheets hierarchy provided. Can we still maintain that through CMake easily? -How does CMake handle different build targets. Would I have to open up different project files per configuration? -If I'm understanding things correctly the main differences with using CMake would be: 1. If a project configuration is changed run CMake / I guess whenever you update the source as well (just to be safe). We would want to change any build scripts to use CMake: perhaps build-webkit is the really the only one we have to worry about in the OpenSource tree. 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Our opensource bots run VS2005 and our internal run VS2010 currently, and seeing as we're not ready to use only VS2010 yet we would need to be able to specify which. If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. Thanks, Roger On Apr 9, 2013, at 9:34 AM, Patrick Gansterer par...@paroga.com wrote: Hi, On Mon, 08 Apr 2013 18:10:29 -0700, Mark Rowe wrote: On 2013-04-08, at 17:45, Patrick Gansterer par...@paroga.com wrote: Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Sounds good. I pushed a quick dirty example to [1], which shows a possible solution for WTF and JavaScriptCore. You can test it with the following steps. The helper directory contains then all built files. * Create a directory helper * Copy all files from Source/cmake to helper/cmake * Copy all files (including the support libraries) from WebKitLibraries to helper/WebKitLibraries * Create an independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/WTF/wtf -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * You get a WTF.zip, which should be extracted in the directory helper * Create an additional independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/JavaScriptCore -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * Yout get a JavaScriptCore.zip with the DLL I would be great if someone can verify that this solution will work for the internal builds at Apple. If I get positive feedback I'll can implement this for WebCore and WebKit too. Is there someone who will review my patches for this? Do you think it's possible to directly switch to CMake at Apple instead of upstreaming the VS2010 files? IHMO the whole work can be done in a few days, if someone at Apple is willing to work with me on it. [1] https://github.com/paroga/webkit -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Rewriting binding code generator, maybe?
Hi, Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I'm not necessarily volunteering to do the work myself at this moment but I wanted to see if there is any interest in this idea or not. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
I know some folks in our TOK office have expressed strong interest in re-writing it in python for Blink. Perhaps there is an opportunity for some x-project collaboration here. On Wed, Apr 10, 2013 at 3:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I'm not necessarily volunteering to do the work myself at this moment but I wanted to see if there is any interest in this idea or not. - R. Niwa ___ 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] Buildsystem cleanup
Hi everyone: Sent from my iPhone On Apr 10, 2013, at 3:30 PM, Roger Fong roger_f...@apple.com wrote: 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. I think the enable/disable stuff we use for conditionally building WinCairo versus stock Apple would go away; ale generates project files with only the relevant items per build. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Yes, it's -G It allows choices between Xcode, Visual Studio 2006, VS2012, etc. ... move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. I can help with this now. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. Agreed! Patrick, can you expound a little on the abilities cmake apparently has for performing shell operations? I think you suggested at one point that some of the. Things we currently do with BASH and DOS shell scripts could be done by cmake. Can you elaborate on what kind of things? - Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
On Wed, Apr 10, 2013 at 3:30 PM, Roger Fong roger_f...@apple.com wrote: If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. We're going to try it out for WebKitGTK+ and that really just leaves QtWebKit on qmake [1]. Perhaps someday WebKit will only have two build systems. :) 1. There's also the Wx port, but they don't seem very interested in switching and it seems the build system is very low maintenance. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Somewhat painful AppEngine transitions coming
Hi, I've started moving Google owned http://test-results.appspot.com and http://webkit-commit-queue.appspot.com to Apple owned http://webkit-test-results.appspot.com and http://webkit-queues.appspot.comrespectively. Ojan and I have already moved the flakiness dashboard to http://webkit-test-results.appspot.com so builders on build.webkit.org have started uploading results there. Unfortunately, the historical results are still on http://test-results.appspot.com so we probably need to use both websites for the next couple of weeks. Moving http://webkit-commit-queue.appspot.com is a little tricker because it involves moving off EWS bots as well. My current plan is to modify Bugzilla so that it'll show two sets of bubbles for both websites during the transition. I expect this transition to be somewhat painful and you may feel cause a great disturbance in the force. I'll do my best to minimize the damage. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
I know some folks in our TOK office have expressed strong interest in re-writing it in python for Blink. Yeah, I'm planning (but in low priority) to rewrite it in Python after cleaning up IDLs and code generators. The difficulty is that CodeGenerator*.pm are not the only target for rewriting. We also have to rewrite IDLParser.pm (2500 lines) and all other related Perl scripts at a breath. Although we can proceed with the work incrementally by defining intermediate data structure between Python and Perl, it will anyway be a huge amount of work. On Thu, Apr 11, 2013 at 7:36 AM, Eric Seidel e...@webkit.org wrote: I know some folks in our TOK office have expressed strong interest in re-writing it in python for Blink. Perhaps there is an opportunity for some x-project collaboration here. On Wed, Apr 10, 2013 at 3:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I'm not necessarily volunteering to do the work myself at this moment but I wanted to see if there is any interest in this idea or not. - R. Niwa ___ 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 -- Kentaro Hara, Tokyo, Japan 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] Adding LenientThis to WebKitIDL
On Apr 10, 2013, at 3:02 PM, Victor Costan cos...@gmail.com wrote:
Dear WebKit devs,
I would like to make console.log and related functions work without
requiring that this is set to the console object. This would make
debugging from Web Inspector easier, because console.log could be
passed directly to functions that require a callback, instead of
having to pass function(arg) { console.log(arg); }
You can also use Function.bind for this purpose - is that to verbose?
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding LenientThis to WebKitIDL
this is kind of what 'bind' is for, no?
it's a little wordy, but you can just pass:
console.log.bind(console)
instead of the closure.
its been around quite a while:
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Function/bind
personally as a web dev, it would frustrate me if console.log (or any other
api) behaved differently in webkit than in other engine.
Alec
On Wed, Apr 10, 2013 at 3:02 PM, Victor Costan cos...@gmail.com wrote:
Dear WebKit devs,
I would like to make console.log and related functions work without
requiring that this is set to the console object. This would make
debugging from Web Inspector easier, because console.log could be
passed directly to functions that require a callback, instead of
having to pass function(arg) { console.log(arg); }
In order to make this happen, I need a static method that shows up on
the console object (or its prototype). The closest thing I could find
in WebIDL is the [LenientThis] attribute. In WebIDL it's only intended
for attributes, but I think it would be very useful for methods.
If it makes a difference, Firefox supports using console.log without
this being the console object, and this feature has been requested
on the Chromium bug tracker, so it is useful to people other than
myself.
Before I embark on a quest to learn Perl so I can change the code
generator, I would like to check if this is worthwhile. Would a patch
along these lines be considered for WebKit? Is there another
established pattern for achieving my goal? (e.g. some form of const
attribute that returns a function?)
Thank you very much for your help,
Victor
___
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] Rewriting binding code generator, maybe?
On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. They can't be merged. We also have CodeGeneratorObjC.pm. (And internally we have CodeGeneratorSafari.pm.) I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I've also seen people express their frustration for our tools currently written in Ruby and Python. I personally find Perl fine for this task and don't see a need to rewrite things just because. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
As a person who does not know any of Perl, Python or Ruby very well, I find unfamiliar Python the easiest to understand (even though I have more experience with Perl). I feel this would be worthwhile, if not necessarily a top priority. I do hope that this could be done without undue increase in verbosity. - Maciej On Apr 10, 2013, at 3:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I'm not necessarily volunteering to do the work myself at this moment but I wanted to see if there is any interest in this idea or not. - R. Niwa ___ 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] Rewriting binding code generator, maybe?
On Wed, Apr 10, 2013 at 4:59 PM, Timothy Hatcher timo...@apple.com wrote: On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. They can't be merged. We also have CodeGeneratorObjC.pm. (And internally we have CodeGeneratorSafari.pm.) I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I've also seen people express their frustration for our tools currently written in Ruby and Python. I personally find Perl fine for this task and don't see a need to rewrite things just because. I'm sure Perl is a fine tool for the job, if you happen to know Perl, but Perl code is generally much less approachable than Ruby, and Ruby less so than Python. Of course many if not most of the Python zealots have gone elsewhere :). I believe in Blink-land there may be a reasonably concerted effort to move the stuff Chromium still uses to Python where possible, and obviously this is one such case (as Eric alludes to earlier), so it does seem like it would be nice to be able share the code and make the rewrite generic if it wasn't too much additional work, there was interest in doing so, and the rewrite was gonna happen anyway. Otherwise I'm quite sympathetic to the ain't broke argument here :) -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Somewhat painful AppEngine transitions coming
On Wed, Apr 10, 2013 at 4:20 PM, Ryosuke Niwa rn...@webkit.org wrote: Moving http://webkit-commit-queue.appspot.com is a little tricker because it involves moving off EWS bots as well. My current plan is to modify Bugzilla so that it'll show two sets of bubbles for both websites during the transition. I've done this. Now you see two set of bubbles on each patch. The first set (with opacity: 0.3) is from webkit-commit-queue.appspot.com, which is going to be turned off. The second set of bubbles is for webkit-queues.appspot.com . - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
I've seen many people expressing their inability to improve the binding code because of its being written in Perl. Although I agree that the complexity of the binding code partly comes from the fact that it's written in Perl, another big reason is that current code generators are more complicated than necessary. Now that JSC is the only engine in WebKit and V8 is the only engine in V8, we both can remove a bunch of unnecessary abstractions and IDL attributes that had existed to share code between JSC and V8. In short-term, this kind of clean-up will improve our situation a lot. (I'm doing the work with the highest priority in the V8 side.) On Thu, Apr 11, 2013 at 9:08 AM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Apr 10, 2013 at 4:59 PM, Timothy Hatcher timo...@apple.comwrote: On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. They can't be merged. We also have CodeGeneratorObjC.pm. (And internally we have CodeGeneratorSafari.pm.) I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I've also seen people express their frustration for our tools currently written in Ruby and Python. I personally find Perl fine for this task and don't see a need to rewrite things just because. I'm sure Perl is a fine tool for the job, if you happen to know Perl, but Perl code is generally much less approachable than Ruby, and Ruby less so than Python. Of course many if not most of the Python zealots have gone elsewhere :). I believe in Blink-land there may be a reasonably concerted effort to move the stuff Chromium still uses to Python where possible, and obviously this is one such case (as Eric alludes to earlier), so it does seem like it would be nice to be able share the code and make the rewrite generic if it wasn't too much additional work, there was interest in doing so, and the rewrite was gonna happen anyway. Otherwise I'm quite sympathetic to the ain't broke argument here :) -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Kentaro Hara, Tokyo, Japan 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] Somewhat painful AppEngine transitions coming
Unfortunately, EWS is going to have to re-process all 300+ patches that are currently up for review again as there is no easy way for the status server or EWS bots to retrieve the information from the old status server. Please obsolete patches and close bugs as much as we can to reduce the work load so that EWS can catch up sooner. - R. Niwa - R. Niwa On Wed, Apr 10, 2013 at 5:14 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Apr 10, 2013 at 4:20 PM, Ryosuke Niwa rn...@webkit.org wrote: Moving http://webkit-commit-queue.appspot.com is a little tricker because it involves moving off EWS bots as well. My current plan is to modify Bugzilla so that it'll show two sets of bubbles for both websites during the transition. I've done this. Now you see two set of bubbles on each patch. The first set (with opacity: 0.3) is from webkit-commit-queue.appspot.com, which is going to be turned off. The second set of bubbles is for webkit-queues.appspot.com. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
On Apr 10, 2013, at 8:17 PM, Kentaro Hara hara...@chromium.org wrote: Now that JSC is the only engine in WebKit and V8 is the only engine in V8, we both can remove a bunch of unnecessary abstractions and IDL attributes that had existed to share code between JSC and V8. In short-term, this kind of clean-up will improve our situation a lot. (I'm doing the work with the highest priority in the V8 side.) As I said in a previous email, JSC isn't the only binding we generate with these scripts. We also generate ObjC and internal Safari bindings. So those needs need to be considered for anyone rewriting these scripts. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
If a rewrite does happen, it would be nice to have some generic functionality abstracted away from the specific language generators. For example, the function to add an #include statement to the generated implementation file is currently replicated for every language. JS and V8 have AddToImplIncludes, while CPP and ObjC have AddIncludesForType. I personally copy+pasted a lot of code from CPP and JS for the Ruby code generator, and it would be nice if some of that was more generic. -Tim On Apr 10, 2013, at 6:03 PM, Timothy Hatcher timo...@apple.com wrote: On Apr 10, 2013, at 8:17 PM, Kentaro Hara hara...@chromium.org wrote: Now that JSC is the only engine in WebKit and V8 is the only engine in V8, we both can remove a bunch of unnecessary abstractions and IDL attributes that had existed to share code between JSC and V8. In short-term, this kind of clean-up will improve our situation a lot. (I'm doing the work with the highest priority in the V8 side.) As I said in a previous email, JSC isn't the only binding we generate with these scripts. We also generate ObjC and internal Safari bindings. So those needs need to be considered for anyone rewriting these scripts. — Timothy Hatcher ___ 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] Somewhat painful AppEngine transitions coming
Alan has offered us a help to migrate the status data from the old server so I'm going to temporarily move EWS back to the old server until that's done. Sorry for the noise and thank you for your patience. - R. Niwa On Wed, Apr 10, 2013 at 6:02 PM, Ryosuke Niwa rn...@webkit.org wrote: Unfortunately, EWS is going to have to re-process all 300+ patches that are currently up for review again as there is no easy way for the status server or EWS bots to retrieve the information from the old status server. Please obsolete patches and close bugs as much as we can to reduce the work load so that EWS can catch up sooner. - R. Niwa On Wed, Apr 10, 2013 at 5:14 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Apr 10, 2013 at 4:20 PM, Ryosuke Niwa rn...@webkit.org wrote: Moving http://webkit-commit-queue.appspot.com is a little tricker because it involves moving off EWS bots as well. My current plan is to modify Bugzilla so that it'll show two sets of bubbles for both websites during the transition. I've done this. Now you see two set of bubbles on each patch. The first set (with opacity: 0.3) is from webkit-commit-queue.appspot.com, which is going to be turned off. The second set of bubbles is for webkit-queues.appspot.com. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Am 11.04.2013 um 00:30 schrieb Roger Fong: Hi Patrick, A few questions I have about the CMake system, being someone who's never used it before. -I would like to keep all of the unified properties settings that the VS2010 property sheets hierarchy provided. Can we still maintain that through CMake easily? The main idea in CMake is, that it does not know anything about Visual Studio sheets. This is required to use other generators as well (e.g. a -G Ninja). What you usually do with VS property sheets is done with CMake variables, where you store your compiler, linker or whatever flags. -How does CMake handle different build targets. Would I have to open up different project files per configuration? In the default configuration CMake has 4 configurations: Debug, Release, MinSizeRelease and RelWithDebInfo. This allows in 99% direct production builds out of Visual Studio. Makefile generators (including Ninja) do not have this configuration and instead expect a -DCMAKE_BUILD_TYPE=config when running CMake. If you need additional configurations (e.g. the current Production configs) the CMake-way is to do this with an additional CMake variable defined via command line. So if you want a production build you just add a -DBUILD_FOR_PRODUCTION=ON to the initial call to cmake. Then you can do stuff like if (BUILDFOR_PRODUCTION) list(APPEND LINNKER_FLAGS ...) endif () to get the job done. -If I'm understanding things correctly the main differences with using CMake would be: 1. If a project configuration is changed run CMake / I guess whenever you update the source as well (just to be safe). We would want to change any build scripts to use CMake: perhaps build-webkit is the really the only one we have to worry about in the OpenSource tree. Importent is that you do not change the VS files any more. Only the CMake files should be changed then. CMake adds an additional project into the Visual Studio solution (ZERO_CHECK), which detects modified CMake files and runs cmake if something has changed. Since adding/removing a source files results in a change of the CMake file everything is done automatically. build-wekit has already support for CMake, so you only need to remove the VS code. :-) 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. You can do this in VS as well: You only need to open the CMakeLists.txt in Visual Studio and add i there. Pressing the build button then generates new VS project, as mentioned before. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Our opensource bots run VS2005 and our internal run VS2010 currently, and seeing as we're not ready to use only VS2010 yet we would need to be able to specify which. -G does the job. You can also use Makefile based generators with no extra work. IMHO it would be great to use -G Ninja an the buildbots, since it has a much better output when you only see the command line (and it's faster). If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. Many thanks. Please let me know if you see additional problems so we can address them as soon as possible. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Please let me know when I can help somewhere. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. IMHO we can enforce new ports to use CMake already. Does anybody know if it's possible for the Qt port to switch to CMake? I know that QtWebKit is part of the Qt source distribution, which does not require CMake. Maybe somebody can tell me if the following would work for Qt: Use the CMake builds as e.g. EFL does at the moment and add an additional target for auto-generation of the qmake files. This qmake files then only have a list of header and source files, since code-generators (e.g. for IDL) are run by CMake. Am 11.04.2013 um 00:39 schrieb Brent Fulgham: On Apr 10, 2013, at 3:30 PM, Roger Fong roger_f...@apple.com wrote: 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we
Re: [webkit-dev] Buildsystem cleanup
Hi Patrick, On Apr 10, 2013, at 8:12 PM, Patrick Gansterer wrote: [snip] 1. There's also the Wx port, but they don't seem very interested in switching and it seems the build system is very low maintenance. There is still a patch at webkit.org/b/73100 for adding CMake files for Wx. The decision has already been made to remove wx from the tree (I need to whip up a patch when I have time…), so it probably isn't worth spending time on this. Regards, Kevin -- Patrick ___ 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
