For those interested, I've gone ahead and filed a bug to get the keyword
added:
https://bugzilla.mozilla.org/show_bug.cgi?id=785519
Thanks to everyone who provided feedback.
On 12-08-17 10:30 AM, Ralph Giles wrote:
On 12-08-16 6:01 PM, Anthony Hughes wrote:
(CCing dev-quality to reach a broa
On Fri, Aug 24, 2012 at 2:08 PM, Brian Smith wrote:
> Also, are you saying "if you are going to write a mochitest, then try to
> write a reusable test" or "if you are going to write a test, write a
> reusable test?" The reason I ask is that we're supposed to write xpcshell
> tests in preference t
Aryeh Gregor wrote:
> 1) Decide on guidelines for whether a test is internal or reusable.
> As a starting point, I suggest that all tests that are regular
> webpages that don't use any Mozilla-specific features should be
> candidates for reuse. Examples of internal tests would be tests
> written i
On 8/24/12 12:42 PM, Brian Smith wrote:
I do not think it is reasonable to require support for alternate build systems
for all of Gecko/Firefox.
But, let's say were were to divide the build into three phases:
1. Generate any generated C/C++ source files.
2. Build all the C/C++ code into librari
Gregory Szorc wrote:
> 4. Native support for list and maps. Make files only support strings.
> The hacks this results in are barely tolerable.
>
> 5. Ability to handle conditionals. We need to be able to
> conditionally define things based on the presence or value of certain
> "variables."
> e.g.
On Fri, Aug 24, 2012 at 2:44 AM, Neil wrote:
> Justin Lebar wrote:
>
>> %{C++
>> inline int32_t GetFoo() {
>>int32_t result;
>>nsresult rv = GetFoo(&result);
>>MOZ_ASSERT(NS_SUCCEEDED(rv));
>>return result;
>> }
>> %}
>>
>
> Alternative approach?
> inline int32_t Foo(int32_t re
>>> nsCOMPtr foo;
>>> int32_t f = foo->GetFoo();
>>>
>> Why was I expecting this to be Foo()? (Perhaps unreasonably.)
>
> Yeah, it should be Foo().
> File a bug?
I considered Foo(), but my concern was that, when we extend this to
attributes which return interfaces (e.g. nsIFoo), then Foo() versu
On Friday, August 24, 2012 10:32:46 AM UTC-4, Ted Mielczarek wrote:
> On Fri, Aug 24, 2012 at 9:17 AM, qheaden
> wrote:
>
> > Is there any special reason why an existing build system such as SCcons
> > couldn't be used as a new build system for Mozilla? I know the Mozilla
> > source has a lot
On Fri, Aug 24, 2012 at 9:17 AM, qheaden wrote:
> Is there any special reason why an existing build system such as SCcons
> couldn't be used as a new build system for Mozilla? I know the Mozilla source
> has a lot of special build instructions, but SCons does allow you to create
> your own spec
On Tuesday, August 21, 2012 7:36:26 PM UTC-4, Gregory Szorc wrote:
> tl;dr We're proposing moving away from Makefile's as the sole source of
>
> the build system definition. This will lead to faster build times.
>
> Bikeshedding^wFeedback on the file format is requested.
>
>
>
> The existing
On 08/24/2012 02:42 AM, Neil wrote:
Justin Lebar wrote:
So now you can do
nsCOMPtr foo;
int32_t f = foo->GetFoo();
Why was I expecting this to be Foo()? (Perhaps unreasonably.)
Yeah, it should be Foo().
File a bug?
I rejected the first approach because it meant that every call to G
Justin Lebar wrote:
%{C++
inline int32_t GetFoo() {
int32_t result;
nsresult rv = GetFoo(&result);
MOZ_ASSERT(NS_SUCCEEDED(rv));
return result;
}
%}
Alternative approach?
inline int32_t Foo(int32_t result = 0) {
GetFoo(&result);
return result;
}
--
Warning: May contain
Justin Lebar wrote:
So now you can do
nsCOMPtr foo;
int32_t f = foo->GetFoo();
Why was I expecting this to be Foo()? (Perhaps unreasonably.)
I rejected the first approach because it meant that every call to GetFoo from
XPCOM would need to go through two virtual calls: GetFoo(int32_t*) an
Makoto Kato wrote:
How about PRUptrdiff? Most cases can changes to uintptr_t.
Which surprised me, but then I guess NSPR didn't have a true uintptr_t type.
I did find one use of PRUptrdiff that should have been size_t though.
--
Warning: May contain traces of nuts.
__
Gregory Szorc wrote:
We want feedback on the file format to use for the new build manifest
files.
Is there a good reason to shoehorn everything into a single file format?
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-plat
15 matches
Mail list logo
