From transfire at gmail.com  Sat Mar  8 01:20:57 2008
From: transfire at gmail.com (Trans)
Date: Fri, 7 Mar 2008 22:20:57 -0800 (PST)
Subject: [Rubygems-developers] Free the Docs
Message-ID: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>

I know the immediate reaction this is likely to get --half of which is
probably just b/c it is coming from me. But putting these gut-
reactions aside, consider it objectively. It makes sense...

RubyGems should not be generating rdocs.

As good an example as any for when convention ought to triumph over
configuration, this is it. As it stands we currently must fill out
gemspec options: has_rdoc, rdoc_options and extra_rdoc_files, to get
rdocs generated on install, but that's still not enough to get them
right. For starters, --main README's are missing across the board.
Well beyond that it prevents us from all forms of customization of our
docs, from simply using a different template to using a system other
then rdoc altogether. The current design completely constrains our
documentation freedom.

A far better solution is simply to designate a conventional location
for html api docs, say doc/html-api/ or something like that, and just
have gem server look for them there. For those who would rather
generate docs then redistribute them (to save package size?)  then
provide a ruby script that does it, and the gemspec can have a field
to designate that, which it can then run on install. That's much
simpler solution and much more powerful to boot.

T.

From transfire at gmail.com  Sat Mar  8 01:52:38 2008
From: transfire at gmail.com (Trans)
Date: Fri, 7 Mar 2008 22:52:38 -0800 (PST)
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
Message-ID: <9de49157-05ab-4de5-bff1-25ead2084cf8@x41g2000hsb.googlegroups.com>



On Mar 8, 1:20 am, Trans <transf... at gmail.com> wrote:
> I know the immediate reaction this is likely to get --half of which is
> probably just b/c it is coming from me. But putting these gut-
> reactions aside, consider it objectively. It makes sense...
>
> RubyGems should not be generating rdocs.
>
> As good an example as any for when convention ought to triumph over
> configuration, this is it. As it stands we currently must fill out
> gemspec options: has_rdoc, rdoc_options and extra_rdoc_files, to get
> rdocs generated on install, but that's still not enough to get them
> right. For starters, --main README's are missing across the board.

I found some gem generated rdocs that mange to get the READMEs up
front. So that can be configured. Many of packages I looked at though
don't have it configured correctly. Clearly many people aren't
checking the output of RubyGems generated rdocs.

T.

From halostatue at gmail.com  Sat Mar  8 08:06:58 2008
From: halostatue at gmail.com (Austin Ziegler)
Date: Sat, 8 Mar 2008 08:06:58 -0500
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <9de49157-05ab-4de5-bff1-25ead2084cf8@x41g2000hsb.googlegroups.com>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
	<9de49157-05ab-4de5-bff1-25ead2084cf8@x41g2000hsb.googlegroups.com>
Message-ID: <9e7db9110803080506rf764c78h641cabd2165ff134@mail.gmail.com>

On Sat, Mar 8, 2008 at 1:52 AM, Trans <transfire at gmail.com> wrote:
>  On Mar 8, 1:20 am, Trans <transf... at gmail.com> wrote:
>  > I know the immediate reaction this is likely to get --half of which is
>  > probably just b/c it is coming from me. But putting these gut-
>  > reactions aside, consider it objectively. It makes sense...
>  >
>  > RubyGems should not be generating rdocs.
>  >
>  > As good an example as any for when convention ought to triumph over
>  > configuration, this is it. As it stands we currently must fill out
>  > gemspec options: has_rdoc, rdoc_options and extra_rdoc_files, to get
>  > rdocs generated on install, but that's still not enough to get them
>  > right. For starters, --main README's are missing across the board.

Instead of preventing rdoc generation, RubyGems should make it easier
to generate docs in a straightforward, standard way. Specifically, it
should provide some accessors that correspond to common RDoc
command-line options (e.g., main page, title, etc.) that make for
better documentation results.

Then, hoe and similar tools should generate gemspecs that use these accessors.

The situation could definitely use some improvement.

-austin
-- 
Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/
               * austin at halostatue.ca * http://www.halostatue.ca/feed/
               * austin at zieglers.ca

From devi.webmaster at gmail.com  Sat Mar  8 12:54:59 2008
From: devi.webmaster at gmail.com (Daniel Brumbaugh Keeney)
Date: Sat, 8 Mar 2008 11:54:59 -0600
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
Message-ID: <3bceeb2d0803080954y40c0c675s8d2d763ada1ff10c@mail.gmail.com>

On Sat, Mar 8, 2008 at 12:20 AM, Trans <transfire at gmail.com> wrote:
>  RubyGems should not be generating rdocs.
>
>  As good an example as any for when convention ought to triumph over
>  configuration, this is it. As it stands we currently must fill out
>  gemspec options: has_rdoc, rdoc_options and extra_rdoc_files, to get
>  rdocs generated on install, but that's still not enough to get them
>  right. For starters, --main README's are missing across the board.
>  Well beyond that it prevents us from all forms of customization of our
>  docs, from simply using a different template to using a system other
>  then rdoc altogether. The current design completely constrains our
>  documentation freedom.
>
>  A far better solution is simply to designate a conventional location
>  for html api docs, say doc/html-api/ or something like that, and just
>  have gem server look for them there. For those who would rather
>  generate docs then redistribute them (to save package size?)  then
>  provide a ruby script that does it, and the gemspec can have a field
>  to designate that, which it can then run on install. That's much
>  simpler solution and much more powerful to boot.
>
>  T.


RubyGems is a package management system. It is common and appropriate
that documentation be distributed along with software. RubyGems is
unique, however, in that, with a particular documentation system, it
generates the documentation on the user's computer, rather than
generating it during packaging and including it within the package. It
is important to note, that of course any documentation system could be
used and distributed within the gem as is common in other packaging
systems. However, I consider the fact that documentation is generated
on the user's computer to be a significant feature of RubyGems, and
agree that it is worthwhile to ensure that an alternative
documentation system could be similarly integrated.

I agree with your solution, that it should be possible to have a Ruby
script, included in the gem, should be executed after installation of
the gem. That permits the use of arbitrary programs for documentation,
such as rdoc, or other install procedures, such as adding menu items,
currently not possible during RubyGems' install process. This, as
well, I consider to be a major flaw in RubyGems, which a post-install
script would cleanly solve. Of course, this would also require a
pre-removal script, and it is important to consider the authority
these scripts will be given. Basically, I think it's a fantastic idea.

However, I think that same idea directly conflicts with your other
proposal. As it stands, it should be fairly simple to allow
customization of rdoc generation, having local options override ones
contained in the gem, since the rdoc command is neatly separated.

If rdoc generation moves into a post-install script, it will become
much more difficult to override. Contained within an arbitrary script,
there would be no good way to separate the rdoc generation command and
override its options. This suggests that a special format or library
would be in use for post-install scripts, something like:
command_line_task( false, 'rdoc', "--main=README --title 'Cool Program'" )
where false is in an indicator that it's okay if rdoc isn't available,
the program will still run. Then the user could set a local option to
append '--template=**' any commands to 'rdoc'.

Anyhow, I would suggest making a way for the user to change rdoc
options locally first, since that should be fairly simple. Adding
post-install and pre-removal scripts would be a major change to
RubyGems, but I think it's the right choice.


Daniel Brumbaugh Keeney

From transfire at gmail.com  Sun Mar  9 10:26:20 2008
From: transfire at gmail.com (Trans)
Date: Sun, 9 Mar 2008 07:26:20 -0700 (PDT)
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <3bceeb2d0803080954y40c0c675s8d2d763ada1ff10c@mail.gmail.com>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
	<3bceeb2d0803080954y40c0c675s8d2d763ada1ff10c@mail.gmail.com>
Message-ID: <c2ae0884-5b15-48ec-bd97-11fc070ff9a1@o77g2000hsf.googlegroups.com>



On Mar 8, 1:54 pm, "Daniel Brumbaugh Keeney"
<devi.webmas... at gmail.com> wrote:

> RubyGems is a package management system. It is common and appropriate
> that documentation be distributed along with software. RubyGems is
> unique, however, in that, with a particular documentation system, it
> generates the documentation on the user's computer, rather than
> generating it during packaging and including it within the package. It
> is important to note, that of course any documentation system could be
> used and distributed within the gem as is common in other packaging
> systems. However, I consider the fact that documentation is generated
> on the user's computer to be a significant feature of RubyGems, and
> agree that it is worthwhile to ensure that an alternative
> documentation system could be similarly integrated.
>
> I agree with your solution, that it should be possible to have a Ruby
> script, included in the gem, should be executed after installation of
> the gem. That permits the use of arbitrary programs for documentation,
> such as rdoc, or other install procedures, such as adding menu items,
> currently not possible during RubyGems' install process. This, as
> well, I consider to be a major flaw in RubyGems, which a post-install
> script would cleanly solve. Of course, this would also require a
> pre-removal script, and it is important to consider the authority
> these scripts will be given. Basically, I think it's a fantastic idea.
>
> However, I think that same idea directly conflicts with your other
> proposal. As it stands, it should be fairly simple to allow
> customization of rdoc generation, having local options override ones
> contained in the gem, since the rdoc command is neatly separated.

Don't get me wrong. I'm not against having an rdoc generation feature.
That's fine. I'm only saying that it would be better for this feature
to participate in a broader convention, whereby it would generate
those rdocs into a conventional directory location. That way we can
supply there own pre-built docs, if we prefer, and RubyGems need not
bother generating the rdocs --that's a simple way in fact for RubyGems
to know if it should generate rdocs, rather than using the has_rdoc
config, just look to see if there is any content in the conventional
location or not.

> If rdoc generation moves into a post-install script, it will become
> much more difficult to override. Contained within an arbitrary script,
> there would be no good way to separate the rdoc generation command and
> override its options. This suggests that a special format or library
> would be in use for post-install scripts, something like:
> command_line_task( false, 'rdoc', "--main=README --title 'Cool Program'" )
> where false is in an indicator that it's okay if rdoc isn't available,
> the program will still run. Then the user could set a local option to
> append '--template=**' any commands to 'rdoc'.

That's too complicated. I thought of it as a simple separate dedicated
ruby script, not part of another arbitrary one. But the more I think
about this the more I think this isn't needed. Either let RubyGems
generate the rdocs or supply a pre-built set in the package. That's
enough.

The need for pre- and post- install scripts is a separate question.

> Anyhow, I would suggest making a way for the user to change rdoc
> options locally first, since that should be fairly simple. Adding
> post-install and pre-removal scripts would be a major change to
> RubyGems, but I think it's the right choice.

The template is probably the only rdoc option that it makes sense to
let the user determine. In my modified setup.rb, in which I added an
rdoc feature, I used an environment variable for this, RDOC_TEMPLATE.

T.

From halostatue at gmail.com  Sun Mar  9 11:39:02 2008
From: halostatue at gmail.com (Austin Ziegler)
Date: Sun, 9 Mar 2008 08:39:02 -0700
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <3bceeb2d0803080954y40c0c675s8d2d763ada1ff10c@mail.gmail.com>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
	<3bceeb2d0803080954y40c0c675s8d2d763ada1ff10c@mail.gmail.com>
Message-ID: <9e7db9110803090839h4725a7dagd68fb9fe8030c2fc@mail.gmail.com>

On Sat, Mar 8, 2008 at 10:54 AM, Daniel Brumbaugh Keeney
<devi.webmaster at gmail.com> wrote:
>  I agree with your solution, that it should be possible to have a Ruby
>  script, included in the gem, should be executed after installation of
>  the gem. That permits the use of arbitrary programs for documentation,
>  such as rdoc, or other install procedures, such as adding menu items,
>  currently not possible during RubyGems' install process. This, as
>  well, I consider to be a major flaw in RubyGems, which a post-install
>  script would cleanly solve. Of course, this would also require a
>  pre-removal script, and it is important to consider the authority
>  these scripts will be given. Basically, I think it's a fantastic idea.

My understanding is that it's a security feature as to why arbitrary
scripts aren't executed in a RubyGems install. It can be worked around
by making an "extension" that does this, but that is considered bad
form (and if a "reviewed repository" concept similar to RPA is ever
implemented, would be grounds for *not* including such a gem).

I would be opposed to post-install/pre-remove scripts just for that
reason. (It may also more tightly bind RubyGems to its current
directory structure.)

-austin
-- 
Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/
               * austin at halostatue.ca * http://www.halostatue.ca/feed/
               * austin at zieglers.ca

From fajwilson at gmail.com  Tue Mar 11 08:33:53 2008
From: fajwilson at gmail.com (Frank Wilson)
Date: Tue, 11 Mar 2008 12:33:53 +0000
Subject: [Rubygems-developers] installing rubygems under home dir
Message-ID: <13b70780803110533s1bbe873dj1fe6785d1972d2c3@mail.gmail.com>

I don't know if a development list is the appropriate place for this
so I apologise if this is going to the wrong list. This is the only
rubygems list I know of.

I've been trying to install rubygems under my home directory so it
doesn't foul up apt (im running debian testing).

I followed section 2.4 of the rubygems faq
http://rubygems.org/read/chapter/15#page101 but that didnt really
help.

When I ran gems I got a message saying that it couldn't find the rubygems.rb.

I found rubygems.rb under ~/lib which clearly wasnt where the writer
of FAQ intended it to be because he gave this for the RUBYLIB
variable:

export RUBYLIB=$PREFIX/lib/ruby:$PREFIX/lib/site_ruby/1.8

So I got gem working by adding $PREFIX/lib to RUBYLIB. However, what
I'd like to know is, is there a way of getting everything contained
under ~/lib/ruby or ~/lib/site_ruby or even ~/lib/gems (pretty much
what the faq implied was possible)?

Thanks,

Frank

From drbrain at segment7.net  Tue Mar 11 17:59:00 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 12 Mar 2008 08:59:00 +1100
Subject: [Rubygems-developers] installing rubygems under home dir
In-Reply-To: <13b70780803110533s1bbe873dj1fe6785d1972d2c3@mail.gmail.com>
References: <13b70780803110533s1bbe873dj1fe6785d1972d2c3@mail.gmail.com>
Message-ID: <6464B3F0-7329-49CE-8106-6B34932B424B@segment7.net>

On Mar 11, 2008, at 23:33 PM, Frank Wilson wrote:

> I've been trying to install rubygems under my home directory so it
> doesn't foul up apt (im running debian testing).

Try:

unpack rubygems
ruby setup.rb --prefix ~/ruby/lib
export RUBYLIB=~/ruby/lib
export GEM_HOME=~/ruby/gems
~/ruby/lib/bin/gem env # should list ~/ruby/gems in GEM PATHS
add ~/ruby/lib/bin/gem to your PATH somehow

From vieuxtech at gmail.com  Thu Mar 13 02:01:36 2008
From: vieuxtech at gmail.com (Sam Roberts)
Date: Wed, 12 Mar 2008 23:01:36 -0700
Subject: [Rubygems-developers] gem search doesn't search the gem summary (or
	description)
Message-ID: <17eac67c0803122301l6b52dfdai592c158bc0500596@mail.gmail.com>

It seems less than useful for a package search tool.

For example, if you searched for microscope you might want to find
rscope if its summary said "library allowing you to control your
microscope with ruby".

Am I missing something? How do I make my gems queryable by keywords in
their summary?

I'm about to add gems to my project that have names like
projectname+keyword+keyword2, with no contents, that  depend solely
on projectname... but that seems lame, so any better suggestions?

Thanks,
Sam

From thewoolleyman at gmail.com  Fri Mar 14 01:59:15 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 13 Mar 2008 22:59:15 -0700
Subject: [Rubygems-developers] Explicit 'exit' in InstallCommand#execute
	method causes problems when invoking RubyGems programatically
Message-ID: <e3af97510803132259h28e217q992728142949b134@mail.gmail.com>

Hi,

An explicit exit was added to InstallCommand#execute in revision 1621
to address bug #17438.

However, this breaks apps which invoke rubygems programatically.

Can this be rolled back and implemented at a higher level?  I
interface programatically via GemRunner#run.  If this is the correct
way, it seems like you should pass the return code up to the top-level
'gem' executable and perform the exit there.  Alternately, some sort
of "programmatic flag" could be passed in somewhere, but handling the
exit in the top-level executable seems more appropriate.

This completely broke GemInstaller, so I'd like to get it rolled back
or patched.  If you are too busy, I can take a shot at it.

Thanks,
-- Chad

From tobiasreif at pinkjuice.com  Fri Mar 14 15:23:35 2008
From: tobiasreif at pinkjuice.com (Tobi Reif)
Date: Fri, 14 Mar 2008 20:23:35 +0100
Subject: [Rubygems-developers] "No definition for dummy_dump"
Message-ID: <20080314192335.GA6589@linux.local>

Hi

Only if it's of interest:

$ sudo gem install mongrel
[...]
5 gems installed
Installing ri documentation for gem_plugin-0.2.3...
Installing ri documentation for daemons-1.0.9...
Installing ri documentation for fastthread-1.0.1...

No definition for dummy_dump

No definition for dummy_dump

No definition for rb_queue_marshal_load

Tobi

-- 
http://www.rubynaut.com/


From drbrain at segment7.net  Fri Mar 14 09:33:13 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 15 Mar 2008 00:33:13 +1100
Subject: [Rubygems-developers] Explicit 'exit' in InstallCommand#execute
	method causes problems when invoking RubyGems programatically
In-Reply-To: <e3af97510803132259h28e217q992728142949b134@mail.gmail.com>
References: <e3af97510803132259h28e217q992728142949b134@mail.gmail.com>
Message-ID: <1063EF59-6121-4F60-9BF6-FFB27DA704FD@segment7.net>

On Mar 14, 2008, at 16:59 PM, Chad Woolley wrote:
> An explicit exit was added to InstallCommand#execute in revision 1621
> to address bug #17438.
>
> However, this breaks apps which invoke rubygems programatically.
>
> Can this be rolled back and implemented at a higher level?

I don't believe there is a higher level than Gem::Command subclasses  
for this.

> This completely broke GemInstaller, so I'd like to get it rolled back
> or patched.  If you are too busy, I can take a shot at it.

I suppose instead an appropriate exception could be raised.  Please  
take a shot at it.


From drbrain at segment7.net  Fri Mar 14 17:46:42 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 15 Mar 2008 08:46:42 +1100
Subject: [Rubygems-developers] "No definition for dummy_dump"
In-Reply-To: <20080314192335.GA6589@linux.local>
References: <20080314192335.GA6589@linux.local>
Message-ID: <5F726C1D-B949-42A7-9896-D12DB8EADFD8@segment7.net>

On Mar 15, 2008, at 06:23 AM, Tobi Reif wrote:

> Installing ri documentation for fastthread-1.0.1...
>
> No definition for dummy_dump
>
> No definition for dummy_dump
>
> No definition for rb_queue_marshal_load

Report this to the fastthread people.

From vieuxtech at gmail.com  Fri Mar 14 20:03:49 2008
From: vieuxtech at gmail.com (Sam Roberts)
Date: Fri, 14 Mar 2008 17:03:49 -0700
Subject: [Rubygems-developers] Explicit 'exit' in InstallCommand#execute
	method causes problems when invoking RubyGems programatically
In-Reply-To: <1063EF59-6121-4F60-9BF6-FFB27DA704FD@segment7.net>
References: <e3af97510803132259h28e217q992728142949b134@mail.gmail.com>
	<1063EF59-6121-4F60-9BF6-FFB27DA704FD@segment7.net>
Message-ID: <17eac67c0803141703i3664844eldeb3d7e48559702d@mail.gmail.com>

On Fri, Mar 14, 2008 at 6:33 AM, Eric Hodel <drbrain at segment7.net> wrote:
> On Mar 14, 2008, at 16:59 PM, Chad Woolley wrote:
>  > An explicit exit was added to InstallCommand#execute in revision 1621
>  > to address bug #17438.
>  >
>  > However, this breaks apps which invoke rubygems programatically.
>
>  > This completely broke GemInstaller, so I'd like to get it rolled back
>  > or patched.  If you are too busy, I can take a shot at it.
>
>  I suppose instead an appropriate exception could be raised.  Please
> take a shot at it.


That sounds like the right way... but remember that Kernel.exit()
doesn't actually exit immediately (in the unix sense of exit(2)), it
just raises an exception, so you can rescue it:

~ % ruby exit.rb
#<SystemExit: exit>
#<SystemExit: exit>
~ % cat exit.rb

2.times do
  begin
    exit
  rescue SystemExit
    p $!
  end
end

From thewoolleyman at gmail.com  Fri Mar 14 20:24:59 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 14 Mar 2008 17:24:59 -0700
Subject: [Rubygems-developers] Explicit 'exit' in InstallCommand#execute
	method causes problems when invoking RubyGems programatically
In-Reply-To: <1063EF59-6121-4F60-9BF6-FFB27DA704FD@segment7.net>
References: <e3af97510803132259h28e217q992728142949b134@mail.gmail.com>
	<1063EF59-6121-4F60-9BF6-FFB27DA704FD@segment7.net>
Message-ID: <e3af97510803141724w17091e13u88fe76471e03322@mail.gmail.com>

On Fri, Mar 14, 2008 at 6:33 AM, Eric Hodel <drbrain at segment7.net> wrote:
>  I suppose instead an appropriate exception could be raised.  Please
>
> take a shot at it.

Yes, an exceptions seems the right way to handle it, I realized that today.

So, to confirm, I would make something like a custom
Gem::ExitException, and catch/handle that in the 'gem' executable.
Sound right?  If there is a different exception you'd like me to use,
either a standard one or one already in rubygems, let me know.

Thanks,
-- Chad

From raasdnil at gmail.com  Sun Mar 16 19:38:36 2008
From: raasdnil at gmail.com (Mikel Lindsaar)
Date: Mon, 17 Mar 2008 10:38:36 +1100
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <c2ae0884-5b15-48ec-bd97-11fc070ff9a1@o77g2000hsf.googlegroups.com>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
	<3bceeb2d0803080954y40c0c675s8d2d763ada1ff10c@mail.gmail.com>
	<c2ae0884-5b15-48ec-bd97-11fc070ff9a1@o77g2000hsf.googlegroups.com>
Message-ID: <57a815bf0803161638p406d7525re44c9ad62779ea35@mail.gmail.com>

On Mon, Mar 10, 2008 at 1:26 AM, Trans <transfire at gmail.com> wrote:
>  bother generating the rdocs --that's a simple way in fact for RubyGems
>  to know if it should generate rdocs, rather than using the has_rdoc
>  config, just look to see if there is any content in the conventional
>  location or not.

That is an elegant solution.  Either, you produce your custom HTML
based documentation in a specific folder (maybe /docs/ anchored at
index.html) within your package, or rubygems will generate your RDocs
from source.

unless File.exist?('docs/index.html')
  generate rdoc
end

Simple.

The other nice thing about that solution is that all the packages out
there that know nothing about pre-built rdoc will continue to work
exactly as they do no without any modification.

Compressed pre generated RDoc pages will not create a huge hit for
those packages that want to distribute their own documents.

Mikel

From luislavena at gmail.com  Tue Mar 18 20:11:42 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 18 Mar 2008 21:11:42 -0300
Subject: [Rubygems-developers] trunk segfault on Windows
Message-ID: <71166b3b0803181711j38601c07s3488ecb8e0bb39f6@mail.gmail.com>

Hello fellow ruby developers!,

Been away a few weeks (work and vacations) and didn't notice until
today that my CI for several Ruby OSS projects was down. Switching it
on again showed a few issues with latest Rubygems.

It seems that the changes introduced in trunk (related to tar
handling) are generating some segmentation faults in Windows:

(in D:/Users/Luis/projects/oss/rubygems/rubygems-trunk)
Loaded suite C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake/rake_test_loader
Started
...E....E........../lib/rubygems/package/tar_header.rb:211: warning:
Zlib::GzipWriter object must be closed explicitly.
./lib/rubygems/package/tar_writer.rb:40: [BUG] Segmentation fault
ruby 1.8.6 (2007-09-24) [i386-mswin32]


This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
rake aborted!
Command failed with status (3): [C:/Ruby/bin/ruby -w -Ilib "C:/Ruby/lib/rub...]

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

Ruby used:
ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] (this is x86-mswin32-60)
Windows XP SP2

===

Just wanted to warn about this before an official release/update came
out. I'll investigate this issue tomorrow afternoon and hope find the
root of the problem.

I know, Windows... Windows... so much troubles for that damn platform :-P

Everybody have a good night :-)
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From drbrain at segment7.net  Wed Mar 19 00:10:10 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 18 Mar 2008 21:10:10 -0700
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
Message-ID: <F6022AB9-8C47-480E-A44F-5FE3A62578D9@segment7.net>

On Mar 7, 2008, at 22:20 PM, Trans wrote:
> [...] Well beyond that it prevents us from all forms of  
> customization of our docs, from simply using a different template to  
> using a system other then rdoc altogether. The current design  
> completely constrains our documentation freedom.

The current design also gives consistency of documentation across all  
installed gems, which has incredible value by itself.

> A far better solution is simply to designate a conventional location
> for html api docs, say doc/html-api/ or something like that, and just
> have gem server look for them there.

This is a good idea as an additional feature.

> For those who would rather generate docs then redistribute them (to  
> save package size?)  then provide a ruby script that does it, and  
> the gemspec can have a field
> to designate that, which it can then run on install. That's much  
> simpler solution and much more powerful to boot.

RubyGems doesn't have a post-install script on purpose.

From Daniel.Berger at qwest.com  Wed Mar 19 10:58:02 2008
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Wed, 19 Mar 2008 09:58:02 -0500
Subject: [Rubygems-developers] trunk segfault on Windows
In-Reply-To: <71166b3b0803181711j38601c07s3488ecb8e0bb39f6@mail.gmail.com>
References: <71166b3b0803181711j38601c07s3488ecb8e0bb39f6@mail.gmail.com>
Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D30D3@ITOMAE2KM01.AD.QINTRA.COM>

 

> -----Original Message-----
> From: rubygems-developers-bounces at rubyforge.org 
> [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf 
> Of Luis Lavena
> Sent: Tuesday, March 18, 2008 6:12 PM
> To: RubyGems Developers (ML)
> Subject: [Rubygems-developers] trunk segfault on Windows
> 
> Hello fellow ruby developers!,
> 
> Been away a few weeks (work and vacations) and didn't notice 
> until today that my CI for several Ruby OSS projects was 
> down. Switching it on again showed a few issues with latest Rubygems.
> 
> It seems that the changes introduced in trunk (related to tar
> handling) are generating some segmentation faults in Windows:
> 
> (in D:/Users/Luis/projects/oss/rubygems/rubygems-trunk)
> Loaded suite 
> C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake/rake_test_loader
> Started
> ...E....E........../lib/rubygems/package/tar_header.rb:211: warning:
> Zlib::GzipWriter object must be closed explicitly.
> ./lib/rubygems/package/tar_writer.rb:40: [BUG] Segmentation 
> fault ruby 1.8.6 (2007-09-24) [i386-mswin32]
> 
> 
> This application has requested the Runtime to terminate it in 
> an unusual way.
> Please contact the application's support team for more information.
> rake aborted!
> Command failed with status (3): [C:/Ruby/bin/ruby -w -Ilib 
> "C:/Ruby/lib/rub...]
> 
> (See full trace by running task with --trace)
> 
> Ruby used:
> ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] (this 
> is x86-mswin32-60) Windows XP SP2

Here's the code in question from zlib.c:

static void
gzfile_free(gz)
    struct gzfile *gz;
{
    struct zstream *z = &gz->z;

    if (ZSTREAM_IS_READY(z)) {
	if (z->func == &deflate_funcs) {
	    finalizer_warn("Zlib::GzipWriter object must be closed
explicitly.");
	}
	zstream_finalize(z);
    }
    free(gz);
}

static void
finalizer_warn(msg)
    const char *msg;
{
    fprintf(stderr, "zlib(finalizer): %s\n", msg);
}

static void
zstream_finalize(z)
    struct zstream *z;
{
    int err = z->func->end(&z->stream);
    if (err == Z_STREAM_ERROR)
	finalizer_warn("the stream state was inconsistent.");
    if (err == Z_DATA_ERROR)
	finalizer_warn("the stream was freed prematurely.");
}

Nothing jumps out at me at the moment. Anyone else?

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  Wed Mar 19 11:03:04 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 19 Mar 2008 12:03:04 -0300
Subject: [Rubygems-developers] trunk segfault on Windows
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D30D3@ITOMAE2KM01.AD.QINTRA.COM>
References: <71166b3b0803181711j38601c07s3488ecb8e0bb39f6@mail.gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB023D30D3@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <71166b3b0803190803t6a3f0bb1l2a7d8fb3f4dff999@mail.gmail.com>

On Wed, Mar 19, 2008 at 11:58 AM, Berger, Daniel
<Daniel.Berger at qwest.com> wrote:
>
>
>  Here's the code in question from zlib.c:
>
>  static void
>  gzfile_free(gz)
>     struct gzfile *gz;
>  {
>     struct zstream *z = &gz->z;
>
>     if (ZSTREAM_IS_READY(z)) {
>         if (z->func == &deflate_funcs) {
>             finalizer_warn("Zlib::GzipWriter object must be closed
>  explicitly.");
>         }
>         zstream_finalize(z);
>     }
>     free(gz);
>  }
>
>  static void
>  finalizer_warn(msg)
>     const char *msg;
>  {
>     fprintf(stderr, "zlib(finalizer): %s\n", msg);
>  }
>
>  static void
>  zstream_finalize(z)
>     struct zstream *z;
>  {
>     int err = z->func->end(&z->stream);
>     if (err == Z_STREAM_ERROR)
>         finalizer_warn("the stream state was inconsistent.");
>     if (err == Z_DATA_ERROR)
>         finalizer_warn("the stream was freed prematurely.");
>  }
>
>  Nothing jumps out at me at the moment. Anyone else?
>

That warning is shown before but is not related to the segmentation
fault, at least, not directly. I'll try to debug it later today to see
what is happening down there :-P

Thank you for your time.

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From djberg96 at gmail.com  Wed Mar 19 11:32:51 2008
From: djberg96 at gmail.com (Daniel Berger)
Date: Wed, 19 Mar 2008 09:32:51 -0600
Subject: [Rubygems-developers] trunk segfault on Windows
In-Reply-To: <71166b3b0803190803t6a3f0bb1l2a7d8fb3f4dff999@mail.gmail.com>
References: <71166b3b0803181711j38601c07s3488ecb8e0bb39f6@mail.gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB023D30D3@ITOMAE2KM01.AD.QINTRA.COM>
	<71166b3b0803190803t6a3f0bb1l2a7d8fb3f4dff999@mail.gmail.com>
Message-ID: <6037b70c0803190832o610df0d0u375d5a519e7ec942@mail.gmail.com>

On Wed, Mar 19, 2008 at 9:03 AM, Luis Lavena <luislavena at gmail.com> wrote:
>
> On Wed, Mar 19, 2008 at 11:58 AM, Berger, Daniel
>  <Daniel.Berger at qwest.com> wrote:
>  >
>  >
>  >  Here's the code in question from zlib.c:
>  >
>  >  static void
>  >  gzfile_free(gz)
>  >     struct gzfile *gz;
>  >  {
>  >     struct zstream *z = &gz->z;
>  >
>  >     if (ZSTREAM_IS_READY(z)) {
>  >         if (z->func == &deflate_funcs) {
>  >             finalizer_warn("Zlib::GzipWriter object must be closed
>  >  explicitly.");
>  >         }
>  >         zstream_finalize(z);
>  >     }
>  >     free(gz);
>  >  }
>  >
>  >  static void
>  >  finalizer_warn(msg)
>  >     const char *msg;
>  >  {
>  >     fprintf(stderr, "zlib(finalizer): %s\n", msg);
>  >  }
>  >
>  >  static void
>  >  zstream_finalize(z)
>  >     struct zstream *z;
>  >  {
>  >     int err = z->func->end(&z->stream);
>  >     if (err == Z_STREAM_ERROR)
>  >         finalizer_warn("the stream state was inconsistent.");
>  >     if (err == Z_DATA_ERROR)
>  >         finalizer_warn("the stream was freed prematurely.");
>  >  }
>  >
>  >  Nothing jumps out at me at the moment. Anyone else?
>  >
>
>  That warning is shown before but is not related to the segmentation
>  fault, at least, not directly. I'll try to debug it later today to see
>  what is happening down there :-P

See if you can fix these warnings while you're down there:

"zlib.c", line 297: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const unsigned char : "zlib.c", line 272
        argument : pointer to char
"zlib.c", line 450: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 469: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 482: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 488: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 503: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 523: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 567: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 718: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 722: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const char : "zlib.c", line 596
        argument : pointer to unsigned char
"zlib.c", line 723: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 754: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const char : "zlib.c", line 596
        argument : pointer to unsigned char
"zlib.c", line 767: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const char : "zlib.c", line 596
        argument : pointer to unsigned char
"zlib.c", line 782: warning: assignment type mismatch:
        pointer to unsigned char "=" pointer to char
"zlib.c", line 788: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const char : "zlib.c", line 596
        argument : pointer to unsigned char
"zlib.c", line 793: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "../../intern.h", line 404
        argument : pointer to unsigned char
"zlib.c", line 804: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const char : "zlib.c", line 596
        argument : pointer to unsigned char
"zlib.c", line 808: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "../../intern.h", line 404
        argument : pointer to unsigned char
"zlib.c", line 972: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 1205: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 1265: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 1270: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 1344: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 1405: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const unsigned char :
"/usr/include/zlib.h", line 444
        argument : pointer to char
"zlib.c", line 1470: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 1471: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 1522: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 1527: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 1623: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 774
        argument : pointer to char
"zlib.c", line 1667: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const unsigned char :
"/usr/include/zlib.h", line 553
        argument : pointer to char
"zlib.c", line 1961: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const char : "zlib.c", line 495
        argument : pointer to unsigned char
"zlib.c", line 1983: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const char : "zlib.c", line 495
        argument : pointer to unsigned char
"zlib.c", line 1999: warning: assignment type mismatch:
        pointer to const unsigned char "=" pointer to char
"zlib.c", line 2037: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const unsigned char : "zlib.c", line 1899
        argument : pointer to char
"zlib.c", line 2075: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const unsigned char : "zlib.c", line 1909
        argument : pointer to char
"zlib.c", line 2076: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const unsigned char : "zlib.c", line 1909
        argument : pointer to char
"zlib.c", line 2123: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 2140: warning: argument #2 is incompatible with prototype:
        prototype: pointer to const unsigned char :
"/usr/include/zlib.h", line 838
        argument : pointer to char
"zlib.c", line 2215: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 2762: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 708
        argument : pointer to char
"zlib.c", line 2784: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 2091
        argument : pointer to char
"zlib.c", line 2798: warning: argument #2 is incompatible with prototype:
        prototype: pointer to unsigned char : "zlib.c", line 2091
        argument : pointer to char

Regards,

Dan

From transfire at gmail.com  Wed Mar 19 12:58:04 2008
From: transfire at gmail.com (Trans)
Date: Wed, 19 Mar 2008 09:58:04 -0700 (PDT)
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <F6022AB9-8C47-480E-A44F-5FE3A62578D9@segment7.net>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
	<F6022AB9-8C47-480E-A44F-5FE3A62578D9@segment7.net>
Message-ID: <87419898-0a60-4770-a4ae-f5c2db690560@8g2000hsu.googlegroups.com>



On Mar 19, 12:10 am, Eric Hodel <drbr... at segment7.net> wrote:
> On Mar 7, 2008, at 22:20 PM, Trans wrote:
>
> > [...] Well beyond that it prevents us from all forms of
> > customization of our docs, from simply using a different template to
> > using a system other then rdoc altogether. The current design
> > completely constrains our documentation freedom.
>
> The current design also gives consistency of documentation across all
> installed gems, which has incredible value by itself.

That's true, but I think that's where RI comes in. What would be nice
to see is RI become format savy. Currently is spits out ANSI or plain
text. If it could spit out other formats like html and xml, and
perhaps tex or pdf too, then it would serve very well as this across
the board consistent api reference.

The main problem with RDocs is that they are static. I see RDocs more
as a means for project developers to generate project reference
manuals. Right now I think RDoc is trying to straddle two different
use-cases --api docs and project manual, and is thus coming up a bit
short on both counts.

> > A far better solution is simply to designate a conventional location
> > for html api docs, say doc/html-api/ or something like that, and just
> > have gem server look for them there.
>
> This is a good idea as an additional feature.

Cool. I'm using doc/html/ in my own projects --seems like a
reasonable, concise convention.

> > For those who would rather generate docs then redistribute them (to
> > save package size?)  then provide a ruby script that does it, and
> > the gemspec can have a field
> > to designate that, which it can then run on install. That's much
> > simpler solution and much more powerful to boot.
>
> RubyGems doesn't have a post-install script on purpose.

I agree. I don't think the overhead of distributing pre-built docs is
much of a price to pay these days if one has special documentation
requirements. So post-install scripts for documentation sake is
completely unnecessary.

Finally I note what would make a big difference for me when
documenting a large project like Facets, is support for documentation
"groups", maybe via a per file directive ":group: GroupName", or
otherwise as command line options. If Rdoc could take that and present
those groups separated is some fashion, things would have been much
better for me, and I imagine James Britt, at least, might feel the
same in his work to document Ruby's standard library.

T.

From ryand-ruby at zenspider.com  Wed Mar 19 13:39:55 2008
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Wed, 19 Mar 2008 10:39:55 -0700
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <87419898-0a60-4770-a4ae-f5c2db690560@8g2000hsu.googlegroups.com>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
	<F6022AB9-8C47-480E-A44F-5FE3A62578D9@segment7.net>
	<87419898-0a60-4770-a4ae-f5c2db690560@8g2000hsu.googlegroups.com>
Message-ID: <1829F9B3-F65F-4680-A7A2-207EB3479321@zenspider.com>


On Mar 19, 2008, at 09:58 , Trans wrote:
> That's true, but I think that's where RI comes in. What would be nice
> to see is RI become format savy. Currently is spits out ANSI or plain
> text. If it could spit out other formats like html and xml, and
> perhaps tex or pdf too, then it would serve very well as this across
> the board consistent api reference.

% ri -h
...
    --format, -f <name>
                   Format to use when displaying output:
                      ansi, bs, html, plain, simple
...


From drbrain at segment7.net  Wed Mar 19 17:11:17 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 19 Mar 2008 14:11:17 -0700
Subject: [Rubygems-developers] trunk segfault on Windows
In-Reply-To: <71166b3b0803181711j38601c07s3488ecb8e0bb39f6@mail.gmail.com>
References: <71166b3b0803181711j38601c07s3488ecb8e0bb39f6@mail.gmail.com>
Message-ID: <87F13874-8725-4784-A03C-A728FA11B29A@segment7.net>

On Mar 18, 2008, at 17:11 PM, Luis Lavena wrote:
> Hello fellow ruby developers!,
>
> Been away a few weeks (work and vacations) and didn't notice until
> today that my CI for several Ruby OSS projects was down. Switching it
> on again showed a few issues with latest Rubygems.
>
> It seems that the changes introduced in trunk (related to tar
> handling) are generating some segmentation faults in Windows:

The changes to tar handling largely involved refactorings, so behavior  
should be identical.  However, many new tests were added.

> (in D:/Users/Luis/projects/oss/rubygems/rubygems-trunk)
> Loaded suite C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake/ 
> rake_test_loader
> Started
> ...E....E........../lib/rubygems/package/tar_header.rb:211: warning:
> Zlib::GzipWriter object must be closed explicitly.

This appears to be when the GC ran, as the line here is currently:

     header.unpack("C*").inject { |a, b| a + b }

and I think that message comes from a Zlib finalizer.

I suspect this has something to do with the previous test errors, as  
that message should show up regardless of platform.

> ./lib/rubygems/package/tar_writer.rb:40: [BUG] Segmentation fault
> ruby 1.8.6 (2007-09-24) [i386-mswin32]

And this one is:
   @io.write data

I think it will be most-fruitful to look into the test errors first.   
I fear that things may not be properly cleaned-up in the tests which  
may lead to the segfaults.

> ===
>
> Just wanted to warn about this before an official release/update came
> out. I'll investigate this issue tomorrow afternoon and hope find the
> root of the problem.
>
> I know, Windows... Windows... so much troubles for that damn  
> platform :-P
>
> Everybody have a good night :-)

From transfire at gmail.com  Wed Mar 19 17:13:31 2008
From: transfire at gmail.com (Trans)
Date: Wed, 19 Mar 2008 14:13:31 -0700 (PDT)
Subject: [Rubygems-developers] Free the Docs
In-Reply-To: <1829F9B3-F65F-4680-A7A2-207EB3479321@zenspider.com>
References: <0cdf1bc6-8dfd-4844-952c-b759669a816e@59g2000hsb.googlegroups.com>
	<F6022AB9-8C47-480E-A44F-5FE3A62578D9@segment7.net>
	<87419898-0a60-4770-a4ae-f5c2db690560@8g2000hsu.googlegroups.com>
	<1829F9B3-F65F-4680-A7A2-207EB3479321@zenspider.com>
Message-ID: <fbaded8e-e5c1-4e94-ae47-cba56072e542@m44g2000hsc.googlegroups.com>



On Mar 19, 1:39 pm, Ryan Davis <ryand-r... at zenspider.com> wrote:
> On Mar 19, 2008, at 09:58 , Trans wrote:
>
> > That's true, but I think that's where RI comes in. What would be nice
> > to see is RI become format savy. Currently is spits out ANSI or plain
> > text. If it could spit out other formats like html and xml, and
> > perhaps tex or pdf too, then it would serve very well as this across
> > the board consistent api reference.
>
> % ri -h
> ...
>     --format, -f <name>
>                    Format to use when displaying output:
>                       ansi, bs, html, plain, simple
> ...

Bahahaha! All this time I never bother to check to see if that worked.
I always thought the format option only applied to Rdocs --which was
reinforced b/c I've been using FastRI, and figured it was the same for
RI.

Very cool! Thanks!
T.

From drbrain at segment7.net  Wed Mar 19 17:23:48 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 19 Mar 2008 14:23:48 -0700
Subject: [Rubygems-developers] Explicit 'exit' in InstallCommand#execute
	method causes problems when invoking RubyGems programatically
In-Reply-To: <e3af97510803141724w17091e13u88fe76471e03322@mail.gmail.com>
References: <e3af97510803132259h28e217q992728142949b134@mail.gmail.com>
	<1063EF59-6121-4F60-9BF6-FFB27DA704FD@segment7.net>
	<e3af97510803141724w17091e13u88fe76471e03322@mail.gmail.com>
Message-ID: <039D8075-06E5-4ED9-BCBE-2F34980F8763@segment7.net>

On Mar 14, 2008, at 17:24 PM, Chad Woolley wrote:
> On Fri, Mar 14, 2008 at 6:33 AM, Eric Hodel <drbrain at segment7.net>  
> wrote:
>> I suppose instead an appropriate exception could be raised.  Please
>>
>> take a shot at it.
>
> Yes, an exceptions seems the right way to handle it, I realized that  
> today.
>
> So, to confirm, I would make something like a custom
> Gem::ExitException, and catch/handle that in the 'gem' executable.
> Sound right?  If there is a different exception you'd like me to use,
> either a standard one or one already in rubygems, let me know.

I think that would be fine, make it a subclass of Gem::Exception, and  
add an exit_code field to it.

From luislavena at gmail.com  Wed Mar 19 21:00:38 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 19 Mar 2008 22:00:38 -0300
Subject: [Rubygems-developers] trunk segfault on Windows
In-Reply-To: <6037b70c0803190832o610df0d0u375d5a519e7ec942@mail.gmail.com>
References: <71166b3b0803181711j38601c07s3488ecb8e0bb39f6@mail.gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB023D30D3@ITOMAE2KM01.AD.QINTRA.COM>
	<71166b3b0803190803t6a3f0bb1l2a7d8fb3f4dff999@mail.gmail.com>
	<6037b70c0803190832o610df0d0u375d5a519e7ec942@mail.gmail.com>
Message-ID: <71166b3b0803191800i1dd8e822r367fa9789f6b4adc@mail.gmail.com>

On Wed, Mar 19, 2008 at 12:32 PM, Daniel Berger <djberg96 at gmail.com> wrote:
>
>  See if you can fix these warnings while you're down there:
>
>  "zlib.c", line 297: warning: argument #2 is incompatible with prototype:
>         prototype: pointer to const unsigned char : "zlib.c", line 272
>         argument : pointer to char
>  "zlib.c", line 450: warning: assignment type mismatch:
>         pointer to unsigned char "=" pointer to char
>  "zlib.c", line 469: warning: assignment type mismatch:
>         pointer to unsigned char "=" pointer to char

Those sounds quite familiar with wrong zlib.h ... what compiler are you using?

My last build of ruby_1_8 branch didn't show that (both VC6 and MinGW)

BTW, I just committed a fix for the use of GzipWriter, which was the
one generating the segfault due #flush call on it...
(Eric will agree that is weird stuff) :-P

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Thu Mar 20 00:03:34 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 20 Mar 2008 01:03:34 -0300
Subject: [Rubygems-developers] Strange errors, can you shed some light?
Message-ID: <71166b3b0803192103q5d91bde8ib0dfd4134a094959@mail.gmail.com>

Hello list,

I'm looking at the trunk code trying to solve a series of errors shown
during 'rake test' on Windows.

Solved the segfaults a few hours ago (thanks to Eric to point to
GzipWriter issues) and now I'm facing the following ones:

$ ruby -v -Ilib test\test_gem_commands_update_command.rb

  1) Error:
test_execute(TestGemCommandsUpdateCommand):
NoMethodError: undefined method `size' for nil:NilClass
    ./lib/rubygems/package/tar_reader/entry.rb:84:in `read'
    ./lib/rubygems/specification.rb:609:in `normalize_yaml_input'
    ./lib/rubygems/specification.rb:575:in `from_yaml'
    ./lib/rubygems/package/tar_input.rb:184:in `load_gemspec'
    ./lib/rubygems/package/tar_input.rb:52:in `initialize'
    ./lib/rubygems/package/tar_reader.rb:46:in `each'
    ./lib/rubygems/package/tar_reader.rb:37:in `loop'
    ./lib/rubygems/package/tar_reader.rb:37:in `each'
    ./lib/rubygems/package/tar_input.rb:33:in `initialize'
    ./lib/rubygems/package/tar_input.rb:18:in `new'
    ./lib/rubygems/package/tar_input.rb:18:in `open'
    ./lib/rubygems/package.rb:56:in `open'
    ./lib/rubygems/format.rb:67:in `from_io'
    ./lib/rubygems/format.rb:51:in `from_file_by_path'
    ./lib/rubygems/format.rb:50:in `open'
    ./lib/rubygems/format.rb:50:in `from_file_by_path'
    ./lib/rubygems/installer.rb:81:in `initialize'
    ./lib/rubygems/dependency_installer.rb:184:in `new'
    ./lib/rubygems/dependency_installer.rb:184:in `install'
    ./lib/rubygems/dependency_installer.rb:173:in `each'
    ./lib/rubygems/dependency_installer.rb:173:in `install'
    ./lib/rubygems/commands/update_command.rb:86:in `execute'
    ./lib/rubygems/commands/update_command.rb:82:in `each'
    ./lib/rubygems/commands/update_command.rb:82:in `execute'
    test/test_gem_commands_update_command.rb:31: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_update_command.rb:30:in `test_execute'

  2) Error:
test_execute_dependencies(TestGemCommandsUpdateCommand):
Gem::InstallError: invalid gem format for
D:/Temp/test_rubygems_2904/gemhome/cache/c-2.gem
    ./lib/rubygems/installer.rb:83:in `initialize'
    ./lib/rubygems/dependency_installer.rb:184:in `new'
    ./lib/rubygems/dependency_installer.rb:184:in `install'
    ./lib/rubygems/dependency_installer.rb:173:in `each'
    ./lib/rubygems/dependency_installer.rb:173:in `install'
    ./lib/rubygems/commands/update_command.rb:86:in `execute'
    ./lib/rubygems/commands/update_command.rb:82:in `each'
    ./lib/rubygems/commands/update_command.rb:82:in `execute'
    test/test_gem_commands_update_command.rb:93:in `test_execute_dependencies'
    ./lib/rubygems/user_interaction.rb:45:in `use_ui'
    ./lib/rubygems/user_interaction.rb:27:in `use_ui'
    test/test_gem_commands_update_command.rb:92:in `test_execute_dependencies'

  3) Error:
test_execute_named(TestGemCommandsUpdateCommand):
NoMethodError: undefined method `size' for nil:NilClass
    ./lib/rubygems/package/tar_reader/entry.rb:84:in `read'
    ./lib/rubygems/specification.rb:609:in `normalize_yaml_input'
    ./lib/rubygems/specification.rb:575:in `from_yaml'
    ./lib/rubygems/package/tar_input.rb:184:in `load_gemspec'
    ./lib/rubygems/package/tar_input.rb:52:in `initialize'
    ./lib/rubygems/package/tar_reader.rb:46:in `each'
    ./lib/rubygems/package/tar_reader.rb:37:in `loop'
    ./lib/rubygems/package/tar_reader.rb:37:in `each'
    ./lib/rubygems/package/tar_input.rb:33:in `initialize'
    ./lib/rubygems/package/tar_input.rb:18:in `new'
    ./lib/rubygems/package/tar_input.rb:18:in `open'
    ./lib/rubygems/package.rb:56:in `open'
    ./lib/rubygems/format.rb:67:in `from_io'
    ./lib/rubygems/format.rb:51:in `from_file_by_path'
    ./lib/rubygems/format.rb:50:in `open'
    ./lib/rubygems/format.rb:50:in `from_file_by_path'
    ./lib/rubygems/installer.rb:81:in `initialize'
    ./lib/rubygems/dependency_installer.rb:184:in `new'
    ./lib/rubygems/dependency_installer.rb:184:in `install'
    ./lib/rubygems/dependency_installer.rb:173:in `each'
    ./lib/rubygems/dependency_installer.rb:173:in `install'
    ./lib/rubygems/commands/update_command.rb:86:in `execute'
    ./lib/rubygems/commands/update_command.rb:82:in `each'
    ./lib/rubygems/commands/update_command.rb:82:in `execute'
    test/test_gem_commands_update_command.rb:117:in `test_execute_named'
    ./lib/rubygems/user_interaction.rb:45:in `use_ui'
    ./lib/rubygems/user_interaction.rb:27:in `use_ui'
    test/test_gem_commands_update_command.rb:116:in `test_execute_named'

===

Errors 1 and 3 are related to tar_input trying to get #size from a
#read operation over the IO, which returned nil since readed
information was greater than header size:

lib/rubygems/package/tar_reader/entry.rb:78 (#read):

    return nil if @read >= @header.size


But I cannot determine exactly why this is happening (at least, why
this happens on Windows).

Error 2 I think is also related, but on a higher level and the raised
exception is hidden (just a guees).

Any pointers? I'm not familiar with the TarWriter, TarImport and
related Tar handling files.

FYI, there are a few issues with the TestCase helpers that write or
read from files not being opened as binary format (something needed in
Windows for ASCII values outside the printable 127 ones).

Thanks in advance.
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Sat Mar 22 11:32:33 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 22 Mar 2008 12:32:33 -0300
Subject: [Rubygems-developers] Errors in trunk (for Windows)
Message-ID: <71166b3b0803220832l714e4a43ta75f842abf731e3f@mail.gmail.com>

Hello Guys,

I'm still getting the following errors on Windows. These came from gem
commands 'update' and 'install', but both end in the same place of the
"from_yaml" and normalize_yaml_input:

  1) Error:
test_execute_remote(TestGemCommandsInstallCommand):
NoMethodError: undefined method `size' for nil:NilClass
    ./lib/rubygems/package/tar_reader/entry.rb:84:in `read'
    ./lib/rubygems/specification.rb:609:in `normalize_yaml_input'
    ./lib/rubygems/specification.rb:575:in `from_yaml'
    ./lib/rubygems/package/tar_input.rb:184:in `load_gemspec'
    ./lib/rubygems/package/tar_input.rb:52:in `initialize'
    ./lib/rubygems/package/tar_reader.rb:46:in `each'
    ./lib/rubygems/package/tar_reader.rb:37:in `loop'
    ./lib/rubygems/package/tar_reader.rb:37:in `each'
    ./lib/rubygems/package/tar_input.rb:33:in `initialize'
    ./lib/rubygems/package/tar_input.rb:18:in `new'
    ./lib/rubygems/package/tar_input.rb:18:in `open'
    ./lib/rubygems/package.rb:56:in `open'
    ./lib/rubygems/format.rb:67:in `from_io'
    ./lib/rubygems/format.rb:51:in `from_file_by_path'
    C:/Ruby/lib/ruby/1.8/open-uri.rb:32:in `open_uri_original_open'
    C:/Ruby/lib/ruby/1.8/open-uri.rb:32:in `open'
    ./lib/rubygems/format.rb:50:in `from_file_by_path'
    ./lib/rubygems/installer.rb:81:in `initialize'
    ./lib/rubygems/dependency_installer.rb:194:in `new'
    ./lib/rubygems/dependency_installer.rb:194:in `install'
    ./lib/rubygems/dependency_installer.rb:183:in `each'
    ./lib/rubygems/dependency_installer.rb:183:in `install'
    ./lib/rubygems/commands/install_command.rb:73:in `execute'
    ./lib/rubygems/commands/install_command.rb:70:in `each'
    ./lib/rubygems/commands/install_command.rb:70:in `execute'
    ./test/test_gem_commands_install_command.rb:119:in `test_execute_remote'
    ./lib/rubygems/user_interaction.rb:45:in `use_ui'
    ./lib/rubygems/user_interaction.rb:27:in `use_ui'
    ./test/test_gem_commands_install_command.rb:118:in `test_execute_remote'

===

I exposed this on a previous message, but no one answered.

To quote myself:

"Errors 1 and 3 are related to tar_input trying to get #size from a
#read operation over the IO, which returned nil since readed
information was greater than header size:

lib/rubygems/package/tar_reader/entry.rb:78 (#read):

   return nil if @read >= @header.size


But I cannot determine exactly why this is happening (at least, why
this happens on Windows).
"

Any ideas?

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Mon Mar 24 00:01:20 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 24 Mar 2008 01:01:20 -0300
Subject: [Rubygems-developers] GEM_HOME and GEM_PATH on Windows
Message-ID: <71166b3b0803232101m11848596h9f3390a2298d9712@mail.gmail.com>

Hello List,

I'm dealing with something related to how GEM_HOME and GEM_PATH is
processed on Windows.

Take as base $HOME being set on D:/Users/Luis (except for the drive
letter, sounds like *nix).

set GEM_HOME to %HOME%\.gems, which ends into
D:\\Users\\Luis\\.gems

set GEM_PATH to %GEM_HOME%;C:/Ruby/lib/ruby/gems/1.8

Now, Gem::path reply return this array:

["D:\\Users\\Luis\\.gems", "C:/Ruby/lib/ruby/gems/1.8"]

And gem install is capable to install into GEM_HOME.

Now, 'gem list' do not find the installed gem, unless I change
GEM_HOME definition to use File::SEPARATOR instead of
File::ALT_SEPARATOR...

I know the issue is in Gem::set_home and Gem::set_paths
(lib/rubygems.rb:511 and 517)

1am here, worked all weekend on getting i386-mingw32 Ruby build
working so been a bit exhausted... any hint?

FYI, reduced the failures and errors for rubygems trunk, and no more
segfaults! :-D
(for those who care) ;-)

Regards,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Mon Mar 24 01:17:30 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 23 Mar 2008 22:17:30 -0700
Subject: [Rubygems-developers] GEM_HOME and GEM_PATH on Windows
In-Reply-To: <71166b3b0803232101m11848596h9f3390a2298d9712@mail.gmail.com>
References: <71166b3b0803232101m11848596h9f3390a2298d9712@mail.gmail.com>
Message-ID: <e3af97510803232217n72dfb8cerce3336ca5f22e438@mail.gmail.com>

On Sun, Mar 23, 2008 at 9:01 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  FYI, reduced the failures and errors for rubygems trunk, and no more
>  segfaults! :-D
>  (for those who care) ;-)

Good Job.  I care, and take heart in your difficulties debugging
problems on windows.  I've got some that have me stumped, but still
trying to find the root cause :)

-- Chad

From drbrain at segment7.net  Tue Mar 25 17:43:52 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 25 Mar 2008 14:43:52 -0700
Subject: [Rubygems-developers] Errors in trunk (for Windows)
In-Reply-To: <71166b3b0803220832l714e4a43ta75f842abf731e3f@mail.gmail.com>
References: <71166b3b0803220832l714e4a43ta75f842abf731e3f@mail.gmail.com>
Message-ID: <D5A5F8D7-A044-4791-A14B-820D7F52C715@segment7.net>

On Mar 22, 2008, at 08:32 AM, Luis Lavena wrote:
> Hello Guys,
>
> I'm still getting the following errors on Windows. These came from gem
> commands 'update' and 'install', but both end in the same place of the
> "from_yaml" and normalize_yaml_input:
>
>  1) Error:
> test_execute_remote(TestGemCommandsInstallCommand):
> NoMethodError: undefined method `size' for nil:NilClass
>    ./lib/rubygems/package/tar_reader/entry.rb:84:in `read'
>    ./lib/rubygems/specification.rb:609:in `normalize_yaml_input'
>    ./lib/rubygems/specification.rb:575:in `from_yaml'
>    ./lib/rubygems/package/tar_input.rb:184:in `load_gemspec'
>    ./lib/rubygems/package/tar_input.rb:52:in `initialize'
>    ./lib/rubygems/package/tar_reader.rb:46:in `each'
>    ./lib/rubygems/package/tar_reader.rb:37:in `loop'
>    ./lib/rubygems/package/tar_reader.rb:37:in `each'
>    ./lib/rubygems/package/tar_input.rb:33:in `initialize'
>    ./lib/rubygems/package/tar_input.rb:18:in `new'
>    ./lib/rubygems/package/tar_input.rb:18:in `open'
> [...]
>
> ===
>
> I exposed this on a previous message, but no one answered.
>
> To quote myself:
>
> "Errors 1 and 3 are related to tar_input trying to get #size from a
> #read operation over the IO, which returned nil since readed
> information was greater than header size:
>
> lib/rubygems/package/tar_reader/entry.rb:78 (#read):
>
>   return nil if @read >= @header.size
>
>
> But I cannot determine exactly why this is happening (at least, why
> this happens on Windows).
> "
>
> Any ideas?

It sounds like the gem being extracted has been built wrong.

When will you be online next so we can confer?

I've finished up the index update changes that were in my tree, so I  
think this is our last thing to fix.

From drbrain at segment7.net  Tue Mar 25 19:51:08 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 25 Mar 2008 16:51:08 -0700
Subject: [Rubygems-developers] GEM_HOME and GEM_PATH on Windows
In-Reply-To: <71166b3b0803232101m11848596h9f3390a2298d9712@mail.gmail.com>
References: <71166b3b0803232101m11848596h9f3390a2298d9712@mail.gmail.com>
Message-ID: <6D27D21F-3811-4168-B5D9-8F7B6D519215@segment7.net>


On Mar 23, 2008, at 21:01 PM, Luis Lavena wrote:
> Hello List,
>
> I'm dealing with something related to how GEM_HOME and GEM_PATH is
> processed on Windows.
>
> Take as base $HOME being set on D:/Users/Luis (except for the drive
> letter, sounds like *nix).
>
> set GEM_HOME to %HOME%\.gems, which ends into
> D:\\Users\\Luis\\.gems
>
> set GEM_PATH to %GEM_HOME%;C:/Ruby/lib/ruby/gems/1.8
>
> Now, Gem::path reply return this array:
>
> ["D:\\Users\\Luis\\.gems", "C:/Ruby/lib/ruby/gems/1.8"]
>
> And gem install is capable to install into GEM_HOME.
>
> Now, 'gem list' do not find the installed gem, unless I change
> GEM_HOME definition to use File::SEPARATOR instead of
> File::ALT_SEPARATOR...

I wonder, try:

p Dir["D:\\Users\\Luis\\.gems/specifications"]

vs:

p Dir["D:/Users/Luis/.gems/specifications"]

Maybe mixing SEPARATOR and ALT_SEPARATOR confuses something inside ruby.

From djberg96 at gmail.com  Tue Mar 25 20:26:30 2008
From: djberg96 at gmail.com (Daniel Berger)
Date: Tue, 25 Mar 2008 18:26:30 -0600
Subject: [Rubygems-developers] GEM_HOME and GEM_PATH on Windows
In-Reply-To: <6D27D21F-3811-4168-B5D9-8F7B6D519215@segment7.net>
References: <71166b3b0803232101m11848596h9f3390a2298d9712@mail.gmail.com>
	<6D27D21F-3811-4168-B5D9-8F7B6D519215@segment7.net>
Message-ID: <6037b70c0803251726m257297cs6572bbb76578de89@mail.gmail.com>

On Tue, Mar 25, 2008 at 5:51 PM, Eric Hodel <drbrain at segment7.net> wrote:
>
>  On Mar 23, 2008, at 21:01 PM, Luis Lavena wrote:
>  > Hello List,
>  >
>  > I'm dealing with something related to how GEM_HOME and GEM_PATH is
>  > processed on Windows.
>  >
>  > Take as base $HOME being set on D:/Users/Luis (except for the drive
>  > letter, sounds like *nix).
>  >
>  > set GEM_HOME to %HOME%\.gems, which ends into
>  > D:\\Users\\Luis\\.gems
>  >
>  > set GEM_PATH to %GEM_HOME%;C:/Ruby/lib/ruby/gems/1.8
>  >
>  > Now, Gem::path reply return this array:
>  >
>  > ["D:\\Users\\Luis\\.gems", "C:/Ruby/lib/ruby/gems/1.8"]
>  >
>  > And gem install is capable to install into GEM_HOME.
>  >
>  > Now, 'gem list' do not find the installed gem, unless I change
>  > GEM_HOME definition to use File::SEPARATOR instead of
>  > File::ALT_SEPARATOR...
>
>  I wonder, try:
>
>  p Dir["D:\\Users\\Luis\\.gems/specifications"]
>
>  vs:
>
>  p Dir["D:/Users/Luis/.gems/specifications"]
>
>  Maybe mixing SEPARATOR and ALT_SEPARATOR confuses something inside ruby.

http://groups.google.com/group/comp.lang.ruby/msg/730266613bde1047

Dir[] doesn't allow backslashes.

Regards,

Dan

From luislavena at gmail.com  Tue Mar 25 21:36:55 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 25 Mar 2008 22:36:55 -0300
Subject: [Rubygems-developers] GEM_HOME and GEM_PATH on Windows
In-Reply-To: <6D27D21F-3811-4168-B5D9-8F7B6D519215@segment7.net>
References: <71166b3b0803232101m11848596h9f3390a2298d9712@mail.gmail.com>
	<6D27D21F-3811-4168-B5D9-8F7B6D519215@segment7.net>
Message-ID: <71166b3b0803251836w13b72921q8a1c3cd3977df49f@mail.gmail.com>

On Tue, Mar 25, 2008 at 8:51 PM, Eric Hodel <drbrain at segment7.net> wrote:
>
>  On Mar 23, 2008, at 21:01 PM, Luis Lavena wrote:
>  > Hello List,
>  >
>  > I'm dealing with something related to how GEM_HOME and GEM_PATH is
>  > processed on Windows.
>  >
>  > Take as base $HOME being set on D:/Users/Luis (except for the drive
>  > letter, sounds like *nix).
>  >
>  > set GEM_HOME to %HOME%\.gems, which ends into
>  > D:\\Users\\Luis\\.gems
>  >
>  > set GEM_PATH to %GEM_HOME%;C:/Ruby/lib/ruby/gems/1.8
>  >
>  > Now, Gem::path reply return this array:
>  >
>  > ["D:\\Users\\Luis\\.gems", "C:/Ruby/lib/ruby/gems/1.8"]
>  >
>  > And gem install is capable to install into GEM_HOME.
>  >
>  > Now, 'gem list' do not find the installed gem, unless I change
>  > GEM_HOME definition to use File::SEPARATOR instead of
>  > File::ALT_SEPARATOR...
>
>  I wonder, try:
>
>  p Dir["D:\\Users\\Luis\\.gems/specifications"]
>
>  vs:
>
>  p Dir["D:/Users/Luis/.gems/specifications"]
>
>  Maybe mixing SEPARATOR and ALT_SEPARATOR confuses something inside ruby.
>

Daniel was correct:

irb(main):001:0> p Dir["D:\\Users\\Luis\\.gems/specifications"]
[]
=> nil
irb(main):002:0> p Dir["D:/Users/Luis/.gems/specifications"]
["D:/Users/Luis/.gems/specifications"]

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Tue Mar 25 21:40:07 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 25 Mar 2008 22:40:07 -0300
Subject: [Rubygems-developers] Errors in trunk (for Windows)
In-Reply-To: <D5A5F8D7-A044-4791-A14B-820D7F52C715@segment7.net>
References: <71166b3b0803220832l714e4a43ta75f842abf731e3f@mail.gmail.com>
	<D5A5F8D7-A044-4791-A14B-820D7F52C715@segment7.net>
Message-ID: <71166b3b0803251840i364d4dcen6df60b10405c749f@mail.gmail.com>

On Tue, Mar 25, 2008 at 6:43 PM, Eric Hodel <drbrain at segment7.net> wrote:
> On Mar 22, 2008, at 08:32 AM, Luis Lavena wrote:
>  > Hello Guys,
>  >
>  > I'm still getting the following errors on Windows. These came from gem
>  > commands 'update' and 'install', but both end in the same place of the
>  > "from_yaml" and normalize_yaml_input:
>  >
>  >  1) Error:
>  > test_execute_remote(TestGemCommandsInstallCommand):
>  > NoMethodError: undefined method `size' for nil:NilClass
>  >    ./lib/rubygems/package/tar_reader/entry.rb:84:in `read'
>  >    ./lib/rubygems/specification.rb:609:in `normalize_yaml_input'
>  >    ./lib/rubygems/specification.rb:575:in `from_yaml'
>  >    ./lib/rubygems/package/tar_input.rb:184:in `load_gemspec'
>  >    ./lib/rubygems/package/tar_input.rb:52:in `initialize'
>  >    ./lib/rubygems/package/tar_reader.rb:46:in `each'
>  >    ./lib/rubygems/package/tar_reader.rb:37:in `loop'
>  >    ./lib/rubygems/package/tar_reader.rb:37:in `each'
>  >    ./lib/rubygems/package/tar_input.rb:33:in `initialize'
>  >    ./lib/rubygems/package/tar_input.rb:18:in `new'
>  >    ./lib/rubygems/package/tar_input.rb:18:in `open'
>  > [...]
>
> >
>  > ===
>  >
>  > I exposed this on a previous message, but no one answered.
>  >
>  > To quote myself:
>  >
>  > "Errors 1 and 3 are related to tar_input trying to get #size from a
>  > #read operation over the IO, which returned nil since readed
>  > information was greater than header size:
>  >
>  > lib/rubygems/package/tar_reader/entry.rb:78 (#read):
>  >
>  >   return nil if @read >= @header.size
>  >
>  >
>  > But I cannot determine exactly why this is happening (at least, why
>  > this happens on Windows).
>  > "
>  >
>  > Any ideas?
>
>  It sounds like the gem being extracted has been built wrong.
>

Yes, I was thinkint the same, but couldn't find where the generated
gem is being generated wrongly.

>  When will you be online next so we can confer?
>

I'll be tomorrow all afternoon (is 10.30pm here now).

>  I've finished up the index update changes that were in my tree, so I
>  think this is our last thing to fix.

Since I'm the move from MSVC to MinGW for One-Click Installer is mor
ea reality now than before [1], I'm testing it against these two
platform and report back the current status.

Regards,

[1] http://blog.mmediasys.com/2008/03/24/great-news-from-a-happy-hacking-weekend/

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From drbrain at segment7.net  Tue Mar 25 22:19:59 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 25 Mar 2008 19:19:59 -0700
Subject: [Rubygems-developers] GEM_HOME and GEM_PATH on Windows
In-Reply-To: <71166b3b0803251836w13b72921q8a1c3cd3977df49f@mail.gmail.com>
References: <71166b3b0803232101m11848596h9f3390a2298d9712@mail.gmail.com>
	<6D27D21F-3811-4168-B5D9-8F7B6D519215@segment7.net>
	<71166b3b0803251836w13b72921q8a1c3cd3977df49f@mail.gmail.com>
Message-ID: <BC277CDF-3946-4B57-ADBC-92AEFA4A228F@segment7.net>

On Mar 25, 2008, at 18:36 PM, Luis Lavena wrote:
> On Tue, Mar 25, 2008 at 8:51 PM, Eric Hodel <drbrain at segment7.net>  
> wrote:
>> On Mar 23, 2008, at 21:01 PM, Luis Lavena wrote:
>>> Now, 'gem list' do not find the installed gem, unless I change
>>> GEM_HOME definition to use File::SEPARATOR instead of
>>> File::ALT_SEPARATOR...
>>
>> I wonder, try:
>>
>> p Dir["D:\\Users\\Luis\\.gems/specifications"]
>>
>> vs:
>>
>> p Dir["D:/Users/Luis/.gems/specifications"]
>>
>> Maybe mixing SEPARATOR and ALT_SEPARATOR confuses something inside  
>> ruby.
>>
>
> Daniel was correct:
>
> irb(main):001:0> p Dir["D:\\Users\\Luis\\.gems/specifications"]
> []
> => nil
> irb(main):002:0> p Dir["D:/Users/Luis/.gems/specifications"]
> ["D:/Users/Luis/.gems/specifications"]


Will this patch work?

Index: lib/rubygems.rb
===================================================================
--- lib/rubygems.rb	(revision 1650)
+++ lib/rubygems.rb	(working copy)
@@ -523,6 +521,7 @@ module Gem
    # Set the Gem home directory (as reported by Gem.dir).

    def self.set_home(home)
+    home = home.gsub File::ALT_SEPARATOR, File::SEPARATOR if  
File::ALT_SEPARATOR
      @gem_home = home
      ensure_gem_subdirectories(@gem_home)
    end
@@ -535,6 +534,13 @@ module Gem
    def self.set_paths(gpaths)
      if gpaths
        @gem_path = gpaths.split(File::PATH_SEPARATOR)
+
+      if File::ALT_SEPARATOR then
+        @gem_path.map do |path|
+          path.gsub File::ALT_SEPARATOR, File::SEPARATOR
+        end
+      end
+
        @gem_path << Gem.dir
      else
        @gem_path = [Gem.dir]


From luislavena at gmail.com  Tue Mar 25 23:40:37 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 26 Mar 2008 00:40:37 -0300
Subject: [Rubygems-developers] GEM_HOME and GEM_PATH on Windows
In-Reply-To: <BC277CDF-3946-4B57-ADBC-92AEFA4A228F@segment7.net>
References: <71166b3b0803232101m11848596h9f3390a2298d9712@mail.gmail.com>
	<6D27D21F-3811-4168-B5D9-8F7B6D519215@segment7.net>
	<71166b3b0803251836w13b72921q8a1c3cd3977df49f@mail.gmail.com>
	<BC277CDF-3946-4B57-ADBC-92AEFA4A228F@segment7.net>
Message-ID: <71166b3b0803252040y7371f591t44d14f71b10e2280@mail.gmail.com>

On Tue, Mar 25, 2008 at 11:19 PM, Eric Hodel <drbrain at segment7.net> wrote:
>
>  Will this patch work?
>
>  Index: lib/rubygems.rb
>  ===================================================================
>  --- lib/rubygems.rb     (revision 1650)
>  +++ lib/rubygems.rb     (working copy)
>  @@ -523,6 +521,7 @@ module Gem
>     # Set the Gem home directory (as reported by Gem.dir).
>
>     def self.set_home(home)
>  +    home = home.gsub File::ALT_SEPARATOR, File::SEPARATOR if
>  File::ALT_SEPARATOR
>       @gem_home = home
>       ensure_gem_subdirectories(@gem_home)
>     end
>  @@ -535,6 +534,13 @@ module Gem
>     def self.set_paths(gpaths)
>       if gpaths
>         @gem_path = gpaths.split(File::PATH_SEPARATOR)
>  +
>  +      if File::ALT_SEPARATOR then
>  +        @gem_path.map do |path|
>  +          path.gsub File::ALT_SEPARATOR, File::SEPARATOR
>  +        end
>  +      end
>  +
>         @gem_path << Gem.dir
>       else
>         @gem_path = [Gem.dir]
>
>


@gem_path.map! was needed ;-)

My brain was too busted when I sent the mail to came with a solution :-D

Did commit the fix, thank you.

Now I'm focusing in the Zlib issues, which seems are the root for
TarInput and the malformed gems.

I'll contact you tomorrow.

Thank you again for your time.
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Tue Mar 25 23:52:50 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Tue, 25 Mar 2008 20:52:50 -0700
Subject: [Rubygems-developers] always updating metadata???
Message-ID: <e3af97510803252052g3bf1722esb36bca7de960bed6@mail.gmail.com>

I suspect there are some issues with "updating metadata" for gem
install.  I just waited through an update for 140+ gems (took several
minutes), then about 5 minutes later, I am getting another 140+ gem
update.  it is unlikely this many gems were published in 5 minutes,
isn't it?

Is this an issue with gem mirrors being out of sync?

Thanks,
-- Chad

From assaph at gmail.com  Wed Mar 26 01:13:04 2008
From: assaph at gmail.com (Assaph Mehr)
Date: Wed, 26 Mar 2008 16:13:04 +1100
Subject: [Rubygems-developers] always updating metadata???
In-Reply-To: <e3af97510803252052g3bf1722esb36bca7de960bed6@mail.gmail.com>
References: <e3af97510803252052g3bf1722esb36bca7de960bed6@mail.gmail.com>
Message-ID: <3ff47be90803252213v24547dbcs7e8ce1093df69f@mail.gmail.com>

On Wed, Mar 26, 2008 at 2:52 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> I suspect there are some issues with "updating metadata" for gem
>  install.  I just waited through an update for 140+ gems (took several
>  minutes), then about 5 minutes later, I am getting another 140+ gem
>  update.  it is unlikely this many gems were published in 5 minutes,
>  isn't it?
>
>  Is this an issue with gem mirrors being out of sync?

Silly question: did you do a gem list/search as a regular user
followed by a gem install as sudo? There would be 2 different caches
in this case that will be updated...

HTH, Assaph

From drbrain at segment7.net  Wed Mar 26 06:13:50 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 26 Mar 2008 03:13:50 -0700
Subject: [Rubygems-developers] always updating metadata???
In-Reply-To: <e3af97510803252052g3bf1722esb36bca7de960bed6@mail.gmail.com>
References: <e3af97510803252052g3bf1722esb36bca7de960bed6@mail.gmail.com>
Message-ID: <E9655F58-B799-4D50-B177-CBC3AF64130E@segment7.net>

On Mar 25, 2008, at 20:52 PM, Chad Woolley wrote:
> I suspect there are some issues with "updating metadata" for gem
> install.  I just waited through an update for 140+ gems (took several
> minutes), then about 5 minutes later, I am getting another 140+ gem
> update.  it is unlikely this many gems were published in 5 minutes,
> isn't it?
>
> Is this an issue with gem mirrors being out of sync?

It shouldn't be.

There is an issue with ~ 10 gems that get updated every time, and I  
have a suspected cause for it, but haven't looked into it yet.

I would guess that it's a sudo/non-sudo thing, as that is the only  
time I've noticed it doubling up.

PS:  Did you whip up a patch for the SystemExit thing?

From thewoolleyman at gmail.com  Wed Mar 26 11:13:52 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 26 Mar 2008 08:13:52 -0700
Subject: [Rubygems-developers] always updating metadata???
In-Reply-To: <3ff47be90803252213v24547dbcs7e8ce1093df69f@mail.gmail.com>
References: <e3af97510803252052g3bf1722esb36bca7de960bed6@mail.gmail.com>
	<3ff47be90803252213v24547dbcs7e8ce1093df69f@mail.gmail.com>
Message-ID: <e3af97510803260813n46f46973m2511928c58c623e3@mail.gmail.com>

On Tue, Mar 25, 2008 at 10:13 PM, Assaph Mehr <assaph at gmail.com> wrote:
>  Silly question: did you do a gem list/search as a regular user
>  followed by a gem install as sudo? There would be 2 different caches
>  in this case that will be updated...

Yeah, that's what must have happened.  Thanks.

From luislavena at gmail.com  Thu Mar 27 00:30:14 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 27 Mar 2008 01:30:14 -0300
Subject: [Rubygems-developers] 2 failures away from Heaven
Message-ID: <71166b3b0803262130x17bf816dm401a4e9b4851b5e@mail.gmail.com>

Hello Guys,

Thanks to Eric and his perseverance, we hunted down and killed almost
all the pending errors and failures that stop RubyGems on Windows.

As for now, these are the results (Revision 1652):
ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
585 tests, 1734 assertions, 2 failures, 0 errors

ruby 1.8.6 (2008-03-24 patchlevel 5000) [i386-mingw32]
585 tests, 1740 assertions, 2 failures, 0 errors

Both are failing with the following:

  1) Failure:
test_install_no_wrappers(TestGemDependencyInstaller)
[./test/test_gem_dependency_installer.rb:403]:
</This file was generated by RubyGems./> expected to not match
<"#!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 'a_bin'\n">.

  2) Failure:
test_expand_and_validate_gem_dir(TestGemInstaller)
[./test/test_gem_installer.rb:118]:
<"c:/nonexistent"> expected but was
<"d:/nonexistent">.

==

Based on the assertion count, it seems mingw build is doing some test
mswin32 isn't.... anyway, I'll take another stab to these things
tomorrow at lunch time :-)

FYI: the first is the one related to binaries being changed when they
shouldn't, the second one is just a problem with the location of code,
since I'm not using C:/ drive to hold the code, I'm using D:/

Regards and good night everybody,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Thu Mar 27 03:46:52 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 27 Mar 2008 00:46:52 -0700
Subject: [Rubygems-developers] Explicit 'exit' in InstallCommand#execute
	method causes problems when invoking RubyGems programatically
In-Reply-To: <1063EF59-6121-4F60-9BF6-FFB27DA704FD@segment7.net>
References: <e3af97510803132259h28e217q992728142949b134@mail.gmail.com>
	<1063EF59-6121-4F60-9BF6-FFB27DA704FD@segment7.net>
Message-ID: <e3af97510803270046g7b39146t74e132ac6a3d38b0@mail.gmail.com>

On Fri, Mar 14, 2008 at 6:33 AM, Eric Hodel <drbrain at segment7.net> wrote:
>  I suppose instead an appropriate exception could be raised.  Please
> take a shot at it.

Ticket and patch submitted:

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

-- Chad

From thewoolleyman at gmail.com  Fri Mar 28 01:02:38 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 27 Mar 2008 22:02:38 -0700
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on trunk?
Message-ID: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>

Hi,

For my project, I run CI regression testing against several rubygems
versions, which are embedded in specs fixtures dir:
http://ci.thewoolleyweb.com/

This is all dynamically specified through the cc.rb project name and a
RUBYGEMS_VERSION env var:
http://geminstaller.rubyforge.org/svn/trunk/cruise_config.rb

I would also like to include a SVN external to automatically test
against the latest rubygems trunk (which is nice because cc.rb trunk
now detects svn external checkins).  However, this is difficult since
the rubygems_version.rb on trunk is hardcoded to the version of the
latest release, and for my approach to work, the dir name and rubygems
version must match.

Would you be open to either one of these two options?

1. 'preemptively' increment Gem::RubyGemsVersion after each release,
to have a higher "tiny" component.  For example, the trunk now would
be "1.0.1.1", or "1.0.1.99" or whatever...

or

2. Allow an environment var to be passed, which if set would append
the current trunk revision as the tiny component (and if not set,
would not touch the version).  Something like this (but cleaned
up/extracted):

RubyGemsVersion = '1.0.1' + (ENV['TRUNK_VERSION'] ? '.' + `svn log -q
-rhead http://rubygems.rubyforge.org/svn/trunk`.scan(/r([0-9]*)/).first.first.to_s
: "")

Yeah, I know I can do this myself by rewriting the rubygems_version.rb
file in the external before my CI build kicks off, but it would be
nice to have it built in to RubyGems.

Thanks,
-- Chad

From luislavena at gmail.com  Fri Mar 28 01:03:22 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Mar 2008 02:03:22 -0300
Subject: [Rubygems-developers] Some stats before finishing the day.
Message-ID: <71166b3b0803272203m12ea7bd4s4f04aaee21efc30c@mail.gmail.com>

Just FYI:

Revision 1658:
i386-mswin32: 585 tests, 1741 assertions, 0 failures, 0 errors
i386-mingw32: 585 tests, 1747 assertions, 0 failures, 0 errors

Good night everybody.
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Fri Mar 28 01:27:40 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 27 Mar 2008 22:27:40 -0700
Subject: [Rubygems-developers] Some stats before finishing the day.
In-Reply-To: <71166b3b0803272203m12ea7bd4s4f04aaee21efc30c@mail.gmail.com>
References: <71166b3b0803272203m12ea7bd4s4f04aaee21efc30c@mail.gmail.com>
Message-ID: <e3af97510803272227h12bc656apc9ed659e3410b8f0@mail.gmail.com>

On Thu, Mar 27, 2008 at 10:03 PM, Luis Lavena <luislavena at gmail.com> wrote:
> Just FYI:
>
>  Revision 1658:
>  i386-mswin32: 585 tests, 1741 assertions, 0 failures, 0 errors
>  i386-mingw32: 585 tests, 1747 assertions, 0 failures, 0 errors

