thanks to dylan's work on bug 489028, bugzilla now tracks when you view
a bug, allowing you to search for bugs which have been updated since you
last visited them.
see my blog post for more details: http://wp.me/p1JUqW-9M
--
byron jones - :glob - bugzilla.mozilla.org team -
__
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 ch
On Tue, Jun 3, 2014 at 3:48 PM, Till Schneidereit wrote:
> On Wed, Jun 4, 2014 at 12:26 AM, Rik Cabanier 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
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 jus
On Wed, Jun 4, 2014 at 12:26 AM, Rik Cabanier 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 there
> > is no a
On Wed, Jun 4, 2014 at 10:42 AM, Rik Cabanier wrote:
> Going with Benoit's suggestion, we can change the idl for invert to:
>
> bool invert();
>
> and change inverse to return a matrix with NaN for all its elements.
>
Make it so!
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehr
On Tue, Jun 3, 2014 at 3:29 PM, Robert O'Callahan
wrote:
> On Wed, Jun 4, 2014 at 10:26 AM, Rik Cabanier 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 prefer that we
2014-06-03 18:29 GMT-04:00 Robert O'Callahan :
> On Wed, Jun 4, 2014 at 10:26 AM, Rik Cabanier 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 prefer that we don't throw
On 03/06/14 20:34, Boris Zbarsky wrote:
> I'm arguing against Assert.jsm using the commonjs API names.
And I am arguing against using the CommonJS semantics. If we are adding
new assertions it shouldn't be ones that encourage broken tests.
___
dev-plat
On Wed, Jun 4, 2014 at 10:26 AM, Rik Cabanier 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 prefer that we don't throw at all but we have to because SVGMatrix did.
>
Are you
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 al
On Wed, Jun 4, 2014 at 10:23 AM, Robert O'Callahan
wrote:
> On Wed, Jun 4, 2014 at 1:13 AM, Benoit Jacob
> 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
2014-06-03 18:26 GMT-04:00 Rik Cabanier :
>
>
>
> On Tue, Jun 3, 2014 at 2:40 PM, Benoit Jacob
> wrote:
>
>>
>>
>>
>> 2014-06-03 17:34 GMT-04:00 Benoit Jacob :
>>
>>
>>>
>>>
>>> 2014-06-03 16:20 GMT-04:00 Rik Cabanier :
>>>
>>>
On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob
wro
On Tue, Jun 3, 2014 at 2:40 PM, Benoit Jacob
wrote:
>
>
>
> 2014-06-03 17:34 GMT-04:00 Benoit Jacob :
>
>
>>
>>
>> 2014-06-03 16:20 GMT-04:00 Rik Cabanier :
>>
>>
>>>
>>>
>>> On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob
>>> wrote:
>>>
2014-06-03 3:34 GMT-04:00 Dirk Schulze :
On Wed, Jun 4, 2014 at 1:13 AM, Benoit Jacob
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 raised this issue too a w
On Tue, Jun 3, 2014 at 2:34 PM, Benoit Jacob
wrote:
>
>
>
> 2014-06-03 16:20 GMT-04:00 Rik Cabanier :
>
>
>>
>>
>> On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob
>> wrote:
>>
>>>
>>>
>>>
>>> 2014-06-03 3:34 GMT-04:00 Dirk Schulze :
>>>
>>>
On Jun 2, 2014, at 12:11 AM, Benoit Jacob
wrote
2014-06-03 17:34 GMT-04:00 Benoit Jacob :
>
>
>
> 2014-06-03 16:20 GMT-04:00 Rik Cabanier :
>
>
>>
>>
>> On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob
>> wrote:
>>
>>>
>>>
>>>
>>> 2014-06-03 3:34 GMT-04:00 Dirk Schulze :
>>>
>>>
On Jun 2, 2014, at 12:11 AM, Benoit Jacob
wrote:
2014-06-03 16:20 GMT-04:00 Rik Cabanier :
>
>
>
> On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob
> wrote:
>
>>
>>
>>
>> 2014-06-03 3:34 GMT-04:00 Dirk Schulze :
>>
>>
>>> On Jun 2, 2014, at 12:11 AM, Benoit Jacob
>>> wrote:
>>>
>>> > Objection #6:
>>> >
>>> > The determinant() method, being in thi
On Tue, Jun 3, 2014 at 12:41 PM, Bobby Holley wrote:
> On Tue, Jun 3, 2014 at 12:31 PM, Boris Zbarsky 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
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 6:06 AM, Benoit Jacob
wrote:
>
>
>
> 2014-06-03 3:34 GMT-04:00 Dirk Schulze :
>
>
>> On Jun 2, 2014, at 12:11 AM, Benoit Jacob
>> wrote:
>>
>> > Objection #6:
>> >
>> > The determinant() method, being in this API the only easy way to get
>> > something that looks roughly l
On 6/3/14, 3:57 PM, Ehsan Akhgari wrote:
Nobody is opposing a proposal where someone volunteered to create the
rewriting facilities you're mentioning and using them to fix the entire
code base in one go.
I somewhat am.
-Boris
___
dev-platform mailin
I did following
1. main.c
#include
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;
alert(
On Tue, Jun 3, 2014 at 12:52 PM, Benoit Jacob
wrote:
> I also think that now that determinant() is being removed, is a good time
> to revisit my Objection #4 which I don't think has been addressed at all:
> please remove inverse() too.
>
> Indeed, without its companion determinant() method, the i
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 of
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
dev-pl
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 w
On 2014-06-03, 3:34 PM, Boris Zbarsky wrote:
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/o
I also think that now that determinant() is being removed, is a good time
to revisit my Objection #4 which I don't think has been addressed at all:
please remove inverse() too.
Indeed, without its companion determinant() method, the inverse() method is
now standing out as by far the most advanced
On Tue, Jun 3, 2014 at 12:31 PM, Boris Zbarsky 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 no
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 6/3/14, 1:49 PM, Gavin Sharp wrote:
I suspected this is where we'd end up :) "Reasonability" is just as
subjective as aesthetics.
Of cours.
I really have a hard time accepting at face value the argument
"Assert.notEqual (or other shorter variants) is unreasonably long to
type/paste repeate
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 while. :\
chris
___
On 6/3/14, 11:28 AM, Ehsan Akhgari wrote:
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, acro
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 xpcshell).
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 xpcshell). Do you disagree?
Gavin
On Tue, Jun 3, 201
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 wrote:
> >>Assuming that ICU is already compiled with the moral equivalent of GCC's
> >>-ffunction-sections -fdata-sections or MSVC's /Gy,
On 2014-06-03, 1:49 PM, Gavin Sharp wrote:
On Mon, Jun 2, 2014 at 9:35 PM, Boris Zbarsky 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 :) "Reasonability"
On Mon, Jun 2, 2014 at 9:35 PM, Boris Zbarsky 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 :) "Reasonability" is just as
subjective as aesthetics.
I re
On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob
wrote:
>
>
>
> 2014-06-03 3:34 GMT-04:00 Dirk Schulze :
>
>
>> On Jun 2, 2014, at 12:11 AM, Benoit Jacob
>> wrote:
>>
>> > Objection #6:
>> >
>> > The determinant() method, being in this API the only easy way to get
>> > something that looks roughly l
On Tue, Jun 3, 2014 at 6:13 AM, Benoit Jacob
wrote:
>
>
>
> 2014-06-02 23:45 GMT-04:00 Rik Cabanier :
>
> 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 t
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 th
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, 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 f
On 2014-06-03, 12:13 PM, Mike de Boer wrote:
On 03 Jun 2014, at 17:39, Ehsan Akhgari 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
On 03 Jun 2014, at 17:39, Ehsan Akhgari 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 tests the
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 so
On 6/3/14, 6:16 AM, Mike de Boer wrote:
Writing wrappers in python around things to improve the current situation like
a band-aid isnāt the way Iām used to fix things; I like to take the bull by the
horns[1]
Iād like to ask _why_ structured logging needs to be bolted on top of what we
have cu
On 2014-06-03, 5:57 AM, Henri Sivonen wrote:
On Wed, May 28, 2014 at 5:45 PM, Nathan Froyd 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 th
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 Tuesday 2014-06-03 15:21 +0200, Mike de Boer wrote:
> On 03 Jun 2014, at 15:07, Boris Zbarsky 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 assumption
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.
This
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.
Ge
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 examp
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 wrote:
> On 03/06/14 14:16, Mike de Boer wrote:
>
>> Writing
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,
>
> 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
On 03/06/14 14:16, Mike de Boer wrote:
> Writing wrappers in python around things to improve the current
> situation like a band-aid isnāt the way Iām used to fix things; I
> like to take the bull by the horns[1]
>
> Iād like to ask _why_ structured logging needs to be bolted on top of
> what we
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 o
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 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 t
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 f
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. This is something I miss
while working on Fx and
On 03 Jun 2014, at 14:50, Boris Zbarsky 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 explanation o
On 03 Jun 2014, at 15:07, Boris Zbarsky 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 function
On 03 Jun 2014, at 14:54, Boris Zbarsky 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 use it excl
2014-06-02 23:45 GMT-04:00 Rik Cabanier :
> 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.
> - update constru
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 function in the new
setup) y
One other note.
The checkin so far
2014-06-03 3:34 GMT-04:00 Dirk Schulze :
>
> On Jun 2, 2014, at 12:11 AM, Benoit Jacob
> 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
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 is
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 h
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 writ
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 det
On 03/06/2014 12:27, Mike de Boer wrote:
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 fully co
Please see my comments inline.
On 03 Jun 2014, at 12:57, James Graham 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 present in the addo
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
>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 thi
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 whatever suits your fancy.
2. testharness.js, Mochitest, XPCShellās head.js and other suite-runners that
we u
On Wed, May 28, 2014 at 5:45 PM, Nathan Froyd 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 (when
> using the ap
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 transfo
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 acc
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 st
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 Jun 2, 2014, at 12:11 AM, Benoit Jacob 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 confident that it
>
83 matches
Mail list logo
