「 プログラミング 」一覧

VisualStudio で for Linux Development


以前に VisualStudio で Linux での開発に向けて色々とやってみましたが、今はまた新しい方法があるようだったので試してみました。今回は Linux 側として Fedora23 を使用してみます。特殊なことはしていないため他のLinux系のものでも適用可能だと思います。

vs_linux_8

これらの環境設定の手順などを説明していきます。 続きを読む


MobaXterm が便利


SSHのクライアントとしては Tera Term を愛用しているのですが、とあることから MobaXterm というソフトを知ったので試してみました。これが便利でしばらく使ってみようと思います。

なにが良いかといいますと、これ単体で Xサーバーが内蔵されており、 OpenGL のアプリケーションも動作させることができた点にあります。このときの様子を撮影してみたので貼ってみました。
mobaxterm_opengl

これは Windows10 上で別PCに Ubuntu 16.04 LTS をインストールしたターゲットに接続して、試してみたときのものとなります。OpenGL アプリとして定番のものを動かしてみました。また OpenGL ES2.0 のアプリも動かしてみました。
どちらも動いていることが確認できます。

1つ残念な点は OpenGL は LLVMpipe によるソフトウェア実装が動いている点ですが・・・動くだけマシといったところですね。

この MobaXterm で設定で OpenGL のハードウェアアクセラレート ON というのが見当たったのですが、有効にしてみたところ妙な挙動になってしまいました。以下のように一見動きそうな感じなのですが、実際に動かすとフリーズしたかのごとく重い動作になってしまい・・・使えませんでした。

mobaxterm-opengl_2

他にもこのMobaXtermのよいところは、ホームディレクトリがすでに sftp で見えているため、ドラッグアンドドロップでファイルをやりとりできるところがあります。今までは別ソフト使っていたりしたのでこの1つに集約することができそうです。


Wayland でウィンドウを出す


前回はディスプレイサーバーに接続のみだったため、今回は画面に見えるようにするところまで紹介したいと思います。

プログラム

ウィンドウを出してみるプログラムは以下のようになります。
このコードで真っ黒のウィンドウが表示されますが、終了手段はコンソールで Ctrl+C で閉じることになるので注意してください。

このプログラムの解説は後半で行います。

プログラム解説

コードの流れとしては以下のようになっています。
サーバー、クライアントのプログラムであると言うことを意識すると理解しやすいかもしれません。

  1. コンポジッタに接続
  2. コンポジッタ上の各情報を取得&自分の関数コールバックを登録
  3. 描画用バッファを共有メモリで作成して登録
  4. バッファに描画データを書き込み、wl_surface_commit で登録
  5. wl_display_dispatch でいわゆるイベントループを回す

各Listenerはサーバーであるコンポジッタからの応答を実装する部分となります。

wl_shell 関連は表示している surface に対してのユーザーからの対話部分、すなわちキーボードやマウスの関連を実装するものとなるようです。
今回はこれらを何も処理していないため、まだウィンドウとして完成していない状態です。

これだけのコードがあるのにまだウィンドウとして完成していないあたり、低レベルのインターフェースである実感がありますね。


はじめての Wayland


ぼちぼち Wayland というものが標準で使用可能になっていく気配を感じたので、
Xorg ベースから切り替えが必要かと思って調べてみました。
先日は X11 なしで OpenGL の連載をしていましたが、今度は Wayland を使って OpenGL を使うというゴールに向かって話を進めていきたいと思います。前回はフルスクリーンのみでの動作でしたが今回はウィンドウシステムありでとなります。

Wayland とは

検索してもらうといろいろと情報が出てくると思いますが、
これはディスプレイサーバーのプロトコルであり、Wayland-client というライブラリが存在します。またwayland コンポジッタというものが画面の表示を行います。
そして weston というものが wayland コンポジッタのリファレンス実装となっています。

X-Windowの場合ではサーバ、クライアントは別のPCでも使用可能でしたが、Wayland の場合には同一端末上を想定しています。

実験環境

以下の環境で実験しています。

  • ArchLinux (64bit)
  • VMware Workstation 12 Player
  • weston 1.10

はじめてのWayland通信

まだ何もウィンドウが出せませんが以下のコードで、
ディスプレイサーバーに接続して情報を少し出してみることが可能です。

これを実行すると以下のような結果が出てくると思います。


VisualStudio 2015 で Linux アプリの開発&デバッグ その2


前回は単独のプロジェクトでソースコードも1つだったので、
今回はスタティックライブラリを使用しての複数のソースコードで動作を試してみたい思います。

準備

前回はソースコード単独でビルドできる状態だったので、実行体の生成のため gcc を呼び出すコードを書いていました。
今回からは複数のコードやライブラリのリンクと言ったことも考慮するためにこの部分を make コマンドを実行するように変更しました。
これにより Makefile さえエディットすれば、ソースコードの変更に対応できるようになります。注意点としては VisualStudio でのプロジェクトへのソースコードの追加と、Makefile の中身は同期されないので、手動(もしくは他の手段で)同期をとる必要があるかもしれません。ただ大事なのは Makefile なのでこちらをエディットすることを守ればなんとかなりそうです。

具体的にはプロジェクトのプロパティで Build Command Line を以下のように変更しました。(実際にはこれを1行で記入してください)
vs2015-target-linux-use-staticlib-0

またプロジェクトに登録したファイルの転送は考えたくなかったので、Linux で Samba を導入し、共有フォルダに VisualStudio のプロジェクトを作るようにしています。

続いてスタティックライブラリの準備にとりかかります。
続きを読む


VisualStudio 2015 で Linux アプリの開発&デバッグ


VisualStudio 2015 で別PCで動いている Linux 環境でのアプリ開発およびデバッグということができるかを試してみました。

必要なものは以下の通りです。

  • Linux環境の別ターゲット
  • VisualStudio 2015 を ”Visual C++ Android 開発”付きでインストール

ここでは VisualStudio 2015 Professional, Windows10 Pro (x64) で確認しています。
vs2015-target-linux-11

セットアップ

最低限の必要なものは準備が終わっているものとして、環境構築の説明をしていきます。

Linux側の準備

ここでは少し古いですが CentOS 6.5 の環境があったのでこれで説明します。
Samba を用いて Linux-Windows のファイル共有ができるように設定しておきます。
またコードのコンパイルを Linux で行うために、コンパイラなどのツールチェインをインストールしておきます。

Windows側の準備

Visual Studio GDB Debugger 」という拡張プラグインをインストールします。
これは以下のページからダウンロードすることができます。
https://visualstudiogallery.msdn.microsoft.com/35dbae07-8c1a-4f9d-94b7-bac16cad9c01
VisualStudioGDB.vsix というファイルがダウンロードされるので、ダブルクリックでインストールを行います。
(本プラグインは Microsoft のデジタル署名がついているようでした)

このプラグインが Plink を使うようなので、Putty のページからファイルを取得してきます。
Putty のページ: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

インストールしてしまっても良さそうですが、開発環境に tortoise Git も入っており、こちらが標準で使っている TortoisePlink でないものを設定済みだったりするとかち合うため、安全を考えて zip アーカイブを取得することにします。

そして、これを適当なところに展開します。ここでは C:\tools\putty に展開しました

続きを読む


Ubuntu で DirectFB が試せないかテストしてみました。


DirectFB なるものの存在を今更知ったので動くか確認してみました。(ほんとに今更・・・)

必要なもののインストール

設定

.directfbrc という設定ファイルに以下の内容を記述します. こうしないとエラーが起こってしまいました。
こうしておくと X11 の上で動作させることが出来ました。

サンプルコード

StackOverflow かどこかで公開されていたコードを試してみました。 続きを読む



Git LFS を使ってみる


Git はソースコードの管理ツールのため、巨大なバイナリファイルの扱いが苦手でした。これに対応すべく開発されたのが LFS: Large file storage という機能です。
今回はこれをインストール&触ってみたいと思います。なお環境はすでに git for windows がインストールされた環境で行っています。

