JavaScript」タグアーカイブ

Node.js Gjs Async

今回は Node.js でシェルコマンドを使う方法を探してみる。

Node.jsからシェルコマンドを実行する – BppLOG

あらこんな簡単に、Gjs と違って日本語で見つかるのは羨ましい。
exec で非同期になるのかフムフム。

…って非同期通信だよね、mainloop いらないの?
関数を抜けた後でも callback handler を保持しなきゃいけないよね??
本当は非同期ではないのかも、実験だ!

#!/usr/bin/env node

const exec = require('child_process').exec;

exec('eog', (err, stdout, stderr) => {
    if (err) { console.log(err); }
    console.log('callback');
});

console.log('__done__');

GUI のほうが動作が解りやすいので eog を立ち上げてみる、Linux の長所だね。
macOS では Kivy とか PyObjC を使えばいいと思う。
結果は見事に __done__ のほうが先に表示、eog 終了時に callback 表示となった。
見事に関数を抜けているね、本当に非同期で動いていことを確認できた。
どうやっているの?

っっって。
よく見たら child_process というモジュール名じゃないか。
つまり Subprocess で動かしているだけってことかも。
Gjs で同様に動く処理を考えてみる、えぇと…

2017.08.27 以下おもいっきり間違えていたので書き換え

#!/usr/bin/gjs

const Gio = imports.gi.Gio;
const ByteArray = imports.byteArray;

let subprocess = Gio.Subprocess.new(["eog"], Gio.SubprocessFlags.STDIN_PIPE);
let barray = new ByteArray.ByteArray();
subprocess.communicate_async(barray, null, function(source_object, res) {
    print('__DONE__');
});
print('__EOL__');

ダメだ。
これじゃ callback を保持できないままプログラムが終わってしまう。

#!/usr/bin/gjs

const GLib = imports.gi.GLib;
const Gio = imports.gi.Gio;

let mainloop = GLib.MainLoop.new(null, false);
let subprocess = Gio.Subprocess.new(["pwd"], Gio.SubprocessFlags.STDOUT_PIPE);

subprocess.communicate_utf8_async(null, null, function(self, result) {
    let [ok, stdin_buf, stderr_buf] = self.communicate_utf8_finish(result);
    if (ok) {
        print(stdin_buf.trim()); // remove '\n'
    }
    print('__DONE__');
    mainloop.quit();
});

print('__EOL__');
mainloop.run()

やはり mainloop は必須。

色々試してみたけど GSubprocess では同様に扱うのは無理みたい。
GUI なら Gtk.main がループしてくれるのでこんな処理はいらないのだが。
GLib.Thread なら、って Gjs からは使えないジャン。

一ヶ月も更新が止まっているのはこの件ででドン詰りしていたからだったりして…
日本語情報が皆無ってキビシイなぁ、もう少し調べます。

js/jsc/v8

ごめんウソ書いていた。
/usr/bin/js は mozjs だった。
JavaScriptCore は /usr/libexec/webkit2gtk-4.0/jsc です。
ということで書き直しました。

/usr/bin/js | PaePoi

せっかくなので jsc のエイリアスを .bashrc に追加。

alias jsc=/usr/libexec/webkit2gtk-4.0/jsc

せっかくだから V8 も追加したいな。
V8 をスタンドアロンで使えるコマンドはあるのかな?

Running V8 Javascript Engine Standalone – Stack Overflow

うーん。。。。。
素直に Node.js を使ったほうが良さそう。
dnf のパッケージ名は nodejs です。

#!/bin/sh

## include alias
. $HOME/.bashrc

js -e 'print(17 + "才");'

gjs -c 'print(17 + "才");'

jsc -e 'print(17 + "才");'

node -e 'console.log(17 + "才");'

echo 'print(17 + "才"); exit();' | jjs

JavaScript 実行環境が 5 つになってしまった。
いや gjs と mozjs はエンジン自体は同じものなんだけどさ。

.bashrc で指定したエイリアスって端末エミュからしか使えないのね。
こうやってドットコマンドを使って読み込むしかないのかなぁ。

Node.js だけ console.log になってしまった。
macOS なら JXA と同じだから気にならないんだろうけど。

jjs は eval できないので変なコトしているけど気にしない!
これを探していたら –language=es6 オプションで let が使えると知った。
でも Template literals は未対応のようだ、やはり無視のほうがいいかも。

JavaScript Template literals (Here Document)

さて Fedora 26 での Gjs は何か進展があるのかな?
って下記の更新適用はいつだか知らないんだけど。

gjs – GNOME JavaScript/Spidermonkey bindings

あれ、この Template literals ってなんていうか…
こういうのをヒアドキュメントというんじゃないの?

少なくとも WikiPedia では Python の DocString すらヒアドキュメント扱いだぞぃ。
筆写としては「Python のソレは流石に別物!」と言いたいが、色々な解釈があるなぁと。

テンプレート文字列 – JavaScript | MDN

Gjs の機能ではなく ES6 定義か、それなら Node.js てか V8 でも使えるだろう。
うん、どう見てもどう考えてもどう突っ込まれてもヒアドキュメントだよね。

文法とデータ型 – JavaScript | MDN

なのに上記ではヒアドキュメント未対応ですとハッキリ記述、なんだかなぁ。
しっかり定義してくださいよ Mozilla さん。

#!/usr/bin/gjs

let val = "backquote";

let heredoc = `JavaScript
${val}
Test`;

print(heredoc);

バッククォートです、シングルクォートと間違えないでね。
これは便利、プラス記号で文字列の合体って作る側は「読み難いコード」でしかない。
つか Gedit は普通に色分けするんだ、知らなかった。

Safari も対応ってことで JXA でも使えるようだ。
vscode もしっかり色分け。

ちなみに jjs ではバッククォートの時点でエラーになる。
そりゃ今でも let 宣言にすら対応していないのですし。
現状 JAVA 界隈でもまったく使われていないようだし jjs ってガン無視でいいかも。

LOKDocView

本日の Fedora アップデートでこんなのが出た。

LOKDocView って何だ?

Development/Integrating LOKDocView and GNOME Documents – The Document Foundation Wiki

libreoffice 文書を GNOME Document で表示する API なのか。
ということは gir でバインドされているのかな。

普通にあったわ、コレって今まであったっけ?
まあそれはいいや、さてサンプルコードを探してみよう。

GitHub – pranavk/lokdocviewer: An application for testing LOKDocView

js/py 両方用意してくれているとは親切ですね。
しかし new メソッドの引数が PyGObject は 2 つで Gjs は 3 つ。
Gjs らしく new キーワードに書き換えるとコアダンプ。

#!/usr/bin/gjs

const Gtk = imports.gi.Gtk;
const LOKDocView = imports.gi.LOKDocView;
const Lang = imports.lang;

const LOKWindow = new Lang.Class({
    Name: 'LOKWindow',
    Extends: Gtk.ApplicationWindow,

    _init: function(app) {
        this.parent({
            application: app
        });
        // Segmentation fault
        //this.view = new LOKDocView.View();
        this.view = LOKDocView.View.new(null, null, null); // OK
        this.view.open_document(
            "/home/sasakima-nao/syokumu.odt",
            "{}",
            null,
            Lang.bind(this, function() {
                this.view.set_edit(true);
            }),
            null);
        let sw = new Gtk.ScrolledWindow();
        sw.add(this.view);
        this.add(sw);
        //
        this.show_all();
    }
});

let app = new Gtk.Application();
app.connect("activate", function() {
    new LOKWindow(app);
});
app.run(null);

前々回みたいな問題があるし…
GNOME はぶっちゃけ Gjs に全面移行したいのだろうけどまだ問題が多いなぁ。
てか Python はサードパーティなのに対応っぷりがスゲェ。
当面は Python と併用が続くのだろう。

コレを使って何か作るかな、ここんとこネタ切れなのは秘密だよ。

ClutterImage PyGObject/Gjs

おまたせ、Comipoli Gjs 版が遅くて出せない原因が判明しました。

#!/usr/bin/env python3

import gi
gi.require_version('Clutter', '1.0')
gi.require_version('GdkPixbuf', '2.0')
from gi.repository import Clutter, Cogl, GdkPixbuf

Clutter.init()

PICTURE = "burgman400.jpg"

pixbuf = GdkPixbuf.Pixbuf.new_from_file(PICTURE)
image = Clutter.Image()
image.set_data(
    pixbuf.get_pixels(),
    Cogl.PixelFormat.RGB_888,
    pixbuf.get_width(),
    pixbuf.get_height(),
    pixbuf.get_rowstride()
)

#!/usr/bin/gjs

const Clutter = imports.gi.Clutter;
const Cogl = imports.gi.Cogl;
const GdkPixbuf = imports.gi.GdkPixbuf;

Clutter.init(null);

const PICTURE = "burgman400.jpg";

let pixbuf = GdkPixbuf.Pixbuf.new_from_file(PICTURE);
let image = new Clutter.Image();
image.set_data(
    pixbuf.get_pixels(),
    Cogl.PixelFormat.RGB_888,
    pixbuf.get_width(),
    pixbuf.get_height(),
    pixbuf.get_rowstride()
);

何ですかこの圧倒的なスピード差は!!!
というより Gjs のこの異様な遅さは何なんだ?
GdkPixbuf を使うだけなら特に差が無いのに。

憶測だけど PyGObject は get_pixels でバイナリ出力を直接使っていると思う。
Gjs は多分バイナリ出力を Uint8Array オブジェクトに変換している。
言語仕様の制限だろうからセット関数の追加が無いかぎりこのままだろうね。

ClutterImage に画像セットはコレしか手段が無い、これは困った。
Gjs でいくなら ClutterCnavas で cairo という手しか無いっぽい。
でもそれなら GtkDrawinArea でいいじゃん、ということになり…

結論、Clutter で画像を使うのに Gjs は絶望的に向いていません。