From: Eli Zaretskii <eliz@gnu.org>
To: ludo@gnu.org (Ludovic Courtès)
Cc: xdje42@gmail.com, gdb-patches@sourceware.org, guile-devel@gnu.org
Subject: Re: [PATCH v2] Improved ^c support for gdb/guile
Date: Tue, 18 Feb 2014 16:02:00 -0000 [thread overview]
Message-ID: <83iosc76kz.fsf@gnu.org> (raw)
In-Reply-To: <871tz0d5vc.fsf@gnu.org>
> From: ludo@gnu.org (Ludovic Courtès)
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org, guile-devel@gnu.org
> Date: Tue, 18 Feb 2014 12:20:39 +0100
>
> Doug Evans <xdje42@gmail.com> skribis:
>
> I donât remember, Eli: do you have patches pending review for these
> issues and other MinGW issues in Guile?
I don't know, you tell me. I sent several changesets in June,
in these messages:
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00031.html
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00032.html
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00033.html
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00036.html
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00037.html
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00039.html
In this message:
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00057.html
you have requested a copyright assignment for applying my patches;
that paperwork was done long ago, so the changes can be admitted. I
don't know if they were, though. One thing I do know is that the
request to gnulib maintainers to include hstrerror, which I posted, at
your request, here
http://lists.gnu.org/archive/html/bug-gnulib/2013-06/msg00042.html
was left without any followups.
Also, since the only way I could get a functional MinGW Guile was to
configure it without threads, I would suggest that this be the default
for MinGW, but that isn't a big deal.
> The non-pthread code is used when Guile is built without pthread
> support. In that case, the async is queued directly from the signal
> handler.
So why cannot this code be used by GDB?
> (I think we should aim to get rid of the signal-delivery thread
> eventually, and I remember Mark mentioned it before too.)
Right, which raises again the question why use in GDB something that
is slated for deletion.
Btw, where does the value of SCM_USE_PTHREAD_THREADS come from? Is it
something defined by the installed Guile headers?
next prev parent reply other threads:[~2014-02-18 16:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 7:39 [PATCH] " Doug Evans
2014-02-17 9:27 ` Mark Kettenis
2014-02-17 16:06 ` Ludovic Courtès
2014-02-17 20:26 ` [PATCH v2] " Doug Evans
2014-02-17 20:43 ` Eli Zaretskii
2014-02-17 20:59 ` Doug Evans
2014-02-17 21:13 ` Eli Zaretskii
2014-02-18 0:37 ` Doug Evans
2014-02-18 11:20 ` Ludovic Courtès
2014-02-18 16:02 ` Eli Zaretskii [this message]
2014-02-18 16:45 ` Ludovic Courtès
2014-02-18 16:56 ` Eli Zaretskii
2014-02-18 17:46 ` Ludovic Courtès
2014-02-18 17:58 ` Eli Zaretskii
2014-02-18 23:08 ` Ludovic Courtès
2014-02-19 7:51 ` Mark H Weaver
2014-02-19 16:42 ` Eli Zaretskii
2014-02-18 17:31 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83iosc76kz.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=xdje42@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox