Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library"
writes:
> [[PGP Signed Part:Good signature from 91C9C33D2C61ACDB Jonas Hahnfeld
> (trust undefined) created at
> 2021-11-19T13:18:31+0100 using RSA]]
> Am Sonntag, dem 10.10.2021 um 18:22 +0200 schrieb Jonas
Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]:
> diff --git a/libguile/random.c b/libguile/random.c
> index 63da7f5d6..ac400a9fd 100644
> --- a/libguile/random.c
> +++ b/libguile/random.c
> @@ -324,9 +324,7 @@ scm_c_random_bignum (scm_t_rstate *state, SCM m)
> /* we know the result
Am Freitag, dem 19.11.2021 um 18:48 + schrieb Maxime Devos:
> Jonas Hahnfeld schreef op vr 19-11-2021 om 15:52 [+0100]:
> > Am Freitag, dem 19.11.2021 um 14:14 + schrieb Maxime Devos:
> > > [...]
> > >
> > > From your other responses, I now know it is actually related to
> > > (non-
> > >
Jonas Hahnfeld schreef op vr 19-11-2021 om 15:52 [+0100]:
> Am Freitag, dem 19.11.2021 um 14:14 + schrieb Maxime Devos:
> > [...]
> >
> > From your other responses, I now know it is actually related to
> > (non-
> > )Java style finalisation, but my comment about ‘separate patch’
> > still
> >
Am Freitag, dem 19.11.2021 um 14:21 + schrieb Maxime Devos:
> Jonas Hahnfeld schreef op vr 19-11-2021 om 14:35 [+0100]:
> > Am Freitag, dem 19.11.2021 um 13:15 + schrieb Maxime Devos:
> > > Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]:
> > > > + SCM *smobs = scm_gc_malloc
Am Freitag, dem 19.11.2021 um 14:14 + schrieb Maxime Devos:
> Jonas Hahnfeld schreef op vr 19-11-2021 om 14:55 [+0100]:
> > Am Freitag, dem 19.11.2021 um 13:48 + schrieb Maxime Devos:
> > > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > > > > - rx =
Jonas Hahnfeld schreef op vr 19-11-2021 om 14:35 [+0100]:
> Am Freitag, dem 19.11.2021 um 13:15 + schrieb Maxime Devos:
> > Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]:
> > > + SCM *smobs = scm_gc_malloc (sizeof(SCM) * SMOBS_COUNT,
> > > "smobs");
> > > +
> > > int i;
> > >
Jonas Hahnfeld schreef op vr 19-11-2021 om 14:55 [+0100]:
> Am Freitag, dem 19.11.2021 um 13:48 + schrieb Maxime Devos:
> > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > > > - rx = scm_gc_malloc_pointerless (sizeof (regex_t),
> > > > > "regex");
> > > > > + rx = scm_malloc
Am Freitag, dem 19.11.2021 um 13:48 + schrieb Maxime Devos:
> Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > > - rx = scm_gc_malloc_pointerless (sizeof (regex_t), "regex");
> > > > + rx = scm_malloc (sizeof (regex_t));
> > >
> > > If the regex why scm_gc_malloc_pointerless
Jonas Hahnfeld schreef op vr 19-11-2021 om 14:53 [+0100]:
> [...]
> The straight-forward solution is to statically tie the lifetime of
> regex_t to that of the smob. Which we cannot do with GC, but simply
> with malloc+free - as implemented in the patch.
OK, but for clarity I recommend adding a
Maxime Devos schreef op vr 19-11-2021 om 13:44 [+]:
> Jonas Hahnfeld schreef op vr 19-11-2021 om 14:40 [+0100]:
> > Am Freitag, dem 19.11.2021 um 13:35 + schrieb Maxime Devos:
> > > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > > > You coud simply ...
> > > > >
> > > > >
Am Freitag, dem 19.11.2021 um 13:44 + schrieb Maxime Devos:
> Jonas Hahnfeld schreef op vr 19-11-2021 om 14:40 [+0100]:
> > Am Freitag, dem 19.11.2021 um 13:35 + schrieb Maxime Devos:
> > > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > > > You coud simply ...
> > > > >
>
Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > - rx = scm_gc_malloc_pointerless (sizeof (regex_t), "regex");
> > > + rx = scm_malloc (sizeof (regex_t));
> >
> > If the regex why scm_gc_malloc_pointerless -> scm_malloc?
> > Is rx not pointerless?
>
> Not sure I understand the
Jonas Hahnfeld schreef op vr 19-11-2021 om 14:40 [+0100]:
> Am Freitag, dem 19.11.2021 um 13:35 + schrieb Maxime Devos:
> > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > > You coud simply ...
> > > >
> > > >
> > > > > - scm_gc_free (rx, sizeof(regex_t), "regex");
> > >
Am Freitag, dem 19.11.2021 um 13:17 + schrieb Maxime Devos:
> Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]:
> > + /* For guardians, we use unordered finalization `a la Java. */
>
> Maybe add the reasons why this is only done when a guardian is created?
> E.g.,
>
> /* Don't use
Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > You coud simply ...
> >
> >
> > > - scm_gc_free (rx, sizeof(regex_t), "regex");
> > > + free (rx);
> >
> > drop the scm_gc_free AFAIK.
>
> No, I cannot as explained in the patch summary: If we use scm_gc_free
> in a free
Am Freitag, dem 19.11.2021 um 13:35 + schrieb Maxime Devos:
> Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > You coud simply ...
> > >
> > >
> > > > - scm_gc_free (rx, sizeof(regex_t), "regex");
> > > > + free (rx);
> > >
> > > drop the scm_gc_free AFAIK.
> >
> >
Am Freitag, dem 19.11.2021 um 13:15 + schrieb Maxime Devos:
> Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]:
> > + SCM *smobs = scm_gc_malloc (sizeof(SCM) * SMOBS_COUNT, "smobs");
> > +
> > int i;
> > mark_call_count = 0;
> > for (i = 0; i < SMOBS_COUNT; i++)
> > -
Am Freitag, dem 19.11.2021 um 13:13 + schrieb Maxime Devos:
> Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]:
> > From 33af6a98c6801e7b4880d1d3f78f7e2097c2174e Mon Sep 17 00:00:00
> > 2001
> > From: Jonas Hahnfeld
> > Date: Fri, 2 Jul 2021 23:03:17 +0200
> > Subject: [PATCH 2/3]
Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]:
> + /* For guardians, we use unordered finalization `a la Java. */
Maybe add the reasons why this is only done when a guardian is created?
E.g.,
/* Don't use unordered finalization when not using guardians,
because Java finalization
Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]:
> + SCM *smobs = scm_gc_malloc (sizeof(SCM) * SMOBS_COUNT, "smobs");
> +
> int i;
> mark_call_count = 0;
> for (i = 0; i < SMOBS_COUNT; i++)
> - make_x ();
> + smobs[i] = make_x ();
> scm_gc ();
smobs doesn't need to be
Jonas Hahnfeld schreef op do 15-07-2021 om 20:44 [+0200]:
> From 33af6a98c6801e7b4880d1d3f78f7e2097c2174e Mon Sep 17 00:00:00
> 2001
> From: Jonas Hahnfeld
> Date: Fri, 2 Jul 2021 23:03:17 +0200
> Subject: [PATCH 2/3] Avoid matching calls of scm_gc_free
>
> There is no point in registering
Am Donnerstag, dem 15.07.2021 um 20:44 +0200 schrieb Jonas Hahnfeld via
Developers list for Guile, the GNU extensibility library:
> Am Samstag, dem 03.07.2021 um 14:05 +0200 schrieb Jonas Hahnfeld via
> Developers list for Guile, the GNU extensibility library:
> > Hi Guile devs,
> >
> > I'm
Am Samstag, dem 03.07.2021 um 14:05 +0200 schrieb Jonas Hahnfeld via
Developers list for Guile, the GNU extensibility library:
> Hi Guile devs,
>
> I'm hacking on GNU LilyPond and recently wondered if Guile could run
> without Java finalization that prevents collection of chains of
> unreachable
Jonas Hahnfeld schreef op za 03-07-2021 om 19:26 [+0200]:
> > Normally scm_remember_upto_here is used for that.
>
> I think I tried, but it wasn't available. Or I mistyped, not sure.
It is defined in .
Actually, the special case scm_remember_upto_here_1 would be prefered,
because it
Jonas Hahnfeld schreef op za 03-07-2021 om 19:26 [+0200]:
> Sorry, I should have been clearer: Chains don't become uncollectable,
> but a chain of N objects takes N collections to be completely reclaimed
> (because Java finalization prepares for the possibility that a free
> function makes an
Am Samstag, dem 03.07.2021 um 19:14 +0200 schrieb Maxime Devos:
> Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
> schreef op za 03-07-2021 om 14:05 [+0200]:
> > Hi Guile devs,
> >
>
> Hi, I'm not really a Guile dev but I'll respond anyway.
>
> > I'm hacking on GNU
Hi Guile devs,
I'm hacking on GNU LilyPond and recently wondered if Guile could run
without Java finalization that prevents collection of chains of
unreachable objects. I found that the functionality is only needed once
the first guardian is created, so it's possible to delay enabling the
mode
28 matches
Mail list logo
