3,691,621 events, 1,500,264 push events, 2,368,516 commit messages, 184,023,399 characters
what the actual fuck I'm gonna eat a small chiled this is dumb make the pain stop
When I die put my ashes in a trashbag
I don't where they go
Don't waste your money on a grave stone :cry:
I honestly have no fucking idea at this point, it's fucking ridiculous, Apple have just broken something and I might just leave it for now
Liquids are implemented
Sucking and blowing, oh yeah
New data: 2021-03-31. See data notes.
Revise historical data: cases (BC, MB, ON, SK); mortality (ON).
Note regarding deaths added in QC today: “9 new deaths, for a total of 10,667 deaths: 3 death in the last 24 hours, 6 deaths between March 24 and March 29.” 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.
0.3.8 r2
ENGINE
- Crafting sound preset (cook sound, metal sound)
- Ground sound replace placeholder CSS sound mod
- Autosave when quits or main menu
- Save small image preview into a file.
- Load game menu UI.
- Camp user interface overhaul o Use sprite o Crafting components requirements
- Revamp camping cost build o Use both centurion and item requirements. o Build camp object remove item from inventory. o Retrieve item returns 50% centurion and all components back.
GAMEPLAY
- Cheat god (toggle immortal)
- Local NPC Manager constant spawning is annoying. Replace spawner system with Cydrone deployer (spawns cydrone, Interact_EnemyGenerator, can be deactivated.
- Artillery can be deactivated.
- Artillery minimum range.
- Artillery target error
- OST Don’t play twice in a row (Save into the save file)
- MusicManager better transition (play immediately on load save like Skyrim)
BUGS
- Crafting item preview bug
- Inventory favorite icon cannot be seen bug
- Autosave/quicksave wrong filename bug
stage2: WIP: rework ZIR memory layout; overhaul source locations
The memory layout for ZIR instructions is completely reworked. See zir.zig for those changes. Some new types:
-
zir.Code: a "finished" set of ZIR instructions. Instead of allocating each instruction independently, there is now a Tag and 8 bytes of data available for all ZIR instructions. Small instructions fit within these 8 bytes; larger ones use 4 bytes for an index intoextra. There is alsostring_bytesso that we can have 4 byte references to strings.zir.Inst.Tagdescribes how to interpret those 8 bytes of data.- This is shared by all
Blockscopes.
- This is shared by all
-
Module.WipZirCode: represents an in-progresszir.Code. In this structure, the arrays are mutable, and get resized as we add/delete things. There is extra state to keep track of things. This struct is stored on the stack. Once it is finished, it produces an immutablezir.Code, which will remain on the heap for the duration of a function's existence.- This is shared by all
GenZirscopes.
- This is shared by all
-
Sema: represents in-progress semantic analysis of azir.Code. This data is stored on the stack and is shared among allBlockscopes. It is now the main "self" argument to everything in the file that was previously namedzir_sema.zig. Additionally, I moved some logic that was inModuleinto here.
Module.Fn now stores its parameter names inside the zir.Code,
instead of inside ZIR instructions. When the TZIR memory layout
reworking time comes, codegen will be able to reference this data
directly instead of duplicating it.
astgen.zig is (so far) almost entirely untouched, but nearly all of it will need to be reworked to adhere to this new memory layout structure.
I have no benchmarks to report yet, as I am still working through compile errors and fixing various things that I broke in this branch.
Overhaul of Source Locations:
Previously we used usize everywhere to mean byte offset, but sometimes
also mean other stuff. This was error prone and also made us do
unnecessary work, and store unnecessary bytes in memory.
Now there are more types involved into source locations, and more ways to describe a source location.
- AllErrors.Message: embrace the assumption that files always have less than 2 << 32 bytes.
- SrcLoc gets more complicated, to model more complicated source locations.
- Introduce LazySrcLoc, which can model interesting source locations with very little stored state. Useful for avoiding doing unnecessary work when no compile errors occur.
Also, previously, we had src: usize on every ZIR instruction. This is
no longer the case. Each instruction now determines whether it even cares
about source location, and if so, how that source location is stored.
This requires more careful work inside Sema, but it results in fewer
bytes stored on the heap, without compromising accuracy and power of
compile error messages.
Miscellaneous:
- std.zig: string literals have more helpful result values for
reporting errors. There is now a lower level API and a higher level
API.
- side note: I noticed that the string literal logic needs some love. There is some unnecessarily hacky code there.
- cut & pasted some TZIR logic that was in zir.zig to ir.zig. This probably broke stuff and needs to get fixed.
- Removed type/Enum.zig, type/Union.zig, and type/Struct.zig. I don't think this quite how this code will be organized. Need some more careful planning about how to implement structs, unions, enums. They need to be independent Decls, just like a top level function.
Fucking piece of shit crlf bullcrap god fucking damn you windows and git for doing this shit.
v0.0.1.3 - 01.04.2021.
With this, I can say that my save/load/delete feature is complete. Again, most of these changes were in BP's. Most of interactions (for this feature) are located in Widgets, really don't want to code widgets in C++ (I can make C++ base class and BP derived class so I can style it). Might do these in the future, it's not difficult, just annoying to deal with.
- Fixed save games path - Save games weren't loading on beginning of the new session. Apparently 'FPaths::ProjectSavedDir()' doesn't actually go inside 'SaveGames' dir. It was my bad for thinking that it does, without testing it afterwards (was getting late and just wanted to finish that part of the feature).
- Fixed cancel save game - Now clicking on the 'return' button, or pressing the 'esc' key on keyboard, won't save the game no matter what the player types in.
- Fixed NameSaveSlot_WBP focus - On player click, with mouse, widget was deleted, and gave save slot was saved based on current input. Now it will only change focus to widget instead of editable text box.
- Reworked NewGameSlot_WBP - Now it holds save/load slot and delete slot. GUI depends if there exists, or doesn't, a save game.
- Implemented 'esc' key - In menus pressing 'esc' key on the keyboard will return player to the previous menu or cancel the current action (exit, naming the game). Focus will always be on the current menu (this was a pain to understand).
- Implemented delete feature - Player can now delete his saved game. Delete button will only appear if player has made a save game. Otherwise it will not be shown (does exist always).
- Implemented enter feature - Player can save game with pressing 'enter' on the keyboard. No longer need to click on 'save' with the left mouse button.
- Implemented save game limitations - Things like naming and length. This was fun to do (not). 8.1) Save game name limitation - Player can only use standard letters (a-q/A-Q) and numbers (0-9). 8.2) Save game name length limit - Player can use 12 characters for naming a save game. Yes, save slot can be empty and it will work. Why? Why not.
Time for the next challenge. Much less coding in this one, probably only for some 'feature' fixes (when I stumble upon them). Time for some modeling/remodeling, texturing, animations, particle effects (this one is second to last, never did this) and sound effects (this one is last, last time I did this was in college).
Merge pull request #15 from blitzblade/KD/fixes
fuck you
fuck man on a monday man, shit fuck i got a steak on a monday main, shit fuck fuck shit, fuck yeah man, monday with a steak, beer too man.
feat: enable costs profiling by default
Having costs breakdown (how much gas was spend for each operation type) is helpful for both increasing reliability (as we can eyeball if the costs "make sense") and developer friendliness (as devs can understand where all the gas is going).
Currently this is hidden behind a feature flag, but I would love to argue that we should just always enable it.
Performance cost seems to be negligible: we heap-allocate an array once per apply state, and actual cost increasse are just counter increments, they should be dwarfed by the host functions themselves.
Correctness-wise, the code is semi-sensitive. It is executed by runtime, but doesn't affect the results. So it's enough if it doesn't panic.
Create Menstrual Cycle Predictive Model.ipynb
Menstruation, or period, is normal vaginal bleeding that occurs as part of a woman's monthly cycle. Every month, a woman’s body prepares for pregnancy. If no pregnancy occurs, the uterus, or womb, sheds its lining. The menstrual blood is partly blood and partly tissue from inside the uterus. Regular periods are a sign that a woman’s body is working normally. A woman should have regular periods unless she is pregnant, breastfeeding, postmenopausal, hormonal imbalance, or have a medical condition that causes her periods to stop. Irregular, painful, or heavy periods may be signs of a serious health problem. Irregular periods also can make it harder to get pregnant.
Below are four of the most common types of abnormal menstrual periods: -
Menorrhagia & Polymenorrhagia (Prolonged, Heavy Bleeding) Dysmenorrhea (Excess Pain During Period) Amenorrhea (Absent Periods) Hypomenorrhea (Extra Light Periods) Ovulation – Ovulation refers to the release of an egg during menstruation in females. Part of the ovary called the ovarian follicle discharges an egg. The egg is also known as an ovum, oocyte, or female gamete. It is only released on reaching maturity.
There's a 42% (max) chance of conception on the day before ovulation, the most fertile day of your cycle. 10% of women have PCOS, a condition that is associated with irregular and infrequent ovulation, making natural conception trickier. Ovulation day can be find using the surge in Luteinizing Hormone (LH): - a. A LH surge means that you will probably ovulate within the next 12 to 24 hours. b. When taken correctly, ovulation tests are approximately 99% accurate in detecting the LH surge that precedes ovulation. However, these tests cannot confirm whether ovulation actually occurs a day or two later. Problem Statement: Estimate the menstruation cycle at an early stage and be ready before the process begins.
Predict the chances of next menstrual cycle. Predict the Estimated Ovulation Cycle. ABSTRACT:
This analysis details variation in menstrual cycle characteristics that are not widely known yet have significant implications for health and well-being. Clinically, women who wish to plan a pregnancy need to have intercourse on their fertile days. In order to identify the fertile period, it is important to track different parameters such as cycle length and to keep watch on various hormones like Luteinizing hormones, Estrogen. Conclusion:
Variability of the menstrual cycle is normal.
There are, however, norms that if exceeded might indicate health problems.
At a minimum, monitoring menstrual cycle length with a simple calendar is recommended.
The addition of a biological marker for estimating the day of ovulation and the beginning of the fertile phase is essential for those seeking to avoid and achieve pregnancy and for assessing menstrual cycle health.
Score for objective I:- To predict next menstrual cycle
RMSE: 1.34 R2Score: 0.862 Adj Rsquared: 0.859 Score for objective II:- To predict estimated day of ovulation
RMSE: 1.66 R2Score: 0.88 Adj Rsquared: 0.879
April 1st commit- First commit of chapter 2
First of chapter 2, legit a day after lmao. Idk what this chapter holds but it's just another chapter in our story. Don't know what to expect from this, I feel closer than ever to her mentally it's weird. I think I've come to peace that this is just another part in our great story. If it's meant to be everything will fall into place itself. Let's see how this goes and let it flow. Fuck love, Fuck feelings, we live in the moment and have fun. IT'S THE LIFE OF THE PARTY!!!!!!!!!!!
update es.js
Modified from the formal "You" to the direct "you" for two reasons:
- Its more friendly
- It's more inclusive. The formal you makes you choose between female and male nouns,adjectives, etc., and with the informal you it's easier to avoid those. I also modified words that are female/male with the @ at symbol. For example, bienvenid@ , and changed the gender on "coder" to be programador@ .
A couple other small corrections on language too.
[EDS-556] Return student search results when requester is authenticated (#47)
- Refactor backend to support student search results
Essentially, this inserts a population layer into the results.
Before:
{
"num_results": 1,
"scenarios": [
{
"description": "foo",
"people": [...]
}, # . . .
]
}
New structure:
{
"num_results": 2,
"scenarios": [
{
"description": "foo",
"num_results": 2,
"populations": {
"employees": {
"num_results": 1,
"people": [ . . . ]
},
"students": {
"num_results": 1,
"people": [ . . . ],
}
]
}
]
}
This also includes the num_results field at each layer, so it's always known whether the underlying structure has values that need to be iterated over, or whether it's just a default, empty collection.
- Updates JSON output test, since that is not reliant on front-end changes
- Fixes
validate_box_numberafter writing a test for it and realizing it was broken.
- Updates the frontend to be compatible with the output structure change
Other changes:
- Consistently use
num_resultsinstead of a combination ofnum_resultsandresults|length, now thatnum_resultsis available at all layers - Breaks out the radio options for population and full/summary into a separate partial template , just because it was getting lengthy.
- Renames
search_options.pytosearch_attribute_selection.yso that the stuff including the title "Search options" heading can be broken out into a file calledsearch_options.py. - Adds developer-friendly type-hints to the data types in the complex jinja rendering, where we have loops within loops, so that it's easier to understand which loop is iterating over which model.
-
Updates tests to be compatible with the new front-end state, and back-end data structure.
-
Fixes/Feedback from PR
- Refactors another small snippet from
test_saml_blueprint.pyto use the new HTMLValidator strategy for consistency. - Breaks
summary_results_table.htmlinto several partials, so that we don't have to deal with the insane amount of indentation when editing. - Renames
TestModelto_TestModelto get rid of a pytest warning - Fixes result count so that results are comma-delimited and properly singular/pluralized
- Simplify the browser<->backend communication (#48)
The original intent of the backend API design was because we originally intended this to be a javascript-powered experience. However, once we realized it wasn't, we never addressed the back-end API, which resulted in a lot of extra complexity.
This change makes the front-end request input model match the actual front-end use case, which removes several additional validations, translations, and an extra javascript function.
The request input is now preserved exactly as-is and returned exactly as-was.
Additionally I have added tests to ensure that this behavior stays in sync.
The input model is now simply:
{
"method": "name", // or phone, boxNumber, etc.
"query": "ada lovelace", // actual query term
"population": "all", // or "students", "employees"
"length": "summary" // or "full"
}
This correlates 1:1 with the form, so we no longer have to coerce these two models.
Additionally:
- Removes unused check for "show_count"
- Fixes the "has_tag_with_text" to fix false positives (replacement is heavily documented)
-
- Fix regression that omitted uwnetid from rendering context during '/search [POST]'
- Added test for /search POST (the previous search only tried '/ [GET]')
- Fix autofocus relying on form name in order to work.
Remove the lifetime from stream profiles
The rationale for this is that this propagates explicit lifetimes for like half the API, in particular the ActivePipeline, which makes working with the data wonky. The initial motivation for this was to prevent users from holding onto a stream profile beyond the lifetime of the owning object (profile list or frame).
For frames, we can control this by never returning an owned profile, and instead just providing a reference. You probably shouldn't be using this profile much anyways outside of getting the data format for image frames.
For pipeline profiles, this is admittedly still a little wonky, but not too bad. We return a cached vector rather than an exact copy of every stream profile, even though because we generate the vector from a stream profile list we get a full set of owned sensor profiles now.
If you query the stream list from a sensor type however, you can get a fully owned vector of all stream profiles.
The final moral here is that we don't need the artificial phantom data +
explicit lifetime that was encoded into stream profiles before, instead
relying on actual ownership. It does mean whenever a stream profile is
constructed from a rs2_stream_profile_list (via try_create) we are
doing a clone of the data via the rs2 API. However, this just makes the
ownership semantics much easier to understand and requires less explicit
lifetime management, so I see it as a net-win across the API.
Side note: it seems strange to me that there is three ways to get this data. The RS2 API continues to confound and elude reason.
im a fucking idiot I was doing matrix math on cpu
The result of changing this is unironic tripling of framerate why am I so fucking stupid
Prow autobumper: support labels override as cmd arg
The problem we might run into while rolling back prow autobump PR, is that there is no existing autobump PR for oncall to put hold on for pausing prow auto deployment process. Since the autobumper runs every 6 hours, oncall might need to wait for 6 hours or wake up at exactly the time when autobumper runs next morning. As I can imagine this will be very annoying.
One way to solve this (The only way I can think about right now) is having autobumper job runs every hour, and only adds 'skip-review' label on 9:05 and 15:05 each day. Instead of wrangling this logic in autobumper code, I would perfer creating two separate prow jobs, one runs continuously without labeling, while the other runs 9:05 and 15:05 on week days and add label on PR. By going this approach, there should always be a new autobump PR created within an hour after rollback