From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 6GR7D6i2d2OVMgEAbAwnHQ (envelope-from ) for ; Fri, 18 Nov 2022 17:45:28 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id OBFxDqi2d2PvCwAAG6o9tA (envelope-from ) for ; Fri, 18 Nov 2022 17:45:28 +0100 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 AEE0519087 for ; Fri, 18 Nov 2022 17:45:27 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ow4U7-0003xv-HT; Fri, 18 Nov 2022 11:44:59 -0500 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 1ow4U6-0003xA-0U for guix-devel@gnu.org; Fri, 18 Nov 2022 11:44:58 -0500 Received: from mail-qv1-xf2f.google.com ([2607:f8b0:4864:20::f2f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ow4U3-0001r3-V7 for guix-devel@gnu.org; Fri, 18 Nov 2022 11:44:57 -0500 Received: by mail-qv1-xf2f.google.com with SMTP id df6so1476573qvb.0 for ; Fri, 18 Nov 2022 08:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:to:from:from:to:cc:subject:date :message-id:reply-to; bh=B6JFEF0YA0akhvNYSxoFk9pRFFm9YUG2UQ5g9qMoz+g=; b=o4ZvoHXSznQnMT/2krVZOnZ1to92+B8po4elIpxQ7D0QU8IvaUxCPJbG90rbPysB9N Nz3zwaib9vRLHZk1pnPONWhoZgaqb+MOv6xJTE0337RyigCjaqt5MSa8dT2kcmW0oZyQ ufgrD4UfwSWnh4+EiaqibfF54T0rCWUlZhKey++ujAiBV7e1HHTSmATKT8UDOJp3JPQ8 MYibG9P9Itnsnuy/RG93h2xoCQqSz7SfQKLwm9DVdoGYC0aJzh+vPV55yWziRjf49i8D 7nAtW/h9aLiQT/BEn188bxrEf86zqSx45+vWPVSq/f5JmjUPITDfyx4Q7alMUP+YXBrQ hhbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=B6JFEF0YA0akhvNYSxoFk9pRFFm9YUG2UQ5g9qMoz+g=; b=pTpsXI569PxH5aE3h0u4TUIwxBEPsycKOcbJ4G7UZYZN6EoZKIfEvs5Lf5tI0CApbf NCJFme2UML35xSDAcbsmY2YVtlfP78ao2HTsWGIgrgH9s34ekWHzp3Va9KNOlunKolk4 3Q94CuTBYULieyzeSSQPEsZ/pKFMm0fKV/QB/L/ekx2kC64TLOLvnzRDrjYkmXyHSVo4 Ymcymdl9ok+rYIVkyfhRrCh2gtGOOlMUVXOweS7/IK/as1+rQnx1W1qJGOk10nJqpHZZ MDTEhUQfDkwevQhygFpRfeAZjBIKXzo5aKTa0K8jdzfB/+VoToNEJ9pVQy/vigslAZKK +DdQ== X-Gm-Message-State: ANoB5pkda2Z776oOUGzbp0n0kJolVSDHG18e18P9VD4HBiOcOe30Bw7J f2tKQ59GWcdqWwz06sE5llFg0s6l6ds= X-Google-Smtp-Source: AA0mqf6PloNUb8gN1XfgcleTNQiT2/dclJavUayDKmCxEgSO8pAcD2Y6QlVzagNmOutyLvk+Wpk0xg== X-Received: by 2002:a0c:f604:0:b0:4ba:3ddb:a032 with SMTP id r4-20020a0cf604000000b004ba3ddba032mr7353924qvm.9.1668789894526; Fri, 18 Nov 2022 08:44:54 -0800 (PST) Received: from hurd (dsl-10-132-210.b2b2c.ca. [72.10.132.210]) by smtp.gmail.com with ESMTPSA id s68-20020ae9de47000000b006eed47a1a1esm2609533qkf.134.2022.11.18.08.44.53 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Nov 2022 08:44:54 -0800 (PST) From: Maxim Cournoyer To: guix-devel@gnu.org Subject: Re: Layout of =?utf-8?Q?=E2=80=98define-configuration=E2=80=99?= records References: <20221029034716.11125-1-maxim.cournoyer@gmail.com> <20221029041649.12144-1-maxim.cournoyer@gmail.com> <87zgcpdx6q.fsf_-_@gnu.org> Date: Fri, 18 Nov 2022 11:44:53 -0500 In-Reply-To: <87zgcpdx6q.fsf_-_@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s?= =?utf-8?Q?=22's?= message of "Thu, 17 Nov 2022 23:37:49 +0100") Message-ID: <8735ag43ga.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::f2f; envelope-from=maxim.cournoyer@gmail.com; helo=mail-qv1-xf2f.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1668789927; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=B6JFEF0YA0akhvNYSxoFk9pRFFm9YUG2UQ5g9qMoz+g=; b=gdzklQ8FvGZM662y8kt138waPrpcrLtuLwgg+JeuRwn+rgDwXtJ0IoJbjQwozVtGq2FiO2 SIxSXXurIyEHJA4eBR6KwUYOy6AKGcNfAty/ngLSJ2yybwZTT/7phGrV6l4Eg6CA7Jctai OGRKkljdHkjMpG1n9G+kkiCMg84FKGKhZTYrmrZ15d27X8WRWd6GJC7PLv/h14njHMFtB/ 5+DqdXvWG0+mSPNwRuDpxfYJqq319qMHtg6b2QBC7iD7f6CxRz3ytW3ruIrp63VFbSZW3R omrSED3qQECMe50WoMuH4BxvTQ3c4HNpmk0q363U9pL7S5MfEpaIw84JIYRv6Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1668789927; a=rsa-sha256; cv=none; b=qfD0tqbQ3lKBHAVTnZTP0sQLyVYuVD12PvKrZYfsnr4Z4udA88WtBRdsLcHXEu0JEUgI8c +HZGEyAS75J92Lcx1kszrLweF1Ix8/cxtk6+3eorZw0a0AAYlFYYIL/qKYMZM2AK0r5o5j SNg1OkJxN9S+8HFkHP0zCLQkzJORFu5eT5Syf7bof15OSw2eirFiSOuD1wxmxVHgpxNCzd ajL2jJNcyZZKTmBWorceGTD3X7+cC38OReGr9X/7ifcDvrMojFdhPyoaPzXNnlsTJ+Rm67 Bx3I7ZvbK3/PzbG0sGmXyVFPW+4FfH4I7kaCPKDhVTtSRT4B5rasMx87wJKgcg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=o4ZvoHXS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -6.72 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=o4ZvoHXS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: AEE0519087 X-Spam-Score: -6.72 X-Migadu-Scanner: scn0.migadu.com X-TUID: asB74gLxcTfe Hi Ludo, Ludovic Court=C3=A8s writes: > Hi, > > Maxim Cournoyer skribis: > >> This is so that the first field of the generated record matches the firs= t one >> declared, which makes 'define-configuration' record API compatible with >> define-record-type* ones. >> >> * gnu/services/configuration.scm (define-configuration-helper): Move the >> %location field below the ones declared by the user. >> * gnu/services/monitoring.scm (zabbix-front-end-config): Adjust match pa= ttern >> accordingly. > > [...] > >> +++ b/gnu/services/configuration.scm >> @@ -242,17 +242,17 @@ (define-record-type* #,(id #'stem #'< #'stem #'>) >> stem >> #,(id #'stem #'make- #'stem) >> #,(id #'stem #'stem #'?) >> - (%location #,(id #'stem #'stem #'-location) >> - (default (and=3D> (current-source-location) >> - source-properties->location)) >> - (innate)) >> #,@(map (lambda (name getter def) >> #`(#,name #,getter (default #,def) >> (sanitize >> #,(id #'stem #'validate- #'stem #'-= name)))) >> #'(field ...) >> #'(field-getter ...) >> - #'(field-default ...))) >> + #'(field-default ...)) >> + (%location #,(id #'stem #'stem #'-location) >> + (default (and=3D> (current-source-location) >> + source-properties->location)) >> + (innate))) > > Moving the field last is problematic as we=E2=80=99ve seen for any user t= hat > uses =E2=80=98match=E2=80=99 on records=E2=80=94something that=E2=80=99s = not recommended but still used > a lot. Yep. I had that on mind when I made the change, though I still missed a few occurrences. >> (define (zabbix-front-end-config config) >> (match-record config >> - (%location db-host db-port db-name db-user db-password db-secret-fi= le >> - zabbix-host zabbix-port) >> + (db-host db-port db-name db-user db-password db-secret-file >> + zabbix-host zabbix-port %location) > > This change has no effect because =E2=80=98match-record=E2=80=99 matches = fields by name, > precisely to avoid problems when changing the layout of record types. Good catch; I got confused there, although my confusion luckily had no side effect :-). > I=E2=80=99m not sure what was meant by =E2=80=9Ccompatible=E2=80=9D in th= e commit log; how > fields are laid out is something user code should not be aware of. I wanted match on define-configuration'd fields to be backward-compatible with fields migrated from define-record-type*, so that they such change can be made without worrying breakages. It seems good for consistency that both our define-record-type* and define-configuration fields share a similar internal layout, at least until all the old-fashion (ice-9 match) record matching usages are rewritten to use something like 'match-record'. I initially got tricked by that discrepancy and it took me quite some time hunting down a cryptic backtrace when authoring the new mcron configuration records. > The only thing to keep in mind is that records must not be matched with > =E2=80=98match=E2=80=99 because then the code silently breaks when the re= cord type > layout is changed. This is why =E2=80=98match-record=E2=80=99 was introd= uced: > > https://issues.guix.gnu.org/28960#4 > > One last thing: placing =E2=80=98%location=E2=80=99 first can let us impl= ement: > > (define (configuration-location config) > (struct-ref config 0)) Would this have worked? --8<---------------cut here---------------start------------->8--- scheme@(gnu services mcron)> (define config (mcron-configuration)) scheme@(gnu services mcron)> (struct-ref 0 config) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure struct-ref: Wrong type argument in position 1 (expecting struc= t): 0 Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(gnu services mcron) [1]> ,q scheme@(gnu services mcron)> ,use (oop goops) scheme@(gnu services mcron)> (class-of config) $5 =3D #< <> 7fe20fd83e00> --8<---------------cut here---------------end--------------->8--- All in all, I think that's a rather small change that got our internal implementation of both type of records in sync between define-configuration and define-record-type*, that should pave the way for migrating more of the later to the former without risking breaking something, going forward. Alternatively, if we have a good reason to not to go with this, I think we should abstract all the internal-implementation dependent code from our code base (e.g., the match patterns directly matching on field slots). What do you think? --=20 Thanks, Maxim