Here’s an idea. How about a wiki for Wanted/Requested Libraries?
It exists, of course. That’s the problem with Wikis. Creating a page
like this seems like a great idea, and of course it is in some sense.
But you don’t know about it until you ask here. And for every person
who asks, there’s 10 who don’t.
I can’t remember the name of the page, but MissingLibraries might just
get there.
Most of the time I had to use good ol’ Perl instead of Ruby is because
of libraries. CPAN is so complete, while Ruby still trails quite
behind (not just behind Perl, Python too). Several personal examples of
mine:
a fast/C-based buffer XOR (last time I checked there are several libs
to do bitwise operation but strangely none can XOR two string buffers);
diff algorithms (there are several in Perl);
interacting with subversion (there are already several SVN::* Perl
modules showing up in CPAN);
None of these sound difficult (given that Perl implementations exist).
If I had a need for something like those, and had the time to do so,
I’d port to Ruby as needed. I don’t think the time required would be
all that great, either.
The Requested Libraries wiki could let people tell what modules they
need, and let other people vote too what they would like to see most.
Then yet some other looking for projects will know what is currently on
demand.
There’s no evidence that the Ruby economy works in this way. People
scratch itches rather than looking for in-demand projects.
Not that anything you’ve written is a bad idea… A well-known,
up-to-date list of requested libraries would be a great resource.
Cheers,
Gavin
···
On Tuesday, May 11, 2004, 5:32:16 AM, David wrote:
Here’s an idea. How about a wiki for Wanted/Requested Libraries?
Ok idea.
[In order not to forget this idea I thus post it here]
I have also an idea: Recently I have been thinking of devote one day
in my calender to review 10 ruby-projects… I don’t know which projects
I wish to review (maybe the last 10 of top 20 on rubyforge?)
Then I would have 1 hour to each project, and could write some interesting
stuff about them. How was installation? What is their purpose? Is the
goal of the project fullfilled? How was documentation? How was code?
When done I would post the review-results at ruby-talk?
Too bad I don’t have time fore it at the moment… but I hope.
Suggestions?
> Yes, I did recompile it. If you have a simple way to test that
everything
> still works I would appreciate it.
See if the unit tests (in the "tests" subdirectory) pass. Change to
that directory and type:
ruby TS_All.rb
If I recall correctly, a couple of the tests for the FXFileStream
classes are broken on Win32 (but they are benign failures).
I just tried this, and to my horror, FXRuby wasn't in the distribution at
all! I didn't get any build errors on the installer (which includes FXRuby),
so I need to figure out what happened here, and then run your test.
Thanks,
Curt
···
On Wed, 30 Jun 2004 15:04:07 -0500, Curt Hibbs <curt@hibbs.com> wrote:
> This is fine with me. When there are multiple versions
installed, there also
> needs to be a pointer to the default installation (the one
that is on the
> path). wxRuby currently uses this to decide where to install itself.
> Is there anyone out there (other than wxRuby) that is using
the current
> registry schema?
> How's this look (as an example relative to
> "HKEY_LOCAL_MACHINE\SOFTWARE"):
I vote against it because it assumes that your installer is the only
one in the windows world. For example in the first month i shipped my
own ruby distribution with my IDE and maybe i will do this later again
when i target people at "download.com" or "winfiles.com" to try
another programming language. While the core should be the same, the
"site-lib" directory tree could be different.
"pp14" is a shortcut for "pragmatic programmers" or however you want
call it, maybe only 14 because this is the installer for the masses.
You see the problem in the python world where there is the www.python.org installer and then there exists also a few
"scientific" pythons and of course the one from ActiveState.
Think that my solution is a little bit more flexible, and its only a
few lines more for persons who use it/write it.
This sounds reasonable to me, and it doesn't look like anyone else (besides
me in wxRuby) is using these registry entries, so I don't have to worry
about breaking things for anyone else.
As you see in the patch, when require 'tcltklib', environment variables
which starts 'RUBYTK_' replace to the one removed 'RUBYTK_' (e.g.
RUBYTK_TCL_LIBRARY --> TCL_LIBRARY).
If the target enviromnent variable already exists and the backup
variable does not exist (it means that to make backup is only once),
the backup variable are make (e.g. TCL_LIBRARY --> X_RUBYTK_TCL_LIBRARY).
Can it satisfy you?
Yes, thats better.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
At Thu, 8 Jul 2004 12:23:43 +0900,
Hidetoshi NAGAI wrote in [ruby-talk:105546]:
> The Ruby Installer still conflicts with because the TCL_LIBRARY is set
> to a value that python can't handle (python needs TCL 8.4).
>
> I think this is a show stopper bug.
>
> I really get angry every time i install Ruby and can't access "idle"
> (which is Python's standard IDE) anymore.
>
> Can you please patch the main function in rubys "main.c" file
> until the tk maintainer fixes this in the right place.
I'll modify Init_tcltklib() of tcltklib.c such like the following.
No, eban says those environment variables are not need at all.
RubyInstaller should just set PATH, but not TCL_LIBRARY. And
RUBY_{TCL,TK}_DLL are used only if tcltklib is compiled with
--enable-tcltk_stubs, but RubyInstaller doesn't.
I have also an idea: Recently I have been thinking of devote one day
in my calender to review 10 ruby-projects… I don’t know which projects
I wish to review (maybe the last 10 of top 20 on rubyforge?)
Then I would have 1 hour to each project, and could write some interesting
stuff about them. How was installation? What is their purpose? Is the
goal of the project fullfilled? How was documentation? How was code?
When done I would post the review-results at ruby-talk?
it would be nice
But maybe it could be better to put it on the WhyRuby wiki and just
show the link to the page here
Too bad I don’t have time fore it at the moment… but I hope.
doh!
···
il Wed, 12 May 2004 17:21:54 +0900, Simon Strandgaard neoneye@adslhome.dk ha scritto::
> Are you thinking of including wxRuby in the Rubyinstaller as well ?
Yes please - if you think it is stable enough. "0.3" was not stable
even for minor things.
And whats about adding including SQLite library ?
The list of desirable inclusions could easily be endless and very much
subject to individual preferences.
What I want to do is to include a GUI based RubyGems browser that would let
you choose what packages (or named groups of packages) that you would like
to install. This RubyGems browser/installer should also be runnable at any
time after the initial installation to add or remove installed packages.
Two make this a reality, two things need to happen:
1) A GUI-based RubyGems browser needs to be written (I was going to do this,
but due to my time constraints, Lyle Johnson is working on it).
2) More Ruby developers need to create RubyGem packages of their work.
In the meantime, I will probably resist making changes to the list of
pre-installed packages unless there is a compelling reason to do so.
Curt
PS
With the next version of wxRuby I hope to be able to package it up as a
RubyGem
Good, I like that even better! I will change the installer to not set
TCL_LIBRARY.
Curt
···
nobu.nokada@softhome.net wrote:
Hi,
At Thu, 8 Jul 2004 12:23:43 +0900,
Hidetoshi NAGAI wrote in [ruby-talk:105546]:
> > The Ruby Installer still conflicts with because the TCL_LIBRARY is set
> > to a value that python can't handle (python needs TCL 8.4).
> >
> > I think this is a show stopper bug.
> >
> > I really get angry every time i install Ruby and can't access "idle"
> > (which is Python's standard IDE) anymore.
> >
> > Can you please patch the main function in rubys "main.c" file
> > until the tk maintainer fixes this in the right place.
>
> I'll modify Init_tcltklib() of tcltklib.c such like the following.
No, eban says those environment variables are not need at all.
RubyInstaller should just set PATH, but not TCL_LIBRARY. And
RUBY_{TCL,TK}_DLL are used only if tcltklib is compiled with
--enable-tcltk_stubs, but RubyInstaller doesn't.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.716 / Virus Database: 472 - Release Date: 7/5/2004
No, eban says those environment variables are not need at all.
RubyInstaller should just set PATH, but not TCL_LIBRARY. And
RUBY_{TCL,TK}_DLL are used only if tcltklib is compiled with
--enable-tcltk_stubs, but RubyInstaller doesn't.
I have also an idea: Recently I have been thinking of devote one day
in my calender to review 10 ruby-projects… I don’t know which projects
I wish to review (maybe the last 10 of top 20 on rubyforge?)
Then I would have 1 hour to each project, and could write some
interesting
stuff about them. How was installation? What is their purpose? Is the
goal of the project fullfilled? How was documentation? How was code?
When done I would post the review-results at ruby-talk?
it would be nice
But maybe it could be better to put it on the WhyRuby wiki and just
show the link to the page here
Yes, just posting this to the ruby-talk ML would be too fleeting and easily
lost over time. Ideally, RAA would have a facility to allow the posting of
user comments and allow users to post the personal “ranking” of the package.
But since RAA doesn’t do that, and since I want to collect useful
information like this to further Why Ruby’s mission, I think it makes a
great deal of sense to post stuff like this to the Why Ruby wiki.
I’ll add some infrastructure to the Why Ruby wiki to make an obvious place
to post stuff like this and then post a request on ruby-talk asking people
to post their comments on their favorite Ruby packages (or their least
favorite, as the case may be).
Curt
···
il Wed, 12 May 2004 17:21:54 +0900, Simon Strandgaard > neoneye@adslhome.dk ha scritto::
il Wed, 12 May 2004 17:21:54 +0900, Simon Strandgaard >neoneye@adslhome.dk ha scritto::
I have also an idea: Recently I have been thinking of devote one day
in my calender to review 10 ruby-projects… I don’t know which projects
I wish to review (maybe the last 10 of top 20 on rubyforge?)
Then I would have 1 hour to each project, and could write some interesting
stuff about them. How was installation? What is their purpose? Is the
goal of the project fullfilled? How was documentation? How was code?
When done I would post the review-results at ruby-talk?
it would be nice
But maybe it could be better to put it on the WhyRuby wiki and just
show the link to the page here
Too bad I don’t have time fore it at the moment… but I hope.
doh!
Would’nt it be neat for that to be built into raa - ability to comment .
And how many downloads
Comments on installation, docs, purpose fulfillment of purpose
At Thu, 8 Jul 2004 20:06:36 +0900,
Curt Hibbs wrote in [ruby-talk:105566]:
> No, eban says those environment variables are not need at all.
> RubyInstaller should just set PATH, but not TCL_LIBRARY. And
> RUBY_{TCL,TK}_DLL are used only if tcltklib is compiled with
> --enable-tcltk_stubs, but RubyInstaller doesn't.
Good, I like that even better! I will change the installer to not set
TCL_LIBRARY.
Correction: It couldn't find tk.tcl file when it just is not
set. It worked by moving tcl/lib/* to lib.
Another issue, there are identical files under samples/sample
and doc/Tcl/Tk-1.8.1/sample, except for several files only in
the former. Instead, *.{rb,so,lib} underneath lib are
superfluous, since they exist also under lib/ruby/1.8 and never
be used.
At Thu, 8 Jul 2004 20:06:36 +0900,
Curt Hibbs wrote in [ruby-talk:105566]:
> > No, eban says those environment variables are not need at all.
> > RubyInstaller should just set PATH, but not TCL_LIBRARY. And
> > RUBY_{TCL,TK}_DLL are used only if tcltklib is compiled with
> > --enable-tcltk_stubs, but RubyInstaller doesn't.
>
> Good, I like that even better! I will change the installer to not set
> TCL_LIBRARY.
Correction: It couldn't find tk.tcl file when it just is not
set. It worked by moving tcl/lib/* to lib.
Another issue, there are identical files under samples/sample
and doc/Tcl/Tk-1.8.1/sample, except for several files only in
the former. Instead, *.{rb,so,lib} underneath lib are
superfluous, since they exist also under lib/ruby/1.8 and never
be used.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004
also: it would be nice if
<rubydir>\doc\Ruby-1.8.2-snapshot\sample
could go in
<rubydir>\samples
···
il Tue, 13 Jul 2004 21:46:30 +0900, "Curt Hibbs" <curt@hibbs.com> ha scritto::
nobu.nokada@softhome.net wrote:
At Thu, 8 Jul 2004 20:06:36 +0900,
Curt Hibbs wrote in [ruby-talk:105566]:
> > No, eban says those environment variables are not need at all.
> > RubyInstaller should just set PATH, but not TCL_LIBRARY. And
> > RUBY_{TCL,TK}_DLL are used only if tcltklib is compiled with
> > --enable-tcltk_stubs, but RubyInstaller doesn't.
>
> Good, I like that even better! I will change the installer to not set
> TCL_LIBRARY.
Correction: It couldn't find tk.tcl file when it just is not
set. It worked by moving tcl/lib/* to lib.
Another issue, there are identical files under samples/sample
and doc/Tcl/Tk-1.8.1/sample, except for several files only in
the former. Instead, *.{rb,so,lib} underneath lib are
superfluous, since they exist also under lib/ruby/1.8 and never
be used.
A well-known,