Re: [webkit-dev] On returning mutable pointers from const methods
On Oct 28, 2012, at 10:09 PM, Peter Kasting pkast...@chromium.org wrote: On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak m...@apple.com wrote: I am not sure a blanket rule is correct. If the Foo* is logically related to the object with the foo() method and effectively would give access to mutable internal state, then what you say is definitely correct. But if the const object is a mere container that happens to hold pointers, there's no particular reason it should turn them into const pointers. For example, it is fine for const methods of HashSet or Vector to return non-const pointers if that happens to be the template parameter type. In such cases, constness of the container should only prevent you from mutating the container itself, not from mutating anything held in the container, or else const containers of non-const pointers (or non-const types in general) would be useless. IMO const containers that vend non-const pointers _are_ nearly useless. I consider logical constness to include not only this statement has no observable side effect but also this statement does not allow me to issue a subsequent statement with observable side effects. Surely that's not quite correct as a definition of logical constness. You can always pass a const reference to another object's setter to cause an observable side effect. The scope of side effects under consideration has to be limited to the object itself plus anything else that could be considered part of its state. In brief, a const method on object O should neither mutate O nor expose the possibility of mutating the state of O, but it has no responsibility for its involvement in mutation of objets A const Vector that allows to to obtain a non-const element pointer, which you subsequently mutate, means that you can mutate the vector. (Consider for example an element destructor that removes the element from the vector.) If you allow const methods to return non-const pointers, it's almost always possible to construct some chain of events that leads to mutation of the const object or of state it can observe. It is far easier to simply make simple rules like const methods shall not vend non-const pointers than try to allow it but guarantee that all the code everyone writes is safe. Sure, there are unusual circumstances where calling non-const methods could cause totally unexpected side effects. But taking const strictness to this level makes it impossible to express some useful semantics. Consider the following use case: - I have collected a an ordered list of pointers to objects of type T in a Vector. - I'd like to call a function that will operate on this list - it's allowed to do anything it wants to the Ts, including mutating them, but it can't alter the order or contents of the Vector. (For example, I may want to pass the same list to another function). Currently one would express this by passing a const VectorT*. I don't see a good approach to this that strictly follows the suggested rule. You'd have to either copy the Vector to a temporary just for the call, or abandon const-correctness. Note that the other semantic (can't mutate the T's themselves) is currently available as const Vectorconst T* but the proposal, strictly construed, would make those two types effectively identical. I do think returning const pointers from accessors is generally the right thing when we aren't just talking about pure containers. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
On Sun, Oct 28, 2012 at 11:16 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 28, 2012, at 10:09 PM, Peter Kasting pkast...@chromium.org wrote: On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak m...@apple.com wrote: I am not sure a blanket rule is correct. If the Foo* is logically related to the object with the foo() method and effectively would give access to mutable internal state, then what you say is definitely correct. But if the const object is a mere container that happens to hold pointers, there's no particular reason it should turn them into const pointers. For example, it is fine for const methods of HashSet or Vector to return non-const pointers if that happens to be the template parameter type. In such cases, constness of the container should only prevent you from mutating the container itself, not from mutating anything held in the container, or else const containers of non-const pointers (or non-const types in general) would be useless. IMO const containers that vend non-const pointers _are_ nearly useless. I consider logical constness to include not only this statement has no observable side effect but also this statement does not allow me to issue a subsequent statement with observable side effects. Surely that's not quite correct as a definition of logical constness. You can always pass a const reference to another object's setter to cause an observable side effect. The scope of side effects under consideration has to be limited to the object itself plus anything else that could be considered part of its state. In brief, a const method on object O should neither mutate O nor expose the possibility of mutating the state of O, but it has no responsibility for its involvement in mutation of objets Sorry, I left out words. Consider the phrase on the state of the object to be appended to both those quoted phrases I originally said. I still think that it's extremely difficult to avoid exposing the possibility of mutating the state of O in most cases. The mechanism may be obscure, but it is frequently present -- frequently enough to make me advocate for hard-and-fast rules. Consider the following use case: - I have collected a an ordered list of pointers to objects of type T in a Vector. - I'd like to call a function that will operate on this list - it's allowed to do anything it wants to the Ts, including mutating them, but it can't alter the order or contents of the Vector. (For example, I may want to pass the same list to another function). Currently one would express this by passing a const VectorT*. I don't see a good approach to this that strictly follows the suggested rule. You'd have to either copy the Vector to a temporary just for the call, or abandon const-correctness. I think by abandon const-correctness you mean pass a VectorT**, which is indeed the route I'd go. I don't consider that an abandonment of const-correctness, in that you are indeed not violating logical constness. But yes, you lose the ability to convey the idea that this function, in and of itself, doesn't modify the number or order of elements in the vector. On the other hand, you don't put yourself in a position where a caller of the function could then immediately use his returned T* to mutate the vector -- which is often a real possibility in real-world systems. There aren't any magic bullets here. Given that the compiler can very rarely use const to optimize anything anyway, const is effectively whatever we want it to be. I prefer hard guarantees that occur less frequently to less-ironclad guarantees that are more common. Reasonable people can disagree. I think your position -- that the hard guarantee usually makes sense for non-simple-containers but you'd prefer to allow a less-strict usage for simple containers -- is one that has some appeal even if it's not what I'd personally choose (and is more complex to explain/enforce). I certainly think we'd be in a better world if the codebase followed this policy, compared to today. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] question about jsc
hi, all, I try to port the webkit to a new platform(the platform is linux based run with glibc glib, but not gtk), now I have build the jsc project successfully, but when I run the jsc program, something happend show as below: qing@HAHA:/data/project/webOS/WebKit/Source/JavaScriptCore/JavaScriptCore.catwalk$ ./jsc var string=hello world :); undefined print(string); hello world :) undefined now I have 2 questions: 1. Why the word undefined comes up? 2. How to test the jsc program? qing 2012-10-29 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Oct 28, 2012, at 3:30 PM, Antti Koivisto koivi...@iki.fi wrote: We could clear the cache between tests but run each test twice in a row. Second run will then happen with deterministically pre-populated cache. That would both make things more predictable and improve our test coverage for cached cases. Unfortunately it would also slow down testing significantly, though less than 2x. I actually really like this idea. Doing it this way would effectively run each test both completely uncached, and fully cached, which would be better test coverage than our current approach. Can we get an estimate on what this would cost if applied to our whole test suite? Could we do it for just a subset of the tests? (BTW I think this is better than the virtual test suite approach suggested by Dirk; running the test with all its resources cached from having loaded it immediately before is more reliable and better test coverage than running it later as part of some sequence that doesn't clear the cache.) Does anyone strongly object to this approach? It seems way better to me than other options discussed on this thread. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] How to modify JsHTMLMediaElement.cpp to add STOP fucntionality
Hi All, I'm trying to add stop functionality in my application which is using webkit on WIN port. currently Play and Pause functions are available but no STOP function is present , so in JsHTMLMediaElement.cpp I have added a new function: jsHTMLMediaElementPrototypeFunctionStop(ExecState* exec) After this function and couple of changes in my application , I'm able to perform STOP functionality. But I guess I can not modify this file. So can someone please let me know , how to add this function ?? Regards, Ankit ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
I don't think the original proposal was meant to apply to the basic container types. Would this be a sensible rule to adopt for WebCore only for example? Like all our blanket rules, this one should be ignored when it doesn't make sense. If that kind of cases are expected to be very rare then their existence shouldn't be a show stopper for adopting the rule. antti ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
On Oct 29, 2012, at 3:47 PM, Antti Koivisto koivi...@iki.fi wrote: I don't think the original proposal was meant to apply to the basic container types. Would this be a sensible rule to adopt for WebCore only for example? Like all our blanket rules, this one should be ignored when it doesn't make sense. If that kind of cases are expected to be very rare then their existence shouldn't be a show stopper for adopting the rule. At the moment, I can't think of any obvious counter-examples to the rule other than basic container types. I don't have a problem with the rule in general as long as we acknowledge the exceptions. If we wanted to enforce the rule mechanically, then we could just whitelist the relevant basic data structure types. The same rule should probably also apply to references (and references to pointers). I think when describing the rule, we should also identify the underlying motivation: don't expose mutable state from a const member function in addition to the concrete method used to avoid that goal. That would help avoid misunderstanding over time about the purpose of the rule. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] question about jsc
The output of undefined is normal. It is the result of the expression you entered. jsc is basically returning the result of the expressions you enter. Both var and print themselves evaluate to undefined. If you try x = 1; you'll get 1 as that expression returns 1. Concerning testing, If you have successfully built testapi, from the webkit top directory you can run Tools/Scripts/run-javascriptcore-tests. This script will first run testapi, which tests the JavaScript APIs and then run a collection of javascript tests. If you have successfully built testRegExp, you can run run-regexp-tests which will test the regular expression engine. Both testapi and testRegExp should be built along with jsc when you run the script Tools/Scripts/build-jsc. - Michael On Oct 29, 2012, at 2:39 AM, yuqing cai yuqingc...@gmail.com wrote: hi, all, I try to port the webkit to a new platform(the platform is linux based run with glibc glib, but not gtk), now I have build the jsc project successfully, but when I run the jsc program, something happend show as below: qing@HAHA:/data/project/webOS/WebKit/Source/JavaScriptCore/JavaScriptCore.catwalk$ ./jsc var string=hello world :); undefined print(string); hello world :) undefined now I have 2 questions: 1. Why the word undefined comes up? 2. How to test the jsc program? qing 2012-10-29 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] question about jsc
Michael, Thanks for your reply, now I understand it. :~) 于 2012年10月29日 23:16, Michael Saboff 写道: The output of undefined is normal. It is the result of the expression you entered. jsc is basically returning the result of the expressions you enter. Both var and print themselves evaluate to undefined. If you try x = 1; you'll get 1 as that expression returns 1. Concerning testing, If you have successfully built testapi, from the webkit top directory you can run Tools/Scripts/run-javascriptcore-tests. This script will first run testapi, which tests the JavaScript APIs and then run a collection of javascript tests. If you have successfully built testRegExp, you can run run-regexp-tests which will test the regular expression engine. Both testapi and testRegExp should be built along with jsc when you run the script Tools/Scripts/build-jsc. - Michael On Oct 29, 2012, at 2:39 AM, yuqing cai yuqingc...@gmail.com wrote: hi, all, I try to port the webkit to a new platform(the platform is linux based run with glibc glib, but not gtk), now I have build the jsc project successfully, but when I run the jsc program, something happend show as below: qing@HAHA:/data/project/webOS/WebKit/Source/JavaScriptCore/JavaScriptCore.catwalk$ ./jsc var string=hello world :); undefined print(string); hello world :) undefined now I have 2 questions: 1. Why the word undefined comes up? 2. How to test the jsc program? qing 2012-10-29 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Mon, Oct 29, 2012 at 5:48 AM, Maciej Stachowiak m...@apple.com wrote: On Oct 28, 2012, at 10:09 PM, Dirk Pranke dpra...@chromium.org wrote: On Sun, Oct 28, 2012 at 6:32 AM, Maciej Stachowiak m...@apple.com wrote: I think the nature of loader and cache code is that it's very hard to make tests which always fail deterministically when regressions are introduced, as opposed to randomly. The reason for this is that bugs in these areas are often timing-dependent. I think it's likely this tendency to fail randomly will be the case whether or not the tests are trying to explicitly test the cache or are just incidentally doing so in the course of other things. I am not familiar with the loader and caching code in webkit, but I know enough about similar problem spaces to be puzzled by why it's impossible to write tests that can adequately test the code. Has anyone claimed that? I think impossible to write tests that can adequately test the code is not a position that anyone in this thread has taken, certainly not me above. My claim is only that many classes of loader and cache bugs, when first introduced, are likely to cause nondeterministic test failures. And further, this is likely to be the case even if tests are written to target that subsystem. That's not the same as saying adequate tests are impossible. I'm sorry, I didn't mean impossible literally. Please strike that, as it sounds like it has just made a confusing situation worse. But, you did claim that it would be very hard to make tests that always fail deterministically, and I don't see why that's true? Testing things that are timing-dependent only require that you be able to control or simulate time. It may be that this is hard to do with layout tests, but it's pretty straightforward with unit tests that allow you to control the layers above and below the cache. It just means to have good testing of some areas of the code, we need a good way of dealing with nondeterministic failures. This is backwards. If you *don't* have good testing, more of your failures are likely to show up sporadically, which leads you to want to build tools for them. Randomized testing is a helpful tool to use *alongside* focused testing to ensure coverage, but should not be used as a replacement. What I personally would most wish for is good tools to catch when a test starts failing nondeterministically, and to identify the revision where the failures began. The reason we hate random failures is that they are hard to track down and diagnose. But some types of bugs are unlikely to manifest in a purely deterministic way. It would be good if we had a reliable and useful way to catch those types of bugs. This is a fine idea -- and I'm always happy to talk about ways we can improve our test tooling, please feel free to start a separate thread on these issues -- but I don't want to lose sight of the main issue here. I think the problem I identified -- that it's overly hard to track down and diagnose regressions that cause tests to fail only part of the time -- is more important and more fundamental than any of the three problems that you cite below. Our test infrastructure ultimately exists to help us notice and promptly fix regressions, and for some types of regressions, namely those that do not manifest 100% of the time, it is not working so well. The problems you mention are all secondary consequences of that fundamental problem, in my opinion. First of all, this isn't an either/or situation. We should be capable of addressing all of these issues in parallel. Second, I don't see how the existence of bugs in the code, the lack of test isolation, or the lack of good test coverage for certain layers of the code follow from not having good tools to triage intermittent failures? That seems like putting the cart before the horse. Third, are you familiar with the flakiness dashboard? http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.orgbuilder=Apple%20Lion%20Debug%20WK1%20(Tests) Does it not do exactly what you're describing? Are there things that you would like added? If it would be helpful for us to have a meeting or something to help explain how this works, I'm sure we could set one up. - Maciej It sounds like we've identified three existing problems - please correct me if I'm misstating them: 1. There appears to be a bug in the caching code that is causing tests for other parts of the system to fail randomly. 2. DRT and WTR on some ports are implemented in a way that is causing the system to be more fragile than some of us would like it to be, and there doesn't seem to be an a priori need for this to be the case; indeed some ports already don't do this. 3. We don't apparently have dedicated test coverage for caching and the loader that people think is good enough, and getting such tests might be hard. P.S. I do think your problem
Re: [webkit-dev] Performance Tests
Thanks a lot for your work :) This is a huge improvement to our perf. test infrastructure. On Mon, Oct 29, 2012 at 3:01 PM, Zoltan Horvath zol...@webkit.org wrote: Hi there, In the past few weeks I made some refactoring work on the PageLoad tests of the PerformanceTests, so now for your information, what were accessible under PerformanceTests/PageLoad/* now accessible only under PerformanceTests/SVG. We have now a platform independent solution for the 'PageLoad' tests to measure the JSHeap and (Fast)Malloc memory usage from JS without DRT modifications. Cool! You can check the results on our WebKitPerformance site: http://webkit-perf.appspot.com I made some modifications on the Performance Tests wiki page as well, you can find it under its new location or from the track main page: http://trac.webkit.org/wiki/Performance%20Tests Have fun, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Some stderr output missing when using run-webkit-tests
On Mon, Oct 29, 2012 at 6:59 PM, Dirk Pranke dpra...@chromium.org wrote: If that's the case, it's a bug, and new to me. The output was present on the results page, but it would only include the first, maybe, 60 lines or so. - Dana -- Dirk On Mon, Oct 29, 2012 at 3:42 PM, Terry Anderson tdander...@chromium.org wrote: I was actually noticing that some of the stderr output was missing from a failing test, not a passing one. Terry On Sun, Oct 28, 2012 at 8:42 PM, Dirk Pranke dpra...@chromium.org wrote: As Balazs said, we don't save the stderr output from tests that pass. So, you don't have to crash, but your tests have to at least fail. It wouldn't be hard to change that somehow ... -- Dirk On Sun, Oct 28, 2012 at 4:29 PM, Terry Anderson tdander...@chromium.org wrote: Hi webkit-dev, When I include fprintf(stderr, ...) statements in WebKit code that I expect to be executed when running a set of layout tests, the summary page of run-webkit-tests will sometimes only show a subset of these statements. However, when I add a CRASH() somewhere in the code, the missing stderr output will appear on the summary page. Has anyone else experienced this issue? Is there a way to force run-webkit-tests to display all stderr output without needing to force a crash at a particular point in the code? Terry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
