tanishiking

	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

tanishiking

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

• https://github.com/sjrd/scalajs-benchmarks/commits/wasm/
• https://github.com/sjrd/scalajs-benchmarks/commit/6bc8ad791076117c14c9b82d3d2cdd00cb69cb00

tanishiking

amm-intellij-example

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

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 --

tanishiking

diff --git a/sample/src/main/scala/Sample.scala b/sample/src/main/scala/Sample.scala
index 2bd374c..c861535 100644
--- a/sample/src/main/scala/Sample.scala
+++ b/sample/src/main/scala/Sample.scala
@@ -17,6 +17,7 @@ object Main {
 
   def main(args: Array[String]): Unit = {
     println("hello world")
+    val foo = new Foo
   }

tanishiking

Why

WebAssembly interacts with the external environment through imported and exported functions. If it's a simple function that takes an integer and returns an integer, there is no problem.

However, when trying to use complex data types (such as strings or arrays), the limitation of WebAssembly 1.0 having only 4 types (i32, i64, f32, f64) becomes an issue.

To represent strings or user-defined types, we have to represent it using these 4 types, and there are no predefined rules on how to represent them in linear memory. The consumers of these modules need to understand how these data structures are laid out in linear memory and implement glue code accordingly.

tanishiking

Why WASI?

To communicate with the systems provided by the operating system, you need to call system calls. However, WebAssembly is designed as a complete sandbox, and Wasm modules cannot directly access OS system calls.

To call system calls from Wasm, you need to import functions that have access to system calls from the host environment.

#[link(wasm_import_module = "syscall")]
extern "C" {
    fn write(pointer: i32, length: i32);

tanishiking

/**
  * The `String` class represents character strings. All string literals in Kotlin programs, such as `"abc"`, are
  * implemented as instances of this class.
  */
 public class String internal @WasmPrimitiveConstructor constructor(
     private var leftIfInSum: String?,
     @kotlin.internal.IntrinsicConstEvaluation
     public override val length: Int,
     private var _chars: WasmCharArray,

tanishiking

https://github.com/tanishiking/scala-wasm

• Basic mathematics
• class
• object (load module / store module)
• static function call
• virtual call
• interface call
• loop
• if/switch

tanishiking

The future of semanticDB, TASTy, and the overlap that they have #73

---

ckipp01

on Aug 22 Maintainer So I don't have a specific point to bring up for this topic, but lately on Discord there have been multiple different places where conversations about the usage of SemanticDB and TASTY are discussed. We currently have an ecosystem that heavily relies on semanticDB for tooling, but also TASTy is starting to be used in various places. There are also other tools/formats like SCIP that are using semanticDB to produce SCIP.

Especially to outsiders this web gets pretty confusing. Why do we need both? Can't X work for both use-cases, etc. I think it may be a good idea to have a session where we discuss the pros and cons of both and potentially look at solutions in tooling that only require using one these to avoid the situation where we have tools relying on both semanticDB and TASTy.