忘れやすいが for のカウンタ変数はローカルです。しかも for を抜けると揮発します。

 

 

自分宛てメモ

 

  • ローカルテーブルとして新規オブジェクトを作成し、それのメタテーブルを書き換えて継承する。{__index=親}
  • 多重継承できない。必要であれば後からメンバを流し込む。
  • selfは暗黙の変数として予約されている。
  • 自動で動く関数はない。初期化の際は親クラスの初期化関数を呼ばなくてはならない。
  • その代わりオブジェクトの破壊は(多分)ガベコレまかせにできる。


書きにくくて仕方ない。慣れというものはあるのかも知れないが。いちいち local 書かなくてはならないし。

 

LinuxMint17でVirtualBox5.1の更新通知が届いた。meltdownの件もあったのでアップデートしたのだが、一部仮想環境が動かなくなった。

 

debian(stable,32bit)
症状 GuestAdditionsを変更したらディスプレイマネージャまで辿り着かなくなった。
対策 実機インストールとの比較実験用であり、実機のほうがそれなりに動いているのでもはや不要と判断して削除。

 

Slitaz(カーネルを自前で4.4系に入れ替え)
症状 GuestAdditionsを更新しようとしたらできなかった。ビルドはするがインストールできないという、いつもの状況。
対策 後述

 

Slitaz(カーネルを自前で4.9系に入れ替え)
症状 特に異常なし。これはGUIを切ってサーバーとして動作させている。H8/300Hのコンパイラを動かすために共有フォルダーを使っており、動かなくなると悲惨なことになるのでこのまま。

 

LinuxMint Debian Edition (LMDE,32bit)
症状 変化なし。LinuxMintはvbox用のドライバを同梱していたはずで、おかげで仮想環境でも普通に動く。壊したくないのでこのまま。

 

 

5.1を使い続けていたのは下手にバージョンアップするとGuestAdditionsの導入で失敗するから。が、遂に失敗してしまったので、5.1を削除して5.2に更新した。
それでもdebianはダメだったので削除。Slitazはうっかり4.4系のソースを消してしまっていたので、公式カーネル(3.2.98)に戻してGuestAdditionsを導入したところうまくいった。但し、起動するたびに画面解像度がSVGA(800x600)になってしまい、都度Slitaz側で変更しなくてはならないのは煩わしい。見ていると、一瞬全画面表示(1280x1024)になってからSVGA(800x600)に引き戻される。
ブートメッセージを眺めていると、ユーザーvboxaddが無い、とか言っていたので手動で追加したら、DE(xfce4)起動後、盛大にエラー通知が出るようになった。これはGuestAdditionsを再インストールしたところ出なくなった。

 

(手抜きで)自動でローカル変数をダンプするようにしておいたままだけど、意外と便利かも。

 

上の図の例では、関数hogeは計算結果ではなく無名関数を返している。そして関数の実行時には引数だけでなく、無名関数の外側で定義された関数hogeの引数Cも使っている。(hogeの最初の2つの引数は未使用です。)

 

初学者には分かり難いかも知れないけれど、うまく使うとコードをコンパクトにまとめることができる。

 

まあ、別にLuaでなくても書けるけど。処理系のフットプリントを考えると、Luaはもっと利用されて良い言語だと思います。

引き続きluaの実行環境を作っている。ブレークポイントが扱えるようになったのでステップ実行を実装してみた。一般的にステップ実行にはステップインとステップオーバーとがあるが、今回はステップインである。ステップオーバーはブレークポイントで代用できる。同様に「カーソルのあるところまで実行」というのも無しで行こうと思う。

 

「ステップ」といえば昔からプログラムの規模を表す尺度として使われてきた、ように思う。10代の頃、ハンドアセンブルに嫌気してZ80のアブソリュートアセンブラを(ハンドアセンブルで)書いたことがあるが、それを高校の担任に話したら「何ステップくらいのプログラムですか?」と訊ねられて返事に困ったことがある。単純なパソコン少年だった俺は、それまでプログラムの大きさなんてキロバイトでしか考えていなかったからね。アセンブラ(というか機械語)にせよBASICにせよ何らかのデータを含んでいる場合がほとんどだから、キロバイト、即ちロード時のメモリ占有量がでかくても必ずしもプログラムそのものが複雑かつ巨大ということにはならない。この点でステップ数は単純にプログラムの規模を比較するには都合がいいのかも知れなかった。

 

まあ、30数年前と違って使えるライブラリはゴマンとあって、大した苦労もせずにそれなりのプログラムが作成できるようになった。いい時代になった、と思う。これでドキュメントが全部日本語だったら言うこと無いのだけれどね。

 

 

luaのランタイムイベントは空白行や非実行行(単にブロックを示すだけのdo end等)では発生しない。ブレークポイントを3箇所設定しているが、2箇所しかブレーク(青文字)していないのはそのため。

変数のウォッチはローカル変数は簡単に拾い出せるのでとりあえずブレークするごとにダンプしている。問題は大域変数や上位値、関数の類だ。しかし、そもそも、これらをいちいち止めて調べないと判らないようなプログラムを書くだろうか?

 

 

 

自分宛てメモ

 

gtkのmainループの外で「待ちループ」(以下、外ループ)を構成すると、gtk側の処理が進まずUIが動かなくなる。

 

これを回避するには、外ループの中で gtk_main_iteration を呼んで gtkのmainループを動かせば良い。

 

しかし、状況によってはmainループがスムーズに進まず、gtk_main_iterationが帰ってこないため今度は外ループが滞ってしまう場合がある。

 

詳細は不明だが、gtkの動作をイベントドリブンと仮定すれば、UI上でイベントが発生しない状況(例えば画面を眺めているだけ)が長く続けば、待機になってしまうのではなかろうか。

 

試しに動かなくなったウィンドウの上でマウスカーソルを動かすと、途端に動作が進むことを確認している。

 

対策として、代わりに gtk_main_iteration_do(FALSE) を呼んでみたら改善した。

 

UIの構成によって全体の挙動は変わると思うので、これが常に確実な方法かどうかは分からない。

 

leafpadを改造してluaの実行環境を作る話の続き。

 

gtksourceview2.0のガーターにアイコンを表示する件について、2日かかりでようやく解決を見ました。

 

行番号同様、GtkSourceMarkがほとんど面倒を見てくれます。最初、このことに気づかず、gutterにcellrendererを追加して1ドット刻みでガーターが広がったりして「???」と悩んでしまいました。

 

また、表示するアイコンもファイルから読み込まずにGtkのストックを流用することで簡略化しました。

 

これで任意の位置にブレークポイントを設定できるようになりました。

 

 

ブレークポイント処理について

 

luaにはイベントフックが用意されており、これにコールバックをアタッチすることで処理できます。
コールバックからそのまま戻ればコンティニュー、luaL_errorでエラーを起こせば終了します(userbreak)。
今回のようにGUIを使っていると、コールバックの中で単純に待ちループを設けると他のウィジェットにアクセスできなくなるので工夫が必要です。

 while ( gtk_main_iteration() == FALSE &&
                is_lua_break_in == TRUE ) {
            // とりあえずコンティニュー待ち
            ;
        }

      
gtkの場合gtk_main()で待ちループに入りますが、単純に呼ぶと前述のように他に何もできなくなります。
このため、gtk_main_iteration() を呼んでイベントの有無を調べながらループします。is_lua_break_in はコンティニューやストップが実行されるとFALSEになり、このループは終了します。

 

 

さて、残る機能はウォッチ式の追加です。これも凝りだすと泥沼なので必要最低限に留めたいところです。UIにGtkTreeを使わざるを得ないと思いますが、考えただけでぐったりしますよ。

 

実行画面。コンティニュー待なのでメニュー項目の「Run F5」は触れないようにしていますが、キー入力そのものはバッファリングされたままです。この状態で F5を押下するとlua終了後に再度実行されてしまいます。

 

 

 

leafpadを改造してluaの実行環境を作る話の続き。

 

gtksourceview-2.0の機能の一つにガーター表示があります。これは行番号の右隣りに図形を表示する、というもので、ブレークポイントやエラー発生行のマークに使うことができます。

 

が、実際どうやって使うのかさっぱり分かりません。

 

ガーター部分にボタンウィジェット(のようなもの)がずらりと並んでいて、それにコールバックをアタッチすれば良い、とかなら簡単なのですが、viewは設定やbufferの内容によって見た目が大きく変わるのでこの方法は効率的とは言えないと思います。

 

実際、管理しているウィジェットはsourceviewです。

 

  1. ウィンドウのどこをクリックされたかを検出し、
  2. ガーター上であれば座標をもらって
  3. そこから該当行を割り出して
  4. マークを表示・非表示し、
  5. マークの情報は別途ウィジェットに格納する。

という流れになります。

 

問題は具体的にどう書いたら良いのか、というのがさっぱり。既にgtksourceviewは3.0に移行しており、公式サイトのドキュメントに書かれていることが2.0にはそのまま流用できないのですね。ガーターの利用例が少ないこともあり、参考になりそうなコードを探し出すことすら難しい。

 

それでも、pythonのバインディングにdemoプログラムが付属していたので、それを手がかりに試行錯誤をはじめました。単なるラッパーではなく、使いやすいように結構手が加わっているようでpythonの関数にそのまま該当するAPIがなかったりして、こちらもまた茨の道ではあるのですが。

 

python-gtksourceview2のデモプログラム。手元の環境にはプログラム指定のpngが入っておらず、最初エラーになったので、適当なもので代替しました。

 

 

 

素直にgtk+-3.0で始めるべきだったか?まあ、今までもなんだかんだ言いつつ最終的には(問題は多々残しはしても)仕上げてきたので。今回もなんとかなるでしょう、多分。

 

 

gtk-sourceview2を利用しているgedit(2.30.5)。行番号右側の表示切り替えが見当たらなかった。使っていないのかも知れない。

 

 

おまけ。Linux Mint 17では gedit は新しものと旧いもの両方を扱えます(同時には無理だけど)。

 

自分宛てメモ。

 

meltdown関係でubuntuのカーネルアップデートが行われているが、ABIを変更しているためモジュールを自前で追加している場合は再コンパイルが必要になる。

 

今朝、LinuxMint17を起動したら新たにlinux-generic-lts-xenialが利用可能になっていた。依存関係を追うと4.4.0-109に繋がったのでもはや入れる必要はなかったのだけれど、分かりやすいので入れておいた。ついでに4.4.0-98を削除した。

 

セキュリティパッチ済のカーネルに差し替えてからいろいろ動かしているが、xfce4の起動時の動作が際立って遅くなってしまった。

 

パネルを3枚開いているのだけれど、天気情報やシステム負荷モニターのアイコンが表示されるまで10数秒かかる。
元々遅いwhiskerMenuに至っては30秒以上待たされる。感覚的には数字以上に長い。起動に失敗したのかと勘違いしたくらいである。
加えて、今までまったく気にならなかったデスクトップ上のアイコン表示が、同じくらい遅くなってしまった。

 

このほか、thunarのサムネイル作成デーモンが極端に重くなったので(HDD内に動画ファイルが溜まっているのも原因)サムネイル表示を切った。画像整理をthunarでやることも多いので、これはちょっと不便かも知れない。

 

もうとっくに終わっていると思ったのですが。

 

ubuntu の次期LTS(18.04)では gtk2とpython2がmainリポジトリ(Canonical謹製)から⁠universe(コミュニティ)へ降格になるとか。
で、mainリポジトリ内のパッケージはuniverseに依存できないそうなので、gtk3への移行を進めていたのが最終局面らしい。

 

個人的には pythonは処理系(いわゆるcpython)が総じて遅いのでなるべく使いたくないのと、gtk3は出だしに不評だったのと未だに動作がもっさりなので(バックエンドが何かにもよるだろうけど)積極的に使う気がしません。

重大なセキュリティホールが放置されたままとかでなければ、枯れている分だけ旧いライブラリのほうが扱いやすいということもあります。

 

とはいえ、gtk2は途中でcairoに変わったこともあってプログラミング上の煩わしさが半端ないのも事実。expose-eventでcairoから画像1枚貼り付けることもままならない(imagesurfaceを直結できない)とかキツイです(gtk3では可能、らしい)。

 


Search

Calendar

S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728   
<< February 2018 >>

Archive

Mobile

qrcode

Selected Entry

Link

Profile

Search

Other

Powered

無料ブログ作成サービス JUGEM