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 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
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-32id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie de...@desrt.ca
Date: Wed Aug 31 22:07:02 2011 -0400
GMain: simplify
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-32id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie de...@desrt.ca
Date: Wed Aug
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:
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:
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:
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-32id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie de...@desrt.ca
Date:
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
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
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-32id=7eae486179e2799c369ed9ffcea663bf9161ce79
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 I
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
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
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
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-32id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie de...@desrt.ca
Date: Wed Aug 31 22:07:02 2011 -0400
GMain: simplify
On 6/6/2012 7:04 AM, Stephen L wrote:
Ken Brownkbrownat 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
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-free
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
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 branch
Ken Brown kbrown at 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.
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
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
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
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
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/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
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
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
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
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
[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 Brownkbr...@cornell.edu 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
Ken Brown kbrown at 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
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
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
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
Ken Brown kbrown at 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
On 5/31/2012 4:45 AM, Stephen L wrote:
Ken Brownkbrownat 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
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
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
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
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...
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, it
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
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 kbr...@cornell.edu wrote:
On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote:
After an cygwin-upgrade this
45 matches
Mail list logo
