From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Taylan Kammer Newsgroups: gmane.lisp.guile.bugs Subject: bug#72368: srfi-64: test-begin does not set test-runner-test-name Date: Mon, 30 Sep 2024 18:09:47 +0200 Message-ID: <702df1ed-b404-4cda-8115-b56dfd54fd80@gmail.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0Z7Hc0g9PeVPyNoNbTcLSQb0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21643"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird To: Tomas Volf <~@wolfsden.cz>, 72368@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Mon Sep 30 18:12:19 2024 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1svJ0V-0005PV-6d for guile-bugs@m.gmane-mx.org; Mon, 30 Sep 2024 18:12:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1svIzk-000275-Ez; Mon, 30 Sep 2024 12:11:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1svIzh-000262-H1 for bug-guile@gnu.org; Mon, 30 Sep 2024 12:11:29 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1svIzh-00033E-8D for bug-guile@gnu.org; Mon, 30 Sep 2024 12:11:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=fBstjhoCAXVV5u2wWmno+pvmk4glPXUbDbQSrGMlBTo=; b=ZtTXA8h+VFvTvChVKGL+zhmrlXwB8SfFsbI9GmYkKy+Twc0pKaYmCmofEtTW/L002Urm5CDuWp5m1kyd/iByvPkXM8M0lMJT3noDiXkDTWem5gbQpYBGknM9p6AQAjI1Y5IoRcnQCG29gyVbwNo+ShBsG6EFJqyjdb4NmiYeyX+l5Bhz6N2GxdZusJfIwpRP+WwQWzqOK25dccSMO24Ip1S7iAKcc9il1ZzdTEF5zbpLcwIkoCTs8sQv5wNek94Dh9xL7AeJLMwUwwAVGsUbe27cgwM1HU38W/BcqOoxtekzecJqJIPWbSasStVRNTRiA18MBNvkvtk5fn9MmGE85Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1svJ0D-0001Vk-Rh for bug-guile@gnu.org; Mon, 30 Sep 2024 12:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Taylan Kammer Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 30 Sep 2024 16:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72368 X-GNU-PR-Package: guile Original-Received: via spool by 72368-submit@debbugs.gnu.org id=B72368.17277126905785 (code B ref 72368); Mon, 30 Sep 2024 16:12:01 +0000 Original-Received: (at 72368) by debbugs.gnu.org; 30 Sep 2024 16:11:30 +0000 Original-Received: from localhost ([127.0.0.1]:45665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svIzh-0001VF-AW for submit@debbugs.gnu.org; Mon, 30 Sep 2024 12:11:29 -0400 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:40588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svIzf-0001V7-TH for 72368@debbugs.gnu.org; Mon, 30 Sep 2024 12:11:28 -0400 Original-Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-37cdab63866so213848f8f.2 for <72368@debbugs.gnu.org>; Mon, 30 Sep 2024 09:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727712589; x=1728317389; darn=debbugs.gnu.org; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=fBstjhoCAXVV5u2wWmno+pvmk4glPXUbDbQSrGMlBTo=; b=HSpJVFAqjLjgSfmzbwHav83GYVW2oq6cvRdMDgDGlznVUd5oh4//W5bwwaNKNk3BX8 VwRyA5BpuSwfqk/df6Td5gKI64/4HNZbi6ottGiMkOJbZDKxBwOrsuXIaq2yViak/Ev3 R6uHedKx7nCNFDNRLMmgkDsV2tx68JoRH6eRf9wVu/DZk+xAe7IqILUlBZIyZ8qJoACf +7Nd7zHGFtUM+O6caFHA2mGcUpUpGLSU+i9GdNoKcja2kxvMrGDabBD+I9Pke3r1We18 /yw9IPpLdAKNXleTCaw7WTVlGrERYt2kMlUbhdhKAUMEl2Qc5fkg0TkpWlF311x4+O9v uWRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727712589; x=1728317389; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=fBstjhoCAXVV5u2wWmno+pvmk4glPXUbDbQSrGMlBTo=; b=gKjrEJfSkQPUNuTH8BFWjC98F74JBLDmFZUwLYXI2iCjxyWpoFWbR+uZocTZXx0fN+ n0HXVhUDkAjJ7KWfnpzYtFfgJs9CLF3cLqcLlGhmmKk6xYZnCcqPwAAbAU/30fKAIpHM s8I2y6aZqbtaIidDxs9ZtbB0fcj0lfja5XhhHyNFtGVYO205BehH4oJn1U5WqNdu/2Nl 9hnIIW8yYht5SD3aZHmpFYsWqAnIPnrvcGZyE06jnhKQaGvL6tO/o50nFyXG21HiZJLU jF0IANGfS4zirOhJYdUoTy2P1MLrsMSuncgxijxgl2RI3iLj0hmh7b0k6ta2TDVSVlih PofQ== X-Forwarded-Encrypted: i=1; AJvYcCVIDOBfQH3TyyM/nmSs7y6VAJj7AFA0teudYOvohHVosGj9vZntPKljHcbznc/kMIVS0bKSIw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyP4/ayYKISwZ1Jhd7FtHlAJizzXz/sem4dYhJahowrGSXvYyHw lDg9YtD5bjDx3tCkLcikT2zupZXgXMftHjqrvNL2rjODbVSOfumq X-Google-Smtp-Source: AGHT+IFjafO+J2d4KAzRCfeF5E2S6mT8sWHlbeiu9wmAnBvGEMywjDusX3YdzJkAb2r9stXv4uWQVg== X-Received: by 2002:a05:6000:2a2:b0:378:9560:330 with SMTP id ffacd0b85a97d-37cde44b498mr2369118f8f.13.1727712588596; Mon, 30 Sep 2024 09:09:48 -0700 (PDT) Original-Received: from ?IPV6:2003:106:8f04:c300:192e:476d:8ae3:22f2? (p200301068f04c300192e476d8ae322f2.dip0.t-ipconnect.de. [2003:106:8f04:c300:192e:476d:8ae3:22f2]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37cd565e48fsm9282665f8f.39.2024.09.30.09.09.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Sep 2024 09:09:48 -0700 (PDT) Content-Language: en-US In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.bugs:10997 Archived-At: This is a multi-part message in MIME format. --------------0Z7Hc0g9PeVPyNoNbTcLSQb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 30.07.2024 21:51, Tomas Volf wrote: > Hello, > > I think I found a bug in (srfi srfi-64) module shipped with GNU Guile. > > The specification says the following regarding the test-runner-test-name: > >> Returns the name of the current test or test group, as a string. During >> execution of test-begin this is the name of the test group [..] > Thus I believe that following should print `x': > > (use-modules (srfi srfi-64)) > (let ((r (test-runner-null))) > (test-runner-current r) > (test-runner-on-group-begin! r > (λ (runner suite-name count) > (pk (test-runner-test-name r)))) > (test-begin "x")) > > However it does not: > > ;;; ("") > > Have a nice day > Tomas Volf I think the spec *may* have meant to say "between test-begin and test-end" or "during execution of a test group" rather than "during execution of test-begin." The reason I think so is that the on-group-begin handler is also called before the new name is added to the stack. So, still having the old name at that point would be consistent. But this may also have all been unintentional, because the implementation of test-runner-test-name is kind of hacky (uses the name from the test-result alist). If we take the spec literally, you are right in that it should set the name before calling the on-group-begin handler. And I think that's more intuitive anyway. So, I agree that this is best seen a bug, and I believe I've now fixed it in my implementation with this commit:     https://codeberg.org/taylan/scheme-srfis/commit/16ef0d987c99df7d488e6f4b3fef41d972a7552c Now my code behaves as follows: scheme@(guile-user)> ,use (srfi srfi-64) ;;; note: source file /home/taylan/src/scheme-srfis/guile-srfi-64/srfi/srfi-64.scm ;;; newer than compiled /usr/lib/x86_64-linux-gnu/guile/3.0/ccache/srfi/srfi-64.go ;;; found fresh local cache at /home/taylan/.cache/guile/ccache/3.0-LE-8-4.6/home/taylan/src/scheme-srfis/guile-srfi-64/srfi/srfi-64.scm.go scheme@(guile-user)> (let ((r (test-runner-null))) (test-runner-current r) (test-runner-on-group-begin! r (λ (runner suite-name count) (pk 'group-begin (test-runner-test-name r)))) (test-runner-on-test-begin! r (λ (runner) (pk 'test-begin (test-runner-test-name r)))) (test-runner-on-test-end! r (λ (runner) (pk 'test-end (test-runner-test-name r)))) (test-runner-on-group-end! r (λ (runner) (pk 'group-end (test-runner-test-name r)))) (test-runner-on-final! r (λ (runner) (pk 'final (test-runner-test-name r)))) (pk 'before-begin (test-runner-test-name r)) (test-begin "x") (pk 'within-group (test-runner-test-name r)) (test-assert "x1" #t) (pk 'within-group (test-runner-test-name r)) (test-end "x") (pk 'after-end (test-runner-test-name r))) ;;; (before-begin "") ;;; (group-begin "x") ;;; (within-group "x") ;;; (test-begin "x1") ;;; (test-end "x1") ;;; (within-group "x") ;;; (group-end "x") ;;; (final "") ;;; (after-end "") $1 = "" scheme@(guile-user)> Further, to make the point at which the name is changed consistent with the point at which the group stack is changed, I've modified my implementation to call the on-group-begin handler *after* the stack is modified:     https://codeberg.org/taylan/scheme-srfis/commit/9f247f9b8d3bca2c9f9fe26581cd8f695714a8aa >From what I can tell, this doesn't contradict anything in the spec, though it is a deviation from what the reference implementation does in practice. I think it's better this way, because otherwise the current name will be inconsistent with the topmost name in the group stack during on-group-begin. The downside is that there could theoretically be code out there that relies on the behavior of the reference implementation, but I see this as being quite unlikely and it would be easy to fix such code. Opinions welcome. - Taylan --------------0Z7Hc0g9PeVPyNoNbTcLSQb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 30.07.2024 21:51, Tomas Volf wrote:
Hello,

I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.

The specification says the following regarding the test-runner-test-name:


Returns the name of the current test or test group, as a string. During
execution of test-begin this is the name of the test group [..]

Thus I believe that following should print `x':

    (use-modules (srfi srfi-64))
    (let ((r (test-runner-null)))
      (test-runner-current r)
      (test-runner-on-group-begin! r
        (λ (runner suite-name count)
          (pk (test-runner-test-name r))))
      (test-begin "x"))

However it does not:

    ;;; ("")

Have a nice day
Tomas Volf

I think the spec *may* have meant to say "between test-begin and test-end" or "during execution of a test group" rather than "during execution of test-begin." The reason I think so is that the on-group-begin handler is also called before the new name is added to the stack. So, still having the old name at that point would be consistent. But this may also have all been unintentional, because the implementation of test-runner-test-name is kind of hacky (uses the name from the test-result alist).

If we take the spec literally, you are right in that it should set the name before calling the on-group-begin handler. And I think that's more intuitive anyway. So, I agree that this is best seen a bug, and I believe I've now fixed it in my implementation with this commit:

    https://codeberg.org/taylan/scheme-srfis/commit/16ef0d987c99df7d488e6f4b3fef41d972a7552c

Now my code behaves as follows:

scheme@(guile-user)> ,use (srfi srfi-64)
;;; note: source file /home/taylan/src/scheme-srfis/guile-srfi-64/srfi/srfi-64.scm
;;;       newer than compiled /usr/lib/x86_64-linux-gnu/guile/3.0/ccache/srfi/srfi-64.go
;;; found fresh local cache at /home/taylan/.cache/guile/ccache/3.0-LE-8-4.6/home/taylan/src/scheme-srfis/guile-srfi-64/srfi/srfi-64.scm.go
scheme@(guile-user)> (let ((r (test-runner-null)))
  (test-runner-current r)
  (test-runner-on-group-begin! r
    (λ (runner suite-name count)
      (pk 'group-begin (test-runner-test-name r))))
  (test-runner-on-test-begin! r
    (λ (runner)
      (pk 'test-begin (test-runner-test-name r))))
  (test-runner-on-test-end! r
    (λ (runner)
      (pk 'test-end (test-runner-test-name r))))
  (test-runner-on-group-end! r
    (λ (runner)
      (pk 'group-end (test-runner-test-name r))))
  (test-runner-on-final! r
    (λ (runner)
      (pk 'final (test-runner-test-name r))))
  (pk 'before-begin (test-runner-test-name r))
  (test-begin "x")
  (pk 'within-group (test-runner-test-name r))
  (test-assert "x1" #t)
  (pk 'within-group (test-runner-test-name r))
  (test-end "x")
  (pk 'after-end (test-runner-test-name r)))

;;; (before-begin "")

;;; (group-begin "x")

;;; (within-group "x")

;;; (test-begin "x1")

;;; (test-end "x1")

;;; (within-group "x")

;;; (group-end "x")

;;; (final "")

;;; (after-end "")
$1 = ""
scheme@(guile-user)>

Further, to make the point at which the name is changed consistent with the point at which the group stack is changed, I've modified my implementation to call the on-group-begin handler *after* the stack is modified:

    https://codeberg.org/taylan/scheme-srfis/commit/9f247f9b8d3bca2c9f9fe26581cd8f695714a8aa

From what I can tell, this doesn't contradict anything in the spec, though it is a deviation from what the reference implementation does in practice. I think it's better this way, because otherwise the current name will be inconsistent with the topmost name in the group stack during on-group-begin.

The downside is that there could theoretically be code out there that relies on the behavior of the reference implementation, but I see this as being quite unlikely and it would be easy to fix such code. Opinions welcome.


- Taylan

--------------0Z7Hc0g9PeVPyNoNbTcLSQb0--