Gauche-gl
実りの秋の田畑を歩いていると、
実る程 頭を垂れる 稲穂かな
なんて言う農民の句を思い出しましたよ。これが、都会の人だと
落ちる程 頭を垂れる ミズホかな
なんでしょうな。ふと、葡萄の取入れをやってるおじさんに出会った。はちきれそうなやつ。ニコニコ顔してます。苦労が実った、葡萄が実ったでホクホクです。
おじさんに聞いてみた。今はシャインマスカットが流行ってますけど、こちらは、それに転作しないんですかって、ね。苗からだと、実を付けるまで三年かかる。そんな先の事は判らんとな。
そうですか、流行に追従するって言っても、そんな遅延があるんじゃ、おいそれといかないね。 もっと新しい品種って言っても博打の要素があるから、大変だ。
一房、1000円以上って、オイラーからすれば異常な価格だと思うぞ。とか言いながら、女房は、どこから仕入れてきたか、３種混合の色あざやかな、葡萄を盛合せて食べていますよ。
実家の裏のりんご畑が潰されて、ぶどう棚になったから、実を付け初めたのかな？
scp -d -t Downloads
よそのマシンからscpを使ってファイルを送り付けている時、受信側では、どんなプロセスが対応してるの？
1275 ? Ss 0:00 scp -d -t Downloads
これが、その答だ。-dってオプションは何？ -t は、何となく受信側のdirなんで、ターゲットって意味だろうね。両者共、manには言及されていない。
sakae@deb:~$ pstree
systemd─┬─avahi-autoipd───avahi-autoipd
├─sshd─┬─sshd───sshd───bash───tmux: client
│ └─sshd───sshd───scp
├─systemd-timesyn───{systemd-timesyn}
:
少し知恵を働かせて、scpの親分を確認すると、sshdって当然のごとくなってる。って事は、-dは、一時的なダエモン君ですよって印かな。 対比でFreeBSDでも確認しとく。
| \-+= 04586 root sshd: sakae [priv] (sshd) | \-+- 04589 sakae sshd: sakae@notty (sshd) | \--= 04590 sakae scp -t /tmp
ついでなんで、OpenBSDでも。各社各様で面白い。
|-+= 89423 root sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups (sshd) | |-+= 99304 root sshd: sakae [priv] (sshd) | | \-+- 78932 sakae sshd: sakae@notty (sshd) | | \-+= 56532 sakae ksh -c scp -r -t . | | \--- 35322 sakae scp -r -t . | \-+= 68104 root sshd: sakae [priv] (sshd) | \-+- 67598 sakae sshd: sakae@ttyp1 (sshd) | \-+= 72991 sakae -ksh (ksh) | |-+= 39909 sakae pstree
そんな事より、時間同期もどきが、勝手に動いてるっぽい。
ntpdate ?
debian機の時計が合っているのか、前から気になっていた。昔ながらのntpdateでも入れて、ntp.nict.jpに同期させるか？ なんて思っていたら、ふとした偶然で、既に時刻合わせ機構が動いている事を知った。面倒無しで、非常に宜しい。
sakae@deb:~$ timedatectl timesync-status
Server: 2001:67c:25dc::29 (2.debian.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 2
Reference: 1F1CA144
Precision: 1us (-23)
Root distance: 28.457ms (max: 5s)
Offset: +15.620ms
Delay: 322.951ms
Jitter: 50.432ms
Packet count: 10
Frequency: -26.145ppm
timedatectl status で、実際の時刻を確認出来る。
/etc/systemd/timesyncd.confを変更して、NICTにしようかな。
gauche-gl
前回は色々なschemeを取り上げたけどgauche一族が今迄出てこなかったので、GUI関連を入れてみる。
Practical Scheme へ行って、公式版を眺めてみる。Gauche-gl Gauche-gtk が有るな。非公式には、色々あるみたいだけど、本家ですから、どちらかを選べ。
そう言われると、オイラーなら、間違いなくGauche-glを選びますよ。だって、gtkならgtk2,gtk3,gtk4と五月雨式でしょ。それにqt版は無いのかとか、際限がなさそうですから。
正直言うと、gl何それってのも有るんだ。選択に間違いないか、ちと先走りして、マニュアルを確認。
Gauche-gl : OpenGL binding for Gauche
これ、Xlibの底辺じゃなくて、結構上位の機能を使ってるぞ。
OpenGL
#include <GL/gl.h>
#include <GL/glut.h>
GLfloat top = -0.9;
void disp( void ) {
glClear(GL_COLOR_BUFFER_BIT);
glBegin(GL_POLYGON);
glVertex2f(-0.9 , -0.9);
glVertex2f(0 , top);
glVertex2f(0.9 , -0.9);
glEnd();
glFlush();
}
void timer(int value) {
static GLboolean isUp = GL_TRUE;
if (top > 0.9F) isUp = GL_FALSE;
else if (top <= -0.9F) isUp = GL_TRUE;
top += (isUp == GL_TRUE ? 0.01 : -0.01);
glutPostRedisplay();
glutTimerFunc(50 , timer , 0);
}
int main(int argc , char ** argv) {
glutInit(&argc , argv);
glutInitWindowPosition(100 , 50);
glutInitWindowSize(400 , 300);
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGBA);
glutCreateWindow("Kitty on your lap");
glutDisplayFunc(disp);
glutTimerFunc(100 , timer , 0);
glutMainLoop();
return 0;
}
タイマーを使って、アニメっぽくやる例。glBegin() ~ glEnd()の間に、glVertex(頂点)を書いておくのは、お約束っぽい。
CFLAGS = -I/usr/X11R6/include
LDLIBS = -L/usr/X11R6/lib -lglut -lGLU -lGL -lXmu -lXi -lXext -lX11 -lm -lpthread
a.out: z.c
$(CC) $(CFLAGS) z.c $(LDLIBS)
C語用のMakefile freegult-devを入れないとエラーになると言うリナのお約束があります。
try Gauche-gl
次はいよいよ、括弧混じりの世界へ突入だな。リナでもFreeBSDでも、パッケージになってるので、gauche-glをパッケージ名に指定するだけで、簡単にインストール出来る。
手始めに３つの歯車が回るデモをやってみた。32Bit環境ね
run gears.scm at Debian
322 in 5.007 seconds = 64.30996604753346 FPS 313 in 5.004 seconds = 62.54996003197443 FPS 313 in 5.004 seconds = 62.54996003197443 FPS 313 in 5.004 seconds = 62.54996003197443 FPS
run gears.scm at FreeBSD
456 in 5.002 seconds = 91.16353458616554 FPS 881 in 5.004 seconds = 176.05915267785772 FPS 996 in 5.003 seconds = 199.0805516689986 FPS 920 in 5.002 seconds = 183.92642942822872 FPS
Debianの方が性能が良いと思ってた。何故っていうと、Xなドライバーがハードを直接叩くと言う、リナ寄りな実装になってるから。対してBSDの方は、以前に書いたけど、そんな芸当は、まだオイラーの所では実現出来ず、昔ながらのやり方をしてるから。
なんかX関係の資料を漁っていると、Xがリナのカーネルに吸収されてしまうみたいだ。世の中、みんなリナになびいているなあ。その辺の事をPlamoの、こじま先生が紹介されてた。 Days of WINE and Struggles again
ああ、FPS値は、画面サイズに依存する事は知っていますよ。どちらもデフォな画面サイズでの計測値です。
/usr/share/doc/gauche-gl/examples/glbook ここに、色々なサンプルが置いてあるなあ。 そして、もっとサンプルをと言う人には、 Gauche:Gauche-glサンプル 沢山有るヨロシ。
ちょっと、このサンプルを実行してみた。ruby/Tk に対抗して180行でアナログ時計が出来上がっていた。秒針が、本当にアナログ時計っぽく、スムースに動いていた。0.1秒間隔でやると、目をごまかせるのね。
後は、フライトゲーム。スペースキーを押し続けると加速され、離陸限界スピードを越える。これでやっと離陸だ。最初この塩梅が判らず、プチ迷ったぞ。離陸してしまえば、後はグライダー操縦の要領だな(本物は体験した事が無い)。機体コントロールに、上下矢印キーを使う。んだけど、オイラーの感覚では、左右キーの方が馴染むな。何か深遠な理由でもあるんだろうか？
この他にも沢山のゲームが同梱されてる、６年ぐらいかかって、コレクションを増やしてこられたみたいなので、堪能しなければ失礼ってものです。
遊びは、これぐらいにして、 Infoの一番最初に出て来る例、example1-2.scmに、ギアの中の面白いコードを混ぜてみた。
(glut-display-func disp) (newline) (print #`"GL_RENDERER = ,(gl-get-string GL_RENDERER)") (print #`"GL_VERSION = ,(gl-get-string GL_VERSION)") (print #`"GL_VENDOR = ,(gl-get-string GL_VENDOR)") (print #`"GL_EXTENSIONS = ,(gl-get-string GL_EXTENSIONS)") (newline) (glut-keyboard-func keyboard) (glut-main-loop)
Gaucheは機能豊富で、直に忘れる。#`"…" で、変数展開をしてくれるんだったな。
debianなマシンの結果
> sakae@deb:/tmp$ gosh small.scom GL_RENDERER = Mesa DRI Mobile Intel® GM45 Express Chipset (CTG) GL_VERSION = 2.1 Mesa 20.3.5 GL_VENDOR = Intel Open Source Technology Center GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr ... GL_EXT_EGL_sync
しっかりIntel入ってる、ですな。一方FreeBSDでは、
GL_RENDERER = llvmpipe (LLVM 10.0.1, 128 bits) GL_VERSION = 3.1 Mesa 20.2.3 GL_VENDOR = Mesa/X.org GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr ...
こんな結果になった。LLVMの方がハードより性能が良い、のかな？ ちゃんとしたベンチマークを取ってみたいぞ。以上はdual bootなマシン。
折角なので、Windows10にはいってるdebian MobaX/terminal なX環境を使った時。 実際にレンダリングしてるのは、debian側のX環境？
GL_RENDERER = llvmpipe (LLVM 11.0.1, 256 bits) GL_VERSION = 3.1 Mesa 20.3.5 GL_VENDOR = Mesa/X.org GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr ...
こちらは、VcXsrvなX環境から起動
GL_RENDERER = Intel(R) HD Graphics 520 GL_VERSION = 1.4 (4.6.0 - Build 27.20.100.8854) GL_VENDOR = Intel GL_EXTENSIONS = GL_ARB_depth_texture ...
窓の中に箱が一瞬出て、消えてしまうなあ？ でも、歯車はちゃんと回っている。
17298 in 8.063 seconds = 2145.3553268014384 FPS 4549 in 9.365 seconds = 485.7447944474106 FPS 15954 in 5.006 seconds = 3186.975629244906 FPS 5721 in 11.823 seconds = 483.8873382390256 FPS 20620 in 5.0 seconds = 4124.0 FPS
このばらつきは、Windowsの気紛れによるのかな？ いや違うな。多分GCに時間を取られて、本業に時間をさけなかったんだろう。これはもう、避けられない宿命か。
それにしても、VcXsrvはいやに速いな。きっと、自分で何とかするのを諦めて、CPUに内蔵してるGPUに丸投げしてるんだろう。
matrix
モデルビュー変換 上で出て来た入門部門は色々な紹介があるけど、ここが一番大事な部分と思うよ。そして、本家の方が書かれた案内もね。やや、gl.math3dの一員として
6.4 Quaternions
-- Class: <quatf>
Quaternions. Internally quaternions are represented as just an
array of four floats; the first three are the vector component and
the last is the scalar component.
四元数なんてのもあるぞ。どこかに出てたなと頭を巡らせてみると、 素数夜曲―女王陛下のLISP：吉田武 この本に出てた。最初に出会った時、変なやつって思ってた。改めて拾い読みしたよ。 少し知識を広めてみる。
便利な仕組みなのね。ソースコード付きってので、落してきて、g++ qu.cpp とかやったけど、のっけから、iostream.h なんてファイルは有りませんと怒られた。そんな馬鹿なと思ってググると、ヘッダーが必要なのは、旧式な書きかたらしい。さすが、Cフラフラ言語だわい。フラフラと目標が定まらない訳ね。
ヘッダーファイルがいらない代わりに、#include <iostream> と書いておくんだそうです。そして、ソース中にある、cin,cout,endlの前に、それぞれ std:: を補うんだそうです。
全く、これぐらいなソースならC言語で十分と思うけど、どうよ？ で、使いかた。にわかに理解出来無かった。そういう時は実例で考えればいいんだな。
厚くて凶器にもなりそうな、上記の合体本。縦・横・厚さが、22cm X 17cm X 5cm だったよ。 まあ、これぐらいあると、ドカ弁(当)を想像してもいいかも知れない。
この本が、書店の平台に載ってます。一応表紙が目立つように上を向いてます。なんでも表紙のふくろうは、知恵の鳥って事で、特別に描いてもらった、こだわりの日本画だそうです。
この本を台の面を中心に、90度回転させれば、本は自立(厚いから本当に自立します)する。 この時、本の座標はどうなるか？ 頂点が８つあるけど、形を端的に表す事にします。
台の適当な所をゼロ点と定め、そこに、本の一つの頂点を合わせたとします。その頂点から一番遠い所にある、頂点を考えます。
平台に置いた本を、真横から眺める。真上から眺める、とかすれば、製図の３角法になるけど、とりあえず無視。
プログラムの実行例
sakae@deb:/tmp$ ./a.out
Point Position (x, y, z)
x = 22
y = 17
z = 5
Rotation Degree ? (Enter 0 to Quit)
angle = 90
Rotation Axis Direction ? (x, y, z)
x = 0
y = 1
z = 0
Anser X = -5
Y = 17
Z = 22
Point Positionは、背表紙が見える配置に置いたとしてます。それを90度回転させます。30度とか、数学上では例によく出て来るけど、普通は直角君で、90度の回転が多いでしょ。 そして、回転は、Y軸(平台の奥向き方向)を基準に90度回転させました。
一寸極性があれですが、厚さがX軸に現れ、縦サイズが高さ方向に来ましたね。 これが、威力かな。上の結果に続いて、Z軸周りに90度回転させると、
Rotation Degree ? (Enter 0 to Quit)
angle = 90
Rotation Axis Direction ? (x, y, z)
x = 0
y = 0
z = 1
Anser X = 17
Y = 5
Z = 22
今度は、自立した状態で、表紙が見えるようになった。
なお、座標の取り方には、いろいろな流派があり、混沌としてるようです。極性が逆って事は、X軸の原点より左側(数直線で考える)に来たって事です。まあ、回転の方向は、反時計方向を正と仮定してるから、そうなるわな。
いきなり四元数が出てきちゃったけど、普通はアフィン変換のモデルが使われるのかな。
こちらも、頭がクラクラするな。
座標のとり方に、右手系と左手系が有るって言うけど、これってフレミングの右手（左手）の法則と、何か関係があるのだろうか？ 昔の電気エンジニアは考えるのであった。