GTK pipe
hello every1,
i'm trying to capture stdout.stderr of a child prosses while using gtk. i'v
found the following codes and i changed it a little and it works perfect:
void run_program( char *cmd)
{
gintstdin_pipe[2];
gintstdout_pipe[2];
gintstderr_pipe[2];
/* Define buffs to copy your reads from the pipes to */
gchar buffer[BUFSIZ+1];
gchar buffer_err[BUFSIZ+1];
/* Def some vars to hold your results */
gint fork_result;
gint data_processed;
gint data_processed_err;
gint nchars;
nchars=0;
/* Clear Your Buffers */
memset(buffer, '\0', sizeof(buffer));
memset(buffer_err, '\0', sizeof(buffer_err));
/* Do the fork and pipe - watch closely here */
/* Create pipes to read from and write too */
if( (pipe(stdin_pipe) == 0)
(pipe(stdout_pipe) == 0)
(pipe(stderr_pipe) == 0)
)
{
/* Perform the fork */
fork_result = fork();
/* fork attempt was not successful */
if(fork_result == -1)
{
fprintf(stderr, Fork Failure\n);
exit(EXIT_FAILURE);
}
/* We're in the child process! */
else if(fork_result == 0)
{
/* Close the Child process' STDIN */
close(0);
/* Duplicate the Child's STDIN to the stdin_pipe file descriptor
*/
dup(stdin_pipe[0]);
/* Close the read and write to for the pipe for the child. The
child will now only be able to read from it's STDIN (which is our pipe). */
close(stdin_pipe[0]);
close(stdin_pipe[1]);
/* Close the Child process' STDOUT */
close(1);
dup(stdout_pipe[1]);
close(stdout_pipe[0]);
close(stdout_pipe[1]);
/* Close the Child process' STDERR */
close(2);
dup(stderr_pipe[1]);
close(stderr_pipe[0]);
close(stderr_pipe[1]);
/* Make the system call to run the program. */
system(cmd);
/* If javac didn't take over the exec call failed. */
exit(EXIT_FAILURE);
}
/* We're in the parent process. */
else
{
/* Close STDIN for read write and close STDERR for write */
close(stdin_pipe[0]);
close(stdin_pipe[1]);
close(stderr_pipe[1]);
while(1)
{
data_processed_err=read(stderr_pipe[0],buffer_err,BUFSIZ);
if(data_processed_err == 0) break;
//addMsgInfo( buffer_err );
Msg_dialog(Error,buffer_err);
}
/* Close the read end of STDERR */
close(stderr_pipe[0]);
/* Close the write end of STDOUT */
close(stdout_pipe[1]);
while(1)
{
/* Read BUFSIZ of STDOUT data */
data_processed=read(stdout_pipe[0],buffer,BUFSIZ);
/* Break this loop when we're read all of the STDOUT data */
if(data_processed == 0) break;
/* Insert it into our gtktextbox */
addMsgInfo( buffer );
}
/* Close STDOUT for reading */
close(stdout_pipe[0]);
}
}
}
but if i call the following function (clicking that button):
void on_button1_clicked(GtkButton *button, gpointer user_data){
GtkWidget *dialog;
GtkFileFilter *filter = gtk_file_filter_new ();
GtkFileFilter *filter2 = gtk_file_filter_new ();
GtkWidget *parent = lookup_widget(GTK_WIDGET(button), win);
GtkWidget *entry = lookup_widget(GTK_WIDGET(button), entry1);
dialog = gtk_file_chooser_dialog_new (Open Image File,
parent,
GTK_FILE_CHOOSER_ACTION_OPEN,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
NULL);
gtk_file_filter_set_name(filter,Iso Files);
gtk_file_filter_set_name(filter2,All Files);
gtk_file_filter_add_pattern (filter, *.iso);
gtk_file_filter_add_pattern (filter2, *.*);
gtk_file_chooser_add_filter (GTK_FILE_CHOOSER (dialog), filter);
gtk_file_chooser_add_filter (GTK_FILE_CHOOSER (dialog), filter2);
if (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_ACCEPT)
{
char *filename;
filename = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER (dialog));
gtk_entry_set_text(GTK_ENTRY(entry),filename);
g_free (filename);
}
gtk_widget_destroy (dialog);
}
befor using the first one my program chrashes. has anyone any idea? i can't
actually find any relationship bitween these two functions. but with a
little experiment i realized it crashesh if i make any dialog (filechooser
or not) in my programm.
thankx
Ammsa
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Events and derived objects
I'm using in my application a subclassed object (a subclass of HBox) that contains a TextView widget (and some other things not relevant here). What I'd like to do, with regard to key presses, is the following: 1. Almost all basic keys (letters, cursor movement, etc) should still be handled by the TextView so that it behaves normally. 2. A couple of keys would be captured by the derived object itself (notably, ENTER will have a special action), and do some internal action. 3. Everything else should be propagated so that the user of this derived widget can connect a handler to key-press-event and add special actions for even more keys. I've achieved capturing some specials keys, but letting everything else work as normally in the TextView by connecting a handler to a key-press-event of the TextView inside the derived widget's implementation, but I have'nt discovered how to propagate keys unhandled by the TextView itself or by my special handler to the user. -- Eduardo M Kalinowski [EMAIL PROTECTED] http://move.to/hpkb ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
re: SPAM LOW Re: Top Window Background
Yeah, when I use the gtk_widget_modify_bg(GTK_WIDGET(window), GTK_STATE_NORMAL, color), the background color does not change, even if I use it with all GTK_STATE_...s. Andy From: Andreas Stricker [EMAIL PROTECTED] Sent: Wednesday, December 14, 2005 3:01 AM To: gtk-app-devel-list@gnome.org Subject: SPAM LOW Re: Top Window Background Andy Grebe wrote: I've got a callback function where I want to change the background of the entire window. I can set the color on startup using: style = gtk_widget_get_style(topWindow); style-bg[0] = c; style-bg[1] = c; style-bg[2] = c; style-bg[3] = c; style-bg[4] = c; gtk_widget_set_style(topWindow, style); but when I attempt to change the color of the background in a callback function, it doesn't work. I've also tried the modify_bg function with the same results. The right approch is indeed gtk_widget_modify_bg(): GdkColor color; gdk_color_parse(red, color); gtk_widget_modify_bg(GTK_WIDGET(window), GTK_STATE_NORMAL, color); Note that the widget must be in the right state. Cheers, Andy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
re: Reference to a C++ object in GTK+ callbacks
Paul,
As it has been said, your function needs to have the correct format, i.e.
gboolean play_cb (GtkWidget *widget, gpointer ptr) {}
Andy
From: Paul Santa Maria [EMAIL PROTECTED]
Sent: Tuesday, December 13, 2005 7:01 PM
To: gtk-app-devel-list@gnome.org
Subject: Reference to a C++ object in GTK+ callbacks
Hi -
I'm using the GTK+ 2.6.4 that came with Suse 9.3. I'm coding in C++, but using
the raw GTK+ C
libraries.
I'm trying to pass a pointer to one of my C++ classes into a callback, so that
I can call a method
on that class. The code looks like this:
1. less hbaview.h =
--
class HbaviewApp
{
...
private:
AnimationFile *m_animation;
...
class Hbafile : public AnimationFile
{
public:
Hbafile (GtkWidget *da);
virtual ~Hbafile ();
virtual void open (const char *fname);
virtual void close ();
virtual void start ();
...
2. less HbaviewApp.cpp =
---
void init ()
...
GtkWidget *play =
gtk_image_menu_item_new_from_stock (
gtk-media-play, accel_group);
gtk_widget_show (play);
gtk_container_add (GTK_CONTAINER (menu3), play);
gtk_signal_connect (GTK_OBJECT (play), activate,
G_CALLBACK (play_cb), m_animation);
...
3. less callbacks.cpp =
--
gboolean
play_cb (gpointer data)
{
// Deference the object pointer to do the actual work
AnimationFile *ani = (AnimationFile *)data;
ani-start ();
}
ani-start() works fine outside of the callback. I know my Animation object
has been
successfully created and that m_animation points to it before I call
gtk_signal_connect().
But it crashes with a signal SIGSEGV, Segmentation fault when the play_cb
callback tries to call
ani-start().
Any idea what I might be doing wrong?
Or tips for debugging the problem?
Thanx in advance!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Events and derived objects
Eduardo M Kalinowski wrote: [...] I've achieved capturing some specials keys, but letting everything else work as normally in the TextView by connecting a handler to a key-press-event of the TextView inside the derived widget's implementation, but I have'nt discovered how to propagate keys unhandled by the TextView itself or by my special handler to the user. If the user wants to treat events that are not handled by the widget's event handler, they'll have to use g_signal_connect_after (or the appropriate flag), otherwise the handler will be called before the default widget's handler. So the normal chain would be: my_ojbect_key_press (connected to textview delagate's key-press-event) key_press_cb(connected by the user using g_signal_connect) textview_key_press (base class handler) after_key_press_cb (connected by the user using g_signal_connect_after) And ofcourse, the first handler to return TRUE effectively stops the emission. Another approach would be to derive an object from GtkTextView, override the base class handler for class-key_press_event and from your key_press_event; decide if you want to: return GTK_WIDGET_CLASS (parent_class)-key_press_event (widget, event); Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/2005 11:19 AM, Stephen Pollei wrote:
On 12/13/05, Daryl Lee [EMAIL PROTECTED] wrote:
Are you sure that is the right style for that callback?
static void
rocket_cb(GtkWidget *widget, GdkEventExpose *event, gpointer data)
{
class city_node *city=static_castclass city_node *(data);
global_game.rocket_up(*city);
city-update_targets();
each_tick(NULL);
}
C++ functions do, indeed, have to be static to be used as GTK+
callbacks.
Untrue I just removed the static keyword from 8 of my callbacks and
then recompiled, worked just fine. As Andy Grebe of apogeelabs said
... function needs to have the correct format.
That I bet was the problem. That I label a lot of my callbacks with
static, I just consider good style.
diff -u1 gtk_main.cc-save gtk_main.cc static-out.diff
The only c++ problem I can see is if you had overloaded functions; I
can't think of how you'd select which one you meant.
IIRC, I believe the functions only have to be static in this case if
they're actually C++ class methods. Plain old C global functions don't
need to be static, though if they're only used in that one module,
there's no reason *not* to make them static, and it's good practice to
do so.
-brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDoHJ16XyW6VEeAnsRAiaqAJ0fCFNpf1k/+OSTqtxHUpDdKuD6QACfSkJT
3iqrkpsHfNp4+XzAnyLq+so=
=BnXm
-END PGP SIGNATURE-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
Well, thanks for the correction. I will have to go back through my projects to understand why I thought that. On Wed, 2005-12-14 at 11:19 -0800, Stephen Pollei wrote: On 12/13/05, Daryl Lee [EMAIL PROTECTED] wrote: ... C++ functions do, indeed, have to be static to be used as GTK+ callbacks. Untrue I just removed the static keyword from 8 of my callbacks and then recompiled, worked just fine. ... -- Daryl Lee Open the Present--It's a Gift. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ for Windows: issues with apps locating the dll's
On 12/14/05, Gnaural [EMAIL PROTECTED] wrote: Does anyone here know why the GTK+ windows apps would give-up before even getting to either my main() (or WinMain())? If a library (dll) that your executable is linked against is not found, the executable cannot be run. You're trying to specify the library path after it has already tried to load the library. The way that gaim's loader works is that the initial executable is a small application that is linked only with System Libraries - it then sets up the appropriate path and dynamically loads a (gtk+ dependent) dll containing the bulk of the application. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
On Wed, 2005-12-14 at 11:28 -0800, Brian J. Tarricone wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... IIRC, I believe the functions only have to be static in this case if they're actually C++ class methods. Plain old C global functions don't need to be static, though if they're only used in that one module, there's no reason *not* to make them static, and it's good practice to do so. True. the static keyword is 'overloaded' with a different meaning - it doesn't change scope, but indicates that the function is one that doesn't have an associated object. // Wally ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
On Wednesday 14 December 2005 20:38, Wallace Owen wrote:
[snip]
Warning!
It may work for you. It's not portable. C++ implementations are free
to use a calling convention different from the C calling convention: In
C, parameters are pushed in reverse order to support varargs. C++
functions are specified in the standard as not supporting varargs so
that compiler vendors are free to use certain optimizations. For
example, in C, it's the caller's responsibility to clean up the stack
after a call because the called function can't know at compile time how
many parms were passed. C++ compilers are free to optimize this such
that the called function does the stack cleanup, so that a function
that's called from many different places only has one stack cleanup
chunk generated.
It's for this reason that a static function should be used to catch
callbacks, so it can cast the parameter to a pointer to the object, then
invoke the member function. Static member functions don't have an
implied first parm that's it's object. See below:
class Foo
{
public:
static redrawCB(Event *event, void *parm)
{
Foo *obj = reinterpret_castFoo*(parm);
obj-redraw(event);
}
redraw(Event *event)
{
...
}
};
Your version isn't portable either. GTK+ callbacks required C linkage, so to
be portable your code should provide C linkage, and static member functions
cannot have C linkage. This means that to be portable the callback has to be
declared extern C in file scope (and if it needs access to the class's
internals, needs to be declared a friend in the class definition).
Paragraph 7.5.1 of the standard says this:
All function types, function names, and variable names have a language
linkage. The default language linkage of all function types, function names,
and variable names is C++ language linkage. Two function types with
different language linkages are distinct types even if they are otherwise
identical.
Static member functions happen to work with g++. They may not work with other
compilers.
Chris
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
activeX embedding
Does anyone know if it is possible to embed an activeX control in a GTK+ app? In particular the mozilla control or if I get desperate enough the IE one? For win32 so gtkmozembed is out although I'll probably use that when I port to linux. Thanks guys. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ for Windows: issues with apps locating the dll's
Gnaural writes: One glitch, though. I'm finding that my GTK+ apps don't automaticaly find the installed GTK+ dll's in Windows. The lazy solution was just to set the system PATH variable to point to the GTK+ bin directory. But I've been informed that this is bad practice, because of (among other things) something called dll hell. Umm, dunno. I would say that setting PATH to include the bin folder of the GTK+ installation you want to use is quite straightforward. It's when users start copying DLLs here and there and then forgetting where they are, and messing with PATH so that they don't know what copies of the DLLs they really are using that you get DLL hell. You could always write a minimal (a dozen of lines) helper exe that sets the PATH environment variable and then invokes you real application. Does anyone here know why the GTK+ windows apps would give-up before even getting to either my main() (or WinMain())? Well, if the exe requires on DLLs that aren't found, it will never get to main() (or WinMain()). The DLLs that an exe links to are loaded by the system before the program starts executing user code. And is there another, more straightforward way people are accomplishing this (besides either setting the system PATH or using some very fudgy-looking platform-dependent registry code to find the dll's)? You could keep your application's exe in the same bin folder where the GTK+ (Pango, atk, GLib etc) DLLs are. Then they will be found without any PATH manipulation. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
Thank you on all counts!
The main problem was my callback (duh! I forgot the GtkWidget *w argument!);
I also changed all
my gtk_signal_connect() calls to g_signal_connect(), and all my
gtk_signal_connect_object()
to g_signal_connect_swapped().
It works fine now - thanx again!
--- Stephen Pollei [EMAIL PROTECTED] wrote:
On 12/13/05, Paul Santa Maria [EMAIL PROTECTED] wrote:
I'm coding in C++, but using the raw GTK+ C
libraries.
I'm doing similiar for a game I'm making.
--
gboolean
play_cb (gpointer data)
{
// Deference the object pointer to do the actual work
AnimationFile *ani = (AnimationFile *)data;
ani-start ();
}
Are you sure that is the right style for that callback?
static void
rocket_cb(GtkWidget *widget, GdkEventExpose *event, gpointer data)
{
class city_node *city=static_castclass city_node *(data);
global_game.rocket_up(*city);
city-update_targets();
each_tick(NULL);
}
is what I have for one of my callbacks.
Maybe do a printf(%p,ani); and a printf(%p,m_animation);
to really make sure they point to the same thing.
ani-start() works fine outside of the callback. I know my Animation
object has been
successfully created and that m_animation points to it before I call
gtk_signal_connect().
Good does ani point to the same thing once inside the callback as
m_animation points to outside the callback?
--
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ for Windows: issues with apps locating the dll's
Gnaural wrote: First of all, big thanks to Tor Lillqvist and everyone else involved in the GTK+ for Windows port. Because of the GTK+, Glib, the MinGW cross-compiler, and WINE, I never have to leave Linux (or even own a Windows box) to make some Windows users happy! I love that -- in fact, it is the main feature that's made me commit to GTK+. [snip] I've found out that if the user install a GTK+ Runtime (such as the one found at http://gimp-win.sourceforge.net/), GTk+ apps find the necessary dlls just fine. Another option is Application Paths - they are registry keys for you application that set a path were it can find DLL's. It's better than setting the global PATH environment variable. If your program uses a installer, you'd set this registry key during installation. Google for more details since I don't know exactly where the keys should be and how that works. -- He's dead, Jim. Eduardo M KALINOWSKI [EMAIL PROTECTED] http://move.to/hpkb ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ for Windows: issues with apps locating the dll's
Eduardo M KALINOWSKI [EMAIL PROTECTED] wrote: ... Another option is Application Paths - they are registry keys for you application that set a path were it can find DLL's. It's better than setting the global PATH environment variable. If your program uses a installer, you'd set this registry key during installation. ... Great tip - you got me to look in to the freeware installer Inno Setup, which will handle all the registry stuff I'd like to keep out of my core code, and (with the help of a simple script I found in this list) checks to see if GTK+ 2.0 is installed and gives me the path to it. Which I can then put in a string named Path under my app's key here: HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\MyApp.exe And thanks also to the other two replies. I hadn't realized that all the libs an exe was linked-with needed to be available at the exe's launch, and also hadn't yet figured out that Gaim was running itself as a dll once a it's launcher established that GTK+ was available. Creative solution! Now win_gaim.c makes a lot more sense for me. BTW, with all that solved, I am still a bit mystified by one thing I mentioned in my last email (and don't want to start another thread unless someone else thinks this is important): Why are Gimp's GTK+ runtime 2.6.9 unuseable under WINE (even a standard GTK+ Hello World is all black on all Debian/Ubuntu boxes I tried), while Gaim's GTK+ runtime 2.6.9-rev-a work great? Tonight, as an experiment, I tried Gimp's GTK+ 2.8.7 runtime -- which ALMOST works in WINE, but still has big black splotches over it. What is the relationship between the two packages? Do the Gaim developers just modify current stable packages offered at Gimp site, or are they developing their own line independently? Both seem to work fine enough in Windows; it only matters for me because WINE is a crucial part of my development process, since all preliminary debugging happens through it. Thanks again, people. You've helped a lot. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: linking / performance / interposing detection ...
On Tue, 2005-12-13 at 12:16 -0600, Federico Mena Quintero wrote: On Fri, 2005-12-09 at 14:36 +, michael meeks wrote: So - as part of my -Bdirect work - trying to detect genuine cases of interposing - I ran my simple perl script over all my gnome libraries: http://go-oo.org/ooo-build/bin/finterpose (for which I attach the gnome specific exclusions file [this incidentally shows lots of other bad behavior in Gnome ;-]): Very neat. How do interposed symbols happen? Is it just people forgetting to put a static somewhere? That seems to be the case for parent_class in metal_gtk2_engine.c. I vaguely recall fixing that in some other theme engine at one point - it was causing crashes when you changed from that theme to another theme and back again, I think. So, yeah, it does cause problems. Cheers, Mark. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
Murray Cumming wrote: Murray Cumming wrote: On Tue, 13 Dec 2005, Murray Cumming wrote: In GTK+ 2.9, GTK_FLOATING is deprecated and README.in states that it can no longer be used to detect floating objects. I hope nobody is using that. I assume that effort was made to avoid this ABI breakage. But does this also mean that setting GTK_FLOATING has no effect with 2.9? right, since the floating flag is stored in GObject in 2.9, so altering the GtkObject won't have any effect. Eek. This is where we discover who else uses that. Are you saying that you are manually tweaking the value of GTK_FLOATING, rather than using g_object_ref() / gtk_object_sink() pair? Yes, we are using GTK_OBJECT_SET_FLAGS(objcet, GTK_FLOATING). I'm not sure of any alternative to that, without glib 2.9. g_object_ref() + gtk_object_sink() goes in the other direction. It's not the most fun part of the gtkmm code. Okay. The approach I took in Python was to try and remove the floating flag as soon as possible -- never to refloat objects. James. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: inlining glib functions (Was: public barrier functions)
On Tue, 2005-12-13 at 22:13 +0100, Tim Janik wrote:
On Tue, 13 Dec 2005, Gustavo J. A. M. Carneiro wrote:
Ter, 2005-12-13 às 17:11 +0100, Tim Janik escreveu:
IMHO, some functions are obvious candidates for inlining, regardless
of any profiling done on them. For instance:
gchar*
g_strdup (const gchar *str)
{
gchar *new_str;
gsize length;
if (str)
{
length = strlen (str) + 1;
new_str = g_new (char, length);
memcpy (new_str, str, length);
}
else
new_str = NULL;
return new_str;
}
This function is trivial. I doubt you'll ever find any new bugs in it.
It is called in many places. So why pay a performance penalty when you
could easily avoid it?
inlining doesn't automatically mean performance improvements and
not inlining doesn't automatically cause performance penalties.
if you start to inline lots of widely used small functions in
non performance critical code sections, all you've gained is a
bigger code section size and less likelyness for warm instruction
caches (that becomes especially critical when starting to bloat
tight loops due to inlining).
now consider that 90% of a programs runtime is spent in 10% of its
code, that means 90% of your inlininig does ocoour in non performance
critical sections.
that's why modern compilers use tunable heuristics to decide about
automated inlining and don't stupidly inline everything they can.
I personally would not say to inline every trivial function in GLib, I
was talking about single-instruction functions that are not inlined
right now, it might even be possible that the call instruction itself is
longer than the instruction itself, not to mention that functions linked
in from shared libraries jump twice to reach the actual body of the
function. (first call to a stub which jumps to the function itself), so
it effectively empties the instruction pipeline twice.
Nevertheless I shut up and post patches :) Thanks for the information
and sorry for the noise.
--
Bazsi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
On Wed, 14 Dec 2005, Murray Cumming wrote: Murray Cumming wrote: On Tue, 13 Dec 2005, Murray Cumming wrote: In GTK+ 2.9, GTK_FLOATING is deprecated and README.in states that it can no longer be used to detect floating objects. I hope nobody is using that. I assume that effort was made to avoid this ABI breakage. But does this also mean that setting GTK_FLOATING has no effect with 2.9? right, since the floating flag is stored in GObject in 2.9, so altering the GtkObject won't have any effect. Eek. This is where we discover who else uses that. Are you saying that you are manually tweaking the value of GTK_FLOATING, rather than using g_object_ref() / gtk_object_sink() pair? Yes, we are using GTK_OBJECT_SET_FLAGS(objcet, GTK_FLOATING). I'm not sure of any alternative to that, without glib 2.9. g_object_ref() + gtk_object_sink() goes in the other direction. It's not the most fun part of the gtkmm code. before starting to investigate in ugly hacks to continue maintaining the current GTK_FLOATING semantics with GtkObject, i'd really like to raise the issue that people/langauge bnindings most probably never should be setting GTK_FLOATING with GTK_OBJECT_SET_FLAGS. besides the obvious implementation, the only case i saw so far where this was need is in GtkMenu. so, could you please outline why you need this in GtkMM (especially considering that james gets along without it in python)? Murray Cumming [EMAIL PROTECTED] --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
could you please outline why you need this in GtkMM By default, gtkmm _Widgets_ are not owned by their containers, because that would not allow regular C++ memory management. For instance: Gtk::VBox* box1 = new Gtk::VBox; Gtk::Button button(Hello); box1.pack_start(button); //The button is in box1. delete box1; Gtk::VBox* box2 = new Gtk::VBox; box2.pack_start(button); //Now the button is in box2. At best we'd have to have separate lifetimes for gtkmm objects and their underlying GTK+ objects, meaning that we'd have the annoying concept of invalid gtkmm objects. This works and is not something I'm going to debate. However, containers-owning-children is useful, as long as it's not the default. So, we have a Gtk::manage() function that makes objects floating again. For instance: Gtk::VBox* box = new Gtk::VBox; Gtk::Button* button = Gtk::manage(new Gtk::Button(Hello)); box.pack_start(button); //The button is in box1 (and owned by box1) delete box; //button has now been deleted (by the box), and I shouldn't use it anymore unless I like segfaults. So, we need to re-float the object when we use Gtk::manage(). Hence the use of GTK_OBJECT_SET_FLAGS(object, GTK_FLOATING) For (not important) completeness, here's a link to the source of the Object::set_manage() function where this happens: in gtkmm 2.8: http://cvs.gnome.org/viewcvs/gtkmm/gtk/src/object.ccg?rev=1.7only_with_tag=gtkmm-2-8view=markup and in gtkmm 2.9, using the new glib 2.9 API: http://cvs.gnome.org/viewcvs/gtkmm/gtk/src/object.ccg?view=markup (especially considering that james gets along without it in python)? I guess reference-counting/garbage-collection is the default (only?) memory management used in Python. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set/get_flags() (Re: GTK_FLOATING broken in 2.9?)
On 12/14/05, Tim Janik [EMAIL PROTECTED] wrote: On Tue, 13 Dec 2005, Matthias Clasen wrote: On 12/13/05, Murray Cumming [EMAIL PROTECTED] wrote: gtkmm 2.8 depends on glib/gtk 2.8, right? then you don't have g_object_force_floating() there. would it be of any help to you if glib 2.8 had g_object_force_floating() already (whether function or not)? Yes, or something in GTK+. Though it would be an act of desparation. One could conceivably modify GTK_OBJECT_SET_FLAGS to do the right thing for floating, but direct setting/checking of the flag is not fixable.hm.my take on this is that the only way to go this route would be along thelines of introducing:voidgtk_widget_set_flags (GtkWidget *widget, guint64 flags); guint64 gtk_widget_get_flags (GtkWidget *widget);/* this is reflected by ::notify::flags */and *deprecating* GTK_OBJECT_SET_FLAGS(), GTK_OBJECT_GET_FLAGS(),GTK_WIDGET_SET_FLAGS() and GTK_WIDGET_GET_FLAGS() while changing their implementations to use gtk_widget_*et_flags().for most flags, modification through GTK_OBJECT_SET_FLAGS() already is wrongand you should use proeprties instead.Coincidentally, we have an old bug about deprecating GTK_WIDGET_SET_FLAGS() and replacing them all by properties...bug 69872.Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
Tim Janik said: so, could you please outline why you need this in GtkMM (especially considering that james gets along without it in python)? metooThe perl bindings also sink all GtkObjects that get a perl wrapper attached, as the perl wrapper holds a real reference in all cases, and owns the return values of constructors called by perl. GtkObjects are never re-floated./metoo -- muppet scott at asofyet dot org ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk+2.8.x and cairo
Hi, There is a rather significant cairo bug that can cause all gtk+2 based apps to sefault upon startup in some X server setups. The problem can be seen across archs (sparc/sparc64/macppc/i386) and OS's and seems to be easist to reproduce when the X server is at Depth 8. I know this is a cairo bug, but it effects all gtk+2.8.x based applications when a machine happens to be configured such that the bug it hit. In some cases it is not possible to configure the X server to avoid the bug, so it makes all gtk+2 apps not useable. I'm writing this list in an attempt to raise awareness of the bug. https://bugs.freedesktop.org/show_bug.cgi?id=4505 Thanks, -Kurt ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
On Wed, 2005-12-14 at 13:42 -0600, Federico Mena Quintero wrote: From the point of view of the release team, We Cannot Break Existing Code(tm). By corollary, we need to avoid doing interesting stuff in macros, since they essentially embed parts of the ABI in compiled code. We already had one such problem in another ocassion; I think it had to do with mutex functions or warnings or something. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
The problem you are thinking about is probably the fact that g_return_if_fail is a very widely used macro that started to use a new symbol at some point,g_return_if_fail_warning(), thus immediately making everything compiled against the new glib depend on the new ABI. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
On Wed, 2005-12-14 at 14:51 -0500, Matthias Clasen wrote: The problem you are thinking about is probably the fact that g_return_if_fail is a very widely used macro that started to use a new symbol at some point, g_return_if_fail_warning(), thus immediately making everything compiled against the new glib depend on the new ABI. Yeah, that was it. This makes it really hard for people to do the build-on-new-gtk, run-on-old-gtk thing. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+2.8.x and cairo
On Wed, 2005-12-14 at 14:26 -0500, Kurt Miller wrote: Hi, There is a rather significant cairo bug that can cause all gtk+2 based apps to sefault upon startup in some X server setups. The problem can be seen across archs (sparc/sparc64/macppc/i386) and OS's and seems to be easist to reproduce when the X server is at Depth 8. I know this is a cairo bug, but it effects all gtk+2.8.x based applications when a machine happens to be configured such that the bug it hit. In some cases it is not possible to configure the X server to avoid the bug, so it makes all gtk+2 apps not useable. I'm writing this list in an attempt to raise awareness of the bug. https://bugs.freedesktop.org/show_bug.cgi?id=4505 I'd basically consider GTK+-2.8 to require something better than 8pp; I know there are people who love to get new software running on ancient hardware, but PseudoColor really is a different and complex world. Getting PseudoColor support working reasonably was one of the most time-consuming parts of GTK+-0.9x development. (And the CPU that goes along with that vintage of hardware is going to perform pretty badly for Cairo ...) That being said, it really shouldn't segfault; but it's not something within what the scope of the Cairo developers test on or can support themselves. If you catch up with Keith Packard on #cairo, I think he had some ideas about how PseudoColor could be supported in cairo without causing excessive complexity to leak into the normal code. If the issue is 8/24 hardware defaulting to 8bpp, then it might make sense to have some environment variable or XSetting to make the GTK+ default visual the GdkRGB visual rather than the system visual. Regards, Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
On Wed, 2005-12-14 at 14:56 -0500, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote: Yes, we do really need the floating reference. There is no reason to discourage the code you mentioned when you want to make reusable container objects that have a sane API without requiring the caller to do a bunch of work and potentially introduce bugs. When you are calling your own code, it is not that much to keep track of, but when I write code that is used by 1000 developers it is much easier for me to take care of the reference issues inside the API and make the large group of unknown developers free from unknowingly creating reference counting bugs. Okay. So how do we do it without breaking the ABI? The fact that this ABI is so low down in the stack means that things become *really hard* in the upper layers. How do we build applications against a new Glib (without using new APIs), especially GTK+ applications, and yet be able to run them on older versions of Glib? How do we avoid breaking existing apps which use GtkObject's floating stuff, and have them run unchanged on a newer Glib? Remember that GNOME 2.14 will use GTK+ *2.8*, but Glib *2.10*. We can't break that code. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Helping on reducing evolution memory usage
On Wed, 2005-12-14 at 19:17 -0500, Morten Welinder wrote: --enable-purify is the one for ORBit at least. Didn't know there was one for glib. What exactly does --enable-gc-friendly=yes do? It clears memory held in pools so old pointers does not confuse memory debuggers. The docs (http://developer.gnome.org/doc/API/2.0/glib/glib-building.html) say this: --disable-gc-friendly and --enable-gc-friendly. When enabled all memory freed by the application, but retained by GLib for performance reasons is set to zero, thus making deployed garbage collection or memory profiling tools detect unlinked memory correctly. This will make GLib slightly slower and is thus disabled by default. This could be more specific: - When shrinking a GArray, it zeros out the memory no longer available in the array: shrink an array from 10 bytes to 7, and the last 3 bytes will be cleared. This includes removals of single and multiple elements. - When growing a GArray, it clears the new chunk of memory. Grow an array from 7 bytes to 10 bytes, and the last 3 bytes will be cleared. - The above applies to GPtrArray as well. - When freeing a node from a GHashTable, it first clears the node (which used to point to the key and the value stored at that node). - When destroying or removing a GTree node, it clears the node (which used to point to the value, and the left and right subnodes). (I've just committed the text above to the documentation.) In Glib 2.12, this also applied to freeing a GList/GSList node, and to creating/freeing GMemChunk blocks. It's a shame that we don't have that in HEAD. Which brings us to... Note, the glib head has no way of disabling pools. Before the most recen tthings, one could use --disable-mem-pools and be happy. Indeed. And now, the documentation for --disable-mem-pools is incorrect, since it does nothing now. This is all easy to fix, of course, and we need to do it before the final 2.10. One thing I absolutely loathe, though, is to have to *recompile glib* just to be able to run valgrind on GNOME programs. I'd really prefer to set G_DEBUG=gc-friendly and just run my software with that. To avoid calling getenv() all over the place, I'd like to have a private g_ensure_debug() macro and possibly others to access a global _g_enable_gc_friendly variable. This would ensure that we have called gmessages.c:_g_debug_init(), so that the debug variables are set. Thoughts? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Helping on reducing evolution memory usage
On 12/14/05, Federico Mena Quintero [EMAIL PROTECTED] wrote: Note, the glib head has no way of disabling pools.Before the most recen tthings, one could use --disable-mem-pools and be happy.Indeed.And now, the documentation for --disable-mem-pools is incorrect, since it does nothing now.This is all easy to fix, of course, and we need to do it before thefinal 2.10.One thing I absolutely loathe, though, is to have to *recompile glib*just to be able to run valgrind on GNOME programs.I'd really prefer to set G_DEBUG=gc-friendly and just run my software with that.To avoid calling getenv() all over the place, I'd like to have a privateg_ensure_debug() macro and possibly others to access a global_g_enable_gc_friendly variable.This would ensure that we have called gmessages.c:_g_debug_init(), so that the debug variables are set.Thoughts?You want to check out g_slice_set_config(), which allows you to turn off various aspects of the slice allocator. I believe timj also has plans for making this runtime-configurable with an env var.Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
On 12/14/05, Federico Mena Quintero [EMAIL PROTECTED] wrote: Okay.So how do we do it without breaking the ABI?The fact that this ABI is so low down in the stack means that thingsbecome *really hard* in the upper layers.How do we build applications against a new Glib (without using new APIs), especially GTK+ applications, and yet be able to run them onolder versions of Glib?This has never been supported. How do we avoid breaking existing apps which use GtkObject's floatingstuff, and have them run unchanged on a newer Glib?This is what we need to figure out. Remember that GNOME 2.14 will use GTK+ *2.8*, but Glib *2.10*.We can'tbreak that code.There is no problem in this combination. GTK+ 2.8 continues to use the GtkObject floating flag,and does not care about the GObject floating flag at all. We decided to allow finalizing floating GObjects, so there is no problem.Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Re: GTK_FLOATING broken in 2.9?
ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote: When you are calling your own code, it is not that much to keep track of, but when I write code that is used by 1000 developers it is much easier for me to take care of the reference issues inside the API and make the large group of unknown developers free from unknowingly creating reference counting bugs. So, the thousands of another developers now will have to check documentation for any GObject-derived class to figure out whether they own reference or not. This is exactly why it's good when you invent your wrappers, where it's clear that wrapper is made for purpose and one might be interested in what that wrapper does. So, if before the usage pattern was: object = create_object (); ... g_object_unref (object); /* I do know I own it */ now it will be object = create_object (); g_object_ref_sink (object); /* who knows what will happen in ... */ ... g_object_unref (object); Is it really good for glib, the library which is used by all people using glib, not just those 1000 unknown developers who are not aware of the need to free allocated memory? These arguments about bugs and stuff are good arguments about why one should use C++ or whatever other language with some sort of automatic memory management. C is known not to be safe, and it's known that you must be careful. After introducing floating references one will still need to be as careful, but he also will need to check one more thing - floating reference (or sink it as soon as possible). Maybe real solution would be for those 1000 guys to use mono or something? In short, it's nice that glib will be more safe for those who do not check what his code does, but if one tries to write safe code, he'll get one more headache. Regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
