I haven't been able to get ri or fxri to work right since I installed ruby 1.8.4 on my
winxp laptop:
...
ri never finds anything. And when I click on a method name in fxri it just pastes the
entry into the irb window.
What have I done wrong?
Nothing, probably. Did you use the "1-click" Windows installer package from RubyForge.org? And install over an existing, earlier version?
I had the same problem, and it seems that earlier installations (well, 1.8.2 at least) put the ri data files in one place ("site"), while the current installation has them in another ("system").
I believe the correct place is "system". I deleted the duplicates from "site".
···
--
James Britt
"The greatest obstacle to discovery is not ignorance, but the illusion of knowledge."
- D. Boorstin
If you installed 184 on top of an existig installation, you'll have more
problems than just this. I suggest reinstalling into a new directory.
Ryan Leavengood just added code to the installer script to check for this
condition, so starting with the next release, the installer won't let you do
this.
Curt
···
On 5/25/06, James Britt <james_b@neurogami.com> wrote:
Warren Seltzer wrote:
> I haven't been able to get ri or fxri to work right since I installed
ruby 1.8.4 on my
> winxp laptop:
>
...
> ri never finds anything. And when I click on a method name in fxri it
just pastes the
> entry into the irb window.
>
> What have I done wrong?
>
Nothing, probably. Did you use the "1-click" Windows installer package
from RubyForge.org? And install over an existing, earlier version?
I had the same problem, and it seems that earlier installations (well,
1.8.2 at least) put the ri data files in one place ("site"), while the
current installation has them in another ("system").
I believe the correct place is "system". I deleted the duplicates from
"site".
--
James Britt
"The greatest obstacle to discovery is not ignorance, but the illusion
of knowledge."
- D. Boorstin
Thanx guys. That fixed it. I nuked the site directory and left the system directory and
both 'ri' and 'fxri' began working properly immediately.
Warren Seltzer
···
-----Original Message-----
From: James Britt [mailto:james_b@neurogami.com]
Sent: Friday, May 26, 2006 7:27 AM
To: ruby-talk ML
Subject: Re: ri broken?
Warren Seltzer wrote:
I haven't been able to get ri or fxri to work right since I installed ruby 1.8.4 on my
winxp laptop:
...
ri never finds anything. And when I click on a method name in fxri it just pastes the
entry into the irb window.
What have I done wrong?
Nothing, probably. Did you use the "1-click" Windows installer package
from RubyForge.org? And install over an existing, earlier version?
I had the same problem, and it seems that earlier installations (well,
1.8.2 at least) put the ri data files in one place ("site"), while the
current installation has them in another ("system").
I believe the correct place is "system". I deleted the duplicates from
"site".
--
James Britt
"The greatest obstacle to discovery is not ignorance, but the illusion
of knowledge."
- D. Boorstin
If you installed 184 on top of an existig installation, you'll have more
problems than just this. I suggest reinstalling into a new directory.
What are these other problems?
Life is so much simpler for the guy not assembling the installer when it installs over existing installations and Just Works.
Ryan Leavengood just added code to the installer script to check for this
condition, so starting with the next release, the installer won't let you do
this.
What is "this"? Install to the same directory as a previous version?
If one installs to a new location, what happens to the gems, etc., installed under the previous Ruby?
My ri is broken too, and I *need* it since without it I do not know WTF
I am doing, and I don't know how to fix it.
from the previous posts in thread on this:
earlier installations (well, 1.8.2 at least) put the ri data files in one place ("site"), while the current installation has them in another ("system").
I believe the correct place is "system". I deleted the duplicates from "site".
Warren Seltzer replied:
Thanx guys. That fixed it. I nuked the site directory and left the
system directory and
both 'ri' and 'fxri' began working properly immediately.
and Anna wonders -
OK, so where is the site directory ? ( I see a ruby_site and a scite and
a Site - is it any of these?)
my capital-S Site is
InstantRails\ruby\lib\ruby\gems\1.8\doc\rubyforge-0.4.2\ri\Site
but it only contains cdesc-Site.yaml - does this mean that my "broken
ri" is an entirely different problem from Warren's?
ri --version
gives 1.0.1 if that helps any.
and is there a forum specific to "ruby newbie" questions, where it'd
make sense to ask this stuff? I hate to clog up the "ruby people who
know what they're doing" forum with basic questions, but it would help
SOOOOOO much to be able to ask a quick Q and get an answer, rather than
spending 1/2 hr of my time (and too much of my sanity) digging to find
each answer to each newbie question.
thanks
Anna
p.s. behavior: when I type "ri String" in a dos window *nothing* happens
until I hit ctrl-c at which pt I get a flurry of "gee we got
interrupted" msgs - starting with:
[...]InstantRails/ruby/lib/ruby/1.8/rdoc/ri/ri_cache.rb:57 in
'load_from': Interrupt
Curt Hibbs wrote:
> If you installed 184 on top of an existig installation, you'll have more
> problems than just this. I suggest reinstalling into a new directory.
What are these other problems?
Life is so much simpler for the guy not assembling the installer when it
installs over existing installations and Just Works.
I know. The only other problem that comes immediately to mind was that
openSSL stops working. I know there's something else, but its not coming
back to me at the moment.
> Ryan Leavengood just added code to the installer script to check for
this
> condition, so starting with the next release, the installer won't let
> you do
> this.
What is "this"? Install to the same directory as a previous version?
Yes, it won't let you install over a previous installation.
If one installs to a new location, what happens to the gems, etc.,
installed under the previous Ruby?
you'd have to reinstall the gems.
Curt
···
On 5/26/06, James Britt <james_b@neurogami.com> wrote:
If you are using Instant Rails you should use fxri which is a
graphical version ri combined with an irb (interactive ruby) session
-- much better that plain old ri.
In the Instant Rails menus, choose "Help >> fxri""
Curt
···
On 6/24/07, Anna Haynes <ncfocus2003@yahoo.com> wrote:
My ri is broken too, and I *need* it since without it I do not know WTF
I am doing, and I don't know how to fix it.
from the previous posts in thread on this:
> earlier installations (well, 1.8.2 at least) put the ri data files in one place ("site"), while the current installation has them in another ("system").
> I believe the correct place is "system". I deleted the duplicates from "site".
Warren Seltzer replied:
> Thanx guys. That fixed it. I nuked the site directory and left the
> system directory and
> both 'ri' and 'fxri' began working properly immediately.
and Anna wonders -
OK, so where is the site directory ? ( I see a ruby_site and a scite and
a Site - is it any of these?)
my capital-S Site is
InstantRails\ruby\lib\ruby\gems\1.8\doc\rubyforge-0.4.2\ri\Site
but it only contains cdesc-Site.yaml - does this mean that my "broken
ri" is an entirely different problem from Warren's?
ri --version
gives 1.0.1 if that helps any.
and is there a forum specific to "ruby newbie" questions, where it'd
make sense to ask this stuff? I hate to clog up the "ruby people who
know what they're doing" forum with basic questions, but it would help
SOOOOOO much to be able to ask a quick Q and get an answer, rather than
spending 1/2 hr of my time (and too much of my sanity) digging to find
each answer to each newbie question.
thanks
Anna
p.s. behavior: when I type "ri String" in a dos window *nothing* happens
until I hit ctrl-c at which pt I get a flurry of "gee we got
interrupted" msgs - starting with:
[...]InstantRails/ruby/lib/ruby/1.8/rdoc/ri/ri_cache.rb:57 in
'load_from': Interrupt
> Ryan Leavengood just added code to the installer script to check for
this
> condition, so starting with the next release, the installer won't let
> you do
> this.
What is "this"? Install to the same directory as a previous version?
Yes, it won't let you install over a previous installation.
If one installs to a new location, what happens to the gems, etc.,
installed under the previous Ruby?
you'd have to reinstall the gems.
Wow. Painful.
This used to not be a problem; what changed, and what would be needed to allow for in-place upgrades?
···
--
James Britt
"Programs must be written for people to read, and only incidentally
for machines to execute."
- H. Abelson and G. Sussman
(in "The Structure and Interpretation of Computer Programs)
The directory layout changed quite a bit in the latest installer.
An example of something that changed which caused a problem was
openssl moved from lib/ruby/site_ruby into lib/ruby/1.8. Leaving the
old version in site_ruby would break any use of SSL.
To allow for in-place upgrades we would have to find every
incompatibility caused by libraries which have moved or changed in
some way (like openssl) and explicitly add support to the installer to
delete the old versions first. Though there might be some more general
way to do it. It would still involve selective deleting which is error
prone and could result in more problems and big reports.
Considering you don't have to upgrade very often, I don't think it is
that hard to refresh your gems and other libraries after a new clean
install.
Ryan
···
On 5/26/06, James Britt <james_b@neurogami.com> wrote:
Wow. Painful.
This used to not be a problem; what changed, and what would be needed to
allow for in-place upgrades?
To allow for in-place upgrades we would have to find every
incompatibility caused by libraries which have moved or changed in
some way (like openssl) and explicitly add support to the installer to
delete the old versions first. Though there might be some more general
way to do it. It would still involve selective deleting which is error
prone and could result in more problems and big reports.
Considering you don't have to upgrade very often, I don't think it is
that hard to refresh your gems and other libraries after a new clean
install.
Interesting. I had thought there were well-defined locations for different types of libraries (core, stdlib, and everything else), so that replacing old with new would be predictable (e.g., an upgrade could just nuke any old core + stdlib stuff and drop in new ones, leaving any custom stuff alone).
Oh well.
A job for Rake or Reap or Rant ...
···
Ryan
--
James Britt
"In physics the truth is rarely perfectly clear, and that is certainly
universally the case in human affairs. Hence, what is not surrounded by
uncertainty cannot be the truth."
- R. Feynman
Interesting. I had thought there were well-defined locations for
different types of libraries (core, stdlib, and everything else), so
that replacing old with new would be predictable (e.g., an upgrade could
just nuke any old core + stdlib stuff and drop in new ones, leaving any
custom stuff alone).
The openssl example is a prime deal breaker. To fix this problem you
must either selectively delete the old openssl stuff in site_ruby, or
delete the entire site_ruby. The first solution could become a
maintenance nightmare because every time something moves from
site_ruby into the stdlib we would have to add a special case for it
to the installer. The second solution is bad because then the non-gem
libraries that are installed will be deleted, which I guarantee people
will not like.
With our current solution we are being explicit that you're old ruby
install will be uninstalled first, so at least you know what you are
getting into.
A job for Rake or Reap or Rant ...
To me that sounds like RubyGems could use some improvements...like
maybe bulk installs, or a nice point and click GUI (click all the
checkboxes for the gems you want.) In fact now that I've thought of
this I'm surprised no one has coded that up.
Ryan
···
On 5/26/06, James Britt <james_b@neurogami.com> wrote:
On 5/26/06, James Britt <james_b@neurogami.com> wrote:
.. With our current solution we are being explicit that you're old ruby
install will be uninstalled first, so at least you know what you are
getting into.
A job for Rake or Reap or Rant ...
To me that sounds like RubyGems could use some improvements...like
maybe bulk installs, or a nice point and click GUI (click all the
checkboxes for the gems you want.) In fact now that I've thought of
this I'm surprised no one has coded that up.
But it's not not just gems that would have to migrate, but all the libs installed with setup.rb or install.rb or whatever was used.
not to mention all binary gems would need re-compiled.
-a
···
On Sat, 27 May 2006, James Britt wrote:
Ryan Leavengood wrote:
On 5/26/06, James Britt <james_b@neurogami.com> wrote:
.. With our current solution we are being explicit that you're old ruby
install will be uninstalled first, so at least you know what you are
getting into.
A job for Rake or Reap or Rant ...
To me that sounds like RubyGems could use some improvements...like
maybe bulk installs, or a nice point and click GUI (click all the
checkboxes for the gems you want.) In fact now that I've thought of
this I'm surprised no one has coded that up.
But it's not not just gems that would have to migrate, but all the libs
installed with setup.rb or install.rb or whatever was used.
--
be kind whenever possible... it is always possible.
- h.h. the 14th dali lama
There's no guarantee that existing libs are compatible with new Ruby
releases. They might be, and they might not.
To be perfectly blunt, the one-click installer is now up to about 6,000
downloads a day, and anything that we can do to minimize support problems is
a blessing.
Curt
···
On 5/26/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Sat, 27 May 2006, James Britt wrote:
> Ryan Leavengood wrote:
>> On 5/26/06, James Britt <james_b@neurogami.com> wrote:
>
>> .. With our current solution we are being explicit that you're old ruby
>> install will be uninstalled first, so at least you know what you are
>> getting into.
>>
>>> A job for Rake or Reap or Rant ...
>>
>> To me that sounds like RubyGems could use some improvements...like
>> maybe bulk installs, or a nice point and click GUI (click all the
>> checkboxes for the gems you want.) In fact now that I've thought of
>> this I'm surprised no one has coded that up.
>>
>
> But it's not not just gems that would have to migrate, but all the libs
> installed with setup.rb or install.rb or whatever was used.
not to mention all binary gems would need re-compiled.
