From ryand-ruby at zenspider.com  Wed Sep  5 04:33:27 2007
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Wed, 5 Sep 2007 01:33:27 -0700
Subject: [Rubygems-developers] Gems for several architectures
In-Reply-To: <20070831195622.GA3914@eldorado.remote.org>
References: <20070831195622.GA3914@eldorado.remote.org>
Message-ID: <36B1E2B2-D09A-45D6-B999-15A566F09989@zenspider.com>


On Aug 31, 2007, at 12:56 , Jochen Topf wrote:

> Any ideas on what the right procedure is here?

Wait for Eric to finish his changes... better, help him test via:

svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4


From ryand-ruby at zenspider.com  Wed Sep  5 04:38:15 2007
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Wed, 5 Sep 2007 01:38:15 -0700
Subject: [Rubygems-developers] bug in latest_specs
In-Reply-To: <43679DC1-DB01-4802-A136-B1AC2BAF0519@zenspider.com>
References: <43679DC1-DB01-4802-A136-B1AC2BAF0519@zenspider.com>
Message-ID: <58B85DE4-C0AC-4A06-97CD-19F9CC6DDB22@zenspider.com>

This is the latest version I've been monkeypatching with:

class Gem::SourceIndex
   alias :dead_latest_specs :latest_specs
   def latest_specs
     result, latest = Hash.new { |h,k| h[k] = [] }, {}

     each do |full_name, spec|
       name = spec.name
       curr = spec.version
       prev = latest[name] || curr

       next unless curr >= prev

       if curr > prev then
         result[name].clear
         latest[name] = curr
       end

       result[name] << spec
     end

     result
   end
end

Seems to work well, tho it returns a different structure than before.  
It seems to work pretty well. I'm pretty sure that latest_specs is  
only used sparingly within (if at all) and other than that, I think  
I'm the only external client of this method (at least, of the actual  
values of the hash).

From thewoolleyman at gmail.com  Wed Sep  5 14:57:33 2007
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 5 Sep 2007 11:57:33 -0700
Subject: [Rubygems-developers] Gems for several architectures
In-Reply-To: <36B1E2B2-D09A-45D6-B999-15A566F09989@zenspider.com>
References: <20070831195622.GA3914@eldorado.remote.org>
	<36B1E2B2-D09A-45D6-B999-15A566F09989@zenspider.com>
Message-ID: <e3af97510709051157v2a89bb14r6c73a8c358a4418a@mail.gmail.com>

Has this tag been updated with the patches I saw go by recently?
What's your standards on this, are you "moving" the tag or cutting new
ones as you get closer to release quality?

I was going to try it out, but I didn't see a new tag, and didn't want
to encounter already-patched bugs

-- Chad

On 9/5/07, Ryan Davis <ryand-ruby at zenspider.com> wrote:
>
> On Aug 31, 2007, at 12:56 , Jochen Topf wrote:
>
> > Any ideas on what the right procedure is here?
>
> Wait for Eric to finish his changes... better, help him test via:
>
> svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4
>
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>

From ryand-ruby at zenspider.com  Thu Sep  6 03:13:08 2007
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Thu, 6 Sep 2007 00:13:08 -0700
Subject: [Rubygems-developers] Gems for several architectures
In-Reply-To: <e3af97510709051157v2a89bb14r6c73a8c358a4418a@mail.gmail.com>
References: <20070831195622.GA3914@eldorado.remote.org>
	<36B1E2B2-D09A-45D6-B999-15A566F09989@zenspider.com>
	<e3af97510709051157v2a89bb14r6c73a8c358a4418a@mail.gmail.com>
Message-ID: <0DA73EF3-0142-4833-B7AF-E6E805D8DB7E@zenspider.com>


On Sep 5, 2007, at 11:57 , Chad Woolley wrote:

> Has this tag been updated with the patches I saw go by recently?
> What's your standards on this, are you "moving" the tag or cutting new
> ones as you get closer to release quality?
>
> I was going to try it out, but I didn't see a new tag, and didn't want
> to encounter already-patched bugs

That's Eric's call... and he's on vacation until the weekend. I doubt  
you'll hit the bug in question as it involves only two or three gems.


From transfire at gmail.com  Fri Sep  7 18:57:19 2007
From: transfire at gmail.com (TRANS)
Date: Fri, 7 Sep 2007 15:57:19 -0700
Subject: [Rubygems-developers] Error with local install
Message-ID: <4b6f054f0709071557m38832313qfe98ebbdb2c56556@mail.gmail.com>

Hi--

I'm getting an error trying to do a local install:

  $ sudo gem install facets-2.0.0.gem
  ERROR:  Error installing gem facets-2.0.0.gem[.gem]: undefined
method `required_ruby_version' for nil:NilClass

Is this a known issue? Is there a quick fix?

Thanks,
T.

From chad at chadfowler.com  Fri Sep  7 20:53:27 2007
From: chad at chadfowler.com (Chad Fowler)
Date: Fri, 7 Sep 2007 18:53:27 -0600
Subject: [Rubygems-developers] Error with local install
In-Reply-To: <4b6f054f0709071557m38832313qfe98ebbdb2c56556@mail.gmail.com>
References: <4b6f054f0709071557m38832313qfe98ebbdb2c56556@mail.gmail.com>
Message-ID: <c67184de0709071753g1d2de5b8t7d26a9690b2b928c@mail.gmail.com>

On 9/7/07, TRANS <transfire at gmail.com> wrote:
> Hi--
>
> I'm getting an error trying to do a local install:
>
>   $ sudo gem install facets-2.0.0.gem
>   ERROR:  Error installing gem facets-2.0.0.gem[.gem]: undefined
> method `required_ruby_version' for nil:NilClass
>
> Is this a known issue? Is there a quick fix?
>

Can you add --backtrace to the command see where it's happening?

Chad

From transfire at gmail.com  Fri Sep  7 22:13:56 2007
From: transfire at gmail.com (TRANS)
Date: Fri, 7 Sep 2007 19:13:56 -0700
Subject: [Rubygems-developers] Error with local install
In-Reply-To: <c67184de0709071753g1d2de5b8t7d26a9690b2b928c@mail.gmail.com>
References: <4b6f054f0709071557m38832313qfe98ebbdb2c56556@mail.gmail.com>
	<c67184de0709071753g1d2de5b8t7d26a9690b2b928c@mail.gmail.com>
Message-ID: <4b6f054f0709071913w5d137d0an94d73662627ae94e@mail.gmail.com>

On 9/7/07, Chad Fowler <chad at chadfowler.com> wrote:
> On 9/7/07, TRANS <transfire at gmail.com> wrote:
> > Hi--
> >
> > I'm getting an error trying to do a local install:
> >
> >   $ sudo gem install facets-2.0.0.gem
> >   ERROR:  Error installing gem facets-2.0.0.gem[.gem]: undefined
> > method `required_ruby_version' for nil:NilClass
> >
> > Is this a known issue? Is there a quick fix?
> >
>
> Can you add --backtrace to the command see where it's happening?

Exactly the same.

  $ sudo gem install --backtrace facets-2.0.0.gem
  ERROR:  Error installing gem facets-2.0.0.gem[.gem]: undefined
method `required_ruby_version' for nil:NilClass


T.

From jim.weirich at gmail.com  Fri Sep  7 23:51:40 2007
From: jim.weirich at gmail.com (Jim Weirich)
Date: Fri, 7 Sep 2007 23:51:40 -0400
Subject: [Rubygems-developers] Error with local install
In-Reply-To: <4b6f054f0709071913w5d137d0an94d73662627ae94e@mail.gmail.com>
References: <4b6f054f0709071557m38832313qfe98ebbdb2c56556@mail.gmail.com>
	<c67184de0709071753g1d2de5b8t7d26a9690b2b928c@mail.gmail.com>
	<4b6f054f0709071913w5d137d0an94d73662627ae94e@mail.gmail.com>
Message-ID: <FB82A91D-99BF-4948-A5AF-EFFE5F2AC40C@gmail.com>

On Sep 7, 2007, at 10:13 PM, TRANS wrote:
> Exactly the same.
>
>   $ sudo gem install --backtrace facets-2.0.0.gem
>   ERROR:  Error installing gem facets-2.0.0.gem[.gem]: undefined
> method `required_ruby_version' for nil:NilClass

My guess is that you installed a gem with the beta version of  
RubyGems, then switched back to a previous version.

To fix:  (1) Uninstall the offending gem, or (2) grep the gem/ 
specification directory for require_ruby_version and delete that line  
from the spec.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com





From transfire at gmail.com  Sat Sep  8 00:16:00 2007
From: transfire at gmail.com (TRANS)
Date: Fri, 7 Sep 2007 21:16:00 -0700
Subject: [Rubygems-developers] Error with local install
In-Reply-To: <FB82A91D-99BF-4948-A5AF-EFFE5F2AC40C@gmail.com>
References: <4b6f054f0709071557m38832313qfe98ebbdb2c56556@mail.gmail.com>
	<c67184de0709071753g1d2de5b8t7d26a9690b2b928c@mail.gmail.com>
	<4b6f054f0709071913w5d137d0an94d73662627ae94e@mail.gmail.com>
	<FB82A91D-99BF-4948-A5AF-EFFE5F2AC40C@gmail.com>
Message-ID: <4b6f054f0709072116jede106eic382f5cb185f3240@mail.gmail.com>

On 9/7/07, Jim Weirich <jim.weirich at gmail.com> wrote:
> On Sep 7, 2007, at 10:13 PM, TRANS wrote:
> > Exactly the same.
> >
> >   $ sudo gem install --backtrace facets-2.0.0.gem
> >   ERROR:  Error installing gem facets-2.0.0.gem[.gem]: undefined
> > method `required_ruby_version' for nil:NilClass
>
> My guess is that you installed a gem with the beta version of
> RubyGems, then switched back to a previous version.

I generated the gem, then tried to install it as a test and got this
error. Then I upgraded to the latest version of RubyGems 0.9.4 and did
it all again. Both times I got the exact same error. Here's the
metadata as it exists in the gem:

--- !ruby/object:Box::GemSpecification
rubygems_version: 0.9.4
specification_version: 1
name: facets
version: !ruby/object:Gem::Version
  version: 2.0.0
date: 2007-09-07 00:00:00 -07:00
summary: Premium Core Extensions and Standard Additions
require_paths:
- lib
email: facets-universal at rubyforge.org
homepage: http://facets.rubyforge.org
rubyforge_project:
description: Facets is a large collection of core extension methods
and standard additions for the Ruby programming language. The core
extensions are unique by virtue of their atomicity. Methods are stored
in small, tightly related collections, allowing for highly granular
control of requirements. The modules include a variety of useful
classes, mixins and microframeworks, from the Functor to a complete
Annotations system.
autorequire:
default_executable:
bindir: bin
has_rdoc: false
required_ruby_version: !ruby/object:Gem::Version::Requirement
  requirements:
  - - ">"
    - !ruby/object:Gem::Version
      version: 0.0.0
  version:
platform: ruby
signing_key:
cert_chain:
post_install_message:
authors:
- Thomas Sawyer <transfire at gmail.com>
files:
- LICENSE
- README
- demo
- demo/bench
- demo/bench/bench_factorial.rb
...

> To fix:  (1) Uninstall the offending gem, or (2) grep the gem/
> specification directory for require_ruby_version and delete that line
> from the spec.

I could delete require_ruby_version, if that would fix the problem,
but since RubyGems is generating this spec, it really doesn't solve my
problem beyond this one test install.

Thanks,
T.

From drbrain at segment7.net  Sat Sep  8 10:46:10 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 8 Sep 2007 07:46:10 -0700
Subject: [Rubygems-developers] Error with local install
In-Reply-To: <4b6f054f0709072116jede106eic382f5cb185f3240@mail.gmail.com>
References: <4b6f054f0709071557m38832313qfe98ebbdb2c56556@mail.gmail.com>
	<c67184de0709071753g1d2de5b8t7d26a9690b2b928c@mail.gmail.com>
	<4b6f054f0709071913w5d137d0an94d73662627ae94e@mail.gmail.com>
	<FB82A91D-99BF-4948-A5AF-EFFE5F2AC40C@gmail.com>
	<4b6f054f0709072116jede106eic382f5cb185f3240@mail.gmail.com>
Message-ID: <21F016E4-D8C8-4857-B416-DC09FAAF285C@segment7.net>

On Sep 7, 2007, at 21:16, TRANS wrote:
> On 9/7/07, Jim Weirich <jim.weirich at gmail.com> wrote:
>> On Sep 7, 2007, at 10:13 PM, TRANS wrote:
>>> Exactly the same.
>>>
>>>   $ sudo gem install --backtrace facets-2.0.0.gem
>>>   ERROR:  Error installing gem facets-2.0.0.gem[.gem]: undefined
>>> method `required_ruby_version' for nil:NilClass
>>
>> My guess is that you installed a gem with the beta version of
>> RubyGems, then switched back to a previous version.
>
> I generated the gem, then tried to install it as a test and got this
> error. Then I upgraded to the latest version of RubyGems 0.9.4 and did
> it all again. Both times I got the exact same error. Here's the
> metadata as it exists in the gem:
>
> --- !ruby/object:Box::GemSpecification
> [...]
>
>> To fix:  (1) Uninstall the offending gem, or (2) grep the gem/
>> specification directory for require_ruby_version and delete that line
>> from the spec.
>
> I could delete require_ruby_version, if that would fix the problem,
> but since RubyGems is generating this spec, it really doesn't solve my
> problem beyond this one test install.

Box::GemSpecification is not generated by RubyGems.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From transfire at gmail.com  Sat Sep  8 10:57:00 2007
From: transfire at gmail.com (TRANS)
Date: Sat, 8 Sep 2007 07:57:00 -0700
Subject: [Rubygems-developers] Error with local install
In-Reply-To: <21F016E4-D8C8-4857-B416-DC09FAAF285C@segment7.net>
References: <4b6f054f0709071557m38832313qfe98ebbdb2c56556@mail.gmail.com>
	<c67184de0709071753g1d2de5b8t7d26a9690b2b928c@mail.gmail.com>
	<4b6f054f0709071913w5d137d0an94d73662627ae94e@mail.gmail.com>
	<FB82A91D-99BF-4948-A5AF-EFFE5F2AC40C@gmail.com>
	<4b6f054f0709072116jede106eic382f5cb185f3240@mail.gmail.com>
	<21F016E4-D8C8-4857-B416-DC09FAAF285C@segment7.net>
Message-ID: <4b6f054f0709080757j722008e1xefde2a7f710a9099@mail.gmail.com>

On 9/8/07, Eric Hodel <drbrain at segment7.net> wrote:

> Box::GemSpecification is not generated by RubyGems.

Ah ha! Thank you, Eric. Sometimes it just takes another pair of eyes.

T.

From weyus at att.net  Sun Sep  9 11:22:24 2007
From: weyus at att.net (Wes Gamble)
Date: Sun, 09 Sep 2007 10:22:24 -0500
Subject: [Rubygems-developers] Moving gems after upgrade from Ruby 1.8.4 to
	1.8.6 on Windows XP
Message-ID: <46E40FB0.1020700@att.net>

I've successfully installed Ruby 1.8.6 on Windows with the 1-click 
installer.

I have a lot of gems (about 40) that I don't want to re-get.  I copied 
the entire contents of %RUBY_HOME%/lib/ruby/gems/1.8 from my old 
installation to my new installation.

When I run "gem list" I still don't see my existing gems.

I have 2 questions:
1) What do I need to do to have my existing gems added to the local 
repository's index?
2) Is there a user - level list for rubygems where this type of question 
would be more appropriate?

Thanks,
Wes Gamble

From weyus at att.net  Sun Sep  9 11:48:51 2007
From: weyus at att.net (Wes Gamble)
Date: Sun, 09 Sep 2007 10:48:51 -0500
Subject: [Rubygems-developers] Moving gems after upgrade from Ruby 1.8.4
 to	1.8.6 on Windows XP
In-Reply-To: <46E40FB0.1020700@att.net>
References: <46E40FB0.1020700@att.net>
Message-ID: <46E415E3.4080407@att.net>

OK I'm not sure what I did but when I opened up a new command window and 
executed "gem list" all of my gems were there.  I can't imagine why 
things would change for detecting gems across an invocation of the 
command interpreter, but I'll take it :).  So I'm good. 

Thanks.
WG

Wes Gamble wrote:
> I've successfully installed Ruby 1.8.6 on Windows with the 1-click 
> installer.
>
> I have a lot of gems (about 40) that I don't want to re-get.  I copied 
> the entire contents of %RUBY_HOME%/lib/ruby/gems/1.8 from my old 
> installation to my new installation.
>
> When I run "gem list" I still don't see my existing gems.
>
> I have 2 questions:
> 1) What do I need to do to have my existing gems added to the local 
> repository's index?
> 2) Is there a user - level list for rubygems where this type of question 
> would be more appropriate?
>
> Thanks,
> Wes Gamble
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>
>   

From drbrain at segment7.net  Sun Sep  9 13:57:54 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sun, 9 Sep 2007 10:57:54 -0700
Subject: [Rubygems-developers] Moving gems after upgrade from Ruby 1.8.4
	to	1.8.6 on Windows XP
In-Reply-To: <46E415E3.4080407@att.net>
References: <46E40FB0.1020700@att.net> <46E415E3.4080407@att.net>
Message-ID: <4C9E29D7-77C6-41A7-8B29-537B2500B2A1@segment7.net>

On Sep 9, 2007, at 08:48, Wes Gamble wrote:
> Wes Gamble wrote:
>> I've successfully installed Ruby 1.8.6 on Windows with the 1-click
>> installer.
>>
>> I have a lot of gems (about 40) that I don't want to re-get.  I  
>> copied
>> the entire contents of %RUBY_HOME%/lib/ruby/gems/1.8 from my old
>> installation to my new installation.
>>
>> When I run "gem list" I still don't see my existing gems.
>>
>> I have 2 questions:
>> 1) What do I need to do to have my existing gems added to the local
>> repository's index?
>
> OK I'm not sure what I did but when I opened up a new command  
> window and
> executed "gem list" all of my gems were there.  I can't imagine why
> things would change for detecting gems across an invocation of the
> command interpreter, but I'll take it :).  So I'm good.

Your shell was using the old ruby.  The new terminal switched to the  
new ruby.

>> 2) Is there a user - level list for rubygems where this type of  
>> question
>> would be more appropriate?

No.  This list is low traffic anyhow, so it doesn't matter.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From jacron at randann.com  Fri Sep 14 11:08:03 2007
From: jacron at randann.com (Joel Cron)
Date: Fri, 14 Sep 2007 11:08:03 -0400 (EDT)
Subject: [Rubygems-developers] Trouble installing rubygems on Ubuntu feisty
Message-ID: <13158.192.146.101.24.1189782483.squirrel@webmail.randann.com>

Here is the error I'm receiving with 'sudo ruby setup.rb all'.

  Successfully built RubyGem
  Name: sources
  Version: 0.0.1
  File: sources-0.0.1.gem
hook /home/jcron/software/rubygems-0.9.4/./post-install.rb failed:
uninitialized constant Gem::FilePermissionError
Try 'ruby setup.rb --help' for detailed usage.

I've not done anything special with config and not trying to install this
locally.  Any suggestions?

joel



From jabberwock at tenebrous.com  Fri Sep 14 11:16:43 2007
From: jabberwock at tenebrous.com (Michael Behan)
Date: Fri, 14 Sep 2007 11:16:43 -0400
Subject: [Rubygems-developers] Trouble installing rubygems on Ubuntu
	feisty
In-Reply-To: <13158.192.146.101.24.1189782483.squirrel@webmail.randann.com>
References: <13158.192.146.101.24.1189782483.squirrel@webmail.randann.com>
Message-ID: <46EAA5DB.6090906@tenebrous.com>

are you root when installing?

Joel Cron wrote:
> Here is the error I'm receiving with 'sudo ruby setup.rb all'.
>
>   Successfully built RubyGem
>   Name: sources
>   Version: 0.0.1
>   File: sources-0.0.1.gem
> hook /home/jcron/software/rubygems-0.9.4/./post-install.rb failed:
> uninitialized constant Gem::FilePermissionError
> Try 'ruby setup.rb --help' for detailed usage.
>
> I've not done anything special with config and not trying to install this
> locally.  Any suggestions?
>
> joel
>
>
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>
>   


From jabberwock at tenebrous.com  Fri Sep 14 12:00:52 2007
From: jabberwock at tenebrous.com (Michael Behan)
Date: Fri, 14 Sep 2007 12:00:52 -0400
Subject: [Rubygems-developers] Trouble installing rubygems on Ubuntu
	feisty
In-Reply-To: <13158.192.146.101.24.1189782483.squirrel@webmail.randann.com>
References: <13158.192.146.101.24.1189782483.squirrel@webmail.randann.com>
Message-ID: <46EAB034.7070802@tenebrous.com>

Sorry. I didn't see the 'sudo'. Much sleep deprivation! Are you by
chance running SELinux?

Thanks
-Michael
Joel Cron wrote:
> Here is the error I'm receiving with 'sudo ruby setup.rb all'.
>
>   Successfully built RubyGem
>   Name: sources
>   Version: 0.0.1
>   File: sources-0.0.1.gem
> hook /home/jcron/software/rubygems-0.9.4/./post-install.rb failed:
> uninitialized constant Gem::FilePermissionError
> Try 'ruby setup.rb --help' for detailed usage.
>
> I've not done anything special with config and not trying to install this
> locally.  Any suggestions?
>
> joel
>
>
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>
>   


From listsub at twelve71.com  Fri Sep 14 14:06:47 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Fri, 14 Sep 2007 19:06:47 +0100
Subject: [Rubygems-developers] SourceInfoCache.search
Message-ID: <882EEDF7-6470-4E00-BD74-B844B9370BB7@twelve71.com>

I'm building a little tool around gems, mostly as a learning tool.  I  
called SourceInfoCache.search while disconnected and was unsurprised  
to see it fail.   If I rescue and just retry, I get results (which I  
assume are the cache mentioned in the title :-)

If there a way to ask just for the cache without trying to make the  
netcall first ?

A.
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/




From drbrain at segment7.net  Fri Sep 14 21:17:16 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Fri, 14 Sep 2007 18:17:16 -0700
Subject: [Rubygems-developers] SourceInfoCache.search
In-Reply-To: <882EEDF7-6470-4E00-BD74-B844B9370BB7@twelve71.com>
References: <882EEDF7-6470-4E00-BD74-B844B9370BB7@twelve71.com>
Message-ID: <D51D87E0-9C03-4EB7-B610-DB9ED7869C6A@segment7.net>

On Sep 14, 2007, at 11:06, Alan C Francis wrote:

> I'm building a little tool around gems, mostly as a learning tool.  I
> called SourceInfoCache.search while disconnected and was unsurprised
> to see it fail.   If I rescue and just retry, I get results (which I
> assume are the cache mentioned in the title :-)
>
> If there a way to ask just for the cache without trying to make the
> netcall first ?

No.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From chad at chadfowler.com  Sat Sep 15 00:36:04 2007
From: chad at chadfowler.com (Chad Fowler)
Date: Sat, 15 Sep 2007 06:36:04 +0200
Subject: [Rubygems-developers] SourceInfoCache.search
In-Reply-To: <D51D87E0-9C03-4EB7-B610-DB9ED7869C6A@segment7.net>
References: <882EEDF7-6470-4E00-BD74-B844B9370BB7@twelve71.com>
	<D51D87E0-9C03-4EB7-B610-DB9ED7869C6A@segment7.net>
Message-ID: <c67184de0709142136i7825a969tede26c793b8c3802@mail.gmail.com>

On 9/15/07, Eric Hodel <drbrain at segment7.net> wrote:
> On Sep 14, 2007, at 11:06, Alan C Francis wrote:
>
> > I'm building a little tool around gems, mostly as a learning tool.  I
> > called SourceInfoCache.search while disconnected and was unsurprised
> > to see it fail.   If I rescue and just retry, I get results (which I
> > assume are the cache mentioned in the title :-)
> >
> > If there a way to ask just for the cache without trying to make the
> > netcall first ?
>
> No.
>

There's actually an ugly way to do it.  E.g.:

 Gem::SourceInfoCache.new.cache_data.values.map{|s|
s.source_index.map{|g| g.first}}.flatten

Chad

From drbrain at segment7.net  Sun Sep 16 00:11:56 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 15 Sep 2007 21:11:56 -0700
Subject: [Rubygems-developers] SourceInfoCache.search
In-Reply-To: <c67184de0709142136i7825a969tede26c793b8c3802@mail.gmail.com>
References: <882EEDF7-6470-4E00-BD74-B844B9370BB7@twelve71.com>
	<D51D87E0-9C03-4EB7-B610-DB9ED7869C6A@segment7.net>
	<c67184de0709142136i7825a969tede26c793b8c3802@mail.gmail.com>
Message-ID: <E91B83B1-2DAA-47EC-9B01-E2B0DCEB2EBF@segment7.net>

On Sep 14, 2007, at 21:36, Chad Fowler wrote:
> On 9/15/07, Eric Hodel <drbrain at segment7.net> wrote:
>> On Sep 14, 2007, at 11:06, Alan C Francis wrote:
>>
>>> I'm building a little tool around gems, mostly as a learning  
>>> tool.  I
>>> called SourceInfoCache.search while disconnected and was unsurprised
>>> to see it fail.   If I rescue and just retry, I get results (which I
>>> assume are the cache mentioned in the title :-)
>>>
>>> If there a way to ask just for the cache without trying to make the
>>> netcall first ?
>>
>> No.
>>
>
> There's actually an ugly way to do it.  E.g.:
>
>  Gem::SourceInfoCache.new.cache_data.values.map{|s|
> s.source_index.map{|g| g.first}}.flatten

It would be best if we could work with the data on-hand.  I don't  
know how to determine when we're too stale though.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From jacron at randann.com  Mon Sep 17 08:35:51 2007
From: jacron at randann.com (Joel Cron)
Date: Mon, 17 Sep 2007 08:35:51 -0400 (EDT)
Subject: [Rubygems-developers] Trouble installing rubygems on Ubuntu
 feisty
In-Reply-To: <46EAB034.7070802@tenebrous.com>
References: <13158.192.146.101.24.1189782483.squirrel@webmail.randann.com>
	<46EAB034.7070802@tenebrous.com>
Message-ID: <61769.192.146.101.24.1190032551.squirrel@webmail.randann.com>

Michael,

I don't believe I'm running SELinux.  I was under the impression Ubuntu
didn't start it by default the way fedora does.  How could I tell for
sure.

joel

> Sorry. I didn't see the 'sudo'. Much sleep deprivation! Are you by
> chance running SELinux?
>
> Thanks
> -Michael
> Joel Cron wrote:
>> Here is the error I'm receiving with 'sudo ruby setup.rb all'.
>>
>>   Successfully built RubyGem
>>   Name: sources
>>   Version: 0.0.1
>>   File: sources-0.0.1.gem
>> hook /home/jcron/software/rubygems-0.9.4/./post-install.rb failed:
>> uninitialized constant Gem::FilePermissionError
>> Try 'ruby setup.rb --help' for detailed usage.
>>
>> I've not done anything special with config and not trying to install
>> this
>> locally.  Any suggestions?
>>
>> joel
>>
>>
>> _______________________________________________
>> Rubygems-developers mailing list
>> Rubygems-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rubygems-developers
>>
>>
>
>



From jacron at randann.com  Mon Sep 17 10:45:04 2007
From: jacron at randann.com (Joel Cron)
Date: Mon, 17 Sep 2007 10:45:04 -0400 (EDT)
Subject: [Rubygems-developers] Trouble installing rubygems on Ubuntu
 feisty
In-Reply-To: <46EAB034.7070802@tenebrous.com>
References: <13158.192.146.101.24.1189782483.squirrel@webmail.randann.com>
	<46EAB034.7070802@tenebrous.com>
Message-ID: <53217.192.146.101.24.1190040304.squirrel@webmail.randann.com>

Okay, suffering from a true WTF moment here.  I logged out and back in and
setup.rb ran just fine and the 'gem' command seems to be working fine.  I
don't know what could have been different.  Believe me, I'm duly
embarassed and sorry.

joel

> Sorry. I didn't see the 'sudo'. Much sleep deprivation! Are you by
> chance running SELinux?
>
> Thanks
> -Michael
> Joel Cron wrote:
>> Here is the error I'm receiving with 'sudo ruby setup.rb all'.
>>
>>   Successfully built RubyGem
>>   Name: sources
>>   Version: 0.0.1
>>   File: sources-0.0.1.gem
>> hook /home/jcron/software/rubygems-0.9.4/./post-install.rb failed:
>> uninitialized constant Gem::FilePermissionError
>> Try 'ruby setup.rb --help' for detailed usage.
>>
>> I've not done anything special with config and not trying to install
>> this
>> locally.  Any suggestions?
>>
>> joel
>>
>>
>> _______________________________________________
>> Rubygems-developers mailing list
>> Rubygems-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rubygems-developers
>>
>>
>
>



From drbrain at segment7.net  Wed Sep 19 20:47:39 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 19 Sep 2007 17:47:39 -0700
Subject: [Rubygems-developers] Beta Time?
In-Reply-To: <072A6FC7-0924-40A1-9BB6-514132D948B9@segment7.net>
References: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net>
	<e3af97510708251942jbaaa4f0i25d6f4cd9861c703@mail.gmail.com>
	<A7AC9BE3-79E6-4921-996C-79ADEA33F0DB@segment7.net>
	<0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com>
	<4E316973-6D54-48CD-BF8E-0F46B065EB8F@zenspider.com>
	<072A6FC7-0924-40A1-9BB6-514132D948B9@segment7.net>
Message-ID: <FD09D5CD-D3E1-40A5-824A-5484593DA19A@segment7.net>

On Aug 29, 2007, at 21:15, Eric Hodel wrote:
> On Aug 27, 2007, at 20:08, Ryan Davis wrote:
>> On Aug 27, 2007, at 10:51 , Jim Weirich wrote:
>>> On Aug 26, 2007, at 4:03 PM, Eric Hodel wrote:
>>>> On Aug 25, 2007, at 19:42, Chad Woolley wrote:
>>>>> Sounds great.  I'll play with it.  Do you have to package it,  
>>>>> or is
>>>>> there a tag, or just use trunk?
>>>>
>>>> svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4
>>>>
>>>> I sent packages to Jim, he should announce them in the next day or
>>>> two when he gets a spare moment.
>>>
>>> I'm having a problem with the beta version.  It complains about the
>>> POpen gem.  I uninstalled POpen and reinstalled it using the beta,
>>> but it still fails.
>>
>> Try this (made against head, but should apply to either?):
>>
>> Index: test/test_gem_specification.rb
>> ===================================================================
>> --- test/test_gem_specification.rb	(revision 1378)
>> +++ test/test_gem_specification.rb	(working copy)
>> @@ -454,6 +454,17 @@
>>       @a0_0_1.platform = Gem::Platform::DARWIN
>>       assert_equal ['powerpc', 'darwin', nil], @a0_0_1.platform
>> +
>> +    util_set_arch 'i686-linux'
>> +    @a0_0_1.platform = Gem::Platform::UNIX
>> +    assert_equal Gem::Platform.local, @a0_0_1.platform
>> +
>> +    %w(java mswin32 mingw32).each do |arch|
>> +      util_set_arch arch
>> +      assert_raises Gem::Exception do
>> +        @a0_0_1.platform = Gem::Platform::UNIX
>> +      end
>> +    end
>>     end
>>     def test_require_paths
>> Index: lib/rubygems/specification.rb
>> ===================================================================
>> --- lib/rubygems/specification.rb	(revision 1378)
>> +++ lib/rubygems/specification.rb	(working copy)
>> @@ -297,7 +297,11 @@
>>           @platform = Gem::Platform::X86_LINUX
>>         when Platform::DARWIN then
>>           @platform = Gem::Platform::PPC_DARWIN
>> -
>> +      when Platform::UNIX then
>> +        @platform = Gem::Platform.local
>> +        raise Gem::Exception,
>> +          "invalid platform #{platform.inspect}, see
>> Gem::Platform" if
>> +          @platform[1] =~ /mswin|mingw|java/ # HACK prolly should go
>> a more heirarchical route
>>         else
>>           raise Gem::Exception,
>>             "invalid platform #{platform.inspect}, see Gem::Platform"
>
> My thought for raising the exception was to make gem authors switch
> from whichever string they thought was appropriate (like "unix" or
> "win32-1.8.2-VC7") to Gem::Platform::CURRENT.  It shouldn't be raised
> when evaling a gemspec.
>
> I don't like the code that would be needed (checking the stack) to
> make that work.  Maybe it should just be dropped and a HACK tag added
> pointing to the POpen4 gem?

Ok, this is handled in Gem::Specification#validate now, which is  
called in Gem::Builder.  Now only builders of the gem will see the  
error, which is as it should be.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From drbrain at segment7.net  Wed Sep 19 22:57:31 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 19 Sep 2007 19:57:31 -0700
Subject: [Rubygems-developers] Test failures for 0.9.4.4 beta on Windows
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72DC0@ITOMAE2KM01.AD.QINTRA.COM>
References: <7524A45A1A5B264FA4809E2156496CFBE72DC0@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <EDB04D68-4B95-4AC2-BE9D-4B6E8103CE8B@segment7.net>

On Aug 31, 2007, at 07:27, Berger, Daniel wrote:
>> -----Original Message-----
>> From: rubygems-developers-bounces at rubyforge.org
>> [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf
>> Of Daniel Berger
>> Sent: Wednesday, August 29, 2007 8:37 PM
>> To: rubygems-developers at rubyforge.org
>> Subject: [Rubygems-developers] Test failures for 0.9.4.4 beta
>> on Windows
>>
>>
>> Hi all,
>>
>> Ruby 1.8.5 (one click)
>> Windows XP SP 2
>> Rubygems tag REL_0_9_4_4
>>
>> Most of these look like path handling or teardown issues in the test
>> suite itself, but I'll investigate a couple of these.
>>
>> Look for a patch this weekend...
>
> <snip>
>
> I've submitted a series of patches on the project page that cut it  
> down
> to 2 failures and 2 errors.
>
> Please see:
>
> http://rubyforge.org/tracker/index.php? 
> func=detail&aid=13528&group_id=12
> 6&atid=577
> http://rubyforge.org/tracker/index.php? 
> func=detail&aid=13529&group_id=12
> 6&atid=577
> http://rubyforge.org/tracker/index.php? 
> func=detail&aid=13533&group_id=12
> 6&atid=577
> http://rubyforge.org/tracker/index.php? 
> func=detail&aid=13535&group_id=12
> 6&atid=577
> http://rubyforge.org/tracker/index.php? 
> func=detail&aid=13537&group_id=12
> 6&atid=577

All applied!

> Here are the remaining issues:
>
>   1) Error:
> test_execute(TestGemCommandsPristineCommand):
> SecurityError: Insecure operation - initialize
>     ./lib/rubygems/installer.rb:272:in `initialize'
>     ./lib/rubygems/installer.rb:272:in `open'
>     ./lib/rubygems/installer.rb:272:in `shebang'
>     ./lib/rubygems/installer.rb:290:in `app_script_text'
>     ./lib/rubygems/installer.rb:229:in `generate_bin_script'
>     ./lib/rubygems/installer.rb:228:in `open'
>     ./lib/rubygems/installer.rb:228:in `generate_bin_script'
>     ./lib/rubygems/installer.rb:241:in `generate_bin_symlink'
>     ./lib/rubygems/installer.rb:215:in `generate_bin'
>     ./lib/rubygems/installer.rb:206:in `each'
>     ./lib/rubygems/installer.rb:206:in `generate_bin'
>     ./lib/rubygems/installer.rb:112:in `install'
>     ./test/gemutilities.rb:117:in `install_gem'
>     ./test/test_gem_commands_pristine_command.rb:19:in `test_execute'
>
> I may have introduced this bug in my attempt to fix the filehandle
> closing issue in patch #13533. I haven't investigated further.

Not sure, I'm not getting the SecurityError with your patches.

>   2) Failure:
> test_download_gem_local_read_only(TestGemDependencyInstaller)
> [./test/test_gem_dependency_installer.rb:356]:
> <"C:/WINNT/temp/test_rubygems_2032/a-1.gem"> expected but was
> <"C:/WINNT/temp/test_rubygems_2032/gemhome/cache/a-1.gem">.
>
> I'm not sure if the patch is bad or the test is bad. See my comment in
> patch #13537.

This test uses chmod which doesn't do anything on mswin.

>   3) Error:
> test_generate_index(TestGemIndexerIndexer):
> Zlib::BufError: buffer error
>     ./lib/rubygems/indexer/compressor.rb:22:in `inflate'
>     ./lib/rubygems/indexer/compressor.rb:22:in `unzip'
>     ./lib/rubygems/indexer/master_index_builder.rb:38:in `paranoid'
>     ./lib/rubygems/indexer/master_index_builder.rb:20:in `cleanup'
>     ./lib/rubygems/indexer/abstract_index_builder.rb:42:in `build'
>     ./lib/rubygems/indexer/indexer.rb:34:in `build_index'
>     ./lib/rubygems/indexer/indexer.rb:91:in `generate_index'
>     ./test/test_gem_indexer_indexer.rb:34:in `test_generate_index'
>     ./lib/rubygems/user_interaction.rb:45:in `use_ui'
>     ./lib/rubygems/user_interaction.rb:27:in `use_ui'
>     ./test/test_gem_indexer_indexer.rb:33:in `test_generate_index'
>
> No clue. Will require diving into some ugly C code with a wet suit  
> and a
> spear gun.

Is this repeatable?  I had one of these go by once in the last day.

>   4) Failure:
> test_self_match_version(TestGemPlatform)
> [./test/test_gem_platform.rb:74]:
> versionless == any.
> <false> is not true.
>
> This failure is caused by changing the architecture in patch  
> #13529, but
> the lack of a release number in Config::CONFIG['arch'] for MS Windows
> made me unsure how the tests should be refactored.

I've reworked Gem::Platform to be a real object now with methods like  
#=== and #=~ and so-forth, so this may have moved.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From ryand-ruby at zenspider.com  Thu Sep 20 04:24:19 2007
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Thu, 20 Sep 2007 01:24:19 -0700
Subject: [Rubygems-developers] bug in latest_specs
In-Reply-To: <58B85DE4-C0AC-4A06-97CD-19F9CC6DDB22@zenspider.com>
References: <43679DC1-DB01-4802-A136-B1AC2BAF0519@zenspider.com>
	<58B85DE4-C0AC-4A06-97CD-19F9CC6DDB22@zenspider.com>
Message-ID: <644F5828-6200-47ED-92E8-6F751CB31263@zenspider.com>

class Gem::SourceIndex
   alias :dead_latest_specs :latest_specs
   def latest_specs
     result, latest = Hash.new { |h,k| h[k] = [] }, {}

     self.each do |_, spec| # SourceIndex is not a hash, so we're  
stuck with each
       name = spec.name
       curr_ver = spec.version
       prev_ver = latest[name]

       next unless prev_ver.nil? or curr_ver >= prev_ver

       if prev_ver.nil? or curr_ver > prev_ver then
         result[name].clear
         latest[name] = curr_ver
       end

       result[name] << spec
     end

     result.values.flatten
   end
end

This is my latest version and works well. I'm using it with flog and  
a new project.

From djberg96 at gmail.com  Thu Sep 20 07:49:45 2007
From: djberg96 at gmail.com (Daniel Berger)
Date: Thu, 20 Sep 2007 05:49:45 -0600
Subject: [Rubygems-developers] Test failures for 0.9.4.4 beta on Windows
In-Reply-To: <EDB04D68-4B95-4AC2-BE9D-4B6E8103CE8B@segment7.net>
References: <7524A45A1A5B264FA4809E2156496CFBE72DC0@ITOMAE2KM01.AD.QINTRA.COM>
	<EDB04D68-4B95-4AC2-BE9D-4B6E8103CE8B@segment7.net>
Message-ID: <46F25E59.8090402@gmail.com>

Eric Hodel wrote:
> On Aug 31, 2007, at 07:27, Berger, Daniel wrote:

<snip>

>> Please see:
>>
>> http://rubyforge.org/tracker/index.php? 
>> func=detail&aid=13528&group_id=12
>> 6&atid=577
>> http://rubyforge.org/tracker/index.php? 
>> func=detail&aid=13529&group_id=12
>> 6&atid=577
>> http://rubyforge.org/tracker/index.php? 
>> func=detail&aid=13533&group_id=12
>> 6&atid=577
>> http://rubyforge.org/tracker/index.php? 
>> func=detail&aid=13535&group_id=12
>> 6&atid=577
>> http://rubyforge.org/tracker/index.php? 
>> func=detail&aid=13537&group_id=12
>> 6&atid=577
> 
> All applied!

Excellent! Eric and I worked on this last night a bit and we're down to 
two errors.

>> Here are the remaining issues:
>>
>>   1) Error:
>> test_execute(TestGemCommandsPristineCommand):
>> SecurityError: Insecure operation - initialize
>>     ./lib/rubygems/installer.rb:272:in `initialize'
>>     ./lib/rubygems/installer.rb:272:in `open'
>>     ./lib/rubygems/installer.rb:272:in `shebang'
>>     ./lib/rubygems/installer.rb:290:in `app_script_text'
>>     ./lib/rubygems/installer.rb:229:in `generate_bin_script'
>>     ./lib/rubygems/installer.rb:228:in `open'
>>     ./lib/rubygems/installer.rb:228:in `generate_bin_script'
>>     ./lib/rubygems/installer.rb:241:in `generate_bin_symlink'
>>     ./lib/rubygems/installer.rb:215:in `generate_bin'
>>     ./lib/rubygems/installer.rb:206:in `each'
>>     ./lib/rubygems/installer.rb:206:in `generate_bin'
>>     ./lib/rubygems/installer.rb:112:in `install'
>>     ./test/gemutilities.rb:117:in `install_gem'
>>     ./test/test_gem_commands_pristine_command.rb:19:in `test_execute'
>>
>> I may have introduced this bug in my attempt to fix the filehandle
>> closing issue in patch #13533. I haven't investigated further.
> 
> Not sure, I'm not getting the SecurityError with your patches.

This one is gone now.

> 
>>   2) Failure:
>> test_download_gem_local_read_only(TestGemDependencyInstaller)
>> [./test/test_gem_dependency_installer.rb:356]:
>> <"C:/WINNT/temp/test_rubygems_2032/a-1.gem"> expected but was
>> <"C:/WINNT/temp/test_rubygems_2032/gemhome/cache/a-1.gem">.
>>
>> I'm not sure if the patch is bad or the test is bad. See my comment in
>> patch #13537.
> 
> This test uses chmod which doesn't do anything on mswin.

This one is also gone.

