ruby wish-list

[Roger Pack]

I wish that backtraces had more information, and could also display
variables and bindings, etc.

ex:
Thread.current.backtrace_bindings or $!.bindings

and outputs like

NameError: undefined local variable or method `abc' for main:Object
from
/Users/rogerpack/dev/ruby-roger-useful-functions/irb_lookup.rb:40:in
`method_missing('abc', 34)'
from (irb):12


Also displaying the line of code that crashed you would be sweet, a la
NameError: undefined local variable or method `abc' for main:Object
print abc # the line in question
from
/Users/rogerpack/dev/ruby-roger-useful-functions/irb_lookup.rb:40:in
`method_missing('abc', 34)'
from (irb):12

Though I suppose this is indeed possible in Ruby as it currently is ex:
[1]'s source_extract function

Take care.
-R
[1]
http://github.com/rails/rails/tree/...ntroller/templates/rescues/template_error.erb

 

[Roger Pack]

I wish that backtraces had more information, and could also display
variables and bindings, etc.

another wish:
rescue => e
really should rescue the same as
rescue # nothing

and, IMHO, rescue # blank
should rescue Exception, not just StandardError--a point of confusion to
almost all newbies
Take care!
-R

 

[Roger Pack]

another wish:

My thanks to the 1.9 team, who allowed for "abc\x14" style string
syntax, so we can actually input any arbitrary strings now within string
syntax. That's nicer
-R

 

[Roger Pack]

I wish we had Fiber.root method in 1.9
-R

 

[Nobuyoshi Nakada]

Hi,

At Wed, 2 Jul 2008 10:24:21 +0900,
Roger Pack wrote in [ruby-talk:306957]:

My thanks to the 1.9 team, who allowed for "abc\x14" style string
syntax, so we can actually input any arbitrary strings now within string
syntax. That's nicer

Of course, it's been possible also in 1.8 or earlier, even in 0.95.

$ ./ruby -v -e 'print "abc\x14"'| od -tx1z
ruby - version 0.95 (95/12/21)
0000000 61 62 63 14 >abc.<
0000004

 

[Roger Pack]

Of course, it's been possible also in 1.8 or earlier, even in 0.95.

$ ./ruby -v -e 'print "abc\x14"'| od -tx1z
ruby - version 0.95 (95/12/21)
0000000 61 62 63 14 >abc.<
0000004

Nice.
Next wish: IO#read_line [and I know I can make my own--just wishing I
didn't have to ]
-R

 

[Rob Biedenharn]

Of course, it's been possible also in 1.8 or earlier, even in 0.95.

$ ./ruby -v -e 'print "abc\x14"'| od -tx1z
ruby - version 0.95 (95/12/21)
0000000 61 62 63 14 >abc.<
0000004

Nice.
Next wish: IO#read_line [and I know I can make my own--just wishing I
didn't have to ]
-R

Granted!

Use IO#gets or IO#readline depending on the behavior that you expect.

-Rob

Rob Biedenharn http://agileconsultingllc.com
(e-mail address removed)

 

[Roger Pack]

Granted!

Use IO#gets or IO#readline depending on the behavior that you expect.

Thank you genie! That's like my 4th wish granted, and one created! You
rock!

Next wish:
Not mine, but copied from
http://eigenclass.org/hiki/Rename+and+reject+methods+from+included+modules


"Mark Hubbart I particularly like the ':alias => {rig => :new}'
syntax. I wish alias_method would take a hash; I think it would be much
clearer than 'alias_method :new, ld'.
"
I realize it's possible, but hey, here's wishing it were normal

=R

 

[Roger Pack]

Next wish [stolen shamelessly from Ryan Davis' blog]:

That 1.9 had a dissassemble command that worked, or some way at the
abstract syntax tree
=> nil # this one right here

-R

 

[Roger Pack]

Roger Pack wrote:

Wish I could 'steal' methods from classes. Without using parse_tree,
anyway

class A
def b;
'secret is here!'
end
end
class C
alias :stolen_b A:b # copy from a different class.
end
=> "secret is here!"

 

[Roger Pack]

"Mark Hubbart I particularly like the ':alias => {rig => :new}'
syntax. I wish alias_method would take a hash; I think it would be much
clearer than 'alias_method :new, ld'.
"
I realize it's possible, but hey, here's wishing it were normal

=R

Or rather wishing that alias weren't a compiler keyword but just a
function, like include is, or what not, so it could be overridden.
-R

 

[Trans]

Or rather wishing that alias weren't a compiler keyword but just a
function, like include is, or what not, so it could be overridden.

++1

#alias_method works though.

T.

 

[Robert Dober]

Yeah /* comments */ would be sweet. Then you could also have 'inline'
comments, like
a =3D [8..9 /* bread id's */, 900..990 /* butter id's */]

D=E9j=E0 vu?
a =3D [ 8..9 || "bread id's", 900..990 || "butter id's"]

Which would be awesome in some instances. Obviously these are poor
examples, but with some it would be nice.

And my technique just makes it clear how poor they are IMHO.
Robert

--=20
http://ruby-smalltalk.blogspot.com/

There's no one thing that's true. It's all true.

 

[Roger Pack]

Now you know you can.

|2) a GC that is 'user-definable' (run after this definable threshold,
|this often), and (asidedbly), a GC that can run in its own (native)
|thread so it doesn't pause execution of normal threads.

