swift-developers-japan

ここならLinux版Swiftの話をしても良いのかな？ (edited)

良いと思います

1:52 AM

linux-swift チャンネルがあったほうがいい？

アプリに対してのサーバーサイドかと思ってた

1:52 AM

linuxチャンネルあってもいいんでない

紛らわしいからつくっとこ

1:52 AM

つくったよ #linux-swift

1

ありがとうございます。

おもちのadminみが増してる

1

Slackと違ってチャンネルが基本全部見えてるの便利

wakaru

なう https://tokyo-ss-swift.connpass.com/event/56630/

Tokyo Server Side Swift Meetup #7 (2017/05/26 19:30〜)

このmeetupは、Server Side Swiftに関することを発表、ディスカッションする場となります。 Vapor, Zewoなどのフレームワークを使ってみた、Swiftサーバーを自分のサービスに導入してみたなどの経験談や、自作しているOSSの紹介など話したいネタがある方は是非、スピーカーとしてご参加ください！ # 発表発表者発表タイトル発表詳細 Yuki Takei (noppoMan) Server Less Server Side Swift with Hexaville Hexavilleを使い、serverlessなSwift製Serverを構築します...

1

https://medium.com/@yukitakei/serverless-server-side-swift-with-hexaville-ef0e1788a20

Serverless Server Side Swift with Hexaville – Yuki Takei – Medium

Hello World.

3:03 PM

ヘキサビル良さげだったいわゆるwebappの枠組みで実装すると、ルーター定義をAWSLambdaにマップしてドッカーでELFバイナリ作って全部デプロイしてくれてサーバーレスでAppServerが動くローカルのデバッガサーバもあってxcodeでブレーク可能

おおー

ステートレスになるのでLambdaの枠組みで自動スケール

xcodeデバッガ使えるの凄い

え、すごい

作者さんは自分の業務二件に今後適用する予定で

3:05 PM

どんどん改良していくそうです

3:06 PM

永続化についてはRDBに対するコネクションプーリングができないのが弱みで、今後の知見を出して行くとのこと

前にもlibuvベースのframework書いてた方ですよね...本当すごい

あ、そうですね、懇親会で話したらそんなこともいってた

コネクションプーリングできない、解決する見込みあるのかしら

ディスコード誘っといたからきたら聞いて

わいわいしてきた

お邪魔しま〜す

2

@noppoman 発表の時に言っていた、「RDBに対するコネクションプーリングができない」件に対して検討してるアイデアってなんでしたっけ

lambdaからRDBや他のミドルウェアに対するコネクションプーリングをどう持つかという点ですが、 lambda <-> TCP proxy server <-> RDB, Redis みたいな感じでミドルウェアとの間にコネクションプールを持つTCPプロキシサーバーを立ててやり過ごすのが妥協案として検討しているものになります。 TCPプロキシサーバーを構築する上でミソになるのが、・SPOFにならないよう複数台立ててLBにぶら下げる・非同期IO+イベントループモデルなサーバーを採用する(microなどの低スペックインスタンスでも十分動作するように) になるのでしょうか。一番簡単なのは、node.jsのTCPサーバー+mysqlクライアントで構築してしまうのが良さそうです。ただ、このアイデアはもはやサーバーレスではなくなりすまし、運用が発生するので、最終兵器感はあります、、 lambdaを使ったアプリケーションのデータストア先として相性が良いものは、コネクションの本数を気にしなくていいdynamodbやkinesis、sqs、s3なので、これらを選択するのが一番最良です。

4:57 PM

ちなみに、SwiftのMysqlクライアントには、 https://github.com/noppoMan/SwiftKnex を利用するつもりです。

noppoMan/SwiftKnex

SwiftKnex - A Mysql Native Client and Query Builder written in Pure Swift

なるほど。RDBプロキシの単機能インスタンスなら、それでもAPサーバを保守するよりはマシそうです。

ですね。 ecsのオーケストレーションとオートスケールを組み合わせる事で、プロキシサーバーレベルであればほぼ運用なしで行けるとは思っています。

この辺も運用し出したら、Dockerfileとcloudformationに切り出してHexavilleのプラグイン的な感じで出そうかなと思います

Swaggerを元にVaporのコントローラとモデルのコードを自動生成するような仕組みをこの休みで作ってたんですが最高ですね

Swaggerを元にVaporのコントローラとモデルのコードを自動生成

気になる

おっ

9:54 AM

具体的にはswaggerのymlを読んで構造化してgybから呼び出せるようなpythonのスクリプトを書きました

9:54 AM

でXcodeのbuild phaseにそのジェネレータを突っ込んでおいてcmd+bのたびに生成されるようにした

あ、ということはSwagger自体が持ってる自動生成の仕組みと別でってことなんですね :tsuyoi: (edited)

swagger-codegenは使ったことないですけど、自由にやりたいという気持ちから自作しました

1

9:56 AM

確かswagger-codegenはjava製だった？ような

9:56 AM

それも使いたくないの理由です

#java

9:57 AM

これか https://github.com/swagger-api/swagger-codegen

swagger-api/swagger-codegen

swagger-codegen contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition.

ですです

swagger、普通にenumとかも表現できそうなので自動生成である程度型化できると嬉しい感あるけど、そこまでやるとやりすぎなのか悩みどころです

どうでしょう

9:59 AM

やり過ぎということは無い気がしていて、むしろSwaggerいじれば全てがそれに合わせて生成される方がハッピーそう

ドキュメント=実装なの最高すなー

自作コードジェネレータはまだSwaggerのenumに対応してないですが、やりたいと思っています

期待

ていうか、gybの導入についてはmoaibleさんのブログにだいぶ助けていただきましたよ

10:00 AM

ありがとうございます

10:01 AM

http://moapp.hateblo.jp/entry/2017/06/30/210636

moapp

Swift gybの環境構築 - モアイはコードを書く

Swift gybの環境構築ふとSwiftのgybが気になったので環境構築を試して見ました gybとは Swift言語開発の副産物のメタプログラミングツールgybがとても良い— おもちメタル (@omochimetaru) 2017年6月30日 gybは「Generate Your Boilerplate」の略称みたいです(gyb --helpより) 具体的に何かと言うと、Swiftの公式リポジトリの中でSwiftコードの自動生成に使われているPython製のテンプレートエンジンになります gybを導入する qiita.com というわけで、こちらを参考に環境構築して見ましたまずgyb自体…

10:01 AM

これ

おおお、良かったです！少しでもお役に立てればッ

コードジェネレータの部分は単独でリポジトリに切り出してGitHubに置くつもりがあるので

10:02 AM

もうすこしこなれたら是非触ってみて貰いたいです

ぜひぜひ！使わせてください

Swaggerからのコード生成、Swaggerの仕様を全部カバーしないといけないの結構大変でバージョン1のリリースかなり遠い感じある

10:16 AM

適当にバージョン0で出しちゃうか

@hiragram >@lovee: そういえばSSSやってる人はみんなVaporとかKituraとかPerfectとかどれでやってますか？

はい

9:05 AM

Vapor

9:05 AM

Vaporマンいたらちょっと聴きたいことあるんで助けてほしいです

やっぱVapor人気っぽいですね

9:55 AM

冬コミ終わったらやってみたい感 is ある（その前に本を…本を……

Vapor Cloudで実際にサービス動かしてる話とかコードジェネレータの話とかするので良かったらきてください https://connpass.com/event/77789/

Vapor Meetup 1st in Tokyo (2018/02/06 19:00〜)

## イベント概要 Swiftはバージョン3以降OSSとなり、LinuxやAndroidなどのAppleプラットフォーム以外での利用シーンも広がってきています。サーバサイドでSwiftを使うことも選択肢の一つになってきています。日本ではまだあまり有名になっていないサーバサイドSwiftの代表的なフルスタックMVCフレームワークであるVaporを取り上げ、サーバサイドSwiftの使い所やメリットやデメリットなど知見を共有し、プロダクションでの実例が増えること目指します。初回はVaporのコアコミッタである Tanner を始め豪華ゲストに参加してもらい、Vaporについて語...

↓すごい。

Vaporの生みの親である Tanner が来日し参加してくれます。Vaporの紹介や他のプログラミング言語に比べる優位性、Vaporの未来や、USやヨーロッパでの浸透状況について話していただきます。

3:50 AM

聞いてみたいけど東京じゃ無理だー。

参加！

昨日ポチったけど、完全にそこ見落としていたw

結局全然触らないまま「vaperが良さそうらしい」という雰囲気だけ受信してる・・・ｗ

2

同じく Kitura だけ触ったけどどうやら Vapor が良さそうらしいという（略 (edited)

昨日

4:00 AM

https://vapormeetuptokyo.connpass.com/event/77789/ で話した資料をupしました！ https://speakerdeck.com/noppoman/server-side-swift-falsege-ren-de-nali-yong-sin 興味ある人は御覧ください (edited)

6

vapor/mysqlにpublic varで宣言されてる定数っぽいのがたくさんあって困惑している https://github.com/vapor/mysql/blob/master/Sources/MySQL/Protocol/MySQLStatusFlags.swift 雑なだけなのか変更される可能性があるのか……

vapor/mysql

mysql -

Pure Swift MySQL client built on non-blocking, event-driven sockets.

雑なだけじゃないか・・・？

letになおすだけでもいいけどこのへんもOptionSetにしたくなってくる

個別にPR出してみたら。

こんなプロトコルがあるのに適合してるのが一種だけだったりする https://github.com/vapor/mysql/blob/master/Sources/MySQL/Protocol/MySQLFlags.swift

vapor/mysql

mysql -

Pure Swift MySQL client built on non-blocking, event-driven sockets.

9:47 AM

そうですね。そうしようかと思います

結局このパッケージってローレイヤでしかなくて

9:48 AM

Fluent / FluentMySQL を介してしか触らないから

9:49 AM

ユーザのコードにはあんまり影響無いしそんなに来にしてないんじゃないだろうか

自動生成なんじゃないかとみた

いやそれはおかしいです Configなんかはユーザーからも触るので

自動生成

あ〜ありえますね

＞自動生成だとすると勝手に変更してもまずいですかね・・・？

/// public var SERVER_MORE_RESULTS_EXISTS: MySQLStatusFlag = 0x0008 ^ この辺の空のドキュメンテーションコメントが自動生成っぽい。

mysqlはおそらくfluentMySQLから@_exported importされてる　調べてないですが

たぶん書き捨てのスクリプトとかで一発目を作ったとかじゃないかと思うんですよね。自動生成でメンテすることはおそらく考えてないとかじゃないかな。

9:50 AM

だからPRはむしろ歓迎じゃないかと。

その可能性はありそうですね。まぁ投げて反応見てみます。

これNOW()を使うのが間違ってる様に思える。 https://github.com/vapor/fluent/issues/464

Feature request: time zone support · Issue #464 · vapor/fluent

I want vapor to support time zone. Details are in below. Problem Database level debuggability Currently vapor supports to reading and writing Date value for database. But it is always encoded as GM...

MySQLでレコードの更新時刻とかをNOW()で埋めるのとかわりと普通じゃないですか？

3:18 AM

それが間違ってるとすると、MySQL自体のtimezone機能の存在自体がおかしいってことに。

UTC_TIMESTAMP()を使うべきでは。

それはtimezoneに関わらずUTCの時刻を返す関数ですね。 Vaporの現状によせつつクエリを書くならそうですね。

3:32 AM

やりたいことの前提が逆で、timezoneを使ってJSTの値でDBを使いたいのです。

3:33 AM

理由はDBを直接みたりするときにその方がわかりやすいから。

TIMESTAMPカラムではなくDATETIMEカラムなのか。

そうです。でも、その二つの違いを気にしてなかったです。

MySQL は、TIMESTAMP 値を、ストレージでは現在のタイムゾーンを UTC に変換し、取得では UTC から現在のタイムゾーンに戻します。(DATETIME などのほかの型ではこれは行われません。)

https://dev.mysql.com/doc/refman/5.6/ja/datetime.html

3:54 AM

TIMESTAMPだったら表示はオフセットされるのか。

3:55 AM

もしかしてTIMESTAMP型を使えばなにもかも解決する・・・？

サーバーのタイムゾーンをJSTにしたところでvaporがUTCのDateしか扱えないので問題はのこるのでは？コネクション毎にタイムゾーンを切り替えるとかならできるのかもしれないですが

そもそもSwift.DateはUTCですよね。

ですね

4:03 AM

SQLサーバーにはJSTのタイムスタンプが格納されていて、それをvaporの方法に則って取得すると9時間ずれた時刻になるのが現在の問題(の一つ)で、カラムをTImestampにしたところで結局swift側ではUTCで受け取りたいのでサーバー設定を上書きしてタイムゾーンをUTCにしてやらないとじゃないかと思います。サーバーのタイムゾーンをJSTにしておけばPHPMyAdmin等で見るTimeStampカラムは補正されてくれそうですが

@t.ae Swift.DateとMySQL.TIMESTAMPの間の変換(Vaporの実装における)はコネクションのtime zoneの影響を受けないんじゃない？ (edited)

そこはどうなってるか見てみないとわからないですね。サーバーのタイムゾーンをJSTに設定している場合、コネクションの最初にUTCに変更しないとJSTに補正された値が返ってくるんじゃないかと思ってるんですが

4:07 AM

＞コネクションの最初にUTCに変更ここをvaporがやってくれてるかどうか (edited)

