HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2014
0131
しますず自作ライブラリを公式に同梱して欲しい8解決


しますず

リンク

2014/1/31(Fri) 18:26:40|NO.59571

自作ライブラリを公式で同梱して欲しいのですが
どのような手順を踏めばよいでしょうか?

作成したものは連想配列のライブラリです
まだヘルプは作成しておりません
http://simasuzu.web.fc2.com/stdmap_v1_00.zip

非営利利用も営利利用も無償で使ってもらって構いませんし
ライセンス表記も無くても構いません

次期バージョンで連想配列が実装されるようでしたら
その旨書いていただければ幸いです

ご意見あればよろしくお願いします



この記事に返信する


check

リンク

2014/1/31(Fri) 23:07:03|NO.59574

403エラーが出て肝心のファイルがDLできないのはさておき、
一番確実なのは、おにたま氏に連絡を取って承認を得ることだろう。

広く使われているもの(過去のEasy3D.dll)や、
コンテストで入賞した人(d3module, Artlet2D)の作品が同梱されているので、
まずは一般に公開して知名度を上げていくことをお勧めする。



しますず

リンク

2014/1/31(Fri) 23:57:14|NO.59577

ありがとうございます

zip に直リンクしていたのが良くなかったようです
こちらの一番上のリンクからダウンロードできます
http://simasuzu.web.fc2.com/

色々と標準に追加して欲しい関数郡がまだまだあるので
追加できるようなら命名規則等そろえて作りたいと思います



HIJIKI

リンク

2014/2/1(Sat) 06:04:49|NO.59582

ずっと前からすごく欲しかった機能です。
ありがたく使わせて頂きます。

同梱に関しては、メールで直接連絡するのが確実ではないでしょうか?
メールはとても律儀に返してくださるので、
タイミング的に、チェックしてない可能性もある掲示板に書くより
そちらのほうが確実だと思います。



3k

リンク

2014/2/1(Sat) 10:54:48|NO.59591

連想配列ですが、うーん、何とも反応が難しい…

というのも、ご存知かもしれませんが、HSP自体に連想配列型っぽく添字を受け取る変数型のサポートがもう既にあります(HSPVAR_SUPPORT_ARRAYOBJ)
本当は公式が連想配列型を作るのを待つのが妥当ですが、今のところありません
しかし、非公式でよいのなら現時点でもその変数型をサポートするプラグインがあります

プログラ広場:連想配列 拡張プラグイン
http://prograpark.ninja-web.net/CollectField/index.html#var_assoc

個人的には、この状況下で「公式に入れてほしい連想配列プラグインを開発した」ということでしたら、既にあるものとはどう違うのかなども挙げると良いのではないでしょうか
例えば
 ・モジュール形式であるため移植性が高い(HSPDishでも使用に耐えうる)
 ・バグフィックスなどのサポートはいつまで可能であるか(メンテなど)
 ・どのような用途に対して特に有効であるか(あるいは、どの程度の用途までは使用に耐えうる実行速度であるか)
 …etc

あと、手間がかかるのは分かりますがヘルプはないと、F1で命令のリファレンスが見れないため普及は難しいのではないかと思います
最低でもヘルプファイル、余裕があるならドキュメントも書いてみてはいかがでしょうか

中身見た感じナイーブではあるがキーによるソートと二分探索を使った実装で、(思ったより)ちゃんと実装されてありますし
内部にストアされる変数はキーの型値->キー同士の大小関係順に並ぶなどの説明があってもいいかなと思いましたよ
連想配列をイテレートする時に列挙される順番に制約があるので、それに依存したコードを書けるか書けないかは定めたいところです(std::mapはキー同士の大小関係を定義すれば、その順番にイテレート可能な設計ですよね)
ついでに言うなら、mapで実装するならlower_bound、upper_boundあたりはあって欲しいですね(実行速度で見れば一般的にstd::unordered_mapの方が速いですよね)
ただ、この辺は仕様が変わる可能性があるのかもしれませんが…

少々愚痴っぽくなってしまい申し訳ありませんが、折角作ったのであれば妥当なアピールはして欲しいです



しますず

リンク

2014/2/1(Sat) 18:39:14|NO.59598

色々とありがとうございます

dll とか hpi とかのプラグインを必要とせずに
連想配列を標準で使えるようになりさえすれば
別に自分の作ったものでなくてもいいのですが…

さしあたって ヘルプファイルと lower_bound, upper_bound 相当についても作成しますが
いわゆるハッシュでの実装をする予定はありません

あとはユーザー定義の比較関数でソートするというのもできなくはないのですが
ユーザー側で若干気持ち悪いコードを書いてもらうことになるので避けたいところです


連想配列以外については
スタックとキューも欲しいとか
ソートも欲しいとか
文字列の比較についても大小比較(>=, >, <=, <) が使えるようにするか strcmp を標準にしてほしいとか
バイト単位ではなく sjis の文字単位で全角、半角混在でもちゃんと処理する関数を使いたいとか
grotate, gsquare で描画がバグる部分を直したいとか
実行ファイルに埋め込んだアルファ付 png をまともに読み込めるようにしたいとか
eval のような関数が欲しいとか

そういったいくつか気になる部分をどうにか「標準」でクリアできるようにしたいと思っており
簡単そうなモジュール形式での連想配列からはじめてみた次第です



しますず

リンク

2014/2/1(Sat) 19:18:21|NO.59599

3k さん
ユーザー定義の比較を使うとすると下のようになるんですが
これは許容範囲だと思いますか?

※便宜上コムソートにしています


// ソートライブラリ ここから #module comb_sort_mod #define global comb_sort_a s_cmp_a@comb_sort_mod #define global comb_sort_b s_cmp_b@comb_sort_mod #define global comb_sort(%1,%2,%3=0) s_var@comb_sort_mod=%3 : comb_sort_ %1,%2,s_var@comb_sort_mod #deffunc comb_sort_ array data, int data_num, var usercmp, \ local h, local is_changed, local cmp, local temp cmp=usercmp if vartype(cmp)!1 { if vartype(data)=vartype("str") { cmp=*cmp_str_default } else { cmp=*cmp_num_default } } h=data_num*10/13 repeat is_changed=0 repeat data_num-h dup s_cmp_a, data(cnt) dup s_cmp_b, data(cnt+h) gosub cmp if stat>0 { temp=data(cnt) data(cnt)=data(cnt+h) data(cnt+h)=temp is_changed=1 } loop if h>1 { h=h*10/13 } else { if is_changed=0 : break } loop return // デフォルトの比較関数 *cmp_num_default return comb_sort_a>comb_sort_b *cmp_str_default dim a dim b repeat a=peek(comb_sort_a, cnt) b=peek(comb_sort_b, cnt) if a=0 or a!b : break loop return a>b #global // ソートライブラリ ここまで /*============================================================ ============================================================*/ // 整数のソート dim data data=6,3,9,7,2,1,8,4,5 disp data comb_sort data, length(data) disp data comb_sort data, length(data), *cmp_num_descend disp data // 文字列のソート dim data data="banana", "grape", "apple", "meron", "strawberry" disp data comb_sort data, length(data) disp data comb_sort data, length(data), *cmp_str_descend disp data stop // 終了! // 数値用ユーザー定義比較関数? *cmp_num_descend return comb_sort_a<comb_sort_b // 文字列用ユーザー定義比較関数? *cmp_str_descend repeat a=peek(comb_sort_a, cnt) b=peek(comb_sort_b, cnt) if a=0 or a!b : break loop return a<b #module // データ表示 #deffunc disp array data, int data_num_, local data_num, local buf data_num=data_num_ if data_num<=0 : data_num=length(data) repeat data_num if cnt=0 { buf=str(data(cnt)) } else { buf+=", "+str(data(cnt)) } loop mes buf return #global



3k

リンク

2014/2/1(Sat) 21:05:32|NO.59602

あややん、名指しで呼ばれるとは…

> 3k さん
> ユーザー定義の比較を使うとすると下のようになるんですが
> これは許容範囲だと思いますか?
> ※便宜上コムソートにしています

