Re: cygwin-x xterm not compatible with windows 7?
On 12/07/2009 06:13 PM, Mike Ayers wrote: I'm asking because what I have noticed about Windows 7 > Home Edition is that even though I have created a user for myself with > administrative priveleges, unless I tell the OS that I want to > run a program as the administrator it will default to the privileges > for an > ordinary user. I don't know a way to turn this off, yet. I don't believe there is a workaround, unfortunately. Vista has the same issue. Isn't this just UAC? You can turn that off for a user if you want. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: cygwin-x xterm not compatible with windows 7?
> From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- > ow...@cygwin.com] On Behalf Of wgw...@sbcglobal.net > Sent: Saturday, December 05, 2009 4:34 PM > Sorry to take a bit of time to get back to you. I am attaching the > files you requested. I am not familar with the cygwin x server log, > but it looks like *that* starts up. It's just that xterm cannot > connect. That does appear to be the case. > You mentioned that the server listenens on 0.0.0.0. You mean a > port? No. "0.0.0.0" is the broadcast IP address. When a server listens on that address, it listens to every interface on the computer, so it wouldn't matter if you tried connecting to localhost or the external address (i.e. leave your DISPLAY pointing to 127.0.0.1:0). > I'm asking because what I have noticed about Windows 7 > Home Edition is that even though I have created a user for myself with > administrative priveleges, unless I tell the OS that I want to > run a program as the administrator it will default to the privileges > for an > ordinary user. I don't know a way to turn this off, yet. I don't believe there is a workaround, unfortunately. Vista has the same issue. > So, is it possible that the port that the cygwin-x server is listening > on > belongs to the administrator and the xterm session when it is > launched cannot write to this port as a result? No, there are no ownership issues sending packets to ports. My suspicion would be that the non-administrator X server process would not be allowed to open the listeneing port, or be firewalled off, but neither can be the case if xcalc works. Have you tried running xterm from a cygwin console after the server has started? > I tried running DOS > cmd as > the administrator btw, with no better results. Which DOS command? Thanks, Mike
Re: GSlice problem with emacs Gtk+ build
On 12/7/2009 2:13 PM, Yaakov (Cygwin/X) wrote: On 07/12/2009 10:06, Ken Brown wrote: There's a known workaround, which is to set G_SLICE=always-malloc before starting emacs. As emacs maintainer, I've been reluctant to provide the Gtk+ version of emacs, because I don't want to answer hundreds of emails telling people about the workaround. I could supply a wrapper script that sets G_SLICE, but I'm still afraid that would cause a lot of confusion; I suspect many people are in the habit of calling emacs-X11.exe directly. I have therefore configured the emacs-X11 package to use Xaw instead of Gtk+. But Gtk+ is really much nicer, and I would like to be able to provide an emacs-X11 that uses it. What about adding to the beginning of main(): #ifdef __CYGWIN__ setenv("G_SLICE", "always-malloc", 1); #endif Thanks, Yaakov! I was looking for more complicated solutions and never thought of the easy one. That fixes it. Ken -- 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: GSlice problem with emacs Gtk+ build
On 07/12/2009 10:06, Ken Brown wrote: There's a known workaround, which is to set G_SLICE=always-malloc before starting emacs. As emacs maintainer, I've been reluctant to provide the Gtk+ version of emacs, because I don't want to answer hundreds of emails telling people about the workaround. I could supply a wrapper script that sets G_SLICE, but I'm still afraid that would cause a lot of confusion; I suspect many people are in the habit of calling emacs-X11.exe directly. I have therefore configured the emacs-X11 package to use Xaw instead of Gtk+. But Gtk+ is really much nicer, and I would like to be able to provide an emacs-X11 that uses it. What about adding to the beginning of main(): #ifdef __CYGWIN__ setenv("G_SLICE", "always-malloc", 1); #endif Yaakov Cygwin/X -- 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/
GSlice problem with emacs Gtk+ build
There's been a longstanding problem with emacs if it is configured to use Gtk+ in Cygwin. The relevant threads begin here: http://cygwin.com/ml/cygwin/2006-07/threads.html#00823 http://cygwin.com/ml/cygwin/2007-02/threads.html#00469 http://cygwin.com/ml/cygwin/2007-02/threads.html#00503 Briefly, the problem is the following (quoted from the emacs etc/PROBLEMS file): "Emacs supplies its own malloc, but glib (part of Gtk+) calls memalign and on Cygwin, that becomes the Cygwin supplied memalign. As malloc is not the Cygwin malloc, the Cygwin memalign always returns ENOSYS." The symptom is that emacs crashes with an error message like the following: ***MEMORY-ERROR***: [2428]: GSlice: failed to allocate 120 bytes (alignment: 128): Function not implemented Fatal error (6)Aborted (core dumped) There's a known workaround, which is to set G_SLICE=always-malloc before starting emacs. As emacs maintainer, I've been reluctant to provide the Gtk+ version of emacs, because I don't want to answer hundreds of emails telling people about the workaround. I could supply a wrapper script that sets G_SLICE, but I'm still afraid that would cause a lot of confusion; I suspect many people are in the habit of calling emacs-X11.exe directly. I have therefore configured the emacs-X11 package to use Xaw instead of Gtk+. But Gtk+ is really much nicer, and I would like to be able to provide an emacs-X11 that uses it. At the time this was first discussed, Cygwin did not have an X maintainer. Now that we have Jon and Yaakov actively providing Cygwin/X support, I wonder if it would be possible to revisit the issue and try to fix the problem. For example, might it be as simple as patching the Cygwin port of glib to achieve the same effect as setting G_SLICE=always-malloc? Ken -- 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: 1.7 - what's the right way to start X?
"Yaakov (Cygwin/X)" writes: >On 04/12/2009 10:12, Fredrik Staxeng wrote: >> I have seen this problem before, and the solution was to run rebaseall, >> which broke emacs, and then reinstall libncurses to fix emacs. >> >> Is this the way to do it? >> Will it still break emacs? >> Will other things break? >> Will it break again when updating cygwin? > >This was only true with the old version of emacs which depended on >libncurses7, as the latter was not rebase-able. This is no longer an >issue with the latest version of emacs; just rebase and you should be >fine. Thanks. I just upgraded to the version released this Friday, and I haven't seen the message yet. But if I do, I know what to do. -- Fredrik Stax\"ang | rot13: s...@hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET -- 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/