実はゲームを弟にやらせて、ここ 1 週間ほどドキュメント作りとか頑張ってました。
クリスマスプレゼントっていう位置付けでリリースするけど、テストは一切やってないのでご了承あれ。
YsPlugins180a1.zip(1.34 MB)
YsPlugins180a1_src.zip(ソースコード)(661 KB)
全て:
[chg]ライセンスを修正 BSD ライセンスに変更しました。
Y_CallBack:
[Chg]MemoryBlock.Address メソッドが MemoryBlock.Y_Address に名称変更。
[Chg]Y_CallBack.CallBack イベントの argument 引数が arguments に名称変更。
Y_FileUtilities:
[New](WIN)Y_MakeAlias, Y_FindAlias が ShellLink に対応し、Mac のエイリアスとほぼ同じ感覚で利用可能になった。
[Kis](WIN)上記変更により、従来の Y_MakeAlias で作成した文字列を現在の Y_FindAlias に渡してもファイルが見つけられなくなりました。従来の Y_MakeAlias はファイルパスを返すだけのメソッドであったので、従来の Y_MakeAlias で作成した文字列から FolderItem を取得したい場合は、GetFolderItem の引数にそのまま渡してください。
Y_NthFields:
[New]Rb 4.5 以降のデフォルトエンコーディングが UTF-8 なので、UTF-8 向けの対処をしてみた (Rb 4.5 以降を持って無いので確認できない)。
Y_Strings:
[New]Rb 4.5 以降のデフォルトエンコーディングが UTF-8 なので、UTF-8 向けの対処をしてみた (Rb 4.5 以降を持って無いので確認できない)。
Y_StyleText:
[New]Y_StyleText.AnalyzeToHTML が Rb 2.x~Rb 3.0.x でも使用可能になった。
[New](68K)Rb 2.x 以降で Y_StyleText クラスが 68K に対応。
Y_TextConverter:
[New]Y_GetCharset, Y_GuessCharset, Y_ConvertCharset を追加。
[chg]上記により Y_KCCheck, Y_KCConvert, Y_KCConvertEx は廃止予定になった。
[New]Rb 4.5 以降のデフォルトエンコーディングが UTF-8 なので、UTF-8 向けの対処をしてみた (Rb 4.5 以降を持って無いので確認できない)。
あと、Y_TextConverter の Y_GetCharset, Y_GuessCharset の戻り値、Y_ConvertCharset の引数に関するドキュメントがまとまっていないので、値の一覧を置いときます。
コメント (6)
すげー!お疲れ様です。
なんつーか、かなーり使えるプラグインになった気がしまする。
特に文字コードあたりが充実してて、イイ!
投稿者: LETTER | 2004年12月26日 08:24
日時: 2004年12月26日 08:24
動いた?
1 つのプラグインで Rb 2.0 から Rb 4.5 まで、果ては MPW では不可能に近い 68K にまで対応してるから鬼のようにトリッキーなコードになってる(笑) SDK なんかは全部書き直しだったし、パッと見て意味が分らないマクロを沢山作っちゃったし(疲)
って Read me.html に書いてあるライセンスの記述ファイル、入れ忘れてるぢゃん。
ソースコードの方には入ってるからいいか。
投稿者: よっふぃ~ | 2004年12月26日 09:35
日時: 2004年12月26日 09:35
>>3 を読んだ人が誤解するといけないから補足しとくけど、
プラグインは Rb 1~Rb 5.5 まで対応してます。
なのに「1 つのプラグインで Rb 2.0 から Rb 4.5 まで」って言ってるのは
Rb 1 用、Rb 2~4.5 用、Rb 5.x用に分かれてるっちゅー意味。
投稿者: よっふぃ~ | 2004年12月26日 09:43
日時: 2004年12月26日 09:43
nthfieldの高速化版が使いたくてYsPlugins180a1.zipのYnthfieldを使わせていただきました。
10000000回で速度テスト(↓のソース)をしたところ標準のものとあまり速度差はありませんでした。
RB5.5.4J(WIN版)、winXPを使用しているのですが既に標準が高速化されちゃっているのでしょうか…。
dim tmp as string
dim i as integer
progressBar1.maximum=10000
for i=0 to 10000000
//tmp=Y_nthfield("1 2 3"," ",2)
tmp=nthfield("1 2 3"," ",2)
if i mod 1000=0 then
progressBar1.value=i/1000
end if
next
勝手な提案で申し訳ないのですが、
例えば文字コード限定で、セパレータは半角スペースや"/"、TAB文字といった1Byte文字などの制限付きでもっと高速化するということは可能でしょうか?
また、Y_ChangeFieldを見て思ったのですが、派生関数として、Y_SwapFieldなる関数があると面白いなと思いました。(何番目と何番目を入れ替える)
私がやりたいことですが、
1 2 3の組み合わせパターンをすべて洗い出すということを
やりたいと思っています。
例えばn個の組み合わせパターンはn=12の場合、4.7億パターンありそれを処理しようとすると膨大な時間がかかります。二次元配列を使う方法も試してみましたが、nthfieldを使って文字列で処理したほうが速いということがわかり、nthfieldの高速化プラグインを求めてこちらのサイトにやってきました。
下のソースを見てもらうとわかりますが、swapというオリジナル関数の中はnthfieldの繰り返しでそこで時間を浪費してしまっています。
for p=1 to bit-1
for q=p+1 to bit
for i=0 to n(p-1)-1
rptn.append me_swap(rptn(i),p,q)me_swap関数はオリジナル関数
progressbar1.value=i
next
next
n(p)=ubound(rptn)+1
progressbar1.maximum=n(p)
progressbar1.value=0
next
投稿者: オパ夫 | 2008年06月05日 09:28
日時: 2008年06月05日 09:28
なんと。まだ使ってくれている人がいる事に驚いています。
Rb 4.5 以降を持っていないので分かりませんが、標準の物が十分に高速化されている可能性もありますね。
Rb 4.0 時点での Y_NthField 関連は、以下のいずれかの場合に特に効果を発揮します:
1 byte の場合は専用のプログラムが走るようになっていて、既に限界に近いと思われます。
ただ、オパ夫さんの例のように対象の文字列が "1 2 3" と短い場合はどのような方法を使ってもあまり差が出ません。
Swap については大変面白いと思いますが、現在はもう MPW (開発環境) の動く環境が無いため、仕切り直さないと開発の続行は難しくなっています。
例では配列に Append を行っているようですが、ここに時間がかかっているという事はないでしょうか。
数が予め分かっている場合は、ループの前に Redim をしてから代入だけしていった方が良いと思います。
投稿者: よっふぃ〜 | 2008年06月05日 15:20
日時: 2008年06月05日 15:20
>例では配列に Append を行っているようですが、
ご指摘ありがとうございます!
これをループ前に宣言することで非常に高速になりました!
二次元配列にしたときも同じようにやってたのでそちらのほうもめちゃくちゃ速くなりました。
nthfieldと全然違うとこに問題があったとは…(^-^:
さて出来上がった4.7億個のパターンをどうやって出力するかですが…(^-^;;
どうもありがとうございました。
投稿者: オパ夫 | 2008年06月05日 23:26
日時: 2008年06月05日 23:26