ちなみにこの記事の内容は Git for windows 2.7.2, git-lfs 1.1.1 を用いての内容となってます。バージョンが異なる場合、以下の内容とは変更になっている可能性があるのでご注意ください。

GIT LFSについて

扱いとしては git のエクステンションという形になってます。
提供する機能は、指定されたファイルタイプの場合に特殊な処理を行うようになります。
この処理というのが、バイナリファイルを指し示すリンクをソースコードの場合と同じように保持するようにして、バイナリファイル自体はそのリポジトリとは別の場所に管理させる、というようなものです。

このLFSですが、前身になるようなものとして、git-media, git-fat などがありました。これらを使用していた人は同じようなものだと考えてもらってよいと思います。
LFSのメリットはすでにGitHub や、ほかのホスティングサービスも対応を始めているため、バイナリファイルの扱いに対して準標準を得られるのでは、というところもあるかと思います。

git lfs のインストール

https://git-lfs.github.com/ からインストーラーをダウンロードします。
この記事を書いているときには、 git-lfs-windows-1.1.1.exe でした。
このインストーラーをダブルクリックで起動してインストールを行っていきます。

インストールする場所ですが、 Git for windows をインストールしたフォルダで、
mingw64/bin 以下になるようにします。以下の図では標準の場所を指していますが、Git for Windows を別の場所にインストールしている場合ではここを修正する必要があります。
(現時点ではすでにインストールされているgit のインストールパスは探索されない模様)

インストールが終わって Git Bash を開き、以下のコマンドを実行します。

このように表示されればOKです。 git lfs init というコマンドもあったようですが、廃止扱いになっており、今は git lfs install が正しいようです。

動作を確認してみる

まずは適当な git リポジトリを用意して、動作を確認していきたいと思います。

Git lfs では LFS として管理させるファイルタイプを選択、設定します。
ここでは、よく使う画像ファイルを登録したいと思います。
この登録は以下のようなコマンドによって行います。

これらの情報は .gitattributes に格納されます。上記の実行結果で以下のようになっていました。

この .gitattributes ファイルを開かずとも、 git lfs track コマンドで確認することもできます。

さて登録したタイプにあうような適当なファイルをコミットしてみます。
ここでは png のファイルを追加・コミットしてみます。
以下のように行いましたが、これは通常の git のファイル追加・コミットと変わらないです。

これが LFS の管理になっているかどうかを確認するのに以下のコマンドを実行します。

正常に機能していれば上記のように、ファイル名とその何らかのハッシュ値が表示されます。

リモートリポジトリとのアクセス

ローカルでの機能確認ができたら、リモートとのアクセスを試してみたいと思います。
現時点では GitHub は、 1GB までは無料でLFSが使えるようなのでこちらを利用したいと思います。

GitHub で新規のリポジトリを作成し、そのリポジトリをリモートするように今回のリポジトリを設定しておきます。

そして普通に git push origin master を実行してみます。

というように普通に成功しました。
(ほかの設定も必要なのではと思っていましたので意外でした)

さて、正常にあがったところでこのリポジトリを別の場所で clone してみたいと思います。新規に取得してみることが目的なので、別PCでやってもかまいません。

内部的には追加したバイナリファイルは単なるテキストファイルに変わっています。
しかし、clone,pull などのコマンド実行の際には、LFSがうまく実行され、バイナリファイルが復元されます。

などと表示されている行がまさにバイナリファイルを取得している状態を示しています。

まとめ・感想など

準公式での巨大バイナリデータに対する対策が入ったことは大きいと思います。
最低限の LFS の動作を確認してきましたが、Git をコマンドで扱っている人にとってはすでに実用になるかなと思います。

tortoisegitとの組み合わせについて

1.8.16.0 のバージョンを使っている場合での話になりますが、ちょっとまずい点がありそうです。
「 TortoiseGit commit with git-lfs files, show me a error: “.git/index.lock” file exist」
というエラーがあるようで、これが 1.8.16.4 かそれ以降のバージョンで修正されるようです。

バイナリ状態がちょっと怪しい挙動

バイナリファイルを含むリポジトリを clone した際にバイナリファイルが復元されないケースがありました。このときファイルを試しにテキストエディタで開いたら以下のようになっていました。

このときバイナリデータの復元はどうするかというと、以下のコマンドによって復元(再取得)が行えます。

これによりデータが元のバイナリデータとして復元されます。

このような状態に陥っているときには、バイナリファイル復元した状態がすでに変更状態と見なされてしまうようで、最低限のデータ取り出しを行ったら、新規にリポジトリを作成・取得し直しといったことを行った方がよさそうでした。

対応プロトコルについて

Git LFSは大容量ファイルに対するサブのリポジトリを作ってそこにデータを放り込みます。このときの通信は http となるようで、前身の git-media のほうが対応種類が多くて状況によって適切に使い分けができた気がします。LFSもまた対応が広がってくれるとうれしいのですが。

LFSによる前提の崩壊?

従来からの使用者の感覚としては、ソースコードと大容量ファイル、それぞれ別管理という印象が強いですが、この機能が標準になってさえしまえば、これらをまとめた単位がリモートのリポジトリという1つのまとまりという認識に変わりそうです。
1つ気になった点としては、LFSリポジトリ(別の置き場を今はこう呼んでおきます)ができて、ここから必要なデータだけを復元するやり方によって、
開発者全員が全てのリポジトリデータのクローンを持つわけではなくなったと考えられます。
そのため、少々強引な表現ではありましたが「分散リポジトリだから開発者全員が同じリポジトリデータを持つ」は崩れてしまった前提になるのではないかなと感じます。
(そもそも公開されていないブランチもあるでしょうから、全員が同じリポジトリデータを持つわけではなく、単に公開されているものにおいては同じ、くらいなのですが)

LFSリポジトリデータ自体のクローンは行われないわけなので、ここにたまっているデータをきちんとバックアップしてあげる仕組みがないとトラブル時にバイナリを失ってしまうということになるのではと心配が残ります。

試しに適当な場所にリポジトリをcloneした後で、リモートリポジトリを削除し、ブランチの移動やら任意コミットへのcheckout を実行したところ、バイナリファイルの復元に失敗してしまうようでした。


X-Window なしで OpenGL ES2 を使う その3


Ubuntu で NVIDIA のボード&ドライバを使って試してみました。

NVIDIA のプロプライエタリドライバをインストール

今回使用したのが NVIDIA の Geforce 750 Ti だったのですが、
Ubuntu 15.10 の標準インストールで使える nouveau ドライバでは通常の描画からして異常で使い物になりませんでした。
そこでプロプライエタリドライバをインストールするに至りました。

ドライバのインストールは以下のようにして行いました。

このドライバをインストールしてもうまく動かないようならば、
最初の描画不正の点も相まってボード故障も疑うところでした。
実際のところ、ドライバのインストール後の再起動したあとからは正常に描画できるようになりました。

コマンドでインストールしましたが、GUIからもインストールは可能だと思います。
(Additinal Drivers 関連かSoftwareセンターからできるかと思われます)

プログラムの実行

X-WindowなしでのOpenGLなプログラムを実行してみました。
そもそもこのドライバ使用でも /dev/dri/card0 が出現していたので、
KMS有効であると考えて、先日のプログラムは動くのではないかと思った次第です。

しかし結果は drmOpen で失敗してしまうようで、動作確認に至りませんでした。
NVIDIA のプロプライエタリドライバでも/dev/dri/card0 へのアクセス可能なようでしたが、 drmModeGetResources で失敗してしまうようでした。もう一歩でうまくいきそうな感じがするだけに、残念です。

追記

どうやら KMS サポートしているという見え方がダミーだったようです。
/dev/dri/card0 あたりがすでにダミーデバイスノードとの情報を見つけました。
そのせいもあって、 weston も動作しないという情報もあるようです。

http://wayland-bugs.freedesktop.narkive.com/4zE7PwYd/bug-90323-weston-launch-drmmodegetresources-failed