[#4076] Ruby/DL — Jamis Buck <jamis_buck@...>

I recently used Ruby/DL to create bindings to the SQLite3 embedded

40 messages 2005/01/03
[#4096] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/04

On Tue, Jan 04, 2005 at 02:53:49AM +0900, Jamis Buck wrote:

[#4099] Re: Ruby/DL — ts <decoux@...> 2005/01/04

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4119] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Wed, Jan 05, 2005 at 03:05:48AM +0900, ts wrote:

[#4120] Re: Ruby/DL — ts <decoux@...> 2005/01/05

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4125] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Thu, Jan 06, 2005 at 01:10:34AM +0900, ts wrote:

[#4116] Test::Unit::Collector::Dir won't work with code that modifies $LOAD_PATH — Eric Hodel <drbrain@...7.net>

Any test code that depends upon modifications of $: fails when used

10 messages 2005/01/05

[#4146] The face of Unicode support in the future — Charles O Nutter <headius@...>

Hello Rubyists!

47 messages 2005/01/06
[#4152] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/07

Hi,

[#4167] Re: The face of Unicode support in the future — Christian Neukirchen <chneukirchen@...> 2005/01/09

Yukihiro Matsumoto <matz@ruby-lang.org> writes:

[#4175] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/10

Hi,

[#4186] Re: The face of Unicode support in the future — Paul Brannan <pbrannan@...> 2005/01/11

On Mon, Jan 10, 2005 at 11:53:48PM +0900, Yukihiro Matsumoto wrote:

[#4192] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/12

Hi,

[#4269] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...>

19 messages 2005/01/18
[#4270] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/18

Hi,

[#4275] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...> 2005/01/19

[#4323] test/unit doesn't rescue a Exception — Tanaka Akira <akr@...17n.org>

test/unit doesn't rescue a Exception in a test method, as follows.

14 messages 2005/01/27
[#8773] Re: test/unit doesn't rescue a Exception — Tanaka Akira <akr@...> 2006/09/02

In article <87is5jb46q.fsf@serein.a02.aist.go.jp>,

[#8776] Re: test/unit doesn't rescue a Exception — "Nathaniel Talbott" <ntalbott@...> 2006/09/03

On 9/1/06, Tanaka Akira <akr@fsij.org> wrote:

[#8777] Re: test/unit doesn't rescue a Exception — Eric Hodel <drbrain@...7.net> 2006/09/03

On Sep 2, 2006, at 6:34 PM, Nathaniel Talbott wrote:

Re: [BUG] Win32: rb_sys_fail() - errno == 0

From: "Berger, Daniel" <Daniel.Berger@...>
Date: 2005-01-05 20:11:36 UTC
List: ruby-core #4123
> -----Original Message-----
> From: Paul Brannan [mailto:pbrannan@atdesk.com] 
> Sent: Wednesday, January 05, 2005 8:53 AM
> To: ruby-core@ruby-lang.org
> Subject: Re: [BUG] Win32: rb_sys_fail() - errno == 0
> 
> 
> On Thu, Jan 06, 2005 at 12:34:27AM +0900, Berger, Daniel wrote:
> > I'm not sure I follow, because this has worked as expected 
> in certain 
> > circumstances in the past (i.e. it raised Errno::ENOENT).
> > 
> > Perhaps I need more detail on how rb_sys_fail() actually works.
> 
> Perhaps you need an abstraction like this one (from
> http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/OS_NS_errno.inl):
> 
>   ACE_INLINE int
>   ACE_OS::last_error (void)
>   {
>     // ACE_OS_TRACE ("ACE_OS::last_error");
> 
>   #if defined (ACE_WIN32)
>     // ACE_OS::last_error() prefers errnor since started out 
> as a way to
>     // avoid directly accessing errno in ACE code - 
> particularly the ACE
>     // C++ socket wrapper facades.  On Windows, some things that would
>     // use errno on UNIX require ::GetLastError(), so this 
> method tries
>     // to shield the rest of ACE from having to know about this.
>     int lerror = ::GetLastError ();
>     int lerrno = errno;
>     return lerrno == 0 ? lerror : lerrno;
>   #else
>     return errno;
>   #endif /* ACE_WIN32 */
> 
> Or perhaps rb_sys_fail() should do this behind the scenes.

Thanks for this Paul - I'll take a look.
 
> > That, or I need to figure out a way to explicitly raise 
> Errno::ENOENT 
> > within a C extension.
> 
> The easiest way is to set errno to ENOENT before calling 
> rb_sys_fail().

Actually, I couldn't figure out how to do that.  Or is errno an external
int that I can just set without having to declare?

Regards,

Dan


In This Thread

Prev Next