On Sat, Nov 3, 2012 at 8:59 AM, Jason Duell wrote:
> I see an increasing number of patches using anonymous namespaces instead
> of 'static'. This is debugger unfriendly: setting a breakpoint in gdb
> for 'foo' in an anonymous namespace requires the following syntax:
>
> b (anonymous namespac
On Sat, Nov 3, 2012 at 10:59 AM, Justin Lebar wrote:
>
>>It also obfuscates the visibility of the identifier,
>
> That's a problem with namespaces in general. Do you have a reason we
> should use namespaces but shouldn't use anonymous ones (except where
> we have to), or is the argument for limit
> [It's annoying to do]
>
> b (anonymous namespace)::foo
>
> (If there's a less verbose way of doing this, please let me know.)
Does that even work if you're not inside the file which contains
foo()? I'd be impressed...
I almost always do
(gdb) b Foo.cpp:123
because that's the only thing wh
Hello,
The Graphics meeting will take place this Monday at 2:30 PM US/Pacific
time. That could be Tuesday in your timezone.
Please first add your agenda items there:
https://wiki.mozilla.org/Platform/GFX/2012-November-5
* Not every Monday at 2:30 PM Pacific Time
* +1 650 903 0800 x92 Conf# 9936
On Sat, Nov 3, 2012 at 6:59 AM, Jason Duell wrote:
> I see an increasing number of patches using anonymous namespaces instead of
> 'static'. This is debugger unfriendly
It also obfuscates the visibility of the identifier, because the
|namespace {| is often far from the identifier. This is part
I see an increasing number of patches using anonymous namespaces instead
of 'static'. This is debugger unfriendly: setting a breakpoint in gdb
for 'foo' in an anonymous namespace requires the following syntax:
b (anonymous namespace)::foo
(If there's a less verbose way of doing this, plea
On 11/2/12 1:08 AM, Ms2ger wrote:
On 11/02/2012 01:47 AM, Dave Mandelin wrote:
First, I want to try to pour some gasoline on the dying embers and
suggest that perhaps we should totally rearrange everything. As a
developer user of our testing systems, I always found it incredibly
irritating that
On Tuesday, October 30, 2012 7:26:34 AM UTC-7, Henrik Skupin wrote:
> As nearly all of you agreed on a flat folder structure makes a lot of
> sense if only one type of test is present. I second that, and we
> shouldn't make use of a 'tests' subfolder in such a case. But it would
> be fantastic if
On Friday, November 2, 2012 8:44:03 AM UTC-7, Ehsan Akhgari wrote:
> On 2012-11-01 8:47 PM, Dave Mandelin wrote:
>
> > |-- tests/
>
> > |-- browser-chrome/
>
> > |-- topic1 (omit this level if there would be only one)
>
> > |-- topic2
>
> >
Hi all,
The building where the machine hosting the git mirror updater is located is
going under a power maintenance tomorrow, Nov 3, from 8am - 4pm eastern
time. Therefore, the git mirror may not get updated in that period. Once
the power comes back up, the service should resume.
Apologies in a
Right - the linked modules are not jetpack-only code - they're part of
"core" gecko code now, and the plan is to land even more of them, so
we need to keep them working somehow.
Gavin
On 2012-11-02, at 9:33 AM, David Rajchenbach-Teller wrote:
> On 11/2/12 4:42 PM, Kyle Huey wrote:
>> On Thu, No
On 11/2/12 4:42 PM, Kyle Huey wrote:
> On Thu, Nov 1, 2012 at 10:24 AM, Gavin Sharp wrote:
>
>> On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey wrote:
>>> Not if the pref isn't set. If the pref is set I suspect it still returns
>>> an object with the relevant properties, but that object is no longer
On Fri, Nov 02, 2012 at 11:40:56AM -0400, Ehsan Akhgari wrote:
> On 2012-11-02 12:12 AM, Nicholas Nethercote wrote:
> >On Thu, Nov 1, 2012 at 6:33 PM, wrote:
> >>
> >>The tyranny of hierarchy never ends. Either we have subsidiarity for js and
> >>other modules, or not. If "Gecko" is one big modu
On Nov 2, 2012, at 8:42, Kyle Huey wrote:
> On Thu, Nov 1, 2012 at 10:24 AM, Gavin Sharp wrote:
>
>> On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey wrote:
>>> Not if the pref isn't set. If the pref is set I suspect it still returns
>>> an object with the relevant properties, but that object is no
On 2012-11-01 8:47 PM, Dave Mandelin wrote:
|-- tests/
|-- browser-chrome/
|-- topic1 (omit this level if there would be only one)
|-- topic2
|-- [...]
|-- chrome/
|-- crashtests/
|-- marionette/
|-- m
On Thu, Nov 1, 2012 at 10:24 AM, Gavin Sharp wrote:
> On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey wrote:
> > Not if the pref isn't set. If the pref is set I suspect it still returns
> > an object with the relevant properties, but that object is no longer a
> > BackstagePass. I haven't verified
On 2012-11-02 12:12 AM, Nicholas Nethercote wrote:
On Thu, Nov 1, 2012 at 6:33 PM, wrote:
The tyranny of hierarchy never ends. Either we have subsidiarity for js and other
modules, or not. If "Gecko" is one big module -- ok, I get it. But you need a
principle for giving js its own tests whi
On 11/1/2012 9:19 PM, Dave Mandelin wrote:
> (a) How about building Windows with a newer version of MSVC, say 2012? (What
> version are we using now, anyway? The build instructions page says 2010 is
> official, but a tbpl log showed Visual Studio 9.0 on the path.) Maybe they
> have fixed bugs i
On 11/1/2012 8:47 PM, Dave Mandelin wrote:
I would prefer something like this:
|-- tests/
|-- browser-chrome/
|-- topic1 (omit this level if there would be only one)
|-- topic2
|-- [...]
|-- chrome/
|-- crashtests
On Fri, Nov 2, 2012 at 9:22 PM, L. David Baron wrote:
> Or were you talking about something else in terms of the mapping?
>
No. I agree with you.
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
On Friday 2012-11-02 16:10 +1300, Robert O'Callahan wrote:
> On Fri, Nov 2, 2012 at 2:53 PM, Dave Mandelin wrote:
>
> > Sure, it's not some grand thing. I just like things to be nicely
> > organized. And I really did find mochitest paths a hassle and a (small) tax
> > on development effort.
> >
>
On 11/02/2012 01:47 AM, Dave Mandelin wrote:
First, I want to try to pour some gasoline on the dying embers and
suggest that perhaps we should totally rearrange everything. As a
developer user of our testing systems, I always found it incredibly
irritating that there were test directories sprinkl
22 matches
Mail list logo
