Re: TimeStamp too expensive?

2013-01-07 Thread Robert O'Callahan 
On Mon, Jan 7, 2013 at 8:39 PM, Josh Aas  wrote:

> I was working on something for which TimeStamp and TimeDuration classes
> would be helpful in simplifying code that deals with a cache expiration
> date. This code does not require high-precision timing. In review I was
> told that "TimeStamp shouldn't be used unless a hi-precision ms resolution
> is needed", and that TimeStamp was particularly expensive on Windows due to
> the use of QueryPerfomanceCounter.
>

Who told you this?

The original goal was for TimeStamp to be comparable in performance to
PR_IntervalNow, i.e. as fast as anything else we have. That hasn't changed
to my knowledge.

Rob
-- 
Jesus called them together and said, โ€œYou know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave โ€” just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.โ€ [Matthew 20:25-28]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: TimeStamp too expensive?

2013-01-07 Thread Jeff Muizelaar 

On 2013-01-07, at 2:39 AM, Josh Aas wrote:

> I was working on something for which TimeStamp and TimeDuration classes would 
> be helpful in simplifying code that deals with a cache expiration date. This 
> code does not require high-precision timing. In review I was told that 
> "TimeStamp shouldn't be used unless a hi-precision ms resolution is needed", 
> and that TimeStamp was particularly expensive on Windows due to the use of 
> QueryPerfomanceCounter.
> 
> TimeStamp doesn't seem to have been created with a heavy speed for accuracy 
> tradeoff in mind. Is this true?

TimeStamp is designed to be both very fast and very accurate. Unfortunately, 
the the Windows timing APIs are somewhat of a disaster which makes it very
difficult to achieve this (Bug 676349)

> If so, should there be a less expensive way to use it, such as an option or 
> default for lower accuracy?

Probably. I'd suggest adding a TimeStamp::LowResNow() as an alias for Now() and 
filing a bug about getting a cheaper implementation of that function on 
Windows. FWIW, Chrome has something similar to this as well.

-Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: jsm source (mercurial )

2013-01-07 Thread rvj 

thanks    do_get_cwd  will do !

function run_test()
{
 var isWindows = ("@mozilla.org/windows-registry-key;1" in 
Components.classes);

 var dataFile = do_get_file("ipc-data.txt" , true);

 var processDir = do_get_workdir();
 var cmd = processDir.clone();
 cmd.append("IpcCat" + (isWindows ? ".exe" : ""));

..
}


"Daniel Holbert"  wrote in message 
news:mailman.6054.1357507491.32706.dev-platf...@lists.mozilla.org...

I'm guessing you meant "do_get_cwd" (not _workdir)

That and do_print are defined in head.js:
https://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/head.js

and they're documented here:
https://developer.mozilla.org/en/docs/Writing_xpcshell-based_unit_tests

~Daniel

On 01/06/2013 09:12 AM, rvj wrote:

Many thanks for your reply  all your suggestions..
...its just taken a bit of time knowing in which JSM  a particular
function is located

For example, I was trying to find  "helper" functions used in
test_subprocess(), functions such as do_get_workdir() and do_print(),
but it seems that  you have to search the entire source of hg.

"Jonathan Protzenko"  wrote in message
news:mailman.6025.1357487145.32706.dev-platf...@lists.mozilla.org...

On Sun 06 Jan 2013 03:49:46 PM CET, rvj wrote:

Yes thanks .

Thats where I started before getting sidetracked looking for
test functions in the Mercurial source ...something which I am just
finding my around

https://github.com/protz/gpgfox/blob/0d2fb7c0e207c8a76def0d87b0888b759b2f6ffe/lib/gpg.js#L100

has an example of how to use the subprocess.call function, assuming
you've properly done the Components.utils.import(...) call. But all of
those requirements are properly detailed at
http://hg.mozilla.org/ipccode/file/b3725e9efa10/modules/subprocess.jsm#l39

and the library is really easy to use. Maybe what you're missing is
some background on what a JSM is. If that is the case, I suggest
https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules
as a starting point.


PS  do you understand the reference to compilation of tests?

The tests for the library itself need to simulate calling a binary
process. Therefore, there is a little bit of compilation involved, but
that is not relevant to what you need to do as a client of the library.

