«

Doesn't ri have a problem if two parts of the class are defined in
--ri-system and --ri-site, much less a "local" directory?

-austin

On Sun, Aug 22, 2004 at 05:20:28AM +0900, Richard Kilmer wrote:
> You were misled? This is just some notes that I typed up relayed from Chad
> on some final things we wanted to get done...not a general communications to
> the broader community. No problem with reading it obviously but don't take
> it as a message. The below mentioned item says Dave is open to changing
> ri...in general...based on community feedback...he always has been. We can
> obviously add our own version of ri, but we did not like the idea. Don't
> take it personally

mmmm I was wondering why both you & Dave were attaching such an
importance to the word 'misled'. It seems my condition of non-native
English speaker might well be the culprit

dictionary.com returns

mis·lead ( P ) Pronunciation Key (ms-ld)
tr.v. mis··led, (-ld) mis·lead·ing, mis·leads

1. To lead in the wrong direction.
2. To lead into error of thought or action, especially by intentionally
deceiving. See Synonyms at deceive.

For the record, I obviously meant a softer (1)... I didn't want to imply
that you deliberately deceived me on purpose; I was just confused. I
didn't mean to blame you for that

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

On Aug 21, 2004, at 22:08, Austin Ziegler wrote:

> Doesn't ri have a problem if two parts of the class are defined in
> --ri-system and --ri-site, much less a "local" directory?

Yup! Currently it assumes that any one class is defined in one place,
as I hadn't anticipated that
the packaging folks would install into many different documentation
directories. When I get this book project finished, I'll be trying to
work with anyone who's interested to change this behavior to better
suit their models.


Cheers

Dave

On Sun, 22 Aug 2004 23:00:08 +0900, Dave Thomas <> wrote:
> On Aug 21, 2004, at 22:08, Austin Ziegler wrote:
> > Doesn't ri have a problem if two parts of the class are defined in
> > --ri-system and --ri-site, much less a "local" directory?
> Yup! Currently it assumes that any one class is defined in one place,
> as I hadn't anticipated that
> the packaging folks would install into many different documentation
> directories. When I get this book project finished, I'll be trying to
> work with anyone who's interested to change this behavior to better
> suit their models.

Right. I think that this is something that can be dealt with
regardless of the model by the use of a (for lack of a better term)
RI_PATH similar to MAN_PATH. Then, RPA and RubyGems can add to or
remove from a standard RI_PATH location "at will" (or locations; I
would suggest that the RI_PATH could be stored in the site directory,
the system directory, and optionally the "local" directory).

Right now, without even using one of the main packaging systems, I can do:

% rdoc --ri-system diff/lcs

If I have previously run rdoc/ri generation for Ruby as a whole to
--ri-site, then when I do "ri Array", I will no longer be able to see
the general ri documentation for Array (because Diff::LCS includes an
extension to Array). (There also appears to be a problem with merging
last time I checked this; I think I sent a patch that should fix that,
though. Merging should be the default) I think that it will also cause
problems if I generate the ri documentation in the "local/home"
directory.

As long as ri knows where to find various YAML files (e.g., RI_PATH),
then whatever solution is used to fix the existing problem will fix
the problem for packagers.

-austin
--
Austin Ziegler *
* Alternate:

I just tried to install rpa-base-0.2.0b on a Win2K machine, with no luck.

First, it keeps asking me to modify the installation prefix, although on
each step the prefix is really just a variation on what has gone before;
you'd think it would keep track of what I just entered and use that to
derive the next path option. But no matter. Even after explicitly
entering the paths, the installation fails.

(Here I'm trying to install the packages into c:/ruby-rpa/ and related
subdirectories)

c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
c:/ruby-rpa/c: (Errno::EINVAL)

Has this been tested on Windows? Is it not meant for Windows users?

Thanks,

James

P.S.

A recent blog entry at
http://www.thekode.net/blog/Tech/Ruby/rpa-packages.html
says,

"I have invited the people from ruby-talk to request packages for the
Ruby Production Archive. So far the response has been a bit
disappointing; seemingly no Rubyist wants to use software packaged with
some care, or maybe it’s just that the 114 packages currently available
cover all needs?"

I'm sure Mauricio meant no disrespect, but this seems to imply that
packages currently available from RubyForge and elsewhere are *not*
packaged with some care. No doubt some of these *are* fairly
half-assed, but there may be many other reasons why people prefer not to
use rpa; poor Windows support being a real possibility.

> A recent blog entry at
> http://www.thekode.net/blog/Tech/Ruby/rpa-packages.html
> says,
>
> "I have invited the people from ruby-talk to request packages for the
> Ruby Production Archive. So far the response has been a bit
> disappointing; seemingly no Rubyist wants to use software packaged with
> some care, or maybe it¢s just that the 114 packages currently available
> cover all needs?"

It's damn good! A fair bit ahead of where I am. Everything I currently
use is in there, my own ruby-xattr aside.

> I'm sure Mauricio meant no disrespect, but this seems to imply that
> packages currently available from RubyForge and elsewhere are *not*
> packaged with some care. No doubt some of these *are* fairly
> half-assed, but there may be many other reasons why people prefer not to
> use rpa; poor Windows support being a real possibility.

I can testify as to the varying quality of the author's packaging. I've
been working really hard on building RPM specs for Ruby packages for the
PLD distro, and it's tough, slow going. Some things (notably using a
modern setup.rb from Minero Aoki) are very easy. Others I've had to
fight with a lot, trying to get them to comply with the Linux Filesystem
Heirarchy Standard and other requirements. It's not easy.

I'm looking forward to trying rpa-base soon -- I haven't had the time (I
spent four hours trying to figure out why Ruby wouldn't compile on Sparc
or Alpha processors, only to find it was the Oniguruma preview failing
on some architectures)

For RPA, I can see windows support being important. I imagine that
limits its usage by about half.

Ari

As mentioned in other emails. Windows is a target
platform for it to work on. RPA-base might be a
development release, but it works very well.

Batsman: Work work work




--- Aredridel <> wrote:

> > A recent blog entry at
> >
>
http://www.thekode.net/blog/Tech/Ruby/rpa-packages.html
> > says,
> >
> > "I have invited the people from ruby-talk to
> request packages for the
> > Ruby Production Archive. So far the response has
> been a bit
> > disappointing; seemingly no Rubyist wants to use
> software packaged with
> > some care, or maybe it¢s just that the 114
> packages currently available
> > cover all needs?"
>
> It's damn good! A fair bit ahead of where I am.
> Everything I currently
> use is in there, my own ruby-xattr aside.
>
> > I'm sure Mauricio meant no disrespect, but this
> seems to imply that
> > packages currently available from RubyForge and
> elsewhere are *not*
> > packaged with some care. No doubt some of these
> *are* fairly
> > half-assed, but there may be many other reasons
> why people prefer not to
> > use rpa; poor Windows support being a real
> possibility.
>
> I can testify as to the varying quality of the
> author's packaging. I've
> been working really hard on building RPM specs for
> Ruby packages for the
> PLD distro, and it's tough, slow going. Some things
> (notably using a
> modern setup.rb from Minero Aoki) are very easy.
> Others I've had to
> fight with a lot, trying to get them to comply with
> the Linux Filesystem
> Heirarchy Standard and other requirements. It's not
> easy.
>
> I'm looking forward to trying rpa-base soon -- I
> haven't had the time (I
> spent four hours trying to figure out why Ruby
> wouldn't compile on Sparc
> or Alpha processors, only to find it was the
> Oniguruma preview failing
> on some architectures)
>
> For RPA, I can see windows support being important.
> I imagine that
> limits its usage by about half.
>
> Ari
>
>
>
>
>
>

----------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo [dot] com
----------------------------------------



_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

On Mon, Aug 23, 2004 at 02:42:02AM +0900, James Britt wrote:
> I just tried to install rpa-base-0.2.0b on a Win2K machine, with no luck.
>
> First, it keeps asking me to modify the installation prefix, although on
> each step the prefix is really just a variation on what has gone before;
> you'd think it would keep track of what I just entered and use that to
> derive the next path option. But no matter. Even after explicitly
> entering the paths, the installation fails.
>
> (Here I'm trying to install the packages into c:/ruby-rpa/ and related
> subdirectories)
>
> c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
> c:/ruby-rpa/c: (Errno::EINVAL)
>
> Has this been tested on Windows? Is it not meant for Windows users?

It has been tested on Win32. I myself have tried it on WinXP and it
worked fine there (I've often installed instiki in a couple minutes and
verified it ran fine for instance; I also installed Rails that way and
toyed with it, using the WEBrick dispatcher).

I believe you triggered a bug in the bootstrap phase related to the use
of a $prefix different from the one Ruby is installed under.

Could you try to install it under c:\ruby (you can later remove it with
rpa remove rpa-base and nothing will have been modified) to confirm
this? This should be safe since rpa-base will not overwrite anything
unless you tell it explicitly that it's ok (--force), and installations
are atomic.

I'll look into the possible bug and hopefully solve it soon.

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

On Mon, Aug 23, 2004 at 02:42:02AM +0900, James Britt wrote:
> (Here I'm trying to install the packages into c:/ruby-rpa/ and related
> subdirectories)
>
> c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
> c:/ruby-rpa/c: (Errno::EINVAL)

Thank you for your report. It helped me find a stupid bug which was triggered
when one didn't use ruby's own $prefix.

Since the issue affects the bootstrapping phase (i.e. can't be fixed
with a normal self-upgrade), I have decided to release 0.2.1pre1, available
at http://rubyforge.org/frs/?group_id=265. Please tell me if it solves
your problems.

Please keep in mind the following:
* when answering to the questions in the bootstrap phase, only the first
path is absolute (will default to Ruby's own $prefix, e.g. c:\ruby
normally on win32). The others are relative to the former and the
default values should be perfectly fine.
* setting the $prefix to c:\ruby-rpa means that rpa-base itself will be
put there; you will have to set PATH to point to c:\ruby-rpa\bin too,
and adjust RUBYLIB (something like c:\ruby-rpa\lib\ruby\site_ruby\1.8,
but not 100% sure).
As of now, it is probably better to just install into the normal
$prefix, since rpa-base provides enough guarantees to make sure it
won't end up cluttered with half-installed RPA ports.
Support for per-user installations is planned and might be done in
time for 0.3.0.

For your reference, here's the patch that fixes the problem you
reported, I believe.

--- lib/rpa/helper.rb (revision 765)
+++ lib/rpa/helper.rb (revision 766)
@@ -471,7 +471,7 @@
def run(installer)
super
sitelibdir = ::Config::CONFIG["sitelibdir"]
- sitelibdir.gsub!(/^#{Regexp.escape @config["prefix"]}/, "")
+ sitelibdir.gsub!(/^#{Regexp.escape(::Config::CONFIG["prefix"])}/, "")
do_copy(installer, sitelibdir)
end


> there may be many other reasons why people prefer not to
> use rpa; poor Windows support being a real possibility.

There are good reasons for using both RubyGems and rpa-base, and you
can indeed use them both at a time.

I am sure more bugs will be found in rpa-base's codebase, just as in
any other piece of sw.; I believe the bases are solid, though (I haven't
touched the transactional code lately, but last time I did the count was
at 500000 successful transactions since the last real bug in that area).
So far I've managed to fix all reported bugs in under 1-2 days (those
that were reported via IRC were typically fixed within a few hours).

Now, regarding my original question, is there anything you'd like to
see packaged?

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Mauricio Fernández wrote:
> On Mon, Aug 23, 2004 at 02:42:02AM +0900, James Britt wrote:
>
>>(Here I'm trying to install the packages into c:/ruby-rpa/ and related
>>subdirectories)
>>
>>c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
>>c:/ruby-rpa/c: (Errno::EINVAL)
>
>
> Thank you for your report. It helped me find a stupid bug which was triggered
> when one didn't use ruby's own $prefix.

Sweet. Thanks.
>
> Since the issue affects the bootstrapping phase (i.e. can't be fixed
> with a normal self-upgrade), I have decided to release 0.2.1pre1, available
> at http://rubyforge.org/frs/?group_id=265. Please tell me if it solves
> your problems.
>
> Please keep in mind the following:
> * when answering to the questions in the bootstrap phase, only the first
> path is absolute (will default to Ruby's own $prefix, e.g. c:\ruby
> normally on win32). The others are relative to the former and the
> default values should be perfectly fine.

Ah. I thought the default paths, as presented by the installer, were
complete paths. So I kept entering complete paths. The prompts gave no
indication that my earlier paths would be reused to build the other paths.

> * setting the $prefix to c:\ruby-rpa means that rpa-base itself will be
> put there; you will have to set PATH to point to c:\ruby-rpa\bin too,
> and adjust RUBYLIB (something like c:\ruby-rpa\lib\ruby\site_ruby\1.8,
> but not 100% sure).
> As of now, it is probably better to just install into the normal
> $prefix, since rpa-base provides enough guarantees to make sure it
> won't end up cluttered with half-installed RPA ports.

Are you *sure*? I've had enough issues with
installing/uninstalling/reinstalling assorted versions of the 1-click
package. I don't want any overlap between this and my main ruby
installation.


> Support for per-user installations is planned and might be done in
> time for 0.3.0.

Nice.

...

>
>>there may be many other reasons why people prefer not to
>>use rpa; poor Windows support being a real possibility.
>
>
> There are good reasons for using both RubyGems and rpa-base, and you
> can indeed use them both at a time.
>
> I am sure more bugs will be found in rpa-base's codebase, just as in
> any other piece of sw.; I believe the bases are solid, though (I haven't
> touched the transactional code lately, but last time I did the count was
> at 500000 successful transactions since the last real bug in that area).
> So far I've managed to fix all reported bugs in under 1-2 days (those
> that were reported via IRC were typically fixed within a few hours).
>
> Now, regarding my original question, is there anything you'd like to
> see packaged?

I don't know yet. I need to see how much disk space this takes up as
is, and see what's installed, and what I might use. You've probably
covered all the things I need. I have a few alpha/beta projects on
rubyforge. They tend have been created to scratch a personal itch, so
if they're not currently on your list then it's unlikely there is much
demand for them.

I'll go see if I can get this to play well on my laptop.

Thanks,

James