Skip to content

Latest commit

 

History

History
475 lines (357 loc) · 25.7 KB

2021-03-13.md

File metadata and controls

475 lines (357 loc) · 25.7 KB

< 2021-03-13 >

2,147,164 events, 1,184,889 push events, 1,723,975 commit messages, 109,867,678 characters

Saturday 2021-03-13 02:22:29 by Joe Hosten

wanna be fucking coder bad kid cant code what a fucking melon smackhead bitch fuckery of a coder what a mess you cant code for shite imagine doxxing get demot pog


Saturday 2021-03-13 02:50:46 by Jean-Paul R. Soucy

New data: 2021-03-12: See data notes.

Revise historical data: cases (BC, MB, ON, QC, SK).

AB case numbers for today do not match the official provincial total. The provincial total was reported to be 425 but the sum of the health region totals was 427. We opted to match the cumulative health region totals.

Note regarding deaths added in QC today: “9 new deaths, but the total of deaths amounts to 10,526, due to the withdrawal of 1 death not attributable to COVID-19: 3 deaths in the last 24 hours, 5 deaths between March 5 and March 10, 1 death before March 5.” We report deaths such that our cumulative regional totals match today’s values. This sometimes results in extra deaths with today’s date when older deaths are removed.

Recent changes:

2021-01-27: Due to the limit on file sizes in GitHub, we implemented some changes to the datasets today, mostly impacting individual-level data (cases and mortality). Changes below:

  1. Individual-level data (cases.csv and mortality.csv) have been moved to a new directory in the root directory entitled “individual_level”. These files have been split by calendar year and named as follows: cases_2020.csv, cases_2021.csv, mortality_2020.csv, mortality_2021.csv. The directories “other/cases_extra” and “other/mortality_extra” have been moved into the “individual_level” directory.
  2. Redundant datasets have been removed from the root directory. These files include: recovered_cumulative.csv, testing_cumulative.csv, vaccine_administration_cumulative.csv, vaccine_distribution_cumulative.csv, vaccine_completion_cumulative.csv. All of these datasets are currently available as time series in the directory “timeseries_prov”.
  3. The file codebook.csv has been moved to the directory “other”.

We appreciate your patience and hope these changes cause minimal disruption. We do not anticipate making any other breaking changes to the datasets in the near future. If you have any further questions, please open an issue on GitHub or reach out to us by email at ccodwg [at] gmail [dot] com. Thank you for using the COVID-19 Canada Open Data Working Group datasets.

  • 2021-01-24: The columns "additional_info" and "additional_source" in cases.csv and mortality.csv have been abbreviated similar to "case_source" and "death_source". See note in README.md from 2021-11-27 and 2021-01-08.

