The real Ruby vs. Python.

[gabriele renzi]

Jamis Buck ha scritto:

Besides which: Ruby/DL is often touted as a great way to write extension
libraries. Are there any examples of libraries that have been written
using Ruby/DL instead of C? I've never seen any, much to my own
frustration when I would like a good example of Ruby/DL usage.

well I can only remember the htmltidy library, never looked at it, anyway :/

 

[Bill Atkins]

Is there a significant difference in speed between a straight C
extension and a Ruby/DL interface?

Bill

 

[trans. (T. Onoma)]

Then it sounds like that RubyGems needs to adopt the framework of RPA, and
help improve/adapt it to its needs, e.g. versionsing.

I like RPA. I want to use RPA. But I can't. I have to say "pretty please"
package this for me. I understand the QA. I think that's great. But I also
think there needs be a way for beta wares to "get on the line". Gems allows
that. So I'll just use Gems.

You all keep talking about why the two can't really work together. Eventually
you'll talk yourself right out of the picture.

2%,
T.



On Wednesday 27 October 2004 06:34 pm, Mauricio Fernández wrote:
| RubyGems installs packages in separate directories; it supports multiple
| versions of a lib at a time but it is not totally transparent (you need
| a combination of the "require hack" plus executable stubs, and the
| datadir issue is yet to be addressed).
| rpa-base installs atomically into $prefix; the operations are transacted
| and it is transparent; it can track reverse dependencies and GC packages
| on uninstall. It can also do parallel installs and update itself.
|
| Even the basics are quite different. The basic, fundamental operation
| (installing a package) is arguably stronger in rpa-base because it
| is atomic. This is an absolute must because rpa-base manages files
| in $prefix.
|
| There is no gain in throwing away a codebase that works well and
| replacing it with another that does NOT do what RPA needs, the way it
| needs it.
|
| However, we have tried to share code when possible, and it is in that
| spirit that we contributed rpa-base's package format code to RubyGems,
| which was integrated as of 0.8.0.
|
| > module Gem; require_gem 'Core'... end
| > module RPS; require_gem 'Core' ... end
|
| The deep differences even in the core operations make this approach
| impossible.
|
| > > This is a large task. The present rpa-base and package set only
| > > scratch the surface of what we're trying to do. We're presently
| > > looking at the next step in the enabling this:
| > >
| > > - A new version of rpa-base that support the development cycle for the
| > > above much better (integration with version control system to make
| > > maintenance of code uniform etc)
| > > - Documentation to help more people be able to do RPA packaging
| > > - Documentation and checklists for helping software quality
| > > - Building a review team for doing code review for code we import into
| > > the
| >
| > RPA
| >
| > > - Support for binary packages, to make Ruby deployment on Windows etc
| >
| > easier
| >
| > > - Increase in team size
| >
| > These are great, and 100% valid. It's just that there is a core that
| > seems identical, Imho.
|
| Well, it just isn't... Note that the development of rpa-base
| began in February; by the time RubyGems 0.2.0 (first public
| release) was out, in 2004-03-14, rpa-base was already doing atomic
| installations/upgrades/deletions, handling extensions, RDoc generation,
| automated unit test runs, etc. I just mention that to illustrate that
| the development of these two codebases happened in parallel, and that
| different design and implementation choices were taken on each.

