自己顕示欲の開放治療所

erg, programming and something.

別名:Laughing and Grief 雑記

Latin and Greekは習ったこともない

真面目な記事の他、特定の方には不快と思われる事柄に関して言及を行うことがあります。ちょっと頑張りますが、Blog内で解決できなかった場合要望があれば別ページに技術記事は書き直します

EWB Licenseニアリィイコール3条項BSD

この記事はEWBアドベントカレンダー2019の16日目の記事です。

adventar.org

前回のEWBライブ

binディレクトリに入ってるやつの中に実行用バイナリでないツールが結構入っていることが発覚。

EWB LICENSE

web.archive.org

Copyright (C) 1986, 1999 ASCII Corporation.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.
3. Neither the name of the author may be used to endorse or promote products
   derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

EWBの頒布規約は大体3条項BSDになります。上のアーカイブに記載された日本語訳を掲載しますと、

【著作権表示】
Copyright (C) 1986, 1999 ASCII Corporation.
All rights reserved.

【契約条件】
改変の有無にかかわらず、本ソフトウェアのソースコード及びバイナリーコー
ド形式による再頒布及び使用は、次の契約条件の下に許諾される。
1. ソースコードの再頒布に際しては、上記の【著作権表示】、この【契約条
   件】及び次の【免責条項】の表記を、引き続き維持して明記しなければな
   らない。
2. バイナリー形式による再頒布に際しては、上記の【著作権表示】、この
   【契約条件】及び次の【免責条項】を、再頒布に際し提供する説明書及び
   その他の関連資料に改めて明記しなければならない。
3. 特別な事前の書面による許諾がない限り、本ソフトウェアから派生した製
   品を推奨又は宣伝するために、著作権者名は使用してはならない。

【免責条項】
本ソフトウェアは、著作権者により、「現状有姿のまま(そのままの形で)」
提供されるものであり、商品性又は特定目的への適合性に関する黙示的保証な
ど、明示又は黙示の保証を問わず、いかなる保証をも行うものではない。
いかなる理由によっても、また、契約責任、厳格責任又は(過失によるものを
含む)不法行為責任を問わずどのような責任の理論によっても、著作権者は、
いかなる場合も、本ソフトウェアを使用することにより発生する、あらゆる直
接損害、間接損害、偶発損害、特別損害、懲罰的損害あるいは派生的損害(代
替製品・代替サービスの調達、使用利益、データ又は収益に関する損失、営業
中断による損失など)について何らの責任も負わない。これは、本ソフトウェ
アを使用することにより、これらの損害が発生する可能性について、あらかじ
め示唆されていた場合であっても同様である。

ということで、GitHub上に上のライセンスを表示しながら配置するのはセーフのはず。

github.com

ででーん! ちょこちょこ足します。

実はEWB3.2リリースと3.3のリリースタイミングで頒布のライセンスが変わったとの履歴があるんですが、それ以前のライセンスが分からないんですね。 3条項BSD自体は1999年に登場していますし、コピーライトの表記年はEWB3の登場時の固定っぽいんですよね。

それと、よく見る最近のBSDだとクオーテーションマークが""ですが、バッククオート2つとシングルクオート2つのLaTeXでよしなにしてくれるやつになってます。

pTeXのライセンス

同じくアスキー社の開発であるp\TeX{}のライセンスを確認してみましょう。

github.com

こちらはtexjporgによって管理されている歴史資料になります。

COPYRIGHTを見ると、こちらも3条項BSDですね。表記年と著作者表記は2009年アスキー・メディアワークスになっていますが。

分かったのはツール群大体そのまま読めるスクリプトってことだけ

この記事はEWBアドベントカレンダー2019の15日目の記事です。 技術書典の当落によって残りの10日のやる気がかわりそう。

adventar.org

進捗

新しめのFreeBSDに古いパッケージを入れて動くか試すのは「失敗」です。予定通りですね。 そもそも、互換が用意されてるとはいえ32bit時代のパッケージ群を64bit用OSに入れるときは色々考えるべきですね。

収穫は一応ありまして、

