Раздан-3

タイトル長い。

前回の記事にて、Windows 10 で日本語を含んだフォルダに格納されている Pharo システムを起動しようとすると、うまくいかない件について説明した。

要するに、素のWindows 10ではアプリへ引き渡す実行ファイルパスがShift JIS なのに対して、Pharo VM ではUTF-8が来ることを想定していることに起因する問題だった。
（CJK以外ではきっと問題にならないのでしょう）

いろいろ試した結果、VM を読み込む際にファイル名を Shift-JIS から UTF-8 に変更すれば万事解決することがわかった。

変更箇所は src/client.c だけ。diff したものを下に記載する。

*** src/client.c	2022-07-30 16:34:45.625821758 +0900
--- changes4/client.c	2022-08-10 17:03:13.256402934 +0900
***************
*** 207,213 ****
--- 207,227 ----
      sqImageFile imageFile = NULL;
  
      /* Open the image file. */
+ #ifdef _WIN32
+     size_t acpLength = strlen(fileName);
+     int utf16Length = MultiByteToWideChar(CP_ACP, 0, fileName, acpLength, NULL, 0);
+ 
+     WCHAR *utf16String = (WCHAR*)alloca((utf16Length + 1) * 2);
+     MultiByteToWideChar(CP_ACP, 0, fileName, acpLength, utf16String, utf16Length + 1);
+ 
+     int utf8Length = WideCharToMultiByte(CP_UTF8, 0, utf16String, utf16Length, NULL, 0, NULL, FALSE);
+     char *utf8filename = (char*)alloca(utf8Length + 1);
+     WideCharToMultiByte(CP_UTF8, 0, utf16String, utf16Length, utf8filename, utf8Length + 1, NULL, FALSE);
+ 
+     imageFile = sqImageFileOpen(utf8filename, "rb");
+ #else
      imageFile = sqImageFileOpen(fileName, "rb");
