Re: Virtual Memory fragmentation issues

[Jet Villegas]

I'm curious if small >4K textures are getting passed back as these mysterious 
64K pages. What does that look like on your ATI machine?

--Jet

- Original Message -
From: "Jeff Muizelaar" 
To: "Jet Villegas" 
Cc: "Justin Lebar" , "Aaron Klotz" , 
dev-platform@lists.mozilla.org, "Nicholas Nethercote" 
, "Brian R. Bondy" , "Benjamin 
Smedberg" , "Bas Schouten" 
Sent: Tuesday, April 9, 2013 12:45:51 PM
Subject: Re: Virtual Memory fragmentation issues

Just allocating a bunch of Texture memory and looking at the process in VMMap 
should show the problem. Process Explorer also lets you view per process GPU 
memory consumption which might be interesting to look at.

-Jeff

On 2013-04-09, at 3:29 PM, Jet Villegas wrote:

> Jeff: how mysterious is this phenomena? Can we write a test that forces it to 
> happen? I'm curious how it behaves on ATI vs. other drivers.
> 
> --Jet
> 
> 
> - Original Message -
> From: "Jeff Muizelaar" 
> To: "Benjamin Smedberg" 
> Cc: "Justin Lebar" , "Aaron Klotz" , 
> dev-platform@lists.mozilla.org, "Nicholas Nethercote" 
> , "Brian R. Bondy" 
> Sent: Tuesday, April 9, 2013 12:24:32 PM
> Subject: Re: Virtual Memory fragmentation issues
> 
> 
> On 2013-04-08, at 7:46 PM, Benjamin Smedberg wrote:
> 
>> In stability-land we're starting to see some "interesting" problems relating 
>> to virtual memory usage in Firefox on Windows.
> 
> 
>> Either our code or the ATI driver is leaking mapped memory references in a 
>> way that chews up VM space without actually using memory. We need to figure 
>> out why and fix our work around the problem. I'm hoping that one of you on 
>> the "To" of this email may be able to help figure out a way to either patch 
>> Firefox or run an external debugging tool which can help record information 
>> about the stacks when these mappings are typically created and destroyed, 
>> and help create a detailed understanding of the problem so that we can 
>> either fix our code or hand the problem to the nvidia developers with the 
>> most reproducible/detailed report possible
> 
> One interesting phenomenon that I have seen is pages being mysteriously added 
> to firefox's address space. I believe this can happen when graphics memory is 
> paged into system memory and is added to our address space. I'm not sure what 
> OS accounting all knows about this and what doesn't.
> 
> -Jeff
> 
> ___
> 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: Virtual Memory fragmentation issues

[Jeff Muizelaar]

Just allocating a bunch of Texture memory and looking at the process in VMMap 
should show the problem. Process Explorer also lets you view per process GPU 
memory consumption which might be interesting to look at.

-Jeff

On 2013-04-09, at 3:29 PM, Jet Villegas wrote:

> Jeff: how mysterious is this phenomena? Can we write a test that forces it to 
> happen? I'm curious how it behaves on ATI vs. other drivers.
> 
> --Jet
> 
> 
> - Original Message -
> From: "Jeff Muizelaar" 
> To: "Benjamin Smedberg" 
> Cc: "Justin Lebar" , "Aaron Klotz" , 
> dev-platform@lists.mozilla.org, "Nicholas Nethercote" 
> , "Brian R. Bondy" 
> Sent: Tuesday, April 9, 2013 12:24:32 PM
> Subject: Re: Virtual Memory fragmentation issues
> 
> 
> On 2013-04-08, at 7:46 PM, Benjamin Smedberg wrote:
> 
>> In stability-land we're starting to see some "interesting" problems relating 
>> to virtual memory usage in Firefox on Windows.
> 
> 
>> Either our code or the ATI driver is leaking mapped memory references in a 
>> way that chews up VM space without actually using memory. We need to figure 
>> out why and fix our work around the problem. I'm hoping that one of you on 
>> the "To" of this email may be able to help figure out a way to either patch 
>> Firefox or run an external debugging tool which can help record information 
>> about the stacks when these mappings are typically created and destroyed, 
>> and help create a detailed understanding of the problem so that we can 
>> either fix our code or hand the problem to the nvidia developers with the 
>> most reproducible/detailed report possible
> 
> One interesting phenomenon that I have seen is pages being mysteriously added 
> to firefox's address space. I believe this can happen when graphics memory is 
> paged into system memory and is added to our address space. I'm not sure what 
> OS accounting all knows about this and what doesn't.
> 
> -Jeff
> 
> ___
> 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: Virtual Memory fragmentation issues

