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

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

[Phil Sainty]

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]

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
\f
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
\f
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
\f
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
\f
Compiling file /path/to/vlf-1.7.1/vlf-pkg.el at Thu Aug 20 00:06:32 2020
\f
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
\f
Compiling file /path/to/vlf-1.7.1/vlf-setup.el at Thu Aug 20 00:06:32 2020
\f
Compiling file /path/to/vlf-1.7.1/vlf-tune.el at Thu Aug 20 00:06:32 2020
\f
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
\f
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 #2: 0001-packages-vlf-Fix-byte-compilation-and-load-errors.patch --]
[-- Type: text/x-patch, Size: 1190 bytes --]

From 0d8e72ca0a450c5da8fe6c47b582b6ecf66eff84 Mon Sep 17 00:00:00 2001
From: Phil Sainty <psainty@orcon.net.nz>
Date: Wed, 19 Aug 2020 23:55:51 +1200
Subject: [PATCH] packages/vlf: Fix byte-compilation and load errors

* packages/vlf/vlf-tune.el (vlf-tune-max): Handle a nil value of
'large-file-warning-threshold'.
---
 packages/vlf/vlf-tune.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/packages/vlf/vlf-tune.el b/packages/vlf/vlf-tune.el
index 566f2d6..df92551 100644
--- a/packages/vlf/vlf-tune.el
+++ b/packages/vlf/vlf-tune.el
@@ -60,7 +60,9 @@ but don't change batch size.  If t, measure and change."
                                (if ram-size
                                    (/ ram-size 20)
                                  0))
-                             large-file-warning-threshold)
+                             (or large-file-warning-threshold
+                                 (eval (car (get 'large-file-warning-threshold
+                                                 'standard-value)))))
   "Maximum batch size in bytes when auto tuning.
 Avoid increasing this after opening file with VLF."
   :group 'vlf :type 'integer)
-- 
2.8.3

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

[Lars Ingebrigtsen]

Phil Sainty <psainty@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