--
( o _ カラãƒ
// trans.
/ \ (e-mail address removed)

I don't give a damn for a man that can only spell a word one way.
-Mark Twain

 

[David Ross]

You can create your own packages with RPA as well. RPA doesnt have an
anonymous upload like RubyGems does yet, maybe sometime in the future
we can. In the meantime anyone can create a RPA (non QA'ed) as well as
submit it to the team for review to submit in the stable branch. By the
way, the RPA wiki does have a place to place "wanted software" for us to
pacakge. The RPA urge you to please use it, The RPA are open to
suggestion, thoughts, comments, and extra help.



David Ross
--
Hazzle free packages for Ruby?
RPA is available from http://www.rubyarchive.org/

 

[David Ross]

You can create your own packages with RPA as well. RPA doesnt have an
anonymous upload like RubyGems does yet, maybe sometime in the future
we can. In the meantime anyone can create a RPA (non QA'ed) as well as
submit it to the team for review to submit in the stable branch. By
the way, the RPA wiki does have a place to place "wanted software" for
us to pacakge. The RPA urge you to please use it, The RPA are open to
suggestion, thoughts, comments, and extra help.



David Ross

A small detail I forgot. When you create your own RPA source files, you
can build them by specifying the remote URL.

rpa install http://domain.com/softwaretitle.rps

David Ross

 

[Chad Fowler]

This bites me quite often as well, though I have not given up. There are
likely hordes of unwashed masses like me, not entirely adept at
source-patch-recompile-rebuild, who never even get started with Ruby because
of the kinds of issues Abe describes.

Their loss or Ruby's? Unfortunately, probably both.

I feel gems is one of the keys to getting past this. Gems can make my local
(Windows) Ruby install feel like
- a single plug-in system
- pulling together 'requires'
- incorporating documentation from a single starting point
- including compatible versions and dependencies

This is the vision. Above all, "really freaking easy". That's our focus.

Some misc thoughts:

- Could gems ALSO cover binaries AND binary/library dependencies?

- Could the gems RDOCs have links to some gems-aligned community
documentation site, as someone else proposed here recently?

Great ideas. The binary/library dependency thing will require a lot
of thought, but it will definitely come up in the future. We have
limited support for binaries now, but it needs a lot of filling out.

We're building a site for RubyGems (hopefully to be released within
the next few weeks) which I think will excite you. More details to
come....

Thanks for the great ideas and enthusiasm.
--

Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 20,000 gems served!)

 

[Mauricio Fernández]

Then it sounds like that RubyGems needs to adopt the framework of RPA, and
help improve/adapt it to its needs, e.g. versionsing.

That's something the RubyGems team will have to decide upon but it
doesn't seem likely

I like RPA. I want to use RPA.

Then just do it There are over 130 libs/apps in the Ruby Production
Archive...
If you want to package your software using rpa-base, take a look at
http://rpa-base.rubyforge.org/wiki/...tion/Introduction_To_Packaging_Using_Rpa_Base

This is some preliminary documentation (targeting RPA developers), but
I'd be willing to expand it if it helps you; feel free to ask for more
information. You can also get the package done for you on demand
(offer limited in time, take it now!

But I can't. I have to say "pretty please"
package this for me. I understand the QA. I think that's great. But I also
think there needs be a way for beta wares to "get on the line". Gems allows
that. So I'll just use Gems.

That's fine. That is the primary goal of RubyGems, and although it is
indeed possible and normally easy (the RPAfied install.rb is typically
shorter than the corresponding gemspec) to package your software with
rpa-base and distribute it (some people have done so in the past already),
it is not the primary goal of RPA. I refer you to the manifesto for more
information on our goals:

http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto

I would hence recommend you to release your software using RubyGems and
following the good practices documented in
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodPractices
(http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodAPIDesign won't hurt
either)
which benefit all repackagers (not only RPA but also FreeBSD, Debian,
Gentoo, PLD, Fedora, etc), or using Aoki's setup.rb.

You all keep talking about why the two can't really work together. Eventually
you'll talk yourself right out of the picture.

We are already working together: the RPA team has contributed ideas
and code to RubyGems (something approaching 20% of their codebase was
originally developed for rpa-base); there's not much more we can do )
Also, the RubyGems team is committed to making RubyGems packages easy
to repackage for other people:

http://rubyforge.org/pipermail/rubygems-developers/2004-October/001150.html

That is, work is already on the way to make RubyGems repackager-friendly
and address the many issues reported by several independent packagers:
we are all looking forward to RubyGems making repackaging easier instead
of harder as happens often now.

 

[Andreas Schwarz]

You can create your own packages with RPA as well.

"Note that, although packaging stuff for RPA is very easy (we designed
rpa-base for ourselves too , there's deliberately no documentation on
how to do it" (FAQ)

Hmm... not very encouraging.

 

[David Ross]

"Note that, although packaging stuff for RPA is very easy (we designed
rpa-base for ourselves too , there's deliberately no documentation
on how to do it" (FAQ)

Hmm... not very encouraging.

There could very well be documentation, and my work queue is currently
to the max so I need to complete a few before adding anything like that
to my list. Documentation is very important, possibly someone will
create it if I don't first.

David Ross

 

[Kaspar Schiess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| I don't have anything against windows, but now I will get a team
| together and have a group of people build binaries for windows users,
| now it consists of lypanov and me. Soon we shall have a binary
| revolution. To the Ruby Republic!
|
| David Ross

Count me in. Power to the people.

kaspar

hand manufactured code - www.tua.ch/ruby
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgKpXFifl4CA0ImQRArpdAJ42DGc8LR9ACqF36DwdJFQ9259U4wCgk3Du
K3GplYx0zcFEVqWiG33kITA=
=PdI9
-----END PGP SIGNATURE-----

 

[Mauricio Fernández]

"Note that, although packaging stuff for RPA is very easy (we designed
rpa-base for ourselves too , there's deliberately no documentation on
how to do it" (FAQ)

mmm the FAQ is outdated, since right now there is indeed some
(preliminary) documentation at

http://rpa-base.rubyforge.org/wiki/...tion/Introduction_To_Packaging_Using_Rpa_Base

Keep in mind that RPA is about packages, not about a port/package
manager: rpa-base is just something we needed to achieve our real goals,
because nothing else satisfied our requirements. That means that rpa-base
itself is not considered a "final product", so it must not be seen as a
competitor for RubyGems: we deliberately kept it away from that niche,
to focus on the end goals stated in our manifesto:

http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto

I would thus recommend you the same I told to T. Onoma:

Release your software using using Aoki's setup.rb or RubyGems and
following the good practices documented in
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodPractices

If you really want to use rpa-base (maybe you need atomicity or strong
dependency management?), take a look at the above link and feel free to
ask

 

[David A. Black]

If you really want to use rpa-base (maybe you need atomicity or strong
dependency management?), take a look at the above link and feel free to
ask

Clarification, in case anyone misunderstands: I don't know what your
threshold is for "strong", but Ruby Gems has dependency management,
and I haven't seen anything non-strong about it.


David

 

[Eivind Eklund]

Then it sounds like that RubyGems needs to adopt the framework of RPA, and
help improve/adapt it to its needs, e.g. versionsing.

I like RPA. I want to use RPA. But I can't. I have to say "pretty please"
package this for me. I understand the QA. I think that's great. But I also
think there needs be a way for beta wares to "get on the line". Gems allows
that. So I'll just use Gems.

Would it help you if we added the ability to "fall back to" gems for
the cases where something hasn't been RPAfied to the user interface?

Eivind.

 

[Michael DeHaan]

Speaking of Ruby/DL, I have a question ...

Supposing I have a library that demands control of an event loop.
Examples could include GLUT (glutMainLoop) or SDL, but maybe it's
something else. What ways are there in Ruby/DL to call back into
Ruby code from the C library?

Is this even possible, or do I have to write Swig/XS for this? Up
until this point I haven't had a need for XS/Swig, so I've typically
gone the Ruby/DL route (in what few Ruby apps I've written), or I've
used Inline::C (awesome module, BTW) in Perl.

Anyhow, ruby-sdl and ruby-opengl may exist, but occasionally I take
some pleasure in reinventing wheels...or at least in knowing how to.
In fact, ruby-opengl might be a good example after all. I'd really
like to stay down in C code for longer lengths of time, so this is a
case where writing one's own bindings may be useful.

--Michael DeHaan

 

[Mauricio Fernández]

Clarification, in case anyone misunderstands: I don't know what your
threshold is for "strong", but Ruby Gems has dependency management,
and I haven't seen anything non-strong about it.

"Strong dependency management" means that the system ensures no invalid
state (where the dependencies are not fully satisfied) can be reached.
In that sense, RubyGems' dependency management isn't "strong".

The problems are fairly subtle and easy to overlook; I myself didn't
notice them at first when working on rpa-base.

RubyGems' versioning model makes it difficult to track reverse
dependencies: currently user intervention is required to ensure no
dependencies are broken on uninstall, and the installation/removal
of a RubyGems package plus its dependencies isn't performed as a
transaction. There are also some essentially unsolvable issues at runtime
(unsatisfiable dependencies).

 

[Ara.T.Howard]

"Strong dependency management" means that the system ensures no invalid
state (where the dependencies are not fully satisfied) can be reached.
In that sense, RubyGems' dependency management isn't "strong".

The problems are fairly subtle and easy to overlook; I myself didn't
notice them at first when working on rpa-base.

RubyGems' versioning model makes it difficult to track reverse
dependencies: currently user intervention is required to ensure no
dependencies are broken on uninstall, and the installation/removal
of a RubyGems package plus its dependencies isn't performed as a
transaction. There are also some essentially unsolvable issues at runtime
(unsatisfiable dependencies).

when a package is installed - do you store dags of the dependancies somewhere
then? i guess it would need to be a single dag (at least logically) so you
could detect problems on uninstall huh?

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself. --Shunryu Suzuki
===============================================================================

 

[Chad Fowler]

On Thu, 28 Oct 2004, Mauricio [iso-8859-1] Fernández wrote:

# On Thu, Oct 28, 2004 at 09:08:08PM +0900, David A. Black wrote:
# > On Thu, 28 Oct 2004, Mauricio Fernández wrote:
# >
# > > If you really want to use rpa-base (maybe you need atomicity or strong
# > > dependency management?), take a look at the above link and feel free to
# > > ask
# >
# > Clarification, in case anyone misunderstands: I don't know what your
# > threshold is for "strong", but Ruby Gems has dependency management,
# > and I haven't seen anything non-strong about it.
#
# "Strong dependency management" means that the system ensures no invalid
# state (where the dependencies are not fully satisfied) can be reached.
# In that sense, RubyGems' dependency management isn't "strong".
#

"Strong" as in "Strong typing".

# The problems are fairly subtle and easy to overlook; I myself didn't
# notice them at first when working on rpa-base.
#
# RubyGems' versioning model makes it difficult to track reverse
# dependencies: currently user intervention is required to ensure no
# dependencies are broken on uninstall, and the installation/removal
# of a RubyGems package plus its dependencies isn't performed as a
# transaction. There are also some essentially unsolvable issues at runtime
# (unsatisfiable dependencies).
#

Most of this is by design. An example of something that I believe is
broken from an end-user perspective in rpa-base is that when I remove a
package, it removes all of the dependencies. We _don't_ want to do that
with RubyGems. I have Rails installed, and I've written scripts to use
ActiveRecord, which was installed with Rails. If I decide I don't want
Rails anymore, I don't want to have to go manually install ActiveRecord
afterward.

As for tracking reverse dependencies, it doesn't seem difficult to me:

spec.dependent_gems

The manual user intervention you were talking about is not _necessary_.
We added it because we wanted the user to have the choice to remove a
package even if it might screw something up. I see it as being in the
same vein as allowing a programmer to pass a String into a method that may
usually expect something else. "Here's some rope...you can use it to tie
knots, secure things, etc. or you can hang yourself with it. We trust
that you'll make the right decision, because we don't think you're an
idiot."

Chad

 

[Jamis Buck]

Speaking of Ruby/DL, I have a question ...

Supposing I have a library that demands control of an event loop.
Examples could include GLUT (glutMainLoop) or SDL, but maybe it's
something else. What ways are there in Ruby/DL to call back into
Ruby code from the C library?

Ruby/DL does support callbacks, but only a fixed number of them (10, by
default, unless you compile the DL extension yourself and specify
otherwise):

module Stuff
extend DL::Importable
dlload "..."

extern "int fn_with_cb( void* )"

def my_callback( x, y, z )
do_something_with( x, y, z )
end

CALLBACK = callback( "int my_callback( int x, int y, int z )" )
end

Stuff.fn_with_cb( Stuff::CALLBACK )

There is an example in the libc.rb file in the sample subdirectory of
the DL directory in the Ruby source distribution.

- Jamis

 

[Bill Guindon]

We trust that you'll make the right decision,
because we don't think you're an idiot."

... unlike Mauricio (and the rest of the RPA team).

That last part didn't add much to the discussion, but it does add to
the belief that the two teams are antagonistic.

Perhaps I just read it the wrong way.

 

[Gavin Sinclair]

... unlike Mauricio (and the rest of the RPA team).

That last part didn't add much to the discussion, but it does add to
the belief that the two teams are antagonistic.

Not every sentence by a discussion participant needs to add something
to the discussion, surely.

Perhaps I just read it the wrong way.

Perhaps, perhaps not. The above sentence is not good evidence,
though: claiming to not treat users like idiots is the preserve of
many technology enthusiasts. That doesn't make them antagonistic.

Gavin