にゃははー

はへらー

Debian GNU/Hurd 2013のインストールでパーティションを切りたい

Debianのインストールから、カーネルビルドまで...はいかない - にゃははー のハマリポイント4をなんとか回避できた。

結論から言うとprocfsがmountsを提供しないのが原因で、手動で切ったパーティションがマウントされているかを確認できていなかったのが原因でした。
具体的にはDebian GNU/Hurd 2013のインストールメディアは僅差でGNU Mach 1.3.99/Hurd 0.3という古いバージョンで収録されているが、手元のGNU Mach 1.4/Hurd 0.5では/proc/mountsがあったので、頑張って手動でこのファイルを作ればよかった。

手順としては、パーティション切ったところで何とかしてshellをとって

# settrans -g /proc
# cat > /proc/mounts
/dev/hd0s8 /target ext2fs defaults 0 0
/dev/hd0s3 /target/boot ext2fs defaults 0 0

ってする。

catめんどかったらnanoで。vimもviも無いです。
あとdpkgもないので、hurd 0.5を頑張って持ってきても手で頑張ってやらないといけないので普通にproc書いたほうが楽だと思う。

/proc/mounts 以外のprocfsなものはどうやら使わないみたいなので、/procにmountsしかなくても良かったです。

expert modeでしか確認してないので他のインストール方法でどうやってshell取るかは知らないです。多分出来ないです。
ほげ〜

Debianのインストールから、カーネルビルドまで...はいかない

ディストリビューション/パッケージマネージャー Advent Calendar 2013 - Qiita の18日目です。

今回はDebianのインストールとちょっとした操作説明したいと思います。Debian系は最近あんまり使ってないのですが、選択肢が現時点ではDebianしか無いので。

何を言っているかわからないと思いますが、すぐに分かります。

ほんとはカーネルのビルドまでやりたかったのですが、文章量が増えるだけなので諦めました。

続きを読む

Boost.Range でも regular が使いたい! - C++ AdC 2013

C++ Advent Calendar 2013 - PARTAKE の12日目です。

もう一個のカレンダーの方で激おことかforkforkとか言ってたら、なんかみんな頑張ってるしカレンダー名に(fork)とか付いてしまってて申し訳ないなーとか思ってたり少しはしているのですが、特にカレンダー書く予定はないです。

ネタを Modularized Boost(GitHubへ移行したリポジトリ)を使用する | イグトランスの頭の中(のかけら) に掻っ攫われてしまったので急遽頑張って考えました。
嘘です特に考えてませんでした。

ところがつい先日会社の同期が Boost.Range に足下掬われていて丁度いいかなと思ってネタにします。

続きを読む

C++ Advent Clandar 2013 1日目 (forkした方)

※注: これはforkした方の。C++ Advent Calendar 2013

今年もAdvent Calendarの季節です。
しかも驚くべきことにC++ Advent Calendarはforkしました。あと先に断っておきますが、25日やらないです。
立ちあげた本人が表にもこちらにも書こうとしていないのは一体どういうことでしょうか。激おこです。


表のカレンダーは多分ガチなので、こっちはこれまでのC++関連のAdvent Calendarを振り返って見たいと思います。
私が参加したカレンダーしか知らないので、もしかしたら抜けがあると思いますが、ご容赦を。

続きを読む

今年参加するAdvent Calendar 2013

びぼうろく


C++ Advent Calendar 2013
担当日 :12/1(Sun)
書くこと:C++ACの傾向と対策

ついにC++ Advent Calendarもforkする時代です!!!


C++ Advent Calendar 2013 - PARTAKE
担当日 :12/12 (Thu)
書くこと:なにか

本当になにも考えていない。やばい。


ディストリビューション/パッケージマネージャー Advent Calendar 2013 - Qiita [キータ]
担当日 :12/18 (Wed)
書くこと:Debianのこと

いつもFedoraがメインで別にDebianスキーというわけでも無いけど、Debianしか選択肢が無いので仕方なくDebianで書く

Boost.Coroutine with 1.55.0 Beta 1 RC

もうBoost 1.55.0の時季となったわけで、リリースノートの翻訳作業も進めている。
Boost 1.55.0のリリースノート翻訳を更新 - Faith and Brave - C++で遊ぼう

今回はBoost.PredefというBoost.Configみたいな感じのものが来る。
どうせ誰かが解説するし、変更点とかは次のBoost.勉強会でアキラさんが発表するだろう。

ということで、私は割と見守ってきた(つもりでいる)Concurrentライブラリをつついていた。
過去にOliverはいろいろやってくれていたわけだけど、最近は何事もなかったように思えていたので気を抜いていた。
Boost.Contextの怒涛の変更 - にゃははー
Boost.Contextのnamespace - にゃははー

1.55.0のリリースノートを覗いてみると

New interface (unidirectional data transfer)

と書いてあるわけである。
フム、新しいインターフェイスかどんなものだろう。
当然www.boost.org上にドキュメントはまだ置かれないので、ソースを読む必要がある。

どうやらGeneratorを実装しましたということらしい。
邦訳版のリリースノートの方にも簡単なコード例を載せたが、一応こちらにも示す。

boost::coroutines::coroutine<int>::pull_type gen(
    [](boost::coroutines::coroutine<int>::push_type &yield)
    {
        for (int i : { 0, 1, 2, 3 })
            yield(i);
    });

for (int i : gen)
    std::cout << i << std::endl;

まぁシンプルで良いのではないか。

さて、ここまで気を抜いていた私は、そのままなんとなく昔からあるドキュメントについても眺めてみた。
coroutine.qbk

[section:coroutine Coroutine]

__boost_coroutine__ provides two interfaces - one with uni- and one with bidirectional
data transfer (deprecated).

[include unidirect.qbk]
[/[include old.qbk]]

え、old.qbkって何、
old.qbk

[section:old Bidirectional coroutine (['deprecated])]

[note This interface is deprecated but can be used by compiling the code with
compiler flag BOOST_COROUTINES_OLD.]

何を言っているかわからないだろうが、これまでのインターフェイスは非推奨となった。
BOOST_COROUTINES_OLDマクロが必要らしい。

ここでやっと私はコードを実際にコンパイルしてみようと考えた。
しかし、uniなインターフェイスでどうもコンパイルが通らない。
なんかincomplete typeがなんちゃらと言われる。
coroutine.hppを眺める。

coroutine.hpp

#ifdef BOOST_COROUTINES_UNIDIRECT
#include <boost/coroutine/v2/coroutine.hpp>
#else
#include <boost/coroutine/v1/coroutine.hpp>
#endif

え、BOOST_COROUTINES_OLDどこいった...
とりあえずBOOST_COROUTINES_UNIDIRECTつけたらコンパイル通ったし、期待通り動いたが、どうも釈然としない。

ので、あとでメール投げます。

std::bindとboost::bindとboost::asio::placeholders

c++ - Should std::bind be compatible with boost::asio? - Stack Overflow
std::bindにboost::asio::placeholder::errorを渡すと死ぬ(そりゃそうだ) - 2冊の本を3等分

Boost.Asioのasyncハンドラには多くの場合、Boost.Bindとboost::asio::placeholdersを組み合わせると思うので問題ないですが、C++11のstd::bindと組み合わせる時には注意が必要です。

boost::asio::placeholdersは実際にはBoost.Bindのboost::argを使っているので、boost::bindからすればplaceholderとして認識できるのは当然ですが、std::bindからしてみればboost::argはplaceholderではないので、そのままではstd::bindをAsioのhanlderにはできません。

これは、std::is_placeholderを特殊化することで対応出来ます。
user-defined typeのpartial specializationなので問題ない...はずです...*1

#include <functional>
#include <boost/bind/arg.hpp>

namespace std {

template <int n>
struct is_placeholder<boost::arg<n>>
  : public ::std::integral_constant<int, n> { };

} // namespace std

最近の一般的なコンパイラであれば、上の定義で問題なくBoost.Bindのplaceholderをstd::bindに叩き込めます。
が、Boost.Bindのplaceholderにはもう一つのworkaround用定義があり、あろうことかBoost.Asioはデフォルトでこちらを使います。

これを考慮すると、

#include <functional>
#include <boost/bind/arg.hpp>

namespace std {

template <int n>
struct is_placeholder<boost::arg<n>>
  : public ::std::integral_constant<int, n> { };

template <int n>
struct is_placeholder<boost::arg<n>(*)()>
  : public ::std::integral_constant<int, n> { };

} // namespace std

となります。

Boost.Asioだけでいいなら下の定義だけあればstd::bindを使うことができます。

# どうでもいいけど、はてぶろ未だにトラバ送れないのかな...

*1:n3337 17.6.4.2.1読んでたら混乱し始めた...