+ #endif
      if(!imageFile)
  	{
      	logErrorFromErrno("Opening Image");
***************
*** 223,229 ****
      sqImageFileClose(imageFile);
  
      char* fullImageName = alloca(FILENAME_MAX);
! 	fullImageName = getFullPath(fileName, fullImageName, FILENAME_MAX);
  
      setImageName(fullImageName);
  
--- 237,247 ----
      sqImageFileClose(imageFile);
  
      char* fullImageName = alloca(FILENAME_MAX);
! #ifdef _WIN32
!     fullImageName = getFullPath(utf8filename, fullImageName, FILENAME_MAX);
! #else /* _WIN32 */
!     fullImageName = getFullPath(fileName, fullImageName, FILENAME_MAX);
! #endif /* _WIN32 */
  
      setImageName(fullImageName);
 

たぶんこれでOKなはず。お盆開けたらいろいろな環境で試してみるつもり。

酔狂で面倒な VM のビルドをしたかった訳じゃない。Pharo を使って作成したアプリを展開するのに、表記のような問題があって困るので、VMの変更で対応したいと思ったから。

Pharo VM に関して困っているのは以下の２点である。

• パスに日本語を含んでいるときにVMがイメージを認識してくれない。
• 共有フォルダに格納したVMから起動できない。

どっちも「使わなきゃいいじゃない」レベルの話で個人ならいくらでも回避できるんだけど、アプリを展開したいと思っている先の環境なので致し方ない。

VM ソースを追っかけてみると、前者については以下が原因らしい。

• VMの実行パスからイメージのパスを生成する際、UTF-8からUTF-16の変換をしている。
• 素のWindows 10の場合、実行パスはShift-JISで表現されている。
• なので正しく日本語を変換できずイメージファイルを見つけることができない。

後者についてはもっと根が深いみたい。→要追加調査

まずは前者に対応して見ようと思う。

（本日は休日出勤日なのでやる気なし）

前回の記事でビルドする手順を説明したが手抜きすぎたので、簡単なバッチファイルを作ってみた。賞味期限は非常に短いと思われるけど、cygwin のオプションをいろいろ調べたりしたので、その成果も兼ねて。

（2022.8.10追記）
もとの記事だと「FreeTypeライブラリがない」と怒られてしまったので、cygwin のパッケージにlibfreetype-devel を追加した。これに伴って link.txt の変更が不要になった。

Cygwin のダウンロードとインストール

まずはcygwinのsetupプログラムをダウンロードして必要なパッケージをダウンロードするまでの手順。適当なバッチファイルに保存して実行すれば良い（はず）。

いちおう管理者権限なしでインストールできる（はず）

set ROOT=%HOMEDRIVE%%HOMEPATH%
cd %ROOT%
curl http://cygwin.com/setup-x86_64.exe -o setup-x86_64.exe
setup-x86_64 ^
  --no-admin ^
  --root %ROOT%\cygwin ^
  --site http://ftp.jaist.ac.jp/pub/cygwin/ ^
  --local-package-dir %ROOT%\cygwin\packages\ ^
  --no-desktop ^
  --quiet-mode ^
  -P make ^
  -P cmake=3.17.3-2 ^
  -P zip ^
  -P mingw64-x86_64-clang ^
  -P unzip ^
  -P wget ^
  -P git ^
  -P autoconf2.5 ^
  -P autoconf ^
  -P automake1.16 ^
  -P automake ^
  -P libtool ^
  -P patch ^
  -P libssl-devel ^
  -P libgit2-devel ^
  -P libz4-devel ^
  -P libfreetype-devel

これで C:\Users\hoge のようなユーザーフォルダに cygwin フォルダが作成され、自動的にパッケージがインストールされる。

github レポジトリのクローン＆ビルド

次にスタートから Cygwin64 Terminalを選んで cygwin のターミナルを起動して、以下を入力する。

git clone https://github.com/pharo-project/pharo-vm.git

以下のようにcmake を実行して、buildディレクトリを生成する。

cmake -S pharo-vm -B build

（2022.8.10追記）
以下、libfreetype-devel パッケージの追加によって link.txt の変更が不要になった。

運良くcmake に成功したら freetype-build の link.txt を編集する。

vi build/freetype-build/CMakeFiles/freetype.dir/link.txt

長大だけど１行しかないファイルなので、末尾の -lz の直前に -L/usr/lib を挿入する。こんな感じ。（太字部分）

(ごちゃごちゃ) ftdebug.c.o -L/usr/lib -lz

最後に build ディレクトリで make する。

cd build
make

幸運ならビルドが成功して、build/vm ディレクトリにVMやプラグインのバイナリが生成されている（はず）。

ちなみにWindows側からみたディレクトリは、ユーザー名=hoge として、C:\Users\hoge\cygwin\home\hoge\build\build\vm みたいなところにある。

（2022.08.10追記）

上記を自動化したスクリプトを作ってみた。いちおう動くことも確認済み。（link.txt 変更のためのsedスクリプトは削除した）

git clone https://github.com/pharo-project/pharo-vm
cmake -S pharo-vm -B build
cd build
make

おまけ

Cygwin のアンインストール方法はこちらを参考に。

レポジトリには簡単にできそうに書いてあったけど、ビルドできるようにするまで大変だったので備忘としてメモ。

ポイントはcmakeのバージョンをできるだけ下げること。執筆時点でCygwinにインストールされるのは 3.23.2-1 だったけど、これでは不可解なエラーが発生して cmake が失敗する。

先のレポジトリでは最低でも3.7.2と書いてあったので、選択できる一番古いバージョン（3.17.3-2）に戻したら cmake が成功するようになった。

あと、Windowsの項目では「cmake .」するように書かれているけど、Linux/Mac OSと同じように親ディレクトリから「cmake -S pharo-vm -B build」した方が、いろいろ試しやすくてよかった。

レポジトリにある便利スクリプト（scripts\installCygwin.ps1）は必要なパッケージを自動的にインストールしてくれる。実際にはそれだけでは足りずエラーになった。ビルドには更に以下のパッケージが必要だった。（どうせsetupしなおすんだったら、スクリプトに書いてあるパッケージも含めて手動で入れた方が楽かも）

libssl-devel
libgit2-devel
libz4-devel

パッケージを追加するたびにCygwinのsetupが cmake を最新版にしようとするので、かならず Keep を選んでおくこと。

さて、buildディレクトリでmakeすると途中でエラーになる。freetype ライブラリをリンクする際に-lz が見つからないようだ。cmake のスクリプトを書き換えれば良いのだろうが場所が特定できなかった。（後でやる）

とりあえず build/freetype-build/CMakeFiles/freetype.dir/link.txt を直接編集して、-lz の前に -L/usr/lib を追記したら最後までビルドできた。

cmake は難しい。

前回の記事でPharo のプロジェクトを github.com で公開する方法について説明した。

今回は、 Travis CI を使ってテストを自動実行させる方法について説明する。

前提

• Travis のアカウントを持っていること。
• github.com と連携済みであること。
• 自分のプロジェクトにテストパッケージを作っていること。

【重要】パッケージを保存する

先に進む前に、Monticello などでパッケージが保存されていることを確認する。テストも含め、いつでもパッケージ内容を元に戻せる状態にしておく方が安全・安心。

設定ファイルを作る

Travis CI でテストを実行させるために、リポジトリに２つのテキストファイルを作成する。

１つめは、 .smalltalk.ston である。内容は以下のようなもの。

SmalltalkCISpec {
  #loading : [
    SCIMetacelloLoadSpec {
      #baseline : 'MyProject',
      #directory : 'src',
      #platforms : [ #pharo ]
    }
  ]
}

