カナダからのブログ

このカテゴリーには小規模なプログラミングから大規模なプログラム開発，プログラミング言語，コンパイラなどに関する話題をあつめています． 上位のカテゴリーは 情報学・計算・プログラミング です．

なお，このページはプログラミングとコンパイラアーカイブ のページの先頭に表示されるように，意図的に投稿日時を 0001-01-01 00:00:00 としてあります (実際の投稿日時は 2007-12-23 17:30:17 です)．

おもくなるのをさけるためにアーカイブのページには写真がはいらないようにしていますが，個別ページにある写真をここに引用しておきます．

2003 年のおわりに SSIP コミュニケータという Web ページをつくっています． SSIP コミュニケータは Java で書いた文字による対話 (2 者間の会話) のためのプログラムです． 実用をめざしたわけではなく，会社での教育用につくったものです． 1 回使用しただけなので成功したかどうかはさだかではありませんが，通信プログラムのつくりをしめすみじかいプログラムとして，私自身は気にいっています． 最近は IP 電話やビデオ会議などのために SIP (Session Initiation Protocol) というプロトコルがよくつかわれますが，SSIP というのはそれにすこし似せてつくった，しかし SIP よりはずっとかんたんなプロトコルです．

1996 年に JavaScript による習作として単純な電卓をつくりました． 四則演算だけができる単純な電卓ですが，普通の電卓とちょっとちがうのは，"=" をおすまでは式を評価しないということです． このほうが誤入力を確認しやすくて，個人的には安心できる気がします． JavaScript はいまや，いたるところでつかわれていますが，これは単純でプログラムの動作がわかりやすいプログラムなので，教育的なのではないかとおもっています．

Apple II がひろくつかわれていた 1979 年ころ，出身高校の先生から Apple II 上でのプログラム開発をたのまれました． そのためのツールとして Basic で小規模な視覚的なエディタ BATE をつくってつかったのですが，それをあとで雑誌 I/O に投稿しました． I/O の別冊に掲載されたその記事の著作権は工学社にあるのでしょうが，いまやコピーしてもビジネスをじゃますることにはならないとおもわれるので，ここにおいておきます． いまなら実名で掲載してもらうでしょうが，なぜかペンネームをつかっています．

テキスト・エディタはプログラミングとコンテンツ制作のためのパワフルなツールです． 大学院にいるとき指導教官の和田先生や和田研究室のひとたちから TECO をはじめとするテキスト・エディタがもつ “ちから” をおそわりました． 私自身は TECO をつかうことはありませんでしたが，それにかわって普及した Emacs をいまも プログラム編集にはつねにつかっています．

このエントリーの内容はかなり特殊なプログラミング技法に関することなので， Movable Type のつかいかたにとくに興味があるひと以外には，あまりおすすめはできません．

これから書くことは，「わかっている」 ひとにとってはあたりまえのこと，あるいはまだおまえは十分わかっていないといわれることかもしれないのですが，一般にはプログラム全体を理解することの重要性がまだよく理解されていないとおもわれるので，書くことにします．

ASP.NET は Microsoft の汎用の Web アプリケーション開発/実行環境です． CGI という，従来の Web アプリケーションのしくみの問題点を解決するために ASP.NET にはサーバー・コントロールという一種のライブラリが くみこまれていますが，私はある Web アプリケーションのプロトタイプ 開発において，このサーバー・コントロールと格闘したすえに，それを捨てる (つかわない) という決断をしました． そのことについて書くことにします．

創発的計算のモデル CCM (Chemical Computation (or Casting) Model) というテーマで研究していたことがあります． 説明しだすとながくなるのでやめますが，このモデルで N クィーン問題， 地図のぬりわけ，魔方陣などの制約充足問題を確率的にとくことができます． それをネット上でためしてもらえるように，1996 年にはじめて Java のプログラムを Web で公開しました．

部品をくみあわせると “プログラミングなしに” システムがつくりあげられるようにしようとこころみつつ，失敗におわっているとおもわれる例を 2 つあげることにします． それは ASP.NET と JMF (Java Media Framework) です．

「はじめて公開した Java のプログラム -- 反オブジェクト指向 (?) のプログラム」 にも書きましたが，私がはじめて Java で書いたプログラムを公開したのは 「CCM をつかった単純な問題解決の例」 で N クウィーン問題，地図のぬりわけ，魔方陣をとくプログラムを公開した 1996 年です．

「失敗談を書く場所」 や 「プログラム部品化の失敗例」 で失敗談を書いてきましたが，ここでは信号処理に関する失敗談を 2 つ書きます．

1981 年のことですが，私は修士論文のテーマとして 「プログラミング言語の言語学」 をえらびました． これはプログラミング言語を (自然言語の) 言語学の手法をつかって分析するこころみです． Web 上で英語でもすこしだけ内容を紹介していたため，最近この論文に興味をもち，学会のチュートリアルで紹介したいというひとがでてきました． そのために Web ページに英語の要約と目次ものせました． このブログでもこの論文について紹介したいとまえからおもっていましたが，これをきっかけにすこし書いてみようとおもいます．

「プログラミングの小石・大石」 というなまえで，あたらしい “ブログ” をオープンしました． この “ブログ” の目的は，私がもっているプログラミングに関する，いろいろな，ちょっとした知識を紹介することです． すでに 10 項目くらい書きましたが，まだかきかけの項目もあります．

私のてもとにある Linux PC (会社のと家のとをあわせると 8 台くらいあります) のほとんどには Fedora Core 4 以降の Linux がインストールされています． しかし，いまでも 1 台だけ Red Hat Enterprise Linux の初期の版が動作している PC があります． この PC 上の Perl には私にとって致命的なバグがあり，それに 2 回つかまってしまいました．

「和田研ワークショップ」 という場で，私の最近 10 年くらいのあいだの研究開発のなかでの “ハッカー的” な仕事のやりかた，とくに Perl を道具としてさまざまな研究開発をしてきたことと，Perl + CGI の世界から脱却しようとして失敗した話とを紹介しました． そのときつかった PowerPoint 形式のファイル (2.5 MB!) と PDF 形式のファイル (1.5 MB!) があります．

Mule (ミュール) は GNU Emacs を多言語化したエディタですが，その機能がその後 Emacs じたいにくみこまれたため，いまではあまりつかわれなくなっています． それにもかかわらず，私は Windows XP や Windows Vista のうえで Mule for Win32 をつかいつづけています． Windows XP / Vista で動作する Emacs のあたらしい版はもちろんありますが，きちんと多言語対応 (というか日本語対応) していないからです．

このブログのためにつかっている Movable Type を 3.33j から 3.36 にバージョンアップしたことについては 「Movable Type 3.33j のバグ ― パーマリンクの勝手な変更」 に書きました． いれかえそのものは容易だったのですが，これによって項目を保存するときにエラーがでるようになり，ついには Movable Type のプログラムにパッチをあててしのぐことになりました．

私が修論で提案した 「プログラミング言語学」 について最近フランスからといあわせがあったことは 「プログラミング言語の言語学 ― 日本語の修論にいまフランスから照会が」 という項目に書きました． きのう，今度は国内からといあわせがあって，関連研究があるかどうかをしらべました． 上記の項目にも書いたようにプログラムを人間が書いた言語表現としてあつかう視点からの研究はすくないのですが，Masaru Ohba と Katsuhiko Gondow による識別子の構造解析に関する研究がみつかりました．

といあわせがあったことを機に，修論で書いたプログラミング言語学について再考したことは 「プログラミング言語学 「形態論」 のその後」 にも書きました． といあわせにこたえたり，「その後」 の研究をしらべているうちに，2 つのことに気がつきました． プログラミング言語学と OSS (オープンソース・ソフトウェア) との関係と， MSR (International Working Conference on Mining Software Repositories) という学会のことです．

プレゼンテーション [Nis 04] [Tak 99] や思考法 [Mur 06] でつかわれる図解のおおくは，プログラムの制御構造やデータ構造と対応していることがわかる． しかし，日本における図解の解説本ではこういう論理構造がかならずしも明確にされず，図解が論理をあらわさずに，みばえをよくするだけになってしまっているようにみえる． プログラムと対応づけることによって論理を明確化することができるだろう．

一方，図解において重要なポイントとされているがプログラムにおいては重視されていない点 (たとえば要素数を 7 くらいにおさえるべきだという点) が多々ある． これは，プログラムが読み手の立場で書かれていないことをあらわしているとかんがえられる． よみやすいプログラムを書くためには図解からまなぶべき点がいろいろあるだろう．

NTT 東日本の ICC (InterCommunication Center) が自宅からあるいてもいけるオペラシティにあります． こどもをつれて，きょう 8 月 31 日が最後の 「ICC キッズ・プログラム 2008」 と来年 3 月までの 「OPEN SPACE 2008」 をみてきました． どちらも，こどもにとっても私にとっても，たのしむことができる展示会でしたが，いささか不満な点もありました． とくに OPEN SPACE 2008 のほうは，作者が意図した方向に体験者をガイドできていない作品がめだっているようにおもえました．

1980 年代後半に，私は当時は全盛だったベクトル型のスーパーコンピュータ (スパコン) をつかった記号処理や論理型言語 (Prolog) の処理を研究していた (「論理 / 記号 ベクトル処理」 参照)． 当時，スパコンのプログラムを書くための唯一の言語は Fortran だった． しかし，Prolog プログラムの S-810 上での実行において最高性能をえるためには，それを Fortran に変換するのでは十分でなかった． そのため，Prolog 風のプログラムをいったんアセンブリ言語風のプログラムに変換し，さらに S-810 の機械語に変換するプログラムを Lisp によって記述していた． しかし，当時はそこまで論文には書かなかった．

タイトルには 「基盤技術」 もふくまれていて，実際に最初の 80 ページくらいはコンパイラの一般論にあてられている． しかし，80 ページで説明されて理解できる内容ではないとかんがえられるので，これはオマケとかんがえたほうがよい．

この本のテーマは COINS をつかった実践 (演習) にある． COINS をつかえば Yacc のようなパーザ自動生成から最適化，コード生成までを比較的容易にためしてみることができる (らしい)． 実際に C0 という簡単な言語のコンパイラのつくりかたが解説されている．

私はためしていないが，たぶんこの本をみながらじっくりとりくめば，他の本をただ読むよりはるかにえるところがあるだろう． 逆に，読むだけですませようというひと (私もそのひとりなのだが) には，この本はすすめられない．

評価: ★★★☆☆

関連リンク: コンパイラの基盤技術と実践@ ，コンパイラの基盤技術と実践@Amazon.co.jp．

大学にいたころから，いくつもコンパイラをつくってきた． しかし，もう 10 年以上，言語処理系からはなれていた． 最近，ついに仕事でコンパイラをつくる機会がやってきた． 以前とは言語仕様も実装もすこしちがうが，コンパイラづくりはやはりたのしい．

ドナルド・クヌースの本にならって (?) 仮想マシン Comp-XX の機械語プログラミングからはじめて，アセンブラ，Fortran，Basic, … と説明がつづき，最後に C, C++, Java, スクリプト言語の説明でおわっている． 正統的な入門のしかただが，初心者にこれで理解しろというのはむずかしいだろう． 案の定 (失礼!) 品切れ (絶版 ?) になっている．

初心者でなくても 2 つ以上のプログラミング言語をあつかうのはむずかしい． 初心者にはなおさら，まずなるべくたんたんな言語をすこしおぼえてもらうのがよいのではないだろうか． そのうえでなら，もしかしたら Comp-XX にもつきあってもらえるかもしれない． Comp-XX として，スナップ・スイッチがならんだ古典的なコンピュータの絵が何枚もあるが，まったく 「仮想」 でおわってしまっている． これに似た実在したコンピュータの写真をのせれば，もっと迫力があっただろう． ほかにも，もっとリアリティがあれば…という気がする．

評価: ★★★☆☆

関連リンク: プログラミング言語@ ，プログラミング言語@Amazon.co.jp．

ひさしぶりに Perl で日本語をあつかう環境を構築しようとしている． 12 年まえには会社で百科事典の検索の仕事をするために環境構築したが，そのときは Shift JIS コードないし EUC JP コードをあつかった． 今回は UTF-8 コード中心の環境をつくることになるが，周囲にはまだ UTF に完全に対応しきれていない環境やプログラムなどがいろいろあり，なかなかうまく構築できずにいる．

もう数週間まえのことだが，6 月の Linux Journal をみて，すこしおどろいた． LJ 読者対象の調査の結果として，すきなスクリプト言語をきいた結果として Python が 3 位で 19%，それに対して Perl は 4 位で 14% だという． これはそれほどおどろくべきことではないが，すきなプログラミング言語をきいた結果として Python が 1 位 (!) で 20%． C++, Java, C がそれにつづいて Perl が 5 位で 12% ということだ． Python の人気がこんなにたかいとは，しらなかった．

