2020年12月1日火曜日

Eclipse の TeXLipse プラグインが2年ぶりに更新されていた話

文書作成には主に LaTeX (LuaLaTeX) を使ってまして,執筆用の環境としては Eclipse 上の TeXLipse を使っています.

最近,かなりアグレッシブにドキュメントを書くことが増えてきてまして,だんだんと TeXLipse の小さな問題が気になってきました.現在使っている 2020-06/2020-09 との相性の部分もあるかとは思いますが,特に

  • bib ファイルの編集をしようとして BibTeX Editor で開いても何も表示されず,通常のテキストエディタで編集せざるえない
    • なお両エディタ共に Eclipse 上のものです.BibTeX Editor は TeXLipse をインストールすると Preferences で表示されますし,Project Explorer 上でファイルを選択し Open with で開こうとすると出てきますので何かしら機能はあると思いますが,見たことがありません
  • tex ⇔ bib との連携がうまく行かないことがあり,文献参照が適切に表示されない
    • usepackageのbiblatexでbiberを指定することが多いですが,途中まではうまくいっていたのに,ある時から citation が見つからないというエラーが出て,参考文献リストも文章中の参照も適切に表示されない(citation名が表示される)

でつまることが増えて,ちょっと困ってました.

Eclipse 上で「Check for Updates」を実行してもなんら表示されないので,最新版は出てないままかと思っていましたが,上記問題への解決策がないかとプロジェクトのホームページを開いてみると,実はこの10月13日にバージョン 2.0.3 の最新版がリリースされていることが分かりました.前の 2.0.2 が 2018年7月27日だったため,2年ぶりの更新となります.

どうやってインストールするのかと調べてみた所,このページの Release に記載されているページ:

http://download.eclipse.org/texlipse/2.0.3/

を Eclipse の Install New Software のリポジトリに登録(Add)して,インストールすれば良いみたいですね.

実行した結果,無事に BibTeX Editor も動作するようになりました.


なお Eclipse 上のメニュー 「LaTeX」から「Force build」というのが選べて,前からこれを実行すると Eclipse がハングアップするという状況が発生してたのですが,それについては,変わってないみたいですね...





2020年11月20日金曜日

Ubuntu Server 20.04/Tomcat9でJenkinsインストール

Ubuntu Server 20.04 および Tomcat9 も動作し、GitBucket もインストールが完了したので、次のサーブレットとして Jenkins をインストールしようと思います。

Jenkins は Wikipedia の記載では、

Jenkins(ジェンキンス)はフリーでオープンソースの自動化サーバー

です。

イメージとしては、GitBucket に対してコミットしたファイル群から、様々な自動化処理を行ってくれるためのフレームワークといった所です。

Jenkinsのホームページから war ファイルがダウンロード可能で、同ファイルをデプロイすることで使用が可能です。

Jenkinsのインストール手順が書かれたページによると、

Jenkins can also be run as a servlet in different Java servlet containers such as Apache Tomcat or GlassFish. However, instructions for setting up these types of installations are beyond the scope of this chapter.

とのことで、一瞬、「ん?」と思えますが、手順は簡単なため、以下に手順として記載しておきます。

Jenkinsのサイトから war ファイルをダウンロード

これはそのまんまです。Jenkinsのダウンロードサイトからwarファイルをダウンロードします。なお Jenkins も LTS と最新の2種類が存在していますが、今回は LTS を使用することとします。現時点での最新版は Jenkins 2.249.3 LTS  みたいです。

なおどれが war ファイルのダウンロードなのか、少し分かりにくいです。ぱっと見た時、Ubuntu/Debian と書かれた所に目がいってしまいますが、左側の表の一番上の、少しごちゃごちゃと記載されているのが war ファイルとなります。なお左側がLTSを示しています。


tomcatサービスの停止

デプロイを安全に行うために一度tomcatを停止します。稼働させたままデプロイできるやもしれませんが、心配なので一旦停止します。

$ sudo systemctl stop tomcat9

tomcatのwebappにコピー

tomcatが停止したことを確認した後、tomcatのwebappフォルダにダウンロードしたwarファイルをコピーします。停止の確認は以下で可能です。ステータスが inactive であれば大丈夫です。

$ sudo systemctl status tomcat9

なおwebappフォルダは以下です。システム構成によっては違うかもしれませんが。

/var/lib/tomcat9/webapps

tomcatサービスの起動

warファイルをコピー後、tomcatを再稼働させます。これはstopと逆の操作です。

$ sudo systemctl start tomcat9

jenkinsへ1stアクセス

これで Jenkins のインストールが開始されます。無事に動作したかどうかは tomcat の manager 画面から確認出来ると思います。URLとしては、

http://localhost:8080/manager/html

とかになるかと思います(localhostの場合)。

ここでエラーなく Jenkins が稼働(Running が true)しているのを確認したら Jenkins のページにアクセスします。

http://localhost:8080/jenkins

ですね。

そうすると以下のUnlock画面が表示されます。


このページの意味は書かれている内容の通りですが、画面上に表示されている指定のファイルからパスワード文字列をコピーして入力欄に貼り付けて Continue です。

その後、無事に動作し、プラグインのインストール画面が表示されます。


水色で示されている Install suggested plugins をクリックします。


このように提案された各種プラグインのインストールが開始されます。

無事にインストールが終わるとFirst Admin User の登録画面が表示されます。


これで Save and Continue として進めると無事にJenkinsが開始されます。

webアプリケーションによるとは思いますが、いつもながら Jenkins のデプロイは楽ですね。開発者またユーザの皆様に感謝です。

実務側ではソフトウェアリポジトリへコミットされたソース群を Nightly で検証することをさせていますが、家のサーバですし、少し便利な使い方を考えてみたいと思います。

もしかしたら「それ、cronで出来るやん」という使い方だけで終わるかもしれませんが。。。

2020年11月19日木曜日

HomeServer / 気がつくと Gnome Desktop が...

 最近稼働中の HomeServer ですが、元々 Ubuntu Server 20.04 として GUI なし CUI ベースで導入していたのですが、今しがたリモートログインして top を見てみると、Xサーバが稼働していることに気づきました...

うーんです...

前に本サーバからメインの開発PCにリモートで色々とXアプリケーションをとばして表示させようとしていたのですが、その時、うっかりと導入してしまった模様です。

gnome-shellも動いてますね。

基本サーバマシンであり低消費電力で連続動作させたいってのがありますので、このデスクトップ環境は停めたいなと思いますね。

また、まだサーバの方、電力制御の設定を行っていないので、低電力化の設定としてまとめて次は行いたいと思います。

それを進めるには CPU のモードや BIOS 機能など、色々とハード側の確認が必要な気がしますので、そちらについては本ブログの兄弟であるハードウェア関係のブログ記事に書いていこうかと思います。

Ubuntu Server 20.04/Tomcat9/GitBucketでMySQL

前回の記事で Ubuntu Server 20.04/tomcat9上でGitBucketが動作する所までは対応しました。

GitBucketはデフォルトで H2 Database を使用しています。

開発元が公式に

「H2はデータの保全性に問題がありますので業務等の重要な用途にGitBucketを使われるのであればなるべくPostgreSQLもしくはMySQLを利用することが望ましいです(パフォーマンス面でもメリットがあります)」

と説明されていますので、今回、MySQLに変更することにしました。

なお前の Ubuntu 18.04 の時も MySQL を使用していました。基本的な内容は同じです。細かな部分については前の記事の方が詳しいので、そちらを参考にしてください。大枠としては 20.04/Tomcat9 での動作確認の意味でこちらの記事を参照してください。


MySQL を Ubuntu Server 20.04 の標準リポジトリからインストールすると、本記事作成時点では、バージョン 8.0.22 がインストールされます:

$ mysql --version
mysql  Ver 8.0.22-0ubuntu0.20.04.2 for Linux on x86_64 ((Ubuntu))
これを使うことにします。

GitBucket 側の設定方法は公式Wikiの External database configuration に説明が記載されています。

ほぼその通りにすれば出来るのですが、注意点としては、

  • mysqlのバージョンが8以上なので、上記ページ記載の MySQL8 以上への対応が必要
  • 説明されている grant all privileges on ... のコマンド一文が MySQL8 ではエラーとなるため、ユーザ作成と grant を別コマンドで実行

があるかなと思います。

無事に稼働すると、以下のように外部データベースで無事に接続出来ていることが確認出来ます。

色々とスムーズに導入できるので、開発者の方やこれまでの多くのユーザさんに感謝です。

これで信頼性を確保し導入が容易なGitリポジトリが実現出来ました。

あと気になる所はデータバックアップですね。

次はデータバックアップの設定を行いたいと思います。

ただバックアップからの復帰確認は、するかしないか、少し悩んでいます。

ちょっとした手間+リスクですしね。

そもそも自分ローカルのネットワーク内でどこでも作業可能とし、色々な開発リソースの置き場を一元化することを主目的に導入したものであるため、とりあえずバックアップが取れて、そこに必要なデータが入っていることが確認出来たら、それ以上は確認しないかもしれません。


2020年11月15日日曜日

Ubuntu Server 20.04/Tomcat9でGitBucketインストール

現在、Ubuntu 20.04 Server のサーバマシン上で Tomcat9 を動かしています。

なおJavaは OpenJDK 14 を使用しています。

サーバマシンのハードウェア詳細については、別のブログに記載しています(書きかけのため公開していない記事も多いので、色々と前後していますが)。 

同サーバ上で稼働させるサーバとしてはGitサーバとCMSサーバを予定しています。

両者共にJavaサーブレットとしての実現を考えており、まずはGitサーバとして以前から愛用している GitBucket を導入しました。

インストールの方、ざっくりとは同じやり方で問題ないかとは思いますが、ちょっとだけ Tomcat9 へのデプロイ時にエラーでごたごたしましたので、記録としてメモしておきます。

なお基本的なデプロイの方法についてはGitBucketのインストールページの「Deployment to JEE and Servlet containers」に紹介されていますが、Tomcat9 の所は ToDo となっています。

インストール時のごたごた、具体的にはデプロイに失敗する(falseとなる)はインストール手順どうこうというよりは、こちらのTomcat9 側の基本設定に依存する内容かな、と思いますので、参考までに情報を列挙する形で上げておきます。

  • Tomcat が使用する Java環境としては Ubuntu 20.04 Server の通常リポジトリから OpenJDK14 をインストール
  • Ubuntu 20.04 Server の通常リポジトリから Tomcat9 をインストール
  • インストールによりユーザ tomcat が自動生成されるが、ホームディレクトリが設定されていないため設定
    • /home/tomcat をmkdirし、/etc/passwdのtomcatユーザの設定箇所に /home/tomcat を追加
    • chown tomcat:tomcat /home/tomcat によりオーナを tomcat に
  • GitBucket のサイトから gitbucket.war をダウンロードし、Tomcat の管理画面 (TomcatのURL/manager/html )の「サーバ上のWARファイル又はディレクトリの配備」の[WARファイル又はディレクトリのURL:] でファイル位置を指定してデプロイ (配置)

です。

僕がミスしていた所は上記で chown を忘れ root アクセス権のままで、gitbucket をデプロイする際に同ディレクトリ下にファイル等を生成出来ないためでした。

これで無事に起動しました。tomcatの管理画面上ではこのようになっています。


また GitBucket 側の管理画面上ではこのようになっています。

上述のような素の設定下では GITBUCKET_HOME は自動的に /home/tomcat/.gitbucket となる模様です。

なおいつもデプロイ直後に「どうだったっけ?」と悩む管理者の初期情報ですが、GitBucketのページの Installation に記載されている以下の情報ですね。

  • Download the latest gitbucket.war from the releases page and run it by java -jar gitbucket.war.
  • Go to http://[hostname]:8080/ and log in with ID: root / Pass: root.
これで無事Gitサーバは起動しました。

次は上記の管理画面に記載されているデータベースの変更を行おうと思います。





2020年4月15日水曜日

Google Noto Fonts

家で仕事をする中でドキュメントを書くことが多いのですが、色々とフォントのことが気になります。

ちょっと Unicode 全般について勉強する必要も出てきてて、出来るだけ多くの文字が、豆腐文字になることなく表示できるフォントを探してます。

そのまさに「NO more TOfu」となるフォントがGoogle Noto Fontsの様です。

この Google Noto Fonts をメインマシン(Ubuntu 18.04)に入れてみようと思います。

Google Noto Fonts の入手

Google Noto Fonts は以下のサイトから入手可能です。

Google Noto Fonts/Beautiful and free fonts for all languages

ページ上の [DOWNLOAD ALL FONTS] ボタンをクリックするとダウンロードが始まります。

ダウンロードボタンの下に書いてある通り1.1GBもあるフォントセットです。

Google Noto Fonts のインストール

インストールは上記ページの[Install]の所の説明の通りです。

How to install fonts

Windows/macOS/Linuxでのインストール方法の説明がのっています。

僕は Ubuntu18.04 なので Linux インストールなのですが、「for a single user」か「for all users」かの選択肢があります。

どちらにしようか悩みましたが「for all users」にしておこうかと思います。

その手順は以下の様です。

# for all users
sudo mkdir -p /usr/share/fonts/opentype/noto
sudo cp *otf *otc /usr/share/fonts/opentype/noto
sudo fc-cache -f -v # optional

ちょっと2つ目のコマンドが正常動作しないので、以下としました。

sudo cp *.otf  /usr/share/fonts/opentype/noto

そして fc-cache をして終了です。

notoフォントとして 137フォント が取り込まれてますね。

/usr/share/fonts/opentype/noto: caching, new cache contents: 137 fonts, 0 dirs

2020年4月13日月曜日

TeX Live 2020 での LuaLatex エンジン

前の記事 で、TeX Live 2020 は 2019 から対して変わってないのでは、みたいなことを書きましたが、 ちょっと使ってみて、それなりに大きな違いが発生していることに気が付きました。

僕はpdfの直接的な生成を考えて LuaLatex を、Eclipse上のTeXLipseで使っています。

TeXLipse上での実行時にコンソールに表示される最初のメッセージは、これまで、

running: /usr/local/texlive/2019/bin/x86_64-linux/lualatex -synctex=1 -interaction=nonstopmode document.tex 
lualatex> This is LuaTeX, Version 1.10.0 (TeX Live 2019) 

だったのですが、TeX Live 2020 に変えると、

running: /usr/local/texlive/2020/bin/x86_64-linux/lualatex -synctex=1 -interaction=nonstopmode document.tex 
lualatex> This is LuaHBTeX, Version 1.12.0 (TeX Live 2020) 

となっていることに気が付きました。

これまではLuaTeXベースだったのが TeX Live 2020 からは LuaHBTeXベースになったのですね。

LuaHBTeXは前にLuaTeXについて調べた時に存在は知っていたのですが、HarfBuzzライブラリを組み込んだLuaTeXのことみたいです。

HarfBuzzライブラリとは、フリーのOpenTypeテキストシェーピングエンジン(フォントレンダリングエンジン)みたいです。

ここが開発元で Android, Chrome, ChromeOS, Firefox, OpenJDK, Qt 等にも使われているみたいです。

TeX Live 2020 から変更されたことの情報源を探していたのですが、 LATEX News/Issue 31, February 2020 に記載がありました。

Concerning this release . . . (LuaLATEX engine) The new LuaHBTEX engine is LuaTEX with an embedded HarfBuzz library. HarfBuzz can be used by setting a suitable renderer in the font declaration. A basic interface for that is provided by fontspec. This additional font renderer will greatly improve the shaping of various scripts when using LuaLATEX, many of which are currently handled correctly only by X TEEX, which always uses HarfBuzz. To simplify testing of the new engine, binaries have already been added to MiKTEX and TEX Live 2019 and both distributions have already now changed the LuaLATEX-dev format to use it. Going forward, LuaLATEX (and LuaLATEX-dev) will both use the LuaHBTEX engine. The timing of the switch to the LuaHBTEX engine depends on the distribution you use (for TEX Live this will be with TEX Live 2020).

とのことです。

TeX Live 2020 のインストール

TeX Live 2020 がリリースされました。

TeX Liveは常時updateされているため、2020リリースの目玉となる特徴とかあるのか分かりませんが、 既にTeX Live 2019でのupdateが止まっているため、2020を入れてみようと思います。

プラットフォームはいつもながらの Ubuntu 18.04 です。

TeX Live 2020 のインストール

リリースの ダウンロードページ から install-tl-unx.tar.gz をダウンロードし、tar.gz を展開して出来る install-tl を実行することで、後は自動的にインストールされます。

sudo ./install-tl 
Loading http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet/tlpkg/texlive.tlpdb
Installing TeX Live 2020 from: http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet (verified)
Platform: x86_64-linux => 'GNU/Linux on x86_64'
Distribution: net  (downloading)
Using URL: http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet
Directory for temporary files: /tmp/aiomRbLkQx

======================> TeX Live installation procedure <=====================

======>   Letters/digits in <angle brackets> indicate   <=======
======>   menu items for actions or customizations      <=======

 Detected platform: GNU/Linux on x86_64
 
 <B> set binary platforms: 1 out of 16

 <S> set installation scheme: scheme-full

 <C> set installation collections:
     40 collections out of 41, disk space required: 6524 MB

 <D> set directories:
   TEXDIR (the main TeX directory):
     /usr/local/texlive/2020
   TEXMFLOCAL (directory for site-wide local files):
     /usr/local/texlive/texmf-local
   TEXMFSYSVAR (directory for variable and automatically generated data):
     /usr/local/texlive/2020/texmf-var
   TEXMFSYSCONFIG (directory for local config):
     /usr/local/texlive/2020/texmf-config
   TEXMFVAR (personal directory for variable and automatically generated data):
     ~/.texlive2020/texmf-var
   TEXMFCONFIG (personal directory for local config):
     ~/.texlive2020/texmf-config
   TEXMFHOME (directory for user-specific files):
     ~/texmf

 <O> options:
   [ ] use letter size instead of A4 by default
   [X] allow execution of restricted list of programs via \write18
   [X] create all format files
   [X] install macro/font doc tree
   [X] install macro/font source tree
   [ ] create symlinks to standard directories

 <V> set up for portable installation

Actions:
 <I> start installation to hard disk
 <P> save installation profile to 'texlive.profile' and exit
 <H> help
 <Q> quit

TeX Liveはパッケージ数が多いので、ダウンロード・インストール完了まで結構時間がかかります。

実際、3986パッケージのダウンロードにほぼ1時間かかりました。

ダウンロードサイトの帯域が狭い気はしますが、通常のupdate時も相応の時間がかかるので、最近はあまり気にしていません。

ざっと下のような感じでした。

Installing [3981/3986, time/total: 01:04:20/01:04:22]: zref [684k]
Installing [3982/3986, time/total: 01:04:21/01:04:22]: zwgetfdate [242k]
Installing [3983/3986, time/total: 01:04:21/01:04:22]: zwpagelayout [630k]
Installing [3984/3986, time/total: 01:04:22/01:04:22]: zxjafbfont [3k]
Installing [3985/3986, time/total: 01:04:23/01:04:23]: zxjafont [181k]
Installing [3986/3986, time/total: 01:04:23/01:04:23]: zxjatype [144k]

インストール後のファイルサイズはざっと7GBほどみたいですね。 インストール後に一度、既存のTeXドキュメントを lualatex でビルドしたので、 もしかしたらその際に生成されたファイルも含めてなのかもしれませんが、そのぐらいのサイズは必要となる模様です。

