150cc on a rainy day

愛知から下関(旧豊浦郡)の実家にはいつも新幹線なのに今回はバイクな理由。
そう角島大橋、地元すぎて一度もいったことがないので用事のついででツーリング。

IMG_0016

したら土砂降りだwww
実はこのレポ 2013.08.24 です、つまり島根県今年二度目の集中豪雨の日。
雨の角島大橋(と私の Fighter)画像も粋なもんさ。

あー晴れていたらスッゲェ気持ちイイんだろうなヽ(;▽;)ノ
とか叫びながら橋を往復したのは言うまでもない。

漁師な実父の情報によると中央のボッコリ部以外を船で抜けようとすると座礁するらしい。
漁船の事情でこんな型になっただけなのに超有名観光地化って世の中は本当に解らない。

で、最大の目的を果たしたところで。

多分なんとかなるさ、ということで以後の山陰ツーリングを決行。
ズブ濡れツーリングのレビューができて得したんだ、と自己催眠を掛ける。

R191 をガンガン進むが萩手前から通行止めで R262 へ迂回。
いきなり観光予定が狂う、あぁ怪しくなってきた。

津和野付近の川が凄い水嵩に、鯉は大丈夫?
でココもスルーすることに、雨は当然小降りになる気配すらない。

なんかもう、観光どころか本日ゴールの米子まで辿り着くことが目的になりそう。
せめて出雲大社だけにはどうしても寄りたいのだが。

道の駅シルクウェイにちはらで飯と島根災害情報の確認。
R9 も通行止めオンパレード臭い、これはマジで不安。
ビショビショのままな合羽と手袋を再び装着し東へ急ぐ。

江津市(ごうつし)でとうとう完全に止められる。
150cc の機動力で脇道を進むもその細い道すらも通行止めロープが。

完全に東へ進む手段を失った。
雨が一時的とはいえ止んだのはせめてもの救い。

土砂崩れ部手前の大渋滞でヘルメットを脱いでしばし途方に暮れていた。
後ろの車の人が降りて話しかけてくれしばし雑談、そのとき神の一言。

「歩道は通れるみたいだからソイツなら押してイケるんじゃない?」

細かいことは忘れたけどそんな感じで。
エンジン切って押せば歩行者だ、その手があったか、押したよ、上り坂だったけど。

ユンボで崩れた木と土砂をトラックに積んでいる現場もしっかり見えたよ。
抜けれたよ、ありがとうバイクはスカブ乗りだという人。

抜けた後の道もあちこちで土砂崩れしていた。
けど軽量で低重心の 150cc スクーターであるおかげでコケずに脱出できた。
一部区間は押して抜けたので足元が泥だらけになったけどさ。
CBR だったら絶対にコケていた、あの手は寝かせやすいように重心が高いもん。

まさかの 150cc スクーターで来たからなんとかなったという現実。
はたして私は運がいいのか悪いのか。

ところで山陰の道は自動車専用道路だらけ、道の駅すら自動車専用道路上に。
150cc が最適とは言わないけどピンクナンバー車だと泣くはめになるよと。

その後も通行止めの遠回りを何度も強要されるがなんとか前に進めた。
でももはや出雲大社に寄る時間なんてまったくない。

マジで今日は角島にしか行っていないまま終わるのか、何しに来たやら。

小降りの中、予定の一時間遅れでなんとか予約していたホテルに到着。
備え付けのドライヤーで靴等を乾かす間の情無さといったらもう…
明日は愛知の自宅まで、天気予報は明日も雨。

なんとかなるよ、絶対大丈夫だよ。

********************

さて、土砂降りで一番困ったのはお金。
札が湿気でフニャフニャに、合羽の中でもシート下でも無意味だった。

札はジップロックに入れて五百円硬貨を大量に手持ちするのが吉かと。
旅先のレシートを取っておきたい場合も、私は途中で全部捨てるはめに。
問題は高速道路の通行券とかだな、こんなマシンで ETC な人は少ないだろうし。

