From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Internationalize Emacs's messages (swahili) Date: Thu, 31 Dec 2020 21:55:20 -0800 (PST) Message-ID: <892fac78-0457-41b4-a442-46d992ca6e23@default> References: <87o8ivumn5.fsf@telefonica.net> <83h7odrdwy.fsf@gnu.org> <86sg7w39fh.fsf@163.com> <83pn30pku5.fsf@gnu.org> <86wnx8otoj.fsf@163.com> <834kkbp9vr.fsf@gnu.org> <87czyxuxw6.fsf@db48x.net> <87y2hlt82w.fsf@db48x.net> <87lfdlvsw4.fsf@logand.com> <83h7o8ncly.fsf@gnu.org> <87pn2wudab.fsf@db48x.net> <87mty0c3m1.fsf@gnus.org> <83czywnb86.fsf@gnu.org> <87im8ob707.fsf@gnus.org> <87eejcb6nx.fsf@gnus.org> <875z4ob5c9.fsf@gnus.org> <87a6u09nkq.fsf@gnus.org> <875z4o9jdg.fsf@gnus.org> <87r1nb8yoj.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36918"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Lars Ingebrigtsen , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 01 06:56:21 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kvDQD-0009IO-9b for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 06:56:21 +0100 Original-Received: from localhost ([::1]:48468 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvDQC-0004lu-CF for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 00:56:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvDPQ-0004KS-BO for emacs-devel@gnu.org; Fri, 01 Jan 2021 00:55:32 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:50598) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvDPN-00034F-Dw; Fri, 01 Jan 2021 00:55:31 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 1015n896128858; Fri, 1 Jan 2021 05:55:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=wlymaWo6lG5CrK/w4fa+FtjK+vyauUu2FlijGcXp0f0=; b=aw6lakD67Cg1zEVlJMHZvsLNzru6mL6lyHvWOUKg20lRdrWvChGjupM9Ewj9PkEI9ZQE uXAnPf2pOQb6rT6OuzD8ItKbr1PXyE/KpOtMQca0i09kfdE/Nu692ZUDGQc32W51hNk5 u21xnP/Gbz3L4uUR98ra6SW1Tjfx2znQvA1QpvLPF0ZUKiENhoCnkOVwbQFRRdzarClQ 8TVpEy5Z9JGBMqfeBiczyb4XbdaURwnFPnLegCUT8qidqOM5s+6J8QLsXvvLleUj7Nl1 XiM/MAOY85YbM806siOU5PBBpyxzu2e/fPKffg6YN7r3uetXT3U4h+vr7XJmjynMO9EU 6Q== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 35nvkqv6cp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 01 Jan 2021 05:55:25 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 1015o6u5036201; Fri, 1 Jan 2021 05:55:25 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 35pexuxhmu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Jan 2021 05:55:25 +0000 Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 1015tLkK014856; Fri, 1 Jan 2021 05:55:22 GMT In-Reply-To: <87r1nb8yoj.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5095.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9851 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 spamscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101010034 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9851 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 bulkscore=0 adultscore=0 priorityscore=1501 malwarescore=0 impostorscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101010034 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262214 Archived-At: > > +DEFUN ("length<", Flength_less, Slength_less, 2, 2, 0, >=20 > I went ahead and pushed this (along with > and =3D, which seems like a > natural set). Is this the set of C-code definitions you implemented? https://repo.or.cz/emacs.git/blobdiff/714ca849ba658405ddde698cdc5836c4c9b28= 9ca..0f790464d547dd57a857d88dab309b286067ac45:/src/fns.c Let me say at the outset that I'm no expert in C code. But it looks to me like this might have the problems I spoke of wrt Lisp implementations that don't handle dotted or circular lists correctly. Is that the case? For circular lists, it looks like you just raise an error systematically. To me, that's not as good as it should be. The Lisp definitions I provided work fine for circular lists - their length is greater than any numeric value, through ` most-positive-fixnum'. (The function `nthcdr' is well-defined and performant for a circular-list argument.) For dotted lists, I cited the fact that simple Lisp definitions of the `length(<|=3D|>)' predicates can raise an error for some inputs and for other inputs return the same length as if the last cdr were wrapped in `list'. IOW, the behavior is inconsistent: no consistent notification (e.g. error) that the list is dotted; silent answers as if the list were not dotted, in ~half the cases. Does your C code have these problems also? The Lisp definitions I posted don't have these problems. They handle circular and dotted lists fine. For dotted lists, the length returned is always the same as what it would be for a proper list equal to the dotted list but with the last cdr wrapped in `list'. I imagine that the same approach I used in Lisp could be used in C, with no loss in performance wrt the code you have. But again, I'm no expert, especially in C. In case you missed the Lisp definitions I'm talking about, they're at the end of this message: https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg01850.html