Access Windows system variable from chrome JavaScript

[Malintha Adikari]

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://lists.mozilla.org/listinfo/dev-platform

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

[Jason Duell]

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 avoiding doing any clean
up until we need more space than is available. After that, each job
would still end up cleaning up roughly one objdir to clean up enough
space to run.

Why can't you move it, then spawn a background thread to remove it at
minimum priority?  IIUC, Vista and later support I/O prioritization,


Brian Bondy just added I/O prioritization to our code that removes 
corrupt HTTP caches, in bug 773518, in case that code helps.


Jason


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

STR Needed Keyword?

[Anthony Hughes]

(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 are wanted. I find it 
to be extremely useful when someone requesting qawanted pairs it with a keyword 
indicating what is being requested. It's certainly more efficient then having 
to parse the comments to interpret the request.

Assuming support for such a keyword here are some proposed names:
 * steps-wanted
 * str-wanted
 * needSTR
 * need-steps

Would people find this keyword useful? If so, I can file a bug to get it added.

Thanks

Anthony Hughes
Quality Engineer
Mozilla Corporation


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Kyle Huey]

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 browser engines start to use
>> our tests (and hopefully share theirs with us as well).
>>
>
> Is there a concrete plan for getting other browsers to run these shared
> tests?
>
> The basic idea here sounds worthy, but one concern is that our own tests
> are often unreliable in our own browser -- and I'd expect that to only get
> worse as other browsers and their tests enter the picture. I'd therefore
> suggest that a successful cross-browser test effort should prioritize
> getting stuff running (even with just a handful of tests)... That way fun
> problems like reliability have a chance to be found/fixed over time,
> instead of having a megatestsuite suddenly appear that's unappealing to get
> working.


That's not really true.  Most of our mochitests and reftests are pretty
solid.  I don't think reliability will be a huge issue, and reliability
problems due to bad tests can be fixed quite easily.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Justin Dolske]

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 with us as well).


Is there a concrete plan for getting other browsers to run these shared 
tests?


The basic idea here sounds worthy, but one concern is that our own tests 
are often unreliable in our own browser -- and I'd expect that to only 
get worse as other browsers and their tests enter the picture. I'd 
therefore suggest that a successful cross-browser test effort should 
prioritize getting stuff running (even with just a handful of tests)... 
That way fun problems like reliability have a chance to be found/fixed 
over time, instead of having a megatestsuite suddenly appear that's 
unappealing to get working.


Justin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[james]

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 
> 
> subjective and depends on what the author of the test is used to see.


As the original author of testharness.js this is one style choice I feel I can 
defend. The API is indeed relatively large – but no more so than the typical 
JUnit inspired framework – but this design has substantial benefits, and it is 
easy to ignore the parts that you aren't using.

The typical test format we used at Opera before testharness.js was exceedingly 
lightweight/liberal; it basically has a single function that takes a boolean 
indicating whether the test passed. Sadly this makes the tests very 
inconsistent and hard to read because every one is a special snowflake that 
does its own validation logic. This requires lots of code, often duplicated 
across tests, that is not really related to the thing under test but is needed 
to validate the results. It also means that every author makes their own 
decisions about how to do various kinds of test e.g. checking the right 
exception was thrown by a DOM method.

The advantage of having a richer API is that it brings rigor and consistency to 
tests. By far the most common assertion in testharness.js is assert_equals. 
Even this simple method is a win compared to having people write their own 
equality test because it will always use strict equality. 

For more complex cases where the logic needed to make the test correct is more 
involved the benefits are correspondingly greater e.g. assert_array_equals 
removes the need for an explicit loop cluttering up the test itself and 
assert_throws has some relatively complex logic to handle checking the expected 
properties of DOM and ECMAScript exceptions. 

If test authors were left to reimplement on an ad-hoc basis the assertions that 
testharness.js provides built-in tests would be harder to read, less 
consistent, and more prone to error. That seems well worth the cost of a having 
such a rich API.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Pedro Bessa]

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 the programming language that you should use
must be ready for prime time, in other words, not alpha, so
Rust can't be used.
Pedro, are you trolling or serious? We are designing Rust to meet our 
specific needs for a functional programming language because none of 
the existing languages were suitable candidates, especially about 
native compiled speed, C interop, and strong typesafety.


