3,197,330 events, 1,666,784 push events, 2,589,686 commit messages, 210,305,897 characters
Added and removed alot of shit cause fuck you
AHJR BH#@!UYWDQEFB UVRLBEN!@#W R!#
MOVE THE SHITTY FUCKING STUPID
accidentally put in weeks instead character
Updates for: Life is NP-hard, and then you die. -- Dave Cock
Paginate the user outfits page
My main inspiration for doing this is actually our potentially-huge upcoming Vercel bill lol
From inspecting my Honeycomb dashboard, it looks like the main offender for backend CPU time usage is outfit images. And it looks like they come in big spikes, of lots of low usage and then suddenly 1,000 requests in one minute.
My suspicion is that this is from users with many saved outfits loading their outfit page, which previously would show all of them at once.
We do have loading="lazy" set, but not all browsers support that yet, and I've had trouble pinning down the exact behavior anyway!
Anyway, paginating makes for a better experience for those huge-list users anyway. We've been meaning to do it, so here we go!
My hope is that this drastically decreases backend CPU hours immediately 🤞 If not, we'll need to investigate in more detail where these outfit image requests are actually coming from!
Note that I added the pagination to the existing outfits GraphQL endpoint, rather than creating a new one. I felt comfortable doing this because it requires login anyway, so I'm confident that other clients aren't using it; and because, while this kind of thing often creates a risk of problems with frontend and backend code getting out of sync, I think someone running old frontend code will just see only their first 30 outfits (but no pagination toolbar), and get confused and refresh the page, at which point they'll see all of them. (And I actually prefer that slightly confusing UX, to avoid getting more giant spikes of outfit image requests, lol :p)
Merge pull request #756 from MeowcaTheoRange/patch-3
funny issue template shit that I'm Sure won't fuck up everything this time
Redesign the main questline
This commit rearranges the story quests, especially the Bracada/Deyja ones. Firstly, the player no longer has to wait 4 months after saving dwarves for the story to progress. As long as all Erathia/Avlee quests are completed on time, the party is almost immediately given a "probatory access" to both Celeste and the Pit. This special circumstance allows maintaining friendly relations with both parties for a short while, until the altar pieces quest which of course can only be completed for one side -- and the other one will then consider you a traitor, which will cement the path choice. You can also reject alliance with one of the kings immediately, which gives you a bonus later on. So far you cannot initiate promotion quests during the probatory stage, but that's for next time. Took me too long already!
There's also a number of other incidental changes, such as a hack for extending npctext.txt, or reworking the human-elf war winner logic. I also feel I haven't playtested it all thoroughly enough. We'll see.
I have 0 idea why it's like this but here
Despite having a fuck ton of listed shit it still sees it as "No content changes done"
- Removed the goddamn annoying nuke launch sound from the Ravager AA and Scoprion IFV
- Buffed M107 HE & AP
- A10 increased price and build time
Implement websocket helpers
RED ALERT:
-> Change commit message cuz this one kinda sucks
-> Replace the hacks for the settings with something sane
Ability to query older versions of a vmspec
I tried to come up with a proper solution to this, but all of them had flaws.
== Options I found and explored their possibilities
- Add a new version argument to the Get function.
That's just ugly as hell. I like the Options pattern. Much easier to update without breaking 300 calls in the codebase.
- Add a new function on the Repo.
It seems odd and I think it's unnecessary because Get can handle it.
- Create a function only on the Containerd repo implementation.
That would require checks and casting everywhere we want to use it.
== Conclusion
I picked options 1, because it causes less pain not and long term. It does not matter what content store we are using, it HAS to be able to manage versions somehow, even if it's an external service, the Repository implementation has to handle versions, without versions we are are playing with a bag of venomous snakes without any kind of antidote, maybe fun, but not safe.
Related to #66
"9:30am. Time sure passes fast. The tablet should arrive in the next 1-3 days. Let me chill a bit and then I will start leg sculpting.
9:50am. Let me sculpt. I want to play around at making things smooth. I really should restart the sculpting and do it like Flycat - with the minimum of effort, but I want to internalize the feel. I do not want to put in a bunch of object and adjust it by tiny amount. I should be able to sculpt things in place for any kind of position.
10:05am. I am getting it. A combination of inflate + smooth tool works very well. The upper part needs to be more taut, and the lower legs are too short, but I've managed to get over the noodle problems.
Right now it no longer looks like a 50 yo housewife, but maybe a 30 yo who hit the wall.
https://www.youtube.com/results?search_query=blender+measure
Focus me, stop listening the Ruina ost and watch this thing.
10:15am. Let me get rid of one of the legs. It is just getting too much in the way.
10:45am. I keep going back and forth on the leg, trying to get the stars to align. Forget the upper part, let me give some definition to the lower part. But even so the upper part still have that woman-who-hit-the-wall feel.
11:15am. Hmmm, I didn't do the toes, but this is good enough to pause and review.
The look still has that woman-past-her-prime feel, and to be honest, I am not sure why. If I had such perfect self awareness that I could immediatelly understand how to fix something based on knowing the problem, I would have already made good RL agents.
I keep trying to capture Flycat's feeling and am failing. Let me stop here with my own effort for now. I think once I get the tablet and start drawing, my sculpting and my drawing efforts will synergize. Let me not forget that my grasp of the human body is still quite incomplete at this stage.
11:20am. Let me watch how Devilpeace does it.
https://www.youtube.com/watch?v=axOS7n9e6to Sculpting Leg ( Female ) Blender sculpting tutorial 2.9+ Slow and detailed
https://youtu.be/axOS7n9e6to?t=3
One thing I notice that the calves for this model are a lot bigger than mine. I know that Flycat's model is unnatural, so I've been doing the lower legs on the smaller side. But still, I do feel that the upper half is saggy even in isolation.
https://youtu.be/axOS7n9e6to?t=168
Just what am I looking at, aren't these obviously guy legs?
https://youtu.be/axOS7n9e6to?t=558
Ok, the upper ref is female.
11:35am. I skimmed the video. I don't know. None of this tells me what exactly is wrong with my own model. Let me get rid of the bottom leg.
11:40am. I just do not get it. Is the leg shape rounded in an uneven manner.
Let me watch Flycat's video.
Focus me.
https://www.youtube.com/watch?v=VzMAh66ofq0 Create a Perfect Body Base Mesh with Blender 2.92
Let me watch the first 10m of this again.
11:45am. https://youtu.be/VzMAh66ofq0?t=16
Actually right at the start, it gives me a complete reference.
Looking at this, I can immediatelly see what the problem with my own model is. If you look at the knee, it is not all the way to the right and the thigh does not just drop down. Instead the upper thigh curves outward past the crotch and then inward as it nears the knee. This gives it a feeling of tautness. Similarly, it also curves out past the waist and then inwards.
I fucked up those curves, so it is no wonder I get the feeling I am looking at saggy woman hips and legs. I went and improved the lower leg, but that did not change my perception much. The only thing I could think of is that the leg is not smooth enough, but that is not really the problem.
https://youtu.be/VzMAh66ofq0?t=29
This part where he is rotating the model is everything I need.
Sigh, I am so incompetent.
11:55am. I am taking a breather. Let me stop here for breakfast. I am going to use this as reference and see if I can improve the leg later. Tomorrow the tablet might arrive and I want to get ready.
These studies are going to become useful when it is time to draw chara portraits. Plus, it would be good to be able to showcase something."
modpost: file2alias: go back to simple devtable lookup
commit ec91e78d378cc5d4b43805a1227d8e04e5dfa17d upstream.
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] [nc: Omit rpmsg, sdw, tbsvc, and typec as they don't exist here] Signed-off-by: Nathan Chancellor [email protected] Signed-off-by: Sasha Levin [email protected]
prompt.c: add and use a GIT_TEST_TERMINAL_PROMPT=true
In 97387c8bdd9 (am: read interactive input from stdin, 2019-05-20) we we fixed a behavior change in the conversion of git-am from a shellscript to a C program by changing it from using git_prompt() to using fgets(..., stdin). This ensured that we could run:
echo y | git am --interactive [...]
But along with that in the subsequent 6e7baf246a2 (am: drop tty requirement for --interactive, 2019-05-20) we had to remove support for:
git am --interactive </dev/null
This change builds on the refactoring of git_prompt() into "normal prompt" and "wants password" functions in the preceding commit, and moves "git am --interactive" back to using the prompt function.
This allows us to have our cake and eat it too by adding a GIT_TERMINAL_PROMPT=true mode to test-lib.sh. Adjusting "git am --interactive" for use in our tests (see e.g. "t/t4257-am-interactive.sh") was what 97387c8bdd9 and 6e7baf246a2 were aiming for.
Then more recently in 09535f056b0 (bisect--helper: reimplement
bisect_autostart shell function in C, 2020-09-24) we've had the same
sort of behavior change happen to "git bisect"'s interactive question
mode, it now uses git_prompt()'s /dev/tty, not stdin.
It seems to me that using /dev/tty is desirable over using stdin, these prompts are meant to be interactive, and our acceptance of stdin was an artifact of how these commands were originally implemented in shellscript.
So let's move "git am --interactive" back to using "git_prompt()" (which is called "git_prompt_echo()" as of the preceding commit), and similarly remove the "!isatty(STDIN_FILENO)" test added in 09535f056b0, that control flow was converted as-is from the shellscript behavior.
Let's also change a similar assertion added to "git am" in 6e7baf246a2. Now we'll die on:
# no arguments provided
git am --interactive
But not:
git am --interactive </dev/null
Or:
git am --interactive <mbox
To do this we'll need to add a GIT_TEST_TERMINAL_PROMPT variable for use in test-lib.sh, by doing so this "echo input | git cmd ..." behavior of interactive commands is now isolated to our own test suite, instead of leaking out into the wild.
Now that we've done that we can exhaustively test the prompt behavior of "git bisect", which wasn't previously possible.
There is some discussion downthread of the series 97387c8bdd9 is in about whether we should always accept stdin input in these commands[1]. I think that's arguably a good idea, and perhaps we'll need to change the approach here.
Using a git_prompt_echo() that we know never needs to handle passwords should provide us with an easy path towards deciding what to do in those cases, we'll be able to consistently pick one behavior or the other, instead of having the behavior of specific commands cater to test-only needs.
The lack of _() on the new die() message is intentional. This message will only be emitted if there's a bug in our own test suite, so it's a waste of translator time to translate it.
Signed-off-by: Ævar Arnfjörð Bjarmason [email protected]
[Experiment] Lazily propagate context changes (#20890)
- Move context comparison to consumer
In the lazy context implementation, not all context changes are propagated from the provider, so we can't rely on the propagation alone to mark the consumer as dirty. The consumer needs to compare to the previous value, like we do for state and context.
I added a memoizedValue field to the context dependency type. Then in
the consumer, we iterate over the current dependencies to see if
something changed. We only do this iteration after props and state has
already bailed out, so it's a relatively uncommon path, except at the
root of a changed subtree. Alternatively, we could move these
comparisons into readContext, but that's a much hotter path, so I
think this is an appropriate trade off.
- [Experiment] Lazily propagate context changes
When a context provider changes, we scan the tree for matching consumers and mark them as dirty so that we know they have pending work. This prevents us from bailing out if, say, an intermediate wrapper is memoized.
Currently, we propagate these changes eagerly, at the provider.
However, in many cases, we would have ended up visiting the consumer nodes anyway, as part of the normal render traversal, because there's no memoized node in between that bails out.
We can save CPU cycles by propagating changes only when we hit a memoized component — so, instead of propagating eagerly at the provider, we propagate lazily if or when something bails out.
Most of our bailout logic is centralized in
bailoutOnAlreadyFinishedWork, so this ended up being not that
difficult to implement correctly.
There are some exceptions: Suspense and Offscreen. Those are special because they sometimes defer the rendering of their children to a completely separate render cycle. In those cases, we must take extra care to propagate all the context changes, not just the first one.
I'm pleasantly surprised at how little I needed to change in this initial implementation. I was worried I'd have to use the reconciler fork, but I ended up being able to wrap all my changes in a regular feature flag. So, we could run an experiment in parallel to our other ones.
I do consider this a risky rollout overall because of the potential for subtle semantic deviations. However, the model is simple enough that I don't expect us to have trouble fixing regressions if or when they arise during internal dogfooding.
This is largely based on RFC#118, by @gnoff. I did deviate in some of the implementation details, though.
The main one is how I chose to track context changes. Instead of storing
a dirty flag on the stack, I added a memoizedValue field to the
context dependency object. Then, to check if something has changed, the
consumer compares the new context value to the old (memoized) one.
This is necessary because of Suspense and Offscreen — those components
defer work from one render into a later one. When the subtree continues
rendering, the stack from the previous render is no longer available.
But the memoized values on the dependencies list are. This requires a
bit more work when a consumer bails out, but nothing considerable, and
there are ways we could optimize it even further. Conceptually, this
model is really appealing, since it matches how our other features
"reactively" detect changes — useMemo, useEffect,
getDerivedStateFromProps, the built-in cache, and so on.
I also intentionally dropped support for
unstable_calculateChangedBits. We're planning to remove this API
anyway before the next major release, in favor of context selectors.
It's an unstable feature that we never advertised; I don't think it's
seen much adoption.
Co-Authored-By: Josh Story [email protected]
- Propagate all contexts in single pass
Instead of propagating the tree once per changed context, we can check all the contexts in a single propagation. This inverts the two loops so that the faster loop (O(numberOfContexts)) is inside the more expensive loop (O(numberOfFibers * avgContextDepsPerFiber)).
This adds a bit of overhead to the case where only a single context changes because you have to unwrap the context from the array. I'm also unsure if this will hurt cache locality.
Co-Authored-By: Josh Story [email protected]
- Stop propagating at nearest dependency match
Because we now propagate all context providers in a single traversal, we can defer context propagation to a subtree without losing information about which context providers we're deferring — it's all of them.
Theoretically, this is a big optimization because it means we'll never propagate to any tree that has work scheduled on it, nor will we ever propagate the same tree twice.
There's an awkward case related to bailing out of the siblings of a context consumer. Because those siblings don't bail out until after they've already entered the begin phase, we have to do extra work to make sure they don't unecessarily propagate context again. We could avoid this by adding an earlier bailout for sibling nodes, something we've discussed in the past. We should consider this during the next refactor of the fiber tree structure.
Co-Authored-By: Josh Story [email protected]
- Mark trees that need propagation in readContext
Instead of storing matched context consumers in a Set, we can mark
when a consumer receives an update inside readContext.
I hesistated to put anything in this function because it's such a hot path, but so are bail outs. Fortunately, we only need to set this flag once, the first time a context is read. So I think it's a reasonable trade off.
In exchange, propagation is faster because we no longer need to accumulate a Set of matched consumers, and fiber bailouts are faster because we don't need to consult that Set. And the code is simpler.
Co-authored-by: Josh Story [email protected]
Add files via upload
fuck you, token. updated publis.
RSA: soter => pub: Allocate OSSL_PARAM_BLD and OSSL_PARAM
You wanted more heap allocations in your application? Here you go, OpenSSL 3 API design team has you covered. Stop complaining and enjoy your malloc() traffic. This makes want to (ノಠ益ಠ)ノ彡┻━┻
Anyhow. They invented this OSSL_PARAM thingie for passing parameters between the application and the (cryptography) provider. However, it does not really support BIGNUMs. Well, the API suggests that it does but it's very unwieldy. Supposedly, builder is able to pass BIGNUMs by reference and that's what documentation suggests, but reading the code -- I don't see anything like that, BIGNUM data is still copied.
A-a-anyhow. The non-miserable-to-use API for handling BIGNUMs is available only via allocated builders which will allocat params. And OpenSSL people on GitHub are like, "Duuuuuude, stop complaning about repackaging BIGNUMs and just use builder API". This is stupid, but that's the way it is.
You do not want to unpack BIGNUMs into native byte arrays, because
- you'd mess it up, 2) that's another copy of you private keys being placed in allocated heap, 3) supposedly, OpenSSL people are good at wiping those copies is secure allocations are used, 4) but you are certainly going to mess it up.
So I let a sigh and create a builder. This is another nudge from the OpenSSL 3 API design: one should not use raw key material or one will suffer greatly while writing code that uses raw key material. That actually makes sense (think: handling cryptography inside TPM and the key never leaves TPM's memory), but God damn it is painful to see a dozen of implicit malloc() calls made when loading keys!
Add files via upload
So imagine a cohort of people with an infectious disease. It's a simple disease like simple flu disease. So we're going to assume that ultimately, everyone recovers from the infection after a certain infectious period. We can then separate the cohort into two compartments. One is the number of people still infected with the disease and the other is the number of people who have recovered. We start with everyone in the infected compartment and end up with everyone in the recovered compartment. So far, it is simple. But how long does it take for people to move from one compartment to another? If we knew the infectious period, then could we predict how many people would be infected and recovered after one week, after a month, or how about after a year? To model this, we will use the rate of transition between I (infectious) and R (recovered). Many of you may be familiar with constant hazard rates and survival analysis. What we are doing here is basically the same thing. So first, you can model the dynamics of this cohort using just two differential equations: dI by dt equals minus Gamma times I and dR by dt equals Gamma times I. You'll recognize these as simple differential equations, where dI by dt denotes the rate of change of I with respect to time. We've just seen that the rate of flow out of the I compartment is proportional to the number of people in the I compartment, and the constant of proportionality is Gamma. We call Gamma the recovery rate. So the larger the value of Gamma, the more quickly people go from I to R. That is, the more quickly they recover. We'll make this a bit more precise very soon, and we'll describe how Gamma actually relates to the infectious period. But it turns out that this model is simple enough that we can actually write down the solution to it. Now, this is a very simple system of equations, but it's important to realize that we've already made a series of assumptions to get here. Perhaps most important is that at any given point in time, every individual in the I compartment is just as likely to experience a recovery. This is why we're able to attach this rate Gamma to everyone in the I compartment. So next, let's look at the behavior of I and R over time for different values of Gamma. We will start with a cohort of 1,000 people and simulating how they recover over time. Note that Gamma is a rate per unit time. So it has units of per day or day to the minus one. This graph has time in days along the x-axis. You can see that when we choose a value of Gamma that is 0.1 per day, some people in the cohort recover quickly, others recover slowly, but on average, it takes people 10 days to recover. When we have a higher value of Gamma, say 0.5 per day, on average, it takes people two days to recover. So what's going on here is the behavior of the exponential distribution. It turns out that for any population governed by this assumption, the time spent in the I compartment is distributed according to an exponential distribution with exponential parameter Gamma. The mean of that distribution or the mean infectious period is just one over Gamma. It makes sense, right? The shorter the infectious period, the shorter the duration, and therefore, the larger the value of Gamma. So to recap, we have just written down a simple model to describe the dynamics of an infected cohort. As long as you know the value of Gamma, you'll be able to say how many people are still infected and how many people are recovered at any given point of time. Here we've talked about the infectious period and recovery times. But now imagine more complex models that involve additional compartments and rates to describe other types of transitions like mortality. In all of these models, two important things to remember about rates like Gamma are that they are in units of inverse time, so they could be days to the minus one or even years to the minus one, and secondly, the inverse of the rate is the average duration that people spend in a given compartment.
Merge tag '0.0.1' into develop
ne, two, three! My baby don't mess around Because she loves me so This I know fo sho! But does she really wanna But can't stand to see me walk out the door Don't try to fight the feeling Because the thought alone is killin' me right now Thank God for Mom and Dad For sticking to together Like we don't know how Hey ya! Hey ya! Hey ya! Hey ya! Hey ya! Hey ya! Hey ya! Hey ya! You think you've got it Oh, you think you've got it But got it just don't get it when there's nothin' at all We get together Oh, we get together But separate's always better when there's feelings involved Know what they say -its Nothing lasts forever! Then what makes it, then what makes it Then what makes it, then what makes it Then what makes love the exception? So why, oh, why, oh Why, oh, why, oh, why, oh Are we still in denial when we know we're not happy here Hey ya! (y'all don't want to here me, ya just want to dance) Hey ya! Don't want to meet your daddy (oh ohh), just want you in my caddy (oh ohh) Hey ya! (oh, oh!) Hey ya! (oh, oh!) Don't want to meet your momma, just want to make you cum-a (oh, oh!) I'm (oh, oh) I'm (oh, oh) I'm just being honest! (oh, oh) I'm just being honest! Hey! alright now! alright now, fellas! Yea? Now, what cooler than being cool? Ice cold! I can't hear ya! I say what's, what's cooler than being cool? Ice cold! Alright alright alright alright alright alright alright alright alright alright alright alright alright alright alright alright! Okay, now ladies! Yea? Now we gonna break this thang down for just a few seconds Now don't have me break this thang down for nothin' I want to see you on your badest behavior! Lend me some sugar, I am your neighbor! Ah! Here we go now, Shake it, shake it, shake it, shake it, shake it Shake it, shake it, shake it, shake it Shake it like a Polaroid picture! Hey ya! Shake it, shake it, shake it, shake it, shake it Shake it, shake it, shake it, suga! Shake it like a Polaroid picture! Now all the Beyonce's, and Lucy Liu's, and baby dolls Get on tha floor get on tha floor! Shake it like a Polaroid picture! Oh, you! oh, you! Hey ya!(oh, oh) Hey ya!(oh, oh) Hey ya!(oh, oh) Hey ya!(oh, oh) Hey ya!(oh, oh) Hey ya!(oh, oh)
Merge pull request #1 from Aligh5831/main
Fuck you too
android: disable background location access due to Google Play Store policy
I submitted explanatory text, but without a video:
While flying an aircraft, XCSoar is designed to record the flight path, and continues to do so while the app is in background. Without access to the GPS while in background, that part of the flight path is missing, and is not available for in-flight and post-flight analysis. That defies XCSoar's primary purpose.
However, the evil Google overlords have rejected this explanation, and today, XCSoar has been removed from the Play Store:
Reasons of violation
Issue with your app
Your app requests location in the background for either unapproved and/or undisclosed purposes. Apps that request location in the background must successfully complete a console-based declaration process and adequately disclose use to users. Publishing Status
[...]
App status: Removed
Your app has been removed due to this policy issue. This app won't be available to users until you submit a compliant update.
This change tries to get XCSoar back into the Play Store quickly, until we have decided what to do. Maybe we'll decide to keep XCSoar off the Play Store forever, and switch to F-Droid.
Unfortunately, this means XCSoar needs to stay in foreground. Sorry, blame Google for this shit.
fixed your css
fuck you im god now i can code css
OpenGL = garbage
Here's why.
So for some reason some cunt decided to make Y=0 in UV coordinates be the BOTTOM of the texture. Whoever came up with this stupid decision, I curse you and your programming carreer over the hours I've spent debugging stupid issues related to this. The problem I came across was that I was sending in images where Y=0 is at the top. I was wondering why my images looked correct and why framebuffers were flipped around, and here's why: When you send an image into a texture, the first scanline of the image (that is, the one that begins at byte 0) will be assigned Y=0 in UV coordinates, going upwards as it scans more lines. Now, in NDC, the image will appear flipped, but then the orthographic projection flips the coordinate space around, which means that the coordinates of the image will indeed be correct. But what happens if you try to draw a framebuffer texture instead? Well, shit goes downhill, and now you have to deal with the fact that for OpenGL Y=0 is at the bottom of the texture. You flip the UVs and call it a day. So framebuffeer textures will be flipped around, but your good ol' normal image textures won't. Because of this, when sending in external data to fill the framebuffer with (using glTexSubImage), you need to flip all the pixels 'round on the Y axis, as well as the Y position you're plopping the texture sub image on.
Jesus fuck, this took me hours to debug. So here's to future generations HOPEFULLY not having to debug this. At least I know I won't have to.
Take care.
feat: make Duvessa permanently berserk when Dowan dies
She waits to see you before going crazy. But the game of "kill Dowan first then escape to wait out the berserk and fight a normal Duvessa" always seemed a bit sad, considering Dowan's grief gave him permanent new strength.
So lets let the bond run a bit deeper, and make Duvessa's rage eternal.
holy fucking shit this is so close to working right