Re: [webkit-dev] ENABLE(INSPECTOR) check in Console::lastWMLErrorMessage

2010-04-29 Thread Joseph Pecoraro
On Apr 29, 2010, at 12:53 AM, Joseph Pecoraro wrote: > Looks like it should add ENABLE(INSPECTOR) check in > Console::lastWMLErrorMessage() > (/trunk/WebCore/page/Console.cpp) Thanks. Ryan, I've created a bug and put up a few patches (2 desired behaviors): https://bugs.webkit.org/show_bug.cgi?id

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Jeremy Orlow
On Thu, Apr 29, 2010 at 9:05 PM, Adam Barth wrote: > On Thu, Apr 29, 2010 at 12:43 PM, Maciej Stachowiak wrote: > > > It seems to me a better model would be to regenerate the bindings test > file > > automatically as part of the build. Then the changes can still be > reviewed > > by you, or as p

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Eric Seidel
Since I'm in the bindings hall of shame, I guess I'm supposed to reply. ;) The twice that I've used it, it was very helpful. The few reviews I've done of Adam's it was much better than what we had before. However, I agree something better could be built. I'm just not sure what better looks like

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Alexey Proskuryakov
On 29.04.2010, at 13:38, Maciej Stachowiak wrote: Alexey (or others who don't like the new tests), do you think this change would address your concerns? It would definitely be better if changes weren't detected as failures. Changing a checked out file as part of build seems rather magical

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Maciej Stachowiak
On Apr 29, 2010, at 1:05 PM, Adam Barth wrote: On Thu, Apr 29, 2010 at 12:43 PM, Maciej Stachowiak wrote: It seems to me a better model would be to regenerate the bindings test file automatically as part of the build. Then the changes can still be reviewed by you, or as part of a diff,

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Yaar Schnitman
I see run-bindings-tests is primary a productivity tool: Faster development, easy debugging, better reviews. But it only works if the golden copies don't fall into disrepair => Hence the need to bake this tool into the general testing framework (run-webkit-tests, pre-submit checks, etc.). It will

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Adam Barth
On Thu, Apr 29, 2010 at 12:43 PM, Maciej Stachowiak wrote: > To repeat, I think this is a useful tool, but not necessarily as a test. > The mode of operation is that when you run this test, if the generated > bindings for the text IDL file change in any way, it reports a failure. Then > you must m

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Maciej Stachowiak
On Apr 29, 2010, at 11:38 AM, Ojan Vafai wrote: I don't really follow the argument against supporting this test. What is the maintenance overhead? Isn't this just like having a layout test with expected results? It's a small isolated test instead of testing everything. That seems like a go

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Adam Barth
IMHO, run-webkit-tests should run all the various webkit testing scripts and we should have a run-layout-tests script that does what run-webkit-tests does today. I'd also settle for a run-tests scripts that was the ASAD testing script. Adam On Thu, Apr 29, 2010 at 12:16 PM, David Levin wrote:

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread David Levin
Just curious, would it be less maintenance if the test run was integrated with run-webkit-tests?/Is the concern about having lots of different tests harness to run to verify a change? dave On Thu, Apr 29, 2010 at 12:11 PM, James Robinson wrote: > As a concrete example, I found this test setup h

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread James Robinson
As a concrete example, I found this test setup helpful for this patch: http://trac.webkit.org/changeset/58345. A nice side effect was that it revealed a bug in CodeGeneratorGObject.pm and let me fix it without having to set up build setup for whatever it is that uses the GObject bindings. I agree

Re: [webkit-dev] attach/detach or insertedIntoDocument/removedFromDocument

2010-04-29 Thread Sergiy Byelozyorov
Noone? Sergiy On Tue, Apr 27, 2010 at 12:59 PM, Sergiy Byelozyorov < r...@graphics.cs.uni-sb.de> wrote: > Hello, > > I am implementing XML3D format into WebKit. I have > a number of new elements that I have added to a separate namespace. Root > element is and it's the o

[webkit-dev] High performance TCP Sockets in WebKit

2010-04-29 Thread Chinmaya Sn
Hi Everyone, I need to implement a general purpose, high performance TCP sockets inside WebCore for some of my work. By high performance I mean select/poll (multiplexing) based and by general purpose, I mean, any one (Inside WebCore) should be able to open a socket and transfer any kind of data in

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Ojan Vafai
On Thu, Apr 29, 2010 at 11:39 AM, Alexey Proskuryakov wrote: > On 29.04.2010, at 11:17, Yaar Schnitman wrote: > >> I've been using the tool for a couple of patches in V8. It really boost >> the development cycle, helps reviewers understanding what a cryptic perl >> block of code actually does, an

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Alexey Proskuryakov
On 29.04.2010, at 11:17, Yaar Schnitman wrote: I've been using the tool for a couple of patches in V8. It really boost the development cycle, helps reviewers understanding what a cryptic perl block of code actually does, and side effects are easy to find. Once you start using it, its becom

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Alexey Proskuryakov
On 29.04.2010, at 10:54, Adam Barth wrote: You should feel free to develop a better testing harness. Since you're proposing run-bindings-tests as a required tool for everyone to use, I don't think that this resolves my concerns. The maintenance is super easy. I've been doing a lot of de

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Maciej Stachowiak
On Apr 29, 2010, at 10:54 AM, Adam Barth wrote: It would be great to have a tool that generates a diff of derived sources for inspection, but making it into a test for everyone to maintain feels like unnecessary burden. I certainly would feel bad about having to maintain a test that ver

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Adam Barth
On Thu, Apr 29, 2010 at 10:54 AM, Adam Barth wrote: > On Thu, Apr 29, 2010 at 10:39 AM, Alexey Proskuryakov wrote: >> On 29.04.2010, at 10:27, Jeremy Orlow wrote: >>> It's great to test end-to-end behavior, and unit tests can also also >>> useful sometimes, but why test that source code stays byt

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Kent Hansen
ext Alexey Proskuryakov wrote: On 29.04.2010, at 10:30, Adam Barth wrote: Yeah, without seeing the consequence on the generated code, it can be very difficult to review changes to the code generator. Yes, that's a useful goal. Since an old version of code generating scripts is alwa

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Adam Barth
On Thu, Apr 29, 2010 at 10:39 AM, Alexey Proskuryakov wrote: > On 29.04.2010, at 10:27, Jeremy Orlow wrote: >> It's great to test end-to-end behavior, and unit tests can also also >> useful sometimes, but why test that source code stays byte to byte >> identical? >> >> When you make a change to th

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Alexey Proskuryakov
On 29.04.2010, at 10:30, Adam Barth wrote: Yeah, without seeing the consequence on the generated code, it can be very difficult to review changes to the code generator. Yes, that's a useful goal. Since an old version of code generating scripts is always in .svn directory (or its git equiva

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Alexey Proskuryakov
On 29.04.2010, at 10:27, Jeremy Orlow wrote: It's great to test end-to-end behavior, and unit tests can also also useful sometimes, but why test that source code stays byte to byte identical? When you make a change to the code generator, you should make a corresponding change to the gene

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Adam Barth
On Thu, Apr 29, 2010 at 9:44 AM, Alexey Proskuryakov wrote: > On 26.04.2010, at 22:06, Adam Barth wrote: >> If you make changes to CodeGenerator*.pm, please test your >> change using the following command: >> >> ~/git/webkit$ ./WebKitTools/Scripts/run-bindings-tests > > > I don't understand the ut

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Adam Barth
On Thu, Apr 29, 2010 at 10:27 AM, Jeremy Orlow wrote: > On Thu, Apr 29, 2010 at 5:44 PM, Alexey Proskuryakov wrote: >> On 26.04.2010, at 22:06, Adam Barth wrote: >>> If you make changes to CodeGenerator*.pm, please test your >>> change using the following command: >>> >>> ~/git/webkit$ ./WebKitTo

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Jeremy Orlow
On Thu, Apr 29, 2010 at 5:44 PM, Alexey Proskuryakov wrote: > > On 26.04.2010, at 22:06, Adam Barth wrote: > > If you make changes to CodeGenerator*.pm, please test your >> change using the following command: >> >> ~/git/webkit$ ./WebKitTools/Scripts/run-bindings-tests >> > > > I don't understan

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Alexey Proskuryakov
On 26.04.2010, at 22:06, Adam Barth wrote: If you make changes to CodeGenerator*.pm, please test your change using the following command: ~/git/webkit$ ./WebKitTools/Scripts/run-bindings-tests I don't understand the utility of such testing. When one edits CodeGenerator*.pm, that's general

Re: [webkit-dev] Function & Property Names

2010-04-29 Thread Nyx
Kent Hansen-2 wrote: > > Works for me. > You can pass callFrame to name() if you want, the result is the same. > What does your JavaScript look like? > E.g., if you're using a function expression > > Foo.prototype.bar = function() { ... } > > Then that function isn't going to have a name, e.g.

Re: [webkit-dev] Disabling the JIT

2010-04-29 Thread Nyx
chinmaya sn (chins) wrote: > > Just curious, how would you verify if JavaScript in your browser has JIT > support or not? > I added this in the interpreter constructor: #if ENABLE(JIT) printf("JIT enabled\n"); #else printf("JIT disabled\n"); #endif As an update. Building with "JAVASC

Re: [webkit-dev] MathML in Qt

2010-04-29 Thread İsmail Dönmez
Nice! Thanks for letting us know. Regards, ismail On Thu, Apr 29, 2010 at 5:37 PM, Alex Milowski wrote: > My patch for MathML support in the Qt port build has just been committed. > So > far it looks good. > > There are some issues with the over all MathML rendering code on Linux that > I'm lo

[webkit-dev] MathML in Qt

2010-04-29 Thread Alex Milowski
My patch for MathML support in the Qt port build has just been committed. So far it looks good. There are some issues with the over all MathML rendering code on Linux that I'm looking into (e.g. stack operators have some font issues). These aren't specific to the Qt port. -- --Alex Milowski "T

Re: [webkit-dev] Function & Property Names

2010-04-29 Thread Kent Hansen
Hi, ext Nyx wrote: I'm in the process of writing a program to analyze traces of JavaScript code. This involves logging events that occur in the interpreter. Currently, I'm trying to just log function calls and property accesses. However, I'm unsure exactly how to go about getting the names (iden

[webkit-dev] Root (accessible) element in WebKitGtk+

2010-04-29 Thread Mario Sanchez Prada
Hi, I've recently started to look at a11y issues in WebKitGtk (nothing too impressive, just taking a look by the moment :-)), and I found the implementation a bit strange, and not sure whethers there's a reason for that I'm missing (most likely, I'd say): // WebKitTools/DumpRenderTree/gtk/Access

Re: [webkit-dev] ENABLE(INSPECTOR) check in Console::lastWMLErrorMessage

2010-04-29 Thread Joseph Pecoraro
Hello Ryan, > Looks like it should add ENABLE(INSPECTOR) check in > Console::lastWMLErrorMessage() > (/trunk/WebCore/page/Console.cpp) Thanks. Could you file a bug using this link? http://webkit.org/new-inspector-bug Please include any relevant error messages you're getting, such as a compiler