>>   3) Error:
>> test_generate_index(TestGemIndexerIndexer):
>> Zlib::BufError: buffer error
>>     ./lib/rubygems/indexer/compressor.rb:22:in `inflate'
>>     ./lib/rubygems/indexer/compressor.rb:22:in `unzip'
>>     ./lib/rubygems/indexer/master_index_builder.rb:38:in `paranoid'
>>     ./lib/rubygems/indexer/master_index_builder.rb:20:in `cleanup'
>>     ./lib/rubygems/indexer/abstract_index_builder.rb:42:in `build'
>>     ./lib/rubygems/indexer/indexer.rb:34:in `build_index'
>>     ./lib/rubygems/indexer/indexer.rb:91:in `generate_index'
>>     ./test/test_gem_indexer_indexer.rb:34:in `test_generate_index'
>>     ./lib/rubygems/user_interaction.rb:45:in `use_ui'
>>     ./lib/rubygems/user_interaction.rb:27:in `use_ui'
>>     ./test/test_gem_indexer_indexer.rb:33:in `test_generate_index'
>>
>> No clue. Will require diving into some ugly C code with a wet suit  
>> and a
>> spear gun.
> 
> Is this repeatable?  I had one of these go by once in the last day.

Eric smoked out the problem in 
lib/rubygems/indexer/master_index_builder.rb - we needed a binary read. 
Yay, Eric!

>>   4) Failure:
>> test_self_match_version(TestGemPlatform)
>> [./test/test_gem_platform.rb:74]:
>> versionless == any.
>> <false> is not true.
>>
>> This failure is caused by changing the architecture in patch  
>> #13529, but
>> the lack of a release number in Config::CONFIG['arch'] for MS Windows
>> made me unsure how the tests should be refactored.

Also fixed.

We're down to these two, which both appear to be caused by an old stub 
(I think):

   1) Failure:
test_class_build(TestGemExtRakeBuilder) 
[./test/test_gem_ext_rake_builder.rb:41]:
<["ruby mkrf_conf.rb",
  "",
  "rake 
RUBYARCHDIR=C:/DOCUME~1/djberge/LOCALS~1/Temp/test_rubygems_3360/prefix 
RUBYLIBDIR=C:/DOCUME~1/djberge/LOCALS~1/T
emp/test_rubygems_3360/prefix",
  "(in C:/DOCUME~1/djberge/LOCALS~1/Temp/test_rubygems_3360/ext)\n"]> 
expected but was
<["ruby mkrf_conf.rb",
  "",
  "rake 
RUBYARCHDIR=C:/DOCUME~1/djberge/LOCALS~1/Temp/test_rubygems_3360/prefix 
RUBYLIBDIR=C:/DOCUME~1/djberge/LOCALS~1/T
emp/test_rubygems_3360/prefix",
  "(in 
C:/DOCUME~1/djberge/LOCALS~1/Temp/test_rubygems_3360/ext)\nC:0:Warning: 
require_gem is obsolete.  Use gem instead.
\n"]>.

   2) Failure:
test_class_build_fail(TestGemExtRakeBuilder) 
[./test/test_gem_ext_rake_builder.rb:55]:
<Gem::InstallError> exception expected but none was thrown.

452 tests, 1569 assertions, 2 failures, 0 errors
rake aborted!
Command failed with status (1): [C:/ruby/bin/ruby -w -Ilib 
"C:/ruby/lib/rub...]

Attempts to clean it with 'gem pristine --all' or 'gem pristine rake' 
didn't work, and Eric is working on that now I believe.

Regards,

Dan

From drbrain at segment7.net  Thu Sep 20 17:37:57 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 20 Sep 2007 14:37:57 -0700
Subject: [Rubygems-developers] Source caches again.
In-Reply-To: <Pine.GSO.4.64.0708291831270.22900@brains.eng.cse.dmu.ac.uk>
References: <Pine.GSO.4.64.0708221424240.12350@brains.eng.cse.dmu.ac.uk>
	<1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>
	<Pine.GSO.4.64.0708241144550.261@brains.eng.cse.dmu.ac.uk>
	<EC20F6A1-2133-4AB3-943B-DC3B8ACC0C33@zenspider.com>
	<Pine.GSO.4.64.0708281027050.261@brains.eng.cse.dmu.ac.uk>
	<CA6C6513-A5C5-4645-9FED-9D67CDB29823@zenspider.com>
	<Pine.GSO.4.64.0708291006090.22900@brains.eng.cse.dmu.ac.uk>
	<b37300880708290715h17130d29r7768eab9c500439@mail.gmail.com>
	<Pine.GSO.4.64.0708291624550.22900@brains.eng.cse.dmu.ac.uk>
	<Pine.GSO.4.64.0708291831270.22900@brains.eng.cse.dmu.ac.uk>
Message-ID: <7B8E9770-133D-4D59-95D8-88CA423B0949@segment7.net>

On Aug 29, 2007, at 10:38, Hugh Sasse wrote:
> On Wed, 29 Aug 2007, I wrote:
>
>> Thanks.  I managed to miss that.
>>
>> :r! gem help source | grep cache | wc
>>        0       0       0
>>
>> no mention of the cache in there.  I'll try to work up a doc patch
>>
>>         Hugh
>
> I've come up with this so far. Not as nice as I'd like, the  
> duplication
> in the second part is basically vile, maybe remove_cache could be a
> protected method of command?  Well, that isn't beautiful either, is  
> it?
> Command then knows too much about Source.  Oh well, I'm sure someone
> here can come up with something better.  This is untested as yet,  
> by the
> way, so beware.  A patch against the unpacked tar ball grabbed from
> Rubyforge.
>         Hugh
>
> :r! (cd /scratch/hgs; display_diffs.rb rubygems-0.9.4)
>
> --- rubygems-0.9.4/lib/rubygems/commands/sources_command.rb.orig	 
> 2007-05-23 15:51:31.000000000 +0100
> +++ rubygems-0.9.4/lib/rubygems/commands/sources_command.rb	 
> 2007-08-29 18:15:20.674031000 +0100
> @@ -18,7 +18,7 @@
>            options[:remove] = value
>          end
>
> -        add_option '-c', '--clear-all', 'Remove all sources' do | 
> value, options|
> +        add_option '-c', '--clear-all', 'Remove all sources (clear  
> the cache)' do |value, options|
>            options[:clear_all] = value
>          end
>        end

This part I like.  I also changed the description to:

   'Manage the sources and cache file RubyGems uses to search for gems'

> --- rubygems-0.9.4/lib/rubygems/commands/ 
> clear_cache_command.rb.orig	2007-08-29 18:22:58.049867000 +0100
> +++ rubygems-0.9.4/lib/rubygems/commands/clear_cache_command.rb	 
> 2007-08-29 18:29:57.586782000 +0100
> @@ -0,0 +1,37 @@
> +module Gem
> +  module Commands
> +
> +    class Clear_cacheCommand < Command
> +
> +      def initialize
> +        super 'clear_cache', 'clear the sources i.e the cache.'
> +
> +      end
> +
> +      def defaults_str
> +        ''
> +      end
> +
> +      def execute
> +        remove_cache_file("user",  
> Gem::SourceInfoCache.user_cache_file)
> +        remove_cache_file("system",  
> Gem::SourceInfoCache.system_cache_file)
> +        say "Cache cleared"
> +
> +      end
> +
> +      def remove_cache_file(desc, fn)
> +        FileUtils.rm_rf fn rescue nil
> +        if ! File.exist?(fn)
> +          say "*** Removed #{desc} source cache ***"
> +        elsif ! File.writable?(fn)
> +          say "*** Unable to remove #{desc} source cache (write  
> protected) ***"
> +        else
> +          say "*** Unable to remove #{desc} source cache ***"
> +        end
> +      end
> +      private :remove_cache_file
> +      # It's private, so we need our own copy. Very non-DRY.
> +
> +    end # class Clear_cacheCommand
> +  end # module Commands
> +end # module Gem

I don't understand this part.  How is this different from `gem  
sources -c`?

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From hgs at dmu.ac.uk  Fri Sep 21 04:51:25 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Fri, 21 Sep 2007 09:51:25 +0100 (WEST)
Subject: [Rubygems-developers] Source caches again.
In-Reply-To: <7B8E9770-133D-4D59-95D8-88CA423B0949@segment7.net>
References: <Pine.GSO.4.64.0708221424240.12350@brains.eng.cse.dmu.ac.uk>
	<1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>
	<Pine.GSO.4.64.0708241144550.261@brains.eng.cse.dmu.ac.uk>
	<EC20F6A1-2133-4AB3-943B-DC3B8ACC0C33@zenspider.com>
	<Pine.GSO.4.64.0708281027050.261@brains.eng.cse.dmu.ac.uk>
	<CA6C6513-A5C5-4645-9FED-9D67CDB29823@zenspider.com>
	<Pine.GSO.4.64.0708291006090.22900@brains.eng.cse.dmu.ac.uk>
	<b37300880708290715h17130d29r7768eab9c500439@mail.gmail.com>
	<Pine.GSO.4.64.0708291624550.22900@brains.eng.cse.dmu.ac.uk>
	<Pine.GSO.4.64.0708291831270.22900@brains.eng.cse.dmu.ac.uk>
	<7B8E9770-133D-4D59-95D8-88CA423B0949@segment7.net>
Message-ID: <Pine.GSO.4.64.0709210939270.20822@brains.eng.cse.dmu.ac.uk>

On Thu, 20 Sep 2007, Eric Hodel wrote:

> On Aug 29, 2007, at 10:38, Hugh Sasse wrote:
> > On Wed, 29 Aug 2007, I wrote:
> >
> >> Thanks.  I managed to miss that.
> >>
> >> :r! gem help source | grep cache | wc
> >>        0       0       0
> >>
> >> no mention of the cache in there.  I'll try to work up a doc patch
> >>
> >>         Hugh
> >
> > I've come up with this so far. Not as nice as I'd like, the  
> > duplication
        [...]
> > here can come up with something better.  This is untested as yet,  
> > by the
> > way, so beware.  A patch against the unpacked tar ball grabbed from
> > Rubyforge.
> >         Hugh
> >
> > :r! (cd /scratch/hgs; display_diffs.rb rubygems-0.9.4)
> >
> > --- rubygems-0.9.4/lib/rubygems/commands/sources_command.rb.orig	 
> > 2007-05-23 15:51:31.000000000 +0100
> > +++ rubygems-0.9.4/lib/rubygems/commands/sources_command.rb	 
> > 2007-08-29 18:15:20.674031000 +0100
> > @@ -18,7 +18,7 @@
> >            options[:remove] = value
> >          end
> >
> > -        add_option '-c', '--clear-all', 'Remove all sources' do | 
> > value, options|
> > +        add_option '-c', '--clear-all', 'Remove all sources (clear  
> > the cache)' do |value, options|
> >            options[:clear_all] = value
> >          end
> >        end
> 
> This part I like.  I also changed the description to:
> 
>    'Manage the sources and cache file RubyGems uses to search for gems'
> 

Thank you.
> > --- rubygems-0.9.4/lib/rubygems/commands/ 
> > clear_cache_command.rb.orig	2007-08-29 18:22:58.049867000 +0100
> > +++ rubygems-0.9.4/lib/rubygems/commands/clear_cache_command.rb	 
> > 2007-08-29 18:29:57.586782000 +0100
> > @@ -0,0 +1,37 @@
> > +module Gem
> > +  module Commands
> > +
> > +    class Clear_cacheCommand < Command
> > +
        [...]
> > +
> > +    end # class Clear_cacheCommand
> > +  end # module Commands
> > +end # module Gem
> 
> I don't understand this part.  How is this different from `gem  
> sources -c`?

I needed a way to put in a command name that reflected the semantics
of "clear the cache".  As far as I could see your commands are defined
separately, so I had to create a new class for it.  My intent was to 
allow more than one way to do this:  either
gem sources -c
or 
gem clear_cache
and this was the only way I could see to create this command.  Maybe
there's a better way I have missed to add that command.

In case you're wondering why anyone would need another command: I didn't
know till I poked around in this what was actually cached.  I didn't know
it was the sources as such.  So "clear the cache" which people mention
didn't lead me to look at the source command. Therefore I thought people
would look for a separate command.

        Thank you
        Hugh

From listsub at twelve71.com  Sat Sep 22 02:23:24 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Sat, 22 Sep 2007 07:23:24 +0100
Subject: [Rubygems-developers] SourceInfoCache.search (Eric Hodel)
In-Reply-To: <mailman.212.1190257054.15851.rubygems-developers@rubyforge.org>
References: <mailman.212.1190257054.15851.rubygems-developers@rubyforge.org>
Message-ID: <6CE09B6D-E557-4902-B312-A39EA414580B@twelve71.com>

>> There's actually an ugly way to do it.  E.g.:
>>
>>  Gem::SourceInfoCache.new.cache_data.values.map{|s|
>> s.source_index.map{|g| g.first}}.flatten
>
> It would be best if we could work with the data on-hand.  I don't
> know how to determine when we're too stale though.

It could be left up to users ?   Some options:

a) a flag on install / list
b) update local cache only on 'outdated' or 'update'
c) go the apt route and add a command specifically to refresh the  
local cache.

In any case, even if the default 'gem' behaviour was to *always*  
update before any operation, and there was no CLI command to do it,  
providing a programmatic way to search the local cache would be  
useful for tool developers (by which, of course, I mean specifically  
me :).

The thing I'm building, which again I stress is mostly a RubyCocoa  
learning tool, is a two-tab window with 'local' and 'remote'.  I aim  
to be able to 'remove' and 'install' respectively.  I've added a  
'live' search to each tab which also works fine right now.  I'm  
planning to do such arbitrary operations as 'find all other gems by  
this author', and 'fire up a gem_server and start a browser on the  
help for this gem'

I can successfully populate both local and remote, but right now I've  
opted for a manual 'retrieve' button on the remote tab since the app  
hung for a fair-old-while when loading the remote gems.  If I could  
load the remote gems piecemeal and refresh the GUI as new gems are  
discovered, that'd be perfect.  Perfect being somewhat unattainable  
I'd love to just populate (quickly) from local cache, check for  
outdated version when installing, and add a user operation to update  
the cache.

Any thoughts on any of this welcomed as a somewhat academic discussion.

A.
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/


From drbrain at segment7.net  Sat Sep 22 05:38:34 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 22 Sep 2007 02:38:34 -0700
Subject: [Rubygems-developers] Source caches again.
In-Reply-To: <Pine.GSO.4.64.0709210939270.20822@brains.eng.cse.dmu.ac.uk>
References: <Pine.GSO.4.64.0708221424240.12350@brains.eng.cse.dmu.ac.uk>
	<1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>
	<Pine.GSO.4.64.0708241144550.261@brains.eng.cse.dmu.ac.uk>
	<EC20F6A1-2133-4AB3-943B-DC3B8ACC0C33@zenspider.com>
	<Pine.GSO.4.64.0708281027050.261@brains.eng.cse.dmu.ac.uk>
	<CA6C6513-A5C5-4645-9FED-9D67CDB29823@zenspider.com>
	<Pine.GSO.4.64.0708291006090.22900@brains.eng.cse.dmu.ac.uk>
	<b37300880708290715h17130d29r7768eab9c500439@mail.gmail.com>
	<Pine.GSO.4.64.0708291624550.22900@brains.eng.cse.dmu.ac.uk>
	<Pine.GSO.4.64.0708291831270.22900@brains.eng.cse.dmu.ac.uk>
	<7B8E9770-133D-4D59-95D8-88CA423B0949@segment7.net>
	<Pine.GSO.4.64.0709210939270.20822@brains.eng.cse.dmu.ac.uk>
Message-ID: <C4BC96A1-7FF8-4E18-9008-7744C559482B@segment7.net>

On Sep 21, 2007, at 01:51, Hugh Sasse wrote:
> On Thu, 20 Sep 2007, Eric Hodel wrote:
>> On Aug 29, 2007, at 10:38, Hugh Sasse wrote:
>>> On Wed, 29 Aug 2007, I wrote:
>>> --- rubygems-0.9.4/lib/rubygems/commands/
>>> clear_cache_command.rb.orig	2007-08-29 18:22:58.049867000 +0100
>>> +++ rubygems-0.9.4/lib/rubygems/commands/clear_cache_command.rb	
>>
>> I don't understand this part.  How is this different from `gem
>> sources -c`?
>
> I needed a way to put in a command name that reflected the semantics
> of "clear the cache".  As far as I could see your commands are defined
> separately, so I had to create a new class for it.  My intent was to
> allow more than one way to do this:  either
> gem sources -c
> or
> gem clear_cache
> and this was the only way I could see to create this command.  Maybe
> there's a better way I have missed to add that command.
>
> In case you're wondering why anyone would need another command: I  
> didn't
> know till I poked around in this what was actually cached.  I  
> didn't know
> it was the sources as such.  So "clear the cache" which people mention
> didn't lead me to look at the source command. Therefore I thought  
> people
> would look for a separate command.

Is a change in documentation sufficient?  The sources command's  
description now reads:

$ gem help commands | grep -A1 sources
     sources           Manage the sources and cache file RubyGems  
uses to search
                       for gems

Also, the way the source cache works has been changed since the last  
release.  When --source (for install, etc) is given, only the sources  
listed on the command line are used.  To add extra sources  
permanently you must run `gem sources --add`.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From drbrain at segment7.net  Sat Sep 22 05:45:43 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 22 Sep 2007 02:45:43 -0700
Subject: [Rubygems-developers] SourceInfoCache.search (Eric Hodel)
In-Reply-To: <6CE09B6D-E557-4902-B312-A39EA414580B@twelve71.com>
References: <mailman.212.1190257054.15851.rubygems-developers@rubyforge.org>
	<6CE09B6D-E557-4902-B312-A39EA414580B@twelve71.com>
Message-ID: <10B8492C-0FE1-429F-B226-79F0E67FAF5F@segment7.net>

On Sep 21, 2007, at 23:23, Alan C Francis wrote:
>>> There's actually an ugly way to do it.  E.g.:
>>>
>>>  Gem::SourceInfoCache.new.cache_data.values.map{|s|
>>> s.source_index.map{|g| g.first}}.flatten
>>
>> It would be best if we could work with the data on-hand.  I don't
>> know how to determine when we're too stale though.
>
> It could be left up to users ?   Some options:
>
> a) a flag on install / list
> b) update local cache only on 'outdated' or 'update'
> c) go the apt route and add a command specifically to refresh the
> local cache.
>
> In any case, even if the default 'gem' behaviour was to *always*
> update before any operation, and there was no CLI command to do it,
> providing a programmatic way to search the local cache would be
> useful for tool developers (by which, of course, I mean specifically
> me :).

I think I would like:

If Gem.configuration.update_sources is true (default) the source  
cache will be updated automatically.

Add `gem sources --update` (or -u) to force a source cache update.

You should then be able to override the user's  
Gem.configuration.update_sources value for your purposes.

I don't have time to write it.  Could you write up a patch and put it  
in the tracker?  (Don't forget tests!)

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From drbrain at segment7.net  Sat Sep 22 19:43:55 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 22 Sep 2007 16:43:55 -0700
Subject: [Rubygems-developers] `gem help` descriptions
Message-ID: <4D120A60-F43C-4A4A-AE30-64F2F2301FDF@segment7.net>

I've added descriptions to `gem help` output, but only for the  
following commands:

lib/rubygems/commands/lock_command.rb
lib/rubygems/commands/mirror_command.rb
lib/rubygems/commands/pristine_command.rb
lib/rubygems/commands/server_command.rb

I'd like help writing the rest of them, unless the summary is  
sufficient.

For example, here's `gem help lock`:

$ ruby -Ilib bin/gem help lock
Usage: gem lock GEMNAME-VERSION [GEMNAME-VERSION ...] [options]

   Options:
     -s, --[no-]strict                fail if unable to satisfy a  
dependency

   Common Options:
     -h, --help                       Get help on this command
     -v, --[no-]verbose               Set the verbose level of output
         --config-file FILE           Use this config file instead of  
default
         --backtrace                  Show stack backtrace on errors
         --debug                      Turn on Ruby debugging


   Arguments:
     GEMNAME       name of gem to lock
     VERSION       version of gem to lock

   Summary:
     Generate a lockdown list of gems

   Description:
     The lock command will generate a list of +gem+ statements that  
will lock
     down
     the versions for the gem given in the command line.  It will  
specify exact
     versions in the requirements list to ensure that the gems loaded  
will always
     be consistent.  A full recursive search of all effected gems  
will be
     generated.

     Example:

       gemlock rails-1.0.0 > lockdown.rb

     will produce in lockdown.rb:

       require "rubygems"
       gem 'rails', '= 1.0.0'
       gem 'rake', '= 0.7.0.1'
       gem 'activesupport', '= 1.2.5'
       gem 'activerecord', '= 1.13.2'
       gem 'actionpack', '= 1.11.2'
       gem 'actionmailer', '= 1.1.5'
       gem 'actionwebservice', '= 1.0.0'

     Just load lockdown.rb from your application to ensure that the  
current
     versions are loaded.  Make sure that lockdown.rb is loaded  
*before* any
     other require statements.

     Notice that rails 1.0.0 only requires that rake 0.6.2 or better  
be used.
     Rake-0.7.0.1 is the most recent version installed that satisfies  
that, so we
     lock it down to the exact version.

   Defaults:
     --no-strict

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From listsub at twelve71.com  Sun Sep 23 02:09:19 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Sun, 23 Sep 2007 07:09:19 +0100
Subject: [Rubygems-developers] SourceInfoCache.search (Eric Hodel)
In-Reply-To: <mailman.55.1190454348.10750.rubygems-developers@rubyforge.org>
References: <mailman.55.1190454348.10750.rubygems-developers@rubyforge.org>
Message-ID: <78CB41D1-03E6-4337-81CC-CDACEBBB1372@twelve71.com>

Hi Eric,

On 22 Sep 2007, at 10:45, rubygems-developers-request at rubyforge.org  
wrote:

> I think I would like:
>
> If Gem.configuration.update_sources is true (default) the source
> cache will be updated automatically.

Do you mean for the search (my original request) or for all commands  
where the cache is update (eg install)

>
> Add `gem sources --update` (or -u) to force a source cache update.
>

This I'm pretty clear on.

> You should then be able to override the user's
> Gem.configuration.update_sources value for your purposes.
>
> I don't have time to write it.  Could you write up a patch and put it
> in the tracker?

I'll have a crack at it.  At the risk of provoking the Wrath of  
Stallman[*], my brand new 5-day old daughter can spoil the  
concentration somewhat :-)

 > (Don't forget tests!)`

Testing is my middle name ! :-)

A.
[*] http://edward.oconnor.cx/2005/04/rms
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/



From drbrain at segment7.net  Sun Sep 23 04:37:58 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sun, 23 Sep 2007 01:37:58 -0700
Subject: [Rubygems-developers] SourceInfoCache.search (Eric Hodel)
In-Reply-To: <78CB41D1-03E6-4337-81CC-CDACEBBB1372@twelve71.com>
References: <mailman.55.1190454348.10750.rubygems-developers@rubyforge.org>
	<78CB41D1-03E6-4337-81CC-CDACEBBB1372@twelve71.com>
Message-ID: <4FDE03B6-15ED-452F-91CD-07506F612E86@segment7.net>

On Sep 22, 2007, at 23:09, Alan C Francis wrote:
> On 22 Sep 2007, at 10:45, rubygems-developers-request at rubyforge.org
> wrote:
>> I think I would like:
>>
>> If Gem.configuration.update_sources is true (default) the source
>> cache will be updated automatically.
>
> Do you mean for the search (my original request) or for all commands
> where the cache is update (eg install)

I was thinking for all commands, having it baked right in to  
Gem::SourceInfoCache.

I don't forsee a problem with going the all commands route, with  
update_sources set to false, RubyGems would work like macports, which  
requires a `port update` to get the latest.

>> You should then be able to override the user's
>> Gem.configuration.update_sources value for your purposes.
>>
>> I don't have time to write it.  Could you write up a patch and put it
>> in the tracker?
>
> I'll have a crack at it.  At the risk of provoking the Wrath of
> Stallman[*], my brand new 5-day old daughter can spoil the
> concentration somewhat :-)

There should be enough tests in there to make it a 1-2 hour job.   
You'll need to look at Gem::SourceInfoCache and Gem::ConfigFile.

> [*] http://edward.oconnor.cx/2005/04/rms

LOL!  FWIW, I'm with Nick, take your time.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From hgs at dmu.ac.uk  Mon Sep 24 04:21:08 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Mon, 24 Sep 2007 09:21:08 +0100 (WEST)
Subject: [Rubygems-developers] Source caches again.
In-Reply-To: <C4BC96A1-7FF8-4E18-9008-7744C559482B@segment7.net>
References: <Pine.GSO.4.64.0708221424240.12350@brains.eng.cse.dmu.ac.uk>
	<1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>
	<Pine.GSO.4.64.0708241144550.261@brains.eng.cse.dmu.ac.uk>
	<EC20F6A1-2133-4AB3-943B-DC3B8ACC0C33@zenspider.com>
	<Pine.GSO.4.64.0708281027050.261@brains.eng.cse.dmu.ac.uk>
	<CA6C6513-A5C5-4645-9FED-9D67CDB29823@zenspider.com>
	<Pine.GSO.4.64.0708291006090.22900@brains.eng.cse.dmu.ac.uk>
	<b37300880708290715h17130d29r7768eab9c500439@mail.gmail.com>
	<Pine.GSO.4.64.0708291624550.22900@brains.eng.cse.dmu.ac.uk>
	<Pine.GSO.4.64.0708291831270.22900@brains.eng.cse.dmu.ac.uk>
	<7B8E9770-133D-4D59-95D8-88CA423B0949@segment7.net>
	<Pine.GSO.4.64.0709210939270.20822@brains.eng.cse.dmu.ac.uk>
	<C4BC96A1-7FF8-4E18-9008-7744C559482B@segment7.net>
Message-ID: <Pine.GSO.4.64.0709240916490.13494@brains.eng.cse.dmu.ac.uk>

On Sat, 22 Sep 2007, Eric Hodel wrote:

