204 karma · joined August 10, 2018
With DC it's harder because you don't have the time changing nature necessary for the magnetic field so you have to turn the DC on and off which requires a switch. Nowadays we have very fast switches (transistors) that allow us to tune a circuit to the power required and temporary energy storage (capacitors and inductors) available. Ignoring (or shielding) the RF interference that's created with fast switching we have systems that can efficiently convert between one DC voltage and another.
I'm not so sure we'll have DC to the home for supply, a zero-crossing is helpful to keep circuit breakers small and reduce damage in brief, accidental contact (eg broken insulation on a lamp etc).
If you're doing more than the once a year small project you should have fume extraction, occupational (or hobby-based) asthma sucks. As does metal flu (zinc for welding and tin for soldering although I expect that's rarer).
https://www.smithsonianmag.com/smart-news/how-mouse-utopias-...
https://www.lse.ac.uk/Economic-History/Assets/Documents/Rese...
Glad to help, it was similar for me with a lot of effort to synthesize best practices and really appreciate all the concurrent options (asyncio, threads, MP) for where they each are valuable.
MP is good when the GIL would hamper your thread concurrency, ie your problem is likely CPU bound rather than IO/network bound (where Cython is good about releasing the GIL).
Cost is that there's process overhead of each new instance of Python running the worker code and pickling any required data to/from the worker across a process boundary (rather than between threads). Benefit is mostly the last answer: can saturate all available CPUs.
Few options but generally something like `concurrent.future`'s `.map` will keep tasks with order while a `.submit` and then checking with `.as_completed` will be tasks out of order (but if you return an ID of what you were working on you could reorder after and that may be worthwhile if the workloads are highly variable).
Exceptions:
Capture all in your worker and make available to the main via event or queue and check that signal periodically in your main and take action as needed.
For the other (Ctrl+C in your main) have your workers periodically check a signal from main as often as needed for the responsiveness desired and have the worker cleanup/quit on Interrupt signals.
Data transmission feels too problem-dependent to give a single answer to but if you're processing say, files, don't read and pass the files bytes to a worker, pass the file's location and let the worker read the file and return/write results.
None of those require the paper you're citing to be free from fraud: seminal works with fraudulent or inaccurate results may still have preparation methods that are applicable to novel, non-fraudulent, experimental techniques and equations are rarely at issue with data manipulation or other fraud.
There's still space to be aware of retracted papers in citations as building directly on those results and managing to show an improvement on doctored data would be suspicious but I'm pretty sure that is the minority of citations in many fields.
>[Non-programmer programmers becoming/being SMEs] is great for a while; finally someone can fix all the annoying known issues in that space that have been lingering for a while.
Followed a whole sentence later with:
>If something is only getting done because someone that "isn’t a dev resource” wants to work on it, then that’s a sign that it shouldn’t be getting done.
Yes it's qualified that it's "a sign" but if you have annoying known issues that are customer facing (even if only internal customers) sitting open in perpetuity you're probably under resourcing those areas. If you're doing that it's likely that those areas could disappear and the company would be better off or should be charged at a higher rate to external customers so they are properly maintained.
As a whole having the codebase be accessible is just open source writ small: a small number of people will be interested enough to take part and they'll often not be fully aware of the code culture when they submit a PR leading to more work for the maintainer. But they were also interested or annoyed enough to clear the hurdle of submitting one and maybe that's a sign something should be getting done in that area.
In both cases though the presenting personality is key as they have interesting knowledge that they share in an engaging way; it might be childish but their excitement is infectious.
[1]: https://tinyapps.org/blog/202207100700_thunderbird-mbox-to-m...
Also those were Humvees taken from Iraqi personnel.
If I got the 'polished' version as part of the normal update cycle I'd be upset that my tight, space-efficient and incredibly responsive productivity app had decided to use a design language that reduces information displayed. The point of email is to communicate information and I now have to interact with the UI more than I did before to get the same amount of information.
The launched version hits the density that Thunderbird has been for about a decade and is what I'd prefer (ie the compact mode might be better for those being upgraded).
Based on the YT comments it's been done at shadertoy too: https://www.shadertoy.com/view/XdsGWH
[1]: http://pouet.net/prod.php?which=4662 [2]: https://youtu.be/_zSjpIyMt0k
1: https://lastjourney.exeter.ac.uk/last-journey-wallpapers/ 2: https://www.researchgate.net/profile/Michael-Ziegler-6/publi... 3: https://issuu.com/universityofexeter/docs/the_painted_forest...
https://practicaltypography.com/widow-and-orphan-control.htm...
If you're bandwidth starved (ie ISDN or worse) then it's also a nice speedup.