[ANN] Non-standard library project

Discussion in 'Ruby' started by Gavin Sinclair, Jun 14, 2004.

  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
    Gavin Sinclair, Jun 14, 2004
    #1
    1. Advertising

  2. Gavin Sinclair <> 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
    Martin DeMello, Jun 14, 2004
    #2
    1. Advertising

  3. Gavin Sinclair

    Curt Hibbs Guest

    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
    Curt Hibbs, Jun 14, 2004
    #3
  4. 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
    Gavin Sinclair, Jun 14, 2004
    #4
  5. 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
    Gavin Sinclair, Jun 14, 2004
    #5
  6. 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 <> 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.
    >
    >
    >
    Tyler Zesiger, Jun 14, 2004
    #6
  7. Gavin Sinclair

    James Britt Guest

    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
    James Britt, Jun 14, 2004
    #7
  8. 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
    >
    >
    >
    >
    >
    >
    Tyler Zesiger, Jun 14, 2004
    #8
  9. Gavin Sinclair

    Aredridel Guest

    > > 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
    Aredridel, Jun 14, 2004
    #9
  10. 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
    Gavin Sinclair, Jun 15, 2004
    #10
  11. 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, Jun 15, 2004
    #11
  12. 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
    Martin DeMello, Jun 15, 2004
    #12
  13. Gavin Sinclair

    Curt Hibbs Guest

    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
    Curt Hibbs, Jun 15, 2004
    #13
  14. Gavin Sinclair

    Mark Hubbart Guest

    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
    Mark Hubbart, Jun 15, 2004
    #14
  15. 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
    Gavin Sinclair, Jun 15, 2004
    #15
  16. --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--
    Stephen Steiner, Aug 10, 2004
    #16
  17. 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
    Mauricio Fernández, Aug 10, 2004
    #17
  18. Gavin Sinclair

    T. Onoma Guest

    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.
    T. Onoma, Aug 23, 2004
    #18
  19. 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
    Gavin Sinclair, Aug 23, 2004
    #19
  20. Gavin Sinclair

    T. Onoma Guest

    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.
    T. Onoma, Aug 23, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. steve.leach

    How standard is the standard library?

    steve.leach, Apr 18, 2005, in forum: Python
    Replies:
    1
    Views:
    388
    Christos TZOTZIOY Georgiou
    Apr 18, 2005
  2. Jon Hewer
    Replies:
    0
    Views:
    244
    Jon Hewer
    Aug 19, 2005
  3. Steve Holden
    Replies:
    6
    Views:
    345
    Terry Reedy
    Aug 20, 2005
  4. funkyj
    Replies:
    5
    Views:
    1,122
    funkyj
    Jan 20, 2006
  5. Joe Van Dyk
    Replies:
    3
    Views:
    138
    Kouhei Sutou
    Dec 7, 2006
Loading...

Share This Page