From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22471 invoked by alias); 11 Jun 2012 13:56:14 -0000 Received: (qmail 22447 invoked by uid 22791); 11 Jun 2012 13:56:11 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com) (209.85.214.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jun 2012 13:55:56 +0000 Received: by bkty5 with SMTP id y5so3794477bkt.2 for ; Mon, 11 Jun 2012 06:55:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.133.212 with SMTP id hz20mr10053736bkc.99.1339422954759; Mon, 11 Jun 2012 06:55:54 -0700 (PDT) Received: by 10.204.198.16 with HTTP; Mon, 11 Jun 2012 06:55:54 -0700 (PDT) In-Reply-To: <4FD53FA9.2040105@cornell.edu> References: <4FC7D9E6.5050609@alice.it> <4FCA1FF0.8090703@alice.it> <4FCA2CA9.7080704@cornell.edu> <4FCA634D.1080206@cornell.edu> <4FCB2991.3010701@users.sourceforge.net> <4FCB5438.7080903@cornell.edu> <4FCB9872.5010506@cornell.edu> <4FD1F709.4050107@cornell.edu> <87k3zhbyyk.fsf@Rainer.invalid> <4FD22C39.6070107@cornell.edu> <4FD53FA9.2040105@cornell.edu> Date: Mon, 11 Jun 2012 13:56:00 -0000 Message-ID: Subject: Re: Performance problems with emacs-X11 in current cygwin From: K Stahl To: cygwin@cygwin.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-06/txt/msg00189.txt.bz2 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/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 checked out the >>>> 2-32 branch, and I guess the next step is to find a problem-free >>>> revision of that branch, and then bisect between it and the 2.31.0 >>>> tag. I'm in the process of reading the git documentation to figure out >>>> how to do that, but I wouldn't object if someone would save me some >>>> time by giving me the appropriate git commands. >>> >>> >>> I've had a quick look at how the GNOME folks use their release branches: >>> they are tagged in master and then only some version bumping and a few >>> quickfixes. There are no odd numbered releases, so I assume they start >>> the disruptive changes right after a release, tag the unstable version >>> in master with an odd number and then work out the kinks until the new >>> release is done. >>> >>> So, you can indeed start on the 2.32 branch and then bisect down to the >>> 2.30 tag. Don't bother with the run-up between 2.31 and 2.32, just >>> bisect it whole, the bisect sequence will be just one build longer if at >>> all. >>> >>> git checkout glib-2-32 >>> git bisect start bad >>> git bisect good 2.30.3 >>> >>> If any of the intermediate versions doesn't build, say >>> >>> git bisect skip >>> >>> with the offending commit still checked out. >> >> >> 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. > > > The bisection shows that the first problematic commit is this one: > > http://git.gnome.org/browse/glib/commit/?h=3Dglib-2-32&id=3D7eae486179e27= 99c369ed9ffcea663bf9161ce79 > > Author: Ryan Lortie > Date: =A0 Wed Aug 31 22:07:02 2011 -0400 > > =A0 =A0GMain: simplify logic for g_wakeup_acknowledge() > > =A0 =A0Instead of messing around with context->poll_waiting, just look at= the > GPollFD to see if the GWakeup needs to be acknowledged. > > In case anyone else wants to confirm this, you can get my glib builds by > running > > =A0setup.exe -K http://sanibeltranquility.com/cygwin/kbrown.gpg > > and adding http://sanibeltranquility.com/cygwin to the list of mirrors. = =A0The > problematic version is > > =A0libglib2.0_0-2.30.90_7eae4861-1 > > and the preceding version (without the problem) is > > =A0libglib2.0_0-2.30.90_87880df-1 > > I've tested the latter with emacs-23, emacs-24, and gvim. > > > Ken > > -- > Problem reports: =A0 =A0 =A0 http://cygwin.com/problems.html > FAQ: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://cygwin.com/faq/ > Documentation: =A0 =A0 =A0 =A0 http://cygwin.com/docs.html > Unsubscribe info: =A0 =A0 =A0http://cygwin.com/ml/#unsubscribe-simple > -- 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