(仮)クリーンHSPに関する議論 ver0.2

NO.77973 †

開発言語がC言語の流れですが

Cは後方交換性がやたら保たれてるイメージなんですが

別の環境への対応はどうなるんでしょうか

バイナリまんま動けばいいんですけども

そうとも限らず

Cだからソースコードを渡して

再コンパイルしてもらう流れになりそうですが

HSPはゲーム用途が多いので自分的にはちょっとなあ。です

現状もHSPの中間言語をHSPのソースコードに

ものすごい戻せるみたいですがｗ

（だからいいんじゃない？みたい感じなのかな？）

そういう意味でJAVAで開発するとしても

バーチャルマシンのバージョンによって

色々なバージョンに対応しなきゃですよね

JAVAもバイナリからソースコードに戻せるとかなんとかですし

Cで書いて

Ubuntu/debian/fedora/ラズパイ

くらいに作者がコンパイルして複数のバイナリをDLするとかがいいのかもですね

後winとMACと

gccなら変更なしでコンパイルはいけそうだと思ってます

Y_repeat氏　2017/1/18(Wed) 01:27:18

↑

NO.78010 †

せっかくスレを立てたので要望とか書きます

関数と命令が混在しててたまに頭がこんがらがるので

＃voiddefcfunc

とか

＃voidmodcfunc

とかの導入はどうでしょうか

返り値がvoidの関数です

メリットは

これらの導入で

引数とかの書式が()あるかんじで統一できます

自作言語の構想は

mingw+cyzwin(tcl/tk)の採用を調べてます

cyzwin導入の必須は敷居が高いですが

tcl/tkは結構好感持ってるんですよねー

HSP書式のGUIから大分離れちゃいそうですがｗ

近いかんじのとこはHSPに似せようとは思ってマス

＞dolphiliaさん

今回はtinyHSPとのことで

完成したら研究させてくださいねー

そしてそれよりもその次回作の方が楽しみです

5000行～10000行くらいの

中型言語を勝手に期待してますー

Y_repeat氏　2017/1/23(Mon) 03:01:14

↑

NO.78053 †

＞Y_repeat さん

スレッドの作成とコメントありがとうございます。

HSPはWindows10(x86,x64)で動作します。3.5からは動作環境に入れたいと考えています。

Windows版HSPのソースは、C/C++ですがWindows固有のライブラリに多く依存しているため、移植性はあまり良くありません。

hspcmp(コンパイラ)及びHSP3Dish関連(HGIMG4含む)は、ある程度移植性の良いライブラリを使用しているため、幅広く使用できるかと思います。

おにたま氏　2017/1/24(Tue) 23:03:05

↑

NO.78066 †

おはこんばんは

＞作者様へ

回答ありがとうございます

近いうちにWindows10に上げようと思います

Windows10は有効期限が無期限とかどっかで読んで　それで

導入してみたくなりました

大体10年はWindowsOSの有効期限あるかんじではありますが^^;

少々の移植性のなさならifdefマクロとかで

マクロで切り替えて記述出来るよなー

とは思いました

HSP3Dishのライブラリはそういう意味で転用させてもらおうかな？

と思いましたが　案外大きいんですね

openHSPザックリ眺めただけですが

何が理解を阻むのかと言えば

全体的に理解したいと思ってソースコードを読むから理解できないっぽいです

目的意識がぼやけてます

後、規模の割と大きいソースコード読んだことないですし

そういう意味では広げた風呂敷を包む

規模を圧縮したライブラリ構成のライブラリは存在価値あると思います

Y_repeat氏　2017/1/26(Thu) 03:55:06

↑

NO.78095 †

クリーンなHSPについて、

あまり討議されていな論題を中心に考えてみました。

1. 作ると仮定した際の専用エディターの仕様

2. 作ると仮定した際の専用エディターの実装方法

3. 作品の配布の支援についての検討

4. 作品の配布の支援のためのサーバーについての検討

－－－－

1. 作ると仮定した際の専用エディターの仕様

最低限の仕様は、以下のようなものです。

・スクリプトの編集

・保存と読み込み

・コンパイルと実行（コンパイラとエンジンの起動）

・何らかの方法での作品の配布の支援

・標準の文字コードはUTF-8

あるに越したことはない、その他の仕様は以下の通りです。

・行番号の表示

・シンタックスハイライト

・検索と置き換え

・コードの折りたたみ

・オートセーブ（自動保存）