I'd rather prefer smarter collector, but it's possible.

GC on its own thread is a different story. Interaction between
collector and mutator may hinder the performance.

Would the following be a good idea?

When you garbage collect, fork and have the child "check for garbage"
then report back to the parent on which objects are no longer used.

Children and parents can share memory, it appears [1].
So my thought would be to have the parent and child share a "freeable"
list.

When the parent runs out of memory it spawns a child to do garbage
collection, and continues running. The child would propagate a shared
[large'ish] "freeable" list with pointers to memory which is no longer
used. The parent would later notice GC completion through some message,
and then reclaim the memory and free any unused blocks, and reap the
child.

My hypothesis is that this would allow for a single script to execute
faster, especially on dual core machines when only one script is running
[the child could run in the other core]. This would theoretically then
[should it work]: cost more RAM, use about the same total CPU, but allow
the script to continue running [a la macruby] during GC. Should you
have multiple cores available, it should have shorter execution time,
which is, after all, what we're after.

Thoughts? Cautions?

-R

 

[Joel VanderWerf]

When you garbage collect, fork and have the child "check for garbage"
then report back to the parent on which objects are no longer used.

The check for garbage can't be done concurrently with ruby code:

a = []
$a = a
a = nil

depending on how the gc process is scheduled, that empty array may
falsely appear to be garbage:

# start scan
a = []
# scan globals
$a = a
a = nil
# scan locals

 

[Roger Pack]

The check for garbage can't be done concurrently with ruby code:

a = []
$a = a
a = nil

depending on how the gc process is scheduled, that empty array may
falsely appear to be garbage:

# start scan * SNAPSHOT *
a = []
# scan globals
$a = a
a = nil
# scan locals

Definitely a consideration.

Do you think this help? The child process is basically operating off a
snapshot of memory, since it was a fork. It will thus only 'mark as
free' the ruby objects that are inaccessible at the time of the
snapshot, thus, in this example, not collecting "a" since it...hasn't
been created yet.

The memory is 'reclaimed' by the parent "all at once" so should avoid
concurrency weirdness that way, too. There is always "at most" one fork
doing a GC. Come to think of it, I'm not sure how this would work if
you had a process that actually called fork while running, but for
single [true] threaded scripts it should work.

Thoughts?

-R

 

[Joel VanderWerf]

The check for garbage can't be done concurrently with ruby code:

a = []
$a = a
a = nil

depending on how the gc process is scheduled, that empty array may
falsely appear to be garbage:

# start scan * SNAPSHOT *
a = []
# scan globals
$a = a
a = nil
# scan locals

Definitely a consideration.

Do you think this help? The child process is basically operating off a
snapshot of memory, since it was a fork. It will thus only 'mark as
free' the ruby objects that are inaccessible at the time of the
snapshot, thus, in this example, not collecting "a" since it...hasn't
been created yet.

The memory is 'reclaimed' by the parent "all at once" so should avoid
concurrency weirdness that way, too. There is always "at most" one fork
doing a GC. Come to think of it, I'm not sure how this would work if
you had a process that actually called fork while running, but for
single [true] threaded scripts it should work.

Thoughts?

-R

Oh, I wasn't understanding your idea, which does seem to make sense now.
There's the overhead of essentially duplicating the object space of the
original process in the fork (since mark will write to memory pages).
Maybe it would be worth this cost (esp. on a second processor) for the
benefit of not having to stop the main process?

Interesting!

 

[Roger Pack]

Oh, I wasn't understanding your idea, which does seem to make sense now.
There's the overhead of essentially duplicating the object space of the
original process in the fork (since mark will write to memory pages).
Maybe it would be worth this cost (esp. on a second processor) for the
benefit of not having to stop the main process?

Now that you mention it, this might would work even better in
conjunction with Hongli's Copy on write friendly GC. Then you wouldn't
have to copy the entire ruby space per GC

Interesting!

I can't get much credit for the idea since it just came to me while
reading scriptures yesterday morning
Now you know what distracts me a lot.

I'll probably hack it up sometime, first version as a straight patch to
1.8.6

-R

 

[Roger Pack]

if arr.include? 'a'
puts "array arr includes the letter 'a'"
end

Another wish [I believe this one is in facets already] is that wherever
there's a multiples verb like .include? it would also come with
includes? version so that the grammar isn't as confusing.
Thanks!
-R

 

[AdSR]

Another wish [I believe this one is in facets already] is that wherever
there's a multiples verb like .include? it would also come with
includes? version so that the grammar isn't as confusing.
Thanks!
-R

My interpretation of it is that "include" here is in the infinitive,
as in "Does x include y?", so the API as it is makes sense to me.
YMMV, of course.

AdSR