Re: The current state of Talos benchmarks

2012-08-29 Thread Mike Hommey
On Wed, Aug 29, 2012 at 07:03:17PM -0400, Ehsan Akhgari wrote: > I don't believe that the current situation is acceptable, especially > with the recent focus on performance (through the Snappy project), > and I would like to ask people if they have any ideas on what we can > do to fix this. The fi

load xml file to DOM tree

2012-08-29 Thread Malintha Adikari
var oFile = DirIO.get("ProfD"); // %Profile% dir oFile.append("extensions"); ssoFile.append("{5872365E-67D1-4AFD-9480-FD293BEBD20D}"); oFile.append("ObjectMap.xml"); // this code is not working for me. Is there any error ? Give me any advice ___ dev-pla

Re: The current state of Talos benchmarks

2012-08-29 Thread Robert O'Callahan
On Thu, Aug 30, 2012 at 1:00 PM, Ehsan Akhgari wrote: > I agree with that if we talk about performance in general. But this > thread is about specific regressions in performance as a result of > changeset going into our tree. I don't think the same argument applies > here, unless we decide that

Re: The current state of Talos benchmarks

2012-08-29 Thread Joshua Cranmer
On 8/29/2012 6:03 PM, Ehsan Akhgari wrote: Hi everyone, The Talos regression detection emails caught a number of regressions during the Monday uplift (see [1] for Aurora and [2] for Beta regressions). To put things into perspective, I prepared a spreadsheet of the most notable performance re

Re: The current state of Talos benchmarks

2012-08-29 Thread Dave Mandelin
On Wednesday, August 29, 2012 4:03:24 PM UTC-7, Ehsan Akhgari wrote: > Hi everyone, > > The way the current situation happens is that many of the developers > ignore the Talos regression emails that go to dev-tree-management, Talos is widely disliked and distrusted by developers, because it's h

Re: The current state of Talos benchmarks

2012-08-29 Thread Ehsan Akhgari
On Wed, Aug 29, 2012 at 8:00 PM, Matt Brubeck wrote: > On 08/29/2012 04:03 PM, Ehsan Akhgari wrote: > >> I don't believe that the current situation is acceptable, especially >> with the recent focus on performance (through the Snappy project), and I >> would like to ask people if they have any id

Re: The current state of Talos benchmarks

2012-08-29 Thread Ehsan Akhgari
On 12-08-29 8:41 PM, Robert O'Callahan wrote: Some of the 16->17 regressions are known and due to DLBI patches (bug 539356). Since we don't have full DLBI on trunk yet, those changes should just be preffed off on Aurora for 17. We should do that and see how that affects the numbers. Matt Woodrow

Re: The current state of Talos benchmarks

2012-08-29 Thread Ehsan Akhgari
On 12-08-29 8:56 PM, Anthony Jones wrote: On 30/08/12 12:10, Justin Lebar wrote: More on topic: I think the essential problem is, you can spend a week chasing down a perf regression when there's a good chance it's not your fault (and also a good chance it's not a regression). So people are maki

Re: The current state of Talos benchmarks

2012-08-29 Thread Ehsan Akhgari
On 12-08-29 8:10 PM, Justin Lebar wrote: After getting an e-mail every single time m-c was merged for a day or two, I filtered the e-mails and completely forgot about them. I imagine most other people did the same. If we fix bug 752002, we'd also need to change the e-mails so as to get around e

Re: The current state of Talos benchmarks

2012-08-29 Thread Anthony Jones
On 30/08/12 12:10, Justin Lebar wrote: More on topic: I think the essential problem is, you can spend a week chasing down a perf regression when there's a good chance it's not your fault (and also a good chance it's not a regression). So people are making a reasonable trade-off here when they ig

Re: The current state of Talos benchmarks

2012-08-29 Thread Robert O'Callahan
Some of the 16->17 regressions are known and due to DLBI patches (bug 539356). Since we don't have full DLBI on trunk yet, those changes should just be preffed off on Aurora for 17. We should do that and see how that affects the numbers. Matt Woodrow will take care of that :-). Rob -- “You have h

Re: The current state of Talos benchmarks

2012-08-29 Thread Justin Lebar
After getting an e-mail every single time m-c was merged for a day or two, I filtered the e-mails and completely forgot about them. I imagine most other people did the same. If we fix bug 752002, we'd also need to change the e-mails so as to get around everyone's existing filters. More on topic:

Re: The current state of Talos benchmarks

2012-08-29 Thread Matt Brubeck
On 08/29/2012 04:03 PM, Ehsan Akhgari wrote: I don't believe that the current situation is acceptable, especially with the recent focus on performance (through the Snappy project), and I would like to ask people if they have any ideas on what we can do to fix this. The fix might be turning off s

Re: Proposed W3C Charter: RDFa Working Group

2012-08-29 Thread L. David Baron
On Wednesday 2012-08-29 14:41 +0200, Axel Hecht wrote: > On 28.08.12 21:31, Benjamin Smedberg wrote: > >On 8/27/2012 6:34 PM, L. David Baron wrote: > >>W3C is proposing a revised charter for the RDFa Working Group. For > >>more details, see: > >>http://lists.w3.org/Archives/Public/public-new-work/

Re: The current state of Talos benchmarks

2012-08-29 Thread Ehsan Akhgari
On 12-08-29 7:32 PM, Nicholas Nethercote wrote: On Wed, Aug 29, 2012 at 4:03 PM, Ehsan Akhgari wrote: Some people have noted in the past that some Talos measurements are not representative of something that the users would see, the Talos numbers are noisy, and we don't have good tools to deal

Re: The current state of Talos benchmarks

2012-08-29 Thread Matt Brubeck
On 08/29/2012 04:32 PM, Nicholas Nethercote wrote: In my experience, a lot of those emails say "there was a regression caused by one of the following 100 patches", and I will have written 1 of those patches. I usually ignore those ones (though it depends on the nature of the patch). But if I ge

Re: The current state of Talos benchmarks

2012-08-29 Thread Nicholas Nethercote
On Wed, Aug 29, 2012 at 4:03 PM, Ehsan Akhgari wrote: > > Some people have noted in the past that some Talos measurements are not > representative of something that the users would see, the Talos numbers are > noisy, and we don't have good tools to deal with these types of regressions. > There mig

Re: Attribute getter naming in WebIDL bindings

2012-08-29 Thread Ehsan Akhgari
On 12-08-29 4:32 PM, Kyle Huey wrote: Thoughts? Sounds great! Sounds lovely! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

The current state of Talos benchmarks

2012-08-29 Thread Ehsan Akhgari
Hi everyone, The Talos regression detection emails caught a number of regressions during the Monday uplift (see [1] for Aurora and [2] for Beta regressions). To put things into perspective, I prepared a spreadsheet of the most notable performance regressions [3] (and please do take a look at

Re: I/O effect on builds [was Moving Away from Makefile's]

2012-08-29 Thread Gregory Szorc
On 8/29/12 2:51 PM, Karl Tomlinson wrote: On 8/22/12 6:10 AM, Robert Kaiser wrote: [...] esp. given that basic file I/O is often costly (from watching my CPU usage, a lot of the build time is spent in I/O wait when using spinning disks - SSDs improve that hugely). On Wed, 22 Aug 2012 12:29:2

I/O effect on builds [was Moving Away from Makefile's]

2012-08-29 Thread Karl Tomlinson
> On 8/22/12 6:10 AM, Robert Kaiser wrote: >> [...] >> esp. given that basic file I/O is often costly (from watching my CPU >> usage, a lot of the build time is spent in I/O wait when using spinning >> disks - SSDs improve that hugely). On Wed, 22 Aug 2012 12:29:24 -0700, Gregory Szorc wrote: >

Re: Moving Away from Makefile's

2012-08-29 Thread Robert Kaiser
Gregory Szorc schrieb: * "if" is "ifneq (,$(foo))" or even "ifneq (,$(strip $(foo)))" in case some extra whitespace snuck in there. One thing that was hoped we could achieve with pymake was to possibly switch to it everywhere at some time and then be able to replace those ugly conditionals wi

Re: Moving Away from Makefile's

2012-08-29 Thread Anthony Jones
On 29/08/12 19:45, Gregory Szorc wrote: On 8/23/2012 9:11 AM, Hanno Schlichting wrote: Instead of using Python's ast module, you can also do a simple trick with the exec statement and limit the global scope and only allow certain whitelisted names. An example implementation is at https://gist.gi

Re: Attribute getter naming in WebIDL bindings

2012-08-29 Thread Kyle Huey
On Wed, Aug 29, 2012 at 1:20 PM, Boris Zbarsky wrote: > Right now, attribute getters always get prefixed with "Get" in the WebIDL > bindings. So "readonly attribute long foo" becomes "int32_t GetFoo()" in > the C++. > > Would it make sense to drop the Get in certain cases? In particular, in > c

Attribute getter naming in WebIDL bindings

2012-08-29 Thread Boris Zbarsky
Right now, attribute getters always get prefixed with "Get" in the WebIDL bindings. So "readonly attribute long foo" becomes "int32_t GetFoo()" in the C++. Would it make sense to drop the Get in certain cases? In particular, in cases in which: 1) The getter is infallible. 2) The return v

Re: XUL Runner, and the future.

2012-08-29 Thread Scott Elcomb
On Wed, Aug 29, 2012 at 10:56 AM, passfree wrote: > I am glad to hear that there is at least one person stepping up to support > xulrunner if a need arises. I also have some apps written on top of xulrunner > but my gut feeling tells me that xul is not the most future-proof technology. > Sadly,

Re: Changing reftest required resolution

2012-08-29 Thread jmaher
On Wednesday, August 29, 2012 11:35:52 AM UTC-4, Andrew Halberstadt wrote: > On 08/29/2012 09:56 AM, Andrew Halberstadt wrote: > > > On 08/28/2012 02:17 PM, L. David Baron wrote: > > >> On Tuesday 2012-08-28 12:52 -0400, Andrew Halberstadt wrote: > > >> I also don't think we should go quite as s

Re: Changing reftest required resolution

2012-08-29 Thread Andrew Halberstadt
On 08/29/2012 09:56 AM, Andrew Halberstadt wrote: On 08/28/2012 02:17 PM, L. David Baron wrote: On Tuesday 2012-08-28 12:52 -0400, Andrew Halberstadt wrote: I also don't think we should go quite as small as 400x400 -- and we want to come up with a common value with other browser vendors that are

Re: XUL Runner, and the future.

2012-08-29 Thread passfree
On Monday, August 20, 2012 8:22:07 PM UTC+1, Alex Vincent wrote: > On 8/14/2012 8:45 PM, andreas.pals...@gmail.com wrote: > > > Hi. > > > > > > I am curious if XUL Runner has an End-Of-Life policy? > > > Or is it intimately connected with Firefox, i.e. as long as there is > > Firefox releases

Re: Changing reftest required resolution

2012-08-29 Thread Andrew Halberstadt
On 08/28/2012 02:17 PM, L. David Baron wrote: On Tuesday 2012-08-28 12:52 -0400, Andrew Halberstadt wrote: I also don't think we should go quite as small as 400x400 -- and we want to come up with a common value with other browser vendors that are also using reftest. We don't want to be running o

nsCAutoString -> nsAutoCString - mass change

2012-08-29 Thread Randell Jesup
[ This is largely a repeat of an earlier posting, with some updates ] See bug 773151 After seeing some discussion on #developers about how we should bring the naming of nsCAutoString in line with other classes, I threw together a patch (using the wonders of 'sed') and now I'm stuck shepherding it

Re: Proposed W3C Charter: RDFa Working Group

2012-08-29 Thread Axel Hecht
On 28.08.12 21:31, Benjamin Smedberg wrote: On 8/27/2012 6:34 PM, L. David Baron wrote: W3C is proposing a revised charter for the RDFa Working Group. For more details, see: http://lists.w3.org/Archives/Public/public-new-work/2012Aug/0001.html http://www.w3.org/2012/06/rdfwa-wg-charter.html Mo

Re: Moving Away from Makefile's

2012-08-29 Thread Gregory Szorc
On 8/23/2012 9:11 AM, Hanno Schlichting wrote: Instead of using Python's ast module, you can also do a simple trick with the exec statement and limit the global scope and only allow certain whitelisted names. An example implementation is at https://gist.github.com/3437909. Download it as restri

Re: quick! use lisp! before it's too late!

2012-08-29 Thread Simon Kornblith
On Aug 29, 2:17 am, Pedro Bessa wrote: > Design patterns solve a problem, but the problem shouldn't have existed in > the first place. Prototypal OO doesn't have the problems that traditional > OO has. Lua is fast, prototypal, has C interop and was used to create World > of Warcraft, the most fina