Hope that helps,

jonathan


___
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: TimeStamp too expensive?

2013-01-07 Thread Honza Bambas 

On 1/7/2013 1:40 PM, Jeff Muizelaar wrote:
Probably. I'd suggest adding a TimeStamp::LowResNow() as an alias for 
Now() and filing a bug about getting a cheaper implementation of that 
function on Windows. FWIW, Chrome has something similar to this as 
well. -Jeff 


I was recently talking about this with Ehsan and LowRes (or HiRes 
rather?) is the way here.  Chrome has something similar as well.


I will work (or prepare land) on this in bug 822490.

-hb-

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DOM Bindings Meeting - Monday @ 12:30 PM PST

2013-01-07 Thread Kyle Huey 
Our (ostensibly) weekly DOM bindings meetings continue on Monday January
7th at 12:30 PM PST.

Meeting details:

* Monday, January 7, 2012, 12:30 PM PST (9:30 PM CET)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
 - Vidyo room: SFO-7N
 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference num 95704
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed 2013 Platform Goals

2013-01-07 Thread JP Rosevear 
On Fri, 2012-12-21 at 11:17 -0500, JP Rosevear wrote:
> Hello all,
> 
> As we prepare to enter 2013, I'd like to propose a set of goals for the
> platform next year.  These goals have had initial review by many
> platform leaders and have an initial cut at owners.   Owners are
> responsible for producing a plan of attack for their area by Jan 15 and
> converting those to quarterly goals.  

Just poking this thread again to make sure people see it as this mail
went out right before many people had holidays.

Its already 2013, register your complaints soon!

Thanks,

-JP


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tablet vs. Touch: decision

2013-01-07 Thread JP Rosevear 
On Tue, 2012-12-18 at 16:03 +, Gervase Markham wrote:
> Hi everyone,
> 
> After taking all input into account, I have decided that we should drop 
> the "Tablet" token from Fennec's UA on tablets. This is what Android 
> browser and Chrome do, and corresponds to option D) of my original 
> options. So for non-"Mobile" devices, it would be:
> 
> Mozilla/5.0 (Android; rv:12.0) Gecko/12.0 Firefox/12.0
> 
> We should be aware that we _may_ in the future need to add "Touch" on 
> Windows 8 Metro only, if developers start detecting it in large numbers 
> and consequently sites start breaking. We should write up on MDN and 
> publicise a document of best practices in detecting and using touch 
> events cross-browser, to try and make that less likely.
> 
> It's relevant to note that, according to recent ADI data, Tablet users 
> make up about 25% of Fennec installs, for a total of about 388,000 ADIs, 
> so perhaps a million users. (Thanks to Anurag Phadke on the Metrics team 
> for getting the data for me here.)
> 
> To elaborate on some points people may ask about:
> 
> - We would therefore use "Mobile" on devices where we thought a mobile 
> experience should be the default, and the desktop UA where we think a 
> desktop experience should be the default. At the moment, opinion seems 
> to be that phones are "Mobile" and tablets from 7" up are not, but we 
> have the flexibility to change that view later.

How?  By switch more devices to the "Mobile" variant?

> - Given the short time this token has been in use, and the small number 
> of Tablet Fennec users (relative to e.g. desktop), we don't expect 
> significant compatibility problems. The speed we deploy this change is a 
> trade-off between "minimising the number of browsers with the old UA" 
> and "making sure we can detect any compatibility problems". So therefore 
> the exact timing and train schedule of deployment of the change would be 
> a matter for the release-drivers.

> - For the above reasons (short time, relatively small number of users), 
> I am not too concerned that large numbers of web developers are going to 
> have been detecting our "Tablet" string, or that this will lead to 
> frustration at our "ever-changing" UA.

If I understand what you are proposing I think its reasonable given we
are switching to the "desktop" UA.  But I come from the camp that UA
changes should be for a deeply clear benefit, simply "it won't harm
much" is not an argument for change in a property where changing it
*never* again is the ideal.

Thanks,

-JP

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Question about Bugzilla bug dependencies

2013-01-07 Thread Chris Peterson 

I've seen some inconsistent usage, so I just wanted to get a group opinion.

