From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Implement fast verisons of json-parse functions Date: Sat, 30 Mar 2024 16:00:30 +0300 Message-ID: <86plvbdgcx.fsf@gnu.org> References: <87h6h2rsgn.fsf@gmail.com> <867chy3vpm.fsf@gnu.org> <87cyrqrqnb.fsf@gmail.com> <865xxi3tsu.fsf@gnu.org> <874jd2rnwj.fsf@gmail.com> <864jd14lqs.fsf@gnu.org> <87edc1rzig.fsf@gmail.com> <865xx4dv0g.fsf@gnu.org> <871q7snffr.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12109"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?G=C3=A9za_Herman?= , Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 30 14:02:07 2024 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 1rqYLW-0002x2-T6 for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Mar 2024 14:02:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rqYKZ-0008Qc-Lm; Sat, 30 Mar 2024 09:01:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rqYKA-0008KV-6y for emacs-devel@gnu.org; Sat, 30 Mar 2024 09:00:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rqYK6-0004Ug-1v; Sat, 30 Mar 2024 09:00:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=6rbb74WJVP5eMpWB/hNvKiPIacyiOhLJdEd2BtiSv9A=; b=nZAI1R60vjNUO3b7C8tc 9kRp+N/69JVfX00magVexmW6VFebiSciSp4Z+yYJZWW1/KqKW+0OhUvvuvoK6nn57bQ2I6hhGmqHo 6eJ65byPFAtJkBdF83OpGbgqT/nx5U24tZMZphZ3bl/gkcSxqjun/9ywS9O7sf1jUUioTcQ6kpxk+ e2gStdXS/H9m8oxhq0iD4VRl3uLmmW+r9Ysnys1eqtMJlIwZR+un8WrqKrX3ih1nb9VAB2WjgQSjN d53gLpUTj8nL3IR9tHGeHDjkcrYVH8i1fbVg3HMi+C/8ZCnDv3S6ocvJEpxbVFM8YdfSGVWkYUiKx 5aNVQf3lXGR5pQ==; In-Reply-To: <871q7snffr.fsf@gmail.com> (message from Herman, =?utf-8?Q?G?= =?utf-8?Q?=C3=A9za?= on Sat, 30 Mar 2024 11:50:19 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317394 Archived-At: > From: Herman, Géza > Cc: Géza Herman , > emacs-devel@gnu.org > Date: Sat, 30 Mar 2024 11:50:19 +0100 > > > > . 3 tests in test/src/json-tests.el are now failing, where > > they > > succeeded before; see the log at the end > > . the times of the relevant tests don't seem to be faster than > > the libjansson version, perhaps because this is an > > unoptimized > > build > > 3 test failures: > 1. Handling of utf-8 decode errors: the new parser emits > json-utf8-decode-error instead of json-parse-error (this is what > the test expects). I can fix this by modifying the test OK, but we will need to mention this in NEWS as an incompatible change. > 2. Handling of a single \0 byte: the new parser emits > json-end-of-file. I think this is not the best error kind for > this case, so I'll modify the parser to emit json-parse-error > instead. This is still different what the test expects > (wrong-type-argument), but I think there is no reason to treat > zero bytes specially. Considering the JSON spec, it's the same > error as any other unexpected byte value. Does JSON allow null bytes in its strings? If not, why wrong-type-argument is not TRT? > 3. Handling objects with duplicate keys. That's an interesting > one. With alist/plist objects, the old parser removed duplicate > members, but the new parser doesn't remove such members, it keeps > them all. The JSON spec doesn't really say anything about this > case, so I think we're free to do anything we like. Mattias > Engdegård had an interesting idea: what if we put alist/plist > members in reversed order? This way, if one uses assq/plist-get to > get values by keys, the behavior will be consistent with the hash > table representation (which keeps that last value of duplicate > keys). I like the idea of consistency, but I don't like that the > elements will become reversed after parsing. I had the idea that > if the hash table kept the first value of duplicate keys, then > we'd also have consistency. What do you think? I think we should modify the expected results of the test to match the new behavior, and leave the order as it is now. But please also compare with what the Lisp implementation does in these cases, as that could give us further ideas or make us reconsider. Mattias, any comments or suggestions?