[ANN] Non-standard library project
 

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

Re: [ANN] Non-standard library project
 

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

> 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 :( 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

Re: [ANN] Non-standard library project
 

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

Re: [ANN] Non-standard library project
 

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

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

Re: [ANN] Non-standard library project
 

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

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

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

Re: [ANN] Non-standard library project
 

I have a radical idea: Why don't we call it something that makes sense,
like "nonstandardlib", or "extralib". I thought "addlib" was catchy.
Let's avoid abbreviating it so badly that I can't tell what it is when I
see it.

Hynek Schlawack wrote:

> * Gavin Sinclair <gsinclair@soyabean.com.au> wrote:
>
>
>>>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. ;)
>
>
>>>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.
>
>
>

Re: [ANN] Non-standard library project
 

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? :)

>
> * 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

Re: [ANN] Non-standard library project
 

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

Re: [ANN] Non-standard library project
 

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

Re: [ANN] Non-standard library project
 

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

> 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? :)

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 :)

> 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