Re: [webkit-dev] Incremental steps towards moving WebCore/platform out of WebCore
One concern is that Platform is too generic to put in global namespace and it might conflict existing symbols from platform SDK or something. But because we already have generic names like ASSERT() and it works, this concern is just a theoretical thing. So if it works with existing platforms, I think it's fine. -- morrita On Thu, Dec 15, 2011 at 4:02 PM, Jarred Nicholls jar...@webkit.org wrote: On Thu, Dec 15, 2011 at 1:55 AM, Adam Barth aba...@webkit.org wrote: I was working backwards from what's going to be needed to move WebCore/platform out of WebCore, and it occurred to me that we'll probably want a separate namespace for the code once it's outside of WebCore, just like WTF has a separate namespace from JSC. It seems like introducing the new namespace before the move would be beneficial because it would help us sort out whatever layering violations we have today (as they'd become apparent because of the explicit mention of the WebCore namespace). What would be an appropriate name for the namespace? My first instinct is Platform to match the name of the new directory, but I'm open to suggestions. I think Platform is good. When explaining it to an outsider, I refer to it as the Client Interface or Port Interface. If Platform doesn't resonate well with everyone then maybe something around that verbiage would fit. But honestly I can't think of anything better than Platform. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JavaScriptCore and ES6
Hello all,
As you probably know, the ECMA TC39 committee is slowly approaching
consensus on a new revision of the ECMAScript language. The interim
results of this process have gone under various names: Harmony, ES.next,
and ES6. They are the same thing. This mail is intended to open the
discussion on what to do now regarding ES6 in JSC.
Here is the latest draft ES6 spec, from 7 November:
http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_draftscache=cachemedia=harmony:working_draft_ecma-262_edition_6_11-7-11.pdf
Discussion takes place among committee members. Some discussion also
takes place in public, on es-disc...@mozilla.org.
We cannot consider implementing ES6 now, as the final document is not
out, and some things are likely to change. It only makes sense to look
at the features for which broad consensus exists.
So, what is agreed upon in the ES6 spec? I would answer this by
mentioning the parts of ES6 that folks are working on both for
SpiderMonkey and for V8. These are:
1. Block-scoped `let' and `const'
(https://bugs.webkit.org/show_bug.cgi?id=31813)
2. typeof 'null' - 'null', not 'object'
3. Proxies
4. Collections (maps, sets, weak maps)
Things that are not implemented by multiple JS engines, but otherwise
are close to agreement:
5. Modules
6. Destructuring binding
7. Parameter default values, rest parameters
8. Quasi-literals
9. Generators, iterators, comprehensions
10. Binary data
Things that will probably change:
11. Classes, |, .{
See http://wiki.ecmascript.org/doku.php?id=harmony:proposals for more
information.
V8 currently compiles in support for 1-4, but disabled behind a runtime
flag. I think that with the nightly Chromium builds you can run it with
--harmony to enable these features. Modules are being worked on for V8,
but not finished AFAIK.
* * *
One big problem for ES6 is how to get there from here: how to enable
the new language features without breaking the web. The current answer
is to define a new mode, and allow code to opt-in to that mode.
Recall that ES5 defines strict mode, a new mode of execution for JS.
Let's call the other mode classic mode. ES6 defines a third extended
mode, which builds on strict mode, and enables the new features.
ES6 does not yet define how extended mode is entered, however. Some ES6
functionality is incompatible both with classic mode and with strict
mode, so it has to be an opt-in thing, perhaps via script
type=application/ecmascript;version=6.
However, there is a subset of ES6 that is compatible with strict-mode.
I am interested in implementing parts of this set. Specifically, I am
interested in implementing block-scoped `let' and `const'.
I think it would be fine to enable the compatible subset of ES6 within
all strict-mode code. It would not be incompatible with existing code
on the web. V8 seems likely to go in this direction as well, and
SpiderMonkey already has done so. Effectively, strict mode could become
compatible extended mode, globally.
Compatible extended mode is not a point we need to decide now,
however. Implementation work towards agreed-upon parts of ES6 is useful
in any eventuality.
Now, it is fine enough to have an implementation of parts of ES6 behind
an #ifdef. I think though that we should get to the point that the
#ifdef is on by default, then removed entirely. We still need a bit to
indicate at parse-time whether a piece of code is extended-mode or
strict-mode. It does not seem that we need a runtime extended-mode bit,
though, as we do with strict-mode vs classic-mode.
My current approach to this, given that the ES6 draft doesn't specify
how to enter extended mode, is to provide a global flag that turns
strict mode into compatible extended mode.
So, those are my thoughts on this. Your feedback is welcome. I hope to
have a block scope implementation finished by mid-january or so; follow
https://bugs.webkit.org/show_bug.cgi?id=31813, for more information.
Regards,
Andy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Incremental steps towards moving WebCore/platform out of WebCore
The BlackBerry port uses BlackBerry::Platform for its system libraries - it wouldn't surprise me if some of our files in the platform dirs have using BlackBerry so they can just use Platform::symbol instead of BlackBerry::Platform::symbol in the source. Shouldn't be hard to sort out, though. -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Hajime Morrita Sent: Thursday, December 15, 2011 3:31 AM To: Jarred Nicholls Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Incremental steps towards moving WebCore/platform out of WebCore One concern is that Platform is too generic to put in global namespace and it might conflict existing symbols from platform SDK or something. But because we already have generic names like ASSERT() and it works, this concern is just a theoretical thing. So if it works with existing platforms, I think it's fine. -- morrita On Thu, Dec 15, 2011 at 4:02 PM, Jarred Nicholls jar...@webkit.org wrote: On Thu, Dec 15, 2011 at 1:55 AM, Adam Barth aba...@webkit.org wrote: I was working backwards from what's going to be needed to move WebCore/platform out of WebCore, and it occurred to me that we'll probably want a separate namespace for the code once it's outside of WebCore, just like WTF has a separate namespace from JSC. It seems like introducing the new namespace before the move would be beneficial because it would help us sort out whatever layering violations we have today (as they'd become apparent because of the explicit mention of the WebCore namespace). What would be an appropriate name for the namespace? My first instinct is Platform to match the name of the new directory, but I'm open to suggestions. I think Platform is good. When explaining it to an outsider, I refer to it as the Client Interface or Port Interface. If Platform doesn't resonate well with everyone then maybe something around that verbiage would fit. But honestly I can't think of anything better than Platform. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Incremental steps towards moving WebCore/platform out of WebCore
The namespace name Platform is OK. I’m concerned that this is over-use of namespace and will make WebCore code overall harder to read. One of the notable features of the classes in the platform directory is that they fit in smoothly and are easy to use in WebCore. Being in the same namespace as the rest of WebCore is part of that. If we do use a namespace, we’ll have to decide whether to use it in a conventional way or use it with the “put using in header” technique that we use, somewhat controversially, in WTF. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Is Harmony a new WebKit project?
I see some work in JavaScriptCore on something named Harmony. Is adding this a WebKit project? If so, then I’d like to see the customary webkit-dev message announcing the new project so we can discuss it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is Harmony a new WebKit project?
An e-mail was sent to webkit-dev about this four hours ago, titled: [webkit-dev] JavaScriptCore and ES6 Peter On Thu, Dec 15, 2011 at 16:24, Darin Adler da...@apple.com wrote: I see some work in JavaScriptCore on something named Harmony. Is adding this a WebKit project? If so, then I’d like to see the customary webkit-dev message announcing the new project so we can discuss it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How to use ASSERT_NO_EXCEPTION
Here’s my first draft of a note about ASSERT_NO_EXCEPTION. We might want to add this to the WebCore website; not sure. Many core DOM functions in classes in WebCore serve a dual purpose. They are used to implement DOM API that can be called from JavaScript. This often means that they will handle exceptional cases by raising a DOM exception. For example, if you call appendChild and pass a null pointer for the child, you will get a NOT_FOUND_ERR exception. Those same functions are often used to implement the internals of the web engine. In those cases, they are called by callers who can guarantee none of the exceptional cases exist. Before ASSERT_NO_EXCEPTION, here’s how you would write a call like that: ExceptionCode ec; appendChild(newChild, ec); ASSERT(!ec); That’s pretty ugly, and we can do better. ASSERT_NO_EXCEPTION lets us do these two things: #include ExceptionCodePlaceholder.h appendChild(newChild, ASSERT_NO_EXCEPTION); That’s pretty good, but this is even better: appendChild(newChild); To allow the last style, we add the ExceptionCodePlaceholder.h include to the header file and make ASSERT_NO_EXCEPTION the default argument for the ExceptionCode in the function’s declaration in the header. If you look at ContainerNode.h you can see that in use for appendChild. Here are some rules of thumb for using this: 1) If there’s a DOM function where callers inside WebCore can easily guarantee that no exception will be raised, it’s recommended to add ASSERT_NO_EXCEPTION as a default value for the ExceptionCode argument. 2) If you need to call a function like this, first double check that you can indeed guarantee that no exception will occur, then either use ASSERT_NO_EXCEPTION directly and 3) Do not use ASSERT_NO_EXCEPTION if the exception is possible. Be sure that you know why there is no exception possible before using this technique. In some cases, you may even need to add a comment to the source code explaining why no exception is possible. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to use ASSERT_NO_EXCEPTION
-Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Darin Adler Sent: Thursday, December 15, 2011 11:37 AM To: WebKit Development Subject: [webkit-dev] How to use ASSERT_NO_EXCEPTION Those same functions are often used to implement the internals of the web engine. In those cases, they are called by callers who can guarantee none of the exceptional cases exist. Before ASSERT_NO_EXCEPTION, here's how you would write a call like that: ExceptionCode ec; appendChild(newChild, ec); ASSERT(!ec); That's pretty ugly, and we can do better. ASSERT_NO_EXCEPTION lets us do these two things: #include ExceptionCodePlaceholder.h appendChild(newChild, ASSERT_NO_EXCEPTION); That's pretty good, but this is even better: appendChild(newChild); I disagree that the last style is better. Having the text ASSERT_NO_EXCEPTION in every function call makes it clear to all readers that there's a theoretical possibility of an exception here, and the author has made sure that it can't happen. If the assertion is hidden in the default parameter, people who come to the code without reading this note (which will be very common) won't know the rules. Here are some rules of thumb for using this: 1) If there's a DOM function where callers inside WebCore can easily guarantee that no exception will be raised, it's recommended to add ASSERT_NO_EXCEPTION as a default value for the ExceptionCode argument. 2) If you need to call a function like this, first double check that you can indeed guarantee that no exception will occur, then either use ASSERT_NO_EXCEPTION directly and 3) Do not use ASSERT_NO_EXCEPTION if the exception is possible. Be sure that you know why there is no exception possible before using this technique. In some cases, you may even need to add a comment to the source code explaining why no exception is possible. Whenever there are rules of thumb like this, we need constant vigilance by the reviewers to make sure they're followed. This is made easier if the coding style enforces the rules, so that places where they're ignored stand out. Having ASSERT_NO_EXCEPTION appearing in the code is a valuable reminder to authors and reviewers that they should be checking for exception-safety. Without it, I suspect we will often forget to check for this. I think the first rule of thumb should be reversed, and explicit ASSERT_NO_EXCEPTION should be the norm. Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Incremental steps towards moving WebCore/platform out of WebCore
On Thu, Dec 15, 2011 at 8:22 AM, Darin Adler da...@apple.com wrote: The namespace name Platform is OK. I’m concerned that this is over-use of namespace and will make WebCore code overall harder to read. One of the notable features of the classes in the platform directory is that they fit in smoothly and are easy to use in WebCore. Being in the same namespace as the rest of WebCore is part of that. If we do use a namespace, we’ll have to decide whether to use it in a conventional way or use it with the “put using in header” technique that we use, somewhat controversially, in WTF. My inclination is to put using in the header for exactly this reason. I'm hopeful the namespace be useful in preventing dependencies in the other direction, where WebCore namespaced types are used in Platform. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore and ES6
The versioning issues in ECMAScript are tough. We ran into these same
problems when we were working with TC39 to formulate a versioning plan
for what became ES5. None of the alternatives are really that great,
but you likely need to pick one to make progress.
I would caution you about adding more modes to ECMAScript. That trick
works once or twice, but if you keep adding modes over the years, you
eventually end up with something extremely complicated. IE is
starting to suffer from this pain as their number of rendering modes
compounds with each release.
Adam
On Thu, Dec 15, 2011 at 3:38 AM, Andy Wingo wi...@igalia.com wrote:
Hello all,
As you probably know, the ECMA TC39 committee is slowly approaching
consensus on a new revision of the ECMAScript language. The interim
results of this process have gone under various names: Harmony, ES.next,
and ES6. They are the same thing. This mail is intended to open the
discussion on what to do now regarding ES6 in JSC.
Here is the latest draft ES6 spec, from 7 November:
http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_draftscache=cachemedia=harmony:working_draft_ecma-262_edition_6_11-7-11.pdf
Discussion takes place among committee members. Some discussion also
takes place in public, on es-disc...@mozilla.org.
We cannot consider implementing ES6 now, as the final document is not
out, and some things are likely to change. It only makes sense to look
at the features for which broad consensus exists.
So, what is agreed upon in the ES6 spec? I would answer this by
mentioning the parts of ES6 that folks are working on both for
SpiderMonkey and for V8. These are:
1. Block-scoped `let' and `const'
(https://bugs.webkit.org/show_bug.cgi?id=31813)
2. typeof 'null' - 'null', not 'object'
3. Proxies
4. Collections (maps, sets, weak maps)
Things that are not implemented by multiple JS engines, but otherwise
are close to agreement:
5. Modules
6. Destructuring binding
7. Parameter default values, rest parameters
8. Quasi-literals
9. Generators, iterators, comprehensions
10. Binary data
Things that will probably change:
11. Classes, |, .{
See http://wiki.ecmascript.org/doku.php?id=harmony:proposals for more
information.
V8 currently compiles in support for 1-4, but disabled behind a runtime
flag. I think that with the nightly Chromium builds you can run it with
--harmony to enable these features. Modules are being worked on for V8,
but not finished AFAIK.
* * *
One big problem for ES6 is how to get there from here: how to enable
the new language features without breaking the web. The current answer
is to define a new mode, and allow code to opt-in to that mode.
Recall that ES5 defines strict mode, a new mode of execution for JS.
Let's call the other mode classic mode. ES6 defines a third extended
mode, which builds on strict mode, and enables the new features.
ES6 does not yet define how extended mode is entered, however. Some ES6
functionality is incompatible both with classic mode and with strict
mode, so it has to be an opt-in thing, perhaps via script
type=application/ecmascript;version=6.
However, there is a subset of ES6 that is compatible with strict-mode.
I am interested in implementing parts of this set. Specifically, I am
interested in implementing block-scoped `let' and `const'.
I think it would be fine to enable the compatible subset of ES6 within
all strict-mode code. It would not be incompatible with existing code
on the web. V8 seems likely to go in this direction as well, and
SpiderMonkey already has done so. Effectively, strict mode could become
compatible extended mode, globally.
Compatible extended mode is not a point we need to decide now,
however. Implementation work towards agreed-upon parts of ES6 is useful
in any eventuality.
Now, it is fine enough to have an implementation of parts of ES6 behind
an #ifdef. I think though that we should get to the point that the
#ifdef is on by default, then removed entirely. We still need a bit to
indicate at parse-time whether a piece of code is extended-mode or
strict-mode. It does not seem that we need a runtime extended-mode bit,
though, as we do with strict-mode vs classic-mode.
My current approach to this, given that the ES6 draft doesn't specify
how to enter extended mode, is to provide a global flag that turns
strict mode into compatible extended mode.
So, those are my thoughts on this. Your feedback is welcome. I hope to
have a block scope implementation finished by mid-january or so; follow
https://bugs.webkit.org/show_bug.cgi?id=31813, for more information.
Regards,
Andy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
Re: [webkit-dev] How to use ASSERT_NO_EXCEPTION
On Thu, Dec 15, 2011 at 8:36 AM, Darin Adler da...@apple.com wrote: ExceptionCode ec; appendChild(newChild, ec); ASSERT(!ec); Often code like this indicates misuse of DOM API functions for internal purposes. This is inefficient (due to exception related checking and other spec mandated behaviors) and architecturally bad (ties our internal data structures to DOM way of presenting them, see stylesheet related classes). I'm not sure it is a good idea to make these cases less visible. antti ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore and ES6
On Thu, 2011-12-15 at 10:36 -0800, Adam Barth wrote: I would caution you about adding more modes to ECMAScript. I agree. You probably know this, but I just realized that my original mail could have implied that I'm on TC39, which is not the case. Just making that particular point clear. :) Cheers, Andy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore and ES6
As you probably know, the ECMA TC39 committee is slowly approaching consensus on a new revision of the ECMAScript language. The interim results of this process have gone under various names: Harmony, ES.next, and ES6. They are the same thing. Hi Andy, one nit to pick: Harmony is the full post-ES4 agenda, not just what fits in any one edition. So ES.next is a subset of Harmony, and we talk about proposals being in Harmony vs. strawman. We consider strawman proposals that won't make ES.next, even as we work to finalize ES.next. We may reorder proposals to correct mistaken priorities or stale decisions. We try to look at the big picture and follow the hermeneutic spiral. Harmony is also an approach to evolving JS (a shared set of requirements, goals, technical values and aesthetics if you will), as well as a set of evolving proposals that span future editions. See http://wiki.ecmascript.org/doku.php?id=harmony:harmony for requirements and more links. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] sheriffbot needs a kick
The sheriffbot has been failing to handle rollout commands for a few days now. The failures reported are: sheriffbot: Exception executing command: Failed to run ['Tools/Scripts/update-webkit'] exit_code: 9 Looks to me like the workspace on the machine running sheriffbot needs to be blown away. Adam, could you please look into this? Thanks, -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] sheriffbot needs a kick
I'll take a look. Sorry for the disruption. Adam On Thu, Dec 15, 2011 at 4:24 PM, Kenneth Russell k...@google.com wrote: The sheriffbot has been failing to handle rollout commands for a few days now. The failures reported are: sheriffbot: Exception executing command: Failed to run ['Tools/Scripts/update-webkit'] exit_code: 9 Looks to me like the workspace on the machine running sheriffbot needs to be blown away. Adam, could you please look into this? Thanks, -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] sheriffbot needs a kick
I believe this is cleared up now. In the future, you can send sheriffbot the restart command, which can often clear up these sorts of issues: sheriffbot: restart I've just now made that command beefier so that it should be able to fix more problems. Adam On Thu, Dec 15, 2011 at 4:26 PM, Adam Barth aba...@webkit.org wrote: I'll take a look. Sorry for the disruption. Adam On Thu, Dec 15, 2011 at 4:24 PM, Kenneth Russell k...@google.com wrote: The sheriffbot has been failing to handle rollout commands for a few days now. The failures reported are: sheriffbot: Exception executing command: Failed to run ['Tools/Scripts/update-webkit'] exit_code: 9 Looks to me like the workspace on the machine running sheriffbot needs to be blown away. Adam, could you please look into this? Thanks, -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] sheriffbot needs a kick
Great, thanks. I vaguely recall seeing somebody restart it on IRC but it seemed to not fix this particular problem. BTW, thanks for writing and maintaining it; it's a very useful tool as evidenced by how many people were trying and failing to use it recently. :) -Ken On Thu, Dec 15, 2011 at 4:46 PM, Adam Barth aba...@webkit.org wrote: I believe this is cleared up now. In the future, you can send sheriffbot the restart command, which can often clear up these sorts of issues: sheriffbot: restart I've just now made that command beefier so that it should be able to fix more problems. Adam On Thu, Dec 15, 2011 at 4:26 PM, Adam Barth aba...@webkit.org wrote: I'll take a look. Sorry for the disruption. Adam On Thu, Dec 15, 2011 at 4:24 PM, Kenneth Russell k...@google.com wrote: The sheriffbot has been failing to handle rollout commands for a few days now. The failures reported are: sheriffbot: Exception executing command: Failed to run ['Tools/Scripts/update-webkit'] exit_code: 9 Looks to me like the workspace on the machine running sheriffbot needs to be blown away. Adam, could you please look into this? Thanks, -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] sheriffbot needs a kick
Yes, before the changes I made just now, the restart command wasn't powerful enough to clear out the problem. Hopefully the new beefier restart will work better in the future. (Mostly I mentioned the restart command so that more folks would know about it and give it a try when they run into trouble.) Adam On Thu, Dec 15, 2011 at 5:16 PM, Kenneth Russell k...@google.com wrote: Great, thanks. I vaguely recall seeing somebody restart it on IRC but it seemed to not fix this particular problem. BTW, thanks for writing and maintaining it; it's a very useful tool as evidenced by how many people were trying and failing to use it recently. :) -Ken On Thu, Dec 15, 2011 at 4:46 PM, Adam Barth aba...@webkit.org wrote: I believe this is cleared up now. In the future, you can send sheriffbot the restart command, which can often clear up these sorts of issues: sheriffbot: restart I've just now made that command beefier so that it should be able to fix more problems. Adam On Thu, Dec 15, 2011 at 4:26 PM, Adam Barth aba...@webkit.org wrote: I'll take a look. Sorry for the disruption. Adam On Thu, Dec 15, 2011 at 4:24 PM, Kenneth Russell k...@google.com wrote: The sheriffbot has been failing to handle rollout commands for a few days now. The failures reported are: sheriffbot: Exception executing command: Failed to run ['Tools/Scripts/update-webkit'] exit_code: 9 Looks to me like the workspace on the machine running sheriffbot needs to be blown away. Adam, could you please look into this? Thanks, -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
