[#90399] [Ruby trunk Feature#14813] [PATCH] gc.c: make gc_enter+gc_exit pairs dtrace probes, too — ko1@...
Issue #14813 has been updated by ko1 (Koichi Sasada).
3 messages
2018/12/10
[#90417] [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD — naruse@...
Issue #15398 has been reported by naruse (Yui NARUSE).
4 messages
2018/12/11
[#90423] Re: [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD
— Eric Wong <normalperson@...>
2018/12/11
[email protected] wrote:
[#90519] Spoofing warnings for mail from bugs.ruby-lang.org — Charles Oliver Nutter <headius@...>
I'm getting a spoofing warning for emails sent from bugs.ruby-lang.org when
4 messages
2018/12/13
[#90522] Re: Spoofing warnings for mail from bugs.ruby-lang.org
— Eric Wong <normalperson@...>
2018/12/13
Charles Oliver Nutter <[email protected]> wrote:
[#90533] [Ruby trunk Feature#15413] unmarkable C stack (3rd stack) — normalperson@...
Issue #15413 has been reported by normalperson (Eric Wong).
3 messages
2018/12/14
[#90581] [Ruby trunk Bug#15424] Ruby 2.6.0rc1 & 2.6.0rc2 mutex exception — mat999@...
Issue #15424 has been reported by splitice (Mathew Heard).
3 messages
2018/12/17
[#90595] [Ruby trunk Bug#15430] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been reported by hsbt (Hiroshi SHIBATA).
3 messages
2018/12/18
[#90614] [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been updated by hsbt (Hiroshi SHIBATA).
4 messages
2018/12/19
[#90630] Re: [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI
— Eric Wong <normalperson@...>
2018/12/20
> It still exists. https://rubyci.org/logs/rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181218T230003Z.fail.html.gz
[#90820] Re: [ruby-cvs:73697] k0kubun:r66593 (trunk): accept_nonblock_spec.rb: skip spurious failure — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/12/30
[ruby-core:90791] Re: [Ruby trunk Bug#15478] [RFC] erb: remove deprecation warnings from ERB.new
From:
Eric Wong <normalperson@...>
Date:
2018-12-29 06:44:19 UTC
List:
ruby-core #90791
[email protected] wrote: > Issue #15478 has been updated by k0kubun (Takashi Kokubun). > > > > nil and 0 $SAFE is already no-op, already, right? I don't care about $SAFE, so I would expect people will pass nil or 0 when they don't care (because they need to pass the other legacy variables). > > > > > Note that we already showed this deprecation warning on warnlevel == 2 on Ruby 2.6. > > > > Yeah, so if $SAFE already warns, I don't think ERB should also need to warn. > I think you misunderstand that we're warning here only for > $SAFE deprecation. Once $SAFE is eliminated, why would we > leave the second argument for setting safe_level? Leave it as a placeholder for compatibility. > The purpose of this warning is to eliminate the second argument of > ERB.new. Passing nil and 0 will be harmful when the argument > does not exist anymore. Why would safe_level=(0|nil) ever be harmful? It's the default security level and it'll be the same when $SAFE is eliminated. Warning on safe_level=(1|2|etc) I can understand. > Also note that I actually meant that it's fine to combine > multiple warnings to one line by "Stop showing warnings for > legacy_trim_mode and legacy_eoutvar is fine", and still the > third/fourth arguments are expected to go away. No, removing any args is a bad idea because it screws up existing users and my main point. I understand $SAFE removal since it's fake security and already broken. But it's OK to ignore 0/nil. > > I hit this at: > > https://80x24.org/olddoc.git/tree/lib/oldweb.rb?h=v1.5.1#n272 > > Thanks. Shall I send a patch to fix it? Thanks, but I already had a dirty patch which I just pushed out (connection still flaky). https://80x24.org/olddoc-public/[email protected]/ > > Most code repositories are NOT public; and we can never know > > all or even most of them. By now, I believe deprecating > > existing/stable APIs gracefully in scripting languages is > > impossible without either making users angry or wasting > > their time with churn. > > I get your point. I actually faced this by myself at my > company's private code. > > At the same time, it should be only acceptable on a major > version upgrade as long as we provide a way to gracefully > migrate from old interface to new interface and notify users > gradually. Starting from warn level 2 in Ruby 2.6, decreasing > it to 1 in Ruby 2.7, and changing the behavior on Ruby 3.0 > should be fine in that sense. Why change existing behavior at all? We can support both old and new-style kwargs without much overhead. There needs to be no breaking changes for most users, no breaking changes for Ruby 3, none for 4, etc. And 3 years deprecation is way too fast for users on LTS systems. > > If anything, such warning should go to syslog (or an out-of-the-way OS-level logging mechanism). Stderr is too annoying to ordinary users (not programmers). > > I agree that non programmers wouldn't see syslog and it would not annoy them. But do you think programmers always see syslog when they execute Ruby? I don't think so because I only see it when something strange happens. > I believe annoying users by suggesting to fix the usage first > is far better than immediately breaking it at some point with > just ArgumentError which has almost no clue to fix it > immediately. Of course we never break anything immediately. We don't need to change or break 99% of ERB use cases which never change $SAFE. Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>