Re: Why are there "Android 4.0 opt" test runs on mozilla-central and nowhere else?
L. David Baron wrote: > On Saturday 2012-12-22 09:51 -0800, Daniel Holbert wrote: >> Mozilla-central TBPL has a row for "Android 4.0 opt", which isn't >> available on mozilla-inbound or on Try. >> >> I was under the impression that all the tests that get run on >> mozilla-central are supposed to also be run on Try and Inbound. Why is >> this not the case for these "Android 4.0 opt" tests? >> This was a concious choice with ATeam+Releng to get a number of tests running + visible with a small number of "ready" devices. It is common practice to have things on try/inbound/m-c as well. In a case like "large inbound merge breaks stuff on these tests and only these tests" the intent was that we would simply hide the suite(s) that break and try to figure out the problem out-of-band without forcing the tree closed. I recognize we may not have communicated that plan/desire well enough. [I *believe* edmorley as our paid sheriff knew] We will work to get these enabled on inbound at the least shortly after the holiday to help avoid this problem. > I'd note that if the underlying problem is that we want to test > something where we're *really* constrained in number of test > devices, it might be ok to not run on Try by default and not run on > inbound. But it should be *possible* to run on Try via trychooser, > so that when something like this happens, it can at the very least > be bisected after the fact. If we can't at least do that, then the > tests shouldn't be shown on mozilla-central. It is currently not possible to have an --all run *not* run a certain test type by default (aiui), furthermore since these tests come off of regular android builds, a simple -p android would also trigger them. I *believe* sfink is working on improvements in this are for us, but being able to default-limit and overall improve try capacity/use in ways like this is also on our radar/wanted. -- ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_ENSURE_{TRUE,FALSE,SUCCESS}_VOID
Can you make NS_ENSURE_TRUE(foo, /* */) and NS_ENSURE_TRUE(foo,) errors?
Maybe there's a better way to do this, but I think we could do
template
MOZ_ALWAYS_INLINE void EnsureIsLvalue(T t) {}
and then make NS_ENSURE_TRUE call EnsureIsLvalue on the second arg.
I'd want to check that this doesn't slow down our compilations, though.
On Sun, Dec 23, 2012 at 8:31 PM, Nicholas Nethercote
wrote:
> Hi,
>
> This is a moderately common idiom:
>
> NS_ENSURE_TRUE(foo, );
>
> It also occurs with NS_ENSURE_FALSE and NS_ENSURE_SUCCESS. It's used
> in functions that return |void|.
>
> Unfortunately, it causes warnings with recent versions of clang, and
> they can turn into errors if you have --enable-warnings-as-errors.
>
> This alternative is sometimes is used instead, which (surprisingly
> enough) avoids the warning:
>
> NS_ENSURE_TRUE(foo, /* */);
>
> However, this trick isn't needed, because you can instead do this:
>
> NS_ENSURE_TRUE_VOID(foo);
>
> All of this applies to NS_ENSURE_FALSE and NS_ENSURE_SUCCESS, too.
>
> I've filed bug 824397 to convert the existing cases. Please use the
> _VOID forms in the future. Thanks!
>
> Nick
> ___
> 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
NS_ENSURE_{TRUE,FALSE,SUCCESS}_VOID
Hi, This is a moderately common idiom: NS_ENSURE_TRUE(foo, ); It also occurs with NS_ENSURE_FALSE and NS_ENSURE_SUCCESS. It's used in functions that return |void|. Unfortunately, it causes warnings with recent versions of clang, and they can turn into errors if you have --enable-warnings-as-errors. This alternative is sometimes is used instead, which (surprisingly enough) avoids the warning: NS_ENSURE_TRUE(foo, /* */); However, this trick isn't needed, because you can instead do this: NS_ENSURE_TRUE_VOID(foo); All of this applies to NS_ENSURE_FALSE and NS_ENSURE_SUCCESS, too. I've filed bug 824397 to convert the existing cases. Please use the _VOID forms in the future. Thanks! Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changed font size interpretation
On Sun, 23 Dec 2012 03:49:26 UTC, Dave Yeo wrote: > Allan wrote: > > For a long time, I never understood how that worked for you. > > I have same problem here, that just about all websites uses too small fonts. > > When I tried that setting 1.1-1.9 made no difference, but 2 did INDEED:-) > > > > Today it just stroke me to try something odd, so I tried 1,1-1,9 instead. > > Now, I see your results, and this setting is indeed very usefull for me too > > now. > > > > However, this must be a major bug in Moz, as I assume the difference here > > is because of our country settings. Here in Denmark, we do indeed use ',' > > as the separator, where US uses '.' > > > > I can't really imagine, that every numeric setting in Moz has to be > > translated > > for a Danish user (and a lot of other countries too I guess) - and now I do > > wonder > > how many other setting with a decimal part that this might affect. > > > > Any ideas, why this is so ? > > This is part of localization, set things like separators, date formats > and such depending on your locale. For me the separator has to be a > decimal. And yes there is a lot of people working on translating various > parts of the browser for various locales. I find it rather confusing, that some values have '.' as separator, and some has ',' Anyway, a nice person sent me an email with a bit of explanation, and a ref to this bug about it: https://bugzilla.mozilla.org/show_bug.cgi?id=816485 Allan. -- Allan. It is better to close your mouth, and look like a fool, than to open it, and remove all doubt. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: passing command line and filenames as parameters to nsiProcess
Patrick Brunschwig used to work on ipccode, the XPCOM library that is
able to read/write from a process's stdin/stdout. He uses it to
communicate with gpg for Enigmail (Thunderbird addon).
http://hg.mozilla.org/ipccode/
I don't know what the status of this code is, but from reading
https://bugzilla.mozilla.org/show_bug.cgi?id=68702 it looks like it
works, it does precisely what you want, and it no longer requires C++
parts since it's been rewritten using js-ctypes.
Cheers,
jonathan
On Sun 23 Dec 2012 06:33:08 AM CET, Philip Chee wrote:
On 23/12/2012 02:58, Ted Mielczarek wrote:
On 12/22/2012 1:02 PM, rvj wrote:
its a while since I used the ns interfaces. I want to run
gambit-enumpure < e02.nfg > numerate.txt
how do I pass as arguments in nsiProcess?
I asssume the file names must be prefixed with c:\\
is this correct?
***
var file = Components.classes["@mozilla.org/file/local;1"]
.createInstance(Components.interfaces.nsILocalFile);
file.initWithPath("c:\\gambit-enumpure.exe ")
var process=Components.classes["@mozilla.org/process/util;1"]
.createInstance(Components.interfaces.nsIProcess);
process.init(file)
var args = ["<","c:\\e02.nfg",">","c:\\numerate.txt"]
process.run(true,args,args.length)
This will not work. the < and > are only parsed by a shell, they are not
true commandline arguments. nsIProcess does not run its arguments
through a shell, so you can't redirect things that way. I don't think we
have any platform support for running processes and redirecting their I/O.
-Ted
Can you run a shell script using nsiProcess? Or even the shell (cmd,
bash, etc) itself?
Phil
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
