Received: (at 77725) by debbugs.gnu.org; 29 Apr 2025 16:33:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 29 12:33:38 2025
Received: from localhost ([127.0.0.1]:59239 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u9ntn-0005aB-03
for submit <at> debbugs.gnu.org; Tue, 29 Apr 2025 12:33:38 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13927)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u9ntk-0005Zk-Ci
for 77725 <at> debbugs.gnu.org; Tue, 29 Apr 2025 12:33:32 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 842C910006B;
Tue, 29 Apr 2025 12:33:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745944405;
bh=SLa37Nfh0KjiephG7vjwffCZMRD/D1MKDVLJ8GLuEek=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=FSvKfI+i9q2gSIc8gbebh5Z9VHHUREDWHUUJBZ66rZ1yctwhDS8TcZlZPvAFSChjw
fSlmvoOiyBrYaahEwpmzf8slRaxGvHy8AQZW9cYcZk7wVYGaU5T9v+2vq/EclJauvG
jubimB3Io0d4H8UKXLnGL1MgRZBUq5K9Tt1LRefFvmIi2mUUgNEu64K8/EhgJJWPZ+
fqpdH/+mBlXIbJ9KmiPWIiRXc53lldKqGL5KCbXb2vEUmhHIV884Vh4ZSFO6EYNQ7A
P1y2A1Oj/aed1Z4p1uKA4WIBJls8o8OXesSIVsJCto/W8zgXrQTNp+rfR+uWnHy8uD
eq33mJJsi4U/w==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D2631100029;
Tue, 29 Apr 2025 12:33:25 -0400 (EDT)
Received: from asado (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 975A5120199;
Tue, 29 Apr 2025 12:33:16 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <e03aadc4-5a8f-464b-b79d-f9408bf460ff@HIDDEN>
Message-ID: <jwvo6wfymbe.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
<8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
<jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN>
<bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN>
<jwvjz73ujru.fsf-monnier+emacs@HIDDEN>
<e03aadc4-5a8f-464b-b79d-f9408bf460ff@HIDDEN>
Date: Tue, 29 Apr 2025 12:33:06 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.292 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Of course, it makes much sense. If I am not wrong, the constructor of the
> class `cl-type-class' already ensures that parent types must be defined
> before their "child" types (i.e. already added to the `cl--type-list' for
> types defined with `cl-deftype").
I think so, yes.
> So it should work to simply push a new type at the beginning of the
> list.
Yup.
> And, when a type is redefined, move it at the beginning of
> the list?
Redefinition is more complicated, because child types may be in the
list, so moving the type to the head can be incorrect. The "cheap"
solution is to leave the list unchanged (and hope the redefinition
doesn't change the hierarchy too much).
Side note: Redefinitions introduce other problems as well because the
class object's `parents` slot contains references to `cl--class`
objects, so after a redefinition via (setf (cl--find-class FOO) ...),
the children's `parents` slots point to the old class object.
That's a problem that affects all types and that we don't really try to
solve currently.
> Sorry, that's a bit paranoid of me, as I've heard many times that function
> calls are inefficient in ELisp.
FWIW, calls from bytecode to bytecode have been improved noticeable by
Mattias (can't remember if that was for Emacs-29 or Emacs-30), so it's
not as bad as it used to be.
> You're certainly right: in this case, the overhead of a function call
> should be negligible. I'll replace those "defsubst" with "defun".
It's good to be mindful of costs, but it's also important to remember
that the majority of the code is actually not performance sensitive at
all (by which I mean that small constant factors, like what you get from
inlining, don't matter).
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 29 Apr 2025 15:50:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 29 11:50:02 2025 Received: from localhost ([127.0.0.1]:58462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u9nDd-00004u-3Z for submit <at> debbugs.gnu.org; Tue, 29 Apr 2025 11:50:02 -0400 Received: from smtp-76.smtpout.orange.fr ([80.12.242.76]:50417 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u9nDZ-0008WI-Ok for 77725 <at> debbugs.gnu.org; Tue, 29 Apr 2025 11:49:59 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 9nDTuHv0NSxyX9nDWuhXzX; Tue, 29 Apr 2025 17:49:55 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745941796; bh=8q+eSYvP4FOPoqGRD8u48wrN885/HYs218/kEQDjChw=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=VKzQeEH50Y/z5Xb4rAq64EhIAalBWoslLTVk/HEsl5ifH0IqAq0kwvXmHLWR19chh VdO7sIzsShTuFWI8TkIIzNppIuyfv25L4R4gceddyqIMeH6ZWM4ST9dtqFS1XwXJem DhJ4DaRADYO+mr/f/7ff/+AjCH1qJob7ihKqR6OWANZV+7WOwWxEQD93d2PgSYSM/u 8e1pD0BBMDAKOHEBtop9SXl9f7TLuyhuQatXfc+H49d+y85DIG85vzdx0JRBuljAj0 uvPc1YjQ9gJmvmRTp6Ex7ig6GcLcYnMyAnb0Q4g04Mo3p6AVBoCWegHVzqf6Tqf6N5 h3QeeoW1g//2A== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Tue, 29 Apr 2025 17:49:56 +0200 X-ME-IP: 90.112.40.65 Message-ID: <e03aadc4-5a8f-464b-b79d-f9408bf460ff@HIDDEN> Date: Tue, 29 Apr 2025 17:49:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN> <1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN> <jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN> <0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN> <jwvwmb6yylb.fsf-monnier+emacs@HIDDEN> <jwv5xiplqbk.fsf-monnier+emacs@HIDDEN> <8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN> <jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN> <bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN> <jwvjz73ujru.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvjz73ujru.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-29 16:49, Stefan Monnier wrote: >> ;; FIXME: This global operation is a bit worrisome, because it >> ;; scales poorly with the number of types. I guess it's OK >> ;; for now because `cl-deftype' is not very popular, but it'll >> ;; probably need to be replaced at some point. Maybe we >> ;; should simply require that the parents be defined already, >> ;; then we can just `push' the new type, knowing it's in >> ;; topological order by construction. >> >> It's not clear to me how "simply require that the parents be defined >> already", makes the new type "in topological order by construction". > > If they're already defined, it means they're already in the list, so if > you add the new type at the head of the list you know this "child" comes > before all its parents in the list. If the list is constructed only by > making such additions where we make sure the parents are already there, > then the property is valid over the whole list. > > Note, there's no magic: we should push the responsibility of topological > sorting onto the programmers (who now have to define their types in > topological order). Of course, it makes much sense. If I am not wrong, the constructor of the class `cl-type-class' already ensures that parent types must be defined before their "child" types (i.e. already added to the `cl--type-list' for types defined with `cl-deftype"). So it should work to simply push a new type at the beginning of the list. And, when a type is redefined, move it at the beginning of the list? >> Also, as all this is done only at type (re)definition, which should >> not happen so often, I am curious to know why you think "this global >> operation is a bit worrisome"? > > The algorithmic complexity of merge-ordered-list is O(N²), in the number > of types IIRC, so while it may seem fine with 10 types, it could take > more than a minute given enough type declarations. I understand now, thanks! > >> In `cl-types-of', I liked your idea to avoid calls to >> `cl--type-parents' and `merge-ordered-list' before we do the >> `gethash'. I've gone a bit further in this direction (hopefully not >> too far!) by doing all the type list computation just before creating >> a new entry in the hash table. There's a slight overhead to determine >> the types of objects not yet processed, but determining the types of >> similar objects should be faster, which should be the most common case >> (or at least the one to favor) when using types to dispatch methods. > > +1 > > I notice that the `(null (assq type found))` is now ineffective, tho. > Maybe it's OK and we should just remove it. Good catch :-) I think it's OK to just remove this test. > Why all the `defsubst`? Have you measured a noticeable speed difference > by using them? I have a hard time seeing how that could happen. > All 3 `defsubst` in your patch are for function which contain > a non-trivial loop, so I'd expect the overhead of a function call to be > negligible. Sorry, that's a bit paranoid of me, as I've heard many times that function calls are inefficient in ELisp. You're certainly right: in this case, the overhead of a function call should be negligible. I'll replace those "defsubst" with "defun". David
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 29 Apr 2025 14:49:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 29 10:49:32 2025
Received: from localhost ([127.0.0.1]:57373 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u9mH3-0000tl-RF
for submit <at> debbugs.gnu.org; Tue, 29 Apr 2025 10:49:32 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16544)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u9mH1-0000tF-Je
for 77725 <at> debbugs.gnu.org; Tue, 29 Apr 2025 10:49:28 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8C1D980899;
Tue, 29 Apr 2025 10:49:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745938160;
bh=mkTbuINwmSDkztYGst3Z0eR4jzswi/QaNLR2LIh6nAA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=RJ8Bt/NPxVtXpKNvoUzExJbZOd3m6BEj3vgSQyFnY9BtOJfssUfPOtF4riliRI+o1
GkdL9q6qtHthdEQvFJWQS3F34ECB1Z3wpWJ7+lVPg/4CW5fyC3wdqOHy3Y3hqPt9iw
OvqOciOtyqZoUJzxf/lP4JUngu9uDTWCWwKCBEk1RL3J1xFbUj+Twk3Z/DWGo00qYw
29OL3MdimSXtS/dCn+xUy5xfzK6BLH98abWb2nsDKIZ28IXOqepcprpPlOHk8O+2D4
/EMTuKfm5mVAgnGWuiEv7bspgUQqQum4jV7pcinWpFys7qO4JdpARU96yOxrvzTh54
xMF9yYN62rIkQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A50F78034C;
Tue, 29 Apr 2025 10:49:20 -0400 (EDT)
Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7687112041B;
Tue, 29 Apr 2025 10:49:20 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN>
Message-ID: <jwvjz73ujru.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
<8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
<jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN>
<bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN>
Date: Tue, 29 Apr 2025 10:49:13 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.060 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> ;; FIXME: This global operation is a bit worrisome, because it
> ;; scales poorly with the number of types. I guess it's OK
> ;; for now because `cl-deftype' is not very popular, but it'll
> ;; probably need to be replaced at some point. Maybe we
> ;; should simply require that the parents be defined already,
> ;; then we can just `push' the new type, knowing it's in
> ;; topological order by construction.
>
> It's not clear to me how "simply require that the parents be defined
> already", makes the new type "in topological order by construction".
If they're already defined, it means they're already in the list, so if
you add the new type at the head of the list you know this "child" comes
before all its parents in the list. If the list is constructed only by
making such additions where we make sure the parents are already there,
then the property is valid over the whole list.
Note, there's no magic: we should push the responsibility of topological
sorting onto the programmers (who now have to define their types in
topological order).
> Also, as all this is done only at type (re)definition, which should
> not happen so often, I am curious to know why you think "this global
> operation is a bit worrisome"?
The algorithmic complexity of merge-ordered-list is O(N=B2), in the number
of types IIRC, so while it may seem fine with 10 types, it could take
more than a minute given enough type declarations.
> In `cl-types-of', I liked your idea to avoid calls to
> `cl--type-parents' and `merge-ordered-list' before we do the
> `gethash'. I've gone a bit further in this direction (hopefully not
> too far!) by doing all the type list computation just before creating
> a new entry in the hash table. There's a slight overhead to determine
> the types of objects not yet processed, but determining the types of
> similar objects should be faster, which should be the most common case
> (or at least the one to favor) when using types to dispatch methods.
+1
I notice that the `(null (assq type found))` is now ineffective, tho.
Maybe it's OK and we should just remove it.
> WDYT
Why all the `defsubst`? Have you measured a noticeable speed difference
by using them? I have a hard time seeing how that could happen.
All 3 `defsubst` in your patch are for function which contain
a non-trivial loop, so I'd expect the overhead of a function call to be
negligible.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 29 Apr 2025 10:50:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 29 06:50:42 2025 Received: from localhost ([127.0.0.1]:50770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u9iXx-0001cd-FJ for submit <at> debbugs.gnu.org; Tue, 29 Apr 2025 06:50:42 -0400 Received: from smtp-80.smtpout.orange.fr ([80.12.242.80]:55773 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u9iXq-0001b8-Jw for 77725 <at> debbugs.gnu.org; Tue, 29 Apr 2025 06:50:39 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 9iXkuM3e5eSp19iXnuVYKA; Tue, 29 Apr 2025 12:50:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745923832; bh=3IehPu/4LKRlHsEIvUVyLuKclROKWkZi1s+5m5BQTkI=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=KaJFhqBvC4ow3UpbqIL+QplvJ0HEH22VovFPTSbgiw0NATyIOm7p3xVr0cgFdJsD+ p7I88raMjPyPk6GsW7L2VWyxsCqr/HtO5p/EfKvrAXeafflROMwhJ6qxvu68g/Fo54 UIulV8qYV6wGxzxStYdkJpXx0eBs6223nEOnZHwqG9gkkS3dWPgaIIzXjp3foLwcoR rRk/4Ky3UmqMQDupx00baMRcbXmHzIJaAXycBvAnoGOjPTmfliXufShySYjQEiO2fy wQp0fLrlhHCMwp35cPKOfiV3uKt16bjopGYHFfqAALo/ugzo8xu6wGFNXdid32tnyL 9EwVFY73BLjOg== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Tue, 29 Apr 2025 12:50:32 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------wX7ISlduev3upoIOjvky26gv" Message-ID: <bba80d3d-67bb-483b-98f4-a0a32ea2a36b@HIDDEN> Date: Tue, 29 Apr 2025 12:50:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN> <1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN> <jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN> <0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN> <jwvwmb6yylb.fsf-monnier+emacs@HIDDEN> <jwv5xiplqbk.fsf-monnier+emacs@HIDDEN> <8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN> <jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------wX7ISlduev3upoIOjvky26gv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2025-04-28 23:44, Stefan Monnier wrote: [...] > I pushed your new code to the `scratch/cl-types` branch in `emacs.git`. > I haven't integrated it into the other CL-Lib files yet. > See patch below for comments on your code. Merci! Please find attached a new version of cl-types.el with some updates following your comments. Regarding this FIXME, in `cl--type-deftype', about the global setting of `cl--type-list': ;; FIXME: This global operation is a bit worrisome, because it ;; scales poorly with the number of types. I guess it's OK ;; for now because `cl-deftype' is not very popular, but it'll ;; probably need to be replaced at some point. Maybe we ;; should simply require that the parents be defined already, ;; then we can just `push' the new type, knowing it's in ;; topological order by construction. It's not clear to me how "simply require that the parents be defined already", makes the new type "in topological order by construction". Also, as all this is done only at type (re)definition, which should not happen so often, I am curious to know why you think "this global operation is a bit worrisome"? In `cl-types-of', I liked your idea to avoid calls to `cl--type-parents' and `merge-ordered-list' before we do the `gethash'. I've gone a bit further in this direction (hopefully not too far!) by doing all the type list computation just before creating a new entry in the hash table. There's a slight overhead to determine the types of objects not yet processed, but determining the types of similar objects should be faster, which should be the most common case (or at least the one to favor) when using types to dispatch methods. WDYT? Thanks! David --------------wX7ISlduev3upoIOjvky26gv Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el" Content-Disposition: attachment; filename="cl-types.el" Content-Transfer-Encoding: base64 OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBEYXRhIHR5cGVzIGRlZmluZWQg YnkgYGNsLWRlZnR5cGUnIGFyZSBub3cgcmVjb2duaXplZCBhcyBhcmd1bWVudAo7OyB0eXBl cyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbnMgbWV0aG9kcy4KCjs7IE5lZWRl ZCB1bnRpbCBtZXJnZWQgaW4gZXhpc3RpbmcgbGlicmFyaWVzLgoocmVxdWlyZSAnY2wtbGli KQooZXZhbC13aGVuLWNvbXBpbGUgKHJlcXVpcmUgJ2NsLW1hY3MpKSAgO0ZvciBjbC0tZmlu ZC1jbGFzcy4KKGRlY2xhcmUtZnVuY3Rpb24gY2wtcmVtcHJvcCAiY2wtZXh0cmEiIChzeW1i b2wgcHJvcG5hbWUpKQooZGVjbGFyZS1mdW5jdGlvbiBjbC0tY2xhc3MtY2hpbGRyZW4gImNs LWV4dHJhIiAoY2xhc3MpKQoKOzsgRXh0ZW5kIGBjbC1kZWZ0eXBlJyB0byBkZWZpbmUgZGF0 YSB0eXBlcyB3aGljaCBhcmUgYWxzbyB2YWxpZAo7OyBhcmd1bWVudCB0eXBlcyBmb3IgZGlz cGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbiBtZXRob2RzIChzZWUgYWxzbwo7OyA8aHR0cHM6 Ly9kZWJidWdzLmdudS5vcmcvY2dpL2J1Z3JlcG9ydC5jZ2k/YnVnPTc3NzI1PikuCjs7Cjs7 IFRoZSBtYWluIGVudHJ5IHBvaW50cyBhcmU6Cjs7Cjs7IC0gYGNsLWRlZnR5cGUnLCB0aGF0 IGRlZmluZXMgbmV3IGRhdGEgdHlwZXMuCjs7Cjs7IC0gYGNsLXR5cGVzLW9mJywgdGhhdCBy ZXR1cm5zIHRoZSB0eXBlcyBhbiBvYmplY3QgYmVsb25ncyB0by4KCihkZWZ2YXIgY2wtLXR5 cGUtbGlzdCBuaWwKICAiTGlzdCBvZiBkZWZpbmVkIHR5cGVzIHRvIGxvb2t1cCBmb3IgbWV0 aG9kIGRpc3BhdGNoaW5nLiIpCgo7OyBGSVhNRTogVGhlIGBjbC1kZWZ0eXBlLWhhbmRsZXIn IHByb3BlcnR5IHNob3VsZCBhcmd1YWJseSBiZSB0dXJuZWQKOzsgaW50byBhIGZpZWxkIG9m IHRoaXMgc3RydWN0IChidXQgaXQgaGFzIHBlcmZvcm1hbmNlIGFuZAo7OyBjb21wYXRpYmls aXR5IGltcGxpY2F0aW9ucywgc28gbGV0J3Mgbm90IG1ha2UgdGhhdCBjaGFuZ2UgZm9yIG5v dykuCihjbC1kZWZzdHJ1Y3QKICAgIChjbC10eXBlLWNsYXNzCiAgICAgKDppbmNsdWRlIGNs LS1jbGFzcykKICAgICAoOm5vaW5saW5lIHQpCiAgICAgKDpjb25zdHJ1Y3RvciBuaWwpCiAg ICAgKDpjb25zdHJ1Y3RvciBjbC0tdHlwZS1jbGFzcy1tYWtlCiAgICAgICAgICAgICAgICAg ICAobmFtZQogICAgICAgICAgICAgICAgICAgIGRvY3N0cmluZwogICAgICAgICAgICAgICAg ICAgIHBhcmVudC10eXBlcwogICAgICAgICAgICAgICAgICAgICZhdXggKHBhcmVudHMKICAg ICAgICAgICAgICAgICAgICAgICAgICAobWFwY2FyCiAgICAgICAgICAgICAgICAgICAgICAg ICAgIChsYW1iZGEgKHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG9yIChj bC0tZmluZC1jbGFzcyB0eXBlKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAo ZXJyb3IgIlVua25vd24gdHlwZTogJVMiIHR5cGUpKSkKICAgICAgICAgICAgICAgICAgICAg ICAgICAgcGFyZW50LXR5cGVzKSkpKQogICAgICg6Y29waWVyIG5pbCkpCiAgIlR5cGUgZGVz Y3JpcHRvcnMgZm9yIHR5cGVzIGRlZmluZWQgYnkgYGNsLWRlZnR5cGUnLiIpCgooZGVmdW4g Y2wtLXR5cGUtcCAob2JqZWN0KQogICJSZXR1cm4gbm9uLW5pbCBpZiBPQkpFQ1QgaXMgYSBj bC10eXBlLgpUaGF0IGlzLCBhIHR5cGUgZGVmaW5lZCBieSBgY2wtZGVmdHlwZScsIG9mIGNs YXNzIGBjbC10eXBlLWNsYXNzJy4iCiAgKGFuZCAoc3ltYm9scCBvYmplY3QpIChjbC10eXBl LWNsYXNzLXAgKGNsLS1maW5kLWNsYXNzIG9iamVjdCkpKSkKCihkZWZzdWJzdCBjbC0tdHlw ZS1wYXJlbnRzIChuYW1lKQogICJHZXQgcGFyZW50cyBvZiB0eXBlIHdpdGggTkFNRS4KTkFN RSBpcyBhIHN5bWJvbCByZXByZXNlbnRpbmcgYSB0eXBlLgpSZXR1cm4gYSBwb3NzaWJseSBl bXB0eSBsaXN0IG9mIHR5cGVzLiIKICAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLS1maW5k LWNsYXNzIG5hbWUpKSkKCihkZWZzdWJzdCBjbC0tdHlwZS1jaGlsZHJlbiAobmFtZSkKICAi R2V0IGNoaWxkcmVuIG9mIHRoZSB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhIHN5bWJvbCBy ZXByZXNlbnRpbmcgYSB0eXBlLgpSZXR1cm4gYSBwb3NzaWJseSBlbXB0eSBsaXN0IG9mIHR5 cGVzLiIKICAoY2wtLWNsYXNzLWNoaWxkcmVuIChjbC0tZmluZC1jbGFzcyBuYW1lKSkpCgoo ZGVmc3Vic3QgY2wtLXR5cGUtZGFnICh0eXBlcykKICAiUmV0dXJuIGEgREFHIGZyb20gdGhl IGxpc3Qgb2YgVFlQRVMuIgogIChtYXBjYXIgIydjbC0tdHlwZS1wYXJlbnRzIHR5cGVzKSkK Cjs7IEtlZXAgaXQgZm9yIG5vdywgZm9yIHRlc3RpbmcuCihkZWZ1biBjbC0tdHlwZS11bmRl ZmluZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBkZWZpbml0aW9uIG9mIGNsLXR5cGUgd2l0aCBO QU1FLgpOQU1FIGlzIGFuIHVucXVvdGVkIHN5bWJvbCByZXByZXNlbnRpbmcgYSBjbC10eXBl LgpTaWduYWwgYW4gZXJyb3IgaWYgTkFNRSBoYXMgc3VidHlwZXMuIgogIChjbC1jaGVjay10 eXBlIG5hbWUgKHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAod2hlbi1sZXQqICgoY2hpbGRy ZW4gKGFuZCAoY2wtLXR5cGUtcCBuYW1lKQogICAgICAgICAgICAgICAgICAgICAgICAgICAg IChjbC0tdHlwZS1jaGlsZHJlbiBuYW1lKSkpKQogICAgKGVycm9yICJUeXBlIGhhcyBjaGls ZHJlbjogJVMiIGNoaWxkcmVuKSkKICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tdHlwZS1lcnJv cikKICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXByb3AgbmFtZSAn Y2wtZGVmdHlwZS1oYW5kbGVyKQogIChzZXRxIGNsLS10eXBlLWxpc3QgKGRlbHEgbmFtZSBj bC0tdHlwZS1saXN0KSkpCgooZGVmdW4gY2wtLXR5cGUtZGVmdHlwZSAobmFtZSBwYXJlbnRz ICZvcHRpb25hbCBkb2NzdHJpbmcpCiAgOzsgRklYTUU6IFNob3VsZCB3ZSBhbHNvIHJlY2Vp dmUgdGhlIGFyZ2xpc3Q/CiAgIkdlbmVyYWxpemUgY2wtdHlwZSB3aXRoIE5BTUUgZm9yIG1l dGhvZCBkaXNwYXRjaGluZy4KUEFSRU5UUyBpcyBhIGxpc3Qgb2YgdHlwZXMgTkFNRSBpcyBh IHN1YnR5cGUgb2YsIG9yIG5pbC4KRE9DU1RSSU5HIGlzIGFuIG9wdGlvbmFsIGRvY3VtZW50 YXRpb24gc3RyaW5nLiIKICAobGV0ICgodHlwZWxpc3QgY2wtLXR5cGUtbGlzdCkKICAgICAg ICAob2xkcGxpc3QgKGNvcHktc2VxdWVuY2UgKHN5bWJvbC1wbGlzdCBuYW1lKSkpKQogICAg KGNvbmRpdGlvbi1jYXNlIGVycgogICAgICAgIChsZXQqICgoY2xhc3MgKGNsLS1maW5kLWNs YXNzIG5hbWUpKQogICAgICAgICAgICAgICAocmVjb3JkZWQgKG1lbXEgbmFtZSB0eXBlbGlz dCkpKQogICAgICAgICAgKGlmIChudWxsIGNsYXNzKQogICAgICAgICAgICAgIChvciAobnVs bCByZWNvcmRlZCkKICAgICAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGdlbmVyYWxpemVk LCBidXQgZG9lc24ndCBleGlzdCIpKQogICAgICAgICAgICAob3IgcmVjb3JkZWQgKGVycm9y ICJUeXBlIGV4aXN0cywgYnV0IG5vdCBnZW5lcmFsaXplZCIpKQogICAgICAgICAgICAob3Ig KGNsLXR5cGUtY2xhc3MtcCBjbGFzcykKICAgICAgICAgICAgICAgIDs7IEZJWE1FOiBXZSBo YXZlIHNvbWUgdXNlcyBgY2wtZGVmdHlwZScgaW4gRW1hY3MgdGhhdAogICAgICAgICAgICAg ICAgOzsgImNvbXBsZW1lbnQiIGFub3RoZXIgZGVjbGFyYXRpb24gb2YgdGhlIHNhbWUgdHlw ZSwKICAgICAgICAgICAgICAgIDs7IHNvIG1heWJlIHdlIHNob3VsZCB0dXJuIHRoaXMgaW50 byBhIHdhcm5pbmcgKGFuZAogICAgICAgICAgICAgICAgOzsgbm90IG92ZXJ3cml0ZSB0aGUg YGNsLS1maW5kLWNsYXNzJyBpbiB0aGF0IGNhc2UpPwogICAgICAgICAgICAgICAgKGVycm9y ICJUeXBlIGluIGFub3RoZXIgY2xhc3M6ICVTIiAodHlwZS1vZiBjbGFzcykpKSkKICAgICAg ICAgIDs7IFNldHVwIGEgdHlwZSBkZXNjcmlwdG9yIGZvciBOQU1FLgogICAgICAgICAgKHNl dGYgKGNsLS1maW5kLWNsYXNzIG5hbWUpCiAgICAgICAgICAgICAgICAoY2wtLXR5cGUtY2xh c3MtbWFrZSBuYW1lIGRvY3N0cmluZyBwYXJlbnRzKSkKICAgICAgICAgIChpZiByZWNvcmRl ZAogICAgICAgICAgICAgIDs7IENsZWFyIGFueSBwcmV2aW91cyBlcnJvciBtYXJrLgogICAg ICAgICAgICAgIChjbC1yZW1wcm9wIG5hbWUgJ2NsLS10eXBlLWVycm9yKQogICAgICAgICAg ICA7OyBSZWNvcmQgbmV3IHR5cGUgdG8gaW5jbHVkZSBpdHMgZGVwZW5kZW5jeSBpbiB0aGUg REFHLgogICAgICAgICAgICAocHVzaCBuYW1lIHR5cGVsaXN0KSkKICAgICAgICAgIDs7IGBj bC10eXBlcy1vZicgaXRlcmF0ZXMgdGhyb3VnaCBhbGwga25vd24gdHlwZXMgdG8gY29sbGVj dAogICAgICAgICAgOzsgYWxsIHRob3NlIGFuIG9iamVjdCBiZWxvbmdzIHRvLCBzb3J0ZWQg ZnJvbSB0aGUgbW9zdAogICAgICAgICAgOzsgc3BlY2lmaWMgdHlwZSB0byB0aGUgbW9yZSBn ZW5lcmFsIHR5cGUuICBTbywga2VlcCB0aGUKICAgICAgICAgIDs7IGdsb2JhbCBsaXN0IGlu IHRoaXMgb3JkZXIuCiAgICAgICAgICA7OyBGSVhNRTogVGhpcyBnbG9iYWwgb3BlcmF0aW9u IGlzIGEgYml0IHdvcnJpc29tZSwgYmVjYXVzZSBpdAogICAgICAgICAgOzsgc2NhbGVzIHBv b3JseSB3aXRoIHRoZSBudW1iZXIgb2YgdHlwZXMuICBJIGd1ZXNzIGl0J3MgT0sKICAgICAg ICAgIDs7IGZvciBub3cgYmVjYXVzZSBgY2wtZGVmdHlwZScgaXMgbm90IHZlcnkgcG9wdWxh ciwgYnV0IGl0J2xsCiAgICAgICAgICA7OyBwcm9iYWJseSBuZWVkIHRvIGJlIHJlcGxhY2Vk IGF0IHNvbWUgcG9pbnQuICBNYXliZSB3ZQogICAgICAgICAgOzsgc2hvdWxkIHNpbXBseSBy ZXF1aXJlIHRoYXQgdGhlIHBhcmVudHMgYmUgZGVmaW5lZCBhbHJlYWR5LAogICAgICAgICAg OzsgdGhlbiB3ZSBjYW4ganVzdCBgcHVzaCcgdGhlIG5ldyB0eXBlLCBrbm93aW5nIGl0J3Mg aW4KICAgICAgICAgIDs7IHRvcG9sb2dpY2FsIG9yZGVyIGJ5IGNvbnN0cnVjdGlvbi4KICAg ICAgICAgIChzZXRxIGNsLS10eXBlLWxpc3QKICAgICAgICAgICAgICAgIChtZXJnZS1vcmRl cmVkLWxpc3RzCiAgICAgICAgICAgICAgICAgKGNsLS10eXBlLWRhZyB0eXBlbGlzdCkKICAg ICAgICAgICAgICAgICAobGFtYmRhIChfKSAoZXJyb3IgIkludmFsaWQgZGVwZW5kZW5jeSBn cmFwaCIpKSkpKQogICAgICAoZXJyb3IKICAgICAgIChzZXRmIChzeW1ib2wtcGxpc3QgbmFt ZSkgb2xkcGxpc3QpCiAgICAgICAoZXJyb3IgKGZvcm1hdCAiRGVmaW5lICVTIGZhaWxlZDog JXMiCiAgICAgICAgICAgICAgICAgICAgICBuYW1lIChlcnJvci1tZXNzYWdlLXN0cmluZyBl cnIpKSkpKSkpCgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gY2wtZGVmdHlwZTIgKG5hbWUg YXJnbGlzdCAmcmVzdCBib2R5KQogICJEZWZpbmUgTkFNRSBhcyBhIG5ldyBkYXRhIHR5cGUu ClRoZSB0eXBlIE5BTUUgY2FuIHRoZW4gYmUgdXNlZCBpbiBgY2wtdHlwZWNhc2UnLCBgY2wt Y2hlY2stdHlwZScsCmV0Yy4sIGFuZCBhcyBhcmd1bWVudCB0eXBlIGZvciBkaXNwYXRjaGlu ZyBnZW5lcmljIGZ1bmN0aW9uIG1ldGhvZHMuCgpBUkdMSVNUIGlzIGEgQ29tbW9uIExpc3Ag YXJndW1lbnQgbGlzdCBvZiB0aGUgc29ydCBhY2NlcHRlZCBieQpgY2wtZGVmbWFjcm8nLiAg Qk9EWSBmb3JtcyBhcmUgZXZhbHVhdGVkIGFuZCBzaG91bGQgcmV0dXJuIGEgdHlwZQpzcGVj aWZpZXIgdGhhdCBpcyBlcXVpdmFsZW50IHRvIHRoZSB0eXBlIChzZWUgdGhlIEluZm8gbm9k ZSBgKGNsKSBUeXBlClByZWRpY2F0ZXMnIGluIHRoZSBHTlUgRW1hY3MgQ29tbW9uIExpc3Ag RW11bGF0aW9uIG1hbnVhbCkuCgpJZiB0aGVyZSBpcyBhIGBkZWNsYXJlJyBmb3JtIGluIEJP RFksIHRoZSBzcGVjIChwYXJlbnRzIFBBUkVOVFMpIGlzCnJlY29nbml6ZWQgdG8gc3BlY2lm eSBhIGxpc3Qgb2YgdHlwZXMgTkFNRSBpcyBhIHN1YnR5cGUgb2YuICBGb3IKaW5zdGFuY2U6 CgogIChjbC1kZWZ0eXBlMiB1bnNpZ25lZC1ieXRlICgmb3B0aW9uYWwgYml0cykKICAgIFwi VW5zaWduZWQgaW50ZWdlci5cIgogICAgKGxpc3QgXFw9J2ludGVnZXIgMCAoaWYgKGVxIGJp dHMgXFw9JyopIGJpdHMgKDEtIChhc2ggMSBiaXRzKSkpKSkKCiAgKGNsLWRlZnR5cGUyIHVu c2lnbmVkLThiaXRzICgpCiAgICBcIlVuc2lnbmVkIDgtYml0cyBpbnRlZ2VyLlwiCiAgICAo ZGVjbGFyZSAocGFyZW50cyB1bnNpZ25lZC1ieXRlKSkKICAgIFxcPScodW5zaWduZWQtYnl0 ZSA4KSkKClRoZSBsaXN0IG9mIFBBUkVOVFMgdHlwZXMgZGV0ZXJtaW5lcyB0aGUgb3JkZXIg b2YgbWV0aG9kcyBpbnZvY2F0aW9uLAphbmQgbWlzc2luZyBQQVJFTlRTIG1heSBjYXVzZSBp bmNvcnJlY3Qgb3JkZXJpbmcgb2YgbWV0aG9kcywgd2hpbGUKZXh0cmFuZW91cyBQQVJFTlRT IG1heSBjYXVzZSB1c2Ugb2YgZXh0cmFuZW91cyBtZXRob2RzLgoKSWYgUEFSRU5UUyBpcyBu b24tbmlsLCBBUkdMSVNUIG11c3QgYmUgbmlsLiIKICAoZGVjbGFyZSAoZGVidWcgY2wtZGVm bWFjcm8pIChkb2Mtc3RyaW5nIDMpIChpbmRlbnQgMikpCiAgKHBjYXNlLWxldCoKICAgICAg KChgKCxkZWNscyAuICxmb3JtcykgKG1hY3JvZXhwLXBhcnNlLWJvZHkgYm9keSkpCiAgICAg ICAoZG9jc3RyaW5nIChpZiAoc3RyaW5ncCAoY2FyIGRlY2xzKSkKICAgICAgICAgICAgICAg ICAgICAgIChjYXIgZGVjbHMpCiAgICAgICAgICAgICAgICAgICAgICAoY2FkciAoYXNzcSA6 ZG9jdW1lbnRhdGlvbiBkZWNscykpKSkKICAgICAgIChkZWNsYXJlcyAoYXNzcSAnZGVjbGFy ZSBkZWNscykpCiAgICAgICAocGFyZW50LWRlY2wgKGFzc3EgJ3BhcmVudHMgKGNkciBkZWNs YXJlcykpKQogICAgICAgKHBhcmVudHMgKGNkciBwYXJlbnQtZGVjbCkpKQogICAgKHdoZW4g cGFyZW50LWRlY2wKICAgICAgOzsgIkNvbnN1bWUiIHRoZSBgcGFyZW50cycgZGVjbGFyYXRp b24uCiAgICAgIChjbC1jYWxsZiAobGFtYmRhICh4KSAoZGVscSBwYXJlbnQtZGVjbCB4KSkg KGNkciBkZWNsYXJlcykpCiAgICAgICh3aGVuIChlcXVhbCBkZWNsYXJlcyAnKGRlY2xhcmUp KQogICAgICAgIChjbC1jYWxsZiAobGFtYmRhICh4KSAoZGVscSBkZWNsYXJlcyB4KSkgZGVj bHMpKSkKICAgIChpZiAobWVtcSBuYW1lIHBhcmVudHMpCiAgICAgICAgKGVycm9yICJUeXBl IGluIHBhcmVudHM6ICVTIiBwYXJlbnRzKSkKICAgIChhbmQgcGFyZW50cyBhcmdsaXN0CiAg ICAgICAgIChlcnJvciAiUGFyZW50cyBzcGVjaWZpZWQsIGJ1dCBhcmdsaXN0IG5vdCBlbXB0 eSIpKQogICAgYChldmFsLWFuZC1jb21waWxlIDs7Y2wtZXZhbC13aGVuIChjb21waWxlIGxv YWQgZXZhbCkKICAgICAgIDs7IEZJWE1FOiBXaGVyZSBzaG91bGQgYGNsLS10eXBlLWRlZnR5 cGUnIGdvPyAgQ3VycmVudGx5LCBjb2RlCiAgICAgICA7OyB1c2luZyBgY2wtZGVmdHlwZScg Y2FuIHVzZSAoZXZhbC13aGVuLWNvbXBpbGUgKHJlcXVpcmUKICAgICAgIDs7ICdjbC1saWIp KSwgc28gYGNsLS10eXBlLWRlZnR5cGUnIG5lZWRzIHRvIGdvIGVpdGhlciB0bwogICAgICAg OzsgYGNsLXByZWxvYWRlZC5lbCcgb3IgaXQgc2hvdWxkIGJlIGF1dG9sb2FkZWQgZXZlbiB3 aGVuCiAgICAgICA7OyBgY2wtbGliJyBpcyBub3QgbG9hZGVkLgogICAgICAgKGNsLS10eXBl LWRlZnR5cGUgJyxuYW1lICcscGFyZW50cyAsZG9jc3RyaW5nKQogICAgICAgKGRlZmluZS1z eW1ib2wtcHJvcCAnLG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcgogICAgICAgICAgICAgICAg ICAgICAgICAgICAoY2wtZnVuY3Rpb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgIChs YW1iZGEgKCZjbC1kZWZzICgnKikgLEBhcmdsaXN0KQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAsQGRlY2xzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICxAZm9ybXMp KSkpKSkKCjs7IEVuc3VyZSBlYWNoIHR5cGUgc2F0aXNmaWVzIGBlcWwnLgooZGVmdmFyIGNs LS10eXBlLXVuaXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVhbCkKICAiUmVjb3Jk IGFuIHVuaXF1ZSB2YWx1ZSBvZiBlYWNoIHR5cGUuIikKCihkZWZ1biBjbC0tdHlwZS1lcnJv ciAodHlwZSBlcnJvcikKICAiTWFyayBUWVBFIGFzIGluLWVycm9yLCBhbmQgcmVwb3J0IHRo ZSBwcm9kdWNlZCBFUlJPUiB2YWx1ZS4iCiAgKHB1dCB0eXBlICdjbC0tdHlwZS1lcnJvciBl cnJvcikgOzsgTWFyayBUWVBFIGFzIGluLWVycm9yLgogIDs7IFRlbXBvcmFyaWx5IHJhaXNl IHRoZSByZWN1cnNpb24gbGltaXQgdG8gYXZvaWQgYW5vdGhlciByZWN1cnNpb24KICA7OyBl cnJvciB3aGlsZSByZXBvcnRpbmcgRVJST1IuCiAgKGxldCAoKG1heC1saXNwLWV2YWwtZGVw dGggKCsgODAwIG1heC1saXNwLWV2YWwtZGVwdGgpKSkKICAgICh3YXJuICAiY2wtdHlwZXMt b2YgJXMsICVzIiB0eXBlIChlcnJvci1tZXNzYWdlLXN0cmluZyBlcnJvcikpKQogIG5pbCkK Cjs7IEZJWE1FOiBgY2wtdHlwZXMtb2YnIENQVSBjb3N0IGlzIHByb3BvcnRpb25hbCB0byB0 aGUgbnVtYmVyIG9mIHR5cGVzCjs7IGRlZmluZWQgd2l0aCBgY2wtZGVmdHlwZScsIHNvIHRo ZSBtb3JlIHBvcHVsYXIgaXQgZ2V0cywgdGhlIHNsb3dlcgo7OyBpdCBiZWNvbWVzLiAgQW5k IG9mIGNvdXJzZSwgdGhlIGNvc3Qgb2YgZWFjaCB0eXBlIGNoZWNrIGlzCjs7IHVuYm91bmRl ZCwgc28gYSBzaW5nbGUgImV4cGVuc2l2ZSIgdHlwZSBjYW4gc2xvdyBldmVyeXRoaW5nIGRv d24KOzsgZnVydGhlci4KOzsKOzsgVGhlIHVzdWFsIGRpc3BhdGNoIGlzCjs7Cjs7ICAgKGxh bWJkYSAoYXJnICZyZXN0IGFyZ3MpCjs7ICAgICAobGV0ICgoZiAoZ2V0aGFzaCAoY2wtdHlw ZW9mIGFyZykgcHJlY29tcHV0ZWQtbWV0aG9kcy10YWJsZSkpKQo7OyAgICAgICAoaWYgZgo7 OyAgICAgICAgICAgKGFwcGx5IGYgYXJnIGFyZ3MpCjs7ICAgICAgICAgOzsgU2xvdyBjYXNl IHdoZW4gZW5jb3VudGVyaW5nIGEgbmV3IHR5cGUKOzsgICAgICAgICAuLi4pKSkKOzsKOzsg d2hlcmUgb2Z0ZW4gdGhlIG1vc3QgZXhwZW5zaXZlIHBhcnQgaXMgYCZyZXN0JyAod2hpY2gg aGFzIHRvCjs7IGFsbG9jYXRlIGEgbGlzdCBmb3IgdGhvc2UgcmVtYWluaW5nIGFyZ3VtZW50 cyksCjs7Cjs7IFNvIHdlJ3JlIHRhbGtpbmcgYWJvdXQgcmVwbGFjaW5nCjs7Cjs7ICAgJnJl c3QgKyBjbC10eXBlLW9mICsgZ2V0aGFzaCArIGlmICsgYXBwbHkKOzsKOzsgd2l0aCBhIGZ1 bmN0aW9uIHRoYXQgbG9vcHMgb3ZlciBOIHR5cGVzLCBjYWxsaW5nIGBjbC10eXBlcCcgb24g ZWFjaAo7OyBvbmUgb2YgdGhlbSAoYGNsLXR5cGVwJyBpdHNlbGYgYmVpbmcgYSByZWN1cnNp dmUgZnVuY3Rpb24gdGhhdAo7OyBiYXNpY2FsbHkgaW50ZXJwcmV0cyB0aGUgdHlwZSBsYW5n dWFnZSkuICBUaGlzIGlzIGdvaW5nIHRvIHNsb3cKOzsgZG93biBkaXNwYXRjaCB2ZXJ5IHNp Z25pZmljYW50bHkgZm9yIHRob3NlIGdlbmVyaWMgZnVuY3Rpb25zIHRoYXQKOzsgaGF2ZSBh IG1ldGhvZCB0aGF0IGRpc3BhdGNoZXMgb24gYSB1c2VyIGRlZmluZWQgdHlwZSwgY29tcGFy ZWQgdG8KOzsgdGhvc2UgdGhhdCBkb24ndC4KOzsKOzsgQSBwb3NzaWJsZSBmdXJ0aGVyIGlt cHJvdmVtZW50Ogo7Owo7OyAtIGJhc2VkIG9uIHRoZSBQQVJFTlRTIGRlY2xhcmF0aW9uLCBj cmVhdGUgYSBtYXAgZnJvbSBidWlsdGluLXR5cGUKOzsgICB0byB0aGUgc2V0IG9mIGNsLXR5 cGVzIHRoYXQgaGF2ZSB0aGF0IGJ1aWx0aW4tdHlwZSBhbW9uZyB0aGVpcgo7OyAgIHBhcmVu dHMuICBUaGF0IHByZXN1bWVzIHNvbWUgUEFSRU5UUyBpbmNsdWRlIHNvbWUgYnVpbHRpbi10 eXBlcywKOzsgICBvYnZpb3VzbHkgb3RoZXJ3aXNlIHRoZSBtYXAgd2lsbCBiZSB0cml2aWFs IHdpdGggYWxsIGNsLXR5cGVzCjs7ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBgdCcgImR1bW15 IHBhcmVudCIuICBbIFdlIGNvdWxkIGV2ZW4gZ28gY3JhenkKOzsgICBhbmQgdHJ5IGFuZCBn dWVzcyBQQVJFTlRTIHdoZW4gbm90IHByb3ZpZGVkLCBieSBhbmFseXppbmcgdGhlCjs7ICAg dHlwZSdzIGRlZmluaXRpb24uIF0KOzsKOzsgLSBpbiBgY2wtdHlwZXMtb2YnIHN0YXJ0IGJ5 IGNhbGxpbmcgYGNsLXR5cGUtb2YnLCB0aGVuIHVzZSB0aGUgbWFwCjs7ICAgdG8gZmluZCB3 aGljaCBjbC10eXBlcyBtYXkgbmVlZCB0byBiZSBjaGVja2VkLgo7OwooZGVmdW4gY2wtdHlw ZXMtb2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0by4K UmV0dXJuIGFuIHVuaXF1ZSBsaXN0IG9mIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRl cmVkIGZyb20gdGhlCm1vc3Qgc3BlY2lmaWMgdHlwZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIK ICAobGV0IChmb3VuZCkKICAgIDs7IEJ1aWxkIGEgbGlzdCBvZiBhbGwgdHlwZXMgT0JKRUNU IGJlbG9uZ3MgdG8uCiAgICAoZG9saXN0ICh0eXBlIGNsLS10eXBlLWxpc3QpCiAgICAgIChh bmQKICAgICAgIDs7IFNraXAgdHlwZSwgaWYgaXQgcHJldmlvdXNseSBwcm9kdWNlZCBhbiBl cnJvci4KICAgICAgIChudWxsIChnZXQgdHlwZSAnY2wtLXR5cGUtZXJyb3IpKQogICAgICAg OzsgU2tpcCB0eXBlIG5vdCBkZWZpbmVkIGJ5IGBjbC1kZWZ0eXBlJy4KICAgICAgIChjbC10 eXBlLWNsYXNzLXAgKGNsLS1maW5kLWNsYXNzIHR5cGUpKQogICAgICAgOzsgSWYgQkFSIGlz IGRlY2xhcmVkIGFzIGEgcGFyZW50IG9mIEZPTyBhbmQgYGNsLXR5cGVzLW9mJyBoYXMKICAg ICAgIDs7IGFscmVhZHkgZGVjaWRlZCB0aGF0IHRoZSB2YWx1ZSBpcyBvZiB0eXBlIEZPTywg dGhlbiB3ZQogICAgICAgOzsgYWxyZWFkeSBrbm93IEJBUiB3aWxsIGJlIGluIHRoZSBvdXRw dXQgYW55d2F5IGFuZCB0aGVyZSdzIG5vCiAgICAgICA7OyBwb2ludCB0ZXN0aW5nIEJBUi4g IFNvLCBza2lwIHR5cGUgYWxyZWFkeSBzZWxlY3RlZCBhcyBwYXJlbnQKICAgICAgIDs7IG9m IGFub3RoZXIgdHlwZSwgYXNzdW1pbmcgdGhhdCwgbW9zdCBvZiB0aGUgdGltZSwgYGFzc3En CiAgICAgICA7OyB3aWxsIGJlIGZhc3RlciB0aGFuIGBjbC10eXBlcCcuCiAgICAgICAobnVs bCAoYXNzcSB0eXBlIGZvdW5kKSkKICAgICAgIDs7IElmIE9CSkVDVCBpcyBvZiB0eXBlLCBh ZGQgdHlwZSB0byB0aGUgbWF0Y2hpbmcgbGlzdC4KICAgICAgIChjb25kaXRpb24tY2FzZS11 bmxlc3MtZGVidWcgZQogICAgICAgICAgIChjbC10eXBlcCBvYmplY3QgdHlwZSkKICAgICAg ICAgKGVycm9yIChjbC0tdHlwZS1lcnJvciB0eXBlIGUpKSkKICAgICAgIChwdXNoIHR5cGUg Zm91bmQpKSkKICAgIDs7IFJldHVybiBhbiB1bmlxdWUgdmFsdWUgb2YgdGhlIGxpc3Qgb2Yg dHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8sCiAgICA7OyB3aGljaCBpcyBhbHNvIHRoZSBsaXN0 IG9mIHNwZWNpZmllcnMgZm9yIE9CSkVDVC4KICAgICh3aXRoLW1lbW9pemF0aW9uIChnZXRo YXNoIGZvdW5kIGNsLS10eXBlLXVuaXF1ZSkKICAgICAgOzsgQ29tcHV0ZSBhIERBRyBmcm9t IHRoZSBjb2xsZWN0ZWQgbWF0Y2hpbmcgdHlwZXMuCiAgICAgIChsZXQgKGRhZykKICAgICAg ICAoZG9saXN0ICh0eXBlIGZvdW5kKQogICAgICAgICAgKGxldCAoKHBsIChjbC0tdHlwZS1w YXJlbnRzIHR5cGUpKSkKICAgICAgICAgICAgKHdoaWxlIHBsCiAgICAgICAgICAgICAgKHB1 c2ggcGwgZGFnKQogICAgICAgICAgICAgIChzZXRxIHBsIChjZHIgcGwpKSkpKQogICAgICAg IDs7IENvbXB1dGUgYW4gb3JkZXJlZCBsaXN0IG9mIHR5cGVzIGZyb20gdGhlIERBRy4KICAg ICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cwogICAgICAgICAobnJldmVyc2UgKGNvbnMgKGNs LS10eXBlLXBhcmVudHMgKGNsLXR5cGUtb2Ygb2JqZWN0KSkKICAgICAgICAgICAgICAgICAg ICAgICAgIGRhZykpKSkpKSkKCjs7OyBNZXRob2QgZGlzcGF0Y2hpbmcKOzsKKGNsLWdlbmVy aWMtZGVmaW5lLWdlbmVyYWxpemVyIGNsLS10eXBlLWdlbmVyYWxpemVyCiAgMjAgOzsgInR5 cGVvZiIgPCAiY2wtdHlwZXMtb2YiIDwgImhlYWQiIHByaW9yaXR5CiAgKGxhbWJkYSAob2Jq ICZyZXN0IF8pIGAoY2wtdHlwZXMtb2YgLG9iaikpCiAgKGxhbWJkYSAodGFnICZyZXN0IF8p IChpZiAoY29uc3AgdGFnKSB0YWcpKSkKCihjbC1kZWZtZXRob2QgY2wtZ2VuZXJpYy1nZW5l cmFsaXplcnMgOmV4dHJhICJjbC10eXBlcy1vZiIgKHR5cGUpCiAgIlN1cHBvcnQgZm9yIGRp c3BhdGNoIG9uIGNsLXR5cGVzLiIKICAoaWYgKGNsLS10eXBlLXAgdHlwZSkKICAgICAgKGxp c3QgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIpCiAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQoK KHByb3ZpZGUgJ2NsLXR5cGVzKQoKOzs7IGNsLXR5cGVzLmVsIGVuZHMgaGVyZQo= --------------wX7ISlduev3upoIOjvky26gv--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 28 Apr 2025 21:45:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 28 17:45:23 2025
Received: from localhost ([127.0.0.1]:37380 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u9WHu-0002l3-GU
for submit <at> debbugs.gnu.org; Mon, 28 Apr 2025 17:45:23 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54729)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u9WHg-0002cV-5D
for 77725 <at> debbugs.gnu.org; Mon, 28 Apr 2025 17:45:13 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8B727442895;
Mon, 28 Apr 2025 17:44:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745876690;
bh=jW4Hc+jcpsO+RgPkPzYgVz+Eth2Xm920adTwRPPlmIs=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=o7MWMNEQJ2D0z91X3LNtzTrTtlgycpUlkU0lsXiENhR90bFKJlNscuxFywCylUvPd
IBvu6cEO7OeLpX+lKaaeiqUARtSfdRRuWM1Z1xtfKFEnUlmLzhsuJ3MyosYj6oQxD1
xSf/Bddv63040kMc3g/vOdXWTCsNqvwmggVmDNQFNYPvG/Zfm1aGxlOZqAbgcynjjJ
ktnZPttyTgxfRZ0MctZGdae35Y1Si5g7j7tulBxrLDpOu7OLo765NkO3PrHw2LoE3d
gVyqHq1K1M15FuPTKFdqVm2qKDfBOEWyHDFLlrRoJLAVxiDhgTJ5EoPHo3wbBOP5Zy
13j3nbdsdfN8Q==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BDCF444274B;
Mon, 28 Apr 2025 17:44:50 -0400 (EDT)
Received: from asado (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 99A0E12063D;
Mon, 28 Apr 2025 17:44:50 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
Message-ID: <jwv1ptc2cfe.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
<jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
<8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN>
Date: Mon, 28 Apr 2025 17:44:49 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.214 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--=-=-=
Content-Type: text/plain
> I quite like this approach, where it's not `cl-types-of', but each type
> that bears responsibility for its implementation.
Usually, I like to solve a problem centrally so it's done once and for
all, but here the problem is that breaking recursion is tricky business
which may need to be done in different ways in different cases, and on
top of that it's a fairly rare need, so I think in this case dumping the
responsibility onto those rare users of circularity in types is the
right tradeoff.
> So, if I understand correctly, your recommendation is to not try to solve
> recursion (or other) problems in `cl-types-of' at all, but rather at the
> level of each type's definition, and to let ill-defined types possibly
> cause errors?
Basically, yes.
> The only point that still bothers me is not protecting `cl-types-of' from
> errors due to ill-defined types. This is particularly true because this
> can impact the entire Emacs session if certain methods are prevented from
> working, such as those involved in the display process (I use such methods
> based on `cl-deftype' for example, in my own alternative implementation of
> icons and tab-line).
Fair enough.
I pushed your new code to the `scratch/cl-types` branch in `emacs.git`.
I haven't integrated it into the other CL-Lib files yet.
See patch below for comments on your code.
Stefan
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=cl-types.patch
diff --git a/lisp/emacs-lisp/cl-types.el b/lisp/emacs-lisp/cl-types.el
index 0a384e09d79..830acb1ff0c 100644
--- a/lisp/emacs-lisp/cl-types.el
+++ b/lisp/emacs-lisp/cl-types.el
@@ -46,12 +46,13 @@ cl--type-p
That is, a type of class `cl-type-class'."
(and (symbolp object) (cl-type-class-p (cl--find-class object))))
-(defmacro cl--type-parents (name)
+(defmacro cl--type-parents (name) ;FIXME: Make it a `defun' or `defsubst'!
"Get parents of type with NAME.
NAME is a symbol representing a type."
`(cl--class-allparents (cl--find-class ,name)))
(defun cl--type-children (name)
+ ;; FIXME: Isn't that he same as `cl--class-children'?
"Get children of the type with NAME.
NAME is a symbol representing a type.
Return a possibly empty list of types."
@@ -82,6 +83,7 @@ cl--type-undefine
(setq cl--type-list (delq name cl--type-list)))
(defun cl--type-deftype (name parents &optional docstring)
+ ;; FIXME: Should we also receive the arglist?
"Generalize type with NAME for method dispatching.
PARENTS is a list of types NAME is a subtype of, or nil.
DOCSTRING is an optional documentation string."
@@ -95,8 +97,13 @@ cl--type-deftype
(error "Type generalized, but doesn't exist"))
(or recorded (error "Type exists, but not generalized"))
(or (cl-type-class-p class)
+ ;; FIXME: We have some uses `cl-deftype' in Emacs that
+ ;; "complement" another declaration of the same type, so
+ ;; maybe we should turn this into a warning (and not overwrite
+ ;; the `cl--find-class' in that case)?
(error "Type in another class: %S" (type-of class))))
(if (memq name parents)
+ ;; FIXME: This test should be performed in the macro not here.
(error "Type in parents: %S" parents))
;; Setup a type descriptor for NAME.
(setf (cl--find-class name)
@@ -110,12 +117,21 @@ cl--type-deftype
;; all those an object belongs to, sorted from the most
;; specific type to the more general type. So, keep the
;; global list in this order.
+ ;; FIXME: This global operation is a bit worrisome, because it
+ ;; scales poorly with the number of types. I guess it's OK
+ ;; for now because `cl-deftype' is not very popular, but it'll
+ ;; probably need to be replaced at some point. Maybe we
+ ;; should simply require that the parents be defined already,
+ ;; then we can just `push' the new type, knowing it's in
+ ;; topological order by construction.
(setq cl--type-list
(merge-ordered-lists
(cl--type-dag)
(lambda (_) (error "Invalid dependency graph")))))
(error
;; On error restore previous data.
+ ;; FIXME: `cl--type-list' has not been changed yet at this point, AFAIK,
+ ;; so restoring with `oldtlist' is always redundant.
(setq cl--type-list oldtlist)
(setf (symbol-plist name) oldplist)
(error (format "Define %S failed: %s"
@@ -155,16 +171,27 @@ cl-deftype2
((`(,decls . ,forms) (macroexp-parse-body body))
(docstring (if (stringp (car decls))
(car decls)
- (cadr (assq :documentation decls))))
- (parents (cdr (assq 'parents (cdr (assq 'declare decls))))))
+ (cadr (assq :documentation decls))))
+ (declares (assq 'declare decls))
+ (parent-decl (assq 'parents (cdr declares)))
+ (parents (cdr parent-decl)))
+ (when parent-decl
+ ;; "Consume" the `parents' declaration.
+ (cl-callf (lambda (x) (delq parent-decl x)) (cdr declares))
+ (when (equal declares '(declare))
+ (cl-callf (lambda (x) (delq declares x)) decls)))
(and parents arglist
(error "Parents specified, but arglist not empty"))
- (if docstring (setq forms (cons docstring forms)))
`(eval-and-compile ;;cl-eval-when (compile load eval)
+ ;; FIXME: Where should `cl--type-deftype' go? Currently, code
+ ;; using `cl-deftype' can use (eval-when-compile (require 'cl-lib)),
+ ;; so `cl--type-deftype' needs to go either to `cl-preloaded.el'
+ ;; or it should be autoloaded even when `cl-lib' is not loaded.
(cl--type-deftype ',name ',parents ,docstring)
(define-symbol-prop ',name 'cl-deftype-handler
(cl-function
(lambda (&cl-defs ('*) ,@arglist)
+ ,@decls
,@forms))))))
;; Ensure each type satisfies `eql'.
@@ -226,6 +253,9 @@ cl-types-of
"Return the types OBJECT belongs to.
Return an unique list of types OBJECT belongs to, ordered from the
most specific type to the most general."
+ ;; FIXME: The current implementation of `cl--type-parents' is
+ ;; moderately expensive, so we should probably avoid calling it
+ ;; before we do the `gethash'.
(let ((found (list (cl--type-parents (cl-type-of object)))))
;; Build a DAG of all types OBJECT belongs to.
(dolist (type cl--type-list)
@@ -242,6 +272,9 @@ cl-types-of
;; will be faster than `cl-typep'.
(null (assq type found))
;; If OBJECT is of type, add type and its parents to the DAG.
+ ;; FIXME: This `condition-case' will make it harder to get a backtrace
+ ;; to debug the error in the type definition. So maybe
+ ;; use `condition-case-unless-debug'.
(condition-case e
(cl-typep object type)
(error (cl--type-error type e)))
@@ -254,11 +287,10 @@ cl-types-of
(push pl found)
(setq pl (cdr pl))))))
;; Compute an ordered list of types from the collected DAG.
- (setq found (merge-ordered-lists found))
;; Return an unique value of this list of types, which is also the
;; list of specifiers for this type.
(with-memoization (gethash found cl--type-unique)
- found)))
+ (merge-ordered-lists found))))
;;; Method dispatching
;;
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 28 Apr 2025 10:56:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 28 06:56:50 2025 Received: from localhost ([127.0.0.1]:54501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u9MAL-0003qH-Ap for submit <at> debbugs.gnu.org; Mon, 28 Apr 2025 06:56:50 -0400 Received: from smtp-73.smtpout.orange.fr ([80.12.242.73]:39753 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u9MAF-0003pz-Av for 77725 <at> debbugs.gnu.org; Mon, 28 Apr 2025 06:56:47 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 9MA7u5rBB5k819MAAuffQ2; Mon, 28 Apr 2025 12:56:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745837801; bh=naXhKEH5u/qmLNS5YEi6v6kda32w4lOtwMpJs0eu1bQ=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=DjQ8x7++PP9Mpu+1OkLxnSscouV/IxPJfSMHBmIL2IHFXFx+dsI1nZiCbwStXBcVI yHgy03bWWFpqN7hgzCAA1GFz53NPZduUWBdMebihKjUoOO7X9Rcq8adyWBGL9gZ4a0 Vuy4TQ408zQJqBTnpSHNGocJKE2uXsZaU18v+Gh8QbcIA78qY1ojoemn5q/+Z6uAky u/pENM0gASwAgZwbc4cnMIMl6GGX14S5fGBK/EGEEmTJEK+U+2U5YloXkIOhr5E0zS Pf+d2QDqCU5ii4Zlcph3Ua/iSBgBj538cI5lfzCtGzxAdOPtz7IidcwQg9mam14+KA RY8M/KV91qwEw== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Mon, 28 Apr 2025 12:56:41 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------IFhIYKTIZdYTv2nFCBYlduCU" Message-ID: <86086316-6416-47c0-b7b5-42b84c25c5de@HIDDEN> Date: Mon, 28 Apr 2025 12:56:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? From: David Ponce <da_vid@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN> <1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN> <jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN> <0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN> <jwvwmb6yylb.fsf-monnier+emacs@HIDDEN> <jwv5xiplqbk.fsf-monnier+emacs@HIDDEN> <8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN> Content-Language: fr, en-US In-Reply-To: <8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------IFhIYKTIZdYTv2nFCBYlduCU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025-04-27 17:31, David Ponce wrote: > On 2025-04-27 14:59, Stefan Monnier wrote: >>>> Exactly, I fully agree, the question is "how to keep track of the >>>> children"? >>> >>> You could approximate it with `after-load-functions`. Or, with the >>> proposed patch, you could use an advice on `cl--type-deftype`. Once you >>> do that, you won't need to break circularity in `cl-types-of`. >> >> I think what I was trying to say all along is: >> the circularity you're trying to break doesn't come from `cl-deftype` or >> `cl-types-of` but from your impredicative definition of `T1`. >> So it'd be best to fix it there: >> >> (cl-deftype T1 () >> `(satisfies ,(lambda (o) (memq 'T1 (cl-types-of o))))) >> >> => >> >> (defvar my-pending-T1-check (make-symbol "void")) >> >> (cl-deftype T1 () >> `(satisfies >> ,(lambda (o) >> (and (not (eq o my-pending-T1-check)) >> (let ((my-pending-T1-check o)) >> (memq 'T1 (cl-types-of o))))))) >> > > Hi Stefan, > > I quite like this approach, where it's not `cl-types-of', but each type > that bears responsibility for its implementation. > > So, if I understand correctly, your recommendation is to not try to solve > recursion (or other) problems in `cl-types-of' at all, but rather at the > level of each type's definition, and to let ill-defined types possibly > cause errors? > > The only point that still bothers me is not protecting `cl-types-of' from > errors due to ill-defined types. This is particularly true because this > can impact the entire Emacs session if certain methods are prevented from > working, such as those involved in the display process (I use such methods > based on `cl-deftype' for example, in my own alternative implementation of > icons and tab-line). > > If you agree I will update cl-types.el accordingly and dispatch it in > the existing libraries according to your previous proposal... to see what > happens ;-) > > Thanks again for being so helpful! > > David Please find attached a new version of cl-types.el, where any attempt to work around type definition errors with `cl-types-of' has been removed. If such an error occurs, it is now clearly signaled by `warn', and the affected type is marked as "in error" and ignored until its next redefinition or deletion. WDYT? --------------IFhIYKTIZdYTv2nFCBYlduCU Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el" Content-Disposition: attachment; filename="cl-types.el" Content-Transfer-Encoding: base64 OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBEYXRhIHR5cGVzIGRlZmluZWQg YnkgYGNsLWRlZnR5cGUnIGFyZSBub3cgcmVjb2duaXplZCBhcyBhcmd1bWVudAo7OyB0eXBl cyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbnMgbWV0aG9kcy4KCjs7IFdpbGwg YmUgcmVtb3ZlZCB3aGVuIGluY2x1ZGVkIGluIGNsLWxpYi4KKHJlcXVpcmUgJ2NsLWxpYikK KGV2YWwtd2hlbi1jb21waWxlIChyZXF1aXJlICdjbC1tYWNzKSkgIDtGb3IgY2wtLWZpbmQt Y2xhc3MuCgo7OyBFeHRlbmQgYGNsLWRlZnR5cGUnIHRvIGRlZmluZSBkYXRhIHR5cGVzIHdo aWNoIGFyZSBhbHNvIHZhbGlkCjs7IGFyZ3VtZW50IHR5cGVzIGZvciBkaXNwYXRjaGluZyBn ZW5lcmljIGZ1bmN0aW9uIG1ldGhvZHMgKHNlZSBhbHNvCjs7IDxodHRwczovL2RlYmJ1Z3Mu Z251Lm9yZy9jZ2kvYnVncmVwb3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4g ZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgY2wtZGVmdHlwZScsIHRoYXQgZGVmaW5lcyBu ZXcgZGF0YSB0eXBlcy4KOzsKOzsgLSBgY2wtdHlwZXMtb2YnLCB0aGF0IHJldHVybnMgdGhl IHR5cGVzIGFuIG9iamVjdCBiZWxvbmdzIHRvLgoKKGRlZnZhciBjbC0tdHlwZS1saXN0IG5p bAogICJMaXN0IG9mIGRlZmluZWQgdHlwZXMgdG8gbG9va3VwIGZvciBtZXRob2QgZGlzcGF0 Y2hpbmcuIikKCjs7IEZJWE1FOiBUaGUgYGNsLWRlZnR5cGUtaGFuZGxlcicgcHJvcGVydHkg c2hvdWxkIGFyZ3VhYmx5IGJlIHR1cm5lZAo7OyBpbnRvIGEgZmllbGQgb2YgdGhpcyBzdHJ1 Y3QgKGJ1dCBpdCBoYXMgcGVyZm9ybWFuY2UgYW5kCjs7IGNvbXBhdGliaWxpdHkgaW1wbGlj YXRpb25zLCBzbyBsZXQncyBub3QgbWFrZSB0aGF0IGNoYW5nZSBmb3Igbm93KS4KKGNsLWRl ZnN0cnVjdAogICAgKGNsLXR5cGUtY2xhc3MKICAgICAoOmluY2x1ZGUgY2wtLWNsYXNzKQog ICAgICg6bm9pbmxpbmUgdCkKICAgICAoOmNvbnN0cnVjdG9yIG5pbCkKICAgICAoOmNvbnN0 cnVjdG9yIGNsLS10eXBlLWNsYXNzLW1ha2UKICAgICAgICAgICAgICAgICAgIChuYW1lCiAg ICAgICAgICAgICAgICAgICAgZG9jc3RyaW5nCiAgICAgICAgICAgICAgICAgICAgcGFyZW50 LXR5cGVzCiAgICAgICAgICAgICAgICAgICAgJmF1eCAocGFyZW50cwogICAgICAgICAgICAg ICAgICAgICAgICAgIChtYXBjYXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJk YSAodHlwZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAob3IgKGNsLS1maW5kLWNs YXNzIHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcnJvciAiVW5r bm93biB0eXBlOiAlUyIgdHlwZSkpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJl bnQtdHlwZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBm b3IgdHlwZXMgZGVmaW5lZCBieSBgY2wtZGVmdHlwZScuIikKCihkZWZ1biBjbC0tdHlwZS1w IChvYmplY3QpCiAgIlJldHVybiBub24tbmlsIGlmIE9CSkVDVCBpcyBhIHVzZWQgZGVmaW5l ZCB0eXBlLgpUaGF0IGlzLCBhIHR5cGUgb2YgY2xhc3MgYGNsLXR5cGUtY2xhc3MnLiIKICAo YW5kIChzeW1ib2xwIG9iamVjdCkgKGNsLXR5cGUtY2xhc3MtcCAoY2wtLWZpbmQtY2xhc3Mg b2JqZWN0KSkpKQoKKGRlZm1hY3JvIGNsLS10eXBlLXBhcmVudHMgKG5hbWUpCiAgIkdldCBw YXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2VudGlu ZyBhIHR5cGUuIgogIGAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNzICxu YW1lKSkpCgooZGVmdW4gY2wtLXR5cGUtY2hpbGRyZW4gKG5hbWUpCiAgIkdldCBjaGlsZHJl biBvZiB0aGUgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5n IGEgdHlwZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAgKGNs LWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXApKQogIChsZXQgKGNoaWxk cmVuKQogICAgKGRvbGlzdCAoZWx0IGNsLS10eXBlLWxpc3QpCiAgICAgIChvciAoZXEgbmFt ZSBlbHQpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSAoY2wtLXR5cGUtcGFyZW50cyBlbHQp KQogICAgICAgICAgICAgIChwdXNoIGVsdCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVuKSkK CihkZWZ1biBjbC0tdHlwZS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZyb20gdGhlIGxpc3Qg b2YgZGVmaW5lZCB0eXBlcy4iCiAgKG1hcGNhciAobGFtYmRhICh0eXBlKSAoY2wtLXR5cGUt cGFyZW50cyB0eXBlKSkgY2wtLXR5cGUtbGlzdCkpCgo7OyBLZWVwIGl0IGZvciBub3csIGZv ciB0ZXN0aW5nLgooZGVmdW4gY2wtLXR5cGUtdW5kZWZpbmUgKG5hbWUpCiAgIlJlbW92ZSB0 aGUgZGVmaW5pdGlvbnMgb2YgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYW4gdW5xdW90ZWQg c3ltYm9sIHJlcHJlc2VudGluZyBhIHR5cGUuClNpZ25hbCBhbiBlcnJvciBpZiBvdGhlciB0 eXBlcyBpbmhlcml0IGZyb20gTkFNRS4iCiAgKGRlY2xhcmUtZnVuY3Rpb24gY2wtcmVtcHJv cCAiY2wtZXh0cmEiIChzeW1ib2wgcHJvcG5hbWUpKQogIChjbC1jaGVjay10eXBlIG5hbWUg KHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAod2hlbi1sZXQqICgoY2hpbGRyZW4gKGFuZCAo Y2wtLXR5cGUtcCBuYW1lKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC0tdHlw ZS1jaGlsZHJlbiBuYW1lKSkpKQogICAgKGVycm9yICJUeXBlIGhhcyBjaGlsZHJlbjogJVMi IGNoaWxkcmVuKSkKICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXBy b3AgbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVyKQogIChzZXRxIGNsLS10eXBlLWxpc3QgKGRl bHEgbmFtZSBjbC0tdHlwZS1saXN0KSkpCgooZGVmdW4gY2wtLXR5cGUtZGVmdHlwZSAobmFt ZSBwYXJlbnRzICZvcHRpb25hbCBkb2NzdHJpbmcpCiAgIkdlbmVyYWxpemUgdHlwZSB3aXRo IE5BTUUgZm9yIG1ldGhvZCBkaXNwYXRjaGluZy4KUEFSRU5UUyBpcyBhIGxpc3Qgb2YgdHlw ZXMgTkFNRSBpcyBhIHN1YnR5cGUgb2YsIG9yIG5pbC4KRE9DU1RSSU5HIGlzIGFuIG9wdGlv bmFsIGRvY3VtZW50YXRpb24gc3RyaW5nLiIKICAobGV0ICgob2xkdGxpc3QgKGNvcHktc2Vx dWVuY2UgY2wtLXR5cGUtbGlzdCkpCiAgICAgICAgKG9sZHBsaXN0IChjb3B5LXNlcXVlbmNl IChzeW1ib2wtcGxpc3QgbmFtZSkpKSkKICAgIChjb25kaXRpb24tY2FzZSBlcnIKICAgICAg ICAobGV0KiAoKGNsYXNzIChjbC0tZmluZC1jbGFzcyBuYW1lKSkKICAgICAgICAgICAgICAg KHJlY29yZGVkIChtZW1xIG5hbWUgY2wtLXR5cGUtbGlzdCkpKQogICAgICAgICAgKGlmIChu dWxsIGNsYXNzKQogICAgICAgICAgICAgIChvciAobnVsbCByZWNvcmRlZCkKICAgICAgICAg ICAgICAgICAgKGVycm9yICJUeXBlIGdlbmVyYWxpemVkLCBidXQgZG9lc24ndCBleGlzdCIp KQogICAgICAgICAgICAob3IgcmVjb3JkZWQgKGVycm9yICJUeXBlIGV4aXN0cywgYnV0IG5v dCBnZW5lcmFsaXplZCIpKQogICAgICAgICAgICAob3IgKGNsLXR5cGUtY2xhc3MtcCBjbGFz cykKICAgICAgICAgICAgICAgIChlcnJvciAiVHlwZSBpbiBhbm90aGVyIGNsYXNzOiAlUyIg KHR5cGUtb2YgY2xhc3MpKSkpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSBwYXJlbnRzKQog ICAgICAgICAgICAgIChlcnJvciAiVHlwZSBpbiBwYXJlbnRzOiAlUyIgcGFyZW50cykpCiAg ICAgICAgICA7OyBTZXR1cCBhIHR5cGUgZGVzY3JpcHRvciBmb3IgTkFNRS4KICAgICAgICAg IChzZXRmIChjbC0tZmluZC1jbGFzcyBuYW1lKQogICAgICAgICAgICAgICAgKGNsLS10eXBl LWNsYXNzLW1ha2UgbmFtZSBkb2NzdHJpbmcgcGFyZW50cykpCiAgICAgICAgICAoaWYgcmVj b3JkZWQKICAgICAgICAgICAgICA7OyBDbGVhciBhbnkgcHJldmlvdXMgZXJyb3IgbWFyay4K ICAgICAgICAgICAgICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tdHlwZS1lcnJvcikKICAgICAg ICAgICAgOzsgUmVjb3JkIG5ldyB0eXBlIHRvIGluY2x1ZGUgaXRzIGRlcGVuZGVuY3kgaW4g dGhlIERBRy4KICAgICAgICAgICAgKHB1c2ggbmFtZSBjbC0tdHlwZS1saXN0KSkKICAgICAg ICAgIDs7IGBjbC10eXBlcy1vZicgaXRlcmF0ZXMgdGhyb3VnaCBhbGwga25vd24gdHlwZXMg dG8gY29sbGVjdAogICAgICAgICAgOzsgYWxsIHRob3NlIGFuIG9iamVjdCBiZWxvbmdzIHRv LCBzb3J0ZWQgZnJvbSB0aGUgbW9zdAogICAgICAgICAgOzsgc3BlY2lmaWMgdHlwZSB0byB0 aGUgbW9yZSBnZW5lcmFsIHR5cGUuICBTbywga2VlcCB0aGUKICAgICAgICAgIDs7IGdsb2Jh bCBsaXN0IGluIHRoaXMgb3JkZXIuCiAgICAgICAgICAoc2V0cSBjbC0tdHlwZS1saXN0CiAg ICAgICAgICAgICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cwogICAgICAgICAgICAgICAgIChj bC0tdHlwZS1kYWcpCiAgICAgICAgICAgICAgICAgKGxhbWJkYSAoXykgKGVycm9yICJJbnZh bGlkIGRlcGVuZGVuY3kgZ3JhcGgiKSkpKSkKICAgICAgKGVycm9yCiAgICAgICA7OyBPbiBl cnJvciByZXN0b3JlIHByZXZpb3VzIGRhdGEuCiAgICAgICAoc2V0cSBjbC0tdHlwZS1saXN0 IG9sZHRsaXN0KQogICAgICAgKHNldGYgKHN5bWJvbC1wbGlzdCBuYW1lKSBvbGRwbGlzdCkK ICAgICAgIChlcnJvciAoZm9ybWF0ICJEZWZpbmUgJVMgZmFpbGVkOiAlcyIKICAgICAgICAg ICAgICAgICAgICAgIG5hbWUgKGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVycikpKSkpKSkKCjs7 OyMjI2F1dG9sb2FkCihkZWZtYWNybyBjbC1kZWZ0eXBlMiAobmFtZSBhcmdsaXN0ICZyZXN0 IGJvZHkpCiAgIkRlZmluZSBOQU1FIGFzIGEgbmV3IGRhdGEgdHlwZS4KVGhlIHR5cGUgTkFN RSBjYW4gdGhlbiBiZSB1c2VkIGluIGBjbC10eXBlY2FzZScsIGBjbC1jaGVjay10eXBlJywK ZXRjLiwgYW5kIGFzIGFyZ3VtZW50IHR5cGUgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVu Y3Rpb24gbWV0aG9kcy4KCkFSR0xJU1QgaXMgYSBDb21tb24gTGlzcCBhcmd1bWVudCBsaXN0 IG9mIHRoZSBzb3J0IGFjY2VwdGVkIGJ5CmBjbC1kZWZtYWNybycuICBCT0RZIGZvcm1zIGFy ZSBldmFsdWF0ZWQgYW5kIHNob3VsZCByZXR1cm4gYSB0eXBlCnNwZWNpZmllciB0aGF0IGlz IGVxdWl2YWxlbnQgdG8gdGhlIHR5cGUgKHNlZSB0aGUgSW5mbyBub2RlIGAoY2wpIFR5cGUK UHJlZGljYXRlcycgaW4gdGhlIEdOVSBFbWFjcyBDb21tb24gTGlzcCBFbXVsYXRpb24gbWFu dWFsKS4KCklmIHRoZXJlIGlzIGEgYGRlY2xhcmUnIGZvcm0gaW4gQk9EWSwgdGhlIHNwZWMg KHBhcmVudHMgUEFSRU5UUykgaXMKcmVjb2duaXplZCB0byBzcGVjaWZ5IGEgbGlzdCBvZiB0 eXBlcyBOQU1FIGlzIGEgc3VidHlwZSBvZi4gIEZvcgppbnN0YW5jZToKCiAgKGNsLWRlZnR5 cGUyIHVuc2lnbmVkLWJ5dGUgKCZvcHRpb25hbCBiaXRzKQogICAgXCJVbnNpZ25lZCBpbnRl Z2VyLlwiCiAgICAobGlzdCBcXD0naW50ZWdlciAwIChpZiAoZXEgYml0cyBcXD0nKikgYml0 cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQoKICAoY2wtZGVmdHlwZTIgdW5zaWduZWQtOGJpdHMg KCkKICAgIFwiVW5zaWduZWQgOC1iaXRzIGludGVnZXIuXCIKICAgIChkZWNsYXJlIChwYXJl bnRzIHVuc2lnbmVkLWJ5dGUpKQogICAgXFw9Jyh1bnNpZ25lZC1ieXRlIDgpKQoKVGhlIGxp c3Qgb2YgUEFSRU5UUyB0eXBlcyBkZXRlcm1pbmVzIHRoZSBvcmRlciBvZiBtZXRob2RzIGlu dm9jYXRpb24sCmFuZCBtaXNzaW5nIFBBUkVOVFMgbWF5IGNhdXNlIGluY29ycmVjdCBvcmRl cmluZyBvZiBtZXRob2RzLCB3aGlsZQpleHRyYW5lb3VzIFBBUkVOVFMgbWF5IGNhdXNlIHVz ZSBvZiBleHRyYW5lb3VzIG1ldGhvZHMuCgpJZiBQQVJFTlRTIGlzIG5vbi1uaWwsIEFSR0xJ U1QgbXVzdCBiZSBuaWwuIgogIChkZWNsYXJlIChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1z dHJpbmcgMykgKGluZGVudCAyKSkKICAocGNhc2UtbGV0KgogICAgICAoKGAoLGRlY2xzIC4g LGZvcm1zKSAobWFjcm9leHAtcGFyc2UtYm9keSBib2R5KSkKICAgICAgIChkb2NzdHJpbmcg KGlmIChzdHJpbmdwIChjYXIgZGVjbHMpKQogICAgICAgICAgICAgICAgICAgICAgKGNhciBk ZWNscykKICAgICAgICAgICAgICAgICAgICAoY2FkciAoYXNzcSA6ZG9jdW1lbnRhdGlvbiBk ZWNscykpKSkKICAgICAgIChwYXJlbnRzIChjZHIgKGFzc3EgJ3BhcmVudHMgKGNkciAoYXNz cSAnZGVjbGFyZSBkZWNscykpKSkpKQogICAgKGFuZCBwYXJlbnRzIGFyZ2xpc3QKICAgICAg ICAgKGVycm9yICJQYXJlbnRzIHNwZWNpZmllZCwgYnV0IGFyZ2xpc3Qgbm90IGVtcHR5Iikp CiAgICAoaWYgZG9jc3RyaW5nIChzZXRxIGZvcm1zIChjb25zIGRvY3N0cmluZyBmb3Jtcykp KQogICAgYChldmFsLWFuZC1jb21waWxlIDs7Y2wtZXZhbC13aGVuIChjb21waWxlIGxvYWQg ZXZhbCkKICAgICAgIChjbC0tdHlwZS1kZWZ0eXBlICcsbmFtZSAnLHBhcmVudHMgLGRvY3N0 cmluZykKICAgICAgIChkZWZpbmUtc3ltYm9sLXByb3AgJyxuYW1lICdjbC1kZWZ0eXBlLWhh bmRsZXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNsLWZ1bmN0aW9uCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAobGFtYmRhICgmY2wtZGVmcyAoJyopICxAYXJnbGlzdCkK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLEBmb3JtcykpKSkpKQoKOzsgRW5zdXJl IGVhY2ggdHlwZSBzYXRpc2ZpZXMgYGVxbCcuCihkZWZ2YXIgY2wtLXR5cGUtdW5pcXVlICht YWtlLWhhc2gtdGFibGUgOnRlc3QgJ2VxdWFsKQogICJSZWNvcmQgYW4gdW5pcXVlIHZhbHVl IG9mIGVhY2ggdHlwZS4iKQoKKGRlZnVuIGNsLS10eXBlLWVycm9yICh0eXBlIGVycm9yKQog ICJNYXJrIFRZUEUgYXMgaW4tZXJyb3IsIGFuZCByZXBvcnQgdGhlIHByb2R1Y2VkIEVSUk9S IHZhbHVlLiIKICAocHV0IHR5cGUgJ2NsLS10eXBlLWVycm9yIGVycm9yKSA7OyBNYXJrIFRZ UEUgYXMgaW4tZXJyb3IuCiAgOzsgVGVtcG9yYXJpbHkgcmFpc2UgdGhlIHJlY3Vyc2lvbiBs aW1pdCB0byBhdm9pZCBhbm90aGVyIHJlY3Vyc2lvbgogIDs7IGVycm9yIHdoaWxlIHJlcG9y dGluZyBFUlJPUi4KICAobGV0ICgobWF4LWxpc3AtZXZhbC1kZXB0aCAoKyA4MDAgbWF4LWxp c3AtZXZhbC1kZXB0aCkpKQogICAgKHdhcm4gICJjbC10eXBlcy1vZiAlcywgJXMiIHR5cGUg KGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVycm9yKSkpCiAgbmlsKQoKOzsgRklYTUU6IGBjbC10 eXBlcy1vZicgQ1BVIGNvc3QgaXMgcHJvcG9ydGlvbmFsIHRvIHRoZSBudW1iZXIgb2YgdHlw ZXMKOzsgZGVmaW5lZCB3aXRoIGBjbC1kZWZ0eXBlJywgc28gdGhlIG1vcmUgcG9wdWxhciBp dCBnZXRzLCB0aGUgc2xvd2VyCjs7IGl0IGJlY29tZXMuICBBbmQgb2YgY291cnNlLCB0aGUg Y29zdCBvZiBlYWNoIHR5cGUgY2hlY2sgaXMKOzsgdW5ib3VuZGVkLCBzbyBhIHNpbmdsZSAi ZXhwZW5zaXZlIiB0eXBlIGNhbiBzbG93IGV2ZXJ5dGhpbmcgZG93bgo7OyBmdXJ0aGVyLgo7 Owo7OyBUaGUgdXN1YWwgZGlzcGF0Y2ggaXMKOzsKOzsgICAobGFtYmRhIChhcmcgJnJlc3Qg YXJncykKOzsgICAgIChsZXQgKChmIChnZXRoYXNoIChjbC10eXBlb2YgYXJnKSBwcmVjb21w dXRlZC1tZXRob2RzLXRhYmxlKSkpCjs7ICAgICAgIChpZiBmCjs7ICAgICAgICAgICAoYXBw bHkgZiBhcmcgYXJncykKOzsgICAgICAgICA7OyBTbG93IGNhc2Ugd2hlbiBlbmNvdW50ZXJp bmcgYSBuZXcgdHlwZQo7OyAgICAgICAgIC4uLikpKQo7Owo7OyB3aGVyZSBvZnRlbiB0aGUg bW9zdCBleHBlbnNpdmUgcGFydCBpcyBgJnJlc3QnICh3aGljaCBoYXMgdG8KOzsgYWxsb2Nh dGUgYSBsaXN0IGZvciB0aG9zZSByZW1haW5pbmcgYXJndW1lbnRzKSwKOzsKOzsgU28gd2Un cmUgdGFsa2luZyBhYm91dCByZXBsYWNpbmcKOzsKOzsgICAmcmVzdCArIGNsLXR5cGUtb2Yg KyBnZXRoYXNoICsgaWYgKyBhcHBseQo7Owo7OyB3aXRoIGEgZnVuY3Rpb24gdGhhdCBsb29w cyBvdmVyIE4gdHlwZXMsIGNhbGxpbmcgYGNsLXR5cGVwJyBvbiBlYWNoCjs7IG9uZSBvZiB0 aGVtIChgY2wtdHlwZXAnIGl0c2VsZiBiZWluZyBhIHJlY3Vyc2l2ZSBmdW5jdGlvbiB0aGF0 Cjs7IGJhc2ljYWxseSBpbnRlcnByZXRzIHRoZSB0eXBlIGxhbmd1YWdlKS4gIFRoaXMgaXMg Z29pbmcgdG8gc2xvdwo7OyBkb3duIGRpc3BhdGNoIHZlcnkgc2lnbmlmaWNhbnRseSBmb3Ig dGhvc2UgZ2VuZXJpYyBmdW5jdGlvbnMgdGhhdAo7OyBoYXZlIGEgbWV0aG9kIHRoYXQgZGlz cGF0Y2hlcyBvbiBhIHVzZXIgZGVmaW5lZCB0eXBlLCBjb21wYXJlZCB0bwo7OyB0aG9zZSB0 aGF0IGRvbid0Lgo7Owo7OyBBIHBvc3NpYmxlIGZ1cnRoZXIgaW1wcm92ZW1lbnQ6Cjs7Cjs7 IC0gYmFzZWQgb24gdGhlIFBBUkVOVFMgZGVjbGFyYXRpb24sIGNyZWF0ZSBhIG1hcCBmcm9t IGJ1aWx0aW4tdHlwZQo7OyAgIHRvIHRoZSBzZXQgb2YgY2wtdHlwZXMgdGhhdCBoYXZlIHRo YXQgYnVpbHRpbi10eXBlIGFtb25nIHRoZWlyCjs7ICAgcGFyZW50cy4gIFRoYXQgcHJlc3Vt ZXMgc29tZSBQQVJFTlRTIGluY2x1ZGUgc29tZSBidWlsdGluLXR5cGVzLAo7OyAgIG9idmlv dXNseSBvdGhlcndpc2UgdGhlIG1hcCB3aWxsIGJlIHRyaXZpYWwgd2l0aCBhbGwgY2wtdHlw ZXMKOzsgICBhc3NvY2lhdGVkIHdpdGggdGhlIGB0JyAiZHVtbXkgcGFyZW50Ii4gIFsgV2Ug Y291bGQgZXZlbiBnbyBjcmF6eQo7OyAgIGFuZCB0cnkgYW5kIGd1ZXNzIFBBUkVOVFMgd2hl biBub3QgcHJvdmlkZWQsIGJ5IGFuYWx5emluZyB0aGUKOzsgICB0eXBlJ3MgZGVmaW5pdGlv bi4gXQo7Owo7OyAtIGluIGBjbC10eXBlcy1vZicgc3RhcnQgYnkgY2FsbGluZyBgY2wtdHlw ZS1vZicsIHRoZW4gdXNlIHRoZSBtYXAKOzsgICB0byBmaW5kIHdoaWNoIGNsLXR5cGVzIG1h eSBuZWVkIHRvIGJlIGNoZWNrZWQuCjs7CihkZWZ1biBjbC10eXBlcy1vZiAob2JqZWN0KQog ICJSZXR1cm4gdGhlIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLgpSZXR1cm4gYW4gdW5pcXVl IGxpc3Qgb2YgdHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8sIG9yZGVyZWQgZnJvbSB0aGUKbW9z dCBzcGVjaWZpYyB0eXBlIHRvIHRoZSBtb3N0IGdlbmVyYWwuIgogIChsZXQgKChmb3VuZCAo bGlzdCAoY2wtLXR5cGUtcGFyZW50cyAoY2wtdHlwZS1vZiBvYmplY3QpKSkpKQogICAgOzsg QnVpbGQgYSBEQUcgb2YgYWxsIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLgogICAgKGRvbGlz dCAodHlwZSBjbC0tdHlwZS1saXN0KQogICAgICAoYW5kCiAgICAgICA7OyBTa2lwIHR5cGUs IGlmIGl0IHByZXZpb3VzbHkgcHJvZHVjZWQgYW4gZXJyb3IuCiAgICAgICAobnVsbCAoZ2V0 IHR5cGUgJ2NsLS10eXBlLWVycm9yKSkKICAgICAgIDs7IFNraXAgdHlwZSBub3QgZGVmaW5l ZCBieSBgY2wtZGVmdHlwZScuCiAgICAgICAoY2wtdHlwZS1jbGFzcy1wIChjbC0tZmluZC1j bGFzcyB0eXBlKSkKICAgICAgIDs7IElmIEJBUiBpcyBkZWNsYXJlZCBhcyBhIHBhcmVudCBv ZiBGT08gYW5kIGBjbC10eXBlcy1vZicgaGFzCiAgICAgICA7OyBhbHJlYWR5IGRlY2lkZWQg dGhhdCB0aGUgdmFsdWUgaXMgb2YgdHlwZSBGT08sIHRoZW4gd2UKICAgICAgIDs7IGFscmVh ZHkga25vdyBCQVIgd2lsbCBiZSBpbiB0aGUgb3V0cHV0IGFueXdheSBhbmQgdGhlcmUncyBu bwogICAgICAgOzsgcG9pbnQgdGVzdGluZyBCQVIuICBTbywgc2tpcCB0eXBlIGFscmVhZHkg c2VsZWN0ZWQgYXMgcGFyZW50CiAgICAgICA7OyBvZiBhbm90aGVyIHR5cGUsIGFzc3VtaW5n IHRoYXQsIG1vc3Qgb2YgdGhlIHRpbWUsIGBhc3NxJwogICAgICAgOzsgd2lsbCBiZSBmYXN0 ZXIgdGhhbiBgY2wtdHlwZXAnLgogICAgICAgKG51bGwgKGFzc3EgdHlwZSBmb3VuZCkpCiAg ICAgICA7OyBJZiBPQkpFQ1QgaXMgb2YgdHlwZSwgYWRkIHR5cGUgYW5kIGl0cyBwYXJlbnRz IHRvIHRoZSBEQUcuCiAgICAgICAoY29uZGl0aW9uLWNhc2UgZQogICAgICAgICAgIChjbC10 eXBlcCBvYmplY3QgdHlwZSkKICAgICAgICAgKGVycm9yIChjbC0tdHlwZS1lcnJvciB0eXBl IGUpKSkKICAgICAgIDs7IChkb2xpc3QgKHAgKGNsLS10eXBlLXBhcmVudHMgdHlwZSkpCiAg ICAgICA7OyAgIChwdXNoIChjbC0tdHlwZS1wYXJlbnRzIHApIGZvdW5kKSkKICAgICAgIDs7 IEVxdWl2YWxlbnQgdG8gdGhlIGBkb2xpc3QnIGFib3ZlLCBidXQgZmFzdGVyOiBhdm9pZCB0 bwogICAgICAgOzsgcmVjb21wdXRlIHNldmVyYWwgbGlzdHMgb2YgcGFyZW50cyB3ZSBhbHJl YWR5IGtub3cuCiAgICAgICAobGV0ICgocGwgKGNsLS10eXBlLXBhcmVudHMgdHlwZSkpKQog ICAgICAgICAod2hpbGUgcGwKICAgICAgICAgICAocHVzaCBwbCBmb3VuZCkKICAgICAgICAg ICAoc2V0cSBwbCAoY2RyIHBsKSkpKSkpCiAgICA7OyBDb21wdXRlIGFuIG9yZGVyZWQgbGlz dCBvZiB0eXBlcyBmcm9tIHRoZSBjb2xsZWN0ZWQgREFHLgogICAgKHNldHEgZm91bmQgKG1l cmdlLW9yZGVyZWQtbGlzdHMgZm91bmQpKQogICAgOzsgUmV0dXJuIGFuIHVuaXF1ZSB2YWx1 ZSBvZiB0aGlzIGxpc3Qgb2YgdHlwZXMsIHdoaWNoIGlzIGFsc28gdGhlCiAgICA7OyBsaXN0 IG9mIHNwZWNpZmllcnMgZm9yIHRoaXMgdHlwZS4KICAgICh3aXRoLW1lbW9pemF0aW9uIChn ZXRoYXNoIGZvdW5kIGNsLS10eXBlLXVuaXF1ZSkKICAgICAgZm91bmQpKSkKCjs7OyBNZXRo b2QgZGlzcGF0Y2hpbmcKOzsKKGNsLWdlbmVyaWMtZGVmaW5lLWdlbmVyYWxpemVyIGNsLS10 eXBlLWdlbmVyYWxpemVyCiAgMjAgOzsgInR5cGVvZiIgPCAiY2wtdHlwZXMtb2YiIDwgImhl YWQiIHByaW9yaXR5CiAgKGxhbWJkYSAob2JqICZyZXN0IF8pIGAoY2wtdHlwZXMtb2YgLG9i aikpCiAgKGxhbWJkYSAodGFnICZyZXN0IF8pIChpZiAoY29uc3AgdGFnKSB0YWcpKSkKCihj bC1kZWZtZXRob2QgY2wtZ2VuZXJpYy1nZW5lcmFsaXplcnMgOmV4dHJhICJjbC10eXBlcy1v ZiIgKHR5cGUpCiAgIlN1cHBvcnQgZm9yIGRpc3BhdGNoIG9uIHR5cGVzLiIKICAoaWYgKGNs LS10eXBlLXAgdHlwZSkKICAgICAgKGxpc3QgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIpCiAgICAo Y2wtY2FsbC1uZXh0LW1ldGhvZCkpKQoKKHByb3ZpZGUgJ2NsLXR5cGVzKQoKOzs7IGNsLXR5 cGVzLmVsIGVuZHMgaGVyZQo= --------------IFhIYKTIZdYTv2nFCBYlduCU--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 27 Apr 2025 15:31:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 27 11:31:51 2025 Received: from localhost ([127.0.0.1]:43669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u93yw-00007z-Pj for submit <at> debbugs.gnu.org; Sun, 27 Apr 2025 11:31:51 -0400 Received: from smtp-17.smtpout.orange.fr ([80.12.242.17]:55195 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u93yt-00007l-Rv for 77725 <at> debbugs.gnu.org; Sun, 27 Apr 2025 11:31:49 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 93yluiUwfXKsE93ypugVdF; Sun, 27 Apr 2025 17:31:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745767906; bh=fVIvenwD5GLJE3nEW3Nlaj9Wz0vnrfXXz7iGUXYaq4c=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=Ium3aheJJWChKlAGAPCAGlPDqGV7JbawfGs9M1JLOVTZ+oBqHiRFueRyJUQa5wovV V3Dis3vBQKK2ZWy62Xo6HSihiQxtqMwI3u58h2i/sAQw+oE0jyQhM0lev2P96lKHRW 8gZnTQylGccdKy6R6NHej+BJLpIirg1vRiuzdgv6QkOJhSrEl6KI/0ERbzlWfygWWK wufvpBSLsMXWJDE7ZuNAJIbHGriCkNqJ8ks3D/3ugWCMUhJB1zN+QVdzuoeymL4RSY +w6a0CUEVZe69hgwP+/j+cKiJ+PG6jhYuBLr2VYjH0zGtbXrE1IsTg9ZC/bGflOy3k adE2VW+9PmGxg== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sun, 27 Apr 2025 17:31:46 +0200 X-ME-IP: 90.112.40.65 Message-ID: <8026961e-c8e6-46ee-9a0d-e4c43ed39ee0@HIDDEN> Date: Sun, 27 Apr 2025 17:31:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN> <1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN> <jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN> <0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN> <jwvwmb6yylb.fsf-monnier+emacs@HIDDEN> <jwv5xiplqbk.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwv5xiplqbk.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-27 14:59, Stefan Monnier wrote: >>> Exactly, I fully agree, the question is "how to keep track of the >>> children"? >> >> You could approximate it with `after-load-functions`. Or, with the >> proposed patch, you could use an advice on `cl--type-deftype`. Once you >> do that, you won't need to break circularity in `cl-types-of`. > > I think what I was trying to say all along is: > the circularity you're trying to break doesn't come from `cl-deftype` or > `cl-types-of` but from your impredicative definition of `T1`. > So it'd be best to fix it there: > > (cl-deftype T1 () > `(satisfies ,(lambda (o) (memq 'T1 (cl-types-of o))))) > > => > > (defvar my-pending-T1-check (make-symbol "void")) > > (cl-deftype T1 () > `(satisfies > ,(lambda (o) > (and (not (eq o my-pending-T1-check)) > (let ((my-pending-T1-check o)) > (memq 'T1 (cl-types-of o))))))) > Hi Stefan, I quite like this approach, where it's not `cl-types-of', but each type that bears responsibility for its implementation. So, if I understand correctly, your recommendation is to not try to solve recursion (or other) problems in `cl-types-of' at all, but rather at the level of each type's definition, and to let ill-defined types possibly cause errors? The only point that still bothers me is not protecting `cl-types-of' from errors due to ill-defined types. This is particularly true because this can impact the entire Emacs session if certain methods are prevented from working, such as those involved in the display process (I use such methods based on `cl-deftype' for example, in my own alternative implementation of icons and tab-line). If you agree I will update cl-types.el accordingly and dispatch it in the existing libraries according to your previous proposal... to see what happens ;-) Thanks again for being so helpful! David
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 27 Apr 2025 12:59:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 27 08:59:36 2025
Received: from localhost ([127.0.0.1]:40307 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u91bb-00036e-Rk
for submit <at> debbugs.gnu.org; Sun, 27 Apr 2025 08:59:36 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7253)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u91bY-00035R-4l
for 77725 <at> debbugs.gnu.org; Sun, 27 Apr 2025 08:59:33 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 336348086D;
Sun, 27 Apr 2025 08:59:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745758765;
bh=U5gT6UNmPJUexJkGPJ7ImJA2vnhpWp8NQlZK8VIr5BY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=FJHFS8JOkMjXllJzUogV9vA0ee5+KJ5eWVyZV7tEy9839Gd2mnknXI4JQ7l5KfChp
dX5/JPLZcZYqhbPHIltbiQ441+/fgwcaGXflCjxb7w6nXzeXdk4UGt+mIih81zeG5Q
9DauGPbtrmOAlJC4YdKGwRu/nHbk0EjYn/CQp5f/BTcu9pwdWaCZsB4PDdeNMuaB4Y
GWzL5SqYSekMVNwLZ1+Js/B7YkAx+EIw1wNPgovZ/IJeL4e8M0NEJwlH5rgnlCH59P
ISlvz1Ei5lCjlbEEQD/mx1wB0S3IZfw1++PnWwJDVeDMpSuDW+zbARPD+4P1Tlaozp
SRKUhsRWLLeaQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 548618089D;
Sun, 27 Apr 2025 08:59:25 -0400 (EDT)
Received: from alfajor (104-195-232-56.cpe.teksavvy.com [104.195.232.56])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 21EF212049E;
Sun, 27 Apr 2025 08:59:25 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwv5xiplqbk.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
<jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
Date: Sun, 27 Apr 2025 08:59:24 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.064 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> Exactly, I fully agree, the question is "how to keep track of the
>> children"?
>
> You could approximate it with `after-load-functions`. Or, with the
> proposed patch, you could use an advice on `cl--type-deftype`. Once you
> do that, you won't need to break circularity in `cl-types-of`.
I think what I was trying to say all along is:
the circularity you're trying to break doesn't come from `cl-deftype` or
`cl-types-of` but from your impredicative definition of `T1`.
So it'd be best to fix it there:
(cl-deftype T1 ()
`(satisfies ,(lambda (o) (memq 'T1 (cl-types-of o)))))
=>
(defvar my-pending-T1-check (make-symbol "void"))
(cl-deftype T1 ()
`(satisfies
,(lambda (o)
(and (not (eq o my-pending-T1-check))
(let ((my-pending-T1-check o))
(memq 'T1 (cl-types-of o)))))))
- Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 27 Apr 2025 05:55:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 27 01:55:09 2025
Received: from localhost ([127.0.0.1]:38129 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8uyq-0006rB-Lc
for submit <at> debbugs.gnu.org; Sun, 27 Apr 2025 01:55:09 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39902)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u8uyn-0006mE-0o
for 77725 <at> debbugs.gnu.org; Sun, 27 Apr 2025 01:55:05 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A9644440910;
Sun, 27 Apr 2025 01:54:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745733296;
bh=3Ju6BTYEXlSeSjQpIKcGXfSiH5rS51Azo1bfSatsTBs=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=jdXcecUaNSwkyYshBYVk4wIv4TrRHoganBi7eAd5Ty37mJCYrp+i5YPAJv+2eXIqe
Mt0thvssUP+gloMlob30FVpyHZct258NZK6PoOkQYH6Opdpguo2aDoaEXFnnzBs+cG
VH6x5iCyW6Cqpc5BrIaMA1qmPBIvO+Otd+kMEQ3ieAsBakfko2lHE/gNJ26HnhnmtD
y9ofk+UREi70p0HD1GwxJ907lhZ4pwnXl4UlVQDd+6o8GQ84AxaCfKyZ98tUXfMPQD
ycB7ozzrO/XN3QpF3htAMKClSzzcoeShwIT89XdBRkkBG0qlGA8RAQL8hhU69UO+LX
tQN9Yozkw+RUA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1E57544046A;
Sun, 27 Apr 2025 01:54:56 -0400 (EDT)
Received: from alfajor (104-195-232-56.cpe.teksavvy.com [104.195.232.56])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DDB3F1201F3;
Sun, 27 Apr 2025 01:54:55 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
Message-ID: <jwvwmb6yylb.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
<jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
<0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN>
Date: Sun, 27 Apr 2025 01:54:55 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.018 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Exactly, I fully agree, the question is "how to keep track of the
> children"?
You could approximate it with `after-load-functions`. Or, with the
proposed patch, you could use an advice on `cl--type-deftype`. Once you
do that, you won't need to break circularity in `cl-types-of`.
> I wonder if it would be possible to do something when the type is
> (re)defined? For example, pass the type once defined to some kind of
> "after-defined-hook" that could adjust the environment accordingly.
Maybe more generally we could/should provide "fast" (i.e. cached)
versions of `cl--class-allparents` and `cl--class-children`.
[ And remove those `--`. ]
>>> This makes me think that errors that might occur when calling
>>> `cl-typep' should be handled in `cl-types-of' to prevent an
>>> incorrect definition from impacting method dispatching on types
>>> correctly defined.
>>> WDYT?
>> Maybe. I'd tend to think that `cl-typep` should never error, so if
>> it ever does (which would indicate a bug in some `cl-deftype`), we
>> wouldn't want to hide that error.
> Unfortunately, currently `cl-typep' can error, but currently the
> impact is limited to the broken definition. Here is an example of
> broken definition:
>
> (cl-deftype bad-type ()
> '(satisfies unknown-function))
But this is bug in the definition of the type.
> But, when any type defined by 'cl-deftype' can also be a method type
> argument, any broken type can also break dispatching of method for
> other types. So, such errors need to be caught and reported by
> `cl-types-of'. For now, I updated `cl-types-of' accordingly.
You could also take the position that we shouldn't catch those errors
and instead put pressure to fix those broken `cl-deftype` definitions.
> I am afraid, I still don't see how I can implement this "common
> approach" to break circularity.
I think it would look something like:
(defvar cl--type-pending nil)
(defun cl--typep (o type)
;; Like `cl-typep` but with recursion-check.
(let ((entry (cons o type)))
;; Note: `member` is not quite right.
(if (member entry cl--type-pending)
;; We're called recursively while in the process of testing
;; if `o` is of type `type`, so presume it's true for now,
;; rather than inf-loop.
t
(let ((cl--type-pending (cons cl--type-pending)))
(cl-typep o type)))))
(defun cl-types-of (o)
(let ((types ()))
(dolist (type ...alltypes...)
(when (cl--typep o type)
(push type types))))))
...types...))
> When I consider that a type "match" before to check, it will still
> match after a cycle is detected, if I understood correctly your
> explanation. So, a circular type will always match for any objet?
If the type is "trivially circular", yes. Otherwise, not necessarily.
E.g.
(cl-deftype is-cons (t1 t2)
`(and cons (satisfies
,(lambda (x)
(and (cl--typep (car x) t1) (cl--typep (car x) t2))))))
(cl-deftype list-of-int ()
`(is-cons integer (or null list-of-int)))
and then
(let ((x (list 1 2 3 4 5)))
(setcdr (last x) x)
(cl--typep x 'list-of-int))
would terminate and return t but
(let ((x (list "1" "2" "3" "4" "5")))
(setcdr (last x) x)
(cl--typep x 'list-of-int))
would return nil.
> Please find attached a new simpler and cleaner version of
> cl-types-test.el. All tests pass for me :-)
Looks good, thanks.
> Also attached my last version of cl-types.el. For now, I prefer to
> work on separate files. Based on your previous proposal, it should
> not be difficult to merge the code in existing libraries when/if we
> are satisfied of the implementation ;-)
It would be good to check that the split I proposed works correctly, tho.
The main issues are likely to be around whether things are autoloaded
when they to.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 26 Apr 2025 09:50:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 26 05:50:41 2025 Received: from localhost ([127.0.0.1]:58283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u8cBF-00040o-76 for submit <at> debbugs.gnu.org; Sat, 26 Apr 2025 05:50:41 -0400 Received: from smtp-22.smtpout.orange.fr ([80.12.242.22]:41359 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u8cBD-00040d-7q for 77725 <at> debbugs.gnu.org; Sat, 26 Apr 2025 05:50:39 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 8cB6u4lV520Vo8cB9u443m; Sat, 26 Apr 2025 11:50:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745661037; bh=NfItWs6JcX20stFu62H/Bljazp2txX4pRZ5p1gFaFKA=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=i0EvV0yxTf7Wo/4RwntQQt2BbAt5bzmCyOWlv0mT82ps2NQ0yt1YPvv7f+udOvIwH Isc+YSmrrQhIAo+vT0unV415mHTnQAoNhfOx6joUFGrmaMiSvgvc8kl6cLzUu5o2gZ 3taPbSINyiL3moucO7/2+sBdsnOjjadLBt13qkmpUJXvhoLhrraic3Yc8YF+olDH5V Mtpgpnt+so513Gxgk0KghVPlzkpe9Kr9Ww1i3B9akQrk/+aOPPjebOUtZW9w0nh3qd v71i/4iILIuo8v/bYZeY9GGW+Tfb+yXAvXFY4KutuF9vq62E3A11KYTubbQu/ilyHh SFUpB6Uzt88Cg== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sat, 26 Apr 2025 11:50:37 +0200 X-ME-IP: 90.112.40.65 Message-ID: <daf6e3c9-a6f9-4ced-b859-8774f467f176@HIDDEN> Date: Sat, 26 Apr 2025 11:50:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN> <jwv7c38avsu.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwv7c38avsu.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-25 21:37, Stefan Monnier wrote: > [ Just tooting my horn, nothing to see. ] > >>> Here is a test case with a recursion: >>> >>> (cl-deftype T1 () >>> "Root type. >>> Check if passed object is a subtype of T1. I.e., if T1 is present in >>> object type parents." >>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o))))) >> >> Hmm... I can see that it could be handy if you don't know how to >> characterize type T1 other than as the "sum" of its subtypes. >> But this seems rather circular. Have you seen such things out in >> the wild? > > BTW, this form of circularity is called an *impredicative* definition: > the above definition does not directly refer to T1 (as in the case of > a recursive definition), instead it refers (via the definition of > `gtypes-of`) to the set of all types, to which T1 happens to belong. > > As it happens, the notion of *type* was invented/introduced by Bertrand > Russel (early 20th century) specifically in order to try and disallow > the kind of paradoxes (like Russel's paradox or the paradox of the > barber) that impredicativity makes possible. > > OK, you can go back to your regularly scheduled ELisp hacking now, Thank you! I always appreciate enriching my knowledge :-)
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 26 Apr 2025 09:48:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 26 05:48:07 2025 Received: from localhost ([127.0.0.1]:58274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u8c8j-0003px-Jd for submit <at> debbugs.gnu.org; Sat, 26 Apr 2025 05:48:06 -0400 Received: from smtp-25.smtpout.orange.fr ([80.12.242.25]:47525 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u8c8e-0003pH-6T for 77725 <at> debbugs.gnu.org; Sat, 26 Apr 2025 05:48:02 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 8c8WueSn8Aix78c8ZuYvjs; Sat, 26 Apr 2025 11:47:58 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745660878; bh=V4kIuvtBS3RAGzTxpUxKHiXWeSISP9w6TBYOz0dL6II=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=FlKt3lDzVot0DQpxiMR6AGrOIxkAB1tOQS/BX2PukzPTCJo/j48gRJxTfrWXgIL9k F9qw3xidD5GWaCv6hueHC+VgiLidrFj/aLIoGwUfG+PAHBzgCEpijmdk7aLp9frYtC TloKvQZ5YUEnnxT2t5Jt82GwaRAtmH2/VUqDGlp9vKcKuoMuwFw5J0hUNG20MQocM8 vHsNZAWrTqNFoLorsVgzpeDLfFJHpTQA8nwbDuNqOsucREocusO5FzDVYPIzkx7Fp/ Vt5lKmpeImzRikiRYpsUhkQCbHw0/dBO+W6GOa8FHwtdFpAfoOjmBftVMMtlVMD63e fvhMQvqW8mX0Q== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sat, 26 Apr 2025 11:47:58 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------f9Pq14eM3v8f6UAXZV4u0vT5" Message-ID: <0a0dc14d-ab88-4707-9998-2dae0898fb17@HIDDEN> Date: Sat, 26 Apr 2025 11:47:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN> <1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN> <jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------f9Pq14eM3v8f6UAXZV4u0vT5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2025-04-25 20:07, Stefan Monnier wrote: >>>> (cl-deftype T1 () >>>> "Root type. >>>> Check if passed object is a subtype of T1. I.e., if T1 is present in >>>> object type parents." >>>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o))))) >>> Hmm... I can see that it could be handy if you don't know how to >>> characterize type T1 other than as the "sum" of its subtypes. >>> But this seems rather circular. Have you seen such things out in >>> the wild? >> I am using a such "abstract" type in one of my library for exactly >> this: "characterize type T1 other than as the "sum" of its subtypes." > > [ FWIW, this definition makes your type-test quite costly since it will > test more or less each and every type defined with `cl-deftype`. > You'd be better served with a more targeted test which keeps track of > the children of T1 so it can then do something like > > (cl-some (lambda (child) (cl-typep o child)) my-children) > > This way the performance is not affected by random other unrelated types. > > But, yes, that begs the question of how to keep track of the > children, e.g. how to be told when a child needs to be added/removed > to/from `my-children`. ] Exactly, I fully agree, the question is "how to keep track of the children"? I wonder if it would be possible to do something when the type is (re)defined? For example, pass the type once defined to some kind of "after-defined-hook" that could adjust the environment accordingly. >>> More importantly, with your circularity-breaking approach, if `gtype-of` >>> (aka `cl-types-of`) happens to look at T1 first, that check will >>> immediately return nil, so `cl-types-of` may decide "Oh, I just >>> discovered this is not a T1, so I can skip checking all the subtypes of >>> T1". So, the cycle is broken, but the output is wrong. >> >> Look at T1 first should be possible only if T1 is alone, without any > [...] > > Agreed. > >> Did I miss something? > > What you missed (because I didn't make it clear) is that I was talking > about an incorrect behavior of your circularity-breaking approach, when > coupled with *another* algorithm than the one you currently use to > collect the set of types to return in `cl-types-of`. Ah, OK, I better understand your point. Thanks! > >> This makes me think that errors that might occur when calling >> `cl-typep' should be handled in `cl-types-of' to prevent an >> incorrect definition from impacting method dispatching on types >> correctly defined. >> WDYT? > > Maybe. I'd tend to think that `cl-typep` should never error, so if it > ever does (which would indicate a bug in some `cl-deftype`), we wouldn't > want to hide that error. Unfortunately, currently `cl-typep' can error, but currently the impact is limited to the broken definition. Here is an example of broken definition: (cl-deftype bad-type () '(satisfies unknown-function)) But, when any type defined by 'cl-deftype' can also be a method type argument, any broken type can also break dispatching of method for other types. So, such errors need to be caught and reported by `cl-types-of'. For now, I updated `cl-types-of' accordingly. > >>>> ;; T2 will never match, because `cl-types-of' enters in an endless recursion >>>> (cl-typep (list 'T2) 'T1) >>>> => nil >>> This is both right and wrong: we could return t and that would be >>> equally valid. >>> >>>> (cl-types-of (list 'T2)) >>>> => (cons list sequence t) >>> And here (T2 T1 cons list sequence t) would also be equally valid. >> >> Sorry, you lost me here. As I understand it, a type whose definition >> enter in an endless recursion is not valid, and should never match? > > It depends on whether you define your types inductively or co-inductively. > IOW, do you define the type by starting with the "empty set" and then > adding new elements to it until there's nothing more to add, or do you > define it by starting with a "total set" that contains everything and > then remove elements from it until you've removed everything that > doesn't belong there. > > Another way to look at it: there's nothing in your definition of T2 that > says that the list `(T2)` should *not* be an element of that type. > > For recursive values, in order to break circularity, it is common to > check whether a value satisfies a constraint by adding "yes it does" as > a temporary assumption while performing the check, so as to break the > cycle when we get to a nested occurrence of that object. > If we use the same approach here, the T2 test will say that `(T2)` is > indeed of type T2. > I am afraid, I still don't see how I can implement this "common approach" to break circularity. When I consider that a type "match" before to check, it will still match after a cycle is detected, if I understood correctly your explanation. So, a circular type will always match for any objet? I certainly missed something, sorry. [...] >> >> The problem with this approach is that it is difficult to isolate and cleanup >> the definitions needed for test-1 from those needed for test-2. Also the result >> will depends on the order of the cl-deftype for test-1 and test-2, because these >> definitions will be effective outside of test-1 and test-2. >> >> But maybe it's not so important after all. I'll try to reformulate the tests this way. > > In the worst case, you can duplicate the definitions (with different names). Please find attached a new simpler and cleaner version of cl-types-test.el. All tests pass for me :-) Also attached my last version of cl-types.el. For now, I prefer to work on separate files. Based on your previous proposal, it should not be difficult to merge the code in existing libraries when/if we are satisfied of the implementation ;-) David --------------f9Pq14eM3v8f6UAXZV4u0vT5 Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types-tests.el" Content-Disposition: attachment; filename="cl-types-tests.el" Content-Transfer-Encoding: base64 Ozs7IFRlc3QgYGNsLXR5cGVkZWYnIC0qLSBsZXhpY2FsLWJpbmRpbmc6IHQ7IC0qLQo7Owoo cmVxdWlyZSAnZXJ0KQoocmVxdWlyZSAnY2wtdHlwZXMpCgooY2wtZGVmdHlwZTIgbXVsdGlw bGVzLW9mICgmb3B0aW9uYWwgbSkKICAobGV0ICgobXVsdGlwbGVwIChpZiAoZXEgbSAnKikK ICAgICAgICAgICAgICAgICAgICAgICAjJ2lnbm9yZQoJCSAgICAgKGxhbWJkYSAobikgKD0g MCAoJSBuIG0pKSkpKSkKICAgIGAoYW5kIGludGVnZXIgKHNhdGlzZmllcyAsbXVsdGlwbGVw KSkpKQogICAgIAooY2wtZGVmdHlwZTIgbXVsdGlwbGVzLW9mLTIgKCkKICAnKG11bHRpcGxl cy1vZiAyKSkKICAgICAKKGNsLWRlZnR5cGUyIG11bHRpcGxlcy1vZi0zICgpCiAgJyhtdWx0 aXBsZXMtb2YgMykpCiAgICAgCihjbC1kZWZ0eXBlMiBtdWx0aXBsZXMtb2YtNCAoKQogIChk ZWNsYXJlIChwYXJlbnRzIG11bHRpcGxlcy1vZi0yKSkKICAnKGFuZCBtdWx0aXBsZXMtb2Yt MiAobXVsdGlwbGVzLW9mIDQpKSkKCihjbC1kZWZ0eXBlMiB1bnNpZ25lZC1ieXRlICgmb3B0 aW9uYWwgYml0cykKICAiVW5zaWduZWQgaW50ZWdlci4iCiAgYChpbnRlZ2VyIDAgLChpZiAo ZXEgYml0cyAnKikgYml0cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQogICAgIAooY2wtZGVmdHlw ZTIgdW5zaWduZWQtMTZiaXRzICgpCiAgIlVuc2lnbmVkIDE2LWJpdHMgaW50ZWdlci4iCiAg KGRlY2xhcmUgKHBhcmVudHMgdW5zaWduZWQtYnl0ZSkpCiAgJyh1bnNpZ25lZC1ieXRlIDE2 KSkKICAgICAKKGNsLWRlZnR5cGUyIHVuc2lnbmVkLThiaXRzICgpCiAgIlVuc2lnbmVkIDgt Yml0cyBpbnRlZ2VyLiIKICAoZGVjbGFyZSAocGFyZW50cyB1bnNpZ25lZC0xNmJpdHMpKQog ICcodW5zaWduZWQtYnl0ZSA4KSkKICAgICAKKGNsLWRlZm1ldGhvZCBteS1mb28gKChfbiB1 bnNpZ25lZC1ieXRlKSkKICAoZm9ybWF0ICJ1bnNpZ25lZCIpKQogICAgIAooY2wtZGVmbWV0 aG9kIG15LWZvbyAoKF9uIHVuc2lnbmVkLTE2Yml0cykpCiAgKGZvcm1hdCAidW5zaWduZWQg MTZiaXRzIC0gYWxzbyAlcyIKICAgICAgICAgIChjbC1jYWxsLW5leHQtbWV0aG9kKSkpCiAg ICAgCihjbC1kZWZtZXRob2QgbXktZm9vICgoX24gdW5zaWduZWQtOGJpdHMpKQogIChmb3Jt YXQgInVuc2lnbmVkIDhiaXRzIC0gYWxzbyAlcyIKICAgICAgICAgIChjbC1jYWxsLW5leHQt bWV0aG9kKSkpCgooZXJ0LWRlZnRlc3QgY2wtdHlwZXMtdGVzdCAoKQogICJUZXN0IHR5cGVz IGRlZmluaXRpb24sIGNsLXR5cGVzLW9mIGFuZCBtZXRob2QgZGlzcGF0Y2hpbmcuIgoKICA7 OyBJbnZhbGlkIERBRyBlcnJvcgogIChzaG91bGQtZXJyb3IKICAgKGV2YWwKICAgICcoY2wt ZGVmdHlwZTIgdW5zaWduZWQtMTZiaXRzICgpCiAgICAgICAiVW5zaWduZWQgMTYtYml0cyBp bnRlZ2VyLiIKICAgICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2lnbmVkLThiaXRzKSkKICAg ICAgICcodW5zaWduZWQtYnl0ZSAxNikpCiAgICBsZXhpY2FsLWJpbmRpbmcKICAgICkpCgog IDs7IFRlc3QgdGhhdCAoY2wtdHlwZXMtb2YgNCkgaXMgKG11bHRpcGxlcy1vZi00IG11bHRp cGxlcy1vZi0yIC4uLikKICA7OyBUZXN0IHRoYXQgKGNsLXR5cGVzLW9mIDYpIGlzIChtdWx0 aXBsZXMtb2YtMyBtdWx0aXBsZXMtb2YtMiAuLi4pCiAgOzsgVGVzdCB0aGF0IChjbC10eXBl cy1vZiAxMikgaXMgKG11bHRpcGxlcy1vZi00IG11bHRpcGxlcy1vZi0zIG11bHRpcGxlcy1v Zi0yIC4uLikKICAobGV0ICgodHlwZXMgJyhtdWx0aXBsZXMtb2YtMiBtdWx0aXBsZXMtb2Yt MyBtdWx0aXBsZXMtb2YtNCkpKQogICAgKHNob3VsZCAoZXF1YWwgJyhtdWx0aXBsZXMtb2Yt MikKCQkgICAoc2VxLWludGVyc2VjdGlvbiAoY2wtdHlwZXMtb2YgMikgdHlwZXMpKSkKCiAg ICAoc2hvdWxkIChlcXVhbCAnKG11bHRpcGxlcy1vZi00IG11bHRpcGxlcy1vZi0yKQoJCSAg IChzZXEtaW50ZXJzZWN0aW9uIChjbC10eXBlcy1vZiA0KSB0eXBlcykpKQoKICAgIChzaG91 bGQgKGVxdWFsICcobXVsdGlwbGVzLW9mLTMgbXVsdGlwbGVzLW9mLTIpCgkJICAgKHNlcS1p bnRlcnNlY3Rpb24gKGNsLXR5cGVzLW9mIDYpIHR5cGVzKSkpCgogICAgKHNob3VsZCAoZXF1 YWwgJyhtdWx0aXBsZXMtb2YtMyBtdWx0aXBsZXMtb2YtNCBtdWx0aXBsZXMtb2YtMikKCQkg ICAoc2VxLWludGVyc2VjdGlvbiAoY2wtdHlwZXMtb2YgMTIpIHR5cGVzKSkpCiAgICAKICAg IChzaG91bGQgKGVxdWFsICcoKQoJCSAgIChzZXEtaW50ZXJzZWN0aW9uIChjbC10eXBlcy1v ZiA1KSB0eXBlcykpKQogICAgKQogIAogIDs7OyBNZXRob2QgZGlzcGF0Y2hpbmcuCiAgKHNo b3VsZCAoZXF1YWwgInVuc2lnbmVkIDhiaXRzIC0gYWxzbyB1bnNpZ25lZCAxNmJpdHMgLSBh bHNvIHVuc2lnbmVkIgoJCSAobXktZm9vIDEwMCkpKQoKICAoc2hvdWxkIChlcXVhbCAidW5z aWduZWQgMTZiaXRzIC0gYWxzbyB1bnNpZ25lZCIKCQkgKG15LWZvbyAyNTYpKSkKCiAgKHNo b3VsZCAoZXF1YWwgInVuc2lnbmVkIgoJCSAobXktZm9vIG1vc3QtcG9zaXRpdmUtZml4bnVt KSkpCiAgKQoKKHByb3ZpZGUgJ2NsLXR5cGVzLXRlc3RzKQoKOzs7IGNsLXR5cGVzLXRlc3Rz LmVsIGVuZHMgaGVyZQo= --------------f9Pq14eM3v8f6UAXZV4u0vT5 Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el" Content-Disposition: attachment; filename="cl-types.el" Content-Transfer-Encoding: base64 OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBEYXRhIHR5cGVzIGRlZmluZWQg YnkgYGNsLWRlZnR5cGUnIGFyZSBub3cgcmVjb2duaXplZCBhcyBhcmd1bWVudAo7OyB0eXBl cyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbnMgbWV0aG9kcy4KCjs7IFdpbGwg YmUgcmVtb3ZlZCB3aGVuIGluY2x1ZGVkIGluIGNsLWxpYi4KKHJlcXVpcmUgJ2NsLWxpYikK KGV2YWwtd2hlbi1jb21waWxlIChyZXF1aXJlICdjbC1tYWNzKSkgIDtGb3IgY2wtLWZpbmQt Y2xhc3MuCgo7OyBFeHRlbmQgYGNsLWRlZnR5cGUnIHRvIGRlZmluZSBkYXRhIHR5cGVzIHdo aWNoIGFyZSBhbHNvIHZhbGlkCjs7IGFyZ3VtZW50IHR5cGVzIGZvciBkaXNwYXRjaGluZyBn ZW5lcmljIGZ1bmN0aW9uIG1ldGhvZHMgKHNlZSBhbHNvCjs7IDxodHRwczovL2RlYmJ1Z3Mu Z251Lm9yZy9jZ2kvYnVncmVwb3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4g ZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgY2wtZGVmdHlwZScsIHRoYXQgZGVmaW5lcyBu ZXcgZGF0YSB0eXBlcy4KOzsKOzsgLSBgY2wtdHlwZXMtb2YnLCB0aGF0IHJldHVybnMgdGhl IHR5cGVzIGFuIG9iamVjdCBiZWxvbmdzIHRvLgoKKGRlZnZhciBjbC0tdHlwZS1saXN0IG5p bAogICJMaXN0IG9mIGRlZmluZWQgdHlwZXMgdG8gbG9va3VwIGZvciBtZXRob2QgZGlzcGF0 Y2hpbmcuIikKCjs7IEZJWE1FOiBUaGUgYGNsLWRlZnR5cGUtaGFuZGxlcicgcHJvcGVydHkg c2hvdWxkIGFyZ3VhYmx5IGJlIHR1cm5lZAo7OyBpbnRvIGEgZmllbGQgb2YgdGhpcyBzdHJ1 Y3QgKGJ1dCBpdCBoYXMgcGVyZm9ybWFuY2UgYW5kCjs7IGNvbXBhdGliaWxpdHkgaW1wbGlj YXRpb25zLCBzbyBsZXQncyBub3QgbWFrZSB0aGF0IGNoYW5nZSBmb3Igbm93KS4KKGNsLWRl ZnN0cnVjdAogICAgKGNsLXR5cGUtY2xhc3MKICAgICAoOmluY2x1ZGUgY2wtLWNsYXNzKQog ICAgICg6bm9pbmxpbmUgdCkKICAgICAoOmNvbnN0cnVjdG9yIG5pbCkKICAgICAoOmNvbnN0 cnVjdG9yIGNsLS10eXBlLWNsYXNzLW1ha2UKICAgICAgICAgICAgICAgICAgIChuYW1lCiAg ICAgICAgICAgICAgICAgICAgZG9jc3RyaW5nCiAgICAgICAgICAgICAgICAgICAgcGFyZW50 LXR5cGVzCiAgICAgICAgICAgICAgICAgICAgJmF1eCAocGFyZW50cwogICAgICAgICAgICAg ICAgICAgICAgICAgIChtYXBjYXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJk YSAodHlwZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAob3IgKGNsLS1maW5kLWNs YXNzIHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcnJvciAiVW5r bm93biB0eXBlOiAlUyIgdHlwZSkpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJl bnQtdHlwZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBm b3IgdHlwZXMgZGVmaW5lZCBieSBgY2wtZGVmdHlwZScuIikKCihkZWZ1biBjbC0tdHlwZS1w IChvYmplY3QpCiAgIlJldHVybiBub24tbmlsIGlmIE9CSkVDVCBpcyBhIHVzZWQgZGVmaW5l ZCB0eXBlLgpUaGF0IGlzLCBhIHR5cGUgb2YgY2xhc3MgYGNsLXR5cGUtY2xhc3MnLiIKICAo YW5kIChzeW1ib2xwIG9iamVjdCkgKGNsLXR5cGUtY2xhc3MtcCAoY2wtLWZpbmQtY2xhc3Mg b2JqZWN0KSkpKQoKKGRlZm1hY3JvIGNsLS10eXBlLXBhcmVudHMgKG5hbWUpCiAgIkdldCBw YXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2VudGlu ZyBhIHR5cGUuIgogIGAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNzICxu YW1lKSkpCgooZGVmdW4gY2wtLXR5cGUtY2hpbGRyZW4gKG5hbWUpCiAgIkdldCBjaGlsZHJl biBvZiB0aGUgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5n IGEgdHlwZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAgKGNs LWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXApKQogIChsZXQgKGNoaWxk cmVuKQogICAgKGRvbGlzdCAoZWx0IGNsLS10eXBlLWxpc3QpCiAgICAgIChvciAoZXEgbmFt ZSBlbHQpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSAoY2wtLXR5cGUtcGFyZW50cyBlbHQp KQogICAgICAgICAgICAgIChwdXNoIGVsdCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVuKSkK CihkZWZ1biBjbC0tdHlwZS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZyb20gdGhlIGxpc3Qg b2YgZGVmaW5lZCB0eXBlcy4iCiAgKG1hcGNhciAobGFtYmRhICh0eXBlKSAoY2wtLXR5cGUt cGFyZW50cyB0eXBlKSkgY2wtLXR5cGUtbGlzdCkpCgo7OyBLZWVwIGl0IGZvciBub3csIGZv ciB0ZXN0aW5nLgooZGVmdW4gY2wtLXR5cGUtdW5kZWZpbmUgKG5hbWUpCiAgIlJlbW92ZSB0 aGUgZGVmaW5pdGlvbnMgb2YgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYW4gdW5xdW90ZWQg c3ltYm9sIHJlcHJlc2VudGluZyBhIHR5cGUuClNpZ25hbCBhbiBlcnJvciBpZiBvdGhlciB0 eXBlcyBpbmhlcml0IGZyb20gTkFNRS4iCiAgKGRlY2xhcmUtZnVuY3Rpb24gY2wtcmVtcHJv cCAiY2wtZXh0cmEiIChzeW1ib2wgcHJvcG5hbWUpKQogIChjbC1jaGVjay10eXBlIG5hbWUg KHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAod2hlbi1sZXQqICgoY2hpbGRyZW4gKGFuZCAo Y2wtLXR5cGUtcCBuYW1lKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC0tdHlw ZS1jaGlsZHJlbiBuYW1lKSkpKQogICAgKGVycm9yICJUeXBlIGhhcyBjaGlsZHJlbjogJVMi IGNoaWxkcmVuKSkKICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXBy b3AgbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVyKQogIChzZXRxIGNsLS10eXBlLWxpc3QgKGRl bHEgbmFtZSBjbC0tdHlwZS1saXN0KSkpCgooZGVmdW4gY2wtLXR5cGUtZGVmdHlwZSAobmFt ZSBwYXJlbnRzICZvcHRpb25hbCBkb2NzdHJpbmcpCiAgIkdlbmVyYWxpemUgdHlwZSB3aXRo IE5BTUUgZm9yIG1ldGhvZCBkaXNwYXRjaGluZy4KUEFSRU5UUyBpcyBhIGxpc3Qgb2YgdHlw ZXMgTkFNRSBpcyBhIHN1YnR5cGUgb2YsIG9yIG5pbC4KRE9DU1RSSU5HIGlzIGFuIG9wdGlv bmFsIGRvY3VtZW50YXRpb24gc3RyaW5nLiIKICAobGV0ICgob2xkdGxpc3QgKGNvcHktc2Vx dWVuY2UgY2wtLXR5cGUtbGlzdCkpCiAgICAgICAgKG9sZHBsaXN0IChjb3B5LXNlcXVlbmNl IChzeW1ib2wtcGxpc3QgbmFtZSkpKSkKICAgIChjb25kaXRpb24tY2FzZSBlcnIKICAgICAg ICAobGV0KiAoKGNsYXNzIChjbC0tZmluZC1jbGFzcyBuYW1lKSkKICAgICAgICAgICAgICAg KHJlY29yZGVkIChtZW1xIG5hbWUgY2wtLXR5cGUtbGlzdCkpKQogICAgICAgICAgKGlmIChu dWxsIGNsYXNzKQogICAgICAgICAgICAgIChvciAobnVsbCByZWNvcmRlZCkKICAgICAgICAg ICAgICAgICAgKGVycm9yICJUeXBlIGdlbmVyYWxpemVkLCBidXQgZG9lc24ndCBleGlzdCIp KQogICAgICAgICAgICAob3IgcmVjb3JkZWQgKGVycm9yICJUeXBlIGV4aXN0cywgYnV0IG5v dCBnZW5lcmFsaXplZCIpKQogICAgICAgICAgICAob3IgKGNsLXR5cGUtY2xhc3MtcCBjbGFz cykKICAgICAgICAgICAgICAgIChlcnJvciAiVHlwZSBpbiBhbm90aGVyIGNsYXNzOiAlUyIg KHR5cGUtb2YgY2xhc3MpKSkpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSBwYXJlbnRzKQog ICAgICAgICAgICAgIChlcnJvciAiVHlwZSBpbiBwYXJlbnRzOiAlUyIgcGFyZW50cykpCiAg ICAgICAgICA7OyBTZXR1cCBhIHR5cGUgZGVzY3JpcHRvciBmb3IgTkFNRS4KICAgICAgICAg IChzZXRmIChjbC0tZmluZC1jbGFzcyBuYW1lKQogICAgICAgICAgICAgICAgKGNsLS10eXBl LWNsYXNzLW1ha2UgbmFtZSBkb2NzdHJpbmcgcGFyZW50cykpCiAgICAgICAgICA7OyBSZWNv cmQgbmV3IHR5cGUgbm93IHRvIGluY2x1ZGUgaXRzIGRlcGVuZGVuY3kgaW4gdGhlIERBRy4K ICAgICAgICAgIChvciByZWNvcmRlZCAocHVzaCBuYW1lIGNsLS10eXBlLWxpc3QpKQogICAg ICAgICAgOzsgYGNsLXR5cGVzLW9mJyBpdGVyYXRlcyB0aHJvdWdoIGFsbCBrbm93biB0eXBl cyB0byBjb2xsZWN0CiAgICAgICAgICA7OyBhbGwgdGhvc2UgYW4gb2JqZWN0IGJlbG9uZ3Mg dG8sIHNvcnRlZCBmcm9tIHRoZSBtb3N0CiAgICAgICAgICA7OyBzcGVjaWZpYyB0eXBlIHRv IHRoZSBtb3JlIGdlbmVyYWwgdHlwZS4gIFNvLCBrZWVwIHRoZQogICAgICAgICAgOzsgZ2xv YmFsIGxpc3QgaW4gdGhpcyBvcmRlci4KICAgICAgICAgIChzZXRxIGNsLS10eXBlLWxpc3QK ICAgICAgICAgICAgICAgIChtZXJnZS1vcmRlcmVkLWxpc3RzCiAgICAgICAgICAgICAgICAg KGNsLS10eXBlLWRhZykKICAgICAgICAgICAgICAgICAobGFtYmRhIChfKSAoZXJyb3IgIklu dmFsaWQgZGVwZW5kZW5jeSBncmFwaCIpKSkpKQogICAgICAoZXJyb3IKICAgICAgIDs7IE9u IGVycm9yIHJlc3RvcmUgcHJldmlvdXMgZGF0YS4KICAgICAgIChzZXRxIGNsLS10eXBlLWxp c3Qgb2xkdGxpc3QpCiAgICAgICAoc2V0ZiAoc3ltYm9sLXBsaXN0IG5hbWUpIG9sZHBsaXN0 KQogICAgICAgKGVycm9yIChmb3JtYXQgIkRlZmluZSAlUyBmYWlsZWQ6ICVzIgogICAgICAg ICAgICAgICAgICAgICAgbmFtZSAoZXJyb3ItbWVzc2FnZS1zdHJpbmcgZXJyKSkpKSkpKQoK Ozs7IyMjYXV0b2xvYWQKKGRlZm1hY3JvIGNsLWRlZnR5cGUyIChuYW1lIGFyZ2xpc3QgJnJl c3QgYm9keSkKICAiRGVmaW5lIE5BTUUgYXMgYSBuZXcgZGF0YSB0eXBlLgpUaGUgdHlwZSBO QU1FIGNhbiB0aGVuIGJlIHVzZWQgaW4gYGNsLXR5cGVjYXNlJywgYGNsLWNoZWNrLXR5cGUn LApldGMuLCBhbmQgYXMgYXJndW1lbnQgdHlwZSBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBm dW5jdGlvbiBtZXRob2RzLgoKQVJHTElTVCBpcyBhIENvbW1vbiBMaXNwIGFyZ3VtZW50IGxp c3Qgb2YgdGhlIHNvcnQgYWNjZXB0ZWQgYnkKYGNsLWRlZm1hY3JvJy4gIEJPRFkgZm9ybXMg YXJlIGV2YWx1YXRlZCBhbmQgc2hvdWxkIHJldHVybiBhIHR5cGUKc3BlY2lmaWVyIHRoYXQg aXMgZXF1aXZhbGVudCB0byB0aGUgdHlwZSAoc2VlIHRoZSBJbmZvIG5vZGUgYChjbCkgVHlw ZQpQcmVkaWNhdGVzJyBpbiB0aGUgR05VIEVtYWNzIENvbW1vbiBMaXNwIEVtdWxhdGlvbiBt YW51YWwpLgoKSWYgdGhlcmUgaXMgYSBgZGVjbGFyZScgZm9ybSBpbiBCT0RZLCB0aGUgc3Bl YyAocGFyZW50cyBQQVJFTlRTKSBpcwpyZWNvZ25pemVkIHRvIHNwZWNpZnkgYSBsaXN0IG9m IHR5cGVzIE5BTUUgaXMgYSBzdWJ0eXBlIG9mLiAgRm9yCmluc3RhbmNlOgoKICAoY2wtZGVm dHlwZTIgdW5zaWduZWQtYnl0ZSAoJm9wdGlvbmFsIGJpdHMpCiAgICBcIlVuc2lnbmVkIGlu dGVnZXIuXCIKICAgIChsaXN0IFxcPSdpbnRlZ2VyIDAgKGlmIChlcSBiaXRzIFxcPScqKSBi aXRzICgxLSAoYXNoIDEgYml0cykpKSkpCgogIChjbC1kZWZ0eXBlMiB1bnNpZ25lZC04Yml0 cyAoKQogICAgXCJVbnNpZ25lZCA4LWJpdHMgaW50ZWdlci5cIgogICAgKGRlY2xhcmUgKHBh cmVudHMgdW5zaWduZWQtYnl0ZSkpCiAgICBcXD0nKHVuc2lnbmVkLWJ5dGUgOCkpCgpUaGUg bGlzdCBvZiBQQVJFTlRTIHR5cGVzIGRldGVybWluZXMgdGhlIG9yZGVyIG9mIG1ldGhvZHMg aW52b2NhdGlvbiwKYW5kIG1pc3NpbmcgUEFSRU5UUyBtYXkgY2F1c2UgaW5jb3JyZWN0IG9y ZGVyaW5nIG9mIG1ldGhvZHMsIHdoaWxlCmV4dHJhbmVvdXMgUEFSRU5UUyBtYXkgY2F1c2Ug dXNlIG9mIGV4dHJhbmVvdXMgbWV0aG9kcy4KCklmIFBBUkVOVFMgaXMgbm9uLW5pbCwgQVJH TElTVCBtdXN0IGJlIG5pbC4iCiAgKGRlY2xhcmUgKGRlYnVnIGNsLWRlZm1hY3JvKSAoZG9j LXN0cmluZyAzKSAoaW5kZW50IDIpKQogIChwY2FzZS1sZXQqCiAgICAgICgoYCgsZGVjbHMg LiAsZm9ybXMpIChtYWNyb2V4cC1wYXJzZS1ib2R5IGJvZHkpKQogICAgICAgKGRvY3N0cmlu ZyAoaWYgKHN0cmluZ3AgKGNhciBkZWNscykpCiAgICAgICAgICAgICAgICAgICAgICAoY2Fy IGRlY2xzKQogICAgICAgICAgICAgICAgICAgIChjYWRyIChhc3NxIDpkb2N1bWVudGF0aW9u IGRlY2xzKSkpKQogICAgICAgKHBhcmVudHMgKGNkciAoYXNzcSAncGFyZW50cyAoY2RyIChh c3NxICdkZWNsYXJlIGRlY2xzKSkpKSkpCiAgICAoYW5kIHBhcmVudHMgYXJnbGlzdAogICAg ICAgICAoZXJyb3IgIlBhcmVudHMgc3BlY2lmaWVkLCBidXQgYXJnbGlzdCBub3QgZW1wdHki KSkKICAgIChpZiBkb2NzdHJpbmcgKHNldHEgZm9ybXMgKGNvbnMgZG9jc3RyaW5nIGZvcm1z KSkpCiAgICBgKGV2YWwtYW5kLWNvbXBpbGUgOztjbC1ldmFsLXdoZW4gKGNvbXBpbGUgbG9h ZCBldmFsKQogICAgICAgKGNsLS10eXBlLWRlZnR5cGUgJyxuYW1lICcscGFyZW50cyAsZG9j c3RyaW5nKQogICAgICAgKGRlZmluZS1zeW1ib2wtcHJvcCAnLG5hbWUgJ2NsLWRlZnR5cGUt aGFuZGxlcgogICAgICAgICAgICAgICAgICAgICAgICAgICAoY2wtZnVuY3Rpb24KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKCZjbC1kZWZzICgnKikgLEBhcmdsaXN0 KQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAsQGZvcm1zKSkpKSkpCgo7OyBJbnRl cm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVuZGxlc3MgcmVjdXJzaW9uIGluICdjbC10eXBl LW9mJy4KKGRlZnZhciBjbC0tdHlwZS1vYmplY3QgKG1ha2Utc3ltYm9sICJ2b2lkIikpCjs7 IEVuc3VyZSBlYWNoIHR5cGUgc2F0aXNmaWVzIGBlcWwnLgooZGVmdmFyIGNsLS10eXBlLXVu aXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVhbCkKICAiUmVjb3JkIGFuIHVuaXF1 ZSB2YWx1ZSBvZiBlYWNoIHR5cGUuIikKCjs7IEZJWE1FOiBgY2wtdHlwZXMtb2YnIENQVSBj b3N0IGlzIHByb3BvcnRpb25hbCB0byB0aGUgbnVtYmVyIG9mIHR5cGVzCjs7IGRlZmluZWQg d2l0aCBgY2wtZGVmdHlwZScsIHNvIHRoZSBtb3JlIHBvcHVsYXIgaXQgZ2V0cywgdGhlIHNs b3dlcgo7OyBpdCBiZWNvbWVzLiAgQW5kIG9mIGNvdXJzZSwgdGhlIGNvc3Qgb2YgZWFjaCB0 eXBlIGNoZWNrIGlzCjs7IHVuYm91bmRlZCwgc28gYSBzaW5nbGUgImV4cGVuc2l2ZSIgdHlw ZSBjYW4gc2xvdyBldmVyeXRoaW5nIGRvd24KOzsgZnVydGhlci4KOzsKOzsgVGhlIHVzdWFs IGRpc3BhdGNoIGlzCjs7Cjs7ICAgKGxhbWJkYSAoYXJnICZyZXN0IGFyZ3MpCjs7ICAgICAo bGV0ICgoZiAoZ2V0aGFzaCAoY2wtdHlwZW9mIGFyZykgcHJlY29tcHV0ZWQtbWV0aG9kcy10 YWJsZSkpKQo7OyAgICAgICAoaWYgZgo7OyAgICAgICAgICAgKGFwcGx5IGYgYXJnIGFyZ3Mp Cjs7ICAgICAgICAgOzsgU2xvdyBjYXNlIHdoZW4gZW5jb3VudGVyaW5nIGEgbmV3IHR5cGUK OzsgICAgICAgICAuLi4pKSkKOzsKOzsgd2hlcmUgb2Z0ZW4gdGhlIG1vc3QgZXhwZW5zaXZl IHBhcnQgaXMgYCZyZXN0JyAod2hpY2ggaGFzIHRvCjs7IGFsbG9jYXRlIGEgbGlzdCBmb3Ig dGhvc2UgcmVtYWluaW5nIGFyZ3VtZW50cyksCjs7Cjs7IFNvIHdlJ3JlIHRhbGtpbmcgYWJv dXQgcmVwbGFjaW5nCjs7Cjs7ICAgJnJlc3QgKyBjbC10eXBlLW9mICsgZ2V0aGFzaCArIGlm ICsgYXBwbHkKOzsKOzsgd2l0aCBhIGZ1bmN0aW9uIHRoYXQgbG9vcHMgb3ZlciBOIHR5cGVz LCBjYWxsaW5nIGBjbC10eXBlcCcgb24gZWFjaAo7OyBvbmUgb2YgdGhlbSAoYGNsLXR5cGVw JyBpdHNlbGYgYmVpbmcgYSByZWN1cnNpdmUgZnVuY3Rpb24gdGhhdAo7OyBiYXNpY2FsbHkg aW50ZXJwcmV0cyB0aGUgdHlwZSBsYW5ndWFnZSkuICBUaGlzIGlzIGdvaW5nIHRvIHNsb3cK OzsgZG93biBkaXNwYXRjaCB2ZXJ5IHNpZ25pZmljYW50bHkgZm9yIHRob3NlIGdlbmVyaWMg ZnVuY3Rpb25zIHRoYXQKOzsgaGF2ZSBhIG1ldGhvZCB0aGF0IGRpc3BhdGNoZXMgb24gYSB1 c2VyIGRlZmluZWQgdHlwZSwgY29tcGFyZWQgdG8KOzsgdGhvc2UgdGhhdCBkb24ndC4KOzsK OzsgQSBwb3NzaWJsZSBmdXJ0aGVyIGltcHJvdmVtZW50Ogo7Owo7OyAtIGJhc2VkIG9uIHRo ZSBQQVJFTlRTIGRlY2xhcmF0aW9uLCBjcmVhdGUgYSBtYXAgZnJvbSBidWlsdGluLXR5cGUK OzsgICB0byB0aGUgc2V0IG9mIGNsLXR5cGVzIHRoYXQgaGF2ZSB0aGF0IGJ1aWx0aW4tdHlw ZSBhbW9uZyB0aGVpcgo7OyAgIHBhcmVudHMuICBUaGF0IHByZXN1bWVzIHNvbWUgUEFSRU5U UyBpbmNsdWRlIHNvbWUgYnVpbHRpbi10eXBlcywKOzsgICBvYnZpb3VzbHkgb3RoZXJ3aXNl IHRoZSBtYXAgd2lsbCBiZSB0cml2aWFsIHdpdGggYWxsIGNsLXR5cGVzCjs7ICAgYXNzb2Np YXRlZCB3aXRoIHRoZSBgdCcgImR1bW15IHBhcmVudCIuICBbIFdlIGNvdWxkIGV2ZW4gZ28g Y3JhenkKOzsgICBhbmQgdHJ5IGFuZCBndWVzcyBQQVJFTlRTIHdoZW4gbm90IHByb3ZpZGVk LCBieSBhbmFseXppbmcgdGhlCjs7ICAgdHlwZSdzIGRlZmluaXRpb24uIF0KOzsKOzsgLSBp biBgY2wtdHlwZXMtb2YnIHN0YXJ0IGJ5IGNhbGxpbmcgYGNsLXR5cGUtb2YnLCB0aGVuIHVz ZSB0aGUgbWFwCjs7ICAgdG8gZmluZCB3aGljaCBjbC10eXBlcyBtYXkgbmVlZCB0byBiZSBj aGVja2VkLgo7OwooZGVmdW4gY2wtdHlwZXMtb2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSB0 eXBlcyBPQkpFQ1QgYmVsb25ncyB0by4KUmV0dXJuIGFuIHVuaXF1ZSBsaXN0IG9mIHR5cGVz IE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCm1vc3Qgc3BlY2lmaWMgdHlw ZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIKICA7OyBJZ25vcmUgcmVjdXJzaXZlIGNhbGwgb24g dGhlIHNhbWUgT0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5CiAgOzsgb2NjdXIgd2hl biBhIHBhcmVudCB0eXBlIGlzIGNoZWNraW5nIHdoZXRoZXIgYW4gb2JqZWN0J3MgdHlwZSBp cwogIDs7IHRoYXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJlbi4KICAodW5sZXNzIChlcSBvYmpl Y3QgY2wtLXR5cGUtb2JqZWN0KQogICAgKGxldCAoKGNsLS10eXBlLW9iamVjdCBvYmplY3Qp CiAgICAgICAgICAoZm91bmQgKGxpc3QgKGNsLS10eXBlLXBhcmVudHMgKGNsLXR5cGUtb2Yg b2JqZWN0KSkpKSkKICAgICAgOzsgQnVpbGQgYSBEQUcgb2YgYWxsIHR5cGVzIE9CSkVDVCBi ZWxvbmdzIHRvLgogICAgICAoZG9saXN0ICh0eXBlIGNsLS10eXBlLWxpc3QpCiAgICAgICAg OzsgU2tpcCB0eXBlcyB0aGF0IHByb2R1Y2UgYW4gZXJyb3IuCiAgICAgICAgKGNvbmRpdGlv bi1jYXNlIGVycgogICAgICAgICAgICAoYW5kCiAgICAgICAgICAgICA7OyBTa2lwIHR5cGUg bm90IGRlZmluZWQgYnkgYGNsLWRlZnR5cGUnLgogICAgICAgICAgICAgKGNsLXR5cGUtY2xh c3MtcCAoY2wtLWZpbmQtY2xhc3MgdHlwZSkpCiAgICAgICAgICAgICA7OyBJZiBCQVIgaXMg ZGVjbGFyZWQgYXMgYSBwYXJlbnQgb2YgRk9PIGFuZAogICAgICAgICAgICAgOzsgYGNsLXR5 cGVzLW9mJyBoYXMgYWxyZWFkeSBkZWNpZGVkIHRoYXQgdGhlIHZhbHVlIGlzIG9mCiAgICAg ICAgICAgICA7OyB0eXBlIEZPTywgdGhlbiB3ZSBhbHJlYWR5IGtub3cgQkFSIHdpbGwgYmUg aW4gdGhlCiAgICAgICAgICAgICA7OyBvdXRwdXQgYW55d2F5IGFuZCB0aGVyZSdzIG5vIHBv aW50IHRlc3RpbmcgQkFSLiAgU28sCiAgICAgICAgICAgICA7OyBza2lwIHR5cGUgYWxyZWFk eSBzZWxlY3RlZCBhcyBwYXJlbnQgb2YgYW5vdGhlciB0eXBlLAogICAgICAgICAgICAgOzsg YXNzdW1pbmcgdGhhdCwgbW9zdCBvZiB0aGUgdGltZSwgYGFzc3EnIHdpbGwgYmUgZmFzdGVy CiAgICAgICAgICAgICA7OyB0aGFuIGBjbC10eXBlcCcuCiAgICAgICAgICAgICAobnVsbCAo YXNzcSB0eXBlIGZvdW5kKSkKICAgICAgICAgICAgIDs7IElmIE9CSkVDVCBpcyBvZiB0eXBl LCBhZGQgdHlwZSBhbmQgcGFyZW50cyB0byB0aGUgREFHLgogICAgICAgICAgICAgKGNsLXR5 cGVwIG9iamVjdCB0eXBlKQogICAgICAgICAgICAgOzsgKGRvbGlzdCAocCAoY2wtLXR5cGUt cGFyZW50cyB0eXBlKSkKICAgICAgICAgICAgIDs7ICAgKHB1c2ggKGNsLS10eXBlLXBhcmVu dHMgcCkgZm91bmQpKQogICAgICAgICAgICAgOzsgRXF1aXZhbGVudCB0byB0aGUgYGRvbGlz dCcgYWJvdmUsIGJ1dCBmYXN0ZXI6IGF2b2lkIHRvCiAgICAgICAgICAgICA7OyByZWNvbXB1 dGUgc2V2ZXJhbCBsaXN0cyBvZiBwYXJlbnRzIHdlIGFscmVhZHkga25vdy4KICAgICAgICAg ICAgIChsZXQgKChwbCAoY2wtLXR5cGUtcGFyZW50cyB0eXBlKSkpCiAgICAgICAgICAgICAg ICh3aGlsZSBwbAogICAgICAgICAgICAgICAgIChwdXNoIHBsIGZvdW5kKQogICAgICAgICAg ICAgICAgIChzZXRxIHBsIChjZHIgcGwpKSkpKQogICAgICAgICAgKGVycm9yCiAgICAgICAg ICAgKG1lc3NhZ2UgImNsLXR5cGVzLW9mLCAlcyIgKGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVy cikpKSkpCiAgICAgIDs7IENvbXB1dGUgYW4gb3JkZXJlZCBsaXN0IG9mIHR5cGVzIGZyb20g dGhlIGNvbGxlY3RlZCBEQUcuCiAgICAgIChzZXRxIGZvdW5kIChtZXJnZS1vcmRlcmVkLWxp c3RzIGZvdW5kKSkKICAgICAgOzsgUmV0dXJuIGFuIHVuaXF1ZSB2YWx1ZSBvZiB0aGlzIGxp c3Qgb2YgdHlwZXMsIHdoaWNoIGlzIGFsc28KICAgICAgOzsgdGhlIGxpc3Qgb2Ygc3BlY2lm aWVycyBmb3IgdGhpcyB0eXBlLgogICAgICAod2l0aC1tZW1vaXphdGlvbiAoZ2V0aGFzaCBm b3VuZCBjbC0tdHlwZS11bmlxdWUpCiAgICAgICAgZm91bmQpKSkpCgo7OzsgTWV0aG9kIGRp c3BhdGNoaW5nCjs7CihjbC1nZW5lcmljLWRlZmluZS1nZW5lcmFsaXplciBjbC0tdHlwZS1n ZW5lcmFsaXplcgogIDIwIDs7ICJ0eXBlb2YiIDwgImNsLXR5cGVzLW9mIiA8ICJoZWFkIiBw cmlvcml0eQogIChsYW1iZGEgKG9iaiAmcmVzdCBfKSBgKGNsLXR5cGVzLW9mICxvYmopKQog IChsYW1iZGEgKHRhZyAmcmVzdCBfKSAoaWYgKGNvbnNwIHRhZykgdGFnKSkpCgooY2wtZGVm bWV0aG9kIGNsLWdlbmVyaWMtZ2VuZXJhbGl6ZXJzIDpleHRyYSAiY2wtdHlwZXMtb2YiICh0 eXBlKQogICJTdXBwb3J0IGZvciBkaXNwYXRjaCBvbiB0eXBlcy4iCiAgKGlmIChjbC0tdHlw ZS1wIHR5cGUpCiAgICAgIChsaXN0IGNsLS10eXBlLWdlbmVyYWxpemVyKQogICAgKGNsLWNh bGwtbmV4dC1tZXRob2QpKSkKCihwcm92aWRlICdjbC10eXBlcykKCjs7OyBjbC10eXBlcy5l bCBlbmRzIGhlcmUK --------------f9Pq14eM3v8f6UAXZV4u0vT5--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 25 Apr 2025 19:37:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 25 15:37:48 2025
Received: from localhost ([127.0.0.1]:53330 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8Ors-0002J2-2y
for submit <at> debbugs.gnu.org; Fri, 25 Apr 2025 15:37:48 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60612)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u8Orp-0002Ib-O6
for 77725 <at> debbugs.gnu.org; Fri, 25 Apr 2025 15:37:46 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EE9CF8061C;
Fri, 25 Apr 2025 15:37:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745609859;
bh=qw6jisVQqd0a08K0OrRav6WyGlbMiewCjrUMZTuqDtA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=nl/FxiFzN0TY+PR8nzN6ZeFg9pjWxGRfU6fqhfDm12N0/FH5dhCxkYZ6pNq4P9wEf
ghvYx0rG9lS9El9tz23mI7qF+lVsFghfAic6Aq56N2DvkAOeYSP2nvnyFKtGep8255
Z9vAotoQfnYy6buksJ15/qOAJxzRcnKDh0oR8IXbcP1TSzCmskQGjQQC6wp6VQr/x1
UGIhV1Yp+gqAlIy2SH6x1InfI1Kx3WbbKOCjIDjuVlvQT91cuy6lIV6S4DLQMI4acr
set/pq8qIAX3XZSsehXeEBjj8IaQ0qtEES7wFuOpBmp/G1iyiek3l2d2kiU/U8WNHO
DmdXU5V9BvYkg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 28301806EF;
Fri, 25 Apr 2025 15:37:39 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 13996120497;
Fri, 25 Apr 2025 15:37:39 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwv7c38avsu.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
Date: Fri, 25 Apr 2025 15:37:38 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.202 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
[ Just tooting my horn, nothing to see. ]
>> Here is a test case with a recursion:
>>
>> (cl-deftype T1 ()
>> "Root type.
>> Check if passed object is a subtype of T1. I.e., if T1 is present in
>> object type parents."
>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
>
> Hmm... I can see that it could be handy if you don't know how to
> characterize type T1 other than as the "sum" of its subtypes.
> But this seems rather circular. Have you seen such things out in
> the wild?
BTW, this form of circularity is called an *impredicative* definition:
the above definition does not directly refer to T1 (as in the case of
a recursive definition), instead it refers (via the definition of
`gtypes-of`) to the set of all types, to which T1 happens to belong.
As it happens, the notion of *type* was invented/introduced by Bertrand
Russel (early 20th century) specifically in order to try and disallow
the kind of paradoxes (like Russel's paradox or the paradox of the
barber) that impredicativity makes possible.
OK, you can go back to your regularly scheduled ELisp hacking now,
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 25 Apr 2025 18:07:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 25 14:07:16 2025
Received: from localhost ([127.0.0.1]:52624 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8NSF-0003iw-De
for submit <at> debbugs.gnu.org; Fri, 25 Apr 2025 14:07:16 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1059)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u8NSC-0003ia-V6
for 77725 <at> debbugs.gnu.org; Fri, 25 Apr 2025 14:07:13 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3696480911;
Fri, 25 Apr 2025 14:07:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745604425;
bh=Fw8Q96Ppzq/xzBXkl35O1/dysQboZnEwoUCbf4o8sYs=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=equhsCUrn84kPXmRoyQzV+SBQ9qd5DGEF3o8Q6FwwqzeHgdtFcGdsfOvISpycmdY4
AG9zscRTESQbYwb423jjJBQS6dpcOZsRFQ4kS9aAeP4wloHMRE05mitmf44pVV03pY
DlHOYQSr9S7BXDlG6AgM8tDxo5Gw+DRBLYAu20Fi0b2typNHokSMjf+uiGOXYBNV5H
lCQ++1ZCjkU4L5cQq1+3QDg+sj+KuThW9Sep/NaY4rGGUy++rCmx0Ec79wrxN2WWIB
5RZqW7hmxvnt9K8P484mQuV1BeASFlh2R9sk+B7ABPegmXVzXyCQb80KOYYcHm6Bws
JikSSjnL/OR3g==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0BB9E80860;
Fri, 25 Apr 2025 14:07:05 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EFFC01201A9;
Fri, 25 Apr 2025 14:07:04 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
Message-ID: <jwvtt6cb0o0.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
<1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
Date: Fri, 25 Apr 2025 14:07:04 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.202 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> (cl-deftype T1 ()
>>> "Root type.
>>> Check if passed object is a subtype of T1. I.e., if T1 is present in
>>> object type parents."
>>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
>> Hmm... I can see that it could be handy if you don't know how to
>> characterize type T1 other than as the "sum" of its subtypes.
>> But this seems rather circular. Have you seen such things out in
>> the wild?
> I am using a such "abstract" type in one of my library for exactly
> this: "characterize type T1 other than as the "sum" of its subtypes."
[ FWIW, this definition makes your type-test quite costly since it will
test more or less each and every type defined with `cl-deftype`.
You'd be better served with a more targeted test which keeps track of
the children of T1 so it can then do something like
(cl-some (lambda (child) (cl-typep o child)) my-children)
This way the performance is not affected by random other unrelated types.
But, yes, that begs the question of how to keep track of the
children, e.g. how to be told when a child needs to be added/removed
to/from `my-children`. ]
>> More importantly, with your circularity-breaking approach, if `gtype-of`
>> (aka `cl-types-of`) happens to look at T1 first, that check will
>> immediately return nil, so `cl-types-of` may decide "Oh, I just
>> discovered this is not a T1, so I can skip checking all the subtypes of
>> T1". So, the cycle is broken, but the output is wrong.
>
> Look at T1 first should be possible only if T1 is alone, without any
[...]
Agreed.
> Did I miss something?
What you missed (because I didn't make it clear) is that I was talking
about an incorrect behavior of your circularity-breaking approach, when
coupled with *another* algorithm than the one you currently use to
collect the set of types to return in `cl-types-of`.
>> The need for multiple object would be for cases like:
>> (cl-deftype car-foo ()
>> "Car-Foo type.
>> Check if passed object has a subtype of FOO as car."
>> `(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
>> but I guess this can inf-loop only if we follow a cycle in the object
>> (e.g. say if o == (car (car (car o)))).
>
> Not sure to understand what you mean by "need for multiple object", I am sorry.
>
> I tries this, and, for me it works as expected:
>
> (cl-deftype car-foo ()
> "Car-Foo type.
> Check if passed object has a subtype of FOO as car."
> `(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
>
> (cl-deftype FOO ()
> `(or (and symbol (satisfies ,(lambda (o) (eq o 'FOO))))
> car-foo))
>
> (cl-types-of 'FOO)
> => FOO symbol atom t)
>
> (cl-types-of '(FOO))
> => (FOO car-foo cons list sequence t)
>
> (cl-types-of '(((((FOO))))))
> => (FOO car-foo cons list sequence t)
Don't test it with '(((((FOO))))) because that's not a case where
`o == (car (car (car o)))` You need something like
(let ((o (list nil nil)))
(setq o (list (list (list o))))
(cl-types-of o))
As I implied, this is probably not too serious.
> This makes me think that errors that might occur when calling
> `cl-typep' should be handled in `cl-types-of' to prevent an
> incorrect definition from impacting method dispatching on types
> correctly defined.
> WDYT?
Maybe. I'd tend to think that `cl-typep` should never error, so if it
ever does (which would indicate a bug in some `cl-deftype`), we wouldn't
want to hide that error.
>>> ;; T2 will never match, because `cl-types-of' enters in an endless recursion
>>> (cl-typep (list 'T2) 'T1)
>>> => nil
>> This is both right and wrong: we could return t and that would be
>> equally valid.
>>
>>> (cl-types-of (list 'T2))
>>> => (cons list sequence t)
>> And here (T2 T1 cons list sequence t) would also be equally valid.
>
> Sorry, you lost me here. As I understand it, a type whose definition
> enter in an endless recursion is not valid, and should never match?
It depends on whether you define your types inductively or co-inductively.
IOW, do you define the type by starting with the "empty set" and then
adding new elements to it until there's nothing more to add, or do you
define it by starting with a "total set" that contains everything and
then remove elements from it until you've removed everything that
doesn't belong there.
Another way to look at it: there's nothing in your definition of T2 that
says that the list `(T2)` should *not* be an element of that type.
For recursive values, in order to break circularity, it is common to
check whether a value satisfies a constraint by adding "yes it does" as
a temporary assumption while performing the check, so as to break the
cycle when we get to a nested occurrence of that object.
If we use the same approach here, the T2 test will say that `(T2)` is
indeed of type T2.
>>>> There's also some stylistic problems with the tests:
>>>> - We shouldn't test the return value of `cl-deftype`: I don't think it's
>>>> documented anywhere and I don't think it's good practice to pay
>>>> attention to the return value of declarations.
>>> You are certainly right. I just wanted to check that `cl-deftype'
>>> didn't fail, but there is no `should-no-error'. Would it be better to
>>> test for the presence of the type just defined in `cl--type-list'?
>> I'd just move the `cl-deftype` calls out of the tests and presume that if
>> they signal an error we'll see it.
>
> The problem with this approach is that it is difficult to isolate and cleanup
> the definitions needed for test-1 from those needed for test-2. Also the result
> will depends on the order of the cl-deftype for test-1 and test-2, because these
> definitions will be effective outside of test-1 and test-2.
>
> But maybe it's not so important after all. I'll try to reformulate the tests this way.
In the worst case, you can duplicate the definitions (with different names).
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 25 Apr 2025 09:02:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 25 05:02:30 2025 Received: from localhost ([127.0.0.1]:47193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u8Ex3-0006y2-SU for submit <at> debbugs.gnu.org; Fri, 25 Apr 2025 05:02:30 -0400 Received: from smtp-82.smtpout.orange.fr ([80.12.242.82]:47251 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u8Ex1-0006xs-NT for 77725 <at> debbugs.gnu.org; Fri, 25 Apr 2025 05:02:28 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 8Ewuuwwmpvf4p8Ewxugyth; Fri, 25 Apr 2025 11:02:26 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745571746; bh=GT01lSjYxR7CR65lUt+9IH7gtM9JKIIe1BnM/8RmN9g=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=JfbgNgU+J4+cB5zSdCehV3CfbjnpNcbH5JW354uS4BXG5fqXReImw/GjlkdA33lEM tnfVY+47fRc3aaHelOMG2ldojtrHZ0uAt0MM4TFHubC46NB360fxsXAsOqIfVf0rlh rCywJVsDLihZIQC/HO2aHKot8g2gVUpNUKqPI7MNdZo9FXRwl/ykqv7XJEtIF0uUiS NzY+5RKnELLCQROJLDlv8VBqiS1h3nQIA6AgufWbNvv9MQTGZLvvBzxYjTyfL2tNhy nrHNS4Ct9Lb0szal73arrvR4XGHIEEjMt8OuTe2+Frkee6TK2iupmU0D+EKtu1JfO9 BebuCgKVrok9Q== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Fri, 25 Apr 2025 11:02:26 +0200 X-ME-IP: 90.112.40.65 Message-ID: <d9f0efa0-b3c1-4bbc-a8ec-9c5d394a7c9a@HIDDEN> Date: Fri, 25 Apr 2025 11:02:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> <21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN> <2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN> <85583c7e-fcf1-47e9-985b-4cefb26ca0c5@HIDDEN> <jwvbjsl9wky.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvbjsl9wky.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-24 21:44, Stefan Monnier wrote: >> Another information which could be useful: if I replace (cl-eval-when >> (compile load eval) ...) by (eval-and-compile ...) in the definition >> of `cl-deftype', there is no side effect of the byte-compilation on >> the current definition. > > It looks like this is a bug in `cl-eval-when` introduced when Alan added > "symbol with positions" for better error reporting. > > Could you make it a separate bug-report? Done. Bug#78056 > >> What I don't know is if the two forms are equivalent. > > Obviously they don't do quite the same thing, but AFAIK they *should* > behave the same, so I'd use `eval-and-compile`. > Ok, done. Thank you!
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 25 Apr 2025 09:01:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 25 05:01:24 2025
Received: from localhost ([127.0.0.1]:47184 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u8Evz-0006ur-Pi
for submit <at> debbugs.gnu.org; Fri, 25 Apr 2025 05:01:24 -0400
Received: from smtp-78.smtpout.orange.fr ([80.12.242.78]:44901
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u8Evu-0006uR-O3
for 77725 <at> debbugs.gnu.org; Fri, 25 Apr 2025 05:01:21 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 8EvnuxSy2OaHY8EvruW8LY; Fri, 25 Apr 2025 11:01:16 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1745571676;
bh=8XW2fgSCO82sqeYNL1E3IJKaOl2CMKUURjQp7eQA3RU=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=I9hG1nMZV7X8c8MwOHyss2dSa4SrLNxMcnTa05HOcUB022DEFIlXQtvCHYj6O77Le
/fUuQGFdv2jwRMhscqISvwQKxvGx9GUZ3reeyKecVEOXsOjOt0LDXQIgwnGPZVZ42z
SFbAtI6KiLp6mBAYqvM73c5m7ywB7J6JNg9AXakYpxq+/8Gq65rrQYhmwZ0zXF4efA
WMqTPcaDauCtktLZhbdQHQKJbyCpizE7inKvkPfrCrwFXJ/2zOt1RZ7VsQCFbwIY25
CzeX2D6NLL4uQBta+qjcIc42MZzJztlJTKW4mSxWc71spZa7sbj9W98upEGetv0xws
gfNy7EOe+czPA==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Fri, 25 Apr 2025 11:01:16 +0200
X-ME-IP: 90.112.40.65
Message-ID: <1fc713be-ed86-45ab-bff7-dc2aac307b57@HIDDEN>
Date: Fri, 25 Apr 2025 11:01:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep'
to cl-generic?
To: Stefan Monnier <monnier@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-24 21:38, Stefan Monnier wrote:
>> Here is a test case with a recursion:
>>
>> (cl-deftype T1 ()
>> "Root type.
>> Check if passed object is a subtype of T1. I.e., if T1 is present in
>> object type parents."
>> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
>
> Hmm... I can see that it could be handy if you don't know how to
> characterize type T1 other than as the "sum" of its subtypes.
> But this seems rather circular. Have you seen such things out in
> the wild?
I am using a such "abstract" type in one of my library for exactly
this: "characterize type T1 other than as the "sum" of its subtypes."
> More importantly, with your circularity-breaking approach, if `gtype-of`
> (aka `cl-types-of`) happens to look at T1 first, that check will
> immediately return nil, so `cl-types-of` may decide "Oh, I just
> discovered this is not a T1, so I can skip checking all the subtypes of
> T1". So, the cycle is broken, but the output is wrong.
Look at T1 first should be possible only if T1 is alone, without any
subtype defined. This is why I call T1 an "abstract" type. And as such
it is normal that no object will belong to it directly. For an object to
belong to T1 it must first belong to one of its "concrete" subtype (with a
builtin Emacs type in parents). And in this case it is guaranteed that
subtypes will appear before T1 in the list of defined types to check.
So, no recursion on T1 when subtypes exist.
Did I miss something?
>
> The need for multiple object would be for cases like:
>
> (cl-deftype car-foo ()
> "Car-Foo type.
> Check if passed object has a subtype of FOO as car."
> `(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
>
> but I guess this can inf-loop only if we follow a cycle in the object
> (e.g. say if o == (car (car (car o)))).
Not sure to understand what you mean by "need for multiple object", I am sorry.
I tries this, and, for me it works as expected:
(cl-deftype car-foo ()
"Car-Foo type.
Check if passed object has a subtype of FOO as car."
`(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
(cl-deftype FOO ()
`(or (and symbol (satisfies ,(lambda (o) (eq o 'FOO))))
car-foo))
(cl-types-of 'FOO)
=> FOO symbol atom t)
(cl-types-of '(FOO))
=> (FOO car-foo cons list sequence t)
(cl-types-of '(((((FOO))))))
=> (FOO car-foo cons list sequence t)
However, in the last case, cl-types-of is entered 95 times!
This makes me think that errors that might occur when calling
`cl-typep' should be handled in `cl-types-of' to prevent an
incorrect definition from impacting method dispatching on types
correctly defined.
WDYT?
>
>> (cl-deftype T2 ()
>> "Recursive on checking for T1, never match."
>> (declare (parents T1))
>> `(and T1 (satisfies ,(lambda (o) (equal o '(T2))))))
>
> Is this definition meaningful with the above definition of T1?
> I don't think it's well-founded.
Correct. It was just a "bad" example. The correct definition is T3.
>> (defgtype T3 ()
>> "Not recursive on T1."
>> (declare (parents T1))
>> `(satisfies ,(lambda (o) (equal o '(T3)))))
>>
>> ;; T2 will never match, because `cl-types-of' enters in an endless recursion
>> (cl-typep (list 'T2) 'T1)
>> => nil
>
> This is both right and wrong: we could return t and that would be
> equally valid.
>
>> (cl-types-of (list 'T2))
>> => (cons list sequence t)
>
> And here (T2 T1 cons list sequence t) would also be equally valid.
Sorry, you lost me here. As I understand it, a type whose definition
enter in an endless recursion is not valid, and should never match?
>
>>> There's also some stylistic problems with the tests:
>>> - We shouldn't test the return value of `cl-deftype`: I don't think it's
>>> documented anywhere and I don't think it's good practice to pay
>>> attention to the return value of declarations.
>> You are certainly right. I just wanted to check that `cl-deftype'
>> didn't fail, but there is no `should-no-error'. Would it be better to
>> test for the presence of the type just defined in `cl--type-list'?
>
> I'd just move the `cl-deftype` calls out of the tests and presume that if
> they signal an error we'll see it.
The problem with this approach is that it is difficult to isolate and cleanup
the definitions needed for test-1 from those needed for test-2. Also the result
will depends on the order of the cl-deftype for test-1 and test-2, because these
definitions will be effective outside of test-1 and test-2.
But maybe it's not so important after all. I'll try to reformulate the tests this way.
>
>>> - They use `eval` too much.
>> This is because `cl-deftype' is a macro and the doc string of
>> `ert-deftest' suggests to wrap macros in `(eval (quote ...))' to test
>> them.
>
> That's only when you specifically need to test the effect of the
> macro-expansion itself, rather than test the result of running the
> macro-expanded code. It's rarely needed IME. An example would be to
> detect when a macro-expansion emits a warning.
>
> Also, by using this `eval+quote` you can't test the macro in the way
> it's usually used (where it's macro-expanded once during compilation and
> then its result is run in another Emacs session) so you may miss bugs
> such as when the macro's expansion performs a side-effect (like add
> something to a list) which the expanded code expects to have happened
> (but this will have happened during compilation, so the element may not
> be in the list any more when the code is finally executed).
>
> IOW, I disagree with the docstring. 🙁
I understand.
Thanks
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 24 Apr 2025 19:44:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 24 15:44:50 2025
Received: from localhost ([127.0.0.1]:41477 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u82V7-0004Xf-WA
for submit <at> debbugs.gnu.org; Thu, 24 Apr 2025 15:44:50 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63872)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u82V4-0004XA-Kt
for 77725 <at> debbugs.gnu.org; Thu, 24 Apr 2025 15:44:47 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 02DB710013E;
Thu, 24 Apr 2025 15:44:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745523880;
bh=Sr53QluRaFPrXTG2Uer5tuUMKYlu+W3Ue7nAisRgpsA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=VQDuaEWx8LR67hv0MY1OrkydLZD6jC2x4iwrl9kqcouR33He23FcNx5FQXkerz44u
zpaUOTkHf+8f/dBaWfNfes7TUnBgapMly8LPf0JceWOg2TSivhLwyPjMN/dBOLa5P8
5T0DyolR27aXiPb3uLYyZq3AyA6Do/kb8T85RH6rgbBNs03ck15GRs1Rih690plEV1
AnUq33yx55y36qEHstQi/7jiqWBqX1cceeGEyBtujelwjBpCIz6/ol0Ch7pklLbIWb
Ps9HUOP5hdO4rW9yeJMx9jcspPeN6Y6y5939wGRuLEOHmcfPnTcphSufJS4GDjOUhd
On0CdHnBJWcag==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 604C0100034;
Thu, 24 Apr 2025 15:44:40 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 45B0E12051F;
Thu, 24 Apr 2025 15:44:40 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <85583c7e-fcf1-47e9-985b-4cefb26ca0c5@HIDDEN>
Message-ID: <jwvbjsl9wky.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
<21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN>
<2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN>
<85583c7e-fcf1-47e9-985b-4cefb26ca0c5@HIDDEN>
Date: Thu, 24 Apr 2025 15:44:38 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.204 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Another information which could be useful: if I replace (cl-eval-when
> (compile load eval) ...) by (eval-and-compile ...) in the definition
> of `cl-deftype', there is no side effect of the byte-compilation on
> the current definition.
It looks like this is a bug in `cl-eval-when` introduced when Alan added
"symbol with positions" for better error reporting.
Could you make it a separate bug-report?
> What I don't know is if the two forms are equivalent.
Obviously they don't do quite the same thing, but AFAIK they *should*
behave the same, so I'd use `eval-and-compile`.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 24 Apr 2025 19:38:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 24 15:38:51 2025
Received: from localhost ([127.0.0.1]:41437 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u82PK-0004BH-S4
for submit <at> debbugs.gnu.org; Thu, 24 Apr 2025 15:38:51 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15694)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u82PH-0004Al-Sa
for 77725 <at> debbugs.gnu.org; Thu, 24 Apr 2025 15:38:50 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 342C08087F;
Thu, 24 Apr 2025 15:38:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745523520;
bh=kbhyl4Rfq2SIOs6K3nHnsg+Q8NFCqa/VY+6Gahg13d0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=mf3jhvxPR/pvZaLw5dpVyMocLkMB9Iw+Z4Q+vrempDE4JAiKJNq7S6ruKuWEq0Uxs
Ai4wdurmsyCPeIkcbFKMaCBGejm4ru5lRb63IVed4BN5L8hrxjgHg2uIL24Kk0UUQ7
2AIoTAk4MPAEK77lzg4amssoYax7BfE+s/H80zfJWH9Mwa/KdOkn5gaW7ig2nWOiBB
b61FAxenE1YANXB0xipWesAwlhjH+2/PAUzxovQFHzRIzQ2tEWyJjaIYifJ1KBzUSI
mvIWQCXX7mhLcRNrjxuziFNdnDgT831dyvr5tedjLBZBMSaaGd1zQs3hk3vwK84SbL
sTEYr7HySUh3A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CAD5C802A2;
Thu, 24 Apr 2025 15:38:40 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A38B5120568;
Thu, 24 Apr 2025 15:38:40 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
Message-ID: <jwvh62d9ybw.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
<jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
<a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN>
Date: Thu, 24 Apr 2025 15:38:40 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.169 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Here is a test case with a recursion:
>
> (cl-deftype T1 ()
> "Root type.
> Check if passed object is a subtype of T1. I.e., if T1 is present in
> object type parents."
> `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o)))))
Hmm... I can see that it could be handy if you don't know how to
characterize type T1 other than as the "sum" of its subtypes.
But this seems rather circular. Have you seen such things out in
the wild?
More importantly, with your circularity-breaking approach, if `gtype-of`
(aka `cl-types-of`) happens to look at T1 first, that check will
immediately return nil, so `cl-types-of` may decide "Oh, I just
discovered this is not a T1, so I can skip checking all the subtypes of
T1". So, the cycle is broken, but the output is wrong.
The need for multiple object would be for cases like:
(cl-deftype car-foo ()
"Car-Foo type.
Check if passed object has a subtype of FOO as car."
`(satisfies ,(lambda (o) (memq 'FOO (gtype-of (car-safe o))))))
but I guess this can inf-loop only if we follow a cycle in the object
(e.g. say if o =3D=3D (car (car (car o)))).
> (cl-deftype T2 ()
> "Recursive on checking for T1, never match."
> (declare (parents T1))
> `(and T1 (satisfies ,(lambda (o) (equal o '(T2))))))
Is this definition meaningful with the above definition of T1?
I don't think it's well-founded.
> (defgtype T3 ()
> "Not recursive on T1."
> (declare (parents T1))
> `(satisfies ,(lambda (o) (equal o '(T3)))))
>
> ;; T2 will never match, because `cl-types-of' enters in an endless recurs=
ion
> (cl-typep (list 'T2) 'T1)
> =3D> nil
This is both right and wrong: we could return t and that would be
equally valid.
> (cl-types-of (list 'T2))
> =3D> (cons list sequence t)
And here (T2 T1 cons list sequence t) would also be equally valid.
>> There's also some stylistic problems with the tests:
>> - We shouldn't test the return value of `cl-deftype`: I don't think it's
>> documented anywhere and I don't think it's good practice to pay
>> attention to the return value of declarations.
> You are certainly right. I just wanted to check that `cl-deftype'
> didn't fail, but there is no `should-no-error'. Would it be better to
> test for the presence of the type just defined in `cl--type-list'?
I'd just move the `cl-deftype` calls out of the tests and presume that if
they signal an error we'll see it.
>> - They use `eval` too much.
> This is because `cl-deftype' is a macro and the doc string of
> `ert-deftest' suggests to wrap macros in `(eval (quote ...))' to test
> them.
That's only when you specifically need to test the effect of the
macro-expansion itself, rather than test the result of running the
macro-expanded code. It's rarely needed IME. An example would be to
detect when a macro-expansion emits a warning.
Also, by using this `eval+quote` you can't test the macro in the way
it's usually used (where it's macro-expanded once during compilation and
then its result is run in another Emacs session) so you may miss bugs
such as when the macro's expansion performs a side-effect (like add
something to a list) which the expanded code expects to have happened
(but this will have happened during compilation, so the element may not
be in the list any more when the code is finally executed).
IOW, I disagree with the docstring. =F0=9F=99=81
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 24 Apr 2025 16:34:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 24 12:34:23 2025 Received: from localhost ([127.0.0.1]:40618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u7zWo-0001Op-9j for submit <at> debbugs.gnu.org; Thu, 24 Apr 2025 12:34:22 -0400 Received: from smtp-74.smtpout.orange.fr ([80.12.242.74]:44693 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u7zWh-0001OW-Fl for 77725 <at> debbugs.gnu.org; Thu, 24 Apr 2025 12:34:18 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 7zWZu5VowCZIm7zWcuoHV9; Thu, 24 Apr 2025 18:34:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745512453; bh=Vtzh+6FqS8meQ+ESlHUz7a7AskghZHPvCkjCuHXbfzI=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=pE5QZoEw2ZR6cvMPU5A5TsUhBlDdgK2/mC/Xxy8M5jlT+6/M1AYjO+oTu0dKH07Pi mH7rt3Ffiev4szfzeLEbjSz4u3Lz4ARkYSRFu5b1+DfAgsTm/6jy+Djvqq03tbU+cp 6+fqj/8RGcxY4mLr1Nu7vRkopzlI7iunCB07/SIC64dlhbmsPqTRXdpN76Zuq41hs7 h0dXNZx36xnopGK1YNFo3r+WmVrCzZ3PjfPEONWFZAYd5TCKtES7ODvRe+yP9gczNB 296ky+0DEC7ztCzLgrOtIZ0oMAHpPIMtDfGn+ytbqtF5SDVa+MncfdY5Fuas6eUmkh i2NW/Z03yt3uw== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Thu, 24 Apr 2025 18:34:13 +0200 X-ME-IP: 90.112.40.65 Message-ID: <85583c7e-fcf1-47e9-985b-4cefb26ca0c5@HIDDEN> Date: Thu, 24 Apr 2025 18:34:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? From: David Ponce <da_vid@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> <21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN> <2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN> Content-Language: fr, en-US In-Reply-To: <2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-24 13:44, David Ponce wrote: > On 2025-04-23 14:59, David Ponce wrote: >> >> While working with cl-types.el I discovered a nasty side effect >> of byte compilation on the cl--type-list. >> >> I can't explain what is going on :-( >> >> Here is a recipe: >> >> - run emacs -Q >> >> - load cl-type.el (the last version previously attached) >> >> - load cl-type-recipe.el (attached) >> >> - In the scratch buffer eval cl--type-list. Result is expected: >> >> (cons-cdr-foo cons-car-foo) >> >> - Then open cl-type-recipe.el and byte-compile it with >> M-x emacs-lisp-byte-compile >> >> - Then eval again cl--type-list in the scratch buffer, and now the >> result is something like this: >> >> (#<symbol cons-cdr-foo at 158> #<symbol cons-car-foo at 46>) >> >> Which completely breaks cl-types ! >> >> I hope you can shed some light on what is going on here. >> >> Thanks! >> > > It seems the side effect is more general than just with cl-type.el. > > I attached cl-type-recipe2.el, another simple recipe to illustrate with > current `cl-deftype'. > > - Run emacs -Q and load cl-type-recipe2.el. > - Then in the scratch buffer eval: > > (symbol-plist 'cons-car-foo) > => (cl-deftype-handler #[nil ((list 'satisfies #'(lambda (x) (eq (car-safe x) 'foo)))) (t) nil "A cons with a `foo' car."]) > > - Then open cl-type-recipe2.el and M-x emacs-lisp-byte-compile > > - Then in the scratch buffer eval again: > > (symbol-plist 'cons-car-foo) > => (cl-deftype-handler #[nil (`(#<symbol satisfies at 113> ,(#<symbol lambda at 125> (x) (#<symbol eq at 137> (#<symbol car-safe at 141> #<symbol x at 150>) '#<symbol foo at 154>)))) (t) nil "A cons with a `foo' car."]) > > And, of course: > > (cl-typep '(foo) 'cons-car-foo) > => (invalid-function #<symbol lambda at 125>) > > Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect. > > Hope it will help. > > David Another information which could be useful: if I replace (cl-eval-when (compile load eval) ...) by (eval-and-compile ...) in the definition of `cl-deftype', there is no side effect of the byte-compilation on the current definition. What I don't know is if the two forms are equivalent.
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 24 Apr 2025 11:44:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 24 07:44:23 2025 Received: from localhost ([127.0.0.1]:36902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u7v0A-0007ju-Kt for submit <at> debbugs.gnu.org; Thu, 24 Apr 2025 07:44:23 -0400 Received: from smtp-30.smtpout.orange.fr ([80.12.242.30]:33103 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u7v05-0007jP-M1 for 77725 <at> debbugs.gnu.org; Thu, 24 Apr 2025 07:44:18 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 7uzxu2U5kN5mI7v00uBNIe; Thu, 24 Apr 2025 13:44:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745495056; bh=XRHHayeUZRcdxOyzjCVPrlAxFQBOHFaQiH7tEXNTBMM=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=amv6iIY1SrGqv28KXWQx0SeBG9dFpWZEypfZ36sc5pQiKyqLlzUK4WSLt4o/cw334 IVu+oyljOdsVHL2okp7EeBcryNO0xHtH7KQ/oQR89WziPtBWefkcW6bPoFcsmLE4Qg zm+R4gJsh6+UZvXNrFDpqpi4KbXuzj11W6pXILQkS8Tr4Moi198/2HeMFcDS83EBW/ 7nnTX5bKdODpy2tnCv0wZpCGownKm2l7Ne5Ij5RheRMPmXEyx7y8fwqapX0Dbng4Jo PbEblbvrNMWtLXLHi775hddINd5FXPwrhb+HjQuXP7auusNg2iBo0FjuVz/MdB3ngY kMxDtya7hLcSA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Thu, 24 Apr 2025 13:44:16 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------qBlIzokXAVqaBLV6oMH0fVFq" Message-ID: <2320a70a-025c-4803-8842-b20cf6275d41@HIDDEN> Date: Thu, 24 Apr 2025 13:44:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? From: David Ponce <da_vid@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> <21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN> Content-Language: fr, en-US In-Reply-To: <21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------qBlIzokXAVqaBLV6oMH0fVFq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025-04-23 14:59, David Ponce wrote: > > While working with cl-types.el I discovered a nasty side effect > of byte compilation on the cl--type-list. > > I can't explain what is going on :-( > > Here is a recipe: > > - run emacs -Q > > - load cl-type.el (the last version previously attached) > > - load cl-type-recipe.el (attached) > > - In the scratch buffer eval cl--type-list. Result is expected: > > (cons-cdr-foo cons-car-foo) > > - Then open cl-type-recipe.el and byte-compile it with > M-x emacs-lisp-byte-compile > > - Then eval again cl--type-list in the scratch buffer, and now the > result is something like this: > > (#<symbol cons-cdr-foo at 158> #<symbol cons-car-foo at 46>) > > Which completely breaks cl-types ! > > I hope you can shed some light on what is going on here. > > Thanks! > It seems the side effect is more general than just with cl-type.el. I attached cl-type-recipe2.el, another simple recipe to illustrate with current `cl-deftype'. - Run emacs -Q and load cl-type-recipe2.el. - Then in the scratch buffer eval: (symbol-plist 'cons-car-foo) => (cl-deftype-handler #[nil ((list 'satisfies #'(lambda (x) (eq (car-safe x) 'foo)))) (t) nil "A cons with a `foo' car."]) - Then open cl-type-recipe2.el and M-x emacs-lisp-byte-compile - Then in the scratch buffer eval again: (symbol-plist 'cons-car-foo) => (cl-deftype-handler #[nil (`(#<symbol satisfies at 113> ,(#<symbol lambda at 125> (x) (#<symbol eq at 137> (#<symbol car-safe at 141> #<symbol x at 150>) '#<symbol foo at 154>)))) (t) nil "A cons with a `foo' car."]) And, of course: (cl-typep '(foo) 'cons-car-foo) => (invalid-function #<symbol lambda at 125>) Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect. Hope it will help. David --------------qBlIzokXAVqaBLV6oMH0fVFq Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-type-recipe2.el" Content-Disposition: attachment; filename="cl-type-recipe2.el" Content-Transfer-Encoding: base64 OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgoocmVxdWlyZSAnY2wtbGliKQoKKGNs LWRlZnR5cGUgY29ucy1jYXItZm9vICgpCiAgIkEgY29ucyB3aXRoIGEgYGZvbycgY2FyLiIK ICBgKHNhdGlzZmllcyAsKGxhbWJkYSAoeCkgKGVxIChjYXItc2FmZSB4KSAnZm9vKSkpKQoK KGNsLWRlZnR5cGUgY29ucy1jZHItZm9vICgpCiAgIkEgY29ucyB3aXRoIGEgYGZvbycgY2Ry LiIKICBgKHNhdGlzZmllcyAsKGxhbWJkYSAoeCkgKGVxIChjZHItc2FmZSB4KSAnZm9vKSkp KQo= --------------qBlIzokXAVqaBLV6oMH0fVFq--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 23 Apr 2025 12:59:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 23 08:59:47 2025 Received: from localhost ([127.0.0.1]:55530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u7Zha-0005wp-AE for submit <at> debbugs.gnu.org; Wed, 23 Apr 2025 08:59:47 -0400 Received: from smtp-73.smtpout.orange.fr ([80.12.242.73]:59937 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u7ZhV-0005vx-TV for 77725 <at> debbugs.gnu.org; Wed, 23 Apr 2025 08:59:43 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 7ZhIuwMuXCZIm7ZhLusStQ; Wed, 23 Apr 2025 14:59:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745413180; bh=iFSNsv7QDhbS4JT/pM8OuoKkWGZLBw/n1nTXCcFtUEE=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=a7D9stwdBIe+E/CWTTfMNTOAmud978rQhVTrNnw8ElOwHqhGovOQWb2NNr86xyXwc cjeee7o4kWMes2a9HDsXMQk2IRbkYi7XFUSCQI8YcFuSiE+GLU/4OXMlhGVTb0ZZWf p079rp9mTAQh16Emm1ENl32OP2VAWRq28w8MbkcWtF5eAAZsQxOkTpZu0YehIm/1kF V5i36ksxOLb39b5mDQBuSlfpHoHc7XL0ozDMJ63kGrexmbvsLrXst+GtONnsZnUwnl cJ1QXqwysKCVcUumbLeGcdc2AakJzvylgVZmwQJTFXXbBYBTBW0i93WZ7xPqEHmcYn 8juSjfHzIWJyw== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Wed, 23 Apr 2025 14:59:40 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------WhsiHRnMr05b0GhdpVAPRinF" Message-ID: <21c6be88-5137-404b-a838-bc4da8cdf241@HIDDEN> Date: Wed, 23 Apr 2025 14:59:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? From: David Ponce <da_vid@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> Content-Language: fr, en-US In-Reply-To: <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------WhsiHRnMr05b0GhdpVAPRinF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit While working with cl-types.el I discovered a nasty side effect of byte compilation on the cl--type-list. I can't explain what is going on :-( Here is a recipe: - run emacs -Q - load cl-type.el (the last version previously attached) - load cl-type-recipe.el (attached) - In the scratch buffer eval cl--type-list. Result is expected: (cons-cdr-foo cons-car-foo) - Then open cl-type-recipe.el and byte-compile it with M-x emacs-lisp-byte-compile - Then eval again cl--type-list in the scratch buffer, and now the result is something like this: (#<symbol cons-cdr-foo at 158> #<symbol cons-car-foo at 46>) Which completely breaks cl-types ! I hope you can shed some light on what is going on here. Thanks! --------------WhsiHRnMr05b0GhdpVAPRinF Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-type-recipe.el" Content-Disposition: attachment; filename="cl-type-recipe.el" Content-Transfer-Encoding: base64 OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgooY2wtZGVmdHlwZTIgY29ucy1jYXIt Zm9vICgpCiAgIkEgY29ucyB3aXRoIGEgYGZvbycgY2FyLiIKICBgKHNhdGlzZmllcyAsKGxh bWJkYSAoeCkgKGVxIChjYXItc2FmZSB4KSAnZm9vKSkpKQoKKGNsLWRlZnR5cGUyIGNvbnMt Y2RyLWZvbyAoKQogICJBIGNvbnMgd2l0aCBhIGBmb28nIGNkci4iCiAgYChzYXRpc2ZpZXMg LChsYW1iZGEgKHgpIChlcSAoY2RyLXNhZmUgeCkgJ2ZvbykpKSkK --------------WhsiHRnMr05b0GhdpVAPRinF--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 23 Apr 2025 09:35:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 23 05:35:13 2025 Received: from localhost ([127.0.0.1]:53336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u7WVb-000398-B3 for submit <at> debbugs.gnu.org; Wed, 23 Apr 2025 05:35:13 -0400 Received: from smtp-72.smtpout.orange.fr ([80.12.242.72]:46023 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u7WVW-000347-9l for 77725 <at> debbugs.gnu.org; Wed, 23 Apr 2025 05:35:08 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 7WVIuRqNcX7PJ7WVLuWqiw; Wed, 23 Apr 2025 11:35:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745400904; bh=RUGu11WNq0w12VutxXjkLD+CtZ9or4os/rG1FLSIWjE=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=O0BUAf8fpr7GUWmPwIFWcL1x1ExOWNkT/jy/Mdde6m4vxf6orQNg5i6pw2/mUaoY+ rJ0KeXHB5xt6M9i5EOkRXNeyjNdcBDJ/7eBdz/Me8AGKMhKTqf7PjL6H8rWw3a0AJN gx90AgO9u1mbAw3crpMbuVW219iLv/74SIewIL8bW1s22TL0XgaacVHUpLhtTM0MVg VzfYZxtsL3IK1aMWRdFLHs7ojSMAk0yggle29nPFCeBmzIFuDtspssu3efZyuppSuG jbsQzMs7WYoeggcw3ebOL+dkOASZCs0oIcJApKsUysdLdDPUe1l6aDtOdNCaoRh5rC iwiWa4bA9hE7w== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Wed, 23 Apr 2025 11:35:04 +0200 X-ME-IP: 90.112.40.65 Message-ID: <a9fa4b18-0f1c-4d47-92a8-605d234b8ec9@HIDDEN> Date: Wed, 23 Apr 2025 11:34:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <jwvbjt08401.fsf-monnier+emacs@HIDDEN> <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-22 23:34, Stefan Monnier wrote: >>> Yes, as you've seen, the placement can be tricky. There are bootstrap >>> constraints as well as "general design" desires, and they all kind >>> of pull in different directions. >>> I'll take a closer look and come back with a proposal. >> Great. Thank you! > > Sorry for the delay, here's what I came up with. No problem, we're in no rush and certainly have plenty of other things to do in our life. Thank you very much for taking time to work on this! > I added a FIXME about the recursion-breaker which I have a feeling might > not work. I read your FIXME: + ;; FIXME: Does this even work? Won't `cl--type-object' be rebound to + ;; the other object before we get here? IOW wouldn't we need a list + ;; of objects that are in the process of being checked? And while + ;; returning nil breaks the recursion, won't it return a bogus result? However, I don't understand why you think this might not work. I don't see how `cl--type-object' can be rebound while `cl-types-of' is running? Recursion can only occur when calling `cl-typep' to check the type of `cl--type-object', and `cl-types-of' will immediately return nil in that case. Did I miss something? Regarding the bogus result, I chose to ignore types that will never match, resulting in infinite recursion of `cl-types-of'. It's not possible to signal an error here, as that would block subsequent types that have no problem. Perhaps a warning message is missing when recursion is detected on a type? It would probably be much better to detect recursions during type definition and report an error at that point. But I suspect that would be a lot of work. Here is a test case with a recursion: (cl-deftype T1 () "Root type. Check if passed object is a subtype of T1. I.e., if T1 is present in object type parents." `(satisfies ,(lambda (o) (memq 'T1 (gtype-of o))))) (cl-deftype T2 () "Recursive on checking for T1, never match." (declare (parents T1)) `(and T1 (satisfies ,(lambda (o) (equal o '(T2)))))) (defgtype T3 () "Not recursive on T1." (declare (parents T1)) `(satisfies ,(lambda (o) (equal o '(T3))))) ;; T2 will never match, because `cl-types-of' enters in an endless recursion (cl-typep (list 'T2) 'T1) => nil (cl-types-of (list 'T2)) => (cons list sequence t) ;; T3 will match. (cl-typep (list 'T3) 'T1) => (T1 cons list sequence t) (cl-types-of (list 'T3)) => (T3 T1 cons list sequence t) > There's also some stylistic problems with the tests: > > - We shouldn't test the return value of `cl-deftype`: I don't think it's > documented anywhere and I don't think it's good practice to pay > attention to the return value of declarations. You are certainly right. I just wanted to check that `cl-deftype' didn't fail, but there is no `should-no-error'. Would it be better to test for the presence of the type just defined in `cl--type-list'? > - They use `eval` too much. This is because `cl-deftype' is a macro and the doc string of `ert-deftest' suggests to wrap macros in `(eval (quote ...))' to test them. But I must admit that my knowledge of ERT is very limited. Any suggestions for improving the tests would be welcome. David
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 22 Apr 2025 21:34:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 22 17:34:34 2025
Received: from localhost ([127.0.0.1]:50295 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u7LGD-0001z0-3t
for submit <at> debbugs.gnu.org; Tue, 22 Apr 2025 17:34:34 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47960)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u7LGA-0001yl-EE
for 77725 <at> debbugs.gnu.org; Tue, 22 Apr 2025 17:34:31 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E8CA38061C;
Tue, 22 Apr 2025 17:34:24 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745357658;
bh=ybtJIr5wS0JC0z9iLo/hFvp8mdpsl/1EOCRQwSGOsRE=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=KNQsAjy00bFW+zl9nZwjtVO3XSYbaWCok0BDb9BeKdRJQwS67aD2uwZPCp3k5c9bB
2G9n5X0NR+NoZ47yhZipxmPLsuWuCVTFzx+W/mIpVKIsNqzbftzN2Ovp2FxYtUlQ8T
eGZWZZpdrefpyIgcr0x7+Qxccah52+hVf/ziKsIeXY3mN72xqQBvLou3DcsN67AIGD
KNh8Uf8TkwNN63QMLqxDBd9oPtDgrgO5uzHR18p8BAWG+YC05hg59fTcqzYa1ol3Sl
EMzaMaqcNVT+tVrDzbjmJpak6CTjisImivq2yxltc/Z3E3bgZBPPi3TumBvxvRL1Ca
v2Q9vM/IXoodw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DE0FA80387;
Tue, 22 Apr 2025 17:34:18 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B731712022A;
Tue, 22 Apr 2025 17:34:18 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
Message-ID: <jwvy0vrdhhb.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
<jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
<cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN>
Date: Tue, 22 Apr 2025 17:34:17 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.221 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
PROLO_LEO1 0.1 Meta Catches all Leo drug variations so far
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--=-=-=
Content-Type: text/plain
>> Yes, as you've seen, the placement can be tricky. There are bootstrap
>> constraints as well as "general design" desires, and they all kind
>> of pull in different directions.
>> I'll take a closer look and come back with a proposal.
> Great. Thank you!
Sorry for the delay, here's what I came up with.
I added a FIXME about the recursion-breaker which I have a feeling might
not work.
There's also some stylistic problems with the tests:
- We shouldn't test the return value of `cl-deftype`: I don't think it's
documented anywhere and I don't think it's good practice to pay
attention to the return value of declarations.
- They use `eval` too much.
Stefan
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=cl-types.patch
diff --git a/lisp/emacs-lisp/cl-extra.el b/lisp/emacs-lisp/cl-extra.el
index 6390d17a5b7..eb2ad605c8e 100644
--- a/lisp/emacs-lisp/cl-extra.el
+++ b/lisp/emacs-lisp/cl-extra.el
@@ -577,8 +577,8 @@ cl-subseq
,new)))))
(seq-subseq seq start end))
-;;; This isn't a defalias because autoloading defaliases doesn't work
-;;; very well.
+;; This isn't a defalias because autoloading defaliases doesn't work
+;; very well.
;;;###autoload
(defun cl-concatenate (type &rest sequences)
@@ -731,6 +731,213 @@ cl-prettyexpand
(cl-prettyprint form)
(message "")))
+;;; CL type defined via `deftype'.
+
+(defvar cl--type-list nil
+ "List of defined types to lookup for method dispatching.")
+
+;; FIXME: The `cl-deftype-handler' property should arguably be turned
+;; into a field of this struct (but it has performance and
+;; compatibility implications, so let's not make that change for now).
+(cl-defstruct
+ (cl-type-class
+ (:include cl--class)
+ (:noinline t)
+ (:constructor nil)
+ (:constructor cl--type-class-make
+ (name
+ docstring
+ parent-types
+ &aux (parents
+ (mapcar
+ (lambda (type)
+ (or (cl--find-class type)
+ (error "Unknown type: %S" type)))
+ parent-types))))
+ (:copier nil))
+ "Type descriptors for types defined by `cl-deftype'.")
+
+(defun cl--type-p (object)
+ "Return non-nil if OBJECT is a used defined type.
+That is, a type of class `cl-type-class'."
+ (and (symbolp object) (cl-type-class-p (cl--find-class object))))
+
+(defmacro cl--type-parents (name)
+ "Get parents of type with NAME.
+NAME is a symbol representing a type."
+ `(cl--class-allparents (cl--find-class ,name)))
+
+(defun cl--type-children (name)
+ "Get children of the type with NAME.
+NAME is a symbol representing a type.
+Return a possibly empty list of types."
+ (cl-check-type name (satisfies cl--type-p))
+ (let (children)
+ (dolist (elt cl--type-list)
+ (or (eq name elt)
+ (if (memq name (cl--type-parents elt))
+ (push elt children))))
+ children))
+
+;; Keep it for now, for testing.
+(defun cl--type-undefine (name)
+ "Remove the definitions of type with NAME.
+NAME is an unquoted symbol representing a type.
+Signal an error if other types inherit from NAME."
+ (declare-function cl-remprop "cl-extra" (symbol propname))
+ (cl-check-type name (satisfies cl--type-p))
+ (when-let* ((children (and (cl--type-p name)
+ (cl--type-children name))))
+ (error "Type has children: %S" children))
+ (cl-remprop name 'cl--class)
+ (cl-remprop name 'cl-deftype-handler)
+ (setq cl--type-list (delq name cl--type-list)))
+
+;;;###autoload
+(defun cl--type-deftype (name parents &optional docstring)
+ "Generalize type with NAME for method dispatching.
+PARENTS is a list of types NAME is a subtype of, or nil.
+DOCSTRING is an optional documentation string."
+ (let ((oldplist (copy-sequence (symbol-plist name))))
+ (condition-case err
+ (let* ((class (cl--find-class name))
+ (recorded (memq name cl--type-list)))
+ (if (null class)
+ (or (null recorded)
+ (error "Type generalized, but doesn't exist"))
+ (or recorded (error "Type exists, but not generalized"))
+ (or (cl-type-class-p class)
+ (error "Type in another class: %S" (type-of class))))
+ (if (memq name parents)
+ (error "Type in parents: %S" parents))
+ ;; Setup a type descriptor for NAME.
+ (setf (cl--find-class name)
+ (cl--type-class-make name docstring parents))
+ ;; `cl-types-of' iterates through all known types to collect
+ ;; all those an object belongs to, sorted from the most
+ ;; specific type to the more general type. So, keep the
+ ;; global list in this order.
+ (setq cl--type-list
+ (merge-ordered-lists
+ (mapcar (lambda (type)
+ (cl--class-allparents (cl--find-class type)))
+ (if recorded
+ cl--type-list
+ (cons name cl--type-list)))
+ (lambda (_) (error "Invalid dependency graph")))))
+ (error
+ ;; On error restore previous data.
+ (setf (symbol-plist name) oldplist)
+ (error (format "Define %S failed: %s"
+ name (error-message-string err)))))))
+
+(defvar cl--type-object (make-symbol "void"))
+;; Ensure each type satisfies `eql'.
+(defvar cl--type-unique (make-hash-table :test 'equal)
+ "Record an unique value of each type.")
+
+;; FIXME: `cl-types-of' CPU cost is proportional to the number of types
+;; defined with `cl-deftype', so the more popular it gets, the slower
+;; it becomes. And of course, the cost of each type check is
+;; unbounded, so a single "expensive" type can slow everything down
+;; further.
+;;
+;; The usual dispatch is
+;;
+;; (lambda (arg &rest args)
+;; (let ((f (gethash (cl-typeof arg) precomputed-methods-table)))
+;; (if f
+;; (apply f arg args)
+;; ;; Slow case when encountering a new type
+;; ...)))
+;;
+;; where often the most expensive part is `&rest' (which has to
+;; allocate a list for those remaining arguments),
+;;
+;; So we're talking about replacing
+;;
+;; &rest + cl-type-of + gethash + if + apply
+;;
+;; with a function that loops over N types, calling `cl-typep' on each
+;; one of them (`cl-typep' itself being a recursive function that
+;; basically interprets the type language). This is going to slow
+;; down dispatch very significantly for those generic functions that
+;; have a method that dispatches on a user defined type, compared to
+;; those that don't.
+;;
+;; A possible further improvement:
+;;
+;; - based on the PARENTS declaration, create a map from builtin-type
+;; to the set of cl-types that have that builtin-type among their
+;; parents. That presumes some PARENTS include some builtin-types,
+;; obviously otherwise the map will be trivial with all cl-types
+;; associated with the `t' "dummy parent". [ We could even go crazy
+;; and try and guess PARENTS when not provided, by analyzing the
+;; type's definition. ]
+;;
+;; - in `cl-types-of' start by calling `cl-type-of', then use the map
+;; to find which cl-types may need to be checked.
+;;
+;;;###autoload
+(defun cl-types-of (object)
+ "Return the types OBJECT belongs to.
+Return an unique list of types OBJECT belongs to, ordered from the
+most specific type to the most general."
+ ;; Ignore recursive call on the same OBJECT, which can legitimately
+ ;; occur when a parent type is checking whether an object's type is
+ ;; that of one of its children.
+ ;; FIXME: Does this even work? Won't `cl--type-object' be rebound to
+ ;; the other object before we get here? IOW wouldn't we need a list
+ ;; of objects that are in the process of being checked? And while
+ ;; returning nil breaks the recursion, won't it return a bogus result?
+ (unless (eq object cl--type-object)
+ (let ((cl--type-object object)
+ (found (list (cl--type-parents (cl-type-of object)))))
+ ;; Build a DAG of all types OBJECT belongs to.
+ (dolist (type cl--type-list)
+ (and
+ ;; Skip type not defined by `cl-deftype'.
+ (cl-type-class-p (cl--find-class type))
+ ;; If BAR is declared as a parent of FOO and `cl-types-of'
+ ;; has already decided that the value is of type FOO, then we
+ ;; already know BAR will be in the output anyway and there's
+ ;; no point testing BAR. So, skip type already selected as
+ ;; parent of another type, assuming that, most of the time,
+ ;; `assq' will be faster than `cl-typep'.
+ (null (assq type found))
+ ;; If OBJECT is of type, add type and parents to the DAG.
+ (cl-typep object type)
+ ;; (dolist (p (cl--type-parents type))
+ ;; (push (cl--type-parents p) found))
+ ;; Equivalent to the `dolist' above, but faster: avoid to
+ ;; recompute several lists of parents we already know.
+ (let ((pl (cl--type-parents type)))
+ (while pl
+ (push pl found)
+ (setq pl (cdr pl))))
+ ))
+ ;; Compute an ordered list of types from the collected DAG.
+ (setq found (merge-ordered-lists found))
+ ;; Return an unique value of this list of types, which is also
+ ;; the list of specifiers for this type.
+ (with-memoization (gethash found cl--type-unique)
+ found))))
+
+(cl-deftype extended-char () '(and character (not base-char)))
+
+;;;; Method dispatching
+
+(cl-generic-define-generalizer cl--type-generalizer
+ 20 ;; "typeof" < "cl-types-of" < "head" priority
+ (lambda (obj &rest _) `(cl-types-of ,obj))
+ (lambda (tag &rest _) (if (consp tag) tag)))
+
+(cl-defmethod cl-generic-generalizers :extra "cl-types-of" (type)
+ "Support for dispatch on types."
+ (if (cl--type-p type)
+ (list cl--type-generalizer)
+ (cl-call-next-method)))
+
;;; Integration into the online help system.
(eval-when-compile (require 'cl-macs)) ;Explicitly, for cl--find-class.
diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el
index 8de45626bf0..af38f432e84 100644
--- a/lisp/emacs-lisp/cl-generic.el
+++ b/lisp/emacs-lisp/cl-generic.el
@@ -582,6 +582,7 @@ cl-defmethod
(,'declare-function ,name "")
;; We use #' to quote `name' so as to trigger an
;; obsolescence warning when applicable.
+ ;; FIXME: Eval `eql'and `head' thingies!
(cl-generic-define-method #',name ',(nreverse qualifiers) ',args
',call-con ,fun)))))
diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index a966ec5eaf6..1bd3ab55519 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -3786,15 +3786,46 @@ cl--compiler-macro-get
;;;###autoload
(defmacro cl-deftype (name arglist &rest body)
"Define NAME as a new data type.
-The type name can then be used in `cl-typecase', `cl-check-type', etc."
+The type NAME can then be used in `cl-typecase', `cl-check-type', etc,
+and as argument type for dispatching generic function methods.
+
+ARGLIST is a Common Lisp argument list of the sort accepted by
+`cl-defmacro'. BODY forms are evaluated and should return a type
+specifier that is equivalent to the type (see the Info node `(cl) Type
+Predicates' in the GNU Emacs Common Lisp Emulation manual).
+
+If there is a `declare' form in BODY, the spec (parents PARENTS) is
+recognized to specify a list of types NAME is a subtype of. For
+instance:
+
+ (cl-deftype unsigned-byte (&optional bits)
+ \"Unsigned integer.\"
+ (list \\='integer 0 (if (eq bits \\='*) bits (1- (ash 1 bits)))))
+
+ (cl-deftype unsigned-8bits ()
+ \"Unsigned 8-bits integer.\"
+ (declare (parents unsigned-byte))
+ \\='(unsigned-byte 8))
+
+The list of PARENTS types determines the order of methods invocation,
+and missing PARENTS may cause incorrect ordering of methods, while
+extraneous PARENTS may cause use of extraneous methods."
(declare (debug cl-defmacro) (doc-string 3) (indent 2))
- `(cl-eval-when (compile load eval)
- (define-symbol-prop ',name 'cl-deftype-handler
- (cl-function (lambda (&cl-defs ('*) ,@arglist) ,@body)))))
-
-(cl-deftype extended-char () '(and character (not base-char)))
-;; Define fixnum so `cl-typep' recognize it and the type check emitted
-;; by `cl-the' is effective.
+ (pcase-let*
+ ((`(,decls . ,forms) (macroexp-parse-body body))
+ (docstring (if (stringp (car decls))
+ (car decls)
+ (cadr (assq :documentation decls))))
+ (parents (cdr (assq 'parents (cdr (assq 'declare decls))))))
+ (and parents arglist
+ (error "Parents specified, but arglist not empty"))
+ (if docstring (setq forms (cons docstring forms)))
+ `(cl-eval-when (compile load eval)
+ (cl--type-deftype ',name ',parents ,docstring)
+ (define-symbol-prop ',name 'cl-deftype-handler
+ (cl-function
+ (lambda (&cl-defs ('*) ,@arglist)
+ ,@forms))))))
;;; Additional functions that we can now define because we've defined
;;; `cl-defsubst' and `cl-typep'.
diff --git a/test/lisp/emacs-lisp/cl-extra-tests.el b/test/lisp/emacs-lisp/cl-extra-tests.el
index 20d1e532a6f..08198faf28c 100644
--- a/test/lisp/emacs-lisp/cl-extra-tests.el
+++ b/test/lisp/emacs-lisp/cl-extra-tests.el
@@ -348,4 +348,156 @@ cl-extra-test-tailp
(should (cl-tailp l l))
(should (not (cl-tailp '(4 5) l)))))
+(ert-deftest cl-types-test-1 ()
+ "Test types definition and cl-types-of."
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype multiples-of (&optional m)
+ (let ((multiplep (if (eq m '*)
+ #'ignore
+ (lambda (n) (= 0 (% n m))))))
+ `(and integer (satisfies ,multiplep))))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype multiples-of-2 ()
+ '(multiples-of 2))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype multiples-of-3 ()
+ '(multiples-of 3))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype multiples-of-4 ()
+ (declare (parents multiples-of-2))
+ '(and multiples-of-2 (multiples-of 4)))
+ t)))
+
+ ;; Test that (cl-types-of 4) is (multiples-of-4 multiples-of-2 ...)
+ ;; Test that (cl-types-of 6) is (multiples-of-3 multiples-of-2 ...)
+ ;; Test that (cl-types-of 12) is (multiples-of-4 multiples-of-3 multiples-of-2 ...)
+ (should
+ (equal
+ (cl-types-of 2)
+ '( multiples-of-2 fixnum integer number integer-or-marker
+ number-or-marker atom t)))
+
+ (should
+ (equal
+ (cl-types-of 4)
+ '( multiples-of-4 multiples-of-2 fixnum integer number
+ integer-or-marker number-or-marker atom t)
+ ))
+
+ (should
+ (equal
+ (cl-types-of 6)
+ '( multiples-of-3 multiples-of-2 fixnum integer number
+ integer-or-marker number-or-marker atom t)
+ ))
+
+ (should
+ (equal
+ (cl-types-of 12)
+ '( multiples-of-3 multiples-of-4 multiples-of-2 fixnum integer
+ number integer-or-marker number-or-marker atom t)
+ ))
+
+ (should
+ (equal
+ (cl-types-of 5)
+ '(fixnum integer number integer-or-marker number-or-marker atom t)
+ ))
+
+ ;; Cleanup
+ (mapc #'cl--type-undefine cl--type-list)
+
+ )
+
+(ert-deftest cl-types-test-2 ()
+ "Test types definition and dispatch."
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype unsigned-byte (&optional bits)
+ "Unsigned integer."
+ `(integer 0 ,(if (eq bits '*) bits (1- (ash 1 bits)))))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype unsigned-16bits ()
+ "Unsigned 16-bits integer."
+ (declare (parents unsigned-byte))
+ '(unsigned-byte 16))
+ t)))
+
+ (should
+ (functionp
+ (eval
+ '(cl-deftype unsigned-8bits ()
+ "Unsigned 8-bits integer."
+ (declare (parents unsigned-16bits))
+ '(unsigned-byte 8))
+ t)))
+
+ ;; Invalid DAG error
+ (should-error
+ (eval
+ '(cl-deftype unsigned-16bits ()
+ "Unsigned 16-bits integer."
+ (declare (parents unsigned-8bits))
+ '(unsigned-byte 16))
+ t))
+
+ (eval
+ '(cl-defmethod my-foo ((_n unsigned-byte))
+ (format "unsigned"))
+ t)
+
+ (eval
+ '(cl-defmethod my-foo ((_n unsigned-16bits))
+ (format "unsigned 16bits - also %s"
+ (cl-call-next-method)))
+ t)
+
+ (eval
+ '(cl-defmethod my-foo ((_n unsigned-8bits))
+ (format "unsigned 8bits - also %s"
+ (cl-call-next-method)))
+ t)
+
+ (should
+ (equal
+ (my-foo 100)
+ "unsigned 8bits - also unsigned 16bits - also unsigned"
+ ))
+
+ (should
+ (equal
+ (my-foo 256)
+ "unsigned 16bits - also unsigned"
+ ))
+
+ (should
+ (equal
+ (my-foo most-positive-fixnum)
+ "unsigned"
+ ))
+ ;; Cleanup
+ (mapc #'cl--type-undefine cl--type-list)
+ )
+
;;; cl-extra-tests.el ends here
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 19 Apr 2025 15:38:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 19 11:38:19 2025 Received: from localhost ([127.0.0.1]:35579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u6AGl-0000MJ-F0 for submit <at> debbugs.gnu.org; Sat, 19 Apr 2025 11:38:19 -0400 Received: from smtp-19.smtpout.orange.fr ([80.12.242.19]:47579 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u6AGZ-0000L4-Jo for 77725 <at> debbugs.gnu.org; Sat, 19 Apr 2025 11:38:07 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 6AGRuh9R0iSFB6AGUuNr8k; Sat, 19 Apr 2025 17:38:01 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745077081; bh=rXcLNMmyoMbNgiBZwPW7FGg8aOE4rshqAqa5i6IEF+Q=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=By4O3peP3zLEhjnkJOoZGU82L2em8ILeeJwMcNinj0dv0aIANBfmQyxLHRaEbIqmu NN3BrlGyudinzqvjRaJx9oi8oeRxv/fpyi/JNW+7cVEQ0vk8yl7tynJHexGIKE8/JR iHcMgWVuUfURRBl37OE4Y+V5TLSFy0faMvmzuVU9XQ8sR77qW3USrk4MMWh5IN/5My pdgHLFoi304AHEzK3zl1GYjteNiWcRxYQ8uNI7RqMu70K6pfT84DhbqfD+wp2uT62C WCvKvrmVd4H8EOeFg6BtOW/0HHSl5A33uczIIV2jwk+4nmonLxMc/ev8ENt2PvCT3F baXsAKLcxa1Qg== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sat, 19 Apr 2025 17:38:01 +0200 X-ME-IP: 90.112.40.65 Message-ID: <cf8e1302-9e94-4dd0-b90d-daf68c8118f0@HIDDEN> Date: Sat, 19 Apr 2025 17:37:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN> <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN> <jwvbjt08401.fsf-monnier+emacs@HIDDEN> <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvplh8dyme.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-19 16:20, Stefan Monnier wrote: >>> Regarding a possible merge in cl-lib, should cl-types.el be copied at >>> the end of cl-lib, after cl-macs is loaded? If I correctly understand >>> the logic of loading these libs ;-) >> >> I looked into this a bit more, and it turns out that cl-generic >> depends on cl-lib, so the code in cl-types.el that depends on >> cl-generic can't go in cl-lib. This concern the two definitions >> at the end of cl-types.el: > > Yes, as you've seen, the placement can be tricky. There are bootstrap > constraints as well as "general design" desires, and they all kind > of pull in different directions. > I'll take a closer look and come back with a proposal. Great. Thank you! David
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 19 Apr 2025 14:20:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 19 10:20:11 2025
Received: from localhost ([127.0.0.1]:34981 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u693D-0000CL-10
for submit <at> debbugs.gnu.org; Sat, 19 Apr 2025 10:20:11 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36854)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u693A-00006c-Rx
for 77725 <at> debbugs.gnu.org; Sat, 19 Apr 2025 10:20:09 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 60290440BE2;
Sat, 19 Apr 2025 10:20:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1745072401;
bh=XDCtRtijfx7Q5VSV+x1Ibs7+OWhmVRWLTu0tGV0y8Rg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=XpNQnC2Lzy7uePEWDgzbUcGmYzAmfNCEjR6sNcb7KJVLniKKP8iiIYuJ2TQErY2FF
nQxUq5k5hma9VPttUWsaO9FRZXUF4CoMmJCWlhYevETmOiXMte5Bv6OfIyFxJpFFvR
gp0WRcuH6PfhN8lAcHcndctiwdB74k2xKXgsRJwHX4lhQ7CGpOuVEvvSbAeCPPIPi6
kdpSlqHkA27rf6TaUNjstnZQQsIiUri63APt+4FHRbBiDnBfPzDHnJ+W1q066JWpdn
BJ6I7DCKiMCPPyNgK/Kjb1wX3RV7GpXAiL3RRyT7uU44JNyvh1HlOl8T5kL36fpKoM
xyD9dpbrOfFgQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DFF3C440B0D;
Sat, 19 Apr 2025 10:20:01 -0400 (EDT)
Received: from pastel (104-195-239-180.cpe.teksavvy.com [104.195.239.180])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AA7CF12065C;
Sat, 19 Apr 2025 10:20:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
Message-ID: <jwvplh8dyme.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
<jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
<ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN>
<f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN>
Date: Sat, 19 Apr 2025 10:20:00 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.023 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> Regarding a possible merge in cl-lib, should cl-types.el be copied at
>> the end of cl-lib, after cl-macs is loaded?=A0 If I correctly understand
>> the logic of loading these libs ;-)
>
> I looked into this a bit more, and it turns out that cl-generic
> depends on cl-lib, so the code in cl-types.el that depends on
> cl-generic can't go in cl-lib. This concern the two definitions
> at the end of cl-types.el:
Yes, as you've seen, the placement can be tricky. There are bootstrap
constraints as well as "general design" desires, and they all kind
of pull in different directions.
I'll take a closer look and come back with a proposal.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 19 Apr 2025 10:11:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 19 06:11:38 2025 Received: from localhost ([127.0.0.1]:58416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u65Ae-0000FD-UH for submit <at> debbugs.gnu.org; Sat, 19 Apr 2025 06:11:37 -0400 Received: from smtp-22.smtpout.orange.fr ([80.12.242.22]:34475 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u65Ab-0000En-FY for 77725 <at> debbugs.gnu.org; Sat, 19 Apr 2025 06:11:35 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 65ATujIsUaoZo65AWuqEVN; Sat, 19 Apr 2025 12:11:31 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745057491; bh=2S4fkNLAmSMCeC1rkn6KT+r+DwuAUFveY3hGWDbV/gA=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=YJQ+4z/LSMJrT8QtbCY66mTK26yERR2q6q+g6qZhzF0G/BLqefI4zA0TZ+AEmejuG zzXtMY/zFwjV223DHcVIejqvpeA4JkjB5I0s4MTeMZXDCrZ2wBaKeq2Xp/B/vgZcRw q5v3K+O18i9ZL7PQ/ULn9KAfH441FFnKHf6eEgLAaVO+Eh4AHHtIcVVFi26uACkHY7 vrBTkL4D4W08xOiWFf/aElAjz7znkhW/QE+b4RBcLuB5FOxxU3dPocbU6Zgp04FOBy BLbMMliHth/8G/dH/m86rwo0ktiYNGnnOaGfozIGqgmKgtCUhcThVDA2Poq4rpOM2r e7RxZ9W/EgV/g== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sat, 19 Apr 2025 12:11:31 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------4ow9Gxj9UDAJ0uo5JML1T0bX" Message-ID: <f15550a0-62aa-4af5-83e1-8e3c158966cf@HIDDEN> Date: Sat, 19 Apr 2025 12:11:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? From: David Ponce <da_vid@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN> <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN> <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN> <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN> <jwvbjt08401.fsf-monnier+emacs@HIDDEN> <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> Content-Language: fr, en-US In-Reply-To: <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------4ow9Gxj9UDAJ0uo5JML1T0bX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit > Regarding a possible merge in cl-lib, should cl-types.el be copied at > the end of cl-lib, after cl-macs is loaded? If I correctly understand > the logic of loading these libs ;-) I looked into this a bit more, and it turns out that cl-generic depends on cl-lib, so the code in cl-types.el that depends on cl-generic can't go in cl-lib. This concern the two definitions at the end of cl-types.el: (cl-generic-define-generalizer cl--type-generalizer ... ) (cl-defmethod cl-generic-generalizers :extra "cl-types-of" (type) ... ) which could logically go in cl-generic? I attached a slightly updated version of cl-types.el, mainly to check first if a type is of class `cl-type-class' in `cl-types-of', and to use the predicate `cl-type-class-p' simpler than `cl-typep'. Happy Easter weekend :-) --------------4ow9Gxj9UDAJ0uo5JML1T0bX Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el" Content-Disposition: attachment; filename="cl-types.el" Content-Transfer-Encoding: base64 OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBXaWxsIGJlIHJlbW92ZWQgd2hl biBpbmNsdWRlZCBpbiBjbC1saWIuCihyZXF1aXJlICdjbC1saWIpCihldmFsLXdoZW4tY29t cGlsZSAocmVxdWlyZSAnY2wtbWFjcykpICA7Rm9yIGNsLS1maW5kLWNsYXNzLgoKOzsgRXh0 ZW5kIGBjbC1kZWZ0eXBlJyB0byBkZWZpbmUgZGF0YSB0eXBlcyB3aGljaCBhcmUgYWxzbyB2 YWxpZAo7OyBhcmd1bWVudCB0eXBlcyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlv biBtZXRob2RzIChzZWUgYWxzbwo7OyA8aHR0cHM6Ly9kZWJidWdzLmdudS5vcmcvY2dpL2J1 Z3JlcG9ydC5jZ2k/YnVnPTc3NzI1PikuCjs7Cjs7IFRoZSBtYWluIGVudHJ5IHBvaW50cyBh cmU6Cjs7Cjs7IC0gYGNsLWRlZnR5cGUnLCB0aGF0IGRlZmluZXMgbmV3IGRhdGEgdHlwZXMu Cjs7Cjs7IC0gYGNsLXR5cGVzLW9mJywgdGhhdCByZXR1cm5zIHRoZSB0eXBlcyBhbiBvYmpl Y3QgYmVsb25ncyB0by4KCihkZWZ2YXIgY2wtLXR5cGUtbGlzdCBuaWwKICAiTGlzdCBvZiBk ZWZpbmVkIHR5cGVzIHRvIGxvb2t1cCBmb3IgbWV0aG9kIGRpc3BhdGNoaW5nLiIpCgo7OyBG SVhNRTogVGhlIGBjbC1kZWZ0eXBlLWhhbmRsZXInIHByb3BlcnR5IHNob3VsZCBhcmd1YWJs eSBiZSB0dXJuZWQKOzsgaW50byBhIGZpZWxkIG9mIHRoaXMgc3RydWN0IChidXQgaXQgaGFz IHBlcmZvcm1hbmNlIGFuZAo7OyBjb21wYXRpYmlsaXR5IGltcGxpY2F0aW9ucywgc28gbGV0 J3Mgbm90IG1ha2UgdGhhdCBjaGFuZ2UgZm9yIG5vdykuCihjbC1kZWZzdHJ1Y3QKICAgIChj bC10eXBlLWNsYXNzCiAgICAgKDppbmNsdWRlIGNsLS1jbGFzcykKICAgICAoOm5vaW5saW5l IHQpCiAgICAgKDpjb25zdHJ1Y3RvciBuaWwpCiAgICAgKDpjb25zdHJ1Y3RvciBjbC0tdHlw ZS1jbGFzcy1tYWtlCiAgICAgICAgICAgICAgICAgICAobmFtZQogICAgICAgICAgICAgICAg ICAgIGRvY3N0cmluZwogICAgICAgICAgICAgICAgICAgIHBhcmVudC10eXBlcwogICAgICAg ICAgICAgICAgICAgICZhdXggKHBhcmVudHMKICAgICAgICAgICAgICAgICAgICAgICAgICAo bWFwY2FyCiAgICAgICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKHR5cGUpCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKG9yIChjbC0tZmluZC1jbGFzcyB0eXBlKQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZXJyb3IgIlVua25vd24gdHlwZTogJVMi IHR5cGUpKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFyZW50LXR5cGVzKSkpKQog ICAgICg6Y29waWVyIG5pbCkpCiAgIlR5cGUgZGVzY3JpcHRvcnMgZm9yIHR5cGVzIGRlZmlu ZWQgYnkgYGNsLWRlZnR5cGUnLiIpCgooZGVmdW4gY2wtLXR5cGUtcCAob2JqZWN0KQogICJS ZXR1cm4gbm9uLW5pbCBpZiBPQkpFQ1QgaXMgYSB1c2VkIGRlZmluZWQgdHlwZS4KVGhhdCBp cywgYSB0eXBlIG9mIGNsYXNzIGBjbC10eXBlLWNsYXNzJy4iCiAgKGFuZCAoc3ltYm9scCBv YmplY3QpIChjbC10eXBlLWNsYXNzLXAgKGNsLS1maW5kLWNsYXNzIG9iamVjdCkpKSkKCihk ZWZtYWNybyBjbC0tdHlwZS1wYXJlbnRzIChuYW1lKQogICJHZXQgcGFyZW50cyBvZiB0eXBl IHdpdGggTkFNRS4KTkFNRSBpcyBhIHN5bWJvbCByZXByZXNlbnRpbmcgYSB0eXBlLiIKICBg KGNsLS1jbGFzcy1hbGxwYXJlbnRzIChjbC0tZmluZC1jbGFzcyAsbmFtZSkpKQoKKGRlZnVu IGNsLS10eXBlLWNoaWxkcmVuIChuYW1lKQogICJHZXQgY2hpbGRyZW4gb2YgdGhlIHR5cGUg d2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2VudGluZyBhIHR5cGUuClJldHVy biBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlwZXMuIgogIChjbC1jaGVjay10eXBlIG5h bWUgKHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAobGV0IChjaGlsZHJlbikKICAgIChkb2xp c3QgKGVsdCBjbC0tdHlwZS1saXN0KQogICAgICAob3IgKGVxIG5hbWUgZWx0KQogICAgICAg ICAgKGlmIChtZW1xIG5hbWUgKGNsLS10eXBlLXBhcmVudHMgZWx0KSkKICAgICAgICAgICAg ICAocHVzaCBlbHQgY2hpbGRyZW4pKSkpCiAgICBjaGlsZHJlbikpCgooZGVmdW4gY2wtLXR5 cGUtZGFnICgpCiAgIlJldHVybiBhIERBRyBmcm9tIHRoZSBsaXN0IG9mIGRlZmluZWQgdHlw ZXMuIgogIChtYXBjYXIgKGxhbWJkYSAodHlwZSkgKGNsLS1jbGFzcy1hbGxwYXJlbnRzIChj bC0tZmluZC1jbGFzcyB0eXBlKSkpCiAgICAgICAgICBjbC0tdHlwZS1saXN0KSkKCjs7IEtl ZXAgaXQgZm9yIG5vdywgZm9yIHRlc3RpbmcuCihkZWZ1biBjbC0tdHlwZS11bmRlZmluZSAo bmFtZSkKICAiUmVtb3ZlIHRoZSBkZWZpbml0aW9ucyBvZiB0eXBlIHdpdGggTkFNRS4KTkFN RSBpcyBhbiB1bnF1b3RlZCBzeW1ib2wgcmVwcmVzZW50aW5nIGEgdHlwZS4KU2lnbmFsIGFu IGVycm9yIGlmIG90aGVyIHR5cGVzIGluaGVyaXQgZnJvbSBOQU1FLiIKICAoZGVjbGFyZS1m dW5jdGlvbiBjbC1yZW1wcm9wICJjbC1leHRyYSIgKHN5bWJvbCBwcm9wbmFtZSkpCiAgKGNs LWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXApKQogICh3aGVuLWxldCog KChjaGlsZHJlbiAoYW5kIChjbC0tdHlwZS1wIG5hbWUpCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKGNsLS10eXBlLWNoaWxkcmVuIG5hbWUpKSkpCiAgICAoZXJyb3IgIlR5cGUg aGFzIGNoaWxkcmVuOiAlUyIgY2hpbGRyZW4pKQogIChjbC1yZW1wcm9wIG5hbWUgJ2NsLS1j bGFzcykKICAoY2wtcmVtcHJvcCBuYW1lICdjbC1kZWZ0eXBlLWhhbmRsZXIpCiAgKHNldHEg Y2wtLXR5cGUtbGlzdCAoZGVscSBuYW1lIGNsLS10eXBlLWxpc3QpKSkKCihkZWZ1biBjbC0t dHlwZS1nZW5lcmFsaXplIChuYW1lIHBhcmVudHMgJm9wdGlvbmFsIGRvY3N0cmluZykKICAi R2VuZXJhbGl6ZSB0eXBlIHdpdGggTkFNRSBmb3IgbWV0aG9kIGRpc3BhdGNoaW5nLgpQQVJF TlRTIGlzIGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlzIGEgc3VidHlwZSBvZiwgb3IgbmlsLgpE T0NTVFJJTkcgaXMgYW4gb3B0aW9uYWwgZG9jdW1lbnRhdGlvbiBzdHJpbmcuIgogIChsZXQg KChvbGR0bGlzdCAoY29weS1zZXF1ZW5jZSBjbC0tdHlwZS1saXN0KSkKICAgICAgICAob2xk cGxpc3QgKGNvcHktc2VxdWVuY2UgKHN5bWJvbC1wbGlzdCBuYW1lKSkpKQogICAgKGNvbmRp dGlvbi1jYXNlIGVycgogICAgICAgIChsZXQqICgoY2xhc3MgKGNsLS1maW5kLWNsYXNzIG5h bWUpKQogICAgICAgICAgICAgICAocmVjb3JkZWQgKG1lbXEgbmFtZSBjbC0tdHlwZS1saXN0 KSkpCiAgICAgICAgICAoaWYgKG51bGwgY2xhc3MpCiAgICAgICAgICAgICAgKG9yIChudWxs IHJlY29yZGVkKQogICAgICAgICAgICAgICAgICAoZXJyb3IgIlR5cGUgZ2VuZXJhbGl6ZWQs IGJ1dCBkb2Vzbid0IGV4aXN0IikpCiAgICAgICAgICAgIChvciByZWNvcmRlZCAoZXJyb3Ig IlR5cGUgZXhpc3RzLCBidXQgbm90IGdlbmVyYWxpemVkIikpCiAgICAgICAgICAgIChvciAo Y2wtdHlwZS1jbGFzcy1wIGNsYXNzKQogICAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGlu IGFub3RoZXIgY2xhc3M6ICVTIiAodHlwZS1vZiBjbGFzcykpKSkKICAgICAgICAgIChpZiAo bWVtcSBuYW1lIHBhcmVudHMpCiAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGluIHBhcmVu dHM6ICVTIiBwYXJlbnRzKSkKICAgICAgICAgIDs7IFNldHVwIGEgdHlwZSBkZXNjcmlwdG9y IGZvciBOQU1FLgogICAgICAgICAgKHNldGYgKGNsLS1maW5kLWNsYXNzIG5hbWUpCiAgICAg ICAgICAgICAgICAoY2wtLXR5cGUtY2xhc3MtbWFrZSBuYW1lIGRvY3N0cmluZyBwYXJlbnRz KSkKICAgICAgICAgIDs7IFJlY29yZCBuZXcgdHlwZSBub3cgdG8gaW5jbHVkZSBpdHMgZGVw ZW5kZW5jeSBpbiB0aGUgREFHLgogICAgICAgICAgKG9yIHJlY29yZGVkIChwdXNoIG5hbWUg Y2wtLXR5cGUtbGlzdCkpCiAgICAgICAgICA7OyBgY2wtdHlwZXMtb2YnIGl0ZXJhdGVzIHRo cm91Z2ggYWxsIGtub3duIHR5cGVzIHRvIGNvbGxlY3QKICAgICAgICAgIDs7IGFsbCB0aG9z ZSBhbiBvYmplY3QgYmVsb25ncyB0bywgc29ydGVkIGZyb20gdGhlIG1vc3QKICAgICAgICAg IDs7IHNwZWNpZmljIHR5cGUgdG8gdGhlIG1vcmUgZ2VuZXJhbCB0eXBlLiAgU28sIGtlZXAg dGhlCiAgICAgICAgICA7OyBnbG9iYWwgbGlzdCBpbiB0aGlzIG9yZGVyLgogICAgICAgICAg KHNldHEgY2wtLXR5cGUtbGlzdAogICAgICAgICAgICAgICAgKG1lcmdlLW9yZGVyZWQtbGlz dHMKICAgICAgICAgICAgICAgICAoY2wtLXR5cGUtZGFnKQogICAgICAgICAgICAgICAgIChs YW1iZGEgKF8pIChlcnJvciAiSW52YWxpZCBkZXBlbmRlbmN5IGdyYXBoIikpKSkpCiAgICAg IChlcnJvcgogICAgICAgOzsgT24gZXJyb3IgcmVzdG9yZSBwcmV2aW91cyBkYXRhLgogICAg ICAgKHNldHEgY2wtLXR5cGUtbGlzdCBvbGR0bGlzdCkKICAgICAgIChzZXRmIChzeW1ib2wt cGxpc3QgbmFtZSkgb2xkcGxpc3QpCiAgICAgICAoZXJyb3IgKGZvcm1hdCAiRGVmaW5lICVT IGZhaWxlZDogJXMiCiAgICAgICAgICAgICAgICAgICAgICBuYW1lIChlcnJvci1tZXNzYWdl LXN0cmluZyBlcnIpKSkpKSkpCgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gY2wtZGVmdHlw ZTIgKG5hbWUgYXJnbGlzdCAmcmVzdCBib2R5KQogICJEZWZpbmUgTkFNRSBhcyBhIG5ldyBk YXRhIHR5cGUuClRoZSB0eXBlIE5BTUUgY2FuIHRoZW4gYmUgdXNlZCBpbiBgY2wtdHlwZWNh c2UnLCBgY2wtY2hlY2stdHlwZScsIGV0YywKYW5kIGFzIGFyZ3VtZW50IHR5cGUgZm9yIGRp c3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KCkFSR0xJU1QgaXMgYSBDb21t b24gTGlzcCBhcmd1bWVudCBsaXN0IG9mIHRoZSBzb3J0IGFjY2VwdGVkIGJ5CmBjbC1kZWZt YWNybycuICBCT0RZIGZvcm1zIGFyZSBldmFsdWF0ZWQgYW5kIHNob3VsZCByZXR1cm4gYSB0 eXBlCnNwZWNpZmllciB0aGF0IGlzIGVxdWl2YWxlbnQgdG8gdGhlIHR5cGUgKHNlZSB0aGUg SW5mbyBub2RlIGAoY2wpIFR5cGUKUHJlZGljYXRlcycgaW4gdGhlIEdOVSBFbWFjcyBDb21t b24gTGlzcCBFbXVsYXRpb24gbWFudWFsKS4KCklmIHRoZXJlIGlzIGEgYGRlY2xhcmUnIGZv cm0gaW4gQk9EWSwgdGhlIHNwZWMgKHBhcmVudHMgUEFSRU5UUykgaXMKcmVjb2duaXplZCB0 byBzcGVjaWZ5IGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlzIGEgc3VidHlwZSBvZi4gIEZvcgpp bnN0YW5jZToKCiAgKGNsLWRlZnR5cGUyIHVuc2lnbmVkLWJ5dGUgKCZvcHRpb25hbCBiaXRz KQogICAgXCJVbnNpZ25lZCBpbnRlZ2VyLlwiCiAgICAobGlzdCBcXD0naW50ZWdlciAwIChp ZiAoZXEgYml0cyBcXD0nKikgYml0cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQoKICAoY2wtZGVm dHlwZTIgdW5zaWduZWQtOGJpdHMgKCkKICAgIFwiVW5zaWduZWQgOC1iaXRzIGludGVnZXIu XCIKICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2lnbmVkLWJ5dGUpKQogICAgXFw9Jyh1bnNp Z25lZC1ieXRlIDgpKQoKVGhlIGxpc3Qgb2YgUEFSRU5UUyB0eXBlcyBkZXRlcm1pbmVzIHRo ZSBvcmRlciBvZiBtZXRob2RzIGludm9jYXRpb24sCmFuZCBtaXNzaW5nIFBBUkVOVFMgbWF5 IGNhdXNlIGluY29ycmVjdCBvcmRlcmluZyBvZiBtZXRob2RzLCB3aGlsZQpleHRyYW5lb3Vz IFBBUkVOVFMgbWF5IGNhdXNlIHVzZSBvZiBleHRyYW5lb3VzIG1ldGhvZHMuIgogIChkZWNs YXJlIChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1zdHJpbmcgMykgKGluZGVudCAyKSkKICAo cGNhc2UtbGV0KgogICAgICAoKGAoLGRlY2xzIC4gLGZvcm1zKSAobWFjcm9leHAtcGFyc2Ut Ym9keSBib2R5KSkKICAgICAgIChkb2NzdHJpbmcgKGlmIChzdHJpbmdwIChjYXIgZGVjbHMp KQogICAgICAgICAgICAgICAgICAgICAgKGNhciBkZWNscykKICAgICAgICAgICAgICAgICAg ICAoY2FkciAoYXNzcSA6ZG9jdW1lbnRhdGlvbiBkZWNscykpKSkKICAgICAgIChwYXJlbnRz IChjZHIgKGFzc3EgJ3BhcmVudHMgKGNkciAoYXNzcSAnZGVjbGFyZSBkZWNscykpKSkpKQog ICAgKGFuZCBwYXJlbnRzIGFyZ2xpc3QKICAgICAgICAgKGVycm9yICJQYXJlbnRzIHNwZWNp ZmllZCwgYnV0IGFyZ2xpc3Qgbm90IGVtcHR5IikpCiAgICAoaWYgZG9jc3RyaW5nIChzZXRx IGZvcm1zIChjb25zIGRvY3N0cmluZyBmb3JtcykpKQogICAgYChjbC1ldmFsLXdoZW4gKGNv bXBpbGUgbG9hZCBldmFsKQogICAgICAgKGNsLS10eXBlLWdlbmVyYWxpemUgJyxuYW1lICcs cGFyZW50cyAsZG9jc3RyaW5nKQogICAgICAgKGRlZmluZS1zeW1ib2wtcHJvcCAnLG5hbWUg J2NsLWRlZnR5cGUtaGFuZGxlcgogICAgICAgICAgICAgICAgICAgICAgICAgICAoY2wtZnVu Y3Rpb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKCZjbC1kZWZzICgn KikgLEBhcmdsaXN0KQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAsQGZvcm1zKSkp KSkpCgo7OyBJbnRlcm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVuZGxlc3MgcmVjdXJzaW9u IGluICdjbC10eXBlLW9mJy4KKGRlZnZhciBjbC0tdHlwZS1vYmplY3QgKG1ha2Utc3ltYm9s ICJ2b2lkIikpCjs7IEVuc3VyZSBlYWNoIHR5cGUgc2F0aXNmaWVzIGBlcWwnLgooZGVmdmFy IGNsLS10eXBlLXVuaXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVhbCkKICAiUmVj b3JkIGFuIHVuaXF1ZSB2YWx1ZSBvZiBlYWNoIHR5cGUuIikKCjs7IEZJWE1FOiBgY2wtdHlw ZXMtb2YnIENQVSBjb3N0IGlzIHByb3BvcnRpb25hbCB0byB0aGUgbnVtYmVyIG9mIHR5cGVz Cjs7IGRlZmluZWQgd2l0aCBgY2wtZGVmdHlwZScsIHNvIHRoZSBtb3JlIHBvcHVsYXIgaXQg Z2V0cywgdGhlIHNsb3dlcgo7OyBpdCBiZWNvbWVzLiAgQW5kIG9mIGNvdXJzZSwgdGhlIGNv c3Qgb2YgZWFjaCB0eXBlIGNoZWNrIGlzCjs7IHVuYm91bmRlZCwgc28gYSBzaW5nbGUgImV4 cGVuc2l2ZSIgdHlwZSBjYW4gc2xvdyBldmVyeXRoaW5nIGRvd24KOzsgZnVydGhlci4KOzsK OzsgVGhlIHVzdWFsIGRpc3BhdGNoIGlzCjs7Cjs7ICAgKGxhbWJkYSAoYXJnICZyZXN0IGFy Z3MpCjs7ICAgICAobGV0ICgoZiAoZ2V0aGFzaCAoY2wtdHlwZW9mIGFyZykgcHJlY29tcHV0 ZWQtbWV0aG9kcy10YWJsZSkpKQo7OyAgICAgICAoaWYgZgo7OyAgICAgICAgICAgKGFwcGx5 IGYgYXJnIGFyZ3MpCjs7ICAgICAgICAgOzsgU2xvdyBjYXNlIHdoZW4gZW5jb3VudGVyaW5n IGEgbmV3IHR5cGUKOzsgICAgICAgICAuLi4pKSkKOzsKOzsgd2hlcmUgb2Z0ZW4gdGhlIG1v c3QgZXhwZW5zaXZlIHBhcnQgaXMgYCZyZXN0JyAod2hpY2ggaGFzIHRvCjs7IGFsbG9jYXRl IGEgbGlzdCBmb3IgdGhvc2UgcmVtYWluaW5nIGFyZ3VtZW50cyksCjs7Cjs7IFNvIHdlJ3Jl IHRhbGtpbmcgYWJvdXQgcmVwbGFjaW5nCjs7Cjs7ICAgJnJlc3QgKyBjbC10eXBlLW9mICsg Z2V0aGFzaCArIGlmICsgYXBwbHkKOzsKOzsgd2l0aCBhIGZ1bmN0aW9uIHRoYXQgbG9vcHMg b3ZlciBOIHR5cGVzLCBjYWxsaW5nIGBjbC10eXBlcCcgb24gZWFjaAo7OyBvbmUgb2YgdGhl bSAoYGNsLXR5cGVwJyBpdHNlbGYgYmVpbmcgYSByZWN1cnNpdmUgZnVuY3Rpb24gdGhhdAo7 OyBiYXNpY2FsbHkgaW50ZXJwcmV0cyB0aGUgdHlwZSBsYW5ndWFnZSkuICBUaGlzIGlzIGdv aW5nIHRvIHNsb3cKOzsgZG93biBkaXNwYXRjaCB2ZXJ5IHNpZ25pZmljYW50bHkgZm9yIHRo b3NlIGdlbmVyaWMgZnVuY3Rpb25zIHRoYXQKOzsgaGF2ZSBhIG1ldGhvZCB0aGF0IGRpc3Bh dGNoZXMgb24gYSB1c2VyIGRlZmluZWQgdHlwZSwgY29tcGFyZWQgdG8KOzsgdGhvc2UgdGhh dCBkb24ndC4KOzsKOzsgQSBwb3NzaWJsZSBmdXJ0aGVyIGltcHJvdmVtZW50Ogo7Owo7OyAt IGJhc2VkIG9uIHRoZSBQQVJFTlRTIGRlY2xhcmF0aW9uLCBjcmVhdGUgYSBtYXAgZnJvbSBi dWlsdGluLXR5cGUKOzsgICB0byB0aGUgc2V0IG9mIGNsLXR5cGVzIHRoYXQgaGF2ZSB0aGF0 IGJ1aWx0aW4tdHlwZSBhbW9uZyB0aGVpcgo7OyAgIHBhcmVudHMuICBUaGF0IHByZXN1bWVz IHNvbWUgUEFSRU5UUyBpbmNsdWRlIHNvbWUgYnVpbHRpbi10eXBlcywKOzsgICBvYnZpb3Vz bHkgb3RoZXJ3aXNlIHRoZSBtYXAgd2lsbCBiZSB0cml2aWFsIHdpdGggYWxsIGNsLXR5cGVz Cjs7ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBgdCcgImR1bW15IHBhcmVudCIuICBbIFdlIGNv dWxkIGV2ZW4gZ28gY3JhenkKOzsgICBhbmQgdHJ5IGFuZCBndWVzcyBQQVJFTlRTIHdoZW4g bm90IHByb3ZpZGVkLCBieSBhbmFseXppbmcgdGhlCjs7ICAgdHlwZSdzIGRlZmluaXRpb24u IF0KOzsKOzsgLSBpbiBgY2wtdHlwZXMtb2YnIHN0YXJ0IGJ5IGNhbGxpbmcgYGNsLXR5cGUt b2YnLCB0aGVuIHVzZSB0aGUgbWFwCjs7ICAgdG8gZmluZCB3aGljaCBjbC10eXBlcyBtYXkg bmVlZCB0byBiZSBjaGVja2VkLgo7OwooZGVmdW4gY2wtdHlwZXMtb2YgKG9iamVjdCkKICAi UmV0dXJuIHRoZSB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0by4KUmV0dXJuIGFuIHVuaXF1ZSBs aXN0IG9mIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCm1vc3Qg c3BlY2lmaWMgdHlwZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIKICA7OyBJZ25vcmUgcmVjdXJz aXZlIGNhbGwgb24gdGhlIHNhbWUgT0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5CiAg Ozsgb2NjdXIgd2hlbiBhIHBhcmVudCB0eXBlIGlzIGNoZWNraW5nIHdoZXRoZXIgYW4gb2Jq ZWN0J3MgdHlwZSBpcwogIDs7IHRoYXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJlbi4KICAodW5s ZXNzIChlcSBvYmplY3QgY2wtLXR5cGUtb2JqZWN0KQogICAgKGxldCAoKGNsLS10eXBlLW9i amVjdCBvYmplY3QpCiAgICAgICAgICAoZm91bmQgKGxpc3QgKGNsLS10eXBlLXBhcmVudHMg KGNsLXR5cGUtb2Ygb2JqZWN0KSkpKSkKICAgICAgOzsgQnVpbGQgYSBEQUcgb2YgYWxsIHR5 cGVzIE9CSkVDVCBiZWxvbmdzIHRvLgogICAgICAoZG9saXN0ICh0eXBlIGNsLS10eXBlLWxp c3QpCiAgICAgICAgKGFuZAogICAgICAgICA7OyBTa2lwIHR5cGUgbm90IGRlZmluZWQgYnkg YGNsLWRlZnR5cGUnLgogICAgICAgICAoY2wtdHlwZS1jbGFzcy1wIChjbC0tZmluZC1jbGFz cyB0eXBlKSkKICAgICAgICAgOzsgSWYgQkFSIGlzIGRlY2xhcmVkIGFzIGEgcGFyZW50IG9m IEZPTyBhbmQgYGNsLXR5cGVzLW9mJwogICAgICAgICA7OyBoYXMgYWxyZWFkeSBkZWNpZGVk IHRoYXQgdGhlIHZhbHVlIGlzIG9mIHR5cGUgRk9PLCB0aGVuIHdlCiAgICAgICAgIDs7IGFs cmVhZHkga25vdyBCQVIgd2lsbCBiZSBpbiB0aGUgb3V0cHV0IGFueXdheSBhbmQgdGhlcmUn cwogICAgICAgICA7OyBubyBwb2ludCB0ZXN0aW5nIEJBUi4gIFNvLCBza2lwIHR5cGUgYWxy ZWFkeSBzZWxlY3RlZCBhcwogICAgICAgICA7OyBwYXJlbnQgb2YgYW5vdGhlciB0eXBlLCBh c3N1bWluZyB0aGF0LCBtb3N0IG9mIHRoZSB0aW1lLAogICAgICAgICA7OyBgYXNzcScgd2ls bCBiZSBmYXN0ZXIgdGhhbiBgY2wtdHlwZXAnLgogICAgICAgICAobnVsbCAoYXNzcSB0eXBl IGZvdW5kKSkKICAgICAgICAgOzsgSWYgT0JKRUNUIGlzIG9mIHR5cGUsIGFkZCB0eXBlIGFu ZCBwYXJlbnRzIHRvIHRoZSBEQUcuCiAgICAgICAgIChjbC10eXBlcCBvYmplY3QgdHlwZSkK ICAgICAgICAgOzsgKGRvbGlzdCAocCAoY2wtLXR5cGUtcGFyZW50cyB0eXBlKSkKICAgICAg ICAgOzsgICAocHVzaCAoY2wtLXR5cGUtcGFyZW50cyBwKSBmb3VuZCkpCiAgICAgICAgIDs7 IEVxdWl2YWxlbnQgdG8gdGhlIGBkb2xpc3QnIGFib3ZlLCBidXQgZmFzdGVyOiBhdm9pZCB0 bwogICAgICAgICA7OyByZWNvbXB1dGUgc2V2ZXJhbCBsaXN0cyBvZiBwYXJlbnRzIHdlIGFs cmVhZHkga25vdy4KICAgICAgICAgKGxldCAoKHBsIChjbC0tdHlwZS1wYXJlbnRzIHR5cGUp KSkKICAgICAgICAgICAod2hpbGUgcGwKICAgICAgICAgICAgIChwdXNoIHBsIGZvdW5kKQog ICAgICAgICAgICAgKHNldHEgcGwgKGNkciBwbCkpKSkKICAgICAgICAgKSkKICAgICAgOzsg Q29tcHV0ZSBhbiBvcmRlcmVkIGxpc3Qgb2YgdHlwZXMgZnJvbSB0aGUgY29sbGVjdGVkIERB Ry4KICAgICAgKHNldHEgZm91bmQgKG1lcmdlLW9yZGVyZWQtbGlzdHMgZm91bmQpKQogICAg ICA7OyBSZXR1cm4gYW4gdW5pcXVlIHZhbHVlIG9mIHRoaXMgbGlzdCBvZiB0eXBlcywgd2hp Y2ggaXMgYWxzbwogICAgICA7OyB0aGUgbGlzdCBvZiBzcGVjaWZpZXJzIGZvciB0aGlzIHR5 cGUuCiAgICAgICh3aXRoLW1lbW9pemF0aW9uIChnZXRoYXNoIGZvdW5kIGNsLS10eXBlLXVu aXF1ZSkKICAgICAgICBmb3VuZCkpKSkKCjs7OyBNZXRob2QgZGlzcGF0Y2hpbmcKOzsKKGNs LWdlbmVyaWMtZGVmaW5lLWdlbmVyYWxpemVyIGNsLS10eXBlLWdlbmVyYWxpemVyCiAgMjAg OzsgInR5cGVvZiIgPCAiY2wtdHlwZXMtb2YiIDwgImhlYWQiIHByaW9yaXR5CiAgKGxhbWJk YSAob2JqICZyZXN0IF8pIGAoY2wtdHlwZXMtb2YgLG9iaikpCiAgKGxhbWJkYSAodGFnICZy ZXN0IF8pIChpZiAoY29uc3AgdGFnKSB0YWcpKSkKCihjbC1kZWZtZXRob2QgY2wtZ2VuZXJp Yy1nZW5lcmFsaXplcnMgOmV4dHJhICJjbC10eXBlcy1vZiIgKHR5cGUpCiAgIlN1cHBvcnQg Zm9yIGRpc3BhdGNoIG9uIHR5cGVzLiIKICAoaWYgKGNsLS10eXBlLXAgdHlwZSkKICAgICAg KGxpc3QgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIpCiAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkp KQoKKHByb3ZpZGUgJ2NsLXR5cGVzKQoKOzs7IGNsLXR5cGVzLmVsIGVuZHMgaGVyZQo= --------------4ow9Gxj9UDAJ0uo5JML1T0bX--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 18 Apr 2025 15:07:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 18 11:07:19 2025 Received: from localhost ([127.0.0.1]:52460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u5nJC-00009O-SY for submit <at> debbugs.gnu.org; Fri, 18 Apr 2025 11:07:19 -0400 Received: from [80.12.242.23] (port=42707 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u5nIt-0007yS-FT for 77725 <at> debbugs.gnu.org; Fri, 18 Apr 2025 11:07:10 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 5nF4uuSNM4rbB5nF7uiQrQ; Fri, 18 Apr 2025 17:03:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1744988584; bh=HkgjYspVaLkQfXp74jCtnjW76YTINsxJlnVmE/eUXxI=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=LB4FVUqQ6y2ifapK8EMcJGoPVrjkbwQFh7wqWJJQoU2J8LN0yaYm0p2S9dUXOOjvF 28T+aSymDPA7aKXgjujl0rw5/GARSwntZPZc1elGmpVJyn7oJkiO3L/UVhYptkid0U sg5YRW1Z5rENVdogVJl5PH75YQz4KztIUzvgIlpQbcM9HHDHFVo3vp34tpjCtDylMg o4Enn2/qaNqtkrDmrMP3IdFb7Sj0Nw07sqO14DwlKJFefzNCFwGqrRnKpeYasm/CnW 3kn/1q4kazWxWjB7Hx76e0rp94b8IGPlIZIRSYax25l+MsxkqFpZwPktQTtjil5XJK Lc3lbICXj42Hw== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Fri, 18 Apr 2025 17:03:04 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------oQNclki4E7GToXoSUh4I3NAy" Message-ID: <ebfd6ed4-a0d2-4655-a5ef-07fc74852b58@HIDDEN> Date: Fri, 18 Apr 2025 17:02:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN> <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN> <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN> <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN> <jwvbjt08401.fsf-monnier+emacs@HIDDEN> <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwv8qnyi281.fsf-monnier+emacs@HIDDEN> X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Stefan, >> (merge-ordered-lists '((test test))) >> => (test test) > > Ah, right, `merge-ordered-lists` presumes the arg lists are already sane. > So, I kept the test to ensure `name' is not in `parents'. Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [80.12.242.23 listed in bl.score.senderscore.com] 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [80.12.242.23 listed in sa-trusted.bondedsender.org] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [80.12.242.23 listed in list.dnswl.org] 0.0 T_SPF_TEMPERROR SPF: test of record failed (temperror) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (da_vid[at]orange.fr) 0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror) 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 SPOOFED_FREEMAIL_NO_RDNS From SPOOFED_FREEMAIL and no rDNS X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.3 (/) This is a multi-part message in MIME format. --------------oQNclki4E7GToXoSUh4I3NAy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Stefan, >> (merge-ordered-lists '((test test))) >> => (test test) > > Ah, right, `merge-ordered-lists` presumes the arg lists are already sane. > So, I kept the test to ensure `name' is not in `parents'. >>> The converse is that if we have already decided that the value is *not* >>> for type BAR, then it can't be of type FOO either, so there's no point >>> testing FOO. >> Wouldn't this involve calculating the parents of all the types traversed, >> instead of just the matching ones? > > I wasn't describing an algorithm, just a principle that can be used > within an algorithm. Depending on the algorithm you use it can be used > in different ways. With your current loop, I don't think you can make > much use of it. > > But I think what we could do fairly easily is the following: > > - based on the PARENTS declaration, create a map from builtin-type to > the set of cl-types that have that builtin-type among their parents. > That presumes some PARENTS include some builtin-types, obviously > otherwise the map will be trivial with all cl-types associated with > the `t` "dummy parent". > [ We could even go crazy and try and guess PARENTS when not provided, > by analyzing the type's definition. ] > - in `cl-types-of` start by calling `cl-type-of`, then use the map to > find which cl-types may need to be checked. > > But let's keep this for later. I was thinking about the exact same idea not long ago :-) I totally agree with your analysis. I noted this point in a FIXME. Please, find attached a new version of cl-types.el: - I've divided the code more logically between the `cl-deftype2' macro and the `cl--type-generalize' function. - In `cl-types-of', I implemented the idea of not testing a type already selected as a parent of a type already selected :-) - I tried to add some comments to the not so obvious code. I also wrote a first try at a test file, cl-types-tests.el, also attached: - It includes your proposed tests with multiples-of... All tests pass for me :-) Please let me know if something is not correct, need more work, etc. Regarding a possible merge in cl-lib, should cl-types.el be copied at the end of cl-lib, after cl-macs is loaded? If I correctly understand the logic of loading these libs ;-) Thank you! David --------------oQNclki4E7GToXoSUh4I3NAy Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types-tests.el" Content-Disposition: attachment; filename="cl-types-tests.el" Content-Transfer-Encoding: base64 Ozs7IFRlc3QgYGNsLXR5cGVkZWYnIC0qLSBsZXhpY2FsLWJpbmRpbmc6IHQ7IC0qLQo7Owoo cmVxdWlyZSAnZXJ0KQoocmVxdWlyZSAnY2wtdHlwZXMpCgooZXJ0LWRlZnRlc3QgY2wtdHlw ZXMtdGVzdC0xICgpCiAgIlRlc3QgdHlwZXMgZGVmaW5pdGlvbiBhbmQgY2wtdHlwZXMtb2Yu IgogIAogIChzaG91bGQKICAgKGZ1bmN0aW9ucAogICAgKGV2YWwKICAgICAnKGNsLWRlZnR5 cGUyIG11bHRpcGxlcy1vZiAoJm9wdGlvbmFsIG0pCiAgICAgICAgKGxldCAoKG11bHRpcGxl cCAoaWYgKGVxIG0gJyopCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIydpZ25vcmUK ICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAobikgKD0gMCAoJSBuIG0pKSkp KSkgIAogICAgICAgICAgYChhbmQgaW50ZWdlciAoc2F0aXNmaWVzICxtdWx0aXBsZXApKSkp CiAgICAgbGV4aWNhbC1iaW5kaW5nCiAgICAgKSkpCiAgCiAgKHNob3VsZAogICAoZnVuY3Rp b25wCiAgICAoZXZhbAogICAgICcoY2wtZGVmdHlwZTIgbXVsdGlwbGVzLW9mLTIgKCkKICAg ICAgICAnKG11bHRpcGxlcy1vZiAyKSkKICAgICBsZXhpY2FsLWJpbmRpbmcKICAgICApKSkK ICAKICAoc2hvdWxkCiAgIChmdW5jdGlvbnAKICAgIChldmFsCiAgICAgJyhjbC1kZWZ0eXBl MiBtdWx0aXBsZXMtb2YtMyAoKQogICAgICAgICcobXVsdGlwbGVzLW9mIDMpKQogICAgIGxl eGljYWwtYmluZGluZwogICAgICkpKQogIAogIChzaG91bGQKICAgKGZ1bmN0aW9ucAogICAg KGV2YWwKICAgICAnKGNsLWRlZnR5cGUyIG11bHRpcGxlcy1vZi00ICgpCiAgICAgICAgKGRl Y2xhcmUgKHBhcmVudHMgbXVsdGlwbGVzLW9mLTIpKQogICAgICAgICcoYW5kIG11bHRpcGxl cy1vZi0yIChtdWx0aXBsZXMtb2YgNCkpKQogICAgIGxleGljYWwtYmluZGluZwogICAgICkp KQoKICA7OyBUZXN0IHRoYXQgKGNsLXR5cGVzLW9mIDQpIGlzIChtdWx0aXBsZXMtb2YtNCBt dWx0aXBsZXMtb2YtMiAuLi4pCiAgOzsgVGVzdCB0aGF0IChjbC10eXBlcy1vZiA2KSBpcyAo bXVsdGlwbGVzLW9mLTMgbXVsdGlwbGVzLW9mLTIgLi4uKQogIDs7IFRlc3QgdGhhdCAoY2wt dHlwZXMtb2YgMTIpIGlzIChtdWx0aXBsZXMtb2YtNCBtdWx0aXBsZXMtb2YtMyBtdWx0aXBs ZXMtb2YtMiAuLi4pCiAgKHNob3VsZAogICAoZXF1YWwKICAgIChjbC10eXBlcy1vZiAyKQog ICAgJyggbXVsdGlwbGVzLW9mLTIgZml4bnVtIGludGVnZXIgbnVtYmVyIGludGVnZXItb3It bWFya2VyCiAgICAgICBudW1iZXItb3ItbWFya2VyIGF0b20gdCkKICAgICkpCgogIChzaG91 bGQKICAgKGVxdWFsCiAgICAoY2wtdHlwZXMtb2YgNCkKICAgICcoIG11bHRpcGxlcy1vZi00 IG11bHRpcGxlcy1vZi0yIGZpeG51bSBpbnRlZ2VyIG51bWJlcgogICAgICAgaW50ZWdlci1v ci1tYXJrZXIgbnVtYmVyLW9yLW1hcmtlciBhdG9tIHQpCiAgICApKQoKICAoc2hvdWxkCiAg IChlcXVhbAogICAgKGNsLXR5cGVzLW9mIDYpCiAgICAnKCBtdWx0aXBsZXMtb2YtMyBtdWx0 aXBsZXMtb2YtMiBmaXhudW0gaW50ZWdlciBudW1iZXIKICAgICAgIGludGVnZXItb3ItbWFy a2VyIG51bWJlci1vci1tYXJrZXIgYXRvbSB0KQogICAgKSkKCiAgKHNob3VsZAogICAoZXF1 YWwKICAgIChjbC10eXBlcy1vZiAxMikKICAgICcoIG11bHRpcGxlcy1vZi0zIG11bHRpcGxl cy1vZi00IG11bHRpcGxlcy1vZi0yIGZpeG51bSBpbnRlZ2VyCiAgICAgICBudW1iZXIgaW50 ZWdlci1vci1tYXJrZXIgbnVtYmVyLW9yLW1hcmtlciBhdG9tIHQpCiAgICApKQoKICAoc2hv dWxkCiAgIChlcXVhbAogICAgKGNsLXR5cGVzLW9mIDUpCiAgICAnKGZpeG51bSBpbnRlZ2Vy IG51bWJlciBpbnRlZ2VyLW9yLW1hcmtlciBudW1iZXItb3ItbWFya2VyIGF0b20gdCkKICAg ICkpCgogIDs7IENsZWFudXAKICAobWFwYyAjJ2NsLS10eXBlLXVuZGVmaW5lIGNsLS10eXBl LWxpc3QpCgogICkKCihlcnQtZGVmdGVzdCBjbC10eXBlcy10ZXN0LTIgKCkKICAiVGVzdCB0 eXBlcyBkZWZpbml0aW9uIGFuZCBkaXNwYXRjaC4iCgogIChzaG91bGQKICAgKGZ1bmN0aW9u cAogICAgKGV2YWwKICAgICAnKGNsLWRlZnR5cGUyIHVuc2lnbmVkLWJ5dGUgKCZvcHRpb25h bCBiaXRzKQogICAgICAgICJVbnNpZ25lZCBpbnRlZ2VyLiIKICAgICAgICBgKGludGVnZXIg MCAsKGlmIChlcSBiaXRzICcqKSBiaXRzICgxLSAoYXNoIDEgYml0cykpKSkpCiAgICAgbGV4 aWNhbC1iaW5kaW5nCiAgICAgKSkpCgogIChzaG91bGQKICAgKGZ1bmN0aW9ucAogICAgKGV2 YWwKICAgICAnKGNsLWRlZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICAgICJVbnNp Z25lZCAxNi1iaXRzIGludGVnZXIuIgogICAgICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2ln bmVkLWJ5dGUpKQogICAgICAgICcodW5zaWduZWQtYnl0ZSAxNikpCiAgICAgbGV4aWNhbC1i aW5kaW5nCiAgICAgKSkpCgogIChzaG91bGQKICAgKGZ1bmN0aW9ucAogICAgKGV2YWwKICAg ICAnKGNsLWRlZnR5cGUyIHVuc2lnbmVkLThiaXRzICgpCiAgICAgICAgIlVuc2lnbmVkIDgt Yml0cyBpbnRlZ2VyLiIKICAgICAgICAoZGVjbGFyZSAocGFyZW50cyB1bnNpZ25lZC0xNmJp dHMpKQogICAgICAgICcodW5zaWduZWQtYnl0ZSA4KSkKICAgICBsZXhpY2FsLWJpbmRpbmcK ICAgICApKSkKCiAgOzsgSW52YWxpZCBEQUcgZXJyb3IKICAoc2hvdWxkLWVycm9yCiAgIChl dmFsCiAgICAnKGNsLWRlZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICAgIlVuc2ln bmVkIDE2LWJpdHMgaW50ZWdlci4iCiAgICAgICAoZGVjbGFyZSAocGFyZW50cyB1bnNpZ25l ZC04Yml0cykpCiAgICAgICAnKHVuc2lnbmVkLWJ5dGUgMTYpKQogICAgbGV4aWNhbC1iaW5k aW5nCiAgICApKQoKICAoZXZhbAogICAnKGNsLWRlZm1ldGhvZCBteS1mb28gKChfbiB1bnNp Z25lZC1ieXRlKSkKICAgICAgKGZvcm1hdCAidW5zaWduZWQiKSkKICAgbGV4aWNhbC1iaW5k aW5nCiAgICkKCiAgKGV2YWwKICAgJyhjbC1kZWZtZXRob2QgbXktZm9vICgoX24gdW5zaWdu ZWQtMTZiaXRzKSkKICAgICAgKGZvcm1hdCAidW5zaWduZWQgMTZiaXRzIC0gYWxzbyAlcyIK ICAgICAgICAgICAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQogICBsZXhpY2FsLWJpbmRp bmcKICAgKQoKICAoZXZhbAogICAnKGNsLWRlZm1ldGhvZCBteS1mb28gKChfbiB1bnNpZ25l ZC04Yml0cykpCiAgICAgIChmb3JtYXQgInVuc2lnbmVkIDhiaXRzIC0gYWxzbyAlcyIKICAg ICAgICAgICAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQogICBsZXhpY2FsLWJpbmRpbmcK ICAgKQogIAogIChzaG91bGQKICAgKGVxdWFsCiAgICAobXktZm9vIDEwMCkKICAgICJ1bnNp Z25lZCA4Yml0cyAtIGFsc28gdW5zaWduZWQgMTZiaXRzIC0gYWxzbyB1bnNpZ25lZCIKICAg ICkpCgogIChzaG91bGQKICAgKGVxdWFsCiAgICAobXktZm9vIDI1NikKICAgICJ1bnNpZ25l ZCAxNmJpdHMgLSBhbHNvIHVuc2lnbmVkIgogICAgKSkKCiAgKHNob3VsZAogICAoZXF1YWwK ICAgIChteS1mb28gbW9zdC1wb3NpdGl2ZS1maXhudW0pCiAgICAidW5zaWduZWQiCiAgICAp KQogIAogIDs7IENsZWFudXAKICAobWFwYyAjJ2NsLS10eXBlLXVuZGVmaW5lIGNsLS10eXBl LWxpc3QpCiAgKQoKKHByb3ZpZGUgJ2NsLXR5cGVzLXRlc3RzKQoKOzs7IGNsLXR5cGVzLXRl c3RzLmVsIGVuZHMgaGVyZQo= --------------oQNclki4E7GToXoSUh4I3NAy Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el" Content-Disposition: attachment; filename="cl-types.el" Content-Transfer-Encoding: base64 OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBXaWxsIGJlIHJlbW92ZWQgd2hl biBpbmNsdWRlZCBpbiBjbC1saWIuCihyZXF1aXJlICdjbC1saWIpCihldmFsLXdoZW4tY29t cGlsZSAocmVxdWlyZSAnY2wtbWFjcykpICA7Rm9yIGNsLS1maW5kLWNsYXNzLgoKOzsgRXh0 ZW5kIGBjbC1kZWZ0eXBlJyB0byBkZWZpbmUgZGF0YSB0eXBlcyB3aGljaCBhcmUgYWxzbyB2 YWxpZAo7OyBhcmd1bWVudCB0eXBlcyBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlv biBtZXRob2RzIChzZWUgYWxzbwo7OyA8aHR0cHM6Ly9kZWJidWdzLmdudS5vcmcvY2dpL2J1 Z3JlcG9ydC5jZ2k/YnVnPTc3NzI1PikuCjs7Cjs7IFRoZSBtYWluIGVudHJ5IHBvaW50cyBh cmU6Cjs7Cjs7IC0gYGNsLWRlZnR5cGUnLCB0aGF0IGRlZmluZXMgbmV3IGRhdGEgdHlwZXMu Cjs7Cjs7IC0gYGNsLXR5cGVzLW9mJywgdGhhdCByZXR1cm5zIHRoZSB0eXBlcyBhbiBvYmpl Y3QgYmVsb25ncyB0by4KCihkZWZ2YXIgY2wtLXR5cGUtbGlzdCBuaWwKICAiTGlzdCBvZiBk ZWZpbmVkIHR5cGVzIHRvIGxvb2t1cCBmb3IgbWV0aG9kIGRpc3BhdGNoaW5nLiIpCgo7OyBG SVhNRTogVGhlIGBjbC1kZWZ0eXBlLWhhbmRsZXInIHByb3BlcnR5IHNob3VsZCBhcmd1YWJs eSBiZSB0dXJuZWQKOzsgaW50byBhIGZpZWxkIG9mIHRoaXMgc3RydWN0IChidXQgaXQgaGFz IHBlcmZvcm1hbmNlIGFuZAo7OyBjb21wYXRpYmlsaXR5IGltcGxpY2F0aW9ucywgc28gbGV0 J3Mgbm90IG1ha2UgdGhhdCBjaGFuZ2UgZm9yIG5vdykuCihjbC1kZWZzdHJ1Y3QKICAgIChj bC10eXBlLWNsYXNzCiAgICAgKDppbmNsdWRlIGNsLS1jbGFzcykKICAgICAoOm5vaW5saW5l IHQpCiAgICAgKDpjb25zdHJ1Y3RvciBuaWwpCiAgICAgKDpjb25zdHJ1Y3RvciBjbC0tdHlw ZS1jbGFzcy1tYWtlCiAgICAgICAgICAgICAgICAgICAobmFtZQogICAgICAgICAgICAgICAg ICAgIGRvY3N0cmluZwogICAgICAgICAgICAgICAgICAgIHBhcmVudC10eXBlcwogICAgICAg ICAgICAgICAgICAgICZhdXggKHBhcmVudHMKICAgICAgICAgICAgICAgICAgICAgICAgICAo bWFwY2FyCiAgICAgICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKHR5cGUpCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKG9yIChjbC0tZmluZC1jbGFzcyB0eXBlKQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZXJyb3IgIlVua25vd24gdHlwZTogJVMi IHR5cGUpKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFyZW50LXR5cGVzKSkpKQog ICAgICg6Y29waWVyIG5pbCkpCiAgIlR5cGUgZGVzY3JpcHRvcnMgZm9yIHR5cGVzIGRlZmlu ZWQgYnkgYGNsLWRlZnR5cGUnLiIpCgooZGVmdW4gY2wtLXR5cGUtcCAob2JqZWN0KQogICJS ZXR1cm4gbm9uLW5pbCBpZiBPQkpFQ1QgaXMgYSB1c2VkIGRlZmluZWQgdHlwZS4KVGhhdCBp cywgYSB0eXBlIG9mIGNsYXNzIGBjbC10eXBlLWNsYXNzJy4iCiAgKGFuZCAoc3ltYm9scCBv YmplY3QpCiAgICAgICAoY2wtdHlwZXAgKGNsLS1maW5kLWNsYXNzIG9iamVjdCkgJ2NsLXR5 cGUtY2xhc3MpKSkKCihkZWZtYWNybyBjbC0tdHlwZS1wYXJlbnRzIChuYW1lKQogICJHZXQg cGFyZW50cyBvZiB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhIHN5bWJvbCByZXByZXNlbnRp bmcgYSB0eXBlLiIKICBgKGNsLS1jbGFzcy1hbGxwYXJlbnRzIChjbC0tZmluZC1jbGFzcyAs bmFtZSkpKQoKKGRlZnVuIGNsLS10eXBlLWNoaWxkcmVuIChuYW1lKQogICJHZXQgY2hpbGRy ZW4gb2YgdGhlIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2VudGlu ZyBhIHR5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlwZXMuIgogIChj bC1jaGVjay10eXBlIG5hbWUgKHNhdGlzZmllcyBjbC0tdHlwZS1wKSkKICAobGV0IChjaGls ZHJlbikKICAgIChkb2xpc3QgKGVsdCBjbC0tdHlwZS1saXN0KQogICAgICAob3IgKGVxIG5h bWUgZWx0KQogICAgICAgICAgKGlmIChtZW1xIG5hbWUgKGNsLS10eXBlLXBhcmVudHMgZWx0 KSkKICAgICAgICAgICAgICAocHVzaCBlbHQgY2hpbGRyZW4pKSkpCiAgICBjaGlsZHJlbikp CgooZGVmdW4gY2wtLXR5cGUtZGFnICgpCiAgIlJldHVybiBhIERBRyBmcm9tIHRoZSBsaXN0 IG9mIGRlZmluZWQgdHlwZXMuIgogIChtYXBjYXIgKGxhbWJkYSAodHlwZSkgKGNsLS1jbGFz cy1hbGxwYXJlbnRzIChjbC0tZmluZC1jbGFzcyB0eXBlKSkpCiAgICAgICAgICBjbC0tdHlw ZS1saXN0KSkKCjs7IEtlZXAgaXQgZm9yIG5vdywgZm9yIHRlc3RpbmcuCihkZWZ1biBjbC0t dHlwZS11bmRlZmluZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBkZWZpbml0aW9ucyBvZiB0eXBl IHdpdGggTkFNRS4KTkFNRSBpcyBhbiB1bnF1b3RlZCBzeW1ib2wgcmVwcmVzZW50aW5nIGEg dHlwZS4KU2lnbmFsIGFuIGVycm9yIGlmIG90aGVyIHR5cGVzIGluaGVyaXQgZnJvbSBOQU1F LiIKICAoZGVjbGFyZS1mdW5jdGlvbiBjbC1yZW1wcm9wICJjbC1leHRyYSIgKHN5bWJvbCBw cm9wbmFtZSkpCiAgKGNsLWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXAp KQogICh3aGVuLWxldCogKChjaGlsZHJlbiAoYW5kIChjbC0tdHlwZS1wIG5hbWUpCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKGNsLS10eXBlLWNoaWxkcmVuIG5hbWUpKSkpCiAg ICAoZXJyb3IgIlR5cGUgaGFzIGNoaWxkcmVuOiAlUyIgY2hpbGRyZW4pKQogIChjbC1yZW1w cm9wIG5hbWUgJ2NsLS1jbGFzcykKICAoY2wtcmVtcHJvcCBuYW1lICdjbC1kZWZ0eXBlLWhh bmRsZXIpCiAgKHNldHEgY2wtLXR5cGUtbGlzdCAoZGVscSBuYW1lIGNsLS10eXBlLWxpc3Qp KSkKCihkZWZ1biBjbC0tdHlwZS1nZW5lcmFsaXplIChuYW1lIHBhcmVudHMgJm9wdGlvbmFs IGRvY3N0cmluZykKICAiR2VuZXJhbGl6ZSB0eXBlIHdpdGggTkFNRSBmb3IgbWV0aG9kIGRp c3BhdGNoaW5nLgpQQVJFTlRTIGlzIGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlzIGEgc3VidHlw ZSBvZiwgb3IgbmlsLgpET0NTVFJJTkcgaXMgYW4gb3B0aW9uYWwgZG9jdW1lbnRhdGlvbiBz dHJpbmcuIgogIChsZXQgKChvbGR0bGlzdCAoY29weS1zZXF1ZW5jZSBjbC0tdHlwZS1saXN0 KSkKICAgICAgICAob2xkcGxpc3QgKGNvcHktc2VxdWVuY2UgKHN5bWJvbC1wbGlzdCBuYW1l KSkpKQogICAgKGNvbmRpdGlvbi1jYXNlIGVycgogICAgICAgIChsZXQqICgoY2xhc3MgKGNs LS1maW5kLWNsYXNzIG5hbWUpKQogICAgICAgICAgICAgICAocmVjb3JkZWQgKG1lbXEgbmFt ZSBjbC0tdHlwZS1saXN0KSkpCiAgICAgICAgICAoaWYgKG51bGwgY2xhc3MpCiAgICAgICAg ICAgICAgKG9yIChudWxsIHJlY29yZGVkKQogICAgICAgICAgICAgICAgICAoZXJyb3IgIlR5 cGUgZ2VuZXJhbGl6ZWQsIGJ1dCBkb2Vzbid0IGV4aXN0IikpCiAgICAgICAgICAgIChvciBy ZWNvcmRlZCAoZXJyb3IgIlR5cGUgZXhpc3RzLCBidXQgbm90IGdlbmVyYWxpemVkIikpCiAg ICAgICAgICAgIChvciAoY2wtdHlwZXAgY2xhc3MgJ2NsLXR5cGUtY2xhc3MpCiAgICAgICAg ICAgICAgICAoZXJyb3IgIlR5cGUgaW4gYW5vdGhlciBjbGFzczogJVMiICh0eXBlLW9mIGNs YXNzKSkpKQogICAgICAgICAgKGlmIChtZW1xIG5hbWUgcGFyZW50cykKICAgICAgICAgICAg ICAoZXJyb3IgIlR5cGUgaW4gcGFyZW50czogJVMiIHBhcmVudHMpKQogICAgICAgICAgOzsg U2V0dXAgYSB0eXBlIGRlc2NyaXB0b3IgZm9yIE5BTUUuCiAgICAgICAgICAoc2V0ZiAoY2wt LWZpbmQtY2xhc3MgbmFtZSkKICAgICAgICAgICAgICAgIChjbC0tdHlwZS1jbGFzcy1tYWtl IG5hbWUgZG9jc3RyaW5nIHBhcmVudHMpKQogICAgICAgICAgOzsgUmVjb3JkIG5ldyB0eXBl IG5vdyB0byBpbmNsdWRlIGl0cyBkZXBlbmRlbmN5IGluIHRoZSBEQUcuCiAgICAgICAgICAo b3IgcmVjb3JkZWQgKHB1c2ggbmFtZSBjbC0tdHlwZS1saXN0KSkKICAgICAgICAgIDs7IGBj bC10eXBlcy1vZicgaXRlcmF0ZXMgdGhyb3VnaCBhbGwga25vd24gdHlwZXMgdG8gY29sbGVj dAogICAgICAgICAgOzsgYWxsIHRob3NlIGFuIG9iamVjdCBiZWxvbmdzIHRvLCBzb3J0ZWQg ZnJvbSB0aGUgbW9zdAogICAgICAgICAgOzsgc3BlY2lmaWMgdHlwZSB0byB0aGUgbW9yZSBn ZW5lcmFsIHR5cGUuICBTbywga2VlcCB0aGUKICAgICAgICAgIDs7IGdsb2JhbCBsaXN0IGlu IHRoaXMgb3JkZXIuCiAgICAgICAgICAoc2V0cSBjbC0tdHlwZS1saXN0CiAgICAgICAgICAg ICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cwogICAgICAgICAgICAgICAgIChjbC0tdHlwZS1k YWcpCiAgICAgICAgICAgICAgICAgKGxhbWJkYSAoXykgKGVycm9yICJJbnZhbGlkIGRlcGVu ZGVuY3kgZ3JhcGgiKSkpKSkKICAgICAgKGVycm9yCiAgICAgICA7OyBPbiBlcnJvciByZXN0 b3JlIHByZXZpb3VzIGRhdGEuCiAgICAgICAoc2V0cSBjbC0tdHlwZS1saXN0IG9sZHRsaXN0 KQogICAgICAgKHNldGYgKHN5bWJvbC1wbGlzdCBuYW1lKSBvbGRwbGlzdCkKICAgICAgIChl cnJvciAoZm9ybWF0ICJEZWZpbmUgJVMgZmFpbGVkOiAlcyIKICAgICAgICAgICAgICAgICAg ICAgIG5hbWUgKGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVycikpKSkpKSkKCjs7OyMjI2F1dG9s b2FkCihkZWZtYWNybyBjbC1kZWZ0eXBlMiAobmFtZSBhcmdsaXN0ICZyZXN0IGJvZHkpCiAg IkRlZmluZSBOQU1FIGFzIGEgbmV3IGRhdGEgdHlwZS4KVGhlIHR5cGUgTkFNRSBjYW4gdGhl biBiZSB1c2VkIGluIGBjbC10eXBlY2FzZScsIGBjbC1jaGVjay10eXBlJywgZXRjLAphbmQg YXMgYXJndW1lbnQgdHlwZSBmb3IgZGlzcGF0Y2hpbmcgZ2VuZXJpYyBmdW5jdGlvbiBtZXRo b2RzLgoKQVJHTElTVCBpcyBhIENvbW1vbiBMaXNwIGFyZ3VtZW50IGxpc3Qgb2YgdGhlIHNv cnQgYWNjZXB0ZWQgYnkKYGNsLWRlZm1hY3JvJy4gIEJPRFkgZm9ybXMgYXJlIGV2YWx1YXRl ZCBhbmQgc2hvdWxkIHJldHVybiBhIHR5cGUKc3BlY2lmaWVyIHRoYXQgaXMgZXF1aXZhbGVu dCB0byB0aGUgdHlwZSAoc2VlIHRoZSBJbmZvIG5vZGUgYChjbCkgVHlwZQpQcmVkaWNhdGVz JyBpbiB0aGUgR05VIEVtYWNzIENvbW1vbiBMaXNwIEVtdWxhdGlvbiBtYW51YWwpLgoKSWYg dGhlcmUgaXMgYSBgZGVjbGFyZScgZm9ybSBpbiBCT0RZLCB0aGUgc3BlYyAocGFyZW50cyBQ QVJFTlRTKSBpcwpyZWNvZ25pemVkIHRvIHNwZWNpZnkgYSBsaXN0IG9mIHR5cGVzIE5BTUUg aXMgYSBzdWJ0eXBlIG9mLiAgRm9yCmluc3RhbmNlOgoKICAoY2wtZGVmdHlwZTIgdW5zaWdu ZWQtYnl0ZSAoJm9wdGlvbmFsIGJpdHMpCiAgICBcIlVuc2lnbmVkIGludGVnZXIuXCIKICAg IChsaXN0IFxcPSdpbnRlZ2VyIDAgKGlmIChlcSBiaXRzIFxcPScqKSBiaXRzICgxLSAoYXNo IDEgYml0cykpKSkpCgogIChjbC1kZWZ0eXBlMiB1bnNpZ25lZC04Yml0cyAoKQogICAgXCJV bnNpZ25lZCA4LWJpdHMgaW50ZWdlci5cIgogICAgKGRlY2xhcmUgKHBhcmVudHMgdW5zaWdu ZWQtYnl0ZSkpCiAgICBcXD0nKHVuc2lnbmVkLWJ5dGUgOCkpCgpUaGUgbGlzdCBvZiBQQVJF TlRTIHR5cGVzIGRldGVybWluZXMgdGhlIG9yZGVyIG9mIG1ldGhvZHMgaW52b2NhdGlvbiwK YW5kIG1pc3NpbmcgUEFSRU5UUyBtYXkgY2F1c2UgaW5jb3JyZWN0IG9yZGVyaW5nIG9mIG1l dGhvZHMsIHdoaWxlCmV4dHJhbmVvdXMgUEFSRU5UUyBtYXkgY2F1c2UgdXNlIG9mIGV4dHJh bmVvdXMgbWV0aG9kcy4iCiAgKGRlY2xhcmUgKGRlYnVnIGNsLWRlZm1hY3JvKSAoZG9jLXN0 cmluZyAzKSAoaW5kZW50IDIpKQogIChwY2FzZS1sZXQqCiAgICAgICgoYCgsZGVjbHMgLiAs Zm9ybXMpIChtYWNyb2V4cC1wYXJzZS1ib2R5IGJvZHkpKQogICAgICAgKGRvY3N0cmluZyAo aWYgKHN0cmluZ3AgKGNhciBkZWNscykpCiAgICAgICAgICAgICAgICAgICAgICAoY2FyIGRl Y2xzKQogICAgICAgICAgICAgICAgICAgIChjYWRyIChhc3NxIDpkb2N1bWVudGF0aW9uIGRl Y2xzKSkpKQogICAgICAgKHBhcmVudHMgKGNkciAoYXNzcSAncGFyZW50cyAoY2RyIChhc3Nx ICdkZWNsYXJlIGRlY2xzKSkpKSkpCiAgICAoYW5kIHBhcmVudHMgYXJnbGlzdAogICAgICAg ICAoZXJyb3IgIlBhcmVudHMgc3BlY2lmaWVkLCBidXQgYXJnbGlzdCBub3QgZW1wdHkiKSkK ICAgIChpZiBkb2NzdHJpbmcgKHNldHEgZm9ybXMgKGNvbnMgZG9jc3RyaW5nIGZvcm1zKSkp CiAgICBgKGNsLWV2YWwtd2hlbiAoY29tcGlsZSBsb2FkIGV2YWwpCiAgICAgICAoY2wtLXR5 cGUtZ2VuZXJhbGl6ZSAnLG5hbWUgJyxwYXJlbnRzICxkb2NzdHJpbmcpCiAgICAgICAoZGVm aW5lLXN5bWJvbC1wcm9wICcsbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVyCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIChjbC1mdW5jdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgKGxhbWJkYSAoJmNsLWRlZnMgKCcqKSAsQGFyZ2xpc3QpCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICxAZm9ybXMpKSkpKSkKCjs7IEludGVybmFsIGRhdGEgdXNlZCB0byBk ZXRlY3QgZW5kbGVzcyByZWN1cnNpb24gaW4gJ2NsLXR5cGUtb2YnLgooZGVmdmFyIGNsLS10 eXBlLW9iamVjdCAobWFrZS1zeW1ib2wgInZvaWQiKSkKOzsgRW5zdXJlIGVhY2ggdHlwZSBz YXRpc2ZpZXMgYGVxbCcuCihkZWZ2YXIgY2wtLXR5cGUtdW5pcXVlIChtYWtlLWhhc2gtdGFi bGUgOnRlc3QgJ2VxdWFsKQogICJSZWNvcmQgYW4gdW5pcXVlIHZhbHVlIG9mIGVhY2ggdHlw ZS4iKQoKOzsgRklYTUU6IGBjbC10eXBlcy1vZicgQ1BVIGNvc3QgaXMgcHJvcG9ydGlvbmFs IHRvIHRoZSBudW1iZXIgb2YgdHlwZXMKOzsgZGVmaW5lZCB3aXRoIGBjbC1kZWZ0eXBlJywg c28gdGhlIG1vcmUgcG9wdWxhciBpdCBnZXRzLCB0aGUgc2xvd2VyCjs7IGl0IGJlY29tZXMu ICBBbmQgb2YgY291cnNlLCB0aGUgY29zdCBvZiBlYWNoIHR5cGUgY2hlY2sgaXMKOzsgdW5i b3VuZGVkLCBzbyBhIHNpbmdsZSAiZXhwZW5zaXZlIiB0eXBlIGNhbiBzbG93IGV2ZXJ5dGhp bmcgZG93bgo7OyBmdXJ0aGVyLgo7Owo7OyBUaGUgdXN1YWwgZGlzcGF0Y2ggaXMKOzsKOzsg ICAobGFtYmRhIChhcmcgJnJlc3QgYXJncykKOzsgICAgIChsZXQgKChmIChnZXRoYXNoIChj bC10eXBlb2YgYXJnKSBwcmVjb21wdXRlZC1tZXRob2RzLXRhYmxlKSkpCjs7ICAgICAgIChp ZiBmCjs7ICAgICAgICAgICAoYXBwbHkgZiBhcmcgYXJncykKOzsgICAgICAgICA7OyBTbG93 IGNhc2Ugd2hlbiBlbmNvdW50ZXJpbmcgYSBuZXcgdHlwZQo7OyAgICAgICAgIC4uLikpKQo7 Owo7OyB3aGVyZSBvZnRlbiB0aGUgbW9zdCBleHBlbnNpdmUgcGFydCBpcyBgJnJlc3QnICh3 aGljaCBoYXMgdG8KOzsgYWxsb2NhdGUgYSBsaXN0IGZvciB0aG9zZSByZW1haW5pbmcgYXJn dW1lbnRzKSwKOzsKOzsgU28gd2UncmUgdGFsa2luZyBhYm91dCByZXBsYWNpbmcKOzsKOzsg ICAmcmVzdCArIGNsLXR5cGUtb2YgKyBnZXRoYXNoICsgaWYgKyBhcHBseQo7Owo7OyB3aXRo IGEgZnVuY3Rpb24gdGhhdCBsb29wcyBvdmVyIE4gdHlwZXMsIGNhbGxpbmcgYGNsLXR5cGVw JyBvbiBlYWNoCjs7IG9uZSBvZiB0aGVtIChgY2wtdHlwZXAnIGl0c2VsZiBiZWluZyBhIHJl Y3Vyc2l2ZSBmdW5jdGlvbiB0aGF0Cjs7IGJhc2ljYWxseSBpbnRlcnByZXRzIHRoZSB0eXBl IGxhbmd1YWdlKS4gIFRoaXMgaXMgZ29pbmcgdG8gc2xvdwo7OyBkb3duIGRpc3BhdGNoIHZl cnkgc2lnbmlmaWNhbnRseSBmb3IgdGhvc2UgZ2VuZXJpYyBmdW5jdGlvbnMgdGhhdAo7OyBo YXZlIGEgbWV0aG9kIHRoYXQgZGlzcGF0Y2hlcyBvbiBhIHVzZXIgZGVmaW5lZCB0eXBlLCBj b21wYXJlZCB0bwo7OyB0aG9zZSB0aGF0IGRvbid0Lgo7Owo7OyBBIHBvc3NpYmxlIGZ1cnRo ZXIgaW1wcm92ZW1lbnQ6Cjs7Cjs7IC0gYmFzZWQgb24gdGhlIFBBUkVOVFMgZGVjbGFyYXRp b24sIGNyZWF0ZSBhIG1hcCBmcm9tIGJ1aWx0aW4tdHlwZQo7OyAgIHRvIHRoZSBzZXQgb2Yg Y2wtdHlwZXMgdGhhdCBoYXZlIHRoYXQgYnVpbHRpbi10eXBlIGFtb25nIHRoZWlyCjs7ICAg cGFyZW50cy4gIFRoYXQgcHJlc3VtZXMgc29tZSBQQVJFTlRTIGluY2x1ZGUgc29tZSBidWls dGluLXR5cGVzLAo7OyAgIG9idmlvdXNseSBvdGhlcndpc2UgdGhlIG1hcCB3aWxsIGJlIHRy aXZpYWwgd2l0aCBhbGwgY2wtdHlwZXMKOzsgICBhc3NvY2lhdGVkIHdpdGggdGhlIGB0JyAi ZHVtbXkgcGFyZW50Ii4gIFsgV2UgY291bGQgZXZlbiBnbyBjcmF6eQo7OyAgIGFuZCB0cnkg YW5kIGd1ZXNzIFBBUkVOVFMgd2hlbiBub3QgcHJvdmlkZWQsIGJ5IGFuYWx5emluZyB0aGUK OzsgICB0eXBlJ3MgZGVmaW5pdGlvbi4gXQo7Owo7OyAtIGluIGBjbC10eXBlcy1vZicgc3Rh cnQgYnkgY2FsbGluZyBgY2wtdHlwZS1vZicsIHRoZW4gdXNlIHRoZSBtYXAKOzsgICB0byBm aW5kIHdoaWNoIGNsLXR5cGVzIG1heSBuZWVkIHRvIGJlIGNoZWNrZWQuCjs7CihkZWZ1biBj bC10eXBlcy1vZiAob2JqZWN0KQogICJSZXR1cm4gdGhlIHR5cGVzIE9CSkVDVCBiZWxvbmdz IHRvLgpSZXR1cm4gYW4gdW5pcXVlIGxpc3Qgb2YgdHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8s IG9yZGVyZWQgZnJvbSB0aGUKbW9zdCBzcGVjaWZpYyB0eXBlIHRvIHRoZSBtb3N0IGdlbmVy YWwuIgogIDs7IElnbm9yZSByZWN1cnNpdmUgY2FsbCBvbiB0aGUgc2FtZSBPQkpFQ1QsIHdo aWNoIGNhbiBsZWdpdGltYXRlbHkKICA7OyBvY2N1ciB3aGVuIGEgcGFyZW50IHR5cGUgaXMg Y2hlY2tpbmcgd2hldGhlciBhbiBvYmplY3QncyB0eXBlIGlzCiAgOzsgdGhhdCBvZiBvbmUg b2YgaXRzIGNoaWxkcmVuLgogICh1bmxlc3MgKGVxIG9iamVjdCBjbC0tdHlwZS1vYmplY3Qp CiAgICAobGV0ICgoY2wtLXR5cGUtb2JqZWN0IG9iamVjdCkKICAgICAgICAgIChmb3VuZCAo bGlzdCAoY2wtLXR5cGUtcGFyZW50cyAoY2wtdHlwZS1vZiBvYmplY3QpKSkpKQogICAgICA7 OyBCdWlsZCBhIERBRyBvZiBhbGwgdHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8uCiAgICAgIChk b2xpc3QgKHR5cGUgY2wtLXR5cGUtbGlzdCkKICAgICAgICAoYW5kCgkgOzsgSWYgQkFSIGlz IGRlY2xhcmVkIGFzIGEgcGFyZW50IG9mIEZPTyBhbmQgYGNsLXR5cGVzLW9mJwoJIDs7IGhh cyBhbHJlYWR5IGRlY2lkZWQgdGhhdCB0aGUgdmFsdWUgaXMgb2YgdHlwZSBGT08sIHRoZW4g d2UKCSA7OyBhbHJlYWR5IGtub3cgQkFSIHdpbGwgYmUgaW4gdGhlIG91dHB1dCBhbnl3YXkg YW5kIHRoZXJlJ3MKCSA7OyBubyBwb2ludCB0ZXN0aW5nIEJBUi4gIFNvLCBza2lwIHR5cGUg YWxyZWFkeSBzZWxlY3RlZCBhcwoJIDs7IHBhcmVudCBvZiBhbm90aGVyIHR5cGUsIGFzc3Vt aW5nIHRoYXQsIG1vc3Qgb2YgdGhlIHRpbWUsCgkgOzsgYGFzc3EnIHdpbGwgYmUgZmFzdGVy IHRoYW4gYGNsLXR5cGVwJy4KICAgICAgICAgKG51bGwgKGFzc3EgdHlwZSBmb3VuZCkpCiAg ICAgICAgIDs7IFNraXAgdHlwZSBub3QgZGVmaW5lZCBieSBgY2wtZGVmdHlwZScuCiAgICAg ICAgIChjbC10eXBlcCAoY2wtLWZpbmQtY2xhc3MgdHlwZSkgJ2NsLXR5cGUtY2xhc3MpCiAg ICAgICAgIDs7IElmIE9CSkVDVCBpcyBvZiB0eXBlLCBhZGQgdHlwZSBhbmQgcGFyZW50cyB0 byB0aGUgREFHLgogICAgICAgICAoY2wtdHlwZXAgb2JqZWN0IHR5cGUpCgkgOzsgKGRvbGlz dCAocCAoY2wtLXR5cGUtcGFyZW50cyB0eXBlKSkKCSA7OyAgIChwdXNoIChjbC0tdHlwZS1w YXJlbnRzIHApIGZvdW5kKSkKCSA7OyBFcXVpdmFsZW50IHRvIHRoZSBgZG9saXN0JyBhYm92 ZSwgYnV0IGZhc3RlcjogYXZvaWQgdG8KCSA7OyByZWNvbXB1dGUgc2V2ZXJhbCBsaXN0cyBv ZiBwYXJlbnRzIHdlIGFscmVhZHkga25vdy4KCSAobGV0ICgocGwgKGNsLS10eXBlLXBhcmVu dHMgdHlwZSkpKQoJICAgKHdoaWxlIHBsCgkgICAgIChwdXNoIHBsIGZvdW5kKQoJICAgICAo c2V0cSBwbCAoY2RyIHBsKSkpKQoJICkpCiAgICAgIDs7IENvbXB1dGUgYW4gb3JkZXJlZCBs aXN0IG9mIHR5cGVzIGZyb20gdGhlIGNvbGxlY3RlZCBEQUcuCiAgICAgIChzZXRxIGZvdW5k IChtZXJnZS1vcmRlcmVkLWxpc3RzIGZvdW5kKSkKICAgICAgOzsgUmV0dXJuIGFuIHVuaXF1 ZSB2YWx1ZSBvZiB0aGlzIGxpc3Qgb2YgdHlwZXMsIHdoaWNoIGlzIGFsc28KICAgICAgOzsg dGhlIGxpc3Qgb2Ygc3BlY2lmaWVycyBmb3IgdGhpcyB0eXBlLgogICAgICAod2l0aC1tZW1v aXphdGlvbiAoZ2V0aGFzaCBmb3VuZCBjbC0tdHlwZS11bmlxdWUpCiAgICAgICAgZm91bmQp KSkpCgo7OzsgTWV0aG9kIGRpc3BhdGNoaW5nCjs7CihjbC1nZW5lcmljLWRlZmluZS1nZW5l cmFsaXplciBjbC0tdHlwZS1nZW5lcmFsaXplcgogIDIwIDs7ICJ0eXBlb2YiIDwgImNsLXR5 cGVzLW9mIiA8ICJoZWFkIiBwcmlvcml0eQogIChsYW1iZGEgKG9iaiAmcmVzdCBfKSBgKGNs LXR5cGVzLW9mICxvYmopKQogIChsYW1iZGEgKHRhZyAmcmVzdCBfKSAoaWYgKGNvbnNwIHRh ZykgdGFnKSkpCgooY2wtZGVmbWV0aG9kIGNsLWdlbmVyaWMtZ2VuZXJhbGl6ZXJzIDpleHRy YSAiY2wtdHlwZXMtb2YiICh0eXBlKQogICJTdXBwb3J0IGZvciBkaXNwYXRjaCBvbiB0eXBl cy4iCiAgKGlmIChjbC0tdHlwZS1wIHR5cGUpCiAgICAgIChsaXN0IGNsLS10eXBlLWdlbmVy YWxpemVyKQogICAgKGNsLWNhbGwtbmV4dC1tZXRob2QpKSkKCihwcm92aWRlICdjbC10eXBl cykKCjs7OyBjbC10eXBlcy5lbCBlbmRzIGhlcmUK --------------oQNclki4E7GToXoSUh4I3NAy--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 18 Apr 2025 03:43:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 17 23:43:07 2025
Received: from localhost ([127.0.0.1]:49147 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u5cd7-0002cb-M5
for submit <at> debbugs.gnu.org; Thu, 17 Apr 2025 23:43:07 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18428)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u5cd1-0002b1-9G
for 77725 <at> debbugs.gnu.org; Thu, 17 Apr 2025 23:43:02 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 28A5B807BC;
Thu, 17 Apr 2025 23:42:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744947769;
bh=P3wiOWcF2mGAaUjT10k7HZL3oGtQk+EImI8/mK8aVZU=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=iOtoVTe32c2KE3Lahp76QvzOuy816UV6OZhf0oGSVz0gQVZT57/dGSH22RPuHFviO
KVOWknYwNb5ZT2CkR6gthlyUUWL7gSTWRGLuGyc5Bd6/Ix9O1JE1T0QafnIqRu0MKR
piKCE3fVBj77zaftC7vS/0Pv7QvasTYl8KdXfzbm2kx7b5ckO9KvZJ6sChxjinbPQy
XGpPM9vhd/lG+WI+7dZKypB1Ia8dWQ68lyGhraQ7Ti7Pu3JBUEx0vuk8QrRiwdSKkA
Xez9tOGivbgOvuT8Aw3SuSJu8FI1acgHZCoo+jYmyDB/IbiVjjsawXNcSTtRqscH3v
ZkmoUzexPw1oQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 539E7806BF;
Thu, 17 Apr 2025 23:42:49 -0400 (EDT)
Received: from pastel (104-195-239-180.cpe.teksavvy.com [104.195.239.180])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 26D63120713;
Thu, 17 Apr 2025 23:42:49 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
Message-ID: <jwv8qnyi281.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
<jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
<82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN>
Date: Thu, 17 Apr 2025 23:42:48 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.053 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> (merge-ordered-lists '((test test)))
> => (test test)
Ah, right, `merge-ordered-lists` presumes the arg lists are already sane.
>> The converse is that if we have already decided that the value is *not*
>> for type BAR, then it can't be of type FOO either, so there's no point
>> testing FOO.
> Wouldn't this involve calculating the parents of all the types traversed,
> instead of just the matching ones?
I wasn't describing an algorithm, just a principle that can be used
within an algorithm. Depending on the algorithm you use it can be used
in different ways. With your current loop, I don't think you can make
much use of it.
But I think what we could do fairly easily is the following:
- based on the PARENTS declaration, create a map from builtin-type to
the set of cl-types that have that builtin-type among their parents.
That presumes some PARENTS include some builtin-types, obviously
otherwise the map will be trivial with all cl-types associated with
the `t` "dummy parent".
[ We could even go crazy and try and guess PARENTS when not provided,
by analyzing the type's definition. ]
- in `cl-types-of` start by calling `cl-type-of`, then use the map to
find which cl-types may need to be checked.
But let's keep this for later.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 17 Apr 2025 23:01:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 17 19:01:14 2025 Received: from localhost ([127.0.0.1]:48847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u5YEI-0002JF-9B for submit <at> debbugs.gnu.org; Thu, 17 Apr 2025 19:01:14 -0400 Received: from smtp-78.smtpout.orange.fr ([80.12.242.78]:56595 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u5YEC-0002I0-7W for 77725 <at> debbugs.gnu.org; Thu, 17 Apr 2025 19:01:08 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 5YE5ufIdhwRVI5YE9uDwpb; Fri, 18 Apr 2025 01:01:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1744930862; bh=QwQC5fYxJODpskiwX39brBbsrUHj2TAhRsqeg+l4pDc=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=o7DEfNJD2k8EcsLLPl89Js6MNJfrQsWkAE5A/QTMXGtfQuUGpb+eNs71bAfkOH9wi 9+d85u9QYnop2AbbAdfMryiYGVcTr8zKNx0WXCOYHtbJPvU1yeHTLZ0VPxl2jxmy0z bcSSTeAbtc03snNBAarJTEKy4Vi7DyXEdefryvxSnPzdEP2dXo0c4eQEcAy5fm59Fg 2KeIQybsFwdOWS0APuU6Q1y5opJ6cX5tJnFKerncwEYDLLRloNLhxbwX/5RgDySMM2 pS6o/W+6ec2WiLsxb8ED2VGlNY4HtXPwttp8rNzsHOx2qEFacILLPrXE4NDbxK/Ngy Boa92siMfSs5A== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Fri, 18 Apr 2025 01:01:02 +0200 X-ME-IP: 90.112.40.65 Message-ID: <82685e00-8373-4648-b9a3-9208f0e23f2f@HIDDEN> Date: Fri, 18 Apr 2025 01:00:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN> <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN> <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN> <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN> <jwvbjt08401.fsf-monnier+emacs@HIDDEN> <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> <jwvikn4ufar.fsf-monnier+emacs@HIDDEN> <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN> <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-17 17:27, Stefan Monnier wrote: >>>> (if (memq name parents) >>>> (error "Type in parents: %S" parents)) >>> Not sure how useful is this test. >> >> I removed testing if parents is a list, this is always true. >> The other test prevents to define a type whose parent is itself. > > My comment was specifically about the last 2 lines testing if `name` is > in `parents`. How likely is this error? Wouldn't it be caught by the > DAG test later anyway? In principle your are correct, the cycle should be caught at DAG test. But it seems it's not the case. I removed the test for `name' in `parents' and tried these definitions: (cl-deftype test () 'number) (cl-deftype test () (declare (parents test)) 'number) Normally, the second definition should be caught by the DAG test, but is not, and produced wrong definition, with `cl--type-list' equals to (test test). It seems the problem is that `merge-ordered-lists' doesn't caught this case: (merge-ordered-lists '((test test))) => (test test) I tried the same test with the topologic sort, and it failed as expected: (gtype--topologic-sort '((test test))) => "Invalid graph" error > >>>> ;; Clear cached value of specializers with NAME. >>>> (if class >>>> (cl--type-reset-specializers name) >>>> ;; Record new type. >>>> (push name cl--type-list)) >>> Shouldn't we test `reged` before `push`ing? >> Not sure to understand this point. name needs to be in cl--type-list >> before to call merge-ordered-lists on the DAG. > > IIRC if `reged` is non-nil, `name` is already included in > `cl--type-list` so we shouldn't push it again there. In fact, push is done only if `class' is nil, which is the equivalent to `reged' non-nil. For clarity, I changed to test with `reged' (renamed `recorded' new versions). >>>> (defmacro cl-type-undefine (name) >>>> "Remove the definitions of type with NAME. >>>> NAME is an unquoted symbol representing a type. >>>> Signal an error if other types inherit from NAME." >>>> `(progn >>>> (cl-check-type ',name (satisfies cl-type-p)) >>>> (cl--type-undefine ',name))) >>> We don't have that for other types. I understand it's somewhat >>> dangerous for the other types and not for this one, but I still wonder >>> if we need it. >> I thought it could be useful, for example to cleanup the environment >> when you kind of uninstall a library which defined types. Maybe it >> could help during tests? > > I'm not saying it can't be useful, just wondering if it will be. > In either case it doesn't seem like there's a good reason it should be > a `defmacro` rather than a `defun`. > > BTW, part of this is handled by `define-symbol-prop` which makes sure > that the `cl-deftype-handler` is automatically removed when you > `unload-feature`. Maybe we should use `define-symbol-prop` instead of > `setf` for the `cl--class` property as well. This is good to know. For now, I only kept the function `cl--type-undefine', in case we need it to cleanup things while testing. We can remove it later if not useful. >>> That doesn't sound right: it works only if there are no types which are >>> overlapping and "incomparable" (like `cons-car-foo` and `cons-cdr-foo`). >>> We may be able to use the `subtype-of` info to skip some types (e.g. we >>> don't need to test the parents, or if we traverse the list in the other >>> direction, we don't need to test FOO if we already saw that the object >>> failed the test for one of FOO's parents), but in general we'll have to >>> check them all: we definitely can't stop at the first successful check. >> Good point. But you lost me regarding possible optimizations :-( > > If BAR is declared as a parent of FOO and `cl-types-of` has already > decided that the value *is* of type FOO, then we already know BAR will > be in the output anyway and there's no point testing BAR. This looks like what I did in my previous version. When FOO matched, I put FOO and its parents in the result. My mistake was stopping there instead of continuing to the end of the list! > The converse is that if we have already decided that the value is *not* > for type BAR, then it can't be of type FOO either, so there's no point > testing FOO. Wouldn't this involve calculating the parents of all the types traversed, instead of just the matching ones? If so, wouldn't we risk losing on one side what we gain on the other? >>>> ;;; Some tests >> [...] >>> I suggest to define something like `multiples-of-2`, `multiples-of-3`, >>> and `multiples-of-4`, so as to test more complex relationships between >>> types (with overlap but not inclusion). >> >> Do you have any examples in mind? > > Test that (c-types-of 4) is (multiples-of-4 multiples-of-2 ...) > Test that (c-types-of 6) is (multiples-of-3 multiples-of-2 ...) > Test that (c-types-of 12) is (multiples-of-4 multiples-of-3 multiples-of-2 ...) > > This would have failed with your previous code which didn't check > all types. Thank you, I'll give it a try.
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 17 Apr 2025 15:27:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 17 11:27:14 2025
Received: from localhost ([127.0.0.1]:48132 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u5R90-0003jW-45
for submit <at> debbugs.gnu.org; Thu, 17 Apr 2025 11:27:14 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17447)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u5R8v-0003iN-F1
for 77725 <at> debbugs.gnu.org; Thu, 17 Apr 2025 11:27:10 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BBB984421AA;
Thu, 17 Apr 2025 11:27:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744903622;
bh=g5oVlZSyBTXi8fJMeiLDtiKvJBJZh1fXXW6ry/ln6d0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=fo65d5SFfCS6A1OJdBN7T0EfTpyKmbkb8VAhVgf1p9AsY5sY7eWNPeeEbSrV8fPn9
95baqBPImLGmvxa2xjUN1bvLfUoBzxb2sXVOOumZoOH/+mTjk+0+CB1LOH1hgbYNhf
v+djulpZuvkUZ9H67kSwxelOVA4axNVQYac7nA7ZBJXPzzGouYWC/uxT3U2vwXRkR1
jfcdaWuD0DlFpKFJI6V1P0jYeRxVN8MFJdcnPTlkcH3BGNyF5f6R2yzsQahlQcv/2W
fwR3JfeGozkiyrc4vA957KJovsb2mhjKkS9FHq61GBc7rwmXfFA4oGYphJEgnSGTNl
JQYQRStT2Tkag==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 358AB4420DC;
Thu, 17 Apr 2025 11:27:02 -0400 (EDT)
Received: from pastel (104-195-239-180.cpe.teksavvy.com [104.195.239.180])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 049D8120E98;
Thu, 17 Apr 2025 11:27:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
Message-ID: <jwvtt6mkeny.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
<810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
Date: Thu, 17 Apr 2025 11:27:01 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.024 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> (or (eq (type-of class) 'cl-type-class)
>>> (error "Type in another class: %S" (type-of class))))
>>> (or (listp parents) (setq parents (list parents)))
>>> (if (memq name parents)
>>> (error "Type in parents: %S" parents))
>> Not sure how useful is this test.
>
> I removed testing if parents is a list, this is always true.
> The other test prevents to define a type whose parent is itself.
My comment was specifically about the last 2 lines testing if `name` is
in `parents`. How likely is this error? Wouldn't it be caught by the
DAG test later anyway?
>>> ;; Clear cached value of specializers with NAME.
>>> (if class
>>> (cl--type-reset-specializers name)
>>> ;; Record new type.
>>> (push name cl--type-list))
>> Shouldn't we test `reged` before `push`ing?
> Not sure to understand this point. name needs to be in cl--type-list
> before to call merge-ordered-lists on the DAG.
IIRC if `reged` is non-nil, `name` is already included in
`cl--type-list` so we shouldn't push it again there.
>>> (defmacro cl-type-undefine (name)
>>> "Remove the definitions of type with NAME.
>>> NAME is an unquoted symbol representing a type.
>>> Signal an error if other types inherit from NAME."
>>> `(progn
>>> (cl-check-type ',name (satisfies cl-type-p))
>>> (cl--type-undefine ',name)))
>> We don't have that for other types. I understand it's somewhat
>> dangerous for the other types and not for this one, but I still wonder
>> if we need it.
> I thought it could be useful, for example to cleanup the environment
> when you kind of uninstall a library which defined types. Maybe it
> could help during tests?
I'm not saying it can't be useful, just wondering if it will be.
In either case it doesn't seem like there's a good reason it should be
a `defmacro` rather than a `defun`.
BTW, part of this is handled by `define-symbol-prop` which makes sure
that the `cl-deftype-handler` is automatically removed when you
`unload-feature`. Maybe we should use `define-symbol-prop` instead of
`setf` for the `cl--class` property as well.
>> That doesn't sound right: it works only if there are no types which are
>> overlapping and "incomparable" (like `cons-car-foo` and `cons-cdr-foo`).
>> We may be able to use the `subtype-of` info to skip some types (e.g. we
>> don't need to test the parents, or if we traverse the list in the other
>> direction, we don't need to test FOO if we already saw that the object
>> failed the test for one of FOO's parents), but in general we'll have to
>> check them all: we definitely can't stop at the first successful check.
> Good point. But you lost me regarding possible optimizations :-(
If BAR is declared as a parent of FOO and `cl-types-of` has already
decided that the value *is* of type FOO, then we already know BAR will
be in the output anyway and there's no point testing BAR.
The converse is that if we have already decided that the value is *not*
for type BAR, then it can't be of type FOO either, so there's no point
testing FOO.
This presumes that the declaration that BAR is parent of FOO is
actually correct, of course.
> I returned to the previous version that check all types.
Good.
>>> ;;; Some tests
> [...]
>> I suggest to define something like `multiples-of-2`, `multiples-of-3`,
>> and `multiples-of-4`, so as to test more complex relationships between
>> types (with overlap but not inclusion).
>
> Do you have any examples in mind?
Test that (c-types-of 4) is (multiples-of-4 multiples-of-2 ...)
Test that (c-types-of 6) is (multiples-of-3 multiples-of-2 ...)
Test that (c-types-of 12) is (multiples-of-4 multiples-of-3 multiples-of-2 ...)
This would have failed with your previous code which didn't check
all types.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 17 Apr 2025 12:30:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 17 08:30:22 2025
Received: from localhost ([127.0.0.1]:46110 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u5ONp-0001EV-AR
for submit <at> debbugs.gnu.org; Thu, 17 Apr 2025 08:30:22 -0400
Received: from smtp-69.smtpout.orange.fr ([80.12.242.69]:60881
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u5ONj-0001Bp-Pv
for 77725 <at> debbugs.gnu.org; Thu, 17 Apr 2025 08:30:19 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 5ONbu3W2yukJt5ONfumaMJ; Thu, 17 Apr 2025 14:30:13 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744893013;
bh=jCDpaDrVLruUfA4YPXct/7djE3Qk8M/0HdIFm4+1rKU=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=hNFgD2Vq7/gR1gFLRWhuNh7UzKu02LzXDMBBeTf+e+ejGn9HPYYRRNJJsO4BcUvcW
7M0p8pp1CRFmWAed9Mb5YUCmbppD990SiH3RUwKFjZjL5wgNiOZDyIVJBZ+hIbt3+e
VaZFseV++XvAUKF6C2+lize75ZnSVmpi6b9VD9jiHn/sUWe6CykmVGl0hujx+Zf+lW
7ASARKr1Jua9vxxSsdn9dRgb+IaTy5WgofRrZ2meSvYSSTQaq0e0cij2/6MB2U3vjO
YO25cSl15oWgUuB4BPiEoJuaYVg7V4gOrV4j7rUdZiQmhwDmMxxiPdY4fXABfT8upX
bWY35+cTLqdew==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Thu, 17 Apr 2025 14:30:13 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------PB4Obs9l4nluomYQAxkWHcmP"
Message-ID: <810ab211-fcb2-490e-83da-6e3b131b0271@HIDDEN>
Date: Thu, 17 Apr 2025 14:30:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep'
to cl-generic?
To: Stefan Monnier <monnier@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
<jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------PB4Obs9l4nluomYQAxkWHcmP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
[...]
> The cost is doesn't depend on priority, it depends only on which
> generalizers are used for which generic-functions: a generic function
> whose methods don't use cl-types will not be affected at all. A generic
> function which does have at least one method dispatching on a cl-type
> will be affected, even if you never call it with an object of such cl-type.
Good to know :-)
>> (defun cl-type-p (object)
>> "Return non-nil if OBJECT is a used defined type.
>> That is, a type of class `cl-type-class'."
>> (and (symbolp object)
>> (eq (type-of (cl-find-class object)) 'cl-type-class)))
>
> Hmm... yeah... names...
>
> Then again, I don't think we have an equivalent function to test if
> a type is a bultin type or a struct type or a defclass type or an
> OClosure type, so let's push this to the "cl--" namespace.
Done.
>> (cl-defstruct
>> (cl-type-class
>> (:include cl--class)
>> (:noinline t)
>> (:constructor nil)
>> (:constructor cl--type-class-make
>> (name
>> docstring
>> parent-types
>> &aux (parents
>> (mapcar
>> (lambda (type)
>> (cl-check-type type (satisfies cl-type-p))
>> (cl-find-class type))
>> parent-types))))
>> (:copier nil))
>> "Type descriptors for user defined types.")
>
> I'm thinking it might be useful to accept builtin types as parents.
> E.g. we could make `cl-types-p` skip testing those cl-types whose parents
> are incompatible with the output of `cl-type-p`.
I tried to do that, but I am not sure I well understood your point.
Please let me know if the code is what you expect.
> I'd add a FIXME in there noting that the `cl-deftype-handler` property
> should arguably be turned into a field of this struct (but it has
> performance and compatibility implications, so let's not make that
> change for now).
Done.
>> (defun cl-type-parents (name)
>> "Get parents of type with NAME.
>> NAME is a symbol representing a type."
>> (cl--class-allparents (cl-find-class name)))
>
> Let's push this to "cl--" as well.
Done. As it is now internal, I used a macro to reduce function calls
in cl-types-of (see your point below about making `cl-types-of`
returns directly the complete list of types+allparents).
>
>> (defun cl-type-children (name)
>> "Get children of the type with NAME.
>> NAME is a symbol representing a type.
>> Return a possibly empty list of types."
>> (cl-check-type name (satisfies cl-type-p))
>> (let (children)
>> (dolist (elt cl--type-list)
>> (or (eq name elt)
>> (if (memq name (cl-type-parents elt))
>> (push elt children))))
>> children))
>
> Same.
Done.
>> (defun cl--type-generalize (name arglist body)
>> "Generalize type with NAME for method dispatching.
>> ARGLIST and BODY are passed to `cl-deftype'."
>> (let ((oldtlist (copy-sequence cl--type-list))
>> (oldplist (copy-sequence (symbol-plist name))))
>> (condition-case err
>> (pcase-let* ((`(,decls . ,body) (macroexp-parse-body body))
>> (docstring (if (stringp (car decls))
>> (pop decls)
>> (cdr (assq :documentation decls))))
>> (decls (cdr (assq 'declare decls)))
>> (parents (cdr (assq 'subtype-of decls)))
>
> Since we use the word "parents" everywhere, maybe we should look for
> `parents` rather than `subtype-of`?
Make sense. I used parents.
>
>> (class (cl-find-class name))
>> (reged (memq name cl--type-list)))
>> (if (null class)
>> (or (null reged)
>> (error "Type generalized, but doesn't exist"))
>> (or reged "Type exists, but not generalized")
>
> I think there's an `error` missing here or something.
Good catch. Fixed.
>> (or (eq (type-of class) 'cl-type-class)
>> (error "Type in another class: %S" (type-of class))))
>> (or (listp parents) (setq parents (list parents)))
>> (if (memq name parents)
>> (error "Type in parents: %S" parents))
>
> Not sure how useful is this test.
I removed testing if parents is a list, this is always true.
The other test prevents to define a type whose parent is itself.
>> ;; Setup a type descriptor for NAME. Can't use `setf' with
>> ;; `cl-find-class', so fallback to plain `put' to set the
>> ;; `cl--class' symbol property.
>> (put name 'cl--class
>> (cl--type-class-make name docstring parents))
>
> Better use `setf` (with `cl--find-class`).
I switched to `cl--find-class' everywhere for consistency.
>> ;; Clear cached value of specializers with NAME.
>> (if class
>> (cl--type-reset-specializers name)
>> ;; Record new type.
>> (push name cl--type-list))
>
> Shouldn't we test `reged` before `push`ing?
Not sure to understand this point. name needs to be in cl--type-list
before to call merge-ordered-lists on the DAG.
> Also, I think we should skip those types whose arglist is not empty
> (and probably signal an error if `subtype-of` is specified at the same
> time as a non-empty arglist).
Signal an error if arglist and parents are both non-nil.
>> ;; Keep most specific types before more general types.
>> (setq cl--type-list (merge-ordered-lists
>> (cl--type-dag)
>> (lambda (g)
>> (error "Invalid DAG, %S" g))))
>
> Why do we need sorting? Ah, it's so as to avoid sorting in
> `cl-types-of`? Maybe clarify it in the comment, then.
Done.
>> ;; Return the form to declare the type.
>> `(cl-eval-when (compile load eval)
>> (define-symbol-prop ',name 'cl-deftype-handler
>> (cl-function
>> (lambda (&cl-defs ('*) ,@arglist)
>> ,docstring
>> ,@body)))))
>
> Hmm... wait, so all the code before is executed only during
> macro-expansion and not at run-time? That doesn't sound right.
OMG! You are right. I fixed that.
>> (defmacro cl-type-undefine (name)
>> "Remove the definitions of type with NAME.
>> NAME is an unquoted symbol representing a type.
>> Signal an error if other types inherit from NAME."
>> `(progn
>> (cl-check-type ',name (satisfies cl-type-p))
>> (cl--type-undefine ',name)))
>
> We don't have that for other types. I understand it's somewhat
> dangerous for the other types and not for this one, but I still wonder
> if we need it.
I thought it could be useful, for example to cleanup the environment
when you kind of uninstall a library which defined types. Maybe it
could help during tests?
>> ;; Assuming that `cl--type-list' is properly sorted from most specific
>> ;; types to least specific ones, which should be guaranteed by
>> ;; `merge-ordered-list' in `cl--type-generalize' this verions of
>> ;; `cl-types-of' tries sequentially each type in `cl--type-list', but
>> ;; stops on the first type that matches and returns the parents of the
>> ;; type plus the builtin type of OBJECT. If no type is found, return
>> ;; nil to fallback to the "typeof" generalizer.
>
> That doesn't sound right: it works only if there are no types which are
> overlapping and "incomparable" (like `cons-car-foo` and `cons-cdr-foo`).
> We may be able to use the `subtype-of` info to skip some types (e.g. we
> don't need to test the parents, or if we traverse the list in the other
> direction, we don't need to test FOO if we already saw that the object
> failed the test for one of FOO's parents), but in general we'll have to
> check them all: we definitely can't stop at the first successful check.
Good point. But you lost me regarding possible optimizations :-(
I returned to the previous version that check all types.
>> (defvar cl--type-specializers (make-hash-table :test 'eq)
>> "Memoize type specializers.
>> Values are refreshed following the definition or removal of types.")
>>
>> (defun cl--type-reset-specializers (name)
>> "Remove all cached value of specializers related to type with NAME."
>> (maphash (lambda (key _)
>> (if (memq name key)
>> (remhash key cl--type-specializers)))
>> cl--type-specializers))
>
> BTW, you can also make `cl-types-of` return directly the complete list
> of types+allparents, i.e. the ordered list of specializers. And then
> your `cl--type-specializers` function could turn into the identity.
Good idea. I did that, which seems to work well :-)
>> ;;; Some tests
[...]
>
> I suggest to define something like `multiples-of-2`, `multiples-of-3`,
> and `multiples-of-4`, so as to test more complex relationships between
> types (with overlap but not inclusion).
Do you have any examples in mind?
Thank you for your help.
David
--------------PB4Obs9l4nluomYQAxkWHcmP
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el"
Content-Disposition: attachment; filename="cl-types.el"
Content-Transfer-Encoding: base64
OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBXaWxsIGJlIHJlbW92ZWQgd2hl
biBpbmNsdWRlZCBpbiBjbC1saWIuCihyZXF1aXJlICdjbC1saWIpCihldmFsLXdoZW4tY29t
cGlsZSAocmVxdWlyZSAnY2wtbWFjcykpICA7Rm9yIGNsLS1maW5kLWNsYXNzLgoKCgo7OyBF
eHRlbmQgYGNsLWRlZnR5cGUnIHRvIGRlZmluZSBkYXRhIHR5cGVzIHdoaWNoIGFyZSBhbHNv
IHZhbGlkCjs7IGFyZ3VtZW50IHR5cGVzIGZvciBkaXNwYXRjaGluZyBnZW5lcmljIGZ1bmN0
aW9uIG1ldGhvZHMgKHNlZSBhbHNvCjs7IDxodHRwczovL2RlYmJ1Z3MuZ251Lm9yZy9jZ2kv
YnVncmVwb3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4gZW50cnkgcG9pbnRz
IGFyZToKOzsKOzsgLSBgY2wtZGVmdHlwZScsIHRoYXQgZGVmaW5lcyBuZXcgZGF0YSB0eXBl
cy4KOzsKOzsgLSBgY2wtdHlwZXMtb2YnLCB0aGF0IHJldHVybnMgdGhlIHR5cGVzIGFuIG9i
amVjdCBiZWxvbmdzIHRvLgoKKGRlZnZhciBjbC0tdHlwZS1saXN0IG5pbAogICJMaXN0IG9m
IGRlZmluZWQgdHlwZXMgdG8gbG9va3VwIGZvciBtZXRob2QgZGlzcGF0Y2hpbmcuIikKCjs7
IEZJWE1FOiBUaGUgYGNsLWRlZnR5cGUtaGFuZGxlcmAgcHJvcGVydHkgc2hvdWxkIGFyZ3Vh
Ymx5IGJlIHR1cm5lZAo7OyBpbnRvIGEgZmllbGQgb2YgdGhpcyBzdHJ1Y3QgKGJ1dCBpdCBo
YXMgcGVyZm9ybWFuY2UgYW5kCjs7IGNvbXBhdGliaWxpdHkgaW1wbGljYXRpb25zLCBzbyBs
ZXQncyBub3QgbWFrZSB0aGF0IGNoYW5nZSBmb3Igbm93KS4KKGNsLWRlZnN0cnVjdAogICAg
KGNsLXR5cGUtY2xhc3MKICAgICAoOmluY2x1ZGUgY2wtLWNsYXNzKQogICAgICg6bm9pbmxp
bmUgdCkKICAgICAoOmNvbnN0cnVjdG9yIG5pbCkKICAgICAoOmNvbnN0cnVjdG9yIGNsLS10
eXBlLWNsYXNzLW1ha2UKICAgICAgICAgICAgICAgICAgIChuYW1lCiAgICAgICAgICAgICAg
ICAgICAgZG9jc3RyaW5nCiAgICAgICAgICAgICAgICAgICAgcGFyZW50LXR5cGVzCiAgICAg
ICAgICAgICAgICAgICAgJmF1eCAocGFyZW50cwogICAgICAgICAgICAgICAgICAgICAgICAg
IChtYXBjYXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAodHlwZSkKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAob3IgKGNsLS1maW5kLWNsYXNzIHR5cGUpCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcnJvciAiVW5rbm93biB0eXBlOiAl
UyIgdHlwZSkpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJlbnQtdHlwZXMpKSkp
CiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBmb3IgdHlwZXMgZGVm
aW5lZCBieSBgY2wtZGVmdHlwZScuIikKCihkZWZ1biBjbC0tdHlwZS1wIChvYmplY3QpCiAg
IlJldHVybiBub24tbmlsIGlmIE9CSkVDVCBpcyBhIHVzZWQgZGVmaW5lZCB0eXBlLgpUaGF0
IGlzLCBhIHR5cGUgb2YgY2xhc3MgYGNsLXR5cGUtY2xhc3MnLiIKICAoYW5kIChzeW1ib2xw
IG9iamVjdCkKICAgICAgIChjbC10eXBlcCAoY2wtLWZpbmQtY2xhc3Mgb2JqZWN0KSAnY2wt
dHlwZS1jbGFzcykpKQoKKGRlZm1hY3JvIGNsLS10eXBlLXBhcmVudHMgKG5hbWUpCiAgIkdl
dCBwYXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2Vu
dGluZyBhIHR5cGUuIgogIGAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNz
ICxuYW1lKSkpCgooZGVmdW4gY2wtLXR5cGUtY2hpbGRyZW4gKG5hbWUpCiAgIkdldCBjaGls
ZHJlbiBvZiB0aGUgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50
aW5nIGEgdHlwZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAg
KGNsLWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLS10eXBlLXApKQogIChsZXQgKGNo
aWxkcmVuKQogICAgKGRvbGlzdCAoZWx0IGNsLS10eXBlLWxpc3QpCiAgICAgIChvciAoZXEg
bmFtZSBlbHQpCiAgICAgICAgICAoaWYgKG1lbXEgbmFtZSAoY2wtLXR5cGUtcGFyZW50cyBl
bHQpKQogICAgICAgICAgICAgIChwdXNoIGVsdCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVu
KSkKCihkZWZ1biBjbC0tdHlwZS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZyb20gdGhlIGxp
c3Qgb2YgZGVmaW5lZCB0eXBlcy4iCiAgKG1hcGNhciAobGFtYmRhICh0eXBlKSAoY2wtLWNs
YXNzLWFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNzIHR5cGUpKSkKICAgICAgICAgIGNsLS10
eXBlLWxpc3QpKQoKOzsgS2VlcCBpdCBmb3Igbm93LCBmb3IgdGVzdGluZy4KKGRlZnVuIGNs
LS10eXBlLXVuZGVmaW5lIChuYW1lKQogICJSZW1vdmUgdGhlIGRlZmluaXRpb24gb2YgdHlw
ZSB3aXRoIE5BTUUuIgogIChkZWNsYXJlLWZ1bmN0aW9uIGNsLXJlbXByb3AgImNsLWV4dHJh
IiAoc3ltYm9sIHByb3BuYW1lKSkKICAod2hlbi1sZXQqICgoY2hpbGRyZW4gKGFuZCAoY2wt
LXR5cGUtcCBuYW1lKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC0tdHlwZS1j
aGlsZHJlbiBuYW1lKSkpKQogICAgKGVycm9yICJUeXBlIGhhcyBjaGlsZHJlbjogJVMiIGNo
aWxkcmVuKSkKICA7OyBDbGVhciBjYWNoZWQgdmFsdWUgb2Ygc3BlY2lhbGl6ZXJzIHdpdGgg
TkFNRS4KICAoY2wtcmVtcHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXByb3AgbmFt
ZSAnY2wtZGVmdHlwZS1oYW5kbGVyKQogIChzZXRxIGNsLS10eXBlLWxpc3QgKGRlbHEgbmFt
ZSBjbC0tdHlwZS1saXN0KSkpCgo7OyBLZWVwIGl0IGZvciBub3csIGZvciB0ZXN0aW5nLgoo
ZGVmbWFjcm8gY2wtdHlwZS11bmRlZmluZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBkZWZpbml0
aW9ucyBvZiB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhbiB1bnF1b3RlZCBzeW1ib2wgcmVw
cmVzZW50aW5nIGEgdHlwZS4KU2lnbmFsIGFuIGVycm9yIGlmIG90aGVyIHR5cGVzIGluaGVy
aXQgZnJvbSBOQU1FLiIKICBgKHByb2duCiAgICAgKGNsLWNoZWNrLXR5cGUgJyxuYW1lIChz
YXRpc2ZpZXMgY2wtLXR5cGUtcCkpCiAgICAgKGNsLS10eXBlLXVuZGVmaW5lICcsbmFtZSkp
KQoKKGRlZnVuIGNsLS10eXBlLWdlbmVyYWxpemUgKG5hbWUgYXJnbGlzdCBib2R5KQogICJH
ZW5lcmFsaXplIHR5cGUgd2l0aCBOQU1FIGZvciBtZXRob2QgZGlzcGF0Y2hpbmcuClNlZSBg
Y2wtZGVmdHlwZScgYWJvdXQgQVJHTElTVCBhbmQgQk9EWS4iCiAgKGxldCAoKG9sZHRsaXN0
IChjb3B5LXNlcXVlbmNlIGNsLS10eXBlLWxpc3QpKQogICAgICAgIChvbGRwbGlzdCAoY29w
eS1zZXF1ZW5jZSAoc3ltYm9sLXBsaXN0IG5hbWUpKSkpCiAgICAoY29uZGl0aW9uLWNhc2Ug
ZXJyCiAgICAgICAgKGxldCogKChkZWNscyAgICAgKGNhciAobWFjcm9leHAtcGFyc2UtYm9k
eSBib2R5KSkpCiAgICAgICAgICAgICAgIChkb2NzdHJpbmcgKGlmIChzdHJpbmdwIChjYXIg
ZGVjbHMpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjYXIgZGVjbHMpCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAoY2RyIChhc3NxIDpkb2N1bWVudGF0aW9uIGRlY2xz
KSkpKQogICAgICAgICAgICAgICAoZGVjbHNwZWNzIChjZHIgKGFzc3EgJ2RlY2xhcmUgZGVj
bHMpKSkKICAgICAgICAgICAgICAgKHBhcmVudHMgICAoY2RyIChhc3NxICdwYXJlbnRzIGRl
Y2xzcGVjcykpKQogICAgICAgICAgICAgICAoY2xhc3MgICAgIChjbC0tZmluZC1jbGFzcyBu
YW1lKSkKICAgICAgICAgICAgICAgKHJlY29yZGVkICAobWVtcSBuYW1lIGNsLS10eXBlLWxp
c3QpKSkKICAgICAgICAgIChhbmQgcGFyZW50cyBhcmdsaXN0CiAgICAgICAgICAgICAgIChl
cnJvciAiUGFyZW50cyBzcGVjaWZpZWQsIGJ1dCBhcmdsaXN0IG5vdCBlbXB0eSIpKQogICAg
ICAgICAgKGlmIChudWxsIGNsYXNzKQogICAgICAgICAgICAgIChvciAobnVsbCByZWNvcmRl
ZCkKICAgICAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGdlbmVyYWxpemVkLCBidXQgZG9l
c24ndCBleGlzdCIpKQogICAgICAgICAgICAob3IgcmVjb3JkZWQgKGVycm9yICJUeXBlIGV4
aXN0cywgYnV0IG5vdCBnZW5lcmFsaXplZCIpKQogICAgICAgICAgICAob3IgKGNsLXR5cGVw
IGNsYXNzICdjbC10eXBlLWNsYXNzKQogICAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGlu
IGFub3RoZXIgY2xhc3M6ICVTIiAodHlwZS1vZiBjbGFzcykpKSkKICAgICAgICAgIChpZiAo
bWVtcSBuYW1lIHBhcmVudHMpCiAgICAgICAgICAgICAgKGVycm9yICJUeXBlIGluIHBhcmVu
dHM6ICVTIiBwYXJlbnRzKSkKICAgICAgICAgIDs7IFNldHVwIGEgdHlwZSBkZXNjcmlwdG9y
IGZvciBOQU1FLgogICAgICAgICAgKHNldGYgKGNsLS1maW5kLWNsYXNzIG5hbWUpCiAgICAg
ICAgICAgICAgICAoY2wtLXR5cGUtY2xhc3MtbWFrZSBuYW1lIGRvY3N0cmluZyBwYXJlbnRz
KSkKICAgICAgICAgIDs7IFJlY29yZCBuZXcgdHlwZSBub3cgdG8gaW5jbHVkZSBpdHMgZGVw
ZW5kZW5jeSBpbiB0aGUgREFHLgogICAgICAgICAgKG9yIGNsYXNzIChwdXNoIG5hbWUgY2wt
LXR5cGUtbGlzdCkpCiAgICAgICAgICA7OyBgY2wtdHlwZXMtb2YnIGl0ZXJhdGVzIHRocm91
Z2ggYWxsIGtub3duIHR5cGVzIHRvIGNvbGxlY3QKICAgICAgICAgIDs7IGFsbCB0aG9zZSBh
biBvYmplY3QgYmVsb25ncyB0bywgc29ydGVkIGZyb20gdGhlIG1vc3QKICAgICAgICAgIDs7
IHNwZWNpZmljIHR5cGUgdG8gdGhlIG1vcmUgZ2VuZXJhbCB0eXBlLiAgU28sIGtlZXAgdGhl
CiAgICAgICAgICA7OyBnbG9iYWwgbGlzdCBpbiB0aGlzIG9yZGVyLgogICAgICAgICAgKHNl
dHEgY2wtLXR5cGUtbGlzdAogICAgICAgICAgICAgICAgKG1lcmdlLW9yZGVyZWQtbGlzdHMK
ICAgICAgICAgICAgICAgICAoY2wtLXR5cGUtZGFnKQogICAgICAgICAgICAgICAgIChsYW1i
ZGEgKF8pIChlcnJvciAiSW52YWxpZCBkZXBlbmRlbmN5IGdyYXBoIikpKSkpCiAgICAgIChl
cnJvcgogICAgICAgOzsgT24gZXJyb3IgcmVzdG9yZSBwcmV2aW91cyBkYXRhLgogICAgICAg
KHNldHEgY2wtLXR5cGUtbGlzdCBvbGR0bGlzdCkKICAgICAgIChzZXRmIChzeW1ib2wtcGxp
c3QgbmFtZSkgb2xkcGxpc3QpCiAgICAgICAoZXJyb3IgKGZvcm1hdCAiRGVmaW5lICVTIGZh
aWxlZDogJXMiCiAgICAgICAgICAgICAgICAgICAgICBuYW1lIChlcnJvci1tZXNzYWdlLXN0
cmluZyBlcnIpKSkpKSkpCgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gY2wtZGVmdHlwZTIg
KG5hbWUgYXJnbGlzdCAmcmVzdCBib2R5KQogICJEZWZpbmUgTkFNRSBhcyBhIG5ldyBkYXRh
IHR5cGUuClRoZSB0eXBlIE5BTUUgY2FuIHRoZW4gYmUgdXNlZCBpbiBgY2wtdHlwZWNhc2Un
LCBgY2wtY2hlY2stdHlwZScsIGV0YywKYW5kIGFzIGFyZ3VtZW50IHR5cGUgZm9yIGRpc3Bh
dGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KCkFSR0xJU1QgaXMgYSBDb21tb24g
TGlzcCBhcmd1bWVudCBsaXN0IG9mIHRoZSBzb3J0IGFjY2VwdGVkIGJ5CmBjbC1kZWZtYWNy
bycuICBCT0RZIGZvcm1zIGFyZSBldmFsdWF0ZWQgYW5kIHNob3VsZCByZXR1cm4gYSB0eXBl
CnNwZWNpZmllciB0aGF0IGlzIGVxdWl2YWxlbnQgdG8gdGhlIHR5cGUgKHNlZSB0aGUgSW5m
byBub2RlIGAoY2wpIFR5cGUKUHJlZGljYXRlcycgaW4gdGhlIEdOVSBFbWFjcyBDb21tb24g
TGlzcCBFbXVsYXRpb24gbWFudWFsKS4KCklmIHRoZXJlIGlzIGEgYGRlY2xhcmUnIGZvcm0g
aW4gQk9EWSwgdGhlIHNwZWMgKHBhcmVudHMgUEFSRU5UUykgaXMKcmVjb2duaXplZCB0byBz
cGVjaWZ5IGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlzIGEgc3VidHlwZSBvZi4gIEZvcgppbnN0
YW5jZToKCiAgKGNsLWRlZnR5cGUyIHVuc2lnbmVkLWJ5dGUgKCZvcHRpb25hbCBiaXRzKQog
ICAgXCJVbnNpZ25lZCBpbnRlZ2VyLlwiCiAgICAobGlzdCBcXD0naW50ZWdlciAwIChpZiAo
ZXEgYml0cyBcXD0nKikgYml0cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQoKICAoY2wtZGVmdHlw
ZTIgdW5zaWduZWQtOGJpdHMgKCkKICAgIFwiVW5zaWduZWQgOC1iaXRzIGludGVnZXIuXCIK
ICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2lnbmVkLWJ5dGUpKQogICAgXFw9Jyh1bnNpZ25l
ZC1ieXRlIDgpKQoKVGhlIGxpc3Qgb2YgUEFSRU5UUyB0eXBlcyBkZXRlcm1pbmVzIHRoZSBv
cmRlciBvZiBtZXRob2RzIGludm9jYXRpb24sCmFuZCBtaXNzaW5nIFBBUkVOVFMgbWF5IGNh
dXNlIGluY29ycmVjdCBvcmRlcmluZyBvZiBtZXRob2RzLCB3aGlsZQpleHRyYW5lb3VzIFBB
UkVOVFMgbWF5IGNhdXNlIHVzZSBvZiBleHRyYW5lb3VzIG1ldGhvZHMuIgogIChkZWNsYXJl
IChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1zdHJpbmcgMykgKGluZGVudCAyKSkKICBgKGNs
LWV2YWwtd2hlbiAoY29tcGlsZSBsb2FkIGV2YWwpCiAgICAgKGNsLS10eXBlLWdlbmVyYWxp
emUgJyxuYW1lICcsYXJnbGlzdCAnLGJvZHkpCiAgICAgKGRlZmluZS1zeW1ib2wtcHJvcCAn
LG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcgogICAgICAgICAgICAgICAgICAgICAgICAgKGNs
LWZ1bmN0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAoJmNsLWRlZnMg
KCcqKSAsQGFyZ2xpc3QpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAsQGJvZHkpKSkp
KQoKOzsgSW50ZXJuYWwgZGF0YSB1c2VkIHRvIGRldGVjdCBlbmRsZXNzIHJlY3Vyc2lvbiBp
biAnY2wtdHlwZS1vZicuCihkZWZ2YXIgY2wtLXR5cGUtb2JqZWN0IChtYWtlLXN5bWJvbCAi
dm9pZCIpKQo7OyBFbnN1cmUgZWFjaCB0eXBlIHNhdGlzZmllcyBgZXFsJy4KKGRlZnZhciBj
bC0tdHlwZS11bmlxdWUgKG1ha2UtaGFzaC10YWJsZSA6dGVzdCAnZXF1YWwpCiAgIlJlY29y
ZCBhbiB1bmlxdWUgdmFsdWUgb2YgZWFjaCB0eXBlLiIpCgo7OyBGSVhNRTogYGNsLXR5cGVz
LW9mJyBDUFUgY29zdCBpcyBwcm9wb3J0aW9uYWwgdG8gdGhlIG51bWJlciBvZiB0eXBlcwo7
OyBkZWZpbmVkIHdpdGggYGNsLWRlZnR5cGUnLCBzbyB0aGUgbW9yZSBwb3B1bGFyIGl0IGdl
dHMsIHRoZSBzbG93ZXIKOzsgaXQgYmVjb21lcy4gIEFuZCBvZiBjb3Vyc2UsIHRoZSBjb3N0
IG9mIGVhY2ggdHlwZSBjaGVjayBpcwo7OyB1bmJvdW5kZWQsIHNvIGEgc2luZ2xlICJleHBl
bnNpdmUiIHR5cGUgY2FuIHNsb3cgZXZlcnl0aGluZyBkb3duCjs7IGZ1cnRoZXIuCjs7Cjs7
IFRoZSB1c3VhbCBkaXNwYXRjaCBpcwo7Owo7OyAgIChsYW1iZGEgKGFyZyAmcmVzdCBhcmdz
KQo7OyAgICAgKGxldCAoKGYgKGdldGhhc2ggKGNsLXR5cGVvZiBhcmcpIHByZWNvbXB1dGVk
LW1ldGhvZHMtdGFibGUpKSkKOzsgICAgICAgKGlmIGYKOzsgICAgICAgICAgIChhcHBseSBm
IGFyZyBhcmdzKQo7OyAgICAgICAgIDs7IFNsb3cgY2FzZSB3aGVuIGVuY291bnRlcmluZyBh
IG5ldyB0eXBlCjs7ICAgICAgICAgLi4uKSkpCjs7Cjs7IHdoZXJlIG9mdGVuIHRoZSBtb3N0
IGV4cGVuc2l2ZSBwYXJ0IGlzIGAmcmVzdGAgKHdoaWNoIGhhcyB0bwo7OyBhbGxvY2F0ZSBh
IGxpc3QgZm9yIHRob3NlIHJlbWFpbmluZyBhcmd1bWVudHMpLAo7Owo7OyBTbyB3ZSdyZSB0
YWxraW5nIGFib3V0IHJlcGxhY2luZwo7Owo7OyAgICZyZXN0ICsgY2wtdHlwZS1vZiArIGdl
dGhhc2ggKyBpZiArIGFwcGx5Cjs7Cjs7IHdpdGggYSBmdW5jdGlvbiB0aGF0IGxvb3BzIG92
ZXIgTiB0eXBlcywgY2FsbGluZyBgY2wtdHlwZXBgIG9uIGVhY2gKOzsgb25lIG9mIHRoZW0g
KGBjbC10eXBlcGAgaXRzZWxmIGJlaW5nIGEgcmVjdXJzaXZlIGZ1bmN0aW9uIHRoYXQKOzsg
YmFzaWNhbGx5IGludGVycHJldHMgdGhlIHR5cGUgbGFuZ3VhZ2UpLiAgVGhpcyBpcyBnb2lu
ZyB0byBzbG93Cjs7IGRvd24gZGlzcGF0Y2ggdmVyeSBzaWduaWZpY2FudGx5IGZvciB0aG9z
ZSBnZW5lcmljIGZ1bmN0aW9ucyB0aGF0Cjs7IGhhdmUgYSBtZXRob2QgdGhhdCBkaXNwYXRj
aGVzIG9uIGEgdXNlciBkZWZpbmVkIHR5cGUsIGNvbXBhcmVkIHRvCjs7IHRob3NlIHRoYXQg
ZG9uJ3QuCjs7Cjs7IEl0J3Mgbm90IHRoZSBlbmQgb2YgdGhlIHdvcmxkLCBlc3BlY2lhbGx5
IGJlY2F1c2UgdGhlcmUncyBhIGxvdCBvZgo7OyBvcHBvcnR1bml0aWVzIGZvciBvcHRpbWl6
YXRpb25zIGluIHRoZXJlLCBidXQgaXQncyBzb21ldGhpbmcgdG8KOzsga2VlcCBpbiBtaW5k
LgooZGVmdW4gY2wtdHlwZXMtb2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSB0eXBlcyBPQkpF
Q1QgYmVsb25ncyB0by4KUmV0dXJuIGFuIHVuaXF1ZSBsaXN0IG9mIHR5cGVzIE9CSkVDVCBi
ZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCm1vc3Qgc3BlY2lmaWMgdHlwZSB0byB0aGUg
bW9zdCBnZW5lcmFsLiIKICA7OyBJZ25vcmUgcmVjdXJzaXZlIGNhbGwgb24gdGhlIHNhbWUg
T0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5CiAgOzsgb2NjdXIgd2hlbiBhIHBhcmVu
dCB0eXBlIGlzIGNoZWNraW5nIHdoZXRoZXIgYW4gb2JqZWN0J3MgdHlwZSBpcwogIDs7IHRo
YXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJlbi4KICAodW5sZXNzIChlcSBvYmplY3QgY2wtLXR5
cGUtb2JqZWN0KQogICAgKGxldCAoKGNsLS10eXBlLW9iamVjdCBvYmplY3QpCiAgICAgICAg
ICAoZm91bmQgKGxpc3QgKGNsLS10eXBlLXBhcmVudHMgKGNsLXR5cGUtb2Ygb2JqZWN0KSkp
KSkKICAgICAgOzsgQ29sbGVjdCBhbGwgdHlwZXMgT0JKRUNUIGJlbG9uZ3MgdG8uCiAgICAg
IChkb2xpc3QgKHR5cGUgY2wtLXR5cGUtbGlzdCkKICAgICAgICAoYW5kIChjbC10eXBlcCAo
Y2wtLWZpbmQtY2xhc3MgdHlwZSkgJ2NsLXR5cGUtY2xhc3MpCiAgICAgICAgICAgICAoY2wt
dHlwZXAgb2JqZWN0IHR5cGUpCiAgICAgICAgICAgICAocHVzaCAoY2wtLXR5cGUtcGFyZW50
cyB0eXBlKSBmb3VuZCkpKQogICAgICAoc2V0cSBmb3VuZCAobWVyZ2Utb3JkZXJlZC1saXN0
cyBmb3VuZCkpCiAgICAgIDs7IFJldHVybiBhbiB1bmlxdWUgdmFsdWUgb2YgdHlwZS4KICAg
ICAgKHdpdGgtbWVtb2l6YXRpb24gKGdldGhhc2ggZm91bmQgY2wtLXR5cGUtdW5pcXVlKQog
ICAgICAgIGZvdW5kKSkpKQoKOzs7IE1ldGhvZCBkaXNwYXRjaGluZwo7OwooY2wtZ2VuZXJp
Yy1kZWZpbmUtZ2VuZXJhbGl6ZXIgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIKICAyMCA7OyAidHlw
ZW9mIiA8ICJjbC10eXBlcy1vZiIgPCAiaGVhZCIgcHJpb3JpdHkKICAobGFtYmRhIChvYmog
JnJlc3QgXykgYChjbC10eXBlcy1vZiAsb2JqKSkKICAobGFtYmRhICh0YWcgJnJlc3QgXykg
KGlmIChjb25zcCB0YWcpIHRhZykpKQoKKGNsLWRlZm1ldGhvZCBjbC1nZW5lcmljLWdlbmVy
YWxpemVycyA6ZXh0cmEgImNsLXR5cGVzLW9mIiAodHlwZSkKICAiU3VwcG9ydCBmb3IgZGlz
cGF0Y2ggb24gdHlwZXMuIgogIChpZiAoY2wtLXR5cGUtcCB0eXBlKQogICAgICAobGlzdCBj
bC0tdHlwZS1nZW5lcmFsaXplcikKICAgIChjbC1jYWxsLW5leHQtbWV0aG9kKSkpCgo7Ozsg
U29tZSB0ZXN0cwo7OwonKHByb2duCiAgIChjbC1kZWZ0eXBlMiB1bnNpZ25lZC1ieXRlICgm
b3B0aW9uYWwgYml0cykKICAgICAiVW5zaWduZWQgaW50ZWdlci4iCiAgICAgYChpbnRlZ2Vy
IDAgLChpZiAoZXEgYml0cyAnKikgYml0cyAoMS0gKGFzaCAxIGJpdHMpKSkpKQoKICAgKGNs
LWRlZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICJVbnNpZ25lZCAxNi1iaXRzIGlu
dGVnZXIuIgogICAgIChkZWNsYXJlIChwYXJlbnRzIHVuc2lnbmVkLWJ5dGUpKQogICAgICco
dW5zaWduZWQtYnl0ZSAxNikpCgogICAoY2wtZGVmdHlwZTIgdW5zaWduZWQtOGJpdHMgKCkK
ICAgICAiVW5zaWduZWQgOC1iaXRzIGludGVnZXIuIgogICAgIChkZWNsYXJlIChwYXJlbnRz
IHVuc2lnbmVkLTE2Yml0cykpCiAgICAgJyh1bnNpZ25lZC1ieXRlIDgpKQoKICAgKGNsLXR5
cGVzLW9mIDEwMCkKICAgOzsgKHVuc2lnbmVkLThiaXRzIHVuc2lnbmVkLTE2Yml0cyB1bnNp
Z25lZC1ieXRlIGZpeG51bSkKCiAgIChjbC10eXBlcy1vZiAyNTYpCiAgIDs7ICh1bnNpZ25l
ZC0xNmJpdHMgdW5zaWduZWQtYnl0ZSBmaXhudW0pCgogICAoY2wtdHlwZXMtb2YgbW9zdC1w
b3NpdGl2ZS1maXhudW0pCiAgIDs7ICh1bnNpZ25lZC1ieXRlIGZpeG51bSkKCiAgIChjbC1k
ZWZtZXRob2QgbXktZm9vICgoX24gdW5zaWduZWQtYnl0ZSkpCiAgICAgKGZvcm1hdCAidW5z
aWduZWQiKSkKCiAgIChjbC1kZWZtZXRob2QgbXktZm9vICgoX24gdW5zaWduZWQtMTZiaXRz
KSkKICAgICAoZm9ybWF0ICJ1bnNpZ25lZCAxNmJpdHMgLSBhbHNvICVzIgogICAgICAgICAg
ICAgKGNsLWNhbGwtbmV4dC1tZXRob2QpKSkKCiAgIChjbC1kZWZtZXRob2QgbXktZm9vICgo
X24gdW5zaWduZWQtOGJpdHMpKQogICAgIChmb3JtYXQgInVuc2lnbmVkIDhiaXRzIC0gYWxz
byAlcyIKICAgICAgICAgICAgIChjbC1jYWxsLW5leHQtbWV0aG9kKSkpCgogICAobXktZm9v
IDEwMCkKICAgOzsgInVuc2lnbmVkIDhiaXRzIC0gYWxzbyB1bnNpZ25lZCIKCiAgIChteS1m
b28gMjU2KQogICA7OyAidW5zaWduZWQgMTZiaXRzIC0gYWxzbyB1bnNpZ25lZCA4Yml0cyAt
IGFsc28gdW5zaWduZWQiCgogICAobXktZm9vIG1vc3QtcG9zaXRpdmUtZml4bnVtKQogICA7
OyAidW5zaWduZWQiCgogICAoY2wtZGVmdHlwZTIgdW5zaWduZWQtMTZiaXRzICgpCiAgICAg
IlVuc2lnbmVkIDE2LWJpdHMgaW50ZWdlci4iCiAgICAgKGRlY2xhcmUgKHBhcmVudHMgdW5z
aWduZWQtOGJpdHMpKQogICAgICcodW5zaWduZWQtYnl0ZSAxNikpCiAgIDs7IEludmFsaWQg
REFHIGVycm9yCgogICkK
--------------PB4Obs9l4nluomYQAxkWHcmP--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 16 Apr 2025 19:56:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 16 15:56:45 2025
Received: from localhost ([127.0.0.1]:42539 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u58sG-0001Qa-Nt
for submit <at> debbugs.gnu.org; Wed, 16 Apr 2025 15:56:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:2996)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u58sB-0001PG-Pv
for 77725 <at> debbugs.gnu.org; Wed, 16 Apr 2025 15:56:43 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 67253441E98;
Wed, 16 Apr 2025 15:56:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744833391;
bh=qIv0EnC0qNRahph0CPsRQ95kAOn+flXgx+ZdutlL9IY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=QZNaNuShutAGIhjv4x51I8eBUQEj/SB7gWMa5P5VOmoTDyDtg+nqPnbYTNDVL3nis
Z/Lw1qb0Nxlu4vbkZprISVOxKC0b+q/hKuHKwul1I+kjD9kVHg15HqZRDAjd9UWZ3e
7WDIWs2ZJ5Hv0gNZFvnq/YuQ1+MYVbn5ozPIvJ+jKIERKZGSz9xePGlEB/v5oMjcsv
pCwvp2gqwiQqy61032XLKZX28WifVMLac6Vwku45MgNZ90/PVt5kbmMB31GJraaxF4
n14cd+h4rPO9zD1TMj4PEw46d4ZBDM7iAtufACT+JEpXJJxlrRZ3pdV8GO0pROajDw
hslo5S4pJvh8g==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 360634418DA;
Wed, 16 Apr 2025 15:56:31 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EC6F11205FA;
Wed, 16 Apr 2025 15:56:30 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
Message-ID: <jwvikn4ufar.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
Date: Wed, 16 Apr 2025 15:56:30 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.201 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Please find attached a first attempt at a cl-types.el to be merged in
> cl-lib. Please feel free to propose new names if mine are not good.
>
> For now, the new `cl-deftype' is named `cl-deftype2' for testing
> without impacting the existing environment.
=F0=9F=91=8D=F0=9F=8F=BE
> so I used the name `cl-types-of' which also better represent that this
> function returns a list of types.
+1
> WDYT?
See comments below.
> The proposed "cl-types-of" generalizer must have a higher priority than
> "typof" to correctly takes precedence over built-in types.
That's right.
> But, what about the defstruct and defclass types? Shouldn't such types
> have higher priority than cl-deftype and builtin types?
Actually, since Emacs-26 `(cl-)type-of` returns the proper struct type
for both defstruct and defclass types, so they both use the
`cl--generic-typeof-generalizer`.
[ That's still not the case for OClosures, sadly. ]
> I wouldn't want "cl-types-of" to have too much of a performance impact on
> method dispatch for defstruct and defclass types, unless it's really
> necessary.
The cost is doesn't depend on priority, it depends only on which
generalizers are used for which generic-functions: a generic function
whose methods don't use cl-types will not be affected at all. A generic
function which does have at least one method dispatching on a cl-type
will be affected, even if you never call it with an object of such cl-type.
> (defun cl-type-p (object)
> "Return non-nil if OBJECT is a used defined type.
> That is, a type of class `cl-type-class'."
> (and (symbolp object)
> (eq (type-of (cl-find-class object)) 'cl-type-class)))
Hmm... yeah... names...
Then again, I don't think we have an equivalent function to test if
a type is a bultin type or a struct type or a defclass type or an
OClosure type, so let's push this to the "cl--" namespace.
> (cl-defstruct
> (cl-type-class
> (:include cl--class)
> (:noinline t)
> (:constructor nil)
> (:constructor cl--type-class-make
> (name
> docstring
> parent-types
> &aux (parents
> (mapcar
> (lambda (type)
> (cl-check-type type (satisfies cl-type-p))
> (cl-find-class type))
> parent-types))))
> (:copier nil))
> "Type descriptors for user defined types.")
I'm thinking it might be useful to accept builtin types as parents.
E.g. we could make `cl-types-p` skip testing those cl-types whose parents
are incompatible with the output of `cl-type-p`.
I'd add a FIXME in there noting that the `cl-deftype-handler` property
should arguably be turned into a field of this struct (but it has
performance and compatibility implications, so let's not make that
change for now).
> (defun cl-type-parents (name)
> "Get parents of type with NAME.
> NAME is a symbol representing a type."
> (cl--class-allparents (cl-find-class name)))
Let's push this to "cl--" as well.
> (defun cl-type-children (name)
> "Get children of the type with NAME.
> NAME is a symbol representing a type.
> Return a possibly empty list of types."
> (cl-check-type name (satisfies cl-type-p))
> (let (children)
> (dolist (elt cl--type-list)
> (or (eq name elt)
> (if (memq name (cl-type-parents elt))
> (push elt children))))
> children))
Same.
> (defun cl--type-generalize (name arglist body)
> "Generalize type with NAME for method dispatching.
> ARGLIST and BODY are passed to `cl-deftype'."
> (let ((oldtlist (copy-sequence cl--type-list))
> (oldplist (copy-sequence (symbol-plist name))))
> (condition-case err
> (pcase-let* ((`(,decls . ,body) (macroexp-parse-body body))
> (docstring (if (stringp (car decls))
> (pop decls)
> (cdr (assq :documentation decls))))
> (decls (cdr (assq 'declare decls)))
> (parents (cdr (assq 'subtype-of decls)))
Since we use the word "parents" everywhere, maybe we should look for
`parents` rather than `subtype-of`?
> (class (cl-find-class name))
> (reged (memq name cl--type-list)))
> (if (null class)
> (or (null reged)
> (error "Type generalized, but doesn't exist"))
> (or reged "Type exists, but not generalized")
I think there's an `error` missing here or something.
> (or (eq (type-of class) 'cl-type-class)
> (error "Type in another class: %S" (type-of class))))
> (or (listp parents) (setq parents (list parents)))
> (if (memq name parents)
> (error "Type in parents: %S" parents))
Not sure how useful is this test.
> ;; Setup a type descriptor for NAME. Can't use `setf' with
> ;; `cl-find-class', so fallback to plain `put' to set the
> ;; `cl--class' symbol property.
> (put name 'cl--class
> (cl--type-class-make name docstring parents))
Better use `setf` (with `cl--find-class`).
> ;; Clear cached value of specializers with NAME.
> (if class
> (cl--type-reset-specializers name)
> ;; Record new type.
> (push name cl--type-list))
Shouldn't we test `reged` before `push`ing?
Also, I think we should skip those types whose arglist is not empty
(and probably signal an error if `subtype-of` is specified at the same
time as a non-empty arglist).
> ;; Keep most specific types before more general types.
> (setq cl--type-list (merge-ordered-lists
> (cl--type-dag)
> (lambda (g)
> (error "Invalid DAG, %S" g))))
Why do we need sorting? Ah, it's so as to avoid sorting in
`cl-types-of`? Maybe clarify it in the comment, then.
> ;; Return the form to declare the type.
> `(cl-eval-when (compile load eval)
> (define-symbol-prop ',name 'cl-deftype-handler
> (cl-function
> (lambda (&cl-defs ('*) ,@arglist)
> ,docstring
> ,@body)))))
Hmm... wait, so all the code before is executed only during
macro-expansion and not at run-time? That doesn't sound right.
> (defmacro cl-type-undefine (name)
> "Remove the definitions of type with NAME.
> NAME is an unquoted symbol representing a type.
> Signal an error if other types inherit from NAME."
> `(progn
> (cl-check-type ',name (satisfies cl-type-p))
> (cl--type-undefine ',name)))
We don't have that for other types. I understand it's somewhat
dangerous for the other types and not for this one, but I still wonder
if we need it.
> ;; Assuming that `cl--type-list' is properly sorted from most specific
> ;; types to least specific ones, which should be guaranteed by
> ;; `merge-ordered-list' in `cl--type-generalize' this verions of
> ;; `cl-types-of' tries sequentially each type in `cl--type-list', but
> ;; stops on the first type that matches and returns the parents of the
> ;; type plus the builtin type of OBJECT. If no type is found, return
> ;; nil to fallback to the "typeof" generalizer.
That doesn't sound right: it works only if there are no types which are
overlapping and "incomparable" (like `cons-car-foo` and `cons-cdr-foo`).
We may be able to use the `subtype-of` info to skip some types (e.g. we
don't need to test the parents, or if we traverse the list in the other
direction, we don't need to test FOO if we already saw that the object
failed the test for one of FOO's parents), but in general we'll have to
check them all: we definitely can't stop at the first successful check.
Stefan
> (defvar cl--type-specializers (make-hash-table :test 'eq)
> "Memoize type specializers.
> Values are refreshed following the definition or removal of types.")
>
> (defun cl--type-reset-specializers (name)
> "Remove all cached value of specializers related to type with NAME."
> (maphash (lambda (key _)
> (if (memq name key)
> (remhash key cl--type-specializers)))
> cl--type-specializers))
BTW, you can also make `cl-types-of` return directly the complete list
of types+allparents, i.e. the ordered list of specializers. And then
your `cl--type-specializers` function could turn into the identity.
> ;;; Some tests
> ;;
> '(progn
> (cl-deftype2 unsigned-byte (&optional bits)
> "Unsigned integer."
> `(integer 0 ,(if (eq bits '*) bits (1- (ash 1 bits)))))
>
> (cl-deftype2 unsigned-16bits ()
> "Unsigned 16-bits integer."
> (declare (subtype-of unsigned-byte))
> '(unsigned-byte 16))
>
> (cl-deftype2 unsigned-8bits ()
> "Unsigned 8-bits integer."
> (declare (subtype-of unsigned-16bits))
> '(unsigned-byte 8))
I suggest to define something like `multiples-of-2`, `multiples-of-3`,
and `multiples-of-4`, so as to test more complex relationships between
types (with overlap but not inclusion).
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 16 Apr 2025 15:42:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 16 11:42:28 2025
Received: from localhost ([127.0.0.1]:40618 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u54uB-0001sh-Li
for submit <at> debbugs.gnu.org; Wed, 16 Apr 2025 11:42:28 -0400
Received: from smtp-15.smtpout.orange.fr ([80.12.242.15]:53949
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u54u7-0001rp-3T
for 77725 <at> debbugs.gnu.org; Wed, 16 Apr 2025 11:42:25 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 54tduUjyYtvMG54tgu2SnR; Wed, 16 Apr 2025 17:41:59 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744818119;
bh=oS4g5MBbq40ywNiAlAtv4P5PQp3MBuBMb3MHNVJPLKw=;
h=Message-ID:Date:MIME-Version:Subject:From:To;
b=aIlTuNgWWYyfCN3Aav/K3Dpmqk06d/ZauU1lP4Qwc8EFLLj8e+4x3CzgB9Y5h2kjk
tfc8ya2oUntRuEWgHyiy0GuG1tYJujMouR0U2mNioMqrPomBpQNuBW+Olz0E5kmS0Z
Izu8pXA9ij9oyvKSeYMUVN42le39SINruPRMPs/oy4cbbVNzGGk8tkrDHWkPBgvAL/
7mmx6a5KyM59swuiADI4gnjg41TsVBDOHX077lY5lyq4PSCCWwnm+Uxbl3xWojdPIw
2LgQgNQZSABPeyLJGux3gFM/emICFgFu4eIYEDYLsu8oaKsJEhAkPhl42paAHvd1OE
LNclT9zFwY81g==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Wed, 16 Apr 2025 17:41:59 +0200
X-ME-IP: 90.112.40.65
Message-ID: <e910b889-2d57-41d5-a048-713e6dfb8b58@HIDDEN>
Date: Wed, 16 Apr 2025 17:42:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep'
to cl-generic?
From: David Ponce <da_vid@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
<jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
<8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
Content-Language: fr, en-US
In-Reply-To: <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
[...]
> Please find attached a first attempt at a cl-types.el to be merged in
> cl-lib. Please feel free to propose new names if mine are not good.
>
> For now, the new `cl-deftype' is named `cl-deftype2' for testing
> without impacting the existing environment.
>
> I tried to consistent at using the `cl-type-' prefix (or `cl--type-'
> for internals). But some names are very close to already existing
> ones, like 'cl-type-p' vs. `cl-typep'. There is also a collision with
> the name `cl-type-of', already used for a builtin function, so I used
> the name `cl-types-of' which also better represent that this function
> returns a list of types.
>
> The new code is also better at handling errors. It should detect most
> of the possible errors, and will restore the current environnement on
> error. I also tried to improve cl-types-of. Please read my comments
> in the code.
>
> WDYT?
I also have a question regarding the "typeof" generalizer which is defined
like this in cl-generic:
(cl-generic-define-generalizer cl--generic-typeof-generalizer
10 (lambda (name &rest _) `(cl-type-of ,name))
#'cl--generic-type-specializers)
(cl-defmethod cl-generic-generalizers :extra "typeof" (type)
"Support for dispatch on types.
This currently works for built-in types and types built on top of records."
;; FIXME: Add support for other "types" accepted by `cl-typep' such
;; as `character', `face', `keyword', ...?
(or
(and (symbolp type)
(not (eq type t)) ;; Handled by the `t-generalizer'.
(let ((class (cl--find-class type)))
(memq (type-of class)
'(built-in-class cl-structure-class eieio--class)))
(list cl--generic-typeof-generalizer))
(cl-call-next-method)))
The proposed "cl-types-of" generalizer must have a higher priority than
"typof" to correctly takes precedence over built-in types.
But, what about the defstruct and defclass types? Shouldn't such types
have higher priority than cl-deftype and builtin types?
I wouldn't want "cl-types-of" to have too much of a performance impact on
method dispatch for defstruct and defclass types, unless it's really
necessary.
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 16 Apr 2025 15:17:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 16 11:17:50 2025 Received: from localhost ([127.0.0.1]:40364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u54WK-0007JV-Vk for submit <at> debbugs.gnu.org; Wed, 16 Apr 2025 11:17:50 -0400 Received: from smtp-30.smtpout.orange.fr ([80.12.242.30]:55669 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u54WG-0007JE-G9 for 77725 <at> debbugs.gnu.org; Wed, 16 Apr 2025 11:17:46 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 54W8ubdic1J2g54WCuvErr; Wed, 16 Apr 2025 17:17:42 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1744816662; bh=WlTVe8zAXPdY1jBrOe+EKQmT3vu2i7wM7PfLBCLYlM8=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=HM2AEIxiHj8GfV4KL+S3Qcj0YNgHxp75hxTxuXNbHLkRzPB6l/izrvu0ZyjQISsn0 YI8LzCU3lH3KWDu2GKyD6xw++Ld7rEMlELdI2lMi/b/jEEHS0CX9u9RVjypH0OHXls 8MkGEMiCl4uo+aUOl7cb+jH7B56UlY2U3c3S/caY1+DAKGVDBN5lNGIEap4kj0BKAx +HlJ/Vt4m6MF9a/NxITL8yvWiy00vfays340/PrSADDEneOdB24bFAPD1I0witVCZr HBnscAlJHB1UZdIEnEc5TJ03AFFHCQT64Wh1q7sT5m8Cj/wIzvwteHDZqBj43ze7+z uUzUwxYpMvkVA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Wed, 16 Apr 2025 17:17:42 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------NmUF7puYso0yKcC0qzFBhzuT" Message-ID: <8b5d55ef-4dba-4931-a96c-b48097d0e4ca@HIDDEN> Date: Wed, 16 Apr 2025 17:17:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN> <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN> <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN> <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN> <jwvbjt08401.fsf-monnier+emacs@HIDDEN> <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> <jwvcydek5ax.fsf-monnier+emacs@HIDDEN> <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN> <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN> <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN> <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------NmUF7puYso0yKcC0qzFBhzuT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2025-04-15 21:17, Stefan Monnier wrote: >>>> That would be great. But I need some help here to correctly dispatch >>>> all functions in gtype to Emacs libraries: cl-macs, cl-generic ? >>> Not `cl-generic`, but yes `cl-macs.el` with maybe some parts in >>> `cl-preloaded.el` and/or `cl-lib.el` and/or `cl-extra.el`. >> Shouldn't the code related to method dispatching, at the end of gtype.el, >> go to cl-generic? > > Technically it can go to various places, but ideally `cl-generic` just > provides the machinery whereas the actual generalizers would be > defined next to where we define the corresponding types. In practice, > we have most of the `cl-generic-define-generalizer` in there, > admittedly, but that's because of overriding bootstrapping issues. > > Since we're talking about generalizers defined for `cl-deftype` which is > not a core primitive but one defined in `cl-lib`, it makes sense to > define it elsewhere (i.e. in the `cl-lib` files), like we do for > EIEIO types. OK. > >>> I was thinking that the main(only?) difference between `cl-deftype` and >>> `gdeftype` is: >>> - the PARENTS argument, where the question is how to add a PARENTS >>> argument. Maybe we could use a (declare (parents ...))? >> >> Another possibility could be to have 2 separate definitions: >> >> - cl-deftype to define a data type, as currently. >> >> - cl-types-generalize (or something better) to declare a type previously >> defined by cl-deftype usable to dispatch methods, with specified parents? >> >> (cl-deftype my-type () >> "A user defined type." >> ...) >> (cl-types-generalize my-type) ;; No parents >> >> (cl-deftype my-type1 () >> "Another user defined type." >> ...) >> (cl-types-generalize my-type1 my-type) ;; With parents > > We could, but having them separate begs the question of how to match one > with the other: e.g. if we re-evaluate (cl-deftype my-type ...) should the > corresponding previous (cl-types-generalize ...) be "undone"? > > It's somewhat philosophical, admittedly, but bringing them together > makes it much more clear what is the "right" behavior (regardless if we > end up implementing the right behavior: at least when we get > a bug-report, we know which change is an improvement). I agree. > >>> - The ARGS: Clearly your `gtype-of` can invent which args to pass >>> for a given value to match the resulting type, so `gtype-of` (and >>> everything which relies on it, i.e. method dispatch) wouldn't be >>> usable for types with a non-empty arglist. >> >> I am not sure I understand this point regarding ARGS. >> Is this related to the `cl-deftype' arguments which cannot be used to >> declare argument type of methods: > > Exactly. `cl-deftype` lets you define types such as `(list-of > integer)`, but your code is not able to figure out that a value is of > type `(list-of integer)` so you can't handle those kinds of types. > And that's OK: it's still better than what we currently have. > >> But, below is possible instead: >> >> (defgtype u8 unsigned-byte () >> '(unsigned-byte 8)) >> >> (cl-defmethod my-foo ((n u8)) >> (format "unsigned 8bits, %s - also %s" >> n (cl-call-next-method))) > > That's right. OK. > > We could try to later add support for > > (cl-defmethod my-foo ((n (unsigned-byte 8))) > (format "unsigned, %s" n)) > > but ... one step at a time. Sure. Even better could be to support the full type-specifier syntax ;-) Please find attached a first attempt at a cl-types.el to be merged in cl-lib. Please feel free to propose new names if mine are not good. For now, the new `cl-deftype' is named `cl-deftype2' for testing without impacting the existing environment. I tried to consistent at using the `cl-type-' prefix (or `cl--type-' for internals). But some names are very close to already existing ones, like 'cl-type-p' vs. `cl-typep'. There is also a collision with the name `cl-type-of', already used for a builtin function, so I used the name `cl-types-of' which also better represent that this function returns a list of types. The new code is also better at handling errors. It should detect most of the possible errors, and will restore the current environnement on error. I also tried to improve cl-types-of. Please read my comments in the code. WDYT? Thanks! David --------------NmUF7puYso0yKcC0qzFBhzuT Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-types.el" Content-Disposition: attachment; filename="cl-types.el" Content-Transfer-Encoding: base64 OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgo7OyBXaWxsIGJlIHJlbW92ZWQgd2hl biBpbmNsdWRlZCBpbiBjbC1saWIuCihyZXF1aXJlICdjbC1saWIpCgooZGVjbGFyZS1mdW5j dGlvbiBjbC1maW5kLWNsYXNzICJjbC1leHRyYSIgKHR5cGUpKQooZGVjbGFyZS1mdW5jdGlv biBjbC1yZW1wcm9wICJjbC1leHRyYSIgKHN5bWJvbCBwcm9wbmFtZSkpCgo7OyBFeHRlbmQg YGNsLWRlZnR5cGUnIHRvIGRlZmluZSBkYXRhIHR5cGVzIHdoaWNoIGFyZSBhbHNvIHZhbGlk Cjs7IGFyZ3VtZW50IHR5cGVzIGZvciBkaXNwYXRjaGluZyBnZW5lcmljIGZ1bmN0aW9uIG1l dGhvZHMgKHNlZSBhbHNvCjs7IDxodHRwczovL2RlYmJ1Z3MuZ251Lm9yZy9jZ2kvYnVncmVw b3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFyZToK OzsKOzsgLSBgY2wtZGVmdHlwZScsIHRoYXQgZGVmaW5lcyBuZXcgZGF0YSB0eXBlcy4KOzsK OzsgLSBgY2wtdHlwZXMtb2YnLCB0aGF0IGxvb2t1cHMgdGhlIHR5cGVzIGFuIG9iamVjdCBi ZWxvbmdzIHRvLgoKKGRlZnZhciBjbC0tdHlwZS1saXN0IG5pbAogICJMaXN0IG9mIGRlZmlu ZWQgdHlwZXMgdG8gbG9va3VwIGZvciBtZXRob2QgZGlzcGF0Y2hpbmcuIikKCihkZWZ1biBj bC10eXBlLXAgKG9iamVjdCkKICAiUmV0dXJuIG5vbi1uaWwgaWYgT0JKRUNUIGlzIGEgdXNl ZCBkZWZpbmVkIHR5cGUuClRoYXQgaXMsIGEgdHlwZSBvZiBjbGFzcyBgY2wtdHlwZS1jbGFz cycuIgogIChhbmQgKHN5bWJvbHAgb2JqZWN0KQogICAgICAgKGVxICh0eXBlLW9mIChjbC1m aW5kLWNsYXNzIG9iamVjdCkpICdjbC10eXBlLWNsYXNzKSkpCgooY2wtZGVmc3RydWN0CiAg ICAoY2wtdHlwZS1jbGFzcwogICAgICg6aW5jbHVkZSBjbC0tY2xhc3MpCiAgICAgKDpub2lu bGluZSB0KQogICAgICg6Y29uc3RydWN0b3IgbmlsKQogICAgICg6Y29uc3RydWN0b3IgY2wt LXR5cGUtY2xhc3MtbWFrZQogICAgICAgICAgICAgICAgICAgKG5hbWUKICAgICAgICAgICAg ICAgICAgICBkb2NzdHJpbmcKICAgICAgICAgICAgICAgICAgICBwYXJlbnQtdHlwZXMKICAg ICAgICAgICAgICAgICAgICAmYXV4IChwYXJlbnRzCiAgICAgICAgICAgICAgICAgICAgICAg ICAgKG1hcGNhcgogICAgICAgICAgICAgICAgICAgICAgICAgICAobGFtYmRhICh0eXBlKQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC1jaGVjay10eXBlIHR5cGUgKHNhdGlz ZmllcyBjbC10eXBlLXApKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC1maW5k LWNsYXNzIHR5cGUpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJlbnQtdHlwZXMp KSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBmb3IgdXNlciBk ZWZpbmVkIHR5cGVzLiIpCgooZGVmdW4gY2wtdHlwZS1wYXJlbnRzIChuYW1lKQogICJHZXQg cGFyZW50cyBvZiB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhIHN5bWJvbCByZXByZXNlbnRp bmcgYSB0eXBlLiIKICAoY2wtLWNsYXNzLWFsbHBhcmVudHMgKGNsLWZpbmQtY2xhc3MgbmFt ZSkpKQoKKGRlZnVuIGNsLXR5cGUtY2hpbGRyZW4gKG5hbWUpCiAgIkdldCBjaGlsZHJlbiBv ZiB0aGUgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5nIGEg dHlwZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAgKGNsLWNo ZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGNsLXR5cGUtcCkpCiAgKGxldCAoY2hpbGRyZW4p CiAgICAoZG9saXN0IChlbHQgY2wtLXR5cGUtbGlzdCkKICAgICAgKG9yIChlcSBuYW1lIGVs dCkKICAgICAgICAgIChpZiAobWVtcSBuYW1lIChjbC10eXBlLXBhcmVudHMgZWx0KSkKICAg ICAgICAgICAgICAocHVzaCBlbHQgY2hpbGRyZW4pKSkpCiAgICBjaGlsZHJlbikpCgooZGVm dW4gY2wtLXR5cGUtZGFnICgpCiAgIlJldHVybiBhIERBRyBmcm9tIHRoZSBsaXN0IG9mIGRl ZmluZWQgdHlwZXMuIgogIChjbC1sYWJlbHMgKChhbGxwYXJlbnRzIChjbGFzcykKICAgICAg ICAgICAgICAgIChsZXQgKCh0eXBlIChjbC0tY2xhc3MtbmFtZSBjbGFzcykpKQogICAgICAg ICAgICAgICAgICA7OyBFeGNsdWRlIG5vbi1jbC10eXBlLXAgZnJvbSB0aGUgREFHLgogICAg ICAgICAgICAgICAgICAoaWYgKGNsLXR5cGUtcCB0eXBlKQogICAgICAgICAgICAgICAgICAg ICAgKGNvbnMgdHlwZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgKG1lcmdlLW9yZGVy ZWQtbGlzdHMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobWFwY2FyICMnYWxscGFy ZW50cwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNsLS1jbGFzcy1w YXJlbnRzIGNsYXNzKSkpKSkpKSkKICAgIChtYXBjYXIgKGxhbWJkYSAodHlwZSkgKGFsbHBh cmVudHMgKGNsLWZpbmQtY2xhc3MgdHlwZSkpKQogICAgICAgICAgICBjbC0tdHlwZS1saXN0 KSkpCgooZGVmdW4gY2wtLXR5cGUtdW5kZWZpbmUgKG5hbWUpCiAgIlJlbW92ZSB0aGUgZGVm aW5pdGlvbiBvZiB0eXBlIHdpdGggTkFNRS4iCiAgKHdoZW4tbGV0KiAoKGNoaWxkcmVuIChh bmQgKGNsLXR5cGUtcCBuYW1lKSAoY2wtdHlwZS1jaGlsZHJlbiBuYW1lKSkpKQogICAgKGVy cm9yICJUeXBlIGhhcyBjaGlsZHJlbjogJVMiIGNoaWxkcmVuKSkKICA7OyBDbGVhciBjYWNo ZWQgdmFsdWUgb2Ygc3BlY2lhbGl6ZXJzIHdpdGggTkFNRS4KICAoY2wtLXR5cGUtcmVzZXQt c3BlY2lhbGl6ZXJzIG5hbWUpCiAgKGNsLXJlbXByb3AgbmFtZSAnY2wtLWNsYXNzKQogIChj bC1yZW1wcm9wIG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcikKICAoc2V0cSBjbC0tdHlwZS1s aXN0IChkZWxxIG5hbWUgY2wtLXR5cGUtbGlzdCkpKQoKKGRlZnVuIGNsLS10eXBlLWdlbmVy YWxpemUgKG5hbWUgYXJnbGlzdCBib2R5KQogICJHZW5lcmFsaXplIHR5cGUgd2l0aCBOQU1F IGZvciBtZXRob2QgZGlzcGF0Y2hpbmcuCkFSR0xJU1QgYW5kIEJPRFkgYXJlIHBhc3NlZCB0 byBgY2wtZGVmdHlwZScuIgogIChsZXQgKChvbGR0bGlzdCAoY29weS1zZXF1ZW5jZSBjbC0t dHlwZS1saXN0KSkKCShvbGRwbGlzdCAoY29weS1zZXF1ZW5jZSAoc3ltYm9sLXBsaXN0IG5h bWUpKSkpCiAgICAoY29uZGl0aW9uLWNhc2UgZXJyCiAgICAgICAgKHBjYXNlLWxldCogKChg KCxkZWNscyAuICxib2R5KSAobWFjcm9leHAtcGFyc2UtYm9keSBib2R5KSkKICAgICAgICAg ICAgICAgICAgICAgKGRvY3N0cmluZyAoaWYgKHN0cmluZ3AgKGNhciBkZWNscykpCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChwb3AgZGVjbHMpCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoY2RyIChhc3NxIDpkb2N1bWVudGF0aW9uIGRlY2xz KSkpKQogICAgICAgICAgICAgICAgICAgICAoZGVjbHMgICAoY2RyIChhc3NxICdkZWNsYXJl IGRlY2xzKSkpCiAgICAgICAgICAgICAgICAgICAgIChwYXJlbnRzIChjZHIgKGFzc3EgJ3N1 YnR5cGUtb2YgZGVjbHMpKSkKICAgICAgICAgICAgICAgICAgICAgKGNsYXNzICAgKGNsLWZp bmQtY2xhc3MgbmFtZSkpCiAgICAgICAgICAgICAgICAgICAgIChyZWdlZCAgIChtZW1xIG5h bWUgY2wtLXR5cGUtbGlzdCkpKQogICAgICAgICAgKGlmIChudWxsIGNsYXNzKQogICAgICAg ICAgICAgIChvciAobnVsbCByZWdlZCkKICAgICAgICAgICAgICAgICAgKGVycm9yICJUeXBl IGdlbmVyYWxpemVkLCBidXQgZG9lc24ndCBleGlzdCIpKQogICAgICAgICAgICAob3IgcmVn ZWQgIlR5cGUgZXhpc3RzLCBidXQgbm90IGdlbmVyYWxpemVkIikKICAgICAgICAgICAgKG9y IChlcSAodHlwZS1vZiBjbGFzcykgJ2NsLXR5cGUtY2xhc3MpCiAgICAgICAgICAgICAgICAo ZXJyb3IgIlR5cGUgaW4gYW5vdGhlciBjbGFzczogJVMiICh0eXBlLW9mIGNsYXNzKSkpKQog ICAgICAgICAgKG9yIChsaXN0cCBwYXJlbnRzKSAoc2V0cSBwYXJlbnRzIChsaXN0IHBhcmVu dHMpKSkKICAgICAgICAgIChpZiAobWVtcSBuYW1lIHBhcmVudHMpCiAgICAgICAgICAgICAg KGVycm9yICJUeXBlIGluIHBhcmVudHM6ICVTIiBwYXJlbnRzKSkKICAgICAgICAgIDs7IFNl dHVwIGEgdHlwZSBkZXNjcmlwdG9yIGZvciBOQU1FLiAgQ2FuJ3QgdXNlIGBzZXRmJyB3aXRo CiAgICAgICAgICA7OyBgY2wtZmluZC1jbGFzcycsIHNvIGZhbGxiYWNrIHRvIHBsYWluIGBw dXQnIHRvIHNldCB0aGUKICAgICAgICAgIDs7IGBjbC0tY2xhc3MnIHN5bWJvbCBwcm9wZXJ0 eS4KICAgICAgICAgIChwdXQgbmFtZSAnY2wtLWNsYXNzCiAgICAgICAgICAgICAgIChjbC0t dHlwZS1jbGFzcy1tYWtlIG5hbWUgZG9jc3RyaW5nIHBhcmVudHMpKQogICAgICAgICAgOzsg Q2xlYXIgY2FjaGVkIHZhbHVlIG9mIHNwZWNpYWxpemVycyB3aXRoIE5BTUUuCiAgICAgICAg ICAoaWYgY2xhc3MKCSAgICAgIChjbC0tdHlwZS1yZXNldC1zcGVjaWFsaXplcnMgbmFtZSkK CSAgICA7OyBSZWNvcmQgbmV3IHR5cGUuCgkgICAgKHB1c2ggbmFtZSBjbC0tdHlwZS1saXN0 KSkKICAgICAgICAgIDs7IEtlZXAgbW9zdCBzcGVjaWZpYyB0eXBlcyBiZWZvcmUgbW9yZSBn ZW5lcmFsIHR5cGVzLgogICAgICAgICAgKHNldHEgY2wtLXR5cGUtbGlzdCAobWVyZ2Utb3Jk ZXJlZC1saXN0cwoJCQkgICAgICAgKGNsLS10eXBlLWRhZykKCQkJICAgICAgIChsYW1iZGEg KGcpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcnJvciAiSW52YWxpZCBE QUcsICVTIiBnKSkpKQogICAgICAgICAgOzsgUmV0dXJuIHRoZSBmb3JtIHRvIGRlY2xhcmUg dGhlIHR5cGUuCiAgICAgICAgICBgKGNsLWV2YWwtd2hlbiAoY29tcGlsZSBsb2FkIGV2YWwp CiAgICAgICAgICAgICAoZGVmaW5lLXN5bWJvbC1wcm9wICcsbmFtZSAnY2wtZGVmdHlwZS1o YW5kbGVyCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC1mdW5jdGlvbgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAoJmNsLWRlZnMgKCcq KSAsQGFyZ2xpc3QpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICxkb2Nz dHJpbmcKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLEBib2R5KSkpKSkK ICAgICAgKGVycm9yCiAgICAgICA7OyBPbiBlcnJvciByZXN0b3JlIHRoZSBwcmV2aW91cyBk YXRhLgogICAgICAgKHNldHEgY2wtLXR5cGUtbGlzdCBvbGR0bGlzdCkKICAgICAgIChzZXRm IChzeW1ib2wtcGxpc3QgbmFtZSkgb2xkcGxpc3QpCiAgICAgICAoZXJyb3IgKGZvcm1hdCAi RGVmaW5lICVTIGZhaWxlZDogJXMiCiAgICAgICAgICAgICAgICAgICAgICBuYW1lIChlcnJv ci1tZXNzYWdlLXN0cmluZyBlcnIpKSkpKSkpCgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8g Y2wtZGVmdHlwZTIgKG5hbWUgYXJnbGlzdCAmcmVzdCBib2R5KQogICJEZWZpbmUgTkFNRSBh cyBhIG5ldyBkYXRhIHR5cGUuClRoZSB0eXBlIE5BTUUgY2FuIHRoZW4gYmUgdXNlZCBpbiBg Y2wtdHlwZWNhc2UnLCBgY2wtY2hlY2stdHlwZScsIGV0YywKYW5kIGFzIGFyZ3VtZW50IHR5 cGUgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KCkFSR0xJU1Qg aXMgYSBDb21tb24gTGlzcCBhcmd1bWVudCBsaXN0IG9mIHRoZSBzb3J0IGFjY2VwdGVkIGJ5 CmBjbC1kZWZtYWNybycuICBCT0RZIGZvcm1zIGFyZSBldmFsdWF0ZWQgYW5kIHNob3VsZCBy ZXR1cm4gYSB0eXBlCnNwZWNpZmllciB0aGF0IGlzIGVxdWl2YWxlbnQgdG8gdGhlIHR5cGUg KHNlZSB0aGUgSW5mbyBub2RlIGAoY2wpIFR5cGUKUHJlZGljYXRlcycgaW4gdGhlIEdOVSBF bWFjcyBDb21tb24gTGlzcCBFbXVsYXRpb24gbWFudWFsKS4KCklmIHRoZSBmaXJzdCBmb3Jt IGluIEJPRFkgaXMgYSBgZGVjbGFyZScgZm9ybSwgdGhlIHNwZWMgKHN1YnR5cGUtb2YKUEFS RU5UUykgaXMgcmVjb2duaXplZCB0byBzcGVjaWZ5IGEgbGlzdCBvZiB0eXBlcyBOQU1FIGlz IGEgc3VidHlwZQpvZi4gIEZvciBpbnN0YW5jZToKCiAgKGNsLWRlZnR5cGUyIHVuc2lnbmVk LWJ5dGUgKCZvcHRpb25hbCBiaXRzKQogICAgXCJVbnNpZ25lZCBpbnRlZ2VyLlwiCiAgICAo bGlzdCBcXD0naW50ZWdlciAwIChpZiAoZXEgYml0cyBcXD0nKikgYml0cyAoMS0gKGFzaCAx IGJpdHMpKSkpKQoKICAoY2wtZGVmdHlwZTIgdW5zaWduZWQtOGJpdHMgKCkKICAgIFwiVW5z aWduZWQgOC1iaXRzIGludGVnZXIuXCIKICAgIChkZWNsYXJlIChzdWJ0eXBlLW9mIHVuc2ln bmVkLWJ5dGUpKQogICAgXFw9Jyh1bnNpZ25lZC1ieXRlIDgpKQoKVGhlIGxpc3Qgb2YgUEFS RU5UUyB0eXBlcyBkZXRlcm1pbmVzIHRoZSBvcmRlciBvZiBtZXRob2RzIGludm9jYXRpb24s CmFuZCBtaXNzaW5nIFBBUkVOVFMgbWF5IGNhdXNlIGluY29ycmVjdCBvcmRlcmluZyBvZiBt ZXRob2RzLCB3aGlsZQpleHRyYW5lb3VzIFBBUkVOVFMgbWF5IGNhdXNlIHVzZSBvZiBleHRy YW5lb3VzIG1ldGhvZHMuIgogIChkZWNsYXJlIChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1z dHJpbmcgMykgKGluZGVudCAyKSkKICAoY2wtLXR5cGUtZ2VuZXJhbGl6ZSBuYW1lIGFyZ2xp c3QgYm9keSkpCgooZGVmbWFjcm8gY2wtdHlwZS11bmRlZmluZSAobmFtZSkKICAiUmVtb3Zl IHRoZSBkZWZpbml0aW9ucyBvZiB0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhbiB1bnF1b3Rl ZCBzeW1ib2wgcmVwcmVzZW50aW5nIGEgdHlwZS4KU2lnbmFsIGFuIGVycm9yIGlmIG90aGVy IHR5cGVzIGluaGVyaXQgZnJvbSBOQU1FLiIKICBgKHByb2duCiAgICAgKGNsLWNoZWNrLXR5 cGUgJyxuYW1lIChzYXRpc2ZpZXMgY2wtdHlwZS1wKSkKICAgICAoY2wtLXR5cGUtdW5kZWZp bmUgJyxuYW1lKSkpCgo7OyBJbnRlcm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVuZGxlc3Mg cmVjdXJzaW9uIGluICdjbC10eXBlLW9mJy4KKGRlZnZhciBjbC0tdHlwZS1vYmplY3QgKG1h a2Utc3ltYm9sICJ2b2lkIikpCjs7IEVuc3VyZSBlYWNoIHR5cGUgc2F0aXNmaWVzIGBlcWwn LgooZGVmdmFyIGNsLS10eXBlLXVuaXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVh bCkKICAiUmVjb3JkIGFuIHVuaXF1ZSB2YWx1ZSBvZiBlYWNoIHR5cGUuIikKCjs7IEZJWE1F OiBgZ3R5cGUtb2YnIENQVSBjb3N0IGlzIHByb3BvcnRpb25hbCB0byB0aGUgbnVtYmVyIG9m IHR5cGVzCjs7IGRlZmluZWQgd2l0aCBgY2wtZGVmdHlwZScsIHNvIHRoZSBtb3JlIHBvcHVs YXIgaXQgZ2V0cywgdGhlIHNsb3dlcgo7OyBpdCBiZWNvbWVzLiAgQW5kIG9mIGNvdXJzZSwg dGhlIGNvc3Qgb2YgZWFjaCB0eXBlIGNoZWNrIGlzCjs7IHVuYm91bmRlZCwgc28gYSBzaW5n bGUgImV4cGVuc2l2ZSIgdHlwZSBjYW4gc2xvdyBldmVyeXRoaW5nIGRvd24KOzsgZnVydGhl ci4KOzsKOzsgVGhlIHVzdWFsIGRpc3BhdGNoIGlzCjs7Cjs7ICAgKGxhbWJkYSAoYXJnICZy ZXN0IGFyZ3MpCjs7ICAgICAobGV0ICgoZiAoZ2V0aGFzaCAoY2wtdHlwZW9mIGFyZykgcHJl Y29tcHV0ZWQtbWV0aG9kcy10YWJsZSkpKQo7OyAgICAgICAoaWYgZgo7OyAgICAgICAgICAg KGFwcGx5IGYgYXJnIGFyZ3MpCjs7ICAgICAgICAgOzsgU2xvdyBjYXNlIHdoZW4gZW5jb3Vu dGVyaW5nIGEgbmV3IHR5cGUKOzsgICAgICAgICAuLi4pKSkKOzsKOzsgd2hlcmUgb2Z0ZW4g dGhlIG1vc3QgZXhwZW5zaXZlIHBhcnQgaXMgYCZyZXN0YCAod2hpY2ggaGFzIHRvCjs7IGFs bG9jYXRlIGEgbGlzdCBmb3IgdGhvc2UgcmVtYWluaW5nIGFyZ3VtZW50cyksCjs7Cjs7IFNv IHdlJ3JlIHRhbGtpbmcgYWJvdXQgcmVwbGFjaW5nCjs7Cjs7ICAgJnJlc3QgKyBjbC10eXBl LW9mICsgZ2V0aGFzaCArIGlmICsgYXBwbHkKOzsKOzsgd2l0aCBhIGZ1bmN0aW9uIHRoYXQg bG9vcHMgb3ZlciBOIHR5cGVzLCBjYWxsaW5nIGBjbC10eXBlcGAgb24gZWFjaAo7OyBvbmUg b2YgdGhlbSAoYGNsLXR5cGVwYCBpdHNlbGYgYmVpbmcgYSByZWN1cnNpdmUgZnVuY3Rpb24g dGhhdAo7OyBiYXNpY2FsbHkgaW50ZXJwcmV0cyB0aGUgdHlwZSBsYW5ndWFnZSkuICBUaGlz IGlzIGdvaW5nIHRvIHNsb3cKOzsgZG93biBkaXNwYXRjaCB2ZXJ5IHNpZ25pZmljYW50bHkg Zm9yIHRob3NlIGdlbmVyaWMgZnVuY3Rpb25zIHRoYXQKOzsgaGF2ZSBhIG1ldGhvZCB0aGF0 IGRpc3BhdGNoZXMgb24gYSB1c2VyIGRlZmluZWQgdHlwZSwgY29tcGFyZWQgdG8KOzsgdGhv c2UgdGhhdCBkb24ndC4KOzsKOzsgSXQncyBub3QgdGhlIGVuZCBvZiB0aGUgd29ybGQsIGVz cGVjaWFsbHkgYmVjYXVzZSB0aGVyZSdzIGEgbG90IG9mCjs7IG9wcG9ydHVuaXRpZXMgZm9y IG9wdGltaXphdGlvbnMgaW4gdGhlcmUsIGJ1dCBpdCdzIHNvbWV0aGluZyB0bwo7OyBrZWVw IGluIG1pbmQuCgo7OyAoZGVmdW4gY2wtdHlwZXMtb2YgKG9iamVjdCkKOzsgICAiUmV0dXJu IHRoZSB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0by4KOzsgUmV0dXJuIGFuIHVuaXF1ZSBsaXN0 IG9mIHR5cGVzIE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCjs7IG1vc3Qg c3BlY2lmaWMgdHlwZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIKOzsgICA7OyBJZ25vcmUgcmVj dXJzaXZlIGNhbGwgb24gdGhlIHNhbWUgT0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5 Cjs7ICAgOzsgb2NjdXIgd2hlbiBhIHBhcmVudCB0eXBlIGlzIGNoZWNraW5nIHdoZXRoZXIg YW4gb2JqZWN0J3MgdHlwZSBpcwo7OyAgIDs7IHRoYXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJl bi4KOzsgICAodW5sZXNzIChlcSBvYmplY3QgY2wtLXR5cGUtb2JqZWN0KQo7OyAgICAgKGxl dCAoKGNsLS10eXBlLW9iamVjdCBvYmplY3QpCjs7ICAgICAgICAgICAoZm91bmQgKGxpc3Qg KGNsLXR5cGUtb2Ygb2JqZWN0KSkpKQo7OyAgICAgICA7OyBDb2xsZWN0IGFsbCB0eXBlcyBP QkpFQ1QgYmVsb25ncyB0by4KOzsgICAgICAgKGRvbGlzdCAodHlwZSBjbC0tdHlwZS1saXN0 KQo7OyAgICAgICAgIChpZiAoY2wtdHlwZXAgb2JqZWN0IHR5cGUpCjs7ICAgICAgICAgICAg IChwdXNoIHR5cGUgZm91bmQpKSkKOzsgICAgICAgOzsgUmV0dXJuIGFuIHVuaXF1ZSB2YWx1 ZSBvZiB0eXBlLgo7OyAgICAgICAod2l0aC1tZW1vaXphdGlvbiAoZ2V0aGFzaCBmb3VuZCBj bC0tdHlwZS11bmlxdWUpCjs7ICAgICAgICAgZm91bmQpKSkpCgo7OyBBc3N1bWluZyB0aGF0 IGBjbC0tdHlwZS1saXN0JyBpcyBwcm9wZXJseSBzb3J0ZWQgZnJvbSBtb3N0IHNwZWNpZmlj Cjs7IHR5cGVzIHRvIGxlYXN0IHNwZWNpZmljIG9uZXMsIHdoaWNoIHNob3VsZCBiZSBndWFy YW50ZWVkIGJ5Cjs7IGBtZXJnZS1vcmRlcmVkLWxpc3QnIGluIGBjbC0tdHlwZS1nZW5lcmFs aXplJyB0aGlzIHZlcmlvbnMgb2YKOzsgYGNsLXR5cGVzLW9mJyB0cmllcyBzZXF1ZW50aWFs bHkgZWFjaCB0eXBlIGluIGBjbC0tdHlwZS1saXN0JywgYnV0Cjs7IHN0b3BzIG9uIHRoZSBm aXJzdCB0eXBlIHRoYXQgbWF0Y2hlcyBhbmQgcmV0dXJucyB0aGUgcGFyZW50cyBvZiB0aGUK OzsgdHlwZSBwbHVzIHRoZSBidWlsdGluIHR5cGUgb2YgT0JKRUNULiAgSWYgbm8gdHlwZSBp cyBmb3VuZCwgcmV0dXJuCjs7IG5pbCB0byBmYWxsYmFjayB0byB0aGUgInR5cGVvZiIgZ2Vu ZXJhbGl6ZXIuCihkZWZ1biBjbC10eXBlcy1vZiAob2JqZWN0KQogICJSZXR1cm4gdGhlIHVz ZXIgZGVmaW5lZCB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0bywgb3IgbmlsIGlmIG5vbmUuClJl dHVybiBhbiB1bmlxdWUgbGlzdCBvZiB0eXBlcyBPQkpFQ1QgYmVsb25ncyB0bywgb3JkZXJl ZCBmcm9tIHRoZQptb3N0IHNwZWNpZmljIHR5cGUgdG8gdGhlIG1vc3QgZ2VuZXJhbC4iCiAg OzsgSWdub3JlIHJlY3Vyc2l2ZSBjYWxsIG9uIHRoZSBzYW1lIE9CSkVDVCwgd2hpY2ggY2Fu IGxlZ2l0aW1hdGVseQogIDs7IG9jY3VyIHdoZW4gYSBwYXJlbnQgdHlwZSBpcyBjaGVja2lu ZyB3aGV0aGVyIGFuIG9iamVjdCdzIHR5cGUgaXMKICA7OyB0aGF0IG9mIG9uZSBvZiBpdHMg Y2hpbGRyZW4uCiAgKHVubGVzcyAoZXEgb2JqZWN0IGNsLS10eXBlLW9iamVjdCkKICAgIChs ZXQgKChjbC0tdHlwZS1vYmplY3Qgb2JqZWN0KQogICAgICAgICAgKHR5cGVzIGNsLS10eXBl LWxpc3QpCiAgICAgICAgICAoZm91bmQgbmlsKSkKICAgICAgOzsgVHJ5IGFsbCB0eXBlcyB1 bnRpbCBvbmUgaXMgZm91bmQgT0JKRUNUIGJlbG9uZ3MgdG8uCiAgICAgICh3aGlsZSAoYW5k IHR5cGVzIChub3QgZm91bmQpKQogICAgICAgIChpZiAoY2wtdHlwZXAgb2JqZWN0IChjYXIg dHlwZXMpKQogICAgICAgICAgICA7OyBJZiBPQkpFQ1QgYmVsb25ncyB0byB0eXBlLCBhc3N1 bWluZyB0eXBlIGlzIHRoZSBtb3N0CiAgICAgICAgICAgIDs7IHBvc3NpYmxlIHNwZWNpZmlj IHR5cGUgb2YgT0JKRUNULCB0aGUgbGlzdCBvZiB0eXBlcwogICAgICAgICAgICA7OyBPQkpF Q1RTIGJlbG9uZ3MgdG8gc2hvdWxkIGJlIGVxdWFsIHRvIHRoZSBsaXN0IG9mIHR5cGUKICAg ICAgICAgICAgOzsgcGFyZW50cywgcGx1cyB0aGUgYnVpbHRpbiB0eXBlIG9mIE9CSkVDVC4K ICAgICAgICAgICAgKHNldHEgZm91bmQgKG5jb25jIChjbC10eXBlLXBhcmVudHMgKGNhciB0 eXBlcykpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobGlzdCAoY2wtdHlwZS1v ZiBvYmplY3QpKSkpCiAgICAgICAgICAoc2V0cSB0eXBlcyAoY2RyIHR5cGVzKSkpKQogICAg ICAoaWYgZm91bmQKICAgICAgICAgIDs7IFJldHVybiBhbiB1bmlxdWUgdmFsdWUuCiAgICAg ICAgICAod2l0aC1tZW1vaXphdGlvbiAoZ2V0aGFzaCBmb3VuZCBjbC0tdHlwZS11bmlxdWUp CiAgICAgICAgICAgIGZvdW5kKSkpKSkKCjs7OyBNZXRob2QgZGlzcGF0Y2hpbmcKOzsKKGRl ZnZhciBjbC0tdHlwZS1zcGVjaWFsaXplcnMgKG1ha2UtaGFzaC10YWJsZSA6dGVzdCAnZXEp CiAgIk1lbW9pemUgdHlwZSBzcGVjaWFsaXplcnMuClZhbHVlcyBhcmUgcmVmcmVzaGVkIGZv bGxvd2luZyB0aGUgZGVmaW5pdGlvbiBvciByZW1vdmFsIG9mIHR5cGVzLiIpCgooZGVmdW4g Y2wtLXR5cGUtcmVzZXQtc3BlY2lhbGl6ZXJzIChuYW1lKQogICJSZW1vdmUgYWxsIGNhY2hl ZCB2YWx1ZSBvZiBzcGVjaWFsaXplcnMgcmVsYXRlZCB0byB0eXBlIHdpdGggTkFNRS4iCiAg KG1hcGhhc2ggKGxhbWJkYSAoa2V5IF8pCiAgICAgICAgICAgICAoaWYgKG1lbXEgbmFtZSBr ZXkpCiAgICAgICAgICAgICAgICAgKHJlbWhhc2gga2V5IGNsLS10eXBlLXNwZWNpYWxpemVy cykpKQogICAgICAgICAgIGNsLS10eXBlLXNwZWNpYWxpemVycykpCgooZGVmdW4gY2wtLXR5 cGUtc3BlY2lhbGl6ZXJzICh0YWcgJnJlc3QgXykKICAiSWYgVEFHIGlzIGEgdHlwZSwgcmV0 dXJuIGl0cyBzcGVjaWFsaXplcnMuIgogIDs7IFRoaXMgZnVuY3Rpb24gaXMgb25seSBldmVy IGNhbGxlZCB3aXRoICJ0YWdjb2RlcyIgcmV0dXJuZWQgYnkKICA7OyBgY2wtdHlwZS1vZics IHNvIHRoZSBgY2wtdHlwZS1wJyB0ZXN0IGlzIHJlZHVuZGFudC4KICAoYW5kIChjb25zcCB0 YWcpIDs7IChjbC10eXBlLXAgKGNhciB0YWcpKQogICAgICAgKHdpdGgtbWVtb2l6YXRpb24g KGdldGhhc2ggdGFnIGNsLS10eXBlLXNwZWNpYWxpemVycykKICAgICAgICAgOzsgVG8gZmlu ZCB0aGUgbW9zdCBwb3NzaWJsZSBzcGVjaWZpYyB0eXBlIG9mIGFuIG9iamVjdCwgaXQKICAg ICAgICAgOzsgaXMgY3JpdGljYWwgdG8gaGF2ZSBzcGVjaWFsaXplcnMgb3JkZXJlZCBmcm9t IHRoZSBtb3N0CiAgICAgICAgIDs7IHNwZWNpZmljIHBvc3NpYmxlIHR5cGUgdG8gdGhlIG1v cmUgZ2VuZXJhbCB0eXBlLgogICAgICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cyAobWFwY2Fy ICMnY2wtdHlwZS1wYXJlbnRzIHRhZykpKSkpCgooY2wtZ2VuZXJpYy1kZWZpbmUtZ2VuZXJh bGl6ZXIgY2wtLXR5cGUtZ2VuZXJhbGl6ZXIKICAyMCA7OyAidHlwZW9mIiA8ICJjbC10eXBl cy1vZiIgPCAiaGVhZCIgcHJpb3JpdHkKICAobGFtYmRhIChvYmogJnJlc3QgXykgYChjbC10 eXBlcy1vZiAsb2JqKSkKICAjJ2NsLS10eXBlLXNwZWNpYWxpemVycykKCihjbC1kZWZtZXRo b2QgY2wtZ2VuZXJpYy1nZW5lcmFsaXplcnMgOmV4dHJhICJjbC10eXBlcy1vZiIgKHR5cGUp CiAgIlN1cHBvcnQgZm9yIGRpc3BhdGNoIG9uIHR5cGVzLiIKICAoaWYgKGNsLXR5cGUtcCB0 eXBlKQogICAgICAobGlzdCBjbC0tdHlwZS1nZW5lcmFsaXplcikKICAgIChjbC1jYWxsLW5l eHQtbWV0aG9kKSkpCgo7OzsgU29tZSB0ZXN0cwo7OwonKHByb2duCiAgIChjbC1kZWZ0eXBl MiB1bnNpZ25lZC1ieXRlICgmb3B0aW9uYWwgYml0cykKICAgICAiVW5zaWduZWQgaW50ZWdl ci4iCiAgICAgYChpbnRlZ2VyIDAgLChpZiAoZXEgYml0cyAnKikgYml0cyAoMS0gKGFzaCAx IGJpdHMpKSkpKQoKICAgKGNsLWRlZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICJV bnNpZ25lZCAxNi1iaXRzIGludGVnZXIuIgogICAgIChkZWNsYXJlIChzdWJ0eXBlLW9mIHVu c2lnbmVkLWJ5dGUpKQogICAgICcodW5zaWduZWQtYnl0ZSAxNikpCgogICAoY2wtZGVmdHlw ZTIgdW5zaWduZWQtOGJpdHMgKCkKICAgICAiVW5zaWduZWQgOC1iaXRzIGludGVnZXIuIgog ICAgIChkZWNsYXJlIChzdWJ0eXBlLW9mIHVuc2lnbmVkLTE2Yml0cykpCiAgICAgJyh1bnNp Z25lZC1ieXRlIDgpKQogICAKICAgKGNsLXR5cGVzLW9mIDEwMCkKICAgOzsgKHVuc2lnbmVk LThiaXRzIHVuc2lnbmVkLTE2Yml0cyB1bnNpZ25lZC1ieXRlIGZpeG51bSkKCiAgIChjbC10 eXBlcy1vZiAyNTYpCiAgIDs7ICh1bnNpZ25lZC0xNmJpdHMgdW5zaWduZWQtYnl0ZSBmaXhu dW0pCgogICAoY2wtdHlwZXMtb2YgbW9zdC1wb3NpdGl2ZS1maXhudW0pCiAgIDs7ICh1bnNp Z25lZC1ieXRlIGZpeG51bSkKIAogICAoY2wtZGVmbWV0aG9kIG15LWZvbyAoKF9uIHVuc2ln bmVkLWJ5dGUpKQogICAgIChmb3JtYXQgInVuc2lnbmVkIikpCgogICAoY2wtZGVmbWV0aG9k IG15LWZvbyAoKF9uIHVuc2lnbmVkLTE2Yml0cykpCiAgICAgKGZvcm1hdCAidW5zaWduZWQg MTZiaXRzIC0gYWxzbyAlcyIKICAgICAgICAgICAgIChjbC1jYWxsLW5leHQtbWV0aG9kKSkp CgogICAoY2wtZGVmbWV0aG9kIG15LWZvbyAoKF9uIHVuc2lnbmVkLThiaXRzKSkKICAgICAo Zm9ybWF0ICJ1bnNpZ25lZCA4Yml0cyAtIGFsc28gJXMiCiAgICAgICAgICAgICAoY2wtY2Fs bC1uZXh0LW1ldGhvZCkpKQogICAKICAgKG15LWZvbyAxMDApCiAgIDs7ICJ1bnNpZ25lZCA4 Yml0cyAtIGFsc28gdW5zaWduZWQiCgogICAobXktZm9vIDI1NikKICAgOzsgInVuc2lnbmVk IDE2Yml0cyAtIGFsc28gdW5zaWduZWQgOGJpdHMgLSBhbHNvIHVuc2lnbmVkIgoKICAgKG15 LWZvbyBtb3N0LXBvc2l0aXZlLWZpeG51bSkKICAgOzsgInVuc2lnbmVkIgoKICAgKGNsLWRl ZnR5cGUyIHVuc2lnbmVkLTE2Yml0cyAoKQogICAgICJVbnNpZ25lZCAxNi1iaXRzIGludGVn ZXIuIgogICAgIChkZWNsYXJlIChzdWJ0eXBlLW9mIHVuc2lnbmVkLThiaXRzKSkKICAgICAn KHVuc2lnbmVkLWJ5dGUgMTYpKQogICA7OyBJbnZhbGlkIERBRyBlcnJvcgogICAKICApCg== --------------NmUF7puYso0yKcC0qzFBhzuT--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 15 Apr 2025 19:17:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 15 15:17:32 2025
Received: from localhost ([127.0.0.1]:55653 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4lml-0004Lp-I1
for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 15:17:31 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60157)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u4lmi-0004LU-Os
for 77725 <at> debbugs.gnu.org; Tue, 15 Apr 2025 15:17:29 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7ED2C10006B;
Tue, 15 Apr 2025 15:17:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744744639;
bh=x4h689TxI62nU9kpKuowSLhSsHhT5I12+dDluphJuIk=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Tv6tKk4yJr+Z59c8GMv5qE867RJM1Yxe44jvG65tuHypoxXj+d7AFScqDWUjwsoSJ
QzwzQoXAgQydWFRGLRltwqM8KE2z1P9XAalnGPYFXvs6QVcnNi6Evt7nY0fYox+etd
BRLwfTy2RtHO5+PXHF801F9E3Xw4q0kUMtCekOW3qAdSoQpD6Mk5+IHqirvqtCquO2
AHkte45LAGsTUhUvM2QbBY0+rabjEj8/eFH5pVQuMFW6pQPk/2ZDYWEltcWYbRV0ES
ZOeOyD0V+HxeGWwJrSi1qsRfuSz7xO7Y7kUZ8Vn1yhpkmYWdrrRW/kYFGKgkp6lJQv
WCsIWPwmWrtWg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B635F100027;
Tue, 15 Apr 2025 15:17:19 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8B9A31202D5;
Tue, 15 Apr 2025 15:17:19 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
Message-ID: <jwvtt6p1ceh.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
<1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
Date: Tue, 15 Apr 2025 15:17:13 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.376 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> That would be great. But I need some help here to correctly dispatch
>>> all functions in gtype to Emacs libraries: cl-macs, cl-generic ?
>> Not `cl-generic`, but yes `cl-macs.el` with maybe some parts in
>> `cl-preloaded.el` and/or `cl-lib.el` and/or `cl-extra.el`.
> Shouldn't the code related to method dispatching, at the end of gtype.el,
> go to cl-generic?
Technically it can go to various places, but ideally `cl-generic` just
provides the machinery whereas the actual generalizers would be
defined next to where we define the corresponding types. In practice,
we have most of the `cl-generic-define-generalizer` in there,
admittedly, but that's because of overriding bootstrapping issues.
Since we're talking about generalizers defined for `cl-deftype` which is
not a core primitive but one defined in `cl-lib`, it makes sense to
define it elsewhere (i.e. in the `cl-lib` files), like we do for
EIEIO types.
>> I was thinking that the main(only?) difference between `cl-deftype` and
>> `gdeftype` is:
>> - the PARENTS argument, where the question is how to add a PARENTS
>> argument. Maybe we could use a (declare (parents ...))?
>
> Another possibility could be to have 2 separate definitions:
>
> - cl-deftype to define a data type, as currently.
>
> - cl-types-generalize (or something better) to declare a type previously
> defined by cl-deftype usable to dispatch methods, with specified parents?
>
> (cl-deftype my-type ()
> "A user defined type."
> ...)
> (cl-types-generalize my-type) ;; No parents
>
> (cl-deftype my-type1 ()
> "Another user defined type."
> ...)
> (cl-types-generalize my-type1 my-type) ;; With parents
We could, but having them separate begs the question of how to match one
with the other: e.g. if we re-evaluate (cl-deftype my-type ...) should the
corresponding previous (cl-types-generalize ...) be "undone"?
It's somewhat philosophical, admittedly, but bringing them together
makes it much more clear what is the "right" behavior (regardless if we
end up implementing the right behavior: at least when we get
a bug-report, we know which change is an improvement).
>> - The ARGS: Clearly your `gtype-of` can invent which args to pass
>> for a given value to match the resulting type, so `gtype-of` (and
>> everything which relies on it, i.e. method dispatch) wouldn't be
>> usable for types with a non-empty arglist.
>
> I am not sure I understand this point regarding ARGS.
> Is this related to the `cl-deftype' arguments which cannot be used to
> declare argument type of methods:
Exactly. `cl-deftype` lets you define types such as `(list-of
integer)`, but your code is not able to figure out that a value is of
type `(list-of integer)` so you can't handle those kinds of types.
And that's OK: it's still better than what we currently have.
> But, below is possible instead:
>
> (defgtype u8 unsigned-byte ()
> '(unsigned-byte 8))
>
> (cl-defmethod my-foo ((n u8))
> (format "unsigned 8bits, %s - also %s"
> n (cl-call-next-method)))
That's right.
We could try to later add support for
(cl-defmethod my-foo ((n (unsigned-byte 8)))
(format "unsigned, %s" n))
but ... one step at a time.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 15 Apr 2025 16:40:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 15 12:40:59 2025
Received: from localhost ([127.0.0.1]:54483 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4jLE-0006kO-Uz
for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 12:40:59 -0400
Received: from smtp-78.smtpout.orange.fr ([80.12.242.78]:37283
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u4jLA-0006jB-7h
for 77725 <at> debbugs.gnu.org; Tue, 15 Apr 2025 12:40:54 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 4jL3ubMfUOaHY4jL6ullYy; Tue, 15 Apr 2025 18:40:50 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744735250;
bh=KTFgPY1OrHLiC8agUTqeR/+FdUF03jrinXGOHLOw3Hc=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=HjjnjfohDSTldUv6t42b1mtxfdVsnXnoog7dQedNxG1WP3buZvMw63DYifgdSwgTW
ebbRyyvftlmzsjXS/zZWvJUfdAPd7e9YUbczJRUn2fnqxdqTKQ8a5ya53HP1TgT0LI
qdyB9L9NeGGdQBuQxRDQosSiDiwLSqWU5hZ+trD1m2FMi94AzJagT+evsIcaS4/Ion
q3IFzAwAWhLcroIpEAEMvyNbdxs27eBBdN4z2XsUGZp+SYtvY9n5BFW/+piASSjfsy
zPcoMK/oio9UC53wYaSktXvA0TGyu9cWMY2yANL9TIM3qx+4XDcoPkgC0eeIq9B/wD
bqskTTnskSOSg==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Tue, 15 Apr 2025 18:40:50 +0200
X-ME-IP: 90.112.40.65
Message-ID: <1f4001c3-b0b4-41f4-8706-1853c3086da7@HIDDEN>
Date: Tue, 15 Apr 2025 18:40:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep'
to cl-generic?
To: Stefan Monnier <monnier@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
<jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-04-15 17:13, Stefan Monnier wrote:
>>> I get the impression that the role/impact of PARENTS is not explained
>>> clearly enough. The explanation should be clear enough that the reader
>>> can infer more or less what could happen if a parent is missing or if
>>> a non-parent is incorrectly listed as a parent.
>> This is a very good point. Currently, the role of PARENTS is limited
>> to specify in which order gtype `gtype-of' will check gtypes.
>
> Why does this order matter? I thought the PARENTS was used just in
> `gtype--specializers` to sort the various types.
Sorry for the confusion, you are right, of course.
>> For instance, you can do something like this:
>>
>> (defgtype a-fixnum nil ()
>> 'fixnum)
>>
>> (gtype-of 10)
>> (a-fixnum fixnum)
>>
>> (defgtype a-fixnum-between-1-10 a-fixnum ()
>> `(satisfies ,(lambda (x) (and (numberp x) (> x 0) (< x 11)))))
>>
>> (gtype-of 10.1)
>> (a-fixnum-between-1-10 float)
>> gtype--list
>> (a-fixnum-between-1-10 a-fixnum)
>>
>> Clearly 10.1 is not "a-fixnum-between-1-10", because the type
>> specifier is incorrect; even if `a-fixnum-between-1-10' is a subtype
>> of `a-fixnum'.
>>
>> The correct subtype could be:
>>
>> (defgtype a-fixnum-between-1-10 a-fixnum ()
>> `(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
>>
>> But the type specifier is not produced automatically.
>
> AFAICT the error will manifest itself in the fact that
> `gtype--specializers` will return
>
> (a-fixnum-between-1-10 a-fixnum float fixnum integer ...)
>
> so a method defined `a-fixnum` may end up incorrectly invoked in this case.
>
> In contrast if `a-fixnum` is missing:
>
> (defgtype a-fixnum-between-1-10 nil ()
> `(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
>
> then `gtype--specializers` may end up returning
>
> (a-fixnum a-fixnum-between-1-10 float fixnum integer ...)
>
> so a method defined for `a-fixnum` may take precedence over one defined
> for `a-fixnum-between-1-10`.
>
>> Not so easy to put all this in a docstring. Any idea?
>
> AFAICT, missing PARENTS may cause incorrect ordering of methods,
> while extraneous PARENTS may cause use of extraneous methods.
I will add this to the docstring.
>
>>>> (declare (debug cl-defmacro) (doc-string 4) (indent 3))
>>>> (cl-with-gensyms (err)
>>>> `(condition-case ,err
>>>> (progn
>>>> (cl-deftype ,name ,@args)
>>>> (gtype--register ',name ',parents ',args))
>>>> (error
>>>> (gtype--unregister ',name)
>>>> (error (error-message-string ,err))))))
>>> Could we merge this into `cl-deftype`?
>>
>> That would be great. But I need some help here to correctly dispatch
>> all functions in gtype to Emacs libraries: cl-macs, cl-generic ?
>
> Not `cl-generic`, but yes `cl-macs.el` with maybe some parts in
> `cl-preloaded.el` and/or `cl-lib.el` and/or `cl-extra.el`.
Shouldn't the code related to method dispatching, at the end of gtype.el,
go to cl-generic?
>> May be in this case, gtype should be moved to the cl namespace too.
>
> Yup. I guess they'd become "cl-types" instead of "gtypes".
>
>> Or do you envision something different?
>
> I was thinking that the main(only?) difference between `cl-deftype` and
> `gdeftype` is:
>
> - the PARENTS argument, where the question is how to add a PARENTS
> argument. Maybe we could use a (declare (parents ...))?
Another possibility could be to have 2 separate definitions:
- cl-deftype to define a data type, as currently.
- cl-types-generalize (or something better) to declare a type previously
defined by cl-deftype usable to dispatch methods, with specified parents?
(cl-deftype my-type ()
"A user defined type."
...)
(cl-types-generalize my-type) ;; No parents
(cl-deftype my-type1 ()
"Another user defined type."
...)
(cl-types-generalize my-type1 my-type) ;; With parents
It should be possible also to "un-generalize" a type.
> - The ARGS: Clearly your `gtype-of` can invent which args to pass
> for a given value to match the resulting type, so `gtype-of` (and
> everything which relies on it, i.e. method dispatch) wouldn't be
> usable for types with a non-empty arglist.
I am not sure I understand this point regarding ARGS.
Is this related to the `cl-deftype' arguments which cannot be used to
declare argument type of methods:
(defgtype unsigned-byte nil (&optional bits)
(list 'integer 0 (if (eq bits '*) bits (1- (ash 1 bits)))))
(cl-defmethod my-foo ((n (unsigned-byte 8))) ;; fails
(format "unsigned, %s" n))
But, below is possible instead:
(defgtype u8 unsigned-byte ()
'(unsigned-byte 8))
(cl-defmethod my-foo ((n u8))
(format "unsigned 8bits, %s - also %s"
n (cl-call-next-method)))
(my-foo 100)
=> "unsigned 8bits, 100 - also unsigned, 100"
(my-foo 256)
=> "unsigned, 256"
>
>>> But the above looks rather costly. 🙁
>>
>> emacs -Q on my laptop:
>>
>> Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz
>> Memory: 15,5 GiB of RAM
>>
>> consistently takes around 1 millisecond to check 2000 gtypes, which
>> seems not so bad.
>
> AFAICT its CPU cost is proportional to the number of types defined with
> `defgtype`, so the more popular it gets, the slower it becomes.
> And of course, the cost of each type check is unbounded, so a single
> "expensive" type can slow everything down further.
>
> The usual dispatch is
>
> (lambda (arg &rest args)
> (let ((f (gethash (cl-typeof arg) precomputed-methods-table)))
> (if f
> (apply f arg args)
> ;; Slow case when encountering a new type
> ...)))
>
> where often the most expensive part is `&rest` (which has to allocate
> a list for those remaining arguments),
>
> So we're talking about replacing
>
> &rest + cl-type-of + gethash + if + apply
>
> with a function that loops over N types, calling `cl-typep` on each one
> of them (`cl-typep` itself being a recursive function that basically
> interprets the type language). This is going to slow down dispatch
> *very* significantly for those generic functions that have a method that
> dispatches on a gtype, compared to those that don't.
>
> It's not the end of the world, especially because there's a lot of
> opportunities for optimizations in there, but it's something to keep
> in mind.
Sure.
Thanks you again.
David
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 15 Apr 2025 15:13:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 15 11:13:29 2025
Received: from localhost ([127.0.0.1]:53548 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4hyZ-0002mu-G2
for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 11:13:28 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18849)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u4hyW-0002mD-BO
for 77725 <at> debbugs.gnu.org; Tue, 15 Apr 2025 11:13:25 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3E10110006B;
Tue, 15 Apr 2025 11:13:18 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744729997;
bh=uYFpb0e61Wege3ORHhpLowYofkmlZ/lgu3o/74+UeEU=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Mu8dF6vHa3jPsbRVctGSO9OBOXnbzJP4hE7/uRlMavWqKJIQGQfF4jxdqyTpwTwx1
o8zFooxrEaCP4tiO34f5YLvgoLwbjlFOC1nYHw0zmixFDaijV/+j0B1fAsBtvGLYjk
qKdlSHNWajmg6PQDfmEgpq7k5ya2LruxTVGqHstOtzlgeQngf0Yf2r/TM9tcRIVeoF
qF3XhzqJa+ftSFxZBQjg8dpy5GhtWBoEmElGVEy9hJ15cu3N55UrBHlWMZOfmRSgij
kJ6T27bpyyHfkh2+F6yMayYxyDEXQph6NKBFtkC0A4Kj/JC51A0Rcjq8x2st7ZRiY3
zzyY6Tfd+j0WQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4E54F100027;
Tue, 15 Apr 2025 11:13:17 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 27F24120323;
Tue, 15 Apr 2025 11:13:17 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
Message-ID: <jwv4iyp4i8x.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
<e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
Date: Tue, 15 Apr 2025 11:13:16 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.378 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> (eval-when-compile (require 'cl-macs)) ;For cl--find-class.
>> You can also use `cl-find-class` which doesn't require this gymnastics.
>
> Done. I didn't know about this public version of `cl--find-class'.
> However, as it seems not possible to write:
>
> `(setf (cl-find-class object) value)'
Ah, right, we still don't have a pubic version of defining a class,
indeed, sorry. I guess `cl--find-class` it is, huh.
>> I get the impression that the role/impact of PARENTS is not explained
>> clearly enough. The explanation should be clear enough that the reader
>> can infer more or less what could happen if a parent is missing or if
>> a non-parent is incorrectly listed as a parent.
> This is a very good point. Currently, the role of PARENTS is limited
> to specify in which order gtype `gtype-of' will check gtypes.
Why does this order matter? I thought the PARENTS was used just in
`gtype--specializers` to sort the various types.
> For instance, you can do something like this:
>
> (defgtype a-fixnum nil ()
> 'fixnum)
>
> (gtype-of 10)
> (a-fixnum fixnum)
>
> (defgtype a-fixnum-between-1-10 a-fixnum ()
> `(satisfies ,(lambda (x) (and (numberp x) (> x 0) (< x 11)))))
>
> (gtype-of 10.1)
> (a-fixnum-between-1-10 float)
> gtype--list
> (a-fixnum-between-1-10 a-fixnum)
>
> Clearly 10.1 is not "a-fixnum-between-1-10", because the type
> specifier is incorrect; even if `a-fixnum-between-1-10' is a subtype
> of `a-fixnum'.
>
> The correct subtype could be:
>
> (defgtype a-fixnum-between-1-10 a-fixnum ()
> `(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
>
> But the type specifier is not produced automatically.
AFAICT the error will manifest itself in the fact that
`gtype--specializers` will return
(a-fixnum-between-1-10 a-fixnum float fixnum integer ...)
so a method defined `a-fixnum` may end up incorrectly invoked in this case.
In contrast if `a-fixnum` is missing:
(defgtype a-fixnum-between-1-10 nil ()
`(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
then `gtype--specializers` may end up returning
(a-fixnum a-fixnum-between-1-10 float fixnum integer ...)
so a method defined for `a-fixnum` may take precedence over one defined
for `a-fixnum-between-1-10`.
> Not so easy to put all this in a docstring. Any idea?
AFAICT, missing PARENTS may cause incorrect ordering of methods,
while extraneous PARENTS may cause use of extraneous methods.
>>> (declare (debug cl-defmacro) (doc-string 4) (indent 3))
>>> (cl-with-gensyms (err)
>>> `(condition-case ,err
>>> (progn
>>> (cl-deftype ,name ,@args)
>>> (gtype--register ',name ',parents ',args))
>>> (error
>>> (gtype--unregister ',name)
>>> (error (error-message-string ,err))))))
>> Could we merge this into `cl-deftype`?
>
> That would be great. But I need some help here to correctly dispatch
> all functions in gtype to Emacs libraries: cl-macs, cl-generic ?
Not `cl-generic`, but yes `cl-macs.el` with maybe some parts in
`cl-preloaded.el` and/or `cl-lib.el` and/or `cl-extra.el`.
> May be in this case, gtype should be moved to the cl namespace too.
Yup. I guess they'd become "cl-types" instead of "gtypes".
> Or do you envision something different?
I was thinking that the main(only?) difference between `cl-deftype` and
`gdeftype` is:
- the PARENTS argument, where the question is how to add a PARENTS
argument. Maybe we could use a (declare (parents ...))?
- The ARGS: Clearly your `gtype-of` can invent which args to pass
for a given value to match the resulting type, so `gtype-of` (and
everything which relies on it, i.e. method dispatch) wouldn't be
usable for types with a non-empty arglist.
>> But the above looks rather costly. =F0=9F=99=81
>
> emacs -Q on my laptop:
>
> Processors: 8 =C3=97 Intel=C2=AE Core=E2=84=A2 i7-7700HQ CPU @ 2.80GHz
> Memory: 15,5 GiB of RAM
>
> consistently takes around 1 millisecond to check 2000 gtypes, which
> seems not so bad.
AFAICT its CPU cost is proportional to the number of types defined with
`defgtype`, so the more popular it gets, the slower it becomes.
And of course, the cost of each type check is unbounded, so a single
"expensive" type can slow everything down further.
The usual dispatch is
(lambda (arg &rest args)
(let ((f (gethash (cl-typeof arg) precomputed-methods-table)))
(if f
(apply f arg args)
;; Slow case when encountering a new type
...)))
where often the most expensive part is `&rest` (which has to allocate
a list for those remaining arguments),
So we're talking about replacing
&rest + cl-type-of + gethash + if + apply
with a function that loops over N types, calling `cl-typep` on each one
of them (`cl-typep` itself being a recursive function that basically
interprets the type language). This is going to slow down dispatch
*very* significantly for those generic functions that have a method that
dispatches on a gtype, compared to those that don't.
It's not the end of the world, especially because there's a lot of
opportunities for optimizations in there, but it's something to keep
in mind.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 15 Apr 2025 09:31:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 15 05:31:14 2025
Received: from localhost ([127.0.0.1]:50695 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4cdN-0005By-Dv
for submit <at> debbugs.gnu.org; Tue, 15 Apr 2025 05:31:14 -0400
Received: from smtp-26.smtpout.orange.fr ([80.12.242.26]:35423
helo=smtp.smtpout.orange.fr)
by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u4cdG-0005BP-5w
for 77725 <at> debbugs.gnu.org; Tue, 15 Apr 2025 05:31:09 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 4cd8u3VVA2zsA4cdCuBLLG; Tue, 15 Apr 2025 11:31:04 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744709464;
bh=onn+OKbV2YH2sALAUPnMKhfmSN2BOFCacNtvU2p3DY8=;
h=Message-ID:Date:MIME-Version:Subject:To:From;
b=fiAIOoKq/shXPEEjY6t2pCTEof4yRgskTeuVMzvLee27/5L/xC0JWn4wMh2kx5+tp
1HKdqDXdieYyqytSd6T7yOr/1S49eYM/ulOu5iuFlvLUy/pD4NVpGZWYOpTSV8mQ+O
DwzEkH4EU/0TWBN1t/T6HIe739/T7y2guperiguR9KmP8K42sXt2DGr2243ag1m/Bo
H6a0jaTgfFweHbv3XemNpQGXT7H/nZPKUxD7rg6OLE3nh0Dr/+IBP+Tnv6tCI65S9U
XA5q48mDw+CeD4R1QGeeETrxtK3gjpAnPaQwF+6/8/5aLlZ4aV13kVCHSNVxy0jdqP
V6mpbOEYzCv4A==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Tue, 15 Apr 2025 11:31:04 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------VcIOq35tljgy1x8KnkSj0iEX"
Message-ID: <e657ab9e-259a-4b83-8ab9-5f51cae7460b@HIDDEN>
Date: Tue, 15 Apr 2025 11:30:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep'
to cl-generic?
To: Stefan Monnier <monnier@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
<jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
Content-Language: fr, en-US
From: David Ponce <da_vid@HIDDEN>
In-Reply-To: <jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------VcIOq35tljgy1x8KnkSj0iEX
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 2025-04-14 20:27, Stefan Monnier wrote:
>> I understand more how cl-generic works, and I reworked gtype.el
>> (attached) according to your inputs and my better understanding.
>
> Looks good, thanks.
Thank you for your review! My answers below.
>> (eval-when-compile (require 'cl-macs)) ;For cl--find-class.
>
> You can also use `cl-find-class` which doesn't require this gymnastics.
Done. I didn't know about this public version of `cl--find-class'.
However, as it seems not possible to write:
`(setf (cl-find-class object) value)'
I had to use `put' instead in one place in `gtype--register'.
>> (define-inline gtype-p (object)
>> "Return non-nil if the type of OBJECT is a gtype."
>> (inline-letevals (object)
>> (inline-quote
>> (and (symbolp ,object)
>> (eq (type-of (cl--find-class ,object)) 'gtype-class)))))
>
> I hope this function is not speed-critical (and so can be a plain `defun`).
>
>> (define-inline gtype-parents (name)
>> "Get parents of type with NAME.
>> NAME is a symbol representing a type.
>> Return a possibly empty list of types."
>> (inline-quote
>> (cl--class-allparents (cl--find-class ,name))))
>
> Same here.
Done. I didn't notice any significant impact on performance :-)
>> (defun gtype--topologic-sort (graph &optional tie-breaker)
>
> How is this different from `merge-ordered-lists`?
The result of the two functions are slightly different but seems
consistent, so I switched to `merge-ordered-lists'.
>> ;;;###autoload
>> (defmacro defgtype (name &optional parents &rest args)
>> "Define NAME as a gtype that inherits from PARENTS.
>
> Inheritance != subtyping. Better stick to the term "subtype" here since
> there doesn't seem to be any inheritance going on here.
Done.
> I get the impression that the role/impact of PARENTS is not explained
> clearly enough. The explanation should be clear enough that the reader
> can infer more or less what could happen if a parent is missing or if
> a non-parent is incorrectly listed as a parent.
This is a very good point. Currently, the role of PARENTS is limited
to specify in which order gtype `gtype-of' will check gtypes.
This order is not automatically transposed to the type specifier of
`cl-deftype'. And there is a risk of inconsistency here.
For instance, you can do something like this:
(defgtype a-fixnum nil ()
'fixnum)
(gtype-of 10)
(a-fixnum fixnum)
(defgtype a-fixnum-between-1-10 a-fixnum ()
`(satisfies ,(lambda (x) (and (numberp x) (> x 0) (< x 11)))))
(gtype-of 10.1)
(a-fixnum-between-1-10 float)
gtype--list
(a-fixnum-between-1-10 a-fixnum)
Clearly 10.1 is not "a-fixnum-between-1-10", because the type
specifier is incorrect; even if `a-fixnum-between-1-10' is a subtype
of `a-fixnum'.
The correct subtype could be:
(defgtype a-fixnum-between-1-10 a-fixnum ()
`(and a-fixnum (satisfies ,(lambda (x) (> x 0) (< x 11)))))
But the type specifier is not produced automatically.
Not so easy to put all this in a docstring. Any idea?
>> (declare (debug cl-defmacro) (doc-string 4) (indent 3))
>> (cl-with-gensyms (err)
>> `(condition-case ,err
>> (progn
>> (cl-deftype ,name ,@args)
>> (gtype--register ',name ',parents ',args))
>> (error
>> (gtype--unregister ',name)
>> (error (error-message-string ,err))))))
>
> Could we merge this into `cl-deftype`?
That would be great. But I need some help here to correctly dispatch
all functions in gtype to Emacs libraries: cl-macs, cl-generic ? May
be in this case, gtype should be moved to the cl namespace too.
Or do you envision something different?
>> (defmacro remgtype (name)
>
> Try and stay within the namespace prefix.
Renamed to `gtype-remove'.
>> (defun gtype-of (object)
>> "Return the most specific possible gtype OBJECT belongs to.
>> Return an unique list of types OBJECT belongs to, ordered from the
>> most specific type to the most general."
>> ;; Ignore recursive call on the same OBJECT, which can legitimately
>> ;; occur when, for example, a parent type is investigating whether
>> ;; an object's type is that of one of its children.
>> (unless (eq object gtype--object)
>> (let ((gtype--object object)
>> (found (list (cl-type-of object))))
>> ;; Collect all gtypes OBJECT belongs to.
>> (dolist (gtype gtype--list)
>> (if (cl-typep object gtype)
>> (push gtype found)))
>> ;; Return an unique value of type.
>> (with-memoization (gethash found gtype--unique)
>> found))))
>
> Since `gtype-of` is the function used to get the "tagcode" used for
> method-dispatch, it is speed-critical.
I agree.
> But the above looks rather costly. 🙁
emacs -Q on my laptop:
Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz
Memory: 15,5 GiB of RAM
consistently takes around 1 millisecond to check 2000 gtypes, which
seems not so bad.
Here is the benchmark I use:
(defgtype cons-car-foo nil ()
"A cons with a `foo' car."
`(satisfies ,(lambda (x) (eq (car-safe x) 'foo))))
(defgtype cons-cdr-foo nil ()
"A cons with a `foo' cdr."
`(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo))))
(gtype-of '(foo . foo))
=> (cons-car-foo cons-cdr-foo cons)
;; Create a very long list of gtypes that gtype-of will check
;; sequentially.
(let* ((count 2000)
(gtype--list (let ((list '(cons-cdr-foo)))
(dotimes (_ count)
(push 'cons-car-foo list))
list))
(object '(foo . foo))
(runs 1))
(garbage-collect)
(benchmark-run
(gtype-of object)
runs))
=>(0.00107773 0 0.0)
> I think we could reduce this problem significantly with reasonably
> simple changes to `cl-generic`: we could provide to the TAGCODE-FUNCTION
> the list of specializers used by methods of the current
> generic-function, so we'd only need to check those types which are
> actually useful for the current dispatch.
> [ Hmm... well, maybe not completely "simple" since it might have
> some problematic impact on the `cl--generic-prefill-dispatchers`
> mechanism, but that should be solvable. ]
I am afraid, this looks beyond my knowledge of cl-generic.
>> (defun gtype--specializers (tag &rest _)
>> "If TAG is a gtype, return its specializers."
>> (and (consp tag) (gtype-p (car tag))
>> (with-memoization (gethash tag gtype--specializers)
>> (merge-ordered-lists (mapcar #'gtype-parents tag)))))
>
> AFAIK this function is only ever called with "tagcodes" returned by your
> own TAGCODE-FUNCTION, so I think the `gtype-p` test is redundant.
Good find. Done.
Please find attached the last version.
David
--------------VcIOq35tljgy1x8KnkSj0iEX
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="gtype.el"
Content-Disposition: attachment; filename="gtype.el"
Content-Transfer-Encoding: base64
Ozs7IGd0eXBlLmVsIC0tLSBEYXRhIHR5cGVzIGZvciBnZW5lcmljIGZ1bmN0aW9ucyAtKi0g
bGV4aWNhbC1iaW5kaW5nOnQgLSotCgo7OyBDb3B5cmlnaHQgKEMpIDIwMjUgRGF2aWQgUG9u
Y2UKCjs7IEF1dGhvcjogRGF2aWQgUG9uY2UgPGRhX3ZpZEBvcmFuZ2UuZnI+Cjs7IE1haW50
YWluZXI6IERhdmlkIFBvbmNlIDxkYV92aWRAb3JhbmdlLmZyPgo7OyBDcmVhdGVkOiA2IEFw
cmlsIDIwMjUKOzsgS2V5d29yZHM6IGV4dGVuc2lvbnMKCjs7IFRoaXMgZmlsZSBpcyBub3Qg
cGFydCBvZiBHTlUgRW1hY3MuCgo7OyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTog
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCjs7IG1vZGlmeSBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzCjs7IHB1Ymxpc2hl
ZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRoZXIgdmVyc2lvbiAzIG9m
IHRoZQo7OyBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u
LgoKOzsgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg
d2lsbCBiZSB1c2VmdWwsIGJ1dAo7OyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCjs7IE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCjs7IEdlbmVyYWwg
UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCjs7IFlvdSBzaG91bGQgaGF2ZSBy
ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCjs7IGFs
b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcv
bGljZW5zZXMvPi4KCjs7OyBDb21tZW50YXJ5Ogo7Owo7OyBUaGlzIGxpYnJhcnkgZXh0ZW5k
cyBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIGBndHlwZXMnLCBpLmUuIGRhdGEKOzsgdHlwZXMg
ZGVmaW5lZCBieSAnY2wtZGVmdHlwZScgd2hpY2ggYXJlIGFsc28gdmFsaWQgYXJndW1lbnQg
dHlwZXMKOzsgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcyAoc2Vl
IGFsc28gQnVnIzc3NzI1IGF0Cjs7IDxodHRwczovL2RlYmJ1Z3MuZ251Lm9yZy9jZ2kvYnVn
cmVwb3J0LmNnaT9idWc9Nzc3MjU+KS4KOzsKOzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFy
ZToKOzsKOzsgLSBgZGVmZ3R5cGUnLCBhIG1hY3JvIHRoYXQgZGVmaW5lcyBhIGd0eXBlLgo7
Owo7OyAtIGBndHlwZS1vZicsIGEgZnVuY3Rpb24gdGhhdCBsb29rdXAgdGhlIGd0eXBlIG9m
IGFuIG9iamVjdC4KOzsKOzsgLSBgZ3R5cGUtcmVtb3ZlJywgYSBtYWNybyB0aGF0IHJlbW92
ZXMgYSBndHlwZS4KOzsKOzsgQSB0cml2aWFsIGV4YW1wbGU6Cjs7Cjs7IChkZWZndHlwZSBu
ZWdhdGl2ZSBuaWwgKCkKOzsgICAiQSBuZWdhdGl2ZSBudW1iZXIiCjs7ICAgJyhhbmQgbnVt
YmVyIChzYXRpc2ZpZXMgbWludXNwKSkpCjs7Cjs7IChkZWZndHlwZSB6ZXJvIG5pbCAoKQo7
OyAgICJBIHplcm8gbnVtYmVyIgo7OyAgICcoYW5kIG51bWJlciAoc2F0aXNmaWVzIHplcm9w
KSkpCjs7Cjs7IChkZWZndHlwZSBwb3NpdGl2ZSBuaWwgKCkKOzsgICAiQSBwb3NpdGl2ZSBu
dW1iZXIiCjs7ICAgJyhhbmQgbnVtYmVyIChzYXRpc2ZpZXMgcGx1c3ApKSkKOzsKOzsgKGNs
LWRlZm1ldGhvZCB0ZXN0LW51bWJlciAoKG4gbmVnYXRpdmUpKQo7OyAgIChmb3JtYXQgIm5l
Z2F0aXZlIG51bWJlciwgJXMiIG4pKQo7Owo7OyAoY2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVy
ICgobiB6ZXJvKSkKOzsgICAoZm9ybWF0ICJ6ZXJvIG51bWJlciwgJXMiIG4pKQo7Owo7OyAo
Y2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVyICgobiBwb3NpdGl2ZSkpCjs7ICAgKGZvcm1hdCAi
cG9zaXRpdmUgbnVtYmVyLCAlcyIgbikpCjs7Cjs7ICh0ZXN0LW51bWJlciAtMTIzLjApCjs7
ID0+ICJuZWdhdGl2ZSBudW1iZXIsIC0xMjMuMCIKOzsgKHRlc3QtbnVtYmVyIChhYnMgLTEy
My4wKSkKOzsgPT4gInBvc2l0aXZlIG51bWJlciwgMTIzLjAiCjs7ICh0ZXN0LW51bWJlciAo
cm91bmQgMC4wMDAwMDAwMDAwMDEpKQo7OyA9PiAiemVybyBudW1iZXIsIDAiCjs7Cjs7IFBl
cmZvcm1hbmNlIGNvbnNpZGVyYXRpb25zOgo7Owo7OyBUaGUgY3JpdGljYWwgcG9pbnQgb2Yg
dGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gaXMgdGhlIGZ1bmN0aW9uCjs7IGBndHlwZS1v
Zicgd2hpY2ggc2VxdWVudGlhbGx5IHRyaWVzIGFsbCBrbm93biBndHlwZXMgdG8gY29sbGVj
dCBhbGwKOzsgdGhvc2UgYW4gb2JqZWN0IGJlbG9uZ3MgdG8sIGZyb20gdGhlIG1vc3Qgc3Bl
Y2lmaWMgdG8gdGhlIG1vc3QKOzsgZ2VuZXJhbCB0eXBlLiAgVGhlcmVmb3JlLCB0aGUgbWF4
aW11bSB0aW1lIHRvIGZpbmQgYW4gb2JqZWN0J3MgdHlwZQo7OyBkaXJlY3RseSBkZXBlbmRz
IG9uIHRoZSBudW1iZXIgb2YgZ3R5cGVzLiAgSXMgdGhlcmUgYSBiZXR0ZXIKOzsgc29sdXRp
b24/ICBBbnl3YXksIGFzc3VtaW5nIHRoYXQgZWFjaCBzaW5nbGUgdGVzdCB0byBrbm93IHdo
ZXRoZXIKOzsgYW4gb2JqZWN0IGlzIG9mIGEgZ2l2ZW4gZ3R5cGUgaXMgcmVhc29uYWJseSBm
YXN0LCB0aGUgcGVyZm9ybWFuY2UKOzsgb2YgdGhpcyBpbXBsZW1lbnRhdGlvbiBzZWVtcyBh
Y2NlcHRhYmxlIChiYXNlZCBvbiB0aGUgdHJpdmlhbAo7OyBleGFtcGxlIGFib3ZlLCBhdHRl
bXB0aW5nIDEsMDAwIGd0eXBlIGNoZWNrcyB0YWtlcyBhYm91dCBoYWxmIGEKOzsgbWlsbGlz
ZWNvbmQgb24gbXkgc2V0dXApLgo7OwoKOzs7IENvZGU6Cjs7CihyZXF1aXJlICdjbC1saWIp
CgooZGVmdmFyIGd0eXBlLS1saXN0IG5pbAogICJQcmVjZWRlbmNlIGxpc3Qgb2YgdGhlIGRl
ZmluZWQgZ3R5cGVzLiIpCgooZGVmdW4gZ3R5cGUtcCAob2JqZWN0KQogICJSZXR1cm4gbm9u
LW5pbCBpZiB0aGUgdHlwZSBvZiBPQkpFQ1QgaXMgYSBndHlwZS4iCiAgKGFuZCAoc3ltYm9s
cCBvYmplY3QpCiAgICAgICAoZXEgKHR5cGUtb2YgKGNsLWZpbmQtY2xhc3Mgb2JqZWN0KSkg
J2d0eXBlLWNsYXNzKSkpCgooY2wtZGVmc3RydWN0CiAgICAoZ3R5cGUtY2xhc3MKICAgICAo
OmluY2x1ZGUgY2wtLWNsYXNzKQogICAgICg6bm9pbmxpbmUgdCkKICAgICAoOmNvbnN0cnVj
dG9yIG5pbCkKICAgICAoOmNvbnN0cnVjdG9yIGd0eXBlLS1jbGFzcy1tYWtlCiAgICAgICAg
ICAgICAgICAgICAobmFtZQogICAgICAgICAgICAgICAgICAgIGRvY3N0cmluZwogICAgICAg
ICAgICAgICAgICAgIHBhcmVudC10eXBlcwogICAgICAgICAgICAgICAgICAgICZhdXggKHBh
cmVudHMKICAgICAgICAgICAgICAgICAgICAgICAgICAobWFwY2FyCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIChsYW1iZGEgKHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKGNsLWNoZWNrLXR5cGUgdHlwZSAoc2F0aXNmaWVzIGd0eXBlLXApKQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChjbC1maW5kLWNsYXNzIHR5cGUpKQogICAgICAgICAgICAg
ICAgICAgICAgICAgICBwYXJlbnQtdHlwZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAi
VHlwZSBkZXNjcmlwdG9ycyBmb3IgZ3R5cGVzLiIpCgooZGVmdW4gZ3R5cGUtcGFyZW50cyAo
bmFtZSkKICAiR2V0IHBhcmVudHMgb2YgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1i
b2wgcmVwcmVzZW50aW5nIGEgdHlwZS4iCiAgKGNsLS1jbGFzcy1hbGxwYXJlbnRzIChjbC1m
aW5kLWNsYXNzIG5hbWUpKSkKCihkZWZ1biBndHlwZS1jaGlsZHJlbiAobmFtZSkKICAiR2V0
IGNoaWxkcmVuIG9mIHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVw
cmVzZW50aW5nIGEgZ3R5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlw
ZXMuIgogIChjbC1jaGVjay10eXBlIG5hbWUgKHNhdGlzZmllcyBndHlwZS1wKSkKICAobGV0
IChjaGlsZHJlbikKICAgIChkb2xpc3QgKGVsdCBndHlwZS0tbGlzdCkKICAgICAgKG9yIChl
cSBuYW1lIGVsdCkKICAgICAgICAgIChpZiAobWVtcSBuYW1lIChndHlwZS1wYXJlbnRzIGVs
dCkpCiAgICAgICAgICAgICAgKHB1c2ggZWx0IGNoaWxkcmVuKSkpKQogICAgY2hpbGRyZW4p
KQoKKGRlZnVuIGd0eXBlLS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZyb20gdGhlIGxpc3Qg
b2YgZGVmaW5lZCBndHlwZXMuIgogIChjbC1sYWJlbHMgKChhbGxwYXJlbnRzIChjbGFzcykK
ICAgICAgICAgICAgICAgIChsZXQgKCh0eXBlIChjbC0tY2xhc3MtbmFtZSBjbGFzcykpKQog
ICAgICAgICAgICAgICAgICA7OyBFeGNsdWRlIG5vbi1ndHlwZXMgZnJvbSB0aGUgREFHLiAg
YGd0eXBlLW9mJwogICAgICAgICAgICAgICAgICA7OyBkb2Vzbid0IGNoZWNrIG5vbi1ndHlw
ZXMgYXQgcnVuIHRpbWUsIHRoZXkgYXJlCiAgICAgICAgICAgICAgICAgIDs7IGhhbmRsZWQg
YnkgdGhlICJ0eXBlLW9mIiBnZW5lcmFsaXplci4KICAgICAgICAgICAgICAgICAgKGlmIChn
dHlwZS1wIHR5cGUpCiAgICAgICAgICAgICAgICAgICAgICAoY29ucyB0eXBlCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cwogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIChtYXBjYXIgIydhbGxwYXJlbnRzCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAoY2wtLWNsYXNzLXBhcmVudHMgY2xhc3MpKSkpKSkpKQog
ICAgKG1hcGNhciAobGFtYmRhIChndHlwZSkgKGFsbHBhcmVudHMgKGNsLS1maW5kLWNsYXNz
IGd0eXBlKSkpCiAgICAgICAgICAgIGd0eXBlLS1saXN0KSkpCgooZGVmdW4gZ3R5cGUtLXJl
Z2lzdGVyIChuYW1lICZvcHRpb25hbCBwYXJlbnRzIGFyZ3MpCiAgIlJlZ2lzdGVyIGEgZ3R5
cGUgd2l0aCBOQU1FIGFuZCBQQVJFTlRTLgpBUkdTIGFyZSB0aG9zZSB0aGF0IHdpbGwgYmUg
cGFzc2VkIHRvIGBjbC1kZWZ0eXBlJy4iCiAgKGNvbmRpdGlvbi1jYXNlIGVycgogICAgICAo
bGV0ICgoY2xhc3MgKGNsLWZpbmQtY2xhc3MgbmFtZSkpCiAgICAgICAgICAgIChyZWdlZCAo
bWVtcSBuYW1lIGd0eXBlLS1saXN0KSkpCiAgICAgICAgKGlmIChudWxsIGNsYXNzKQogICAg
ICAgICAgICAob3IgKG51bGwgcmVnZWQpCiAgICAgICAgICAgICAgICAoZXJyb3IgIk5ldyB0
eXBlLCBidXQgYWxyZWFkeSBpbiBndHlwZXMgbGlzdCIpKQogICAgICAgICAgKG9yIHJlZ2Vk
ICJFeGlzdGluZyB0eXBlLCBidXQgbm90IGluIGd0eXBlcyBsaXN0IikKICAgICAgICAgIChv
ciAoZXEgKHR5cGUtb2YgY2xhc3MpICdndHlwZS1jbGFzcykKICAgICAgICAgICAgICAoZXJy
b3IgIlR5cGUgaW4gYW5vdGhlciBjbGFzczogJVMiICh0eXBlLW9mIGNsYXNzKSkpKQogICAg
ICAgIChvciAobGlzdHAgcGFyZW50cykgKHNldHEgcGFyZW50cyAobGlzdCBwYXJlbnRzKSkp
CiAgICAgICAgKGlmIChtZW1xIG5hbWUgcGFyZW50cykKICAgICAgICAgICAgKGVycm9yICJU
eXBlIGluIHBhcmVudHM6ICVTIiBwYXJlbnRzKSkKICAgICAgICA7OyBTZXR1cCBhIHR5cGUg
ZGVzY3JpcHRvciBmb3IgTkFNRSwgd2l0aCBQQVJFTlRTIGFuZCB0aGUKICAgICAgICA7OyBk
b2NzdHJpbmcgcG9zc2libHkgcHJlc2VudCBpbiBBUkdTLgogICAgICAgIChsZXQgKChkb2Nz
dHJpbmcgKGNhYXIgKG1hY3JvZXhwLXBhcnNlLWJvZHkgKGNkciBhcmdzKSkpKSkKICAgICAg
ICAgIChvciAoc3RyaW5ncCBkb2NzdHJpbmcpIChzZXRxIGRvY3N0cmluZyBuaWwpKQogICAg
ICAgICAgKHB1dCBuYW1lICdjbC0tY2xhc3MKICAgICAgICAgICAgICAgKGd0eXBlLS1jbGFz
cy1tYWtlIG5hbWUgZG9jc3RyaW5nIHBhcmVudHMpKSkKICAgICAgICAoaWYgY2xhc3MKICAg
ICAgICAgICAgOzsgQ2xlYXIgY2FjaGVkIHZhbHVlIG9mIHNwZWNpYWxpemVycyB3aXRoIE5B
TUUuCiAgICAgICAgICAgIChndHlwZS0tcmVzZXQtc3BlY2lhbGl6ZXJzIG5hbWUpCiAgICAg
ICAgICA7OyBSZWNvcmQgdGhlIG5ldyB0eXBlLgogICAgICAgICAgKHB1c2ggbmFtZSBndHlw
ZS0tbGlzdCkpCiAgICAgICAgOzsgVG8gZmluZCB0aGUgbW9zdCBwb3NzaWJsZSBzcGVjaWZp
YyBndHlwZSBvZiBhbiBvYmplY3QsIG1vc3QKICAgICAgICA7OyBzcGVjaWZpYyB0eXBlcyBt
dXN0IGJlIHRyaWVkIGJlZm9yZSBtb3JlIGdlbmVyYWwgdHlwZXMuCiAgICAgICAgKHNldHEg
Z3R5cGUtLWxpc3QgKG1lcmdlLW9yZGVyZWQtbGlzdHMgKGd0eXBlLS1kYWcpKSkKICAgICAg
ICBuYW1lKQogICAgKGVycm9yCiAgICAgKGd0eXBlLS11bnJlZ2lzdGVyIG5hbWUpCiAgICAg
KGVycm9yIChmb3JtYXQgIiVzLCAlUyIgKGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVycikgbmFt
ZSkpKSkpCgooZGVmdW4gZ3R5cGUtLXVucmVnaXN0ZXIgKG5hbWUpCiAgIlVucmVnaXN0ZXIg
dGhlIGd0eXBlIHdpdGggTkFNRS4iCiAgKHdoZW4tbGV0KiAoKGNoaWxkcmVuIChhbmQgKGd0
eXBlLXAgbmFtZSkgKGd0eXBlLWNoaWxkcmVuIG5hbWUpKSkpCiAgICAoZXJyb3IgIlR5cGUg
aGFzIGNoaWxkcmVuOiAlUyIgY2hpbGRyZW4pKQogIDs7IENsZWFyIGNhY2hlZCB2YWx1ZSBv
ZiBzcGVjaWFsaXplcnMgd2l0aCBOQU1FLgogIChndHlwZS0tcmVzZXQtc3BlY2lhbGl6ZXJz
IG5hbWUpCiAgKGNsLXJlbXByb3AgbmFtZSAnZ3R5cGUtLXNlcW4pCiAgKGNsLXJlbXByb3Ag
bmFtZSAnY2wtLWNsYXNzKQogIChjbC1yZW1wcm9wIG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxl
cikKICAoc2V0cSBndHlwZS0tbGlzdCAoZGVscSBuYW1lIGd0eXBlLS1saXN0KSkKICBuaWwp
Cgo7OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gZGVmZ3R5cGUgKG5hbWUgJm9wdGlvbmFsIHBh
cmVudHMgJnJlc3QgYXJncykKICAiRGVmaW5lIE5BTUUgYXMgYSBndHlwZSwgc3VidHlwZSBv
ZiBQQVJFTlRTIGd0eXBlcy4KSWYgYSBndHlwZSB3aXRoIE5BTUUgYWxyZWFkeSBleGlzdHMs
IHJlZGVmaW5lIGl0LiAgT24gZXJyb3IsIE5BTUUgaXMKbm8gbW9yZSBkZWZpbmVkIGFzIGEg
Z3R5cGUuCgpOQU1FIGlzIGFuIHVucXVvdGVkIHN5bWJvbCByZXByZXNlbnRpbmcgYSBndHlw
ZS4KCk9wdGlvbmFsIGFyZ3VtZW50IFBBUkVOVFMgaXMgZWl0aGVyIGFuIHVucXVvdGVkIHN5
bWJvbCBvciBsaXN0IG9mCnN5bWJvbHMgb3RoZXIgdGhhbiBOQU1FIHJlcHJlc2VudGluZyBn
dHlwZXMgd2hvc2UgTkFNRSBpcyBhIHN1YnR5cGUuCgpBbHNvIHBhc3MgTkFNRSBhbmQgQVJH
UyB0byBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIE5BTUUgYXMgYSBuZXcgZGF0YQp0eXBlLiIK
ICAoZGVjbGFyZSAoZGVidWcgY2wtZGVmbWFjcm8pIChkb2Mtc3RyaW5nIDQpIChpbmRlbnQg
MykpCiAgYChwcm9nMSAoZ3R5cGUtLXJlZ2lzdGVyICcsbmFtZSAnLHBhcmVudHMgJyxhcmdz
KQogICAgIChjbC1kZWZ0eXBlICxuYW1lICxAYXJncykpKQoKKGRlZm1hY3JvIGd0eXBlLXJl
bW92ZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYW4g
dW5xdW90ZWQgc3ltYm9sIHJlcHJlc2VudGluZyBhIGd0eXBlLgpTaWduYWwgYW4gZXJyb3Ig
aWYgb3RoZXIgZ3R5cGVzIGluaGVyaXQgZnJvbSBOQU1FLiIKICBgKHByb2duCiAgICAgKGNs
LWNoZWNrLXR5cGUgJyxuYW1lIChzYXRpc2ZpZXMgZ3R5cGUtcCkpCiAgICAgKGd0eXBlLS11
bnJlZ2lzdGVyICcsbmFtZSkpKQoKOzsgSW50ZXJuYWwgZGF0YSB1c2VkIHRvIGRldGVjdCBl
bmRsZXNzIHJlY3Vyc2lvbiBpbiAnZ3R5cGUtb2YnLgooZGVmdmFyIGd0eXBlLS1vYmplY3Qg
KG1ha2Utc3ltYm9sICJ2b2lkIikpCjs7IEVhY2ggZ3R5cGUgbXVzdCBzYXRpc2ZpZXMgYGVx
bCcuCihkZWZ2YXIgZ3R5cGUtLXVuaXF1ZSAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVh
bCkKICAiUmVjb3JkIGFuIHVuaXF1ZSB2YWx1ZSBmb3IgZWFjaCBndHlwZS4iKQoKKGRlZnVu
IGd0eXBlLW9mIChvYmplY3QpCiAgIlJldHVybiB0aGUgbW9zdCBzcGVjaWZpYyBwb3NzaWJs
ZSBndHlwZSBPQkpFQ1QgYmVsb25ncyB0by4KUmV0dXJuIGFuIHVuaXF1ZSBsaXN0IG9mIHR5
cGVzIE9CSkVDVCBiZWxvbmdzIHRvLCBvcmRlcmVkIGZyb20gdGhlCm1vc3Qgc3BlY2lmaWMg
dHlwZSB0byB0aGUgbW9zdCBnZW5lcmFsLiIKICA7OyBJZ25vcmUgcmVjdXJzaXZlIGNhbGwg
b24gdGhlIHNhbWUgT0JKRUNULCB3aGljaCBjYW4gbGVnaXRpbWF0ZWx5CiAgOzsgb2NjdXIg
d2hlbiwgZm9yIGV4YW1wbGUsIGEgcGFyZW50IHR5cGUgaXMgaW52ZXN0aWdhdGluZyB3aGV0
aGVyCiAgOzsgYW4gb2JqZWN0J3MgdHlwZSBpcyB0aGF0IG9mIG9uZSBvZiBpdHMgY2hpbGRy
ZW4uCiAgKHVubGVzcyAoZXEgb2JqZWN0IGd0eXBlLS1vYmplY3QpCiAgICAobGV0ICgoZ3R5
cGUtLW9iamVjdCBvYmplY3QpCiAgICAgICAgICAoZm91bmQgKGxpc3QgKGNsLXR5cGUtb2Yg
b2JqZWN0KSkpKQogICAgICA7OyBDb2xsZWN0IGFsbCBndHlwZXMgT0JKRUNUIGJlbG9uZ3Mg
dG8uCiAgICAgIChkb2xpc3QgKGd0eXBlIGd0eXBlLS1saXN0KQogICAgICAgIChpZiAoY2wt
dHlwZXAgb2JqZWN0IGd0eXBlKQogICAgICAgICAgICAocHVzaCBndHlwZSBmb3VuZCkpKQog
ICAgICA7OyBSZXR1cm4gYW4gdW5pcXVlIHZhbHVlIG9mIHR5cGUuCiAgICAgICh3aXRoLW1l
bW9pemF0aW9uIChnZXRoYXNoIGZvdW5kIGd0eXBlLS11bmlxdWUpCiAgICAgICAgZm91bmQp
KSkpCgo7OzsgTWV0aG9kIGRpc3BhdGNoaW5nCjs7CihkZWZ2YXIgZ3R5cGUtLXNwZWNpYWxp
emVycyAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcSkKICAiTWVtb2l6ZSBndHlwZSBzcGVj
aWFsaXplcnMuClRoaXMgY2FjaGUgaXMgY2xlYXJlZCBieSBgZ3R5cGUtLXJlZ2lzdGVyJyBh
bmQgYGd0eXBlLS11bnJlZ2lzdGVyJy4iKQoKKGRlZnVuIGd0eXBlLS1yZXNldC1zcGVjaWFs
aXplcnMgKG5hbWUpCiAgIlJlbW92ZSBhbGwgY2FjaGVkIHZhbHVlIG9mIHNwZWNpYWxpemVy
cyB3aXRoIE5BTUUuIgogIChtYXBoYXNoIChsYW1iZGEgKGtleSBfKQogICAgICAgICAgICAg
KGlmIChtZW1xIG5hbWUga2V5KQogICAgICAgICAgICAgICAgIChyZW1oYXNoIGtleSBndHlw
ZS0tc3BlY2lhbGl6ZXJzKSkpCiAgICAgICAgICAgZ3R5cGUtLXNwZWNpYWxpemVycykpCgoo
ZGVmdW4gZ3R5cGUtLXNwZWNpYWxpemVycyAodGFnICZyZXN0IF8pCiAgIklmIFRBRyBpcyBh
IGd0eXBlLCByZXR1cm4gaXRzIHNwZWNpYWxpemVycy4iCiAgOzsgVGhpcyBmdW5jdGlvbiBp
cyBvbmx5IGV2ZXIgY2FsbGVkIHdpdGggInRhZ2NvZGVzIiByZXR1cm5lZCBieQogIDs7IGBn
dHlwZS1vZicsIHNvIHRoZSBgZ3R5cGUtcCcgdGVzdCBpcyByZWR1bmRhbnQuCiAgKGFuZCAo
Y29uc3AgdGFnKSA7OyAoZ3R5cGUtcCAoY2FyIHRhZykpCiAgICAgICAod2l0aC1tZW1vaXph
dGlvbiAoZ2V0aGFzaCB0YWcgZ3R5cGUtLXNwZWNpYWxpemVycykKICAgICAgICAgKG1lcmdl
LW9yZGVyZWQtbGlzdHMgKG1hcGNhciAjJ2d0eXBlLXBhcmVudHMgdGFnKSkpKSkKCihjbC1n
ZW5lcmljLWRlZmluZS1nZW5lcmFsaXplciBndHlwZS0tZ2VuZXJhbGl6ZXIKICAyMCA7OyAi
dHlwZW9mIiBwcmlvcml0eSA8ICJndHlwZS1vZiIgcHJpb3JpdHkgPCAiaGVhZCIgcHJpb3Jp
dHkKICAobGFtYmRhIChvYmogJnJlc3QgXykgYChndHlwZS1vZiAsb2JqKSkKICAjJ2d0eXBl
LS1zcGVjaWFsaXplcnMpCgooY2wtZGVmbWV0aG9kIGNsLWdlbmVyaWMtZ2VuZXJhbGl6ZXJz
IDpleHRyYSAiZ3R5cGUtb2YiICh0eXBlKQogICJTdXBwb3J0IGZvciBkaXNwYXRjaCBvbiBn
dHlwZXMuIgogIChpZiAoZ3R5cGUtcCB0eXBlKQogICAgICAobGlzdCBndHlwZS0tZ2VuZXJh
bGl6ZXIpCiAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQoKKHByb3ZpZGUgJ2d0eXBlKQoK
Ozs7IGd0eXBlLmVsIGVuZHMgaGVyZQo=
--------------VcIOq35tljgy1x8KnkSj0iEX--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 14 Apr 2025 18:27:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 14 14:27:12 2025
Received: from localhost ([127.0.0.1]:48946 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4OWW-0002ZQ-5M
for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 14:27:12 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47983)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u4OWS-0002ZB-Oa
for 77725 <at> debbugs.gnu.org; Mon, 14 Apr 2025 14:27:09 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3FB9D80860;
Mon, 14 Apr 2025 14:27:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744655221;
bh=QCL8PHb28WMr+cpFsspVXKxD74FdIj0XF6kwv20eQts=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=QH41ooHBgLOvpCcScTqwG3HllciIxWdceVO2W/Xhrdqfn8wNQGHN2wwq+4mMwEbRc
gDfBy1b1G2eZJniGdz5/7/rahoJ1PcJ30Q6lh63a1RMxiiS1BaBaVOPp+DCcw0iXgP
/REZ9Ynds8puLC2P+rwo37m/IQ4qmODWydWYF+TIaiy2mil+bNaE0ms2ciYmK+rQ4b
S3BMd69uZfaPl9V3nbxALX09RrxX266lzE1MZfBJHIhnzZpWWq/Q6ceU5lK9Ts+613
kwYwkgRWrwaX6Nsm9MH/3+U3RoGBYcUUfZ+ATHacMuAYk2jVzMZFZR8d+Q9yc3p1Se
ki32u/s7zEs1A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 35CF280644;
Mon, 14 Apr 2025 14:27:01 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0F689120550;
Mon, 14 Apr 2025 14:27:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
Message-ID: <jwvcydek5ax.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
<jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
<5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN>
Date: Mon, 14 Apr 2025 14:27:00 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.184 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> I understand more how cl-generic works, and I reworked gtype.el
> (attached) according to your inputs and my better understanding.
Looks good, thanks.
Some comments below.
> (eval-when-compile (require 'cl-macs)) ;For cl--find-class.
You can also use `cl-find-class` which doesn't require this gymnastics.
> (define-inline gtype-p (object)
> "Return non-nil if the type of OBJECT is a gtype."
> (inline-letevals (object)
> (inline-quote
> (and (symbolp ,object)
> (eq (type-of (cl--find-class ,object)) 'gtype-class)))))
I hope this function is not speed-critical (and so can be a plain `defun`).
> (define-inline gtype-parents (name)
> "Get parents of type with NAME.
> NAME is a symbol representing a type.
> Return a possibly empty list of types."
> (inline-quote
> (cl--class-allparents (cl--find-class ,name))))
Same here.
> (defun gtype--topologic-sort (graph &optional tie-breaker)
How is this different from `merge-ordered-lists`?
> ;;;###autoload
> (defmacro defgtype (name &optional parents &rest args)
> "Define NAME as a gtype that inherits from PARENTS.
Inheritance !=3D subtyping. Better stick to the term "subtype" here since
there doesn't seem to be any inheritance going on here.
> If a gtype with NAME already exists, replace it.
>
> NAME is an unquoted symbol representing a gtype.
>
> Optional argument PARENTS is either an unquoted symbol or list of
> symbols other than NAME representing types parents of NAME.
> PARENTS nil or omitted means that NAME is a root type.
>
> Also pass NAME and ARGS to `cl-deftype' to define NAME as a new data
> type."
I get the impression that the role/impact of PARENTS is not explained
clearly enough. The explanation should be clear enough that the reader
can infer more or less what could happen if a parent is missing or if
a non-parent is incorrectly listed as a parent.
> (declare (debug cl-defmacro) (doc-string 4) (indent 3))
> (cl-with-gensyms (err)
> `(condition-case ,err
> (progn
> (cl-deftype ,name ,@args)
> (gtype--register ',name ',parents ',args))
> (error
> (gtype--unregister ',name)
> (error (error-message-string ,err))))))
Could we merge this into `cl-deftype`?
> (defmacro remgtype (name)
Try and stay within the namespace prefix.
> (defun gtype-of (object)
> "Return the most specific possible gtype OBJECT belongs to.
> Return an unique list of types OBJECT belongs to, ordered from the
> most specific type to the most general."
> ;; Ignore recursive call on the same OBJECT, which can legitimately
> ;; occur when, for example, a parent type is investigating whether
> ;; an object's type is that of one of its children.
> (unless (eq object gtype--object)
> (let ((gtype--object object)
> (found (list (cl-type-of object))))
> ;; Collect all gtypes OBJECT belongs to.
> (dolist (gtype gtype--list)
> (if (cl-typep object gtype)
> (push gtype found)))
> ;; Return an unique value of type.
> (with-memoization (gethash found gtype--unique)
> found))))
Since `gtype-of` is the function used to get the "tagcode" used for
method-dispatch, it is speed-critical.
But the above looks rather costly. =F0=9F=99=81
I think we could reduce this problem significantly with reasonably
simple changes to `cl-generic`: we could provide to the TAGCODE-FUNCTION
the list of specializers used by methods of the current
generic-function, so we'd only need to check those types which are
actually useful for the current dispatch.
[ Hmm... well, maybe not completely "simple" since it might have
some problematic impact on the `cl--generic-prefill-dispatchers`
mechanism, but that should be solvable. ]
> (defun gtype--specializers (tag &rest _)
> "If TAG is a gtype, return its specializers."
> (and (consp tag) (gtype-p (car tag))
> (with-memoization (gethash tag gtype--specializers)
> (merge-ordered-lists (mapcar #'gtype-parents tag)))))
AFAIK this function is only ever called with "tagcodes" returned by your
own TAGCODE-FUNCTION, so I think the `gtype-p` test is redundant.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 14 Apr 2025 14:24:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 14 10:24:18 2025 Received: from localhost ([127.0.0.1]:48422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u4KjR-0007XP-3K for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 10:24:18 -0400 Received: from smtp-17.smtpout.orange.fr ([80.12.242.17]:35409 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u4KjM-0007XC-Mt for 77725 <at> debbugs.gnu.org; Mon, 14 Apr 2025 10:24:15 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 4KjEueiXbETiN4KjIul78K; Mon, 14 Apr 2025 16:24:10 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1744640650; bh=mLP7FKcYRctCE9hMv+eccfNJDiiZUjEJ/MlqbcFAEGg=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=OK+P8KhKq8J+ul9wLZ3xzDlsJkiQvw9io0E4C5o1E+P4FVaHKIoe64fgPBhk1HeYx xRAbcjXLwYO3stf6uIDoNMoFr9TGosXIaW67yUyLcZjPabQ3OTcmdxFfw2xE15upNP eE2ooRc0t8D4XTiCgGandTO05B/W7aAX8hAbo8N+17Aw7GGrAR2pHwd60tgcBpGO9R 8ISnBQuR2J2PSejomsdijJhG2zHKfvsOUsMwhQwUO91V+wCBNrkspBc0eXpF6OXCjH DQ/8/uya/06vUYUx3I4oD+gzyQS9XPaI85uABgHiPy4lgg8jz5zCfszSdAruYVcBcx AesVosgYBUM6Q== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Mon, 14 Apr 2025 16:24:10 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------NqVnDj0IabAnTmcUIWM0h849" Message-ID: <5a16adbe-b9f3-4516-b15d-4243e7dcefdd@HIDDEN> Date: Mon, 14 Apr 2025 16:24:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN> <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN> <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN> <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN> <jwvbjt08401.fsf-monnier+emacs@HIDDEN> <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN> <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------NqVnDj0IabAnTmcUIWM0h849 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025-04-13 19:10, Stefan Monnier wrote: > > In case it can help, here's some example: > > (cl-defmethod my-foo ((x symbol)) > (message "%S is a symbol" x)) > > If I call `(my-foo nil)` it will report that nil is a symbol, even > though `(cl-type-of nil)` returns `null` rather than `symbol`. > > If I add a new method for `null`: > > (cl-defmethod my-foo ((x null)) > (message "%S is null" x) > (cl-call-next-method)) > > Now a call to `(my-foo nil)` will report both that nil is null and that > it's a symbol (in that order). > > For your `button` example, we'd similarly want that > > (cl-defmethod my-foo ((x icon)) > (message "%S is an icon" x) > (cl-call-next-method)) > > `(my-foo 'button)` reports button as both an icon and a symbol (in that > order). Now let's say we add: > > (defgtype face nil () > "Builtin face type." > '(and symbol (satisfies facep))) > > (cl-defmethod my-foo ((x face)) > (message "%S is an face" x) > (cl-call-next-method)) > > We'd want `(my-foo 'button)` now to report that button is an icon, > a face, and a symbol (and here I think it's OK if the ordering between > icon and face is arbitrary, tho they should both come before symbol). > > One way you could do that is for your `(gtype-of 'button)` to return > some new `face&icon` type and to have your SPECIALIZERS-FUNCTION return > the list `(face icon symbol)` or `(icon face symbol)` for that type. > > Does that help? Thank you very much Stefan, it helped much! J'aperçois enfin la lumière au bout du tunnel :-) I understand more how cl-generic works, and I reworked gtype.el (attached) according to your inputs and my better understanding. Now your examples above give the expected results :-) And: (gtype-of '(foo . foo)) => (cons-car-foo cons-cdr-foo cons) (gtype--specializers (gtype-of '(foo . foo))) => (cons-car-foo cons-cdr-foo cons list sequence t) --------------NqVnDj0IabAnTmcUIWM0h849 Content-Type: text/x-emacs-lisp; charset=UTF-8; name="gtype.el" Content-Disposition: attachment; filename="gtype.el" Content-Transfer-Encoding: base64 Ozs7IGd0eXBlLmVsIC0tLSBEYXRhIHR5cGVzIGZvciBnZW5lcmljIGZ1bmN0aW9ucyAtKi0g bGV4aWNhbC1iaW5kaW5nOnQgLSotCgo7OyBDb3B5cmlnaHQgKEMpIDIwMjUgRGF2aWQgUG9u Y2UKCjs7IEF1dGhvcjogRGF2aWQgUG9uY2UgPGRhX3ZpZEBvcmFuZ2UuZnI+Cjs7IE1haW50 YWluZXI6IERhdmlkIFBvbmNlIDxkYV92aWRAb3JhbmdlLmZyPgo7OyBDcmVhdGVkOiA2IEFw cmlsIDIwMjUKOzsgS2V5d29yZHM6IGV4dGVuc2lvbnMKCjs7IFRoaXMgZmlsZSBpcyBub3Qg cGFydCBvZiBHTlUgRW1hY3MuCgo7OyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTog eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCjs7IG1vZGlmeSBpdCB1bmRlciB0aGUg dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzCjs7IHB1Ymxpc2hl ZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRoZXIgdmVyc2lvbiAzIG9m IHRoZQo7OyBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u LgoKOzsgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg d2lsbCBiZSB1c2VmdWwsIGJ1dAo7OyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCjs7IE1FUkNIQU5UQUJJTElUWSBvciBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCjs7IEdlbmVyYWwg UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCjs7IFlvdSBzaG91bGQgaGF2ZSBy ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCjs7IGFs b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcv bGljZW5zZXMvPi4KCjs7OyBDb21tZW50YXJ5Ogo7Owo7OyBUaGlzIGxpYnJhcnkgZXh0ZW5k cyBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIGBndHlwZXMnLCBpLmUuIGRhdGEKOzsgdHlwZXMg ZGVmaW5lZCBieSAnY2wtZGVmdHlwZScgd2hpY2ggYXJlIGFsc28gdmFsaWQgYXJndW1lbnQg dHlwZXMKOzsgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KOzsK OzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgZGVmZ3R5cGUnLCBhIG1h Y3JvIHRoYXQgZGVmaW5lcyBhIGd0eXBlLgo7Owo7OyAtIGBndHlwZS1vZicsIGEgZnVuY3Rp b24gdGhhdCBsb29rdXAgdGhlIGd0eXBlIG9mIGFuIG9iamVjdC4KOzsKOzsgLSBgcmVtZ3R5 cGUnLCBhIG1hY3JvIHRoYXQgcmVtb3ZlcyBhIGd0eXBlLgo7Owo7OyBBIHRyaXZpYWwgZXhh bXBsZToKOzsKOzsgKGRlZmd0eXBlIG5lZ2F0aXZlIG5pbCAoKQo7OyAgICJBIG5lZ2F0aXZl IG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlzZmllcyBtaW51c3ApKSkKOzsKOzsg KGRlZmd0eXBlIHplcm8gbmlsICgpCjs7ICAgIkEgemVybyBudW1iZXIiCjs7ICAgJyhhbmQg bnVtYmVyIChzYXRpc2ZpZXMgemVyb3ApKSkKOzsKOzsgKGRlZmd0eXBlIHBvc2l0aXZlIG5p bCAoKQo7OyAgICJBIHBvc2l0aXZlIG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlz ZmllcyBwbHVzcCkpKQo7Owo7OyAoY2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVyICgobiBuZWdh dGl2ZSkpCjs7ICAgKGZvcm1hdCAibmVnYXRpdmUgbnVtYmVyLCAlcyIgbikpCjs7Cjs7IChj bC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHplcm8pKQo7OyAgIChmb3JtYXQgInplcm8g bnVtYmVyLCAlcyIgbikpCjs7Cjs7IChjbC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHBv c2l0aXZlKSkKOzsgICAoZm9ybWF0ICJwb3NpdGl2ZSBudW1iZXIsICVzIiBuKSkKOzsKOzsg KHRlc3QtbnVtYmVyIC0xMjMuMCkKOzsgPT4gIm5lZ2F0aXZlIG51bWJlciwgLTEyMy4wIgo7 OyAodGVzdC1udW1iZXIgKGFicyAtMTIzLjApKQo7OyA9PiAicG9zaXRpdmUgbnVtYmVyLCAx MjMuMCIKOzsgKHRlc3QtbnVtYmVyIChyb3VuZCAwLjAwMDAwMDAwMDAwMSkpCjs7ID0+ICJ6 ZXJvIG51bWJlciwgMCIKOzsKOzsgUGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbnM6Cjs7Cjs7 IFRoZSBjcml0aWNhbCBwb2ludCBvZiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBpcyB0 aGUgZnVuY3Rpb24KOzsgYGd0eXBlLW9mJyB3aGljaCBzZXF1ZW50aWFsbHkgdHJpZXMgYWxs IGtub3duIGd0eXBlcyB0byBjb2xsZWN0IGFsbAo7OyB0aG9zZSBhbiBvYmplY3QgYmVsb25n cyB0bywgZnJvbSB0aGUgbW9zdCBzcGVjaWZpYyB0byB0aGUgbW9zdAo7OyBnZW5lcmFsIHR5 cGUuICBUaGVyZWZvcmUsIHRoZSBtYXhpbXVtIHRpbWUgdG8gZmluZCBhbiBvYmplY3QncyB0 eXBlCjs7IGRpcmVjdGx5IGRlcGVuZHMgb24gdGhlIG51bWJlciBvZiBndHlwZXMuICBJcyB0 aGVyZSBhIGJldHRlcgo7OyBzb2x1dGlvbj8gIEFueXdheSwgYXNzdW1pbmcgdGhhdCBlYWNo IHNpbmdsZSB0ZXN0IHRvIGtub3cgd2hldGhlcgo7OyBhbiBvYmplY3QgaXMgb2YgYSBnaXZl biBndHlwZSBpcyByZWFzb25hYmx5IGZhc3QsIHRoZSBwZXJmb3JtYW5jZQo7OyBvZiB0aGlz IGltcGxlbWVudGF0aW9uIHNlZW1zIGFjY2VwdGFibGUgKGJhc2VkIG9uIHRoZSB0cml2aWFs Cjs7IGV4YW1wbGUgYWJvdmUsIGF0dGVtcHRpbmcgMSwwMDAgZ3R5cGUgY2hlY2tzIHRha2Vz IGFib3V0IGhhbGYgYQo7OyBtaWxsaXNlY29uZCBvbiBteSBzZXR1cCkuCjs7Cgo7OzsgQ29k ZToKOzsKKHJlcXVpcmUgJ2NsLWxpYikKKGV2YWwtd2hlbi1jb21waWxlIChyZXF1aXJlICdj bC1tYWNzKSkgIDtGb3IgY2wtLWZpbmQtY2xhc3MuCgooZGVmdmFyIGd0eXBlLS1saXN0IG5p bAogICJQcmVjZWRlbmNlIGxpc3Qgb2YgdGhlIGRlZmluZWQgZ3R5cGVzLiIpCihkZWZ2YXIg Z3R5cGUtLXNlcW4gMAogICJTZXF1ZW5jZSBudW1iZXIgb2YgZGVmaW5lZCBndHlwZXMuIikK CihkZWZpbmUtaW5saW5lIGd0eXBlLXAgKG9iamVjdCkKICAiUmV0dXJuIG5vbi1uaWwgaWYg dGhlIHR5cGUgb2YgT0JKRUNUIGlzIGEgZ3R5cGUuIgogIChpbmxpbmUtbGV0ZXZhbHMgKG9i amVjdCkKICAgIChpbmxpbmUtcXVvdGUKICAgICAoYW5kIChzeW1ib2xwICxvYmplY3QpCiAg ICAgICAgICAoZXEgKHR5cGUtb2YgKGNsLS1maW5kLWNsYXNzICxvYmplY3QpKSAnZ3R5cGUt Y2xhc3MpKSkpKQoKKGNsLWRlZnN0cnVjdAogICAgKGd0eXBlLWNsYXNzCiAgICAgKDppbmNs dWRlIGNsLS1jbGFzcykKICAgICAoOm5vaW5saW5lIHQpCiAgICAgKDpjb25zdHJ1Y3RvciBu aWwpCiAgICAgKDpjb25zdHJ1Y3RvciBndHlwZS0tY2xhc3MtbWFrZQogICAgICAgICAgICAg ICAgICAgKG5hbWUKICAgICAgICAgICAgICAgICAgICBkb2NzdHJpbmcKICAgICAgICAgICAg ICAgICAgICBwYXJlbnQtdHlwZXMKICAgICAgICAgICAgICAgICAgICAmYXV4IChwYXJlbnRz CiAgICAgICAgICAgICAgICAgICAgICAgICAgKG1hcGNhcgogICAgICAgICAgICAgICAgICAg ICAgICAgICAobGFtYmRhICh0eXBlKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChv ciAoY2wtLWZpbmQtY2xhc3MgdHlwZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKGVycm9yICJVbmtub3duIHR5cGU6ICVTIiB0eXBlKSkpCiAgICAgICAgICAgICAgICAg ICAgICAgICAgIHBhcmVudC10eXBlcykpKSkKICAgICAoOmNvcGllciBuaWwpKQogICJUeXBl IGRlc2NyaXB0b3JzIGZvciBndHlwZXMuIikKCihkZWZpbmUtaW5saW5lIGd0eXBlLXBhcmVu dHMgKG5hbWUpCiAgIkdldCBwYXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEg c3ltYm9sIHJlcHJlc2VudGluZyBhIHR5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxp c3Qgb2YgdHlwZXMuIgogIChpbmxpbmUtcXVvdGUKICAgKGNsLS1jbGFzcy1hbGxwYXJlbnRz IChjbC0tZmluZC1jbGFzcyAsbmFtZSkpKSkKCihkZWZ1biBndHlwZS1jaGlsZHJlbiAobmFt ZSkKICAiR2V0IGNoaWxkcmVuIG9mIHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBz eW1ib2wgcmVwcmVzZW50aW5nIGEgZ3R5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxp c3Qgb2YgdHlwZXMuIgogIChjbC1jaGVjay10eXBlIG5hbWUgKHNhdGlzZmllcyBndHlwZS1w KSkKICAobGV0IChjaGlsZHJlbikKICAgIChkb2xpc3QgKGVsdCBndHlwZS0tbGlzdCkKICAg ICAgKG9yIChlcSBuYW1lIGVsdCkKICAgICAgICAgIChpZiAobWVtcSBuYW1lIChndHlwZS1w YXJlbnRzIGVsdCkpCiAgICAgICAgICAgICAgKHB1c2ggZWx0IGNoaWxkcmVuKSkpKQogICAg Y2hpbGRyZW4pKQoKKGRlZnVuIGd0eXBlLS10aWUtYnJlYWtlciAobTEgbTIpCiAgIlJldHVy biB0aGUgbGVzcyBzcGVjaWZpYyBvZiB0d28gbWluLWVsZW1lbnRzIE0xIGFuZCBNMi4KVGhh dCBpcywgdGhlIG1pbi1lbGVtZW50IGZpcnN0IHB1c2hlZCBpbiB0aGUgZ3R5cGUgcHJlY2Vk ZW5jZSBsaXN0LApvcmRlcmVkIGZyb20gbW9zdCB0byBsZXNzIHNwZWNpZmljIHR5cGVzLgpJ ZiBNMSBhbmQgTTIgaG9sZCBndHlwZXMsIHByZWZlciB0aGUgb25lIHdpdGggdGhlIGZpcnN0 IGRlZmluZWQgZ3R5cGUuCk90aGVyd2lzZSwgcHJlZmVyIE0xLCB0aGUgZmlyc3QgbWluLWVs ZW1lbnQgZm91bmQgaW4gdGhlIERBRy4iCiAgKGlmLWxldCogKChpMSAoZ2V0IChjYXIgbTEp ICdndHlwZS0tc2VxbikpCiAgICAgICAgICAgIChpMiAoZ2V0IChjYXIgbTIpICdndHlwZS0t c2VxbikpKQogICAgICAoaWYgKDwgaTEgaTIpIG0xIG0yKQogICAgbTEpKQoKKGRlZnVuIGd0 eXBlLS10b3BvbG9naWMtc29ydCAoZ3JhcGggJm9wdGlvbmFsIHRpZS1icmVha2VyKQogICJS ZXR1cm4gdGhlIHRvcG9sb2dpY2FsbHkgc29ydGVkIGVsZW1lbnRzIG9mIEdSQVBILgpHUkFQ SCBtdXN0IGJlIGEgdmFsaWQgZGlyZWN0ZWQgYWN5Y2xpYyBncmFwaCAoREFHKSBhcyBhIGxp c3Qgb2YKZWxlbWVudHMgKFZpIFtWaiBWay4uLlZuXSkgd2hpY2ggbWVhbnMgdGhhdCBWaSBk ZXBlbmRzIHVwb24gVmosIFZqCnVwb24gVmssIGV0Yy4sIG9yIGRlcGVuZHMgdXBvbiBub3Ro aW5nLiAgU2lnbmFsIGFuIGVycm9yIG90aGVyd2lzZS4KRWxlbWVudHMgYXJlIGNvbXBhcmVk IHVzaW5nIGBlcScuCgpJZiBub24tbmlsLCBUSUUtQlJFQUtFUiBtdXN0IGJlIGEgZnVuY3Rp b24gdGhhdCByZWNlaXZlcyB0aGUKcHJldmlvdXNseSBhbmQgbGFzdCBmb3VuZCBtaW4tZWxl bWVudHMoKiksIGFuZCBtdXN0IHJldHVybiBvbmUgb2YKdGhlbS4gIElmIFRJRS1CUkVBS0VS IGlzIG5pbCBvciBvbWl0dGVkLCBwcmVmZXIgdGhlIGZpcnN0IG1pbi1lbGVtZW50CmZvdW5k LCBpLmUuIHRoZSBvbmUgdGhhdCBhcHBlYXJzIGZpcnN0IGluIHRoZSBuYXR1cmFsIG9yZGVy IG9mIHRoZQpEQUcuCgpbKl0gQSBtaW4tZWxlbWVudCBpcyBhbiBlbGVtZW50IHdpdGggbm8g c3VjY2Vzc29yLCBsaWtlIChEKS4KClNvbWUgZXhhbXBsZXM6CgogIChndHlwZS0tdG9wb2xv Z2ljLXNvcnQgXFw9JygoQSBCIEMpIChCIEQpIChDIEQpIChEKSkpCiAgPT4gKEEgQiBDIEQp CgogIChndHlwZS0tdG9wb2xvZ2ljLXNvcnQgXFw9JygoQSBCIEMpIChCIEQpIChDIEQpIChE KSkKICAgICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKF9wcmV2IGxhc3QpIGxhc3Qp KQogID0+IChBIEMgQiBEKQoKICAoZ3R5cGUtLXRvcG9sb2dpYy1zb3J0IFxcPScoKEEgQiBD KSAoQiBEKSAoRCBCKSAoRCkpKQogID0+IGVycm9yIgogIChkZWNsYXJlIChzaWRlLWVmZmVj dC1mcmVlIHQpKQogIChjbC1sYWJlbHMgKChyZW1xLW1pbmltYWwgKG0gZykKICAgICAgICAg ICAgICAgIDs7IFJlbW92ZSBtaW4tZWxlbWVudCBNIGZyb20gRy4KICAgICAgICAgICAgICAg IChsZXQgKChtZSAoY2FyIG0pKSByZXN1bHQpCiAgICAgICAgICAgICAgICAgIChkb2xpc3Qg KGUgKGRlbHEgbSBnKSkKICAgICAgICAgICAgICAgICAgICAocHVzaCAoY29ucyAoY2FyIGUp IChyZW1xIG1lIChjZHIgZSkpKSByZXN1bHQpKQogICAgICAgICAgICAgICAgICByZXN1bHQp KQogICAgICAgICAgICAgIChuZXh0LW1pbmltYWwgKGcpCiAgICAgICAgICAgICAgICA7OyBS ZXR1cm4gdGhlIG5leHQgbWluLWVsZW1lbnQgZm91bmQgaW4gRy4KICAgICAgICAgICAgICAg IChsZXQgKG0pCiAgICAgICAgICAgICAgICAgIChkb2xpc3QgKGUgZykKICAgICAgICAgICAg ICAgICAgICAob3IgKGNkciBlKQogICAgICAgICAgICAgICAgICAgICAgICA7OyBXaGVuIHRo ZXJlIGFyZSB0d28gbWluLWVsZW1lbnRzLCBjYWxsIHRoZQogICAgICAgICAgICAgICAgICAg ICAgICA7OyBUSUUtQlJFQUtFUiB0byBkZWNpZGUgd2hpY2ggb25lIGlzIG1vcmUKICAgICAg ICAgICAgICAgICAgICAgICAgOzsgc3BlY2lmaWMuCiAgICAgICAgICAgICAgICAgICAgICAg IChzZXRxIG0gKGlmIG0gKGZ1bmNhbGwgdGllLWJyZWFrZXIgbSBlKSBlKSkpKQogICAgICAg ICAgICAgICAgICBtKSkpCiAgICAob3IgdGllLWJyZWFrZXIgKHNldHEgdGllLWJyZWFrZXIg KGxhbWJkYSAocHJldiBfbmV4dCkgcHJldikpKQogICAgKGxldCAoKGcgKGNvcHktc2VxdWVu Y2UgZ3JhcGgpKSB0cykKICAgICAgKHdoaWxlICh3aGVuLWxldCogKChtIChuZXh0LW1pbmlt YWwgZykpKQogICAgICAgICAgICAgICAoc2V0cSBnIChyZW1xLW1pbmltYWwgbSBnKSkKICAg ICAgICAgICAgICAgKHB1c2ggKGNhciBtKSB0cykpKQogICAgICAoY2wtYXNzZXJ0IChlcWwg KGxlbmd0aCBncmFwaCkgKGxlbmd0aCB0cykpIG5pbAogICAgICAgICAgICAgICAgICJJbnZh bGlkIGdyYXBoLCAlUyIgdHMpCiAgICAgIHRzKSkpCgooZGVmdW4gZ3R5cGUtLWRhZyAoKQog ICJSZXR1cm4gYSBEQUcgZnJvbSB0aGUgbGlzdCBvZiBkZWZpbmVkIGd0eXBlcy4iCiAgKGNs LWxhYmVscyAoKGFsbHBhcmVudHMgKGNsYXNzKQogICAgICAgICAgICAgICAgKGxldCAoKHR5 cGUgKGNsLS1jbGFzcy1uYW1lIGNsYXNzKSkpCiAgICAgICAgICAgICAgICAgIDs7IEV4Y2x1 ZGUgbm9uLWd0eXBlcyBmcm9tIHRoZSBEQUcuICBgZ3R5cGUtb2YnCiAgICAgICAgICAgICAg ICAgIDs7IGRvZXNuJ3QgY2hlY2sgbm9uLWd0eXBlcyBhdCBydW4gdGltZSwgdGhleSBhcmUK ICAgICAgICAgICAgICAgICAgOzsgaGFuZGxlZCBieSB0aGUgInR5cGUtb2YiIGdlbmVyYWxp emVyLgogICAgICAgICAgICAgICAgICAoaWYgKGd0eXBlLXAgdHlwZSkKICAgICAgICAgICAg ICAgICAgICAgIChjb25zIHR5cGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgIChtZXJn ZS1vcmRlcmVkLWxpc3RzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG1hcGNhciAj J2FsbHBhcmVudHMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjbC0t Y2xhc3MtcGFyZW50cyBjbGFzcykpKSkpKSkpCiAgICAobWFwY2FyIChsYW1iZGEgKGd0eXBl KSAoYWxscGFyZW50cyAoY2wtLWZpbmQtY2xhc3MgZ3R5cGUpKSkKICAgICAgICAgICAgZ3R5 cGUtLWxpc3QpKSkKCihkZWZ1biBndHlwZS0tcmVnaXN0ZXIgKG5hbWUgJm9wdGlvbmFsIHBh cmVudHMgYXJncykKICAiUmVnaXN0ZXIgYSBndHlwZSB3aXRoIE5BTUUgYW5kIFBBUkVOVFMu CkFSR1MgYXJlIHRob3NlIHRoYXQgd2lsbCBiZSBwYXNzZWQgdG8gYGNsLWRlZnR5cGUnLiIK ICA7OyBBdCB0aGlzIHBvaW50IE5BTUUgbXVzdCBiZSBhIGRlZmluZWQgdHlwZS4KICAoY2wt YXNzZXJ0IChnZXQgbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVyKSBuaWwKICAgICAgICAgICAg ICJVbmtub3duIHR5cGUgJVMiIG5hbWUpCiAgKGxldCAoKGNsYXNzIChjbC0tZmluZC1jbGFz cyBuYW1lKSkKICAgICAgICAocmVnZWQgKG1lbXEgbmFtZSBndHlwZS0tbGlzdCkpKQogICAg KGlmIChudWxsIGNsYXNzKQogICAgICAgIChjbC1hc3NlcnQgKG51bGwgcmVnZWQpIG5pbCAi RXhpc3RpbmcgdHlwZSBub3QgcmVnaXN0ZXJlZCIpCiAgICAgIChjbC1hc3NlcnQgcmVnZWQg bmlsICJOZXcgdHlwZSBhbHJlYWR5IHJlZ2lzdGVyZWQiKQogICAgICAoY2wtYXNzZXJ0IChl cSAodHlwZS1vZiBjbGFzcykgJ2d0eXBlLWNsYXNzKSBuaWwKICAgICAgICAgICAgICAgICAi VHlwZSBpcyBpbiBhbm90aGVyIGNsYXNzOiAlUyIgKHR5cGUtb2YgY2xhc3MpKSkKICAgIChv ciAobGlzdHAgcGFyZW50cykgKHNldHEgcGFyZW50cyAobGlzdCBwYXJlbnRzKSkpCiAgICAo Y2wtYXNzZXJ0IChudWxsIChtZW1xIG5hbWUgcGFyZW50cykpIG5pbAogICAgICAgICAgICAg ICAiVHlwZSBpcyBpbiBwYXJlbnRzOiAlUyIgcGFyZW50cykKICAgIDs7IFNldHVwIGEgdHlw ZSBkZXNjcmlwdG9yIGZvciBOQU1FLCB3aXRoIFBBUkVOVFMgYW5kIHRoZQogICAgOzsgZG9j c3RyaW5nIHBvc3NpYmx5IHByZXNlbnQgaW4gQVJHUy4KICAgIChsZXQgKChkb2NzdHJpbmcg KGNhYXIgKG1hY3JvZXhwLXBhcnNlLWJvZHkgKGNkciBhcmdzKSkpKSkKICAgICAgKG9yIChz dHJpbmdwIGRvY3N0cmluZykgKHNldHEgZG9jc3RyaW5nIG5pbCkpCiAgICAgIChzZXRmIChj bC0tZmluZC1jbGFzcyBuYW1lKQogICAgICAgICAgICAoZ3R5cGUtLWNsYXNzLW1ha2UgbmFt ZSBkb2NzdHJpbmcgcGFyZW50cykpKQogICAgKGlmIGNsYXNzCiAgICAgICAgOzsgQ2xlYXIg Y2FjaGVkIHZhbHVlIG9mIHNwZWNpYWxpemVycyB3aXRoIE5BTUUuCiAgICAgICAgKGd0eXBl LS1yZXNldC1zcGVjaWFsaXplcnMgbmFtZSkKICAgICAgOzsgUmVjb3JkIHRoZSBuZXcgdHlw ZS4KICAgICAgKHB1c2ggbmFtZSBndHlwZS0tbGlzdCkKICAgICAgOzsgQW5kIGl0cyBzZXF1 ZW5jZSBudW1iZXIuCiAgICAgIChwdXQgbmFtZSAnZ3R5cGUtLXNlcW4gKHByb2cxIGd0eXBl LS1zZXFuIChpbmNmIGd0eXBlLS1zZXFuKSkpKQogICAgOzsgVG8gZmluZCB0aGUgbW9zdCBw b3NzaWJsZSBzcGVjaWZpYyBndHlwZSBvZiBhbiBvYmplY3QsIG1vc3QKICAgIDs7IHNwZWNp ZmljIHR5cGVzIG11c3QgYmUgdHJpZWQgYmVmb3JlIG1vcmUgZ2VuZXJhbCB0eXBlcy4KICAg IDs7IENvbXB1dGUgdGhlIGd0eXBlIHByZWNlZGVuY2UgbGlzdCBieSBhIHRvcG9sb2dpYyBz b3J0IG9mIHRoZQogICAgOzsgZ3R5cGVzIGRlcGVuZGVuY2llcyBEQUcuCiAgICAoc2V0cSBn dHlwZS0tbGlzdCAoZ3R5cGUtLXRvcG9sb2dpYy1zb3J0CiAgICAgICAgICAgICAgICAgICAg ICAgKGd0eXBlLS1kYWcpICMnZ3R5cGUtLXRpZS1icmVha2VyKSkKICAgIG5hbWUpKQoKKGRl ZnVuIGd0eXBlLS11bnJlZ2lzdGVyIChuYW1lKQogICJVbnJlZ2lzdGVyIHRoZSBndHlwZSB3 aXRoIE5BTUUuIgogIChjbC1hc3NlcnQgKG51bGwgKGd0eXBlLWNoaWxkcmVuIG5hbWUpKSB0 ICJUeXBlIGhhcyBjaGlsZHJlbjogJVMiKQogIDs7IENsZWFyIGNhY2hlZCB2YWx1ZSBvZiBz cGVjaWFsaXplcnMgd2l0aCBOQU1FLgogIChndHlwZS0tcmVzZXQtc3BlY2lhbGl6ZXJzIG5h bWUpCiAgKGNsLXJlbXByb3AgbmFtZSAnZ3R5cGUtLXNlcW4pCiAgKGNsLXJlbXByb3AgbmFt ZSAnY2wtLWNsYXNzKQogIChjbC1yZW1wcm9wIG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcikK ICAoc2V0cSBndHlwZS0tbGlzdCAoZGVscSBuYW1lIGd0eXBlLS1saXN0KSkKICBuaWwpCgo7 OzsjIyNhdXRvbG9hZAooZGVmbWFjcm8gZGVmZ3R5cGUgKG5hbWUgJm9wdGlvbmFsIHBhcmVu dHMgJnJlc3QgYXJncykKICAiRGVmaW5lIE5BTUUgYXMgYSBndHlwZSB0aGF0IGluaGVyaXRz IGZyb20gUEFSRU5UUy4KSWYgYSBndHlwZSB3aXRoIE5BTUUgYWxyZWFkeSBleGlzdHMsIHJl cGxhY2UgaXQuCgpOQU1FIGlzIGFuIHVucXVvdGVkIHN5bWJvbCByZXByZXNlbnRpbmcgYSBn dHlwZS4KCk9wdGlvbmFsIGFyZ3VtZW50IFBBUkVOVFMgaXMgZWl0aGVyIGFuIHVucXVvdGVk IHN5bWJvbCBvciBsaXN0IG9mCnN5bWJvbHMgb3RoZXIgdGhhbiBOQU1FIHJlcHJlc2VudGlu ZyB0eXBlcyBwYXJlbnRzIG9mIE5BTUUuClBBUkVOVFMgbmlsIG9yIG9taXR0ZWQgbWVhbnMg dGhhdCBOQU1FIGlzIGEgcm9vdCB0eXBlLgoKQWxzbyBwYXNzIE5BTUUgYW5kIEFSR1MgdG8g YGNsLWRlZnR5cGUnIHRvIGRlZmluZSBOQU1FIGFzIGEgbmV3IGRhdGEKdHlwZS4iCiAgKGRl Y2xhcmUgKGRlYnVnIGNsLWRlZm1hY3JvKSAoZG9jLXN0cmluZyA0KSAoaW5kZW50IDMpKQog IChjbC13aXRoLWdlbnN5bXMgKGVycikKICAgIGAoY29uZGl0aW9uLWNhc2UgLGVycgogICAg ICAgICAocHJvZ24KICAgICAgICAgICAoY2wtZGVmdHlwZSAsbmFtZSAsQGFyZ3MpCiAgICAg ICAgICAgKGd0eXBlLS1yZWdpc3RlciAnLG5hbWUgJyxwYXJlbnRzICcsYXJncykpCiAgICAg ICAoZXJyb3IKICAgICAgICAoZ3R5cGUtLXVucmVnaXN0ZXIgJyxuYW1lKQogICAgICAgIChl cnJvciAoZXJyb3ItbWVzc2FnZS1zdHJpbmcgLGVycikpKSkpKQoKKGRlZm1hY3JvIHJlbWd0 eXBlIChuYW1lKQogICJSZW1vdmUgdGhlIGd0eXBlIHdpdGggTkFNRS4KTkFNRSBpcyBhbiB1 bnF1b3RlZCBzeW1ib2wgcmVwcmVzZW50aW5nIGEgZ3R5cGUuClNpZ25hbCBhbiBlcnJvciBp ZiBvdGhlciBndHlwZXMgaW5oZXJpdCBmcm9tIE5BTUUuIgogIGAocHJvZ24KICAgICAoY2wt Y2hlY2stdHlwZSAnLG5hbWUgKHNhdGlzZmllcyBndHlwZS1wKSkKICAgICAoZ3R5cGUtLXVu cmVnaXN0ZXIgJyxuYW1lKSkpCgo7OyBJbnRlcm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVu ZGxlc3MgcmVjdXJzaW9uIGluICdndHlwZS1vZicuCihkZWZ2YXIgZ3R5cGUtLW9iamVjdCAo bWFrZS1zeW1ib2wgInZvaWQiKSkKOzsgRWFjaCBndHlwZSBtdXN0IHNhdGlzZmllcyBgZXFs Jy4KKGRlZnZhciBndHlwZS0tdW5pcXVlIChtYWtlLWhhc2gtdGFibGUgOnRlc3QgJ2VxdWFs KQogICJSZWNvcmQgYW4gdW5pcXVlIHZhbHVlIGZvciBlYWNoIGd0eXBlLiIpCgooZGVmdW4g Z3R5cGUtb2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSBtb3N0IHNwZWNpZmljIHBvc3NpYmxl IGd0eXBlIE9CSkVDVCBiZWxvbmdzIHRvLgpSZXR1cm4gYW4gdW5pcXVlIGxpc3Qgb2YgdHlw ZXMgT0JKRUNUIGJlbG9uZ3MgdG8sIG9yZGVyZWQgZnJvbSB0aGUKbW9zdCBzcGVjaWZpYyB0 eXBlIHRvIHRoZSBtb3N0IGdlbmVyYWwuIgogIDs7IElnbm9yZSByZWN1cnNpdmUgY2FsbCBv biB0aGUgc2FtZSBPQkpFQ1QsIHdoaWNoIGNhbiBsZWdpdGltYXRlbHkKICA7OyBvY2N1ciB3 aGVuLCBmb3IgZXhhbXBsZSwgYSBwYXJlbnQgdHlwZSBpcyBpbnZlc3RpZ2F0aW5nIHdoZXRo ZXIKICA7OyBhbiBvYmplY3QncyB0eXBlIGlzIHRoYXQgb2Ygb25lIG9mIGl0cyBjaGlsZHJl bi4KICAodW5sZXNzIChlcSBvYmplY3QgZ3R5cGUtLW9iamVjdCkKICAgIChsZXQgKChndHlw ZS0tb2JqZWN0IG9iamVjdCkKICAgICAgICAgIChmb3VuZCAobGlzdCAoY2wtdHlwZS1vZiBv YmplY3QpKSkpCiAgICAgIDs7IENvbGxlY3QgYWxsIGd0eXBlcyBPQkpFQ1QgYmVsb25ncyB0 by4KICAgICAgKGRvbGlzdCAoZ3R5cGUgZ3R5cGUtLWxpc3QpCiAgICAgICAgKGlmIChjbC10 eXBlcCBvYmplY3QgZ3R5cGUpCiAgICAgICAgICAgIChwdXNoIGd0eXBlIGZvdW5kKSkpCiAg ICAgIDs7IFJldHVybiBhbiB1bmlxdWUgdmFsdWUgb2YgdHlwZS4KICAgICAgKHdpdGgtbWVt b2l6YXRpb24gKGdldGhhc2ggZm91bmQgZ3R5cGUtLXVuaXF1ZSkKICAgICAgICBmb3VuZCkp KSkKCjs7OyBNZXRob2QgZGlzcGF0Y2hpbmcKOzsKKGRlZnZhciBndHlwZS0tc3BlY2lhbGl6 ZXJzIChtYWtlLWhhc2gtdGFibGUgOnRlc3QgJ2VxKQogICJNZW1vaXplIGd0eXBlIHNwZWNp YWxpemVycy4KVGhpcyBjYWNoZSBpcyBjbGVhcmVkIGJ5IGBndHlwZS0tcmVnaXN0ZXInIGFu ZCBgZ3R5cGUtLXVucmVnaXN0ZXInLiIpCgooZGVmdW4gZ3R5cGUtLXJlc2V0LXNwZWNpYWxp emVycyAobmFtZSkKICAiUmVtb3ZlIGFsbCBjYWNoZWQgdmFsdWUgb2Ygc3BlY2lhbGl6ZXJz IHdpdGggTkFNRS4iCiAgKG1hcGhhc2ggKGxhbWJkYSAoa2V5IF8pCiAgICAgICAgICAgICAo aWYgKG1lbXEgbmFtZSBrZXkpCiAgICAgICAgICAgICAgICAgKHJlbWhhc2gga2V5IGd0eXBl LS1zcGVjaWFsaXplcnMpKSkKICAgICAgICAgICBndHlwZS0tc3BlY2lhbGl6ZXJzKSkKCihk ZWZ1biBndHlwZS0tc3BlY2lhbGl6ZXJzICh0YWcgJnJlc3QgXykKICAiSWYgVEFHIGlzIGEg Z3R5cGUsIHJldHVybiBpdHMgc3BlY2lhbGl6ZXJzLiIKICAoYW5kIChjb25zcCB0YWcpIChn dHlwZS1wIChjYXIgdGFnKSkKICAgICAgICh3aXRoLW1lbW9pemF0aW9uIChnZXRoYXNoIHRh ZyBndHlwZS0tc3BlY2lhbGl6ZXJzKQogICAgICAgICAobWVyZ2Utb3JkZXJlZC1saXN0cyAo bWFwY2FyICMnZ3R5cGUtcGFyZW50cyB0YWcpKSkpKQoKKGNsLWdlbmVyaWMtZGVmaW5lLWdl bmVyYWxpemVyIGd0eXBlLS1nZW5lcmFsaXplcgogIDIwIDs7ICJ0eXBlb2YiIHByaW9yaXR5 IDwgImd0eXBlLW9mIiBwcmlvcml0eSA8ICJoZWFkIiBwcmlvcml0eQogIChsYW1iZGEgKG9i aiAmcmVzdCBfKSBgKGd0eXBlLW9mICxvYmopKQogICMnZ3R5cGUtLXNwZWNpYWxpemVycykK CihjbC1kZWZtZXRob2QgY2wtZ2VuZXJpYy1nZW5lcmFsaXplcnMgOmV4dHJhICJndHlwZS1v ZiIgKHR5cGUpCiAgIlN1cHBvcnQgZm9yIGRpc3BhdGNoIG9uIGd0eXBlcy4iCiAgKGlmIChn dHlwZS1wIHR5cGUpCiAgICAgIChsaXN0IGd0eXBlLS1nZW5lcmFsaXplcikKICAgIChjbC1j YWxsLW5leHQtbWV0aG9kKSkpCgoocHJvdmlkZSAnZ3R5cGUpCgo7OzsgZ3R5cGUuZWwgZW5k cyBoZXJlCg== --------------NqVnDj0IabAnTmcUIWM0h849--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 13 Apr 2025 17:10:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 13 13:10:49 2025
Received: from localhost ([127.0.0.1]:43679 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u40r2-0007YF-RW
for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 13:10:49 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46662)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u40r0-0007Xv-6F
for 77725 <at> debbugs.gnu.org; Sun, 13 Apr 2025 13:10:47 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1A51D10006B;
Sun, 13 Apr 2025 13:10:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744564239;
bh=aSSofOLOc4E1pgkVpmkiD8zSUSZdSkVVYtiRn8TEpQM=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=bbI/7bNiMQto7q4mC/Tcz3UjDB8nhzdCzhJvGLDws9C70D1F+R0TnqWJ+AKcEgjoo
es98qd5Zb1lXk2jeJh7dmsO0Bu8B+9jUAGHgAwy7K6zKYHLkbJMjdP8ICtfx4M41Bx
R37wiQYhprFOpID811gCDTyXwSId4JKpPlo+GAepKWyt4IwYQsMRgES26U0UEfniNm
emnFa8DBrvVJwkGXp8EN4qxrm0aKl/qxiYDMhEoXaNRb2D0NhnhsP1fEnywMexlSrC
JGN3YDUxFmibhzzHk9/o9u587SJDSuNHhQTWlrr9NC9OQhqdxzfzbIbPe3IFMkNkHr
A62GOn9gktaBA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 23B88100029;
Sun, 13 Apr 2025 13:10:39 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EA45512075A;
Sun, 13 Apr 2025 13:10:38 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
Message-ID: <jwvzfgk6lzz.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
<jwvbjt08401.fsf-monnier+emacs@HIDDEN>
<4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN>
Date: Sun, 13 Apr 2025 13:10:38 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.385 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Thank you again for your very valuable input.
> I am afraid, this discussion just confirms that I don't understand well
> enough how cl-generic works, and how it can be improved the correct way :-(
In case it can help, here's some example:
(cl-defmethod my-foo ((x symbol))
(message "%S is a symbol" x))
If I call `(my-foo nil)` it will report that nil is a symbol, even
though `(cl-type-of nil)` returns `null` rather than `symbol`.
If I add a new method for `null`:
(cl-defmethod my-foo ((x null))
(message "%S is null" x)
(cl-call-next-method))
Now a call to `(my-foo nil)` will report both that nil is null and that
it's a symbol (in that order).
For your `button` example, we'd similarly want that
(cl-defmethod my-foo ((x icon))
(message "%S is an icon" x)
(cl-call-next-method))
`(my-foo 'button)` reports button as both an icon and a symbol (in that
order). Now let's say we add:
(defgtype face nil ()
"Builtin face type."
'(and symbol (satisfies facep)))
(cl-defmethod my-foo ((x face))
(message "%S is an face" x)
(cl-call-next-method))
We'd want `(my-foo 'button)` now to report that button is an icon,
a face, and a symbol (and here I think it's OK if the ordering between
icon and face is arbitrary, tho they should both come before symbol).
One way you could do that is for your `(gtype-of 'button)` to return
some new `face&icon` type and to have your SPECIALIZERS-FUNCTION return
the list `(face icon symbol)` or `(icon face symbol)` for that type.
Does that help?
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 13 Apr 2025 16:28:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 13 12:28:57 2025 Received: from localhost ([127.0.0.1]:43577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u40CW-0005Ly-RL for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 12:28:57 -0400 Received: from smtp-78.smtpout.orange.fr ([80.12.242.78]:50109 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u40CS-0005Lk-Bs for 77725 <at> debbugs.gnu.org; Sun, 13 Apr 2025 12:28:54 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 40CKu1K2mNyiG40COuEQKp; Sun, 13 Apr 2025 18:28:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1744561730; bh=EEuEGaz0rOBE8XITCKzgxRq/cR6SLVqlrjOsgICsbnk=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=ofXnfJoRf3FQ03nNxKJqVKE55DFwjeKVmzf7zbV3eftiiXZBovIhJTePZriE1AM5H zrIomncj2JFCJJ2fjLmOK5S1YEdkJ7fSjE1A6s3vwZ3Y6Di80ELhi5V2QVHD+DMzGi GsnnRc/ccXDiZKMbCM2QOBHG6WRlFbeBMB2FQUYFKnaO+9wbyuiUCfXFIXFafGrCwT ztdiF3lrco6TuKtWSzTfYbtdMJCfRqUyUpIdNcy7TNANBOG4EnoS1lAkcZqrHIfwLh HTKay/oWTmbrILD3bmsUJTryNtyvBAV4Yi8HaASrBZAyMQQHqRFYT69/aJDvtYUgPr C4A0S/0ABsMyw== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sun, 13 Apr 2025 18:28:50 +0200 X-ME-IP: 90.112.40.65 Message-ID: <4931d938-18b7-412c-8f9a-3856ceb98a6a@HIDDEN> Date: Sun, 13 Apr 2025 18:28:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN> <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN> <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN> <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN> <jwvbjt08401.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvbjt08401.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-13 17:53, Stefan Monnier wrote: >> For instance, if you define an icon type like this: >> >> (defgtype icon nil () >> "Builtin icon type." >> '(and symbol (satisfies iconp))) >> >> (gtype-of 'button) >> => icon >> (cl-type-of 'button) >> => symbol >> >> So you cannot have two methods with the same name, one to handle the >> symbol type, and one to handle the icon type. I agree, it is a >> limitation. Is this your point? > > Kind of. Note: you can. It's just that with your current code I expect > it will misbehave (rather than signal an error). > > BTW, for the above case, your code could recognize that `icon` is > a subtype of `symbol` and tell that to cl-generic. > >> I wonder if in practice it is really inconvenient, and worth the >> trouble of complicate more the implementation? > > I don't think I understand what compilations you're talking about, nor > what kind of inconvenience you're referring to. > >> Isn't it clearer to use different methods for icons and symbols? >> Aren't these types fundamentally different, and isn't the fact that an >> icon is a symbol just an implementation choice? > > The question is not whether it's desirable, but whether we can provide > an implementation that works without too many quirks. 🙂 > >>> BTW if you do >>> (defgtype cons-car-foo nil () >>> "A cons with a `foo' car." >>> `(satisfies ,(lambda (x) (eq (car-safe x) 'foo)))) >>> (defgtype cons-cdr-foo nil () >>> "A cons with a `foo' cdr." >>> `(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo)))) >>> what's the `(gtype-of '(foo . foo))` ? >> >> Regarding this point, perhaps it would be possible to use an heuristic >> like: "in case of conflict, the last defined type is chosen as the >> most specific"? > > I'm pretty sure some of your users will still be confused when their > methods are not used, just because some other part of their `cons` cells > happens to have a value recognized by an unrelated type. > > And of course, they'd probably also be confused if the method that > handles `cons` is not used for those cons-cells. > >>> Yeah, it's unsatisfactorily intricate, indeed. It's designed first and >>> foremost to keep the dispatch "simple and reasonable fast", at the cost >>> of making `cl-generic-define-generalizer` a very sharp tool. 🙂 >>> I have recently been thinking about how to make it more reliable (which >>> would also make it more flexible/powerful, allowing the definition of >>> both `and` and `or` specializers). I have some vague idea, but there's >>> no code at all yet, and it might come with some non-trivial tradeoffs >>> (e.g. preloading the byte-compiler). >> I can't wait to see this :-) > > I know I wrote "yet", but I have a very long list of "ideas I've had": > most of those will never become concrete. > > > Stefan > Hi Stefan Thank you again for your very valuable input. I am afraid, this discussion just confirms that I don't understand well enough how cl-generic works, and how it can be improved the correct way :-( Have a nice Sunday. David
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 13 Apr 2025 15:53:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 13 11:53:59 2025
Received: from localhost ([127.0.0.1]:43508 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3zeh-0003cO-85
for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 11:53:59 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47123)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u3zed-0003c2-TM
for 77725 <at> debbugs.gnu.org; Sun, 13 Apr 2025 11:53:57 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E772B10006B;
Sun, 13 Apr 2025 11:53:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744559622;
bh=YnfLEHgg4HqepaDf4ytmvLQFstc5Y2L9H/2wnqWuIYg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=II37cUntVP3reGSxAIP8eATYSo0juOsVyxKsUy5GiICI4toB1PxS6kqu4kk7BoXBB
Fo+gFclTqoDQyugKepX4BMPReanOan7ZgJIbew/ZbG/d66sB9dm1/l/ty616OcKAM7
iQNCMhRtOBJ70iyXDwMbxzKEsAIBKplCDrdFxrezxvsw3NVAGWPHCJbf/z7JQ4OXtQ
3ykegZcx5gGLz4XZ3wNIl8v1iGq07dsN6YpnLDNcar+gnAcJnBbsjfA0+U0MkmZZ7Q
30zzANj1CCHXRV07HPB0FzLaDEbFsMmU6v7ci6ZNJEArbP5l23dtlI2G+URKYu4VnK
ExTXURwEAzlYA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B522E100029;
Sun, 13 Apr 2025 11:53:42 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 74867120755;
Sun, 13 Apr 2025 11:53:42 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
Message-ID: <jwvbjt08401.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
<jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
<ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN>
Date: Sun, 13 Apr 2025 11:53:40 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.386 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> For instance, if you define an icon type like this:
>
> (defgtype icon nil ()
> "Builtin icon type."
> '(and symbol (satisfies iconp)))
>
> (gtype-of 'button)
> =3D> icon
> (cl-type-of 'button)
> =3D> symbol
>
> So you cannot have two methods with the same name, one to handle the
> symbol type, and one to handle the icon type. I agree, it is a
> limitation. Is this your point?
Kind of. Note: you can. It's just that with your current code I expect
it will misbehave (rather than signal an error).
BTW, for the above case, your code could recognize that `icon` is
a subtype of `symbol` and tell that to cl-generic.
> I wonder if in practice it is really inconvenient, and worth the
> trouble of complicate more the implementation?
I don't think I understand what compilations you're talking about, nor
what kind of inconvenience you're referring to.
> Isn't it clearer to use different methods for icons and symbols?
> Aren't these types fundamentally different, and isn't the fact that an
> icon is a symbol just an implementation choice?
The question is not whether it's desirable, but whether we can provide
an implementation that works without too many quirks. =F0=9F=99=82
>> BTW if you do
>> (defgtype cons-car-foo nil ()
>> "A cons with a `foo' car."
>> `(satisfies ,(lambda (x) (eq (car-safe x) 'foo))))
>> (defgtype cons-cdr-foo nil ()
>> "A cons with a `foo' cdr."
>> `(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo))))
>> what's the `(gtype-of '(foo . foo))` ?
>
> Regarding this point, perhaps it would be possible to use an heuristic
> like: "in case of conflict, the last defined type is chosen as the
> most specific"?
I'm pretty sure some of your users will still be confused when their
methods are not used, just because some other part of their `cons` cells
happens to have a value recognized by an unrelated type.
And of course, they'd probably also be confused if the method that
handles `cons` is not used for those cons-cells.
>> Yeah, it's unsatisfactorily intricate, indeed. It's designed first and
>> foremost to keep the dispatch "simple and reasonable fast", at the cost
>> of making `cl-generic-define-generalizer` a very sharp tool. =F0=9F=99=
=82
>> I have recently been thinking about how to make it more reliable (which
>> would also make it more flexible/powerful, allowing the definition of
>> both `and` and `or` specializers). I have some vague idea, but there's
>> no code at all yet, and it might come with some non-trivial tradeoffs
>> (e.g. preloading the byte-compiler).
> I can't wait to see this :-)
I know I wrote "yet", but I have a very long list of "ideas I've had":
most of those will never become concrete.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 13 Apr 2025 14:46:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 13 10:46:29 2025 Received: from localhost ([127.0.0.1]:43332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u3ybM-0000Hl-CQ for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 10:46:29 -0400 Received: from smtp-24.smtpout.orange.fr ([80.12.242.24]:44683 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u3ybH-0000HX-Pi for 77725 <at> debbugs.gnu.org; Sun, 13 Apr 2025 10:46:26 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 3ya2uKxz6RaJG3ya5uQlEl; Sun, 13 Apr 2025 16:45:11 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1744555511; bh=qpk8zId1r1RTtMKitxDoBxUozhQqWAkBI5QVPGt3DsU=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=la3GsbS8HQi0mon4L4hbTrUVs6TPYvQ1N/OT9QVZHFt+UGkudca/1iGGDt+IIj/nd 2O19SEdIMo6lIwGp2LY/f29MkIWAPJ+NceQ++I3dODO/QOIUg8kOuQP7QjBa8fCu+I TvmX+StfSg7/JUTc1l696C7TQlABjl2rg1Fe8P/mbHw/hSQ+qIPYXo36JlTIwzUoGT z/O0ZzOzZhT3CFJxzKntF9mjFbHfyPDrK138UnbUy022pd4ufxLBJOX0BjkY53T49S r1+IGKKwmoAqYDUzDAf+TMkwhfJzLVpGe5x9Vx+LijywzNP3EH1x4gOSdC7mc9qPyF 47A/V/mwG2B0g== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sun, 13 Apr 2025 16:45:11 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------K7ayjXP8dGQosZr0arxKGOQ6" Message-ID: <ac629e63-a7b0-461f-8f98-6c79f567ebbb@HIDDEN> Date: Sun, 13 Apr 2025 16:45:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN> <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN> <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------K7ayjXP8dGQosZr0arxKGOQ6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Stefan, Sorry for this late answer. It took me a while to take it all in ;-) On 2025-04-11 18:26, Stefan Monnier wrote: >> Does this mean that for a `cl-deftype'-like generalizer to work >> correctly, it must be part of the "typof" generalizer? > > No, but it needs to be either always more precise or always less precise > than `type-of`. > > IOW, either: > > (eql (gtypeof-generalizer A) (gtypeof-generalizer B)) > IMPLIES ((eql (gtypeof-generalizer A) nil) > OR (eql (cl-type-of A) (cl-type-of B))) > > or the reverse. That's a current limitation in the cl-generic system. > > One way to solve this is to use a generalizer that returns either nil or > a pair containing both the `gtype-of` and the `cl-type-of`, so it's > trivially always more precise than `cl-type-of`. But beware: these > things are compared with `eql` so you need to "uniquify" them with > a sort of hashconsing scheme. I am not sure to understand this point. AFAICS, gtypes always take precedence over other types. So, provided I correctly understand your point, the gtype generalizer is more precise than `type-of`. For instance, if you define an icon type like this: (defgtype icon nil () "Builtin icon type." '(and symbol (satisfies iconp))) (gtype-of 'button) => icon (cl-type-of 'button) => symbol So you cannot have two methods with the same name, one to handle the symbol type, and one to handle the icon type. I agree, it is a limitation. Is this your point? I wonder if in practice it is really inconvenient, and worth the trouble of complicate more the implementation? Isn't it clearer to use different methods for icons and symbols? Aren't these types fundamentally different, and isn't the fact that an icon is a symbol just an implementation choice? > > BTW if you do > > (defgtype cons-car-foo nil () > "A cons with a `foo' car." > `(satisfies ,(lambda (x) (eq (car-safe x) 'foo)))) > > (defgtype cons-cdr-foo nil () > "A cons with a `foo' cdr." > `(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo)))) > > what's the `(gtype-of '(foo . foo))` ? Regarding this point, perhaps it would be possible to use an heuristic like: "in case of conflict, the last defined type is chosen as the most specific"? I implemented this idea in gtype (attached) to compute the gtype precedence list, by using a topologic sort with a tie-breaker to decide which gtype will be the most specific between two candidates that cannot be separated otherwise. It should be easy to implement different heuristics by providing different tie-breakers. With your example, if you define `cons-cdr-foo' after `cons-car-foo': (gtype-of '(foo . foo)) => cons-cdr-foo And, if you define `cons-car-foo' after `cons-cdr-foo': (gtype-of '(foo . foo)) => cons-car-foo To avoid inconsistent method dispatching, the order of gtypes does not change if you eval again the definition of an existing gtype. But the order will change if you first remove the gtype, then define it again. >> Or am I missing something? --- Sorry, I only started studying >> cl-generic relatively recently, and I probably don't understand >> all its intricacies ;-) > > Yeah, it's unsatisfactorily intricate, indeed. It's designed first and > foremost to keep the dispatch "simple and reasonable fast", at the cost > of making `cl-generic-define-generalizer` a very sharp tool. 🙂 > > I have recently been thinking about how to make it more reliable (which > would also make it more flexible/powerful, allowing the definition of > both `and` and `or` specializers). I have some vague idea, but there's > no code at all yet, and it might come with some non-trivial tradeoffs > (e.g. preloading the byte-compiler). I can't wait to see this :-) Thanks for your patience! --------------K7ayjXP8dGQosZr0arxKGOQ6 Content-Type: text/x-emacs-lisp; charset=UTF-8; name="gtype.el" Content-Disposition: attachment; filename="gtype.el" Content-Transfer-Encoding: base64 Ozs7IGd0eXBlLmVsIC0tLSBEYXRhIHR5cGVzIGZvciBnZW5lcmljIGZ1bmN0aW9ucyAtKi0g bGV4aWNhbC1iaW5kaW5nOnQgLSotCgo7OyBDb3B5cmlnaHQgKEMpIDIwMjUgRGF2aWQgUG9u Y2UKCjs7IEF1dGhvcjogRGF2aWQgUG9uY2UgPGRhX3ZpZEBvcmFuZ2UuZnI+Cjs7IE1haW50 YWluZXI6IERhdmlkIFBvbmNlIDxkYV92aWRAb3JhbmdlLmZyPgo7OyBDcmVhdGVkOiA2IEFw cmlsIDIwMjUKOzsgS2V5d29yZHM6IGV4dGVuc2lvbnMKCjs7IFRoaXMgZmlsZSBpcyBub3Qg cGFydCBvZiBHTlUgRW1hY3MuCgo7OyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTog eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCjs7IG1vZGlmeSBpdCB1bmRlciB0aGUg dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzCjs7IHB1Ymxpc2hl ZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRoZXIgdmVyc2lvbiAzIG9m IHRoZQo7OyBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u LgoKOzsgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg d2lsbCBiZSB1c2VmdWwsIGJ1dAo7OyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCjs7IE1FUkNIQU5UQUJJTElUWSBvciBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCjs7IEdlbmVyYWwg UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCjs7IFlvdSBzaG91bGQgaGF2ZSBy ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCjs7IGFs b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcv bGljZW5zZXMvPi4KCjs7OyBDb21tZW50YXJ5Ogo7Owo7OyBUaGlzIGxpYnJhcnkgZXh0ZW5k cyBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIGBndHlwZXMnLCBpLmUuIGRhdGEKOzsgdHlwZXMg ZGVmaW5lZCBieSAnY2wtZGVmdHlwZScgd2hpY2ggYXJlIGFsc28gdmFsaWQgYXJndW1lbnQg dHlwZXMKOzsgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KOzsK OzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgZGVmZ3R5cGUnLCBhIG1h Y3JvIHRoYXQgZGVmaW5lcyBhIGd0eXBlLgo7Owo7OyAtIGBndHlwZS1vZicsIGEgZnVuY3Rp b24gdGhhdCBsb29rdXAgdGhlIGd0eXBlIG9mIGFuIG9iamVjdC4KOzsKOzsgLSBgcmVtZ3R5 cGUnLCBhIG1hY3JvIHRoYXQgcmVtb3ZlcyBhIGd0eXBlLgo7Owo7OyBBIHRyaXZpYWwgZXhh bXBsZToKOzsKOzsgKGRlZmd0eXBlIG5lZ2F0aXZlIG5pbCAoKQo7OyAgICJBIG5lZ2F0aXZl IG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlzZmllcyBtaW51c3ApKSkKOzsKOzsg KGRlZmd0eXBlIHplcm8gbmlsICgpCjs7ICAgIkEgemVybyBudW1iZXIiCjs7ICAgJyhhbmQg bnVtYmVyIChzYXRpc2ZpZXMgemVyb3ApKSkKOzsKOzsgKGRlZmd0eXBlIHBvc2l0aXZlIG5p bCAoKQo7OyAgICJBIHBvc2l0aXZlIG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlz ZmllcyBwbHVzcCkpKQo7Owo7OyAoY2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVyICgobiBuZWdh dGl2ZSkpCjs7ICAgKGZvcm1hdCAibmVnYXRpdmUgbnVtYmVyLCAlcyIgbikpCjs7Cjs7IChj bC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHplcm8pKQo7OyAgIChmb3JtYXQgInplcm8g bnVtYmVyLCAlcyIgbikpCjs7Cjs7IChjbC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHBv c2l0aXZlKSkKOzsgICAoZm9ybWF0ICJwb3NpdGl2ZSBudW1iZXIsICVzIiBuKSkKOzsKOzsg KHRlc3QtbnVtYmVyIC0xMjMuMCkKOzsgPT4gIm5lZ2F0aXZlIG51bWJlciwgLTEyMy4wIgo7 OyAodGVzdC1udW1iZXIgKGFicyAtMTIzLjApKQo7OyA9PiAicG9zaXRpdmUgbnVtYmVyLCAx MjMuMCIKOzsgKHRlc3QtbnVtYmVyIChyb3VuZCAwLjAwMDAwMDAwMDAwMSkpCjs7ID0+ICJ6 ZXJvIG51bWJlciwgMCIKOzsKOzsgUGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbnM6Cjs7Cjs7 IFRoZSBjcml0aWNhbCBwb2ludCBvZiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBpcyB0 aGUgZnVuY3Rpb24KOzsgYGd0eXBlLW9mJyB3aGljaCBzZXF1ZW50aWFsbHkgdHJpZXMgYWxs IGtub3duIGd0eXBlcywgZnJvbSB0aGUgbW9zdAo7OyBzcGVjaWZpYyB0byB0aGUgbW9zdCBn ZW5lcmFsLCB1bnRpbCB0aGUgbW9zdCBzcGVjaWZpYyBndHlwZSB0aGF0Cjs7IGFwcGxpZXMg dG8gYSBnaXZlbiBvYmplY3QgaXMgZm91bmQuICBUaGVyZWZvcmUsIHRoZSBtYXhpbXVtIHRp bWUgdG8KOzsgZmluZCBhbiBvYmplY3QncyB0eXBlIGRpcmVjdGx5IGRlcGVuZHMgb24gdGhl IG51bWJlciBvZiBndHlwZXMgdG8KOzsgdHJ5LiAgSXMgdGhlcmUgYSBiZXR0ZXIgc29sdXRp b24/ICBBbnl3YXksIGFzc3VtaW5nIHRoYXQgZWFjaAo7OyBzaW5nbGUgdGVzdCB0byBrbm93 IHdoZXRoZXIgYW4gb2JqZWN0IGlzIG9mIGEgZ2l2ZW4gZ3R5cGUgaXMKOzsgcmVhc29uYWJs eSBmYXN0LCB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhpcyBpbXBsZW1lbnRhdGlvbiBzZWVtcwo7 OyBhY2NlcHRhYmxlIChiYXNlZCBvbiB0aGUgdHJpdmlhbCBleGFtcGxlIGFib3ZlLCBhdHRl bXB0aW5nIDEsMDAwCjs7IGd0eXBlIGNoZWNrcyB0YWtlcyBhYm91dCBoYWxmIGEgbWlsbGlz ZWNvbmQgb24gbXkgc2V0dXApLgo7OwoKOzs7IENvZGU6Cjs7CihyZXF1aXJlICdjbC1saWIp CihldmFsLXdoZW4tY29tcGlsZSAocmVxdWlyZSAnY2wtbWFjcykpICA7Rm9yIGNsLS1maW5k LWNsYXNzLgoKKGRlZnZhciBndHlwZS0tbGlzdCBuaWwKICAiUHJlY2VkZW5jZSBsaXN0IG9m IHRoZSBkZWZpbmVkIGd0eXBlcy4iKQooZGVmdmFyIGd0eXBlLS1zZXFuIDAKICAiU2VxdWVu Y2UgbnVtYmVyIG9mIGRlZmluZWQgZ3R5cGVzLiIpCgooZGVmaW5lLWlubGluZSBndHlwZS1w IChvYmplY3QpCiAgIlJldHVybiBub24tbmlsIGlmIHRoZSB0eXBlIG9mIE9CSkVDVCBpcyBh IGd0eXBlLiIKICAoaW5saW5lLWxldGV2YWxzIChvYmplY3QpCiAgICAoaW5saW5lLXF1b3Rl CiAgICAgKGFuZCAoc3ltYm9scCAsb2JqZWN0KQogICAgICAgICAgKGVxICh0eXBlLW9mIChj bC0tZmluZC1jbGFzcyAsb2JqZWN0KSkgJ2d0eXBlLWNsYXNzKSkpKSkKCihkZWZpbmUtaW5s aW5lIGd0eXBlLS1hbGxwYXJlbnRzIChuYW1lKQogICJSZXR1cm4gYWxsIHBhcmVudHMgb2Yg dHlwZSB3aXRoIE5BTUUuCk5BTUUgbXVzdCBiZSBhIHN5bWJvbCByZXByZXNlbnRpbmcgYSB0 eXBlLiIKICA7OyBUbyBzYXZlIGNhbGxzIHRvIGBjbC0tY2xhc3MtYWxscGFyZW50cycgY2Fj aGUgcGFyZW50cyBvZiBndHlwZXMKICA7OyAocG9zc2libHkgYnVpbHRpbiB0eXBlcykuIGBn dHlwZS0tcmVnaXN0ZXInIHRha2VzIGNhcmUgb2YKICA7OyBjbGVhcmluZyBjYWNoZWQgdmFs dWVzIGlmIGEgZ3R5cGUgaXMgcmVkZWZpbmVkOyBhbmQgdGhlcmUgc2hvdWxkCiAgOzsgYmUg bm90aGluZyB0byBkbyBmb3IgYnVpbHRpbiB0eXBlcyB3aGljaCBzaG91bGQgbm90IGNoYW5n ZS4KICAoaW5saW5lLXF1b3RlCiAgIChvciAoZ2V0ICxuYW1lICdndHlwZS0tYWxscGFyZW50 cykKICAgICAgIChwdXQgLG5hbWUgJ2d0eXBlLS1hbGxwYXJlbnRzCiAgICAgICAgICAgIChj bC0tY2xhc3MtYWxscGFyZW50cyAoY2wtLWZpbmQtY2xhc3MgLG5hbWUpKSkpKSkKCihjbC1k ZWZzdHJ1Y3QKICAgIChndHlwZS1jbGFzcwogICAgICg6aW5jbHVkZSBjbC0tY2xhc3MpCiAg ICAgKDpub2lubGluZSB0KQogICAgICg6Y29uc3RydWN0b3IgbmlsKQogICAgICg6Y29uc3Ry dWN0b3IgZ3R5cGUtLWNsYXNzLW1ha2UKICAgICAgICAgICAgICAgICAgIChuYW1lCiAgICAg ICAgICAgICAgICAgICAgZG9jc3RyaW5nCiAgICAgICAgICAgICAgICAgICAgcGFyZW50LXR5 cGVzCiAgICAgICAgICAgICAgICAgICAgJmF1eCAocGFyZW50cwogICAgICAgICAgICAgICAg ICAgICAgICAgIChtYXBjYXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAo dHlwZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY2wtY2hlY2stdHlwZSB0eXBl IChzYXRpc2ZpZXMgZ3R5cGUtcCkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNs LS1maW5kLWNsYXNzIHR5cGUpKQogICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJlbnQt dHlwZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBmb3Ig Z3R5cGVzLiIpCgooZGVmdW4gZ3R5cGUtcGFyZW50cyAobmFtZSkKICAiR2V0IHBhcmVudHMg b2YgdHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5nIGEgdHlw ZS4KUmV0dXJuIGEgcG9zc2libHkgZW1wdHkgbGlzdCBvZiB0eXBlcy4iCiAgKGNsLWNoZWNr LXR5cGUgbmFtZSAoc2F0aXNmaWVzIGd0eXBlLXApKQogIChndHlwZS0tYWxscGFyZW50cyBu YW1lKSkKCihkZWZ1biBndHlwZS1jaGlsZHJlbiAobmFtZSkKICAiR2V0IGNoaWxkcmVuIG9m IHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYSBzeW1ib2wgcmVwcmVzZW50aW5nIGEg Z3R5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlwZXMuIgogIChjbC1j aGVjay10eXBlIG5hbWUgKHNhdGlzZmllcyBndHlwZS1wKSkKICAobGV0IChjaGlsZHJlbikK ICAgIChkb2xpc3QgKGVsdCBndHlwZS0tbGlzdCkKICAgICAgKG9yIChlcSBuYW1lIGVsdCkK ICAgICAgICAgIChpZiAobWVtcSBuYW1lIChndHlwZS0tYWxscGFyZW50cyBlbHQpKQogICAg ICAgICAgICAgIChwdXNoIGVsdCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVuKSkKCihkZWZ1 biBndHlwZS0tdGllLWJyZWFrZXIgKG0xIG0yKQogICJSZXR1cm4gdGhlIGxlc3Mgc3BlY2lm aWMgb2YgdHdvIG1pbi1lbGVtZW50cyBNMSBhbmQgTTIuClRoYXQgaXMsIHRoZSBtaW4tZWxl bWVudCBmaXJzdCBwdXNoZWQgaW4gdGhlIGd0eXBlIHByZWNlZGVuY2UgbGlzdCwKb3JkZXJl ZCBmcm9tIG1vc3QgdG8gbGVzcyBzcGVjaWZpYyB0eXBlcy4KSWYgTTEgYW5kIE0yIGhvbGQg Z3R5cGVzLCBwcmVmZXIgdGhlIG9uZSB3aXRoIHRoZSBmaXJzdCBkZWZpbmVkIGd0eXBlLgpP dGhlcndpc2UsIHByZWZlciBNMSwgdGhlIGZpcnN0IG1pbi1lbGVtZW50IGZvdW5kIGluIHRo ZSBEQUcuIgogIChpZi1sZXQqICgoaTEgKGdldCAoY2FyIG0xKSAnZ3R5cGUtLXNlcW4pKQog ICAgICAgICAgICAoaTIgKGdldCAoY2FyIG0yKSAnZ3R5cGUtLXNlcW4pKSkKICAgICAgKGlm ICg8IGkxIGkyKSBtMSBtMikKICAgIG0xKSkKCihkZWZ1biBndHlwZS0tdG9wb2xvZ2ljLXNv cnQgKGdyYXBoICZvcHRpb25hbCB0aWUtYnJlYWtlcikKICAiUmV0dXJuIHRoZSB0b3BvbG9n aWNhbGx5IHNvcnRlZCBlbGVtZW50cyBvZiBHUkFQSC4KR1JBUEggbXVzdCBiZSBhIHZhbGlk IGRpcmVjdGVkIGFjeWNsaWMgZ3JhcGggKERBRykgYXMgYSBsaXN0IG9mCmVsZW1lbnRzIChW aSBbVmogVmsuLi5Wbl0pIHdoaWNoIG1lYW5zIHRoYXQgVmkgZGVwZW5kcyB1cG9uIFZqLCBW agp1cG9uIFZrLCBldGMuLCBvciBkZXBlbmRzIHVwb24gbm90aGluZy4gIFNpZ25hbCBhbiBl cnJvciBvdGhlcndpc2UuCkVsZW1lbnRzIGFyZSBjb21wYXJlZCB1c2luZyBgZXEnLgoKSWYg bm9uLW5pbCwgVElFLUJSRUFLRVIgbXVzdCBiZSBhIGZ1bmN0aW9uIHRoYXQgcmVjZWl2ZXMg dGhlCnByZXZpb3VzbHkgYW5kIGxhc3QgZm91bmQgbWluLWVsZW1lbnRzKCopLCBhbmQgbXVz dCByZXR1cm4gb25lIG9mCnRoZW0uICBJZiBUSUUtQlJFQUtFUiBpcyBuaWwgb3Igb21pdHRl ZCwgcHJlZmVyIHRoZSBmaXJzdCBtaW4tZWxlbWVudApmb3VuZCwgaS5lLiB0aGUgb25lIHRo YXQgYXBwZWFycyBmaXJzdCBpbiB0aGUgbmF0dXJhbCBvcmRlciBvZiB0aGUKREFHLgoKWypd IEEgbWluLWVsZW1lbnQgaXMgYW4gZWxlbWVudCB3aXRoIG5vIHN1Y2Nlc3NvciwgbGlrZSAo RCkuCgpTb21lIGV4YW1wbGVzOgoKICAoZ3R5cGUtLXRvcG9sb2dpYy1zb3J0IFxcPScoKEEg QiBDKSAoQiBEKSAoQyBEKSAoRCkpKQogID0+IChBIEIgQyBEKQoKICAoZ3R5cGUtLXRvcG9s b2dpYy1zb3J0IFxcPScoKEEgQiBDKSAoQiBEKSAoQyBEKSAoRCkpCiAgICAgICAgICAgICAg ICAgICAgICAgICAobGFtYmRhIChfcHJldiBsYXN0KSBsYXN0KSkKICA9PiAoQSBDIEIgRCkK CiAgKGd0eXBlLS10b3BvbG9naWMtc29ydCBcXD0nKChBIEIgQykgKEIgRCkgKEQgQikgKEQp KSkKICA9PiBlcnJvciIKICAoZGVjbGFyZSAoc2lkZS1lZmZlY3QtZnJlZSB0KSkKICAoY2wt bGFiZWxzICgocmVtcS1taW5pbWFsIChtIGcpCiAgICAgICAgICAgICAgICA7OyBSZW1vdmUg bWluLWVsZW1lbnQgTSBmcm9tIEcuCiAgICAgICAgICAgICAgICAobGV0ICgobWUgKGNhciBt KSkgcmVzdWx0KQogICAgICAgICAgICAgICAgICAoZG9saXN0IChlIChkZWxxIG0gZykpCiAg ICAgICAgICAgICAgICAgICAgKHB1c2ggKGNvbnMgKGNhciBlKSAocmVtcSBtZSAoY2RyIGUp KSkgcmVzdWx0KSkKICAgICAgICAgICAgICAgICAgcmVzdWx0KSkKICAgICAgICAgICAgICAo bmV4dC1taW5pbWFsIChnKQogICAgICAgICAgICAgICAgOzsgUmV0dXJuIHRoZSBuZXh0IG1p bi1lbGVtZW50IGZvdW5kIGluIEcuCiAgICAgICAgICAgICAgICAobGV0IChtKQogICAgICAg ICAgICAgICAgICAoZG9saXN0IChlIGcpCiAgICAgICAgICAgICAgICAgICAgKG9yIChjZHIg ZSkKICAgICAgICAgICAgICAgICAgICAgICAgOzsgV2hlbiB0aGVyZSBhcmUgdHdvIG1pbi1l bGVtZW50cywgY2FsbCB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgOzsgVElFLUJSRUFL RVIgdG8gZGVjaWRlIHdoaWNoIG9uZSBpcyBtb3JlCiAgICAgICAgICAgICAgICAgICAgICAg IDs7IHNwZWNpZmljLgogICAgICAgICAgICAgICAgICAgICAgICAoc2V0cSBtIChpZiBtIChm dW5jYWxsIHRpZS1icmVha2VyIG0gZSkgZSkpKSkKICAgICAgICAgICAgICAgICAgbSkpKQog ICAgKG9yIHRpZS1icmVha2VyIChzZXRxIHRpZS1icmVha2VyIChsYW1iZGEgKHByZXYgX25l eHQpIHByZXYpKSkKICAgIChsZXQgKChnIChjb3B5LXNlcXVlbmNlIGdyYXBoKSkgdHMpCiAg ICAgICh3aGlsZSAod2hlbi1sZXQqICgobSAobmV4dC1taW5pbWFsIGcpKSkKICAgICAgICAg ICAgICAgKHNldHEgZyAocmVtcS1taW5pbWFsIG0gZykpCiAgICAgICAgICAgICAgIChwdXNo IChjYXIgbSkgdHMpKSkKICAgICAgKGNsLWFzc2VydCAoZXFsIChsZW5ndGggZ3JhcGgpIChs ZW5ndGggdHMpKSBuaWwKICAgICAgICAgICAgICAgICAiSW52YWxpZCBncmFwaCwgJVMiIHRz KQogICAgICB0cykpKQoKKGRlZnVuIGd0eXBlLS1kYWcgKCkKICAiUmV0dXJuIGEgREFHIGZy b20gdGhlIGxpc3Qgb2YgZGVmaW5lZCBndHlwZXMuIgogIChtYXBjYXIgIydndHlwZS0tYWxs cGFyZW50cyBndHlwZS0tbGlzdCkpCgooZGVmdW4gZ3R5cGUtLXJlZ2lzdGVyIChuYW1lICZv cHRpb25hbCBwYXJlbnRzIGFyZ3MpCiAgIlJlZ2lzdGVyIGEgZ3R5cGUgd2l0aCBOQU1FIGFu ZCBQQVJFTlRTLgpBUkdTIGFyZSB0aG9zZSB0aGF0IHdpbGwgYmUgcGFzc2VkIHRvIGBjbC1k ZWZ0eXBlJy4iCiAgOzsgQXQgdGhpcyBwb2ludCBOQU1FIG11c3QgYmUgYSBkZWZpbmVkIHR5 cGUuCiAgKGNsLWFzc2VydCAoZ2V0IG5hbWUgJ2NsLWRlZnR5cGUtaGFuZGxlcikgbmlsCiAg ICAgICAgICAgICAiVW5rbm93biB0eXBlICVTIiBuYW1lKQogIChsZXQgKChjbGFzcyAoY2wt LWZpbmQtY2xhc3MgbmFtZSkpCiAgICAgICAgKHJlZ2VkIChtZW1xIG5hbWUgZ3R5cGUtLWxp c3QpKSkKICAgIChpZiAobnVsbCBjbGFzcykKICAgICAgICAoY2wtYXNzZXJ0IChudWxsIHJl Z2VkKSBuaWwgIkV4aXN0aW5nIHR5cGUgbm90IHJlZ2lzdGVyZWQiKQogICAgICAoY2wtYXNz ZXJ0IHJlZ2VkIG5pbCAiTmV3IHR5cGUgYWxyZWFkeSByZWdpc3RlcmVkIikKICAgICAgKGNs LWFzc2VydCAoZXEgKHR5cGUtb2YgY2xhc3MpICdndHlwZS1jbGFzcykgbmlsCiAgICAgICAg ICAgICAgICAgIlR5cGUgaXMgaW4gYW5vdGhlciBjbGFzczogJVMiICh0eXBlLW9mIGNsYXNz KSkpCiAgICAob3IgKGxpc3RwIHBhcmVudHMpIChzZXRxIHBhcmVudHMgKGxpc3QgcGFyZW50 cykpKQogICAgKGNsLWFzc2VydCAobnVsbCAobWVtcSBuYW1lIHBhcmVudHMpKSBuaWwKICAg ICAgICAgICAgICAgIlR5cGUgaXMgaW4gcGFyZW50czogJVMiIHBhcmVudHMpCiAgICA7OyBT ZXR1cCBhIHR5cGUgZGVzY3JpcHRvciBmb3IgTkFNRSwgd2l0aCBQQVJFTlRTIGFuZCB0aGUg ZG9jc3RyaW5nCiAgICA7OyBwb3NzaWJseSBwcmVzZW50IGluIEFSR1MuCiAgICAobGV0ICgo ZG9jc3RyaW5nIChjYWFyIChtYWNyb2V4cC1wYXJzZS1ib2R5IChjZHIgYXJncykpKSkpCiAg ICAgIChvciAoc3RyaW5ncCBkb2NzdHJpbmcpIChzZXRxIGRvY3N0cmluZyBuaWwpKQogICAg ICAoc2V0ZiAoY2wtLWZpbmQtY2xhc3MgbmFtZSkKICAgICAgICAgICAgKGd0eXBlLS1jbGFz cy1tYWtlIG5hbWUgZG9jc3RyaW5nIHBhcmVudHMpKSkKICAgIChpZiBjbGFzcwogICAgICAg IDs7IENsZWFyIHRoZSBjYWNoZWQgdmFsdWUgb2YgcGFyZW50cyBmb3IgZWFjaCBjaGlsZHJl biBvZiBhCiAgICAgICAgOzsgbW9kaWZpZWQgZ3R5cGUuCiAgICAgICAgKGRvbGlzdCAoYyAo Z3R5cGUtY2hpbGRyZW4gbmFtZSkpCiAgICAgICAgICAoY2wtcmVtcHJvcCBjICdndHlwZS0t YWxscGFyZW50cykpCiAgICAgIDs7IFJlY29yZCB0aGUgbmV3IHR5cGUuCiAgICAgIChwdXNo IG5hbWUgZ3R5cGUtLWxpc3QpCiAgICAgIDs7IEFuZCBpdHMgc2VxdWVuY2UgbnVtYmVyLgog ICAgICAocHV0IG5hbWUgJ2d0eXBlLS1zZXFuIChwcm9nMSBndHlwZS0tc2VxbiAoaW5jZiBn dHlwZS0tc2VxbikpKSkKICAgIDs7IFRvIGZpbmQgdGhlIG1vc3QgcG9zc2libGUgc3BlY2lm aWMgZ3R5cGUgb2YgYW4gb2JqZWN0LCBtb3N0CiAgICA7OyBzcGVjaWZpYyB0eXBlcyBtdXN0 IGJlIHRyaWVkIGJlZm9yZSBtb3JlIGdlbmVyYWwgdHlwZXMuCiAgICA7OyBDb21wdXRlIHRo ZSBndHlwZSBwcmVjZWRlbmNlIGxpc3QgYnkgYSB0b3BvbG9naWMgc29ydCBvZiB0aGUKICAg IDs7IGd0eXBlcyBkZXBlbmRlbmNpZXMgREFHLiAgQXMgdGhlIERBRyBtYXkgaW5jbHVkZSBu b24tZ3R5cGVzCiAgICA7OyBuZWVkZWQgdG8gY29ycmVjdGx5IGNvbXB1dGUgdGhlIHByZWNl ZGVuY2UgbGlzdCwgcmVtb3ZlIHRoZW0KICAgIDs7IGZyb20gdGhlIGZpbmFsIHByZWNlZGVu Y2UgbGlzdDogYGd0eXBlLW9mJyBkb2Vzbid0IGNoZWNrCiAgICA7OyBub24tZ3R5cGUgYXQg cnVuIHRpbWUsIGhhbmRsZWQgYnkgdGhlICJ0eXBlLW9mIiBnZW5lcmFsaXplci4KICAgIChz ZXRxIGd0eXBlLS1saXN0IChzZXEtZmlsdGVyICMnZ3R5cGUtcAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKGd0eXBlLS10b3BvbG9naWMtc29ydAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChndHlwZS0tZGFnKQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICMnZ3R5cGUtLXRpZS1icmVha2VyKSkpCiAgICBuYW1lKSkKCihk ZWZ1biBndHlwZS0tdW5yZWdpc3RlciAobmFtZSkKICAiVW5yZWdpc3RlciB0aGUgZ3R5cGUg d2l0aCBOQU1FLiIKICAoY2wtYXNzZXJ0IChudWxsIChndHlwZS1jaGlsZHJlbiBuYW1lKSkg dCAiVHlwZSBoYXMgY2hpbGRyZW46ICVTIikKICAoY2wtcmVtcHJvcCBuYW1lICdndHlwZS0t YWxscGFyZW50cykKICAoY2wtcmVtcHJvcCBuYW1lICdndHlwZS0tc2VxbikKICAoY2wtcmVt cHJvcCBuYW1lICdjbC0tY2xhc3MpCiAgKGNsLXJlbXByb3AgbmFtZSAnY2wtZGVmdHlwZS1o YW5kbGVyKQogIChzZXRxIGd0eXBlLS1saXN0IChkZWxxIG5hbWUgZ3R5cGUtLWxpc3QpKQog IG5pbCkKCjs7OyMjI2F1dG9sb2FkCihkZWZtYWNybyBkZWZndHlwZSAobmFtZSAmb3B0aW9u YWwgcGFyZW50cyAmcmVzdCBhcmdzKQogICJEZWZpbmUgTkFNRSBhcyBhIGd0eXBlIHRoYXQg aW5oZXJpdHMgZnJvbSBQQVJFTlRTLgpJZiBhIGd0eXBlIHdpdGggTkFNRSBhbHJlYWR5IGV4 aXN0cywgcmVwbGFjZSBpdC4KCk5BTUUgaXMgYW4gdW5xdW90ZWQgc3ltYm9sIHJlcHJlc2Vu dGluZyBhIGd0eXBlLgoKT3B0aW9uYWwgYXJndW1lbnQgUEFSRU5UUyBpcyBlaXRoZXIgYW4g dW5xdW90ZWQgc3ltYm9sIG9yIGxpc3Qgb2YKc3ltYm9scyBvdGhlciB0aGFuIE5BTUUgcmVw cmVzZW50aW5nIHR5cGVzIHBhcmVudHMgb2YgTkFNRS4KUEFSRU5UUyBuaWwgb3Igb21pdHRl ZCBtZWFucyB0aGF0IE5BTUUgaXMgYSByb290IHR5cGUuCgpBbHNvIHBhc3MgTkFNRSBhbmQg QVJHUyB0byBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIE5BTUUgYXMgYSBuZXcgZGF0YQp0eXBl LiIKICAoZGVjbGFyZSAoZGVidWcgY2wtZGVmbWFjcm8pIChkb2Mtc3RyaW5nIDQpIChpbmRl bnQgMykpCiAgKGNsLXdpdGgtZ2Vuc3ltcyAoZXJyKQogICAgYChjb25kaXRpb24tY2FzZSAs ZXJyCiAgICAgICAgIChwcm9nbgogICAgICAgICAgIChjbC1kZWZ0eXBlICxuYW1lICxAYXJn cykKICAgICAgICAgICAoZ3R5cGUtLXJlZ2lzdGVyICcsbmFtZSAnLHBhcmVudHMgJyxhcmdz KSkKICAgICAgIChlcnJvcgogICAgICAgIChndHlwZS0tdW5yZWdpc3RlciAnLG5hbWUpCiAg ICAgICAgKGVycm9yIChlcnJvci1tZXNzYWdlLXN0cmluZyAsZXJyKSkpKSkpCgooZGVmbWFj cm8gcmVtZ3R5cGUgKG5hbWUpCiAgIlJlbW92ZSB0aGUgZ3R5cGUgd2l0aCBOQU1FLgpOQU1F IGlzIGFuIHVucXVvdGVkIHN5bWJvbCByZXByZXNlbnRpbmcgYSBndHlwZS4KU2lnbmFsIGFu IGVycm9yIGlmIG90aGVyIGd0eXBlcyBpbmhlcml0IGZyb20gTkFNRS4iCiAgYChwcm9nbgog ICAgIChjbC1jaGVjay10eXBlICcsbmFtZSAoc2F0aXNmaWVzIGd0eXBlLXApKQogICAgIChn dHlwZS0tdW5yZWdpc3RlciAnLG5hbWUpKSkKCjs7IEludGVybmFsIGRhdGEgdXNlZCB0byBk ZXRlY3QgZW5kbGVzcyByZWN1cnNpb24gaW4gJ2d0eXBlLW9mJy4KKGRlZnZhciBndHlwZS0t b2JqZWN0IChtYWtlLXN5bWJvbCAidm9pZCIpKQooZGVmdmFyIGd0eXBlLS10eXBlIG5pbCkK CihkZWZ1biBndHlwZS1vZiAob2JqZWN0KQogICJSZXR1cm4gdGhlIG1vc3Qgc3BlY2lmaWMg cG9zc2libGUgZ3R5cGUgb2YgT0JKRUNULCBvciBuaWwgaWYgbm9uZS4iCiAgOzsgSWdub3Jl IHJlY3Vyc2l2ZSBjYWxsIG9uIHRoZSBzYW1lIE9CSkVDVCwgd2hpY2ggY2FuIGxlZ2l0aW1h dGVseQogIDs7IG9jY3VyIHdoZW4sIGZvciBleGFtcGxlLCBhIHBhcmVudCB0eXBlIGlzIGlu dmVzdGlnYXRpbmcgd2hldGhlcgogIDs7IGFuIG9iamVjdCdzIHR5cGUgaXMgdGhhdCBvZiBv bmUgb2YgaXRzIGNoaWxkcmVuLgogICh1bmxlc3MgKGVxIG9iamVjdCBndHlwZS0tb2JqZWN0 KQogICAgKGxldCAoKGd0eXBlLS1vYmplY3Qgb2JqZWN0KQogICAgICAgICAgKHR5cGVzIGd0 eXBlLS1saXN0KQogICAgICAgICAgZm91bmQpCiAgICAgIDs7IFRyeSBlYWNoIGd0eXBlLCBm cm9tIG1vc3Qgc3BlY2lmaWMgdG8gbGVhc3Qgc3BlY2lmaWMsIHVudGlsCiAgICAgIDs7IG9u ZSBpcyBmb3VuZCBhcyB0aGUgbW9zdCBzcGVjaWZpYyBwb3NzaWJsZSBndHlwZSBvZiBPQkpF Q1QuCiAgICAgICh3aGlsZSAoYW5kIChub3QgZm91bmQpIHR5cGVzKQogICAgICAgIChsZXQg KChndHlwZS0tdHlwZSAoY2FyIHR5cGVzKSkpCiAgICAgICAgICAoaWYgKGNsLXR5cGVwIG9i amVjdCBndHlwZS0tdHlwZSkKICAgICAgICAgICAgICAoc2V0cSBmb3VuZCBndHlwZS0tdHlw ZSkKICAgICAgICAgICAgKHNldHEgdHlwZXMgKGNkciB0eXBlcykpKSkpCiAgICAgIGZvdW5k KSkpCgo7OzsgTWV0aG9kIGRpc3BhdGNoaW5nCjs7CihkZWZ1biBndHlwZS0tc3BlY2lhbGl6 ZXJzICh0YWcgJnJlc3QgXykKICAiSWYgVEFHIGlzIGEgZ3R5cGUsIHJldHVybiBpdHMgc3Bl Y2lhbGl6ZXJzLiIKICAoaWYgKGd0eXBlLXAgdGFnKSAoZ3R5cGUtLWFsbHBhcmVudHMgdGFn KSkpCgooY2wtZ2VuZXJpYy1kZWZpbmUtZ2VuZXJhbGl6ZXIgZ3R5cGUtLWdlbmVyYWxpemVy CiAgMTAKICAobGFtYmRhIChvYmogJnJlc3QgXykgYChndHlwZS1vZiAsb2JqKSkKICAjJ2d0 eXBlLS1zcGVjaWFsaXplcnMpCgooY2wtZGVmbWV0aG9kIGNsLWdlbmVyaWMtZ2VuZXJhbGl6 ZXJzIDpleHRyYSAiZ3R5cGUtb2YiICh0eXBlKQogICJTdXBwb3J0IGZvciBkaXNwYXRjaCBv biBndHlwZXMuIgogIChpZiAoZ3R5cGUtcCB0eXBlKQogICAgICAobGlzdCBndHlwZS0tZ2Vu ZXJhbGl6ZXIpCiAgICAoY2wtY2FsbC1uZXh0LW1ldGhvZCkpKQoKKHByb3ZpZGUgJ2d0eXBl KQoKOzs7IGd0eXBlLmVsIGVuZHMgaGVyZQo= --------------K7ayjXP8dGQosZr0arxKGOQ6--
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 11 Apr 2025 16:26:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 12:26:18 2025
Received: from localhost ([127.0.0.1]:51471 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3HCs-00019w-1N
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 12:26:18 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13865)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u3HCq-00019h-8a
for 77725 <at> debbugs.gnu.org; Fri, 11 Apr 2025 12:26:16 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 48E9D801CC;
Fri, 11 Apr 2025 12:26:10 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744388763;
bh=QkUTtgbokRJaxYtUqIgLaDHF0CO7A5VqS7cLdC/eL6k=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=JHLQ3zmd+ezW+6m0IJuVg9XTyhx9Urhct2oHSKKTd004fYH2qCPYXOucz9MtHvT1W
HR4brIcUm+K7sBgsFH8MSGP+4RZaTbYiVXXAYj+wSwAPqfsdqfu9i9JcDAmUEXe3LA
LrxE+7qUFHp3/AZ64Cghffe8IqpNzqmzGyBXPzz8KpPr2FEz6Nv94lldOVvRAxbt0g
4O9CqQL6wAerIG6fDDMOJ/RNVH/OxKXdVl6z0afBrrmd9LIpaWegfr2khZbE3U8dIv
GHptrVnivCZoGpSMwYjusPYogZm2Bw/3PR4pKbOrfBkRZMIxCc59LpidK/w5RLX6yq
xKURWrQ1dh72g==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9A8C9804C9;
Fri, 11 Apr 2025 12:26:03 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7B1031202BB;
Fri, 11 Apr 2025 12:26:03 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: David Ponce <da_vid@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
Message-ID: <jwv8qo6n0py.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
<f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN>
Date: Fri, 11 Apr 2025 12:26:05 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.172 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Does this mean that for a `cl-deftype'-like generalizer to work
> correctly, it must be part of the "typof" generalizer?
No, but it needs to be either always more precise or always less precise
than `type-of`.
IOW, either:
(eql (gtypeof-generalizer A) (gtypeof-generalizer B))
IMPLIES ((eql (gtypeof-generalizer A) nil)
OR (eql (cl-type-of A) (cl-type-of B)))
or the reverse. That's a current limitation in the cl-generic system.
One way to solve this is to use a generalizer that returns either nil or
a pair containing both the `gtype-of` and the `cl-type-of`, so it's
trivially always more precise than `cl-type-of`. But beware: these
things are compared with `eql` so you need to "uniquify" them with
a sort of hashconsing scheme.
BTW if you do
(defgtype cons-car-foo nil ()
"A cons with a `foo' car."
`(satisfies ,(lambda (x) (eq (car-safe x) 'foo))))
(defgtype cons-cdr-foo nil ()
"A cons with a `foo' cdr."
`(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo))))
what's the `(gtype-of '(foo . foo))` ?
> Or am I missing something? --- Sorry, I only started studying
> cl-generic relatively recently, and I probably don't understand
> all its intricacies ;-)
Yeah, it's unsatisfactorily intricate, indeed. It's designed first and
foremost to keep the dispatch "simple and reasonable fast", at the cost
of making `cl-generic-define-generalizer` a very sharp tool. =F0=9F=99=82
I have recently been thinking about how to make it more reliable (which
would also make it more flexible/powerful, allowing the definition of
both `and` and `or` specializers). I have some vague idea, but there's
no code at all yet, and it might come with some non-trivial tradeoffs
(e.g. preloading the byte-compiler).
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.Received: (at 77725) by debbugs.gnu.org; 11 Apr 2025 15:04:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 11:04:24 2025 Received: from localhost ([127.0.0.1]:51202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u3Fvc-0004Vi-46 for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 11:04:24 -0400 Received: from smtp-29.smtpout.orange.fr ([80.12.242.29]:50725 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u3FvW-0004V7-O0 for 77725 <at> debbugs.gnu.org; Fri, 11 Apr 2025 11:04:21 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 3FvOu4XDK724L3FvSuQZmY; Fri, 11 Apr 2025 17:04:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1744383856; bh=c9KZDmLNFIGaaw/k0e8rChzd4Scd8yW6K5hacRM5uZE=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=qYV8GdC2tVCb+4AKMQUo+/iTNt1tX85CRWje87Gj/vKVOJoKSM1XXUvREfxO9z+Y4 S/1Y8BOb33D1P5dzFw7SIdbeB/HrgmapxhUQC5t2lPNWajlsUMrEhLlleYa5TnvN3b OcHi4mgi335n/E/nZbfKsllfXw0BYwUGpYdgto1JZD1lCNLWjovGk4Hxz0qmC29eyS DGtyhnlkM27uxOVTEG1JrdI9/f8P9UniCLN7EaeFazDF9+My15lRBaDo3SN2anQSvK li0LBsv4k75oyrgDFW+rurZrZWtxpvR4dAu5kpsoUfy+g0OOmEMC+hvhRiDOsb+Cof cU+wEwbktnnmg== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Fri, 11 Apr 2025 17:04:16 +0200 X-ME-IP: 90.112.40.65 Message-ID: <f63cd290-ba06-4f67-b106-0a7ca7b2c881@HIDDEN> Date: Fri, 11 Apr 2025 17:04:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic? To: Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN> <868qo7ozzh.fsf@HIDDEN> <jwvplhiestk.fsf-monnier+emacs@HIDDEN> Content-Language: fr, en-US From: David Ponce <da_vid@HIDDEN> In-Reply-To: <jwvplhiestk.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77725 Cc: 77725 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-04-11 15:41, Stefan Monnier wrote: > Hi David, > >>> As part of some other works, I created the attached "gtype" library, >>> which complements `cl-deftype' so that such defined types are also >>> recognized as argument types for dispatching generic function methods. >>> Here is a quick example of use: >>> >>> (defgtype face nil () >>> "A face type." >>> '(satisfies facep)) >>> >>> (gtype-of 'default) >>> => face >>> (cl-type-of 'default) >>> => symbol >>> >>> (cl-defmethod my-add-face ((text string) (face face)) >>> (propertize text 'face face)) >>> => my-add-face > > Nice. > >>> I've been using this library successfully in some of my code, and was >>> wondering if it could help add this functionality to Emacs. My goal >>> is not to include this library, but to use it as a starting point for >>> further reflection on this subject. > > The problem with adding new generalizers is to make sure they interact > correctly with others. If you allow `satisfies` kind of definitions, > then it's easy to end up with situations where one of your new types is > neither a subtype (aka sub-specializer) nor a supertype > (super-specializer) of an existing type (specializer). > > Let's take `function` defined as `(satisfies functionp)` is an example. > > (functionp '(lambda () 1)) > => t > (type-of '(lambda a)) > => cons > > this suggests (satisfies functionp) should be a subtype of `cons`, but > that is clearly wrong because > > (functionp (lambda () 1)) > => t > (consp (lambda () 1)) > => nil > > The type-dispatch code wants *one* value (generalizer) to lookup the > hash-table where it will find the corresponding effective method. > That one value should be "the most specific" generalizer among the > generalizers currently used for that generic function. > > Now a `gtype-of` called `g-function` built from `(satisfies functionp)` > will be sometimes more specific and sometimes less specific than > `type-of`, so there is no correct PRIORITY to indicate to > `cl-generic-define-generalizer`: we'll end up with dispatch errors if > a generic function has a method for both `g-function` and for `cons`. > > > Stefan > Hi Stefan, Thank you very much for your feedback! Your remarks make sense, for sure. Does this mean that for a `cl-deftype'-like generalizer to work correctly, it must be part of the "typof" generalizer? In other words, that a function like `gtype-of' should fall back to `cl-type-of' when there is no corresponding gtype for an object? Or am I missing something? --- Sorry, I only started studying cl-generic relatively recently, and I probably don't understand all its intricacies ;-)
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 11 Apr 2025 13:41:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 09:41:52 2025
Received: from localhost ([127.0.0.1]:49601 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3Edj-0006if-Gm
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 09:41:51 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65131)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1u3Edh-0006iJ-Iu
for 77725 <at> debbugs.gnu.org; Fri, 11 Apr 2025 09:41:50 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B8749801CC;
Fri, 11 Apr 2025 09:41:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1744378901;
bh=aLrlpaqrdo3szFgPr5+3BgiajoyN0PqHkYE9mLN7rDY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=eyke12sbTDv3I7bVpCeuU+4lDGZSf95t98hNYuEC/g7tTrT7CZ02EhZJ06BFHQrEA
KVAABz94w3+WkHCtlZlCWgoOgR6WZgJiSpJ5VPX9T4agTa7SZcJJ7LMSL0um2cx/ch
Wh5cL+hkUtDo3s4KzSiwutk//pPIMSfNSUp4Wz1tb9df9lWRHFJSmuyd0GPjmrhZcW
zlEbM7j4bJ4rKkLi5WcDCdx3hh2mMgDF5T8n1fuVySXo6tjsaTMUjX1g43kgzxfrUt
esEpO5AhJXW1n8PKuAiw5qGzjDglyNXdaGMeZgNWjWFUkyUzJAGIFV1HmmdAt7aGlE
kMs/tmnt42UbA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D6C2E80599;
Fri, 11 Apr 2025 09:41:41 -0400 (EDT)
Received: from pastel (unknown [104.247.242.5])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AD62E120346;
Fri, 11 Apr 2025 09:41:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#77725: 31.0.50; Add support for types accepted by
`cl-typep' to cl-generic?
In-Reply-To: <868qo7ozzh.fsf@HIDDEN>
Message-ID: <jwvplhiestk.fsf-monnier+emacs@HIDDEN>
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
<868qo7ozzh.fsf@HIDDEN>
Date: Fri, 11 Apr 2025 09:41:40 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.354 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: David Ponce <da_vid@HIDDEN>, 77725 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Hi David,
>> As part of some other works, I created the attached "gtype" library,
>> which complements `cl-deftype' so that such defined types are also
>> recognized as argument types for dispatching generic function methods.
>> Here is a quick example of use:
>>
>> (defgtype face nil ()
>> "A face type."
>> '(satisfies facep))
>>
>> (gtype-of 'default)
>> => face
>> (cl-type-of 'default)
>> => symbol
>>
>> (cl-defmethod my-add-face ((text string) (face face))
>> (propertize text 'face face))
>> => my-add-face
Nice.
>> I've been using this library successfully in some of my code, and was
>> wondering if it could help add this functionality to Emacs. My goal
>> is not to include this library, but to use it as a starting point for
>> further reflection on this subject.
The problem with adding new generalizers is to make sure they interact
correctly with others. If you allow `satisfies` kind of definitions,
then it's easy to end up with situations where one of your new types is
neither a subtype (aka sub-specializer) nor a supertype
(super-specializer) of an existing type (specializer).
Let's take `function` defined as `(satisfies functionp)` is an example.
(functionp '(lambda () 1))
=> t
(type-of '(lambda a))
=> cons
this suggests (satisfies functionp) should be a subtype of `cons`, but
that is clearly wrong because
(functionp (lambda () 1))
=> t
(consp (lambda () 1))
=> nil
The type-dispatch code wants *one* value (generalizer) to lookup the
hash-table where it will find the corresponding effective method.
That one value should be "the most specific" generalizer among the
generalizers currently used for that generic function.
Now a `gtype-of` called `g-function` built from `(satisfies functionp)`
will be sometimes more specific and sometimes less specific than
`type-of`, so there is no correct PRIORITY to indicate to
`cl-generic-define-generalizer`: we'll end up with dispatch errors if
a generic function has a method for both `g-function` and for `cons`.
Stefan
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at 77725) by debbugs.gnu.org; 11 Apr 2025 08:37:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 04:37:57 2025
Received: from localhost ([127.0.0.1]:48625 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u39td-0002fw-0u
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 04:37:57 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:50592)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u39ta-0002fe-2p
for 77725 <at> debbugs.gnu.org; Fri, 11 Apr 2025 04:37:54 -0400
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 <eliz@HIDDEN>)
id 1u39tT-0000ay-ND; Fri, 11 Apr 2025 04:37:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=X78ael6JLBIlHxw3SCMO1KkSDUVuJxhisIHg6i7pLZ4=; b=XYNivL5nk8bb
Du5Bfihzz1Hcun/JTMmQMSu0EOKv196XzBNOI/uarvZU9cNLW9+r4DW83f5ZnAX7zDg5VhPWWm4Ut
SsiHnZOBfbfrLcmGbjMYE2XtFwu74JM50YNBrGI5T6TvywCB+JWY2QLW2GdIHjS9Kp1OsoOGA16/C
PSnQGcc+pabiofqJauDMOfqD1aPP9flVzy9go7cVpiOzlVlWOaWP7CfHrqUVCMv3hJKu+0N3tgtYd
OngDoK3dFqcvOu0smscVbss2W+dweN3Kx7ELlI/Vt+mY/t3cDaDenEKZkhvzmcvOmfCDOJQgxQrKl
N4R5jtlTekD/CoTyqzVk+Q==;
Date: Fri, 11 Apr 2025 11:37:38 +0300
Message-Id: <868qo7ozzh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: David Ponce <da_vid@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
(bug-gnu-emacs@HIDDEN)
Subject: Re: bug#77725: 31.0.50;
Add support for types accepted by `cl-typep' to cl-generic?
References: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77725
Cc: 77725 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Fri, 11 Apr 2025 09:14:41 +0200
> From: David Ponce via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> In the cl-generic library, the implementation of the
> `cl-generic-generalizers' "typeof" method, used to dispatch
> "normal types", mentions in a FIXME on line 1367: "Add support for
> other "types" accepted by `cl-typep' such as `character', `face',
> `keyword', ...?".
>
> As part of some other works, I created the attached "gtype" library,
> which complements `cl-deftype' so that such defined types are also
> recognized as argument types for dispatching generic function methods.
> Here is a quick example of use:
>
> (defgtype face nil ()
> "A face type."
> '(satisfies facep))
>
> (gtype-of 'default)
> => face
> (cl-type-of 'default)
> => symbol
>
> (cl-defmethod my-add-face ((text string) (face face))
> (propertize text 'face face))
> => my-add-face
>
> (my-add-face "text" 'bold)
> => #("text" 0 4 (face bold))
>
> (my-add-face "text" 'bad-face)
> => No applicable method: add-face, "text", bad-face
>
> I've been using this library successfully in some of my code, and was
> wondering if it could help add this functionality to Emacs. My goal
> is not to include this library, but to use it as a starting point for
> further reflection on this subject.
>
> My library is relatively concise and adopts a design similar to that
> used for built-in types. The new types (which I call "gtypes") are
> instances of the structure `gtype-class', derived from `cl--class',
> just as built-in types are instances of the structure `built-in-class'
> also derived from `cl--class'. gtypes thus benefits from the existing
> infrastructure used for other types. I also chose to have a separate
> "generalizer" for gtypes. I'm not sure if it would be desirable to
> extend the existing generalizer "typof" to support such types.
>
> I would therefore be interested in hearing more expert opinions on
> my implementation and whether it could help add this functionality to
> cl-generic, if it makes sense.
Thanks, adding Stefan to the discussion.
bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 11 Apr 2025 07:15:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 03:15:08 2025
Received: from localhost ([127.0.0.1]:48406 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u38bS-0004DG-LI
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 03:15:08 -0400
Received: from lists.gnu.org ([2001:470:142::17]:60348)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <da_vid@HIDDEN>) id 1u38bP-0003wx-Sv
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 03:15:05 -0400
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 <da_vid@HIDDEN>) id 1u38bJ-0003rO-5q
for bug-gnu-emacs@HIDDEN; Fri, 11 Apr 2025 03:14:57 -0400
Received: from smtp-30.smtpout.orange.fr ([80.12.242.30]
helo=smtp.smtpout.orange.fr)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <da_vid@HIDDEN>) id 1u38bG-0005SS-7Q
for bug-gnu-emacs@HIDDEN; Fri, 11 Apr 2025 03:14:56 -0400
Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA
id 38b3u04qE724L38b6uxRDI; Fri, 11 Apr 2025 09:14:45 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr;
s=t20230301; t=1744355685;
bh=2UI7M3qLfQE5LbfHoG1pFjvgVsqiCTDgOReIVK8khWo=;
h=Message-ID:Date:MIME-Version:To:From:Subject;
b=DlseKPD6Q8EBYzCfgBJE7FXzd/8CbIHS8dfQc6WwrWKIq3tqOGvApEgWgQZ6BBXRu
yRE092/fdwN28uhqigpcPRas/9G45Qp1BC0IuT7Yi7X93uk7KfftQa4lZnCSoosBEu
xozZ/MZFOIJJ+C8fYXafzAuHbJqFDChNsCT6FNcbjVOcl7nBgkYNePqhPy9az2+Pq8
WahzECAkjHiOweXoYhtG+QxJy8bWqDq3IMfqyl0omTdTxKpsFOFaLn0TipOW4cTmqY
75q3x0qFZlmWWRJVoeZ8Ncg/sPJe0Mx3+IjuO+AApfvlWV5quC+iEKWpuOA6UA1Sv0
sk32cmoA28KuA==
X-ME-Helo: [192.168.1.21]
X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI=
X-ME-Date: Fri, 11 Apr 2025 09:14:45 +0200
X-ME-IP: 90.112.40.65
Content-Type: multipart/mixed; boundary="------------n1eQXsc1ZT8h0XgHFf6i8M60"
Message-ID: <8cf44be2-96da-4383-84bd-9470a748d500@HIDDEN>
Date: Fri, 11 Apr 2025 09:14:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: fr, en-US
To: bug-gnu-emacs@HIDDEN
From: David Ponce <da_vid@HIDDEN>
Subject: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Received-SPF: pass client-ip=80.12.242.30; envelope-from=da_vid@HIDDEN;
helo=smtp.smtpout.orange.fr
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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
This is a multi-part message in MIME format.
--------------n1eQXsc1ZT8h0XgHFf6i8M60
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hello
In the cl-generic library, the implementation of the
`cl-generic-generalizers' "typeof" method, used to dispatch
"normal types", mentions in a FIXME on line 1367: "Add support for
other "types" accepted by `cl-typep' such as `character', `face',
`keyword', ...?".
As part of some other works, I created the attached "gtype" library,
which complements `cl-deftype' so that such defined types are also
recognized as argument types for dispatching generic function methods.
Here is a quick example of use:
(defgtype face nil ()
"A face type."
'(satisfies facep))
(gtype-of 'default)
=> face
(cl-type-of 'default)
=> symbol
(cl-defmethod my-add-face ((text string) (face face))
(propertize text 'face face))
=> my-add-face
(my-add-face "text" 'bold)
=> #("text" 0 4 (face bold))
(my-add-face "text" 'bad-face)
=> No applicable method: add-face, "text", bad-face
I've been using this library successfully in some of my code, and was
wondering if it could help add this functionality to Emacs. My goal
is not to include this library, but to use it as a starting point for
further reflection on this subject.
My library is relatively concise and adopts a design similar to that
used for built-in types. The new types (which I call "gtypes") are
instances of the structure `gtype-class', derived from `cl--class',
just as built-in types are instances of the structure `built-in-class'
also derived from `cl--class'. gtypes thus benefits from the existing
infrastructure used for other types. I also chose to have a separate
"generalizer" for gtypes. I'm not sure if it would be desirable to
extend the existing generalizer "typof" to support such types.
I would therefore be interested in hearing more expert opinions on
my implementation and whether it could help add this functionality to
cl-generic, if it makes sense.
Thank you for your time.
--------------n1eQXsc1ZT8h0XgHFf6i8M60
Content-Type: text/x-emacs-lisp; charset=UTF-8; name="gtype.el"
Content-Disposition: attachment; filename="gtype.el"
Content-Transfer-Encoding: base64
Ozs7IGd0eXBlLmVsIC0tLSBEYXRhIHR5cGVzIGZvciBnZW5lcmljIGZ1bmN0aW9ucyAtKi0g
bGV4aWNhbC1iaW5kaW5nOnQgLSotCgo7OyBDb3B5cmlnaHQgKEMpIDIwMjUgRGF2aWQgUG9u
Y2UKCjs7IEF1dGhvcjogRGF2aWQgUG9uY2UgPGRhX3ZpZEBvcmFuZ2UuZnI+Cjs7IE1haW50
YWluZXI6IERhdmlkIFBvbmNlIDxkYV92aWRAb3JhbmdlLmZyPgo7OyBDcmVhdGVkOiA2IEFw
cmlsIDIwMjUKOzsgS2V5d29yZHM6IGV4dGVuc2lvbnMKCjs7IFRoaXMgZmlsZSBpcyBub3Qg
cGFydCBvZiBHTlUgRW1hY3MuCgo7OyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTog
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCjs7IG1vZGlmeSBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzCjs7IHB1Ymxpc2hl
ZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRoZXIgdmVyc2lvbiAzIG9m
IHRoZQo7OyBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u
LgoKOzsgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg
d2lsbCBiZSB1c2VmdWwsIGJ1dAo7OyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCjs7IE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCjs7IEdlbmVyYWwg
UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCjs7IFlvdSBzaG91bGQgaGF2ZSBy
ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCjs7IGFs
b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcv
bGljZW5zZXMvPi4KCjs7OyBDb21tZW50YXJ5Ogo7Owo7OyBUaGlzIGxpYnJhcnkgZXh0ZW5k
cyBgY2wtZGVmdHlwZScgdG8gZGVmaW5lIGBndHlwZXMnLCBpLmUuIGRhdGEKOzsgdHlwZXMg
ZGVmaW5lZCBieSAnY2wtZGVmdHlwZScgd2hpY2ggYXJlIGFsc28gdmFsaWQgYXJndW1lbnQg
dHlwZXMKOzsgZm9yIGRpc3BhdGNoaW5nIGdlbmVyaWMgZnVuY3Rpb24gbWV0aG9kcy4KOzsK
OzsgVGhlIG1haW4gZW50cnkgcG9pbnRzIGFyZToKOzsKOzsgLSBgZGVmZ3R5cGUnLCBhIG1h
Y3JvIHRoYXQgZGVmaW5lcyBhIGd0eXBlLgo7Owo7OyAtIGBndHlwZS1vZicsIGEgZnVuY3Rp
b24gdGhhdCBsb29rdXAgdGhlIGd0eXBlIG9mIGFuIG9iamVjdC4KOzsKOzsgLSBgcmVtZ3R5
cGUnLCBhIG1hY3JvIHRoYXQgcmVtb3ZlcyBhIGd0eXBlLgo7Owo7OyBBIHRyaXZpYWwgZXhh
bXBsZToKOzsKOzsgKGRlZmd0eXBlIG5lZ2F0aXZlIG5pbCAoKQo7OyAgICJBIG5lZ2F0aXZl
IG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlzZmllcyBtaW51c3ApKSkKOzsKOzsg
KGRlZmd0eXBlIHplcm8gbmlsICgpCjs7ICAgIkEgemVybyBudW1iZXIiCjs7ICAgJyhhbmQg
bnVtYmVyIChzYXRpc2ZpZXMgemVyb3ApKSkKOzsKOzsgKGRlZmd0eXBlIHBvc2l0aXZlIG5p
bCAoKQo7OyAgICJBIHBvc2l0aXZlIG51bWJlciIKOzsgICAnKGFuZCBudW1iZXIgKHNhdGlz
ZmllcyBwbHVzcCkpKQo7Owo7OyAoY2wtZGVmbWV0aG9kIHRlc3QtbnVtYmVyICgobiBuZWdh
dGl2ZSkpCjs7ICAgKGZvcm1hdCAibmVnYXRpdmUgbnVtYmVyLCAlcyIgbikpCjs7Cjs7IChj
bC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHplcm8pKQo7OyAgIChmb3JtYXQgInplcm8g
bnVtYmVyLCAlcyIgbikpCjs7Cjs7IChjbC1kZWZtZXRob2QgdGVzdC1udW1iZXIgKChuIHBv
c2l0aXZlKSkKOzsgICAoZm9ybWF0ICJwb3NpdGl2ZSBudW1iZXIsICVzIiBuKSkKOzsKOzsg
KHRlc3QtbnVtYmVyIC0xMjMuMCkKOzsgPT4gIm5lZ2F0aXZlIG51bWJlciwgLTEyMy4wIgo7
OyAodGVzdC1udW1iZXIgKGFicyAtMTIzLjApKQo7OyA9PiAicG9zaXRpdmUgbnVtYmVyLCAx
MjMuMCIKOzsgKHRlc3QtbnVtYmVyIChyb3VuZCAwLjAwMDAwMDAwMDAwMSkpCjs7ID0+ICJ6
ZXJvIG51bWJlciwgMCIKOzsKOzsgUGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbnM6Cjs7Cjs7
IFRoZSBjcml0aWNhbCBwb2ludCBvZiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBpcyB0
aGUgZnVuY3Rpb24KOzsgYGd0eXBlLW9mJyB3aGljaCBzZXF1ZW50aWFsbHkgdHJpZXMgYWxs
IGtub3duIGd0eXBlcywgZnJvbSB0aGUgbW9zdAo7OyBzcGVjaWZpYyB0byB0aGUgbW9zdCBn
ZW5lcmFsLCB1bnRpbCB0aGUgbW9zdCBzcGVjaWZpYyBndHlwZSB0aGF0Cjs7IGFwcGxpZXMg
dG8gYSBnaXZlbiBvYmplY3QgaXMgZm91bmQuICBUaGVyZWZvcmUsIHRoZSBtYXhpbXVtIHRp
bWUgdG8KOzsgZmluZCBhbiBvYmplY3QncyB0eXBlIGRpcmVjdGx5IGRlcGVuZHMgb24gdGhl
IG51bWJlciBvZiBndHlwZXMgdG8KOzsgdHJ5LiAgSXMgdGhlcmUgYSBiZXR0ZXIgc29sdXRp
b24/ICBBbnl3YXksIGFzc3VtaW5nIHRoYXQgZWFjaAo7OyBzaW5nbGUgdGVzdCB0byBrbm93
IHdoZXRoZXIgYW4gb2JqZWN0IGlzIG9mIGEgZ2l2ZW4gZ3R5cGUgaXMKOzsgcmVhc29uYWJs
eSBmYXN0LCB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhpcyBpbXBsZW1lbnRhdGlvbiBzZWVtcwo7
OyBhY2NlcHRhYmxlIChiYXNlZCBvbiB0aGUgdHJpdmlhbCBleGFtcGxlIGFib3ZlLCBhdHRl
bXB0aW5nIDEsMDAwCjs7IGd0eXBlIGNoZWNrcyB0YWtlcyBhYm91dCBoYWxmIGEgbWlsbGlz
ZWNvbmQgb24gbXkgc2V0dXApLgo7OwoKOzs7IENvZGU6Cjs7CihyZXF1aXJlICdjbC1saWIp
CgooY2wtZGVmc3RydWN0CiAgICAoZ3R5cGUtY2xhc3MKICAgICAoOmluY2x1ZGUgY2wtLWNs
YXNzKQogICAgICg6bm9pbmxpbmUgdCkKICAgICAoOmNvbnN0cnVjdG9yIG5pbCkKICAgICAo
OmNvbnN0cnVjdG9yIGd0eXBlLS1jbGFzcy1tYWtlCiAgICAgICAgICAgICAgICAgICAobmFt
ZSBkb2NzdHJpbmcgcGFyZW50LXR5cGVzCiAgICAgICAgICAgICAgICAgICAgICAgICAmYXV4
IChwYXJlbnRzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobWFwY2FyCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAodHlwZSkKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIChvciAoY2wtLWZpbmQtY2xhc3MgdHlwZSkKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZXJyb3IgIlVua25vd24gdHlwZTog
JVMiIHR5cGUpKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJlbnQtdHlw
ZXMpKSkpCiAgICAgKDpjb3BpZXIgbmlsKSkKICAiVHlwZSBkZXNjcmlwdG9ycyBmb3IgZ3R5
cGVzLiIpCgooZGVmdmFyIGd0eXBlLS1saXN0IG5pbAogICJMaXN0IG9mIGFsbCB0aGUgZ3R5
cGVzIGN1cnJlbnRseSBkZWZpbmVkLiIpCgooZGVmaW5lLWlubGluZSBndHlwZS1wIChvYmpl
Y3QpCiAgIlJldHVybiBub24tbmlsIGlmIHRoZSB0eXBlIG9mIE9CSkVDVCBpcyBhIGd0eXBl
LiIKICAoaW5saW5lLWxldGV2YWxzIChvYmplY3QpCiAgICAoaW5saW5lLXF1b3RlCiAgICAg
KGFuZCAoc3ltYm9scCAsb2JqZWN0KQogICAgICAgICAgKGVxICh0eXBlLW9mIChjbC0tZmlu
ZC1jbGFzcyAsb2JqZWN0KSkgJ2d0eXBlLWNsYXNzKSkpKSkKCihkZWZtYWNybyBndHlwZS0t
YWxscGFyZW50cyAobmFtZSkKICAiUmV0dXJuIGFsbCBwYXJlbnRzIG9mIHR5cGUgd2l0aCBO
QU1FLgpOQU1FIG11c3QgYmUgYSBzeW1ib2wgcmVwcmVzZW50aW5nIGEgdHlwZS4iCiAgOzsg
VG8gc2F2ZSBjYWxscyB0byBgY2wtLWNsYXNzLWFsbHBhcmVudHMnIGNhY2hlIHBhcmVudHMg
b2YgZ3R5cGVzCiAgOzsgKHBvc3NpYmx5IGJ1aWx0aW4gdHlwZXMpLiBgZ3R5cGUtLXJlZ2lz
dGVyJyB0YWtlcyBjYXJlIG9mCiAgOzsgY2xlYXJpbmcgY2FjaGVkIHZhbHVlcyBpZiBhIGd0
eXBlIGlzIHJlZGVmaW5lZDsgYW5kIHRoZXJlIHNob3VsZAogIDs7IGJlIG5vdGhpbmcgdG8g
ZG8gZm9yIGJ1aWx0aW4gdHlwZXMgd2hpY2ggc2hvdWxkIG5vdCBjaGFuZ2UuCiAgYChvciAo
Z2V0ICxuYW1lICdndHlwZS0tYWxscGFyZW50cykKICAgICAgIChwdXQgLG5hbWUgJ2d0eXBl
LS1hbGxwYXJlbnRzCiAgICAgICAgICAgIChjbC0tY2xhc3MtYWxscGFyZW50cyAoY2wtLWZp
bmQtY2xhc3MgLG5hbWUpKSkpKQoKKGRlZnVuIGd0eXBlLXBhcmVudHMgKG5hbWUpCiAgIkdl
dCBwYXJlbnRzIG9mIHR5cGUgd2l0aCBOQU1FLgpOQU1FIGlzIGEgc3ltYm9sIHJlcHJlc2Vu
dGluZyBhIHR5cGUuClJldHVybiBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YgdHlwZXMuIgog
IChhbmQgKHN5bWJvbHAgbmFtZSkKICAgICAgIChsZXQgKChjbGFzcyAoY2wtLWZpbmQtY2xh
c3MgbmFtZSkpKQogICAgICAgICAoaWYgY2xhc3MKICAgICAgICAgICAgIChpZiAobWVtcSAo
dHlwZS1vZiBjbGFzcykgJyhndHlwZS1jbGFzcyBidWlsdC1pbi1jbGFzcykpCiAgICAgICAg
ICAgICAgICAgOzsgQ2FjaGUgZ3R5cGUgKGFuZCBidWlsdGluIHR5cGUpIHBhcmVudHMuCiAg
ICAgICAgICAgICAgICAgKGd0eXBlLS1hbGxwYXJlbnRzIG5hbWUpCiAgICAgICAgICAgICAg
IDs7IERvbid0IGNhY2hlIG90aGVyIHR5cGUgcGFyZW50cy4KICAgICAgICAgICAgICAgKGNs
LS1jbGFzcy1hbGxwYXJlbnRzIGNsYXNzKSkpKSkpCgooZGVmdW4gZ3R5cGUtY2hpbGRyZW4g
KG5hbWUpCiAgIkdldCBjaGlsZHJlbiBvZiB0aGUgZ3R5cGUgd2l0aCBOQU1FLgpOQU1FIGlz
IGEgc3ltYm9sIHJlcHJlc2VudGluZyBhIGd0eXBlLgpSZXR1cm4gYSBwb3NzaWJseSBlbXB0
eSBsaXN0IG9mIHR5cGVzLiIKICAobGV0IChjaGlsZHJlbikKICAgIChkb2xpc3QgKGVsdCBn
dHlwZS0tbGlzdCkKICAgICAgKG9yIChlcSBuYW1lIGVsdCkKICAgICAgICAgIChpZiAobWVt
cSBuYW1lIChndHlwZS0tYWxscGFyZW50cyBlbHQpKQogICAgICAgICAgICAgIChwdXNoIGVs
dCBjaGlsZHJlbikpKSkKICAgIGNoaWxkcmVuKSkKCihkZWZ1biBndHlwZS0tcmVnaXN0ZXIg
KG5hbWUgJm9wdGlvbmFsIHBhcmVudHMgYXJncykKICAiUmVnaXN0ZXIgYSBndHlwZSB3aXRo
IE5BTUUgYW5kIFBBUkVOVFMuCkFSR1MgYXJlIHRob3NlIHRoYXQgd2lsbCBiZSBwYXNzZWQg
dG8gYGNsLWRlZnR5cGUnLiIKICA7OyBBdCB0aGlzIHBvaW50IE5BTUUgbXVzdCBiZSBhIGRl
ZmluZWQgdHlwZS4KICAoY2wtYXNzZXJ0IChnZXQgbmFtZSAnY2wtZGVmdHlwZS1oYW5kbGVy
KSBuaWwKICAgICAgICAgICAgICJVbmtub3duIHR5cGUgJVMiIG5hbWUpCiAgKGxldCAoKGNs
YXNzIChjbC0tZmluZC1jbGFzcyBuYW1lKSkKICAgICAgICAocmVnZWQgKG1lbXEgbmFtZSBn
dHlwZS0tbGlzdCkpKQogICAgKGlmIChudWxsIGNsYXNzKQogICAgICAgIChjbC1hc3NlcnQg
KG51bGwgcmVnZWQpIG5pbCAiRXhpc3RpbmcgdHlwZSBub3QgcmVnaXN0ZXJlZCIpCiAgICAg
IChjbC1hc3NlcnQgcmVnZWQgbmlsICJOZXcgdHlwZSBhbHJlYWR5IHJlZ2lzdGVyZWQiKQog
ICAgICAoY2wtYXNzZXJ0IChlcSAodHlwZS1vZiBjbGFzcykgJ2d0eXBlLWNsYXNzKSBuaWwK
ICAgICAgICAgICAgICAgICAiVHlwZSBpcyBpbiBhbm90aGVyIGNsYXNzOiAlUyIgKHR5cGUt
b2YgY2xhc3MpKSkKICAgIChvciAobGlzdHAgcGFyZW50cykgKHNldHEgcGFyZW50cyAobGlz
dCBwYXJlbnRzKSkpCiAgICAoY2wtYXNzZXJ0IChudWxsIChtZW1xIG5hbWUgcGFyZW50cykp
IG5pbAogICAgICAgICAgICAgICAiVHlwZSBpcyBpbiBwYXJlbnRzOiAlUyIgcGFyZW50cykK
ICAgIDs7IFNldHVwIGEgdHlwZSBkZXNjcmlwdG9yIGZvciBOQU1FLCB3aXRoIFBBUkVOVFMg
YW5kIHRoZSBkb2NzdHJpbmcKICAgIDs7IHBvc3NpYmx5IHByZXNlbnQgaW4gQVJHUy4KICAg
IChsZXQgKChkb2NzdHJpbmcgKGNhYXIgKG1hY3JvZXhwLXBhcnNlLWJvZHkgKGNkciBhcmdz
KSkpKSkKICAgICAgKG9yIChzdHJpbmdwIGRvY3N0cmluZykgKHNldHEgZG9jc3RyaW5nIG5p
bCkpCiAgICAgIChzZXRmIChjbC0tZmluZC1jbGFzcyBuYW1lKQogICAgICAgICAgICAoZ3R5
cGUtLWNsYXNzLW1ha2UgbmFtZSBkb2NzdHJpbmcgcGFyZW50cykpKQogICAgKGlmIGNsYXNz
CiAgICAgICAgOzsgQ2xlYXIgdGhlIGNhY2hlZCB2YWx1ZSBvZiBwYXJlbnRzIGZvciBlYWNo
IGNoaWxkcmVuIG9mIGEKICAgICAgICA7OyBtb2RpZmllZCBndHlwZS4KICAgICAgICAoZG9s
aXN0IChjIChndHlwZS1jaGlsZHJlbiBuYW1lKSkKICAgICAgICAgIChjbC1yZW1wcm9wIGMg
J2d0eXBlLS1hbGxwYXJlbnRzKSkKICAgICAgOzsgUmVjb3JkIHRoZSBuZXcgdHlwZS4KICAg
ICAgKHB1c2ggbmFtZSBndHlwZS0tbGlzdCkpCiAgICA7OyBUbyBmaW5kIHRoZSBtb3N0IHBv
c3NpYmxlIHNwZWNpZmljIGd0eXBlIG9mIGFuIG9iamVjdCwgdGhlIG1vc3QKICAgIDs7IHNw
ZWNpZmljIHR5cGVzIG11c3QgYmUgdHJpZWQgYmVmb3JlIHRoZSBtb3JlIGdlbmVyYWwgdHlw
ZXMuIFRoZQogICAgOzsgbGlzdCBvZiBndHlwZXMgaXMgdGhlcmVmb3JlIHNvcnRlZCBhY2Nv
cmRpbmdseSwgYXNzdW1pbmcgZWFjaAogICAgOzsgdHlwZSBpcyBkaXN0aW5jdCBhbmQgdGhh
dCB0aGUgbW9yZSBwYXJlbnRzIGEgdHlwZSBoYXMsIHRoZSBtb3JlCiAgICA7OyBzcGVjaWZp
YyBpdCBpcy4KICAgIChzZXRxIGd0eXBlLS1saXN0CiAgICAgICAgICAoc29ydCBndHlwZS0t
bGlzdAogICAgICAgICAgICAgICAgOmtleSAobGFtYmRhICh0eXBlKSAobGVuZ3RoIChndHlw
ZS0tYWxscGFyZW50cyB0eXBlKSkpCiAgICAgICAgICAgICAgICA6bGVzc3AgIyc+PQogICAg
ICAgICAgICAgICAgOmluLXBsYWNlIHQpKQogICAgbmFtZSkpCgooZGVmdW4gZ3R5cGUtLXVu
cmVnaXN0ZXIgKG5hbWUpCiAgIlVucmVnaXN0ZXIgdGhlIGd0eXBlIHdpdGggTkFNRS4iCiAg
KGNsLWNoZWNrLXR5cGUgbmFtZSAoc2F0aXNmaWVzIGd0eXBlLXApKQogIChjbC1hc3NlcnQg
KG51bGwgKGd0eXBlLWNoaWxkcmVuIG5hbWUpKSB0ICJUeXBlIGhhcyBjaGlsZHJlbjogJVMi
KQogIChjbC1yZW1wcm9wIG5hbWUgJ2d0eXBlLS1hbGxwYXJlbnRzKQogIChjbC1yZW1wcm9w
IG5hbWUgJ2NsLS1jbGFzcykKICAoY2wtcmVtcHJvcCBuYW1lICdjbC1kZWZ0eXBlLWhhbmRs
ZXIpCiAgKHNldHEgZ3R5cGUtLWxpc3QgKGRlbHEgbmFtZSBndHlwZS0tbGlzdCkpCiAgbmls
KQoKOzs7IyMjYXV0b2xvYWQKKGRlZm1hY3JvIGRlZmd0eXBlIChuYW1lICZvcHRpb25hbCBw
YXJlbnRzICZyZXN0IGFyZ3MpCiAgIkRlZmluZSBOQU1FIGFzIGEgZ3R5cGUgdGhhdCBpbmhl
cml0cyBmcm9tIFBBUkVOVFMuCklmIGEgZ3R5cGUgd2l0aCBOQU1FIGFscmVhZHkgZXhpc3Rz
LCByZXBsYWNlIGl0LgoKTkFNRSBpcyBhbiB1bnF1b3RlZCBzeW1ib2wgcmVwcmVzZW50aW5n
IGEgZ3R5cGUuCgpPcHRpb25hbCBhcmd1bWVudCBQQVJFTlRTIGlzIGVpdGhlciBhbiB1bnF1
b3RlZCBzeW1ib2wgb3IgbGlzdCBvZgpzeW1ib2xzIG90aGVyIHRoYW4gTkFNRSByZXByZXNl
bnRpbmcgdHlwZXMgcGFyZW50cyBvZiBOQU1FLgpQQVJFTlRTIG5pbCBvciBvbWl0dGVkIG1l
YW5zIHRoYXQgTkFNRSBpcyBhIHJvb3QgdHlwZS4KCkFsc28gcGFzcyBOQU1FIGFuZCBBUkdT
IHRvIGBjbC1kZWZ0eXBlJyB0byBkZWZpbmUgTkFNRSBhcyBhIG5ldyBkYXRhCnR5cGUuIgog
IChkZWNsYXJlIChkZWJ1ZyBjbC1kZWZtYWNybykgKGRvYy1zdHJpbmcgNCkgKGluZGVudCAz
KSkKICBgKHByb2duCiAgICAgKGNsLWRlZnR5cGUgLG5hbWUgLEBhcmdzKQogICAgIChndHlw
ZS0tcmVnaXN0ZXIgJyxuYW1lICcscGFyZW50cyAnLGFyZ3MpKSkKCihkZWZtYWNybyByZW1n
dHlwZSAobmFtZSkKICAiUmVtb3ZlIHRoZSBndHlwZSB3aXRoIE5BTUUuCk5BTUUgaXMgYW4g
dW5xdW90ZWQgc3ltYm9sIHJlcHJlc2VudGluZyBhIGd0eXBlLgpTaWduYWwgYW4gZXJyb3Ig
aWYgb3RoZXIgZ3R5cGVzIGluaGVyaXQgZnJvbSBOQU1FLiIKICBgKGd0eXBlLS11bnJlZ2lz
dGVyICcsbmFtZSkpCgo7OyBJbnRlcm5hbCBkYXRhIHVzZWQgdG8gZGV0ZWN0IGVuZGxlc3Mg
cmVjdXJzaW9uIGluICdndHlwZS1vZicuCihkZWZ2YXIgZ3R5cGUtLW9iamVjdCAobWFrZS1z
eW1ib2wgInZvaWQiKSkKKGRlZnZhciBndHlwZS0tdHlwZSBuaWwpCgooZGVmdW4gZ3R5cGUt
b2YgKG9iamVjdCkKICAiUmV0dXJuIHRoZSBtb3N0IHNwZWNpZmljIHBvc3NpYmxlIGd0eXBl
IG9mIE9CSkVDVCwgb3IgbmlsIGlmIG5vbmUuIgogIDs7IElnbm9yZSByZWN1cnNpdmUgY2Fs
bCBvbiB0aGUgc2FtZSBPQkpFQ1QsIHdoaWNoIGNhbiBsZWdpdGltYXRlbHkKICA7OyBvY2N1
ciB3aGVuLCBmb3IgZXhhbXBsZSwgYSBwYXJlbnQgdHlwZSBpcyBpbnZlc3RpZ2F0aW5nIHdo
ZXRoZXIKICA7OyBhbiBvYmplY3QncyB0eXBlIGlzIHRoYXQgb2Ygb25lIG9mIGl0cyBjaGls
ZHJlbi4KICAodW5sZXNzIChlcSBvYmplY3QgZ3R5cGUtLW9iamVjdCkKICAgIChsZXQgKChn
dHlwZS0tb2JqZWN0IG9iamVjdCkKICAgICAgICAgICh0eXBlcyBndHlwZS0tbGlzdCkKICAg
ICAgICAgIGZvdW5kKQogICAgICA7OyBUcnkgZWFjaCBndHlwZSwgZnJvbSBtb3N0IHNwZWNp
ZmljIHRvIGxlYXN0IHNwZWNpZmljLCB1bnRpbAogICAgICA7OyBvbmUgaXMgZm91bmQgYXMg
dGhlIG1vc3Qgc3BlY2lmaWMgcG9zc2libGUgZ3R5cGUgb2YgT0JKRUNULgogICAgICAod2hp
bGUgKGFuZCAobm90IGZvdW5kKSB0eXBlcykKICAgICAgICAobGV0ICgoZ3R5cGUtLXR5cGUg
KGNhciB0eXBlcykpKQogICAgICAgICAgKGlmIChjbC10eXBlcCBvYmplY3QgZ3R5cGUtLXR5
cGUpCiAgICAgICAgICAgICAgKHNldHEgZm91bmQgZ3R5cGUtLXR5cGUpCiAgICAgICAgICAg
IChzZXRxIHR5cGVzIChjZHIgdHlwZXMpKSkpKQogICAgICBmb3VuZCkpKQoKOzs7IE1ldGhv
ZCBkaXNwYXRjaGluZwo7OwooZGVmdW4gZ3R5cGUtLXNwZWNpYWxpemVycyAodGFnICZyZXN0
IF8pCiAgIklmIFRBRyBpcyBhIGd0eXBlLCByZXR1cm4gaXRzIHNwZWNpYWxpemVycy4iCiAg
KGlmIChndHlwZS1wIHRhZykgKGd0eXBlLS1hbGxwYXJlbnRzIHRhZykpKQoKKGNsLWdlbmVy
aWMtZGVmaW5lLWdlbmVyYWxpemVyIGd0eXBlLS1nZW5lcmFsaXplcgogIDEwCiAgKGxhbWJk
YSAob2JqICZyZXN0IF8pIGAoZ3R5cGUtb2YgLG9iaikpCiAgIydndHlwZS0tc3BlY2lhbGl6
ZXJzKQoKKGNsLWRlZm1ldGhvZCBjbC1nZW5lcmljLWdlbmVyYWxpemVycyA6ZXh0cmEgImd0
eXBlLW9mIiAodHlwZSkKICAiU3VwcG9ydCBmb3IgZGlzcGF0Y2ggb24gZ3R5cGVzLiIKICAo
aWYgKGd0eXBlLXAgdHlwZSkKICAgICAgKGxpc3QgZ3R5cGUtLWdlbmVyYWxpemVyKQogICAg
KGNsLWNhbGwtbmV4dC1tZXRob2QpKSkKCihwcm92aWRlICdndHlwZSkKCjs7OyBndHlwZS5l
bCBlbmRzIGhlcmUK
--------------n1eQXsc1ZT8h0XgHFf6i8M60--
David Ponce <da_vid@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#77725; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.