Greg Hazel

I'm not a developer on the daemons project, I just forked it to fix a bug myself.

I would expect module / class methods to keep no state, and the `C::Parser.new` approach to be used when state should be kept on that object.

``` ruby $ irb 1.9.3p286 :001 > require 'cast' => true 1.9.3p286 :002 > C::Preprocessor.new.preprocess_file('/usr/include/math.h') Errno::ENOENT: No such file or directory - /usr/include/cast-preprocessor-input.20140218-12133-xon498.c.lock from /Users/ghazel/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/tempfile.rb:346:in `rmdir' from /Users/ghazel/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/tempfile.rb:346:in `rmdir' from...

Fwiw, this fixes it for me: https://github.com/axonal/Distance-Measures/commit/5c44fce40a5f4180a3734fbf2e3c7ec92c02c16d

async_sinatra has the same issue. ``` ruby require 'async-rack' require 'sinatra/async' class TestServer < Sinatra::Base register Sinatra::Async set :server, 'thin' aget '/' do body("Hello, world!") end end TestServer.run! ```

Rails/ActiveRecord 2.3.10, ar-extension 0.9.3

Why default off? The goal here is to protect against developer error/unawareness of the limitation. They're probably also likely to not remember/know about the option. Is there a case where...

Hm. I would be surprised if a DELETE trigger significantly affected the performance of non-DELETE operations. But, I agree with your point about errors being only marginally better than ignoring...

+1 I had a need for this as well ("delete=" and "head=" are implemented, but not "delete" and "head" to return a boolean).

Yeah it doesn't happen every time or anything. In fact it happens very very rarely, and I'm not sure which codepath triggers it. It is fairly harmless, I just thought...