Re: [ANNOUNCEMENT] xterm 348-1

2019-11-07 Thread Katsumi Yamaoka
On Thu, 07 Nov 2019 11:39:36 +0900, Takashi Yano wrote: > Wait. I have just found /etc/X11/app-defaults/XTerm has a entry > *VT100*eightBitInput: false > which is added from cygwin xterm 348-1. > Removing this line or changing the value to true solves this issue. > Katsumi, could you please

Re: [ANNOUNCEMENT] xterm 348-1

2019-10-31 Thread Katsumi Yamaoka
Hi, On Wed, 11 Sep 2019 18:24:37 -0400, Yaakov Selkowitz wrote: > The following packages have been uploaded to the Cygwin distribution: > * xterm-348-1 First of all, reverting it to XTerm(330) solved my problem. When copying non-ASCII text from another window to XTerm(348), it will be shown as

Re: A workaround against Emacs crash when displaying images

2019-03-10 Thread Katsumi Yamaoka
On Fri, 08 Mar 2019 13:04:40 +0100, Corinna Vinschen wrote: > I could reproduce the hang and found a potential deadlock situation. > I pushed a fix and uploaded new developer snapshots to > https://cygwin.com/snapshots/ > Please test. All seems to work fine on 3.0.3. Thank you! -- Problem

Re: A workaround against Emacs crash when displaying images

2019-03-07 Thread Katsumi Yamaoka
On Fri, 08 Mar 2019 08:36:24 +0900, Katsumi Yamaoka wrote: > I tried the 2019-03-06 snapshot and, oh!, I verified Emacs got > not to crash for displaying images without such a spell. > It seems Emacs revived as for me as it was before Cygwin 3. I'm sorry that was a hasty conclusio

Re: A workaround against Emacs crash when displaying images

