| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
ノーコード、ローコードというのが最近の流行り（というか、バズワード）のようだ。次のような定義らしい。
「いや、そんなん昔から有るじゃん。RPGツクールとか」とも思うが、またRPGツクールのような物はジェネレータと呼んでいた記憶もあるが、それは言ってはいけないのだろう。まぁ所詮はバズワード。
……ところで、既存の、通常のコーディングでプログラムを作成する事は何と言えば良いのだろう？lowの逆だし、ハイコードだろうか？
閑話休題。幾つかノーコード、或いはローコードツールと呼べそうな物を使ってみたので、ノーコード/ローコードツールについての所感を記しておきたいと思う。使ってみたのは次の物：
Windows10上に本物のLinux環境を構築できる Windows Subsystem for Linux、略してWSL。現状、初代と vertion 2 の新旧2つが在るが、その新しい方、WSL2について。
続きを読む自宅PCにはOS(ディストリビューション)としてLinux (Fedora 22) を入れている。Linuxはそれを構成する各種ソフトウェアの独立性が高く、WM――ウィンドウマネージャ。GUI環境下で表示しているウィンドウの管理を行う――も入れ替えることが出来る。
今回、Awesomeというタイル型WMを導入してみた。「タイル型WM」とは、各ウィンドウを画面上にタイル状に敷き詰めて表示するタイプのWMだ。 Windows 8 (或いは Windows 10 のタブレットモード)で画面上に複数のモダンアプリを表示した時のような表示方法で、原則、ウィンドウ同士が重なる事がない。なお、 Windows 10 や、それ以前のデスクトップアプリでのウィンドウ表示の方式は「スタック型WM」とか「コンポジット型WM」という。
タイル型WMの良い所は、まさに「ウィンドウ同士が重なる事がない」という点に尽きる。考えてみれば、同時に使いたいソフトだから同時に起動している訳で、それぞれのウィンドウを並べるのは道理であるように思える。メーラーのような例外は、別の仮想デスクトップに配置しておけば問題ない。むしろ、自然と役割毎に仮想デスクトップを使い分ける癖がついて好都合とも言える。大体のタイル型WMはキーボードショートカットが充実しているのも、実に素晴らしい。
AwesomeはLuaというプログラミング言語で設定をカスタマイズ出来る。設定ファイルを0から作る事も出来るが、/etc/xdg/awesome/rc.luaに在るサンプルに手を加える事にした。というか、Luaを勉強した事がないので、サンプルが無いと何も出来ない。今の所の私の設定ファイルはこれ。サンプルはデフォルトの挙動を再現するコードで構成されているようなので、それらを削ればもっと短くなるだろう。
参考にしたページは以下の通り。
ただし、手元の環境だとアイコンファイルのパスが異なっていたり、ミュート解除時に-cオブションを付けると上手くいかなかったりしたので、その部分は変えている。
現状、かなり満足している。不満点は、キーボード操作のウェイトが増した結果ファイラであるnautilusの使い勝手が悪くなった事、GnomeのActivityのようなGUIソフトを選んで実行する仕組みが無い事ぐらいか。前者は代替品を探すとして、後者はどうしたものかなぁ。
しかし、もうちょっと名前は何とかならなかったものか。検索しにくいぞ。
最近、お仕事でNode.jsを使っている。Node.jsは、いろいろな処理が非同期処理を前提とした作りとなっており、「ある処理を行った後にする処理」を、「ある処理」を行う関数のコールバック関数として書く必要がある。例えば、ファイルに何か書く場合は、こう。
require('fs'); // ファイルのIOを行うfsモジュール読み込み。
fs.readFile('foo.txt', 'utf8', function(error, data) {
// エラーの場合は、コールバックの第1引数にエラーを表すオブジェクトが入る
if(error) {
console.log("error!");
return;
}
console.log(data); // ファイルの内容
});わお! ファイルを読むだけで1つコールバック関数が出てきた。
例に挙げたような単純な物ならば特に問題にはならないだろうが、大体のプログラムは、こんなに簡単ではない。ファイルを読んで、DBのAとBとCテーブル読んで、それらでゴニョゴニョした結果を別のファイルに書き込んで、そんな処理が2つも3つも在って……とやっていくと、出来上がるのは深い深ーいコールバック関数の「谷」である。人はコレを「コールバック地獄」と呼ぶとか呼ばないとか。
コレは拙いよね、どうにかしないとね。という訳で使われるのが、async.jsというライブラリ。というか、その中のwaterfallやseriesか。
この内、waterfall関数の効果的な使い方が、イマイチよく分からない。
この記事は、「Vim Advent Calendar 2013」の第77日目、通算2回目の担当記事である。
なお、昨日はosyo-manga(@manga-osyo)さんの「Vim Advent Calendar 2013: KaoriYa 版 Vim の +migemo を試してみた」だった。
更に、私のVAC2013担当記事1つめは「closesomewindow.vim – 条件に合うウィンドウを閉じる Vim plugin」だった。
ごめんなさい。
シェルスクリプトやその他大体のスクリプト言語に実装されている、以下のような機能のことである。
var = <<EOS
↑こういう風に、
"<<" + 識別子
という形式で書いたら、
次に識別子と同じ文字列が現れるまでの、
全ての行の内容を、
一つの文字列として取得出来る
↓この"EOS"までがヒアドキュメント
EOSある思いつきがあって、それが実現出来るのか確認する為に、 Win32 API を使ったコードを書いてる。
MinGWのgcc環境下で書いているのだが、Winternl.hが無いと怒られる。mingw32-w32apiパッケージを導入すればいいのかと思ったがそうでもない。
ググってみると、Rubinius開発者のIRCチャットログと思しき物がヒット。
00:08:29 natte src/mutex.c:2:22: fatal error: winternl.h: No such file or directory 00:09:02 natte strange seems like the platform SDK is missing, thought that would come with VS Ultimate but I guess not 00:33:46 brixen I think you're using mingw 00:33:51 brixen instead of mingw-w64 00:37:13 natte oh crap 00:37:17 natte you are correct
どうも、MinGWとは別にMinGW-w64というプロジェクトがあって、そっちを使えばいいらしい。
「個々のコンパイラ?Wolfram Mathematica 9 ドキュメント」曰く。
MinGW
CCompilerDriverパッケージはWindowsにおけるGCCのネイティブWindowsポートであるMinGW(http://www.mingw.org)について，Windowsプラットフォーム上でテストされている．このソースのMinGWは64ビットバイナリを生成しないことに注意されたい．この機能は汎用Cコンパイラのセクションに記載のMinGW-w64で提供される．
64ビットターゲット用MinGW
http://www.mingw.orgで入手できるコンパイラはWindowsの32ビットおよび64ビットの両方で動作するが，現時点では32ビットバイナリのみをコンパイルする．64ビットWolframライブラリを生成するためには，MinGW-w64（http://mingw-w64.sourceforge.netから入手可能）という別のプロジェクトを使う．
ううむ、MinGWとMinGW-w64が別物だという事は把握したが、何故、別になっているのか。MinGW-w64が(その名の通り)64ビット環境専用というのならば解るが、そういう訳でもないらしい。理由が分からんので若干モヤモヤする……
というか、導入するのが面倒くさいで御座る! MinGW関係のディレクトリにPATH通してるから、単純にインストールとPATH設定だけだと競合して変な事になるのが目に見えるてるで御座る!
あるC++プログラムをMinGWのGCCでコンパイルしようとしたら、吐き気がする程の大量のエラーメッセージが表示された。いやいやエラーになるにしてもこの量は有り得ないわ。何かが悪さしてるんじゃないか。
で、試しに超簡単なコード書いてコンパイルしてみようとしたらコケる。
> type test.cpp
#include <iostream>
int main(int argc, char *argv[])
{
std::cout << "hello" << std::endl;
return 0;
}
> gcc test.cpp
C:/Program Files/Haskell Platform/2012.4.0.0/mingw/bin/ld.exe: cannot open outpu
t file a.exe: Permission denied
collect2: ld returned 1 exit status
> g++ test.cpp
Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
c:/program files/haskell platform/2012.4.0.0/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
続きを読む
大分前になるけれど、上記の記事で、 Linux / Unix で用いられる「cat」コマンドの使われ方について紹介されていた。
catは、専らファイルの内容の出力に使われているイメージがある。しかし、catは「concatenate」(連結する)の略であり、本来はファイルを連結する為のコマンドだった(らしい)。
Linux / UNIX のcatに似たWindowsのコマンドとして「type」が在る。このtypeコマンドでも、上記記事で紹介された使い方の一部は実現出来る。以下でそれらを紹介する。
なお、typeはMS-DOSにも存在するが、そちらではどうかは確認していない(確認出来る環境が手元に無い)。
コマンドラインシェルの用途は2つ在る。対話的に処理させる場合と、バッチ処理させたい場合だ。バッチ処理用に起動した場合に、対話的環境での利用を想定した処理を行うのは無駄だ。例えばPowerShellでの場合、バッチ処理時にPowerTabモジュールを導入するのは意味がない。むしろ、その為の処理リソースを取られる事になるので、出来る限り避けたい。
続きを読む先日Windowsの環境変数について調べた際に、久しぶりにWSH用のJScriptを書いた。WSHはMicrosoftが提供するWindows用のスクリプト実行環境だ。
WSHの利点はWindowsにプリインストールされているという事だ。Wikipediaに拠ると、 Windows 98 以降であれば確実に入っているという。(RubyやPerl等とは異なり、)別途実行環境を用意する必要がないので、作成したスクリプトを配布する際にとても便利だ。
しかし、今となっては甚だ時代遅れで使いづらい。例えば配列の全要素を舐めるのに Array.forEach() が使えなかったり。現代のJavaScriptに触れていると、「あれも無い、これも無い」という点が気になってしまう。
流石にこれではキツイ。そこで Windows PowerShell に目を付けた。PowerShellはMicrosoftが新たに開発したコマンドラインシェル環境だ。これがまぁ意外と良い感じ。 Windows 7 からはプリインストールされているらしいし、将来的には導入コストは0になるだろう。
勿論、WSHはスクリプト実行環境でPowerShellはシェル環境なので、単純に比べられる物ではない。WSHとcmd.exeを合わせたものと比べるべきなのかもしれない。今までこの2つで行っていた作業をPowerShellで行うようにしてみたが、今のところ問題は発生していない。
個人的には、ドライブの機能に注目している。ディスクアクセスに用いるドライブレターのような識別子を用いて、様々なデータへのアクセスを共通のコマンドで行えるようにした仕組みだ。例えば、カレントディレクトリ以下のファイル/ディレクトリの一覧はGet-ChildItemコマンドレットで取得出来るが、Envという名のドライブへ移動した後なら同じ方法で環境変数の一覧を取得出来る。この仕組みはコマンドラインシェル以外にも応用が利きそうだ。エクスプローラのようなファイラ風のインタフェイスを備えたソフトから様々なデータにアクセスしたり。
amazon-bookmeter-link-adder.user.js ver1.01.20130425を作る時に、「@grant付けりーよー」とお猿さんに怒られたので、"@grant - GreaseSpot Wiki"を読んでみたが、イマイチこのメタデータの意義が分からない。
どうもセキュリティ関係の機構のようだが、"If a script does not specify any @grant values, Greasemonkey will attempt to auto-detect the right settings.
"と書かれているし、自動判定するのに要るんだろうかこれ。
ここで言う"起動時"というのは、GVim起動直後の.vimrc処理時で、多分、"has('vim_starting')==1"な時の事。
なお、GVim――つまりGUI用のVimでの話であって、コンソールで使う普通の(?)Vimでは問題ない。
NOTE: This function must not be used in a startup file, for
the versions that only run in GUI mode (e.g., the Win32 GUI).
しかしどうもinput()だけの話じゃ無いようで、以下の関数が使えなかった。
input()inputdialog()inputlist()confirm()ユーザーに何か問い合わせる系統かな……そういう関数って他にも在る?
inputで始まる関数群はまともに動かない(空文字列とか0が帰ってきている模様)だけだけど、confirm()が曲者で、Linux(Crunchbang)だとGVimの起動さえしない。
因みにWindows XPだと、第1引数と第2引数を改行で連結した内容がダイアログボックスで表示された。例えば、
call confirm('prompt', "Yes\nNo")とだけ書いたファイル(%HOMEDRIVE%%HOMEPATH%\test.vim)を用意して、以下のように実行すると、
gvim -u "%HOMEDRIVE%%HOMEPATH%\test.vim" -U NONE以下のダイアログボックスが表示される。
:autocmdにするとよさげ。やや意味合いが変わってくるけれど、影響は無いんじゃないかなぁ?
autocmd VimEnter * call confirm('prompt', "Yes\nNo")どうも、--cmdオプションで使った時も同様の問題が発生する模様(あまりきちんと調べていない)。
バージョン7.3で確認。
Avner Cohen : Git - Autocorrect spelling
へー、知らなかった。というわけで紹介。
Gitコマンドを打つ時(いや、Gitに限らないが)、何らかのtypoを犯してしまう事は良くある。
例えば、
git pusj # 本当はpush勿論Gitに"pusj"なんてコマンドは無いので、本来ならばエラーとなる。
エラーを確認し、正しいコマンドを打ち直すのは何とも面倒だ。しかし、ユーザーが意図していたコマンドを推測し、それを実行するようにGitを設定する事が出来る。
その為にはhelp.autocorrectを使う。
git config --global help.autocorrect 1help.autocorrectの引数は、補完対象のコマンドを実行するまでの待ち時間(0.1秒単位)である。上記の場合であれば0.1秒待つ事を意味する。
先の"pusj"の場合であれば、"push"のtypoである事が推測出来るので、Gitは以下の警告メッセージを出力後、指定の時間だけ待ってから"push"を実行する。
WARNING: You called a Git command named 'pusj', which does not exist. Continuing under the assumption that you meant 'push' in 0.1 seconds automatically...
(勿論"0.1 seconds
"の部分は、実際にhelp.autocorrectに設定した値によって変動する。)
待ち時間が在るのは、ユーザーの意図と異なる推測が行われた時に、それを(例えばCTRL-Cで)キャンセル出来るようにする為だろう。
なお、値を0にすると候補の列挙のみ(つまりデフォルトの挙動)、負数にすると待ち時間無しに推測したコマンドを実行する。
因みに私は20、即ち2秒待機するように設定している。誤った推測をキャンセルする事を考えると、数秒のウェイトは必要ではないかと思う。
※タイトルは一息に読む(変に長くてごめんなさい)。
作成途中に一度Qiitaに投稿したけど、どうも上手く動いてるようなので公開。"どうも"なんて不確かな表現なのはPipeの動作確認が超絶面倒だから。お察しくださいな。
任意のQiitaアカウントがフォローしているタグを付与された新着記事をfeed(RSS等)として出力するPipe。
例えば私の場合、アカウント名は"AmaiSaeta"なので、AmaiSaetaがフォロー中のタグ - Qiitaでリストアップされる24種(2012年7月22日現在)のタグが対象になる。
Qiita following tags feedにアクセスし、feedを取得したいユーザーのアカウント名を"Input a user name."テキストフィールドに入力しRun Pipe。後は"Get as RSS"のリンクをフィードリーダーに登録するなりなんなりお好きなように。
稀にtimeoutしている……ような気がする。Pipesレベルじゃ対処法が思いつかないので、仕様って事で。
というわけでアンケートを採ってみた結果。
コミットログは現在形?過去形?それとも……(択一)
- 現在形
- 5
- 過去形
- 3
現在形で書く人の方が多いらしい事が分かった。
まぁ、回答数が少なすぎて、有効な結果と言えるのかかなり怪しいけど……
とはいえ、役に立つ知見を得られたのも事実。
yossiy7 現在形・過去形というのは、ちょっと違っていて、実際は「誤：??→正：○○」とかそんな感じで一応過去形なので過去形にしたけど、両方ってのが正解かな。
「文章ではなく、記号的に記述する」というパターンは完全に想定外だった……
コメント欄でid:tyruさんが言及しているStack Overflow上の質問に付けられたこのコメントが引用している文章には以下の様に書かれている。
The use of the imperative, present tense is one that takes a little getting used to. When I started mentioning it, it was met with resistance. Usually along the lines of “The commit message records what I have done”. But, Git is a distributed version control system where there are potentially many places to get changes from. Rather than writing messages that say what you’ve done; consider these messages as the instructions for what applying the commit will do.
自分の(悲惨な)英語力を動員して読んでみるに、「Gitは分散VCSなので、(他の開発者の為に?)『そのコミットで何を行ったか』ではなく『そのコミットを適用する事で何が起こるか』を記述しろ」という事らしい。
私は今まで、「コミットログとは(ログの名の示す通り)変更内容を記述する物だ」という認識だったので、このようなコミットログの捉え方は考えた事がなかった。成る程この考え方ならば過去形はおかしいな。
しかし、その考え方は、適用する(pullしてくる)コミットを好き勝手に選べる環境じゃないと意味を成さないような……例えば、オリジナルのリポジトリからcloneし、その後変更点をpullする迄に、オリジナルに複数のコミットが追加されていた場合、「1つ目のコミットは無視するが、2つ目のコミットはpullする」のような場合(そもそも出来るのだろうか?)でも問題ないと保証出来る時に限られるのではないか?
それはかなり難しいと思うので、私はこのガイドラインには否定的。
尤も、件の365Gitには次のようにも書かれている。
Having said all that - it’s your code, your repository: so set up your own guidelines and stick to them.
あんまり気にせずに自分の好きなように運営するのが一番なのかもしれない。
現在、heroku gemのAPIを用いてのHerokuへのアクセスはdeprecatedになり、替わりに、heroku-apiを用いるようになっている(herokuコマンド自体は引き続き利用出来る)。
Herokuのconfig varをローカル環境下のスクリプト内で取得するには(heroku-api版)を参照されたし。
HerokuとGitHubの両方にプッシュできるようになったのはいいけど、例えばTwitterのOAuth認証用のトークンとか、何かのAPIを利用するためのAPIキーとか、あるいはもっと大事な何かのパスワードなど、秘密にしておきたい情報は、GitHubにプッシュしてしまうと全世界に公開されるので非常にマズい。
かといって書いておかないと、Herokuにプッシュしたときに情報が足らなくてアプリが正常に動かない。
どうするん？毎回消したり書いたりするの？
config varというのは、上記のようにHerokuとGitHubの両方にプッシュする時の秘密にしたい値の扱い - アインシュタインの電話番号?に記されているような要求をこなす時に使うheroku config:addで追加する値の事ね。
ENVでアクセス出来るし、正体はただの環境変数だと思うが、heroku help configにはconfig vars
と表記されてるのでそっちの表記を採用。
さて、このconfig vars、ruedapさんも言及してるように、Herokuの環境下でしか利用出来ない値で、ローカル環境での開発時にはENVに無い。彼も言っているような、ローカル環境かどうか判定して、同一内容をENVに突っ込むスクリプトをrequire、そのファイルは間違ってHeroku側のリポジトリにcommitしないように.gitignoreに書いておく……というのがサッと思いつく対処法か。だが、値の追加/編集時に、heroku configとそのスクリプト、両方を同一内容になるように保持するというのは流石にめんどくさい。
そんな馬鹿な。
おかしい。
あり得ない。
ぜんっぜんprogrammableじゃない。
そもそも、herokuコマンドはgemで導入する物だし、もしかしてライブラリとして利用する方法があるんじゃないの?
という訳で、herokuコマンドのソースを斜め読んでみると、次のようにしてRubyのスクリプトから取得出来る事が分かった。
#!/usr/bin/ruby
require 'rubygems'
require 'heroku'
require 'pp'
EMAIL = '(Herokuに登録した時に使ったメールアドレス)'
PASSWORD = '(Herokuのパスワード)'
APPLICATION = '(アプリケーション名)'
KEY = '(値を取得したいconfig varのKEY)'
heroku = Heroku::Client.new(EMAIL, PASSWORD)
# APPLICATIONの全config varを取得
vars = heroku.config_vars(APPLICATION)
pp vars # heroku.config_varsの戻り値はただのHash
# 特定のconfig varを取得
var = vars[KEY]
p val……コード中にメールアドレスだのパスワードだの埋め込むのは美しくない。何の為にconfig vars使おうとしてるのやら。
もうちょっとherokuのコードを読み進めてみると、既にheroku loginしているならば、Heroku::Client.newの替わりにHeroku::Auth::clientでも良さそう。
という事は、実際に使う時は次のような感じだろうか。
# 既にheroku loginしている事前提
require 'rubygems'
# ...snip...
if !ENV.key?('VAR1') # config varのどれか一つでも存在しない場合
require 'heroku'
config_vars = Heroku::Auth.client.config_vars(APPLICATION)
# PATHやLANGといったheroku config:addで登録した物以外も出てくるので、愚直に代入処理をしている
ENV['VAR1'] = config_vars['VAR1']
ENV['VAR2'] = config_vars['VAR2']
# ...以下全てのconfig varについて同様に
end
#...snip...うーん、ローカルかリモート(Heroku上)かの判定をENV.key?で行うのは何か変だな……もっとスマートな方法が在りそうな気がするが……
……というのが、忍者バリアーの趣旨らしいのだが……忍者バリアーは「荒らし」、スパムなどからのアクセスを簡単に拒否、制限できるサービスです。
『許可したドメインのJavaScriptのみ実行を許可する』アドオンのNoScriptを導入したFirefoxで、忍者バリアーを導入しているwebページを閲覧しようとすると……
![[忍者バリアーで飛ばされるページ]](https://agpg.up.seesaa.net/image/ninja-barrier.png)
問答無用で閲覧がブロックされる。
閲覧出来なかったページのソースコードを覗いてみる。
<script type="text/javascript" src="http://bar1.shinobi.jp/hash.js"></script>
<script type="text/javascript" src="http://bar1.shinobi.jp/s/40/00381.js"></script>
<noscript><a href="http://www.ninja.co.jp/barrier/" target="_blank">アクセス制御</a></noscript>
<noscript><meta http-equiv="refresh" content="0;URL=http://bar1.shinobi.jp/hoge/NoScript?0038140" />
<div style="background-color: #000000;text-align: center;vertical-align: middle;width:100%;height: 100%;margin: -10px;padding: 0px;z-index: 10;position: absolute;">
<div style="color: #ffffff;margin: 0px;padding: 0px;position: absolute;top:50%;left:47%;"><a href="http://www.ninja.co.jp/">NINJA TOOLS</a></div></div></noscript>スクリプトを実行出来ない環境下で適用する内容を記述するnoscript要素の下で、<meta http-equiv="refresh" ～ />を使い、忍者バリアーが用意したページにリダイレクトしている。
強制的に忍者バリアーの用意したページに移動してしまうので、元のサイトのスクリプト実行を許可する暇もない。
つまり、NoScript(或いは類似機能を導入したwebブラウザ)では、忍者バリアーを導入したページは閲覧出来ない。荒らしやスパマーか否かに拘わらず。
『荒らしやスパマーか否かに拘わらず』。
はい、大事な事なので2回言いました。
そもそも、
このホームページはJavaScriptを使っています。
ブラウザの設定でJavaScriptを有効に設定してから
アクセスしてください。
とか言っているが、JavaScriptが必要なのは忍者バリアー自身じゃないか。
また、世の中にはJavaScript使えないwebブラウザだって存在するのだ。そういったブラウザの利用者はどうしろと?
大体、忍者バリアーなんて簡単に通過できてしまうのだ。忍者バリアーで本当に防ぎたい荒らしやスパマーは、これくらいの対策はしてくるだろう。バリアー（）
結局、
忍者バリアーは、荒らしやスパマーに対しての効果が殆ど程めず、且つ、悪意の無い閲覧者にとってはページ閲覧の邪魔になりかねないという、全くのクソッタレなのだ。
敢えて言おう。
忍者バリアーは役立たずであると!
備忘録ともいう。
cygpath -w filepathcygpath -d filepathcygpath -u filepath -uがデフォの挙動のようで、省略しても動作する。
他に、Windowsの各種特殊フォルダ(デスクトップとかSystemフォルダとか)を出力させる事も出来たり、結構多機能。
Try `cygpath --help' for more information.
此処で出てくる"Visual C++ 2010"は正確には"Visual C++ 2010 Express SP1"の事ですはい。
以下やった事箇条書き。
実行すると……
D:\Documents and Settings\AmaiSaeta\qttest.vc>debug\qttest.exe 指定されたプログラムは実行できません。
ｱﾙｪｰ?
まぁVC++2010でVC++2008用のバイナリを使ったわけだから、変な事になるのも致し方なし……
仕方無いので、Qtをソースからビルド。
"%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat"
PATH C:\OpenSSL-Win32\bin\;%PATH%
SET INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE%
SET LIB=C:\OpenSSL-Win32\lib;%LIB%
PATH (Qtソース展開先)\bin;%PATH%
CD (Qtソース展開先)
configure -debug-and-release -opensource -shared -static -no-qt3support -platform win32-msvc2010
nmake![[Qtサンプルプログラムを実行すると表示されたAssertion Failedダイアログ]](https://agpg.up.seesaa.net/image/running_qt_sample_but_assert_failed.png)
ｱﾙｪｰ?
assertion failedしたf:\dd\vctools\ctr_bld\self_x86\crt\dbgdel.cppというファイルはこちらの環境には存在しない。というかf:ドライブなんて無い。という事は、Qtのbuildで使った(C++標準含む)ライブラリの何れかで発生していると思われるが、それを調査する気力は既に残っていないのであった……