[Jet Villegas]

Jeff: how mysterious is this phenomena? Can we write a test that forces it to 
happen? I'm curious how it behaves on ATI vs. other drivers.

--Jet


- Original Message -
From: "Jeff Muizelaar" 
To: "Benjamin Smedberg" 
Cc: "Justin Lebar" , "Aaron Klotz" , 
dev-platform@lists.mozilla.org, "Nicholas Nethercote" 
, "Brian R. Bondy" 
Sent: Tuesday, April 9, 2013 12:24:32 PM
Subject: Re: Virtual Memory fragmentation issues


On 2013-04-08, at 7:46 PM, Benjamin Smedberg wrote:

> In stability-land we're starting to see some "interesting" problems relating 
> to virtual memory usage in Firefox on Windows.


> Either our code or the ATI driver is leaking mapped memory references in a 
> way that chews up VM space without actually using memory. We need to figure 
> out why and fix our work around the problem. I'm hoping that one of you on 
> the "To" of this email may be able to help figure out a way to either patch 
> Firefox or run an external debugging tool which can help record information 
> about the stacks when these mappings are typically created and destroyed, and 
> help create a detailed understanding of the problem so that we can either fix 
> our code or hand the problem to the nvidia developers with the most 
> reproducible/detailed report possible

One interesting phenomenon that I have seen is pages being mysteriously added 
to firefox's address space. I believe this can happen when graphics memory is 
paged into system memory and is added to our address space. I'm not sure what 
OS accounting all knows about this and what doesn't.

-Jeff

___
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: Virtual Memory fragmentation issues

[Jeff Muizelaar]

On 2013-04-08, at 7:46 PM, Benjamin Smedberg wrote:

> In stability-land we're starting to see some "interesting" problems relating 
> to virtual memory usage in Firefox on Windows.


> Either our code or the ATI driver is leaking mapped memory references in a 
> way that chews up VM space without actually using memory. We need to figure 
> out why and fix our work around the problem. I'm hoping that one of you on 
> the "To" of this email may be able to help figure out a way to either patch 
> Firefox or run an external debugging tool which can help record information 
> about the stacks when these mappings are typically created and destroyed, and 
> help create a detailed understanding of the problem so that we can either fix 
> our code or hand the problem to the nvidia developers with the most 
> reproducible/detailed report possible

One interesting phenomenon that I have seen is pages being mysteriously added 
to firefox's address space. I believe this can happen when graphics memory is 
paged into system memory and is added to our address space. I'm not sure what 
OS accounting all knows about this and what doesn't.

-Jeff

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

Re: CSS outline-color: invert

[Jeff Muizelaar]

Since IE supports this with hardware acceleration I don't think there's any 
theoretical reason we couldn't. That being said it is probably a lot of work 
and probably not worth doing right now.

-Jeff

On 2013-04-09, at 2:21 PM, Matt Brubeck wrote:

> Support for "outline-color: invert" was removed in Firefox 3, and a bug to 
> restore support was RESOLVED WONTFIX several years ago because it was deemed 
> infeasible while using hardware acceleration [1].
> 
> Since then, some developers have asked for reconsideration on the bug; since 
> some of their questions in the bug remain unanswered, one developer asked me 
> to bring it up here.
> 
> The specific question is whether the many changes to our graphics 
> acceleration since 2009 have made it any more feasible to implement "invert" 
> today.  Do IE or Opera use any tricks to do this that could be useful for us 
> too?
> 
> In addition to the obvious use case of making outlines visible against 
> multiple background colors, apparently this can be used for hacks [2] to 
> invert entire regions, similar to David Baron's SVG filter demo [3] but 
> possibly more flexible.
> 
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=359497#c24
> [2]: http://lea.verou.me/2011/04/invert-a-whole-webpage-with-css-only/
> [3]: http://dbaron.org/log/20110430-invert-colors
> ___
> 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: Virtual Memory fragmentation issues

