So-net無料ブログ作成
検索選択
プログラミング ブログトップ
前の10件 | -

コンピューター言語食い散らかし2 Swift [プログラミング]

ネタがないので最近やってるコンピュータ言語で考えていることとか状況。


・Swift

OSSになったAppleが作った言語。はじめはOSSにする気はさらさらなかったらしいけど、周りからの多くの要望によってOSSにせざるを得なくなった。当時は結構揉めた気はしたが、OSSになったからと言って大して盛り上がっていない気がします。Swift3になってMacでの開発も落ち着きつつありますが、どうにも以前との互換性がなくなった分、前のソースがそのまま使えないというのは学ぶのにしんどかったりします。

SwiftがOSSになったのはいいものの、Swift自体がGUIを前提に作られたもので、コマンドライン用のライブラリがきちんと整備されていない。あるにはあるのだけれど、Core Foundationとしてかなりベアな形でしか存在していない。その上、GUI部分がOSS版には用意されていないところが発展途上なところだった。少なくともCore FoundationからのFoundationがスタブ(?)的にありはするけど実装はされていない状態では使いようがない。

今も大して変わっていないとは思うけど、恐らくは言語仕様を実現させるぐらいが関の山なのではなかろうか。OSSとして成立させるためには、他の言語と同じようにコンソールで動く標準ライブラリを充実させる必要があるだろう。そうじゃないと他の言語同様に使えない。とりあえず動きますよ的なポーズで終わってしまう可能性がある。

言語使用的には強制的にエラーチェックをしないといけないとか、バグの出にくい体制にはなっているものの、面倒くさがって避けてしまったらたいした違いはなかったりする。ただどうせ回りくどいんだったらチェックしてしまおうという気にもならなくもない。

よく考えたらこの言語で特徴的なのはこのOptionalの部分ぐらいのものかなと感じる。他にはLLにはあってもコンパイル言語にはあまりなかったところとかが新しいくらいで、既存の言語にはあるものを全部乗せした感じではある。型推論、クロージャ、ジェネリクスなどは他の言語にもある。全部そろっているかどうかは別だけど、コンパイル言語としてはないものはない感じではある。

ただ他の先進の言語を詳しく知っているわけではないから、現行の言語としては大体あるものはある的な確度しかないんだけどねw。ともあれ、こういう風にきちんと建て増しっぽくない状態で提供されるというのはいいことだろう。


建て増しで思い出したが、前のObjective-CはC言語にクラス部分を建て増していた。そのため切り分けはできていたものの異物感というのは避けられなかった。少なくとも関数とクラスのメソッドの書き方が違うというだけで、言語としての一体感を欠いていたと言わざるを得ない。C++もそうだがC言語からの建て増し感があって、ライブラリを使うための言語になってしまう側面があった気がする。実際、新しい分野や基本的分野で提供されるライブラリはベタな関数だったりするわけで、クラスによって組み上げられているものはそこそこその分野が練れてきている証拠だったりする。

建て増しという言葉がネガティブなら、C言語にクラス機能を付加するラッパーともいえるだろう。C言語自体は各環境が各々持っているアセンブラの違いを吸収するためのラッパー(それ自体ほとんどC言語のみで構成されているかもしれないが)であり、SwiftはObjective-CをLL的に使うラッパーであるとも言えるだろう。Apple的に言えば、Foundationなどを中途半端で古めなObjective-Cから置換するためのもので、これもC言語と同じように完全に置き換えをするものになっているのだろう。

そして後から出てきた言語なので、取ってつけたような異物感はあまりない。そういう意味では先進的というより現代的なコンパイル言語になっている。LLではRubyやPythonのようにいくつか現代的に整った言語は存在するけれども、コンパイル言語ではそんなに多いとは思えなかった。そういう意味でSwiftは格好の的になっていて、OSSとしてリリースさせろとあんだけ要望があったのも、現行でそういうコンパイル言語がほとんどなかったからだろうと思われる。

Linuxにしてもカーネル部分からユーザーランドまでC言語でいいやん的な雰囲気が流れているのは間違いないし、たまにPerlやPythonで書かれているものがあって、バージョン依存があって面倒だなとかいう次元だったと思う。そういう意味ではまともに最近の常識で書けるコンパイル言語というのは、割と貴重なのではないかと思う。それとメモリ処理的に問題となりやすいガベージコレクションを使わないというのも、実行サイズがコンパクトになるという点においては、コンパイルされているという点と同様に重要な点になっているだろう。


正直、OSSは先に言ったようにまだまだです。言語仕様は固まってきているとは思うけれども、使っている人も使われている例もAppleに偏っているのが実情でしょう。Linuxのカーネルに対するディストリビューションと一緒で、言語仕様だけでは使えないので、周辺のライブラリの実装がカギになってくるのでしょうね。

次はあんまりやっていないけどRuby。LLはあんまり好きになれなかったんだけど、これが契機でやるようになりました。

コメント(0) 

コンピューター言語食い散らかし1 Golang [プログラミング]

最近使ったコンピューター言語をなんとなくダラダラ思う。

・Go

スクリプト言語全盛の中で出てきたコンパイル言語。正直LL言語を使っていてコンパイルして速く動かしたいなと思う事がよくあった。それとLLは動作環境を整えないと動かないことも面倒くささが募ったりするし、バージョンの差も気になるところであった。Golangを使ってみて改めてコンパイル言語がいいなぁと思うところがあった。

思ったよりか改善著しい感じで良い。その上、言語仕様が途中で変わったりはほとんどしていないから、あのバージョンのソースが新しいバージョンで動かないとかはあんまりない気がする。バージョンの非互換性というのはどうしても言語が盛り上がれば盛り上がるほど起こってくるものだけれど、最初から標準ライブラリには必要十分なものが揃っていたし、安心して使えるという感じ。