Rewriting our codebase in a functional language is not a short-term 
operation: it's worth doing right.


--BDS


Since there's no functional programming language with the three
features that you mentioned, it looks to me like you'll have to go
with C or C++.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Neil]

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 to see.


I don't know whether we do a lot of regexp matching but if we did I 
would want it to use a dedicated method. I implemented ise because 
having an entire test reporting via ok(foo === bar, "foo was not exactly 
equal to bar"); does not make for good debugging. (Sadly I still wasn't 
able to work out why the test was failing and had to unCC myself from 
the bug again. (No it wasn't my test.))


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[William Lachance]

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 to determine which areas we needed
to optimize:

http://brasstacks.mozilla.com/gofaster/#/buildcharts


Very nice. If you are accepting feature requests, I think the most
helpful would be checkboxes to filter hardware platforms. It's kind of
hard sorting through everything when all the platforms are mixed together.


We have a bugzilla component for filing these sorts of things (though 
note that AFAIK no one's actively working on the dashboard atm):


https://bugzilla.mozilla.org/enter_bug.cgi?component=GoFaster&product=Testing

I do agree that more filtering options would be useful. I think the 
first thing to do would be to confirm the data in these charts is valid 
though.



I would also like to see hardware utilization in this chart somehow. If
a build step is consuming all local hardware resources (mainly CPU and
I/O), that is a completely different optimization strategy from one
where we are not fully utilizing local capacity or are waiting on
external resources, such as those on a network.


I'm not sure if this works at all anymore, but it used to be that you 
could click on a particular build to get the breakdown of the amount of 
time spent on any particular step. We could certainly do a similar thing 
with hardware utilization -- just a matter of getting the information 
available somewhere we can access it (we used elastic search for the 
build steps).


Will
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ehsan Akhgari]

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 more complicated to export our tests
to the official W3C test suite, right?  As long as we solve that problem
in a locaton-agnostic way, we should be fine.


I would imagine having a manifest somewhere which points to the tests 
which can be submitted would solve that problem, right?


Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Pedro Bessa]

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 the programming language that you should use
must be ready for prime time, in other words, not alpha, so
Rust can't be used.
Pedro, are you trolling or serious? We are designing Rust to meet our 
specific needs for a functional programming language because none of 
the existing languages were suitable candidates, especially about 
native compiled speed, C interop, and strong typesafety.


Rewriting our codebase in a functional language is not a short-term 
operation: it's worth doing right.


--BDS


C interop is a killer feature! I'm going to try changing a part of
the Firefox codebase from C++ to Rust.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert Kaiser]

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 Windows sucks when you are using the POSIX APIs instead of the Win32
ones.


From all I heard so far, the truth is in the middle of your and Mike's 
position. I/O on Windows sucks, but it sucks even more when you are 
using POSIX APIs on top of it.


An interesting data point is that the Wine team found out that running 
tests involving file/disk I/O are significantly slower on native Windows 
than on Wine-on-Linux on the same hardware. This implies that Windows 
I/O really sucks already by itself (and I know from my own experience 
how painful it is even with native Windows applications to delete larger 
trees, even more so when they are VMs, which we have eliminated from out 
build pools nowadays, though). Emulating POSIX upon that already slow 
I/O makes it even worse, though.


Robert Kaiser

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[L. David Baron]

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 doing.

I think the key to making it work is figuring out how to distribute
the knowledge effectively in the Mozilla community.  This requires
educating Mozilla module owners and code reviewers about the testing
guidelines for W3C tests.  Some of this can be done by written
documentation, but some of it, I think, can only be taught through
review and feedback cycles.  In some cases, this means getting
reasonably rapid feedback (from other browser vendors or others
involved in W3C testing efforts) on submitted tests so that people
at Mozilla who are writing tests can learn, through rapid feedback,
what's required of tests submitted to W3C groups.

