sizeof

sizeof ってスタック領域でのサイズだったのか!

#include <glib.h>
#include <stdio.h>

int
main (int argc, char *argv[]) {

    gchar* s;

    /* コレはイケる */
    gchar c[] = "たのしい Linux 1";
    g_printf ("%s は %ld 文字です\n", c, g_utf8_strlen(c, sizeof(c)));

    /* sizeof(s) が 8byte、つまりポインタのサイズになってしまう */
    s = g_strdup("たのしい Linux 2");
    g_printf ("%s は %ld 文字です\n", s, g_utf8_strlen(s, sizeof(s)));
    g_free(s);

    /* 一応試したけど同じだった */
    s = g_malloc(256);
    g_sprintf(s, "たのしい Linux 3");
    g_printf ("%s は %ld 文字です\n", s, g_utf8_strlen(s, sizeof((gchar*)s)));
    g_free(s);

    /* strlen ならイケるけど警告になる */
    s = g_strdup("たのしい Linux 4");
    g_printf ("%s は %ld 文字です\n", s, g_utf8_strlen(s, strlen(s)));
    g_free(s);

    /* Best */
    s = g_strdup("たのしい Linux 5");
    g_printf ("%s は %ld 文字です\n", s, g_utf8_strlen(s, -1));
    g_free(s);

    return 0;
}

sizeof

gcc でしか試していないけど、まあ思いっきり GLib だし。
(gchar*) キャストも無意味ってことはつまりそういうことだろう。
ひらがな UTF-8 は 3byte だから当然 2 文字分しか検出しない結果に。

検索しても何も見つからないのは何故だろう?
gcc 以外ならイケるのか、それとも皆スタック領域でしか sizeof を使わないのか。

てゆーかこの問題は -1 指定で普通に解決した。
おかげでこんなことが解ったので無駄な時間は結果オーライ。

GTK+ Inspector

海外の GTK+ 関連 Blog を見ていると GTK+ Inspector というものをよく見かける。
Projects/GTK+/Inspector – GNOME Wiki!
どうも Visual Studio 付属の spy++ のようなものみたい、実は何かよく知らなかった。
GPL ばかりの Linux ではソースを見ればいいのであまり興味も無かった。

が、今日なにげに Ctrl+Shift+I を押したら立ち上がってマジ驚いた!
キーボード設定を見てもそんな設定なんかしていないんですけど。
ちなみに Ctrl+Shift+D でもいい、Fedora ではデフォルトで使えるの?
てゆーか何故いままで気が付かなかったのだ?

もしかしたら gcc, gtk3-devel, gtk3-devel-doc が必要かもしれない。
GTK+ ヘッダとヘルプね、筆者は新規インストール直後にコレは入れるので。

使い方を検索してもやはり日本語情報は皆無か。
せっかくなので自分で少し使ってみよう。

とにかく GTK3 で作られているアプリを立ち上げ上記のキーを押す。
Python 製でも GTK3 ならいける、GTK2 の Firefox, Gimp はスルーされた。
Qt の KeepassX や独自 SDK の Libre Office でも当然立ち上がらない。
下記は Totem がアクティブ状態で Ctrl+Shift+I を押した状態。

gtk_inspector

OK ボタンで解析開始。
やはり spy++ みたいなものですがリアルタイムでプロパティを弄ることもできる。
たとえば Visual のタブでダークテーマの切り替えなんかも即時おこなえる。

カスタム CSS まで即時、ちなみに GTK+ Inspector 側にも適用される。
CSS で見た目の微調節をしたい場合なんかに凄く便利そう。

gtk_inspector_css

肝心の解析は左ペインで Widget の階層が解る、spy++ より判り易い。
本体から知りたい部分をクリックするとその Widget 部にフォーカスが移る。
初心者の頃他人のアプリを見て「こんなに積み上がってるの!」と驚いた。

他に Properties の Defined At が参考になるかな。
Totem 3.14 の動画表示部は GtkClutterEmbed をインプリメントしているね。
つーことは Clutter を使わない Ubuntu は次バージョンも古いアプリのままだなw

gtk_inspector_props

これ以上は各自で。
GTK+ でアプリを作る人以外は必要無いしさほど重要でもないアプリですけど。
せっかく Fedora なら即使えるので試してみるのもいいでしょう。

GLib stdin

時は 2015 年

@ サイト管理者やプログラマー
今後は更にスマートフォンの時代になる、タッチパネル向けに作らなければ!

@ 絵師
ソシャゲ用イラストの需要が凄い、ソッチ向けを考慮しなきゃ!!

