[ANN] Non-standard library project

ruby-talk
1

Hi all,

It's a bit cheeky to call this an announcement, since it's only
announcing a project idea.

I would like to create a RubyForge project that builds a library of
useful classes and modules. That basically describes the standard
library. This library wouldn't be standard, hence the name
"non-standard library".

The purposes of the project:

* collect existing small projects (e.g. Memoize) to ensure their
   continued maintenance, and hopefully give them higher exposure

* provide a good environment for the development of ADTs, etc.
   that might otherwise not seem worthwhile due to project
   management overhead

* provide a rich library that is easy to install and has a high
   standard of documentation and testing

   * thus, convenience and quality

For example, a very recent thread suggested *replacing* pack and
unpack with an OO version (Packer and Unpacker classes). That's a
radical suggestion that's unlikely to be accepted. The milder
approach of providing an OO facade to the existing methods is more
reasonable, but if accepted, would still take a long time to appear in
a Ruby release.

On the other hand, inclusion of this idea in a 'nonstdlib' project
would be feasible and fast. Before long, you could write in your
code something like this:

  require_gem 'nonstdlib', '>= 0.3'
  require 'nonstdlib/packer'

  p = Packer.new
  p.word 0x01
  p.word 0x00
  # etc.

Notice that the version number can be specified to ensure that the
'nonstdlib' gem has the required feature. Of course, you can use
the 'require' line without the 'require_gem' line: RubyGems is not an
actual dependency here.

The steps to getting this started are:

  1. Get feedback from interested people.

  2. Decide on a name.

  3. Start a RubyForge project and mailing list.

  4. Take it from there.

If there's no interest to start with, I'll just get going. But this
sort of thing would benefit from involvement by interested people.

The main thing for now is the name. That enables the creation of the
mailing list, on which people can express interest.

I think 'nonstdlib' is a good name. Anyone got other ideas?

Cheers,
Gavin

2

If there's no interest to start with, I'll just get going. But this
sort of thing would benefit from involvement by interested people.

I'd be very interested, but my new job is taking up an awful amount of
time and I don't have a machine at home yet :frowning: I'll definitely chime in
on the mailing list, though.

The main thing for now is the name. That enables the creation of the
mailing list, on which people can express interest.

I think 'nonstdlib' is a good name. Anyone got other ideas?

It looks nice, but it's a bit of a mouthful. extlib, perhaps? addlib?
tplib (for 'third party')? Also, how does this play with your standard
class extension package?

martin

···

Gavin Sinclair <gsinclair@soyabean.com.au> wrote:

3

Gavin Sinclair wrote:

I would like to create a RubyForge project that builds a library of
useful classes and modules. That basically describes the standard
library. This library wouldn't be standard, hence the name
"non-standard library".

[snip]

The main thing for now is the name. That enables the creation of the
mailing list, on which people can express interest.

I think 'nonstdlib' is a good name. Anyone got other ideas?

I'm not sure how much bandwidth I have left (at least for the remainder of
the summer), but I am definitely interested in participating at some level.

Here are some project-name ides (I tend to prefer short, and easy to type):

  NSL
  NSLIB

Curt

4

Gavin Sinclair wrote:

Hi all,

It's a bit cheeky to call this an announcement, since it's only
announcing a project idea.

I would like to create a RubyForge project that builds a library of
useful classes and modules. That basically describes the standard
library. This library wouldn't be standard, hence the name
"non-standard library".

The purposes of the project:

* collect existing small projects (e.g. Memoize) to ensure their
   continued maintenance, and hopefully give them higher exposure

