Ruby Issue Tracking System: Issueshttps://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112016-05-09T15:23:51ZRuby Issue Tracking System
Redmine Ruby master - Feature #12360 (Rejected): More useful return values from bang methodshttps://bugs.ruby-lang.org/issues/123602016-05-09T15:23:51Ztrans (Thomas Sawyer)
<p>It would be nice if bang methods returned results that where of some additional use. Presently most just return the effected receiver.</p>
<p>For example, currently Array#reject! works as follows:</p>
<pre><code>a = [1,2,3,4]
a.reject!{ |x| x % 2 == 0 }
=> [2,4]
a
=> [2,4]
</code></pre>
<p>So the return value of #reject! is useless b/c it is just the same as <code>a</code> (in this example). So why not return what was rejected instead:</p>
<pre><code>a = [1,2,3,4]
a.reject!{ |x| x % 2 == 0 }
=> [1,3]
a
=> [2,4]
</code></pre>
<p>Now we have useful additional information -- we know exactly what got rejected. To do the same thing presently we would have to fully duplicate the original array and then take the difference -- two extra steps.</p>
<p>The downside is that the method would consume a little more memory and probably slow the method's execution a little too. But I tend to side with functionality when I use Ruby.</p> Ruby master - Bug #10929 (Rejected): NilClass#to_proc and & don't mix?https://bugs.ruby-lang.org/issues/109292015-03-02T23:43:42Ztrans (Thomas Sawyer)
<p>This is sort of like a "who would ever care" kind of bug. Nonetheless technically it seems like it is one. So I thought it best that I report it just the same.</p>
<pre><code> class NilClass
def to_proc
Proc.new{ |*x| nil }
end
end
def f(&b)
b.call(1)
end
f(&nil)
=> NoMethodError: undefined method `call' for nil:NilClass
</code></pre>
<p>(Maybe it was fixed already. Filing out this issue reminded me I need to update my version of Ruby.)</p> Ruby master - Bug #10924 (Closed): String#bhttps://bugs.ruby-lang.org/issues/109242015-03-02T01:27:32Ztrans (Thomas Sawyer)
<p>Well, I just learned about the String#b <a href="http://ruby-doc.org/core-2.1.0/String.html#methodi-b" class="external">method</a> today. And of course it breaks the <a href="https://github.com/rubyworks/radix" class="external">Radix</a> gem :-( Honestly, back when I create Radix in 2009 I could not have imagined a safer bet than <code>#b</code> for an extension if I tried. And yet sure enough, Ruby makes <code>String#b</code> an official method for converting to ASCII 8-bit. Is it really such a popular method to get such a short name? I mean <code>String#ascii</code> wouldn't have been a better choice? To go along with <code>#ascii_only</code>?</p>
<p>Okay, so much for my mini-rant. So bottom line, can I ask that this method not be called <code>#b</code>? Even putting the conflict with Radix aside, I think it's a pretty bad name for a standard Ruby method. Just read it: "#b". Do you have any idea what that does without looking it up in the documentation? Nope, no way.</p>
<p>(P.S. Bug or feature, not sure what to label it. Left it a bug b/c it did <a href="https://github.com/rubyworks/radix/issues/10" class="external">break people's code</a>.)</p> Ruby master - Feature #9704 (Open): Refinements as files instead of moduleshttps://bugs.ruby-lang.org/issues/97042014-04-04T20:41:06Ztrans (Thomas Sawyer)
<p>If refinements are to remain file-scoped, then it would be more convenient if <code>using</code> worked at the file level, akin to <code>require</code>, rather than behave like a module <code>include</code>. For instance, instead of:</p>
<pre><code># foo.rb
module Foo
refine String do
def some_method
...
end
end
end
</code></pre>
<pre><code>require 'foo'
using Foo
</code></pre>
<p>We could do:</p>
<pre><code># foo.rb
class String
def some_method
...
end
end
</code></pre>
<pre><code>using 'foo'
</code></pre>
<p>This would make <code>require</code> and <code>using</code>, in a certain sense, <em>polymorphic</em> --if we <code>require</code> it will extend the classes directly, but if <code>using</code> then they will be refined instead.</p> Ruby master - Feature #9696 (Rejected): More Flexible Refinement Syntaxhttps://bugs.ruby-lang.org/issues/96962014-04-03T03:21:55Ztrans (Thomas Sawyer)
<p>I am the maintainer of Ruby Facets, the core extensions library. For the next release of Facets I have long planned to provide support for Refinements. Unfortunately, after working with the code to determine what would be necessary to support them, I've come to the conclusion that it's just not reasonable to do so. The problem lies in the fact that Facets must still be backward compatible with it's "monkey-patch" usage. In fact, that usage is sometimes preferable b/c you can require once and don't have to write <code>using Foo</code> in every file that a core extension might be needed. But, b/c of the syntax that refinements use, to support both patching and refining I would have to maintain TWO COPIES of every extension, which simply isn't practical.</p>
<p>For example, the normal definition of a String#foo:</p>
<pre><code>class String
def foo
...
end
end
</code></pre>
<p>And the refinement:</p>
<pre><code>module Facets
refine String do
def foo
...
end
end
end
</code></pre>
<p>There does not appear to be any reasonable way to have the definition defined once and still be able to be use it in either manner. (Also, I want to point out that refinements do not lend themselves to cherry picking specific methods per-file either.)</p>
<p>So, unless someone has a clever approach that I have not thought of, I wonder if it would not be a good idea to reconsider the syntax of refinements. Would it be possible to simplify the definition to use <code>class</code> instead of <code>refine</code>, e.g.</p>
<pre><code>module Facets
class String
def foo
...
end
end
end
</code></pre>
<p>And then allow <code>using Facets</code> which would refine any common class is the scope. And further, allowing also <code>using Facets::String</code> and even <code>using Facets::String::foo</code> to cherry pick refinements? In addition, a way to "apply" a module as if it were evaluated in the scope. This would then allow the same code to be used either as a refinement or as an extension.</p>
<p>Alternatively, maybe refinements should just be a require --if they will forever remain at the file-level. Then no special syntax would be needed at all. Simply defining them in a separate file, e.g.</p>
<pre><code># string/foo.rb
class String
def foo
...
end
end
</code></pre>
<p>And then "using" them by file name instead would do the trick.</p>
<pre><code>using 'string/foo'
</code></pre> Ruby master - Feature #8820 (Closed): Speed up Array#indexhttps://bugs.ruby-lang.org/issues/88202013-08-27T02:31:36Ztrans (Thomas Sawyer)
<p>I did a quick comparison:</p>
<p>In Ruby</p>
<pre><code>def main
n = 10000000 # ten million
a = randPerm(100)
t0 = Time.now
n.times do |i|
a.index(i)
end
puts "%.5f" % [Time.now - t0]
end
def randPerm(n)
(0...n).sort_by{rand}
end
main()
</code></pre>
<p>In Go</p>
<pre><code>package main
import (
"fmt"
"time"
"math/rand"
)
func main() {
n := 10000000 // ten million
a := rand.Perm(100)
t0 := time.Now()
for i := 0; i < n; i++ {
index(a, i)
}
fmt.Printf("%.5f\n", time.Now().Sub(t0).Seconds())
}
func index(slice []int, value int) int {
for i, v := range slice {
if (v == value) {
return i
}
}
return -1
}
</code></pre>
<p>The result</p>
<p>Ruby: 71.08961 secs<br>
Go: 2.61975 secs</p>
<p>That's pretty huge difference (and worse I was told my Go index function was "crazily inefficient" too, though personally I don't see how it can be any better). So, I thought I'd mention it. Maybe it would be possible to speed up.</p> Ruby master - Feature #8807 (Open): Custom literalshttps://bugs.ruby-lang.org/issues/88072013-08-21T18:20:52Ztrans (Thomas Sawyer)
<p>So why can't we define custom literals? There's been recent discussion about adding a new freeze literal. Would have been nice if coders could have defined it for themselves, then it would have been more clear if there really was enough use to add it to core.</p>
<p>I imagine the syntax of such a feature to be quite simple.</p>
<p>def %foo(string, mod=nil)<br>
p [string, mod]<br>
end</p>
<p>%foo{something}o<br>
=> ["something", "o"]</p> Ruby master - Feature #8772 (Open): Hash alias #| merge, and the case for Hash and Array polymorp...https://bugs.ruby-lang.org/issues/87722013-08-11T11:46:03Ztrans (Thomas Sawyer)
<p>Ideally Hash and Array would be completely polymorphic in every manner in which it is possible for them to be so. The reason for this is very simple. It makes a programmer's life easier. For example, in a recent program I was working on, I had a list of keyboard layouts.</p>
<p>layouts = [layout1, layout2, layout3]</p>
<p>Later I realized I wanted to identify them by a label not an index. So...</p>
<p>layouts = {:foo => layout1, :bar => layout2, :baz => layout3}</p>
<p>Unfortunately this broke my program in a number of places, and I had to go through every use of <code>layouts</code> to translate what was an Array call into a Hash call. If Array and and Hash were more polymorphic I would have only had to adjust the places were I wanted to take advantage of the Hash. Ideally almost nothing should have actually broken.</p>
<p>The achieve optimal polymorphism between Hash and Array is to treat a Hash's keys as indexes and its values as as the values of an array. e.g.</p>
<p>a = [:a,:b,:c]<br>
h = {0=>:a,1=>:b,2=>:c}<br>
a.to_a #=> [:a,:b,:c]<br>
h.to_a #=> [:a,:b,:c]</p>
<p>Of course the ship has already sailed for some methods that are not polymorphic, in particular #each. Nonetheless it would still be wise to try to maximize the polymorphism going forward. (Perhaps even to be willing to take a bold leap in Ruby 3.0 to break some backward compatibility to improve upon this.)</p>
<p>In the mean time, let us consider what it might mean for Hash#+ as an alias for #merge, <em>if the above were so</em>:</p>
<p>([:a,:b] + [:c,:d]).to_a => [:a,:b,:c,:d]<br>
({0=>:a,1=>:b} + {2=>:c,3=>:d}).to_a => [:a,:b,:c,:d]</p>
<p>([:a,:b] + [:a,:b]).to_a => [:a,:b,:a,:b]<br>
({0=>:a,1=>:b} + {0=>:a,1=>:b}).to_a => [:a,:b]</p>
<p>Damn! So it appears that #+ isn't the right operator. Let's try #| instead.</p>
<p>([:a,:b] | [:c,:d]).to_a => [:a,:b,:c,:d]<br>
({0=>:a,1=>:b} | {2=>:c,3=>:d}).to_a => [:a,:b,:c,:d]</p>
<p>([:a,:b] | [:a,:b]).to_a => [:a,:b]<br>
({0=>:a,1=>:b} | {0=>:a,1=>:b}).to_a => [:a,:b]</p>
<p>Bingo. So I formally stand corrected. The best alias for merge is #| not #+.</p>
<p>Based on this line of reasoning I formally request the Hash#| be an alias of Hash#merge.</p>
<p>P.S. Albeit, given the current state of polymorphism between Ruby's Array and Hash, and the fact that it will probably never be improved upon, I doubt it really matters which operator is actually used.</p> Ruby master - Feature #8111 (Closed): Redmine Manager?https://bugs.ruby-lang.org/issues/81112013-03-18T20:18:26Ztrans (Thomas Sawyer)
<p>How/Who do you contact for Redmine management issues?</p> Ruby master - Feature #7986 (Feedback): Custom case statement comparison methodhttps://bugs.ruby-lang.org/issues/79862013-02-28T22:09:11Ztrans (Thomas Sawyer)
<p>=begin<br>
Case statements use #=== to handle matching, but sometimes this can be limiting. It such cases it would be helpful to be able to specify the comparison method. So I wondered if that could be done by hanging the method off the <code>case</code> keyword, e.g.</p>
<pre><code>class Bar < Foo; end
case == obj.class
when Foo
p "Foo, not Bar!"
when Bar
p "Bar!"
end
</code></pre>
<p>And</p>
<pre><code>case.include? name
when a
p "a includes name"
when b
p "b includes name, not a"
else
p "neither a or b includes name"
end
</code></pre>
<p>=end</p> Ruby master - Feature #7914 (Open): Case for local class methodshttps://bugs.ruby-lang.org/issues/79142013-02-23T00:13:20Ztrans (Thomas Sawyer)
<p>=begin<br>
Here is a use case for local class methods.</p>
<p>Say we wish to give certain classes and all subclasses a special name.</p>
<p>class X<br>
def self.special_name<br>
"special:#{name}"<br>
end<br>
end<br>
class Y < X; end<br>
class Z < Y; end</p>
<p>Z.special_name #=> "special:Z"</p>
<p>But what if Y has a unique special name?</p>
<p>class Y < X<br>
def special_name<br>
'unique:Y'<br>
end<br>
end</p>
<p>Problem that arises:</p>
<pre><code>Z.special_name #=> "unique:Y" # wrong!
</code></pre>
<p>Currently, to solve this would require creating an additional method, e.g. <code>unique_name</code> and redefine <code>special_name</code> to first look for unique_name then fallback to default special name if non-found. It works, but adds additional complexity to API.</p>
<p>Nicer solution would be local class methods.</p>
<pre><code>class Y < X
def special_name
'unique:Y'
end
local :special_name
end
Y.special_name #=> "unique:Y"
Z.special_name #=> "special:Z"
</code></pre>
<p>The idea being that local class methods are skipped in super/lookup chain.</p>
<p>This idea is not without precedence. Module class methods can be thought of as being local. So this idea has other side of the notion, that modules could have class methods that are not skipped over in the super/lookup chain. In that case we would need a term that means opposite of local, so I'll use <code>nonlocal</code>:</p>
<pre><code>module M
def self.q; "q"; end
nonlocal :q
end
class X
include M
end
X.q #=> "q"
</code></pre>
<p>=end</p> Ruby master - Feature #7907 (Rejected): Give meaning to staby wordhttps://bugs.ruby-lang.org/issues/79072013-02-22T03:06:50Ztrans (Thomas Sawyer)
<p>=begin<br>
I noticed that <code>->word</code> doesn't mean anything. i.e.</p>
<blockquote>
<blockquote>
<p>->foo<br>
SyntaxError: (irb):4: syntax error, unexpected '\n', expecting keyword_do_LAMBDA or tLAMBEG<br>
from /opt/Ruby/1.9.3-p327/bin/irb:12:in `'</p>
</blockquote>
</blockquote>
<p>If that is always so, then could it be given a meaning as a shorthand for method()? i.e.</p>
<p>->foo</p>
<p>would be the same as writing</p>
<p>method(:foo).to_proc</p>
<p>=end</p> Ruby master - Feature #7906 (Rejected): Giving meaning to ->foo https://bugs.ruby-lang.org/issues/79062013-02-22T03:05:09Ztrans (Thomas Sawyer)
<p>=begin<br>
I noticed that "(({->word}))" doesn't mean anything. i.e.</p>
<blockquote>
<blockquote>
<p>->foo<br>
SyntaxError: (irb):4: syntax error, unexpected '\n', expecting keyword_do_LAMBDA or tLAMBEG<br>
from /opt/Ruby/1.9.3-p327/bin/irb:12:in `'</p>
</blockquote>
</blockquote>
<p>If that is always so, then could it be given a meaning as a shorthand for (({method()}))? i.e.</p>
<p>->foo</p>
<p>would be the same as writing</p>
<p>method(:foo).to_proc</p>
<p>=end</p> Ruby master - Feature #7849 (Rejected): Symbol#to_strhttps://bugs.ruby-lang.org/issues/78492013-02-14T04:46:00Ztrans (Thomas Sawyer)
<p>Even though a Symbol is not technically an honest-to-goodness String, from the standpoint of simple practicality it would help to have Symbol#to_str defined.</p>
<p>There are times when we want an argument to accept a String or a Symbol, but don't really want it to accept any type of object under the sun that responds to #to_s --which is just about anything. This is especially the case when writing DSLs. Having Symbol#to_str is the nice solution to this.</p>
<p>Defining Symbol#to_str may be an exception to the rule, but it's one worth making.</p> Ruby master - Feature #7788 (Open): YAML Tag Schema Supporthttps://bugs.ruby-lang.org/issues/77882013-02-06T05:05:55Ztrans (Thomas Sawyer)
<p>=begin<br>
I have endeavoured to add proper Schema support to Psych (see ((<YAML Spec|URL:<a href="http://www.yaml.org/spec/1.2/spec.html#Schema%3E" class="external">http://www.yaml.org/spec/1.2/spec.html#Schema></a>)) on Schemas). The primary reasons for supporting schemas are two fold: security and global tag conflict. The first is well known b/c of recent events. The second is less realized, but consider is it same problem as using global variables. Different apps have different tags; two identical local tags may have different meanings and thus cause conflict.</p>
<p>The API works like this:</p>
<pre><code>class Foo
end
foo_schema = YAML::Schema.new do |s|
s.tag '!foo', Foo
end
YAML.load('foo.yml', :schema=>foo_schema)
</code></pre>
<p>This code would allow only failsafe and json schema tags (core defaults), plus the specifically defined !foo tag.<br>
Also, %TAG prefix is supported:</p>
<pre><code>foo_schema = YAML::Schema.new(:prefix=>{'!'=>'tag:foo.org/'}) do |s|
s.tag '!foo', Foo
end
</code></pre>
<p>This will add tag 'tag:foo.org/foo<code>instead of local</code>!foo` tag.</p>
<p>To properly support schema, object's must store the tag with which they were loaded in order to ensure correct round tripping. For this there is <code>tag_uri</code> attribute.<br>
(Note: I am not sure if it best to store as instance variable, which it currently is, or to store in global table. Need feedback.)</p>
<p>In the process of adding schema support I was able to clean up and generalize loading code. For immutable types and class factories, adding (({ClassName.new_with(coder)})) can be used to instantiate class.</p>
<p>Implementation is close to complete, I believe this is all that remains:</p>
<ol>
<li>ScalarScanner needs to respect schema (basically if failsafe and/or json schemas are not used).</li>
<li>Dumping needs to take :schema option to limit it to schema tags.</li>
<li>Dumping needs to look to tag_uri for tag by default.</li>
<li>There is one bug I have yet to figure out (test_spec_builtin_map).</li>
<li>I have questions about Coder, b/c it seems more complex than it needs to be.</li>
</ol>
<p>I am also considering refactoring Schemas as modules that can be included into other schema. Currently they are classes/objects that can be subclassed or merged via <code>+</code>, e.g.</p>
<pre><code>LEGACY_SCHEMA = CORE_SCHEMA + RUBY_SCHEMA + OBJECT_SCHEMA + SYCK_SCHEMA
</code></pre>
<p>Of course, as with any new code, there's sure to be corner cases to work out. Having other pound on it for a while would be very helpful. Oh, and I should also mention I am documenting as much of the code as can.</p>
<p>Feel free to ask me any questions for more details about the code. You can find the branch here: <a href="https://github.com/trans/psych/tree/isotag" class="external">https://github.com/trans/psych/tree/isotag</a><br>
=end</p> Ruby master - Bug #7782 (Closed): Struct both has and does not have an allocatorhttps://bugs.ruby-lang.org/issues/77822013-02-05T01:33:07Ztrans (Thomas Sawyer)
<p>=begin<br>
One the one hand:</p>
<pre><code>>> Struct.allocate
TypeError: allocator undefined for Struct
from (irb):1:in `allocate'
from (irb):1
from /opt/Ruby/1.9.3-p327/bin/irb:12:in `<main>'
</code></pre>
<p>But on the other:</p>
<pre><code>>> Struct.method(:allocate)
=> #<Method: Class#allocate>
</code></pre>
<p>In my current case, I need a reliable way to check if a class can be allocated or not. How can one do this if the method is remains present even when it can not be used?<br>
=end</p> Ruby master - Feature #7748 (Open): Contextual sendhttps://bugs.ruby-lang.org/issues/77482013-01-28T16:11:40Ztrans (Thomas Sawyer)
<p>=begin<br>
If I write a method that uses #send vs. #public_send, I am making an assumption about how that method is invoked. For example, take the simplest form of such a method:</p>
<p>class String<br>
def send_out(op, *a, &b)<br>
send(op, *a, &b)<br>
end<br>
end</p>
<p>This code has a bug in it, in the sense that it can be used to call private string methods. The solution is to use #public_send. In most cases that will be fine. But if anyone tries to reuse the method while extending String themselves, e.g.</p>
<p>class String<br>
def send_out(op, *a, &b)<br>
public_send(op, *a, &b)<br>
end</p>
<pre><code>def some_public_method
send_out(:some_private_method)
end
private
def some_private_method
end
</code></pre>
<p>end</p>
<p>Then it will be a problem b/c it cannot be used on a private supporting method.</p>
<p>So it seems like there should be something like a ((<em>contextual send</em>)) which invokes a send with the same visibility as the parent method is invoked. e.g.</p>
<p>class String<br>
def send_out(op, *a, &b)<br>
contextual_send(op, *a, &b)<br>
end<br>
end</p>
<p>And then all cases will work as expected.<br>
=end</p> Ruby master - Bug #7716 (Closed): Readdressing Autoloadhttps://bugs.ruby-lang.org/issues/77162013-01-19T05:03:00Ztrans (Thomas Sawyer)
<p>=begin<br>
It has been known for a long time that Autoload does not utilize the normal require method, and thus is unaffected when require is overridden. This makes it impossible to fully implement a custom load system. Obviously, customizing the load system is a fairly rare usecase and thus a low priority. But it can and does occur. The most notable example is RubyGems itself. Without the ability to customize the load system, RubyGems would have been much more difficult, if not impossible, to create. It can be thankful that its particular design does not suffer greatly from the "autoload hole", nonetheless it does have a reported bug b/c of it, <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: autoload Can't Require Gems (Closed)" href="https://bugs.ruby-lang.org/issues/4233">#4233</a>. I too have a custom load system that I have been using in a development setting for many years. I use it to simplify vendoring between dependent projects. I would have liked to made public releases of the project, but the autoload issue has always been too much of a show-stopper to make it generally usable.</p>
<p>This issue with autoload has been reported since at least as far back as October 2007. That's over 5 years ago. Over these years, I have asked many times that this issue be addressed and why I needed it addressed. It has been very frustrating to watch this issue languish, year after year, going unresolved. I understand low priority issues, but 5 years!? Finally, just ((<em>over a year ago</em>)) Matz declared that "autoload will be dead" in issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead) (Closed)" href="https://bugs.ruby-lang.org/issues/5653">#5653</a>. "Well", I thought at the time, "that's one way to fix it". While I still wished autoload would actually be fixed, at least I could rest assured that in due course the problem would dissipate as new releases of projects are made deprecating their use of autoload.</p>
<p>In the last few days, I have asked a number of notable projects, including Bundler and RubyGems (a standard library mind you!) when we might expect autoload to be removed from their code. After all it's already been over a year since Matz' declaration. But, in all cases, they reported that they had no intentions of removing autoload in the foreseeable future. So much for strong discouragements from our benevolent dictator.</p>
<p>This week I revisited my custom load manager and re-factored the code a great deal. I'm very happy with the new code and think that it's about as good as it's going to get (minor improvements aside). I suppose I can at least be happy that I've had all this time to think about and improve my code. That's good. But at this point I'd would really like to release it all proper-like.</p>
<p>So... since this autoload issue was obviously still not going anywhere, I took it upon myself to fix. Mind you, I am not a C programmer and this is basically right at the limits of my ability to do anything with Ruby's C code. But, I was able to wrangle out how to make a fix and now offer it up here with an enclosed patch. The patch simply adds a Kernel singleton method called #require_autoload which can be overridden to customize it's operation. The patch includes a test to ensure it works. Perhaps there is some preference to handle this differenetly. That's fine, please adjust it as seen fit. But please <em>do something</em>! This issue has gone unaddressed long enough. And really, it is only a small bit of code. I ask, and pray, we will see this fix make it into the next release of 2.0 and back-ported tho 1.9. Please.<br>
=end</p> Ruby master - Feature #7711 (Rejected): RubyGems uses autoloadhttps://bugs.ruby-lang.org/issues/77112013-01-18T04:43:52Ztrans (Thomas Sawyer)
<p>Using a custom require method, I ran into an issue with RubyGems b/c it is using autoload:</p>
<p><a href="https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L1062-L1074" class="external">https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L1062-L1074</a></p>
<p>Seeing that autoload is now discouraged from standard libs (<a href="http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/41149" class="external">http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/41149</a>), when might we see it removed?</p> Ruby master - Bug #7695 (Closed): Constant Lookup - For goodness sake it should at least see itself!https://bugs.ruby-lang.org/issues/76952013-01-15T04:17:25Ztrans (Thomas Sawyer)
<p>=begin<br>
Example:</p>
<blockquote>
<blockquote>
<p>module Foo; end<br>
module Foo::Bar<br>
p Bar<br>
end<br>
NameError: uninitialized constant Foo::Bar::Bar<br>
from (irb):3:in <code><module:Bar>' from (irb):2 from /opt/Ruby/1.9.3-p327/bin/irb:12:in </code>'</p>
</blockquote>
</blockquote>
<p>While I understand the technical details of constant lookup and why this happens, it just seems plan wrong on the face of it. Why wouldn't a module/class not at least see ((<em>itself</em>))!?</p>
<p>For use case -- I was writing some code and I determined that a whole set of classes should be under a secondary namespace. It was convenient to go from <code>module Realms</code> to <code>class Realms::Library</code>, but alas, it broke the code, because none of the code inside could see <code>Library</code> anymore. So I had to go through all the files, use two lines instead on one, i.e. <code>module Realms</code> then <code>class Library</code>, indent every line another tab and finally add another <code>end</code> at the bottom of each file. A pain in the arse!</p>
<p>While it might not technically be a "bug", I am going to go ahead and file it as one b/c to me it really seems like one. And if I didn't know exactly how constant lookup worked I would think it one too.<br>
=end</p> Ruby master - Feature #7677 (Closed): YAML load mode that does instantiate Ruby https://bugs.ruby-lang.org/issues/76772013-01-09T11:40:02Ztrans (Thomas Sawyer)
<p>See <a href="https://makandracards.com/makandra/892-never-use-yaml-load-with-user-input" class="external">https://makandracards.com/makandra/892-never-use-yaml-load-with-user-input</a></p>
<p>I suggest that YAML.load and YAML.load_file have an optional mode that will allow the YAML to load but not instantiate <code>!ruby/object:</code> tags, nor any registered tags. To go with this there could be a way to see what the tag is after having been loaded.</p> Ruby master - Feature #7614 (Open): alias_accessorhttps://bugs.ruby-lang.org/issues/76142012-12-24T11:19:06Ztrans (Thomas Sawyer)
<p>=begin<br>
Prior issue reminded me that I've been meaning to ask for this for a while, as I use is fairly often.</p>
<p>In pure Ruby the definition is essentially:</p>
<pre><code>def alias_accessor(name, origin)
alias_method "#{name}=", "#{origin}="
alias_method name, origin
end
</code></pre>
<p>Albeit pursuit to prior mentioned issue, I'd define it more like:</p>
<pre><code>def alias_accessor(name, origin)
writer_name = name.to_s.chomp('?')
alias_method "#{writer_name}=", "#{origin}="
alias_method name, origin
end
</code></pre>
<p>=end</p> Ruby master - Feature #7611 (Open): Focal method for all loads/requireshttps://bugs.ruby-lang.org/issues/76112012-12-23T23:50:40Ztrans (Thomas Sawyer)
<p>=begin<br>
Presently Ruby has seven methods for importing code. These are:</p>
<ul>
<li>(({Kernel#load}))</li>
<li>(({Kernel#require}))</li>
<li>(({Kernel#relative_require}))</li>
<li>(({Kernel.load}))</li>
<li>(({Kernel.require}))</li>
<li>(({Kernel.relative_require}))</li>
<li>(({Kernel#autoload}))</li>
</ul>
<p>Even though the Kernel module methods do the same thing as the instance methods, all of these act independently. If you need to tap into or override code loading in general it means doing so for each and every one.</p>
<p>Would it not be much more elegant if they all called upon one focal method? Lacking another name for this example, lets call it (({#open_eval()})). The method would take a path argument and options for (({feature})), (({relative})) and (({wrap})), where if (({feature})) is true then it is a "require", otherwise it is a "load".</p>
<p>def open_eval(path, feature: false, relative: false, wrap: nil)<br>
...<br>
end</p>
<p>All the other seven methods listed above would route to this one method. So it would then be possible to monitor or override this behavior, e.g. like RubyGems does, via a single interface.</p>
<p>Note, even if this feature request is not accepted, I would like to get some opinion on it, b/c I am currently working on a project where I have to do this (specifically I am in need of require/load callbacks). For the purpose I have created another reusable gem for it and I want to get an idea of what would be considered appropriate API for it.<br>
=end</p> Ruby master - Feature #7548 (Open): Load and Require Callbackshttps://bugs.ruby-lang.org/issues/75482012-12-12T13:15:48Ztrans (Thomas Sawyer)
<p>=begin<br>
Should #load and #require have callbacks? e.g.</p>
<p>def required(path)<br>
...<br>
end</p>
<p>def loaded(path, wrap)<br>
...<br>
end</p>
<p>On occasion I have wanted to do load monitoring to track down a bug. This would have made it easier.</p>
<p>Are there any other good use cases?<br>
=end</p> Ruby master - Feature #7519 (Rejected): Module Single Inheritancehttps://bugs.ruby-lang.org/issues/75192012-12-06T00:36:30Ztrans (Thomas Sawyer)
<p>A limitation of modules is that they can not gain and augment the qualities of another module in the same manner that a class can of another class. They can use #include, but using #include to carry the behavior of one module into another is limited in that singleton methods are not available to it and also because of the well known Module Include Problem. So it occurs to me that modules could have their own inheritance chain.</p>
<p>For example:</p>
<p>module M<br>
def self.foo<br>
"foo"<br>
end<br>
def bar<br>
"bar"<br>
end<br>
end</p>
<p>module N < M<br>
def bar<br>
super + "!"<br>
end<br>
end</p>
<p>N.foo #=> "foo"</p>
<p>class C<br>
include N<br>
end</p>
<p>C.new.bar #=> "bar!"</p>
<p>I think it easy to think about in terms of classes being types of "nouns", and modules being types of "adjectives". So just as one "noun" can inherit the behavior of another "noun", so could one "adjective" inherit the behavior of another "adjective".</p> Ruby master - Feature #7487 (Rejected): Cutting through the issues with Refinementshttps://bugs.ruby-lang.org/issues/74872012-12-01T08:55:57Ztrans (Thomas Sawyer)
<p>=begin<br>
In issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Refinements and nested methods (Closed)" href="https://bugs.ruby-lang.org/issues/4085">#4085</a>, there has been a long somewhat contentious discussion about Refinements. While it seems that everyone agrees they have merit, no one seems to have a concrete idea about how they should actually work. There are all sorts of complicated questions and edge case being flailed about. And though Matz is determined to stick to the feature freeze and include Refinements in Ruby 2.0, he has had to greatly peel back there capabilities and scope --it's quite a large change this close to release, and no one is still at all sure that this new limited design is right either. All this is rather unfortunate, not just because it means Ruby 2.0 is probably going to have a half-baked feature that is certain to change substantially by 2.1, but even more so because we were having pretty much the very same discussion six years ago!</p>
<p>In late 2003, there was a long discussion about method wrapping and aspect-oriented programming (AOP) on ruby-talk[1,2,3]. The conversation grew out of an early notion Matz (and maybe Jim Weirich?) had about wrapping methods for Rite. Remember Rite? That was the codename of the original Ruby 2.0. Back then Matz offered up the idea of using (({:pre})) and (({:post})) hooks to wrap methods. The notation was something like:</p>
<pre><code>class C
def foo
print "foo"
end
def foo:pre
print "before"
end
def foo:post
print "after"
end
end
C.new.foo
=> "beforefooafter"
</code></pre>
<p>Many of the same questions were asked about these method "hooks" that are now being asked about refinements -- "do they stack", "what happens if we remove the main method", "how are they applied to the object hierarchy?", and so on. While at first glance these yesteryear method hooks and today's refinements may seem quite different, they are actually quite related, which will become clear in a moment.</p>
<p>It was through these threads that Peter Vanbroekhoven and myself began an extensive conversation on AOP for Ruby, based originally on his idea of method wrapping via a module in much the same way as one uses include. He originally called the method that handled this simply "wrap". We know it today as (({prepend})). So you can thank Peter for that whole idea[4]. So, we were both very interested in the concept of AOP and with these early notions in mind we decided to take our conversation off-list with the hope of working out the ideal design for bringing AOP to Ruby. Truth is, we did even better than that.</p>
<p>Peter and I continued to discuss AOP over the following year trading hundreds of communiques exploring every nook and cranny of the concept. Indeed, at a certain point I think Peter was quite tired of it, as I had the tendency to review a concept again and again and again just to make sure we didn't miss anything. But as long and drawn out and as detailed as the whole process was, I think we were far the better for it. We developed a very good understanding of the whole matter. In the course of these conversations, I came upon the idea of the ((<em>transparent-subclass</em>)). It was little more than a variation on Peters original wrap idea but it had all the hallmarks of a fundamental OOP concept. With further discussion we agreed that this was a solid corner stone upon which to lay AOP --and not just for Ruby, but for OOP in general! I gave it a name, the "Cut".</p>
<p>From there Peter and I toiled to write an RCR (Ruby Change Request) to introduce the concept to the Ruby community. (Yes, in those days there was such a thing.) We wrote and edited our RCR on the old RubyGarden.org wiki. After many dozens of revisions and over a year after our original discussion!, we finally had our proposal. To top it off Peter even put together a preliminary implementation patch for Ruby, as I put together a pure Ruby (and thus limited) demonstration library. You can find that code and the ((<RCR|URL:<a href="http://rubyworks.github.com/cuts/rcr.html%3E" class="external">http://rubyworks.github.com/cuts/rcr.html></a>)) today on ((<github|URL:<a href="http://rubyworks.github.com/cuts%3E" class="external">http://rubyworks.github.com/cuts></a>)).</p>
<p>Now all of this pre-story leads up to what I want to suggest now. I would like the Cuts RCR to be reconsidered[5], on the merits that it is precisely the well thought out, solid foundation, with a real OOP design, that can serve as the basis of implementation for both prepend and refinements, as well as all other aspect-oriented designs patterns developers wish it construct.</p>
<p>So how does this work? How can prepend and refinements be implemented via cuts?</p>
<p>By simple analogy, prepend is to include as cuts are to classes. What this means implementation-wise is that just as modules are included in the class hierarchy via proxy classes, modules would be prepended into the hierarchy via proxy cuts. Its a simple symmetry that provides the proper behavior.</p>
<p>For refinements we need only add a conditional proviso to cuts --a cut would only be applicable if the pertinent scope is <code>using</code> the refinement. The condition could even be customizable for other uses lending a great deal of flexibility, power and convenience in aspect-oriented designs. To make this idea clear, here is example code for how a cut can be used as a refinement:</p>
<pre><code>cut MyRefinement < String
def self.apply?(binding)
binding.using?(self)
end
def titlecase
gsub(/\b\w/){ $`[-1,1] == "'" ? $& : $&.upcase }
end
end
</code></pre>
<p>This is just a normal cut as described in the RCR, but we have added the idea of an ((<em>applicable callback</em>)) --a condition that determines if the cut is used or skipped-over in the method chain. What <code>binding.using?</code> checks exactly is up to Matz. Most recently Matz has said that the scope should be per-file, but it can just as easily be at a lower level, say pre-module, and it all works --because, cuts themselves have a well defined behavior.</p>
<p>There would be no more confusion about how refinements are supposed to work. Cuts provide the well-defined answer.</p>
<hr>
<p>[1] ((<a href="URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86071" class="external">URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86071</a>))</p>
<p>[2] ((<a href="URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86391" class="external">URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86391</a>))</p>
<p>[3] ((<a href="URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86646" class="external">URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86646</a>))</p>
<p>[4] Not actually Yahuda Katz, who Matz has erroneously credited is his recent keynote speeches.</p>
<p>[5] Excluding the idea of the aspect given at the end of the RCR, that can be done via a 3rd party gem.<br>
=end</p> Ruby master - Feature #7486 (Rejected): Cutting through the issues with Refinementshttps://bugs.ruby-lang.org/issues/74862012-12-01T08:50:19Ztrans (Thomas Sawyer)
<p>=begin<br>
In issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Refinements and nested methods (Closed)" href="https://bugs.ruby-lang.org/issues/4085">#4085</a>, there has been a long somewhat contentious discussion about Refinements. While it seems that everyone agrees they have merit, no one seems to have a concrete idea about how they should actually work. There are all sorts of complicated questions and edge case being flailed about. And though Matz is determined to stick to the feature freeze and include Refinements in Ruby 2.0, he has had to greatly peel back there capabilities and scope --it's quite a large change this close to release, and no one is still at all sure that this new limited design is right either. All this is rather unfortunate, not just because it means Ruby 2.0 is probably going to have a half-baked feature that is certain to change substantially by 2.1, but even more so because we were having pretty much the very same discussion six years ago!</p>
<p>In late 2003, there was a long discussion about method wrapping and aspect-oriented programming (AOP) on ruby-talk[1,2,3]. The conversation grew out of an early notion Matz (and maybe Jim Weirich?) had about wrapping methods for Rite. Remember Rite? That was the codename of the original Ruby 2.0. Back then Matz offered up the idea of using (({:pre})) and (({:post})) hooks to wrap methods. The notation was something like:</p>
<pre><code>class C
def foo
print "foo"
end
def foo:pre
print "before"
end
def foo:post
print "after"
end
end
C.new.foo #=> "beforefooafter"
</code></pre>
<p>Many of the same questions were asked about these method "hooks" that are now being asked about refinements --"do they stack"", "what happens if we remove the main method", "how are they applied to the object hierarchy?", and so on. While at first glance these yesteryear method hooks and today's refinements may seem quite different, they are actually quite related, which will become clear in a moment.</p>
<p>It was through these threads that Peter Vanbroekhoven and myself began an extensive conversation on AOP for Ruby, based originally on his idea of method wrapping via a module in much the same way as one uses include. He originally called the method that handled this simply "wrap". We know it today as (({prepend})). So you can thank Peter for that whole idea[4]. So, we were both very interested in the concept of AOP and with these early notions in mind we decided to take our conversation off-list with the hope of working out the ideal design for bringing AOP to Ruby. Truth is, we did even better than that.</p>
<p>Peter and I continued to discuss AOP over the following year trading hundreds of communiques exploring every nook and cranny of the concept. Indeed, at a certain point I think Peter was quite tired of it, as I had the tendency to review a concept again and again and again just to make sure we didn't miss anything. But as long and drawn out and as detailed as the whole process was, I think we were far the better for it. We developed a very good understanding of the whole matter. In the course of these conversations, I came upon the idea of the ((<em>transparent subclass</em>)). It was little more than a variation on Peters original wrap idea but it had all the hallmarks of a fundamental OOP concept. With further discussion we agreed that this was a solid corner stone upon which to lay AOP --and not just for Ruby, but for OOP in general! I gave it a name, the "Cut".</p>
<p>From there Peter and I toiled to write an RCR (Ruby Change Request) to introduce the concept to the Ruby community. (Yes, in those days there was such a thing.) We wrote and edited our RCR on the old RubyGarden.org wiki. After many dozens of revisions and over a year after our original discussion!, we finally had our proposal. To top it off Peter even put together a preliminary implementation patch for Ruby, as I put together a pure Ruby (and thus limited) demonstration library. You can find that code and the ((<RCR|<a href="http://rubyworks.github.com/cuts/rcr.html%3E" class="external">http://rubyworks.github.com/cuts/rcr.html></a>)) today on ((<github|<a href="http://rubyworks.github.com/cuts%3E" class="external">http://rubyworks.github.com/cuts></a>)).</p>
<p>Now all of this pre-story leads up to what I want to suggest now. I would like the Cuts RCR to be reconsidered[5], on the merits that it is precisely the well thought out, solid foundation, with a real OOP design, that can serve as the basis of implementation for both prepend and refinements, as well as all other aspect-oriented designs patterns developers wish it construct.</p>
<p>So how does this work? How can prepend and refinements be implemented via cuts?</p>
<p>By simple analogy, prepend is to include as cuts are to classes. What this means implementation-wise is that just as modules are included in the class hierarchy via proxy classes, modules would be prepended into the hierarchy via proxy cuts. Its a simple symmetry that provides the proper behavior.</p>
<p>For refinements we need only add a conditional proviso to cuts --a cut would only be applicable if the pertinent scope is <code>using</code> the refinement. The condition could even be customizable for other uses lending a great deal of flexibility, power and convenience in aspect-oriented designs. To make this idea clear, here is example code for how a cut can be used as a refinement:</p>
<pre><code>cut MyRefinement < String
def self.apply?(binding)
binding.using?(self)
end
def titlecase
gsub(/\b\w/){ $`[-1,1] == "'" ? $& : $&.upcase }
end
end
</code></pre>
<p>This is just a normal cut as described in the RCR, but we have added the idea of an ((<em>applicable callback</em>)) --a condition that determines if the cut is used or skipped-over in the method chain. What <code>binding.using?</code> checks exactly is up to Matz. Most recently Matz has said that the scope should be per-file, but it can just as easily be at a lower level, say pre-module, and it all works --because, cuts themselves have a well defined behavior.</p>
<p>There would be no more confusion about how refinements are supposed to work. Cuts provide the well-defined answer.</p>
<p>[1] ((<a href="URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86071" class="external">URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86071</a>))<br>
[2] ((<a href="URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86391" class="external">URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86391</a>))<br>
[3] ((<a href="URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86646" class="external">URL:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86646</a>))<br>
[4] Not Yahuda Katz, who Matz has erroneously credited is his recent keynote speeches.<br>
[5] Excluding the idea of the aspect given at the end of the RCR, that can be done via a 3rd party gem.<br>
=end</p> Ruby master - Feature #7384 (Open): Rename #each_with_object to #each_withhttps://bugs.ruby-lang.org/issues/73842012-11-18T20:12:53Ztrans (Thomas Sawyer)
<p>I propose that #each_with_object be renamed to #each_with, for the following reasons:</p>
<ol>
<li>
<p>The original name is too long. When general purpose methods have long names it tends to deter developers from using them even when they are a good fit to the use case.</p>
</li>
<li>
<p>The last word, "object", is completely redundant. All methods that take an argument could say the same thing. e.g. Array#push is not named #push_object though that is obviously what it means.</p>
</li>
<li>
<p>The change need not effect backward compatibility b/c #each_with_object can remain an alias of #each_with for as long as deemed necessary.</p>
</li>
</ol> Ruby master - Feature #7336 (Rejected): Flexiable OPerator Precedencehttps://bugs.ruby-lang.org/issues/73362012-11-12T23:54:16Ztrans (Thomas Sawyer)
<p>=begin<br>
If Ruby classes could provide some means for redefining operator precedence, it would provide the flexibility useful to some DSL use-cases.</p>
<p>My particular application, for instance, is in an SI units system gem that could use <code>^</code> to mean power of the unit (e.g. 1.meter^3 would mean cubic meters). But to do that right the operator needs a higher precedence. I don't expect it to be something commonly used, obviously, but it certain use cases like mine it is practically essential.</p>
<p>I first suggested that (({#^})) be given a higher precedence and XOR get another operator in <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Precedence of ^ operator (Rejected)" href="https://bugs.ruby-lang.org/issues/6678">#6678</a>. I was not surprised that it was rejected, but I figured it was the proper first step, before proposing this much broader feature request.</p>
<p>As for notation, I suppose the simplest means if to create class method that can move the precedence to a position relative to another, e.g.</p>
<pre><code>class Unit
precedence :^, :**
</code></pre>
<p>Which is to say, move (({#^})) operator to a precedence above (({#**})).<br>
=end</p> Ruby master - Feature #6840 (Rejected): YAML tag methodhttps://bugs.ruby-lang.org/issues/68402012-08-07T09:30:43Ztrans (Thomas Sawyer)
<p>=begin<br>
When loading YAML documents that have a tag, there doesn't seem to be anyway to query for that information.</p>
<p>h = YAML.load("--- !foo\na: 1\nb: 2")<br>
h #=> {"a"=>1, "b"=>2}<br>
h.what_method? #=> "!foo"</p>
<p>I know about <code>YAML.add_domian_tag</code> and the like, but registering tags up front doesn't always fit the usecase. For instance, I am working on a project where I don't want the end users to have to use a support library to work with the data, and I certainly don't expect them to copy and paste dozens of lines of #add_domain_tag boilerplate to their projects. Yet the tags can be useful to them for type revison information, e.g.</p>
<p>--- !foo/2</p>
<p>So this is the second revision of the foo type. The information could be important to consumer apps to ensure they handle the data properly.</p>
<p>So I am proposing that Pysch add a method (maybe call it <code>#yaml_tag</code>), that can be used to get this information from an object when it has been loaded via YAML.<br>
=end</p> Ruby master - Feature #6828 (Open): Constancy of Constantshttps://bugs.ruby-lang.org/issues/68282012-08-04T01:23:08Ztrans (Thomas Sawyer)
<p>=begin<br>
Could have swore there was a recent issue addressing this, but couldn't find it, so...</p>
<p>I hope by Ruby 2.0</p>
<p>module Foo::Bar::Baz</p>
<p>will be equivalent to</p>
<p>module Foo; module Bar; module Baz</p>
<p>That constant lookup doesn't work the same for both is really really really annoying.<br>
=end</p> Ruby master - Feature #6808 (Feedback): Implicit index for enumerationshttps://bugs.ruby-lang.org/issues/68082012-07-29T01:11:44Ztrans (Thomas Sawyer)
<p>=begin<br>
One of the less lovely things about Ruby's otherwise elegant enumerables is the lack of ubiquitous access to the current index. Because of this, we end up with a bevy of extra methods that are little more than counter parts and compensation for other enumerable methods to gain access to the index. Examples include, #each_with_index, #each_index and (in many extension libraries) #collect_with_index. It is all rather wasteful, inelegant, and limiting. Heaven forbid we need a #select_with_index, or some other uncommon case.</p>
<p>No doubt this has had some discussion long in the past, but I would like revisit and offer a bnew more concrete proposal...</p>
<p>Thanks to Enumerator, we can now at least do:</p>
<p>[:a,:b,:c].each_with_index.map{ |e, i| [i, e] }</p>
<p>That's great, but it has obvious shortcomings. It's long winded and it has the overhead of an Enumerator object. Ideally we would want to do this instead:</p>
<p>[:a,:b,:c].map{ |e| [$i, e] }</p>
<p>Where $i is the implicit index. Now a global variable is surely the simplest solution. But, I can understand that some might object to the use of a global variable, despite the fact that this approach is common with regexp matches like $1, $2, etc. In that case, we could designate a new keyword. Lets call it <code>index</code>.</p>
<p>[:a,:b,:c].map{ |e| [index, e] }</p>
<p>We might suffer a conflict here however if someone has already used "index" as a block argument. In that case we would need Ruby to allow it to be overridden, in the same sense that one can define a public method called <code>class</code>, even though <code>class</code> is a keyword in other contexts.</p>
<p>If this were all that we gained then I say it is a victory, but I'd like to consider also that we go a step further, and instead of having just "index", we have an iterative object. After all Ruby is an OOPL. In this case, the keyword would be <code>it</code> and we could do:</p>
<p>[:a,:b,:c].map{ |e| [it.index, e] }</p>
<p>The nice thing about <code>it</code> is that it can have a few other useful methods to improve readability of code, such as <code>it.first?</code> and <code>it.last?</code> (if size is known for the enumerable). I think this is awesome solution that grants the most readability and flexibility to the language.</p>
<p>Of course, having an iteration object might bring up concerns about performance, since it will add overhead to create a new iteration instance with every pass. This can be addressed by having the object be mutable, so all that needs to change is the index in the same object. A minor downside here, an <code>it</code> can't be stored by reference between passes (e.g. <code>prev_it = it</code>), but knowing this, #dup could be used if that was really necessary. If that isn't good enough to curb performance concerns, I would suggest a means of indicating the <code>it</code> object be made available. We don't want to drag Enumerator into this so <code>map.it{...}</code> is not the solution, but perhaps Ruby could recognize <code>;it</code> at the end of block arguments?</p>
<p>[:a,:b,:c].map{ |e; it| [it.index, e] }</p>
<p>Maybe that syntax can't work, but surely something along these lines could. Personally, I doubt the overhead of mutable <code>it</code> is too much, but just in case.</p>
<p>To summarize, I propose an implicit mutable iteration object called <code>it</code> that allows access to the enumerations index, plus convenience methods for querying the index. Or, if that is considered too much, then at least an implicit index, either as a global variable or a special keyword. Any of these choices would be a marked improvement, allowing us to avoid the endless proliferation of <code>_with_index</code> methods.<br>
=end</p> Ruby master - Feature #6737 (Feedback): Add Hash#read and alias as #[].https://bugs.ruby-lang.org/issues/67372012-07-16T02:08:18Ztrans (Thomas Sawyer)
<p>Just, generally speaking it is nice to have a word named method for things when that suites readability better. Most operators (outside of numerical math, of course) have word equivalents. I actually hope you will accept this request based on this merit alone.</p>
<p>But more specifically this is also related to <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: CRUDify Hash class (Feedback)" href="https://bugs.ruby-lang.org/issues/6442">#6442</a>, "CRUDifying" Hash's design. Adding #read is essentially the first step in doing this. Since #read, being the "R" in CRUD, would be one of the core methods, its preferable to have word-named method to go along with other methods, #store (for create and update) and #delete to act as that foundation.</p>
<p>Obviously there is nothing earth shattering here, just asking for an alias at this point. I'd like to incrementally submit requests/patches to "CRUDify" Hash rather then submit one huge patch as it will be much easier to test and ensure backward compatibility that way.</p> Ruby master - Bug #6705 (Closed): Random core dumphttps://bugs.ruby-lang.org/issues/67052012-07-08T03:00:33Ztrans (Thomas Sawyer)
<p>=begin<br>
I keep getting this core dump, but it seems completely random. Here is as much of the dump as I could copy:</p>
<p>513 /home/rubyworks/Projects/rubyworks/smeagol/lib/smeagol.rb<br>
514 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
515 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/json/version.rb<br>
516 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/json/common.rb<br>
517 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
518 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
519 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
520 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
521 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
522 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
523 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/json/ext.rb<br>
524 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/json.rb</p>
<ul>
<li>Process memory map:</li>
</ul>
<p>00400000-0061c000 r-xp 00000000 08:02 20975641 /home/trans/.local/lib/ry/rubies/1.9.3-p194/bin/ruby<br>
0081b000-0081c000 r--p 0021b000 08:02 20975641 /home/trans/.local/lib/ry/rubies/1.9.3-p194/bin/ruby<br>
0081c000-0081e000 rw-p 0021c000 08:02 20975641 /home/trans/.local/lib/ry/rubies/1.9.3-p194/bin/ruby<br>
0081e000-0083b000 rw-p 00000000 00:00 0<br>
02350000-0617a000 rw-p 00000000 00:00 0 [heap]<br>
7f26572b3000-7f2657328000 rw-p 00000000 00:00 0<br>
7f265744a000-7f26574cc000 rw-p 00000000 00:00 0<br>
7f26575ee000-7f26575f7000 r-xp 00000000 08:02 20975739 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
7f26575f7000-7f26577f6000 ---p 00009000 08:02 20975739 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
7f26577f6000-7f26577f7000 r--p 00008000 08:02 20975739 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
7f26577f7000-7f26577f8000 rw-p 00009000 08:02 20975739 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
7f26577f8000-7f26577f9000 r-xp 00000000 08:02 20975676 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
7f26577f9000-7f26579f8000 ---p 00001000 08:02 20975676 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
7f26579f8000-7f26579f9000 r--p 00000000 08:02 20975676 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
7f26579f9000-7f26579fa000 rw-p 00001000 08:02 20975676 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
7f26579fa000-7f26579fb000 r-xp 00000000 08:02 20975724 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
7f26579fb000-7f2657bfa000 ---p 00001000 08:02 20975724 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
7f2657bfa000-7f2657bfb000 r--p 00000000 08:02 20975724 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
7f2657bfb000-7f2657bfc000 rw-p 00001000 08:02 20975724 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
7f2657bfc000-7f2657bfd000 r-xp 00000000 08:02 20975727 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
7f2657bfd000-7f2657dfc000 ---p 00001000 08:02 20975727 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
7f2657dfc000-7f2657dfd000 r--p 00000000 08:02 20975727 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
7f2657dfd000-7f2657dfe000 rw-p 00001000 08:02 20975727 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
7f2657dfe000-7f2657dff000 r-xp 00000000 08:02 20975726 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
7f2657dff000-7f2657ffe000 ---p 00001000 08:02 20975726 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
7f2657ffe000-7f2657fff000 r--p 00000000 08:02 20975726 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
7f2657fff000-7f2658000000 rw-p 00001000 08:02 20975726 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
7f2658000000-7f2658021000 rw-p 00000000 00:00 0<br>
7f2658021000-7f265c000000 ---p 00000000 00:00 0<br>
7f265c0e3000-7f265c0e8000 r-xp 00000000 08:02 20975736 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
7f265c0e8000-7f265c2e8000 ---p 00005000 08:02 20975736 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
7f265c2e8000-7f265c2e9000 r--p 00005000 08:02 20975736 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
7f265c2e9000-7f265c2ea000 rw-p 00006000 08:02 20975736 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
7f265c2ea000-7f265c300000 r-xp 00000000 08:02 20975697 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
7f265c300000-7f265c4ff000 ---p 00016000 08:02 20975697 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
7f265c4ff000-7f265c504000 r--p 00015000 08:02 20975697 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
7f265c504000-7f265c505000 rw-p 0001a000 08:02 20975697 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
7f265c505000-7f265c531000 rw-p 00000000 00:00 0<br>
7f265c588000-7f265c61e000 r-xp 00000000 08:02 8920086 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0<br>
7f265c61e000-7f265c81d000 ---p 00096000 08:02 8920086 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0<br>
7f265c81d000-7f265c823000 r--p 00095000 08:02 8920086 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0<br>
7f265c823000-7f265c824000 rw-p 0009b000 08:02 8920086 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0<br>
7f265c824000-7f265c827000 r-xp 00000000 08:02 9046227 /usr/lib/python2.7/dist-packages/PIL/_imagingft.so<br>
7f265c827000-7f265ca27000 ---p 00003000 08:02 9046227 /usr/lib/python2.7/dist-packages/PIL/_imagingft.so<br>
7f265ca27000-7f265ca28000 r--p 00003000 08:02 9046227 /usr/lib/python2.7/dist-packages/PIL/_imagingft.so<br>
7f265ca28000-7f265ca29000 rw-p 00004000 08:02 9046227 /usr/lib/python2.7/dist-packages/PIL/_imagingft.so<br>
7f265ca29000-7f265caea000 rw-p 00000000 00:00 0<br>
7f265caea000-7f265cb28000 r-xp 00000000 08:02 8920233 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2<br>
7f265cb28000-7f265cd27000 ---p 0003e000 08:02 8920233 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2<br>
7f265cd27000-7f265cd28000 r--p 0003d000 08:02 8920233 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2<br>
7f265cd28000-7f265cd29000 rw-p 0003e000 08:02 8920233 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2<br>
7f265cd29000-7f265cd39000 rw-p 00000000 00:00 0<br>
7f265cd39000-7f265cd75000 r-xp 00000000 08:02 9046225 /usr/lib/python2.7/dist-packages/PIL/_imaging.so<br>
7f265cd75000-7f265cf74000 ---p 0003c000 08:02 9046225 /usr/lib/python2.7/dist-packages/PIL/_imaging.so<br>
7f265cf74000-7f265cf77000 r--p 0003b000 08:02 9046225 /usr/lib/python2.7/dist-packages/PIL/_imaging.so<br>
7f265cf77000-7f265cf7a000 rw-p 0003e000 08:02 9046225 /usr/lib/python2.7/dist-packages/PIL/_imaging.so<br>
7f265cf7a000-7f265cf9b000 r-xp 00000000 08:02 9047585 /usr/lib/python2.7/lib-dynload/_ctypes.so<br>
7f265cf9b000-7f265d19a000 ---p 00021000 08:02 9047585 /usr/lib/python2.7/lib-dynload/_ctypes.so<br>
7f265d19a000-7f265d19b000 r--p 00020000 08:02 9047585 /usr/lib/python2.7/lib-dynload/_ctypes.so<br>
7f265d19b000-7f265d19f000 rw-p 00021000 08:02 9047585 /usr/lib/python2.7/lib-dynload/_ctypes.so<br>
7f265d19f000-7f265d1a0000 rw-p 00000000 00:00 0<br>
7f265d1a0000-7f265d1a3000 r-xp 00000000 08:02 9047590 /usr/lib/python2.7/lib-dynload/_heapq.so<br>
7f265d1a3000-7f265d3a2000 ---p 00003000 08:02 9047590 /usr/lib/python2.7/lib-dynload/_heapq.so<br>
7f265d3a2000-7f265d3a3000 r--p 00002000 08:02 9047590 /usr/lib/python2.7/lib-dynload/_heapq.so<br>
7f265d3a3000-7f265d3a5000 rw-p 00003000 08:02 9047590 /usr/lib/python2.7/lib-dynload/_heapq.so<br>
7f265d3a5000-7f265d3ba000 r-xp 00000000 08:02 24382982 /lib/x86_64-linux-gnu/libgcc_s.so.1<br>
7f265d3ba000-7f265d5b9000 ---p 00015000 08:02 24382982 /lib/x86_64-linux-gnu/libgcc_s.so.1<br>
7f265d5b9000-7f265d5ba000 r--p 00014000 08:02 24382982 /lib/x86_64-linux-gnu/libgcc_s.so.1<br>
7f265d5ba000-7f265d5bb000 rw-p 00015000 08:02 24382982 /lib/x86_64-linux-gnu/libgcc_s.so.1<br>
7f265d5bb000-7f265d5bd000 r-xp 00000000 08:02 24383065 /lib/x86_64-linux-gnu/libutil-2.15.so<br>
7f265d5bd000-7f265d7bc000 ---p 00002000 08:02 24383065 /lib/x86_64-linux-gnu/libutil-2.15.so<br>
7f265d7bc000-7f265d7bd000 r--p 00001000 08:02 24383065 /lib/x86_64-linux-gnu/libutil-2.15.so<br>
7f265d7bd000-7f265d7be000 rw-p 00002000 08:02 24383065 /lib/x86_64-linux-gnu/libutil-2.15.so<br>
7f265d7be000-7f265da3f000 r-xp 00000000 08:02 8916000 /usr/lib/libpython2.7.so.1.0<br>
7f265da3f000-7f265dc3e000 ---p 00281000 08:02 8916000 /usr/lib/libpython2.7.so.1.0<br>
7f265dc3e000-7f265dc40000 r--p 00280000 08:02 8916000 /usr/lib/libpython2.7.so.1.0<br>
7f265dc40000-7f265dca9000 rw-p 00282000 08:02 8916000 /usr/lib/libpython2.7.so.1.0<br>
7f265dca9000-7f265ddbc000 rw-p 00000000 00:00 0<br>
7f265ddbc000-7f265ddbd000 r-xp 00000000 08:02 20975662 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/fcntl.so<br>
7f265ddbd000-7f265dfbc000 ---p 00001000 08:02 20975662 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/fcntl.so<br>
7f265dfbc000-7f265dfbd000 r--p 00000000 08:02 20975662 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/fcntl.so<br>
7f265dfbd000-7f265dfbe000 rw-p 00001000 08:02 20975662 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/fcntl.so<br>
7f265dfbe000-7f265e010000 r-xp 00000000 08:02 24380314 /lib/x86_64-linux-gnu/libssl.so.1.0.0<br>
7f265e010000-7f265e210000 ---p 00052000 08:02 24380314 /lib/x86_64-linux-gnu/libssl.so.1.0.0<br>
7f265e210000-7f265e213000 r--p 00052000 08:02 24380314 /lib/x86_64-linux-gnu/libssl.so.1.0.0<br>
7f265e213000-7f265e219000 rw-p 00055000 08:02 24380314 /lib/x86_64-linux-gnu/libssl.so.1.0.0<br>
7f265e219000-7f265e21a000 rw-p 00000000 00:00 0<br>
7f265e21a000-7f265e265000 r-xp 00000000 08:02 20975943 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/openssl.so<br>
7f265e265000-7f265e465000 ---p 0004b000 08:02 20975943 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/openssl.so<br>
7f265e465000-7f265e466000 r--p 0004b000 08:02 20975943 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/openssl.so<br>
7f265e466000-7f265e468000 rw-p 0004c000 08:02 20975943 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/openssl.so<br>
7f265e468000-7f265e469000 rw-p 00000000 00:00 0<br>
7f265e469000-7f265e48c000 r-xp 00000000 08:02 20975731 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/socket.so<br>
7f265e48c000-7f265e68b000 ---p 00023000 08:02 20975731 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/socket.so<br>
7f265e68b000-7f265e68c000 r--p 00022000 08:02 20975731 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/socket.so<br>
7f265e68c000-7f265e68d000 rw-p 00023000 08:02 20975731 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/socket.so<br>
7f265e68d000-7f265e690000 r-xp 00000000 08:02 3543558 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/posix-spawn-0.3.6/lib/posix_spawn_ext.so<br>
7f265e690000-7f265e88f000 ---p 00003000 08:02 3543558 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/posix-spawn-0.3.6/lib/posix_spawn_ext.so<br>
7f265e88f000-7f265e890000 r--p 00002000 08:02 3543558 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/posix-spawn-0.3.6/lib/posix_spawn_ext.so<br>
7f265e890000-7f265e891000 rw-p 00003000 08:02 3543558 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/posix-spawn-0.3.6/lib/posix_spawn_ext.so<br>
7f265e891000-7f265e8b3000 r-xp 00000000 08:02 3543095 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi_c.so<br>
7f265e8b3000-7f265eab2000 ---p 00022000 08:02 3543095 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi_c.so<br>
7f265eab2000-7f265eab3000 r--p 00021000 08:02 3543095 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi_c.so<br>
7f265eab3000-7f265eab4000 rw-p 00022000 08:02 3543095 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi_c.so<br>
7f265eab4000-7f265eab8000 r-xp 00000000 08:02 20975729 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/racc/cparse.so<br>
7f265eab8000-7f265ecb7000 ---p 00004000 08:02 20975729 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/racc/cparse.so<br>
7f265ecb7000-7f265ecb8000 r--p 00003000 08:02 20975729 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/racc/cparse.so<br>
7f265ecb8000-7f265ecb9000 rw-p 00004000 08:02 20975729 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/racc/cparse.so<br>
7f265ecb9000-7f265ecbc000 r-xp 00000000 08:02 24382988 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0<br>
7f265ecbc000-7f265eebb000 ---p 00003000 08:02 24382988 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0<br>
7f265eebb000-7f265eebc000 r--p 00002000 08:02 24382988 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0<br>
7f265eebc000-7f265eebd000 rw-p 00003000 08:02 24382988 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0<br>
7f265eebd000-7f265ef37000 r-xp 00000000 08:02 24379466 /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0<br>
7f265ef37000-7f265f137000 ---p 0007a000 08:02 24379466 /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0<br>
7f265f137000-7f265f138000 r--p 0007a000 08:02 24379466 /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0<br>
7f265f138000-7f265f13b000 rw-p 0007b000 08:02 24379466 /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0<br>
7f265f13b000-7f265f28c000 r-xp 00000000 08:02 8918697 /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8<br>
7f265f28c000-7f265f48b000 ---p 00151000 08:02 8918697 /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8<br>
7f265f48b000-7f265f493000 r--p 00150000 08:02 8918697 /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8<br>
7f265f493000-7f265f495000 rw-p 00158000 08:02 8918697 /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8<br>
7f265f495000-7f265f496000 rw-p 00000000 00:00 0<br>
7f265f496000-7f265f4d0000 r-xp 00000000 08:02 8920496 /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.26<br>
7f265f4d0000-7f265f6cf000 ---p 0003a000 08:02 8920496 /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.26<br>
7f265f6cf000-7f265f6d0000 r--p 00039000 08:02 8920496 /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.26<br>
7f265f6d0000-7f265f6d1000 rw-p 0003a000 08:02 8920496 /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.26<br>
7f265f6d1000-7f265f6e5000 r-xp 00000000 08:02 8920074 /usr/lib/x86_64-linux-gnu/libexslt.so.0.8.15<br>
7f265f6e5000-7f265f8e4000 ---p 00014000 08:02 8920074 /usr/lib/x86_64-linux-gnu/libexslt.so.0.8.15<br>
7f265f8e4000-7f265f8e5000 r--p 00013000 08:02 8920074 /usr/lib/x86_64-linux-gnu/libexslt.so.0.8.15<br>
7f265f8e5000-7f265f8e6000 rw-p 00014000 08:02 8920074 /usr/lib/x86_64-linux-gnu/libexslt.so.0.8.15<br>
7f265f8e6000-7f265f8ff000 r-xp 00000000 08:02 3544353 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.4/lib/nokogiri/nokogiri.so<br>
7f265f8ff000-7f265fafe000 ---p 00019000 08:02 3544353 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.4/lib/nokogiri/nokogiri.so<br>
7f265fafe000-7f265faff000 r--p 00018000 08:02 3544353 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.4/lib/nokogiri/nokogiri.so<br>
7f265faff000-7f265fb00000 rw-p 00019000 08:02 3544353 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.4/lib/nokogiri/nokogiri.so<br>
7f265fb00000-7f265fb02000 r-xp 00000000 08:02 20975716 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/iso_8859_1.so<br>
7f265fb02000-7f265fd01000 ---p 00002000 08:02 20975716 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/iso_8859_1.so<br>
7f265fd01000-7f265fd02000 r--p 00001000 08:02 20975716 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/iso_8859_1.so<br>
7f265fd02000-7f265fd03000 rw-p 00002000 08:02 20975716 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/iso_8859_1.so<br>
7f265fd03000-7f265fd8f000 r-xp 00000000 08:02 27793230 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.9/lib/redcloth_scan.so<br>
7f265fd8f000-7f265ff8e000 ---p 0008c000 08:02 27793230 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.9/lib/redcloth_scan.so<br>
7f265ff8e000-7f265ff8f000 r--p 0008b000 08:02 27793230 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.9/lib/redcloth_scan.so<br>
7f265ff8f000-7f265ff90000 rw-p 0008c000 08:02 27793230 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.9/lib/redcloth_scan.so<br>
7f265ff90000-7f265ff91000 rw-p 00000000 00:00 0<br>
7f265ff91000-7f265ff9e000 r-xp 00000000 08:02 3542571 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/github-markdown-0.4.1/lib/github/markdown.so<br>
7f265ff9e000-7f266019e000 ---p 0000d000 08:02 3542571 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/github-markdown-0.4.1/lib/github/markdown.so<br>
7f266019e000-7f266019f000 r--p 0000d000 08:02 3542571 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/github-markdown-0.4.1/lib/github/markdown.so<br>
7f266019f000-7f26601a0000 rw-p 0000e000 08:02 3542571 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/github-markdown-0.4.1/lib/github/markdown.so<br>
7f26601a0000-7f26601ae000 r-xp 00000000 08:02 20975743 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/zlib.so<br>
7f26601ae000-7f26603ad000 ---p 0000e000 08:02 20975743 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/zlib.so<br>
7f26603ad000-7f26603ae000 r--p 0000d000 08:02 20975743 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/zlib.so<br>
7f26603ae000-7f26603af000 rw-p 0000e000 08:02 20975743 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/zlib.so<br>
7f26603af000-7f26603b0000 r-xp 00000000 08:02 20975655 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/sha1.so<br>
7f26603b0000-7f26605af000 ---p 00001000 08:02 20975655 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/sha1.so<br>
7f26605af000-7f26605b0000 r--p 00000000 08:02 20975655 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/sha1.so<br>
7f26605b0000-7f26605b1000 rw-p 00001000 08:02 20975655 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/sha1.so<br>
7f26605b1000-7f26605b4000 r-xp 00000000 08:02 20975745 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/etc.so<br>
7f26605b4000-7f26607b3000 ---p 00003000 08:02 20975745 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/etc.so<br>
7f26607b3000-7f26607b4000 r--p 00002000 08:02 20975745 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/etc.so<br>
7f26607b4000-7f26607b5000 rw-p 00003000 08:02 20975745 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/etc.so<br>
7f26607b5000-7f26607b8000 r-xp 00000000 08:02 20975668 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest.so<br>
7f26607b8000-7f26609b7000 ---p 00003000 08:02 20975668 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest.so<br>
7f26609b7000-7f26609b8000 r--p 00002000 08:02 20975668 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest.so<br>
7f26609b8000-7f26609b9000 rw-p 00003000 08:02 20975668 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest.so<br>
7f26609b9000-7f26609cf000 r-xp 00000000 08:02 24383072 /lib/x86_64-linux-gnu/libz.so.1.2.3.4<br>
7f26609cf000-7f2660bce000 ---p 00016000 08:02 24383072 /lib/x86_64-linux-gnu/libz.so.1.2.3.4<br>
7f2660bce000-7f2660bcf000 r--p 00015000 08:02 24383072 /lib/x86_64-linux-gnu/libz.so.1.2.3.4<br>
7f2660bcf000-7f2660bd0000 rw-p 00016000 08:02 24383072 /lib/x86_64-linux-gnu/libz.so.1.2.3.4<br>
7f2660bd0000-7f2660d6f000 r-xp 00000000 08:02 24380313 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0<br>
7f2660d6f000-7f2660f6e000 ---p 0019f000 08:02 24380313 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0<br>
7f2660f6e000-7f2660f89000 r--p 0019e000 08:02 24380313 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0<br>
7f2660f89000-7f2660f94000 rw-p 001b9000 08:02 24380313 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0<br>
7f2660f94000-7f2660f98000 rw-p 00000000 00:00 0<br>
7f2660f98000-7f2660f99000 r-xp 00000000 08:02 20975654 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/md5.so<br>
7f2660f99000-7f2661198000 ---p 00001000 08:02 20975654 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/md5.so<br>
7f2661198000-7f2661199000 r--p 00000000 08:02 20975654 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/md5.so<br>
7f2661199000-7f266119a000 rw-p 00001000 08:02 20975654 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/md5.so<br>
7f266119a000-7f26611cc000 r-xp 00000000 08:02 20975741 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f26611cc000-7f26613cc000 ---p 00032000 08:02 20975741 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f26613cc000-7f26613cd000 r--p 00032000 08:02 20975741 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f26613cd000-7f26613ce000 rw-p 00033000 08:02 20975741 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f26613ce000-7f26613d0000 rw-p 00000000 00:00 0<br>
7f26613d0000-7f26613d5000 r-xp 00000000 08:02 20975744 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f26613d5000-7f26615d4000 ---p 00005000 08:02 20975744 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f26615d4000-7f26615d5000 r--p 00004000 08:02 20975744 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f26615d5000-7f26615d6000 rw-p 00005000 08:02 20975744 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f26615d6000-7f26615dd000 r-xp 00000000 08:02 20975728 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f26615dd000-7f26617dc000 ---p 00007000 08:02 20975728 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f26617dc000-7f26617dd000 r--p 00006000 08:02 20975728 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f26617dd000-7f26617de000 rw-p 00007000 08:02 20975728 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f26617de000-7f26617fe000 r-xp 00000000 08:02 20975635 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/libyaml-0.so.2.0.2<br>
7f26617fe000-7f26619fd000 ---p 00020000 08:02 20975635 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/libyaml-0.so.2.0.2<br>
7f26619fd000-7f26619fe000 r--p 0001f000 08:02 20975635 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/libyaml-0.so.2.0.2<br>
7f26619fe000-7f26619ff000 rw-p 00020000 08:02 20975635 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/libyaml-0.so.2.0.2<br>
7f26619ff000-7f2661a05000 r-xp 00000000 08:02 20975657 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f2661a05000-7f2661c04000 ---p 00006000 08:02 20975657 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f2661c04000-7f2661c05000 r--p 00005000 08:02 20975657 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f2661c05000-7f2661c06000 rw-p 00006000 08:02 20975657 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f2661c06000-7f2661c08000 r-xp 00000000 08:02 20975710 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f2661c08000-7f2661e08000 ---p 00002000 08:02 20975710 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f2661e08000-7f2661e09000 r--p 00002000 08:02 20975710 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f2661e09000-7f2661e0a000 rw-p 00003000 08:02 20975710 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f2661e0a000-7f2661e0c000 r-xp 00000000 08:02 20975693 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f2661e0c000-7f266200b000 ---p 00002000 08:02 20975693 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f266200b000-7f266200c000 r--p 00001000 08:02 20975693 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f266200c000-7f266200d000 rw-p 00002000 08:02 20975693 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f266200d000-7f26626f0000 r--p 00000000 08:02 8919290 /usr/lib/locale/locale-archive<br>
7f26626f0000-7f26628a3000 r-xp 00000000 08:02 24382961 /lib/x86_64-linux-gnu/libc-2.15.so<br>
7f26628a3000-7f2662aa2000 ---p 001b3000 08:02 24382961 /lib/x86_64-linux-gnu/libc-2.15.so<br>
7f2662aa2000-7f2662aa6000 r--p 001b2000 08:02 24382961 /lib/x86_64-linux-gnu/libc-2.15.so<br>
7f2662aa6000-7f2662aa8000 rw-p 001b6000 08:02 24382961 /lib/x86_64-linux-gnu/libc-2.15.so<br>
7f2662aa8000-7f2662aad000 rw-p 00000000 00:00 0<br>
7f2662aad000-7f2662ba6000 r-xp 00000000 08:02 24382993 /lib/x86_64-linux-gnu/libm-2.15.so<br>
7f2662ba6000-7f2662da5000 ---p 000f9000 08:02 24382993 /lib/x86_64-linux-gnu/libm-2.15.so<br>
7f2662da5000-7f2662da6000 r--p 000f8000 08:02 24382993 /lib/x86_64-linux-gnu/libm-2.15.so<br>
7f2662da6000-7f2662da7000 rw-p 000f9000 08:02 24382993 /lib/x86_64-linux-gnu/libm-2.15.so<br>
7f2662da7000-7f2662db0000 r-xp 00000000 08:02 24382969 /lib/x86_64-linux-gnu/libcrypt-2.15.so<br>
7f2662db0000-7f2662fb0000 ---p 00009000 08:02 24382969 /lib/x86_64-linux-gnu/libcrypt-2.15.so<br>
7f2662fb0000-7f2662fb1000 r--p 00009000 08:02 24382969 /lib/x86_64-linux-gnu/libcrypt-2.15.so<br>
7f2662fb1000-7f2662fb2000 rw-p 0000a000 08:02 24382969 /lib/x86_64-linux-gnu/libcrypt-2.15.so<br>
7f2662fb2000-7f2662fe0000 rw-p 00000000 00:00 0<br>
7f2662fe0000-7f2662fe2000 r-xp 00000000 08:02 24382974 /lib/x86_64-linux-gnu/libdl-2.15.so<br>
7f2662fe2000-7f26631e2000 ---p 00002000 08:02 24382974 /lib/x86_64-linux-gnu/libdl-2.15.so<br>
7f26631e2000-7f26631e3000 r--p 00002000 08:02 24382974 /lib/x86_64-linux-gnu/libdl-2.15.so<br>
7f26631e3000-7f26631e4000 rw-p 00003000 08:02 24382974 /lib/x86_64-linux-gnu/libdl-2.15.so<br>
7f26631e4000-7f26631eb000 r-xp 00000000 08:02 24383047 /lib/x86_64-linux-gnu/librt-2.15.so<br>
7f26631eb000-7f26633ea000 ---p 00007000 08:02 24383047 /lib/x86_64-linux-gnu/librt-2.15.so<br>
7f26633ea000-7f26633eb000 r--p 00006000 08:02 24383047 /lib/x86_64-linux-gnu/librt-2.15.so<br>
7f26633eb000-7f26633ec000 rw-p 00007000 08:02 24383047 /lib/x86_64-linux-gnu/librt-2.15.so<br>
7f26633ec000-7f2663404000 r-xp 00000000 08:02 24383041 /lib/x86_64-linux-gnu/libpthread-2.15.so<br>
7f2663404000-7f2663603000 ---p 00018000 08:02 24383041 /lib/x86_64-linux-gnu/libpthread-2.15.so<br>
7f2663603000-7f2663604000 r--p 00017000 08:02 24383041 /lib/x86_64-linux-gnu/libpthread-2.15.so<br>
7f2663604000-7f2663605000 rw-p 00018000 08:02 24383041 /lib/x86_64-linux-gnu/libpthread-2.15.so<br>
7f2663605000-7f2663609000 rw-p 00000000 00:00 0<br>
7f2663609000-7f266362b000 r-xp 00000000 08:02 24382941 /lib/x86_64-linux-gnu/ld-2.15.so<br>
7f2663686000-7f2663687000 ---p 00000000 00:00 0<br>
7f2663687000-7f266380d000 rw-p 00000000 00:00 0<br>
7f266381a000-7f266381c000 rw-p 00000000 00:00 0<br>
7f266381c000-7f266381d000 rwxp 00000000 00:00 0<br>
7f266381d000-7f2663824000 r--s 00000000 08:02 9177264 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache<br>
7f2663824000-7f2663825000 r-xp 00000000 00:00 0<br>
7f2663825000-7f2663826000 ---p 00000000 00:00 0<br>
7f2663826000-7f266382b000 rw-p 00000000 00:00 0<br>
7f266382b000-7f266382c000 r--p 00022000 08:02 24382941 /lib/x86_64-linux-gnu/ld-2.15.so<br>
7f266382c000-7f266382e000 rw-p 00023000 08:02 24382941 /lib/x86_64-linux-gnu/ld-2.15.so<br>
7fffb00fe000-7fffb0120000 rw-p 00000000 00:00 0 [stack]<br>
7fffb01ff000-7fffb0200000 r-xp 00000000 00:00 0 [vdso]<br>
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]</p>
<p>[NOTE]<br>
You may have encountered a bug in the Ruby interpreter or extension libraries.<br>
Bug reports are welcome.<br>
For details: <a href="http://www.ruby-lang.org/bugreport.html" class="external">http://www.ruby-lang.org/bugreport.html</a></p>
<p>Aborted (core dumped)</p>
<p>=end</p> Ruby master - Bug #6704 (Rejected): Random core dumphttps://bugs.ruby-lang.org/issues/67042012-07-08T02:59:05Ztrans (Thomas Sawyer)
<p>=begin<br>
I keep getting this core dump, but it seems completely random. Here is as much of the dump as I could copy:</p>
<p>513 /home/rubyworks/Projects/rubyworks/smeagol/lib/smeagol.rb<br>
514 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
515 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/json/version.rb<br>
516 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/json/common.rb<br>
517 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
518 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
519 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
520 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
521 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
522 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
523 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/json/ext.rb<br>
524 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/json.rb</p>
<ul>
<li>Process memory map:</li>
</ul>
<p>00400000-0061c000 r-xp 00000000 08:02 20975641 /home/trans/.local/lib/ry/rubies/1.9.3-p194/bin/ruby<br>
0081b000-0081c000 r--p 0021b000 08:02 20975641 /home/trans/.local/lib/ry/rubies/1.9.3-p194/bin/ruby<br>
0081c000-0081e000 rw-p 0021c000 08:02 20975641 /home/trans/.local/lib/ry/rubies/1.9.3-p194/bin/ruby<br>
0081e000-0083b000 rw-p 00000000 00:00 0<br>
02350000-0617a000 rw-p 00000000 00:00 0 [heap]<br>
7f26572b3000-7f2657328000 rw-p 00000000 00:00 0<br>
7f265744a000-7f26574cc000 rw-p 00000000 00:00 0<br>
7f26575ee000-7f26575f7000 r-xp 00000000 08:02 20975739 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
7f26575f7000-7f26577f6000 ---p 00009000 08:02 20975739 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
7f26577f6000-7f26577f7000 r--p 00008000 08:02 20975739 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
7f26577f7000-7f26577f8000 rw-p 00009000 08:02 20975739 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/generator.so<br>
7f26577f8000-7f26577f9000 r-xp 00000000 08:02 20975676 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
7f26577f9000-7f26579f8000 ---p 00001000 08:02 20975676 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
7f26579f8000-7f26579f9000 r--p 00000000 08:02 20975676 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
7f26579f9000-7f26579fa000 rw-p 00001000 08:02 20975676 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32le.so<br>
7f26579fa000-7f26579fb000 r-xp 00000000 08:02 20975724 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
7f26579fb000-7f2657bfa000 ---p 00001000 08:02 20975724 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
7f2657bfa000-7f2657bfb000 r--p 00000000 08:02 20975724 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
7f2657bfb000-7f2657bfc000 rw-p 00001000 08:02 20975724 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_32be.so<br>
7f2657bfc000-7f2657bfd000 r-xp 00000000 08:02 20975727 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
7f2657bfd000-7f2657dfc000 ---p 00001000 08:02 20975727 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
7f2657dfc000-7f2657dfd000 r--p 00000000 08:02 20975727 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
7f2657dfd000-7f2657dfe000 rw-p 00001000 08:02 20975727 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16le.so<br>
7f2657dfe000-7f2657dff000 r-xp 00000000 08:02 20975726 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
7f2657dff000-7f2657ffe000 ---p 00001000 08:02 20975726 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
7f2657ffe000-7f2657fff000 r--p 00000000 08:02 20975726 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
7f2657fff000-7f2658000000 rw-p 00001000 08:02 20975726 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/utf_16be.so<br>
7f2658000000-7f2658021000 rw-p 00000000 00:00 0<br>
7f2658021000-7f265c000000 ---p 00000000 00:00 0<br>
7f265c0e3000-7f265c0e8000 r-xp 00000000 08:02 20975736 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
7f265c0e8000-7f265c2e8000 ---p 00005000 08:02 20975736 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
7f265c2e8000-7f265c2e9000 r--p 00005000 08:02 20975736 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
7f265c2e9000-7f265c2ea000 rw-p 00006000 08:02 20975736 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/json/ext/parser.so<br>
7f265c2ea000-7f265c300000 r-xp 00000000 08:02 20975697 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
7f265c300000-7f265c4ff000 ---p 00016000 08:02 20975697 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
7f265c4ff000-7f265c504000 r--p 00015000 08:02 20975697 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
7f265c504000-7f265c505000 rw-p 0001a000 08:02 20975697 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/single_byte.so<br>
7f265c505000-7f265c531000 rw-p 00000000 00:00 0<br>
7f265c588000-7f265c61e000 r-xp 00000000 08:02 8920086 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0<br>
7f265c61e000-7f265c81d000 ---p 00096000 08:02 8920086 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0<br>
7f265c81d000-7f265c823000 r--p 00095000 08:02 8920086 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0<br>
7f265c823000-7f265c824000 rw-p 0009b000 08:02 8920086 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0<br>
7f265c824000-7f265c827000 r-xp 00000000 08:02 9046227 /usr/lib/python2.7/dist-packages/PIL/_imagingft.so<br>
7f265c827000-7f265ca27000 ---p 00003000 08:02 9046227 /usr/lib/python2.7/dist-packages/PIL/_imagingft.so<br>
7f265ca27000-7f265ca28000 r--p 00003000 08:02 9046227 /usr/lib/python2.7/dist-packages/PIL/_imagingft.so<br>
7f265ca28000-7f265ca29000 rw-p 00004000 08:02 9046227 /usr/lib/python2.7/dist-packages/PIL/_imagingft.so<br>
7f265ca29000-7f265caea000 rw-p 00000000 00:00 0<br>
7f265caea000-7f265cb28000 r-xp 00000000 08:02 8920233 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2<br>
7f265cb28000-7f265cd27000 ---p 0003e000 08:02 8920233 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2<br>
7f265cd27000-7f265cd28000 r--p 0003d000 08:02 8920233 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2<br>
7f265cd28000-7f265cd29000 rw-p 0003e000 08:02 8920233 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2<br>
7f265cd29000-7f265cd39000 rw-p 00000000 00:00 0<br>
7f265cd39000-7f265cd75000 r-xp 00000000 08:02 9046225 /usr/lib/python2.7/dist-packages/PIL/_imaging.so<br>
7f265cd75000-7f265cf74000 ---p 0003c000 08:02 9046225 /usr/lib/python2.7/dist-packages/PIL/_imaging.so<br>
7f265cf74000-7f265cf77000 r--p 0003b000 08:02 9046225 /usr/lib/python2.7/dist-packages/PIL/_imaging.so<br>
7f265cf77000-7f265cf7a000 rw-p 0003e000 08:02 9046225 /usr/lib/python2.7/dist-packages/PIL/_imaging.so<br>
7f265cf7a000-7f265cf9b000 r-xp 00000000 08:02 9047585 /usr/lib/python2.7/lib-dynload/_ctypes.so<br>
7f265cf9b000-7f265d19a000 ---p 00021000 08:02 9047585 /usr/lib/python2.7/lib-dynload/_ctypes.so<br>
7f265d19a000-7f265d19b000 r--p 00020000 08:02 9047585 /usr/lib/python2.7/lib-dynload/_ctypes.so<br>
7f265d19b000-7f265d19f000 rw-p 00021000 08:02 9047585 /usr/lib/python2.7/lib-dynload/_ctypes.so<br>
7f265d19f000-7f265d1a0000 rw-p 00000000 00:00 0<br>
7f265d1a0000-7f265d1a3000 r-xp 00000000 08:02 9047590 /usr/lib/python2.7/lib-dynload/_heapq.so<br>
7f265d1a3000-7f265d3a2000 ---p 00003000 08:02 9047590 /usr/lib/python2.7/lib-dynload/_heapq.so<br>
7f265d3a2000-7f265d3a3000 r--p 00002000 08:02 9047590 /usr/lib/python2.7/lib-dynload/_heapq.so<br>
7f265d3a3000-7f265d3a5000 rw-p 00003000 08:02 9047590 /usr/lib/python2.7/lib-dynload/_heapq.so<br>
7f265d3a5000-7f265d3ba000 r-xp 00000000 08:02 24382982 /lib/x86_64-linux-gnu/libgcc_s.so.1<br>
7f265d3ba000-7f265d5b9000 ---p 00015000 08:02 24382982 /lib/x86_64-linux-gnu/libgcc_s.so.1<br>
7f265d5b9000-7f265d5ba000 r--p 00014000 08:02 24382982 /lib/x86_64-linux-gnu/libgcc_s.so.1<br>
7f265d5ba000-7f265d5bb000 rw-p 00015000 08:02 24382982 /lib/x86_64-linux-gnu/libgcc_s.so.1<br>
7f265d5bb000-7f265d5bd000 r-xp 00000000 08:02 24383065 /lib/x86_64-linux-gnu/libutil-2.15.so<br>
7f265d5bd000-7f265d7bc000 ---p 00002000 08:02 24383065 /lib/x86_64-linux-gnu/libutil-2.15.so<br>
7f265d7bc000-7f265d7bd000 r--p 00001000 08:02 24383065 /lib/x86_64-linux-gnu/libutil-2.15.so<br>
7f265d7bd000-7f265d7be000 rw-p 00002000 08:02 24383065 /lib/x86_64-linux-gnu/libutil-2.15.so<br>
7f265d7be000-7f265da3f000 r-xp 00000000 08:02 8916000 /usr/lib/libpython2.7.so.1.0<br>
7f265da3f000-7f265dc3e000 ---p 00281000 08:02 8916000 /usr/lib/libpython2.7.so.1.0<br>
7f265dc3e000-7f265dc40000 r--p 00280000 08:02 8916000 /usr/lib/libpython2.7.so.1.0<br>
7f265dc40000-7f265dca9000 rw-p 00282000 08:02 8916000 /usr/lib/libpython2.7.so.1.0<br>
7f265dca9000-7f265ddbc000 rw-p 00000000 00:00 0<br>
7f265ddbc000-7f265ddbd000 r-xp 00000000 08:02 20975662 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/fcntl.so<br>
7f265ddbd000-7f265dfbc000 ---p 00001000 08:02 20975662 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/fcntl.so<br>
7f265dfbc000-7f265dfbd000 r--p 00000000 08:02 20975662 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/fcntl.so<br>
7f265dfbd000-7f265dfbe000 rw-p 00001000 08:02 20975662 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/fcntl.so<br>
7f265dfbe000-7f265e010000 r-xp 00000000 08:02 24380314 /lib/x86_64-linux-gnu/libssl.so.1.0.0<br>
7f265e010000-7f265e210000 ---p 00052000 08:02 24380314 /lib/x86_64-linux-gnu/libssl.so.1.0.0<br>
7f265e210000-7f265e213000 r--p 00052000 08:02 24380314 /lib/x86_64-linux-gnu/libssl.so.1.0.0<br>
7f265e213000-7f265e219000 rw-p 00055000 08:02 24380314 /lib/x86_64-linux-gnu/libssl.so.1.0.0<br>
7f265e219000-7f265e21a000 rw-p 00000000 00:00 0<br>
7f265e21a000-7f265e265000 r-xp 00000000 08:02 20975943 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/openssl.so<br>
7f265e265000-7f265e465000 ---p 0004b000 08:02 20975943 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/openssl.so<br>
7f265e465000-7f265e466000 r--p 0004b000 08:02 20975943 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/openssl.so<br>
7f265e466000-7f265e468000 rw-p 0004c000 08:02 20975943 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/openssl.so<br>
7f265e468000-7f265e469000 rw-p 00000000 00:00 0<br>
7f265e469000-7f265e48c000 r-xp 00000000 08:02 20975731 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/socket.so<br>
7f265e48c000-7f265e68b000 ---p 00023000 08:02 20975731 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/socket.so<br>
7f265e68b000-7f265e68c000 r--p 00022000 08:02 20975731 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/socket.so<br>
7f265e68c000-7f265e68d000 rw-p 00023000 08:02 20975731 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/socket.so<br>
7f265e68d000-7f265e690000 r-xp 00000000 08:02 3543558 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/posix-spawn-0.3.6/lib/posix_spawn_ext.so<br>
7f265e690000-7f265e88f000 ---p 00003000 08:02 3543558 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/posix-spawn-0.3.6/lib/posix_spawn_ext.so<br>
7f265e88f000-7f265e890000 r--p 00002000 08:02 3543558 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/posix-spawn-0.3.6/lib/posix_spawn_ext.so<br>
7f265e890000-7f265e891000 rw-p 00003000 08:02 3543558 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/posix-spawn-0.3.6/lib/posix_spawn_ext.so<br>
7f265e891000-7f265e8b3000 r-xp 00000000 08:02 3543095 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi_c.so<br>
7f265e8b3000-7f265eab2000 ---p 00022000 08:02 3543095 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi_c.so<br>
7f265eab2000-7f265eab3000 r--p 00021000 08:02 3543095 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi_c.so<br>
7f265eab3000-7f265eab4000 rw-p 00022000 08:02 3543095 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi_c.so<br>
7f265eab4000-7f265eab8000 r-xp 00000000 08:02 20975729 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/racc/cparse.so<br>
7f265eab8000-7f265ecb7000 ---p 00004000 08:02 20975729 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/racc/cparse.so<br>
7f265ecb7000-7f265ecb8000 r--p 00003000 08:02 20975729 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/racc/cparse.so<br>
7f265ecb8000-7f265ecb9000 rw-p 00004000 08:02 20975729 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/racc/cparse.so<br>
7f265ecb9000-7f265ecbc000 r-xp 00000000 08:02 24382988 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0<br>
7f265ecbc000-7f265eebb000 ---p 00003000 08:02 24382988 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0<br>
7f265eebb000-7f265eebc000 r--p 00002000 08:02 24382988 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0<br>
7f265eebc000-7f265eebd000 rw-p 00003000 08:02 24382988 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0<br>
7f265eebd000-7f265ef37000 r-xp 00000000 08:02 24379466 /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0<br>
7f265ef37000-7f265f137000 ---p 0007a000 08:02 24379466 /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0<br>
7f265f137000-7f265f138000 r--p 0007a000 08:02 24379466 /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0<br>
7f265f138000-7f265f13b000 rw-p 0007b000 08:02 24379466 /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0<br>
7f265f13b000-7f265f28c000 r-xp 00000000 08:02 8918697 /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8<br>
7f265f28c000-7f265f48b000 ---p 00151000 08:02 8918697 /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8<br>
7f265f48b000-7f265f493000 r--p 00150000 08:02 8918697 /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8<br>
7f265f493000-7f265f495000 rw-p 00158000 08:02 8918697 /usr/lib/x86_64-linux-gnu/libxml2.so.2.7.8<br>
7f265f495000-7f265f496000 rw-p 00000000 00:00 0<br>
7f265f496000-7f265f4d0000 r-xp 00000000 08:02 8920496 /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.26<br>
7f265f4d0000-7f265f6cf000 ---p 0003a000 08:02 8920496 /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.26<br>
7f265f6cf000-7f265f6d0000 r--p 00039000 08:02 8920496 /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.26<br>
7f265f6d0000-7f265f6d1000 rw-p 0003a000 08:02 8920496 /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.26<br>
7f265f6d1000-7f265f6e5000 r-xp 00000000 08:02 8920074 /usr/lib/x86_64-linux-gnu/libexslt.so.0.8.15<br>
7f265f6e5000-7f265f8e4000 ---p 00014000 08:02 8920074 /usr/lib/x86_64-linux-gnu/libexslt.so.0.8.15<br>
7f265f8e4000-7f265f8e5000 r--p 00013000 08:02 8920074 /usr/lib/x86_64-linux-gnu/libexslt.so.0.8.15<br>
7f265f8e5000-7f265f8e6000 rw-p 00014000 08:02 8920074 /usr/lib/x86_64-linux-gnu/libexslt.so.0.8.15<br>
7f265f8e6000-7f265f8ff000 r-xp 00000000 08:02 3544353 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.4/lib/nokogiri/nokogiri.so<br>
7f265f8ff000-7f265fafe000 ---p 00019000 08:02 3544353 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.4/lib/nokogiri/nokogiri.so<br>
7f265fafe000-7f265faff000 r--p 00018000 08:02 3544353 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.4/lib/nokogiri/nokogiri.so<br>
7f265faff000-7f265fb00000 rw-p 00019000 08:02 3544353 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.4/lib/nokogiri/nokogiri.so<br>
7f265fb00000-7f265fb02000 r-xp 00000000 08:02 20975716 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/iso_8859_1.so<br>
7f265fb02000-7f265fd01000 ---p 00002000 08:02 20975716 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/iso_8859_1.so<br>
7f265fd01000-7f265fd02000 r--p 00001000 08:02 20975716 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/iso_8859_1.so<br>
7f265fd02000-7f265fd03000 rw-p 00002000 08:02 20975716 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/iso_8859_1.so<br>
7f265fd03000-7f265fd8f000 r-xp 00000000 08:02 27793230 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.9/lib/redcloth_scan.so<br>
7f265fd8f000-7f265ff8e000 ---p 0008c000 08:02 27793230 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.9/lib/redcloth_scan.so<br>
7f265ff8e000-7f265ff8f000 r--p 0008b000 08:02 27793230 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.9/lib/redcloth_scan.so<br>
7f265ff8f000-7f265ff90000 rw-p 0008c000 08:02 27793230 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.9/lib/redcloth_scan.so<br>
7f265ff90000-7f265ff91000 rw-p 00000000 00:00 0<br>
7f265ff91000-7f265ff9e000 r-xp 00000000 08:02 3542571 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/github-markdown-0.4.1/lib/github/markdown.so<br>
7f265ff9e000-7f266019e000 ---p 0000d000 08:02 3542571 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/github-markdown-0.4.1/lib/github/markdown.so<br>
7f266019e000-7f266019f000 r--p 0000d000 08:02 3542571 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/github-markdown-0.4.1/lib/github/markdown.so<br>
7f266019f000-7f26601a0000 rw-p 0000e000 08:02 3542571 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/gems/1.9.1/gems/github-markdown-0.4.1/lib/github/markdown.so<br>
7f26601a0000-7f26601ae000 r-xp 00000000 08:02 20975743 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/zlib.so<br>
7f26601ae000-7f26603ad000 ---p 0000e000 08:02 20975743 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/zlib.so<br>
7f26603ad000-7f26603ae000 r--p 0000d000 08:02 20975743 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/zlib.so<br>
7f26603ae000-7f26603af000 rw-p 0000e000 08:02 20975743 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/zlib.so<br>
7f26603af000-7f26603b0000 r-xp 00000000 08:02 20975655 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/sha1.so<br>
7f26603b0000-7f26605af000 ---p 00001000 08:02 20975655 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/sha1.so<br>
7f26605af000-7f26605b0000 r--p 00000000 08:02 20975655 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/sha1.so<br>
7f26605b0000-7f26605b1000 rw-p 00001000 08:02 20975655 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/sha1.so<br>
7f26605b1000-7f26605b4000 r-xp 00000000 08:02 20975745 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/etc.so<br>
7f26605b4000-7f26607b3000 ---p 00003000 08:02 20975745 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/etc.so<br>
7f26607b3000-7f26607b4000 r--p 00002000 08:02 20975745 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/etc.so<br>
7f26607b4000-7f26607b5000 rw-p 00003000 08:02 20975745 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/etc.so<br>
7f26607b5000-7f26607b8000 r-xp 00000000 08:02 20975668 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest.so<br>
7f26607b8000-7f26609b7000 ---p 00003000 08:02 20975668 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest.so<br>
7f26609b7000-7f26609b8000 r--p 00002000 08:02 20975668 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest.so<br>
7f26609b8000-7f26609b9000 rw-p 00003000 08:02 20975668 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest.so<br>
7f26609b9000-7f26609cf000 r-xp 00000000 08:02 24383072 /lib/x86_64-linux-gnu/libz.so.1.2.3.4<br>
7f26609cf000-7f2660bce000 ---p 00016000 08:02 24383072 /lib/x86_64-linux-gnu/libz.so.1.2.3.4<br>
7f2660bce000-7f2660bcf000 r--p 00015000 08:02 24383072 /lib/x86_64-linux-gnu/libz.so.1.2.3.4<br>
7f2660bcf000-7f2660bd0000 rw-p 00016000 08:02 24383072 /lib/x86_64-linux-gnu/libz.so.1.2.3.4<br>
7f2660bd0000-7f2660d6f000 r-xp 00000000 08:02 24380313 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0<br>
7f2660d6f000-7f2660f6e000 ---p 0019f000 08:02 24380313 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0<br>
7f2660f6e000-7f2660f89000 r--p 0019e000 08:02 24380313 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0<br>
7f2660f89000-7f2660f94000 rw-p 001b9000 08:02 24380313 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0<br>
7f2660f94000-7f2660f98000 rw-p 00000000 00:00 0<br>
7f2660f98000-7f2660f99000 r-xp 00000000 08:02 20975654 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/md5.so<br>
7f2660f99000-7f2661198000 ---p 00001000 08:02 20975654 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/md5.so<br>
7f2661198000-7f2661199000 r--p 00000000 08:02 20975654 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/md5.so<br>
7f2661199000-7f266119a000 rw-p 00001000 08:02 20975654 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/digest/md5.so<br>
7f266119a000-7f26611cc000 r-xp 00000000 08:02 20975741 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f26611cc000-7f26613cc000 ---p 00032000 08:02 20975741 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f26613cc000-7f26613cd000 r--p 00032000 08:02 20975741 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f26613cd000-7f26613ce000 rw-p 00033000 08:02 20975741 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f26613ce000-7f26613d0000 rw-p 00000000 00:00 0<br>
7f26613d0000-7f26613d5000 r-xp 00000000 08:02 20975744 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f26613d5000-7f26615d4000 ---p 00005000 08:02 20975744 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f26615d4000-7f26615d5000 r--p 00004000 08:02 20975744 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f26615d5000-7f26615d6000 rw-p 00005000 08:02 20975744 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f26615d6000-7f26615dd000 r-xp 00000000 08:02 20975728 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f26615dd000-7f26617dc000 ---p 00007000 08:02 20975728 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f26617dc000-7f26617dd000 r--p 00006000 08:02 20975728 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f26617dd000-7f26617de000 rw-p 00007000 08:02 20975728 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f26617de000-7f26617fe000 r-xp 00000000 08:02 20975635 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/libyaml-0.so.2.0.2<br>
7f26617fe000-7f26619fd000 ---p 00020000 08:02 20975635 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/libyaml-0.so.2.0.2<br>
7f26619fd000-7f26619fe000 r--p 0001f000 08:02 20975635 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/libyaml-0.so.2.0.2<br>
7f26619fe000-7f26619ff000 rw-p 00020000 08:02 20975635 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/libyaml-0.so.2.0.2<br>
7f26619ff000-7f2661a05000 r-xp 00000000 08:02 20975657 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f2661a05000-7f2661c04000 ---p 00006000 08:02 20975657 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f2661c04000-7f2661c05000 r--p 00005000 08:02 20975657 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f2661c05000-7f2661c06000 rw-p 00006000 08:02 20975657 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f2661c06000-7f2661c08000 r-xp 00000000 08:02 20975710 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f2661c08000-7f2661e08000 ---p 00002000 08:02 20975710 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f2661e08000-7f2661e09000 r--p 00002000 08:02 20975710 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f2661e09000-7f2661e0a000 rw-p 00003000 08:02 20975710 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f2661e0a000-7f2661e0c000 r-xp 00000000 08:02 20975693 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f2661e0c000-7f266200b000 ---p 00002000 08:02 20975693 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f266200b000-7f266200c000 r--p 00001000 08:02 20975693 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f266200c000-7f266200d000 rw-p 00002000 08:02 20975693 /home/trans/.local/lib/ry/rubies/1.9.3-p194/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f266200d000-7f26626f0000 r--p 00000000 08:02 8919290 /usr/lib/locale/locale-archive<br>
7f26626f0000-7f26628a3000 r-xp 00000000 08:02 24382961 /lib/x86_64-linux-gnu/libc-2.15.so<br>
7f26628a3000-7f2662aa2000 ---p 001b3000 08:02 24382961 /lib/x86_64-linux-gnu/libc-2.15.so<br>
7f2662aa2000-7f2662aa6000 r--p 001b2000 08:02 24382961 /lib/x86_64-linux-gnu/libc-2.15.so<br>
7f2662aa6000-7f2662aa8000 rw-p 001b6000 08:02 24382961 /lib/x86_64-linux-gnu/libc-2.15.so<br>
7f2662aa8000-7f2662aad000 rw-p 00000000 00:00 0<br>
7f2662aad000-7f2662ba6000 r-xp 00000000 08:02 24382993 /lib/x86_64-linux-gnu/libm-2.15.so<br>
7f2662ba6000-7f2662da5000 ---p 000f9000 08:02 24382993 /lib/x86_64-linux-gnu/libm-2.15.so<br>
7f2662da5000-7f2662da6000 r--p 000f8000 08:02 24382993 /lib/x86_64-linux-gnu/libm-2.15.so<br>
7f2662da6000-7f2662da7000 rw-p 000f9000 08:02 24382993 /lib/x86_64-linux-gnu/libm-2.15.so<br>
7f2662da7000-7f2662db0000 r-xp 00000000 08:02 24382969 /lib/x86_64-linux-gnu/libcrypt-2.15.so<br>
7f2662db0000-7f2662fb0000 ---p 00009000 08:02 24382969 /lib/x86_64-linux-gnu/libcrypt-2.15.so<br>
7f2662fb0000-7f2662fb1000 r--p 00009000 08:02 24382969 /lib/x86_64-linux-gnu/libcrypt-2.15.so<br>
7f2662fb1000-7f2662fb2000 rw-p 0000a000 08:02 24382969 /lib/x86_64-linux-gnu/libcrypt-2.15.so<br>
7f2662fb2000-7f2662fe0000 rw-p 00000000 00:00 0<br>
7f2662fe0000-7f2662fe2000 r-xp 00000000 08:02 24382974 /lib/x86_64-linux-gnu/libdl-2.15.so<br>
7f2662fe2000-7f26631e2000 ---p 00002000 08:02 24382974 /lib/x86_64-linux-gnu/libdl-2.15.so<br>
7f26631e2000-7f26631e3000 r--p 00002000 08:02 24382974 /lib/x86_64-linux-gnu/libdl-2.15.so<br>
7f26631e3000-7f26631e4000 rw-p 00003000 08:02 24382974 /lib/x86_64-linux-gnu/libdl-2.15.so<br>
7f26631e4000-7f26631eb000 r-xp 00000000 08:02 24383047 /lib/x86_64-linux-gnu/librt-2.15.so<br>
7f26631eb000-7f26633ea000 ---p 00007000 08:02 24383047 /lib/x86_64-linux-gnu/librt-2.15.so<br>
7f26633ea000-7f26633eb000 r--p 00006000 08:02 24383047 /lib/x86_64-linux-gnu/librt-2.15.so<br>
7f26633eb000-7f26633ec000 rw-p 00007000 08:02 24383047 /lib/x86_64-linux-gnu/librt-2.15.so<br>
7f26633ec000-7f2663404000 r-xp 00000000 08:02 24383041 /lib/x86_64-linux-gnu/libpthread-2.15.so<br>
7f2663404000-7f2663603000 ---p 00018000 08:02 24383041 /lib/x86_64-linux-gnu/libpthread-2.15.so<br>
7f2663603000-7f2663604000 r--p 00017000 08:02 24383041 /lib/x86_64-linux-gnu/libpthread-2.15.so<br>
7f2663604000-7f2663605000 rw-p 00018000 08:02 24383041 /lib/x86_64-linux-gnu/libpthread-2.15.so<br>
7f2663605000-7f2663609000 rw-p 00000000 00:00 0<br>
7f2663609000-7f266362b000 r-xp 00000000 08:02 24382941 /lib/x86_64-linux-gnu/ld-2.15.so<br>
7f2663686000-7f2663687000 ---p 00000000 00:00 0<br>
7f2663687000-7f266380d000 rw-p 00000000 00:00 0<br>
7f266381a000-7f266381c000 rw-p 00000000 00:00 0<br>
7f266381c000-7f266381d000 rwxp 00000000 00:00 0<br>
7f266381d000-7f2663824000 r--s 00000000 08:02 9177264 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache<br>
7f2663824000-7f2663825000 r-xp 00000000 00:00 0<br>
7f2663825000-7f2663826000 ---p 00000000 00:00 0<br>
7f2663826000-7f266382b000 rw-p 00000000 00:00 0<br>
7f266382b000-7f266382c000 r--p 00022000 08:02 24382941 /lib/x86_64-linux-gnu/ld-2.15.so<br>
7f266382c000-7f266382e000 rw-p 00023000 08:02 24382941 /lib/x86_64-linux-gnu/ld-2.15.so<br>
7fffb00fe000-7fffb0120000 rw-p 00000000 00:00 0 [stack]<br>
7fffb01ff000-7fffb0200000 r-xp 00000000 00:00 0 [vdso]<br>
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]</p>
<p>[NOTE]<br>
You may have encountered a bug in the Ruby interpreter or extension libraries.<br>
Bug reports are welcome.<br>
For details: <a href="http://www.ruby-lang.org/bugreport.html" class="external">http://www.ruby-lang.org/bugreport.html</a></p>
<p>Aborted (core dumped)<br>
=end</p> Ruby master - Feature #6678 (Rejected): Precedence of ^ operatorhttps://bugs.ruby-lang.org/issues/66782012-07-01T06:32:27Ztrans (Thomas Sawyer)
<p>I wrote about this here: <a href="http://trans.github.com/2009/12/13/a-failure-of-precedence.html" class="external">http://trans.github.com/2009/12/13/a-failure-of-precedence.html</a> (or <a href="https://github.com/trans/trans.github.com/wiki/2009-12-13-a-failure-of-precedence" class="external">https://github.com/trans/trans.github.com/wiki/2009-12-13-a-failure-of-precedence</a> if you prefer)</p>
<p>In short I would like to see <code>^</code> operator move up in precedence to be the same as <code>**</code>. We need another option besides <code>**</code> at the top of precedence list and <code>^</code> fits the bill well since many languages already think of it as "power of".</p>
<p>Of course, this has downside that effects current use for XOR definition. A new operator would be needed for that but <code>^</code> could alias it by default, so only thing that changes is precedence. Thankfully XOR is not among the most commonly used operators and often when used the precedence will be okay either way. So there should be very few cases where new operator or parenthesis will need to be put in.</p>
<p>Ultimately it would be great if precedence could be controlled on per-class basis. But that is big change, and might not be altogether practical. So I propose this one modest adjustment instead in which it would be an improvement.</p> Ruby master - Feature #6671 (Assigned): File.split_all and File.split_roothttps://bugs.ruby-lang.org/issues/66712012-06-30T04:28:57Ztrans (Thomas Sawyer)
<p>=begin<br>
Is there a method for this already?</p>
<p>File.split_all('a/b/c') #=> ['a','b','c']</p>
<p>If not I propose it be added. I've had need of such more than a few times.</p>
<p>It's too bad that File.split can't do this, as it would make more sense. And the current method be called <code>split_base</code>.</p>
<p>In addition <code>split_root</code> would be helpful.</p>
<p>root, path = File.split_all('a/b/c')<br>
root #=> 'a'<br>
path #=> 'b/c'<br>
=end</p> Ruby master - Feature #6646 (Closed): Objectified callerhttps://bugs.ruby-lang.org/issues/66462012-06-26T05:22:11Ztrans (Thomas Sawyer)
<p>In Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: [proposal] called_from() which is much faster than caller() (Closed)" href="https://bugs.ruby-lang.org/issues/3917">#3917</a> it is mentioned short-coming of caller:</p>
<ul>
<li>caller() returns an array of "filename:linenum in `method'" string.<br>
User must parse it and retrieve filename and linenum by rexp.<br>
It is also very heavy weight task.</li>
</ul>
<p>I think many have wished for objectified trace.</p>
<p>caller[0].file<br>
caller[0].line<br>
caller[0].in</p>
<p>Different method would be needed than #caller though to prevent backward compatibility issue.</p> Ruby master - Feature #6641 (Open): Hash.auto constructorhttps://bugs.ruby-lang.org/issues/66412012-06-25T09:34:06Ztrans (Thomas Sawyer)
<p>=begin<br>
It is not uncommon to need a Hash following the pattern:</p>
<p>Hash.new{ |h,k| h[k]={} }</p>
<p>Another common example:</p>
<p>Hash.new{ |h,k| h[k]=[] }</p>
<p>This is common enough that it would very nice if we could have a more concise form, e.g.</p>
<p>Hash.auto{ {} }</p>
<p>Or for the second example:</p>
<p>Hash.auto{ [] }</p>
<p>Pure Ruby implementation is pretty simple:</p>
<p>def Hash.auto<br>
Hash.new{ |h,k| h[k] = yield }<br>
end</p>
<p>I think it would be nice to have in Core.</p>
<p>This is secondary, but it just occurred to me. Could there even be a literal notation for the above? Something like:</p>
<p>{}([])</p>
<p>?<br>
=end</p> Ruby master - Feature #6609 (Closed): Toplevel as self extended modulehttps://bugs.ruby-lang.org/issues/66092012-06-19T21:58:57Ztrans (Thomas Sawyer)
<p>As promised sometime back here is my proposal that Toplevel object become a self-extended module instead of the current partial Object class proxy.</p>
<p>I have written about it in a blog post: <a href="http://trans.github.com/2012/06/17/kill-the-proxy-and-save-toplevel.html" class="external">http://trans.github.com/2012/06/17/kill-the-proxy-and-save-toplevel.html</a></p>
<p>In summary the basic idea is to have a special toplevel namespace that is self-extended, e.g.</p>
<p>module Toplevel<br>
extend self<br>
end</p>
<p>in which all toplevel code is evaluated.</p>
<p>Definitions at the toplevel would no longer inject into Object class. This frees up the toplevel to be used for general purpose DSL "batch" scripting. What I mean by that is that one can create a DSL, load it in to toplevel and then evaluate scripts based on it simply by load/require and without fret that the code loaded in will infect Object if it defines it's own methods.</p>
<p>Conceptually the idea of self-extended module is much simpler than current proxy object --there is really nothing special to understand about it since it is just a module like any other module.</p>
<p>With regard to backward compatibility, the only programs that would be effected are any that defined a toplevel method fully expecting it to add a method to Object. But those will be very rare since it is generally considered bad form to do that. (And of course the simple fix is to wrap the method in the proper <code>class Object private ... end</code> code.</p> Ruby master - Feature #6594 (Assigned): Integrated Functorhttps://bugs.ruby-lang.org/issues/65942012-06-15T09:02:38Ztrans (Thomas Sawyer)
<p>I know the developers meeting is coming up so I'd like to get a few ideas I've had sitting in the wings out in the air before then.</p>
<p>One the more useful is the idea of integrating Functors directly into the language. "Functor" is the term I use for "higher-order function".</p>
<p>I blogged about this idea and you can read it here: <a href="http://trans.github.com/2011-09-07-ruby-heart-higher-order-functions/" class="external">http://trans.github.com/2011-09-07-ruby-heart-higher-order-functions/</a></p>
<p>The super short version is this:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">def</span> <span class="nf">f</span> <span class="o">=></span> <span class="n">op</span><span class="p">,</span> <span class="n">arg</span>
<span class="n">arg</span><span class="p">.</span><span class="nf">send</span><span class="p">(</span><span class="n">__op__</span><span class="p">,</span> <span class="n">arg</span><span class="p">)</span>
<span class="k">end</span>
<span class="n">f</span> <span class="o">+</span> <span class="mi">3</span> <span class="c1">#=> 6</span>
<span class="n">f</span> <span class="o">*</span> <span class="mi">3</span> <span class="c1">#=> 9</span>
</code></pre>
<p>Another example:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">class</span> <span class="nc">String</span>
<span class="k">def</span> <span class="nf">file</span> <span class="o">=></span> <span class="n">op</span><span class="p">,</span> <span class="o">*</span><span class="n">args</span>
<span class="no">File</span><span class="p">.</span><span class="nf">send</span><span class="p">(</span><span class="n">__op__</span><span class="p">,</span> <span class="nb">self</span><span class="p">,</span> <span class="o">*</span><span class="n">args</span><span class="p">)</span>
<span class="k">end</span>
<span class="k">end</span>
<span class="s2">"README.rdoc"</span><span class="p">.</span><span class="nf">file</span><span class="p">.</span><span class="nf">mtime</span> <span class="c1">#=> 2012-06-14 12:34:45 -0400</span>
</code></pre>
<p>I'm using <code>=></code> as means of indicating a higher-order function. Of course another syntax could be used if this won't fly. The important thing is the idea of higher-order functions being integrated directly into the language. Doing this without that integration requires the creation of an intermediate object for each call which is very inefficient.</p> Ruby master - Feature #6507 (Feedback): File Literalhttps://bugs.ruby-lang.org/issues/65072012-05-28T02:03:35Ztrans (Thomas Sawyer)
<p>=begin<br>
One of the features of the Rebol programming language that I has always liked is its direct support for files via the (({%filename})) notation (See <a href="http://www.rebol.com/r3/docs/datatypes/file.html" class="external">http://www.rebol.com/r3/docs/datatypes/file.html</a>). I've often wondered how Ruby might support the same, but finding a suitable and available notation proved rather difficult.</p>
<p>Today it occurred to me that perhaps the <code>/</code> symbol could do the trick:</p>
<p>file = /README.rdoc</p>
<p>For absolute paths it could be <code>//</code>:</p>
<p>file = //etc/fstab</p>
<p>Exactly what class of object (({file})) should be is up for debate. Probably it would be a (({Pathname})) instance, but I suppose it could a different "Path" class basically a wrapper round (({File})) and (({Dir})) classes.</p>
<p>The benefit of this is fairly obvious I think, but I'll give one clear usecase just the same:</p>
<p>class Foo<br>
def initialize(source)<br>
case source<br>
when String<br>
parse(source)<br>
when Pathname # assuming this to be the instance<br>
parse(source.read)<br>
end<br>
end<br>
end</p>
<a name="from-string"></a>
<h1 >from string<a href="#from-string" class="wiki-anchor">¶</a></h1>
<p>Foo.new "content of foo"</p>
<a name="from-file"></a>
<h1 >from file<a href="#from-file" class="wiki-anchor">¶</a></h1>
<p>Foo.new /foo.txt</p>
<p>There is the ambiguity of <code>x /a</code> for division, but I think expecting <code>x/a</code> or <code>x / a</code> for that is okay. After all, the same limitation holds for other unary operators too.</p>
<p>Actually, while I like the concise notation, it may be more flexible to require a string:</p>
<p>/'foo.txt'</p>
<p>Then <code>/</code> could actually be a unary operator.</p>
<p>In anycase, whether this notation works or not, I hope this spurs some debate so that ultimately something along these lines will come of it. I truly tire of typing things like (({File.read(File.join(File.dirname(<strong>FILE</strong>), fname))})).<br>
=end</p> Ruby master - Feature #6478 (Feedback): BasicObject#__class__https://bugs.ruby-lang.org/issues/64782012-05-22T22:05:42Ztrans (Thomas Sawyer)
<p>How else is one supposed to get the class of a subclass of BasicObject?</p> Ruby master - Feature #6442 (Feedback): CRUDify Hash classhttps://bugs.ruby-lang.org/issues/64422012-05-17T01:07:20Ztrans (Thomas Sawyer)
<p>Ruby's Hash class is not very internally "connascent" --many different methods access the underlying data. There is no core set of specific methods that can be overridden to handle all cases. This leads to a very unDRY and bloated class when subclassing or delegating. If Ruby's Hash could be modified to follow essentially a CRUD model, with single points-of-entry for the creation, reading, updating and deletion of entries, and all other methods route through these core methods for access to the underlying data, then it would be much easier to subclass and delegate, and make the Hash class much more solid in design.</p>
<p>I believe the core methods needed are: <code>read(key)</code>, <code>store(key,value)</code>, <code>delete(key)</code> as well as <code>key?(key)</code> and <code>keys</code>.</p> Ruby master - Bug #6434 (Rejected): Block passed implicitly via superhttps://bugs.ruby-lang.org/issues/64342012-05-15T02:58:00Ztrans (Thomas Sawyer)
<p>=begin<br>
Block is being passed via super implicitly even though the method is explicit and does not pass the block when calling super.</p>
<pre><code>class H < Hash
def initialize(default=nil, &block)
super(default)
end
end
H.new(0){}
ArgumentError: wrong number of arguments
from (pry):3:in `initialize'
</code></pre>
<p>Hash#initialize doesn't allow both a default argument and a default_proc, which is the cause of this error. Which means the block is being passed up even though it should not be.<br>
=end</p> Ruby master - Bug #6425 (Closed): Psych issue with !!omaphttps://bugs.ruby-lang.org/issues/64252012-05-12T04:55:07Ztrans (Thomas Sawyer)
<p>=begin</p>
<p>Psych doesn't seem to know ordered map. It parses fine, but loose the type when round-tripped.</p>
<h2>a = YAML.load %{<br>
--- !!omap<br>
a: 1<br>
b: 2<br>
}<br>
=> {"a"=>1, "b"=>2}<br>
a.class<br>
=> Hash<br>
puts a.to_yaml</h2>
<p>a: 1<br>
b: 2</p>
<p>=end</p> Backport193 - Backport #6377 (Closed): $LOADED_FEATURES entry via YAML is binary data?https://bugs.ruby-lang.org/issues/63772012-04-29T07:14:45Ztrans (Thomas Sawyer)
<p>=begin<br>
While working with $LOADED_FEATURES, came across this odd result:</p>
<p>trans@logisys:courtier$ irb</p>
<p>irb(main):001:0> require 'yaml'</p>
<p>irb(main):002:0> puts $LOADED_FEATURES.join("\n")<br>
enumerator.so<br>
/home/trans/.local/lib/ry/rubies/1.9.3-p125/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
/home/trans/.local/lib/ry/rubies/1.9.3-p125/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
/home/trans/.local/lib/ry/rubies/1.9.3-p125/lib/ruby/1.9.1/rubygems/defaults.rb<br>
...</p>
<a name="irbmain0030gt-y-LOADED_FEATURES"></a>
<h2 >irb(main):003:0> y $LOADED_FEATURES<a href="#irbmain0030gt-y-LOADED_FEATURES" class="wiki-anchor">¶</a></h2>
<ul>
<li>enumerator.so</li>
<li>!binary |-<br>
L2hvbWUvdHJhbnMvLmxvY2FsL2xpYi9yeS9ydWJpZXMvMS45LjMtcDEyNS9s<br>
aWIvcnVieS8xLjkuMS94ODZfNjQtbGludXgvZW5jL2VuY2RiLnNv</li>
<li>/home/trans/.local/lib/ry/rubies/1.9.3-p125/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so</li>
<li>/home/trans/.local/lib/ry/rubies/1.9.3-p125/lib/ruby/1.9.1/rubygems/defaults.rb<br>
...</li>
</ul>
<p>=end</p> Ruby master - Feature #6376 (Assigned): Feature lookup and checking if feature is loadedhttps://bugs.ruby-lang.org/issues/63762012-04-29T07:03:40Ztrans (Thomas Sawyer)
<p>$LOADED_FEATURES is useful to know what "files" have been loaded. But it doesn't really tell us what "features" have been loaded. If there where were a way to look-up a load path, without actually loading it then it would be possible to compare that to $LOADED_FEATURES and thus know. e.g.</p>
<pre><code>require 'ostruct'
$LOADED_FEATURES #=> [..., "/home/trans/.local/lib/ry/rubies/1.9.3-p125/lib/ruby/1.9.1/ostruct.rb"]
path = require_path('ostruct') #=> "/home/trans/.local/lib/ry/rubies/1.9.3-p125/lib/ruby/1.9.1/ostruct.rb"
$LOADED_FEATURES.include?(path)
</code></pre>
<p>Of course, it would be nice to also have:</p>
<pre><code>required?('ostruct') #=> true
</code></pre>
<p>These methods could be class methods of special module, if it's important to keep the Kernel more tidy, e.g. <code>Ruby.required?('ostruct')</code>.</p>
<p>I am currently working on a project where I need this (and have a couple of other projects that could use it too) and I've had to implement the whole thing from scratch, which isn't simple, nor fast, nor am I 100% confident that it specs exactly to Ruby's own lookup procedure. So it would be much better if Ruby would expose its lookup functionality.</p> Ruby master - Feature #6373 (Closed): public #selfhttps://bugs.ruby-lang.org/issues/63732012-04-28T06:46:11Ztrans (Thomas Sawyer)
<p>This was recently suggested to me as an extension:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">class</span> <span class="nc">Object</span>
<span class="c1"># An identity method that provides access to an object's 'self'.</span>
<span class="c1">#</span>
<span class="c1"># Example:</span>
<span class="c1"># [1,2,3,4,5,1,2,2,3].group_by(&:identity)</span>
<span class="c1"># #=> {1=>[1, 1], 2=>[2, 2, 2], 3=>[3, 3], 4=>[4], 5=>[5]}</span>
<span class="c1">#</span>
<span class="k">def</span> <span class="nf">identity</span>
<span class="nb">self</span>
<span class="k">end</span>
<span class="k">end</span>
</code></pre>
<p>First, is such a method commonly useful enough to warrant existence?</p>
<p>Second, it makes me wonder if #self should be a public method in general.</p> Ruby master - Feature #6372 (Rejected): More specific error for uncaught throwhttps://bugs.ruby-lang.org/issues/63722012-04-28T04:09:12Ztrans (Thomas Sawyer)
<p>I have this method:</p>
<p>=begin<br>
class Symbol<br>
# Does the block throw the symbol?<br>
#<br>
def thrown?<br>
catch(self) do<br>
begin<br>
yield<br>
true<br>
rescue ArgumentError => err # 1.9 exception<br>
false<br>
rescue NameError => err # 1.8 exception<br>
false<br>
end<br>
end<br>
end<br>
end<br>
=end</p>
<p>But it was recently pointed out to me that the rescue of ArgumentError and NameError is not good enough b/c they might rescue an unrelated error of the same type. So to make this right there needs to be a more specific error. Perhaps <code>class ThrowError < ArgumentError</code>.</p> Ruby master - Feature #6337 (Assigned): FileUtils#synchttps://bugs.ruby-lang.org/issues/63372012-04-22T09:13:25Ztrans (Thomas Sawyer)
<p>=begin<br>
I'd like to see some sort of FileUtils#sync method to sync the contents of one directory with another.</p>
<p>Here is a prototype definition:</p>
<pre><code>#
# Synchronize a destination directory with a source directory.
#
def sync(src, dst, options={})
src_files = Dir[File.join(src, '**', '*')].map{ |f| f.sub(src+'/', '') }
dst_files = Dir[File.join(dst, '**', '*')].map{ |f| f.sub(dst+'/', '') }
removal = dst_files - src_files
rm_dirs, rm_files = [], []
removal.each do |f|
path = File.join(dst, f)
if File.directory?(path)
rm_dirs << path
else
rm_files << path
end
end
rm_files.each { |f| rm(f) }
rm_dirs.each { |d| rmdir(d) }
src_files.each do |f|
src_path = File.join(src, f)
dst_path = File.join(dst, f)
if File.directory?(src_path)
mkdir_p(dst_path)
else
parent = File.dirname(dst_path)
mkdir_p(parent) unless File.directory?(parent)
install(src_path, dst_path)
end
end
end
</code></pre>
<p>I haven't tested this beyond a simple trial. It needs improvement. For one, it probably should be able to handle regular files as arguments too. It also needs to handle verbose and dryrun options properly. Nonetheless, with improvements, would be okay for such to become new feature for FileUtils?</p>
<p>=end</p> Ruby master - Feature #6305 (Rejected): Lazyhttps://bugs.ruby-lang.org/issues/63052012-04-17T04:39:04Ztrans (Thomas Sawyer)
<p>I believe we discussed before but I couldn't find the issue, so I'll just bring it up again.</p>
<p>Might MenTaLguY's Lazy library make it's way into Ruby proper?</p>
<p><a href="http://moonbase.rydia.net/software/lazy.rb/" class="external">http://moonbase.rydia.net/software/lazy.rb/</a></p>
<p><a href="https://github.com/mental/lazy" class="external">https://github.com/mental/lazy</a></p> Ruby master - Feature #6298 (Rejected): Proc#+https://bugs.ruby-lang.org/issues/62982012-04-15T17:31:29Ztrans (Thomas Sawyer)
<p>=begin<br>
Maybe there is another way to do this, and if so please enlighten me.</p>
<p>I have a case where collection of blocks need to be handled as if a single block, e.g.</p>
<p>class BlockCollection<br>
def initialize(*procs)<br>
@procs = procs<br>
end<br>
def to_proc<br>
procs = @procs<br>
Proc.new{ |*a| procs.each{ |p| p.call(*a) } }<br>
end<br>
end</p>
<p>The issue with this is with #to_proc. It's not going to do the right thing if a BlockCollection instance is passed to #instance_eval b/c it would not actually be evaluating each internal block via #instance_eval.</p>
<p>But if we change it to:</p>
<pre><code>def to_proc
Proc.new{ |*a| procs.each{ |p| instance_exec(*a, &p) } }
end
</code></pre>
<p>It would do the right thing with #instance_eval, but it would no longer do the right thing for #call, b/c would it evaluate in the context of BlockCollection instance instead of where the blocks weer defined.</p>
<p>So, unless there is some way to do this that I do not see, to handle this Ruby would have to provide some means for it. To this end Proc#+ is a possible candidate which could truly combine two procs into one.<br>
=end</p> Ruby master - Feature #6277 (Assigned): Hash#convert_keyhttps://bugs.ruby-lang.org/issues/62772012-04-11T01:12:20Ztrans (Thomas Sawyer)
<p>=begin<br>
Many times a hash with uniform keys is needed (or is at least preferable) for a particular usecase. To this end I propose ((%Hash#convert_key%)).</p>
<p>h = {}<br>
h.convert_key{ |k| k.to_sym }<br>
h['a'] = 1<br>
h.update('b'=>2)<br>
h #=> {:a=>1, :b=>2}</p>
<p>The idea is similar in concept to ((%#default_proc%)).</p>
<p>Others solutions to fill this need have been tried and used, but almost exclusively are in the form of a new class. Most notable is Rails HashWithIndifferentAccess. But ((%#convert_key%)) has much greater flexibility since keys can be converted to anything.<br>
=end</p> Ruby master - Feature #6263 (Feedback): Simple access to toplevel object (main)https://bugs.ruby-lang.org/issues/62632012-04-06T05:25:17Ztrans (Thomas Sawyer)
<p>=begin<br>
Maybe I miss something, but why is there no way to get toplevel object easily. Only way seems<br>
to be:</p>
<pre><code>main = eval('self', TOPLEVEL_BINDING)
</code></pre>
<p>Would be nice if there were a simple way, maybe special global <code>(({$main}))</code> would be good choice.<br>
=end</p> Ruby master - Feature #6243 (Rejected): Make ERB Ruby's Super Powerhttps://bugs.ruby-lang.org/issues/62432012-04-02T06:31:37Ztrans (Thomas Sawyer)
<p>As a Super Ruby Developer<br>
I want to make Ruby Super Developery<br>
Given wimpy Ruby, coding is arduous:</p>
<p>class Letters<br>
def a<br>
"Aa"<br>
end</p>
<pre><code>def b
"Bb"
end
# Oh, dear St. V! It's just too long. I don't want to go on!
</code></pre>
<p>Then Super Ruby saves the day!</p>
<p>class Letters<br>
<%= ('a'...'z').each do |letter| %><br>
def <%= letter %><br>
"<%= letter.upcase %><%= letter %>"<br>
end<br>
<% end %><br>
end</p>
<p>letters = Letters.new</p>
<p>letters.a #=> "Aa"<br>
letters.b #=> "Bb"</p>
<p>Imagine the power of <code>Ruby ** Ruby</code>! It's like putting Ruby in a phone booth and out pops Ruby with big <s> on chest. And like that, Super Ruby destroys all super villain languages like PHP!</s></p>
<p>And you can't reject b/c this issue is all Gherkin which makes it legit.</p> Ruby master - Feature #6225 (Rejected): Hash#+https://bugs.ruby-lang.org/issues/62252012-03-30T08:19:01Ztrans (Thomas Sawyer)
<p>Strings and Arrays can be combined with #+. I don't see any reason not to allow Hashes to do so as well.</p>
<p>class Hash<br>
alias :+ :merge<br>
end</p> Ruby master - Feature #6176 (Rejected): Allow Enumerable#flatten to take a blockhttps://bugs.ruby-lang.org/issues/61762012-03-20T00:31:20Ztrans (Thomas Sawyer)
<p>I see a new method <code>#flat_map</code> has been added to Enumerable. Yet passing a block to #flatten has no use. That seems a waste, as it adds yet another method to remember when one we already know can do the job and makes sense.</p> Ruby master - Feature #6166 (Rejected): Enumerator::Lazy#pinchhttps://bugs.ruby-lang.org/issues/61662012-03-18T00:47:49Ztrans (Thomas Sawyer)
<p>In previous issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Enumerator::Lazy#take: should it be lazy? (Closed)" href="https://bugs.ruby-lang.org/issues/6158">#6158</a> it has been determined that Enumerator::Lazy#take should be lazy. But an eager form of #take would still be useful.</p>
<p>To this end I'll suggest <code>Enumerator::Lazy#pinch</code>. Examples of usage:</p>
<pre><code>e.lazy.pinch 1
e.lazy.pinch 1..2
e.lazy.pinch 1,2
</code></pre>
<p>It is basically equivalent to calling <code>to_a[index]</code>, but has the advantage of being a single invocation instead of two, and reads better.</p>
<p>The #pinch method would be strictly a Lazy method and have no counterpart in Enumerable.</p> Ruby master - Bug #6151 (Closed): ArgumentError of lambda shows wrong locationhttps://bugs.ruby-lang.org/issues/61512012-03-16T06:08:38Ztrans (Thomas Sawyer)
<p>=begin</p>
<p>Perhaps there is a reason, but it sure seems like a bug to me. Given this simple class:</p>
<pre><code> #
class BlockParser < BasicObject
def initialize(data={}, &block)
@data = data
instance_eval(&block)
end
def method_missing(name, *args, &block)
if block
@data[name] = {}
BlockParser.new(@data[name], &block)
else
case args.size
when 0
@data[name]
when 1
@data[name] = args.first
else
@data[name] = args
end
end
end
end
</code></pre>
<p>Then we can do:</p>
<pre><code> data = {}
BlockParser.new(data) do
name 'Tommy'
end
data #=> {:name=>'Tommy'}
</code></pre>
<p>But,</p>
<pre><code> data = {}
blk = lambda do
name 'Tommy'
end
BlockParser.new(data, &blk)
ArgumentError: wrong number of arguments (1 for 0)
from (irb):44:in `block in irb_binding'
from (irb):16:in `instance_eval'
from (irb):16:in `initialize'
from (irb):46:in `new'
from (irb):46
from /home/trans/.rbfu/rubies/1.9.3-p0/bin/irb:12:in `<main>'
</code></pre>
<p>If I use (({Proc.new})) instead of (({lambda})) it works. But since I am using (({#instance_eval})) to evaluate the Proc, that shouldn't matter.</p>
<p>Note the reported line number of the error corresponds to (({name 'Tommy'})).<br>
=end</p> Ruby master - Feature #6130 (Closed): inspect using to_s is painhttps://bugs.ruby-lang.org/issues/61302012-03-12T08:21:54Ztrans (Thomas Sawyer)
<p>Every time I define #to_s on a class I have to remember to also redefine #inspect. It's annoying and has led me to waste hours debugging b/c the errors that can occur from it often seem strange and unrelated.</p>
<p>I think #inspect should have an independent definition that outputs the class name, object_id and when possible instance variable settings, and should have nothing to do with #to_s by default. We developers can always alias it as such if it is appropriate.</p>
<p>The only exception should be for classes that have literal representation in Ruby, such as Array, String, Hash, etc. In those cases the #inspect should give the literal representation.</p> Ruby master - Feature #6074 (Rejected): Allow alias arguments to have a commahttps://bugs.ruby-lang.org/issues/60742012-02-24T20:31:32Ztrans (Thomas Sawyer)
<p>This is one my biggest pet peeves with Ruby. I am always typing:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">alias</span> <span class="ss">:foo</span><span class="p">,</span> <span class="ss">:bar</span>
</code></pre>
<p>And getting a damn syntax error.</p>
<p>Btw, is there a reason why <code>alias</code> is a keyword and not a method?</p> Ruby master - Feature #6056 (Closed): Enhancements to OpenStructhttps://bugs.ruby-lang.org/issues/60562012-02-21T23:16:55Ztrans (Thomas Sawyer)
<p>This patch fixes one issue, protecting #new_ostruct_member method, and possibly another by dup'ing marshal_dump, but I need more feedback on the later b/c I've also been told it is not needed.</p>
<p>The rest of this patch provides enhancements to OpenStruct that I feel are sorely needed, these include access via [] and []=, ability to mass update via merge!, minimal polymorphism with Hash and the addition of equality methods, eql? and ==.</p>
<p><a href="https://github.com/ruby/ruby/pull/95" class="external">https://github.com/ruby/ruby/pull/95</a></p>
<p>I'd also like opinions on further enhancements:</p>
<ul>
<li>adding #each and #each_pair</li>
<li>making OpenStruct a subclass of BasicObject</li>
</ul> Ruby master - Bug #5978 (Closed): YAML.load_stream should process documents as they are readhttps://bugs.ruby-lang.org/issues/59782012-02-08T01:47:30Ztrans (Thomas Sawyer)
<p>Psych say YAML.load_documents is deprecated and say to use <code>YAML.load_stream</code> instead.</p>
<p>Looking at the implementation for <code>load_stream()</code>, looks to me as if it waits for all documents in the stream to load before anything can be done with it.</p>
<pre><code># File 'lib/psych.rb', line 221
def self.load_stream yaml
parse_stream(yaml).children.map { |child| child.to_ruby }
end
</code></pre>
<p>I don't think this should be the case. Ideally <code>load_stream()</code> would take a block, and if an IO object is given, read a document, yield it and then read the next document, and so on.</p>
<p>I imagine an Enumerator might be applicable to this as well.</p> Ruby master - Feature #5922 (Rejected): Migrate equal? to identical?https://bugs.ruby-lang.org/issues/59222012-01-22T01:36:09Ztrans (Thomas Sawyer)
<p>From Ruby docs: "the equal? method should never be overridden by subclasses: it is used to determine object identity (that is, a.equal?(b) iff a is the same object as b)."</p>
<p>I think it would make more sense to name such a method <code>#identical?</code>, since that is what it is doing --<em>comparing identity</em>. Over a sufficient period of time the current use of <code>#equal?</code> can be deprecated and possibly made better use of with a different definition. I realize this is not a minor change. This transition would probably be much like the one from #id to #object_id.</p>
<p>The reason I propose this, and why it is an issue for myself, is in of the design of assertion frameworks. For example, #assert_equal is a comparison of #==, not #equal?. We run into this naming conundrum and end up having to use assertion names that don't correspond well to the names of the underlying comparison. So that's the practical reason. But formally speaking, I think #identical? also better b/c it is more precise.</p> Ruby master - Feature #5898 (Rejected): raise and Exception#initializehttps://bugs.ruby-lang.org/issues/58982012-01-16T10:03:55Ztrans (Thomas Sawyer)
<p>Calling <code>#raise</code> with a <code>message</code> parameter passes the argument on the Exception class' initialize method. But it does not support any additional arguments if the initialize method has been defined otherwise. Nor is the last optional argument, <code>caller</code>, passed to the initializer. All of which makes for a rather confusing mishmash of an interface between <code>#raise</code> and <code>Exception#initialize</code>.</p>
<p>Ideally I would think whatever arguments are passed to <code>#raise</code> would likewise be passed on to <code>Exception#initialize</code>, e.g.</p>
<p>class MyError < Exception<br>
def initialize(a,b)<br>
super("#{a} and #{b}")<br>
end<br>
end</p>
<p>raise MyError, 'foo', 'bar'</p>
<p>Alas, because <code>caller</code> can be passed to <code>#raise</code> this causes an error, as it thinks <code>bar</code> ought to be the caller array. So unless others see a way around it that I do not, this idealized scenario simply is not possible.</p>
<p>So I propose a second best approach. Notice that if <code>caller</code> is passed to <code>#raise</code> it is not being passed on to the <code>#initialize</code> method unlike the <code>message</code> argument. Instead <code>#set_backtrace</code> is being used to set the caller. I propose that the <code>message</code> argument be handled in the same way, and a new method <code>#set_message(msg)</code> be added to the <code>Exception</code> class to handle it.</p>
<p>This would then allow the initializer of subclasses to be freed up to be defined in other ways, should a specialized exception be able to make good use of a variant interface Which, btw, is the exact circumstance I presently find myself in for one of my projects. Consequently I had no choice by to define the #initialize method to take an initial blank argument that will almost always be set to +nil+.</p> Ruby master - Feature #5866 (Rejected): ValidationErrorhttps://bugs.ruby-lang.org/issues/58662012-01-08T21:57:34Ztrans (Thomas Sawyer)
<p>I've come across this from time to time, where some piece of complex data, often (but not always) loaded from a file, doesn't conform to some set of validation requirements. I've never been quite sure what type of error to throw if the data doesn't conform. It's not exactly an ArgumentError, it's more complex then that and not necessarily coming in via method arguments, nor is it exactly a TypeError since it's not necessarily anything to do with a specific class. So I find myself falling back to Runtime error and rolling my own, but thinking it would be nice if there were a general purpose <code>ValidationError</code> to raise or subclass in these cases.</p> Ruby master - Feature #5805 (Feedback): object_hexidhttps://bugs.ruby-lang.org/issues/58052011-12-25T00:22:36Ztrans (Thomas Sawyer)
<p>I would like to see #object_hexid added to Ruby to return an object's id in hexidecimal form.</p>
<p>By default Ruby will show this id when using #inspect.</p>
<p>Object.new.inspect<br>
=> "#<a href="Object:0x000000023cadf0" class="external">Object:0x000000023cadf0</a>"</p>
<p>I, for one, have often wanted to include this hex id when I customize an #inspect method for a class. But despite my lengthy efforts I have never been able to ensure the hex id is correct. It seems to vary a great deal depending on platform and Ruby version.</p>
<p>You can see the current effort at this here: <a href="https://github.com/rubyworks/facets/blob/master/lib/core/facets/kernel/object_hexid.rb" class="external">https://github.com/rubyworks/facets/blob/master/lib/core/facets/kernel/object_hexid.rb</a> But this definition is currently failing on Ruby 1.8.7 and JRuby. I have tried a number of variations, but nothing sees to work for all platforms.</p>
<p>My last ditch approach will be to bind Kernel#inspect InstanceMethod to the current object and extract the hex id from it's output. It should work, but it's definitely a hack. In the future I'd much rather just ask Ruby for it!</p> Ruby master - Feature #5781 (Assigned): Query attributes (attribute methods ending in `?` mark)https://bugs.ruby-lang.org/issues/57812011-12-20T04:57:11Ztrans (Thomas Sawyer)
<p>Pretty sure this has come up before, but I'd like to revisit b/c I don't understand why it isn't allowed.</p>
<p>Sometimes I define "query" attributes, and in those cases I'd like the reader method to end in a <code>?</code> mark. Currently I have to do:</p>
<pre><code># @attribute
def foo?
@foo
end
</code></pre>
<p>or, if I don't mind a shadowing bare method,</p>
<pre><code>attr :foo
alias_method :foo?, :foo
</code></pre>
<p>So why not just allow:</p>
<pre><code>attr :foo?
</code></pre>
<p>Currently this causes an error. But why? It just seems like a waste of potentially cleaner code.</p> Ruby master - Bug #5759 (Rejected): flatten calls to_ary on everythinghttps://bugs.ruby-lang.org/issues/57592011-12-14T08:55:33Ztrans (Thomas Sawyer)
<p>I often ensure that I have an array by doing:</p>
<p>def foo=(x)<br>
@foo = [x].flatten<br>
end</p>
<p>But this has turned into a problem as of late, as it seems #flatten is calling #to_ary on every element in the array, and apparently catching the error raised if #to_ary isn't defined for that object. But that causes potential issues with objects that use #method_missing. I think #flatten should use <code>respond_to?(:to_ary)</code> to make sure an object can handle it before actually calling it.</p> Ruby master - Feature #5673 (Feedback): undef_method probably doesn't need to raise an errorhttps://bugs.ruby-lang.org/issues/56732011-11-26T12:33:07Ztrans (Thomas Sawyer)
<p>Is there any significant reason for #undef_method to raise an error if the method is already undefined? If no, then change it to just continue on. It can return true/false to relay if was undefined vs already undefined.</p> Ruby master - Feature #5643 (Assigned): require/load options and binding optionhttps://bugs.ruby-lang.org/issues/56432011-11-17T07:41:01Ztrans (Thomas Sawyer)
<p>Current Kernel#load is defined as:</p>
<pre><code>load(filename, wrap=false)
</code></pre>
<p>I purpose that it be modified to work as option argument, e.g.</p>
<pre><code>load(filename, :wrap=>true)
</code></pre>
<p>Right off the bat this has better name connascence.</p>
<p>Then support an additional option <code>:binding</code>, such that, given:</p>
<pre><code>$ cat lib/example.rb
def a
1
end
</code></pre>
<p>then</p>
<pre><code>class X
load('example.rb', :binding=>binding)
end
X.new.a #=> 1
</code></pre>
<p>The binding option should also work with #require (which would also support option parameter) differing from #load in the it would only allow the feature to be loaded once per-binding's self regardless of being required again.</p>
<p>This ability would greatly benefit systems that need "plugin" capability. Presently, a great deal of coding has to go into simulating this functionality to create plugin systems, which are often imperfect nor robust.</p> Backport193 - Backport #5634 (Closed): yield and bindinghttps://bugs.ruby-lang.org/issues/56342011-11-15T03:50:31Ztrans (Thomas Sawyer)
<p>Per my recent question on ruby-core... "well there's your problem":</p>
<blockquote>
<blockquote>
<p>def x<br>
binding<br>
end<br>
=> nil<br>
b = x{|a|a+a}<br>
=> #<a href="Binding:0x0000000103f1a0" class="external">Binding:0x0000000103f1a0</a><br>
b.eval('yield(2)')</p>
</blockquote>
</blockquote>
<p>(irb):2: [BUG] Segmentation fault<br>
ruby 1.9.3dev (2011-09-23 revision 33323) [x86_64-linux]</p>
<p>-- Control frame information -----------------------------------------------<br>
c:0026 p:0007 s:0091 b:0090 l:001ff8 d:000089 EVAL (irb):2<br>
c:0025 p:---- s:0088 b:0088 l:000087 d:000087 FINISH<br>
c:0024 p:---- s:0086 b:0086 l:000085 d:000085 CFUNC :eval<br>
c:0023 p:0013 s:0082 b:0082 l:0009a8 d:000081 EVAL (irb):6<br>
c:0022 p:---- s:0080 b:0080 l:000079 d:000079 FINISH<br>
c:0021 p:---- s:0078 b:0078 l:000077 d:000077 CFUNC :eval<br>
c:0020 p:0028 s:0071 b:0071 l:000070 d:000070 METHOD /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/workspace.rb:80<br>
c:0019 p:0033 s:0064 b:0063 l:000062 d:000062 METHOD /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/context.rb:254<br>
c:0018 p:0031 s:0058 b:0058 l:000a28 d:000057 BLOCK /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:159<br>
c:0017 p:0042 s:0050 b:0050 l:000049 d:000049 METHOD /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:273<br>
c:0016 p:0011 s:0045 b:0045 l:000a28 d:000044 BLOCK /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:156<br>
c:0015 p:0144 s:0041 b:0041 l:000024 d:000040 BLOCK /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-lex.rb:243<br>
c:0014 p:---- s:0038 b:0038 l:000037 d:000037 FINISH<br>
c:0013 p:---- s:0036 b:0036 l:000035 d:000035 CFUNC :loop<br>
c:0012 p:0009 s:0033 b:0033 l:000024 d:000032 BLOCK /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-lex.rb:229<br>
c:0011 p:---- s:0031 b:0031 l:000030 d:000030 FINISH<br>
c:0010 p:---- s:0029 b:0029 l:000028 d:000028 CFUNC :catch<br>
c:0009 p:0023 s:0025 b:0025 l:000024 d:000024 METHOD /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-lex.rb:228<br>
c:0008 p:0046 s:0022 b:0022 l:000a28 d:000a28 METHOD /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:155<br>
c:0007 p:0011 s:0019 b:0019 l:000658 d:000018 BLOCK /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:70<br>
c:0006 p:---- s:0017 b:0017 l:000016 d:000016 FINISH<br>
c:0005 p:---- s:0015 b:0015 l:000014 d:000014 CFUNC :catch<br>
c:0004 p:0183 s:0011 b:0011 l:000658 d:000658 METHOD /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:69<br>
c:0003 p:0039 s:0006 b:0006 l:0007a8 d:001e18 EVAL /home/trans/.rbenv/versions/1.9.3-rc1/bin/irb:12<br>
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH<br>
c:0001 p:0000 s:0002 b:0002 l:0007a8 d:0007a8 TOP</p>
<p>-- Ruby level backtrace information ----------------------------------------<br>
/home/trans/.rbenv/versions/1.9.3-rc1/bin/irb:12:in <code><main>' /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:69:in </code>start'<br>
/home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:69:in <code>catch' /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:70:in </code>block in start'<br>
/home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:155:in <code>eval_input' /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in </code>each_top_level_statement'<br>
/home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in <code>catch' /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in </code>block in each_top_level_statement'<br>
/home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in <code>loop' /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-lex.rb:243:in </code>block (2 levels) in each_top_level_statement'<br>
/home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:156:in <code>block in eval_input' /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:273:in </code>signal_status'<br>
/home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb:159:in <code>block (2 levels) in eval_input' /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/context.rb:254:in </code>evaluate'<br>
/home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/workspace.rb:80:in <code>evaluate' /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/workspace.rb:80:in </code>eval'<br>
(irb):6:in <code>irb_binding' (irb):6:in </code>eval'<br>
(irb):2:in `x'</p>
<p>-- C level backtrace information -------------------------------------------<br>
irb() [0x526f18]<br>
irb() [0x56ecb8]<br>
irb(rb_bug+0xb3) [0x56ee53]<br>
irb() [0x4b42b0]<br>
/lib/libpthread.so.0(+0xf8f0) [0x7f8c9f5d38f0]<br>
irb() [0x517a16]<br>
irb() [0x51ba3b]<br>
irb() [0x51c4da]<br>
irb() [0x51ca86]<br>
irb() [0x41ac06]<br>
irb() [0x52072e]<br>
irb() [0x5178d7]<br>
irb() [0x51ba3b]<br>
irb() [0x51c4da]<br>
irb() [0x51ca86]<br>
irb() [0x52072e]<br>
irb() [0x5178d7]<br>
irb() [0x51ba3b]<br>
irb() [0x526259]<br>
irb(rb_rescue2+0x15b) [0x417b9b]<br>
irb() [0x5119c9]<br>
irb() [0x52072e]<br>
irb() [0x5178d7]<br>
irb() [0x51ba3b]<br>
irb() [0x51eb0e]<br>
irb(rb_catch_obj+0xbe) [0x51082e]<br>
irb() [0x51161a]<br>
irb() [0x52072e]<br>
irb() [0x5178d7]<br>
irb() [0x51ba3b]<br>
irb() [0x51eb0e]<br>
irb(rb_catch_obj+0xbe) [0x51082e]<br>
irb() [0x51161a]<br>
irb() [0x52072e]<br>
irb() [0x5178d7]<br>
irb() [0x51ba3b]<br>
irb(rb_iseq_eval_main+0x292) [0x51be72]<br>
irb() [0x417f32]<br>
irb(ruby_run_node+0x36) [0x419ff6]<br>
irb() [0x4170d9]<br>
/lib/libc.so.6(__libc_start_main+0xfd) [0x7f8c9e997c4d]<br>
irb() [0x416fc9]</p>
<p>-- Other runtime information -----------------------------------------------</p>
<ul>
<li>
<p>Loaded script: irb</p>
</li>
<li>
<p>Loaded features:</p>
<p>0 enumerator.so<br>
1 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
2 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
3 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/defaults.rb<br>
4 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/rbconfig.rb<br>
5 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/deprecate.rb<br>
6 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/exceptions.rb<br>
7 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/custom_require.rb<br>
8 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems.rb<br>
9 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
10 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
11 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/nodes/node.rb<br>
12 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/nodes/stream.rb<br>
13 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/nodes/document.rb<br>
14 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/nodes/sequence.rb<br>
15 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/nodes/scalar.rb<br>
16 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/nodes/mapping.rb<br>
17 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/nodes/alias.rb<br>
18 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/nodes.rb<br>
19 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/streaming.rb<br>
20 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/visitors/visitor.rb<br>
21 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
22 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/scalar_scanner.rb<br>
23 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/visitors/to_ruby.rb<br>
24 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/visitors/emitter.rb<br>
25 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/visitors/yaml_tree.rb<br>
26 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/json/ruby_events.rb<br>
27 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/visitors/json_tree.rb<br>
28 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/visitors/depth_first.rb<br>
29 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/visitors.rb<br>
30 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/handler.rb<br>
31 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/tree_builder.rb<br>
32 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/parser.rb<br>
33 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/omap.rb<br>
34 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/set.rb<br>
35 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/coder.rb<br>
36 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/core_ext.rb<br>
37 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
38 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/date/format.rb<br>
39 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/date.rb<br>
40 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/deprecated.rb<br>
41 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych/json.rb<br>
42 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/psych.rb<br>
43 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/yaml.rb<br>
44 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/core_ext/rbconfig.rb<br>
45 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/xdg.rb<br>
46 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/control.rb<br>
47 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/command.rb<br>
48 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/original.rb<br>
49 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/core_ext/file.rb<br>
50 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/library/requirements.rb<br>
51 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/library/metadata.rb<br>
52 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/library/script.rb<br>
53 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/library/version.rb<br>
54 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/library.rb<br>
55 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/ruby.rb<br>
56 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll/kernel.rb<br>
57 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/roll.rb<br>
58 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/site_ruby/1.9.1/oll.rb<br>
59 ubygems.rb<br>
60 rubygems.rb<br>
61 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/ubygems.rb<br>
62 irb.rb<br>
63 e2mmap.rb<br>
64 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/e2mmap.rb<br>
65 irb/init.rb<br>
66 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/init.rb<br>
67 irb/context.rb<br>
68 irb/workspace.rb<br>
69 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/workspace.rb<br>
70 irb/inspector.rb<br>
71 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/inspector.rb<br>
72 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/context.rb<br>
73 irb/extend-command.rb<br>
74 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/extend-command.rb<br>
75 irb/ruby-lex.rb<br>
76 irb/slex.rb<br>
77 irb/notifier.rb<br>
78 irb/output-method.rb<br>
79 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/output-method.rb<br>
80 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/notifier.rb<br>
81 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/slex.rb<br>
82 irb/ruby-token.rb<br>
83 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-token.rb<br>
84 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/ruby-lex.rb<br>
85 irb/input-method.rb<br>
86 irb/src_encoding.rb<br>
87 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/src_encoding.rb<br>
88 irb/magic-file.rb<br>
89 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/magic-file.rb<br>
90 readline.so<br>
91 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/readline.so<br>
92 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/input-method.rb<br>
93 irb/locale.rb<br>
94 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/locale.rb<br>
95 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb.rb<br>
96 rubygems/version.rb<br>
97 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/version.rb<br>
98 rubygems/requirement.rb<br>
99 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/requirement.rb<br>
100 rubygems/platform.rb<br>
101 rubygems/deprecate.rb<br>
102 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/platform.rb<br>
103 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/specification.rb<br>
104 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/path_support.rb<br>
105 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/rubygems/dependency.rb<br>
106 ostruct.rb<br>
107 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/ostruct.rb<br>
108 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/gems/1.9.1/gems/wirble-0.1.3/lib/wirble.rb<br>
109 pp.rb<br>
110 prettyprint.rb<br>
111 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/prettyprint.rb<br>
112 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/pp.rb<br>
113 irb/completion.rb<br>
114 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/irb/completion.rb</p>
</li>
<li>
<p>Process memory map:</p>
</li>
</ul>
<p>00400000-00616000 r-xp 00000000 08:01 5575135 /home/trans/.rbenv/versions/1.9.3-rc1/bin/ruby<br>
00815000-00816000 r--p 00215000 08:01 5575135 /home/trans/.rbenv/versions/1.9.3-rc1/bin/ruby<br>
00816000-00818000 rw-p 00216000 08:01 5575135 /home/trans/.rbenv/versions/1.9.3-rc1/bin/ruby<br>
00818000-00834000 rw-p 00000000 00:00 0<br>
00a47000-012f9000 rw-p 00000000 00:00 0 [heap]<br>
7f8c9d264000-7f8c9d27a000 r-xp 00000000 08:01 18972791 /lib/libgcc_s.so.1<br>
7f8c9d27a000-7f8c9d479000 ---p 00016000 08:01 18972791 /lib/libgcc_s.so.1<br>
7f8c9d479000-7f8c9d47a000 r--p 00015000 08:01 18972791 /lib/libgcc_s.so.1<br>
7f8c9d47a000-7f8c9d47b000 rw-p 00016000 08:01 18972791 /lib/libgcc_s.so.1<br>
7f8c9d47b000-7f8c9d4b9000 r-xp 00000000 08:01 18972805 /lib/libncurses.so.5.7<br>
7f8c9d4b9000-7f8c9d6b9000 ---p 0003e000 08:01 18972805 /lib/libncurses.so.5.7<br>
7f8c9d6b9000-7f8c9d6bd000 r--p 0003e000 08:01 18972805 /lib/libncurses.so.5.7<br>
7f8c9d6bd000-7f8c9d6be000 rw-p 00042000 08:01 18972805 /lib/libncurses.so.5.7<br>
7f8c9d6be000-7f8c9d6f7000 r-xp 00000000 08:01 18972819 /lib/libreadline.so.6.1<br>
7f8c9d6f7000-7f8c9d8f6000 ---p 00039000 08:01 18972819 /lib/libreadline.so.6.1<br>
7f8c9d8f6000-7f8c9d8f8000 r--p 00038000 08:01 18972819 /lib/libreadline.so.6.1<br>
7f8c9d8f8000-7f8c9d8fe000 rw-p 0003a000 08:01 18972819 /lib/libreadline.so.6.1<br>
7f8c9d8fe000-7f8c9d8ff000 rw-p 00000000 00:00 0<br>
7f8c9d8ff000-7f8c9d905000 r-xp 00000000 08:01 8702444 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/readline.so<br>
7f8c9d905000-7f8c9db04000 ---p 00006000 08:01 8702444 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/readline.so<br>
7f8c9db04000-7f8c9db05000 r--p 00005000 08:01 8702444 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/readline.so<br>
7f8c9db05000-7f8c9db06000 rw-p 00006000 08:01 8702444 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/readline.so<br>
7f8c9db06000-7f8c9db3a000 r-xp 00000000 08:01 8702448 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f8c9db3a000-7f8c9dd39000 ---p 00034000 08:01 8702448 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f8c9dd39000-7f8c9dd3a000 r--p 00033000 08:01 8702448 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f8c9dd3a000-7f8c9dd3b000 rw-p 00034000 08:01 8702448 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/date_core.so<br>
7f8c9dd3b000-7f8c9dd3c000 rw-p 00000000 00:00 0<br>
7f8c9dd3c000-7f8c9dd41000 r-xp 00000000 08:01 8702451 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f8c9dd41000-7f8c9df41000 ---p 00005000 08:01 8702451 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f8c9df41000-7f8c9df42000 r--p 00005000 08:01 8702451 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f8c9df42000-7f8c9df43000 rw-p 00006000 08:01 8702451 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/strscan.so<br>
7f8c9df43000-7f8c9df4a000 r-xp 00000000 08:01 8702446 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f8c9df4a000-7f8c9e149000 ---p 00007000 08:01 8702446 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f8c9e149000-7f8c9e14a000 r--p 00006000 08:01 8702446 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f8c9e14a000-7f8c9e14b000 rw-p 00007000 08:01 8702446 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/stringio.so<br>
7f8c9e14b000-7f8c9e16a000 r-xp 00000000 08:01 39535253 /home/trans/.rbenv/versions/1.9.3-rc1/lib/libyaml-0.so.2.0.2<br>
7f8c9e16a000-7f8c9e369000 ---p 0001f000 08:01 39535253 /home/trans/.rbenv/versions/1.9.3-rc1/lib/libyaml-0.so.2.0.2<br>
7f8c9e369000-7f8c9e36a000 r--p 0001e000 08:01 39535253 /home/trans/.rbenv/versions/1.9.3-rc1/lib/libyaml-0.so.2.0.2<br>
7f8c9e36a000-7f8c9e36b000 rw-p 0001f000 08:01 39535253 /home/trans/.rbenv/versions/1.9.3-rc1/lib/libyaml-0.so.2.0.2<br>
7f8c9e36b000-7f8c9e370000 r-xp 00000000 08:01 8702452 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f8c9e370000-7f8c9e570000 ---p 00005000 08:01 8702452 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f8c9e570000-7f8c9e571000 r--p 00005000 08:01 8702452 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f8c9e571000-7f8c9e572000 rw-p 00006000 08:01 8702452 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/psych.so<br>
7f8c9e572000-7f8c9e574000 r-xp 00000000 08:01 9421126 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f8c9e574000-7f8c9e774000 ---p 00002000 08:01 9421126 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f8c9e774000-7f8c9e775000 r--p 00002000 08:01 9421126 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f8c9e775000-7f8c9e776000 rw-p 00003000 08:01 9421126 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/trans/transdb.so<br>
7f8c9e776000-7f8c9e778000 r-xp 00000000 08:01 9421099 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f8c9e778000-7f8c9e977000 ---p 00002000 08:01 9421099 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f8c9e977000-7f8c9e978000 r--p 00001000 08:01 9421099 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f8c9e978000-7f8c9e979000 rw-p 00002000 08:01 9421099 /home/trans/.rbenv/versions/1.9.3-rc1/lib/ruby/1.9.1/x86_64-linux/enc/encdb.so<br>
7f8c9e979000-7f8c9eaf3000 r-xp 00000000 08:01 18972789 /lib/libc-2.11.1.so<br>
7f8c9eaf3000-7f8c9ecf2000 ---p 0017a000 08:01 18972789 /lib/libc-2.11.1.so<br>
7f8c9ecf2000-7f8c9ecf6000 r--p 00179000 08:01 18972789 /lib/libc-2.11.1.so<br>
7f8c9ecf6000-7f8c9ecf7000 rw-p 0017d000 08:01 18972789 /lib/libc-2.11.1.so<br>
7f8c9ecf7000-7f8c9ecfc000 rw-p 00000000 00:00 0<br>
7f8c9ecfc000-7f8c9ed7e000 r-xp 00000000 08:01 18972854 /lib/libm-2.11.1.so<br>
7f8c9ed7e000-7f8c9ef7d000 ---p 00082000 08:01 18972854 /lib/libm-2.11.1.so<br>
7f8c9ef7d000-7f8c9ef7e000 r--p 00081000 08:01 18972854 /lib/libm-2.11.1.so<br>
7f8c9ef7e000-7f8c9ef7f000 rw-p 00082000 08:01 18972854 /lib/libm-2.11.1.so<br>
7f8c9ef7f000-7f8c9ef88000 r-xp 00000000 08:01 18972806 /lib/libcrypt-2.11.1.so<br>
7f8c9ef88000-7f8c9f188000 ---p 00009000 08:01 18972806 /lib/libcrypt-2.11.1.so<br>
7f8c9f188000-7f8c9f189000 r--p 00009000 08:01 18972806 /lib/libcrypt-2.11.1.so<br>
7f8c9f189000-7f8c9f18a000 rw-p 0000a000 08:01 18972806 /lib/libcrypt-2.11.1.so<br>
7f8c9f18a000-7f8c9f1b8000 rw-p 00000000 00:00 0<br>
7f8c9f1b8000-7f8c9f1ba000 r-xp 00000000 08:01 18972823 /lib/libdl-2.11.1.so<br>
7f8c9f1ba000-7f8c9f3ba000 ---p 00002000 08:01 18972823 /lib/libdl-2.11.1.so<br>
7f8c9f3ba000-7f8c9f3bb000 r--p 00002000 08:01 18972823 /lib/libdl-2.11.1.so<br>
7f8c9f3bb000-7f8c9f3bc000 rw-p 00003000 08:01 18972823 /lib/libdl-2.11.1.so<br>
7f8c9f3bc000-7f8c9f3c3000 r-xp 00000000 08:01 18973094 /lib/librt-2.11.1.so<br>
7f8c9f3c3000-7f8c9f5c2000 ---p 00007000 08:01 18973094 /lib/librt-2.11.1.so<br>
7f8c9f5c2000-7f8c9f5c3000 r--p 00006000 08:01 18973094 /lib/librt-2.11.1.so<br>
7f8c9f5c3000-7f8c9f5c4000 rw-p 00007000 08:01 18973094 /lib/librt-2.11.1.so<br>
7f8c9f5c4000-7f8c9f5dc000 r-xp 00000000 08:01 18973092 /lib/libpthread-2.11.1.so<br>
7f8c9f5dc000-7f8c9f7db000 ---p 00018000 08:01 18973092 /lib/libpthread-2.11.1.so<br>
7f8c9f7db000-7f8c9f7dc000 r--p 00017000 08:01 18973092 /lib/libpthread-2.11.1.so<br>
7f8c9f7dc000-7f8c9f7dd000 rw-p 00018000 08:01 18973092 /lib/libpthread-2.11.1.so<br>
7f8c9f7dd000-7f8c9f7e1000 rw-p 00000000 00:00 0<br>
7f8c9f7e1000-7f8c9f801000 r-xp 00000000 08:01 18972752 /lib/ld-2.11.1.so<br>
7f8c9f894000-7f8c9f995000 rw-p 00000000 00:00 0<br>
7f8c9f995000-7f8c9f9d4000 r--p 00000000 08:01 10846233 /usr/lib/locale/en_US.utf8/LC_CTYPE<br>
7f8c9f9d4000-7f8c9f9d9000 rw-p 00000000 00:00 0<br>
7f8c9f9f1000-7f8c9f9f3000 rw-p 00000000 00:00 0<br>
7f8c9f9f3000-7f8c9f9f4000 ---p 00000000 00:00 0<br>
7f8c9f9f4000-7f8c9f9f7000 rw-p 00000000 00:00 0<br>
7f8c9f9f7000-7f8c9f9fe000 r--s 00000000 08:01 23150643 /usr/lib/gconv/gconv-modules.cache<br>
7f8c9f9fe000-7f8c9fa00000 rw-p 00000000 00:00 0<br>
7f8c9fa00000-7f8c9fa01000 r--p 0001f000 08:01 18972752 /lib/ld-2.11.1.so<br>
7f8c9fa01000-7f8c9fa02000 rw-p 00020000 08:01 18972752 /lib/ld-2.11.1.so<br>
7f8c9fa02000-7f8c9fa03000 rw-p 00000000 00:00 0<br>
7fffaa009000-7fffaa01f000 rw-p 00000000 00:00 0 [stack]<br>
7fffaa095000-7fffaa096000 r-xp 00000000 00:00 0 [vdso]<br>
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]</p>
<p>[NOTE]<br>
You may have encountered a bug in the Ruby interpreter or extension libraries.<br>
Bug reports are welcome.<br>
For details: <a href="http://www.ruby-lang.org/bugreport.html" class="external">http://www.ruby-lang.org/bugreport.html</a></p>
<p>Aborted</p> Ruby master - Feature #5628 (Feedback): Module#basenamehttps://bugs.ruby-lang.org/issues/56282011-11-14T11:17:39Ztrans (Thomas Sawyer)
<p>Something I use fairly often:</p>
<pre><code>some_module.name.split("::").last
</code></pre>
<p>It's useful for things like factory methods. It would be much nicer if we had:</p>
<pre><code>class Module
def basename
name.split("::").last
end
end
</code></pre> Ruby 1.8 - Bug #5599 (Rejected): YAML.load_documentshttps://bugs.ruby-lang.org/issues/55992011-11-08T23:50:09Ztrans (Thomas Sawyer)
<p>Just discovered:</p>
<p>YAML.load_documents(@out)</p>
<p>is raising an error "undefined method `call' for nil:NilClass", b/c their is no block, but it is supposed to (and used to) return an array of documents.</p>
<p>It works fine in Ruby 1.9.3.</p> Ruby master - Feature #5578 (Rejected): Embedded YAML for Ruby 2.0https://bugs.ruby-lang.org/issues/55782011-11-06T17:11:40Ztrans (Thomas Sawyer)
<p>Way cool would be support for embedded YAML.</p>
<p>data = ---<br>
a: 1<br>
b: 2<br>
c: 3<br>
...</p> Ruby master - Feature #5558 (Assigned): String#% strange arity errorshttps://bugs.ruby-lang.org/issues/55582011-11-03T10:25:55Ztrans (Thomas Sawyer)
<p>When the number of arguments do not match the number of % parameters, the String#% method has some odd behavior.</p>
<p>When too many, it seems to work fine, ignoring the extra arguments.</p>
<p>"%s" % [1,2] #=> "1"</p>
<p>But if <code>$DEBUG = true</code>,</p>
<p>"%s" % [1,2] #=> ArgumentError: too many arguments for format string</p>
<p>That doesn't seem right. Is it an error or isn't it?</p>
<p>For too few arguments it is always an error:</p>
<p>"%s" % [] #=> ArgumentError: too few arguments</p>
<p>Personally, I think it should use '' for missing arguments. That would make it more flexible in practice.</p>
<p>I consider the first $DEBUG issue a bug, and the later a feature. But I'll just call it a feature altogether to make things easier.</p> Ruby master - Feature #5528 (Closed): OO API for tracinghttps://bugs.ruby-lang.org/issues/55282011-11-01T00:22:23Ztrans (Thomas Sawyer)
<p>It would be nice to see a better API for "set_trace_func" functionality.</p>
<p>I wrote a fairly simple library to do this some time ago called <a href="<a href="https://github.com/rubyworks/tracepoint%3ETracePoint" class="external">https://github.com/rubyworks/tracepoint>TracePoint</a>. One of the significant advantages of TracePoint is that it allows for multiple traces to be defined without interfering others and they can even be given names to activate and deactivate them independently.</p>
<p>It would be nice to see something like this is Ruby 2.0, it would have the a number of advantages:</p>
<ul>
<li>Object-oriented - a tracepoint is an object, not just an array of arguments.</li>
<li>Connescence - the tracepoint methods give tangible names to the properties that are traced.</li>
<li>More robust - currently one use of set_trace_func will clobber another.</li>
</ul>
<p>And probably others beside.</p> Ruby master - Bug #5527 (Closed): set_trace_func binding incorrecthttps://bugs.ruby-lang.org/issues/55272011-11-01T00:08:04Ztrans (Thomas Sawyer)
<p>set_trace_func seems to be broken. I traced the issue to the binding<br>
(<code>b</code> below).</p>
<pre><code> $ cat t.rb
fn = lambda do |e, f, l, m, b, k|
p Kernel.eval('self', b)
end
set_trace_func(fn)
" a ".strip
$ rbenv shell 1.8.7-p352
$ ruby t.rb
main
" a "
" a "
$ rbenv shell 1.9.3-rc1
$ ruby t.rb
main
main
main
main
</code></pre>
<p>It would seem the binding has somehow become the binding-of-caller, rather than receiver.</p> Ruby master - Feature #5505 (Rejected): BasicObject#__extend__https://bugs.ruby-lang.org/issues/55052011-10-28T23:07:33Ztrans (Thomas Sawyer)
<p>Unless there is already some way to do it that I've overlooked, the it would be nice if there were still some way to extend an instance of BasicObject.</p>
<p>Probably the easiest way is defining #<strong>extend</strong>.</p> Ruby master - Feature #5482 (Rejected): Rubinius as basis for Ruby 2.0https://bugs.ruby-lang.org/issues/54822011-10-25T09:46:48Ztrans (Thomas Sawyer)
<p>I'll give you three great reasons why:</p>
<ol>
<li>It's Ruby in Ruby (mostly).</li>
<li>Ruby is better.</li>
<li>Read #1 and #2, again.</li>
</ol>
<p>As Rubyists, if we truly believe that Ruby makes software development more enjoyable and more productive, then it only stands to reason that Rubinius be the future of Ruby.</p> Ruby master - Feature #5445 (Assigned): Need RUBYOPT -r before ARGV -rhttps://bugs.ruby-lang.org/issues/54452011-10-14T00:47:09Ztrans (Thomas Sawyer)
<p>Libraries given by -r options in RUBYOPT should be loaded before ones in direct command line arguments.</p>
<p>I use a custom load system for development that I have been using for years and it works very well for me. But Ruby has some edge cases that prevents it from being feature complete. One of these is the order in which RUBYOPT is applied vs. -r command line option.</p>
<p>My custom loader is too large to include here, so I will simply demonstrate the problem with simple sample code:</p>
<p>$ cat req.rb<br>
p "Custom Require"</p>
<p>module Kernel<br>
alias :require0 :require</p>
<pre><code>def require(*a)
puts "Kernel#require"
p a
require0(*a)
end
class << self
alias :require0 :require
def require(*a)
puts "Kernel.require"
p a
require0(*a)
end
end
</code></pre>
<p>end</p>
<p>If we load this via RUBYOPT, the result is:</p>
<p>$ RUBYOPT=-r./req.rb ruby -rstringio -e0<br>
Custom Require</p>
<p>But if we load via -r the result is:</p>
<p>$ ruby -r./req.rb -rstringio -e0<br>
Custom Require<br>
Kernel#require<br>
["stringio"]</p>
<p>I would ask that the output of both invocations to be identical.</p>
<p>(Note, the -T option should still allow RUBYOPT to be omitted regardless.)</p> Ruby master - Feature #5444 (Rejected): Object.freehttps://bugs.ruby-lang.org/issues/54442011-10-14T00:28:00Ztrans (Thomas Sawyer)
<p>I came across this gem today:</p>
<p><a href="http://github.com/banister/free" class="external">http://github.com/banister/free</a></p>
<p>Which led me to wonder if it might not be good to have this feature built-in to the core language. While not useful in most cases, it could be very useful to power-users who need to eek out every bit performance they can.</p> Ruby master - Feature #5421 (Rejected): -r option uselesshttps://bugs.ruby-lang.org/issues/54212011-10-07T22:54:27Ztrans (Thomas Sawyer)
<p>Ran into a problem trying to require a plugin I had written while running a ruby scipt, e.g.</p>
<p>$ ruby -rmyplugin script.rb</p>
<p>It tells me "no such file" for myplugin. Turns out the problem is that the -r option uses internal require code and thus circumvents rubygems or any modified #require, so even though my RUBYOPT="-rubygems", it makes no difference. I've also been informed that RUBYOPT is applied after -r options, which makes for an additional problem. Apparently this so -T can ignore RUBYOPT? But if that's the only reason, then -T should be preparsed from ARGV b/c having -r options load first prevents augmentation and use of what RUBYOPT loads by -r. RUBYOPT is supposed to set the environment, but it isn't much of an environment if its not there when I run a ruby command.</p>
<p>I've marked this report as a feature b/c I'm sure someone would take issue if I did otherwise, but I personally see it as a bug b/c it makes -r useless in many cases.</p> Ruby master - Feature #5361 (Rejected): Lice?https://bugs.ruby-lang.org/issues/53612011-09-24T11:05:58Ztrans (Thomas Sawyer)
<p>Err... why is there a new String method for getting the lice of bytes?</p>
<p>'hello'.byteslice(2, 2) # => "ll"</p>
<p>I don't like getting lice ;)</p>
<p>(In other words what happened to good old readable underscores?)</p> Ruby master - Feature #5360 (Feedback): BasicObject#bindinghttps://bugs.ruby-lang.org/issues/53602011-09-24T10:57:29Ztrans (Thomas Sawyer)
<p>For meta-programming purposes I think there needs to be a way to get a BasicObject's binding.</p> Ruby master - Bug #5186 (Closed): Psych noisy parsing valid nodehttps://bugs.ruby-lang.org/issues/51862011-08-11T12:24:05Ztrans (Thomas Sawyer)
<p>Psych makes a lot of noise over perfectly valid value.</p>
<blockquote>
<blockquote>
<p>$DEBUG = true<br>
YAML.load('--- 1.1.1')<br>
Exception <code>ArgumentError' at /usr/local/lib/ruby/1.9.1/psych/scalar_scanner.rb:71 - invalid value for Integer(): "1.1.1" Exception </code>ArgumentError' at /usr/local/lib/ruby/1.9.1/psych/scalar_scanner.rb:72 - invalid value for Float(): "1.1.1"<br>
=> "1.1.1"</p>
</blockquote>
</blockquote> Ruby master - Feature #5185 (Rejected): Set#merge acts in place but Hash#merge does nothttps://bugs.ruby-lang.org/issues/51852011-08-11T12:16:15Ztrans (Thomas Sawyer)
<p>Waste of brain cells to have to learn and recall they are different. The expected method would be Set#merge!, Set#merge would return a new Set instance.</p>
<p>OTOH, why not Set#concat ? Or conversely, Array#merge ?</p> Ruby master - Bug #5184 (Closed): YAML #y method not privatehttps://bugs.ruby-lang.org/issues/51842011-08-11T12:07:18Ztrans (Thomas Sawyer)
<p>And it's bleeding through OpenStruct.</p>
<p>require 'ostruct'<br>
=> true<br>
irb(main):002:0> o = OpenStruct.new<br>
=> #<br>
irb(main):003:0> o.y 1<br>
--- 1<br>
...<br>
=> nil</p> Ruby master - Feature #5148 (Rejected): Constant Namespace/Scoping in Dynamic Classes/Moduleshttps://bugs.ruby-lang.org/issues/51482011-08-03T00:01:03Ztrans (Thomas Sawyer)
<p>When defining a dynamic class or module, the constants defined within it are not kept within it's namespace, but are tied to the outer scope's namespace.</p>
<pre><code>c = Class.new do
module M; end
end
#=> #<Class:0xa601300>
c::M #=> M
M #=> M
</code></pre>
<p>This presents serious limitations in designing domain specific languages that take advantage of Ruby's class system. For instance in creating a test framework that uses blocks to defines testcases it is not possible to isolate fixture constants from those of other testcases. E.g.</p>
<pre><code>describe "fancy mixin" do
class Foo
include FancyMixin
end
...
end
describe "unfancy mixin" do
class Foo
include UnfancyMixin
end
...
end
</code></pre>
<p>Foo in the unfancy testcase will use Foo in the fancy testcase, causing unexpected issues --especially as these testcases may be defined in different files and coded by different people.</p> Ruby master - Bug #5109 (Third Party's Issue): YAML output has changedhttps://bugs.ruby-lang.org/issues/51092011-07-28T06:20:54Ztrans (Thomas Sawyer)
<p>Have no idea why, but I noticed that 1.9.3 is producing strange YAML output:</p>
<p>snippet:</p>
<ul>
<li>35: ''</li>
<li>36: ! ' Then ''the result should be (((\d+))) on the screen'' do |n|'</li>
<li>37: ! ' @result.assert == n.to_i'</li>
<li>38: ! ' end'</li>
<li>39: end</li>
</ul>
<p>Where as in 1.9.2 it comes out more like one would expect:</p>
<p>snippet:</p>
<ul>
<li>35: ""</li>
<li>36: " Then 'the result should be (((\d+))) on the screen' do |n|"</li>
<li>37: " @result.assert == n.to_i"</li>
<li>38: " end"</li>
<li>39: end</li>
</ul> Ruby master - Bug #5091 (Rejected): Can't require './.testrb'https://bugs.ruby-lang.org/issues/50912011-07-25T07:40:36Ztrans (Thomas Sawyer)
<p>Just ran across this oddity. I made a local configuration file called <code>.testrb</code>, but I can't require it.</p>
<blockquote>
<p>require './.testrb'<br>
LoadError: no such file to load -- ./.testrb</p>
</blockquote>
<p>Just to make sure I did not mess up somehow, I renamed it to <code>.rbtest</code> and it worked fine. I change it back and still no go.</p>
<p>I tried it under 1.9.2 and 1.8.7, both failed to require the file.</p> Ruby master - Bug #5059 (Closed): Mailing Listhttps://bugs.ruby-lang.org/issues/50592011-07-20T07:00:14Ztrans (Thomas Sawyer)
<p>I know this is not really the place to report this. But I have tried all other avenues and have had no success.</p>
<p>I have tried multiple times to subscribe to ruby-core mailing list both via the web form on the website and manually via email to the controller address. I have also tried to contact the mailing list administrator. None of these have produced any response.</p>
<p>Yehuda recently posted to the list and I would like to make a reply, but cannot. Could some please address this?</p>
<p>Thanks.</p> Ruby master - Feature #5044 (Rejected): #zip with block return mapped resultshttps://bugs.ruby-lang.org/issues/50442011-07-18T12:35:25Ztrans (Thomas Sawyer)
<p>Is there any reason that #zip doesn't return results like map?</p>
<p>[1,2,3].zip([1,2,3]){ |a,b| a + b } #=> [2,4,6]</p>
<p>Currently, it just returns nil, which seems rather contrary to the return result of the non-block form.</p> Ruby master - Bug #5025 (Rejected): YAML::Syck::Map#children returns [nil, nil]https://bugs.ruby-lang.org/issues/50252011-07-14T01:29:03Ztrans (Thomas Sawyer)
<p>ruby-1.9.2-p0 > d = YAML.load('--- { a: 1, b: 2 }')<br>
=> {"a"=>1, "b"=>2}<br>
ruby-1.9.2-p0 > d = YAML.parse('--- { a: 1, b: 2 }')<br>
=> #<a href="Syck::Map:0x00000001890840" class="external">Syck::Map:0x00000001890840</a><br>
ruby-1.9.2-p0 > d.children<br>
=> [nil, nil]</p> Ruby master - Feature #5006 (Rejected): Allow ~> as a methodhttps://bugs.ruby-lang.org/issues/50062011-07-09T21:42:55Ztrans (Thomas Sawyer)
<p>It occurs to me that since RubyGems uses ~> as a recognized version constraint operator (along with >, <, >= and <=) it would be nice if Ruby supported it as a valid method. Ultimately RubyGems could use the new method in it's code. But more generally it could be useful too, as it has a couple of nice features, namely the '~' part can be thought of as meaning "approximate", and as a whole it looks like a pointing arrow.</p> Ruby master - Feature #4970 (Closed): FileUtils refactoredhttps://bugs.ruby-lang.org/issues/49702011-07-04T08:55:22Ztrans (Thomas Sawyer)
<p>I've been working with FileUtils a good bit, and concluded it could use some refactoring to make the code clearer and easier to work with. Here is the pull request:</p>
<p><a href="https://github.com/ruby/ruby/pull/30" class="external">https://github.com/ruby/ruby/pull/30</a></p>
<p>Essentially, I have removed the method definition loops that occur at the end of the script and replaced them with a simple call (<code>define_command</code>) made for each command as it is defined. This allowed me to use <code>extend self</code> all the way through, rather than having to use <code>module_function</code> in FileUtils and <code>extend self</code> in the Verbose, NoWrite and DryRun "submodules".</p> Ruby master - Feature #4969 (Rejected): Subtle issue with requirehttps://bugs.ruby-lang.org/issues/49692011-07-04T04:19:41Ztrans (Thomas Sawyer)
<p>If I have a library with same name as Ruby standard library in load path (as an example):</p>
<p>lib/abbrev.rb</p>
<p>There is conflict with loading. Ok, I work around:</p>
<p>require 'rbconfig'</p>
<a name="Notice-that-rubylibdir-takes-precendence"></a>
<h1 >Notice that rubylibdir takes precendence.<a href="#Notice-that-rubylibdir-takes-precendence" class="wiki-anchor">¶</a></h1>
<p>LOCATIONS = ::RbConfig::CONFIG.values_at(<br>
'rubylibdir', 'archdir', 'sitelibdir', 'sitearchdir'<br>
)</p>
<h1></h1>
<p>def require_ruby(file)<br>
LOCATIONS.each do |loadpath|<br>
if path = lib_find(loadpath, file)<br>
return path<br>
end<br>
end</p>
<pre><code>raise LoadError, "no such file to load -- #{fname}"
</code></pre>
<p>end</p>
<p>private</p>
<pre><code>SUFFIXES = ['.rb', '.rbw', '.so', '.bundle', '.dll', '.sl', '.jar']
# Given a +loadpath+, a file's relative path, +relname+, and
# options hash, determine a matching file exists. Unless +:load+
# option is +true+, this will check for each viable Ruby suffix.
# If a match is found the full path to the file is returned,
# otherwise +nil+.
def lib_find(loadpath, relname)
if SUFFIXES.include?(File.extname(relname))
abspath = File.join(loadpath, relname)
File.exist?(abspath) ? abspath : nil
else
SUFFIXES.each do |ext|
abspath = File.join(loadpath, relname + ext)
return abspath if File.exist?(abspath)
end
end
nil
end
</code></pre>
<p>Now I can do:</p>
<p>require 'abbrev'<br>
require_ruby 'abbrev'</p>
<p>And it works fine. But, if I do:</p>
<p>require_ruby 'abbrev'<br>
require 'abbrev'</p>
<p>The second is not loaded because somehow it seems to confuse it for the first in $LOADED_FEATURES.</p>
<p>I realize this is a very subtle issue and not likely to effect most people, but it presents a big problem for some of my work (e.g. wedge gem)</p>
<p>How is Ruby confusing the two? Can it be fixed? Or is there at least a work around?</p> Ruby master - Feature #4189 (Closed): FileUtils#ln_rhttps://bugs.ruby-lang.org/issues/41892010-12-23T10:25:39Ztrans (Thomas Sawyer)
<p>=begin<br>
I wrote a method for FileUtils to do recursive hard linking. It works just like cp_r but links instead of copies.</p>
<p>The code can be found along with the pull request I made to ruby/ruby on Github:</p>
<p><a href="http://github.com/ruby/ruby/pull/4#issuecomment-631067" class="external">http://github.com/ruby/ruby/pull/4#issuecomment-631067</a></p>
<p>It's a pretty handy method for "staging" read-only files. For example I've used it to stage test fixture files in a tmp testing location and I've used it collect together a set of files for packaging into a tarball.<br>
=end</p> Backport187 - Backport #4156 (Closed): Use RUBY_VERSION instead of VERSION in e2mmap.rbhttps://bugs.ruby-lang.org/issues/41562010-12-14T05:58:05Ztrans (Thomas Sawyer)
<p>=begin<br>
e2mmap.rb:fail "Use Ruby 1.1" if VERSION < "1.1"<br>
=end</p>