That said, some test reviews in the W3C space tend to be
unnecessarily nitpicky.  I think we need to be careful to filter the
review feedback appropriately for the change requests that are
actually motivated by real testing needs, and to push back on the
others so that the amount of information that we need to distribute
through the Mozilla community is not too large.

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla   http://www.mozilla.org/   𝄂
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[L. David Baron]

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 ?  If that is the case,
> >the API looks a lot heavier weight than the default mochitest API we
> >use.  In that case, would it make sense for us to have a compatibility
> >layer which translates our mochitest APIs to the equivalent
> >testharness.js API calls?  (I'm not 100% sure if that conversion would
> >be straightforward.)
> 
> I don't feel it's terribly heavyweight. In the simple case, you need a
> 
> test(function() {
>   // tests
> });
> 
> That's two extra lines of boilerplate. Our mochitest boilerplate is…
> (*looks it up*) 30 lines. I think we'll deal. The method names for
> assertions (assert_*) are a bit longer than we're used to, but in my
> experience, you get used to it rather quickly.

It's two extra lines of boilerplate if you only have one test in the
file.

But if you have many tests in the file, it's a lot more, since each
test needs to be wrapped in this -- at least in my understanding.
Some browser vendors (e.g., Opera) seem to care quite strongly that
each test file always execute the same number of tests in the same
order -- even if some of those tests fail by throwing an exception.
So my understanding is that the intent here is that *each* test be
wrapped this way, presumably along with anything that might throw an
exception.  (That said, I think this "might throw" concept is rather
loose.)

I think it's probably worth writing tests this way because of the
value of sharing them.  But I wouldn't minimize that it is more
overhead.



One other characteristic of tests to be submitted to the W3C that's
rather important is that they fail when the feature isn't
implemented.  If this isn't true, then people will build tables that
show a feature as being partially implemented, etc.  (It's
particularly bad if, say, all but one of a large set of tests that
mostly test error handling actually pass when the feature isn't
implemented.)

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla   http://www.mozilla.org/   𝄂
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ms2ger]

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 beginning
of ?  If that is the case,
the API looks a lot heavier weight than the default mochitest API we
use.  In that case, would it make sense for us to have a compatibility
layer which translates our mochitest APIs to the equivalent
testharness.js API calls?  (I'm not 100% sure if that conversion would
be straightforward.)


I don't feel it's terribly heavyweight. In the simple case, you need a

test(function() {
   // tests
});

That's two extra lines of boilerplate. Our mochitest boilerplate is…
(*looks it up*) 30 lines. I think we'll deal. The method names for
assertions (assert_*) are a bit longer than we're used to, but in my
experience, you get used to it rather quickly.


I was not necessarily talking about the size of the boilerblate.  I was
mostly talking about the size of the API.  The mochitest API is
considerably smaller than testharness.js, and is therefore easier to
read and learn, I think.


I don't really agree that the API is much larger; it's just that all the 
assert_* functions are documented, unlike the various functions we 
expose to mochitests.


It's of course true that this is another API to learn, but I don't think 
it's significantly harder than the mochitest API for people who don't 
yet know either.



IMO, it would not be a good idea to try to layer another API on top of
this, because it makes our tests harder to understand and less reusable
by other browser vendors, and it means that experience with our brand of
testharness.js doesn't help much to understand the standard brand.


I would agree if the mochitest API was also huge.  We're basically
talking about 3 functions: is, is_not and ok.  I don't agree that using
these functions would make our tests any less usable by other browser
vendors.  But I understand that in their eyes, these functions may not
be as intuitive as in mine.  :-)


How about 
SimpleTest.ise()/isa()/typeOf()/isDeeply()/waitForExplicitFinish()/finish()/executeSoon()/expectUncaughtException()/…?


I would argue that functions like assert_regexp_match don't get in your 
way if you don't use them, just like SimpleTest.isDeeply() never gets in 
my way when writing mochitests. In general, assert_{true,false}, 
assert_{equals,not_equals} and maybe assert_throws are, in my 
experience, sufficient for most test.



