From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/32060 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "'William Lupton' via pandoc-discuss" Newsgroups: gmane.text.pandoc Subject: logging.lua and 'light userdata' Date: Sat, 21 Jan 2023 17:41:15 +0000 Message-ID: References: <1D22B433-211B-4033-8A63-F637F52B2008@gmail.com> <87fsc4koud.fsf@zeitkraut.de> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e50e1905f2c9aca3" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38286"; mail-complaints-to="usenet@ciao.gmane.io" To: pandoc-discuss Original-X-From: pandoc-discuss+bncBCS4HJ6WSAHBBSGHWCPAMGQEQFAG6FI-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Sat Jan 21 18:41:33 2023 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane-mx.org Original-Received: from mail-lj1-f188.google.com ([209.85.208.188]) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pJHrx-0009oQ-35 for gtp-pandoc-discuss@m.gmane-mx.org; Sat, 21 Jan 2023 18:41:33 +0100 Original-Received: by mail-lj1-f188.google.com with SMTP id l1-20020a2e9081000000b0028b97d2c493sf1949178ljg.2 for ; Sat, 21 Jan 2023 09:41:33 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1674322892; cv=pass; d=google.com; s=arc-20160816; b=Qh+WRFIK57EMP4BPE/EFGP6StVR1ZE1vYqHkOCs2C7WYryWvXlQWu3JKWwNn18IxN6 WjLZsHivR+OvAEqJBQt67GoYQkDfoCPuPW6PzohtwMzjtVQ2Q5O3TYyFb8nSXS55bF2S 0pwDlfl35hGZEc/Co/tCxEHOgM0a8kKMzCjBUWWJLIFcH6toSc3DCKlKxbHBW1p+afUS wBr2tgNNW2I/aIjZazPHS57SGgwkgDBoPTVZBT9M0xj8F2cPlmYb4z1g6ijt3MNhdGpu w0uqwOAGkkrFTM02BpJiUT2Yk2Bn0D9EWhURPLkslp4Zze13Ns62rAI1sqVvpvbSI4sc lLaA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=h64dM61KhhUUvewz+37nsz11WHDEUgNLEyd/mS88wtM=; b=VOwBo0bBFG0A2EwBYs9JFc9A8qoXZzx5PGNl8M5RgeOf12DLTs2rDruuNA0YcuidcD oUSCqhdyEMTQwstxMHp5094QROmDmVeF5mXuyLuwev24zZdvnATIzddOnEqCK7bxBFGz jTtE3XkeyiJ9OjWinvMzx/JBUiEjjjI/WseUu/sM3YNgr3pcFBAEJqk5ZHGgNvW8FVag WPj3+mNxHGkz8uLDNysaAUokd2baYQqdabFX0WlV0pXIK7p2bGZy9oHgxNumzmM8kMox yB6cmF87kt8/V+ivqmf7V5gD/OJRq1y13d/nY/OQWrdyjLu/yQYMwmDRnC+WCI5Svzdk TLPw== ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@broadband-forum.org header.s=google header.b=PGMXO28t; spf=pass (google.com: domain of wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadband-forum.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20210112; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=h64dM61KhhUUvewz+37nsz11WHDEUgNLEyd/mS88wtM=; b=ongZz2bvpRGjW/ouxr0zzI/IYaKa/fQb7UmAYiBUrdVvqRJeZ1UqMF7wtIs/E/oFQ/ X1jazTPGt/fXSAWve6hPXSCY8y4QkhD02EmLz3aec9fw7xNIVYOYgcm6U8ax607K01Dj kig7ommaVw2SGZgCV4Pjjwa3vqPeGOFJzVJ2GaLvGpsDClyWWzrW0xqZEo+Q0Hkhdr7X TYJQXJ6cmkC6jrIbi5H0rT+V7PhDhIgYoTFUb9Fgga1J1M/bQolB85NgiKIu616JbL7T szNEl1N2u1NSGhaiRL8SQuoXQwrDsli9ShC0f10rzOY1czES0Gqm/QDhKgG8Pt+seK5w hM0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :x-spam-checked-in-group:list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:to:subject :message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h64dM61KhhUUvewz+37nsz11WHDEUgNLEyd/mS88wtM=; b=dv1ZGxHecCfWwBH0Rl9mk9P+bZYhn+6xG4jN/axk39uAcuX7c5nrVJK6OeEDotmZp8 MK24O1qpuKnZMHjaLZZDp+TmzTjsqBY9jwzuSIt+/OtePFU+dsUzgNsZwtgsiZQ8+aP2 yUKfYeZ7LC1auMTlk27thE++/HB52HFVkHurTp2rXy4UkarfKYm52odYHgPO1vuMGnmI h09rbcqX5fTyeVAxtTJGxzTQA4bBsrn4OFRWVQ1tQjfQUBIKieoUbXQYJv0qg+3+YDnn MxxclRjpYFX6TESwqAfTKNSu8Y0Lgxbx/QtVGQsSJ3NznxkKaqdnKGf/2zRB156 X-Gm-Message-State: AFqh2kqgU2QFw7EJ0gU+dPFHRpCw9TfYGVu0XxLEpVg0VB7LhuAH5J4c YkQzBwRx0gS+5Khnj0zxsS0= X-Google-Smtp-Source: AMrXdXusTGnqbHZkj02ztXU58JnVHq0SAN1iUWzTtHEoN5wUeMWEcQV1BGk0DuF1gtWdUbZX54LZkQ== X-Received: by 2002:ac2:53ae:0:b0:4cc:59f7:4453 with SMTP id j14-20020ac253ae000000b004cc59f74453mr1569601lfh.323.1674322892518; Sat, 21 Jan 2023 09:41:32 -0800 (PST) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 2002:a2e:83cc:0:b0:27f:b767:aaf6 with SMTP id s12-20020a2e83cc000000b0027fb767aaf6ls1110810ljh.3.-pod-prod-gmail; Sat, 21 Jan 2023 09:41:27 -0800 (PST) X-Received: by 2002:a2e:9dda:0:b0:284:53cd:74d7 with SMTP id x26-20020a2e9dda000000b0028453cd74d7mr4909602ljj.0.1674322887555; Sat, 21 Jan 2023 09:41:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674322887; cv=none; d=google.com; s=arc-20160816; b=xtkcusZoEZ5nVyLE2sEQsCxL7aVOkPy0CQ3b/UDY/mPqRnP2HEMJdr6duIr53lTNKS QPEyRFuBJ7iO3XmEgZ4rcDT4KrmahuRHYPtx+qj0GZcjnrq5W/jhYjyxc5lxIs+DlDOj LaayrXq/x3aQIclhOnerOiCyIXo9jNjySu6ZdSQ79nA6FHMT1VEGSHFhX7Yymz2xlmL0 oaAqbfZEOwtggWub1OM0E9iomUxTRh8R2LBe64cxmoq/f2Wc/1RwX2ChjuG6GGUkFdrw UKbw5/HPhsYkIRaSbVRy1X+PdUXFJli0ncFQZtw+8swhFYDw7l6DeEPJGiDafqfPR55Y 4/pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=jEh5YAxZcAIVhClHKc9Wf7Cx3PZMN+JxHVv3IVGi0uk=; b=Hl/7TrpvL0yKKRsqNzWK01NHx2qckNmrbJU108WdvjqzaGktI9iFWgcxti0RFq5Ves E6z7T7Kpc8WwcNalsy3wm1RBKVj/XwBZ8B7CcmPX6Fvxu0io/OCAJ31sHs+ikETRIu4P zB7vWGS6woVnx01VKodvHkwsgrtryrphEVA3y1LDf44yNQlC4Ji6+0WnN2vTn10s7ghE 0XgU9eOsX+ec5BANIGgsvLaF4mXYWClbV0l4mYfxzz+1Z1bal4F3hZQlaQwVYw0+vwaF jKmIoAkAUqmqSZjjOLqF6SKkHI4iB/vem8eJU2c39O4ck27lgX7IAawH0GESJOOn0tq8 zRGA== ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@broadband-forum.org header.s=google header.b=PGMXO28t; spf=pass (google.com: domain of wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadband-forum.org Original-Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com. [2a00:1450:4864:20::52a]) by gmr-mx.google.com with ESMTPS id bd16-20020a05651c169000b0028b62e93f26si746342ljb.4.2023.01.21.09.41.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Jan 2023 09:41:27 -0800 (PST) Received-SPF: pass (google.com: domain of wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org designates 2a00:1450:4864:20::52a as permitted sender) client-ip=2a00:1450:4864:20::52a; Original-Received: by mail-ed1-x52a.google.com with SMTP id v13so10135608eda.11 for ; Sat, 21 Jan 2023 09:41:27 -0800 (PST) X-Received: by 2002:a50:99cf:0:b0:49e:f56e:7af1 with SMTP id n15-20020a5099cf000000b0049ef56e7af1mr580178edb.138.1674322886588; Sat, 21 Jan 2023 09:41:26 -0800 (PST) In-Reply-To: <87fsc4koud.fsf-9EawChwDxG8hFhg+JK9F0w@public.gmane.org> X-Original-Sender: wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@broadband-forum.org header.s=google header.b=PGMXO28t; spf=pass (google.com: domain of wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadband-forum.org X-Original-From: William Lupton Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Xref: news.gmane.io gmane.text.pandoc:32060 Archived-At: --000000000000e50e1905f2c9aca3 Content-Type: text/plain; charset="UTF-8" (Creating a new thread with cleaned-up history. Sorry for hijacking your thread ChrisD!) I've merged a small update to logging.lua (just removing the leading 'userdata: ' when reporting light userdata values). Thanks for the explanation Albert. I don't suppose that you really want to change the behaviour of pandoc.utils.type(), so I'm not really inclined to create an issue suggesting that you should do so. However (if you like) I could create an issue suggesting that it be slightly more fully documented (e.g., giving some examples of what it would return for various pandoc.xxx types). As for your other earlier suggestion (creating an issue to suggest a custom `__pairs` metamethod on PANDOC_WRITER_OPTIONS), would that fix the issue? The 0x0 values aren't associated with top-level keys of PANDOC_WRITER_OPTIONS, they're (for example) within highlight_style (see below). I can't help feeling that we should either do nothing or else do something that would work for arbitrary structures (not just for PANDOC_WRITER_OPTIONS). Given that I've worked around the problem in logging.lua I'd be quite happy to do nothing. A specific point about the items that have 0x0 values: these are all items that have no value, so is it the end of the world if they are simply omitted? Mightn't that be more whatever-the-lua-equivalent-of-pythonic-is? Yes pairs() won't visit them, but an attempt to access them will return nil as expected. WriterOptions { cite_method: "citeproc" ... highlight_style: { background-color: 0x0 line-number-background-color: 0x0 line-number-color: "#aaaaaa" text-color: 0x0 ... On Sat, 21 Jan 2023 at 13:18, Albert Krewinkel wrote: > > "'William Lupton' via pandoc-discuss" > writes: > > > pandoc.utils.type() return values seem to be a little inconsistent. > > For example, it can return: > > > > 'List' ... for pandoc.List (note: logging.lua leaves this alone) > > 'pandoc Xxx' ... for pandoc.Row etc. (note: logging.lua replaces > > the space with a dot) > > 'HsLua.JSON.array' ... presumably for arrays that have come via a > > JSON library > > Thank you for digging and asking! It's great to have more eyeballs in > this part of the code. > > A bit of background: all types have a corresponding entry in the Lua > "registry", a global table that contains all sorts of info. The Lua > manual states "you should use as key a string containing your library > name", hence the "pandoc" and "HsLua" prefixes. Additional > inconsistencies are cause by the fact that I didn't follow the Lua > manual's advice in the beginning, as name clashes with other packages > where not really a concern of mine. > > > I was toying with not indicating HsLua.JSON.array (i.e., showing it > > like any other table) but perhaps it's better just to report things > > as they are. Can any other HsLua.JSON.xxx values be returned, e.g., > > why not HsLua.JSON.object or indeed HsLua.JSON. > > {boolean,number,string,null}? > > There's a technical reason for this: we must be able to round-trip > from JSON to Lua to JSON. Both JSON arrays and objects are represented > as Lua tables, but how can we know whether an empty Lua table `{}` > represents an empty array or an empty object? We solve this by assigning > a metatable/type to array values. > > I guess we could also do this for JSON objects, but the advantage is > less clear in that case: being able to add metamethods like `insert` > makes sense for lists, but not for objects: String fields can shadow any > method, which would most likely lead to subtle bugs. E.g., > `obj:merge(obj2)` would stop working if `obj` has a key `merge`. > Adding a metatable to objects would therefore be little more than > performance degrading overhead. > > The other JSON types, boolean, numbers, and strings, map directly to the > respective Lua types of the same name, and pandoc.utils.type will report > the Lua type name in those cases. > > Anyway, please do open issues for any inconsistencies you find. We may > want to keep some of those old names to keep error messages more > readable, but consistency would be nice to have, too. > > > On Fri, 20 Jan 2023 at 16:33, William Lupton < > > wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org> wrote: > > > > Update: Until today, logging.lua assumed that pairs() would work > > on all userdata. Option 2 (my favourite) should work well if > > there are ever any other types of userdata (not sure whether > > there ever will be). > > > > On Fri, 20 Jan 2023 at 16:29, William Lupton < > > wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org> wrote: > > > > Thanks Albert. I expect I'll raise an issue. I assume > > that this is the only use of light userdata? > > > > Looking more closely (why didn't I do this before?) I see > > that tostring() returns 'userdata: 0x0' for these values, so > > I think it makes sense to report them as one of: > > Whatever tostring() returns > > As above with the leading 'userdata: ' removed > > <--- probably my favourite > > As above with '0x0' reported as 'nil' (not sure about > > this) > > > > On Fri, 20 Jan 2023 at 16:05, ChrisD < > > cd34-gg-4SSc53hpTiu9TMao6EloiEEOCMrvLtNR@public.gmane.org> wrote: > > > > On 1/20/2023 2:54 AM, 'William Lupton' via pandoc-discuss > > wrote: > > > I investigated, and parts of the writer options are > > "light userdata" (I hadn't heard of that). I've committed > > and merged a fix that will report such items as " > > ". You can now list most of the writer options > > (just a few colors show as ). > > > > Your update works well. (I didn't know about light > > userdata either.) Thanks! > On Fri, 20 Jan 2023 at 15:59, Albert Krewinkel wrote: > > "'William Lupton' via pandoc-discuss" > writes: > > > Re this: > > > >> Also, I tried to print the value of PANDOC_WRITER_OPTIONS, but > > wlupton's logging.lua errors on it (bad argument #1 to 'for iterator' > > (table expected, got light userdata)) > > > > I investigated, and parts of the writer options are "light userdata" > > (I hadn't heard of that). I've committed and merged a fix that will > > report such items as "". You can now list most of the writer > > options (just a few colors show as ). > > > > I'm not sure whether the use of light userdata is intentional here > > (this isn't a 3.0 thing; it was already the case in previous > > versions). Albert? > > Let's call it semi-intentional: what happens is that we go via JSON to > create the Lua representation of the writer options. The problem is > that, if a JSON value is `null`, we can't use `nil` in Lua because that > would make the key "disappear", i.e., it would not show up when > iterating through the resulting table with `pairs`. So, in an effort to > gain compatibility with the very popular Lua library "cjson", we > represent `null` values as C null pointers. Hence the "light userdata". > > The one solution I can think of is to set a custon `__pairs` metamethod > on PANDOC_WRITER_OPTIONS. That would allow us to set the missing values > to `nil`, while still having `pairs(PANDOC_WRITER_OPTIONS)` list all > supported keys. Please feel free to raise an issue for this on GitHub. -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAEe_xxjsmxwx4B_f1j4buVT8P%2BcdVdVw4q8dbtxiuJNoXsNweQ%40mail.gmail.com. --000000000000e50e1905f2c9aca3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Creating a new thread with cleaned-up=C2=A0history. = Sorry for hijacking your thread ChrisD!)

I'= ;ve merged a small update to logging.lua (just removing the leading 'us= erdata: ' when reporting light userdata values).

Thanks for the explanation Albert. I don't suppose that you really w= ant to change the behaviour of pandoc.utils.type(), so I'm not really i= nclined to create an issue suggesting that you should do=C2=A0so. However (= if you like) I could create an issue suggesting that it be slightly more fu= lly documented (e.g., giving some examples of what it would return for vari= ous pandoc.xxx types).

As for your other earlier s= uggestion (creating an issue to suggest a custom `__pairs` metamethod on PA= NDOC_WRITER_OPTIONS), would that fix the issue? The 0x0 values aren't a= ssociated with top-level keys of PANDOC_WRITER_OPTIONS, they're (for ex= ample) within highlight_style (see below). I can't help feeling that we= should either do nothing or else do something that would work for arbitrar= y structures (not just for PANDOC_WRITER_OPTIONS). Given that I've work= ed around the problem in logging.lua I'd be quite happy to do nothing.<= /div>

A specific point about the items that have 0x0 val= ues: these are all items that have no value, so is it the end of the world = if they are simply omitted? Mightn't that be more whatever-the-lua-equi= valent-of-pythonic-is? Yes pairs() won't visit them, but an attempt to = access them will return nil as expected.

WriterOptions {
=C2=A0 cite_method: "citeproc"=
=C2=A0 ...
=C2=A0 highlight_s= tyle: {
=C2=A0 =C2=A0 background-color: 0x0
=C2=A0 =C2=A0 line-number= -background-color: 0x0
=C2=A0 =C2=A0 line-number-color: "#aaaaaa&qu= ot;
=C2=A0 =C2=A0 text-color: 0x0
=C2=A0 =C2=A0 ...

On Sat, 21 Jan 2023 at 13:18, Al= bert Krewinkel <albert+p= andoc-9EawChwDxG8hFhg+JK9F0w@public.gmane.org> wrote:

"'William Lupton' via pandoc-discuss" <pandoc-discuss@google= groups.com> writes:

> pandoc.utils.type() return values seem to be a little inconsistent. > For example, it can return:
>
>=C2=A0 =C2=A0 =C2=A0'List' ... for pandoc.List (note: logging.l= ua leaves this alone)
>=C2=A0 =C2=A0 =C2=A0'pandoc Xxx' ... for pandoc.Row etc. (note:= logging.lua replaces
>=C2=A0 =C2=A0 =C2=A0the space with a dot)
>=C2=A0 =C2=A0 =C2=A0'HsLua.JSON.array' ... presumably for array= s that have come via a
>=C2=A0 =C2=A0 =C2=A0JSON library

Thank you for digging and asking! It's great to have more eyeballs in this part of the code.

A bit of background: all types have a corresponding entry in the Lua
"registry", a global table that contains all sorts of info. The L= ua
manual states "you should use as key a string containing your library<= br> name", hence the "pandoc" and "HsLua" prefixes. Ad= ditional
inconsistencies are cause by the fact that I didn't follow the Lua
manual's advice in the beginning, as name clashes with other packages where not really a concern of mine.

> I was toying with not indicating HsLua.JSON.array (i.e., showing it > like any other table) but perhaps it's better just to report thing= s
> as they are. Can any other HsLua.JSON.xxx values be returned, e.g., > why not HsLua.JSON.object or indeed HsLua.JSON.
> {boolean,number,string,null}?

There's a technical reason for this: we must be able to round-trip
from JSON to Lua to JSON. Both JSON arrays and objects are represented
as Lua tables, but how can we know whether an empty Lua table `{}`
represents an empty array or an empty object? We solve this by assigning a metatable/type to array values.

I guess we could also do this for JSON objects, but the advantage is
less clear in that case: being able to add metamethods like `insert`
makes sense for lists, but not for objects: String fields can shadow any method, which would most likely lead to subtle bugs. E.g.,
`obj:merge(obj2)` would stop working if `obj` has a key `merge`.
Adding a metatable to objects would therefore be little more than
performance degrading overhead.

The other JSON types, boolean, numbers, and strings, map directly to the respective Lua types of the same name, and pandoc.utils.type will report the Lua type name in those cases.

Anyway, please do open issues for any inconsistencies you find. We may
want to keep some of those old names to keep error messages more
readable, but consistency would be nice to have, too.

> On Fri, 20 Jan 2023 at 16:33, William Lupton <
> wlupt= on-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Update: Until today, logging.lua assumed that pairs= () would work
>=C2=A0 =C2=A0 =C2=A0on all userdata. Option 2 (my favourite) should wor= k well if
>=C2=A0 =C2=A0 =C2=A0there are ever any other types of userdata (not sur= e whether
>=C2=A0 =C2=A0 =C2=A0there ever will be).
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0On Fri, 20 Jan 2023 at 16:29, William Lupton < >=C2=A0 =C2=A0 =C2=A0wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org> wrote:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks Albert. I expect I'll rais= e an issue. I assume
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that=C2=A0this is the only use of lig= ht userdata?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Looking more closely (why didn't = I do this before?) I see
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that tostring() returns 'userdata= : 0x0' for these values, so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think it makes sense to report them= as one of:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Whatever tostring() ret= urns
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As above=C2=A0with=C2= =A0the leading 'userdata: ' removed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 = =C2=A0<--- probably my favourite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As above with '0x0&= #39; reported as 'nil' (not sure about
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, 20 Jan 2023 at 16:05, ChrisD = <
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cd34-gg-4SSc53hpTiu9TMao6EloiEEOCMrvLtNR@public.gmane.org> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 1/20/2023 2:54 AM, &= #39;William Lupton' via pandoc-discuss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I investigated, an= d parts of the writer options are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"light userdata&qu= ot; (I hadn't heard of that). I've committed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and merged a fix that w= ill report such items as "
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<pointer>". = You can now list most of the writer options
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(just a few colors show= as <pointer>).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Your update works well.= (I didn't know about light
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0userdata either.) Thank= s!

On = Fri, 20 Jan 2023 at 15:59, Albert Krewinkel <albert+pandoc-9EawChwDxG8hFhg+JK9F0w@public.gmane.org> wrote:

"'William Lupto= n' via pandoc-discuss" <pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> write= s:

> Re this:
>
>> Also, I tried to print the valu= e of PANDOC_WRITER_OPTIONS, but
> wlupton's logging.lua errors on= it (bad argument #1 to 'for iterator'
> (table expected, got= light userdata))
>
> I investigated, and parts of the writer o= ptions are "light userdata"
> (I hadn't heard of that).= I've committed and merged a fix that will
> report such items as= "<pointer>". You can now list most of the writer
> o= ptions (just a few colors show as <pointer>).
>
> I'm= not sure whether the use of light userdata is intentional here
> (th= is isn't a 3.0 thing; it was already the case in previous
> versi= ons). Albert?

Let's call it semi-intentional: what happens is th= at we go via JSON to
create the Lua representation of the writer options= . The problem is
that, if a JSON value is `null`, we can't use `nil`= in Lua because that
would make the key "disappear", i.e., it = would not show up when
iterating through the resulting table with `pairs= `. So, in an effort to
gain compatibility with the very popular Lua libr= ary "cjson", we
represent `null` values as C null pointers. He= nce the "light userdata".

The one solution I can think of = is to set a custon `__pairs` metamethod
on PANDOC_WRITER_OPTIONS. That w= ould allow us to set the missing values
to `nil`, while still having `pa= irs(PANDOC_WRITER_OPTIONS)` list all
supported keys. Please feel free to= raise an issue for this on GitHub.
=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pand= oc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To view this discussion on the web visit https://group= s.google.com/d/msgid/pandoc-discuss/CAEe_xxjsmxwx4B_f1j4buVT8P%2BcdVdVw4q8d= btxiuJNoXsNweQ%40mail.gmail.com.
--000000000000e50e1905f2c9aca3--