Would these be projects that have reached the end of their development (i.e., they're "done")?

* provide a good environment for the development of ADTs, etc.
   that might otherwise not seem worthwhile due to project
   management overhead

What's ADT?

* provide a rich library that is easy to install and has a high
   standard of documentation and testing

Does rich === large? :slight_smile:

   * thus, convenience and quality

A concern: n different libraries have ~n owners. How is project access/admin handled through RubyForge?

Why is this better than having a separate project for each library? Is it that much harder to create a new project than it is to get a project added to the NSL?

For example, a very recent thread suggested *replacing* pack and
unpack with an OO version (Packer and Unpacker classes). That's a
radical suggestion that's unlikely to be accepted. The milder
approach of providing an OO facade to the existing methods is more
reasonable, but if accepted, would still take a long time to appear in
a Ruby release.

On the other hand, inclusion of this idea in a 'nonstdlib' project
would be feasible and fast. Before long, you could write in your
code something like this:

  require_gem 'nonstdlib', '>= 0.3'

Another concern (playing Devil's advocate here): How is this different from

   require_gem 'kitchen_sink_plus_more', '>= 0.3'

I think I would prefer to install those libs I expect I'll need, rather use bulk packaging.

I agree, though, that there is the matter of small, useful libs disappearing over time from owner attrition( I'm finding this to be the case with the sysvipc lib), but I'm not convinced about arbitrary bundling.

James

5

Might this have a place in the "batteries included" ideas that have been floating around for a future ruby release? It sounds like a good start to me.

Gavin Sinclair wrote:

···

Hi all,

It's a bit cheeky to call this an announcement, since it's only
announcing a project idea.

I would like to create a RubyForge project that builds a library of
useful classes and modules. That basically describes the standard
library. This library wouldn't be standard, hence the name
"non-standard library".

The purposes of the project:

* collect existing small projects (e.g. Memoize) to ensure their
   continued maintenance, and hopefully give them higher exposure

* provide a good environment for the development of ADTs, etc.
   that might otherwise not seem worthwhile due to project
   management overhead

* provide a rich library that is easy to install and has a high
   standard of documentation and testing

   * thus, convenience and quality

For example, a very recent thread suggested *replacing* pack and
unpack with an OO version (Packer and Unpacker classes). That's a
radical suggestion that's unlikely to be accepted. The milder
approach of providing an OO facade to the existing methods is more
reasonable, but if accepted, would still take a long time to appear in
a Ruby release.

On the other hand, inclusion of this idea in a 'nonstdlib' project
would be feasible and fast. Before long, you could write in your
code something like this:

  require_gem 'nonstdlib', '>= 0.3'
  require 'nonstdlib/packer'

  p = Packer.new
  p.word 0x01
  p.word 0x00
  # etc.

Notice that the version number can be specified to ensure that the
'nonstdlib' gem has the required feature. Of course, you can use
the 'require' line without the 'require_gem' line: RubyGems is not an
actual dependency here.

The steps to getting this started are:

  1. Get feedback from interested people.

  2. Decide on a name.

  3. Start a RubyForge project and mailing list.

  4. Take it from there.

If there's no interest to start with, I'll just get going. But this
sort of thing would benefit from involvement by interested people.

The main thing for now is the name. That enables the creation of the
mailing list, on which people can express interest.

I think 'nonstdlib' is a good name. Anyone got other ideas?

Cheers,
Gavin

6

It's an interesting concept. Convenience and quality are huge factors in utility.

The Jakarta commons comes to mind of an interesting model, as well as the Apache incubator.

The existense of a target structure for things would be a motivating and organizing means for the community as well. In of itself, a project on RAA is high-effort/high-risk to use unless I hear frequent mention of it. If contained in a pre-validated library, it becomes much more comforting to try something out.

Also, a large project can make code more "free" from ownership, which can actually be a motivating factor to work on it- the assumption that someone owns and is happily working on something isn't there, and there is a great sense of potential community benefit to working on something.

It might be worthwhile to late-bind on the naming, or use a code name for now. The project might refactor itself in interesting ways.

I heard another response say something about an existing library called ruby-sumo. Don't know what that is exactly, but it's a cool handle!

For names, addlib is cute, and works on a few levels,

From dictionary.com:
adlib- "To improvise and deliver extemporaneously".

I don't mind acronyms for something like this- it'll be fairly foundational (I almost said standard :)) so something like nstdlib works for me. "extlib" I also like, since it plays on stdlib in C.

The other option is to brand the effort, aka Jakarta from Apache.

Maybe something like "glitter", "shine", "red", "jones", "rubicon" (taken, I'm sure by some project), "tuesday" (also taken, I expect), "kansas", "toto", "bricks", "blocks", "lumber", "bamboo", etc.

Nick

Gavin Sinclair wrote:

···

Hi all,

It's a bit cheeky to call this an announcement, since it's only
announcing a project idea.

I would like to create a RubyForge project that builds a library of
useful classes and modules. That basically describes the standard
library. This library wouldn't be standard, hence the name
"non-standard library".

The purposes of the project:

* collect existing small projects (e.g. Memoize) to ensure their
  continued maintenance, and hopefully give them higher exposure

* provide a good environment for the development of ADTs, etc.
  that might otherwise not seem worthwhile due to project
  management overhead

* provide a rich library that is easy to install and has a high
  standard of documentation and testing

  * thus, convenience and quality

For example, a very recent thread suggested *replacing* pack and
unpack with an OO version (Packer and Unpacker classes). That's a
radical suggestion that's unlikely to be accepted. The milder
approach of providing an OO facade to the existing methods is more
reasonable, but if accepted, would still take a long time to appear in
a Ruby release.

On the other hand, inclusion of this idea in a 'nonstdlib' project
would be feasible and fast. Before long, you could write in your
code something like this:

require_gem 'nonstdlib', '>= 0.3'
require 'nonstdlib/packer'

p = Packer.new
p.word 0x01
p.word 0x00
# etc.

Notice that the version number can be specified to ensure that the
'nonstdlib' gem has the required feature. Of course, you can use
the 'require' line without the 'require_gem' line: RubyGems is not an
actual dependency here.

The steps to getting this started are:

1. Get feedback from interested people.

2. Decide on a name.

3. Start a RubyForge project and mailing list.

4. Take it from there.

If there's no interest to start with, I'll just get going. But this
sort of thing would benefit from involvement by interested people.

The main thing for now is the name. That enables the creation of the
mailing list, on which people can express interest.

I think 'nonstdlib' is a good name. Anyone got other ideas?

Cheers,
Gavin

7

Are you talking with this guy, yet?

batsman.geo@yahoo.com

See his: Subject: [ANN] Preliminary Ruby Production Archive -- over 100 packages available

Looks to me like everyone wants the same thing: CPAN for Ruby.

Steve

···

On Jun 14, 2004, at 4:59 AM, Gavin Sinclair wrote:

Hi all,

It's a bit cheeky to call this an announcement, since it's only
announcing a project idea.

I would like to create a RubyForge project that builds a library of
useful classes and modules. That basically describes the standard
library. This library wouldn't be standard, hence the name
"non-standard library".

The purposes of the project:

* collect existing small projects (e.g. Memoize) to ensure their
   continued maintenance, and hopefully give them higher exposure

* provide a good environment for the development of ADTs, etc.
   that might otherwise not seem worthwhile due to project
   management overhead

* provide a rich library that is easy to install and has a high
   standard of documentation and testing

   * thus, convenience and quality

For example, a very recent thread suggested *replacing* pack and
unpack with an OO version (Packer and Unpacker classes). That's a
radical suggestion that's unlikely to be accepted. The milder
approach of providing an OO facade to the existing methods is more
reasonable, but if accepted, would still take a long time to appear in
a Ruby release.

On the other hand, inclusion of this idea in a 'nonstdlib' project
would be feasible and fast. Before long, you could write in your
code something like this:

  require_gem 'nonstdlib', '>= 0.3'
  require 'nonstdlib/packer'

  p = Packer.new
  p.word 0x01
  p.word 0x00
  # etc.

Notice that the version number can be specified to ensure that the
'nonstdlib' gem has the required feature. Of course, you can use
the 'require' line without the 'require_gem' line: RubyGems is not an
actual dependency here.

The steps to getting this started are:

  1. Get feedback from interested people.

  2. Decide on a name.

  3. Start a RubyForge project and mailing list.

  4. Take it from there.

If there's no interest to start with, I'll just get going. But this
sort of thing would benefit from involvement by interested people.

The main thing for now is the name. That enables the creation of the
mailing list, on which people can express interest.

I think 'nonstdlib' is a good name. Anyone got other ideas?

Cheers,
Gavin

8

The main thing for now is the name. That enables the creation of the
mailing list, on which people can express interest.

I think 'nonstdlib' is a good name. Anyone got other ideas?

I'm not sure how much bandwidth I have left (at least for the remainder of
the summer), but I am definitely interested in participating at some level.

Cool. As far as "participating at some level" goes, simply lurking on
the mailing list and throwing in occasional suggestions is a good level of
participation.

For any "package" that could be implemented, there are obviously
different ways to name methods, present APIs, etc. So airing
different points of view would be a great help.

I certainly don't intend it to be a high-intensity project that takes
up lots of people's time. Backward-incompatibilities would be
strenuously avoided, which means a slow, considered pace is likely.

Here are some project-name ideas (I tend to prefer short, and easy to type):

  NSL
  NSLIB

I guess this seems reasonable as an example:

  require 'nslib/packer'

Gavin

···

On Monday, June 14, 2004, 10:42:15 PM, Curt wrote:

9

Completely different. 'extensions' adds methods to built-in classes.
It explicitly avoids stdlib classes.

nonstdlib would, I suspect, try not to modify stdlib classes too, I
think. There would probably be times when doing so would make sense,
though.

The best way to describe the aim of this project, I suppose, is "to
complement the standard library".

Gavin

···

On Monday, June 14, 2004, 8:03:38 PM, Martin wrote:

Also, how does this play with your standard class extension package?

10

> I think 'nonstdlib' is a good name. Anyone got other ideas?

It looks nice, but it's a bit of a mouthful. extlib, perhaps? addlib?
tplib (for 'third party')? Also, how does this play with your standard
class extension package?

It sounds a lot like ruby-sumo in some ways.

This is a sort of project I was thinking I'd like to work on as well,
and lo, here's the announcement. Quite surreal.

I'd love to see such a library serve two purposes:

1) a widely available, visible place for small extensions that "play
nice" -- they follow the style of the standard library, and are not
difficult to install. Things with minimal or standard dependencies like
WEBrick was before it was standard would be the sort of project I'd love
to see included.

2) a place for extensions that may eventually become standard. A sort of
proving ground, a place for well-made libraries to get some visibility
as "the one to use", once they're established and widely accepted. It
would make some sense of the often murky waters of the ruby sites around
the world. Crême de la crême, as it were.

Ari

11

Gavin Sinclair wrote:

Hi all,

It's a bit cheeky to call this an announcement, since it's only
announcing a project idea.

I would like to create a RubyForge project that builds a library of
useful classes and modules. That basically describes the standard
library. This library wouldn't be standard, hence the name
"non-standard library".

The purposes of the project:

* collect existing small projects (e.g. Memoize) to ensure their
   continued maintenance, and hopefully give them higher exposure

Would these be projects that have reached the end of their development
(i.e., they're "done")?

There or thereabouts.

* provide a good environment for the development of ADTs, etc.
   that might otherwise not seem worthwhile due to project
   management overhead

What's ADT?

Abstract Data Type, e.g. binary trees, insert order hashes.

* provide a rich library that is easy to install and has a high
   standard of documentation and testing

Does rich === large? :slight_smile:

Yeah, the idea is to be large, just like the standard library. Also
like the standard library, it's not loaded monolithically. Thus, for
example:

  require 'nonstdlib' # LoadError

  require 'nonstdlib/this'
  require 'nonstdlib/that'
  require 'nonstdlib/one_thing'
  require 'nonstdlib/the_other'

   * thus, convenience and quality

A concern: n different libraries have ~n owners. How is project
access/admin handled through RubyForge?

If a package is added to NSL, it's under the "do whatever you
like with the code" clause of the license, not under the "I am, now
and forever, the maintainer of this code". Original authors are
welcome to participate, but in practice I suspect many wouldn't bother
and would be happy seeing someone do something with their code (with
credit attributed, of course). We'll see. I don't anticipate any
hostile takeovers :slight_smile:

Why is this better than having a separate project for each library? Is
it that much harder to create a new project than it is to get a project
added to the NSL?

It's not hard to create a new RubyForge project, but it's a lot of
work. If someone writes a useful package for their own program and
couldn't be bothered releasing it, it won't see the light of day.
OTOH, it can be included (perhaps with modification, and with some
testing and documentation) in the NSL, then more people are
benefiting.

For example, a very recent thread suggested *replacing* pack and
unpack with an OO version (Packer and Unpacker classes). That's a
radical suggestion that's unlikely to be accepted. The milder
approach of providing an OO facade to the existing methods is more
reasonable, but if accepted, would still take a long time to appear in
a Ruby release.

On the other hand, inclusion of this idea in a 'nonstdlib' project
would be feasible and fast. Before long, you could write in your
code something like this:

  require_gem 'nonstdlib', '>= 0.3'

Another concern (playing Devil's advocate here): How is this different
from

   require_gem 'kitchen_sink_plus_more', '>= 0.3'

You might be implying that such a statement will import *lots* of
stuff into your code, which it wouldn't. See also my comment about
arbitrary bundling below.

I think I would prefer to install those libs I expect I'll need, rather
use bulk packaging.

It's more convenient to install one

I agree, though, that there is the matter of small, useful libs
disappearing over time from owner attrition( I'm finding this to be the
case with the sysvipc lib), but I'm not convinced about arbitrary bundling.

Well, the bundling will be guided by some (yet to be determined)
principles. Basically though, if a package *would be* a decent fit
with the Ruby standard library, but the stdlib is not taking offers
right now, then it's good for the NSL.

So there's another false comparison with 'kitchen_sink_plus_more'.
It's not a repository for projects that need a home, despite having
nothing in common. The aim is to be consistent in purpose, quality,
and presentation, and thus to get more mileage out of the code than
would be likely if the projects were held in isolation.

I'd be interested to know if this addresses your points adequately.

Cheers,
Gavin

PS. Here's a rough list of things I have considered as good candidates
for inclusion (these are ideas, not necessarily existing
implementations):

* Caching results of method calls (a la Robert Klemme's Memoize)

* Data types:
   * bounded LRU cache
   * insert order hash

* some text formatting utils (no specific idea yet)

* DateTime::Interval

* Packer/Unpacker classes as recently discussed

Obviously, these are not all well-thought-through proposals for
specific inclusion, just an idea of what sort of things I'm after.

Cheers,
Gavin

···

On Tuesday, June 15, 2004, 1:59:55 AM, James wrote:

12

Yeah, that's what I had in mind (:

martin

···

Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote:

For names, addlib is cute, and works on a few levels,

From dictionary.com:
adlib- "To improvise and deliver extemporaneously".

13

Van Weerdenburg wrote:

For names, addlib is cute, and works on a few levels,

From dictionary.com:
adlib- "To improvise and deliver extemporaneously".

I don't mind acronyms for something like this- it'll be fairly
foundational (I almost said standard :)) so something like nstdlib works
for me. "extlib" I also like, since it plays on stdlib in C.

"adlib" is cute for its double meaning. I still like "nslib" (I'm biased,
since I proposed it), but the above also made me think of "xlib".

Curt

14

I guess double meanings are very programmer-like so I'd vote for it. :slight_smile:

···

* Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote:

For names, addlib is cute, and works on a few levels,
From dictionary.com:
adlib- "To improvise and deliver extemporaneously".

15

I believe it can be made better than CPAN (yes, really), which is only
natural since we can learn from their mistakes.

···

On Tue, Aug 10, 2004 at 11:16:06AM +0900, Stephen Steiner wrote:

Are you talking with this guy, yet?

batsman.geo@yahoo.com

See his: Subject: [ANN] Preliminary Ruby Production Archive --
over 100 packages available

Looks to me like everyone wants the same thing: CPAN for Ruby.

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

16

Are you talking with this guy, yet?

batsman.geo@yahoo.com

Dunno. Are we talking yet, Mauricio? :slight_smile:

See his: Subject: [ANN] Preliminary Ruby Production Archive -- over
100 packages available

Looks to me like everyone wants the same thing: CPAN for Ruby.

I guess I didn't explain the 'nonstdlib' concept very well, then. It's
now called 'addlib' and rooted at http://addlib.rubyforge.org.

The idea of 'addlib' is to create a collection of fairly general
libraries, not to provide a packaging/distribution mechanism for
existing ones.

For those who are interested, I'll be creating a "rough" directory in
the CVS soon (no promises as to when :slight_smile: containing the following code:
- an Enum module (by Tim Hunter, think C's enum keyword)
- an IO mixin for dealing with binary data (Michael Neumann's recent
   ruby-talk contribution)
- a command-line command parser, as opposed to option parser (ripped
   from RubyGems, works nicely with optparse)

That should give some idea of the nature of the project.

Gavin

···

On Tuesday, August 10, 2004, 12:16:06 PM, Stephen wrote:

17

I'm not sure how much bandwidth I have left (at least for the remainder of
the summer), but I am definitely interested in participating at some level.

Cool. As far as "participating at some level" goes, simply lurking on
the mailing list and throwing in occasional suggestions is a good
level of participation.

I'd love to help too. I'm lacking creativity to start an own module just
now but would definitly like to help ruby on the way to RAA > CPAN. :wink:

Here are some project-name ideas (I tend to prefer short, and easy to
type):
  NSL
  NSLIB

I guess this seems reasonable as an example:
  require 'nslib/packer'

Hm, doesn't it sound a bit too much like "libnsl"? Might be confusing
under unix. I'd suggest rather "nstdlib" or alike.

···

* Gavin Sinclair <gsinclair@soyabean.com.au> wrote:

18

I agree :slight_smile: 'addlib' has a great double-meaning, and 'nonstdlib' has a good dose of irony. Both are great as far as I'm concerned.

cheers,
Mark

···

On Jun 15, 2004, at 5:28 AM, Hynek Schlawack wrote:

* Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote:

For names, addlib is cute, and works on a few levels,
From dictionary.com:
adlib- "To improvise and deliver extemporaneously".

I guess double meanings are very programmer-like so I'd vote for it. :slight_smile:

19

Ok, after a beer-soaked Ruby Tuesday meeting with my Sydney
cohabitants, I've been sold on 'addlib'. Thanks for all the
suggestions.

I'll announce the project with mailing list details and clearer goals
once I get it set up. Not that I'm trying to make a fanfare or
anything; I'd just like to draw interested people while I've still got
their attention :slight_smile:

Cheers,
Gavin

···

On Tuesday, June 15, 2004, 10:28:27 PM, Hynek wrote:

* Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote:

For names, addlib is cute, and works on a few levels,
From dictionary.com:
adlib- "To improvise and deliver extemporaneously".

I guess double meanings are very programmer-like so I'd vote for it. :slight_smile:

20

what kinds of things are you still looking for gavin?

-a

···

On Tue, 10 Aug 2004, Gavin Sinclair wrote:

On Tuesday, August 10, 2004, 12:16:06 PM, Stephen wrote:

Are you talking with this guy, yet?

batsman.geo@yahoo.com

Dunno. Are we talking yet, Mauricio? :slight_smile:

See his: Subject: [ANN] Preliminary Ruby Production Archive -- over
100 packages available

Looks to me like everyone wants the same thing: CPAN for Ruby.

I guess I didn't explain the 'nonstdlib' concept very well, then. It's
now called 'addlib' and rooted at http://addlib.rubyforge.org.

The idea of 'addlib' is to create a collection of fairly general
libraries, not to provide a packaging/distribution mechanism for
existing ones.

For those who are interested, I'll be creating a "rough" directory in
the CVS soon (no promises as to when :slight_smile: containing the following code:
- an Enum module (by Tim Hunter, think C's enum keyword)
- an IO mixin for dealing with binary data (Michael Neumann's recent
  ruby-talk contribution)
- a command-line command parser, as opposed to option parser (ripped
  from RubyGems, works nicely with optparse)

That should give some idea of the nature of the project.

Gavin

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen

===============================================================================