[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] More 2.6 patches and a (maybe) a small speedup to neural

From: Øystein Johansen
Subject: Re: [Bug-gnubg] More 2.6 patches and a (maybe) a small speedup to neuralnet.c
Date: Fri, 25 Feb 2005 00:53:00 +0100
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)

Hash: SHA1

macherius wrote:
| Hi,
| please find attached another patch towards better 2.6 conformance.
| Here is what it does:
| 1. Invisible EventBoxes
| Made all EventBoxes invisible, by this removing dark grey artifacts
| in the display. You can easily spot them e.g. in the
| "Settings->Options" dialog. See
|  ndow With the patch, the artifacts are gone.

I see! This looks better indeed. I thought this artifacts was a bug in
the theme...

| Note: This was introduced in 2.4.0, so I used #if
| GTK_CHECK_VERSION(2,4,0) rather than #if HAVE_GTK2 for a reason.

Probably smart!

| 2. Corrected cast Macro for Progress bar
| Small glitch in Oysteins Progress bar patch, with a cast macro.
| Replaced GTK_PROGRESS(...) with GTK_PROGRESS_BAR(...) in the 2.x
| branch.


| 3. Test balloon: Combobox vs. MenuChooser
| I've replace one MenuChooser (deprecated) with a ComboBox to study
| effort and effect. It's the one in
| "Settings->Options->Tutor->Warning". Result: Looks a bit different,
| otherwise no big advantage. I had hoped the unusual drop-down
| behaviour would change, but it does not. Seems ComboBox has some
| issues as well, and a look into the Gtk Bugzilla confirms it (use
| keyword "ComboBox"). Nevertheless, there is hope that ComboBox get's
| bugfixes while I doubt MenuChooser will.

s/MenuChooser/OptionMenu/g   ??

I believe we should convert to ComboBox if we can.

| Note: Again this is a 2.4 extension, so I've flagged it with #if
| GTK_CHECK_VERSION(2,4,0). I abstained from using 2.6 methods to keep
| it working for the major Linux distributions, which ship with 2.4.


| 4. Blast support changed from runtime to compile time
| As discussed in earlier mail, I've removed an unconditional branch in
|  neuralnet.c. Blast support is now detected and activated at compile
| time only, hopefully saving a tiny amount of runtime CPU. Otherwise
| the control flow is absolutely unchanged. And while I was in that
| file, I made some #if to kill unused code, namely
| NeuralNetCreateDirect is nowonly compild in if MMAP support is
| actually there and the Blast variants are only compiled it LIBATLAS
| support is there. Reduces code size without any cost.

Does anyone use the BLAS implementation? I think it was added mostly for
the experiment.

- -Øystein
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]