headers
Johan Ur Riise | 15 Mar 2009 15:51
Picon

Hangs when closing app.

Now I have a real app going. Next problem: 
I want to do something resembling the :pulse-image in test-gtk, that
is a widget that changes text depending on some cell.

The difference here is that it depends on a cell in its own instance,
but I get the same problem if I put it in another instance, like in the
app itself or in a global instance of a specially designed class.

This is a minimal app showing the problem. Setting of the value works,
and the display is changed, But when I close the app, it hangs. 
If I just close it without executing the setf, it closes normally.
Any ideas?

(cells:defmodel statebar (cgtk:hbox) 
  ((busy :accessor busy :initform (cells:c-in nil)))
  (:default-initargs
      :md-name :statebar
      :kids (cgtk:kids-list?
             (cgtk:mk-label :text (if (busy cells:self) "Busy"
"NotBusy"))
             (cgtk:mk-label :markup (cgtk:with-markup (:background (if
(busy cells:self) :yellow :brown))
                            (if (busy cells:self) "Busy" "NotBusy"))))))

(cells:defmodel my-app (cells-gtk:gtk-app)
  ()
  (:default-initargs
    :kids (cells:c? (cells:the-kids 
                     (cells-gtk:mk-vbox 
                      :kids  (cells-gtk:kids-list?
(Continue reading)

Permalink | Reply |
headers
Ramarren | 15 Mar 2009 16:30
Picon
Gravatar

Re: Hangs when closing app.

On Sun, Mar 15, 2009 at 3:51 PM, Johan Ur Riise <johan <at> riise-data.no> wrote:
> #|
> (cells-gtk:start-app 'my-app)
> |#
>
> #|
> (cgtk:with-widget (w :statebar) (setf (busy w) t))
> |#

On my system at least cells-gtk:start-app blocks the repl, so how
would you set the widget after that? When using cells-gtk:start-win it
closes normally in both cases.

Anyway, as far as I can tell, cells have no thread-safety at all. The
GTK parts do have locks to guarantee at most one thread accesses them
at a time, but as far as I can tell the cells system doesn't, and it
is quite possible to cause two conflicting datapulses, which means
that all cell access, even with models completely separate from
cells-gtk, have to be done through cells-gtk:with-gdk-threads. But
this doesn't seem to related to your problem.

Regards,
Jakub Higersberger
Permalink | Reply |
headers
Johan Ur Riise | 16 Mar 2009 00:34
Picon

Re: Hangs when closing app.

sø., 15.03.2009 kl. 16.30 +0100, skrev Ramarren:
> On Sun, Mar 15, 2009 at 3:51 PM, Johan Ur Riise <johan <at> riise-data.no> wrote:
> > #|
> > (cells-gtk:start-app 'my-app)
> > |#
> >
> > #|
> > (cgtk:with-widget (w :statebar) (setf (busy w) t))
> > |#
> 
> On my system at least cells-gtk:start-app blocks the repl, so how
> would you set the widget after that? 
I used slime, and executed one in the repl and one by C-x C-e in the
source window. That means two threads, but I also tried enclosing the
setf in cells-gtk:with-gdk-threads, with the same result

> When using cells-gtk:start-win it
> closes normally in both cases.

That is a lead, could be threads problem. Using start-win does not make
a difference.

> Anyway, as far as I can tell, cells have no thread-safety at all. The
> GTK parts do have locks to guarantee at most one thread accesses them
> at a time, but as far as I can tell the cells system doesn't, and it
> is quite possible to cause two conflicting datapulses, which means
> that all cell access, even with models completely separate from
> cells-gtk, have to be done through cells-gtk:with-gdk-threads. But
> this doesn't seem to related to your problem.
(Continue reading)

Permalink | Reply |
headers
Ramarren | 16 Mar 2009 08:07
Picon
Gravatar

Re: Hangs when closing app.

On Mon, Mar 16, 2009 at 12:34 AM, Johan Ur Riise <johan <at> riise-data.no> wrote:
> * libGL error: open DRM failed (Operation not permitted)
> libGL error: reverting to (slow) indirect rendering

I think that is unrelated OpenGL initialization message coming from
gtkglext being loaded. Under slime it just goes into *inferior-lisp*.

At least now I know why I couldn't replicate your problem earlier.
Since I was not particularly interested in cells debug info and didn't
understand most of it anyway, and there was apparently no way to turn
it off, I modified tracing macros to expand to null in the cells
branch I normally use: http://github.com/Ramarren/cells/tree/nogtkspam
.

The problem seems to be that somehow the system tries to print a cell
element which no longer exists, and hence fails. Or something... I
don't really see, how this can happen. No, what actually happens is
that somewhere *print-readably* is set to true, and since c-link
objects are objects, they cannot be printed readably and error occurs.
What I don't see is where... Ah, bordeaux-threads for some reason
overrides standard special variables. I suppose it makes some sort of
sense. It seems to have changed a few months ago.

Sorry for the stream of consciousness. I pushed the solution to this
problem into my cells-gtk3 repo on github.

Regards,
Jakub Higersberger
(Continue reading)

Permalink | Reply |
headers
Johan Ur Riise | 16 Mar 2009 20:54
Picon

Re: Hangs when closing app.

ma., 16.03.2009 kl. 08.07 +0100, skrev Ramarren:
> On Mon, Mar 16, 2009 at 12:34 AM, Johan Ur Riise <johan <at> riise-data.no> wrote:
> > * libGL error: open DRM failed (Operation not permitted)
> > libGL error: reverting to (slow) indirect rendering
> 
> I think that is unrelated OpenGL initialization message coming from
> gtkglext being loaded. Under slime it just goes into *inferior-lisp*.
> 
> At least now I know why I couldn't replicate your problem earlier.
> Since I was not particularly interested in cells debug info and didn't
> understand most of it anyway, and there was apparently no way to turn
> it off, I modified tracing macros to expand to null in the cells
> branch I normally use: http://github.com/Ramarren/cells/tree/nogtkspam
> .
> 
> The problem seems to be that somehow the system tries to print a cell
> element which no longer exists, and hence fails. Or something... I
> don't really see, how this can happen. No, what actually happens is
> that somewhere *print-readably* is set to true, and since c-link
> objects are objects, they cannot be printed readably and error occurs.
> What I don't see is where... Ah, bordeaux-threads for some reason
> overrides standard special variables. I suppose it makes some sort of
> sense. It seems to have changed a few months ago.
> 
> Sorry for the stream of consciousness. I pushed the solution to this
> problem into my cells-gtk3 repo on github.
> 
> Regards,
> Jakub Higersberger
>
(Continue reading)

Permalink | Reply |

Gmane