afpd からのエラー対処

volume "/hoge" does not support Extended Attributes or read-only volume

extended attributes が有効になっていない。/etc/fstabにて

UUID=f9d0cd90-5d2d-4379-9025-c69eb58e7006 /hoge ext4 defaults,user_xattr 0 0

オプションに user_xattr を追加する
 

parse_entries: bogus eid: 9

ディレクトリ内の ._ で始まるファイルを消したらなおった

 sys_lsetxattr("/hoge"): Permission denied

 

ログインユーザーからの hoge ディレクトリのアクセス権が無い。
ログインユーザーに公開しているディレクトリのトップ(afpd.conf path=のディレクトリ)の書き込み権限を与える。サブディレクトリに対しては書き込み許可の必要は無い。トップのみで良い。
ログイン可能ユーザーのグループをつくり、
groupadd afpuser
usermod -G smbuser ログインユーザーID
chgrp afpuser /hoge
chmod g+w /hoge
など。

posix_acls_to_uaperms(obj, path, st, ma) failed: Too many levels of symbolic links

acl = acl_get_file(path, ACL_TYPE_ACCESS) failed: Too many levels of symbolic links

間違って、自分をさしているシンボリックリンクがあると発生した。
シンボリックリンクを消す。
 

ATL COM Service のトラブル

Visual Studio 2012 / Visual C++ ATL Wizard で作成したオブジェクトが、Local Serverでは作成できるが、Serviceとして登録した場合に、オブジェクトが作成できない問題の解決方法。

対象のクラスの .rgs ファイルに AppId 値を追加する。
再コンパイルを行う
xxxx.exe /service　で登録する


HKCR
{
 NoRemove CLSID
 {
  ForceRemove {6E94C55F-4AE0-45F1-A6A1-47C97110E1A4} = s 'Manager Class'
  {
   ForceRemove Programmable
   LocalServer32 = s '%MODULE%'
   {
    val ServerExecutable = s '%MODULE_RAW%'
   }
   val AppID = s '%APPID%'
   TypeLib = s '{FDEF3EA6-16EE-4421-996D-E615C277C041}'
   Version = s '1.0'
  }
 }
}

error: call to implicitly-deleted default constructor of '...'

error: call to implicitly-deleted default constructor of '...'


clang, C++ の一見して何が悪いかわからないエラー。

エラーとなるクラスのメンバー変数にデフォルトコンストラクターがないクラスのオブジェクトがあると発生する。
 

NSOperationQueue, NSOperation メモ

キューのキャンセル

- [NSOperationQueue cancelAllOperations] - [NSOperationQueue waitUntilAllOperaitonsAreFinished] を行なった後のキューに、あたらしいオペレーションを追加すると、変な場所で EXEC_BAD_ACCESS 例外が発生する。キャンセルしたキューは再利用しないで、再作成すべき。

複数のキューにまたがる依存・優先関係

複数のキューを作成し、 - [NSOperation addDependency] をもちいて、複数のキューをまたがる依存関係(dependency)を作ることが出きる。

平行実行数を押さえたキューと、無制限のキューを併用して、オペレーションの個数を制御しながら、OOB的なキューで終了や優先処理を行なうなどができる。単一のキューでごちゃごちゃ操作するより簡単。

キャンセル処理

- [NSOperation cancel] を受けたら、isFinished = YES に移行しないと、オペレーションがキューに溜まったままになる。特に、開始していないオペレーションに対する処理をわすれがち。

キューの平行動作数と子オペレーション、currentQueue の問題

子オペレーションを利用する場合、+ [NSOperationQueue currentQueue] で取得した現在のオペレーションキューに、子オペレーションを追加し、KVOで終了を待つ処理は危険。

現在のオペレーションキューに、平行動作オペレーション数の余裕がないと、たちまちデッドロックする。
平行動作数を変更すれば動くようになるかもしれないが、キューの平行動作数に依存する実装は好ましくない。

子オペレーションを使う場合、そのオペレーションのインスタンスに NSOperationQueue を作成し、そこに子オペレーションを追加すると良い。

なお、平行実行数が無制限なら問題はおきない。平行実行数無制限で組んだあと、パフォーマンス調整のため、「フォアグラウンドが重いなら、バックグラウンド平行実行数をおさえりゃいいんじゃね?」的に - [NSOperationQueue setMaximumConcurrentOperations:] を加えた瞬間、うごかなくなったりするので気をつける。
 

tomcat で war をデプロイできずにはまったこと

要約:

 

• tomcat (7で確認)では、すでにある webapp を War のアップロードで上書きでプロいできないようだ。
• まず、Undeploy してからデプロイすれば更新される。
• server.xml の設定項目は、（たぶん）関係ないので頑張るだけ無駄。
• デプロイ時のエラーメッセージはサーバーマネージャーのタイトルの下、小さな枠内に、すごく控えめに表示される。よーくみていないと、エラーに気づかない。

 

詳細:

 

deploy ができなくなった、とおもったが、とても初心者な勘違い。

 

Tomcat Web Application Manager 　の Deploy - War file to deploy で、ファイルをアップロードすると、そのままデプロイ出来るのかと思っていたが、そうではない。

 

検索すると、server.xml のunpackWARs や autoDeploy に関するが引っかかるが、関係なかった。

 

 

アップロード後、なにもエラーないので(ここが勘違い)、デプロイできているのかとおもいきや、コードの変更が反映されない。エラーメッセージがめだたなくて、気づいていないだけだった。エラーメッセージは、画面上部、Message: に表示される。失敗メッセージが <TT> の目立たないフォントで表示されてて、気づかなかったのが敗因。

 

 

Xcode 4.4 にしたら git が使えなくなった

Xcode 4.4 にしたら、既存の　git のワーキングコピーに対するソースコントロールができなくなった。

Project Navigator のソースコントロール状態を示す "M" とか"A"とか "C"のマークが出ない。Version Editor 画面でリビジョン比較ができない。プロジェクトと git との関連性が失われたような感じ。

手動(コマンドラインなど)で git の操作をしていたプロジェクトで発生するようだ。Xcode 4.4 より前は、フォルダに .git があるだけで良かったが、Xcode 4.4 になり挙動がかわったようだ。

解決方法:

問題があるプロジェクトが開いていたら閉じる

Organizer の Repositories を開く
左下の '+' で "Add Working Copy..."
".git" がおいてあるフォルダを指定

Organizer の Projects を開く
プロジェクトをオーガナイザーから削除
左の一覧で Ctrl+Click して Remove From Organizer
一覧から削除されるだけで、プロジェクト本体に影響はない

プロジェクトを開く

以上で直るはず

CentOS 6.2 に cups-pdf をインストールする

インストール手順にしたがったら CUPS で一覧表示されなかったのでメモ。
cups-pdf のパーミッションに注意。

http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/download.shtmlからソースのtarballをダウンロードする。

http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/documentation.shtmlの Installation に準じてインストールするが、追加作業を要する。

• Modify the file cups-pdf.h to set the location of the configuration file.

修正不要。オリジナルのままでかまわない。


• Compile cups-pdf.c in the same directory as cups-pdf.h is located and move the binary to CUPS' backend directory (/usr/lib/cups/backend/cups-pdf)
  
  [ e.g. by calling "gcc -O9 -lcups -s -o /usr/lib/cups/backend/cups-pdf cups-pdf.c" ]

この通りコンパイルする。

/usr/lib/cups/backend/cups-pdf のパーミッションを調整する必要がある。
chmod 700 /usr/lib/cups/backend/cups-pdf
これをしないと、CUPSが認識しない。


• Copy the file cups-pdf.conf to /etc/cups/cups-pdf.conf (or whatever you set above in cups-pdf.h) and modify it to meet you requirements. All options are commented and the defaults should work fine on most systems.

修正不要。オリジナルのままでかまわない。


• Copy the file CUPS-PDF_opt.ppd to /usr/share/cups/model/Generic/CUPS-PDF_opt.ppd
  [ if you do not wish to use option setting via PPD you can use CUPS-PDF_noopt.ppd instead ]

/usr/share/cups/model/Generic はないので mkdir する必要がある。
というか、/usr/share/cups/model にコピーすれば良い。

Xcode4 の特定のプロジェクト(ターゲット)が Attaching to ... で常にハングアップする

(2012/1/10修正追記)

Xcode で Simulator を使ったデバッグを開始しようとすると、"Attaching to アプリ名" のところで常にハングしてデバッグセッションを開始できない プロジェクトができてしまった。

Stack Overflow のこの問題のスレッドには多数のレスがあり、原因・解決方法も多種多様のようだ。

私の場合、

One more possible solution: I had my Resources folder added to the project as a folder reference (the blue folder icon). That caused the trouble, after adding the folder as a group the problem went away.

まさに、この状況で発生した。ハングアップはリソースを Folder Reference で追加した直後だった。

レスにあるように Folder Reference を Folder As Group に変えてみたが、それだけでは解消しなかった。

1. Folder Referenceを削除、Folder As Group でリソース類を追加し直す
   
2. *.xcodeproj/xcuserdata/*.xcuserdatad を削除
   
3. Simulator をリセット (Reset Contents And Settings)
   
4. ~/Library/Developer/Xcode/DerivedData/アプリ名-* を削除
   

私の場合、この4つを行ったら、ハングアップが解消された。

CIImageを描画する方法

CIContext を作る等やってみていましたが、なかなかうまく行かない。
この方法が簡単なようです。

- (void)drawRect:(CGRect)rect
{
    [[UIImage imageWithCIImage:_image] drawInRect:rect];
}

.ipa ファイルを配布するときの名前をきっちりつけたい

ipautil について。

iOS 開発では、"Archive"でアーカイブを作り、Share... で Adhoc 配布します。
Adhoc配布をするパッケージは、社内サーバーの所定の位置に配置して、
テスターがダウンロードしておのおのインストール、テストを行うのが
普通だと思います。

テスターの人にわかりすいよう、ファイルをアプリケーションごとのディレクトリに分けていれたり、ファイル名にリリース日付を入れたり、バージョン番号を入れたりしたいものです。

ところが、Xcode の Share... では app.ipa というファイル名がデフォルトになります。配布する人(私)は、わかりやすいファイル名を、間違えないよう注意しながら、手入力しなければなりません。

この入力は結構神経を使います。さらにまずいことに、この作業ステップは、コーディングを散々したあげく、テストがやっと通り、ああもうすぐにでもこいつをリリースしちゃって寝たい、という極限状況で訪れます。

一刻も早く寝たいのです。格納場所が間違っていてテスターにファイルがわたらなかったり、バージョン番号が間違っていて、どのファイルが最新?みたいな質問で起こされたくありません。

そこで、アプリケーション名やバージョン番号を ipa ファイルから抜き出すユーティリティを作りました。これを使えば、決まった形式で、決まった場所にコピーするシェルスクリプトを書くことができます。

こんな者を使うのはプロの方だけだろうとおもうので、ソース配布です。
BSDライセンスで ここに置きました。

Xcode 4.2 でビルドできます。libarchive が必要です。
libarchiveは、ふつうに configure / make したもので OK です。

Xcode 4.2 / iOS開発でスタティックライブラリを利用する

Xcode 4.2 で iOS のスタティックライブラリを作り、自分で利用する
スタティックライブラリとアプリケーションは別のプロジェクトとする。

せっかちな人用

ライブラリを使う側:

• スタティックライブラリのプロジェクトの .xcodeproj を、プロジェクトに追加する。
• ターゲットの Target Dependencies および Link Binary With Libraries に対象のライブラリを追加する。
• プロジェクトレベルの Build Settings の Header Search Paths に下記を追加
  $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/usr/local/include
  $(INSTALL_ROOT)/usr/local/include

ライブラリ側:

• 公開したいヘッダーファイルの属性を変更する。File Inspector の Target Membership のチェックボックスをチェックかつPublic に変更する。

一般的な考慮事項

ライブラリを利用する場合、

• コンパイル時にライブラリが提供する定義が入ったヘッダーをインクルード
• リンク時にライブラリファイルをリンク

の二点が必要になる。前者はコンパイラーの -I オプションに関する設定であり、後者はリンカーの -L のディレクトリ指定、-lのライブラリ指定に関わる設定だ。
両者を適切に設定しないと、コンパイルできない(.hが見つからない)、リンクできない(未定義シンボル)といったトラブルになる。

スタティックライブラリの作成方法

プロジェクト作成時に、Cocoa Static Library を選択する。ここまでは簡単。

ライブラリの名前のつけ方に注意。
Unix系のライブラリは libなんとか.a というファイル名とするのが慣例で、この名前にするために、プロジェクト名は、「なんとか」の部分だけを指定する。

例えば、libpicture.a を作ろうとしている場合、Xcode でのプロジェクト名は "picture" だけを指定する 。"libpicture"などと指定すると、liblibpicture.a が作られてしまい気持ちが悪い。あとで修正するのも面倒だ。

Xcode プロジェクトにライブラリのプロジェクトを追加する。

アプリケーションのプロジェクトに、スタティックライブラリの .xcodeproj ファイルを追加する。追加するのは .xcodeproj であり、スタティックライブラリプロジェクトのディレクトリではない。

• "File" "Add Files To ..."で出てくるダイアログで .xcodeproj ファイルを指定して "Add" する。
• この作業で、プロジェクトの中にライブラリのプロジェクトが包含され、以下の手順で、ライブラリが選択可能になる。
  プロジェクトナビゲーターはこんなかんじになる。
  
  ここでは "usesample アプリケーション" のプロジェクトに "sample スタティックライブラリ"のプロジェクトを追加した。
• ただし、これだけでは、インクルードもできないしリンクもしない。下記の手順が必要。

スタティックライブラリがヘッダーファイルを公開する方法

スタティックライブラリは、ライブラリ関数のプロトタイプや各種定義類が入ったヘッダーファイルを提供する。automake/autoconfを使う場合は make install で /usr/local/include などにコピーするのだが、アーキテクチャの違う iOS ライブラリをそのような場所にコピーする訳にもいかない。

Xcodeでは少し変わったビルド方法をとっている。公開するヘッダーファイルをプロジェクト内の領域(DerivedData下)にヘッダーファイルをコピーして、依存関係のあるプロジェクトでヘッダーファイルを参照する仕組みだ。

公開したいヘッダーファイルを Project Navigator(⌘1)で選択し、File Inspector(Option+⌘+1)のTarget Membershipでライブラリターゲットのメンバーとするよう、チェックを入れる
また、Target Membership の "Project" となっている部分を Public に変更する。

• ヘッダーファイルはデフォルトでは Target Membership が off になる。
• また、ライブラリプロジェクト以外では、ヘッダーファイルの Target Membership を on にできない。

• この操作により、ヘッダーファイルが DerivedData 下のビルドディレクトリにコピーされ、別プロジェクトから利用できるようになる。

スタティックライブラリが公開したヘッダーファイルをインクルードする設定。

プロジェクト内の領域(DerivedData下)にコピーされたヘッダーファイルを利用できるように設定する。ライブラリを使用するターゲットの "Header Search Path" に下記の2行を追加する。

$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/usr/local/include
$(INSTALL_ROOT)/usr/local/include
(2011/10/18追記: Archive時、これがないと include が見つからない)

検索ボックスで "header search" と入れると見つけやすい。設定項目の表示が Basic だと出ないので注意。
プロジェクトレベルの Header Search Paths に、本設定を追加しても良い。

依存関係および、リンク対象とする設定を行う

アプリケーションの Target の Build Phases を開く。

Target Dependencies に、利用したいスタティックライブラリを追加する。

• こんなかんじ
  
• この作業で、アプリケーション Target をビルドする前にライブラリのソースファイルの依存関係がチェックされ、必要なら再ビルドされる。
• この依存関係は .c -> .o -> .a を再構成するだけでなく、ヘッダーファイルの変更にも影響する。リンクしないがヘッダーファイルをインクルードする場合(スタティックライブラリが別のスタティックライブラリを利用しているようなケース)でも、この依存関係を設定する必要がある。
• Target Depencency を適切に設定していないと、オブジェクトファイルの変更が、ターゲットアプリケーションに反映されないだけでなく、ヘッダーファイルの変更までも無視されてビルド・デバッグが混乱するので要注意。
• 完成されたライブラリなど、変更されないライブラリなら、依存関係を設定する必要はない。

Link対象となるように設定する

Link Binary With Libraries に、リンクしたいライブラリを追加する。

• これでアプリケーションにライブラリがリンクされる。
• こんなかんじになる
  

以上。
これで複数プロジェクトに分かれたスタティックライブラリ・アプリケーション間でコンパイル、リンクがスムーズに通るようになるはずだ。

Xcode4 でうるさい no previous prototype for function 警告を消す

急いでいる人用:

-Wmissing-prototypes をつけないようにする。

Xcode で、Project または Targetの Build Settings を表示して、
Apple LLVM 3.0 Warnings
Missing function prototypes
をNo にする。

解説

Xcode 4.2 では、これまでより多くのコンパイラー警告が出るようになっている。
そのなかでも特に五月蝿いのは、プロトタイプ宣言がないC言語関数の定義だ。

warning: no previous prototype for function 'somefunction'

警告の趣旨としては、プロトタイプ宣言がないから、別のモジュールでその関数の戻り値・引数が間違って利用されいる可能性があり、実行時に予期せぬ結果になるということだろう。この点は、もっともと言える。

しかしながら、ひとつのソースファイル内のみで用いられるプライベートな(staticをつけても大丈夫な)関数の場合、前方参照にならないかぎり、プロトタイプ宣言を書かないのが普通だろう。

この警告を消す正統な方法は 関数を static にしてしまうことだ。だが、過去のコード、他の開発環境で作られたコードでは、この点について無頓着な場合が多く、大量の "no previous prototype ..." を吐き、重要な警告が埋もれてしまう。

この警告は -Wmissing-prototypes をつけると発生する。Xcode 4.2 でプロジェクトを作成すると、このオプションがデフォルトでついてくる。これを外せば良い。

警告がどの警告オプションで出力されているか調べる方法

Xcode 4.2 (というか Apple LLVM 3.0) は、警告メッセージの最後に、その警告をださせている警告オプションを表示するようになった。Xcodeエディタ上に出現する黄色い警告マークのポップアップでは、メッセージの後ろの方が切れて見えないのだが、Log Navigator (⌘7) で詳細を見ると、

warning: no previous prototype for function 'somefunction' [-Wmissing-prototypes,3]

などと表示され -Wmissing-prototypes によって出力されている警告だということがわかる。Xcode の Build Settings の検索ボックスに "-Wmissing-prototypes" と入力すれば設定項目が一発で見つかるはずだ。

Xcode4 で Build Configuration を削除する方法

Xcode3 で Adhoc ビルドをする場合は、Adhoc 用のビルドコンフィグレーションを作り、AdHoc の Provisioning Profile を設定する。

Xcode4 では、Build -> Archive でアーカイブ用ビルド(通常は Release コンフィグレーション) を行い、アーカイブ後に Provisioning Profile を指定するので、AdHocビルドが不要になる。

不要になった AdHoc の消し方。

プロジェクトナビゲーターでプロジェクトを選択する。
Info タブを選択する。
iOS Deployment Target の下、"Configuration" 内の AdHoc (削除したいコンフィグレーション)を選択する
Delete キーを押す (または、リストの下にある - ボタンを押す)

Xcode 系覚え書き

デバッグ時のコマンドライン引数の与え方

Product -> Edit Scheme -> Argument Passed On Launch

apache 2.2 の make で libtool が無いと言われてしまう

Apache再インストール時には apu-1-config に注意。

間違って /usr/local/bin, /usr/bin などに apache をインストールしてしまった場合は、apu-1-config の残骸をきっちり消す事。

以下、経緯。

apache 2.2 をインストールしていた。configure の --prefix をまちがえて --prefix=/usr/local として configure, make, make install インストールしたら、/usr/local 下に諸々がインストールされてしまった。まあ、ここまでは、よくある凡ミス。

/usr/local 以下にちらばった apache 関連のファイルを削除し、--prefix=/usr/local/www として再度 configure, make したのだが、make が通らない。コンパイル時に /usr/local/build/libtool という存在しないコマンドが使われてしまう(エラーメッセージは下の方に)。

まちがった "configure --prefix=/usr/local" の影響を受けているな、ってところまでは明白なので、make distclean して再 configure しても状況はかわらない。tarball を開き直しても状況はかわらない。

これは、先に失敗した --prefix=/usr/local の make install で作られた apu-1-config というコマンドが、PATHのかかった /usr/local/bin に残っていて、configure が、このコマンドを使い libtool の位置を特定していたのが原因だった。間違ってインストールしてしまったファイルを削除したつもりが削除しきれいてなかった、ってわけだが、configureで以前のインストールした実行ファイルを使ってしまうとは・・・

エラーメッセージはこんな感じでした。

/usr/local/build/libtool --silent --mode=compile gcc -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/naoshi/src/httpd-2.2.19/srclib/pcre -I. -I/home/naoshi/src/httpd-2.2.19/os/unix -I/home/naoshi/src/httpd-2.2.19/server/mpm/prefork -I/home/naoshi/src/httpd-2.2.19/modules/http -I/home/naoshi/src/httpd-2.2.19/modules/filters -I/home/naoshi/src/httpd-2.2.19/modules/proxy -I/home/naoshi/src/httpd-2.2.19/include -I/home/naoshi/src/httpd-2.2.19/modules/generators -I/home/naoshi/src/httpd-2.2.19/modules/mappers -I/home/naoshi/src/httpd-2.2.19/modules/database -I/usr/local/include -I/home/naoshi/src/httpd-2.2.19/server -I/home/naoshi/src/httpd-2.2.19/modules/proxy/../generators -I/home/naoshi/src/httpd-2.2.19/modules/ssl -I/home/naoshi/src/httpd-2.2.19/modules/dav/main -c maketables.c && touch maketables.lo
/bin/sh: /usr/local/build/libtool: No such file or directory

Xcode 4 のコンパイルエラーつぶしをやりやすくする設定

Xcode 4 でエラーが起きたとき "Issue Navigator" にエラーが表示され、ソースコードにエラーメッセージが赤字で表示されるが、いずれも表示領域が小さく、エラーが起きた具体的なシンボル名などが表示されずイラっとくる。詳細を見るために、右クリックメニューから "Reveal in Log" を選択しなければならずめんどくさい。

Behavior をいじることで、ビルドエラーがおきたときに、エラーメッセージを、メインウィンドウのタブで読みやすく表示する方法についての設定メモ。

Preferences / Behaviors の "Build fails" の項目を下記のように設定。

• Show "Issue Navigator"

Xcode の左側にエラー一覧が出る。が、これだけではメッセージが読みにくいので、さらに設定・・・


• Hide Debug Area

デバッグ領域を隠す。エラーが起きてるから、デバッグ領域は要らないでしょう。ただ、ウィンドウやエディタサイズががちゃがちゃ動くのも見苦しいので、この機能を使わない(チェックを入れない)のもありだと思う。



• Show Tab "Build Log"

Build Log という名前のタブがなければ作成し、そのタブを表示する。
この設定がないと、ビルドしていたときに開いていたタブ(たいていの場合、直近に編集していたソースファイル)のあった場所にエラーログを表示してしまう。


• Navigate to current log

作成した "Build log" タブに現在のログ(つまり、失敗したビルドログ)を表示する。