Nabble - RubyOnRails Core

Re: Site-wide memcaching

2008-11-18T14:06:15Z

On Nov 18, 10:58 pm, "Michael Koziarski" <mich...@...>
wrote:
> Just use your own code rather than Rails.cache. For one of myprojects I have
>
> QUEUE = MemCache.new("localhost:22122")
>
> And use that from code. No need to do anything with Rails.cache at all.

Actually you might be interested in
ActiveSupport::Cache::MemCacheStore instead. It wraps the memcache
library and provides an interface that's compatible with Rails.cache's.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Site-wide memcaching

2008-11-18T13:58:43Z

On Tue, Nov 18, 2008 at 10:54 PM, Norman Elton <normelton@...> wrote:

>
> I know I can configure Rails.cache to be backed by memcache, and that
> I can configure multiple memcache servers for load balancing. Is there
> any way to configure multiple instances of Rails.cache? In this case,
> I'd like my application to use a standard memcache server, as well as
> a starling server.
>
> Ideally, something like Rails.cache[:memcache] vs.
> Rails.cache[:starling] would point to different servers.
>
> Thoughts?

Just use your own code rather than Rails.cache. For one of myprojects I have

QUEUE = MemCache.new("localhost:22122")

And use that from code. No need to do anything with Rails.cache at all.

> Thanks!
>
> Norman
>
> >
>

--
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Site-wide memcaching

2008-11-18T13:54:21Z

I know I can configure Rails.cache to be backed by memcache, and that
I can configure multiple memcache servers for load balancing. Is there
any way to configure multiple instances of Rails.cache? In this case,
I'd like my application to use a standard memcache server, as well as
a starling server.

Ideally, something like Rails.cache[:memcache] vs.
Rails.cache[:starling] would point to different servers.

Thoughts?

Thanks!

Norman

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Quick Routing Bug Fix

2008-11-18T13:46:18Z

Sorry, I actually had that in a local branch! Applied and merged to 2-2

On Tue, Nov 18, 2008 at 10:36 PM, dasil003 <gabriel.d@...> wrote:

>
> Alright, let me try again. Did you know that:
>
> film_url(@film, :protocol => 'https')
>
> doesn't work? Does that sound like it might blindside you at some
> point in the future? Check out my patch.
>
> On Nov 14, 1:30 am, dasil003 <gabrie...@...> wrote:
>> This should be pretty straightforward. 5 virtual peanuts to the first
>> reviewer:
>>
>> http://rails.lighthouseapp.com/projects/8994/tickets/1375-fix-reserve...
> >
>

--
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Quick Routing Bug Fix

2008-11-18T13:36:40Z

Alright, let me try again. Did you know that:

film_url(@film, :protocol => 'https')

doesn't work? Does that sound like it might blindside you at some
point in the future? Check out my patch.

On Nov 14, 1:30 am, dasil003 <gabrie...@...> wrote:
> This should be pretty straightforward. 5 virtual peanuts to the first
> reviewer:
>
> http://rails.lighthouseapp.com/projects/8994/tickets/1375-fix-reserve...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: About HTML attributes with the value 'false'

2008-11-18T11:53:11Z

On Nov 18, 8:27 pm, "Mislav Marohnić" <mislav.maroh...@...>
wrote:

> Thanks Koz for a brief and Hongli for more detailed explanation, but I don't
> think you got my question right.
>
> You guys are talking about (hidden) textual form controls that map to
> booleans. That's fine. I'm talking about HTML attribute serialization in
> general, meaning *everything besides* textual form controls mapping to
> booleans, and why I think this commit should be reverted. This is the
> reason:
>
> <% tag :input, :type => "checkbox", :checked => false %>
>
> Who here thought that this creates a text input that isn't checked? Well,
> you thought wrong. This generates an initially checked box.

Good point. This has been fixed in
http://github.com/rails/rails/commit/0f89ed5636f69c7ae75f99ca2a613b1918de5f95

I've registered 'checked' as a boolean HTML attribute so that it
doesn't get outputted when its value is false. If you encounter more
problems, then please suggest more attributes to register as boolean
HTML attributes.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: About HTML attributes with the value 'false'

2008-11-18T11:33:15Z

> <% tag :input, :type => "checkbox", :checked => false %>
> Who here thought that this creates a text input that isn't checked? Well,
> you thought wrong. This generates an initially checked box.

OK, I now follow you. A patch to fix this would be appreciated :)

--
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: About HTML attributes with the value 'false'

2008-11-18T11:27:52Z

2008/11/14 Hongli Lai <hongli@...>

Before this commit, the hidden_field helper would output:
<input type="hidden" name="person[is_alien]" />
As you can see, there's no "value" attribute. Upon submitting the
form, @person.is_alien would be set to nil instead of the expected
false, causing an SQL error. This is solved by making hidden_field
output value="false":
<input type="hidden" name="person[is_alien]" value="false" />

Thanks Koz for a brief and Hongli for more detailed explanation, but I don't think you got my question right.

You guys are talking about (hidden) textual form controls that map to booleans. That's fine. I'm talking about HTML attribute serialization in general, meaning *everything besides* textual form controls mapping to booleans, and why I think this commit should be reverted. This is the reason:

<% tag :input, :type => "checkbox", :checked => false %>

Who here thought that this creates a text input that isn't checked? Well, you thought wrong. This generates an initially checked box.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: should ActiveRecord::AssociationProxy#reload allow options?

2008-11-18T11:00:15Z

Sweet, Koz, thanks a lot.

Looking at the AssociationProxy implementation I don't quite know how
I'd go about refactoring that #reload method to work like
AR::Base#reload. To be honest, I hadn't noticed the lock! method
before and now that you've pointed it out I'll probably just stick to
it. lock! is more intention revealing anyways so I'm happy to use it
in favor of reload and ignore the reload problem for the time being :)

Cheers,
Andrew

On Nov 18, 10:24 am, "Michael Koziarski" <mich...@...>
wrote:

> > So, long story short, the implementation of AssociationProxy exposes
> > itself when using the #reload(:lock => true) technique to elevate a
> > lock. My question to the core is whether or not this is an acceptable
> > side effect of the implementation? In particular, I am curious if
> > using this #reload method of lock escalation is a supported mode of
> > operation, or is there some other means to the same end that is better
> > supported by ActiveRecord? For instance, I suppose I could do this
> > (hopefully the formatting on this doesn't get bojacked):
>
> Nice find, that's definitely not an acceptable side-effect of the
> implementation. A patch to address this would be great.
>
> In the meantime you can use @record.whatever.lock! which will behave
> as expected.
>
> --
> Cheers
>
> Koz

Re: should ActiveRecord::AssociationProxy#reload allow options?

2008-11-18T10:24:25Z

> So, long story short, the implementation of AssociationProxy exposes
> itself when using the #reload(:lock => true) technique to elevate a
> lock. My question to the core is whether or not this is an acceptable
> side effect of the implementation? In particular, I am curious if
> using this #reload method of lock escalation is a supported mode of
> operation, or is there some other means to the same end that is better
> supported by ActiveRecord? For instance, I suppose I could do this
> (hopefully the formatting on this doesn't get bojacked):

Nice find, that's definitely not an acceptable side-effect of the
implementation. A patch to address this would be great.

In the meantime you can use @record.whatever.lock! which will behave
as expected.

--
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

should ActiveRecord::AssociationProxy#reload allow options?

2008-11-18T10:12:00Z

Hi All,

Recently, in the AR AsscociationProxy class, my colleague and I came
across a case that seems to be a violation of the principle of least
surprise.

The problem shows itself when trying to take out an elevated lock on
an ActiveRecord#Base object: 'ar_obj.reload(:lock => true)'. In
general, this works fine. However, if the ar_obj object was not
created directly, but instead came from an association proxy off some
other AR#base object, then we have a problem. Since AssociationProxy
defines its own (no-arg) version of #reload we hit a "wrong number of
arguments error" because the object we're calling the method on is of
type AssociationProxy, not AR:Base. Thank the stars that the AP#reload
method doesn't take an options hash, if that were the case it could be
possible to go forward thinking the object was having its lock
elevated as expected. With the problem understood it was easy enough
to work around by checking if the object had a #target method and
using that target object directly if it did.

So, long story short, the implementation of AssociationProxy exposes
itself when using the #reload(:lock => true) technique to elevate a
lock. My question to the core is whether or not this is an acceptable
side effect of the implementation? In particular, I am curious if
using this #reload method of lock escalation is a supported mode of
operation, or is there some other means to the same end that is better
supported by ActiveRecord? For instance, I suppose I could do this
(hopefully the formatting on this doesn't get bojacked):
<pre>
def do_stuff_with_lock(ar_or_ap_object)
transaction do
ar_or_ap_object.class.find(ar_or_ap_object.id, :lock => true)
# do stuff with ar_or_ap_object
ar_or_ap_object.save
end
end
</pre>

Cheers,
Andrew
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: tzinfo-0.3.11 bundled with activesupport-2.1.2 is incomplete

2008-11-18T08:56:29Z

On Tue, Nov 18, 2008 at 8:57 AM, Geoff B <gbuesing@...> wrote:

Adam and Chad -- curious to know if this setup would work for you:

I was just bikeshedding about the dubiousness of bundling a hacked version of a dependency gem in another gem, and adding code manage the resulting problems. I didn't actually have a personal problem (with tzinfo). Thanks, though :)

Re: tzinfo-0.3.11 bundled with activesupport-2.1.2 is incomplete

2008-11-18T07:57:40Z

Adam and Chad -- curious to know if this setup would work for you:

I pulled together a version of tzinfo that has all the stuff (classes,
definitions, indexes) that's *not* in the slimmed-down ActiveSupport
version:

http://github.com/gbuesing/tzinfo_completer
(works as a plugin: I tried to make a gem of it, but github won't let
me use fileutils in the gemspec)

...seems to work, given my limited testing. With this setup, you can
effectively have access to the full gem, and updates to the bundled
version won't break it. Also slims down your app repository a bit,
since you don't have to duplicate tzinfo files that are already
bundled in AS.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Test::Unit::TestCase refactoring

2008-11-17T15:28:26Z

Yes; thanks: 5a4789e :)

jeremy

On Mon, Nov 17, 2008 at 2:03 PM, Matt Jones <al2o3cr@...> wrote:

>
> The relevant line (from railties test_help.rb) was deleted in commit
> 582aa2ead58eacffca13e7efe94235958ee4db1b
> on November 7 - should that be put back?
>
> --Matt
>
> On Nov 17, 2008, at 4:39 PM, Jeremy Kemper wrote:
>
>>
>> On Mon, Nov 17, 2008 at 1:26 PM, Matt Jones <al2o3cr@...> wrote:
>>> Found it - in activesupport/lib/active_support/test_case.rb, test/
>>> unit
>>> needs to be required,
>>> or the tests don't get run. Add "require 'test/unit'" after "rescue
>>> LoadError".
>>
>> It's required in railties' test_help.
>>
>> Otherwise, requiring 'active_support/test_case' will tests even if you
>> didn't mean to.
>>
>> jeremy
>>
>> >
>
>
> >
>

asset_host with Proc and mailer templates

2008-11-17T14:07:50Z

If asset_host is set as a 2 arguement Proc, asset tag helpers will
fall over at compute_asset_host when called from mailer views because
Mailers do not have access to a request object.

I've created a small patch that modifies compute_asset_host to return
nil in place of a request object if it's not present:

http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1394-compute_asset_host-bombs-when-asset_host-proc-and-called-from-a-mailer

This way, if your using asset tag helpers in your mailer views, you
can write your Proc to deal with nil requests and all is well!

Tekin Suleyman

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Test::Unit::TestCase refactoring

2008-11-17T14:03:37Z

The relevant line (from railties test_help.rb) was deleted in commit
582aa2ead58eacffca13e7efe94235958ee4db1b
on November 7 - should that be put back?

--Matt

On Nov 17, 2008, at 4:39 PM, Jeremy Kemper wrote:

>
> On Mon, Nov 17, 2008 at 1:26 PM, Matt Jones <al2o3cr@...> wrote:
>> Found it - in activesupport/lib/active_support/test_case.rb, test/
>> unit
>> needs to be required,
>> or the tests don't get run. Add "require 'test/unit'" after "rescue
>> LoadError".
>
> It's required in railties' test_help.
>
> Otherwise, requiring 'active_support/test_case' will tests even if you
> didn't mean to.
>
> jeremy
>
> >

Re: Test::Unit::TestCase refactoring

2008-11-17T13:39:50Z

On Mon, Nov 17, 2008 at 1:26 PM, Matt Jones <al2o3cr@...> wrote:
> Found it - in activesupport/lib/active_support/test_case.rb, test/unit
> needs to be required,
> or the tests don't get run. Add "require 'test/unit'" after "rescue
> LoadError".

It's required in railties' test_help.

Otherwise, requiring 'active_support/test_case' will tests even if you
didn't mean to.

jeremy

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: support for postgres-pr

2008-11-17T13:38:38Z

On Sun, Nov 16, 2008 at 5:19 AM, Stefan Lang
<perfectly.normal.hacker@...> wrote:

>
> 2008/11/15 Jeremy Kemper <jeremy@...>:
>>
>> On Sat, Nov 15, 2008 at 8:44 AM, Stefan Lang
>> <perfectly.normal.hacker@...> wrote:
>>>
>>> 2008/11/15 Andrew Kaspick <akaspick@...>:
>>>>
>>>> The pg gem is what you should be using now.
>>>
>>> postgres-pr was easier to deploy - put it in vendor
>>> and be done. Building a C extension on/for the server
>>> can be a hassle.
>>>
>>> And neither pg nor ruby-postgres build with Ruby 1.9.
>>>
>>> What was the reason for dropping postgres-pr support,
>>> and what needs to be done to make it work again?
>>
>> It wasn't intentionally dropped. It doesn't implement the
>> #transaction_status method.
>>
>> Upgrade to the latest postgres-pr, which has this method, and you'll
>> be back up and running.
>
> Weird. gem install gives me version 0.4.0. Looking on RubyForge
> there's a 0.5.0 version. I manually downloaded and installed
> that, but rails still gives me this error (with Ruby 1.9):
>
> in establish_connection': Please install the postgresql adapter: `gem
> install activerecord-postgresql-adapter` (no such file to load -- pg)
> (RuntimeError)
>
> And trying to load postgres-pr manually:
>
> irb(main):001:0> require "postgres"
> LoadError: no such file to load -- readbytes
> from /usr/local/lib/ruby191/gems/1.9.1/gems/postgres-pr-0.5.0/lib/postgres-pr/message.rb:8:in
> `require'
> ...
>
> readbytes.rb is in Ruby 1.8 standard library but not in Ruby 1.9
> anymore. It doesn't do much anyway. I'll patch postgres-pr.
>
>> Also, the C drivers have worked with 1.9 since January 2008.
>
> ruby-postgres-0.7.1.2006.04.06 fails with this error:
>
> In file included from postgres.c:16:
> /usr/local/include/ruby191-1.9.1/ruby/backward/rubyio.h:2:2: warning:
> #warning use "ruby/io.h" instead of "rubyio.h"
> In file included from postgres.c:17:
> /usr/local/include/ruby191-1.9.1/ruby/backward/st.h:2:2: warning:
> #warning use "ruby/st.h" instead of bare "st.h"
> postgres.c:18:20: error: intern.h: No such file or directory
>
> pg-0.7.9.2008.10.13 fails with this error:
>
> In file included from pg.h:6,
> from pg.c:15:
> /usr/local/include/ruby191-1.9.1/ruby/backward/rubyio.h:2:2: warning:
> #warning use "ruby/io.h" instead of "rubyio.h"
> pg.c: In Funktion »parse_connect_args«:
> pg.c:233: Warnung: Variable »error« wird nicht verwendet
> pg.c:231: Warnung: Variable »conn« wird nicht verwendet
> pg.c: In Funktion »pgconn_exec«:
> pg.c:960: Fehler: »struct RArray« hat kein Element namens »len«

Ah, this is due to a recent change in Ruby 1.9. Here's a patch that fixes it:
http://rubyforge.org/tracker/index.php?func=detail&aid=22856&group_id=3214&atid=12396

Best,
jeremy

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Test::Unit::TestCase refactoring

2008-11-17T13:26:53Z

Found it - in activesupport/lib/active_support/test_case.rb, test/unit
needs to be required,
or the tests don't get run. Add "require 'test/unit'" after "rescue
LoadError".

--Matt

On Nov 17, 2008, at 3:46 PM, Kevin Hall wrote:

>
> Just so you know, I have edge frozen from around five days ago and I
> went through and replaced all Test::Unit::TestCase instances in my
> test/ directory and all my tests still pass.
>
> On Nov 17, 2008, at 11:31 AM, Matt Jones wrote:
>
>>
>> Are you sure? When I changed that (in test/test_helper.rb), none of
>> the test methods ran, and I
>> don't see any activity in the log.
>>
>> On Nov 17, 2008, at 1:41 PM, Jeremy Kemper wrote:
>>
>>>
>>> On Mon, Nov 17, 2008 at 10:31 AM, Matt Jones <al2o3cr@...>
>>> wrote:
>>>>
>>>> I noted that in b0ee1bdf2650d7a8380d4e9be58bba8d9c5bd40e and
>>>> related
>>>> commits that
>>>> the extensions to TestCase are getting pulled out; what's the
>>>> correct
>>>> thing to put into test/test_helper.rb?
>>>
>>> Use ActiveSupport::TestCase instead of Test::Unit::TestCase :)
>>>
>>> jeremy
>>>
>>>>
>>
>>
>>>
>
>
> >

Re: Test::Unit::TestCase refactoring

2008-11-17T12:46:47Z

Just so you know, I have edge frozen from around five days ago and I
went through and replaced all Test::Unit::TestCase instances in my
test/ directory and all my tests still pass.

On Nov 17, 2008, at 11:31 AM, Matt Jones wrote:

>
> Are you sure? When I changed that (in test/test_helper.rb), none of
> the test methods ran, and I
> don't see any activity in the log.
>
> On Nov 17, 2008, at 1:41 PM, Jeremy Kemper wrote:
>
>>
>> On Mon, Nov 17, 2008 at 10:31 AM, Matt Jones <al2o3cr@...>
>> wrote:
>>>
>>> I noted that in b0ee1bdf2650d7a8380d4e9be58bba8d9c5bd40e and related
>>> commits that
>>> the extensions to TestCase are getting pulled out; what's the
>>> correct
>>> thing to put into test/test_helper.rb?
>>
>> Use ActiveSupport::TestCase instead of Test::Unit::TestCase :)
>>
>> jeremy
>>
>>>
>
>
> >

Re: Test::Unit::TestCase refactoring

2008-11-17T11:31:47Z

Are you sure? When I changed that (in test/test_helper.rb), none of
the test methods ran, and I
don't see any activity in the log.

On Nov 17, 2008, at 1:41 PM, Jeremy Kemper wrote:

>
> On Mon, Nov 17, 2008 at 10:31 AM, Matt Jones <al2o3cr@...>
> wrote:
>>
>> I noted that in b0ee1bdf2650d7a8380d4e9be58bba8d9c5bd40e and related
>> commits that
>> the extensions to TestCase are getting pulled out; what's the correct
>> thing to put into test/test_helper.rb?
>
> Use ActiveSupport::TestCase instead of Test::Unit::TestCase :)
>
> jeremy
>
> >

Re: Test::Unit::TestCase refactoring

2008-11-17T10:41:11Z

On Mon, Nov 17, 2008 at 10:31 AM, Matt Jones <al2o3cr@...> wrote:
>
> I noted that in b0ee1bdf2650d7a8380d4e9be58bba8d9c5bd40e and related
> commits that
> the extensions to TestCase are getting pulled out; what's the correct
> thing to put into test/test_helper.rb?

Use ActiveSupport::TestCase instead of Test::Unit::TestCase :)

jeremy

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Test::Unit::TestCase refactoring

