[#7043] RUBYOPT versioning? — Caleb Tennis <caleb@...>
Matz, others:
[#7050] RDoc patches for BigDecimal in Ruby CVS — mathew <meta@...>
Now that 1.8.4 is out and the initial flurry of problem reports has died
[#7055] More on VC++ 2005 — Austin Ziegler <halostatue@...>
Okay. I've got Ruby compiling. I'm attempting to get everything in
Hi,
On 05/01/06, nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
On 06/01/06, Austin Ziegler <halostatue@gmail.com> wrote:
Hi,
On 09/01/06, nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
[#7057] 64-bit Solaris READ_DATA_PENDING Revisited — Steven Lumos <steven@...>
[#7078] CRC - a proof-of-concept Ruby compiler — Anders Hkersten <chucky@...>
Hello everyone,
[#7084] mathn: ugly warnings — hadmut@... (Hadmut Danisch)
Hi,
Hadmut Danisch wrote:
Daniel Berger wrote:
*Dean Wampler *<deanwampler gmail.com> writes:
On Fri, 13 Jan 2006, mathew wrote:
On Fri, 13 Jan 2006, Mathieu Bouchard wrote:
ara.t.howard@noaa.gov wrote:
On Fri, 13 Jan 2006, James Britt wrote:
Dean Wampler <deanwampler gmail.com> writes:
On Sat, 14 Jan 2006, mathew wrote:
[#7100] core dump with ruby 1.9.0 (2006-01-10) and bdb-0.5.8 — Tanaka Akira <akr@...17n.org>
I found following test script dumps core.
>>>>> "T" == Tanaka Akira <akr@m17n.org> writes:
In article <200601110905.k0B950Op001713@moulon.inra.fr>,
[#7109] Calling flock with block? — Bertram Scharpf <lists@...>
Hi,
On Thu, 12 Jan 2006, Bertram Scharpf wrote:
[#7129] YAML.load({[]=>""}.to_yaml) — Tanaka Akira <akr@...17n.org>
I found that current YAML doesn't round trip {[]=>""}.
Hi.
Hi.
In article <20060115202203.D3624CA0.ocean@m2.ccsnet.ne.jp>,
[#7162] FileUtils.mv does not unlink source file when moving over filesystem boundary — Pav Lucistnik <pav@...>
Hi,
On Mon, 16 Jan 2006, Pav Lucistnik wrote:
[#7178] Add XHTML 1.0 Output Support to Ruby CGI — Paul Duncan <pabs@...>
The attached patch against Ruby 1.8.4 adds XHTML 1.0 output support to
[#7186] Ruby 1.9 and FHS — "Kirill A. Shutemov" <k.shutemov@...>
Build and install system changes:
[#7195] trouble due ruby redefining posix function eaccess — noreply@...
Bugs item #3317, was opened at 2006-01-24 15:33
[#7197] SSL-enabled DRb fds on SSLError? — ctm@... (Clifford T. Matthews)
Howdy,
On Jan 24, 2006, at 12:46 PM, Clifford T. Matthews wrote:
Patch worked fine against HEAD.
[#7203] bcc32's memory manager bug — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
Hi.
[#7211] Some troubles with an embedded ruby interpreter — Matt Mower <matt.mower@...>
Hi folks,
[#7216] String#scan loops forefever if scanned string is modified inside block. — noreply@...
Bugs item #3329, was opened at 2006-01-26 10:55
[#7226] Fwd: Re: Question about massive API changes — "Sean E. Russell" <ser@...>
Hello,
Sean E. Russell wrote:
>
On 1/28/06, Caleb Tennis <caleb@aei-tech.com> wrote:
On Saturday 28 January 2006 17:13, Wilson Bilkovich wrote:
Sean E. Russell wrote:
[#7249] PATCH: append option to sysread — Yohanes Santoso <ysantoso-rubycore@...>
[#7259] TCP/UDP server weird lags on 1.8.4 linux — "Bill Kelly" <billk@...>
Hi !
64-bit Solaris READ_DATA_PENDING Revisited
I have to start off with an apology. Over a year ago, I submitted a
READ_DATA_PENDING patch to use __fpending() [ruby-core:3766]. I then
failed to notice the discussion starting at [ruby-core:3785], and even
failed to notice later that my patch had been backed out. Guy Decoux
was completely correct: __fpending() only works for output streams!
So, sorry to anyone whose time was wasted either by my broken patch or
by the fact that I didn't follow up and come up with a correct version
sooner (i.e. anyone who tried to compile 64-bit on Solaris in the last
year). I'm only figuring this out now due to [ruby-talk:153006].
Here's something that actually works (for me):
--- io.c.orig 2006-01-05 16:12:19.634441000 -0800
+++ io.c 2006-01-05 11:15:50.907474000 -0800
@@ -156,6 +156,19 @@
# define READ_DATA_PENDING_COUNT(fp) ((unsigned int)(*(fp))->_cnt)
# define READ_DATA_PENDING(fp) (((unsigned int)(*(fp))->_cnt) > 0)
# define READ_DATA_BUFFERED(fp) 0
+#elif defined(__sparc) && defined(_LP64) && defined(__SVR4)
+typedef struct _FILE64 {
+ unsigned char *_ptr; /* next character from/to here in buffer */
+ unsigned char *_base; /* the buffer */
+ unsigned char *_end; /* the end of the buffer */
+ ssize_t _cnt; /* number of available characters in buffer */
+ int _file; /* UNIX System file descriptor */
+ unsigned int _flag; /* the state of the stream */
+ char __fill[80]; /* filler to bring size to 128 bytes */
+} FILE64;
+# define READ_DATA_PENDING(fp) (((FILE64*)(fp))->_cnt > 0)
+# define READ_DATA_PENDING_COUNT(fp) (((FILE64*)(fp))->_cnt)
+# define READ_DATA_PENDING_PTR(fp) ((char *)((FILE64*)(fp))->_ptr)
#else
/* requires systems own version of the ReadDataPending() */
extern int ReadDataPending();
It's not very nice, but Solaris doesn't provide anything like
__fpending() for reads. Thankfully, they do now provide the Solaris
source, so we can get the struct from the internal header[1].
Without this patch, DRb tests hang forever, and many other tests
fail. With it:
% gmake check
test succeeded
[...]
1224 tests, 13482 assertions, 0 failures, 0 errors
(Yay!)
I get the same result using Sun C 5.6 2004/07/15 with
-xtarget=ultrasparc3cu -xarch=v9a and GCC 3.4.3 with -mcpu=ultrasparc3
-m64. This is Solaris 8/SPARC.
I also checked just READ_DATA_PENDING_COUNT against the regular
FILE_COUNT version for the 32-bit case using a simple C program.
Hopefully, this or something like it can find its way in. In the
meantime, please test this if you have access to Solaris!
Steve
[1] http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/inc/file64.h