unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* C++ application linked with guile dos not quite
@ 2002-06-17 13:23 CDDP
  0 siblings, 0 replies; 12+ messages in thread
From: CDDP @ 2002-06-17 13:23 UTC (permalink / raw)


Hi,

In DrGenius (guile aware), when I quite, all the application is hanging.

This happens when there is a user defined guile procedure. If the user
does not define procedure this does not happen.

If I run it under GDB then the application quite normaly.

I am not very confortable with guile, so there is probably something
wrong in my code.

I use Libguile 1.4

Hilaire


For information, the related piece of code are:

I initialise the guile interprertor as:

int main(int argc, char* argv[])
{
	gh_enter(argc, argv, main_prog);
	return 0;
}


In main_prog, I record some procedures:

  /* declare drgeo interface in guile */
  gh_new_procedure ("move", drgeo_scm_move, 2, 0, 0);
  gh_new_procedure ("getAbscissa", drgeo_scm_getAbscissa, 1, 0, 0);
  gh_new_procedure ("getCoordinates", drgeo_scm_getCoordinates, 1, 0,
0);
  gh_new_procedure ("getValue", drgeo_scm_getValue, 1, 0, 0);

  [...]

  gtk_main();
}

The GTK+ application is started with gtk_main()

User script are recorded in the guile interpreter as:

void script::
setScript (gchar *scriptCode)
{
	gchar *tmpScript, *tmp1, *tmp2;
	gint nb;

	g_free (this->scriptCode);
	this->scriptCode = g_strdup (scriptCode);

	/* define a scm procedure to hold the user script */
	tmpScript = g_strdup_printf ("(define (script%d",this);
	for (nb = 1; nb <= g_list_length (parentList); nb++)
	{
		tmp1 = g_strdup_printf (" a%d", nb);
		tmp2 = g_strconcat (tmpScript, tmp1, NULL);
		g_free (tmp1);
		g_free (tmpScript);
		tmpScript = tmp2;
	}
	tmp1 = g_strconcat (tmpScript, ")", scriptCode, ")", NULL);
	g_free(tmpScript);
	/* define the procedure in the Guile interpretor */
	gh_eval_str_with_catch(tmp1, standard_handler);
	g_free (tmp1);
}

Basicly the user script is embedded in a procedure so the code is
looking like:
(define (scriptOBJECT_ADRESS a1 a2 ...)
CODE PROVIDED BY THE USER
)


Then in the geometric engine, this procedure is called as:

	/* build the call sequence */
	tmpScript = g_strdup_printf ("(script%d", this);
	for (nb = 0; nb < g_list_length (parentList); nb++)
	{
		tmp1 = g_strdup_printf (" %d", g_list_nth_data (parentList, nb));
		tmp2 = g_strconcat (tmpScript, tmp1, NULL);
		g_free (tmpScript);
		g_free (tmp1);
		tmpScript = tmp2;
	}
	tmp1 = g_strconcat (tmpScript, ")", NULL);
	g_free (tmpScript);	
	ret = gh_eval_str_with_catch(tmp1, standard_handler);
	g_free (tmp1);
	if (gh_number_p (ret))
	{
		val = gh_scm2double (ret);
		str = g_strdup_printf ("%.2f", val);
	}
	else if (gh_string_p (ret))
	{
		str = gh_scm2newstr (ret, NULL);
	}
	else
		str = g_strdup (_("Unprintable result"));
}

When the script object is deleted I undefine the function.