Very nice.  Good Job.

From luislavena at gmail.com  Fri Mar 28 01:38:02 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Mar 2008 02:38:02 -0300
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on
	trunk?
In-Reply-To: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
References: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
Message-ID: <71166b3b0803272238g57469b4enf9a5d3163316c8d2@mail.gmail.com>

On Fri, Mar 28, 2008 at 2:02 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> Hi,
>
>  For my project, I run CI regression testing against several rubygems
>  versions, which are embedded in specs fixtures dir:
>  http://ci.thewoolleyweb.com/
>
>  This is all dynamically specified through the cc.rb project name and a
>  RUBYGEMS_VERSION env var:
>  http://geminstaller.rubyforge.org/svn/trunk/cruise_config.rb
>
>  I would also like to include a SVN external to automatically test
>  against the latest rubygems trunk (which is nice because cc.rb trunk
>  now detects svn external checkins).  However, this is difficult since
>  the rubygems_version.rb on trunk is hardcoded to the version of the
>  latest release, and for my approach to work, the dir name and rubygems
>  version must match.
>
>  Would you be open to either one of these two options?
>
>  1. 'preemptively' increment Gem::RubyGemsVersion after each release,
>  to have a higher "tiny" component.  For example, the trunk now would
>  be "1.0.1.1", or "1.0.1.99" or whatever...
>
>  or
>
>  2. Allow an environment var to be passed, which if set would append
>  the current trunk revision as the tiny component (and if not set,
>  would not touch the version).  Something like this (but cleaned
>  up/extracted):
>
>  RubyGemsVersion = '1.0.1' + (ENV['TRUNK_VERSION'] ? '.' + `svn log -q
>  -rhead http://rubygems.rubyforge.org/svn/trunk`.scan(/r([0-9]*)/).first.first.to_s
>  : "")
>

I like the idea, the only thing I don't like is the need for query the
remote repository, but after all, it's getting the information from
there ;-)

>  Yeah, I know I can do this myself by rewriting the rubygems_version.rb
>  file in the external before my CI build kicks off, but it would be
>  nice to have it built in to RubyGems.
>

Lot of projects that provide nightly builds set somehow the "version"
information using some of these techniques...

+1 from me, I like the idea.

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Fri Mar 28 02:18:47 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 27 Mar 2008 23:18:47 -0700
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on
	trunk?
In-Reply-To: <71166b3b0803272238g57469b4enf9a5d3163316c8d2@mail.gmail.com>
References: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
	<71166b3b0803272238g57469b4enf9a5d3163316c8d2@mail.gmail.com>
Message-ID: <e3af97510803272318r532a4595v8b60e217714eae35@mail.gmail.com>

On Thu, Mar 27, 2008 at 10:38 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  I like the idea, the only thing I don't like is the need for query the
>  remote repository, but after all, it's getting the information from
>  there ;-)

Right, it would be smarter to grab it from svn info somehow, since
that is the actual revision you are running (not necessarily the
latest).  However, I stole that code from rails and it was easy to
reuse for the example :)

From thewoolleyman at gmail.com  Fri Mar 28 03:21:50 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 28 Mar 2008 00:21:50 -0700
Subject: [Rubygems-developers] patch to expose method for resetting cache
	file
Message-ID: <e3af97510803280021h790a1f48v3711325f2cd80ffb@mail.gmail.com>

Please consider applying this, or help me understand an alternate approach:

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

Thanks,
-- Chad

From luislavena at gmail.com  Fri Mar 28 09:30:06 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Mar 2008 10:30:06 -0300
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on
	trunk?
In-Reply-To: <e3af97510803272318r532a4595v8b60e217714eae35@mail.gmail.com>
References: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
	<71166b3b0803272238g57469b4enf9a5d3163316c8d2@mail.gmail.com>
	<e3af97510803272318r532a4595v8b60e217714eae35@mail.gmail.com>
Message-ID: <71166b3b0803280630j5eaa083bh4bbd47c906ef4354@mail.gmail.com>

On Fri, Mar 28, 2008 at 3:18 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Thu, Mar 27, 2008 at 10:38 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  >  I like the idea, the only thing I don't like is the need for query the
>  >  remote repository, but after all, it's getting the information from
>  >  there ;-)
>
>  Right, it would be smarter to grab it from svn info somehow, since
>  that is the actual revision you are running (not necessarily the
>  latest).  However, I stole that code from rails and it was easy to
>  reuse for the example :)
>

Hehe, I'm my case that would work since I'm running from a bazaar
checkout and svn will not get information about it :-P
The same thing could happen for those running other any other vcs on
top of the rubyforge svn repository.

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Fri Mar 28 09:44:33 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 28 Mar 2008 06:44:33 -0700
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on
	trunk?
In-Reply-To: <71166b3b0803280630j5eaa083bh4bbd47c906ef4354@mail.gmail.com>
References: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
	<71166b3b0803272238g57469b4enf9a5d3163316c8d2@mail.gmail.com>
	<e3af97510803272318r532a4595v8b60e217714eae35@mail.gmail.com>
	<71166b3b0803280630j5eaa083bh4bbd47c906ef4354@mail.gmail.com>
Message-ID: <e3af97510803280644l7c1cb0acr658f566ae027b144@mail.gmail.com>

On Fri, Mar 28, 2008 at 6:30 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  Hehe, I'm my case that would work since I'm running from a bazaar
>  checkout and svn will not get information about it :-P
>  The same thing could happen for those running other any other vcs on
>  top of the rubyforge svn repository.

Well, it would only be used if you set that env var anyway.  By
default, the code would never get hit.

From luislavena at gmail.com  Fri Mar 28 09:59:31 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Mar 2008 10:59:31 -0300
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on
	trunk?
In-Reply-To: <e3af97510803280644l7c1cb0acr658f566ae027b144@mail.gmail.com>
References: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
	<71166b3b0803272238g57469b4enf9a5d3163316c8d2@mail.gmail.com>
	<e3af97510803272318r532a4595v8b60e217714eae35@mail.gmail.com>
	<71166b3b0803280630j5eaa083bh4bbd47c906ef4354@mail.gmail.com>
	<e3af97510803280644l7c1cb0acr658f566ae027b144@mail.gmail.com>
Message-ID: <71166b3b0803280659h6004a554kd5b8bd3b0230dd6c@mail.gmail.com>

On Fri, Mar 28, 2008 at 10:44 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Fri, Mar 28, 2008 at 6:30 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  >  Hehe, I'm my case that would work since I'm running from a bazaar
>  >  checkout and svn will not get information about it :-P
>  >  The same thing could happen for those running other any other vcs on
>  >  top of the rubyforge svn repository.
>
>  Well, it would only be used if you set that env var anyway.  By
>  default, the code would never get hit.
>

I know, but is useless generate packages between builds without that
environment variable set.
(like nightly builds?)

BTW, are you testing GemInstaller on Windows? ;-)

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From jftucker at gmail.com  Fri Mar 28 10:10:07 2008
From: jftucker at gmail.com (James Tucker)
Date: Fri, 28 Mar 2008 14:10:07 +0000
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on
	trunk?
In-Reply-To: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
References: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
Message-ID: <4F829574-1A19-4F90-B8EC-3A5DCE3B6CC5@gmail.com>


On 28 Mar 2008, at 05:02, Chad Woolley wrote:
> Hi,
>
> For my project, I run CI regression testing against several rubygems
> versions, which are embedded in specs fixtures dir:
> http://ci.thewoolleyweb.com/
>
> This is all dynamically specified through the cc.rb project name and a
> RUBYGEMS_VERSION env var:
> http://geminstaller.rubyforge.org/svn/trunk/cruise_config.rb
>
> I would also like to include a SVN external to automatically test
> against the latest rubygems trunk (which is nice because cc.rb trunk
> now detects svn external checkins).  However, this is difficult since
> the rubygems_version.rb on trunk is hardcoded to the version of the
> latest release, and for my approach to work, the dir name and rubygems
> version must match.
>
> Would you be open to either one of these two options?
>
> 1. 'preemptively' increment Gem::RubyGemsVersion after each release,
> to have a higher "tiny" component.  For example, the trunk now would
> be "1.0.1.1", or "1.0.1.99" or whatever...
>
> or
>
> 2. Allow an environment var to be passed, which if set would append
> the current trunk revision as the tiny component (and if not set,
> would not touch the version).  Something like this (but cleaned
> up/extracted):
>
> RubyGemsVersion = '1.0.1' + (ENV['TRUNK_VERSION'] ? '.' + `svn log -q
> -rhead http://rubygems.rubyforge.org/svn/trunk`.scan(/ 
> r([0-9]*)/).first.first.to_s
> : "")
>
> Yeah, I know I can do this myself by rewriting the rubygems_version.rb
> file in the external before my CI build kicks off, but it would be
> nice to have it built in to RubyGems.

I've had to do something similar for a number of projects where I have  
submitted patches which have not reached the release cycle yet. When  
the original authors are too busy, and we need the patch, the only  
sensible way I have found is to have some patch details, or just add  
another version number on to the end of the version set.

Example:

gem list --remote analogger
...
analogger (0.5.0)

gem list --local analogger
...
analogger (0.5.0.1)


Now this is 'ok' until the author replaces their versioning style or  
something similar.

The generic problem though, is how to deploy 'local patches' or 'local  
versions'. I'm seriously considering doing this with any future  
releases of my own, having the last section of the version number  
always at 0 for official releases, so that users can specify their own  
patches with versions there, or use versions from committed patches  
straight from a repo.


> Thanks,
> -- Chad
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From thewoolleyman at gmail.com  Fri Mar 28 11:27:46 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 28 Mar 2008 08:27:46 -0700
Subject: [Rubygems-developers] GemInstaller on Windows (was: Incrementing
	Gem::RubyGemsVersion on trunk?)
Message-ID: <e3af97510803280827x7b42f8a7xbea07e14546c00d9@mail.gmail.com>

On Fri, Mar 28, 2008 at 6:59 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  BTW, are you testing GemInstaller on Windows? ;-)

Yes, however, it keeps breaking - I don't have CI running on trunk,
which is the point of the original thread.  Currently trying to get
the test suite to pass again against trunk (it was passing on 1.0.1),
I hope soon.  I think your recent windows RubyGems patches have helped
:)

-- Chad

From luislavena at gmail.com  Fri Mar 28 11:32:47 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Mar 2008 12:32:47 -0300
Subject: [Rubygems-developers] GemInstaller on Windows (was:
	Incrementing Gem::RubyGemsVersion on trunk?)
In-Reply-To: <e3af97510803280827x7b42f8a7xbea07e14546c00d9@mail.gmail.com>
References: <e3af97510803280827x7b42f8a7xbea07e14546c00d9@mail.gmail.com>
Message-ID: <71166b3b0803280832i43ea3431n21485240be01fd0d@mail.gmail.com>

On Fri, Mar 28, 2008 at 12:27 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Fri, Mar 28, 2008 at 6:59 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  >  BTW, are you testing GemInstaller on Windows? ;-)
>
>  Yes, however, it keeps breaking - I don't have CI running on trunk,
>  which is the point of the original thread.  Currently trying to get
>  the test suite to pass again against trunk (it was passing on 1.0.1),
>  I hope soon.  I think your recent windows RubyGems patches have helped
>  :)
>

Don't have time in my hands right now, but I'm adding this to my TODO
list so working the weekend on the CI can put GemInstaller to work.

<off-topic>
What will be great is a UI on top of RubyGems, maybe using something
like wxRuby or FXRuby ;-)

Something like Netbeans did, but more ruby-like :-)

Can GemInstaller simplify it and user as backend layer instead of
direct access to rubygems?
</off-topic>

Regards,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From hgs at dmu.ac.uk  Fri Mar 28 11:45:08 2008
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Fri, 28 Mar 2008 15:45:08 +0000 (WET)
Subject: [Rubygems-developers] GemInstaller on Windows (was:
 Incrementing Gem::RubyGemsVersion on trunk?)
