339 karma · joined July 4, 2012
Are you using it from the command line? I feel that helps a lot. Get a good log alias[1] and get hacking. I almost exclusively use the official CLI, with the exception of git-gui for committing and rolling back patches (lines / hunks). (I find it's easier than `add -p` and that CTRL+J is a good time saver.)
1: As an example, https://github.com/aib/dotfiles/blob/master/.gitconfig#L29
"The O_DIRECT flag on its own makes an effort to transfer data synchronously, but does not give the guarantees of the O_SYNC flag that data and necessary metadata are transferred."
While I don't think this is relevant to block devices, I see no harm in including the flag in my alias, either.
Edit: Looks like O_SYNC (oflag=sync) is needed, too. Should update my 'sddd' alias.
I could even imagine an "assigned capability strings" database and x- prefixes and all, but it's probably an old fool's dream in these fast-m— thing-breaking times.
I guess it's implicit in that f-strings, as arguments, will be evaluated before the logging function can even run whereas `debug("...", heavy_obj)` will avoid a potentially expensive `str(heavy_obj)` (or whatever the string conversion warrants.)
As for raiseExceptions, I'm not sure it's for optimization. It looks like an old sanity check for bad logging configurations.
Exactly! And remember, it's not always getting a grip on the language. Sometimes it's getting a grip on the problem or one of the possible solutions.
This is a great idea! It made me realize why I still choose Python for prototyping. (I had been wondering...)
I absolutely love Rust's guarantees and prefer its memory management over GC. But nothing beats no memory management! Make everything Arc, make everything static---I don't care! My program will only live long enough to print "OK" and reach the next TODO, anyway.
> If your program confuses the borrow checker, that means that the compiler can't figure out when it should close that TCP connection on your behalf.
That's quite okay. "Process end" is as good a time as any, in this case.
> This isn't the sort of thing you can just turn off in debug mode, because programs should act the same in debug and release modes.
I don't know why programs with and without overflow and bounds checking are the "same" while programs that close unused sockets at different times are not, but it's okay---we don't have to call it "debug" mode. "Development" or "prototyping" mode both sound fine to me.
> There are ways around this - you can use types like Box, String, Rc, Cell, etc. And then just .clone() all over the place. But your code will run slowly. And thats still way more annoying to use compared to other languages. I don't know any other language which makes you write "Box" to put an object on the heap.
I think this is precisely the point. In other languages we can just create objects without worrying about where they should be stored. This is good because most of the objects -w-e- some people create don't get stored anywhere, anyway. They don't make it to the first release.
--
And yes, I realize I'm describing what is, from some angles, a completely different language. But I think one of the original discussion points is "why Rust-like languages keep popping up"? This is my take.
I didn't know where to squeeze this in, but the biggest annoyance in my (quite limited) time with Rust was: refactoring functions. I like breaking up functions into smaller chunks: `do_xy() { ... do_x(); ... do_y(); }` especially where a block of code could really benefit from being under its own name. Developing in Rust, I often found myself looking up internal types for the parameters/return type, and sometimes fighting the borrow checker. (I'm not sure type inference would be a good solution to the first, and I believe the second is mostly due to lexical lifetimes?)
How is the proof different than a signed message saying "This person has found the treasure"? With the private key derived from the coordinates?
Anyway, I'm off to read more about ZK proofs in hopes of making the above sound silly to me.
This reads like an article from 10+ years ago, even the part where Apple objects.
1: See https://en.wikipedia.org/wiki/Common_external_power_supply
Sometimes I tell onlookers that it's an ISO standard.
Another angle to this is that had Slack not been a proprietary platform, I would've taken time to find or help develop a sane client that is -e-a-s-y- possible to fix.
I think they were talking about ARM.
How are we going to prevent every single useful thing from coming up with its own crappy, poorly-maintained application? Because obviously having open standards is not enough.
So far the solution we've come up with seems to be "wait until one or a few companies dominate the market, come up with their own solution, and hope it's an open one and/or others adopt it."
This particular app might not be crappy, but I think my question still stands.
> It's my favourite feature of Python
It's like the speed bump: It's for people who can't follow simple rules. It inconveniences you, but is rationalized with that it ultimately makes the world a little safer for everyone, including you.
Me, I unindent temporary code like debug-print statements and literals overriding actual data. This makes it impossible to commit by accident.
But my argument against whitespace sensitivity would be that bad and unreadable code is bad and unreadable regardless of its whitespace. In fact, force-formatting it just hides the evidence.
1: https://pandoc.org/MANUAL.html
2: https://www.aib42.net/articles source at https://github.com/aib/www.aib42.net/tree/master/articles
I would therefore like to add my personal savior: Hamstring stretches.
Changing your lifestyle (not necessarily drastically) and excercising/stretching in general is the solution in most cases, yes, but for me the single greatest contributor was the hamstring stretch. Lie flat on your back, keep your legs straight and raise one until you feel its back sides burn. Strain it a little; using a towel, rope, bedsheet or spare pair of pants to pull on your heel if necessary. IANAD, but I hear it's pretty hard to injure your spine this way.
I did, but I was so distracted by the vast amount of whitespace (and 3x normal the amount of scrolling required) that I don't remember anything.