I can understand why people don’t care for threading on DOS. But
portability? Isn’t that an advantage?
No, not if portability isn’t something that your system/program/etc. needs.
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook™.
http://calendar.yahoo.com
Jason Creighton androflux@remove.to.reply.softhome.net writes:
…or whatever. We need more flexible package managers in general, not
just
a language specific package manager every time we feel like we need to
reinvent the wheel.The problem with solving the general case once and for all is that
everyone
talks about it and nobody does it. CPAN may have its flaws, but it beats
anything non-existent hands down.
Ah, the ontological proof of the existence of CPAN.
Actually I’ve always thought it worth noting that
CPAN wasn’t built in a day (to coin a phrase).
Whatever benefits it has, it wasn’t created with
all of them at once.
Likewise, RAA is much better than it was a year ago.
(Thanks to the hard work of certain developers.)
To me, the important thing is continuous improvement.
Sure, catch the vision of what RAA should be like in
five years. But don’t stop worrying about what it
will be in six months.
The thing about dreams is that their implementation
is so daunting. That’s one reason XP (arguably) is
better than Big Design Up Front. When we dream, we
sometimes forget YAGNI and want to do everything at
once.
I think this is why RubyGems went away (not to
disparage the author, who did a great job). It was
more dream than reality (though it was a good
dream). raa-install is not as good as the dream of
RubyGems; but raa-install is here now, and it works.
And as Simon said so aptly, it beats anything non-
existent hands down.
Hal
----- Original Message -----
From: “Simon Cozens” simon@simon-cozens.org
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, June 12, 2003 5:05 PM
Subject: Re: Ruby advantages over Perl
If there were a standard set of commands as widely understood as
“./configure” “make” “make install”, then there would be no need for a
CPAN-alike repository and build and test system – wget and a shell
would be all that is needed, and a very simplistic tool to search the
RAA, download the package and execute the standard commands would be
very easy to create.
It was easy, and it’s called raa-install. It works just as you
described:
http://raa.ruby-lang.org/list.rhtml?name=raainstall
-Tom
Also, I would probably implement it thus:
class Integer
def factorial
(1…self).inject { |f, n| f * n }
end
end
Actually, my original code does a (1…self).each for efficiency. I wrote
the recursive one for my email because it displayed the “._!” method which
I thought was cool.
My original code makes ._! a method of Fixnum and not Integer because I
certainly don’t ever want to take the factorial of a Bignum.
…just in case we want to calculate the factorials of numbers larger than
2**30 - 1
My point exactly. 
Daniel Carrera | OpenPGP fingerprint:
Graduate TA, Math Dept | 6643 8C8B 3522 66CB D16C D779 2FDD 7DAC 9AF7 7A88
UMD (301) 405-5137 | http://www.math.umd.edu/~dcarrera/pgp.html
On Fri, Jun 13, 2003 at 01:49:02PM +0900, Jason Creighton wrote:
Yes, of course.
But.
Lots of people are talking about making the RAA into something like CPAN.
That’s okay, but I’m sick of seeing the package management wheel being
reinvented over and over again. So it would be really nice if we could solve
it “once and for all”. Really, this has happened before in OSS. Case in point:
automake/autoconf.
Jason Creighton
On Thu, 12 Jun 2003 22:46:46 +0100 Simon Cozens simon@simon-cozens.org wrote:
Jason Creighton androflux@remove.to.reply.softhome.net writes:
…or whatever. We need more flexible package managers in general, not
just a language specific package manager every time we feel like we need
to reinvent the wheel.The problem with solving the general case once and for all is that everyone
talks about it and nobody does it. CPAN may have its flaws, but it beats
anything non-existent hands down.
“Shashank Date” sdate@everestkc.net wrote in message news:bc9uao$g0chk$1@ID-194283.news.dfncis.de…
“Mauricio Fernández” batsman.geo@yahoo.com wrote in message
I guess you meant that Ruby has no native threads but rather green
threads, etc…I must be using wrong terminology here … I meant to say OS independant.
I thought “native” meant language supported … but looks like it means OS
supported. Thanks for correcting me. What is the correct term for language
supported threading ? “Simulated threading” ?
I think of it more as “Lack of threading.”
“Yukihiro Matsumoto” matz@ruby-lang.org schrieb im Newsbeitrag
news:1055467650.532054.27264.nullmailer@picachu.netlab.jp…
So perl is better because it’s harder and you have to think more? I
doubt
any perl advocates would want you to use this argument on their side in
this one…Some people really love to solve hard puzzles. I respect them.
I’m not as good as Larry at making puzzles. sigh.
I’m quite satsified with this - no reason to sigh.
robert
In message “Re: Ruby disadvantages over Mind” > on 03/06/13, “Brett H. Williams” brett_williams@agilent.com writes:
“Aredridel” aredridel@nbtsc.org wrote in message
news:1055462560.19566.30.camel@mizar…
…or whatever. We need more flexible package managers in general, not
just a language specific package manager every time we feel like we need
to reinvent the wheel.Jason, I couldn’t agree more. The one thing that has made perl
horrendously hard to maintain on most systems is that it ignores the
system package manager, whatever that is, be it ports, portage, rpm,
dpkg, or whatever else.
I have tried to point attention to Bram Molenaar (VIM author) s A-A-P build
tool which is written in Python. I think it could be a good general tool for
package management.
Mikkel
Wise words!
On Thu, 2003-06-12 at 18:26, Hal E. Fulton wrote:
Likewise, RAA is much better than it was a year ago.
(Thanks to the hard work of certain developers.)To me, the important thing is continuous improvement.
Sure, catch the vision of what RAA should be like in
five years. But don’t stop worrying about what it
will be in six months.
“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)
CPAN was based on CTAN (used for Tex). Both are, IMHO, very high mental
overhead archives to use effectively. So high overhead, I’ve never used
them (or maybe it doesn’t have to be that high to be over my head).
Off-Topic: For Tex, I let Gerben Wierda pick what he thinks I need
from CTAN and use his i-Installer app (http://www.rna.nl/tex.html),
which is wonderful.
Back on Topic: I think RAA is excellent, much improved recently, and I
understand it will be improved on a regular basis. I also like
raa-install, because it handles dependencies so well (when they are
declared by the developer, I think).
“Shashank Date” sdate@everestkc.net wrote in message news:bc9uao$g0chk$1@ID-194283.news.dfncis.de…
“Mauricio Fernández” batsman.geo@yahoo.com wrote in message
I guess you meant that Ruby has no native threads but rather green
threads, etc…I must be using wrong terminology here … I meant to say OS independant.
I thought “native” meant language supported … but looks like it means OS
supported. Thanks for correcting me. What is the correct term for language
supported threading ? “Simulated threading” ?
I call them Lightweight Threads?
I think of it more as “Lack of threading.”
Regards,
Michael
On Fri, Jun 13, 2003 at 06:31:04PM +0900, Benjamin Peterson wrote:
Lots of people are talking about making the RAA into something like
CPAN.
That’s okay, but I’m sick of seeing the package management wheel
being reinvented over and over again.
This to me seems quite the opposite of reinventing the wheel,
while…
So it would be really nice if we could solve it “once and for all”.
…THIS seems the very definition of it.
You feel that doing something new and different is preferable to
using a model that’s up and working, and you’re using the “wheel
reinvention” analogy to justify it?
What am I missing?
I’m not disagreeing with you necessarily, but I’m wondering why we
seem to be 180 degrees apart…
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook™.
http://calendar.yahoo.com
From: “Simon Cozens” simon@simon-cozens.org
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, June 12, 2003 5:05 PM
Subject: Re: Ruby advantages over PerlJason Creighton androflux@remove.to.reply.softhome.net writes:
…or whatever. We need more flexible package managers in general, not
just
a language specific package manager every time we feel like we need to
reinvent the wheel.The problem with solving the general case once and for all is that
everyone
talks about it and nobody does it. CPAN may have its flaws, but it beats
anything non-existent hands down.Ah, the ontological proof of the existence of CPAN.
Actually I’ve always thought it worth noting that
CPAN wasn’t built in a day (to coin a phrase).
Whatever benefits it has, it wasn’t created with
all of them at once.Likewise, RAA is much better than it was a year ago.
(Thanks to the hard work of certain developers.)To me, the important thing is continuous improvement.
Sure, catch the vision of what RAA should be like in
five years. But don’t stop worrying about what it
will be in six months.The thing about dreams is that their implementation
is so daunting. That’s one reason XP (arguably) is
better than Big Design Up Front. When we dream, we
sometimes forget YAGNI and want to do everything at
once.
What is YAGNI?
On Thu, 2003-06-12 at 18:26, Hal E. Fulton wrote:
----- Original Message -----
I think this is why RubyGems went away (not to
disparage the author, who did a great job). It was
more dream than reality (though it was a good
dream). raa-install is not as good as the dream of
RubyGems; but raa-install is here now, and it works.And as Simon said so aptly, it beats anything non-
existent hands down.Hal
raa-install looks very nice, and simple to use.
But raa-install doesn’t do (yet) what the main point of the parent post
was:
RPM detected – building packages.
Downloading package list from RAA… done.
Finding syck… done, 2 prerequisites.
Downloading syck… done
making spec files… done
This is my biggest wish (thanks for articulating it so well, Ari). Every
ruby package I want to use here at work must become an RPM first. This of
course would be much easier if everyone used the same installer (I could
write a script to convert the tarball into an RPM that worked for more
than one package), but the fact remains that I have to make RPMS, someone
else might have to make .debs, etc…
I’ve got no idea how this sort of thing is handled in windows land.
By all means, I’m for a standard way of installing: but really this is
just to make it easier for me to take packages that actually play nicely
with the system’s package manager (in my case RPMs).
On Jun 13, Tom Clarke wrote:
If there were a standard set of commands as widely understood as
“./configure” “make” “make install”, then there would be no need for a
CPAN-alike repository and build and test system – wget and a shell
would be all that is needed, and a very simplistic tool to search the
RAA, download the package and execute the standard commands would be
very easy to create.It was easy, and it’s called raa-install. It works just as you
described:
http://raa.ruby-lang.org/list.rhtml?name=raainstall
http://www.rubygarden.org/ruby?QuickGuideToRaaInstall-Tom
–
---------------------------------------------- | --------------------------
Brett Williams | (970) 288-0475
| Agilent Technologies | brett_williams@agilent.com |
|---|
The thing about dreams is that their implementation
is so daunting. That’s one reason XP (arguably) is
better than Big Design Up Front. When we dream, we
sometimes forget YAGNI and want to do everything at
once.What is YAGNI?
http://xp.c2.com/YouArentGonnaNeedIt.html
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook™.
http://calendar.yahoo.com
This is my biggest wish (thanks for articulating it so well, Ari). Every
ruby package I want to use here at work must become an RPM first. This of
course would be much easier if everyone used the same installer (I could
write a script to convert the tarball into an RPM that worked for more
than one package), but the fact remains that I have to make RPMS, someone
else might have to make .debs, etc…
This is what I exposed in
and
Could you tell me if the requirements in the 2nd link are realistic?
On Sat, Jun 14, 2003 at 12:06:05AM +0900, Brett H. Williams wrote:
I’ve got no idea how this sort of thing is handled in windows land.
By all means, I’m for a standard way of installing: but really this is
just to make it easier for me to take packages that actually play nicely
with the system’s package manager (in my case RPMs).
–
_ _
__ __ | | ___ _ __ ___ __ _ _ __
'_ \ /| __/ __| '__ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
One tree to rule them all,
One tree to find them,
One tree to bring them all,
and to itself bind them.
– Gavin Koch gavin@cygnus.com
In article 1055514298.6703.24.camel@comp,
Guillaume Marcais guslist@free.fr wrote:
What is YAGNI?
You aren’t going to need it. See “The Trip Packing Dilemma” on
http://www.pragmaticprogrammer.com/articles/index.html which diccusses
YAGNI on the first page…
Hope this helps,
Mike
–
mike@stok.co.uk | The “`Stok’ disclaimers” apply.
http://www.stok.co.uk/~mike/ | GPG PGP Key 1024D/059913DA
mike@exegenix.com | Fingerprint 0570 71CD 6790 7C28 3D60
http://www.exegenix.com/ | 75D2 9EC4 C1C0 0599 13DA
I was actually starting to thing about adding this sort of feature. In
my case I was thinking it would probably be quite easy to generate
gentoo ebuild files - although I had considered running over the entire
repository and generating all the ebuilds, so that everything becomes
accessible from emerge (the gentoo package installer).
Doing it live is also possible (and may even be better).
I don’t have much experience building RPMS, but if someone sent me a
template (and perhaps a walkthrough of the steps) I would be happy to
experiment with including this feature in raa-install.
-Tom
On Fri, 2003-06-13 at 11:06, Brett H. Williams wrote:
ruby-package-get syck
RPM detected – building packages.
Downloading package list from RAA… done.
Finding syck… done, 2 prerequisites.
Downloading syck… done
making spec files… done
- rpmbuild -ba prereq1.spec
…- rpmbuild -ba prereq2.spec
…- rpmbuild -ba syck.spec
RPMS are in ~/rpm/RPMS. Installing…- rpm -i ~/rpm/RPMS/{prereq1-0.0.0,prereq2-0.0.0,syck-1.0}.noarch.rpm
Done!This is my biggest wish (thanks for articulating it so well, Ari). Every
ruby package I want to use here at work must become an RPM first. This of
course would be much easier if everyone used the same installer (I could
write a script to convert the tarball into an RPM that worked for more
than one package), but the fact remains that I have to make RPMS, someone
else might have to make .debs, etc…
This is my biggest wish (thanks for articulating it so well, Ari).
You’re welcome.
I’ve got no idea how this sort of thing is handled in windows
.msi packages, not that I’d want to deal with creating them, or some
sort of installer-exe, or a .zip with a note on where in the tree to
unpack it. All are good options, though I think the .msi approach is
the “right way”.
By all means, I’m for a standard way of installing: but really this is
just to make it easier for me to take packages that actually play nicely
with the system’s package manager (in my case RPMs).
Here, here. Systems I maintain often have a policy of “if it’s not
installed by RPM, it’s not going to be installed. And --nodeps and
–force are illegal, too”
Ari
Lots of people are talking about making the RAA into something like
CPAN.
That’s okay, but I’m sick of seeing the package management wheel
being reinvented over and over again.This to me seems quite the opposite of reinventing the wheel,
while…
Huh?
What I meant was, if we have “CPAN for Ruby”, it would be basically the same
thing as the CPAN, only for Ruby. I’m resigned to the fact that what we’ll
probably get is “CPAN for Ruby”, but what I would like to see implemented is a
general package manager, that would just so happen to work well with the RAA.
“Prefix in /usr, don’t link against X, be sure to link against Y, etc, etc”.
ie, each distro has rules set out that each package must follow.
Why can’t we just have some metadata with each package describing what options
it supports. Then our package manager could just say to package X:
“Okay, I want X11 support with GTK widgets, prefix is /usr/local, strip
binaries, don’t install the manpages, and install the package in
/tmp/lala-1234 so we can record what files are in the package before we
install it in /usr/local”.
(Of course, the software would be nowhere near as chatty. )
And we would somehow get a package that meets those specifications: We might
build it locally, we might fetch binaries from somewhere, etc.
The nice thing about this approach is that we would only have to package stuff
once. And then build the software differently for each configuration needed.
I’ve been thinking about implementing something like this in Ruby, but I don’t
have my ideas pinned down enough to start coding. I have vague ideas about
this software taking “steps” (download, extract, build, install) so that we
could take a package from any step and complete it. That is, we could have one
PC doing builds for a network of 100 that would pick up at the “install” step.
Or something like that.
Also, how all the options a package has would be tricky to represent.
So it would be really nice if we could solve it “once and for all”.
…THIS seems the very definition of it.
Now you’ve got me really confused. If making our own CPAN isn’t reinventing
the wheel, how is making our own general purpose package manager reinventing
the wheel?
You feel that doing something new and different is preferable to
using a model that’s up and working, and you’re using the “wheel
reinvention” analogy to justify it?
No, I feel that implementing basically the same thing (CPAN-like package
manager) for two (or more) languages is a waste.
I also think that having CPAN in the first place is a waste: Package managers
should be flexible enough to deal with that. We should just be able to tell
the package manager about a new source for packages and then it should be able
to download, compile and install those packages.
I want a package managers that adapts a package to the local configuration,
not one that basically dumps tarballs into the directory tree, assuming that
the package is built for the way the system is.
So basically, what I’m asking for is a package manager that will manage
packages.
Will I even find it? Or will I just always say “not flexible enough” to every
thing I try?
I don’t know.
Jason Creighton
On Fri, 13 Jun 2003 22:14:08 +0900 Michael Campbell michael_s_campbell@yahoo.com wrote: