Re: very odd behavior of Cygwin python from CMD

2007-03-03 Thread David Abrahams
Brian Dessent <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > >> Now, I am writing a program that must use CMD to probe for python in >> the PATH and check its version. If I do the naive thing and just try >> to invoke "python," and there's a Cygwin installation, my program will >> crash or

Re: javac?

2007-03-03 Thread Igor Peshansky
On Sun, 4 Mar 2007, Samuel Thibault wrote: > Igor Peshansky, le Sat 03 Mar 2007 19:06:43 -0500, a écrit : > > You might consider the Java wrappers in cygwin-apps: > > . > > But this is not provided as a cygwin package and doe

Re: [ANNOUNCEMENT] GCC doesn't create an executable

2007-03-03 Thread Bogus Bill
I have the same problem. I tried to compile the requisite "Hello, world!" program, but gcc didn't give any messages, nor generate any output. Here are the specifics: Code: #include using namespace std; int main (void) { cout << "Hello, world!"; return 0; } Compiler c

Re: very odd behavior of Cygwin python from CMD

2007-03-03 Thread Brian Dessent
David Abrahams wrote: > Now, I am writing a program that must use CMD to probe for python in > the PATH and check its version. If I do the naive thing and just try > to invoke "python," and there's a Cygwin installation, my program will > crash or freeze. So the question is, what do I do instead

Re: very odd behavior of Cygwin python from CMD

2007-03-03 Thread David Abrahams
David Abrahams <[EMAIL PROTECTED]> writes: > With c:\cygwin\bin in my PATH, if I open a CMD shell and invoke > > python > > I get some garbage characters on my console, and then it freezes. If > I instead do > > set USER=dave && python > > there are no garbage characters and no freeze, but a

Re: script problem

2007-03-03 Thread Lev Bishop
On 3/3/07, Gary R. Van Sickle wrote: > Does running fc-cache speed up your startup? > > Lev It hasn't bothered me enough to even look in to it frankly. My Cygwin interactive shell startup times have been a bit slower than normal for years because I have a bit of Perl/Cygpath magic in my bash_pr

Re: javac?

2007-03-03 Thread Samuel Thibault
Hi, Igor Peshansky, le Sat 03 Mar 2007 19:06:43 -0500, a écrit : > You might consider the Java wrappers in cygwin-apps: > . But this is not provided as a cygwin package and does point to cygwin programs. Isn't there a way t

Re: javac?

2007-03-03 Thread Igor Peshansky
On Sun, 4 Mar 2007, Samuel Thibault wrote: > Hi, > > Samuel Thibault, le Sun 04 Mar 2007 00:01:54 +0100, a écrit : > > Linux distributions usually provide a javac symlink pointing on gcj, > > which is handy for all these applications that assume that javac is the > > proper command for compiling j

Re: javac?

2007-03-03 Thread Samuel Thibault
Hi, Samuel Thibault, le Sun 04 Mar 2007 00:01:54 +0100, a écrit : > Linux distributions usually provide a javac symlink pointing on gcj, > which is handy for all these applications that assume that javac is the > proper command for compiling java programs. > > Maybe cygwin should provide a javac

javac?

2007-03-03 Thread Samuel Thibault
Hi, Linux distributions usually provide a javac symlink pointing on gcj, which is handy for all these applications that assume that javac is the proper command for compiling java programs. Maybe cygwin should provide a javac symlink too? Samuel -- Unsubscribe info: http://cygwin.com/ml/#un

RE: script problem

2007-03-03 Thread Gary R. Van Sickle
> From: Lev Bishop > Sent: Saturday, March 03, 2007 2:42 PM > Subject: Re: script problem > > On 3/2/07, Gary R. Van Sickle wrote: > > The only downside to the switch that I've experienced is that my > > interactive shells take quite a bit longer to come up, but I think > > that may have somethi

emacs fatal error - called with threadlist_ix -1

2007-03-03 Thread Martin Sebor
I've observed the following message with the latest Cygwin running on Vista: 7 [sig] emacs 2476 C:\cygwin\bin\emacs.exe: *** fatal error - called with threadlist_ix -1 Both times emacs was idle and not being used when it happened, although there were other running processes on the system. I've

very odd behavior of Cygwin python from CMD

2007-03-03 Thread David Abrahams
With c:\cygwin\bin in my PATH, if I open a CMD shell and invoke python I get some garbage characters on my console, and then it freezes. If I instead do set USER=dave && python there are no garbage characters and no freeze, but also no python process. Can anyone explain this? Thanks,

Re: script problem

2007-03-03 Thread Lev Bishop
On 3/2/07, Gary R. Van Sickle wrote: The only downside to the switch that I've experienced is that my interactive shells take quite a bit longer to come up, but I think that may have something to do with my setup rather than something intrinsic to the rxvt-unicode+Xserver setup. My usage pattern

Re: missing definition of __STRING macro in standard cygwin headers

2007-03-03 Thread Pedro Alves
Brian Dessent wrote: Pedro Alves wrote: It wouldn't work. #define __STRING #x != #define __STRING(x) #x I am just quoting what the OP said, which was: What the web link basically says that cygwin doesn't have #define __STRING #x defined in any of the standard header files which means some

Re: missing definition of __STRING macro in standard cygwin headers

2007-03-03 Thread Brian Dessent
Pedro Alves wrote: > It wouldn't work. > #define __STRING #x != #define __STRING(x) #x I am just quoting what the OP said, which was: > What the web link basically says that cygwin doesn't have > #define __STRING #x > defined in any of the standard header files which means some source code I h

Re: missing definition of __STRING macro in standard cygwin headers

2007-03-03 Thread Pedro Alves
Brian Dessent wrote: Eric Blake wrote: Not to mention the fact that it's incredibly silly to rely on libc headers to define something as trivial as the stringify operator which is a standard part of the C language. Does it also require __COMMENTBEGIN to be defined as /*? __BRACEBEGIN as {? Why

Re: missing definition of __STRING macro in standard cygwin headers

2007-03-03 Thread Brian Dessent
Eric Blake wrote: > Then that's a bug in FAAC. Using any identifier in the __ namespace is > admitting that your code is relying on implementation details, and it > deserves to break when ported to a different implementation. > > That said, submit a patch, and it will probably be applied, since

Re: Ambiguous error from ./configure

2007-03-03 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Forrest Aldrich on 3/2/2007 11:11 AM: > Here is the output from cygcheck. We ask for cygcheck output _as an attachment_ for a reason - so that the mailing list archive search engine won't get false positives on the body of your mail. And

Re: missing definition of __STRING macro in standard cygwin headers

2007-03-03 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jaakko Pääkkönen on 3/3/2007 3:08 AM: > Hi > Shouldn't this be fixed in cygwin headers? > http://www.audiocoding.com/modules/newbb/viewtopic.php?topic_id=448&forum=3 > > What the web link basically says that cygwin doesn't have > #defin

Re: missing definition of __STRING macro in standard cygwin headers

2007-03-03 Thread Christopher Faylor
On Sat, Mar 03, 2007 at 12:08:50PM +0200, Jaakko P??kk?nen wrote: >...cygwin doesn't have >#define __STRING #x >defined in any of the standard header files which means some source code >won't compile out of the box (FAAC library in this case). Hacking up all the >software by inserting that bit int

missing definition of __STRING macro in standard cygwin headers

2007-03-03 Thread Jaakko Pääkkönen
Hi Shouldn't this be fixed in cygwin headers? http://www.audiocoding.com/modules/newbb/viewtopic.php?topic_id=448&forum=3 What the web link basically says that cygwin doesn't have #define __STRING #x defined in any of the standard header files which means some source code won't compile out of th

Re: One happy screen user

2007-03-03 Thread Andrew Schulman
> I am using the screen test package Andrew Schulman mentioned here some 2 > weeks ago. And so far it works great for me. > http://cygwin.com/ml/cygwin/2007-02/msg00446.html > > Andrew, thanks for your work. Again, I'm not experiencing any problems > with this build. Please consider trying to m