MyProject の箇所は適宜修正する必要がある。

２つめは、 .travis.yml である。

language: smalltalk
sudo: false

notifications:
  email:
    on_success: never
    on_failure: always

os:
  - linux

smalltalk:
  - Pharo32-8.0
  - Pharo64-8.0

変更する必要のある箇所は、osのところと、smalltalkのところ。osは、他に osx が指定できる。（きっとwindowsも。詳しくは Travis CI のドキュメントを参照のこと）

smalltalk にはテストしたいイメージのバージョンを書く。このあたりの情報は以下のサイトで確認できる。

https://github.com/hpi-swa/smalltalkCI

上記を適当なテキストエディタで作成して、ローカルレポジトリのフォルダに保存しておく。

Shellで作業する

ローカルレポジトリ内で行った修正作業は、Iceberg では Commit できないので、Shell でコミットとプッシュを行う必要がある。作成したファイルをadd したあと、適当なコメントで commit して push する。

% git add .smalltalk.ston .travis.yml
% git commit -a -m 'add travis ci settings'
% git push

プッシュが完了したら Travis CI が自動的にテストを始めるはず。

Pharo で作業する

Pharo の環境にもどり、Iceberg でレポジトリのエントリを右クリックして Fetch を選ぶと、Up to date だったステータスが赤色の Detached Working Copy になる。

再度、右クリックして、 Repair Repository を選ぶ。そこで、Discard image changes and load repository version を選ぶ。ここで、Monticello などに保存していないパッケージの変更があると全て失われてしまうので、必ず保存しておく。問題なければ OK を押す。

続く画面で Checkout を押してレポジトリの状態が Up to date に戻れば完了。これ以降は、Iceberg でもコミット＆プッシュ後に Travis CI が自動的に動き出すようになる。

SqueakMap とか、SmalltalkHub とか、Smalltalk のプロジェクトを残す方法はいろいろあったけど、いまは github.com に残すのがナウい。

今年、立て続けに何個かプロジェクトを登録したけど、毎回忘れてしまうので備忘のために残しておく。

参考にしたサイトはこちら。

前提

• 自分の github アカウントが存在すること。
• 登録するプロジェクトのパッケージが作ってあること。（この記事では MyProject とする）
• travis でCIするなら、テスト用のパッケージも作っておく。（推奨、この記事では MyProject-Tests とする）

