In case anyone here hasn't seen it, I want to share this very cool youtube series of an Australian clock maker creating a replica of the Antikythera device using only tools believed to be available to the ancient Greeks: https://www.youtube.com/watch?v=ML4tw_UzqZE&list=PLZioPDnFPN...
I want to second this, I worked as a mechanical engineer and never had accurate time estimates there either. Estimates of how long the work will take will be wrong whenever there are new problems to be solved, which is all engineering worth the name.
I spent some time helping someone get this set up for their music group, and it's really really nice just as a voice chat program. It's amazing how much of the unpleasantness of something like a Skype call goes away with really low latency
The vague impression I get is that maybe the answer is "Because Apple's software people and chip design people are in the same company, they did a better job of coordinating to make good tradeoffs in the chip and software design."
(I'm getting this from reading between lines on Twitter, so it's not exactly a high confidence guess)
I have walked out of pharmacies without buying Sudafed that I would have wanted because the "ask for a pack of Sudafed" step was too uncomfortable. Buying liquor is easier because I don't have to say words to explain what I want.
Edited to add: I'm not particularly up in arms about needing ID, and I feel like buying Sudafed got easier somehow recently, but this seemed like a place where I could help explain what sorts of things can be uncomfortable/difficult for some people.
I work on another music file management system, my personal special hell is playlist files. An m3u playlist file is just a new-line separated list of file paths, which can be relative or absolute, and potentially encoded in whatever locale is set on the users computer. Some fun issues:
* Windows and Mac filesystems are generally case-insensitive, so some users will have the file names in the playlist file in one case and the actual file names on disk in another format
* Sometimes file paths cross between two different filesystems, because one is mounted in the other with a USB drive or over CIFS or similar. Sometimes these two different filesystems have different case sensitivities
* There's no way to know how the playlist file was encoded
* HFS+ normalizes file paths to Unicode NFD, but there's no guarantee that the paths in a playlist file will be normalized. Also, sometimes users generate an m3u file on a Windows system and expect it to just work on a Mac. Also, the filesystem nesting problem with network or USB mounts can happen this way too.
Sounds a lot like my life a couple of years ago (and intermittently since). I don't get the bug reports any more because I think customer service has learned that file name problems can be fixed by renaming the files. Not fun for the user, but a sure fix.
Ya know what kind of file names work virtually everywhere? ASCII ones.
This is a mis-use of ASCII. After all, the colon, asterisk, forward slash, question mark, backward slash, and NUL characters are all in ASCII, yet they are far from things that "work virtually everywhere". And that isn't even considering the open and close square bracket and semi-colon characters which are also not anywhere near portable to the extent of "working virtually everywhere".
The kind of file names that do work "virtually everywhere" are not ASCII, but rather are those who only use characters from the POSIX Portable Filename Character Set, which at 65 characters is just over half the size of ASCII (which has 128 characters).
I understand alias'es and wrappers fine, but I like having the environment have some way to contribute. It's just my simple preference.
There's also the related #314 which makes even more sense- per project configuration. Sure would be great being able to download a project & have it already setup nicely for ripgrep! https://github.com/BurntSushi/ripgrep/issues/314
Wow, cool. Thanks burntsushi. rg is already amazing. This project really has gotten an enormous amount of love & effort from you & it really shows through & through.
Your implementation of the gitignore algorithm is crazy impressive to me.
In the spirit of learning about these things, you might want to try these: https://cryptopals.com/
In particular, problem number 17 from set 3 is an attack against CBC mode AES used with Mac-the-Encrypt. Maybe a fun exercise would be to first implement that attack against CBC mode, and then try to see if you can make it work against your CFB-HMAC protocol.
CVD in general is slow and time consuming, but because graphene is just one atom thick growing graphene specifically might not be too bad. Also the process gas/chemistry requirements are relatively very simple.
For reference, I used to see ~4 hour cycle times for growing graphene on copper sheets. I think most of that was in the heat up and cool down, maybe order of 30min actual growth time. These numbers might be off by a factor of 2-5, it's been a few years since that job, and I was a equipment design engineer not a process guy as such.
Asking honestly because I would like to know: What is wrong with writing a state machine using gotos? Assuming that one is solving a problem that definitely needs a state machine for some reason.
Many programmers treat 'goto' the same way that we treat radioactive waste, but they don't know why. Perhaps it is a holdover from courses with teachers who automatically graded 'fail' on programs that used a goto. Perhaps the programmers have only heard that gotos were bad.
Sometimes 'goto' is the correct answer. For state machines it can be an pretty efficient technique. For "ordinary" code it is sometimes the best way out of a situation (e.g., busting out of a deeply nested set of loops).
The "Goto considered harmful" movement came out of the 1970s, when GOTO was used all the time and the normal state for a big project was abject spaghetti. I think we can all agree that was a very bad thing. But the utter avoidance of goto is an overreaction that seems to be based on unreasoning fear, or toxic peer pressure.
so, goto is efficient at escaping inefficiently structured code? That doesn't make it really efficient. I mean there's a reasonable rule of thumb: don't indent the code too deep. Because what you are talking about is one kind of spaghetti, the kind cut into digestable chunks. The interleaving of active and inactive blocks leads to unreadable code sooner or later.
This is lazy thinking, the gotos described in that essay can jump anywhere in the program while modern gotos are limited to the function scope and have various warnings about initialization order and whatnot.
All the arguments it makes no longer apply but people still quote the snappy headline.
That essay does make an excellent argument against programming with many tiny functions though, as those do cause the execution cursor to jump all over the source code document.
It seems to me that a substantial fraction of the people who quote that paper, assuming they have even read it, have failed to think critically about it.