・オートコンプリート（入力補完）

・自動インデント

・フォント・カラーのテーマの変更

・プリント（印刷）

・改行コード・エンコーディングの変更

・行の折り返しの設定

・ソース情報の表示（行数・文字数）

・キーバインド（ワンキーヘルプ、F5起動など）

・ etc...

－－－

2. 作ると仮定した際の専用エディターの実装方法

次のような選択肢が考えられます。

・各OSごと個別に作る

・ Electronのようなマルチプラットフォーム環境で作る

Windows版のエディターを移植するという選択肢は、

移植性の関係でおそらくないと思われます。

－－－

3. 作品の配布の支援についての検討

次のような選択肢が考えられます。

・実行ファイルを作成する機能

・配布用の実行エンジンを用意して、中間言語等をパックする

・配布用のプロジェクトを用意して、中間言語等をパックする

・ HSPTV、HSP部屋のようなサーバーと連携する

１つ目の方法が理想ですが、

Windows以外のOSでは難しいと思われます。

２つ目は、

実行エンジンと同じフォルダ内に、

パックしたファイルあるいは生成した中間言語を置いて、

ZIP等などに圧縮して配布するパターンです。

３つ目は、

用意されたVisualStudio?などのプロジェクトをダウンロードして、

各自でコンパイル・リリースしてもらうパターンです。

開発環境を導入する手間がありますが、

WindowsストアやApp Storeでの配布を視野に入れることができます。

４つ目は、

HSPTVブラウザやHSP部屋のような作品を共有できるサイトに、

作品をアップロードできる機能をエディターに内蔵するパターンです。

モバイル版を念頭に置いた仕様です。

－－－

4. 作品の配布の支援のためのサーバーについての検討

モバイル版のHSPでは実行ファイルを生成することができないので、作品をアップできるサーバーが必要になると思われます。それはちょうどHSPTVブラウザやHSP部屋のようなものです。

－－－

以上です。

dolphilia氏　2017/1/29(Sun) 13:54:50

↑

NO.78097 †

dolphiliaさん

＞ 3. 作品の配布の支援についての検討

ソースファイルやデータファイルを移行すればOKでしょ！とだけ

HSP導入済を前提に考えてましたが、配布支援があるにこしたことはないですね。

＞ - 配布用の実行エンジンを用意して、中間言語等をパックする

これは某RPGツクールなんかでもやってる方式ですかね？

個人的にはこちらが妥当なセンかなと考えます。

kikeroga氏　2017/1/30(Mon) 13:02:18

↑

NO.78098 †

＞ dolphiliaさん

＞専用エディター

別にいらなそうだな。とは思いました

既存のエディタの外部実行で

シェルかなんか書けば実行できそうな気がします

vimとかだと簡単に実装出来そう

cとかperlとかvimから簡単に実行出来たような

そういう意味ではHSP+Emacsとか憧れるなーｗ

ちょっと練習した程度です。自分→Emacs

＞＞実行ファイルを作成する機能

＞１つ目の方法が理想ですが、

＞Windows以外のOSでは難しいと思われます。

自分の予定だとCのコードジェネレータぽくしたいので

生成したCのコードをgccでコンパイルしたいです

最適化すれば逆コンパイルもしにくそう

代表的のOSごとにコンパイルして配布的な

gccでコンパイル出来ればOSは選ばない的な言語だとね

コードジェネレータぽくしたいので

C言語まんまを中間言語にするのも大変そうなので

自分だと中間言語には翻訳したくないよーな

って書いてるの中間言語の段階ですが

って

kikerogaさんの意見だと

＞これは某RPGツクールなんかでもやってる方式ですかね？

RPGツクールもRuby採用してるので

C言語まんまでも包めるかもしれませんね

自分的言語の長期的展望では

RPGツクールぽくしたくもあるんですよね

Y_repeat氏　2017/1/30(Mon) 17:57:33

↑

NO.78102 †

kikerogaさん、ご意見ありがとうございます。

＞ HSP導入済を前提に考えてましたが

そういえば最初に提案された資料にそう書いてありましたね。

＞ソースファイルやデータファイルを移行すればOK

たしかにコードとデータのみの配布だけで完結できたら、

クールでいいなあ、と思います。

Y_repeatさん、ご意見ありがとうございます。

＞自分の予定だとCのコードジェネレータぽくしたいので

C言語へのコードジェネレータ、いい考えですね。

私も以前に、

Javascript風のコードをHSPコードに変換する、

コード変換器を作ったことがありました。

http://dolphilia.github.io/althsp/

正規表現を使って、

無理やり置き換えするというもので、

速度と精度の面で難がある、

いわば失敗作なのですが。;^^

クリーンなHSPについて、考えたことの続きです。

1. 対象となるユーザー層は？

2. オブジェクトファイルを生成するべきか

3. フィードバックに関する葛藤

4. クリーンさを最重要視すると仮定した場合の考え

5. 必要最低限の拡張

1. 対象となるユーザー層は？

クリーンHSPの対象とするユーザーはどのような人たちなのでしょうか。

HSP経験者でしょうか。

・ HSPユーザー

・非HSPユーザー

プログラミングをどの程度たしなむでしょうか。

・初心者（プログラミングは初めて）

・初級者（少しは触ったことがある）

・中級者（ある程度の作品を作ったことがある）

・上級者（業務あるいは趣味として日常的に書いている）

私は「非HSPユーザー」で「プログラミング初心者」を想定していましたが、

（それで「スマホでゲームが作れる」などの提案をした次第です）

もしかすると、むしろHSPのヘビーユーザーを対象しているのかも、

とも思い、考えが揺れています。

2. オブジェクトファイルを生成するべきか

本家HSPはaxファイルを生成します。

そのようなわけで、

クリーンなHSPも、それに倣うべきとは思いますが、

生成しないパターンについても考慮しています。

オブジェクトファイルを生成しないメリットは、

セキュリティが若干向上することです。

オブジェクトファイルが汚染されている可能性を、

チェックする手間が省けるからです。

オブジェクトファイルを生成するメリットは、

速度が向上することと、

実行エンジンの実装が若干簡潔になるです（たぶん）。

3. フィードバックに関する葛藤

クリーンなHSPの成果を、

本家にフィードバックしたいという思いと、

その難しさの間で葛藤があります。

本家のOpenHSPに直接コミットするのが、

一番手っ取り早い方法だと思います。

とはいえ、

全く別のプロジェクトとしてフォークしてしまった方が、

作業はやりやすいと感じています。

しかし、そうなると、

本家HSPでの更新を手動で反映させなければならなくなる、

という課題が出てきます。

そしてそれは、元のコードを改変すればするほど、

難しくなっていきます。

本家HSPと足並みを揃えたいという思いはありますが、

現実的なところ難しいので、そこは妥協するしかないのかな、

と考えています。

何か良い方法があるでしょうか。

4. クリーンさを最重要視すると仮定した場合の考え

前スレッドで「機能拡張はしない」とありましたが、

ここは仮に、クリーンさを最重要視するものと仮定して、

考えを進めてみます。

前スレッドでダウンロードできる、

sakuraさんの作成した資料を見ていると、

よりクリーンにできそうな仕様がいくつか見つかります。

例えば、カレント情報を扱う命令を挙げると（posなど）、

新たに、サイズのカレント情報を扱うsize命令があっても良いような気がします。

他に、font命令は、

第3パラメータに16を指定することでアンチエイリアシングを指定できますが、

それをくくり出して、smooth命令などに置き換えるのは、

クリーンなやり方のように思えます。

スムージングのカレント情報とも捉えることができるので、

line命令などにも適用できるからです。

5. 必要最低限の拡張

OS情報の取得

HiDPIへの対応

上の２つはマルチプラットフォームにする上で、

拡張する必要のある機能だと思っています。

dolphilia氏　2017/2/2(Thu) 14:43:26

↑

NO.78120 †

自分なりの考えという範囲内においての意見です

＞1. 対象となるユーザー層は？

HSPユーザーか非ユーザーかは区別しないでいいと思います

でもベーシックに好意を持ってる人だと思います

＞プログラミングをどの程度たしなむでしょうか。

＞- 初級者（少しは触ったことがある）

以上

＞- 中級者（ある程度の作品を作ったことがある）

以下だと思います

HSPを改造したい人向けだと思います

改造したいけど　HSPも結構規模が大きい故に

コンパクトな言語が欲しいというかんじだと思います

僕の考えの中では

＞2. オブジェクトファイルを生成するべきか

作る人の判断に委ねた方がいいと思います

自分的には　自動的に作って　コンパイルが終わったら

自動的に削除した方がいいんなじゃいかな？と思います

HSP本家も含めて

