Re: Increase in mozilla-inbound bustage due to people not using Try

On Wed, Aug 15, 2012 at 11:41 PM, Mike Hommey wrote: >> >> A few months back, John Ford wrote a standalone win32 executable >> that used the proper APIs to delete an entire directory. I think he >> said that it deleted the object directory 5-10x faster or something. >> No clue what happened with t

Re: Increase in mozilla-inbound bustage due to people not using Try

On 08/16/2012 12:03 AM, Nicholas Nethercote wrote: On Wed, Aug 15, 2012 at 11:41 PM, Mike Hommey wrote: A few months back, John Ford wrote a standalone win32 executable that used the proper APIs to delete an entire directory. I think he said that it deleted the object directory 5-10x faster or

Proposed policy change: reusability of tests by other browsers

Mozilla has a long-standing policy that with certain limited exceptions, all code changes must be accompanied by a test. Following this policy has given us an excellent and steadily growing regression test-suite. Some of these tests are very specific to Mozilla, but a substantial fraction test ou

Re: Increase in mozilla-inbound bustage due to people not using Try

Whenever I need to delete a large directory on Windows I always move it to a junk directory and then rm -rf the junk directory in the background. It saves a lot of time. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray f

Re: XUL Runner, and the future.

Dave Townsend wrote: On 08/15/12 12:41, Ben Hearsum wrote: On 08/15/12 02:57 PM, Justin Wood (Callek) wrote: XULRunner is currently an unsupported piece of software, we don't run tests for it, and we *barely* ensure it still builds. I don't think this is true. It's not tier1, but we ship i

Re: XUL Runner, and the future.

On 08/16/2012 12:51 PM, Neil wrote: Dave Townsend wrote: On 08/15/12 12:41, Ben Hearsum wrote: On 08/15/12 02:57 PM, Justin Wood (Callek) wrote: XULRunner is currently an unsupported piece of software, we don't run tests for it, and we *barely* ensure it still builds. I don't think this i

Re: XUL Runner, and the future.

On 08/15/12 05:57 PM, Dave Townsend wrote: > On 08/15/12 12:41, Ben Hearsum wrote: >> On 08/15/12 02:57 PM, Justin Wood (Callek) wrote: >>> XULRunner is currently an unsupported piece of software, we don't run >>> tests for it, and we *barely* ensure it still builds. >> >> I don't think this is tru

Re: Increase in mozilla-inbound bustage due to people not using Try

On 08/16/12 02:10 AM, Mike Hommey wrote: > But maybe we can work around this. At least for rm -rf, instead of > rm -rf'ing before the build, we could move the objdir away so that a > fresh new one is created. The older one could be removed much later. I don't think this would be any more than a on

Re: Increase in mozilla-inbound bustage due to people not using Try

On Thu, Aug 16, 2012 at 4:18 PM, Ben Hearsum wrote: > I don't think this would be any more than a one-time win until the disk > fills up. At the start of each job we ensure there's enough space to do > the current job. By moving the objdir away we'd avoiding doing any clean > up until we need more

Re: Increase in mozilla-inbound bustage due to people not using Try

On Thu, Aug 16, 2012 at 09:18:11AM -0400, Ben Hearsum wrote: > On 08/16/12 02:10 AM, Mike Hommey wrote: > > But maybe we can work around this. At least for rm -rf, instead of > > rm -rf'ing before the build, we could move the objdir away so that a > > fresh new one is created. The older one could b

Re: Increase in mozilla-inbound bustage due to people not using Try

On 08/16/12 09:23 AM, Aryeh Gregor wrote: > On Thu, Aug 16, 2012 at 4:18 PM, Ben Hearsum wrote: >> I don't think this would be any more than a one-time win until the disk >> fills up. At the start of each job we ensure there's enough space to do >> the current job. By moving the objdir away we'd a

Re: Increase in mozilla-inbound bustage due to people not using Try

