From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id aI6xEfeCbWfv9AAAe85BDQ:P1 (envelope-from ) for ; Thu, 26 Dec 2024 16:23:19 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id aI6xEfeCbWfv9AAAe85BDQ (envelope-from ) for ; Thu, 26 Dec 2024 17:23:19 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=Iehl+VcL; dkim=fail ("headers rsa verify failed") header.d=whispers-vpn.org header.s=protonmail header.b=Vz5iNfCa; 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"; dmarc=pass (policy=none) header.from=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1735230198; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: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=ynF6RB1k+LELgoNfAUuH/RLrAAwPScBPO7FVGriTkV4=; b=dsDPYOhRJpA3ZLzWo+9+oJX+2R1lcWspGgOkF41/pxrJv9MjhVmRK+p+HgQjw0Qn0O6EfB e1cLaWFKfPpsG4CozJjbOejVJwjS4gYKsERpCN7ChmkfgMc03opzrfqZBkC/nQVU8LFh/v hMOamudzWRUAibSPyK8Cjlf5otF6TNYVcSZ8x3g3iUckGowA9tzMBpag65XS9ffeub7+kT BCTyvo9JJeX4cVk4cP4NPxoLn2FiQYwdqA4Qpp2vbU8lKVaPa7BH+s8bcRlsXS9fx6xove l5Y2iMRoeSdCse6w0rUVnvAmYRJOmD1KwFOWXcMq7VKxvgD8yukkpE7JWiS8Fw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=Iehl+VcL; dkim=fail ("headers rsa verify failed") header.d=whispers-vpn.org header.s=protonmail header.b=Vz5iNfCa; 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"; dmarc=pass (policy=none) header.from=gnu.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1735230198; a=rsa-sha256; cv=none; b=tiAv2WPJsnXtHKSxD0vMqWju+l3FssoS8bfw/1htcZS0zU+rLOePS25UrB5RInn8WKtcNG /pw5nJUIyx+nKBuTjPiove2jJ3v5uD1ErGN5+chH647Ky1Uz4D9w1zXdp8FwXLMX+ZJG2P PQbXsABlKVXnVj3gllE36mFh3uYpAdrWt6q1N/aw1saaZ9g3KX2uWuj3wcVT4+vwzVQQRY 2zRe6h/IVzPYuh+yRWMSLnNRkXyM6bFgWlqlZb2bdJ73BxsPKNV3QsTLRML5lBfMwpLZ+E 2zAXXDtaECFe7ooYP4cvHy1ZCr9LYBNOIp7EWS818JvI+H7QmQGojOh6DeiuVw== 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 4D3737AFFE for ; Thu, 26 Dec 2024 17:23:18 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQqdd-0000FP-EA; Thu, 26 Dec 2024 11:23:05 -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 1tQqdb-0000FG-8w for guix-patches@gnu.org; Thu, 26 Dec 2024 11:23:03 -0500 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 1tQqdb-0005Y3-0O for guix-patches@gnu.org; Thu, 26 Dec 2024 11:23:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:From:Date:To:In-Reply-To:References:Subject; bh=ynF6RB1k+LELgoNfAUuH/RLrAAwPScBPO7FVGriTkV4=; b=Iehl+VcLuuqJ8J6H7nPWT3at1m9/eRZ/buG9da/Geg/N00gF5G/6n50/lTIFzWcU3XldRUmjpeStaTgLdidUzZwlPz4/uYsaHmVjQxaNVkhlkCyyxC8tTg3J9H2mI9rA5iBLCMVTN4D1AyXznG9kFj4xsYvs5TAiFUE1v9vrh3qFP7U58U+X5kNGxmJJUbO0coLMt3lHx4G9MMg0cbE2bJFXUsYp2IjznII1NzbaIia4k+4w516MGjU+CafKhRX5WLUgeQSKPHiRMBBbRGDL/LjDDF8PtDxv84Q0DnYZWao+x2PiF+QmiuVtDutyKgOagA+rVUxgg/CKmajMTgRfPA==; Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tQqda-0006HC-Bd for guix-patches@gnu.org; Thu, 26 Dec 2024 11:23:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#75063] [PATCH 1/2] gnu: dict: Add symbols to help users configure FreeDict with dicod. References: In-Reply-To: Resent-From: Runciter Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 26 Dec 2024 16:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75063 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 75063@debbugs.gnu.org Received: via spool by 75063-submit@debbugs.gnu.org id=B75063.173523014924087 (code B ref 75063); Thu, 26 Dec 2024 16:23:02 +0000 Received: (at 75063) by debbugs.gnu.org; 26 Dec 2024 16:22:29 +0000 Received: from localhost ([127.0.0.1]:41979 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tQqd2-0006GQ-Vl for submit@debbugs.gnu.org; Thu, 26 Dec 2024 11:22:29 -0500 Received: from mail-40136.proton.ch ([185.70.40.136]:42055) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tQqcz-0006G9-My for 75063@debbugs.gnu.org; Thu, 26 Dec 2024 11:22:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=whispers-vpn.org; s=protonmail; t=1735230138; x=1735489338; bh=ynF6RB1k+LELgoNfAUuH/RLrAAwPScBPO7FVGriTkV4=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=Vz5iNfCamOvAM7RPbRjywNteG6y6yXy6AgJd3vx2XllyGyQsSZdaDv7eHdOT3jpvO AzLONTWEA7cwxArdjjsucy3yYz/mRmVQzqB1AbTIzSFVEq4hcIuaw9DfZ0fjp0hNf7 x9f6kFVdDSvI1pMbOClKmzoEiuagzrxldlbceIYyq2l4So+ps80aWZuD7pUUPUpI/J 30X4Dyek4RLe8LwM94vMSr9z7fIqKRbs+YTNwifMb2+0sfPNVHu3Xwf/64+Xgj4eiv op/GzzPiYbp5owT/7brQ7578DWmXPFeXIhjriP9AkbUJ6VWSPmmagAVurZehe6q1z4 zuMfbdrIPoVWw== Date: Thu, 26 Dec 2024 16:22:12 +0000 Message-ID: <875xn6v2hd.fsf@whispers-vpn.org> Feedback-ID: 119317227:user:proton X-Pm-Message-ID: c230cf6c16ed5b08f4f0ae5f6e4ed87c840ea295 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: , Reply-to: Runciter X-ACL-Warn: , Runciter via Guix-patches From: Runciter via Guix-patches via Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 4D3737AFFE X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -3.69 X-Spam-Score: -3.69 X-TUID: nkPzcpDB0OHa Hello, I'll squash both commits, simplify the configuration if appropriate, update symbol names and improve the documentation in the beginning of next week. Meanwhile I have not tested much yet but by reviewing code I found something which is possibly interesting. >> +(define %dictorg-handler >> + (dicod-handler (name "dictorg") >> + (module "dictorg") >> + (options (list #~(string-append "dbdir=3D/"))))) > > I believe we don=E2=80=99t even need that; it=E2=80=99s built-in. You found something simpler but I'll need to dive into the dicod.conf file in the store. See below. And sorry for the call to string-append with just one argument, I also seem to have included a useless G-exp... Probably a leftover from a previous version of mine. >> +(define (freedict-dictorg-database dict-name) >> + "Return a record of type @code{} that configures a >> +database for the freedict multilingual dictionary named by the string >> +DICT-NAME." >> + (dicod-database (name (string-append "freedict-" >> + dict-name)) >> + (complex? #t) > > What does =E2=80=98complex?=E2=80=99 do actually? (Seems to work without= it.) Reviewing the code in the (gnu services dict) module, the relevant symbol is `database->text` defined inside the `dicod-configuration-file` procedure. `database->text` recurses into itself one time maximally, so that dicod gets one auto-generated handler with default handler options from the service module for each configured database which has `complex?` evaluating to #f, independently (TBC) from what the system configuration's explicit handlers and other non-complex databases are configuring. dicod has modules, handlers referencing a module, and databases referencing a handler. The latter two are user-configurable. dicod has hard-coded modules and I suppose it has no hard-coded handlers. In any case, as far as the Guix service module design goes, dicod is always supposed to get all of its handlers from Guix, either flexible handlers from the system configuration, or default handlers from the service module. This being the inferred design intent, 3 things are possibly not ideal in the way Guix handles dicod, by increasing order of importance: 1. In the Guix manual, the documentation of the `complex?` field may be slightly misleading. Strictly speaking it's the handler configuration which is complex when `complex?` is true, not the database configuration. Within dicod, those 2 levels of configuration are at least partially substitutable to each other, but they're not occupying the same position along an inheritance chain. 2. Here's one thing that I must experiment with before finishing this patch: some interactions between the service module and the system configuration might result in a "dirty" dicod configuration file defining the same handler multiple times. There are 2 cases which can result in this situation, and I don't think this is caught by the service module (TBC): a. same handler name defined explicitly by the system configuration, and by the service module when the system configuration also defines a non-complex database naming the same handler; b. System configuration containing multiple non-complex databases naming the same handler. If I have to bet right now, this is what happens with the simple system configuration you found. There's reason to think the dicod configuration file is "dirty" but non-failing, and in any case non-risky at run-time in this case, because the multiply-defined handler(s) should be all configured exactly to an identical default. 3. Are we possibly configuring dicod to load some of its modules multiple times, or possibly misleading users into doing it? This could be also non-failing but a most undesirable thing to do. Regards, Runciter