I just thought of what the problem might be: Ruby 1.9.0-03 is a
Japanese version of Ruby. I guessed my way through the .msi installer
screens. I haven't seen any impact of its Japanese origin when
running run-of-the-mill Ruby scrips, so far. But maybe the URI
generated was for a Japanese browser. Trying to actually debug the
gem is beyond my pay grade
I'm going to experiment some more to see if I can get a better fix on
this problem.
Again, Thanks in Advance,
Richard
···
On Aug 4, 7:05 pm, RichardOnRails <RichardDummyMailbox58...@uscomputergurus.com> wrote:
Hi All,
I installed Ruby 1.9.0-03 (ruby 1.9.0 (2008-07-25 revision 18217)
[i386-mswin32]) over WinXP/SP2 a few days ago. It works great.
That installation included gem 1.2.0.1824. I searched for a Rails gem
and got:
Thanks for looking into this issue. It's not life or death for me: I
can alway switch back painlessly to 1.8.6.
The results per your request follow below.
On Aug 4, 2008, at 16:08 PM, RichardOnRails wrote:
> I installed Ruby 1.9.0-03 (ruby 1.9.0 (2008-07-25 revision 18217)
> [i386-mswin32]) over WinXP/SP2 a few days ago. It works great.
>
> That installation included gem 1.2.0.1824. I searched for a Rails gem
> and got:
>
> K:\_Utilities\Ruby>gem list rails -r
> *** REMOTE GEMS ***
> rails (2.1.0)
> [snip]
>
> I tried a number of permutations/combinations of:
> gem install rails �r
>
> They all failed with:
> ERROR: While executing gem ... (URI::InvalidURIError)
> bad URI(is not URI?):
>
> Gem under my Ruby 1.8.6 installation was working fine a while back.
> My Firefox 2.0 browser is working fine. Any idea what the problem
> might be?
I still have 1.8.6 installed along with 1.9.0. I mention that because
it might have some bearing at the second exception following the "gem
--debug install rails -r" command.
The exception references F:\Documents and Settings\RLMuller\.gem\specs
\gems.rubyforge.org%80,
which contains an untyped file "latest_specs.4.8" that seems to
contain Rails settings, e.g. ActsAsEscaped.
Presumably my 1.8.6 version references the Latest Specs file also.
that presents a potential conflict that might bear on the current
problem.
I hope this is a help to your analysis and not a distraction.
Best wishes,
Richard
···
On Aug 4, 7:46 pm, Eric Hodel <drbr...@segment7.net> wrote:
On Aug 4, 2008, at 16:08 PM, RichardOnRails wrote:
> I installed Ruby 1.9.0-03 (ruby 1.9.0 (2008-07-25 revision 18217)
> [i386-mswin32]) over WinXP/SP2 a few days ago. It works great.
> That installation included gem 1.2.0.1824. I searched for a Rails gem
> and got:
I tried a number of permutations/combinations of:
gem install rails –r
They all failed with:
ERROR: While executing gem ... (URI::InvalidURIError)
bad URI(is not URI?):
Gem under my Ruby 1.8.6 installation was working fine a while back.
My Firefox 2.0 browser is working fine. Any idea what the problem
might be?
Please report:
gem env
gem --debug install rails -r
Hi again Eric,
I still have 1.8.6 installed along with 1.9.0. I mention that because
it might have some bearing at the second exception following the "gem
--debug install rails -r" command.
The exception references F:\Documents and Settings\RLMuller\.gem\specs
\gems.rubyforge.org%80,
which contains an untyped file "latest_specs.4.8" that seems to
contain Rails settings, e.g. ActsAsEscaped.
The .4.8 at the end refers to the Marshal version of the contents of the file. Inside it is an Array of Arrays of gem names, versions and platforms.
Presumably my 1.8.6 version references the Latest Specs file also.
that presents a potential conflict that might bear on the current
problem.
Provided Ruby 1.9 correctly bumps the Marshal version numbers when changes occur, there should be no problem. Your backtrace shows that this isn't the problem.
···
On Aug 4, 2008, at 20:28 PM, RichardOnRails wrote:
On Aug 4, 7:46 pm, Eric Hodel <drbr...@segment7.net> wrote:
On Aug 4, 2008, at 16:08 PM, RichardOnRails wrote:
Can you add 'p uri' above this line and report what it is trying to parse?
···
On Aug 4, 2008, at 19:48 PM, RichardOnRails wrote:
Hi Eric,
Thanks for looking into this issue. It's not life or death for me: I
can alway switch back painlessly to 1.8.6.
The results per your request follow below.
The is a belated post to tell you that 1.9 seemed more problematic
than I'm prepared to deal with. I have only occasional use for look-
behind and can always use Perl until a regular release of 1.9 is
issued.
I apologize for not having reported back promptly.
Best wishes,
Richard
···
On Aug 6, 7:31 pm, Eric Hodel <drbr...@segment7.net> wrote:
On Aug 4, 2008, at 20:28 PM, RichardOnRails wrote:
> On Aug 4, 7:46 pm, Eric Hodel <drbr...@segment7.net> wrote:
>> On Aug 4, 2008, at 16:08 PM, RichardOnRails wrote:
>>> I installed Ruby 1.9.0-03 (ruby 1.9.0 (2008-07-25 revision 18217)
>>> [i386-mswin32]) over WinXP/SP2 a few days ago. It works great.
>>> That installation included gem 1.2.0.1824. I searched for a Rails
>>> gem
>>> and got:
>>> I tried a number of permutations/combinations of:
>>> gem install rails –r
>>> They all failed with:
>>> ERROR: While executing gem ... (URI::InvalidURIError)
>>> bad URI(is not URI?):
>>> Gem under my Ruby 1.8.6 installation was working fine a while back.
>>> My Firefox 2.0 browser is working fine. Any idea what the problem
>>> might be?
>> Please report:
>> gem env
>> gem --debug install rails -r
> Hi again Eric,
> I still have 1.8.6 installed along with 1.9.0. I mention that because
> it might have some bearing at the second exception following the "gem
> --debug install rails -r" command.
> The exception references F:\Documents and Settings\RLMuller\.gem\specs
> \gems.rubyforge.org%80,
> which contains an untyped file "latest_specs.4.8" that seems to
> contain Rails settings, e.g. ActsAsEscaped.
The .4.8 at the end refers to the Marshal version of the contents of
the file. Inside it is an Array of Arrays of gem names, versions and
platforms.
> Presumably my 1.8.6 version references the Latest Specs file also.
> that presents a potential conflict that might bear on the current
> problem.
Provided Ruby 1.9 correctly bumps the Marshal version numbers when
changes occur, there should be no problem. Your backtrace shows that
this isn't the problem.