TIMESTAMP型の振る舞いについては、SQLをコンソールからIOしたときのテキストベースの振る舞いの話と、Vaporが叩いてるMySQLのバイナリAPIの方で、同じ事がおきるのかどうかよくわかんなくって (edited)

4:09 AM

バイナリAPIでは内部のデータ表現がTIMESTAMP型の値としてそのままやってくるんだとしたら

4:10 AM

表現型での時差変換の話は関係なさそうだなと

https://github.com/vapor/mysql/blob/master/Sources/MySQL/Protocol/MySQLBinaryValue.swift#L57 https://github.com/vapor/mysql/blob/master/Sources/MySQL/Connection/MySQLData.swift#L492

vapor/mysql

mysql -

Pure Swift MySQL client built on non-blocking, event-driven sockets.

vapor/mysql

mysql -

Pure Swift MySQL client built on non-blocking, event-driven sockets.

4:39 AM

バイナリでもYMDHMSが分割されたフィールドセットとしてエンコードされるみたいだね

4:40 AM

TIMESTAMP型の時差変換が発生するなら、SQLサーバのtime zoneはUTCにしておいて、デバッグ用途で直接見るときにJSTでつなぐのが良さそう

4:41 AM

たしかにサーバー time zoneがJSTだった場合に、 MySQL.TIMESTAMPとSwift.Dateの間の変換は狂いそう。やってみないとわからんけど

サンプルコードを最小限にしたvapor3のテンプレートvapor-cleanに、docker-compseとHerokuの設定を追加したテンプレートを作った。 https://github.com/norio-nomura/vapor-clean

norio-nomura/vapor-clean

vapor-clean - A Vapor 3 template with no additional cruft.

KitsuraもSwift-NIO利用するように以降し始めている？ https://github.com/IBM-Swift/Kitura-NIO

IBM-Swift/Kitura-NIO

Kitura-NIO - A networking library for Kitura, based on SwiftNIO

おー、KituraはVaporと違ってFutureを表に出さない実装になってますね。

10:16 AM

互換性維持したままみたいだから当然か。 https://github.com/IBM-Swift/Kitura/compare/kitura-nio

IBM-Swift/Kitura

Kitura - A Swift web framework and HTTP server.

https://vapormeetuptokyo.connpass.com/event/88654/

Vapor Meetup 2nd (server-side swift) (2018/06/07 19:00〜)

## イベント概要 # VaporMeetupTokyo Swiftはバージョン3以降OSSとなり、LinuxやAndroidなどのAppleプラットフォーム以外での利用シーンも広がってきています。サーバサイドでSwiftを使うことも選択肢の一つになって...

6:54 AM

本日開催だけど、まだ20人くらい枠空いてます

発表します

4

Vaporユーザーは対応必要そうですね https://forums.swift.org/t/severe-swiftnio-security-vulnerability-affecting-swiftnio-1-8-0/14040

Severe SwiftNIO Security Vulnerability (affecting SwiftNIO < 1.8.0)

tl;dr swift package update Slightly longer version After an initial report from @Pushkar_N_Kulkarni (thank you!) we recently identified a severe security vulnerability in SwiftNIO's ByteBuffer code which was fixed in the following releases: 1.0.1, 1.1.1, 1.2.2, 1.3.2, 1.4.3,...

1

サーバー書いてたらこんなのにぶつかった…… https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/FileManager.swift#L585-L586

apple/swift-corelibs-foundation

swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence

ちょっとずれるけど、Carthageで rename システムコールをまず試してダメだったら FileManager.moveItem を試すというのをやったけど、corelibs-Foundationではそのケースが未実装なのかー。 https://github.com/Carthage/Carthage/pull/713 (edited)

Use NSFileManager.moveItemAtURL() as a fallback of rename() system...

Should fix #706 and #711. The manpage of rename() says: Both old and new must be of the same type (that is, both must be either directories or non-directories) and must reside on the same file sys...

6:59 AM

corelibs-Foundationの実装がまさに rename 使ってるのか（これはcontributionチャンス）

copyItemとremoveItem組み合わせるだけじゃ足りないんですかね？そのくらいならPR出せそうですけどいろんなケースを知らなすぎて適当なことできない感じが

SwiftPMでもこの辺は再実装されてるから参考になるかも？

私もあまり詳しくないですが、真っ先に思いつくのは copyItem と removeItem の間はちゃんと lock とらないと、copyItem と removeItem の間で古い item に書き込みが生じてしかも見かけ上成功してしまい、呼び出しがわで recovery できない的な問題が発生しそうですね

root@7214eacbf30e:/var/vapor# swift a.swift Fatal error: enumerateSubstrings(in:options:using:) is not yet implemented: file Foundation/NSString.swift, line 791 /usr/bin/swift[0x3f24d54] /usr/bin/swift[0x3f25096] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f5a99805390] /usr/lib/swift/linux/libswiftCore.so(+0x2baf79)[0x7f5a94a43f79] /usr/lib/swift/linux/libswiftCore.so(_T0s17_assertionFailures5NeverOs12StaticStringV_SSAE4fileSu4lines6UInt32V5flagstF+0x2c)[0x7f5a948d646c] /usr/lib/swift/linux/libFoundation.so(+0x501c3f)[0x7f5a8dac7c3f] /usr/lib/swift/linux/libFoundation.so(+0x501b0a)[0x7f5a8dac7b0a] /usr/lib/swift/linux/libFoundation.so(_T010Foundation8NSStringC14enumerateLinesyySS_SpyAA8ObjCBoolVGtcF+0x77)[0x7f5a8db559c7] /usr/lib/swift/linux/libFoundation.so(_T0s14StringProtocolP10FoundationSS5IndexVADRtzrlE14enumerateLinesyySS_Sbztc8invoking_tF+0xa0)[0x7f5a8db6bed0] [0x7f5a99c350c3] /usr/bin/swift[0xfed1ce] /usr/bin/swift[0xff1692] /usr/bin/swift[0x4d9076] /usr/bin/swift[0x4c35d3] /usr/bin/swift[0x4beecc] /usr/bin/swift[0x4778c4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f5a97f2f830] /usr/bin/swift[0x475179] Stack dump: 0. Program arguments: /usr/bin/swift -frontend -interpret a.swift -disable-objc-interop -color-diagnostics -module-name a Illegal instruction

(edited)

7:01 AM

root@7214eacbf30e:/var/vapor# swiftc a.swift root@7214eacbf30e:/var/vapor# ./a Fatal error: enumerateSubstrings(in:options:using:) is not yet implemented: file Foundation/NSString.swift, line 791 Illegal instruction

7:01 AM

NSUnimplemented を呼び出すコードを一度バイナリにコンパイルしてから実行するとスタックトレースが出ない

7:02 AM

Vapor Frameworkでこれに直面していて、ユーザコードで fatalError した場合はスタックトレースが出るが

7:02 AM

Foundationの NSUnimplemented でクラッシュするとスタックトレースが出ないのだけど

7:02 AM

理由や、どうすれば出るようになるか、わかる方いますか？

Linuxだとスタックトレースを出す仕組みが成果物に組み込まれていない。

11:18 AM

スタックトレースを出力するシグナルハンドラを自分で設定する必要がある。

11:19 AM

僕はその目的で https://github.com/norio-nomura/SwiftBacktrace を作りました。

norio-nomura/SwiftBacktrace

SwiftBacktrace - Stack traces for Swift on Mac and Linux using libunwind.

上の例で、swiftコマンドで直接実行した場合は出てくるのと、 swiftcでコンパイルしても、fatalError直接呼び出しなら出るのが、謎で。

11:20 AM

あ、シンボル名が出なくてアドレスしか出ない件については

11:20 AM

のむらさんのそれはチェックしました！

11:20 AM

謎なのは、アドレスだけのスタックトレースさえ、条件によって出ないことです

swiftコマンドだとswiftコマンドが設定したシグナルハンドラが受け取ってくれます。

11:21 AM

Linux版のswiftcで作成された成果物には、スタックトレースを出力するシグナルハンドラは設定されません。

ふむふむ。

macOSの場合、システムが用意したスタックトレースを出力するシグナルハンドラが使われているのだと思います。

Linuxでも、vapor buildしたバイナリで(内部的にはswiftPM) 自分で書いたfatalErrorなら出るんです

11:24 AM

Foundationの中で落ちた時だけでない。

自分で書いたfatalErrorなら出るんです

これ本当ですか？

ふむ。あとで確認できるものを用意してみます

11:27 AM

ありがとうございます

ああ、fatalError()はシグナル経由ではなくて、fatalError() > _assertionFailure() > _swift_stdlib_reportFatalError*() > swift_reportError() > reportNow() > printCurrentBacktrace() なのかな。

再現環境がもうちょっとでできそうです。

