From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 6D6jOgEf8WJtmAAAbAwnHQ (envelope-from ) for ; Mon, 08 Aug 2022 16:34:42 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id sAGMOgEf8WInEQAAauVa8A (envelope-from ) for ; Mon, 08 Aug 2022 16:34:41 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 6D5523FBC8 for ; Mon, 8 Aug 2022 16:34:41 +0200 (CEST) Received: from localhost ([::1]:46306 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oL3q4-000722-H4 for larch@yhetil.org; Mon, 08 Aug 2022 10:34:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45818) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL3pS-0006zq-6j for guix-patches@gnu.org; Mon, 08 Aug 2022 10:34:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:51687) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oL3pR-0001V1-Tp for guix-patches@gnu.org; Mon, 08 Aug 2022 10:34:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oL3pR-0001r9-KF for guix-patches@gnu.org; Mon, 08 Aug 2022 10:34:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#56989] [PATCH v3] gnu: Add dbqn. Resent-From: Christopher Rodriguez Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 08 Aug 2022 14:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56989 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxime Devos Cc: Christopher Rodriguez , 56989@debbugs.gnu.org Received: via spool by 56989-submit@debbugs.gnu.org id=B56989.16599691997071 (code B ref 56989); Mon, 08 Aug 2022 14:34:01 +0000 Received: (at 56989) by debbugs.gnu.org; 8 Aug 2022 14:33:19 +0000 Received: from localhost ([127.0.0.1]:41436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oL3ok-0001pz-Tm for submit@debbugs.gnu.org; Mon, 08 Aug 2022 10:33:19 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:42968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oL3oi-0001pj-Fb for 56989@debbugs.gnu.org; Mon, 08 Aug 2022 10:33:17 -0400 Received: by mail-qt1-f169.google.com with SMTP id w26so1738228qtv.9 for <56989@debbugs.gnu.org>; Mon, 08 Aug 2022 07:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc; bh=QQLlU9m67noa7hDHmibIeZzHxQ3C7gXmndAiuqwCSDY=; b=LWrxltKFm018W0yUBo38WhF+bK3pEWtSJMwNs5/Kz7OFrg4PWToFBZeHkgRYBgW36Q BdGd3DHIJQUQgpfh0wLLvd97k/gQVflKUoWv7HgouV0VgQ+sx8ctIn7ZRXvHWTtxa8tz n0bh9xbysAVDUPTKeUu+hAtlLKbzvrDMDdiVrFE7Ek2ySJpcACLSKrgElIZfnjw7l+Sl 0b5UtttAPAl3gIoK6pxqZOars5r8A6zerqW2xJ8tt8W0tv9KalqWJxQG7qyeKQ3T7txX 6cVg7EsQ1jgYuvpWeqkyvASVwGCfy+sdpNDC34rUqjBX+sB5+T2/8DnvcYIVZUgp+ROB Aqlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc; bh=QQLlU9m67noa7hDHmibIeZzHxQ3C7gXmndAiuqwCSDY=; b=H7418+Pn9d+9/alGdxWZeMTN0GeO8xAs3/MYv/AMNEue9LI0PlhELoVFlnLJXGTqc/ qrGTAPvquPRu/yXLFAqw9M1xChz9SYFzwyvOZc5WYl8ewIxdzokgOULWwjpE7BvqjT1Q i7R0TRl3HoFa1FcErpPIX8uynrvxDMAzx+BP1/iHrM17D3sxK0E9DhWJVuWwqab8svPQ q2QCHSLahTJCK1uzseo0Gl/ZJTaXPx1w1EdXK+GX8bqdylZWdnkBcDjixpox2rUSoYiD e96C1Sysp4n98NnV99iC93azePdri+BRAppazp7yCeaLj3HDAaXI5vWlsG0+qC1a2/1x wFDw== X-Gm-Message-State: ACgBeo3WBXhwydC0xlhznuIvktu6RCjUCyuFx7F+LKJEib5Ih6lSiOFw K/+bG847HdGVwpweQtscTvA= X-Google-Smtp-Source: AA6agR58Jk1ICckxx1y41UWKejbHwLvMkXa7zpsbfWUtYGBgVjlfOKlJBJrkcnS6TQlHu08ghtwo2A== X-Received: by 2002:a05:622a:1052:b0:31e:fcb3:4aa2 with SMTP id f18-20020a05622a105200b0031efcb34aa2mr16361283qte.399.1659969190694; Mon, 08 Aug 2022 07:33:10 -0700 (PDT) Received: from gmail.com (ec2-44-193-71-234.compute-1.amazonaws.com. [44.193.71.234]) by smtp.gmail.com with ESMTPSA id x8-20020a05620a258800b006b5e45ff82csm9678256qko.93.2022.08.08.07.33.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Aug 2022 07:33:09 -0700 (PDT) References: <20220805022023.5044-1-yewscion@gmail.com> <20220806022022.24054-1-yewscion@gmail.com> <00125176-9e1f-6d91-21d8-0d2fd9558aca@telenet.be> User-agent: mu4e 1.8.7; emacs 28.1 From: Christopher Rodriguez Date: Mon, 08 Aug 2022 09:54:33 -0400 In-reply-to: <00125176-9e1f-6d91-21d8-0d2fd9558aca@telenet.be> Message-ID: <87h72mx0t7.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1659969281; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=QQLlU9m67noa7hDHmibIeZzHxQ3C7gXmndAiuqwCSDY=; b=j5t+jYPuvRcvvIWdwZfHhm/CvoVuABWGtdFuJGF/r7e5kE0/phx04BRLUEXqdBjqUBzT1q P5Y9WJ7qTUnIXm4tjo65UmG8n8pDVDD6oiICRcoEA8Sq2G0VS+GgNiQd/wEiX0wpTs8JI2 geHP2hMOrVtV9hDUEeqcu9foesk7EV0BEMyRJghsbCYSMt78jRiVJYB6Ooc0N5IJLDBQ8a D6XLhHC2Jkaipy7IsINyVa7j98/NjYjOK2b6fnl0o+umferm30hYKuZhkGzD6iAqYse4ax tjy2UbeJzgU0TJZM90vvNzQATNq29zar9LMONYw6VAHNJxbLkusyw6kY3k1H1w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1659969281; a=rsa-sha256; cv=none; b=qvDrSKzeOQC6sFcchG6RzmtUSisTXIPkdo6Zn7I7F7AHyYTbaLK1R+Yu6jYimb8o0Tf/NA Lp92gl0jFAk24BwY9ziGgEdV/K3odkyRYnH3NWAsoT/qvv2iNu6L7ug0VqH5EtYwGgwB+7 0JRTuCPPf0xXKEmHD1e+jWdQW6tpwrNkg422Tf8437Wtm4dWOPGyVr1wmPV1sZvscaWAZV x84VVJzTHrjOS17UGJUa1FY+3kdIvuLfioFYpx7MFSAdb3Y7wKZ6vHzrmYitPKsp++IHUu ff0mVB9rCq7swaw55J/KhDhtdzJoZBTichSjQXMyfXYvC4ataONbYp7xoGYcbQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=LWrxltKF; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 4.01 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=LWrxltKF; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 6D5523FBC8 X-Spam-Score: 4.01 X-Migadu-Scanner: scn1.migadu.com X-TUID: euLCE4FeqzhP --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Maxime Devos writes: > Copyright and license headers are missing. Also, usually we don't do > per-package modules but rather thematic modules, though that's not a hard > rule especially if there are technical problems with that. Ah, right, I forgot about those. Not used to creating new files. Will be in the patch I'm sending shortly. As for the per-package rule, this will not be the only package for this file. Aside from the 2 user-facing packages and 3 bootstrap packages in this series, I'm hoping to package a further (at least) 3 packages=E2=80=94a standard library, a DSL, and a primer (info). I'm also hoping to package an emacs mode, a few fonts, and an update to a few packages to add BQN support. But those have their own files, and won't be included here. Is that enough of a justification for a new file, or should I look to add this to another? I /suppose/ apl.scm would work, though technically that would be like scheme, common lisp, arc, clojure, et al being grouped in the same language. WDYT? > I don't think you are using (guix deprecation) below? I don't think I am either, now that You mention it. Somehow that made its way into my starting template; I will remove it in the forthcoming patch. > I have looked at the 'v0.2.1' tag, and it points at the 0bbe096... commit= , so > you are actually packaging version 0.2.1, not some git commit after > v0.2.1. As such, no need for (git-version ...), you can just write "0.2.1" > there. Then 'revision' becomes unused and can be dropped, and 'commit' is > only used in a single place anymore so it can be inlined. This honestly confused me a bit at first, but I think I see what You mean now. Since it's an official upstream version, that can be the version, instead of using git-version. I will apply these changes as well. >> + (native-inputs (list `(,icedtea-8 "jdk") coreutils zip)) > coreutils is an implicit (native-)input, likely no need to to mention it. > > Also, the Makefile mentions that the executable to start things has > #!/bin/bash -- to properly patch is when cross-compiling, you need > 'bash-minimal' or 'bash' in inputs, otherwise it will be patched for the > wrong architecture. > > Also, that script runs 'java' -- make sure it is patched too such that ja= va > will actually be found -- and to patch it, you need to have icedtea:out or > openjdk:out in 'inputs'. Per the feedback I received from Liliana, I will use icedtea:out to (as there is less bootstrapping required if building everything from source). I'll also add bash-minimal in place of the unneeded coreutils, and place both icedtea:out and bash-minimal in inputs rather than native, as they are expected for the target machine. >> + (outputs '("out")) > That's the default, no need to set it. >> + (list #:imported-modules `(,@%gnu-build-system-modules (guix bui= ld >> + sys= calls) > For formatting, (guix build syscalls) should be on a separate line. >> + (synopsis "BQN implementation based on dzaima/APL") >> + (description "BQN implementation based on dzaima/APL.") > The synopsis and description are identical, and this doesn't explain much= to > people who don't know what 'BQN' is. Can it be rewritten such that people= not > familiar with BQN can decide whether this =E2=80=98BQN=E2=80=99 is someth= ing that's useful > for them? '(guix)Synopses and Descriptions' has more information. >> + (lambda* (:#key tests? >> + #:allow-other-tags) > Why the : before #:key? Also, no need to break it in separate lines. All of these points are addressed in the forthcoming (v4) patch. In particular, thanks for calling out the description: It had been a placeholder while I was getting things working, and I'm happy to replace it with something more descriptive. And the `:#key` was a typo, unsure how it has worked thus far, as I had tests disabled up until recently. Maybe I was using the stock check phase, then. I forget, tbh. >> + (add-after 'install 'reorder-jar-content >> + (lambda* (#:key outputs #:allow-other-keys) >> + (apply (assoc-ref ant:%standard-phases >> + 'reorder-jar-content) >> + #:outputs (list outputs)))) > 'output's is a list of strings, now you are giving reorder-jar-content a = list > of lists of strings > However, looking at (guix build ant-build-system), it looks like it just > wants a list of strings. > > As such, maybe it should be: > > (add-after 'install 'reorder-jar-content > =C2=A0 (assoc-ref ant:%standard-phases 'reorder-jar-content)) > > ? (untested)=C2=A0 Possibly likewise for the other phases. This intrigues me. The list of outputs was a kludge to allow the function to accept the singleton output. If the singleton is still wrapped in a list, then I'm unsure why it fails. Perhaps I need to test this more; will do so before sending v4. >> (the implementation is even under single-license GPL!) [...] > You are writing license:expat in the 'license' field, not > license:gplN/license:gplN+. Is it Expat or is it GPL? So, this package (dbqn) is expat. The implementation I referenced above (which is recommended and actively developed) is a different one (cbqn) that relies on this one as a dependency for bootstrapping, and is under gpl. I really just wanted to add cbqn to guix, but can't do so without dbqn, which /is/ still functional, is depended on by a bunch of tooling for the language, and may as well also be a package because of the above (sort of like how someone using common lisp may view clisp as a slow dependency of sbcl, or they may instead choose to use it as their target implementation). >> + (synopsis "Official BQN sources in BQN") > If they are just sources, you can do (define bqn-bytecode-sources (origin > ...)) I had not realized the package was unneeded! That might simplify things greatly. I love packaging things for guix; I always learn something new. >> + (home-page"https://github.com/mlochbaum/BQN.git") >> + (license license:gpl3)))) > The 'LICENSE' file says something different. I don't think that's the home > page, maybe instead? So, is the homepage of the language, but the sources we're using are only a part of that language definition. In particular, we're only using the src/ and test/ directories of that repository. We're ignoring the docs, commentary, editor plugins, fonts, implementation instructions, spec, tutorial, javascript implementation, etc. We really are just targetting the sources for the bytecode and the tests, which is why I thought the repo itself makes a better homepage. Should I change that to the homepage for the language? As for the LICENSE file, indeed, it is isc. Thanks for the catch. > >> + (chmod "BQN" 493) > Hexadecimal would be clearer. As in Your second message, I will use the octal notation per Liliana. >> + "The expected implementation for the BQN language, >> +according to the official documentation of that specification.") > expected -> standard (what's 'expected' depends on the user, they might w= ant > a different implementation), unless it's not the standard implementation. > > 'documentation of that specification' -> 'the specification (pleonasm) > > And maybe remove 'official', given the absence of 'official' in the > descriptions of, say, guile, gcc, openjdk and java, this sounds marketing= and > unfair to me. I will change this to "The standard implementation of the BQN language, according to the specification." (Also, thank You for teaching me 'pleonasm'!) > (singeli-bootstrap:) > >> + (let* ((tag "0") >> + (revision "1") >> + (commit "fd17b144483549dbd2bcf23e3a37a09219171a99") >> + (hash "1rr4l7ijzcg25n2igi1mzya6qllh5wsrf3m5i429rlgwv1fwvfji") >> + (version (git-version tag revision commit))) > I'm not seeing a '0' tag anywhere in the repository -- I dont see any tag= s at > all tere. There are none; I thought the absence of any tage necessitates a '0' for the version number, and wanted to keep the definitions standardized. Should I inline the 0 instead in the git-version? >> + (inputs (list bqn-bytecode-sources libffi singeli-bootstrap)))) > For cross-compilation, I would have expected sengili-bootstrap in > native-inputs, not inputs, assuming that it is used as a compiler. Does > cross-compilation (with --target) work? Singeli is written in BQN, which is an interpreted language. So, as long as the BQN interpreter is for the correct architecture, it will work. It will never be compiled itelf. Thank You for all of the feedback! I'll try to have a revised set of patches in by this evening EDT, in the next 8 hours. =2D- Christopher Rodriguez --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJMQbvYVxvZ0eF/84XZ6FgaGVz3sFAmLxHqQACgkQXZ6FgaGV z3uqJRAAjC1FB/NLE6/5KQpQrhPVq08yHVlpKBDDneJnAOooV87Xg0RpFi//xUJn RySRacvDI6OGjhcUiAA2/toUKULBzlw1gOZjJoZ4PBwhWyJQtfCHoskDmLo74G9f 7SbOQmRh385fmz5szdKETScJ6832KL3yVklfDpGhotoxn6EySG6mNoBFg7gCM0Il nDXoAI1UnUGrV+LhAExk76DnVGoYViPdle8kDObh9h3r8SJ45zE6qI25uKqwW4nc jb3nToZT9/dd22xyQmHiAjjoyjcm/MQjz2RgE8+tG8A+8irM6tijH4tVe2ky5N1g s326d/FrUEk46xWjUJZDhSarrm0s8ah0acI6RGqQ8PJBOgVkEN8mH/U7YVG6u4sx wvVYIDyxCK8RiQlO4PCJPe6+7vnZmOaEJGOerrqjpiBJqv1yiTGTcfvE7VYJtETh yQkNUd2ilwnliMVyBH8O0rSDF6ECJsLE17HzPwDUJPE+qBcwKKV2ssqFZ0bdVAmJ OcQahkRHuy2tuxeON+pF0RmXxsA1B2+qmzRg4IJ9ZR/tGhbs1m2QoiqNcqOiMOHp PqMBFkCnW8QKWOOsUfjRrdOZ9HFwRMINRAFlg1U9upg6NxOiYNrIBvfCmhc9RrnH rf9O2+3U1HeUSpzX83tX1j3+Z+BmJP0J8XP+PAV3FFYPOmRfbl4= =bee8 -----END PGP SIGNATURE----- --=-=-=--