search

stuncloud / UWSCR

UWSC互換スクリプト実行ツール
MIT License
49 stars 4 forks source link

FGETで数字・数値を他の文字列と区別しない事, 及びそれに付随する数字・数値の仕様について（Inputを含む) #204

Closed DIYJii closed 2 weeks ago

DIYJii commented 3 weeks ago

概要

先般の本題関連の議論の後、UWSCの未解明領域の仕様の解析が根本解決のカギと考え、徹底調査しましたので、 その結果をレポートします。なお、言語レベルでの調査ではなく、InputとOutputからの推測ですので、間違っている点も あるかも知れない事を断っておきます。

(もう少し整理してからと思ったのですが、#201が急展開しそうなので、それと合わせて考えて貰うよう急遽送ります）

先ずは仕様の大まかな纏めから。

UWSC：

UWSCR:

調査の詳細については文末の備考欄の補足資料を参照してください。

この調査で使ったUWSCのVer 1.0　1999/10/01 以来のバージョン更新の発表メモを一つにまとめたものUWSCBug修正.txt を添付しておきます。メモ帳検索で過去の経緯が簡単に調べられるので便利ですよ。

次に、この仕様の違いによって、UWSCとUWSCRの間でどんな変化が生じたかを調べてみたのが、以下の再現スクリプト のリストです。　その後、備考欄に話は続きます。

UWSCBug修正.txt TESTASTRLog.txt TESTASTRuws.txt EqTESTuws.txt EqUWSC.txt EqUWSCR.txt

再現スクリプト

　f_Id =  FOPEN("TestFile.csv",  F_Read or F_Write)

//１．FGETとは関係ない数字までが数値変換され、文字結合であるべきものが加算になってしまう。
//   （UWSCは「+」演算で数字（VAR_USTR）->数値の変換はしない）

    　a = "2"                   // UWSCR     UWSC
　    Print (1 + a)    　   　  //   3        12               

//２．数字が「+」の左右どちらの辺に有るかによって演算結果が変わる。
//　　（UWSCでは「+」の左右の区別は無く、又FGETでダブルクオートで囲まれていない数字・数値は数値扱い）

　　　　　　　　　　　　　　　　 　　　　　　　    //UWSCR　          UWSC　　
　　　Print （"1" + 2） 　   　　　　　　　　    　//  12    　        12
      Print (  1 + "2")     　　　　　　　　　 　  //   3              12

　　　FPUT(f_Id,1,1,1)　
      Print (FGET(f_Id,1,1) + 2 )                  //  12               3
      Print (2 + FGET(f_Id,1,1) )                  //   3               3

//３．CSVファイルのダブル・クオートで囲まれた数字が数値として扱われる

    FPUT(f_Id,"08,<#DBL>08<#DBL>",1)
                                                   //UWSCR    　       UWSC
    PRINT (2024 + FGET(f_Id,1,1))                  // 2032            2032      
    PRINT (2024 + FGET(f_Id,1,2))                  // 2032            202408

//４．If文で数字を含む大小比較結果がUWSCと異なる。
//　　　(UWSCは同じ型同士なら其の型での比較、でなければ文字コードで比較？）

　　　If "01" > "1" Then 
        Print "<#DBL>01<#DBL> > <#DBL>1<#DBL>" 
      ElseIf "01" < "1" Then 
        Print "<#DBL>01<#DBL> < <#DBL>1<#DBL>"     //     UWSCR         UWSC
      EndIf                                        //  "01" > "1"    "01" <  "1"  

　　　If "01" > 1 Then 
        Print "<#DBL>01<#DBL> > 1" 
      ElseIf "01" < 1 Then 
        Print "<#DBL>01<#DBL> < 1"                 //     UWSCR         UWSC
      EndIf                                        //   "01" > 1     "01" <   1  

//５．If文で左辺と右辺を入れ替えると　二律背反の結果が返って来る

　　　If "02" > "2" Then 
        Print "<#DBL>02<#DBL> > <#DBL>2<#DBL>" 
      ElseIf "02" < "2" Then 
        Print "<#DBL>02<#DBL> < <#DBL>2<#DBL>"     //     UWSCR         UWSC
      EndIf                                        //  "02" > "2"    "02" <  "2"  

　　　If "2" > "02" Then 
        Print "<#DBL>2<#DBL> > <#DBL>02<#DBL>" 
      ElseIf "2" < "02" Then 
        Print "<#DBL>2<#DBL> < <#DBL>02<#DBL>"     //     UWSCR         UWSC
      EndIf                                        //   "2" > "02"    "2" >  "02"  

//　　（４.５．は全ケースを網羅したコードがEqTEST.uwsと、そのLogがEqUWSC.txtとEqUWSCR.txtに入っています。）

//６．FORMATでFGETの数字・数値は文字扱いになる　（UWSCではダブルクオートで囲まれていない数字・数値は数値扱い）

　 　 FPUT(f_Id,12.3,1,1)                                   //    UWSCR         UWSC 
      Print ("@" +  FORMAT(FGET(f_Id,1,1),8) + "@")         //  @12.312.3@    @    12.3@       

//７．CALCARRAYでFGETの数字・数値は文字扱いになる（UWSCではダブルクオートで囲まれていない数字・数値は数値扱い）

     FPUT(f_Id,"1,2,3",1)     
   　Dim fuga[] = FGET(f_Id,1,1),FGET(f_Id,1,2),FGET(f_Id,1,3)
                                                             //    UWSCR          UWSC 
　   Print CALCARRAY(fuga,CALC_ADD)                          //    Empty           6 

//８．QSORTで数字配列が数値扱いのSortになる。（UWSCでは配列要素の型に合わせてSort)

    Dim A[] = "10","03","2","1"　;    QSort(A)　
                                                             //      UWSCR                  UWSC
    Print A[0] + "  " + A[1] + "  " + A[2] + "  " + A[3]   　// "1" "2" "03" "10"     "03" "1" "10" "2"

再現手順

No response

回避方法

No response

備考

と云う事で、単にFGETしたものにVALを掛けるなり、＃１９６で予定のFGETに数値変換フラグを設けるにしても、 上記６．と７．ぐらいが解決されるのみで、型に関する根本な解決には至らない事になります。 型で分類されていないファイルの文字データと、スクリプト内できちっと型宣言されているものが混在しているところに、 数値変換出来るものは数値変換するという方式を持ち込んだ結果ではないでしょうか？

前回、私の提案した数値変換可能な物は変換する方法の拡大適用もダメでした。 小手先の対応は、後々に禍根を残すことになるので、かえって却下されて良かったのかも知れませんね。スンマセンでした。

なお、INPUT関数でもFGETと同じように数字入力はVAR_ASTR（２５６）型で返ってきます。 POSACCは数字でもVAR_UASTR（２５８）扱いです。 EXCELの方は、UWSCはFree版しか持っていないのでテスト出来ていません。

この問題を解決するのはしんどいでしょうが、下のURLを読んでみて下さい。どんな人達が、これからあなたのビッグ・ユー ザーになるのかがよく判ると思います。私が、今迄色々うるさい事を言ってきた理由もこの事が有るからなのです。日本社会 の発展の為に,ぜひ頑張って下さい。 https://note.com/rpa_uwsc_user/n/n080849bc3702

最後に、２５６と２５８の間が開いてますよね。　２５６は昔からあったことから、Unicodeがその番号を使えないで２５８ になったという事は、何かがそこにあるからなのですねー。２５７もVer　５.０.０以前からあった事になりますよね。 いったいUmiumiさんは２５７に何を隠していったのでしょうかねー？？？

===================================================================================== 補足資料：

今回調査で判った事の詳細を列記します。

１．UWSC　仕様（推測）の詳細

２．「VAR_ASTRとVAR_USTRで挙動が変わるのはUWSCがおかしい、つまりバグと見なしている」との見解に関して

　　　（添付のTESTASTR.uwsをVer 4.3aで走らせたLogがTESTASRLog.txtです。）

https://docwiki.embarcadero.com/RADStudio/Sydney/ja/%E6%96%87%E5%AD%97%E5%88%97%E5%9E%8B%EF%BC%88Delphi%EF%BC%89
より抜粋

　　　 ということで、VAR_ASTRはDelphiのAnsiString型、またVAR_USTRはUnicodeString型であると判断してほぼ間違いな 　　　 いようです。

　 　https://junjun777.hatenablog.com/entry/20140531/uwsc_ustr_astr　　より抜粋

　　これを関数で利用すれば、引数要件が数字の関数では無条件で引数にEmptyを付けてやるようにすれば、簡単にUSTRに変 　　わって、処理が簡単に出来るように思います。USTRや数値型にEmptyを付けても無害ですし。

　 ３．CSVファイルについて CSVファイルは企業間の異なるアプリ同士の橋渡しとなる事もありますが、その歴史的背景から、統一的なText Format の規約は基本的な部分に留まり、EXCELの様なセルごとに数値や文字などの型を表す構造にはなっていません。CSVデータ には頭に0が付く事も有る電話番号や伝票番号のようなコードを表す数字データと、金額や個数を表す数値データが混在 する事から数値と数字の区別がつかないと頭の０が落ちてしまったり、Sortで正しくない順になったりする事になります。

私の知る限りCSVファイルには少なくとも以下のような３つのTEXTのFormatが有ります。

　UWSCではBのダブル・クオートの付いたものはVAR_USTRにしていますが、Cのケースについては対応し ていません。この方式は昔のEXCELでは用いられてなかった可能性が有ります。

ところで、これ役に立ちませんか？

Python/Pandasなら文字数値混在csvも簡単読み込み! https://watlab-blog.com/2019/09/04/pandas-csv/

バージョン

1.0.2

不具合発生環境

No response

stuncloud commented 3 weeks ago

文字列型の実装方針

UWSCRには二通りの文字列型はないため、UWSCにおけるVAR_USTR、VAR_ASTRのいずれかの仕様のみを採用する UWSCではVAR_USTRが標準であることから、その仕様に合わせる この決定は覆らないです

issueについて

bug ラベルをつけて報告するなら発生する現象をひとつのissueにつき一点報告してください

そしてこれはバグ報告には見えないんですけど なんなんでしょうか

それと、文体が読みにくい上に長すぎます もしかしたら後で目を通すかもしれないですが、今のところこれを読む気はないです もうちょっと読みやすくできないですかね…

言語仕様の実装方針

この際はっきり言いますが @DIYJii さんような素人を基準に言語の実装を行うつもりは開発当初からありません 言語の仕様を理解し使いこなそうという気がなく言語側のレベルを自分並みに落とせという要求を、言語開発者がはいそうですねと受け入れると思いますか？

UWSCを使いましょう

おそらく今のUWSCRはあなた向けのアプリケーションではありません WindowsがWindowsである限り、UWSCが使えなくなることはありません そして、UWSCであれば今までの資産 (スクリプト) がそのまま理想通りに動きます わざわざ面倒な思いをしながらUWSCR用にスクリプトを書き直す必要もなくなります

UWSCRが必要なのはUWSCの不便さから解放されたい人を想定してましたが、UWSCで十分なのであればUWSCを使うべきです

Better UWSCRという選択肢

UWSCはこれ以上使えないというやむを得ない理由があるのならば残る選択肢はこれしかありません

UWSCRはソースが公開されており、またMITライセンスであることから第三者がこれといった制限もなく自由に使うことができます つまり、僕の実装が気に入らなければ自分なりの実装を盛り込んだ (あなたにとって) より良いUWSCRを作れるということです また、それを公開して (あなたの想定する) より良いUWSCRを求めるユーザーに届けてあげてください

むしろ、あなたにはそれをやる義務すらあると思います あれほど大口を叩き、しかし全ての責任は僕になすりつけるようなやり方をする暇があるのならば、自ら手を動かしあなたの正義を実現してください あなたの言う多くのユーザーがあなたの言う理想のUWSCRを待っています

あなたがすべきことはあなたの言う事に耳を貸さない愚かな開発者を説き伏せようとすることではなく、あなたの中にあるUWSCRの本来あるべき姿をこの世に具体化することです

今すぐこのリポジトリをforkしてやることやりましょう！ね！

そんでこのわけわからんissueはcloseしてもらえると助かる

DIYJii commented 3 weeks ago

大本の原因は１つ、ファイル・データの数字や数値を検出せずに全て文字型としてFGETの戻り値にしている事。それによって、 式や関数が統一性の無い「型」の扱い方をして起きている不具合が８つ、合計９つのバグです。 この場合、１つのReportでまとめて揚げるのが適切だと判断しました。一つずつ上げたのでは、適切な解決策に至りません。 でも、必要なら、１つずつ、ここ#204をRefしてIssueを上げますけど。

最後まで、読んでもらわないと話は伝わらず、議論にもなりません。 大筋はこうです。

調査したのは＃１９４で

当方が 「UWSCではファイル・データの数値、数字はANSI文字列となっており、数字以外の文字のUNICODE文字列とは区別する 事で、演算に於ける数値化のコントロールを行っているように見えます。」 とレポートしたところ 「VAR_ASTRとVAR_USTRで挙動が変わるのはUWSCがおかしい、つまりバグと見なしているのでUWSCRでは採用しません」

という回答が有った事で、長い間使われてきたUWSCにそんな根本的な所にバグがあるのだろうかとの疑問が生じたのが理由です。

結果、バグではないという事、そしてANSI型を含む数字・数値の型や関数、式の仕様について判った事、更に調査結果を元に 幅広くUWSCRを調べてみると新しく8つの問題が見つかったという事を今回書いたわけです。

それから、ANSI文字型を使えと言っている訳ではないですよ。 ファイル・データの数字や数値を表すTYPE_NUMBER_On_Fileとかいう型を新たに作るのでも良いのではないのですか？

責任を貴方に押し付けるつもりなら、何も、私の貴重な時間を長時間使って調べる訳ないでしょ。 RustやPythonが書けない分、こうやって調査で協力しているのが分からないのですか？ 私は、企業でいえば、良い製品を出す為の、品質管理部門のつもりでやっている訳ですから。 品質管理の人達は、別に、製品の設計が出来る訳でもなく、ただ、お客様視点で改善点を指摘する訳です。

UWSCの名を冠する限り、誰でもUWSCとほぼ同じと思って使ってみようとします。特に、UWSCRの宣伝文句を読めばね。 もしUWSCRが別の名前だったら、私もこんなことは言わないし、たまたまUWSCで検索したら、UWSCRが出てきて知った訳で、 そうでなければ,4月にここに来てたかどうかも分かりません。ビジネス系の人達に使われる事を想定すると、この問題は今の内に すっきりさせて置いたほうが良いのではないでしょうか。この人たち一人一人に、貴方の使用目的にはUWSCRは向いていません と言う訳にもいかないですし。

On Fri, Aug 23, 2024 at 6:25 PM Joey Takahashi @.***> wrote:

文字列型の実装方針

UWSCRには二通りの文字列型はないため、UWSCにおけるVAR_USTR、VAR_ASTRのいずれかの仕様のみを採用する UWSCではVAR_USTRが標準であることから、その仕様に合わせる この決定は覆らないです issueについて

bug ラベルをつけて報告するなら発生する現象をひとつのissueにつき一点報告してください

そしてこれはバグ報告には見えないんですけど なんなんでしょうか

それと、文体が読みにくい上に長すぎます もしかしたら後で目を通すかもしれないですが、今のところこれを読む気はないです もうちょっと読みやすくできないですかね… 言語仕様の実装方針

この際はっきり言いますが @DIYJii https://github.com/DIYJii さんような素人を基準に言語の実装を行うつもりは開発当初からありません 言語の仕様を理解し使いこなそうという気がなく言語側のレベルを自分並みに落とせという要求を、言語開発者がはいそうですねと受け入れると思いますか？ UWSCを使いましょう

おそらく今のUWSCRはあなた向けのアプリケーションではありません WindowsがWindowsである限り、UWSCが使えなくなることはありません そして、UWSCであれば今までの資産 (スクリプト) がそのまま理想通りに動きます わざわざ面倒な思いをしながらUWSCR用にスクリプトを書き直す必要もなくなります

UWSCRが必要なのはUWSCの不便さから解放されたい人を想定してましたが、UWSCで十分なのであればUWSCを使うべきです Better UWSCRという選択肢

UWSCはこれ以上使えないというやむを得ない理由があるのならば残る選択肢はこれしかありません

UWSCRはソースが公開されており、またMITライセンスであることから第三者がこれといった制限もなく自由に使うことができます つまり、僕の実装が気に入らなければ自分なりの実装を盛り込んだ (あなたにとって) より良いUWSCRを作れるということです また、それを公開して (あなたの想定する) より良いUWSCRを求めるユーザーに届けてあげてください

むしろ、あなたにはそれをやる義務すらあると思います あれほど大口を叩き、しかし全ての責任は僕になすりつけるようなやり方をする暇があるのならば、自ら手を動かしあなたの正義を実現してください あなたの言う多くのユーザーがあなたの言う理想のUWSCRを待っています

あなたがすべきことはあなたの言う事に耳を貸さない愚かな開発者を説き伏せようとすることではなく、あなたの中にあるUWSCRの本来あるべき姿をこの世に具体化することです

今すぐこのリポジトリをforkしてやることやりましょう！ね！

そんでこのわけわからんissueはcloseしてもらえると助かる

— Reply to this email directly, view it on GitHub https://github.com/stuncloud/UWSCR/issues/204#issuecomment-2306677931, or unsubscribe https://github.com/notifications/unsubscribe-auth/BH6AXYVMVDFLF7RHDWWTJXLZS35YJAVCNFSM6AAAAABM7WUEBCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBWGY3TOOJTGE . You are receiving this because you were mentioned.Message ID: @.***>

stuncloud commented 3 weeks ago

あーもううるさいうるさい ここではもうあなたの主張に価値も意味もないの あなたにあるのはあなたが始めたことの責任だけ

まずね、僕にはね、あなたの言う多くのユーザーに対する責任は一切ないんです (そもそもどこにいるんだよそいつら、なんで存在すら怪しいやつのためになにかしなきゃならないんだ) なのでポリシーを曲げてまでその者らに迎合するいわれはないの

でもあなたには彼らに対する責任がある なぜならあなたはあなたの言う多くのユーザーを代表した立場で物を言うことを選択してしまったから あなたは彼らの声を無視できないんでしょう？

架空の第三者を盾に僕に要求するな、ということをあなたには伝えていたはずなんですけどね？ しかし卑怯なあなたはそれを止めないどころか、その責任をすべて僕になすりつけようとした 本来あなたが負うべき責任に気付きもせず一方的に、暴力的に

そうは行くものかよ

いいですか、ここまできたらあなたには彼らのためにあなたの主張が具現化されたプロダクトを作る義務がある もちろん僕にはそれに協力する義理なんてね、当然ないです あなたがやらなきゃこいつは終わらないんですよ あなたができないとかは関係ないの あなたのやっている、できるやつがやるべきだという押しつけはね、通らないんだよ

それとね、こちとらメンタルやられて社会性を失った人間ですのでね、あなたのために精神を削られて日常生活に支障が出てる有り様なんですよ なのでもう僕の目に入るとこに出てこないで欲しいんですね

正直ね、あなたの存在は僕と、そして僕の作るUWSCRにとってとても有害です あなた自身に害意はなくとも、あなたがやってるのは僕と僕の作りたいUWSCRを破壊する行為なんです 僕は僕と僕のUWSCRを守らなくてはならない

UWSCRは自由なソフトウェアです ですがそれは害をなしても良いという意味ではありません あなたもそれは望んでないでしょう？

あなたにはあなたとあなたの言う多くのユーザーが求める、より良い新たなUWSCRを自らの力で作り上げる自由があります もちろん名称を変更してもいいですよ、UWSCRだと印象悪いからね それを阻むものはなにもありません そしてあなたの責任を果たしてください より良い未来のためにね

DIYJii commented 2 weeks ago

私は、元エンジニアとして、技術について遠慮なしの議論をしてきたつもりでしたが・・

悪い事してしまったようで、すみませんでした。

もう、黙ります。

On Sun, Aug 25, 2024 at 12:00 AM Joey Takahashi @.***> wrote:

あーもううるさいうるさい ここではもうあなたの主張に価値も意味もないの あなたにあるのはあなたが始めたことの責任だけ

まずね、僕にはね、あなたの言う多くのユーザーに対する責任は一切ないんです (そもそもどこにいるんだよそいつら、なんで存在すら怪しいやつのためになにかしなきゃならないんだ) なのでポリシーを曲げてまでその者らに迎合するいわれはないの

でもあなたには彼らに対する責任がある なぜならあなたはあなたの言う多くのユーザーを代表した立場で物を言うことを選択してしまったから あなたは彼らの声を無視できないんでしょう？

架空の第三者を盾に僕に要求するな、ということをあなたには伝えていたはずなんですけどね？ しかし卑怯なあなたはそれを止めないどころか、その責任をすべて僕になすりつけようとした 本来あなたが負うべき責任に気付きもせず一方的に、暴力的に

そうは行くものかよ

いいですか、ここまできたらあなたには彼らのためにあなたの主張が具現化されたプロダクトを作る義務がある もちろん僕にはそれに協力する義理なんてね、当然ないです あなたがやらなきゃこいつは終わらないんですよ あなたができないとかは関係ないの あなたのやっている、できるやつがやるべきだという押しつけはね、通らないんだよ

それとね、こちとらメンタルやられて社会性を失った人間ですのでね、あなたのために精神を削られて日常生活に支障が出てる有り様なんですよ なのでもう僕の目に入るとこに出てこないで欲しいんですね

正直ね、あなたの存在は僕と、そして僕の作るUWSCRにとってとても有害です あなた自身に害意はなくとも、あなたがやってるのは僕と僕の作りたいUWSCRを破壊する行為なんです 僕は僕と僕のUWSCRを守らなくてはならない

UWSCRは自由なソフトウェアです ですがそれは害をなしても良いという意味ではありません あなたもそれは望んでないでしょう？

あなたにはあなたとあなたの言う多くのユーザーが求める、より良い新たなUWSCRを自らの力で作り上げる自由があります もちろん名称を変更してもいいですよ、UWSCRだと印象悪いからね それを阻むものはなにもありません そしてあなたの責任を果たしてください より良い未来のためにね

— Reply to this email directly, view it on GitHub https://github.com/stuncloud/UWSCR/issues/204#issuecomment-2308422773, or unsubscribe https://github.com/notifications/unsubscribe-auth/BH6AXYRJAK46ERF76BROAN3ZTCN2TAVCNFSM6AAAAABM7WUEBCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGQZDENZXGM . You are receiving this because you were mentioned.Message ID: @.***>