_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* C++ application linked with guile dos not quite
@ 2002-06-17 13:24 Hilaire Fernandes
  2002-06-18  8:25 ` CDDP 40 - TICE
  0 siblings, 1 reply; 12+ messages in thread
From: Hilaire Fernandes @ 2002-06-17 13:24 UTC (permalink / raw)


Hi,

In DrGenius (guile aware), when I quite, all the application is hanging.

This happens when there is a user defined guile procedure. If the user
does not define procedure this does not happen.

If I run it under GDB then the application quite normaly.

I am not very confortable with guile, so there is probably something
wrong in my code.

I use Libguile 1.4

Hilaire


For information, the related piece of code are:

I initialise the guile interprertor as:

int main(int argc, char* argv[])
{
        gh_enter(argc, argv, main_prog);
        return 0;
}


In main_prog, I record some procedures:

  /* declare drgeo interface in guile */
  gh_new_procedure ("move", drgeo_scm_move, 2, 0, 0);
  gh_new_procedure ("getAbscissa", drgeo_scm_getAbscissa, 1, 0, 0);
  gh_new_procedure ("getCoordinates", drgeo_scm_getCoordinates, 1, 0,
0);
  gh_new_procedure ("getValue", drgeo_scm_getValue, 1, 0, 0);

  [...]

  gtk_main();
}

The GTK+ application is started with gtk_main()

User script are recorded in the guile interpreter as:

void script::
setScript (gchar *scriptCode)
{
        gchar *tmpScript, *tmp1, *tmp2;
        gint nb;

        g_free (this->scriptCode);
        this->scriptCode = g_strdup (scriptCode);

        /* define a scm procedure to hold the user script */
        tmpScript = g_strdup_printf ("(define (script%d",this);
        for (nb = 1; nb <= g_list_length (parentList); nb++)
        {
                tmp1 = g_strdup_printf (" a%d", nb);
                tmp2 = g_strconcat (tmpScript, tmp1, NULL);
                g_free (tmp1);
                g_free (tmpScript);
                tmpScript = tmp2;
        }
        tmp1 = g_strconcat (tmpScript, ")", scriptCode, ")", NULL);
        g_free(tmpScript);
        /* define the procedure in the Guile interpretor */
        gh_eval_str_with_catch(tmp1, standard_handler);
        g_free (tmp1);
}

Basicly the user script is embedded in a procedure so the code is
looking like:
(define (scriptOBJECT_ADRESS a1 a2 ...)
CODE PROVIDED BY THE USER
)


Then in the geometric engine, this procedure is called as:

        /* build the call sequence */
        tmpScript = g_strdup_printf ("(script%d", this);
        for (nb = 0; nb < g_list_length (parentList); nb++)
        {
                tmp1 = g_strdup_printf (" %d", g_list_nth_data
(parentList, nb));
                tmp2 = g_strconcat (tmpScript, tmp1, NULL);
                g_free (tmpScript);
                g_free (tmp1);
                tmpScript = tmp2;
        }
        tmp1 = g_strconcat (tmpScript, ")", NULL);
        g_free (tmpScript);     
        ret = gh_eval_str_with_catch(tmp1, standard_handler);
        g_free (tmp1);
        if (gh_number_p (ret))
        {
                val = gh_scm2double (ret);
                str = g_strdup_printf ("%.2f", val);
        }
        else if (gh_string_p (ret))
        {
                str = gh_scm2newstr (ret, NULL);
        }
        else
                str = g_strdup (_("Unprintable result"));
}

When the script object is deleted I undefine the function.


-- 
http://www.ofset.org
Organization for Free Software in
Education and Teaching


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-17 13:24 Hilaire Fernandes
@ 2002-06-18  8:25 ` CDDP 40 - TICE
  2002-06-18 13:43   ` Brett Viren
  0 siblings, 1 reply; 12+ messages in thread
From: CDDP 40 - TICE @ 2002-06-18  8:25 UTC (permalink / raw)


When guile is embedded in a C++ aplication, is there any garbage
collection to take care of ?

Hilaire



Le lun 17/06/2002 à 15:24, Hilaire Fernandes a écrit :
> Hi,
> 
> In DrGenius (guile aware), when I quite, all the application is hanging.
> 
> This happens when there is a user defined guile procedure. If the user
> does not define procedure this does not happen.
> 
> If I run it under GDB then the application quite normaly.
> 
> I am not very confortable with guile, so there is probably something
> wrong in my code.
> 
> I use Libguile 1.4
> 
> Hilaire
> 
> 
> For information, the related piece of code are:
> 
> I initialise the guile interprertor as:
> 
> int main(int argc, char* argv[])
> {
>         gh_enter(argc, argv, main_prog);
>         return 0;
> }
> 
> 
> In main_prog, I record some procedures:
> 
>   /* declare drgeo interface in guile */
>   gh_new_procedure ("move", drgeo_scm_move, 2, 0, 0);
>   gh_new_procedure ("getAbscissa", drgeo_scm_getAbscissa, 1, 0, 0);
>   gh_new_procedure ("getCoordinates", drgeo_scm_getCoordinates, 1, 0,
> 0);
>   gh_new_procedure ("getValue", drgeo_scm_getValue, 1, 0, 0);
> 
>   [...]
> 
>   gtk_main();
> }
> 
> The GTK+ application is started with gtk_main()
> 
> User script are recorded in the guile interpreter as:
> 
> void script::
> setScript (gchar *scriptCode)
> {
>         gchar *tmpScript, *tmp1, *tmp2;
>         gint nb;
> 
>         g_free (this->scriptCode);
>         this->scriptCode = g_strdup (scriptCode);
> 
>         /* define a scm procedure to hold the user script */
>         tmpScript = g_strdup_printf ("(define (script%d",this);
>         for (nb = 1; nb <= g_list_length (parentList); nb++)
>         {
>                 tmp1 = g_strdup_printf (" a%d", nb);
>                 tmp2 = g_strconcat (tmpScript, tmp1, NULL);
>                 g_free (tmp1);
>                 g_free (tmpScript);
>                 tmpScript = tmp2;
>         }
>         tmp1 = g_strconcat (tmpScript, ")", scriptCode, ")", NULL);
>         g_free(tmpScript);
>         /* define the procedure in the Guile interpretor */
>         gh_eval_str_with_catch(tmp1, standard_handler);
>         g_free (tmp1);
> }
> 
> Basicly the user script is embedded in a procedure so the code is
> looking like:
> (define (scriptOBJECT_ADRESS a1 a2 ...)
> CODE PROVIDED BY THE USER
> )
> 
> 
> Then in the geometric engine, this procedure is called as:
> 
>         /* build the call sequence */
>         tmpScript = g_strdup_printf ("(script%d", this);
>         for (nb = 0; nb < g_list_length (parentList); nb++)
>         {
>                 tmp1 = g_strdup_printf (" %d", g_list_nth_data
> (parentList, nb));
>                 tmp2 = g_strconcat (tmpScript, tmp1, NULL);
>                 g_free (tmpScript);
>                 g_free (tmp1);
>                 tmpScript = tmp2;
>         }
>         tmp1 = g_strconcat (tmpScript, ")", NULL);
>         g_free (tmpScript);     
>         ret = gh_eval_str_with_catch(tmp1, standard_handler);
>         g_free (tmp1);
>         if (gh_number_p (ret))
>         {
>                 val = gh_scm2double (ret);
>                 str = g_strdup_printf ("%.2f", val);
>         }
>         else if (gh_string_p (ret))
>         {
>                 str = gh_scm2newstr (ret, NULL);
>         }
>         else
>                 str = g_strdup (_("Unprintable result"));
> }
> 
> When the script object is deleted I undefine the function.
> 
> 
> -- 
> http://www.ofset.org
> Organization for Free Software in
> Education and Teaching
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user
> 
-- 
Ingénierie Éducative
CDDP des Landes


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-18  8:25 ` CDDP 40 - TICE
@ 2002-06-18 13:43   ` Brett Viren
  2002-06-18 14:37     ` Hilaire Fernandes
  2002-06-18 17:26     ` Marius Vollmer
  0 siblings, 2 replies; 12+ messages in thread
From: Brett Viren @ 2002-06-18 13:43 UTC (permalink / raw)
  Cc: Guile user

CDDP 40 - TICE writes:
 > When guile is embedded in a C++ aplication, is there any garbage
 > collection to take care of ?

Nothing specific about C++, however, if you store a returned SCM value
that is not referenced by Guile, you should call scm_protect_object()
on it.  I do this for example in a strip chart that plots a guile
procedure.  I need to call scm_protect_object() when the SCM
containing the proc. is created and then scm_unprotect_object() when
my chart object dies.  I happen to store this SCM object in two places
in C++, both need "protection".

Maybe if you are calling scm_protect_object() but failing to call
scm_unprotect_object() then the garbage collector is waiting for the
reference count to go to zero?  (I'm no expert, so take this with a
grain of salt).

-Brett.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-18 13:43   ` Brett Viren
@ 2002-06-18 14:37     ` Hilaire Fernandes
  2002-06-18 14:45       ` Brett Viren
  2002-06-18 17:26     ` Marius Vollmer
  1 sibling, 1 reply; 12+ messages in thread
From: Hilaire Fernandes @ 2002-06-18 14:37 UTC (permalink / raw)
  Cc: Guile user

I do not use any scm_ methods actualy, I do not know anything about
them. I do not know if guile use it internaly then wait for it to be
unprotected.

Well I am wondering what is for scm_protect_object().
Is there some special procedure to free memory from a SCM object?
For example the value returned by a call to guile procedure?


Hilaire

Le mar 18/06/2002 à 15:43, Brett Viren a écrit :
> CDDP 40 - TICE writes:
>  > When guile is embedded in a C++ aplication, is there any garbage
>  > collection to take care of ?
> 
> Nothing specific about C++, however, if you store a returned SCM value
> that is not referenced by Guile, you should call scm_protect_object()
> on it.  I do this for example in a strip chart that plots a guile
> procedure.  I need to call scm_protect_object() when the SCM
> containing the proc. is created and then scm_unprotect_object() when
> my chart object dies.  I happen to store this SCM object in two places
> in C++, both need "protection".
> 
> Maybe if you are calling scm_protect_object() but failing to call
> scm_unprotect_object() then the garbage collector is waiting for the
> reference count to go to zero?  (I'm no expert, so take this with a
> grain of salt).
> 
> -Brett.
> 
-- 
http://www.ofset.org
Organization for Free Software in
Education and Teaching


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-18 14:37     ` Hilaire Fernandes
@ 2002-06-18 14:45       ` Brett Viren
  0 siblings, 0 replies; 12+ messages in thread
From: Brett Viren @ 2002-06-18 14:45 UTC (permalink / raw)
  Cc: Guile user

Hilaire Fernandes writes:
 > I do not use any scm_ methods actualy, I do not know anything about
 > them. I do not know if guile use it internaly then wait for it to be
 > unprotected.

I don't think there is ever a time that you must call
scm_unprotect_object() unless you explicitly called
scm_protect_object().

 > Well I am wondering what is for scm_protect_object().

You would only need scm_protect_object() on any SCM if two cases are
met:

1) you store the SCM in your C/C++ code for multiple calls to gh_ or
scm_ functions (ie, any time that a garbage collection might happen).

2) If there is any chance that all internal references to the SCM will
disappear.

Since garbage collection looks at reference counts, if your C/C++ code
is still referring to an SCM, but nothing on the guile side is, then
the ref count can go to zero and the GC thinks it's okay to reap the
SCM (since it doesn't know about your C/C++ reference).  The
protect/unprotect just increments/decrements the ref count.

 > Is there some special procedure to free memory from a SCM object?
 > For example the value returned by a call to guile procedure?

Not that I know of.  I have always done things via
scm_(un)protect_object().  

BTW, you can force a garbage collection via scm_gc().  Durring
debugging I would call this once per "cycle" of my program.  This
greatly slowed things down, but it will trigger a SegV immediately so
it is easier to know when something is going wrong.

Again, I am no expert, but since the experts seem to be quiet today, I
hope this helps.

-Brett.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-18 13:43   ` Brett Viren
  2002-06-18 14:37     ` Hilaire Fernandes
@ 2002-06-18 17:26     ` Marius Vollmer
  2002-06-19  8:02       ` CDDP 40 - TICE
  1 sibling, 1 reply; 12+ messages in thread
From: Marius Vollmer @ 2002-06-18 17:26 UTC (permalink / raw)
  Cc: CDDP 40 - TICE, Guile user

Brett Viren <bv@bnl.gov> writes:

> Maybe if you are calling scm_protect_object() but failing to call
> scm_unprotect_object() then the garbage collector is waiting for the
> reference count to go to zero?  (I'm no expert, so take this with a
> grain of salt).

No, this wont happen.  There must be some other cause.  It would help
to know in what way the application normally exits, and on what point
it stops.

I.e., does it return from gtk_main?  Or does it hang in _exit?

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-18 17:26     ` Marius Vollmer
@ 2002-06-19  8:02       ` CDDP 40 - TICE
  2002-06-19 11:14         ` Marius Vollmer
  0 siblings, 1 reply; 12+ messages in thread
