新着記事

− 野ざらし言 −

新規投稿は記事一覧のフォームからお願いします

[5885] Re^5: DOSVAXJ3を使ったVz

めざら 2025/05/31(Sat) 16:03
[関連記事] [5884]へのコメント
http://mezala.la.coocan.jp/
> 昔はゼロのフォントを作っていたことがあったような記憶

LX を使っていた頃は,14ドット程度でも視認性がよくなるようにフォントエディタで編集していましたね。半分は遊びだったので楽しかった。

> 昔、私はVzで何をやっていたのか? そして現在で使えるものは何か?

仕事や趣味で必要な作業も変遷しますから,ゼロから始めてもよいのではないかと思います。わたしも VZ ばかり使っているわけではなくて,作業の半ば以上は Windows のアプリケーションになります。VZ では定型的な編集作業をマクロでやっつけて,他に貼り付けるということが多いですね。なにせテキストエディタですから。

Windows のアプリケーションと連携するのに便利なのが,寅次氏の作成したコマンドラインツールの CLPPST.EXE と 関連マクロの CLPPST.DEF です。クリップボードのテキストをやり取りするためのツールで,Windows 環境においてはもはや必須と言ってもよいでしょう。素の dosvaxj3 でもクリップボードを扱えますし,流石にマウスで選択とはいきませんが,榊原氏の「いきなりブロック」というマクロを使えば,Windows の [Shift]+[移動キー] と同等の使い勝手ですから面倒はありません。逆にマウスに手を伸ばす方が面倒かなと思ったりもします。時短の時代ですから。

お手伝いできることは手間を惜しみませんので,今後ともよろしくお願いします。

[5884] Re^4: DOSVAXJ3を使ったVz

KTAM 2025/05/29(Thu) 21:52
[関連記事] [5883]へのコメント
https://ktamsan-restore2.blog.jp/
> とりあえずベターな表示を得られたようでよかったです。
DOSVAXJ3の敷居の低さと、めざらさんのサンプルのおかげです。

ゼロとオーの判別は今のWinでもわかりにくく不便ですね。昔はゼロのフォントを作っていたことがあったような記憶がよみがえりました。

行幅の広いSVGAができても、さすがにDOSのJW_CADは今では動かさないので
chev vt3 は今のところ必要ないようです。vt2でいきます。

自分のDEFファイルを印刷して通勤時に読んでみましたが、1行もわかりません。10年以上のブランクはなかなか簡単には埋まらないようです。少しづつめげずにやってみます。昔、私はVzで何をやっていたのか? そして現在で使えるものは何か? がわかれば良いですね。

WINに慣れた身としては、Vzの画面からマウスで文字を拾って、Win画面にペーストできれば便利だよね。。。などと、できるのかどうか思いつきました。

今後も野ざらし言で超初心者な質問をすると思いますがよろしいでしょうかね。。。すでにしていますが。

[5883] Re^3: DOSVAXJ3を使ったVz

めざら 2025/05/28(Wed) 17:33
[関連記事] [5882]へのコメント
http://mezala.la.coocan.jp/
ブログの図は試行錯誤の過程がわかりやすくてよいですね。
とりあえずベターな表示を得られたようでよかったです。

わたしも本当は0(ゼロ)とO(オー)が判別しやすいフォント(VL Gothic とか UME Gothic など)を使いたいのですが,滲んで見えるような感じなので,結局いちばんすっきり見える MSゴチに落ち着いています。

> chev vt3 にするとsxgaになり幅が広くなります。どう使うのか?です。

もともと V-TEXT は解像度を上げた環境で桁数・行数を拡張してテキストの情報量を増やすものなので,解像度に合わせた桁数にしてやればよいのかもしれません。インスタントマクロ([ESC]@)で【we=wd=wx】などと実行してみてください。横幅いっぱいに使えるでしょう。ただし,テキストエディタは表示行幅がタブカラムの倍数でないとなんだか気持ちわるいですし,その幅を前提に情報を他の人とやりとりするわけにいかないですから,80桁にいちばん近く行間も少し空いているところに落ち着くように思います。

テキストエディタではなく,例えば JW-CAD とかを使うのであれば,画面が広く使えて快適なのではないでしょうか。

> さてこれからがVzのリハビリです。これが大変そうです。

ぜひマクロをばんばん使い倒してください!

[5882] Re^2: DOSVAXJ3を使ったVz

KTAM 2025/05/27(Tue) 22:24
[関連記事] [5881]へのコメント
https://
助かりました。
真似してやってみました。ひとつずつ組み込んだ経緯は私のブログに書きました。

> jfontuse20 = true
> #jfontuse20 = false
これはtureですね。falseだとフォントがきたなかったです。

「jfontuse20 の設定は Windowsフォントで24×24ドットフォント使用時に20×20ドットフォントで代用する方法です。MSゴシック等のフォントは24×24のビットマップデータが内蔵されておらず表示が汚くなるためこの設定を有効にします」とコマンド比較の表に書いてありました。

> 同じvt2で起動しているということは,上の vtext2 の設定が
> vga になっていたりするのではないでしょうか。

vtext1 = svga
vtext2 = xga24,40
vtext3 = sxga24,40
vtext4 = vga,50

ハイ正解です。教えていただいたこれをそのまま実行したらフォントが大きくなりました。 \(^o^)/
chev vt3 にするとsxgaになり幅が広くなります。どう使うのか?です。

とりあえず見やすく大きくなってVzが立ち上がるようになりました。
一日で大きな進化で。ありがとうございました。

いろいろググっていたら、konnoさんやとしきさんのページも見つかって、これも参考にさせていただきました。

さてこれからがVzのリハビリです。これが大変そうです。

[5881] Re: DOSVAXJ3を使ったVz

めざら 2025/05/26(Mon) 22:38
[関連記事] [5879]へのコメント
http://mezala.la.coocan.jp/
お久しぶりです,ktam さん。
復活への道ですね!

Android の dosbox で VZ を走らせていた ktam さんにヒントをと言うのも
烏滸がましい気もしますが,多分 VTEXT モードの設定のせいだと思います。

手元の dosbox.conf では,以下のようになっています。

#jfontname     = MS 明朝
jfontname     = MS ゴシック

jfontuse20    = true
#jfontuse20    = false

#■■■■■■■■■■■■■■■■■■
vtext1        = svga
vtext2        = xga24,40
vtext3        = sxga24,40
vtext4        = vga,50
#■■■■■■■■■■■■■■■■■■

そして,末尾の [autoexec] の部分で

mount c c:\
C:
cd vz
path=c:\vz;%path%;
set TMP=c:\windows\temp
SET WINDIR=LFN
chev vt2
v.bat

……となっています。
同じvt2で起動しているということは,上の vtext2 の設定が 
vga になっていたりするのではないでしょうか。
あるいは windowresolution が環境と異なっていたりとか。

あれ? jfontuse20 = faise って false の転記誤りですか?
うちは jfontuse20    = true ですが……

実はわたしもあまりよくわかっていないのです。(笑)

[5880] Re: 種蒔・栽培 2025 (甘藷)

めざら 2025/05/26(Mon) 21:55
[関連記事] [5725]へのコメント
http://mezala.la.coocan.jp/
昨年は調達が遅れて目当ての品種が育てられなかった甘藷ですが,今年は紅東を20本買いました。購入したのは先週の火曜だったのですが,植付けの準備ができていなかったため,培養土を満たした洗面器に浸けておきました。

その状態で漫然と構えていたら,白黴らしきものが出てきたため,本日慌てて植え付けました。

ほとんどは発根していましたが,葉が腐ってしまっていたものもあり,もしかすると全滅に近いことをやらかした可能性を否定できません。

甘藷は先に準備を整えてから調達せねばならぬ……ということですね。

[5879] DOSVAXJ3を使ったVz

KTAM 2025/05/26(Mon) 21:55
[関連記事]
https://
お久しぶりでございます。
Vzを復活させたいと思って早2年。最近、めざらさんの「64ビット版Windows環境」の「DOSVAXJ3」を読んで、これならできるかも、と思い始めて早速やってみました。
Vzが立ち上がっただけですが、嬉しい。やった。
それで相談ですが、フォントが小さいのを大きくしたいのですが、サイズがかわりません。
dosboxj.confのどこを弄るのか? よくわからない。

[dosbox]
jfontsbcs =
jfontdbcs =
jfontsbcs16 =
jfontdbcs24 =true
jfontsbcs24 =true
#
#jfontuse20 = true
jfontuse20 = faise

[autoexec]
@echo off
mount c c:\
mount d d:\
C:
cd vz
path=c:\ut;D:\wt;%path%;
set vzdef=c:\vz\vz.def
set tmp=c:\tmp
set ASM=m
set VZBAK=.\bak
set vzsym=AXJ3
#vwx -z2 -v2 -x1 -l4096

chev vt2
AZ.bat
-----------ここまで

------ AZ.bat ----------
@ ECHO OFF
CD \VZ
VWX -Z2 -L4096 -X1 -V3
c:\VZ\vz.com -Nd+ /Az %2 %3

こんな感じで実行して、Vzが立ち上がったのは感激でした。
なにかフォントを大きくするヒントがわかればと思います。

画面は私のブログに書いておきました。
https://ktamsan-restore2.blog.jp/archives/8467718.html

[5878] Re^2: 続・N88-BASICのRENUMのようなマクロ

めざら 2025/05/26(Mon) 16:09
[関連記事] [5877]へのコメント
http://mezala.la.coocan.jp/
> が、実は変数 h って、他でも使っていたんですね。

あーらら。よくコードを見ていなくて申し訳ないです。
よろしくない書き方で,としき兄の睡眠時間を削ってしまったのか。
本当にすみません。
○○の代わりに,なんて書かなきゃよかったですね。


ログの破損の方は,だいたい直しました。
またヌルの混入など変な症状がでなければよいですが……。
ネットワークのせいみたいなので,原因は分からず。
なにしろ,ふたつのアーティクルが接続しちゃってたりすることもあったので,単にヌル混入よりひどい。ヌルなら検索すれば見つかりますからね。混入っていうか,通常の文字がヌルに置き換わってバイト数は変わらないとか,紛らわしいことこの上ない。○-com のせいかなぁ……

[5877] Re: 続・N88-BASICのRENUMのようなマクロ

としき 2025/05/26(Mon) 02:00
[関連記事] [5876]へのコメント
http://toshiki.la.coocan.jp/
うあ、こんな時間。
朝になったら普通に出社しなくてはならないのに。
時間を忘れてマクロをトレースしていました。
結果。

> そして、ver.0.22bとして、マークジャンプを使用
> が、これがなぜかうまく動かない。

原因がわかりました。
単に私が素直すぎただけ、というか。
#5870でいただいたアドバイスですが

> h=ln, の代わりに &#M(1) を,&#J(h) の代わりに &#U(1) を使うだけ

このとおりのコードを書いてしまっていました。
が、実は変数 h って、他でも使っていたんですね。
つまり、設定していない変数を参照していたのでした。
何やってんだか。

これで何とか動くコードができたので、各バージョンに#5872で教えていただいた時間計測ルーチンを仕込んで測定してみたいと思います。

[5876] 続・N88-BASICのRENUMのようなマクロ

としき 2025/05/26(Mon) 00:41
[関連記事]
http://toshiki.la.coocan.jp/
巨大なツリーは全く問題とは思わない私ですが、錯綜したツリーはなぜか問題と感じるものですから、新しいツリーにします。というか、マトレス的な発言だから新しいツリーにした、というのが正解かも。
とりあえず、乱れたログは回復したようで、祝着至極。

さて、#5687では

> ver.0.21として、

> 終了時のメッセージを出すことと、
> > #55 " " &?("%d",o) #m"
> > ……これを少しだけまとめて……"
> > #55 &?(" %d",o) #m"
> この変更を加えてみました。

#55 だけではなく、#5866でめざらさんからアドバイスされていた #56 の変更も加えたものをver.0.21としました。

ついで、ver.0.22aとして、ファイル先頭にジャンプして末尾まで検索するロジックにした版を作りました。これは行番号ジャンプを使用しています。
これはなんとなく動いているようです。
そして、ver.0.22bとして、マークジャンプを使用して、旧番存在確認は従前のまま上下検索を実施する版を作ってみました。が、これがなぜかうまく動かない。トレースしてみたところ、なんかおかしい。#56 の置換文字列の入力部分で&?("\1FTHEN\2%d\3",n)とかやっているのですが、ここの「%d\3」の部分が数字の連続になってしまった結果、解釈がこけている、というような感じ。ただ、これ、ver.0.21もver.0.22aも同じルーチンなんですよ。ローカル10番にテキストの比較をかましても、3つとも同じ。にもかかわらず、マークジャンプ版だけ正常に動作しない。なので、実は違うところでバグっているはず。

ちょっと頭を冷やして、もう一度トレースを追いかけてみます。
きっとどこか、私が見落としているところがあるのでしょう。
特に、マークジャンプの部分で。

[5875] Re^2: 種蒔・栽培 2025 (トマト)

めざら 2025/05/25(Sun) 13:52
[関連記事] [5838]へのコメント
http://mezala.la.coocan.jp/
苗の定植から1ヶ月経過。
かなり小さかった千果も他の苗と遜色ない大きさに育ってきました。
まだ脇芽を一度も摘んでいないので,いずれも脇芽伸び放題となり,一部は地面を這うような状態となっているところまで放置してしまいました。

これはマズい……ということで,雨除け用のビニールシートを張るためのアーチ状の支柱を立て,長い塩ビパイプを渡して結わえ付け,ビニール紐で主枝と伸びた脇芽を吊りました。

吊っておくと,際限なく上に伸びても,紐をゆるめることでさらに伸ばすことが可能になる……というわけなのですが,毎年その頃にはモサモサに枝がからみ合ってしまい,紐をゆるめようが丈を低くできません。暑いうちから日常的に管理しないといけないわけだなぁ……自分にできそうもないです。

肝腎の実のほうは,まだ蒼いのが少しついているだけです。
ちょっと放置しすぎて脇芽に栄養を取られているのでしょう。そろそろ脇芽かきを始めないといけない。

[5874] Re^2: 種蒔・栽培 2025 (胡瓜)

めざら 2025/05/24(Sat) 16:55
[関連記事] [5841]へのコメント
http://mezala.la.coocan.jp/
種蒔きから一ヶ月もかかって本葉がいくつか出たので,8本中6本を定植しました。

……と思ったら,残しておいた苗の双葉を瓜葉虫が食っていました。

五月にして瓜葉虫が成虫になっているとは驚きです。即刻捕殺。
定植したものは網掛けをしていますが,500mlのヨーグルト容器を利用して作成したもののため,既に窮屈そうです。早々に大きなサイズの防虫網籠を準備しないといけないでしょう。いっそ紋白蝶防除用の大きなネットで覆ってしまおうかとも考えますが,胡瓜はすぐに伸びてくるので,そういつまでも誘引ネットを張らないわけにもいかない。悩みどころです。

種蒔きから定植までひと月かかるとなると,もう次の種を蒔かないといけないかもしれない。作物を育てるのもなかなか大変です。

[5873] Re: 種蒔・栽培 2025 (オクラ)

めざら 2025/05/24(Sat) 16:38
[関連記事] [5725]へのコメント
http://mezala.la.coocan.jp/
ひどく乱れてしまっているツリーなので,恐る恐るぶら下げます。

昨年ダイソーで購入したオクラの種が残っていたので,今ごろ蒔きました。

一昨年オクラを作っていた場所なので,根瘤線虫とか残っていると生育がよろしくないかもしれませんが,他に適当な場所がありません。

オクラは以前,水に浸けて芽出ししたのに全滅したことがあったので,今回は芽出ししませんでした。まぁ,今夜から降るらしいのでよいでしょう。

それにしても,今年はいろいろ意欲がわきません。今年と言うか,先の冬から全然ダメダメの状態なわけで,なるべく朝夕の決まった時間帯は平日でも野良仕事しないと草ボーボーになってしまう……

[5872] Re^23: N88-BASICのRENUMのようなマクロ

めざら 2025/05/24(Sat) 16:21
[関連記事] [5871]へのコメント
http://mezala.la.coocan.jp/
スマホのストップウォッチで計測って話なのは,いくら何でもと思ったので,
簡易計測用の部品です。

単にファンクションコールで得た現在時刻を秒で表現した値の差し引きなので,
日付をまたげば狂いますし,ロング整数も使っていないのでオフセット値。

それでも,目→脳→指→タッチ画面という伝達よりは確かな気がします。
短時間アバウト計測用と割り切ってください。

= t
*m
1 ^^ ""
        ?.
        &20
;       i-,
;       (10){ &w(100) &m("%5u",i++) }
        b[, &20 b=b-0],
        &m("%5u sec(s)",b)

20:     ;; 時刻の数値化(秒計)
        ax=$2C00, &i($21) b=cx>>8*3600+cx&$ff*60+dx>>8,
*

[5871] Re^22: N88-BASICのRENUMのようなマクロ

としき 2025/05/21(Wed) 00:53
[関連記事] [5870]へのコメント
http://toshiki.la.coocan.jp/
> 90%の出来を92%にする程度

確かにそうかもしれない。
でも、8ビット時代のBASICのマシン、プログラムのサイズは16KBだの32KBだの64KBといった制限はあれど、論理行数は60000行以上を許されていたわけです。そして、クロック速度は例えば1MHzとか4MHzのマシンで10000行ぐらいあるプログラムの行番号の付け替えが、アセンブラで書かれているとはいえ、ほとんど数秒とかからずに終わるのですよ。そういう経験があると、いくらエミュレータ上とはいえ、たかだか200行そこそこで10秒以上かかるといわれると、やっぱりもうちょっとがんばりたい気分にはなる。

> > 実行時のコストが一番高いのは何かというと、比較ならびに条件分岐
> そんな常識がかつて存在したのですね。

たぶん、1960年代とか1970年代のころの話だと思う。
80年代のBASICでは既に伝説でしたけど、if then elseをいくつも重ねるよりはVzマクロで言うところの多重分岐のようなコードのほうが速い、みたいな事は言われていましたね。

> 1行ごとにローカル10番で12回の全置換を試みるコストの方が気になります。

同感です。こちらも何とか改善できる方法が思いつければいいんですけど。

マークジャンプについては、書き方を教えていただきありがとうございます。
こちらは、書き換えたバージョンを使って、所要時間の測定までやってみたいと思います。あと、検索2回ではなくジャンプ+検索1回のコードでも測定してみたいかな。

[5870] Re^21: N88-BASICのRENUMのようなマクロ

めざら 2025/05/20(Tue) 07:42
[関連記事] [5869]へのコメント
http://mezala.la.coocan.jp/
実行速度を気にされているように思った結果にひねり出した提案だったのですが,既に速度は十分に出ていると思います。90%の出来を92%にする程度のことにこだわるかどうかというところでしょうか。

> 実行時のコストが一番高いのは何かというと、比較ならびに条件分岐

そんな常識がかつて存在したのですね。スクリーン書換えのコストが高いことは理解できますが,比較や条件分岐ってプログラムの基本ですよね。初耳。

思うに……。
1行ごとにローカル10番で12回の全置換を試みるコストの方が気になります。


> マークジャンプのコードを書くのが面倒、な気がする。