$ du -s /usr/local/texlive/2020/
6927572 /usr/local/texlive/2020/

2020年4月12日日曜日

Ubuntu 18.04 での POCO C++ Libraries 構築 (1)

POCO C++ Libraries

POCO C++ Libraries とは C++ ベースでのネットワークアプリケーションやインターネットアプリケーションを開発するためのオープンソースのクロスプラットフォームライブラリです。以下のサイトで公開されています(画像をクリックすると開発元のホームページにジャンプします):

デスクトップやサーバ、IoTデバイスや組込みシステムまでの適用が想定されているライブラリであり、 Boost Software License として公開されています。

その特徴は開発元の 「Features」 に示されています。

国内ではサイト「POCO Fanatic」 に色々と詳しい情報が掲載されています。

2018年以降は更新されてないみたいで、POCOのv1.8.1までの話しがのっています。

なお POCO の最新バージョンは 1.10.1 (2020-02-10) みたいです。

今回、ちょっと作りたいものがあって C++ での webフレームワークみたいなのを探していたのですが、 この POCO がひっかかりまして、少し試してみたいと思っています。

Ubuntu 18.04 でのライブラリ構築

僕の開発用メインマシンは Ubuntu 18.04 なので、その上での開発環境整備を進めたく思います。

POCOのダウンロードページ に行くとダウンロード情報が載っていますが、今回は、 COMPLETE EDITION (全てのライブラリが含まれているが外部ライブラリとして OpenSSL, MySQLクライアント, ODBCライブラリが必要) で進めてみようと思います。

まずは同ページにある poco-1.10.1-all.tar.gz をダウンロードして展開します。

そこに README ファイルがあり、そこにインストール方法が書かれています。

Linux では cmake でのインストールか configure でのインストールとの 2者があるみたいです。

今回は Windows 上でもビルドが可能である cmake で試してみようと思います。

Ubuntu 18.04 での cmake ビルド

READMEファイル上の記載では以下のように進めるとのことです。

1. create a cmake-build directory (e.g. in the POCO root directory):
$ mkdir cmake-build

2. and run CMake from there:
$ cd cmake-build
$ cmake ..
$ make -s -j (or build the generated Visual Studio solution on Windows)

今回はこの通りにすすめてみようと思います。

cmake ..の所までは進めたのですが、そこで以下のメッセージが表示されていました:

-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR 
(missing: OPENSSL_CRYPTO_LIBRARY OPENSSL_INCLUDE_DIR) 
-- Could NOT find APR (missing: APR_INCLUDE_DIR APR_LIBRARY) 
-- Could NOT find APRUTIL (missing: APRUTIL_INCLUDE_DIR APRUTIL_LIBRARY) 
-- Could NOT find Apache2 (missing: APACHE2_INCLUDE_DIR) 
-- Could NOT find MYSQL (missing: MYSQL_INCLUDE_DIR MYSQL_LIBRARY) 
-- Could NOT find PostgreSQL (missing: PostgreSQL_LIBRARY PostgreSQL_INCLUDE_DIR) 
-- Could NOT find ODBC (missing: ODBC_LIBRARY ODBC_INCLUDE_DIR) 

開発マシンとして色々と開発用ライブラリは入れてきましたが、まだまだ入っていないものが多いのですね。。。

ざっとネットで検索して以下のパッケージを追加でインストールしました。わかり易く apt install での インストールパッケージ表現で記載しておきます。

    sudo apt install openssl-dev libssl-dev libapr1-dev libaprutil1-dev apache2-dev libmysqlclient-dev libpq-dev unixodbc-dev

これで cmake を無事に通りました。その時の表示を参考までに以下に掲載しておきます。

~/POCO/poco-1.10.1-all/cmake-build$ cmake ..
-- Checking for C++14 compiler
-- Checking for C++14 compiler - available
-- Found ODBC: /usr/lib/x86_64-linux-gnu/libodbc.so  
-- Building without tests & samples
-- Using internal sqlite, zlib, pcre, expat, ...
-- SQLite Support Enabled
-- MySQL Support Disabled
-- PostgreSQL Support Disabled
-- ODBC Support Disabled
-- CMake 3.10.2 successfully configured Poco using Unix Makefiles generator
-- Poco package version: 1.10.1
-- Building dynamic libraries
-- [cmake] Installation target path: /usr/local
-- [cmake] Bulid for OS type:  Linux
-- [cmake] Build for OS version: 5.3.0-46-generic
-- [cmake] Build for CPU type:  x86_64
-- [cmake] Build type:    RelWithDebInfo
-- [cmake] Build with cxx flags: -O2 -g -DNDEBUG 
-- [cmake] Build with c flags:  -O2 -g -DNDEBUG 
-- Building: Encodings
-- Building: XML
-- Building: JSON
-- Building: Util
-- Building: Net
-- Building: MongoDB
-- Building: Redis
-- Building: Data
-- Building: Zip
-- Building: PageCompiler
-- Building: File2Page
-- Configuring done
-- Generating done
-- Build files have been written to: ~/POCO/poco-1.10.1-all/cmake-build

無事に cmake が通ったので make でビルドを行わせました。

make の -j オプションということもありますが、途中、結構メモリを使用するみたいです。

途中の様子は以下のパフォーマンスモニタの通りです。

途中でメモリ使用量が30%から90%まで一気に増えていきました。

開発マシンのメモリ搭載量は16GBで、その60%を使うみたいなので、さっくりと10GBぐらいはメモリを消費する形でしょうか。

ただ、そのぐらいまでは一気にメモリを使いますが、それ以降は一つずつライブラリのビルドが行われていましたので、 メモリ使用量は増えず、数分程度でエラーなくビルドが完了しました。


これで無事にライブラリが生成出来たようなので次回は色々と使って試してみるのと、ライブラリの内部調査もしてみようかと思います。

それで現在作ろうとしているものに使えそうと判断したら、少しずつその開発を進めたく思います。

2020年3月17日火曜日

TeX Live 2020

自分は TeX Live 使いでして、主に Ubuntu 18.04 上で個別に TeX Live 2019 を入れて使っています。
update は適宜 tlmgr を使って手動で実施しているのですが、昨夜、update しようとして全くアップデートがないことに気づき、同時に以下のメッセージに気づきました:

TeX Live 2019 is frozen forever and will no
longer be updated.  This happens in preparation for a new release.

カレンダーイヤー毎でフリーズする有意性は把握出来ていませんし、リポジトリの指定等で継続的なアップデートが出来るのかもしれませんが、TeX Live のホームページ上に以下のリリーススケジュールが記載されていることが分かりました。なお日付の表示はわかり易く変更しています:

Plan for TeX Live 2020:
2月15日: candidate/final sources committed, test builds begin.
2月28日: tlnet (and TL'19) frozen, tlpretest starts, CTAN updates continue there.
3月15日: code freeze for final build, major bug fixes only.
3月22日: final updates from CTAN, final doc tweaks.
3月29日: deliver TL image for TeX Collection packaging/testing.
4月5日: deliver TeX Collection DVD image for manufacturing.
4月10日: public release (also of MacTeX).
6月?: delivery of DVDs to members.

これを見るとカレンダーイヤーよりファイナンシャルイヤー(年度)のリリースと思った方が良さそうですね。
年度が変わる頃までには、TeX Live 2020 を新たにインストールするのか、TeX Live 2019 を継続的にアップデートし続ける方法があるのか、調べておきたく思います。


GNU Emacs for Windows における最近の IMEパッチ問題

自分は GNU Emacs 使いなのですが、Windows版の Emacs を使用する場合、IMEパッチの問題がありました。 ざっくり言うと、FSFの正規のリリースバイナリだと日本語変換のIMEに切り替えた時、インラインで候補文字が表示されないという問題です。そのために有志の方々...