Hi All,
Can we start using C++ STL containers like std::set, std::map,
std::queue in Mozilla code please? Many of the STL containers are more
convenient to use than our equivalents, and more familiar to new
contributors.
I understand that we used to have a policy of not using STL in mozilla
Note that we already do use at least those STL containers for which we
don't have an equivalent in the tree. I've seen usage of at least:
std::map, std::set, and std::bitset.
I think that Nick has a good point about reporting memory usage, but I
think that the right solution to this problem is to
Also note that IIUC, the only thing that prevents us from solving the
memory-reporting problem using a STL allocator, is that the spec doesn't
allow us to rely on storing per-object member data on a STL allocator.
Even without that, we could at least have a STL allocator doing
On 12/10/2013 11:28 AM, Chris Pearce wrote:
Hi All,
Can we start using C++ STL containers like std::set, std::map, std::queue in
Mozilla code please? Many of the STL containers are more convenient to
use than our equivalents, and more familiar to new contributors.
I understand that we used to
On 12/10/13 9:49 AM, Benoit Jacob wrote:
since AFAIK we don't have a HashSet class in mfbt or xpcom.
It's called nsBaseHashtable. Granted, using it as a hashset is not that
intuitive.
-Boris
___
dev-platform mailing list
On Tue, Dec 10, 2013 at 1:28 AM, Chris Pearce cpea...@mozilla.com wrote:
Hi All,
Can we start using C++ STL containers like std::set, std::map, std::queue
in Mozilla code please? Many of the STL containers are more convenient to
use than our equivalents, and more familiar to new
On 12/10/13 9:09 AM, Boris Zbarsky wrote:
On 12/10/13 9:49 AM, Benoit Jacob wrote:
since AFAIK we don't have a HashSet class in mfbt or xpcom.
It's called nsBaseHashtable. Granted, using it as a hashset is not
that intuitive.
There's also js::HashSet in js/public/HashTable.h.
-j
On 12/10/2013 3:28 AM, Chris Pearce wrote:
Hi All,
Can we start using C++ STL containers like std::set, std::map,
std::queue in Mozilla code please? Many of the STL containers are more
convenient to use than our equivalents, and more familiar to new
contributors.
I understand that we used
On 12/10/2013 9:49 AM, Benoit Jacob wrote:
std::set compared to using a hashtable to do the same thing, since AFAIK we
don't have a HashSet class in mfbt or xpcom.
nsTHashtableKeyType is the XPCOM hashset.
--BDS
___
dev-platform mailing list
On 09/12/13 08:44 PM, Tetsuharu OHZEKI wrote:
For mobile, this delaying approach is well for saving power. I feel
this approach make sense.
Power? How about not blowing through your data cap allowance or paying
and other hefty charges
Very few countries have cheap unlimited data over
On 08/12/13 04:49 AM, Robert O'Callahan wrote:
Don't these arguments apply to desktop Firefox used at work, in an Internet
cafe, or in a library, as well?
I think it's important to have an easy way to mute/unmute the browser, but
disabling autoplay is probably not the right way to address
On 12/10/2013 4:28 AM, Chris Pearce wrote:
Hi All,
Can we start using C++ STL containers like std::set, std::map,
std::queue in Mozilla code please? Many of the STL containers are more
convenient to use than our equivalents, and more familiar to new
contributors.
njn already mentioned the
Hello,
I wanted to know if there is any way to access bookmarks and history from the
firefox mobile sdk like the places api for the desktop version.
Another question, when I try to cfx run with my firefox mobile, the firefox
crashes and doesn't work. And I tried with something simple, like
The next MemShrink meeting will be brought to you by the Nuwa process on B2G:
https://bugzilla.mozilla.org/show_bug.cgi?id=930282
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure
As I was looking into the patches I noticed that if we remove the
Windows tests I would not be able to find a good reason to trigger the
win32opt debug builds as they would be triggering nothing.
I will be disabling the win32 builds as well.
Please comment in the bug in case you have any
On 12/10/2013 09:49 AM, Benoit Jacob wrote:
std::map and std::set are also free of any size restriction, and do not
require a contiguous part of our address space (see
https://bugzilla.mozilla.org/show_bug.cgi?id=944810#c12 ) , so they won't
run OOM before we are actually OOM.
I posit that if
It seems to me that we should be optimizing for developer productivity
first, and use profiling tools to find code that needs to be optimized.
i.e. we should be able to use STL containers where we need basic ADTs in
day-to-day coding, and if instances of these containers show up in
profiles
On Wed, Dec 11, 2013 at 10:29 AM, Chris Pearce cpea...@mozilla.com wrote:
It seems to me that we should be optimizing for developer productivity
first, and use profiling tools to find code that needs to be optimized.
i.e. we should be able to use STL containers where we need basic ADTs in
2013/12/10 Chris Pearce cpea...@mozilla.com
It seems to me that we should be optimizing for developer productivity
first, and use profiling tools to find code that needs to be optimized.
i.e. we should be able to use STL containers where we need basic ADTs in
day-to-day coding, and if
Also note that IIUC, the only thing that prevents us from solving the
memory-reporting problem using a STL allocator, is that the spec doesn't
allow us to rely on storing per-object member data on a STL allocator.
I believe C++11 supports this.
Cheers,
Botond
On Tue, Dec 10, 2013 at 09:17:22AM -0600, Joshua Cranmer ? wrote:
On 12/10/2013 3:28 AM, Chris Pearce wrote:
Hi All,
Can we start using C++ STL containers like std::set, std::map,
std::queue in Mozilla code please? Many of the STL containers are
more convenient to use than our equivalents,
On Wed, Dec 11, 2013 at 10:50 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:
2013/12/10 Robert O'Callahan rob...@ocallahan.org
Keep in mind that proliferation of different types for the same
functionality hurts developer productivity in various ways, especially
when
they have quite
On Tue, Dec 3, 2013 at 5:02 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
I'm working on getting Valgrind (Linux64-only) runs visible on TBPL.
In order to understand what needs to be done, I looked at the Requirements
for
being shown in the default TBPL view, from From
Is this the default right now? If someone follows the steps and gets the
Mozilla Build package on that page[1], will their build fail or succeed?
[1]:
https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prerequisites
On 12/10/2013 3:29 PM, Chris Pearce wrote:
It seems to me that we should be optimizing for developer productivity
first, and use profiling tools to find code that needs to be optimized.
For many of our developers, the STL is not an API that they are
intimately familiar with, so it's not
Erase-remove seems like poor naming, more than anything. I think that iterators
(pretending things are arrays) are generally really handy. Alternatives
(needing to do everything with pfns) really tend towards arcaneness and are
often awkward to use.
In my experience, docs for 'our' containers
For many of our developers, the STL is not an API that they are
intimately familiar with, so it's not altogether clear that using the
STL instead optimizes for developer productivity.
Developers come and go, however, and the average C++ developer is
more likely to be familiar with STL
Nicholas Nethercote writes:
- When a job times out, the output produced by Valgrind is
usually chopped off in the middle of a line. In fact, it's
often chopped off in the middle of a line that would have been
produced by a single write() system call. So it feels like the
test harness is
2013/12/11 Hubert Figuière h...@mozilla.com:
Power? How about not blowing through your data cap allowance or paying
and other hefty charges
Very few countries have cheap unlimited data over cellular.
Of course, it includes network data traffic. I hope it saves power/data cost :)
--
2013/12/11 Hubert Figuière h...@mozilla.com:
It should be noted that here on desktop I do have
`media.autoplay.enabled=false` (I hate videos that autoplay) and this
still doesn't stop YouTube. [1]
I seem that Gecko's implementation of HTMLMediaElement.play() doesn't
handle
[I'm highlighting this exchange, because it's been buried somewhat;
apologies for the misleading information]
On Tue, Dec 10, 2013 at 4:29 PM, Joshua Cranmer pidgeo...@gmail.com wrote:
Based on
On 12/11/2013 3:07 PM, Tetsuharu OHZEKI wrote:
2013/12/11 Hubert Figuière h...@mozilla.com:
It should be noted that here on desktop I do have
`media.autoplay.enabled=false` (I hate videos that autoplay) and this
still doesn't stop YouTube. [1]
I seem that Gecko's implementation of
On Dec 10, 2013 6:30 PM, Chris Pearce cpea...@mozilla.com wrote:
We could add a pref that caused HTMLMediaElement.play() to only work if
called from inside a user generated event handler (i.e. mouse click, key
press). That would achieve most of what you want, and is very easy to
implement.
This
On 12/11/2013 4:18 PM, Alex Jordan wrote:
On Dec 10, 2013 6:30 PM, Chris Pearce cpea...@mozilla.com wrote:
We could add a pref that caused HTMLMediaElement.play() to only work if
called from inside a user generated event handler (i.e. mouse click, key
press). That would achieve most of what
34 matches
Mail list logo
