Kjetil -- > this isn't really a very unique problem to solve, a lot of applications > have done this before, efficiently. (e.g., reading large blocks is > guaranteed safe when reading from "slow" devices, this includes pipes > and sockets. a "fast" device (ie. hard disk) will hang until the whole > request is fulfilled, but you need a hardware error for that to happen.)
I would love to have a patch which resolves this, if you'd care to submit one. I believe you are oversimplifying the issue (easy to do, from the sidelines; I was in the same boat just weeks ago) but I could be mistaken. Working code would be a great way to make me admit that you are right and I am wrong, and earn my eternal gratitude as well. :) >>>> ENV['LANG'] = ENV['LC_ALL'] = ENV['LC_MESSAGES'] = >>>> ENV['LANGUAGE'] = 'C' >>>> Kernel.exec(*command) >>> >>> not part of your patch, but I couldn't resist commenting on this cargo >>> cult code :-). setting ENV['LC_ALL'] is sufficient. 'LANGUAGE' is not >>> POSIX, and not consulted when LC_MESSAGES (effectively) is 'C'. >> >> We got into this problem by cleaning up code that was "obviously" >> unneeded and found to our dismay that there were environments were it >> was not as superfluous as it appeared. You may be perfectly correct >> but I'm not going to compound the error by making the same mistake >> again, pulling out tested, working code at the eleventh hour just >> because we all agree it probably isn't needed. > > that's the very definition of cargo cult :-) Not quite. "Cargo cult" is doing something that looks like what worked in the past, in the hopes of recreating that past success, and continuing to do so in the face of repeated failure. "Change management" is refraining from changing something that is demonstrably working in the present until and unless the new version can be shown to be demonstrably better by some objective metric. The first is what you get when "ought to" takes precedence over "does" (believing the planes will return, even when they don't); the second is what you get when "does" takes precedence over "ought to" (you can believe that a change ought to work fine, but you don't accept it until it can be shown that it does). -- Markus
-- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
