ブランチ分岐

[cesare]

みなさま

ブランチを一つ作りました。
主にconstructフェーズ周りのコードを追加するのに使っています。
本線の方はよしみさんが開発を進めていることだし、横から急に
改変するのもどうかと思ったので、ブランチを分けることにしました。

ブランチ名は「developing-construction-phase」で、詳細は↓をどうぞ。
http://github.com/cesare/ruby-libc-libyaml/tree/developing-construction-phase
今のところ、nullとかtrue/false、NaN/+-Infinityあたりを扱えるようにしてあります。

どこかのタイミングで本線にマージしていただければ幸いです。
ツッコミ＆要望など歓迎です。


P.S
ていうか、あけましておめでとうございます :)
今年も引き続き、宜しくお願いします。

--
cesare

[河野 誠]

皆様

あけましておめでとうございます。
本年もよろしくお願い致します。

cesareさん
ブランチ作成お疲れ様です。

僕もC言語のリハビリ兼ねて、yaml_streamの実装を試しに
やってみているのですが、作業が被らないように
ある程度分担して開発した方が良さそうですね。

2009/01/01 19:31 cesare <moc.liam...@gmail.com>:

[Keiji Yoshimi]

おつかれさまです。

Dovrakに慣れてない状態だったので返事が遅くなりました

> 本線の方はよしみさんが開発を進めていることだし、横から急に
> 改変するのもどうかと思ったので、ブランチを分けることにしました。

ブランチ分けの方針はどうしましょうね。

個人的にはコンフリクトするようなケースだと、
変更した機能範囲がかぶっていることがほとんどなので、
どのみち手動マージしないといけないので
ブランチあまりきらなくてもよいと思っているのですが、
コンフリクトが発生するのを他のみなさんが嫌うのでしたら、
切ってもらう分には構いません

masterにmergeしたあとはどうしましょうね。
個人的には利用者にわかりやすいようにforkでなければ、
基本消すのが個人的には良いかなと思っています。

branchの扱いかたは(念のため)、
他のブランチからcesare/masterにmergeするときのみ
git-mergeして、それ以外の場合は
git rebase cesare/masterするようにしてやってください

> ブランチ名は「developing-construction-phase」で、詳細は↓をどうぞ。
> http://github.com/cesare/ruby-libc-libyaml/tree/developing-construction-phase
> 今のところ、nullとかtrue/false、NaN/+-Infinityあたりを扱えるようにしてあります。

Cはあまり得意ではないのでどう実装しようか迷っていたので非常に助かりました

>
> どこかのタイミングで本線にマージしていただければ幸いです。
> ツッコミ＆要望など歓迎です。
>

特に問題はなさそうだったのでマージしておきました。
アップデートした方はrake compileする前にrake cleanするのを忘れないように。

ファイルのわけかたで少しひっかかったのですが、
constract.cの名前がちょっと何をするものなのか
わかりにくいかなと思いました。
最終的にはdumperも作るのですがそれの意味と混同しそうになるかなと思いました。

個人的にはscalarの場合の処理なので、process_scalar.cとか、
do_parseもあわせてわけてparse.cとしてしまうのがよいかなと思います

今の規模であればファイルを分けるほどでもないかなと思うのですが、Cの開発だと機能単位でファイルを分ける
のが一般的なのでしょうか?

そして、テストのファイルなのですが、
1) YAMLと同機能であることが期待できるテスト
2) YAMLにバグがあるのでlibyamlだけ実行するテスト
( libyamlの有用性を示すためYAMLでも実行できるようになっているとのぞましい)

というわけかたが保守しやすくてよいかなと思います。

>
> P.S
> ていうか、あけましておめでとうございます :)
> 今年も引き続き、宜しくお願いします。

こちらこそ今年もよろしくおねがいします
libyamlをぜひRubyConfで発表してやりましょう!!

>
> --
> cesare
>
> >
>

[SAWADA Tadashi]

沢田です。

マージ確認しました。作業ありがとうございます。
作業用に分岐させたブランチについては、消しておく方針にしようと思います。