[Benjamin Smedberg]

On 4/8/2013 7:46 PM, Benjamin Smedberg wrote:
In stability-land we're starting to see some "interesting" problems 
relating to virtual memory usage in Firefox on Windows.


See bug 875030

This should have been bug 857030.


2) later on, there appear to be a large number of 8.7MB allocated 
blocks which are mapped memory. The minidump does not appear tell me 
any more about the mapping, whether it is a file mapping, or named or 
anonymous shared memory.
I have now filed bug 859955 about this issue. Jet volunteered to help 
find an owner.


--BDS

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

CSS outline-color: invert

[Matt Brubeck]

Support for "outline-color: invert" was removed in Firefox 3, and a bug 
to restore support was RESOLVED WONTFIX several years ago because it was 
deemed infeasible while using hardware acceleration [1].


Since then, some developers have asked for reconsideration on the bug; 
since some of their questions in the bug remain unanswered, one 
developer asked me to bring it up here.


The specific question is whether the many changes to our graphics 
acceleration since 2009 have made it any more feasible to implement 
"invert" today.  Do IE or Opera use any tricks to do this that could be 
useful for us too?


In addition to the obvious use case of making outlines visible against 
multiple background colors, apparently this can be used for hacks [2] to 
invert entire regions, similar to David Baron's SVG filter demo [3] but 
possibly more flexible.


[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=359497#c24
[2]: http://lea.verou.me/2011/04/invert-a-whole-webpage-with-css-only/
[3]: http://dbaron.org/log/20110430-invert-colors
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What does BC stand for?

[Ryan VanderMeulen]

On 4/8/2013 10:28 PM, allencb...@gmail.com wrote:

Am I right to assume that the XULrunner 23 daily build includes BC?



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

Re: Virtual Memory fragmentation issues

[Justin Lebar]

> I see, so the hypothesis is that 100% of the fragmentation is coming from
> VirtualAlloc/MapViewOfFile, not from allocations in general?

jemalloc does not make 4kb allocations, I think ever.  So yes.

On Tue, Apr 9, 2013 at 9:23 AM, Kevin Gadd  wrote:
> I see, so the hypothesis is that 100% of the fragmentation is coming from
> VirtualAlloc/MapViewOfFile, not from allocations in general? I believe the
> kernel instrumentation tools could give you data on this but it would
> probably require modifications to the profiler tool, so maybe it can't be
> used to answer questions about 'who allocated this'.
>
> It does appear that MS offers a utility for this, though, called LeakDiag:
> http://blogs.jetbrains.com/yole/archives/34.html
>
> It appears to instrument VirtualAlloc and record tracebacks. Maybe worth a
> look.
>
>
> On Tue, Apr 9, 2013 at 6:07 AM, Benjamin Smedberg 
> wrote:
>>
>> On 4/9/13 7:12 AM, Kevin Gadd wrote:
>>>
>>> This is one of the problems Heap Profiler was written to solve:
>>>
>>> https://github.com/kevingadd/HeapProfiler
>>>
>>> It enables stack trace captures at allocation time, so at any given point
>>> in the capture you can open the heap and see who allocated a given block
>>> of
>>> memory. It can also display a fragmentation summary.
>>>
>>> It would probably be trivial to extend it to do a fragmentation analysis
>>> and generate a summary of who's causing the most fragmentation (by module
>>> or function, most likely).
>>
>> As far as I understand it, this tool profiles heap allocations like
>> "malloc". I am not concerned with those allocations, but only with page
>> allocations. Can this tool intercept calls to VirtualAlloc and especially
>> MapViewOfFile so that we can see the stack at the point the large memory
>> mappings are created?
>>
>> Note that although it's interesting that we're fragmenting the page
>> because of the 4k/64k behavior, I am much less concerned with that behavior
>> than I am with the leaked memory mappings.
>>
>> --BDS
>>
>
>
>
> --
> -kg
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

