On 6/14/2012 3:18 PM, Ryan Johnson wrote:
On 13/06/2012 5:40 PM, Christopher Faylor wrote:
On Wed, Jun 13, 2012 at 05:07:17PM -0400, Ken Brown wrote:
On 6/13/2012 2:40 PM, Ken Brown wrote:
On 6/10/2012 8:45 PM, Ken Brown wrote:
The bisection shows that the first problematic commit is this one
On 13/06/2012 5:40 PM, Christopher Faylor wrote:
On Wed, Jun 13, 2012 at 05:07:17PM -0400, Ken Brown wrote:
On 6/13/2012 2:40 PM, Ken Brown wrote:
On 6/10/2012 8:45 PM, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/
Thank you Ken for first providing a useable patch and then finding the problem!
--
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
On Wed, Jun 13, 2012 at 05:07:17PM -0400, Ken Brown wrote:
>On 6/13/2012 2:40 PM, Ken Brown wrote:
>> On 6/10/2012 8:45 PM, Ken Brown wrote:
>>> The bisection shows that the first problematic commit is this one:
>>>
>>> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9f
On 6/13/2012 2:40 PM, Ken Brown wrote:
On 6/10/2012 8:45 PM, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie
Date: Wed Aug 31 22:07:02 201
On 6/10/2012 8:45 PM, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie
Date: Wed Aug 31 22:07:02 2011 -0400
GMain: simplify logic for g_wake
On 6/11/2012 11:10 AM, Ken Brown wrote:
On 6/11/2012 7:39 AM, Ken Brown wrote:
On 6/10/2012 10:54 PM, Yaakov (Cygwin/X) wrote:
On 2012-06-10 19:45, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae4
rebaseall appears to resolved the issue. GVim is running as expected!
--
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
Once again, please don't http://cygwin.com/acronyms/#TOFU .
On 6/11/2012 12:14 PM, K Stahl wrote:
I've reverted the suggested libraries and still no success with GVim.
Keep getting either a failed execution (exit code 127) or bad address
for /usr/bin/gvim.
Try running rebaseall. If that doesn
I've reverted the suggested libraries and still no success with GVim.
Keep getting either a failed execution (exit code 127) or bad address
for /usr/bin/gvim.
>
>
> On 6/11/2012 9:55 AM, K Stahl wrote:
>>
>> I've tried to revert the version of GLib 2.0 using the instructions
>> provided, but when
On 6/11/2012 7:39 AM, Ken Brown wrote:
On 6/10/2012 10:54 PM, Yaakov (Cygwin/X) wrote:
On 2012-06-10 19:45, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
A
Please don't http://cygwin.com/acronyms/#TOFU . Thanks.
On 6/11/2012 9:55 AM, K Stahl wrote:
I've tried to revert the version of GLib 2.0 using the instructions
provided, but when I attempt to start GVim nothing happens. The
process appears to fail without an explanation. System WinXP and all
I've tried to revert the version of GLib 2.0 using the instructions
provided, but when I attempt to start GVim nothing happens. The
process appears to fail without an explanation. System WinXP and all
Cygwin libs updated to the latest.
On Sun, Jun 10, 2012 at 8:45 PM, Ken Brown wrote:
> On 6/8/
On 6/10/2012 10:54 PM, Yaakov (Cygwin/X) wrote:
On 2012-06-10 19:45, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie
Date: Wed Aug 31 22:0
On 2012-06-10 19:45, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie
Date: Wed Aug 31 22:07:02 2011 -0400
GMain: simplify logic for g_wakeu
On 6/8/2012 12:45 PM, Ken Brown wrote:
On 6/8/2012 11:33 AM, Achim Gratz wrote:
Ken Brown writes:
As I said earlier, I don't understand very well how git branches work,
but I *think* this means we have to look in the 2-32 branch, prior to
the 2.31.0 tag, to find the problematic commit. I've che
Greetings, Ken Brown!
> Thanks, Achim. That helps a lot. The only thing I might have to change
> is the starting point for the bisection, since the tag 2.30.3 represents
> a fairly recent commit. But I think starting with 2.30.1 should work.
> I'll give it a try.
Why not slice relevant branc
On 6/8/2012 11:33 AM, Achim Gratz wrote:
Ken Brown writes:
As I said earlier, I don't understand very well how git branches work,
but I *think* this means we have to look in the 2-32 branch, prior to
the 2.31.0 tag, to find the problematic commit. I've checked out the
2-32 branch, and I guess t
Ken Brown writes:
> As I said earlier, I don't understand very well how git branches work,
> but I *think* this means we have to look in the 2-32 branch, prior to
> the 2.31.0 tag, to find the problematic commit. I've checked out the
> 2-32 branch, and I guess the next step is to find a problem-fr
On 6/6/2012 7:04 AM, Stephen L wrote:
Ken Brown cornell.edu> writes:
Never mind. I'm not up to this task. But if you're willing to
facilitate the bisection by doing the builds, I'll be glad to test them
on my XP system, at least as far as emacs is concerned. And I'm sure
there are gvim user
Ken Brown cornell.edu> writes:
> Never mind. I'm not up to this task. But if you're willing to
> facilitate the bisection by doing the builds, I'll be glad to test them
> on my XP system, at least as far as emacs is concerned. And I'm sure
> there are gvim users who would do the same.
ok so
On Mon, 04 Jun 2012 11:49:07 -0400, Ken Brown wrote:
| | |The emacs is not the only application, which is very slow now.
| | |Take a look at gvim.
| | |
| | |
| | |For my purpose I have not installed the changes to GNOME and work
| | |still with the old versions.
| | |With the f
On 6/3/2012 8:10 AM, Ken Brown wrote:
On 6/3/2012 5:08 AM, Yaakov (Cygwin/X) wrote:
On 2012-06-02 14:02, Ken Brown wrote:
I hope someone (Yaakov?) will take a look at the glib changes between
2.30.2 and 2.32.2 and try to find the cause of this problem.
I keep seeing XP in this thread. If this
On 6/3/2012 5:08 AM, Yaakov (Cygwin/X) wrote:
On 2012-06-02 14:02, Ken Brown wrote:
I hope someone (Yaakov?) will take a look at the glib changes between
2.30.2 and 2.32.2 and try to find the cause of this problem.
I keep seeing XP in this thread. If this is affecting only XP and not
other ver
On 2012-06-02 14:02, Ken Brown wrote:
I hope someone (Yaakov?) will take a look at the glib changes between
2.30.2 and 2.32.2 and try to find the cause of this problem.
I keep seeing XP in this thread. If this is affecting only XP and not
other versions of Windows, then it would be a bug in e
On 6/2/2012 11:09 AM, Ken Brown wrote:
We can revert by using the CTM (Cygwin Time Machine):
http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine
I'm hoping to do that this weekend on my XP machine and see if I can pin
down when the problem started. I made some incorrect statements about
On 6/2/2012 10:15 AM, Angelo Graziosi wrote:
Ken,
Ken Brown wrote:
Is this on XP? I ask because I'm having trouble reverting my XP system
back to a state where there's no problem.
I think we cannot revert because many of "prev" packages have been
removed by Cygwin distro.
We can revert by
Ken,
Ken Brown wrote:
Is this on XP? I ask because I'm having trouble reverting my XP system back to
a state where there's no problem.
I think we cannot revert because many of "prev" packages have been
removed by Cygwin distro.
Anyway, I have only XP and Emacs 24 from trunk, and it cannot
On 6/1/2012 2:17 AM, Pach Roman (DGS-EC/ESG2) wrote:
The emacs is not the only application, which is very slow now.
Take a look at gvim.
For my purpose I have not installed the changes to GNOME and work
still with the old versions.
With the following packages everything is running as fast as ear
This morning, I reverted GLib2.0 to a previous version and it did not
solve the issue.
Steps used in testing:
Extracted "libglib2.0_0-2.30.2-1.tar.bz2" and ran /etc/postinstall/glib2.0.sh
Started XWin and attempted to edit a file via gvim (performance issue
still remain)
On Fri, Jun 1, 2012 at 2:
On 6/1/2012 7:00 AM, Ken Brown wrote:
I found an XP system that hadn't been upgraded in a few weeks, and I
upgraded libglib2.0_0 but nothing else. This was enough to trigger the
problem.
I've checked the git repository for glib at
http://git.gnome.org/browse/glib/log/?h=glib-2-32
and there
Ken Brown cornell.edu> writes:
> Fortunately for emacs users, the problem doesn't seem to occur with
> emacs-24. (Can anyone else confirm this?)
Hi Ken,
So I just upgraded to emacs-24 (24.0.96.1), and while it is certainly better, I
wouldn't say it's fixed.
Try opening a text file (I have a ~
[Reformatted. Please don't top-post.]
On 6/1/2012 7:20 AM, xxx@xxx wrote:
On Fri, Jun 1, 2012 at 1:00 PM, Ken Brown wrote:
On 5/31/2012 4:51 PM, Angelo Graziosi wrote:
My upgrade regarded these packages:
_autorebase-69-1.tar.bz2
_update-info-dir-01051-1.tar.bz2
fftw3-3.3.2-1.tar.bz2
g
Hello,
Sorry, I have the same issue with emacs24 (GNU Emacs 24.0.96.1
(i686-pc-cygwin, GTK+ Version 2.24.10)).
Well it seems this EMACS 24 is built with GTK2.
This is the emacs package 24.0.96-2 I installed with setup.exe.
Regards
Fabien
On Fri, Jun 1, 2012 at 1:00 PM, Ken Brown wrote:
>
> On
On 5/31/2012 4:51 PM, Angelo Graziosi wrote:
My upgrade regarded these packages:
_autorebase-69-1.tar.bz2
_update-info-dir-01051-1.tar.bz2
fftw3-3.3.2-1.tar.bz2
glib2.0-networking-2.32.3-1.tar.bz2
gsettings-desktop-schemas-3.4.2-1.tar.bz2
gtk3-demo-3.4.3-1.tar.bz2
gvfs-1.12.3-1.tar.bz2
libff
The emacs is not the only application, which is very slow now.
Take a look at gvim.
For my purpose I have not installed the changes to GNOME and work
still with the old versions.
With the following packages everything is running as fast as earlier
release/GNOME/GConf2/GConf2-3.2.5-1.tar.bz2
Ken Brown wrote:
Yes, that is a lot of packages (almost 200). I don't think that will be of any
help in pinning down the problem.
My upgrade regarded these packages:
_autorebase-69-1.tar.bz2
_update-info-dir-01051-1.tar.bz2
fftw3-3.3.2-1.tar.bz2
glib2.0-networking-2.32.3-1.tar.bz2
gsetti
On 5/31/2012 4:45 AM, Stephen L wrote:
Ken Brown cornell.edu> writes:
Which packages got upgraded? You can check this by looking at
/var/log/setup.log.
unfortunately, a lot of packages were upgraded, as it is some while since I last
did an upgrade :(
Yes, that is a lot of packages (almos
Ken Brown cornell.edu> writes:
> Which packages got upgraded? You can check this by looking at
> /var/log/setup.log.
unfortunately, a lot of packages were upgraded, as it is some while since I last
did an upgrade :(
fyi I put the log here:
http://whelk.landamore.com/setup.log.gz
best regards
On 5/30/2012 6:51 AM, Stephen L wrote:
I just upgraded this morning and can confirm emacs is also very sluggish for me
also.
I'm running windows xp pro 2002 sp 3, if that is any help.
Let me know if you need any more information and/or help testing,
Which packages got upgraded? You can check
I just upgraded this morning and can confirm emacs is also very sluggish for me
also.
I'm running windows xp pro 2002 sp 3, if that is any help.
Let me know if you need any more information and/or help testing,
best regards,
stephen
--
Problem reports: http://cygwin.com/problems.html
FAQ
Thu, May 24, 2012 at 08:51AM -0400 Ken Brown wrote:
> On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote:
> >After an cygwin-upgrade this morning I'm experiencing performance
> >problems with emacs-X11 (23.4.2). The performance problem seem to be
> >graphics related. Window redraw is really slow
Hi Ken,
Ken Brown wrote:
I've noticed the same thing on my XP
I notice this, yesterday, after the upgrade announcede here:
http://cygwin.com/ml/cygwin-xfree/2012-05/msg00040.html
My builds of Emacs trunk, do not work any more correctly after the
upgrade. Emacs is very very slow...
Thi
I can confirm that same issue is present with GVim on a Windows XP
machine. The issue occurred after the last update (Gnome Libraries I
believe).
On Thu, May 24, 2012 at 8:51 AM, Ken Brown wrote:
> On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote:
>>
>> After an cygwin-upgrade this morning I'm e
On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote:
After an cygwin-upgrade this morning I'm experiencing performance problems with
emacs-X11 (23.4.2). The performance problem seem to be graphics related. Window
redraw is really slow, it can take up to a couple of seconds to redraw the
emacs win
On Mon, Jun 06, 2005 at 06:51:46PM -0700, Linda W wrote:
>>>separate thread running which manages this (which implies careful
>>attention to locking issues and context switching) or you a schedule
>> timer signal (which has similar problems).)
>>
>>
>This may not be necessary if you only cache fil
This may not be necessary if you only cache file handles within
1 execution of a program (like find), so that file-ops within the same
program achive speedup. You could time-out cache entries on an
as-needed basis or timer.
I was filling in the details here just to show that the solutio
On Jun 6 11:31, Corinna Vinschen wrote:
> On Jun 2 18:32, Brian Dessent wrote:
> > In order to implement stat(), cygwin has to call NtQueryInformationFile
> > (GetFileInformationByHandle for 9x/me) and this requires the file to be
> > opened. Thus the reason that stat takes forever is that each
On Jun 2 18:32, Brian Dessent wrote:
> In order to implement stat(), cygwin has to call NtQueryInformationFile
> (GetFileInformationByHandle for 9x/me) and this requires the file to be
> opened. Thus the reason that stat takes forever is that each file has
There would be a theoretical way around
On Sun, Jun 05, 2005 at 11:46:52PM -0400, Christopher Faylor wrote:
>I am talking about cache coherency.
It occured to me that I'm using the term "cache coherency" incorrectly
here. What I really mean to say is that Windows is in charge of all
file operations and so can and does maintain a consis
On Sun, Jun 05, 2005 at 08:00:44PM -0700, Linda W wrote:
>Christopher Faylor wrote:
>>On Sat, Jun 04, 2005 at 03:00:13PM -0700, Linda W wrote:
>>>You are technically accurate, but the cygwin layer is a POSIX
>>>complient-OS emulation layer by some definition, no?
>>
>>Yes, but that has nothing to d
Christopher Faylor wrote:
On Sat, Jun 04, 2005 at 03:00:13PM -0700, Linda W wrote:
You are technically accurate, but the cygwin layer is a POSIX
complient-OS emulation layer by some definition, no?
Yes, but that has nothing to do with caching. Cygwin is just a DLL. It
can't monito
On Sat, Jun 04, 2005 at 08:55:08PM -0400, Christopher Faylor wrote:
>I merely represented our current thinking about the subject that you
>raised.
Oh, on rereading this thread, I remembered that the main reason that I
responded at all was that Igor suggested SHTDI and PTC. I thought it
behooved m
On Sat, Jun 04, 2005 at 03:00:13PM -0700, Linda W wrote:
>Christopher Faylor wrote:
>>On Thu, 2 Jun 2005, Linda W wrote:
>>>In tracing the Win32 file operations, find seems to perform multiple
>>>file open operations for each file processed. One way to speed up
>>>operations in this area might be
Christopher Faylor wrote:
On Thu, 2 Jun 2005, Linda W wrote:
In tracing the Win32 file operations, find seems to perform multiple
file open operations for each file processed. One way to speed up
operations in this area might be to keep a "cache" of the last "N" file
handles. I suspect it's
On Thu, Jun 02, 2005 at 11:21:16PM -0400, Larry Hall wrote:
>At 09:40 PM 6/2/2005, Christopher Faylor wrote:
>>On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>>>I think you will find that the cygwin DLL (and most of the base system)
>>>you are using now was probably cross-compiled.
At 09:40 PM 6/2/2005, Christopher Faylor wrote:
>On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>>I think you will find that the cygwin DLL (and most of the base system)
>>you are using now was probably cross-compiled.
>
>Yup. And, these days, it's cross-compiled on a Debian-based
On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>I think you will find that the cygwin DLL (and most of the base system)
>you are using now was probably cross-compiled.
Yup. And, these days, it's cross-compiled on a Debian-based system.
cgf
--
Unsubscribe info: http://cygwin
Linda W wrote:
> Not everyone can do all things. I didn't "speculate" on the cause, I
> noticed multiple opens for a program that really only needs stat/lstat I
> believe.
In order to implement stat(), cygwin has to call NtQueryInformationFile
(GetFileInformationByHandle for 9x/me) and
I know, but truthfully, you are taking my response a bit out of context.
I was responding, specifically to CFG's message:
Christopher Faylor wrote:
> Yep. This is pretty much what I expected. Now we'll see a stream of
> people commenting on slowness and speculating on the cause without
> spen
60 matches
Mail list logo