Vaccine datasets:

  • 2021-01-19: Fully vaccinated data have been added (vaccine_completion_cumulative.csv, timeseries_prov/vaccine_completion_timeseries_prov.csv, timeseries_canada/vaccine_completion_timeseries_canada.csv). Note that this value is not currently reported by all provinces (some provinces have all 0s).
  • 2021-01-11: Our Ontario vaccine dataset has changed. Previously, we used two datasets: the MoH Daily Situation Report (https://www.oha.com/news/updates-on-the-novel-coronavirus), which is released weekdays in the evenings, and the “COVID-19 Vaccine Data in Ontario” dataset (https://data.ontario.ca/dataset/covid-19-vaccine-data-in-ontario), which is released every day in the mornings. Because the Daily Situation Report is released later in the day, it has more up-to-date numbers. However, since it is not available on weekends, this leads to an artificial “dip” in numbers on Saturday and “jump” on Monday due to the transition between data sources. We will now exclusively use the daily “COVID-19 Vaccine Data in Ontario” dataset. Although our numbers will be slightly less timely, the daily values will be consistent. We have replaced our historical dataset with “COVID-19 Vaccine Data in Ontario” as far back as they are available.
  • 2020-12-17: Vaccination data have been added as time series in timeseries_prov and timeseries_hr.
  • 2020-12-15: We have added two vaccine datasets to the repository, vaccine_administration_cumulative.csv and vaccine_distribution_cumulative.csv. These data should be considered preliminary and are subject to change and revision. The format of these new datasets may also change at any time as the data situation evolves.

https://www.quebec.ca/en/health/health-issues/a-z/2019-coronavirus/situation-coronavirus-in-quebec/#c47900

Note about SK data: As of 2020-12-14, we are providing a daily version of the official SK dataset that is compatible with the rest of our dataset in the folder official_datasets/sk. See below for information about our regular updates.

SK transitioned to reporting according to a new, expanded set of health regions on 2020-09-14. Unfortunately, the new health regions do not correspond exactly to the old health regions. Additionally, the provided case time series using the new boundaries do not exist for dates earlier than August 4, making providing a time series using the new boundaries impossible.

For now, we are adding new cases according to the list of new cases given in the “highlights” section of the SK government website (https://dashboard.saskatchewan.ca/health-wellness/covid-19/cases). These new cases are roughly grouped according to the old boundaries. However, health region totals were redistributed when the new boundaries were instituted on 2020-09-14, so while our daily case numbers match the numbers given in this section, our cumulative totals do not. We have reached out to the SK government to determine how this issue can be resolved. We will rectify our SK health region time series as soon it becomes possible to do so.


Saturday 2021-03-13 03:16:36 by Magical Marvelous MADMADMAD Mister Mim !

ever had a day when you feel like you should just sit in one spot with a loaded shotgun and not do anything but wave it at every piece of repeat shit that wanders by thus fucking up their pattern for at least 24 hours ?


Saturday 2021-03-13 05:37:04 by Lorentz Factr

This is it.

Three modes:

  1. Just show me an up and down arrow.
  2. Show me the ticker info!
  3. Help! My wife's boyfriend only let me have LED strips!

Other features added: -Super fucking fast string parser. -Adjust above modes through Python! No need to hardcode it into Arduino. -Live comfortable knowing your GME's are printing tendies all day.


Saturday 2021-03-13 06:27:44 by Michal Hocko

oom: make oom_reaper freezable

After "oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space" oom_reaper will call exit_oom_victim on the target task after it is done. This might however race with the PM freezer:

CPU0 CPU1 CPU2 freeze_processes try_to_freeze_tasks # Allocation request out_of_memory oom_killer_disable wake_oom_reaper(P1) __oom_reap_task exit_oom_victim(P1) wait_event(oom_victims==0) [...] do_exit(P1) perform IO/interfere with the freezer

which breaks the oom_killer_disable semantic. We no longer have a guarantee that the oom victim won't interfere with the freezer because it might be anywhere on the way to do_exit while the freezer thinks the task has already terminated. It might trigger IO or touch devices which are frozen already.

In order to close this race, make the oom_reaper thread freezable. This will work because a) already running oom_reaper will block freezer to enter the quiescent state b) wake_oom_reaper will not wake up the reaper after it has been frozen c) the only way to call exit_oom_victim after try_to_freeze_tasks is from the oom victim's context when we know the further interference shouldn't be possible

Signed-off-by: Michal Hocko [email protected] Cc: Tetsuo Handa [email protected] Cc: David Rientjes [email protected] Cc: Mel Gorman [email protected] Cc: Oleg Nesterov [email protected] Cc: Hugh Dickins [email protected] Cc: Rik van Riel [email protected] Signed-off-by: Andrew Morton [email protected] Signed-off-by: Linus Torvalds [email protected] Signed-off-by: Reinazhard [email protected]


Saturday 2021-03-13 06:27:44 by Michal Hocko

mm, oom: introduce oom reaper

This patch (of 5):

This is based on the idea from Mel Gorman discussed during LSFMM 2015 and independently brought up by Oleg Nesterov.

The OOM killer currently allows to kill only a single task in a good hope that the task will terminate in a reasonable time and frees up its memory. Such a task (oom victim) will get an access to memory reserves via mark_oom_victim to allow a forward progress should there be a need for additional memory during exit path.

It has been shown (e.g. by Tetsuo Handa) that it is not that hard to construct workloads which break the core assumption mentioned above and the OOM victim might take unbounded amount of time to exit because it might be blocked in the uninterruptible state waiting for an event (e.g. lock) which is blocked by another task looping in the page allocator.

This patch reduces the probability of such a lockup by introducing a specialized kernel thread (oom_reaper) which tries to reclaim additional memory by preemptively reaping the anonymous or swapped out memory owned by the oom victim under an assumption that such a memory won't be needed when its owner is killed and kicked from the userspace anyway. There is one notable exception to this, though, if the OOM victim was in the process of coredumping the result would be incomplete. This is considered a reasonable constrain because the overall system health is more important than debugability of a particular application.

A kernel thread has been chosen because we need a reliable way of invocation so workqueue context is not appropriate because all the workers might be busy (e.g. allocating memory). Kswapd which sounds like another good fit is not appropriate as well because it might get blocked on locks during reclaim as well.

oom_reaper has to take mmap_sem on the target task for reading so the solution is not 100% because the semaphore might be held or blocked for write but the probability is reduced considerably wrt. basically any lock blocking forward progress as described above. In order to prevent from blocking on the lock without any forward progress we are using only a trylock and retry 10 times with a short sleep in between. Users of mmap_sem which need it for write should be carefully reviewed to use _killable waiting as much as possible and reduce allocations requests done with the lock held to absolute minimum to reduce the risk even further.

The API between oom killer and oom reaper is quite trivial. wake_oom_reaper updates mm_to_reap with cmpxchg to guarantee only NULL->mm transition and oom_reaper clear this atomically once it is done with the work. This means that only a single mm_struct can be reaped at the time. As the operation is potentially disruptive we are trying to limit it to the ncessary minimum and the reaper blocks any updates while it operates on an mm. mm_struct is pinned by mm_count to allow parallel exit_mmap and a race is detected by atomic_inc_not_zero(mm_users).

Signed-off-by: Michal Hocko [email protected] Suggested-by: Oleg Nesterov [email protected] Suggested-by: Mel Gorman [email protected] Acked-by: Mel Gorman [email protected] Acked-by: David Rientjes [email protected] Cc: Mel Gorman [email protected] Cc: Tetsuo Handa [email protected] Cc: Oleg Nesterov [email protected] Cc: Hugh Dickins [email protected] Cc: Andrea Argangeli [email protected] Cc: Rik van Riel [email protected] Signed-off-by: Andrew Morton [email protected] Signed-off-by: Linus Torvalds [email protected] Signed-off-by: Reinazhard [email protected]


Saturday 2021-03-13 07:42:34 by Elijah Littell

Took me forever to figure out a little bug that cost me 40+ mins of my life, the problem was simply I put the totalamount to int instead of double :) Me thinking Im really fucking stupid with decimals :D


Saturday 2021-03-13 07:58:16 by Saegor

Create LICENSE.md

please do what the fuck you want. i'm turning all my projects under cc0 to promote releases under public domain in europa


Saturday 2021-03-13 08:19:44 by winderica

Update: fuck you and never see you again express-session


Saturday 2021-03-13 09:41:48 by Ravicale

Beeeg DS Spawngroup commit.

Reworked all existing spawngroups on DS. Added a few really bullshit tier ones. hurtstage_zerg_rush - An LPF spawns with a metric fuck ton of HRTs and maybe some other specials. boom_taser - Shits out up to 3 tasers+grenadiers, or maybe a special. Either way, have fun rounding corners and getting tased+gassed. Added more generic 'shield' and 'taser' special groups (these sometimes include mildly synergistic specials). These get displaced with more asshat tier groups as diff increases. Tweaked some existing spawn groups. More changes than worth listing. Tweaked dozer spawns. Dozer spawns will be significantly more common on higher diff. Green dozers no longer spawn with a grenadier. Instead, they get larger than normal squads for a dozer. Skull Dozers get titan tasers instead of regular tasers.

