It's going to be a month since GitHub incident, a number of repos still do not show all pull requests with a few repos still missing dozens and the UI showing different counts in different places. GitHub support now autoclose report in minutes and does not fix it.
I love how you are not even realising that behind the oatmilk ticket is written "last oatmilk", the behind the half and half one is written "only 3 half and half" behind the foo ticket "foo down to f(frequency of foo use)", and the person now now only need to go through the tickets at the end of the week (or if more than N tickets).
I will let you ponder if you need to reticket all, or just the reordered product, wether a stack can have multiple ticket (a white one say 5 from the last and one red one two from the back know wether you need an urgent order) etc...
And whether or miracle, if you don't receive any ticket a week that you don't need to reorder !
It's amazing how if that was expressed in term of resource allocation, reference counting, tagged pointers, scaling heuristic, garbage collect... that would click in people's mind, but many are incapable at abstracting because they feel they are beyond this.
Well, it's just bad journalism, cause what they are referring to is a quantum inertial navigation system, not a clock – it's just thousands of time more precise. The plan happen to also have an atomic clock (which is used to properly integrate inertia through time), without having to rely on external GPS (which is a clock).
I think that's fairly normal, having alternative frontends can only be beneficial to the community. I know it also look like there is a single Jupyter team, but the project is quite large, there are a lot of constraints and disagreements internally and there is not way to accomodate all users in the default jupyter install. Alternative are always welcome ; at least if they don't fragment the ecosystem by being not backward compatible with the default.
Also to be fair I'm also one of the Jupyter dev that agree with many points of OP, and would have pulled it into a different direction; but regardldess I will still support people wanting to go in a different direction than mine.
IPython maintainer and Jupyter dev (even if I barely touch frontend stuff these days). Happy to see diversity, keep up the good work and happy new year. Feel free to open issues upstream if you find lack of documentation or issue with protocol. You can also try to reach to jupyter media strategy team, maybe they'll be open to have a blog post about this on blog.jupyter.org
In this repo: furry. A coworker of mine reported another repository of this author (or another contributor?) for according to my coworker containing CP. Read issue 474 as well.
Project that contains (contained?) porn in the source tree https://github.com/Alex313031/thorium/pull/469 and I've heard the maintainer also promotes some quite reprehensible stuff. So I can't support it.
While I agree this is marketing stunts in general, sometime the difference between 99.5 and 99.6 reemission is 0.5 vs 0.4 percent absorption. so one way of seeing it the second one is 20% better than the first one at not heating the building.
This is often the case for percentages "close" to 100%, e.g: with LED efficiency, for powerful LEDs the problem is not the quantity of light emitted but dissipating the heat that may need active cooling, so what may look like a few percent improvement is luminosity may actually be a much stronger decrease of the size of active cooling,
Or semi-transparent mirrors in physics, where you really make a difference between 99.95 and 99.96% reflectance, because what you really look at the transmitance.
Hum, that is interesting. I'm more thinking that in a perfect world the pristine-tar delta file should be empty. (Assuming I understand what pristine-tar is doing correctly).
For example I tend to use SOURCE_DATE_EPOCH to be the timestamp of the commit to make sure that anything that embed time is reproducible without extra instruction/manual process specific file.
Thanks for advice, and I assume you are the one who commented on the upstream issue. This show it is not trivial, and it would be nice to be done automatically by default.
As a curiosity, what would it entail to make the two tgz byte-for-byte identical ?
There was/is some discussion in setuptools about how to normalize the tarball (https://github.com/pypa/setuptools/issues/2133#issuecomment-...) coudl something similar be applied to Building Python itself ?