V8.66β12 - 秀丸エディタβ版 - スレッド09200, 2016/11/02

秀丸担当 さん　16/11/02 12:55

V8.66β12を公開しました。

以下のページの「先行開発バージョンはこちら」からダウンロードできます。
http://hide.maruo.co.jp/software/hidemaru.html

32bit版：
http://hide.maruo.co.jp/software/bin/hm866b12_signed.exe

64bit版：
http://hide.maruo.co.jp/software/bin/hm866b12_x64_signed.exe

RE:09200 V8.66β12

天翔記.jp さん　16/11/02 16:08

ASTと「単項評価→複項評価」という基本原則を考えると
やむを得ないと思いますが、
とりあえず、最初のテストがこうなりました、という報告です。

例の\d等の警告関連で

//-----------------------------------------------------
$mes = @"
if "123" =~ /\d/ then
;
end
";

message($mes);
//-----------------------------------------------------

この時、本来間違っているのは、"123" → ""123""であり、
\dの方はむしろ
正しいわけですが、ASTとして分解された時には、

" =~ /\d/ then
;
end
"
として、分解されてしまっているので、\d系のエラーが優先されます。

(なのでこのエラーが先に出るのは仕方ない気がしまうねぇ…)

個人的には""問題があるので、よほど単純でない限りRしかつかわないので
あまり問題ではないのですが。

RE:09202 V8.66β12

秀丸担当 さん　16/11/02 17:23

$a= @"abc" 123 "def";
で出る警告は実行時の警告になります。

$a= @"abc" 123 "\def";
で出る警告はマクロのコンパイル時の警告になります。
コンパイル時が優先されてしまうため、仕方ないことになってしまいます。

しいて対策するとすれば、警告は必ずしも必要なものではないので、@""を使う
ようなケースでは、エスケープ等を熟知しているものとみなして、"\d"の警告そ
のものをやめてしまってもいいかもしれません。

RE:09203 V8.66β12

天翔記.jp さん　16/11/02 18:01

>
>$a= @"abc" 123 "def";
>で出る警告は実行時の警告になります。
>
>$a= @"abc" 123 "\def";
>で出る警告はマクロのコンパイル時の警告になります。
>コンパイル時が優先されてしまうため、仕方ないことになってしまいます。
単項、複項ではなく、\系は、実行時(の事前)コンパイルでのチェックだったんですね。

ん～そういうことであれば、
警告はこの順番で残しておくしかないかと思います。
(熟知していても、スクリプト等の慣れがある分付け忘れるのがデフォだと思うので)

そういえば、
@"abc" 123 "def";
がコンパイル通ってしまうのはなぜですか？

RE:09204 V8.66β12

秀丸担当 さん　16/11/04 09:16

>そういえば、
>@"abc" 123 "def";
>がコンパイル通ってしまうのはなぜですか？

コンパイルという言葉がちょっと適切ではなかったですが、テキストからマクロ
で解釈しやすい中間コードに変換するという単純な過程です。
このコンパイルの過程で文法もチェックすれば先に警告を出すことも不可能では
ないと思います。
ただもともと中間コードの意味が何であるかを理解して処理している実行時のほ
うがやりやすかったというだけになります。

一方で"\d"はコンパイルで"d"に変換されてしまっているため、実行時には判別
不可能なため、コンパイルの過程でしか判別不可能でした。

RE:09205 V8.66β12

天翔記.jp さん　16/11/04 11:23

>コンパイルという言葉がちょっと適切ではなかったですが、テキストからマクロ
>で解釈しやすい中間コードに変換するという単純な過程です。
了解です。

.cacheというのは該当の中間コードと完全に一致するものですか？

スクリプト言語の多くは、中間コードを事前に作成しておくことも自然と出来ますが
（どちらかと言えば、スクリプトをimportすると
内部的に出来上がる「チャンク」が実行される、
これを一般的には、実行時コンパイル＆実行等々と称するわけですが、
当然、このチャンクは明示的にファイルに書き出しす行為が可能であり、
一般的には、テキストままでも、このチャンクでもどちらでもimportして実行可能
となっているスクリプト言語が大半である、といった方が適切ですが）

秀丸マクロもまた、そのスタイルを採っていると考えればよいのでしょうか。
①テキストファイル→②中間コード（チャンク）→③普段はファイルに書き出さずメ
モリ上のみ→④実行

①ではなく②を直接読み込んでも実行が可能（.cacheを読み込んで実行可能)→今の
ところは、自動起動マクロ系の高速化の項でのみ存在を明示

RE:09206 V8.66β12

秀丸担当 さん　16/11/04 15:29

自動起動マクロの、.mac.cacheのファイルも、中間コードに相当するデータです。
中間コード以外にファイルのタイムスタンプ等の情報は付加されています。
いまのところ自動起動マクロ以外は対応していませんが、技術的には.mac.cache
のファイルを直接読み込んで実行させることもできないことはないです。

RE:09207 V8.66β12

天翔記.jp さん　16/11/04 17:02

>
≪全文引用されていたのでコミュニテックス会議室システムが引用部分を省略処理し
ました。≫
>のファイルを直接読み込んで実行させることもできないことはないです。
了解しました。
以前から若干疑問に思っていたところがいろいろわかりました。
ありがとうございます。

あと、
◎HIDEMARUINFO_GETFILEFULLPATH
　は昨日だったか動作確認できました。
　(新規作成の時に空文字なども)

◎周辺のマクロヘルプも整備されているのを確認しました。

△Hidemaru_GetDllFuncCalledType についは、
　マクロと絡めたようなサンプルをいくつか書いておいてあげた方が親切かもしれま
せん。
　（使い方が１系統ではないですし、４系統・５系統ぐらいの結構方向性の違った意
味に使うことも出来るので）

RE:09208 V8.66β12

秀丸担当 さん　16/11/04 17:28

ご確認ありがとうございます。
Hidemaru_GetDllFuncCalledTypeについてのサンプルはあったほうがいいと思い
ます。
今後追記したいと思います。

RE:09200 「dll側の関数の作り方」の説明

天翔記.jp さん　16/11/09 20:13

秀丸のマクロの「dll側の関数の作り方」のヘルプなんですが、

・わかりやすく、初学者がわかる構成すること
・実際のソースが秀丸32bit/64bitで共通にすること

が両立しくく難しい側面もあるのですが、
以下の点をもう少し明確に主張した方が、
最終的によりよい理想的なソースへの到達が早くなるように思えます。

・秀丸には32bitと64bit系が存在していること。
・32bitの秀丸マクロは数値型が4バイト(32bit)
・64bitの秀丸マクロは数値型が8バイト(64bit)
・よって、いわゆる「C++で単純にint型」を使って64bitでコンパイルしても秀丸(マ
クロ)の数値型とはビット幅が食い違うこと。
(プロセス=ポインタ幅が64bitになっても、通常はintの幅を32bitなのですが、
秀丸では数値型の幅を64bitに増やしていること)

(こうなっている理由はおそらく秀丸マクロにはポインタ型がないものの、ポイ
ンタ値をやりとりを数値型で済ませているためとは思いますが…)

現在のヘルプだと、秀丸のdllを作る際によくよく64bitの項目を正しく捉えない限り、
「なんとなくサンプル通り見よう見まねで記述して、int型を関数を作ってそのまま
externしてしまう」ように感じます。

・32bitでも64bitでも共通のC/C++ソースで済ますなら「intではなく、intptr_t」と
明示し、
intptr_tで書いたソースを実際にマニュアルに盛り込む。
「秀丸マクロ用のdll的には、intptr_tの使用を推奨する」

と言い切っても良いぐらいかと思います。
このほうが、結局は理想的な移植性の高いソースへの到達が早くなりそうです。

(今は64bitのところに、さらりとINT_PTRが触れられていますが、CでもC++でも標準
仕様とも言えるintptr_tで推してしまったほうが良いかと）

ただし、intptr_tといきなり記述しても、intと比べると知ってる人が
俄然少ないので、
「intptr_t」を見て「敷居が高い」と思わないような
記述順番の工夫は必要かと思います。

RE:09210 「dll側の関数の作り方」の説明

秀丸担当 さん　16/11/10 10:30

秀丸マクロは、確かに変数の格納は64bit版は8バイトです。

DLLの数値は32bit版/64bit版で確かに違いがあります。
引数に関しては、intと書いてもらってもレジスタやスタックがずれることはな
いので、一般的な数値を扱う限りでは表面上の問題はないです。
返り値に関しては、INT_PTRじゃないとマイナス値を返したときに問題がありま
す。ここは重要なので、少なくとも返り値の部分のヘルプやサンプルはコピペさ
れてもいいように修正したほうがよさそうです。

intptr_tは言われている通り敷居が高くなる気がするので、Win32アプリを作る
場合はWin32 APIもINT_PTR等の記述なので、INT_PTRの記述のほうが馴染みやす
いと思います。
ご意見参考にさせていただいて修正したいと思います。