Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic
On Mon, Apr 28, 2014 at 7:18 AM, Birunthan Mohanathas birunt...@mohanathas.com wrote: Bugs 900903 and 900908 introduced variadic variants of NS_IMPL_ISUPPORTS, NS_IMPL_QUERY_INTERFACE, NS_IMPL_CYCLE_COLLECTION, etc. and removed the old numbered macros. Cool. Is there a script that rewrites mq patches whose context has numbered macros to not expect numbered macros? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Too many system compartments at start-up
Le jeudi 24 avril 2014 10:51:12 UTC+2, Nicholas Nethercote a écrit : I've given the list of current start-up (+30s) modules below. This list contains several compartments for XPCOM components handling the command line (eg. nsSetDefaultBrowser.js or nsDefaultCLH.js). I wouldn't expect them to still be alive 30s after startup. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=975639 on this a while ago. Florian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic
Birunthan Mohanathas wrote: Note that due to technical details, the new macros will reject uses with zero variadic arguments. In such cases, you will want to continue to use the zero-numbered macro, e.g. NS_IMPL_ISUPPORTS0(nsFoo). I can't help wondering who would need to implement only nsISupports. It can't be for the refcounting, because you can just use inline refcounting. And you've got no way of telling whether an arbitrary nsISupports is your object or not. For example, nsMemoryReporterManager creates an object, hands it out, and assumes the one it got back was the one it handed out. (I picked that as an easy example that could technically be written safely using an nsSupportsPRInt64.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic
2014-04-28 0:18 GMT-04:00 Birunthan Mohanathas birunt...@mohanathas.com: Bugs 900903 and 900908 introduced variadic variants of NS_IMPL_ISUPPORTS, NS_IMPL_QUERY_INTERFACE, NS_IMPL_CYCLE_COLLECTION, etc. and removed the old numbered macros. So, instead of e.g. NS_IMPL_ISUPPORTS2(nsFoo, nsIBar, nsIBaz), simply use NS_IMPL_ISUPPORTS(nsFoo, nsIBar, nsIBaz) instead. Right now, the new macros support up to 50 variadic arguments. Awesome, congrats, and thanks! Question: is there a plan to switch to an implementation based on variadic templates when we will stop supporting compilers that don't support them? Do you know when that would be (of the compilers that we currently support, which ones don't support variadic templates?) Benoit Note that due to technical details, the new macros will reject uses with zero variadic arguments. In such cases, you will want to continue to use the zero-numbered macro, e.g. NS_IMPL_ISUPPORTS0(nsFoo). Cheers, Biru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Policing dead/zombie code in m-c
On 2014-04-28, 8:59 AM, Henri Sivonen wrote: New question: We have various scriptable nsIFoo stuff (e.g. nsIParserService, nsIScriptableUConv) on the fringes of Gecko for use by mailnews, the Firefox UI or extensions. Since Gaia doesn't use XPCOM, those things are dead code in B2G, right? Would it make sense to invest time in #ifdefing them out for B2G? Or are they already left out by some mechanism not obvious to me? No, there is no such mechanism. We should turn these off where we can. With bug 996061, even marking them as non-scriptable would help. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic
2014-04-28 14:18 GMT-04:00 Trevor Saunders trev.saund...@gmail.com:
On Mon, Apr 28, 2014 at 02:07:07PM -0400, Benoit Jacob wrote:
2014-04-28 12:17 GMT-04:00 Birunthan Mohanathas
birunt...@mohanathas.com:
On 28 April 2014 14:18, Benoit Jacob jacob.benoi...@gmail.com wrote:
Question: is there a plan to switch to an implementation based on
variadic
templates when we will stop supporting compilers that don't support
them? Do
you know when that would be (of the compilers that we currently
support,
which ones don't support variadic templates?)
I don't think a purely variadic template based solution is possible
(e.g. due to argument stringification employed by NS_IMPL_ADDREF and
others).
Would it be possible to have a variadic macro that takes N arguments,
stringifies them, and passes all 2N resulting values (the original N
arguments and their N stringifications) to a variadic template?
Well, the bigger problem is that those macros are defining member
functions, so I don't see how you could do that with a variatic
template, accept perhaps for cycle collection if we can have a struct
that takes a variatic template, and then use the variatic template args
in member functions.
Right, NS_IMPL_CYCLE_COLLECTION and its variants are what I have in mind
here.
Benoit
Trev
Benoit
As for compiler support, I believe our current MSVC version is the
only one lacking variadic templates. I don't know if/when we are going
to switch to VS2013.
On 28 April 2014 12:07, Henri Sivonen hsivo...@hsivonen.fi wrote:
Cool. Is there a script that rewrites mq patches whose context has
numbered macros to not expect numbered macros?
Something like this should work (please use with caution because it's
Perl and because I only did a quick test):
perl -i.bak -0777 -pe '
$names = join(|, (
NS_IMPL_CI_INTERFACE_GETTER#,
NS_IMPL_CYCLE_COLLECTION_#,
NS_IMPL_CYCLE_COLLECTION_INHERITED_#,
NS_IMPL_ISUPPORTS#,
NS_IMPL_ISUPPORTS#_CI,
NS_IMPL_ISUPPORTS_INHERITED#,
NS_IMPL_QUERY_INTERFACE#,
NS_IMPL_QUERY_INTERFACE#_CI,
NS_IMPL_QUERY_INTERFACE_INHERITED#,
NS_INTERFACE_TABLE#,
NS_INTERFACE_TABLE_INHERITED#,
)) =~ s/#/[1-9]\\d?/gr;
sub rep {
my ($name, $args) = @_;
my $unnumbered_name = $name =~ s/_?\d+//r;
my $spaces_to_remove = length($name) -
length($unnumbered_name);
$args =~ s/^(. {16}) {$spaces_to_remove}/\1/gm;
return $unnumbered_name . $args;
}
s/($names)(\(.*?\))/rep($1, $2)/ges;
' some-patch.diff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: OS.File design issue from bug 961080 (making downloads respect umask)
On 28/04/14 21:00, Paolo Amadini wrote: On 4/28/2014 7:44 PM, Zack Weinberg wrote: Based on all discussion to this point, I'm proposing this low-level API: fileObject.setPermissions(options); OS.File.setPermissions(path, options); Generally, this looks good to me. I'd rather use unix as a prefix than posix, to match the rest of the API. Unless somebody disagrees, all that's left is nitpicking and we can finish that discussion on the bug. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic
Neil n...@parkwaycc.co.uk wrote: I can't help wondering who would need to implement only nsISupports. It can't be for the refcounting, because you can just use inline refcounting. And you've got no way of telling whether an arbitrary nsISupports is your object or not. Well, except that in the case of callbacks and context arguments you do know what object you're getting, however, you do have to play by XPCOM rules. The nsMemoryReporterManager case could use an nsSupportsPRInt64, but if that was a real object with more than just an int64_t, it'd need its own class. -- Blake Kaplan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
