[#9382] the sign of a number is omitted when squaring it. -2**2 vs (-2)**2 — <noreply@...>

Bugs item #6468, was opened at 2006-11-03 17:25

9 messages 2006/11/03

[#9385] merge YARV into Ruby — SASADA Koichi <ko1@...>

Hi,

42 messages 2006/11/04
[#9405] Re: merge YARV into Ruby — "Kirill Shutemov" <k.shutemov@...> 2006/11/06

On 11/4/06, SASADA Koichi <ko1@atdot.net> wrote:

[#9406] Re: merge YARV into Ruby — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2006/11/06

On Monday 06 November 2006 16:01, Kirill Shutemov wrote:

[#9417] Re: merge YARV into Ruby — Sean Russell <ser@...> 2006/11/06

On Monday 06 November 2006 10:15, Sylvain Joyeux wrote:

[#9428] Re: merge YARV into Ruby — "Kirill Shutemov" <k.shutemov@...> 2006/11/06

On 11/6/06, Sean Russell <ser@germane-software.com> wrote:

[#9402] fast mutexes for 1.8? — MenTaLguY <mental@...>

Many people have been using Thread.critical for locking because Ruby

24 messages 2006/11/06

[#9450] Bikeshed: No more Symbol < String? — Kornelius Kalnbach <murphy@...>

Hi ruby-core!

21 messages 2006/11/07
[#9452] Re: Bikeshed: No more Symbol < String? — Yukihiro Matsumoto <matz@...> 2006/11/07

Hi,

[#9493] Future Plans for Ruby 1.8 Series — URABE Shyouhei <shyouhei@...>

This week Japanese rubyists were talking about the future of ruby_1_8

13 messages 2006/11/09

[#9515] External entropy pool for random number generator — "Kirill Shutemov" <k.shutemov@...>

In the attachment patch which allow to use external entropy pool for

13 messages 2006/11/11
[#9522] Re: External entropy pool for random number generator — "Nobuyoshi Nakada" <nobu@...> 2006/11/13

Hi,

[#9554] Ruby 1.[89].\d+ and beyond. — Hugh Sasse <hgs@...>

I've been thinking about how version numbers are restricting what we can do.

30 messages 2006/11/16
[#9561] Re: Ruby 1.[89].\d+ and beyond. — Eric Hodel <drbrain@...7.net> 2006/11/16

[#9563] Re: Ruby 1.[89].\d+ and beyond. — Hugh Sasse <hgs@...> 2006/11/16

On Fri, 17 Nov 2006, Eric Hodel wrote:

[#9564] Re: Ruby 1.[89].\d+ and beyond. — Eric Hodel <drbrain@...7.net> 2006/11/16

On Nov 16, 2006, at 12:02 PM, Hugh Sasse wrote:

[#9571] Re: Ruby 1.[89].\d+ and beyond. — "Robert Dober" <robert.dober@...> 2006/11/19

On 11/16/06, Eric Hodel <drbrain@segment7.net> wrote:

[#9604] #ancestors never includes the singleton class (inconsistent) — <noreply@...>

Bugs item #6820, was opened at 2006-11-22 08:49

12 messages 2006/11/22
[#9618] Re: [ ruby-Bugs-6820 ] #ancestors never includes the singleton class (inconsistent) — Yukihiro Matsumoto <matz@...> 2006/11/25

Hi,

[#9629] Re: [ ruby-Bugs-6820 ] #ancestors never includes the singleton class (inconsistent) — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2006/11/27

> It is supposed to. Singleton classes (or eigenclasses, if you want to

Re: io_write (io.c) bug (and its fix) under MS Windows for GUI apps (rubyw)

From: "Mounir Idrassi" <idrassi@...>
Date: 2006-11-20 05:03:23 UTC
List: ruby-core #9577
Hi Dominic,
For the #ifdef of the if statement, it was the simplest way to achieve
my goal without modifying much of the code but it can be written
differently with a more elegant style.
For the GetConsoleTitle function,  if the title is bigger than 127, it
will return 0 and GetLastError will return ERROR_SUCCESS as
documented: this case is treated in my implementation as you can see.
Actually, one could replace 128 with any value(e.g. 1).

Concerning the empty title case, you are right: it will return 0 ,
yielding to a false negative detection. This would affect only
ruby.exe in case it's launched as a child process that shares the
console of its father and the father sets the console title to an
empty string ... this is an extremely rare case.

I've tried before using the GetStdHandle function as you mentioned :
when debugging it returns NULL as expected but when I start rubyw.exe
from a batch file or using a windows link it returns a fixed value
0x00010001 and writing to stdio continues to fail. This behavior is
not documented at all so I decided to look for another way to detect
the existence of a console.

I'm sure someone can come-up with a better implementation of the
"ProcessHasConsole" function. Meanwhile, the one I supplied works fine
for all the practical use-cases I'm aware of.

Cheers,

Mounir IDRASSI
IDRIX
web: http://www.idrix.fr


On 11/20/06, Dominic Cooney <dominic.cooney@gmail.com> wrote:
> Is it good style to #ifdef the if statement guard?
>
> Does ProcessHasConsole return the right value when:
>
> (a) The console's title is more than 127 characters? MSDN says "total
> size of the buffer required will be less than 64K."
>
> (b) When the console's title is blank? MSDN says "If the function
> succeeds, the return value is the length of the string copied to the
> buffer, in characters. If the buffer is not large enough to store the
> title, the return value is zero and GetLastError returns
> ERROR_SUCCESS." Does that mean empty string => \0 => return value 1?
> Have you tried it out?
>
> I think a better bet would be:
>
> if (GetStdHandle(STD_OUTPUT_HANDLE)) // or STD_ERROR_HANDLE, as appropriate
>
> would be safer. You might want to test for INVALID_HANDLE_VALUE as well as NULL.
>
> Dominic Cooney
>
> On 11/19/06, Mounir Idrassi <idrassi@gmail.com> wrote:
> > Hi all,
> > I recently encountered a problem under MS Windows where a GUI
> > application that runs correctly with ruby.exe refused to start with
> > rubuw.exe (1.8.5 version). After some digging I found that the problem
> > came from the function io_write in io.c : rb_sys_fail was called after
> > receiving -1 from io_fwrite. Actually, the ruby interpreter wanted to
> > print some warning to "rb_stderr" and because its a GUI application
> > with no console attached to it the C runtime returned -1. If I use
> > ruby.exe instead, the warnings are printed correctly.
> > To correct this behavior, it's sufficient to test if we have a console
> > attached to the current process and in case no one is found, we don't
> > call rb_sys_fail if the target stream is either rb_stderr ou
> > rb_stdout.
> > I made the following modifications to implement this :
> >
> >     - Add a function named "ProcessHasConsole" in case we are
> > compiling for MS Windows that returns TRUE if a console is attached to
> > the current process and FALSE otherwise. You can find its body at the
> > end of this email.
> >
> >     - In "io_write" body, replace the statement "if (n == -1)
> > rb_sys_fail(fptr->path);" with the following :
> >                if (n == -1)
> >                {
> >                   #ifdef _WIN32
> >                   if( (io != rb_stderr && io != rb_stdout) ||
> > ProcessHasConsole())
> >                   #endif
> >                   rb_sys_fail(fptr->path);
> >                }
> >
> > I hope this can help Windows users of ruby that were affected by the
> > same problem as me.
> > Is there any specific protocol for submitting patches?
> >
> > Cheers,
> >
> > Mounir IDRASSI
> > IDRIX
> > web: http://www.idrix.fr
> >
> > PS: body of the function  "ProcessHasConsole" :
> >
> > #ifdef _WIN32
> > static BOOL ProcessHasConsole()
> > {
> >        TCHAR szTitle[128];
> >        if(GetConsoleTitle(szTitle,128) || GetLastError() == ERROR_SUCCESS)
> >                 return TRUE;
> >        else
> >                 return FALSE;
> > }
> > #endif
> >
> >
>
>

In This Thread