Web framework for Ruby 1.9


#1

I’m looking for a web framework that:

  1. really works with Ruby 1.9

  2. pure Ruby code (i.e. doesn’t depend on C-extensions, Java
    libraries…)

  3. has an active community

bonus points:

  1. doesn’t follow the “let’s extend core classes whenever possible”
    craze

  2. good postgres support

Does such a framework exist or am I asking for too much?

Actually I would use Rails, the latest RC is advertised as Ruby 1.9
compatible but I’ve immediately hit a couple of errors and I
don’t have the time ATM to fix compatibility errors in such a big
codebase and push the changes upstream. What’s more, the pure
Ruby postgres driver doesn’t work anymore.

Merb fails with syntax errors with Ruby 1.9.

Thanks,
Stefan


#2

On Nov 14, 2008, at 4:42 PM, Stefan L. wrote:

codebase and push the changes upstream. What’s more, the pure
Ruby postgres driver doesn’t work anymore.

Merb fails with syntax errors with Ruby 1.9.

Thanks,
Stefan

it’s called ramaze.

a @ http://codeforpeople.com/


#3

2008/11/15 ara.t.howard removed_email_address@domain.invalid:

don’t have the time ATM to fix compatibility errors in such a big
codebase and push the changes upstream. What’s more, the pure
Ruby postgres driver doesn’t work anymore.

Merb fails with syntax errors with Ruby 1.9.

Thanks,
Stefan

it’s called ramaze.

Thanks. At least a basic app works fine in Ruby 1.9,
installation is simple, only dependency rack and
colored console output. Neat.

But what the hell is with all these extensions to core classes.
acquire __DIR__/"*.rb"

Thats Kernel#acquire, Kernel#DIR, Symbol#/
and String#/. What’s wrong with a simple:

Ramaze::Utils.acquire_relative "*.rb"

There is nothing modular about putting arbitrary
utility methods into core classes!

Stefan


#4

On Fri, Nov 14, 2008 at 3:42 PM, Stefan L.
removed_email_address@domain.invalid wrote:

  1. doesn’t follow the “let’s extend core classes whenever possible” craze

  2. good postgres support

Does such a framework exist or am I asking for too much?

Rails satisfies all 5 for me, but you may find Active Support adds too
much for your taste.

Actually I would use Rails, the latest RC is advertised as Ruby 1.9
compatible but I’ve immediately hit a couple of errors and I
don’t have the time ATM to fix compatibility errors in such a big
codebase and push the changes upstream. What’s more, the pure
Ruby postgres driver doesn’t work anymore.

What’d you run into? The only outstanding compatibility issue I have
is with the test/unit -> minitest change.

Rails has been chasing 1.9 compatibility like a drowning man gulps for
air. Luckily the recent feature freeze means we’re close to having dry
land underfoot.

The latest postgres-pr works, btw. The earlier driver was missing the
#transaction_status method.

Merb fails with syntax errors with Ruby 1.9.

Thanks,
Stefan

Best,
jeremy


#5

On Nov 15, 2008, at 3:52 AM, Stefan L. wrote:

Thats Kernel#acquire, Kernel#DIR, Symbol#/
and String#/. What’s wrong with a simple:

Ramaze::Utils.acquire_relative “*.rb”

There is nothing modular about putting arbitrary
utility methods into core classes!

Stefan

perhaps - but there are far less than in any other ruby framework.
also DIR and the ‘/’ string join i think are planned for a future
ruby release…

a @ http://codeforpeople.com/


#6

2008/11/15 Jeremy K. removed_email_address@domain.invalid:

bonus points:
Actually I would use Rails, the latest RC is advertised as Ruby 1.9
compatible but I’ve immediately hit a couple of errors and I
don’t have the time ATM to fix compatibility errors in such a big
codebase and push the changes upstream. What’s more, the pure
Ruby postgres driver doesn’t work anymore.

