which project should I work on?

[Roger Pack]

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

 

[Robert Klemme]

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. =A0It 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
http://doodle.com/wwhedcavpte9ptan

Happy voting!

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 

[Fabian Streitel]

[Note: parts of this message were removed to make it a legal post.]

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

 

[Joel VanderWerf]

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

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?

 

[Roger Pack]

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?

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

 

[botp]

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

 

[Fabian Streitel]

[Note: parts of this message were removed to make it a legal post.]

ah, vim is all I need... ;-)

 

[Marvin Gülker]

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

 

[David Masover]

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?

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

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

 

[Charles Oliver Nutter]

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

 

[Bjoern]

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

 

[Roger Pack]

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

 

[David Masover]

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.

 

[Roger Pack]

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

 

[Dominic Sisneros]

[Note: parts of this message were removed to make it a legal post.]

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.

 

[Roger Pack]

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
http://github.com/espace/sysvipc-0.8-rc1/tree/master

 

[David Masover]

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.

 

[Roger Pack]

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

 

[Roger Pack]

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

 

[Roger Pack]

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