[#2320] Problems in mathn, rational, complex, matrix — Gavin Sinclair <gsinclair@...>
I received a message from Richard Graham mentioning a problem in the
[#2346] Patch for socket.c: control reverse lookup for every instance — Thomas Uehlinger <uehli@...>
Hi all
[#2357] Use the BasicSocket#do_not_reverse_lookup flag in Webrick — Thomas Uehlinger <uehli@...>
Hi
[#2367] Standard libraries — Dave Thomas <dave@...>
From ruby-dev summary:
Hi,
Hi,
By the way, this issue is about a matter of taste, so the debate is somewhat
Hi,
On Thu, Feb 12, 2004 at 02:58:22PM +0900, NAKAMURA, Hiroshi wrote:
On Thursday, February 12, 2004, 8:18:32 PM, Mauricio wrote:
On Thursday 12 February 2004 04:37, Gavin Sinclair wrote:
On Friday, February 13, 2004, 12:44:15 AM, Sean wrote:
(Dave Thomas: there's a question for you in the second paragraph; if you're
[#2397] PATCH: deprecate cgi-lib, getopts, importenv, parsearg from standard library — Gavin Sinclair <gsinclair@...>
Index: cgi-lib.rb
* Gavin Sinclair (gsinclair@soyabean.com.au) wrote:
On Thursday, February 12, 2004, 11:39:37 PM, E wrote:
Hi,
Hi,
[#2422] Re: [ruby-cvs] ruby: * lib/ftools.rb: documented — "U.Nakamura" <usa@...>
Hello,
[#2449] make install not getting through rdoc phase — "David A. Black" <dblack@...>
Hi --
[#2465] PATCH: OpenStruct#initialize to yield self — Gavin Sinclair <gsinclair@...>
This is a common approach I use to object initialization; I don't know
On Fri, 20 Feb 2004 02:42:00 +0900, Dave Thomas wrote:
> > As more general suggestion. Could 'new' yield the new object is a block
On Fri, 20 Feb 2004 08:24:31 +0900, Carlos wrote:
Hi,
Yukihiro Matsumoto wrote:
On Feb 20, 2004, at 4:33 PM, Joel VanderWerf wrote:
[#2494] rehash segfault — Nathaniel Talbott <nathaniel@...>
I don't have a lot of information on this bug at this point, but
Hi,
On Wed, Feb 25, 2004 at 03:30:54AM +0900, Yukihiro Matsumoto wrote:
[#2504] foldl and foldr — "Sean E. Russell" <ser@...>
Sorry if I'm opening old wounds; I have a hard time believing that nobody has
Re: Standard libraries
> |Sounds good. Is there sense in starting a discussion about removing
> |some out-of-date libraries now?
>
> Yes.
OK, what about 'cgi-lib', 'getopts', 'importenv', and 'parsearg'? Here
are some options (for example, with 'getopts'):
* remove lib/getopts.rb
* replace the contents of lib/getopts.rb with
raise "'getopts' is no longer supported from 1.8.2 onwards"
* add a deprecation warning, but let the code work anyway, and
remove it after 1.8.2 (or whenever is suitable)
* move lib/getopts.rb to lib/_old/getopts.rb, forcing users to change
code
* as above, but make lib/getopts.rb look like this:
warn "getopts.rb is deprecated and will disappear after 1.8.2"
require 'lib/_getopts'
I'm not sure what's the best option. I imagine that practically no code
is written for Ruby 1.8 that uses libraries like these, so I'd be inclined
to just remove them!
If we wish to deprecate (which is wise, I suppose), then I like the idea
of an _old directory. It puts all the unwanted code in one place and
removes it from the lib directory.
What are your thoughts, Matz? I'll happily create a patch for any
scenario you wish in order to clean these files up.
> |Also: base64. Can we put the recent HEAD change (modularisation, and
> |deprecating the top-level namespace pollution) in the 1.8 branch as
> |well? It makes sense to deprecate it now, IMO.
>
> OK. Could you put it to 1.8?
Can do (tonight, Japanese time).
Gavin