Hi
I just updated rails. This is what I got:
jfn@indigo 101 /disk2/jfn > gem update
Upgrading installed gems...
Updating Gem source index for: http://gems.rubyforge.org
Attempting remote upgrade of actionpack
Attempting remote installation of 'actionpack'
Successfully installed actionpack, version 0.9.0
Installing RDoc documentation for actionpack-0.9.0...
lib/action_controller/scaffolding.rb:87:37: Skipping require of dynamic
string: "#{model_id.id2name}"
Attempting remote upgrade of activerecord
Attempting remote installation of 'activerecord'
Successfully installed activerecord, version 1.0.0
Installing RDoc documentation for activerecord-1.0.0...
Attempting remote upgrade of rails
Attempting remote installation of 'rails'
Install required dependency actionmailer? [Yn] y
Successfully installed rails, version 0.8.0
Installing RDoc documentation for rails-0.8.0...
WARNING: Generating RDoc on .gem that may not have RDoc.
lib/dispatcher.rb:34:67: Skipping require of dynamic string:
"#{Inflector.underscore(controller_name)}_controller"
Installing RDoc documentation for actionmailer-0.3.0...
Are the 'Skipping require of dynamic string' messages anything to worry
about?
···
--
Jim Freeze
Nope. This is Rdoc saying that it doesn't know what file it would have
to include, so ... it's not going to bother 
You'll get it with TeX::Hyphen, too.
-austin
···
On Tue, 26 Oct 2004 06:22:34 +0900, jim@freeze.org <jim@freeze.org> wrote:
lib/action_controller/scaffolding.rb:87:37: Skipping require of dynamic
string: "#{model_id.id2name}"
Are the 'Skipping require of dynamic string' messages anything to worry
about?
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
: as of this email, I have [ 5 ] Gmail invitations
Nope. Basically this happens where you have, say
require "domain_classes/#{ domain_class_name }"
I've had this warning in Lafcadio from the start, because Lafcadio does similar stuff in terms of inferring where files should be to reduce user configuration.
F.
···
On Oct 25, 2004, at 5:22 PM, jim@freeze.org wrote:
Are the 'Skipping require of dynamic string' messages anything to worry
about?
Francis Hwang ha scritto:
Nope. Basically this happens where you have, say
require "domain_classes/#{ domain_class_name }"
I've had this warning in Lafcadio from the start, because Lafcadio does similar stuff in terms of inferring where files should be to reduce user configuration.
why not using autoload?
Should I remove the warning?
Cheers
Dave
···
On Oct 25, 2004, at 18:47, Francis Hwang wrote:
On Oct 25, 2004, at 5:22 PM, jim@freeze.org wrote:
Are the 'Skipping require of dynamic string' messages anything to worry
about?
Nope. Basically this happens where you have, say
require "domain_classes/#{ domain_class_name }"
Dave Thomas wrote:
Are the 'Skipping require of dynamic string' messages anything to worry
about?
Nope. Basically this happens where you have, say
require "domain_classes/#{ domain_class_name }"
Should I remove the warning?
I think such warnings can be useful for debugging problems, but in general they cause confusion (as we've seen). Can you add a "verbose" option to rdoc (or does it already have one)? Then, if verbose mode is on, display those kinds of warnings, otherwise ignore them.
Alternatively, if "quiet" was specified, you could suppress the warnings.
- Jamis
···
On Oct 25, 2004, at 18:47, Francis Hwang wrote:
On Oct 25, 2004, at 5:22 PM, jim@freeze.org wrote:
--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis
Unless I misunderstand autoload (I've never used it), it won't help what I need. Basically, the Lafcadio ObjectStore uses method_missing more than I've ever seen it used, to make the ObjectStore instance a proxy for a bunch of different ways to query a database. The most common usage is:
os = ObjectStore.get_object_store
client = os.get_client( 1 )
Now, the ObjectStore can only load a Client if it's already loaded the Client class. I wanted to support a bunch of different ways of doing this, and one of them is having a domain directory with each class living in a file of the same name.
./domain_classes/Client.rb
./domain_classes/Invoice.rb
./domain_classes/Project.rb
etc.
(this is only one way to organize the domain classes in Lafcadio; these days I find I don't use this much, myself.)
So one of the things Lafcadio tries to do is load the class by doing a dynamic require:
require "domain_classes/#{ domain_class_name }"
So you don't have to explicitly require those files yourself.
···
On Oct 26, 2004, at 3:39 AM, gabriele renzi wrote:
Francis Hwang ha scritto:
Nope. Basically this happens where you have, say
require "domain_classes/#{ domain_class_name }"
I've had this warning in Lafcadio from the start, because Lafcadio does similar stuff in terms of inferring where files should be to reduce user configuration.
why not using autoload?
Jamis Buck ha scritto:
I think such warnings can be useful for debugging problems, but in general they cause confusion (as we've seen). Can you add a "verbose" option to rdoc (or does it already have one)? Then, if verbose mode is on, display those kinds of warnings, otherwise ignore them.
Alternatively, if "quiet" was specified, you could suppress the warnings.
+1, seems very reasonable
Francis Hwang ha scritto:
Unless I misunderstand autoload (I've never used it), it won't help what I need. Basically, the Lafcadio ObjectStore uses method_missing more than I've ever seen it used, to make the ObjectStore instance a proxy for a bunch of different ways to query a database. The most common usage is:
os = ObjectStore.get_object_store
client = os.get_client( 1 )
Now, the ObjectStore can only load a Client if it's already loaded the Client class.
and this is where autoload would come, it loads the Client class whenever it is used for the first time.
I wanted to support a bunch of different ways of doing this, and one of them is having a domain directory with each class living in a file of the same name.
/domain_classes/Client.rb
/domain_classes/Invoice.rb
/domain_classes/Project.rb
etc.
(this is only one way to organize the domain classes in Lafcadio; these days I find I don't use this much, myself.)
So one of the things Lafcadio tries to do is load the class by doing a dynamic require:
require "domain_classes/#{ domain_class_name }"
So you don't have to explicitly require those files yourself.
ah, now I see what you mean, thanks for taking time to explain