内部的なパフォーマンスもかなり改善しているみたいで、GCとかはかなり著しく改善しているのをどこかで見た。そういう改善ってのは地味に難しいとは思うんだけど、やはりGoogleが作った言語というだけあって半端ない感じはする。正直Googleの言語かよと思っていたのだけれど、一部C言語の代替としてコンパイラ言語としては素養が良すぎる。標準ライブラリはそこそこ癖があるというか、C言語っぽくはないものの、C言語っぽく書ける上に安全で罠にはまらず書けるのはいいのかもしれない。

標準ライブラリ以外のものを使う時もGOPATHのところに突っ込む仕様になっているので、一回やってしまえば日常的に使えるのだろうし、そこのところは面倒なパッケージ管理とかはそんなにない。自分で作ったりするときはどうなのかはわからないけど、そこまでのスキルがあれば問題ないレベルだろう。まぁやれるか面倒かどうかは別の話なんだけど。

OSの中身を書くとか、既存のソースをいじるのであればC言語を始めに学んでもいいと思うんだけど、つまらない細かいしきたりとか仕様とかを考えなくても良い分、GolangをC言語よりか先に学んでもいいんじゃないかと思ったりするんだけど。というかC言語は縛りが少なすぎて、自分で律していかないとダメな面があるので、初心者向けな感じはしないんだよね。言語仕様自体が覚えることが少ない点では、初めての言語として入りやすいのだけれど、訳がわからず動いちゃってる状態が多すぎるし、それ自体がバグになっているケースが多い。それと何をするにも標準ライブラリ以外のもののしきたりを知らないといけないから、環境によって知らなくてはならないことも多くてしんどいとか。

ただでさえ初心者だったらコンパイルが通って動くまで行くのがしんどいのに、実際の動かすロジックに集中させてくれと思う。そういう意味ではGoはそこそこストレスが少ないし、適当にWebからソースを持ってきても動くことが多いので、さくっとオレオレツールを作るのには適している。最近は全部盛りな言語が多い中、覚えることが少ないのは利点なんじゃなかろうか。オブジェクト指向でできることを少しは取り込んでいるし、覚えることが多すぎて使わないものが多すぎるよりかずっとマシだ。というか、C++とか巨大すぎて普通の書き方をしていても、これなんだったっけみたいな事が起こりやすい上に、そんなの知らないという個人の認識の差が大きすぎるのが問題になったりしていた。更に明らかに使い方を間違えている既存のソースを直すのかどうかとか面倒な話になってくることもある。

Golangは最近の動向を掴んで作られているから、初期に言われていたように昔の言語のまんまじゃないですよ。確かにカッコのインデントの位置を強制させるのとかは気持ち悪いけど、まぁ慣れですよね。何にしてもC言語後継のコンパイル言語が出てきてくれてありがたいことは確かだ。まぁC言語はC言語で特定用途で残り続けるとは思うけど。プアな組み込みとか使わざるを得ないしね。


続けてSwiftとRubyを書きたいと思います。

コメント(0) 

Nvidia Video Codec SDK7.1のNvTranscoderをいじる [プログラミング]

NVENCのお勉強の一環として、NvTranscoderをいじっている。元はH.264をH.264とかHEVCに変換するものなんだけど、実はmpeg2も大した改変もなくHEVCとかに変換できた。たぶんNVDECがサポートしているコーデックならみな対応しているんじゃないかなと思う。対応しているんだけど、入力時にH.264しか入れないようになっているので、そこを取り去ってさえすればそのまますんなりトランスエンコードされる。

具体的にはVideoDecoder.cppの114行目

if (oFormat.codec != cudaVideoCodec_H264 && oFormat.codec != cudaVideoCodec_HEVC) {
fprintf(stderr, "The sample only supports H264/HEVC input video!\n");
exit(-1);
}
というところをコメントアウトするだけでいい。ここでいらないチェックをしているから、途中で止まる。少なくとも付属しているplush1_720p_10s.m2vをHEVCにエンコードできたようだ。ただ、今までと同じようにmp4のコンテナに乗っている状態ではないので、そこは別途インプリしないといけない。とりあえずHandbrakeからソースを取ってきて組み入れてみようと思う。

ん〜mpegは結構画像が荒れるな。ブロックノイズどころの話じゃない感じ。VLCとかは細かいブレをチューニングして作られていることが分かる。VOBファイルは途中でエラーが出る。まぁそうだろうね。どちらにしてもMP4化は必須なのでやらないと。

MUX部分だけHandbrakeから持ってこようとしたけど、他のヘッダや何かがかなり入り組んでいて、それだけ抽出するわけには行かなかった。関数だけ引き出すことはできるのだろうけど、それでもHandbrake由来の型が沢山あると思うので、簡単に移植できそうにない。これはHandbrakeにTranscodeのソースを持ち込む方が楽できるかなと思ったり。それにはTranscode側の訳のわかってないところを読み込まないと。もうちっと粘度が低いと思っていたけど、Handbrake自体がかなり色々なものを取り込んでいる上に全体的にはモノリシックな構造になっている。

ってかモノシリックだと今まで思っていた。モノリシックね。lithic自体が岩石関係の言葉でmonoがついているから一枚岩的な意味らしい。日本語の読みやすさで日本語英語ができることって多いよな。シミュレーションがシュミレーションとか、あまりによくありがち。雰囲気をふいんきと読んだりするのも同じだろうなぁ。あまりに頻発するので訂正する気にもならない。まぁ意味が相手に正確に伝わればいいとは思うけど気になる人は気になるだろうな。

そんなわけでmp4boxとか組み入れるなり、外から使うなりしてちょっとやってみたい。その前にHandbrakeに突入しちゃうかもなぁ。cppファイルをそのまま使ってextern"C"して使うか、スクラッチしてC言語のNvEncで始まるAPIを素で使うか、どっちが早くて確実かなぁ。内容をはっきりと理解しなくていいのは.cppファイルのまま渡す方法なんだろうけど、それだと何だかわからないが動く状態になりかねないし、それはそれでいいかなと思う自分がいたりする。目的はHandbrakeを理解することじゃなく、NVENCを使うことなので。しかし、Handbrake久しぶりだな。ちょっとソースが懐かしいとともにQSV関係のソースが加わっていたりする。」