WebAPI Meeting: Tuesday 9 April @ 10 AM Pacific [1]

[Andrew Overholt]

Meeting Details:

* Agenda: https://wiki.mozilla.org/WebAPI/2013-04-09

* WebAPI Vidyo room
* Amoeba conf. room, San Francisco office (7A)
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome!

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130409T10&p1=224&am=30 


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

Re: Virtual Memory fragmentation issues

[Kevin Gadd]

I see, so the hypothesis is that 100% of the fragmentation is coming from
VirtualAlloc/MapViewOfFile, not from allocations in general? I believe the
kernel instrumentation tools could give you data on this but it would
probably require modifications to the profiler tool, so maybe it can't be
used to answer questions about 'who allocated this'.

It does appear that MS offers a utility for this, though, called LeakDiag:
http://blogs.jetbrains.com/yole/archives/34.html

It appears to instrument VirtualAlloc and record tracebacks. Maybe worth a
look.


On Tue, Apr 9, 2013 at 6:07 AM, Benjamin Smedberg wrote:

> On 4/9/13 7:12 AM, Kevin Gadd wrote:
>
>> This is one of the problems Heap Profiler was written to solve:
>>
>> https://github.com/kevingadd/**HeapProfiler
>>
>> It enables stack trace captures at allocation time, so at any given point
>> in the capture you can open the heap and see who allocated a given block
>> of
>> memory. It can also display a fragmentation summary.
>>
>> It would probably be trivial to extend it to do a fragmentation analysis
>> and generate a summary of who's causing the most fragmentation (by module
>> or function, most likely).
>>
> As far as I understand it, this tool profiles heap allocations like
> "malloc". I am not concerned with those allocations, but only with page
> allocations. Can this tool intercept calls to VirtualAlloc and especially
> MapViewOfFile so that we can see the stack at the point the large memory
> mappings are created?
>
> Note that although it's interesting that we're fragmenting the page
> because of the 4k/64k behavior, I am much less concerned with that behavior
> than I am with the leaked memory mappings.
>
> --BDS
>
>


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

Re: WebAPI team plans

[crit . radiodns]

OK. For your point 2, I'll prepare a detailed proposal and I'll file it as a 
ticket and on the FM RDS API thread.

Best regards
Paolo



On Tuesday, April 9, 2013 11:32:41 AM UTC+2, Anne van Kesteren wrote:
> On Tue, Apr 9, 2013 at 10:21 AM,  Paolo wrote:
> 
> > Ref1: 
> > https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/viKr7qCiKaM
> 
> > Ref2: http://radiodns.org
> 
> 
> 
> That would be a new feature, no? I think we should track that
> 
> separately. Also, we should really get a page rather than a collection
> 
> of mailing list messages documenting the actual FM API...
> 
> 
> 
> 
> 
> --
> 
> http://annevankesteren.nl/

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

Re: WebAPI team plans

[crit . radiodns]

Hi Andrew,
could we add also FM RDS support in the FM API in the list? Because there was a 
discussion on FM RDS support in the FM API (Andy, David, Mounir, José, me and 
others in different threads), and there was some agreement that the inclusion 
of such features would enable convenient use cases.

Ref1: 
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/viKr7qCiKaM
Ref2: http://radiodns.org

Best regards
Paolo



On Wednesday, April 3, 2013 10:12:26 PM UTC+2, Andrew Overholt wrote:
> Yesterday a number of people discussed future plans for the WebAPI team. 
> 
>   Our discussion resulted in the ideas and comments that are on this 
> 
> wiki page:
> 
> 
> 
>https://wiki.mozilla.org/WebAPI/PlannedWork
> 
> 
> 
> We'll add items to that page as time goes by and we'll pop items off it 
> 
> as we work on them.  As always, we're interested in your suggestions and 
> 
> input so please feel free to get in touch via dev-webapi, #webapi, or 
> 
> our weekly meetings on Tuesdays at 10 AM Pacific in the WebAPI Vidyo 
> 
> room [1].
> 
> 
> 
> Thanks,
> 
> 
> 
> Andrew
> 
> 
> 
> [1]
> 
> https://wiki.mozilla.org/WebAPI#Meetings
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Virtual Memory fragmentation issues

