On Wed, May 10, 2017 at 10:27 AM, Karl Tomlinson wrote:
>
> Or is NotNull really too awkward IRL?
>
I wrote NotNull.h, and I've used it in various places. I'm ambivalent about
it. It does make things clear, but it also is a bit annoying to use. The
code tends to end up with WrapNotNull() and get
On Wednesday 2017-05-10 02:43 +0200, Emilio Cobos Álvarez wrote:
> The issue I have with per-type conventions is that it doesn't scale very
> well, specially when you're writing new code (and more specially if
> they're not documented in the style guide).
>
> What should the convention be for `Ser
On Tue, May 09, 2017 at 02:11:41PM -0700, L. David Baron wrote:
> On Tuesday 2017-05-09 11:58 +0200, Emilio Cobos Álvarez wrote:
> > I think references help to encode that a bit more in the type system,
> > and help reasoning about the code without having to look at the
> > implementation of the fu
Nathan Froyd writes:
> I think a broader definition of "POD struct" would be required here:
> RefPtr and similar are technically not POD, but I *think* you'd
> want to require RefPtr* arguments when you expect the smart pointer
> to be assigned into? Not sure.
Yes, please, for similar reasons as
+cc Diego, who has experimented with packaging Firefox on Steam...
Thanks Alex,
It sounds as though we can work around all of these issues, based on your
feedback. I believe that we could proxy any file access needed by the content
process. The main process will need to access some resources
On Tue, May 9, 2017 at 12:05 PM, Boris Zbarsky wrote:
> On 5/9/17 11:41 AM, Nathan Froyd wrote:
>
>> I think I would feel a little
>> better about this rule if we permitted it only for types that deleted
>> assignment operators. Not sure if that's really practical to enforce.
>>
>
> Hmm. I wond
On Tuesday 2017-05-09 11:58 +0200, Emilio Cobos Álvarez wrote:
> I think references help to encode that a bit more in the type system,
> and help reasoning about the code without having to look at the
> implementation of the function you're calling into, or without having to
> rely on the callers t
On 08-05-17 19:26, Alex Gaynor wrote:
> Hi dev-platform,
>
> Top-line question: Do you rely on being able to run mochitests from a
> packaged build (`--appname`)?
It seems our Linux tests do, actually:
https://treeherder.mozilla.org/logviewer.html#?job_id=97391302&repo=try
"test-linux32/opt-moc
On 5/9/17 11:41 AM, Nathan Froyd wrote:
I think I would feel a little
better about this rule if we permitted it only for types that deleted
assignment operators. Not sure if that's really practical to enforce.
Hmm. I wonder what happens right now if you try to invoke
nsINode::operator=
On Tue, May 09, 2017 at 06:24:56PM +0300, smaug wrote:
> On 05/09/2017 04:52 PM, smaug wrote:
> > On 05/09/2017 01:55 PM, Mike Hommey wrote:
> > > On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
> > > > On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez
> > > > wrote:
> > > > >
On Mon, May 8, 2017 at 1:26 PM, Alex Gaynor wrote:
> Top-line question: Do you rely on being able to run mochitests from a
> packaged build (`--appname`)?
I don't think it's a *fundamental* part of development workflows, but
I know folks have found value in being able to run tests--including
but
On Tue, May 9, 2017 at 10:39 AM, Boris Zbarsky wrote:
> On 5/9/17 9:17 AM, Nathan Froyd wrote:
>> The argument I have always heard, Gecko-wise and elsewhere [1], is to
>> prefer pointers for modification
>
> This is for primitive-typed out or inout params, right?
I don't remember hearing any dist
On 05/09/2017 11:02 AM, Alex Gaynor wrote:
Hi Ehsan,
If we want to dig deeper, let's fork off another thread, but it sounds
like there's two action items here:
1) Fix https://bugzilla.mozilla.org/show_bug.cgi?id=1345046
2) Better document how to disable the sandbox for debugging -- where
wou
On 05/09/2017 04:52 PM, smaug wrote:
On 05/09/2017 01:55 PM, Mike Hommey wrote:
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
I think references help to encode that a bit more in the type system,
and help reasoning
Hi Ehsan,
If we want to dig deeper, let's fork off another thread, but it sounds like
there's two action items here:
1) Fix https://bugzilla.mozilla.org/show_bug.cgi?id=1345046
2) Better document how to disable the sandbox for debugging -- where would
you expect to find docs on this, https://wiki
Hi,
Hmm, VR appears to be an interesting challenge.
To expand a bit more on why mochitest+sandboxing is a challenge for
packaged builds: The way mochitest is set up is that there's a
configuration file which points to JS files to be loaded for tests. These
are loaded by the content process. This
Hi Alex,
Apologies for hijacking the thread, but since you asked, right now
debugging mochitest that you want to get some logging out of with a
sandboxed content process is super painful. I last hit it when I was
debugging a memory leak which typically requires getting refcount leak
logs and
On 5/9/17 9:03 AM, Bobby Holley wrote:
I think passing non-nullable things by reference is good, but I think we
should keep it consistent for a given type.
I should note that we already have this across all types to some extent:
WebIDL bindings pass non-nullable interface types as references,
On 5/9/17 9:17 AM, Nathan Froyd wrote:
On Tue, May 9, 2017 at 5:58 AM, Emilio Cobos Álvarez wrote:
Personally, I don't think that the fact that they're not used as much as
they could/should is a good argument to prevent their usage, but I don't
know what's the general opinion on that.
The arg
On 05/09/2017 01:55 PM, Mike Hommey wrote:
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
I think references help to encode that a bit more in the type system,
and help reasoning about the code without having to look
On Tue, May 9, 2017 at 5:58 AM, Emilio Cobos Álvarez wrote:
> Personally, I don't think that the fact that they're not used as much as
> they could/should is a good argument to prevent their usage, but I don't
> know what's the general opinion on that.
The argument I have always heard, Gecko-wise
As Henri indicates, I think the use of references is consistent with
the style guide.
It's also worth noting that if you are using boxed pointers, then you
almost certainly want to use references to pass them around. I.e.,
foo(const RefPtr& mPtr); // avoids useless ref count
foo(con
I think passing non-nullable things by reference is good, but I think we
should keep it consistent for a given type. So, for example, we shouldn't
have some callsites that take an nsPresContext* and others that take an
nsPresContext& (unless we have a rare case of a nullable presContext arg,
in whi
On 05/07/2017 07:34 PM, Kris Maglione wrote:
static inline Result
WrapNSResult(PRStatus aRv)
{
if (aRv != PR_SUCCESS) {
return Err(NS_ERROR_FAILURE);
}
return Ok();
}
static inline Result
WrapNSResult(nsresult aRv)
{
if (NS_FAILED(aRv)) {
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
> On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez
> wrote:
> > I think references help to encode that a bit more in the type system,
> > and help reasoning about the code without having to look at the
> > implementation of the f
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
> I think references help to encode that a bit more in the type system,
> and help reasoning about the code without having to look at the
> implementation of the function you're calling into, or without having to
> rely on the callers to
I like using reference to argument if it's non-nullable.
In Core::Editor module, such arguments are already replaced with
reference in a lot of places.
--
Masayuki Nakano
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.moz
nsIEditorIMESupport is an empty interface. Members were moved to
nsIEditor and nsIEditorIMESupport was made a subclass of it.
This interface is now completely unused. So, it should be removed from
the tree completely.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1325281
--
Masayuki Naka
Hi dev-platform@,
So, yesterday was working on a bug (bug 1362991, if you're curious) when
I decided to do some spring cleanup and pass some non-optional argument
as a reference instead of as a pointer.
I got the cleanup patch rejected, because it went against the prevailing
style of the codebase
On Tue, May 9, 2017, at 05:48 AM, Henri Sivonen wrote:
> On Thu, Apr 6, 2017 at 6:26 AM, Kyle Lahnakoski
> wrote:
> > * Getting Rust to emit coverage artifacts is important:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1335518
>
> Is there a plan to factor "cargo test" of individual vendored
On Thu, Apr 6, 2017 at 6:26 AM, Kyle Lahnakoski wrote:
> * Getting Rust to emit coverage artifacts is important:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1335518
Is there a plan to factor "cargo test" of individual vendored crates
into the coverage of Rust code? For example, for encoding_rs
MozPhonetic has an attribute, phonetic, whose type is DOMString. This is
available only in chrome.
https://searchfox.org/mozilla-central/rev/224cc663d54085994a4871ef464b7662e0721e83/dom/webidl/HTMLInputElement.webidl#220-224,227
Its XPCOM implementation is nsIPhonetic, which is inherited by
Edi
32 matches
Mail list logo
