I've tried both, and also Firefox built on this machine.
On 03/04/14 15:16, Kevin Brosnan wrote:
Using a Mozilla build or the Ubuntu package?
http://nightly.mozilla.org/
or
http://www.mozilla.org/en-US/firefox/all/
Kevin
On Apr 2, 2014 6:15 PM, "Geoff Lankow" wrote:
I'm trying to use a game
Using a Mozilla build or the Ubuntu package?
http://nightly.mozilla.org/
or
http://www.mozilla.org/en-US/firefox/all/
Kevin
On Apr 2, 2014 6:15 PM, "Geoff Lankow" wrote:
> I'm trying to use a gamepad in Firefox on Ubuntu 13.10. It shows up fine
> in lsusb and jstest, but neither Firefox nor Chr
I'm trying to use a gamepad in Firefox on Ubuntu 13.10. It shows up fine
in lsusb and jstest, but neither Firefox nor Chromium seem to see it. It
seems like I'm missing a crucial package or something. Any ideas?
My code works fine if I forward the USB device to a VM, but I don't want
to have t
On 4/2/2014 5:30 PM, Ehsan Akhgari wrote:
I have no reservations against making them member functions with a
clear name that do not return T/T*/etc. I was trying to not be super
inconsistent with std::atomic, but if you think that's ok, that's fine
by me.
std::atomic has the fetch_* methods
2014-04-02 11:03 GMT-04:00 Honza Bambas :
> On 4/2/2014 11:33 AM, Nicolas B. Pierron wrote:
>
>>
>> --lock(mRefCnt);
>> if (lock(mRefCnt) == 0) {
>>delete this;
>> }
>>
>> This way, this is more obvious that we might not be doing the right
>> things, as long as we are careful to refuse AtomicH
On 2014-04-02, at 14:01, Ehsan Akhgari wrote:
> AtomicFetchAndSub(&mRefCnt, -1);
I think that I’ll join those who seem to favour member functions over statics,
as you seem to prefer for some reason.
If you want to avoid inventing names and such, how about copying from something
that is known
On Wed, Apr 2, 2014 at 5:29 PM, Joshua Cranmer 🐧 wrote:
> On 4/2/2014 3:52 PM, Ehsan Akhgari wrote:
>
>> On 2014-04-02, 12:11 AM, Joshua Cranmer 🐧 wrote:
>>
>>> On 4/1/2014 4:32 PM, Ehsan Akhgari wrote:
>>>
So, over in bug 987887 I'm proposing to remove all of the methods on
mozilla::Ato
On 4/2/2014 3:52 PM, Ehsan Akhgari wrote:
On 2014-04-02, 12:11 AM, Joshua Cranmer 🐧 wrote:
On 4/1/2014 4:32 PM, Ehsan Akhgari wrote:
So, over in bug 987887 I'm proposing to remove all of the methods on
mozilla::Atomic except for copy construction and assignment and replace
them with global func
On 2014-04-02, 4:43 AM, Neil wrote:
Ehsan Akhgari wrote:
On 2014-04-01, 8:10 PM, Martin Thomson wrote:
count_type tmp = --mRefCnt;
if (tmp == 0) {
delete this;
}
And how do we enforce people to write code like the above example
using the current Atomic interface?
Would WARN_UNUSED_RESU
On 2014-04-02, 11:03 AM, Honza Bambas wrote:
On 4/2/2014 11:33 AM, Nicolas B. Pierron wrote:
--lock(mRefCnt);
if (lock(mRefCnt) == 0) {
delete this;
}
This way, this is more obvious that we might not be doing the right
things, as long as we are careful to refuse AtomicHandler references
in
On 2014-04-02, 12:11 AM, Joshua Cranmer 🐧 wrote:
On 4/1/2014 4:32 PM, Ehsan Akhgari wrote:
So, over in bug 987887 I'm proposing to remove all of the methods on
mozilla::Atomic except for copy construction and assignment and replace
them with global functions that can operate on the atomic type.
On Wed, Apr 02, 2014 at 05:37:39PM +0200, Honza Bambas wrote:
> On 4/2/2014 5:24 PM, Trevor Saunders wrote:
> >On Wed, Apr 02, 2014 at 05:03:53PM +0200, Honza Bambas wrote:
> >>On 4/2/2014 11:33 AM, Nicolas B. Pierron wrote:
> >>>--lock(mRefCnt);
> >>>if (lock(mRefCnt) == 0) {
> >>> delete this;
On 2014-04-02, 1:46 AM, Paul wrote:
I strongly suspect this happens due to the permission issue while Nightly does
not allow me to gain root privileges.
However, this is necessary for me to complete my experiment. How can I obtain a
decent permission while I do this?
strace -f should see you
On 4/2/2014 5:24 PM, Trevor Saunders wrote:
On Wed, Apr 02, 2014 at 05:03:53PM +0200, Honza Bambas wrote:
On 4/2/2014 11:33 AM, Nicolas B. Pierron wrote:
--lock(mRefCnt);
if (lock(mRefCnt) == 0) {
delete this;
}
This way, this is more obvious that we might not be doing the right
things, as
On Wed, Apr 02, 2014 at 05:03:53PM +0200, Honza Bambas wrote:
> On 4/2/2014 11:33 AM, Nicolas B. Pierron wrote:
> >
> >--lock(mRefCnt);
> >if (lock(mRefCnt) == 0) {
> > delete this;
> >}
> >
> >This way, this is more obvious that we might not be doing the right
> >things, as long as we are carefu
On 4/2/2014 11:33 AM, Nicolas B. Pierron wrote:
--lock(mRefCnt);
if (lock(mRefCnt) == 0) {
delete this;
}
This way, this is more obvious that we might not be doing the right
things, as long as we are careful to refuse AtomicHandler references
in reviews.
I personally don't think this w
On Tue, Apr 1, 2014 at 5:56 PM, Zack Weinberg wrote:
> The downside of turning this on would be that any switch statements
> that *deliberately* include only a subset of the enumerators, plus a
> default case, would now have to be expanded to cover all the
> enumerators.
If there are few enough t
The Web API documentation meeting is Friday at 9 AM Pacific Time.
Everyone's welcome to attend; if you're interested in ensuring that
these APIs are properly documented, we'd love your input.
We have an agenda, as well as details on how to join, here:
https://etherpad.mozilla.org/WebAPI-docs-2
On 04/01/2014 02:32 PM, Ehsan Akhgari wrote:
The summary is that I think the mozilla::Atomic API which is modeled after
std::atomic is harmful in that it makes it very non-obvious that you're
dealing with atomic integers. Basically the existing interface makes
mozilla::Atomic look like a normal
Ehsan Akhgari wrote:
On 2014-04-01, 8:10 PM, Martin Thomson wrote:
count_type tmp = --mRefCnt;
if (tmp == 0) {
delete this;
}
And how do we enforce people to write code like the above example
using the current Atomic interface?
Would WARN_UNUSED_RESULT help here, so that you remember t
20 matches
Mail list logo
