GNU bug report logs - #49660
28.0.50; json-available-p should exist

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49660 in the body.
You can then email your comments to 49660 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; json-available-p should exist
Date: Tue, 20 Jul 2021 14:53:00 +0200

All other libraries like this have an -available-p function, but not
json.c.

But json.c is slightly unusual in that it's not compiled at all if
jansson isn't available, so the function will have to go somewhere else,
which is rather, er, inconvenient.

Anybody have an idea how to solve that problem?


In GNU Emacs 28.0.50 (build 93, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-07-19 built on elva
Repository revision: b0c73439932eefb8302ec10c61d95ffcf2ef39be
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #8 received at 49660 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 49660 <at> debbugs.gnu.org
Subject: Re: bug#49660: 28.0.50; json-available-p should exist
Date: Tue, 20 Jul 2021 16:04:25 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Tue, 20 Jul 2021 14:53:00 +0200
> 
> 
> All other libraries like this have an -available-p function, but not
> json.c.
> 
> But json.c is slightly unusual in that it's not compiled at all if
> jansson isn't available, so the function will have to go somewhere else,
> which is rather, er, inconvenient.
> 
> Anybody have an idea how to solve that problem?

Compile json.c always, but have a HAVE_LIBJANSSON preprocessor symbol
that would effectively ifdef away all of json.c except that single
function (and syms_of_json).

Message #11 received at 49660 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 49660 <at> debbugs.gnu.org
Subject: Re: bug#49660: 28.0.50; json-available-p should exist
Date: Tue, 20 Jul 2021 15:43:42 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Compile json.c always, but have a HAVE_LIBJANSSON preprocessor symbol
> that would effectively ifdef away all of json.c except that single
> function (and syms_of_json).

Yeah, I guess there's really no other cleanish way to do this?  And it's
the pattern we follow in all the other library-specific src/*.c files, I
think...

So unless somebody protests (or beats me to it), I'll do this in a few
days.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #14 received at 49660 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 49660 <at> debbugs.gnu.org
Subject: Re: bug#49660: 28.0.50; json-available-p should exist
Date: Tue, 20 Jul 2021 16:47:13 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Yeah, I guess there's really no other cleanish way to do this? 

Oh, I thought of a simple hack: We could define json-available-p in
json.c, but we could also have (say) loadup.el check whether it's
defined, and if not, it can define a nil-returning stub?  That'll mean a
whole lot less #ifdef-ing in json.c.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 49660 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 49660 <at> debbugs.gnu.org
Subject: Re: bug#49660: 28.0.50; json-available-p should exist
Date: Tue, 20 Jul 2021 18:45:22 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 49660 <at> debbugs.gnu.org
> Date: Tue, 20 Jul 2021 16:47:13 +0200
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > Yeah, I guess there's really no other cleanish way to do this? 
> 
> Oh, I thought of a simple hack: We could define json-available-p in
> json.c, but we could also have (say) loadup.el check whether it's
> defined, and if not, it can define a nil-returning stub?  That'll mean a
> whole lot less #ifdef-ing in json.c.

If you are ready to define json-available-p somewhere other than
json.c, then you could simply do that in subr.el or somesuch.  It
would be cleaner than defining stubs in loadup.el.

Message #20 received at 49660 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 49660 <at> debbugs.gnu.org
Subject: Re: bug#49660: 28.0.50; json-available-p should exist
Date: Tue, 20 Jul 2021 17:50:17 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> If you are ready to define json-available-p somewhere other than
> json.c, then you could simply do that in subr.el or somesuch.  It
> would be cleaner than defining stubs in loadup.el.

The meats of json-available-p have to be in json.c, though?  (It has to
call init_json_functions (on Windows) to see whether we have the DLL or
not.)

We could have a json--available-p in json.c that does that, but it
doesn't seem less hackey...  but I guess it doesn't really matter
much -- neither solution is super clean.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #23 received at 49660 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 49660 <at> debbugs.gnu.org
Subject: Re: bug#49660: 28.0.50; json-available-p should exist
Date: Tue, 20 Jul 2021 19:53:55 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 49660 <at> debbugs.gnu.org
> Date: Tue, 20 Jul 2021 17:50:17 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If you are ready to define json-available-p somewhere other than
> > json.c, then you could simply do that in subr.el or somesuch.  It
> > would be cleaner than defining stubs in loadup.el.
> 
> The meats of json-available-p have to be in json.c, though?

No, it doesn't have to.  You could have json-available-p that simply
tested one of json.c primitives to be fboundp, and if so, tried to
invoke one of them on a trivial input to see if it signals an error.

Alternatively, we could do this like decompress.c does: it would
require the test for availability to be slightly more complex:

  (and (fboundp 'json-available-p)
       (json-available-p))

Would that be good enough?

Message #26 received at 49660 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 49660 <at> debbugs.gnu.org
Subject: Re: bug#49660: 28.0.50; json-available-p should exist
Date: Wed, 21 Jul 2021 12:50:55 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> No, it doesn't have to.  You could have json-available-p that simply
> tested one of json.c primitives to be fboundp, and if so, tried to
> invoke one of them on a trivial input to see if it signals an error.

That's true -- especially since they now signal a distinct error when
the library isn't available.  Pushed to Emacs 28 now.

> Alternatively, we could do this like decompress.c does: it would
> require the test for availability to be slightly more complex:
>
>   (and (fboundp 'json-available-p)
>        (json-available-p))
>
> Would that be good enough?

No, I think the -available-p predicates should always be defined.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.