[#6363] Re: rescue clause affecting IO loop behavior — ts <decoux@...>

>>>>> "D" == David Alan Black <dblack@candle.superlink.net> writes:

17 messages 2000/11/14
[#6367] Re: rescue clause affecting IO loop behavior — David Alan Black <dblack@...> 2000/11/14

Hello again --

[#6582] best way to interleaf arrays? — David Alan Black <dblack@...>

Hello --

15 messages 2000/11/26

[#6646] RE: Array Intersect (&) question — Aleksi Niemel<aleksi.niemela@...>

Ross asked something about widely known and largely ignored language (on

23 messages 2000/11/29
[#6652] RE: Array Intersect (&) question — rpmohn@... (Ross Mohn) 2000/11/29

aleksi.niemela@cinnober.com (Aleksi Niemel) wrote in

[#6723] Re: Array Intersect (&) question — Mathieu Bouchard <matju@...> 2000/12/01

> >Use a hash. Here's code to do both and more. It assumes that

[#6656] printing/accessing arrays and hashes — raja@... (Raja S.)

I'm coming to Ruby with a Python & Common Lisp background.

24 messages 2000/11/30

[ruby-talk:6494] about proposals and organisation. Was "Batteries Included" Distribution

From: hipster <hipster@...4all.nl>
Date: 2000-11-21 10:49:57 UTC
List: ruby-talk #6494
On Tue, 21 Nov 2000  16:58:30 +0900, Conrad Schneiker wrote:
[snip]

META: This thread discusses something orthogonal to Conrad's post.

> First, a little introductory background 
> (http://www.cs.man.ac.uk/fellowsd-bin/TIP/):
> 
> # What is a TIP?
> # 
> # TIP stands for Tcl Improvement Proposal. A TIP is a design document
> # providing information to the Tcl community, or describing a new
> # feature for Tcl. The TIP should provide a concise technical
> # specification of the feature and a rationale for the feature.
> # 
> # We intend TIPs to be the primary mechanisms for proposing new
> # features, for collecting community input on an issue, and for
> # documenting the design decisions that have gone into Tcl. The TIP
> # author is responsible for building consensus within the community and
> # documenting dissenting opinions.
> # 
> # Because the TIPs are maintained as text files under revision control,
> # their history is the historical record of the feature proposal.  This
> # historical record is available by the normal (CVS?) commands for
> # retrieving older revisions. For those without direct access to the CVS
> # tree, you can browse the current and past TIP revisions via
> # http://tip.web.site/

Now this is something I'd really like to see for Ruby (e.g. RAP / Ruby
Augmentation Proposals, analogue to RRFC / Ruby Request for Comments).

You'll remember the discussion about a new synchronisation primitive
we had some time ago. As the original poster, I feel responsible for
drawing such threads to a conclusion or consensus. At the moment this
is hard to realize, as the discussion remains just a thread and can
(as it did with the synch discussion) peter out over the weekend.
There's no sense of 'finalisation' (maybe except for Matz's personal
notebook)

This solution begs another question (of course): how are we going to
setup responsibilities? There's always Matz as our benevolent dictator
(Linus:kernel ~ Matz:Ruby), but do we need/want an organisational
structure (like Debian? voting?) to handle these things? We might want
to straighten these things out before our World Domination Plan[tm]
really takes off.

I am not saying the status quo is bad, I'd just like to know what you
people think about this.

	Michel

In This Thread