[#66126] Creation/Conversion methods/functions table for Ruby types — SASADA Koichi <ko1@...>
Hi,
5 messages
2014/11/07
[#66248] [ruby-trunk - Feature #10423] [PATCH] opt_str_lit*: avoid literal string allocations — normalperson@...
Issue #10423 has been updated by Eric Wong.
3 messages
2014/11/13
[#66595] [ruby-trunk - Bug #10557] [Open] Block not given when the argument is a string — bartosz@...
Issue #10557 has been reported by Bartosz Kopinski.
3 messages
2014/11/30
[ruby-core:66410] [ruby-trunk - Feature #8543] rb_iseq_load
From:
normalperson@...
Date:
2014-11-22 08:28:27 UTC
List:
ruby-core #66410
Issue #8543 has been updated by Eric Wong.
billk@cts.com wrote:
> But ultimately, the result of the manual bisect was:
>
> 66d247bcb50a29769ff940100223544c125521aa is the first bad commit
> commit 66d247bcb50a29769ff940100223544c125521aa
> Author: ko1 <ko1@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>
> Date: Tue Apr 24 09:20:42 2012 +0000
>
> * compile.c: fix to output warning when the same literals
> are available as a condition of same case clause.
> And remove infomation ('#n') because we can find duplicated
> condition with explicit line numbers.
> [ruby-core:38343] [Ruby 1.9 - Bug #5068]
> * test/ruby/test_syntax.rb: add a test for above.
That was only one of the breakages :)
Things have bitrotted a lot over the years.
The following patch might be ready to commit to trunk:
http://80x24.org/spew/m/rb_iseq_load_fix@v1.txt
It's better than the complete breakage we have right now, so I might
commit the above in a few days. The new test case I added should
help (or force) other core committers to maintain iseq loading,
though.
There's no public API change in this version of my patch.
The test cases are probably not complete, though. I am mainly
interested in the feature because I'm working on another (in-core)
optimization which may utilize this.
I can definitely use some help thinking of better test cases since I
don't believe I remember all of Ruby syntax :x
----------------------------------------
Feature #8543: rb_iseq_load
https://bugs.ruby-lang.org/issues/8543#change-50047
* Author: Alexey Voskov
* Status: Open
* Priority: Low
* Assignee: Koichi Sasada
* Category: YARV
* Target version: current: 2.2.0
----------------------------------------
I noticed an unusual behaviour of undocumented rb_iseq_load function.
Its work differs in different Ruby versions. I'm trying to protect some Ruby
source code by its conversion to YARV p-code and using the next strategy:
1. Convert code to array
~~~ruby
data = RubyVM::InstructionSequence.compile_file('hello.rb').to_a
~~~
2. Pass a compiled source to the rb_iseq_load function and evaluate it
~~~ruby
iseq = iseq_load.(data)
iseq.eval
~~~
Sample programs are supplied in the attachments.
"hello.rb"
```ruby
puts "tralivali"
def funct(a,b)
a**b
end
3.times { |i|
puts "Hello, world#{funct(2,i)}!"
}
```
The differences
Ruby 1.9.3 (ruby 1.9.3p194 (2012-04-20) [i386-mingw32])
Correct work. Output:
```
tralivali
Hello, world1!
Hello, world2!
Hello, world4!
```
Ruby 2.0.0 (ruby 2.0.0p193 (2013-05-14) [x64-mingw32])
Incorrect work (omits the code inside code blocks). Output
```
tralivali
```
Attempts of loading bigger programs by means of rb_iseq_load in Ruby 2.0.0 usually ends with a segmentation fault.
Such behaviour also can be reproduced by means of iseq Ruby extension ("for iseq freaks")
https://github.com/wanabe/iseq
P.S. I understand that it is an undocumented feature.
---Files--------------------------------
hello.rb (102 Bytes)
rb_pack.rb (931 Bytes)
iseq-load-test3.rb (210 Bytes)
iseq-load-test3-file.rb (369 Bytes)
please-fix-rb_iseq_load-thank-you.pdf (444 KB)
--
https://bugs.ruby-lang.org/