以下のサイトに手頃な文量で要点がまとまっているので参考になりました。

• SCons：基本的な使い方

公式ドキュメントは以下にあります。

• http://www.scons.org/documentation.php

SCons本が欲しい今日この頃。 達人出版会 に期待したい。

git svnを以下のような構成で使っていた時に、git svnのリモートトラッキングブランチのpointerがtrunkに代わってしまい、いつのまにかブランチにcommitしたつもりのものがtrunkにcommitされるという事があり、困りました。

gitから.gitにpushしたものを git-svnからpullしたタイミングで発生するようです。 解決策としては、git-svnでgit pullをせずに、

   1  % git fetch remote-name
   2  % git merge --no-ff remote-name/branch-name
   3  % git svn dcommit

でok. アクシデンシャルなdcommitを防ぐには、--dry-runが便利です。

git-svnを使っていて、git svn dommitするときに、 掲題のようなエラーメッセージが出た場合、リモートリポジトリとローカルリポジトリのトラッキングブランチの同期が取れていない事が原因かもしれません。

例えば、SVNリポジトリ上で削除されているブランチが、ローカルのgitリポジトリに残ってしまっている場合、以下のようにリモートトラッキングブランチを削除する事で問題を解決できる可能性があります。

   1  % git branch -D -r <branch name>

SConsを使ってscons testでテストを実行するには、 SConstructもしくはSConscriptで以下のように書く （Google Test仕様）

   1  import os, sys
   2  Import('env')
   3  env = env.Clone()
   4  
   5  test = env.Program('test', Glob('*.cpp'), LIBS='gtest')
   6  test_alias = Alias('test', [test], test[0].abspath)
   7  AlwaysBuild(test_alias)

See Also

• 開発環境向上wiki - SCons

PLY形式のモデルデータをMSH形式に変換する方法のメモ。

MT Package の FORM2FORMコンバータを使います。 このページの下のほう から mtjade.tar.gz をダウンロードして展開し、FORM2FORMディレクトリに移動してmakeします。 使い方はこんな感じです。

   1  % ./form2form foo.ply foo.msh

以下の行をコメントアウトしておくと、indexedではないmshが生成されます。

   1  #define INDEXED

MSH形式の仕様は こんな感じ です。

しばらく前から安定性が悪くなってきたのですが、ここに来て頻繁にPassengerのプロセスが暴走するようになってきました。

• ruby 1.8.7 (2009-04-08 patchlevel 160) [i686-linux]
• Passengerのバージョンは2.2.8
• Rails 2.3.5

プログラムやシステム構成はここしばらくほとんど変えておらず、トラフィックも大きな変動はないので、うわさのEC2のサービス劣化の影響でしょうか。

Formulaを使って数式の画像を生成するときに、数式のサイズを指定する場合、以下のようにするとうまくいきます。

   1  \mbox{\Huge $\displaystyle
   2  I_j=\int_\Omega f_j(\bar{x})\,d\mu(\bar{x})
   3  $}

出力結果は以下の通り。

CUresultの値一覧表です。

   1  CUDA_SUCCESS                = 0,    ///< No errors
   2  CUDA_ERROR_INVALID_VALUE    = 1,    ///< Invalid value
   3  CUDA_ERROR_OUT_OF_MEMORY    = 2,    ///< Out of memory    
   4  CUDA_ERROR_NOT_INITIALIZED  = 3,    ///< Driver not initialized
   5  CUDA_ERROR_DEINITIALIZED    = 4,    ///< Driver deinitialized
   6  
   7  CUDA_ERROR_NO_DEVICE        = 100,  ///< No CUDA-capable device available
   8  CUDA_ERROR_INVALID_DEVICE   = 101,  ///< Invalid device
   9  CUDA_ERROR_INVALID_IMAGE    = 200,  ///< Invalid kernel image
  10  CUDA_ERROR_INVALID_CONTEXT  = 201,  ///< Invalid context
  11  CUDA_ERROR_CONTEXT_ALREADY_CURRENT = 202,   ///< Context already current
  12  CUDA_ERROR_MAP_FAILED       = 205,  ///< Map failed
  13  CUDA_ERROR_UNMAP_FAILED     = 206,  ///< Unmap failed
  14  CUDA_ERROR_ARRAY_IS_MAPPED  = 207,  ///< Array is mapped
  15  CUDA_ERROR_ALREADY_MAPPED   = 208,  ///< Already mapped
  16  CUDA_ERROR_NO_BINARY_FOR_GPU = 209, ///< No binary for GPU
  17  CUDA_ERROR_ALREADY_ACQUIRED = 210,  ///< Already acquired
  18  CUDA_ERROR_NOT_MAPPED       = 211,  ///< Not mapped
  19  CUDA_ERROR_INVALID_SOURCE   = 300,  ///< Invalid source
  20  CUDA_ERROR_FILE_NOT_FOUND   = 301,  ///< File not found
  21  
  22  CUDA_ERROR_INVALID_HANDLE   = 400,  ///< Invalid handle
  23  
  24  CUDA_ERROR_NOT_FOUND        = 500,  ///< Not found
  25  
  26  CUDA_ERROR_NOT_READY        = 600,  ///< CUDA not ready
  27  
  28  CUDA_ERROR_LAUNCH_FAILED    = 700,  ///< Launch failed
  29  CUDA_ERROR_LAUNCH_OUT_OF_RESOURCES = 701, ///< Launch exceeded resources
  30  CUDA_ERROR_LAUNCH_TIMEOUT   = 702,  ///< Launch exceeded timeout
  31  CUDA_ERROR_LAUNCH_INCOMPATIBLE_TEXTURING = 703, ///< Launch with incompatible texturing
  32  
  33  CUDA_ERROR_UNKNOWN          = 999   ///< Unknown error

Linux環境でNVIDIAのCUDA/OpenCLを使う場合、以下のような環境変数の設定に注意する必要がある。

   1  NV_COMPUTE_SDK_PATH="/path/to/NVIDIA_GPU_Computing_SDK"
   2  SDK_INSTALL_PATH="/path/to/NVIDIA_GPU_Computing_SDK/C"

まだリリースされて間もないせいか、 NVIDIAのOpenCL SDKを使っていると不可解なエラーに遭遇します。 掲題のようなエラーメッセージを出すのもその一例ですが、 以下のようなコード（一部抜粋）でエラーがでます。

   1      float4 x = sphere->c;
   2      dg->t = x.x;

しかし以下のように記述すると大丈夫です。

   1      float x = sphere->c.x;
   2      dg->t = x;

OpenCLコンパイラが生成したptxコードの中に'selp'というのが入るような場合に問題が発生するようです。

NVIDIAのOpenCL SDKの場合、*.clファイルをCLコンパイラがコンパイルして、ptxという中間言語に変換します。さらに、ptxをptxparse（PLANGというパッケージの一部らしい）が解析してllvmのbcに変換します。 このケースでは、CLコンパイラが吐き出すコードと、ptxparse側の認識が一致していない感じです。 とりあえず、バグが直るまでコンパイラの気持ちになって回避するしかありません。