GNU logs - #76200, boring messages

Message sent to bug-guile@HIDDEN:

Subject: bug#76200: `with-parameters*' seems to create a continuation barrier
Resent-From: "W. Kosior" <koszko@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Tue, 11 Feb 2025 11:00:02 +0000
Resent-Message-ID: <handler.76200.B.173927159731523 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 76200 <at> debbugs.gnu.org
Date: Tue, 11 Feb 2025 11:59:36 +0100
From: "W. Kosior" <koszko@HIDDEN>
Message-ID: <20250211115936.163461f7.koszko@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/vwVMj1iR57JM2neVWqrGx0g";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Received-SPF: pass client-ip=188.68.237.248; envelope-from=koszko@HIDDEN;
 helo=koszko.org
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)

--Sig_/vwVMj1iR57JM2neVWqrGx0g
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

I've been experimenting with guile-fibers.  I noticed that
`with-parameters*' procedure included as an "extra" in Guile's srfi-39
creates a continuation barrier.  From the documentation it is not clear
that it does so.

Consider this sample program (which I ran with Guile 3.0.9 and Fibers
1.0.0, as they are defined in Guix
2fda889ac992977af7b4cd96d09f737d834e0b2d):

--8<---------------cut here---------------start------------->8---
(use-modules (fibers)
             (fibers channels)
             (srfi srfi-18)
             ((srfi srfi-39) #:select (with-parameters*)))

(define %my-channel
  (make-channel))

(define %my-param
  (make-parameter #f))

(define %my-thread
  (make-thread (lambda ()
                 (run-fibers (lambda ()
                               (with-parameters* (list %my-param) '(hello)
                                 (lambda ()
                                   (put-message %my-channel (%my-param))
                                   'ok)))))))

(thread-start! %my-thread)

(format #t "message: ~a~%" (get-message %my-channel))

(thread-join! %my-thread)
--8<---------------cut here---------------end--------------->8---

It prints:

> Uncaught exception in task:
> In fibers.scm:
>    186:20  6 (_)
>    145:21  5 (_)
> In unknown file:
>            4 (with-fluids* (#<fluid 7f192cf70d70>) (hello) #<procedure 10=
0903e0 at <=E2=80=A6>)
> In current input:
>     17:35  3 (_)
> In fibers/operations.scm:
>    154:10  2 (perform-operation _)
> In fibers/scheduler.scm:
>     357:6  1 (suspend-current-task _)
> In ice-9/boot-9.scm:
>   1685:16  0 (raise-exception _ #:continuable? _)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Attempt to suspend fiber within continuation barrier

But if I use `parameterize' rather than `with-parameters*', no errors
occur.  Here's an example of a working program:

--8<---------------cut here---------------start------------->8---
(use-modules (fibers)
             (fibers channels)
             (srfi srfi-18))

(define %my-channel
  (make-channel))

