[#1579] arity bug? — "Christoph" <chr_news@...>
Hi,
5 messages
2003/10/05
[#1588] FreeBSD problem with processes — Laurent Sansonetti <pinux@...>
Hi all,
1 message
2003/10/07
[#1591] Re: Yielding to a block from a proc? — george.marrows@...
> > Is this right? Is this pathological? Is it a bug? Is there
6 messages
2003/10/08
[#1596] PATCH: Revive NextStep, OpenStep, Rhapsody ports — Eric Sunshine <sunshine@...>
Hello,
7 messages
2003/10/09
[#1597] Re: PATCH: Revive NextStep, OpenStep, Rhapsody ports
— matz@... (Yukihiro Matsumoto)
2003/10/09
Hi,
[#1600] CVS access — Sean Russell <ser@...>
Hiya,
8 messages
2003/10/09
[#1611] set_trace_func/Array#fetch error — "Nathaniel Talbott" <nathaniel@...>
I've reduced the error I reported in ruby-talk:84013 to the following code:
17 messages
2003/10/11
[#1612] Re: set_trace_func/Array#fetch error
— ts <decoux@...>
2003/10/11
>>>>> "N" == Nathaniel Talbott <nathaniel@talbott.ws> writes:
[#1616] Re: set_trace_func/Array#fetch error
— "Nathaniel Talbott" <nathaniel@...>
2003/10/11
ts [mailto:decoux@moulon.inra.fr] wrote:
[#1617] Re: set_trace_func/Array#fetch error
— ts <decoux@...>
2003/10/11
>>>>> "N" == Nathaniel Talbott <nathaniel@talbott.ws> writes:
[#1618] Re: set_trace_func/Array#fetch error
— "Nathaniel Talbott" <nathaniel@...>
2003/10/11
ts [mailto:decoux@moulon.inra.fr] wrote:
[#1634] stringy range bug — "Christoph" <chr_news@...>
Hi,
6 messages
2003/10/15
[#1640] SystemStackError in embedding — Sentinel <sentinel27@...>
Hi, I am just now trying to embed ruby into my apprication
8 messages
2003/10/18
Re: PATCH: Revive NextStep, OpenStep, Rhapsody ports
From:
Eric Sunshine <sunshine@...>
Date:
2003-10-10 16:45:12 UTC
List:
ruby-core #1608
On Sat, 11 Oct 2003 01:11:35 +0900, Yukihiro Matsumoto wrote:
> In message "Re: PATCH: Revive NextStep, OpenStep, Rhapsody ports"
> on 03/10/10, Eric Sunshine <sunshine@sunshineco.com> writes:
> |I can re-submit the patch without the fixes for those three methods in the
> |curses module, if you like. Would this be more acceptable?
> Or explain those modifies. I'm waiting for confirmation anyway.
I consulted several `man' pages and found that the existing curses extension
was returning values inconsistent with the `man' page documentation. Below
is a summary.
The bkgd() and wbkgd() functions are documented as returning OK (a boolean
value), but the existing curses extension returns a numeric value from these
functions. I changed the return value of these functions to boolean to be
consistent with the documentation. Here is an excerpt from a manual page:
RETURN VALUE
The routines bkgd and wbkgd return the integer OK. The
SVr4.0 manual says "or a non-negative integer if immedok
is set", but this appears to be an error.
Here are some URLs from various vendors which document the return values
from these two functions:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/bkgd.3x.html
http://docs.hp.com/cgi-bin/doc3k/B3643090008.12947/56
http://www.mkssoftware.com/docs/man3/curs_bkgd.3.asp
The getbkgd() function is documented in a number of places as returning a
numeric result unless there is an error, in which case ERR is returned. Here
is an excerpt from a manual page:
RETURN VALUE
Upon successful completion, getbkgd() returns the
specified window's background character and
rendition. Otherwise, it returns (chtype)ERR.
Here are som URLs from various vendors which document the return value from
this function:
http://www.opengroup.org/onlinepubs/7908799/xcurses/bkgd.html
http://docs.sun.com/db/doc/816-3323/6m9k40tdl?a=view
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V40G_HTML/MAN/MAN3/0092____.HTM
The existing Ruby curses extension always returns a numeric result, even if
getbkgd() returns ERR. I changed it so that the Ruby function returns nil if
ERR is returned from the getbkgd() curses function in order to be consistent
with the curses_curs_set() function in curses.c. The curs_set() function
also returns a numeric result unless an error occurs, in which case it
returns ERR. The Ruby curses_curs_set() cover function converts the ERR to
Ruby nil upon return. It seems to me that these two curses functions, which
have similar return values (numeric or ERR), should be treated similarly by
the Ruby code.
-- ES