On 03.06.2014 00:42, Ehsan Akhgari wrote:
Also, I'm not sure where the original discussion happened,
Ditto. For a change that affects pretty much all mozilla-central
hackers, I would have expected a public proposal and a feedback round on
this list.
(My initial reaction was similar to
On Jun 2, 2014, at 12:11 AM, Benoit Jacob jacob.benoi...@gmail.com wrote:
Objection #6:
The determinant() method, being in this API the only easy way to get
something that looks roughly like a measure of invertibility, will probably
be (mis-)used as a measure of invertibility. So I'm quite
Ok. I'll work to integrate sdk version =18 and see if that works.
Just curious as to how it is working in one application. Any idea?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 03/06/14 00:24, Chris Peterson wrote:
On 6/2/14, 3:42 PM, Ehsan Akhgari wrote:
2. I also value consistency more than my personal preferences, and based
on that, using the existing APIs in some tests and the new APIs in other
tests (even if we agreed that #1 above doesn't matter) is strictly
On 03.06.14 10:24, bhargava.animes...@gmail.com wrote:
Ok. I'll work to integrate sdk version =18 and see if that works.
Just curious as to how it is working in one application. Any idea?
Maybe the application where it's working has hardware acceleration
disabled, and it somewhat works by
Rik Cabanier wrote:
Still up for discussion:
- rename isIdentity
My understanding is that you want to use isIdentity/is2D as an
optimisation for known classes of matrix, and what you're really
interested in is if the matrix has had any 2D or 3D transforms applied
to it, even if those
On Wed, May 28, 2014 at 5:45 PM, Nathan Froyd froy...@mozilla.com wrote:
Assuming that ICU is already compiled with the moral equivalent of GCC's
-ffunction-sections -fdata-sections or MSVC's /Gy, then statically linking
ICU into libxul should already strip out all the un-needed ICU bits
From time to time, no matter what platform I use, the build configuration on
the try server changes
and from that point on it's just a matter of time that my build gets broken.
When you're
about to work on some urgent fixes, it can be very frustrating to try and fix
the build instead...
I
I'm not sure I grasp your overall point, but I have a few comments.
On 03/06/14 11:22, Mike de Boer wrote:
1. The `Assert.*` namespace is optional and may be omitted. This
module is also present in the addon-sdk and used _with_ that
namespace, usually with a lowercase `assert.*`. Please pick
Please see my comments inline.
On 03 Jun 2014, at 12:57, James Graham ja...@hoppipolla.co.uk wrote:
I'm not sure I grasp your overall point, but I have a few comments.
On 03/06/14 11:22, Mike de Boer wrote:
1. The `Assert.*` namespace is optional and may be omitted. This
module is also
On 03/06/2014 12:27, Mike de Boer wrote:
snip
5. Assertion semantics are indeed poorly specified, across the board.
Our switch from `do_check_matches()` to `deepEqual()` even revealed a
buggy implementation there, which we didn’t know about. Apart from
that, it was largely undocumented, not
On 03/06/14 12:27, Mike de Boer wrote:
4. None of the test-suites promote modularity and needlessly dictate
a reporting style. What I mean by this is that there’s no way to hook
different reporting styles in a test runner to promote TDD, for
example. What does automation use to detect test
Indeed I meant to say the following:
Taking the CommonJS spec as an umbrella for these simple assertion methods is
more of a nice side-effect than it was the primary objective we started off
with.
I think it helps provide a common, immediate understanding for new contributors
who’d like to
On 6/3/14, 8:39 AM, Mike de Boer wrote:
I think it helps provide a common, immediate understanding for new contributors
who’d like to write test for the code they contribute, as the add-on SDK and
the NodeJS community already use it exclusively.
I think there's a bit of functional area bias
On 6/3/14, 6:22 AM, Mike de Boer wrote:
Their lack of modularity costs us flexibility in adopting and/ or promoting TDD
development.
Mike, I'm very curious about this part. Do you have a link offhand to a
more detailed explanation of the issues here?
Note that none of us think Mochitest
2014-06-02 23:45 GMT-04:00 Rik Cabanier caban...@gmail.com:
To recap I think the following points have been resolved:
- remove determinant (unless someone comes up with a strong use case)
- change is2D() so it's a flag instead of calculated on the fly
- change isIdentity() so it's a flag.
-
On 03 Jun 2014, at 14:54, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/3/14, 8:39 AM, Mike de Boer wrote:
I think it helps provide a common, immediate understanding for new
contributors who’d like to write test for the code they contribute, as the
add-on SDK and the NodeJS community already
On 03 Jun 2014, at 15:07, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/3/14, 8:50 AM, Boris Zbarsky wrote:
I do think we should be very intentional about adopting something new,
both in terms of semantics (mochitest is() using == is a mistake we
should not duplicate in the short-name comparison
On 03 Jun 2014, at 14:50, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/3/14, 6:22 AM, Mike de Boer wrote:
Their lack of modularity costs us flexibility in adopting and/ or promoting
TDD development.
Mike, I'm very curious about this part. Do you have a link offhand to a more
detailed
On 14-06-03 06:39 AM, Gabor Krizsanits wrote:
From time to time, no matter what platform I use, the build configuration on
the try server changes
and from that point on it's just a matter of time that my build gets broken.
When you're
about to work on some urgent fixes, it can be very
I understand all that and I *think* you missed the header mentioning I was
going off-topic…
Mike.
On 03 Jun 2014, at 15:39, Gijs Kruitbosch gijskruitbo...@gmail.com wrote:
On 03/06/2014 14:16, Mike de Boer wrote:
Indeed, I’m used to the NodeJS/ Mocha flow of writing tests as fast, or even
I don't think this is off-topic. I'm essentially asking: why did you
focus on this, and why in this way? More broadly, I'm asking what it is
you're missing from node/mocha.
If you think that needs its own topic, feel free to fork the summary.
In any case, discussions about the ease of use of
It's pretty rare that things such OS, Compiler, SDK change on our build
systems. We do tend to make noise about them when that happens, too. Do
you have specific examples to point at?
Where can I follow these changes? One specific example is bug 1002729 and the
like...
Currently m-c does
I started to summarise the things I’d like to see in a JS unit test runner
here[1]:
* mini-core.
* Async support as a base. We’ve added `add_task()` methods where possible,
but we haven’t made it a core feature of the legacy suites in use today.
Generators yielding Promises are now possible,
James, thanks so much for the additional background information about testing
at Mozilla.
I’m currently following the bugs you mentioned earlier and am looking forward
to their results!
Mike.
On 03 Jun 2014, at 16:07, James Graham ja...@hoppipolla.co.uk wrote:
On 03/06/14 14:16, Mike de
On 14-06-03 10:32 AM, Gabor Krizsanits wrote:
It's pretty rare that things such OS, Compiler, SDK change on our build
systems. We do tend to make noise about them when that happens, too. Do
you have specific examples to point at?
Where can I follow these changes? One specific example is bug
On 03/06/2014 15:35, Mike de Boer wrote:
I started to summarise the things I’d like to see in a JS unit test runner
here[1]:
* mini-core.
* Async support as a base. We’ve added `add_task()` methods where possible,
but we haven’t made it a core feature of the legacy suites in use today.
On 6/3/2014 8:39 AM, Gijs Kruitbosch wrote:
On 03/06/2014 14:16, Mike de Boer wrote:
Indeed, I’m used to the NodeJS/ Mocha flow of writing tests as fast,
or even faster, as writing the implementation of a feature. I could
group tests, isolate one, hook in a debugger at any point and more.
On Tuesday 2014-06-03 15:21 +0200, Mike de Boer wrote:
On 03 Jun 2014, at 15:07, Boris Zbarsky bzbar...@mit.edu wrote:
I assume that the mochitest version will use a different reporter that
doesn't throw-and-terminate, to preserve the current semantics of mochitest
assertions. (If this
On 2014-06-02, 9:35 PM, Boris Zbarsky wrote:
On 6/2/14, 5:33 PM, Gavin Sharp wrote:
Do either of you have reasoning for that other than it looks better
to me?
My personal experience is that when I try to write xpcshell tests the
amount of time it takes to type the test function names is very
On 2014-06-03, 5:57 AM, Henri Sivonen wrote:
On Wed, May 28, 2014 at 5:45 PM, Nathan Froyd froy...@mozilla.com wrote:
Assuming that ICU is already compiled with the moral equivalent of GCC's
-ffunction-sections -fdata-sections or MSVC's /Gy, then statically linking ICU
into libxul should
On 6/3/14, 6:42 AM, Ben Hearsum wrote:
On 14-06-03 06:39 AM, Gabor Krizsanits wrote:
From time to time, no matter what platform I use, the build configuration on
the try server changes
and from that point on it's just a matter of time that my build gets broken.
When you're
about to work on
On 03 Jun 2014, at 17:39, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On 2014-06-02, 9:35 PM, Boris Zbarsky wrote:
On 6/2/14, 5:33 PM, Gavin Sharp wrote:
Do either of you have reasoning for that other than it looks better
to me?
My personal experience is that when I try to write xpcshell
On 6/3/14, 9:29 AM, Mike de Boer wrote:
Nope, you got me there - I generalised too easily. This statement is based on
personal experience, not science.
I'm not looking for science, necessarily. I'm looking for an
understanding of the problems we're trying to solve.
My basic issue is that
On 6/3/14, 11:19 AM, L. David Baron wrote:
Locally I generally want to see all the failures, since seeing the
complete set of failures is often a much better hint as to the cause
of the failures than just seeing the first one.
Yes, exactly.
-Boris
On 6/3/14, 11:17 AM, Joshua Cranmer wrote:
I'm used to xpcshell tests more than mochitests, and the biggest
difference by far between xpcshell and mocha that I'm aware of is that
mocha counts tests at finer granularity: xpcshell tests work on a
file-by-file basis, whereas mocha tests work at
On Tue, Jun 3, 2014 at 6:13 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-02 23:45 GMT-04:00 Rik Cabanier caban...@gmail.com:
To recap I think the following points have been resolved:
- remove determinant (unless someone comes up with a strong use case)
- change is2D() so it's
On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-03 3:34 GMT-04:00 Dirk Schulze dschu...@adobe.com:
On Jun 2, 2014, at 12:11 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
Objection #6:
The determinant() method, being in this API the only easy
On 2014-06-03, 1:49 PM, Gavin Sharp wrote:
On Mon, Jun 2, 2014 at 9:35 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I think what xpcshell has now and what testharness says and what's being
proposed (with the Assert. prefix) are unreasonably long/verbose.
I suspected this is where we'd end up :)
On Tue, Jun 03, 2014 at 12:08:52PM -0400, Ehsan Akhgari wrote:
On 2014-06-03, 5:57 AM, Henri Sivonen wrote:
On Wed, May 28, 2014 at 5:45 PM, Nathan Froyd froy...@mozilla.com wrote:
Assuming that ICU is already compiled with the moral equivalent of GCC's
-ffunction-sections -fdata-sections or
On 2014-06-03, 2:17 PM, Gavin Sharp wrote:
I won't argue that a great case has been made :) But I see inherent
value in consistency (both in the implementations and in the
user-exposed API) for assertions across our in-tree test suites (or at
least, across mochitest-based harnesses and
On 6/3/14, 2:36 PM, Gregory Szorc wrote:
There is a clear win in the ability to reuse, understand, and modify the
common code.
No one is arguing against having common harness code as far as I can see.
I can't even recall which file(s)
contain is/ok from mochitest
SimpleTest.js. Which also
On Tue, Jun 3, 2014 at 12:31 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I can certainly buy it's longer than what I'm
used to, and even incremental effort is required - just not
incremental effort is required and that effort is non-negligible
given other factors
Purely subjectively, it's
On 2014-06-03, 2:37 PM, Chris Peterson wrote:
http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html
What is the status of Firefox builds for Win64? When Mozilla releases
Win64 builds (again), we'll be seen as reacting to Google when we've
actually been working on it for a
On 6/3/14, 3:31 PM, Boris Zbarsky wrote:
Maybe that's a personal failing of mine, but I suspect not.
More precisely, I expect it's a personal failing that is widespread, not
just my personal little quirk.
-Boris
___
dev-platform mailing list
Inverses get used *a lot*. I would argue that they are only 'advanced'
in that there are many lines of code in an implementation - they are a
common operation when setting up transforms or working with
transforms. For example, reverse-projecting from an onscreen point
into a point on the surface
I did following
1. main.c
#include stdio.h
int add(int a, int b) {
return a + b;
}
2. gcc -fPIC -c main.c
3. gcc -shared -o main.so main.o
4. copied main.so file to content folder.
5. started my extension and called on following code in html in the extension
const {utils:Cu} = Components;
On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-03 3:34 GMT-04:00 Dirk Schulze dschu...@adobe.com:
On Jun 2, 2014, at 12:11 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
Objection #6:
The determinant() method, being in this API the only easy
found solution ..
http://stackoverflow.com/questions/9152142/mozilla-use-a-c-dll-with-js-ctypes
it worked.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Tue, Jun 3, 2014 at 12:41 PM, Bobby Holley bobbyhol...@gmail.com wrote:
On Tue, Jun 3, 2014 at 12:31 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I can certainly buy it's longer than what I'm
used to, and even incremental effort is required - just not
incremental effort is required and that
2014-06-03 16:20 GMT-04:00 Rik Cabanier caban...@gmail.com:
On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-03 3:34 GMT-04:00 Dirk Schulze dschu...@adobe.com:
On Jun 2, 2014, at 12:11 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
Objection
2014-06-03 17:34 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com:
2014-06-03 16:20 GMT-04:00 Rik Cabanier caban...@gmail.com:
On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-03 3:34 GMT-04:00 Dirk Schulze dschu...@adobe.com:
On Jun 2, 2014,
On Tue, Jun 3, 2014 at 2:34 PM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-03 16:20 GMT-04:00 Rik Cabanier caban...@gmail.com:
On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-03 3:34 GMT-04:00 Dirk Schulze dschu...@adobe.com:
On Jun
On Wed, Jun 4, 2014 at 1:13 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
This list misses some of the points that I care more about:
- Should DOMMatrix really try to be both 3D projective transformations
and 2D affine transformations or should that be split into separate classes?
I
On Tue, Jun 3, 2014 at 2:40 PM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-03 17:34 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com:
2014-06-03 16:20 GMT-04:00 Rik Cabanier caban...@gmail.com:
On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-03 18:26 GMT-04:00 Rik Cabanier caban...@gmail.com:
On Tue, Jun 3, 2014 at 2:40 PM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
2014-06-03 17:34 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com:
2014-06-03 16:20 GMT-04:00 Rik Cabanier caban...@gmail.com:
On Tue, Jun 3,
On Wed, Jun 4, 2014 at 10:23 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Wed, Jun 4, 2014 at 1:13 AM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
This list misses some of the points that I care more about:
- Should DOMMatrix really try to be both 3D projective transformations
and
On 03/06/14 22:28, Jonas Sicking wrote:
testharness.js still requires lots of boiler plate. Especially when
writing async tests. And especially if you try to follow the rule that
each test within a file should clean up after itself.
At this point testharness.js has taken several steps to
2014-06-03 18:29 GMT-04:00 Robert O'Callahan rob...@ocallahan.org:
On Wed, Jun 4, 2014 at 10:26 AM, Rik Cabanier caban...@gmail.com wrote:
That would require try/catch around all the invert() calls. This is ugly
but more importantly, it will significantly slow down javascript
execution.
I'd
On Tue, Jun 3, 2014 at 3:29 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Wed, Jun 4, 2014 at 10:26 AM, Rik Cabanier caban...@gmail.com wrote:
That would require try/catch around all the invert() calls. This is ugly
but more importantly, it will significantly slow down javascript
On Wed, Jun 4, 2014 at 12:26 AM, Rik Cabanier caban...@gmail.com wrote:
Actually, inverse() is already spec'd to throw if the inversion fails. In
that case (assuming we keep it that way) there is no need at all for any
isInvertible kind of method. Note that in floating-point arithmetic
On Tue, Jun 03, 2014 at 09:11:26AM -0700, Gregory Szorc wrote:
On 6/3/14, 6:42 AM, Ben Hearsum wrote:
On 14-06-03 06:39 AM, Gabor Krizsanits wrote:
From time to time, no matter what platform I use, the build configuration
on the try server changes
and from that point on it's just a matter of
On Tue, Jun 3, 2014 at 3:48 PM, Till Schneidereit t...@tillschneidereit.net
wrote:
On Wed, Jun 4, 2014 at 12:26 AM, Rik Cabanier caban...@gmail.com wrote:
Actually, inverse() is already spec'd to throw if the inversion fails.
In
that case (assuming we keep it that way) there is no need at
On Tue, Jun 03, 2014 at 07:32:57AM -0700, Gabor Krizsanits wrote:
It's pretty rare that things such OS, Compiler, SDK change on our build
systems. We do tend to make noise about them when that happens, too. Do
you have specific examples to point at?
Where can I follow these changes?
64 matches
Mail list logo