現在の最新版は Python 3.0 だが，この本は Python 2.4 (?) に準拠している． 3 年くらいふるくてもたいした差はないだろうとおもって古書を買ったが，いくつかの例をためしてみると，どれも結果が本書に書いてあるのとはちがう． “ustr = u"あ"” と入力するとエラーとなる (ただしくは ustr = "あ") し，“1/2” と入力すると，本書に書いてある 0 ではなくて 0.5 が表示される． というわけで，たとえ古書をやすく売っているとしても，最新版のほうを買うべきでしょう．

評価: ★★☆☆☆

関連リンク: みんなのPython@ ，みんなのPython@Amazon.co.jp．

前著 「みんなの Python」 につづいて，Web アプリケーション開発にしぼった Python 入門書である． 前著と同様に Python 2.4 (?) に準拠しているため，最新版である Python 3.0 とはだいぶちがう点がある． しかし，Web アプリ開発技術という点からみれば，現在でもおおきなちがいはない．

むしろ問題は Web アプリ開発の基礎をひととおりさらうまえに特殊な 「テンプレートエンジン」 について書いていることだ． 現在では CGI をナマでつかうことはすくなくなっているので Web 開発ツールについて書くのはよいが，特殊なツールについて書いても読者にはあまり，やくにたたないだろう．

評価: ★★☆☆☆

関連リンク: みんなのPython@ ，みんなのPython@Amazon.co.jp．

日本ではあまりつかわれていないが，アメリカなどでは Perl より Python のほうがはるかにおおくつかわれているようだ． そこで Python をためしてみようとおもって，処理系もインストールし，本も何冊か買った (柴田 淳 著, 「みんなの Python」, 「みんなの Python Web アプリ編」 など) のだが，あいかわらず，なかなか Perl からぬけだせないでいる．

小学生のころは 「x 年の科学」 をたのしみにしていたが，「大人の科学」 はこれまで買ったことがなかった． Vol. 24 の 4 bit マイコン GMC-4 にちょっと興味をそそられて買ってみたが，なかなかにクセモノだ．

14 年くらいまえからパズルをとく Java のプログラムを公開している． N クイーン (エイト・クイーンの一般化)，米国の地図ぬりわけ，魔方陣のプログラムである． ほとんど手をくわえていないそのプログラムがいまでもちゃんと Web ブラウザでうごくのが Java のすごさだ．

日本人よりは，Ruby on Rails，Perl，Twitter などの有名な言語やサービスを開発してきた外国人がインタビューの対象になっている． 技術系雑誌の連載を単行本化したということで，Perl, Ruby, JavaScript などといったプログラミング言語の話題もおおい． これらの言語を知っていればよりたのしめるが，知らなくてもえられるものはおおいだろう．

評価: ★★★☆☆

関連リンク: 小飼弾のアルファギークに逢ってきた@ ， 小飼弾のアルファギークに逢ってきた@Amazon.co.jp．

自分はプログラマではないがプログラムを書くのが仕事の一部だ． この本はそういう自分のことが書かれているようだ． つまりは，プログラマだけのことを書いているのではなくて，理科系にはかなり共通する部分がある．

「本を読むのが仕事」，半分の時間は調べものをしていると書いてあるが，研究者のばあいはプログラミングより本，論文，Web などを読むのが本来の仕事． 自宅にかえっても趣味でプログラムを書くというのもあたっている． トイレにいくときについでになにかしてくるというのも，いいあてられている． バグで悩んでいるときは，社内を歩いているときでも原因を考えているというのもそうだ． つかったことのないソフトのつかいかたをきかれてもこたえられないのに…ということも書いてある． 読んだらやくにたつという本ではないが，共感してしまう．

評価: ★★★☆☆

関連リンク: プログラマのしくみ@ ， プログラマのしくみ@Amazon.co.jp．

この本を書いたのはプログラマから SE を経て 「卒業」 したフリーライター． SE というと高級プログラマとおもっていたが，この本と，プログラマが書いた SE についての本などをみくらべると，SE とプログラマとのギャップ・対立がいかにおおきいかがわかる． やとったプログラマをついつい信じてうらぎられ，顧客をよみちがえる SE のすがたが，ここにはある．

評価: ★★★☆☆

