Bug 120722

Created attachment 210543 [details] the patch

What the output looks like right now: .... bunch of stuff ** The following fast/js test failures have been introduced: fast/js/exception-expression-offset fast/js/Object-defineProperty Results for Mozilla tests: 0 regressions found. 0 tests fixed. OK. Results for fast/js tests: 2 failures found. 0 crashes found.

Created attachment 210545 [details] the patch

Comment on attachment 210545 [details] the patch r=me Nice. Why do we need jsc-test-list? Do only a subset of tests work in this way?

(In reply to comment #4) > (From update of attachment 210545 [details]) > r=me > > Nice. > > Why do we need jsc-test-list? Do only a subset of tests work in this way? Good question. The short answer is that only a subset of fast/js tests work in the jsc shell because a lot of them depend on DOM behavior. Some of them are specifically testing the JS side of DOM behavior. The long answer is that we should just use directory structure to dictate this. Any test that isn't in jsc-test-list should just be in a different directory, like I don't know, fast/js/dom RS=you to do such test motion to fast/js/dom for those tests that aren't pure JS?

Landed in http://trac.webkit.org/changeset/155092

Sounds good, rs = me.

(In reply to comment #6) > Landed in http://trac.webkit.org/changeset/155092 Unfortunately it broke run-javascriptcore-tests on linux bots at least because of the following reasons: - slurp isn't installed on the linux bots (EFL/GTK/Qt) - function and let aren't valid keyword in dash (dash is the default shell on Ubuntu!)

(In reply to comment #8) > (In reply to comment #6) > > Landed in http://trac.webkit.org/changeset/155092 > > Unfortunately it broke run-javascriptcore-tests on linux bots > at least because of the following reasons: > - slurp isn't installed on the linux bots (EFL/GTK/Qt) > - function and let aren't valid keyword in dash > (dash is the default shell on Ubuntu!) That's unfortunate, now can you fix it?

Re-opened since this is blocked by bug 120756

(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #6) > > > Landed in http://trac.webkit.org/changeset/155092 > > > > Unfortunately it broke run-javascriptcore-tests on linux bots > > at least because of the following reasons: > > - slurp isn't installed on the linux bots (EFL/GTK/Qt) > > - function and let aren't valid keyword in dash > > (dash is the default shell on Ubuntu!) > > That's unfortunate, now can you fix it? (I hope that I am being rather unambiguous that rolling this out because you're too lazy to help look for the Linux-specific workaround would be irresponsible.)

(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #6) > > > Landed in http://trac.webkit.org/changeset/155092 > > > > Unfortunately it broke run-javascriptcore-tests on linux bots > > at least because of the following reasons: > > - slurp isn't installed on the linux bots (EFL/GTK/Qt) > > - function and let aren't valid keyword in dash > > (dash is the default shell on Ubuntu!) > > That's unfortunate, now can you fix it? Of course, I can, but not now, only ~3-4 hours later.

(In reply to comment #12) > (In reply to comment #9) > > (In reply to comment #8) > > > (In reply to comment #6) > > > > Landed in http://trac.webkit.org/changeset/155092 > > > > > > Unfortunately it broke run-javascriptcore-tests on linux bots > > > at least because of the following reasons: > > > - slurp isn't installed on the linux bots (EFL/GTK/Qt) > > > - function and let aren't valid keyword in dash > > > (dash is the default shell on Ubuntu!) > > > > That's unfortunate, now can you fix it? > > Of course, I can, but not now, only ~3-4 hours later. Then leave it in and I'll make it so that Linux doesn't run the new tests.

(In reply to comment #8) > (In reply to comment #6) > > Landed in http://trac.webkit.org/changeset/155092 > > Unfortunately it broke run-javascriptcore-tests on linux bots > at least because of the following reasons: > - slurp isn't installed on the linux bots (EFL/GTK/Qt) I can fix this, give me a sec. > - function and let aren't valid keyword in dash > (dash is the default shell on Ubuntu!) Three choices: 1) You can fix the shell script to use whatever language "dash" uses. 2) Install a compliant shell. 3) Disable the new tests on Linux. I'll do (3). If you want to implement one of the other fixes, then that's fine.

(In reply to comment #11) > (I hope that I am being rather unambiguous that rolling this out because you're too lazy to help look for the Linux-specific workaround would be irresponsible.) Lazy? What's wrong with you men? Please don't expect me to fix your regression instead of you _immediately_ ... I do always willingly help fixing things ... I'd like to help you ... after I go to the office ... But considering me lazy wasn't so friendly ...

(In reply to comment #15) > (In reply to comment #11) > > (I hope that I am being rather unambiguous that rolling this out because you're too lazy to help look for the Linux-specific workaround would be irresponsible.) > > Lazy? What's wrong with you men? Please don't expect me > to fix your regression instead of you _immediately_ ... > > I do always willingly help fixing things ... I'd like to help you ... > after I go to the office ... But considering me lazy wasn't so friendly ... I'm sorry. But next time you can give me a bit more time before starting a rollout.

(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #11) > > > (I hope that I am being rather unambiguous that rolling this out because you're too lazy to help look for the Linux-specific workaround would be irresponsible.) > > > > Lazy? What's wrong with you men? Please don't expect me > > to fix your regression instead of you _immediately_ ... > > > > I do always willingly help fixing things ... I'd like to help you ... > > after I go to the office ... But considering me lazy wasn't so friendly ... > > I'm sorry. But next time you can give me a bit more time before starting a rollout. Not problem. I'm sorry too for the missing communication. But make it clear, you landed the patch ~2 hours previously, you could have notice that it broke everything. ( It was a little bit similar to http://webkitmemes.tumblr.com/post/18264800090/cool-developers-dont-look-at-the-build-bots ) Additionally I tried to contact you on #webkit, but you were offline. It's absolutely reasonable at midnight and I didn't expect you to fix this bug instead of sleeping. ;) I simple thought you left. Then I asked the webkitbot to create a rollout patch and started to write a similar comment to the bug: "I don't have time for debugging now, so I'm going to roll it out to make bots happier and will check it a little bit later after I go to the office in ~3-4 hours" But the bugzilla refused the comment, because you already closed the bug and added that disparagement comment. But please forget this misunderstanding situation and let's try to continue making WebKit better together without fighting. Thanks for these fixes: - https://trac.webkit.org/changeset/155101 - https://trac.webkit.org/changeset/155103 I tried to be constructive and fixed the run-fast-jsc script for dash: - https://bugs.webkit.org/show_bug.cgi?id=120759 filed a bug for Windows failures: - https://bugs.webkit.org/show_bug.cgi?id=120765 and made master.cfg to understand the new output: - https://bugs.webkit.org/show_bug.cgi?id=120766

(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > (In reply to comment #11) > > > > (I hope that I am being rather unambiguous that rolling this out because you're too lazy to help look for the Linux-specific workaround would be irresponsible.) > > > > > > Lazy? What's wrong with you men? Please don't expect me > > > to fix your regression instead of you _immediately_ ... > > > > > > I do always willingly help fixing things ... I'd like to help you ... > > > after I go to the office ... But considering me lazy wasn't so friendly ... > > > > I'm sorry. But next time you can give me a bit more time before starting a rollout. > > Not problem. I'm sorry too for the missing communication. > > But make it clear, you landed the patch ~2 hours previously, you could have > notice that it broke everything. ( It was a little bit similar to > http://webkitmemes.tumblr.com/post/18264800090/cool-developers-dont-look-at-the-build-bots ) > Additionally I tried to contact you on #webkit, but you were offline. It's > absolutely reasonable at midnight and I didn't expect you to fix this bug > instead of sleeping. ;) I simple thought you left. It takes ~1 hour for the Linux test bots to cycle. So yeah, I noticed it with a delay. > > Then I asked the webkitbot to create a rollout patch and started to write a > similar comment to the bug: "I don't have time for debugging now, so I'm going > to roll it out to make bots happier and will check it a little bit later after > I go to the office in ~3-4 hours" But the bugzilla refused the comment, > because you already closed the bug and added that disparagement comment. > > But please forget this misunderstanding situation and let's try > to continue making WebKit better together without fighting. > > Thanks for these fixes: > - https://trac.webkit.org/changeset/155101 > - https://trac.webkit.org/changeset/155103 > > I tried to be constructive and fixed the run-fast-jsc script for dash: > - https://bugs.webkit.org/show_bug.cgi?id=120759 > > filed a bug for Windows failures: > - https://bugs.webkit.org/show_bug.cgi?id=120765 > > and made master.cfg to understand the new output: > - https://bugs.webkit.org/show_bug.cgi?id=120766 Awesome, thanks for those!