ご提示頂いたスクリプトだと、恐らくユーザ視点から次の二つほど問題(気持ち悪いと思う点)があるという認識でいいんですかね
 1.ソートに渡す比較処理の実装がラベルである(#defcfuncなどの関数でない)
 2.ラベルは引数をとれないため比較するべき値として特定のマクロ(comb_sort_aとcomb_sort_b)を参照する必要がある

HSPというスクリプト言語として見た場合、ユーザ定義の比較処理を用いたソートの実装としてはおよそこの形になるでしょうね
なので、”HSPというスクリプト言語の実装として見るなら”特に問題があるようには思いません

私自身の言語感覚(というか何といいますか)の観点から述べるなら、「しょうがない」ですね
上述しましたが、この言語における実装としてはこれ以上にうまいやりようが特に思い浮かばないため、「気持ち悪い!」とは一瞬思ってもその後に「言語仕様から考えたらなるべくしてなった形だな」という考えに収束します
更に言うなら、同様の論理は実は既にoncmdやonclickで使われてますし、「今更」というツッコミになりますね(iparamやlparamなどはマクロではありませんが、コンテキストによって特殊な意味を持つ変数ですよね)

そもそも論になるのであまり話題としたくはないんですが、HSPではコールバック処理は非常に書きづらいと感じてます、個人的に関数はスクリプト言語っぽく格好良くファーストクラスにしてほしいぐらいです(やりすぎですかね)
しかし現時点でoncmdやonclickの使い方を鑑みるに、おにたまさんは言語仕様としてこの書き方を選んだという推論になるため、ここに関して突っ込むのは何となく野暮な話です

話が逸れました
結局私自身が「この実装は許容範囲か?」と聞かれたら、「(言語仕様から考えたらしょうがない、)YES」です


以下、その前の回答にて少々の誤解があったようなのでそれに対する補足など

> あとはユーザー定義の比較関数でソートするというのもできなくはないのですが
> ユーザー側で若干気持ち悪いコードを書いてもらうことになるので避けたいところです

私の書き方が悪かったため誤解させてしまったようですが、私が意図したのは「イテレートする時特定の順番で列挙される」性質をドキュメントに書いてはどうかという提案でした
比較関数云々の節は、「C++のstd::mapは(ユーザ定義の比較関数とかも使えるけど、それは置いといて、)とりあえず何らかの基準に則った順番でイテレート可能な仕様ですよね」という、仕様が存在するという例示でした


> そういったいくつか気になる部分をどうにか「標準」でクリアできるようにしたいと思っており
> 簡単そうなモジュール形式での連想配列からはじめてみた次第です

「標準」の捉え方にもよるので私の解釈違いなら申し訳ないですが、あくまで「標準で提供される機能」と捉えるならば、HSPの開発に参加して連想配列型を作成した方が心配も少なくメリットが大きくないですか?
HSPDishにおいてもコア部分の設計はWindows版と同様だと思いますし、実行速度においてもモジュールよりは速くなるでしょうし、プラグインとかと違って”最初から”HSPと一体になっているので煩わしい操作は必要ないですし
先に挙げられた他に修正したい点に関しても、同じくHSP本体のソースとしてマージした方が早いでしょうし、決して全HSPユーザにとってマイナスとなる点ではないように思いますが

あとこれは単なるお節介なんですが,何よりしますずさんは折角C/C++にも精通しておられるようなので、勿体ないように感じます
まあ、実際はHSP自体のコミッタになるのは実装した機能のテストとかもあるだろうし非常に敷居が高そうなので、これに関してはただの空言だと思って流して頂いて結構です、実際空言


以上、長い回答となってしまいました、長文駄文すみません



おにたま(管理人)

リンク

2014/2/3(Mon) 22:00:49|NO.59641

HSPによる自作ライブラリの公開ありがとうございます。
公式のフルセットに同梱するための正式な手順は特になく、
有用で安定しているライブラリに対してこちらからお願いをさせて頂いています。
連想配列や各種アルゴリズムの実装は、今後進めていきたいと思っていますので、
ご意見を頂いたり、今回のような製作物の公開なども歓迎しています。
(こういった話は、この掲示板でも良いですし、hsp-devメーリングリスト内でも構いません。)

私としては、連想配列やソート、検索など速度が必要なものについては、
標準の内蔵機能として持つのが一番良いように思っています。
命令の構成や機能の範囲など、皆さんの意見なども参考にしていきたいと考えています。



ONION software Copyright 1997-2021(c) All rights reserved.