In-Reply-To: <71166b3b0803280832i43ea3431n21485240be01fd0d@mail.gmail.com>
References: <e3af97510803280827x7b42f8a7xbea07e14546c00d9@mail.gmail.com>
	<71166b3b0803280832i43ea3431n21485240be01fd0d@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0803281541230.10469@brains.eng.cse.dmu.ac.uk>

On Fri, 28 Mar 2008, Luis Lavena wrote:

> <off-topic>
> What will be great is a UI on top of RubyGems, maybe using something
> like wxRuby or FXRuby ;-)
> 
> Something like Netbeans did, but more ruby-like :-)

But _ Nobody Knows Shoes _ so we're a bit stuck :-)
http://code.whytheluckystiff.net/shoes/
> 
> Can GemInstaller simplify it and user as backend layer instead of
> direct access to rubygems?
> </off-topic>

        Hugh

From luislavena at gmail.com  Fri Mar 28 11:58:30 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Mar 2008 12:58:30 -0300
Subject: [Rubygems-developers] GemInstaller on Windows (was:
	Incrementing Gem::RubyGemsVersion on trunk?)
In-Reply-To: <Pine.GSO.4.64.0803281541230.10469@brains.eng.cse.dmu.ac.uk>
References: <e3af97510803280827x7b42f8a7xbea07e14546c00d9@mail.gmail.com>
	<71166b3b0803280832i43ea3431n21485240be01fd0d@mail.gmail.com>
	<Pine.GSO.4.64.0803281541230.10469@brains.eng.cse.dmu.ac.uk>
Message-ID: <71166b3b0803280858y23d8ae45n6aa8fd4cd4394e20@mail.gmail.com>

On Fri, Mar 28, 2008 at 12:45 PM, Hugh Sasse <hgs at dmu.ac.uk> wrote:
> On Fri, 28 Mar 2008, Luis Lavena wrote:
>
>  > <off-topic>
>  > What will be great is a UI on top of RubyGems, maybe using something
>  > like wxRuby or FXRuby ;-)
>  >
>  > Something like Netbeans did, but more ruby-like :-)
>
>  But _ Nobody Knows Shoes _ so we're a bit stuck :-)
>  http://code.whytheluckystiff.net/shoes/
>

Shoes is great, but it uses a custom build ruby, so could present some
issues installing gems or even managing them.

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From hgs at dmu.ac.uk  Fri Mar 28 12:09:56 2008
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Fri, 28 Mar 2008 16:09:56 +0000 (WET)
Subject: [Rubygems-developers] GemInstaller on Windows (was:
 Incrementing Gem::RubyGemsVersion on trunk?)
In-Reply-To: <71166b3b0803280858y23d8ae45n6aa8fd4cd4394e20@mail.gmail.com>
References: <e3af97510803280827x7b42f8a7xbea07e14546c00d9@mail.gmail.com>
	<71166b3b0803280832i43ea3431n21485240be01fd0d@mail.gmail.com>
	<Pine.GSO.4.64.0803281541230.10469@brains.eng.cse.dmu.ac.uk>
	<71166b3b0803280858y23d8ae45n6aa8fd4cd4394e20@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0803281607370.10469@brains.eng.cse.dmu.ac.uk>

On Fri, 28 Mar 2008, Luis Lavena wrote:

> On Fri, Mar 28, 2008 at 12:45 PM, Hugh Sasse <hgs at dmu.ac.uk> wrote:
> > On Fri, 28 Mar 2008, Luis Lavena wrote:
> >
> >  > <off-topic>
> >  > What will be great is a UI on top of RubyGems, maybe using something
> >  > like wxRuby or FXRuby ;-)
> >  >
> >  > Something like Netbeans did, but more ruby-like :-)
> >
> >  But _ Nobody Knows Shoes _ so we're a bit stuck :-)
> >  http://code.whytheluckystiff.net/shoes/
> >
> 
> Shoes is great, but it uses a custom build ruby, so could present some
> issues installing gems or even managing them.

One could use it as a wrapper calling scripts %x{...} perhaps.

Anyway, I agree there are problems,as I'm having them for cygwin's
Ruby and perl stuff called from it.

        Hugh



From thewoolleyman at gmail.com  Fri Mar 28 12:14:38 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 28 Mar 2008 09:14:38 -0700
Subject: [Rubygems-developers] GemInstaller on Windows (was:
	Incrementing Gem::RubyGemsVersion on trunk?)
In-Reply-To: <71166b3b0803280832i43ea3431n21485240be01fd0d@mail.gmail.com>
References: <e3af97510803280827x7b42f8a7xbea07e14546c00d9@mail.gmail.com>
	<71166b3b0803280832i43ea3431n21485240be01fd0d@mail.gmail.com>
Message-ID: <e3af97510803280914n6adf4deajcafda3568e0abc75@mail.gmail.com>

On Fri, Mar 28, 2008 at 8:32 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  <off-topic>
>  What will be great is a UI on top of RubyGems, maybe using something
>  like wxRuby or FXRuby ;-)
>
>  Something like Netbeans did, but more ruby-like :-)
>
>  Can GemInstaller simplify it and user as backend layer instead of
>  direct access to rubygems?
>  </off-topic>

Yes, and this is one of my eventual goals (to make it pluggable).  I
wrote it from scratch with a BDD and Dependency Injection approach, so
hopefully it is loosely coupled and easy to allow a GUI or IDE
integration instead of a CLI, without changing the underlying logic.

From ryand-ruby at zenspider.com  Fri Mar 28 17:07:05 2008
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Fri, 28 Mar 2008 14:07:05 -0700
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on
	trunk?
In-Reply-To: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
References: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
Message-ID: <470C9550-5346-4C7C-90CD-EA8AA51CB2BC@zenspider.com>


On Mar 27, 2008, at 22:02 , Chad Woolley wrote:
> RubyGemsVersion = '1.0.1' + (ENV['TRUNK_VERSION'] ? '.' + `svn log -q
> -rhead http://rubygems.rubyforge.org/svn/trunk`.scan(/ 
> r([0-9]*)/).first.first.to_s
> : "")

`svnversion .`.chomp


From luislavena at gmail.com  Fri Mar 28 17:12:20 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 28 Mar 2008 18:12:20 -0300
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on
	trunk?
In-Reply-To: <470C9550-5346-4C7C-90CD-EA8AA51CB2BC@zenspider.com>
References: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
	<470C9550-5346-4C7C-90CD-EA8AA51CB2BC@zenspider.com>
Message-ID: <71166b3b0803281412k6fdbc477kffd53cdb20b3b93f@mail.gmail.com>

On Fri, Mar 28, 2008 at 6:07 PM, Ryan Davis <ryand-ruby at zenspider.com> wrote:
>
>  On Mar 27, 2008, at 22:02 , Chad Woolley wrote:
>  > RubyGemsVersion = '1.0.1' + (ENV['TRUNK_VERSION'] ? '.' + `svn log -q
>  > -rhead http://rubygems.rubyforge.org/svn/trunk`.scan(/
>  > r([0-9]*)/).first.first.to_s
>  > : "")
>
>  `svnversion .`.chomp
>

That wouldn't work for at least me :-P
and svnversion do not accept remote URLs

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Sat Mar 29 00:55:51 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 28 Mar 2008 21:55:51 -0700
Subject: [Rubygems-developers] always updating metadata???
In-Reply-To: <e3af97510803260813n46f46973m2511928c58c623e3@mail.gmail.com>
References: <e3af97510803252052g3bf1722esb36bca7de960bed6@mail.gmail.com>
	<3ff47be90803252213v24547dbcs7e8ce1093df69f@mail.gmail.com>
	<e3af97510803260813n46f46973m2511928c58c623e3@mail.gmail.com>
Message-ID: <e3af97510803282155h72e819r237de9bbeb585661@mail.gmail.com>

On Wed, Mar 26, 2008 at 8:13 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Tue, Mar 25, 2008 at 10:13 PM, Assaph Mehr <assaph at gmail.com> wrote:
>  >  Silly question: did you do a gem list/search as a regular user
>  >  followed by a gem install as sudo? There would be 2 different caches
>  >  in this case that will be updated...
>
>  Yeah, that's what must have happened.  Thanks.
>

I'm still seeing wierdness here.  First of all, when I do a remote
list for capistrano on rubyforge, I only find cap 2.2.0.  I know there
was a 2.0.0 and 2.1.0, but it is not shown.

Also, it keeps updating the cache over and over when there is a
failure to find a gem, even with the same user.

This is on default Leopard ruby install, I'm pretty sure with a gem
update --system to 1.0.1, but I might have installed a recent trunk
with setup and forgot about it.

Probably just something with my system, but thought I'd report it anyway.

From thewoolleyman at gmail.com  Sat Mar 29 01:10:10 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 28 Mar 2008 22:10:10 -0700
Subject: [Rubygems-developers] always updating metadata???
In-Reply-To: <e3af97510803282155h72e819r237de9bbeb585661@mail.gmail.com>
References: <e3af97510803252052g3bf1722esb36bca7de960bed6@mail.gmail.com>
	<3ff47be90803252213v24547dbcs7e8ce1093df69f@mail.gmail.com>
	<e3af97510803260813n46f46973m2511928c58c623e3@mail.gmail.com>
	<e3af97510803282155h72e819r237de9bbeb585661@mail.gmail.com>
Message-ID: <e3af97510803282210r3895fc9fj4d40a8d038c1fbb2@mail.gmail.com>

On Fri, Mar 28, 2008 at 9:55 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>  I'm still seeing wierdness here.  First of all, when I do a remote
>  list for capistrano on rubyforge, I only find cap 2.2.0.  I know there
>  was a 2.0.0 and 2.1.0, but it is not shown.
>
>  Also, it keeps updating the cache over and over when there is a
>  failure to find a gem, even with the same user.
>
>  This is on default Leopard ruby install, I'm pretty sure with a gem
>  update --system to 1.0.1, but I might have installed a recent trunk
>  with setup and forgot about it.

Update - this was definitely with trunk installed (after recent
caching changes), and definitely was fixed by reinstalling 1.0.1 from
setup.rb.  I didn't have to manually blow away ~/.gem, just
reinstalling 1.0.1 fixed it.

From drbrain at segment7.net  Sat Mar 29 01:44:12 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Fri, 28 Mar 2008 22:44:12 -0700
Subject: [Rubygems-developers] always updating metadata???
In-Reply-To: <e3af97510803282210r3895fc9fj4d40a8d038c1fbb2@mail.gmail.com>
References: <e3af97510803252052g3bf1722esb36bca7de960bed6@mail.gmail.com>
	<3ff47be90803252213v24547dbcs7e8ce1093df69f@mail.gmail.com>
	<e3af97510803260813n46f46973m2511928c58c623e3@mail.gmail.com>
	<e3af97510803282155h72e819r237de9bbeb585661@mail.gmail.com>
	<e3af97510803282210r3895fc9fj4d40a8d038c1fbb2@mail.gmail.com>
Message-ID: <C6FC8F5B-30BB-4E57-9E68-7BAE516F5E04@segment7.net>

On Mar 28, 2008, at 22:10 PM, Chad Woolley wrote:
> On Fri, Mar 28, 2008 at 9:55 PM, Chad Woolley  
> <thewoolleyman at gmail.com> wrote:
>> I'm still seeing wierdness here.  First of all, when I do a remote
>> list for capistrano on rubyforge, I only find cap 2.2.0.  I know  
>> there
>> was a 2.0.0 and 2.1.0, but it is not shown.

Nope.  `gem list -r --all cap`  to force a bulk update.

99% of the time you don't care about anything other than the latest,  
so RubyGems will no longer keep up to date for past revisions.

If you want to install a particular version, RubyGems will go looking  
for it.  (This could now be made even smarter, but I currently lack  
the energy.)

>> Also, it keeps updating the cache over and over when there is a
>> failure to find a gem, even with the same user.
>>
>> This is on default Leopard ruby install, I'm pretty sure with a gem
>> update --system to 1.0.1, but I might have installed a recent trunk
>> with setup and forgot about it.
>
> Update - this was definitely with trunk installed (after recent
> caching changes), and definitely was fixed by reinstalling 1.0.1 from
> setup.rb.  I didn't have to manually blow away ~/.gem, just
> reinstalling 1.0.1 fixed it.

I just fixed the last bug with the quick/latest index code.  It seems  
to be ok now.

From luislavena at gmail.com  Sat Mar 29 06:46:02 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 29 Mar 2008 07:46:02 -0300
Subject: [Rubygems-developers] Stats from Revision 1676
Message-ID: <71166b3b0803290346n59a8dadyedbb36fdc25b2b07@mail.gmail.com>

ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
591 tests, 1759 assertions, 1 failures, 0 errors

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

ruby 1.8.6 (2008-03-24 patchlevel 5000) [i386-mingw32]
591 tests, 1766 assertions, 0 failures, 0 errors

Maybe I should set the CI to send mails to this mailing list? at least
considering these platforms (and the lack of knowing the RubyGems
release schedule) :-D

Anyway, damage is done, let hope we don't chat too many gems uisng
rakefiles for their extensions ;-)
(at least not until we get mingw as official One-Click Installer).

Regards,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From djberg96 at gmail.com  Sat Mar 29 08:14:56 2008
From: djberg96 at gmail.com (Daniel Berger)
Date: Sat, 29 Mar 2008 06:14:56 -0600
Subject: [Rubygems-developers] 1.1.0 upgrade failure on Windows
Message-ID: <6037b70c0803290514vb1fe12ch801714c85291cefb@mail.gmail.com>

Ruby 1.8.6
Windows XP

C:\Documents and Settings\djberge>gem update --system
JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
Updating RubyGems...
Attempting remote update of rubygems-update
Successfully installed rubygems-update-1.1.0
1 gem installed
Updating version of RubyGems to 1.1.0
Installing RubyGems 1.1.0
'RUBYOPT' is not recognized as an internal or external command,
operable program or batch file.

C:\Documents and Settings\djberge>gem -v
1.0.1

RUBYOPT is an environment variable, yes? What's it trying to run?

Regards,

Dan

From luislavena at gmail.com  Sat Mar 29 08:25:57 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 29 Mar 2008 09:25:57 -0300
Subject: [Rubygems-developers] 1.1.0 upgrade failure on Windows
In-Reply-To: <6037b70c0803290514vb1fe12ch801714c85291cefb@mail.gmail.com>
References: <6037b70c0803290514vb1fe12ch801714c85291cefb@mail.gmail.com>
Message-ID: <71166b3b0803290525g46e701c1t1b7a47d1f46f6177@mail.gmail.com>

On Sat, Mar 29, 2008 at 9:14 AM, Daniel Berger <djberg96 at gmail.com> wrote:
> Ruby 1.8.6
>  Windows XP
>
>  C:\Documents and Settings\djberge>gem update --system
>  JRuby limited openssl loaded. gem install jruby-openssl for full support.
>  http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
>  Updating RubyGems...
>  Attempting remote update of rubygems-update
>  Successfully installed rubygems-update-1.1.0
>  1 gem installed
>  Updating version of RubyGems to 1.1.0
>  Installing RubyGems 1.1.0
>  'RUBYOPT' is not recognized as an internal or external command,
>  operable program or batch file.
>
>  C:\Documents and Settings\djberge>gem -v
>  1.0.1
>
>  RUBYOPT is an environment variable, yes? What's it trying to run?
>
>  Regards,
>

I didn't get the output you got:

ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]

D:\Users\Luis>set RUBYOPT=rubygems

D:\Users\Luis>gem -v
1.0.1

D:\Users\Luis>gem update --system --no-ri --no-rdoc
Updating RubyGems...
Updating metadata for 75 gems from http://gems.rubyforge.org
...........................................................................
complete
Attempting remote update of rubygems-update
Successfully installed rubygems-update-1.1.0
1 gem installed
Updating version of RubyGems to 1.1.0
Installing RubyGems 1.1.0
(zillions of install lines here)

Removing old RubyGems RDoc and ri
As of RubyGems 0.8.0, library stubs are no longer needed.
Searching $LOAD_PATH for stubs to optionally delete (may take a while)
...done.
No library stubs found.

------------------------------------------------------------------------------

Oh-no! Unable to find release notes in:
        doc/release_notes/rel_1_1_0.rdoc

------------------------------------------------------------------------------

RubyGems installed the following executables:
        C:/Ruby/bin/gem

If `gem` was installed by a previous RubyGems installation, you may need
to remove it by hand.

RubyGems system software updated

D:\Users\Luis>gem -v
1.1.0

===

It sounds like you're running Jruby version of gem instead of what you
states, Ruby 1.8.6
I don't have jRuby version at hand to test it. Sorry

Regards,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From djberg96 at gmail.com  Sat Mar 29 08:33:01 2008
From: djberg96 at gmail.com (Daniel Berger)
Date: Sat, 29 Mar 2008 06:33:01 -0600
Subject: [Rubygems-developers] 1.1.0 upgrade failure on Windows
In-Reply-To: <71166b3b0803290525g46e701c1t1b7a47d1f46f6177@mail.gmail.com>
References: <6037b70c0803290514vb1fe12ch801714c85291cefb@mail.gmail.com>
	<71166b3b0803290525g46e701c1t1b7a47d1f46f6177@mail.gmail.com>
Message-ID: <6037b70c0803290533l5c1b63f7u2a4b5acc345e166f@mail.gmail.com>

On Sat, Mar 29, 2008 at 6:25 AM, Luis Lavena <luislavena at gmail.com> wrote:
>
> On Sat, Mar 29, 2008 at 9:14 AM, Daniel Berger <djberg96 at gmail.com> wrote:
>  > Ruby 1.8.6
>  >  Windows XP
>  >
>  >  C:\Documents and Settings\djberge>gem update --system
>  >  JRuby limited openssl loaded. gem install jruby-openssl for full support.
>  >  http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
>  >  Updating RubyGems...
>  >  Attempting remote update of rubygems-update
>  >  Successfully installed rubygems-update-1.1.0
>  >  1 gem installed
>  >  Updating version of RubyGems to 1.1.0
>  >  Installing RubyGems 1.1.0
>  >  'RUBYOPT' is not recognized as an internal or external command,
>  >  operable program or batch file.
>  >
>  >  C:\Documents and Settings\djberge>gem -v
>  >  1.0.1
>  >
>  >  RUBYOPT is an environment variable, yes? What's it trying to run?
>  >
>  >  Regards,
>  >
>
>  I didn't get the output you got:
>
>  ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
>
>  D:\Users\Luis>set RUBYOPT=rubygems
>
>  D:\Users\Luis>gem -v
>  1.0.1
>
>  D:\Users\Luis>gem update --system --no-ri --no-rdoc
>  Updating RubyGems...
>  Updating metadata for 75 gems from http://gems.rubyforge.org
>  ...........................................................................
>  complete
>
> Attempting remote update of rubygems-update
>  Successfully installed rubygems-update-1.1.0
>  1 gem installed
>  Updating version of RubyGems to 1.1.0
>  Installing RubyGems 1.1.0
>  (zillions of install lines here)
>
>  Removing old RubyGems RDoc and ri
>  As of RubyGems 0.8.0, library stubs are no longer needed.
>  Searching $LOAD_PATH for stubs to optionally delete (may take a while)
>  ...done.
>  No library stubs found.
>
>  ------------------------------------------------------------------------------
>
>  Oh-no! Unable to find release notes in:
>         doc/release_notes/rel_1_1_0.rdoc
>
>  ------------------------------------------------------------------------------
>
>  RubyGems installed the following executables:
>         C:/Ruby/bin/gem
>
>  If `gem` was installed by a previous RubyGems installation, you may need
>  to remove it by hand.
>
>  RubyGems system software updated
>
>  D:\Users\Luis>gem -v
>  1.1.0
>
>  ===
>
>  It sounds like you're running Jruby version of gem instead of what you
>  states, Ruby 1.8.6
>  I don't have jRuby version at hand to test it. Sorry