If a fix for bug X introduces regression bug Y, should Y "block" X 
(because X is not properly fixed until regression Y is fixed) or should 
Y "depend on" X (because regression Y does not exist without fix X)?


thanks,
chris p.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Question about Bugzilla bug dependencies

2013-01-07 Thread Kyle Huey 
Y blocks X.

On Mon, Jan 7, 2013 at 1:02 PM, Chris Peterson wrote:

> I've seen some inconsistent usage, so I just wanted to get a group opinion.
>
> If a fix for bug X introduces regression bug Y, should Y "block" X
> (because X is not properly fixed until regression Y is fixed) or should Y
> "depend on" X (because regression Y does not exist without fix X)?
>
> thanks,
> chris p.
> __**_
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-platform
>

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Question about Bugzilla bug dependencies

2013-01-07 Thread L. David Baron 
On Monday 2013-01-07 13:02 -0800, Chris Peterson wrote:
> I've seen some inconsistent usage, so I just wanted to get a group opinion.
> 
> If a fix for bug X introduces regression bug Y, should Y "block" X
> (because X is not properly fixed until regression Y is fixed)

This one.

At least, until we get caused/caused by fields in bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=490926

-David

-- 
๐„ž   L. David Baron http://dbaron.org/   ๐„‚
๐„ข   Mozilla   http://www.mozilla.org/   ๐„‚
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Question about Bugzilla bug dependencies

2013-01-07 Thread Gavin Sharp 
On Mon, Jan 7, 2013 at 1:13 PM, L. David Baron  wrote:
> On Monday 2013-01-07 13:02 -0800, Chris Peterson wrote:
>> I've seen some inconsistent usage, so I just wanted to get a group opinion.
>>
>> If a fix for bug X introduces regression bug Y, should Y "block" X
>> (because X is not properly fixed until regression Y is fixed)
>
> This one.
>
> At least, until we get caused/caused by fields in bugzilla:
> https://bugzilla.mozilla.org/show_bug.cgi?id=490926

+1. I think this is fairly widely agreed upon, but I do occasionally
see mistakes made in following this convention (quite understandably -
it's very non-obvious). Having a dedicated field would be a nice
improvement.

Gavin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MXR Updates for python parsing. [testing in production]

2013-01-07 Thread Justin Wood (Callek) 
Hey Guys,

I got fed up with some of the python parsing in MXR so at risk of
becoming the MXR owner [shudder] I wrote a patch in Bug 812719

The patch has been sitting idle for > a month by now, awaiting IT to
setup a staging instance, so last week myself and :jakem discussed and
we wish to move forward with deploying it on Wednesday, with the
understanding that if anything regresses we either fix or backout ASAP.

We expect to know if things are sane or bad by Friday at the latest.

So if you notice anything looking wrong, MXR being stuck (not updating),
etc. Feel free to poke me in IRC.

-- 
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Emacs and vim modelines

2013-01-07 Thread Nicholas Nethercote 
On Fri, Jan 4, 2013 at 4:21 PM, Benjamin Smedberg  wrote:
>>
>> So it sounds like the recommended mode lines should look like this:
>>
>>/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil;
>> c-basic-offset: 2 -*- */
>>/* vim: set ts=8 sts=2 et sw=2 tw=80: */
>
> Please make this change.

I've done this.  Thanks!

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

No Memshrink meeting on Jan 8, 2013

2013-01-07 Thread Jet Villegas 
Some key contributors are away at the FirefoxOS work week. Next meeting will be 
on January 22.

In the meantime, check out the new & improved Dark Matter Detector:
https://wiki.mozilla.org/Performance/MemShrink/DMD

--Jet
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Question about Bugzilla bug dependencies

2013-01-07 Thread Justin Dolske 

On 1/7/13 1:02 PM, Chris Peterson wrote:

I've seen some inconsistent usage, so I just wanted to get a group opinion.

If a fix for bug X introduces regression bug Y, should Y "block" X
(because X is not properly fixed until regression Y is fixed) or should
Y "depend on" X (because regression Y does not exist without fix X)?


Y blocks X.

I find it easier to remember as "X depends on Y" (a complete fix for X 
depends on Y)... And then work backward to what to set, since setting 
one for X will set the other for Y. YMMV. ;-)



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: backtrace display in ASSERTION from debug build of TB (comm-central.)