What’d you run into? The only outstanding compatibility issue I have
is with the test/unit -> minitest change.

  • Creating an app failed with an exception. Installing the test-unit
    gem fixed that.

  • Booting the application failed because config/boot.rb depends
    on a Gem::RubyGemsVersion that is not defined in the RubyGems 1.3.1
    that comes with Ruby 1.9.1 (I’ve got a fairly recent build from the
    1_9_1
    branch). I fixed that by constantly returning “1.3.1” from
    rubygems_version.

  • Freezing rails failed with missing method in RubyGems. Didn’t find
    a fix for that.

  • Rails didn’t use the postgres-pr driver I installed with “gem
    install”.
    (And that wasn’t a RubyGems issue, it didn’t work with postgres-pr
    in vendor either). Neither ruby-postgres nor pg built with Ruby 1.9.

Rails has been chasing 1.9 compatibility like a drowning man gulps for
air. Luckily the recent feature freeze means we’re close to having dry
land underfoot.

The latest postgres-pr works, btw. The earlier driver was missing the
#transaction_status method.

Great, where can I get that version?

Stefan


#7

I’m just curious, why would you use 1.9 if JRuby has rails support?
The support tools, native threads and performance would seem
compelling (I’m still on 1.8.6).

Sent from my iPhone

On Nov 15, 2008, at 3:36 PM, “Jeremy K.” removed_email_address@domain.invalid


#8

Stefan L. wrote:

There’s Ruby 1.9, the language and then there are
implementations. JRuby lags behind in 1.9 compatibility
(understandably, because 1.9 has been in flux until very
recently).

Ruby 1.9 has some nice features like the encoding support
and the earlier the Ruby community migrates, the better.

We’ve already started adding 1.9 support and the plan is to have it done
around the time of the 1.9.1 final release at Christmas. The
parser+interpreter are almost done, compiler will follow that. Some core
library changes have been migrated already, and M17N (new String) is
under way.

I agree there are some compelling features in 1.9, and 1.9.1 being the
first real feature-frozen release makes it a good time for us to get
JRuby to support it. You can test out what works in 1.1.5 by passing
–1.9 flag…but a lot more will be in 1.1.6.

Regarding performance, I have a rails app running on
JRuby and it’s actually slightly slower than MRI 1.8.

You may want to try 1.1.5…we’ve gotten reports that it’s quite a bit
faster than 1.1.4. At any rate, we’re making a big performance push
specifically targeted at Rails, which seems to do something we’re a bit
slower at. We’ll find it. Any information you can feed us (like specific
parts of the app that are slower, etc) would be of great help :slight_smile:

  • Charlie

#9

On Sat, Nov 15, 2008 at 7:52 PM, Stefan L.
removed_email_address@domain.invalid wrote:

  1. has an active community
    compatible but I’ve immediately hit a couple of errors and I
    it’s called ramaze.

Thats Kernel#acquire, Kernel#DIR, Symbol#/
and String#/. What’s wrong with a simple:

Ramaze::Utils.acquire_relative “*.rb”

There is nothing modular about putting arbitrary
utility methods into core classes!

Thanks for your feedback, I’ll address these things.
At least acquire will become Ramaze::acquire, I think the String#/ and
Symbol#/ are quite useless as well, given that File.join never changes
the separator no matter which platform, so we can deprecate them as
well.
But DIR, I will keep that one around, it’s a proposed feature
since quite some time and chances are high that it will be added to
ruby sometime in the future.

Please note that all methods added to core classes are kept in their
own modules and will never cause any overwrites of existing methods.
See http://github.com/manveru/ramaze/tree/master/lib/ramaze/snippets.rb

^ manveru


#10

2008/11/16 Peter B. removed_email_address@domain.invalid:

I’m just curious, why would you use 1.9 if JRuby has rails support? The
support tools, native threads and performance would seem compelling (I’m
still on 1.8.6).

There’s Ruby 1.9, the language and then there are
implementations. JRuby lags behind in 1.9 compatibility
(understandably, because 1.9 has been in flux until very
recently).

Ruby 1.9 has some nice features like the encoding support
and the earlier the Ruby community migrates, the better.

Regarding performance, I have a rails app running on
JRuby and it’s actually slightly slower than MRI 1.8.

Stefan