[Aaron Klotz]

On 4/08/13 5:57 PM, Nicholas Nethercote wrote:

AIUI, on Windows the smallest block you can ask for with VirtualAlloc
is 4 KiB.  However, no more than one VirtualAlloc block can exist per
64 KiB chunk.  So if you ask for 4 KiB you'll end up wasting the
remaining 60 KiB of address space in the 64 KiB chunk.

Assuming I'm right about this (I'm fairly certain, but not 100%), it
sounds like some code (be it Mozilla or driver code) is
VirtualAlloc'ing lots of 4 KiB blocks, and thus wasting lots of
address space.


This sounds like a really good hypothesis.

FWIW, the VirtualAlloc() allocation granularity may be queried via 
GetSystemInfo(), but AFAIK it has always been 64KiB across all 
architectures supported by NT.


Unsurprisingly, Raymond Chen provides some history on this:
http://blogs.msdn.com/b/oldnewthing/archive/2003/10/08/55239.aspx
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Virtual Memory fragmentation issues

[Benjamin Smedberg]

On 4/9/13 7:12 AM, Kevin Gadd wrote:

This is one of the problems Heap Profiler was written to solve:

https://github.com/kevingadd/HeapProfiler

It enables stack trace captures at allocation time, so at any given point
in the capture you can open the heap and see who allocated a given block of
memory. It can also display a fragmentation summary.

It would probably be trivial to extend it to do a fragmentation analysis
and generate a summary of who's causing the most fragmentation (by module
or function, most likely).
As far as I understand it, this tool profiles heap allocations like 
"malloc". I am not concerned with those allocations, but only with page 
allocations. Can this tool intercept calls to VirtualAlloc and 
especially MapViewOfFile so that we can see the stack at the point the 
large memory mappings are created?


Note that although it's interesting that we're fragmenting the page 
because of the 4k/64k behavior, I am much less concerned with that 
behavior than I am with the leaked memory mappings.


--BDS

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

Re: Virtual Memory fragmentation issues

[Kevin Gadd]

This is one of the problems Heap Profiler was written to solve:

https://github.com/kevingadd/HeapProfiler

It enables stack trace captures at allocation time, so at any given point
in the capture you can open the heap and see who allocated a given block of
memory. It can also display a fragmentation summary.

It would probably be trivial to extend it to do a fragmentation analysis
and generate a summary of who's causing the most fragmentation (by module
or function, most likely).

See
http://www.luminance.org/blog/code/2011/06/03/diving-into-memory-usage-with-heap-profilerand
http://www.luminance.org/blog/code/2011/08/01/a-journey-into-linker-hell-and-a-mistakefor
some examples of usage.

On Mon, Apr 8, 2013 at 11:39 PM, Mike Hommey  wrote:

> On Mon, Apr 08, 2013 at 08:09:08PM -0400, Justin Lebar wrote:
> > > AIUI, on Windows the smallest block you can ask for with VirtualAlloc
> > > is 4 KiB.  However, no more than one VirtualAlloc block can exist per
> > > 64 KiB chunk.  So if you ask for 4 KiB you'll end up wasting the
> > > remaining 60 KiB of address space in the 64 KiB chunk.
> >
> > Awesome memory, Nick.
> >
> > MSDN seems to confirm this.
> >
> > "The second parameter [to VirtualAlloc] indicates the range of
> > addresses the function should allocate. This value can be anywhere
> > from one page to 2 GB in size, but VirtualAlloc is actually
> > constrained to a smaller range than that. The minimum size that can be
> > reserved is 64K, and the maximum that can be reserved is the largest
> > contiguous range of free addresses in the process. Requesting one page
> > of reserved addresses results in a 64K address range."
> >
> > http://msdn.microsoft.com/en-us/library/ms810627.aspx
> >
> > We have the ability to intercept VirtualAlloc calls on Windows, so
> > assuming that works for these particular VirtualAlloc calls (it
> > should?) perhaps we can take backtraces and write them to a file.
>
> We're already intercepting VirtualAlloc in
> xpcom/base/AvailableMemoryTracker.cpp
>
> Mike
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



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

