ときどきの雑記帖 RE* (新南口)
Flowers for Algernon
マジンガーZ
MXでの今週の放送では、 両手にミサイルを持って マジンガーZが空を飛んだ回 だったのだけど
- BGM でクラシックやゴジラの劇伴(?)が使われていた
- バリヤー展開→破壊(例のガラスの割れるような演出ではなかった)
- マジンガーZが、NARUTOや聖闘士がやるような例の走り方で激走
等々インパクトのある回だった。
合体魔道王Ωアビゲイル一世
こんなのが(ちょっと欲しい😄)
合体魔道王Ωアビゲール一世 Tシャツ [アニメ「BASTARD!!-暗黒の破壊神-」] | キャラクターグッズ&アパレル製作販売のコスパ|COSPA | COSPA,inc.
Xライダー
久しぶりに。 んが、緊急地震速報が入ったりいろいろ。
某コンビニのサンドイッチ
とあるわりとお気に入りのサンドイッチがあるのだけど、 御多分に漏れず順調に値上げが続いていた。
しかしちょっと前に値下げされ、 「これは今どき珍しい」 と思ったがなんか小さくなってる?
タマゴサンドも結構高くなってますねえ…
自転車と信号
前回信号(と自動車の運転)の話を書いたけど、 自転車も大概だよねえ。 むしろこっちの方がひどい?
自転車は「『車両でも歩行者でもない』のでどちらの信号も守る必要はない」 とでも考えているような手合いが多い気がする (実際には「軽車両」ではあるのだけど)。
あと、「(目的地に着いた以外で)止まったら死んじゃう病」 に罹患しているのも多いすな>自転車乗り
chatgpt
Newtonでも特集されたなあ。
と思ったら単行本もすでに結構出ていてびっくりだよ。
powerquery
特に指定しないでも
20230101
のような8桁の数字列を日付を表すものと解釈してくれたり
012345
のような6桁の数字列を時刻を表すものと解釈してくれた
Excelさんも、
20230101012345
のような14桁の数字列を日付+時刻を表すものとは
解釈してくれず。
いろいろ試してみたけど
DateTime.FromText(
Text.Conbine(
{Text.Start([xxx], 8), Text.End([xxx], 6)},
"T"))
これで変換するのが一番お手軽?
FW14B
自分があげるならアレかアレかな と思ったものでワンツーで苦笑い(なぜ)
恐ろしいほど強かった……日本のファンが選ぶ「最強F1マシン」
←↑→
割と近く(と言いつつ歩いていくと結構ある)にこの種の信号があって、 なぜ青信号にせずこんな表示にしているのだろうかと 気になっていたのだけど(と言いつつ調べたりはしなかった)、 なるほどねえ、
もうすぐ青信号と思ったら「赤で“←↑→”」だった ナゼ? ちょっとしたら青に | 乗りものニュース
新刊近刊
パラダイム
新訳が出るらしい
待望の日本語版新版(原著第IV版、50周年記念版の全訳)。
出版社: みすず書房 (2023/6/13)
旧版(というか現行?)は大学のとある講義で読まされてレポート書いたなあ。 まあ「パラダイム」という単語を使うなら一読はしてもらいたいものだけど (偉そう)。
新しい訳で出ないかと思う。 読みづらい。
色々な所で紹介や、引用されているため、既に既視感のある本。出た当時は衝撃的だったのだろう。
デタラメに引用したり、強引に自説の裏付けとして使う輩(ビジネス書の著者に多い)が多いため、騙されない為にも、一度読んでおいても損はない。
新訳されて良かったすね(って新訳がどんなものかまだ分からないけど みすず書房なら大丈夫なのでは…)
メモ
Cをどうこうしようというアイデアが色々出されていますが さらにまたもうひとつ。
RFC: Enforcing Bounds Safety in C (-fbounds-safety) | Hacker News
C99 also lets you do this:
void foo(size_t elem_count, int elems[elem_count]);
Unfortunately this constraints the argument order. C23 fixes that with something like this:
void foo(size_t elem_count; int elems[elem_count], elem_count);
(Might be slightly wrong, going from memory.)
この種の引数の順番がどうこうという話を 以前tnozakiさんが書いていたと思うのだけど サイトがなくなってしまったので確かめられん
CSV
GoAWK(Goで書かれたawk)でもcsvサポートが入るという話があり、その中で
Add support for –csv (which Gawk and onetrueawk are adding) · Issue #181 · benhoyt/goawk
Gawk and BWK’s onetrueawk are adding a –csv option (for the second edition of The AWK Programming Language), which I believe is equivalent to GoAWK’s -i csv. We should confirm that and then add support for this argument to GoAWK for compatibility. Arnold said:
In particular:
- Quoted fields are handled
- Including embedded CR-LF or CR or LF
- The record can be terminated by CR-LF or just LF
- In all cases, CR-LF becomes just LF by the time gawk sees the data
とOne true awkにも追加される(た?)ということが書いてあり そんな話あったっけかと onetrueawk/awk: One true awk を見てもそれっぽいものが見当たらなかったのだけど 別ブランチ onetrueawk/awk at csv で進んでいるようだ。 Unicode対応も別ブランチだったけど いつ頃マージされるんだろう。
grep
例の-P
オプションがらみ(と思われるもの)のコミットを追いかけてみた
grep.git - grep
pcre: work around a PCRE2_MATCH_INVALID_UTF bug
2023-04-20 18:37:20 -0700
PCRE2 has a bug when using PCRE2_MATCH_INVALID_UTF: it would sometimes fail to match patterns using negative classes like \W and \D. * NEWS (Bug fixes): Mention it. * src/pcre2search.c: Restrict impact of the bug. Do not use the problematic flag with broken versions of PCRE2. Also, generate locale tables only for single-byte locales, as the PCRE2 documentation recommends this. * tests/Makefile.am (TESTS): Add the file name * tests/pcre-utf8-bug224: New file, to test for this.
2023-04-29 23:41:14 -0700
This follows up to Carlo Marcelo Arenas Belón’s email https://lists.gnu.org/r/grep-devel/2023-04/msg00017.html that proposed changing the code too. These patches change only the documentation since we’re so near a release. * NEWS: Be less optimistic about the fix for -P '\d', and warn that behavior is likely to change again. * doc/grep.texi (grep Programs): Be less specific about -P \d behavior, since it’s still in flux. Warn about mismatching Unicode versions, or disagreements about obscure constructs.
build: support explicit ‘PCRE_CFLAGS= PCRE_LIBS=’
2023-04-29 18:30:47 -0700
* m4/pcre.m4 (gl_FUNC_PCRE): Check whether PCRE_CFLAGS and PCRE_LIBS are set, not whether they are set to a nonempty value.
doc: note when a bug was introduced
2023-04-20 18:50:37 -0700
* NEWS: say that the \d bug was introduced in 3.10.
grep: make -P survive JIT compilation failure
2023-04-11 15:10:06 -0700
* src/pcresearch.c (Pcompile): Ignore failure returns from pcre2_jit_compile.
grep: improve PCRE2 version output
2023-04-10 11:31:58 -0700
* src/grep.c: No need to include pcre2.h. (main) [HAVE_LIBPCRE]: Call Pprint_version instead of doing it ourselves. * src/pcresearch.c (Pprint_version): New function. It also checks belatedly for buffer overflow, and says "grep -P uses PCRE2" instead of "Built with PCRE". * tests/version-pcre: Adjust test to match.
grep: fix -P [\d] by fixing \w only if PCRE2 10.43
2023-04-01 13:55:26 -0700
Our prepass-based fixes for the -P \d bug have caused repeated further bugs. Avoid the need for a prepass, by using PCRE2_UCP only if PCRE2_EXTRA_ASCII_BSD is also supported. Since the -P \w bug was present from grep 2.5 through 3.8 it’s OK if we wait a little longer to fix it. * NEWS: Mention this. * src/pcresearch.c (pcre_pattern_expand_backslash_d}: Remove. Remove its use. (Pcompile): Use PCRE2_UCP only if PCRE2_EXTRA_ASCII_BSD. * tests/pcre-ascii-digits, tests/pcre-utf8-w: Skip tests on older PCRE2 implementations.
doc: clarify BRE vs ERE (bug#62272)
2023-03-20 00:20:05 -0700
doc: clarify BRE vs ERE (bug#62272)
grep: -P (–perl-regexp) \D once again works like [^0-9]
2023-03-18 23:25:03 -0700
* NEWS: Mention \D, too. * doc/grep.texi: Likewise * src/pcresearch.c (pcre_pattern_expand_backslash_d): Handle \D. Also, ifdef-out this new function and its call site when not needed. * tests/pcre-ascii-digits: Test \D, too. Tighten one test by using returns_ 1. Add comments and tests that work only with 10.43 and newer. Paul Eggert raised the issue of \D in https://bugs.gnu.org/62267#8
grep: forward port to PCRE2 10.43
2023-03-19 01:50:00 -0700
* doc/grep.texi: Document this. * src/grep.c: Move recent changes into pcresearch.c. (P_MATCHER_INDEX): Remove. (pcre_pattern_expand_backslash_d): Move from here ... * src/pcresearch.c: ... to here. (PCRE2_EXTRA_ASCII_BSD): Default to 0. (Pcompile): Use PCRE2_EXTRA_ASCII_BSD if available, and expand \d to [0-9] otherwise.
doc: distinguish Perl from PCRE
2023-03-19 01:45:53 -0700
* doc/grep.texi: Mention that PCRE might not match Perl exactly.
grep: -P (–perl-regexp) \d: match only ASCII digits
2023-03-18 08:28:36 -0700
Prior to grep-3.9, the PCRE matcher had always treated \d just like [0-9]. grep-3.9's fix for \w and \b mistakenly relaxed \d to also match multibyte digits. * src/grep.c (P_MATCHER_INDEX): Define enum. (pcre_pattern_expand_backslash_d): New function. (main): Call it for -P. * NEWS (Bug fixes): Mention it. * doc/grep.texi: Document it: with -P, \d matches only ASCII digits. Provide a PCRE documentation URL and an example of how to use (?s) with -z. * tests/pcre-ascii-digits: New test. * tests/Makefile.am (TESTS): Add that file name. Reported as https://bugs.gnu.org/62267
grep: diagnose no UTF-8 support (Bug#60708)
2023-01-12 19:35:08 -0800
* src/pcresearch.c (Pcompile): Issue a diagnostic and exit instead of misbehaving if libpcre2 does not support the requested locale.
pcre: use UTF only when available in the library
2023-01-06 20:40:07 -0800
Before this change, if linked with a PCRE library without unicode any invocations of grep when using a UTF locale will error with: grep: this version of PCRE2 does not have Unicode support * src/pcresearch.c: Check whether Unicode was compiled in. * tests/pcre-utf8-w: Add check to skip test. * tests/pcre-utf8: Update check.
2023-01-06 19:34:56 -0800
This fixes a serious bug affecting word-boundary and word-constituent regular expressions when the desired match involves non-ASCII UTF8 characters. * src/pcresearch.c: Set PCRE2_UCP together with PCRE2_UTF * tests/pcre-utf8-w: New file. * tests/Makefile.am (TESTS): Add it. * NEWS (Bug fixes): Mention this. * THANKS.in: Add Gro-Tsen and Karl Petterson. Reported by Gro-Tsen https://twitter.com/gro_tsen/status/1610972356972875777 via Karl Pettersson in https://github.com/PCRE2Project/pcre2/issues/185 This bug was present from grep-2.5, when --perl-regexp (-P) support was added.
MID$ statement
ところで BASIC言語、MID$(ステートメント)実行結果一覧 2023.4.16 のリストの中で
11234
となるものをみると
FM-7/FM77 F-BASIC V3.0 FM-11AD2/AD2+ F-BASIC V5.0 FM-11ST/AD/EX F-BASIC V4.0 FM-8 F-BASIC V1.0 FM-8 F-BASIC V2 FM-TOWNS F-BASIC386 BASIC MASTER LEVEL 3 LEVEL-3 BASIC V1.0 MB-S1 S1 BASIC V1.0 Windows 2022 Visual Basic 2022 PC-88VA N88-日本語BASIC v3.1 MZ-2500 BASIC-M25 (6Z002) V2.0B MZ-2800 BASIC-M28 (6Z016) V1.0A
を改めて見てみると
88VAのBASICも11234
組(ってなんですか)だったのに気がついた。
名前もN88~となっている以上、 NEC側で勝手に(?)変えたものとも考えづらいけど 実際のところはどうなんだろうか。 と思ったので調べてみると
PC-88VA用
PC-88VAシリーズには、専用に新規開発された「N88-日本語BASIC V3」が標準添付された。V2までのN88-BASICに対し、 ある程度の上位互換性を保っているが、完全上位互換ではない。ROM-BASICは無く、PC-Engineと呼ばれる独自OSから起動して使うもので、 その意味ではスタンドアロンBASICでもない。機能的にもN88-BASICよりは、むしろN88-日本語BASIC(86)に近い。 V3モードのCRTCは2バイト文字テキストに対応しているため、PC-88VA用のBASICとして広く使われるようになった。
ふむ。 そして同じページの98用に関する部分を見ると N88-BASIC - Wikipedia
PC-9800シリーズ用
N88-BASIC(86)は、1982年(昭和57年)から発売されたPC-9800シリーズのROM-BASICで、PC-8800シリーズのN88-BASICと、 高いレベルで互換性がある。名称の(86)は、採用したx86系プロセッサに由来する。 8ビット機時代のN-BASICとN88-BASICはNECとマイクロソフトの共同開発であったが、N88-BASIC(86)はNECのみによる独自開発である。
当初NECはマイクロソフトに開発を打診したが、8ビット機時代の「方言」の氾濫に手を焼き標準化を画策していたマイクロソフトは、 同社が16ビット機用の決定版として開発したGW-BASICの採用を強く働きかけてきた。しかし、 GW-BASICはIBM PC互換アーキテクチャを前提としている上、ラベルすら使えない旧態依然としたBASICであったため、 N88-BASICで蓄積された膨大なソフトウェア資産を継承することは困難であり、 NECはBASICを自社開発することによって独自路線を堅持する道を選択した。開発にあたってNECは、 互換性を高めるためにN88-BASICのリバースエンジニアリングを行っている。当然ながら、 完成したBASICにはN88-BASICと限りなく似た部分が存在し、マイクロソフトと衝突する可能性もあったわけであるが、 最終的にはマイクロソフトから相当額の別の製品を購入することと、著作権の表示にマイクロソフトとNECの両社名を併記することで折り合った[1]。
なんだってー>N88-BASIC(86)はNECのみによる独自開発である
そして[1]のリンクから
互換ベーシックの著作権侵害を問うべきか? - パソコン創世記
9月、著作権侵害に対する疑念を水面下で充分にぶつけてから、西は浜田に提案を持ちかけた。
今後情報処理事業グループは、互換ベーシックのライセンス料に相当する金額のマイクロソフト製品を、別個に購入する。 著作権の表示には、マイクロソフトと日本電気の両社名を併記する。この条件を受け入れる限り、 マイクロソフトは今回の互換ベーシックに関して著作権の侵害を問わない。
浜田はこの提案を受け入れた。
など、うぃきぺの記述のもとになったであろう文章がまとまってではないけれども見つかった。
まあNECの独自開発であったとしても、従来のものとの互換性を保つことが最優先であったとすれば MID$ Statementの動作も(意図的であったにしろなかったにしろ)同じなのは納得できる。 が、じゃあVAで変わっているのはなぜ? という疑問は残る。
それはさておき、パソコン創世記を読むと色々興味深い部分がある (今回実際に読んだのはごく一部だけど)。
日本電気のPC-8001以降、マイクロソフトのベーシックにいっせいになびきながら各社がつぎつぎと新型機を発表してしのぎを削った日本市場では、 特にはなばなしい機能拡張競争が繰り広げられた。グラフィックス関連に力を入れたPC-8001に続いて、日立のベーシックマスター版、 解像度を大幅に高めた日本電気のPC-8801版と機能拡張が続き、ビル・ゲイツ自身がハードウエアのスペックに惚れ込んで拡張に入れあげた 沖電気のif800では、ついにベーシックの規模は56Kバイトにまで膨れ上がるにいたった★。
★1964年にアメリカのダートマス大学でジョン・ケメニーとトーマス・カーツによって大型コンピュータのタイム・シェアリング・システム用の 会話型言語として書かれたとき、ベーシックの規模はごく小さかった。ダートマス版の第1版では、マシンに直接動作を指示するコマンドが3語、 プログラムの中で使われるステートメントが14語、関数が10語の計27語を数えるのみだった。それがPC-8001では143語、PC-8801では249語にまで膨らんでいた。
1982年3月号から、『ASCII』に「パーソナルコンピュータのBASIC徹底比較」と題する短期の連載を持った土井政則 (当時、宇部工業高等専門学校電気工業科助教授)は代表的なマシンを総当たりして、ベーシックの機能拡大の歩みをじつに丹念に跡付けている。 土井のレポートによれば、PETで64語まで膨らんでいたベーシックは、当時の最新機種である日本電気のPC-8801では、249語を数えるにいたっていた。
日本語BASIC漢字BASIC
BASIC言語、MID$(ステートメント)実行結果一覧 2023.4.16 でNECのものをみていると
PC-9801 | 1983 | NEC / Microsoft | N-88 BASIC(86) | v4.1 | 11111 |
PC-8801MA2 | 1988 | Microsoft/日本電気株式会社 | N88-日本語BASIC MA2 | V2.2 | 11111 |
PC-9801 | 1994 | NEC / Microsoft | N-88 BASIC(86) | v6.2 | 11111 |
PC-8801 | N88-漢字BASIC | V1.1 | 11111 | ||
PC-88VA | N88-日本語BASIC | v3.1 | 11234 |
「N88-日本語BASIC」と「N88-漢字BASIC」と似たような名前のものがある。 これって違うものなのかと思ったがジッサイ別物っぽい。
V1およびV2対応の日本語拡張として、NECからN88-漢字BASICとN88-日本語BASICが、システムソフトから8801漢字BASICと新8801漢字BASICが発売された。 それぞれの間では2バイト文字の内部表現形式が異なっており、変換にはコンバータを必要とした。 これらはいずれも命令は通常のBASICコマンドで、日本語を文字列として扱えるようにしたものである。 なお、N88-日本語BASICはPC-8801mkIIFR/MR以降の機種に標準添付されたが、 PC-8800シリーズのCRTコントローラはテキストVRAM上の2バイト文字に対応しておらず、 従ってグラフィックVRAMにビットマップグラフィックとして文字を描画することになるため、 動作が遅くプログラムを組む上ではあまり使われなかった。
あー、なんかかすかに記憶が>グラフィックVRAMにビットマップグラフィックとして文字を描画
Microsoft BASIC variants
Microsoftが8bit時代にメーカーに提供した(売りつけた) BASICってどのくらいあるのだろうか と気になっているのだけど、 そのものではないものの うぃきぺの Altair BASIC - Wikipedia などのページの最後の方にBASICのvariantのリストがあって、 その中のMicrosoftをみるとこんな感じだった。
Microsoft
- Altair BASIC
- Applesoft BASIC
- Atari Microsoft BASIC
- Color BASIC
- Commodore BASIC
- Disk Extended Color BASIC
- Extended Color BASIC
- GW-BASIC
- IBM BASIC
- MBASIC
- Microsoft BASIC (MS BASIC for Macintosh)
- MSX BASIC
- TRS-80 BASICs (Level I, Level II/III)
- Thomson BASIC 1.0
FORTRAN Compiler on IBM 704
subscript
E+1にストアする値は以下の三つのいずれか。らしい。
ADPLUS OCT 200000000000 ADDITION SIGN -ARITHMETIC. 4F10389
ADSTAR OCT -140000000000 MULTIPLUCATION SIGN -ARITHMETIC. 4F10399
STRSTR OCT -145400000000 EXPONENTIATION SIGN -ARITHMETIC. 4F10400
ひょっとして+
、*
、**
の文字コードそのまま?
(-14は54と等価。のはず)
12Z OCT 20 + - CTEST-2 4F10317
STAR OCT 54 * - CTEST-1 4F10318
あと The Arithmetic Translator-Compiler of the IBM FORTRAN Automatic Coding System によると
2. definition (c) A subscript is a string of one of the following forms:
Σ K K*Σ Σ+K Σ-K K*Σ+P K*Σ-P
where K, P are integer constants and Σ is an integer variable. In addition, the magnitude of a subscript cannot exceed 2^15-1.
ということらしい。
これ、順番もこうでないといけないのだろうか
(つまり、3*I
やJ+1
とは書けるけど
I*3
や1+J
とは書けない)?
カッコが許されないのは解析が面倒になるからで、 除算が書けないのは整数除算がないから?
ざっとしか目を通していないけど 添え字指定の式の中で演算子が二度登場していないか チェックしているっぽい。
SS0018 SXD CHCTR,4 SUBSCRIPT MULTIPLIER. 4F11075
SBX CLS SBC6 TEST FOR 4F11076
TMI SBX1 PREVIOUS MULTIPLIER. 4F11077
TSX DIAG,4 * DOUBLE MULTIPLIER FOR SUBSCRIPT. 4F11078
SBX1 STO SBC6 RESET MULTIPLIER SWITCH. 4F11079
SBM SSM MINUS ADDEND. 4F11117
SBP CLM PLUS ADDEND. 4F11118
LXD SBS2,4 GET STORING TAG, AND 4F11119
STO E+15,4 STORE SIGN OF ADDEND. 4F11120
CLS SBC8 TEST SWITCH 4F11121
TMI SBP1 FOR PREVIOUS ADDEND. 4F11122
TSX DIAG,4 * DOUBLE ADDEND FOR SUBSCRIPT. 4F11123
SBP1 STO SBC8 RESET ADDEND SWITCH. 4F11124
rustization
fishのRust化もうC++の半分くらいの割合まで来ててすごい。
— yutkat (@yutkat) May 26, 2023
このペースだとあと1年後にはC++なくなってそうhttps://t.co/cMhpHpPcD6 pic.twitter.com/jKbjCpzgMM
へー、そんな作業をしていたのか。 あとでちょっと見てみよう。
mod 7
bash で指定範囲(例えば4 〜 10)の乱数を取得するには、以下の式で実現できる。
— IT勉強中 (@IT41408082) May 24, 2023
$ echo $((RANDOM % 7 + 4))
9
組み込み変数 RANDOM は 1 〜 32767 の範囲内の乱数を生成。RANDOM % 7 で 0 〜 6 の乱数を生成、それに 4 を足せば、4 〜 10 の乱数を生成することになる。
単純に剰余をとるだけだと 偶数と奇数が交互に出てくるような 「落とし穴」にはまったりしないか といういらん心配はさておき、 「余り」があるから 7つのそれぞれが出現する確率は 微妙に違うんじゃないか と思ったが
$ factor 32767
32767: 7 31 151
7で割り切れた😄
巨大な看板も付きました。
— 上野の森美術館 (@UenoMoriMuseum) May 25, 2023
いよいよ作品が到着。展示作業が始まります。
「特別展 #恐竜図鑑 失われた世界の想像/創造」2023年5月31日(水)~7月22日(土) pic.twitter.com/v81G8ZUz5I
行きたいな、これ。
実は昔とは変わっている教科書の内容や表記をまとめました。詳しくは...… pic.twitter.com/T68eElDCB5
— けんたろ (@kenlife202010) May 25, 2023
知っているものも結構あったけど 知らなかったものもあるなあ。