Rikito Taniguchi tanishiking

Create a Service Account https://developers.google.com/identity/protocols/oauth2/service-account?hl=en#creatinganaccount That account should be able to read/write to the firestore.
Download the service account key to the current directory.
Run scala-cli main.scala --

amm-intellij-example

Not sure why ivy imports are marked red, but everything works fine 👍

Benchmarked against https://github.com/tanishiking/scala-js/tree/opt%2Btyped-closures that contains the following changes.

CI ONLY Enable the optimizer with WebAssembly. by sjrd · Pull Request #4993 · scala-js/scala-js
RFC: Introduce TypedClosures in the IR, which are closures without JS interop. by sjrd · Pull Request #5003 · scala-js/scala-js

The benchmark is

	wasm	js	wasm / js
sha512	12368.78034	69356.554	0.1783361431
sha512int	12078.89027	18342.09272	0.6585339229
queens	3.299606497	9.262363477	0.3562380709
list	76.06484363	142.8739845	0.5323911412
richards	92.35085892	130.1592505	0.7095220552
cd	40129.51947	62085.45494	0.6463594332
gcbench	111415.1666	135005.6104	0.8252632331
tracerFloat	1048.518644	1280.901067	0.8185789445

Wasm-Native String

I attempted to implement a String representation in our Wasm backend using an i16 array with WasmGC. However, we cannot simply switch the String representation from a JS String to an i16 array, as we still rely on JS Strings for JS interoperation. The plan is to allow these two String representations to coexist, using i16 arrays wherever possible while retaining JS Strings where necessary. This way, we should be able to keep the test suites passing, start using i16 arrays, and gradually remove JS interoperation.

To achieve this, we need to convert between JS Strings and i16 array Strings. The main idea is to

convert an i16 array String to a JS String when upcasting String into Any and
convert a JS String into an i16 array when down casting from Any to String
Additionally, we must handle conversions between JS Strings and i16 arrays when passing Strings between non-JS and JS classes (because we keep using JSStrings inside the JSClasses).
Select from JSClass fro

How to proceed the development to standalone wasm

We (I?) want to make the scala-js wasm backend generate wasm binaries that can run on stand-alone wasm runtime. However, that requires a lot of changes, and most of them are not self-contained (for example, WASI preview 1/2 support alone doesn't mean anything to users).

It's not desirable to add such non-self-contained changes to the main branch of scala-js. Only changes that are meaningful to users should be merged into the main branch.

Therefore, if we use the main branch as the target branch for stand-alone wasm development, we'll inevitably end up holding a gigantic changes locally and submitting extremely large pull requests. This puts a significant burden on reviewers and is undesirable. We want to proceed with frequent reviews and agreements among tanishiking, sjrd, and gzm0 on changes.

LoopInvariantCodeMotion - wasm-opt

Flattening

TL;DR: We would need running --flatten pass before --licm to make LICM work.

;; test.wat
(module
  (global $x (mut i32) (i32.const 0))
  (func (export "test")
 (result i32)

$ wasm-tools parse itoa.wat -o itoa.wasm

import { readFileSync } from "node:fs";
const wasmBuffer = readFileSync("itoa.wasm");
const importObj = {}
const wasmModule = await WebAssembly.instantiate(wasmBuffer, importObj, { builtins: ['js-string'] });
const { test } = wasmModule.instance.exports;

	(component
	(type (;0;)
	(instance
	(export (;0;) "error" (type (sub resource)))
	)
	)
	(import "wasi:io/[email protected]" (instance (;0;) (type 0)))
	(alias export 0 "error" (type (;1;)))
	(type (;2;)
	(instance

	theme = afterglow
	fullscreen = true

	# font
	font-size = 17
	font-thicken = true
	font-thicken-strength = 1

	cursor-style = block
	cursor-opacity = 0.6