2019-03-07 Thread Katsumi Yamaoka
On Thu, 07 Mar 2019 15:55:29 +, Ken Brown wrote: > On 3/6/2019 7:20 PM, Katsumi Yamaoka wrote: >> export MAGICK_THREAD_LIMIT=1 > Is this a new issue with cygwin-3.0.x? If so, it might be related > to the memory leak that was recently discovered (and fixed in the &g

A workaround against Emacs crash when displaying images

2019-03-06 Thread Katsumi Yamaoka
Hi, I found a workaround for Emacs from crashing that always happens when displaying images in an html article using Gnus. That is: export MAGICK_THREAD_LIMIT=1 According to the Google search someone said the crash arises due to a bug in ImageMagick incorporating OpenMP. I don't know what it

Emacs slow startup

2018-10-03 Thread Katsumi Yamaoka
Hi, Since a couple of months ago, Emacs takes about a minute to start. This happens with both emacs-X11 (the one Cygwin distributes) and the one I built, and everytime I get the following error: ** (emacs:10672): WARNING **: Error retrieving accessibility bus address:

Re: Cygwin 2.6.1 32-bit post install failed by /usr/bin/perl.exe

2017-01-17 Thread Katsumi Yamaoka
On Mon, 16 Jan 2017 18:57:51 +0100, Achim Gratz wrote: > Katsumi Yamaoka writes: >> Run setup-x86.exe for full install excluding *x86_64* modulues. > You do not want a full Cygwin install. In particular, you do not want a > full installl for Cygwin 32bit. Yes, I know I overdo or

Cygwin 2.6.1 32-bit post install failed by /usr/bin/perl.exe

2017-01-15 Thread Katsumi Yamaoka
Hi, I recently tried newly install Cygwin 2.6.1 on 32-bit Windows 10. I did: Stop old cygwin cd c:\ ren cygwin cygwin.old Run setup-x86.exe for full install excluding *x86_64* modulues. However, the post install didn't seem to end. At that time, ps on mintty showed a lot of defunct perl

Re: (call-process ...) hangs in emacs

2014-08-06 Thread Katsumi Yamaoka
On Wed, 06 Aug 2014 10:48:49 +0200, Corinna Vinschen wrote: On Aug 6 11:30, Katsumi Yamaoka wrote: % ./autogen.sh [...] Running 'autoreconf -fi -I m4' ... 0 [main] perl 4508 child_info_fork::abort: address space needed by 'POSIX.dll' (0x2D) is already occupied [...] You

Re: (call-process ...) hangs in emacs

2014-08-05 Thread Katsumi Yamaoka
On Tue, 05 Aug 2014 13:55:31 -0400, Ken Brown wrote: Angelo and Katsumi, could you test it and see if it solves the problems you reported? If so, I'll issue new emacs releases. Thanks. But currently I cannot test it since the autogen.sh script doesn't work as the following. I must make it

Re: (call-process ...) hangs in emacs

2014-08-01 Thread Katsumi Yamaoka
On Thu, 31 Jul 2014 15:51:49 +0100, Peter Hull wrote: VC integration in emacs has stopped working for me in the past few days. Using emacs debugger I found the last function call was to call-process which never returns. I can reproduce this by evaluating in Lisp Interaction mode (using ^J)

rebaseall breaks some packages(?)

2014-06-17 Thread Katsumi Yamaoka
Hi, I updated the Cygwin installation on Win7 SP1 32-bit yesterday (using setup-x86.exe) and got unable to use some commands. For instance, when I tried to update the Emacs source by using bzr+ssh I got: $ cd emacs/trunk $ bzr update 0 [main] python2.7 3856 child_info_fork::abort: address\

Re: rebaseall breaks some packages(?)

2014-06-17 Thread Katsumi Yamaoka
On Tue, 17 Jun 2014 15:40:25 +0900, Katsumi Yamaoka wrote: [...] Rebaseall doesn't help. A way to make those programs work I found is only to reinstall the packages: `gnome-keyring', `p11-kit-trust', `bzr', and `python'. However, those reinstallations cause some other programs to not work

Re: rebaseall breaks some packages(?)

2014-06-17 Thread Katsumi Yamaoka
On Tue, 17 Jun 2014 18:33:14 +0100, David Stacey wrote: On 17/06/14 09:28, Marco Atzeri wrote: [...] Sometime you need to full rebase from scratch. Remove the rebase database /etc/rebase.db.i386 and rebaseall again. Be sure to have not any running cygwin program This might happen if you

Re: rebaseall breaks some packages(?)

2014-06-17 Thread Katsumi Yamaoka
On Wed, 18 Jun 2014 13:11:44 +0900, Katsumi Yamaoka wrote: I did do nothing special; nevertheless all seems to be working fine now. It's a mystery, but I'm sorry for the noise anyway. A similar trouble happened after performing setup-x86.exe, that updated a couple of packages and ran

Re: bzr problem

2013-07-18 Thread Katsumi Yamaoka
Solved. What I've done was the clean install[1]. But I don't know what did the trick nor the cause of the problem[2] after all. Performing rebaseall doesn't seem to do any harm in this installation. Regards, [1] Rename c:\cygwin\ to c:\cygwin_old\ Install Cygwin in c:\cygwin\ using

Re: bzr problem

2013-07-15 Thread Katsumi Yamaoka
Achim Gratz wrote: Katsumi Yamaoka writes: 0 [main] python2.7 1264 child_info_fork::abort: address space needed by 'math.dll' (0x80) is already occupied But it is sometimes: 1 [main] python2.7 5784 child_info_fork::abort: unable to remap _ARC4.dll to same address as parent (0xBE

Re: bzr problem

2013-07-11 Thread Katsumi Yamaoka
binC_jMOtKUez.bin Description: application/emacs-lisp -- 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: bzr problem

2013-07-11 Thread Katsumi Yamaoka
Please ignore my last reply (there's something wrong in MIME encoding). Ken Brown wrote: On 7/11/2013 12:32 AM, Katsumi Yamaoka wrote: Hi, Recently /usr/bin/bzr doesn't work well. For the Emacs trunk, those two commands achieve the purpose even if issuing a warning: $ bzr update $ bzr

bzr problem

2013-07-10 Thread Katsumi Yamaoka
Hi, Recently /usr/bin/bzr doesn't work well. For the Emacs trunk, those two commands achieve the purpose even if issuing a warning: $ bzr update $ bzr commit -m Bla bla Usually a warning is like: 0 [main] python2.7 1264 child_info_fork::abort: address space needed by 'math.dll' (0x80) is