あとバックに手持ちだったコレを無理矢理利用している。
ベルトをシートにユルく這わせシートを閉めた後ピンと張れば固定できる。
ピンと張らないとブレーキ毎にケツに激突します。

レインカバーは同梱物にあるけど下から水が結構染み込んできます。
コイツで長時間雨中を走るならビニール袋で中身はガードしておこう。

肝心の人間は十時間以上雨の中をムレムレ合羽で走ったのに平気なものです。
ホテルでシャワーを浴びた後はアラいつもどおり。
ただ明日も合羽を着て走るのかと考えると滅入ります。

結論、ズブ濡れツーリングは余程の理由が無いかぎりヤメておきましょう。
コレはコレで楽しかったけどね。

SYM New Fighter 150 ZR

150cc のスクーターが気になる。
自分の利用範囲から 125cc くらいのサイズと重量が丁度イイ。
けどピンクナンバーでは自動車専用道路の無料区間すら走れないのは困る。
大型と二台持ちをするほど二輪が大好きなわけじゃない、つかそんな贅沢は無理。
ならば 150cc という手段があるじゃないかと。

とはいえピンクナンバーより割高な維持費を払う価値はあるのだろうか?
実際に高速道路はどうなのよ、長距離ツーリングはどうなのよ?

ということで自分で試す。
現在の愛車は台湾 SYM の New Fighter 150 ZR というマシン。
PCX は多過ぎなのと 125 とデザインが同じことが気に入らずコレを選んだ。

さて、愛知から山口へ往復の三泊四日の旅へ。
下関市(旧豊浦郡)の実家に用事があっただけなんだが、ついでに。

まず名神高速で一宮 IC から吹田 JCT へ。
近畿道に入り大阪南港のフェリー乗り場まで。
門司港までフェリー、関門トンネルを通り R191 に入り実家へ。

帰りは国道 9 号線を観光しながらオール下道、米子で一泊。
という高速道路と長距離とついでにフェリーというコースにした。

**********

さてこのマシンで初めての高速道路だ。
ガソリンを満タンにしてイザ一宮 IC へ。

あれ、普通に走れる。
100Km/h ちょっとしか出ないマシンだが全然怖くない、意外だ。
もちろん遅いトラックの後を付いていっているだけですけど。
直進安定性も問題なし、やるな台湾製。

前車が 70Km/h 以下になったら追い越しをかけることもできた。
でも関ヶ原の上りでは 80Km/h を切りそうになり焦る。
やはり高速の上りはキツい、今度から新名神ルートにしよう。

草津 PA で給油、いやこのマシンは 120Km 程度でランプが付くので。
燃費は街乗り平均 32、高速は今回だけだが 36 程度というところか。
慣らし中は 40 いったんだけどな、回すとこんなものか。

近畿道に入り渋滞を挟みながら順調にフェリー乗り場へ。
手続きを済ませ時間が余ったのでガソリンを入れに。
もう少しタンクを大きくできなかったのかなぁ。

ということで 150cc にて高速道路を走ってみた感想。

「登坂車線を走るなんて俺のプライドが許さないぜ!」
というお金で手に入るものにしがみ付く器の小さい人間でなければ充分に走れます。
多分軽トラックで走っているような感覚かと。

意外だったのは高速走行で全然疲れない、特に手がまったく痺れない。
以前乗っていた CBR250R はたった二区間で手が真っ白になっていたのだが。
排気量ダウンなので更に酷いのを覚悟していたけど不要な心配だった。
スクーターなので足は当然疲れないw

12 インチの小さいホイルのくせに安定感も充分。
欠点は本当に上り坂とガソリンタンク容量だけ。

車種によって違うだろうけど Fighter ならこんな感じ。
積極的に使いたいとは思わないけど問題は無いというレベル。

フェリーは予定通り門司港に午前 5:30 到着。
いざ下関へ、150cc の関門トンネル通行料金は百円だった。
ちなみに関門トンネルは二輪ではクソ熱い、関門橋のほうを勧める。

