2,922,661 events, 1,436,381 push events, 2,304,234 commit messages, 180,641,462 characters
FUCKING KILL ME CHRIST I HATE THIS GOD DAMN PROJECT JUST END MY SUFFERING (I'm still fucking trying to import mysql drivers)
Created Text For URL [www.dispatchlive.co.za/news/2021-02-08-kzn-man-gets-life-in-prison-for-rape-of-girlfriends-5-year-old-child/]
fix(connectdb): Re-use existing DB connection (#21)
This avoids instantiating a new peewee Database (and, hence, creating a new database connection) in the get_peewee_database calls if one already exists. I suspect this is what we intended to happen all along.
Without this fix, every call to chimedb.core.connect() results in a new connection to the database being established. In theory, for normal connections to the MySQL database, this is not a problem: one connection should be the same as any other. (The previous connection is closed during GC).
However, this can cause trouble when using an in-memory SQLite database in test-safe mode.
I also wonder if this is the cause of some of the unexplained DB connection loss we've experienced, especially in alpenhornd, but I have no real evidence for that.
New data: 2021-02-08: See data notes.
Revise historical data: cases (BC, MB, ON); mortality (AB).
Note regarding deaths added in QC today: “The data also report 17 new deaths, but the total of deaths amounts to 10,046 due to the withdrawal of 2 deaths that the investigation has shown not to be attributable to COVID-19. Among these 17 deaths, 2 have occurred in the last 24 hours, 11 have occurred between February 1 and February 6 and 4 have occurred before February 1.” 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.
Updating: 2/9/2021 6:00:00 AM
- Added: My experience of using modular monolith and DDD architectures – The Reformed Programmer (https://www.thereformedprogrammer.net/my-experience-of-using-modular-monolith-and-ddd-architectures/)
- Added: 10 Reasons to Love Passwordless #2: NIST Compliance (https://techcommunity.microsoft.com/t5/azure-active-directory-identity/10-reasons-to-love-passwordless-2-nist-compliance/ba-p/2115725)
- Added: Continuous Monitoring for Web Performance and Accessibility | Azure DevOps Blog (https://devblogs.microsoft.com/devops/continuous-monitoring-for-web-performance-and-accessibility/)
- Added: Make code more readable by refactoring it with ReSharper – .NET Tools Blog | JetBrains (https://blog.jetbrains.com/dotnet/2021/02/08/make-code-more-readable-by-refactoring-with-resharper/)
- Added: TechEmpower Web Framework Performance Comparison (https://www.techempower.com/benchmarks/#section=data-r20)
- Added: Sharing data between CSS and JavaScript using custom properties (https://christianheilmann.com/2021/02/08/sharing-data-between-css-and-javascript-using-custom-properties/)
Generation took: 00:08:37.5979848 Maintenance update - cleaning up homepage and feed
Sorry to interrupt this lovely reunion, betrayer...
But I need to keep you, uh, motivated.
we didnt wanna push until we had the cool effect for repentance done but crown cranium demands it
- racing thoughts got tweaked AGAIN ooUAUUGh. it shouldnt be as nuts as before ( hopefully )
- polish for various crown cranium effects
- camoflauge and displacement now undo their stat changing stuff on skill_lose
- mechanics for repentance spawning have been changed to be more forgiving and also work if you didnt have any curse
- resurrection now works if you have it on characters that arent skeleton while not in coop ( just for u, gepsi )
- secret stash now makes sure not to slap soda machines on top of chests
- cultra updates courtesy of yokin
- sprite updates woo
Pick between see read
Love the article and it's premise.
I noticed a small error and the make a pull-request so as a thank you I opted to contribute back
There was a sentenced that had a small mistake. It contained the combination "see read", which seems wrong to me. I opted to change it to "see", but that is a choice best left to you.
Thanks again for the time to publish your thoughts.
Removed Ded'Jellow and God'Jellow from the proper names pool. (#643)
$changelog: Removed kinjello references in Priest & Master Healer proper name.
It has reached my hearing that some people aren't happy at all seeing kinjello having a reference in priest name. Those names have been added by me in a context where the player base was meme-ing at kinjello perfomance on priest, sometime he would crappy move and die, sometime he would actually do good play and turn up a fight. His behavior being impredictable, I decided to add those name just for meme-ing, the community back then didn't seem to complain, atleast not to the point where I had to revert it.
I was fucking stupid, sorry r0neko you are awesome
Merge #1162 #1383
1162: DifferentialEquations.jl-Based ODE Solvers r=charleskawczynski a=ChrisRackauckas
This sets up "two" ODE solvers: DiffEqJLSolver and DiffEqJLIMEXSolver. These solvers allow taking in a DEAlgorithm which can be any DiffEq common interface ODE solver that satisfies the common integrator interface, which includes OrdinaryDiffEq, Sundials, and a few others.
The only kernel calls are done through fused broadcasts, so in theory there shouldn't be any overhead on large problems as long as we are only using the right number of kernels. In practice, since this is our first super larger scale application since we plan to track, there may be an extra kernel call somewhere, and so I assume that after we get attempt 1 done here we may need to make an upstream change. The standard RK methods (including the SSP methods, which includes some methods with enhanced stability specifically for DG discretizations) should all be optimized already. I think we may need to do something special for the low-storage RK methods.
As for implicit and IMEX methods, I setup the interface for how to hook into them, though we may need to setup a linear solver for DiffEq. That can be done via https://docs.sciml.ai/latest/features/linear_nonlinear/#Linear-Solvers:-linsolve-Specification-1 , so we can just make the solvers call your linear solvers.
There are a few things we're looking at for how this will benefit both our own research and Clima. To list a few:
- Our methods for numerical uncertainty quantification will allow for understanding the error induced by the time stepping methods. There's other (undocumented) UQ methods being published soon which could be useful too.
- Checkpointed adjoint sensitivity analysis for parameter fitting and UQ is probably a big feature Clima would gain from this. More work might be required to complete the integration of this, but I think there could be a lot of uses.
- Stochastic differential equation models would be pretty accessible from this form, so if there are reasonable extensions to SPDEs they can be considered and high order adaptive methods can be applied.
- Generalized Physics-Informed Learning: you can see from this talk that I want to start taking this to climate models for developing surrogates.
- Tons of new methods. Specifically:
- A bunch of SSP methods
- A bunch of low-storage RK methods
- A bunch of IMEX methods
- Whatever we build in the future.
The benefits to SciML are:
- We see that there's been some recent work in MRI methods. It would be nice to capture that momentum as something that can be added directly to OrdinaryDiffEq (or even just in SimpleDiffEq.jl or another common interface algorithm package) so that they can be used on an SplitODEProblem. This would enhance the Julia ecosystem beyond Clima and be something that can then be demonstrated as a benefit of the Clima project to other projects down the line. By creating this common interface ODE solver algorithm for Clima, I hope we can accelerate this effort because now, if the MRI methods are moved to a DiffEq interface compatible package, they should be usable in Clima without overhead which should be a good incentive to do so!
- We can start to use Clima as one of our canonical benchmarks, and hopefully overtime improve algorithm performance on Clima's type of problems and use it as a source of real-world problems in publications and grants (possibly we could look for a joint grant in this area).
- This serves as a good testing ground for MPI and GPU based array usage. It won't be perfect until we have a real test, so let's get a test!
So in short, this should help Clima get a few new features while improving SciML for large models to help out other PDE-based modeling projects beyond Clima.
There are a few small issues noticed in this PR:
- What test case should I be using? I just grabbed what was in the ODESolver tests, but what's a good demo climate simulation I can start using to test out CPU usage, GPU usage, and MPI+GPU usage? I'd like to have these three cases for development and to add to DiffEqBenchmarks.jl.
- When is
pdefined? In the DiffEq solvers, we wantpat the time of the construction of theODEProblemso we can concretely type the integrator. We at least need to know and have something of its type. The test just hasnothingparameters, so that works, but I wonder if this will be an issue. I addedpas a keyword argument to the solver's constructor. - The methods from Sundials and other C++/Fortran libraries are "technically" supported, but in reality they need the array type to be an
Array, which I assume will almost never be the case with Clima. Sundials does have some good MRI methods that would be interesting to try out here, but making them work would require making NVector wrappers which, it might just be easier to make Julia versions of all of that (and that is a summer project for students). - Is there any more structure in the ODEs that can be exploited? Semilinearity for exponential integrators or anything of that sort? Symplecticness or partitioning of the states?
- Dependencies: are you open to a DiffEqBase dependency? That's a whole lot smaller than OrdinaryDiffEq or DifferentialEquations.jl. A user would need to
using DifferentialEquations(or justusing OrdinaryDiffEq) to actually get solver methods.
If this is setup, then I would like to have some of our GSoC and MLH students optimize this interfacing and demonstrate results using it. That would then set the stage for less technical more mathematical students to just do pure algorithm development in OrdinaryDiffEq knowing that this would be efficient. I hope we can demonstrate that this connection ends up calling the optimal number of kernels by the end of the summer.
In 18.337 Scientific Machine Learning and Parallel Computing in the next fall, each student has final projects to do and, if this is all setup, I would like to point a few students towards implementing some new methods and demonstrating the results on Clima, so this is where new IMEX, MRI, etc. methods can get developed, improved, and tested.
1383: Add flattened_tup_chain and chained getproperty/getindex methods r=charleskawczynski a=charleskawczynski
Debugging highly nested models (e.g., EDMF) is difficult because, at the moment, checking fields in all sub-models requires manually writing out all fields/subfields, or writing recursive getproperty/getindex methods, which is painful/overkill just for debugging. This PR adds a method flattened_tup_chain, along with a recursive and interleaved getindex/getproperty, to VariableTemplates so that users can iterate through every field in compute kernels in a convenient way, as demonstrated in a new test in the test suite:
ftc = flattened_tup_chain(st)
@test ftc[1] === (:ntuple_model, 1, :scalar_model, :x)
@test ftc[2] === (:ntuple_model, 2, :scalar_model, :x)
@test ftc[3] === (:ntuple_model, 3, :scalar_model, :x)
@test ftc[4] === (:vector_model, :x)
@test ftc[5] === (:scalar_model, :x)
# getproperty with tup-chain
for i in 1:N
@test v.scalar_model.x == getproperty(v, (:scalar_model, :x))
@test v.vector_model.x == getproperty(v, (:vector_model, :x))
@test v.ntuple_model[i] == getproperty(v, (:ntuple_model, i))
@test v.ntuple_model[i].scalar_model == getproperty(v, (:ntuple_model, i, :scalar_model))
@test v.ntuple_model[i].scalar_model.x == getproperty(v, (:ntuple_model, i, :scalar_model, :x))
endIf we change our initialization, as suggested by @trontrytel and discussed with @kpamnany, to initializing fields to NaNs, a very practical use-case of this might look like:
function init_heldsuarez!(balance_law, state::Vars{st}, aux::Vars{au}, coords, t) where {st,au}
# Initialize fields...
for tc in flattened_tup_chain(st)
@assert getproperty(state, tc) ≠ NaN
end
for tc in flattened_tup_chain(au)
@assert getproperty(aux, tc) ≠ NaN
end
# All fields in all balance_law submodels are now gauranteed to be initialized
endCo-authored-by: Chris Rackauckas [email protected] Co-authored-by: Charles Kawczynski [email protected]
oh god what the fuck did i do
please dont use this it's horrible
Get codebase completely working with LLVM
You can now build Cosmopolitan with Clang:
make -j8 MODE=llvm
o/llvm/examples/hello.com
The assembler and linker code is now friendly to LLVM too. So it's not needed to configure Clang to use binutils under the hood. If you love LLVM then you can now use pure LLVM.
BACKPORT: modpost: file2alias: go back to simple devtable lookup
Commit e49ce14150c6 ("modpost: use linker section to generate table.") was not so cool as we had expected first; it ended up with ugly section hacks when commit dd2a3acaecd7 ("mod/file2alias: make modpost compile on darwin again") came in.
Given a certain degree of unknowledge about the link stage of host programs, I really want to see simple, stupid table lookup so that this works in the same way regardless of the underlying executable format.
Signed-off-by: Masahiro Yamada [email protected] Acked-by: Mathieu Malaterre [email protected] Link: https://git.kernel.org/linus/ec91e78d378cc5d4b43805a1227d8e04e5dfa17d Signed-off-by: Nathan Chancellor [email protected] Signed-off-by: Anushek Prasal [email protected]
"10:15am. It is the long awaited go-to-the-bank day. Shortly before 4pm I'll have to go out of the house for an hour or two.
10:20am. Let me do my morning reading. I'll do programming later.
10:30am. https://mangadex.org/title/44529/jk-musou-owaru-sekai-no-sukuikata
Tomoko in a Zombie apocalypse. I enjoy crazy, violent female leads in shonen-type works a bit too much.
Let me catch up with Satanophany and I will start programming. I've had a ton of time to think about how I want things to work. Today, I will get the games out of the way at least. Maybe I will do a few of them even.
10:45am. It is time to start.
union card = King | Queen | Jack
union player = PlayerOne | PlayerTwo
type chips = i32
type raise = u8
union observation =
| HoleCard: card For: player
| CommunityCard: card
| Call | Raise | Fold
| Reward: chips
inl GameSettings = {
round_one_raise = 2 : chips
round_two_raise = 4 : chips
max_raises_per_round = 2 : raise
}
union kuhn_state =
| Init
| RoundOne: {pot : chips * chips; hands : card * card; raises_left : raise; waiting_for : player}
| RoundTwo: {pot : chips * chips; hands : card * card; community_card : card; raises_left : u8; waiting_for : player}
inl shuffle (x : array _) : () =
!!!!Import("numpy.random")
$"numpy.random.default_rng(!x)"
// TODO: Make a proper array literal so I can write this as ![King; King; Queen; Queen; Jack; Jack]
inl InitialDeck = arrayu64.init 6 (fun i => match i / 2 with 0 => King | 1 => Queen | _ => Jack)
// inl sample_with_replacement (x : array card) : card * array card = failwith "TODO"
inl get_random_community_card (hands : card * card) : card = failwith "TODO"
inl game _ = ()
// inl normalize forall t. (x : array (t * f64)) : array (t * f64) = failwith "TODO"
// inl sample forall t. (x : array (t * f64)) : t = failwith "TODO"
inl main() =
()
Let me get rid of all of this. I'll start from scratch.
inl game init_deck {chance_all chance action terminal} =
()
I spent a lot of time thinking about this. As it turns out, the main inspiration was my CFR work from late 2019. I actually came close to the ideal form near the end of that experiment, but I stopped just a step short of reaching it.
In fact, last time I did end up with the feeling of reaching my limit. I worked a lot on that, so unfortunately, I thought I was done with it. Because I could not go far enough, I ended up thinking that was how far things could go. So my initial thoughts was to try to find an alternative way.
I had to churn away at it in order to get past my misconceptions.
I am happy though that the work I did last time is sound as a base. That means I did not waste my time doing it.
If I had not gone through that, I would be so much poorer now as a result. I'd actually need to put in all of that effort now. But instead I have the experience pushing me on.
11:05am. Now if I can stop surfing 4chan, I'd be able to get some work done.
inl sample forall t. (x : array t) : t = failwith "TODO"
inl sample_with_replacement forall t. (x : array t) : t * array t = failwith "TODO"
inl game init_deck {draw_all draw action terminal} =
()
Let me make a draw node instead of the plain chance node. No need to complicate things here.
All of this is really annoying though. I need my own library of immutable data structures. I also need dictionaries and array library functions. Maybe Python has something, but with Python I do not have integration with equality, hashing and comparison. The integration is only halfway right now. How annoying.
11:20am.
action p1 [Call, Raise] fun action =>
This is unbearable. I really need to put in the array and list literals.
TODO: List and array patterns and literals.
Forget the patterns, but I will do literals right now. Unlike F#, I'll make arrays the default []. I'll make lists ![] rather than having || inside. [||] would actually be fairly hard to parse.
...No, I'll make ![] arrays.
11:25am. But I really don't want to work on this right now. I want to work on the game. Forget this for the time being.
inl InitActions : array action = failwith "TODO" // ![Call; Rise]
Let me leave this like so.
11:45am.
union action = Fold | Call | Raise
union card = King | Queen | Jack
// TODO: Implement the array literals.
inl ActionsInit : array action = failwith "TODO" // ![Call; Rise]
inl ActionsFull : array action = failwith "TODO" // ![Fold; Call; Rise]
inl ActionsNoRaise : array action = failwith "TODO" // ![Fold; Call]
inl DeckInit : array card = failwith "TODO" // ![King; Queen; Jack; King; Queen; Jack]
inl game {draw_all draw act terminal} =
inl done = ()
let rec init () =
draw 0 DeckInit fun (card, deck : card * array card) =>
inl p1 = {card pot=1; id=0}
draw 1 deck fun card, deck =>
inl p2 = {card pot=1; id=1}
round_one {raise_amount=2; rounds_left=2; raises_left=2; actions on_call} (p1,p2)
and let round {raise_amount rounds_left raises_left actions on_call} (p1,p2) =
act p1 actions' function
| Fold => terminal (p1.id, p1.pot + p2.pot)
| Call => round_one raises_left Actions (p2,p1)
| Raise =>
inl raises_left = raises_left - 1
inl raise () = inl dif = p2.pot - p1.pot in p1.pot + dif + 2
round_one raises_left (if raises_left = 0 then ActionsNoRaise else Actions) (p2, {p1 with pot=raise()})
()
How annoying. How much of this do I want to hardcode?
12:30pm.
// The Leduc poker game in CPS'd form.
union action = Fold | Call | Raise
union card = King | Queen | Jack
// TODO: Implement the array literals.
inl ActionsInit : array action = failwith "TODO" // ![Call; Rise]
inl ActionsFull : array action = failwith "TODO" // ![Fold; Call; Rise]
inl ActionsNoRaise : array action = failwith "TODO" // ![Fold; Call]
inl DeckInit : array card = failwith "TODO" // ![King; Queen; Jack; King; Queen; Jack]
type player = {card : card; id : u8; pot : u32}
type players = player * player
inl game {sample_all draw action terminal} =
inl done = ()
inl raise amount (p1,p2 : players) = p2.pot + amount
draw 0 DeckInit fun (card, deck : card * array card) =>
inl p1 = {card pot=1; id=0}
draw 1 deck fun card, deck =>
inl p2 = {card pot=1; id=1}
let rec round_two (raises_left : i32) (community_card : card) (p1,p2 : players) =
action p1.id (if 0 < raises_left then ActionsFull else ActionsNoRaise) function
| Fold => terminal (p2.id, p1.pot + p2.pot)
| Call => failwith "TODO: compare_hands" community_card (p1,p2)
| Raise => round_two (raises_left-1) community_card (p2,{p1 with pot=raise 4 (p1,p2)})
let round_two_init (p1,p2 : players) =
sample_all deck fun card =>
action p1.id ActionsInit function
| Fold => failwith "impossible"
| Call => round_two 2 card (p2,p1)
| Raise => round_two 1 card (p2,{p1 with pot=raise 4 (p1,p2)})
let rec round_one (raises_left : i32) (p1,p2 : players) =
action p1.id (if 0 < raises_left then ActionsFull else ActionsNoRaise) function
| Fold => terminal (p2.id, p1.pot + p2.pot)
| Call => round_two_init (if p1.id = 0 then p1,p2 else p2,p1)
| Raise => round_one (raises_left-1) (p2,{p1 with pot=raise 2 (p1,p2)})
action p1.id ActionsInit function
| Fold => failwith "impossible"
| Call => round_one 2 (p2,p1)
| Raise => round_one 1 (p2,{p1 with pot=raise 2 (p1,p2)})
This is perfect. I could lower the code size though some functional abstraction, but that would make things harder to read. There is no need to push myself here.
inl game {sample_all draw action terminal} =
inl done = ()
inl raise amount (p1,p2 : players) = p2.pot + amount
inl pot = 1
inl id = 0
draw id DeckInit fun (card, deck : card * array card) =>
inl p1 = {card id pot}
inl id = 1
draw id deck fun card, deck =>
inl p2 = {card id pot}
Let me do it like this. The type passed into draw is an arbitrary number instead of an id.
forall 'a. {action : u8 -> array action -> (action -> 'a) -> 'a; draw : u8 -> array card -> (card * array card -> 'a) -> 'a; sample_all : array card -> (card -> 'a) -> 'a; terminal : u8 * u32 -> 'a} -> 'a
Now the type of game is this. Exactly what one would expect if it were CPS'd.
I should do Dudo next. But before that I also need to do the hand ranking function.
Let me have breakfast here. I'll do that afterwards."
"1:55pm. Let me finish the chapter of Otherside Picnic and then I'll resume. I have 1.5 hours before I leave so that is not too much time, but it might be enough to deal with the hand ranking functions and the Dudo game. The Leduc game just came out so well. 5/5. If I'd tried to abstract it further, it would have been 4/5.
2pm. Ok, focus me. Let me do the hand ranker.
2:15pm.
inl compare_hands (community_card : card) (p1,p2 : players) =
let tag = function King => 2i32 | Queen => 1 | Jack => 0
let order (a,b) = if a > b then a,b else b,a
let a = (tag p1.card, tag community_card) |> order
let b = (tag p2.card, tag community_card) |> order
let is_pair (a,b) = a = b
if is_pair a && is_pair b then comp (fst a) (fst b)
elif is_pair a then GT
elif is_pair b then LT
else
match comp (fst a) (fst b) with
| EQ => comp (snd a) (snd b)
| x => x
I really hate how Cython heap allocates unions. I am tempted to just make the order an int.
union order = LT | EQ | GT
prototype comparable a : a -> a -> order
inl eq_is = function EQ => true | _ => false
Let me change this. Forget making this smooth. It will be more efficient if it is not an union anyway.
type order = i32
prototype comparable a : a -> a -> order
inl EQ = 0i32
inl eq_is (x : i32) = !!!!EQ(x, 0i32)
inl LT = -1i32
inl lt_is (x : i32) = !!!!EQ(x, -1i32)
inl GT = 1i32
inl gt_is (x : i32) = !!!!EQ(x, 1i32)
inl compare_hands (community_card : card) (p1,p2 : players) =
let tag = function King => 2i32 | Queen => 1 | Jack => 0
let a = tag p1.card, tag community_card
let b = tag p2.card, tag community_card
let is_pair (a,b) = a = b
if is_pair a && is_pair b then comp (fst a) (fst b)
elif is_pair a then GT
elif is_pair b then LT
else
let order (a,b) = if a > b then a,b else b,a
inl a,b = order a, order b
inl x = comp (fst a) (fst b)
if eq_is x then comp (snd a) (snd b) else x
Here is the hand ranker.
| Call =>
let x = compare_hands community_card (p1,p2)
if gt_is x then terminal (p1.id, p1.pot + p2.pot)
elif lt_is x then terminal (p2.id, p1.pot + p2.pot)
else terminal (p1.id, 0)
Here is the last case.
union action = Fold | Call | Raise
union card = King | Queen | Jack
Though I am wondering about the value of the optimization I did considering these will also be heap alloc'd.
2:35pm. Maybe I for getting real performance out of the Cython backend, I should do a C one as well and then call that where I need to. Nevermind this for the time being.
This kind of extreme performance case is not something I need to concern myself with right now.
2:40pm. I am getting distracted with meaningless things. I made the change, so I might as well live with it.
What is next? Focus me.
Let me do Dudo.
I am getting that lingering error on rename.
Sometimes even on delete. Damn it, I thought I took care of this?
if ("RenameFile" in x[1] || "RenameDirectory" in x[1]) {
const r = range(x[0])
const target = await window.showInputBox({value: doc.getText(r), prompt: "Enter a new file name."})
if (target) {
if ("RenameDirectory" in x[1]) {x[1].RenameDirectory.target = target}
else {x[1].RenameFile.target = target}
error = await spiprojCodeActionExecuteReq(uri,x[1])
if (!error) {
const edit = new WorkspaceEdit()
edit.replace(doc.uri,r,target)
workspace.applyEdit(edit)
}
}
}But I did not really consider the code actions. What a pile of crap.
Let me add this to the list. It is not that important at the moment.
Dudo, let me do dudo here.
let rec dudo_main (history, one, two as key) =
match history with
| [] -> response key claims (fun claim one -> dudo_main (claim :: history, two, one))
| (number,rank as claim) :: _ ->
response key
actions.[Array.findIndex ((=) claim) claims + 1 .. ]
(fun action one ->
match action with
| Dudo ->
let check_guess s x = if x = 1 || x = rank then s+1 else s
let dice_guessed = check_guess (check_guess 0 one.state) two.state
if dice_guessed < number then 1.0 else -1.0
|> terminal
| Claim claim -> dudo_main (claim :: history, two, one)
)
let dudo_initial one two =
chance one <| fun one ->
chance two <| fun two ->
dudo_main ([], one, two)Let me paste this here again.
2:50pm. It is really annoying...I am supposed to be working, but knowing I have to leave in an hour is really squeezing me. I am subconsciously trying to hold back on sleeping too much into the zone. This is hindering me.
Well, let me do what I can.
// Appends two arrays.
inl append a b = init (length a + length b) (fun i => inl l = length a in if i < l then index a i else index b (i - l))
Let me implement it like this.
3:05pm.
inl Dice : array rank = failwith "TODO"
inl Claims : array claim = failwith "TODO"
inl Actions : array action = arrayu64.append (arrayu64.map claim_ Claims) (arrayu64.singleton Dudo)
The way this works is honestly crazy. I am creating these heap allocated arrays and concatenating them.
// TODO: Implement the array literals.
inl ActionsInit : array action = failwith "TODO" // ![Call; Rise]
inl ActionsFull : array action = failwith "TODO" // ![Fold; Call; Rise]
inl ActionsNoRaise : array action = failwith "TODO" // ![Fold; Call]
inl DeckInit : array card = failwith "TODO" // ![King; Queen; Jack; King; Queen; Jack]
The same thing here. I am going to wrap these in a join point and pull them inside the function so they do not keep getting realloc'd.
Nevermind this for now.
3:25pm.
// Finds the index of the true applicant.
inl findIndex f x =
let rec loop i = if i < length x then f (index x i) && loop (i+1) else failwith "The true applicant does not exist."
loop 0
// Slices the array at the specified range.
inl slice (from:nearTo:) x = init (nearTo-from) (fun i => index x (i+from))
Let me add these two as well.
// Finds the index of the true applicant.
inl findIndex f x =
let rec loop i =
if i < length x then if f (index x i) then i else loop (i+1)
else failwith "The true applicant does not exist."
loop 0
Let me do this one like so. I messed up.
3:45pm.
inl game {sample action_response action_init terminal} =
inl actions = Actions
inl claims = Claims
inl dice = Dice
let rec loop (number,rank as claim) (p1,p2 : players) =
inl from = arrayu64.findIndex ((=) claim) claims + 1
action_response p1.id (arrayu64.sliceFrom from actions) function
| Claim: x => loop x (p2,p1)
| Dudo =>
inl check_guess x = if x = 1 || x = rank then 1 else 0
inl dice_guessed = check_guess p1.die + check_guess p2.die
inl winner_id = if dice_guessed < number then p1.id else p2.id
terminal (winner_id, 1)
let id = 0
sample id dice fun die =>
inl p1 = {id die}
let id = 1
sample id dice fun die =>
inl p2 = {id die}
action_init p1.id claims fun claim =>
loop claim (p2,p1)
I am not done yet, but let me stop here. I need to get ready to leave. Maybe I'll do a bit more after I get back."
Started over. Gonna get the barebones necessities laid out first. Once i can do everything in the console, I'll make a GUI. Shit was getting messy as hell.
Renamed original main.cpp to "oldmain.cpp" in case I need to remember anything. I'll delete once I'm sure I don't need it anymore. Thank you Github for the free space. I genuinely mean this.
Create README.md
Hello my name is Susan I am a curious dentist. I love digital life, languages and adventures. Actually I am into programming, e-learning and developing my platforms of my dentistry profesion. You can contact me at [email protected]
I will be glad to keep you informed in relation to dentistry and make it a great experience to maintain your health. You can ask me about: dentistry diagnosis in case you are feeling insecure and need more info to continue a treatment, implants, and neural therapy.
ansible: Fix sink url pattern
We shouldn't use ansible_host there, as that will be something clunky
like ec2-<IP>.*.amazonaws.com and not match the TLS certificate's
subjectAlternateNames.
Configure the logs.cockpit-project.org domain name instead. We had this for a long time, until the re-deployment earlier this morning changed it.
Still having hope; I already uploaded this shit to github. Although I deleted like 10 years of my life in photos, I think I'm progressing at this stupid thing
scaling now checks out!
passing verifications now
added histograms to verification
comparison to slim looks good. need to keep testing for different param values
holy shit it all works
working on docs
tau-- time since a sweep ocurred, now checks out
had to add untracked file?
added comments to time scaling code in verification.py
adding a bunch of documentation
auto lint
auto lint part 2
warning levels got my c code
test cases now failing due to nonsensical params
fixing up unit tests now
fixing up unit tests now
trying to fix doc notebook import to use matplotlib
still issues in old unit tests
incorporating Jerome's comments
found a damn typo
made the switch from alpha to s
straggling tests with the switch to s
still turning up weird tests...
more testing snafus with change to s
changed this weird msms mimic test-- i think we can dump it?
jerome edits on doc
"5:25pm. Display card - get! Now I can login into my bank account. I'll see about making that sponsor link for Spiral. I am not expecting anything of it, but allowing people to give me money is better than not.
Let me just catch my breath. Hopefully I didn't get corona'd during my one trip outside the house in over a year.
5:35pm. Let me start.
inl Dice : array rank = failwith "TODO" // [|1..6|]
inl Claims : array claim = failwith "TODO" // [|1,2; 1,3; 1,4; 1,5; 1,6; 1,1; 2,2; 2,3; 2,4; 2,5; 2,6; 2,1|]
This is really killing me. I am going to have to put in array literals at the earliest opportunity.
inl Dice : array rank = failwith "TODO" // [|1..6|]
inl Claims : array claim = failwith "TODO" // [|1,2; 1,3; 1,4; 1,5; 1,6; 1,1; 2,2; 2,3; 2,4; 2,5; 2,6; 2,1|]
inl Actions : array action = arrayu64.append (arrayu64.map claim_ Claims) (arrayu64.singleton Dudo)
type player = {id : u8; die : rank}
type players = player * player
inl game {sample action_response action_init terminal} =
inl actions = Actions
inl claims = Claims
inl dice = Dice
let rec loop (number,rank as claim) (p1,p2 : players) =
inl from = arrayu64.findIndex ((=) claim) claims + 1
action_response p1.id (arrayu64.sliceFrom from actions) function
| Claim: x => loop x (p2,p1)
| Dudo =>
inl check_guess x = if x = 1 || x = rank then 1 else 0
inl dice_guessed = check_guess p1.die + check_guess p2.die
inl winner_id = if dice_guessed < number then p1.id else p2.id
terminal (winner_id, 1)
let id = 0
sample id dice fun die =>
inl p1 = {id die}
let id = 1
sample id dice fun die =>
inl p2 = {id die}
action_init p1.id claims fun claim =>
loop claim (p2,p1)
Let me do this a bit differently.
...I meant to remove claims, but no. The idea is no good.
I do need two different functions here.
inl game {sample_all draw action terminal} = join
// TODO: Implement the array literals.
inl actionsInit : array action = failwith "TODO" // ![Call; Rise]
inl actionsFull : array action = failwith "TODO" // ![Fold; Call; Rise]
inl actionsNoRaise : array action = failwith "TODO" // ![Fold; Call]
inl deckInit : array card = failwith "TODO" // ![King; Queen; Jack; King; Queen; Jack]
Let me draw these in like so.
action p1.id actionsInit function
| Fold => failwith "impossible"
| Call => round_one 2 (p2,p1)
| Raise => round_one 1 (p2,{p1 with pot=raise 2 (p1,p2)})
It is wasted on Cython, but I'll implement the actions as unboxing applies.
5:55pm. This does not really matter now.
// union order = LT | EQ | GT
// I am doing this like so to prevent the Cython backend from allocating these as heap objects.
type order = i32
prototype comparable a : a -> a -> order
inl EQ = 0i32
inl eq_is (x : i32) = !!!!EQ(x, 0i32)
inl LT = -1i32
inl lt_is (x : i32) = !!!!EQ(x, -1i32)
inl GT = 1i32
inl gt_is (x : i32) = !!!!EQ(x, 1i32)
I am not comfortable with this. Let me make order a nominal at least.
6pm.
nominal order = i32
prototype comparable a : a -> a -> order
inl EQ = order 0i32
inl eq_is (order x) : bool = !!!!EQ(x, 0i32)
inl LT = order -1i32
inl lt_is (order x) : bool = !!!!EQ(x, -1i32)
inl GT = order 1i32
inl gt_is (order x) : bool = !!!!EQ(x, 1i32)
Forget the return type here as well.
Lunch.
6:20pm. Done with it. Right now I am thinking of ditching 32-bit arrays completely and making the default u64. It is a massive pain to keep writing that u64. Not to mention maintaining two different array and string modules.
6:25pm. No, this is not right. What might be right though is to convert i32 to u32 arrays even on the F# backend. Array length and indexing being signed there makes zero sense. If I were making a 32-bit C backend, I'd make them unsigned.
Added a TODO.
Then if I made array indexing unsigned, that would make it easier to upcast to 64-bit. If I ever made array patterns, I'd want that.
6:55pm. Let me close here. I am just chilling anyway at this point.
Tomorrow, I am going to do what I said - turn i32 into u32 arrays. The same for strings. And after that I will get to work on array literals and patterns.
inl game {sample action_response action_init terminal} = join
inl claims = failwith "TODO" // [|1,2; 1,3; 1,4; 1,5; 1,6; 1,1; 2,2; 2,3; 2,4; 2,5; 2,6; 2,1|]
inl actions = arrayu64.append (arrayu64.map claim_ claims) (arrayu64.singleton Dudo)
inl dice = failwith "TODO" // [|1..6|]
Right now the two games are almost complete, but I have to deal with these TODOs here.
Overall, today went quite nicely. None of this is going to go quickly. I just need to put in effort every day and I will reach my goals. Tomorrow arrays. The following week, CFR and UIs.
After that come deep learning based agents.
Before I start on work tomorrow, I really will take some time to open the sponsorship page for Spiral. I can't delay this even though I feel like it. Even if I had to spend my entire day to do it, I will make that a priority. Then I'll get back to programming.
I think after I plugin in tabular CFR, I'll dedicate some time and fire off the resume to a few of the companies just to see what comes out of it. I am not sure how impressive the char sheet approach will be. If I get ghosted again, I'll have to come up with some other idea.
Though it might seem like a joke, a resume such as that is in fact the ideal document a potential employer could get since it is an honest self assessment. If this approach turns out to be a problem, I'll replace the honest parts, ditch the humiliating trading segment and start making things up. I'll invent some company in Croatia, or maybe even say that I was a founder of my own. High school? I've dropped that out to start making money with my programming skills! Makes perfect sense after becoming a national champion.
Though, I'll only take this approach if I outright get ghosted again. If I am merely rejected for a valid reason I'll accept my lumps. I am not in such an adversarial position that I have to go to these lengths to make a gain. In the first place, I am trying to promote Spiral, not actually get a job."
Made it even shorter somehow
I was going to make a repo for the YAZ assignment and noticed you forked my assignment so I went to check for comments and remembered that I thought of a few ways I could make it shorter and then I spent my lunch break working on it. In the spec it says it took them 88 lines of code to write the full game so I decided to challenge myself to do less but I realized that wouldn't be that hard so I decided to make it as short as possible without doing something dumb like putting all the code in main. Just so we're clear this code was not meant to be readable and it was not meant to be good (maybe clever) just as short as possible without using a dumb trick.
Call status after activity & reduce number of calls...
Using define-globalized-minor-mode was causing spotify-remote-mode to be called repeatedly on
every switch from a buffer another buffer (or to the minibuffer). This was causing many unnecessary
API calls because I had assumed the minor mode function would be called once. By specifying :global
in the minor mode definition, the minor mode function is now called once for each toggle. This does
prevent us from offering a buffer-specific minor mode, but that doesn't seem very useful anyway?
I attempted to handle various sets of callbacks to get the status after the API calls were complete but it truly was callback hell and required a lot of ugly, repetitive code. I think the right approach would be to use something like aio or whatever is considered the best async/await/promise library currently. As it stands, I just hacked in a 1s timer to get status after any call is made.
🔥 type representing structs refined
admittedly, I've no idea of how correct the current implementation is. However! besides me being quite the inactive for the last couple days, I think I now have a general idea of how this should go on.
With a couple of handy micro-passes what's here can be accomplished. I don't think I am a fond of this approach performance wise, but indeed it gets the job done.
I would like for someone to point me in the right direction. And that's likely because of the complexity of what I myself have conjured scaring me away from doing what I want to do.
I believe tho that this can be simplified even more. I need to start removing stuff. Well nothing matters and we all gonna die, bye then!