From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: feature/package-vc has been merged Date: Tue, 08 Nov 2022 21:53:03 +0000 Message-ID: <87zgd1f70g.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <875yg6qtbl.fsf@posteo.net> <87ilk33lqk.fsf@posteo.net> <87mt9epqlk.fsf@posteo.net> <87ilk1bgvd.fsf@posteo.net> <87edupbdp0.fsf@posteo.net> <875yg1bc02.fsf@posteo.net> <878rkxgpms.fsf@posteo.net> <87sfiyk3a2.fsf_-_@posteo.net> <87mt948pmo.fsf@posteo.net> <87fsevyxnt.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5843"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Richard Stallman , emacs-devel@gnu.org To: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 08 22:53:59 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1osWXe-0001Gv-MS for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Nov 2022 22:53:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1osWWt-00023I-A9; Tue, 08 Nov 2022 16:53:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osWWr-00022w-D3 for emacs-devel@gnu.org; Tue, 08 Nov 2022 16:53:09 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osWWo-0001cD-VM for emacs-devel@gnu.org; Tue, 08 Nov 2022 16:53:09 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 22603240026 for ; Tue, 8 Nov 2022 22:53:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667944385; bh=9PvKLD87L5B+vQhcFNxhOHV1NpHSGqG9fcgjHq9rTRg=; h=From:To:Cc:Subject:Date:From; b=KiinpLo0SNyFqv7nSRPhAp9GaWER5BK+DiMKkBh4UIjI9WWYTDJVos80D9miKz9b0 0GZWxpQvymDvTCQTwt9o4iLrTrBu03FtKAv5V0wKNFHCIgWXML1A6xTQ8uU7OgWk1L I3rJIQZGfkWaghFXsM5uEkXeKhdDU/4vglXif1RNtGLbGkF59wNh1kfq+p5TuHPtda 5/CyHPDQzO+7SR87BNRzS83EMKsSEBMxGZJiqr4xvyuMnkFNIQees0IHm3xI03xIEF XgV+1C2sKdfAGZ1kKE1HwHBjmNs+2GJ+zeIBpl7iB6C6nV8LUi255TL8X/kikQ/rjY g5WMX2xKUi58g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N6MKX2HLyz6tpy; Tue, 8 Nov 2022 22:53:03 +0100 (CET) In-Reply-To: ("Rudolf =?utf-8?Q?Adamkovi=C4=8D=22'?= =?utf-8?Q?s?= message of "Tue, 08 Nov 2022 00:17:22 +0100") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299370 Archived-At: Rudolf Adamkovi=C4=8D writes: > Philip Kaludercic writes: > >> The thing is the user options aren't strictly variables. The usually >> are, but they are explicitly meant to operate on a higher abstraction >> level, sort of even in a separate name space. > > Gotcha! Worse still, any variable, user option or not can have a side effect, when `add-variable-watcher' is used. >> But of course, I understand that not everyone feels comfortable with >> this. So while I insist that package-vc-selected-packages ought to be >> a user option, I have also made `package-vc-install-selected-packages' >> autoloaded (I have yet to push all the commits) and invocable as a >> regular function > > Perfect. Win-win. Thank you so much! > > (I hope you also marked the function as interactive. When playing with > VC package, I have half of the history in M-x and the other half in M-:. > Switching between the two all the time confuses me to no end.) Yes, I've done it, but haven't pushed the changes yet. >>> I like the clear distinction between `foo' and `(foo)' in Lisp. I even >>> like the `*' in C that clearly says "a pointer". Brilliant ideas lost >>> to the history in most modern languages. But I digress! >> >> Maybe I am missing your point, but why shouldn't `foo' and (foo) be >> different? The only context where I can think of `foo' and (foo) >> being treated the same is in some APL-like language ... > > I apologize for the digression! :) > > To quickly explain, consider Swift code: > > class Things { > // stored property > var count =3D 0 // set during init > } > > and > > class Things { > // computed property > var count: Int { > // arbitrary code > } > } > > One calls `things.count' in both cases, with no parentheses, so one has > no idea whether `count' is a *stored* property (true variable) with O(1) > access or a *computed* property that runs in say in O(n). Accidentally > quadratic code in no time! Plus, one also know nothing about side > effects. > > (Further, one can also define `willSet' and `didSet' on *stored* > properties, makes things even worse.) > > In C, one sees `count' or `*count' or `count()' and everything is clear > on the first sight. Similarly, in Scheme, one sees `count' or > `(count)'. Interesting, I didn't know this. >> I see, this is an interesting approach. But just to make sure, can >> you confirm that package-vc doesn't break any of the assumptions you >> make that are necessary for your configuration to work as intended? > > Suddenly ... so many issues! :) > > First, Emacs failed with "circular loads" errors (or something like > that). I had to comment out `(package-vc-ensure-packages)' here to work > around the problem: > (defcustom package-vc-selected-packages '() > [...] > :set (lambda (sym val) > (custom-set-default sym val) > (package-vc-ensure-packages)) That is unusual, `package-vc-ensure-packages' (or as it is now called `package-vc-install-selected-packages') doesn't modify `package-vc-selected-packages' so the setter shouldn't be invoked either? > I then tried to change all packages to VC at once and got: > > user-error: Package has no VC data > > Which one, I wondered. Good point, I can add that to the error message. > Anyway, I reverted the config and decided to proceed in smaller steps. > > As a side note, while I investigated various issues, I found myself > wishing for a hyperlink to > > `package-vc-archive-spec-alist' > > from the help page for > > `package-vc-selected-packages'. > > (The help page mentions does not use a hyperlink.) These issues have already been solved. > Finally, I got to MELPA packages and got stuck altoegether. > > When I > > (1) require `package-vc', and then > (2) run `package-refresh-contents', > > I get > > Debugger entered--Lisp error: (file-error > "https://melpa.org/packages/elpa-packages.eld" "Not found") > signal(file-error ("https://melpa.org/packages/elpa-packages.eld" "Not > found")) package--with-response-buffer-1("https://melpa.org/packages/" > #f(compiled-function () #) :file > "elpa-packages.eld" :async nil :error-function #f(compiled-function () > #) :noerror nil) > package--download-one-archive(("melpa" > . "https://melpa.org/packages/") "elpa-packages.eld" nil) > (condition-case nil (package--download-one-archive archive > "elpa-packages.eld" async) ((debug error) (message "Failed to download > `%s' archive." (car archive)))) (let ((archive (car tail))) > (condition-case nil (package--download-one-archive archive > "elpa-packages.eld" async) ((debug error) (message "Failed to download > `%s' archive." (car archive)))) (setq tail (cdr tail))) (while tail > (let ((archive (car tail))) (condition-case nil > (package--download-one-archive archive "elpa-packages.eld" async) > ((debug error) (message "Failed to download `%s' archive." (car > archive)))) (setq tail (cdr tail)))) (let ((tail package-archives)) > (while tail (let ((archive (car tail))) (condition-case nil > (package--download-one-archive archive "elpa-packages.eld" async) > ((debug error) (message "Failed to download `%s' archive." (car > archive)))) (setq tail (cdr tail))))) > package-vc--download-and-read-archives(nil) > run-hook-with-args(package-vc--download-and-read-archives nil) > package-refresh-contents() > funcall-interactively(package-refresh-contents) > call-interactively(package-refresh-contents record nil) > command-execute(package-refresh-contents record) > execute-extended-command(nil "package-refresh-contents" nil) > funcall-interactively(execute-extended-command nil > "package-refresh-contents" nil) > call-interactively(execute-extended-command nil nil) > command-execute(execute-extended-command) Do you have `debug-on-error' enabled? I don't use MELPA, so this error doesn't occur in my case. I've modified `package-archives', but even so the most I get in my case is Failed to download =E2=80=98melpa=E2=80=99 archive. > Rudy > -- > "'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and > if it were so, it would be; but as it isn't, it ain't. That's logic.'" > -- Lewis Carroll, Through the Looking Glass, 1871/1872 > > Rudolf Adamkovi=C4=8D [he/him] > Studenohorsk=C3=A1 25 > 84103 Bratislava > Slovakia