swift-developers-japan

@hiragram

2:25 AM

http://twitter.com/hiragram/status/933883163914276864

@omochimetaru -emit-irで吐いた.llをemに食わせると Appending variables with different alignment need to be linked! って言われてコンパイル通らないんだけどなんだかわかりますか・・・

はい

2:25 AM

$ ./emsdk-portable/emscripten/incoming/emcc swift/hello.ll -o swift/hello.html warning: Linking two modules of different data layouts: '/Users/hiragram/.emscripten_cache/asmjs/dlmalloc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmp4kw329/hello_0.o' is 'e-m:o-i64:64-f80:128-n8:16:32:64-S128' warning: Linking two modules of different target triples: /Users/hiragram/.emscripten_cache/asmjs/dlmalloc.bc' is 'asmjs-unknown-emscripten' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmp4kw329/hello_0.o' is 'x86_64-apple-macosx10.9' warning: Linking two modules of different data layouts: '/Users/hiragram/.emscripten_cache/asmjs/libc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmp4kw329/hello_0.o' is 'e-m:o-i64:64-f80:128-n8:16:32:64-S128' warning: Linking two modules of different target triples: /Users/hiragram/.emscripten_cache/asmjs/libc.bc' is 'asmjs-unknown-emscripten' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmp4kw329/hello_0.o' is 'x86_64-apple-macosx10.9' error: Appending variables with different alignment need to be linked! ERROR:root:Failed to run llvm optimizations:

全体としてはわからんけど何かの型についての情報が足りないって感じがする different alignment はアライメントが違うってことだから

全文

例えば Int は 8 ？(4？) で、 UInt8 は 1 で、みたいな。

2:26 AM

Appending variables ってのがよくわからんね

2:26 AM

どの次元の何のAppendの話なんだろう

元のSwiftは print("Hello, Swift!") これだけ

2:27 AM

1行

ll を生成した行は？

$ swiftc swift/hello.swift -emit-ir -o swift/hello.ll

swiftc swift/hello.swift -emit-ir -static-stdlib -o swift/hello.ll だとどう？

変わらんすねえ

llのサイズ変わった？

2:31 AM

元のやつだと、 print と String についての情報が生成されてないから

かわんない

あと @convention(c) func a(x: Int) -> Int { return x * 2 }

2:32 AM

とかから試したほうが良いと思う

2:32 AM

print とか String の定義とか

2:32 AM

いろいろあるから

ok

あれ～サイズ変わらないのか

2:33 AM

あれか、static-stdlib はリンクステージの話だから、

2:33 AM

ll を吐くステージで止めてるから意味ないのか。

@convention って初めて使った。

(c) つけとくとC言語から呼び出せる関数になる

@omochimetaru swift/hello.swift:1:2: error: attribute can only be applied to types, not declarations @convention(c) ^

付ける場所が違うかもｗ

コンパイル通んなかったｗ

調べて

ok

@_cdecl じゃないかな？

emscripten側は内部に持ってるclangを使っててターゲットが asmjs-unknown-emscripten で、swiftcはターゲットが x86_64-apple-macosx10.9 になってるっぽい

2:50 AM

warning: Linking two modules of different data layouts: '/Users/hiragram/.emscripten_cache/asmjs/dlmalloc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWhbLkq/hello_0.o' is 'e-m:o-i64:64-f80:128-n8:16:32:64-S128' warning: Linking two modules of different target triples: /Users/hiragram/.emscripten_cache/asmjs/dlmalloc.bc' is 'asmjs-unknown-emscripten' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWhbLkq/hello_0.o' is 'x86_64-apple-macosx10.9' warning: Linking two modules of different data layouts: '/Users/hiragram/.emscripten_cache/asmjs/libc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWhbLkq/hello_0.o' is 'e-m:o-i64:64-f80:128-n8:16:32:64-S128' warning: Linking two modules of different target triples: /Users/hiragram/.emscripten_cache/asmjs/libc.bc' is 'asmjs-unknown-emscripten' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWhbLkq/hello_0.o' is 'x86_64-apple-macosx10.9'