> On Sep 21, 2007, at 01:51, Hugh Sasse wrote:
> > On Thu, 20 Sep 2007, Eric Hodel wrote:
> >> On Aug 29, 2007, at 10:38, Hugh Sasse wrote:
> >>> On Wed, 29 Aug 2007, I wrote:
> >>> --- rubygems-0.9.4/lib/rubygems/commands/
> >>> clear_cache_command.rb.orig	2007-08-29 18:22:58.049867000 +0100
> >>> +++ rubygems-0.9.4/lib/rubygems/commands/clear_cache_command.rb	
> >>
> >> I don't understand this part.  How is this different from `gem
> >> sources -c`?
> >
> > I needed a way to put in a command name that reflected the semantics
> > of "clear the cache".  As far as I could see your commands are defined
        [...]
> > it was the sources as such.  So "clear the cache" which people mention
> > didn't lead me to look at the source command. Therefore I thought  
> > people
> > would look for a separate command.
> 
> Is a change in documentation sufficient?  The sources command's  
> description now reads:
> 
> $ gem help commands | grep -A1 sources
>      sources           Manage the sources and cache file RubyGems  
> uses to search
>                        for gems

Yes, I expect people will (?:visually)? grep the help for /cache/
so in most cases this will suffice.  If there were a way to alias
commands, I'd recommend that as well, but duplication of code is
best avoided, so I'd concede the lack of a clear_cache command.
> 
> Also, the way the source cache works has been changed since the last  
> release.  When --source (for install, etc) is given, only the sources  
> listed on the command line are used.  To add extra sources  
> permanently you must run `gem sources --add`.

OK, I'll have to have a look at that. Thanks for pointing it out.
> 
        Thank you,
        Hugh

From thewoolleyman at gmail.com  Mon Sep 24 05:03:53 2007
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 24 Sep 2007 02:03:53 -0700
Subject: [Rubygems-developers] SourceInfoCache.search (Eric Hodel)
In-Reply-To: <4FDE03B6-15ED-452F-91CD-07506F612E86@segment7.net>
References: <mailman.55.1190454348.10750.rubygems-developers@rubyforge.org>
	<78CB41D1-03E6-4337-81CC-CDACEBBB1372@twelve71.com>
	<4FDE03B6-15ED-452F-91CD-07506F612E86@segment7.net>
Message-ID: <e3af97510709240203s22735f68gf211cace12b7ee11@mail.gmail.com>

On 9/23/07, Eric Hodel <drbrain at segment7.net> wrote:
> On Sep 22, 2007, at 23:09, Alan C Francis wrote:
> >> I don't have time to write it.  Could you write up a patch and put it
> >> in the tracker?
> >
> > I'll have a crack at it.  At the risk of provoking the Wrath of
> > Stallman[*], my brand new 5-day old daughter can spoil the
> > concentration somewhat :-)
> >
> > [*] http://edward.oconnor.cx/2005/04/rms
>
> LOL!  FWIW, I'm with Nick, take your time.

That's crazy.  I've never been THAT big of a jerk on a mailing list.
At least I don't think so...

>From a fellow conscienceless procreator: don't worry - you'll still
have some time to hack.  A little.  Even if it's coding 'til you pass
out in the la-z-boy after you've outlasted the little rugrat.  There's
even benefits - it's easier to make excuses for dumb bugs.

Congrats, Alan :)

-- Chad W.

From listsub at twelve71.com  Mon Sep 24 12:30:41 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Mon, 24 Sep 2007 17:30:41 +0100
Subject: [Rubygems-developers] test_gem_config_file.rb
In-Reply-To: <mailman.55.1190454348.10750.rubygems-developers@rubyforge.org>
References: <mailman.55.1190454348.10750.rubygems-developers@rubyforge.org>
Message-ID: <72F5C9CD-CA38-4ADE-B3BD-A53FCAD17921@twelve71.com>

>
> If Gem.configuration.update_sources is true (default) the source
> cache will be updated automatically.


Hi,

Can anyone help me out with the test_write and test_write_from_hash  
methods in this file ?

They *look* like what they're doing is setting up a bunch of stuff,  
calling write, then using util_config_file() to load the written file  
back in and then make assertions...however:

1) test_write does the write then calls util_config_file and asserts  
that all values are back to default.

2) test_write_from_hash creates a config file, loads(using  
util_config_file), overwrites values with junk, writes (to  
overwrite?), reloads again then makes a bunch of assertions which  
vary from defaults, original filewrite, and the 'junk' values (in the  
case of sources).

I'd appreciate a wee bit of description on what the behaviour is  
these tests are testing ?

Any help gratefully appreciated :-)

A.
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/

From listsub at twelve71.com  Wed Sep 26 06:28:14 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Wed, 26 Sep 2007 11:28:14 +0100
Subject: [Rubygems-developers] Patch added.
Message-ID: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>

http://rubyforge.org/tracker/index.php? 
func=detail&aid=14246&group_id=126&atid=577

Criticism *very much* welcomed.  I'm sure I haven't got it right.   
Also, tests for config_file are still confusing me a little.  See  
#ACF comments in the file.

A.
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/




From transfire at gmail.com  Wed Sep 26 11:49:50 2007
From: transfire at gmail.com (TRANS)
Date: Wed, 26 Sep 2007 11:49:50 -0400
Subject: [Rubygems-developers] Windows Error
Message-ID: <4b6f054f0709260849u73dc2c8ehd66504131607d14d@mail.gmail.com>

On a Windows system, after installing the One-Click Installer, I tried:

  gem install rubyscript2exe

For that I got a "getaddrinfo: no address associated with
hostname.(SocketError)"

So I added --no-http-proxy option, and got "underfined method '[]='
for #<Gem::ConfigFile:0x2df7864>"

Would upgrading to 0.9.4 help? But I would have to install manually
because 'gem update  --system' gives the same error.

T.

From ryand-ruby at zenspider.com  Wed Sep 26 19:51:57 2007
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Wed, 26 Sep 2007 16:51:57 -0700
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
Message-ID: <7D9B4974-419E-4E36-9D4F-9EAFC7F5E748@zenspider.com>


On Sep 26, 2007, at 03:28 , Alan C Francis wrote:

> http://rubyforge.org/tracker/index.php?
> func=detail&aid=14246&group_id=126&atid=577
>
> Criticism *very much* welcomed.  I'm sure I haven't got it right.
> Also, tests for config_file are still confusing me a little.  See
> #ACF comments in the file.

not attached...

I should ask tom to remove that stupid checkbox...


From listsub at twelve71.com  Thu Sep 27 02:30:43 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Thu, 27 Sep 2007 07:30:43 +0100
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <7D9B4974-419E-4E36-9D4F-9EAFC7F5E748@zenspider.com>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
	<7D9B4974-419E-4E36-9D4F-9EAFC7F5E748@zenspider.com>
Message-ID: <78DA0ED8-7F49-45DB-8D23-A9BC695B0408@twelve71.com>

Done now.  oops.

A.
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/



On 27 Sep 2007, at 00:51, Ryan Davis wrote:

>
> not attached...
>
> I should ask tom to remove that stupid checkbox...


From drbrain at segment7.net  Thu Sep 27 03:12:30 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 27 Sep 2007 00:12:30 -0700
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
Message-ID: <2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net>

On Sep 26, 2007, at 03:28 , Alan C Francis wrote:

> http://rubyforge.org/tracker/index.php?
> func=detail&aid=14246&group_id=126&atid=577
>
> Criticism *very much* welcomed.  I'm sure I haven't got it right.

--update_sources should be --update-sources, since every other  
program I've seen uses dashes in command-line options.

I think the --update-sources option should be added to  
local_remote_options.rb instead of config_file.rb, it doesn't need to  
be active for every command, just the ones doing the remote stuff.   
It'll also be documented in local_remote_command.rb.  (I should have  
let you know.)

If you don't get these changes made tomorrow, I probably will.  I  
think its beta time after this patch goes in.

> Also, tests for config_file are still confusing me a little.  See
> #ACF comments in the file.

Some things should be written out when changed on the command line,  
other things shouldn't.  The tests there make sure the unchanged  
things remain unchanged, and the change things get changed.

From listsub at twelve71.com  Thu Sep 27 04:25:58 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Thu, 27 Sep 2007 09:25:58 +0100
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
	<2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net>
Message-ID: <223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com>

Hi Eric, I'll try and finish it tonight.  Would be nice to see it all  
the way through :-)

Is there a way to sandbox the gems installation so I can really try  
it out without losing my 'site_ruby' gems installation ?

A.
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/



On 27 Sep 2007, at 08:12, Eric Hodel wrote:

> On Sep 26, 2007, at 03:28 , Alan C Francis wrote:
>
>> http://rubyforge.org/tracker/index.php?
>> func=detail&aid=14246&group_id=126&atid=577
>>
>> Criticism *very much* welcomed.  I'm sure I haven't got it right.
>
> --update_sources should be --update-sources, since every other
> program I've seen uses dashes in command-line options.
>
> I think the --update-sources option should be added to
> local_remote_options.rb instead of config_file.rb, it doesn't need to
> be active for every command, just the ones doing the remote stuff.
> It'll also be documented in local_remote_command.rb.  (I should have
> let you know.)
>
> If you don't get these changes made tomorrow, I probably will.  I
> think its beta time after this patch goes in.
>
>> Also, tests for config_file are still confusing me a little.  See
>> #ACF comments in the file.
>
> Some things should be written out when changed on the command line,
> other things shouldn't.  The tests there make sure the unchanged
> things remain unchanged, and the change things get changed.
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From drbrain at segment7.net  Thu Sep 27 12:02:12 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 27 Sep 2007 09:02:12 -0700
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
	<2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net>
	<223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com>
Message-ID: <B0B36497-EE48-4900-947E-4C1B818EF93F@segment7.net>

On Sep 27, 2007, at 01:25 , Alan C Francis wrote:
> Hi Eric, I'll try and finish it tonight.  Would be nice to see it all
> the way through :-)
>
> Is there a way to sandbox the gems installation so I can really try
> it out without losing my 'site_ruby' gems installation ?

I use:

ruby -Ilib bin/gem command options

from the checkout to run the gem command, and explicitly provide the  
path to checkout/lib when testing interoperation between libraries.

From luislavena at gmail.com  Thu Sep 27 21:39:30 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 27 Sep 2007 22:39:30 -0300
Subject: [Rubygems-developers] Questions about Gem Platform Matching
Message-ID: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>

Hello guys,

After reading Eric's post about the new Gem Platform Matching in
trunk... I have done some testing now that my sandbox is full of
rubies:

$ ruby -v ~/Desktop/platform.rb
ruby 1.8.6 (2007-09-23 patchlevel 110) [i386-mingw32]
Your cpu is:   "i386"
Your os is:    "mingw32"
Your platform is: "x86-mingw32"

ruby 1.8.5 (2006-12-25 patchlevel 12) [i386-mswin32]
Your cpu is:   "i386"
Your os is:    "mswin32"
Your platform is: "x86-mswin32"

ruby 1.8.6 (2007-09-23 patchlevel 110) [i386-mswin32_80]
Your cpu is:   "i386"
Your os is:    "mswin32_80"
Your platform is: "x86-mswin32"

ruby 1.9.0 (2007-09-27 patchlevel 0) [i386-mswin32_80]
Your cpu is:   "i386"
Your os is:    "mswin32_80"
Your platform is: "x86-mswin32"


I don't know if the problem is noticeable, but I'll bold it:

All the builds with MS tools states "x86-mswin32"... but both use
different compilers: mswin32 are build with VC6 (the official build)
and the mswin32_80 is with latest VS2005 compiler (VC8).

both compilers links against different runtime libraries (msvcrt.dll
and msvcr80.dll respectively).

Also, the extensions compiled will not find the ruby18 shared library
(msvcrt-ruby18.dll and msvcr80-ruby18.dll).

So... that will not work and produce broken gems and a lot of traffic
about "hey, tried to install this and it's broken!).

Should the version for mswin32 (current nil) be used for this case?

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From drbrain at segment7.net  Fri Sep 28 04:46:14 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Fri, 28 Sep 2007 01:46:14 -0700
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
Message-ID: <ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>

On Sep 27, 2007, at 18:39 , Luis Lavena wrote:
> Hello guys,
>
> After reading Eric's post about the new Gem Platform Matching in
> trunk... I have done some testing now that my sandbox is full of
> rubies:
>
> $ ruby -v ~/Desktop/platform.rb
> ruby 1.8.6 (2007-09-23 patchlevel 110) [i386-mingw32]
> Your cpu is:   "i386"
> Your os is:    "mingw32"
> Your platform is: "x86-mingw32"
>
> ruby 1.8.5 (2006-12-25 patchlevel 12) [i386-mswin32]
> Your cpu is:   "i386"
> Your os is:    "mswin32"
> Your platform is: "x86-mswin32"
>
> ruby 1.8.6 (2007-09-23 patchlevel 110) [i386-mswin32_80]
> Your cpu is:   "i386"
> Your os is:    "mswin32_80"
> Your platform is: "x86-mswin32"
>
> ruby 1.9.0 (2007-09-27 patchlevel 0) [i386-mswin32_80]
> Your cpu is:   "i386"
> Your os is:    "mswin32_80"
> Your platform is: "x86-mswin32"
>
>
> I don't know if the problem is noticeable, but I'll bold it:
>
> All the builds with MS tools states "x86-mswin32"... but both use
> different compilers: mswin32 are build with VC6 (the official build)
> and the mswin32_80 is with latest VS2005 compiler (VC8).
>
> both compilers links against different runtime libraries (msvcrt.dll
> and msvcr80.dll respectively).
>
> Also, the extensions compiled will not find the ruby18 shared library
> (msvcrt-ruby18.dll and msvcr80-ruby18.dll).
>
> So... that will not work and produce broken gems and a lot of traffic
> about "hey, tried to install this and it's broken!).
>
> Should the version for mswin32 (current nil) be used for this case?

Probably.  Is there a way to get the value out of Config::CONFIG?

I think people expect an x86-mswin32 platform gem to work with  
whatever the latest one-click installer is.  RubyGems also provides a  
required_ruby_version check, so you can lock it down to a particular  
ruby one-click version.

From drbrain at segment7.net  Fri Sep 28 12:26:45 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Fri, 28 Sep 2007 09:26:45 -0700
Subject: [Rubygems-developers] New setup.rb
Message-ID: <B30B289C-E958-41DE-AF70-31984B87918A@segment7.net>

I replaced the giant setup.rb with a small one we can easily debug.   
It seems to fix all the issues people have been having.

Please test it out on windows, I do not have one of those set up for  
development.

It also comes with --no-rdoc and --no-ri, and the gem updater has  
been hooked into those options (and --prefix).  I still need to set  
up and test updating through `gem update --system`, its a bit more work.

What's not well-documented is the difference between --prefix and  
GEM_HOME, defining both to be the same is certainly not what people  
want.  (This is true with all versions of RubyGems.)

From Daniel.Berger at qwest.com  Fri Sep 28 13:04:40 2007
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Fri, 28 Sep 2007 12:04:40 -0500
Subject: [Rubygems-developers] New setup.rb
In-Reply-To: <B30B289C-E958-41DE-AF70-31984B87918A@segment7.net>
Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E41@ITOMAE2KM01.AD.QINTRA.COM>

> -----Original Message-----
> From: rubygems-developers-bounces at rubyforge.org 
> [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf 
> Of Eric Hodel
> Sent: Friday, September 28, 2007 10:27 AM
> To: rubygems-developers at rubyforge.org
> Subject: [Rubygems-developers] New setup.rb
> 
> 
> I replaced the giant setup.rb with a small one we can easily debug.   
> It seems to fix all the issues people have been having.
> 
> Please test it out on windows, I do not have one of those set up for  
> development.
> 
> It also comes with --no-rdoc and --no-ri, and the gem updater has  
> been hooked into those options (and --prefix).  I still need to set  
> up and test updating through `gem update --system`, its a bit 
> more work.
> 
> What's not well-documented is the difference between --prefix and  
> GEM_HOME, defining both to be the same is certainly not what people  
> want.  (This is true with all versions of RubyGems.) 

Assuming setup.rb has its own tests in the test suite somewhere, here's
the latest results (Ruby 1.8.6 one click, rake 0.7.3, Windows XP Pro SP
2).

Failures 5-9 look easy enough. I'm not sure what's happening with 1-4
yet, though.

And, if setup.rb does NOT have separate tests, how/what would you like
me to test?

C:\Documents and Settings\djberge\workspace\rubygems>rake test
(in C:/Documents and Settings/djberge/workspace/rubygems)
./test/test_gem_specification.rb:478: warning: ambiguous first argument;
put parentheses or even spaces
./test/test_gem_specification.rb:487: warning: ambiguous first argument;
put parentheses or even spaces
Loaded suite
C:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake/rake_test_loader
Started
..........................................................C:/ruby/lib/ru
by/1.8/openssl/x509.rb:24: warning: instance var
iable @config not initialized
C:/ruby/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable
@config not initialized
C:/ruby/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable
@config not initialized
...............................C:/ruby/lib/ruby/1.8/rdoc/parsers/parse_c
.rb:204: warning: method redefined; discarding o
ld progress
..EWARNING:  Unable to use symlinks on win32, installing wrapper
.WARNING:  Unable to use symlinks on win32, installing wrapper
.WARNING:  Unable to use symlinks on win32, installing wrapper
..............................................WARNING:  Unable to use
symlinks on win32, installing wrapper
............WARNING:  Unable to use symlinks on win32, installing
wrapper
......................................EEE....F..........................
......FFF........................F..............
........................................................................
................................................
........................................................................
...........
Finished in 102.587 seconds.

  1) Error:
test_execute(TestGemCommandsMirrorCommand):
RuntimeError: Compressed file
C:/DOCUME~1/djberge/LOCALS~1/Temp/gem_generate_index_3976/Marshal.Z does
not match uncompr
essed file
C:/DOCUME~1/djberge/LOCALS~1/Temp/gem_generate_index_3976/Marshal
    ./lib/rubygems/indexer/master_index_builder.rb:40:in `paranoid'
    ./lib/rubygems/indexer/master_index_builder.rb:24:in `cleanup'
    ./lib/rubygems/indexer/abstract_index_builder.rb:42:in `build'
    ./lib/rubygems/indexer.rb:47:in `build_index'
    ./lib/rubygems/indexer/abstract_index_builder.rb:39:in `build'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `open'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `build'
    ./lib/rubygems/indexer.rb:46:in `build_index'
    ./lib/rubygems/indexer/abstract_index_builder.rb:39:in `build'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `open'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `build'
    ./lib/rubygems/indexer.rb:45:in `build_index'
    ./lib/rubygems/indexer.rb:105:in `generate_index'
    ./test/test_gem_commands_mirror_command.rb:28:in `test_execute'
    ./lib/rubygems/user_interaction.rb:45:in `use_ui'
    ./lib/rubygems/user_interaction.rb:27:in `use_ui'
    ./test/test_gem_commands_mirror_command.rb:27:in `test_execute'

  2) Error:
test_generate_index(TestGemIndexer):
RuntimeError: Compressed file
C:/DOCUME~1/djberge/LOCALS~1/Temp/gem_generate_index_3976/Marshal.Z does
not match uncompr
essed file
C:/DOCUME~1/djberge/LOCALS~1/Temp/gem_generate_index_3976/Marshal
    ./lib/rubygems/indexer/master_index_builder.rb:40:in `paranoid'
    ./lib/rubygems/indexer/master_index_builder.rb:24:in `cleanup'
    ./lib/rubygems/indexer/abstract_index_builder.rb:42:in `build'
    ./lib/rubygems/indexer.rb:47:in `build_index'
    ./lib/rubygems/indexer/abstract_index_builder.rb:39:in `build'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `open'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `build'
    ./lib/rubygems/indexer.rb:46:in `build_index'
    ./lib/rubygems/indexer/abstract_index_builder.rb:39:in `build'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `open'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `build'
    ./lib/rubygems/indexer.rb:45:in `build_index'
    ./lib/rubygems/indexer.rb:105:in `generate_index'
    ./test/test_gem_indexer.rb:34:in `test_generate_index'
    ./lib/rubygems/user_interaction.rb:45:in `use_ui'
    ./lib/rubygems/user_interaction.rb:27:in `use_ui'
    ./test/test_gem_indexer.rb:33:in `test_generate_index'

  3) Error:
test_generate_index_contents(TestGemIndexer):
RuntimeError: Compressed file
C:/DOCUME~1/djberge/LOCALS~1/Temp/gem_generate_index_3976/Marshal.Z does
not match uncompr
essed file
C:/DOCUME~1/djberge/LOCALS~1/Temp/gem_generate_index_3976/Marshal
    ./lib/rubygems/indexer/master_index_builder.rb:40:in `paranoid'
    ./lib/rubygems/indexer/master_index_builder.rb:24:in `cleanup'
    ./lib/rubygems/indexer/abstract_index_builder.rb:42:in `build'
    ./lib/rubygems/indexer.rb:47:in `build_index'
    ./lib/rubygems/indexer/abstract_index_builder.rb:39:in `build'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `open'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `build'
    ./lib/rubygems/indexer.rb:46:in `build_index'
    ./lib/rubygems/indexer/abstract_index_builder.rb:39:in `build'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `open'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `build'
    ./lib/rubygems/indexer.rb:45:in `build_index'
    ./lib/rubygems/indexer.rb:105:in `generate_index'
    ./test/test_gem_indexer.rb:72:in `test_generate_index_contents'
    ./lib/rubygems/user_interaction.rb:45:in `use_ui'
    ./lib/rubygems/user_interaction.rb:27:in `use_ui'
    ./test/test_gem_indexer.rb:71:in `test_generate_index_contents'

  4) Error:
test_generate_index_ui(TestGemIndexer):
RuntimeError: Compressed file
C:/DOCUME~1/djberge/LOCALS~1/Temp/gem_generate_index_3976/Marshal.Z does
not match uncompr
essed file
C:/DOCUME~1/djberge/LOCALS~1/Temp/gem_generate_index_3976/Marshal
    ./lib/rubygems/indexer/master_index_builder.rb:40:in `paranoid'
    ./lib/rubygems/indexer/master_index_builder.rb:24:in `cleanup'
    ./lib/rubygems/indexer/abstract_index_builder.rb:42:in `build'
    ./lib/rubygems/indexer.rb:47:in `build_index'
    ./lib/rubygems/indexer/abstract_index_builder.rb:39:in `build'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `open'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `build'
    ./lib/rubygems/indexer.rb:46:in `build_index'
    ./lib/rubygems/indexer/abstract_index_builder.rb:39:in `build'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `open'
    ./lib/rubygems/indexer/abstract_index_builder.rb:36:in `build'
    ./lib/rubygems/indexer.rb:45:in `build_index'
    ./lib/rubygems/indexer.rb:105:in `generate_index'
    ./test/test_gem_indexer.rb:57:in `test_generate_index_ui'
    ./lib/rubygems/user_interaction.rb:45:in `use_ui'
    ./lib/rubygems/user_interaction.rb:27:in `use_ui'
    ./test/test_gem_indexer.rb:56:in `test_generate_index_ui'

  5) Failure:
test_app_script_text(TestGemInstaller)
[./test/test_gem_installer.rb:91]:
<"#!C:/ruby/bin/ruby\n#\n# This file was generated by RubyGems.\n#\n#
The application 'a' is installed as part of a gem,
 and\n# this file is here to facilitate running it.\n#\n\nrequire
'rubygems'\n\nversion = \">= 0\"\n\nif ARGV.first =~ /
^_(.*)_$/ and Gem::Version.correct? $1 then\n  version = $1\n
ARGV.shift\nend\n\ngem 'a', version\nload 'my_exec'\n"> e
xpected but was
<"#!C:/ruby/bin/ruby.exe\n#\n# This file was generated by
RubyGems.\n#\n# The application 'a' is installed as part of a
gem, and\n# this file is here to facilitate running it.\n#\n\nrequire
'rubygems'\n\nversion = \">= 0\"\n\nif ARGV.first
=~ /^_(.*)_$/ and Gem::Version.correct? $1 then\n  version = $1\n
ARGV.shift\nend\n\ngem 'a', version\nload 'my_exec'\n
">.

  6) Failure:
test_shebang(TestGemInstaller) [./test/test_gem_installer.rb:645]:
<"#!C:/ruby/bin/ruby"> expected but was
<"#!C:/ruby/bin/ruby.exe">.

  7) Failure:
test_shebang_arguments(TestGemInstaller)
[./test/test_gem_installer.rb:653]:
<"#!C:/ruby/bin/ruby -ws"> expected but was
<"#!C:/ruby/bin/ruby.exe -ws">.

  8) Failure:
test_shebang_empty(TestGemInstaller) [./test/test_gem_installer.rb:660]:
<"#!C:/ruby/bin/ruby"> expected but was
<"#!C:/ruby/bin/ruby.exe">.

  9) Failure:
test_fetch_path_system_call_error(TestGemRemoteFetcher)
[./test/test_gem_remote_fetcher.rb:257]:
<"Errno::ECONNREFUSED: Connection refused - connect(2) reading uri">
expected but was
<"Errno::ECONNREFUSED: No connection could be made because the target
machine actively refused it. - connect(2) reading
uri">.

475 tests, 1580 assertions, 5 failures, 4 errors

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

From luislavena at gmail.com  Fri Sep 28 15:12:32 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Sep 2007 16:12:32 -0300
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
	<ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
Message-ID: <71166b3b0709281212t766fb5c7kd7005447ff164400@mail.gmail.com>

On 9/28/07, Eric Hodel <drbrain at segment7.net> wrote:
>
> Probably.  Is there a way to get the value out of Config::CONFIG?
>
> I think people expect an x86-mswin32 platform gem to work with
> whatever the latest one-click installer is.  RubyGems also provides a
> required_ruby_version check, so you can lock it down to a particular
> ruby one-click version.

The problem is this:

OCI uses official VC6 builds, which is old (sometimes gets a bit
before stable patchlevels gets build for mswin32).

Anyway, the use of VC6 will vanish with ruby 1.9, and that could
present a problem.

Manually build ruby with free compiler from microsoft (VC8) produces
msvcr80-ruby18.dll as shared library of ruby.

Now, using 'gem' I install Mongrel, and manually choose mswin32 as
platform, but the extension is linked against msvcrt-ruby18.dll, which
don't exist. Result: not working mongrel and lots of reports on
rubyforge.

Next version of RubyGems will choose platform automatically and
"correctly", and that level of intelligence will make this more
problematic what is really is now.

Also, last but no least, the dependencies of runtimes (msvcrt vs
msvcr80) sharing the same memory could bring some issues -- besides
having two different runtimes for the same task loaded in memory.

I took the platform.rb example you posted in your blog to collect these details.

Official build of ruby states as OS: "mswin32"
Builds made with VC8: "mswin32_80"

Maybe we could take the "80" from mswin32 and append to the end: x86-mswin32-80.

Also, was a lot of discusion in ruby-talk about the next OCI and if
will be MinGW or VC2005 based... and never heard from Curt again.

Or continue being using VC6... which is slow.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From luislavena at gmail.com  Fri Sep 28 15:14:23 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Sep 2007 16:14:23 -0300
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
	<ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
Message-ID: <71166b3b0709281214j51b5279bm18b1cb70ac8f43a@mail.gmail.com>

On 9/28/07, Eric Hodel <drbrain at segment7.net> wrote:
>
> I think people expect an x86-mswin32 platform gem to work with
> whatever the latest one-click installer is.  RubyGems also provides a
> required_ruby_version check, so you can lock it down to a particular
> ruby one-click version.

Forgot to mention: what I'm raising here is not a problem with
required_ruby_version, I made example of different builds of ruby,
version number wasn't the problem, wanted to show the different
reports of OS and the build platform.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From luislavena at gmail.com  Fri Sep 28 15:22:15 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Sep 2007 16:22:15 -0300
Subject: [Rubygems-developers] New setup.rb
In-Reply-To: <B30B289C-E958-41DE-AF70-31984B87918A@segment7.net>
References: <B30B289C-E958-41DE-AF70-31984B87918A@segment7.net>
Message-ID: <71166b3b0709281222o6f77e57gc1cfe435bc965c7f@mail.gmail.com>

On 9/28/07, Eric Hodel <drbrain at segment7.net> wrote:
> I replaced the giant setup.rb with a small one we can easily debug.
> It seems to fix all the issues people have been having.
>
> Please test it out on windows, I do not have one of those set up for
> development.
>
> It also comes with --no-rdoc and --no-ri, and the gem updater has
> been hooked into those options (and --prefix).  I still need to set
> up and test updating through `gem update --system`, its a bit more work.
>
> What's not well-documented is the difference between --prefix and
> GEM_HOME, defining both to be the same is certainly not what people
> want.  (This is true with all versions of RubyGems.)

I'll do a round of testing later today when I return to office (also
to report the exact Config::CONFIG you asked).

Ruby 1.8.6 VC6 and MinGW will be the targets.

Also 1.9.0 MinGW, just for testing ;-)

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From drbrain at segment7.net  Fri Sep 28 16:43:20 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Fri, 28 Sep 2007 13:43:20 -0700
Subject: [Rubygems-developers] New setup.rb
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72E41@ITOMAE2KM01.AD.QINTRA.COM>
References: <7524A45A1A5B264FA4809E2156496CFBE72E41@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <B132617E-D1BC-46FA-991D-9EDDB119610C@segment7.net>

On Sep 28, 2007, at 10:04 , Berger, Daniel wrote:
>> I replaced the giant setup.rb with a small one we can easily debug.
>> It seems to fix all the issues people have been having.
>>
>> Please test it out on windows, I do not have one of those set up for
>> development.
>>
>> It also comes with --no-rdoc and --no-ri, and the gem updater has
>> been hooked into those options (and --prefix).  I still need to set
>> up and test updating through `gem update --system`, its a bit
>> more work.
>>
>> What's not well-documented is the difference between --prefix and
>> GEM_HOME, defining both to be the same is certainly not what people
>> want.  (This is true with all versions of RubyGems.)
>
> Assuming setup.rb has its own tests in the test suite somewhere,  
> here's
> the latest results (Ruby 1.8.6 one click, rake 0.7.3, Windows XP  
> Pro SP
> 2).

It doesn't, most of it is post-install.rb and pre-install.rb.  The  
bit in the middle is so stupid-simple that it shouldn't need tests  
(ha! yeah, I know...).

> Failures 5-9 look easy enough. I'm not sure what's happening with 1-4
> yet, though.

Probably missing 'b' flags.

> And, if setup.rb does NOT have separate tests, how/what would you like
> me to test?

Its the setup.rb that installs rubygems.

ruby setup.rb --prefix /some/test/path

Also, you can pass --no-rdoc and --no-ri and not build rdoc or ri  
respectively.

and you should be able to

ruby -I /some/test/path/lib /some/test/path/bin/gem env

There should also be gem.cmd file in /some/test/path/bin/ that works  
on windows.

> C:\Documents and Settings\djberge\workspace\rubygems>rake test
> (in C:/Documents and Settings/djberge/workspace/rubygems)
> ./test/test_gem_specification.rb:478: warning: ambiguous first  
> argument;
> put parentheses or even spaces
> ./test/test_gem_specification.rb:487: warning: ambiguous first  
> argument;
> put parentheses or even spaces

Fixed these guys

> Loaded suite
> C:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake/rake_test_loader
> Started
> Finished in 102.587 seconds.
>
>   1) Error:
> test_execute(TestGemCommandsMirrorCommand):
>
>   2) Error:
> test_generate_index(TestGemIndexer):
>
>   3) Error:
> test_generate_index_contents(TestGemIndexer):
>
>   4) Error:
> test_generate_index_ui(TestGemIndexer):

I flushed out a few more opens that were missing 'b's, but I don't  
know if that did it.

>   5) Failure:
> test_app_script_text(TestGemInstaller)
> [./test/test_gem_installer.rb:91]:
>
>   6) Failure:
> test_shebang(TestGemInstaller) [./test/test_gem_installer.rb:645]:
>
>   7) Failure:
> test_shebang_arguments(TestGemInstaller)
> [./test/test_gem_installer.rb:653]:
>
>   8) Failure:
> test_shebang_empty(TestGemInstaller) [./test/test_gem_installer.rb: 
> 660]:

Fixed all these that were missing the ".exe".

>   9) Failure:
> test_fetch_path_system_call_error(TestGemRemoteFetcher)
> [./test/test_gem_remote_fetcher.rb:257]:
> <"Errno::ECONNREFUSED: Connection refused - connect(2) reading uri">
> expected but was
> <"Errno::ECONNREFUSED: No connection could be made because the target
> machine actively refused it. - connect(2) reading
> uri">.

Bleh.  Fixed.

Thanks for testing!

From luislavena at gmail.com  Fri Sep 28 19:40:18 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Sep 2007 20:40:18 -0300
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
	<ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
Message-ID: <71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com>

On 9/28/07, Eric Hodel <drbrain at segment7.net> wrote:
> On Sep 27, 2007, at 18:39 , Luis Lavena wrote:
> >
> > Should the version for mswin32 (current nil) be used for this case?
>
> Probably.  Is there a way to get the value out of Config::CONFIG?
>

# Ruby built with VC6 (official) 1.8.6-p110
irb(main):005:0> Config::CONFIG['arch']
=> "i386-mswin32"

Config::CONFIG['LIBRUBY_SO']
=> "msvcrt-ruby18.dll"

# Ruby built with VC8 (which is supported) 1.8.6-p110
irb(main):004:0> Config::CONFIG['arch']
=> "i386-mswin32_80"

Config::CONFIG['LIBRUBY_SO']
=> "msvcr80-ruby18.dll"

===

As you can see, both libruby are different, so this could raise the
problem I stated about gems build with VC6 and using ruby build with
VC8...

Using the matcher found in your article about Lazyweb ;-)
http://blog.segment7.net/articles/2007/08/20/dear-lazyweb-gem-platforms

I gather this information:

ruby 1.8.6 (2007-09-23 patchlevel 110) [i386-mswin32]
Your cpu is:   "i386"
Your os is:    "mswin32"
Your platform is: "x86-mswin32"

ruby 1.8.6 (2007-09-23 patchlevel 110) [i386-mswin32_80]
Your cpu is:   "i386"
Your os is:    "mswin32_80"
Your platform is: "x86-mswin32"

The OS defines which version of runtime is needed/used.

Changing the case line:

  when /mswin32(\_(\d+))?/ then    [ 'mswin32',   $2  ]

Works around the problem.

Also, to be noted:

Gem::Platform.local will report 'i386-mswin32_80' since is what
Config::CONFIG['arch'] have for ruby build with VC8... and that
differs from VC6...

I'm working on a patch and checking the tests cases.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From luislavena at gmail.com  Fri Sep 28 20:22:15 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Sep 2007 21:22:15 -0300
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
	<ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
	<71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com>
Message-ID: <71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com>

On 9/28/07, Luis Lavena <luislavena at gmail.com> wrote:
>
> I'm working on a patch and checking the tests cases.
>

Pointless... it seems that on different platforms (darwin as example)
compile something in darwin will be compatible with darwin8, but not
darwin7 or 9 (as test_gem_platform.rb assert).

http://pastie.caboo.se/101899

I know that is wrong... apply the changes I made bomb the darwin plaform.

But on windows, VC6 and VC8 aren't compatible builds, neither the
linking to msvcrt-ruby18 and msvcr80-ruby18...

So installing gems made with Gem::Platform.local 'i386-mswin32' will
not work under Gem::Platform.local == 'i386-mswin32_80' ...due the
missing shared library.

Guess until users face the problem and start closing tickets at
rubyforge will be some general acknowledge about it.

What the hell... just ignore me.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From drbrain at segment7.net  Sat Sep 29 18:12:25 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 29 Sep 2007 15:12:25 -0700
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
	<ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
	<71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com>
	<71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com>
Message-ID: <B1A36693-2447-40EF-9424-BF4A13F83CB0@segment7.net>

On Sep 28, 2007, at 17:22, Luis Lavena wrote:
> On 9/28/07, Luis Lavena <luislavena at gmail.com> wrote:
>> I'm working on a patch and checking the tests cases.
>
> Pointless... it seems that on different platforms (darwin as example)
> compile something in darwin will be compatible with darwin8, but not
> darwin7 or 9 (as test_gem_platform.rb assert).
>
> http://pastie.caboo.se/101899
>
> I know that is wrong... apply the changes I made bomb the darwin  
> plaform.
>
> But on windows, VC6 and VC8 aren't compatible builds, neither the
> linking to msvcrt-ruby18 and msvcr80-ruby18...
>
> So installing gems made with Gem::Platform.local 'i386-mswin32' will
> not work under Gem::Platform.local == 'i386-mswin32_80' ...due the
> missing shared library.
>
> Guess until users face the problem and start closing tickets at
> rubyforge will be some general acknowledge about it.
>
> What the hell... just ignore me.

I see what you mean, is there any other way to detect VC6 from  
Config::CONFIG?

Would it be worthwhile to special-case for mswin32?

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



From luislavena at gmail.com  Sat Sep 29 18:37:17 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 29 Sep 2007 19:37:17 -0300
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <B1A36693-2447-40EF-9424-BF4A13F83CB0@segment7.net>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
	<ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
	<71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com>
	<71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com>
	<B1A36693-2447-40EF-9424-BF4A13F83CB0@segment7.net>
Message-ID: <71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com>

On 9/29/07, Eric Hodel <drbrain at segment7.net> wrote:
>
> I see what you mean, is there any other way to detect VC6 from
> Config::CONFIG?
>

Config::CONFIG['RUBY_SO_NAME']
=> "msvcrt-ruby18"

Config::CONFIG["LIBRUBY_SO"]
=> "msvcrt-ruby18.dll"

The shared library changes names between versions. VC6 uses 'msvcrt'
and VC8 uses 'msvcr80'

We could call it "runtime" since is that what the acronym mean ;-)
(MicroSoft Visual C Run Time)

> Would it be worthwhile to special-case for mswin32?

I don't know what whould happen to 1.8.x releases after 1.9 get on the spot.

Nobu is in charge of the releases and keep using VC6 for it, which is slow.

http://pastie.caboo.se/pastes/95210

I have found a few Ruby users that compile ruby from scratch instead
of using the OCI.
The only compiler available for that task is VC8 (which is free
available as Visual Studio Express or Windows SDK for Vista).

Also the "tests" builds of 1.9 are made with VC6, but since they are
older, someone checkout trunk will need VC8... which will face similar
issues against VC6.

I forgot to include in the pastie the change to ~ method, which
currently ignores version mismatch (and making it strict bomb darwin
tests).

Maybe we should ask on ruby-code about it... and Curt since I never
heard back from him about this.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From drbrain at segment7.net  Sat Sep 29 23:32:56 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 29 Sep 2007 20:32:56 -0700
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
	<ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
	<71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com>
	<71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com>
	<B1A36693-2447-40EF-9424-BF4A13F83CB0@segment7.net>
	<71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com>
Message-ID: <940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net>

On Sep 29, 2007, at 15:37 , Luis Lavena wrote:
> On 9/29/07, Eric Hodel <drbrain at segment7.net> wrote:
>> I see what you mean, is there any other way to detect VC6 from
>> Config::CONFIG?
>
> Config::CONFIG['RUBY_SO_NAME']
> => "msvcrt-ruby18"
>
> Config::CONFIG["LIBRUBY_SO"]
> => "msvcrt-ruby18.dll"
>
> The shared library changes names between versions. VC6 uses 'msvcrt'
> and VC8 uses 'msvcr80'
>
> We could call it "runtime" since is that what the acronym mean ;-)
> (MicroSoft Visual C Run Time)

Ok.

Should we make this check in Gem::Platform.local and choose x86- 
mswin32-80 or x86-mswin32-60 (I think those are right) based on which  
one it is?

This will also cause future gems built with the platform set to  
Gem::Platform::CURRENT to have the properly versioned platform.

If the future gems have the wrong platform, we've done our best.  :/

>> Would it be worthwhile to special-case for mswin32?
>
> I don't know what whould happen to 1.8.x releases after 1.9 get on  
> the spot.
>
> Nobu is in charge of the releases and keep using VC6 for it, which  
> is slow.
>
> http://pastie.caboo.se/pastes/95210
>
> I have found a few Ruby users that compile ruby from scratch instead
> of using the OCI.
> The only compiler available for that task is VC8 (which is free
> available as Visual Studio Express or Windows SDK for Vista).
>
> Also the "tests" builds of 1.9 are made with VC6, but since they are
> older, someone checkout trunk will need VC8... which will face similar
> issues against VC6.
>
> I forgot to include in the pastie the change to ~ method, which
> currently ignores version mismatch (and making it strict bomb darwin
> tests).
>
> Maybe we should ask on ruby-code about it... and Curt since I never
> heard back from him about this.

Yes.  I don't think it is worth delaying a beta of RubyGems for, if  
there is so much uncertainty.

Do you know which compiler the one-click installer is built with?

From djberg96 at gmail.com  Sun Sep 30 00:08:15 2007
From: djberg96 at gmail.com (Daniel Berger)
Date: Sat, 29 Sep 2007 22:08:15 -0600
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>	<ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>	<71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com>	<71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com>	<B1A36693-2447-40EF-9424-BF4A13F83CB0@segment7.net>	<71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com>
	<940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net>
Message-ID: <46FF212F.3030300@gmail.com>

Eric Hodel wrote:

<snip>

> Do you know which compiler the one-click installer is built with?

The ReleaseNotes.txt file for 1.8.6-25 says it was built with MS Visual 
C++ 6.

Regards,

Dan


From listsub at twelve71.com  Sun Sep 30 02:23:29 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Sun, 30 Sep 2007 07:23:29 +0100
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <B0B36497-EE48-4900-947E-4C1B818EF93F@segment7.net>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
	<2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net>
	<223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com>
	<B0B36497-EE48-4900-947E-4C1B818EF93F@segment7.net>
Message-ID: <F6700D65-FE96-461C-A638-2A10CE9E9DA9@twelve71.com>

Hi Eric,

I just did an svn up (rev 1413) and an full-on setup.rb.  The .gemrc  
option seems tobe working fine, but the --update-sources arg does not  
appear to override that (at least in my adhoc, very early morning  
testing).

I'll dig a bit deeper, but would be great if someone else could confirm.

1) disconnect from network
2) gem search rails --remote (should fail)
3) edit .gemrc, set :update_sources: false
4) gem search rails --remote (should work!)
5) gem search rails --remote --update-sources should fail again as no  
network, but seems to work.

Alan
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/





From listsub at twelve71.com  Sun Sep 30 02:28:36 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Sun, 30 Sep 2007 07:28:36 +0100
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <B0B36497-EE48-4900-947E-4C1B818EF93F@segment7.net>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
	<2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net>
	<223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com>
	<B0B36497-EE48-4900-947E-4C1B818EF93F@segment7.net>
Message-ID: <9E306CC7-D23B-4F07-8402-CDFE80EA3103@twelve71.com>

Ahh, Gem.configuration[:update_sources] is set to true, but  
Gem.configuration.update_sources is still false.  I'll go look at the  
config file stuff.

A.
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/



On 27 Sep 2007, at 17:02, Eric Hodel wrote:

> On Sep 27, 2007, at 01:25 , Alan C Francis wrote:
>> Hi Eric, I'll try and finish it tonight.  Would be nice to see it all
>> the way through :-)
>>
>> Is there a way to sandbox the gems installation so I can really try
>> it out without losing my 'site_ruby' gems installation ?
>
> I use:
>
> ruby -Ilib bin/gem command options
>
> from the checkout to run the gem command, and explicitly provide the
> path to checkout/lib when testing interoperation between libraries.
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From listsub at twelve71.com  Sun Sep 30 02:32:47 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Sun, 30 Sep 2007 07:32:47 +0100
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <B0B36497-EE48-4900-947E-4C1B818EF93F@segment7.net>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
	<2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net>
	<223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com>
	<B0B36497-EE48-4900-947E-4C1B818EF93F@segment7.net>
Message-ID: <53ADEB83-846C-4F33-B78F-8FE65230A546@twelve71.com>

:-(

The @update_sources is, of course, only set in initialize and not  
refreshed in []=.  SO when I set the config with []= later in the  
game, the accessor is out of date.

This is a bit bigger than just this flag, perhaps as it would be true  
for all the options in Gem.configuration  configuration.backtrace,  
for example doesn't necessarily equal configuration[:backtrace].

A.
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/



On 27 Sep 2007, at 17:02, Eric Hodel wrote:

> On Sep 27, 2007, at 01:25 , Alan C Francis wrote:
>> Hi Eric, I'll try and finish it tonight.  Would be nice to see it all
>> the way through :-)
>>
>> Is there a way to sandbox the gems installation so I can really try
>> it out without losing my 'site_ruby' gems installation ?
>
> I use:
>
> ruby -Ilib bin/gem command options
>
> from the checkout to run the gem command, and explicitly provide the
> path to checkout/lib when testing interoperation between libraries.
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From listsub at twelve71.com  Sun Sep 30 02:44:33 2007
From: listsub at twelve71.com (Alan C Francis)
Date: Sun, 30 Sep 2007 07:44:33 +0100
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <9E306CC7-D23B-4F07-8402-CDFE80EA3103@twelve71.com>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
	<2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net>
	<223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com>
	<B0B36497-EE48-4900-947E-4C1B818EF93F@segment7.net>
	<9E306CC7-D23B-4F07-8402-CDFE80EA3103@twelve71.com>
Message-ID: <11F9E65B-CB1F-4E03-BA65-DC3323D29001@twelve71.com>

A non-text attachment was scrubbed...
Name: config_file_hash_accessor_patch.diff
Type: application/octet-stream
Size: 432 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20070930/1dee8edd/attachment.obj 
-------------- next part --------------

I've added

     instance_variable_set("@#{key.to_sym}", value) if respond_to?  
key.to_sym

to Gem::ConfigFile # []=

Which seems to work on the command line.  Unfortunately I can't seem  
to run the tests so can't verify I haven't broken anything :-)

------

Harpo:~/work/rubygems_trunk acf$ rake
(in /Users/acf/work/rubygems_trunk)
./lib/rubygems/custom_require.rb:27:in `gem_original_require': ./lib/ 
rubygems/digest/md5.rb:16: syntax error, unexpected '.', expecting  
'\n' or ';' (SyntaxError)
     def Gem::MD5.md5(string)
                  ^
