Forum: Ruby web framework for Ruby 1.9

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Stefan L. (Guest)
on 2008-11-15 01:46
(Received via mailing list)
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:

4) doesn't follow the "let's extend core classes whenever possible"
craze

5) 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
Ara H. (Guest)
on 2008-11-15 04:43
(Received via mailing list)
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/
Stefan L. (Guest)
on 2008-11-15 12:56
(Received via mailing list)
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.

<rant>
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!
</rant>

Stefan
Ara H. (Guest)
on 2008-11-15 18:36
(Received via mailing list)
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!
> </rant>
>
> 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/
Jeremy K. (Guest)
on 2008-11-15 22:40
(Received via mailing list)
On Fri, Nov 14, 2008 at 3:42 PM, Stefan L.
<removed_email_address@domain.invalid> wrote:
> 4) doesn't follow the "let's extend core classes whenever possible" craze
>
> 5) 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
Stefan L. (Guest)
on 2008-11-16 14:43
(Received via mailing list)
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
Peter B. (Guest)
on 2008-11-16 22:05
(Received via mailing list)
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>
Stefan L. (Guest)
on 2008-11-16 22:47
(Received via mailing list)
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
Charles Oliver N. (Guest)
on 2008-11-17 00:07
(Received via mailing list)
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 :)

- Charlie
Michael F. (Guest)
on 2008-11-17 01:44
(Received via mailing list)
On Sat, Nov 15, 2008 at 7:52 PM, Stefan L.
<removed_email_address@domain.invalid> wrote:
>>> 3) 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!
> </rant>

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

^ manveru
This topic is locked and can not be replied to.