From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10205 invoked by alias); 9 Aug 2006 16:49:11 -0000 Received: (qmail 10193 invoked by uid 22791); 9 Aug 2006 16:49:10 -0000 X-Spam-Check-By: sourceware.org Received: from brmea-mail-3.Sun.COM (HELO brmea-mail-3.sun.com) (192.18.98.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Aug 2006 16:49:08 +0000 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k79Gn6DJ021632 for ; Wed, 9 Aug 2006 10:49:06 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J3Q00701PDRMY00@mail-amer.sun.com> (original mail from Nikolay.Molchanov@Sun.COM) for gdb@sourceware.org; Wed, 09 Aug 2006 10:49:06 -0600 (MDT) Received: from [172.16.1.35] ([69.106.253.60]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J3Q005DCPDUPQ3R@mail-amer.sun.com>; Wed, 09 Aug 2006 10:49:06 -0600 (MDT) Date: Wed, 09 Aug 2006 16:49:00 -0000 From: Nikolay Molchanov Subject: Re: Why gdb 6.5 prints fullname in /cygdrive/... format on Windows? In-reply-to: <44D99FBE.3070805@portugalmail.pt> To: Pedro Alves Cc: gdb@sourceware.org Reply-to: Nikolay.Molchanov@Sun.COM Message-id: <44DA11F8.9000301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <44D832EE.2040405@sun.com> <44D8E404.5050407@Sun.COM> <44D98D66.9060202@sun.com> <44D99FBE.3070805@portugalmail.pt> User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00072.txt.bz2 Pedro, >>> Eli Zaretskii wrote: >>> In general, if you want to avoid such problems, you should be using a >>> coherent set of tools. Which in practice means that a Cygwin build >>> of GDB should be used with Cygwin front ends and other programs. If >>> your front end cannot be built with Cygwin, you might consider using >>> the MinGW GCC and GDB instead, which are native Windows executables >>> and understand Windows-style d:/foo file names. >>> >>> >> Yes, we will try to support these compilers as well in future, but >> our primary >> target is to provide a free open source IDE for java and C/C++ >> developers, >> and this IDE shall work with Cygwin compilers on Windows, and with many >> other compilers on Linux, Windows and Solaris. This IDE is based on >> Netbeans >> (http://netbeans.org), which is a Java application, and it is very >> inconvenient to >> translate file names from Cygwin format to Windows format in Java code. >> For gdb it takes a few microseconds to translate a file name. We have to >> spend 250-400 milliseconds to execute external binary "cygpath -m ..." >> and to get translated name from its output. We can try to cache the >> directory names, but it is not correct in general case because mount >> points can be changed, and there is no way to notice such change >> from Java application. So, if it is possible to provide an option to >> print fullname in Windows format, we will very much appreciate it. >> > > Hummm, how about?: > You could avoid the external executable loading time everytime you > want to convert a path, by keeping one "cygpath -m -f -" loaded, and > feeding it the pathnames to stdin / getting result from stdout. > Thank you, I'll try this solution. In general we are trying to balance between complexity and performance in such cases :-) Dialog seems to be a more complicated solution, because we don't know what delays can be there, and what to do in case of timeout (restart cygpath? what if it hangs again?). Also dialog is async, which means we need several threads to "talk" (at least 2 threads for stdin and stdout, and probably one more for stderr). BTW, thank you for the suggestion to use "cygpath -m /..." to translate file names! I already implemented it, and it works just fine (though the delays are really visible :-) Thanks, Nik