I also don't think it would be terribly straightforward, and I think
that having real mochitests, testharness.js-that-look-like-mochitest and
standard testharness.js in our tree would make our testing situation
more confusing than the lessened learning curve would be worth. In
particular, having two APIs that superficially look the same but are
actually built on unrelated frameworks seems a recipe for a lot of
annoying differences in edge cases.


Hrm, which edge cases are you talking about?  Let's talk about is(a, b,
"msg") for example.  Why do you think there would be cases where calling
is() is less understandable or more error prone than assert_equals?


Excellent example: is(undefined, null) passes, assert_equals(undefined, 
null) fails.


However, I was thinking more about the fact that mochitest watches 
window.onerror, while testharness.js catches exceptions from the 
functions you pass to test(). To me, it seems easier to make sure you 
use two different-looking APIs correctly, than to make sure you've got 
the right API when one tries to disguise as the other.



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 to see.


I wouldn't disagree.

HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XUL Runner, and the future.

[Dave Townsend]

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 true. It's not tier1, but we ship it with every
release and beta. However, I'd be surprised if there was any
guarantee that it will exist in 5-10y though.


I think it's true. We don't have any automated tests that verify that
the build works beyond compiling and it was totally failing on most
platforms for 2-3 releases. Right now there are a couple of us that
attempt to keep it going but I have no idea how long that will last.

Thankfully XULRunner is a simple enough extension of the core pieces
of Firefox that the potential for breakage is pretty small, this is
probably the only reason it is still alive. I'm not sure its chances
are good if we make a change that requires a lot of work to keep
XULRunner working.


Aren't there linux distros trying to ship Firefox + Thunderbird +
XULRunner?

Sadly I doubt we have the capacity, but I would have thought that all
our existing tests should work just as well on a Firefox/Thunderbird +
XULRunner build as on a monolithic build.


That would be possible yeah, but yes it would increase the load. Really 
all it would take is a couple of simple XUL applications checked into 
the tree that report that they start up ok. That would be enough to have 
detected the issues I've seen in the past, but no-one has time to work 
on it (and hasn't since XULRunner's inception).


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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 official W3C test suite, right?  As long as we solve that problem 
in a locaton-agnostic way, we should be fine.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ehsan Akhgari]

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 ?  If that is the case,
the API looks a lot heavier weight than the default mochitest API we
use.  In that case, would it make sense for us to have a compatibility
layer which translates our mochitest APIs to the equivalent
testharness.js API calls?  (I'm not 100% sure if that conversion would
be straightforward.)


I don't feel it's terribly heavyweight. In the simple case, you need a

test(function() {
   // tests
});

That's two extra lines of boilerplate. Our mochitest boilerplate is…
(*looks it up*) 30 lines. I think we'll deal. The method names for
assertions (assert_*) are a bit longer than we're used to, but in my
experience, you get used to it rather quickly.


I was not necessarily talking about the size of the boilerblate.  I was 
mostly talking about the size of the API.  The mochitest API is 
considerably smaller than testharness.js, and is therefore easier to 
read and learn, I think.



IMO, it would not be a good idea to try to layer another API on top of
this, because it makes our tests harder to understand and less reusable
by other browser vendors, and it means that experience with our brand of
testharness.js doesn't help much to understand the standard brand.


I would agree if the mochitest API was also huge.  We're basically 
talking about 3 functions: is, is_not and ok.  I don't agree that using 
these functions would make our tests any less usable by other browser 
vendors.  But I understand that in their eyes, these functions may not 
be as intuitive as in mine.  :-)



I also don't think it would be terribly straightforward, and I think
that having real mochitests, testharness.js-that-look-like-mochitest and
standard testharness.js in our tree would make our testing situation
more confusing than the lessened learning curve would be worth. In
particular, having two APIs that superficially look the same but are
actually built on unrelated frameworks seems a recipe for a lot of
annoying differences in edge cases.


Hrm, which edge cases are you talking about?  Let's talk about is(a, b, 
"msg") for example.  Why do you think there would be cases where calling 
is() is less understandable or more error prone than assert_equals?


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 to see.