(docker周りのミスでimage構築をやりなおしが複数回発生していて時間がかかってます

再現環境は明日見ますね。

あい。

とりあえず今確認した範囲では、fatalError()をユーザーコードで呼び出した場合は https://github.com/apple/swift/blob/master/stdlib/public/runtime/Errors.cpp#L275 のprintCurrentBacktrace()が呼ばれ、NSUnimplemented()経由だとprintCurrentBacktrace()は呼ばれずシグナルハンドラの挙動に依存する、という違いがあると知りました。

apple/swift

swift - The Swift Programming Language

できた https://github.com/omochi/linux-swift-stacktrace

omochi/linux-swift-stacktrace

Contribute to linux-swift-stacktrace development by creating an account on Github.

1:32 PM

なるほど、fatalErrorのコール内部でシグナル飛ばす前に直接スタックトレースを出す処理があって、それがコンパイル条件で異なるんですね。

1:32 PM

うーんまさにそれっぽい。

1:34 PM

ということは、シグナルハンドラ + norioさんの libunwindラッパーを導入するのが安牌っぽいですが、逆に二回出ちゃう事になるんだろうか

-assert-configでコントロールできそうにも見える。

 -assert-config <value> Specify the assert_configuration replacement. Possible values are Debug, Release, Unchecked, DisableReplacement.

(edited)

@swift-4.1.3 -assert-config Release fatalError()

exit status: 4 with stderr:

Fatal error: file <stdin>, line 1 #0 0x0000000003f25074 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x3f25074) #1 0x0000000003f253b6 SignalHandler(int) (/usr/bin/swift+0x3f253b6) #2 0x00007f662e570390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x00007f6629e5a0b9 _T0s17_assertionFailures5NeverOs12StaticStringV_SSAE4fileSu4lines6UInt32V5flagstFTf4nxnnn_n (/usr/lib/swift/linux/libswiftCore.so+0x2bb0b9) #4 0x00007f6629cec41c _T0s17_assertionFailures5NeverOs12StaticStringV_SSAE4fileSu4lines6UInt32V5flagstF (/usr/lib/swift/linux/libswiftCore.so+0x14d41c) #5 0x00007f662e9a006e #6 0x0000000000fed3be llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) (/usr/bin/swift+0xfed3be) #7 0x0000000000ff1882 llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, char const* const*) (/usr/bin/swift+0xff1882) #8 0x00000000004d9076 swift::RunImmediately(swift::CompilerInstance&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, swift::IRGenOptions&, swift::SILOptions const&) (/usr/bin/swift+0x4d9076) #9 0x00000000004c35d3 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) (/usr/bin/swift+0x4c35d3) #10 0x00000000004beecc swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) (/usr/bin/swift+0x4beecc) #11 0x00000000004778c4 main (/usr/bin/swift+0x4778c4) #12 0x00007f662cc9a830 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20830) #13 0x0000000000475179 _start (/usr/bin/swift+0x475179) Stack dump: 0. P

stderr.txt

https://file.io/69QVh0

@swift-4.1.3 -assert-config Debug fatalError()

exit status: 4 with stderr:

Fatal error: file <stdin>, line 1 Current stack trace: 0 libswiftCore.so 0x00007f18b22e0680 _swift_stdlib_reportFatalErrorInFile + 221 1 libswiftCore.so 0x00007f18b204f38c <unavailable> + 1368972 2 libswiftCore.so 0x00007f18b22892f2 <unavailable> + 3703538 3 libswiftCore.so 0x00007f18b228a759 <unavailable> + 3708761 4 libswiftCore.so 0x00007f18b204ea86 <unavailable> + 1366662 5 libswiftCore.so 0x00007f18b22890bb <unavailable> + 3702971 6 libswiftCore.so 0x00007f18b204ea86 <unavailable> + 1366662 7 libswiftCore.so 0x00007f18b21bc0b9 <unavailable> + 2863289 8 libswiftCore.so 0x00007f18b204e3f0 _assertionFailure(_:_:file:line:flags:) + 44 10 swift 0x0000000000fed3be <unavailable> + 12506046 11 swift 0x0000000000ff1882 <unavailable> + 12523650 12 swift 0x00000000004d9076 <unavailable> + 888950 13 swift 0x00000000004c35d3 <unavailable> + 800211 14 swift 0x00000000004beecc <unavailable> + 782028 15 swift 0x00000000004778c4 <unavailable> + 489668 16 libc.so.6 0x00007f18b4ffc740 __libc_start_main + 240 17 swift 0x0000000000475179 <unavailable> + 479609 #0 0x0000000003f25074 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x3f25074) #1 0x0000000003f253b6 SignalHandler(int) (/usr/bin/swift+0x3f253b6) #2 0x00007f18b68d2390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x00007f18b21bc0b9 _T0s17_assertionFailures5NeverOs12StaticStringV_SSAE4fileSu4lines6UInt32V5flagstFTf4nxnnn_n (/usr/lib/swift/linux/libswiftCore.so+0x2bb0b9) #4 0x00007f18b204e41c _T0s17_assertionFailures5NeverOs12StaticStr

stderr.txt

https://file.io/KDScou

-assert-config ReleaseでprintCurrentBacktrace()は呼ばれなくなる。

ほほーそんなものが

@usableFromInline @_transparent internal func _fatalErrorFlags() -> UInt32 { // The current flags are: // (1 << 0): Report backtrace on fatal error #if os(iOS) || os(tvOS) || os(watchOS) return 0 #else return _isDebugAssertConfiguration() ? 1 : 0 #endif }

(edited)

3:07 AM

なるほどなるほど

3:09 AM

assert-config Releaseだと他のassertion関係も変化が生じてしまいそうなので採用は見送ろうと思いますがいろいろなことがわかりました

lldbのリモートデバッグ機能を使って、LinuxのプロセスをMacからデバッグしようとしているのですがうまくいきません・・・

3:29 AM

Linuxのホスト内で、 lldb-server と lldb を使って、自分で自分にリモートデバッグ接続をして、 attach することはできました

3:30 AM

Linux上のlldb-server に Mac のlldbから接続して、 platform connect には成功しているのですが

3:30 AM

(lldb) attach 572 error: attach failed: Failed to connect port

3:30 AM

アタッチするところで失敗していまいます

3:31 AM

バージョンはどちらも4.1.0 releaseを使っていて

3:31 AM

// Linux root@031ab2443e1a:/var/vapor# lldb-server v lldb version 5.0.0 (git@github.com:apple/swift-lldb.git revision 76dfa56ed35eaa392f7e51088c08f08f1150d142) Swift-4.1 (revision f01501c324876fc07820dc28923d7088fb7af847) clang revision cd84be6c4294f9ec302c20c63a601cbaeaa6a017 llvm revision cf364153438b3ac07a4a7d721159936e439ba2e7

(edited)

3:31 AM

[omochi@omochi-iMac-PC43 ~]$ lldb --version lldb-360.0.0 (buildbot 2018-03-29) Swift-4.1 (revision f01501c324876fc07820dc28923d7088fb7af847) clang revision cd84be6c4294f9ec302c20c63a601cbaeaa6a017 llvm revision cf364153438b3ac07a4a7d721159936e439ba2e7

3:32 AM

このlldb自体のバージョン表記が異なっているのがちょっと気になっていますが依存パッケージ3つはリビジョンも一致しているしあってそう

3:36 AM

それともattachするときにlldb sv/cl通信とは別のポートを使うのでしょうか？

Ubuntu16.04の4.1 releaseをDLしてみたけどやはり上記の表示でした

https://stackoverflow.com/questions/51888521/lldb-remote-debug-for-server-side-swift-is-failed-between-linux-in-docker-and-ma

LLDB remote debug for server side Swift is failed between Linux in...

I am trying to remote debug server side swift from macOS. lldb-server run on Ubuntu 16.04 on Docker on macOS. I am using swift-4.1-RELEASE binaries. root@031ab2443e1a:/var/vapor# lldb-server vers...

4:48 AM

スタックオーバーフロー書き込んだ・・・

@omochimetaru なんかコードブロックがおかしくなってる。 (edited)

これマークダウンじゃないのかな

4:57 AM

あ、わかった、なんかちがうっぽい

4:58 AM

できた。 @koher どうもです。

1

lldb-server試した。

11:06 AM

docker-compose.ymlにprivileged: trueを追加。

11:06 AM

lldb-server起動オプションに--min-gdbserver-port 31167 --max-gdbserver-port 31266を追加。

11:07 AM

docker-compose.ymlのportsに- "31166-31266:31166-31266"を追加。

11:07 AM

それでいけた。

マジですか！

linux-swift-stacktraceに https://github.com/omochi/linux-swift-stacktrace/compare/master...norio-nomura:use-lldb-server の変更を加え、

docker exec -it vapor lldb-server platform --listen "*:31166" --server --min-gdbserver-port 31167 --max-gdbserver-port 31266

でlldb-serverを起動。

omochi/linux-swift-stacktrace

Contribute to linux-swift-stacktrace development by creating an account on Github.

gdbプロコトルのほうで使うポートがあったんですね

11:30 AM

ありがとうございます、あとでよく見てみます

$ xcrun lldb (lldb) platform select remote-linux Platform: remote-linux Connected: no (lldb) platform connect connect://172.16.241.138:31166 Platform: remote-linux Triple: x86_64-*-linux-gnu OS Version: 4.9.93 (4.9.93-boot2docker) Kernel: #1 SMP Thu Jul 19 18:29:50 UTC 2018 Hostname: 88958a83a317 Connected: yes WorkingDir: /var/vapor (lldb) platform process list 4 matching processes were found on "remote-linux" PID PARENT USER TRIPLE NAME ====== ====== ========== ======================== ============================ 1 0 (null) x86_64-*-linux dash 338 1 x86_64-*-linux vapor 563 338 x86_64-*-linux Run 568 0 x86_64-*-linux lldb-server (lldb) platform process attach --pid 563 Process 563 stopped * thread #1, name = 'Run', stop reason = signal SIGSTOP frame #0: 0x00007f8f41cfe360 libpthread.so.0`__pthread_cond_wait + 192 libpthread.so.0`__pthread_cond_wait: -> 0x7f8f41cfe360 <+192>: movl (%rsp), %edi 0x7f8f41cfe363 <+195>: callq 0x7f8f41d011c0 ; __pthread_disable_asynccancel 0x7f8f41cfe368 <+200>: movq 0x8(%rsp), %rdi 0x7f8f41cfe36d <+205>: movl $0x1, %esi thread #2, name = 'Run', stop reason = signal SIGSTOP frame #0: 0x00007f8f41d00827 libpthread.so.0`do_futex_wait.constprop.3 + 55 …

(edited)

11:35 AM

僕はdocker-machineを使ってるので、macOSのlldbからの接続先が127.0.0.1ではないのが違うくらいかな。

@norio_nomura ありがとうございます、いけました。ドキュメントは見つけられなかったですが、与えたリストから一つ使うみたいでした。 https://github.com/apple/swift-lldb/blob/a5cac96cb2861b5b818cc280911180a0329f1205/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp#L482 本番構成のほうでは、Dockerホストマシンがクラウドにあるのですが、sshポートフォワードを介して、Dockerコンテナ内のlldb-serverと手元のMacのlldbを接続できました。

apple/swift-lldb

swift-lldb - This is the version of LLDB that supports the Swift programming language & REPL.

1

7:23 AM

エラーメッセージでググってたとき、 --min-gdbserver-port を指定してるコマンドラインは見かけていたのですが、それについて調べても情報が出てこなかったのでスルーしていました。gdbの互換モードみたいな特殊な使い方があるのかな？みたいな。

vaporのwebsocket-clientがプロトコルアップグレードの処理でバグってる件、パッチを提出しておいたんだけど、タナーさんから返事がついてて別のアプローチ検討してるとのことアップグレードするときに、「普段はバッファリングするだけ、外すときに中身を吐き出す」ハンドラをくっつける方式らしい。 https://github.com/vapor/nio-websocket-client/pull/4

Buffer early stream by omochi · Pull Request #4 · vapor/nio-webs...

I retry #3 This PR resolves #1. Original implementation have this steps. add out WebSocketFrameEncoder add in WebSocketFrameDecoder remove inout WebSocketClientUpgradeHandler upgradePipelineHandler...

2

IBMがSwiftへのcontributionを止めるらしい。 https://forums.swift.org/t/december-12th-2019/31735 (edited)

December 12th, 2019

IBM update @IanPartridge and @Chris_Bailey let the group know that following a review by IBM of its open source priorities, it has been decided that they will not be continuing to work on Swift in 2020. As a result, they are both standing down from the workgroup. @IanPartrid...

8

あら・・・

残念だ

https://swift.org/blog/aws-lambda-runtime/

3

Lambda!

7:14 PM

サーバーレスSwiftだ

サーバーレス...

Lambda使うところだけPythonになっちゃうの嫌だったから助かる

AWSにロックイン

AWSｷﾀｰ

う、最近 GCP に寄せてたのに・・・

Vaporは非力なマシンでdocker buildするとコンパイルが終わんないっすね。ビルド済みのイメージを転送するかPullするようにしたらいいけど、絶賛開発中みたいなときは面倒だな。

なにがそんなに遅いんですかね

全体的にビルドが数倍遅くなるんですけど、だいたいCファイルをコンパイルしようとするところですごく遅くなって、進まなくなることもありますね。

7:40 PM

メモリをすごい使ってて、スワップがすごく多くなるのかな。

~~Swift 5.3はビルドがめちゃめちゃ遅いです。5.2でビルドできるコードなら、そっちを使った方が良い。~~ (edited)

なんと。5.3が理由だったのか。ローカルだと速いのであとでGCE＋Dockerの環境で試してみます。

へえ、なんでだろ。

過去にビルド時のメモリ消費が増えたときには、アロケーションエラーで止まるようになったのですが、今回はswift-atomicsとかでタイムアウトになる。

そっすねえ。swift-atomicsのCファイルをビルドするのめっちゃ遅いです。非力なマシンだと。

5.2だと普通にビルドできます。

9:57 PM

あ、コンパイルエラーが出て早く終わってただけかも？ちゃんと確認してないや。

5.2で使えないエクステンションの書き方とかを修正したけど、clangの機能が足りなくてビルドを諦めたんだったかな？

「Swift 5.3はビルドが遅い」というのは撤回します。

5.3が遅いのではなくOSS Toolchainが遅いのかも。macOSでも、Xcode添付版に比べてOSS Toolchainはビルドが遅い。

メモリとマシンパワーがあればDockerビルドでも十分な速さっぽいですけどね。

swift-atomicsをswift build --build-testsすると、Xcode 12.01.1版は2分14秒、swift-5.3 OSS ToolchainのmacOS版は8分43秒かかった。 (edited)

４倍遅いんすね。

Xcode 11.7版は2分6秒、swift-5.2.5 OSS ToolchainのmacOS版は6分51秒だった。 (edited)

OSS版はアサーション付いてたりするんですかね

実行ファイルサイズはOSS版がかなり大きい。

$ du -m $(DEVELOPER_DIR=/Applications/Xcode_11.7.app xcrun --find swift) $(xcrun --toolchain org.swift.525202008051a --find swift) $(xcrun --find swift) $(xcrun --toolchain org.swift.530202009161a --find swift) 39 /Applications/Xcode_11.7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift 162 /Library/Developer/Toolchains/swift-5.2.5-RELEASE.xctoolchain/usr/bin/swift 97 /Applications/Xcode_12.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift 179 /Library/Developer/Toolchains/swift-5.3-RELEASE.xctoolchain/usr/bin/swift

(edited)

--preset="buildbot_osx_package"だからアサーションついてるぽい。 https://ci.swift.org/view/Swift%205.3/job/oss-swift-5.3-package-osx/

[preset: buildbot_osx_package] mixin-preset= mixin_osx_package_base mixin_osx_package_test mixin_lightweight_assertions,no-stdlib-asserts … # A mixin that enables 'lightweight' assertions that don't slow down the # compiler significantly. [preset: mixin_lightweight_assertions] assertions

https://github.com/apple/swift/blob/main/utils/build-presets.ini#L1306-L1310

apple/swift

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

12:50 AM

ubuntu版も同様にmixin_lightweight_assertionsが使われてる。 (edited)

12:55 AM

mixin_lightweight_assertionsのコメント、4倍遅いのはsignificantlyではないということなのか…

# A mixin that enables 'lightweight' assertions that don't slow down the # compiler significantly.

SwiftWasmのツールチェーンもこの間アサーション切ったら2倍くらいstdlibが速くなったのでもしやと思ったらビンゴだった

https://github.com/swiftwasm/JavaScriptKit/pull/91#issuecomment-703029881

Remove all unsafe linker flags from Package.swift by kateinoigakuku...

Need toolchain including swiftwasm/llvm-project@20c933e Resolve #6

OSS版でswift-atomicsのビルドが4倍遅いのはエッジケースですね。SwiftLintとかはXcode版のビルド時間がswift-atomicsとそれほど変わらないけど、OSS版は1.5倍未満のビルド時間に収まってる。

VaporのLeafというテンプレートエンジンはJSが壊れるような気がするけど気のせいかな。ドキュメントが古いものしかなくてよくわからない。

テキスト処理なんで特にJSが壊れるとかはない気がする

テンプレート内にJS書いてますけど特に壊れるとかはないですね。 id指定のところの#がエスケープ要るくらい

index.htmlをindex.leafにしただけで動かなくなったんですよね。

3のころはブレースで色々埋め込んでたんでJSと相性悪かった記憶ありますが4ではブレース不要になったので特に問題を感じていません。

2:44 AM

動かなくなったってエラーですか？

もうちょっとちゃんと調べてみます。

2:47 AM

Leafにしただけで Uncaught TypeError: Cannot read property 'getChildren' of undefined JSがTypeErrorになったのでLeafがなんかおかしいのかな、、と思ったのですが、、、

2:49 AM

ちょっとデバッグしてみたのですが、よくわからないですね。ソースを壊しているということはなさそう。

2:49 AM

JSもある程度までは動いている。

4で自分が問題あったこととしては、ID指定する#がleafでも使われるのでエスケープが必要なことくらいですかね。 (edited)

どっちにエスケープが必要なんですか？テンプレート（index.leaf）の方ですか？

どっちにというと？jsのソースは別れてるんでしょうか。

Index.leafに書かれています。 <script></script>タグで。

index.leafの中にdocument.querySelector("#some-id") とかがあるなら、この#に\を付ける必要があります。

えー、、、

ｗ

＄('#loading') のがいっぱいあるんですけど、それにエスケープをしていく必要があるんですね。。。

そうですね。残念ながら。

えー、それはテンプレート文字列を#(title)にした設計の問題じゃないの。。。

ファイルを分離して <script src> にするのが楽そう。

それで解決するかなあ。#idっていうのは普通にいくらでも出てくるし。。。

2:56 AM

とりあえずやってみます。

2:58 AM

#idじゃないですけどカラーコード #FAFAFA はそのままでOKですか？

カラーコード埋めたことはないですが＃始まりのは全部エスケープ要ると思います……カスタムタグとかあるので

CSSファイルを分離して class="..." にしてカラーコードはHTMLに埋め込まないのが楽そう・・・ｗ

もしくはrgb(r, g, b)

<li class="nav-item" style="width: 140px;"> <a href="#tab1" class="nav-link py-1 active" data-toggle="tab"> <h6 style="font-size: large;"><i class="far fa-folder-tree"></i> Structure</h6> </a> </li> <li class="nav-item" style="width: 140px;"> <a href="#tab2" class="nav-link py-1" data-toggle="tab"> <h6 style="font-size: large;"><i class="fal fa-file-code"></i> Syntax</h6> </a> </li>

^ Bootstrapでこういうタブを作る指定があるんですけどこれもダメでしたね。

URL fragmentか。

3:00 AM

それはファイル分離できないな。

#tab1 のところ。leaf作った人なんで#(title)を選んじゃったの。

1

こうなるとSSRするよりもクライアントサイドでバインドしたほうが楽そう…

Leaf3のときにテンプレート変数と別テンプレートのincludeに関してスコープが無いのがヤバいと思ったけど

3:02 AM

Leaf4も同じ？

今は埋め込みの際にexport/importで指定できますけど、スコープはどうだろう。調べてないです。

ふむ

3:04 AM

サーバーサイドで適当に Swift の """ 文字列で書いたほうが楽そう。

たしかに

\( ) で変数埋め込みすればほぼ衝突しないだろうし、

動いたと思う。とにかく全部の#を\#に変える必要がある。 (edited)

関数定義したら部品化もできる。

3:05 AM

あ、分岐とか繰り返しができないから FunctionBuilder 書いたほうが良いかもな。

3:05 AM

とにかく全部の#を#に変える必要がある。

その工程に取り漏らしのミスが無いことを機械的に保証できないんでかなりきつそうです。

漏れたら中途半端に動くからねえ。

JSなら動かなくてわかりますけど色とかは気付きにくいかもですね。

まあJSだけ、じゃなくて全部の#を\#だからまだマシ (edited)

3:07 AM

ちなみにHTMLやCSSをSwift側で書くのはしんどいと思う。ホットリロードとかあったらいいけど。

ああ、たしかに。そこは面倒かも。

VaporはRoutingをRegexで書くのは無理ですか？ app.get(/^\/([a-f0-9]{32})$/i, async (req, res) => { ^ Node.jsでいうこういうのを書きたいのですが、ちょっと調べた限り無理そう。

https://docs.vapor.codes/4.0/routing/#parameter

Vapor: Basics → Routing

Vapor 4's documentation (web framework for Swift).

3:20 AM

パラメータがただのプレースホルダしかないからできなそう。

1

Vaporはまだまだパッチを送る余地がありそうだ。 (edited)

Swiftでテンプレートが書けるとパフォーマンスも良さそうというのはある。軽量なプレビューがあったらいけるかも。

5:13 AM

別プロセスかなんかで動いてホットリロード的なことができたり。

ビルドしたバイナリから型情報を洗い出して

6:11 AM

テンプレート型を抽出して、依存してる値をなんとか埋めて・・・

6:11 AM

SwiftUI Preview みたいに Preview用の型とか関数を書くぐらいはやってもいいか。

期待

いや、僕はやらないですよ、Leaf見捨ててるんで

www

Vaporは支持してるけどLeafだけは要らない

いやSwiftでテンプレートを書くってことはLeafは当然使わないでしょ。

あ、そっちの話か

テキストで取り込んで置換して、ってパフォーマンスも上がらないと思うんですよね。

ごっちゃになってた。

Leafってさらにループとか書けるんでしょ。最初からSwiftになってるならそれがベスト。 (edited)

ですね。＞ループとか

erbとrubyみたいにホスト言語とテンプレート内で使える言語が一致していると嬉しい

そんな感じ。

ただResult BuilderみたいなDSLで書くとHTMLとしての可搬性が無くなる。。。

レンダリングすればHTMLになるよ

6:37 AM

どうせ制御部分には可搬性がないのだから。

HTMLスニペットを適当なところからコピペするときコンバータが必要じゃないですか

HTML→テンプレートのところは機械変換できる

6:37 AM

コンバータあれば良い

6:38 AM

admin-lteってやつ使ったんだけど

6:38 AM

JSXでほんのちょっと違ってコピペするとぶっ壊れて

コンバータがあれば良い理論だとJSX必要なくないですか？

はい

6:38 AM

JSX意味ないと思います

6:38 AM

どうせコピペできないんだもん

あれ、そうなんだ

6:38 AM

classNameとかか

class が className とか

6:38 AM

forがhtmlForとか

6:39 AM

HTMLでは通った <input> が <input /> じゃないとだめとか

6:39 AM

styleも文字列じゃなくてオブジェクトだし・・・

6:39 AM

ちまちまいろいろとあるんすよ。結局全行に手入れした。

6:39 AM

だから HTML → JSX も機械処理すべきだなという考えになり

6:39 AM

それならJSXじゃなくていいやと今思ってる

ふむーなるほど

JSXは開発環境も込みで用意されてるんじゃないんですか？

あるのかな？僕が見落とした可能性はありますね。

私もよく知らない。。。

vscodeがtsxを認識してくれる以上のツーリングはやってないです。

JSX作るくらいならそこまでやりそう、、、みたいな。

https://magic.reactjs.net/htmltojsx.htm

HTML to JSX

6:41 AM

あった

お、続きはこれ使お。 (edited)

6:42 AM

ああ、そうそう、コメント文もだめなんよな

これならHTML to ReactElementにしてくれても。。。

JSXは、見た目がHTMLっぽいからとっつきやすいとかはありそう。

6:43 AM

でも僕はHTMLの方に軸足無いから

6:43 AM

別にいいんだよね。

6:44 AM

閉じタグとかいらんと思うし・・・

見た目を優先した結果TypeScriptで使うためにJSXとはまた別のTSXが必要になっている

app.get("*") { req -> EventLoopFuture<EventLoopFuture<View>> in let pattern = try! NSRegularExpression(pattern: #"^\/([a-f0-9]{32})$"#, options: [.caseInsensitive]) let matches = pattern.matches(in: req.url.path, options: [], range: NSRange(location: 0, length: NSString(string: req.url.path).length)) guard matches.count == 1 && matches[0].numberOfRanges == 2 else { throw Abort(.notFound) } let gistId = NSString(string: req.url.path).substring(with: matches[0].range(at: 1)) let promise = req.eventLoop.makePromise(of: EventLoopFuture<View>.self) let session = URLSession(configuration: .default) let request = URLRequest(url: URL(string: "https://api.github.com/gists/\(gistId)")!) session.dataTask(with: request) { (data, response, error) in if let error = error { promise.fail(error) return } guard let data = data else { promise.fail(Abort(.notFound)) return } guard let contents = try? JSONSerialization.jsonObject(with: data, options: []) as? [String: Any], let files = contents["files"] as? [String: Any], let filename = files.keys.first, let file = files[filename] as? [String: Any], let content = file["content"] as? String else { promise.fail(Abort(.notFound)) return } promise.succeed( req.view.render( "index", [ "title": "Swift AST Explorer", "defaultSampleCode": content, "swiftVersion": swiftVersion, ] ) ) } .resume() return promise.futureResult }

VaporでAsyncでビューを返すのってこれであってます？動いてるんですけど EventLoopFuture<EventLoopFuture<View>> となってるところがホントに合ってるのかな？と。

EventLoopFuture<View> じゃないですかね？コンパイル通りますか？

6:48 AM

// ここをこうして let promise = req.eventLoop.makePromise(of: View.self) // ここをこう req.view.render( "index", [ "title": "Swift AST Explorer", "defaultSampleCode": content, "swiftVersion": swiftVersion, ] ).cascase(to: promise)

(edited)

promise.succeed() <= ここにViewを渡せないなと思ってたんですけど、 .cascase(to: promise) っていうのがあるんですね！

はい、なんかそういう風に困ってるのかなとコードから推測しました。

6:50 AM

https://apple.github.io/swift-nio/docs/current/NIO/Classes/EventLoopFuture.html#/s:3NIO15EventLoopFutureC7cascade2toyAA0bC7PromiseVyxGSg_tF

バッチリでした。ありがとうございます

1

https://apple.github.io/swift-nio/docs/current/NIO/Structs/EventLoopPromise.html#/s:3NIO16EventLoopPromiseV12completeWithyyAA0bC6FutureCyxGF

6:51 AM

Promise.completeWith(Future) ともかけるし

6:51 AM

Future.always { result in Promise.completeWith(result) }

6:51 AM

ともかけますが、ここはcascadeが一番オシャレかな。

なるほど。Promiseをちゃんと勉強しないとわからんな。

PromiseはMutableFuture的なものですね

6:56 AM

readonly Promise が Future とも言える。

Vaporに関してはEventLoopFutureのAPIを一通り眺めたらいけそう。 VaprotはちょっとGetting Started以降のドキュメントが少ないよね。

Leafなんか4のドキュメント無いですからね。やりたいことあったらテストコード読んでできないか確認したりしてます。

Leafないよね。READMEにも何も書いてないし。

7:18 AM

Vapor勉強会必要だわ

昔一回行きましたけど結局その後無いのかな？

Vapor Meetupってのがあったのかな

7:20 AM

URLSessionってLinuxにはないんでしたっけ？

7:21 AM

そういえばなかった気がする。

7:21 AM

Curlとか呼ばないとあかんのか。

import FoundationNetworkingすると使えませんでしたっけ？ (edited)

あ、FoundationNetworkingってそれが入ってるのか。

vaporからHTTP叩くだけなら request.client がありますよ。

おお、ありがとうございます。

7:24 AM

/build/Sources/App/routes.swift:31:23: error: 'URLSession' is unavailable: This type has moved to the FoundationNetworking module. Import that module to use it. let session = URLSession(configuration: .default) ^~~~~~~~~~ Foundation.URLSession:2:18: note: 'URLSession' has been explicitly marked unavailable here public typealias URLSession = AnyObject

確かにFoundationNetworkingに移ったって書いてありましたわ。

Vaporでカスタムの404ページを返したい、場合はミドルウェアを使うのでしょうか？

7:37 AM

標準でサポートされてない？

たぶん。

7:39 AM

https://docs.vapor.codes/4.0/errors/#error-middleware

Vapor: Basics → Errors

Vapor 4's documentation (web framework for Swift).

うーむ。Statusコードをセットしつつ、view.renderできたらいいのに。。。

 return Response( status: .ok, headers: ["Content-Type": "text/html; charset=UTF-8"], body: Response.Body(string: html) )

7:41 AM

View 型だとどうなってるんだろうな。

7:42 AM

public struct View: ResponseEncodable { public var data: ByteBuffer public init(data: ByteBuffer) { self.data = data } public func encodeResponse(for request: Request) -> EventLoopFuture<Response> { let response = Response() response.headers.contentType = .html response.body = .init(buffer: self.data) return request.eventLoop.makeSucceededFuture(response) } }

7:43 AM

うーむ。できなさそう。

7:43 AM

一度 view.encodeResponseしてから、 Response型の statusプロパティだけ書き換えるとかになりますね。

7:44 AM

return view.encodeResponse(for: request).map { (response) in var response = response response.status = .notFound return response }

なるほど。そういうことができるんですね。viewをレスポンスオブジェクトにして、ステータスコードを書き換える。

 @discardableResult public func get<Response>( _ path: PathComponent..., use closure: @escaping (Request) throws -> Response ) -> Route where Response: ResponseEncodable { return self.on(.GET, path, use: closure) }

7:47 AM

routesの登録はジェネリックになってて、 ResponseEncodable な値を返す関数ならなんでもいいんですよね。

7:47 AM

String　とかView が ResponseEncodable ですけど、 Response型に erase してしまうと一番自由度が高い。

7:48 AM

(このコードの Response は型パラメータ名だけど、同じ名前の　Response 型もある )

今の問題を解決したらやってみます。（まだちゃんと動いてないけどエラーが生のJSONで返ってくるのがめっちゃ気になっていた）

ああ。なりますね。さっきのところに書いてある、デフォルトで仕込まれてるErrorMiddlewareさんがその変換をしている。

7:50 AM

ErrorMiddleware is the only middleware added to your application by default. This middleware converts Swift errors that have been thrown or returned by your route handlers into HTTP responses. Without this middleware, errors thrown will result in the connection being closed without a response.

他のエラーのことも考えるとミドルウェアを挟んだ方がいいのかな？

7:52 AM

といっても404と500だけ、になると思うけど。

他のエラーってどういうのですか？

7:53 AM

カスタムしたいなら自前のミドルウェアに置き換えるのが良いとは思います。

7:54 AM

ただ、ページの中で生じるエラー、例えば、「メールアドレスが入力されていません」とかは

7:54 AM

そのページ内のロジックとして扱う必要があるので

7:54 AM

この手の例外で吹っ飛んで落ちるレベルのエラーとは別ですよね。

7:55 AM

個人的にはこのレベルのエラーは既に正常系じゃないのでなんでもいいんじゃないかと思いますけど、

7:55 AM

なんかウェブサービスって洒落た404ページ出すとかよくありますね。

404と500っす。

URL間違えてて404はよく出るか。

とりあえずこの２つについてちゃんとした見た目のViewを出したい。

それならmiddleware作るですね

で、404返しつつ、静的なHTMLを返すっていうのが簡単なんですけど、

7:57 AM

やっぱりミドルウェアですかね。

struct CSRFProtection { struct Key: StorageKey { typealias Value = CSRFProtection } struct Post: Decodable { var csrfToken: UUID? } let sessionKey = "csrfToken" struct Middleware: Vapor.Middleware { func respond(to request: Request, chainingTo next: Responder) -> EventLoopFuture<Response> { let eventLoop = request.eventLoop guard request.method == .POST else { return next.respond(to: request) } let verify = eventLoop.future { try request.verifyCSRFToken() } return verify.flatMap { () in next.respond(to: request) } } } var middleware: Middleware { Middleware() } }

7:58 AM

結構簡単ですよ。 respond (to:, chainingTo) メソッドを実装するだけなので。

7:58 AM

↑は自作のCSRF脆弱性対策くん

なるほど。Expressと同じ感じだ。

7:58 AM

助かります。

あ、このコードの場合は、事前検査してエラー投げてるだけだから前処理ですけど

7:59 AM

今の話の場合はエラーを変換するから後続処理になるので

8:00 AM

next.respond(to: request).flatMapError{ (error) in ... switch error { // errorの型をがんばって404と500を振り分ける case ... }

(edited)

8:00 AM

って感じのコードになりますね。

うーむ、そこで振り分けるのできるかな。

8:03 AM

そもそも http://localhost:8080/b4f866efb1c1dc63b0a9cce000cf5688 こういうPathを受けるために /* で受けてると難しい気がするな。

マッチしなかった時に特定のエラーを投げておけば、ミドルウェアでそれを捕まえられる。

App側はAbort(.notFound)かAbort(.internalServerError)しておけばいい？

notFoundは404にして

8:06 AM

ほかの例外は全部500でも良さそう。

8:06 AM

デフォルトだとroutesが無かったら↓が飛んでるらしい

struct RouteNotFound: Error { } extension RouteNotFound: AbortError { static var typeIdentifier: String { "Abort" } var status: HTTPResponseStatus { .notFound } }

8:08 AM

AbortErrorはprotocolになっててstatusをもってるから

8:09 AM

例外をAbortErrorにキャストしてstatusを調べて404かその他か決められそう。

どうもどうも。とりあえず正常系は動きました。 https://swift-ast-explorer.com/ ミドルウェアやってみます。

Swift AST Explorer

Swift AST Explorer - AST visualizer for Swift source code

8:10 AM

^ ピュアSwiftのWebサービスになりました。

おおｗ

macOSとLinuxの微妙な違い、は開発が進んでくるとつまずかなくなるのかな？ずっとDockerで開発すれば起こらないけどそれは結構しんどいしな。

僕はまだmacでずっとやっててなんとも。(まだ開発初期なのでLinuxに展開してない) @t.ae どうすかね (edited)

困ったことはあんまりないですね。

8:16 AM

Vaporじゃないですけど、macとlinuxでdependencyが違うパッケージがあったりして、毎回dirtyになるのがちょっと気になるくらい？

毎回dirtyになる

これはbuild directoryをmountしてるからだよね

そうですね。純粋にdocker内でやる場合は外からは見えないので問題ない？

final class ErrorMiddleware: Middleware { func respond(to request: Request, chainingTo next: Responder) -> EventLoopFuture<Response> { return next.respond(to: request).flatMapError { (error) in let headers: HTTPHeaders let status: HTTPResponseStatus let reason: String let title: String switch error { case let abort as AbortError: headers = abort.headers status = abort.status title = "Not Found" reason = status == .notFound ? "Sorry, an error has occured, Requested page not found!" : abort.reason default: headers = [:] status = .internalServerError title = "Internal Server Error" reason = "Something went wrong." } return request.view.render("error", [ "title": title, "status": "\(status.code)", "reason": reason, ]) .encodeResponse(status: status, headers: headers, for: request) } } }

ミドルウェアはとりあえずこんな感じにしました。

7:32 PM

error.leaf っていうテンプレートがあって、タイトルとかが変わります。

7:33 PM

だんだんわかってきた。Vaporと結構格闘したからある程度スイスイかけるようになった、、、かもしれない。 (edited)

よさそう

もうちょっとシンプルになりそうだけど

AbortErrorならステータスコードはそのまま通してそれ以外の例外は500ってことですね

今のところ404以外出してないんですけど、なんとなくその方がいいかなって

7:38 PM

401とか増えるかも、、、しれない

encodeResponseメソッドに直接status渡せるのか。

これはなんかencodeResponseの戻り値が合わない〜って悩んでたときに発見しました。

なるほど。

Server Side Swift楽しいっすね。

お

7:40 PM

良いですよねどのへんが楽しいですか

Swiftで書けるところだなあ。

それはそう

Node.jsとTypeScriptでいいやん、と言ってたけど、あれは嘘だ

言語のせいで引っかかるところが少ない

7:41 PM

嘘wだいぶ来ましたね

Node.jsとかライブラリの先を見に行く気にあんまならないし、

それはありますね、xcodeでポンポン潜ってコード読んでわかれる

まあなんか組み合わせで書けるんだけど、ものができた以上の楽しさは少ないかな。

型かなぁ

7:44 PM

型がないと読んでても不安になる逆にTypeScriptは型が複雑なことしすぎて厳しい

7:44 PM

Swiftの型はちょうどいい。めっちゃ主観的な意見だけど、、

ちょうどいいってのはありますね。

7:47 PM

あとはHTMLの部分がもうちょっといい感じになれば。

7:48 PM

最終的にはSwiftで書けるのはいいと思うけど、過渡期の間はJSXとかEJBとか既存のものが扱えるといいじゃないかな。

7:49 PM

普通のHTMLで扱える、でもいいけど。

ふむ

Leafは＃の問題を除いても、独自の拡張子で既存のフォーマッタとかハイライトとかそのままだと動かないし。

たしかに、既存のものに寄せるとツールとかが使えたりしますね

HTMLとかJSはVS Codeみたいなのがないと書けない。

<html><body>hello world</body></html>

8:04 PM

かけた！

8:05 PM

Scalaでサーバーサイド書いてる身としては

8:06 PM

相当分厚いjvmの資産とかを考えると

8:06 PM

なかなか新しいものを実用するは怖い気持ちがある

実用できるのはいつになりますかねえ。もっと使う人が増えてパッと検索すると情報が出てくるようにならないと。。。

時間かかるんだろうなという印象。あとはメジャーでトラフィックの多いサービスが使ってコントリビュートするとかがないと。

8:23 PM

こういうのって運用が関わってくるから、知見の蓄積がないとダメで

8:23 PM

jvmの世界はもうそれは枯れまくってるのでなかなか容易い

 static var updateDatePropertyKeyPath: KeyPath<PasswordResetModel, TimestampProperty<PasswordResetModel, DefaultTimestampFormat>> { \.$updateDate }

6:36 AM

Modelを抽象化したら派手なのが出てきた

型がゴツい (edited)

大きめのデータを受け取りたい、場合は app.post("update") { req -> EventLoopFuture<SyntaxResponse> in を app.on(.POST, "update", body: .collect(maxSize: "10mb")) { req -> EventLoopFuture<SyntaxResponse> in でいいのかな。そうするとルーティングは全部 app.on(.POST 形式に合わせた方が見やすいかな。

5:34 PM

そうでもないな。

ちょうどその辺今日見てた

5:36 PM

容量をでかくするならそれでもいいし

5:36 PM

public final class Routes: RoutesBuilder, CustomStringConvertible { public var all: [Route] /// Default value used by `HTTPBodyStreamStrategy.collect` when `maxSize` is `nil`. public var defaultMaxBodySize: ByteCount /// Default routing behavior of `DefaultResponder` is case-sensitive; configure to `true` prior to /// Application start handle `Constant` `PathComponents` in a case-insensitive manner. public var caseInsensitive: Bool public var description: String { return self.all.description } public init() { self.all = [] self.defaultMaxBodySize = "16kb" self.caseInsensitive = false } public func add(_ route: Route) { self.all.append(route) } } extension Application: RoutesBuilder { public func add(_ route: Route) { self.routes.add(route) } }

5:36 PM

この defaultMaxBodySize が普段は入ってるんで

5:37 PM

あーでも微妙だな。

5:37 PM

一つのところだけでかくしたいならここは変えないほうがいいですね。

5:38 PM

ほうがいいというか都度評価だから駄目だ

5:38 PM

on(.POST, "update", body: .collect(maxSize: "10mb")) の一択っぽい

5:38 PM

メモリに載せたくないなら .stream にして、リクエストハンドラでチマチマ読み出すことはできます

5:39 PM

ただ制限突破したいだけなら collect(maxSize) ですね

そっすね。だいたいエンドポイントで変わると思います。（今回は一個しかないけど）でまあだいたい多くても数十MBくらい一度に受けれたらいいことがほとんどだろうから、20〜30MBとかにしとけばだいたいいい感じなのかな。 (edited)

5:41 PM

デフォルトは16kbなのか。すぐオーバーするな。

Leafの# にエスケープがいる仕様はリファクタリングの過程で別のファイル（〜.cssや〜.js）に分けると今度は戻さないといけないんだけど、忘れると静かに表示が壊れる。

7:03 AM

いちおうエスケープしなくても済むように検討しているみたいなIssueはどこかで読んだ。置き換え文字列を無難なものに変えた方がいいと思うけど。。。

つらそう

普通にHTML・CSS・JSを使うぶんには起こらないことだからその可能性を忘れがち、なのがツラいところですねえ。

絶賛開発中のインラインでJSやStyleをちょこちょこ書いて試す、みたいな間は普通にHTMLを書くほうがいいけど、コードベースが整然としてくるとHTML全部Swiftから生成したいな。手でHTMLを書いてると静かに壊したりちょっとした書き方のブレが気になってくる。

2:15 PM

最初からSwiftで書いていくのはまあまあハードだと思うけど、だんだんHTMLを書くほうがしんどくなってくる。。と思う。

サーバーサイドと wasm である程度共通の API を持つ @resultBuilder を使った HTML のテンプレートエンジン的なものがあれば使いやすかったりするでしょうか？目的が違うから微妙？でも API が似てたら両方を触りやすい気も。 (edited)

12:29 AM

div(id: "foos") { for foo in foos { img(src: "img/\(foo.id).png", alt: "foo") } }

12:30 AM

みたいな感じで。用意されてないものは最悪↓ tag("img", ["src": "img/foo.png", "alt": "foo"]) みたいに逃げられる。 (edited)

ちょうどそれ作ろうと思ってます

デファクト的なものが盛り上がって、 SSS も wasm も似た API で触れるといいよね。

そうですね nextjsとかは

6:25 AM

reactをサーバーサイドで描画するし

6:25 AM

どちらも需要がある

私も同様のものを作りたい気持ちが出てきてるんですけどまだデザインがピンときてないんですよね。上記のようなHTMLに似たものをSwiftで書くっていうのは、ある種の問題を解決するとは思いますが、常用するのはハードルが高いかなと漠然と思っています。

6:55 AM

Swiftで書きたい、と言いましたがこれだったら直接HTMLを書いたほうが、っていうのを超えるのは難しそうなんですよね。

6:55 AM

UIKitやSwftUIみたいにかけるのがいいんじゃないかとこれも漠然と思っています

iOSDC のときに少し @Yuta Saito にも話したんだけど、 Tokamak も需要はあると思うけど、 wasm では純粋に HTML に振ったライブラリも需要があるんじゃないかなと思うんよね。それが単純に DOM を作るだけなのか、 React / SwiftUI 的な仮想 DOM なのかは検討の余地があるとして（というか両方ほしい？）。

6:56 AM

@Kishikawa Katsumi HTML は型付けされてないから、静的型のサポートを受けながら HTML を @resultBuilder で書けたらうれしいこともありそうな？

それはあると思います。が、全体をこれで書いていくのは常にHTMLが見えててツラそうな印象があります。

一応既存のテンプレートエンジンをresultBuilderでやりたいというのであればVapor が HTMLKit というのを作ってはいますね (Vapor4で使うドキュメントがなかった気がするけど…) https://github.com/vapor-community/HTMLKit

vapor-community/HTMLKit

A type-safe DSL that renders dynamic HTML templates in Swift - vapor-community/HTMLKit

1

6:58 AM

って思ったけど普通にreadmeに書いてあった

この辺に関しては私の主張はあまり一貫していないです。

それに、結局 Swift のコードの中に書きたいという需要なので、そうすると HTML を書こうとするとエスケープとか色んな問題が生まれるから、 Swift の構文に則って書けたらうれしいように思います。

HTML、CSSをどれくらい書けるか、にもよるのかも。私はあまり自由に書けないので、HTMLをカッチリ書けるというのはHTMLを直接書いたほうが、と思うことが多いです。

使い方にもよりそうですね。 HTML 全体を書く場合わざわざ Swift で書かなくてもってのはありそうで、一方で React みたいにコンポーネントを組み上げていく形なら断片的だし @resultBuilder でいい気もします。

JSXはめっちゃ良いと思っています。

7:03 AM

あそこまでHTMLにするか、UIViewを重ねる感じで書けるか、がいいのかなあ。

Swift で HTML 全体を書くのは、ツール周りも整わないと辛そう。簡単にレンダリング結果を確認できるかとか考えただけでも。ポータビリティも、 Swift -> HTML はレンダリングしてしまえばできるけど、 HTML -> Swift が辛そう。

7:04 AM

JSX の代わりに @resultBuilder だと思うんですけどねぇ・・・。

@resultBuilder でHTML書くのはけっこうツラそうな気がするんですよねえ。

JSX も純粋な HTML じゃないし、パーツを書くだけだったら変わらなくないですか？

はい、やってみたら案外いけるかも、となる可能性もけっこうあります

今のLeafは文法がちょっと変わってループは #for(version in versions): <option value="#(version)">#(version)</option> #endfor こう書くみたいだな。ドキュメント（１つ前のバージョンしかない）に載ってるのは <ul> #for(planet in planets) { <li>#(planet)</li> } </ul>

いや、書き方が増えただけで前のも使えるのかな？どうもForとIfを組み合わせるときはネストした中カッコをエスケープする必要があるらしく前のが動かなかったのはそのせいかも。

#if(version == stableVersion): <option value="#(version)" selected>#(version)</option> #else: <option value="#(version)">#(version)</option> #endif

Ifもこんな感じっぽい。 https://forums.swift.org/t/pitch-new-leaf-body-syntax/18188

Pitch: New Leaf Body Syntax

Pitch: New Leaf Body Syntax Leaf is a templating language built for Swift. This pitch proposes introducing a new syntax for declaring tag bodies that would simplify the parser and make using Leaf easier. Current Syntax Leaf has supported the following syntax for declaring tag...

私はとにかく # を使うのをやめてほしいと思っているが。。。

[]にしましょう

4:03 AM

ObjCを思い出せる

ブレースによるやつはVapor3の文法で、今は使えないはずですね。

4:04 AM

[] もJSで使うから厳しそう…

よさそうなのはぜんぶ使われてる...

他のテンプレートエンジンはなんとかなってるから%とか$でいいと思うんですけどね。

バックスラッシュはだめなんですっけ？ jsの正規表現で使うバックスラッシュと組み合わさるとものすごいエスケープになりそうですが……

2文字つかっていいなら幅が広がる

$はjQueryで多用されるから拒否感ありそうな気が

正規表現で使うのは普通のスラッシュだから行けるかな？

4:28 AM

あ、ドルはダメなんでしたか。

バックスラッシュにマッチするのを書きたい場合 "\\\\\\\\" になりそう

$はjsでidになれるから。

%も演算子なのでそれエスケープはしたくないですねぇ・・・

そもそもLeafはそんな凝ったコードは中にかけないっぽいんですよね。

{{}} とか

いや、書けるのか？

中身は大したこと書けないですね。

2文字系はわりといける感じ

{{ なんか変数 }} はありですよね。

上のPitchの話では{}の対応が壊れてても大丈夫なようにしたいとか書いてあったので {{}} もだめかも。

書けないっすよね。私はちょっと書式の問題かコードの問題か切り分けられてないけど、どうも条件分岐も決まった感じにしか書けないっぽい。

うーん

一部の比較演算子とか ! が使えるくらいですね。あとはカスタムタグで頑張るしかない。カスタムタグ使ったことないですが

カスタムタグ！懐かしい感じになってきたぞ。

https://docs.vapor.codes/3.0/leaf/custom-tags/ 4のドキュメント無いのが辛い

4:33 AM

https://github.com/vapor/leaf-kit/blob/master/Tests/LeafKitTests/LeafKitTests.swift#L605-L627 テストコードだとこのへんかな

"Hello #custom(name)" うーむ。思ってたのと違うなあ。

カスタムルーター、みたいなのありますかねえ。

 app.get("*") { req -> EventLoopFuture<View> in guard let pattern = try? NSRegularExpression(pattern: #"^\/([a-f0-9]{32})$"#, options: [.caseInsensitive]) else { throw Abort(.internalServerError) }

^ みたいな正規表現を使ったルーティング、増えてくると大変だから１つ１つ書きたい。

6:32 AM

app.get(#"^/([a-f0-9]{32})$"#) app.get(#"^/([A-Z2-7]{26})$"#) みたいに書きたいが。。。

SwiftNIOはとても良いんじゃないか

わかる

Future Promiseが便利

でもネットワークプログラミングのインターフェースとしてはなんかちょっと独特で難しいです

そうなんすか

swiftnioはnettyやってたひとたちが作ってるからnetty的な風合いがある気がする

6:34 AM

nettyはfinagleの足回りなので割と戦った記憶がある

そうですね。 > It's like Netty, but written for Swift.

Server Side SwiftでFirebaseを使うにはREST API経由になるのはちょっと面倒だな。

8:13 AM

gRPCでもいいかもしれないけど。とにかく標準のSDKはiOS/macOS用だから使えない。 (edited)

あー、 Swift のサーバーサイド用 API がないんですね。 (edited)

そうなんです。FirestoreはスキーマレスだからCodebleに対応させるのもちょっと面倒だったり

iOS 用のを fork してサーバーサイドでも使えるようにするとかも、規模がでかすぎて大変そうですしね

8:22 AM

https://github.com/firebase/firebase-ios-sdk/blob/master/Package.swift ↑に Linux を加えて swift build したらどの辺りにエラーが出てくるでしょうね。

firebase/firebase-ios-sdk

Firebase iOS SDK. Contribute to firebase/firebase-ios-sdk development by creating an account on GitHub.

firebase-ios-sdkはObjective-Cで書かれてるんですよね。。。

8:24 AM

必要に応じて部分的にSwiftに移植する、が現実的ですかねぇ (edited)

あ、これはガワを被せただけなのか・・・。

Pythonの

たしかに、そういえば FIR プレフィックス付きのが見え隠れしてました。

SDKをブリッジするはどうだろう

なるほど、それはありかもしれませんね。 Python 連携は比較的やりやすそうだし。

全部同期的にやるならアリかも知れないですね

https://github.com/pvieito/PythonKit

pvieito/PythonKit

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

8:28 AM

↑これ使う想定ですか？

選択肢として、 REST API（gRPC?）を使う（リクエストとレスポンスのモデル定義が面倒だけど確実、簡単）、 iOS SDKを部分的に移植して使う他言語のSDKをなんとかして使う

8:28 AM

か。 PythonKitは未知ですけど、そういうので意外と簡単にできないかな、、、みたいな。 (edited)

PythonKit は Swift for TensorFlow 互換で Swift for TensorFlow チームと連携して作業してたはずなので、それなりに信頼できるかと思います。ちゃんと使ったことはないですが。

PythonKitはクロージャの受け渡しみたいなことが単体だとできなかった気がするんですよね

なるほど。それで「全部同期的にやるなら」なんですね。

ですです

Swift に async/await が来て、 Python の async/await と連携して、さらに Firebase SDK for Python が async/await に対応してて、違いがうまく吸収されるようになるという夢のような状況なら連携しやすそうですが、なかなか難しそうですね・・・。

8:33 AM

Firebase は基本非同期だからクロージャの受け渡しに難があると大変そうですね。

async/awaitのFFIはアツいですね

めっちゃ大変そうですが

8:34 AM

JavaScriptKit も直面するテーマですね

そうなんですよね〜、、

8:35 AM

JavaScriptKitがNode.jsと連携して動くようになればNode.js向けのSDKと連携してうまいこといくようになるかな？ (edited)

意外と Promise に包むのと剥がすのだけでうまくいく？

8:37 AM

JS の async は JS の世界に閉じてるから、単に Promise を返す関数というだけだから、 JS で Promise を返す関数を await したときに、うまく剥がしてやれば良い？

8:38 AM

Swift から見たら JS の関数全部 async になっちゃうのか。

JSPromiseにawaitメソッドを生やして、それがasyncになっていれば良いのかな https://github.com/swiftwasm/JavaScriptKit/blob/main/Sources/JavaScriptKit/BasicObjects/JSPromise.swift (edited)

swiftwasm/JavaScriptKit

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

あー、そうやってマニュアルで解決する方法はありますね。

8:40 AM

throws はどうなってるんですっけ？

8:40 AM

let divElement = document.createElement!("div").object! この createElement とか try なしで呼べているのはなぜ？？

例外は今の所キャッチしてないですね

8:41 AM

全部throwsになっちゃうので…

8:41 AM

ユーザーが明示的にthrowableな関数であることをアノテートする、がいい感じですかね。 (edited)

なるほど。

8:42 AM

同じ方針でいくとユーザーが明示的に async であることをアノテートする、になりますね。

let divElement = document.createElement!.throwing("div").object!

8:42 AM

こんな感じですかね

8:43 AM

同じ要領でいくとasyncはこう？ let result = fetch!.async("...")

そんな感じになりそうですね。そうすると throwing も throws の方が対応がわかりやすそうだけど（英語としてどうかは別として）。

ただ、JSは関数もオブジェクトで throwing フィールドがあるかも知れないんですよね

throwing は JSValue のメソッドではなく、 JS 側で持ってるってことですか？

8:46 AM

あ、シャドーしちゃうかもしれないってこと？

シャドー

それです

さっきからリポジトリを検索しても throwing が出てこないですが、どこに実装あるんでしょうか？

throwingはさっき頭の中で考えた機能です

なるほどｗ

8:51 AM

JSValue を受ける関数にするのはどうでしょうか？ let foo = try jsTry(jsFoo)

8:51 AM

JSValue の中に throw されたエラーの情報を閉じ込めておいて。 (edited)

8:52 AM

やばい、ここ #server-side だった・・・。

（firebaseから随分話が飛んでしまったw）

8:52 AM

続きは #wasm

亀ですが、FirestoreにはCodableに対応したSwift Extensionがいます https://github.com/firebase/firebase-ios-sdk/tree/master/Firestore/Swift (edited)

firebase/firebase-ios-sdk

Firebase iOS SDK. Contribute to firebase/firebase-ios-sdk development by creating an account on GitHub.

おお。なるほど https://github.com/firebase/firebase-ios-sdk/blob/master/Firestore/Swift/Source/Codable/DocumentSnapshot%2BReadDecodable.swift#L30 ^ このメソッドがうまいことシンプルなモデルにしてくれるやつかな？ fields.キー.stringValue みたいな複雑なモデルいらなくなるんや。

firebase/firebase-ios-sdk

Firebase iOS SDK. Contribute to firebase/firebase-ios-sdk development by creating an account on GitHub.

func suspendAsync<T>( ^ こういう文字列をLeafで置換すると func suspendAsync( みたいに <T> が消えるんだけどどういうことなの

タグになってる・・・？

そういう解釈でなんか消してると思うんですけど <T> こういう形になってない < や > はOKだし何のためにやってるのかわからない。

4:51 PM

Vapor 2の頃は #raw() ってのが使えたらしいけどすでになく、カスタムタグを作るという方法があるらしいけど、よくわからなかった。カスタムタグを通しても消える。

4:51 PM

そのまま消さずに出す、みたいなデータ型がなかった。

4:52 PM

しょうがないからBase 64で渡したけどどうするのがいいんだろう。

4:55 PM

Base 64もJSのビルトインのBase 64はマルチバイト文字をマトモに扱えないから苦しい。

プロジェクトをビルドするときにメモリ使用量が1Gを超える瞬間があるらしく、 AWS EC2 の t2.micro インスタンスではメモリ不足でクラッシュしてしまった

7:04 AM

t2.small にしたらビルドできた。

swapおいてますか？デフォルトだと無いのでめちゃくちゃ重いですよ

$ top で見てたら swiftプロセスが 900M ぐらいもっていく瞬間があるのは見えた

t2.microのメモリ量も相まって

そのまま使ってるからswap無いっぽい

7:06 AM

ただ t2 micro でもそもそもめっちゃ遅いから、スワップで生き延びても更に待ち時間伸びそうでヤバそう

コードによりますけどクラッシュまでしたことはないですね。応答しなくなってインスタンス再起動したことは何度かありますが……

LLVM ERROR: out of memory って表示されてコンパイラのスタックトレースが出たよ

7:08 AM

https://github.com/vapor/vapor/blob/master/Sources/Vapor/HTTP/Headers/HTTPMediaType.swift#L234

7:08 AM

この行のtypecheckがトドメを刺したらしい

7:09 AM

ただ中間データ構造もメモリに乗ってるだろうからこの行が重い影響がどの程度致命的だったのかはよくわからんが

ところで @Kishikawa Katsumi func suspendAsync<T>( の埋め込み　こちらではソースには<T> 出てました。

ブラウザがタグとして隠しただけでLeafの出力には乗ってる？

はい。

む、Leafのせいではない？

9:55 AM

私はデプロイ先のインスタンスはだいたい非力なのでビルドは諦めてイメージをPullするだけにしました。ビルドはGitHub ActionsとかCIでやります。

なるほど。

Nodeはそのままで全然OK、Rubyはswap追加でOK、Swiftは（Vapor）はどうやっても無理、でした。多少スペックを上げて見ましたが変わらなかった。ビルドするのはだいぶスペックが入りそうなのでどっちにしろ別に分けるしかなさそう。

9:58 AM

GCEの一番下のスペックで確認。たぶんAWSのmicroと似たようなもんだと思う。

9:59 AM

Vaporは月5000円くらいのプランでもダメだったから諦めました。

t3.microで月1000円くらいでしたっけ 5000円で無理は何か別の問題がありそう……

なるほど、もっかい調べてみるかな。あまり期待せずに試したから雑だったかも。

Vaporは月5000円くらいのプランでもダメだったから諦めました。

これはウソでした。月5000円だとvCPU x 2、メモリ 8 GBあるんでビルドは終わりました。

10:18 AM

ビルド時間はやはりかなりかかるけど。。。

10:19 AM

まあでもSwiftはメモリを積めば積むほどビルドが速いな。

めちゃめちゃ時間かかるけど4GBメモリのマシン（＝月3000円くらい）でもビルドは終わった。前は裏で別のイメージをビルドしてたりして止まったか、単に時間がかかってるだけのを止まったと勘違いしたっぽい。

VaporのFluentの @Parent リレーションは、 self.$parent.id が non optional で self.parent.id が optional なのはうまいことできてて良いな。

9:44 AM

本当は型で頑張って self.parent.id も non optional になっててほしいけど

9:45 AM

ParentModel.id そのものが optional なのはレコードの新規作成を考えると正しい。

@t.ae @omochimetaru 今度Server Side Swift

2:36 PM

@t.ae @omochimetaru にテーマを絞ってPodcastで話をしようと考えてるんですけど識者としてゲスト参加してくれませんか？

2:36 PM

予定は都合に合わせるので。

良いですよ〜　podcast聞いたこともやったこともないけど・・・

sonsonさんは素人、私はちょっと齧ってなかなか使えると思ってるけどツラいところも結構ある、みたいな立場で、いやそれは実際にはこう、みたいな感じで正してほしい。

とりあえず10月いっぱいは忙しいので11月以降に相談したいです。

2:38 PM

なるほど

了解です。じゃあまた１１月に声をかけます。一番詳しいのは @t.aeさんだと思うのでぜひお願いしたいっす。

そうですね > 一番詳しい

Docker in Docker (Docker out of Docker) でRootユーザじゃなくて実行するようにできた。実行ユーザーをdockerグループに入れる、というのはそうなんだけどそれだけだとダメでホストと同じGIDを持つdockerグループ、に入れてやることでできた。 RUN groupadd docker -g ${HOST_DOCKER_GROUP_ID} && \ usermod -a -G docker vapor

3:00 PM

HOST_DOCKER_GROUP_ID はビルドするマシンは別だから一回SSHにログインして取る。

3:01 PM

TERM=xterm ssh -t -t -o 'StrictHostKeyChecking no' "${{ secrets.SSH_LOGIN_USER }}@${{ secrets.SSH_HOST }}" "grep "^docker:" /etc/group | sed -e 's/^[^:]\+:[^:]\+:\([^:]\+\):[^:]\+$/\1/g'" > gid REMOTE_DOCKER_GID=$(echo $(tail -n 1 gid) | sed -e 's/\r//g')

CIの最初の方でこんな感じでとってる。デプロイ先は getent も入ってないOSだからグループIDを取るだけなのに結構ややこしいことをしている。

ほお〜

3:02 PM

なんかコンテナならではの仕組みですね

3:03 PM

Dockerの中のプロセスもホストマシンのプロセスだからGroupによる権限があればホストのDockerエンジンに触れるのか。

DooD (Docker out of Docker)方式はホストのDocker Daemonと通信するソケットをコンテナに共有するんですよ volumes: - /var/run/docker.sock:/var/run/docker.sock:ro で、それ以外のDockerのCLIとかはコンテナに別途インストールするんですけど、docker.sockがrootかdockerグループにいないと読めないんですけど、rootかホストと同じGIDのdockerグループ、でしたね。私の環境では。

3:07 PM

具体的な方法はそういうことであとは

Dockerの中のプロセスもホストマシンのプロセスだからGroupによる権限があればホストのDockerエンジンに触れるのか。

ということだと思います。

なるほど、unixsocketを挿し込んでやるのか。

3:11 PM

そのソケットがパーミッションモデルでマシン内において保護されてるからグループを使うのかあ。

実行するだけなら細かいことはいいんですけど、ボリュームをマウントするとその構造が難しくて、コンテナ（子）の中から作ったコンテナ（孫）も結局子のコンテナと同じなので（ホストが作ったコンテナと同じ）子のコンテナのボリュームを孫にマウントするとそれは何もないものをマウントするので親から見たパスを孫にマウントする、みたいなところがややこしいです。

ｗｗ

services: app: image: kishikawakatsumi/swift-playground:latest container_name: swift-playground depends_on: - letsencrypt env_file: - .env environment: HOST_PWD: $PWD/

このボリュームを孫にマウントできるようにするのをポータブルにするためにdocker-compose.ymlでホストのカレントディレクトリを渡しています。こういう書き方ができるのがよかった。

https://github.com/vapor/vapor/blob/master/Tests/VaporTests/URLEncodedFormTests.swift#L255

5:17 PM

let tanner = User(name: "Tanner", age: 23, pets: ["Zizek", "Foo"], dict: ["a": 1, "b": 2], foos: [.baz], nums: [3.14], isCool: true) let ravneet = User(name: "Ravneet", age: 33, pets: ["Piku"], dict: ["a": -3, "b": 99], foos: [.baz, .bar], nums: [3.14, 144], isCool: true) let usersToEncode = Users(users: [tanner, ravneet]) let result = try URLEncodedFormEncoder().encode(usersToEncode) XCTAssert(result.contains("users[0][pets][]=Zizek")) XCTAssert(result.contains("users[0][pets][]=Foo")) XCTAssert(result.contains("users[0][age]=23")) XCTAssert(result.contains("users[0][name]=Tanner")) XCTAssert(result.contains("users[0][dict][a]=1")) XCTAssert(result.contains("users[0][dict][b]=2")) XCTAssert(result.contains("users[0][foos][]=baz")) XCTAssert(result.contains("users[0][nums][]=3.14")) XCTAssert(result.contains("users[0][isCool]=true"))

5:17 PM

VaporはQueryStringに構造化データのエンコード/デコードできるらしい

5:18 PM

できないと思い込んで無駄に頑張ってしまった・・・

なるほどねえ。

まあこのキーに [ ] を使ってパスを表すスタイル自体はPHPからあるんですが・・・

ただこれはクエリで与えるのも受け取るのもしんどいからJSONでBODYにした方がいいんじゃない

Vaporは無理だろうな〜っと下から入ったのが良くなかった。。

ああいうのって規格化されてるんですかね？それとも慣習？

これは規格ではないと思います・・・

5:20 PM

&で区切った K=V 形式自体は、 x-www-form-urlencoded で規格になってるけど。

5:22 PM

JSONでBODYにした方がいいんじゃない

ブラウザのFORMから自然にPOSTさせようとするとこっちが楽なんです

ああ、確かにブラウザからはそうかな。ブラウザからJSでPOSTがいいと思うけどそれよりもFORMの方が良い？

リロードボタンを押したときの振る舞いとか

5:24 PM

普通のPOSTと違ったりしそう。調べてないけど。

5:24 PM

Fetch API ってことですよね？

それかXMLHTTPRequest。まあ一緒っすね。 FormのSubmitで動くJSでパラメータを集めて改めてFetch APIかXMLHTTPRequestでPOST。

やっぱり、ブラウザとしての遷移を挟まないのが気になりますね。

5:29 PM

それを完全に捨てるとか、逆にHistoryAPI使っていい感じにするとか、道はあるけど。

5:29 PM

認証系ヘッダーとかクッキーの振る舞いとかも。まあ制御する方法はあるんでしょうけど

5:33 PM

https://www.npmjs.com/package/query-string

query-string

Parse and stringify URL query strings

5:34 PM

jsのquery-stringライブラリは、構造データは扱えないらしい。 JSONにして文字列にすればとか書いてある。 1次元の配列だけは扱えるらしい。

https://github.com/ljharb/qs はめっちゃ深いネストじゃなかったらいけるみたい

ljharb/qs

A querystring parser with nesting support. Contribute to ljharb/qs development by creating an account on GitHub.

By default, when nesting objects qs will only parse up to 5 children deep.

この制限いるのか？ｗ

5:39 PM

でもこれはいいですね

5:40 PM

こいつを使えばJS側でも取り回せるな。

Express.jsが使ってるのはこれらしいです。

なるほど。

5:42 PM

デフォルトでは [ をパーセントエスケープするところがちょっと違うな。

5:48 PM

https://github.com/vapor/vapor/blob/master/Sources/Vapor/URLEncodedForm/URLEncodedFormParser.swift

5:49 PM

パーセントデコードしてない状態を型で区別していて良い。

.urlEncoded(value)

なるほど。どっちでもStringはStringだけど型でラップすると混同を防げるんだな

パーセントエンコードとかは前後が両方文字列だから、2回やっちゃったり、0回になっちゃったり（これは危険！）するバグがまれにあるんですよね。

https://discord.com/channels/291054398077927425/291397416043675649/767646667356373002 <xmp>...</xmp> で囲うことで<T>みたいなタグっぽい部分の出るようになりました。ということでLeafは濡れ衣でした

■HTML5情報 HTML5では、<XMP>は廃止される予定です。 <pre>や<code> に置き換えることが推奨されています。

と言ってもPreとCodeだと挙動が違うんですよね。

9:29 AM

XMLのCDATAセクションを使う、、というのもいけそうだけど。少なくともタグっぽいものをそのままだす、というのはPreとCodeだとやってくれないです。

なるほど。

本当はちゃんとエスケープしろ、ということだと思うけど。。。

うーん、POSTサイズの仕様が悩ましい

6:40 AM

投稿内容を検証するmiddlewareはコントローラーより先に処理したいけど

6:40 AM

検証のためにPOST body stream を collect する必要があって

6:40 AM

そのサイズの設定は本当はコントローラーの route登録のところに書きたいのに

6:41 AM

前段にあるmiddleware全部に設定しないといけなくなる

6:41 AM

サイズの制約を外すのはファイルアップロードする特定のrouteだけにしたいし・・・

特定のエンドポイントにだけミドルウェア注入できなかったでしたっけ？

このミドルウェアがCSRF対策フィルターで

6:43 AM

全部にまとめてかけてるんだよね

6:43 AM

一箇所だけ外す/設定を変えようとすると

6:43 AM

他も全部一個ずつ設定する書き方になっちゃう

なるほど。

セキュリティ関係だしまとめて設定する書き方にしたい

6:44 AM

Middlewareがその先のresponder chainを盗み見できたらいいんだけど・・・

6:44 AM

public protocol Middleware { func respond(to request: Request, chainingTo next: Responder) -> EventLoopFuture<Response> } public protocol Responder { func respond(to request: Request) -> EventLoopFuture<Response> }

(edited)

6:45 AM

あまりに何もみえねえ

発想の転換で、GETに変えるとか

1

そもそもMiddlewareでcollectする必要があるのってどうなんですかね？遅らせるのが良いのは分かるけどMiddlewareでリクエスト内容ほしいことはよくありそうだし・・・ (edited)

collectしないとparseできないのは本質的に回避できない

6:47 AM

認証ヘッダーを使うとかやればいけるけど

6:47 AM

そうするとHTML側が凝った作りになってしまう

6:48 AM

どうなってればいいかでいうと

6:49 AM

controllerの直前でBasicResponderがcollectした直後の、ハンドラ突入の前

6:49 AM

このタイミングに挿し込める規格があったら嬉しい

固定のパスだからどうにかなるけど

7:27 AM

これプレースホルダもつかってたらどうすりゃいいんだ

7:29 AM

やっぱ1ルートずつミドルウエアを全構成するしか無い気が

7:30 AM

まあヘルパー関数書けばそんなに大変でもないか・・・？

7:32 AM

 func add(_ collection: RouteCollection, csrf: Bool = true, login: Bool = true) throws { var middlewares: [Middleware] = [] if csrf { middlewares.append(csrfProtection.middleware) } if login { middlewares += userLoginGuard(doesRedirect: true) } try routes.group(middlewares) { (routes) in try routes.register(collection: collection) } }

7:32 AM

こんなかんじか。。

7:35 AM

あ、ちがう、CSRF外したいわけじゃなかった。

エンドポイントで決まってる（ことの方が多いと思う）ならAppじゃなくてリバースプロキシで制限してもいいんじゃない。

あ〜なるほど・・・

8:53 AM

リバースプロキシさんは既に自分でPOSTをデコードしてるから良いのか。

やっぱ1ルートずつミドルウエアを全構成するしか無い気が

大きいサイズを許容したいルートとそれ以外のルートで分けたら良いんじゃないですか？ルートの階層構造によってはやっぱり面倒ですが

認証の階層とか

9:00 AM

ブラウザ向け / API向けの階層とか

9:00 AM

それらがマトリックスになってるから

9:00 AM

どれかが犠牲になるんだよね。

そのへんすでに分かれてると更に倍に分かれるので微妙ですね……

https://twitter.com/_cweinberger/status/1322522026985345025?s=21

Christian Weinberger 😷 (@_cweinberger)

An interesting (early-stage!) thread outlining how the new swift concurrency features might be adopted by #SwiftNIO. https://t.co/h5obfu5nsn #ServerSideSwift #SwiftLang @codevapor

@t.ae 前に書いたPodcastでServer Side Swiftの話をする会、「来週の13日以外」のどこか、21~23時くらいを予定しているのですが、ご都合いかがですか？一番詳しい人にぜひ加わっていただきたいと、思ってます

13日以外ですね。今の所何日でも大丈夫です。正直言ってあまり話せること無いと思いますが、それでよろしければ。

ありがとうございます。日にちを決めてお知らせします。気楽に参加してください

@t.ae 12日の21時から、使用するツールはZoomでお願いします。ZoomのURLは当日までにお知らせします。

1

CodableだけどVaporのContentにConformsできないっていうの https://github.com/kishikawakatsumi/CodableConformsToContent/blob/master/Sources/App/routes.swift#L15 これです。 DocumentSymbolRequest.Response は Codable なんですけど

Conditional conformance of type 'Optional<Wrapped>' to protocol 'Content' does not imply conformance to inherited protocol 'RequestDecodable'

というエラーで、定義は

public struct DocumentSymbolRequest: TextDocumentRequest, Hashable { public static let method: String = "textDocument/documentSymbol" public typealias Response = DocumentSymbolResponse? /// The document in which to lookup the symbol location. public var textDocument: TextDocumentIdentifier public init(textDocument: TextDocumentIdentifier) { self.textDocument = textDocument } }

なので typealias Response = DocumentSymbolResponse? のところが問題なのかな？ちなみに、 DocumentSymbolResponse の方は extension DocumentSymbolResponse: Content {} でOK。 (edited)

kishikawakatsumi/CodableConformsToContent

Contribute to kishikawakatsumi/CodableConformsToContent development by creating an account on GitHub.

往年の芸能人のブログ並みの改行具合

ホントだ。。。自分でもなんでこうしてしまったのか。。。

改行がx3に?

なんかコードブロックの後は自動的に空行が入るのかな。それで自分の入れたのと合わせてダブル改行みたいになってる、というのはわかりました。

Discordが悪いのか...

ちょっと編集しました。コードブロックの後の改行はどうにもならないっぽいですね。

let a = 1

(edited)

4:05 AM

なるほどー

4:05 AM

`x3 の直後の改行はx2になる

もとの話題に戻ると、

extension DocumentSymbolRequest.Response: ResponseEncodable {} extension DocumentSymbolRequest.Response: RequestDecodable {} extension DocumentSymbolRequest.Response: Content {}

上の二行を追加するとコンパイルできます。コンパイラのバグっぽい？ (edited)

おおー。protocol Content: Codable, RequestDecodable, ResponseEncodable ContentっていうのはそもそもCodable + RequestDecodable + ResponseEncodable なんですね。

4:10 AM

なかなか謎な挙動ですね。 extension DocumentSymbolRequest.Response: Content, RequestDecodable, ResponseEncodable {} はコンパイルできるけど、 extension DocumentSymbolRequest.Response: RequestDecodable, ResponseEncodable {} は同じエラーでダメ。

Codable? Content?

Contentがデフォルト実装を与えてるみたいなので下のケースはそれのエラーじゃないですか？

VaporにContentっていうプロトコルがあってVaporのリクエストやレスポンスとしてオブジェクトを渡す場合にはそのプロトコルに準拠しないといけない、というものです。で、CodableならContentにできる、、、という想定のはずなんですが、CodableだけどシンプルにエクステンションだけでContentにできなかった、ということがあった、という相談なんです。 (edited)

ホントだ。ちゃんと見れてなかった。RequestDecodable, ResponseEncodableだけ書いたときはContentが提供しているデフォルト実装がないからResponseEncodableに準拠するには実装が必要、というエラーですね。そうするとそれは合ってるからContentだけだとダメっていうケースだけおかしいんですね。

エラーメッセージ的にはdoes not imply conformance to inherited protocol 'RequestDecodable'なのでRequestDecodableを書く必要があるって言ってる気がするんですが、一般には Content だけで済むはずですよね。

4:31 AM

@swift-5.3.3

public protocol ResponseEncodable { func encodeResponse() } public protocol Content: Codable, ResponseEncodable { } extension Content { func encodeResponse() {} } struct MyType: Codable {} extension Optional: Content where Wrapped == MyType {}

exit status: 1 with stderr:

<stdin>:13:1: error: conditional conformance of type 'Optional<Wrapped>' to protocol 'Content' does not imply conformance to inherited protocol 'ResponseEncodable' extension Optional: Content where Wrapped == MyType {} ^ <stdin>:13:1: note: did you mean to explicitly state the conformance like 'extension Optional: ResponseEncodable where ...'? extension Optional: Content where Wrapped == MyType {} ^ <stdin>:13:1: error: method 'encodeResponse()' must be declared public because it matches a requirement in public protocol 'ResponseEncodable' extension Optional: Content where Wrapped == MyType {} ^ <stdin>:9:10: note: mark the instance method as 'public' to satisfy the requirement func encodeResponse() {} ^ public

これで再現できたかな

おおー、同じこと試してたんですけど再現しなくて、Contentのデフォルト実装がキモなんですね。

もうちょっと進めたらデフォルト実装関係ないみたいでした。 @swift-5.3.3

protocol ResponseEncodable {} protocol Content: ResponseEncodable {} //extension Optional: Content {} // OK extension Optional: Content where Wrapped == String {} // NG

(edited)

exit status: 1 with stderr:

<stdin>:4:1: error: conditional conformance of type 'Optional<Wrapped>' to protocol 'Content' does not imply conformance to inherited protocol 'ResponseEncodable' extension Optional: Content where Wrapped == String {} // NG ^ <stdin>:4:1: note: did you mean to explicitly state the conformance like 'extension Optional: ResponseEncodable where ...'? extension Optional: Content where Wrapped == String {} // NG ^

(edited)

Codable も関係無さそうです。 protocolの親子関係とextensionのwhere句が条件と思われます。

https://forums.swift.org/t/conditional-conformance-with-protocol-inheritance/11262/14 この辺の話題がそうかな。

Conditional Conformance with Protocol Inheritance

Yes, so for completeness, here’s how to conditionally conform MyArrayOfOne to Foobarable (leaving Array and Optional there to demonstrate – what turned out to probably be – the actual bug): protocol Fooable { func foo() } protocol Barable { func bar() } protocol Fooba...

4:40 AM

https://forums.swift.org/t/amending-se-0143-conditional-conformances-dont-imply-other-conformances/11017/18 これも関係あるかな？

Amending SE-0143: conditional conformances don't imply other confor...

Yeah, I agree that that example is a bit subtle and a bit of an edge case. I actually realised a slightly more convincing one: SomeConditionalSequence.Iterator will infer the appropriate bounds to make SomeConditionalSequence a Sequence, to get access to Iterator. I think it...

https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md#implied-conditional-conformances これが説明してそうですね

apple/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

4:45 AM

例に出てるコードはちょっと違うかな……

へー、親プロトコルつきのプロトコルは1発でcond confできないんだ。

へー

conditional conformanceは、そう

気づいてたのか

たしかこの話題は #math 辺りでやった記憶がある

VaporアプリをビルドするとBoringSSLを2回ビルドすることになって辛い。。

4:49 AM

NIOSSLと https://github.com/apple/swift-nio-ssl/blob/main/Package.swift#L41

4:50 AM

Cryptoが依存していて https://github.com/apple/swift-crypto/blob/main/Package.swift#L49

4:51 AM

さらにNIOSSL側はパッチを当ててるみたい

https://github.com/apple/swift-nio-ssl/blob/main/scripts/patch-2-arm-arch.patch (edited)

4:53 AM

JWTを検証しようとするともう一つ追加される。。。https://github.com/vapor/jwt-kit/blob/b9c8950be2530c5f55407fca723c960eae88a95f/Package.swift#L20 (edited)

vapor/jwt-kit

JSON Web Token signing and verification (HMAC, RSA, ECDSA) using BoringSSL. - vapor/jwt-kit

気づかなかったパッチがあるから共有されないんか

そうなんですよ

5:41 AM

BoringSSLはちゃんとプレフィックスが付けられるような仕組みになってて、シンボル衝突しないようになってるのでこういう重複が許されるんですよね。 https://github.com/apple/swift-nio-ssl/blob/cc0e80dbccf8c89c1f49c3a11c5929575035076c/Sources/CNIOBoringSSL/crypto/fipsmodule/digest/digests.c#L90

apple/swift-nio-ssl

TLS Support for SwiftNIO, based on BoringSSL. Contribute to apple/swift-nio-ssl development by creating an account on GitHub.

おー

https://aws.amazon.com/jp/blogs/aws/new-use-mac-instances-to-build-test-macos-ios-ipados-tvos-and-watchos-apps/

New – Use Amazon EC2 Mac Instances to Build & Test macOS, iOS, ipad...

Throughout the course of my career I have done my best to stay on top of new hardware and software. As a teenager I owned an Altair 8800 and an Apple II. In my first year of college someone gave me a phone number and said “call this with modem.” I did, it answered “PENTAGON […]

4:49 AM

EC2にmacが出たそうな

x86_64?

The instances feature an 8th generation, 6-core Intel Core i7 (Coffee Lake) processor running at 3.2 GHz, with Turbo Boost up to 4.6 GHz

Apple M1 Chip – EC2 Mac instances with the Apple M1 chip are already in the works, and planned for 2021.

4:51 AM

Vapor使うならめちゃくちゃ良さそうですね。 linux環境であれがないこれがないが解決する。

MacServer

https://www.youtube.com/watch?v=Pn3miC_tTH0

Amazon Web Services

AWS EC2 Mac Instances Launch - macOS in the cloud for the first tim...

MacStadiumの話を聞いてると滅茶苦茶大変そうだなという印象だったんですけど、こんなにシュッと用意できるものなんですね

（動画のとおりなら）１０ヶ月ぐらいかかってるからシュッではないのでは (edited)

10ヶ月なんてこの規模の会社ならシュッレベルの速さ

大きい会社が効率的に仕事をしたらこのくらい感

そうなのかなぁ

M1マックでお祭りなところにタイムリーに出てきたからタイミングは良かったと思う

小さい会社のときから大きくなったときまで経験してきたけどプロダクトの変更とかにかかる時間はうなぎのぼりなので

6:03 AM

10ヶ月って0からならヤバイ速いと思う。 (edited)

MacStadiumとかMacのホスティングサービスの会社は大騒ぎになってそう。

6:18 AM

MacStadiumくらいデファクトスタンダードなところは大丈夫なんだと思うけど。

Xcodeとかあらかじめ入ってるといいなあ。それかイメージのテンプレートから構築できるとか。空っぽの環境に入れていくとなると結構面倒。

Xcode入れていくのめんどくさいですねｗ

9:10 AM

ダウンロードしてxip解凍しないといけない。。

カスタムイメージ作れるからそこにxcode入れれそう

9:23 AM

※amiつくれるなら

料金どこに載ってるか見つけてないんですがVaporDiscordによると$1.207/ hour

まあまあ手軽に使える値段っすね。月800$程度なのかな。

そういえばMac StadiumのMacはVNCがよく使えなくなる。SSHは生きてるけどVNCつながらないということが起こりがち。よくサポートに再起動してもらってる。

絶妙な価格設定 https://twitter.com/fujiwara/status/1333662024211939329

fujiwara (@fujiwara)

EC2 mac mini、$1/hourは高いなーと思ったけど、12コア32GBということでc5.4xlargeと比べるとまあスペック相当のお値段で高すぎるということはないんだな…3ヶ月動かすと1台買えると思うと安くは感じないのがあれ

勘違いしてた。まあまあ手軽に使える値段じゃないわ。800$まで計算して800円くらいか、と思ってしまった。8万円や。

$800は岸川さんの「まあまあ手軽」な範囲なのかと思って見てました

ハハッ。 500円〜1000円くらいなら別にいいかなあって感じですねえ。

1

M1Macの小売価格が安すぎて頭がおかしくなってる説はある

1ヶ月$800でMac mini買える

800円やすい

https://soundcloud.com/nextstepfm/025-grpc Server Side Swift、VaporとかWebフレームワークも不要でSwift gRPCでAPIだけあってフロントReactでいいんちゃうの、というのは私はとても良さそうに思いました。

1

久しぶりに、というかずっと気づかなかった問題で app.on(.POST, "shared_link", body: .collect(maxSize: "10mb")) { (req) -> EventLoopFuture<[String: String]> in VaporはPOSTボディのデフォルトのサイズ制限が意外と小さいっていうのに当たった。

あれ？それ一度会話してますよ

5:25 PM

デフォルト小さいねって

そうそう。そうなんだけど、このエンドポイントは忘れてて簡単な書き方を使ってて、デフォルトになってた。

5:26 PM

なんかアプリケーショングローバルに設定できたりしないかなあ。

5:26 PM

で、さらに増やしたいとか小さくしたい場合はエンドポイントごとにオーバーライドしたい。

5:26 PM

たぶんあるんじゃないかと思うんだけど。app.config...みたいな。

そのへんの設定はあんまりうまいことできる感じではなかった

5:27 PM

多分開発リソースが足りてない部分だから、いい感じの実装を提案できるといいのかも？

そうすると、まあ定数化とか書き方を工夫することはできるけど、エンドポイントごとに app.on(.POST, "shared_link", body: .collect(maxSize: "10mb")) を現在はすべて指定していくのが正しい、であってます？

application.routes.defaultMaxBodySize

ちょっと前に別の問題でリバースプロキシとVapor側の設定があってなくて、リバースプロキシでタイムアウトになってて手元では再現しなくて困ったことがあって、今回も先にNginx側の方を調べてたからちょっと時間かかった。