The real Ruby vs. Python

[David_Ross]

Michael DeHaan wrote:

Dare I say it, but cloning CPAN near-exactly wouldn't be a bad way to
go.

And that means putting RPAN (or whatever) as part of the Ruby standard
library, having college mirrors, doing dependancy checking, and so
forth.

This is not quite the same thing, but...

The One-Click Ruby Installer for Windows is going to include RubyGems and
a
GUI interface to RubyGems. RubyGems will be in the final 1.8.2 release of
the installer (hopefully the GUI interface will be ready in time to be
included as well). It is also possible that a follow-on release would
contain RPA (and a corresponding GUI interface).

Curt

Curt, I will hope that we can maybe release a version with RPA even
sooner. The RPA team and I are very fast hackers. I think I could have
many packages built that would seem awesome(big) in package count and QA
support if anything goes wrong people have a place to nag instead of the
developers.

Dross

···

On Thu, 28 Oct 2004 01:12:24 +0900, David Ross >> <dross@code-exec.net> wrote:
> Its Me wrote:
>
>
>
> >"Abe Vionas_MailingList" <mailinglist_abe@yahoo.com> wrote
> >
> >
> >
> >>What it comes down to is what it's coming down to for
> >>me... platform maturity.
> >>
> >>
> >
> >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
> >
> >It would be great if gems was part of the standard Ruby
distribution, if RPA
> >could use gems as its underlying package manager (reducing
confusion for
> >newBs), and if RPA could then also take on the role of Release
Manager for
> >Ruby itself.
> >
> >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?
> >
> >
> >
> >
> >
> >
> >
> RPA and RubyGems have different aspects in implementation, so it would
> not be compatible/easy. Now that I have a RPA QA team for windows, we
> should have binaries put together soon. Good support for software.
>
> David Ross
> --
> Hazzle free packages for Ruby?
> RPA is available from http://www.rubyarchive.org/
>
>

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.775 / Virus Database: 522 - Release Date: 10/8/2004

[gabriele_renzi]

David Ross ha scritto:

You can use mingw32. Help out you blasted lypanov. I told earlier you its up to us, not end users.

actually you can use MS' stuff as it is available free as in beer (compiler and nmake, at least)

[Bill_Atkins]

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

Bill

···

On Thu, 28 Oct 2004 06:53:39 +0900, Jamis Buck <jgb3@email.byu.edu> wrote:

gabriele renzi wrote:

> that's why people should use ruby/dl, say 'boo' for c bindings

True. However, Ruby/DL has a compile-time limit (defaults to 10) on the
number of callbacks you can use, which limits its usefulness in
situations where callbacks are needed. This includes the Win32 API (for
winprocs), or SQLite (where callbacks are one way to obtain query results).

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.

- Jamis

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

[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

[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.
/ \ transami@runbox.com

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

[Guillaume_Marcais1 (Guillaume Marcais)]

I wouldn't dare to brag about 'good example', but it at least is a
(mostly) working one. I say mostly as a good number of the settings for
a user are undocumented and I had to guess the return value type.
Anyway, the following code is a binding to the Merak mail server
library. It allowed may to automate the transition from our old mail
server to Merak. It is now a nice way to get the password in clear that
the stupid GUI shows as stars. The creation and basic settings of a
Domain and a User should work. The more exotic settings are untested.

Here is an example of a session using the created merak shell:

$ ssh Administrator@fakedomain irb -r merak_shell
Administrator@fakedomain's password:
Warning: Remote host denied X11 forwarding.
Merak 1:0> toto = Domain["toto.net"]
toto = Domain["toto.net"]
=> #<Domain name=toto.net; index=15>
Merak 2:0> user = toto["toto"]
user = toto["toto"]
=> #<User domain=toto.net index=0>
Merak 3:0> user.password
user.password
=> "coucou"
Merak 4:0> user.password = "hello"
user.password = "hello"
=> "hello"
Merak 5:0> user.save
user.save
=> #<User domain=toto.net index=0>

In short, I would never have written it if I had to drop down to C. One
reason being that I don't have a compiler installed on any Windows
machine yet.

Guillaume.

merak.rb (13 KB)

merak_shell.rb (284 Bytes)

Merak Shell.bat (54 Bytes)

···

On Wed, 2004-10-27 at 17:53, Jamis Buck wrote:

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.

[David_Ross]

trans. (T. Onoma) wrote:

Michael DeHaan wrote:
> Dare I say it, but cloning CPAN near-exactly wouldn't be a bad way to go.
>
> And that means putting RPAN (or whatever) as part of the Ruby standard
> library, having college mirrors, doing dependancy checking, and so
> forth.

This is not quite the same thing, but...

The One-Click Ruby Installer for Windows is going to include RubyGems and a
GUI interface to RubyGems. RubyGems will be in the final 1.8.2 release of
the installer (hopefully the GUI interface will be ready in time to be
included as well). It is also possible that a follow-on release would
contain RPA (and a corresponding GUI interface).

And use the same GUI for both?

Seems to me it would be best of Gems team and RPA team really worked hard together to create shared framework. Gems serving as a general packaging framework and the idea of RPA becoming QC would be a real boon for Ruby. --Mind you though, setup.rb still does things they can't. So lets draw that in too.

Together we stand, divided...

As they say,
T.

This would not work. I'm creating a GUI for Windows, I have more experience with GUI design and what a user wants in a easy to use gui. If you want the job done right, you've got ot do it yourself. I will make sure my GUI for RPA(on windows currently) is feasible where maybe others could use it as well. I will keep others in mind. However I dislike the way people design, and so I have to do it myself. Its a perfection task, not a personal one. I like easy-to-use- guis with good design.

My implementation of the RPA GUI is to use WideStudio first because its much easier than any other, then I will port it to a popular(aka native - really its not, its called popular; Qt, GTK, etc) toolkit using GUI toolkit. WideStudio has its own widgets, and I'm aware not everyone likes a non-popular toolkit look. So I'll rewrite it quickly in another. It will also be for Unix OSes depending if I see it good or not. Possiblyeven porting it to unix, depending how I will implement it to jump to root.

David Ross

···

On Wednesday 27 October 2004 02:00 pm, Curt Hibbs wrote:

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

[David_Ross]

gabriele renzi wrote:

David Ross ha scritto:

You can use mingw32. Help out you blasted lypanov. I told earlier you its up to us, not end users.

actually you can use MS' stuff as it is available free as in beer (compiler and nmake, at least)

I'm aware, but I usually compile win32 program on my bsd machine with the mingw port. I can install the microsoft compiler later maybe. Thanks though.

David Ross

···

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

[gabriele_renzi]

trans. (T. Onoma) ha scritto:

Seems to me it would be best of Gems team and RPA team really worked hard together to create shared framework. Gems serving as a general packaging framework and the idea of RPA becoming QC would be a real boon for Ruby. --Mind you though, setup.rb still does things they can't. So lets draw that in too.

Together we stand, divided...

there are philosophical and practical differences in approaching packaging that makes this impossible, for what I understand. But the teams collaborate and share stuff. So it is a "We stand togheter, even if we don't hug"

[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/

trans. (T. Onoma) wrote:

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.

[Mauricio_Fernndez]

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/wiki.cgi?Developer_Documentation/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.

···

On Thu, Oct 28, 2004 at 09:38:11AM +0900, trans. (T. Onoma) wrote:

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

[Eivind_Eklund]

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.

···

On Thu, 28 Oct 2004 09:38:11 +0900, trans. (T. Onoma) <transami@runbox.com> wrote:

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.

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

[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

···

On Thu, 28 Oct 2004 07:49:01 +0900, gabriele renzi <rff_rff@remove-yahoo.it> wrote:

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

[gga]

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.

Amen, brother.

From trying both, my impression so far (which does not yet include evaluation
of how C modules are handled) is that rpa is clearly superior for my needs.

But, as well intentioned as rpa's team may be, not having a well documented and
clean way to distribute your own packages, I see it never catching on.
Mauricio, that web page explaining things really does not explain anything. I
could not make head or tails of it. Having perhaps the rpa "gemspec" available
for the modules of rpa would be a better approach.

The rubygems team seems to have a somewhat "unfair" advantage as they seem to
have better "contacts" among the ruby community as they got the benefit of a
full chapter in the PickAxe and the support of rubyforge.net, and the one-click
installer while rpa got neither so far.

If RPA's format was documented and was as simple to use as a gemspec (or,
better yet, use gemspec itself as it stands, as it is popular enough already),
I really would not bother with rubygems, imo.

Having tried rubygems, I really did not like it much, except for the feature of
being in control of packaging my own stuff.
But even then, as it stands, I saw a lot of problems with it (if I'm wrong
about any of the things below, please let me know).

Things that, imo, rubygems got wrong so far include:

* Lack of atomic installs. For a system that is supporting multiple versions
of libraries in different directories, perhaps this is not as dangerous.

* The whole versioning thing of installing in separate subdirectories
   This *seems* like a good idea. But I consider this one of rubygems biggest
misfeatures.
  After working at one of python's largest shops in the world for 3 years and
seeing python code written in the span of 5+ years and having dealt with perl
for as many years, I can state with some certaintity that the conflict among
libraries (particularly popular ones) is few and far between. And in the rare
cases it arises, it is much easier to just change the library path as needed or
not upgrade until the libraries you need work nicely together, without having
to change any code. If you absolutely need to use a new version of a library,
naming it, say "library2.0" and using it like that is easier (and much simpler
as a symbolic link solves all issues without changing a single line of code).
   As having this feature also encourages libraries to not be mantained or
upgraded, since you can always "use require_gem gem version number to work
around it", I have to say I feel very, very, very strongly against having this.
   Finally, it isn't clear to me if this feature is compatible with having
installs of platform-indepent modules in a single location. As I usually have
to deal with mantaining scripting languages across multiple platforms, I like
the idea of having a single location where libraries are dumped (usually a unix
box). With rubygems, my impression is that it seems like libraries for
multiple platforms would need to be installed repeatedly multiple times and in
separate locations.

* rubygems adds the whole require_gem which is silly. It completely breaks
code written before its appearance and gives sysadmins/coders, at least for
now, the headache of mantaining two systems. It also can lead to the same
module being installed normally in different versions, meaning require_gem
returns one version while require returns another. If rubygems becomes
popular, this may not be an issue. But there's a lot to say about keeping any
new system backwards compatible.

* rubygems lacks ri documentation. Without that, rubygems should really not
have been released yet, in my opinion. Much more important to me than any
silly windows gui installer or what not.

* As a package installer, rubygems currently seems like it does not support
installing gems that have nested directory constructs. Again, this is a huge
problem. For my Getopt/Declare module, it became just getopt-declare/. This
difficults maintaining any complex project with it. It also difficults users'
looking up documentation for it, as ri getopt-declare will deal with nothing.

Anyway, my $0.02 so far.

[David_Ross]

David Ross wrote:

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

···

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

[Andreas_S2 (Andreas S.)]

David Ross wrote:

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.

[Jamis_Buck4 (Jamis Buck)]

Michael DeHaan wrote:

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

···

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

On Thu, 28 Oct 2004 07:49:01 +0900, gabriele renzi > <rff_rff@remove-yahoo.it> wrote:

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

.

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

[David_Ross]

Andreas Schwarz wrote:

David Ross wrote:

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.

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

···

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

[Mauricio_Fernndez]

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

http://rpa-base.rubyforge.org/wiki/wiki.cgi?Developer_Documentation/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

···

On Thu, Oct 28, 2004 at 01:44:00PM +0900, Andreas Schwarz wrote:

David Ross wrote:
>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)

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

[David_A_Black3 (David A. Black)]

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

···

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

--
David A. Black
dblack@wobblini.net