From: CDDP 40 - TICE @ 2002-06-19  8:02 UTC (permalink / raw)
  Cc: Brett Viren, Guile user

Le mar 18/06/2002 à 19:26, Marius Vollmer a écrit :
> Brett Viren <bv@bnl.gov> writes:
> 
> > Maybe if you are calling scm_protect_object() but failing to call
> > scm_unprotect_object() then the garbage collector is waiting for the
> > reference count to go to zero?  (I'm no expert, so take this with a
> > grain of salt).
> 
> No, this wont happen.  There must be some other cause.  It would help
> to know in what way the application normally exits, and on what point
> it stops.
> 
> I.e., does it return from gtk_main?  Or does it hang in _exit?

Ok, here is the exact situation:


void 
main_prog(int argc, char* argv[])
{
  [..]
  gtk_main();
  g_print("Do we quit gtk_main?\n");
}

int main(int argc, char* argv[])
{
	gh_enter(argc, argv, main_prog);
	g_print ("Can we quit?");
	return 0;
}


"Do we quit gtk_main' is printed but not "Can we quit?"
But I guess "Can we quit" has not to be printed.

Also some remarks about how guile scripts are used into drgenius, guile
scripts are embedded into object plugged in a geometric figures logic
and area.
The geometric figures are user interactive, it means guile scripts are
evaluated hundred of time when the user plays interactively with the
figure. Actually I notice, DrGenius may not hang when quitting if the
user just loads a figure (with scripts) then directly quit.

