3,142,140 events, 1,533,333 push events, 2,406,918 commit messages, 193,068,243 characters
New data: 2021-01-31: DATA RECENTLY CHANGED. SEE NOTES.
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:
- 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.
- 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”.
- 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.
Revise historical data: cases (MB, NU, SK).
SK did not provide testing data today. They also did not update their usual daily case CSV.
Note regarding deaths added in QC today: “The data also report 31 new deaths, for a total of 9,794. Among these 31 deaths, 3 have occurred in the last 24 hours, 25 have occurred between January 24 and January 29 and 3 have occurred before January 24.” 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.
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.
Add files via upload
Family Bitch changes:
- I improved some pieces of text
- Also, I fixed the kitchen schedule a bit (the lack of energy error)
- Added the ability to jump into Family Bitch mode right from the beginning (in perks)
- Fixed a collar displaying. Yes, again..
- Added a Family Bitch section in the Help menu
- Now you can't use your phone while Family Bitch mode is active
- Also, I changed the Bay Window location a bit. For now, you only can stare outside, but I think it's a good place to add a scene or two in the future
- Added a scene by Plaze. When you walk outside in FB mode, there's a 20% chance to meet a police officer and to have fun with his dog. Bestiality and non-consent fetishes must be turned on to see this scene! Other changes:
- Hid some dead links to not existing paragraphs
- Also, I improved the training with the brother paragraph (just a bit, totally nothing interesting)
- Added a scene by Rachael. Now, if your baby's father is Jack, you will see a rich scene with a good or bad reaction
- Another new scene by Rachael
- A threesome event! When you are working as a "night GF" and call a young man over to your place, there is a 20% chance (if you have 70 or more Corruption points and your dad has 50 or more of them) to run into it. As you could guess, your father catches you in the middle of the night and decides to join the fun
I love to listen too music, I love sports but stop playing after high school. And I hate the habits I picked up
31january2021 Jeremiah Owyang-The Future of Social Audio: Startups, Roadmap, Business Models, and a Forecast <- will audio rival video by the end of 2020s? I don't think so but I'd love to be proven wrong since the human voice is amazing
Updates for: Remember: Silly is a state of Mind, Stupid is a way of Life. -- Dave Butler
Reference implementation of Soter container (#35)
- Reference implementation of Soter container
Okay, here's my stupid idea. In addition to specs with prose, provide users with a reference implementation of whatever is described. Some people are better at understanding concepts through code. Plus, this provides an "executable specification" and tests. I have found this invaluable when writing Secure Cell spec: that caught quite a few mistakes and misconceptions that I had about its implementation.
(History-savvy people here could have found parallels between this and the concept of "literate programming". Indeed, if only Knuth's ideas caught up, this would have been a perfect opportunity for that approach. Unfortunately, it's not really popular to have good tooling.)
The reference implementation is written in Go. Aside from an obvious reasons having to do with Cossack Labs being a Go shop, this choice has a number of other benefits:
-
very good standard library, with a lot of cryptographic primitives available which will come very handy later
-
readable to most programmers who are familiar with C syntax
-
almost immediately executable if you copy-paste the sample code, thanks to "push to GitHub to publish a package" approach
-
reference implementation can actually reuse its own code for different cryptosystems
Unfortunately, you can't run this on Go Playground without much hassle, but that would have been amazing.
Now, note that "reference implementation" is different from the "official GoThemis source code". The overriding objective here is to illustrate key points in Themis algorithms. Readability and correctness are the main focus of the reference implementation. Performance, usability, good error reporting, feature completeness -- all of this can be sacrificed for the sake of brevity and clarity of the code.
Themis Core's C code is anything but easy to understand cryptography. Since even its maintainers make mistakes when deciphering code paths leading to arcane OpenSSL invocations, any cryptography audit would be pretty expensive for it. Hopefully, this reference implementation can serve as a better way to understand the cryptography behind Themis.
Now... Here's an implementation of Soter container for starters.
- Use reference implementation instead of example
Now that we have a reference implementation in our repository, let's link to it for the implementation details and replace the snippet with something shorter (which still invokes the same code). The reader should be able to copy the snippet, run it with "go run", and see the output which corresponds to whatever is there in the spec prose.
OpenSSL: Support configuration of TLSv1.3 ciphersuites
The OpenSSL developers decided, during the OpenSSL 1.1.1 development phase, to use a different API and different set of lists for TLSv1.3 ciphersuites, than for every TLS version preceeding it.
This is stupid, but we have to work with it.
Rename the current default ciphersuites array to indicate that it is for older protocols, and add a new array for the defaults for the newer protocol. Those defaults correspond to the built-in defaults in OpenSSL; users are free to add or remove entries as usual.
This commit also improves configuration fault resilience. The reason is that if you don't pass any valid old-style ciphersuites, OpenSSL will not negotiate an older protocol at all. However, when they implemented the new API, they decided that lack of any valid ciphersuites should result in using the defaults. This means that if you pass a completely invalid ciphersuite list (like "foo"), OR if you pass a TLSv1.2-only ciphersuite list, TLSv1.3 continues to work. This is not mirrored; passing a TLSv1.3-only ciphersuite list will break TLSv1.2 and below.
Therefore we work around this lack of mirroring by falling back to the default lists for each protocol. This means that if ssl_cipher_list is complete garbage, the defaults for the respective protocols will be used, and TLS setup will succeed. This is logged, so that administrators can fix their configuration.
I prefer this approach over explicitly disabling the protocols if their respective ciphersuite lists are garbage, because it will result in unusable TLSv1.3 if people run newer solanum with their older charybdis/solanum configuration files that contain custom ssl_cipher_list definitions. Hindering TLSv1.3 adoption is not an option, in my opinion.
The downside of this is that it is no longer possible to disable a protocol family by not including any of its ciphersuites. This could be remedied by an ssl_protocol_list configuration directive if it is decided that this functionality is ultimately necessary.
This work is not required for either of the other TLS backends, because neither of those libraries yet support TLSv1.3, and in the event that they eventually do, I expect them to allow configuration of newer ciphersuites with the existing APIs. This can be revisited if it turns out not to be the case.
Signed-off-by: Aaron Jones [email protected] Tested-by: Aaron Jones [email protected]
Update Ca1_Programming.java
You have been given a file named “people.txt” – this contains the details of a person in the following format: Line 1 --- Line 2 --- Line 3 --- The firstname and surname should be text; the age should be a number between 0 and 100, and the gender should be either ‘M’ (for Male), ‘F’ (for Female), or ‘T’ (for Transgender) Example: Tiago Murphy 23 M Your task is to:
- Read the information and store it in appropriate variables in your program.
- Check that the data obeys the validation rules. These are: a. The firstname and surname must be TEXT ONLY. No numbers are allowed. There must be 1 space in the line to separate firstname from surname. If there is more than 1 space, everything after the 1st space is considered to be the surname. b. The age must be an integer between 0 and 100 c. The gender must be only the letter ‘M’, or the letter ‘F’ or the letter ‘T’. If any of the validation rules have been broken, then you must output an appropriate error message that tells the user clearly why it is not valid.
- Output the data to a new file called “status.txt” in the following format:
runtest: rollback --nbval-lax change in bc4f9daa140d36b86c272ba941cdb9bc33b6401e
Thinking about this over the night. Maybe disable all output check by default is probably too extreme.
I would assume there will be at least one cell with # NBVAL_CHECK_OUTPUT in
every notebook. I feel that output checking is the equivalent of the assert
in regular unit tests so it would be weird and a bit scary that we do not
assert anything in the notebooks.
So either have # NBVAL_CHECK_OUTPUT with --nbval-lax or # NBVAL_IGNORE_OUTPUT with regular --nbval is the same: we can never hide that
we leverage the notebooks as test cases. Might as well be on the safe side and
stick with regular --nbval like currently.
Most of the current cells do not need # NBVAL_IGNORE_OUTPUT. We will need
it for cells that output xarray dataset in html. So probably 1 or 2 cells per
notebooks, assuming notebooks are not gigantic.
For other ordering problems in the output, we can also use # NBVAL_IGNORE_OUTPUT instead of doing hacks like in
https://github.com/Ouranosinc/pavics-sdi/commit/d19ad355b522b6f5f012308b4fe94a079ca76c37
which makes the code harder to read from the tutorial perspective.
OpenSSL: Support configuration of TLSv1.3 ciphersuites
The OpenSSL developers decided, during the OpenSSL 1.1.1 development phase, to use a different API and different set of lists for TLSv1.3 ciphersuites, than for every TLS version preceeding it.
This is stupid, but we have to work with it.
This commit also improves configuration fault resilience. The reason is that if you don't pass any valid old-style ciphersuites, OpenSSL will not negotiate an older protocol at all. However, when they implemented the new API, they decided that lack of any valid ciphersuites should result in using the defaults. This means that if you pass a completely invalid ciphersuite list (like "foo"), OR if you pass a TLSv1.2-only ciphersuite list, TLSv1.3 continues to work. This is not mirrored; passing a TLSv1.3-only ciphersuite list will break TLSv1.2 and below.
Therefore we work around this lack of mirroring by falling back to the default list for each protocol. This means that if ssl_cipher_list is complete garbage, the default will be used, and TLS setup will succeed for both protocols. This is logged, so that administrators can fix their configuration.
I prefer this approach over explicitly disabling the protocols if their respective ciphersuite lists are invalid, because it will result in unusable TLSv1.3 if people run newer solanum with their older charybdis/solanum configuration files that contain custom ssl_cipher_list definitions. Hindering TLSv1.3 adoption is not an option, in my opinion.
The downside of this is that it is no longer possible to disable a protocol family by not including any of its ciphersuites. This could be remedied by an ssl_protocol_list configuration directive if it is decided that this functionality is ultimately necessary.
This work is not required for either of the other TLS backends, because neither of those libraries yet support TLSv1.3, and in the event that they eventually do, I expect them to allow configuration of newer ciphersuites with the existing APIs. This can be revisited if it turns out not to be the case.
Signed-off-by: Aaron Jones [email protected] Tested-by: Aaron Jones [email protected]
Merge #39
39: Address #6: polyval r=michaelkirk a=stonylohr
Slightly different from my original proposal. There are a few pieces worth highlighting.
First, I think the most idiomatic Rust approach would actually be to drop the n argument as well as s, and let the size of the p argument imply the order of the polynomial. The reason I didn't take this further step is that keeping n requires fewer changes, and leaves the code a closer parallel to its C++ and Java counterparts. I figure we can always choose to reconsider later, perhaps if and when we focus on performance. The performance implications are likely minor, and I'm not sure which approach they favor.
Second, while keeping n, it's somewhat tempting to change it to usize, since its support for the negative special case doesn't appear to be used in any of Karney's code that I've examined or logged. It's certainly not used in any of our current geodesic functionality. It may be used in geoid, magnetic model, or projection special cases that aren't hit by any of the scenarios I've run in my instrumented C++. My current guess is that it's not actually used and was only added for completeness. Anyway, I left it signed for now, but changed it from i64 to isize since we ultimately need to cast it to usize for use as an array index, and any value too large for i32 would strongly hint that we're already off the rails. The largest n I've seen in instrumented scenarios is 29.
Third, I went with a slightly different polyval implementation than my original proposal. I felt that my new version is slightly more clear that it never tries to cast a negative n to usize (though both should actually be safe), and that it might give the optimizer more of a hint that we don't care about the i value except for accessing an element of p (though I suspect it would recognize that anyway).
Fourth, I tried to keep changes to polyval's callers minimal in most cases, but there were two I couldn't resist: Both _C3f and _C4f were using floating point values to represent array indices. I switched these to usize, also tweaking the types of some variables they interact with.
Finally, these changes should be behavior-neutral. I think they'll help me with arcdirect troubleshooting because polyval is called extensively in some sections of code used to calculate Geodesic member variables that end up with suspect values, and these changes will make it easier for me to compare the C++ and Rust code for these sections. However, they don't do anything to resolve the arcdirect problems themselves.
I'd be happy to revise my approach if you'd prefer something different for any of these various items.
- I agree to follow the project's code of conduct.
- I added an entry to
CHANGES.mdif knowledge of this change could be valuable to users.
Co-authored-by: Stony [email protected]
Crash Fix. Working Fix. Couple of TO-DOs
It does work. There is a few things that i tested that dealt with consistent results. Test Area is Rage Fire Chasm due to my famliarity of the dungeon as my personal test grounds in all wow revisions. And Moltencore Raid per @Jinnaix guidence So far it is only tested with DUNGEON (Rage Fire Chasm) and RAID (Moltencore).
You MUST be half way thru the dungeon then kill a boss for it to trigger the save resurrection spot thru out the instance. if you die near the entrance upon entry you will spawn in a grave yard, but if you are half way thru the instances like i was with rage fire chasm and killed Taragaram the Hungerer or further then it will start saving the points for anything after you kill in that instance even by the entrance of the instance. Same thing with Molten core, the dynamic resurrection didnt occur until you reached magmus and kill him. TO DO: 5 Man or More Return False Function. Where if we have a group of 5 or in a instance, the module will not work and will send the dead player outside of the entrance. Raids, Figure out how to Ressurect players at the outside entrance of raids as it doesnt do it but acts like normal dungeon when doing a dynamic ressurection.
Co-Authored-By: Jinnaix [email protected]
Uncurses Stim Chems
effect_multiplier is the amount consumed, not the amount in bloodstream. It was being used like that, however, which meant all stat boosts were multiplied by, like, 0.01 and just neutered. Also, having higher effects per unit is kinda insane. If you had 18 units (the overdose limit) of machine spirit in your system, and the effects scaled with amount in your body, you would end up with like, 300 extra mechanical skill.
[wip] Add a basic Emacs configuration
This is intended to be a really basic Emacs configuration. The main features of this configuration are:
- KISS principle; do not include all the super fancy featured packages for IDE or OS-like extension of Emacs, but keep it simple, stupid and thin as possible.
- Out-of-the-box; it should be downloaded with CLI tools (like wget,
curl), and the only additional operation required in order to let it
work is the extraction of the literate part (i.e. org-babel) into a
dedicated
init.el. - Emacs-like; it should work as a vanilla Emacs distribution, so trying not to remap main keybindings, but adding a little set of important keychords. This means no Evil mode, but God mode.
- Extendible; if we want to add a particular set of configuration and packages, better to do it in separate files, which are not included with the basic configuration, but can be easily plugged in (this means some sort of 'ide-mode', 'os-mode')
for some fucking reason i was lied to and our RPID is 144 bits AFTER the RS code is appended. Cool. Epic. 3 hours of my life i will never get back.'
Create ブログ “2021-02-01-if-you-love-your-life-everybody-will-love-you-too”