2008-11-17T10:31:38Z

I noted that in b0ee1bdf2650d7a8380d4e9be58bba8d9c5bd40e and related
commits that
the extensions to TestCase are getting pulled out; what's the correct
thing to put into test/test_helper.rb?

--Matt Jones

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Ruby 1.9 compatibility on Rails 2.2 currently broken

2008-11-17T05:31:35Z

On Sun, Nov 16, 2008 at 11:53 AM, Carlos Paramio
<carlosparamio@...> wrote:
>
> Now that the final Rails 2.2.1 release is comming, and that one of the
> features is to be ready for Ruby 1.9 compatibility, it might be a good
> idea to merge this tiny patch for boot.rb that will fix a bug on the
> Rails bootstrap using Ruby 1.9:
>
> http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1176

Jeremy's been keeping an eye on our 1.9 compatibility, and he's the
best one to pipe up with a reply. However my understanding is that
several 1.9 changes have broken 2.2 support (test related assertions
f.ex) and we'll likely be holding off till 2.3 before we ship a '1.9
friendly' release.
--
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Excess deprecations (number_with_precision deprecation in 2.2)

2008-11-17T02:58:40Z

Will,

I should probably explain the change because I was the one who
introduced it in the first place.

The reason for the changes to the NumberHelper was that I wasn't happy
with them being inconsistent - some helpers would use hashes to supply
optional parameters and some would use a "standard" argument list. In
Rails - and nowadays also in many Ruby libraries, as far as I've seen
- it has become some kind of a best practice to only use fixed
parameters for required parameters (e.g. the number in the number
helpers) and supply optional parameters as an options hash - which is
exactly what all NumberHelper methods do since I made the change. If I
remember correctly, I introduced similar changes in other places in
ActionView.

In short: This is deprecation for the sake of deprecation but for the
sake of consolidating the ActionView helpers API which - in my opinion
- makes plenty of sense and is a valid reason for deprecation, even if
it occasionally results in some verbosity like you indicated.

I hope this explains the change sufficiently. Otherwise maybe Josh
would like to chime in since he was the one who committed it.

- Clemens

On Nov 16, 10:40 pm, "Will Bryant" <will.bry...@...> wrote:

> Hi guys,
> 2.2 has the new number_with_precision implementation which after the number
> takes :precision, :separator, and :delimiter hash arguments instead of just
> a precision integer, and the old argument format has been deprecated.
>
> Are we really on the right track deprecating things like this? It feels
> like deprecation for the sake of deprecation to me.
>
> I mean, if you've got a method called number_with_precision, it seems pretty
> clear that the normal two arguments would be the number, and the precision.
> Being able to supply the separator and delimiter is great, but since most
> people will just set those on the locale (if at all), surely we're just
> making people do a bunch of extra typing & change a _lot_ of calls in their
> existing code for no good reason, merely to get rid of the deprecation?
>
> The code already supports both argument syntaxes, so I think we should just
> remove the deprecation warning. IMHO, we don't have to deprecate every time
> something slightly more flexible comes along if there's nothing wrong with
> the old way - provided there's no confusion between the old & new syntax or
> semantics.
>
> Will

