日記書いてないのは作業が進んでるせい……進んでるかな? まあ日記はある程度書いて上げてないせいもあるんだけど。
最近LOOX UでVisualStudioがクソ重いんだがどうしたものかと。 たぶんPeerCastStationでWPF使うようになったのがでかいとは思うんだけどそれだけなのかなぁ。
WPFのXAML編集がとにかく重いのは確かで数秒固まるのがざらにある状態。 WPF編集が改善された2012入れたらもう少しマシになるのかな? でもディスク容量が厳しいので2010と2012両方は入れられないしなぁ……。
最近使う人がやたらと増えてきたせいか、Issueに上げろと口を酸っぱくして言い続けたせいか、要望やらバグ報告やらが沢山上がってくるようになった。
上がってくるのはありがたいことだけど手がまわってなくて対応しきれてないのがしんどい。 なんとかならんものかと思うもののなんともならんな。
誰か手を入れてくれる人が増えることを期待して開発者用のドキュメントをちゃんと書くのはやるべきか? やるべきかじゃねーよやれよって話だな。ビルド方法だけでも無いよりマシだろうし。
Issueを閉じるタイミングもどうすればいいかよくわからんのが困る。 いついつのコミットで直したわ→クローズ!ってやるとリリースはしてないので同じ報告がまた上がってくる。 そりゃまあユーザ的にはリリースされないうちは直ってないも同然ですね。むむむ……。
今のところリリースしてから閉じるようにしてるけど、そうするといつまでも残って気分的によろしくない。どうしたものか。 あとやっぱりIssueがオフラインで見れねぇのがしんどいな。かといってFossil使うのもなんだかなぁ。
Send Timeoutが多数記録されてリレーできなくなるという報告があったので調べ……られない。 手元では起きてないので調べるのが難しいんだよな。
Send Timeoutが多数記録されているというので、きっと送信タイムアウトで切れてるんだろう。 接続してきたノードにパケットを送る時に送信タイムアウトしちゃってるんじゃないかという辺りが思い当たる。
一律3秒で切れるようになってるけど、これよくないなぁ。送ろうとしてるデータ量にかかわらず一律3秒でタイムアウトしてるから、10MiB送ろうと1KiB送ろうと3秒で送らないと切られちゃう。そりゃひどい。 とりあえず急ぎで対応しておいた方がよさそうだったので10秒に延ばしてみたけど根本的な解決にはなってないぜ。
正しく判別するなら送ろうとするデータ量に応じてタイムアウト延ばすべきだな。 じゃあいくら送るのにいくら時間かけていいんだ?相手がうけとれるのに十分な時間なんて知らんぞ。
それっぽい時間としてはコンテンツのビットレートがあるかなぁ。 コンテンツが公称480kbpsなら少なくとも480kbpsの速度では受け取ってくれることを期待してもよいんじゃなかろうか。 それが転送できないようでは切れても仕方ない。 480kbpsの時に60KiB/sか。ちょっと小さい気はするが、タイムアウト値なのでそれより速く転送できる分には問題ないな。 ちょっとこれでタイムアウト時間調整してみるか。
パケット溜め過ぎなんじゃないかという気もするがPeerCastを見たら64パケット保持してた。 PeerCastStationは100パケット。1.5倍ということでそこまで持ち過ぎって程でもないかなぁ。 問題はパケットのサイズとコンテンツの時間は関係ないのでいったいどれだけ保持したら十分かってわからんこと。 やるならパケット受け取った時刻を保持して時間で消す方がいいのかな。それはそれで検討したいところだ。
パケット返し始める位置が適当なのもなんとかしないと……。→調べたら適当じゃなくてちゃんと実装してあったわ。 貰い始める位置が適当なのはなんとかした方がいいな。
issueを前もってdownloadするとか。<br>https://github.com/mislav/issuesync#readme
おおこんなのあるんですね<br>さすがにローカル書き込みできないのは仕方ないけど見れるだけでもだいぶ助かります