Forum: Ruby Introducing RubyScience on GitHub!

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E8a419959139f3f505b49bb95f7e7afe?d=identicon&s=25 Joshua Ballanco (jballanc)
on 2009-05-18 21:28
(Received via mailing list)
In the tradition of actions vs. words, I present to you:

RubyScience - A Collection of Ruby Science Libraries and Projects
http://github.com/jballanc/RubyScience

To get started:
 > git clone git://github.com/jballanc/RubyScience.git
 > git submodule update --init

So, initially I thought, "Wouldn't it be nice if GitHub had a way of
creating groups to collect related projects?" Which is, of course,
when I realized that GitHub already does... It's called Git!
(specifically git submodules). So, this project isn't much, really, on
its own. Eventually I'd like to automate some of the pulling/updating/
indexing/documenting/etc. tasks. I'd also like to have an umbrella gem
(or perhaps many umbrella gems, i.e. rubyscience-physics, rubyscience-
math, etc.) that would make it easier to start from scratch to do
science with Ruby.

For now, though, RubyScience is just a collection. Please add to it! I
also welcome comments, criticism, discussion regarding organization,
strategy, goal, and so forth. Don't forget projects too! What better
way to motivate yourself to finish that evolution simulation for your
Ph.D. thesis than by showing it in all its unfinished glory to the
world as part of the RubyScience project? (At least, that's what I'm
going for ;-)

Cheers,

Josh
E8a419959139f3f505b49bb95f7e7afe?d=identicon&s=25 Joshua Ballanco (jballanc)
on 2009-05-18 21:33
(Received via mailing list)
Whoops! Forgot to mention:

Since git submodules are locked to specific commits, I'll do my best
to update weekly on Mondays and tag the commits.

- Josh
321492ebcf7d831c99243830690bfaa7?d=identicon&s=25 justin caratzas (Guest)
on 2009-05-18 21:34
(Received via mailing list)
On Mon, May 18, 2009 at 3:27 PM, Joshua Ballanco <jballanc@gmail.com>
wrote:

> creating groups to collect related projects?" Which is, of course, when I
> yourself to finish that evolution simulation for your Ph.D. thesis than by
> showing it in all its unfinished glory to the world as part of the
> RubyScience project? (At least, that's what I'm going for ;-)
>
> Cheers,
>
> Josh
>
>
:)
nice timing, Josh

I'll gladly be looking into this
E8a419959139f3f505b49bb95f7e7afe?d=identicon&s=25 Joshua Ballanco (jballanc)
on 2009-05-18 21:39
(Received via mailing list)
Double whoops... Here's the initial list of libraries contained
(essentially, what I already knew about and what I could find with a
quick bit of googling):

bioruby
rcdk-ng
structure-cdk-ng
ruby-gsl
rsruby
strategery
chipmunk

- Josh
4d5b5dd4e263d780a5dfe7ac8b8ac98c?d=identicon&s=25 Tim Pease (Guest)
on 2009-05-18 21:40
(Received via mailing list)
On Mon, May 18, 2009 at 1:32 PM, Joshua Ballanco <jballanc@gmail.com>
wrote:
> Whoops! Forgot to mention:
>
> Since git submodules are locked to specific commits, I'll do my best to
> update weekly on Mondays and tag the commits.
>

Recomendation: change the "INDEX" files in the various folders to
"README" files; github will then display these files to the user as
they browse the repository. This would be very useful since github
does not link through to the git submodules in the web interface.

Blessings,
TwP
A4a4095ff08bd0fced3c3fddbeac743a?d=identicon&s=25 Cameron McBride (Guest)
on 2009-05-18 21:59
(Received via mailing list)
On Mon, May 18, 2009 at 14:38, Joshua Ballanco <jballanc@gmail.com>
wrote:
> chipmunk
you should add NArray to that list.

Cameron
A4a4095ff08bd0fced3c3fddbeac743a?d=identicon&s=25 Cameron McBride (Guest)
on 2009-05-18 22:21
(Received via mailing list)
On Mon, May 18, 2009 at 14:27, Joshua Ballanco <jballanc@gmail.com>
wrote:
> creating groups to collect related projects?" Which is, of course, when I
> realized that GitHub already does... It's called Git! (specifically git
> submodules). So, this project isn't much, really, on its own. Eventually I'd
> like to automate some of the pulling/updating/indexing/documenting/etc.
> tasks. I'd also like to have an umbrella gem (or perhaps many umbrella gems,
> i.e. rubyscience-physics, rubyscience-math, etc.) that would make it easier
> to start from scratch to do science with Ruby.

cute idea.  I'm not sure how well the many libraries play together -
but we can find this out along the way...

btw, there is already a rubyforge project (sciruby) that I started
with similar ambitions.  Initially, it's intention was just to provide
a separate "science centric" list for ruby discussions to augment Ara
Howard's sciruby wiki (which seem to have evaporated).   The list
still exists, albeit the traffic is *very* light.   I encourage any
interested party to sign up!

In any case, it could easily be the connective bit to provide the
"distribution" gems.  Or to officially house anyone's original code
they don't want to publish separately.    Other suggestions are quite
welcome.

Cameron
E8a419959139f3f505b49bb95f7e7afe?d=identicon&s=25 Joshua Ballanco (jballanc)
on 2009-05-18 22:41
(Received via mailing list)
On May 18, 2009, at 4:20 PM, Cameron McBride wrote:

> welcome.
That sounds like a great idea. Probably the first thing I'm going to
do is figure out some simple rake tasks to add new libraries/projects
and wrangle the indexes in interesting and useful ways. As I mentioned
in the announcement, the idea is not for this to be a project in its
own right, but rather to serve as a gathering place for other
projects. In keeping with the tradition that github is for "in
development" and rubyforge is for "released to public", I think the
sciruby project on rubyforge would be a perfect place to put gem(s)
and hold discussion. In fact, since GitHub doesn't provide for mailing
lists, I've added a link to the sciruby project on the RubyScience
wiki (and I'll update the README shortly).

Cheers,

Josh
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-05-18 22:51
(Received via mailing list)
On May 18, 2009, at 3:27 PM, Joshua Ballanco wrote:

> creating groups to collect related projects?" Which is, of course,
> organization, strategy, goal, and so forth. Don't forget projects
> too! What better way to motivate yourself to finish that evolution
> simulation for your Ph.D. thesis than by showing it in all its
> unfinished glory to the world as part of the RubyScience project?
> (At least, that's what I'm going for ;-)
>
> Cheers,
>
> Josh
>

I like the git idea a lot.   Last year I ported a Ruby science library
to Ruby 1.9, made it into a gem, sent the changes to the maintainer
and nothing became of it.   Not the maintainers fault.  He was just
too busy.   If it's distributed that's just not a problem.
A4a4095ff08bd0fced3c3fddbeac743a?d=identicon&s=25 Cameron McBride (Guest)
on 2009-05-18 22:59
(Received via mailing list)
On Mon, May 18, 2009 at 15:38, Joshua Ballanco <jballanc@gmail.com>
wrote:
>> "distribution" gems.  Or to officially house anyone's original code
> place to put gem(s) and hold discussion. In fact, since GitHub doesn't
> provide for mailing lists, I've added a link to the sciruby project on the
> RubyScience wiki (and I'll update the README shortly).

I agree, very complementary approaches.  Let's have a run at it.

If you (or anyone else interested in helping) want access to the
rubyforge project,  just let me know.

Cameron
Cd0dbf751457cf6fed1f69070d37006a?d=identicon&s=25 Charles Johnson (Guest)
on 2009-05-18 23:05
(Received via mailing list)
On May 18, 2009, at 2:58 PM, Cameron McBride wrote:

>> ruby-gsl
>> rsruby
>> strategery
>> chipmunk
>
>
> you should add NArray to that list.
>
> Cameron
>
If Horinouchi would permit it, the ruby-fftw module might be added, too.

Cheers--

Charles
---
Charles Johnson
Advanced Computing Center for Research and Education
Vanderbilt University
A4a4095ff08bd0fced3c3fddbeac743a?d=identicon&s=25 Cameron McBride (Guest)
on 2009-05-18 23:45
(Received via mailing list)
On Mon, May 18, 2009 at 15:49, Juan Zanos <juan_zanos@talkhouse.com>
wrote:
> distributed that's just not a problem.
This is a neat idea; basically to wrestle unmaintained or
not-quickly-updated libraries into the useable limelight.  This alone
could be a fantastic accomplishment worthy of the project.

But I'm not clear on logistics.  Is the idea to import other peoples
code into github if they don't already exist there?  That seems like a
lot of work, not just initially but also to keep up with releases.

The other problem is what would constitute a pseudo-official
"release"?  Whose fork or repo would incorporate other efforts or
resolve which of two different forks of, say, ruby-gsl to include?

Maybe the github community has acceptable solutions for these
situations.  I haven't followed the social aspect of github at all.

Cameron
E8a419959139f3f505b49bb95f7e7afe?d=identicon&s=25 Joshua Ballanco (jballanc)
on 2009-05-19 02:20
(Received via mailing list)
On May 18, 2009, at 5:42 PM, Cameron McBride wrote:

>> library to
>> Ruby 1.9, made it into a gem, sent the changes to the maintainer
>> and nothing
>> became of it.   Not the maintainers fault.  He was just too busy.
>> If it's
>> distributed that's just not a problem.
>
> This is a neat idea; basically to wrestle unmaintained or
> not-quickly-updated libraries into the useable limelight.  This alone
> could be a fantastic accomplishment worthy of the project.

The whole point of Open Source is just this. GitHub just makes the
practice a bit easier to match up with the theory. If I get hit by a
bus or loose interest, I fully expect someone to fork this project and
keep it up to date (if there's still interest, of course).

> But I'm not clear on logistics.  Is the idea to import other peoples
> code into github if they don't already exist there?  That seems like a
> lot of work, not just initially but also to keep up with releases.

Right now I'm favoring GitHub repositories (for example, the base repo
for Chipmunk is on Google Code; I've included the GitHub fork setup
for Debian maintenance). As I first mentioned, the idea I had was a
GitHub "group", so my primary interest is in GitHub repos. Also, since
everything is just set up as a git submodule, none of the actual code
resides in the repo. This, I think, best reflects the point of the
project. That is, if you want to modify the code for one of the
libraries, please fork and modify the original and not what you find
in RubyScience.

Now, that said, I realize that not every project lives on GitHub.
There are three solutions to handle this:

1. Ask the project to setup a GitHub mirror. Public repos are free,
and some simple post-commit hooks should make maintenance relatively
painless. Of course, not every project will be receptive to this
scenario so:

2. We could setup GitHub repos for projects that we want to carry
across. If we go down this route, I'd ask for volunteers to handle the
synchronization. I'd prefer this to:

3. We could pull code from other repos directly into RubyScience. I
have a script that automates the task of updating git, git-svn, svn,
and cvs repos (adding hg and bzr support shouldn't be too difficult).
I'd like to stay away from this, though, since I really want the
projects included in RubyScience to live in their own git repos.

> The other problem is what would constitute a pseudo-official
> "release"?  Whose fork or repo would incorporate other efforts or
> resolve which of two different forks of, say, ruby-gsl to include?

I'd welcome discussion on this, but for the sake of ruby-talk I'd
invite those interested to sciruby-talk (to which I'll be cc'ing this
message). The easy answer, of course, is that if you don't like my
decisions you're free to maintain your own fork ;-). The better answer
is that when it comes time to put together a RubyScience/sciruby
umbrella gem (say once every quarter or so) we'd likely want to
contact each repo maintainer for guidance on what to include.
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-05-19 15:27
(Received via mailing list)
On May 18, 2009, at 5:42 PM, Cameron McBride wrote:

>> library to
> But I'm not clear on logistics.  Is the idea to import other peoples
> Cameron
The import isn't much work in most cases.  There are different
solutions for
different situations.   Creating a git repo is trivial.   If something
is
already in git you can just clone it.  If it's in Subversion you can
'clone' it
with git-svn.  If it's in Bazaar you can use bzr-svn, etc.   You can
continue
to pull or push changes from the original repository if necessary.
People are
sometimes conservative about keeping some of the old repos around, but
it might
be better to nuke them rather than spend the effort maintaining them.

I think the "officialness" part is overrated in the distributed
world.  Would
you rather have an "official" library that needs a lot of work or an
unofficial
one that someone has kindly updated so it's closer to what you need?

That said, an "official release" is still faithfully reflected in
every repo
that has fetched from any repo that contains the "official release".
Repos
have tags and branches and these are immutable.  So it doesn't matter
from
which repo you checkout say "totally official release 3.2".

As for merging, it doesn't really matter so much who does a merge so
long as
you like the result.  If you don't like it you can fix it or decide that
whoever did it is going down an evolutionary dead end and ignore them.

Github is great.  But a lot of the social networking stuff is built
right into
git.   You can quickly see the entire history of every repo you've
ever fetched
from without using any 3rd party tools.
This topic is locked and can not be replied to.