[#84280] [Ruby trunk Bug#14181] hangs or deadlocks from waitpid, threads, and trapping SIGCHLD — nobu@...
Issue #14181 has been updated by nobu (Nobuyoshi Nakada).
3 messages
2017/12/15
[#84398] [Ruby trunk Bug#14220] WEBrick changes - failures on MSWIN, MinGW — Greg.mpls@...
Issue #14220 has been reported by MSP-Greg (Greg L).
3 messages
2017/12/22
[#84472] Re: [ruby-dev:50394] [Ruby trunk Bug#14240] warn four special variables: $; $, $/ $\ — Eric Wong <normalperson@...>
Shouldn't English posts be on ruby-core instead of ruby-dev?
3 messages
2017/12/26
[ruby-core:84506] Re: [Ruby trunk Bug#14246] Inconsistent C source code indentation
From:
Eric Wong <normalperson@...>
Date:
2017-12-27 10:54:27 UTC
List:
ruby-core #84506
duerst@it.aoyama.ac.jp wrote: > I'm all for better consistency. I thought there were clear > guidelines for Ruby, and (almost) everybody was following > them. I didn't know it was that bad. Right, I remember it being 4 spaces per-level, and use TAB whenever it's 8 spaces. AFAIK, that's the Emacs default and I've seen this in several other projects, so not uncommon.. In vim, I use: :set ts=8 sw=4 sts=4 noexpandtab > But fixing spacing will obscure where the code originally came > from. I don't really like that. Agreed 100%. Noise makes code archaelogy harder, I don't like whitespace-only changes; but I'd be happy to see them if one is in the affected area and already changing code, and the proposed SVN bot might help with that... I admit that I moved some existing all-space code not long ago and did not notice it, but nobu fixed it for me :x > To improve the situation, I have the following suggestions: > 1) Install an SVN bot that fixes indents on newly committed > lines automatically. That would hopefully catch the attention > of the committers. Instead of auto-fixing, it should email the committer; that ought to reduce future screwups. Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>