2. Is there any support for running reftest-style tests in a framework
that is reusable by other browsers?  If not, can we move to propose the
reftest framework to the appropriate standards bodies so that it can be
adopted by other browsers?  Our reftest framework has been carefully
designed to be Gecko-agnostic, and is much superior to the equivalent
testing framework that WebKit has (not sure about other browser
engines).  Furthermore, the files loaded by this framework are not
loaded in a privileged context with APIs such as SpecialPowers, which
makes a large number of them portable to other browser engines.


The W3C has already adopted reftests. See

for example.

In fact, we've already got a place in m-c to put reftests to be
submitted to the CSSWG:
.


Oh, that's good news!  Thanks for the pointer.


The main issue here is that the CSSWG appears to impose rather stringent
test formatting requirements, which makes writing reftests for them much
more of a drag than just writing them for ourselves.


I'm assuming that you're talking about 
.  Yeah, that's quite verbose and 
cumbersome.  :(



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 with us as well).


Opera already shares a lot of their tests, and Google, Apple and
Microsoft have been known to submit tests as well, some of which are
already running on tinderbox.


Great!

Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ehsan Akhgari]

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
eventually start giving r- for tests written in the wrong format or
put in the wrong place, although it would make sense to phase the
requirement in over time and not be too strict at first.  Test writers
do not have to bother actually publishing them -- they just have to
write them in the correct format and put them in the correct directory
in the source tree.

I agree with the first 3 points, but I object rather strongly to this
one. I think we should try to keep the tests close to the relevant code
whenever possible; this makes it more clear which module owner is
responsible for the test, and makes it easier to find and run the
relevant tests when modifying code. I think our system should try to
keep this style of tests in the code module.


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.


Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ms2ger]

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 looks a lot heavier weight than the default mochitest API we
use.  In that case, would it make sense for us to have a compatibility
layer which translates our mochitest APIs to the equivalent
testharness.js API calls?  (I'm not 100% sure if that conversion would
be straightforward.)


I don't feel it's terribly heavyweight. In the simple case, you need a

test(function() {
  // tests
});

That's two extra lines of boilerplate. Our mochitest boilerplate is… 
(*looks it up*) 30 lines. I think we'll deal. The method names for 
assertions (assert_*) are a bit longer than we're used to, but in my 
experience, you get used to it rather quickly.


IMO, it would not be a good idea to try to layer another API on top of 
this, because it makes our tests harder to understand and less reusable 
by other browser vendors, and it means that experience with our brand of 
testharness.js doesn't help much to understand the standard brand.


I also don't think it would be terribly straightforward, and I think 
that having real mochitests, testharness.js-that-look-like-mochitest and 
standard testharness.js in our tree would make our testing situation 
more confusing than the lessened learning curve would be worth. In 
particular, having two APIs that superficially look the same but are 
actually built on unrelated frameworks seems a recipe for a lot of 
annoying differences in edge cases.



2. Is there any support for running reftest-style tests in a framework
that is reusable by other browsers?  If not, can we move to propose the
reftest framework to the appropriate standards bodies so that it can be
adopted by other browsers?  Our reftest framework has been carefully
designed to be Gecko-agnostic, and is much superior to the equivalent
testing framework that WebKit has (not sure about other browser
engines).  Furthermore, the files loaded by this framework are not
loaded in a privileged context with APIs such as SpecialPowers, which
makes a large number of them portable to other browser engines.


The W3C has already adopted reftests. See 
 
for example.


In fact, we've already got a place in m-c to put reftests to be 
submitted to the CSSWG: 
.


The main issue here is that the CSSWG appears to impose rather stringent 
test formatting requirements, which makes writing reftests for them much 
more of a drag than just writing them for ourselves.



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 with us as well).


Opera already shares a lot of their tests, and Google, Apple and 
Microsoft have been known to submit tests as well, some of which are 
already running on tinderbox.


HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 the wrong format or
put in the wrong place, although it would make sense to phase the
requirement in over time and not be too strict at first.  Test writers
do not have to bother actually publishing them -- they just have to
write them in the correct format and put them in the correct directory
in the source tree.
I agree with the first 3 points, but I object rather strongly to this 
one. I think we should try to keep the tests close to the relevant code 
whenever possible; this makes it more clear which module owner is 
responsible for the test, and makes it easier to find and run the 
relevant tests when modifying code. I think our system should try to 
keep this style of tests in the code module.