@ 一般的な人
モンストと Line で忙しい、おっと便利なサイト発見etc…

@ ネクラでキモチワルイ人達
スマホで充分という人はパソコンでもたいしたこと(以下略)ドャァ!!!

こうなることは解っていたがスピードが速すぎな気がする。
実際の話、仕事に必要という理由以外でパソコンを買う人は減る一方なのは確実。
筆者は Fedora 愛用だが実は他人には Mac かタブレットを勧めている。
Linux なんてサイトを自力で作っている人以外にはメリットが無いので。

確実なのは Windows は既にデファクトスタンダードでは無いということ。
モバイルでの Web に関してはもはや Safari がスタンダードに近い。

大型バイク乗りのオッサン、もういいかげんにビクスクを認めろよ。
確かに大型バイクはカッチョイイけどそんなものオイラ達には不要なんですよ。
PCX150 がバカ売れしている時点で余程のバカでなければ気が付くはずなのだが。
その「余程のバカ」が多すぎる、スマホ普及率をガン無視するネラー共と同じく。

絵に関しては Mac 使いにまかせる、その理由で Mac にしたはずだし。
こんな時代にパソコンを使うならプログラミングは必須。
でないとネクラでキモチワルイ人達の一人だと思われてしまう。

そんなこんなで GLib Tips のページを作ろうと思ったわけですが。
GLib って scanf, fgets, fgetc という標準入力のラッパーが無いんですね。

scanf は色々アレなので fgets を今迄使っていたのだが。
コレも色々ある、バッファオーバーランに無力だしスタック領域が無駄だし。
何より改行コード付随というのが気に入らない。

#include <stdio.h>
#include <string.h>
 
int
main (int argc, char *argv[]) {
    char line[256];
    printf("Hi!\nPlease enter your name: ");
    fgets(line, sizeof(line), stdin);
    /* Remove '\n' */
    line[strlen(line)-1] = '\0';
    printf("Welcome, %s!\n", line);
    return 0;
}

ライブラリ関数で取得したものを自力で再加工なんて無駄にもほどがある。
ならば最初から自力で取得し加工したほうが無駄がない。

/* valac -C src.vala */
stdout.printf ("Hi!\nPlease enter your name: ");
var name = stdin.read_line ();
stdout.printf ("Welcome, %s!\n", name);

Vala には stdin.read_line() という便利な関数がある。
コレをどう C 言語にジェネレートしているか -C オプションで確認。
なんと自前で関数を作って適用するという恐るべし手段を使っていた。
相変わらず最適化依存のナニコレなコードを出力するが省略するとこういうこと。

#include <glib.h>
#include <stdio.h>

/* gcc src.c `pkg-config --cflags --libs glib-2.0` */

static gchar*
iostream_read_line (FILE* p) {

	GString* gstr;
	gchar* result;
    gint n;

	gstr = g_string_new("");
	while (TRUE) {
	    n = fgetc(p);
        if (n == ((gint)'\n') || n == EOF) {
			break;
		}
	    g_string_append_c(gstr, (gchar)n);
    }
    result = g_strdup(gstr->str);
    g_string_free(gstr, TRUE);
    return result;
}

int
main (int argc, char *argv[]) {

    gchar* line;

    g_printf("Hi!\nPlease enter your name: ");
    line = iostream_read_line(stdin);
    g_printf("Welcome, %s!\n", line);
    g_free(line);

    return 0;
}

glib_iostream

fgetc で 1 byte ずつチェックしヒープ領域に積み立てて最後にポインタを戻す。
なるほど、これならスタック領域の無駄も最小限だしバッファオーバーランの心配も皆無。
日本語入力も半角スペースも何一つ問題なく処理できてしまう恐るべき関数であった。
Vala を作っている人達は想像以上に頭がいいようです。

ライブラリ関数に徹底的なほど拘るのも悪くないと思うんですけど。
強引に利用するより自分で関数を作ったほうが建設的だなと。
つか、ライブラリ関数に拘る人ってモレなく何もアプリを作っていない現実がね。

Fedora 21 2015.01.05

Fedora 21 を何の不具合もなく使っていたがアップデート通知がこない。
2015.01.05 の今日やっと掛かった、しかしその後アプリがインストールできない。

sudo dnf update

を一応やってみたら何だよコレ…

fedora_update

アップデート通知が無くてもこまめにコマンドを打ちましょう。
カーネルのアップデートがあるので再起動っと。

