[#3907] Obtaining mode information on an IO object — Jos Backus <jos@...>

The attached patch implements IO#mode. This method returns the mode the IO

17 messages 2004/12/06
[#3909] Re: [patch] Obtaining mode information on an IO object — nobu.nokada@... 2004/12/07

Hi,

[#3910] Re: [patch] Obtaining mode information on an IO object — Jos Backus <jos@...> 2004/12/07

On Tue, Dec 07, 2004 at 09:25:13AM +0900, nobu.nokada@softhome.net wrote:

[#3925] Re: [patch] Obtaining mode information on an IO object — James Britt <ruby@...> 2004/12/09

Jos Backus wrote:

[#4009] cgi.rb -- more GET/POST stuff — mde@...26.com

First of all, I think it would be great, as Eustaquio suggests, to

17 messages 2004/12/23
[#4016] Re: [PATCH] cgi.rb -- more GET/POST stuff — Francis Hwang <sera@...> 2004/12/24

GETs and POSTs are defined to be fairly different actions. I'd read

[#4027] Allowing custom number literal suffixes? — Florian Gro<florgro@...>

Moin!

35 messages 2004/12/27
[#4070] Re: Allowing custom number literal suffixes? — nobu.nokada@... 2005/01/02

Hi,

[#4072] Re: Allowing custom number literal suffixes? — Mathieu Bouchard <matju@...> 2005/01/02

[#4079] Re: Allowing custom number literal suffixes? — Florian Gro<florgro@...> 2005/01/03

Mathieu Bouchard wrote:

[#4081] Re: Allowing custom number literal suffixes? — Mathieu Bouchard <matju@...> 2005/01/03

[#4082] Re: Allowing custom number literal suffixes? — Florian Gro<florgro@...> 2005/01/03

Mathieu Bouchard wrote:

[#4084] Re: Allowing custom number literal suffixes? — Brent Roman <brent@...> 2005/01/04

I'm not sure I would advocate making Ruby's grammar even more

[#4086] Re: Allowing custom number literal suffixes? — Mathieu Bouchard <matju@...> 2005/01/04

[#4033] Garbage collection trouble — Christian Neukirchen <chneukirchen@...>

Hello,

13 messages 2004/12/27

Re: mkmf enhancement for Win32

From: nobu.nokada@...
Date: 2004-12-11 00:32:42 UTC
List: ruby-core #3946
Hi,

At Sat, 11 Dec 2004 07:10:54 +0900,
Berger, Daniel wrote in [ruby-core:03944]:
> It turns out that some Win32 functions, such as AttachConsole(), are
> only conditionally available, and depend on the values of specific
> macros.
> 
> From
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog
> /winprog/using_the_windows_headers.asp
> 
> "Certain functions that depend on a particular version of Windows are
> declared using conditional code. This enables you to use the compiler to
> detect whether your application uses functions that are not supported on
> its target version(s) of Windows. To compile an application that uses
> these functions, you must define the appropriate macros. Otherwise, you
> will receive the C2065 error message."

It doesn't seem meaningful to check the compiling environment.
Rather you should check the target, the environment to run that
extension, no?

> This will be more of an issue when 64-bit Windows becomes more popular,
> though I am even hitting it currently with some of the Win32Utils
> extensions I've been working on.
> 
> Now, we could leave it up to individual extension authors to set this
> themselves manually, but that's a pain, and error prone (it's easy to
> forget, and some may not know to do it in the first place).  I thought
> it would be nice if mkmf would set it for us.  So, I submit the
> following patch for consideration:

I guess that developers who intend to restrict the target
should add such macros by themselves.

-- 
Nobu Nakada

In This Thread