Re: [chris@beezer.med.miami.edu: Re: What's wrong with bluefish?]
Hello,
I'm one of the upstream developers for bluefish and I have been notified
that there have been compile problems on the Alpha architecture. If I am
correct, this is an example of the code that has been causing all this
trouble:
{"/Tags/Special/Other/Soft hypen", NULL, insert_char, (int) "­", NULL},
this is how that works (from the GTK site)...
-- begin gtk.org's stuff --
Item 1: The menu path. The letter after the underscore indicates an
accelerator key once the menu is open.
Item 2: The accelerator key for the entry
Item 3: The callback function.
Item 4: The callback action. This changes the parameters with
which the function is called. The default is 0.
Item 5: The item type, used to define what kind of an item it is.
Here are the possible values:
NULL -> "<Item>"
"" -> "<Item>"
"<Title>" -> create a title item
"<Item>" -> create a simple item
"<CheckItem>" -> create a check item
"<ToggleItem>" -> create a toggle item
"<RadioItem>" -> create a radio item
<path> -> path of a radio item to link against
"<Separator>" -> create a separator
"<Branch>" -> create an item to hold sub items (optional)
"<LastBranch>" -> create a right justified branch
-- end gtk.org's stuff --
Item 4 seems to be what screws up the Alpha compiles. Here's how I got it
to work the way I needed it to...
Item 4 wants an int, I needed to put a string there because it would
simplify things GREATLY. After trying various things, it somehow worked by
casting the char* to int because it got cast back to a char* somewhere
withing GTK. I still do not know how this worked.
This is what happens without the cast to int...
In file included from toolbars.c:41:
menu.h:86: warning: initialization makes integer from pointer without a cast
It still works on my system, but having appx 400 warnings pop up during a
compile is not something I like to see, esp when it works if I do a cheesy
hack like casting it to an int. ;)
The GTK stuff says that using gint is more portable than using just
straight int. So if someone wants to try that as a fix, then run "sed
s/(int)/(gint)/ menu.h". I'm not sure if that will do much other than just
cast it back to regular int. It might work, who knows.
I'm pretty clueless about this as the highest bit processor I have worked
with is 32 and I can't test for stuff like this. I really need to get an
alpha... hehe.
-Chris Mazuc
On Mon, 12 Jul 1999, Antti-Juhani Kaijanaho wrote:
> ----- Forwarded message from Christopher C Chimelis <chris@beezer.med.miami.edu> -----
>
> Date: Mon, 12 Jul 1999 13:20:35 -0400 (EDT)
> From: Christopher C Chimelis <chris@beezer.med.miami.edu>
> To: Antti-Juhani Kaijanaho <gaia@iki.fi>
> cc: debian-alpha@lists.debian.org
> Subject: Re: What's wrong with bluefish?
>
>
> On Mon, 12 Jul 1999, Antti-Juhani Kaijanaho wrote:
>
> > If it turns out to be a bug in the code, please file a report in the BTS.
>
> Will do. I'm not too familiar with GTK programming, though, so if you
> can, explain to me what exactly the menu.h file is supposed to be
> providing? It will save me a few steps in figuring this out. I'm
> guessing now that the compiler may be thinking that the & is referring to
> a memory location rather than a string (if that's what it's supposed to
> be).
>
> C
>
>
> ----- End forwarded message -----
>
> --
> %%% Antti-Juhani Kaijanaho % gaia@iki.fi % http://www.iki.fi/gaia/ %%%
>
> "... memory leaks are quite acceptable in many applications ..."
> (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
>
Reply to: