[HOME]  [現在掲示板へもどる]     [全部表示 会議室風]  [最新100]  [最新50]   [新着40]    [全部表示 保存用]
番号順 最新50記事     FGALVZ  

10392/10387 CXB00940  としき           Re: アセンブラ&コンパイラ、きっと NOT (neg?)
( 1) 22/11/11 22:58 10390:文太さんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
#10387で紹介されたリンクからダウンロードしました。
まだ中を覗いてもいません。
が、#10391を見る限りでは、明らかに素のアセンブラ。
なぜここでアセンブラのソースにとどめて一気にマシン語にまで落とさなかったん
だろうという疑問はありますが、私にはわからない何らかのメリットはあるんで
しょう。FAQとかあれば、きちんと書いてありそうな疑問ではあります。

> >そうではなく、変数に定数を代入する、というようなロジックでプログラムを書く
> >のが高級言語。
>  変数への代入? どういうことでしょう? アセンブラソースだって、変数への
> 代入はするでしょう? 何かロジックが根本において違う、ということだろうと
> 想像。

眠くて端折ったところ、やっぱりわかりにくくなっていますね。
多くの場合、高級言語では、1つのコマンドまたはステートメントは複数の機械語
に変換されるのです。例えば、変数の代入の場合なら、変数はメモリ上のどこかの
領域に確保されているわけで、そのアドレスを計算してから、そこへの代入、と
いうコードに変換されるわけです。
この前提があるものですから、かつて、LSI-C86が、可能な限り変数をレジスタに
割り付けると知って、多くのプログラマが驚いたのです。レジスタなら、変数の
アドレスを計算するルーチンが丸々省略できて、場合によっては、高級言語の1つ
の代入が機械語の1つのコードに変換できるわけですから。
私の個人的な話をすると、昔、8ビットマシンでBASICのコードを機械語にハンド
アセンブルしていたとき。当時のZ80では、レジスタを使った値の受け渡しよりも
スタックを介した値の受け渡しのほうが早い場合が多かったのです。今のCPUが
どうなっているかは知りませんがね。なので、私のコードでは、スタックを使い
まくり。

ということで、

> >そして、そのプログラムを複数の機械語に変換する、というのがコンパイラ。
>  なぜ、としきさんはここで「複数の」と書いたのでしょう?

高級言語の1つのコードは、多くの場合、複数の機械語に変換されることが非常に
多いという現実があるわけです。もちろん、場合によっては、一つの機械語に変換
されるかもしれません。そして、仮に一つの機械語であっても、それは単なるcall
文に変換されて、変換先で複数のコードが実行される、ということになっている
かもしれません。

> >また、コンパイラも、ターゲットのマシンの機械語にコンパイルする、いわゆる
> >普通のコンパイラのほかにも、仮想的なマシンの機械語にコンパイルするという
> >種類のものが昔からありました。
>  ここからは、もうまったく。CPUにそもそもvirtualizationの仕組みが入っている
> というのは、「分からん」「いつかね」とCPU本でスキップした箇所。

CPUのvirtualizationとは、おそらく直接は関係ない。
まずは、クロスコンパイラ、という技術を知っていただくのがいいのかな。
多くの場合、コンパイラは、自分の動いているマシンのCPU用のコードを出力します。
これに対してクロスコンパイラは、別のマシン用のコードを出力します。
普通、このクロスコンパイラというやつは、現実に存在するマシンのコードを出力
します。でも、その気になれば、全く世の中に存在しないマシン用のコードを出力
するように設計することも可能なわけですよ。
自然言語で考えればわかりやすいかもしれません。
翻訳ソフトで、普通なら出力が英語。これが普通のコンパイラ。
クロスコンパイラなら、出力がフランス語。
でも、例えば、エスペラントを出力させることも可能。
あるいはそれこそ、仮想言語であるヴォイニッチ語を出力させる、とか。
この辺、私の説明がつたないので、自然言語との類推が難しいかもしれない。
疑問点があればおっしゃってください。
もうちょっと具体的に説明できるかもしれません。

> >最初にBASMの話を聞いたとき、私はこれだと思ったんですよ。
>  いちおう、これのはずなのですが。
>
> >マクロを使いまくったアセンブラのソースに変換するのであれば、それはコンパイラ
> >でもアセンブラでもないよね、ということ。
>  ほぼこれのはずです。

そうですね、なんとなくそんな感じです。
なかなか面白そうではあります。

10393/10387 CRG00666  文太             Re^2: アセンブラ&コンパイラ、きっと NOT (neg?)
( 1) 22/11/12 00:46 10392:としきさんへのコメント コメント数:2
 すいません、とりあえずの最初の一歩の問題への解答は以下のとおり。

BASM converts a BASIC-like language to 80286 Assembly Language Source Code   
which easily compiles using such widely available public domain tools as the 
Arrowsoft Assembler and the Freelink linker. 

Basic-like language(BASM言語=一般に出回ったBasicの弱力化版だろう)を
Asm Source Codeにコンバート。

BASM is a powerful 80286 assembly code generator.  Use it to create stand
alone programs using your assembler and linker. Or use the code to help
optimize routines in your favorite high level programming language.

"80286 assembly code generator"

 なぜ、アセンブルしてしまわないのか? そこまで持っていかないのか?
 optimizeできるから、なのでしょうかね? あるいは、高級言語のインライン・アセンブラ
の部分をBasicで書けるよ、なのかな。

 コンパイルとアセンブルの違い(と僕が思っていたこと)。
 .asmにしてアセンブルすると、.basをコンパイルするより、〈一般に〉速いものが
できあがる。
 しかし、これは「最適化」できるかによりけりで、〈一般に〉にそうとは限らない。
たぶん、大して変わらない。
 こんな風に理解しています。

 僕にとっては、どんなアセンブラ・ソースになるのか見えて楽しい、ぐらいですかね。

 TSRの骨組みは、全部アサム・コードです。あれに必要部分(?)をBasic言語で
つけ加えれば、常駐ソフトができてしまう! のかな? といったところです。
 どんなTSRが欲しいのか、あったら嬉しいのか、分かってませんが。
 ただ僕には、(ぜんぜん原理が違うのは分かってますが)stkhelpがほとんどそんな風に
見えています。原理的に常駐ソフトに似てるものがあるとすれば、それはVzモード型マクロ
なのでしょうが、たぶん。

 あと1点。としきさん、割とマクロ、マクロ(アセンブラの)と書かれていて、そう翻訳
されると想像するのが「順当」なのかな、と思っていましたが、プロシージャです。もっと単位が
上というか大きい? たぶん、そのほうが、BASM作者にとって楽なのかな?
 はい、関数は、ルーチンは、当然、多くの、複数のマシン語命令群に翻訳されているようでした。

CLS
 だって、マシン語で書けばvideo関係のbiosコールかな、などなど、大変です。

 エスペラントなどなど(仮想化)は、うーん、深いですねぇ。
 ただこのラインは本筋から大きくずれたかな、という気はしています。


 じつを言うと、僕が最初にみたBASMと、最終版は違うので、もうちょい地道に自分の辿ってきた道
と道具を再検証したいと思っています。あのbasm.exe + α(シェア1ウェア時代)が、見つからない
のです。

 あった!

c:\>tosfind /nbasm*.*		; 時間かかった! 5分
				; でも使い方や環境によりけりですが、僕は、tosfindの
				; バグに一度も出会ってないです。多謝。

from basm.doc

------------------------------------------------------------------------------------
BASM!  The BASIC to 80286 Assembly Language Compiler ShareWare
BASM translates a BASIC-like language to 80286 assembly language source.    
  The assembly language that BASM produces was designed and tested to compile 
  without modification using Borland's Turbo Assembler versions 1.01 & 3.2    
  and Microsoft's Macro Assembler version 4.00.                               
                        Try BASM free for 30 days...                          
      If you like it, please send $25.00 cash, check or money order to:       
------------------------------------------------------------------------------------

 そうなの? あれで、tasmで通るんだ。
 作者作成の .bas と .asm が直接比較できるファイル群が、ここにはありました。



10394/10387 CRG00666  文太             PrintStrプロシージャ(asm)
( 1) 22/11/12 01:12 10393:文太さんへのコメント
としきさん、無理してお付き合いする必要なんて、まったくありませんからね。


 ほぼ意味がないし、これ、ish部屋に貼るのか? と思ったのは以下。
 断片です。
 意味なく長いのを貼って、ごめんなさい >konnoさん

---------------------------------------------
     Call Cls
;
;input "What is your name? " a$ 
;
     Mov  SI,Offset $tring_01
     Call PrintStr

<cut>
---------------------------------------------


---------------------------------------------
     PrintStr Proc Near
     Call Len
     Push AX
     Mov  CX,AX
     Cmp  CX,0
     Jle  PS_3
     Mov  BX,$Attr
     Mov  AX,$Ycur
     Mov  DI,$Xcur
     Push DS
     Push ES
     Dec  AX
     Dec  DI
     Cmp  DI,0
     Jg   PS_1
     Xor  DI,DI
PS_1:
     Mov  DX,80
     Mul  DX
     Add  DI,AX
     Shl  DI,1
     Mov  AX,0B000H
     Mov  ES,AX
     Mov  AH,0FH
     Int  10H
     Cmp  AL,07H
     Je   PS_2
     Mov  AX,0B800H
     Mov  ES,AX
PS_2:
     Cld
     Movsb
     Mov  ES:[DI],BL
     Inc  DI
     Loop PS_2
     Pop  ES
     Pop  DS
PS_3:
     Pop  AX
     Add  $Xcur,AX
     Ret
     PrintStr Endp
---------------------------------------------

 こんくらい長くなるし、このプロシージャ、別のプロシージャをcallしてるから、
1対1対応でアセンブルされる、本物のソースはもっと長くなりますね。



10395/10387 CXB00940  としき           Re^3: アセンブラ&コンパイラ、きっと NOT (neg?)
( 1) 22/11/12 16:13 10393:文太さんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
だんだんわかってきました。
私の知りたかった一番の核心は

> from basm.doc

> BASM translates a BASIC-like language to 80286 assembly language source.    

ということで、やはり作者的には、コンパイラというよりトランスレータという扱い
のようですね。これで私の頭の中はかなりすっきり。した気がする。してないかも。
もしかすると、スッキリしていない頭でいろいろとあげつらった文章のせいで、逆に
文太さんを困惑させているような。

>  あるいは、高級言語のインライン・アセンブラ
> の部分をBasicで書けるよ、なのかな。

これは大きいかもしれない。
例えば、私の手がけたポケ3用のEMSドライバ、関谷さんの作られた200LX用の古い
バージョンの移植です。そしてこのドライバは、使用頻度の高いファンクション
しかサポートしていない。そこで、歯抜けの部分のファンクションを自力で作りたい
という思いはあって。そしてポケ3のCPUは80286。

>  コンパイルとアセンブルの違い(と僕が思っていたこと)。
>  .asmにしてアセンブルすると、.basをコンパイルするより、〈一般に〉速いものが
> できあがる。
>  しかし、これは「最適化」できるかによりけりで、〈一般に〉にそうとは限らない。
> たぶん、大して変わらない。
>  こんな風に理解しています。

理論的には「大して変わらない」かもしれない。
でも、世の中のコンパイラで、そんなにきちんと最適化できるものは少ない、という
現実もあって。
例えば、DOS3とかDOS5の時代、Turbo CとかQuick Cに比べるとLSI C-86は圧倒的に
最適化レベルが高かった、といわれています。それでも、LSI Cの出力を、手作業で
さらに最適化するような人々もいたらしい。ただ、その時代の職人の手仕事なんて
ほとんど伝説の域に達しているわけで、はたしてどこまで本当なのやら。

一応、多くのコンパイラは、その最終出力は実行ファイルです。
ただ、中間段階として、アセンブラソースをつくるものもあります。
LSI C-86はアセンブラソースを作ります。Delphiは作らないような気がする。
また、LSI C-86は同梱の専用アセンブラ用のソースを経由しますので、いろいろな
記述が、一般的なMASMやTASMと異なり、かなり癖がありました。当然、それらとの
互換性は皆無。とはいえ、ニーモニックは同一ですから、その部分だけを手作業で
MASMで移植、なんてことはよくやられていたようです。

>  としきさん、割とマクロ、マクロ(アセンブラの)と書かれていて、そう翻訳
> されると想像するのが「順当」なのかな、と思っていましたが、プロシージャです。

なるほど、ここも私がわかっていなくて想像していた部分でした。
例えば、分岐やループの構文。
最近のアセンブラならマクロで構築するじゃないですか。
なので、BASICをアセンブラに変換する場合、変換結果はマクロかな、と思っていた
のです。

>  エスペラントなどなど(仮想化)は、うーん、深いですねぇ。
>  ただこのラインは本筋から大きくずれたかな、という気はしています。

ずれまくりましたね。私のほうに誤解がありました。
ということで、以下、余談。
現在、一般に、CPUのvirtualizationというと、CPUで実行するソフトウェアの話。
ご存知だと思いますが、世の中にはシミュレーションゲームってありますよね。
アレって、仮想の世界で遊ぶソフトウェア。
同様に、CPUで、自分自身とか、全く別のCPUをソフトウェアとして動かす、という
ある意味で大技なのが、CPUのvirtualization。
ここで、「全く別のCPU」と言っていますが、たとえばこれ、現実には存在しない
架空のCPUであってもかまわない。その場合、当然、そのCPUで動く機械語は架空の
機械語になるわけです。つまり、現実とは距離を置いた言語。この意味で、まるで
人間の会話における自然言語に対する人工言語であるエスペラントのようだ、と
私は考えたわけです。

> 			; でも使い方や環境によりけりですが、僕は、tosfindの
> 			; バグに一度も出会ってないです。多謝。

私のほうが文太さんよりもtosfindの使用頻度が低いせいもあるのでしょう、私も
一度もバグに出会っていません。
ただ、ソースも公開されていますから、その気になればバグ取りできる人も多いと
思います。こういうところもオープンソースのいいところ。つまり、作者は逃げて
しまえるのですから。

10396/10387 CRG00666  文太             Re^4: アセンブラ&コンパイラ、きっと NOT (neg?)
( 1) 22/11/12 21:53 10395:としきさんへのコメント コメント数:1
としきさん

 今日は、ここだけで失礼します。

>>  としきさん、割とマクロ、マクロ(アセンブラの)と書かれていて、
>なるほど、ここも私がわかっていなくて想像していた部分でした。
>例えば、分岐やループの構文。

 なるほどぉ。いえ、としきさんが正解です、というか半々。マクロでは
ないが、プロシージャでもない。

 制御フローのことがすぐに頭に浮かぶんですね。この前の変数の話(メモリの
アドレス)とも似て、やはりとしきさんのほうが僕より、なんだろう、プログラミング
上、あるいはCPUとプログラムの関係上、正しい想像力をお持ちです、たぶん。
当たり前だけど。
 その方向で考えているのだろう、と僕には想像ができなかった、ということです。
 文脈を想像力で埋めることができなかった、という意味。

 で、マクロでなくプロシージャでもなく(後者でフローを作れるのか?) 
ベタなラベルジャンプ(最終的にはこれしかないから)が正解でした。

DoLoop_01:
;
;print "Hello there " a$ 		;これだけの命令が
;
     Mov  SI,Offset $tring_03		;ループなしでも
     Call PrintStr			;これだけのプロシージャ
     Call SetCursor			;を必要とする
     
     Mov  SI,Offset A$			;やるなら、高級言語だろう
     Call PrintStr			;あるいは
     Call SetCursor			;Vzマクロ。
     					;この感慨が面白くて
     Call DoCrLf			;BASMに興味を持ちました
;
;incr a 
;
     Inc  A
;
;if a = 23 then 
;
     Cmp  A,23
     Je   $+5
     Jmp  _EndIf_01
;
;exit loop 
;
     Jmp DoLoop_01A
;
;end if 
;
_EndIf_01:
;
;loop 
;
     Jmp DoLoop_01

DoLoop_01A:


>最近のアセンブラならマクロで構築するじゃないですか。
 僕は、最近のことはまったく知らないのですが、そうなのですか?
 c.mos流のあれをみて、そしてその原理をEmmettさんに教わって(@過去ログ)
最初にあれを考えた人(注)は何て頭がいいのだろう、と思いました。
 Cみたいな顔してるくせして、実はラベルを中で自動生成していた。

 ちなみに、上のようなプロシージャだらけの書き方を(この例はあまりよくない
かもしれないけど。たぶん他のやり方は醜すぎるから)、Jeff先生は強く強く
推奨していて(構造化)、「どうだ、アセンブラがパスカルみたいだろう」と
書かれていて、笑いました。
 まあね、と。
 で、僕は、よし、パスカルをやろう、と決心したという次第。その後、
1ミリも前進していないけど。

 JVM、たまたま出会いました。別発言で。

(注)とはいっても、〈マクロ〉アセンブラに内蔵されてると言ってもいいような
仕組みだから、アセンブラ作者自身でしょうね。MASMのドキュメントとかに書かれてる
のかなぁ? 「こんな使い方をすると賢いですよ」とか。



10397/10387 CRG00666  文太             JVM
( 1) 22/11/12 21:54 10387:文太さんへのコメント コメント数:1

 #10386 後半に薄く繋がってます。
 ここに貼っておきます。

(2) Andrew S. Tanenbaum. _Structured Computer Organization_, 4th Edition. 1999, Prentice Hall.
 前のパラグラフの一節に対する脚注です。あ、嫌な人の名前が出てきた。彼の本をいっぱい捨てました。
 基本的なアイディアはここから来てる、という注釈。

The Java programming language is based on the virtual machine concept. A program
written in the Java language is translated by a Java compiler into Java byte code. The latter is a
low-level language that is quickly executed at run time by a program known as a Java virtual
machine (JVM). The JVM has been implemented on many different computer systems, making
Java programs relatively system-independent.

 としきさんだって、(分からないけど)、じっと見つめてれば、キーワードから何を言ってるか
分かると思う。
 ま、としきさんは中身を知っているわけだから、読む必要がそもそもないのだけど。

 上の文脈を少しだけつけ加えると、マシン語にはportabilityがない。IntelとMotorolaでは、
instruction setsが違うから。ただし、Javaは、どこに行っても、かなりのportabilityがある。
 え!? どうして? と思って、少しだけ読みました。

Assembly Language For Intel Based Computers By Kip R. Irvine
 という本でした。読んでませんよ、ときどき、e-textを整理したり整形したりしてるだけ
です。今回の出会いは、ほんとうの偶然。あるいは10回よんだ功徳。


 ふーん。でも、これ、関係ないし、僕は興味ないなぁ。Javaって、最近の最有力言語の一つ
なのでしょう。でも、僕は要らない。saki...さんがやってた。やってる。
 (どうでもいいことだけど、うちの学校では1年生必修の「プログラミング演習」でCをやってる
って。伝統的なままでとても宜しい、という感想を持ちました。すごい偏見みたい)

 ま、だいたい話の方向性は見えました。でもでも、、、。
 Tanenbaum先生の思い出に通じる。

 アセンブラ、コンパイラ、トランスレータ、インタープリタ。大きな分類ですね。そして、それら
の関係。すごい抽象論。上の引用箇所の前には、VM0, VM1, VM2とか出てくる。Virtual Machine 0, 1, 2。
はあ、はあ、はあ、みたいな感じでした。



10398/10387 CXB00940  としき           Re^5: アセンブラ&コンパイラ、きっと NOT (neg?)
( 1) 22/11/12 23:09 10396:文太さんへのコメント コメント数:2
参照先:http://toshiki.la.coocan.jp/
タネンバウム先生は、高名な学者だということは存じております。
でも、和訳された先生の著作をまじめに読んだことは、たぶんない。

> >最近のアセンブラならマクロで構築するじゃないですか。
>  僕は、最近のことはまったく知らないのですが、そうなのですか?

最近の話ではないかもしれない。
もう20世紀のうちから、アセンブラではマクロがビシバシ使われていたと思う。
optasmとかtasmとか、MASMとは互換性がないよ、といわれていた部分はおそらく
ほとんどマクロの部分だと思う。それらを使ったことがないので自信はないけど。

で、まぁ、そういった部分のほとんどはおそらく、いわゆる構造化という考え方
に繋がってくる部分だと思う。つまり、分岐とかループ、ということ。ところで、
先日、書名を出した「ソフトウェア作法」とか「プログラム書法」といった、今
では古典とされる書物がどんなことを書いていたかというと、言語仕様が構造化
されていないFORTRANでも構造化に気を配ったプログラムを書くことができますよ、
ということ。そして、それをさらに敷衍して、当時の(マクロのない)アセンブラ
でも構造化することは可能、ということでした。
ただ、正直、小さいプログラムを力任せに書くのなら、構造化だのなんだのって
はっきり言って不要。だけど、ちょっと大きいプログラムを書こうと思ったら、
構造化は必須。これがあるのとないのとで、開発効率は全く違う。
さて、80年代前半、8ビットパソコンの全盛期。BASICユーザ花盛り。
このころ、マシンはどんどん強力になり、大きいプログラムを書けるようになった。
だけど、それこそ、ソフトウェア工学なんて言葉も知らない小中学生がゲームを
つくる時代。例えば、面白いゲーム、すなわち大きなプログラムをバグを少なく、
かつ早く完成させるにはどうすればよいか、という問題がじわじわと出てきました。
また、いろいろな職場にも、とりあえず導入されたパソコンをどう使うか、という
問題も発生。
ここで求められたのが、BASICでの構造化。
そんな中で登場したのが、ソフトバンク刊「Oh!PC」に掲載された林晴比古氏の記事。
その後、単行本にまとめられて「BASICによるプログラミングスタイルブック」と
して出版されました。私も持っています。
ちょっと癖がある文体で、それに拒否反応を示す人もいます。
ただ、内容については、反論した人がおおむね玉砕するくらいの王道。
おそらく、この本または雑誌の記事で初めて構造化ということを知ったという人も、
当時のパソコン少年では多いかもしれません。

あぁ、また昔話で終わってしまった。
これだけはっきり症状が出ているということは、老化が進んでいるのでしょう。
ま、いいか。
#いいのか?

10399/10387 CXB00940  としき           Re: JVM
( 1) 22/11/12 23:23 10397:文太さんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
>  ま、としきさんは中身を知っているわけだから、読む必要がそもそもないのだけど。

おおむね、知っている単語ばかりなので、だいだい読めました。
ま、ポータビリティは重要です。
例えば、自分でウェブサーバを立てているとか、あるいはレンタルでもいいので
ウェブサイトを持っているという人ならJavaScriptで何かをできるでしょう。
でも、そうではないけど何かアプリを作りたい、といった場合。
自分の手元だけで動くアプリなら、自分の手元の環境と言語でOK。
あるいは、Windows上なら、例えばExcelのVBAという選択肢もある。
でも、ターゲット環境がWindowsだけではない場合。
あるいは、WindowsだけどExcelがない場合。
そういう場合に現場の人間が次に検討する言語はJava。
実際、私、知りもしないJavaで何とかしようか、思案中。
業務システムなんですが、セキュリティの関係で、通常の車内網と独立しているん
ですよ。だからインターネットにも繋がらない。Excelが入っているかどうかも不明。
なにせ、メモ帳すらプロテクトがかかっていて、任意に起動できない。業務システム
からなら起動は可能なんで、存在は確認できるのですがね。
こういう環境でも、Javaは存在している。
となると、なんか遊ぼうと思ったら、必然的にJavaは必須。

ま、必要に迫られたら勉強しましょう。

10400/10387 CRG00666  文太             Re^2: JVM
( 1) 22/11/13 00:16 10399:としきさんへのコメント コメント数:1
車内網 → 社内網  ;あるいは術語?

ま、必要には迫られないでしょう。そのような人生は生きないと思います。


10401/10387 CRG00666  文太             Re^6: アセンブラ&コンパイラ、きっと NOT (neg?)
( 1) 22/11/13 00:17 10398:としきさんへのコメント コメント数:1
>あぁ、また昔話で終わってしまった。
 面白かったですよ。
 昔話以外の何かを伝えたかったのですか?

 僕が理解したのは、Basic のリファレンスのたぐいで、「構造化」って連呼
されてたのは、そういう背景なのか、ということ。
 Vzマクロから入門しそれしか知らない人は、&00 とかなかったら、jimae buffer
はどうするんですか? ぐらいなんですよね。

 たぶん一生わからないんだろうな、と思うのは、そのゲームへの熱中。
 ギャラクシアンで少し興奮したのかなぁ?


10402/10387 CRG00666  文太             Re^6: アセンブラ&コンパイラ、きっと NOT (neg?)
( 1) 22/11/13 00:31 10398:としきさんへのコメント コメント数:1
>先日、書名を出した「ソフトウェア作法」とか「プログラム書法」といった、今
>では古典とされる書物がどんなことを書いていたかというと、言語仕様が構造化
>されていないFORTRANでも構造化に気を配ったプログラムを書くことができますよ、
>ということ。そして、それをさらに敷衍して、当時の(マクロのない)アセンブラ
>でも構造化することは可能、ということでした。

 ありがとうございます。そして、五月雨でごめんなさい。
 なるほど! いいことを聞きました。では『ソフトウェア作法』は捨てることに
いたしましょう。コロナ渦の2年で、蔵書10分の1は捨てました。財産を捨てなさい
運動、実行中。
 『ソフトウェア作法』の原書のpdf、どっかで見ました。
 要らない。
 焦点をしぼろう。



10403/10387 CXB00940  としき           Re^3: JVM
( 1) 22/11/13 00:53 10400:文太さんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
> 車内網 → 社内網  ;あるいは術語?

述語ではありません。単なる誤字です。
いかん、アルコールが回っておる。
つ〜か、IMEがへんな学習をしている模様。
この上の2行も、第2順位の単語で確定したからいいものの、最初に候補に出てきた
単語は

術後ではありません。単なる護持です。
遺憾、アルコールが回っておる。

となっていた。一体どうなっているんだろう。

10404/10387 CXB00940  としき           Re^7: アセンブラ&コンパイラ、きっと NOT (neg?)
( 1) 22/11/13 01:01 10402:文太さんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
>  なるほど! いいことを聞きました。では『ソフトウェア作法』は捨てることに
> いたしましょう。コロナ渦の2年で、蔵書10分の1は捨てました。

ターゲットとしている言語がFORTRANだから、という理由で捨てるのなら大いに賛同
できます。ただ、この本で取り上げている内容って、文字列処理が多いのですよ。
もちろん、全てではありませんけどね。そういう理由もあって、私、この本の和訳本
を持っていますが、古典だから、という理由を除外しても、なかなか捨てる度胸は
ありません。

10405/10387 CXB00940  としき           Re^7: アセンブラ&コンパイラ、きっと NOT (neg?)
( 1) 22/11/13 01:30 10401:文太さんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
>  昔話以外の何かを伝えたかったのですか?

そうか、そういわれれば、それ以外の何者でもない。
あのコメントを書き出すときは、構造化の由来、みたいなことを考えていたのだと
思うのですが、そもそもそれは昔話でしかないわけで。
なんてこった。

>  たぶん一生わからないんだろうな、と思うのは、そのゲームへの熱中。

ゲームで遊ぶほうもそうですが。
ゲームを作るほうの熱気もすごかった。
そもそも、ゲーム以外(ビジネス用途)にまともに使えるマシンは、シャープの
MZシリーズとNECのPC-80/88/98シリーズの他は、日立のベーシックマスター
と、あとは富士通のFM−8ぐらいだったような記憶がある。その他、沖のif800
はビジネス向けがメインだったけど。
パソコン雑誌のほうもそう。
ベーマガはゲームのプログラムリストがメイン。4大誌も毎月ゲームのプログラム
が大量に掲載されていた。ゲーム以外の記事も一応は載っていたけど、I/Oなんかは
特に、ゲームとゲーム用ツールの記事ばかりだったような記憶がある。RAMは
ほとんど読んでいなかったから知らないけど、アスキーとマイコンは一応、ゲーム
以外の記事もそれなりに掲載されていた。とはいえ、ビジネス向けの記事というと、
やはりソフトバンクのOh!シリーズのほうが多かったような気がする。

ま、でも、それが当時のその界隈での現実ですからねぇ。

10406/10387 CRG00666  文太             大門未知子
( 1) 22/11/13 13:03 10403:としきさんへのコメント
 かなり受けましたよ。アルコール、まだまだ足りなかったようです。
 頭が回ってる。

>つ〜か、IMEがへんな学習をしている模様。
 社内網 あ、ダメだ、正しくなってしまっている。昨晩は、車内が最初に
出ました。初期設定なのかな?

>術後ではありません。単なる護持です。
 複数候補をそなえた機械なので、その気になればやれるわけですが、なぜか、
これ、すごく受けた。別の候補では、ここまで笑えない。
 大門未知子が病室で憲法論議をしてるイメージがすぐ浮かんで、あう? あう? 
あう? くくくく、お腹が痛い、となりました。



10407/10387 CRG00666  文太             構造化
( 1) 22/11/13 13:49 10404:としきさんへのコメント コメント数:2


>ただ、この本で取り上げている内容って、文字列処理が多いのですよ。
 いいこと聞いた、ふたたび。ありがとうございます!
 そうなんだ、じゃあ、念のため、取っておくかぁ。この本は、本棚の
どこにあるか分からないなぁ、1冊すてるのに、探し回るのは嫌だな、とも
思ってました。(注)

 それより、(『作法』は捨てないほうが良い理由になる? )、「構造化」で
としきさんは、フロー制御−−ループと分岐−−がその代表みたいに書かれて
きましたよね。loopとif ... else。前者をラベルジャンプで、後者をelseなしの
if ... then の羅列で作ったとき、それは「構造的」でないのですかね?
 loop & if_elseがより高度に構造的だとは言えると思うけれど。

 僕は、ちゃんと勉強したことがまったくないわけですが、サブルーチンcallが
構造化の代表格(もっとも分かりやすいサンプル)なんじゃないかと思ってる
のですが。

 行番号ジャンプ(basicにしろsedにしろVzにしろ)は、究極のGOTOみたいで
繰り返し使えばやがてスパゲになる、とは思うのだけど、ループと分岐(case文
も含む)が、、、それほど、、、な気持ちもなくはなく、、、、。
 もはや大きなプログラムを書くことはなかろう(blogjump.defが最長)という
感覚もあるから、こんな風に考えるのだろうとも思うのですが。

 ごくごく簡単な回答で構いません。一言、一語、一発でお願いできませんでしょうか。
 『作法』を読め。え?


(注)−−(注)にならないと思うけど。「文字列処理」の考え方がけっこう
一般性が高そうな事実と、問題解決思考っぽいのと、プログラミング計算が実生活
に役立ったサンプルを超手短に披露−−疲労とか出ます、当然−−。

 充電したリチウムが15本ありました。この中から容量が一番多いもの1本だけ
選べ(アルコールが入って眠れず疲れ切った昨晩の状態でのタスク)。手は2本で、
15本のリチウムを同時には持てず、中腰の姿勢。十分な作業空間なく床に並べること
すらできない。頭と目で計算してタスクをこなすしかない。でも、はやくこの仕事を
片付けたい!
 ソート! 全体を2つのグループに分けよ。1つのグループに最大容量のリチウム
1本だけを残す。1本グループには指を載せておくだけ。総当り戦。

 オチは、今日、空間のじゅうぶんある隣の部屋の机の上で、14本も全部容量順に
並べたこと。最初からこのタスクも頭にあったから、即座問題解決のソート戦略が
嬉しかった。
 はやく寝ればいいんだよ。



10408/10387 CRG00666  文太             ゲーム&ビジネス
( 1) 22/11/13 14:06 10405:としきさんへのコメント コメント数:1

>>昔話以外の何かを伝えたかったのですか?
>そうか、そういわれれば、それ以外の何者でもない。
 すいません、僕が現在、昔を生きているのが異常なわけですが、でも、だからこそ
昔話こそが(Javaはよろし)面白いのです。

>構造化の由来、みたいなことを考えていたのだと
 是非、是非、是非!!!

>ゲームで遊ぶほうもそうですが。
>ゲームを作るほうの熱気もすごかった。
 これなら、僕にも想像がつく。僕にとっては機械相手に遊んでる、みたいな
感覚だった。そうそう。このゲーム、どう出来上がってるか、どういう仕組みで
動いているのか? と気にすることができる人たちがいるんだ、と考えたことが
ありました。
 僕的語彙には、作者との共鳴みたいなものですね。

>そもそも、ゲーム以外(ビジネス用途)にまともに使えるマシンは、シャープの
>MZシリーズとNECのPC-80/88/98シリーズの他は、日立のベーシックマスター
>と、あとは富士通のFM−8ぐらいだったような記憶がある。その他、沖のif800
>はビジネス向けがメインだったけど。
 ゲームとエロビデオがある種のITを商業的に後押しした、とは聞きます。
 ただIBM機がPCブームを巻き起こしたのは(個人の)ビジネスを射程に
収めたから、というより、そっちがメインターゲットだったから、とも聞きます。
 へぇ、というだけなのだけど、上の商標名(固有名詞)3回ぐらい眺めておきます。
 「日立のベーシックマスター」、c.mosさんが所有されていました。
 日立はなぜPC市場を早期撤退したのだろう? もっと大きいのが儲かった?

>パソコン雑誌のほうもそう。
>ベーマガはゲームのプログラムリストがメイン。
 手で打ち込んでいたんですよね。根性あるなぁ。でも、経典の写経のように
聖的体験だったんだろうなぁ。


10409/10409 BQO00549  konno            VZk07t02 テスト版
( 1) 22/11/13 17:07 コメント数:3
VZk07t02 テスト版を「自作、改作アプリの放置部屋」に置きました。


  ・vzk07t01 をベースに [ESC]i ファイル挿入時のVZの不具合を修正してみたテスト版です
  ・VTDOS でのラップアラウンドエラーを回避しています。
  ・テストデータでしか検証していないので、ファイル内容が壊れる可能性があります。
  ・BL1024*3 だとファイル内容が壊れます。(全てのVZで起こるバグなのでこの設定は危険)
  ・詳細は掲示板を読んでください。不具合を見つけたら掲示板に報告願います
  ・VZ高橋版からの差分ファイルになっています。

 動作保証はでき無いので実行は自己責任で。  


10410/10387 CRG00666  文太             Re: 構造化
( 1) 22/11/13 23:36 10407:文太さんへのコメント
としきさん、

 深く悩んではいないと思うけど、「こいつに何を言って意味があるんだ?」とか
悩まないでくださいね。
 以下で解決しました。

「最初に学ぶべき構造化プログラミング、大きな問題を分割して解決」
https://active.nikkeibp.co.jp/atclact/active/17/060100293/060800002/

 パスカルはやるけど、そんなに大きなプログラムを書く予定はないので、Vzマクロの
経験の延長でやれるところまでやる。
 完全にスパゲったら、「やり直しだぁ、26回目」みたいにやります。

 アセンブラは、やっぱり、どれだけcallばっかりで効率悪くても(気にしません)、
短く刻んでプロシージャにする(もぐらさんからの教訓)=アセンブラをパスカルにせよ
の家訓のもと、がんばります。

 何をやっていたかは明かしませんが、以下のような「集中すれば10分だよ」なマクロを
書いていて、ふと考えました。「構造化」をググれ、と。
 そして、この程度なら「順次」でよろし、という結論を得ました。

 「古典」。別発言であげますね。

i-,

#k #i			; duplicate line
#> #d			; next line

(cd=='\')? #g  ? >z		; delete regex header
(cd=='x')? #g  ? >z
(cd==' ')? #g  ? >z

:a
(-1){ (cd=='\') #d ?{} } 
(cd=='(')?  { i++, #h#g "\1" } ? >a


:b

:z	.


10411/10387 CRG00666  文太             古典
( 1) 22/11/13 23:38 10387:文太さんへのコメント コメント数:1
ブライアン・カーニハン
https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%BB%E3%82%AB%E3%83%BC%E3%83%8B%E3%83%8F%E3%83%B3

『プログラム書法』(_The Elements of Programming Style_)1974
by Brian W. Kernighan and P. J. Plauger
https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style
----- Fortran etc .... ムリ。しかし「文字列処理」

『ソフトウェア作法』(_Software Tools_)1976
by Brian W. Kernighan, P. J. Plauger
----- Ratfor, Cobol, Fortran, Algol etc .... ムリ。しかし、、、。

『パスカル・ソフトウェア作法?』(_Software Tools in Pascal_)1981
by Brian W. Kernighan, P. J. Plauger
----- Pascal!!! 読めないと思うけど。「これらプログラムは実用的・
実践的なのじゃ」と序文にあった。

『プログラミング言語AWK?』(_The AWK Programing Language_)1988
----- これですら、世の中にはもっと分かりやすいtutorialがある、と思った。

『プログラミング作法』(_The Practice of Programming_)1999
by Brian W. Kernighan and Rob Pike
https://en.wikipedia.org/wiki/The_Practice_of_Programming
----- C, C++, C#, Java, Pascal etc .... たぶんムリ。新しすぎ!

 上記5点、すべてpdfで入手可能。ただし、原書=英語。



10412/10409 CRG00666  文太             Re: VZk07t02 テスト版
( 1) 22/11/13 23:55 10409:konnoさんへのコメント コメント数:1
konnoさん

 すいませんね。vz.comのアップデートって、緊張しちゃうんですよ。
 ミスっても、やり直し方、いくらでもあるのに。
 高橋版はどこ? と。
 T01 のアップデートすらまだなのです。いえ、じつは、T01かT1かで、最初にとまどい……。
 VzかVzかでも、とまどい。

 はい、こちらが来ると思っていました。ベースはT01です、と。
 え、pcズレ、いまごろ、、、とかなってました。
 ほんとにそうだったかの検証の途中(バリナリ・チェック? fc?)で、もっと落ち着いた
心でやろう、とか、逃げてしまって。
 1週間以内に追いつきます、追いつきたいです。

 15本のリチウムの整理に入る前に、まず作業空間を作るべきじゃないのか? という無限
ループに入る奴です。すいません。なかなか2分岐にもっていくのも大変です。どんどん上がって
いくじゃん、問題解決さん、な感じです。
 しかしこの上がるプロセスも、ちゃんとオーバーヘッドじゃないか、callじゃないか、マクロ
にできないか、とかとか。
 ここが最後で最高度な2分岐だ! というのも、後になって、よかった、ほんとだった、と分かる
「命がけの飛躍」なんじゃないかと思います。

 日はまた昇る。聖書でも読んで寝よう、ウソ。
 プログラミングには、適度な緊張感があるべきだ。

 言い訳でした。m(__)m



10413/10409 CXB00940  としき           Re: VZk07t02 テスト版
( 1) 22/11/14 00:20 10409:konnoさんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
> VZk07t02 テスト版を「自作、改作アプリの放置部屋」に置きました。

ありがとうございます。これからダウンします。

>   ・BL1024*3 だとファイル内容が壊れます。(全てのVZで起こるバグなのでこの設定は危険)

何でこんな不具合が残ったのか、原作者は気がつかなかったのか、という点が本当に
不思議。

実際にパッチを当てて動作試験ができるのは、おそらく、今週の木曜日以降になって
しまう予定。当面、便りがないのは良い便り、と思い込んでおいてください。

10414/10409 BQO00549  konno            Re^2: VZk07t02 テスト版
( 1) 22/11/14 00:57 10412:文太さんへのコメント コメント数:1
文太さん、としきさん、落としていただきありがとうございます。

>  はい、こちらが来ると思っていました。ベースはT01です、と。
>  え、pcズレ、いまごろ、、、とかなってました。
>  ほんとにそうだったかの検証の途中(バリナリ・チェック? fc?)で、もっと落ち着いた
> 心でやろう、とか、逃げてしまって。

え? T01 は文太さんがお使いのVZとバイナルレベルで同じじゃないんですか?
PCズレは無いはずなんですが。
FC /b Vza.com Vzb.com
で確認できますよね。
文太さんがお使いのVZの日付とファイルサイズを教えてもらえますか。
別にそれが無くてもテストはできますが。
もしかして公開版が T1 だったからそれに合わせてほしいとかですかね。

まあ、どうせテスト版なのでゆっくりやりましょう。お互いに。(^^;


10415/10409 CRG00666  文太             Re^3: VZk07t02 テスト版
( 1) 22/11/14 01:12 10414:konnoさんへのコメント コメント数:1
konnoさん

 甘えさせてください。

>文太さんがお使いのVZの日付とファイルサイズを教えてもらえますか。

vz.com 62,184 2018-10-17 19:11
 です。


10416/10387 CXB00940  としき           Re: ゲーム&ビジネス
( 1) 22/11/14 01:36 10408:文太さんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
> >構造化の由来、みたいなことを考えていたのだと
>  是非、是非、是非!!!

ここ、まじめに書こうとすると、私の生まれる前まで遡ることになるわけです。
それでいて、きちんとした参考文献はあまり持ってない。
記憶で書くと、ソフトウェアの生産性が全然上がっていないね、というのが出発点。
そして、ソフトウェア工学なる学問が出来上がってきた。
これの中身もいろいろあって、例えば、コンパイラの最適化をどうするか、なんて
いうのも論点の一つ。そして、いかにバグの少ないソースコードを書くか、という
ことも論じられるようになった。
この当時、プログラムは「順次」「反復」「分岐」 *だけ* で書ける、という説が
出てきたのだけど、当初、その主張があまりにも強すぎて、当時の感覚では過激派
と思われるくらいだったらしい。
そして実際、その3つで大抵のロジックは書けるわけだけど、やっぱりエラー処理
とかまでその3つだけで書こうとするとえらく冗長になるわけで、まぁそんなに
理屈どおりにはいかないわけですよ。ただ、それらの反論は例外的な事象にばかり
焦点を当てたものがほとんど。普通のプログラムであれば、その3つだけで書ける
よね、というところに収束し、今ではソフトウェア初級レベル。今ではもしかすると
普通科高校でやってる「情報」のカリキュラムにも入っているかもしれない。
あとは、トップダウンアプローチとか段階的詳細化とか、用語はいろいろあるけど、
難しいことは解きほぐして解決しましょう、というのは現実世界も同じ。

あ、そうだ、もうひとつ。
ソフトウェア工学って、どうやればバグの少ないプログラムを書けるか、という
ことも扱っています。これって、航空機工学で、どうやればパイロットが操縦の
ミスを少なくできるか、というのと同じようなもの。例えば、あるメーターとか
スイッチとか、操縦士と副操縦士の両方に1つずつ設けるのか、それとも真ん中に
1個だけにするのか、というのを考えるのは立派な考察対象。
ソフトウェア工学にも似たようなことがあります。
たとえば、ループの範囲は直感的にわかったほうがいい、という出発点に立った
とします。まずその前提の当否が議論されて、うんそうだね、と概ねのコンセンサス
が取れた。すると次に、ではどうやってループ範囲を強調するか、という話になる。
プログラムリストをぱっと見てわかるためには、そうだ、字下げを使おう、となる。
ここでまた、部外者からみるとつまらないとしか思えない議論が始まる。すなわち、
字下げは何文字がいいのか、という話。字下げが1文字だけだとループ範囲はよく
わからない、10文字も下げたら多重ループの場合にどうなる、みたいな話を昔の
人は大真面目にやっていたらしい。ただ、これってきっと、心理学とか認知科学の
領域の話ですよね。

余談。航空機工学の話。
昔、80年ぐらい前の話かなぁ、米軍機で事故が多かった。これはコックピットが
狭すぎる、もしくは広すぎて手が届かないせいでパイロットが素早い動作ができない
ためではないかと考えた人がいた。そこで何をやったかというと、数千人だかの
パイロットの身体測定を行い、平均値の身体寸法の人に適したコックピットのサイズ
にしよう、という話になった。ところが、実際に測定を行い平均値を求めた結果、
数千人の中にその平均値ぴたりの人が一人もいなかったとか。あらまぁ。

>  日立はなぜPC市場を早期撤退したのだろう? もっと大きいのが儲かった?

ん〜、単に儲からなかったから、なんでしょうね。
ベーシックマスターはそれなりに売れていたけど、後継のS1は、売れたという話
を聞いたことがない。
とはいえ、プリウスって言ったっけ、ノートパソコンは出していましたよね。

10417/10387 CXB00940  としき           Re: 構造化
( 1) 22/11/14 01:36 10407:文太さんへのコメント コメント数:2
参照先:http://toshiki.la.coocan.jp/
「書法」のほうは、サンプルがPL/Iだったりするので、さすがに古すぎるという
判断で、私は図書館で借りて読むだけで終わらせました。「作法」のほうは購入
しましたが、買っただけの価値はあったと思っています。

>  そうなんだ、じゃあ、念のため、取っておくかぁ。この本は、本棚の
> どこにあるか分からないなぁ、1冊すてるのに、探し回るのは嫌だな、とも

本棚に隠れているのって、英語の原書ですか?それとも和訳?
手元の和訳本をチラッと読み返してみたのですが、古典といわれるだけあって、
使われている用語の選択がかなり古いというか、現在から見ると、違和感バリバリ。
私が読んだのは訳されてから10年たっていない時代でしたが、既に軽く違和感を
感じるくらいでしたから、この業界、新しい概念とか用語とかの変化のスピードの
ほどが知れる、という感じ。
ただ、用語の選択以外はなかなかこなれた訳で、私には読みやすかった。

なお、もし原書を読めるようなら、ざっと目次を眺めてみてください。
文太さんの興味を引きそうな項目が並んでいることと思います。
あと、訳書の場合、まえがき、目次、序論、1章、という順番で並んでいます。
原書でどういう並びになっているかわかりませんが、訳書で言うところの序論の
最初の5パラグラフほどを読んでいただくと、その先を読みすすめるべきか判断
できると思います。

>  ごくごく簡単な回答で構いません。一言、一語、一発でお願いできませんでしょうか。

残念ながら、私には一言で述べる言葉は持ち合わせておりません。
ただ、おそらく、そういうことを述べた一言って、わかっている人にはわかるけど、
わからない人には全くわからない一言になるような気がします。
「光あれ!」とか「悔い改めよ」とかって感じで。

>  充電したリチウムが15本ありました。この中から容量が一番多いもの1本だけ
> 選べ(アルコールが入って眠れず疲れ切った昨晩の状態でのタスク)。手は2本で、

職場の電池捨て場に捨てられていた謎のバッテリーパック。
パッケージに書かれていたメーカー名は聞いたこともない。
調べたところ、どうやら懐中電灯をメインに扱っているメーカーらしい。
殻割りしてみたところ、18650が2本。
私は要らないなぁ。差し上げましょうか?
それはさておき。
容量の一番多いものを特定する方法って、どうやっているのですか?
測定?パッケージの印字?

>  ソート! 全体を2つのグループに分けよ。1つのグループに最大容量のリチウム
> 1本だけを残す。1本グループには指を載せておくだけ。総当り戦。

なんか、クイックソートのアルゴリズムみたい。


10418/10409 BQO00549  konno            Re^4: VZk07t02 テスト版
( 1) 22/11/14 02:23 10415:文太さんへのコメント コメント数:1
> vz.com 62,184 2018-10-17 19:11
>  です。

それなら今回再公開した VZk07t01 とバイナリレベルでも同じはずです。
テスト版はそれがベースになっています。


10419/10409 CRG00666  文太             Re^5: VZk07t02 テスト版
( 1) 22/11/14 10:25 10418:konnoさんへのコメント
 お手数をおかけいたしました。
 ありがとうございます。

10420/10387 CRG00666  文太             Index of _Software Tools_ (1976) by Kernighan & Plauger
( 1) 22/11/14 20:56 10417:としきさんへのコメント
としきさん

 おそらく、捨てたくても持ってないものは捨てられない、という現実。
 しかし、台湾の出版社から出たと思しい _Software Tools_ が
見つかりました。(謎)

    CONTENTS

Preface
Introduction 				1
1. Getting Started 			7
2. Filters 				35
3. Files 				67
4. Sorting 				105
5. Text Patterns 			135
6. Editing 				163
7. Formatting 				219
8. Macro Processing 			251
9. A Ratfor-Fortran Translator 		285

 おお、そう、いい感じ。読めるか分からない、というか、読めない! 
難しすぎ! つまんないからたまにはギャグぐらい入れて、という罰当たり
なことになりそうな気もしますが、そのうちに、とりあえず字を追ってみます。
多謝。m(__)m


>訳書の場合、まえがき、目次、序論、1章、という順番で並んでいます。
 たぶん同じです。こういう「偉い」本のばあい、チャラチャラした商業出版と
違い、訳者も出版社も、怖くてそういじれません。翻訳権取得時につくられる
契約書にその旨書いてあるばあいも多いです。「改変しないこと。原著のまま
訳出のこと」と。
 1章は「はじめに」ぐらい? 僕でも「さあ、始めてみよう」とは訳せないと
思う。格式みたいなものの演出。



10421/10387 CRG00666  文太             18650
( 1) 22/11/14 21:05 10417:としきさんへのコメント
>私は要らないなぁ。差し上げましょうか?
 ま、財産としてとっておき、遊ぼうとしてみてください。
 3.2V-4.2Vで、500mA以下ぐらいで充電。

>容量の一番多いものを特定する方法って、どうやっているのですか?
>測定?パッケージの印字?
 測定です。中古なので劣化していますから。Opus, BT-C3100というものを使っています。
全部測定、容量記入、ソート。
 1本(20本まで同じ)あたり、2時間(満充電まで)+4時間(完全放電)+2時間
(保管用充電)。計8時間ぐらいかかります。初回時のメンテ&健康チェックです。
 ものすごい本数を所有することになってしまっています。

 光あれ!(笑)



10422/10387 CRG00666  文太             Programming Style
( 1) 22/11/14 21:21 10416:としきさんへのコメント
>10文字も下げたら多重ループの場合にどうなる、みたいな話を昔の
>人は大真面目にやっていたらしい。
 けっきょく趣味と慣れの問題ではないかと思いますが……。
 たしかに、c.mos流に慣れると(読んでません、眺めてます)、もぐらさんも
BASM出力ソースも小文字変換したくなりますが、「慣れよ、いろんな書き方がある」
となってます。
 Basic, Pascalも、case-insensitiveだけど、あるパスカル本は、これが規範じゃ
と言ってましたね。WriteLnとか。ま、これでいく? とか。

 Priusって、日立だっけ? このXPノートPCがどうしても見つからないん
ですよねぇ。EMSが取れるマシンだったので、さんざん迷ったうえで立川で買った
のに。どこ行ったんだろう? cmos電池があがってるよ、ぜったい。としきさんが
知るわけないだろ!

 数学の中間テスト。平均点は53.5点でした。53.5点だった人はいるわけないですよね。



10423/10409 DGF01024  めざら           Re: VZk07t02 テスト版
( 1) 22/11/18 13:05 10409:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
以前(k07t01)で発生していた挿入不具合(としきファイル0007.cgi/0007.cg)は
発生しませんでした。製品版[ESC]I(ek-),自作[ESC]I(ek+) とも正常でした。

ただ,ファイラや1行ウィンドウの背景になる文字化けが厳しいです。
http://mezala.la.coocan.jp/upload/file/39.jpg

この文字化けは環境によるのでしたっけ?
環境はckwv/vtdosです。

今月はじめにメインPCを更新したので,まだ環境が整っていない可能性もあります。
ちとあやふやで申し訳ないですが,とりあえず報告です。

10424/10387 CRG00666  文太             _ST in Pascal_ (1981)
( 1) 22/11/18 13:07 10411:文太さんへのコメント コメント数:1
_Software Tools_ was originally published in 1976 with the programs written in
Ratfor, a language based on Fortran. Ratfor was implemented as a preprocessor;
it provided Fortran with modern control flow statements like if-else and
while, and some cosmetic improvements like symbolic constants and free-form
input. The approach and the tools have proved sufficiently useful that many
copies of them have been distributed, and there is a large, active user group.

Pascal is now the dominant teaching language for computer science courses,
and is becoming widely used outside of universities as well. We feel that the
lessons about the design and implementation of tools from the original book
carry over intact to Pascal. Thus _Software Tools in Pascal_ has a great deal of
overlap with the Ratfor original. The same programs are present, except that
there is no preprocessor chapter, since Pascal provides most of the sensible control
flow and cosmetic improvements that Ratfor adds to Fortran. On those systems
where Pascal needs augmentation, tools such as the macro and file inclusion
processors serve as language preprocessors.


 とりわけ誰も得しない話。
 でも、とても感慨が深かったので。

 _Software Tools_ 『ソフトウェア作法』は、1976年の発表。翻訳もされて、たぶん
世界中で教科書として、独学の際の参考書として読まれたのでしょう。20ページ
くらい読みました。(注1)やはり、プログラミング言語の翻訳の翻訳の要素を含んで
いるので−−Fortranは当然として, PL/I その他その他への言及も多し−−(その上、
日本語のasciiでは表現できないだろう記号が使われていたので、自分の頭の中に翻訳機
を入れなくてはいけない=e-textをVzで読んでます)、表面的には読めるけどすごく
苦労するわりには理解が浅いだろうな、という不安がありました。余計な苦労です(注2)。
 外国語は、単語知っててなんぼですからね。


 そして、_Software Tools in Pascal_。1981刊。翻訳は出てないのかな? 原著と
同じく変更不要な部分はそのまま、主に上のような部分とプログラムリストを書き換え
ればいいだけだろうけど、でも、読者は(パスカルに興味が少しでもあるなら、あるいは
Fortran以前を知らないなら)こっちのほうを絶対に歓迎すると思う。Fortranねぇ。
言語体系を調べられるようになっとく? と思い、いちおうネットでマニュアルを
見つけましたよ……。
 (アメリカで僕が前に住んでいた町にNASAの出先機関があり−−知らなかったよ、
田舎町ですよ−−、そこが開発していた! MS-DOSにも移植できそうだった=その時代の
もの)

 プリプロセッサのイメージが沸いてきましたけど……(RatforがFortranのプリプロセッサ。
この本のために開発された=書かれた。そしてこの著作でその言語を使ってプログラム開発
の奥義を語っている)。(注3)

 なお、上の引用部分は、だいたい13パラグラフ(段落)で構成されている「まえがき」
(Preface)の中の2段落。たぶん、残りは元の本とほぼ同じ。
 上のようなことを言ってる部分があるだろうと思って、探し出しました。STから
読み始めて(眺め始めて)しまって(e-text処理を始めてしまって)、ふと、思いついて、
_ST in Pascal_をさっき覗いて、のけぞりました。こっちのほうが、ぜんぜんいい
じゃないか!
 

 詳細は分からないけど、上に続く部分で、標準パスカルの弱点も指摘されているけど、
たぶん、Turbo Pascal, MS Pascal で、克服されているのじゃないかな。macroとか
file inclusionとかlibraryとか。パスカルのmacroって記憶にないけど。

 何しろVzマクロしか知らないものだから、いちいち新鮮です。
 Vzマクロのこの部分は、C的、アセンブラ的、一般の高級言語的、みたいなことが
分かって楽しいです。

 で、どれだけ読みこなせるか分からないけど、内容的には、テキスト処理オタクの僕に
ぴったり! としきさん、この本のこと思い出してくれて、ありがとう!

 あ、2書とも、目次はほぼ同一です。Ratfor開発・解説の章がなくなっている以外は。
 おお、ついにここでは、正規表現も出てくるのか。なくちゃね。Free Pascalには、それ用
ライブラリがあるのを確認ずみです。言語が何であれ、正規表現エンジンなんて書きたく
ないです。読みたくない、が正確。眺めてみたいか?


(注1)べつに誰にも勧めていませんが、翻訳があるということは、どっかの図書館には
あるということです。

(注2)かつて「吉本隆明が理解したければ、日本語を勉強しろ」とかありました。考えて
みれば、外国人の日本文化研究者や日本アニメおたくの方々は、まさしくそれをやっている
わけですが。僕もそうだったんだ。しかしそんなに色々やれないのは自明。

(注3)c.mosさんのソースには、if ... else, break, until, while, repeatがある。それを
vz.incのマクロが展開する。これがプリプロセッサ的作業ですね。マクロ、柔軟ですねぇ。
やはり、自分で自分を書き換えているイメージ。Virtual Machine? 自己書き換えマクロ!



10425/10387 CXB00940  としき           Re: _ST in Pascal_ (1981)
( 1) 22/11/18 16:31 10424:文太さんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
>  そして、_Software Tools in Pascal_。1981刊。翻訳は出てないのかな?

こっちは読んでいませんが、いまさらFortranでもない、という気持ちはよくわかる。
Fortranはなにがいいって、数学のライブラリが充実していること。もしかしたら、
最新のスパコンにもFortranのコンパイラはあるかもしれない、というくらい。

> (Preface)の中の2段落。たぶん、残りは元の本とほぼ同じ。

ちなみに、私が#10417で一読をお勧めしたのは、Ratfor版の、おそらくIntroduction
の最初の部分に該当しそうな気がしています。Pascal版でも、導入部はほぼ同じだと
思いますが、読み比べていないのでわかりません。

10426/10409 BQO00549  konno            Re^2: VZk07t02 テスト版のバグ
( 1) 22/11/18 20:19 10423:めざらさんへのコメント コメント数:1
> 以前(k07t01)で発生していた挿入不具合(としきファイル0007.cgi/0007.cg)は
> 発生しませんでした。製品版[ESC]I(ek-),自作[ESC]I(ek+) とも正常でした。

めざらさん、どうもです。
私もテストデータでテストした範囲しか把握していないので、他で問題が出ることはあると思います。

> ただ,ファイラや1行ウィンドウの背景になる文字化けが厳しいです。
> http://mezala.la.coocan.jp/upload/file/39.jpg
>
> この文字化けは環境によるのでしたっけ?
> 環境はckwv/vtdosです。

げげ、この症状は初めて見ました。
起動後すぐに症状が出るのですか。
発生手順が再現できるのであれば教えてください。

> 今月はじめにメインPCを更新したので,まだ環境が整っていない可能性もあります。
> ちとあやふやで申し訳ないですが,とりあえず報告です。

他のVZで症状が出ないのであればテスト版のバグだと思います。

私は当初 k07t01 のテスト版に入れ替えていたのですが、CGI や HTML の更新で困ってしまいました。
連番セーブでファイル名が大文字になってしまい、いちいち小文字に直さないといけないのです。
なので普段は常用VZのテスト版で使っています。

テスト版ではマクロがバッファから消えて使えなくなることがたまにあるようです。
マクロのロードかバッファ絡みの問題があるかもです。


10427/10387 CRG00666  文太             Re^2: _ST in Pascal_ (1981)
( 1) 22/11/18 20:28 10425:としきさんへのコメント コメント数:2
#10417
>訳書で言うところの序論("Introduction")の
>最初の5パラグラフほどを読んでいただくと、その先を読みすすめるべきか判断
>できると思います。

 構造化、という文脈で、この本が出てきたのでしたっけ? たぶん、もう5パラグラフ
読んだと思うけど(最後までできるものなら読み通したいとの判断)、僕との会話で
としきさんが何に引っかかったのか(思い出したか)知りたいので、もう一度読んで
みます。
「序論」後半は、先の各章の簡単な紹介ですよね。
 ただ、元がpdfで上下さかさま(OCRで化け化け化け化け)のページが「序論」
に入っていたみたいなので、ちょっと1ページごとのe-text作りになりそう。

 具象的個々別々の問題への抽象的解法を見出す。

 僕が日常的にやっている作業より高度なテキスト処理の話だと思うけど、プログラミング
環境を整えるプログラムの作成について、が全体のテーマですよね。
 grep使って、statementだけ取り出す、とか。
 grepの作り方、という話でしょうけど。


冒頭5パラグラフ。
------------------------------------------------------------------------------
	INTRODUCTION

We are going to discuss two things in this book -- how to write programs 
that make good tools, and how to program well in the process. 

What do we mean by a tool? Suppose you have a 5000-line Pascal program 
and you need to find all references to the variable time, to make sure it can 
safely be changed from type integer to type real. How would you do it? 

One possibility is to get a listing and mark it up with a red pencil. But it 
doesn't take much imagination to see what's wrong with red-penciling a hundred 
pages of computer paper. It's mindless and boring busy-work, with lots of 
opportunities for error. And even after you've found all instances of time, you 
still can't do much, because the red marks aren't machine readable. 

Another approach is to write a simple program to find lines containing the 
identifier time. This is an improvement, for such a program is faster and more 
accurate than doing the job by hand. The trouble is that the program is so specialized 
that it will be used once by its author, then tucked away and forgotten. 
No one else will benefit from the effort that went into writing it, and something 
very much like it will have to be reinvented for each new application. 

Finding time's in a Pascal program is a special case of a general problem, 
finding patterns in text. Whoever wanted references to time today will want 
references to some other variable tomorrow, readln and writeln calls the 
day after, and next week an entirely different pattern in some unrelated text. 
Red penciling never ends. The way to cope with the general problem is to provide 
a general purpose pattern finder that will look for a specified pattern and 
print all the lines where it occurs. Then anyone can say 

	find pattern 

and the job is done. find is a tool: it uses the machine; it solves a general 
problem, not a special case; and it's so easy to use that people will use it instead 
of building their own. 
------------------------------------------------------------------------------

 おお、ちゃんとパスカル用になっている。が、内容は同じと言ってよいでしょう。
 ただ、ここまで一般的(抽象的)な問題を解決するツールを僕が開発するとは思えない
ですけどね。grep/sed/awkの使い方を十分マスターすれば良いような気がする。
まだまだ十分でないから。
 逆に、

2022/11/06  18:58    369 srch_do1.def
2022/10/29  11:23    220 srch_do2.def
2022/10/31  22:44    199 srch_do3.def
2022/10/31  23:06    209 srch_do4.def
2022/11/01  01:59    199 srch_do5.def
2022/11/01  02:13    131 srch_do6.def
2022/11/18  11:42    176 srch_do7.def
2022/11/06  18:25    321 srch_do8.def
2022/11/14  01:08    126 srch_do9.def
2022/11/16  00:15    298 srch_doa.def
2022/11/17  17:25    321 srch_dob.def
2022/11/18  11:48    240 srch_doc.def

 これらにちゃんと名前をつけて、管理せい! という感じですかね。
 あ、これ、もぐら流。中身の変更箇所がちょっとずつ違うだけ。
 これらに一般解はないです。問題のほうが"special case"だから。個別だから
偉いツール群。

 それでも、いい本っぽいと思っています。何かが得られるよう精進したいです。
 ありがとうございます。
 なお、パスカル版の翻訳はないみたいでした。


 蛇足。Pascal版 Intro pp.1-2。ページまたぎ部分。


All of them have been run without change on a variety of machines and Pascal 
compilers. 
				;A
---------------------[End of Page 1]---------------------
				;B
The second concern of this book is how to write good programs.

 このページ区切りフッタあたりに色々なノイズが入ります。Aの箇所にページとか
Bの箇所に"Introduction", "CHAPTER 1", "INSIDE THE IBM PC" (see #10359) とか。
それも壊れて化けたりもして。スペースや改行が入ったりもする。それらをVzマクロ
やsedで掃除しています。

 点検は、
>cgrep -A2 -B2 "End of "	;After & Before

 find pattern に同じ。



10428/10387 CXB00940  としき           Re^3: _ST in Pascal_ (1981)
( 1) 22/11/18 22:11 10427:文太さんへのコメント
参照先:http://toshiki.la.coocan.jp/
> 冒頭5パラグラフ。

おぉ、やっぱり「100ページのプリントアウト」だの「赤鉛筆でチェック」だの
といったことは書いてあるのですね。

>  ただ、ここまで一般的(抽象的)な問題を解決するツールを僕が開発するとは思えない
> ですけどね。grep/sed/awkの使い方を十分マスターすれば良いような気がする。

今ではそうなんですけどね。
当時、そういったツールがなかった時代に思いを馳せてください。
いわゆる、古典古代、というヤツかな。違うかもしれない。
あまり文系的な用語はわかりませんが。
この本で取り上げられているのは、そういったツールの作り方がメインではあるのです
が、ツールを作るにあたっての考え方を通して、構造化をはじめとするソフトウェアの
構築法というか理念というか哲学というか、トップダウンではなくボトムアップでその
ような考え方を身につける、ということのように、私は捉えました。もちろん、これは
著者側の考えとはずれているかもしれません。

10429/10409 DGF01024  めざら           Re^3: VZk07t02 テスト版のバグ
( 1) 22/11/19 16:21 10426:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
> 起動後すぐに症状が出るのですか。

起動直後のファイラー背景は化けません。(ほぼ化ける文字がないから?)

ファイルをひとつ開いた状態で,[ESC]O など入力窓を表示した場合に
(WLの値で位置は変わりますが)入力窓の位置よりも下の部分が全部化けます。

WL1にして色々なY位置で試したところ,常に化けるのではなく,化けない位置もあります。

カーソルY位置を上の方で広範囲に化かした場合,入力窓をキャンセルすると元に戻り,
WL15とかで狭範囲に化かした場合,カーソルを下端まで移動して画面の更新をしないと
化けた状態がいつまでも残るという感じもあります。

ここからファイラーに遷移すると,ファイル数が少ないディレクトリを表示している側は
背景のテキストが盛大に化けます。(海豹に上げた画像のとおり)

あとは,メニューの中身(こちらは背景ではない)が化けます。
すべてのメニューが化けるというわけではないようですが。

いまのところ表示上の「不具合手前」くらいな感じですね。

ですが,化けるのは精神衛生上よろしくないので長くは使えないです。(^^;


10430/10409 BQO00549  konno            Re^4: VZk07t02 テスト版のバグ
( 1) 22/11/20 01:43 10429:めざらさんへのコメント コメント数:1
> ファイルをひとつ開いた状態で,[ESC]O など入力窓を表示した場合に
> (WLの値で位置は変わりますが)入力窓の位置よりも下の部分が全部化けます。

うーむ、やっぱりうちでは出ないですね。
Dw- メニューのシャドー表示抑止も関係ないみたいです。
VTDOSかCKWVの環境依存でしょうかね。

> カーソルY位置を上の方で広範囲に化かした場合,入力窓をキャンセルすると元に戻り,
> WL15とかで狭範囲に化かした場合,カーソルを下端まで移動して画面の更新をしないと
> 化けた状態がいつまでも残るという感じもあります。
>
> ここからファイラーに遷移すると,ファイル数が少ないディレクトリを表示している側は
> 背景のテキストが盛大に化けます。(海豹に上げた画像のとおり)
>
> あとは,メニューの中身(こちらは背景ではない)が化けます。
> すべてのメニューが化けるというわけではないようですが。

うう、イメージスタックが怪しいですが、フォント絡みも怪しそうな。
でも VZK07T01 との違いはテスト用の修正ルーチンだけなんですよね。
VZK07T01 で問題が出ていないとしたら、修正箇所がここまで影響しているのかしらん。

> いまのところ表示上の「不具合手前」くらいな感じですね。
> ですが,化けるのは精神衛生上よろしくないので長くは使えないです。(^^;

現在の版は何かしら問題が有ると思っていましたがこの症状は意外でした。


10431/10409 DGF01024  めざら           VZk07t02 テスト版のバグに非ず
( 1) 22/11/20 05:42 10430:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
ごごご,ごめんなさい。(^o^;;;
まだ新PCの環境設定不足の状態であったのが,文字化けの原因でした。

フォント絡みを疑って VLゴシック とか BIZ UDゴシック に切り替えても症状があり,
一旦,t01 に戻したところが絶賛発生中ではありませんか。。。(何故気付かない)

えーと……レガシーコンソールでしたっけ…… どのショートカットで変えるんだったかな
しこしこ……あ,直りました。(^^;

10432/10409 BQO00549  konno            Re: VZk07t02 テスト版のバグに非ず
( 1) 22/11/20 18:02 10431:めざらさんへのコメント
> フォント絡みを疑って VLゴシック とか BIZ UDゴシック に切り替えても症状があり,
> 一旦,t01 に戻したところが絶賛発生中ではありませんか。。。(何故気付かない)

ま、まあ、よくあることですよね・・・(^^;;

> えーと……レガシーコンソールでしたっけ…… どのショートカットで変えるんだったかな
> しこしこ……あ,直りました。(^^;

レガシーコンソールを指定しないとこんな症状が出るんですね。
とりあえずテスト版の致命的なバグでなくてよかったです。(^^;


10433/10409 CXB00940  としき           Re^2: VZk07t02 テスト版
( 1) 22/11/24 02:35 10413:としきさんへのコメント コメント数:3
参照先:http://toshiki.la.coocan.jp/
今日が雨だったため自宅篭城となり、やっと雑務が大幅に片付いた。
まだ残務は大量にあるというか、当初見込みの6〜7割くらい片付いたと思った
のに、実は3割そこそこしか片付いていなかった、という現実もあるわけですが。
そして、そんなに大量に残っているというのに、もうこんな時間。
日付が変わってしまっとるがな。
明日、というか今日24日は、洗濯したいから、あんまり寝坊はしていられないと
いうのに。

それはさておき。

> 実際にパッチを当てて動作試験ができるのは、おそらく、今週の木曜日以降になって
> しまう予定。当面、便りがないのは良い便り、と思い込んでおいてください。

やっとパッチを当てて動作試験をしました。
オリジナルのvz.defにBlだけ8192に変更したものを読んで起動し、0007.cgiを開いた
ところで0007.cgを挿入して、無事に正常挿入。うれしい!

おそらく今後、もしかしたら私の主戦場は、野ざらしからこちらに移動することに
なるかもしれない。
ということで、これから確認したい項目。
80桁未満で桁折しても状況が発生しそう、ということから、例えば、以前、文太さん
に提供していただいたニフティのログを使って、ファイルサイズを0007.*と同じに
したものを作って状況がどうなるか。

あ、そうだ、これはkonnoさんに聞くべきか、めざらさんに聞くべきか。
Blとかのバッファの開始ポイントのアドレスをVzのマクロで取得するには、どう
すればよろしいのでしょうか?
あまり関係はないとは思いますが、今回のテスト版で、もし以前の版と大幅に変化
しているかどうか確認できれば、と思いまして。

10434/10409 DGF01024  めざら           Re^3: VZk07t02 テスト版
( 1) 22/11/24 18:43 10433:としきさんへのコメント
参照先:http://mezala.la.coocan.jp/
> おそらく今後、もしかしたら私の主戦場は、野ざらしからこちらに移動することに

VZ本体のバグである可能性が非常に高いのではないかと考えられるのであれば,
こちらで相談されるのがよいかと存じます。
マクロの問題であればウチの方でもまぁ大丈夫です。

> Blとかのバッファの開始ポイントのアドレスをVzのマクロで取得するには、どう
> すればよろしいのでしょうか?

m.gann師の「ばふつあ」を強くおすすめします。
BUFTOUR.DEF 1.6A ばふつあ Buftour.def v1.6a Vz内部を探る
http://mezala.la.coocan.jp/vz/history/h_ear/lib/buf16a.lzh

自前のマクロを作りたいということであっても,上記のマクロのコードが
大いに参考になると思います。(全バッファの相対アドレスが書かれている。)

実際の各バッファの先頭アドレス(相対アドレス)は,マップを御覧ください。
スタックセグメント・マップ
http://mezala.la.coocan.jp/vz/notes/segmap.html

例えば,ラインバッファなら,相対アドレスは wm+228 または pq..148 です。
wm+228/pq..148 2バイト(0D,0A) CR/LFがラインバッファ先頭に予め置かれている
wm+230/pq..148+2 ラインバッファ本体(サイズはBl-2)


10435/10409 BQO00549  konno            Re^3: VZk07t02 テスト版
( 1) 22/11/24 20:54 10433:としきさんへのコメント コメント数:1
> オリジナルのvz.defにBlだけ8192に変更したものを読んで起動し、0007.cgiを開いた
> ところで0007.cgを挿入して、無事に正常挿入。うれしい!

テストデータを対象にバグを回避しているだけなので他で問題が出ると思います。
テスト版はマクロの読み込み関連でバグがあるようですのでご注意ください。

> ということで、これから確認したい項目。
> 80桁未満で桁折しても状況が発生しそう、ということから、例えば、以前、文太さん
> に提供していただいたニフティのログを使って、ファイルサイズを0007.*と同じに
> したものを作って状況がどうなるか。

検証はよろしくお願いします。m(__)m

> Blとかのバッファの開始ポイントのアドレスをVzのマクロで取得するには、どう
> すればよろしいのでしょうか?
> あまり関係はないとは思いますが、今回のテスト版で、もし以前の版と大幅に変化
> しているかどうか確認できれば、と思いまして。

BLの相対アドレス情報などは、めざらさんが出してくれたので(ありがとうございます)
VTDOS環境での絶対アドレスは

vzk07t01  vzk07t02 test
D192	pq..148		lbuf		8192
F192	pq..149		tmpbuf4		256

スタック領域なので、コードの修正分サイズが増えても変わりませんね。
常駐/非常駐とも同じです。
同じマクロ環境で、高橋版は
vzt 
CFFE	pq..148		lbuf		8192
EFFE	pq..149		tmpbuf4		256

この差は、#if 文でマクロの構成が違うからかなぁ。
オリジナルVZとマクロでは

vzo
777C	pq..148		lbuf		2048
7F7C	pq..149		tmpbuf4		256

BLは変えてるかもですが、だいぶ余裕がありますね。
このラインバッファのサイズで挙動が変わるのは、メモリ転送ルーチンで
ラインバッファを一時バッファとして使っているのが関係しているのかなぁ?


10436/10387 CRG00666  文太             Re^3: _ST in Pascal_ (1981)
( 1) 22/11/28 21:22 10427:文太さんへのコメント コメント数:1
 地獄の仕事場から息継ぎのため、一瞬だけ、浮上してみます。
 すいません、疲れてます。完全なる雑巾状態。そういうときは、こういう無意味な
読書をするにかぎるのです。

    Readers who are sensitive to questions of efficiency may wonder if it is 
economical to use two programs when one would serve. The answer depends 
on the true costs involved, which are often not properly estimated. Most people 
who talk about "efficiency" are concerned primarily with how much machine 
resources are used in the final run or in hands-off production, not with how 
much "people" and machine time is consumed in all the compilations, debugging 
and other false starts that prepare for the final run. Throughout this book 
we consistently take the view that people cost a great deal more than machines,
and that the disparity will increase in the future. Therefore the most important 
consideration is that people get their jobs done with a minimum of fuss and 
bother. 

---------------------[End of Page 82]---------------------

 効率の問題に敏感な読者は、1 つのプログラムで事足りるのに、2 つのプログラム
を使うのは経済的なのだろうかと思うかもしれない。その答えは、しばしば正しく
見積もられていない真のコストに依存する。「効率」について語る人の多くは、
最終的な実行やハンズオフ生産でどれだけの機械資源が使われるかに主眼を置いて
おり、最終実行の準備のためのコンパイル、デバッグ、その他の誤ったスタートで
どれだけの「人」と機械時間が消費されるかには関心がない。本書では、一貫して
「人は機械よりもコストが高い」「その格差は今後ますます広がる」という見解を
とっている。したがって、最も重要なことは、人が最小限の手間で仕事を成し遂げる
ことである。(DeepL による翻訳。立派! トーンだけ改変)

 (ハンズオフ生産だけでしょう、意味不明なのは。消費も変か。最後のところは
  やるね、と思いました。しかし手を入れたくもなる、が、「人」はコストが高い
  のです)

 さすがです、カーニハン先生。ごもっとも!

C:\C>dir /L /B |sort
2repl.def	
2repl2.def	
2strsrch.def	
999.def		
addzspc.def	
alpha.def	
altkey_t.def	
arr_srch.def	
array2.def	
array3.def	
blk0.def	
bothmov.def	
catg_fix.def	
cnd_sch1.def	
com_box.def	
 (以下50行略。うひょひょひょひょ。下品な笑い)

 さすがにこれだけパスカルのコードを読むと、けっこう単語を覚えるものですが、
やっぱりVzマクロが僕にとって最高の高級言語だ、という確信も強くなりますね。
 仕事するするVzマクロ。いえ、本業じゃありません。



10437/10409 CXB00940  としき           Re^4: VZk07t02 テスト版
( 1) 22/11/29 23:57 10435:konnoさんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
今日も天候不順で自宅篭城。
やっと雑務が9割がた終わった。
件数ベースだと、パソコンを使用して解決する必要のある雑務は残り2件。
もっとも、件数ではなく実労力だと、既決は8割弱といった感じ。
もちろん、パソコンとは無関係の雑務もいくらかあるし、日々新しい案件も増える
のだけど、もうどうでもいいやって感じ。

> テスト版はマクロの読み込み関連でバグがあるようですのでご注意ください。

この状況、うちでは発現しないようです。
もし、確実に再現する手順とかがわかれば、追試させていただきますよ。


アドレスについては、いろいろとご教示ありがとうございます。
ただ、いろいろと環境をあわせないと同じ値にはならないのかもしれません。
いろいろなものを合わせなかったときの値は、手元の常用環境である1.60t03kの
Bl8192で

pq..148 DD3Ah
pq..149 FD3Ah

となりました。一方、k07t02 test版とオリジナルvzibmj.def、ただしBl8192の場合は

pq..148 77BCh
pq..149 97BCh

でした。
なんかいずれも、ちょっと見には危なそうな値ですね。
常用環境の場合は、なにかがFFFFhを超えてしまいそうだし、test版の時は8000hを
またいでいるし。

> このラインバッファのサイズで挙動が変わるのは、メモリ転送ルーチンで
> ラインバッファを一時バッファとして使っているのが関係しているのかなぁ?

そういうことをやっているんですか。
なんかこれ、思いっきり妖しそうですね。

10438/10409 CXB00940  としき           Re^3: VZk07t02 テスト版
( 1) 22/11/30 00:28 10433:としきさんへのコメント
参照先:http://toshiki.la.coocan.jp/
> 80桁未満で桁折しても状況が発生しそう、ということから、例えば、以前、文太さん
> に提供していただいたニフティのログを使って、ファイルサイズを0007.*と同じに
> したものを作って状況がどうなるか。

試してみました。常用環境です。test版ではありません。
まず、0007.cgiと同じサイズになるようにDC15_968.LOGというファイルの先頭から
切り出し、次に0007.cgと同じサイズになるようにDC15_971.LOGというファイルの
先頭から切り出し。そして、同じように、ファイルを開き、先頭で即挿入。
結果。
異常は再現しません。正常挿入。なんてこった。
ま、そうだよねぇ。そんなに頻繁に起こるのであれば、とっくに報告が上がって
いたはず。ということは逆に、なぜ私のあのファイルでは異常が起こるのか。

次に試したいこと。
異常の起きないログファイルと、76桁で桁折した私のファイルで、非常に大きい
差として挙げられるのは、空行比率。私のサンプルファイルでは、空行は実質的に
ゼロです。ということで、ログファイルから空行を全て削除したものを作って、
それで異常挿入が起きるか否か。さらに、awkあたりを使ってダミーのファイルを
作り、それで挿入異常が起きるか否か。もし、これらのでっち上げたファイルで
異常挿入が起きないのであれば、やっぱり何かファイルが悪い、ということに
なってしまうわけで。その結論はイヤだな。

10439/10387 CXB00940  としき           Re^4: _ST in Pascal_ (1981)
( 1) 22/11/30 01:49 10436:文太さんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
う〜む、この返信フォームの直上の関連一覧ツリー、なぜこんなに乱れているのか。
いいかげんkonnoさんには本腰を入れて修正していただきたいところ。

>  地獄の仕事場から息継ぎのため、一瞬だけ、浮上してみます。

私なんか、職場よりプライベートが多忙で。
職場でも、プライベートが気になって落ち着かなかったりして。

>  効率の問題に敏感な読者は、1 つのプログラムで事足りるのに、2 つのプログラム
(中略)
> ことである。(DeepL による翻訳。立派! トーンだけ改変)

ぅぉぉ、きちんと意味の通る訳になっていますね。さすが、最近のAI。
ちなみに、40年前に、ほぼ同様の原文を人間が訳した文章が以下。

 効率の問題に敏感な読者は、プログラムが一つですむところでわざわざ二つに
するのは経済的なのだろうか、と心配かも知れない。その答えは、何が真の費用
であるかによって違ってくる。そしてその真の費用なるものは正しく見積もられ
ていないことの多いものである。「効率」についてうんぬんする人々は、たいて
いの場合主として本番計算に計算機資源がどのくらい使われるか、という点にば
かり着目していて、コンパイルしたり、虫取りしたり、その他のさまざまなやり
そこないをしたりしながら本番計算にそなえるために消費される人間の時間と計
算機の時間を考えに入れていないものである。われわれはこの本では一貫して、
人間の方が機械よりずっと高くつくものであり、その差は将来ますます開くの
だ、という見かたをとっている。だから、一番大切な考慮点は、仕事をかたづけ
るまでに要する人間の側の気苦労を最小にすることだ、ということになる。

>  (ハンズオフ生産だけでしょう、意味不明なのは。消費も変か。最後のところは
>   やるね、と思いました。しかし手を入れたくもなる、が、「人」はコストが高い
>   のです)

原文の差異がどうなっているかわかりませんが、業界では、消費というのはそれほど
不自然な言葉ではないと思う。私も、この文脈では、消費という言葉に違和感を感じ
ません。

>  さすがです、カーニハン先生。ごもっとも!

こういう、ごもっとも、という内容がたくさん含まれているから古典なんだ、という
こともあるかもしれない。
私が最初に読んだ時は、どちらかというと、なるほど、という感想を抱いた部分が
多かったですけどね。だって、Fortranをマスターする前、BASICとアセンブラしか
知らなかった時代の私が、仮想言語(と私は捉えた)であるRATFORを使ってアルゴ
リズムを説明する本を読んで、それなりに勉強になったと思えたわけですから。

10440/10409 BQO00549  konno            Re^5: VZk07t02 テスト版
( 1) 22/11/30 21:20 10437:としきさんへのコメント
> 常用環境の場合は、なにかがFFFFhを超えてしまいそうだし

pq..149 は、tmpbuf4 で、ソースでは使われていないようです。
緩衝領域として256バイト設定しているのは、プッシュポップのスタックが後ろから積まれるからかも。
そうだとすれば、この領域を使うのは危険ですね。
pq..149 が、FF00h を超えていたらバッファを減らさないと危険ということでしょうか。

げげ、私知らないで私家常用版で使ってしまっていました。(>_<)
見直さなくては。(^^;;

> test版の時は8000hをまたいでいるし。
あ、そうか、ラインバッファが8000hをまたぐバグってこれを言っていたんですね。

うちのオリジナルVZとマクロでは
vzo
777C	pq..148		lbuf		2048
7F7C	pq..149		tmpbuf4		256

テスト版vzとオリジナルマクロでは
7822	pq..148		lbuf		2048
8022	pq..149		tmpbuf4		256

この環境で、8000h をまたぐバグが出るかどうか確認すればいいのか。
ん? 高橋版で直っていたかしらん? ちょっと過去ログの海に潜ってみます。


10441/10387 CRG00666  文太             Re^5: _ST in Pascal_ (1981)
( 1) 22/12/01 16:15 10439:としきさんへのコメント

 原文は、まったく同じでした。

DeepL
「効率」について語る人の多くは、最終的な実行やハンズオフ生産でどれだけの
機械資源が使われるかに主眼を置いており、最終実行の準備のためのコンパイル、
デバッグ、その他の誤ったスタートで

 (「誤ったスタート」でだいたい通じますね。コンピュータって、コンピュータ
に対してやたら強いのですよね、きっと。
 が、"consideration"を訳出しないという判断は、もう人間並みかよ、と思いました)


邦訳書
「効率」についてうんぬんする人々は、たいていの場合主として本番計算に計算機資源が
どのくらい使われるか、という点にばかり着目していて、コンパイルしたり、虫取りしたり、
その他のさまざまなやりそこないをしたりしながら本番計算にそなえるために消費される
人間の時間と計算機の時間を考えに入れていないものである。

 (訳出がどうというより、意味がよく分かる文章だと思います。「ハンズオフ生産」の部分は
よく分からないし、そんなに重要とも思えないから、飛ばす! という判断でしょうか。
アリだと思います。本番計算!)



Throughout this book we consistently take the view
that people cost a great deal more than machines,
and that the disparity will increase in the future.
Therefore the most important consideration is
that people get their jobs done with a minimum of fuss and bother.

#DeepL
本書では、一貫して
「人は機械よりもコストが高い」
「その格差は今後ますます広がる」
という見解をとっている。したがって、最も重要なことは、
人が最小限の手間で仕事を成し遂げることである。

#人間(40年前)
われわれはこの本では一貫して、
人間の方が機械よりずっと高くつくものであり、
その差は将来ますます開くのだ、
という見かたをとっている。だから、一番大切な考慮点は、
仕事をかたづけるまでに要する人間の側の気苦労を最小にすることだ、
ということになる。

 やっぱり、僕がいちばんに驚くのは、間接話法を直接話法にすることが、
機械にできた、ということかな。

 「人は機械より…」の部分。原文には、「 」とかないのです。
 しかし、「 」(直接話法)があったほうが、ずっと読みやすい、