IRC channel logs
2022-09-30.log
back to list of logs
<rekado>us Emacs folks should not be complacent. VScode does a lot of things right. The LSP stuff comes from there and Emacs is catching up slowly. <PurpleSym>rekado: I imported the entire CRAN now (just 11GB). The cran importer generates a few weird package names like this for Rsmlx: `(inputs (list #{'monolix'}#))`. <PurpleSym>Then there’s indeed dependencies on Bioconductor packages. Not sure if that’s valid or not. I mean: `install.package()` would probably fail? <PurpleSym>Then there’s generic stuff like `c++` and `c++17`, `windows`, `posix.1-2001`. <rekado>I have a list of invalid package names in the importer, which includes c++11, c++14, windows, etc <rekado>should probably add c++ and c++17 and posix.1-2001 there <rekado>the weird-looking inputs would result from improperly quoted dependencies in the DESCRIPTION file <rekado>we turn those into symbols, so when “'” remains in the string we’ll end up with complicated symbols wrapped in #{ and }# <rekado>well, the SystemRequirements field is pretty much a free-form field <rekado>I guess we should be happy that the importer didn’t add the URL as a package name… <rekado>PurpleSym: I made a few minor changes to the importer yesterday to improve license handling <rekado>without these changes you’ll probably end up with lots of (license #f) fields. <rekado>I’d like the importer to get rid of all that quoting and produce texinfo syntax where possible <rekado>SystemRequirements only rarely maps to a usable list of inputs. I kept it because sometimes it contains useful information. <PurpleSym>Nice. I’m counting 1640 packages with license #f right now. <civodul>i think the Nix folks have been doing just that BTW: mass imports of various repos <rekado>yes, that’s what I’ve been telling people on HN who said that Nix has so many more packages — it’s easy if you have all CRAN packages without any quality control ¯\_(ツ)_/¯ <PurpleSym>Soon™ we can tell them “there’s a channel for that” 🙂 <drakonis>i wonder how many top level packages nix has <drakonis>this number includes variations of some packages but not the sets <drakonis>linux packages, for example have more than 50 variations <civodul>sometimes you get one with ETag and without Cache-Control, sometimes it's the opposite <civodul>as if nginx picked location rules in a non-deterministic fashion <rekado>we can make nginx print some more info to the debug logs, right? Make it show which location rule was processed. <rekado>I’ve only ever done this for rewrite rules <rekado>by adding “rewrite_log on;” and then overwrite “error_log” to use the “debug” log level. <civodul>turns out there were two nginx master processes after i had done "herd restart nginx" <civodul>(i wonder how the two nginx managed to work together, go figure) <rekado>when we restart nginx do we use the nginx process replacement feature? <rekado>IIRC nginx minimized downtime by replacing its worker processes one by one, so during restart there is a period where you’ve got both old and new processes running at the same time. <civodul>so when "herd restart nginx" terminates, there are still dangling processes <civodul>we can't really take advantage of its zero-downtime restart feature i think, because we need to give it a different configuration file <civodul>whereas the zero-downtime thing expects the config file to remain the same (i think) <rekado>civodul: I wonder if it wants the config file *contents* to be the same or just the file location. <civodul>rekado: the location, because you can only communicate with it through signals <civodul>so if you sed SIGHUP (IIRC), it tells it to reload the config file <civodul>which assumes the config file is at the same place as before <rekado>I suppose we could arrange for the config file to be placed in a well-known location 