自分宛てメモ。


ネットワークドライブのマウントを待たない。
/usr/share/gvfs/mounts/network.mount

自分宛てメモ。


LTS以降にリリースされたカーネルをLTSでも使えるようにしたもの。
backport kernel.

 

前記事でLinuxMint17のカーネル更新について書いたけれど、今朝起動したらアップデート可能になっていた。

 

正確には

「MintUpdateのアップデート(ややこしい)が届いていて「昨晩全部実施したのにまたかよ」と思って更新をかけたら、LinuxMint18でも使われている4.4.0-109-genericが利用可能になっていた」

ということです。

 

図1 インストール後の様子。

 

LinuxMint17に4.4系を入れたのは昨晩が最初でした。4.4.0-109-genericが見えなかった理由は
・今まで使っていなかったから109-genericが選択肢にならなかった。
・17LTSでも問題なく使えることが分かったのでイネーブルした。
・繋いでいるサーバーが国内ミラーなので時差があった。
あたりかと思いますが、はっきりしたことは不明です。

 

 

図2 テスト結果

 

 

ともかく、これでLinuxMintのカーネルは(応急)修正できました。

 

 

このほかdebianとSlitazもあるんだよな。Slitazはドライバ欲しさに自前で差し替えているのでよく調べてからとりかからないと悲惨なことになりそう。

 

 

CPUに由来するセキュリティホール(Spectre,Meltdown)が見つかった、とかで騒ぎになっている。

 

Linux向けのチェッカーを見つけたので試してみた。
参照元:がとらぼ(https://gato.intaa.net/archives/11412)

 

準備

MintUpdateを使って最新状態にする。LinuxMint18.3(xfce4)のアップデートが有効になっていたのでそれも併せて実施した。

 

 

結果

 

LinuxMint17.3(amd64,xfce) CPU Core2Duo
CPUの対応もカーネル修正もなされていない。試しにこのOSでは最新となる4.4.0-98-generic(それまでは3.19.0-32-lowlatency)をインストールしてみたが変化なし。

LinuxMintによれば対応したカーネルバージョンは3.13.0-139 (https://blog.linuxmint.com/?p=3496)

 

LinuxMint18.3(amd64,xfce) CPU Corei5
CPU対応なし、カーネルは修正あり。カーネルバージョンは4.4.0-109-generic。

 

 

Mint17はUbuntu14.04LTSをベースにしており、まだサポート中なのでカーネルはいずれ対策されるのかも知れない。前述のLinuxMintの記事によれば17向け対策済の4.4系カーネルもありそうなのだけれど。違うのかしらん。

CPUについてはマイクロコードの書き換えが可能かどうかもよく分からない。まあ、攻撃されたら諦めることにしますよ。

 

 

追記

本件に直接関係ないが、Mint17.3のカーネルを3.19から4.4に変えたら心持ち使い勝手が軽くなったような気がする。

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

 

グラフとか描けると便利かしらん、と思って実装をはじめました。このくらいできないとデフォルトのluaと大差ないので。

で、一番簡単な方法(実はデスクトップにおける実装方法はこれしか分からない)である、gtkをそのまま使うことにしました。cairoが使えるのでそこそこ凝った表示も可能なはずです(そうか?)

 

とりあえず、線分を描けるようにしておいてテストしてみたのですが。
(追加した関数については稿末に記載)

 

リスト1

 

実行結果1


何も出ません。
原因は「描画用ウィンドウが表示される前に、luaの実行が終了してしまっている」ため。

 

drawableに描き込んでいるのですが、このウィジェットは実際にディスプレイ上に表示されていないと描き込みが反映されません。
なのでgtkでは、実際に表示される際に発生するイベント「expose-event」にコールバックを定義して描画するようになっています。

 

ウィジェットは各々がdrawable(というかgdkwindow)を持っているので、この方法で問題ありません。これにより、例えばトップレベルのウィンドウがリサイズされたような場合でも適切に再描画することも可能になっています(そのようにexpose-eventのコールバックを書かなくてはなりませんが)。

 

しかし今回は単にビットマップにグラフを描き込みたいだけです。各々の線分をウィジェットとして定義する方法も考えられますが、かなり複雑になりそうです。(動的にカスタムウィジェットを作成してそれを描画することになるので)

 

さて。どうしたものか。

 

 

かっこ悪いですが現状でも工夫すれば使えないことはありません。

 

リスト2

 

実行結果2


プログラムの先頭で入力待ちして、描画ウィンドウの表示を確認してから手動でプログラムを再開しています。原始的ですね。
この方法でも、描画ウィンドウを最小化してから再表示させると描いた内容は全て消えてしまいます。

 

 

以前、青空文庫リーダー(但し言語はCではなくpython)を作った時はgtkに不慣れということもあって描画関係はcairoで完結させていました。cairoからはgtkを触れないので(※)一旦pngに書き出してからgtkのウィジェットに読み込ませて表示しました。この方法は簡便である反面、任意のタイミングで描画したい用途には向きません。

 

(※)直接インスタンスを引けないので。gtkがcairoコンテキストを返すので、それを使います。

 


 

luaに追加した関数
print(...)
    標準関数 print の代替。結果をウィジェット(右側のsourceview)に出力します。
input([prompt])
    ダイアログを表示して入力結果を戻します。キャンセルの場合はnilを戻します。
line()
    線分を引きます。
 

luaを何かに組み込んで使う際、組み込み側からluaを実行するには lua_pcallを使うことが多いと思われる。

 

この関数を使うと、lua側でエラーが発生しても呼び出し側までエラーが波及しない。これ以外の、例えばlua_callだと呼び出し側もろともプロセスがエラー終了する。

 

lua側でエラーが発生した場合、lua_pcallは0以外を戻すので、何が起きているか調べることができる。

 

lua5.1のリファレンス(※)によれば、戻されるのは次の通り。

 

  • LUA_ERRRUN: a runtime error.
  • LUA_ERRMEM: memory allocation error. For such errors, Lua does not call the error handler function.
  • LUA_ERRERR: error while running the error handler function.

 

単純に上記3つのみを調べて終わろうとするとエラーを取りこぼすことがあった。取りこぼしたエラー値は「1」で、lua.hを見てみると LUA_YIELD と定義されていた。綴りから察するに必ずしもエラー用ではなさそうである。

 

他は、

 

LUA_ERRRUN 2
LUA_ERRSYNTAX 3
LUA_ERRMEM 4
LUA_ERRERR 5

 

であった。

 

0以外を戻すという仕様なので 1や3を戻してもよい。
しかし、リファレンスに「うん、嘘はついていない」とか言われているようで腹たつよな。

 

オープンソースなので!読めばわかるさ、迷わず読めよ。 > 俺

 

(※)参照・引用URL
https://www.lua.org/manual/5.1/manual.html#lua_pcall

leafpadをフォークしてLuaの実行環境を作る話(3)

 

何か年内はこれを弄って終わりそうです。

 

GtkSourceViewを使ったおかげでleafpadで使われていたソースを3本(ヘッダも含むと6本)もカットできました(Undo,linenum,indent関係)。

 

いかにGtkSourceViewが機能てんこ盛りか分かりますね。逆に言うと、これだけのものをleafpadは全部自前で用意していた訳で、作った人の苦労がしのばれます。

 

そのほか、emacs(キーバインドのテーマか何からしい)とgnomeprintsessionも切りましたので、合計10本をカットです。

 

メニュー構築関連のコードをUI Managerに書き換えたりしていたので手間取りましたが、取り敢えず必要な機能は盛り込めました。

 

もう少しコードを見なおさなくてはならないのですが、そろそろ本来の目的である、Luaの実行環境として整備していこうと思います。

 

機能が多いのでどうしてもメニューが深くなってしまう。変更頻度が低そうなものを奥にしているが、使い込んでの検証が必要。

leafpadをフォークしてLuaの実行環境を作る話(2)

 

弄っていて初めて知ったのだが、GTKウィジェットのメニューには、メニュー項目を切り離して表示させる機能がある。

 

設定方法は次の通り。(UIマネージャの場合)
gtk_ui_manager_set_add_tearoffs( ui, TRUE );



 

メニューの付け根に点線が表示されるので、そこをクリックすると別ウインドウとして切り離される。

 

 

この状態で、そのままコールバックが動作するのなら使い道もあるのだがそうはならない。そのような機能が必要なら自分で書かなくてはならない(多分)。

 

使っているDE(Xfce4)やアプリケーションもGTKベースのものがほとんどだけれど、覚えている限りでメニューがこのようになっているのには遭遇したことがない。完全に過去の機能として無視されているか、ディストリビュータが切っているのか。

 

ひょっとしたらGnome環境では真価を発揮するのかしらん。純粋にGnomeを使ったのは大昔のFreeBSDの時くらいなので、この機能が本来どのように使われていたのかよく分からない。

 

切り離し時点でのメニューの状態は保持されるので、このままでもステータス表示くらいには使えるかも知れない。

 

leafpadをフォークしてLuaの実行環境を作る話(1)

 

今まで余りシステムべったりのコードを書いてこなかった(PC-9801やAXマシンでMS-DOSを使っていた時を除く)ので、ものすごくベタなところでハマってしまった。我ながら情けなくて二度とやりたくないので、自分宛てメモ。

 

leafpadでLuaのコードを実行する、というのを作っていて、出力結果をGTKウィジェット(textviewとtextbuffer)に取り込むことにしたのですね。

 

で、取り敢えずスクラッチファイルを作ってそれを監視しながら適当に読み込んで表示、という処理は出来たのだけれど、Linuxのファイル監視機能を使うのとファイルの読み書きにまつわる問題(というか仕様)により、レスポンスがよく有りません。

 

で、Luaの出力、即ち標準出力に対するprintの結果を直接受け取ってウィジェットに流し込もうと企てたのです。

 

この場合、Luaの出力をリダイレクトすることになります。一番簡単なのは別プロセスとしてLuaを実行することです。

 

しかし、せっかくleafpadにLuaをリンクしているので、出来ればこのリンクしたLuaに実行させつつ、出力を取り込めないかなあ、と思ったわけです。

 

段取りとしては、

  1. パイプを用意し、
  2. dup2()で入り口を標準出力にあてて、
  3. 実行中のLuaとは別スレッドでパイプの出口を読んで、ウィジェットに流し込む。

と、なります。

 

ところが。

 

どうやっても期待通りの動作になりません。Luaからの出力は表示されなくなったので(デバッグの為、仮想端末からleafpadを起動している)標準出力が切り替わっているのは確かなのですが、パイプの出口から出てきません。

 

試しに、Luaに関係なく、いろいろコードを書いて試したところ printfやputsではダメで writeだと流れていくことが分かりました。

まあ、普通はここで原因に気づきそうなもんですが、気づかなかったんですねえ。齢は取りたくないものです。

 

七転八倒すること2時間()、諦めかけてdup2のリファレンスを読み返してみるとこう書かれているではありませんか。

 

「dup2() システムコールは dup() と同じ処理を実行するが、 番号が最も小さい未使用のファイルディスクリプターを使用する代わりに、 newfd で指定されたディスクリプター番号を使用する。 ディスクリプター newfd が以前にオープンされていた場合には、 黙ってそのディスクリプターをクローズしてから再利用する。」(※)

 

「黙ってそのディスクリプターをクローズしてから再利用する。」

 

 

... そうか、そうであったか。

 

dup2を実行すると、パイプの入り口は標準出力に重なりますが、その時点で既存の標準出力はクローズされる、と。
なので、「既存の標準出力(stdout)」を相手にしているprintf,puts系のライブラリ関数は全滅し、ファイルディスクリプタを明示するwriteだけは「新規の標準出力(パイプの入り口)」に書き出すので、出口からきちんと出てくるという訳かしら?

 

でもファイルにリダイレクトする場合は問題ないのですけどね。あらゆるものがファイル、が前提なのがUnixライクOSだと思いますが「いわゆるファイル」と「パイプ」とでは思わぬ格差があるのかも。

 

うーむ、これは仕様を変えないとダメなケースですね。ひょっとしたら標準ライブラリのどこかに抜け穴的なフックとかあるかも知れませんが、これ以上調べ物に時間を費やせないので、今回はここで転進することにします。

 

ああ、日頃何気なく使っているシェルスクリプトの有り難みが骨身にしみるなあ。

 


(※)引用URL
https://linuxjm.osdn.jp/html/LDP_man-pages/man2/dup.2.html

電子回路の設計をしていると色々と細かい計算が必要になってきます。表計算ソフトも便利なのですが、然程計算量が多くない場合は起動時間が無駄に思えて使う気がしません。


こんな場合、工学用の電卓やスマートフォンのアプリを使うのが普通と思いますが、私は両方共持っていないのですね。

で、いつも電源が入っているPCを使って、PythonやLuaなんかで計算するのですが、これらのスタンドアロン環境って対話操作前提なのでスクリプトを描いて走らせるのが面倒だったりします。


汎用の統合環境(例えばGeanyとか)を使っても良いのですが、せっかくなので勉強も兼ねて一つ自分で作ってみることにしました。

 

フルスクラッチで組み上げるのは相当の手間ですので、楽できるところは楽をしようということで、取り敢えずの仕様は以下のとおりです。

 

  • スクリプトはLua5.1とし、外部プロセス起動ではなく組み込みとする。
  • エディタはLeafpadをフォークし、次の機能を追加する。

ソースコードの色分け表示
標準出力の表示

 

 

今までCでgtk/gobjectを扱ったことがなかったので、ソースを読みながらの試行錯誤で数日を要してしまいましたが、取り敢えずLuaを実行できるようにはなりました。

 

勿論、バグ多数。

 

先は長い。

 

下段に標準出力を表示しているが盛大に文字化けしている。

 


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