all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Runciter via Guix-patches via <guix-patches@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 75063@debbugs.gnu.org
Subject: [bug#75063] [PATCH 1/2] gnu: dict: Add symbols to help users configure FreeDict with dicod.
Date: Thu, 26 Dec 2024 16:22:12 +0000	[thread overview]
Message-ID: <875xn6v2hd.fsf@whispers-vpn.org> (raw)
In-Reply-To: <cover.1735043982.git.runciter@whispers-vpn.org>


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=/")))))
>
> I believe we don’t even need that; it’s 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{<dicod-database>} 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 ‘complex?’ 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





  parent reply	other threads:[~2024-12-26 16:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-24 12:47 [bug#75063] [PATCH 0/2] Easy configuration of FreeDict into dicod-service-type Runciter via Guix-patches via
2024-12-24 13:00 ` [bug#75063] [PATCH 1/2] gnu: dict: Add symbols to help users configure FreeDict with dicod Runciter via Guix-patches via
2024-12-25 21:23   ` Ludovic Courtès
2024-12-24 13:00 ` [bug#75063] [PATCH 2/2] doc: add FreeDict dictionaries to dicod configuration example Runciter via Guix-patches via
2024-12-26 16:22 ` Runciter via Guix-patches via [this message]
2024-12-29 18:35 ` [bug#75063] [PATCH 1/2] gnu: dict: Add symbols to help users configure FreeDict with dicod Runciter via Guix-patches via
2025-01-01 19:23 ` [bug#75063] [PATCH v2] " Runciter via Guix-patches via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875xn6v2hd.fsf@whispers-vpn.org \
    --to=guix-patches@gnu.org \
    --cc=75063@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=runciter@whispers-vpn.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.