コメント(0) 

Nvidia Video Codec SDK 7.1のサンプルをいじってみる [プログラミング]

Video Codec SDK 8.0は動いてくれなくて、SDK7.1を使ったら動いたという話を以前にしましたが、やっぱり全部は動いてくれそうにないという話。とそれを弄って何とかHandbrakeにつなげていきたい、という地道な作業。

とりあえずNvTranscodeやNvEncodeのサンプルはビルドできたバイナリがきちんと動くことを確かめました。出力されたバイナリもきちんと確認できたし、問題はあってもそこはインプリしていないだけという状態なのがわかって少しホッとしているところ。

エンコードはきちんとNVENCが動いてくれているのはわかったけれど、引っかかったのはNVDECの方。未だLinuxでは動いてくれていない。WindowsではDirectXでのサンプルのビルドが通りきちんと動いたのだが、Linuxと同じくOpenGLの方は動いてくれていない。というか、OpenGL用ではLinuxでは通ったビルドさえ、VisualStudioではエラーを吐いてリンクの時に転んで実行ファイルができない。Windows用のfreeglutとか入れないといけないんだろうか。そもそもWindowsには昔からOpenGLは使えたはずなんだけどな。

http://egolog.hateblo.jp/entry/2016/04/09/212608

で入れ込んだけど、static linkは対応していないとか言われたっぽい。ん〜他のfreeglutとか入れてもconflictなんとかのfreeglut_staticd.lib関係のリンクエラーが取れない。というか、Visual Studioなんだからいろいろ設定して動くようにしておいてほしいんだが…。

とにかくDirectXの方のソースは動いているので、NVDECに渡すところは使えるだろう。でも、ちょっと考えてみたんだが、NVDECってインターレースの処理とかするからGPUでデコードしてCPU側にまた戻して、という処理をしなくちゃいけなくなってしまい面倒な気がしてきた。とりあえずNVENCが使えるところを頑張ってからで後で考えればいいかと思ったのでした。それにTranscodeでh.264に関してはNVDECを使っていると思われるので、そこから掠め取ってくればMPEG2とかにも応用できそうな気はする。ただ渡すパラメーターだけの問題な気はするね、きちんとソース読んでないけど。

そんなわけで、とりあえず今できていないH.265のデータをMP4のコンテナに載せる処理をしてあげないといけない。そこいらの処理はHandbrakeの処理から取ってくる方が後々整合性が取りやすくなりそうだからパクってくる。


NVDECとCUVIDがなんか違うものかなぁと思っていたら、SDKのページにおんなじ物だよと書いてあった。SDKのページはダウンロードに行くだけで全然読んでないなぁ。

https://developer.nvidia.com/nvidia-video-codec-sdk

cuvidという名前はAPIに残ってはいるものの、今はNVDECで良いらしい。ちなみにNVENCの方はcuvid何とかで始まる関数ではなくて、NvEnc何とかという関数になって別箇になってはいる。互換性の問題だとは思うけど、統一性はないわな。別機能と考えられなくはない。

基本NVIDIAのハードウェアCODECはYUVを入出力して加工すると思うので、エンコード前のデコードもGPUでやってしまった方が効率がいいと思われる。GPUでの処理のボトルネックはグラフィックメモリへの転送にあるとは思うので、一気にデータを送ってモニョモニョした方がいいんでしょう。今見ている限りでは、データを意図的にGPUに送るとか単体の関数でやっていないみたいなんだけど、内部的にはGPUのメモリに送ったり戻したりはしているとは思うので、そこを細かくしたい場合はCUDAを使うことになるのかもしれない。

Handbrakeに入れようとすると、MPEG2とかのデータを扱うことになると思うけれども、そこいらのデコードもNVDECでもちろん出来て、そのままNVENCにYUVデータを渡せそう。HandbrakeはQSVのデコードの機能はデフォルトでオンになっていないみたいなので、その分CPUへの負荷は更に軽くなると思われる。なかなかいい感じ。というか、大体の処理がGPU内で終わらせられそうだ。ただし、MP4のコンテナに載せる処理とかはやらないと、動画がDEMUXされたようなネイキッドな状態になってしまうので、Linux以外では普通画像が再生できない。

Handbrakeはc言語で、NVENC、NVDECのサンプルはC++で書かれている。組み入れる時に面倒そうだ。NVDECもNVENCもAPIはC言語の関数になっていると思うんだけど、サンプルがC++で書かれているのは移植に面倒なんだよなぁ。extern"C"すればいいんだろうけど、API自体はC言語で書かれているので、C言語で書き直したほうが早いかもしれない。どっちが楽だろうなぁ。

C言語をC++に入れるのは問題ないとは思うんだけど、逆は気をつけないといけなさそうなのでヤダ。コンパイラも統一できそうもないし結局NVCCでやってた時とそんなに変わらないMakefileの扱いになりそうで今からウンザリ。動けば良いとは思うんだけど、元々あるソースを親子関係にあるとはいえ別の言語で書き直すとかしんどすぎるんですが。ソースそのままで無理やりがっちゃんこした方が、手を加えるのが少なくていいのかもしれない。

HandbrakeはGPUに渡す前までの前処理をすることになるわけだけども、その後のMUXの処理が上手くつながるかどうかが気になるところ。とりあえずTranscodeのソースにMPEG2とかのソースを読み込めるようにして、H.265でエンコーディングしたデータをMP4の形式にしたい。今のTranscodeだとH264しか読み込めないから、そこいらの部分をクリアにして、出力が普通のアプリでは読み込めない状態をHandbrakeのMUX部分をパクって直していく。そこからHandbrakeに組み入れられればと思う。