関連リンク: SEのフシギな生態(単行本)@ ， SEのフシギな生態(文庫)@ ， SEのフシギな生態(単行本)@Amazon.co.jp， SEのフシギな生態(文庫)@Amazon.co.jp．

具体的なコンパイラづくりの本はほかにも何冊かあるが，この本は，だいたいふつうだがちょっとクセのある言語をつくっている． 比較的ページ数が多いのは，この手の本のなかではかなりアルゴリズムやデータ構造をくわしく説明しているからだ．

巻末にはソースリストがある． インターネットでダウンロードすればすむ時代にソースリストをのせる必要はないが，30 ページ弱だから，それほどじゃまになっているわけではない． もうちょっとみじかくてすむ言語仕様にすればもっとよかったとおもう． 基本はなるべくみじかくしておいて，この本の第 3 章のようにそれをいろいろ拡張してあそべるようにしておくのがよいようにおもう．

評価: ★★★☆☆

関連リンク: プログラムのしくみ@ ， プログラムのしくみ@Amazon.co.jp．

コンピュータ言語やその理論，とくに再帰を記号論的な見方で分析している． 記号論と人工言語とをむすびつけるそのやりかたは斬新だ． これら両方の分野に精通した人は非常にわずかだとかんがえられるから，どちらの分野のひとにとっても，この内容は新鮮だろう．

しかし，一応は両方を知っている立場からすると，このむすびつけかたはいささか強引だとおもえる． 記号論の対象は人間の言語や記号であり，記号の概念も解釈も人間のものだ． ところが，著者がそれをコンピュータ言語にあてはめるとき，そこには基本的に人間はいない． 機械が解釈するものとしてのコンピュータ言語と人間の言語の記号論を対応させるのには違和感がある． また，いまさら記号論なのかという気がしないでもない．

コンピュータ言語も人間が書くものだから，記号論や言語学の手法をとりいれるのにもっとべつの視点もある． 著者もところどころアドホックに人間の視点をいれてはいる． しかし，それをもっとすすめた議論は実は存在している． 金田 泰 著 「プログラミング言語学をめざして」がそれなのだが，(Web にはアップされているが) 残念ながら手書きの修士論文でおわっているためほとんど知られていないし，議論は浅い．

いずれにしても，この本はいくつかの賞をとり，英語でも出版されている． 著者あるいはこれらの本を読んだだれかが (私もふくめて) これをきっかけとして，さらにすすんだ議論や周辺の話題をほりおこしてくれればよいとおもう．

評価: ★★★★☆

関連リンク: 記号と再帰@ ， 記号と再帰@Amazon.co.jp， 記号と再帰@GoogleBooks．

Xhuang, X. and Pande, S. 著, "Compiler-Supported Thread Management for Multithreaded Network Processors", ACM Trans. on Embedded Computing Systems, Vol. 10, No. 4, Article 44.

ネットワーク・プロセッサ (NP) のスレッド管理をコンパイラによっておこなう方法に関する論文だ． とくべき問題はさまざまな NP に共通だが，この解は IXP という，過去の NP に特化されているところが惜しい．

比較的マイナーだが個性的な言語を 7 つえらんでいる． かつては 「言語屋」 のつもりだった私でも，つかったことがある言語はひとつだけだ． メジャーな手続き型言語やオブジェクト指向言語しか知らないひとにとっては，それらとちがう 7 つの言語を知ることはとてもよい経験になるだろう．

ただ，ひとつの言語について書いているページはかぎられているから，これだけで理解するのはむずかしいかもしれない． 時間があれば実際にこの本にある例をなぞってみれば，より理解がすすむだろう． むかしとちがって，いまならそれが比較的容易にできるだろう．

評価: ★★★☆☆

関連リンク: 7 つの言語 7 つの世界@Amazon.co.jp．

30 年以上まえに手書きで書いた修士論文を手書きのままで Kindle 本にした: 「プログラミング言語学をめざして」． おどろいたことに，私自身が出版されたことを確認するまえに，すでに 1 冊売れた．

プログラミングはほんとうはとてもわくわくするものだとおもうのだが，おおくのひとはそこにちかづかないし，職業プログラマーはなおさらそれを理解していないようにおもう． この Kindle 本には学校教育でプログラミングのおもしろさをおしえること，それを実践してきた MIT のレズニックや UEI の清水氏の話などがとりあげられている． この本がきっかけで，すこしでもプログラミングというものへの理解がふかまるとよいとおもう．

評価: ★★★★☆

関連リンク: Random Analysis@Amazon.co.jp．

最近かなり本気で Python のプログラムを書いている． そこでわかったのは，Python 2 と 3 とのあいだには互換性がなくて，よのなかには Python 2 しかつかえない環境やプログラムもすくなくないし，逆に Python 3 しかつかえない環境もあるということだ． 2to3 というプログラムがそのはしわたしをしてくれるはずだが，これはやくにたたない． だから，この非互換性はおおきな問題だ．

Generative art を生成するためのツールとしてよくつかわれているのが Processing だ． Java をつかって実装され，かんたんに図形や曲線をえがくことができる． しかし，Processing にはいくつか弱点がある． Processing に似た言語として PostScript があるが，弱点はほぼ共通している．

最近はさまざまなことに忙殺されてまだブログにはあまり書いていないのだが，「3D 印刷による 3D タートル・グラフィクス」 の印刷のようすをビデオにとり，YouTube に投稿した: Printing a dish by helical 3D-printing method． 印刷にかかる時間は 6 分ほどだが，途中はちぢめてある． 印刷法の説明は 「3D プリンタによる “3 次元タートル・グラフィクス”」に書いている． Maker Faire Tokyo 2014 にも出展する予定だ．

最近，手続き的に 3D 印刷する方法をいくつかためしているが，すくなくとも最近の文献のなかにはこのような方法はみあたらなかった． しかし，1950-60 年代には APT という言語があって，手続き的な切削加工を手続き的に記述しようとしていたことがわかった． 機械屋には周知のことなのかもしれないが，ACM という私のメインの学会 (コンピュータ学会) で論文が掲載されていたにもかかわらず，これまでまったく知らなかった．

和田研 OB mini・ワークショップという場で近況報告をした． おもな内容は会社でやっている深層学習 (deep learning) にもとづく歩行者検知， 11 月に出展したデザイン・フェスタ，そして先週いって発表・展示してきた Generative Art 2015 (GA 2015) だ． 時間が 15 分だったので，写真が中心だ．

かつて連絡委員をしていたこともあるプログラミング研究会に，ひさしぶりにいってきた． Python で書いたライブラリをつかった 3D 印刷の発表をしてきた (「手続き抽象化機能をもつプログラミング言語による 3D 印刷」)． この論文は情報処理学会の「デジタルプラクティス」の 3D 印刷特集にだしたのだが，おとされたのでかわりにプログラミングの論文誌にだしてもらおうとかんがえて，ここにもってきた．

確率的計算モデル CCM にもとづく Java で書いた N クィーン問題や地図の 4 色ぬりわけ問題などをとくプログラム例題は Web 上で 1995 年から最近まで，ほとんど書きかえることなく動作してきた． しかし，applet がサポートされなくなるというので，ついにこれらのプログラムがうごかなくなる． ためしたところでは，これら CCM 例題の applet は Macintosh (Safari) ではうごいたが，Windows では Internet Explorer でも Mozilla でもうごかなかった． うまく設定すればうごくのかもしれないが，容易でない．

よのなかでは必要以上に複雑なプログラムが書かれ，つかわれている． また，よのなかの Web ページは必要以上に複雑になっている． そういう複雑なものは私には管理できないから，私がつかっているプログラムも Web ページもできるだけ単純にしている．

最近導入した PC に螺旋 3D 印刷の開発環境をセットアップしたが，その一部は Strawberry Perl のインストールだ． それでおもいだしたのがこの環境のために Strawberry Perl を選択した経緯だ． それについては「ラベル印刷プログラムなどに使用している Strawberry Perl」という 3d-dl.com のブログに書いたが，カナダからのブログも検索してみて，「ひさしぶりの Perl 日本語環境構築 ― まだ完全に成功してはいない…」という項目があるのに気づいた． 2009 年にも Strawberry Perl をえらんでいたということだが，そんなことはすっかりわすれていた．

M2 MacBook の Python 環境をととのえるのがむずかしい． ときどき Arm64 と X86_64 の環境が混在しているといわれて，import に失敗する．

一度はこの問題を解決していたはずなのだが，最近，MacBook の SSD を初期化する必要があったために，また復活してしまった． ようやくなおすことができたので，どうやってなおしたのか，ここに書いておくことにする．