X-Recipient:	archive-cygwin AT delorie DOT com
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
MIME-Version:	1.0
In-Reply-To:	<4FD53FA9.2040105@cornell.edu>
References:	<4FC7D9E6 DOT 5050609 AT alice DOT it> <4FCA1FF0 DOT 8090703 AT alice DOT it> <4FCA2CA9 DOT 7080704 AT cornell DOT edu> <4FCA634D DOT 1080206 AT cornell DOT edu> <4FCB2991 DOT 3010701 AT users DOT sourceforge DOT net> <4FCB5438 DOT 7080903 AT cornell DOT edu> <4FCB9872 DOT 5010506 AT cornell DOT edu> <loom DOT 20120606T123651-460 AT post DOT gmane DOT org> <4FD1F709 DOT 4050107 AT cornell DOT edu> <87k3zhbyyk DOT fsf AT Rainer DOT invalid> <4FD22C39 DOT 6070107 AT cornell DOT edu> <4FD53FA9 DOT 2040105 AT cornell DOT edu>
Date:	Mon, 11 Jun 2012 09:55:54 -0400
Message-ID:	<CAMK_jUUEdws1YMomkjQ8bHcrm7xYwC_qBB3KAH29DNO-mk+EiA@mail.gmail.com>
Subject:	Re: Performance problems with emacs-X11 in current cygwin
From:	K Stahl <kdstahl AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id q5BDuNR3017688

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 <kbrown AT cornell DOT edu> 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=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>
> Author: Ryan Lortie <desrt AT desrt DOT ca>
> Date:   Wed Aug 31 22:07:02 2011 -0400
>
>    GMain: simplify logic for g_wakeup_acknowledge()
>
>    Instead 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
>
>  setup.exe -K http://sanibeltranquility.com/cygwin/kbrown.gpg
>
> and adding http://sanibeltranquility.com/cygwin to the list of mirrors.  The
> problematic version is
>
>  libglib2.0_0-2.30.90_7eae4861-1
>
> and the preceding version (without the problem) is
>
>  libglib2.0_0-2.30.90_87880df-1
>
> I've tested the latter with emacs-23, emacs-24, and gvim.
>
>
> Ken
>
> --
> 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
>

--
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

- Raw text -