bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#42930: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load e


From: Phil Sainty
Subject: bug#42930: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load errors
Date: Thu, 20 Aug 2020 00:52:14 +1200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

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 :)

Attachment: 0001-packages-vlf-Fix-byte-compilation-and-load-errors.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]