g_warning throws core dump with a <> while g_info does not Why?
Hello,
I have a multithread program and I use to log over glib. Using
g_warning, g_info, etc convenience macros. I investigated and the only
difference between them is the log level used. Something is what I want.
The problem is that if I use g_warning to highlight connection problems
in my program it coredumps, but it I use g_info it works flawlesly.
And a trap message is shown when using g_warning. The output is just that:
G_MESSAGES_DEBUG=all ./testgpsd
/Gpsd/Test60Seconds: **
(/home/gaguilar/workspace-c/sg64-thrift-c_glib-server/src/test/.libs/testgpsd:21759):
DEBUG: We must create a thread to process incomming messages on client
** INFO: Thread created for the client
**
(/home/gaguilar/workspace-c/sg64-thrift-c_glib-server/src/test/.libs/testgpsd:21759):
WARNING **: sg64_gpsd_handler: Error while waiting on thread for GPSD
«trap» para punto de parada/seguimiento (`core' generado)
For the main loop on the thread:
while (!self->request_exit) {
if(!gps_waiting(>gpsdata, 5)){
g_warning ("sg64_gpsd_handler: Error while waiting on thread
for GPSD");
// g_info ("sg64_gpsd_handler: Error while waiting on thread for
GPSD"); < If I put this it works!
// self->request_exit=TRUE;
}else{
if (gps_read(>gpsdata) == -1) {
g_warning ("sg64_gpsd_handler: %s",
"Error while reading on thread GPSD");
g_mutex_lock (>mutex_settings);
self->request_exit=TRUE;
g_mutex_unlock (>mutex_settings);
}else{
// Get the time if possible
if (isnan(self->gpsdata.fix.time) == 0) {
(void)unix_to_iso8601(self->gpsdata.fix.time, scr, sizeof(scr));
printf("Current time %s\n", scr);
}
/* Fill in the latitude. */
if (self->gpsdata.fix.mode >= MODE_2D) {
if(isnan(self->gpsdata.fix.latitude) == 0){
(void)snprintf(scr, sizeof(scr), "%s %c",
deg_to_str(deg_dd, fabs(self->gpsdata.fix.latitude)),
(self->gpsdata.fix.latitude < 0) ? 'S' : 'N');
printf("Current lat %s\n", scr);
}
/* Fill in the longitude. */
if (isnan(self->gpsdata.fix.longitude) == 0) {
(void)snprintf(scr, sizeof(scr), "%s %c",
deg_to_str(deg_dd, fabs(self->gpsdata.fix.longitude)),
(self->gpsdata.fix.longitude < 0) ? 'W' : 'E');
printf("Current lon %s\n", scr);
}
/* Fill in the speed. */
if (isnan(self->gpsdata.fix.track) == 0){
(void)snprintf(scr, sizeof(scr), "%.1f %s",
self->gpsdata.fix.speed, "m/s");
printf("Current speed %s\n", scr);
}
/* Fill in the heading. */
if (isnan(self->gpsdata.fix.track) == 0) {
double magheading = true2magnetic(self->gpsdata.fix.latitude,
self->gpsdata.fix.longitude,
self->gpsdata.fix.track);
if (!magnetic_flag || isnan(magheading) != 0) {
(void)snprintf(scr, sizeof(scr), "%.1f deg (true)",
self->gpsdata.fix.track);
} else {
(void)snprintf(scr, sizeof(scr), "%.1f deg (mag) ",
magheading);
}
printf("Current heading %s\n", scr);
}
}
/* Fill in the altitude. */
if (self->gpsdata.fix.mode >= MODE_3D){
if(isnan(self->gpsdata.fix.altitude) == 0){
(void)snprintf(scr, sizeof(scr), "%.1f %s",
self->gpsdata.fix.altitude, "m");
}
}
}
}
}
When working with g_info the output is this one:
/Gpsd/Test60Seconds: **
(/home/gaguilar/workspace-c/sg64-thrift-c_glib-server/src/test/.libs/testgpsd:22552):
DEBUG: We must create a thread to process incomming messages on client
** INFO: Thread created for the client
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler: Error while waiting on thread for GPSD
** INFO: sg64_gpsd_handler:
Gobject decorator -> How to deal with properties
Hello,
I'm writting a decorator pattern for a protocol in Thrift that's based
on c_glib. One of the cases I found is that you can have this:
// From Thrift code:
/*!
* Thrift Protocol Decorator instance.
*/
struct _ThriftProtocolDecorator
{
ThriftProtocol parent;
ThriftProtocol *concrete_protocol;
};
typedef struct _ThriftProtocolDecoratorClass ThriftProtocolDecoratorClass;
That's a class that implements an interface but when a method is called,
it really calls the concrete_protocol method. That's nice. It works but
when dealing with properties that's a new history.
For example you can decorate a concrete_protocol that has a property
called "transport" but when the code does something like:
g_object_get(decorated_protocol, "transport", , NULL);
glib will search over the decorator class installed properties that's
not what I want. I resolved hacking a known property install and trying
to find its values on
concrete_protocol.
Something like this:
In the init class
// TODO Ugly hack, in theory we must override all properties from
underlaying
// protocol
thrift_stored_message_protocol_obj_properties[PROP_THRIFT_STORED_MESSAGE_PROTOCOL_TRANSPORT]
=
g_param_spec_pointer ("transport",
"Transport on the underlaying implementation",
"Transport of decorated protocol",
G_PARAM_READABLE);
In the getter function
case PROP_THRIFT_STORED_MESSAGE_PROTOCOL_TRANSPORT:
// FIXME Since we don't override properties in the decorator as
it should
// we just override the properties that we know are used
g_object_get(decorator->concrete_protocol,pspec->name, , NULL);
g_value_set_pointer (value, transport);
break;
But it will fail if it asks for other property of the concrete_protocol
instance. So the question is:
Is there any way to install all properties installed on the
concrete_protocol? So I can override the "Getter" and "Setter" and
fordward the request to the decorated instance?
Best regards,
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Fwd: RE: Pthread lock on g_once_init_enter (_define_type_id__volatile) **Important Information**
Please remove this spam address no_re...@2020mobile.com <no_re...@2020mobile.com> Or the one subscribed to the list. Mensaje reenviado Asunto: RE: Pthread lock on g_once_init_enter (_define_type_id__volatile) **Important Information** Fecha: 6 Oct 2015 09:36:48 +0100 De: no_re...@2020mobile.com <no_re...@2020mobile.com> Para: Gonzalo Aguilar Delgado <gagui...@aguilardelgado.com> Thank you for your email. You are receiving this automatic reply because you sent a message to gtk-list@gnome.org *_Please be aware that all @2020mobile.com email addresses have now been replaced with the @brightstar.com email domain suffix._* Your original email has been automatically forwarded to the correct Brightstar email address. To ensure all future emails to this recipient are delivered please update your address book to reflect the recipients brightstar.com email address. If you are unsure of the recipient's Brightstar email address please contact the recipient for details of the correct address. Be aware that as of 31^st October 2015, the above referenced forwarding action will be turned off and non-deliverable messages will be issued. For any concerns or queries please contact the servicedesk atservicedesk...@brightstar.com <mailto:servicedesk...@brightstar.com>. Thank you ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Pthread lock on g_once_init_enter (_define_type_id__volatile)
Hello,
Maybe someone here can help me. I defined a subclass of another existing
class.
Basicly:
typedef struct _ThriftSSLSocket ThriftSSLSocket;
struct _ThriftSSLSocket
{
ThriftSocket parent;
/* private */
};
typedef struct _ThriftSSLSocketClass ThriftSSLSocketClass;
struct _ThriftSSLSocketClass
{
ThriftSocketClass parent;
};
// More code here
And in the C file I'm defining this new type:
G_DEFINE_TYPE(ThriftSSLSocket, thrift_ssl_socket, THRIFT_TYPE_SSL_SOCKET)
// More code here
Looks good sofar. But when I do:
object = g_object_new (THRIFT_TYPE_SSL_SOCKET, NULL);
It stalls waiting for the macro expansion here:
|||static| |volatile| |gsize g_define_type_id__volatile = 0; |
|||if| |(g_once_init_enter (_define_type_id__volatile)) {
<--- Because a thread lock.
|
|||GType g_define_type_id = |
The question is why? Maybe the base class is not derivable?
Best regards,
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Pthread lock on g_once_init_enter (_define_type_id__volatile) [RESOLVED]
Hello again,
I discovered what happened. The function generated get_type was calling
itself. So double initialization, and the second one on the same thread
was stopped because the thread lock.
The error was here
G_DEFINE_TYPE(ThriftSSLSocket, thrift_ssl_socket, THRIFT_TYPE_SSL_SOCKET)
It was instanciating a subclass of itself. Should be like this:
G_DEFINE_TYPE(ThriftSSLSocket, thrift_ssl_socket, THRIFT_TYPE_SOCKET)
Thank you for the help.
El 06/10/15 a las 10:36, Gonzalo Aguilar Delgado escribió:
Hello,
Maybe someone here can help me. I defined a subclass of another
existing class.
Basicly:
typedef struct _ThriftSSLSocket ThriftSSLSocket;
struct _ThriftSSLSocket
{
ThriftSocket parent;
/* private */
};
typedef struct _ThriftSSLSocketClass ThriftSSLSocketClass;
struct _ThriftSSLSocketClass
{
ThriftSocketClass parent;
};
// More code here
And in the C file I'm defining this new type:
G_DEFINE_TYPE(ThriftSSLSocket, thrift_ssl_socket, THRIFT_TYPE_SSL_SOCKET)
// More code here
Looks good sofar. But when I do:
object = g_object_new (THRIFT_TYPE_SSL_SOCKET, NULL);
It stalls waiting for the macro expansion here:
|||static| |volatile| |gsize g_define_type_id__volatile = 0; |
|||if| |(g_once_init_enter (_define_type_id__volatile)) {
<<<<<--- Because a thread lock.
|
|||GType g_define_type_id = |
The question is why? Maybe the base class is not derivable?
Best regards,
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
GtkTreeView and Hinting
Hello all. I'm doing an App that uses GtkTreeView a lot... I read the EXCELENT GtkTreeView tutorial and helping me a lot but... In: http://scentric.net/tutorial/sec-treeview-col-whole-row.html Says that instead of changing backgroud color (I want to change it to reflect rows changed) I should use hinting... How can I map properties to change hinting as says in the previous paragraph? gtk_tree_view_column_add_attribute(col, renderer, background-set, COL_MODIFIED); I've done already changing backgroud to default color... This is horrible as default color is black... Tnx so much! -- Gonzalo Aguilar Delgado - Ingeniero en Informática [ Seguridad Medios de pago ] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Callbacks and widgets
This way is one of the best I found. Ensures compatibility and as you said performance impact is minimum. Anyway, I found that using a mix of this way and using user data to set widget pointers is a tradeof between performance and memory consumption. So I set the widget dependencies with: g_object_set_data(G_OBJECT(accept),PROFILE_TREEVIEW,(gpointer)treeview); for the main widgets, and search for the secondaries... This works like a charm and don't have to be searching for the most used widgets... Thank you all for your great help!!! I have a 4th way to offer. I also use to access arbitrary widgets from within widget's signal handlers frequently. I don't keep all widgets to be reachable as global variables nor do I define or pass any data structures to the handlers. My way has proven to be quite comfortable at source level, since the only precaution you need to take is to assign names to those widgets you want to refer to, and to provide just one globally accessable variable per window. The tiny performance impact by this function is absolutely negligible at runtime, even if you perform 100 widget searches in a row. http://www.spamkiller.bytechase.cx/democode/widget_find_by_name.c ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Gonzalo Aguilar Delgado - Ingeniero en Informática [ Seguridad Medios de pago ] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Callbacks and widgets
Hi, stefan. This looks also good but it's a pain to have to instanciate every widget. But for some special widgets may be a great solution... Thank you for your reply. hi, Gonzalo Aguilar Delgado wrote: Yep, I know about some of them: 1.- Passing a data structure 2.- Using global variables (not good threading support) 3.- Passing window to gpointer and searching. 4.- Use GObjects for you UI In my apps I don't directly insert e.g. a gtk_hbox, but derive a class from it (e.g. MyOptionGroup) and this class has aditional datafields. The callback gets the pointer to the instance of the MyOptionGroup as user_data. Stefan But the point is. What is the best way? Is there any other way to do that? Because structure option looks more suitable for different data to be passed not just widgets... I tried to set the widgets as user-data of the widget to be triggered. But it seems not to work. I will look anyway in the older mailing list. Thank you. On Tue, Mar 28, 2006 at 09:38:20AM +0200, Gonzalo Aguilar Delgado wrote: Because receiver callback is getting only the receiver widget, In addition, the callback gets an arbitrary pointer passed as user_data to g_signal_connect(). A pointer can be used to pass anything. This is a very frequently asked question, search the archives for discussion... Yeti -- That's enough. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Gonzalo Aguilar Delgado - Ingeniero en Informática [ Seguridad Medios de pago ] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
About widgets and callbacks...
Hello all! I have a question about how to deal with widget interaction inside callbacks... Supose I have a TreeView and a Button in a glade GUI (or Manual gui), each one far from the other... (Separated) When I click in the button. How can I get a reference from the TreeView? Because trasversing all the GTK tree can be a pain... -- Gonzalo Aguilar Delgado - Ingeniero en Informática [ Seguridad Medios de pago ] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
