[...]
Dang, yes, this is correct.
Sorry for the confusion.
···
On Jun 13, 2006, at 7:37 PM, Jim Weirich wrote:
Gregory Brown wrote:
On 6/13/06, Eric Hodel <drbrain@segment7.net> wrote:
I don't see fastercsv being required when rubygems is involved.
I think the difference here is that Eric is probably running with a very
recent development version of RubyGems and Gregory is running the last
stable release.
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
Thank you jim.
This patch seems to resolve the problem, also:
--- rubygems.rb 2006-06-13 22:48:48.000000000 -0400
+++ rubygems-fix.rb 2006-06-13 22:49:22.000000000 -0400
@@ -164,7 +164,7 @@
# Load dependent gems first
spec.dependencies.each do |dep_gem|
- activate(dep_gem, autorequire)
+ activate(dep_gem, spec.autorequire)
end
# add bin dir to require_path
···
On 6/13/06, Jim Weirich <jim@weirichhouse.org> wrote:
Gregory Brown wrote:
> On 6/13/06, Eric Hodel <drbrain@segment7.net> wrote:
>
>> I don't see fastercsv being required when rubygems is involved.
I think the difference here is that Eric is probably running with a very
recent development version of RubyGems and Gregory is running the last
stable release.
Version 0.9.0 should be out within the week, barring unexpected issues.
If you want the try the release candidate for 0.9.0 (which is version
0.8.99), do:
gem update --system --source http://onestepback.org/betagems
Yup, that did it! 
[sandal@harmonix pkg]$ irb -rubygems --simple-prompt
require "ruport"
=> true
$LOADED_FEATURES.length
=> 83
$LOADED_FEATURES.include? "faster_csv.rb"
=> false
[[1,2]].to_ds(%w[a b]).as(:csv)
=> "a,b\n1,2\n"
$LOADED_FEATURES.include? "faster_csv.rb"
=> true
quit
[sandal@harmonix pkg]$ gem -v
0.8.99
If you do try it, please report any issues to me or to the Rubygems
developer mailing list (on RubyForge).
I'm subbed to the list, I would have asked there first, but I didn't
suspect a bug at first, just a problem with my Rakefile maybe.
Thanks Eric and Jim!
···
On 6/13/06, Jim Weirich <jim@weirichhouse.org> wrote:
Just noticed this:
Gregory Brown wrote:
This patch seems to resolve the problem, also:
--- rubygems.rb 2006-06-13 22:48:48.000000000 -0400
+++ rubygems-fix.rb 2006-06-13 22:49:22.000000000 -0400
@@ -164,7 +164,7 @@
# Load dependent gems first
spec.dependencies.each do |dep_gem|
- activate(dep_gem, autorequire)
+ activate(dep_gem, spec.autorequire)
end
Oh, don't do this. The autorequire field in the gem spec is not a
boolean flag, but the name of the file to automatically require when
activating a gem. Setting autorequire in the gem spec only controls
what file you want to autorequire, not whether dependent gems should
autorequire or not.
And we are deprecating autorequire anyways.
-- Jim Weirich
···
--
Posted via http://www.ruby-forum.com/\.
Thank you for pointing this out. I've released FasterCSV 0.2.1 which removes the autorequire.
James Edward Gray II
···
On Jun 13, 2006, at 9:44 PM, Jim Weirich wrote:
A quick followup...
Jim Weirich wrote:
-- Using 0.8.11 -----------
$ gem -v
0.8.11
$ irb
irb(main):001:0> require 'a'
Loading B
Loading A
=> true
irb(main):002:0>
Note that you only get this behavior when the b package specifies an
autorequire file (which b does in this case, and which the fastercsv
package does as well).
Gregory Brown wrote:
> # Load dependent gems first
> spec.dependencies.each do |dep_gem|
> - activate(dep_gem, autorequire)
> + activate(dep_gem, spec.autorequire)
> end
Oh, don't do this. The autorequire field in the gem spec is not a
boolean flag, but the name of the file to automatically require when
activating a gem. Setting autorequire in the gem spec only controls
what file you want to autorequire, not whether dependent gems should
autorequire or not.
Ah, I suspected I was breaking something 
And we are deprecating autorequire anyways.
Good!
···
On 6/14/06, Jim Weirich <jim@weirichhouse.org> wrote: