From unknown Fri Jun 20 07:21:10 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#42930 <42930@debbugs.gnu.org> To: bug#42930 <42930@debbugs.gnu.org> Subject: Status: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load errors Reply-To: bug#42930 <42930@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:21:10 +0000 retitle 42930 [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load e= rrors reassign 42930 emacs submitter 42930 Phil Sainty severity 42930 normal tag 42930 fixed patch thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 19 08:52:25 2020 Received: (at submit) by debbugs.gnu.org; 19 Aug 2020 12:52:25 +0000 Received: from localhost ([127.0.0.1]:38516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8NZp-0000Hl-6p for submit@debbugs.gnu.org; Wed, 19 Aug 2020 08:52:25 -0400 Received: from lists.gnu.org ([209.51.188.17]:56702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8NZn-0000He-ID for submit@debbugs.gnu.org; Wed, 19 Aug 2020 08:52:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8NZn-0005wx-A1 for bug-gnu-emacs@gnu.org; Wed, 19 Aug 2020 08:52:23 -0400 Received: from smtp-2.orcon.net.nz ([60.234.4.43]:36477) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8NZl-0003xL-9G for bug-gnu-emacs@gnu.org; Wed, 19 Aug 2020 08:52:23 -0400 Received: from [101.53.216.96] (port=1792 helo=[192.168.20.103]) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1k8NZe-00086u-BX for bug-gnu-emacs@gnu.org; Thu, 20 Aug 2020 00:52:14 +1200 To: bug-gnu-emacs@gnu.org From: Phil Sainty Subject: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load errors Message-ID: <96c30e2f-5da4-a632-e62d-3bfe1a43f39d@orcon.net.nz> 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 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------5256AAFA08F85BA6870A5F76" Content-Language: en-GB X-GeoIP: NZ Received-SPF: pass client-ip=60.234.4.43; envelope-from=psainty@orcon.net.nz; helo=smtp-2.orcon.net.nz X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/19 08:52:16 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) This is a multi-part message in MIME format. --------------5256AAFA08F85BA6870A5F76 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 :) --------------5256AAFA08F85BA6870A5F76 Content-Type: text/x-patch; charset=UTF-8; name="0001-packages-vlf-Fix-byte-compilation-and-load-errors.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-packages-vlf-Fix-byte-compilation-and-load-errors.patch" >From 0d8e72ca0a450c5da8fe6c47b582b6ecf66eff84 Mon Sep 17 00:00:00 2001 From: Phil Sainty 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 --------------5256AAFA08F85BA6870A5F76-- From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 19 10:20:07 2020 Received: (at 42930) by debbugs.gnu.org; 19 Aug 2020 14:20:07 +0000 Received: from localhost ([127.0.0.1]:40629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8Owh-0003Sz-As for submit@debbugs.gnu.org; Wed, 19 Aug 2020 10:20:07 -0400 Received: from quimby.gnus.org ([95.216.78.240]:45912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8Owf-0003SL-3E for 42930@debbugs.gnu.org; Wed, 19 Aug 2020 10:20:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YQHGYps8UHYhS6f81mZDHNDZhlqXJv4UTanb2BAfByQ=; b=b/nWREcWTLKLybWS2uIjGuPhDV 1McltjuqFO+SlgEBYeKNPCsWL6idl/kbOAQwxn2efYK5IXGzfjZqiNAtyqbZ7pd2a+h0HBwvEKgNy YXTFwxDzFHTaFlsCG6bwhsWZkd3XLbog5fbv8XXNq8OP9Sj7uZt/SXB7UydGIAMUgTV4=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k8OwW-0005f1-Dg; Wed, 19 Aug 2020 16:19:59 +0200 From: Lars Ingebrigtsen To: Phil Sainty Subject: Re: bug#42930: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load errors References: <96c30e2f-5da4-a632-e62d-3bfe1a43f39d@orcon.net.nz> X-Now-Playing: Pieter Nooten & Michael Brook's _Sleeps With The Fishes_: "Several Times II" Date: Wed, 19 Aug 2020 16:19:55 +0200 In-Reply-To: <96c30e2f-5da4-a632-e62d-3bfe1a43f39d@orcon.net.nz> (Phil Sainty's message of "Thu, 20 Aug 2020 00:52:14 +1200") Message-ID: <87y2mazpis.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Phil Sainty 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 tha [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42930 Cc: 42930@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Phil Sainty 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 19 10:20:11 2020 Received: (at control) by debbugs.gnu.org; 19 Aug 2020 14:20:11 +0000 Received: from localhost ([127.0.0.1]:40632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8Owl-0003TF-Jy for submit@debbugs.gnu.org; Wed, 19 Aug 2020 10:20:11 -0400 Received: from quimby.gnus.org ([95.216.78.240]:45928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8Owk-0003Sr-Nr for control@debbugs.gnu.org; Wed, 19 Aug 2020 10:20:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=vwoyZ4rFUsYj3o55gVVhcK3VwsfibhTlWt5z9mUoCXc=; b=TP4RR+0SDPUg0ZmxF82dSsCx1f dSSpyfIKAxuWWOQD8fwJJ5tQfe8NN1TwU2MmSsPTLPQ09fkmWo8xqLMY/r3t2QSM/30OjzEbpxGwd msPx+i17nlRpa1aCM3JUoeM8WwFJVAgo0RJVwzd9kRQsUrmymOEMqKcN7hT4eBGhJXy8=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k8Owd-0005fB-2K for control@debbugs.gnu.org; Wed, 19 Aug 2020 16:20:05 +0200 Date: Wed, 19 Aug 2020 16:20:01 +0200 Message-Id: <87wo1uzpim.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #42930 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 42930 fixed close 42930 28.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 42930 fixed close 42930 28.1 quit From unknown Fri Jun 20 07:21:10 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 17 Sep 2020 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator