Re: emacs-23.2-3 DBus hangs
Ken Brown writes: > On 10/23/2010 12:22 AM, nyc4...@aol.com wrote: >> Just doing a: >> >> (require 'dbus) >> >> hangs Cygwin emacs-23.2-3 >> >> I can only `C-g' and abort emacs. > > Works fine for me. Do you have the system bus and session bus running > before you start emacs? If so, please say exactly how you're starting > the session bus and how you're starting emacs. OK, it looks like loading dbus.el is where it fails when following the instructions given in this URL: http://cygwin.com/ml/cygwin/2010-08/msg00892.html I guess this step is not necessary but emacs shouldn't hang. Here's the steps I followed: $ eval `dbus-launch --auto-syntax` $ echo $DBUS_SESSION_BUS_ADDRESS unix:path=/tmp/dbus-dlr0QTU52y,guid=2ed2e65c8040f348d71319f94cc36ca0 $ xterm & # This gives me a new xterm with "DBUS_SESSION_BUS_ADDRESS" set. In new xterm: $ dbus-monitor signal sender=org.freedesktop.DBus -> dest=:1.0 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.0" method call sender=:1.0 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='method_call'" method call sender=:1.0 -> dest=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='method_return'" method call sender=:1.0 -> dest=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='error'" In first xterm: $ emacs & In that emacs: (dbus-get-unique-name :session) ":1.0" load-file /usr/share/emacs/23.2/lisp/net/dbus.el.gz Hangs emacs after the "done" message... -- 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: Sending signals to a subprocess
On 10/20/2010 4:32 PM, Christopher Faylor wrote: On Wed, Oct 20, 2010 at 08:25:37PM +0100, Andy Koppe wrote: On 20 October 2010 13:20, Andy Koppe wrote: Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she saw Linux doing that. ??But when I run Corinna's test on my Linux system, I get -1 where she got 0. ??So not all Linuxes agree on what tcgetpgrp should do. Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before the child is forked and after it exited, so it's correct to report that there's no foreground process. I wonder which Linux it was that returned 0 in case of failure. I've tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and also a Debian with a 2.4 kernel, and got -1 on all of those. Actually I'd only tried my test on all three systems, whereas I'd tried Corinna's only on the old Redhat, where it did print -1 for failure. On the 2.4 system it can't open /dev/ptmx, whereas on the Opensuse with 2.6.34 I do get the results Corinna reported, including 0 on the master side of the pty when enquiring from the parent. (Process 0 is the startup process, so I guess that makes some sense.) To bring my ramblings to some sort of conclusion, here's a slightly amended version of Corinna's test that checks the master side from the parent process before, *during* and after the child process: FYI, I'm sticking with the test case that I first posted several days ago and which has been cruelly ignored ever since. I've been slowly modifying it for the last several days. I think I'm seeing some pattern to the way Linux handles this and I should be able to make Cygwin work the same way. This seems to be fixed in the latest snapshot, as far as emacs is concerned. I no longer see any difference between Cygwin and Linux there. I also get the expected results when I run the test cases that Andy posted. But when I run the original test case that you posted in http://cygwin.com/ml/cygwin/2010-10/msg00395.html I'm getting strange behavior. I ran it with no argument, getting 0 = tcgetpgrp(4) 0 = ioctl(fd, TIOCGPGRP, &pid), pid = 0 but then the terminal seemed to hang, and I didn't get a new prompt. I tried this both in mintty and xterm. Ken -- 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: problem with PATH set by libtool for uninstalled pixman library
On 04/09/2010 05:06, Charles Wilson wrote: On 7/29/2010 4:20 AM, Charles Wilson wrote: On 7/28/2010 2:24 PM, Jon TURNEY wrote: I have a tinderbox which does daily builds of the X.Org stack for cygwin, and I've come across a something I don't understand with the way libtool is working when building the pixman library, and I hope someone can shed a bit of light. I think a patch to simply swap the order of these two assignments would be fine (e.g. do $dllsearchpath first, then make sure it gets pre-empted by $rpath). On *nix it wouldn't matter, since the two variables are DISTINCT vars. Can you give the most recent (libtool-2.2.11a-1) release a try, and let me know if it fixes your problem? Yes, this seems to be working correctly now. Thanks. Sorry for the slow response, but I wanted to wait until the test result actually changed to check that the correct DLL really was being picked up. j...@allegra /opt/jhbuild/build/pixman/test $ ./blitters-test.exe --lt-debug blitters-test:./.libs/lt-blitters-test.c:227: libtool wrapper (GNU libtool 1.3260 2010-09-02) 2.2.11a blitters-test:./.libs/lt-blitters-test.c:228: (main) argv[0]: ./blitters-test blitters-test:./.libs/lt-blitters-test.c:229: (main) program_name: blitters-test blitters-test:./.libs/lt-blitters-test.c:390: (find_executable): ./blitters-test blitters-test:./.libs/lt-blitters-test.c:345: (check_executable): /opt/jhbuild/build/pixman/test/./blitters-test blitters-test:./.libs/lt-blitters-test.c:234: (main) found exe (before symlink chase) at: /opt/jhbuild/build/pixman/test/./blitters-test blitters-test:./.libs/lt-blitters-test.c:497: checking path component for symlinks: /opt/jhbuild/build/pixman/test/./blitters-test blitters-test:./.libs/lt-blitters-test.c:497: checking path component for symlinks: /opt/jhbuild/build/pixman/test/. blitters-test:./.libs/lt-blitters-test.c:497: checking path component for symlinks: /opt/jhbuild/build/pixman/test blitters-test:./.libs/lt-blitters-test.c:497: checking path component for symlinks: /opt/jhbuild/build/pixman blitters-test:./.libs/lt-blitters-test.c:497: checking path component for symlinks: /opt/jhbuild/build blitters-test:./.libs/lt-blitters-test.c:497: checking path component for symlinks: /opt/jhbuild blitters-test:./.libs/lt-blitters-test.c:497: checking path component for symlinks: /opt blitters-test:./.libs/lt-blitters-test.c:239: (main) found exe (after symlink chase) at: /opt/jhbuild/build/pixman/test/./blitters-test blitters-test:./.libs/lt-blitters-test.c:262: (main) libtool target name: blitters-test.exe blitters-test:./.libs/lt-blitters-test.c:613: (lt_setenv) setting 'BIN_SH' to 'xpg4' blitters-test:./.libs/lt-blitters-test.c:613: (lt_setenv) setting 'DUALCASE' to '1' blitters-test:./.libs/lt-blitters-test.c:663: (lt_update_exe_path) modifying 'PATH' by prepending '/opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:' blitters-test:./.libs/lt-blitters-test.c:613: (lt_setenv) setting 'PATH' to '/opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:/home/jon/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/bin' blitters-test:./.libs/lt-blitters-test.c:684: (lt_update_lib_path) modifying 'PATH' by prepending '/opt/jhbuild/build/pixman/pixman/.libs:' blitters-test:./.libs/lt-blitters-test.c:613: (lt_setenv) setting 'PATH' to '/opt/jhbuild/build/pixman/pixman/.libs:/opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:/home/jon/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/bin' blitters-test:./.libs/lt-blitters-test.c:294: (main) lt_argv_zero: /opt/jhbuild/build/pixman/test/./.libs/blitters-test.exe blitters-test:./.libs/lt-blitters-test.c:298: (main) newargz[0]: /opt/jhbuild/build/pixman/test/./.libs/blitters-test.exe -- 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: Bash Completion Install/Configure ; was: Re: Bash problems, strace, performance, etc.
On 10/22/2010 5:47 PM, Eric Blake wrote: > On 10/22/2010 03:41 PM, Ken Brown wrote: >> On 10/22/2010 12:32 AM, Andy Koppe wrote: >>> On 21 October 2010 22:22, Lee D. Rothstein wrote: The original complaint which is now solved (I think) had nothing to do with Bash completion. Cyrille brought it up, and it's become a crimson (not just red ;-)) herring. (I am grateful to "Ducky" on "NCIS" for explaining that obscure idiom to me. ;-)). I understood before my posts, during my posts, and after my posts (;-), that enabling Bash completion requires editing the startup scripts. The situation, with Bash completion install, as it exists, is fine, IMHDIO. I install everything on my system because there are so few things I don't want, that's its easier to remember to install everything and then not invoke/configure/load, that which I don't want. My only complaint would be if the maintainer somehow updated my customized startup scripts. And, that has/will never likely happene(d), because Cygwin maintainers are users and aware of the consequences of such rash actions. :-|, 8-) My only vote would be for an option to NOT skip library updates in 'setup.exe', but suggestions about 'setup' without the willingness and ability to make them one's own self, are usually met with calls for crucifixion. Alas, I don't have the ability, and object to the latter on religious, if not personal grounds. ;-) Thanks, Lee > Hmm - maybe this is a case of a copy and paste bug on my part. > Certainly, before bash-completion 1.0, you had to manually > enable things. But it looks like 1.0 and later (first cygwin > build in Apr 2009) inherit the upstream default of automatic > enabling. > I'll have to revisit that next time I package bash-completion, > and either fix the release notes to match reality, or alter the > packaging to restore the manual enabling (but note that other > distros like Fedora do automatic enabling if you install the > package, so that's the direction I'm leaning in). -- 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: emacs-23.2-3 DBus hangs
On 10/23/2010 12:22 AM, nyc4...@aol.com wrote: Just doing a: (require 'dbus) hangs Cygwin emacs-23.2-3 I can only `C-g' and abort emacs. Works fine for me. Do you have the system bus and session bus running before you start emacs? If so, please say exactly how you're starting the session bus and how you're starting emacs. Ken -- 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
