Tags
Aucun tag

Frequently used words (click to add to your profile)

javaandroidc++linuxc#objective-ccocoa誰得qtrubypythonwindowsphpgamebathyscaphegui翻訳comegattwitterframeworkbtronvb.net計画中(planning stage)testdomarduinodirectxpreviewerゲームエンジン

最近の作業部屋活動履歴

2020-11-11
2020-11-01
2020-10-28

最近のWikiの更新 (Recent Changes)

2020-11-11
2020-11-01
2020-10-28
2020-09-23
2020-09-21
2020-09-20

Wikiガイド(Guide)

サイドバー (Side Bar)

現在の課題

令和2年9月22日

euphoria 3.1.1 の問題

XP機での試作で使っているが、いろいろと物足りない印象がある。ルーチンIDとシーケンスを応用したメタプログラミング、love2d風のコールバックシステムの構築、それに加えて名前空間を活用したインスタンスベースのオブジェクト指向パラダイムも可能ではあるんだが...…文字コードまわりはなんとかなるが、いかんせブロック構文の冗長さはキーボードマクロか、プリプロセッサがないとつらい。

一応、 euphoria でホメられるところがあるとしたら宣言はすべてローカルスコープになること。宣言時に global を付けない限り、グローバルスコープにならない。この仕組みは名前空間識別子と併用すると安全性と保守性が高まるのがいい。

追記

ルーチンIDを悪用すればgotoモドキはできる気がします。この方法、すぱげっえてぇプログラムの移植をするときくらいですかね。

かな入力配列の定義ファイル形式

問題点として、未だに JIS 規格や業界標準規格はない。

  • かんな
  • かえうち
  • Mozc
  • DVORAKJ

などファイル形式や記法はバラバラで相互運用性は考慮されていない。だいたいCSVやTSV, SSV (Slash Separated Value) の異形で相互変換プログラムもない。最悪、 SQL を使うことも検討。

応答速度

定義ファイル対応となると、やはり起動速度や応答速度の低下は気になる。 FPS や格闘ゲーマーほどではないが、モノカキは短気だし起動・応答速度に対して敏感だと思う。ミリ秒単位で応答性能を上げても喜ばれないのはわかるけど、バックグラウンドで処理が重なったとき、入力を取りこぼしたり遅延やら固まったりしたら頭にくるのがモノカキってものだ。

だいたい、配列やテーブルにたいしてfindやgrep相当の関数を使うのがセオリーなんだけど、想像するだけで応答速度や遅延がものすごく気になる。結局、ゼロレイテンシーに近いものでないと意味無いよね。今回の実装は、配列変換ソフトウェアとは違いネイティブ実装だから、ホストIMへ渡すためのキー入力変換処理は入らないぶん遅延は少ないのは想像できる。だが、それでも比較用の検索・判定関数呼び出し時のオーバーヘッドは累積すると無視できない気がする。

連文節変換

初期は対応しない予定。 何十年経っても同音異義語に弱いのは相変わらず。かと言って予測入力変換も同じ問題を抱えている。結局、信頼性は単文節変換のほうがいいわけだが、こっちは「変換する」といった点でユーザーインタフェースで問題を抱えている。もっとなんとかならないものか。

漢直(連想・無連想方式)への対応

熱狂的なかな配列沼の住人が牢獄に閉じ込められ海に沈めらること一ヶ季。異形なるものへと変貌して肩にキノコが生えて、こうなるらしい(元ネタはSHROUDED ISLE)。原理上、同音異義語に関する誤変換や誤操作がないのが強みである。最良時は親指シフト以上の効率を発揮する。

基本的に定義ファイルの応用なので可能ではあるものの、連想方式ではカンテックや KIS などに代わるフルスペックのオープンソース実装はないのが頭の痛いところ。

余談だが、英文入力多いから親指シフトは諦めたと環境と配列を混同し、詭弁を撒き散らしている者には無連想方式の漢直をオススメしよう。キミには開眼者になる資格がある。