5) Make sure someone is keeping an eye on the reusable-tests
directory, and submitting the tests as appropriate to somewhere where
they can be easily reused.  This might involve submitting some of them
to standards bodies for formal approval.  Other tests might not
currently follow any standard, but could still be imported by other
browsers to test for crashes or assertions, or to flag possible
regressions.  Those tests might not be moved anywhere special, but
should still be easier for other browsers to reuse than they are now.
Why do you think it would be better to have (somebody == Ms2ger) do 
this, instead of expecting module owners in general to be a part of this 
task? It feels to me that module owners should primarily be trying to 
accomplish this sort of thing, and if they need help figuring out the 
right standards body, asking for help from Ms2ger or other experts is a 
great fallback plan.


Given the recent discussion about QA, it feels like this would also be a 
great thing to involve QA in.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ehsan Akhgari]

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 mochitest API we 
use.  In that case, would it make sense for us to have a compatibility 
layer which translates our mochitest APIs to the equivalent 
testharness.js API calls?  (I'm not 100% sure if that conversion would 
be straightforward.)


2. Is there any support for running reftest-style tests in a framework 
that is reusable by other browsers?  If not, can we move to propose the 
reftest framework to the appropriate standards bodies so that it can be 
adopted by other browsers?  Our reftest framework has been carefully 
designed to be Gecko-agnostic, and is much superior to the equivalent 
testing framework that WebKit has (not sure about other browser 
engines).  Furthermore, the files loaded by this framework are not 
loaded in a privileged context with APIs such as SpecialPowers, which 
makes a large number of them portable to other browser engines.


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 with us as well).


Cheers,
Ehsan

On 12-08-16 5:31 AM, Aryeh Gregor wrote:

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 our conformance to web standards that other
UAs implement.  Unfortunately, new tests are as a rule written in very
Mozilla-specific formats.  I think we would do a better job of
fulfilling our mission to advance the web if we made more of an effort
to write our tests in such a way that other UAs could more easily use
them, where relevant.  I believe we could do this without
significantly increasing the burden on test-writers.

To that end, I suggest the following course of action:

1) Decide on guidelines for whether a test is internal or reusable.
As a starting point, I suggest that all tests that are regular
webpages that don't use any Mozilla-specific features should be
candidates for reuse.  Examples of internal tests would be tests
written in XUL and unit tests.  In particular, I think we should write
tests for reuse if they cover anything that other browsers implement
or might implement, even if there's currently no standard for it.
Other browsers should still be able to run these tests, even if they
might decide not to follow them.  Also, tests that currently use
prefixed web-exposed properties should still be made reusable, since
the properties should eventually be unprefixed.

2) Write an introduction to testharness.js targeted at people familiar
with mochitest.  testharness.js is the de facto standard testing
harness in the web standards world, and we already can run such tests
as mochitests automatically (see dom/imptests/), so JavaScript tests
meant to be usable by other browsers should be written in that format.

3) Require that all new tests that qualify as reusable must be written
in testharness.js format rather than mochitest format if possible.
(Reftests and crashtests can remain as-is, IMO.  Some mochitests might
not be possible to rewrite as testharness.js yet, e.g., those using
SpecialPowers, so I guess they can stay mochitests for now.)

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 the wrong format or
put in the wrong place, although it would make sense to phase the
requirement in over time and not be too strict at first.  Test writers
do not have to bother actually publishing them -- they just have to
write them in the correct format and put them in the correct directory
in the source tree.

5) Make sure someone is keeping an eye on the reusable-tests
directory, and submitting the tests as appropriate to somewhere where
they can be easily reused.  This might involve submitting some of them
to standards bodies for formal approval.  Other tests might not
currently follow any standard, but could still be imported by other
browsers to test for crashes or assertions, or to flag possible
regressions.  Those tests might not be moved anywhere special, but
should still be easier for other browsers to reuse than they are now.


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 n

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

[Ben Hearsum]

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
>>> fresh new one is created. The older one could be removed much later.
>>
>> 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 space than is available. After that, each job
>> would still end up cleaning up roughly one objdir to clean up enough
>> space to run.
> 
> If the cleanup happened at the end of the build, rather than at the
> beginning, tests could start earlier.

Good point. This won't help much when we have long wait times, but I
filed https://bugzilla.mozilla.org/show_bug.cgi?id=783253 on it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ben Hearsum]

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 avoiding doing any clean
>> up until we need more space than is available. After that, each job
>> would still end up cleaning up roughly one objdir to clean up enough
>> space to run.
> 
> Why can't you move it, then spawn a background thread to remove it at
> minimum priority?  IIUC, Vista and later support I/O prioritization,
> and the lowest priority will throttle down to two I/O's a second if
> other I/O is happening.  Or are build slaves already I/O-saturated?
> 

I hadn't considered using a background thread to remove it. During
pulling/update we're I/O-saturated, I'm not sure about during compile.
Implementing this would be very tricky thoughthe way the build works
is by executing commands serially, so I'm not sure how we'd do this in
parallel with compilation. There's probably a way, but we'd have to be
reasonably sure it's useful to do before diving deeper, I think.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Mike Hommey]

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 be removed much later.
> 
> 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 space than is available. After that, each job
> would still end up cleaning up roughly one objdir to clean up enough
> space to run.

If the cleanup happened at the end of the build, rather than at the
beginning, tests could start earlier.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Aryeh Gregor]

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 space than is available. After that, each job
> would still end up cleaning up roughly one objdir to clean up enough
> space to run.

Why can't you move it, then spawn a background thread to remove it at
minimum priority?  IIUC, Vista and later support I/O prioritization,
and the lowest priority will throttle down to two I/O's a second if
other I/O is happening.  Or are build slaves already I/O-saturated?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XUL Runner, and the future.

[Ben Hearsum]

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 true. It's not tier1, but we ship it with every
>> release and beta. However, I'd be surprised if there was any guarantee
>> that it will exist in 5-10y though.
> 
> I think it's true.

We're probably just quibbling over terminology at this point, but
"unsupported" to me means we wouldn't bother fixing it if it broke,
which isn't the case.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ben Hearsum]

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 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 space than is available. After that, each job
would still end up cleaning up roughly one objdir to clean up enough
space to run.

A common technique for dealing with this on Windows is to have a
dedicated partition for the builds, and to format it on start-up rather
than delete things, because a quick format is much quicker than
deleting. I don't think it's something RelEng could implement quickly,
but might be worthwhile looking at in the longer term.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XUL Runner, and the future.

[Martin Stransky]

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 is true. It's not tier1, but we ship it with every
release and beta. However, I'd be surprised if there was any
guarantee that it will exist in 5-10y though.


I think it's true. We don't have any automated tests that verify that
the build works beyond compiling and it was totally failing on most
platforms for 2-3 releases. Right now there are a couple of us that
attempt to keep it going but I have no idea how long that will last.

Thankfully XULRunner is a simple enough extension of the core pieces
of Firefox that the potential for breakage is pretty small, this is
probably the only reason it is still alive. I'm not sure its chances
are good if we make a change that requires a lot of work to keep
XULRunner working.


Aren't there linux distros trying to ship Firefox + Thunderbird +
XULRunner?

Sadly I doubt we have the capacity, but I would have thought that all
our existing tests should work just as well on a Firefox/Thunderbird +
XULRunner build as on a monolithic build.



Yes we still ship Xulrunner in Fedora/RHEL, for the SDK and future 
Thunderbird release.


ma.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XUL Runner, and the future.

[Neil]

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 it with every 
release and beta. However, I'd be surprised if there was any 
guarantee that it will exist in 5-10y though.


I think it's true. We don't have any automated tests that verify that 
the build works beyond compiling and it was totally failing on most 
platforms for 2-3 releases. Right now there are a couple of us that 
attempt to keep it going but I have no idea how long that will last.


