emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#53317: closed ([PATCH] Add guile-srfi-189.)


From: GNU bug Tracking System
Subject: bug#53317: closed ([PATCH] Add guile-srfi-189.)
Date: Tue, 18 Jan 2022 21:45:02 +0000

Your message dated Tue, 18 Jan 2022 22:44:25 +0100
with message-id <87pmood8hy.fsf@gnu.org>
and subject line Re: bug#53317: [PATCH] Add guile-srfi-189.
has caused the debbugs.gnu.org bug report #53317,
regarding [PATCH] Add guile-srfi-189.
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
53317: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=53317
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: [PATCH] Add guile-srfi-189. Date: Mon, 17 Jan 2022 14:20:07 +0100
* gnu/packages/guile-xyz.scm (guile-srfi-189): New variable.
---

this is mimicing guile-srfi-180.

please note that there's quite an anomaly among the guile-srfi packages,
including which guile they depend on, and the use of native-inputs vs.
inputs. it may be worth cleaning that up for someone with a better
overview of what's going on here.

 gnu/packages/guile-xyz.scm | 45 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index 74567830e6..6e46a8f376 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -3173,6 +3173,51 @@ (define-public guile-srfi-180
 API.")
       (license license:expat))))
 
+(define-public guile-srfi-189
+  (let ((commit "a0e3786702956c9e510d92746474ac988c2010ec")
+        (revision "0"))
+    (package
+      (name "guile-srfi-189")
+      (version (git-version "0" revision commit))
+      (source
+       (origin
+         (method git-fetch)
+         (uri (git-reference
+               ;; This is a fork of:
+               ;; (url 
"https://github.com/scheme-requests-for-implementation/srfi-189";)
+               ;; Upstream merge requested at:
+               ;; 
https://github.com/scheme-requests-for-implementation/srfi-189/pull/21
+               ;; TODO switch over to the official repo when the PR gets merged
+               (url "https://github.com/attila-lendvai-patches/srfi-189";)
+               (commit commit)))
+         (sha256
+          (base32
+           "0iqv4sjwbp4k87r9l9abzbs5yjcljm69m91kb1ypb03b0rx7napy"))
+         (modules '((guix build utils)))
+         (snippet
+          '(begin
+             (delete-file "test-syntax.scm")
+             (delete-file "test.scm")))
+         (file-name (git-file-name name version))))
+      (build-system guile-build-system)
+      (arguments
+       '(#:not-compiled-file-regexp "srfi/189\\.scm$")) ; it's INCLUDE'd
+      (native-inputs
+       (list guile-3.0))
+      (propagated-inputs
+       (list guile-srfi-145))
+      (home-page "https://srfi.schemers.org/srfi-189/";)
+      (synopsis "Scheme SRFI implementation of Maybe and Either")
+      (description
+       "This SRFI defines two disjoint immutable container types known as
+Maybe and Either, both of which can contain objects collectively known
+as their payload.  A Maybe object is either a Just object or the unique
+object Nothing (which has no payload); an Either object is either a Right
+object or a Left object.  Maybe represents the concept of optional values;
+Either represents the concept of values which are either correct (Right)
+or errors (Left).")
+      (license license:expat))))
+
 (define-public emacsy
   (package
     (name "emacsy")
-- 
2.34.0




--- End Message ---
--- Begin Message --- Subject: Re: bug#53317: [PATCH] Add guile-srfi-189. Date: Tue, 18 Jan 2022 22:44:25 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Hi,

Attila Lendvai <attila@lendvai.name> skribis:

> * gnu/packages/guile-xyz.scm (guile-srfi-189): New variable.
> ---
>
> this is mimicing guile-srfi-180.
>
> please note that there's quite an anomaly among the guile-srfi packages,
> including which guile they depend on, and the use of native-inputs vs.
> inputs. it may be worth cleaning that up for someone with a better
> overview of what's going on here.

I think it’s fine.

Applied, thanks!

Ludo’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]