If you run jit-tests with the options -f --no-xdr it will print out the
command lines you need to use to run the failed tests individually.
--lrs
On Thu, Mar 11, 2021 at 12:05 PM Carsten Grzemba wrote:
> I attempt to build Firefox for Openindiana (Illumos). Some of the tests
> are failing:
> R
WebAssembly SIMD makes a large, common, and portable subset of the 128-bit
vector instructions in many CPUs available to WebAssembly programs. SIMD
helps speed up graphics, video/audio decoding/encoding, and machine
learning workloads, to mention some. It is one of the most-requested
features fro
I want to add that enabling shared memory in Firefox also enables wasm
thread operations [1]. That proposal is only at stage 2 in the Community
Group, but has been in Chrome release since v74, is used in live content on
the web (eg Google Earth), and is therefore in its final form for all
practica
Summary: Allow Wasm programmers and code generators to use short
fixed-length vector data and instructions in applications where those are
typically used by native code (media encoders/decoders/processors; numeric
kernels).
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1625130
Standard: https
Cranelift should be genuinely optional until further notice; to my
knownledge, no near-term product work in Firefox or SpiderMonkey depends on
Cranelift. Cranelift is present in Nightly but (so far as I can tell) not
in Release. It can be disabled in the JS shell by configuring with
--disable-cran
On Fri, Feb 2, 2018 at 2:45 PM, Tom Schuster wrote:
> Any additional ideas how to mitigate the risk here? Chrome seems to
> want to add a kill pref for this, from my experience more difficult
> for us with the way we define methods in SpiderMonkey. Should that be
> a requirement for shipping?
>
On Wed, Oct 4, 2017 at 6:15 PM, Jeff Griffiths
wrote:
> On Tue, Oct 3, 2017 at 6:33 PM, Brendan Barnwell
> wrote:
> ...
>
> > The difference between 12 and 24 tabs is meaningless. My usage
> of
> > Firefox involves large numbers of tabs, frequently exceeding 1000. This
> > use case is
On Thu, May 11, 2017 at 3:00 PM, Bobby Holley wrote:
> On Thu, May 11, 2017 at 2:48 PM, Lars Hansen wrote:
>
>> On Thu, May 11, 2017 at 10:55 AM, Martin Thomson wrote:
>>
>> > On Thu, May 11, 2017 at 5:57 PM, Lars Hansen
>> wrote:
>> > > We do thin
On Thu, May 11, 2017 at 10:55 AM, Martin Thomson wrote:
> On Thu, May 11, 2017 at 5:57 PM, Lars Hansen wrote:
> > We do think there are
> > architectural improvements that hardware manufacturers, operating
> systems,
> > and browsers can make [19], and we intend to inves
We intend to enable the ECMAScript 2017 APIs *SharedArrayBuffer* and
*Atomics* by default in Firefox. The target release is* Firefox 55*, which
is set to ship on* 8 August, 2017*. The feature has been developed behind
the *javascript.options.shared_memory* flag.
The feature is also in Safari (v
sysconf(_SC_NPROCESSORS_ONLN) is used a number of places in the tree to get
a core count for parallel algorithms. The web says that that phrase does
not really return the number of available cores on ARM Linuxish systems in
general, including Android - because the return value does not account for
The baseline compiler has modest needs and should be able to target a
simple wasm interpreter fairly easily.
--lars
On Sun, May 22, 2016 at 11:08 PM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser
> wrote:
>
> > On 5/18/16 10:41 PM, Jan
ill ultimately make the decision to enable the feature,
balancing a possible information leak problem against the evolution of the
web platform.
--lars
On Fri, Mar 4, 2016 at 1:08 PM, Eric Rescorla wrote:
>
>
> On Thu, Mar 3, 2016 at 11:39 PM, Lars Hansen wrote:
>
>> On
the 5usec
boundary will be maintained" is a request not to turn this on, period.
--lars
>
> --Richard
>
>
> On Fri, Jan 15, 2016 at 12:10 AM, Lars Hansen wrote:
>
>> It's not enabled by default because the API is probably not fully baked
>> yet; until the spe
It's not enabled by default because the API is probably not fully baked
yet; until the spec reaches Stage 3 at TC39 we should expect things to be
fluid. I don't expect that milestone to be reached until this summer.
We've discussed enabling by default on Aurora, DevEd, and Beta once we
reach Stag
tly, this will still remain disabled by
> default on all branches. However it will now be possible to test out
> on all branches by flipping a pref?
>
> If so that sounds great to me.
>
> / Jonas
>
> On Thu, Jan 14, 2016 at 5:16 AM, Lars Hansen wrote:
> > Until now t
e a better fit for straight JS programming. I'm hoping that we can use
the current low level mechanisms to prototype higher level ones, and
eventually standardize some of them. I don't know how well we can
prototype TM like that - but it's early days still.
--lars
> Best regar
Until now the new SharedArrayBuffer constructor and the new Atomics global
object [1] have been enabled on Nightly only. Starting with Firefox 46,
those bindings will still be enabled by default on Nightly but they will
also be available on Aurora, DevEd, Beta, and Release by flipping the value
of
I believe JXCore has a version (listed as "beta") using our JS engine.
--lars
On Sat, May 16, 2015 at 8:06 PM, Yonggang Luo wrote:
> I've found Microsoft already done that.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://
> From: "Ehsan Akhgari"
> Sent: Tuesday, August 26, 2014 5:03:31 PM
> Subject: Re: Switching to Visual Studio 2013
>
> I would like us to update the minimum supported MSVC version to 2012 as
> soon as possible. That will give us access to the following C++
> features which are all supported on g
20 matches
Mail list logo