All difficulties below DS use normal difficulty spawn groups to make the fact that things are being redone entirely more clear.

So far they felt alright to me. Though heavies feel a tad too rare, and tactics could probably use adjusting.


Saturday 2021-03-13 13:20:22 by Masahiro Yamada

BACKPORT: modpost: file2alias: go back to simple devtable lookup

Commit e49ce14150c6 ("modpost: use linker section to generate table.") was not so cool as we had expected first; it ended up with ugly section hacks when commit dd2a3acaecd7 ("mod/file2alias: make modpost compile on darwin again") came in.

Given a certain degree of unknowledge about the link stage of host programs, I really want to see simple, stupid table lookup so that this works in the same way regardless of the underlying executable format.

Signed-off-by: Masahiro Yamada [email protected] Acked-by: Mathieu Malaterre [email protected] Link: https://git.kernel.org/linus/ec91e78d378cc5d4b43805a1227d8e04e5dfa17d Signed-off-by: Nathan Chancellor [email protected] Signed-off-by: Samuel Pascua [email protected] Signed-off-by: Sung Mingi [email protected]


Saturday 2021-03-13 16:08:47 by Sree Prosenzit Kumar Sharma

A. Bear and Big Brother

Bear Limak wants to become the largest of bears, or at least to become larger than his brother Bob.

Right now, Limak and Bob weigh a and b respectively. It's guaranteed that Limak's weight is smaller than or equal to his brother's weight.

Limak eats a lot and his weight is tripled after every year, while Bob's weight is doubled after every year.

After how many full years will Limak become strictly larger (strictly heavier) than Bob?

Input The only line of the input contains two integers a and b (1 ≤ a ≤ b ≤ 10) — the weight of Limak and the weight of Bob respectively.

Output Print one integer, denoting the integer number of years after which Limak will become strictly larger than Bob.

Examples input 4 7 output 2 input 4 9 output 3 input 1 1 output 1 Note In the first sample, Limak weighs 4 and Bob weighs 7 initially. After one year their weights are 4·3 = 12 and 7·2 = 14 respectively (one weight is tripled while the other one is doubled). Limak isn't larger than Bob yet. After the second year weights are 36 and 28, so the first weight is greater than the second one. Limak became larger than Bob after two years so you should print 2.

In the second sample, Limak's and Bob's weights in next years are: 12 and 18, then 36 and 36, and finally 108 and 72 (after three years). The answer is 3. Remember that Limak wants to be larger than Bob and he won't be satisfied with equal weights.

In the third sample, Limak becomes larger than Bob after the first year. Their weights will be 3 and 2 then.


Saturday 2021-03-13 17:00:17 by Wilmer Adalid (Alienware)

Updates for: A man can have two, maybe three love affairs while he's married. After that it's cheating. -- Yves Montand


Saturday 2021-03-13 18:46:31 by Chris Bain

Update Documentation for Active Header Highlighting

Yes, I know I call it Active Header Highlighting in some places, and Current Header Highlighting in others.

Basically the user experience I use Current, but within the code I use Active. That's because I think "Current" is a more understandable term to end users. But Active it better in the code, but current is used within the implementation and would be confusing.

If you are reading this and have a suggestion to improve it, I would love to hear it!


Saturday 2021-03-13 19:50:39 by rofl0r

fix some unicode vs ascii codec shit

honestly, the idiotic default behaviour of python with regard to strings containing non-ascii characters just makes me want to nuke my python install and never ever touch it anymore. additionally the functions decode and encode do just the opposite of what one would expect. strings should just be bytes until i explicitly request an operation that needs to operate on unicode codepoints, but not for replacing a tab with spaces.

this fixes display of sources with utf-8 unicode chars in them, like the (C) copyright symbol \xc2\xa9.


Saturday 2021-03-13 21:00:15 by Wilmer Adalid (Alienware)

Updates for: Who does not love wine, women, and song, Remains a fool his whole life long. -- Johann Heinrich Voss


Saturday 2021-03-13 21:24:55 by Tyson Andre

Proposal: Add println(string $data = ''): int

What this does

This function behaves similarly to this userland code

function println(string $data = ''): int {
    return printf("%s\n", $data);
}

Similarly to printf("%s\n", $data);.

  • println is NOT a keyword. (e.g. functions named println can continue to be declared outside of the global namespace)

  • It returns the number of bytes that were successfully written to standard output. In the unlikely event that there was an error writing, this and printf return a smaller number.

  • This deliberately always prints the unix newline (\n) instead of PHP_EOL.

    I would find it very unexpected if println were to behave differently based on the web server was running it, e.g. if you moved a website's backend from/to a linux server to/from a windows server, responses generated by println would suddenly be different.

    Additionally, https://www.php-fig.org/psr/psr-2/ recommends that all php source files contain unix line endings. If those files contain inline html/text snippets mixed with php+println(), it would be inconsistent to have \r\n in the lines printed by println() and \n anywhere else.

    This is same choice of line ending as var_dump, debug_zval_dump, and var_export use for dumping output. Otherwise, println("myArray=" . var_export($myArray, true)); would be a mix of multiple line ending choices.

    Many new languages have elected to always use only the unix newlines, e.g. https://golang.org/pkg/fmt/#Println and https://doc.rust-lang.org/std/macro.println.html

    Overall, editors do a much better job of detecting newline choices and displaying different newline choices than they did decades ago.

    My opinion is that this anything generating files targeting a specific OS's line endings should continue to use PHP_EOL or continue to base the newline choice on the OS of the user requesting the output.

    This newline choice differs from the implementation PR for a similar proposal made 2 years ago https://externals.io/message/104545 , for which an RFC was never written.

Differently from printf's argument list, echo, and print, the argument $data is type checked based on the file's strict_types setting. This is consistent with handling of $data in fwrite($stream, string $data): int or the way format strings($format) of printf are checked.

println((string)$value) should be used when strict_types=1 but you are uncertain of the type.

Reasons to add this

  1. This is useful for self-contained scripts and a useful helper function to have overall. E.g. phpt tests of php itself print multiple lines for the --EXPECT-- section, and var_dump can be overused even for known strings because var_dump(some_function()) is shorter than echo some_function() . "\n";

  2. Even if codebases add userland helper equivalents that do exactly this, If you are new to a codebase, or contribute to multiple codebases, it is inconvenient to use xyz_println, ABCUtils::println(), echo X, "\n", etc., and remember if those different functions actually use the line endings you think they do.

    Additionally, the prefixing is much more verbose.

  3. In tutorials or language references that teach a developer how to use php functionality, it is often preferable to use functions that append a newline when multiple snippets would be evaluated together to keep examples simple.

    println("Hello $name"); would be useful to have for introducing PHP to a new developer before echo "Hello $name\n"; (requires explaining escaping first) or var_dump("Hello $name"); (that debug representation is rarely useful for string(11) "Hello world")

    E.g. var_dump is frequently used instead of var_export, echo, or print in the manual even for printing strings with no control characters such as https://www.php.net/manual/en/function.json-encode.php#example-3972

TODO: Write an rfc document, gather existing counterarguments for/against naming choices and newline choices, gather examples of other languages that put a println equivalent in the standard library and their choices.


Saturday 2021-03-13 21:30:56 by ndrogers

what the fuck is wrong with this fucking shit ass"


Saturday 2021-03-13 23:23:02 by Magical Marvelous MADMADMAD Mister Mim !

SEE this reminds me of fing zimmerman. really does.

and yeah they're closing and reopening stores on a damn schedule.

'can't call them till monday'.

i need something like a familiar. when i packed up jamie and took her with me i kept my memory the whole time that vicious little bitch was around me. no offense.


< 2021-03-13 >