On 08/16/12 09:33 AM, Mike Hommey wrote: > On Thu, Aug 16, 2012 at 09:18:11AM -0400, Ben Hearsum wrote: >> On 08/16/12 02:10 AM, Mike Hommey wrote: >>> But maybe we can work around this. At least for rm -rf, instead of >>> rm -rf'ing before the build, we could move the objdir away so that a >>> fre

Re: Proposed policy change: reusability of tests by other browsers

I think this is generally a good idea. I have a few questions before jumping in to agree though. 1. Is the current testharness.js API the documentation at the beginning of ? If that is the case, the API looks a lot heavier weight than the default

Re: Proposed policy change: reusability of tests by other browsers

On 8/16/2012 5:31 AM, Aryeh Gregor wrote: 4) Require that all new tests that qualify as reusable must be checked into a specific new directory created for this purpose, rather than someplace near the code as they are currently. Reviewers need to eventually start giving r- for tests written in

Re: Proposed policy change: reusability of tests by other browsers

On 08/16/2012 05:10 PM, Ehsan Akhgari wrote: I think this is generally a good idea. I have a few questions before jumping in to agree though. 1. Is the current testharness.js API the documentation at the beginning of ? If that is the case, the API

Re: Proposed policy change: reusability of tests by other browsers

On 12-08-16 11:25 AM, Benjamin Smedberg wrote: On 8/16/2012 5:31 AM, Aryeh Gregor wrote: 4) Require that all new tests that qualify as reusable must be checked into a specific new directory created for this purpose, rather than someplace near the code as they are currently. Reviewers need to

Re: Proposed policy change: reusability of tests by other browsers

On 12-08-16 11:34 AM, Ms2ger wrote: On 08/16/2012 05:10 PM, Ehsan Akhgari wrote: I think this is generally a good idea. I have a few questions before jumping in to agree though. 1. Is the current testharness.js API the documentation at the beginning of

Re: Proposed policy change: reusability of tests by other browsers

On 8/16/12 12:07 PM, Ehsan Akhgari wrote: I agree with Benjamin here. In fact, I think if we take out item 4 completely Aryeh's proposal still makes sense. Where the tests live in our tree should not really matter. It matters insofar as it makes it more complicated to export our tests to the

Re: XUL Runner, and the future.

On 08/16/12 03:51, Neil wrote: Dave Townsend wrote: On 08/15/12 12:41, Ben Hearsum wrote: On 08/15/12 02:57 PM, Justin Wood (Callek) wrote: XULRunner is currently an unsupported piece of software, we don't run tests for it, and we *barely* ensure it still builds. I don't think this is tru

Re: Proposed policy change: reusability of tests by other browsers

On 08/16/2012 06:21 PM, Ehsan Akhgari wrote: On 12-08-16 11:34 AM, Ms2ger wrote: On 08/16/2012 05:10 PM, Ehsan Akhgari wrote: I think this is generally a good idea. I have a few questions before jumping in to agree though. 1. Is the current testharness.js API the documentation at the beginnin

Re: Proposed policy change: reusability of tests by other browsers

On Thursday 2012-08-16 17:34 +0200, Ms2ger wrote: > On 08/16/2012 05:10 PM, Ehsan Akhgari wrote: > >I think this is generally a good idea. I have a few questions before > >jumping in to agree though. > > > >1. Is the current testharness.js API the documentation at the beginning > >of

Re: Proposed policy change: reusability of tests by other browsers

On Thursday 2012-08-16 12:31 +0300, Aryeh Gregor wrote: > I think that the above won't make anything much harder for our coders, > but will be a big step forward for web testing -- especially if our > example motivates other browsers to do the same. It needs a little I agree that this is worth do

Re: Increase in mozilla-inbound bustage due to people not using Try

Gregory Szorc schrieb: On 8/15/12 11:10 PM, Mike Hommey wrote: What is interesting is that the corresponding times are in the order of seconds on linux and osx. We're just hitting the fact that windows sucks at I/O. That is an over-generalization. I/O on Windows itself does not suck. I/O on Wi

