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 Enumerable.zip
More than one method matched your request. You can refine
your search by asking for information on one of:
Enumerable#zip, Enumerable#zip
ri Enumerable#zip
More than one method matched your request. You can refine
your search by asking for information on one of:
Enumerable#zip, Enumerable#zip
ruby --version
ruby 1.8.4 (2005-12-24) [i386-mswin32]
ri --version
ri v1.0.1 - 20041108
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?
W
Warren S. 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 B.
“The greatest obstacle to discovery is not ignorance, but the illusion
of knowledge.”
Curt H. 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.
Ryan L. 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?
James B.
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://refreshingcities.org - Design, technology, usability
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 L. 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/26/06, James B. [email protected] wrote:
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 L. 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
Curt H. wrote:
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 B.
“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)
On 5/26/06, James B. [email protected] wrote:
Wow. Painful.
This used to not be a problem; what changed, and what would be needed to
allow for in-place upgrades?
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
Ryan L. wrote:
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 B.
“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.”
Ryan L. wrote:
On 5/26/06, James B. [email protected] wrote:
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.
On 5/26/06, James B. [email protected] wrote:
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, [email protected] [email protected] wrote:
A job for Rake or Reap or Rant …
not to mention all binary gems would need re-compiled.
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 Sat, 27 May 2006, James B. wrote:
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
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 S.
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 S. 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
?
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