IMG_0012

毘沙ノ鼻は 8:30 まで開いていないので注意。
帰りの山陰下道は次回。

Empty the Clipboard. and Set Clipboard Text

Gedit の GtkToolbar を見ていて気が付いた。

Clipboard が空の時に Gedit を起動。
ウエブブラウザ等の別アプリで Ctrl+C を押し何か文字列をコピー。
すると Gedit の貼り付けアイコンが自動的に有効になる。
当然 Ctrl+V で貼り付け可能。

リアルタイムで監視していたんだね。
クリップボードに何か入っているかのインジケータとして使える、便利だ。

それはともかく、ウエブブラウザを終了してもクリップボードに残っている。
あれ?以前はコピー元を終了すると使えなくなっていたはずだが。
GNOME2 時代の古い記憶だから今は変わっているのかもしれない。

よし実験、ちなみに今後このブログは Python3 コードで書きます。

#!/usr/bin/env python3

from gi.repository import Gtk, Gdk

"""
    Empty the Clipboard.
"""

display = Gdk.Display.get_default()
clipboard = Gtk.Clipboard.get_for_display(display, Gdk.SELECTION_CLIPBOARD)
clipboard.set_text("Failed", -1)

だめジャン!
と思ったけど Gedit のツールバーを見ると貼り付けアイコンが無効になっている。
つまりこうするとクリップボードを空にできるってことみたい。

不本意だがクリップボードを空にする方法を発見してしまった。
使い道はともかく。

何故だろう、我が clipoli と同じコードを書いているのに。
もしかして mainloop が必用なのだろうか。

clipoli から mainloop を通る最小限コードを抜き出して実験。

#!/usr/bin/env python3

from gi.repository import Gtk, Gdk

"""
    Success additional main loop
"""

class ClipboardTest(Gtk.Menu):
    def __init__(self):
        Gtk.Menu.__init__(self)
        menuitem = Gtk.MenuItem.new_with_mnemonic("_Set Clipboard Text")
        menuitem.connect("activate", self.on_menuitem)
        self.append(menuitem)
        self.show_all()
        self.popup( None, None, None, None, 0, 0)

    def on_menuitem(self, widget, data=None):
        display = Gdk.Display.get_default()
        clipboard = Gtk.Clipboard.get_for_display(display, Gdk.SELECTION_CLIPBOARD)
        clipboard.set_text("Sucsess", -1)
        Gtk.main_quit()

ClipboardTest()
Gtk.main()

