Re: cygserver not starting on 20050610 snapshot
On Fri, Jun 10, 2005 at 09:33:51AM -0700, Yitzchak Scott-Thoennes wrote: > I'm not able to get cygserver running on the 20050610 snapshot. This may > have been the case with earlier snapshots too. All better on 20050611. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 3.4.4 optimization problem (was Re: Negative stats from rsync with 20050610 snapshot)
On Jun 11 16:37, Christopher Faylor wrote: > On Sat, Jun 11, 2005 at 02:33:32PM -0400, Christopher Faylor wrote: > >I did a little more debugging on this and it seems like, in this case at > >least, the problem is that the newlib code is wrong. Compiling it with > >-Wstrict-aliasing revealed a problem. Correcting the strict aliasing problem > >seems to make rsync work better. There are also two other strict error > >warnings in newlib which I'll fix. > > I've generated a new snapshot which seems to fix these problems and I've > sent the patches to the newlib mailing list: > > http://cygwin.com/ml/newlib/2005/msg00334.html FWIW, it also works fine without your patch when building newlib with gcc-4.0.1. Oh well... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 3.4.4 optimization problem (was Re: Negative stats from rsync with 20050610 snapshot)
On Jun 11 18:53, Gerrit P. Haase wrote: > Corinna Vinschen wrote: > >Otherwise, do you know by any chance, if there exists some fix for that > >problem? The above kludge is almost a year old, so there's a chance > >that somebody already found the fix. > > Where we had a problem was with -fschedule-insns2 > (flag_schedule_insns_after_reload): Oh, right. > Regarding unit-at-a-time I cannot remember right now if there was > discussion, there are known issues with this option, anyway I will > apply your kludge since I have not much time, I'm on a business trip > the next two weeks. I'm wondering if we should do that or not. I'm not a gcc person, so I'm not exactly the right one to make such a decision. It's just interesting that the strict-aliasing problem Chris found, is no problem in gcc 4 anymore, apparently. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin's symlinks and cifs mounts
On Jun 12 01:10, Samuel Thibault wrote: > Hi, > > We here have a cifs network share on server LVSMB that is mounted on S:\ > on clients. Could cygwin running on clients see symlinks from unix > extensions of this cifs share and ln -s build real symlinks on the > server? (rather than building windows shortcuts or magic cygwin > symlink). No. The fact that symlinks are real symlinks on some Samba share is hidden to a Windows client. There's no such thing as a SMB protocol to create and read symlinks. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ri dumps core
On Jun 11 12:42, Jason Tishler wrote: > On Fri, Jun 10, 2005 at 11:04:22PM -0700, Brian Dessent wrote: > > Steve Kelem wrote: > > > Okay. I ran rebase. Then I get the same problem. > > > > I just noticed that ruby uses .so for the name of its dynamic modules, > > but I think the rebaseall script only looks for .dll. Make a list of > > all the .so files in the ruby package and pass that to rebaseall with > > the -T flag, or modify the rebaseall script to look for files ending > > in .so. I think this could be a bug in the rebaseall script. > > Do others agree? If so, then I will change rebaseall to look for .so > files too. Any other extensions besides .so? I agree and *.so is the only other extension, AFAICS. The next OpenSSL version will bring them, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 3.4.4 optimization problem (was Re: Negative stats from rsync with 20050610 snapshot)
Corinna Vinschen wrote: On Jun 11 18:53, Gerrit P. Haase wrote: Corinna Vinschen wrote: Otherwise, do you know by any chance, if there exists some fix for that problem? The above kludge is almost a year old, so there's a chance that somebody already found the fix. Where we had a problem was with -fschedule-insns2 (flag_schedule_insns_after_reload): Oh, right. Regarding unit-at-a-time I cannot remember right now if there was discussion, there are known issues with this option, anyway I will apply your kludge since I have not much time, I'm on a business trip the next two weeks. I'm wondering if we should do that or not. I'm not a gcc person, so I'm not exactly the right one to make such a decision. It's just interesting that the strict-aliasing problem Chris found, is no problem in gcc 4 anymore, apparently. I just turn off defaulting to unit-at-a-time when you specify -O2. You may always specify -funit-at-a-time to see if code compiles ok with this flag. According to the introduction of the 3.4.4 optimization docs, this flag is optional anyway: "Using the -funit-at-a-time flag will allow the compiler to consider information gained from later functions in the file when compiling a function. Compiling multiple files at once to a single output file (and using -funit-at-a-time) will allow the compiler to use information gained from all of the files when compiling each of them." Where in 4.0.0 is explictly stated even in the introduction that it is defaulty for -O2 and above: "The compiler performs optimization based on the knowledge it has of the program. Optimization levels -O2 and above, in particular, enable unit-at-a-time mode, which allows the compiler to consider information gained from later functions in the file when compiling a function. Compiling multiple files at once to a single output file in unit-at-a-time mode allows the compiler to use information gained from all of the files when compiling each of them." Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SSH and session master multiplexing
On Jun 12 10:37, ne wrote: > Im having some issues with the latest version of OpenSSH released for cygwin > (under WinXP SP2). > > I am trying to connect to ssh.sf.net with a master connection that is > shared. I am using: > >ssh -vv -l user -M -S ~/.ssh/sf-mux ssh.sf.net > To create the master, then: > >ssh -l user-vv -S ~/.ssh/sf-mux ssh.sf.net > > to create a client. I am using keys for the authentication, but have tried > passwords too. > > When I try to create a client, in the master session I get: > > debug1: fd 8 clearing O_NONBLOCK > debug2: client_process_control: accepted tty 1, subsys 0, cmd > debug2: client_process_control: got fds stdin 4257601, stdout 4257601, > stderr 4257601 > client_process_control: tcgetattr: Bad file descriptor > fcntl(4257601, F_GETFL, 0): Bad file descriptor > fcntl(4257601, F_GETFL, 0): Bad file descriptor > fcntl(4257601, F_GETFL, 0): Bad file descriptor > debug2: fd 8 setting O_NONBLOCK > debug1: channel 1: new [client-session] > debug2: channel 1: send open > Segmentation fault (core dumped) Ouch, yes, I see. There's nothing right now I can do to change this. Using a master/slave connection requires the ability to exchange file descriptors over AF_UNIX sockets. That's not possible in Cygwin. So the only help I can give is, don't use master/slave connections on Cygwin for now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 3.4.4 optimization problem (was Re: Negative stats from rsync with 20050610 snapshot)
On Jun 12 11:22, Gerrit P. Haase wrote: > Corinna Vinschen wrote: > >I'm wondering if we should do that or not. I'm not a gcc person, so I'm > >not exactly the right one to make such a decision. It's just interesting > >that the strict-aliasing problem Chris found, is no problem in gcc 4 > >anymore, apparently. > > I just turn off defaulting to unit-at-a-time when you specify -O2. > You may always specify -funit-at-a-time to see if code compiles ok > with this flag. > > According to the introduction of the 3.4.4 optimization docs, this > flag is optional anyway: > > "Using the -funit-at-a-time flag will allow the compiler to consider > information gained from later functions in the file when compiling a > function. Compiling multiple files at once to a single output file > (and using -funit-at-a-time) will allow the compiler to use > information gained from all of the files when compiling each of > them." > > Where in 4.0.0 is explictly stated even in the introduction that it is > defaulty for -O2 and above: > > "The compiler performs optimization based on the knowledge it has of the > program. Optimization levels -O2 and above, in particular, enable > unit-at-a-time mode, which allows the compiler to consider information > gained from later functions in the file when compiling a function. > Compiling multiple files at once to a single output file in > unit-at-a-time mode allows the compiler to use information gained from > all of the files when compiling each of them." I see. It seems the 3.4.x code is just assuming a bit too much when examining functions, whereas the 4.x implementation is a bit more careful. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SSH and session master multiplexing
"Corinna Vinschen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Jun 12 10:37, ne wrote: >> Im having some issues with the latest version of OpenSSH released for >> cygwin >> (under WinXP SP2). >> >> I am trying to connect to ssh.sf.net with a master connection that is >> shared. I am using: >> >ssh -vv -l user -M -S ~/.ssh/sf-mux ssh.sf.net >> To create the master, then: >> >ssh -l user-vv -S ~/.ssh/sf-mux ssh.sf.net >> >> to create a client. I am using keys for the authentication, but have >> tried >> passwords too. >> >> When I try to create a client, in the master session I get: >> >> debug1: fd 8 clearing O_NONBLOCK >> debug2: client_process_control: accepted tty 1, subsys 0, cmd >> debug2: client_process_control: got fds stdin 4257601, stdout 4257601, >> stderr 4257601 >> client_process_control: tcgetattr: Bad file descriptor >> fcntl(4257601, F_GETFL, 0): Bad file descriptor >> fcntl(4257601, F_GETFL, 0): Bad file descriptor >> fcntl(4257601, F_GETFL, 0): Bad file descriptor >> debug2: fd 8 setting O_NONBLOCK >> debug1: channel 1: new [client-session] >> debug2: channel 1: send open >> Segmentation fault (core dumped) > > Ouch, yes, I see. There's nothing right now I can do to change this. > Using a master/slave connection requires the ability to exchange file > descriptors over AF_UNIX sockets. That's not possible in Cygwin. > > So the only help I can give is, don't use master/slave connections on > Cygwin for now. > > > Corinna > Ok thanks, I thought that may be the case, a pity. I would have thought wanting a seamless-"pre-authenticated"-X11-forwarded connection to a unix box is something that would be highly desired and in common use under Cygwin, I guess not :( Unfortuantly the solaris machine I connect to doesn't use keys, is there something else I could do which would allow me to run *local* xterms/rxvt's to this box without having to type in the password everytime? (I realise I can start remote xterms fine, but the remote terms aren't as good :P ). Thanks, Shane -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SSH and session master multiplexing
On Jun 12 19:58, ne wrote: > Ok thanks, I thought that may be the case, a pity. I would have thought > wanting a seamless-"pre-authenticated"-X11-forwarded connection to a unix > box is something that would be highly desired and in common use under > Cygwin, I guess not :( Descriptor passing isn't that easy to implement if you don't want to have some additional background server running all the time. I don't want to make cygserver a requirement for descriptor passing, really. It's something I want to implement at one point, though. > Unfortuantly the solaris machine I connect to doesn't use keys, is there > something else I could do which would allow me to run *local* xterms/rxvt's > to this box without having to type in the password everytime? (I realise I > can start remote xterms fine, but the remote terms aren't as good :P ). ssh-agent Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] New package: xmon-1.5.6-1
The package 'xmon' is now available in the Cygwin distribution. Description === (from http://www.x.org/contrib/devel_tools/xmon.1.5.6.README) Xmon interactively monitors the byte-stream connections between an X server and a number of X clients. Xmon recognizes all requests, events, errors and replies sent between the clients and the server which are part of the core X protocol. The contents of these messages are displayed on standard output at a user settable degree of detail from none to every bit and byte. Xmon also allows the user to select a number of requests or events to be monitored at a different degree of detail. Xmon will also block the transmission of selected requests from the clients to the server and selected events from the server to the clients. Xmon also keeps statistics of the number of requests, events, and errors received. -- Harold Hunt *** To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. *** -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mcedit stackdumps
Hello, On Fri, 10 Jun 2005, Krzysztof Duleba wrote: > Hi > > For a few months now I've been suffering from mcedit internal error. Every > once in a while, without any reason, mcedit stackdumps during exit > procedure (after pressing F10 or double ESC). I got this error with > 1.5.16, then with 1.5.17 snapshots, and now with 1.5.17 as well. I haven't > tried current snapshots yet. Should I? > > Debugging mcedit seems pointless as stackdumps occur on a very irregular > basis. Can I provide any more information? Yes. What kind of file do you edit ? Is it a file for which there is a syntax highlighting ? Do you start mcedit alone or from withing MC i.e. pressing F4 ? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mcedit stackdumps
Pavel Tsekov wrote:
> > For a few months now I've been suffering from mcedit internal error.
> > Every once in a while, without any reason, mcedit stackdumps during
> > exit procedure (after pressing F10 or double ESC). I got this error
> > with 1.5.16, then with 1.5.17 snapshots, and now with 1.5.17 as
> > well. I haven't tried current snapshots yet. Should I?
> >
> > Debugging mcedit seems pointless as stackdumps occur on a very
> > irregular basis. Can I provide any more information?
>
> Yes. What kind of file do you edit ? Is it a file for which there is a
> syntax highlighting ?
mcedit stackdumps on C++ files with standard syntax highlighting, and also
on Apache access log (no highlighting).
> Do you start mcedit alone or from withing MC i.e.
> pressing F4 ?
The problem happens if I start mcedit from shell (mcedit somefile.cpp). I
don't remember seeing a stackdump if I called mcedit directly with
execl("/usr/bin/mc.exe", "/usr/bin/mcedit.exe", "somefile", NULL) and
usually I do it this way.
Regards
Krzysztof Duleba
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: mcedit stackdumps
Hello, On Fri, 10 Jun 2005, Krzysztof Duleba wrote: > For a few months now I've been suffering from mcedit internal error. Every > once in a while, without any reason, mcedit stackdumps during exit > procedure (after pressing F10 or double ESC). I got this error with > 1.5.16, then with 1.5.17 snapshots, and now with 1.5.17 as well. I haven't > tried current snapshots yet. Should I? I am pretty confident that I've found the cause for the crash. It is indeed a double free issue as Christopher Faylor suggested. I just want a confirmation from you if it is possible - does the crash happen only if you use the 'User Menu' (F11) in the editor. P.S. Thanks, Chris! :) The hint was valuable and is much appreciated ! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mcedit stackdumps
Pavel Tsekov wrote: > > For a few months now I've been suffering from mcedit internal error. Every > > once in a while, without any reason, mcedit stackdumps during exit > > procedure (after pressing F10 or double ESC). I got this error with > > 1.5.16, then with 1.5.17 snapshots, and now with 1.5.17 as well. I haven't > > tried current snapshots yet. Should I? > > I am pretty confident that I've found the cause for the crash. It is > indeed a double free issue as Christopher Faylor suggested. I just want a > confirmation from you if it is possible - does the crash happen only if > you use the 'User Menu' (F11) in the editor. No, I've never used User Menu before, even accidentally - I wasn't aware of it. Regards Krzysztof Duleba -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
Krzysztof Duleba wrote: > Christopher Faylor wrote: > > On Fri, Jun 10, 2005 at 06:13:31PM -0500, Gary R. Van Sickle wrote: > > >Configuring wxWindows from cvs, on a 3.4GHz P4: > > > > > >Sh = Ash: > > >real3m55.351s > > >user5m8.610s > > >sys 1m53.240s > > > > > >Sh = Bash: > > >real3m41.850s > > >user5m6.220s > > >sys 1m53.426s > > > > > >Looks like the time has come. > > > > Wow. I never expected that bash would actually be faster. > > > > I would appreciate getting a few more benchmarks for other packages. > > If this holds out then moving to bash is a no-brainer. > > Similar results here. Configuring on Athlon 2200 gives > > 1. octave 2.1.57: > sh = ash > real2m48.347s > user4m13.299s > sys 1m25.203s > > sh = bash > real2m38.129s > user4m11.777s > sys 1m23.915s > > 2. netcat 0.7.1 > sh = ash > real0m56.847s > user1m29.808s > sys 0m30.186s > > sh = bash > real0m57.015s > user1m28.878s > sys 0m29.338s > > 3. mc 4.6.1-pre4 > sh = ash > real2m13.248s > user3m31.685s > sys 1m9.772s > > sh = bash > real2m10.112s > user3m30.198s > sys 1m10.563s Are you sure you didn't actually measure bash's performance twice? If you simply run configure with ash, it will effectively do an exec /bin/bash "$0" "$@" at the beginning, unless you force it to stick with ash by setting CONFIG_SHELL=/bin/sh. FWIW, I did find that the configure scripts I tested ran faster under ash than under bash, but only by 4% to 8%. Regards Thorsten Dahlheimer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mcedit stackdumps
Hello, On Sun, 12 Jun 2005, Krzysztof Duleba wrote: > Pavel Tsekov wrote: > > > > For a few months now I've been suffering from mcedit internal error. > Every > > > once in a while, without any reason, mcedit stackdumps during exit > > > procedure (after pressing F10 or double ESC). I got this error with > > > 1.5.16, then with 1.5.17 snapshots, and now with 1.5.17 as well. I > haven't > > > tried current snapshots yet. Should I? > > > > I am pretty confident that I've found the cause for the crash. It is > > indeed a double free issue as Christopher Faylor suggested. I just want > a > > confirmation from you if it is possible - does the crash happen only if > > you use the 'User Menu' (F11) in the editor. > > No, I've never used User Menu before, even accidentally - I wasn't aware > of it. Well, maybe you've been pressing Ctrl + O then ? In any case - please try using the user menu and then quit to see if you'll manage to crash MC. Either Ctrl + O or a command from the User Menu (F11) should trigger the crash. Please, report back. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
Thorsten Dahlheimer wrote: > Are you sure you didn't actually measure bash's performance twice? Yes, you're right. I didn't set CONFIG_SHELL. I feel really stupid about it :-( I only copied bash to /bin/sh. At the moment my CPU load is high, so it's not the best time to run benchmarks, but MC configure results are similar. I'll rerun the full tests later. Thanks for pointing that out. Regards Krzysztof Duleba -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mcedit stackdumps
Pavel Tsekov wrote: > > > I am pretty confident that I've found the cause for the crash. It is > > > indeed a double free issue as Christopher Faylor suggested. I just want > > a > > > confirmation from you if it is possible - does the crash happen only if > > > you use the 'User Menu' (F11) in the editor. > > > > No, I've never used User Menu before, even accidentally - I wasn't aware > > of it. > > Well, maybe you've been pressing Ctrl + O then ? Yes, that's it! mcedit failes after F10 if I used Ctrl + O earlier. Sometimes it's not even a stackdump, but an infinite loop with 100% CPU usage. > In any case - please try > using the user menu and then quit to see if you'll manage to crash MC. > Either Ctrl + O or a command from the User Menu (F11) should trigger the > crash. Please, report back. F11 causes a crash as well. I've compiled MC-4.6.1-pre4 and tested it with this case. It crashes. I failed to crash the same version on a Linux box this way, though. Thanks for investigating it! Is there a cure? Please let me know if you find one. Regards Krzysztof Duleba -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 3.4.4 optimization problem (was Re: Negative stats from rsync with 20050610 snapshot)
On Sun, Jun 12, 2005 at 11:33:08AM +0200, Corinna Vinschen wrote: >I see. It seems the 3.4.x code is just assuming a bit too much when >examining functions, whereas the 4.x implementation is a bit more careful. AFAICT, the code was just plain wrong with gcc 3.4.4. However, I found a bug report where someone was reporting a similar problem and the reply was "Well, you had aliasing problems. What woudl you expect?" and, indeed, fixing the aliasing problems seemed to fix the code generation problem. It still is troubling that gcc 3.4.4 ended up using a completely wrong place on the stack for a variable (after changing a static function to an inline function). cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Multi Threaded programs deadlock doing simple I/O operations
On Friday, June 10, 2005 at 3:44 PM, Mark Pizzolato wrote: > On Thursday, June 09, 2005 at 6:12 PM, Mark Pizzolato wrote: >> On Thursday, June 09, 2005 at 3:35 PM, Christopher Faylor wrote: >> > On Wed, Jun 08, 2005 at 05:43:59PM -0700, Mark Pizzolato wrote: >> > >There is a serious problem for multi threaded programs doing simple >> > >I/O >> > >operations in cygwin (open, dup, fdopen, fclose, and close). >> > > >> > >The attached 81 line test program clearly demonstrates the issue (by >> > >hanging and no longer consuming CPU or performing any I/O >> > >operations). >> > >> > Thanks for the relatively small test case. That was enough to track >> > the >> > problem down. I'm generating a new snapshot with a fix for this >> > problem. >> >> The snapshot looks good! >> >> This fixes the stability problems with clamav's clamd that I've been >> chasing >> for a long time. > > Some more follow up here...I'm running with the 20050609 snapshot dll. > > clamav's clamd now runs better than it has ever for me on cygwin. > > until "it doesn't", > > once it starts to run poorly it won't run cleanly again until I reboot > the system > (I haven't actually tried after merely exiting all processes ..) Well, i spoke too soon here. There may be some interaction with many recently closed tcp sessions sitting in TIME_WAIT. I'm not sure, but after some time, I can restart and experience aparrently good behavior and then things get "poor" as described. If I run with the 20050607 snapshot, the new "poor" behavior doesn't happen, while the test program I provided earlier in this thread hangs as described. So, the fix to the original problem and the new "poor" behavior are clearly related to changes between the 20050607 and the 20050609 snapshots. > To be more specific about the "poor" behavior: > > > - pthread_unlock_mutex fails leaving errno with a value of 90. This is > in a place where there is only one path through about a dozen lines of > code and the mutex is definately locked. there may have been a call to > pthread_create, and a definate call to pthread_cond_signal. > - once the above error happens, calls (by the same thread) to accept() > fail using a file descriptor which we've been successfully using all > along and only close when the program exists. > > so some change introduced recently (since 1.5.17-1), and possibly in > 20050609 fixes the dup() issue but now mutex operations are failing in > strange ways. > > Sorry not to have a simple isolated test case for this. The good news > is that once it breaks it won't run correcfly again until a reboot. I'm working on a test program to recreate this behavior. - Mark Pizzolato -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Making /bin/sh == bash. Has the time come?
> Are you sure you didn't actually measure bash's performance twice? > If you simply run configure with ash, it will effectively do an > > exec /bin/bash "$0" "$@" > > at the beginning, unless you force it to stick with ash by > setting CONFIG_SHELL=/bin/sh. > > FWIW, I did find that the configure scripts I tested ran > faster under ash than under bash, but only by 4% to 8%. > > Regards > Thorsten Dahlheimer Wait... So everybody's *always* been using bash during configures? -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Making /bin/sh == bash. Has the time come?
Ok, I reran the wxWidgets configure test, taking Thorsten's CONFIG_SHELL tip into account this time: /bin/sh = ash = export CONFIG_SHELL=/bin/bash; time ./transfigure real3m21.888s user5m2.357s sys 1m38.022s export CONFIG_SHELL=/bin/sh; time ./transfigure real3m3.738s user5m1.330s sys 1m28.028s time ./transfigure (I.e., default CONFIG_SHELL, which is empty) real3m35.674s user5m5.728s sys 1m51.104s /bin/sh = bash = export CONFIG_SHELL=/bin/bash; time ./transfigure real3m35.286s user5m6.974s sys 1m50.462s export CONFIG_SHELL=/bin/sh; time ./transfigure real3m35.206s user5m5.343s sys 1m48.977s So: - "transfigure" is a dead-simple shell script that just calls ./configure with a slew of config options. - Everything's faster today (real anyway), probably due to the following: - I'm probably using a different snapshot. - I cvs updated my wxWidgets source just before running the tests. - In the previous tests I wasn't particularly careful to leave the machine alone (did some web browsing, email etc). This time I made sure to do nothing during the tests. - Percentage differences between configuring with bash vs. ash: real: ~+17% user: ~+1% system: ~+25% - Apparently the only way to get ash used at all is by explicitly "export CONFIG_SHELL=/bin/sh"ing. In particular note the third ash test, where /bin/sh is ash, and yet the configure times appear to indicate that bash is in fact being used. Ergo: - Yes, sh is still faster than bash. - It's not a large enough difference that I would care about it. Others' mileage may perhaps vary. - It's unclear to me that it matters in any case, since apparently configures have been using bash anyway. - It's unclear to me then where the "sh is ash not bash" issues are actually coming from, if not from run-of-the-mill configures. - If it isn't configures, does anybody actually care about the semi-minor slowdown since it would eliminate "ash != bash" issues? Hence: - I still say /bin/sh == bash is the way to go. QED. -- Gary R. Van Sickle > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gary R. Van Sickle > Sent: Friday, June 10, 2005 6:14 PM > To: cygwin@cygwin.com > Subject: RE: Making /bin/sh == bash. Has the time come? > > Configuring wxWindows from cvs, on a 3.4GHz P4: > > Sh = Ash: > real3m55.351s > user5m8.610s > sys 1m53.240s > > Sh = Bash: > real3m41.850s > user5m6.220s > sys 1m53.426s > > Looks like the time has come. > > -- > Gary R. Van Sickle > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor > > Sent: Friday, June 10, 2005 10:07 AM > > To: cygwin@cygwin.com > > Subject: Making /bin/sh == bash. Has the time come? > > > > A long time ago, in a Cygwin release prior to B20.1, someone > > made the decision to use "ash" as the standard /bin/sh for > > Cygwin. The sole reason for doing this was that ash was > > faster than bash. > > > > Later, at one point, I implemented a sorta-wannabe version of > > vfork, and commissioned one of the people who worked for me > > to modify ash to use vfork. This made ash even faster than > > it was before. > > > > Recently, after too many hours hacking at vfork corner cases, > > I came to the conclusion that getting vfork working correctly > > was too difficult so, I turned off vfork in cygwin and asked > > Corinna to modify ash to use /bin/sh again. > > > > So, that leaves us with an ash which is still faster. For example: > > > > e:\>time ash -c "i=0; while [ $i -lt 1000 ]; do i=$(expr $i > > + 1); done" > > 32.24user 9.72system 0:12.85elapsed 326%CPU > > (0avgtext+0avgdata 11677696maxresident)k > > 0inputs+0outputs (730699major+0minor)pagefaults 0swaps > > > > e:\>time bash -c "i=0; while [ $i -lt 1000 ]; do i=$(expr > > $i + 1); done" > > 49.86user 16.51system 0:23.04elapsed 288%CPU > > (0avgtext+0avgdata 20525056maxresident)k > > 0inputs+0outputs (1284873major+0minor)pagefaults 0swaps > > > > i.e., bash is twice as slow as ash. However: > > > > e:\>time bash -c "i=0; while [ $i -lt 1000 ]; do i=$(($i + > > 1)); done" > > 0.14user 0.01system 0:00.15elapsed 101%CPU > > (0avgtext+0avgdata 15712maxresident)k > > 0inputs+0outputs (982major+0minor)pagefaults 0swaps > > > > So, there are some constructs available in bash which, if you > > assume that bash == /bin/sh, will result in much faster shell > > script execution. > > > > And, anyone who reads this list regularly will know that we > > get a lot of complaints about the differences between bash > > and ash, which cause people to eventually copy bash to /bin/sh. > > > > So, in conversation with Corinna, I think that we're starting > > to lean towards making /bin/sh == bash sometime soon. We > > won't get rid of ash and will point to it when people send > > the
Re: Making /bin/sh == bash. Has the time come?
Christopher Faylor wrote: > Recently, after too many hours hacking at vfork corner cases, I came to > the conclusion that getting vfork working correctly was too difficult > so, I turned off vfork in cygwin and asked Corinna to modify ash to use > /bin/sh again. I assume that should read "modify ash to use fork() again." Can I just ask a basic question here? So if both ash and bash are using the same method of execution (fork), is the reason for bash's slowness due to it just being a larger program with more pages to copy during a fork()? And a related question: Would it make more sense to compile ash with all its builtins enabled, rather than switching to bash? It seems from the benchmarks that bash loses in speed due to its large size, but wins a lot back by having builtins that it can use for many features. If ash+builtins is still smaller than bash, wouldn't it solve both problems? (Of course if configure scripts choose bash automatically if present, then that sort of throws a wrench in that logic.) Final question: It seems to me that most of what a shell does for most common things is essentially "fork(); ... exec(); ... wait();". I'm sure there's an obvious reason why the following is not feasible, but would it be possible to special case this in the shell to use something that maps closer to the win32 api like spawn() so as to avoid having to fork()? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
On Sun, Jun 12, 2005 at 09:15:58PM -0500, Gary R. Van Sickle wrote: >- "transfigure" is a dead-simple shell script that just calls ./configure >with a slew of config options. >- Everything's faster today (real anyway), probably due to the following: > - I'm probably using a different snapshot. > - I cvs updated my wxWidgets source just before running the tests. > - In the previous tests I wasn't particularly careful to leave the machine >alone (did some web browsing, email etc). This time I made sure to do >nothing during the tests. >- Percentage differences between configuring with bash vs. ash: > real: ~+17% > user: ~+1% > system: ~+25% >- Apparently the only way to get ash used at all is by explicitly "export >CONFIG_SHELL=/bin/sh"ing. In particular note the third ash test, where >/bin/sh is ash, and yet the configure times appear to indicate that bash is >in fact being used. > >Ergo: >- Yes, sh is still faster than bash. >- It's not a large enough difference that I would care about it. Others' >mileage may perhaps vary. >- It's unclear to me that it matters in any case, since apparently >configures have been using bash anyway. >- It's unclear to me then where the "sh is ash not bash" issues are actually >coming from, if not from run-of-the-mill configures. Now I'm confused, too. I thought the complaints were coming from people who used configure. Maybe they were coming from old configure scripts or possibly from makefiles. >- If it isn't configures, does anybody actually care about the semi-minor >slowdown since it would eliminate "ash != bash" issues? > >Hence: >- I still say /bin/sh == bash is the way to go. I agree. I hope that Eric Blake will also agree and eventually release a new version of bash where /bin/sh.exe is a hardlink (?) or copy (sigh). The only thing I'm not entirely sure about is whether we should just nuke ash from the distribution or not. It seems like if we didn't we would need a new release of ash with /bin/sh.exe replaced with /bin/ash.exe. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
Christopher Faylor wrote: > Now I'm confused, too. I thought the complaints were coming from people > who used configure. Maybe they were coming from old configure scripts > or possibly from makefiles. I always got the impression that most of those type of complaints were people that had written a (non-configure) script themselves, under linux, with /bin/sh as the shebang, and then tried to run it under Cygwin. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Making /bin/sh == bash. Has the time come?
> Can I just ask a basic question here? So if both ash and
> bash are using the same method of execution (fork), is the
> reason for bash's slowness due to it just being a larger
> program with more pages to copy during a fork()?
>
Fork() also has to dup any and all handles/descriptors/etc, which takes all
kinds of time.
> And a related question: Would it make more sense to compile
> ash with all its builtins enabled, rather than switching to
> bash? It seems from the benchmarks that bash loses in speed
> due to its large size, but wins a lot back by having builtins
> that it can use for many features. If
> ash+builtins is still smaller than bash, wouldn't it solve both
> problems? (Of course if configure scripts choose bash
> automatically if present, then that sort of throws a wrench
> in that logic.)
>
> Final question: It seems to me that most of what a shell does
> for most common things is essentially "fork(); ... exec();
> ... wait();". I'm sure there's an obvious reason why the
> following is not feasible, but would it be possible to
> special case this in the shell to use something that maps
> closer to the win32 api like spawn() so as to avoid having to fork()?
Something like this is on my "Master Plan Of Things I'll Probably Never Get
Around To". I can't for the life of me figure out why anybody ever thought
that the entire fork() concept was a good idea, indeed how they ever even
thought it up ("Oh my, wouldn't it be nice if I could magically duplicate
the entire state of my app in a new process, even though there has never
been a reason to do so?"), so my life's goal is to eliminate fork() entirely
from computer science. First step would be a shell that never forks.
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
On Sun, Jun 12, 2005 at 07:37:56PM -0700, Brian Dessent wrote: >Christopher Faylor wrote: > >> Recently, after too many hours hacking at vfork corner cases, I came to >> the conclusion that getting vfork working correctly was too difficult >> so, I turned off vfork in cygwin and asked Corinna to modify ash to use >> /bin/sh again. > >I assume that should read "modify ash to use fork() again." Yes. >Can I just ask a basic question here? So if both ash and bash are using >the same method of execution (fork), is the reason for bash's slowness >due to it just being a larger program with more pages to copy during a >fork()? I think it's more than that. I think bash does a lot more stuff. It deals with job control and has more sophisticated handling of functions and variables. So, I think that every invocation of a new process ends up executing more code in bash itself. >And a related question: Would it make more sense to compile ash with all >its builtins enabled, rather than switching to bash? That still leaves us with an "ash != bash" situation although it does reduce the support burden for ash if we get rid of the localized streamlining hacks. I'm still inclined to say that we should go with bash, just for compatibility, since the speed differences don't seem to be that great. >It seems from the benchmarks that bash loses in speed due to its large >size, but wins a lot back by having builtins that it can use for many >features. If ash+builtins is still smaller than bash, wouldn't it >solve both problems? (Of course if configure scripts choose bash >automatically if present, then that sort of throws a wrench in that >logic.) If ash had all of bash's builtins and handled everything just like bash and it was smaller, then yes, it would be a big win. However, if all of that was true, then it seems like there is something seriously wrong with bash. >Final question: It seems to me that most of what a shell does for most >common things is essentially "fork(); ... exec(); ... wait();". I'm >sure there's an obvious reason why the following is not feasible, but >would it be possible to special case this in the shell to use something >that maps closer to the win32 api like spawn() so as to avoid having to >fork()? The vfork implementation was essentially just a wrapper around spawn(). As soon as you start to contemplate using spawn instead of fork/exec you will probably run into all of the same issues that eventually drove me away from vfork. The biggest problem was keeping track of file descriptors. Getting tty file descriptors right was a pain and getting close-on-exec file descriptors right was another pain. Getting pids and process groups handled corectly was more pain. As I have had time to ruminate about this, I think I've come to the conclusion that I just didn't design things very well, so maybe the time is ripe for another vfork implementation. Even more interesting might be an implementation that intelligently tried to use vfork when fork was called -- that would give every program the benefit of vfork without recompiling. OTOH, there is a native Windows version of bash out there somewhere, isn't there? Maybe getting things working without fork would not be that hard given that as a template. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
On Sun, Jun 12, 2005 at 09:48:25PM -0500, Gary R. Van Sickle wrote: >>Can I just ask a basic question here? So if both ash and bash are >>using the same method of execution (fork), is the reason for bash's >>slowness due to it just being a larger program with more pages to copy >>during a fork()? > >Fork() also has to dup any and all handles/descriptors/etc, which takes >all kinds of time. Actually most handles are just inherited. Only some of them have to be duped or recreated -- ttys and sockets are the most notable exceptions. Some close-on-exec'ed fds have to be closed, too. With the advent of the cygheap, most of the inherited information is just one large "ReadProcessMemory" with a fixups for problematic stuff like sockets. There are all sorts of other things that fork does, though, like making half-hearted attempts to load dlls in the same location in the child as they were in the parent, fixing up mmaps, maintaining a list of handles to slow pid reuse for bash (is that still needed?), etc. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
Thorsten Dahlheimer wrote:
> Are you sure you didn't actually measure bash's performance twice?
I've just rerun the tests. This time I made sure in Task Manager that the
right shell is used.
Regards
Krzysztof Duleba
$ cat bench.sh
#!/bin/bash
benchmark() {
package="$1"
shell="$2"
unset CONFIG_SHELL
if [ $shell != "bash" ]; then export CONFIG_SHELL="/bin/$shell";
fi
echo "Configuring $package with $shell"
time "$package"/configure --prefix=/usr >"$package/confout.$shell"
echo
}
benchmark "netcat-0.7.1" "sh"
benchmark "netcat-0.7.1" "bash"
benchmark "mc-4.6.1-pre4" "sh"
benchmark "mc-4.6.1-pre4" "bash"
benchmark "octave-2.1.57" "sh"
benchmark "octave-2.1.57" "bash"
$ ./bench.sh
Configuring netcat-0.7.1 with sh
real0m48.519s
user1m24.139s
sys 0m23.826s
Configuring netcat-0.7.1 with bash
real0m52.584s
user1m29.344s
sys 0m29.698s
Configuring mc-4.6.1-pre4 with sh
real1m55.170s
user3m25.148s
sys 0m58.383s
Configuring mc-4.6.1-pre4 with bash
real2m2.551s
user3m29.032s
sys 1m7.058s
Configuring octave-2.1.57 with sh
real2m22.899s
user3m59.346s
sys 1m8.478s
Configuring octave-2.1.57 with bash
real2m30.363s
user4m9.959s
sys 1m23.563s
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
On Mon, Jun 13, 2005 at 05:45:47AM +0200, Krzysztof Duleba wrote:
>I've just rerun the tests. This time I made sure in Task Manager that
>the right shell is used.
>
>$ cat bench.sh
>#!/bin/bash
>
>benchmark() {
>package="$1"
>shell="$2"
>
>unset CONFIG_SHELL
>
>if [ $shell != "bash" ]; then export CONFIG_SHELL="/bin/$shell";
>fi
>
>echo "Configuring $package with $shell"
>
>time "$package"/configure --prefix=/usr >"$package/confout.$shell"
>echo
>}
>
>benchmark "netcat-0.7.1" "sh"
>benchmark "netcat-0.7.1" "bash"
>
>benchmark "mc-4.6.1-pre4" "sh"
>benchmark "mc-4.6.1-pre4" "bash"
>
>benchmark "octave-2.1.57" "sh"
>benchmark "octave-2.1.57" "bash"
>
>$ ./bench.sh
>Configuring netcat-0.7.1 with sh
>
>real0m48.519s
>user1m24.139s
>sys 0m23.826s
>
>Configuring netcat-0.7.1 with bash
>
>real0m52.584s
>user1m29.344s
>sys 0m29.698s
>
>Configuring mc-4.6.1-pre4 with sh
>
>real1m55.170s
>user3m25.148s
>sys 0m58.383s
>
>Configuring mc-4.6.1-pre4 with bash
>
>real2m2.551s
>user3m29.032s
>sys 1m7.058s
>
>Configuring octave-2.1.57 with sh
>
>real2m22.899s
>user3m59.346s
>sys 1m8.478s
>
>Configuring octave-2.1.57 with bash
>
>real2m30.363s
>user4m9.959s
>sys 1m23.563s
Thanks for running these. Would you mind running the same tests after
doing this:
mount -f -X -b c:/cygwin/bin /bin
mount -f -X -b c:/cygwin/bin /usr/bin
replacing the 'c:' above, as appropriate.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Backspace in gvim
This may not be related in cygwin but since that's where I am seeing it I will go ahead and ask. I am running gvim 6.3 windows version and cygwin latest version on XP and 2k which I just installed. Backspace in insert mode used to delete the char to the left (possibly gvim 6.2 on linux and another older cygwin on 2k). I have always :set bs=2 in gvimrc. Now when I hit backspace in insert mode the cursor just moves over the characters and does not seem to affect them. However, when I go to command mode (hit escape) the characters are then removed. Looking at the gvim/vim documenation it never seems to mention that backspace can delete anything other than possibly eol to joint two lines, nor does it mention the deferred delete on hitting escape. However, for years I have used backspace as a immediate delete key, as you can do on the command line vi mode and as backspace works in the email editor I am typing into now. Someone in a previous post dismissed this as "the way gvim works" but no mention was made of the deferred delete occurring when command mode entered. Anyone here know anything about this or seen this? Tks, -gene -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Question about /etc/profile
Hello, I'm having problems understanding how cygwin handles the loading of /etc/profile: -> My cygwin.bat says the following: @echo off F: chdir F:\cygwin\bin bash --login -i So, 'bash' supposedly goes and looks for /etc/profile where the environment variables are set (PATH, HOME, etc..). However, my installation doesn't have /etc/profile. Does this mean that I have to create it myself? I do find a f:\cygwin\etc\defaults\etc\profile though... Should I put this one in my cygwin.bat? Another thing that I don't understand is why I am not able to execute 'startx' (X server at /usr/X11R6/bin) even executing first the "profile" from above (manually) and having this profile the following: PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:$PATH export PATH Any idea? Thanks! FBM -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
Christopher Faylor wrote: > Thanks for running these. Would you mind running the same tests after > doing this: > > mount -f -X -b c:/cygwin/bin /bin > mount -f -X -b c:/cygwin/bin /usr/bin > > replacing the 'c:' above, as appropriate. I've already had /usr/bin mounted and cygwin\bin in system path (so there seems to be no need for mounting /bin), but sure thing: $ ./bench.sh Configuring netcat-0.7.1 with sh real0m47.611s user1m24.266s sys 0m23.371s Configuring netcat-0.7.1 with bash real0m51.942s user1m29.815s sys 0m29.348s Configuring mc-4.6.1-pre4 with sh real1m52.675s user3m26.551s sys 0m57.965s Configuring mc-4.6.1-pre4 with bash real2m1.234s user3m30.280s sys 1m7.476s Configuring octave-2.1.57 with sh real2m20.639s user4m0.171s sys 1m10.804s Configuring octave-2.1.57 with bash real2m32.874s user4m12.131s sys 1m23.832s Regards Krzysztof Duleba -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
On Mon, Jun 13, 2005 at 06:54:15AM +0200, Krzysztof Duleba wrote: >Christopher Faylor wrote: > >> Thanks for running these. Would you mind running the same tests after >> doing this: >> >> mount -f -X -b c:/cygwin/bin /bin >> mount -f -X -b c:/cygwin/bin /usr/bin >> >> replacing the 'c:' above, as appropriate. > >I've already had /usr/bin mounted and cygwin\bin in system path (so there >seems to be no need for mounting /bin), but sure thing: The key here was the '-X' option. It looks like there was a negligible performance increase from mounting with -X. Thanks for trying this. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Making /bin/sh == bash. Has the time come?
On Mon, Jun 13, 2005 at 01:10:39AM -0400, Christopher Faylor wrote: >On Mon, Jun 13, 2005 at 06:54:15AM +0200, Krzysztof Duleba wrote: >>Christopher Faylor wrote: >> >>> Thanks for running these. Would you mind running the same tests after >>> doing this: >>> >>> mount -f -X -b c:/cygwin/bin /bin >>> mount -f -X -b c:/cygwin/bin /usr/bin >>> >>> replacing the 'c:' above, as appropriate. >> >>I've already had /usr/bin mounted and cygwin\bin in system path (so there >>seems to be no need for mounting /bin), but sure thing: > >The key here was the '-X' option. It looks like there was a negligible >performance increase from mounting with -X. Sorry. It's too late. I meant "a negligible performance improvement". cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Backspace in gvim [SOLVED]
Gene Smith wrote, On 06/13/2005 12:28 AM: This may not be related in cygwin but since that's where I am seeing it I will go ahead and ask. I am running gvim 6.3 windows version and cygwin latest version on XP and 2k which I just installed. Backspace in insert mode used to delete the char to the left (possibly gvim 6.2 on linux and another older cygwin on 2k). I have always :set bs=2 in gvimrc. Now when I hit backspace in insert mode the cursor just moves over the characters and does not seem to affect them. However, when I go to command mode (hit escape) the characters are then removed. Looking at the gvim/vim documenation it never seems to mention that backspace can delete anything other than possibly eol to joint two lines, nor does it mention the deferred delete on hitting escape. However, for years I have used backspace as a immediate delete key, as you can do on the command line vi mode and as backspace works in the email editor I am typing into now. Someone in a previous post dismissed this as "the way gvim works" but no mention was made of the deferred delete occurring when command mode entered. Anyone here know anything about this or seen this? Tks, -gene Finally found this which explains it (see last posting): http://comments.gmane.org/gmane.editors.vim/33436 Since I am *now* using a "system wide" gvimrc, and not ~/.gvimrc, which defaults to vi compatible mode. Have to "set nocp" in $VIM/gvimrc. So not cygwin related as I expected. Now with bs=2, backspace in insert mode deletes to left and delete deletes to right like before. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