2:51 AM

swiftc側のコンパイルをasmjs-unknown-emscriptenをターゲットにできればいいのかな

https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html#//apple_ref/doc/uid/TP40014216-CH8-ID17

2:52 AM

微妙に書いてないな・・・

2:54 AM

あーどうなんだろう、同じになったほうがいいけど、しなくても大丈夫な気もしつつ。

2:54 AM

LLVMIR の時点で LLRMIR 側の i32 みたいな型で記述されているから

alignmentが合わないのはそこの差異が原因ってことはないもの？

ターゲットの違いがあまり問題にならない気もする

ふむ

いや、ありえる

なんか調べた感じemは自分でclangのコンパイラ持ってて、swiftcで使ってるやつと別のやつが動いてる気がする

うん、それはそう

2:55 AM

emはIRからその先の変換処理をもつために独自改造したclangを使うんだと思う

emのSwiftに関するなっげえissue今読んでる

序盤はdylib周りよ

2:56 AM

とりあえず @convention(c) はおいといて普通にfuncつくろう

2:56 AM

普通の(トップレベルでキャプチャがない) funcはC互換な気がしてきた

2:57 AM

ObjCから呼べるし。(thunkが作られている可能性はあるが

hello.swift空っぽにしても同じエラーなんだけどそういうもん？

マジか

なんかfuncとかのステージにすら立ててない感ある

逆にコンパイル後ってそれ何が入ってる？

; ModuleID = 'swift/hello.ll' source_filename = "swift/hello.ll" target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx10.9" @__swift_reflection_version = linkonce_odr hidden constant i16 3 @llvm.used = appending global [1 x i8*] [i8* bitcast (i16* @__swift_reflection_version to i8*)], section "llvm.metadata", align 8 define i32 @main(i32, i8**) #0 { entry: %2 = bitcast i8** %1 to i8* ret i32 0 } attributes #0 = { "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "target-cpu"="core2" "target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+ssse3,+x87" } !llvm.module.flags = !{!0, !1, !2, !3, !4, !5, !9, !10} !0 = !{i32 1, !"Objective-C Version", i32 2} !1 = !{i32 1, !"Objective-C Image Info Version", i32 0} !2 = !{i32 1, !"Objective-C Image Info Section", !"__DATA, __objc_imageinfo, regular, no_dead_strip"} !3 = !{i32 4, !"Objective-C Garbage Collection", i32 1280} !4 = !{i32 1, !"Objective-C Class Properties", i32 64} !5 = !{i32 6, !"Linker Options", !6} !6 = !{!7, !8} !7 = !{!"-lswiftCore"} !8 = !{!"-lobjc"} !9 = !{i32 1, !"PIC Level", i32 2} !10 = !{i32 1, !"Swift Version", i32 5}

2:58 AM

空のhello.swiftのemit-irしたものね

@llvm.used = appending global [1 x i8*] [i8* bitcast (i16* @__swift_reflection_version to i8*)], section "llvm.metadata", align 8

2:59 AM

これあやしそうだね

その怪しみ分からない…

appending

おー

あと、外部関数 __swift_reflection_version

2:59 AM

が絡んでる。

2:59 AM

原理的にいまうまくいかない理由になる。

3:00 AM

; ModuleID = 'swift/hello.ll' source_filename = "swift/hello.ll" target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx10.9" define i32 @main(i32, i8**) #0 { entry: %2 = bitcast i8** %1 to i8* ret i32 0 }

3:00 AM

↑これだけにしたらいけないかな、あと、 main があるのおかしい気がしてきました。

3:00 AM

static library としてビルドしよう

3:00 AM

まあ、 main って名前の関数になってくれるかもしれんけど。

