From rpavlik at gmail.com  Mon Aug 22 23:18:27 2011
From: rpavlik at gmail.com (Ryan Pavlik)
Date: Mon, 22 Aug 2011 18:18:27 -0500
Subject: [cl-gtk2-devel] GBoxed, signals, and dnd
Message-ID: <CAFYWPBijYyXQdqSBPn44rPa25BS=wDNTu1rhxSk3FPuZn7DJuw@mail.gmail.com>

I'm currently working on implementing the calls necessary for DND on
the gtk side.  For the most part, this has been relatively
straightforward; I can receive drop data and initiate drags.

However, the critical part for initiated drags is setting
selection-data in the drag-data-get signal handler.  This requires you
to alter the passed selection-data in response; however, the changes
don't appear to be copied out.  How can I accomplish this?

It appears that glib-defcallback is defined for a related purpose, but
this doesn't seem useful in conjunction with signal handlers.

thanks,

-- 
Ryan Pavlik <rpavlik at gmail.com>



From psilord at cs.wisc.edu  Wed Aug 24 00:02:21 2011
From: psilord at cs.wisc.edu (Peter Keller)
Date: Tue, 23 Aug 2011 19:02:21 -0500
Subject: [cl-gtk2-devel] debugging cl-gtk applications
Message-ID: <20110824000221.GA21837@cs.wisc.edu>

Hello,

When I use cl-gtk with sbcl, sometimes I write a bug where I define a
slot with an incorrect signature.

What SBCL does at this point is that the thread containing the wrong code
dumps a message (usually "wrong number of arguments 2", etc being the
entirety of it even with debug and safety at 3 and speed optimize at 0)
and stops, but the REPL apparently doesn't notice.

So, I then have this stopped thread hanging out in the background. How
does one access the correct thread to figure out a backtrace for the
failure?

Thank you.

-pete



From mathrick at gmail.com  Wed Aug 24 13:25:45 2011
From: mathrick at gmail.com (Maciej Katafiasz)
Date: Wed, 24 Aug 2011 15:25:45 +0200
Subject: [cl-gtk2-devel] debugging cl-gtk applications
In-Reply-To: <20110824000221.GA21837@cs.wisc.edu>
References: <20110824000221.GA21837@cs.wisc.edu>
Message-ID: <CAGNGd0rmzPgfFe623LJ6Rq-o_A03tHhbBErkNcaxqd7AxwVajg@mail.gmail.com>

On Wed, Aug 24, 2011 at 02:02, Peter Keller <psilord at cs.wisc.edu> wrote:
> When I use cl-gtk with sbcl, sometimes I write a bug where I define a
> slot with an incorrect signature.
>
> What SBCL does at this point is that the thread containing the wrong code
> dumps a message (usually "wrong number of arguments 2", etc being the
> entirety of it even with debug and safety at 3 and speed optimize at 0)
> and stops, but the REPL apparently doesn't notice.
>
> So, I then have this stopped thread hanging out in the background. How
> does one access the correct thread to figure out a backtrace for the
> failure?

Which platform are you using? There are two things to consider here:

1) Win32 threading support is still pretty experimental, and there are
many things from the surrounding assumptions (such as signal handling
and the lack thereof on Windows, coupled with the fact that SLIME
sends C-c on break request, which will kill SBCL because it doesn't
register a proper Win32 handler( that simply haven't been updated to
match Win32. The introspection bits can also be somewhat subpar
compared to Linux, which will hurt you when trying to determine a
non-obvious crash. That said, I've had quite good results getting GTK+
to work on Win32, and that's including breaking and debugger
signalling.

2) On Linux there's currently an undetermined SBCL bug which somehow
manifests itself very often in presence of semi-complex CL-GTK2 code.
The end result is that after the first time the offending code is
executed, thread handling fails silently and catastrophically,
including the complete inability to interrupt other threads (which
also precludes the debugger from noticing anything going wrong). It's
very possible that you're seeing this. In this case, there's not much
to be done except a long and torturous debugging session to fix SBCL.
Perhaps trying the same on CCL instead could help in the short term,
but I must admit that I've only thought about migrating my code to
CCL, not actually done so. Another not-really workaround is to restart
SBCL and make sure you only run the suspect on a completely fresh
image, *once*. If you do go down that route, you really, really want
to SAVE-LISP-AND-DIE with as much of everything preloaded as possible.

Hope this helps,
Maciej



From psilord at cs.wisc.edu  Wed Aug 24 15:10:23 2011
From: psilord at cs.wisc.edu (Peter Keller)
Date: Wed, 24 Aug 2011 10:10:23 -0500
Subject: [cl-gtk2-devel] debugging cl-gtk applications
In-Reply-To: <CAGNGd0rmzPgfFe623LJ6Rq-o_A03tHhbBErkNcaxqd7AxwVajg@mail.gmail.com>
References: <20110824000221.GA21837@cs.wisc.edu>
	<CAGNGd0rmzPgfFe623LJ6Rq-o_A03tHhbBErkNcaxqd7AxwVajg@mail.gmail.com>
Message-ID: <20110824151022.GA7804@cs.wisc.edu>

On Wed, Aug 24, 2011 at 03:25:45PM +0200, Maciej Katafiasz wrote:
> On Wed, Aug 24, 2011 at 02:02, Peter Keller <psilord at cs.wisc.edu> wrote:
> > When I use cl-gtk with sbcl, sometimes I write a bug where I define a
> > slot with an incorrect signature.
> >
> > What SBCL does at this point is that the thread containing the wrong code
> > dumps a message (usually "wrong number of arguments 2", etc being the
> > entirety of it even with debug and safety at 3 and speed optimize at 0)
> > and stops, but the REPL apparently doesn't notice.
> >
> > So, I then have this stopped thread hanging out in the background. How
> > does one access the correct thread to figure out a backtrace for the
> > failure?
> 
> Which platform are you using? 

Linux primarily, however the windows knowledge you provided is very useful
as I was hoping my code could be run on a windows machine as well.

> There are two things to consider here:
> 
> 2) On Linux there's currently an undetermined SBCL bug which somehow
> manifests itself very often in presence of semi-complex CL-GTK2 code.
> The end result is that after the first time the offending code is
> executed, thread handling fails silently and catastrophically,
> including the complete inability to interrupt other threads (which
> also precludes the debugger from noticing anything going wrong). It's
> very possible that you're seeing this. In this case, there's not much
> to be done except a long and torturous debugging session to fix SBCL.
> Perhaps trying the same on CCL instead could help in the short term,
> but I must admit that I've only thought about migrating my code to
> CCL, not actually done so. Another not-really workaround is to restart
> SBCL and make sure you only run the suspect on a completely fresh
> image, *once*. If you do go down that route, you really, really want
> to SAVE-LISP-AND-DIE with as much of everything preloaded as possible.

This does help a lot--thanks! I'll go over to the sbcl help list with
my problem and your explanation and see if they have any insight into
how to debug it in more detail.

What I've been doing is the latter "not-really workaround" route and it
increases my development time a very annoying amount.

Is it possible to run cl-gtk applications in a single threaded manner so
I can at least debug my application?

Thank you.

-pete





From kalyanov.dmitry at gmail.com  Wed Aug 24 17:29:22 2011
From: kalyanov.dmitry at gmail.com (Kalyanov Dmitry)
Date: Wed, 24 Aug 2011 21:29:22 +0400
Subject: [cl-gtk2-devel] debugging cl-gtk applications
In-Reply-To: <CAGNGd0rmzPgfFe623LJ6Rq-o_A03tHhbBErkNcaxqd7AxwVajg@mail.gmail.com>
References: <20110824000221.GA21837@cs.wisc.edu>
	<CAGNGd0rmzPgfFe623LJ6Rq-o_A03tHhbBErkNcaxqd7AxwVajg@mail.gmail.com>
Message-ID: <1314206962.4078.13.camel@dvk-laptop>

On Wed, 2011-08-24 at 15:25 +0200, Maciej Katafiasz wrote:
> On Wed, Aug 24, 2011 at 02:02, Peter Keller <psilord at cs.wisc.edu> wrote:
> > When I use cl-gtk with sbcl, sometimes I write a bug where I define a
> > slot with an incorrect signature.
> >
> > What SBCL does at this point is that the thread containing the wrong code
> > dumps a message (usually "wrong number of arguments 2", etc being the
> > entirety of it even with debug and safety at 3 and speed optimize at 0)
> > and stops, but the REPL apparently doesn't notice.
> >
> > So, I then have this stopped thread hanging out in the background. How
> > does one access the correct thread to figure out a backtrace for the
> > failure?
> 
> Which platform are you using? There are two things to consider here:
> 
> 1) Win32 threading support is still pretty experimental, and there are
> many things from the surrounding assumptions (such as signal handling
> and the lack thereof on Windows, coupled with the fact that SLIME
> sends C-c on break request, which will kill SBCL because it doesn't
> register a proper Win32 handler( that simply haven't been updated to
> match Win32. The introspection bits can also be somewhat subpar
> compared to Linux, which will hurt you when trying to determine a
> non-obvious crash. That said, I've had quite good results getting GTK+
> to work on Win32, and that's including breaking and debugger
> signalling.

Actually, threading on Windows works quite fine (either in my SBCL fork
(which is now outdated) or in Anton Kovalenko's (which is more
up-to-date)). You would have to use fresh and patched libraries (namely,
SLIME, Usocket needed patching - at least when I looked at them last
time) and configure SLIME to use :spawn communication model. Then you'll
be able to use debugger and interrupt threads.

> 
> 2) On Linux there's currently an undetermined SBCL bug which somehow
> manifests itself very often in presence of semi-complex CL-GTK2 code.
> The end result is that after the first time the offending code is
> executed, thread handling fails silently and catastrophically,
> including the complete inability to interrupt other threads (which
> also precludes the debugger from noticing anything going wrong). It's
> very possible that you're seeing this. In this case, there's not much
> to be done except a long and torturous debugging session to fix SBCL.
> Perhaps trying the same on CCL instead could help in the short term,
> but I must admit that I've only thought about migrating my code to
> CCL, not actually done so. Another not-really workaround is to restart
> SBCL and make sure you only run the suspect on a completely fresh
> image, *once*. If you do go down that route, you really, really want
> to SAVE-LISP-AND-DIE with as much of everything preloaded as possible.

I've responded to this on SBCL's list, but I'll reply also here.

This seems like an issue in cl-gtk2 that was fixed quite some time ago.
It boils down to the fact that Gtk+ messes with POSIX signal handlers
(http://developer.gnome.org/gtk/2.24/gtk-General.html#gtk-init says that
"GTK+ calls signal (SIGPIPE, SIG_IGN) during initialization, to ignore
SIGPIPE signals"). It was worked around in cl-gtk2.





From kalyanov.dmitry at gmail.com  Wed Aug 24 17:50:39 2011
From: kalyanov.dmitry at gmail.com (Kalyanov Dmitry)
Date: Wed, 24 Aug 2011 21:50:39 +0400
Subject: [cl-gtk2-devel] GBoxed, signals, and dnd
In-Reply-To: <CAFYWPBijYyXQdqSBPn44rPa25BS=wDNTu1rhxSk3FPuZn7DJuw@mail.gmail.com>
References: <CAFYWPBijYyXQdqSBPn44rPa25BS=wDNTu1rhxSk3FPuZn7DJuw@mail.gmail.com>
Message-ID: <1314208239.4078.22.camel@dvk-laptop>

On Mon, 2011-08-22 at 18:18 -0500, Ryan Pavlik wrote:
> I'm currently working on implementing the calls necessary for DND on
> the gtk side.  For the most part, this has been relatively
> straightforward; I can receive drop data and initiate drags.
> 
> However, the critical part for initiated drags is setting
> selection-data in the drag-data-get signal handler.  This requires you
> to alter the passed selection-data in response; however, the changes
> don't appear to be copied out.  How can I accomplish this?
> 
> It appears that glib-defcallback is defined for a related purpose, but
> this doesn't seem useful in conjunction with signal handlers.
> 
> thanks,
> 

I admit that mapping of GBoxed types is not well thought out - it does
not fully capture semantics of C structures.

The easiest way to accomplish this would be to add ability to override
parsing of signal arguments (in gobject.signals.lisp, relevant functions
are LISP-SIGNAL-HANDLER-CLOSURE-MARSHAL, PARSE-CLOSURE-ARGUMENTS) and
use it to parse relevant arguments of signals as just pointers.




From rpavlik at gmail.com  Wed Aug 24 20:54:36 2011
From: rpavlik at gmail.com (Ryan Pavlik)
Date: Wed, 24 Aug 2011 15:54:36 -0500
Subject: [cl-gtk2-devel] [PATCH] Support for DND
Message-ID: <CAFYWPBhOwWJdXO3dkBoEk6Zufem0uJ4paL3cWd=vmfv639qsYA@mail.gmail.com>

Attached is a patch for the majority of the drag'n'drop API, along
with a rather simple test program.  The API is mostly similar to the
native gtk with cl-gtk2 naming conventions; exceptions of note:

  * selection-set selection-data data &key type

    This is a generic function for easily modifying the content of
    selection-data objects.  There are currently methods for data as a
    string and a gdk:pixbuf.

  * selection-get selection-data => string-or-array type format

    This will return a lisp string or array of integers for the
    selection-data, along with the type ("text/plain") and format
    (bits-per-unit).  It should be noted that gtk will currently not
    correctly handle format=32 on 64-bit systems.  (I have filed a bug
    report.)

The test program should allow drags within itself and to other
receivers; "text/plain" is fairly common.  Another common type is
"text/uri-list", but each line must be terminated with CRLF.

I have not tested every API call, particularly the image setting,
though I have tested quite a few more than are in the demo.  As I'm
using this for a project I will be testing more shortly.

A few more things:

  * I have not used (C)FFI much prior to this, and I am not intimately
    familiar with gtk, or cl-gtk2's gobject wrapper, though I did
    consult the source when questions arose.  But there may be
    glaring issues of which I'm not aware.

  * selection-data is now boxed-opaque instead of boxed-cstruct, in
    order to support "out" parameters.  Additionally, I have removed
    the call to boxed-copy-fn from boxed-parse-g-value for
    boxed-opaque types.

    My main concern here is values being double-freed by GC hooks, but
    having tested and looked at the code, this does not appear to
    happen: opaque instances are only finalized if they are allocated
    with make-instance, which will not be the case when calling
    g-boxed-copy.

    I am actually wondering if it's a memory leak as it was.

Also, it'd be nice if cl-gtk2 included the do-gtk macro in the
demo... within-main-loop deadlocks when used recursively...

hth,

-- 
Ryan Pavlik <rpavlik at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl-gtk2-dnd.patch
Type: text/x-patch
Size: 12893 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-gtk2-devel/attachments/20110824/11800089/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtk-dnd-test.lisp
Type: application/octet-stream
Size: 2033 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-gtk2-devel/attachments/20110824/11800089/attachment.obj>

From mathrick at gmail.com  Thu Aug 25 17:42:41 2011
From: mathrick at gmail.com (Maciej Katafiasz)
Date: Thu, 25 Aug 2011 19:42:41 +0200
Subject: [cl-gtk2-devel] debugging cl-gtk applications
In-Reply-To: <1314206962.4078.13.camel@dvk-laptop>
References: <20110824000221.GA21837@cs.wisc.edu>
	<CAGNGd0rmzPgfFe623LJ6Rq-o_A03tHhbBErkNcaxqd7AxwVajg@mail.gmail.com>
	<1314206962.4078.13.camel@dvk-laptop>
Message-ID: <CAGNGd0qCSkytVq46Y_HuHk8XgSgpsXdasxLtdFbSqf1y1tgR+w@mail.gmail.com>

On Wed, Aug 24, 2011 at 19:29, Kalyanov Dmitry
<kalyanov.dmitry at gmail.com> wrote:
> Actually, threading on Windows works quite fine (either in my SBCL fork
> (which is now outdated) or in Anton Kovalenko's (which is more
> up-to-date)). You would have to use fresh and patched libraries (namely,
> SLIME, Usocket needed patching - at least when I looked at them last
> time) and configure SLIME to use :spawn communication model. Then you'll
> be able to use debugger and interrupt threads.

Where's Anton's fork available? I was using your .msi builds, but as
you note, they're no longer the freshest around, Otherwise, yes, I
didn't mean to say that it doesn't work, just that SBCL-as-such
support of Win32 is rough, in particular when it comes to being
runnable under debugger itself, which necessary for any sufficiently
low-level detective work, such as accidentally making a list circular
and then feeding it to find, which I did once, and which results in a
pretty mysterious and entirely non-obvious stacktrace if you can't C-c
your way into the debugger from SLIME, which is another of these
nobody-wrote-the-patch-yet shortcomings.

Also, I'm very happy to hear you worked around the thread breakage
under Linux, it was seriously throwing a spanner in my wheels for a
while.

Cheers,
Maciej



From mathrick at gmail.com  Thu Aug 25 17:45:35 2011
From: mathrick at gmail.com (Maciej Katafiasz)
Date: Thu, 25 Aug 2011 19:45:35 +0200
Subject: [cl-gtk2-devel] debugging cl-gtk applications
In-Reply-To: <CAGNGd0qCSkytVq46Y_HuHk8XgSgpsXdasxLtdFbSqf1y1tgR+w@mail.gmail.com>
References: <20110824000221.GA21837@cs.wisc.edu>
	<CAGNGd0rmzPgfFe623LJ6Rq-o_A03tHhbBErkNcaxqd7AxwVajg@mail.gmail.com>
	<1314206962.4078.13.camel@dvk-laptop>
	<CAGNGd0qCSkytVq46Y_HuHk8XgSgpsXdasxLtdFbSqf1y1tgR+w@mail.gmail.com>
Message-ID: <CAGNGd0pEwbFHX+FLF4mHVt954R=CgthF36LtOThziB2wTkp-aQ@mail.gmail.com>

On Thu, Aug 25, 2011 at 19:42, Maciej Katafiasz <mathrick at gmail.com> wrote:
> Where's Anton's fork available? I was using your .msi builds, but as
> you note, they're no longer the freshest around,

Answering myself, it seems to be at
http://www.siftsoft.com/inprogress/sbcl-notes.html, which also links
to the binary .msi builds (yay!).

Cheers,
Maciej



From psilord at cs.wisc.edu  Sun Aug 28 22:20:05 2011
From: psilord at cs.wisc.edu (Peter Keller)
Date: Sun, 28 Aug 2011 17:20:05 -0500
Subject: [cl-gtk2-devel] debugging cl-gtk applications
In-Reply-To: <1314206962.4078.13.camel@dvk-laptop>
References: <20110824000221.GA21837@cs.wisc.edu>
	<CAGNGd0rmzPgfFe623LJ6Rq-o_A03tHhbBErkNcaxqd7AxwVajg@mail.gmail.com>
	<1314206962.4078.13.camel@dvk-laptop>
Message-ID: <20110828222005.GA4089@cs.wisc.edu>

On Wed, Aug 24, 2011 at 09:29:22PM +0400, Kalyanov Dmitry wrote:
> I've responded to this on SBCL's list, but I'll reply also here.
> 
> This seems like an issue in cl-gtk2 that was fixed quite some time ago.
> It boils down to the fact that Gtk+ messes with POSIX signal handlers
> (http://developer.gnome.org/gtk/2.24/gtk-General.html#gtk-init says that
> "GTK+ calls signal (SIGPIPE, SIG_IGN) during initialization, to ignore
> SIGPIPE signals"). It was worked around in cl-gtk2.

I sent back to the sbcl-help list how to reproduce the problem plus an
attached bit of code which produces it. Hopefully, it can be determined
exactly where the problem is.

Thank you very much for your responses and help!

-pete



From mathrick at gmail.com  Mon Aug 29 12:33:14 2011
From: mathrick at gmail.com (Maciej Katafiasz)
Date: Mon, 29 Aug 2011 14:33:14 +0200
Subject: [cl-gtk2-devel] [PATCH] Support for DND
In-Reply-To: <CAFYWPBhOwWJdXO3dkBoEk6Zufem0uJ4paL3cWd=vmfv639qsYA@mail.gmail.com>
References: <CAFYWPBhOwWJdXO3dkBoEk6Zufem0uJ4paL3cWd=vmfv639qsYA@mail.gmail.com>
Message-ID: <CAGNGd0p8n7_1xmL+QjTNntRqxuzwpH4pJHNWi3EdVd-m3bjxZQ@mail.gmail.com>

On Wed, Aug 24, 2011 at 22:54, Ryan Pavlik <rpavlik at gmail.com> wrote:
> Attached is a patch for the majority of the drag'n'drop API, along
> with a rather simple test program. ?The API is mostly similar to the
> native gtk with cl-gtk2 naming conventions; exceptions of note:

This is great news. However, a technical nitpick: have you thought
about setting up a github branch aside from just sending the
patches?This simplifies matters both for Dmitry and yourself when it
comes to making sure your and his work don't conflict, and also makes
it much easier for other people to pull not-yet-mainline code they
need without having to do the bookkeeping about which patches have
been applied, and what to do with them when updating the tree. In case
you don't know git or find it disgusting (as I do), I can recommend
bzr-git, which provides a good git client while presenting a sane and
friendly UI bzr is known for.

Cheers,
Maciej



From rpavlik at gmail.com  Mon Aug 29 14:39:25 2011
From: rpavlik at gmail.com (Ryan Pavlik)
Date: Mon, 29 Aug 2011 09:39:25 -0500
Subject: [cl-gtk2-devel] [PATCH] Support for DND
In-Reply-To: <CAGNGd0p8n7_1xmL+QjTNntRqxuzwpH4pJHNWi3EdVd-m3bjxZQ@mail.gmail.com>
References: <CAFYWPBhOwWJdXO3dkBoEk6Zufem0uJ4paL3cWd=vmfv639qsYA@mail.gmail.com>
	<CAGNGd0p8n7_1xmL+QjTNntRqxuzwpH4pJHNWi3EdVd-m3bjxZQ@mail.gmail.com>
Message-ID: <CAFYWPBgwrmPw_jL2G0zbymuC=svDmn3WiJKzB3fKAasziY=95Q@mail.gmail.com>

On Mon, Aug 29, 2011 at 07:33, Maciej Katafiasz <mathrick at gmail.com> wrote:
> On Wed, Aug 24, 2011 at 22:54, Ryan Pavlik <rpavlik at gmail.com> wrote:
>> Attached is a patch for the majority of the drag'n'drop API, along
>> with a rather simple test program. ?The API is mostly similar to the
>> native gtk with cl-gtk2 naming conventions; exceptions of note:
>
> This is great news. However, a technical nitpick: have you thought
> about setting up a github branch aside from just sending the
> patches?
<snip>

Apparently I was so hyper-focused on my related project this didn't
even occur to me.  I think this worked:

    git://github.com/rpav/cl-gtk2.git

Changes are in the "dnd" branch.  There's even some new stuff for selections and
cairo -> gdk_pixbuf.

-- 
Ryan Pavlik <rpavlik at gmail.com>