[ANN] RubyGems 1.3.1

ruby-talk
1

= Announce: RubyGems Release 1.3.1

NOTE: RubyGems 1.1 and 1.2 have problems upgrading when there is no
rubygems-update installed. You will need to follow the second set of update
instructions if you see "Nothing to update".

Release 1.3.1 fixes some bugs.

Bugs fixed:

* Disregard ownership of ~ under Windows while creating ~/.gem. Fixes
   issues related to no uid support under Windows.
* Fix requires for Gem::inflate, Gem::deflate, etc.
* Make Gem.dir respect :gemhome value from config. (Note: this feature may be
   removed since it is hard to implement on 1.9.)
* Kernel methods are now private. Patch #20801 by Stefan Rusterholz.
* Gem::location_of_caller now behaves on Windows. Patch by Daniel Berger.
* Silence PATH warning.

Deprecation Notices:

* Gem::manage_gems will be removed on or after March 2009.

For a full list of changes to RubyGems and the contributor for each change, see
the ChangeLog file.

Special thanks to Chad Wooley for backwards compatibility testing and Luis
Lavena for continuing windows support.

== How can I get RubyGems?

NOTE: If you have installed RubyGems using a package system you may want to
install a new RubyGems through the same packaging system.

If you have a recent version of RubyGems (0.8.5 or later), then all
you need to do is:

   $ gem update --system (you might need to be admin/root)

NOTE: RubyGems 1.1 and 1.2 have problems upgrading when there is no
rubygems-update installed. You will need to follow the second set of update
instructions if you see "Nothing to update".

NOTE: You may have to run the command twice if you have any previosly
installed rubygems-update gems.

If you have an older version of RubyGems installed, then you can still
do it in two steps:

   $ gem install rubygems-update (again, might need to be admin/root)
   $ update_rubygems (... here too)

If you don't have any gems install, there is still the pre-gem
approach to getting software ... doing it manually:

1. DOWNLOAD FROM: http://rubyforge.org/frs/?group_id=126
2. UNPACK INTO A DIRECTORY AND CD THERE
3. INSTALL WITH: ruby setup.rb (you may need admin/root privilege)

== To File Bugs

The RubyGems bug tracker can be found on RubyForge at:
http://rubyforge.org/tracker/?func=add&group_id=126&atid=575

When filing a bug, `gem env` output will be helpful in diagnosing the issue.

If you find a bug where RubyGems crashes, please provide debug output. You can
do that with `gem --debug the_command`.

== Thanks

Keep those gems coming!

-- Jim & Chad & Eric (for the RubyGems team)

2

Thank you for the new version. Unfortunately, bug #19268 isn't
resolved yet, so a simple "gem update" still fails on many Windows
installations.

In the bug report, it is suggested to simply continue after an
installation error. A better solution would be to introduce an
additional option for the update command ("--native", "--precompiled",
or something else) to only use gem versions with a precompiled binary.

For example, if I have installed hpricot 0.5 and issue "gem update
hpricot --native", it should update to hpricot 0.6 but not to hpricot
0.6.161.

Regards,
Pit

···

2008/10/29 Eric Hodel <drbrain@segment7.net>:

= Announce: RubyGems Release 1.3.1

3

Eric Hodel wrote:

= Announce: RubyGems Release 1.3.1

Thank you!

NOTE: RubyGems 1.1 and 1.2 have problems upgrading when there is no
rubygems-update installed. You will need to follow the second set of update instructions if you see "Nothing to update".

Or something like,

  $ sudo gem update --system
  Updating RubyGems
  Updating rubygems-update
  Successfully installed rubygems-update-1.3.1
  ERROR: While executing gem ... (NameError)
      undefined local variable or method `remote_gemspecs'
      for #<Gem::Commands::UpdateCommand:0x1208504>

The second update method,

   $ gem install rubygems-update (again, might need to be admin/root)
   $ update_rubygems (... here too)

worked just fine (but bypassing the first step since it was already done).

Regards,

···

--
http://twitter.com/bil_kleb

4

> = Announce: RubyGems Release 1.3.1

Thank you for the new version. Unfortunately, bug #19268 isn't
resolved yet, so a simple "gem update" still fails on many Windows
installations.

In the bug report, it is suggested to simply continue after an
installation error. A better solution would be to introduce an
additional option for the update command ("--native", "--precompiled",
or something else) to only use gem versions with a precompiled binary.

For example, if I have installed hpricot 0.5 and issue "gem update
hpricot --native", it should update to hpricot 0.6 but not to hpricot
0.6.161.

As your point may be valid, introducing a new command not only
requires testing but is too major to be something just for a y.z point
release.

I believe the priorities when installing gems should be 'platform-
specific-one' and then 'ruby', contrary to what we have now (ruby,
then-your-platform).

I invite you bring this discussion to rubygems-developer mailing list
so we can workout something for this.

On a side note, I believe we should directly blame gem maintainers for
neglecting the native builds for the platform. Hopefully when GCC-
based Ruby arrives (I know, too vaporware right now) we would rejoice.

Regards,
Pit

Regards,

···

On Oct 30, 4:48 am, Pit Capitain <pit.capit...@gmail.com> wrote:

2008/10/29 Eric Hodel <drbr...@segment7.net>:

--
Luis Lavena

5

I had the same error on the update --system, but installing rubygems-
update and running that worked for me. I'm on Ubuntu 8.04.

When I tried doing a gem cleanup, my box chewed through it's 2GB of
system memory and started swapping hard. I remember this memory-eating
bug used to happen on gem update, but was cleared up in a previous
release.

- Jason L.

···

On Oct 30, 1:46 am, Bil Kleb <Bil.Kleb-use...@nasa.gov> wrote:

Eric Hodel wrote:
> = Announce: RubyGems Release 1.3.1

Thank you!

> NOTE: RubyGems 1.1 and 1.2 have problems upgrading when there is no
> rubygems-update installed. You will need to follow the second set of
> update instructions if you see "Nothing to update".

Or something like,

$ sudo gem update --system
Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.3.1
ERROR: While executing gem ... (NameError)
undefined local variable or method `remote_gemspecs'
for #<Gem::Commands::UpdateCommand:0x1208504>

The second update method,

> $ gem install rubygems-update (again, might need to be admin/root)
> $ update_rubygems (... here too)

worked just fine (but bypassing the first step since it was already done).

6

I've had a look for exception in here but nothing quite does the job.

(10264..10300).each do |i|
  ...

  begin
    question_text = res_q[0][1].gsub('"', "'")
  rescue Exception=>g
  end

  ...
End

If this query throws and exception is there a way of aborting the
current loop i.e. the loop for record #10267 but then loop again for
#10268?
At the moment it just comes out of
question_text = res_q[0][1].gsub('"', "'")
and goes onto the next operation within the loop, which is fantastic,
but not quite what I want

Kind Regards,
Dan

7

Luis Lavena wrote:

As your point may be valid, introducing a new command not only
requires testing but is too major to be something just for a y.z point
release.

I believe the priorities when installing gems should be 'platform-
specific-one' and then 'ruby', contrary to what we have now (ruby,
then-your-platform).

*Strongly* agree...and I also believe any gem that depends on C extensions which only work on MRI should not be the default "ruby" platform, since they obviously don't work everywhere. Historical reasons, I know...but we have to field at least a couple questions a week from people accidentally trying to install a C extension on JRuby.

- Charlie

8

You want the "next" keyword, which directly jumps to the next iteration
in the loop. Take a look also at break, redo and retry for other cases.

irb(main):001:0> %w{a b c d e}.each do |w|
irb(main):002:1* next if w=="c"
irb(main):003:1> puts w
irb(main):004:1> end
a
b
d
e

Jesus.

···

On Thu, Oct 30, 2008 at 4:54 PM, Daniel Malcolm Webb [dbw] <dbw@aber.ac.uk> wrote:

