Whatever you do, please, please, please make sure that everything is
worker-friendly.
If we can't write (or at least read) contents to that Key-Value store from a
worker, we will need to reimplement everything in a few months.
Cheers,
David
- Original Message -
From: Gregory Szorc
Bug 1231711, but I never got to do it, unfortunately.
On 26/01/17 08:01, zbranie...@mozilla.com wrote:
> On Thursday, November 10, 2016 at 5:15:26 AM UTC-8, David Teller wrote:
>> Ok. My usecase is the reimplementation of OS.File in Rust, which should
>> be pretty straightforward
wrote:
> On 9/24/2016 5:13 PM, David Teller wrote:
>> Which begs the question: what's the point of `Cu.import` these days?
>
> One major difference between Cu.import and ES6/require-style modules is
> that only one version of the script is created with Cu.import. This
&g
I agree that my formulation was poor, but that's what I meant: in *a
single webpage*, all these modules behave the same wrt the underlying
objects.
On 26/09/16 18:14, Boris Zbarsky wrote:
> On 9/26/16 12:09 PM, David Teller wrote:
>> In web content, that's also the case with ES6 an
Once again, there have been discussions on the feasibility of adding
static analysis to our JS code, possibly as part of MozReview. As usual,
one of the main problems is that we are not using standard JS, so we
pretty much cannot use standard tools.
One of the main differences between
On 27/09/16 11:58, Gijs Kruitbosch wrote:
> On 27/09/2016 10:28, David Teller wrote:
>> How hard would it be to consider all chrome code (of a JSRuntime) as a
>> single webpage? That's pretty much a requirement for any module loader
>> we would use for our chrome code.
>
I have opened bug 1305669 with one possible strategy for migrating
towards RequireJS.
Cheers,
David
On 25/09/16 01:16, Bobby Holley wrote:
> If the conversion is tractable and we end up with module ergonomics that
> frontend developers are happy with, I'm certainly in favor of this from
> the
I have posted a draft of a plan for migrating from JSM to ES6 modules here:
https://gist.github.com/Yoric/2a7c8395377c7187ebf02219980b6f4d
Cheers,
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 26/09/16 19:50, zbranie...@mozilla.com wrote:
> So, it seems to me that we're talking about two aspects of module loading:
>
>
> 1) Singleton vs. per-instance
>
> Cu.import allows us to share a single object between all the code that
> references it.
>
> ES6 modules are not meant to do
github.com/Yoric/777effee02d6788d3abc639c82ff4488
[2] https://gist.github.com/Yoric/2a7c8395377c7187ebf02219980b6f4d
On 28/09/16 00:42, Kris Maglione wrote:
> On Sun, Sep 25, 2016 at 12:13:41AM +0200, David Teller wrote:
>> So, can anybody think of good reason to not do this?
>
>
to these.
Cheers,
David
[1] https://flowtype.org/docs/modules.html#_
On 27/09/16 17:00, David Bruant wrote:
> Le mardi 27 septembre 2016 14:49:36 UTC+2, David Teller a écrit :
>> I have opened bug 1305669 with one possible strategy for migrating
>> towards RequireJS.
&g
What's the current status of the implementation of ES6 modules? Also, to
use them in chrome code, can we support synchronous loading? Or would we
need to make the rewrite more complicated to support asynchronous loading?
On 25/09/16 02:35, Bill McCloskey wrote:
> If we're going to do a mass
C+1, David Teller wrote:
>> What's the current status of the implementation of ES6 modules?
>
> ES6 modules are supported for chrome code, but not yet for content (pending
> spec related discussions that are not relevant for chrome).
>
> It would be great if we could moving to us
On 27/09/16 19:35, Zibi Braniecki wrote:
> On Tuesday, September 27, 2016 at 2:28:54 AM UTC-7, David Teller wrote:
>> If I understand ES6 modules correctly, two imports from the same webpage
>> will return the same module instance, right?
>
> I don't think this is a cor
\o/
Do we already have a story for implementing WebIDL in Rust?
Cheers,
David
On 09/11/16 12:20, Ted Mielczarek wrote:
> I recently wrote some documentation on how to add Rust code to Gecko:
> http://gecko.readthedocs.io/en/latest/build/buildsystem/rust.html
>
> It should be fairly
tricky it is to handle with a combo of Rust and C++.
Thanks,
David
On 10/11/16 02:43, Bobby Holley wrote:
> On Wed, Nov 9, 2016 at 12:31 PM, David Teller <dtel...@mozilla.com
> <mailto:dtel...@mozilla.com>> wrote:
>
> \o/
>
> Do we already have a story f
To build upon the "tab bar" idea: scrolling quickly among my 300+ tabs.
On 03/01/17 21:50, sev...@gmail.com wrote:
> Off the top of my head ideas:
>
> Quick-access to the back, forward, refresh, bookmark, share buttons could be
> a good. Tab bar might be handy too, so with a touch of my finger
Node dependency trees tend to be pretty large, so I'm a little concerned
here. Has the memory footprint be measured?
Cheers,
David
On 31/07/17 19:45, Michael Cooper wrote:
> If you mean using modules from NPM in a browser add-on, the Shield client
> extension recently started doing this <
>
Should we moz-prefix moz-specific extensions?
On 25/07/17 20:45, Jet Villegas wrote:
> Based on product plans I've heard, this sounds like the right approach. We
> should try to limit the scope of such browser-specific APIs but it's likely
> necessary in some cases (e.g., in the devtools.)
>
>
Thanks for starting this conversation. I'd love to be able to use more
Rust in Firefox.
In SpiderMonkey, the main blocker I encounter is interaction with all
the nice utility classes we have in C++, in particular templatized ones.
Also, for the rest of Gecko, my main blocker was the lack of
t 6:20 AM, Andrew Overholt <overh...@mozilla.com> wrote:
>> On Tue, Jul 25, 2017 at 3:06 PM, David Teller <dtel...@mozilla.com> wrote:
>>> Should we moz-prefix moz-specific extensions?
>>
>> We have been trying not to do that for Web-exposed APIs but maybe t
Hey, all cool kids have exciting Engineering Newsletters these days, so
it's high time the JavaScript Binary AST got one!
# General idea
JavaScript Binary AST is a joint project between Mozilla and Facebook to
rethink how JavaScript source code is stored/transmitted/parsed. We
expect that this
Out of curiosity, how will this interact with nsCOMPtr thread-safe (or
thread-unsafe) refcounting?
Also, in code I have seen, `NS_IsMainThread` is used mainly for
assertion checking. I *think* that the semantics you detail below will
work, but do you know if there is a way to make sure of that?
On 6/13/17 5:37 PM, Nicolas B. Pierron wrote:
> Also, the chrome files are stored in the jar file (If I recall
> correctly), and we might want to generate the bytecode ahead of time,
> such that users don't have to go through the encoding-phase.
How large is the bytecode?
I suspect that if
Hi everyone,
Yesterday, Nightly was broken on Linux and MacOS because of a typo in
JS code [1]. If I understand correctly, this triggered the usual
"undefined is not a function", which was
1/ uncaught during testing, as these things often are;
2/ basically impossible to diagnose in the
On 18/10/17 10:45, Gregory Szorc wrote:
> I agree that errors like this should have better visibility in order to
> help catch bugs.
>
> I'm not sure changing behavior of the JS VM is the proper layer to
> accomplish this. I think reporting messages from the JS console is a
> better place to
> I'm not sure changing behavior of the JS VM is the proper layer to
> accomplish this. I think reporting messages from the JS console is a
> better place to start. We could change the test harnesses to fail tests
> if certain errors (like SyntaxError or TypeError) are raised. If there
> is a
This should be feasible.
Opening bug 1409852 for the low-level support.
On 18/10/17 22:22, Dan Mosedale wrote:
> Could we do this on a per-module opt-in basis to allow for gradual
> migration? That is to say, assuming there's enough information in the
> stack to tell where it was thrown from
Btw, I believe that there is already support for reporting uncaught
errors and that it is blocked by the lack of test harness support.
Cheers,
David
On 18/10/17 19:37, Steve Fink wrote:
> My gut feeling is that you'd only want uncaught errors, and
> AutoJSAPI::ReportException is a better place
On 18/10/17 14:16, Boris Zbarsky wrote:
> On 10/18/17 4:28 AM, David Teller wrote:
>> 2/ basically impossible to diagnose in the wild, because there was no
>> error message of any kind.
>
> That's odd. Was the exception caught or something? If not, it should
> have
As a user, I would definitely love to have this.
I wanted to add something like that to about:performance, but at the
time, my impression was that we did not have sufficient platform data on
where allocations come from to provide something convincing.
Cheers,
David
On 02/11/17 15:34, Randell
Pretty complicated in the general case but might be simple in the case
of number overflow.
Also, while we shouldn't depend on the UI in libpref, could we send some
kind of event or observer notification that the UI could use to display
a detailed error message? It would be a shame if Firefox was
That would be great!
On 03/01/18 23:09, Gabriele Svelto wrote:
> TL;DR this is a proposal to refactor the observer service to use a
> machine-generated list of integers for the topics (disguised as enums/JS
> constants) instead of arbitrary strings.
>
Out of curiosity, why is the read handled by C++ code?
On 12/03/2018 10:38, Nicholas Nethercote wrote:
> I don't know. But libpref's file-reading is done by C++ code, which passes
> a string to the Rust code for parsing.
>
> Nick
> ___
> dev-platform
On 09/03/2018 19:39, Gregory Szorc wrote:
> On Fri, Mar 9, 2018 at 7:28 AM, David Teller <dtel...@mozilla.com
> <mailto:dtel...@mozilla.com>> wrote:
>
> I'll need a license review for a vendored Rust package. Who can perform
> these reviews these days?
&g
I'll need a license review for a vendored Rust package. Who can perform
these reviews these days?
Thanks,
Yoric
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
# Summary
JavaScript parsing and compilation are performance bottlenecks. The
JavaScript Binary AST is a domain-specific content encoding for
JavaScript, designed to speed up parsing and compilation of JavaScript,
as well as to allow streaming compilation of JavaScript (and possibly
streaming
No plans yet, but it's a good idea. The only reason not to do this (that
I can think of) is that we might prefer switching to the Bytecode Cache,
which would probably give us even better speed ups.
I understand that we can't use the Bytecode Cache for our chrome code
yet due to the fact that it
Ideally, I'd like to put a few well-known frameworks in jsapi tests, to
be used as data for SpiderMonkey integration tests.
What's our policy for this? Are there any restrictions? All the
frameworks I currently have at hand are have either an MIT- or an
MIT-like license, so in theory, we need to
Hi Aaron,
It sounds cool, but I'm trying to understand what it means :) Do I
understand correctly that the main benefit is security?
Cheers,
David
On 27/09/2018 17:19, Aaron Klotz wrote:
> Hi everybody,
>
> Yesterday evening bug 1488554 [1] merged to mozilla-central, thus
> enabling the
Hi everybody,
My last two attempts to update our crates with `./mach vendor rust`
failed, not during vendoring, but when I attempted to upload the patch.
Both times, moz-phab/arcanist or phabricator simply choked during the
call and I gave up after waiting 24h for the patch to be
Nov 21, 2018 at 10:22:38AM -0500, Nathan Froyd wrote:
>> On Wed, Nov 21, 2018 at 4:45 AM David Teller wrote:
>>> What is our policy on using Unix signals on Firefox? I am currently
>>> reviewing a patch by external contributors that involves inotify's
>>> sign
Dear platformers,
What is our policy on using Unix signals on Firefox? I am currently
reviewing a patch by external contributors that involves inotify's
signal API, and I assume it's a bad idea, but I'd like to ask around
first before sending them back to the drawing board.
Cheers,
I find them extremely useful, too (as in "removing them would make my
life miserable in quite a few bugs"). I have no problem with putting
them on a separate line.
Cheers,
David
On 26/01/2019 15:19, Jonathan Watt wrote:
> Personally I find them useful. Putting them on a separate line seems
>
Have you looked at nsIAsyncShutdown?
On 07/06/2019 08:18, Henri Sivonen wrote:
> For late shutdown cleanup, we have nsLayoutStatics::Shutdown(). Do we
> have a similar method for running things as soon as we've decided that
> the application is going to shut down?
>
> (I know there are observer
Even on Desktop, we needed to move some cleanup to startup, in case the
process was killed by the OS.
On 07/06/2019 20:40, Chris Peterson wrote:
> On 6/7/2019 9:36 AM, Kris Maglione wrote:
>> On Fri, Jun 07, 2019 at 09:18:38AM +0300, Henri Sivonen wrote:
>>> For late shutdown cleanup, we have
On 10/06/2019 10:28, Henri Sivonen wrote:
>>> Observers are automatically cleaned up at XPCOM shutdown, so you
>>> generally don't need to worry too much about them. That said,
>>> nsIAsyncShutdown is really the way to go when possible. But it currently
>>> requires an unfortunate amount of
That sounds useful :)
Do we have any documentation on how to add documentation?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
I'm sure that Searchfox could have useful highlights.
However, as you guessed, this was something that happened within an
editor + debugger, so there's only so much we can do in this direction.
Cheers,
David
On 06/09/2019 15:40, Andrew Sutherland wrote:
> On 9/6/19 7:31 AM, David Teller wr
Very good news!
Does this have any impact on SpiderMonkey error handling?
Cheers,
David
On 14/09/2019 06:47, Boris Zbarsky wrote:
> Hello,
>
> ErrorResult has two kinds of exception-throwing APIs on it: the older
> ones that don't allow specifying a custom message string, and newer ones
>
For what it's worth, I recently spent half a day attempting to solve a
bug which would have been trivial if `a` and `m` prefixes had been
present in that part of the code.
While I find these notations ugly, they're also useful.
Cheers,
David
On 06/09/2019 12:57, Honza Bambas wrote:
> On
I believe in least surprise for the caller of an API. This seems to
match with the Google style, as you describe it: any parameter which may
be mutated in any manner should be passed as pointer, rather than reference.
Cheers,
David
On 22/07/2019 08:43, Karl Tomlinson wrote:
>
The Google style sounds pretty good to me.
On 04/07/2019 07:11, Gerald Squelart wrote:
> Recently I coded something with a not-very-important slow-changing
> rarely-used positive number: `unsigned mGeneration;`
> My reviewer commented: "Please use a type with an explicit size, such as
>
For what it's worth, when I last tried, I couldn't even `moz-phab
submit` a self-reviewed patch. I had to arbitrarily pick another
reviewer for a patch that was not meant for landing (it was a
demonstration of a reproducible bug in phabricator, but that's another
story).
Cheers,
Yoric
On
That's cool!
I wonder if there is (or will be) a way to somehow preserve the naming
part of NS_NewNamedThread, which is sometimes precious for debugging,
i.e. somehow attach to the background thread a debugging information in
addition to the stack that would let us analyze what the thread was
Out of curiosity, what external application? OS-specific?
On 19/03/2020 01:24, Michal Novotny wrote:
> We plan to remove FTP protocol implementation from our code. This work
> is tracked in bug 1574475 [1]. The plan is to
>
> - place FTP behind a pref and turn it off by default on 77 [2]
> -
That's an impressive speedup!
Congrats on enabling this, everyone.
On 24/09/2020 14:56, Jan de Mooij wrote:
Warp is now enabled by default on Nightly, after positive feedback
from users dogfooding it [0,1].
Here are just a few of the Talos/Raptor graphs showing improvements
when Warp landed:
57 matches
Mail list logo