(The following screenshot gives an idea how the scripts are plugged in a
figure http://www.ofset.org/drgenius/sshot4.png )

Hilaire


 
-- 
Ingénierie Éducative
CDDP des Landes


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-19  8:02       ` CDDP 40 - TICE
@ 2002-06-19 11:14         ` Marius Vollmer
  2002-06-19 13:19           ` CDDP 40 - TICE
  0 siblings, 1 reply; 12+ messages in thread
From: Marius Vollmer @ 2002-06-19 11:14 UTC (permalink / raw)
  Cc: Brett Viren, Guile user

CDDP 40 - TICE <cddp40.tice@ac-bordeaux.fr> writes:

> Ok, here is the exact situation:
> 
> 
> void 
> main_prog(int argc, char* argv[])
> {
>   [..]
>   gtk_main();
>   g_print("Do we quit gtk_main?\n");
> }
> 
> int main(int argc, char* argv[])
> {
> 	gh_enter(argc, argv, main_prog);
> 	g_print ("Can we quit?");
> 	return 0;
> }
> 
> 
> "Do we quit gtk_main' is printed but not "Can we quit?"
> But I guess "Can we quit" has not to be printed.

Is "Do we quit gtk_main" printed also when drgenius fails to exit?
Or is it printed only when drgenius does exit successfully?

(Yes, "gh_enter" does not return, it exits directly by calling
"exit(0)".)

Try to run drgenius in the debugger and when it should exit but
doesn't, hit C-C and look at the backtrace.

When that doesn't give enough ideas, set a breakpoint on the function
that should normally trigger the exit.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-19 11:14         ` Marius Vollmer
@ 2002-06-19 13:19           ` CDDP 40 - TICE
  2002-06-19 14:09             ` Brett Viren
  0 siblings, 1 reply; 12+ messages in thread
From: CDDP 40 - TICE @ 2002-06-19 13:19 UTC (permalink / raw)
  Cc: Brett Viren, Guile user

Le mer 19/06/2002 à 13:14, Marius Vollmer a écrit :
> CDDP 40 - TICE <cddp40.tice@ac-bordeaux.fr> writes:
> 
> > Ok, here is the exact situation:
> > 
> > 
> > void 
> > main_prog(int argc, char* argv[])
> > {
> >   [..]
> >   gtk_main();
> >   g_print("Do we quit gtk_main?\n");
> > }
> > 
> > int main(int argc, char* argv[])
> > {
> > 	gh_enter(argc, argv, main_prog);
> > 	g_print ("Can we quit?");
> > 	return 0;
> > }
> > 
> > 
> > "Do we quit gtk_main' is printed but not "Can we quit?"
> > But I guess "Can we quit" has not to be printed.
> 
> Is "Do we quit gtk_main" printed also when drgenius fails to exit?
> Or is it printed only when drgenius does exit successfully?


"Do we quit gtk_main" is alway printed!


> Try to run drgenius in the debugger and when it should exit but
> doesn't, hit C-C and look at the backtrace.
> 
> When that doesn't give enough ideas, set a breakpoint on the function
> that should normally trigger the exit.

I found another place where it hangs, I never notice it. It apppear also
when the user close a figure without leaving drgenius. I have been able
to trace back:

Program received signal SIGINT, Interrupt.
[Switching to Thread 1024 (LWP 27923)]
0x40802b90 in poll () from /lib/libc.so.6
(gdb) backt
#0  0x40802b90 in poll () from /lib/libc.so.6
#1  0x40622f09 in g_main_is_running () from /usr/lib/libglib-1.2.so.0
#2  0x406228bd in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#3  0x40622c6c in g_main_run () from /usr/lib/libglib-1.2.so.0
#4  0x4035c7f7 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#5  0x0805ae30 in main_prog (argc=1, argv=0xbffffc64) at
drgenius_main.c:124
#6  0x406632d1 in gh_call3 () from /usr/lib/libguile.so.9
#7  0x40666a38 in scm_boot_guile () from /usr/lib/libguile.so.9
#8  0x4068aa13 in scm_internal_lazy_catch () from /usr/lib/libguile.so.9
#9  0x406669e6 in scm_boot_guile () from /usr/lib/libguile.so.9
#10 0x406666e4 in scm_boot_guile () from /usr/lib/libguile.so.9
#11 0x40663304 in gh_enter () from /usr/lib/libguile.so.9
#12 0x0805ae5d in main (argc=1, argv=0xbffffc64) at drgenius_main.c:130

Does not help much. I try to suspect I have some memory leaks that show
up in the context of guile.
I will try to trace memory leak.

Hilaire




-- 
Ingénierie Éducative
CDDP des Landes


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-19 13:19           ` CDDP 40 - TICE
@ 2002-06-19 14:09             ` Brett Viren
  2002-06-19 16:42               ` CDDP 40 - TICE
  0 siblings, 1 reply; 12+ messages in thread
From: Brett Viren @ 2002-06-19 14:09 UTC (permalink / raw)
  Cc: Guile user

CDDP 40 - TICE writes:
 > I found another place where it hangs, I never notice it. It apppear also
 > when the user close a figure without leaving drgenius. I have been able
 > to trace back:
 > 
 > Program received signal SIGINT, Interrupt.
 > [Switching to Thread 1024 (LWP 27923)]
 > 0x40802b90 in poll () from /lib/libc.so.6
 > (gdb) backt
 > #0  0x40802b90 in poll () from /lib/libc.so.6
 > #1  0x40622f09 in g_main_is_running () from /usr/lib/libglib-1.2.so.0
 > #2  0x406228bd in g_get_current_time () from /usr/lib/libglib-1.2.so.0
 > #3  0x40622c6c in g_main_run () from /usr/lib/libglib-1.2.so.0
 > #4  0x4035c7f7 in gtk_main () from /usr/lib/libgtk-1.2.so.0
 > #5  0x0805ae30 in main_prog (argc=1, argv=0xbffffc64) at
 > drgenius_main.c:124
 > #6  0x406632d1 in gh_call3 () from /usr/lib/libguile.so.9
 > #7  0x40666a38 in scm_boot_guile () from /usr/lib/libguile.so.9
 > #8  0x4068aa13 in scm_internal_lazy_catch () from /usr/lib/libguile.so.9
 > #9  0x406669e6 in scm_boot_guile () from /usr/lib/libguile.so.9
 > #10 0x406666e4 in scm_boot_guile () from /usr/lib/libguile.so.9
 > #11 0x40663304 in gh_enter () from /usr/lib/libguile.so.9
 > #12 0x0805ae5d in main (argc=1, argv=0xbffffc64) at drgenius_main.c:130

Are you saying that you want the act of closing the window to cause
the application to quit?

If so, it sounds to me like you simply didn't connect to the window's
delete_event.  Eg:

  your_window_object.delete_event.connect(Gtk::Main::quit.slot());

(this is for gtkmm 1.2, 2.0 has slightly different syntax).

-Brett.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: C++ application linked with guile dos not quite
  2002-06-19 14:09             ` Brett Viren
@ 2002-06-19 16:42               ` CDDP 40 - TICE
  0 siblings, 0 replies; 12+ messages in thread
From: CDDP 40 - TICE @ 2002-06-19 16:42 UTC (permalink / raw)
  Cc: Guile user

Le mer 19/06/2002 à 16:09, Brett Viren a écrit :
> CDDP 40 - TICE writes:
>  > I found another place where it hangs, I never notice it. It apppear also
>  > when the user close a figure without leaving drgenius. I have been able
>  > to trace back:
>  > 
>  > Program received signal SIGINT, Interrupt.
>  > [Switching to Thread 1024 (LWP 27923)]
>  > 0x40802b90 in poll () from /lib/libc.so.6
>  > (gdb) backt
>  > #0  0x40802b90 in poll () from /lib/libc.so.6
>  > #1  0x40622f09 in g_main_is_running () from /usr/lib/libglib-1.2.so.0
>  > #2  0x406228bd in g_get_current_time () from /usr/lib/libglib-1.2.so.0
>  > #3  0x40622c6c in g_main_run () from /usr/lib/libglib-1.2.so.0
>  > #4  0x4035c7f7 in gtk_main () from /usr/lib/libgtk-1.2.so.0
>  > #5  0x0805ae30 in main_prog (argc=1, argv=0xbffffc64) at
>  > drgenius_main.c:124
>  > #6  0x406632d1 in gh_call3 () from /usr/lib/libguile.so.9
>  > #7  0x40666a38 in scm_boot_guile () from /usr/lib/libguile.so.9
>  > #8  0x4068aa13 in scm_internal_lazy_catch () from /usr/lib/libguile.so.9
>  > #9  0x406669e6 in scm_boot_guile () from /usr/lib/libguile.so.9
>  > #10 0x406666e4 in scm_boot_guile () from /usr/lib/libguile.so.9
>  > #11 0x40663304 in gh_enter () from /usr/lib/libguile.so.9
>  > #12 0x0805ae5d in main (argc=1, argv=0xbffffc64) at drgenius_main.c:130
> 
> Are you saying that you want the act of closing the window to cause
> the application to quit?

No this traceback came when a drgenius_view was closed (I use the MDI
feature from Gnome) gnome_mdi_remove_child (mdi, child, FALSE);
And in this case there is no moving windows to be closed, only the main
drgenius window that will stand.



> 
> If so, it sounds to me like you simply didn't connect to the window's
> delete_event.  Eg:
> 
>   your_window_object.delete_event.connect(Gtk::Main::quit.slot());
> 
> (this is for gtkmm 1.2, 2.0 has slightly different syntax).
> 
> -Brett.
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user
> 
-- 
Ingénierie Éducative
CDDP des Landes


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2002-06-19 16:42 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-17 13:23 C++ application linked with guile dos not quite CDDP
  -- strict thread matches above, loose matches on Subject: below --
2002-06-17 13:24 Hilaire Fernandes
2002-06-18  8:25 ` CDDP 40 - TICE
2002-06-18 13:43   ` Brett Viren
2002-06-18 14:37     ` Hilaire Fernandes
2002-06-18 14:45       ` Brett Viren
2002-06-18 17:26     ` Marius Vollmer
2002-06-19  8:02       ` CDDP 40 - TICE
2002-06-19 11:14         ` Marius Vollmer
2002-06-19 13:19           ` CDDP 40 - TICE
2002-06-19 14:09             ` Brett Viren
2002-06-19 16:42               ` CDDP 40 - TICE

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).