Excess deprecations (number_with_precision deprecation in 2.2)

2008-11-16T13:40:38Z

Hi guys,

2.2 has the new number_with_precision implementation which after the number takes :precision, :separator, and :delimiter hash arguments instead of just a precision integer, and the old argument format has been deprecated.

Are we really on the right track deprecating things like this? It feels like deprecation for the sake of deprecation to me.

I mean, if you've got a method called number_with_precision, it seems pretty clear that the normal two arguments would be the number, and the precision. Being able to supply the separator and delimiter is great, but since most people will just set those on the locale (if at all), surely we're just making people do a bunch of extra typing & change a _lot_ of calls in their existing code for no good reason, merely to get rid of the deprecation?

The code already supports both argument syntaxes, so I think we should just remove the deprecation warning. IMHO, we don't have to deprecate every time something slightly more flexible comes along if there's nothing wrong with the old way - provided there's no confusion between the old & new syntax or semantics.

Will

Re: support for postgres-pr

2008-11-16T05:19:11Z

2008/11/15 Jeremy Kemper <jeremy@...>:

>
> On Sat, Nov 15, 2008 at 8:44 AM, Stefan Lang
> <perfectly.normal.hacker@...> wrote:
>>
>> 2008/11/15 Andrew Kaspick <akaspick@...>:
>>>
>>> The pg gem is what you should be using now.
>>
>> postgres-pr was easier to deploy - put it in vendor
>> and be done. Building a C extension on/for the server
>> can be a hassle.
>>
>> And neither pg nor ruby-postgres build with Ruby 1.9.
>>
>> What was the reason for dropping postgres-pr support,
>> and what needs to be done to make it work again?
>
> It wasn't intentionally dropped. It doesn't implement the
> #transaction_status method.
>
> Upgrade to the latest postgres-pr, which has this method, and you'll
> be back up and running.

Weird. gem install gives me version 0.4.0. Looking on RubyForge
there's a 0.5.0 version. I manually downloaded and installed
that, but rails still gives me this error (with Ruby 1.9):

in establish_connection': Please install the postgresql adapter: `gem
install activerecord-postgresql-adapter` (no such file to load -- pg)
(RuntimeError)

And trying to load postgres-pr manually:

irb(main):001:0> require "postgres"
LoadError: no such file to load -- readbytes
from /usr/local/lib/ruby191/gems/1.9.1/gems/postgres-pr-0.5.0/lib/postgres-pr/message.rb:8:in
`require'
...

readbytes.rb is in Ruby 1.8 standard library but not in Ruby 1.9
anymore. It doesn't do much anyway. I'll patch postgres-pr.

> Also, the C drivers have worked with 1.9 since January 2008.

ruby-postgres-0.7.1.2006.04.06 fails with this error:

In file included from postgres.c:16:
/usr/local/include/ruby191-1.9.1/ruby/backward/rubyio.h:2:2: warning:
#warning use "ruby/io.h" instead of "rubyio.h"
In file included from postgres.c:17:
/usr/local/include/ruby191-1.9.1/ruby/backward/st.h:2:2: warning:
#warning use "ruby/st.h" instead of bare "st.h"
postgres.c:18:20: error: intern.h: No such file or directory

pg-0.7.9.2008.10.13 fails with this error:

In file included from pg.h:6,
from pg.c:15:
/usr/local/include/ruby191-1.9.1/ruby/backward/rubyio.h:2:2: warning:
#warning use "ruby/io.h" instead of "rubyio.h"
pg.c: In Funktion »parse_connect_args«:
pg.c:233: Warnung: Variable »error« wird nicht verwendet
pg.c:231: Warnung: Variable »conn« wird nicht verwendet
pg.c: In Funktion »pgconn_exec«:
pg.c:960: Fehler: »struct RArray« hat kein Element namens »len«

All three gems work with Ruby 1.8 on the same machine.

Thanks,
Stefan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Confusing one-to-one Association example at docs?