./lib/rubygems/digest/md5.rb:20: syntax error, unexpected kEND,  
expecting $end  from ./lib/rubygems/custom_require.rb:27:in `require'
         from ./lib/rubygems/package.rb:12
         from ./lib/rubygems/custom_require.rb:27:in  
`gem_original_require'
         from ./lib/rubygems/custom_require.rb:27:in `require'
         from ./lib/rubygems/format.rb:9
         from ./lib/rubygems/custom_require.rb:27:in  
`gem_original_require'
         from ./lib/rubygems/custom_require.rb:27:in `require'
         from ./test/test_gem_commands_build_command.rb:4
         from /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake/ 
rake_test_loader.rb:5:in `load'
         from /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake/ 
rake_test_loader.rb:5
         from /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake/ 
rake_test_loader.rb:5:in `each'
         from /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake/ 
rake_test_loader.rb:5
rake aborted!
Command failed with status (1): [/usr/local/bin/ruby -w -Ilib "/usr/ 
local/l...]

(See full trace by running task with --trace)


--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/



On 30 Sep 2007, at 07:28, Alan C Francis wrote:

> Ahh, Gem.configuration[:update_sources] is set to true, but
> Gem.configuration.update_sources is still false.  I'll go look at the
> config file stuff.
>
> A.
> --
> http://www.alancfrancis.com/
> http://www.cardboardsoftware.com/
> http://www.scotlandonrails.com/


From luislavena at gmail.com  Sun Sep 30 11:38:09 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 30 Sep 2007 12:38:09 -0300
Subject: [Rubygems-developers] Questions about Gem Platform Matching
In-Reply-To: <940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net>
References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com>
	<ADB7684D-4AF3-4A42-8845-8665BB0914A5@segment7.net>
	<71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com>
	<71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com>
	<B1A36693-2447-40EF-9424-BF4A13F83CB0@segment7.net>
	<71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com>
	<940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net>
Message-ID: <71166b3b0709300838jffa05e2rad5b1578e99f8893@mail.gmail.com>

On 9/30/07, Eric Hodel <drbrain at segment7.net> wrote:
>
> Should we make this check in Gem::Platform.local and choose x86-
> mswin32-80 or x86-mswin32-60 (I think those are right) based on which
> one it is?
>

This sounds good, since Ruby set the platform to mswin32_80 .. adding
-60 to the VC6 version sounds right.

> This will also cause future gems built with the platform set to
> Gem::Platform::CURRENT to have the properly versioned platform.
>
> If the future gems have the wrong platform, we've done our best.  :/
>

Yeah, we cannot prevent apocalypse, but at least, reduce the problems
a few newcomers will face.

> Yes.  I don't think it is worth delaying a beta of RubyGems for, if
> there is so much uncertainty.
>

Yes, I agree with you.

Mailing right now ruby-core to get more information about "the future" :-)

> Do you know which compiler the one-click installer is built with?

VC6 (plain msvcrt) as Daniel Berger stated.

Regards and thank you for your interest on this issue.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From drbrain at segment7.net  Sun Sep 30 20:01:34 2007
From: drbrain at segment7.net (Eric Hodel)
Date: Sun, 30 Sep 2007 17:01:34 -0700
Subject: [Rubygems-developers] Patch added.
In-Reply-To: <11F9E65B-CB1F-4E03-BA65-DC3323D29001@twelve71.com>
References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com>
	<2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net>
	<223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com>
	<B0B36497-EE48-4900-947E-4C1B818EF93F@segment7.net>
	<9E306CC7-D23B-4F07-8402-CDFE80EA3103@twelve71.com>
	<11F9E65B-CB1F-4E03-BA65-DC3323D29001@twelve71.com>
Message-ID: <0EFE6DA9-9E6E-482E-B00E-E6404D619BCA@segment7.net>

On Sep 29, 2007, at 23:44 , Alan C Francis wrote:
> <config_file_hash_accessor_patch.diff>
>
> I've added
>
>     instance_variable_set("@#{key.to_sym}", value) if respond_to?  
> key.to_sym
>
> to Gem::ConfigFile # []=
>
> Which seems to work on the command line.  Unfortunately I can't  
> seem to run the tests so can't verify I haven't broken anything :-)

I decided to go the opposite way around, and use  
Gem.configuration.update_sources instead of the hash-type access.  It  
would probably be better to remove the hash access going forward,  
since it adds lots of complication and requires more manual  
documentation.

> ------
>
> Harpo:~/work/rubygems_trunk acf$ rake
> (in /Users/acf/work/rubygems_trunk)
> ./lib/rubygems/custom_require.rb:27:in `gem_original_require': ./ 
> lib/rubygems/digest/md5.rb:16: syntax error, unexpected '.',  
> expecting '\n' or ';' (SyntaxError)
>     def Gem::MD5.md5(string)
>                  ^

Fixed, I'm dumb.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars