2023年7月15日、リポジトリ
GitHub - fu-sen/IchigoJam-BASIC: 🍓🅱️ IchigoJam BASIC コマンド一覧 command reference (Japanese)
で見つけた問題点を Issues として投稿していたところ、いきなり事実に反する、または反する可能性が高いと考えられる主張を一方的に連投された上、あげくのはてに情報を破損させようとしている呼ばわりされた上反論を書き込めない不都合が発生するという事件が発生しました。
この事件の2日前、別の Issue を投稿したところ、「このとおりに反映いたしました」と称してほとんどが投稿の内容に合わない、かつ正しかった記述を誤りへと書き換える修正が行われたため、これをエビデンスとともに再指摘する Issue での出来事でした。
あれから5ヶ月、いまだに Issue の新規投稿や返信、さらに Pull Request のための fork すらもできない不都合が続いています。
しかも、前の Issue への反応として追加された誤りの一部は、今もそのまま残っています。
なるべく早く不都合の解消と誤りの修正がなされることを望みます。
事件に関係するページ
事件前の Issue
- FILE の説明が事実と異なる · Issue #3 · fu-sen/IchigoJam-BASIC · GitHub
- I2CR・I2CW の返り値の説明が無い · Issue #4 · fu-sen/IchigoJam-BASIC · GitHub
- 位置の計算式がおかしい · Issue #5 · fu-sen/IchigoJam-BASIC · GitHub
- UART typo? · Issue #6 · fu-sen/IchigoJam-BASIC · GitHub
どれも素直に修正していただけました。
#3 と #4 については、様々なバージョンで検証する、様々な資料を調査するなど、コストが高い検証も行っていただけたような記述があります。
さらに「ご報告ありがとうございます。」「報告ありがとうございます。」「ありがとうございます。」という感謝の言葉もあります。
誤りの追加がなされるきっかけとなった Issue
UART の記述が 1.4.1 の挙動と異なる · Issue #7 · fu-sen/IchigoJam-BASIC · GitHub
見直してみると、短文による現状の指摘とログが貼られているのみで、「どう直すべきか」が書かれていません。
これは、自分の至らなかった点であると考えます。
しかし、どう直すべきかがわからないのであれば聞いてくれればいいのであって、いきなり正しい部分を誤りに書き換えた上で、「このとおりに反映いたしました」という誤った主張をしていい理由にはならないと思います。
とはいえ、この時点では「細かく調査していただき、ありがとうございます。」とも書かれており、まだ Issue に対して好意的であるように感じました。
実際に誤りを追加したコミット
記載修正 (issue #7) · fu-sen/IchigoJam-BASIC@bf7a522 · GitHub
正しい「改行コード LF」という記述のほとんどが、「改行コード CR」という誤った記述に書き換えられています。
(なぜか送信モード 10 についてのみ、書き換えを免れています)
さらに、送信モード 4 について、「画面表示を行わない」という誤った記述が追加されています。
送信モード 4 では、PRINT した内容をUARTには出力しませんが、ビデオや液晶の画面には出力します。
この「画面表示を行わない」という表現は送信モード 8 でも使用されており、「画面」とは「シリアル送出」ではないもの、すなわちビデオや液晶の画面のことを指していると考えられます。
改行コードについてはその後修正していただけましたが、この誤りについてはいまだに修正していただけていません。
事件現場
UART の記述が 1.4.1 の動作と異なる · Issue #8 · fu-sen/IchigoJam-BASIC
UART 4 の実行後も液晶の画面に PRINT した内容が出力されること、および改行コードは CR ではなく LF が出力されることを、エビデンスとともに指摘しました。
すると、1日も経たない短時間のうちに一方的な主張が行われ、返信の書き込みができない不都合が発生しました。
しかも、Pull Request を要求しているかのような投稿もあるにもかかわらず、Pull Request のための fork もできない不都合も発生しています。
自分は指摘後一旦GitHubを離れ、次に戻ってきたときには既にこの状態でした。
あまりにも早い凶行に、激しい怒りを覚えました。
事件に対するお気持ち表明
Issueの対応が早くていい奴だと思っていたら裏切られた｜みけCAT
事件の発覚後から書き始め、翌日の昼頃に投稿した記事です。
事件の経緯、相手の主張の問題だと思う点、相手がかわりに取るべきだったと考えられる行動の案などを記載しています。
ただし、返信などができない不都合について「ブロックされた」と決めつけてしまっているのは、自分の反省点です。
事件の凶悪ポイント TOP3
ここでは、この事件で自分が特にひどいと思ったポイントを紹介します。
1位：エビデンスに基づく改善のための指摘をしているだけなのに、情報を破損させようとしている呼ばわりされた
相手はこんな主張をしてきました。
なお、このテキストは私が製作・公開していますが、長年様々な人が製作した仕様書や実際の検証により、ここまで積み上げられてきたものです。つまりは私のものではなく、IchigoJam にたずさわる皆さんの努力によってここまでの形になったものです。この情報を一個人によって異なるからと issues を建て破損させようとしている状況にあります。
私は、これに対し非常に憤りを感じました。
私は、実機を用いた検証をした上で、ログや画面写真といったエビデンスとともに指摘を投稿しました。
すなわち、自分も「皆さん」の一員として、規模は小さいかもしれないとはいえ「努力」をし、「積み上げ」に協力をしようとしただけなのです。
一方、相手は勝手に、自分の指摘に反して正しい記述を誤った記述に書き換えました。
ということは、破損させようとしているのはむしろ相手のほうです。
Issueを立てることで相手が勝手に作ったルールの引き金を引くきっかけになった可能性はありますが、そんなものは知りません。
にもかかわらず、自分のことを「一個人」というバカにしているとも捉えられる表現で指し、破損させようとしている呼ばわりしてくるというのは、非常に許しがたく思います。
侮辱にあたるのではないか、とすら思いました。
2位：事実に反するものを含む主張をいきなり一方的にされた上、反論が書き込めない不都合が発生した
指摘を書き込んでから次に自分が様子をチェックするまでという短い間に、事実に反するものを含む多くの書き込みがなされ、さらにそれらに対する自分の反論が書き込めなくなるという不都合が発生しました。
書き込みの中には Pull Request を求めているように見えるものもありましたが、残念ながら Pull Request のための fork もできなくなる不都合も発生しました。
かわりにnoteに反論を書きましたが、見ていただけるかはわかりません。
GitHubのサポートへの連絡もしましたが、どうやら効果は無かったようです。
相手の主張の中には「感じがします」「しっくりきます」といった主観的なものなど、正確な真偽はわからないものも多いですが、明確に事実に反し、かつ一方的で、非常に不快だった主張が1件ありました。
それがこれです。
モード4において、「画面表示を行わない」と書かれていますが、液晶 (SWITCH 1) を用いて確認したところ、PRINTした内容が画面に出力されました。
これについては UART とは関係なく、SWITCH の仕様なので、issues の対象外です。これは無視されます。
「これ」すなわち「モード4において、PRINTした内容が画面に出力される」ということが「UART とは関係なく、SWITCH の仕様」だという、直感的にもおかしく、かつ実験でも否定される、明確に事実に反する主張をしています。
さらに、この明確に事実に反する根拠をもとに、「これは無視されます」という一方的な主張をしています。
そもそも、無視されるのではなく、お前が自らの判断で無視するんですよね？
大変不愉快です。
3位：最初は Issue に誠実に対応していただけていたようだったのに、いきなり豹変された
このリポジトリは最終更新がだいぶ前だったので、最初に Issue を立てたときは立てても放置されるかなと思いました。
しかし、実際に Issue を立ててみると、素早く、しかも礼儀正しく丁寧な対応をしていただけました。
少なくとも、自分はそう感じました。
のちに一方的な主張をいきなりしてくるとは、本当に夢にも思いませんでした。
その後も数件 Issue を立て、いずれも同じように素晴らしいと感じる対応をしていただけました。
しかし、事件現場となる1個前の Issue では、これまでとはうってかわって、指摘内容に反して実験をすればすぐにわかるような嘘をリポジトリに書き込むという対応をされました。
これはおかしいことであり、ここで手を引くという選択肢もあったかもしれません。
しかし、「異変を見つけたら、すぐに引き返す」８番出口のリリースから4ヶ月以上も前であり、リポジトリに書き込まれた嘘を放置するのは良くないと思ったので、再指摘を行いました。
すると、今度は一旦は Pull Request を要求しているように見える投稿がなされたものの、すぐに手のひらを返し、「UARTのモード4においてPRINTした内容が画面に出力されるのはUARTとは関係なくSWITCHの仕様」というデタラメを含む主張が一方的になされ、Pull Request のための fork ができない不都合が発生しました。
今 IchigoJam に時間をさける状況ではない
また連続した issues により、私の活動時間を奪われており、悪影響を受けている状況でもあります。
という主張もなされていますが、時間が無いのであればIssue を無視すればいいだけでしょう。
無視はできないというこだわりがあるのであれば、素直に「時間が無いため対応できません」などと書いてクローズすればいいでしょう。
READMEなどで更新停止・更新頻度減を宣言したり、リポジトリをアーカイブしたりするという選択肢もあるでしょう。
いきなりこのような一方的な主張をまくしたて、(したと断定はできませんが) 一旦は Pull Request を要求するかのようなそぶりを見せながら即手のひらを返してブロックするという個人攻撃をしていい理由にはならないと考えます。
もちろん、レポジトリに嘘を書き込んでいい理由にもならないでしょう。
UART 4 の動作が SWITCH とは関係ないことを再検証
手元にある以下のバージョンにおいて、あらためて UART 4 の動作は SWITCH とは関係ないことを確認しました。
- 1.3.1 / IchigoJam S
- 1.4.1 / IchigoKamuy
- 1.4.3 / IchigoJam Q
- 1.5b / IchigoJam R
- 1.4.1D2 / IchigoDake
- 1.5.0D / GIGA IchigoDake
- 1.4.1 / IchigoCake
具体的には、以下のコマンド列を実行しました。
PRINT 1
UART 4
PRINT 2
UART 13
PRINT 3
SWITCH 1,22
PRINT 4
UART 4
PRINT 5
ここに含まれる PRINT コマンドは、それぞれ以下の条件で実行されます。
| UART 設定 | SWITCH 設定 | |
|---|---|---|
PRINT 1 |
初期状態 | 初期状態 |
PRINT 2 |
UART 4 |
初期状態 |
PRINT 3 |
UART 13 |
初期状態 |
PRINT 4 |
UART 13 |
SWITCH 1,22 |
PRINT 5 |
UART 4 |
SWITCH 1,22 |
以下が、実際の実験の様子です。
それぞれの PRINT コマンドによって画面 (ビデオまたは液晶) に表示されるかは、以下のようになりました。
(ビデオ：ビデオ画面へ表示 / 液晶：TFT液晶画面へ表示 / なし：表示されず)
| 1.3.1 | 1.4.1 | 1.4.3 | 1.5b | 1.4.1D2 | 1.5.0D | 1.4.1 (Cake) | |
|---|---|---|---|---|---|---|---|
PRINT 1 |
ビデオ | ビデオ | ビデオ | ビデオ | ビデオ | ビデオ | ビデオ |
PRINT 2 |
ビデオ | ビデオ | ビデオ | ビデオ | ビデオ | ビデオ | ビデオ |
PRINT 3 |
ビデオ | なし | なし | ビデオ | - | ビデオ | なし |
PRINT 4 |
液晶 | なし | なし | ビデオ | なし | ビデオ | なし |
PRINT 5 |
液晶 | 液晶 | 液晶 | ビデオ | ビデオ | ビデオ | 液晶 |
今回実験を行った全てのバージョンにおいて、同じ UART 4 の実行後である PRINT 2 と PRINT 5 で画面に表示されるかどうかは一致しています。
また、同じ UART 13 の実行後である PRINT 3 と PRINT 4 で画面に表示されるかどうかも一致しています。
(1.4.1D2 では PRINT 3 の実験を行うのを忘れてしまいましたが、UART 13 に対する OK は表示されなくなっているのが確認でき、PRINT でも同様に出力されないと推測できます)
したがって、少なくとも UART 4 および UART 13 の実行後に画面 (ビデオまたは液晶) への出力が行われるかどうかは、SWITCH 1,22 を実行したか否かにかかわらず同じであることがわかります。
よって、UART の動作は SWITCH とは関係ないと推測できます。
UART 4 に関する説明をあらためて見返してみて
これが、事件の直前、UART 4 で「画面表示を行わない」という嘘が書き込まれたときの UART 4 の説明です。
IchigoJam-BASIC/UART.txt at bf7a52260909f821ff88753ac7a26a28843ca95a · fu-sen/IchigoJam-BASIC · GitHub
4 画面表示を行わない、エコーバックあり
（1.2b63（正式版 1.3.0）～）
PRINT のみ送出、エコーバックあり（1.2b62 のみ）
そしてこれが、さらにその直前、この嘘が書き込まれる前の UART 4 の説明です。
IchigoJam-BASIC/UART.txt at f67d98f315dbf77a4b7eb9cf60c9b859fe3c8dfe · fu-sen/IchigoJam-BASIC · GitHub
4 PRINT のみ送出、エコーバックあり、改行コード CR
（1.2b63（正式版 1.3.0）～）
PRINT のみ送出、エコーバックあり、改行コード CR（1.2b62 のみ）
よく見ると、「1.2b63（正式版 1.3.0）～」と「1.2b62 のみ」という異なるバージョンについて、「PRINT のみ送出、エコーバックあり、改行コード CR」という全く同じ記述がされている、不自然な表現になっています。
となると、「1.2b63（正式版 1.3.0）～」において「画面表示を行わない」というのは誤りであっても、「1.2b62 のみ」においては「画面表示を行わない」可能性が考えられそうであることに気付きました。
1.2b62 や 1.2b63 における UART 4 については、以下のページに記述がありました。
IchigoJamをパソコンにつなぐシリアルモードまとめ＆エコーバックモード追加 1.2β62
シリアル送信ON (キー入力などのエコーバックモード) [new!] 1.2b62
はじめてのIoTプログラミング with ZenIT ペアプログラミングバージョン
シリアル送信ON (キー入力のエコーバックのみ) [new!] 1.2b63
しかし、これらのページの記述はいずれもシリアル送信の制御に関するもののみであり、PRINT などによる画面への出力を抑制する、といった話は出てこないようです。
さらに、モード5～7についても似た表現になっており、モード4のみ画面への出力を抑制する、というのは不自然に思えます。
したがって、該当バージョンのファームウェアを実際に実行して試していないので断定はできませんが、「1.2b62 のみ画面表示を行わない」という可能性も低そうだと考えられます。
とはいえ、1.2b62 では「エコーバックモード」、1.2b63 では「エコーバックのみ」と表現が変わっています。
ということは、1.2b62 ではモード4でも (エコーバックに加え) PRINTの内容がUARTに出力され、1.2b63 ではPRINTの内容はUARTに出力されない、という可能性は考えられます。
もし、送信モード4で追加された「画面表示を行わない」というのがこのこと (モード4ではPRINTの内容をUARTに出力しないこと) を指しているのだとすれば、嘘だとまではいえないかもしれません。
そうだとしても、「画面表示を行わない」という表現は送信モード8の「シリアル送出および画面表示を行わない」(ビデオや液晶の画面に表示しない、VRAMへの書き込みを行わない) と被り、誤解を招く表現であるため、変更するべきだと思います。
その他の問題点
ここでは、事件現場となったリポジトリで発見したその他の問題点を、Issuesのかわりにここに掲載します。
内容が誤っていると思われるもの
CHR$ の説明が不適切
CHR$ を使用する多くは PRINT になるでしょう。
と書かれています。
一方、たとえば HEX$ の解説を見ると、
HEX$ の使用は PRINT で使う事になります。
と書かれています。
ここで、
IchigoJam BASIC リファレンス ver 1.4
を見てみると、CHR の解説は
PRINT内で、文字コードに対応する文字を返す（コンマ区切りで連続表記可）
HEX の解説は
PRINT内で、数を16進数の文字列にする（２番目の数は桁数、省略可）
となっており、同様の「PRINT内で」という表現が使われています。
そのため、CHR$ も HEX$ も PRINT (? を含む) 内でのみ使う機会があると考えられ、それ以外の有効な活用法がありそうな「多くは」という表現は不適切であると考えられます。
COPY の解説の誤りと表現の不統一
COPY の解説において、
仮想メモリ領域の <転送元> から <転送先> へ
<転送数> バイト転送を行います。
<転送元>→<転送先>、<転送先>＋1→<転送先>＋1、……
とコピーしていきます。
とありますが、「<転送先>＋1→<転送先>＋1」ではなく「<転送元>＋1→<転送先>＋1」が適切であると考えられます。
また、この部分以外では「転送元/先」のかわりに「領域元/先」という表現が使用されており、どちらかに統一したほうがいい可能性があります。
DAC の書式の誤り
DAC コマンドにおいて、
[ コマンド 書式 ]
DAC(<端子>,<値>)[ 例 ]
DAC(9,1023)
とありますが、この丸括弧は余計であり、実機でつけると Syntax error になりました。
丸括弧をつけない DAC <端子>,<値> および DAC 9,1023 が正しいと考えられます。
KBD における上書き先の誤り
KBD の解説において、
SD カードに入れるファイル keymap.txt で設定も可能です。
また KBD コマンドで kapmap.txt は上書きされます。
とあります。一方、
IchigoJam BASIC RPi1.2 ドキュメント
では、
KBD キーボードのキーマップの切り替え(※2)
※2 ver1.2.5以降、KBDコマンドで keymap.txt にも設定が保存されます。
とあります。
よって、KBD コマンドで上書きされるのは kapmap.txt ではなく keymap.txt であると考えられます。
内容が足りないと思われるもの
HELP の出力内容の誤り (網羅不足)
HELP の解説において、
1.2 以降は下記の内容となります。
MEM MAP
#000 CHAR
#700 PCG
#800 VAR
#900 VRAM
#C00 LIST
とありますが、以下に挙げる手元にある1.2以降のバージョンすべてにおいて「MEM MAP」が表示されなかったため、「1.2 以降は下記の内容となります」というのは誤りです。
- 1.3.1
- 1.4.1
- 1.4.1D2 (各アドレスも含め何も出力されず)
- 1.4.3
- 1.5b
- 1.5.0D
さらに、
IchigoCake BASIC は下記の内容となります。
MEM MAP
#000 CHAR
#700 PCG
#800 VAR
#900 VRAM
#C00 VAR2
#E00 LIST
とありますが、IchigoCake BASIC 1.4.1 では「MEM MAP」は出力されなかったため、「IchigoCake BASIC は下記の内容となります」というのも誤りです。
なお、1.0.0 では「MEMORY MAP」が出力されたため、この解説に記載されている「MEM MAP」は解説用の文字列ではなく、実際に出力される内容であると解釈するのが妥当であると考えられます。
各バージョンでの出力内容
I2CR・I2CW の1バイトコマンドについて書かれていない
I2CR および I2CW コマンド (1.3系～？) では、コマンドの長さを省略することで、1バイトのコマンドを、アドレスではなくデータを直接指定して送信することができるようです。
しかし、I2CR のページ および I2CW のページ には、このことが書かれていないようです。
PRINT におけるコンマに言及が無い
PRINT 文では、データをコンマで区切って指定することで、複数のデータをタブ区切りで出力できます。
この機能は、少なくとも 1.0.0 では使用可能なようです。
しかし、PRINT のページには、書式・解説ともにこのことへの言及が全く無いようです。
TEMPO の解説が誤解を招く
TEMPO の機能には、
PLAY のテンポを指定します。
とあります。
この表現からは、TEMPO でテンポを指定しておけば、その後の PLAY におけるテンポの初期値として使用されるかのような印象を受けました。
しかし、
IchigoJam BASIC リファレンス ver 1.4
を見ると、TEMPO の解説は
再生中の音楽のテンポを変更する
となっており、これは IchigoJam BASIC リファレンス 1.0 でも同様です。
さらに、実際に実機 (1.4.3) で以下の手順で試してみました。
まず、
10 TEMPO 60
20 PLAY "CDEFG"
を実行し、再生される音を覚えておきました。
次に、10 行目を削除して再び実行すると、同じような音が再生されました。
すなわち、PLAY の前に TEMPO を実行しても、その設定値が PLAY におけるテンポの初期値にはならないことがわかります。
さらに、
30 TEMPO 60
を追加して実行すると、2音目以降の再生時間が長く (テンポが遅く) なりました。
よって、TEMPO によるテンポの設定は再生中の音楽には有効らしいことがわかります。
このため、「TEMPO によるテンポの設定は再生中の音楽にしか効かず、TEMPO の後で実行する PLAY コマンドには効かない」ことを表す表現を入れたほうがいいと思います。
USR の記述不足
USR のページにおいて、少なくとも
- 第4引数に割り算ルーチンのポインタを渡すバージョンが存在することに関する記述
- RISC-V を考慮した記述 (第1引数や戻り値が R0 ではなく R10 (x10) であることなど)
が存在しないようです。
細かいtypoなどと思われるもの
GOSUB におけるtypo
GOSUB の解説において、
1.1.0 beta1（正式版 1.1.0）よりでは省略形 GSB を使用できます。
という表現がありますが、「よりでは」の「では」を削除して「より」としたほうが自然だと思います。
IOT.OUT におけるtypo
IOT.OUT の解説において、
1.3 以降では i2C バッファが追加されたため、破損しなくなりました。
とありますが、小文字の i ではなく大文字の I を使用するのが正しいと思います。
LOAD・LRUN・SAVE における不自然な表現
そのため、プログラムの空いた領域（#FFF に近い後ろの領域）を
POKE で値を入れ SAVE 行う事でこの値も含めて保存し、
LOAD・LRUN の後 PEEK でこの値を取り出せます。
とあります。また、SAVE の解説 には、
そのため、プログラムの空いた領域（#FFF に近い後ろの領域）を
POKE で値を入れ SAVE 行う事でこの値も保存する事ができます。
LOAD・LRUN の後 PEEK でこの値を取り出せます。
とあります。
「SAVE 行う事」の部分に「を」を挿入し、「SAVE を行う事」としたほうが自然だと思います。
OUT における表現の不統一
OUT のページの「機能」には、
OUT 端子へ出力します。
とあります。一方、「解説」には、
<端子> を省略した場合、複数の端子状態を入力します。
0・1 <端子> へ入力
とあります。
「OUTコマンドへ入力する」や「周辺機器へ入力する」などの解釈ができ、間違いであるとは言い切れないものの、「(端子へ) 出力」に統一したほうが自然だと思います。
PEEK における表現の不統一
PEEK の解説において、
IchigoCake BASIC では [102]～[357] が存在します。
そのアドレスは #C00～#Dff に対応します。
とあります。
小文字を用いた #Dff のかわりに、大文字に統一した #DFF を用いたほうが自然だと思います。
また、
1 ← 矢印 左キー
2 → 矢印 右キー
4 ↑ 矢印 上
8 ↓ 矢印 下
16 SPACE スペースキー
とありますが、
- 「上」および「下」にも「キー」をつける
- 「左」および「右」にも「キー」をつけない
のいずれかに統一したほうが自然である可能性があります。
POKE におけるtypo
POKE の解説において、
IchigoCake BASIC では配列 [102]～[357] が #C00～#DFF に対応します。
したがってプログラム以降はアドレズがずれています。
とありますが、「アドレズ」ではなく「アドレス」とするのが一般的だと思います。
REM におけるtypo
REM の解説において、
これを用いて、一時的に実行しなくないコマンドに対し、
頭に REM を入れて無視させる事が可能です。
とありますが、「実行しなくない」ではなく「実行したくない」が適切だと思います。
SIN における句点抜け
SIN の解説には、
<角度> は度で指定します。返される値は 256 倍の値です
とあります。一方、COS の解説では、
<角度> は度で指定します。返される値は 256 倍の値です。
とあります。
SIN の解説にも、COS と同様に句点 (。) を追加したほうが自然だと思います。
SWITCH の書式の表現が不適切
SWITCH [<モード>][,<液晶の濃さ>] (1.3.2b12～）
とあります。一方、たとえば BEEP のコマンド 書式には、
BEEP [<周期>[,<長さ>]]
とあります。
SWITCH においても、BEEP と同様に角括弧をネストさせた
SWITCH [<モード>[,<液晶の濃さ>]] (1.3.2b12～）
としたほうが自然だと思います。
UART における句点抜け
UART の機能には、
シリアルの送受信を設定します
とあります。
他の多くのコマンドの機能の記述と同様に、句点 (。) を追加したほうが自然だと思います。
USR における不適切な表現
USR の解説には、
1.3.2b12（正式版 1.4.0）より、マシン語向けの API が実行されています。
とありますが、「実行」より「実装」のほうが適切である可能性が考えられます。