Thankfully XULRunner is a simple enough extension of the core pieces 
of Firefox that the potential for breakage is pretty small, this is 
probably the only reason it is still alive. I'm not sure its chances 
are good if we make a change that requires a lot of work to keep 
XULRunner working.


Aren't there linux distros trying to ship Firefox + Thunderbird + XULRunner?

Sadly I doubt we have the capacity, but I would have thought that all 
our existing tests should work just as well on a Firefox/Thunderbird + 
XULRunner build as on a monolithic build.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed policy change: reusability of tests by other browsers

[Aryeh Gregor]

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 our conformance to web standards that other
UAs implement.  Unfortunately, new tests are as a rule written in very
Mozilla-specific formats.  I think we would do a better job of
fulfilling our mission to advance the web if we made more of an effort
to write our tests in such a way that other UAs could more easily use
them, where relevant.  I believe we could do this without
significantly increasing the burden on test-writers.

To that end, I suggest the following course of action:

1) Decide on guidelines for whether a test is internal or reusable.
As a starting point, I suggest that all tests that are regular
webpages that don't use any Mozilla-specific features should be
candidates for reuse.  Examples of internal tests would be tests
written in XUL and unit tests.  In particular, I think we should write
tests for reuse if they cover anything that other browsers implement
or might implement, even if there's currently no standard for it.
Other browsers should still be able to run these tests, even if they
might decide not to follow them.  Also, tests that currently use
prefixed web-exposed properties should still be made reusable, since
the properties should eventually be unprefixed.

2) Write an introduction to testharness.js targeted at people familiar
with mochitest.  testharness.js is the de facto standard testing
harness in the web standards world, and we already can run such tests
as mochitests automatically (see dom/imptests/), so JavaScript tests
meant to be usable by other browsers should be written in that format.

3) Require that all new tests that qualify as reusable must be written
in testharness.js format rather than mochitest format if possible.
(Reftests and crashtests can remain as-is, IMO.  Some mochitests might
not be possible to rewrite as testharness.js yet, e.g., those using
SpecialPowers, so I guess they can stay mochitests for now.)

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 the wrong format or
put in the wrong place, although it would make sense to phase the
requirement in over time and not be too strict at first.  Test writers
do not have to bother actually publishing them -- they just have to
write them in the correct format and put them in the correct directory
in the source tree.

5) Make sure someone is keeping an eye on the reusable-tests
directory, and submitting the tests as appropriate to somewhere where
they can be easily reused.  This might involve submitting some of them
to standards bodies for formal approval.  Other tests might not
currently follow any standard, but could still be imported by other
browsers to test for crashes or assertions, or to flag possible
regressions.  Those tests might not be moved anywhere special, but
should still be easier for other browsers to reuse than they are now.


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
bit of infrastructure work, but nothing much.  (1) and (2) are easy,
and I suspect someone like Ms2ger will be happy to handle (5).  But
(3) and (4) need broad agreement from module owners/peers.  Does
anyone have any objections to them?  Once we have a system like this
in place, we can try to persuade other browser vendors to use our
tests, and provide their tests under similar terms.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jason Duell]

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 something.
No clue what happened with that.

I wish this were true, but I seriously doubt it. I can buy that it's
faster, but not 5-10 times so.

http://blog.johnford.org/writting-a-native-rm-program-for-windows/
says that it deleted a mozilla-central clone 3x faster.


And renaming the directory (then deleting it in parallel with the build, 
or later) ought to be some power of ten faster than that, at least from 
the build-time perspective. At least if you don't do anything expensive 
like our nsIFile NTFS renaming goopage (that traverses the directory 
tree making sure NTFS ACLs are preserved for all files).Which most 
versions of 'rm' aren't going to do, I'd guess.


Jason
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Nicholas Nethercote]

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 that.
>
> I wish this were true, but I seriously doubt it. I can buy that it's
> faster, but not 5-10 times so.

http://blog.johnford.org/writting-a-native-rm-program-for-windows/
says that it deleted a mozilla-central clone 3x faster.

https://bugzilla.mozilla.org/show_bug.cgi?id=727551 is the bug
tracking it;  there appear to be some problems blocking progress.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform