Any takers?
-- Forwarded message -
From: anatol.pomozov at gmail dot com
Date: Tue, May 26, 2020 at 10:31 AM
Subject: [Bug guile/21104] 7.12.1 does not compile with latest guile (2.1.6)
To:
https://sourceware.org/bugzilla/show_bug.cgi?id=21104
--- Comment #16 from Anatol Pomoz
On Tue, Feb 6, 2018 at 11:25 AM, Eli Zaretskii wrote:
>> From: "Doug Evans via gdb-patches"
>> Date: Tue, 6 Feb 2018 10:58:07 -0800
>> Cc: guile-devel@gnu.org
>>
>> diff --git a/gdb/NEWS b/gdb/NEWS
>> index f69173a245..324f98b217 100644
>&
further reduced diffs
that may be a possibility.]
2018-02-06 Doug Evans
PR guile/21104
* NEWS: Mention guile 2.2 is supported again.
* configure.ac: Add guile-2.2 back.
* configure: Regenerate.
* guile/scm-ports.c (PORTS_V22): New macro
to redo the 2.0 support to further reduced diffs
that may be a possibility.]
2018-01-21 Doug Evans
PR guile/21104
* configure.ac: Add guile-2.2 back.
* configure: Regenerate.
* guile/scm-ports.c (PORTS_V22): New macro.
(ioscm_memory_port) [!PORTS_V22]: M
On Tue, Sep 1, 2015 at 7:35 AM, Eli Zaretskii wrote:
>> The goal here is to block these signals from being sent to the threads
>> that Guile (or more specifically libgc) creates.
>
> Why only libgc? Don't we want to block these signals in any Guile
> code invoked later by GDB?
Any threads create
On Sat, Aug 29, 2015 at 7:37 PM, Eli Zaretskii wrote:
>> Date: Sat, 29 Aug 2015 23:04:02 +0200 (CEST)
>> From: Mark Kettenis
>> CC: e...@gnu.org, gdb-patc...@sourceware.org, guile-devel@gnu.org
>>
>> I suppose blocking these in the threads that guile starts is necessary
>> because that is the onl
On Sat, Aug 29, 2015 at 1:16 PM, Eli Zaretskii wrote:
>> Date: Sat, 29 Aug 2015 12:20:24 -0700
>> From: Doug Evans
>> Cc: "gdb-patc...@sourceware.org" , guile-devel
>>
>>
>> > What about platforms that don't have sigprocmask, but do ha
On Sat, Aug 29, 2015 at 12:11 PM, Eli Zaretskii wrote:
>> From: Doug Evans
>> cc: guile-devel@gnu.org
>> Date: Sat, 29 Aug 2015 10:22:11 -0700
>>
>> --- a/gdb/guile/guile.c
>> +++ b/gdb/guile/guile.c
>> @@ -847,7 +847,7 @@ _initialize_guile (v
calls sigaddset for each appropriate
signal rather than defining the list in guile.c.
2015-08-29 Doug Evans
* guile/guile.c (_initialize_guile): Block all asynchronous signals
used by gdb when initializing Guile.
diff --git a/gdb/guile/guile.c b/gdb/guile/guile.c
index 4abf5c5..e9
Hi.
This seems obvious, but I could be missing something.
2015-03-28 Doug Evans
* libguile/fports.c (fport_write): Fix test of remaining bytes.
diff --git a/libguile/fports.c b/libguile/fports.c
index 8395f0e..ce1bf54 100644
--- a/libguile/fports.c
+++ b/libguile/fports.c
@@ -869,7
On Wed, Mar 18, 2015 at 1:57 AM, Andy Wingo wrote:
> Hi,
>
> [-asmundak, as he probably doesn't care :)]
>
> On Tue 17 Mar 2015 23:21, Doug Evans writes:
>
>> On Tue, Mar 17, 2015 at 1:57 AM, Andy Wingo wrote:
>>>> As to the class of an object
[+ guile-devel, in case they have an opinion on the spelling of
frame-data-read-register vs frame-data:read-register]
On Tue, Mar 17, 2015 at 1:57 AM, Andy Wingo wrote:
>> As to the class of an object passed to a sniffer, how about calling it
>> FrameData? Note that it's not very important from t
Eli Zaretskii writes:
>> Date: Mon, 1 Sep 2014 15:04:16 -0700
>> From: Doug Evans
>> Cc: Ludovic Courtès ,
>> guile-devel ,
>> "gdb-patc...@sourceware.org"
>>
>>> Eli Zaretskii skribis:
>>>
>>> > Per
On Mon, Sep 1, 2014 at 10:10 AM, Eli Zaretskii wrote:
>> From: l...@gnu.org (Ludovic Courtès)
>> Cc: gdb-patc...@sourceware.org, guile-devel@gnu.org
>> Date: Mon, 01 Sep 2014 18:18:45 +0200
>>
>> Eli Zaretskii skribis:
>>
>> > Perhaps we should request GC and Guile to provide capabilities to
>>
On Mon, Sep 1, 2014 at 5:48 AM, Gary Benson wrote:
> Doug Evans wrote:
>> On Sun, Aug 31, 2014 at 12:36 PM, Eli Zaretskii wrote:
>> > > From: Doug Evans
>> > > Date: Sun, 31 Aug 2014 12:07:58 -0700
>> > >
>> > > Basically, current Gui
[+ guile-devel]
On Sun, Aug 31, 2014 at 12:36 PM, Eli Zaretskii wrote:
>> From: Doug Evans
>> Date: Sun, 31 Aug 2014 12:07:58 -0700
>>
>> Basically, current Guile (git) starts an internal thread
>> (the "finalizer" thread), and libgc as of 7.4 now sta
On Fri, Aug 29, 2014 at 10:36 AM, wrote:
> On master, where we now require gc-7.2 or later, I guess we should be
> able to simplify this and block all signals.
>
> However, it's not clear how to backport this to stable-2.0, which does
> not even have a finalization thread, and yet gdb bug 17247 o
On Tue, Aug 26, 2014 at 1:14 AM, Doug Evans wrote:
> Hi.
>
> I think(!) I understand why gdb is hanging when used with libgc 7.4.x.
> This is gdb bug 17247.
> https://sourceware.org/bugzilla/show_bug.cgi?id=17247#c30
>
> First, libgc 7.4.x was the first release to default
Hi.
I think(!) I understand why gdb is hanging when used with libgc 7.4.x.
This is gdb bug 17247.
https://sourceware.org/bugzilla/show_bug.cgi?id=17247#c30
First, libgc 7.4.x was the first release to default PARALLEL_MARK to
on, so I'm guessing the same "bug" exists in 7.2, it's just not
visible
On Jun 11, 2014 3:14 PM, "Ludovic Courtès" wrote:
>
> Eli Zaretskii skribis:
>
> >> [...]
> > UNRESOLVED: i18n.test: string mapping: string-locale-downcase Turkish
> >
> > I don't know why these fail.
>
> Note that “UNRESOLVED” is not a failure; it means “we can’t run this
> test here, so skip
Hi.
I was looking into the libgc 7.4.0 "GC_MARKERS" bug,
and found that the workaround in Guile is using GC_ALPHA_VERSION
which I can't find in the bdwgc git tree, but I can find GC_VERSION_MICRO.
Since undefined preprocessor macros evaluate to zero this test will
pass for any 7.4.x.
#if (GC_VER
On Wed, May 21, 2014 at 7:24 AM, Ludovic Courtès wrote:
> Hi!
>
> Doug Evans skribis:
>
>> The problem can be succinctly represented by the following:
>>
>> scheme@(guile-user)> (port? (port-with-print-state (current-output-port)))
>> $3 = #f
>
> I t
On Fri, May 16, 2014 at 2:39 AM, Ludovic Courtès wrote:
> WDYT?
>
> I’ll push it shortly if there are no objections.
>
> Ludo’.
Hi.
For reference sake, I checked glibc and it only checks '\n' (AFAICT).
ref: libio/fileops.c
Hi.
I've been playing with gdb objects implemented as structs and have hit
an oddity.
The problem can be succinctly represented by the following:
scheme@(guile-user)> (port? (port-with-print-state (current-output-port)))
$3 = #f
I've dug into the implementation of the functions and macros invol
On Tue, Apr 29, 2014 at 11:25 AM, Andy Wingo wrote:
> Hi!
>
> Thanks for the feedback, it's really useful.
>
> On Tue 29 Apr 2014 17:56, Doug Evans writes:
>
>> The struct interface, contrary to what the documentation says, takes a
>> stdarg list beginning
On Sun, Apr 27, 2014 at 10:51 AM, Andy Wingo wrote:
>[...]
>> Portability is more problematic for pointer types. The C standards make
>> no guarantees about the semantics of converting between pointers and
>> integers, and it's not clear to me how future proof this will be.
>
> Don't they make so
On Fri, May 2, 2014 at 4:19 PM, Ludovic Courtès wrote:
> Doug Evans skribis:
>
>> On Fri, May 2, 2014 at 4:44 AM, Ludovic Courtès wrote:
>>> Doug Evans skribis:
>>>
>>>> While function declarations are markable as being internal/external in
>&
On Fri, May 2, 2014 at 4:44 AM, Ludovic Courtès wrote:
> Doug Evans skribis:
>
>> While function declarations are markable as being internal/external in
>> published headers (SCM_INTERNAL vs SCM_API), macros are not.
>
> Internal macros are marked by a naming conventi
Hi.
Is any of the following exported?
[or are they internal implementation details?]
I can certainly imagine it's the latter, but the DATA versions do
solve the problem (*1) of accessing struct fields as raw values.
#define SCM_STRUCT_DATA(X) ((scm_t_bits*)SCM_CELL_WORD_1 (X))
#defi
Hi all.
While reading guile sources I happened across the implementation
of struct scm_print_state. ref: libguile/print.h
It (tries to) map a C struct to a set of Guile struct fields:
ref: SCM_PRINT_STATE_LAYOUT.
I *could* be missing something, but I think my angst can be represented
with the f
On Sun, Apr 27, 2014 at 6:17 AM, Andy Wingo wrote:
> Hi,
>
> SMOBs have a few problems.
>
> [...]
> 7) There is legacy code out there that uses e.g. SCM_SETCDR to set
> smob fields. (This is terrible, but it exists:
> https://github.com/search?q=SCM_SETCDR+smob&ref=cmdform&type=Code
>
On Mon, Apr 28, 2014 at 9:08 AM, Andy Wingo wrote:
> [...]
> 1.4 Foreign Object Memory Management
>
>
> Once a foreign object has been released to the tender mercies of the
> Scheme system, it must be prepared to survive garbage collection. In
> the example ab
On Sun, Apr 27, 2014 at 6:17 AM, Andy Wingo wrote:
> Hi,
>
> SMOBs have a few problems.
>
> 1) They are limited in number to 255.
>
> 2) It's difficult to refer to a SMOB type from Scheme. You can use
> class-of once you have an object, but the class-of isn't exactly
> the same as t
On Sun, Mar 23, 2014 at 12:38 PM, Andy Wingo wrote:
> Hi,
>
> Following up after a lng time --
>
> On Fri 12 Apr 2013 01:55, Daniel Hartwig writes:
>
>> On 11 April 2013 13:37, Ian Price wrote:
>>>
So, what do you think [about ,run and ,!]?
>>>
>>> This is the sort of thing that belongs
On Mon, Mar 17, 2014 at 1:32 PM, Ludovic Courtès wrote:
> Doug Evans skribis:
>
>> On Thu, Mar 13, 2014 at 11:05 AM, Ludovic Courtès wrote:
>>> Mark H Weaver skribis:
>>>
>>>> Dale Evans pointed out that GCC runs the autoconf tests twice when
>&g
On Thu, Mar 13, 2014 at 11:05 AM, Ludovic Courtès wrote:
> Mark H Weaver skribis:
>
>> Dale Evans pointed out that GCC runs the autoconf tests twice when
>> cross-compiling: once for the build machine and once for the host
>> machine. I suspect that this is the proper solution for us, so we'd
>>
On Thu, Feb 20, 2014 at 2:42 PM, Mark H Weaver wrote:
> Doug Evans writes:
>
>> What I want is all the functionality of scm_c_catch and all the
>> functionality of scm_c_with_continuation_barrier ... which is exactly
>> what scm_i_with_continuation_barrier is.
&g
I realize the _i_ will have to be replaced, and the name
scm_c_with_continuation_barrier is already taken, however,
I found in writing gdb/guile/scm-safe-call.c that
scm_i_with_continuation_barrier is exactly what I need. Since it's
not available I had to do two levels of calls where one should
su
On Tue, Feb 18, 2014 at 3:06 PM, Ludovic Courtès wrote:
> Doug Evans skribis:
>
>> I see (at least) two high level problems.
>>
>> 1) Some apps need ability to use their own signal handlers.
>
> You mean the "real" signal handler, right?
Right.
On Tue, Feb 18, 2014 at 9:42 AM, Ludovic Courtès wrote:
> (Dropping GDB.)
>
> Doug Evans skribis:
>
>> On Tue, Feb 18, 2014 at 3:20 AM, Ludovic Courtès wrote:
>
> [...]
>
>>> (I think we should aim to get rid of the signal-delivery thread
>>> eventu
On Tue, Feb 18, 2014 at 3:20 AM, Ludovic Courtès wrote:
> Right, when Guile is built with pthread support, it has a signal
> delivery thread. The actual SIGINT handler ('take_signal' in scmsigs.c)
> just write one byte to a pipe; the signal delivery thread reads from
> that pipe, and queues an as
On Mon, Feb 17, 2014 at 1:13 PM, Eli Zaretskii wrote:
>> Date: Mon, 17 Feb 2014 12:59:22 -0800
>> From: Doug Evans
>> Cc: "gdb-patc...@sourceware.org" ,
>> guile-devel@gnu.org
>>
>> >> +void
>> >> +gdbscm_initialize_sigint (vo
[+ guile-devel]
On Mon, Feb 17, 2014 at 12:43 PM, Eli Zaretskii wrote:
>> From: Doug Evans
>> Date: Mon, 17 Feb 2014 15:26:27 -0500
>>
>> Unworkable-as-is optimization trying to avoid queueing asyncs. Blech.
>>
>> I'm still seeing intermittent testsuit
43 matches
Mail list logo
