From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Psionic K Newsgroups: gmane.emacs.help Subject: Re: dynamic reload of dynamic module not dynamic? Date: Thu, 4 Jul 2024 16:00:32 +0900 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8235"; mail-complaints-to="usenet@ciao.gmane.io" Cc: help-gnu-emacs@gnu.org To: p.stephani2@gmail.com Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 04 09:01:53 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sPGTZ-0001rQ-BC for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 04 Jul 2024 09:01:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPGSd-0000cB-SJ; Thu, 04 Jul 2024 03:00:55 -0400 Original-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 1sPGSa-0000a3-5i for help-gnu-emacs@gnu.org; Thu, 04 Jul 2024 03:00:53 -0400 Original-Received: from mail-yb1-xb33.google.com ([2607:f8b0:4864:20::b33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sPGSW-0001Ln-BV for help-gnu-emacs@gnu.org; Thu, 04 Jul 2024 03:00:51 -0400 Original-Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-e03a17a50a9so325869276.1 for ; Thu, 04 Jul 2024 00:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1720076446; x=1720681246; darn=gnu.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ZtM2D8t9mewqHK9q0+Pz7vPofoKNax0K/Niq5gYGi+Q=; b=SWrJ1ETzAQwnQQYgotstBJEIS9I54KCqrvNOQM1EMEtK3lRsWzCDZCdk1B0ab/6IKi ph7Map/1d3316i56mp81WUsS5XBj4RGWKpgRZVQLrAqBdCgibVripacXfDkWQzNRq5mT efELqlypmub9wkP1yZwg9EliWriKzx0MdvSzg+tXPfpHxwds+axQTAeCCcTOdHJH60cz HGx9bFCtwoF6CKsk3KhGZ7wRq22S7O1boYzRtwWDQDqAO6ybJaWOp6HhwD/2h4N4e/Xe GsFRvA99uxT65yrt4Yp1IqF8WABgorA9PcJCSF7TCjuoRHOHTjMGQ8UvgOLa93VV184e gV9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720076446; x=1720681246; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ZtM2D8t9mewqHK9q0+Pz7vPofoKNax0K/Niq5gYGi+Q=; b=e4zTCnUY8fYuT5c1tQ76/yssYPPhZO9p87mPNsuDgOFf7COPTiqlxzDHKEU/itz3Ra c/LCMqLhToqLMX5d4JB18B58uQ8ZKoGJ3ymOAZ7ZmyyBXmo8Nhetr01KKUkZwFiLRI6T Wd4tNv0a/5Emj1X5GDBNWIYIY/CCfq3wZmQbMbd4NLl58rmOgVXmODZwSAYX2LKWcQ87 yTyAl2AjRL+7c965odRuxcG2Dj/zIKAO2JCNC3VWZVQLwxg3NyeJDwEf1cAryjPt3rhH tGQn1Gz5QYM0d7x8z6WezPuXZXFHs9xcM5K8iTOq/If3IQDh/FbYD2PY7uSmYTywfw7Z afAQ== X-Gm-Message-State: AOJu0YwruFrciobGkYR1YuW8QtvuwaTLpCKdkxCljeqJ01JXeRYeQIwR Ou5HXT8EQMDYLNUzjnGH30jNRGmx9uPBwUohuZEDmLvgIExUDcPffTZ48chrj9i+q+XKSeJ9aDl LpuXH9rhqdP5/zb8Bme9xs2/gEA2w2a2P4NLHTQ== X-Google-Smtp-Source: AGHT+IHx2qcfuE+VZ6lQPcL2zn1Ym5n188c6zSxcMwIqsY6dQk7T/MBQHuSseku7DuF9J6hksbifDoi39lLubGPqaao= X-Received: by 2002:a25:b183:0:b0:e02:9dd0:e637 with SMTP id 3f1490d57ef6-e03c190e711mr736639276.22.1720076443346; Thu, 04 Jul 2024 00:00:43 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::b33; envelope-from=exec@positron.solutions; helo=mail-yb1-xb33.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, 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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:147069 Archived-At: > but I think first we should discuss whether the FR is important enough for that Full reload? Absolutely indispensable and the right decision. However, I think we're looking at the challenges wrong, worrying about problems that could exist if dynamic modules haphazardly return pointers to owned data rather than focusing on communicating the right contract to dynamic module authors so that such problems don't occur. The former conversation presumes too much responsibility on the part of Emacs for things it can't be responsible for. Instead of saying, "what if the dynamic module does this?" where "this" would be hard for Emacs to manage in the next five or ten years, tell dynamic module authors to conform to a contract that is simple for Emacs already. That way we're not all blocking each other. Just looking at the Rust module code, I see a mechanism to give the Emacs GC ownership of a value. If that can be done, why would I hold in Elisp any pointers into memory managed by the dynamic module? When we do want to name and point to things in the dynamic module, we should do so by identifier, not a raw pointer. That way the dynamic module can look before leaping, using whatever identifier mapping the module author sees fit. Any loss in speed of not handing pointers over to Emacs is silly to worry about because the presumption of the entire scheme is that Elisp is delegating human speed command input to a fast and capable implementation. Lookups for identifiers are faster than human speed, so the cost of looking up identifiers at the human to native interface is negligible. There was a keystroke. We shouldn't be counting microseconds. The presumption is that we saved ten seconds of Elisp or did something Elisp can't do well. >From the rest of the thread and in general, I got the impression that Emacs devs are, out of experience with users making new problems for themselves, being too protective in thinking. Dynamic module authors should be held to a higher standard and not treated like a potential source of annoying bug reports. Just set some ground rules that will make upstream behavior within Emacs easier to plan on rather than presuming too much responsibility. The user is writing a dynamic module. They have opted into knowing what they are doing. There should minimally only be ways made available to write a good module. The contract should be that Emacs can reload the module and that it's the module's responsibility not to violate that contract by handing back data that won't work through reload. Emacs should treat them like oracles that are responsible for not screwing up. I think this is the right conversation to have. It's a C interface. The user is responsible. Honestly it is more of a headache to consider how to tell Emacs to invalidate raw pointers than to manage the data correctly within the module. There's infinite other ways to crash programs that dynamic module authors are also responsible for. It's nothing new. Delegate this responsibility to the maximum extent possible and dynamic module authors will figure it out with libraries. The alternative is to develop by throwing away Emacs instances or load lots of renamed and annoying duplicate modules? A lot of Elisp state might be built up as the user is hacking away with a module and associated Elisp concurrently. When forced to reload Emacs, it will just break the workflow. This is not a 1.0 version of the dynamic module feature because it negates the core strength of interactive dynamic development. In the end, the worst case of badly behaved dynamic modules had nearly identical impact to the user: reload Emacs (if it didn't politely crash already). Thanks