[#1215] Tk widget demo; English Tk docs?; Java 1.2 Swing — "Conrad Schneiker" <schneiker@...>
Hi,
[#1218] Trivial FAQ bug — Dave Thomas <Dave@...>
[#1229] A vote for old behavior — Dave Thomas <Dave@...>
[#1232] Any FAQ requests, updates, ... — Dave Thomas <Dave@...>
[#1233] Singleton classes — Dave Thomas <Dave@...>
[#1263] Draft of the updated Ruby FAQ — Dave Thomas <Dave@...>
[#1307] Ruby/GTK 0.23 released — Hiroshi IGARASHI <igarashi@...>
Hi all,
From: Hiroshi IGARASHI <igarashi@ueda.info.waseda.ac.jp>
From: "Conrad Schneiker" <schneiker@jump.net>
On Fri, Feb 18, 2000 at 09:37:27PM -0500, Yasushi Shoji wrote:
[#1322] FAQ: Ruby acronyms — "Conrad Schneiker" <schneiker@...>
In the spirit of TABWTDI (there are better ways to do it), I'd like to
[#1341] Vim syntax file — Mirko Nasato <mirko.nasato@...>
Hi,
On Mon, Feb 14, 2000 at 05:44:39PM +0100, Mirko Nasato wrote:
[#1354] Say hi (bis) — Pixel <pixel_@...>
hi all,
[#1355] nice sample for functional stuff — Pixel <pixel_@...>
what about having map in standard (and map_index too)?
[#1373] Ruby Language Reference Manual--Glossary — "Conrad Schneiker" <schneiker@...>
I was going to print the Ruby Language Reference Manual when I noticed that
[#1376] Re: Scripting versus programming — Andrew Hunt <andy@...>
Conrad writes:
[#1379] Re: Yield — Andrew Hunt <andy@...>
>From: "Conrad Schneiker" <schneiker@jump.net>
[#1384] Re: Say Hi — mengx@...
My suggestion was to try to find a more comfortable method name (to me, and
[#1392] Re: Some Questions - Parameterised Types / Invariants — Andrew Hunt <andy@...>
>1. Parameterised Types / Template Classes
[#1398] Bignum aset — Andrew Hunt <Andy@...>
[#1488] Discussion happens on news.groups — Clemens Hintze <c.hintze@...>
Hi,
[#1508] Ruby/GTK and the mainloop — Ian Main <imain@...>
Hello Ian,
On Wed, Feb 23, 2000 at 02:56:10AM -0500, Yasushi Shoji wrote:
[#1516] Ruby: PLEASE use comp.lang.misc for all Ruby programming/technical questions/discussions!!!! — "Conrad Schneiker" <schneiker@...>
((FYI: This was sent to the Ruby mail list.))
From: "Conrad Schneiker" <schneiker@jump.net>
[#1528] ruby <=> python — Quinn Dunkan <quinn@...>
Hello! I'm new to ruby-talk, and mostly new to ruby. I'm making a document
[#1551] Ruby thread scheduling buglet — Ian Main <imain@...>
[#1569] Re: Ruby: constructors, new and initialise — Yukihiro Matsumoto <matz@...>
The following message is a courtesy copy of an article
[#1591] Certain char's not recognized by "." in regex? — Wes Nakamura <wknaka@...>
[#1592] Race condition in Singleton — Dave Thomas <Dave@...>
[ruby-talk:01541] Re: Ruby library modules and documentation
The following message is a courtesy copy of an article that has been posted to comp.lang.misc as well. "Conrad Schneiker" <schneiker@jump.net> writes: > It might be a good idea to document these as not being further documented > and to individually identify which ones are obsolete (and its successor), > and which ones of the toys or perlish ones that others would be free to turn > into something more useful (unless there are problems with backwards > compatibility). You know, I've been thinking that it might even be a better idea to reorganize the current library somewhat. Right now, there's stuff in lib/, some of which is useful, some not so. Then there a heap of useful stuff in RAA. So, I'm thinking that maybe there needs to be four library trees: supported, distributed -- final, observer, etc unsupported, distributed -- English, .. supported, not distributed -- irb, benchmark unsupported, not distributed -- ? To qualify for the 'supported' category, a library module must: 1. Be documented with rdtool 2. Install automatically 3. Have a set of regression tests 4. Pass those tests with the currently supported release of Ruby 5. Fit in to the library directory hierarchy (which is yet to be defined, although matz is starting to migrate some stuff into lib/net/). This last point is important. As the size of the library grows, keeping it organized will become a challenge unless we impose some structure from the start. The nice thing is, all these criteria can be tested automatically as part of the overall Ruby testing process, so we can actually cut down on effort at the same time we add value. As the current number of library modules and RAA entries is relatively small, this is a great opportunity to set some standards that will make Ruby an easy language to _manage_ on user's systems. What do people think? Regards Dave