Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
On Sun, Feb 3, 2013 at 7:29 AM, Benjamin Poulain benja...@webkit.orgwrote: On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel e...@webkit.org wrote: What I've learned from this thread, is that AppleWin and AppleMac are the only two ports which require lists of exported symbols. If both were to convert to using EXPORT decorators instead, then we could remove needs for fixing export lists. Please correct me if I've misunderstood. There is also iOS. The export file contains both Mac and iOS, they do not export the same symbols. There is unfortunately a need to have different exports for per platform; the syntax will probably have to account for that. Just to clarify: there's code that is used on e.g. Mac but not iOS, but it's still compiled into the iOS port (i.e. not disabled by some feature macro anyway)? best -jochen Benjamin ___ 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] Throwing SECURITY_ERR on cross-origin window.location property accesses (revisited).
Way back in the depths of 2010, Mihai suggested that we begin to throw exceptions when accessing Location properties across origins[1]. Currently, we log a Unsafe JavaScript attempt to access... message to the console, and return null. Hit http://talkingpointsmemo.com/ with the console open for an example of how this can get out of hand. At the moment, IE, Firefox, and Opera all throw an exception here, and the spec agrees with this behavior[2]. Given this bifurcation, developers are generally forced to have two paths for code that touches Location: one for WebKit, one for everyone else. They're generally not able to avoid the error message (though `ancestorOrigins` should now address some of the use case), which is a bit annoying. Anecdotally, I see this message quite often when browsing around with the console open in Canary, and practically never when doing the same in Firefox. This is something I'd like to address. I've resurrected the JSC side of Mihai's old patch[3], where this was discussed some more. Before getting too far along with that, however: Maciej, Sam, others, WDYT? [1]: https://lists.webkit.org/pipermail/webkit-dev/2010-August/013880.html [2]: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location [3]: https://bugs.webkit.org/show_bug.cgi?id=43891 -mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses (revisited).
Given the consistency of other user agents, this looks like the right thing to do for the web. We should try it in Canary to see if it's compatible with the web. Adam On Feb 4, 2013 5:05 AM, Mike West mk...@chromium.org wrote: Way back in the depths of 2010, Mihai suggested that we begin to throw exceptions when accessing Location properties across origins[1]. Currently, we log a Unsafe JavaScript attempt to access... message to the console, and return null. Hit http://talkingpointsmemo.com/ with the console open for an example of how this can get out of hand. At the moment, IE, Firefox, and Opera all throw an exception here, and the spec agrees with this behavior[2]. Given this bifurcation, developers are generally forced to have two paths for code that touches Location: one for WebKit, one for everyone else. They're generally not able to avoid the error message (though `ancestorOrigins` should now address some of the use case), which is a bit annoying. Anecdotally, I see this message quite often when browsing around with the console open in Canary, and practically never when doing the same in Firefox. This is something I'd like to address. I've resurrected the JSC side of Mihai's old patch[3], where this was discussed some more. Before getting too far along with that, however: Maciej, Sam, others, WDYT? [1]: https://lists.webkit.org/pipermail/webkit-dev/2010-August/013880.html [2]: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location [3]: https://bugs.webkit.org/show_bug.cgi?id=43891 -mike ___ 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] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
On Feb 4, 2013, at 12:17 AM, Jochen Eisinger joc...@chromium.org wrote: On Sun, Feb 3, 2013 at 7:29 AM, Benjamin Poulain benja...@webkit.org wrote: On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel e...@webkit.org wrote: What I've learned from this thread, is that AppleWin and AppleMac are the only two ports which require lists of exported symbols. If both were to convert to using EXPORT decorators instead, then we could remove needs for fixing export lists. Please correct me if I've misunderstood. There is also iOS. The export file contains both Mac and iOS, they do not export the same symbols. There is unfortunately a need to have different exports for per platform; the syntax will probably have to account for that. Just to clarify: there's code that is used on e.g. Mac but not iOS, but it's still compiled into the iOS port (i.e. not disabled by some feature macro anyway)? The WebKit layers aren't identical and may need different WebCore exports, but it's probably ok (not totally sure) to export every actually existing symbol that needs to be exported on either platform. WebCore is a private subframework anyway so keeping its exports clean is not super important. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses (revisited).
On Feb 4, 2013, at 5:04 AM, Mike West mk...@chromium.org wrote: Way back in the depths of 2010, Mihai suggested that we begin to throw exceptions when accessing Location properties across origins[1]. Currently, we log a Unsafe JavaScript attempt to access... message to the console, and return null. Hit http://talkingpointsmemo.com/ with the console open for an example of how this can get out of hand. At the moment, IE, Firefox, and Opera all throw an exception here, and the spec agrees with this behavior[2]. Given this bifurcation, developers are generally forced to have two paths for code that touches Location: one for WebKit, one for everyone else. They're generally not able to avoid the error message (though `ancestorOrigins` should now address some of the use case), which is a bit annoying. If Web developers legitimately have a reason to touch Location properties without knowing if it's allowed, then the exception approach seems better. Also better to align with other UAs. - Maciej Anecdotally, I see this message quite often when browsing around with the console open in Canary, and practically never when doing the same in Firefox. This is something I'd like to address. I've resurrected the JSC side of Mihai's old patch[3], where this was discussed some more. Before getting too far along with that, however: Maciej, Sam, others, WDYT? [1]: https://lists.webkit.org/pipermail/webkit-dev/2010-August/013880.html [2]: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location [3]: https://bugs.webkit.org/show_bug.cgi?id=43891 -mike ___ 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] Common build system (was Re: WebKit Wishes)
GYP was written in Python to address point (b). Python was already part of the baseline requirements on all platforms, so we already had Python available everywhere we needed it. There are no dependencies on external binaries, and no compiled code needs to be checked in anywhere or maintained as part of a base image. As for point (a), you can easily have a top-level Makefile not generated by GYP that says “run GYP to produce the build files for whatever environment you like and then pass control to that build system to do the rest of the build. Developers who like it can use ninja for their own builds, and your bots can use Xcode or make if that’s a requirement (or if ninja doesn’t meet your requirements given point (b)). I’d be happy to discuss this further with anyone who’s interested in moving in this direction. On Mon, Feb 4, 2013 at 12:20 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 3, 2013, at 8:18 PM, Mike Lawther mikelawt...@chromium.org wrote: Hi Maciej! On 31 January 2013 11:15, Maciej Stachowiak m...@apple.com wrote: It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. For b), does 'default' include an Xcode install? From my memory of setting up a Mac dev box Xcode was needed to compile. The limitation in (a) is all about how the build fleet is managed, and yes, the machines in question have the Mac OS X user install as well as developer tools installed, and it is ok to rely on that. To clarify: the things that are not kosher are submitting a binary tool as part of the module, downloading things as part of the build, or relying on something to be installed out of band before building. It is ok for the build to rely on scripts, so long as the relevant interpreter is part of the default install. Any such script would have to be in each directory under Source/ since these build separately without access to the source of the others. I should mention that there's a lot of interest right now at Apple in the possibility of switching to Gyp. We think it's likely closer to what we need than CMake, and we suspect there is probably somewhat better probability of modifying it if necessary. If we find someone at Apple who is able to work on such a project in the short term (not completely impossible), would any Google folks be interested in collaborating? Ideally we could use assistance from someone who (a) understands how the Chromium WebKit Gyp-based build works; and (b) is willing and able to change Gyp if necessary. Regards, Maciej mike On 31 January 2013 11:15, Maciej Stachowiak m...@apple.com wrote: On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I think we can solve this problem if we agree that we want to. I think we haven't in the past mostly because we couldn't reach a consensus that it was worth solving enough to really try. I would love to see this fixed and would be glad to work on it. I think we should at least pursue this far enough to fully understand what our options are and what the costs and tradeoffs might be; does anyone disagree, and is anyone else willing to help pitch in? I think there are several possible ways we could solve this. One would be to switch to a common meta-build system. My understanding is that Apple's internal production build processes impose certain constraints here that I don't fully understand, but I know we've discussed the possibility of checking in generated project files as a workaround. Maybe there are other options as well to those constraints? I would love to discuss this further w/ someone from Apple ... It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b)
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Feb 4, 2013, at 10:46 AM, Mark Mentovai m...@chromium.org wrote: GYP was written in Python to address point (b). Python was already part of the baseline requirements on all platforms, so we already had Python available everywhere we needed it. There are no dependencies on external binaries, and no compiled code needs to be checked in anywhere or maintained as part of a base image. As for point (a), you can easily have a top-level Makefile not generated by GYP that says “run GYP to produce the build files for whatever environment you like and then pass control to that build system to do the rest of the build. Developers who like it can use ninja for their own builds, and your bots can use Xcode or make if that’s a requirement (or if ninja doesn’t meet your requirements given point (b)). Checking in the generated Xcode projects is another alternative. The Makefile might be better for the reasons you suggest, though. I'm reasonably confident at this point that Gyp can meet our hard requirements. Our remaining issues are finding time to do it and comprehensibility/readability of the syntax. I’d be happy to discuss this further with anyone who’s interested in moving in this direction. That would be much appreciated. I'll ping you once we have somebody to work on this. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On 2013-02-04, at 10:57, Maciej Stachowiak m...@apple.com wrote: On Feb 4, 2013, at 10:46 AM, Mark Mentovai m...@chromium.org wrote: GYP was written in Python to address point (b). Python was already part of the baseline requirements on all platforms, so we already had Python available everywhere we needed it. There are no dependencies on external binaries, and no compiled code needs to be checked in anywhere or maintained as part of a base image. As for point (a), you can easily have a top-level Makefile not generated by GYP that says “run GYP to produce the build files for whatever environment you like and then pass control to that build system to do the rest of the build. Developers who like it can use ninja for their own builds, and your bots can use Xcode or make if that’s a requirement (or if ninja doesn’t meet your requirements given point (b)). Checking in the generated Xcode projects is another alternative. The Makefile might be better for the reasons you suggest, though. It’s not immediately obvious to me that a Makefile that ran GYP would be suitable for our production builds. I think it would be materially the same as building with something other than Xcode, in that it would limit the integration with the rest of the Apple build infrastructure. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Sun, Feb 3, 2013 at 9:20 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 3, 2013, at 8:18 PM, Mike Lawther mikelawt...@chromium.org wrote: Hi Maciej! On 31 January 2013 11:15, Maciej Stachowiak m...@apple.com wrote: It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. For b), does 'default' include an Xcode install? From my memory of setting up a Mac dev box Xcode was needed to compile. The limitation in (a) is all about how the build fleet is managed, and yes, the machines in question have the Mac OS X user install as well as developer tools installed, and it is ok to rely on that. To clarify: the things that are not kosher are submitting a binary tool as part of the module, downloading things as part of the build, or relying on something to be installed out of band before building. It is ok for the build to rely on scripts, so long as the relevant interpreter is part of the default install. Any such script would have to be in each directory under Source/ since these build separately without access to the source of the others. I should mention that there's a lot of interest right now at Apple in the possibility of switching to Gyp. We think it's likely closer to what we need than CMake, and we suspect there is probably somewhat better probability of modifying it if necessary. If we find someone at Apple who is able to work on such a project in the short term (not completely impossible), would any Google folks be interested in collaborating? Ideally we could use assistance from someone who (a) understands how the Chromium WebKit Gyp-based build works; and (b) is willing and able to change Gyp if necessary. Mark is the gyp-guru, but I would be happy to help out as well. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Using ninja (was Re:Common build system (was Re: WebKit Wishes))
The short answer is, you can't. The fastest path is probably to get a working set of gyp files for the apple mac wk2. I'm going to start working on this just to see how far of we are (Adam's work from a year or two ago had JSC and WebCore building, but wasn't too functional beyond that; even so, it's probably a good starting point). -- Dirk On Sun, Feb 3, 2013 at 1:22 PM, Dean Jackson d...@apple.com wrote: OK, this sounds fantastic. And I've noticed how much faster Chromium incrementally builds using ninja when I've done that. So, ignoring the discussion of a single build system for a moment, how can I, as a developer using the OS X + WK2 port, living mostly in Xcode for editing and debugging, use ninja? I need the idiot's guide :) (Note: I am an idiot, but not so much an idiot to realise that the answer involves lots of work and probably updating some old GYP files that you and Adam were testing with, etc etc. I'm just selfishly thinking that cutting even 30s off each incremental rebuild would make me so much happier that I'd be willing to put up with other inconveniences.) Dean On 03/02/2013, at 4:54 PM, Eric Seidel e...@webkit.org wrote: +1 Ninja is beyond-words amazing. http://martine.github.com/ninja/ For better or worse, it is not designed to use human-editable build files, but rather to be used by a meta build system, like GYP or CMake. So using ninja is really an orthogonal discussion to the single build system discussion for WebKit. :) Were the WebKit project to convert to using a single meta-build system, ninja would become an option many users might choose. I'm told most Chromium hackers have GYP set to output ninja files these days, with the exception of some folks who still want the MSVC build environment. For WebKit ports already using CMake, they should definitely try ninja today! Anyway, my wish was not about arguing for a specific build solution. I'm instead noting that for the project to continue to move quickly, we need to stop needing to edit 8 build systems for every file move/addition. Whether that's GYP or CMake or something else, I don't really care. Adam and I tried GYP-for-WebKIt a while back. But any of these solutions will require buy-in from Apple, as they will have to do the largest amount of work converting to use something other than XCode. On Sat, Feb 2, 2013 at 8:20 PM, Nico Weber tha...@chromium.org wrote: On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth aba...@webkit.org wrote: Ninja has extremely fast incremental builds and can be generated by GYP. Here are some stats from a year ago: https://plus.google.com/101038813433650812235/posts/irc26fhRtPC Ninja has gotten even faster since then. If you're interested in trying it out, you can play around with incremental builds of the Chromium port on Mac or Linux. You can also look at the build output from the chromium bots. Empty build in 1s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio Build with a few files changed in 15s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio …and this is on fairly slow bots. On my SSD-equipped laptop, I can do incremental rebuilds of all of chrome after touching one (cpp or mm) file in 2-6s. ___ 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] SerializedScriptValue: signed vs unsigned char
At the moment, SerializedScriptValue uses Vectoruint8_t (aka Vectorunsigned char) for both it's API (createFromWireBytes, toWireBytes) as well as its internal representation. (for both v8 and jsc implementations) The two largest consumers of this aspect of SerializedScriptValue seems to be IndexedDB and postMessage(). I'm jumping through some small hoops (i.e. reinterpret_cast and whatnot) in IndexedDB to convert between Vectoruint8_t and Vectorchar and a 'const char*' buffer in order to write out to LevelDB, who likes 'char' as opposed to unsigned char. postMessage() seems to be pretty agnostic to char vs unsigned char, since it uses SerializedScriptValue to both produce and consume the buffers it sends between windows. Before I did a code cleanup and just fixed up all the implementations to use Vectorchar I wanted to see if anyone had any objections here, on both the V8 and the JSC sides. The ultimate compiled code is going to be identical, but I'll be able to avoid all sorts of reinterpret_cast's at various points in the code. objections? Alec ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Using ninja (was Re:Common build system (was Re: WebKit Wishes))
Editing seems OK if we use GYP or CMake. You can generate both Xcode and Ninja files against same source tree. Debugging won't work though, at least for GYP-generated projects. Its Ninja and Xcode builds have different directly structure. If Xcode can attach gdb/llldb to an out-of-project executable for debugging, it might work. The dwarf debug metadata points the same source code after all. But I have no idea whether it is possible. -- morrita On Tue, Feb 5, 2013 at 5:25 AM, Dirk Pranke dpra...@chromium.org wrote: The short answer is, you can't. The fastest path is probably to get a working set of gyp files for the apple mac wk2. I'm going to start working on this just to see how far of we are (Adam's work from a year or two ago had JSC and WebCore building, but wasn't too functional beyond that; even so, it's probably a good starting point). -- Dirk On Sun, Feb 3, 2013 at 1:22 PM, Dean Jackson d...@apple.com wrote: OK, this sounds fantastic. And I've noticed how much faster Chromium incrementally builds using ninja when I've done that. So, ignoring the discussion of a single build system for a moment, how can I, as a developer using the OS X + WK2 port, living mostly in Xcode for editing and debugging, use ninja? I need the idiot's guide :) (Note: I am an idiot, but not so much an idiot to realise that the answer involves lots of work and probably updating some old GYP files that you and Adam were testing with, etc etc. I'm just selfishly thinking that cutting even 30s off each incremental rebuild would make me so much happier that I'd be willing to put up with other inconveniences.) Dean On 03/02/2013, at 4:54 PM, Eric Seidel e...@webkit.org wrote: +1 Ninja is beyond-words amazing. http://martine.github.com/ninja/ For better or worse, it is not designed to use human-editable build files, but rather to be used by a meta build system, like GYP or CMake. So using ninja is really an orthogonal discussion to the single build system discussion for WebKit. :) Were the WebKit project to convert to using a single meta-build system, ninja would become an option many users might choose. I'm told most Chromium hackers have GYP set to output ninja files these days, with the exception of some folks who still want the MSVC build environment. For WebKit ports already using CMake, they should definitely try ninja today! Anyway, my wish was not about arguing for a specific build solution. I'm instead noting that for the project to continue to move quickly, we need to stop needing to edit 8 build systems for every file move/addition. Whether that's GYP or CMake or something else, I don't really care. Adam and I tried GYP-for-WebKIt a while back. But any of these solutions will require buy-in from Apple, as they will have to do the largest amount of work converting to use something other than XCode. On Sat, Feb 2, 2013 at 8:20 PM, Nico Weber tha...@chromium.org wrote: On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth aba...@webkit.org wrote: Ninja has extremely fast incremental builds and can be generated by GYP. Here are some stats from a year ago: https://plus.google.com/101038813433650812235/posts/irc26fhRtPC Ninja has gotten even faster since then. If you're interested in trying it out, you can play around with incremental builds of the Chromium port on Mac or Linux. You can also look at the build output from the chromium bots. Empty build in 1s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio Build with a few files changed in 15s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio …and this is on fairly slow bots. On my SSD-equipped laptop, I can do incremental rebuilds of all of chrome after touching one (cpp or mm) file in 2-6s. ___ 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] SerializedScriptValue: signed vs unsigned char
On Mon, Feb 4, 2013 at 3:51 PM, Alec Flett alecfl...@chromium.org wrote: At the moment, SerializedScriptValue uses Vectoruint8_t (aka Vectorunsigned char) for both it's API (createFromWireBytes, toWireBytes) as well as its internal representation. (for both v8 and jsc implementations) The two largest consumers of this aspect of SerializedScriptValue seems to be IndexedDB and postMessage(). I'm jumping through some small hoops (i.e. reinterpret_cast and whatnot) in IndexedDB to convert between Vectoruint8_t and Vectorchar and a 'const char*' buffer in order to write out to LevelDB, who likes 'char' as opposed to unsigned char. postMessage() seems to be pretty agnostic to char vs unsigned char, since it uses SerializedScriptValue to both produce and consume the buffers it sends between windows. Before I did a code cleanup and just fixed up all the implementations to use Vectorchar I wanted to see if anyone had any objections here, on both the V8 and the JSC sides. The ultimate compiled code is going to be identical, but I'll be able to avoid all sorts of reinterpret_cast's at various points in the code. objections? WTF/WebCore 8bits characters (LChar) are unsigned char. Wouldn't you just push the reinterpret_cast to the other side of the IndexedDB module? I find it a little odd to modify WebCore based on one particular dependency (LevelDB) but maybe there is a good reason. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char
On Mon, Feb 4, 2013 at 4:51 PM, Alec Flett alecfl...@chromium.org wrote: At the moment, SerializedScriptValue uses Vectoruint8_t (aka Vectorunsigned char) for both it's API (createFromWireBytes, toWireBytes) as well as its internal representation. (for both v8 and jsc implementations) The two largest consumers of this aspect of SerializedScriptValue seems to be IndexedDB and postMessage(). I'm jumping through some small hoops (i.e. reinterpret_cast and whatnot) in IndexedDB to convert between Vectoruint8_t and Vectorchar and a 'const char*' buffer in order to write out to LevelDB, who likes 'char' as opposed to unsigned char. postMessage() seems to be pretty agnostic to char vs unsigned char, since it uses SerializedScriptValue to both produce and consume the buffers it sends between windows. Before I did a code cleanup and just fixed up all the implementations to use Vectorchar I wanted to see if anyone had any objections here, on both the V8 and the JSC sides. The ultimate compiled code is going to be identical, but I'll be able to avoid all sorts of reinterpret_cast's at various points in the code. If you are suggesting to change IndexedDB to use Vectorchar in order to accommodate the LevelDB interfaces, then I would suggest you not do that. Vectoruint8_t is more clear than Vectorchar (or Vectorunsigned char) at expressing the intended usage (binary versus character data). ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char
Well, nobody is explicitly using LChar with SerializedScriptValue (maybe it should, maybe that's another issue) but I guess this is why I'm asking - I'm happy to just deal with this in IDB with some ugly reinterpret_casts here and there (ok maybe not happy, but satisfied enough) if folks prefer that. I don't personally find uint8_t to be any more intuitive than char, but it sounds like some do. Nevermind... (In my own experience I've always found explicit unsigned to be more of a hassle then a tool for good type safely, and I suspect that's why LevelDB uses it as its lowest-common-denominator, but we don't have to have that debate here :)) Alec On Mon, Feb 4, 2013 at 4:43 PM, Benjamin Poulain benja...@webkit.orgwrote: On Mon, Feb 4, 2013 at 3:51 PM, Alec Flett alecfl...@chromium.org wrote: At the moment, SerializedScriptValue uses Vectoruint8_t (aka Vectorunsigned char) for both it's API (createFromWireBytes, toWireBytes) as well as its internal representation. (for both v8 and jsc implementations) The two largest consumers of this aspect of SerializedScriptValue seems to be IndexedDB and postMessage(). I'm jumping through some small hoops (i.e. reinterpret_cast and whatnot) in IndexedDB to convert between Vectoruint8_t and Vectorchar and a 'const char*' buffer in order to write out to LevelDB, who likes 'char' as opposed to unsigned char. postMessage() seems to be pretty agnostic to char vs unsigned char, since it uses SerializedScriptValue to both produce and consume the buffers it sends between windows. Before I did a code cleanup and just fixed up all the implementations to use Vectorchar I wanted to see if anyone had any objections here, on both the V8 and the JSC sides. The ultimate compiled code is going to be identical, but I'll be able to avoid all sorts of reinterpret_cast's at various points in the code. objections? WTF/WebCore 8bits characters (LChar) are unsigned char. Wouldn't you just push the reinterpret_cast to the other side of the IndexedDB module? I find it a little odd to modify WebCore based on one particular dependency (LevelDB) but maybe there is a good reason. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char
On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett alecfl...@chromium.org wrote: Well, nobody is explicitly using LChar with SerializedScriptValue (maybe it should, maybe that's another issue) but I guess this is why I'm asking - I'm happy to just deal with this in IDB with some ugly reinterpret_casts here and there (ok maybe not happy, but satisfied enough) if folks prefer that. I don't personally find uint8_t to be any more intuitive than char, but it sounds like some do. Nevermind... Well, since you never use character types and only raw data, just ignore my comment. As far as I know, it is already common to use signed char for raw data (in the network stack for example). Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Gated trunk, experiences from OpenStack
Hey guys, Last week a number of the team here at Google Sydney, including myself attended Linux.conf.au 2013 conference. The conference was a blast and the hot topic this year was OpenStack, an Open Source Cloud layer. The OpenStack project has grown from being a small project to having over 500 active committers and continues to grow at a rapid pace. Both the Continuous Integration Miniconf ( http://lca2013.linux.org.au/schedule/30102/view_talk?day=monday) and main conference included talks from OpenStack leaders about how they have tried to handle this growth and I think we can learn from their successes and failures. All of the OpenStack's infrastructure is documented in the following talks http://openstack-ci.github.com/publications/ I pulled the following stats to see how comparable the projects are; OpenStack; ( http://openstack-ci.github.com/publications/lca2013-ci/index.html#(3)) - Over 500 Active Technical Contributors - As many as 200 trunk changes an hour - 18 (integrated) projects (and growing) I tried looking these up in WebKit and got the following; - ~200 active contributors - As many as ~12 trunk changes an hour - 1 project, but 7 target platforms One of the most interesting parts of OpenStack was having a gated trunk. From their talk; Before each change to the OpenStack projects is merged into the main tree, unit and integration tests are run on the change, and only if they pass, is the change merged. We call this gating. There is a lot of debate about the value of a gated trunk on the internet; which I'm not going to repeat here. OpenStack's experience has been that it preserves the following properties; http://openstack-ci.github.com/publications/lca2013-ci/index.html#(9) - Ensures Code Quality - Protects developers - Devs always start from working code - Protects tree - Bad code doesn't land - Egalitarian - Process is the same for everyone - Process is transparent - Process is automated These are all things that came up in Eric's WebKit wishes email specially the parts about having an always green tree. The egalitarian nature of the system also helps with trusting people as you *know* they can not break the tree. This system is similar to our commit queue, however nobody has privileges to bypass the queue. OpenStack has 18 projects which are all tightly integrated, for example a change in the API in one project could break another project, for this reason they gate changes on tests runs from *all* projects before allowing a commit to land to any of them. While WebKit is only a single project, the process of requiring multiple jobs to be green is similar to WebKit needing to support multiple platforms. They do point out that when this system is set up, the system has to be ultra repeatable and reliable; Once everything is automated, the projects stops if the automation does - http://openstack-ci.github.com/publications/lca2013-ci/index.html#(8) To allow this to happen, OpenStack has managed to eliminated all flaky tests in their suite. WebKit is not at this stage and still has a large number tests which are both failing and/or flaky. Luckily, WebKit has much better infrastructure for dealing with and tracking them down. Other things they have done to try and make this process work are; - Like WebKit, every patch is required to have code review before being submitted. OpenStack requires two positive reviews before allowing a commit to be submitted, rather than the single one that WebKit needs. - Like WebKit, OpenStack has an early warning system which runs all tests as soon as a patch is submitted. The complete OpenStack test suite takes around ~1 hour to run, but as they have more than 1 event per hour their landing system needs pipelining. They have developed a system called Zuul to make this happen. Before they had this pipeline process, committing was taking many hours to land. You can see their currently running system at http://zuul.openstack.org/ and find out more about Zuul at the following locations; Zuul: a Pipelining Trunk Gating System http://amo-probos.org/post/14 http://mirror.linux.org.au/linux.conf.au/2013/ogv/OpenStack_Zuul.ogv I guess this is something we should discuss further. Tim 'mithro' Ansell ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
