swift-developers-japan

Xcode 9.1で4.0.2がリリースされたけど、リポジトリには4.0.1, 4.0.2のリリースタグが付かないですね。 swift-4.0-branch にはバージョン変更入ってるのに。 https://github.com/apple/swift/compare/swift-4.0-RELEASE...swift-4.0-branch

apple/swift

swift - The Swift Programming Language

swift-4.0.2-RELEASE来てた。

String は StringProtocol だけど Number は Numeric なんですね… https://developer.apple.com/documentation/swift/numeric

XxxProtocol は Xxx をそのままプロトコル化したやつで

8:49 AM

Numeric はまた違うんじゃ？

なんか微妙に気持ち悪いというかなんというか…？

Numericはもととなる型があるわけじゃなくてそれ単体で設計された何かなのでは

StringProtocol 以外の XxxProtocol って何があります？

https://developer.apple.com/documentation/swift/iteratorprotocol

NSObjectProtocol

そ

（早押しクイズかな

一番有名で一番邪悪

そｗ

NSObjectProtocolこれ入れるとヘッダーには書いてないけど暗黙的にclass扱いになってる気がするんだよね

ん？

IteratorProtocol 普通にわすれてたｗ NSObjectProtocol なんてあるのかぁ（白目

@tarunon https://developer.apple.com/documentation/objectivec/nsobjectprotocol

An object that conforms to this protocol can be considered a first-class object. Such an object can be asked about its:

Class, and the place of its class in the inheritance hierarchy. Conformance to protocols. Ability to respond to a particular message. The Cocoa root class NSObject adopts this protocol, so all objects inheriting from NSObject have the features described by this protocol.

8:54 AM

クラスとして振る舞うのに必要な要素がNSObjectProtocolに入ってる、って感じかしら

んにゃ、NSObjectとして振る舞う、だね

ああ、そうね

なんちゃらProtocol、意外と無いな

暗黙的にclass扱いってどういうことだろう

ヘッダーでは public protocol NSObjectProtocol { ってなってるのに、実際の動きは public protocol NSObjectProtocol: class { なんじゃあないのっていうのが各所で浮き出てくる (edited)

↑ mutating func とか絡めてみれば確認できそう

なお

@tarunon 浮き出てくるっていうのは実行時の振る舞いの話？

8:57 AM

コンパイラの振る舞い

ああー

IteratorProtocol は、 Sequence.Iterator (associatedtype) との Iterator っていう名前衝突を避けたくてそうなった感があるけどね・・・

それは :class を書いたときと同じやつか

そう、そうであるべきなのに書いてなくて卑怯だな~~ってなる

NSObjectProtocolはObjCのプロトコルだからじゃないかな。

あ〜

UITableVIewDelegateとかも確かそうじゃなかった？

8:58 AM

classって書いてあったっけあれ

@objcつけたらclass矯正されるのと同じ感じですかね

Swift以前からある、

objc側からimportされてるプロトコルは全部そうなのか。

@objc明示ルール出来たのにNSObjectProtocolはそうじゃないっていうのもね

8:58 AM

卑怯ポイント高い

UITableViewDelegateはNSObjectProtocolを継承(?)してた。

Basic Arithmetic、日本語でなんてんだ

四則演算？

9:01 AM

違うか？

> Weblio専門用語対訳辞書での「basic arithmetic operations」の意味 Basic arithmetic operations 四則演算

('ω'

) (edited)

1

あー

9:03 AM

継承はExtends、protocolの場合はどれだと思ってたら違うところ見てた。> Inherits　こっちかな

継承はinheritだね

あれれ

extendはどっちかというと拡張

9:04 AM

= extension

protocolはconformじゃない？

英語力の低さが露呈している

Relationships Inherits From Equatable, ExpressibleByIntegerLiteral Inherited By BinaryInteger, SignedNumeric

プロトコルも継承でいいんでねたぶん

ドキュメント的には protocol のページだと inherit

9:05 AM

満たしてるProtocolについては conforms だったと思う

プロトコルAと実装Bの関係がB conforms to AでプロトコルAの性質を引き継ぐプロトコルBはB inherits from Aのイメージだなあ (edited)

protocolが別のprotocolを継承している場合は inherits、何かの型がprotocolに準拠している場合は conforms、多分これで問題ないかと…？

Inherit, conform, extend, adoptのどれも同じ意味で使われることありますよ。アップルのドキュメント

キビシー

たぶん決まりはない、、、あるかもしれないけど書く人で変わるくらいのものじゃないかな。

https://developer.apple.com/documentation/swift/int あー、僕が言っていたのは文章中の英単語のことじゃなくて、↑の形式のリファレンスの、一番下の方にある機械的に書かれてるっぽいやつのことです

9:07 AM

Relationships セクションの中のサブセクションのタイトル。 (edited)

Int は型だから protocol に Conforms To ですね

Conforms To の逆参照が Adopted From として掲載されてるっぽい

意味的にもそれがしっくりくるね

protocol 同士は ~~Inherited From~~ と Inherited To (edited)

Inherits from ですね

C#のAbstract Class欲しいなぁと改めて思った https://qiita.com/taketo1024/items/71e3272211f08d7e0cde

Swift で Phantom Type (幽霊型) - Qiita

社内の「Scala 勉強会」で Phantom Type (幽霊型) という厨二心をくすぐる感じのデザインパターンを教えてもらったので、同じことを Swift でもやってみました。インスタンスの状態を変数ではなく **型パ...

9:44 AM

この例、Status を abstract class で定義できたらなぁとすごい思う

あーなるほど。

9:45 AM

この場合は、依存型が入ってくれれば、 Status を enum にすればいいですけどね〜

Javaのあの依存型ですか？

依存型は型パラメータに値が書けるやつです

9:47 AM

例えば・・・ struct StackArray<value Size: Int> { ... }

9:47 AM

みたいなノリ

https://qiita.com/hikaruna/items/7d2e919be0bc93bf3f45 こんな感じのやつ？

swiftでenumでstateパターン - Qiita

stateパターンというか列挙されたstrategyパターンというか。

環境

xcode 9.0
swift4 ## 問題

swiftのenumは要素ごとに振る舞いを定義できない

ひたすらswitch文を使...

var a = StackArray<2>() a.0 // ok a.1 // ok a.2 // compile error (edited)

StackArray 欲しいｗ

↑のtaketoさんの記事なら、 enum Status { case NotReady case Ready } class Something<value T: Status> { /*中身は同じでOK*/ } (edited)

編集リクエストを出しては？

いまのSwiftには無いですよ

ああ、後ろが value T: Status になってるのか。 (edited)

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171002/040075.html

Status が protocol じゃダメなんだっけ？ sealed にできない？

↑最近のスレ

9:52 AM

protocol だとユーザが追加した値が入れられちゃいますねあ、abstract class でもその点がダメだな

9:52 AM

- Now you can define a “dependent type”, for example ModuloInteger<P>, where P is the integer value that defines the type. - Like this, you’ll have: —> MI<2>: {0, 1}, where 1 + 1 = 0. —> MI<3>: {0, 1, 2}, where 1 + 1 = 2, and 2 • 2 = 1

Status が protocol でもダメってことはないですが、Something<NotReady>.createInstance() で書かないといけないのがイケてないですね

↑ P で割ったあまりを表す型 ModuloInteger<P> の例、型パラのところに2 とか 3とかの「値」が入る

Vector<2> とか Matrix<4, 4> とかやりたい。

ですね〜〜〜〜

むしろなんでないんだろって思う

9:54 AM

そっちの方がメモリ管理も楽そうなのにな

9:55 AM

reserveCapacity とか考えなくて済む

単に優先度っぽいですけどね、具体的なコアチームからの反論はみてない気がする

Generics Manifesto にもないよね？当分（ Swift 5, 6 あたりで）はなさそうな気が。

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-value-parameters

apple/swift

swift - The Swift Programming Language

1

9:59 AM

あった！！

10:00 AM

Currently, Swift's generic parameters are always types. One could imagine allowing generic parameters that are values, e.g.,

10:00 AM

struct MultiArray<T, let Dimensions: Int> { // specify the number of dimensions to the array subscript (indices: Int...) -> T { get { require(indices.count == Dimensions) // ... } }

(edited)

10:00 AM

例もまさに Vector<N> ですね。

10:01 AM

MayBe セクションだから

10:01 AM

ワンチャンあるで〜

てか、 Rust Like な Generic Protocol についても書いてあるな

10:03 AM

対応見込みは Unlikly になっている

10:04 AM

struct Real { ... } extension Real : ConstructibleFrom<Float> { init(_ value: Float) { ... } } extension Real : ConstructibleFrom<Double> { init(_ value: Double) { ... } }

サンプルも Rust の From trait と似てる

正直長すぎてどの項目がどの項目のサブ項目なのかわからないしOutline機能欲しい…

10:06 AM

せめてFold機能欲しい

たしかに。限界を感じます

上で出て来たenumでstateパターン、無理やりRawValueに振る舞いを実装して見た https://gist.github.com/norio-nomura/65db97c4786851bc368a8d68834fb31b (edited)

https://qiita.com/hikaruna/items/7d2e919be0bc93bf3f45 を RawRepresentable で実装

https://qiita.com/taketo1024/items/71e3272211f08d7e0cde 例のこのPhantom Typeのやつ、extensionで where T: Ready で書くと問題ないけど、where T == Ready で書くと Something.createInstance() の直後でも変換の補完で .shout() が出るのなんで？（もちろんコンパイルエラーにはなるけど…）

Swift で Phantom Type (幽霊型) - Qiita

社内の「Scala 勉強会」で Phantom Type (幽霊型) という厨二心をくすぐる感じのデザインパターンを教えてもらったので、同じことを Swift でもやってみました。インスタンスの状態を変数ではなく **型パ...

1:33 PM

これのせいで微妙に辛いのはStatusがstructで作りにくい…

@omochimetaru おもちのgysb、他のファイルにあるSwiftのメソッドとか呼べる？

呼べません

3:16 AM

呼びたい？

3:17 AM

いまは変換して作られたswiftコードを $ swift generate.swift で実行しているだけなんや。

僕が普段gyb使うケース、gybのテンプレートからpythonで書いたSwaggerのyamlのパーサーをimportして使ってるので、それができれば嬉しみって感じ

そもそもswiftには隣においてあるファイルを読み込む機能とかないから

3:19 AM

どうやるのがいいか悩むね。

インタプリタ実行じゃ無理か

gysb側で % include "./hoge.swift" みたいな機能を追加して

無理やり展開する？

テキストとしてそのままぶち込むのはどうか

3:20 AM

古き良きプリプロセッサ

なんとなく動きそうな感じはする

issueにしとく　いまちょっとパーサーを直さなきゃいけないことに気がついたからあとまわし

3:21 AM

わしもあとでgysbのコードちゃんとよむね

いま最新コミット完全にぶっ壊れてるから一個前を見てｗ

草

ちょっと保存するのにうっかりmasterにやっちまった

0.1.0のタグ打とう

たしかに。

3:22 AM

うった

あれ、swift runが壊れた。

0.2.0 できた。

4:15 AM

%{ let intTypes = [8,16,32,64] }% % for intType in intTypes { % for sign in ["", "U"] { /// Extension that adds a few additional functionalities to ${sign}Int${intType} extension ${sign}Int${intType} { /// Returns a ${sign}Int${intType} with all ones % if sign == "" { public static var allOnes: Int${intType} { return Int${intType}(bitPattern: UInt${intType}.max) } % } else { public static var allOnes: UInt${intType} { return UInt${intType}.max } % } } % } % }

すぐ API のミスに気づいたりするから、とりあえず -alpha とか -beta つけるのオススメ。

↑これ綺麗に出力できるモアイさんの例↓ 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自体…

4:17 AM

ふむう > alpha

gyb よく知らないけれどマクロ的なやつなのか

テンプレートエンジン？

↑のモアイさんの記事読むと良いよ

4:18 AM

func readToken() -> Optional<Token> を func readToken() -> Token に変えて、 enum Token に case end を足したらすごく良くなった https://github.com/omochi/gysb/blob/master/Sources/gysb/Token.swift#L18

omochi/gysb

gysb - Generate your swifty boilerplate

よんだ

4:19 AM

なるほど

とても良いツールなんだけど

4:20 AM

pythonを書かされるという致命的な問題点があるので

4:20 AM

それを解決したのが拙作のgysbですｗ

なるほどアツい

ただ、 Python なのも良いところがあって、 Swift のコードの合間に書かれているときはぱっと見で Python の方が区別しやすいかも？

脳のスイッチングコストは結構でかいです

まあ僕はガチャガチャ複数言語書くの慣れてるけど

5:26 AM

ひらりとかそもそもパイソン書いたことなかったよね。

うん

5:27 AM

gybのために嫌々始めた

草

確かに Python を知らない人にとってはハードルが高いな。

5:29 AM

しかも end とか Python じゃないし。

イニシャライザちゃんと書かないとプロパティがあったりなかったりするのすごくキツイんだけど何か間違ってるのかもしれない

pythonになってるメリットはwindowsとかでも動くことだと思います

まあ、 Swift が動かない環境で Swift で書くツールを使おうとしないでしょう・・・。

swiftコンパイラ本体の開発はまだ動いてない環境でswiftを動かすタスクだから

5:33 AM

swiftに依存しないでswiftを作らないといけないけど

5:33 AM

たしかに、コンパイラじゃなくてswiftアプリケーションを作る場面なら

5:33 AM

swiftに依存してても問題ないですねw

コンパイラ開発であっても、プログラミング言語はある程度固まってきたらセルフホスティングになることも多いし、 gyb レベルならもう Swift でいい気がする。 (edited)

セルフホスティングになった言語って

5:42 AM

まだコンパイラをビルドしてない新しい環境に対応するときはどうすんだろ

5:43 AM

昔のC++の実装で、古いバージョンをコンパイルしてから、その古いバージョンを使って最新のバージョンをセルフコンパイルする？

一回でいけるのかな

https://ja.m.wikipedia.org/wiki/ブートストラップ問題

%E3%83%96%E3%83%BC%E3%83%88%E3%82%B9%E3%83%88%E3%83%A9%E3%83%83%E3%83%97%E5%95%8F%E9%A1%8C

セルフホスティングになると何がメリットなんだろう、コンパイラもSwiftで書かれてるからメンテしやすいとか？ Goがセルフホスティングになった時に、話題にはなっていたけど、いまいち理解できてない

その言語が、コンパイラを書くのに向いてるのであれば、コンパイラの保守性が上がると思いますでも半分はロマンな気がする・・・

ロマンいつかはセルフホスティングみたいなのはある気がする。

この言語自身で効率的にコンパイラを書け、そのコンパイラのパフォーマンスも良いのであれば、その言語のその分野での有効性を示せるとは思います。

2:47 AM

「その分野での」と書きましたが、コンパイラのコードは複雑なのでそれがキレイに書けるのは言語の記述能力の高さを示せそうだし、コンパイラにはパフォーマンスも求められるので、ローレベルからハイレベルまで幅広い範囲で有効性を示そうな気がします。そして、 Swift はまさにそれに向いている言語だと思うので、どこかの段階でセルフホスティングになってほしいですねぇ。まだ時期尚早だとは思いますが。

1

Swiftコンパイラのアーキテクチャでいうと LLVM をライブラリとしてガシガシに使っているから

2:51 AM

C++ Interop が実現されるか、もしくは、

2:52 AM

LLVMをSwift化するか・・・

https://github.com/trill-lang/LLVMSwift 完全ではないけど、LLVM ラッパ的なプロジェクトはありまっせ。 (edited)

trill-lang/LLVMSwift

LLVMSwift - A Swift wrapper for the LLVM C API (version 5.0)

マジか

3:10 AM

Authors Harlan Haskins (@harlanhaskins) Robert Widmann (@CodaFi)

3:10 AM

コダフィ氏だ

ちゃんと SwiftPM 準拠だ。

Swift 4.0.2に-swift-version 3を渡してるかどうかは #if swift(>=3.2.2) で判定。 (edited)

なるほどw > ロマン

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/041072.html

FWIW, I’m getting optimistic about moving to a forum soon.

Ted から久々にフォーラム移行についての言及。まだまだ曖昧。

早くしてほしい・・・　ログが調べにくいせいからか話題がループしてるのを感じる

7:34 AM

@hiragram include実装したよ

おっ

7:35 AM

@omochimetaru SwiftってJSONは読めるけどYAMLは読めないよね確か

なんのこっちゃ

7:36 AM

FoundationにYAMLのなんかがあるかってこと？

わしのgybのユースケースでgysbに置き換えるならgysbファイルからincludeした先でSwaggerのymlをパースする必要がある

ンゴ・・・

7:39 AM

yamlのライブラリをソースとして隣においておいて

7:40 AM

元のジェネレータで全部includeする形で対応になる

なるほろ

7:40 AM

まあSwaggerのymlをjsonに変換しちゃうのもあり

それだったらincludeいらないやんけ

いやいるよ

なんでだっけ

jsonをdictionaryにしたとしてそれをそのままテンプレート側で値取ってくるのしんどいでしょ

ああ、jsonを取り回すユーティリティがほしいのか。

そう

理解

@hiragram

はーい

https://github.com/omochi/gysb#example-1

omochi/gysb

gysb - Generate your swifty boilerplate

9:04 AM

[omochi@omochi-iMac gysb (master *+=)]$ cat Examples/include.swift.gysb %! include_code("libs/*.swift") % aaa=${aaa()} bbb=${bbb()} [omochi@omochi-iMac gysb (master *+=)]$ swift run gysb Examples/include.swift.gysb aaa=999 bbb=777

%!

9:05 AM

メタofメタ

%! と include_code を追加したのでなんとかなる

良い

ワイルドカード対応したから

おおっ

あとは試してみて

master *+= ってなんや

て思ったけどプロンプトだった

ほんとだｗ

9:06 AM

汚いスクショになってしまった。

ああ、libYAMLを使ってるYamsは使えなさげ。

swiftソースをテキスト展開してるだけなので

9:06 AM

リンクが必要だとダメですね・・・

9:07 AM

%! swift_package("Package.swift") とか定義しておくと SPM の executable として実行するような機能を作ったら対応できそう。

%{...}の中にimportは書けないのか

どんどん大掛かりになってる・・・

%{...}の中にimportは書けないのか

Swiftのimportは書けるよ。

9:10 AM

import Foundation とかはできる。

9:10 AM

swift コマンドで何もしないでも import できるものはimportできるってこと

9:10 AM

[omochi@omochi-iMac gysb (master=)]$ swift run gysb --compile Examples/include.swift.gysb func write(_ s: String) { print(s, terminator: "") } func aaa() -> Int { return 999 } func bbb() -> Int { return 777 } write("aaa=") write(String(describing: aaa())) write("\n") write("bbb=") write(String(describing: bbb())) write("\n")

9:11 AM

swiftc みたいに、途中の段階で実行を止める機能を作ったので

9:11 AM

たのしいです

9:11 AM

--parse , --macro , --compile , --render と４ステージあります

9:14 AM

swift コマンドの -Xlinker だけ指定できれば libYAML はいけるかな・・・？

gysbがライブラリになっていて、.gysbインプットから.swiftのStringを作れるAPIがあると、swift testの度に.swiftを生成する事ができる様になります。 (edited)

MSVCがソースファイルのなかに #comment(lib, "GL.h") ってかいてリンク指定できるみたいな。 (edited)

9:15 AM

https://github.com/omochi/gysb/blob/master/Sources/gysb/App.swift#L74

omochi/gysb

gysb - Generate your swifty boilerplate

Yamsは*.cをパッケージ内に持ってて、SwiftPMにClangモジュールとしてビルドしてもらってます。

いまここが、コンパイラのstdout / stderr を、そのまま垂れ流しにしちゃっているので

9:16 AM

ここをキャプチャしてやれば

.gysbインプットから.swiftのStringを作れるAPI

もいけそうです

9:17 AM

あー、Cソースも持っているのか。それはもうSPMとして全体を実行する以外無理そうだなあ

9:17 AM

ひらりの要望だけで無限にシステムが複雑になったｗ

w

いいぞいいぞ〜❗

効率悪いのが、一個のテンプレートの処理のたびに spm package つくることになっちゃって

9:18 AM

依存ライブラリを取り直しまくることになるんだよなあ

9:18 AM

いまはトップレベルで printするSwiftソースとしてコンパイルしているけど

9:18 AM

ひとつのファイルの処理結果を得る関数をもったSwiftソースとしてコンパイルして

9:19 AM

入力のテンプレートファイル全部を関数としてまとめて一個のバイナリにした上で

9:19 AM

それぞれ出力する、みたいな形にすると、それ系をまとめられるが・・・・

Xcodeで使う分にはRun Script Phaseを使えるからCLIでいいけど、SwiftPMはビルドプロセスに入れられないのがネックだね。

あ、そもそも、 gysb を SwiftPM のビルドに差し込めない問題の話ですか。

9:24 AM

そこはもう gysb と変換先の swift を両方コミットしてもらうしかないっすねえ・・・

9:25 AM

まあそれは今のgyb使ってるやり方でも同じことで(Vapor Cloudにデプロイするのに vapor build の手前に処理を差し込む方法ないのって問い合わせたらねえって言われた (edited)

vapor build ってコマンドで全てを発火するの？

ん？

9:28 AM

vapor cloud deploy するとリモートでチェックアウトして vapor build が動くんだけどその手前でコードジェネレータ動かしてもらわないと成果物コミットしてないから当然コンパイル通らない

んーっと vapor build は内部で swift build をする、みたいな感じかなと

そう

あー　リモートでデプロイするためのコマンドが手前側にあって

9:28 AM

リモートはvapor build をするのか

そうそう

うわ〜　それだと何もさせないね

9:29 AM

せめてローカルのvapor build ならオレオレbuildを叩くようにすれば手前にはさめたけど

9:29 AM

向こう側はどうしようもなさ

コミットするしかないんやろかとなって一旦デプロイ周りは棚上げしといた

でもそれだと、CSS Spriteとか

VaporのSlackで聞いたら「今は無いけど将来やりたいねそれ」って言ってた

なんか他にもいろんな前処理したいときにできなくね？

9:29 AM

あ、そういうのはコンパイル後だからなんとかなるのかな？

そもVaporアプリ自体のコンパイルに必要でなければあとでも良い気がする。

リソースはvapor buildとは別に用意したらいいのか。

そね

https://github.com/omochi/gysb/blob/master/Tests/GysbKitTest/DriverTest.swift

omochi/gysb

gysb - Generate your swifty boilerplate

10:53 AM

テストできるようになりました。

1

環境変数を使ってPackage.swiftの内容を切り替え、GYSB=1 swift testでコード生成し、swift testで生成したコードを利用する方法を思いついた。

あーたしかにテスト実行中にソースを書き出せば、、、

テストターゲットを生成用と利用用に分ける方法も考えたけど、swift test --filter Generateとテストするモジュールを制限しても全てをビルドしようとするから、未生成なコードに依存する部分がビルド出来なくてダメだった。

そうか、テストターゲットじゃないと、実行ができないのか

// swift-tools-version:4.0 import PackageDescription import Foundation let package: Package if ProcessInfo.processInfo.environment["GYSB"] != nil { package = Package( name: "Generate", dependencies: [ .package(url: "https://github.com/omochi/gysb.git", .branch("master")), ], targets: [ .testTarget(name: "Generate", dependencies: ["GysbKit"], path: "Tests/GenerateTests") ] ) } else { package = Package( name: "Example", products: [ .library(name: "Example", targets: ["Example"]), .library(name: "Generated", targets: ["Generated"]), ], targets: [ .target(name: "Example", dependencies: ["Generated"]), .target(name: "Generated", dependencies: []), .testTarget(name: "ExampleTests", dependencies: ["Example"]), ] ) }

11:19 AM

$ tree . ├── Package.resolved ├── Package.swift ├── README.md ├── Sources │   ├── Example │   │   └── BuildPhase.swift │   └── Generated │   └── vector.swift └── Tests ├── ExampleTests │   └── ExampleTests.swift ├── GenerateTests │   └── GenerateVectorTests.swift └── LinuxMain.swift

こんな感じ (edited)

11:22 AM

あ、テンプレートを別の場所に置かないとダメだ。

Package.swiftでYamsをビルドして、それを.gysbの中でインポートしようとしてるのだけど、うまくいかないな。

1:32 PM

Test Case '-[GysbWithYamsTests.GysbWithYamsTests testExample]' started. process execution failure path=[/usr/bin/swift] arg[0]=[/var/folders/kt/2mwy9b_56_7993x190pl_1fh0000gn/T/vector_49IokLMk.swift] arg[1]=[-L] arg[2]=[/Users/norio/github/GysbWithYams/.build/x86_64-apple-macosx10.10/debug] statusCode=[1] stderr= /var/folders/kt/2mwy9b_56_7993x190pl_1fh0000gn/T/vector_49IokLMk.swift:4:9: error: no such module 'Yams' import Yams ^ Test Case '-[GysbWithYamsTests.GysbWithYamsTests testExample]' passed (0.438 seconds).

$ /usr/bin/swift /var/folders/kt/2mwy9b_56_7993x190pl_1fh0000gn/T/vector_49IokLMk.swift

1:32 PM

↑これを実行しているだけだから、フレームワークサーチパス的なところで

1:33 PM

ビルド済みのYamsが見えていないと

1:33 PM

見つけられないです

とりあえずこんな感じで起動してます。

return try execCapture(path: swiftPath, arguments: [path, "-L", "/Users/norio/github/GysbWithYams/.build/x86_64-apple-macosx10.10/debug"])

(edited)

ああなるほど。

1:34 PM

ほんとだ、よくみてなかった。

1:34 PM

とりあえず、直接swiftコマンドで実行できるコマンドを

1:34 PM

見つけるのが良さそう

1:34 PM

-F <value> Add directory to framework search path

1:35 PM

.frameworkならこっちですよ。

1:35 PM

static libarryなら、 -L <value> Add directory to library link search path -l<value> Specifies a library which should be linked against これらの併用がひつよう

1:35 PM

フレームワークの場合に -l も必要だったかはよくわからない

-I…,-L…,-F…つけても、YamsのPackage.swiftでライブラリtypeを.staticや.dynamicにして-lYamsつけてもダメだ。

path=[/usr/bin/swift] arg[0]=[/var/folders/kt/2mwy9b_56_7993x190pl_1fh0000gn/T/vector_NwwoI7hu.swift] arg[1]=[-I] arg[2]=[/Users/norio/github/GysbWithYams/.build/x86_64-apple-macosx10.10/debug] arg[3]=[-F] arg[4]=[/Users/norio/github/GysbWithYams/.build/x86_64-apple-macosx10.10/debug] arg[5]=[-L] arg[6]=[/Users/norio/github/GysbWithYams/.build/x86_64-apple-macosx10.10/debug] arg[7]=[-lYams] statusCode=[1] stderr= /var/folders/kt/2mwy9b_56_7993x190pl_1fh0000gn/T/vector_NwwoI7hu.swift:4:9: error: no such module 'Yams' import Yams

(edited)

うへえ

ああ、ソースコードのパスを引数の最後に持ってきたら通った。

おお。

Yamsのlibrary typeを.dynamicにして、以下のオプションをswiftに渡したらいけた。

 return try execCapture(path: swiftPath, arguments: [ "-I", "/Users/norio/github/GysbWithYams/.build/x86_64-apple-macosx10.10/debug", "-L", "/Users/norio/github/GysbWithYams/.build/x86_64-apple-macosx10.10/debug", "-lYams", path, ])

-I と -L は両方そこでいいんですね

テンプレートはこんな感じ

% import Foundation % import Yams % guard let yaml = try Yams.compose(yaml: String(contentsOf: URL(fileURLWithPath: "TestResources/vector/vector.yml"))) else { fatalError() } % let vars = yaml.array().flatMap { $0.string } % for n in 2...4 { struct Vector${n} { % for i in 0..<n { var ${vars[i]}: Float % } } % }

これは、アプリのプロジェクトのPackage.swiftで、Yamsとgysbの両方を依存させていて、 swift run gysb が通る状態？

// swift-tools-version:4.0 import PackageDescription let package = Package( name: "GysbWithYams", dependencies: [ .package(url: "https://github.com/omochi/gysb.git", .branch("master")), .package(url: "https://github.com/jpsim/Yams.git", .branch("master")), ], targets: [ .testTarget( name: "GysbWithYamsTests", dependencies: ["GysbKit", "Yams"]), ] )

class GysbWithYamsTests: XCTestCase { func testExample() { do { let driver = Driver.init(path: "TestResources/vector/vector.swift.gyb") let actual = try driver.render(to: .render) print(actual) } catch { print(error) } } static var allTests = [ ("testExample", testExample), ] }

(edited)

なるほど

SwiftPMはライブラリプロダクトのtypeが未指定でもリンクしてくれますが、この使い方の場合、libYams.aかlibYams.dylibが無いとダメですね。

2:08 PM

type: .staticでも本当はいけると思うのですが、swiftcがクラッシュしてしまいダメでしたが。

なるほど〜

2:09 PM

SwiftPMのデフォルトは .static なんですか？

Swift 4からデフォルトではライブラリを生成しなくなりました。

ほう

ライブラリを構成する.o達を直接リンクします。 (edited)

マジか

2:10 PM

あーシンボルはパッケージで切ってるからいいじゃんってか

2:11 PM

Cとはちょっと違う世界に進みつつありますね

swift test -vとかしてみるとコンパイラの起動オプションを見られます。

2:15 PM

type: .dynamicにするとswift build --static-swift-stdlibとかしてもそれらのライブラリはダイナミックリンクされるみたいだから、今後は使い勝手が悪くなると避けられるんじゃないかな？ (edited)

うーむ、そうなんですかね Swiftが出てきたころから基本dynamic frameworkとembeddedだったから (edited)

2:18 PM

てっきりそういう思想なのかと思っていたけど

2:18 PM

最近static系のサポートも強くなってきていますね

.dynamicなライブラリを同じパッケージ内のexecutableターゲットから使う場合は問題ないのですが、依存しているパッケージから使った場合、それらはフルパスでリンクされてしまい、ポータブルなexecutableではなくなってしまいます。

$ otool -L ./.build/x86_64-apple-macosx10.10/debug/gysbClient ./.build/x86_64-apple-macosx10.10/debug/gysbClient: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1445.12.0) /Users/norio/github/GysbWithYams/.build/x86_64-apple-macosx10.10/debug/libGysbKit.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

(edited)

ふむ

前も書いたけど、 gyb でなくても Swift で Multiline String Literal が追加されたから、↓みたいな感じで大体いける気がする。これならなんでもフルに Swift の機能使える。

prefix operator > prefix func >(value: String) { print(value) } let intTypes = [8, 16, 32, 64] for intType in intTypes { for sign in ["", "U"] { >""" /// Extension that adds a few additional functionalities to \(sign)Int\(intType) extension \(sign)Int\(intType) { /// Returns a \(sign)Int\(intType) with all ones """ if sign == "" { >""" public static var allOnes:Int\(intType) { return Int\(intType)(bitPattern: UInt\(intType).max) } """ } else { >""" public static var allOnes:UInt\(intType) { return UInt\(intType).max } """ } >""" } """ } }

(edited)

2:56 PM

元の gyb は↓。

%{ intTypes = [8,16,32,64] }% % for intType in intTypes: % for sign in ['','U']: /// Extension that adds a few additional functionalities to ${sign}Int${intType} extension ${sign}Int${intType} { /// Returns a ${sign}Int${intType} with all ones %if sign == '': public static var allOnes:Int${intType} { return Int${intType}(bitPattern: UInt${intType}.max) } %else: public static var allOnes:UInt${intType} { return UInt${intType}.max } %end } %end %end

ManifestoGeneratorとか出来てる！w https://github.com/omochi/gysb/blob/master/Sources/GysbSwiftConfig/ManifestoGenerator.swift

omochi/gysb

gysb - Generate your swifty boilerplate

1

SwiftPM対応できた

5:52 AM

https://github.com/omochi/gysb/blob/master/Tests/GysbKitTest/DriverTest.swift#L25-L34

omochi/gysb

gysb - Generate your swifty boilerplate

5:52 AM

%! swift_config("gysb_swift_config.json") %{ import Foundation import Yams let yamlPath = URL.init(fileURLWithPath: "data.yml") let yamlStr = try! String(contentsOf: yamlPath, encoding: .utf8) let yaml = try Yams.compose(yaml: yamlStr)! let fields: [String] = yaml.array().map { $0.string! } }% struct Data { % for field in fields { var ${field}: String % } }

5:53 AM

json

{ "packageDependencies": [ { "url": "https://github.com/jpsim/Yams.git", "requirement": { "identifier": "0.5.0", "type": "exact" } }, ], "targetDependencies": [ { "name": "Yams" } ] }

おお、すげー！

実行時に複数ファイル指定した場合は、一つのSwiftPMターゲットにまとめるから、Yamsの取得やビルドは共有されるただし、 %! swift_config() の指定は１ファイルだけがする。

@omochimetaru 使う側はどこで Package.swift 指定するの？コマンドオプション？

↑にはったjsonを書く。

ああ、↓に書くのか。 %! swift_config("gysb_swift_config.json")

昨日僕が無理やりswiftのコマンドラインオプションでやってたことを、全部SwiftPMへ丸投げしたということですね。

ですね　SPMのワークスペースを作って、execターゲットのmain.swiftを生成するようになりました

@omochimetaru Package.swift 的に、 gybs.json をディレクトリにおいておけば自動的に反映とかが良くないかな？そうすれば gysb ファイルに余計なものを追加しなくて良くて、gyb を Swift にしただけという体を保てそう。 (edited)

6:02 AM

ただし、 %! swift_config() の指定は１ファイルだけがする。

これも結構罠になりそう。

6:02 AM

a と b で同じライブラリが必要だけど、 a だけ、 b だけ、 a と b 同時に、って gysb に渡すときに全部サポートすることができなさそう

ディレクトリにおいておくっていうのが悩ましくて source/fooModule/foo.swift.gysb source/barModule/bar.swift.gysb ってなってるときに $ gysb source/fooModule/foo.swift.gysb って指定すると、 gysb.json はどこにあるんだ？ってなっちゃうんですよね

source/fooModule/gybs.json じゃないかなぁ

6:05 AM

それか、Package.swift と同じ階層におくことにするか。

それは場合によっていて、 source/ ** / * .gysb をドカンとツリー変換したい場合もあるだろうから

%! import("https://github.com/jpsim/Yams.git") とかするとswift_config()に渡すjson相当のものが自動で生成される様にするとか。

$ gysb --config source/gysb.json source/fooModule/foo.swift.gysb こういう感じはできるけどコマンドラインを長くしたくない・・・

↑それだとファイルとライブラリの関係を示せない

これも結構罠になりそう。 a と b で同じライブラリが必要だけど、 a だけ、 b だけ、 a と b 同時に、って > gysb に渡すときに全部サポートすることができなさそう

configが同じファイルならOKにするか

利用側がどの gysb.json を使えばいいかわからないから

同じconfigになっているソースがまとめて指定される限りOK

6:07 AM

これだとソースが自己言及的にできる

対象となる gysb ファイルから遡って、 Package.swift と同じ階層までの gysb.json を適用するとかどう？ (edited)

6:08 AM

ああ

6:08 AM

そうか

6:08 AM

別に Swift 限定じゃないから

%! import("https://github.com/jpsim/Yams.git") とかするとswift_config()に渡すjson相当のものが自動で生成される様にするとか。

これの問題点は、パッケージ名からターゲット名がわからないこと

6:08 AM

そう、あと、生成テンプレートはSwiftに依存させたくないから

6:08 AM

Package.swiftを探すとかは　マッチしない場合も多そう

なるほど。

gyb って import 使えるんだっけ？

6:09 AM

使えるなら参考にできるかも？

つかえます

gybは使えますね、pythonの言語機能のimportが使える。

たとえば、パスの通ってるところに

Swiftのimportはファイルパス的なしくみじゃないからできない。

Foo.framework を置いてある前提にするとか？

6:10 AM

あー,

6:10 AM

Swift PM に乗っかって実行してるんだっけ？

そうそう。

それなら無理か。

6:10 AM

お、じゃあ

libSwiftPMが気軽に使えれば「リポジトリからPackage.swiftを解釈して〜」とか簡単に出来そうなのに… https://github.com/apple/swift-package-manager/blob/master/Package.swift#L19

apple/swift-package-manager

swift-package-manager - The Package Manager for the Swift Programming Language

gysb を実行したディレクトリが対象となるファイルの先祖ディレクトリの場合、

6:11 AM

対象ファイルのディレクトリからカレントディレクトリまで遡って探すとかは？

SwiftPMにgysb機能を載せた方が早そうな気がしてきた。

そうすれば SwiftPM 対応のリポジトリで、リポジトリのルートに gysb.json おいて一括実行とかもできる

現状の仕様で、テンプレート側から

6:13 AM

gysb.json を指定していれば

6:13 AM

それでスッキリしてません？

6:13 AM

探索するとかは、Swift以外の利用時に無駄な処理になるし

6:13 AM

カレントディレクトリの影響をうけずにコマンドラインだけで一貫した結果がいい

@omochimetaru これを swift リポジトリ本体に組み込むことを目指すなら、できるだけ gyb に寄せておいた方が受け入れられる気がして、余計なものを付けない方がいいかなぁと。

6:14 AM

↓この記法一つで議論の余地がいくらでもあると思うので。 %! swift_config("gysb_swift_config.json")

Swift本体に組み込む事は目指してなかったですね、Swiftソース以外の生成も前提にしているから、そこで設計方針がかみあわないのか

6:15 AM

個人的にはC++の生成にも使いたいのです

Swiftのコンパイル時にSwiftが必要になるから、gybの代替にはなれない気がする

セルフホスティングはまだ早いと思いますが、gyb 程度の用途だったらいけそうな気も。

Swift本体とは独立したテンプレートエンジンとして存在してもらうほうが使う側としては嬉しみ

↓この記法一つで議論の余地がいくらでもあると思うので。

そうですねえ、ここにマイクロ言語が必要になっているのは微妙ではある

独立して使えるけど、それを swift リポジトリでも使うという状況を想定してます。

brew install gysbできる様になると良いね。

いま %! swift_config 以外に %! include_code っていうマクロ命令もあって

それはしたい < brew

それで他のSwiftソース（テンプレートロジックの方)を取り込んだりできるんですが

6:18 AM

この機能のためにどうしてもミニ言語が必要に。

include_code はカオス度が増しそうだなぁ。

https://github.com/omochi/gysb/blob/master/Examples/include.swift.gysb

omochi/gysb

gysb - Generate your swifty boilerplate

6:18 AM

↑例

6:19 AM

"libs/*.swift" に書いてある func aaa() {} と func bbb() {} がここにテキスト展開される。

色々な機能を入れると混沌とするから、必要最小限なものをシンプルに保つのが良さそうな。サードパーティライブラリが使いたいのはわかるから、そこはなんとかするとして。

Swiftがスクリプティングサポートを充実して

6:20 AM

ソースコードの相対パスimportができれば

6:20 AM

こんなものはいらなかったんだ

gysb の実行を Swift PM に依存しない方法はないかな？

さっきのYamsの例(Swift製YAMLライブラリ）だけみても

6:21 AM

かなりきついですね

6:21 AM

Cソースとかも絡んでいるので。

swift コマンドで Framework のパス指定して実行できなかったっけ？

6:21 AM

ライブラリのビルドは Swift PM でやるとして

その辺り、昨夜僕が試しました。

gysb が生成したコードの実行を Swift PM に依存しない

Frameworkがdynamicかstaticかで渡し方が変わったり

結論としては、ライブラリの配布元でのPackage.swiftによりswiftコマンドラインオプションの指定方法とか変わってくるので、めんどい。

あと、>ライブラリのビルドは Swift PM でやるとして SPMの.buildから生成物を手で取ってくるっていうのは不便だと思います

うーん、それならやっぱり gysb.json を gysb ファイルと同じ階層においておくだけってのはわかりやすいと思うけどなぁ。

6:24 AM

一括実行は諦めるか、 SwiftPM 対応リポジトリの場合だけ Package.swift と同じ階層も見るとか。

6:25 AM

あとはコマンドラインオプションで指定もできるくらいかなぁ。

一括実行を諦めると

6:25 AM

Yamsなどの重い依存を

6:25 AM

何回も取得・ビルドすることになって

6:25 AM

かなり動作が遅くなってしまう

えっと、それは swift_config 書く場合と同じで

6:26 AM

gysb.json は各ディレクトリに置くけど

6:26 AM

一度に実行した場合はビルドは一度とかでいいんじゃない？

6:27 AM

指定を gysb ファイルの中に書くか json ファイルの有無でやるかだけの違い。

6:27 AM

gysb Sources/Foo/*.gysb Sources/Bar/*.gysb

たとえば src/foo/a.swift.gysb src/foo/b.swift.gysb src/foo/gysb.json src/bar/c.swift.gysb src/bar/d.swift.gysb src/bar/gysb.json こうなってるときに $ gysb src/ こう実行したら

6:28 AM

ああ、これは衝突するから一緒にはできませんよって

6:28 AM

今と同じルールにするということか

うん。解決ルールは今と変わらないはず。

src/fooとsrc/barをまとめて変換したければsrc/gysb.jsonをおくと

設定が同じ場合、 gysb をすべてのディレクトリにコピーしてまわるか、すべてのファイルの先頭の行に書くか程度の違い。

6:29 AM

gysb src/ で再帰的にgysb さがすの？？

はい　それはまだ対応してないけどやるつもり

再帰は gysb -r src/ とか明示的にした方が良さそうな気も。

ああ、そうですね。

6:30 AM

$ gysb --source-dir src

6:30 AM

こういうイメージ

再帰指定のときはその過程の gysb.josn も全部適用で良さそう。 (edited)

あ〜

6:31 AM

gysb.jsonごとに実行を分割すればいいのか

6:31 AM

ていうかそれファイル複数のときでも一緒だな

6:32 AM

入力されたファイルごとに対応するgysb.jsonがあって、gysb.jsonごとにグルーピングしてそれぞれ実行すれば良いのか。

うーん、それってでも複数 gysb.json で同じライブラリが指定されてた場合、多重ビルドにならない？そこは頑張って回避？

複数gysb.jsonをマージしてビルドすることは考えてなかった

ん？だって gysb Sources/Foo/*.gysb Sources/Bar/*.gysb みたいなことがしたいんじゃないの？

↑の例なら、 Sources/gysb.json が置いてあればうまく動くけど

6:34 AM

Sources/foo/gysb.json と Sources/bar/gysb.json が置いてある場合

6:34 AM

一つのビルドにはできない

6:34 AM

という想定でした

6:35 AM

実際、違うライブラリだけど同じターゲット名、とかが出てくるとマージしようもないし。

マージして重複排除でライブラリビルドして、実行はディレクトリ単位にすれば競合があっても解消できそう。

6:35 AM

親と子で競合したらダメだけど。

実行はディレクトリ単位っていうのはどういう意味です？

ディレクトリの gysb.json を見る方式だと、ディレクトリ単位でしか指定できないから。

ディレクトリ単位にした時点で実際のSwiftPMワークスペースがばらばらになるから

6:36 AM

ライブラリが共有できないです

swift_config を導入せずに gysb.json を置く方式にするのであれば、一つのディレクトリの中で設定を切り替えることはできないという意味です。

6:37 AM

逆に言うと、同じディレクトリの gysb ファイル同士では設定（ライブラリ）が競合することはない。

マージして重複排除でライブラリビルドして、

6:37 AM

このマージするっていうのは

6:38 AM

同じgysb.jsonファイル同士を (edited)

6:38 AM

同じものと検出するってことを言っている？

複数の gysb.json の中に書かれた同じバージョンに解決される同じライブラリを重複ビルドしないようにするということを言ってます。

6:39 AM

あー、でもバージョンの解決は Swift PM がやるから無理か。 (edited)

6:39 AM

完全一致くらいなら排除できそうだけど・・・

Sources/foo/a.swift.gysb Sources/foo/b.swift.gysb Sources/foo/gysb.json Sources/bar/x.swift.gysb Sources/bar/y.swift.gysb Sources/bar/gysb.json こうなっているときに

6:40 AM

a.swift.gysb と b.swift.gysb を、一つのPackage.swift でビルド x.swift.gysb と y.swift.gysb を一つのPackage.swiftにしてビルド (edited)

6:40 AM

っていうふうにすることを考えているけど

6:41 AM

foo/gysb.json と bar/gysb.json をマージして、ライブラリをまとめてビルドするのだとして、

Package.json は Package.swift の間違い？？

その場合、Package.swift は1つで、そこに、a.swift.gysb , b.swift.gysb , x.swift.gysb, y.swift.gysb が所属して、コンパイルするってイメージですか？ (edited)

6:43 AM

その考えはわかって、最初そういう意味だと思ったんですけど

実行はディレクトリ単位にすれば競合があっても解消できそう。

その場合この「実行はディレクトリ単位」の概念がわからなかった。

そうかー、ビルドを Swift PM に依存してる時点で同一ライブラリであっても Package.swift 間で共有できないのか。 .build 以下をコピーする処理をいれれば共有できるかもだけど。

ああ、異なるPackage.swiftがあるけど依存ライブラリのバイナリは再利用することを想定していたんですね

6:44 AM

それはSwiftPMの仕様上うまくできなそうと考えています (edited)

そうです < 異なるPackage.swiftがあるけど依存ライブラリのバイナリは再利用することを想定していたんですね

SwiftPMは結構細かいことを中でいろいろやっているので

6:45 AM

あんまり途中成果物のバイナリを触って何かするっていう系は

6:45 AM

うまくいかなそうだなあと思ってます

6:46 AM

昨日 @norio_nomura がいろいろ試した結果もそう思った

そもそも依存ライブラリの作りによっては、ライブラリのバイナリが生成されない。 (edited)

ああ、それもありましたね。

6:46 AM

それが一番ビックリしたんだった。

うーん、そしたら、

foo/gysb.json と bar/gysb.json でそれぞれ Package.swift 作って2回ビルドでいいと思いますよ。

↓ 2 回実行 Sources/Foo/gysb.json Sources/Bar/gysb.json

Sources/gysb.json だけにしてけば 1回ビルドにできるのだし。

↓ Souces/gysb.json と Sources/Foo/gysb.json をマージ、 Souces/gysb.json と Sources/Bar/gysb.json して 2 回実行 Souces/gysb.json Sources/Foo/gysb.json Sources/Bar/gysb.json

6:49 AM

（差分だけを Foo/gysb.json 等に記述することを想定）

6:50 AM

↓ Foo, Bar 以下のすべての gysb ファイルに対して 1 回で実行 Souces/gysb.json

6:50 AM

とかかなぁ。

6:50 AM

もちろん recursive 指定の場合。

そもそもそんなにSources/gysb.json と Sources/Foo/gysb.json で何か分割定義したいと思わないと思うんですよ

6:51 AM

あくまでメタプログラミングのためにつかうライブラリだから

そうですね・・・

FooではYAMLを読むしBarではXMLを読むからっていって

6:52 AM

別に Sources/gysb.json で YAML と XML 両方のライブラリぶち込んでおいて

6:52 AM

それでFooの管理上困るってことも無いと思う。

6:53 AM

それは要望が出てきてから考えるとして、とりあえずは gysb.json 一個に対して 1 Package.swift で良いと思う

6:54 AM

それはそれとして、 %! swift_conifig はやめてディレクトリ遡り探索の gysb.json にしようと思います

6:55 AM

そのほうが同じgysb.json 配下の gysbテンプレート達に対して、特定のファイルだけ変換するってことができる。

6:55 AM

swift_config 方式だと全部にその指定を書かないといけないからめんどくさい

お、いいですね < %! swift_conifig はやめてディレクトリ遡り探索の gysb.json にしようと思います

6:55 AM

include も廃止？

include は必要だと思う。

むー

ちょっと共通のメタプログラミング用の関数とかは生える事が結構あって

6:56 AM

でもそれをわざわざSPMパッケージにしてリポジトリをわけるのは

6:56 AM

面倒な場合があるだろうから、その場で結合できたほうが良さそう

6:56 AM

あ、でもあれか

6:56 AM

gysb.json で

6:57 AM

結合するファイル達として指定できるようにするという手はあるな。

6:57 AM

同じ理由でincludeを全部に書くのは面倒だから。

その方が %! という複雑性を持ち込まなくてよさそう。

そうですね

どちらかというと include したいのはテンプレートそのものの include だと思うけど

6:58 AM

（ HTML 生成するときのヘッダー、フッターとか）

6:58 AM

それも関数化して gysb.json で指定でできるかな？

テキストのinclude 、コード ( % { } の内側 ) のinclude、テンプレートのinclude

6:59 AM

の３種類がありえるとおもったので今は include_code () だけがあるんですが

6:59 AM

テンプレートのincludeにした場合、それ自体は、 %{ } で包まれた中にswiftコードを書いたファイルになるんですが

7:00 AM

それが swift ファイルにならない (構文上) .swift.gysb になってしまう

↓とかできるんだっけ？ % func foo() { FooFooFoo % } % for _ in 0..<3 { % foo() % }

というのが微妙だなあと思っていて

7:00 AM

できますね

↓結果 FooFooFoo FooFooFoo FooFooFoo

そうなるはず。

7:00 AM

で、swift.gysb になっちゃうと、再帰実行とかで巻き込まれるんですよね・・・

よくわかりません・・・

gysb.jsonの中に記述できる様にしてしまうとか。

jsonの中にswiftを書くのは辛いと思います

yamlならいけるかな

えっと、 include_code で取り込まれるファイルは

7:03 AM

それ単体でvalidなswiftソースです

yaml ならいけるかもしれませんが、 gysb の実行に YAML パーサが必要になって依存が生まれてしまいそう・・・

func taxRate() -> Float { return 1.08 }

7:04 AM

とかこういうファイルなわけです。

なるほど、何でもテキストを展開するというわけではないのか。

でも、 @koher のいうように、テンプレートをインクルードする機能だとしたら

7:04 AM

%{ func taxRate() -> Float { return 1.08 } }

7:04 AM

こういうファイルを用意することになって・・・

7:05 AM

このファイル名は metalib.swift.gysb とかになる。

7:05 AM

で、さっきの Sources の例でいえば

7:05 AM

Sources/foo/a.swift.gysb // こいつがそれを読みに行く Sources/foo/metalib/metalib.swift.gysb

7:05 AM

たとえばこういうファイルツリーにしたくなると思います。

7:06 AM

で、さっきまでの議論を前提に考えて、 $ gysb --source-dir Sources を実行すると・・・

7:06 AM

Sources/foo/metalib/metalib.swift.gysb が処理対象になって、自分を自分の上部にincludeしようとして、無限ループして壊れる。

そういうことか。

これは困ったな、という話です。

7:07 AM

今の仕様であれば、インクルードするのはテンプレートではなくでコードなので、 Sources/foo/metalib/metalib.swift が置かれているけど、これはgysbの実行には関与しないのでうまくうごく。

foo/gysb.json に metalib の include を記述とか？

再帰探索で metalib.swift.gysb が見つかったときに、これはinclude用だから処理対象からはずそう、　っていう制御をするってことですか？

うーん、 gysb から読み込む swift ファイルおくとかは Swift PM で壊れたりしないかな？ディレクトリ分けておけば Package.swift でコントロール可能？

7:09 AM

@omochimetaru はい。 include 用のディレクトリを明記するとか。

ターゲットを分けちゃうと public にするとかいろいろ出てきて面倒なんで、シンプルにテキストとして結合されるのが便利な気がします

7:10 AM

いま想定してるのはさっきの func taxRate() みたいな、ちょっとしたやつ。

Swiftファイルを読み込むってのは微妙そう。インクルードされるファイルは gysb でも swift でもないべきでは？

7:12 AM

gysb.gysb とか？

テンプレートだけどインクルード用としてわかるようにする、っていう手はありますね

7:12 AM

拡張子を gysbi にするとか。

ネスト数が必要かと思ったけど、起点を gysb にすればいいだけだから特に問題ないか。

7:13 AM

gysbi が gysbi を include するような場合でも

それは大丈夫ですね。

でも gysb だとマズイよね。ディレクトリで再帰的に指定されるような場合、インクルード用ファイルも単独で展開されちゃう。

gysbi が gysbi を include する

これは、ファイルの中に include 命令が書けるってことになってるとは思うけど・・・

7:14 AM

拡張子が gysb だと面倒なことになりますね

7:14 AM

gysbi が良さそうだなあ。

7:15 AM

template の include なのであれば

テキストで include する機能だったら、どのラインに展開するかも重要だから %! 的な構文は避けられなさそう。

テキストを注入する効果もあるわけなので

7:15 AM

そうそう。

ってか、 gysb 以外なら拡張子なんでもいいのか。

まあそうです。

7:15 AM

includeを考えていくと %! から逃げられないですね

7:15 AM

まあgybはそれはできないですけど。

%! include("path/to/file") の行をそのファイルの中身で展開するだけ。

gybはメタpythonとしてのimportがあるだけだからテキストのincludeはできない

Jekyll の include の構文は↓ {% include footer.html %}

7:18 AM

このパスに変数使えたりする {% include {{ page.my_variable }} %}

7:18 AM

ここまで来るとさらにメタになるけどカオスかな？

7:18 AM

んー、でも

7:19 AM

↓とかもあり得る？ % for i in 0..<10 { %! include("file\(i).gysbi") % }

現状は %! のマクロ言語はテンプレート処理系の前段にあるとしています

7:20 AM

CコンパイラとCプリプロセッサの関係と一緒

7:20 AM

現実的に↑は無理で、なぜなら、

7:20 AM

Swiftとしてのコンパイルをして実行して

7:20 AM

でてきたものを再びテンプレートとして処理するっていうふうに

7:21 AM

Swiftコンパイル実行が何回も繰り返されるモデルになるので

include を関数として実装できないかな？

実行も遅いし変なことになったときわけがわからなくなりそう。

7:21 AM

テキスト注入する関数としては実装できますが

ファイルを読み込んでその内容を write する

いまやりたいのはSwiftのメタライブラリを提供するシナリオだから

7:21 AM

includeをコンパイルする時点でコンパイルエラーになって駄目ですね

そうだなぁ。

include_text: Swift上で実装できる include_template: Swiftコンパイル前に処理しないといけない

Swift の関数を読み込むことはできないけど、テンプレートを読み込むことはできるんじゃない？ gysbi ファイルに対して gysb を実行して得られた文字列を挿入すれば。

7:25 AM

Jekyll はそっちの挙動だと思う。

gysbコマンドを実行して結果を注入するってことですか？

はい。

それはまあできるけど、Swiftの関数を読み込みたい・・・

関数読み込みは gysb.config で記述できそう。

7:26 AM

個別に Swift ファイルのパスを指定するだけで。

そうですね。

7:26 AM

機能としては現状の %! include_code を

Swift ファイルは gysb じゃないから無限再帰問題もないし。

jsonにgysb.jsonに書くようにするってことですね

はい。

それはありだと思います。

7:27 AM

テンプレートを読み込みたいっていったのは @koher だし・・・

テンプレートエンジンとしてはその機能はほしいかと思ったけど、とりあえずなしでいいと思います。複雑化するし。

7:27 AM

そうすれば %! も排除できる。

そうですね > %!

7:29 AM

しばらく離席します

brewのバイナリ配布、sourceryがSwiftPMでビルドしたものを使ってる。 https://github.com/Homebrew/homebrew-core/blob/master/Formula/sourcery.rb

Homebrew/homebrew-core

homebrew-core -

Default formulae for the missing package manager for macOS

7:32 AM

実行環境のSwiftバージョン依存を減らせるから、バイナリ配布はそのうち必要。

@mono さんも LicensePlist を brew で配布してたような。 (edited)

PR来て途中まで対応しつつ、実はまだ対応できてないです(　´･‿･｀)

1

7:35 AM

音信不通に: https://github.com/mono0926/LicensePlist/pull/70#issuecomment-322085272

Support CocoaPods by simorgh3196 · Pull Request #70 · mono0926/LicensePlist

Issue: #52 I hope I can install this library with CocoaPods. I tried installing with CocoaPods by referring to SwiftLint etc. I did not actually register with CocoaPods, so I can not confirm whethe...

配布手続きはそれほど難しくないです。 (edited)

PR や issue で音信不通悲しいですね

分かれば簡単そうとは思いつつ、初めてだとそれなりに手間取りそうと思って敬遠しちゃっていました

7:37 AM

その後1回も突っついてないだけなので、何かしらアクションすれば続きできそうですが(あるいは自分で続きやっても良いですが)

7:38 AM

あ、完全に勘違いしていました。

7:38 AM

brewはやってます。

7:39 AM

CocoaPods配布が途中でした

7:40 AM

でも、brewもバイナリ配布ではなくビルド必要な形式にしちゃっています。 https://qiita.com/mono0926/items/c32c008384df40bf4e41 (edited)

Swift Package Manager(SwiftPM)で作ったコマンドラインツールをHomebrewに登録する方法 - Qiita

mono0926/LicensePlist という、Carthage・CocoaPodsおよび手動指定ライブラリから、iOS設定アプリに載せられ...

1

LicensePlist は CocoaPods でインストールしているライブラリのライセンス情報の生成には対応しているけど、 LicensePlist 自体の CocoaPods でのインストールが未対応ってことですか？

そうです。

SwiftPM や Carthage と比べると複雑ですよね・・・

Homebrewでのバイナリ配布は途中までやりかけたものの少し面倒そうと感じていたところに ishkawaさんからこうリプライいただいて、省略しちゃいました。 https://twitter.com/_ishkawa/status/863662412196597760?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fqiita.com%2Fmono0926%2Fitems%2Fc32c008384df40bf4e41

ishkawa (@_ishkawa)

@_mono それは試したことないですね。自分はbrewで入ればなんでも良いか〜って思ってCarthageの真似で済ませちゃいました。

Swift 界隈以外に使ってもらうためのツールならバイナリ配布した方がいいかも？

成果物がiOSアプリ用なので、その辺りはあまり問題ないかもです。

LicensePlist は大丈夫そうですね。 gysb はバイナリも要りそう。

あ、なるほど、そちらはそうですね。

7:47 AM

あと、LicensePlistの場合は、Swift 4対応するとまだXcode 8メインで使っている人がビルドできなくなっちゃうのでそのケアのためにまだ3のままです

ああ、tapにしたのですね。>ビルド必要な形式

tapかどうかってビルド必要とは関係なかったような？？ bottles対応を省いたからビルド必要、という認識でした。

bottles対応ってオプトインだったかな？勝手にビルドされてた様な…

bottles do ... end にバイナリの置き場所書けば対応で、省略すればインストール先でビルド必要な認識でした。 (edited)

7:52 AM

https://qiita.com/mountcedar/items/f10161d4e483aa8c1283#バイナリインストール

Homebrewで自作のプロジェクト（ライブラリ）を公開する - Qiita

はじめに

Homebrewは自作のライブラリを公開することが割と楽な機能を提供してくれている。しかしながら、その作業全体についてちゃんと書いてくれているブログが少ないので、備忘録として自分の作業を晒しておく。なお、自分のgi...

gysbはテンプレート言語がswiftで、テンプレートを描画するためにswiftのビルド実行をしているので

7:52 AM

gysb自体がビルドできない環境ではgysbを使うことができないと思います

gysbをビルド出来るswiftバージョンと扱うテンプレートに書かれたswiftバージョンが違う場合に、バイナリ配布だと回避できるよね、と。

たしかに・・・

https://github.com/Homebrew/homebrew-core/ へのformula PRは、CIがビルドに成功したらボトリングしてくれます。まあ、tapでも自前でボトリングすればバイナリ配布は出来るのかな。

Homebrew/homebrew-core

homebrew-core -

Default formulae for the missing package manager for macOS

あ、なるほど、前者を知らなかったです。後者でやろうとして面倒で一旦省略しました。

[swift-evolution] update on forum Ted Kremenek via swift-evolution The decision to move to a forum was announced a while ago, and it hasn’t appeared yet. I think we will be making the move soon and I wanted to provide some reasons why it was delayed and what comes next. ... My hope is that process will start in December.

@koher gysb.json と include_files 機能できました。マクロ機能を排除できました。アドバイスありがとうございました。

1

yaml ならいけるかもしれませんが、 gysb の実行に YAML パーサが必要になって依存が生まれてしまいそう・・・

一応書いておくと、YamsはCodableをサポートしたYAMLパーサです。Yams自身には外部ライブラリ依存はなくて、利用実績としてはSwiftLintが.swiftlint.ymlのパースに使っています。

gysb.jsonではなくgysb.ymlも書けたほうが良いですかね？手書き想定ファイルだしそうかな

@norio_nomura gysb から Yams 等への依存が生まれるという意図でした。依存自体は悪くないんですが、なくせるならなくした方が望ましいとは思うので。

1

CIができたから次はHomebrewじゃい、と思ったが、monoさんの記事読んで、なんかめんどくさそうだな・・・って気分

1

改めてmonoさんの記事を読んだけど、tap作る手順は面倒いね。homebrew-coreへPR出す方が簡単なのでは…

1

それぞれの長所短所あまり把握し切らず、何となく最近のはtapが多いかな？？と思いつつそっちにしました。 (edited)

12:09 PM

Vaporとかもtapですね(　´･‿･｀)

12:10 PM

https://docs.vapor.codes/2.0/getting-started/install-on-macos/

とりあえずtapならオレオレで勝手にできるから楽そう

https://twitter.com/_ishkawa/status/863658235869265920

ishkawa (@_ishkawa)

@_mono 初回は苦戦した記憶がありますが、1度やれば簡単だった気がします。参考になるかわかりませんが、当時のメモを貼っておきますね。 https://t.co/OBZtRlwl1S

12:15 PM

そういえば、あまり深く考えずにこれをベースにした、というのがtapにした大きな理由でした(　´･‿･｀)

なるほど

https://t.co/OBZtRlwl1S

やべえ・・・

12:16 PM

ちょっと変えるだけでタグのプッシュとtarのDLとハッシュの計算が必要や・・・

https://github.com/mono0926/LicensePlist/blob/master/release.sh

mono0926/LicensePlist

LicensePlist - A license list generator of all your dependencies for iOS applications

12:18 PM

そのあたり苦手ですが、がんばって書きました

https://github.com/Homebrew/homebrew-core/fork を開いてforkして、remote登録: $(brew --repository homebrew/core) git remote add omochi https://github.com/omochi/homebrew-core.git したら、次のコマンドでformula作成: brew create https://github.com/omochi/gysb/archive/0.8.6.tar.gz して、出来たgysb.rbのdepends_on, def install, test doを https://github.com/Homebrew/homebrew-core/blob/master/Formula/sourcery.rb 辺りを参考に設定して、 brew install --verbose --debug gysb でインストールテストして、

cd $(brew --repo homebrew/core) git checkout -b gysb git add Formula/gysb.rb git commit git push https://github.com/omochi/homebrew-core/ gysb

してPR、って感じかな？

Build software better, together

GitHub is where people build software. More than 25 million people use GitHub to discover, fork, and contribute to over 71 million projects.

Homebrew/homebrew-core

homebrew-core -

Default formulae for the missing package manager for macOS

1

12:18 PM

Makefileとか不要。

12:19 PM

class Gysb < Formula desc "Generate your swifty boilerplate" homepage "" url "https://github.com/omochi/gysb/archive/0.8.6.tar.gz" sha256 "139fd7225442c74e943b32716158a3ea5bd438241372a3cf913fd5313793248e" depends_on :xcode => ["9.0", :build] def install system "swift", "build", "--disable-sandbox", "-c", "release", "-Xswiftc", "-static-stdlib" bin.install ".build/x86_64-apple-macosx10.10/release/gysb" end test do # `test do` will create, run in and delete a temporary directory. # # This test will fail and we won't accept that! For Homebrew/homebrew-core # this will need to be a test that verifies the functionality of the # software. Run the test with `brew test gysb`. Options passed # to `brew install` such as `--HEAD` also need to be provided to `brew test`. # # The installed folder is not in the path, so use the entire path to any # executables being tested: `system "#{bin}/program", "do", "something"`. system "true" end end

bin.install はなんですか？

https://docs.brew.sh/Formula-Cookbook.html を見ると大体わかる。

Formula Cookbook

The missing package manager for macOS

2

12:23 PM

PR開くとチェックリストがテンプレートに載ってるので、追加でそれらに載ってるテストが必要。

ユーザー増えてきたら本家入り考えることにします

一度掲載されたら、次回バージョンアップからはコマンドライン1発でPR開くところまでいけたはず。 https://github.com/realm/SwiftLint/blob/master/Makefile#L114

realm/SwiftLint

SwiftLint - A tool to enforce Swift style and conventions.

なるほど。それは楽だ。。

PRはこんな感じ。 https://github.com/Homebrew/homebrew-core/pull/20522

swiftlint 0.24.0 by jpsim · Pull Request #20522 · Homebrew/homebrew-core

Created with brew bump-formula-pr.

12:30 PM

マージされるとCIがボトル登録 https://github.com/Homebrew/homebrew-core/commit/6d2b793c15e3aef701a6d256035114ff79bca7f1

swiftlint: update 0.24.0 bottle. · Homebrew/homebrew-core@6d2b793

12:35 PM

上で書いたFormulaはtest doにsystem "true"とか書いたけど、そこは真面目に書き換えないといけない。

12:36 PM

テストはsandbox環境下で行われるので、sandboxで動かない機能をテストしたりすると失敗する。

12:38 PM

sourceryの場合は期待したバージョンをsourcery --versionで返すかどうか、かな。

ふむふむ

あ、sourceryはsandboxのせいで、本来のテストが出来てないみたいだな。本来のテストは真面目にコード生成してる。 https://github.com/Homebrew/homebrew-core/blob/master/Formula/sourcery.rb#L32-L54

Homebrew/homebrew-core

homebrew-core -

Default formulae for the missing package manager for macOS

12:47 PM

gysbのテスト記述はこれを参考に出来そう。

なるほど brew と ruby の道具で書いてありますね

この辺りが自前tapリポジトリを使ったとしても通用するのかどうかは知らないです。

12:52 PM

homebrew-coreもtapなので、いけそうな気もしますが。

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

#server-side チャンネルがいいかも

あったそんなチャンネル！

https://github.com/google/swift

google/swift

swift - The Swift Programming Language

朝見たけどまだ何もなさそうだった

何が起こるんだろう・・・

Android対応とかですかねえ

うーん、 Android は Kotlin 採用したし、 Swift だと JVM で動かないし、違いそうな気がするなぁ。 Chris Lattner がらみかな？

http://twitter.com/omochimetaru/status/931340066592403457

おもちメタル (@omochimetaru)

GoogleのSwift fork、本家に Fuchsia OS 対応のプルリク投げてる https://t.co/jPsh9Kvi0h

https://en.wikipedia.org/wiki/Google_Fuchsia

Google Fuchsia

Fuchsia is a capability-based, real-time operating system (RTOS) currently being developed by Google. It was first discovered as a mysterious code post on GitHub in August 2016, without any official announcement. In contrast to prior Google-devel...

https://bugs.swift.org/browse/SR-6103 この前投稿した LoE のバグが解決された　よかった

ズル

tarunonのバグは・・・

なんだと

3:44 AM

https://bugs.swift.org/browse/SR-6126

3:44 AM

https://bugs.swift.org/browse/SR-6304

3:44 AM

返事がほしいでござる

@omochimetaru Assignee 担ってるけど、何かアクションを求められてるの？

あれ、ほんとうだ

勝手に直せやだったらウケる

いま resolved だけど、 closed に俺がするんか？

3:45 AM

コメント欄で聞いてみる

僕の唯一のResolvedは担当者無しやで

3:48 AM

適当なんちゃう?

3:48 AM

そもそもそれも明らかに治ってるのに音沙汰なかったからこれ治ってるよね?って聞いたら解決済みになったやつ

6126は CC joe groff ついたけど 6304については完全に無だね

感情が消えた

投票しておいた

6126はそもそも変性のルールがほこ×たてしてるからなぁ

3:50 AM

ほこたてで変換したら変なのでた

動作確認はしたの？>Assignee

いや、まだです

3:53 AM

Tracking internally as rdar://35215926. ↑こうなっちゃった時点で

3:53 AM

それについて再現テストがたされたのかとか

3:53 AM

よくわからんのですよね

3:54 AM

僕が確認することより再発防止のためにテスト追加することが一番大事だと思うんですけど・・・

PRではテストが追加されてるみたいだけど。

ですね。ちょうど今見てました。

3:57 AM

+struct ParameterizedStruct<T> { + mutating func takesFunctionWithGenericReturnType(_ f: (Int) -> T) {} +} これがArrayに相当してるのか

とりあえず、issueに載せたコードを動かしてみるといいのでは？w

そうですね、マージされてるし、あとでsnapshot落としてきて試してみます。

あ、まだこのPRを含むsnapshotは無いみたい。

あれ、でもmaster に merged だから

4:07 AM

a

4:07 AM

November 15, 2017

git tag --contains cf9a09e18dba7a7fe0506381589fbf0f4bb99a98 で何も出ない。

mergeされたのが17日か

4:08 AM

dailyが15日以降まだ来てないんですね。CIがコケてるのかしら。

swift-DEVELOPMENT-SNAPSHOT-2017-11-21-a出てる。

DL中

#beginner-help_archived が別の話題が進んでるんで、こちらで質問させてください。Swift で C++ の const 引数みたいなことって method / closure でできるんですっけ？

method / closureでできるの意味がいまいちわからないですが

inoutじゃない値型は全部copyなので実用上constになる気がします

すいませんわかりづらい書き方でした。引数で渡す class をその method 内で変更しないことを示せるのかな？と思って。

classはあきらめて

ですが、そもそも class に non mutating な method が定義できないので、const 性を保証できないのでそれはおかしいというツッコミを受けました(報告)

残当

1

struct にすれば > inoutじゃない値型は全部copyなので実用上constになる気がします < このとおり

8:12 AM

あとは class なら親クラスを readonly な type にしてサブクラスで mutating なメソッドを一通り実装すれば・・・

8:12 AM

引数で渡す class をその method 内で変更しないことを示せる

これじたいはできるよ。

readonlyをprotocolで表現してprotocol型で渡した方が良いですね

8:13 AM

流石にclassは面倒すぎるしlet propertyをvarでoverrideできな…できるの？！

8:14 AM

iPhoneなので試せない

たしかにprotocol横付けが楽ですね、ジェネリックだったら

今回はジェネリックじゃないので protocol 案でいけそう

8:19 AM

ジェネリックでもassoctypeつけて関数をジェネリックにすれば動くから出来るまで頑張ろう

ああこの状況なら <X: Proto> でいいのか

そう

なるほどなるほど

たしかに別にプロパティに保管するわけじゃないからいけるのか

プロパティに保管するならその時にerasureを使うぞ

https://gist.github.com/Biacco42/965b21a2fd48aded199cf1558c78a831

ConstReferenceTypeAccess.swift

無駄Optional警察だ！

ｗｗｗ

8:47 AM

そこかいｗ

代入テストで雑にそうしました…

あとこれclassはそのままclassなんで意味なくないですか

processPoに渡すクロージャの中ではsetterが呼び出せないから意味あると思うよ (edited)

あ、これはPoについてConstにしたいのか

8:49 AM

Elementについてと勘違いしてた

そうです。Po を Const にしたかった

型パラが妙に多いな

8:50 AM

func processPo<X: ConstPo>(po: X, process: (X.Element) -> Void) { これでok

なるほど！

本当はElementとかも含めて再帰的にConst化したいと思うんですが、今日のswiftではそれをシュッとやるのは無理ですね

8:54 AM

structつかおう (edited)

たしかに再帰は…

8:55 AM

うーんなるほど

9:00 AM

あ、でも今回は露出するプロパティが値型なので完全に目的を達成できそう

9:01 AM

ありがとうございました

これって const の場合と違って、型ごと CostoPo を満たさないといけないの微妙そう。

そこなんすよね

struct じゃダメ？ Swift の class は二級市民だと思ってる。

そうですね

抽象クラスとかもないし。

View なのでうーん…

再起でできるためにはConstableみたいな不毛なprotocolが必要になって、class to type-erasure structな記述をやる羽目になる

View に対応した ViewModel を struct で作って渡すとか？

structだとvar/letですむのに

View 自体を操作する関数だとダメだけど。

9:04 AM

（でも const にしたいくらいだから View から情報をとりたいだけに見える）

そうですね

caseでenumから値とるやつ、ここまとめられるの知らなかった。

enum Hoge { case fuga(Int) case piyo(Int) var count: Int { switch self { case .fuga(let count), .piyo(let count): // <- ここ return count } } }

えっ、どうなってんの、それ

protocolはまとめられないよん

同じ let count だからいける？

同じ具体型なら変数そろえて同一視できる

ワオー知らなかった

tarunonのいうとおりこれはエラーなった

protocol ProtocolA {} enum Hoge { case fuga(ProtocolA) case piyo(ProtocolA) var count: ProtocolA { switch self { case .fuga(let count), .piyo(let count): return count } } }

9:25 AM

Playground execution failed: error: MyPlayground.playground:5:24: error: matching a protocol value in multiple patterns is not yet supported; use separate cases instead case .fuga(let count), .piyo(let count): ^

前はコンパイラが破壊された

9:25 AM

僕の報告一覧にあるよ

9:25 AM

一応コンパイルエラーになったから解決なのかな

おもしろ記法みつけたと思ったら過去にtarunonに破壊も報告も修正もされてるのなんか悔しい

9:26 AM

悔しい

そんなおこらんといてや

Swift おもしろ記法探検隊

@tarunon これなら通りそうなもんだけど、これもだめなんか

protocol ProtocolA {} enum Hoge<T: ProtocolA> { case fuga(T) case piyo(T) var count: T { switch self { case .fuga(let count), .piyo(let count): return count } } }

パターンマッチ関連のおもしろ記法と言えば前に教えてもらった↓かなぁ。 let a: Int? = 42 if case let a? = a { print(a) }

9:28 AM

Optional Binding よりも意味がわかりやすい。

でた　左辺ハテナｗ

あれそれIterator.next()が粉砕されるやつでは

これって C で int *a = ...; *a = 42; って書くのと似てるよね。 (edited)

@hiragram そのTが通らないのは謎やね

だよね。

見た目だけは似てますね・・・ > *a = 42

いや、 *a が int 型というのと、 a? が Int 型というのが。

a? は Int 型ではないですよね

あ、これはInt型だから虐殺文法ではなかった

代入文の左辺に書けるだけで a? は Optional<Int> だからこそ a の部分だけが Int

9:33 AM

この言い方だとCもそうだけど・・・

9:33 AM

Cは中身と外見が先にあってデリファレンスするけど、 Swiftのさっきの式は中身がそこで産まれるから逆な感じがする。

逆か。 a? は Int? で a が Int か。

9:35 AM

C は *a が int で a は int * 。

さっきのTが通らないの、Tにprotocol入れられたら壊れるからと思ったけど、今はconditionalな型パラはそもそもprotocol入らないので益々謎だ

9:37 AM

その条件付けサボってるのかな

9:39 AM

それか将来的にprotocolが来る可能性があって意図してそうやってるか

抜けてるだけじゃねって印象

9:43 AM

@tarunon プロパティじゃなくてメソッドにしたらエラーメッセージがなんか愉快なことになったよ

protocol ProtocolA {} enum Hoge<T: ProtocolA> { case fuga(T) case piyo(T) func value<T>() -> T { switch self { case .fuga(let value), .piyo(let value): return value } } }

error: MyPlayground.playground:6:20: error: cannot convert return expression of type 'T' to return type 'T' return value ^~~~~ as! T

草

9:44 AM

報告しよう

as! Tいれると其の行はエラー消えるけどcase文の行がまたさっきのエラーでるんだけどね

9:44 AM

つまりvalueはTとして認識できてるんだからそのままコンパイル通ってもいいようなきがするんだけどそういうわけではない？

不思議なエラーだ

意図的に止めてそう

9:45 AM

protocol型で其れが出来ないのは、実際にはprotocol型そのものではなく存在型として振る舞ってることが関係してそうで

9:46 AM

型パラは常にprotocolが当てられることを想定した振る舞いになってる

9:46 AM

TとTが違うよは意味分からんけどprotocolのそれを踏まえて考えると然もありなん

文脈的に1個目のTと2個目のTが違う型の可能性ある可能性あるからってことよね

だね

9:49 AM

ただまあエラーメッセージは適切ではないから報告はしといてよさそう、回答も貰えるといいね

どっから報告するんだっけ。

bugs.swift.org

あとで暇みつけて書いておく

9:50 AM

こっちの書き方はちゃんとやってくれてうれしい

typealias Tuple = (Int, String) enum Hoge { case fuga(Int) case piyo(Tuple) var value: Int { switch self { case .fuga(let value), .piyo((let value, _)): return value } } }

9:54 AM

piyoにくっついてくる値がIntのプロパティをもつようなstructで、caseまとめて書く記法のなかでそのstructのIntのプロパティ取り出せたら便利かと思ったけどそこまでごちゃごちゃしてるならcase分けるわな

struct のプロパティとかをパターンで抽出するの、昔 swift のソースに無効化された状態であったけど、やらない雰囲気だからって消された覚えがあります。

おおっ

別件で Array の要素とマッチさせるのは evolution に何度か上がってた記憶ありますね。

9:59 AM

case let [first, second, third]: みたいな。

おー。

10:02 AM

この場合要素数が2だったらこのcaseにマッチしなくなるのか (edited)

https://github.com/apple/swift/commit/62e4811dacf4fcd1082c5e58a75b933adf6153f0

Remove support for nominal type patterns, which have never been suppo… · apple/swift@62e4811

…rted in an official swift release and have bitrotted.

10:06 AM

Array パターンは https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170116/030347.html

そんなのがあったのか〜

error: MyPlayground.playground:6:20: error: cannot convert return expression of type 'T' to return type 'T' return value ^~~~~ as! T

これは真っ当なエラーでは…

というか、タイプの T使うなら func はこの場合Genericsにすべきでないですね。

見逃してた

11:14 AM

<T>ついてるw

あ、ほんとだ。

あっ

11:14 AM

ごめんなさい

https://github.com/omochi/ReactiveEmitter/commit/c08f4f0c6eeb047531fe853ca3d27869ecdcc89d#diff-d200e6f58b4d87ffba946a6d0bbcef0b

fix never, fix flatMap · omochi/ReactiveEmitter@c08f4f0

11:15 AM

↑それさっきやらかした

タイプの型パラshadowしたら警告出すとか有用なのかも。

↑の例は Event と T だからshadowでもないんですよね・・・ｗ

1

11:17 AM

Array.Elementも結構引数で受けるときはT, U で書いちゃうし

11:18 AM

逆にそのような警告を出す機能があったら、ちゃんとした名前をいつでも使うように心がけるようにはなりそうだ。

この余分なTあるとnever使えなくなって訳わからなくなるよね

推論がコケるんだよねｗ

11:21 AM

すぐ気づけて良かった・・・

ハマると、一度ハマった経験がないと気づけなくなる

https://bugs.swift.org/browse/SR-1420 既に上がっていました。＜型パラshadow警告

要望っぽいものも上がってるんですね

sublime text の syntax カラーリングわかってきた

3:59 PM

しかし既存の Swift プラグインは残念ながら tmLanguage 形式で

4:02 PM

これとがんばって連携していくか、 sublime-syntax 形式での対応を１からやるか・・・

ほうほう、tmLanguage って TextMate のシンタックス定義なんですね。

そのようです。SublimeText2まではそっちだったけど、SublimeText3から、tmLanguageも使えるけど、独自のsublime-syntaxを使おうねって感じ

4:04 PM

https://www.sublimetext.com/docs/3/syntax.html

4:04 PM

スタック付きの正規表現ベースのオートマトンみたいな仕組みっぽい

Swiftのパーサ周りを読んでいたら、 Token と tok と Tok が出てきて、

3:10 AM

Tok の定義が全然見つからないと思ったら Token 型のフィールド名が Tok だった・・・

3:12 AM

ちなみに tok は enum

フィールド名を UpperCamelCase にするのは LLVM 文化特有なんですかねー。

Googleは snake_case_ ですね、他のC++プロダクトをそんなに読んでないのでわからないですが

やっぱりxcodeでリーディングしようと思ってclone,update,build-script --xcodeしてxcodeで開いて、

1:18 PM

プロジェクトのソースツリーのカオスさに笑ってる

ソースツリー役に立たないから検索ばっかしてる

https://qiita.com/rintaro/items/2047a9b88d9249459d9a

Swiftコンパイラ開発環境構築 - Qiita

Swift がオープンソースになってしばらく経ちます。コンパイラや標準ライブラリの開発に手を出してみたいけど、リポジトリを落とした後どうしていいかわからない！という方のために、まずは開発環境の構築方法をご紹介します。基本的には[RE...

1:19 PM

この記事のスクショとすこし違ってる(Sourcesが無い)

1:21 PM

ひらりがこの前言ってた、ファイル名あいまいジャンプできるやつ

1:21 PM

役に立ちそう

⌘⇧Oと⌘⇧Fめっちゃ使うけど結構迷子になるからソースツリー+差分と履歴も使う

1:24 PM

ソースツリーの下の検索ボックスの横に時計とgitマークあるので、onにすると最近見たファイルとか差分のあるファイルで絞り込めてソースツリーが使い物になるようになる

なるほど

1:26 PM

あ、あった、ここらへんだ

1:26 PM

swift/lib/XXX のディレクトリごとに対応するターゲットがあった

え、、、

1:27 PM

俺は一体今まで何を、、、、

上から60%ぐらいのところに

1:28 PM

swiftIndex , swiftIDE, swiftIRGen, swiftParse

1:28 PM

などのグループがあって、それぞれの中に、SourceFilesとHeaderFilesが入ってて

1:29 PM

https://github.com/apple/swift/tree/master/lib/Parse

apple/swift

swift - The Swift Programming Language

1:29 PM

ここらへんの lib/ XXX / CMakeList と対応してるっぽいね

なんか、グループの作られ具合、CMakeのバージョンによっても違うのかも。

CMakeList一個が一個のターゲットになってて、Xcodeに噛み合わないやつは、そのままCmakeをたたくだけのスクリプトターゲットになってて、オプション違い？もバラバラに生成されるから、こんなカオスなのだな

1:31 PM

xcodeprojの生成自体は完全にcmake側の機能に任せてるんですかね？

そのはずですね。 CMake -G Xcode

なるなる

1:34 PM

おっしゃー

1:34 PM

Tok でジャンプできたぞｗ

1:34 PM

１日消えたｗ（途中で寝落ちしてた (edited)

--release-debuginfo --xcode でビルドしたら

4:43 PM

clang: error: no such file or directory: '/Users/omochi/work/swift-source/build/Xcode-RelWithDebInfoAssert/cmark-macosx-x86_64/src/Debug/libcmark.a'

と出ていて (edited)

4:43 PM

実際には /Users/omochi/work/swift-source/build/Xcode-RelWithDebInfoAssert/cmark-macosx-x86_64/src/RelWithDebInfo/libcmark.a

4:43 PM

が生成されているので

4:44 PM

--release-debuginfo なのに cmark は --debug で参照しちゃっててうまくいってないみたいなんですけど

4:46 PM

--xcode は作業用、 ninja でビルドするのが良いのか？ release-debuginfo があまりメンテナンスされていないので、 release にするのが良いのか？とか、どうなんでしょう

あら、 Releaseでやっても同じところでコケた

あっ！

7:17 PM

なるほど、build-scriptに渡したconfigurationとは別に、xcode側のいつものconfigurationをちゃんと設定しないといかんのか。