3,222,992 events, 1,619,590 push events, 2,502,381 commit messages, 191,711,164 characters
New data: 2021-03-22. See data notes.
Revise historical data: cases (BC, MB, ON).
Note regarding deaths added in QC today: “15 new deaths, for a total of 10,614 deaths: 3 deaths in the last 24 hours, 9 deaths between March 15 and March 20, 3 deaths before March 15.” 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.
Trial balloon for dragging windows, I remembered that the ncurses in MacOS is too old to support click-drag operations, but at least the infrastructure to drag is in place (currently, the code to start the dragging is not activated, behind Application.grabMouse in the Window handler, and the grabbed property that tracks the state).
MouseEvent: track the absolute position, rather than passing that delta, that made no sense. No idea why I thought that was useful.
After a window has changed its layout, ensure we flag it for redisplay, this solves a problem when dragging windows that was not redrawing obscured ones.
AttributedString convenience method to turn into a string.
New Label implementation that uses AttributedStrings, the old one is there just for a couple of helper methods that I should move later. The text property is just a proxy to attributedText
Dim: convenience operator functions
Label: auto-sizes Button: auto-sizes
MouseFlags: OptionSet is ridiculous, it should just render the text like C# does, this is primitive
Painter: the visible needs to use the frame, otherwise, we do not draw on nested dialogs.
View.set: convenience method to set x, y, w, h from integers.
View.fill: with percentage, that works for the dimensions, but fails for the positions, should investigate.
Window: allow for a few buttons to be displayed (minimize, maximize, close) and wire up the mouse to these.
Dialog: use the close functionality from Window
FileDialog: some work started on the file dialogs.
Button: convenience constructor, and fix the hotkey rendering
ListView: some list view work.
TextField: move to the same event callback, in addition to supporting Combine
The example program was getting busy, so split it up, so I get some more room to try things out.
Update Readme.md
"Commit!" - shouted he with a quizzical accent of a stereotypical Asian man. Like that wail was one of the mandatory Kiai he had to bellow in front of a judge panel as part of a step toward his next belt in Kyokushin Karate. But there was no judge panel, for it was the second year of a pandemic, and the only mastery rank that cry earned him was that of an utter, committed degenerate. Who still fucking sucked at JavaScript, mind you.
eat the poor
changed prices for fines, fuck you peasant.
Merge pull request #49 from AlignSD/evan
i hate my life
starting move parsing requests into erlang
Fuck you, parsing of c-format string with variable count of parameters.
[lit] Reliable progress indicator and ETA
Quality of progress bar and ETA in lit has always bothered me.
For example, given ./bin/llvm-lit /repositories/llvm-project/clang/test/CodeGen* -sv
at 1%, it says it will take 10 more minutes,
at 25%, it says it will take 1.25 more minutes,
at 50%, it says it will take 30 more seconds,
and in the end finishes with Testing Time: 39.49s
. That's rather wildly unprecise.
Currently, it assumes that every single test will take the same amount of time to run on average. This is is a somewhat reasonable approximation overall, but it is quite clearly imprecise, especially in the beginning.
But, we can do better now, after D98179! We now know how long the tests took to run last time. So we can build a better ETA predictor, by accumulating the time spent already, the time that will be spent on the tests for which we know the previous time, and for the test for which we don't have previous time, again use the average time over the tests for which we know current or previous run time. It would be better to use median, but i'm wary of the cost that may incur.
Now, on first run of ./bin/llvm-lit /repositories/llvm-project/clang/test/CodeGen* -sv
at 10%, it says it will take 30 seconds,
at 25%, it says it will take 50 more seconds,
at 50%, it says it will take 27 more seconds,
and in the end finishes with Testing Time: 41.64s
. That's pretty reasonable.
And on second run of ./bin/llvm-lit /repositories/llvm-project/clang/test/CodeGen* -sv
at 1%, it says it will take 1 minutes,
at 25%, it says it will take 30 more seconds,
at 50%, it says it will take 19 more seconds,
and in the end finishes with Testing Time: 39.49s
. That's amazing i think!
I think people will love this :)
Reviewed By: yln
Differential Revision: https://reviews.llvm.org/D99073
fmtowns_cd.xml: 13 new dumps, 12 replacements, 5 missing floppies added (#7874)
- Added the missing floppy image to OASYS/Win 2.0 (still not working due to lack of DD floppy support). [cyo.the.vile]
- Replaced the psydet5 and psydetf1 floppy images with cleaner unmodified copies. [cherokee]
Alice no Yakata 3 (1995-05-16) [redump.org] Battle [redump.org] Ehon Writer V1.1 L10 [redump.org] Half Moon ni Kawaru made - Ramiya Ryou no Nijiiro Tamatebako [redump.org, wiggy2k] Never Land [redump.org] Oto to E no Deru Eigo Jisho No. 2 - English in Dream [redump.org] Populous II - Trials of the Olympian Gods - Expert [redump.org] Running Girls - Hashiri Onna II + Rance 4.1 / 4.2 Hint Disk [redump.org] Soreike! Anpanman - Tanoshii Eigo Asobi [redump.org] Toshiyuki Yoshino - Lullaby of BirdLand [redump.org] True Heart (alt) [redump.org] Viper GTS [redump.org]
Scavenger 4 (HME-217B) [redump.org]
Hanafuda de Pon! [redump.org] Indiana Jones and the Fate of Atlantis [redump.org] King's Quest V - Absence Makes the Heart Go Yonder [redump.org] Kyan Kyan Collection - Daifugouhen [redump.org] Kyuukyoku Tiger [redump.org] Legends of Valour - Gouyuu no Densetsu [redump.org] Life & Death II - The Brain [redump.org] Menzoberranzan - Yami no Monshou [redump.org] Oshiete Noobow [redump.org] Princess Danger [redump.org] Scavenger 4 (HME-217A) [redump.org] Wrestle Angels Special [redump.org]
Nobunaga no Yabou - Sengoku Gun'yuuden [cherokee] Windows 3.1 L11 [cyo.the.vile]
sched/core: Fix ttwu() race
Paul reported rcutorture occasionally hitting a NULL deref:
sched_ttwu_pending() ttwu_do_wakeup() check_preempt_curr() := check_preempt_wakeup() find_matching_se() is_same_group() if (se->cfs_rq == pse->cfs_rq) <-- BOOM
Debugging showed that this only appears to happen when we take the new code-path from commit:
2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is descheduling")
and only when @cpu == smp_processor_id(). Something which should not be possible, because p->on_cpu can only be true for remote tasks. Similarly, without the new code-path from commit:
c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu")
this would've unconditionally hit:
smp_cond_load_acquire(&p->on_cpu, !VAL);
and if: 'cpu == smp_processor_id() && p->on_cpu' is possible, this would result in an instant live-lock (with IRQs disabled), something that hasn't been reported.
The NULL deref can be explained however if the task_cpu(p) load at the beginning of try_to_wake_up() returns an old value, and this old value happens to be smp_processor_id(). Further assume that the p->on_cpu load accurately returns 1, it really is still running, just not here.
Then, when we enqueue the task locally, we can crash in exactly the observed manner because p->se.cfs_rq != rq->cfs_rq, because p's cfs_rq is from the wrong CPU, therefore we'll iterate into the non-existant parents and NULL deref.
The closest semi-plausible scenario I've managed to contrive is somewhat elaborate (then again, actual reproduction takes many CPU hours of rcutorture, so it can't be anything obvious):
X->cpu = 1
rq(1)->curr = X
CPU0 CPU1 CPU2
// switch away from X
LOCK rq(1)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 9
switch_to(Z)
X->on_cpu = 0
UNLOCK rq(1)->lock
// migrate X to cpu 0
LOCK rq(1)->lock
dequeue_task(X)
set_task_cpu(X, 0)
X->cpu = 0
UNLOCK rq(1)->lock
LOCK rq(0)->lock
enqueue_task(X)
X->on_rq = 1
UNLOCK rq(0)->lock
// switch to X
LOCK rq(0)->lock
smp_mb__after_spinlock
switch_to(X)
X->on_cpu = 1
UNLOCK rq(0)->lock
// X goes sleep
X->state = TASK_UNINTERRUPTIBLE
smp_mb(); // wake X
ttwu()
LOCK X->pi_lock
smp_mb__after_spinlock
if (p->state)
cpu = X->cpu; // =? 1
smp_rmb()
// X calls schedule()
LOCK rq(0)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 0
if (p->on_rq)
smp_rmb();
if (p->on_cpu && ttwu_queue_wakelist(..)) [*]
smp_cond_load_acquire(&p->on_cpu, !VAL)
cpu = select_task_rq(X, X->wake_cpu, ...)
if (X->cpu != cpu)
switch_to(Y)
X->on_cpu = 0
UNLOCK rq(0)->lock
However I'm having trouble convincing myself that's actually possible on x86_64 -- after all, every LOCK implies an smp_mb() there, so if ttwu observes ->state != RUNNING, it must also observe ->cpu != 1.
(Most of the previous ttwu() races were found on very large PowerPC)
Nevertheless, this fully explains the observed failure case.
Fix it by ordering the task_cpu(p) load after the p->on_cpu load, which is easy since nothing actually uses @cpu before this.
Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") Reported-by: Paul E. McKenney [email protected] Tested-by: Paul E. McKenney [email protected] Signed-off-by: Peter Zijlstra (Intel) [email protected] Signed-off-by: Ingo Molnar [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: atndko [email protected]
"10:30am. I should not have stayed up reading Reverend Insanity until 1am. At any rate, I am finally up. Let me chill a bit and I will start.
Today my schedule involves more playing around with Kivy. The first thing I want to do is investigate just what the hell is going on with that slider.
Also, I said yesterday that fill does not matter, but it does. I want to do a back button. How will I do that without filled triangles? Also I want to draw card icon - spade, diamond, heart and club using line instructions and fill it.
10:50am. Let me start. Since I got up late today, I am behind schedule. Let me figure out what the hell is going on with that slider.
root = Builder.load_string('''
BoxLayout:
orientation: 'vertical'
Slider:
size_hint_y: 0.2
min: 0
max: 360
value: 0
FloatLayout
Button:
size_hint_y: None
text: 'x'
''')
Putting an empty float layout helps with stabilizing it. In the previous example, because the Button did not use the size hint, that cause the slider to take up the entirety of the space.
Slider:
size_hint_y: 0.1
min: 0
max: 360
value: 0
This way of doing things is so awkward though. Can it just take up the space it needs, but not any more?
I need to study this more!
I spent an entire day on this yesterday, but I still haven't internalized all that I wanted.
11am. Focus me. What do I do next.
BoxLayout:
orientation: 'vertical'
Slider:
size_hint_y: 0.1
min: 0
max: 360
value: 0
FloatLayout:
canvas:
Color:
rgba: 1,0,0,1
Rectangle:
pos: 0,0
size: 100,100
# Triangle:
# points: 0,0,50,50,100,100
Button:
size_hint_y: None
text: 'x'
Damn it, the triangle is doing nothing, and to make things worse, the Rectangle is not drawing inside the bounds of the FloatLayout.
This is problematic. Let me go through the examples.
Triangle:
points: 0,0,50,50,100,0
Ah, wait this works! I fucked up an made the triangle completely flat.
Triangle:
points: 100,100,50,150,100,200
Here is my back button. To draw card icons, I'll have to get familiar with all sorts of curves though.
It really bothers me that I have no idea what most of this is.
This is the only option for the triangle. No line thickness or roundedness?
You can do that the easy way and the hard way. The easy way is using StencilView as a widget, which has a nice demo.
https://kivy.org/doc/stable/api-kivy.uix.stencilview.html
StencilView limits the drawing of child widgets to the StencilView’s bounding box. Any drawing outside the bounding box will be clipped (trashed).
10:25am.
BoxLayout:
orientation: 'vertical'
Slider:
size_hint_y: 0.1
min: 0
max: 360
value: 0
FloatLayout:
canvas:
PushMatrix
Translate:
xy: self.x, self.y
Scale:
scale: 3
Color:
rgba: 1,0,0,1
Triangle:
points: 50,0,0,50,50,100
PopMatrix
Button:
size_hint_y: None
height: 150
text: 'x'
This works. Let me try the StencilView.
StencilView:
canvas:
PushMatrix
Translate:
xy: self.pos
Scale:
scale: 5
Color:
rgba: 1,0,0,1
Triangle:
points: 50,0,0,50,50,100
PopMatrix
Oh, this indeed clips it when it goes beyond its boundary.
11:35am.
from kivy.app import runTouchApp
from kivy.lang.builder import Builder
root = Builder.load_string('''
BoxLayout:
orientation: 'vertical'
Slider:
id: slider
size_hint_y: 0.1
min: 0.1
max: 10
value: 0.5
StencilView:
canvas:
PushMatrix
Translate:
xy: self.pos
Scale:
xyz: slider.value,slider.value,slider.value
Color:
rgba: 1,0,0,1
Triangle:
points: 50,0,0,50,50,100
PopMatrix
Button:
size_hint_y: None
height: 150
text: 'x'
''')
if __name__ == '__main__': runTouchApp(root)
Ok, I get it.
It is slow, but this is the general way one attains expertise. Getting from 1 to 2 out 5 is actually a fairly smooth journey as long you apply yourself. 3 to 5 is all about abstraction, but 1 to 2 is all about knowledge.
What should I do next? I can do a back button now. I definitely understand a bunch of things now that I hadn't before. But overall, my understanding of graphics is still quite low.
I would not put myself at even 2/5 yet.
11:40am. A few days ago I skimmed the processing tuts, but now that I see there is a lot of overlap between UI work and graphics, I am more motivated to dive deeper into it.
Actually, I had not realized this connection at all while studying Avalonia. With Avalonia I carefully restricted myself to what is available, but now with Kivy I am using the canvas, so my experience is like day and night compared to that time.
11:45am. I am trying to maximize my creativity here.
Right now on the side I am thinking how I would do UIs using Rx and my conclussion is that Python is a massive pain in the ass.
Oh, it takes in the mapper and the comparer.
...Ok, since it allow passing in the comparer, I'll be able to squeeze in using the structural equality that Spiral already has. I was worried about this.
11:50am. I want to go forward with Processing. Right now is the ideal time to study it. After I get familiar with its concepts I'll transfer them to Kivy and can get it on with making the UIs.
Right now, for the first time in my life, the question of data flow and organization is not the problem. Those last two are what will allow me to do in a 100 lines what would have otherwise taken 1000. But I still need basic familiarity with graphics and layouting to make the UI in the first place.
Let me get processing and I will go through the tuts while following the examples.
If I have to pick between Java and Python, I'd pick the later. Performance does not matter for me here either.
12pm. https://medium.com/processing-foundation/a-modern-prometheus-59aed94abe85
A Processing program is called a sketch. This is more than a change in nomenclature, it’s a different approach to coding. The more traditional method is to resolve the entire plan for the software before the first line of code is written. This approach can work well for well-defined domains, but when the goal is exploration and invention, it prematurely cuts off possible outcomes. Through sketching with code, unexpected paths are discovered and followed. Unique outcomes often emerge through the process.
Yes, this is what I must learn with Python. I must learn to learn to move faster when it comes to sketching out UIs. I am not always working with software that takes me weeks to code up.
12:10pm. Let me stop here so I can have breakfast.
Forget about going fast. It seems that the next few weeks are going to be the complete opposite of the tension of the past few. I can take a break from Spiral for a bit."
I found that a 4pm or other non midnight required buffering. (#16182)
- Update history_stats.markdown
title: History Stats description: Instructions about how to integrate historical statistics into Home Assistant. ha_category:
- Utility
- Sensor ha_iot_class: Local Polling ha_release: 0.39 ha_quality_scale: internal ha_domain: history_stats
The history_stats
sensor platform provides quick statistics about another integration or platforms, using data from the history
integration.
It can track how long the integration has been in a specific state, in a custom time period.
Examples of what you can track:
- How long you were at home this week
- How long the lights were ON yesterday
- How long you watched TV today
To enable the history statistics sensor, add the following lines to your configuration.yaml
:
{% raw %}
# Example configuration.yaml entry
sensor:
- platform: history_stats
name: Lamp ON today
entity_id: light.my_lamp
state: 'on'
type: time
start: '{{ now().replace(hour=0, minute=0, second=0) }}'
end: '{{ now() }}'
{% endraw %}
{% configuration %}
entity_id:
description: The entity you want to track.
required: true
type: string
state:
description: The states you want to track.
required: true
type: [list, string]
name:
description: Name displayed on the frontend. Note that it is used by Home Assistant to generate sensor's object_id
so it is advisable to choose a unique one and change name for frontend using customization or via Lovelace.
required: false
default: unnamed statistics
type: string
type:
description: "The type of sensor: time
, ratio
, or count
."
required: false
default: time
type: string
start:
description: When to start the measure (timestamp or datetime).
required: false
type: template
end:
description: When to stop the measure (timestamp or datetime).
required: false
type: template
duration:
description: Duration of the measure.
required: false
type: time
{% endconfiguration %}
You have to provide exactly 2 of start
, end
and duration
.
You can use template extensions such as now()
or as_timestamp()
to handle dynamic dates, as shown in the examples below.
Depending on the sensor type you choose, the history_stats
integration can show different values:
- time: The default value, which is the tracked time, in hours
- ratio: The tracked time divided by the length of your period, as a percentage
- count: How many times the integration you track was changed to the state you track
The history_stats
integration will execute a measure within a precise time period. You should always provide 2 of the following :
- When the period starts (
start
variable) - When the period ends (
end
variable) - How long is the period (
duration
variable)
As start
and end
variables can be either datetimes or timestamps, you can configure almost any period you want.
The duration variable is used when the time period is fixed. Different syntaxes for the duration are supported, as shown below.
# 6 hours
duration: 06:00
# 1 minute, 30 seconds
duration: 00:01:30
# 2 hours and 30 minutes
duration:
# supports seconds, minutes, hours, days
hours: 2
minutes: 30
If the duration exceeds the number of days of history stored by the recorder
component (purge_keep_days
), the history statistics sensor will not have all the information it needs to look at the entire duration. For example, if purge_keep_days
is set to 7, a history statistics sensor with a duration of 30 days will only report a value based on the last 7 days of history.
Here are some examples of periods you could work with, and what to write in your configuration.yaml
:
Today: starts at 00:00 of the current day and ends right now.
{% raw %}
start: '{{ now().replace(hour=0, minute=0, second=0) }}'
end: '{{ now() }}'
{% endraw %}
Yesterday: ends today at 00:00, lasts 24 hours.
{% raw %}
end: '{{ now().replace(hour=0, minute=0, second=0) }}'
duration:
hours: 24
{% endraw %}
This morning (6AM - 11AM): starts today at 6, lasts 5 hours.
{% raw %}
start: '{{ now().replace(hour=6, minute=0, second=0) }}'
duration:
hours: 5
{% endraw %}
Current week: starts last Monday at 00:00, ends right now.
Here, last Monday is today as a timestamp, minus 86400 times the current weekday (86400 is the number of seconds in one day, the weekday is 0 on Monday, 6 on Sunday).
{% raw %}
start: '{{ as_timestamp( now().replace(hour=0, minute=0, second=0) ) - now().weekday() * 86400 }}'
end: '{{ now() }}'
{% endraw %}
**Next 4pm **: ends today at 00:00, lasts 30 days. Easy one.
{% raw %}
end: '{{ now().replace(hour=0, minute=0, second=0) }}'
duration:
days: 30
{% endraw %}
Last 30 days: ends today at 00:00, lasts 30 days. Easy one.
{% raw %}
end: '{{ now().replace(hour=0, minute=0, second=0) }}'
duration:
days: 30
{% endraw %}
** 4PM always in the future**: ends in the future at 16:00, starts 24 hours before.
{% raw %}
end: '{{ (now().replace(minute=0,second=0) + timedelta(hours=8)).replace(hour=16) }}'
duration:
hours: 24
{% endraw %}
All your history starts at timestamp = 0, and ends right now.
{% raw %}
start: '{{ 0 }}'
end: '{{ now() }}'
{% endraw %}
The /developer-tools/template
page of your Home Assistant UI can help you check if the values for start
, end
or duration
are correct. If you want to check if your period is right, just click on your component, the from
and to
attributes will show the start and end of the period, nicely formatted.
-
$pm - 4pm example implemented
-
Tweak
-
Update source/_integrations/history_stats.markdown
Very happy with this change ...
Co-authored-by: Franck Nijhof [email protected]
- Update source/_integrations/history_stats.markdown
Co-authored-by: Franck Nijhof [email protected]
Set allTags dynamically during startup
Eliminates one of the most annoying places where conflicts arise. We already store most of the tags in the patchers, so this is duplicate information as well.
I don't love that this has to modify a game constant, but we don't really have a great place for such a constant yet.
Ports process cleanup and mob refactoring (kinda part I)
Ports some more of PsiOmegaDelta's Destroy()/qdels.
Ports a few tweaks to the powersink's handling to make sure it functions properly.
Ports PsiOmegaDelta's initialize() cleanup and fixes, along with his reduction of spawn() in New() procs.
Also ports some of PsiOmegaDelta's mob refactoring.
Removes sleep() statements from closets, and moves item-sucking-uppage into initialize() instead of New(). Also fixes pathing and formatting issues in most of the above-touched closet files.
Pre-emptively ports PsiOmegaDelta's fixes for runtiming pipes and initialize() not being called after roundstart.
Ports a fix for the teleporter and teleporter computer not updating their power state on setup properly.
Ports mwerezak's fix for area power initialization.
Ports atlantiscze's fix for common channel radios being nonfunctional.
THERE ARE TWO MAJOR GAMEBREAKING BUGS THAT NEED TO BE ADDRESSED:
- Doors and anything else from /obj seem to have lost their density.
- Pipenets are still broken from an eternity ago. I cannot figure out why either of these things are broken, but I bet it's something that I forgot to port over to initialize().
IN ADDITION:
- The machinery process keeps getting stuck.
- Other things are probably broken, but this is a dev client so it's your own fault for using it. :)
Speed League: Fuck the Order, all my homies hate the Order.
All of the stuff up to war and coring of the order is done. Loc is mostly done (missing event loc.) GFX is also mostly done (ideas and decisions don't have proper GFX) But most importantly: ALL THE EFFECTS ARE DONE. (well, for that part)
Also all the decisions work.
Made my own simplified dilatation because FUCK YOU OPENCV
"1:30pm. Done with chores.
1:35pm.
def c(x,y,r):
ellipse(x,y,r,r)
q = sqrt(30**2)
c(25,25,30)
c(25+q,25+q,30)
No, I need to rotate it in order to do sideways placement.
def c(x,y,r):
ellipse(x,y,r,r)
q = sqrt(2 * 30**2)/2
c(25,25,30)
c(25+q,25+q,30)
Ah, wait, it is like this. Ok, I get it.
https://py.processing.org/tutorials/
Let me go through the tutorials here. This is what I should be doing. I'll level up my graphics design skill to a basic level. A week or two will not be too long for this kind of work. Of course, I'll supplement this kind of learning with UI work. I won't just glue myself to Processing.
My first goal would be to do the 4 card icons. Alongside this, I'll also do the Spiral logo.
Let me first deal with the tutorials.
2:10pm.
def setup():
size(480, 480)
background(0)
def table():
rectMode(CORNERS)
fill(210,150,0)
pad = 10
rect(pad,pad,width-pad,height-pad,30)
inner = 30
fill(0,250,10)
rect(inner,inner,width-inner,height-inner,30)
def draw():
table()
Right now I am just drawing a table.
How do I make the stroke thicker?
2:15pm. Let me take a short break here.
https://py.processing.org/tutorials/color/
This thing is next.
2:30pm. Let me resume.
The table I did was nice, but I wonder how I am going to translate that into Kivy considering it does not have rounded rectangles.
I have to get familiar with OpenGL to some degree as Kivy is based on it. Once I have that knowledge, I'll be able to understand what its true capabilities are.
I praised Intellisense of the Python plugin, but it is still nowhere near as good as those for statically typed langs. Also the Processing IDE is not as good as the VS Code editor.
2:35pm. I am just so bad at this. I have no idea what HSB mode would be useful for.
def setup():
size(480, 480)
background(90,90,255,0)
def table():
rectMode(CORNERS)
fill(210,150,0)
strokeWeight(5)
pad = 10
rect(pad,pad,width-pad,height-pad,30)
inner = 30
fill(0,250,10)
rect(inner,inner,width-inner,height-inner,30)
def draw():
table()
This is a bit better, let me go into the tutorial.
3:05pm. https://py.processing.org/tutorials/objects/
This is actually pretty boring. But let me go forward with my plan. I'll start skimming here though.
3:20pm. Yeah, this is pretty boring.
https://py.processing.org/tutorials/text/
I am skimming things again. Maybe when it comes to the 3d stuff, things will get more interesting.
3:40pm. https://py.processing.org/tutorials/transform2d/
I am dying here. This is so boring.
3:55pm.
def setup():
size(400,400,P3D)
def draw():
background(120)
pushMatrix()
translate(100,100)
angle = 360*(float(mouseY)/height)
translate(50,0)
rotateX(radians(angle))
print(angle)
rect(0,0,100,100)
popMatrix()
These is more interesting.
I am surprised that the origin matters when doing the rotation. Also I do not unnderstand exactly why the rectangle bieng a flat like is at 74 degrees. I'd have expected it to be at 90.
def setup():
size(600,600,P3D)
def draw():
background(120)
pushMatrix()
translate(300,300)
angle = 360*(float(mouseY)/height)
rotateX(radians(angle))
print(angle)
rectMode(CENTER)
rect(0,0,100,100)
popMatrix()
Ah, I get it. It is 90* when it is exactly in the middle of the screen. I've neglected to think about the viewport.
https://py.processing.org/reference/beginShape.html
Something like this with fill would be really useful to have in Kivy. In order to draw tables in Kivy since it does not have rounded rectangles out of the box, I'll have to get familiar with curves of various sorts.
Also this primitive is what I'll need to draw card icons...
No wait. I'll need the curves.
def setup():
size(600,600,P3D)
def draw():
background(200)
angleY = 360 * float(mouseY) / height
angleX = 360 * float(mouseX) / width
translate(200,300)
rotateX(radians(angleY))
rotateY(radians(angleX))
scale(3)
beginShape(QUAD_STRIP)
vertex(30, 20, 0)
vertex(30, 75, 0)
vertex(30, 20, 30)
vertex(30, 75, 30)
vertex(50, 20, 30)
vertex(50, 75, 30)
vertex(30, 20, 0)
vertex(30, 75, 0)
endShape()
I like how this is cell shades. The lines show their strokes rather than being bordless.
4:45pm. Focus me.
https://py.processing.org/tutorials/p3d/
This tutorial is a bit interesting. I'll want to get familiar with this.
5:05pm. Had to take a small break. Focus me, focus.
Finish the 3d tutorial.
5:15pm. https://py.processing.org/tutorials/anatomy/
Let me read this next.
5:35pm. https://processing.org/tutorials/curves/
Let me move on to this. But before that.
There are a bunch of book on Kivy on Libgen. Let me download them.
5:40pm. https://processing.org/tutorials/curves/
I don't understand the split and Bezier curves just from this.
6:05pm. Done with lunch. Let me watch some of those spline videos. I remember Wildberger covering this as well.
https://youtu.be/83Nsel2uv6k?t=492
I don't understand on which criteria is the curve split into segments.
https://www.youtube.com/watch?v=ct_uGOSPtok Cubic splines (Bezier curves) using linear algebra | Wild Linear Algebra 24 | NJ Wildberger
Let me go for this.
I don't feel like I've done enough for the day so let me go for it for a while longer.
https://youtu.be/ct_uGOSPtok?t=392
This is simpler than I thought.
https://youtu.be/ct_uGOSPtok?t=862
I am going to need these to make club icons.
https://youtu.be/ct_uGOSPtok?t=1357
He says here outright that these are a good way to encode arcs. Yeah, this is worth studying. Back when I first saw this video, it was no that interesting, but now I'll be using these.
6:50pm. This was interesting.
https://www.youtube.com/watch?v=LFFPbBe7aAs Cubic splines using calculus
I'll watch this video tomorrow along with the...
https://www.youtube.com/results?search_query=Rom-Catmull+Spline
Along with some of these. I got two Kivy books from Libgen. There is more left of the processing tutorials.
Let me stop here for the day. I do not know when I'll get a chance to resume my RL plan, but it should happen at some point. Life is hard, what can I say. Especially when you are a language creator.
7pm. I am get through this. It is amazing the lengths I go through to just make some playing cards. But look at it this way - if I can't do even this easily, how am I going to do something more significant than it in the future."
Merge pull request #1310 from billsacks/izumi_retry
run_sys_tests: add --retry option on izumi
Adds a --retry
option to run_sys_tests
, adds a mechanism to set a machine-dependent default value of this option, and sets the default to 1 for izumi. So, if you don't specify the --retry
option to run_sys_tests
, the --retry
option to create_test
will be set to 1 for izumi, 0 for cheyenne or other machines. You can override this with the --retry
option to run_sys_tests
. This value of this option is printed both to stdout and to the (increasingly poorly named) SRCROOT_GIT_STATUS
file in your testroot directory.
The motivation for this change was: Recently, nearly all of my test runs on izumi have a few tests fail with system errors. It started getting annoying to need to rerun them (and wait for the reruns to complete, then check them) before making a tag. With this change, they will be retried once. We could increase the retry to 2 or 3 if 1 doesn't seem sufficient, but I wanted to start out with just 1 retry because it could start to get confusing or wasteful of machine resources if true failures are rerun multiple times, failing in the same way each time – so I figured we could see if 1 is sufficient before increasing this further.
If I understand correctly how this is implemented in create_test, it will mean that the create_test job (which, with run_sys_tests, is executed on a batch node) will remain active until all tests that it "owns" have completed. There's a chance that this will have negative repercussions in terms of job scheduling (if the scheduler sees that you already have these active jobs so gives priority to someone else), but since izumi tends to be pretty lightly loaded, I'm hopeful it will be okay.
I also made a commit to this PR that fixes some pylint warnings with recent versions of pylint.
Contributors other than yourself, if any: none
CTSM Issues Fixed (include github issue #): none
Are answers expected to change (and if so in what way)? no
Any User Interface Changes (namelist or namelist defaults changes)? no
Testing performed, if any:
- python tests
- Ran full test suite on izumi via the new run_sys_tests to verify that it worked; this test suite had 3 tests that experienced system failures in their first runs but (as desired) were automatically rerun and passed the second time around
- Ran a 2-test run via run_sys_tests on cheyenne to verify that I haven't broken that
Code is still shit. But works.
Code is shitty as hell, needs heavy polishing. But at least, seems to work.
Hell yeah.
WUFR-1165: Sensor board/22 support (#10)
- WUFR-1165: Sensor board 22 firmware support
Fixes WUFR-1166 WUFR-1168
-
Add flashy status light and fix hsd bug
-
WUFR-754: Make the ADC slow to increase precision
-
Configure ADC pins as inputs
-
Fuck ADC1, all my homies hate ADC1
For some reason, the presence of ADC1 being enabled in slave mode would corrupt the reading on AIN0, the first sensor. This commit adds a feature flag to disable dual-ADC mode entirely.
Now that I think about it, the reason for the issue is probably that the second ADC wasn't configured to read anything, so when it was triggered to start it would read one channel anyway. Since reverse_adc1 was set to the default value (0 == sensor1), it corrupted the reading for sensor1.
So two solutions to this problem:
- disable this new feature flag when only using channels on ADC0
- jk this is the only reasonable solution
- Something is causing standard CAN frames to have ID 0
This is as it appears in my makeshift "serial_buffer" arduino sketch. (https://confluence.washuracing.com/x/bgkm) Don't know if zero IDs are being transmitted or if my receiver is dumb.
- Add further documentation to sensor/22
Done with window rescaling and ui elements offsettings. Thanks to a good fuck with my girlfriend. i Luv u
Save before my beautiful girlfriend deletes my ugly code
Rollup merge of #83405 - r00ster91:deprecated_emoji, r=GuillaumeGomez
Slight visual improvements to warning boxes in the docs
First I noticed that sometimes the thumbs-down emoji in the docs is hard to see and hard to look at because the yellow emoji color and the color of the box below are so bright. Especially if you look at the screen late at night you can notice it. I thought I should change that so I added a black outline around the emoji. It works using the text-shadow
property. It may be a bit hacky but it seems to work well and browser compatibility looks pretty good too: browser compatibility.
For consistency the microscope has the black border too.
Alternatively I had drop-shadow(0px 0px 1px black);
in mind but its browser compatibility doesn't look as good and the blurry shadow probably doesn't look as good either.
Then, I thought that now that I'm at it I could also try changing the purple color to a color you would rather expect to see for deprecation: red. For the red I've taken the blue and reused it as a foundation and moved it to the red color spectrum. But then I thought that the purple color could still be reused for something else: for the boxes that tell you about portability (e.g. only supported on Unix). These are currently blue.
I think blue doesn't really represent danger like it should. Not being cross-platform represents a danger because if you want to compile for a different platform, your code may not compile anymore. Blue looks too friendly and is in my opinion more suitable for a box containing general information like for instance "This is available since 1.0.0". None of the current three box types (unstable, deprecated and portability) are that.
I think purple is a better fit for it because it's kind of in the middle between "use it" and "don't use it". Deprecated is definitely "don't use it". To illustrate this better, here's a color spectrum:
Blue = friendly, "use it". Red = danger, "don't use it".
And the purple in the middle (the color that the portability box now has) probably represents "use it if you have to", so it's not entirely friendly and not entirely a danger. That is why I think it fits.
However I made one change to that existing purple: I made the outer color a bit brighter because it's outstandingly dark compared to the other outer colors of the other boxes.
This is all subjective but in my opinion it looks nicer. At first you might need to get used to it though. Notice the box colors and the black outlines around the emoji shapes:
Official release for various promos
The following cards have had their IDs/passcodes updated for their official release. Please re-add them to your decks.
- Curse of Dragon, the Magical Knight Dragon
- Pile Armed Dragon
- Nowruz Elise the Dragon of Beauty and Faith
- Armored Dragon
- Crow Tengu
- Onmoraki
kinyirikisi/LOST-LOVE-SPELL-CASTER-27737785444-BRING-BACK-LOST-LOVER-SPELLS-IN-Canada-Central-African-Republic@5337811a83...
https://www.extremelovespell.co.za/
STOP CRYING BECAUSE OF LOST LOVER +27737785444 IN CAPE TOWN DURBAN KIMBERLY PRETORIA EASTERN CAPE QUEENSTOWN DUBAI MBABANE HARARE WHY DO YOU ALLOW A BREAK UP? HE or SHE CAN'T DUMP YOU Just like that, Spiritual supernatural customized ancestry powers, to make him or her; Love you alone and focus on you, Bring back your lost lover no matter the odds, Have full control of your lover, Stop your lover from cheating. Believe and trust you, respect your feelings, Take good Care of you, support you financially, Renew your love and bind you together. Make your lover marry you within a short period of time. Call/WhatsApp +27737785444 for more information from The Doctor.