Which project should I work on?

[rogerdpack]

I was wondering on any feedback on which of the following pet projects
would be most helpful to the community.

1. create [another] ruby JIT
   There are some ideas that could speed up the tired old VM [and the new
   VM]. Speed is good, right?

2. Documentation: hack on rdoc with a few things – some bugs, update
   the hanna template so that it looks prettier, create a live method
   introspection gem, add remote ri gem, etc.

3. hack on the KRI GC. I think I might be able to run the sweep phase
   in a separate thread, thus speeding up GC.

4. create a ruby tutorial gem, which supplements the RI information for
   core class by adding tutorials to them [yea!]. It would be wiki
   editable and every so often the wiki content snurfed up and packaged
   into a gem with only documentation in it [no real code]. That’s the
   initial thought anyway.

5. create gem plugin to add pre-install hooks [ex: “apt-get install
   some_dependency”]

6. create an “optimized” edition of Ruby–i.e. an REE but for 1.9 [so
   tcmalloc, tuned GC to start, GCC profile optimized, etc.]

7. try to crack down and kill some of the outstanding bugs in the core.

8. try to update mod_rails to allow for “per virtualhost”
   PassengerMaxInstancesPerApp

9. a ruby optimizing pre processor
   converts things like
   def go
   if a == ‘3’
   end
   end

to

@_3 = ‘3’
def go
if a == @_3
end
end

Thus avoiding extra allocations [also an optimized erb].

10. try to optimize rails [is there much possible there though?]

So anyway feel free to vote on your favorite [+1 it] and say why. I
don’t want to work on something that people don’t feel is important

Here’s my own:
+1 for number 1. It might be useful across ruby implementations, and
would make ruby look better in synthetic benchmarks.

Thanks.

=r

[rogerdpack]

huh, a toughy, but I’d vote +1 for

7. try to crack down and kill some of the outstanding bugs in the core

killing bugs is never a bad idea after all

Greetz

[rogerdpack]

Roger P. wrote:

def go
if a == @_3
end
end

Is that really faster? Even so, what is the effect of many such
conversions (hence many ivars) on ivar lookup time and on object size?

[rogerdpack]

2009/7/10 Roger P. [email protected]:

I was wondering on any feedback on which of the following pet projects
would be most helpful to the community.

Here’s my own:
+1 for number 1. It might be useful across ruby implementations, and
would make ruby look better in synthetic benchmarks.

Thanks for this opportunity: I always wanted to try out how good
Doodle works. I took the liberty to set up a doodle at

Expired Group Poll - Create a New Poll or Contact the Owner

Happy voting!

Kind regards

robert

[rogerdpack]

On Sat, Jul 11, 2009 at 12:36 AM, Roger P.[email protected]
wrote:

Also if anybody wants to vote for it, could hack on the redcar editor or
arcadia in the hopes of someday creating an editor

+1
and make them 1.9 ready, pls

[rogerdpack]

Joel VanderWerf wrote:

Roger P. wrote:

def go
if a == @_3
end
end

Is that really faster? Even so, what is the effect of many such
conversions (hence many ivars) on ivar lookup time and on object size?

def go; ‘3’; end
Benchmark.realtime { 1000000.times { go }}
=> 0.40625

@_3 = ‘3’.freeze
def go2; @_3; end
Benchmark.realtime { 1000000.times { go2 }}
=> 0.359375

So…just barely [plus saving on the GC a bit].

Also if anybody wants to vote for it, could hack on the redcar editor or
arcadia in the hopes of someday creating an editor equal to the great
TextMate [except free, open source, and cross platform]

Just +1 it here

=r

[rogerdpack]

ah, vim is all I need…

2009/7/10 botp [email protected]

[rogerdpack]

Roger P. wrote:

4. create a ruby tutorial gem, which supplements the RI information for
   core class by adding tutorials to them [yea!]. It would be wiki
   editable and every so often the wiki content snurfed up and packaged
   into a gem with only documentation in it [no real code]. That’s the
   initial thought anyway.

+1
That’s very useful for newcommers to Ruby and those who don’t want to
write the same things again and again.

Marvin

[rogerdpack]

On Fri, Jul 10, 2009 at 9:10 AM, Roger P.[email protected]
wrote:

10. try to optimize rails [is there much possible there though?]

+1 This more than anything else would aid all Ruby implementations
on all platforms. But it’s obviously a large task. I’d say any help
you can provide Rails folks on moving toward a 3.0 that runs faster,
uses less memory, makes better use of threads, and opens the door to
platform integration (like ActiveORM could wrap Hibernate or JPA), the
better. That’s what I’m going to be looking into.

• Charlie

[rogerdpack]

On Jul 10, 4:10 pm, Roger P. [email protected] wrote:

2. Documentation: hack on rdoc with a few things – some bugs, update
   the hanna template so that it looks prettier, create a live method
   introspection gem, add remote ri gem, etc.

At the moment there is still no (rdoc) documentation for Ruby 1.9.1
available anywhere, so it would be great if that could be improved.

Björn

[rogerdpack]

I’d say, hack on one of the existing ones. Or, if you can, make Rubinius
as
fast as (or faster than) MRI. Hey, shoot the moon!

Yeah it would be a hack to make ruby2cext better [already existing, for
MRI].

This, I’d love to see. REE meaning Ruby Enterprise Edition, right?

Yep.

if (a[0] == ‘3’ && a[1] == NULL)

I’m assuming C strings, Ruby strings might work differently, but you get
the
idea.

That’s a great idea. Avoid ruby calls totally [NB that ruby2cext
already does this for a few things, so…maybe I can just use that].

10. try to optimize rails [is there much possible there though?]

Yes! Happening as part of merging with Merb, I thought. I’d love to see
progress there, though…

Thankfully not many people voted on that one since I didn’t want to
really do it anyway

=r

[rogerdpack]

On Friday 10 July 2009 09:10:57 am Roger P. wrote:

I was wondering on any feedback on which of the following pet projects
would be most helpful to the community.

I can only speak for myself…

1. create [another] ruby JIT
   There are some ideas that could speed up the tired old VM [and the new
   VM]. Speed is good, right?

I’d say, hack on one of the existing ones. Or, if you can, make Rubinius
as
fast as (or faster than) MRI. Hey, shoot the moon!

3. hack on the KRI GC. I think I might be able to run the sweep phase
   in a separate thread, thus speeding up GC.

So, I’d file that with #1.

4. create a ruby tutorial gem, which supplements the RI information for
   core class by adding tutorials to them [yea!]. It would be wiki
   editable and every so often the wiki content snurfed up and packaged
   into a gem with only documentation in it [no real code]. That’s the
   initial thought anyway.

Hmm. Would this be something that could be combined with a Try Ruby
style
tutorial? (tryruby.hobix.net)

5. create gem plugin to add pre-install hooks [ex: “apt-get install
   some_dependency”]

Pre-install hooks? Maybe, though I’d be wary. I like being able to
install a
gem just to read the rdocs.

And that sounds like a TERRIBLE way to do what you’re trying to do, by
the
way. I know gems doesn’t already do this, but what about reverse
dependencies?
What about portability?

Find me an example of a pre-installation script that isn’t better done
some
other way.

6. create an “optimized” edition of Ruby–i.e. an REE but for 1.9 [so
   tcmalloc, tuned GC to start, GCC profile optimized, etc.]

This, I’d love to see. REE meaning Ruby Enterprise Edition, right?

+1 here.

7. try to crack down and kill some of the outstanding bugs in the core.

Always a good idea, but I’m guessing there are people on that. Anyone
doing a
Ruby Enterprise Edition for 1.9?

def go
if a == @_3
end
end

I’d do that in the VM, if you can. Especially seeing as there’s no way
to tell
if your example is universally faster – it necessarily adds an instance
variable. A particularly intelligent optimization might notice that this
string is only ever used for the one comparison, so as long as String
isn’t
messed with, it could be converted into code like the following C:

if (a[0] == ‘3’ && a[1] == NULL)

I’m assuming C strings, Ruby strings might work differently, but you get
the
idea.

10. try to optimize rails [is there much possible there though?]

Yes! Happening as part of merging with Merb, I thought. I’d love to see
progress there, though…

[rogerdpack]

x = 0
foo = lambda { x += 5 }
5.times do
foo.call
end

into something more like this:

x = 25

Of course, that optimization only makes sense if no one’s making changes
to
the Proc class, or to the scope in which that’s run – or maybe we’re
actually
storing ‘foo’ deep in some object, where it probably won’t be touched,
but it
might.

Good point. If there aren’t any class changes you’d think a number of
optimizations would be possible.
=r

[rogerdpack]

On Saturday 11 July 2009 08:17:54 pm Roger P. wrote:

if (a[0] == ‘3’ && a[1] == NULL)

I’m assuming C strings, Ruby strings might work differently, but you get
the
idea.

That’s a great idea. Avoid ruby calls totally [NB that ruby2cext
already does this for a few things, so…maybe I can just use that].

Maybe. The point was to do this at runtime, in the VM. I don’t think all
Ruby
code can be easily converted to C, nor would I want to (I like having
‘eval’
work). But looking at the AST, or even the bytecode representation, this
kind
of thing should be possible to figure out.

Other ideas would be to do clever runtime optimizations, or to do
optimizations that wouldn’t be sane at compile time – for instance,
unroll
this:

x = 0
foo = lambda { x += 5 }
5.times do
foo.call
end

into something more like this:

x = 25

Of course, that optimization only makes sense if no one’s making changes
to
the Proc class, or to the scope in which that’s run – or maybe we’re
actually
storing ‘foo’ deep in some object, where it probably won’t be touched,
but it
might.

All of these are dangerous assumptions to make at compile time, but at
runtime, it might be reasonable to say “If any of these assumptions
change,
drop the optimized version and do it the slow way.”

But I am in a bit over my head, here – I only know in theory how
compilers
and VMs work; I’ve never actually contributed to one.

[rogerdpack]

Create a package like pythons multiprocessing to make multi -process
code
easier in ruby and also to unify the programming model between windows
and
unix variants.

[rogerdpack]

Create a package like pythons multiprocessing to make multi -process
code
easier in ruby and also to unify the programming model between windows
and
unix variants.

A great suggestion.

Any +1’s for it?

I had considered something like it but forgot about it. My first
thought was to wrap the apache runtime calls so that forked processes
could have shared mutexes, shared memory, etc.

However I couldn’t think of…how it would actually be useful in day to
day–would it be? In what circumstances? (just wondering)

Also, can windows actually do something like
a = 3
Thread.new { # other process }
b = 3

? like shared startup state? huh? is that even possible? (just thinking
about how Python’s multi process does things–it seems to allow for
something like that and I’m not sure how).

A search for process gems [1] seems to reveal a few that make forking
more convenient, and I’ve used them before. Would more convenience be
useful, is the question.

?

=r

[1]
http://allgems.ruby-forum.com/gems?search=fork
and
http://allgems.ruby-forum.com/gems?search=process
there are some shared memory gems, it appears, as well
http://allgems.ruby-forum.com/gems?search=memory
google “ruby mmap” and

GitHub - espace/sysvipc-0.8-rc1: SystemVIPC release compatible for Ruby 1.8 and...

[rogerdpack]

Well, in your example, you used threads, and I’m not entirely sure how
it’s
possible. Pretty much by definition, processes don’t share state,
threads do.

There are exceptions – shared memory, the filesystem, and other
well-defined
interfaces – but languages generally don’t make these things obvious.

Hmm. If that’s the case than perhaps the python multi process gem
only shares memory among processes. I suppose I could dig into its
source if needed. Maybe even reuse it!

Regardless, any +1’s for my working on this one?, or am I right that it
isn’t in strong demand?

=r

[rogerdpack]

Dominic S. wrote:

Create a package like pythons multiprocessing to make multi -process
code
easier in ruby and also to unify the programming model between windows
and
unix variants.

I am quite interested in multiprocessings

“A manager object returned by Manager() controls a server process which
holds Python objects and allows other processes to manipulate them using
proxies.”

I envision refitting drb so that you can do something like
global_store = SharedHash.new

global_store[:shared_var] = 3
global_store[:shared_var2] = 3

Process.fork {
proxy = global_store[:shared_var] # drb proxy object to the ‘3’ in the
main class
proxy.to_s # proxy method call with marshalling, etc.
}

i.e. a multi-process friendly wrapper for drb to make it “easy to use
among forked children”

I think this would allow for cross process mutexes
(global_store[:mutex1] = Mutex.new; global_store[:mutex1].synchronize {}
)

Thoughts? Would this be useful to anyone?
=r

[rogerdpack]

On Sunday 12 July 2009 05:41:05 pm Roger P. wrote:

Also, can windows actually do something like
a = 3
Thread.new { # other process }
b = 3

? like shared startup state? huh? is that even possible? (just thinking
about how Python’s multi process does things–it seems to allow for
something like that and I’m not sure how).

Well, in your example, you used threads, and I’m not entirely sure how
it’s
possible. Pretty much by definition, processes don’t share state,
threads do.
There are exceptions – shared memory, the filesystem, and other
well-defined
interfaces – but languages generally don’t make these things obvious.

If you’re wanting something like your example, you’re wanting threads,
and
you’re getting all of the concurrency issues that threads have that
processes
generally don’t.

[rogerdpack]

All righty the results are in.

You said:

YARJIT [Yet Another Ruby JIT]
4

Documentation enhancements:
10

KRI GC improvements:
5

Tutorial gem:
6

pre-install gem hooks:
1 [yea!]

REE for 1.9
6

Try to crack down on core bugs:
10

update mod_rails
1

ruby optimized pre-processor
2

try to optimize rails
3

So the winners are Documentation and core bugs. Both already have
maintainers but I’ll see what I can do.

Current plan for documentation:
create #desc methods for classes and methods [i.e. “String.desc, String.desc_method :strip”] [1]
update Hanna template to be more space friendly
try to see if I can fix some odd ambiguities in the ruby core docs

Would remote ri be useful to anyone?

Current plan for core bugs:
Are there any outstanding that people would have me work on? Any
RCR’s you’d like me to submit to core? I’m currently not annoyed too bad
by any bugs, but if there are some I could give them a whack.

Thanks for the input.

[1] http://github.com/rogerdpack/desc_methods/tree/master though it’s
not perfect yet