> ファイルのわけかたで少しひっかかったのですが、
> constract.cの名前がちょっと何をするものなのか
> わかりにくいかなと思いました。

これですが、処理フェーズの名称でファイルを作るのが解りやすいかと思ったので
constructフェーズの処理を書くソースファイルということで「construct.c」に
してみました。

でも、よく考えたら events から直接 data へ変換しているようなものなので、
nodes → data へ変換する「construct」フェーズとはちょっと違いますね^^;

※ http://gihyo.jp/dev/serial/01/yaml_library/0001 の図1をご参考に


基本方針としては、
(1)libyaml.cはRuby-C間の橋渡しに徹する
→Rubyから引数を受け取ったり、libyaml-C-APIを呼び出したり、Ruby側に結果を返したり

(2)それ以外の、libyaml-Cが面倒を見てくれない部分の調整は「フェーズ名.c」に書く

という線でいかがでしょう？


--
cesare


2009/1/3 Keiji Yoshimi <wal...@gmail.com>:

--
*
* SAWADA Tadashi a.k.a cesare
* <moc.liam...@gmail.com | skype:synkronicity | xri://=cesare>
* feeds: http://friendfeed.com/cesare
* blog: http://cesare.seesaa.net/
*

[Keiji Yoshimi]

よしみです

2009/01/05 0:07 SAWADA Tadashi <moc.liam...@gmail.com>:

>
> 沢田です。
>
> マージ確認しました。作業ありがとうございます。
> 作業用に分岐させたブランチについては、消しておく方針にしようと思います。
>
>
>> ファイルのわけかたで少しひっかかったのですが、
>> constract.cの名前がちょっと何をするものなのか
>> わかりにくいかなと思いました。
>
> これですが、処理フェーズの名称でファイルを作るのが解りやすいかと思ったので
> constructフェーズの処理を書くソースファイルということで「construct.c」に
> してみました。
>
> でも、よく考えたら events から直接 data へ変換しているようなものなので、
> nodes → data へ変換する「construct」フェーズとはちょっと違いますね^^;
>
> ※ http://gihyo.jp/dev/serial/01/yaml_library/0001 の図1をご参考に
>

なるほど。語彙の由来については把握しました。
頭にいれておきます。

>
> 基本方針としては、
> (1)libyaml.cはRuby-C間の橋渡しに徹する
> →Rubyから引数を受け取ったり、libyaml-C-APIを呼び出したり、Ruby側に結果を返したり
>
> (2)それ以外の、libyaml-Cが面倒を見てくれない部分の調整は「フェーズ名.c」に書く
>
> という線でいかがでしょう？
>

という線でとりあえず1)になぞるようにlibyaml.cの一部の
関数を動かしてみました

[KAKUTANI Shintaro]

かくたにです。

2009/1/3 Keiji Yoshimi <wal...@gmail.com>:

> ブランチ分けの方針はどうしましょうね。
>
> 個人的にはコンフリクトするようなケースだと、
> 変更した機能範囲がかぶっていることがほとんどなので、
> どのみち手動マージしないといけないので
> ブランチあまりきらなくてもよいと思っているのですが、
> コンフリクトが発生するのを他のみなさんが嫌うのでしたら、
> 切ってもらう分には構いません
>
> masterにmergeしたあとはどうしましょうね。
> 個人的には利用者にわかりやすいようにforkでなければ、
> 基本消すのが個人的には良いかなと思っています。
>
> branchの扱いかたは(念のため)、
> 他のブランチからcesare/masterにmergeするときのみ
> git-mergeして、それ以外の場合は
> git rebase cesare/masterするようにしてやってください

さわださんのリポジトリはmasterみたいなもんだから、そこでbranchを切りたくなるのは
当然といえば当然なのですが、それでもどんどん突っ込んじゃっていいんじゃないかなあ、と思いますけど……。

> こちらこそ今年もよろしくおねがいします
> libyamlをぜひRubyConfで発表してやりましょう!!

頼もしい!!
たぶんlibyamlだけの紹介だとrejectされると思うのでw、
そのへんの作戦には相談に乗れると思います(傾向と対策的な)。

--
KAKUTANI Shintaro
http://kakutani.com