Wayland のアップデートもあったので変更してみる。
ドラッグアンドドロップ関連がダメダメだったのが修正されている。

しばらくコッチのまま使ってみようかと思えるくらいかな。
と思ったけどログアウトに失敗する、もう少し様子見。

そういえばと vala をインストールしようとしたら何故かまたエラー。
コマンドを打ち直したら正常修了、ダウンロード失敗だったのかな?
おかげで、今頃知ったのか?と思われそうだけど。

dnf_is_python

yum も dnf も Python2 製だったのね。
おいおい、Ubuntu の update-manager ですら Python3 だぞ。
つーか中の人達(死語)はドンダケ Python が好きなんだと。

おまけで、GNOME3 にてこんなことに気が付いた。

DnD_textfile

ブラウザから文字列選択のドロップだけでテキストファイルが作れる。
内容でファイル名が作られるけど私的には日付時刻だと嬉しいのだけど。
Gedit 等にドロップするとコピペになるのは誰でも知っているよね。
ブラウザのタブバーに url をドロップすると移動になるのも常識だよね。

しかし DnD 万能すぎる、何故いままで気が付かなかったのだ?
なのだが、時代は凄い勢いでタッチパネル化なんだよな。
役場の受付番号発券機がタッチパネルになっていて驚いた。
今後は業務用アプリまでもこんな感じになっていくのだろうな。

ということで。
あけましておめでとうございます。

localStorage

二年近く前のネタだけどこんなのを見つけた。

世界が熱狂する「100万のタマゴ」アプリ 日本の個人開発者のアプリが620万DLを達成 | 【EXドロイド(エックスドロイド)】

これならスマートフォン向け Web アプリで作れそう。
しかしパソコン対応なんかにしたらネクラでキモチワルイ奴がスクリプトでアッサリ百万突破してドヤッ!てやるのが目に見える…
まあそれは別の話として。

ゲーム再開用に行うタップ回数の保持は当然ローカルストレージとなるわけで。
スマートフォンのブラウザなら必ず実装しているので使わない手はない。
問題はそのストレージ内と変数値の同期をいつどう行うか。

ページを閉じた時を検知して変数の整数値を保存が一番確実なのだが
window.onbeforeunload – Web API インターフェイス | MDN
これ iPhone で使えなかった。

サイトの後処理にはonpagehideを使う – 読み書きプログラミング ブログ

onpagehide じゃ環境依存になってしまうようだ。
やはり値変更毎に localStorage へ保存するしか確実な手段は無さそう。
しかし[ピアノ打ち]とかされた場合にストレージへの同期は追い付くのかな?

iOSのlocalStorageは非同期でディスクに保存されるっぽい – Qiita

なんてページを発見。
自動的に非同期になるなら何も問題無さそう、コードを書いて実験だ。
毎度のようにスマートフォンかエミュレートでしか動きません。

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>タップした数を記憶する</title>
<!-- for Smart Phone -->
<meta name="viewport" content="
    width=device-width,
    initial-scale=1.0,
    minimum-scale=1.0,
    maximum-scale=1.0,
    user-scalable=no" />
<style>
body {
    -webkit-text-size-adjust: 100%;
}
</style>
<script type="text/javascript"><!--

    var count = 0;

    var writeText = function() {        
        var num = 1000000 - count;
        var out = String(num).replace( /(\d)(?=(\d\d\d)+(?!\d))/g, '$1,' );
        document.getElementById("ID_TEXT").innerHTML = out;
    }
    // Event Handler
    var onTouchEnd = function() {
        if (count < 1000000) {
            count += 1;
            localStorage.setItem("count", count);
            writeText();
        }
    }
    // Connect
    var init = function() {
        if (window.TouchEvent) {
            var tap = document.getElementById("ID_TAP");
            tap.addEventListener("touchend",onTouchEnd);
        }
        /* can not iPhone
        window.onbeforeunload = function(e) {
            localStorage.setItem("count", count);
            return null;
        );*/
        if (localStorage.getItem("count") != null) {
            count = Number(localStorage.getItem("count"));
        };
        writeText();
    }
    //-->
</script>

</head>
<body onLoad="init()">

<div id="ID_TEXT" style="font-size:48pt">1,000,000</div>
<div id="ID_TAP" style="font-size:96pt">Tap!</div>
<p><a href=".">Back</a></p>
</body>
</html>

タップした数を記憶する

IMG_0097

これだけだと本当につまらないアプリです。
卵がちょっぴりづつ割れていくみたいな演出があると先が気になるってことか。
メモしとこ。