GNU bug report logs - #42930
[PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load errors

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 42930 in the body.
You can then email your comments to 42930 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: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load errors
Date: Thu, 20 Aug 2020 00:52:14 +1200

[Message part 1 (text/plain, inline)]

When `large-file-warning-threshold' is set to nil (meaning "never
request confirmation"), the definition for `vlf-tune-max' calls `max'
with nil as an argument.  This then signals "Wrong type argument:
number-or-marker-p, nil" when byte-compiling or loading any of the
libraries which (require 'vlf-tune).

On 27.1 with that var set to nil, M-x package-install RET vlf RET gives:

Compiling file /path/to/vlf-1.7.1/vlf-base.el at Thu Aug 20 00:06:31 2020
vlf-base.el:30:1:Error: Wrong type argument: number-or-marker-p, nil

Compiling file /path/to/vlf-1.7.1/vlf-ediff.el at Thu Aug 20 00:06:31 2020
vlf-ediff.el:30:1:Error: Wrong type argument: number-or-marker-p, nil

Compiling file /path/to/vlf-1.7.1/vlf-follow.el at Thu Aug 20 00:06:31 2020
vlf-follow.el:30:1:Error: Wrong type argument: number-or-marker-p, nil

Compiling file /path/to/vlf-1.7.1/vlf-occur.el at Thu Aug 20 00:06:32 2020
vlf-occur.el:30:1:Error: Wrong type argument: number-or-marker-p, nil

Compiling file /path/to/vlf-1.7.1/vlf-pkg.el at Thu Aug 20 00:06:32 2020

Compiling file /path/to/vlf-1.7.1/vlf-search.el at Thu Aug 20 00:06:32 2020
vlf-search.el:30:1:Error: Wrong type argument: number-or-marker-p, nil

Compiling file /path/to/vlf-1.7.1/vlf-setup.el at Thu Aug 20 00:06:32 2020

Compiling file /path/to/vlf-1.7.1/vlf-tune.el at Thu Aug 20 00:06:32 2020

Compiling file /path/to/vlf-1.7.1/vlf-write.el at Thu Aug 20 00:06:32 2020
vlf-write.el:30:1:Error: Wrong type argument: number-or-marker-p, nil

Compiling file /path/to/vlf-1.7.1/vlf.el at Thu Aug 20 00:06:32 2020
vlf.el:42:1:Error: Wrong type argument: number-or-marker-p, nil


I've attached a patch to make it use the *standard* value (currently
10000000) of `large-file-warning-threshold' in that scenario.  There's
probably an argument to use something bigger, given that the nil value
is really saying that the user will happily cope with much *larger*
file sizes than the standard value; but as this piece of code is only
determining a fallback value in case `vlf-tune-ram-size' failing to
produce a value[1], and the user can simply customize the option if
they're not happy with the default, I concluded it was fine.


-Phil


[1] Or if `vlf-tune-ram-size' produces a value which isn't 20 times
larger than `large-file-warning-threshold' -- that part of the logic
seems slightly iffy, but the issue is probably moot in 2020, given
that 20 x 10,000,000 is only 200M of RAM :)

[0001-packages-vlf-Fix-byte-compilation-and-load-errors.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 42930 <at> debbugs.gnu.org
Subject: Re: bug#42930: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation
 and load errors
Date: Wed, 19 Aug 2020 16:19:55 +0200

Phil Sainty <psainty <at> orcon.net.nz> writes:

> I've attached a patch to make it use the *standard* value (currently
> 10000000) of `large-file-warning-threshold' in that scenario.  There's
> probably an argument to use something bigger, given that the nil value
> is really saying that the user will happily cope with much *larger*
> file sizes than the standard value; but as this piece of code is only
> determining a fallback value in case `vlf-tune-ram-size' failing to
> produce a value[1], and the user can simply customize the option if
> they're not happy with the default, I concluded it was fine.

Yeah, sounds reasonable to me, so I've now applied your patch.  Oh,
forgot to bump the version number as usual; I'll do that now.

-- 
(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.