<snip>

Oh, wow, you're right. That's weird, because it's not first in my
PATH. When I did an explicit "C:\ruby\bin\gem update --system" then it
worked fine.

I must have messed up my environment somehow. Sorry for the noise.

Regards,

Dan

From luislavena at gmail.com  Sat Mar 29 08:39:55 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 29 Mar 2008 09:39:55 -0300
Subject: [Rubygems-developers] 1.1.0 upgrade failure on Windows
In-Reply-To: <6037b70c0803290533l5c1b63f7u2a4b5acc345e166f@mail.gmail.com>
References: <6037b70c0803290514vb1fe12ch801714c85291cefb@mail.gmail.com>
	<71166b3b0803290525g46e701c1t1b7a47d1f46f6177@mail.gmail.com>
	<6037b70c0803290533l5c1b63f7u2a4b5acc345e166f@mail.gmail.com>
Message-ID: <71166b3b0803290539x27d19f6arb5b91bc3d5eb3013@mail.gmail.com>

On Sat, Mar 29, 2008 at 9:33 AM, Daniel Berger <djberg96 at gmail.com> wrote:
>
>  Oh, wow, you're right. That's weird, because it's not first in my
>  PATH. When I did an explicit "C:\ruby\bin\gem update --system" then it
>  worked fine.
>
>  I must have messed up my environment somehow. Sorry for the noise.
>

No problem Dan, I had several reports of jruby interfering with
RubyGems and MRI for One-Click, some of them using jruby behind
netbeans without noticing it! :-P

Have a nice weekend,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Sat Mar 29 11:11:53 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sat, 29 Mar 2008 08:11:53 -0700
Subject: [Rubygems-developers] Stats from Revision 1676
In-Reply-To: <71166b3b0803290346n59a8dadyedbb36fdc25b2b07@mail.gmail.com>
References: <71166b3b0803290346n59a8dadyedbb36fdc25b2b07@mail.gmail.com>
Message-ID: <e3af97510803290811j1cdf0184o6b110fd21f5202bf@mail.gmail.com>

On Sat, Mar 29, 2008 at 3:46 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  Maybe I should set the CI to send mails to this mailing list? at least
>  considering these platforms (and the lack of knowing the RubyGems
>  release schedule) :-D

Definitely +1, for both windows and unix.  Put a descriptive prefix on
the subject, so if people don't like it they can filter.

From luislavena at gmail.com  Sat Mar 29 14:31:17 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 29 Mar 2008 15:31:17 -0300
Subject: [Rubygems-developers] Stats from Revision 1676
In-Reply-To: <e3af97510803290811j1cdf0184o6b110fd21f5202bf@mail.gmail.com>
References: <71166b3b0803290346n59a8dadyedbb36fdc25b2b07@mail.gmail.com>
	<e3af97510803290811j1cdf0184o6b110fd21f5202bf@mail.gmail.com>
Message-ID: <71166b3b0803291131x337b68d8m63c48aa360774d4c@mail.gmail.com>

On Sat, Mar 29, 2008 at 12:11 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Sat, Mar 29, 2008 at 3:46 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  >  Maybe I should set the CI to send mails to this mailing list? at least
>  >  considering these platforms (and the lack of knowing the RubyGems
>  >  release schedule) :-D
>
>  Definitely +1, for both windows and unix.  Put a descriptive prefix on
>  the subject, so if people don't like it they can filter.

I was waiting to set this on our x64 Windows box, but still no time to
set it properly.
Will add to our existing x86 box and let it run i386-mswin32 and i386-mingw32

For the linux/*nix setup, I'll see if I could get freebsd running, or
at least Ubuntu JeOS inside VirtualBox.

Good weekend everybody,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Sun Mar 30 06:25:54 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 30 Mar 2008 07:25:54 -0300
Subject: [Rubygems-developers] [CI] Latest RubyGems build results (r1680)
Message-ID: <71166b3b0803300325n44340602g6be4ccef249d4d24@mail.gmail.com>

ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]

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

589 tests, 1757 assertions, 1 failures, 0 errors

===

ruby 1.8.6 (2008-03-24 patchlevel 5000) [i386-mingw32]

589 tests, 1764 assertions, 0 failures, 0 errors

===

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Sun Mar 30 11:19:50 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 30 Mar 2008 12:19:50 -0300
Subject: [Rubygems-developers] Errno::ECONNABORTED was lost between commits
Message-ID: <71166b3b0803300819s43b1125y5bcfd89cfc988ed4@mail.gmail.com>

Hello list,

Is highly likely i forgot to commit this "piece of work" to remote_fetcher.

Basically is a workaround on Windows when remote connections are been
closed because they don't support or want Keep-Alive mode.

During installation on big gems you find this problem.

--- lib/rubygems/remote_fetcher.rb      2008-03-28 22:46:51 +0000
+++ lib/rubygems/remote_fetcher.rb      2008-03-30 15:13:21 +0000
@@ -236,11 +236,13 @@
       request.add_field 'Keep-Alive', '30'

       # HACK work around EOFError bug in Net::HTTP
+      # NOTE Errno::ECONNABORTED raised a lot on Windows, and make impossible
+      # to install gems.
       retried = false
       begin
         @requests[connection_id] += 1
         response = connection.request(request)
-      rescue EOFError
+      rescue EOFError, Errno::ECONNABORTED
         requests = @requests[connection_id]
         say "connection reset after #{requests} requests, retrying" if
           Gem.configuration.really_verbose

I've committed this change.

BTW, what is the RubyGems release schedule? I keep asking it, but it
seems there isn't one :-P

Good weekend everybody,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From aslak.hellesoy at gmail.com  Sun Mar 30 12:03:48 2008
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 30 Mar 2008 18:03:48 +0200
Subject: [Rubygems-developers] published platform-specific gem not downloaded
Message-ID: <8d961d900803300903h7f0ed770r57dca7bbc1144f24@mail.gmail.com>

Hi,

I just published a generic and platform specific gem:
http://rubyforge.org/frs/?group_id=5920
It looks like the gems have replicated around the net:
http://rubyforge.iasi.roedu.net/gems/

When I do gem install ruby-usb on a Windows box, Rubygems seems to
download ruby-usb-0.1.2.gem and not ruby-usb-0.1.2-x86-mswin32.gem

This happens for both rubygems 1.0.1 and 1.1.0 (which I just updated to).

If I download ruby-usb-0.1.2-x86-mswin32.gem manually and install it
everything looks fine. Can anyone tell me how to fix this? The Windows
gemspec looks like the following:

Gem::Specification.new do |s|
  s.name = %q{ruby-usb}
  s.version = "0.1.2"
  s.platform = %q{mswin32}

  s.specification_version = 2 if s.respond_to? :specification_version=

  s.required_rubygems_version = Gem::Requirement.new(">= 0") if
s.respond_to? :required_rubygems_version=
  s.authors = ["Aslak Helles\303\270y", "Tanaka Akira"]
  s.date = %q{2008-03-29}
  s.description = %q{ruby-usb is a libusb binding library for Ruby.}
  s.email = ["aslak.hellesoy at gmail.com", "akr at fsij.org"]
  s.extra_rdoc_files = ["History.txt", "Manifest.txt", "README.txt"]
  s.files = ["COPYING", "History.txt", "Manifest.txt", "README.txt",
"README.win32", "Rakefile", "ext/constants.h", "ext/extconf.rb",
"ext/usb.c", "lib/usb.rb", "sample/usb-power", "ext/usb.so"]
  s.has_rdoc = true
  s.homepage = %q{http://www.a-k-r.org/ruby-usb/}
  s.rdoc_options = ["--main", "README.txt"]
  s.require_paths = ["lib", "ext"]
  s.rubyforge_project = %q{ruby-usb}
  s.rubygems_version = %q{1.0.1}
  s.summary = %q{Tanaka Akira's ruby-usb packaged as gems}
end

P.S. My first upload of the Windows gem was broken, so I deleted it
and uploaded it again. Can that be the culplrit?

Aslak

From luislavena at gmail.com  Sun Mar 30 12:11:17 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 30 Mar 2008 13:11:17 -0300
Subject: [Rubygems-developers] published platform-specific gem not
	downloaded
In-Reply-To: <8d961d900803300903h7f0ed770r57dca7bbc1144f24@mail.gmail.com>
References: <8d961d900803300903h7f0ed770r57dca7bbc1144f24@mail.gmail.com>
Message-ID: <71166b3b0803300911y1edfd25eg7734b5ac4ce68f5@mail.gmail.com>

On Sun, Mar 30, 2008 at 1:03 PM, aslak hellesoy
<aslak.hellesoy at gmail.com> wrote:
> Hi,
>
>  I just published a generic and platform specific gem:
>  http://rubyforge.org/frs/?group_id=5920
>  It looks like the gems have replicated around the net:
>  http://rubyforge.iasi.roedu.net/gems/
>
>  When I do gem install ruby-usb on a Windows box, Rubygems seems to
>  download ruby-usb-0.1.2.gem and not ruby-usb-0.1.2-x86-mswin32.gem
>
>  This happens for both rubygems 1.0.1 and 1.1.0 (which I just updated to).
>
>  If I download ruby-usb-0.1.2-x86-mswin32.gem manually and install it
>  everything looks fine. Can anyone tell me how to fix this? The Windows
>  gemspec looks like the following:
>
>  Gem::Specification.new do |s|
>   s.name = %q{ruby-usb}
>   s.version = "0.1.2"
>   s.platform = %q{mswin32}
>

I recommend you switch to Gem::Platform::CURRENT, since mswin32 is deprecated.

>
>  P.S. My first upload of the Windows gem was broken, so I deleted it
>  and uploaded it again. Can that be the culplrit?
>

Yes, It appears to be a issue of rubyforge that do not replicate the
changed files across mirrors.

Trying to install it with 0.9.4 also fails and rollback to RUBY
version, and not the pre-compiled one.

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From builder at mmediasys.com  Sun Mar 30 23:00:37 2008
From: builder at mmediasys.com (Integration Builder)
Date: Mon, 31 Mar 2008 00:00:37 -0300
Subject: [Rubygems-developers] [CruiseControl] rubygems-mswin32 build 1681.1
	fixed
Message-ID: <47f053d5ec540_d2c13de3a619e@edicion01.tmail>

The build has been fixed.

  Note: if you set Configuration.dashboard_url in config/site_config.rb, you'd see a link to the build page here.

CHANGES
-------
Build was manually requested


BUILD LOG
---------
D:/Users/Luis/.cruise/projects/rubygems-mswin32/work Luis$ ruby -e "require 'rubygems' rescue nil; require 'rake'; load 'D:/Users/Luis/tools/ccrb/tasks/cc_build.rake'; ARGV << '--nosearch' << 'cc:build'; Rake.application.run; ARGV.clear"  
(in D:/Users/Luis/.cruise/projects/rubygems-mswin32/work)
[CruiseControl] Invoking Rake task "test"
Loaded suite D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake/rake_test_loader
Started
.............................................................D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable @config not initialized
D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable @config not initialized
D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable @config not initialized
................................D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/1.8/rdoc/parsers/parse_c.rb:204: warning: method redefined; discarding old progress
...WARNING:  Unable to use symlinks on Windows, installing wrapper
.WARNING:  Unable to use symlinks on Windows, installing wrapper
.WARNING:  Unable to use symlinks on Windows, installing wrapper
..............................................................WARNING:  Unable to use symlinks on Windows, installing wrapper
.............WARNING:  Unable to use symlinks on Windows, installing wrapper
..WARNING:  Unable to use symlinks on Windows, installing wrapper
..............................................................................................................................................................................................................................................................................................................................................................................................................................
Finished in 55.891 seconds.

589 tests, 1758 assertions, 0 failures, 0 errors


PROJECT SETTINGS
----------------
# Project-specific configuration for CruiseControl.rb

Project.configure do |project|
  
  project.email_notifier.emails = ['rubygems-developers at rubyforge.org', 'rubyinstaller-devel at rubyforge.org']
  
  project.scheduler.polling_interval = 5.minutes

end


From luislavena at gmail.com  Sun Mar 30 23:33:01 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 31 Mar 2008 00:33:01 -0300
Subject: [Rubygems-developers] GemInstaller on Windows (was:
	Incrementing Gem::RubyGemsVersion on trunk?)
In-Reply-To: <e3af97510803280827x7b42f8a7xbea07e14546c00d9@mail.gmail.com>
References: <e3af97510803280827x7b42f8a7xbea07e14546c00d9@mail.gmail.com>
Message-ID: <71166b3b0803302033x75912afci6eb49d129dd412e3@mail.gmail.com>

On Fri, Mar 28, 2008 at 12:27 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Fri, Mar 28, 2008 at 6:59 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  >  BTW, are you testing GemInstaller on Windows? ;-)
>
>  Yes, however, it keeps breaking - I don't have CI running on trunk,
>  which is the point of the original thread.  Currently trying to get
>  the test suite to pass again against trunk (it was passing on 1.0.1),
>  I hope soon.  I think your recent windows RubyGems patches have helped
>  :)
>

I just got it set uo at the office (yes, sunday at midnight, sue me).

Anyway, need to setup dynamic IP for it...

(guess you spotted the build-failures emails) :-D

Regards,

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Mon Mar 31 02:30:10 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 30 Mar 2008 23:30:10 -0700
Subject: [Rubygems-developers] Windows Environment (was ...Latest RubyGems
	build results...)
Message-ID: <e3af97510803302330q176ec7ccs9a3c7e843c5ef2aa@mail.gmail.com>

Luis,

Public CI for RubyGems, I like it!  Couple things:

1. Can you put the platform in the subject line, like linux, win32, mingw?
2. Do you have any instructions on how you have set up your Windows
environments, so other people can reproduce it and look at build
failures on their own?

Thanks,
-- Chad

On Sun, Mar 30, 2008 at 3:25 AM, Luis Lavena <luislavena at gmail.com> wrote:
> ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
>
>   1) Failure:
>  test_class_build_fail(TestGemExtRakeBuilder)
>  [./test/test_gem_ext_rake_builder.rb:55]:
>  <Gem::InstallError> exception expected but none was thrown.
>
>  589 tests, 1757 assertions, 1 failures, 0 errors
>
>  ===
>
>  ruby 1.8.6 (2008-03-24 patchlevel 5000) [i386-mingw32]
>
>  589 tests, 1764 assertions, 0 failures, 0 errors
>
>  ===
>
>  --
>  Luis Lavena
>  Multimedia systems
>  -
>  Human beings, who are almost unique in having the ability to learn from
>  the experience of others, are also remarkable for their apparent
>  disinclination to do so.
>  Douglas Adams
>  _______________________________________________
>  Rubygems-developers mailing list
>  Rubygems-developers at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rubygems-developers
>

From luislavena at gmail.com  Mon Mar 31 02:34:24 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 31 Mar 2008 03:34:24 -0300
Subject: [Rubygems-developers] Windows Environment (was ...Latest
	RubyGems build results...)
In-Reply-To: <e3af97510803302330q176ec7ccs9a3c7e843c5ef2aa@mail.gmail.com>
References: <e3af97510803302330q176ec7ccs9a3c7e843c5ef2aa@mail.gmail.com>
Message-ID: <71166b3b0803302334ye44e74dte0c3c84380170c30@mail.gmail.com>

On Mon, Mar 31, 2008 at 3:30 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> Luis,
>
>  Public CI for RubyGems, I like it!  Couple things:
>
>  1. Can you put the platform in the subject line, like linux, win32, mingw?
>  2. Do you have any instructions on how you have set up your Windows
>  environments, so other people can reproduce it and look at build
>  failures on their own?
>

It's on the subject line:

[CruiseControl] rubygems-mswin32 build 1681.1 fixed

mswin32: i386-mswin32
mingw32: i386-mingw32

ruby 1.8.6 p114 for mswin32
svn build for mingw32 (part of the new upcoming One-Click Installer)


I'll try to make access to the dashboard public, so user can get the
build output too.

Regards,

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Mon Mar 31 02:41:34 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 30 Mar 2008 23:41:34 -0700
Subject: [Rubygems-developers] Errno::ECONNABORTED was lost between
	commits
In-Reply-To: <71166b3b0803300819s43b1125y5bcfd89cfc988ed4@mail.gmail.com>
References: <71166b3b0803300819s43b1125y5bcfd89cfc988ed4@mail.gmail.com>
Message-ID: <e3af97510803302341kd35e3f3pbefa42733c7bea0c@mail.gmail.com>

On Sun, Mar 30, 2008 at 8:19 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  BTW, what is the RubyGems release schedule? I keep asking it, but it
>  seems there isn't one :-P

Yes, 1.1.0 caught me by surprise.  It would be good to have some
advance warning to wrap up any pending patches...

From thewoolleyman at gmail.com  Mon Mar 31 02:45:41 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 30 Mar 2008 23:45:41 -0700
Subject: [Rubygems-developers] Windows Environment (was ...Latest
	RubyGems build results...)
In-Reply-To: <71166b3b0803302334ye44e74dte0c3c84380170c30@mail.gmail.com>
References: <e3af97510803302330q176ec7ccs9a3c7e843c5ef2aa@mail.gmail.com>
	<71166b3b0803302334ye44e74dte0c3c84380170c30@mail.gmail.com>
Message-ID: <e3af97510803302345t6bda03a1i83050faaca579196@mail.gmail.com>

On Sun, Mar 30, 2008 at 11:34 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  [CruiseControl] rubygems-mswin32 build 1681.1 fixed

Hmm.  In gmail, the only message I got had this as the subject:

[Rubygems-developers] [CI] Latest RubyGems build results (r1680)

The platform was the first line of the body, but not in the subject.
I also don't see this "fixed" message in my label for the list.

From luislavena at gmail.com  Mon Mar 31 02:51:28 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 31 Mar 2008 03:51:28 -0300
Subject: [Rubygems-developers] Windows Environment (was ...Latest
	RubyGems build results...)
In-Reply-To: <e3af97510803302345t6bda03a1i83050faaca579196@mail.gmail.com>
References: <e3af97510803302330q176ec7ccs9a3c7e843c5ef2aa@mail.gmail.com>
	<71166b3b0803302334ye44e74dte0c3c84380170c30@mail.gmail.com>
	<e3af97510803302345t6bda03a1i83050faaca579196@mail.gmail.com>
Message-ID: <71166b3b0803302351s422b4d5fq242f60eadcd0a12e@mail.gmail.com>

On Mon, Mar 31, 2008 at 3:45 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Sun, Mar 30, 2008 at 11:34 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  >  [CruiseControl] rubygems-mswin32 build 1681.1 fixed
>
>  Hmm.  In gmail, the only message I got had this as the subject:
>
>  [Rubygems-developers] [CI] Latest RubyGems build results (r1680)
>

Mmm, maybe it's being marked as spam, but is sent from
builder at mmediasys.com (and I subscribed to the mailing list).

>  The platform was the first line of the body, but not in the subject.
>  I also don't see this "fixed" message in my label for the list.
>

Again, check if you have some filters added... it is cross posted to
rubyinstaller-devel mailing list too, which could be the problem.

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Mon Mar 31 03:11:06 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 31 Mar 2008 00:11:06 -0700
Subject: [Rubygems-developers] Support for legacy gems? (Re: published
	platform-specific gem not downloaded)
Message-ID: <e3af97510803310011p7e547bdaud6e34bbbcd541f9c@mail.gmail.com>

On Sun, Mar 30, 2008 at 9:11 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  I recommend you switch to Gem::Platform::CURRENT, since mswin32 is deprecated.
...
> Trying to install it with 0.9.4 also fails and rollback to RUBY
> version, and not the pre-compiled one.

Why should we need to issue this warning manually?

Are some legacy gems not downloadable with the latest version of RubyGems?

Does RubyGems issue a warning whenever a gem with a deprecated spec is
downloaded?  If not, should it?

Is it wrong to break install support for legacy gems in newer RubyGems versions?

From luislavena at gmail.com  Mon Mar 31 03:14:46 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 31 Mar 2008 04:14:46 -0300
Subject: [Rubygems-developers] Support for legacy gems? (Re: published
	platform-specific gem not downloaded)
In-Reply-To: <e3af97510803310011p7e547bdaud6e34bbbcd541f9c@mail.gmail.com>
References: <e3af97510803310011p7e547bdaud6e34bbbcd541f9c@mail.gmail.com>
Message-ID: <71166b3b0803310014v231fd59av5d426a3148dfb112@mail.gmail.com>

On Mon, Mar 31, 2008 at 4:11 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Sun, Mar 30, 2008 at 9:11 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  >  I recommend you switch to Gem::Platform::CURRENT, since mswin32 is deprecated.
>  ...
>  > Trying to install it with 0.9.4 also fails and rollback to RUBY
>  > version, and not the pre-compiled one.
>
>  Why should we need to issue this warning manually?
>

This warns the user during gem building

>  Are some legacy gems not downloadable with the latest version of RubyGems?
>

No, all old and legacy gems are supported, only new gems should use
Gem::Platform::CURRENT

>  Does RubyGems issue a warning whenever a gem with a deprecated spec is
>  downloaded?  If not, should it?
>

No, it install just fine.

>  Is it wrong to break install support for legacy gems in newer RubyGems versions?

yes, it is very wrong... see what happened between 0.9.4 and 0.9.5, I
blogged about it:

http://blog.mmediasys.com/2007/12/19/latest-rubygems-and-rails-is-a-deadly-combo/

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Mon Mar 31 03:15:23 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 31 Mar 2008 00:15:23 -0700
Subject: [Rubygems-developers] Windows Environment (was ...Latest
	RubyGems build results...)
In-Reply-To: <71166b3b0803302351s422b4d5fq242f60eadcd0a12e@mail.gmail.com>
References: <e3af97510803302330q176ec7ccs9a3c7e843c5ef2aa@mail.gmail.com>
	<71166b3b0803302334ye44e74dte0c3c84380170c30@mail.gmail.com>
	<e3af97510803302345t6bda03a1i83050faaca579196@mail.gmail.com>
	<71166b3b0803302351s422b4d5fq242f60eadcd0a12e@mail.gmail.com>
Message-ID: <e3af97510803310015g5326b9afj1e9f3783c88ee62f@mail.gmail.com>

On Sun, Mar 30, 2008 at 11:51 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  Mmm, maybe it's being marked as spam, but is sent from
>  builder at mmediasys.com (and I subscribed to the mailing list).

Sorry, I see it now, you changed the subject on the fixed one:

[Rubygems-developers] [CruiseControl] rubygems-mswin32 build 1681.1 fixed

From thewoolleyman at gmail.com  Mon Mar 31 03:17:44 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 31 Mar 2008 00:17:44 -0700
Subject: [Rubygems-developers] cruise config checked in?
Message-ID: <e3af97510803310017k1478d17cr380adaf81e93152e@mail.gmail.com>

Luis,

Can you commit your cruise config and site config to the project?
That way other people can more closely replicate your CI environment
for local testing, and also offer patches/improvements to the CI
config.

Thanks,
-- Chad

From tom at infoether.com  Mon Mar 31 10:11:40 2008
From: tom at infoether.com (Tom Copeland)
Date: Mon, 31 Mar 2008 10:11:40 -0400
Subject: [Rubygems-developers] A tiny indexer patch
Message-ID: <1206972700.25388.26.camel@localhost.localdomain>

Index: lib/rubygems/indexer/latest_index_builder.rb
===================================================================
--- lib/rubygems/indexer/latest_index_builder.rb        (revision 1663)
+++ lib/rubygems/indexer/latest_index_builder.rb        (working copy)
@@ -16,7 +16,7 @@
 
     latest = @index.latest_specs.sort.map { |spec| spec.original_name }
 
-    @file.write latest.join "\n"
+    @file.write(latest.join("\n"))
   end
 
   def cleanup

This will get rid of some warning messages I keep seeing in the
RubyForge logs, thanks!

Yours,

tom




From tom at infoether.com  Mon Mar 31 10:18:10 2008
From: tom at infoether.com (Tom Copeland)
Date: Mon, 31 Mar 2008 10:18:10 -0400
Subject: [Rubygems-developers] published platform-specific gem
	not	downloaded
In-Reply-To: <71166b3b0803300911y1edfd25eg7734b5ac4ce68f5@mail.gmail.com>
References: <8d961d900803300903h7f0ed770r57dca7bbc1144f24@mail.gmail.com>
	<71166b3b0803300911y1edfd25eg7734b5ac4ce68f5@mail.gmail.com>
Message-ID: <1206973090.25388.33.camel@localhost.localdomain>


On Sun, 2008-03-30 at 13:11 -0300, Luis Lavena wrote:
> >  P.S. My first upload of the Windows gem was broken, so I deleted it
> >  and uploaded it again. Can that be the culplrit?
> >
> 
> Yes, It appears to be a issue of rubyforge that do not replicate the
> changed files across mirrors.

Hm... we detect new gem releases with:

if !File.exist?(dest_gem_file) || File.mtime(dest_gem_file) <
File.mtime(gem_file)
 # various other stuff
end

I think that should find gem updates as well... 

Yours,

tom



From luislavena at gmail.com  Mon Mar 31 11:54:33 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 31 Mar 2008 12:54:33 -0300
Subject: [Rubygems-developers] published platform-specific gem not
	downloaded
In-Reply-To: <1206973090.25388.33.camel@localhost.localdomain>
References: <8d961d900803300903h7f0ed770r57dca7bbc1144f24@mail.gmail.com>
	<71166b3b0803300911y1edfd25eg7734b5ac4ce68f5@mail.gmail.com>
	<1206973090.25388.33.camel@localhost.localdomain>
Message-ID: <71166b3b0803310854n67631fc8maa9d5d3119683f2b@mail.gmail.com>

On Mon, Mar 31, 2008 at 11:18 AM, Tom Copeland <tom at infoether.com> wrote:
>
>  On Sun, 2008-03-30 at 13:11 -0300, Luis Lavena wrote:
>  > >  P.S. My first upload of the Windows gem was broken, so I deleted it
>  > >  and uploaded it again. Can that be the culplrit?
>  > >
>  >
>  > Yes, It appears to be a issue of rubyforge that do not replicate the
>  > changed files across mirrors.
>
>  Hm... we detect new gem releases with:
>
>  if !File.exist?(dest_gem_file) || File.mtime(dest_gem_file) <
>  File.mtime(gem_file)
>   # various other stuff
>  end
>
>  I think that should find gem updates as well...
>

You told me that a few months back, but I keep forgetting about it...
sorry for the "annotate" (yeah, blame mode was off).

That's what happened with Aslak gem? is that fixed now?

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Mon Mar 31 15:59:41 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 31 Mar 2008 12:59:41 -0700
Subject: [Rubygems-developers] Is a remote list with --all supposed to be
	required to install older gem versions?
Message-ID: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>

Hi,

With RubyGems 1.1.0, I just tried to install a non-latest gem
(contacts 1.0.10), but got a failure that it could not be found.

Then, I did a gem list  with --remote --all options, which showed that
version did indeed exist.

After doing the list with --all, the same install with verison 1.0.10 worked.

Is this the desired behavior, or a caching bug?

Thanks,
-- Chad

From luislavena at gmail.com  Mon Mar 31 17:26:19 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 31 Mar 2008 18:26:19 -0300
Subject: [Rubygems-developers] Is a remote list with --all supposed to
	be required to install older gem versions?
In-Reply-To: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>
References: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>
Message-ID: <71166b3b0803311426icae6ac2p373680af3bc11aa2@mail.gmail.com>

On Mon, Mar 31, 2008 at 4:59 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> Hi,
>
>  With RubyGems 1.1.0, I just tried to install a non-latest gem
>  (contacts 1.0.10), but got a failure that it could not be found.
>
>  Then, I did a gem list  with --remote --all options, which showed that
>  version did indeed exist.
>
>  After doing the list with --all, the same install with verison 1.0.10 worked.
>
>  Is this the desired behavior, or a caching bug?
>

Chad, can you provide the gem names so we can replicate? Also, what
are the --debug output?

Regards,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From drbrain at segment7.net  Mon Mar 31 17:42:01 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 31 Mar 2008 14:42:01 -0700
Subject: [Rubygems-developers] A tiny indexer patch
In-Reply-To: <1206972700.25388.26.camel@localhost.localdomain>
References: <1206972700.25388.26.camel@localhost.localdomain>
Message-ID: <252E3471-FB60-49E8-AF9C-8B4F50AE78E0@segment7.net>

On Mar 31, 2008, at 07:11 AM, Tom Copeland wrote:
> Index: lib/rubygems/indexer/latest_index_builder.rb
> ===================================================================
> --- lib/rubygems/indexer/latest_index_builder.rb        (revision  
> 1663)
> +++ lib/rubygems/indexer/latest_index_builder.rb        (working copy)
> @@ -16,7 +16,7 @@
>
>     latest = @index.latest_specs.sort.map { |spec|  
> spec.original_name }
>
> -    @file.write latest.join "\n"
> +    @file.write(latest.join("\n"))
>   end
>
>   def cleanup
>
> This will get rid of some warning messages I keep seeing in the
> RubyForge logs, thanks!

I got the warning too, patched it, but forgot to tell you to update.

From drbrain at segment7.net  Mon Mar 31 17:43:27 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 31 Mar 2008 14:43:27 -0700
Subject: [Rubygems-developers] Is a remote list with --all supposed to
	be required to install older gem versions?
In-Reply-To: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>
References: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>
Message-ID: <7AE38F39-B8FF-40FD-8C38-F1268126D8E5@segment7.net>

On Mar 31, 2008, at 12:59 PM, Chad Woolley wrote:
> With RubyGems 1.1.0, I just tried to install a non-latest gem
> (contacts 1.0.10), but got a failure that it could not be found.
>
> Then, I did a gem list  with --remote --all options, which showed that
> version did indeed exist.
>
> After doing the list with --all, the same install with verison  
> 1.0.10 worked.
>
> Is this the desired behavior, or a caching bug?

Caching bug.

From drbrain at segment7.net  Mon Mar 31 17:52:11 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 31 Mar 2008 14:52:11 -0700
Subject: [Rubygems-developers] published platform-specific gem not
	downloaded
In-Reply-To: <8d961d900803300903h7f0ed770r57dca7bbc1144f24@mail.gmail.com>
References: <8d961d900803300903h7f0ed770r57dca7bbc1144f24@mail.gmail.com>
Message-ID: <CA6B0BF5-A460-4BF3-B119-F1B9C40E459E@segment7.net>

On Mar 30, 2008, at 09:03 AM, aslak hellesoy wrote:
> I just published a generic and platform specific gem:
> http://rubyforge.org/frs/?group_id=5920
> It looks like the gems have replicated around the net:
> http://rubyforge.iasi.roedu.net/gems/
>
> When I do gem install ruby-usb on a Windows box, Rubygems seems to
> download ruby-usb-0.1.2.gem and not ruby-usb-0.1.2-x86-mswin32.gem
>
> This happens for both rubygems 1.0.1 and 1.1.0 (which I just updated  
> to).
>
> If I download ruby-usb-0.1.2-x86-mswin32.gem manually and install it
> everything looks fine.

The tricky part is that the file has to be uploaded with the same  
filename as it was generated with.  There may be a bug that causes it  
to give the file the wrong name.  I'm not sure if that was the problem  
as it seems that you've corrected the gem on rubyforge now, so I can't  
reproduce.

> [...]
>
> P.S. My first upload of the Windows gem was broken, so I deleted it
> and uploaded it again. Can that be the culplrit?

Possibly.

From drbrain at segment7.net  Mon Mar 31 17:55:57 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 31 Mar 2008 14:55:57 -0700
Subject: [Rubygems-developers] published platform-specific gem not
	downloaded
In-Reply-To: <71166b3b0803300911y1edfd25eg7734b5ac4ce68f5@mail.gmail.com>
References: <8d961d900803300903h7f0ed770r57dca7bbc1144f24@mail.gmail.com>
	<71166b3b0803300911y1edfd25eg7734b5ac4ce68f5@mail.gmail.com>
Message-ID: <516492B0-52DA-4013-8247-585729C8F3DF@segment7.net>

On Mar 30, 2008, at 09:11 AM, Luis Lavena wrote:
> On Sun, Mar 30, 2008 at 1:03 PM, aslak hellesoy wrote:
>> Gem::Specification.new do |s|
>>  s.name = %q{ruby-usb}
>>  s.version = "0.1.2"
>>  s.platform = %q{mswin32}
>
> I recommend you switch to Gem::Platform::CURRENT, since mswin32 is  
> deprecated.

Hrm, I thought newer RubyGems wouldn't allow that.  I will double-check.

From luislavena at gmail.com  Mon Mar 31 18:18:58 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 31 Mar 2008 19:18:58 -0300
Subject: [Rubygems-developers] published platform-specific gem not
	downloaded
In-Reply-To: <516492B0-52DA-4013-8247-585729C8F3DF@segment7.net>
References: <8d961d900803300903h7f0ed770r57dca7bbc1144f24@mail.gmail.com>
	<71166b3b0803300911y1edfd25eg7734b5ac4ce68f5@mail.gmail.com>
	<516492B0-52DA-4013-8247-585729C8F3DF@segment7.net>
Message-ID: <71166b3b0803311518l1b68b96ayddf7659c93c3c43a@mail.gmail.com>

On Mon, Mar 31, 2008 at 6:55 PM, Eric Hodel <drbrain at segment7.net> wrote:
> On Mar 30, 2008, at 09:11 AM, Luis Lavena wrote:
>
> > On Sun, Mar 30, 2008 at 1:03 PM, aslak hellesoy wrote:
>  >> Gem::Specification.new do |s|
>  >>  s.name = %q{ruby-usb}
>  >>  s.version = "0.1.2"
>  >>  s.platform = %q{mswin32}
>  >
>  > I recommend you switch to Gem::Platform::CURRENT, since mswin32 is
>  > deprecated.
>
>  Hrm, I thought newer RubyGems wouldn't allow that.  I will double-check.
>

It no allowing it, it raises not just a warning but stop building of the gem.

D:\Users\Luis\projects\oss\mongrel.bzr\work-copy>rake -T
(in D:/Users/Luis/projects/oss/mongrel.bzr/work-copy)
rake aborted!
MSWIN32 has been removed, use CURRENT instead
D:/Users/Luis/projects/oss/mongrel.bzr/work-copy/rakefile:38
(See full trace by running task with --trace)

So is not possible buidl the gem with obsolete gem platform anymore.

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From thewoolleyman at gmail.com  Mon Mar 31 18:29:18 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 31 Mar 2008 15:29:18 -0700
Subject: [Rubygems-developers] Is a remote list with --all supposed to
	be required to install older gem versions?
In-Reply-To: <7AE38F39-B8FF-40FD-8C38-F1268126D8E5@segment7.net>
References: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>
	<7AE38F39-B8FF-40FD-8C38-F1268126D8E5@segment7.net>
Message-ID: <e3af97510803311529h23d2cb47yded2c49420165db4@mail.gmail.com>

On Mon, Mar 31, 2008 at 2:43 PM, Eric Hodel <drbrain at segment7.net> wrote:
> On Mar 31, 2008, at 12:59 PM, Chad Woolley wrote:
>  > Is this the desired behavior, or a caching bug?
>
>  Caching bug.

Ticket: http://rubyforge.org/tracker/index.php?func=detail&aid=19228&group_id=126&atid=575

From tom at infoether.com  Mon Mar 31 18:49:55 2008
From: tom at infoether.com (Tom Copeland)
Date: Mon, 31 Mar 2008 18:49:55 -0400
Subject: [Rubygems-developers] A tiny indexer patch
In-Reply-To: <252E3471-FB60-49E8-AF9C-8B4F50AE78E0@segment7.net>
References: <1206972700.25388.26.camel@localhost.localdomain>
	<252E3471-FB60-49E8-AF9C-8B4F50AE78E0@segment7.net>
Message-ID: <1207003795.25388.69.camel@localhost.localdomain>


On Mon, 2008-03-31 at 14:42 -0700, Eric Hodel wrote:
> On Mar 31, 2008, at 07:11 AM, Tom Copeland wrote:
> > Index: lib/rubygems/indexer/latest_index_builder.rb
> > ===================================================================
> > --- lib/rubygems/indexer/latest_index_builder.rb        (revision  
> > 1663)
> > +++ lib/rubygems/indexer/latest_index_builder.rb        (working copy)
> > @@ -16,7 +16,7 @@
> >
> >     latest = @index.latest_specs.sort.map { |spec|  
> > spec.original_name }
> >
> > -    @file.write latest.join "\n"
> > +    @file.write(latest.join("\n"))
> >   end
> >
> >   def cleanup
> >
> > This will get rid of some warning messages I keep seeing in the
> > RubyForge logs, thanks!
> 
> I got the warning too, patched it, but forgot to tell you to update.

Oh cool, will do, thanks!

Tom