IRC channel logs


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`.
<PurpleSym>`booktabs` is probably the texlive package.
<PurpleSym>And even `notepad.exe` 🤣
<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 }#
<civodul>the DESCRIPTION format is lax?
<PurpleSym>Ah, I see.
<rekado>well, the SystemRequirements field is pretty much a free-form field
<rekado>here it looks like this: SystemRequirements: 'Monolix' (<>)
<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.
<PurpleSym>This is my import script right now:
<civodul>fun :-)
<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>17021 top level packages
<drakonis>this number includes variations of some packages but not the sets
<drakonis>linux packages, for example have more than 50 variations
<drakonis>there's also ~40 adoptopenjdk packages
<drakonis>the numbers are so vastly inflated
<civodul>i have a problem: take
<civodul>i made two nginx changes: one to remove ETag, another one to add Cache-Control ->
<civodul>but if you run "wget --debug -O/dev/null" several times in a row, you won't always get the same response
<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
<civodul>how's that possible?
<rekado>we can make nginx print some more info to the debug logs, right? Make it show which location rule was processed.
<civodul>ah, can we?
*civodul checks
<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>looks like it's deterministic now
<civodul>(i wonder how the two nginx managed to work together, go figure)
<rekado>huh, weird.
<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>right, nginx is too smart
<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