I've had a look for exception in here but nothing quite does the job.

(10264..10300).each do |i|
...

begin
   question_text = res_q[0][1].gsub('"', "'")
rescue Exception=>g
end

...
End

If this query throws and exception is there a way of aborting the
current loop i.e. the loop for record #10267 but then loop again for
#10268?
At the moment it just comes out of
question_text = res_q[0][1].gsub('"', "'")
and goes onto the next operation within the loop, which is fantastic,
but not quite what I want

9

do not thread hijack. it isn't hard to start a new mail from scratch.

···

On Oct 30, 2008, at 08:54 , Daniel Malcolm Webb [dbw] wrote:

I've had a look for exception in here but nothing quite does the job.

10

The problem with that is the _unpredictable_ nature of all the other
"no ruby" platforms.

I alone need to deal with two: i386-mswin32 and i386-mingw32, don't
get me started with x86_64 for 64 bits Windoze...

So I don't see gem developers releasing gems that are the same for all
the known platforms except for "ruby" since ruby will generate this
situation in JRuby.

There is no easy way for this since the gems can have different types
of bundled extensions (via mkrf or extconf).

···

On Oct 30, 2:14 pm, Charles Oliver Nutter <charles.nut...@sun.com> wrote:

Luis Lavena wrote:
> As your point may be valid, introducing a new command not only
> requires testing but is too major to be something just for a y.z point
> release.

> I believe the priorities when installing gems should be 'platform-
> specific-one' and then 'ruby', contrary to what we have now (ruby,
> then-your-platform).

*Strongly* agree...and I also believe any gem that depends on C
extensions which only work on MRI should not be the default "ruby"
platform, since they obviously don't work everywhere. Historical
reasons, I know...but we have to field at least a couple questions a
week from people accidentally trying to install a C extension on JRuby.

--
Luis Lavena

11

Thanks Jesus that's worked a treat! I do love Ruby, just wish I knew more syntax.

Thanks,
Dan

···

-----Original Message-----
From: Jesús Gabriel y Galán [mailto:jgabrielygalan@gmail.com]
Sent: 30 October 2008 16:59
To: ruby-talk ML
Subject: Re: Exceptions & loops

On Thu, Oct 30, 2008 at 4:54 PM, Daniel Malcolm Webb [dbw] <dbw@aber.ac.uk> wrote:

I've had a look for exception in here but nothing quite does the job.

(10264..10300).each do |i|
...

begin
   question_text = res_q[0][1].gsub('"', "'")
rescue Exception=>g
end

...
End

If this query throws and exception is there a way of aborting the
current loop i.e. the loop for record #10267 but then loop again for
#10268?
At the moment it just comes out of
question_text = res_q[0][1].gsub('"', "'")
and goes onto the next operation within the loop, which is fantastic,
but not quite what I want

You want the "next" keyword, which directly jumps to the next iteration
in the loop. Take a look also at break, redo and retry for other cases.

irb(main):001:0> %w{a b c d e}.each do |w|
irb(main):002:1* next if w=="c"
irb(main):003:1> puts w
irb(main):004:1> end
a
b
d
e

Jesus.

12

Luis Lavena wrote:

There is no easy way for this since the gems can have different types
of bundled extensions (via mkrf or extconf).

My argument is that any Ruby impl requirement should be explicit in the gemspec; i.e. it should be possible to install a gem that will only ever work on MRI since it would say it only works on MRI. And likewise for JRuby...there's already a couple non-platform gems that only work in JRuby. Without adding "supported implementations" to the gemspec it will only get worse.

- Charlie

13

Charles Oliver Nutter wrote:

Luis Lavena wrote:

There is no easy way for this since the gems can have different types
of bundled extensions (via mkrf or extconf).

My argument is that any Ruby impl requirement should be explicit in the gemspec; i.e. it should be possible to install a gem that will only ever work on MRI since it would say it only works on MRI.

Er, I meant "it should NOT be possible to install a gem...."

- Charlie