Re: Is --disable-libjpeg-turbo gone?
On 2020/05/16 7:51, Mike Hommey wrote: On Sat, May 16, 2020 at 07:24:44AM +0900, ISHIKAWA,chiaki wrote: I have --disable-libjpeg-turbo in my mozconfig for many years (I build TB locally). After an update of the local source tree this morning, it is no longer recognized? (The last update was several days ago.) Has anyone also experienced this? Traceback (most recent call last): File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 181, in sys.exit(main(sys.argv)) File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 52, in main sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure')) File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/python/mozbuild/mozbuild/configure/__init__.py", line 494, in run raise InvalidOptionError(msg) mozbuild.configure.options.InvalidOptionError: Unknown option: --disable-libjpeg-turbo *** Fix above errors and then restart with\ "./mach build" make: *** [client.mk:115: configure] Error 1 I removed it in bug 1638195, but it hasn't done anything since bug 1515852. Mike Thank you for the pointer. Does this mean I can safely remove --disable-libjpeg-turbo? [I am not sure why I have this. It has been there for years, and I forgot about it. Possibly YASM dependency issues mentioned in the bug under Debian GNU/Linux.] Or should I say explicitly --with-system-jpeg in mozconfig? TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is --disable-libjpeg-turbo gone?
On Sat, May 16, 2020 at 07:24:44AM +0900, ISHIKAWA,chiaki wrote: > I have --disable-libjpeg-turbo in my mozconfig for many years (I build TB > locally). > > After an update of the local source tree this morning, it is no longer > recognized? > (The last update was several days ago.) > > Has anyone also experienced this? > > Traceback (most recent call last): > File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 181, in > > sys.exit(main(sys.argv)) > File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 52, in main > sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure')) > File > "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/python/mozbuild/mozbuild/configure/__init__.py", > line 494, in run > raise InvalidOptionError(msg) > mozbuild.configure.options.InvalidOptionError: Unknown option: > --disable-libjpeg-turbo > *** Fix above errors and then restart with\ > "./mach build" > make: *** [client.mk:115: configure] Error 1 I removed it in bug 1638195, but it hasn't done anything since bug 1515852. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Is --disable-libjpeg-turbo gone?
I have --disable-libjpeg-turbo in my mozconfig for many years (I build TB locally). After an update of the local source tree this morning, it is no longer recognized? (The last update was several days ago.) Has anyone also experienced this? Traceback (most recent call last): File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 181, in sys.exit(main(sys.argv)) File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/configure.py", line 52, in main sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure')) File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/python/mozbuild/mozbuild/configure/__init__.py", line 494, in run raise InvalidOptionError(msg) mozbuild.configure.options.InvalidOptionError: Unknown option: --disable-libjpeg-turbo *** Fix above errors and then restart with\ "./mach build" make: *** [client.mk:115: configure] Error 1 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: "JS BigInt to I64 integration" WebAssembly proposal
# Intent to ship: "JS BigInt to I64 integration" WebAssembly proposal This feature allows I64 values in WebAssembly to be exported to JavaScript as a BigInt value, or imported from JS from a BigInt. With this proposal implemented, all four value types in the WebAssembly MVP can be passed through the Wasm<->JS boundary, allowing for easier interoperation between the languages. This intent-to-ship is on behalf of Asumu Takikawa (in cc), who was experiencing some mail moderation issues. While they are being fixed, we wanted to get this intent-to-ship out there. ## Tracking bugs Implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1608770 Shipping: https://bugzilla.mozilla.org/show_bug.cgi?id=1631702 ## Standard https://github.com/WebAssembly/JS-BigInt-integration https://webassembly.github.io/JS-BigInt-integration/js-api/index.html The proposal very recently entered "phase 4" in the WebAssembly standardization process: https://github.com/WebAssembly/meetings/blob/master/2020/CG-05-12.md ## Platform coverage All ## Devtools support N/A. BigInts are displayed fine in the debugger. ## Restricted to secure contexts No. (Not a worry as no additional capabilities granted.) ## Is this feature enabled by default in sandboxed iframes? Yes. (Not a worry as no additional capabilities granted.) ## Estimated or target release 78 (soft freeze 28 May, train leaving 1 June) ## Support in other browser / JS engines Chrome / V8 implements the proposal. Staged in September 2019, not shipped yet: https://bugs.chromium.org/p/v8/issues/detail?id=7741 Support in emscripten: https://github.com/emscripten-core/emscripten/pull/10860 ## Upstream test coverage There are good tests in the proposal repository, which are not merged upstream into WPT yet but likely will be in the near future: https://github.com/WebAssembly/JS-BigInt-integration/tree/master/test ## Where to send your bugs Asumu Takikawa (:asumu). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
