Forum: Ruby RubyGems 1.3.1

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Eric H. (Guest)
on 2008-10-29 22:35
(Received via mailing list)
= 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 R..
* 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=12...

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)
Pit C. (Guest)
on 2008-10-30 09:50
(Received via mailing list)
2008/10/29 Eric H. <removed_email_address@domain.invalid>:
> = 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.

Regards,
Pit
Bil K. (Guest)
on 2008-10-30 10:51
(Received via mailing list)
Eric H. 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,
Luis L. (Guest)
on 2008-10-30 14:30
(Received via mailing list)
On Oct 30, 4:48 am, Pit C. <removed_email_address@domain.invalid> wrote:
> 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,
(Guest)
on 2008-10-30 17:45
(Received via mailing list)
On Oct 30, 1:46 am, Bil K. <removed_email_address@domain.invalid> wrote:
>
> >    $ 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).


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.
Dan W. (Guest)
on 2008-10-30 17:55
(Received via mailing list)
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
Jesús Gabriel y Galán (Guest)
on 2008-10-30 19:00
(Received via mailing list)
On Thu, Oct 30, 2008 at 4:54 PM, Daniel Malcolm Webb [dbw]
<removed_email_address@domain.invalid> wrote:
>  ...
> 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.
Charles Oliver N. (Guest)
on 2008-10-30 19:16
(Received via mailing list)
Luis L. 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
Ryan D. (Guest)
on 2008-10-30 19:40
(Received via mailing list)
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.

do not thread hijack. it isn't hard to start a new mail from scratch.
Dan W. (Guest)
on 2008-10-31 11:51
(Received via mailing list)
Thanks Jesus that's worked a treat! I do love Ruby, just wish I knew
more syntax.

Thanks,
Dan
Luis L. (Guest)
on 2008-10-31 14:25
(Received via mailing list)
On Oct 30, 2:14 pm, Charles Oliver N. <removed_email_address@domain.invalid>
wrote:
> 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.
>

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).
Charles Oliver N. (Guest)
on 2008-10-31 16:46
(Received via mailing list)
Luis L. 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
Charles Oliver N. (Guest)
on 2008-10-31 17:09
(Received via mailing list)
Charles Oliver N. wrote:
> Luis L. 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
This topic is locked and can not be replied to.