(define %my-param
  (make-parameter #f))

(define %my-thread
  (make-thread (lambda ()
                 (run-fibers (lambda ()
                               (parameterize ((%my-param 'hello))
                                 (put-message %my-channel (%my-param))
                                 'ok))))))

(thread-start! %my-thread)

(format #t "message: ~a~%" (get-message %my-channel))

(thread-join! %my-thread)
--8<---------------cut here---------------end--------------->8---

It prints:

> message: hello

Is it a bug that `with-parameters*' doesn't work equivalently?  Or am I
reading the info pages wrong?

Best :)
Wojtek

--
W. Kosior

website: https://koszko.org/koszko.html
fediverse: https://friendica.me/profile/koszko/profile
PGP fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

--Sig_/vwVMj1iR57JM2neVWqrGx0g
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQTpcnBg48VjfIpPS0JLxSIcWnn9GgUCZ6stmAAKCRBLxSIcWnn9
GtrzAQCIual5Cp+uNk1W18wI45WncPVmxb6S666AAoil63+ERQEA5Uxmdfg1lW/o
VYUHrim/FzcyXzkuZYyIzwCtT3LOwgE=
=484+
-----END PGP SIGNATURE-----

--Sig_/vwVMj1iR57JM2neVWqrGx0g--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "W. Kosior" <koszko@HIDDEN>
Subject: bug#76200: Acknowledgement (`with-parameters*' seems to create a
 continuation barrier)
Message-ID: <handler.76200.B.173927159731523.ack <at> debbugs.gnu.org>
References: <20250211115936.163461f7.koszko@HIDDEN>
X-Gnu-PR-Message: ack 76200
X-Gnu-PR-Package: guile
Reply-To: 76200 <at> debbugs.gnu.org
Date: Tue, 11 Feb 2025 11:00:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guile@HIDDEN

If you wish to submit further information on this problem, please
send it to 76200 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
76200: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D76200
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guile@HIDDEN:

Subject: bug#76200: `with-parameters*' seems to create a continuation barrier
Resent-From: Linus =?UTF-8?Q?Bj=C3=B6rnstam?= <linus.bjornstam@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Fri, 14 Feb 2025 07:59:02 +0000
Resent-Message-ID: <handler.76200.B76200.173951988217732 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "W. Kosior" <koszko@HIDDEN>, 76200 <at> debbugs.gnu.org
Feedback-ID: i51694465:Fastmail
MIME-Version: 1.0
Date: Fri, 14 Feb 2025 08:57:32 +0100
From: Linus =?UTF-8?Q?Bj=C3=B6rnstam?= <linus.bjornstam@HIDDEN>
Message-Id: <d6eacdb0-fb59-49d8-bd42-bdc4136d3b66@HIDDEN>
In-Reply-To: <20250211115936.163461f7.koszko@HIDDEN>
References: <20250211115936.163461f7.koszko@HIDDEN>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

It seems with-fluids* (used by with-parameters*) is still a c function. =
I am not really sure how that stuff works, but I believe C can (always?)=
 impose continuation barriers of delimited continuations.=20

 If you look at the source of parameterize, with-fluids, with-fluids* (a=
nd more?) in boot-9 ther are all using scheme functions, or things defin=
ed in the VM, whereas srfi-39 depends on with-fluids* that is defined in=
 fluids.c.=20

If the transform from let to let* extends to with-fluids->with-fluids* i=
t should be a trivial thing to put into boot-9.scm, but I rarely dabble =
with dynamic environments and whatever is in the documentation is somewh=
at opaque.=20

Best regards
  Linus Bj=C3=B6rnstam

On Tue, 11 Feb 2025, at 11:59, W. Kosior via Bug reports for GUILE, GNU'=
s Ubiquitous Extension Language wrote:
> Hello,
>
> I've been experimenting with guile-fibers.  I noticed that
> `with-parameters*' procedure included as an "extra" in Guile's srfi-39
> creates a continuation barrier.  From the documentation it is not clear
> that it does so.
>
> Consider this sample program (which I ran with Guile 3.0.9 and Fibers
> 1.0.0, as they are defined in Guix
> 2fda889ac992977af7b4cd96d09f737d834e0b2d):
>
> --8<---------------cut here---------------start------------->8---
> (use-modules (fibers)
>              (fibers channels)
>              (srfi srfi-18)
>              ((srfi srfi-39) #:select (with-parameters*)))
>
> (define %my-channel
>   (make-channel))
>
> (define %my-param
>   (make-parameter #f))
>
> (define %my-thread
>   (make-thread (lambda ()
>                  (run-fibers (lambda ()
>                                (with-parameters* (list %my-param) '(he=
llo)
>                                  (lambda ()
>                                    (put-message %my-channel (%my-param=
))
>                                    'ok)))))))
>
> (thread-start! %my-thread)
>
> (format #t "message: ~a~%" (get-message %my-channel))
>
> (thread-join! %my-thread)
> --8<---------------cut here---------------end--------------->8---
>
> It prints:
>
>> Uncaught exception in task:
>> In fibers.scm:
>>    186:20  6 (_)
>>    145:21  5 (_)
>> In unknown file:
>>            4 (with-fluids* (#<fluid 7f192cf70d70>) (hello) #<procedur=
e 100903e0 at <=E2=80=A6>)
>> In current input:
>>     17:35  3 (_)
>> In fibers/operations.scm:
>>    154:10  2 (perform-operation _)
>> In fibers/scheduler.scm:
>>     357:6  1 (suspend-current-task _)
>> In ice-9/boot-9.scm:
>>   1685:16  0 (raise-exception _ #:continuable? _)
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Attempt to suspend fiber within continuation barrier
>
> But if I use `parameterize' rather than `with-parameters*', no errors
> occur.  Here's an example of a working program:
>
> --8<---------------cut here---------------start------------->8---
> (use-modules (fibers)
>              (fibers channels)
>              (srfi srfi-18))
>
> (define %my-channel
>   (make-channel))
>
> (define %my-param
>   (make-parameter #f))
>
> (define %my-thread
>   (make-thread (lambda ()
>                  (run-fibers (lambda ()
>                                (parameterize ((%my-param 'hello))
>                                  (put-message %my-channel (%my-param))
>                                  'ok))))))
>
> (thread-start! %my-thread)
>
> (format #t "message: ~a~%" (get-message %my-channel))
>
> (thread-join! %my-thread)
> --8<---------------cut here---------------end--------------->8---
>
> It prints:
>
>> message: hello
>
> Is it a bug that `with-parameters*' doesn't work equivalently?  Or am I
> reading the info pages wrong?
>
> Best :)
> Wojtek
>
> --
> W. Kosior
>
> website: https://koszko.org/koszko.html
> fediverse: https://friendica.me/profile/koszko/profile
> PGP fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Message sent to bug-guile@HIDDEN:

Subject: bug#76200: `with-parameters*' seems to create a continuation barrier
Resent-From: "W. Kosior" <koszko@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Fri, 14 Feb 2025 10:52:02 +0000
Resent-Message-ID: <handler.76200.B76200.173953029617311 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Linus =?UTF-8?Q?Bj=C3=B6rnstam?= <linus.bjornstam@HIDDEN>
Cc: 76200 <at> debbugs.gnu.org
Date: Fri, 14 Feb 2025 11:51:28 +0100
From: "W. Kosior" <koszko@HIDDEN>
Message-ID: <20250214115128.6625186c.koszko@HIDDEN>
In-Reply-To: <d6eacdb0-fb59-49d8-bd42-bdc4136d3b66@HIDDEN>
References: <20250211115936.163461f7.koszko@HIDDEN>
 <d6eacdb0-fb59-49d8-bd42-bdc4136d3b66@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/YQyxbn6uKdmyzH9+nQnL57V";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--Sig_/YQyxbn6uKdmyzH9+nQnL57V
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

thanks for pointing me in the right direction.

The naming is making me dizzy (the name of `with-fluid*' procedure from
boot-9.scm reads so similar to `with-fluids*' from fluids.c).

Nevertheless, I think I found one relevant Andy Windo's commit from 2010:

    c32b7c4cef1c63a677a1c447a0386e90ab2ecd42
    Remove with-fluids; replaced by with-fluid* and inlined push-fluid prim=
ops

So, previously the procedures `with-fluid*' and `with-fluids*' were
defined in fluids.c as `scm_with_fluid' and `scm_with_fluids',
respectively.  One can see they actually did the same thing back then,
except one dealt with multiple fluids at once.  And they must have both
suffered from the continuation barrier issue.

In addition, the macro `with-fluids' used to be defined in expand.c
before 2010.

In that commit, Andy defined `with-fluid*' and `with-fluids' in scheme
in boot-9.scm.  The C function `scm_with_fluid' remained, unexported to
scheme, likely for compatibility with Libguile users.  At the same
the `scm_with_fluids' exported as `with-fluids*' was left untouched,
perhaps by mistake.

What's a clear mistake is part of the description of that commit.  It
says

    * libguile/fluids.c (scm_with_fluid): Rename from scm_with_fluids, and
      don't expose to Scheme.

The function did not get renamed.  Both `scm_with_fluid' and
`scm_with_fluids' existed before and still live alongside each other.

> If the transform from let to let* extends to
> with-fluids->with-fluids* it should be a trivial thing to put into
> boot-9.scm, but I rarely dabble with dynamic environments and
> whatever is in the documentation is somewhat opaque.=20

In the light of my findings above it'll likely be clear the transform is
different as it is a macro->procedure shift.

But then reimplementing `with-fluids*' should still be easy.  For
example

--8<---------------cut here---------------start------------->8---
(define (with-fluids* fluids vals thunk)
  (if (not (=3D (length fluids) (length vals)))
      (scm-error 'out-of-range "with-fluids*" '("Value out of range: ~S")
                 vals vals))

  (let loop ((fluids-left fluids)
             (vals-left vals))
    (if (null? fluids-left)
        (thunk)
        (with-fluid* (car fluids-left) (car vals-left)
          (lambda ()
            (loop (cdr fluids-left) (cdr vals-left)))))))
--8<---------------cut here---------------end--------------->8---

I tested by running the code from my previous message with
`with-parameters*' redefined to use this new `with-fluids*'.

Best!
Wojtek

--
W. Kosior

website: https://koszko.org/koszko.html
fediverse: https://friendica.me/profile/koszko/profile
PGP fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A


On Fri, 14 Feb 2025 08:57:32 +0100
Linus Bj=C3=B6rnstam <linus.bjornstam@HIDDEN> wrote:

> It seems with-fluids* (used by with-parameters*) is still a c function. I=
 am not really sure how that stuff works, but I believe C can (always?) imp=
ose continuation barriers of delimited continuations.=20
>=20
>  If you look at the source of parameterize, with-fluids, with-fluids* (an=
d more?) in boot-9 ther are all using scheme functions, or things defined i=
n the VM, whereas srfi-39 depends on with-fluids* that is defined in fluids=
.c.=20
>=20
> If the transform from let to let* extends to with-fluids->with-fluids* it=
 should be a trivial thing to put into boot-9.scm, but I rarely dabble with=
 dynamic environments and whatever is in the documentation is somewhat opaq=
ue.=20
>=20
> Best regards
>   Linus Bj=C3=B6rnstam
>=20
> On Tue, 11 Feb 2025, at 11:59, W. Kosior via Bug reports for GUILE, GNU's=
 Ubiquitous Extension Language wrote:
> > Hello,
> >
> > I've been experimenting with guile-fibers.  I noticed that
> > `with-parameters*' procedure included as an "extra" in Guile's srfi-39
> > creates a continuation barrier.  From the documentation it is not clear
> > that it does so.
> >
> > Consider this sample program (which I ran with Guile 3.0.9 and Fibers
> > 1.0.0, as they are defined in Guix
> > 2fda889ac992977af7b4cd96d09f737d834e0b2d):
> >
> > --8<---------------cut here---------------start------------->8---
> > (use-modules (fibers)
> >              (fibers channels)
> >              (srfi srfi-18)
> >              ((srfi srfi-39) #:select (with-parameters*)))
> >
> > (define %my-channel
> >   (make-channel))
> >
> > (define %my-param
> >   (make-parameter #f))
> >
> > (define %my-thread
> >   (make-thread (lambda ()
> >                  (run-fibers (lambda ()
> >                                (with-parameters* (list %my-param) '(hel=
lo)
> >                                  (lambda ()
> >                                    (put-message %my-channel (%my-param))
> >                                    'ok)))))))
> >
> > (thread-start! %my-thread)
> >
> > (format #t "message: ~a~%" (get-message %my-channel))
> >
> > (thread-join! %my-thread)
> > --8<---------------cut here---------------end--------------->8---
> >
> > It prints:
> > =20
> >> Uncaught exception in task:
> >> In fibers.scm:
> >>    186:20  6 (_)
> >>    145:21  5 (_)
> >> In unknown file:
> >>            4 (with-fluids* (#<fluid 7f192cf70d70>) (hello) #<procedure=
 100903e0 at <=E2=80=A6>)
> >> In current input:
> >>     17:35  3 (_)
> >> In fibers/operations.scm:
> >>    154:10  2 (perform-operation _)
> >> In fibers/scheduler.scm:
> >>     357:6  1 (suspend-current-task _)
> >> In ice-9/boot-9.scm:
> >>   1685:16  0 (raise-exception _ #:continuable? _)
> >> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> >> Attempt to suspend fiber within continuation barrier =20
> >
> > But if I use `parameterize' rather than `with-parameters*', no errors
> > occur.  Here's an example of a working program:
> >
> > --8<---------------cut here---------------start------------->8---
> > (use-modules (fibers)
> >              (fibers channels)
> >              (srfi srfi-18))
> >
> > (define %my-channel
> >   (make-channel))
> >
> > (define %my-param
> >   (make-parameter #f))
> >
> > (define %my-thread
> >   (make-thread (lambda ()
> >                  (run-fibers (lambda ()
> >                                (parameterize ((%my-param 'hello))
> >                                  (put-message %my-channel (%my-param))
> >                                  'ok))))))
> >
> > (thread-start! %my-thread)
> >
> > (format #t "message: ~a~%" (get-message %my-channel))
> >
> > (thread-join! %my-thread)
> > --8<---------------cut here---------------end--------------->8---
> >
> > It prints:
> > =20
> >> message: hello =20
> >
> > Is it a bug that `with-parameters*' doesn't work equivalently?  Or am I
> > reading the info pages wrong?
> >
> > Best :)
> > Wojtek
> >
> > --
> > W. Kosior
> >
> > website: https://koszko.org/koszko.html
> > fediverse: https://friendica.me/profile/koszko/profile
> > PGP fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A =20



--Sig_/YQyxbn6uKdmyzH9+nQnL57V
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQTpcnBg48VjfIpPS0JLxSIcWnn9GgUCZ68gMAAKCRBLxSIcWnn9
GgSOAP0QNcnB1fNAx3lHoAgA5N0aaT8ljVrIBG7e2P1nwHoz/AEA/TGA0Z26hGyT
4MiqSgkcugOP2LAsWuGVrPRW7E/zRQg=
=5IuF
-----END PGP SIGNATURE-----

--Sig_/YQyxbn6uKdmyzH9+nQnL57V--

Last modified: Fri, 14 Feb 2025 11:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.