«

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

Nicholas Van Weerdenburg <> wrote:

> 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

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

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

> * Nicholas Van Weerdenburg <> 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.

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

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

> * Nicholas Van Weerdenburg <> 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.

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

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

Are you talking with this guy, yet?



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

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

On Tue, Aug 10, 2004 at 11:16:06AM +0900, Stephen Steiner wrote:
> Are you talking with this guy, yet?
>
>
>
> 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.

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

On Tuesday 10 August 2004 11:20 am, Gavin Sinclair wrote:
> On Wednesday, August 11, 2004, 12:41:23 AM, Ara.T.Howard wrote:
> >> That should give some idea of the nature of the project.
> >>
> >> Gavin
> >
> > what kinds of things are you still looking for gavin?
>
> 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?

--
T.

On Monday, August 23, 2004, 2:34:35 PM, T. wrote:

> On Tuesday 10 August 2004 11:20 am, Gavin Sinclair wrote:
>> On Wednesday, August 11, 2004, 12:41:23 AM, Ara.T.Howard wrote:
>> >> That should give some idea of the nature of the project.
>> >>
>> >> Gavin
>> >
>> > what kinds of things are you still looking for gavin?
>>
>> 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?

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

On Monday 23 August 2004 11:23 am, Gavin Sinclair wrote:
> 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.

--
T.