Any conclusions out of the discussion here? Try is getting slower as we
speak...
I would opt to less disruptive way at first, per what Brian Grinstead said.
We don't even have to implement interactive prompt first. If that makes
people cancel old Try runs more, great, if not, we could consider oth
On Fri, Apr 22, 2016 at 1:05 AM, Nicholas Nethercote
wrote:
> The third example I looked at was CycleCollectedJSRuntime. Again
> problems, specifically this line in Init():
>
> mOwningThread->SetScriptObserver(this);
Others have already said what I would have here generally, but this
example is
Pointers are prefereable for outparams because it makes it clearer
what's going on at the callsite. (at least indicating that something
non-trivial is happening)
On Wed, Apr 20, 2016 at 8:07 PM, Kan-Ru Chen (陳侃如) wrote:
> Nicholas Nethercote writes:
>
>> Hi,
>>
>> C++ constructors can't be made
FWIW, I use static Create functions for fallible heap-only objects,
and StackFallible::ctor(bool* const out_success/error) for the rarer
fallible stack-createable objects.
It sounds like this lines up with existing proposals here.
Example fallible heap-only:
https://dxr.mozilla.org/mozilla-centra
On 4/21/16 11:00 AM, Richard Barnes wrote:
This is clearly a powerful feature, so it's a natural candidate for
restriction. Chromium is restricting all of navigator.geolocation as of 50:
https://codereview.chromium.org/1530403002/
Just to be clear, Firefox will still allow getCurrentPosition(
On 20/4/16 20:14, Ben Hearsum wrote:
This would require a new update channel to support, because it would be
a unique line of code that isn't "release" or "esr".
It couldn't be implemented as a relbranch either, because we'd need CI
for it. You're basically proposing a long lived esr-like branch
This is clearly a powerful feature, so it's a natural candidate for
restriction. Chromium is restricting all of navigator.geolocation as of 50:
https://codereview.chromium.org/1530403002/
Our telemetry shows that only ~0.1% of the usage of watchPosition() is in
non-secure contexts.
http://mzl.l
Agreed! Thanks to you, Ralph, and everyone (especially the build
peers!) who has been providing feedback/reviews and trying to stand up
examples integrating various Rust or Servo code into Gecko so that we
could find the blockers quickly.
For people who would like to follow along without adding th
Hi all,
I wrote some tools a while back intended to make it possible to do complex
crash stats queries locally, using downloaded crash stats data. It can do
queries using a mongodb-like query language; even based on functions (running a
function on each crash to decide whether it should be inc
More evidence that our coding conventions need an owner...
-j
On Wed, Apr 20, 2016 at 10:07 PM, Kan-Ru Chen (陳侃如)
wrote:
> Nicholas Nethercote writes:
>
> > Hi,
> >
> > C++ constructors can't be made fallible without using exceptions. As a
> result,
> > for many classes we have a constructor
On 4/20/16 11:53 AM, Armen Zambrano G. wrote:
> Would it make more sense to have a relbranch instead of using ESR?
Oh lordy, no! It's hard enough diverting engineering work to supporting
a single ESR 9 months after the fork. Why would we do two of them? How
would a relbranch differ from ESR?
> II
On Thu, Apr 21, 2016 at 3:24 AM, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva
> wrote:
> > Fallible construction (even with a way to report failure) is annoying if
> > only because the object's destructor has to account for the possible
> > invalid states. I much p
Thanks, Nathan. This is really great to see!
-r
On Thu, Apr 21, 2016 at 7:57 AM, Nathan Froyd wrote:
> Bug 1163224 has landed on inbound, which means that Gecko builds with
> --enable-rust now support multiple Rust crates. This change is
> intended to make the lives of people developing Rust c
Your example is suffering from the fact that PR_CreateThread is taking
as parameter an object that is half-initialized, and then continues
constructing it. I believe this to be a poor design and that
unfortunately leaks into the creating of nsThread.
In such a situation I would personally still us
Bug 1163224 has landed on inbound, which means that Gecko builds with
--enable-rust now support multiple Rust crates. This change is
intended to make the lives of people developing Rust components
easier, and it comes with several caveats:
1) There is zero support for interdependencies between cr
On Thu, Apr 21, 2016 at 8:41 PM, Martin Thomson wrote:
>
>> - I suspect that in some heap-allocated objects it will be hard to do
>> the fallible parts without having an object of the relevant type. I
>> don't have specific examples, just a hunch.
>
> I'm not aware of any way that necessary state
> * Lack of SSE2, though not an XP problem per se, coincides with XP,
so we could just require SSE2 if we didn't support XP.
We have data about this. Unfortunately we'd also have to kick out some
Windows 7 users. For every ten WinXP Firefox users without SSE2 we have a
Win7 Firefox user without S
I prefer the fallible, if failed return null else return new pattern
myself also. With a little RAII, it keeps manual cleanup to a
minimum.
On Thu, Apr 21, 2016 at 8:24 PM, Nicholas Nethercote
wrote:
> - It doesn't appear to work with stack-allocated objects?
The advantage with a heap-allocated
FWIW, bug 1265035 was an example that got me thinking about this whole
thing, and it was a crash involving a stack-allocated object
(WorkerJSRuntime) in which initialization failed.
On Thu, Apr 21, 2016 at 8:35 PM, Nicolas Silva wrote:
> My experience is that stack allocated objects tend to be si
My experience is that stack allocated objects tend to be simpler,
shorter-lived and less prone to accumulating invalid state somewhere and
crash somewhere else. All in all they haven't been a source of pain the
way heap-allocated objects often are when it comes to invalid state
creeping up. There t
On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva wrote:
> Fallible construction (even with a way to report failure) is annoying if
> only because the object's destructor has to account for the possible
> invalid states. I much prefer having a static creation method that will
> only instantiate the o
Fallible construction (even with a way to report failure) is annoying if
only because the object's destructor has to account for the possible
invalid states. I much prefer having a static creation method that will
only instantiate the object in case of success, and mark the constructor
protected. S
On Thu, Apr 21, 2016 at 7:57 AM, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla wrote:
> > The general problem that
> > it doesn't alleviate is that failure to check the return value leaves you
> > with a reference/pointer to an object in an ill-defined half-construc
On 4/20/16 11:43 PM, Gerald Squelart wrote:
How about another generic helper, e.g.:
template
Maybe MakeCheckedMaybe(Args&&... aArgs)
{
nsresult rv;
Maybe m = Some(T(std::forward(aArgs)..., &rv));
if (NS_SUCCEEDED(rv)) {
return m;
}
return Nothing();
}
Existing
24 matches
Mail list logo