2,953,743 events, 1,508,278 push events, 2,350,132 commit messages, 173,316,189 characters
Updating: 1/27/2021 1:00:00 AM
- Added: Product Management in Saas B2B Enterprise is easy (https://blog.luap.info/product-management-in-saas-b2b-enterprise-is-easy.html?reh=hn2)
- Added: Tools I Love to Not Think About (https://blog.tjll.net/tools-i-love-to-not-think-about/)
- Added: r/Damnthatsinteresting - Amazing... a capella group nails Windows sound effects (https://www.reddit.com/r/Damnthatsinteresting/comments/l5nwep/amazing_a_capella_group_nails_windows_sound/)
- Added: Saasify Key Takeaways (https://transitivebullsh.it/saasify-key-takeaways)
- Added: Wes Kao — How to instantly show your value (https://www.weskao.com/blog/how-to-instantly-show-your-value)
- Added: The fabrication of trust in various types of dollars (https://jpkoning.blogspot.com/2021/01/the-fabrication-of-trust-in-various.html)
- Added: Deep Dive into Many-to-Many: A Tour of EF Core 5.0 pt. 2 (https://channel9.msdn.com/Shows/On-NET/Deep-Dive-into-Many-to-Many-A-Tour-of-EF-Core-50-pt-2)
- Added: Working fewer hours and getting more done – Up There They Dev (https://www.uptheretheylove.com/blog/production/working-fewer-hours-and-getting-more-done/)
- Added: Was Social Media a Mistake? (https://christine.website/blog/social-media-mistake-2021-01-26)
- Added: The Spaghetti Code Conjecture (https://nickdrozd.github.io/2021/01/26/spaghetti-code-conjecture.html)
- Added: Twitter 'Industry' Bullshit (https://patwalls.com/twitter-industry-bullshit)
- Added: Federated development and federated forges – Loïc Dachary (https://blog.dachary.org/2021/01/23/federated-development-and-federated-forges/)
- Added: Bing (and Brave?) are squatting Goo*gle domains so I joined them (https://thomasvds.com/bing-and-brave-are-squatting-goo-gle-domains-so-i-joined-them/)
- Added: Why a paid Twitter won't work (https://jlelse.blog/thoughts/2021/01/paid-twitter)
- Added: Whew. We Got Iceland Teleworker Visas. – Brent Ozar (https://ozar.me/2021/01/whew-we-got-iceland-teleworker-visas/)
Generation took: 00:08:08.7980847
redux: Provide the global state to each sub-reducer.
There are a lot of places in our various reducers where to best do their job, they really want some data from elsewhere in our app state, outside the bit that that particular reducer maintains.
For example, several different reducers want to know when handling an
EVENT_NEW_MESSAGE whether the message was sent by the self user,
because they need to treat it differently in that case. We currently
accommodate this with a hack, where in eventToAction where we turn
the server event into a Redux action, we stick in an extra property
ownUserId that's selected straight off the current state.
We have similar hacks to provide state.caughtUp on the same event
for the sake of some other reducers, and to provide ownUserId or
state.messages on some other event actions. These hacks aren't
limited to actions for server events, either: we have ownUserId on
MESSAGE_FETCH_COMPLETE actions, too.
And then there's more places where we should be using information from elsewhere in the state but haven't been, and as a result doing far more computation than should be necessary to perform some tasks that ought to be very fast.
For example, when some messages get marked as read -- a very common
operation, sitting in the critical path for updating the "N unreads"
banner, which the user is probably noticing right at that moment --
the "unread" reducer has to sweep through its entire data structure
searching for the given message IDs so it can remove them. If there
are a lot of unreads, this can take hundreds of ms, which is
painfully long. What we should be doing there is to consult
state.messages, see exactly what conversation each message appears
in, and go straight to that part of the unreads data structure and
touch that and nothing else.
Why haven't we been better using the information available to us in places like that? One factor is that it's rather a pain to add one of these hacks. Another, probably, is that it's visibly a hack -- and perhaps even because we've felt that the Redux Way is to have each sub-reducer know nothing about the rest of the state and so there's something somehow wrong with doing so.
Well, that version of the Redux Way might be a good idea in situations where different sub-reducers are managing areas of data that are truly independent of each other, and benefit from being isolated. But as these examples show, many or most of our state subtrees are in reality closely interconnected. In particular they're full of IDs that refer to things in other subtrees -- messages, users, streams -- and they're naturally structured by facts about those things, facts which are maintained in those other subtrees. So let's put that idea to rest:
Our reducers often should use data from elsewhere in the state.
If you think one should, it probably should.
And, with this commit, let's start providing a non-hacky way for them to do that. (Or at least a less-hacky way.)
Each sub-reducer is now simply passed the global state as an argument. For the moment, they all just ignore it.
Converting any given sub-reducer to actually use that argument will be a bit of work, just because its tests will all need to be updated to pass it.
But then once that's done for any given sub-reducer, it can go on to inspect the state however it pleases, and use any part of the state that it needs to.
Split Invent into three tags
All this started when someone on Discord noticed that Import Inventory does not actually import changes, only additions and removals. However, its documentation clearly stated that it would patch 'additions, changes and removals'. So I took the opportunity to add that to PBash - but to preserve backwards compatibility, I obviously couldn't change the behavior of Invent.
So I decided to split the tag into three tags (Invent.Add, Invent.Change and Invent.Remove) and introduce an alias that interprets the old Invent tag as Invent.Add + Invent.Remove whenever it finds it in descriptions, LOOT tags and BashTags files. I also updated CBash to use the new tags, but didn't bother to try and make it understand Invent.Change. So CBash behaves exactly like before. One ugly wart here is the local imports in mods_metadata.py, but that file might as well be _mods_metadata.py for all the rethinking it deserves :P
This introduces a framework to allow us to easily support indefinite backwards-compatibility aliases for Bash Tags, so I went ahead and refactored the old InventOnly and C.GridFlags tag to use this system. Also documented all removed and deprecated tags in the Advanced Readme.
An eventual goal here is to investigate if we can refactor this new implementation of Import Inventory to create an abstract _AMerger, then rename _SimpleImporter to _APreserver and split importers.py into _cbash_importer.py, mergers.py and preservers.py.
Note the addition of MelObject.hash, noticed way too late that my set lookups wouldn't work. It's a bit hacky, but at least now any other set usages of MelObject that might be hiding in the patchers won't break anymore. Also dropped the weird 'removable' logic in there, was broken at first but after fixing it it became a noop.
Under #312
New data: 2021-01-26: DATA ARE CHANGING. SEE NOTES.
Imminent upcoming changes:
2021-01-25: Due to the limit on file sizes in GitHub, we will implementing changes to the dataset on Wednesday, January 27, 2021, mostly impacting individual-level data (cases and mortality). Changes below:
- Individual-level data (cases.csv and mortality.csv) will be moved to a new directory in the root directory entitled “individual_level”. These files will be 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” will also be moved into the “individual_level” directory.
- Redundant datasets will be 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 will be moved to the directory “other”.
We appreciate your patience and hope these changes cause minimal disruption. We do not anticipate making any other large scale updates 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.
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.
Recent changes:
- 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.
Revise historical data: cases (AB, BC, MB, ON, QC, SK); mortality (QC).
Many historical cases were removed from Grey-Bruce (ON) between 02-01-2021 to 23-01-2021. See below links for more details.
https://www.publichealthgreybruce.on.ca/Portals/0/Topics/InfectiousDiseases/COVID19/Changes_to_the_Situation_Report_Jan2021.pdf https://www.publichealthgreybruce.on.ca/Portals/0/Topics/InfectiousDiseases/COVID19/Situation%20Reports/January2021_Situation_Report.pdf
Note regarding deaths added in QC today: “The data also report 57 new deaths, but the total of deaths amounts to 9,577 due to the withdrawal of 1 death that the investigation has shown not to be attributable to COVID-19. Among these 57 deaths, 4 have occurred in the last 24 hours, 49 have occurred between January 19 and January 24, 3 have occurred before January 19 and 1 has occurred 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.
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.
ML3M Rebalancing
Originally, the ML3M was intended to be a little bit stronger. The healing values for the Brute, Burn, Omni, Toxin, and Antirad cells, have been adjusted according to what was initially planned. Base Tier's now heal 10 per shot, for a total of 40 damage healed, up from 20. Second Tier's now heal 20, instead of 10. Third Tier's heal 40, instead of 20.
Omni 1 heals 5's for brute, burn, and toxin, and 30 for oxy, up from half those values. Omni 2, is 10's and 60, and Omni 3 is 20's and 120.
Antirad Cell had its toxin heal bumped up from 2.5 to 5, and its radiation-heal from 150, to 350. I wasn't originally going to touch this one, but the text said "It's 150 because that's equal to five units of arithrazine", and... it wasn't. So, I bumped it up to actually be equal to 5u of Arithrazine's worth of radiation healing.
Stabilizer Cell, CorpseMend, Resistance, Haste, and the size-changing cells, were not touched. The reasons for this are as follows:
- The healing laser was simply not strong enough to ever tend to more than one patient. Healing 20-40 damage per cell just isn't enough, even if you had several clips full of cells, it just wasn't viable.
- As a result of this, it was seldom if ever used. Field Medics rarely if ever took it with them. In nearly every round I've played, it was left exactly where it was spawned, collecting dust.
- I'd like to make it a more proper treatment option. It wouldn't be equal to reagents used in your usual Medbay setting, or surgical repair, but if it's modified to actually fulfill its niche as a rapid, contact-free treatment option, it could be relied on more by Field Medics. There is so much potential for this device as an "in the field" healing tool, and I'd like to see it done well. We have no shortage of people who would like to see non-chemical-based treatment options. We might as well make it useful enough to actually use.
Here are a few issues people brought up in Discord when I floated this idea. "But, Tempest, you're doubling everything? That's a huge change! Won't this result in the ML3M overshadowing other treatment options?" Certainly not. Currently, with tier-2 cells that only heal up to 40 damage, this is actually worse than basic first-aid in terms of raw healing ability, as the cutoff for first aid healing is 50 damage on a limb. First aid and reagents will still be the most convenient, most readily available, and overall most-used manner of treatment for injuries that can be treated using those methods. All this change would do is allow the ML3M to also have its uses, and stop being overshadowed by everything else.
"Okay, but what if it DOES actually become The New Meta and becomes the favored tool for healing?" I wouldn't see it as an issue if Chemistry gets dethroned, in all honesty. They'd both take quite a bit of prep-work to use. You have to make multiples of every chem if you want a solid stock, and you'd need multiples of every cell if you want proper coverage and healing-ability, since even with these changes you're expending 1-3 cells per patient. And, unless you get multiple ML3M's made, only folks who are gonna have one are the CMO, and whoever nabs the spawned one first.
"But wouldn't this result in less departmental cooperation between Medical and Science now that Medical will require fewer cells?" Most likely, no. If anything, I'd think there would be an increase, round-to-round, if this becomes a more viable and wanted tool, more people will ask for cells. Personally, my list of requested cells would stay the same, but I'd be sending that request in more often since I know it'll actually be useful rather than having it just to have it. Tier 2 cells are still going to be desirable, and I'm still probably not going to order Tier 3's because of the cost, but that's just me. It's still going to be incredibly weak at roundstart, and better cells will be that much nicer to obtain.
"But Tempest! If you get the highest tiers of cells, and a lot of them, you could fix anything that doesn't require surgery!" Well, if Science had the time and mats, then sure, you could gather up a large enough collection of cells, and you probably could indeed do this for one or two badly injured patients... ... ...and I could accomplish the same goal if I'm given 20 seconds in a chem-lab. The ML3M is more costly to use, the cells cost resources, have to be recharged after 4 shots, and you only start with a base tier Burn, Brute, and Stabilizer cell. Each shot from a base level burn/brute cell is the equivalent of 1.25u of bicaridine or kelotane. This change would make it 2.5. Base level cells are still going to be next to useless for anything other than the most minor of injuries. Chemistry will still be the dominating powerhouse it always has been, but at least you can use this tool, provided the PR goes through, instead, more often.
"Tempest, this thing just wasn't intended to be used to fully heal people..." A couple people have said this, and to be honest, it's silly. In our medical system, there's very little distinction between what can "heal a little bit" and what can "heal fully", because it all comes down to the fact that everything works off of damage values. If Option A heals 5 damage, and Option B heals 50... Both are capable of "healing fully" if you have enough Option A, it's just a question as to whether or not that's practical. Currently, the ML3M's healing values can't really even be used to even partially heal injuries, unless you have a large number of cells. You'd expend all of your charges on one patient and then you've got a paperweight taking up storage space until you can get to a recharger.
Now, as for issues that I personally see? Biggest one is probably the Toxin cell. If I remlember correctly, the base Toxin cell is the same tech requirement as the Second Tier Brute/Burn cells. This PR doesn't fix that, and I don't really see it as a huge priority since I don't think anyone uses the toxin cells as it is, but yeah. Might need to be fixed at some point if this PR goes through.
And, absolute worst case scenario, let's say that this PR screws everything up, turns the Tether upside down, and now Medbay is dominated by a bunch of blue laser beams flying everywhere like it's the new Star Wars Trilogy (but actually better because those movies kinda set a low bar)... this PR was really easy to do. The only long part about it was typing all of this up. We can just bump the numbers down if this ends up sucking really bad, ezpz.
Thank you for coming to my ted talk.
test(pho): new big index ((1541))
Discussion: Before the massive disintegration of our big ball of work into separate patch/steps, we had a full new rewrite of “big index” that took in to account the hierarchical container type… But some time between finishing that and a few days ago, we realized that SSGs would need more from the big index to decide whether they can generate a markdown from them; and also something important (order) was missing by merely determining what the documents were in the collection.
During a run in fact, we developed this idea of the “document depth range”. If we were targeting sphinx, or some big book or something, we could have documents at different depths: “chapters” (say) might not just all be a flat list of documents: they might be broken up into sections and subsections and so on. (Also, we probably wouldn’t have the idea of “documents” so much as sections with automatic pagination, but ignore that for now.)
Axiomatically, we say that if you’re holding a node and that node is a document; then it has a document depth of zero. (The number acts sort of like an offset in an array: If i’m at the current document, how much depth do I have to add to get down to a document? In the case when you’re already at a document, the amount is zero.)
So if you were holding a “chapter” node, and that chapter was just a flat list of documents, the document depth would be one.
If the chapter was broken up in to sections (but not subsections); the document depth would be two, and so on, but we don’t just stop there: It’s entirely common for some sections to have sub-sections (and maybe sub-sub sections and so on) but not others. This is where we derive the idea of a document depth range. (We call it a “minmax” in the code, out of deference to RPG videogames.)
We’re going to dump more documentation sketches her that we decided not to fold into the main body documentation. But before we do, we want to mention that we spent a whole day just on writing the pseudocode for this, this one local maxima of a mountain, then a full few hours writing the new asset (a second rewrite (the first never to be committed)), and a full day on tests, and one test in particular realized a gaping hole in our algorithm (explained in a case) which we then covered in asset.
As for the data model and the big index narrative:
We think what happened was, in the original data model, the only thing
we knew we wanted for sure at first was that notecards had a prev and
a next (to accord with the rough GUI sketch in the README).
Although internally we could have modeled this as only a singly-linked list and derived the other relationship from the one (e.g. determine every "next" by seeing every "previous"), this would have required either some on-disk derived index or taking a big index of the collection on every read of one entity; both of which are not KISS-compatible.
As such, every entity has both a prev and next field.
One the GUI matured, the time came to allow entities to have parent
child relationships. At first, it seems, there was no children field,
just parent, because somewhere at one point there was this idea
that children did not have a sense of order intrinsic in the model.
But the main point is, children do have order in the datastore,
but still we have a prev/next coexisting with parent/child in
a way we never really understood until this last swath of work:
The short of it is, the two associations are redundant but we take
steps to enforce that you only use one or the other or a particular
combination of both.
In the New Way, big-indexing is still mainly to answer the question "what are all the documents in this collection?" but it has gotten more powerful and complicated: documents now get their order and structural relationship from the notecard relationships just like was always intended. Documents can be deeply nested within what we call a "node tree". (We may call it a "document tree" if it has documents in it.) Probably the only rule here (beyond basic data integrity stuff around ordered trees, no cycles and so on) IS, you can't put a document inside another document. Otherwise you have freedom (for now) to nest documents arbitrarily deeply within “document nodes” and then (for now, and/or sort of) you can nest nodes arbitrarily deeply within documents. (There is a hard-coded limit of 6 somewhere for good reason, but in theory we could go deeper.)
So for example you may group your documents in to chapters but also break each chapter in to sections and so on. You may decide you want sub-sections and so on. There are no rules here with how deep your hierarchy goes, or whether the depth needs to be consistent across the collection or otherwise.
Finally, it’s the SSG adapter that gets to decide whether they can handle any given document tree with some given document depth range…
(times) 01-24 09:05 begin think about requirements for new big index and what test cases 11:47 done editing and rewriting and re-housing documentation. begin to write one massive god case 12:06 finished very rough sketch of all our tests in 1 big case 13:53 we have the old new index working on the big crazy new fake graph and it's amazing. now we have to make the new new big index 01-25 21:27 making the big index of the single node tree was so satisfying we flung off in to space and went running 21:45 start big index of whole collection 23:29 ok wow the big index of the whole collection passed rough draft except we aren't exercising built hash 01-26 22:33 begin assemble commit .
Updates for: Doubt is a pain too lonely to know that faith is his twin brother. -- Kahlil Gibran
Day 07 + Exercises
This was a pain in the ass, the exercises some were to think a bit or learn new things outside scope, but a fuck ton of exercises...
Fix 2tap2wake after Ambient Pulsing on some devices
like taimen and walleye, instead sunfish (and probably newer pixels) doesn't need this
To apply, override the config_has_weird_dt_sensor bool in the device tree
TL;DR for some reason, on taimen and walleye, after ambient pulsing gets triggered by adb with the official "com.android.systemui.doze.pulse" intent or by our custom "wake to ambient" features, the double tap sensor dies if you follow this steps:
- screen is OFF
- trigger ambient pulsing with a double tap to wake (if custom wake to ambient feature is enabled), or the official intent by adb, or with music ticker or any other event
- after ambient display shows up, don't touch anything and wait till the screen goes OFF again
- double tap to wake, again
- the double tap sensor doesn't work at all and device doesn't wake up
Now, funny thing, after the steps above, if you cover then uncover the proximity/brightness sensor with the hand, then double tap to wake again, the wake gesture works as expected.
When covering/uncovering the proximity/brightness sensor, this happens: 11-10 22:02:00.916 967 998 I ASH : @ 1993.460: ftm4_disable_sensor: disabling sensor [double-tap] 11-10 22:02:02.013 967 998 I ASH : @ 1994.556: ftm4_enable_sensor: enabling sensor [double-tap]
When you switch screen ON with power button, the doze screen states do the same: the sensor gets disabled then enabled again if device goes to DOZE idle state.
Instead, after Ambient pulsing, when the pulsing finishes, the sensor is still enabled, so the disable/enable event doesn't happen this time. And that's why, for some reason, it doesn't respond anymore.
So, in a nutshell: i've no idea why this sh#t happens lol, but with a super lazy hacky tricky dirty bloody nooby line change, we can force the sensor disable/enable event when the device goes to DOZE state.
Change-Id: I8ce463a6e435e540e3ca93336c5dba7a95771b56 Signed-off-by: Joey Huab [email protected] Signed-off-by: Zaviyar786 [email protected]
My Work Progress Profile
I, Mohammad Obaedul Islam, am better known as Obaedul Islam. I am a professional Web Developer at Fiverr & Upwork market place. I have experience working in the IT industry like Computer Programming, Computer Networking, Hardware, Office Application. I have a considerable amount of expertise in those sectors.
I am passionate to take myself higher in this field. I love this profession because this is a sector which has its own standard. I had a dream since my childhood to do work in a smart way & smart things in the future and that's why I choose this profession. My success lies in the fact that I am motivated by a passion for my work and an unquenchable desire to be at the top.
I have been completed my 'Web Developing" training from "LICT & Shikhbe Shobay" also completed my "SEO" training from 'Basis Institute of Technology & Management' Under a Government Project Named 'Skills for Employment Investment Program (SEIP)'. I always try to work smartly.
Recently I completed my graduation. I'm a student of Computer Science & Engineering department at Daffodil International University. I smartly handle my study by keeping full concentration on my work and research.
Being a web developer I am working at the best freelancing platforms like Upwork and Fiverr. I thoroughly enjoy working with new and expert clients from various countries like the USA, UK, Australia, Canada, Dubai, and so on. This ever-changing field of work motivates me to be up to date. Therefore, most of my works display the latest trend and technology.
I believe with my expertise, continuous learning, hard work and true passion for this vast and ever-changing IT sector, I would be able to positively contribute to this area .
Implement a noop version of init_app_links
We need to rethink app launchers. Shortcuts make no sense on non-Windows systems, plus they keep confusing users (and to top it all off, their code is ugly). Remember how many people have trouble getting a shortcut for xEdit cleaning to work.
Instead, I think a more usable solution is using our settings dialog to implement a page where you can add custom launchers (along with some default ones that we auto-detect, most likely). We can then even generalize concepts like the special links that the BOSS launcher has by allowing users to add right click options that will enable or disable custom CLI flags. And a toggle on each link to suspend Lock Load Order while the app is running, etc.
Includes today's "speed" run. I was not able to run very fast due to ...
... lingering issues from my fall on Saturday. My right ankle is still slightly tender and slightly swollen. There's no discoloration or instability.
Yesterday I had to walk the final mile or so back home due to a very uncomfortable shin splint in my right leg. Well, that discomfort continued through the night, but not enough to keep me awake too much, nor did I take any analgesics last night, but I did take 200mg ibuprofen with my pre-run oatmeal this morning and even with that and three double espressos, my body still wanted me to take it easy, which is why primarily why I was so slow.
There was one more contributing factor and that was it was 14.2F when I started and 28.0F when I finished. As such, I started by wearing my fleece hat, arm warmers and bike gloves with heating pads in them. That meant as I warmed up I had to roll down the sleeves and pop the hat off and several times I had to futz around with my water bottles, because the caddies rely on tension to not fall off and heavy gloves complicate that.
I'm glad I went out and ran today. I was certainly nervous yesterday, last night and this morning before I started. I have two more recovery days before my second 24 mile ruck run on Saturday. I don't know that I'll do as well as my previous 24 mile ruck run, but I don't think I'll backslide too much.
Basic Twitter Design
Takes input from the console from the users and then create a list of hashtags and maintain a global map for it. After taking the input, it displays the top 10 hashtags in the system.
For eg: tweets are as follows: Sachin is best player in the world. #Sachin #India #GOAT Happy #India Republic Day Virat Kohli, you beauty #ICC #India #GOAT You find out at 12:30 in the night that you'll be sharing the dressing room with Virat Kohli and AB de Villiers. How would you sleep after that?#PlayBold #WeAreChallengers The #IPLAuction Is Scheduled To Take Place On 18th February, 2021 In Chennai! Which Players Do You Wish To See #PlayBold For RCB Under Virat Kohli's Captaincy This Time? Thinking face #one8blends - Your secret to confidence. Get the perfect boost of confidence with #one8fragrances RIP Diego Maradona. He changed the way the beautiful game of football is played. True genius. #Maradona
Output: Top 10 HashTags******** India==============> 3 GOAT==============> 2 one8fragrances==============> 1 one8blends==============> 1 WeAreChallengers==============> 1 Sachin==============> 1 PlayBold==============> 1 Maradona==============> 1 IPLAuction==============> 1 ICC==============> 1
Remove MessageEntity::text_from because it's wrong
(the method assumes UTF-8 indices, but the indices are UTF-16) (fuck you, telegram)
SUMMARY analytics api generative-art biology books payroll startups venture-capital cli serverless-computing llvm computer-vision image-processing metal compression formal-verification consciousness ethereum databases neo4j postgresql color design-inspiration design fonts user-experience distributed-systems drugs finance rules css-in-js future chess gamedev games spatial-analysis gpu recipes keyboards knowledge-graphs latex happiness macOS-apps artificial-intelligence ml-libraries pytorch reinforcement-learning product-management lambda-calculus math ambient guitar music-production synthesizers http matrix microservices networking speech-synthesis github containers kubernetes watchos linux newsletters electrical-engineering c qt phoenix erlang go-libraries go js-libraries vue lisp programming-languages django python-libraries r rails rust-libraries rust swift-libraries documentation encoding jupyter-notebooks json logging programming protocol-buffers cypress fuzzing stream-processing git zero-knowledge-proofs social-networks space japan russia shell virtual-reality deno nodejs webassembly communication consultancies hiring
Add message passing system call to the kernel
The kernel now supports message passing. Short of a few tweaks to make things better, we should be good to go.
Here's the problem: true character-based message passing is FRICKIN AWFUL to work with. The invocation is unwieldly and it is especially painful in a bootstrap environment where we only have the text section. As a result of this fact, everything I just did is possibly subject to rework.
In conclusion, this sucks. MINIX memory grants seem like a good direction to go in terms of passing around thicc information bufs; where the kernel sets something up at the tail of process address spaces and allows read/writes. These don't necessarily need to be mediated, either -- we can do this kinda like p9's rendezvous:
-> process A wants to talk to process B and B wants to hear from A -> process A calls compose(to, len), which allocates the buffer to go to some process B. this is all set up and nice inside kernelmode. -> process B calls receivebuf(from), which blocks until writing is complete. it maps in more pages on the first invocation, starting DMA. -> you can call sendbuf/receivebuf repeatedly now to ping pong blocking messages but it's DMA so no overhead now besides the brief kernel crossing to alert the other process you're ready
Signed-off-by: Jay Lang [email protected]
Added prebuild actions + a license file
Do whatever the fuck you want with my code
Global Refactor: Remove fragments and introduce custem elements
My hacky fragment wrapper was fundamentally broken and would have had to go later on anyways [1]. Rather than just removing fragments and turning previous fragments into divs I opted to pull in custom elements - they're just fancy divs. This led to that and here we are - a lot changed.
- hook objects have been replaced with classes. I need to extend HTMLElement for custom elements at some point and there's no value in hiding that from the user
- Moving global variables $update, $path & $query into the global $ felt right
now that it really can be used as the global state as local state can now be
represented with the
thisof the enclosing component. Also properties was exhausting to write - props is just as expressive and shorter. With props comes slot for the children. Taken from what custom elements with shadow dom call those - By pulling out most of the component setup code into the runtime we have less hard to debug and maintain generated code.
- Removed dynamic node tags for now because I'm not even sure I want them (I just wanted to keep that option - but I haven't used it yet) and they add quite a bit of complexity. Also they're not tested and I'm too lazy to write tests right now.
Notably, this commit does not introduce shadow dom. I experimented with that but ended up deciding against it due to the huge amount of complexity they entail.
- query selector breaks because every component instance is their own document. integration tests become annoying because of that - there's no tooling in the stdlib and you have to build something out of treewalker. Not that much code (shitty and wrong but good enough for tests is <20LOC) but made me feel wrong.
- Complete isolation means components do not inherit styles from their parent - but that's exactly what I want. I want some shared styles (e.g. css reset) and styles scoped to the component. I explicitly want scope inheritance; The thing that sucks about css to me is not inheritance, it's the lack of (nested) scopes. Shadow DOM means we have to clone every stylesheet we want in the component into it. That just didn't feel right to me.
I probably missed a lot, but I'm not in the mood to write more. I wish commit messages were editable without rewriting all history. Something as close to the code as commit messages but more like a wiki... Anyways.
[1] My hacky fragment wrapper only worked for create - it didn't handle any
modifications (i.e. update). If nodes changed, (re)moving the fragment only
moved the nodes that already existed at create - because any append would
happen on the current parent (i.e. a descendant of the document) and not the
document fragment.
I decided on removing the complexity of fragments rather than fixing the bugs
because (1) what I thought needed fragments for is actually achievable with
display: contents in 2020 (afaict) and (2) I wanted to add custom element
goodness (remove hook, scoped css, ???) in any case and just put it off because
I couldn't think of how to integrate it with fragments.
Chem rework mk5, the unga strikes back (#4813)
- Chemical additions
Initial add of 2 chemicals, QC+ and Larvaway.
QC+ is highly toxic and stuns, but heals IB very, very rapidly.
Metabolism rate 0.5u/tick, intended dose 5u, OD 6u, crit OD 10u. Healrate will be 2.5/tick, for a total of 25 pts of IB healed/dose, additional if OD'd (next commit). That's the good stuff.
The bad stuff is that it gives you 5u of toxins/tick, AND takes 15 stamina/tick, AND maxes out your pain. Give with antitox and it's 100% safe, but you'll still go down for about 20 seconds.
OD deals 3 toxin/tick and some minor bloodloss. Crit OD deals hilariously high bloodloss. Maybe don't clot all your blood at once?
Larvaway is moderately toxic, and can cause stamina issues, but delays larva growth by 50% or so (next commit). Over time, it will become lethal.
Metabolism of 0.1u/tick, design dose 10u (200 seconds). OD's at 15u, crit OD at 25u. The first 10u cause 0.5 toxin damage/tick with a 25% chance of 0.5 staminaloss/tick. The second 10u cause 1 toxin damage/tick with a 25% chance of 20 staminaloss/tick. Anything after 20u is processed causes 3 toxin/tick (but no staminaloss, yay?)
Co-authored-by: TiviPlus [email protected]