[#3266] 1.8.2 preview bug? — Chad Fowler <chad@...>
I haven't had time to really investigate this, but I've boiled it down
6 messages
2004/08/10
[#3269] YAML problem, possibly? — Hugh Sasse Staff Elec Eng <hgs@...>
I obtained a largish lump of shallow XML, succcessfully read it with
6 messages
2004/08/10
[#3292] dir.c --- Dir.chdir error handling — Johan Holmberg <holmberg@...>
55 messages
2004/08/21
[#3350] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/06
Hi, Johan,
[#3351] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/06
Hello.
[#3352] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/06
Hi,
[#3353] Re: [PATCH] dir.c --- Dir.chdir error handling
— nobu.nokada@...
2004/09/06
Hi,
[#3354] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/06
Hi,
[#3356] Re: [PATCH] dir.c --- Dir.chdir error handling
— nobu.nokada@...
2004/09/07
Hi,
[#3369] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/09
Sorry for late posting. Typhoon striked me.....
[#3372] Re: [PATCH] dir.c --- Dir.chdir error handling
— nobu.nokada@...
2004/09/10
Hi,
[#3374] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/10
[#3376] Re: [PATCH] dir.c --- Dir.chdir error handling
— nobu.nokada@...
2004/09/10
Hi,
[#3378] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/11
nobu.nokada@softhome.net wrote:
[#3383] Re: [PATCH] dir.c --- Dir.chdir error handling
— nobu.nokada@...
2004/09/12
Hi,
[#3384] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/13
[#3385] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/13
Hi,
[#3386] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/13
[#3387] Re: [PATCH] dir.c --- Dir.chdir error handling
— ts <decoux@...>
2004/09/13
>>>>> "H" == H Yamamoto <ocean@m2.ccsnet.ne.jp> writes:
[#3392] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/14
[#3393] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/14
Hi,
[#3394] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/14
[#3395] Re: [PATCH] dir.c --- Dir.chdir error handling
— ts <decoux@...>
2004/09/14
>>>>> "H" == H Yamamoto <ocean@m2.ccsnet.ne.jp> writes:
[#3399] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/15
[#3403] Re: [PATCH] dir.c --- Dir.chdir error handling
— ts <decoux@...>
2004/09/15
>>>>> "H" == H Yamamoto <ocean@m2.ccsnet.ne.jp> writes:
[#3404] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/15
Hi,
[#3405] Re: [PATCH] dir.c --- Dir.chdir error handling
— ts <decoux@...>
2004/09/15
>>>>> "Y" == Yukihiro Matsumoto <matz@ruby-lang.org> writes:
[#3409] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/16
Hi,
[#3416] Re: [PATCH] dir.c --- Dir.chdir error handling
— ts <decoux@...>
2004/09/16
>>>>> "Y" == Yukihiro Matsumoto <matz@ruby-lang.org> writes:
[#3435] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/17
Hi,
[#3436] Re: [PATCH] dir.c --- Dir.chdir error handling
— ts <decoux@...>
2004/09/17
>>>>> "Y" == Yukihiro Matsumoto <matz@ruby-lang.org> writes:
[#3438] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/17
Hi,
[#3441] European Rubykonf 2004
— Mathieu Bouchard <matju@...>
2004/09/17
[#3402] Re: [PATCH] dir.c --- Dir.chdir error handling
— Yukihiro Matsumoto <matz@...>
2004/09/15
Hi,
[#3410] Re: [PATCH] dir.c --- Dir.chdir error handling
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/09/16
[#3293] 1.8.1 gsub/CGI behavior I can't explain — "David A. Black" <dblack@...>
Hi --
8 messages
2004/08/22
[#3301] Is Ruby 1.8.2 100% Backward compatible — Lothar Scholz <mailinglists@...>
Hello,
6 messages
2004/08/25
[#3345] Re: Is Ruby 1.8.2 100% Backward compatible
— Johan Holmberg <holmberg@...>
2004/09/03
[#3303] URGENT: what's the bug reporting system now? — Dave Thomas <dave@...>
Hello!
14 messages
2004/08/25
[#3304] Re: URGENT: what's the bug reporting system now?
— matz@... (Yukihiro Matsumoto)
2004/08/25
Hi,
[#3306] Re: URGENT: what's the bug reporting system now?
— Daniel Berger <djberg96@...>
2004/08/26
[#3315] Pretty Printing more widely — Hugh Sasse Staff Elec Eng <hgs@...>
May I propose the following patch (done against the 1.9.0 nightly
8 messages
2004/08/26
[#3331] "destructiveness" of delete — "David A. Black" <dblack@...>
Hi --
6 messages
2004/08/31
Re: Ruby is eating my signals!
From:
Eric Schwartz <eric.schwartz@...>
Date:
2004-08-31 18:17:21 UTC
List:
ruby-core #3332
I don't mean to be pushy, but this is causing me some fairly sizable pain at the moment; does anyone have an idea as to how I can fix my extension (or alternatively, how to force Ruby to deliver a signal it's currently deferring)? Thanks, -=Eric On Wed, 2004-08-25 at 13:11, Eric Schwartz wrote: > I posted this to comp.lang.ruby, but got no replies. Perhaps it's more > appropriate here. > > I've built a Ruby extension for STAF (<URL:http://staf.sf.net/>) that is > mostly working well. However, sometimes the STAF query goes off into > the weeds. I want to set up a timeout that sends a SIGALRM to the main > process, but that SIGALRM is not getting propogated to my Ruby program. > The interpreter is receiving the signal, but isn't passing it along. > > I instrumented signal.c, and what I've found is that sighandler is being > called for the SIGALRM. In it, rb_trap_immediate is NOT set, so > rb_trap_pending is incremented, and the SIGALRM entry in trap_pending > list is incremented. So far so good-- it appears this is Ruby's way of > deferring handling of signals until it's safe to handle them. > > The problem is, this signal is never getting handled. And, well, kinda > the point of a SIGALRM is that it gets sent in a reasonably timely > manner. :) I've noticed this behaviour seems to exist with every > signal, though, except SIGSTOP and SIGKILL (for obvious reasons). > > Is there something I'm doing wrong in my STAF extension? (You can get > source at http://sourceforge.net/tracker/?group_id=33142&atid=407383 if > you want to double-check me.) Is there some way to force Ruby to > deliver this signal? How can I tell why it's not being delivered? > > Thanks for any help, > > -=Eric -- Eric Schwartz <eric.schwartz@hp.com> Hewlett-Packard Company Linux/Open Source Labs (LOSL)