転ばぬ先の杖

何かのトラブルでせっかくのコードが失われないように、Monticello Browser でパッケージ（Testsパッケージも）を保存しておく。（方法は省略）

github.com での仕事

レポジトリの作成

github.com にログインして、新しいレポジトリを作る。

• Repository name は適当なものでよし。
• Description は適当なものでよし。
• 無料アカウントなので Public 一択。
• Initialize this repository with a README はチェックを入れておく。
• Add .gitignore では、Smalltalk を選ぶ。
• Add a license では、適当なライセンスを選ぶ。（自分はいつも MIT License）
• おわったら Create repository をクリックする。

レポジトリURLのコピー

出来上がったばかりのレポジトリが開かれたら、そのgithubアドレスをコピーする。

Code をクリックして、 Clone with SSH の下の欄の git@github.com: のテキストを全てコピーするか、その隣のアイコンをクリックする。

Pharo での仕事

Iceberg でローカルレポジトリを作る

Pharo を起動して Tools – Iceberg を選んで Iceberg を起動する。

右上のAddをクリックする。

• Clone remote repository を選ぶ。
• Remote URL に、先ほどコピーしたgithubレポジトリのアドレスを貼り付ける。

このままOKを押すと、いま使っているイメージのあるフォルダの下にローカルレポジトリが作られる。PharoLauncher を使っていて、イメージごと削除するのがイヤな場合は、必要に応じて Local directory の場所を変えておく。

問題なければ OK を押す。

ローカルレポジトリに src フォルダを作成する

ソース群を格納するためのsrc フォルダを作る。

Iceberg で作成したばかりのレポジトリのエントリを右クリックし、Extra を選んで Inspect … をクリックする。

Inspector が現れたら Raw タブを押して、コードエリアに以下を入力して do it する。

(self location / 'src') ensureCreateDirectory

特に問題が生じなければ、 Inspector を閉じて構わない。

Meta データを生成する

次にプロジェクトのメタデータを生成するために、再度レポジトリのエントリを右クリックして Repair repository を選ぶ。現れたダイアログで、Create project meta-data を選んで、OKを押すと、Edit Project のダイアログが現れる。

Code directory に先ほど作成した src フォルダが選ばれており、Format が Tonel になっていることを確認したら OK を押す。

BaselineOf パッケージを作る

パッケージの依存関係を明確にするために、BaselineOf クラスのサブクラスを作成する。作成したいパッケージが MyProject なら、以下のようにクラス定義する。

BaselineOf subclass: #BaselineOfMyProject
    instanceVariableNames: ''
    classVariableNames: ''
    package: 'BaselineOfMyProject'

必要なインスタンスメソッドは２つで、１つ目は projectClass メソッドである。

projectClass
    ^ MetacelloCypressBaselineProject

もう一つは baseline: メソッドである。必要なパッケージに応じて内容を適宜修正する必要がある。他のパッケージを参考に依存関係を示せばよい。

baseline: spec
  spec
    for: #common
    do: [ spec
            package: 'MyProject';
            package: 'MyProject-Tests'
            with: [ spec requires: #('MyProject') ] ]

パッケージを追加する

最後に関係する全てのパッケージを追加する。レポジトリのエントリをダブルクリックして Working copy of のダイアログを表示し、右上の Add Packages ボタンでパッケージ（本体、テスト、BaselineOf）を全てチェックし、Add で追加する。（図のようにパッケージ名を入力して絞り込んで置くとラク）

Commit + Push する

Iceberg の作業もほぼ終わり。Commit ボタンを押してコミット内容を確認して適当なコメントを書いたら、再度右下の Commit ボタンでコミット完了し、Push ボタンで github にプッシュする。

なお、下図のように Push changes to origin/main をチェックしておけば、コミットと同時にプッシュが行われる。

以上で github.com にパッケージがアップロードされた。

パッケージの内容を変更したときは、同様に Commit + Push すれば、その都度 github.com の内容も更新されていく。