これは,h=ln, の代わりに &#M(1) を,&#J(h) の代わりに &#U(1) を使うだけですから,ステップ数は変わりません。引数は 1から4まで使えます。#M で得た4バイトの値を保存・復帰するより,それ用に備わっているバッファを利用するのがむしろ常識的という気がします。

[5869] Re^20: N88-BASICのRENUMのようなマクロ

としき 2025/05/19(Mon) 23:24
[関連記事] [5868]へのコメント
http://toshiki.la.coocan.jp/
> で,多分……なんですけど,もう少し速くなりそうな気がします。

こういうアイディアは大歓迎。
ただ、そのアイディアを形にすることが、はたして私にできるかどうか。

> 後方検索で存在が確認できたら,もう前方検索する必要はない

確かにそうです。が、後方検索で存在が確認できたら、という条件分岐を入れるのが面倒だったのです。
もちろん、ファイルのサイズが大きくなればなるほど、ファイル全体を検索する挙動が少ないほうが良い、というのは理解できています。が、古いコンピュータ屋さんにとって、プログラム実行時のコストが一番高いのは何かというと、比較ならびに条件分岐というのが当時の常識。だから、論理演算を駆使したり、今回の私のコードのように算術演算を何回もする代わりに比較は1回だけ、みたいなコードを書いてしまうわけですよ。実際には内部で検索時の比較演算が何回も行われているわけで、見えている表面だけ気にしたって仕方がない、ということは自覚しているんですけどねぇ。これはもう、おつむの古い人の代表的なコードと言ってしまってもいいかも。
う〜ん、ファイル先頭にジャンプしてから下に向かって検索、みたいなコードでも測定してみるかなぁ。

> もうひとつは,行番号ジャンプとマークジャンプでどちらが速いのか。

やっぱり、ここでマークジャンプの話が出てきますか。
これも測ってみたいところではあるのですけどね。
マークジャンプのコードを書くのが面倒、な気がする。
う〜ん、どうしようかな。

[5868] Re^19: N88-BASICのRENUMのようなマクロ

めざら 2025/05/19(Mon) 17:43
[関連記事] [5867]へのコメント
http://mezala.la.coocan.jp/
ログの修復については,過去ログに移ったツリーの中に4個所もヌルの混入等が見られたアーティクルがあったので,これをバックアップから書き戻しました。今のところ,その部分は大丈夫らしいことが確認できたので,そろそろ本腰を入れて直そうかと思います。実行時間帯は早朝かな。


> 990 10 15s 2m58s 25s 11s
> 10000 10 17s 3m12s 25s 10s

おお! これは素晴らしい成果ですね。新板はかなり速い。

で,多分……なんですけど,もう少し速くなりそうな気がします。

現行では,処理行番号の存在を確認するのに,必ず後方・前方の二度検索をしていますよね。
> #55 " " &?("%d",o) #m #r c+=r, #c c+=r, ;旧番存在確認

これ,まず実行する後方検索で存在が確認できたら,もう前方検索する必要はないですよね。
なんなら,一旦ファイルの先頭(または末尾)に移動しておいて前方(または後方)検索をすれば,検索は一度で済むかと思います。(1回目でマッチしたら,という条件分岐も面倒)

検索って,1バイトずつ文字列をなめてゆくわけだから,それなりに時間がかかる処理だと思いますが,ジャンプなら〈探す〉わけではないから速そうに思います。特に探している1文字目がそこらじゅうにある空白だし,2文字目も同じキャラクタである可能性がけっこう高いじゃないですか。それこそ「ふんどしの川流れ」的な状況かと。(まぁ,探している番号が存在しない場合は,結局,テキストを全部なめてしまうわけですけどね)

もうひとつは,行番号ジャンプとマークジャンプでどちらが速いのか。
どちらも検索ではないので,「つっかえつっかえ」はない訳ですが,VZ君はどのように行やマークを探しているのか。なかなか興味深いです。

[5867] Re^18: N88-BASICのRENUMのようなマクロ

としき 2025/05/19(Mon) 01:47
[関連記事] [5866]へのコメント
http://toshiki.la.coocan.jp/
例えば、過去ログについては現行ログからプッシュアウトされる追記しか存在
しないわけですよね。なので、こちらのほう、正規化というか不要なヌルを削除
して再アップするという対応はしてもいいかも。そして、もしそれだけのことで
ログ崩壊が発生するなら、それはもう、回線被疑確定。
そして、もしスクリプトとかではなく回線が悪いのなら、私が#5823で書いたのと
似たような対応がベターかな。すなわち、正当な内容の同一のログを、ファイル
名を変えて5つとかアップロード。そして、それらをサーバ上の名前のままで
ダウンロード。ローカルで原本と比較し、差異がないファイルを新ログとして
現行ログのファイル名にリネーム。
サーバ上でdiffとかできるスクリプトが書ければもっと楽できそうな気もする
けど、そんなスクリプトを書くよりはアップダウンを繰り返してローカルで
比較、というほうがおそらく簡単。

それはさておき。

> これは,例えば 1020 とか 1040 とかのときは遅くならないのですか?

のちほど試して見ましょう。
ん〜、会社からスマホを借り出してくるか。
いや、元々持ち出しようということになっていて、次の木曜日にも諸般の都合で
自宅に持ち帰る予定があったりするのですよ。ただ、他の皆さんと違って私は
個人携帯がガラケーなんで、家に持ってきても充電に問題が発生するので、特段
の用がなければなるべく持って帰らないようにしている。

とりあえず、ver.0.21として、ストップウォッチ計測が少しは楽にできるよう
に、終了時のメッセージを出すことと、

> #55 " " &?("%d",o) #m
> ……これを少しだけまとめて……
> #55 &?(" %d",o) #m

この変更を加えてみました。

で、例によって絨毯爆撃。

開始         としき としき  としき  としき
番号 増分 めざら版 旧版  0.20&s有 0.20&s無 0.21版&s有無
    1    1
    1   10
  990   10       15s  2m58s       25s     11s
 1010   10
 1020   10
 1030   10       15s  3m30s       38s     17s
10000   10       17s  3m12s       25s     10s

とりあえず、上記は暫定結果ということで。
ただ、時間がかかりすぎるので、たぶん、としき旧版はもうやらない。
 

[5866] Re^17: N88-BASICのRENUMのようなマクロ

めざら 2025/05/18(Sun) 09:40
[関連記事] [5865]へのコメント
http://mezala.la.coocan.jp/
ご心配くださり,ありがとうございます。
つい一週間ほど前に過去ログに移ったスレッドがありますが,すでにヌルの混入が見られました。混入部分は本文のため,致命的なものではないようなのですが,なにしろ原因不明かつパターン不明なので手が付けられない。

さて,高速化のこと祝着至極に存じます。そこで確認したいことがあり。

> なぜか1030から始まる変換だけ遅い。

これは,例えば 1020 とか 1040 とかのときは遅くならないのですか?

> 重複した番号が発生したときに著しく遅くなる、とかありそう。

重複というのは,同じ飛び先の指定が複数箇所にあるということでしょうか?
(まぁ,そういうのはよくありますよね)


あと,試してみていただきたいことがあり。
単にステップ数の問題なので,大して変わらないかもしれませんが,例えば……
#55 " " &?("%d",o) #m
……これを少しだけまとめて……
#55 &?(" %d",o) #m
……のようにすると,速度はどうなるか。

ローカル10番の置換の方が数が多い分だけ変化があるかもしれませんけど。

#56 &?("\([ \t]+\)THEN\([ \t]+\)%d$$",o) #m &?("\1FTHEN\2%d",n) #m "ay"
#56 &?("\([ \t]+\)THEN\([ \t]+\)%d\([^0-9]\)",o) #m &?("\1FTHEN\2%d\3",n) #m "ay"

……みたいな。
まぁ,文字列は1文字1ステップみたいだから,さほど変わらないかな……

↑ このページの先頭