I’ve also read that a first version of the file came from a Common Lisp to C++ code generation step: <https://news.ycombinator.com/item?id=23295041>
498 karma · joined August 5, 2018
I’ve also read that a first version of the file came from a Common Lisp to C++ code generation step: <https://news.ycombinator.com/item?id=23295041>
I’ve always used Ctrl+U, it’s an Emacs shortcut, so it works in many shells and other prompts (especially since readline supports it) by default.
(For example Ctrl+Opt+- doesn’t seem to work in the Python REPL whereas Ctrl+U does.)
Also, Bonjour originated at Apple and it is cross-platform, although Avahi probably is more popular
CUPS is associated with Apple as well, but it seems that it also did not originate there
You need to merge the relevant ignore files to create one specific for you, so if you use VSCode on macOS VisualStudioCode.gitignore (e.g., .vscode) + macOS.gitignore (e.g., .DS_Store). There are files for other OSs and editors as well. Technically their README says that the Global folder is intended for user-specific ignore files. But you can still use them for the repo .gitignore.
There is also this API which you can curl: https://gitignore.io/api/macos,vscode
Some of the templates seem to be identical, but I think they are not in sync.
Location: Germany (UTC +1/+2), EU citizen
Remote: preferred
Willing to relocate: no
Technologies: C# and previously C++ and Java, prefer functional style and privately dabble with F# and Haskell. I know SQL, Azure, Docker, high performance computing (Monte Carlo simulations), see also CV
CV: https://stash.ldr.name/wwtbh/rcv-202609-vfay7k0zano.pdf
Email: see CV
I work in mathematical finance so a lot of domain knowledge in that area (derivatives, pricing, probability theory).I am looking for work in other domains as well.
Happy to provide you with a full CV personally.
We also do not create a CVE for curl because you can use it to download the wrong bash script. If this was an alert for suspicious usages of pip instead of pip itself, I’d be less critical of it.
E: and if you decide not to use pip I don’t think there’s an official way to remove ensurepip, I typically rm -rf inside of site-packages, it works but doesn’t feel correct
I hope your team was OK with you uninstalling the VMware package manually (this is actually not a bad outcome if you don’t use that package)
There are also ridiculous CVEs like CVE-2018-20225 for pip, which will not get fixed as that behaviour is by design (but here as well it might be a good idea to strip pip if it’s not used)
> It turns out that only 9 of the first 275 checks that I've sent out since the beginning of 2006 have actually been cashed. The others have apparently been cached. So this change in policy will probably not affect too many people. On the other hand, I don't like to renege on promises, so I shall do my best to find a suitable way to send money to anyone who really prefers legal tender.
I personally sort by ‘date modified (newest first)’ on StackExchange sites.
Use `env:` instead and just work with environment variables in your shell script.
Yes, you still need to vet your script. Quoting is a common source of problems. Use shellcheck. Do not call eval/source/python/perl/whatever with untrusted input.
But you removed one layer of problems already by not pasting a value into your shell script code directly.
Use this instead of x87’s FDIV
But they have regular installers, they are called .pkg and look like a wizard. Programs distributed as a single .app don’t really need them though.
The old Unicode rules for ZWNBSP are also quite tricky: you are not supposed to ignore the first ZWNBSP if you already know the encoding. Which means to express an initial actual ZWNBSP you need to write two of them if the encoding is unknown to the receiver and only one of them if known.
> Where the character set information is explicitly marked, such as in UTF-16BE or UTF-16LE, then all U+FEFF characters, even at the very beginning of the text, are to be interpreted as zero width no-break spaces. Similarly, where Unicode text has known byte order, initial U+FEFF characters are also not required and are to be interpreted as zero width no-break spaces. For example, for strings in an API, the memory architecture of the processor provides the explicit byte order. For databases and similar structures, it is much more efficient and robust to use a uniform byte order for the same field (if not the entire database), thereby avoiding use of the byte order mark. Systems that use the byte order mark must recognize that an initial U+FEFF signals the byte order; it is not part of the textual content. It should be removed before processing, because otherwise it may be mistaken for a legitimate zero width no-break space. To represent an initial U+FEFF ZERO WIDTH NO-BREAK SPACE in a UTF-16 file, use U+FEFF twice in a row. The first one is a byte order mark; the second one is the initial zero width no-break space.
— Unicode 3.0 Standard, p. 325 <https://www.unicode.org/versions/Unicode3.0.0/ch13.pdf>
(With modern Unicode you can write WJ or ZWNBSP,WJ and there is no problem)
Correct. That’s using the wrong base. Decimal floating point doesn’t have that problem.
It also does not collapse lines when there’s a trailing comma.
Your output seems to be from black. IMO it’s insane to collapse lines when there are line comments.
$ uvx ruff format --diff formatting.py
--- formatting.py
+++ formatting.py
@@ -1,8 +1,4 @@
-no_comma = {
- "x": 3,
- "y": 42,
- "z": 2
-}
+no_comma = {"x": 3, "y": 42, "z": 2}
with_comma = {
"x": 3,
@@ -12,6 +8,6 @@
comment = {
"x": 3,
- "y": 42, # Answer to the Ultimate Question!
- "z": 2
+ "y": 42, # Answer to the Ultimate Question!
+ "z": 2,
}
1 file would be reformatted
(I intentionally switched to double quotes since that really is a stylistic choice in Python, you can escape in both, and if you use double quotes inside of single quotes ruff leaves it as-is)