＞3. フィードバックに関する葛藤

フィードバックは必須ではない。と思います

考えてたら　作成の進むも遅くなりそうです

でもこういう場所で意見を書いていたら

本家に取り込まれるかもしれませんね

＞4. クリーンさを最重要視すると仮定した場合の考え

作る人が必要と思う機能なら付け加えるべきではないでしょうか

そういう意味で　改造のしやすい言語というのが

僕なりのクリーンＨＳＰの位置づけです

Y_repeat氏　2017/2/4(Sat) 00:57:10

↑

NO.78255 †

＞dolphilia さん

＞クリーンなHSPの成果を、

＞本家にフィードバックしたいという思いと、

＞その難しさの間で葛藤があります。

HSPへのフィードバックは必ずしも求めているわけではないので、あまり気にしないでおいてください。

まったく新しいソースコードやツールなどであっても、こちらで流用可能なものであれば積極的に取り入れますし、独自に進化することもまた1つの道だと考えています。

最終的には、ユーザーにとって快適に利用できるか、わかりやすいかなどが重要で、クリーンなことがそこに寄与することを願っています。

おにたま氏　2017/2/13(Mon) 01:06:44

↑

NO.78264 †

このスレッドに書く内容かどうか少し迷いましたが…

遊んでいるうちに体裁が整ってきたので一応お知らせしたく。

neteruhsp(exrdさん)→TinyHSP9号(dolphiliaさん)→ときたものを、

ほんのちょっとだけ弄らせていただいたTinyHSPタイニー版です。

tinyhsp tiny版

https://github.com/kikeroga3/tinyhsp

尚、ソース(tinyhsp.cpp)はクロスプラットフォームなハズらしいので

macOS版、Linux版のバイナリ作れる方がおられましたら是非お願い致します。

「サンプルスクリプト作ったよー」という方もお待ちしております。

追加させていただきます。

※(注)

　皆さんの期待しているもっと機能多めのクリーンなHSPではありません。

【謝辞】

exrdさん、dolphiliaさんのバイナリも完成されたものです。

TinyHSPタイニー版は、まさに人の褌で相撲取ってますので exrdさん、dolphiliaさんに深謝致します。

それではー(^_^)/

kikeroga氏　2017/2/15(Wed) 15:33:03

↑

NO.78417 †

現在超多忙（HSP掲示板見るの何ヶ月ぶりだ……？）につき始めはしないけど。

HSP + C++ + Qt = マルチパラダイム・マルチプラットフォームなHSP？

想定される下記の質問

1. 対象となるユーザー層は？

クリーンHSPの対象とするユーザーは

・ HSPユーザー

・非HSPユーザー

両方。Qtの敷居を下げるついでに。

プログラミングをどの程度たしなむでしょうか。

・中級者（ある程度の作品を作ったことがある）

・上級者（業務あるいは趣味として日常的に書いている）

をターゲットとする。C++の敷居の高さが原因。ただ、そうでなければHSP++系を選ぶことはないだろう。

2. オブジェクトファイルを生成するべきか

しません。OSごとにオブジェクトファイルを生成してください。

3. フィードバックに関する葛藤

もしかしたらできるかも？　(新機能の作り方に互換性があればの話。普通は無理)

4. クリーンさを最重要視すると仮定した場合の考え

オブジェクト指向を利用した合理的な考え方の導入、及び手続き型への簡易対応（HSPユーザー向け）

5. 必要最低限の拡張

・ OS情報の取得

・ HiDPIへの対応

多分できる

6. 問題点

ディスアセンブル禁止条項がどう考えても埋め込めない（QtがLGPLなため）

難解なC++を(HSPライクラッパーがあるとはいえ)直接触るというハードな仕様

Velgail氏　2017/3/7(Tue) 21:26:48

↑

NO.78564 †

モジュールを書いたスクリプトのその下にサンプルも付属しているスクリプトがあった時

#if 0 - #end で囲むのは一つの手法ですが、何かと0→1の書き換えが面倒です。

以下のような命令があれば公開するときもそのまま公開できるので便利な気がします

#module hogehoge
#global
//以下サンプル
#ifself
//この間は他のスクリプトから読み込まれたときは実行しない。
#endif

けものみち氏 2017/3/17(Fri) 03:23:51

↑

NO.78653 †

こんばんわ

返信ありがとうございます

＞けものみちさん

要するにプログラムブルなマクロがあればいいと思います

現在のマクロは置き換えるだけですし

というのも上から順に1、2、3～と連番振るのも大変なので

プログラムブルにマクロしたかったり

自分は

フラグ立てて上から順に代入してるかんじです

それでLINEマクロから連番求めてます

秀丸のマクロでなんとかならないかな？とか

けものみちさんの場合

グローバルなマクロを一つ定義するFILEを用意して

0と1を切り替えたいFILEからincludeして

1にしたい時はグローバルなマクロを一つ定義しているFILEを書き換えてから

実行してはどうですか

それらをバッチファイルにして

1にしたい時は外部FILEでバッチファイルを実行するかんじで

バッチ処理サンプルっす

http://seesaawiki.jp/zuzazann/d/bat%20HSP

でもプログラムブルなマクロってそそられます

テキスト+自力マクロってテーマは

挑戦してみたいかな。とはずっと抱えてやってます

環境はHSPでやるかは未定ですが

HSPスクリプトのジェネレートという形で還元できないかな。とも思っています

＞堀木さん

返信ありがとうございます

もう少し考えてから返信いたします

Y_repeat氏 2017/3/24(Fri) 23:59:19

↑

NO.78789 †

＞ Linux版dish発表ありましたな

きましたね、遂に！

ライブラリ導入前提ビルドなのが若干敷居が高いですが、

RasPi?のほうが恐らくMainDish?とみました(^o^)

HSPの可能性がさらに広がりそうで、これからが楽しみです

kikeroga氏 2017/4/1(Sat) 22:12:58

↑

NO.78782 †

Linux版dish発表ありましたな

4/1のジョークなんじゃないかというのが気になるところですｗ

なんか作者様に丸投げしてるっぽい状態なのが申し訳ないです

自分も最近、全く使用してないUbuntuでやってみよっかなー。です

実は最近ラズパイも気になってまして

こうなったら購入に踏み切った方がいいのかな？

開発中のplus moduleはLongInt?が再配布可なのかよくわからないので

大きい桁を扱うdoubleのモジュールも開発中に加えてみましたです

自分HSPに適正ないんじゃないか？疑惑で

しゃばいスクリプトでお恥ずかしいですが

http://zuzazann.boy.jp/media_wiki_120/index.php?title=Plus_modules

Y_repeat氏 2017/4/1(Sat) 06:54:52

↑

NO.79057 †

おはこんばんわ

他の要望だと

アクセサメソッドとか欲しいっすね

割と簡単に実装出来そうな出来なそうなｗ

後は変数とか命令とかで

一文字違いのソレを検索したいですね

タイポのほとんどは一文字打ち間違いとか

言うような言わないような。なので

これはHSPに実装されないでも

ツールとかで実現出来そうな出来なそうなｗ

Y_repeat氏 2017/4/10(Mon) 05:10:12

↑

NO.79088 †

＞＞アクセサメソッド

＞どのオブジェクトの？

HSPのモジュール変数のですね

Rubyとかだと簡単にメンバのアクセサメソッド定義できますよね

＞＞一文字違い

＞文字列距離という言葉で検索すれば結構簡単に出てくるはず。

なるほどひっかかりました

完成せずとも途中まででも自力でやってみますｗ

Y_repeat氏 2017/4/12(Wed) 12:07:15

Top / (仮)クリーンHSPに関する議論 ver0.2
(仮)クリーンHSPに関する議論 ver0.2

最新の20件

NO.77973 †

NO.78010 †

NO.78053 †

NO.78066 †

NO.78095 †

NO.78097 †

NO.78098 †

NO.78102 †

NO.78120 †

NO.78255 †

NO.78264 †

NO.78417 †

NO.78564 †

NO.78653 †

NO.78789 †

NO.78782 †

NO.79057 †

NO.79088 †

Top / (仮)クリーンHSPに関する議論 ver0.2(仮)クリーンHSPに関する議論 ver0.2

最新の20件

NO.77973 †

NO.78010 †

NO.78053 †

NO.78066 †

NO.78095 †

NO.78097 †

NO.78098 †

NO.78102 †

NO.78120 †

NO.78255 †

NO.78264 †

NO.78417 †

NO.78564 †

NO.78653 †

NO.78789 †

NO.78782 †

NO.79057 †

NO.79088 †

Top / (仮)クリーンHSPに関する議論 ver0.2
(仮)クリーンHSPに関する議論 ver0.2