[ANN] Non-standard library project

G

Gavin Sinclair

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
 
M

Martin DeMello

Gavin Sinclair said:
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
 
C

Curt Hibbs

Gavin said:
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
 
G

Gavin Sinclair

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
 
G

Gavin Sinclair

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
 
T

Tyler Zesiger

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

James Britt

Gavin said:
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
 
T

Tyler Zesiger

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

Aredridel

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
 
G

Gavin Sinclair

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

There or thereabouts.
What's ADT?

Abstract Data Type, e.g. binary trees, insert order hashes.
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'
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.
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
 
N

Nicholas Van Weerdenburg

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
 
M

Martin DeMello

Nicholas Van Weerdenburg said:
For names, addlib is cute, and works on a few levels,

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

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

martin
 
C

Curt Hibbs

Van said:
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
 
M

Mark Hubbart

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

I agree :) '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
 
G

Gavin Sinclair

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

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

Cheers,
Gavin
 
S

Stephen Steiner

--Apple-Mail-1--19671475
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed

Are you talking with this guy, yet?

(e-mail address removed)

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

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

--Apple-Mail-1--19671475--
 
M

Mauricio Fernández

Are you talking with this guy, yet?

(e-mail address removed)

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 believe it can be made better than CPAN (yes, really), which is only
natural since we can learn from their mistakes.
 
T

T. Onoma

Well, I anticipate that eventually the project will contain around 30
libraries. At the moment there are about 5 documented ideas on the
Wiki. So I don't have a shopping list, rather an open ear for
suggestions.

Gavin, I just noticed this post and was looking at the project. I currently
have a library of my own that I call "succ". Now I'm sure many people have
there own personal libraries, but I have been farily careful with mine and
it contains mostly only well refined modifications to the Ruby standard
classes, that I've picked up here and there, and a few new small libraries as
well. Would those be of interest?

Speaking of which I sometimes think it would be nice if there were an easy way
append flags onto #require in order to turn on or off certain features. Kind
of a macro thing. A good psuedo-example of this:

# succ/nil.rb
module NilClass

if Kernel.require_flags[:nil_as_emptiness]
def to_f; 0.0; end
def to_s; ''; end
def to_h; {}; end
def to_a; []; end
# ...
end

def intern
self
end

# ... other stuff

end

Then with something to determine default behavior too:

Kernel.require_default = true

# turn off :nil_as_emptiness
require 'succ/nil', :nil_as_emptiness

Or

Kernel.require_default = false

# turn on :nil_as_emptiness
require 'succ/nil', :nil_as_emptiness

Or something like that. Thoughts?
 
G

Gavin Sinclair

Gavin, I just noticed this post and was looking at the project. I currently
have a library of my own that I call "succ". Now I'm sure many people have
there own personal libraries, but I have been farily careful with mine and
it contains mostly only well refined modifications to the Ruby standard
classes, that I've picked up here and there, and a few new small libraries as
well. Would those be of interest?

Yes, it would. Could you email it to me?
Speaking of which I sometimes think it would be nice if there were an easy way
append flags onto #require in order to turn on or off certain
features. [...]
# turn off :nil_as_emptiness
require 'succ/nil', :nil_as_emptiness
Or something like that. Thoughts?

I think the following is adequate:

require 'succ/nil' # whatever methods are in here

or

require 'succ/nil/as_emptiness' # which loads 'succ/nil' as well

Gavin
 
T

T. Onoma

Yes, it would. Could you email it to me?
I think the following is adequate:

require 'succ/nil' # whatever methods are in here

or

require 'succ/nil/as_emptiness' # which loads 'succ/nil' as well

Nice! I'll organize them per the above and then send.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top