Re: latest emacs, cygwin, and constant stackdumps
On Tue, Mar 29, 2011 at 18:24, Ken Brown kbr...@cornell.edu wrote: On 3/29/2011 9:26 AM, Ken Brown wrote: On 3/29/2011 8:48 AM, J. David Boyd wrote: I'm not certain of the exact version of these, but they are the latest, as I upgrade at least once a week. Lately, everytime I do almost anything in emacs, the terminal I started it from shows: [main] emacs-X11 4500 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1149 [main] emacs-X11 4500 open_stackdumpfile: Dumping stack trace to emacs-X11.exe.stackdump I've been experiencing exactly the same symptoms. Also, it might make sense to update your Cygwin installation first, since new versions of cygwin and and xorg-server were just released today. Finally, please tell me if the problem occurs with both emacs-23.3-1 and the test release emacs-23.3-2. I've updated cygwin, installed emacs-23.3-2, and followed the instructions in: http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-status-access-violation None of it helped. Another thought: Have you tried rebaseall?. rebaseall indeed eliminated the problem for me. Thanks! --Dan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unable to install X on 64-bit Windows 7 Premium
On Sun, Aug 15, 2010 at 04:03, Dan Tsafrir da...@cs.technion.ac.il wrote: I've done exactly this, then tried to install some X stuff and got: Package: xinit xinit.sh exit code 8 Package: No package xinit.sh exit code 8 It turns out that the above error message is generated by the second (and final) line of /etc/postinstall/xinit.sh, which attempts to create the Cygwin-X/Xwin Server menu shortcut, using /usr/bin/mkshortcut.exe; I can't tell why the latter fails, but I've attached the output of strace to hopefully provide a clue. Thanks, --Dan 5 5 [main] mkshortcut 4904 open_shared: name shared.5, n 5, shared 0x60FC (wanted 0x60FC), h 0xC4 121 126 [main] mkshortcut 4904 heap_init: heap base 0x1041, heap top 0x1041 75 201 [main] mkshortcut 4904 open_shared: name S-1-5-21-1390067357-606747145-725345543-18054.1, n 1, shared 0x60FD (wanted 0x60FD), h 0xC8 38 239 [main] mkshortcut 4904 user_info::create: opening user shared for 'S-1-5-21-1390067357-606747145-725345543-18054' at 0x60FD 35 274 [main] mkshortcut 4904 user_info::create: user shared version 6112AFB3 60 334 [main] mkshortcut 4904 events_init: windows_system_directory 'C:\Windows\system32\', windows_system_directory_length 20 52 386 [main] mkshortcut 4904 dll_crt0_0: finished dll_crt0_0 initialization 119 505 [main] mkshortcut 4904 _cygtls::remove: wait 0x 46 551 [main] mkshortcut 4904 _cygtls::remove: removed 0x22CE64 element 0 84 635 [main] mkshortcut 4904 _cygtls::remove: wait 0x 33 668 [main] mkshortcut 4904 _cygtls::remove: removed 0x22CE64 element 0 91859853 [main] mkshortcut 4904 _cygwin_istext_for_stdio: fd 0: not open 459898 [main] mkshortcut 4904 _cygwin_istext_for_stdio: fd 1: not open 309928 [main] mkshortcut 4904 _cygwin_istext_for_stdio: fd 2: not open 406 10334 [main] mkshortcut 4904 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\dants, no-keep-rel, no-add-slash) 63 10397 [main] mkshortcut 4904 normalize_win32_path: C:\cygwin\home\dants = normalize_win32_path (C:\cygwin\home\dants) 43 10440 [main] mkshortcut 4904 mount_info::conv_to_posix_path: /home/dants = conv_to_posix_path (C:\cygwin\home\dants) 137 10577 [main] mkshortcut (4904) open_shared: name cygpid.4904, n 4904, shared 0x60FF (wanted 0x60FF), h 0x150 329 10906 [main] mkshortcut 4904 ** 31 10937 [main] mkshortcut 4904 Program name: C:\cygwin\bin\mkshortcut.exe (pid 4904, ppid 1) 29 10966 [main] mkshortcut 4904 App version: 1007.1, api: 0.218 28 10994 [main] mkshortcut 4904 DLL version: 1007.5, api: 0.225 28 11022 [main] mkshortcut 4904 DLL build:2010-04-12 19:07 229 11251 [main] mkshortcut 4904 OS version: Windows NT-6.1 31 11282 [main] mkshortcut 4904 Heap size:402653184 30 11312 [main] mkshortcut 4904 ** 29 11341 [main] mkshortcut 4904 pinfo::thisproc: myself-dwProcessId 4904 31 11372 [main] mkshortcut 4904 time: 1281893010 = time (0) 5661 17033 [main] mkshortcut 4904 parse_options: glob (called func) 59 17092 [main] mkshortcut 4904 parse_options: returning 114 17206 [main] mkshortcut 4904 environ_init: GetEnvironmentStrings returned 0x2BAF48 57 17263 [main] mkshortcut 4904 environ_init: 0x10438298: !::=::\ 54 17317 [main] mkshortcut 4904 environ_init: 0x104382A8: !C:=C:\cygwin\bin 58 17375 [main] mkshortcut 4904 environ_init: 0x104382C0: ALLUSERSPROFILE=C:\ProgramData 56 17431 [main] mkshortcut 4904 environ_init: 0x104382E8: APPDATA=C:\Users\dants\AppData\Roaming 57 17488 [main] mkshortcut 4904 environ_init: 0x10438318: COMMONPROGRAMFILES=C:\Program Files\Common Files 57 17545 [main] mkshortcut 4904 environ_init: 0x10438350: COMPUTERNAME=ZAFRIR 58 17603 [main] mkshortcut 4904 environ_init: 0x10438370: COMSPEC=C:\Windows\system32\cmd.exe 57 17660 [main] mkshortcut 4904 environ_init: 0x104383A0: CVS_RSH=/bin/ssh 56 17716 [main] mkshortcut 4904 environ_init: 0x104383B8: CYGWIN=noglob 56 17772 [main] mkshortcut 4904 environ_init: 0x104383D0: DEFLOGDIR=C:\ProgramData\McAfee\DesktopProtection 55 17827 [main] mkshortcut 4904 environ_init: 0x10438408: FP_NO_HOST_CHECK=NO 73 17900 [main] mkshortcut 4904 getwinenv: can't set native for HOME= since no environ yet 36 17936 [main] mkshortcut 4904 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\dants, no-keep-rel, no-add-slash) 32 17968 [main] mkshortcut 4904 normalize_win32_path: C:\cygwin\home\dants = normalize_win32_path (C:\cygwin\home\dants) 31 17999 [main] mkshortcut 4904 mount_info::conv_to_posix_path: /home/dants = conv_to_posix_path (C:\cygwin\home\dants) 79 18078 [main] mkshortcut 4904 win_env::add_cache: posix /home/dants 29
Re: Unable to install X on 64-bit Windows 7 Premium
On Tue, Aug 10, 2010 at 15:12, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 10/08/2010 00:19, Bob Kline wrote: I finally had to replace my ancient Windows XP box, and ended up with a Windows 7 Home Premium 64-bit system. If I run setup.exe to install a fresh cygwin, it succeeds as long as I don't touch the X11 set, leaving it at Default (which is to say, don't install anything in the set). If I change Default to Install for X11, I get a dialog box which says: Cygwin Setup - Running postinstall scripts Postinstall script errors The following errors occured executing postinstall scripts Package: gcc4-core gcc4-core.sh exit code 126 This one is already reported at [1], and the workaround given there,i.e. chmod 755 /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh and then run /etc/postinstall/gcc4-core.sh manually should work. I've done exactly this, then tried to install some X stuff and got: Package: xinit xinit.sh exit code 8 Package: No package xinit.sh exit code 8 Any help would be appreciated. Thanks, --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Tue, Apr 13, 2010 at 14:16, Ken Brown kbr...@cornell.edu wrote: On 4/12/2010 7:52 PM, Dan Tsafrir wrote: On Tue, Apr 6, 2010 at 00:39, Jon TURNEYjon.tur...@dronecode.org.uk wrote: I've conducted a few repeated measurements and it looks as though setting LANG to be en_US somewhat reduces the start time of emacs-x11: instead of ~30 seconds with LANG=C.UTF-8, it take ~27 seconds LANG=en_US. While this is ~10% less, waiting 27 seconds for emacs to open still seems unreasonable. Any other ideas? Hmm You don't have any emacs fonts being set via ~/.Xdefaults or ~/.Xresources? Actually, I do. However, following the suggestion of Ken Brown http://www.mail-archive.com/cyg...@cygwin.com/msg107126.html I've invoked emacs with -Q (and also, just to make sure, removed my ~/.Xdefaults). It did not change anything: emacs still takes ~30 seconds to open. It still might be font related. You mentioned earlier in the thread that you installed all available font packages. Do you have a very large ~/.fontconfig directory as a result? Maybe emacs has to process this every time it starts up. (I'm not sure.) What if you delete this directory and do a minimal Cygwin install without so many fonts? I think the first time you start emacs it may call fc-cache to populate ~/.fontconfig, but after that it might start faster. Hm, it seems I don't have a ~/.fontconfig. The output of find / -name '*fontconfig*' -print in my system is given in the attached file (I've checked /var/cache/fontconfig which turned out to be empty). I hope that's normal. --Dan find-fontconfig Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Tue, Apr 13, 2010 at 17:22, Jon TURNEY jon.tur...@dronecode.org.uk wrote: The mechanism that loads ~/.Xdefaults into the X server resource database is nicely obscure, so I'm not sure that -q actually avoids that. The definitive way to check would be to move ~/.Xdefaults aside, restart the X server then start emacs (I'm not sure if your clean install test would have done this or not) Yes, this is what I've done after the -Q didn't work. I'm currently running without any customized ~/.Xdefaults, ~/.emacs, ~/.bashrc, etc. It didn't make the problem go away. Emacs still takes ~30 sec to open. Another thing which might be worth trying is to see if the behaviour changes in a non-UTF-8 locale, e.g. export LANG=C and then run emacs. Setting LANG=C doesn't solve the problem. And as I reported here http://cygwin.com/ml/cygwin-xfree/2010-03/msg00090.html LANG=en_US doesn't solve it either. So far it seems that (1) emacs takes a long time to start up (2) xterm starts up quickly. Are there other X applications that you use and how do they behave? - Running time xterm ls (I believe 'ls' is taken to be the shell; so xterm opens, lists the content of my homedir, and immediately closes) reports about 2.6 of real time seconds. - Opening xfig takes about 3-4 seconds. - Doing plot sin(x) from within gnuplot takes about a second or less to open up a window to display the graph. - Opening xeyes takes a second or less. - BUT opening xclock takes nearly 30 seconds (half user time, half system time). So, as you speculated, it turns out this is not just an emacs problem. --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Tue, Apr 13, 2010 at 17:55, Markus Hoenicka markus.hoeni...@mhoenicka.de wrote: Jon TURNEY jon.tur...@dronecode.org.uk was heard to say: So far it seems that (1) emacs takes a long time to start up (2) xterm starts up quickly. Are there other X applications that you use and how do they behave? I've followed this thread with interest, but so far I thought I'm not affected. I usually start emacs along with the xserver by typing startxwin /usr/bin/emacs in the MinTTY console. This works without problems. Also, starting Emacs from the right-click menu of the X server in the system tray works fine. However, I've never noticed that starting emacs from MinTTY into a running X session actually takes quite some time. That is, I can confirm this part of the OP's problem. I bring up X (along with the first xterm window) by using this Windows-XP shortcut: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -nolock After, I do everything through said xterm window. Opening emacs by right clicking the X tray icon produces similar results to doing so through the command line: it takes a very long time. --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Wed, Apr 14, 2010 at 10:17, Dan Tsafrir da...@cs.technion.ac.il wrote: On Tue, Apr 13, 2010 at 17:22, Jon TURNEY jon.tur...@dronecode.org.uk wrote: [snip] So far it seems that (1) emacs takes a long time to start up (2) xterm starts up quickly. Are there other X applications that you use and how do they behave? [snip] opening xclock takes nearly 30 seconds (half user time, half system time). So, as you speculated, it turns out this is not just an emacs problem. I wasn't able to strace emacs, but I am able to strace xclock (brining it up, which when strace-ing takes several long minutes on my netbook, and then immediately killing it). The output is at: http://www.cs.technion.ac.il/~dants/xclock-strace-output.txt.gz Maybe this would provide a clue. --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Wed, Apr 14, 2010 at 12:24, Markus Hoenicka markus.hoeni...@mhoenicka.de wrote: I've had a look at your strace log. I've noticed the same block of statements which seems to be repeated over and over again (see my previous post). Did you watch the strace output on the console in real time to verify that this is where the process spends most of its time? 3139 16066368 [main] xclock 5708 readv: readv (4, 0x22A6D4, 1) blocking, sigcatchers 0 1765 16068133 [main] xclock 5708 readv: no need to call ready_for_read 1487 16069620 [main] xclock 5708 fhandler_base::read: returning 1024, binary mode 1531 16071151 [main] xclock 5708 readv: 1024 = readv (4, 0x22A6D4, 1), errno 2 This is where I have seen xterm to spend most of its time. The two numbers at the beginning of each strace output line (like the ones you quoted above) answer this question. I believe the first number is elapsed microseconds since the previous line and the second number is elapsed microseconds since the beginning of the run. If this is correct then the block above takes about 8ms. Note, however, that the strace log of xclock's startup is comprised of 414,669 lines, a fact that coincides with the several minutes it has taken the straced xclock to open. --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Tue, Apr 13, 2010 at 09:46, Bengt-Arne Fjellner bengt-arne.fjell...@ltu.se wrote: On 2010-04-13 1:52 AM, Dan Tsafrir wrote: I've invoked emacs with -Q (and also, just to make sure, removed my ~/.Xdefaults). It did not change anything: emacs still takes ~30 seconds to open. A shot (well two) in the dark. I have seen delays of 30 seconds when the resolver has problems. Is your dns configuration correct? Do you have valid entries for localhost and your real hostname in windows/system32/drivers/etc/hosts? I'm not sure I know enough to answer these questions. If you could please be more specific regarding what to check, I'll provide the information. Assuming it's related, other then comment lines, my cygwin /etc/hosts contains this single line only: 127.0.0.1 localhost. My DNS configuration appears to be working fine. Note that the emacs / cygwin1.7 problem is reproducible in that it reoccurs whenever I do a clean cygwin install (only installing the default components plus emacs and its dependencies). --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Tue, Apr 6, 2010 at 00:39, Jon TURNEY jon.tur...@dronecode.org.uk wrote: I've conducted a few repeated measurements and it looks as though setting LANG to be en_US somewhat reduces the start time of emacs-x11: instead of ~30 seconds with LANG=C.UTF-8, it take ~27 seconds LANG=en_US. While this is ~10% less, waiting 27 seconds for emacs to open still seems unreasonable. Any other ideas? Hmm You don't have any emacs fonts being set via ~/.Xdefaults or ~/.Xresources? Actually, I do. However, following the suggestion of Ken Brown http://www.mail-archive.com/cyg...@cygwin.com/msg107126.html I've invoked emacs with -Q (and also, just to make sure, removed my ~/.Xdefaults). It did not change anything: emacs still takes ~30 seconds to open. What else? ---Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Mon, Mar 29, 2010 at 19:14, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 29/03/2010 11:33, Dan Tsafrir wrote: After I've upgraded to cygwin-1.7 my emacs takes 30-40 seconds to open. Following http://x.cygwin.com/docs/faq/cygwin-x-faq.html#poor-performance, disabling my antivirus has no affect on emacs's opening time. As far as I can tell other X programs behave similarly to the way they did before the upgrade. Any help would be appreciated. The output of 'cygcheck -s -v -r' is attached. LANG = 'C.UTF-8' You are probably being bitten by [1] [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10948 I confirm the symptom described in [1] happening when I invoke emacs-x11; namely, emacs-x11 indeed consumes a lot of CPU upon startup. But, alas, the workarounds you suggest don't solve the problem. Specifically: As far as I can tell, this is a general problem with X, but cygwin unfortunately encounters it in a default install because (a) the default locale is a UTF-8 locale, and (b) we don't install the CJK fonts by default. Workarounds you might try are (a) install the font packages font-isas-misc, font-jis-misc and font-daewoo-misc (and restart your server), As can be seen in the cygcheck.out I've attached to my initial email, these fonts were/are already installed in my system: font-isas-misc 1.0.1-1 font-jis-misc 1.0.1-1 font-daewoo-misc1.0.1-1 (In fact, I've installed all the available fonts in cygwin setup.) or (b) set your locale to a non-UTF-8 one. I've conducted a few repeated measurements and it looks as though setting LANG to be en_US somewhat reduces the start time of emacs-x11: instead of ~30 seconds with LANG=C.UTF-8, it take ~27 seconds LANG=en_US. While this is ~10% less, waiting 27 seconds for emacs to open still seems unreasonable. Any other ideas? Thanks, --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Mon, Mar 29, 2010 at 15:13, Ken Brown kbr...@cornell.edu wrote: On 3/29/2010 6:33 AM, Dan Tsafrir wrote: Hi, After I've upgraded to cygwin-1.7 my emacs takes 30-40 seconds to open. Following http://x.cygwin.com/docs/faq/cygwin-x-faq.html#poor-performance, disabling my antivirus has no affect on emacs's opening time. As far as I can tell other X programs behave similarly to the way they did before the upgrade. Any help would be appreciated. The output of 'cygcheck -s -v -r' is attached. Does this happen only when you start emacs under X11? If so, the discussion probably belongs on the cygwin-xfree list. If you are referring to, e.g., how long it takes 'emacs -nw' to open, then it's like you speculated, namely, immediately responsive. Have you tried starting emacs with the -Q option? This will eliminate the effects of your customizations (.emacs, .Xdefaults, etc.). Adding the -Q option doesn't change a thing: the opening of emacs-x11 with this option is still very slow, around 30-40 seconds as I reported initially. Thanks, --Dan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Reproducing the cygwin X clipboard problems
On Wed, Feb 25, 2009 at 5:51 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: I've built a version of 1.5.3-7, with this patch reverted and lots more clipboard debugging added. You can download it from [2] It would be most helpful if you could try this and see if the clipboard problems you are seeing are changed at all. I'm afraid I didn't have the same experience as Mike. I've downloaded and ran your patched XWin. The result was non-deterministic: it typically starts good, but then the problem returns, and may go away and return again, depending on what I do. However, I was never able to replicate. Alas, I currently don't have time to come up with some more coherent observations. I will try it out again during the weekend and report back. --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Reproducing the cygwin X problems
On Tue, Feb 24, 2009 at 2:13 PM, Jon TURNEY It seems likely that this clipboard contention between multiple applications might behave differently on machines with multi-core processors (which I don't have the capability to test on), so can you indicate if you are using single-core or multi-core processor? Indeed, I'm using a dual core machine. However, in an attempt to test your hypothesis, I've set the affinity of XWin.exe, emacs, and the vncviewer to only use CPU0 (through the task manager). This had no positive affect on the problem: the instant I highlighted some text within emacs my copy-paste functionality was dead, regardless of affinity. --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xdvi unexplained locale problem
On Wed, Feb 18, 2009 at 3:02 PM, Mike Ayers mike_ay...@tvworks.com wrote: Dan Tsafrir wrote: open xdvi, I get the following error message: Warning: locale not supported by C library, locale unchanged Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default Warning: Unable to load any usable fontset Try unsetting LOCPATH: This didn't work either. In fact, I tried unset-ing this and very many other env variables before posting the question here. It seems to me that the behavior is unrelated to any env variables. It appears as though, for some unexplained reason, somewhere along the way, xdvi or X think they need to change to a locale other than C. Googling the error messages shows that ubuntu users faced a similar problem in early 2007 (related to xdvi and xfig): https://bugs.launchpad.net/ubuntu/+source/control-center/+bug/2066 Some thought it was an xorg problem. The suggested workarounds (e.g., setting a LANG=C env var) don't work for me. Am I the only one that gets this error message for xdvi on cygwin? --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Reproducing the cygwin X problems
On Fri, Feb 20, 2009 at 1:05 PM, Mike Ayers mike_ay...@tvworks.com wrote: I can neither confirm nor deny this, as I don't have ClipBook available. Did you try to run 'clipbrd' through start-run ? I just kill Xwin.exe forcibly in task manager - it takes all X apps with it. Right. However, the better trick I discovered recently is to click on VNC's taskbar icon and close it. Once it closes, the X applications recover and can cut-n-pste with Windows apps. Also, because VNC is VNC, no setup is lost there either - I can reconnect and my console is unharmed. This too works for me (but as you say, only if I kill the vncviewer through the context menu that pops up when right clicking its taskbar icon; strangely, killing it through the top right x doesn't produce a similar effect). Thanks! I suspect the problem here may be contention between the two applications that want to share the clipboard. Our other report implicated Office clipboard, which may be doing the same thing..? I strongly suspect cygwin's xorg is solely to blame: this problem was created immediately after my last upgrade of cygwin during which I unwittingly moved from xfree to xorg. (This is only one of the things that want bad for me; I wish there was a way to return to xfree until most of the problems are resolved.) --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Reproducing the cygwin X problems
On Fri, Feb 20, 2009 at 3:19 PM, Williams, Chris (Marlboro) christopherb.willi...@amd.com wrote: I use the file C:\cygwin\bin\startxwin.bat Me too, so I would guess that the difference in the copy-paste behavior we observe, is unrelated. --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: R: starxwin.bat always misfires the xterm once - it works!
On Wed, Feb 18, 2009 at 12:14 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Making startxwin.bat just launch startx or xinit would also largely solve the problem of overwriting people's customisations to startxwin.bat, as it has defined places to put those. I would like to point out that currently, it appears that in the eyes of the average user (like me?), startx does not produce acceptable results, as was just discussed here: http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00165.html so making startxwin.bat a wrapper around startx would potentially create a problem for many users, who, mind you, were already forced to waste some time in finding a workaround to the unfortunate fact that startx stopped working after up grade to xorg :( --Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xdvi unexplained locale problem
On Sat, Feb 14, 2009 at 1:46 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: NLSPATH = 'C:\Programs\IBM\RunTime\%N;' You should probably try without that in your environment, just to rule it out. $ unset NLSPATH $ xdvi It didn't work :( Any other ideas? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: gv became really slow?
I confirm that gv is practically unusable since I updated to x.org 7.4. It is very very slow. For the example you give, it takes only 2 seconds to load (same version 3.6.5, Windows XP, Dual Core2 Duo 2.6 GHz) but on the large ps files I use it takes ages to show compared to before I upgraded. Yes. In fact, just doing page-up / page-down takes 3-4 seconds if the page contains even the simplest figure (say, eps generated ny gnuplot, plotting ~25 points). It's really frustrating :( -- 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/
gv became really slow?
Hi, It used to be the case that opening a postscript file with gv on cygwin was more or less immediate. I've recently updated cygwin and now it takes about 2-5 seconds (a clock is displayed while gv is thinking). This happens even if the postscript file contains only a few words. For example, if you do: % echo hello hello.txt % a2ps hello.txt -o hello.ps % gv hello.ps The gv version I have running is 3.6.5 (cygwin 1.5.25 on XP). I have no way of telling whether this is a cygwin problem or something else. But running the above example on a debian machine with a gv-3.6.5 installed results in an immediate, much snappier, response. Is this just my problem? And if not, can something be done? Thanks, --Dan -- 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/
bug in cygwin's gcc/g++ getopt_long(): erroneous ambiguous option
Hi,
When given certain long options, Cygwin's getopt_long() function
erroneously fails on ambiguous option. The short program below
illustrates the problem: getopt_long() wrongfully reports the --xy
option as ambiguous.
Strangely, if flipping the order of the 2nd and 3rd entries in the
options-array (by compiling the program with -DNO_BUG) the bug goes
away, clearly demonstrating inconsistent Cygwin/getopt_long behavior.
The bug is triggered when compiling the program with Cygwin's default
gcc/g++ (3.4.4) or with gcc-4/g++-4 (4.3.2). The bug does not occur
when compiling the program with gcc/g++ (ver 3 or 4) on other OSes
(e.g., Linux).
A fix would be appreciated.
Best,
--Dan
// start program:
#include stdio.h
#include getopt.h
const struct option lopts[] = {
#ifdef NO_BUG
{xy1 , required_argument, NULL, 'a' },
{xy , required_argument, NULL, 'b' },
{xy2 , required_argument, NULL, 'c' },
{NULL , 0, NULL, 0 },
#else /* swapping order of 2nd and 3rd entries generates the bug */
{xy1 , required_argument, NULL, 'a' },
{xy2 , required_argument, NULL, 'c' },
{xy , required_argument, NULL, 'b' },
{NULL , 0, NULL, 0 },
#endif
};
int main()
{
const char* argv[] = {./a, --xy=1, NULL};
int argc = 2;
int index, c;
// if NO_BUG defined, will print: got opt=b [OK]
// otherwise: a: ambiguous option -- xy [BUG]
if( (c = getopt_long(argc, (char**)argv, A:B:C, lopts, index)) != EOF )
printf(got opt=%c\n, c);
return 0;
}
// end program
--
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: gv-3.6.1 erroneously displays text: doubling its vertical and halving its horizontal dimensions
On 1/18/07, Dan Tsafrir [EMAIL PROTECTED] wrote: Hi, When I open a postscript document (any document) with 'gv', the text in the document appears doubled in height and halved in width, making the document virtually unreadable. Well apparently there was something messed up in the ~/.gv file, as doing rm ~/.gv solved the problem. Thanks, --Dan -- 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/
