Ruby Issue Tracking System: Activity

ruby-trunk - Feature #7849: Symbol#to_str

2013-02-15T21:24:37+09:00

> You cannot gsub, enumerate characters in or alter encoding of a Symbol, so it is not a string representation.

That the official spec on the definition of a Stringy-thing? That's the "problem" with #to_str, #to_ary, etc. isn't it? There *is no* absolute interface that dictates their proper use. As long the method returns the expected type then its purely a question of *practicality*. And I submit that Symobol#to_str is about a practical as it gets.

And let me put it another way. If you inherited some code that relied on an object responding to #to_str to ensure it also responded to #gsub, #map and #force_encoding (which is the crux of your "definition"), what would you think? Yes, you'd have seriously fragile code on your hands and you'd be a'fixing it.

I think you rejected this issue far too prematurely. Do you guys even know the purpose of dialog?

ruby-trunk - Revision 39254: * ext/socket/sockport.h (SET_SIN_LEN): defined for strict-aliasing

2013-02-15T20:30:19+09:00

rule.
  (INIT_SOCKADDR_IN): ditto.

* ext/socket/raddrinfo.c (make_inetaddr): use INIT_SOCKADDR_IN.
  (addrinfo_ipv6_to_ipv4): ditto.

ruby-trunk - Bug #7101: 拡張ライブラリの質問

2013-02-15T20:22:03+09:00

--with-opt-dirを付けてもOS X (10.8)だと展開されませんでした。
問題のある当該マシンはFreeBSD 9.1なんですが、何が違うんだろう。もう少し調べます。

ruby-trunk - Bug #7101: 拡張ライブラリの質問

2013-02-15T20:19:22+09:00

そもそもrbconfig.rbのCFLAGSが

CONFIG["CFLAGS"] = "-O3 -fno-fast-math -ggdb3 -ansi -std=iso9899:199409  -fno-omit-frame-pointer -fPIC"

のように展開されてしまっているので、mkmf.rb以前の問題のようです。

切り分けを試みたところ、rubyのconfigureで --with-opt-dir="..." を指定すると $(cflags) が展開されてしまうようです。

るりまプロジェクト - Bug #7858 (Open): 拡張子指定無しのインプレイスモードは Windows 環境では使えない

2013-02-15T19:29:54+09:00

いろいろ調べてどういうことか見当が付いたのでパッチを書こうとしたらコメントに書いてあったわけですが、表示しておいて欲しいです。

もしかすると cygwin だと使えるとか有るかも知れませんが確認できないのでとりあえずコメントにならって [[c:Win32]] という表現でパッチを書いてみました。

ruby-trunk - Bug #7101: 拡張ライブラリの質問

2013-02-15T19:27:41+09:00

失礼、記憶違いでした。
添付の拡張ライブラリでもつかないはずですが、環境とwarnflagsの出力を教えて下さい。

ruby-trunk - Bug #7101: 拡張ライブラリの質問

2013-02-15T18:45:55+09:00

これは拡張ライブラリという言葉の使い方が不正確なんですが、付かなくしたのは外部のライブラリのときだけです。それとも、外部のライブラリのときでもまだ付いているなら、そのライブラリとmkmf.log、できたMakefile、以下の出力を教えて下さい。

$ ruby -e 'p RbConfig::CONFIG.values_at(*%w[warnflags strict_warnflags])'

ruby-trunk - Revision 39253: win32.c: style

2013-02-15T18:31:16+09:00

* win32/win32.c (rb_w32_fd_is_text): adjust style.

ruby-trunk - Revision 39252: mkmf.rb: fail if cross compiling

2013-02-15T18:24:50+09:00

* lib/mkmf.rb (MakeMakefile#try_run): bail out explicitly if cross
  compiling, because it cannot work of course.

ruby-trunk - Bug #7101 (Open): 拡張ライブラリの質問

2013-02-15T18:12:54+09:00

これって何がどう直ったんでしたっけ。

現在の trunk や ruby_2_0_0 では拡張ライブラリをビルドするときにも -ansi -std=iso9899:199409 が付くようです。

ruby-trunk - Bug #7758: Ruby on Windows crashes when active codepage is codepage 65001 and output...

2013-02-15T17:07:38+09:00

Seems nice.

ruby-trunk - Feature #7791: Let symbols be garbage collected

2013-02-15T17:05:04+09:00

My definition of complicating the life of the core team is undertaking projects that are likely to cause bugs.

That also complicates the life of everyone using Ruby.

Garbage collection only secures one part of the to_sym problem, that of the memory leak.  It does nothing to address detainting.  It does nothing to address random symbol creation.  Symbol[] provides a facility that can be used to guarantee this.

I can think of no improvement that GCing Symbols does that can not be matched by simply refusing to intern tainted strings.  Of course, that would expose a lot of brain-dead code.  It would also break a lot of acceptable code that is only acceptable because of the details of the environment in which it runs.

As for the proposal here, I have already pointed out, it is not enough to use the two different ways that symbols are created to partition the set of symbols for GC purposes.  You don't want to GC any method names of linked classes, and it doesn't matter how they were first accessed.  If the idea is to limit memory leakage, you DO want to GC method names of classes which are delinked.  Which makes a complete hash of the proposal to do a partial GC.

But a full GC destroys many of the advantages of having symbols in the first place.  Furthermore, it is going to impact performance in hard-to-predict ways.

Security is not optional.  But step 1 of security is to be bug free.  That means simple implementations where possible.  And Symbol[] provides a facility that addresses the memory leak completely without affecting core behaviour.  What it doesn't do is correct a lot of brain-dead behaviour favoured by the users of some web frameworks (which, in their defence, is actually encouraged by the developers of these frameworks).  I don't think it is the responsibility of the core team to try to protect people from being idiots.

ruby-trunk - Revision 39251: socket: ai_addrlen is socklen_t

2013-02-15T16:54:38+09:00

* ext/socket/raddrinfo.c (rsock_make_hostent): ai_addrlen is not
  size_t but socklen_t.

るりまプロジェクト - Feature #7857 (Open): Enumerable#lazy関係のドキュメントを書く

2013-02-15T15:53:19+09:00

Enumerable#lazyと、Enumerator::Lazyのドキュメントを書きます。

ruby-trunk - Feature #7791: Let symbols be garbage collected

2013-02-15T15:25:34+09:00

I don't think the goal is to simplify the life of ruby-core people.

I feel the goal is to have the best language possible be reasonably secure by default.

It would be sad if Ruby and its community suffered because of a reputation of insecurity, especially an insecurity by design that ruby-core won't address.

Maybe it will take a corporate sponsorship and a couple of weeks (months?) of full time work for someone to resolve the issue, but I don't see a fundamental reason why it couldn't be done.