2019年5月20日月曜日

Walterbot の「View log」 がすごく便利!

ブログズミ: [Wercker] Walterbot + Slack を試してみた

この記事を書いた時点では「View log」はなかったので紹介してませんでしたが、
これがすごく便利なので改めて紹介します。
(Walterbot については↑を参考にしてください)

View Log ボタンでエラーの周辺ログが見れる!!


「View Log」ボタンを押すと以下のようにログが見れます。


iutest の Wercker でのテストは
fused したコード(1ファイル化したもの)をさらに圧縮して(js の min.js みたいな) Wandbox に投げつけてコンパイル&実行しているので、エラーがすごく見づらいのですが・・・

ともあれ、すごく便利なので Wercker 使いの方は、ぜひ Walterbot を使いましょう!!

2019年5月13日月曜日

[C++] g++ 9.1.0 で variant が valueless_by_exception にならないケースに遭遇した

iutest の開発をしていたら、variant が valueless になったときのテストが失敗するようになった。


テストコードはこれ。
valueless_by_exception と出力されるのを期待しているが、実際には 0.2 という空になる前の値を出力している。

{
    PrintToLogChecker ck("valueless_by_exception");
    ::std::variant<int, ::std::string, float> v = 0.2f;
    try
    {
        struct S { operator int() { throw 42; } };
        v.emplace<0>(S());
    }
    catch(...)
    {
    }
    IUTEST_SUCCEED() << ::iutest::PrintToString(v);
}

この valueless にするコードは、
https://ja.cppreference.com/w/cpp/utility/variant/valueless_by_exception からとってきたもので、今までは valueless になっていたのを確認している。

関連するコードをいじってはいないので、環境周りの違いだと思い確認したところ、g++ 9.1.0 では valueless にならないことを確認しました。
また、valueless な状態を作る方法を探していたら、
https://cpprefjp.github.io/reference/variant/variant/valueless_by_exception.html に AlwaysThrow でのサンプルがあったので、そちらを使って確認したところ g++ 9.1.0 でも valueless になりました。

(typo がひでぇ)



よって、テストコードとりあえず以下のように修正しました。
{
    PrintToLogChecker ck("valueless_by_exception");
    ::std::variant<int, float, AlwaysThrow> v = 0.2f;
    try
    {
        struct S { operator int() { throw 42; } };
        v.emplace<0>(S());
    }
    catch(...)
    {
        IUTEST_INFORM_TRUE(v.valueless_by_exception());
    }
    if( !v.valueless_by_exception() )
    {
        try
        {
            v = AlwaysThrow();
        }
        catch(...)
        {
           IUTEST_INFORM_TRUE(v.valueless_by_exception());
        }
    }
    IUTEST_SUCCEED() << ::iutest::PrintToString(v);
}

これはバグ?
cpprefjpcppreference.com も、サンプルのコメントを読むと、確実に valueless な状態にはなるとは限らないように読み取れるのだが、(規格的に)これはそういうもんなのだろうか?それとも g++ 9.1.0 のバグなのだろうか?

一旦ここまでで記事公開させていただきます。
続報あれば、追記していきますmm



2019年5月7日火曜日

[Git] マージするときのリネーム上限とリネーム判定の抑制

最近、テスト結果を蓄積する試みをしていたら、git の挙動でハマったので備忘録として残しておきます。

git は意図的なリネームが可能ですが、意図しないリネームが発生したりすることがあります。
これは、リネームは削除と追加がまとまったもので(ほぼ)同じ内容のファイルが削除と追加(別名で)されたときに、git はリネームとして処理することがあります。
なので、こちらとしては望んでいない場合でもリネームとして扱われてしまうことがあります。
(ほとんどの人はこんなケースには遭遇しない気がするけど・・・)

で、なにが起きたかというと、
リネームが大量に検出されて、マージするときのリネーム上限に引っかかってしまいました。



というか、上限なんてあったんだ!という感じでしたが、git config merge.renameLimit で上限解放できるらしいです。
git config merge.renameLimit 9999


そもそもリネームじゃねぇっ!という場合は、merge.renames でリネーム処理を行わないようにもできます。
git config merge.renames false


たぶん、こういうケースにあたる人は少ない気がするけど、
merge.renameLimit と merge.renames config の紹介でした。
では。