Ruby wish-list


#141

Let us assume that the aforementioned resource identifier is an
SCM-dependent URL to a project’s code repository. RubyGems would then
be responsible for (1) checking out the latest copy of the code
repository, (2) constructing a gem out of it, and (2) installing the
constructed gem.

Seems like minimalistically you’d need
scm_type = :git
scm_url = git://whatever # or something less scm dependent
scm_build_command = ‘cd subdir; rake build;’
scm_output_gem = ‘subdir/built.gem’

Just my $0.02 :slight_smile:
-R


#142

my latest wish
File.write ‘filename’, contents
:slight_smile:


#143

Roger P. wrote:

my latest wish
File.write ‘filename’, contents
:slight_smile:

Doh that one’s in facets already :slight_smile:

Question does this exist already?

Some central ‘rubydoc’ index that has links to the docs for installed
gems and/or the core docs? Like an updated index of docs? If that
existed I’d be tempted to actually use the rdocs instead of not even
knowing where they install to, with the current gem stuff [it’s painful
to go after rdocs that are buried X folders deep].
Twould be swell if rubygems automatically updated the doc index. Or
does it exist?
-R


#144

On Wednesday 25 June 2008 18:00:54 Roger P. wrote:

If I wanted something “intuitive”,

/*
I’d probably prefer something like this,
*/

since that’s what I’m used to for multiline comments. On the
other

hand,

=begin
this seems a lot more Ruby-idiomatic to me,
=end

so I like it just fine.

Yeah /* comments / would be sweet. Then you could also have
‘inline’
comments, like
a = [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.
-R
a = [ 8…9, #ids pan
900…990 ] #ids mantequilla


#145

If I wanted something “intuitive”,

/*
I’d probably prefer something like this,
*/

since that’s what I’m used to for multiline comments. On the other
hand,

=begin
this seems a lot more Ruby-idiomatic to me,
=end

so I like it just fine.

Yeah /* comments / would be sweet. Then you could also have ‘inline’
comments, like
a = [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.
-R


#146

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:inmethod_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:inmethod_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/ad772402c46a79c2d38979cef754b26dbd868196/actionpack/lib/action_controller/templates/rescues/template_error.erb


#147

a = [ 8…9, #ids pan
900…990 ] #ids mantequilla

That would work, but forces you to insert line breaks per comment, which
is livable, but exactly the reason for my wish :slight_smile:
-R


#148

Roger P. wrote:

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 :slight_smile:
Take care!
-R


#149

Roger P. wrote:

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


#150

Hi,

At Wed, 2 Jul 2008 10:24:21 +0900,
Roger P. 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 :slight_smile:

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


#151

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 :slight_smile: ]
-R


#152

On Jul 18, 2008, at 2:25 PM, Roger P. wrote:

-R
Granted!

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

-Rob

Rob B. http://agileconsultingllc.com
removed_email_address@domain.invalid


#153

Roger P. wrote:

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 :slight_smile:
-R


#154

Rob B. wrote:

On Jul 18, 2008, at 2:25 PM, Roger P. wrote:

-R
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 H. I particularly like the ‘:alias => {:orig => :new}’
syntax. I wish alias_method would take a hash; I think it would be much
clearer than ‘alias_method :new, :old’.
"
I realize it’s possible, but hey, here’s wishing it were normal :slight_smile:

=R


#155

Next wish [stolen shamelessly from Ryan D.’ blog]:

That 1.9 had a dissassemble command that worked, or some way at the
abstract syntax tree :slight_smile:

p = proc { |n| n + 2 }
=> #Proc:0x3be994@:1(irb)

VM::InstructionSequence.disassemble p
class Temp1; end
Temp1.send :define_method, :m, p
=> #<Proc:0x3be9e4@(irb):1 (lambda)>

VM::InstructionSequence.disassemble(Temp1.instance_method :m)
=> nil # this one right here

-R


#156

Roger P. wrote:

Wish I could ‘steal’ methods from classes. Without using parse_tree,
anyway :stuck_out_tongue:

class A
def b;
‘secret is here!’
end
end
class C
alias :stolen_b A:b # copy from a different class.
end

C.new.stolen_b
=> “secret is here!”


#157

"Mark H. I particularly like the ‘:alias => {:orig => :new}’
syntax. I wish alias_method would take a hash; I think it would be much
clearer than ‘alias_method :new, :old’.
"
I realize it’s possible, but hey, here’s wishing it were normal :slight_smile:

=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


#158

On Jul 25, 1:15 am, Roger P. removed_email_address@domain.invalid wrote:

"Mark H. I particularly like the ‘:alias => {:orig => :new}’
syntax. I wish alias_method would take a hash; I think it would be much
clearer than ‘alias_method :new, :old’.
"
I realize it’s possible, but hey, here’s wishing it were normal :slight_smile:

=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.

++1

#alias_method works though.

T.


#159

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


#160

Roger P. wrote:

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