AtomからVSCodeに移行し，LaTeX機能拡張をインストール

 Atomやっと使い慣れてきて，CでもPythonでもTeXでも便利に使っていたのですが，なんと開発終了という悲しい情報を知り，さて何に乗り換えようかと考えています。

ウインドウを散らかす性格のため，TeXのプレビューが同じウインドウに表示されるエディタがいいので，vimやemacsは選択肢から外れます。

そうすると，にMicrosoftのVisual Studio Codeが上がってきました。

Microsoft?という先入観でちょっと抵抗があったのですが，Atomと似ていて使いやすそう。

早速導入。

環境は，MacPortsでTexLive2022がインストールされている状況。

Visual Studio Codeのバージョンは1.71.2

取り急ぎLaTeX機能拡張が欲しかったので，LaTex Workshop v8.29.0をインストール。

⌘+,で環境設定。

右上のアイコンをクリックすると，設定ファイル（settings.json）をエディットできる。

私は最近uplatexを主に使っているので，ここでtoolとしてptex2pdfに-uオプションをわたして実行すればいいのだが，bibtexをまわすときとまわさないときでレシピを分ける必要がありそう。

ここで色々調べてみると，latexmkをつかうと，その辺を判断してbibtexをまわしたりまわさなかったりしてくれる模様。

日本語の処理を楽ちんにするため，uplatexでdviをつくってdvipdfmxでpdf化する方向で設定したい。

latexmkは，ホームディレクトリの下に.latexmkrcというファイルを用意しておけばその通り実行してくれる模様。

公式マニュアル（$ man latexmk）を実行してざっと文章を斜め読みしながら.latexmkrcの書式について一通りしらべて，私の目的（VSCodeから実行する）なら，以下の項目だけを設定すればいい模様。

まず一番大切なのは，$pdf_mode。

dviからpdfの流れにする場合は3にする。

次にtypesetコマンドの設定。

これは，$latex。

それから$bibtexと$dvipdf，$makeindexを設定しておけば最低限動きそう。

それだけ設定した私の.latexmkrcはこんな感じ。

#!/usr/bin/env perl

$pdf_mode         = 3;

$latex            = 'uplatex -halt-on-error';

$bibtex           = 'upbibtex';

$dvipdf           = 'dvipdfmx %O -o %D %S';

$makeindex        = 'mendex %O -o %D %S';

これを動かすVSCodeのsettings.jsonはこんな感じ。

{

"latex-workshop.latex.recipes": [

{

"name": "latexmk",

"tools": [

"latexmk"

]

}

],

"latex-workshop.latex.tools": [

{

"name": "latexmk",

"command": "latexmk",

"args": [

"%DOC%"

]

}

],

"latex-workshop.view.pdf.viewer": "tab",

"workbench.colorTheme": "Solarized Dark",

}

すっかり忘れていたけど，iCloud Drive上のファイルは扱えません。

VSCode側かLaTeX Workshop側かわかりませんが，おそらくフルパスで処理しようとしてパスにスペースが入っているところでおかしなことになるのかと思われます。それさえなければこの環境はよさそう。

ParallelsClientを用いてLinuxのデスクトップをxrdpでmacOSから遠隔操作（追記あり）

 macOSからwindowsを遠隔操作する際は，Parallels Crientを使うとスピードの面でもキーボード配列の面でも良いので使っていました。

一方でmacOSからlinuxに繋ぐときは，XDMCPやVNCを使っています。

しかし，終了の仕方，起動の仕方にノウハウがありちょこちょこ変なことが起こったりするので，どうにかならないかと思っていました。

最近，xrpdについての記事をちょこちょこ見かけるようになったので，もしかしたらlinuxサーバもrdpを使うとmacから操作できるのではないかと思い，やってみました。

とりあえず私の環境は，古いのですがLinuxのサーバ側はScientificLinux7.9で，クライアントはmacOS BigSur。Montereyでも試しましたがほとんど一緒でした。

Linux側は多分CentOSでも一緒で，RedHat系のディストリビューションならきっとどれも同じでしょう。

Linux側へのxrdpのインストールは色々なところに情報がありますが，vncサーバのインストールも必要なようです。私は元々tigervncを入れてあったのでそこは意識することはありませんでした。

あとは，systemctlでxrdpを起動すれば何もせず接続できました。

# systemctl start xrdp

もし自動起動させたければ，

# systemctl enable xrdp

macからの接続は，Parallels Clientを起動し，新規接続から，標準RDPを選びます。

特に設定する項目はなく，サーバーのところにLinux側のIPアドレスを入れるだけでオッケー。

フレンドリ名は自分が見分けられる単純な名前にすれば良いようです。

ここまでの設定が済むと，そのまま接続すると認証エラーという画面が出てちょっと気分が悪いです。

これはおそらく接続する時にユーザ名とパスワード情報を同時に送信しているからだと思います。

これをログイン画面と解釈してLinux側のユーザ名とログイン名を入れれば何の問題もなくLinux側へログインができます。

認証エラーと言われることがあまり気持ち良くないのであれば，Parallels Client側の詳細設定でユーザ名とパスワードをあらかじめ入れておけばオッケーです。

ParallelsClientのトップ画面で，先程設定した接続を右クリックすると（私はすでにいくつか接続を設定してしまっていますが）

『自動ログイン』にチェックを入れていなくても私の場合上記の認証エラー画面がでます。

ここでLinux側のユーザ名とパスワードをあらかじめ入れておけば認証エラー画面が出ずに，そのままLinux側の画面が出ます。

ここで表示されるデスクトップは，ディストリビューションデフォルトのもので，デスクトップマネージャーのようなものが表示されないので，sessionを選択することなどができませんが，おそらく設定でどうにかできるとは思いますが，それはまた今後。

2022/08/31追記

バージョン19から新規接続の画面が以下のように変わり，デフォルトの設定だとなぜか接続できなくなります。

いくつか試した結果，デフォルトだとRetinaディスプレイのとんでもない解像度で接続に行ってしまいエラーになるようですので，接続前にディスプレイの解像度をたとえば1920x1080などに変えておくとエラーなく接続できるようです。

まず，新規接続は以下の画面でIPアドレスを入れるのではなく，左下にある『代替RDP接続を作成』から進みます。

すると以下の画面になるのでここでLinuxサーバ側のIPアドレスを入れます。

フレンドリ名は多分なんでもいいと思います。

詳細設定画面で，以下のように解像度をおさえめにするとうまく接続できるようです。

MacのzoomでiPadの画面共有ができなくなり驚く（解決済み）

 オンライン授業では，ケーブル接続したiPad上でGoodNoteに手書きしてそれを画面共有していました。

ところが，ある時それができなくなり小一時間焦りました。

症状としては，zoom会議中に『画面の共有』をクリックしても，『iPhone/iPad（ケーブル使用）』の選択肢が出てこないのです。

 結論としては，これはアプリでいくら設定を探してもダメで，ブラウザでアカウントに入り， 

<zoonのurl>/profile/setting

へ移動して，

『主催するミーティングでのデスクトップ画面の共有を無効にします』

の項目のチェックが入っているとデスクトップ画面の共有ができなくなるとともにiPhoneやiPadの画面も共有できなくなるという設定でした。

自分でもいつのまにこの項目にチェックを入れいていたのか覚えていませんでしたが，解決してよかった。

Apple silicon (M1 Mac)でGP-IB通信できるのか（情報収集中）

NI488，やっと64bit対応したと思ったらこんどはApple silicon。

あきらかに重いコンダラを引くことになりそうな話ですが，新品でintel macが手に入らなくなる前にどうにかしておきたい問題。

NI488はまだarm64には対応していない様子。