Re: quick! use lisp! before it's too late!

Em 15-08-2012 03:40, Benjamin Smedberg escreveu: On 8/15/2012 2:24 AM, Pedro Bessa wrote: Ian, Mozilla, I thought all fast functional programming languages were Lisp dialects, but that's not true and you can use other fast functional programming languages, but now that you said Rust, I think th

Re: Proposed policy change: reusability of tests by other browsers

On 12-08-16 12:41 PM, Boris Zbarsky wrote: On 8/16/12 12:07 PM, Ehsan Akhgari wrote: I agree with Benjamin here. In fact, I think if we take out item 4 completely Aryeh's proposal still makes sense. Where the tests live in our tree should not really matter. It matters insofar as it makes it

Re: Proposed policy change: reusability of tests by other browsers

On 8/16/12 3:38 PM, Ehsan Akhgari wrote: I would imagine having a manifest somewhere which points to the tests which can be submitted would solve that problem, right? Sure. Just need to maintain that manifest as new tests (or just new test dirs?) are added. -Boris _

Re: Increase in mozilla-inbound bustage due to people not using Try

On 08/15/2012 07:08 PM, Gregory Szorc wrote: When I was working on this project last year, I designed a build charts view to help visualize which parts were taking the longest (you can see implicit dependencies between build/test tasks by seeing when certain jobs run), which proved very helpful

Re: Proposed policy change: reusability of tests by other browsers

Ehsan Akhgari wrote: On the testharness.js side, we have things like assert_regexp_match, for example. I would argue that whether or not assert_regexp_match(a, /foo/, "msg") is more readable than ok(/foo/.match(a), "msg") is very subjective and depends on what the author of the test is used t

Re: quick! use lisp! before it's too late!

Em 15-08-2012 03:40, Benjamin Smedberg escreveu: On 8/15/2012 2:24 AM, Pedro Bessa wrote: Ian, Mozilla, I thought all fast functional programming languages were Lisp dialects, but that's not true and you can use other fast functional programming languages, but now that you said Rust, I think th

Re: Proposed policy change: reusability of tests by other browsers

On Thursday, 16 August 2012 18:21:35 UTC+2, Ehsan Akhgari wrote: > On the testharness.js side, we have things like assert_regexp_match, for > > example. I would argue that whether or not assert_regexp_match(a, > > /foo/, "msg") is more readable than ok(/foo/.match(a), "msg") is very > > sub

Re: Proposed policy change: reusability of tests by other browsers

On 8/16/12 8:10 AM, Ehsan Akhgari wrote: I think it makes sense for us if we can start this effort on the reftest framework, since that has a much lower barrier to entry, and ultimately this effort would be valuable only if other browser engines start to use our tests (and hopefully share theirs

Re: Proposed policy change: reusability of tests by other browsers

On Thu, Aug 16, 2012 at 2:39 PM, Justin Dolske wrote: > On 8/16/12 8:10 AM, Ehsan Akhgari wrote: > > I think it makes sense for us if we can start this effort on the reftest >> framework, since that has a much lower barrier to entry, and ultimately >> this effort would be valuable only if other

STR Needed Keyword?

(CCing dev-quality to reach a broader audience -- please direct responses to dev-platform) It has come to my attention that we lack a keyword in Bugzilla for when steps-to-reproduce are needed (a very common request). However, we do have keywords for when a testcase, regression range, or URLs a

Re: Increase in mozilla-inbound bustage due to people not using Try

On 08/16/2012 06:23 AM, Aryeh Gregor wrote: On Thu, Aug 16, 2012 at 4:18 PM, Ben Hearsum wrote: I don't think this would be any more than a one-time win until the disk fills up. At the start of each job we ensure there's enough space to do the current job. By moving the objdir away we'd avoidin

Access Windows system variable from chrome JavaScript

Hi, I want to access system variable in Windows OS from my firebug extension. Can I do that ? Is it possible to access OS system variables inside the chrome JavaScript ? Thanks ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lis