コメント(0) 

nvidia video codec sdk 8.0のサンプルコードが動かない(7.1で動いた)。 [プログラミング]

NVENCを使おうとして、Video Codec SDKを入れたのは良いけれど、サンプルコードさえ動かなかった話。

https://developer.nvidia.com/nvidia-video-codec-sdk

経緯を述べておきますと現在SDKは8.0で、UbuntuだとCUDAとドライバの齟齬があってうまく動かないみたいです。仕方ないのでWindowsで動かしてみても、Ubuntuと同様にコンパイルはできるけれども、実際に動いちゃくれなかったりします。

CUDAはOptionalで入れなくてもいいのかなと思いきや、サンプルががっつりCUDAを要求しているので入れざるを得ません。WindowsではサンプルによってはDirectXで良かったりしますが、なんだかんだで使いそうなのでどちらにも入れておくことにします。

んでWindowsでもUbuntuでも出たエラー。NvTranscoderで出てくる。

Failed to find required function "cuvidGetDecoderCaps" in libnvcuvid.so
cuvidInit(0) has returned CUDA error 999

そもそもDLLとかの共有ライブラリを見に行くときにこけているのでどうしようもない。それにCUDAを入れるのは必須なのでダメだったりする。読んでいるところをコメントアウトしたものの、パラメーターからファイルを読むところでコケていて、対処のしようがなかった。

NvEncoderはエラーは出ないんだけど、出力はされていない。こういうのが一番困る。何が悪いのかわからないから、デバッガでステップ実行していかないと突き止められない。デバッグしようとしたけど何やったかは忘れた。

さんざんGT 1030 NVENC未実装問題や、デバドラがきちんと入っているかわからない問題や、CUDAやっぱ入れないとサンプル動かないやん問題を通り過ぎてきたものの、何が問題なのかわからないのでデグレードというか、SDK7.1を使ってみた。すんなり動いたw。たぶん整えた環境の問題なのだろうけど、WindowsもUbuntuも、新しいグラフィックドライバに新しいCUDAを入れたのだ。SDK8.0が悪いとしか言えない。

それに音は入っていないとは言え、Transcodeは1750fpsの爆速を叩き出していた。これは移植するモチベーション上がるなぁw。それにとりあえず動くというところが良い(喜ぶところのレベルが低いw)。まだ面倒があるのには、Windowsで生成されるファイルがmp4形式で吐き出されてないっぽいところ。でも基本的にUbuntuで開発しようとしていたから別にいいかという感じ。今回はnvccとかでコンパイルしてむりやりgccなバイナリと連結しなくても良さそうだし、きちんと動画的なお作法さえ身につけていればなんとかなりそう。

問題が一つ。Transcoderで生成したファイルが、UbuntuのVideoアプリでは見られるけど、MacやUbuntuのVLCでは見られないということ。h.265が悪いのかなと思って、H.264で出力したけど見られなかった。そもそも一般的なmp4の形式で出力できていない模様。Windowsで出力したファイルもWindowsでは見られなかった。

確かにエンコードされるファイルはbitstreamと書いてあるけれども、TranscoderくらいはきちんとMP4の形式に整形してくれないと、どういうデータが来ているのかがさっぱりわからない。ビットストリームをMP4のコンテナに乗せればいいのだろうか…(わかってないw)。MP4をdemuxした状態なのかな。しかし一般的なアプリで見られないとなると、今後は動作確認などが問題になってくるだろう。データとしてはできてはいるんだろうけど、お作法に則って出力してもらわないとねぇ。

それにしても、開発環境が動かないというのは辛いですよ、NVIDIAさん。新しい環境に問題があるというのはよくあることだとしても、過去の動いていたSDKをもっと見つけやすいところに置いておいてもらわないと、正直このレベルの完成度でリリースされるとみんな困る。

https://developer.nvidia.com/video-codec-sdk-archive

コメント(0) 

Golangまたやっか。 [プログラミング]

SwiftをUbuntuに入れて動かしてみたんだけど、正直まだまだだという事が分かった。Deprecatedな関数が多いのにもかかわらず、まだ実装されていないものもあったりで、どこまでSwiftでできないのかが分からなかった。そもそものライブラリの性質がコマンドライン用にできていないので、Foundationを扱うのも面倒な面が多かったりする。それとXcodeみたいにSwift3になって名前が変わったものをサジェストしてくれないので、自分で調べないといけないのもお手軽に書けない理由になっているのだろう。

OSSのSwiftは待ちかなぁと思うにつけ、やっぱりGolangとかはお手軽に書けていいなぁと思ったりしている。Swiftみたいに動的スクリプト言語みたいにかっこよく書けないけれども、C/C++言語から始めた自分としては何となく安心できる言語ではある。C言語的な万能さはないけれども、C/C++の罠が極力抑えられているのがいい。というか、オブジェクト指向は使うのはいいが、ライブラリ側に近いところを作り出すと一気に面倒になる。知らなくてはいけないことが多くなるし、気を付けるところもべらぼうに増える。


車輪の再発明となるが、Golangでhttpdを作ってみたい。busyboxぐらいのシンプルさのhttpdがいい。そこからHTTP/2の実装まで手を伸ばしたい。でもまずは普通のWebサーバ。Golangは標準ライブラリにすらいろいろ材料は揃っているから、割とシンプルに書けそう。あとgoroutineを有効に使ってみたい気持ちもある。なんかそういう基本のところをやってみたくなったんだよね。今まではいかにフレームワークを使うかとかだったけど、一般的なプロトコルを実装したくなった。