2008-11-16T02:57:12Z

I think that the one-to-one example, at the
ActiveRecord::Associations::ClassMethods module, in the documentation
about "Cardinality and associations", is confusing. The example refers
to an office that belongs to one employer, and an employer that has
one office, leaving the foreign key on the Office model pointing to
the employee_id. Maybe the reversed example is much more natural and
nearer to the reality: An employee belongs to an office (where he
works), and the office has one employee, creating the office_id
foreign key at the Employee model. This example also leaves the
posibility for the database structure to grow to a multiple-employee
office design easily, just by changing the has_one macro by has_many,
without touching the database.

Ticket + patch at:

http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1328

What do you think?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Ruby 1.9 compatibility on Rails 2.2 currently broken

2008-11-16T02:53:14Z

Now that the final Rails 2.2.1 release is comming, and that one of the
features is to be ready for Ruby 1.9 compatibility, it might be a good
idea to merge this tiny patch for boot.rb that will fix a bug on the
Rails bootstrap using Ruby 1.9:

http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1176

Carlos Paramio

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: support for postgres-pr

2008-11-15T12:42:12Z

On Sat, Nov 15, 2008 at 8:44 AM, Stefan Lang
<perfectly.normal.hacker@...> wrote:

>
> 2008/11/15 Andrew Kaspick <akaspick@...>:
>>
>> The pg gem is what you should be using now.
>
> postgres-pr was easier to deploy - put it in vendor
> and be done. Building a C extension on/for the server
> can be a hassle.
>
> And neither pg nor ruby-postgres build with Ruby 1.9.
>
> What was the reason for dropping postgres-pr support,
> and what needs to be done to make it work again?

It wasn't intentionally dropped. It doesn't implement the
#transaction_status method.

Upgrade to the latest postgres-pr, which has this method, and you'll
be back up and running.

Also, the C drivers have worked with 1.9 since January 2008.

Best,
jeremy

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: support for postgres-pr

2008-11-15T08:47:44Z

On Sat, Nov 15, 2008 at 5:44 PM, Stefan Lang
<perfectly.normal.hacker@...> wrote:

I don't know if the support was dropped deliberately, merely that the
preferred deployment option is pg. To get it working again you'll
need to simply run the tests and fix the tests. I realise that's a
little trite, but there weren't many huge changes made.

Perhaps use git bisect to find it?

> Thanks,
> Stefan
>
> >
>

--
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: support for postgres-pr

2008-11-15T08:44:59Z

2008/11/15 Andrew Kaspick <akaspick@...>:
>
> The pg gem is what you should be using now.

postgres-pr was easier to deploy - put it in vendor
and be done. Building a C extension on/for the server
can be a hassle.

And neither pg nor ruby-postgres build with Ruby 1.9.

What was the reason for dropping postgres-pr support,
and what needs to be done to make it work again?

Thanks,
Stefan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: support for postgres-pr

2008-11-15T08:35:10Z

The pg gem is what you should be using now.

On Sat, Nov 15, 2008 at 5:47 AM, Stefan Lang
<perfectly.normal.hacker@...> wrote:
>
> The latest version from github doesn't work
> with the postgres-pr driver. Has support
> for postgres-pr been dropped?
>
> Stefan
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

support for postgres-pr

2008-11-15T03:47:52Z

The latest version from github doesn't work
with the postgres-pr driver. Has support
for postgres-pr been dropped?

Stefan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: auto_link failing on URLs with square brackets in query params

2008-11-14T21:53:41Z

On Nov 13, 3:55 pm, "Mislav Marohnić" <mislav.maroh...@...>
wrote:
> Previously hideous regexp becomes this: %r{( https?:// | www\. ) [^\s<]+}x
>
> Added feature: intelligent closing bracket handling. You are now able to
> write this:

Just as an FYI - this is awesome. People have always bitched at me
about the auto-linking stuff in my apps, and this looks like it solves
all their problems.

Thank you!
- Trevor
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---