Hello All, I tried using clang 3.9.0 to emit the llvm ir with -target wasm32-wasm32-wasm32, but end up getting warning for different data layout and target triple. The question is if llvm WebAssembly target is usable as is to generate llvm ir to be fed to emscripten ?

The warning is expected, but should not cause problems in practice. The important things are the same in those two triples. (Except perhaps for the size of long doubles, is that important in Swift?)

3:02 AM

target違いのwarning問題なしみたいなこと言ってる

3:02 AM

https://github.com/kripken/emscripten/issues/2427#issuecomment-216352538

Unable to compile a simple Swift file (maybe not possible?) · Issue #2427 · kripken/emscripten

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

↑はどう？シンプルにするのと、 static libary にするの。

llをこれに置き換えればよし？

うん。

やってみます

余計そうなのを消してみた。

warning: Linking two modules of different data layouts: '/Users/hiragram/.emscripten_cache/asmjs/dlmalloc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWrnym7/hello_0.o' is 'e-m:o-i64:64-f80:128-n8:16:32:64-S128' warning: Linking two modules of different target triples: /Users/hiragram/.emscripten_cache/asmjs/dlmalloc.bc' is 'asmjs-unknown-emscripten' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWrnym7/hello_0.o' is 'x86_64-apple-macosx10.9' warning: Linking two modules of different data layouts: '/Users/hiragram/.emscripten_cache/asmjs/libc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWrnym7/hello_0.o' is 'e-m:o-i64:64-f80:128-n8:16:32:64-S128' warning: Linking two modules of different target triples: /Users/hiragram/.emscripten_cache/asmjs/libc.bc' is 'asmjs-unknown-emscripten' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWrnym7/hello_0.o' is 'x86_64-apple-macosx10.9' warning: Linking two modules of different data layouts: '/Users/hiragram/.emscripten_cache/asmjs/wasm-libc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWrnym7/hello_0.o' is 'e-m:o-i64:64-f80:128-n8:16:32:64-S128' warning: Linking two modules of different target triples: /Users/hiragram/.emscripten_cache/asmjs/wasm-libc.bc' is 'asmjs-unknown-emscripten' whereas '/var/folders/b6/shjk0l7j0mb0j9__n3w7z92w0000gn/T/tmpWrnym7/hello_0.o' is 'x86_64-apple-macosx10.9' warning: incorrect target triple 'x86_64-apple-macosx10.9' (did you use emcc/em++ on all source files and not clang directly?)

3:05 AM

warningはなんか出たが一応エラーなく終了した。

いけたｗ

wasmファイルも書き出された。

3:05 AM

電車降りちゃうからまたあとで

https://github.com/apple/swift/blob/master/lib/IRGen/GenReflection.cpp#L779 https://github.com/apple/swift/blob/master/lib/IRGen/IRGen.cpp#L1130 https://github.com/apple/swift/blob/master/lib/IRGen/GenMeta.cpp#L2036

apple/swift

swift - The Swift Programming Language

apple/swift

swift - The Swift Programming Language

apple/swift

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のとこに行きそう

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

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

apple/swift

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になるんかな

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

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

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

kateinoigakukun (@kateinoigakukun)

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

1

9:06 AM

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

Getting Started - Swift and WebAssembly

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

kateinoigakukun (@kateinoigakukun)

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

1

6:31 AM

6:32 AM

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

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

WebAssembly/wasi-libc

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なのか。

WebAssembly/wasi-libc

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

2:00 PM

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

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

WebAssembly/wasi-libc

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://github.com/WebAssembly/wasi-libc/blob/29d45024c71571d50ec2f98bbe57df9efe57eb65/libc-bottom-half/headers/public/wasi/core.h

WebAssembly/wasi-libc

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

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

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

WebAssembly/wasi-libc

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

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

2:31 PM

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

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" というタイトルで発表してきました．ブラウザ上で「本物の」...