2,954,444 events, 1,479,573 push events, 2,344,725 commit messages, 178,898,267 characters
change difficulty back to normal because the love of my life requested it
New data: 2021-02-17: See data notes.
Revise historical data: cases (AB, BC, MB, ON).
Note regarding deaths added in QC today: “14 new deaths, but the total of deaths amounts to 10,258 due to the withdrawal of 2 deaths not attributable to COVID-19: 0 death in the last 24 hours, 11 deaths between February 10 and February 15, 2 deaths before February 10, 1 death at an unknown date.” 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:
- 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.
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
Section 1 Summary Today we will write some programs involving text file input and output. We will be importing some new libraries that contain methods necessary for making file I/O work.
Part 1 In a class called Stats (template is provided), given a text file of doubles (see this lab’s Canvas page for a sample file), write a program that determines the average, the maximum, the minimum and how many numbers are in the following buckets: less than 0, between 0 (inclusive) and 100 (exclusive), and greater than or equal to 100.
Your program should print the following message to another file called “fileOut.txt”:
Statistics for the numbers in fileIn.txt:
average: <average>
max: <max>
min: <min>
There are <negNum> negative numbers, <btw0and100> numbers between 0 (inclusive) and 100 (exclusive), and <geq100> numbers that are greater than or equal to 100.
(Optional Challenge - work on it after completing the rest of the lab!)
Write a program that generates a text file that can be used as input for the problem described above. Use your knowledge of file output, loops and the random method from the Math library. How random and in what range the numbers should be it totally up to you!
Part 2 In a class called Diary (template is provided), write a program that prompts users to enter the date as three integers separated by spaces (i.e mm dd yyyy) then it prompts them enter as many lines of prose they wish (for their to-do’s list or diary entry). Your program should store their entries at the end of a file called “diaryLog.txt” and old data should NOT be erased. Each entry should be formatted as follows (example for a diary entry entered on 7/14/2017):
...old stuff.
Date: 07/14/2017
Dear diary, today we had a midterm. I think it went ok, ..
Part 3 Write a program Advice.java that gives and takes advice on program writing. The program starts by writing a piece of advice to the screen and asking the user to type in a different piece of advice. The program then ends.
The next person to run the program receives the advice given by the person who last ran the program.
The advice is kept in a text file advice.txt and the content of the file changes after each run of the program. Furthermore, you should have another text file called adviceLog.txt, which starts off blank but with each run of the program it logs the advice that was given (without deleting the previous advices). You should allow theuser to type in advice of any length so that it can be any number of lines long. The user is told to end his orher advice by pressing the Return key two times. Your program can then test to see that it has reached the end of the input by checking to see when it reads an empty string "".
Input file: advice.txt
Section 2 Template: Lab6.javaPreview the document
Summary Today we will write some programs involving String objects. Strings are widely used not only in Java, but in many other programming languages, as well. You can think of a string as a sequence of characters; strings and are treated as objects in Java and Java platform provides the String class to create and manipulate strings.
Part 1 Write a method that capitalizes the first letter of each word in a sentence, named capitalizeFirstLetters. This method prints a capitalized version of a String to the screen -that is, it changes the first letter of each word in the string to upper case (if it is not already upper case). So "I really enjoy attending lab!" becomes "I Really Enjoy Attending Lab!". The string to be printed should be a parameter to the method, and the method should have a void return. You should test your method in main by getting a line of input from the user and applying the method to it.
public static void capitalizeFirstLetters(String input) {
//TODO: parse input for words and capitalize each one.
}
Hint: You may want to browse the Java String docs for useful methods on strings, such as split().
Hint: You can usea new Scanner to get next() words out of a String.
Hint: StringTokenizer is a class that can do the same thing.
Write a method called nameInitials that takes one String as argument, pertaining to somebody's full name and returns a String of the name's initials. Usage example,
String initials = nameInitials("Bertrand Arthur William Russell");
System.out.println(initials); //should print B.A.W.R.
Optional
Write a method called letterCount that takes two String arguments, one containing some text and the other containing a single letter. This method should then compute and return the count of all of the occurrences of that letter in the given text. Usage example,
int countMs;
countMs = letterCount("I am the very model of a modern major general", "m");
System.out.println(countMs); //should print 4
Part 2 Write a method called lexLargest that takes a string object argument containing some text. Your method should return the lexicographical largest word in the String object (that is, the one that would appear latest in the dictionary).
String large = lexLargest ("I am the very model of a modern major general");
System.out.println(large); // should print : very
Write a method called largestBy that takes a string object argument containing some text. Your method should return the largest-by-length word in the String object. In case of ties, return the first occurrence of the largest word. Note the return type is String. Example,
String large ;
large = largestBy("I am the very model of a modern major general");
System.out.println(large); // should print general
Optional
Now, using above two methods, see if you can combine them in one single method and still produce the same outputs? NOTE: use an integer to determine which algorithm your code will execute, e.g., String largestByAction(String inputText, int action) If integer action is 1, then run first algorithm and if integer action is 2, then run the 2nd algorithm. Also, if the integer action is anything other than 1 or 2, return the empty string "".
Part 3 Write a Java program named CharsIndex to get the index of all the characters of the alphabet. Ask user to input a string.The sample output was produced by this string: "The quick brown fox jumps over the lazy dog."
Sample Output:
a b c d e f g h i j
=========================
36 10 7 40 2 16 42 1 6 20
k l m n o p q r s t
===========================
8 35 22 14 12 23 4 11 24 31
u v w x y z
================
5 27 13 18 38 37
doc: move MylesBorins to emeritus (#719)
Life and work has thrown a bunch of new challenges and expectations my way and I unfortunately don't have the time to keep up with the commitments required of a regular member. It is pretty amazing that the foundation and the CPC are in a place where I feel 100% confident in stepping back.
I'll still be around and thanks to our egalitarian governance I'll still be able to participate in all the meetings 🎉
I've moved myself to emeritus, a new section, something we've done over at Node.js that I quite like. I think it is nice to keep track of former members.
What a wild ride this has been!
this crashed the server completely without giving me any code reference, in other words... fuck you jochem <3
change this.index to this.i so osc doesn't try to send an undefined value
arm64/configs: disable Werror
fuck you
Signed-off-by: Reinazhard muh.alfarozy@gmail.com
Change the structure of ParsedArguments and update parsing functions accordingly
This one is a huge quality of life improvement (in my opinion). Parsing the object returned by yargs-parser was absolutely hell, since Object.entries had to be used. The code got rapidly harder and harder to read and I decided to change the structure of the parsed arguments using an interface, and it made every parsing function a bit easier to read and debug in my opinion.
Created Text For URL [tribuneonlineng.com/28-year-old-girl-stabs-boyfriend-to-death-over-n1500-in-bayelsa/]
Always clear invalid regions if performing layout
It has taken me a large number of hours to decide on this particular one-line fix, and I'm still not 100% sure what's going on.
That said, the logic now feels more correct: if we're invalidating everything then that necessarily means we're invalidating whatever rects were in the list, and we can ignore them.
More concretely, I think this was a bug; by leaving the invalid
rects in place, a subsequent call to invalidate_and_finalize would
see the left over rects and invalidate again, unnecessarily.
I do not know why this bug caused (or was a factor in) #1593.
My best guess is that there was a change to how macOS handles setNeedsDisplayInRect: when it is called from viewWillDraw:; my guess is that if you call this method after having previously called setNeedsDisplay: it will assume that the new rect is more accurate than the previous blanket invalidation, and will only redraw the new rect.
I'm not convinced of this explanation, though. In particular, it looks like our drawRect call is still being passed the expected rect, the pixels just end up not the ones we expect.
Okay, here's my revised theory; the additional invalidation is triggering a second paint call before the frame deadline, and so the initial paint work, which covered the entire window, is discarded; the second paint call does not update the regions that weren't explicitly invalidated, and so we end up failing to repaint portions of the view.
I think that might be it.
fix: add index to courseware_studentmodule for report performance.
= IMPORTANT WARNING =
This can be a VERY EXPENSIVE MIGRATION which may take hours or days to run depending on the size of the courseware_studentmodule table on your site. Depending on your database, it may also lock this table, causing courseware to be non-functional during that time.
If you want to run this migration manually in a more controlled way (separate from your release pipeline), the SQL needed is:
CREATE INDEX courseware_stats ON courseware_studentmodule
(module_id, grade, student_id);
You can then fake the migration: https://docs.djangoproject.com/en/2.2/ref/django-admin/#cmdoption-migrate-fake
= Motivation and Background =
TLDR: This adds an index that will speed up reports like the Problem Grade Report. This fixes a performance regression that was unintentionally introduced in 25da206c.
I'm capturing the entire saga below, in case Open edX operators need to dig into it.
The tale begins in November of 2012 (yes, seriously). We had an inline analytics feature that would display a histogram to course staff by each problem in the LMS, detailing how students did on that problem (e.g. 80% got 2 points, 10% got 1 point, 10% got 0 points). The courseware_studentmodule table already had an index on the module_id (a.k.a. module_state_key), but because there were 100K+ students that had student state for some problems, the generation of those histograms was still extremely expensive. During U.S. Thanksgiving weekend in late November of 2012, that load started causing operational failures on edx.org.
As an emergency measure, I manually added a composite index for (module_id, grade, student_id) on courseware_studentmodule in order to stabilize the courseware on edx.org. I did not follow up properly and add it in a migration file. Later on, the inline analytics feature was removed entirely, so the index was considered redundant (but again, it was not properly cleaned up).
Various reports were created over the years, some of which relied on having an index for module_id. These ran fine because there had long been an index for that field specifically.
In 2018, the courseware_studentmodule table for edx.org ran into the 2 TB size limit that our old RDS instance had. We had a fair amount of monitoring for various limits that we thought we might run into, but the per-table limit took us by surprise. The Devops/ SRE person fielding that issue needed to free up space in a hurry in order to make the courseware functional again. Examining the database itself, he noticed that we had a module_id index that was technically redundant because the composite index of (module_id, grade, student_id) would cover queries that would otherwise use it. Again, as an emergency measure, he dropped the index on module_id in order to free up a little space and buy enough time to do a proper move of the database to Aurora.
Devops-of-2018 being more disciplined than me-of-2012, the index on module_id was removed in 25da206c. The intention was to make it so that the state of the code would match what was live on edx.org. But because the composite index was added in an ad hoc way, what that really meant was that now queries involving module_id were only indexed by the (module_id, grade, student_id) composite index that existed only on edx.org and no other Open edX instances.
We didn't realize this issue until months later. @blarghmatey created an index to re-add the index for module_id:
https://github.com/edx/edx-platform/pull/20885
The reason why we didn't accept this immediately is because migrations for this table are very operationally risky and take days to run. Faking this migration would have put edx.org even more out of sync with the Open edX repo. Complicating this somewhat was the fact that some folks still seem to be running a variant of the inline analytics on their fork.
So in the end, we're going forward with this migration that brings the code fully into sync with indexes on edx.org and covers the obscure inline analytics histogram use case, while still covering the module_id index needed for the fast generation of certain reports that focus on a single problem.
Sorry folks.
feat: ConnectionOptions can convert to internal::Options (#5864)
Part of googleapis/google-cloud-cpp#5738
This give us and users a path to migrate from the old ConnectionOptions<T> instances so the new google::cloud::Options class. After this PR, we can start adding overloads to existing functions that take ConnectionOptions<T> to also take Options, and have the Options overload be preferred.
Since this is the first PR where we're really using the Options class, I'll make a few observations and ask for feedback.
- I don't love that
opts.set<GrpcUserAgentPrefixOption>(std::set<std::string>{user_agent_prefix_});requires the user to spell thestd::setpart. The reason for this is becauseOptions::set<T>()takes a variadic forwarding reference, and passing only an initializer list (e.g.,opts.set<GrpcUserAgentPrefixOption>({user_agent_prefix_});) will not be able to deduceU. We could "fix" this ifOptionstakes a position that all option structs must have one data member named.value(which we're currently agnostic about). In this case, we could use the type of the.valuemember to be the type of set's argument, thus avoiding the forwarding reference, and thus enabling caller-side initializer lists. Thoughts? Optionsonly "gets" values, so that requires a copy. This is fine and easy, but it could become an issue if these options become large and get copied a lot. For example, consider an option whose value is a set/map, and the caller wants to insert a value. That would require making a copy, inserting the value, then moving the new value over the old one. Just something to consider.- The endpoint option is gRPC specific:
GrpcEndpointOption. Is that fine? I think it's OK. If we make it transport agnostic, then we'll need to find another header for it to live in. GrpcUserAgentPrefixOptionhas a std::set for all the prefixes. This means that the user can't control the order of the prefixes. Is this OK with us? I think it's probably fine. I don't know if/why the order would matter. If we do care about the order, we could use astd::deque.
Note: I did not change the implementation of ConnectionOptions<T> to simply hold a single google::cloud::Options instance and re-implement its getters/setters in terms of Options, because there were enough little semantic differences that made it messy. For example, channel_pool_domain() is now implemented as a single key in GrpcChannelArgumentsOption, which makes it very difficult for the channel_pool_domain() getter to return a const-reference (to what)? I could stuff a default empty string in there for that option, but then an empty channel_pool_domain is used as a signal to not set that channel attribute.
large-scale refactor
-Now includes all perks (by adding cost scaling info for all perks). Observation and Frenzy are not yet optimized (TODO) but can be manually adjusted. Packrat is now optimized since it's just a resource perk. -Removed heirloom optimization. Omsi's calc is better, and this would have been hard to maintain through the refactor. This is a perks calc! -Added Scruffy level which is required to value Prismal correctly. -Replaced health/attack weights with clearspeed/survival weights for better clarity on the distinction between atk/hp and equality, and to make it impossible to set attack weight higher than health weight (which is just wrong). Final attack weight is clearspeed weight. Final health weight is clearspeed + survival. New equality weight (simply used to weight the effect of max equality) is the survival weight. Radon weight remains. -There is a big global "perks" object where all the bookkeeping happens. Yeah it's still global but it is much easier to maintain in the future. In general a lot of old stuff was cleansed and replaced with routines that I find cleaner. YMMV. -Now includes prestige-based equipment scaling for low equip levels. Prior calc assumed 1.2 cost for linear effect, but prestige scaling is much better than this. -Probably other shit I'm forgetting. -IANA web dev. No bully. Please feel free to volunteer to clean up the HTML-generation code or reorganize this into multiple files or whatever. All the HTML and JS hooks into the HTML are copypasta from the original.
TODO: Add checkbox(es) for locking of inputs to get rid of the annoyance of fucking with the equip levels and tributes every time you load a save. TODO: Optimize Frenzy and Observation. PROBABLY NOT TODO: Optimize Pheromones. There could be an optional breed speed weight, probably no other way to do it.
Authentication forms and 404 page
Through the inspirations I had from dribbble and which I shared with Milanote. I created the Login page and the Registration page. As I had no more ideas for the 404 page and to tell you the truth, I think it is not that ugly either, so I made the 404 page according to the authentication forms.
Obviously, all these pages are subject to changes, from colors, to the design of the buttons and the design of the 404 page itself.
However, everything is functional, from navigation between pages, to their responsiveness in different types of devices.