これなら上手くいく、やはり一旦メインループを回す必用があるみたい。
つまりループ無しだと set_text に NULL ポインタが入ってしまうのかな。
とにかく挙動は解ったので内部の細かいことはイイや(ぉい!

しかし gtk_main_quit を呼ぶ必用があるのでコードが冗長だ。
メニューを出さなくても呼べる何か上手い手段は、、、

そうだ GtkApplication があるじゃないか。

#!/usr/bin/env python3

from gi.repository import Gtk, Gdk

"""
    Put the text to clipboard.
"""

class App(Gtk.Application):
    def __init__(self):
        Gtk.Application.__init__(self)
        self.connect("activate", self.on_activate)
        
    def on_activate(self, data=None):
        display = Gdk.Display.get_default()
        clipboard = Gtk.Clipboard.get_for_display(display, Gdk.SELECTION_CLIPBOARD)
        clipboard.set_text("Success", -1)

app = App()
app.run(None)

GtkApplication ならこんなにスッキリなコードに。
クリップボードにスパッと特定文字列を入れるコマンド程度なら簡単に作れるね。

**********

そういうことなら minipoli の Linux バージョンもイケそう。
なんて思ったけど。

ctrl_c

Nautilus で Ctrl+C して Editor で Ctrl+V すると実はフルパス貼り付けができる。
gnome-terminal に DnD する、そこから Ctrl+Shift+C なんて手段もあるし。
GNOME って便利すぎ、デフォルトでコレだもん。
たまに Windows を使うと何も出来なくてイラッとするのは私だけなのか?

何より GetAsyncKeyState に相当する API が Gtk には無いようだ。
minipoli の移植は作るだけムダだしムリっぽいかな。
でも Palepoli 復活という手もあるな、誰も覚えていないだろうけど。

Change in Python3

Y901x を Python3 化してみた。
Python3 って pyc キャッシュは __pycache__ ディレクトリに入るのね。

言語としての一貫性を重視したPython 3の進化 ? @IT

Y901x は gir 以外は sys, os, time の標準モジュールしか使っていない。
多分文字列と割り算さえ気を付ければそれほど変更点は無いだろう。

Python3 はデフォルトが UTF-8 なので coding 指定が不要に。
これで海外の Python 製アプリの動作が変という場合は減ると思う。

#!/usr/bin/env python
#-*- coding:utf-8 -*-

to

#!/usr/bin/env python3

例外はカンマから as に変わり raise も関数(?)になった。

#except Exception, e:
except Exception as e:

#raise ValueError, "hoge"
raise ValueError("hoge")

忘れちゃいけない unicode 関数を使っていた部分は str にして。

#s = unicode(entry.get_text()) # Python2
s = entry.get_text()
i = s.rindex(".")

割り算で整数にならないと困る部分は / を // に書き換えて。
/= も //= にしないといけないのか。
逆に float にキャストしていた部分はキャストを外して。

Python 歴があるなら誰でも知っていることはこれくらいで。

他 Fedora 19 の gir を色々試してみると
GLib.filename_from_uri 関数の動作が Ubuntu 13.04 と同じになった。
Gio.ApplicationFlags.HANDLES_OPEN も使えるようになった。

しかし Gio.ActionEntry が作れず ApplicationMenu は使えないまま。
使えるなら多重起動防止の設定を追加しようと思ったけどまだムリっぽい。
pygobject のバージョンに今後も振り回されるんだろうな。

今頃気が付いたけど inifile8.py に古いものを使っていた。
Python3 互換の文字列フォーマッタ版を随分前に作ったのにアホだ。

思ったより簡単だと変更していたけど問題は文字列や割り算ではなかった。
自然順ソートを行う numsort.py だった。

Python3 には cmp 関数が無い、いやコレの自作だけなら簡単だけど。
sort(), sorted() の引数が違う、てか比較関数が使えない。

ソート HOW TO ? Python 3.3 documentation

自力でクイックソートを作るか cmp_to_key をコピペするかだね。
cmp_to_key 関数を使うとなるとこんな感じでいいようです。

#! /usr/bin/env python3

from gi.repository import GLib, Gio

def sort_func(str1, str2):
    """
        str1.encode("utf8") is not required.
        Not 'cmp' function in Python3
    """
    cmpstr1 = GLib.utf8_collate_key_for_filename(str1, -1)
    cmpstr2 = GLib.utf8_collate_key_for_filename(str2, -1)
    # cmp function
    if cmpstr1 < cmpstr2:
        return -1
    elif cmpstr1 > cmpstr2:
        return 1
    return 0

def cmp_to_key(mycmp):
    """
        http://docs.python.org/3.3/howto/sorting.html # en
        http://docs.python.jp/3.3/howto/sorting.html # Japanese
        Convert a cmp= function into a key= function
    """
    class K(object):
        def __init__(self, obj, *args):
            self.obj = obj
        def __lt__(self, other):
            return mycmp(self.obj, other.obj) < 0
        def __gt__(self, other):
            return mycmp(self.obj, other.obj) > 0
        def __eq__(self, other):
            return mycmp(self.obj, other.obj) == 0
        def __le__(self, other):
            return mycmp(self.obj, other.obj) <= 0
        def __ge__(self, other):
            return mycmp(self.obj, other.obj) >= 0
        def __ne__(self, other):
            return mycmp(self.obj, other.obj) != 0
    return K

def get_file_numsort_list(dirname):
    """
        param dirname: Directory Full Path Name
        return: List in Numeric Order
    """
    files = []
    d = Gio.file_new_for_path(dirname)
    enum = d.enumerate_children(
            Gio.FILE_ATTRIBUTE_STANDARD_TYPE,
            Gio.FileQueryInfoFlags.NONE,
            None )
    for info in enum:
        if info.get_file_type() == Gio.FileType.REGULAR:
            s = info.get_name()
            if not s.startswith("."):
                if not s.endswith("~"):
                    files.append(s)
    # Python2
    #files.sort(lambda x, y : cmp(GLib.utf8_collate_key_for_filename(x, -1), 
    #            GLib.utf8_collate_key_for_filename(y, -1)))
    #
    # Python3
    files.sort(key=cmp_to_key(sort_func))
    return files

これじゃラムダ式にできない、別にいいけど。
随分コードが長くなってしまったけどアプリケーションは動けばいいのさ。
アーカイブサイズが減った理由がワカラナイ…

GLib.utf8_collate_key_for_filename は str のままイケた。
GLib で文字列として扱う場合は UTF-8 で得られるということみたい。
でも Python 文字列として扱う場合は UCS-4 であるのを意識する必用あり。
でいいのだろうか、いつか落とし穴にはまりそうな気もする。

ついでに PyGI で今更気が付いたこと。

class CToolBox(Gtk.Box):
    def __init__(self):
        Gtk.Box.__init__(self, orientation=Gtk.Orientation.VERTICAL)

GtkBox は GtkOrientable をインプリメントしているから orientation property がある。
なのでこの指定で GtkBox のサブクラスを作れば GtkVBox と同様になる。
いやプロパティは全部 __init__ の引数にできるのを知ったのは最近だし。

y901x101

とりあえず Python3 化した Y901x 1.0.1 公開。
memopoli の更新をやるべきなんだろうけど、実はもう使っていないのだがどうしよう。

1.0.1 Download (34.0kb)

blog にもリンクを今回から貼ることにする。
需要は無いだろうけど何かの参考になればいいや。

google-chrome 28 libpeerconnection.log

Fedora 19 で google-chrome 28 を起動すると
SELinux is preventing /opt/google/chrome/chrome from create access on the file libpeerconnection.log.
と SELinux に怒られる。
そのうち修正されるだろうと都度解除ボタンを押していたが辛くなってきた。
ポリシーツールもチョロメもまったくアップデートに出てこないし。

SELinux ポリシーを自力変更しようとしたが何故か audit2allow が見つからない。
これじゃトラブルシュートできないよ、手段が変わったのだろうか?

なんとかしたいので libpeerconnection.log で検索してみる。

Ubuntuのlibpeerconnection.logって何? 自分は今、Ubuntu13.04を使っていますが、… – Yahoo!知恵袋

Ubuntu だと SELinux が無いからブロックは無いけどホームに log 生成らしい。
なんだそれ、通信ログだろうけどカレントディレクトリに吐き出しているってこと?
完全に chrome 側のチョンボであるようだ。

ということは SELinux の場合 setsebool する必要でもあるのかな。
つかホーム直下に log ファイルを作られても困るんだが…

Issue 239048 – chromium – libpeerconnection.log file created in CWD – An open-source project to help move the web forward. – Google Project Hosting

そうか、カレントを /tmp に変更してしまえばいいんだ。

sudo gedit /opt/google/chrome/google-chrome

linux_chrome28_fix

SELinux はスルーされ、しっかり libpeerconnection.log は /tmp に生成。

tmp_ls

あぁ普通に起動できる、普通って素晴らしい。
しかし当面は chrome アップデート毎に行う必要があるかも。

生成された libpeerconnection.log のセキュリティコンテキストを見ると
chrome_sandbox_tmp_t とよくワカランものになっている。
サンドボックス領域での通信ログをホームに保存だと SELinux は弾くということか。
テンポラリになら保存できるのならあまり意味が無い気もするんですけど。