2013-01-07 Thread Joshua Cranmer 

On 1/7/2013 10:00 PM, ishikawa wrote:

If we can coerce the built-in traceback function to print something more
meaningful, or
if someone can suggest a way to attach gdb to a run of TB during "make
mozmill" session so that I can get a meaningful backtrace [*IF* gdb
can work out meaningful backtrace under the circumstances], that would be
appreciated.



There is a script called mozilla-central/tools/fix-linux-stack.pl. Pipe 
the output of your stack trace through that script, and you will get a 
useful one.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

backtrace display in ASSERTION from debug build of TB (comm-central.)

2013-01-07 Thread ishikawa 
I am trying to analyze the cause of ASSERTION messages in
the session log of "make mozmill" run of debug build of TB (comm-central).

Often the original coder would like to know where the function, which issues
ASSERTION, is made.

Fair enough.

However, the built-in traceback display is a little obscure.
I am not sure if this is a bug or limitation of the traceback (maybe we are
hitting JIT-compiled binary or something? I think valgrind has a
better backtrace [most of the time]. I wonder what is
the difference.]

to wit: Note the "UNKNOWN" in the trace.

###!!! ASSERTION: Bad position passed to nsJISx4051LineBreaker::Next aLen
(0) <= aPos(0): 'aLen > aPos', file
/TB-NEW/TB-3HG/new-src/mozilla/intl/lwbrk/src/nsJISx4501LineBreaker.cpp,
line 798
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x0057A96F]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x01EBE397]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x01EC3B49]
NS_InvokeByIndex_P+0x0030
[/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x025AEE04]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x0167819C]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x01678B91]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x0168003C]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DCA06F]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DD791D]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DD1407]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DD6B59]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DD797C]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02D77919]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DCA06F]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DD791D]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DD8314]
js::BaseProxyHandler::call(JSContext*, JSObject*, unsigned int,
JS::Value*)+0x00EA [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so
+0x02E37DB2]
js::Wrapper::call(JSContext*, JSObject*, unsigned int,
JS::Value*)+0x0094 [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so
+0x02EE1A4A]
js::CrossCompartmentWrapper::call(JSContext*, JSObject*, unsigned int,
JS::Value*)+0x017D [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so
+0x02EE4EDD]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02E3E150]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02E3E1CC]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DCA06F]
UNKNOWN [/TB-NEW/TB-3HG/objdir-tb3/mozilla/dist/bin/libxul.so +0x02DD7B39]

To me, NS_InvokeByIndex_P suggests some type of
function pointer table or something and the call is made from there.
But I don't know the details.

The full log is in
Bug ASSERTION: Bad position passed to nsJISx4051LineBreaker::Next: 'aLen >
aPos', file ./mozilla/intl/lwbrk/src/nsJISx4501LineBreaker.cpp
https://bugzilla.mozilla.org/show_bug.cgi?id=827061

If we can coerce the built-in traceback function to print something more
meaningful, or
if someone can suggest a way to attach gdb to a run of TB during "make
mozmill" session so that I can get a meaningful backtrace [*IF* gdb
can work out meaningful backtrace under the circumstances], that would be
appreciated.

TIA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: backtrace display in ASSERTION from debug build of TB (comm-central.)

2013-01-07 Thread ishikawa 
On (2013ๅนด01ๆœˆ08ๆ—ฅ 13:03), Joshua Cranmer wrote:
> On 1/7/2013 10:00 PM, ishikawa wrote:
>> If we can coerce the built-in traceback function to print something more
>> meaningful, or
>> if someone can suggest a way to attach gdb to a run of TB during "make
>> mozmill" session so that I can get a meaningful backtrace [*IF* gdb
>> can work out meaningful backtrace under the circumstances], that would be
>> appreciated.
>>
> 
> There is a script called mozilla-central/tools/fix-linux-stack.pl. Pipe the 
> output of your stack trace through that script, and you will get a useful one.

Thank you! will try. (Hmm, comm-central has it under
mozilla/tools/rb/ )

Report back tomorrow.

TIA

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform