-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x64対応を何をもって対応と言うか。 #430
Comments
一番分かりやすいのは 32bit アプリじゃ無理だと思われることをやれればいいんだと思います。 サクラエディタの内部データでテキストのサイズを示す変数の型は、ほぼすべてintです。 サクラエディタの内部には、そもそも64bitでビルドすることを想定してないコードが結構あります。 上を目指すのは「梅」にたどり着く目途がついてからでいいのかな、とぼくは思ってます。 |
なるほど、「松」「梅」表現いいですね。 今リリースされているx64はとりあえずコンパイルできた、って状態で4GBファイルは開けないってことですかね(なんかそのまえに2GB Overチェック入ってるんでしたっけ) |
x64 対応に関して誰か作業されてますか? |
先週末に一気に片付けようと着手しましたが体調思わしくなく頓挫しました。今週末にでもチャチャっと対応しちゃおうと思ってますが、自分より先に対応できちゃう方がいるのであればその方に任せても良いです。 |
自分のほうで push しているブランチも無いですし、他の方が作業着手することを止めはしません。 |
ちなみに自分が片付けようとしたのは全Warningの解決です。これでx64完了というわけではないですが、ひとつのステップとしてキリは良いでしょう。 |
今、だれも着手してないかもしれませんが、ひとまず全Warning消せて、4GB overのファイル開いて疎通確認したら、alphaをbetaにして、広くテストしてもらうのどうでしょう。 |
前に @m-tmatma さんが部分的なPRを出されていたと思います。 当時はどういう風にx64化するかの指針が何もなくて、 こういう意味のエラーだから、 と宣言して、対応していく感じになるのかな、と。 その際、x64化のために既存の構造を拡張したり改善したりしない、って感じがスムーズに進めてくための指針になるかと思っています。 この件に関して、ぼくはレビュー側に回ったほうがよさそうな気がしています。 |
@berryzplus さん、反応感謝です^^; ソース見てない身なので小出しでいけるのか一括で変更しないとだめなのか、 だれか修正のパターン、こういう時はこうしましょうとか、 |
警告一覧は Excel ファイルになっていて作業分担はできる状態なんですよね。 https://ci.appveyor.com/project/sakuraeditor/sakura/branch/master/job/p3ul39art0458p1w/artifacts ざーーーーーっと見たところ、ほぼ「 64bit を 32bit に暗黙変換してますけど大丈夫ですか?」という意味の警告っぽいです。 第一段階としては「いいです。」ということになるんだと思ってます。 |
なるほど。とはいえ、割り振るほどヒューマンリソース潤沢じゃないので、 |
64Bitにせねばならないところとそうでないところを分けるって感じですかね。 |
いや、いったん警告潰すだけっす。 x64 になったら何を拡張できるか考えるのはその後です。 拡張できたらうれしい部分は多いですが、 |
そうなんっすね、わかってない中いってますが、64Bit化して4GB Over対応のところを見つけるのが今がいいのかなと思ったのですが、一旦フラグ消してからでもいいって感じなんすね。 |
これは何を意味してますか? 64Bit 環境の場合に 64Bit 変数が必要か判断して適切な型を使うという意味ですか? |
実装レベルは想像の域をでませんが、私の空想は @m-tmatma さんの思いに近いとおもってます。 |
お二人とも正しいと思います。 発生している警告の種類は少し前に書いたとおりです。 たぶん、よくわからない(int)でいっぱいになってると思います。 実際のところ、x64対応は警告潰しなんかじゃなくて、何をx64対応させないといけないかを見定めることだと思っています。そのために、現状の警告はノイズになります。取り払っておくに越したことはないと思います。 |
すみません、離れると言いましたが一応通知は見ているのでここだけは突っ込ませてください。 僕は正直、完璧主義は嫌いです。なのでPRマージ等も今よりもっと雑にやって良いと思っています。 ただ、この件に関しては雑にやると本気で大怪我するので気を付けてください。 |
intのキャストって動的なんすかね。 が、 実際に手つけると意外と局所化できるかもしれないっすよね。 |
一応補足しておくとビット数または値範囲が分かっている変数同士をどうしても橋渡ししなければならない都合で、キャスト(または #pragma 等)によってしか潰せない警告をキャストで潰す対応が必要なことが多々あることもまた事実です。ただ x64 対応については真摯にサイズ問題と向き合わなければならない分野です。 |
実際のところ、何をもって x64 が完了したかについては、x64 対応による影響範囲を洗い出し、そのテストを行い、それがすべて正常に動くことを確認する必要があります。 ただ、その影響範囲は x64 関連の警告を潰すことによって徐々に発掘されることになるはずです。なので対応以前に影響範囲を全て洗い出すことはおそらく不可能です。 x64 関連の警告を潰していくと、その変更コード範囲から影響を受ける機能が洗い出せるので、それをもとにテスト計画を立てる、というのが真っ当な筋道です。これなんか仕事っぽくて嫌ですが、x64 に限っては仕方ないです。 普通の機能対応だったら対応前から先にテスト計画を立てられるのが一般的ですが、x64 についてはちょっと逆向きの方向でものを考える必要があります。そのためにもひとつひとつの警告を丁寧に扱ってあげてください。 |
勘違いされているかもしれませんが、補足すると、私は @kobake さん派です。 キャストをして警告を握りつぶすのを選ぶくらいなら、何も変えずに 警告を握りつぶすのは、害しかないです。
警告を修正することには賛成です。 しかし、64bit OS では 64bit 変数にすべき(or した方がいい) ものを64bit 変数にして |
それだとメチャメチャ時間がかかるからモチベがもたない・・・というのを懸念しています。 芋づる方式というか、指摘された箇所で「何故警告が出たのか」を考えて原因に対処していくやり方になると思います。原因に対処すると警告箇所以外にもあちこち修正することになります。 この方式だとPRする側もレビューする側も、かなりガチンコで取り組むことになります。 それでも「ガチンコで行こう」っていうなら付き合うのもやぶさかではないですが。 |
同じく懸念はしてます、はい。 そしてこの修正ってトリッキーな実装ではなく地道で堅実な人が好きそうな分野なのかなと。 なので援軍呼ぼうかなぁって。 |
64bit化しないといけないint
64bit化しなくてもいいint
|
この2つだけ対応すればいけるんじゃね?というのが何度か試行してみた感想です。
OSに渡すハンドルを対応しなくてよいと考えている理由は、多くの部分で Windows SDK がx86/x86_64の違いを吸収してくれているためです。 x64対応を検討する中で思いついた性能強化案がいくつかあります。 警告を見て思いついたものなので、いま出すと確実に修正範囲が被ります。 やるかやらんかは別にして、issueを立てる障害にはならんと思うので。 |
とりあえず、気が早いかもですが、5Gのテキストファイルは作りました! |
正確に5GBじゃなかったので、リトライ中。 |
スモークテスト(#1301)で問題なければ「できた!」と言ってよい気がします。 というわけで閉じてしまいます。 |
Next Releaseに向けて目玉の一つがx64対応かと思いますが、
現在alphaリリースのものを正式リリースと言うために何をしたらいいかです。
The text was updated successfully, but these errors were encountered: