From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Lisp files that load cl-lib in problematical ways Date: Thu, 19 Oct 2023 09:44:51 -0400 Message-ID: References: <87il8betof.fsf@dataswamp.org> <83fs3dgxv8.fsf@gnu.org> <835y38qvlg.fsf@gnu.org> <87bkcx6eci.fsf@dataswamp.org> <8734y7p7sz.fsf@dataswamp.org> <83v8b3mcuj.fsf@gnu.org> <87jzrjvze8.fsf@gmx.net> <83r0lrm4gj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24717"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stephen Berman , incal@dataswamp.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 19 15:45:55 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qtTLW-0006BC-Ay for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Oct 2023 15:45:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtTKc-0007wR-No; Thu, 19 Oct 2023 09:44:59 -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 1qtTKX-0007vT-KP for emacs-devel@gnu.org; Thu, 19 Oct 2023 09:44:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtTKW-0007h4-Iu; Thu, 19 Oct 2023 09:44:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=F4l30rI/es3a9zbGG6OV82OMo0jihhQLvlBuRxbX3Xs=; b=MBM2gWqoUhRWn7zPznKr IJ6c/b2RWmMw+TJwVbo7y5L04daB8QsDOyIY8Qxl1JmBTlKyYuVHNgKeHdeDuKO1kBXIvc2N0k2+D Cvfgbb6Oert8eiWRN2x5qOcMW9Ga4knnqgROMLkJvWY0kyXyjsIqNt+eq3p33ECPCVOr+NTiIoluG Fy2bRw4HaVYfs3KSJ7OuW1hyyRk8zorU7ReC6BR3Sko6YCjTiHzOhdOWeBpx3Z0T0Rd9iv4jLTfOE omyn7aq3zf/exqOqJbZNb0/qZ9jrWtMzpTjhaU9n8t1oFYMb56RMGxHInhHLqcMo1aKooA8zXjQK2 rru86G8MTvqH0A==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qtTKV-0001Ux-VP; Thu, 19 Oct 2023 09:44:52 -0400 In-Reply-To: (Andrea Corallo's message of "Thu, 19 Oct 2023 05:04:26 -0400") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311594 Archived-At: Andrea Corallo writes: > Eli Zaretskii writes: > >>> From: Stephen Berman >>> Cc: Emanuel Berg , emacs-devel@gnu.org >>> Date: Thu, 19 Oct 2023 09:34:39 +0200 >>> >>> On Thu, 19 Oct 2023 07:54:12 +0300 Eli Zaretskii wrote: >>> >>> > (featurep 'cl-lib) => nil >>> > >>> > both in GUI and TTY (i.e. -nw) sessions. >>> >>> I also get this in a freshly updated build from master both with -Q and >>> with -Q -nw. In a freshly updated build from emacs-29 I also get it >>> with -Q -nw, but with just -Q (i.e. the GUI) it returns `t', and >>> evaluating `features' returns (time-date subr-x cl-loaddefs cl-lib >>> rmc...). And in a GUI build from master from October 8, (featurep >>> 'cl-lib) returns `t' and features returns (time-date subr-x cl-loaddefs >>> cl-lib rmc...). >> >> Please try figuring out what loads cl-lib in your case, as I cannot >> reproduce this with the latest emacs-29 branch. > > Maybe the native compiler as it was triggered for some native > compilation? Okay, I confirm that comp.el loads cl-lib, so any jit compilation triggered loads that. emacs -Q on my system at the first run (not in the followings) loads cl-lib because of that. The compiler really needs cl-lib while running as needs to understand user defined types (cl structs). OTOH one thing we could do, if that's important, is to split the code that only drives the async compilation (that actually happens in a subprocess) so we don't load cl-lib in the Emacs the user is actually using. This should not be that hard (optimism mode on). Andrea