[#7809] uninit bug in yaml/emitter.c — "Pat Eyler" <rubypate@...>
During our hacking night, we also looked at an UNINIT bug in yaml/emitter.c
[#7813] :!~ not a symbol — noreply@...
Bugs item #4344, was opened at 2006-05-03 17:41
[#7818] (security-related) patch to ALLOC macros to prevent integer overflow bugs — "Dominique Brezinski" <dominique.brezinski@...>
While fixing the integer overflow in rb_ary_fill(), it occurred to me
[#7833] segfault on Proc#call after setting a trace_func — Mauricio Fernandez <mfp@...>
$ cat bug2.rb
[#7843] Possible YAMl bug in 1.8.4 — Damphyr <damphyr@...>
OK, while parsing the td2 data from the ruby-lang website we stumbled on
Its probably a bug. I'm not familiar with the specifics, but Ruby
[#7858] Ruby threads working with native threads — "Francis Cianfrocca" <garbagecat10@...>
I recently wrote a network-event extension for Ruby ("eventmachine" in
[#7865] Strange interactions between Struct and 'pp' — noreply@...
Bugs item #4457, was opened at 2006-05-12 17:13
[#7872] Nonblocking socket-connect — "Francis Cianfrocca" <garbagecat10@...>
All, I needed a nonblocking socket connect for my asynchronous-event
In article <3a94cf510605140559l7baa0205le341dac4f47d424b@mail.gmail.com>,
How about introducing the method Socket#set_nonblocking, or alternatively
Hi,
Well, it's ok then. I'm comfortable adding in the nonblocking
Hi,
How about Socket#nbconnect and Socket#nbaccept?
On 5/15/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
In article <1147709691.180288.28647.nullmailer@x31.priv.netlab.jp>,
[#7881] Segfault on x86_64 when built with -O0 in CFLAGS — noreply@...
Bugs item #4491, was opened at 2006-05-16 12:46
[#7882] reproducible bug in DRb on OSX — cremes.devlist@...
I've been tearing my hair out the last few days trying to track down
[#7909] SCRIPT_LINES__ issue when loading a file more than once — Mauricio Fernandez <mfp@...>
SCRIPT_LINES__ is an obscure feature very few people care about, but I happen
On Fri, May 19, 2006 at 06:46:05PM +0900, Mauricio Fernandez wrote:
Hi,
[#7923] Nonblocking accept — "Francis Cianfrocca" <garbagecat10@...>
Thanks to the Matz and colleagues for adding the *_nonblock functions. They
[#7928] set_trace_func: binding has wrong self value for return events — =?ISO-8859-15?Q?Florian_Gro=DF?= <florgro@...>
Moin.
Florian Growrote:
Re: Nonblocking socket-connect
My opinion only, but when I see bang at the end of a method name, it makes me think that it will result in some possibly dangerous change to the object itself, rather than urgency. Earlier I proposed Socket#nbconnect and TCPServer#nbaccept and Socket#nbrecvfrom (I think these are ones that are most needed, the rest can be done with sysread and syswrite. Not sure yet about datagram sends.) This proposal has the advantage that it makes sense in English (read "nbaccept" as "nonblocking accept") but the potential disadvantage that the methods will bunch up together in alphabetical lists. Another possibility would be to add "nb" as a suffix: acceptnb, connectnb, etc. On 5/17/06, Vlad GALU <vladgalu@gmail.com> wrote: > > On 5/15/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote: > > How about Socket#nbconnect and Socket#nbaccept? > > I don't know the usual meaning of the exclamation mark, but I think > it would be nice to use it in order to separate blocking routines from > their non-blocking counterparts. Since usually the exclamation mark > suggests impatience, I thought that socket.connect! would be quite > appropriate to express the idea "connect now or else!", where "else" > may as well mean return with an error. The same thing would be nice > for other I/O routines too. > > My $0.02. Comments ? > > > > > > On 5/15/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote: > > > Hi, > > > > > > In message "Re: Nonblocking socket-connect" > > > on Tue, 16 May 2006 00:42:39 +0900, "Francis Cianfrocca" < > garbagecat10@gmail.com> writes: > > > > > > |Well, it's ok then. I'm comfortable adding in the nonblocking > > > |functions as an extension in my asynchronous-IO framework. If you > > > |decide it's best to leave nonblocking i/o out of the core, then > people > > > |will be able to get it if necessary through my "eventmachine" > library. > > > > > > Note that I'm not against for non-blocking connect. I just oppose to > > > general purpose non-blocking attribute for IO. Hint: name, name. > > > > > > matz. > > > > > > > > > > > > > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. > >