[#72745] [Ruby trunk - Misc #11876] [Closed] Scheduled maintenance 2016/01/01 — shibata.hiroshi@...
Issue #11876 has been updated by Hiroshi SHIBATA.
4 messages
2016/01/07
[#72746] Re: [Ruby trunk - Misc #11876] [Closed] Scheduled maintenance 2016/01/01
— Eric Wong <normalperson@...>
2016/01/07
shibata.hiroshi@gmail.com wrote:
[#72824] [Ruby trunk - Bug #11973] IO#advise should raise NotImplementedError on platforms that do not support that call — git@...
Issue #11973 has been updated by Chuck Remes.
3 messages
2016/01/12
[#72954] [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each — naruse@...
Issue #12010 has been reported by Yui NARUSE.
4 messages
2016/01/20
[#72959] Re: [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each
— Eric Wong <normalperson@...>
2016/01/20
naruse@airemix.jp wrote:
[#73313] [Ruby trunk - Bug #12007] [Open] Newly added Unicode data file doesn't get downloaded — shugo@...
Issue #12007 has been updated by Shugo Maeda.
3 messages
2016/01/23
[#73372] [Ruby trunk - Misc #12004] Code of Conduct — benton@...
Issue #12004 has been updated by Benton Barnett.
4 messages
2016/01/24
[#73379] Re: [Ruby trunk - Misc #12004] Code of Conduct
— KOSAKI Motohiro <kosaki.motohiro@...>
2016/01/24
On Sun, Jan 24, 2016 at 5:13 PM, <benton@bentonbarnett.com> wrote:
[#73421] [Ruby trunk - Misc #12004] Code of Conduct — nekocat432@...
Issue #12004 has been updated by Ruby Dino.
6 messages
2016/01/25
[#73425] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Austin Ziegler <halostatue@...>
2016/01/25
I’m sorry, but this, like the code of merit, is merely a derailing tactic.
[#73469] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Martin J. Dürst <duerst@...>
2016/01/26
On 2016/01/26 01:32, Austin Ziegler wrote:
[#73482] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Austin Ziegler <halostatue@...>
2016/01/26
On Tue, Jan 26, 2016 at 12:25 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp>
[#73491] [Ruby trunk - Misc #12004] Code of Conduct — git@...
Issue #12004 has been updated by Chuck Remes.
7 messages
2016/01/26
[#73492] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Andrew Kirilenko <andrew.kirilenko@...>
2016/01/26
They will never provide any numbers because they are not engineers and they
[#73494] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Brandon Weaver <keystonelemur@...>
2016/01/26
Coraline is a panelist on Ruby rogues and a very well respected member of
[#73498] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Andrew Kirilenko <andrew.kirilenko@...>
2016/01/26
OK, sorry for previous comment. Let's try this way.
[#73500] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Austin Ziegler <halostatue@...>
2016/01/26
On Tue, Jan 26, 2016 at 5:15 PM, Andrew Kirilenko <
[#73558] [Ruby trunk - Misc #12004] Code of Conduct — andrew.kirilenko@...
Issue #12004 has been updated by Andrew Kirilenko.
5 messages
2016/01/28
[#73568] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Austin Ziegler <halostatue@...>
2016/01/29
Andrew, please stop digging. Your hole is only getting deeper.
[#73573] Re: [Ruby trunk - Misc #12004] Code of Conduct
— Andrew Kirilenko <andrew.kirilenko@...>
2016/01/29
>Andrew, please stop digging. Your hole is only getting deeper.
[#73586] [Ruby trunk - Misc #12004] Code of Conduct — andrew@...
Issue #12004 has been updated by Andrew Vit.
4 messages
2016/01/29
[#73593] [Ruby trunk - Bug #12034] RegExp does not respect file encoding directive — nobu@...
Issue #12034 has been updated by Nobuyoshi Nakada.
3 messages
2016/01/30
[ruby-core:72676] [Ruby trunk - Feature #11934] A feature to drop dynamics dynamically
From:
shevegen@...
Date:
2016-01-03 04:05:52 UTC
List:
ruby-core #72676
Issue #11934 has been updated by Robert A. Heiler.
It would be nice to fine-tune some of ruby's behaviour like that.
So I am encouraging all ideas similar as to the above.
There is only one concern I have - is it possible to become
"less" strict again that is, to revert to the default MRI
behaviour?
RubyVM.drop_dynamics
RubyVM.enable_dynamics
Also I am not sure if RubyVM is a good namespace for this,
perhaps this is more RbConfig or some other name? But the
name is not so important, the functionality is more important,
the name can easily be decided. Deciding on functionality
is more difficult.
Thanks for reading!
----------------------------------------
Feature #11934: A feature to drop dynamics dynamically
https://bugs.ruby-lang.org/issues/11934#change-55926
* Author: Yusuke Endoh
* Status: Feedback
* Priority: Normal
* Assignee:
----------------------------------------
Ruby is a dynamic language. Everything is possible in runtime.
So, how about a feature to prohibit some dynamic features in runtime?
~~~~
Foo = 1
RubyVM.drop_dynamics
Bar = 2 #=> cannot define new constant
Foo = 2 #=> cannot redefine a constant
def foo; end #=> cannot define a method
class Baz; end #=> cannot create a new class
~~~~
Ruby's dynamic property greatly restricts performance. However, it is a bad idea to limit Ruby's dynamics. It is Ruby's identity, and is actually useful in some aspects such as debugging, daily-scripting, research, hobby-use, etc.
That being said, when a program is in production, we don't necessarily use the dynamic features at any time during execution. Typically, they are used only in initialization of application, such as eval-for-DRY and monkey patching. After the initialization is done, we can drop (some of) dynamic features in some situations.
Currently, when considering optimization of Ruby implementation, we (the core-team) must always care the possibility of redefinition of any built-in methods. That is not sound. This proposal gives us a "normal" condition for considering optimization. We can easily apply a lot of optimizations, like constant folding and method inline expansion. In addition, some advanced analyses like JIT/AOT compilation, type inference and whole program optimization will be applicable much more effectively.
--
It is arguable what features are prohibited. IMO, it is relatively easy to drop the following features.
* (re)definition of constants
* (re)definition of methods (including singleton methods an aliases)
* (re)definition of classes/modules
* inclusion of modules
Aggressively, we may limit the following features.
* destructive modification of some kind of objects (such as making string literal frozen by default)
* some meta-programming features like `Object#send`
* `eval` and `instance_eval`
* addition of instance variables
* XXX <- feel free to add your unfavorite features
We should care about a trade-off between compatibility impact and optimization effect.
--
I'm half-joking, but half-serious. I'm unsure if this is really a great idea, but surely better than just restricting Ruby specification by default (such as frozen string literal). This may be a key feature towards Ruby3x3.
What do you think?
--
Yusuke Endoh <mame@ruby-lang.org>
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>