swift-developers-japan

swift - The Swift Programming Language

swift - The Swift Programming Language

https://gist.github.com/hiragram/58b9dd4b69f2fdd66ad01fe2511d08a1

swift - The Swift Programming Language

3:22 PM

これ、今のSwiftじゃWebAssemblyできませんよでFAなのかな

3:22 PM

かなしい

swiftc本体からのwasmターゲットが駄目なだけじゃないか

む

これはwasmバイナリの生成パスでしょう

clang -emit-llvmとかそういう感じ？

LLVMIRを生成して、そこから先はemやclangの機能でもっていきたい

IRGen.cppでwasmサポート無いって言われてるから無いのかなーと判断したけど

3:25 PM

要はswiftcが-emit-irで asmjs-unknown-emscripten というターゲットでIRを吐く必要があるんじゃねという理解なんだけど

本来的に

3:27 PM

LLVMって言語→CPU中立なIR　のフロントエンドと、 IR -> アセンブリ　のバックエンドに

うん

分けたのが価値だったはずで

3:27 PM

でもなんでLLVMIRの生成にターゲットトリプルが絡んでくるのか

3:28 PM

そこがよくわかってない

CPU中立なIRっていうのはCPUに依存せず同じIRっていう意味であってる？

CPUの差と、実行ファイル形式の差(ELFとか)はまた別で、後者まではIR生成時に決まってしまうのかなあ

3:29 PM

そう

3:29 PM

同じIRからarmv7とかx86向けのアセンブリを作るのがバックエンド

つまりosxターゲットのIRとwasm用のIRが違うのがおやおやという感じなのよね

3:29 PM

そこはなんとなくわかる

osxターゲットというのはちょっと違う osxは armでもintelでも動くから

おう

で、osxの実行ファイルやstaticライブラリは Mach-O 形式

3:31 PM

あとemscriptenはもともと LLVM to JS なやつで

3:31 PM

wasmがないころからあったプロジェクトだから

3:31 PM

wasm object formatではない ELF や Mach から JSに持っていく機能があると思うんだけどなあ

3:33 PM

こまったなあ

僕もいろいろやってみる

@omochimetaru なんかググりのキーワードありませんか

3:36 PM

学びたい

キーワードはもう出てる限りだと思う

ヒィン

バイナリと実行ファイルのしくみについての知識が不足してそう

してる

急がば回れ感

そうね

少なくとも現時点で「こうやるとできる」ってテキストは見当たらないから

3:46 PM

なんとも

$ swiftc -emit-ir -Xcc --target=wasm32 first.swift -o first.ll

↑それだと昨日のfatalErrorのとこに行きそう

error.txt

4:34 AM

多分clangがSIGABRTで死んだ

4:34 AM

darwinが云々いわれているの、これLinuxで同じコマンド叩いたらしれっと通ったりしないかしら、というのを考えている

<unknown>:0: note: No available targets are compatible with this triple.

4:35 AM

死亡メッセージこれだね

でも、本当に存在しないやつとはエラーが違うのでなにかありそう

$ swiftc -emit-ir -Xcc --target=wasm32aaa first.swift -o first.ll <unknown>:0: warning: argument unused during compilation: '-mmacosx-version-min=10.9.0' <unknown>:0: error: -fobjc-arc is not supported on platforms using the legacy runtime <unknown>:0: error: unknown target triple 'wasm32aaa', please use -triple or -arch <unknown>:0: error: clang importer creation failed

5 swift 0x000000010f02cfe7 swift::performFrontend(llvm::ArrayRef<char const>, char const, void, swift::FrontendObserver)::$_0::invoke(void*, std::1::basic_string<char, std::1::char_traits<char>, std::1::allocator<char> > const&, bool) + 551

4:36 AM

clangじゃなくてswiftcだと思うよ

swiftcか

clangの関数とかも使って作ってるから

4:37 AM

clangっぽい関数も出てくる。

4:37 AM

エラーメッセージでswiftのソース検索すれば多分デル

4:37 AM

ていうか普通に swift::performFrontend じゃないかな

4:39 AM

https://github.com/apple/swift/blob/83ee8cb7f0eaef2f94efb760a7e29554e663bc2c/lib/FrontendTool/FrontendTool.cpp#L1237

https://llvm.org/docs/CommandGuide/llvm-as.html

swift - The Swift Programming Language

4:39 AM

さっきのメッセージはここからllvm内部から戻ってきてそう

DockerでUbuntuたててその中でやってみたけどやっぱSIGABRT

4:58 AM

Darwinとか言われなくなったけど多分Macでやったのと同じ話だとおもう

4:59 AM

お仕事もどります

error: <unknown>:0:0: in function _T01b3addS2i_SitF i64 (i64, i64): WebAssembly doesn't support non-C calling conventions

7:30 AM

define hidden swiftcc i64 @_T01b3addS2i_SitF(i64, i64) #0 { entry: %2 = call { i64, i1 } @llvm.sadd.with.overflow.i64(i64 %0, i64 %1) %3 = extractvalue { i64, i1 } %2, 0 %4 = extractvalue { i64, i1 } %2, 1 br i1 %4, label %6, label %5 ; <label>:5: ; preds = %entry ret i64 %3 ; <label>:6: ; preds = %entry call void @llvm.trap() unreachable }

7:31 AM

Swiftのトップレベル関数は swiftcc ってコンベンションになってて、 llc の wasm モードがそれをサポートしてないからダメっぽい

7:36 AM

LLVM自体は swiftcc のサポートがバックポートされてるっぽくて

おー

CallingConv::Swift で調べると lib/Target/X86とか lib/Target/ARMに

7:37 AM

CallingConv::Swift の分岐がある

7:37 AM

でも lib/Target/WebAssembly には無い

7:37 AM

これが一つの壁っぽい

これ誰の進化が必要なんだ

LLVMのwasmターゲットがswiftccをサポートする必要がある

7:39 AM

LLVMのIRまではswiftccがサポートされてるけどwasm仮想CPU向けが無いってこと

LLVM側かあ

wasmの関数呼び出しについて調べて、swiftcc周りのx86とarm周りの勉強をすれば

7:40 AM

ちょっと進むね。

けわしー❗

7:40 AM

けど興味あり

険しいけどちょっとおもしろそうだからいろいろ調べてみようかな

本家LLVMとSwiftのLLVMがどのくらい乖離してるのか見てるんだけど

10:17 AM

git show-branch llvm/master origin/swift-4.1-branch

.... + [origin/swift-4.1-branch~577] Canonicalize the spelling of RefDie (NFC) + [origin/swift-4.1-branch~578] dsymutil: strip unused types from imported DW_TAG_modules + [origin/swift-4.1-branch~579] Debug Info: Don't strip clang module skeleton CUs. ++ [llvm/master~5237] Recommit r274270, [CMake] Module builds depend on target intrinsics_gen to be built first.

10:18 AM

本家のmasterの5200コミット前と swift-4.1-branchの580コミット前に共通のコミットがあってそこからわかれてる、つまり5700コミットぐらい乖離している・・・？

おもしろ

commit 18e8f9ef0645b15c777547d8655a17a315b0815d Author: NAKAMURA Takumi <geek4civic@gmail.com> Date: Wed Jul 19 11:27:31 2017 +0000 Recommit r274270, [CMake] Module builds depend on target intrinsics_gen to be built first. The builder clang-x86_64-linux-selfhost-modules-2 complains. Investigating. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308439 91177308-0d34-0410-b5e6-96231b3b80d8

10:21 AM

その共通のコミットが2017年6月なんだけど

10:21 AM

半年間ぐらいSwift側の成果が本家に戻ってないってこと・・・？見方があってるのかよくわからない

10:26 AM

あ〜〜〜〜

10:26 AM

Swiftの方のLLVMだと、最近のWASM対応が入って無くて、 llc b.ll -march=wasm32 -filetype=asm -o b.s llc: error: invalid target 'wasm32'.

xcrun clang で動くclangは-target=wasm32使えたけどそういうもん？

llcはllvmのツールで

10:29 AM

clangはまた別管理だから

ふむ

それはあれだよね、C言語を .ll にするときに、ターゲットをwasm32にできるってことよね

そそ

10:30 AM

Cはできた。

その続きっていける？

emscripten？

clang: a.c => a.ll ( この続きは何を使う？ ) (edited)

あ

10:31 AM

できたって言ったのは .llじゃなくて .bc 吐くのだった

10:31 AM

xcrun clang -emit-llvm hoge.c -o hoge.bc

10:32 AM

.ll 吐いてその先は試してない

bcとllは同じもののバイナリとアスキー版じゃないんかな

そうなん？

bitcodeファイルはllvm-disコマンドでテキストのLLVM IRとして出力することができます。

へー

disってことは逆かなアスキーのIRがバイナリのbcになるんかな

なんとなく中間表現→ビットコードのイメージだった

10:34 AM

llvm-as is the LLVM assembler. It reads a file containing human-readable LLVM assembly language, translates it to LLVM bitcode, and writes the result into a file or to standard output.

10:34 AM

If the input is a file that ends with .ll, then the output file is of the same name, except that the suffix is changed to .bc.

10:34 AM

llvm-as で .ll が .bc になると

10:35 AM

https://llvm.org/docs/CommandGuide/llc.html

10:35 AM

で、llcで .ll または .bc がネイティブアセンブリ (.s) になりますよと

10:37 AM

で、wasm32な .s を吐ければ、あとは Wasmのツールの管轄

10:38 AM

Cから生成された .ll であれば llc で .s にできるけど、 swiftから生成された .ll は、 .ll の中で swiftcc などのSwift仕様が含まれていて、 llc が通らない。

10:38 AM

ってのがここまでの流れ。

llcをどうにかする方法を模索する流れ？

実装するしかないんじゃあないかなあ

おおごとになってきた

swiftc -emit-ir b.swift -o b.ll llc b.ll -o b.s libs=/Users/omochi/work/swift-source/build/Ninja-ReleaseAssert/swift-macosx-x86_64/lib/swift/macosx gcc -L$libs b.s -o b.out LD_LIBRARY_PATH=$libs ./b.out

2:09 PM

↑そもそも通常のswiftの場合で実行までの手順を調べた

2:11 PM

$ cat b.swift print("hello swift")

2:12 PM

printだけじゃなくて、 _swift_retain とかも外部リンクされているので

2:14 PM

wasmに乗っける時に持ってこないといけないんだけどそこらへんもやり方が謎

-static-stdlib の挙動について調べたけど、 /usr/bin/ld に -force_load_swift_libs を渡すようになっているだけで、

2:52 PM

/usr/bin/ld についてはオープンソースになってないから、何もわからんという結論になった

https://github.com/apple/swift-llvm/blob/stable/include/llvm/Target/TargetCallingConv.h#L39

apple/swift-llvm

Contribute to swift-llvm development by creating an account on GitHub.

3:50 PM

llvmの引数属性として Swiftの self 用とか Swift の error 用とか足してある

upstream-with-swiftっていうブランチがあるけど、CIは通ってないぽい。 https://ci.swift.org/view/swift-master-next/

Kotlin/Nativeはwasmを正式にサポートしているのね

昨日 LLVMの lib/Target をリーディングしてみたけど

1:49 AM

CPUに関する広くて深い知識が無いと何がなんだかわからん、ってなった

KotlinNativeがwasmサポートしたのごくごく最近だった。

7:03 AM

https://blog.jetbrains.com/kotlin/2017/11/kotlinnative-v0-4-released-objective-c-interop-webassembly-and-more/

Nikolay Igotti

Kotlin/Native v0.4 released: Objective-C interop, WebAssembly and more - Kotlin Blog

We’re happy to announce the release of Kotlin/Native v0.4, KotlinConf 2017 edition! This release adds support for accessing Objective-C APIs on iOS and macOS, WebAssembly target platform, as well as introduces major changes making app development in Kotlin/Native way easier. Platform … Continue reading →

7:04 AM

SwiftがどうにもならないとしたらKotlinでWebフロント開発のほうで遊んでようかな

KotlinNativeでwasm、 $ kotlinc -target wasm32 hello.kt で hello.wasm が直接吐かれて超楽っぽい。

6:22 AM

emscriptenいらずかも

よいね

6:33 AM

メモリ管理ってどうなってる？

どうなってるとは

Kotlin/Nativeってことだから、参照カウント方式だったと思うんだけど

6:33 AM

弱参照作れるの？

まだKotlinハローワールドしかしてないので答えを持っていない

6:33 AM

やっていく

想像なんだけど今は弱参照作れなくて循環参照で無限メモリリークだったりしない？

うーん

Kotlin/Native uses automated memory management, currntly based on automated reference counting with cycle collector. See here for details: https://github.com/JetBrains/kotlin-native/blob/master/runtime/src/main/cpp/Memory.cpp

JetBrains/kotlin-native

kotlin-native - Kotlin/Native infrastructure

6:40 AM

https://github.com/JetBrains/kotlin-native/issues/587

Question: GC or MM? · Issue #587 · JetBrains/kotlin-native

Will Kotlin native be garbage collected or managed manually like C, Rust, etc?

6:40 AM

まじかよサイクルコレクター入ってた

サイクルコレクターって何ですか

循環参照があってもメモリ解放してくれる機構のことです。

6:41 AM

pythonとphpに入ってるよ。

へえ

あ、それの、参照カウンタ方式のときに使うアルゴリズムのことね。

6:41 AM

普通のmark-sweep等のTrace GCなら循環の解放は当たり前なので。

6:43 AM

循環参照の問題が無いから特に何も書かれてないのかかっこいい

https://github.com/kripken/emscripten/issues/2427

Unable to compile a simple Swift file (maybe not possible?) · Iss...

Hi team, playing around with Emscripten in earnest for the first time, not my usual area of work so apologies if this is clearly never going to work. What I'd like to do is compile a simple Swift p...

2:45 PM

swift-wasmに進捗があったみたい

2:46 PM

The calling conventions are mostly for the backends, so it should be possible to just ignore it. That is, if swift didn't emit it, it should be ok, and for now you can strip it from the IR manually for testing. (There are exceptions like tail call optimizations that are done on IR and depend on the convention, but I don't think that would be an issue here.)

2:47 PM

swiftccコーリングコンベンションは普通に無視すればいいよってkripkenさんが言っていて、そのあと他の人が進捗してる

そのスレの最後にもあるし、さっきTwitterにも書いたけど

お？

swift-llvmがLLVM 6.0に追従したようなのでちょっと楽になるのかな https://github.com/apple/swift-llvm/pull/80 (edited)

Update stable branch with swift-4.2-branch by shahmishal · Pull R...

2:50 PM

WebAssembly backendがSwift付属のLLVMに含まれることになりそうということで。

あ、なるほど

https://github.com/kripken/emscripten/issues/2427

Unable to compile a simple Swift file (maybe not possible?) · Iss...

Hi team, playing around with Emscripten in earnest for the first time, not my usual area of work so apologies if this is clearly never going to work. What I'd like to do is compile a simple Swi...

3:02 AM

Swift for WASM スレで、定期的に誰かしら「なんか進捗あった？」って書き込まれるんだけど

3:03 AM

今回はなんかでかめの進捗が報告されてる

3:04 AM

stdlibのビルドはほぼできたらしくて

3:04 AM

バイナリのリンクとかdylibの取り回しの方をWASM環境に適用するのに手こずってるらしい

3:04 AM

めっちゃ大変そう > Unfortunately, a build system used within Swift compiler infrastructure is not very modular, it uses a mix of shell scripts, Python scripts and CMake.

https://github.com/apple/swift-clang/pull/236#issuecomment-441528869

[Swift+WASM] Add an ABI hook for whether swiftcc is supported. by ...

This adds an extension point so the ABI can declare whether or not it supports the swift calling convention. Open to suggestions if you think this doesn't belong here (or is flat out the wrong ...

2:25 AM

いつぞやのwasm対応でswiftcc切るやつ、ジョンマッコールに、「ちゃんとやりなさい」ってリジェクトされてて笑った

https://twitter.com/zhuowei/status/1115784420982583296

Zhuowei Zhang (@zhuowei)

@daniel_dunbar Are you still working on Swift WebAssembly exploration? (SR-9307, https://t.co/u88AVpVn2M hasn't seen activity since January) I'm also trying to get Wasm working (trying to integrate either Emscripten or WASI as the runtime) and would like to know how I can ...

1:26 AM

新たなWASM進めるマンが来た！（ダニエルさんは作業止まってたらしい）

https://swiftwasm.org/

1

おお！？

7:57 PM

https://github.com/swiftwasm/swiftwasm.org/commits/master

swiftwasm/swiftwasm.org

Website for the SwiftWasm project. Contribute to swiftwasm/swiftwasm.org development by creating an account on GitHub.

7:57 PM

zhuoweiさんが主にやってるっぽいな

7:58 PM

https://github.com/apple/swift/pull/24684

WIP: [Swift+WASM] initial support for compiling Swift to WebAssemb...

What's in this pull request? This pull request adds initial support for compiling Swift code to WebAssembly. "Hello world" works, and a large subset of the stdlib already ...

https://forums.swift.org/t/wasm-support/16087/17 正しく意図が読み取れてるか自信がないので相談させてください。

If there's the equivalent of an import table or GOT, it might still be interesting to have something like RelativeIndirectablePointer, but with an absolute address, to still be able to avoid up-front load time costs for cold metadata structures.

これってGOTがあるなら絶対アドレスにしなくてもロード時間は減らせるよね？っていうことですかね。

もしインポートテーブル(Windowsのやつ？)かGOT(Linuxのやつ)と同じものがWASMにもあるなら、 RelativeIndirectablePointerを採用することは意味があるだろう(be iteresting) もし(それがあるのに(but))絶対アドレスを使うのであれば、コールドメタデータの起動時のロード時間を減らす事がそれについても(still be able)できる

7:41 AM

と読んだ。

7:42 AM

起動時じゃないかもな、(up-front)

なるほど

RelativePointerを使ってれば、内部のRelative差分についてはGOTのエントリが減るわけだから、GOTの書き換えコストがカットできるって話かと思った。

7:43 AM

RelativeIndirectablePointerは、基準となるシンボル(GOTエントリ)からの相対オフセットでアドレスを表すから、リンクするのは基準シンボルだけだけど、絶対ポインタを使ったらそういう隠蔽が効かなくなって何もかもGOTエントリに載ってくる (edited)

RelativePointerを使わない場合でもwasm上では内部のシンボル参照にGOTは必要なくて、静的にリンクするときに全部解決されるはず。

7:48 AM

あと、GOTエントリに何もかも載るのは普通のGOTじゃないですか？ (edited)

うん、俺もそう思ってて、WASM実行プロセスにGOT自体存在していないのでは？

7:49 AM

WASMファイルを動的に追加で読み込んだ場合って、JavaScript経由で関数取り出してガチャガチャとバインディングするしかないよね？

7:50 AM

RelativeIndirectablePointerで指し示す対象はシンボルの公開をしないでおけて載らないんじゃないかしら？ > GOTエントリに何もかも載るのは普通のGOTじゃないですか？ (edited)

GOTはLLVMがそれっぽく見せかけるために静的なテーブルを用意してくれますが、動的にリンクしたりするのは出来ないです。

通常の関数呼び出しはそれ経由になってるの？

1つのオブジェクトファイルにまとまってないやつはそうなるはずです

8:04 AM

リンカが関数テーブルを作ってくれて再配置可能wasmモジュール間の関数参照を解決してくれます

あ〜オブジェクトファイル境界がそう効いてくるのか。

なので、返信としては相対絶対に関わらずGOTを経由するケースはあるのでIndirectPointerを使う必要はある、ですかね。

オブジェクトファイルって .o 単位の事？

そうです

.o ごとにGOTがあるの？ .dylibごとかと思ってた

うーん、あれれ。たしかにリンク時にテキストセクションを参照先のアドレスに書き換えれば良いからGOT経由しない気がしてきた

そうそう。

8:15 AM

でdylibごとだとするとwasmの場合全部静的リンクされてるから

8:15 AM

たとえGOTがあったとしても誰も使わないのではと思って。

そうそう、それ朝思ったんだ。朝の時点では「本来GOTを経由する必要は無いので、RelIndirectPterって本当に必要が考える必要あるよね(interesting) 」だと思ってたんだ (edited)

あ、but以下読み違えてたかも

8:20 AM

絶対アドレスを使えば静的メタデータの読み込み時間は回避できるよね(関節化が無くて速いから) か？

8:21 AM

avoid up-front load time costs がよくわからないな〜

butの前後関係がイマイチわからんなー

どうして静的にnon-PICなwasmファイルを構成する個別のオブジェクトファイルにGOTがあるのかわかった。コンパイラ自体はPICなコードを吐くから個別のオブジェクトファイルにGOTエントリが生成されるけど、リンカはnon-PICなコードを吐きたいのでそれを静的なGOTとしてwasmに埋め込むんだ。

リンカはnon-PICなコードを吐きたいので

ここの「ので」がわからなかったので、詳しく知りたい

11:02 AM

位置独立コードからデータを参照する場合はさらに間接的な方式となり、そのコードがアクセスする全グローバル変数のアドレスを格納したGOT (Global Offset Table) を使用する。コンパイル単位またはオブジェクトモジュールごとにGOTがあり、コードから見て固定の相対位置に置かれる（ただし、ライブラリをリンクするまで実際のオフセットは不明である）。リンカがモジュール群をリンクして共有ライブラリを作る場合、各モジュールのGOTをマージし、最終的なコードとのオフセット値を設定する。

https://ja.wikipedia.org/wiki/%E4%BD%8D%E7%BD%AE%E7%8B%AC%E7%AB%8B%E3%82%B3%E3%83%BC%E3%83%89

%E4%BD%8D%E7%BD%AE%E7%8B%AC%E7%AB%8B%E3%82%B3%E3%83%BC%E3%83%89

11:03 AM

↑とりあえず、オブジェクトファイルごとにGOTはあって、静的リンクするときにマージされていくものらしい (edited)

のでの意味

これは単にwasm-ldのデフォルトの挙動としてnon-PICなコードを吐く、という意味でした。一応PICとして吐くこともできるんですけど、その場合はEmscriptenのABI unstableなdynamic loaderの仕様に載っかることになるので一般的ではないです。

単にコンパイラがオブジェクトファイルを生成する時にはPIE対応してGOTを含めているのがリンク後も残っているという話？

そんな感じです。

11:32 AM

リンカの中で分岐があって、静的にGOTを作る場合とdynamic loaderであとからリンクする場合があります。 https://github.com/llvm/llvm-project/blob/c8f9e526bc5319f2d0beed4012fbf17b11e15161/lld/wasm/Relocations.cpp#L47-L59

llvm/llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at...

ふむふむ

技術的内容は理解していないのですが、英語としてはこの"but"は「ではなく」くらいの意味じゃないかな。「GOT的なものがあるので有れば、絶対アドレスではなく、Relative..Pointer的なもの持つことをを検討する価値があるかも知れない」。

おお、そうすると頓珍漢な回答をしてしまったかもしれない…

12:28 PM

ありがとうございます

んーわからん。英語わからないのでリフレーズしてください、が確実か？

そうですねー、適当なこと書くよりそれが確実ですね

https://forums.swift.org/t/wasm-support/16087/19 だいぶ前提が共有されたみたいで話が前進しました

WASM Support

Well, if all wasm code is eventually linked into one object file for deployment, then there shouldn't ever strictly be a need for a GOT (though Swift or LLVM may end up incidentally generating entries because it assumes a symbol might come from a dynamic library in many cases)...

1

結局IRGen飛び越えてLLVM内部の方に行くのね

このスレッドの文脈でKeyPathの呼び出し規約が通常のswiftccから逸脱しているのでは？ということを質問してみました。 https://twitter.com/omochimetaru/status/1232538643731927041?s=20 (edited)

財布紛失太ル (@omochimetaru)

@kateinoigakukun あ〜そっか、サンクの仕様までを固定しておけば、本当のプロパティのgetter自体のABI仕様は露出しないのか。それはありそう。

11:34 PM

https://forums.swift.org/t/wasm-support/16087/21 (edited)

WASM Support

@Joe_Groff Hi! While I was fixing the rest of failing test suites, I found that another issue for ABI. As described here, Swift ABI allows using non-generic function as generic function directly. On WebAssembly runtime, this ABI causes signature mismatch between callee and...

11:37 PM

具体的にはindicesの有無とジェネリックコンテキストの有無がオプショナルになっている部分です。

11:39 PM

さっき回答が来て、それを見るにこの呼び出し規約は多分KeyPath特有で、これのせいでKeyPathのインライン化も面倒なことになっているらしい https://forums.swift.org/t/wasm-support/16087/23

WASM Support

Regarding key paths, their weird calling convention is also an issue for optimization, so we may introduce a SIL convention for key path accessors, which would be another marker you could use to lower them to a consistent LLVM function type for wasm:

so we may introduce a SIL convention for key path accessors, which would be another marker

2:07 AM

これって、新しいSIL conventionを新たに追加して、KeyPathアクセサにそれを設定するようにしようと思っていて、

2:07 AM

そうすれば、KeyPathアクセサのところにWASM対応を仕込まなくても、

2:08 AM

このSIL convensionがついてる関数の呼び出しのところにWASM対応を入れるようにすることで

2:08 AM

今後同種の呼び出しが追加されたときもうまく動くようにできるって意味かと思った。

2:08 AM

conventionってcalling conventionの事なのかなと。

同じように解釈しました

あい。このマーカーが付くまでのことに関しては、KeyPathアクセサしか存在しないと。

2:23 AM

Swift ABIの文書でのくだりだと、細かい調整以外は原則Cコンベンションと同じだって気当てあって

2:23 AM

Cコンベンション自体が原則、末尾引数の無視が可能だから

2:24 AM

なんか厳密なロジックだとあらゆる場面で無視されうる気はする。

あー、たしかにそんなこと書かれてた気がするなぁ

swiftselfとかswifterrorに関しても

2:24 AM

専用のレジスタを割り当ててオプショナルにすれば性能が出せるけど

2:25 AM

最悪それがなくても、ベースのコンベンションがCで可変だから、そこの仕組みで無視したら良いしね、みたいな

2:25 AM

触れられ方をしている。

2:25 AM

まあ、どうせ無理だしスルーが良いと思うけど

2:25 AM

規格としてもう禁止してほしいよな。

ですねー

2:26 AM

逆にclangとかのCのwasmローワリングはどうなってるんだろう

たしか〜に

2:27 AM

Cでコレがダイレクトに効いてくるのが確か

2:27 AM

Cの可変長引数として実装した関数を

2:27 AM

固定引数の関数として呼び出しても動くっていうのじゃなかったっけ

2:28 AM

あれ、逆かな？

そのへんちゃんと調べたこと無いなぁ

てか、printfとかどうなってんだろうね。

ちょうどva_listのテストケース壊れてるんで調べてみます

format文字列とパラメータ数が不一致の場合、引数のclaimができないはず

↑のClangのWebAssemblyローアリングパス調べてみたんですけど、シグネチャが一致してない関数呼び出しに対して、新しくその呼び出し専用の関数を作って置換してました。

4:16 AM

ただこれができるのはcalleeが特定できるダイレクトな関数呼び出しでないといけないのでSwiftの場合は同じ要領ではできなかったです。

じゃあ動的な関数ポインタ経由だったらダメなのか。

です

壊れてるやん。

変換用のPassがあって、それ読む限り関数ポインタまで追っかけてないように見えるんですよね https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/WebAssembly/WebAssemblyAddMissingPrototypes.cpp

llvm/llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at...

まあ動的にやってたらわからんしね。

4:19 AM

そうかあ。そういうこともあるんだなあ。

こっちのPassで関数同士のbitcastに対してサンクを挟んでるのでそれで実は動くのかもしれない https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp

llvm/llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at...

いずれにしても uintptr_t とかタグポインタとか挟んで取り回してたら検出できないっしょ。

そうですねー。

まあやっぱ本質的には互換を取る方法は無いってことなんだな。

4:22 AM

いろいろな前提条件の範囲でごまかすしかない

そうなんですよ。高級ゆえの制限が既存アーキテクチャよりめちゃくちゃ多い

wasm向けツールチェーンの配布をはじめました。swiftenvで入れられるので良かったら試してみてください。 https://twitter.com/kateinoigakukun/status/1240070796321492992?s=20

Getting Started - Swift and WebAssembly

自動で毎日UTC 00:00に最新のSwift for WASMツールチェーンを配布するようにしました https://t.co/ZAi1ggJfDe

1

9:06 AM

最低限のドキュメントも一応書きました https://swiftwasm.github.io/swiftwasm-book/GettingStarted.html

swiftenvを使わずにxcodeのツールチェーン切り替えではできないの？

~/Library/Developer/Toolchains に手でインストールすればXcodeからも切り替えられます

9:12 AM

インストーラは署名しないといけなかったり面倒だったのでまだ作ってないです。

あー、インストーラってそうなのか。でもswiftenv入れるよりはハードル低いと思った

なるほど

9:13 AM

時間あるときに用意してみます

1

SwiftでWebアプリ開発のPoCを作ってみました https://twitter.com/swiftwasm/status/1247797285016055809?s=20

SwiftWasm (@swiftwasm)

Things are progressing really well here at SwiftWasm! With JavaScript/DOM bindings and SwiftPM more or less working, @kateinoigakukun created a simple Conway’s Game of Life demo here: (wait for it to load, binary size is still something we’re working on) https://t.co/mIDYmV...

1

8:21 AM

ローカルで動かす分には全く気にならなかったんですが、インターネットを介すと無視できないダウンロード時間がかかります

おお、すごい。めっちゃすぐ動いたよ

いま買い物に出てるけど4G回線で一瞬だった

うち今WFH勢で回線逼迫していて20秒くらいかかった

ww

うちもキャッシュないと20秒くらいかかるんですよねー

8:28 AM

ちなみに一瞬だった勢は下りどのくらい出てますか？

https://fast.com/ja/share/91Mbps.html

インターネット回線の速度テスト

ダウンロードのスピードはどのくらいですか? Fast.comでは瞬時かつ簡単に、お客様の推定ISPスピードを表示します。

8:30 AM

そんな速くないよ。

うーん何でそんなに差が出るんだろう… https://fast.com/ja/share/90Mbps.html

インターネット回線の速度テスト

ダウンロードのスピードはどのくらいですか? Fast.comでは瞬時かつ簡単に、お客様の推定ISPスピードを表示します。

ほとんど一緒や

8:34 AM

ChromeとSafariのプライベートセッションで試してみたけどやっぱりすぐだったよ。計測したわけじゃないけど２、３秒もかかってないと思う。２０秒は絶対かかってない。

8:36 AM

WebAssenblyは演算した結果を見せようと思ったらJSのブリッジが必要になってCanvasとかDOMを使って表示する、ということですか？

そうですー

なるほど。じゃあ描画がボトルネックのものをなんとかするものじゃないんですね。 SwiftとWebでいわゆるビジネスロジックが共通化できる、というのは明確な利点か。

高速化にも期待したいですね書きやすいRustのポジション

実際、今のJSとRust、Swiftで速度差ってかなり違うんですか？

8:45 AM

今のJSは普通に速い印象。

ちゃんと計測したことないですね、

JSとRust比べるとちょっと早いみたいな事をgfxさんが以前言っていたような

ほー

RustとSwiftはいい感じの比較をそもそも見たことがない

8:46 AM

使う領域が重なってないから実験する人が居ない・・・

8:47 AM

ただJSのJITとWASMランタイムに歴史の差があるからJSが結構速いって感じらしい

まあRust、Swiftの比較は重要じゃないと思います。JSと「Rust、Swift」でそこまで違いがあるかどうか、ですね。

前にChromiumのWASMランタイムちょっと読んだときは未だあんまり積極的なJIT最適化は無かったですね

8:52 AM

ネイティブバイナリに近いパフォーマンスを実現するっていうのがwasmのウリなので気合い入れてるとは思うんですけどね

スマホでは5秒ぐらいだった　多分初見の時にボタンの意味とか考えてた

8:55 AM

これ緑の初期状態が出るまでがロード時間か。

8:56 AM

macだと1秒ぐらい。

インターネットの速度がめっちゃ速い

めっちゃ速い

有線のゲーミングマシンならもっと速いで

バイナリサイズはRustとかGoでも問題になってるんですけど、標準のモジュールの粒度が非常に小さいので一応どうにかなってるんですよねー

家庭くんが留学して解決してくれるんでしょ。

GSoC採択されなかったとしても個人でやると思いますけどねw

留学のほうがオマケだった

9:06 AM

GSocのテーマそのままクラウドファンディングにしてiMacPro調達しようぜ

1

4秒ぐらいで見れますね (ただ netlify はCDNに乗ってないとでかいファイルが極端に遅くなるので、あんまり見られてない地域からとかだと遅くなるかも?)

1

iWork for iCloud 10.0では、C++/ObjCで書かれWebAssemblyとして取り出された機能を含む様になったらしい。 https://twitter.com/lrz/status/1250453967957561344 (edited)

Laurent Sansonetti (@lrz)

What have I been working on lately? Just a few days ago, iWork 10.0 shipped with iCloud apps that now include features extracted from the native codebase (C++/ObjC), using WebAssembly!

Likes

293

アップル自身が既存コードのWASMポートを運用してるのか〜

やっとwasm向けFoundationのビルドが通るようになりました https://github.com/swiftwasm/swift/pull/1000

Build Foundation and add it to the distribution by MaxDesiatov · Pu...

Bits of the dependency installation scripts were refactored to make the local development a bit easier. Overall, Foundation is not fully working yet due to the OOB bug, and to link with it you need...

10

3:49 AM

まだほとんど動かないですが…ｗ

3:50 AM

リンクするとバイナリサイズは11MBから26MBにガッツリ太りました。 (edited)

誰かがやるだろう思っていた SwiftWebUIのwasm移植を@CarsonKatriさんが始めたみたいです。 @State周りもちゃんと動いていて凄い https://twitter.com/kateinoigakukun/status/1268065986294378502?s=20

https://github.com/carson-katri/SwiftWebUI

PoC of SwiftWebUI using SwiftWasm was published! https://t.co/SjWSQdi7w8

1

6:31 AM

6:32 AM

carson-katri/SwiftWebUI

SwiftUI with support for WebAssembly. Contribute to carson-katri/SwiftWebUI development by creating an account on GitHub.

6:32 AM

シュッと試すためのスクリプトもREADMEに用意されていたので手元で動かしてみると楽しいと思います。 (edited)

おお・・・

https://github.com/swiftwasm/swiftwasm-book

swiftwasm/swiftwasm-book

The SwiftWasm book to get you started. Contribute to swiftwasm/swiftwasm-book development by creating an account on GitHub.

1:20 PM

読んでる

お

1:20 PM

昨日ちょっと書き足した

配布してるツールチェインはxctoolchainではないんだね

あー、とりあえずtarballで配布してます

1:22 PM

xctoolchainだとなんか違うのかな

Xcodeから切り替えられるから安心感があった

1:22 PM

swiftenvを入れたくないので。

あー、なるほど

自分で入れるとするとどこに置こうかなと迷う　迷うだけだけど

swiftenv最近僕も微妙だと思い始めてきたのでちゃんとやろうかな

とりあえず $HOME/swift でも作ろっと

ツールチェーンによってあったりなかったりするコマンドがあって、shimsが頻繁に壊れて事故る

ｗ

1:25 PM

xctoolchainだと

1:25 PM

export TOOLCHAINS="org.swift.51220191107a"　で

1:26 PM

swift自体が自力で切り替わってくれるようになるけど

1:26 PM

この形態の場合はこういう切り替える方法はあるんだろうか

1:26 PM

それともPATHで直接参照させるだけ？

PATHの優先度変えるだけで良いと思います

1:27 PM

付随してるライブラリとかはswiftcからの相対パスで決まるので

PATHだけいじって $ swift が切り替わってれば他はいろいろと連動するはずってことね、OK

1:30 PM

げ！

1:30 PM

全部のコマンドに対してこれが出るぞ！

うそーん

一度右クリックから実行すれば許可リスト入りするけど

1:30 PM

bin/の中の全部にやるのは大変ｗ

なんかそれ手元では出ないんですよね

誰がビルドしたか的な情報が入ってんのかな。

1:33 PM

コマンドラインで一気に浄化する方法探してる

1:34 PM

EXAMPLES To check whether Mail.app is allowed to run on the local system: spctl -a /Applications/Mail.app To allow Frobozz.app to run on the local system: spctl --add --label "My Stuff" /Applications/Frobozz.app To forbid all code obtained from the Mac App Store from running: spctl --disable --label "Mac App Store"

じゃあ僕はちゃんと署名する方法探します

助かるｗ

[omochi@omochi-iMacPro bin]$ sudo spctl --add --label swiftwasm $(pwd)/swift-demangle Password: [omochi@omochi-iMacPro bin]$ ./swift-demangle Killed: 9 [omochi@omochi-iMacPro bin]$ sudo spctl -a swift-demangle swift-demangle: rejected (the code is valid but does not seem to be an app)

1:43 PM

できそうでできないなあ

1:43 PM

--master-disable でセキュリティ全解除する情報ばっかり出てくる

それは嫌だなぁ

https://stackoverflow.com/questions/39811791/mac-os-gatekeeper-blocking-signed-command-line-tool

Mac OS Gatekeeper blocking signed command line tool

I have a "command line tool" target (not an App bundle) in Xcode that is being blocked by Gatekeeper. I've used this tool for years as a simple installer for my PostCheck Address Book plugin. In 2...

1:45 PM

The solution is to distribute the command line tool on a signed disk image rather than in a zip file.

100正しい

なんかspctlでコントロールできるのは .app　だけな雰囲気がある

1:46 PM

the code is valid but does not seem to be an app

うーんこれは誰の証明書でサインしたら良いんだ

1:50 PM

Apple Developer AccountはOSS Organizationみたいな括りは無いんだよな

CIで作ってるなら、誰かの秘密鍵をCIに設置しないといけないね・・・

1:55 PM

うおーだめだわからん、Finderで右クリックした時相当のspctlの叩き方が不明。

それこそ手元で署名したら良いんじゃないですか？

再署名ってできるんかな

再署名できるはず。XVimとか入れるのにXcode再署名したことがあるきがする

なるほど

というか今回はもともと署名されてないから。。。 (edited)

実行ファイル単体って

1:58 PM

どこに署名がうまるんだ？

objdumpするとinfo_plistなるセクションが出てくるからMachOバイナリとして埋まってるんじゃないですかね (edited)

なるほど。

いや、よくわからんな… これ

iPhoneだけで、Mac developerのidentifier入ってなかった。また明日・・・

なるほど

swift-demangleが通らなくてもswift demangleは通ったから(swift-frontend)は右クリック済み (edited)

2:06 PM

もしかしたら困ったら手動で右クリックしてればそんなに困らないかも

なるほど？直接発火するバイナリさえ浄化されていればOK？

そうっぽい

でも普通にbrewとかで入れたバイナリって署名されてないけどワーニングでないですよね。

2:09 PM

何が違うんだろう

たしかに・・・

2:15 PM

Safariでダウンロードすると

2:15 PM

危険マークが付く？

そうかなと思ってさっき試してみたんですけど出ないんですよね

/usr/local は聖域？

2:21 PM

chromeで落としたけど駄目だった

2:22 PM

safariで落とした時に許可したやつはいけた。

2:22 PM

バイナリのハッシュ？に対して許可登録してるっぽいな。

https://developer.apple.com/library/archive/technotes/tn2206/_index.html

Technical Note TN2206: macOS Code Signing In Depth

TN2206: Intermediate to expert level overview of macOS code signing that details specific options and gotchas

2:22 PM

読み始めた

思ったけど、もしかしてhomebrewは

2:23 PM

homebrew側でなんかやってんのかもね最後に。

いや、やってないです

そうなのか

brewで入れたgdbは自前で署名しないとプロセスアタッチの権限が無くて使えなかった記憶がある

ふむ

$ codesign -dvvv /usr/local/bin/swiftlint /usr/local/bin/swiftlint: code object is not signed at all

草

どうして俺たちのツールチェーンだけ…

Notarizationは？

/usr/local/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/bin に動かしたけど駄目だなあ。フォルダコピーするときにFinderが謎のダイアログを出して確認してきたからなんかいけそうな気がしたけど。

Notarizationとcodesignは関連するんでしたっけ

2:29 PM

Apple's notary service requires you to adopt the following protections: Enable code-signing for all of the executables you distribute, and ensure that executables have valid code signatures, as described in Ensure a Valid Code Signature.

軽く調べただけなんですけど、Notarizationはcodesignを前提にしている？ https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution

それはちょっとわからないけど「開発元を〜」っていうアラートは公証があれば消えると思う。

2:30 PM

コードサインはなんでもいいんじゃないかな。

なるほど

https://qiita.com/IKEH/items/5d093644922991079ee2

Command Line ToolのApple公証を行う - Qiita

Command Line ToolのApple公証を行う XcodeでCommand line toolを作っている場合、.appと同じ用にOrganizerから公証を行うことができません。 Terminalからコマンドを叩...

ありがとうございます

右クリックで許可されたファイルであっても

4:11 PM

[omochi@omochi-iMacPro wasm]$ spctl -a /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/bin/swift-frontend /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/bin/swift-frontend: rejected (the code is valid but does not seem to be an app)

4:11 PM

spctlから見るとrejectedって出てる

4:11 PM

spctlを超える何かで許可されてる・・・

お

4:11 PM

昨日調べたやつだ

4:12 PM

com.apple.quarantine ついてるかどうかで

4:12 PM

変わる

4:12 PM

どこにも書いてないけど

なんじゃそりゃ・・・

それだけ

なんだそれ。。

サイニングいらない

https://derflounder.wordpress.com/2012/11/20/clearing-the-quarantine-extended-attribute-from-downloaded-applications/

rtrouton

Clearing the quarantine extended attribute from downloaded applicat...

When I’m packaging an application for deployment, I normally download the latest version from the vendor. If it’s a drag-and-drop install, where the application is a self-contained bund…

homebrew は自分でダウンロードしてファイル作ってるから、そのフラグがつかないから

4:13 PM

サインしてないけど、そのバイナリでも実行できる (edited)

4:13 PM

普通にブラウザやcurlでダウンロードしたりzipで解答するとそのフラグがつくから、gatekeeperが、お？なにそれちょっとまって (edited)

4:14 PM

って言ってくる

[omochi@omochi-iMacPro wasm]$ sil-opt Killed: 9 [omochi@omochi-iMacPro wasm]$ xattr sil-opt xattr: No such file: sil-opt [omochi@omochi-iMacPro wasm]$ which sil-opt /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/bin/sil-opt [omochi@omochi-iMacPro wasm]$ xattr $(which sil-opt) com.apple.quarantine [omochi@omochi-iMacPro wasm]$ sudo xattr -r -d com.apple.quarantine $(which sil-opt) Password: [omochi@omochi-iMacPro wasm]$ sil-opt --version LLVM (http://llvm.org/): LLVM version 10.0.0 Optimized build. Default target: x86_64-apple-darwin19.6.0 Host CPU: skylake-avx512

4:14 PM

ほんとだ　できた・・・・

notarization はサインしたあとのはなしだから (edited)

spctlじゃなかったのか。。。

サインしなきゃそもそも要求されない

4:14 PM

ちがいますね

4:14 PM

どこにも書いてないし

アイヤー

Appleのドキュメントも明言してないけど

ありがとうございます！

https://discourse.brew.sh/t/code-signing-installed-executables/2131

Code signing installed executables

First of all: I’m one of the developers of Little Snitch, a user-friendly firewall for macOS that allows creating rules on a per-application (or per-executable) basis. We occasionally have users who run into issues because executables installed via Homebrew do not have a code...

4:15 PM

長いけどこのスレ全部読むとなんとなくわかる

4:16 PM

https://discourse.brew.sh/t/code-signing-installed-executables/2131/9

Code signing installed executables

I think you’re mixing up a few things here. Developer ID is a program by apple that provides code signing certificates, among other things. Developer ID has nothing to do with any review process whatsoever. Notarized apps are an extension of the Developer ID program. Notariz...

4:16 PM

このへんがポイント

find . -perm +111 -type f と xattr を組み合わせたらガッと浄化できそう。

そんな感じ

4:17 PM

昨日めっちゃ調べた

奇遇ですね。

ちょっとバイナリ配布のアレがあって

ｗｗ

いまいち理解してなくて

4:17 PM

人としてまずいと思ったので。。

おかげで人に成れた

xattr -r -d com.apple.quarantine ディレクトリパス でディレクトリ内一気に消せますよ

マジか

4:18 PM

findもいらんかった

-r は recursive

removeかなと思ってスルーしてしまった　なるほど。

4:19 PM

recursive deleteか

なんでかわかんないけど、まあ何と無くわかるんだけど

4:19 PM

このquatrain フラグをつけるのは、open(2)するプロセスの責任で (edited)

4:20 PM

べつにカーネルが面倒見てくれてるわけじゃないっぽいんだよねー。

え。

4:20 PM

じゃあシェルが勝手にやってるんですか

だから、RubyとかでHTTP GETしてFile.write()したバイナリはそのまま実行できる

4:21 PM

サインされてなくても。

あ、フラグを付ける時の話ですか？

4:21 PM

実行時にフラグを見る話ではなく。

そう。フラグつけるのは任意。

そうすると、safariがDLした時にフラグをつけて、それをmacOS標準のアーカイバが展開する時に、中身にフラグを付け直してるんかな。

フラグ見るのは execve(2) でやられてる

4:22 PM

それっぽい

なるほど >execve

4:22 PM

ははあ・・・

appleのツールは守ってる

4:23 PM

homebrewはRubyで書いてあるし、多分意図的に守ってない

4:23 PM

そもそもhomebrewを最初に入れるときに許可がいるっていう

4:23 PM

そう言う話だと思う

4:23 PM

あのインストーラースクリプトはcurlとかで取ってくる必要があるから。

4:24 PM

chain of trustかなあ

なるほどなあ

かたや、notarizationはdeveloper idでサインしたら最近は必須だから、 (edited)

4:25 PM

サインすると面倒という見方も...

4:25 PM

どのみち、エンドユーザーにでるダイアログに大差ないからね

なるほどなぁ

iOSのようなサンドボックスじゃないシステムの妥協としてはまあ良い方なのでは。

4:27 PM

ということをAppleはどこかに書いたらいいとおもいます。 (edited)

4:28 PM

ブログ書いたらいいのかな。。

4:28 PM

辛いのは誤った情報が溢れてることなんだよね (edited)

4:28 PM

ITのひとの寝言みたいなやつとか

ITの人の寝言とは・・・ｗ

ITのひとがなんかこうしたら俺んとこでは解決したよみたいなまったく理論的でない個人のポエムみたいな情報かなあ

ｗｗ

4:35 PM

[omochi@omochi-iMacPro wasm]$ ls -alh total 20432 drwxr-xr-x 4 omochi staff 128B 10 7 01:32 . drwxr-xr-x 14 omochi staff 448B 10 7 01:07 .. -rw-r--r--@ 1 omochi staff 21B 10 7 01:08 a.swift -rwxr-xr-x 1 omochi staff 10M 10 7 01:32 a.wasm [omochi@omochi-iMacPro wasm]$ wasmer a.wasm hello world

4:35 PM

ハロワできた

1

codesignコマンドの--deepオプションが全然再帰的に効かなくて困った。。。

4:41 PM

$ sudo codesign --force --deep --sign "Developer ID Application: Neko Chan (XXXXXXXXX)" --options runtime --deep-verify swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a.xctoolchain/ $ codesign -display swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a.xctoolchain/usr/bin/swift-package swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a.xctoolchain/usr/bin/swift-package: code object is not signed at all

(edited)

/Users/omochi/github/omochi/SwiftDeclWeb/Tests/SDWVDOMTests/VDOMTests.swift:1:8: error: could not find module 'XCTest' for target 'wasm32-unknown-wasi';

4:42 PM

XCTestはないから swift test はできない？

いや、あるんですよ

なんか俺が間違えてるんかな

うーんなんかツールチェーンが腐っている気がする。。。

ねこちゃん

[omochi@omochi-iMacPro usr]$ tree | grep -i xctest │   │   │   ├── XCTest.swiftmodule │   │   │   │   ├── XCTest.opt.bitstream │   │   │   ├── libswiftXCTest.dylib │   │   │   ├── XCTestOverlayShims.h │   │   ├── XCTest.swiftdoc │   │   ├── XCTest.swiftmodule │   │   ├── XCTestOverlayShims.h │   ├── libXCTest.a │   └── swiftpm-xctest-helper

4:45 PM

たしかになんかは入ってるな

オフィシャルのツールチェーンと比較しようと思ったのにswift.orgが落ちててスナップショット落とせない。。。

うーん、 --sdk を指定してないのがいかんのかと思ったが

4:48 PM

swift build と swift test は指定すると逆に通らないな

4:48 PM

[omochi@omochi-iMacPro SwiftDeclWeb]$ swift build --triple wasm32-unknown-wasi --sdk $TOOLCHAIN_PATH/share/wasi-sysroot <module-includes>:1:10: note: in file included from <module-includes>:1: #include "LibcOverlayShims.h" ^ /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/lib/swift/shims/LibcOverlayShims.h:31:10: error: 'semaphore.h' file not found #include <semaphore.h> ^ <unknown>:0: error: could not build C module 'SwiftOverlayShims' <module-includes>:1:10: note: in file included from <module-includes>:1: #include "../../../../share/wasi-sysroot/include/ctype.h" ^ <module-includes>:1:10: note: in file included from <module-includes>:1: #include "LibcOverlayShims.h" ^

4:49 PM

a

4:49 PM

ミスってた

4:50 PM

[omochi@omochi-iMacPro SwiftDeclWeb]$ swift test --triple wasm32-unknown-wasi --sdk $TOOLCHAIN_PATH/share/wasi-sysroot /Users/omochi/github/omochi/SwiftDeclWeb/Tests/SDWVDOMTests/VDOMTests.swift:1:8: error: could not find module 'XCTest' for target 'wasm32-unknown-wasi'; found: arm64e-apple-ios-macabi, x86_64-apple-ios-macabi, arm64, arm64-apple-macos, x86_64, arm64e-apple-macos, x86_64-apple-macos, arm64-apple-ios-macabi, arm64e import XCTest ^ /Users/omochi/github/omochi/SwiftDeclWeb/Tests/SDWVDOMTests/VDOMTests.swift:1:8: error: could not find module 'XCTest' for target 'wasm32-unknown-wasi'; found: arm64e-apple-ios-macabi, x86_64-apple-ios-macabi, arm64, arm64-apple-macos, x86_64, arm64e-apple-macos, x86_64-apple-macos, arm64-apple-ios-macabi, arm64e import XCTest ^ error: fatalError

4:51 PM

ビルドは通った (TOOLCHAIN_PATHがシェルから消えてた) けど、could not findだ

~~あ、corelibsのswiftmoduleの配置がマズそう~~ (edited)

4:55 PM

とりあえずIssue立てておきます

古いのダウンロードしたらいけたりするやつ？

4:56 PM

いまやってるの swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a なんだけど。

動くスナップショットはあるはず

なるほどね

4:57 PM

bookに出てくるやつにするわ

10/2はもう腐ってます

1

笑う (edited)

4:58 PM

https://book.swiftwasm.org/getting-started/setup.html

Setup - Swift and WebAssembly

4:58 PM

イントロで紹介してるの10/2やで

それは凄く良くない

4:59 PM

e2eテストが足りてないですね。

しょうがないよやること無限にある

たぶん1ヶ月前くらいのスナップショットなら動くと思うんですけど、古いのもはオプティマイザが壊れてたり別の問題があるのでとりあえずXCTestは待っててください

了解！

同様にFoundationもimportできないと思います

5:00 PM

あれ、できた

executable作ってFoundation走るかみてみる。

5:06 PM

[omochi@omochi-iMacPro SwiftDeclWeb]$ swift build --triple wasm32-unknown-wasi --sdk $TOOLCHAIN_PATH/share/wasi-sysroot wasm-ld: error: /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/lib/swift_static/wasi/libFoundation.a(NSTimeZone.swift.obj): undefined symbol: CFHash wasm-ld: error: /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/lib/swift_static/wasi/libFoundation.a(NSDate.swift.obj): undefined symbol: _CFDeinit wasm-ld: error: /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/lib/swift_static/wasi/libFoundation.a(NSDate.swift.obj): undefined symbol: CFDateGetTypeID wasm-ld: error: /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/lib/swift_static/wasi/libFoundation.a(NSDate.swift.obj): undefined symbol: CFDateGetTypeID wasm-ld: error: /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/lib/swift_static/wasi/libFoundation.a(NSRegularExpression.swift.obj): undefined symbol: kCFAllocatorSystemDefault

5:06 PM

エラーが1000行出てきた

5:07 PM

[omochi@omochi-iMacPro SwiftDeclWeb]$ tree -L 2 -d $TOOLCHAIN_PATH/share/wasi-sysroot /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/bin/../share/wasi-sysroot ├── include │   ├── arpa │   ├── bits │   ├── c++ │   ├── net │   ├── netinet │   ├── netpacket │   ├── scsi │   ├── sys │   └── wasi ├── lib │   ├── wasm32-wasi │   └── wasm32-wasi-unknown ├── share │   └── wasm32-wasi └── usr └── include 17 directories

5:07 PM

sysrootはあってると思う・・・

あ、

5:08 PM

思い出した

1

5:09 PM

{ "extra-cc-flags" : [ "-I", "TOOLCHAIN_DIR/usr/lib/swift/wasi/wasm32" ], "extra-cpp-flags" : [ ], "target" : "wasm32-unknown-wasi", "version" : 1, "extra-swiftc-flags" : [ "-I", "TOOLCHAIN_DIR/usr/lib/swift/wasi/wasm32", "-Xlinker", "-lFoundation", "-Xlinker", "-lCoreFoundation", "-Xlinker", "-lBlocksRuntime", "-Xlinker", "-licui18n", "-Xlinker", "-luuid" ], "sdk" : "TOOLCHAIN_DIR/usr/share/wasi-syroot", "toolchain-bin-dir" : "TOOLCHAIN_DIR/usr/bin" }

5:10 PM

こういうdestinationファイルを作って、TOOLCHAIN_DIRを置換して、

5:10 PM

swift build -c debug --build-tests --destination wasm32-unknown-wasi.json

5:11 PM

で --destination オプションに渡す

やってみます。

cartonでビルドするとこれ隠蔽されるんですけど、たぶんおもちさんの好みじゃ無さそう

carton使う気は無いですね

5:14 PM

好みじゃなくて・・・

5:14 PM

[omochi@omochi-iMacPro SwiftDeclWeb]$ swift build -c debug --build-tests --destination /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/wasm32-unknown-wasi.json wasm-ld: error: /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/lib/swift_static/wasi/libFoundation.a(Data.swift.obj): undefined symbol: _withStackOrHeapBuffer clang-10: error: linker command failed with exit code 1 (use -v to see invocation) error: link command failed with exit code 1 (use -v to see invocation) [16/18] Linking SwiftDeclWebPackageTests.xctest

5:14 PM

なんかもうちょっとぽい感じになった。

5:14 PM

エラー一件

なんだこれ

5:17 PM

package initで作ったパッケージでは通る

5:19 PM

https://github.com/swiftwasm/swift/issues/1824

Building a test bundle fails with 5.3 snapshots · Issue #1824 · swi...

The error is raised by wasm-ld: wasm-ld: error: /Users/maxd/.carton/sdk/wasm-5.3-SNAPSHOT-2020-09-23-a/usr/share/wasi-sysroot/lib/wasm32-wasi/ libc.a(__original_main.o): undefined symbol: main The ...

5:20 PM

直したやつっぽい

[omochi@omochi-iMacPro wpkg]$ swift package init --type executable Creating executable package: wpkg Creating Package.swift Creating README.md Creating .gitignore Creating Sources/ Creating Sources/wpkg/main.swift Creating Tests/ Creating Tests/LinuxMain.swift Creating Tests/wpkgTests/ Creating Tests/wpkgTests/wpkgTests.swift Creating Tests/wpkgTests/XCTestManifests.swift [omochi@omochi-iMacPro wpkg]$ open . [omochi@omochi-iMacPro wpkg]$ swift build -c debug --build-tests --destination /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/wasm32-unknown-wasi.json /Users/omochi/temp/wpkg/Tests/wpkgTests/wpkgTests.swift:20:23: error: cannot find 'Process' in scope let process = Process() ^~~~~~~ /Users/omochi/temp/wpkg/Tests/wpkgTests/wpkgTests.swift:23:20: error: cannot find 'Pipe' in scope let pipe = Pipe() ^~~~ /Users/omochi/temp/wpkg/Tests/wpkgTests/wpkgTests.swift:44:28: error: value of type 'Bundle' has no member 'bundleURL' return Bundle.main.bundleURL ~~~~~~~~~~~ ^~~~~~~~~ [6/9] Compiling wpkgTests XCTestManifests.swift

5:20 PM

完全に空のディレクトリからやりなおしてみたらこうなった (edited)

Processは使えない気がする (edited)

ああ、たしかに。

5:21 PM

これをちょっと書き換えてみるか

5:22 PM

import XCTest final class wpkgTests: XCTestCase { func testExample() throws { XCTAssertTrue(true) } static var allTests = [ ("testExample", testExample), ] }

5:22 PM

[omochi@omochi-iMacPro wpkg]$ swift build -c debug --build-tests --destination /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/wasm32-unknown-wasi.json wasm-ld: error: /Users/omochi/swift/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/lib/swift_static/wasi/libFoundation.a(Data.swift.obj): undefined symbol: _withStackOrHeapBuffer clang-10: error: linker command failed with exit code 1 (use -v to see invocation) <unknown>:0: error: link command failed with exit code 1 (use -v to see invocation) [7/8] Linking wpkgPackageTests.xctest

5:22 PM

同じシンボルでコケた

5:23 PM

ほんとだ。リグレッションだ > issue 1824

5:23 PM

10/05が駄目なんだな

5:24 PM

10/02にしてみるか。

$ cat Tests/helloTests/helloTests.swift import XCTest final class helloTests: XCTestCase { func testExample() throws { XCTAssertTrue(true) } static var allTests = [ ("testExample", testExample), ] } $ ~/Downloads/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a.xctoolchain/usr/bin/swift build -c debug --build-tests --destination wasm-5.3-SNAPSHOT-2020-09-08-a.json [12/12] Linking helloPackageTests.xctest /var/folders/br/7sr_p7cj7v549x_gtkb33df00000gp/T/tmp.BSZU6PLa $ wasmer ./.build/debug/helloPackageTests.xctest Test Suite 'All tests' started at 2020-10-06 17:24:16.346 Test Suite 'testBundle.xctest' started at 2020-10-06 17:24:16.346 Test Suite 'helloTests' started at 2020-10-06 17:24:16.346 Test Case 'helloTests.testExample' started at 2020-10-06 17:24:16.346 Test Case 'helloTests.testExample' passed (0.0 seconds) Test Suite 'helloTests' passed at 2020-10-06 17:24:16.346 Executed 1 test, with 0 failures (0 unexpected) in 0.0 (0.0) seconds Test Suite 'testBundle.xctest' passed at 2020-10-06 17:24:16.347 Executed 1 test, with 0 failures (0 unexpected) in 0.0 (0.0) seconds Test Suite 'All tests' passed at 2020-10-06 17:24:16.347 Executed 1 test, with 0 failures (0 unexpected) in 0.0 (0.0) seconds

5:25 PM

うーーん？？

そっちも1005なのか。

5:25 PM

あれ、.xctoolchain ?

ああ、これは作業中のツールチェーンです

5:26 PM

バイナリ自体には影響ない

あとdestinationファイルは09-08？

5:26 PM

jsonの中身は1005なの？

お、合わせたら再現した

5:28 PM

じゃあ09-08は動く

なるほど。

5:35 PM

10-02で同じエラーでた

5:35 PM

09-08落とす

5.3-SNAPSHOT-2020-10-02-a はOK

あー、DEVELOPMENTなしのほうか (edited)

そっちはもうちょっと安定してる

なるほど

5:48 PM

[omochi@omochi-iMacPro wpkg]$ swift build -c debug --build-tests --destination /Users/omochi/swift/swift-wasm-5.3-SNAPSHOT-2020-09-08-a/usr/wasm32-unknown-wasi.json wasm-ld: error: /Users/omochi/swift/swift-wasm-5.3-SNAPSHOT-2020-09-08-a/usr/share/wasi-sysroot/lib/wasm32-wasi/libc.a(__original_main.o): undefined symbol: main clang-10: error: linker command failed with exit code 1 (use -v to see invocation) <unknown>:0: error: link command failed with exit code 1 (use -v to see invocation) [8/9] Linking wpkgPackageTests.xctest

5:48 PM

グアア

5:49 PM

10-02 無印ダウンロードする

ウオー見つけた

6:01 PM

マージコンフリクト解消ミスってスタブ実装消えてた。。 https://github.com/swiftwasm/swift-corelibs-foundation/commit/5b440b21a45c958cafaed51fe979b81d47e3e6be

Reimplement _withStackOrHeapBuffer w/o blocks · swiftwasm/swift-cor...

ウオオオｗ

6:02 PM

__withStackOrHeapBuffer のテストケースがあれば・・・

6:02 PM

[omochi@omochi-iMacPro wpkg]$ swift build -c debug --build-tests --destination /Users/omochi/swift/swift-wasm-5.3-SNAPSHOT-2020-10-02-a/usr/wasm32-unknown-wasi.json [12/12] Linking wpkgPackageTests.xctest

(edited)

6:03 PM

10-02無印でビルドできました！！

6:03 PM

[omochi@omochi-iMacPro wpkg]$ wasmer .build/debug/wpkgPackageTests.xctest Test Suite 'All tests' started at 2020-10-06 18:03:44.789 Test Suite 'testBundle.xctest' started at 2020-10-06 18:03:44.790 Test Suite 'wpkgTests' started at 2020-10-06 18:03:44.790 Test Case 'wpkgTests.testExample' started at 2020-10-06 18:03:44.790 Test Case 'wpkgTests.testExample' passed (0.0 seconds) Test Suite 'wpkgTests' passed at 2020-10-06 18:03:44.790 Executed 1 test, with 0 failures (0 unexpected) in 0.0 (0.0) seconds Test Suite 'testBundle.xctest' passed at 2020-10-06 18:03:44.790 Executed 1 test, with 0 failures (0 unexpected) in 0.0 (0.0) seconds Test Suite 'All tests' passed at 2020-10-06 18:03:44.790 Executed 1 test, with 0 failures (0 unexpected) in 0.0 (0.0) seconds

6:03 PM

XCTest走った〜〜

6:05 PM

お、手元のプロジェクトの方もビルド実行できた

6:06 PM

bookのやつは無印の10-02だから結局オッケーだったのか。

わーい

今日は終わっときます〜　どうもありがとう〜

おやすみなさい〜

知見のおおいthreadだった

destination.jsonの書き方はこれか。 https://github.com/apple/swift-package-manager/pull/1098

cross compilation support (configurable destinations) by weissi · P...

General This adds experimental support for cross compilation or more precisely configurable destinations for binaries to SwiftPM. The basic idea is that you hand a JSON file in the format described...

とりあえずFoundationリンクできないやつは治った https://github.com/swiftwasm/swift-corelibs-foundation/pull/143

[WASM] Restore lost _withStackOrHeapBuffer implementation by katein...

Resolve swiftwasm/swift#1824 (comment) $ swift build -c debug --build-tests --destination wasm32-unknown-wasi.json wasm-ld: error: /path/to/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-10-05-a/usr/lib/swi...

.xctoolchainにしてexport TOOLCHAINS="org.swift.…"でツールチェインを切り替える仕組みは、SwiftPMがツールチェイン添付のXCTest.swiftmoduleを使ってくれないから、SwiftWasmには使えないんじゃないかな。 (edited)

そうなんですよね。今はとりあえずdestinationファイルで-I付けてツールチェーンのXCTest.swiftmoduleを優先するようにしてるんですけど微妙。。。 (edited)

C側ではattribute付きのextern宣言をしておいて、 WebAssembly.instantiate でJS側の関数をWASM環境にいれるやつ

1:22 PM

これ引数と返り値の型はどうやって合わされてるの？

実行時検査ですね

あー、C側の呼び出しが

1:24 PM

WASM環境だから

1:24 PM

ランタイムが引数の型を知っている？

1:25 PM

普通のC環境だったらcallerが信じてるcalleeの呼び出し規約と引数に応じてレジスタ/スタックを構成してからジャンプするけど

1:26 PM

WASMだと関数と引数を指定してコールする抽象度だから、

1:26 PM

WASMランタイムがその情報に基づいて引数の値をWASMの型からJSの型に変換してからJSの関数を呼ぶ？

多分そういう実装になっているはず

なるほど・・・

calleeが引数をどう使おうと要求している引数の数が提供される数を超えない限りは問題ない

仮引数に対して実引数の数が足りてなくても

1:29 PM

JSだったらundefinedになって呼び出されそう

1:29 PM

例外飛ぶんだっけ

どうだろう。。

あと

1:29 PM

https://github.com/swiftwasm/JavaScriptKit/blob/main/Example/src/index.js#L9-L27

swiftwasm/JavaScriptKit

Swift framework to interact with JavaScript through WebAssembly. - swiftwasm/JavaScriptKit

1:30 PM

// Output stdout and stderr to console const originalWriteSync = wasmFs.fs.writeSync; wasmFs.fs.writeSync = (fd, buffer, offset, length, position) => { const text = new TextDecoder("utf-8").decode(buffer); // Filter out standalone "\n" added by every `print`, `console.log` // always adds its own "\n" on top. if (text !== "\n") { switch (fd) { case 1: console.log(text); break; case 2: console.error(text); break; } } return originalWriteSync(fd, buffer, offset, length, position); };

1:30 PM

これがいまいち理解できないんだけど

1:30 PM

ここにかいてある print って Swift.print のこと？

これ書いた覚えがないな…

1:30 PM

多分そうだと思うます

https://book.swiftwasm.org/examples/importing-function.html

Importing function - Swift and WebAssembly

1:31 PM

↑bookにもこの書き換えが出てくる

1:31 PM

Swift.print の末尾の改行が不要なのであれば、 print(str, terminator: "") って呼び出せばよくない？

たぶんconsole.logの改行とSwift.print側の改行で2つ改行されるのが嫌なんじゃないですかね

この wasmFS.fs.writeSync の先に繋がってる console.log で勝手に改行されて改行が２つになることを気にしてそうな

そうそう

でも、それおかしいことになるよね

1:33 PM

console.logはどうやったって改行をつけちゃうというか

途中に改行入ってたりすると壊れる

与えられた文字列の単位で行をわけて表示する仕組みだから

1:33 PM

逆にそもそも Swift.print("str", terminator: "") ってやっていたとしても

1:33 PM

console.logによる改行？というか表示上の区切りは生じる

1:34 PM

blameみるとたしかにこれかいたのはJedFoxさんだな

1:35 PM

いや、ちがうな、

1:35 PM

更にずっと前に Max も同じことやってる

https://github.com/swiftwasm/JavaScriptKit/pull/17

Handle stdio/stderr consistently in Example/src/index.js by MaxDesi...

Added per the discussion in #11. Closes #11.

1:36 PM

ア…

1:36 PM

まあ見た目をキレイにしたい気持ちはわかる

やるなら改行が来るまでバッファリングして

1:37 PM

改行のところで分割してconsole.logだったら

1:37 PM

結果が同じになるから正しいと思う・・・

1:37 PM

でも fflush() が呼ばれたら詰む。 (edited)

どうしようもない

console.logにマッピングしてるのがまあ無理だよね

Node.jsだったらprocess.stdout.writeにマップして幸せになれる

1:42 PM

ブラウザでのSwift.printはどうせ開発者しか見ないし。。。

https://github.com/wasmerio/wasmer-js/tree/master/packages/wasmfs

wasmerio/wasmer-js

Monorepo for Javascript WebAssembly packages by Wasmer - wasmerio/wasmer-js

1:43 PM

デフォルトのconsole.logにつなげてる場所どこだろ

wasmer-jsのリポジトリではそういうユースケースないです

const originalWriteSync = wasmFs.fs.writeSync;

wasiアプリケーションのstart関数が終わった後にまとめてstdoutをprintしてる

このoriginalWriteSyncの実装はどこに？

1:44 PM

あ

1:44 PM

あ〜

じっそう？

これフックしてconsole.logに横流ししてるだけか

そうそう。フックしてconsole.logに流した後、元のwriteSync呼ばないとバッファリング壊れるんで。 (edited)

読み間違えてた。なるほど。

1:46 PM

これがないと wasmfs的には /dev/stdout にファイルとして書き溜めてるだけなのね

そうなんです。

うーん。Swift側にconsole.logを意味的にもインポートしてくるのが良さそうだなあ。

1:48 PM

でもXCTestの出力は多分勝手にstdoutに出されてるよね・・・

Rustはwasm-bindgenでconsole.logをRust側に引っ張ってきてますね。

1:48 PM

そうなんですよ

XCTestの出力は逐次で見たいなあ。

XCTestは大体wasmerとかwasmtimeとかコマンドラインでやるからconsole.log必要なくないですか？ (edited)

DOMがちゃんと操作されるかテストしたい。

ああそうか〜

だからブラウザ上でしかテストできない。

1:51 PM

https://stackoverflow.com/questions/7286918/internally-capture-redirect-stdout?rq=1

Internally capture/redirect stdout?

This seems like a bit of a computing systems 101 question, but I'm stumped. I am integrating existing code from C/C++ project A into my own project B. Both A and B will be linked into a single

1:51 PM

C環境で、freopenとかdupとかで

1:52 PM

stdoutの向き先を自前で用意したpipeにすることができるんだけど

1:52 PM

WASI上でそういうのできんのかな。

wasi-libc側でできそう

どういうスタックになってるんだ？

https://github.com/WebAssembly/wasi-libc/blob/9083fe84568fb4de76152757abfd216ba34ad908/libc-top-half/musl/src/stdio/freopen.c#L23-L78

WASI libc implementation for WebAssembly. Contribute to WebAssembly/wasi-libc development by creating an account on GitHub.

wasi-libc が wasi APIの上で実装されたlibc ？

1:56 PM

こう

Swiftはlibcを使ってるつもりになっているのか

1:56 PM

普通のプラットフォームがこれ

freopenだとファイルパスだからちょっと微妙だよね、dup2が良さそうだ

1:57 PM

なるほど

1:57 PM

freopenの中がdup3だ

リダイレクトしてどうするんですか？

自作のpipeオブジェクトに対して

1:58 PM

別スレッドからselect pollingすればリアルタイムに吸い出せる

1:58 PM

いやスレッドないな・・・

1:59 PM

stdoutに来てるストリームを受け取れればあとはどうにでもなるので。consoleには出せないけど。

1:59 PM

<pre> タグの中に流し込んでいくとかのほうがマシな挙動だと思う。

2:00 PM

https://github.com/WebAssembly/wasi-libc/blob/320054e84f8f2440def3b1c8700cedb8fd697bf8/libc-top-half/musl/src/unistd/dup2.c syscallなのか。

https://github.com/WebAssembly/WASI/blob/master/phases/snapshot/docs.md#-fd_renumberfd-fd-to-fd---errno

WASI libc implementation for WebAssembly. Contribute to WebAssembly/wasi-libc development by creating an account on GitHub.

2:00 PM

WebAssembly/WASI

WebAssembly System Interface. Contribute to WebAssembly/WASI development by creating an account on GitHub.

2:01 PM

WASIになんかリッチな名前のdupがあった

ちゃんと名前がついていてわかりやすい

2:02 PM

writeFileSyncで引っ掛けてpreタグに流し込むだとまずいんでしたっけ

制御がSwift側にない。

2:02 PM

JS側でできるだけ何もしたくない・・・

なるほど

でもなんかコスパに見合ってる感じがしないねえ。

2:04 PM

https://github.com/WebAssembly/wasi-libc/blob/29d45024c71571d50ec2f98bbe57df9efe57eb65/libc-top-half/musl/src/stdio/freopen.c#L56

https://github.com/WebAssembly/wasi-libc/blob/29d45024c71571d50ec2f98bbe57df9efe57eb65/libc-bottom-half/headers/public/wasi/core.h

WASI libc implementation for WebAssembly. Contribute to WebAssembly/wasi-libc development by creating an account on GitHub.

2:04 PM

freopenがrenumberでかいてあるんだな

2:04 PM

これsyscallはどこに行くんだろ

2:04 PM

 f2 = fopen(filename, mode); if (!f2) goto fail; if (f2->fd == f->fd) f2->fd = -1; /* avoid closing in fclose */ #ifdef __wasilibc_unmodified_upstream // WASI has no dup else if (__dup3(f2->fd, f->fd, fl&O_CLOEXEC)<0) goto fail2; #else // WASI doesn't have dup3, but does have a way to renumber // an existing file descriptor. else { if (__wasilibc_fd_renumber(f2->fd, f->fd)<0) goto fail2; f2->fd = -1; /* avoid closing in fclose */ } #endif

syscallはよばれないっすよ

いやなんか不穏だな

2:05 PM

なるほど・・・

改造前のコードが残ってるだけですね

そういうことか〜

2:05 PM

じゃあこのwasi-libcにはdup2はなくって

2:05 PM

freopenはあって普通にC関数としてwasiのrenumberを呼ぶのか。

ですね

逆にWASMSwift環境からは

2:06 PM

普通にWASI APIは直接触れる？

ヘッダインクルードすれば

2:07 PM

https://linuxjm.osdn.jp/html/LDP_man-pages/man3/mkfifo.3.html

WASI libc implementation for WebAssembly. Contribute to WebAssembly/wasi-libc development by creating an account on GitHub.

2:08 PM

wasi APIって言っても、ただモジュール名と関数名とシグネチャが指定されてるextern関数なので

なるほど

特に特別扱いされてないですね

wasi側のAPIでなんとかfdを作ってrenumberでstdoutをくっつけてから非同期に読み出せれば

2:10 PM

やりたいことはできそうだな。

非同期に読み出せるか…？

poll_oneoff(in: ConstPointer<subscription>, out: Pointer<event>, nsubscriptions: size) -> (errno, size)

2:13 PM

うーんちがうのかな。

2:13 PM

読めるように成ったら関数読んでくれるコールバック登録的な仕組みがあればできそうだけど

2:15 PM

そもそもファイルに紐付かないfdが欲しいけど・・・

libcのレイヤーでそういうのあるのかな

open の世界だったら pipe がそう

2:18 PM

fopen が返す FILE* は生fd のラッパー

2:20 PM

2:20 PM

mkfifoでパス付きのpipeを作ってfopenするとFILE*に見えるけどpipeらしい。でもlibcじゃなさそう。

2:22 PM

うーんなんかなさそうな気がするな〜

コールバックはなさそう

unixのファイルディスプリプタは

2:23 PM

ファイルといっても実際には抽象的なストリームで

2:23 PM

pipeもsocketも抽象化されてるんだけど

2:23 PM

wasiのファイルディスクリプタは本当にファイルシステムの方のやつしかなさそう？

2:24 PM

poll_oneoff(in: ConstPointer<subscription>, out: Pointer<event>, nsubscriptions: size) -> (errno, size) Concurrently poll for the occurrence of a set of events.

2:24 PM

poll_oneoffがconcurrencyって書いてあるんだけど

2:24 PM

subscriptionの構築方法がさっぱりわかｒなｎ

2:26 PM

subscription { subscription_u { subscription_fd_readwrite { file_descriptor } } }

2:26 PM

なんかこんなのを作れば fd が監視できる気がする？

2:26 PM

でもコールバック関数を渡せそうな場所がない。

これシグネチャ的に関数ポインタ渡せなくないですか

2:27 PM

ですね

2:28 PM

pollの実装に使われてるからこれは待つ感じかな

あー

https://github.com/WebAssembly/wasi-libc/blob/master/libc-bottom-half/cloudlibc/src/libc/poll/poll.c

https://github.com/wasmerio/wasmer-js/blob/3baa0fff318efe159122c78b5436b9f7e6711e26/packages/wasi/src/index.ts#L1369

WASI libc implementation for WebAssembly. Contribute to WebAssembly/wasi-libc development by creating an account on GitHub.

メインループの中で使うやつか。

2:31 PM

wasmerio/wasmer-js

Monorepo for Javascript WebAssembly packages by Wasmer - wasmerio/wasmer-js

2:31 PM

イベントが無かったらすぐ抜ける方なのかなあ。

2:33 PM

なんか、自分で、毎フレーム呼びまくってポーリングするためのものにも見える

ぽい

2:34 PM

libcのapiってそういうの多いですよね

2:35 PM

あ、

2:35 PM

fd_writeって関数をSwift側に作ってリンク時に静的にそっちに実装が紐づくようにすれば良いんですよ

あー

2:37 PM

それstdout以外はどうしよう

2:38 PM

libc上でやるんじゃなくてlibc実装をフックするのは確かに・・・

2:39 PM

でもそれだったらあれだね、最初のJSの方式で

void __wasi_fd_write(...) { // do redirect return original_fd_write(...); } void original_fd_write(...) __attribute__(( __import_module__("wasi_snapshot_preview1"), __import_name__("fd_write") ))

(edited)

2:39 PM

こんな感じになるかな

あー

2:40 PM

そこは名前指定がもう一手かかってるのかややこしいな

ややこしい

2:42 PM

Safariがi64をJS境界でサポートしていないことのpolyfillでも似たようなことした https://github.com/kateinoigakukun/swiftwasm-pad/blob/master/Frontend/Sources/i64_polyfill/i64_polyfill.c

kateinoigakukun/swiftwasm-pad

swiftwasm-pad is a online playground to help developers learn about Swift on Web. - kateinoigakukun/swiftwasm-pad

今のビルドだと

2:45 PM

sysrootの中にある何かが既にそれをやってるんだよね？

2:45 PM

なんていえばいいんだ、wasiのfd_writeの実態に紐付けられようとしてるexternは既に書かれてる (edited)

2:47 PM

Swiftstdlibとかももうlibcとリンクされてるわけで

2:47 PM

そこをつなぎ替える？

いや、Swiftサイドはwasiのインターフェースをフックするみたいなことはしてないです

wasi-libcをビルドしてできたlibcがツールチェインに既に入っているんじゃ？

Swift stdlibはlibcとリンクされているけど、__wasiプレフィックスの付いてるexternなやつたちはundefinedのままです

なるほど。

リンクされている、は嘘だ。

2:50 PM

実行可能ファイルに最終的にリンクするときに全部一気にリンクする

バラバラにstatic libで配布されててswiftpmがリンクしてるけど

2:50 PM

wasiシンボルはそれでもまだつなげていなくて

2:50 PM

それはwasm上でロードするときにwasmerのjs実装が流し込まれてるのか。

で、その結果、最後までundefinedだったシンボルについて、ランタイムサイドからインポートするようなImportセクションを書き出すのがリンカの仕事です

そうするとやっぱJSで流し込む直前につなぎ替えることになりそう

つなぎかえ？

> void __wasi_fd_write(...) { > // do redirect > return original_fd_write(...); > } > void original_fd_write(...) __attribute__(( > __import_module__("wasi_snapshot_preview1"), > __import_name__("fd_write") > ))

(edited)

2:53 PM

↑この方法が機能しない気がしてる

2:54 PM

__attribute__(( __import_module__("wasi_snapshot_preview1"), __import_name__("fd_write") )) __wasi_fd_write(...) ↑すでにこう書かれたヘッダーがビルドに含まれてるわけでしょ？

はい

original_fd_write と、 wasi関数を受け取ろうとしてるやつが2つできちゃうし

2:54 PM

どっちが本物になるのか曖昧にならん？

あー、

2:55 PM

たぶんおもちさんの誤解ポイントが分かった

もともとある wasiのfd_writeをつなぎこもうとしてる __wasi_fd_write と新たに作ろうとしてる、もうひとつの fd_writeを本当につなぎたい original_fd_write と、

2:55 PM

2つある状態になる。

リンカがシンボルを解決するタイミングでは __import_name__ は見ていなくて、C的なシンボルでルックアップしています

あ、じゃあ、実装付きの __wasi_fd_write が別途存在すればそれはそこにつながるのか。

で、wasi-libc側のヘッダに書かれた __wasi_fd_write は実装が無いがユーザーが定義した __wasi_fd_write には実装があるので、この時点で __wasi_fd_write はundefinedなシンボルではなくなります

ふむふむ

definedなシンボルに対してはリンカはimportエントリを発行しないのでwasi-libc側のヘッダの __import_name__ は無視されます

はいはい。

original_fd_write は実装が無いのでundefinedなので、__import_name__ に基づいてimportエントリを発行します

2:59 PM

なのでリンカ的には曖昧さは無いんですよ

なるほどー　そこの処理手順がわかってなかった

3:01 PM

たしかにそれなら安定した挙動でさしこめるな。

リンカを書くとリンカの気持ちがわかるようになる

シンボル解決できたらimport attributeを無視するの気持わかるのだいぶ深い

3:06 PM

あ、もう一個シンプルな方法あるな

3:06 PM

/dev/stdout を wasi で fopen して poll_oneoff 回せば良いんだ。

3:07 PM

スレッドは立てられないから、requestRenderで毎回見るとかtimerとかぶん回す必要があるけど

あー、別のwasmインスタンスを作ってその中で回す？

別のインスタンス！？

3:07 PM

そんな裏技があるの

え、WebAssembly.instantiateをJSから作るだけ。。。

回すとは？

3:08 PM

this.view.setUint32(nevents, eventc, true); while (bindings.hrtime() < waitEnd) { // nothing } return WASI_ESUCCESS;

3:09 PM

タイムアウト無限だとビジーループしてそうなんだよね実装が

wasmerのwasiインスタンスをもう一つのwasmインスタンスと共有してpollを回す

https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame

Window.requestAnimationFrame()

The window.requestAnimationFrame() method tells the browser that you wish to perform an animation and requests that the browser calls a specified function to update an animation before the next repaint. The method takes a callback as an argument to be invoked before the repaint.

3:10 PM

ブラウザだと多分これが良いんだと思う

3:10 PM

ああ、「回す」の

3:11 PM

ループを作る方法が問題ってこと。

あーそうか

3:12 PM

難しいな

https://rhysd.hatenablog.com/entry/2015/11/22/223050

rhysd

vimconf でブラウザ上で Vim を使う方法を発表してきた - はやくプログラムになりたい

今年も vimconf にスタッフ兼発表者として参加してきました．名札の名前が「ドッグ」でじわじわきました… 開場当日は準備スタッフの作業のために 8:30 に会場へ．山手線の遅延に巻き込まれて 8:45 ぐらいに到着．電源ケーブルの配線などをやりました． Vim on Browser vimconf での発表は今年で3回目です．最近趣味ではウェブのフロントエンド周りや Electron を触っているので，今回は便利プラグインとかの実用的な話からそれて "Vim on Browser" というタイトルで発表してきました．ブラウザ上で「本物の」...

requestAnimationFrameがマシなのか

りんださんがvimをブラウザで動かした時に同じような問題があってそうやってたって言ってたようなないような (edited)

見たことがある気がする

3:15 PM

https://speakerdeck.com/rhysd/vim-compiled-to-webassembly?slide=17

Linda_pp

Vim compiled to WebAssembly

Emscripten & WebAssembly night !! #8
30min
Demo: https://rhysd.github.io/vim.wasm/
Repo: https://github.com/rhysd/vim.wasm
Event: https://emsn.connpass.com/event/136346/

3:15 PM

こっちのスライドだ

WebWorkerで並行実行させて

atomicで止める

AtomicsAPIとやらでタイミングを制御とな

3:18 PM

うーむ。

https://discordapp.com/channels/291054398077927425/291397416043675649/765497305637584906 から。

8:54 AM

関数にしておけば名前が被ってしまう問題も回避できそうに思います。

シャドーイングを回避するとそうなりますよねー

メソッドチェーンで書けないのも、どうせ try とか await は前に書くし、前に書いちゃえば良さそう。 let x = try await jsTry(jsAwait(foo.bar.baz))

8:55 AM

jsTryAwait があってもいいか。

どうせ try とか await は前に書くし

たしかに

8:57 AM

let result = await jsAsync(fetch)("...")

そっちは大変じゃないですか？どうせ fetch は Promise 返すんだから、 await jsAsync(fetch("...")) でも良さそうな気も？

9:00 AM

エラーについては JSValue に case error(JSValue) を追加すれば良い？

9:00 AM

あ、循環しちゃうから indirect

9:01 AM

（でも .error がネストしてほしくないから微妙だな・・・。）

JSError が既にあるので case error(JSError) にできそう

なるほど。

JSのエラーはオブジェクトのはずなのでJSValueである必要は無いかな (edited)

string を throw したときは String になってるんですっけ？

特定の型の式だけではなく、あらゆる式をスローすることができます。

https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Control_flow_and_error_handling

制御フローとエラー処理

cv

9:04 AM

オブジェクトだけじゃないのか！

あらゆる式を throw できるけど、オブジェクト化されてる可能性もあるのかなと。

try { throw 1 } catch(e) { console.log(e) } // 1 (edited)

9:06 AM

普通に値のままですねー

typeof も試してみましたが、オブジェクトになってませんでした。

9:07 AM

いちおうブラウザで試してみましたが、↓で string と出てきました。 <script> try { throw 'error'; } catch(e) { alert(typeof e); } </script>

9:09 AM

あー、 JSError っていうのは throw された値を格納するためのものじゃなくて、 JavaScript の Error に対応してるんですね。

ああ、そうですそうです

うーん、論理的には↓みたいな構造にしないとネストを防げなさそうだけど、この変更はちょっと・・・。

enum JSValue { case success(_JSValue) case failure(_JSValue) enum _JSValue { case boolean(Bool) case string(JSString) ... } }

9:15 AM

enum JSValue { case boolean(Bool) case string(JSString) ... case error(JSErroValue) } enum JSErrorValue { case boolean(Bool) case string(JSString) ... }

9:15 AM

↑の方が現実的かな。

JSValueのerror caseをユーザーがハンドリングすることは滅多に無い気がするので、できれば追加したくないなぁ

9:21 AM

jsTry がJS関数を受け取るようにすれば内部に隠蔽できるかもしれない

DOM はわかりませんが、 JS のライブラリを使うときに JS 側でエラーが throw されることは普通にありそうな気がします。

9:22 AM

func jsTry(_ f: JSFunction) -> JSThrowingFunction みたいな？

JSValueのerror caseをユーザーがハンドリング

これは例えばこういうコードはユーザーは滅多に書かないのでJSValueのケースを増やしても使われないんじゃないかなと let result: JSValue = ... if case .error(let error) = result { // ... } // or if let error = result.error { // ... }

9:24 AM

throwされることは普通にあると思います。

僕のイメージしてたのは JSValue にエラー情報を埋め込んじゃって jsTry されたときにエラーを throw するというものだったので JSValue に埋め込まざるを得ませんでしたが、 JSThrowingFunction みたいなものに変換する方式なら JSValue はいじらずに済みそうですね。

9:26 AM

ただ、それだと関数よりやっぱりメソッド／プロパティであってほしいかなぁ。当初の .throwing みたいに。

func jsTry(_ f: JSFunction) -> JSThrowingFunction

こんなイメージでした

9:26 AM

ですよねぇ

9:26 AM

これはもう一つ問題があって、

JSValue に埋め込むなら jsTry と try が必ずセットになるから先頭に戻ってもいいけど、 JSThrowingFunction 方式だとそうは限らないですもんねー。

9:28 AM

ただ、 JSThrowingFunction 化してから Swift で取り回すことを考えると、こっちの方がいい気もしますね。毎回 jsTry 噛まさなくてもいいし。

取り回しが難しいんですよね。

9:30 AM

例えばこれと let div = document.createElement!("div") これは let createElement = document.createElement.function! createElement("div") thisの扱いが違うんですよね。 (edited)

関数になっちゃうのは諦める場合、変換方式なら関数名は jsTry / jsAwait よりも jsThrows / jsAsync が良さそうですね。

9:31 AM

出た、 JS の this 問題。

上の場合、JSObjectに生えてるsubscript(dynamicMember name: String) -> ((ConvertibleToJSValue...) -> JSValue)? が呼ばれて、thisがレシーバでバインドされるんですが https://github.com/swiftwasm/JavaScriptKit/blob/4b7981bc1b81a1f25e7aca851866d55913657d61/Sources/JavaScriptKit/FundamentalObjects/JSObject.swift#L34-L40 (edited)

swiftwasm/JavaScriptKit

Swift framework to interact with JavaScript through WebAssembly. - swiftwasm/JavaScriptKit

9:32 AM

下の場合一度 JSFunction になってしまって、JSFunctionのcallAsFunctionで実行されるのでthisがバインドされないんですよね https://github.com/swiftwasm/JavaScriptKit/blob/4b7981bc1b81a1f25e7aca851866d55913657d61/Sources/JavaScriptKit/FundamentalObjects/JSFunction.swift#L21 (edited)

swiftwasm/JavaScriptKit

Swift framework to interact with JavaScript through WebAssembly. - swiftwasm/JavaScriptKit

9:33 AM

で、 jsThrows 方式で行くと、レシーバのバインディングができないなと。

これは解決が難しそう・・・

あー、 (ConvertibleToJSValue...) -> JSValue) をjsThrowsの引数に取れば良いのか？ (edited)

なるほど。

func jsThrows(_: (ConvertibleToJSValue...) -> JSValue)) -> (ConvertibleToJSValue...) throws -> JSValue) func jsThrows(_: JSFunction) -> (ConvertibleToJSValue...) throws -> JSValue)

オーバーロードして用意しておけばいけそうな気がしますね。

この2つのオーバーロードがあれば良さそう

9:36 AM

これはなんだか実装できそうな気がしてきました

これができるとこれに合わせて jsAsync も実装できそうでいいですね。

9:38 AM

PythonKit は throws/try はどうしてるんでしょうね？

9:39 AM

https://github.com/pvieito/PythonKit/blob/a0817e0d68f0a50a631fc5fab0b8d219fd010241/PythonKit/Python.swift#L199-L206

pvieito/PythonKit

Swift framework to interact with Python. Contribute to pvieito/PythonKit development by creating an account on GitHub.

9:39 AM

これ？

お、考えることは同じだなぁ

Python でもシャドー問題はありますよね。

9:42 AM

Swift で throws は現状で identifier として使えないですけど、 async は使えてすでに使われてて、そう考えると throws も identifier として使えるようにするという変更があり得て、その上で throws と async を使うことで名前被りを避けることはできない？

9:43 AM

https://www.w3schools.com/js/js_reserved.asp

9:43 AM

throws は JS で予約語だから、 throws さえ使えれば foo.throw がいけそう？

9:46 AM

@swift-main -Xfrontend -enable-experimental-concurrency struct Foo { func foo() async {} func async() {} } (edited)

@swift-main struct A { var `throws`: Int { 1 } } _ = A().throws (edited)

no output (edited)

9:46 AM

no output

throws使えるっぽい？

おおお

これは良い

そうすれば throws にしちゃえば解決じゃないですか？

ですね

9:47 AM

おー、これはキレイにまとまりましたね

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#Keywords

Lexical grammar

This page describes JavaScript's lexical grammar. The source text of ECMAScript scripts gets scanned from left to right and is converted into a sequence of input elements which are tokens, control characters, line terminators, comments or white space. ECMAScript also defines c...

9:48 AM

さっき貼ったページがあやしかったので

9:48 AM

調べ直したら

9:48 AM

Future reserved keywords in older standards The following are reserved as future keywords by older ECMAScript specifications (ECMAScript 1 till 3).

9:48 AM

なのでダメ？

a.import a['import'] a = { import: 'test' }.

9:50 AM

これは合法っぽいですね

<script> const a = { throws: 'foo', }; console.log(a.throws); </script>

var obj = { throws: 1 } これも書けるっぽい。。。 (edited)

これで foo と表示されちゃいました

9:50 AM

あー、せっかくいい案だと思ったのに・・・。

ソースコード上の識別子の制約と実行時のフィールド名の制約は別物なんですね (edited)

あ、その import のコードは上記ページのものだったんですね。

そうですそうです

生きてる予約語でダメなら "in older standards" 関係なくダメだ・・・。 (edited)

そうするとやっぱり jsThrows で外から被せる方式ですかね

そうですねぇ・・・。

9:55 AM

演算子とかは避けたいですもんねｗ

グローバルに関数を生やすと補完に出ないのがなぁ。。

throws はダメだったけど、 JS で使えない identifier にするって方法はないでしょうか？

9:59 AM

Swift でしか使えない文字とかがあれば。

JavaScript オブジェクトはキーと値を所持しています。キーは文字列 (または Symbol) ですが、値はなんでもかまいません。これにより、オブジェクトはハッシュマップの様相を呈します。

https://developer.mozilla.org/ja/docs/Web/JavaScript/Data_structures 特にキーに制約なさそうなんですよね (edited)

JavaScript のデータ型とデータ構造

あらゆるプログラミング言語は、それぞれ異なったデータ構造を持っています。この記事では、JavaScript で使用可能な組み込みデータ構造の一覧と、他のデータ構造の構築にも使えるように、それらがどのような性質を持ち合わせているかについて述べることにします。また可能である場合は、他のプログラミング言語におけるデータ構造との対比も行います。

1

まったく関係ないんですけど、前から気になってたんですが、 JSObject を @dynamicMemberLookup にするより、直接 JSValue を @dynamicMemberLoopup にして callAsFunction も持たせちゃった方が便利だったりしないでしょうか？どのみち JS 使ってる時点で安全じゃないですし。 (edited)

10:06 AM

! や .object, .function などを挟まないといけないのが気になってます。

過去に話に出たんですが、それもシャドーイングの問題で辞めておこうって話になったんですよね

10:07 AM

でも改めて考えると名前が被ったときだけ明示的に.object経由でアクセスすれば良いような気もします

お、過去にも出てたんですね。どの issue か教えてもらってもいいですか？

どこだったかな

JSValue にメンバを生やさないで済むのならシャドーイングは問題にならないですか？

見つからなかったので夢かDMで話したんだと思います

夢ｗ

10:12 AM

jsTry とかと合わせるなら関数か static メソッド／プロパティにしちゃって、インスタンスメソッド／プロパティは @dynamicMemberLookup と callAsFunction のものという切り分けにできるなら、シャドーイングも避けられて切り分けも明快かなと。 (edited)

ふむふむなるほど

グローバル関数あまり追加したくないから、 JS. とかがあってもいいかもですね。

10:14 AM

JS.throws, JS.async

https://github.com/swiftwasm/JavaScriptKit/pull/98

[Proposal] Add unsafe convenience methods for JSValue by kateinoiga...

I got feedback that the current API to access JavaScript objects is redundant. As he says, I agree that method!(...) and .object! for every object access is very redundant. I think we can provide u...

11:53 AM

これを試しにやってみました https://discordapp.com/channels/291054398077927425/383442648012423179/765515356889546752

おお、早速。いいですね！

沢山シェルスクリプトを書いてようやくmacOS向けのInstaller配布ができるようになりました https://github.com/swiftwasm/swift/releases/tag/swift-wasm-5.3-SNAPSHOT-2020-10-20-a

Release swift-wasm-5.3-SNAPSHOT-2020-10-20-a · swiftwasm/swift

2

11:50 AM

swiftenvなしで入れられます

おー

CI上でプロンプト出さずにコードサインするのが鬼門でした

仕事が落ち着いたら触りたい

1

macOS向けInstaller、インストール後に作成するシンボリックリンクがswift-latest.xctoolchainではなくswift-latestになってる。

ホントですね、ありがとうございます

10:40 AM

アップストリームのスクリプトがそもそもswift-latestになってました… https://github.com/apple/swift/blob/main/utils/darwin-installer-scripts/postinstall

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

実際の配布パッケージswift-DEVELOPMENT-SNAPSHOT-2020-10-24-a-osx.pkgに入ってるpostinstallはこんな感じ。

#!/bin/bash INSTALLED_TOOLCHAIN=$2 rm -f "${INSTALLED_TOOLCHAIN%/*}/swift-latest.xctoolchain" ln -fs "${INSTALLED_TOOLCHAIN}" "${INSTALLED_TOOLCHAIN%/*}/swift-latest.xctoolchain"

(edited)

12:44 PM

CIでの.pkg作成を確認しようとしたら https://ci.swift.org 落ちてるぽい。 (edited)

そうか、たしかにCIでもインストーラつくってますね。

12:46 PM

メンテでは無さそうだなぁ

上記パッケージのビルドログを見る限りswift/utils/toolchain-installerは使ってないと思われる。 https://ci.swift.org/view/Packages/job/oss-swift-package-osx/5218/

秘密のシェルスクリプトがあるのか…

https://twitter.com/kateinoigakukun/status/1326317368847446016?s=20 https://twitter.com/kateinoigakukun/status/1326317414498271232?s=20

The first stable toolchain release of SwiftWasm! https://t.co/iFb945eIHH

Setup - Swift and WebAssembly

日本語 https://t.co/4fp9VtuaUX

3

2

現在のtoolchainがWasmをサポートしてるかどうか、ってどうやって判定するの？

-targetにwasm32-unknown-wasiを渡してみるか、--versionでベンダー名を見るかですかね

ふむ。

$ echo 'print("hello")'|swiftc -target wasm32-unknown-wasi - <unknown>:0: error: unable to load standard library for target 'wasm32-unknown-wasi'

5:19 AM

arm64がサポートされてるかどうかビルドしてみないと判らないみたいで、Wasmがどうしてるのか気になったのでした。

5:23 AM

ghcr.io/swiftwasm/swift:latestのダウンロードが遅い…

--print-available-targetsみたいなオプションがあると良いんですけどねー

clang11でそんな感じのオプションが追加されるかも？ってのを見かけました。

5:28 AM

実際には追加されてないね…

一緒にビルドされたllcがあれば--versionで見れるっぽいですね

5:29 AM

$ llc --version LLVM (http://llvm.org/): LLVM version 11.0.0 Optimized build. Default target: x86_64-apple-darwin19.6.0 Host CPU: skylake-avx512 Registered Targets: aarch64 - AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) aarch64_be - AArch64 (big endian) ...

arm64サポート有無のチェックはこんな感じとすることに。

$ echo 'print("hello")'|xcrun --toolchain org.swift.50320190830a swiftc -target arm64-apple-macos10.9 - -o /dev/null <unknown>:0: error: unable to load standard library for target 'arm64-apple-macos10.9' $ echo 'print("hello")'|xcrun --toolchain org.swift.531202011121a swiftc -target arm64-apple-macos10.9 - -o /dev/null

で、同様にWasmをチェックしてみるとエラーになった。

$ echo 'print("hello")'|xcrun --toolchain org.swiftwasm.20201102 swiftc -target wasm32-unknown-wasi - -o /dev/null wasm-ld: error: cannot open crt1.o: No such file or directory wasm-ld: error: unable to find library -ldl wasm-ld: error: unable to find library -lc++ wasm-ld: error: unable to find library -lc++abi wasm-ld: error: unable to find library -lm wasm-ld: error: unable to find library -lwasi-emulated-mman wasm-ld: error: unable to find library -lc clang-10: error: linker command failed with exit code 1 (use -v to see invocation) <unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)

docker版はエラーにならない。 $ echo 'print("hello")'|docker run ghcr.io/swiftwasm/swift swiftc -target wasm32-unknown-wasi - -o /dev/null (edited)

あー、おー

7:05 AM

xcrunか〜

7:06 AM

xcrunセットするSDKROOTを優先して見ちゃってますね

あ、SDKROOKか。

7:11 AM

https://book.swiftwasm.org/getting-started/setup.html に書かれたxcrunを使う方法は使えないということ？

SwiftPMはSDKROOTに左右されずに-sdkをコンパイラに渡すのでxcrunでも動くんですよね。

7:13 AM

コンパイラ単体だとxcrunだと駄目ですね。直しておきます

なるほど。

7:16 AM

とりあえず、上記Wasmサポートの検出手順は、手順の汎用性を確認するために試してみただけで、SwiftWasmに対して実用する予定は今のところ無いです。 (edited)

1

上記手順でswiftcを使ったのは、swiftだとビルドに成功しても実行に失敗するから。

macOS版.pkgによるswift-latest.xctoolchainシンボリックリンクの作成、既にシンボリックリンクが存在するとシンボリックリンクが指す先に新しいシンボリックリンクを作ってしまう。 https://github.com/swiftwasm/swift/blob/swiftwasm/utils/darwin-installer-scripts/postinstall#L16 これを避けるためにln -fhs …とかに変えるべき。

LN(1) BSD General Commands Manual LN(1) … -h If the link_name or link_dirname is a symbolic link, do not follow it. This is most useful with the -f option, to replace a symlink which may point to a directory.

(edited)

swiftwasm/swift

WebAssembly support for the Swift Programming Language - swiftwasm/swift

なるほど、デフォルトはリンクを追っかけるんですね

4:04 AM

ありがとうございます

katei氏と呼ばれててそこで切れるんだって思った https://www.publickey1.jp/blog/22/rubywebassemblywasiwebassemblyruby.html

RubyがWebAssemblyのWASI対応へ前進。ブラウザでもサーバでもエッジでもどこでもWebAssembly版Rubyが動くよ...

Ruby言語のリファレンス実装、すなわち事実上の標準となっているRubyインタプリタはC言語で実装されています。そのため、このRubyインタプリタもしくはそのソースコードは一般に「CRuby」（もしくは、まつもとゆきひろ氏による実装という意...

身のある情報を提供できた

https://book.swiftwasm.org の流れでwasmをビルドすると wasi_snapshot_preview1 モジュールの関数一式をimportしたがるwasmファイルが生成されるのですが、これって外せないのでしょうかね？

Introduction - Swift and WebAssembly

色々とわかってきた。これはwasm-bindgenがすごすぎるんだなぁ

WASI-lessバイナリはなかなか面倒なんですよねー。一応TODOとしては挙がっていますが

5:34 AM

WASI無しで表現できるlibcとlibcxxを作るか、Swiftのランタイムから完全にそれらの依存を取り除くかしか無くて。（バイナリいじってゴニョゴニョする手もあるがメンテ大変なのでできればやりたくない） (edited)

5:36 AM

wasm-bindgenはかなり色々やっててすごい

WASIの扱いが面倒で、WASI使ってなければ消したいと思って調べてたらwasm-bindgenはWASI無くても動いててどういうことかと思ったら出力先ごとにWASI相当のランタイム実装埋め込んでてすごすぎ〜となった

ブラウザでなんかしようと思うとWASI邪魔なんですよね。wasmerの提供するWASIブラウザpolyfillは微妙だし。

5:42 AM

しかしWASIが無いと満足にprintすらできないのは厳しい

このツイートを見かけたんですが、標準ライブラリはともかく、言語仕様が軽量化の阻害要因になっている点があるんですっけ？LLVMに落ちてしまえば関係なさそうな？前のわいわいの話みたいに、LTOしやすい／しにくいとかはあるかもですが。 https://twitter.com/mizchi/status/1532215162576379904

mizchi (@mizchi)

本当に書ければ選択肢にはなるんだろうけど、あの言語仕様をAOTとはいえ軽量なランタイムに落とすのかなり無理筋では

6:54 AM

https://twitter.com/laiso/status/1532212759081152514

🕳️ (@laiso)

SwiftでWASMアプリケーションを書きたいかはmizchiさんがコメントしてくれます

みずちさんが「あの言語仕様」として言及したいのがどういう部分なのかわかんないですけど

6:55 AM

SwiftはRustと比べると

軽量というのがサイズ面なのか実行速度面なのか難しい

ここで言ってるのはサイズですね。

Resilencyのためにランタイムで持ってるリフレクションっぽい機能とか

Yuta Saito

軽量というのがサイズ面なのか実行速度面なのか難しい

このスレッドで↓のように続いているのでサイズかなと。 https://twitter.com/mizchi/status/1532216813932584960

mizchi (@mizchi)

ちなみに、自分が他の言語からの Wasm コンパイルで実用可能/エコシステム構築可能と思ってる現実的なラインは、ランタイムのオーバーヘッドが50kb以内です。これを満たしてるのは no_std な rust だけです。

50kb

Unicodeのための定義情報とか

6:56 AM

KeyPathのためのランタイムとか

6:56 AM

そういうランタイム関数がたくさんあるので、

6:56 AM

ランタイムのバイナリサイズが大きいというのはあるんじゃないかなと思ってます

ランタイムキャストやデマングラーのコードが割と重いです

あとはこれはLTOでカットできる話とかもあるけどメタタイプとかが埋め込まれてデカいとか

Yuta Saito

ランタイムキャストやデマングラーのコードが割と重いです

ほ〜

6:58 AM

あとstdlibも普通にデカい気が。AnyHashableとか、純粋に振る舞いのロジックが複雑なためにコード量でかそうなやついろいろあるし。 (edited)

Unicode周りはRustは落とした状態でだからフェアな比較じゃないと思っていて、あとはLTOで頑張ればかなり落とせる可能性あるのかなぁと思ってました。

その辺はライブラリの作り方が微妙なだけなんですよ。言語仕様はあんまり関係ない。

いやでも、規格としてmini Swiftみたいな方言が無いので

6:59 AM

結局フルスペックなstdlibが必要でしょう

いや、使わないやつはリンクしなければ良いんですよ

あーstdlibの個別のコンポーネント自体はそっか。リンク時にカットできるか。 (edited)

6:59 AM

じゃあランタイム関数だな、どうしようもなさそうなのは

今はlibswiftCore.aにSwift.oとしてstdlibのSwiftパートがドーンとあるから、一個でもstdlib関数をリンクすると全部ついてきちゃう

7:00 AM

そすね

まあサイズはある程度大きくても許容できるように環境がなっていくというのもありますよ。

Kishikawa Katsumi

まあサイズはある程度大きくても許容できるように環境がなっていくというのもありますよ。

実は僕はそっちのほうにウェブが進むほうが筋が良いと思っています

omochimetaru

いやでも、規格としてmini Swiftみたいな方言が無いので

これについては、一つの可能性として、SwiftWasmがSwiftのサブセットを仕様策定すれば、それが準公式になりそう。

wasmが実用的になる前に回線速度が向上する可能性は全然ありますよね

koher

これについては、一つの可能性として、SwiftWasmがSwiftのサブセットを仕様策定すれば、それが準公式になりそう。

それはそうですね。ポータブルなSwiftっていう概念が合っても良いと思います。今の所コアチームは方言的な発想にはいつも否定的ですけど

omochimetaru

実は僕はそっちのほうにウェブが進むほうが筋が良いと思っています

全てのサイトで横断的に、「Swiftランタイム」が使えれば、そもそも合理的だと思うんですよね。

7:02 AM

macOSが出荷してるものを事前にブラウザに入れておくって感じです

7:02 AM

昔のFlash playerと同じ。 (edited)

7:03 AM

幸いSwiftのランタイムは、macOSとのからみで、ランタイムの前方互換性が意識されてるし。

7:03 AM

(という趣旨の意見を以前みずちさんに投げてみたんだけど、実際のところはクロスオリジンセキュリティの観点でそういうモチベーションは低そうらしい・・・

Wasmがもっと一般的になってきたら、主要言語のランタイムはブラウザに埋め込む時代が来たりしないのかな？

Wasmとしては、モジュールの再利用性を進める機能が提案されていて、プログラム間でランタイムを再利用できるっていうのはありえるかなぁ https://github.com/WebAssembly/component-model

GitHub - WebAssembly/component-model: Repository for design and spe...

Repository for design and specification of the Component Model - GitHub - WebAssembly/component-model: Repository for design and specification of the Component Model

Yuta Saito

Wasmとしては、モジュールの再利用性を進める機能が提案されていて、プログラム間でランタイムを再利用できるっていうのはありえるかなぁ https://github.com/WebAssembly/component-model

いいね。

それはよさそう。

koher

Wasmがもっと一般的になってきたら、主要言語のランタイムはブラウザに埋め込む時代が来たりしないのかな？

現状のブラウザプラグインみたいな感じでユーザーが管理できると良いと思うんですよね

7:06 AM

初回表示の時にいい感じのUXにできるかは気になるけど・・・

omochimetaru

現状のブラウザプラグインみたいな感じでユーザーが管理できると良いと思うんですよね

そこの一歩が結構厳しい気が。

その辺はもうちょっとやりようがありそう

7:07 AM

まあ現状SwiftでWasmの用途としては、既存コードのWebへの移植がメインですね。 (edited)

wasmもだけど、フロントエンドで推論回したいとかもあったりするので

7:09 AM

ドデカバイナリをなんとかしてブラウザで扱いたいなというのは今後叶っていって欲しいところ

インターネットがはやくなってほしい

Yuta Saito

まあ現状SwiftでWasmの用途としては、既存コードのWebへの移植がメインですね。 (edited)

移植用途だと方言は厳しいよな〜

そもそも、方言はメンテ出来るパワフルな人が居ればやるかもしれないけど、現状きびしいですねぇ

人的リソースが厳しいのか・・・。逆方向はあり得るのかなと思ってたけど。Wasmに最適化されたSwiftのサブセットで、サブセット用に書かれたコードは本家でも実行できる、みたいな。

7:15 AM

第三者がやっても広く利用されるのは厳しいと思うけど、SwiftWasmのプロジェクトとしてなら受け入れられそう。

どの機能を取り除くとどのくらいバイナリサイズがカットできて、一方でどういう問題が起きるか、を整理するだけでもかなり大変そう。

そうなんですよ、まず分析が必要。

7:19 AM

分析するにはコンパイラを触れる人が必要で、一方でそういう人はUpstreamingで手が一杯

今回のRegex関係とかもそうだけど

7:20 AM

未だに結構バンバンビルドとかリンク構成とかが更新されるしね。

7:20 AM

この前のConcurrency runtimeとかもそうだな。

7:21 AM

コンパイラのローレベルな生成部分だけ対応しておけば後は自動的に・・・って行ってないのが大変そう。 (edited)

人員絶賛募集中

ｗ

7:23 AM

https://twitter.com/kateinoigakukun/status/1532253393346912256