EWB-Shelfといったコアなものではなく、ツール群で軽量なものはそのまま読めるシェルスクリプトPerlスクリプトであることが分かりました。

GUIを開く」とあるツールのスクリプトを開くとwishでファイルを開くのに味付けをする程度あったり、tounixPerlスクリプトだったりといった具合です。 現代化、意外と困難でもないかもしれない

バイナリ以外のツールはここに追記していく予定。

あ、GUIツールの中にはEmacsLispを呼ぶものも確認できました。XEmacsでは確かにそうなるやね。

ToDo

大人しくDVD付属のイメージから実行環境を用意します。

FreeBSDに解凍したEWBを入れた(入れたのか?)

この記事はEWBアドベントカレンダー2019の14日目の記事です。

adventar.org

これから電車移動で1時間以上吸われるのに何も進んでいないのですが。

前回FreeBSDをインストールしたので、先ずはEWBのパッケージが入ったDVDをFreeBSD側に認識させます。

VirtualBoxに認識させたディスクをマウントする

今回は雑に/mediaにぶちこみました。devの名前今回はエスパーで検討つけたんですが VirtualBox側で変更できるんですかね。何もわからん。

# mount -t cd9660 /dev/cd0 /media

で、/media/Packages/*を全部/home/ewb(作成したユーザ名)以下にmvでドーン。

これで実質インストール完了といえなくもない(いえない)。

帰りの電車でこれをなんやかんやして起動できるか試します。

GCP無料枠でZerotierVPNを立てる

この記事はWORDIANアドベントカレンダー2019の14日目の記事になります。

adventar.org

今日は自分を編集部員だと思いこんでいるので……。

TL;DR;

Google Cloud Platformには「金を払うと無料」、もといクレカ登録すると使える「無料枠」という概念があります。

この無料枠内で使える構成でVMインスタンスを立てることができ、ここにVPNサーバを立ててみようという話です。

OpenVPNなどについては先例があり、

sorapoo.hatenablog.com

のように構築しています。

今回は一般に馴染みが薄いであろう、「ZeroTierVPN」をここに立ててみましょう。

ZeroTierVPN

www.zerotier.com

ZeroTier VPNは独自のアドレス空間によって管理する、様々なプラットフォームに対応したVPNソフトウェアとサーバです。 アカウントを作成したら無料で100個までアカウントにマシンを割り当てられ、簡単にVPNを構築できるのが特徴です。ただし、自前サーバでアカウント管理部分(controller)までやろうとするとその限りでない。

手順(GCP

上のリンク先などに既にある通りなので、要約すると

  1. アカウント登録
  2. カード登録
  3. マシンをf1-micro
  4. ディスクを30GBに拡張
  5. CentOS8で作成

で、作ったらIPの固定をしてssh鍵の登録をしたら完了です。

Zerotier-One

本来なら「myzerotier.comにアカウントを登録して〜」で終了しますが、 controllerを自分の手で管理したいとなるとそうはいきません。 自分で管理する気がなければそもそもGCP使う必要もないです。ローカルとリモートにzerotier-oneを入れてドキュメントをなぞりましょう。

建てたVMに入り、gitを入れ、

git cloneして、Ubuntuでいうところの build-essential などを入れます。

ところで、f1-microのメモリは600MBそこらです。ちょっと大きくなったC++プログラムなんかはビルドがメモリ不足で失敗します。

令和の時代にswapファイル作るのが有効な案件に出会うとは思ってもみませんでした。 なお、後程「ローカルの仮想環境でビルドして持ち込めばよかったのでは」と突っこまれるなど。

controllerのビルドにはそれ以外に、postgresとそのdev、RabbitMQ用にErlangとRabbitMQを入れる必要があります。sqlite3で代用できる?ようですが、更に複雑化しそうだったのでスルー。

ビルドが終わったら./zerotier-one -d で起動すると、controllerにアクセスできるようになります。CurlでGETとPOSTをすると簡単に値の確認ができますが、 通常/var/lib/zerotier-one以下に生えるはずのauthtoken.secretの値をクエリに?auth= で入れる必要があるので確認しておきましょう。

このとき、

curl -X GET "ZT-Auth" http://localhost:9993/controller?auth=xxxxxxxxxxx

のように叩きます。

github.com

この辺りは追記予定。

クライアント(local machine)

実はsnapで入るよzerotier-one。サーバ(controller)側のサポートはCentOS7なんで (サポートするとはいっていない)、VM上で態々ビルドしたワケですが。 注意点としては、snapで入れると、ZEROTIER_HOMEのパスが通常のビルドと違う場所になるので、snapのvar内の該当箇所にexportしてやる必要があります。 Ubuntu18.04だと /var/snap/zerotier-one/common ですね。

さあ、zerotier-one.zerotier-one -dで起動を、しないんだなこれが/snap/zerotier-one/current/command-zerotier-one.wrapperにある PATH の場所にzerotier-oneの実行ファイルが無かったのでln -sして/snap/zerotier-one/current/usr/zerotier-one`に繋ぎます。

挫折

あの、サーバの zerotier-oneをローカルホスト以外に割り当てて起動する方法が分からないのですが!

年明けなど、落ち着いた時期に更新したい。

何もしてないがとりあえずFreeBSDを用意した

この記事はEWB アドベントカレンダー2019の13日目の記事です。

adventar.org

なんだったらアウトライン以上の内容がないです。

そわそわとメールを待っていたり、 アパレルメーカーOVERDRIVEがブランド最終ゲーム作品として制作した「MUSICUS!」が 自宅に到着してしまうなどすると人は作業ができないことで知られている。ゲームの方は一般発売日まで寝かせておくつもりですが。できればもっと感情がフラットになるまで 寝かせたいんですが、絶対期間限定のホニャララとか忘れるんで。 ゲームを応援したら何故かついてきた2017年のライブのBDは計4時間超えある。物販とかも含めるとあの日あの時あの会場何時間いたんだろうね。

EWBの実行環境であるFreeBSD

以前に触れた気もしますが、EWB自体はUnix Like環境なら動く筈ですが、手元にあるのがソースコードではなくFreeBSD用バイナリなんで、FreeBSDを叩く必要が今私にはあります。 DebianJPにアーカイブ所持者がいるのではというご意見をもらいごもっともと思いましたが、先ずはこちらで試してみたいと思います。

www.freebsd.org

FreeBSD は、最新のサーバ、デスクトップおよび組み込み プラットフォーム 用のオペレーティングシステムです。 多くの コミュニティ が 30 年以上にも渡って開発を続けています。

ということで、配布サイトからディスクのisoをダウンロードし、準備します。例のDVDに動作確認されたバージョン(4.7)のイメージが付いてたんですが、まあパッケージ群は別ディレクトリに収まってるし 動くなら新しいOSの方がええはずや!と新しめのstable(12.0)をダウンロード。そして後悔するまでが1セット。後悔は明日やります。

ローカルではVirtualBoxを準備します。LXDで動いたら楽なのになあ。コンテナでは無いんで致し方無し。

ところで何でfreebsd.orgの日本語版サイト、ゲタをこんなに使ってるんでしょうね。

Done

  • Virtual Boxで仮想環境を用意してFreeBSDをインストール
  • sudoをインストール
  • EWB+VMWAREのDVDをマウント
  • 解凍しないパッケージのアタリをつける(xemacs, kakasiなど)

ToDo

  • 全て

NEXT

EWB-Shelfを動かすところまでやりたい。やるとはいっていない。

EWBとRe:VIEW 記法編

この記事はEWBアドベントカレンダー2019の12日目の記事です。

adventar.org

昨日は記法以外の違いをみたので、今日は記法編です。 全部を紹介するのは面倒臭いのでRe:VIEWの公式やEWBハンドブックに任せるとして、 比較して楽しい箇所をみていきます。

Re:VIEWはEWBの他にもRD記法やwiki記法の影響を受けた、とあるので一部他記法も参考に載せます。 記法が同じ他の言語もあるかもしれませんが、キリが無いので別の機会にそういう話はやりたいですね。

ブロックの記法

EWB

//<トリガ名>{
...
//}

Re:VIEW

//<ブロック名>[<オプション>]{

...
//}

EWBの方は短縮記法ですが、ほぼ一致しますね。

内部要素を持たないブロック

EWB

//<トリガ名> <引数>

Re:VIEW

//<ブロック名>[<オプション引数>]

同じといえば同じですが、オプションがある場合見た目に差が出てきます。 比較するとEWBの方がマークアップというより関数に引数を渡してる感があるような。

インライン

EWB

範囲を指定するグループトリガというケースに含まれ、記法自体は基本的にブロックのときと 同じです。指定されたトリガ毎にブロック扱いされたりインライン扱いされたりするので、基本はトリガを把握しておく必要があります(それはそう)。

...//<トリガ名>{... //}...

Re:VIEW

...@<インライン名>{...}...

私は最初このブロックとインラインの書式の違いがEWBから引き継いだものだと思ってました。

見出し

見出しの番号についてはプレフィクス// のないchapter のようなトリガで番号を指定します。

EWB

//iii 見出し

Re:VIEW

=== 見出し

RDoc

=== 見出し

EWBだとナンバリングが分かりやすい一方で、数字的意味が強いので番号無しのセクションが切りにくい気がします。

小組み

EWB

Re:VIEWとの対応でここだけ閉じタグがフルの記法です。

//c1{
...
//c1}

Re:VIEW

===[column]


===[/column]

//<note/memo/tip/info/warning/important/caution/notice>{
    
//}

EWBの方は数値が入るトリガがでてくるので、単純な記法だけで見ると 気持ち良くないかもしれません。Re:VIEWではヘディングというかセクショニングの 仲間であるというように見えますね。いや、それはコラムだけで、囲み記事は下のブロック記法なんで 実質EWBです。

箇条書き

EWB

//k1{
・ hoge
・ fuga
//}

//k1{
(1.) hoge
(2.) fuga
//}

Re:VIEW

 * hoge
 * fuga

 1. hoge
 2.fuga

Bullet Listはどちらもネストした箇条書き可能ですが、 Re:VIEWは番号付き箇条書きはネストできなかったりします。

EWBの方は「ネスト可能」と対応表にはあるのですが例が無かったため載せていません。 説明を読む限りは\LaTeX{}やHTMLのそれに近い書き方のようですが。

Description

Re:VIEW

 : <DT>
     <DD>

RDoc

:<DT>
  <DD>

EWBではDL相当のものはない、というか表を使っているようです。調べ不足かもしれませんが。

LaTeX直書き

EWB

//LaTeX{
...
//}

Re:VIEW

//raw[|latex|...]

//embed[latex]{
...
//}

組版トリガ的な記法の分離はどちらかというとRe:VIEWにおいてはプリプロセッサ記法が対応します。 \LaTeX{}の直書きなどを行えるraw embedはEWBにおける編集トリガに近い文脈の流れということですね、多分。

組版トリガ

EWB

@@<トリガ>(<引数>)


@@<トリガ>(<引数>)
...
@@end

Re:VIEWプリプロセッサ

#@<プリプロセス処理名>()


#@<プリプロセス処理名>{
...
#@end

この対応は個人的なものなので、開発者的な立ち位置は不明ですが、 文章と異なる処理のマークアップなのでこうなんじゃないかな。


他にもテーブルが基本的にタブ区切りな部分なども共通点といえばそうですね。

Next

不安で不安で記事が手につかない。

EWBとRe:VIEW

この記事はEWBアドベントカレンダー2019の記事です。

adventar.org

2019年12月11日23時30分追記:

該当箇所を修正しました。ついでに出力について、EWBは印刷前チェックの目的もありましたね。

Re:VIEW

Re:VIEWは青木峰郎氏によって開発され、現在@kmuto氏によって 保守・開発されている、Ruby製の書籍用マークアップとその処理系です。

Re:VIEW公式に言及されているように、EWBにその源流があり、それは書式の他の点にも見ることができます。

というわけで、今日はファイル構成とドキュメント以外の書式比較について言及します。 Re:VIEWのバージョンは4系、EWBのバージョンは3.3のものを基準とします。

ディレクトリ構成

一般的と思われる構成です。

EWB

lsttblの中身はEWBフォーマットのプレーンテキスト。.ewbにもできます。 docもEWBドキュメントであることを示すだけでMSWordではないです。 基本的にeucjpエンコーディングです。

ドキュメントは同じ箇所にまとめて配置し、画像やリスト(ソースコード)などはまとめてそれぞれのディレクトリに配置しています。これらの配置位置を マップするのがdatなどに書かれた情報になります。

バックエンドは\LaTeX{}一択、\LaTeX{}文書用のクラスなどコマンドにより都度生成されるので、処理時に別の場所に置いてあるewbbase3_3.styなどを呼ぶものの、基本的に ディレクトリ構造がシンプルですね。

Styles内のファイルは基本的に各体裁用エディタ(フォーム)の出力datから生成されます。

読み込むファイルと順序などの記載されたcontents.ewbはEWB-Shelfで生成するのが恐らく基本的な方法でしょう。

root/
┣FIG/
┃  ┗*.eps
┣LIST/
┃   ┗*.lst
┣Styles/
┃     ┗triger.def //マークアップ挙動記述
┃     ┗PDFStyle //PDF出力用設定ファイル
┃     ┗*.sty
┃     ┗*.cls
┃     ┗yakumono.sed //実質的pre(post) process
┃    ┗ewb2latex.cls //基本LaTeX体裁
┣TABLE/
┃    ┗*.tbl
┝ForAll.index //索引登録ファイル
┝ForAll.phy  //図表登録ファイル
┝MENTUKEinfo //面付出力用設定ファイル
┝PDFinfo 
┝common.dat //他メタデータ
┝psidxested.dat //索引体裁
┝pssted.dat //体裁
┝contents.ewb //処理ファイル登録ファイル
┝*.doc
┝*.doc
┝ ...

Re:VIEW

root/
┣layouts/
┃  ┗<出力形式ごと>.erb //(rubyテンプレート)
┃    
┣lib/
┃   ┗*.rb //rake用補助ファイルその他
┣sty/
┃     ┗*.sty //TeX用体裁補助ファイル
┣Rakefile/
┃    ┗*.rb
┣images/
┃     ┗*.* // 画像ファイル
┣doc/
┃     ┗* // usage
┝style.css //html用体裁ファイル
┝catalog.yml //処理ファイル登録ファイル
┝config.yml //メタデータ、一部体裁記述ファイル
┝*.re
┝*.re
┝ ...

catalog.ymlがcontents.ewb相当になりますが、YAML形式なのと、 体裁のマッピングはlayouts内のテンプレートとconfig.ymlにあるので かなり見た目がすっきりします。比較は明日の気力次第。

config.ymlも

また、\LaTeX{}出力のスタイルに関しては、 現代的な\LaTeX{}の使い方らしく、各場面に合わせた出力に関してもクラスファイルが担い、 必要に応じてスタイルファイルを足したりする形なので、やろうと思わなければ体裁系のファイル群は爆発しません。 EWBがp\LaTeX{}と周辺の過渡期のものであるという歴史を踏まえる必要がありますが。

また、ビルド用ツールの設定がデフォルトで用意されていることで、個別コマンドで出力を調えていくコストが下がっているのも現代的ツールの特徴といえるでしょう。

体裁入力ツール

EWBのややインタラクティブな体裁入力エディタ(pssted)は長年Re:VIEWには無いものでしたが、Re:VIEW4からは ブラウザで見られる体裁入力画面が使えます! すごい! えらい!*1

出力

これを比較と書くべきか分かりませんが、フォーマットの面で触れるであろう事項なので。 EWBはプリンタレディな出力予想とPostScript出力を得るのが目的であり、(少なくとも現在の)Re:VIEWはもう少し汎用的あるいは前段階の出力を意図しています、多分。このことは組版マークアップ入力書式において、意図していたかはおいておいて、両者の違いに表れてきます。

Next

内部フォーマットと体裁フォーマットの比較を、折れていなかったら。