Ruby IDE (again)
Holden Glova
Hash: SHA1
Hi folks of the list,
I'm going to bring up the topic of a Ruby IDE yet again (as I notice it
occurs frequently in the archives too). Straight to the point, I want to make
one :)
If anyone is currently making one I would like to help in some way If I can.
Some features I would like to include in an IDE are:
- - keep it file based so people can choose to use normal editors if they like
- - integrate RubyUnit with an option to test every time a syntax check comes
out with OK.
- - include well known and maybe even not currently well known refactorings to
be accomplished via point and click.
- - be able to relize new plug-ins such as a CVS plug-in or a class diagram
plug-in. Both of these would be fantastic IMHO.
My current level of Ruby is low (I've been examining it for approx 2 weeks
now), but I know several other programming langauges and now that I have
finished my comp sci degree I have free time (amazingly my job doesn't take
up all my time yet :)
I want to do this because I would like to have an IDE that did all these
features and because I would like to learn more about Ruby, lots more in
fact. I'm trying to persuade work to allow me to use in some smaller projects
in the future - currently i'm experiencing resistence. However that is
another discussion.
I'll probably open up a page at sourceforge in the near future if there isn't
a project currently in the works.
Always welcoming thoughts/criticisms/opinions.
- --
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6Or0czrxa+Gy/b/4RAgPnAJ4zmp/OB34Zu/duw3M9/xKY63hoZACdFI8b
IO9UVudkwVVcbqhU5ryfNs4=
=e6eA
-----END PGP SIGNATURE-----
Kevin Smith
>occurs frequently in the archives too). Straight to the point, I want to make
>one :)
>
>If anyone is currently making one I would like to help in some way If I can.
>Some features I would like to include in an IDE are:
I would love to see a ruby IDE. As a fan of XP, I would love to see
it grow incrementally. Grand plans for hundreds of features are
great, but I am most interested in those few features that are
really critical.
I would start to use a ruby IDE that could:
- Edit source (ideally with syntax highlights, but that could come later)
- Automatically pull in 'require' source files
- Invoke the interpreter against the source with one keystroke
With that as a base, adding class browsing, rubyunit, refactoring
abilities, plugins, etc. shouldn't be that hard. There are probably
a couple other "must-have" features, but I can't think of them. My
philosophy is to start small, and let it grow.
I would contribute to this project, if it is done in a language I
can work with. Good luck!
Kevin
Holden Glova
Hash: SHA1
Hi Kevin,
Comments are below.
On Sat, 16 Dec 2000 17:24, I think Kevin Smith wrote:
> I'm going to bring up the topic of a Ruby IDE yet again (as I notice it
>
> >occurs frequently in the archives too). Straight to the point, I want to
> > make one :)
> >
> >If anyone is currently making one I would like to help in some way If I
> > can. Some features I would like to include in an IDE are:
>
> (snipped great features)
>
> I would love to see a ruby IDE. As a fan of XP, I would love to see
> it grow incrementally. Grand plans for hundreds of features are
> great, but I am most interested in those few features that are
> really critical.
I agree completely - I was just trying to show the overall direction that I
would want to take something like this towards in the future :)
> I would start to use a ruby IDE that could:
> - Edit source (ideally with syntax highlights, but that could come later)
> - Automatically pull in 'require' source files
> - Invoke the interpreter against the source with one keystroke
I had originally planned for your points 1 and 3, but what do you mean by
point 2? Do you mean that you don't have to actually write the require, it
will automatically add the require in as you go along?
> With that as a base, adding class browsing, rubyunit, refactoring
> abilities, plugins, etc. shouldn't be that hard.
I hope so :)
> My philosophy is to start small, and let it grow.
Amen to that.
> I would contribute to this project, if it is done in a language I
> can work with. Good luck!
I had planned to write this in Ruby itself.
- --
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6OvVxzrxa+Gy/b/4RAgCBAJ9Tkewh1yZi4OqjCoAZVOvC1360+gCfY8To
bZPnB9dv7M5Er/CIDGcp7V0=
=HSoF
-----END PGP SIGNATURE-----
Kevin Smith
>> - Edit source (ideally with syntax highlights, but that could come later)
>> - Automatically pull in 'require' source files
>> - Invoke the interpreter against the source with one keystroke
>
>I had originally planned for your points 1 and 3, but what do you mean by
>point 2? Do you mean that you don't have to actually write the require, it
>will automatically add the require in as you go along?
Nope. I just want the VC++ feature where you can point to the line
that has the 'require', click a button (or two), and be viewing
that file.
>> I would contribute to this project, if it is done in a language I
>> can work with. Good luck!
>
>I had planned to write this in Ruby itself.
Ok. I assume it would rely on native-compiled extensions for stuff
like the editor itself.
I'm on board.
Kevin
Holden Glova
Hash: SHA1
On Sat, 16 Dec 2000 18:15, I think Kevin Smith wrote:
> >I had originally planned for your points 1 and 3, but what do you mean by
> >point 2? Do you mean that you don't have to actually write the require, it
> >will automatically add the require in as you go along?
>
> Nope. I just want the VC++ feature where you can point to the line
> that has the 'require', click a button (or two), and be viewing
> that file.
Ok I gotcha.
> >> I would contribute to this project, if it is done in a language I
> >> can work with. Good luck!
> >
> >I had planned to write this in Ruby itself.
>
> Ok. I assume it would rely on native-compiled extensions for stuff
> like the editor itself.
At the risk of sounding nieve - can you ellaborate what you mean by this?
> I'm on board.
Fantastic.
- --
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6Ov2Fzrxa+Gy/b/4RAp/LAJ42KVt5KxcX3/3wJzKptB7XcmzgmgCfejGy
yzAi8W5LVn/3i/yyY3HGD7Y=
=0EMJ
-----END PGP SIGNATURE-----
Kevin Smith
is done in a language I
>> >> can work with. Good luck!
>> >
>> >I had planned to write this in Ruby itself.
>>
>> Ok. I assume it would rely on native-compiled
extensions for stuff
>> like the editor itself.
>
>At the risk of sounding nieve - can you
ellaborate what you mean by this?
Speed. Unless the chosen GUI toolkit
(Tk/FLTK/GTK/FOX/???) already includes an editor
with syntax-highlighting, we'll have to find one
or write it. If we write it in ruby, I'm guessing
it would be too slow.
Kevin
Holden Glova
Hash: SHA1
On Sat, 16 Dec 2000 22:33, I think Kevin Smith wrote:
> Speed. Unless the chosen GUI toolkit
> (Tk/FLTK/GTK/FOX/???) already includes an editor
> with syntax-highlighting, we'll have to find one
> or write it. If we write it in ruby, I'm guessing
> it would be too slow.
Thats an interesting point of discussion. Would it really be slow? Has anyone
written fair sized gui applications with Ruby? Surely it would be faster than
Java swing. The issue of deciding on the gui is kind of an issue but as it
would appear by the "Guis and Rubies" thread it is one that is still to be
resolved.
I'd like to start doing some basic prototyping (spike) of this tomorrow.
Seeing as only Kevin and I seem to be in this discussion - would those of the
list prefer to continue this in private or are others interested in this? I
don't want to contribute to "noise" of this fantastic list if I can help it.
Just let me know :)
> Kevin
- --
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6O0BJzrxa+Gy/b/4RAkaOAJ9CeB4ETyTfDTRGPZ4RrhDiToeXOQCfQYeO
TwYObANwDtqB9gDAzlj9tW0=
=GNXx
-----END PGP SIGNATURE-----
Conrad Schneiker
> Seeing as only Kevin and I seem to be in this discussion - would those of
the
> list prefer to continue this in private or are others interested in this?
I
> don't want to contribute to "noise" of this fantastic list if I can help
it.
> Just let me know :)
My vote is to please keep this discussion public.
It's allegedly not unusual for interested parties to outnumber the number of
posters by factors of 10, 20, 50, or more.
As long as the subject line is half-way usefully descriptive, people who
aren't interested can easily skip over it.
Conrad
Stephen White
> Seeing as only Kevin and I seem to be in this discussion - would those of
> the list prefer to continue this in private or are others interested in
> this? I don't want to contribute to "noise" of this fantastic list if I
> can help it. Just let me know :)
I'm following the discussion, just not saying much because I'm not sure
how accurate my current opinions are.
All factors combined, I think Gtk+ is currently the most promising GUI
toolkit. It has a fairly primitive API for GUI builders which I've used
in a previous project. This API is reported to have been upgraded quite
a bit in the upcoming Gtk 2.0, so wrapping this API may be better than
SWIGging all the C level functions across.
Gtk+ has its own dynamic object system with reference counting, which is
closer to Ruby's than it is to C++'s. For this reason, Gtk-- has problems
wrapping Gtk++ as it tries convert things to C++ semantics.
I have some code from another project that uses the GUI builder API and
just got the Programming Ruby book, so I'll play around with this. Not
with the intention of releasing the next wrapper, but so I can better
assist with any GUI/IDE project.
Richard A.Schulman
>...All factors combined, I think Gtk+ is currently the most promising =
GUI
>toolkit....
Does Gtk+ provide a sophisticated table widget, for
row-and-column database display and update?=20
Richard Schulman
Bob Calco
note that Borland is soon to release a version of Delphi on Linux code-named
Kylix. Version 6 of Delphi/C++ Builder will support a cross platform library
for GUI objects called CLX, such that you can code an entire native
application on Win32 using this library, and recompile the same project in
Linux to generate the same application natively on Linux. This isn't
interpreted byte code, a la Java, but real compiled machine code for both
platforms.
I'd be interested in doing two things: 1.) Helping to build a Ruby IDE; and
2.) Creating a GUI widget library for Ruby based on the CLX library. Both
the IDE and the GUI library would work on both Win32 and Linux, assuming of
course that Borland delivers on this very interesting concept.
Any thoughts?
Sincerely,
Bob Calco
-----Original Message-----
From: Richard A.Schulman [mailto:RichardA...@att.net]
Sent: Saturday, December 16, 2000 10:34 AM
To: ruby-talk ML
Subject: [ruby-talk:7437] Re: Ruby IDE (again)
Stephen White writes:
>...All factors combined, I think Gtk+ is currently the most promising GUI
>toolkit....
Does Gtk+ provide a sophisticated table widget, for
row-and-column database display and update?
Richard Schulman
markus jais
> I'd be interested in doing two things: 1.) Helping to build a Ruby IDE; and
> 2.) Creating a GUI widget library for Ruby based on the CLX library. Both
> the IDE and the GUI library would work on both Win32 and Linux, assuming of
> course that Borland delivers on this very interesting concept.
this sound quite interesting, but one question.:
will CLX open source and when which license will be used?????
I heard something about making it open source , but I do not
know for sure.
I know only, that it should work on windows and it should
support both Gnome and KDE, which would be quite helpful
if won't be open source, I think a lot of developers (including me)
would not like to use it.
markus
Matthew PATTISON
> and
> > 2.) Creating a GUI widget library for Ruby based on the CLX library. Both
> > the IDE and the GUI library would work on both Win32 and Linux, assuming
> of
> > course that Borland delivers on this very interesting concept.
>
> this sound quite interesting, but one question.:
> will CLX open source and when which license will be used?????
> I heard something about making it open source , but I do not
> know for sure.
refereneced on that page:
...CLX, the underlying component library, will be released under a
dual license, allowing open source developers to code under the GPL or
commercial developers to purchase a commercial license.
also:
...earlier reports elsewhere that the Kylix IDE itself would be released as
open source software are flatly wrong.
I presume that means that whilst the Kylix IDE will not be open source, CLX
will be.
Matt Pattison
Bob Calco
>if won't be open source, I think a lot of developers
>(including me) would not like to use it.
The honest answer is a.) I don't know, and b.) come to think of it, probably
not. I doubt Borland would invest the kind of money they are into Kylix if
it was going to be Open Source; on the other hand, Borland is quirky. They
did release InterBase to the Open Source world. Stranger things have
happened.
I myself am not religious on the issue of Open Source. I think it's a Good
Thing. But I also think people who choose to get paid for their programming
have that right too, as long as there remain people of sound mind willing to
pay them. A vow of poverty is a matter of personal conviction and
conscience. I might myself take such a vow, but for the need to feed my kids
and put them through college and buy that big house my wife wants. ;)
However, in my spare time, I would enjoy being part of Open Source projects,
mainly because they are typically interesting in a way that "commercial"
development tends not to be, except in some rare and beautiful instances.
Sincerely,
Bob Calco
-----Original Message-----
From: markus jais [mailto:mj...@web.de]
Sent: Saturday, December 16, 2000 1:00 PM
To: ruby-talk ML
jwei...@one.net
Richard> Does Gtk+ provide a sophisticated table widget, for
Richard> row-and-column database display and update?
I don't know what you would call *sophisticated*, but it does supply a
table widget with column headers and resizable columns. Here's a
screen shot of class broswer for Eiffel with several table widgets in
view.
http://w3.one.net/~jweirich/pics/ebrscreen.gif
--
-- Jim Weirich jwei...@one.net http://w3.one.net/~jweirich
---------------------------------------------------------------------
"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)
Conrad Schneiker
Roughly speaking (i.e. leaving out various differentiating qualifications),
these sorts of things are major reasons why Qt never caught on as the
successor to Tk, and were a big stimulus (among other things) for developing
GTK+, reviving wxWindows (and probably for developing FOX too for that
matter).
Not sticking with open source GUI extensions creates (in many cases) lots of
practical (economic, legal, deployment, managerial permission) problems for
(many) users/developers of <language>/<GUI>.
I'm all for people making money off of software--indeed, I hope that people
figure out how to make tons of money off of Ruby software so as to increase
the incentives for maximum world-wide use, and to draw maximum resources
into developing "Ruby/CPAN". But (IMHO) the Ruby community would
(eventually) be (much) better off in the overall average long run by
encouraging "2-nd order" or "Linux-style" profiteering on products and
services derived from a common open source core, especially in connection
with whatever becomes its mainstream, available out-of-the-box GUI(s).
Conrad
Ing. Roman Fischer
This concept still expects a Java-VM at the target machine and a call of a
method inside of the jar. So you cannot deliver a self-installing
application by just putting all your classing into a jar.
Roman
> Von: Matt Harrington <ma...@msg.ucsf.edu>
> Antworten an: ruby...@netlab.co.jp
> Datum: Sun, 17 Dec 2000 06:22:48 +0900
> An: ruby...@netlab.co.jp (ruby-talk ML)
> Betreff: [ruby-talk:7470] Re: Packaging Ruby
>
> On Fri, Dec 15, 2000 at 09:52:22PM +0900, Aleksi Niemelä wrote:
>
>> Having said that, I wonder if it would be a problem to write an utility
>> which grabs all the used libraries and produces a "local copy version" of
>> them. Which in turn could be packaged by various tools and shipped to
>> "customer".
>
> Something like Java's "jar" utility would be nice.
>
> ---Matt
>
Matt Harrington
> A jar-file just contains the classes and other files of your application.
> This concept still expects a Java-VM at the target machine and a call of a
> method inside of the jar. So you cannot deliver a self-installing
> application by just putting all your classing into a jar.
all true. what i meant was, assuming target machines have a ruby
interpreter installed, it would be nice to have a utility along the lines
of 'jar' which allowed for many distint class files to be archived
together. perhaps then the whole shebang could be run with:
ruby AllMyClasses.rbar
as you point out, this isn't the same as having an executable to
distribute to computers which don't already have ruby installed. it only
helps those of us who like to have separate files for each class (as in
Java) but don't want to distribute more than one file.
`m
Joseph McDonald
> the incentives for maximum world-wide use, and to draw maximum =
resources
> into developing "Ruby/CPAN". But (IMHO) the Ruby community would
I want to be in on developing a Ruby CPAN (making RAA better). I have
lots of ideas. Of course the system must be written in ruby. Here's
one idea for starters: each module should get it's own mailing list
which is archived on the web (using blade technology, or next generation
blade... whatever those green dwarves are working on. :-). ). Of course
the ruby IDE should have some nice hooks into said discussion trees and
the owner of the module should have root access to the discussions
if s*he likes.
Is there already an effort for making a better RAA? If not, should
we start? If so, how can I help? I can do the hosting if neccessary.
-joe
W. Kent Starr
> Roughly speaking (i.e. leaving out various differentiating qualifications),
> these sorts of things are major reasons why Qt never caught on as the
> successor to Tk, and were a big stimulus (among other things) for developing
> GTK+, reviving wxWindows (and probably for developing FOX too for that
> matter).
>
> Not sticking with open source GUI extensions creates (in many cases) lots of
> practical (economic, legal, deployment, managerial permission) problems for
> (many) users/developers of <language>/<GUI>.
>
> I'm all for people making money off of software--indeed, I hope that people
> figure out how to make tons of money off of Ruby software so as to increase
> the incentives for maximum world-wide use, and to draw maximum resources
> into developing "Ruby/CPAN". But (IMHO) the Ruby community would
> (eventually) be (much) better off in the overall average long run by
> encouraging "2-nd order" or "Linux-style" profiteering on products and
> services derived from a common open source core, especially in connection
> with whatever becomes its mainstream, available out-of-the-box GUI(s).
>
Stirctly speaking, nothing in the GPL precludes making money from software
development. What it _does_ require is making source code available. Old-style
bastions of proprietary development argue that doing so reduces their
competiveness in the marketplace. New style businesses (including IBM which
is, in b2b speak, "reinventing itself") are learning this is not necessarily
the case and that open-sourcing leads to more rapid, more bug-free development
(qualified beta testers can provide fixes along with reporting, for example).
In the current marketplace, speed _is_ king, so open sourcing can be argued as
a competive _advantage_ rather than a potnential downside.
<soapbox>
Now, in a commercial venue, there _could_ be a downside to
"this_$software_$ux_but_does_something_cool.exe" source code because your
competor can come out with "$sucky_parts_fixed_and_now_does_everything_cool.exe
and blow your marketshare away! But, in the general scheme of things, what is
wrong with that, especially when you consider that end users (and _all_ of us
are in some way "end users") ultimately benefit.
Cornering a market with the only application that performs a specific operation
poorly via copyright and patent, rahter than by quality and features, is
IMO socially unconscionable; in many places in other industries it is also
considered fraud by the applicable legal system.
Competition is great because it encourages (some might say forces) good design,
good engineering and good quality control. Open source fosters this kind of
beneficial competition.
</soapbox>
Kent Starr
elde...@mindspring.com
chad fowler
> I obtained the domain name rubyist.org for the
> community site.
> It would be RAA + forum (like slashdot?) + Wiki +
> whatever.
>
> Volunteers are welcome.
How shall we start? I'll help.
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
Yukihiro Matsumoto
In message "[ruby-talk:7484] Ruby RAA"
on 00/12/17, "Joseph McDonald" <j...@vpop.net> writes:
|Is there already an effort for making a better RAA? If not, should
|we start? If so, how can I help? I can do the hosting if neccessary.
I obtained the domain name rubyist.org for the community site.
It would be RAA + forum (like slashdot?) + Wiki + whatever.
Volunteers are welcome.
matz.
Ben Tilly
>
>Thanks for the excellent input Ben!
You are welcome. One point I think that cannot be made
strongly enough. What matters is not just having things
there, but rather having confidence that the wheels which
are there, will work as advertised.
Also while CPAN is often cited and does indeed work well,
IMHO Debian (http://www.debian.org/) has tackled a similar
problem and done a better job.
> > 1. Have a core team managing the namespace, testing, and
> > telling people about duplicated functionality.
>
>Does CPAN do that? I see a lot of duplicated functionality.
>not that that's a bad thing, different strokes for different
>folks I always say. But a nice summary of similiar modules
>by an impartial would be nice (witness the numerous templating
>modules on CPAN... how do you pick?).
Yes, there is a team of testers that serves an advisory role.
They mainly test whether it builds on different platforms,
and tell the author about similar modules, and advise on
possible namespace conflicts. Authors still decide
whether or not to proceed, and frequently do if they think
that their module does something different.
How do you pick a templating module? Well I listen to
Randal Schwartz and pick Template::Toolkit. :-) Seriously
do take a look at it. Of all of the template solutions to
emerge in the Perl world, it is by far the best. If Ruby
wants to produce its own templating solutions, that one
would be an excellent model to work from. (I think that
second is Text::Template. But it is far less flexible.)
See http://search.cpan.org/search?dist=Template-Toolkit
for details.
> > 2. Have a standard tool ("perl -MCPAN -e shell") to interact
> > with CPAN.
>
>Agreed! What makes it *king* is the dependency checking and
>automatic installs of dependencies. (although it doesn't always work...)
Likewise look at Debian.
> > 3. Have the standard installation save important local
> > information in a way that module authors can use.
>
>you mean for bug reporting?
That or for installation. Try "perldoc Config" and take a
look at what is available. All of that information is
captured by Perl at install time, and when you try
"perl Makefile.PL" any and all of that information can go
into the makefile.
> > 4. Have a standard directory layout decided at installation
> > for where things go.
>
>agreed. key.
>
> > 5. Have a standard method of inlined documentation,
> > automatic regression tests, etc.
>
>key. especially the regression tests.
>
> > 6. Have a standard packaging tool (h2xs) for producing
> > modules in a standard format. (Making the entire
> > "make Config", "make", "make test", "make install"
> > process standardized across modules.)
>
>would probably have a huge impact on people placing their work on
>RAA. the biggest drag is getting something "distribution ready"
>pure grunt work, rubyites (and perlites) don't want to be bothered
>by such drab work.
Exactly. When you look at CPAN, the parts of the proceedure
made automatic by h2xs happen consistently. The parts that
do not are inconsistent and often don't happen.
Likewise take a look at Debian and debmake. Debian is a very
consistent system despite being put together by a distributed
group, and a large part of that is having clearly decided
policies on where things go, and a standardized packaging
tool that makes it easy to follow that policy.
> > 7. Have a standard way to check versions, state
> > dependencies, and so on.
>
>Do you mean that the user could say: puts $class.version; $class.depends ?
Perl doesn't do a great job on this. But if you assign to
$VERSION in a module, then people requiring the module
can put a version check into the load, and the CPAN tool
can detect whether or not your version is sufficiently
up to date. But this is optional and doesn't happen as
consistently as it should.
Debian does a much better job on this. They have a
standard packaging format for their package (the .deb
archive) that carries version information.
> > 8. Have a standard tool to check whether you have
> > indeed done it right.
>
>okee dokee
For instance if you say that your dependencies are Foo and
Bar, it should load your module and see if there is some
other Baz out there that you are loading as well. :-)
> > 9. Have a standard bug reporting mechanism for installed
> > modules.
>
>Amen.
Perl doesn't have this and really, really needs it. Debian
does and it really works. It is critical to be able to go
to a single place and browse open bug reports. It also is
an excellent way to detect when something is not really
being maintained any more.
Today there is no good way of finding out which CPAN modules
are buggy and which are not. There is no good way to find
out whether someone has already pointed out the bug which
you have to report. There is no good way for an eager
volunteer to find out what needs to be worked on.
I cannot stress enough that Perl got this seriously wrong.
And once people have their own ways to handle these things,
it would be very hard to just go and say, "OK, here is the
new bug-tracking system, everyone has to use it." This
has to be gotten right from the start.
>I'd add the obvious: good search mechanism and good hierarchical
>organization. CPAN has that (although it does break more than
>it should IMHO).
Yes.
>Also, I know there is a movement to categorize applications as well
>as modules on CPAN. That is also a good idea.
Another shortcoming. CPAN's system is only good for modules,
which is one reason that there has been room for some of the
other application archives out there...
A final note. The most successful model to emulate IMO is
Debian, not CPAN.
Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
Matt Licholai
system. As a Ruby newbie I'm still working on being productive with the
language, however, a packaging system which consistently put all the right
pieces in the right places would be a great asset in setting up and learning
Ruby.
I'm currently finding myself spending lots of time in trying to install
downloaded scripts and assemble the pieces to make them work instead of
concentrating on understanding how they work. Having Debian on a Linux box at
home, I agree that the approach taken by them is very useful and productive.
Domo,
Matt Licholai
Dave Thomas
> I second the idea that Debian is an outstanding model to follow for
> a packaging system.
Could someone post a short summary of what makes Debian good?
Thanks
Dave
Matt Licholai
the end user perspective):
Standardized file/directory location
Dependency checking
Automated install scripts (set needed environment variables, etc.)
Preservation of configuration files (were applicable)
Rollback/removal options
Short description of package contents and functionality
Indication of stability/maturity of the package (i.e. stable,
unstable)
Ability to download from centralized repositories (using apt)
I'm sure other will find other points that I have overlooked, but the
above represent things that make the system more productive than other
packaging options. I have not yet created any Debian packages, so I feel
unqualified to discuss their packaging tools.
Thanks,
Matt
Dave Thomas
> Here are what I feel the Debian packaging system can do rather well (from
> the end user perspective):
Matt:
Thanks for the list. Any have anything to add?
Dave
John Cusick
<kevi...@pacbell.net> wrote:
> I'm going to bring up the topic of a Ruby IDE yet again (as I notice it
>>occurs frequently in the archives too). Straight to the point, I want to
>>make one :)
>>
>>If anyone is currently making one I would like to help in some way If I
>>can. Some features I would like to include in an IDE are:
> (snipped great features)
>
> I would love to see a ruby IDE. As a fan of XP, I would love to see it
> grow incrementally. Grand plans for hundreds of features are great, but
> I am most interested in those few features that are really critical.
>
> I would start to use a ruby IDE that could:
> - Edit source (ideally with syntax highlights, but that could come
> later)
> - Automatically pull in 'require' source files
> - Invoke the interpreter against the source with one keystroke
Not being much of a programmer (more a hobbyist), I'm not sure
about how relevant this is, but I was recently checking out a fairly
simple, in some regards, but nice terminal-based IDE called motor
for C/C++ used with *nix systems. The first thing I thought to myself,
as I am about a hundred pages into the new Ruby book, was wouldn't
this be nice if it were Ruby-centric. A search on Freshmeat for "motor"
should turn it up.
John C.
Matt Harrington
> Here are what I feel the Debian packaging system can do rather well (from
> the end user perspective):
I once heard that Debian's system is similar to the packages system in
FreeBSD (pkg_add, et al.) Anyone know if this is true? I've not used
Debian.
---Matt
Holden Glova
Hash: SHA1
They have this awesome program called "apt-get" (apt stands for Advanced
Package Tool I think). Basically you would do something like this.
apt-get update
apt-get install ruby
apt will then go search the database files, download ruby and any unmet
dependencies on your system, install them, followed by setting them up. In a
nutshell that is what it does. I can't get enough of apt-get :)
> Thanks
Not a problem
> Dave
- --
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6PZqozrxa+Gy/b/4RAtsRAKCaW8Eq4JaQAOiCrD4dPhjEwuzNNwCfU9TT
LmtoKRjPM7swdxyMNphotyo=
=6opX
-----END PGP SIGNATURE-----
Dave Thomas
> |> Volunteers are welcome.
> |
> |How shall we start? I'll help.
>
> We have to set up channel of communication first.
> Probably a list or wiki?
I started taking notes on
http://www.pragprog.com:8080/ruby?RubyArchive
Everyone please feel free to edit/add/reorganize as you see fit.
Dave
Yukihiro Matsumoto
In message "[ruby-talk:7506] Re: Ruby RAA"
on 00/12/17, chad fowler <chadf...@yahoo.com> writes:
|> Volunteers are welcome.
|
|How shall we start? I'll help.
We have to set up channel of communication first.
Probably a list or wiki?
matz.
Conrad Schneiker
# ma...@zetabits.com (Yukihiro Matsumoto) writes:
#
# > |> Volunteers are welcome.
# > |
# > |How shall we start? I'll help.
# >
# > We have to set up channel of communication first.
# > Probably a list or wiki?
#
# I started taking notes on
#
# http://www.pragprog.com:8080/ruby?RubyArchive
#
# Everyone please feel free to edit/add/reorganize as you see fit.
I have a proposal/recommendation: when you add things, how about "cc'ing"
things to comp.lang.ruby or ruby-list (with a descriptive subject heading)
so that others can (at their option) follow along and/or be notified of
recent additions?
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)
Dave Thomas
> # Everyone please feel free to edit/add/reorganize as you see fit.
>
> I have a proposal/recommendation: when you add things, how about
> "cc'ing" things to comp.lang.ruby or ruby-list (with a descriptive
> subject heading) so that others can (at their option) follow along
> and/or be notified of recent additions?
Or, because it'd be nice if the burden on contributors was minimal,
how about if I arrange for a list of changes to be sent to the
newsgroup/ML periodically?
Dave
Hal E. Fulton
In general, anything that can be done automatically, should be. Notable
exceptions are launching missiles, making love, etc.
Hal
Conrad Schneiker
# "Conrad Schneiker" <sch...@us.ibm.com> writes:
#
# > # Everyone please feel free to edit/add/reorganize as you see fit.
# >
# > I have a proposal/recommendation: when you add things, how about
# > "cc'ing" things to comp.lang.ruby or ruby-list (with a descriptive
# > subject heading) so that others can (at their option) follow along
# > and/or be notified of recent additions?
#
# Or, because it'd be nice if the burden on contributors was minimal,
# how about if I arrange for a list of changes to be sent to the
# newsgroup/ML periodically?
Good idea.
And speaking of making all things Ruby insanely convenient (tm), I wonder
if some mechanism could be set up to work in the other direction. Could
newsgroup/ML posters flag their post with (say, for purposes of
illustration) "## wiki <topic> ##" (ignored unless starting in col.1) so
that successive posts will be appended (and maybe labeled "Pending
addition") to a trailing "input queue" for a given topic (and if the
<topic> didn't match, default to the predefined "nomatch" topic)?
GOTO Kentaro
In message "[ruby-talk:7541] Re: Ruby RAA"
on 00/12/18, Dave Thomas <Da...@PragmaticProgrammer.com> writes:
>I started taking notes on
>
> http://www.pragprog.com:8080/ruby?RubyArchive
>
>Everyone please feel free to edit/add/reorganize as you see fit.
Great!
But why don't you use RWiki? That allows us to write in our RD :-)
See ((<RAA:RWiki>)) and ((<RAA:RWiki-installer>)).
-- gotoken
Dave Thomas
> But why don't you use RWiki? That allows us to write in our RD :-)
> See ((<RAA:RWiki>)) and ((<RAA:RWiki-installer>)).
To be honest: I had for other UseModWikis set up already: creating a
new one takes about ten seconds. Installing and managing RWiki is far
more complex (even with the installer). I was also concerned by the
potential for the background demon to grow in size: this Wiki is
running on a fairly small machine outside the firewall. So, UseModWiki
was a pragmatic choice.
I also thing that RWiki has a serious flaw. References to undefined
pages show up just like normal links. This isn't the way a wiki is
supposed to work. That fact that other wikis display ToBeDefined as
ToBeDefined_?_ acts as both an aide memoire _and_ as an invitation for
others to complete the work.
However, I also know that it might not be the most politically correct
thing to run a non-Ruby Wiki.
What do folks think?
Dave
Stephen White
> And speaking of making all things Ruby insanely convenient (tm), I wonder
> if some mechanism could be set up to work in the other direction. Could
> newsgroup/ML posters flag their post with (say, for purposes of
> illustration) "## wiki <topic> ##" (ignored unless starting in col.1) so
> that successive posts will be appended (and maybe labeled "Pending
> addition") to a trailing "input queue" for a given topic (and if the
> <topic> didn't match, default to the predefined "nomatch" topic)?
It's great seeing some of the items on my IDE wish list coming to life! This
isn't in the IDE, but getting this mechanism in place will be great now and
could be built into a Ruby IDE later on. :)
Hugh Sasse Staff Elec Eng
> Here are what I feel the Debian packaging system can do rather well (from
> the end user perspective):
>
> Standardized file/directory location
This is something I detest. When I have setup my system to have
system software in one place, downloaded software for the whole
network in antother place, and machine specific code in a third place,
I do _not_ want some package telling me that I must put the software
in x/y/z. This is what really annoys me about Imake.
I would plead for one level of indirection: allow me to setup the
standard places at configuration time. Default values are acceptable,
of course. I could do this when I configure Ruby, and then the
downloaded apps could ask me if my settings are what I wanted.
The rest of the points are good.
Hugh
h...@dmu.ac.uk
Ben Tilly
This is exactly what Perl does. Perl's system has a standard
search path that you can see with the following command:
perl -MData::Dumper -e 'print Dumper \@INC'
The defined locations in order stand for:
- OS-specific core packages
- OS-independent core packages
- OS-specific installed packages
- OS-independent installed packages
- current working directory
The separation of OS-specific and OS-independent is for the
benefit of people serving packages off of a fileserver that
are picked up on multiple operating systems. I am not sure
how much this facility is being used. The most commonly
felt need not addressed by the system is the ability for
users to do local installs. Therefore I would suggest that
(at least for *nix) the following might work better:
- Core Ruby
- Globally installed packages
- User installed packages
I have more to say, but I will say it on the wiki. :-)
NAKAMURA, Hiroshi
> From: Dave Thomas
> Sent: Monday, December 18, 2000 11:55 PM
> got...@math.sci.hokudai.ac.jp (GOTO Kentaro) writes:
>
> > But why don't you use RWiki? That allows us to write in our RD :-)
> > See ((<RAA:RWiki>)) and ((<RAA:RWiki-installer>)).
At first, I must thank to gotoken-san for citing RWiki.
And also thanks to Dave for pointing out the truth.
> To be honest: I had for other UseModWikis set up already: creating a
> new one takes about ten seconds. Installing and managing RWiki is far
> more complex (even with the installer). I was also concerned by the
> potential for the background demon to grow in size: this Wiki is
> running on a fairly small machine outside the firewall. So, UseModWiki
> was a pragmatic choice.
I almost agreed. RWiki is rather complex and heavy
for this purpose (discussion, organize, and reorganize
ideas). I endose your pragmatic choice.
> I also thing that RWiki has a serious flaw. References to undefined
> pages show up just like normal links. This isn't the way a wiki is
> supposed to work. That fact that other wikis display ToBeDefined as
> ToBeDefined_?_ acts as both an aide memoire _and_ as an invitation for
> others to complete the work.
Someone claimed us to support this behavior like
"ToBeDefined?", but we have decided not to support it.
Since you can see if the page is defined or not at the
bottom of the page in RWiki, we did not think it
important. Hmm, I'm still not familier to the way a
wiki is supposed to work. I still cannot understand
what Wiki is for since [ruby-talk:4801].
> However, I also know that it might not be the most politically correct
> thing to run a non-Ruby Wiki.
I never think it non-PC. TIMTOLTDI.
// NaHi
Dave Thomas
> (at least for *nix) the following might work better:
>
> - Core Ruby
> - Globally installed packages
> - User installed packages
>
> I have more to say, but I will say it on the wiki. :-)
I've added this discussion to
http://www.pragprog.com:8080/ruby?DebiansGoodPoints
Dave
Ben Tilly
Oops, I said I would say more on the wiki because I planned
to go flesh the comment out. See
http://www.pragprog.com:8080/ruby?ConfigIssues
for more detailed discussion, and a suggested outline for a
standardized configuration scheme for stuff in RAA which is
also easy to modify to suit common development needs.
Sorry for the duplication.
Conrad Schneiker
# got...@math.sci.hokudai.ac.jp (GOTO Kentaro) writes:
#
# > But why don't you use RWiki? That allows us to write in our RD :-)
# > See ((<RAA:RWiki>)) and ((<RAA:RWiki-installer>)).
#
# To be honest: I had for other UseModWikis set up already: creating a
# new one takes about ten seconds. Installing and managing RWiki is
# far more complex (even with the installer). I was also concerned by
# the potential for the background demon to grow in size: this Wiki is
# running on a fairly small machine outside the firewall. So,
# UseModWiki was a pragmatic choice.
#
# I also thing that RWiki has a serious flaw. References to undefined
# pages show up just like normal links. This isn't the way a wiki is
# supposed to work. That fact that other wikis display ToBeDefined as
# ToBeDefined_?_ acts as both an aide memoire _and_ as an invitation
# for others to complete the work.
#
# However, I also know that it might not be the most politically
# correct thing to run a non-Ruby Wiki.
#
# What do folks think?
This instance of folks thinks that recent mass floggings (which
non-fanatics perceived as tactul putlic councelling) of politically
correct Perl zealots by a couple of the leading Perl developers
exhibits the right attitude -- use the best tool for the circumstances
and job at hand.
Kevin Smith
wrote:
>got...@math.sci.hokudai.ac.jp (GOTO Kentaro) writes:
>
>> But why don't you use RWiki? That allows us to write in our RD :-)
>
>more complex (even with the installer). I was also concerned by the
>potential for the background demon to grow in size: this Wiki is
>was a pragmatic choice.
>
>I also thing that RWiki has a serious flaw. References to undefined
>others to complete the work.
>
>
I think it would be ideal to run a ruby wiki. If
it's not mature enough yet, or has problems
specific to your needs, then you shouldn't run it
(yet). I would like to see the community step up
and add features or make fixes that would allow
you to use it successfully.
Kevin
>
>Dave
>
>
Dave Thomas
> I think it would be ideal to run a ruby wiki. If
> it's not mature enough yet, or has problems
> specific to your needs, then you shouldn't run it
> (yet). I would like to see the community step up
> and add features or make fixes that would allow
> you to use it successfully.
Don't get me wrong here. RWiki is a very sophisticated Wiki, probably
one of the most comprehensive out there. In my case, the extra
complexity wasn't needed, that's all.
Dave
NAKAMURA, Hiroshi
> From: Dave Thomas
> Sent: Tuesday, December 19, 2000 1:29 PM
> In my case, the extra
> complexity wasn't needed, that's all.
It's from a not_familier_to_the_wiki_way's poiint of view.
One of the extra complexity but seems to be useful and
to help discussion I think is putting a link to blade
archive easily.
In RWiki, ((<ruby-talk:1234>)) is rendered as a link to
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/1234
In Tiki, a token defined in
http://todo.org/cgi-bin/en/tiki.cgi?c=v&p=InterWikiName
is rendered as a link to other Wiki
(cf. http://todo.org/cgi-bin/en/tiki.cgi?c=v&p=InterWiki)
Example of the feature:
http://www.jin.gr.jp/~nahi/RWiki/?cmd=view&name=RAA
I cannot read/join the wiki at
http://www.pragprog.com:8080/ruby since I cannot access
non-80 web because of my security policy (of course
this is my fault, cannot be helped.) Forgive me if
your wiki already has this feature.
// NaHi
Dave Thomas
> One of the extra complexity but seems to be useful and to help
> discussion I think is putting a link to blade archive easily.
That's a fine idea: I added it. You can now link to an article with
ruby-talk:1234
in the text.
Thanks
Dave