Allan Odgaard mailinglist@textmate.org wrote:
On Mar 8, 2013, at 3:59, Matt Neuburg wrote:
Allan Odgaard wrote:
Did you run the above with Ruby 2.0?
Sure, and it outputs "test", but I really don't quite see what it has to with what I asked.
It is testing if the core functionality that TextMate.executor relies on is available and works in ruby 2.0.
In Ruby 2.0 (but not in Ruby 1.8.7 or Ruby 1.9.3) we are failing on the "for_fd" line. The question is what to do about that.
Figure out which assumption 2.0 breaks, which is what I was trying to do by having you run the code that tests our core assumptions (creating a pipe and getting the write-end by creating a file descriptor from its integer representation).
Could it be that the TM_ERROR_FD pipe created in executor.rb is
somehow not surviving? Is it being closed too soon somehow?
It does look like it is being closed, though _nothing_ in the user script should close this file descriptor, so the most likely explanation would be, that ruby 2.0 closes all open file descriptors (except 0-2) and _before_ handling at_exit code.
I find this a little weird though, if they are actually doing that - should be possible to test though.
Okay, thanks for the clue; following that up, I was able to discover this: system() and exec() and spawn() and IO.popen() in ruby 2.0 apparently close non-standard file descriptors by default (that is to say, everything except 0, 1, and 2). It may be that this can be prevented by passing :close_others=>false (which can itself be overridden by setting the fd's close-on-exec flag).
We are now well out of my depth. :) But it does seem to me that this has something to do with the case (though I do not know exactly what), since it is raising exactly the sort of red flag of incompatibility that we're looking for.
More info at http://ruby-doc.org/core-2.0/Kernel.html with heavy details particularly under "spawn".
Let me know if there's something you want me to try! Thx - m.