Re: Does &method(:foo) get inlined? Can it? Should it?

I think that using this style is certainly possible, but fairly obtuse to most rubyists. If you never wrote
blocks and instead only wrote these &method(:blah) isms, the other programmers on your team would get
frustrated with you.

That being said, you asked a technical question rather than a stylistic one, so I'll answer it technically.

You're assumption that it could be the same as a block is, I'm sad to say, dead wrong. There reason you don't
see Method#to_proc and such in profiling is 2 fold:

1) Most (all?) MRI profilers do not show a methods that MRI defines in C, so they'd never show up.

2) The mechanism for activating a method that has been turned into a Proc is all in C, so the overhead is
invisible on the invocation side too.

You're point about the arty differences are right on. Additionally, you're thinking that a VM could easily
optimize it into a block is quite wrong. Object#method is a not specially, not something that would be
detected and optimized away. Additionally, even with runtime optimizations, something like escape
analysis is still required since #method returns a Method object that you'd have to see inside and extract
the information from. On the invocation side, the invoked method can only do something special with the
block in the case of block inlining, an optimization that only Rubinius has.

So to get to your questions:

1. Does Rubinius optimize this code? No. Could it? Yes, but it's hardly easy.
2. In time it could, yes.
3. In time it should, yes.

 - Evan

--

-- 

Does &method(:foo) get inlined? Can it? Should it?

Hi.

I am a big fan of programming in point-free style, although
unfortunately Ruby makes that unnecessarily ugly. I.e., I very much
prefer 

    ary.each(&method(:puts))

over 

    ary.each {|el| puts el }

The reason for this is the old saying by Phil Karlton:

| There are only two hard problems in computer science. Cache invalidation and naming things.

If naming things is hard (i.e. expensive), then names shouldn't be
wasted on irrelevant things. And conversely, if something has a name,
then it is important.

The whole *point* of higher-level iteration methods like
Enumerable#each and friends is to lift collection operations over the
individual elements, IOW to make the individual elements not
important; ergo, the individual elements shouldn't need to be named.

However, today there was a StackOverflow question about the efficiency
of such point-free code, especially with regards to reified Method and
Proc objects.

Personally, I don't care. I have yet to see Object#method or

Rubinius vs JRE

The architecture for Rubinius looks like an exciting enhancement over
MRI in the areas of concurrency and memory management, but I have two
general questions:

1. Will the Rubinius project exist long-term, or will it be
assimilated into MRI or something else
2. How will Rubinius be better than the JRE, other than for directly
supporting Ruby (e.g. java.lang.NullPointerException, system clock
skewing, incompatibility between minor revisions and patch releases,
weekly high severity vulnerability findings, etc.)

--

-- 
--- !ruby/object:MailingList
name: rubinius-dev
view: http://groups.google.com/group/rubinius-dev?hl=en
post: rubinius-dev <at> googlegroups.com
unsubscribe: rubinius-dev-unsubscribe <at> googlegroups.com

Newbie trying to make Module.freeze prevent singleton methods being added

Hey,

I'm fascinated by the project and so decided to try and to some small
stuff. After getting a trivial fix committed, I tried to find
something a bit more challenging, but I may have taken a bite a bit
too big.
Would love some direction about whether my steps are in the right path
and if this is indeed feasible without knowing too much of rubinius's
guts.

I saw that this spec fails: "Module#freeze prevents further
modifications to self"
It basically checks that after freezing a module, trying to define
singleton method on it raises a TypeError.

After some digging and comparing to the MRI I understood that while
MRI freezes the singleton class after freezing an object, rubinius
doesn't.
"Aha!", I thought. After digging, I ended up adding a simple change to
Object#singleton_class, something along the lines of:
    if (this->frozen_p(state) == Qtrue) cl->freeze(state);

This seems to achieve the right result of freezing the singleton
classes just like MRI, but then I found out it doesn't seem like
there's any guard to stop you from adding methods to frozen classes.

What would be the right way to continue from this point? I've tried
adding a trivial guard in Rubinius#add_method that raises the proper
error in case it was called on a frozen object, but then found out
add_method is currently called for lots of frozen objects, which

Interfacing with the Rubinius VM

VM searches for method relying on @superclass ivar, not on Module#direct_superclass. Is it a bug?

Hi!

I tried to play with superclass chain and here is what I've
discovered:

The first example, @superclass is changed and method is being found
correctly:

https://gist.github.com/888224

# Step 1. Setting up environment

class Government
  def power
    "belongs to government"
  end
end

module People
  def power
    "belogs to people"
  end

  Government.__send__ :include, self
end

government = Government.new

# Step 2. Swapping ancestors by re-setting @superclass

included_module = Government.instance_eval { @superclass }

government.metaclass.instance_eval { @superclass = included_module }
included_module.instance_eval { @superclass = Government }
Government.instance_eval { @superclass = Object }

# Step 3. Testing

puts government.metaclass.superclass_chain.inspect
# => [#<IncludedModule People>, Government, Object, #<IncludedModule
Kernel>] <-------- cool, prepended module is before Class
puts government.power
# =>  belongs to people  <--------- this is definitely right

The second example. Module#direct_superclass is changed.
Module#superclass_chain gives correct result, but wrong method is
being called.

https://gist.github.com/888225

module Rubinius
  class PrependedModule < IncludedModule
    attr_reader :module

    def initialize(mod, superclass)
      @module = mod
      @superclass = superclass
      super(mod)
    end

    def inspect
      "#<PrependedModule #{@module.to_s}>"
    end
  end
end

class Module
  attr_reader :prepended_module # for the sake of simplicity let's
take just one for now

  def prepend(mod)
    @prepended_module = Rubinius::PrependedModule.new(mod, self)
  end

  def direct_superclass
    if @superclass && @superclass.prepended_module &&
@superclass.prepended_module != self
      @superclass.prepended_module
    else
      @superclass
    end
  end
end

# -----------------------------------------

class Government
  def power
    "belongs to government"
  end
end

module People
  def power
    "belogs to people"
  end

  Government.prepend self
end

puts Government.new.metaclass.superclass_chain.inspect
# => [#<PrependedModule People>, Government, Object, #<IncludedModule
Kernel>]      <----- looks good, but...
puts Government.new.power
# => belongs to government              <---- ...is this right? ;)

So, I actually have two questions:
1) Is it a bug?
2) If it has been done intentionally, then  is there better way
manipulate superclass chain?

Thanks,
Daniel Vartanov.

--

-- 
--- !ruby/object:MailingList
name: rubinius-dev
view: http://groups.google.com/group/rubinius-dev?hl=en
post: rubinius-dev <at> googlegroups.com
unsubscribe: rubinius-dev-unsubscribe <at> googlegroups.com

Kernel#gsub not working properly with a block

FFI:FileProcessor, etc and Windows

Hello,

I'm checking out hydra branch and wanted to help, but encountered some
changes in the architecture that wanted to ask about.

Seems there are two places FFI::Generators::Structure is been used:
one to generate platform.conf (rakelib/platform.rake) and the other
through FFI::FileProcessor::Task (invoked in rakelib/vm.rake)

The first one, it uses .rb.ffi to extract @@@ constants and structure
definitions and generate the proper .rb file, the second one, is is
coded directly in platform.rake.

Now, on Windows, pwd.h and grp.h do not exist, and etc is a complete
different thing, sames goes for syslog.

On platform.rake is easy to conditionally select header files, since
we have access to BUILD_CONFIG, but in the case of .rb.ffi, is not
clear what can be considered a good code to be evaluated and
conditions inside the @@@ blocks.

Any ideas to approach this? I believe etc and syslog are just two
examples, but will be great have an overall approach to these cases.

Thank you.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

--

-- 
--- !ruby/object:MailingList
name: rubinius-dev
view: http://groups.google.com/group/rubinius-dev?hl=en
post: rubinius-dev <at> googlegroups.com
unsubscribe: rubinius-dev-unsubscribe <at> googlegroups.com

Feature requests - perpetual thread

Volume on this list is low enough that I'm going to use it as a backup brain for a few requests.

PROFILER

1. A good chunk of the C-api in Rubinius is implemented as a rb_funcall back into a pure Ruby path. None of
these paths show up during profiling. It would be great if they did show up so that it is easier to identify
"slow paths" in C extensions.

2. On hydra (no-GIL branch) it would be interesting if there were an additional cli flag
(-Xprofiler.by_thread ?) that would separate the statistics by thread. This sounds difficult, but it
would be a helpful tool for identifying "hot" threads in a multi-threaded app. Additionally, it could
probably help identify hot methods / bottlenecks where multiple threads come together for synchronization.

That's all for the moment.

cr

--

-- 
--- !ruby/object:MailingList
name: rubinius-dev
view: http://groups.google.com/group/rubinius-dev?hl=en
post: rubinius-dev <at> googlegroups.com
unsubscribe: rubinius-dev-unsubscribe <at> googlegroups.com

Rubinius Contribute to Open Source Session at upcoming Red Dirt RubyConf

We're excited to have Brian Ford come talk about the Future of
Rubinius and ways to contribute to this great open source project.
http://reddirtrubyconf.com/presentations/the-joy-of-rubinius-the-agony-of-rubyspec

---

Red Dirt RubyConf Program and Registration

We are proud to announce the Red Dirt RubyConf 2011 program.
http://reddirtrubyconf.com/schedule

Red Dirt is a content rich two-day conference to be held in
Oklahoma City on April 21st and 22nd, 2011. The conference
program focuses on four themes including Ruby Implementations,
Rails Extentions, Rails Redux and Javascript. We have 2 keynotes,
6 training tracks and 3 contribute to open source tracks.

http://reddirtrubyconf.com/

Red Dirt has one of the best conference lineups that you will
see at any Ruby conference. Our speakers are world-class contributors
in the Ruby and Javascript communities working for leaders in the
industry including Obtiva, Intridea, AT&T Interactive,
Hewlett Packard, Heroku, ThoughtBot, and Engine Yard.

Red Dirt prides itself on being an all inclusive event.
From beginning to end, this will be a great experience.
You will have some of the best food you have ever had,
there will be entertainment and plenty of time and
comfortable space to meet, interact and learn from
Ruby leaders and Heros.

Registration is now open: http://reddirtrubyconf.com/program

Don't miss early bird registration which ends March 1st.

Can't make it? Catch the live video stream or get the conference
videos!
http://reddirtrubyconf.com/program

--

-- 
--- !ruby/object:MailingList
name: rubinius-dev
view: http://groups.google.com/group/rubinius-dev?hl=en
post: rubinius-dev <at> googlegroups.com
unsubscribe: rubinius-dev-unsubscribe <at> googlegroups.com

rbx-trepanning 0.0.4 adds syntax highlighting (via coderay) and remote debugging