ウェブサイトには対応OSとしてmacOS 11(x86_64)と書かれています。

この場合理屈の上ではRosetta 2の上で動くはず。

あとは，コンパイル時にキチンとarchitectureとしてarm64ではなくx86_64が指定できるのかどうか。

今はHomebrewで開発環境整えているので，まずはHomebrewでインストールするパッケージがx86_64にできるのか。

調べてみると，そもそもx86_64では/usr/local以下にインストールされていたものが，arm64では/opt以下になるなど，その時点で大変な予感しかしない。

Homebrew自身は，まずはterminalをRosettaで起動するよう設定。

ここのチェックボックスをオンにするかオフにするかで，Rosettaかどうかを切り替えられる模様。

Rosetta版とarm64版を切り替えて使うことも可能らしい。

とりあえず今日はここまで。

gthreadの使い方が変わったらしい(C言語)

 最近，卒研生に測定用プログラムのメンテナンスや改良を任せようと思っているのですが，gtkやgthreadの情報があまり日本語で公開されていないので，牛の歩みで進めています。

まず一番困ったのが，最近になって以下のような二つのwarningが出てくるようになったことです。

main.c:503:3: warning: 'g_thread_init' is deprecated [-Wdeprecated-declarations]

main.c:580:12: warning: 'g_thread_create' is deprecated: Use 'g_thread_new'

GLibの仕様変更のようです。

一つ目に関しては，どうやらg_thread_initとはもう書かなくてよくなったようで，単純に削除でOKでした。

二つ目に関しては，本文中では

  thread = g_thread_create ( thread_func, (gpointer)label3, FALSE, &error );

と書いているのですが，これをそのままg_thread_newと書き換えただけではダメみたいです。

オンラインドキュメントを見てみると，

g_thread_new ()

GThread *           g_thread_new                        (const gchar *name,
                                                         GThreadFunc func,
                                                         gpointer data);

と書いてあり，引数が３つになって，しかも第一引数が謎のスレッド名。

とりあえず謎のスレッド名のところは適当に名前をつけて，第二引数に関数名，第三引数に関数に渡すパラメータとして書き直したところ無事にwarningが消えました。

SciDAVisのdark modeが見づらい

 MacPortsでインストールされていたSciDAVis，現在のバージョンは2.4らしいのですが，どうにもDarkModeが見づらい。

しかも，コマンドラインからの起動に戻ってしまった。

そこで，古いバージョンをアクティベートし直すことにした。

 % sudo port installed scidavis

Password:

The following ports are currently installed:

  scidavis @2.1.4_0

  scidavis @2.4.0_0

  scidavis @2.4.0_1 (active)

2.1.4の時まで遡ることに。

% sudo port activate scidavis @2.1.4_0

--->  Computing dependencies for scidavis

--->  Deactivating scidavis @2.4.0_1

--->  Cleaning scidavis

--->  Activating scidavis @2.1.4_0

--->  Cleaning scidavis

無事に古い方で起動が可能に。

現在の環境。

macOS 10.15.7

MacPorts version 2.7.1

macOSでパスワードつきzip圧縮

 これまでパスワードつきzipファイルを作るときは，

1. Finder上で右クリックして圧縮

2. terminalで

$ zipcloak <対象zipファイル名>

としていたのですが，最近このやり方で作ったパスワードつきzipファイルがうまく解凍できないトラブルが発生しました。

どうやら，ディレクトリをzip圧縮した際に起こるようです。

よくよくみてみると，zipcloakでパスワードをかける際に，

zipcloak warning: Local Entry CRC does not match CD: <ファイル名>

という警告が出ています。

結局古典的に，

$ zip -r -e <作りたいzipファイル名.zip> <対象ディレクトリ>

でパスワードつきzipファイルを作ったらうまく解凍できました。

理由はよくわかりませんが，今のところディレクトリを圧縮するのに右クリックは使わないほうがいい，ということのようです。