running tests on the build farm in HiDPI mode

[Cameron McCormack]

Are there any plans to have tests on the build farm be run in HiDPI 
mode?  I've recently been working on some test failures that manifest 
themselves locally on my Retina MBP, but which are fine on tbpl.  It 
would be good to have test coverage for this configuration.


It might be sufficient just to set layout.css.devPixelsPerPx = 2, and 
not actually run on HiDPI hardware.  The reftest harness also needs to 
support capturing native resolution images, but bug 821210 should allow 
that.


I just pushed to try to see what sort of failures we currently get, and 
there is a bunch:


  https://tbpl.mozilla.org/?tree=Try&rev=f349f614c174

I filed bug 859742 to hang specific test fixes off.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unable to run TPS tests

[Raymond Lee]

Thanks Jonathan, it works for me with the following.

runtps 
--binary=/Users/raymond/Documents/mozilla-central/obj-ff-dbg/dist/Nightly.app/


Jonathan Griffin於 2013年4月4日星期四UTC+8上午3時54分37秒寫道：
> I just tested this myself and found that it works.  The problem is in 
> 
> your command-line:
> 
> 
> 
>  >>> 2. runtps --binary=/Users/raymond/Documents/mozilla-central/obj-ff-dbg/
> 
> 
> 
> --binary needs to be the full path of the binary, not the directory to it.
> 
> 
> 
> The error message could certainly be improved.  :)
> 
> 
> 
> Let me know if this doesn't resolve your issue.
> 
> 
> 
> Jonathan
> 
> 
> 
> 
> 
> On 4/3/2013 10:31 AM, Jonathan Griffin wrote:
> 
> > You can't run TPS via tryserver; it isn't run in buildbot at all.  It
> 
> > can't, since it uses live Sync servers.
> 
> >
> 
> > Raymond, the problem you're experiencing is likely due to changes in
> 
> > mozprocess/mozrunner API's that TPS hasn't been updated to handle.  Can
> 
> > you file a bug about this, and assign it to me?
> 
> >
> 
> > Thanks,
> 
> >
> 
> > Jonathan
> 
> >
> 
> >
> 
> > On 4/3/2013 9:56 AM, Justin Lebar wrote:
> 
> >> I don't know, actually.  You can ask on #developers, but I'd just run
> 
> >> 'em all.  :)
> 
> >>
> 
> >> On Wed, Apr 3, 2013 at 12:54 PM, Raymond Lee
> 
> >>  wrote:
> 
> >>> Thanks Justin!  Can you suggest what try syntax I can use please?  I
> 
> >>> don't
> 
> >>> see a TPS option in the try syntax builder page.
> 
> >>> http://trychooser.pub.build.mozilla.org/
> 
> >>>
> 
> >>> On 3 Apr, 2013, at 11:47 PM, Justin Lebar 
> 
> >>> wrote:
> 
> >>>
> 
> >>> In general you'll have much more success running these benchmarks on
> 
> >>> tryserver rather than trying to run them locally.  Even if you got the
> 
> >>> test working, there's no guarantee that your local benchmark results
> 
> >>> will have any bearing on the benchmark results on our servers.  (In
> 
> >>> particular, the servers are configured to reduce the noise in these
> 
> >>> results.)
> 
> >>>
> 
> >>> On Wed, Apr 3, 2013 at 3:15 AM,   wrote:
> 
> >>>
> 
> >>> Hi all
> 
> >>>
> 
> >>> I am trying to run TPS to ensure my patch works for bug 852041
> 
> >>> (https://bugzilla.mozilla.org/show_bug.cgi?id=852041)
> 
> >>>
> 
> >>> However, I got some errors when I ran the following.  Could someone
> 
> >>> give me
> 
> >>> some suggestions how to fix it please?
> 
> >>>
> 
> >>> 1. source /Users/raymond/Documents/virtualenv/bin/activate
> 
> >>> 2. runtps --binary=/Users/raymond/Documents/mozilla-central/obj-ff-dbg/
> 
> >>>
> 
> >>> == START ==
> 
> >>> using result file tps_result.json
> 
> >>> ['/Users/raymondlee/Documents/appcoast/mozilla-central2/obj-ff-dbg/',
> 
> >>> '-profile',
> 
> >>> '/var/folders/43/d4b7hbz56jn2gvhmdhtrytxwgn/T/tmpozAsVT.mozrunner',
> 
> >>> '-tps',
> 
> >>> '/var/folders/43/d4b7hbz56jn2gvhmdhtrytxwgn/T/tps_test_Uwxl4Y',
> 
> >>> '-tpsphase', u'1', '-tpslogfile',
> 
> >>> '/Users/raymondlee/Documents/appcoast/mozilla-central2/obj-ff-dbg/dist/tps.log']
> 
> >>>
> 
> >>> Traceback (most recent call last):
> 
> >>>   File
> 
> >>> "/Users/raymondlee/Documents/appcoast/virtualenv/lib/python2.7/site-packages/tps-0.4-py2.7.egg/tps/testrunner.py",
> 
> >>>
> 
> >>> line 331, in run_tests
> 
> >>> self.run_test_group()
> 
> >>>   File
> 
> >>> "/Users/raymondlee/Documents/appcoast/virtualenv/lib/python2.7/site-packages/tps-0.4-py2.7.egg/tps/testrunner.py",
> 
> >>>
> 
> >>> line 405, in run_test_group
> 
> >>> result = self.run_single_test(testdir, test)
> 
> >>>   File
> 
> >>> "/Users/raymondlee/Documents/appcoast/virtualenv/lib/python2.7/site-packages/tps-0.4-py2.7.egg/tps/testrunner.py",
> 
> >>>
> 
> >>> line 223, in run_single_test
> 
> >>> phase.run()
> 
> >>>   File
> 
> >>> "/Users/raymondlee/Documents/appcoast/virtualenv/lib/python2.7/site-packages/tps-0.4-py2.7.egg/tps/phase.py",
> 
> >>>
> 
> >>> line 49, in run
> 
> >>> profile=self.profile)
> 
> >>>   File
> 
> >>> "/Users/raymondlee/Documents/appcoast/virtualenv/lib/python2.7/site-packages/tps-0.4-py2.7.egg/tps/firefoxrunner.py",
> 
> >>>
> 
> >>> line 90, in run
> 
> >>> self.runner.start()
> 
> >>>   File
> 
> >>> "/Users/raymondlee/Documents/appcoast/virtualenv/lib/python2.7/site-packages/mozrunner-5.15-py2.7.egg/mozrunner/runner.py",
> 
> >>>
> 
> >>> line 183, in start
> 
> >>> self.process_handler.run(timeout, outputTimeout)
> 
> >>>   File
> 
> >>> "/Users/raymondlee/Documents/appcoast/virtualenv/lib/python2.7/site-packages/mozprocess-0.9-py2.7.egg/mozprocess/processhandler.py",
> 
> >>>
> 
> >>> line 621, in run
> 
> >>> self.proc = self.Process(self.cmd, **args)
> 
> >>>   File
> 
> >>> "/Users/raymondlee/Documents/appcoast/virtualenv/lib/python2.7/site-packages/mozprocess-0.9-py2.7.egg/mozprocess/processhandler.py",
> 
> >>>
> 
> >>> line 76, in __init__
> 
> >>> universal_newlines, startupinfo, creationflags)
> 
> >>>   File
> 
> >>> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/py

Re: WebAPI team plans

[Anne van Kesteren]

On Tue, Apr 9, 2013 at 10:21 AM,   wrote:
> Ref1: 
> https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/viKr7qCiKaM
> Ref2: http://radiodns.org

That would be a new feature, no? I think we should track that
separately. Also, we should really get a page rather than a collection
of mailing list messages documenting the actual FM API...


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