通信制御系のプログラミングはしていたこともあるけれども、正直全体像が分かるほど触らせてもらえなかった。仕様書ありきの世界でもあったわけなので、正直細かいことを考えたことはなかったりした。きちんと自分がすべきタスクを果たして次に渡せばよいだけだったので、全体の動きとかはまた別の話になっていた。それにしても携帯に限っては、すでに初めのころからハードウェアで実装されて、チップを配置するなりSoCに組み込むなりするだけの世界になっているのだろうから、ソフトウェアで処理して電話の通常通信処理で電池が持たないなんてことはないんだろうね。自分が3G携帯を作っていた頃でもGSMはワンチップ化されていたっぽいしなぁ。少なくとも基地局役の機器がトランシーバー並みの大きさになっていた時は、GSMの基地局側の処理もハードウェア処理されていたんだろう。

正直ハードウェア処理というのがよく分からない。ソフトウェアほど融通が利かないという事ぐらいしかわかっていない。FPGAとかそういう世界は同僚がやっているという話は聞いたことがある程度しか知らない。プログラマブルなハードウェアというのがどういう仕組みで動くのかが想像できない。やはりCPUにメモリを積んでメモリ上にロードするという処理しかしないソフトウェア技術者としては、VHDLとかでプログラミングする世界とは違う別物として考えていた。今VHDLのソースを興味本位で見たら、ネストの深い分岐処理が多いんだなくらいで、思ったほど回路回路していない感じだった。

ソフトウェア処理している部分を、ハードウェアに落とし込むときってどうやっているんだろうなとちょっと気になったり。通信制御系だとC言語とかの奔放な書き方ができる分の冗長さがなくなってやりやすいかもしれないなと思ったりはする。何でもできるからバグができるという側面がC言語には多分にあるから、今のコンパイル言語はバグが出ないようにわりと縛りがきつくなっている。それで書きやすいかどうかはまた別の話だと思うけど。


そんなわけで、おじさんの老後の楽しみとして(笑)、Webサーバぐらいはちょうどいいボリューム感なのかもなぁと思っていたり。仕事だといちからスクラッチする事ってまずないし、かといってシステムや言語に近いところをえぐるようなことも割とあったりするから、妙な知識ばっかり蓄積する。要するにつぶしの利かない仕事が多かったというわけだ。だから仕事をセミリタイアするまでは、DBとかあんまり扱ったことがなかったりして世界の違いに戸惑ったりもした。いや、パッケージでDBを利用していたりしていたんだが、SQLそのものを発行したりするところじゃなくて、Windowsのインターフェイス部分を扱ったり、別システムとのやり取りをしたりとか、そういう雑多な周りのこまごまとしたところをよくやっていた気がする。

これがDBそのものを作るとかになると、非常に敷居が高くなってしまうのだが、通信だとそこまで専門的な知識が必要ではない。英語だけれどRFCというアクセスしやすい資料も存在することだし。他のマイナーなプロトコルのサーバ実装とかもいいかなとは思ったけれども、正直へこたれそうで比較もできないと進んでいる感がないというか、実装後の検証もしんどくなるなぁとか思ってしまう。Webサーバだったら手元のブラウザですぐに確認できる。HTTPという訳が分かっているつもりのプロトコルでも訳の分からないところとか、実際どうやっているのかわかっていないところとか、実装しないとわからないところを知ってみたいという思いがある。単に手軽なおもちゃが欲しいという気持ちがあるわけで、別にそれがプロダクトになってほしいとかそういう気持ちはほとんどない。そもそも、世の中にhttpdなんてメジャーなものがたくさんあるわけで、それを自分で作れたら面白いなと感じるだけです。

とにかく語ってないで作れや、というのが世の常だと思うので、誰でも実装できそうなところから始めます。というかviとかあんま慣れてないんだが。しかし、環境からしてviかemacsでインプリするしかないんだよな。どっちにしても特殊なキーバインドなのは否めない。やっぱりWindows上で開発していたのが長かったから、そういうのにはあまり固執していないからなぁ。お手軽な方法に逃げてしまうのが人間の性というものだ。

コメント(0) 

SwiftをUbuntuでやる。 [プログラミング]

以下は
Ubuntu 16.04
Swift version 3.1.1
でお送りします。んがくく(古い)

インストールの大体はダウンロードサイトのページの事を大体やってある。
https://swift.org/download/#using-downloads

SwiftがOSSになって、Ubuntu上の開発環境が提供されたわけだが、Linux上での開発が良く分からない。というか、基本GUIアプリを作るためのSwiftをLinuxのコマンドラインアプリを作るための使い方とかはあんまり見ない。まぁMacがあるのにわざわざUbuntu上でやることもないのだが、なんとなく天邪鬼な自分としてはせっかくのOSSだからOSSらしく使いたい。

そもそもOSS版で使えるのは標準ライブラリとかなんだろうけど、その範囲がいまいち良く分からなかった。MacのSwiftはGUIを主眼において開発されているから、全体としてそこをどうするかの話になってきてしまう。でも、OSSなSwiftの使うところはそこじゃない。というか、そこの部分は作られてないはず。

http://quesera2.hatenablog.jp/entry/2015/12/05/163855

一年以上前の記事だけど興味深いことが書かれている。実際に実現しているところもあるのかなぁ。細かくは分からん。

Swiftの通常版とオープンソース版の違いについて、という直球な題の記事もあった。

http://qiita.com/glayash/items/a4b1b1ffef97e649395b

一言で言うなら

Foundation
libdispatch
XCTest

ということなんだろうけど、そもそもFoundationというのがどこまでなのかが分かっていない。一つ前のリンクにあるように標準ライブラリを含んだ形でFoundationがあるようだ。

実際のAppleのリファレンス的にはどこのURLに当たるのかだけれども

https://developer.apple.com/reference/swift

ここはどうにも機能的にまとまっているわけでもなく、ただのんべんだらりとアルファベット順に書かれているだけですね。

https://developer.apple.com/reference/foundation

とここにクラス群がまとまっていますが、print文はどこに属すの~という感じで、クラスのメソッドじゃない標準のものに関しては、別途挙げていかないといけないのかなと思いつつ、SwiftはGUI部分以外はほとんど何も分かっていないなと言うことが判明。いや、そんなんでOSSなSwift扱えるんか、と。

それとやたらとNSという接頭辞がObject-Cの時代を思い出させる。Swift3.0からはそれを取ろうとしているみたいだけど、正直中途半端間は否めない。

としりごんでいても仕方ないので、実際にコンパイルして動くものを作ってみようと思う。ただ単にURLを与えると、ダウンロードしてくるプログラムを作ってみる。

まず引数からURLを取ってくるところから。GUI用の言語をCUIで使うにはまずそこからだよね。

import Foundation

//print(C_ARGV)
//print(Process.arguments)
//print(Process.argv[1])
print(CommandLine.arguments)


やっと出てきた。何だよこの情報のぶれ方はw。というか、Swiftのライブラリの命名方法がやたら変わりすぎていて、いつのバージョンで効く情報なのかさえも非常に分かりづらい。

実はimport Foundationしなくても動いた。これが暗黙にFoundationをインポートするのか、なくても標準ライブラリとして装備されているのかは分からない。そもそもFoundationと標準ライブラリの境が分からんし。

NSURLはimport Foundationしないと知らないと言われた。普通に使うには基本的にFoundationをインポートしないといけないらしい。まぁ細かいパッケージをちまちまインポートするよりかずっとマシだけれども。いまだにNS何とかと書かないといけないのは新しくSwift3に移った余波としては言語に型名を近づけるのは、主要な場所以外は限定的なのかなぁ。

ダウンロードはNSURLConnectionがDeprecatedになって、NSURLSessionになったとiOS関係の記事には書いてあるのだけれども、どっちもGUIアプリ用のイベントを前提にしたものだから、普通にコマンドラインで単純に実行するには不必要と言うか、要らない機能も含まれている気がする。ソケットを生で使う程度の低レベルのものがないのかなぁと。

ともあれ非同期的な書き方をしなければいいわけで、Deprecatedになっていようが動けばとりあえず良しとする。というか、どこまで動いてくれるのかがわかっていない状態なので、別にHTTPを特に試したいわけじゃない。

NSURLConnectionがDeprecatedになったと書いてあったが、正確には多くの関数がDeprecatedになって、同期通信は出来なくなっていた。

https://developer.apple.com/reference/foundation/nsurlconnection

デリゲートとかやらないといけないのかな。面倒くさいな。URL取ってくるだけなんだけど。もっとシンプルなクラスとかないのかな。


色々なものを参考にしたんだけど、Linuxで直で動くソースが見つからないので切り張りして何とかコンパイルできるぐらいには持っていってみる。

import Foundation

print(CommandLine.arguments)
let myUrl = URL(string: CommandLine.arguments[1])!
let req = URLRequest.init(url: myUrl)
let config = URLSessionConfiguration.default

let session = URLSession(configuration: config)
let task = URLSession.shared.dataTask(with: myUrl) { data, response, error in
  do{
    try data!.write(to: URL(string: "./text.txt")!, options: NSData.WritingOptions.atomic)
  }catch{
  }
}
task.resume()


上手く動くかどうかは知らんが、コンパイルは通ったのでその点では問題ないだろう。NSのプリフィックスは軒並みコンパイラに怒られた。まぁ使わなくていいならそれでいい。

まずLLVMか何かのエラーが出るので、実行環境の./usr/libを$LD_LIBRARY_PATHに入れる。/etc/ld.conf.dの中のファイルをいじってもいいと思う。

コンパイル後動作させると、色々共有ライブラリがないといわれているみたいで、参照先がないよと言われる。

find .|grep \\.so |xargs -i% cp % .

./usr/libにパスは通っているものの、それ以下のディレクトリには通っていないので、あるもの全部を無理やりコピーしてくる。スタティックリンク用のファイルはいらないはず。

共有ライブラリを移動させた後も、libcurl.so.4がないというので入っているパッケージを入れる。

sudo apt install libcurl3

やっと動いたと思ったら、こんなメッセージが

fatal error: shared is not yet implemented: file Foundation/NSURLSession/NSURLSession.swift, line 200
Illegal instruction (core dumped)

sharedっての、インプリされてないってよw。というか、ソケット使いたいだけなので、低レベルな関数を提供してください。それかXcodeレベルに上げてください…。色々やり方はあるみたいなんだけど、簡単にしようとして逆に八方ふさがりになっている気がする。

もう少しまともになっていると思っていたんだけど、Ubuntuの開発具合はこんなもんなんだな。というか、テキストソースに互換性がないって事なのかな。あ~Macの方はObjective-Cのライブラリをはさんでいるから、直接のインプリはObj-Cって事なのかもね。なもんで、Linux版のインプリはSwiftで全部なされてないと。

Ubuntu版の中身の進捗はあまりよろしくないと言えるでしょう。時間と共に解消はされるけれども、正直何かを作るに足る状態にはなっていないのは間違いないです。だって普通にネットワークのメソッドも使えない状態なんですよ。FoundationはSwiftで書かれているって言うことは、それに近いことを自分でも出来そうな気がしますよね。Core FoundationはC言語で書かれていて、それをSwiftで呼んでいるっぽいのを読んだ気がするので、そこまでしないとまともに使えないのかもしれない。

でも、そこまでしてまで使いたい言語なのかと言うと微妙だ。楽ができるから使うとか、iOSも開発できるから使うとか、そういうカジュアルめいたものだと思っていたんだけど、どうやらそうではない感じである。やはり商業ベースのものをOSSにするというのは、それなりにハードルが高いんだなと思わざるを得ない。

あ~やっぱり本格的に手を入れようとするとCoreFoundationを使わないといけないらしい。

https://developer.apple.com/documentation/corefoundation

でも、Swiftで直接関数を提供しているみたいなので、そこいらはC言語との兼ね合いを考えなくてもいいので楽できるのかもしれない。とはいえ、そこいらへんの情報はAppleからしか出ていなくて、サンプルソースとかあんまり出ていなさそうな気がする。コピペ厨房な自分としては、全部自力でインプリするのはめんどいなぁと思うわけで。

ただ、自分でライブラリを書こうとするとCFなんちゃらの関数は使っていかないとダメだろうなという事はなんとなく分かる。ただFoundationを無視するのは結構汎用性も落ちるし、車輪の再発明になりかねない状態だったりはする。


それにソケットのところを見ると

https://developer.apple.com/documentation/corefoundation/cfsocket-rg7

#include <sys/socket.h>
とかしていて、かなりSwift使っている感が薄くなる。

ちょっとどうしようか迷っている。Swiftで書く意味があるのか、というのが一番の問題点ではある。そもそも先ほどのコンパイルだけ通したものが、Xcodeで動くのかなというのを確かめたほうがいい気がしてきた。

そして、そもそもSwiftがiOSやMacOSのGUIアプリを念頭に置いた言語であり、Foundationもそれに沿ったものであることを心に留めておかないといけない。

タグ:Swift3
コメント(0) 

アプリ機能の拡張とか。 [プログラミング]

So-netブログが勝手に自動保存するようになった。Gmailのエディタみたいだけど、テンポラリで保存するだけで実際の記事に保存するわけじゃないっぽい。機能的には強化されてはいるもののあまり使い勝手がいいものじゃない気がした。テンポラリだからずっと前の下書きが残っていたりして、保存していない既存の記事を差し置いて復活してしまうみたいで、これではやり方によっては自分が書き足した記事が消えかねない。

一度保存してしまうと自動保存はされなくなるみたいで、なんでこんな中途半端な機能を付けるのかなぁと思ってしまう。正直、自分たちが使ってから機能をローンチしているとは思えないのだが。機能というのは間違いなく動けばいいってものではなく、そもそもの設計がきちんとしていないと便利でもなんでもないわけだ。

確かにきちんと動くというのは、プログラミングの原則から大事だとは思う。だけど、使えない機能は使わなくなるし、アラートされても無視されて最後にはうっとうしくなる。なかなか難しいとは思うけど、ツールやアプリの利用なんて部分的なものなんだよね。全部使いこなしているなんて言う人は、プログラムに使われているとしか思えないのだけれど、必要なタスクを少ない手間でやり遂げるのが一番なんじゃなかろうか。


さて、GolangもSwiftも開発環境をLXCで整えたわけだけれど、結局何を作ろうかなぁ。最近の多くが車輪の再発明にならざるを得ないから、フレームワークを使ってサービスを立ち上げるってのが今どきなんだろうなぁ。

Golangではそこそこいろんなものが作られているから、Swiftでなんかコマンドラインベースのアプリかライブラリを書きたい気がしている。それならばviでしこしこ仕事中にでも開発できるし。しかし、SwiftはOSSになる前は盛り上がっていたけれど、今はそうでもない感じがするんだがどうなんだろう。MacとかiOSの開発ではメジャーになっているのだろうけど、OSSの方はあまり芳しくない気もしなくはない。あれだけOSSにしろという要望があったのに開けてみるとこんなもんか。というか、現状はそれほど知らないんだけどね。aptのリポジトリに登録されていない時点でOSSとしては未熟と言っていいと思うんだがどうだろうか。

コメント(0) 

Swiftをコンパイルしてみる。 [プログラミング]

https://swift.org/download/#using-downloads

Ubuntuは解凍してそこにパスを張って使うように薦めているけれど、なんかきちんとインストールディレクトリに入っていないと気持ち悪い。というか、こういう任意の場所で解凍しただけで動くものなんだ。Linuxの深いところを分かっていないので、ディレクトリの位置とか深く考えたことがない。

なんとなく一からコンパイルしたくなった。ただ気持ちの問題。というか、今ならコンテナもあるし、時間もあるしというところで。それにしてもググると他のSwiftが出てくるな。具合の悪いことに開発関係にもあったりするので、apt searchしても他のものが引っかかってくる。一瞬勘違いしそうになったじゃないかw。

https://github.com/apple/swift

ここにガッツリUbuntu用のインストール方法が出ている。最近はOSSだとみんなギフハブだな(ってもうAskaネタはいいってw)。シャブ患者はさておき、インストールしてみた。何気にUbuntu16.04はビルド通ってねぇって書いてあったりする。大丈夫なのかw?

かなり時間がかかりそうなので、途中でコンパイルを止めて、tmuxを入れて続行。LXCコンテナ内だとtmuxを動かすのに17.04用のdebファイルを入れない今のところLTSでは使えないのは前に書いたとおりで、入れ方を自分のブログを見た。まぁインストールはコピペで。にしても長い作業はtmuxとかでやっていないと色々と不安だ。

コンパイル作業を見ているとC++のソースファイルが多いみたい。SwiftはObjective-Cで書かれているわけじゃないのね。その割にはObj-Cとの互換性とかはあるみたいだけど、いちいちインターフェイスを揃えてあげないといけなくなるよなぁ。そこいらの言語の違いはWindowsで面倒だった覚えがある。でもLLVMで作られているからいくらか面倒が少なくなってはいるのかな。

案の定、コンパイルは通っているようなのですがテストが通っていないようで、インストールはされませんでした。そもそも16.10はコンパイルが通るけど、16.04ではコンパイルが通らないとか依存性の問題がバリバリ出とるとしか思えんのだが。まぁそもそもがMacのOSX上で依存性関係無しに作られていたのだろうから、すぐにUbuntuに依存性をクリアして移植と言うのは難しい話なのだろう。そもそも自分たちのXcode環境のバージョンを気にするだけで精一杯とかそのレベルであってもおかしくない。


しょうがないから16.04でビルド済みのtar玉を持ってきて解答してそこにパスを通した。まぁこれが普通なんだろうな。でも、swiftcでコンパイルした時に問題が出た。たった一行のhello worldも出力できなかったのだった。コンパイルは出来ているみたいなのだが、実行時にリンクするライブラリがないみたいで、実行環境は入れているのだが、バージョンがあっていないらしい。このコンパイラを作っている環境では問題ないのかもしれないが、普通にapt update && apt upgradeしている環境では足りないらしい。

またまたしょうがないから16.10でビルドすることにした。というか特に開発とかではLTS以外を使う気にはならないんだよなぁ。色々面倒くさい。

Testing Time: 1133.37s
Expected Passes : 2753
Expected Failures : 81
Unsupported Tests : 787
-- check-swift-linux-x86_64 finished --
--- Finished tests for swift ---

最後に出てきて、swiftコマンドを打つもインストールはされていなかった。失敗?と思いきや、テストしているんだからバイナリ自体はできているんじゃないかと思って
find . -name swiftc
とやってみると、案の定/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin に出てきた。テストが失敗したのか、もともとやらないのかはわからないが、インストールまではしてくれていない。まぁコンパイル・ビルドが./configure&&make&&make installじゃない時点で気づけよという話なのかもしれないが、そこはOSS的なお作法とは違うところから来たものだから仕方ないのかもしれない。

とりあえず、print("Hello, Swift.")という中身を書いたtest.swiftを作って、./swiftc test.swiftをしたら無事コンパイルができて、./testでHello, Swift.が出てきました。そりゃ地元でコンパイルした開発環境だもんなぁ、当たり前か。たぶん16.04でもできていたので、環境を消してしまったけどもう一回16.04のコンテナでコンパイルしたものを、ディレクトリを見つけて動かして見たい。というかLTS以外の短い運命のOSでは開発などはしたくないんだヨォ。


あれ〜作られたバイナリを始めにやって見たんだけど、16.04LTSでもきちんと動くね。コンパイルをする環境を作ってから、始めから用意されたバイナリなtar玉を使おうとしたから、実行環境に問題が起こっていたんだね。どちらにしてもバイナリファイルを入れる.debファイルを作れたら作りたいなと思ったり。それにはバイナリはできているので、make installの記述ができれば大丈夫なのかなと思いつつ、makeファイルなんてしばらく書いてねぇよと独りごちる。

dpkg-buildpackageを使えばできるみたいなので、ちょっとお勉強して.debファイルを作ってみようかなぁ。なんかこのまま解凍してパスを通すってのはあまり綺麗じゃない感じがするんだけれど、そこまでの労力に見合った効果があればいいのだけれど。でも、依存性とか気にしなくて良くなったりするから、きちんとできればいいのかもね。というか、debファイルってディストリビューションのバージョンの依存性とかどうやって解消してんだろう。aptで吸収してそうだな。.debファイルがどのくらいの威力を持っているのかわかってないな。

って16.04でコンパイルするんじゃなかったのかよw。まぁ動く状況ならどんな方法でもいい。

タグ:SWIFT
コメント(0) 

リアルで偉そうなことを言えないから、ネットで横柄になるんだろうな。 [プログラミング]

Golangで構造体のスライスのポインタについて、調べていたときの事。
構造体のスライスと言う点で二つが絡んできて面倒なのだが、良く使うパターンであることは確かだろう。構造体を単体で扱うことの方が少ない気がするし。でもそういうサンプルは少なかったりする。んで、下記で根本的に解決はした。

http://qiita.com/ruiu/items/e60aa707e16f8f6dccd8

ここを読んでわかったのは、単純な構造体はコピー渡しだけど、スライスは参照渡しになるんだねということなんだが、技術文章でこういう風に何でこんなこともわからないんだ、みたいな言い方が良くある。

私の言うことは正しいから、良くありがちなことをけなしても良いのである、みたいな知っているものの驕りを感じるんですよね。特に技術者関係に多いんだわ、昔から。初心者を平気でタコ呼ばわりする風習があって、そういうやつに限って他のことを大して知らないタコツボに入り込んでしまっていることも多い。

なんで、私は正しいことを知っていて周りは間違っている、みたいな言い方しか出来ないのか理解できない。言い方があるだろうと思うんだけど、往々にして社会不適応な人間がコンピュータ技術者に多いのは予想が付くところだ。少なくとも営業の仕事など振れない。

でも、まとまった情報として、
文字列、インターフェイス、チャネル、マップ、スライス
が始めっから参照形式の変数だ、と書いてあるというのは有用だ。本家のリファレンスに明示的にまとまっていないから、みんなが勘違いする可能性が出てきているという事だ。

ただ何度も言うように、「Goでxxxのポインタを取っているプログラムはだいたい全部間違っている」みたいに自己顕示欲プンプンな題名からわかるように、糾弾するような言い方は頭が悪い。頭が悪いと言う言葉は悪いが、知識があるが頭の良い言い回しではない、ということだ。しかし、ちょっとだけ知っていることが多いだけでどうしてこうも高慢な言い回しになるのか訳がわからない。ポインタの使い方が間違っていることがほとんどなので気をつけて、程度の表現にとどめられないこと自体がヒューマンスキルが足りていないと自分で喧伝しているようなものだ。

GoでC言語を知らずにやっていたら、あえてはまらないであろう軽微な罠なので、それほど実害があるわけでもない意味のないポインタのポインタみたいなものに目くじらを立てる意味もないと思うのだが。まぁ確かに可読性は下がるよ。でも、著しく実行速度が落ちるわけでもないから、ポインタを使えなくて問題が出るよりか随分ましな気はするんだけど。

まぁ僕としては知ることが出来てありがたかったんだけど、教えてもらっておいて文句言うな、と言う人もいると思うんだけど、世の中には表現の仕方が残念な人がこうも多いのかと言うことで。

タグ:Golang
コメント(0) 
前の10件 | - プログラミング ブログトップ