there were a lot of events recorded by gharchive.org of which 2,319,150 were push events containing 3,480,449 commit messages that amount to 259,949,880 characters filtered with words.py@e23d022007... to these 51 messages:
[SQUASHED] core: Blacklist pixel system feature from Google Photos
We want to include the P21 experience flag to enable new features,
however it seems like Google Photos uses it to decide whether to use the
TPU tflite delegate. There doesn't seem to be any fallback so we need to
make sure the feature is not exposed to the app so that a normal
NNAPI/GPU delegate can be used instead.
Test: Google Photos editor with PIXEL_2021_EXPERIENCE feature in product
Signed-off-by: Kuba Wojciechowski <nullbytepl@gmail.com>
Change-Id: I51a02f8347324c7a85f3136b802dce4cc4556ac5
commit 67eb31b3bb43d06fcc7f6fdb2f92eb486451cae6 Author: kondors1995 normandija1945@gmail.com Date: Thu Jun 9 17:39:25 2022 +0530
Core: Extend Pixel experience Blacklist For Google Photos
Turns out having these brakes Original quality backups.
Since these indicate that the device is pixel 4 with in the turn brakes device spoofing as OG pixel
Change-Id: I336facff7b55552f094997ade337656461a0ea1d
commit 508a99cde60b73dc3f1e843d569bca31def35988 Author: ReallySnow reallysnow233@gmail.com Date: Fri Dec 31 16:40:23 2021 +0800
base: core: Blacklist Pixel 2017 and 2018 exclusive for Google Photos
* In this way can use PixelPropsUtils to simulate the Pixel XL prop
method to use the unlimited storage space of Google Photos
* Thanks nullbytepl for the idea
Change-Id: I92d472d319373d648365c8c63e301f1a915f8de9
commit aaf07f6ccc89c2747b97bc6dc2ee4cb7bd2c6727 Author: Akash Srivastava akashniki@gmail.com Date: Sat Aug 20 19:04:32 2022 +0700
core: Pixel experience Blacklist For Google Photos for Android 13
* See, in Android 13 pixel_experience_2022_midyear was added, which needs to be blacklisted aswell
Change-Id: Id36d12afeda3cf6b39d01a0dbe7e3e9058659b8e
commit 9d6e5749a988c9051b1d47c11bb02daa7b1b36fd Author: spezi77 spezi7713@gmx.net Date: Mon Jan 31 19:17:34 2022 +0100
core: Rework the ph0t0s features blacklist
* Moving the flags to an array feels more like a blacklist :P
* Converted the flags into fully qualified package names, while at it
Signed-off-by: spezi77 <spezi7713@gmx.net>
Change-Id: I4b9e925fc0b8c01204564e18b9e9ee4c7d31c123
commit d7201c0cff326a6374e29aa79c6ce18828f96dc6 Author: Joey Huab joey@evolution-x.org Date: Tue Feb 15 17:32:11 2022 +0900
core: Refactor Pixel features
* Magic Eraser is wonky and hard to
enable and all this mess isn't really worth
the trouble so just stick to the older setup.
* Default Pixel 5 spoof for Photos and only switch
to Pixel XL when spoof is toggled.
* We will try to bypass 2021 features and Raven
props for non-Pixel 2021 devices as apps usage
requires TPU.
* Remove P21 experience system feature check
Change-Id: Iffae2ac87ce5428daaf6711414b86212814db7f2
aot autograd refactor: make all synthetic base logic layered in a single location (#96235)
This refactor doesn't significantly change LoC in aot autograd, but I think this nets out to making it clearer (interested in peoples' thoughts).
The idea is that I tried to re-write the part of aot autograd that deals with synthetic bases in a layered way, similar to how Ed wrote the logic for dedup'ing inputs: it happens in one place, and all of the downstream transformation in aot autograd don't have to worry about it.
Specifically, I added a new function aot_wrapper_synthetic_base, similar to the existing aot_wrapper_dedupe.
The benefit: none of the other code in aot autograd needs to think about synthetic bases (previously, synthetic base code was intertwined in several places).
The downsides: there are two.
(1) aot_wrapper_synthetic_base() needs to have its own epilogue. There is one particularly hairy case, where factoring the synthetic base logic to a single location was painful: If you have two inputs that alias each other, where one gets a data mutation, and the other gets a metadata mutation.
Ordinarily, metadata mutations are handled by the runtime epilogue, in create_runtime_wrapper. However, now that things are factored this way, the runtime wrapper operates only on synthetic bases instead of operating on the original inputs. For data mutations, it is fine to apply the data mutation to the synthetic base instead of the original input alias. But for metadata mutations, we need to apply the metadata mutation directly to the original inputs.
The way that I handled this was by tracking which inputs slot into this specific case (part of a synthetic base, and get metadata mutations), and updateing the flat_fn() that we pass downstream to return these updated inputs as extra outputs. From the perspective of downstream logic, these are real user outputs, that it can treat like any other user outputs. aot_wrapper_synthetic_base will know to grab these extra outputs and use them to apply the metadata mutations.
This was pretty annoying, but has the benefit that all of that logic is encapsulated entirely in aot_wrapper_synthetic_base().
(2) input mutations are now performed on the synthetic base instead of the individual aliases.
You can see the original code comment here for details. We used to do the optimized thing in this case, and now we do the less optimized thing (copying the entire synthetic base, instead of the potentially smaller alias).
To be fair, we had no data showing that this optimization was showing improvements on any models in practice. I also think that the main reason anyone would ever run across this problem is because of a graph break - so if you care about perf, you probably want to avoid the extra graph breaks to begin with. I haven't added any warnings for this, but we probably could depending on what people think.
Pull Request resolved: pytorch/pytorch#96235 Approved by: https://github.com/ezyang
power: Introduce OnePlus 3 fingerprintd thaw hack
Taken from Oneplus 3, this hack will make fingerprintd recover from suspend quickly.
Small fixes for newer kernels since we're coming from 3.10.108..
Change-Id: I0166e82d51a07439d15b41dbc03d7e751bfa783b Co-authored-by: Cyber Knight cyberknight755@gmail.com [cyberknight777: forwardport and adapt to 4.14] Signed-off-by: Shreyansh Lodha slodha96@gmail.com Signed-off-by: Pierre2324 pdbbasketball@gmail.com Signed-off-by: PainKiller3 ninadpatil100@gmail.com Signed-off-by: Dhruv dhruvgera61@gmail.com Signed-off-by: Cyber Knight cyberknight755@gmail.com
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 paulmck@kernel.org Tested-by: Paul E. McKenney paulmck@kernel.org Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Signed-off-by: Ingo Molnar mingo@kernel.org Link: https://lkml.kernel.org/r/20200622125649.GC576871@hirez.programming.kicks-ass.net Signed-off-by: Samuel Pascua pascua.samuel.14@gmail.com
add dirs command to std lib (#8368)
Prototype replacement for enter, n, p, exit built-ins
implemented as scripts in standard library.
MVP-level capabilities (rough hack), for feedback please. Not intended
to merge and ship as is.
(Description of your pull request goes here. Provide examples and/or screenshots if your changes affect the user experience.)
New command in standard library
〉use ~/src/rust/nushell/crates/nu-utils/standard_library/dirs.nu
---------------------------------------------- /home/bobhy ----------------------------------------------
〉help dirs
module dirs.nu -- maintain list of remembered directories + navigate them
todo:
* expand relative to absolute paths (or relative to some prefix?)
* what if user does `cd` by hand?
Module: dirs
Exported commands:
add (dirs add), drop, next (dirs next), prev (dirs prev), show (dirs show)
This module exports environment.
---------------------------------------------- /home/bobhy ----------------------------------------------
〉dirs add ~/src/rust/nushell /etc ~/.cargo
-------------------------------------- /home/bobhy/src/rust/nushell --------------------------------------
〉dirs next 2
------------------------------------------- /home/bobhy/.cargo -------------------------------------------
〉dirs show
╭───┬─────────┬────────────────────╮
│ # │ current │ path │
├───┼─────────┼────────────────────┤
│ 0 │ │ /home/bobhy │
│ 1 │ │ ~/src/rust/nushell │
│ 2 │ │ /etc │
│ 3 │ ==> │ ~/.cargo │
╰───┴─────────┴────────────────────╯
------------------------------------------- /home/bobhy/.cargo -------------------------------------------
〉dirs drop
---------------------------------------------- /home/bobhy ----------------------------------------------
〉dirs show
╭───┬─────────┬────────────────────╮
│ # │ current │ path │
├───┼─────────┼────────────────────┤
│ 0 │ ==> │ /home/bobhy │
│ 1 │ │ ~/src/rust/nushell │
│ 2 │ │ /etc │
╰───┴─────────┴────────────────────╯
---------------------------------------------- /home/bobhy ----------------------------------------------
〉Haven't even looked at stdlib tests.nu yet.
Other todos:
- address module todos.
- integrate into std lib, rather than as standalone module. Somehow
arrange for
use .../standard_library/std.nuto load this module without having to put all the source instd.nu? - Maybe command should be
std dirs ...? - what else do
enterandexitdo that this should do? Then deprecate those commands.
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
cargo fmt --all -- --checkto check standard code formatting (cargo fmt --allapplies these changes)cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collectto check that you're using the standard code stylecargo test --workspaceto check that all tests pass
If your PR had any user-facing changes, update the documentation after the PR is merged, if necessary. This will help us keep the docs up to date.
Post-Revolutionary Fervor station trait, revolutionary bedsheets, and a megaphone (#73799)
Upon revolution success, the chosen headrev will now also receive a megaphone, and a "revolutionary bedsheet" repurposed from a stolen CC bedsheet to commemorate their success. The post-revs confusion and lack of command/security usually leads to an instantaneous, total breakdown in cohesion. It's every man for himself -- that's no way to run a commune! Just because the revolution has succeeded and nobody can see your big blue "R" anymore doesn't mean you can't be a leader!
This also adds a new revolution-themed negative station trait -- Post-Revolutionary Fervor. When present, this trait trashes the command areas at the start of the round. This means cracked windows, broken consoles, vendors getting knocked over, and the occasional dead greytider.
If you start cleaning at the start of the round, you might finish right as the next batch of revs decides to crop up.
Giving one of the headrevs a bigger voice and a cool cape (or uncool, depending on how you view the sprite) means that there's a chance for them to step up and try to keep the wheels on. Just remember -- Nobody is obligated to actually listen to this person, it's just a bedsheet.
Adds a neato station trait, which probably counts as command gameplay content.
🆑 Rhials add: The headrev who receives the revolutionary banner after a win will also receive a commemorative bedsheet and megaphone. add: Post-Revolutionary Fervor station trait. I hope you enjoy fixing broken computer screens. spriteadd: A revolutionary bedsheet. /🆑
Fix for varediting bitflags. (#2735)
I am honestly at a loss as to what is happening here. I do not speak
HTML all too well, and at cursory reading buttons should be returning
their value, which is 1, 2 and so on. But on debugging, they
actually return their text (Save, Cancel), which does not proceed to
work with the code receiving it. Changed that code accordingly, and then
edited the values for good measure in case somebody better versed in
HTML would get a heart attack from my folly.
Also, this looks ugly to me. Which button is which flag here?
This, in my humble opinion, is easier to read (would actually look better outside of local server messing fancy windows as is its wont):
In the process, I confess, my HTML illiteracy broke a little something
again. But we are not actually using slidecolor, so hopefully it is
not actually important.
Is fix.
See above.
🆑 admin: Editing bitflag variables actually works now. /🆑
[SDPA] Add an optional scale kwarg (#95259)
This PR adds an optional kwarg to torch torch.nn.functional.scaled_dot_product_attention() The new kwarg is a scaling factor that is applied after the q@k.T step of the computation. Made updates to the efficient kernel to support but flash and math were minimally updated to support as well.
Will reduce the complexity of: #94729 and has been asked for by a couple of users.
- As far as I know I did this the correct way and this both BC and FC compliant. However I always seem to break internal workloads so I would love if someone can advice I did this right?
- I named the optional arg 'scale'. This is probably dumb and I should name it 'scale_factor'. I will make this change but this is annoying and it will require someone thinking we should rename.
- 'scale' is interpreted as
Q@K.T * (scale)
Pull Request resolved: pytorch/pytorch#95259 Approved by: https://github.com/cpuhrsch
Buffs Excav Laser Module (#5174)
Buffs Excav laser module. Inconsisten with the one hit of rocks. Hopefully this ammends it specially since scatterlenses are getting removed (although nobody used them in combat yet.)
Scatter lense gone, legitimate mining tool needs a buff. The other options (Phoron Bore) are a sick joke with how slow clunky they are to use.
🆑 balance: Meatier sound on excav laser. Higher excav power to consistently one shot rocks. /🆑
Scattershot nerfs (#5175)
Sniper laser was tame.
This is bullshit. Splurting out 180 damage with high AP with no delay is not okay. Its as bullshit as most FCU we had. Mainly removed scatter on high powered lasers and bloody stuns so the scatter lense may stay for the mining tool (as there is no way to increase firerate on a projectile.
Ever got hit at close range by the particle defender on main? Yeah that is not fun.
🆑 balance: Scattershot on high powered weapons nerfed. Heavy laser and laser cannon beam and electrode now wont create submunitions. Stun beam submunition count lowered. /🆑
Mashes several of the Whitesands Survivor Camp ruins into one extra large ruin (#1640)
Combines the whitesands surface camp adobe, farm, gunslingers, survivors, hunters and saloon into one massive, 59x59 ruin. Some various extra loot and changes have been made throughout, generally to improve the experience of digging through the trash for goodies. Changes the riot shotgun in the saloon to a double barrel shotgun. Also cleans up the various issues with the ruins, like walls under doors, or area passthroughs being used excessively over the outside of the ruins, resulting in them generating in the middle of mountains buried in the rock.
"Well, why didn't you add the drugstore?" The loot in it was too good. The stuff in there can really help a ship get on its feet, and I am not gonna deprive them of that just to shove it in an already packed massive ruin area. I'm not saying it doesn't need its own remap, just that it doesn't fit well with the other camps put into this ruin.
- I affirm that I have tested all of my proposed changes and that any issues found during tested have been addressed.
"a ruin that is tiny and sucks on purpose is still bad" and holy shit did most of the camps fit this criteria. Survivor, Gunslinger, and Hunter camp variants were the smallest ruins in the game next to the one that was just a single tumor, and constantly took up entire map generations just to be a massive dissapointment to any player that came across them. Or they would spawn in the middle of an acid lake. Either way this ruin is massive and should provide a breath of fresh air for scavengers and combat hungry miners alike.
Ingame, two pics due to view range not being large enough to get the
full thing at a good quality.
🆑 add: whitesands_surface_camp_combination, a survivor village comprised of smaller revamped whitesands camps all packaged in one ruin. can be found in the map catalogue. del: whitesands_surface_camp adobe, farm, gunslingers, survivors, hunters and saloon, for being tiny ruins that suck. /🆑
Co-authored-by: Bjarl 94164348+Bjarl@users.noreply.github.com
holy shit i spent ages trying to troubleshoot tag-7 wondering why it wasn't disappearing when it was actually tag-3 that was f**ked
Station Trait: Spider Infestation (#73893)
Hate having your cables eaten by mice? Nanotrasen have heard your complaints and settled on a natural, organic, and eco-friendly solution.
When this station trait is active, roundstart and event mouse spawns have a chance to instead be replaced with duct spiders (both will exist, it doesn't remove mice). Duct spiders are largely harmless to humans, actively hunt other maintenance creatures (such as mice), and have only one tiny downside.
These mobs can also sometimes be spawned by a minor scrubber clog event.
As a side note, all spider basic mobs with AI (except Araneus) will now try to automatically fill a small area around them with webs.
Also I made it so that mobs will ignore their random_walking behaviour
if they're engaged in a do_after, just in case.
Adds a little bit of variety to things which can slightly annoy you in maintenance. Spiders will automatically make places they live in look like spiders live there.
🆑 add: A station trait which sometimes populates maintenance with small spiders. You can wear them as a hat if you wanted to have a spider on your head for some reason. add: Spider mobs will automatically start webbing up their environment. /🆑
lib/sort: make swap functions more generic
Patch series "lib/sort & lib/list_sort: faster and smaller", v2.
Because CONFIG_RETPOLINE has made indirect calls much more expensive, I thought I'd try to reduce the number made by the library sort functions.
The first three patches apply to lib/sort.c.
Patch #1 is a simple optimization. The built-in swap has special cases for aligned 4- and 8-byte objects. But those are almost never used; most calls to sort() work on larger structures, which fall back to the byte-at-a-time loop. This generalizes them to aligned multiples of 4 and 8 bytes. (If nothing else, it saves an awful lot of energy by not thrashing the store buffers as much.)
Patch #2 grabs a juicy piece of low-hanging fruit. I agree that nice simple solid heapsort is preferable to more complex algorithms (sorry, Andrey), but it's possible to implement heapsort with far fewer comparisons (50% asymptotically, 25-40% reduction for realistic sizes) than the way it's been done up to now. And with some care, the code ends up smaller, as well. This is the "big win" patch.
Patch #3 adds the same sort of indirect call bypass that has been added to the net code of late. The great majority of the callers use the builtin swap functions, so replace the indirect call to sort_func with a (highly preditable) series of if() statements. Rather surprisingly, this decreased code size, as the swap functions were inlined and their prologue & epilogue code eliminated.
lib/list_sort.c is a bit trickier, as merge sort is already close to optimal, and we don't want to introduce triumphs of theory over practicality like the Ford-Johnson merge-insertion sort.
Patch #4, without changing the algorithm, chops 32% off the code size and removes the part[MAX_LIST_LENGTH+1] pointer array (and the corresponding upper limit on efficiently sortable input size).
Patch #5 improves the algorithm. The previous code is already optimal for power-of-two (or slightly smaller) size inputs, but when the input size is just over a power of 2, there's a very unbalanced final merge.
There are, in the literature, several algorithms which solve this, but they all depend on the "breadth-first" merge order which was replaced by commit 835cc0c8477f with a more cache-friendly "depth-first" order. Some hard thinking came up with a depth-first algorithm which defers merges as little as possible while avoiding bad merges. This saves 0.2*n compares, averaged over all sizes.
The code size increase is minimal (64 bytes on x86-64, reducing the net savings to 26%), but the comments expanded significantly to document the clever algorithm.
TESTING NOTES: I have some ugly user-space benchmarking code which I used for testing before moving this code into the kernel. Shout if you want a copy.
I'm running this code right now, with CONFIG_TEST_SORT and CONFIG_TEST_LIST_SORT, but I confess I haven't rebooted since the last round of minor edits to quell checkpatch. I figure there will be at least one round of comments and final testing.
This patch (of 5):
Rather than having special-case swap functions for 4- and 8-byte objects, special-case aligned multiples of 4 or 8 bytes. This speeds up most users of sort() by avoiding fallback to the byte copy loop.
Despite what ca96ab859ab4 ("lib/sort: Add 64 bit swap function") claims, very few users of sort() sort pointers (or pointer-sized objects); most sort structures containing at least two words. (E.g. drivers/acpi/fan.c:acpi_fan_get_fps() sorts an array of 40-byte struct acpi_fan_fps.)
The functions also got renamed to reflect the fact that they support multiple words. In the great tradition of bikeshedding, the names were by far the most contentious issue during review of this patch series.
x86-64 code size 872 -> 886 bytes (+14)
With feedback from Andy Shevchenko, Rasmus Villemoes and Geert Uytterhoeven.
Link: http://lkml.kernel.org/r/f24f932df3a7fa1973c1084154f1cea596bcf341.1552704200.git.lkml@sdf.org Signed-off-by: George Spelvin lkml@sdf.org Acked-by: Andrey Abramov st5pub@yandex.ru Acked-by: Rasmus Villemoes linux@rasmusvillemoes.dk Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Cc: Rasmus Villemoes linux@rasmusvillemoes.dk Cc: Geert Uytterhoeven geert@linux-m68k.org Cc: Daniel Wagner daniel.wagner@siemens.com Cc: Don Mullis don.mullis@gmail.com Cc: Dave Chinner dchinner@redhat.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org
lib/list_sort: optimize number of calls to comparison function
CONFIG_RETPOLINE has severely degraded indirect function call performance, so it's worth putting some effort into reducing the number of times cmp() is called.
This patch avoids badly unbalanced merges on unlucky input sizes. It slightly increases the code size, but saves an average of 0.2*n calls to cmp().
x86-64 code size 739 -> 803 bytes (+64)
Unfortunately, there's not a lot of low-hanging fruit in a merge sort; it already performs only nlog2(n) - Kn + O(1) compares. The leading coefficient is already at the theoretical limit (log2(n!) corresponds to K=1.4427), so we're fighting over the linear term, and the best mergesort can do is K=1.2645, achieved when n is a power of 2.
The differences between mergesort variants appear when n is not a power of 2; K is a function of the fractional part of log2(n). Top-down mergesort does best of all, achieving a minimum K=1.2408, and an average (over all sizes) K=1.248. However, that requires knowing the number of entries to be sorted ahead of time, and making a full pass over the input to count it conflicts with a second performance goal, which is cache blocking.
Obviously, we have to read the entire list into L1 cache at some point, and performance is best if it fits. But if it doesn't fit, each full pass over the input causes a cache miss per element, which is undesirable.
While textbooks explain bottom-up mergesort as a succession of merging passes, practical implementations do merging in depth-first order: as soon as two lists of the same size are available, they are merged. This allows as many merge passes as possible to fit into L1; only the final few merges force cache misses.
This cache-friendly depth-first merge order depends on us merging the beginning of the input as much as possible before we've even seen the end of the input (and thus know its size).
The simple eager merge pattern causes bad performance when n is just over a power of 2. If n=1028, the final merge is between 1024- and 4-element lists, which is wasteful of comparisons. (This is actually worse on average than n=1025, because a 1204:1 merge will, on average, end after 512 compares, while 1024:4 will walk 4/5 of the list.)
Because of this, bottom-up mergesort achieves K < 0.5 for such sizes, and has an average (over all sizes) K of around 1. (My experiments show K=1.01, while theory predicts K=0.965.)
There are "worst-case optimal" variants of bottom-up mergesort which avoid this bad performance, but the algorithms given in the literature, such as queue-mergesort and boustrodephonic mergesort, depend on the breadth-first multi-pass structure that we are trying to avoid.
This implementation is as eager as possible while ensuring that all merge passes are at worst 1:2 unbalanced. This achieves the same average K=1.207 as queue-mergesort, which is 0.2n better then bottom-up, and only 0.04n behind top-down mergesort.
Specifically, defers merging two lists of size 2^k until it is known that there are 2^k additional inputs following. This ensures that the final uneven merges triggered by reaching the end of the input will be at worst 2:1. This will avoid cache misses as long as 3*2^k elements fit into the cache.
(I confess to being more than a little bit proud of how clean this code turned out. It took a lot of thinking, but the resultant inner loop is very simple and efficient.)
Refs: Bottom-up Mergesort: A Detailed Analysis Wolfgang Panny, Helmut Prodinger Algorithmica 14(4):340--354, October 1995 https://doi.org/10.1007/BF01294131 https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.5260
The cost distribution of queue-mergesort, optimal mergesorts, and power-of-two rules Wei-Mei Chen, Hsien-Kuei Hwang, Gen-Huey Chen Journal of Algorithms 30(2); Pages 423--448, February 1999 https://doi.org/10.1006/jagm.1998.0986 https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.4.5380
Queue-Mergesort Mordecai J. Golin, Robert Sedgewick Information Processing Letters, 48(5):253--259, 10 December 1993 https://doi.org/10.1016/0020-0190(93)90088-q https://sci-hub.tw/10.1016/0020-0190(93)90088-Q
Feedback from Rasmus Villemoes linux@rasmusvillemoes.dk.
Link: http://lkml.kernel.org/r/fd560853cc4dca0d0f02184ffa888b4c1be89abc.1552704200.git.lkml@sdf.org Signed-off-by: George Spelvin lkml@sdf.org Acked-by: Andrey Abramov st5pub@yandex.ru Acked-by: Rasmus Villemoes linux@rasmusvillemoes.dk Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Cc: Daniel Wagner daniel.wagner@siemens.com Cc: Dave Chinner dchinner@redhat.com Cc: Don Mullis don.mullis@gmail.com Cc: Geert Uytterhoeven geert@linux-m68k.org Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org
rifles!!!1
fixes descs
lathemags
oops i forgot a mag
holy shit hitting / is not that hard
Update code/modules/projectiles/ammunition/boxes.dm
Co-authored-by: Jux 68120725+juxjux9930@users.noreply.github.com Update code/modules/projectiles/ammunition/boxes.dm
Co-authored-by: Jux 68120725+juxjux9930@users.noreply.github.com Update code/modules/projectiles/ammunition/boxes.dm
Co-authored-by: Jux 68120725+juxjux9930@users.noreply.github.com
Reworks trashbags slightly (#73761)
I'm a bit sad about the state of trashbags. They're very clunky to use, so they almost never get touched. S depressing. Let's try and fix that.
Let's make em fit in the belt slot (again), but as a tradeoff we'll make it harder to pull one thing from your bag. We'll give it a say, 1.5 second delay, so you can't quickdraw from em. If you try and dump them out into something else, we'll throw any spillover on the ground below you
I'm also doing some general code cleanup here. Making procs more readable, vars more direct, removing some old legacy stuff. I've added a remove_single proc to hook into via subtype, which takes a mob as input. this has required placing extra requirement on some helper procs, but fortunately it's not something they're unable to meet.
My hope is this will make garbage bags usable without being stupid.
I don't see these get used at all, cause they're a pain to carry around. They got gimped because people were using them as infinite storage for shotgun shells and other small items. I've made using them for this sort of thing hard and slow, so I think we oughta be fine. If not I'll do some more touching, maybe give the autodrop a delay.
🆑 balance: The janitor's trashbag now fits on his belt. In exchange, taking something out of it sends a visible message, and has a delay. /🆑
Co-authored-by: san7890 the@san7890.com
All hail The Pickle Jar, harbringer of better crafting (#73939)
Fixes #73841
It is the 12th of March, 2023. Around 3am. I have published a Pull Request which involves circuits, and got reminded of my low GBP. I go into the issues tab to see if there's anything someone of my low skill caliber could tackle. I see it; Pickles. "How hard could I be?" I ask myself, foolishly unaware of the dangers that would soon overcome me. Surely it must've been a mistype, I thought. Surely someone accidentally confused pickles and cucumbers. "Wait, the pickles are supposed to be created on the jar when the jar is created", I say foolishly. "Wait, its putting the ingredients used for the jar in the jar, that doesn't explain why the pickles aren't there though", I say foolishly "Wait, whoever tried fixing this earlier fucking qdel'd the beaker and called it a day????", I say, foolishly.
Anyways I changed how the crafting menu distincts between categories, instead of checking whether or not the path is for food, it checks the actual categories themselves (why didn't it do this already), meaning that you can have non-food items on the food tab if it has a food category. Did this by adding a list that includes all crafting categories, so in the future when adding new categories you'll have to add them twice, which sucks, but oh well.
Also added a new variable to craftable items, which makes it so that you can not delete a container's contents if you so wish (why was this the default).
All this so that when you craft pickles, it actually crafts pickles instead of cucumbers.
I spent hours on this, its 6:30am as I'm typing this. I'm tired. Fucking pickles.
Super duper ultra thanks to FinalPotato for guiding me and suffering with me through this and teaching me so much about DM and BYOND. I cannot emphasize just how helpful and awesome they were thank you thank you thank you <3
Bug fixing be good
🆑 fix: The jar of pickles, after millenia, finally actually contains pickles. All hail the jar of pickles. /🆑
Polishes some side sources of light and color (#73936)
Circuit floors glow! but it looks like crap cause it's dim and the colors are washed out. I'd like to make them look nicer. Let's make them more intense and longer range, and change the colors over to more vivid replacements.
While I'm here, these should really use power and turn on and off based off that. Simple enough to do, just need to hook into a signal (and add a setter for turf area, which cleans up other code too).
Desklamps look bad. They're fullwhite, have a way too large range.Crummy. Let's lower their lightrange from 5 to 3.5, and make the ornate ones warmer, and the more utilitarian ones cooler. The clown one can be yellow because it's funny
I'm renaming a color define here so I'm touching more files then you'd expect
Increases the light range of request consoles, status displays, newscasters, and air alarms (keycard machines too, when they're awaiting input at least) Increases the brightness of air alarms, I think they should be on par with apcs, should be able to tell when they're good/bad. Increases the brightness of vending machines (I want them to light up the tiles around them very lightly, I think it's a vibe)
Fixes a bug with ai status displays where they'd display an emissive even if they didn't have anything on their screen, looking stupid. This was decently easy but required a define. Looked really bad tho
Pretty
Circuit Floors
Old
New
Desk Lights
Old
New
The niknack changes are more minor so I'm not gonna grab photos for them. I can if you'd like but I don't think it's necessary. Mostly a vibes in dark spaces sorta thing
🆑 add: I made circuit floors brighter and more vivid. add: Made air alarms, vending machines, newscasters, request consoles, status displays and keycard machines slightly "brighter" (larger light range, tho I did make air alarms a bit brighter too) add: Tweaked desklamps. Lower range, and each type gets its own coloring instead of just fullwhite. fix: AI displays are no longer always emissive, they'll stop doing it if they aren't displaying anything. Hopefully this'll look nicer /🆑
You can't instantly resist out of an unlocked labor camp teleporter if you are handcuffed (#73983)
If you are restrained, and placed into an unlocked labor camp teleporter, you cannot instantly resist out of it. However the resist timer is cut in half while unlocked.
Getting someone into the gulag teleporter is an incredibly un-necessary pain in the rear because simply spamming resist turns it into a game where you have to shove them in, then really quick go over to the computer and slam the lock button. This is... kinda lame. A lot of new player security officers get got by this, and I think it's sad. Inb4 "Skill issue"
🆑 Melbert balance: If you are handcuffed, you can't instantly resist out of an unlocked labor camp teleporter (however, resist time is halved). /🆑
platform: always reconfigure IP routes even if removed externally
NML3Cfg is stateful, that means it remembers which address/route it
configured earlier. That is important because the API users of NML3Cfg
only say what the want to configure now, and NML3Cfg needs to remove
addresses/routes that it configured earlier but are no longer to be
present. Also, NetworkManager wants to allow the user to add
addresses/routes externally with ip addr|route add and NetworkManager
not removing it. This is a common use case for dispatcher scripts, but
in general, we want to allow other components to add addresses/routes.
We try something similar with the removal of routes/addresses managed by NetworkManager. When NetworkManager adds a route/address, which later disappears, then we assume that the user intentionally removed the address/route and take the hint to not re-add it.
However, it doesn't work. It is problematic for two reasons:
-
kernel can automatically remove routes. For example, deleting an IPv4 address that is the prefsrc of a route, will cause kernel to delete that route. Sure, we may be unable to re-configure the route at this moment, but we shouldn't remember indefinitely that the route is supposed to be absent. Rather, we should re-add it when possible.
-
kernel is a pain with validating consistencies of routes. For example, when a route has a nexthop gateway, then the gateway must be onlink (directly reachable), or kernel refuses to add it with "Nexthop has invalid gateway". Of course, when removing the onlink route kernel is fine leaving the gateway route behind, which it would otherwise refuse to add. Anyway. Such interdependencies for when kernel rejects adding a route with "Nexthop has invalid gateway" are non-trivial. We try to work around that by always adding the necessary onlink routes. See nm_l3_config_data_add_dependent_onlink_routes(). But if the user externally removed the dependent onlink route, and NetworkManager remembers to not re-adding it, then the efforts from nm_l3_config_data_add_dependent_onlink_routes() are ignored. This causes ripple effects and NetworkManager will also be unable to add the nexthop route.
Trying to preserve absence of routes that NetworkManager would like to configure is not tenable. Don't do it anymore. There was anyway no guarantee that on the next update NetworkManager wouldn't try to re-add the route in question. For example, if the route came from DHCP, and the lease temporarily went away and came back, then NetworkManager probably would have (correctly) forgotten that the user wished that the route be absent. This did not work reliably and it just causes problems.
Full-PWA
Yay! So happy to have things getting this far now. I did some more cross-browser testing today, and everything is working great in Chrome, Safari, and Firefox on desktop, as well as Safari on mobile, iPad and iOS!
Gonna start adding more nice-to-have PWA features, like Web Share, Web Share Target, File Handling, File System Access, you name it.
I didn't quite realize that both the Web App Manifest, and the Theme Color entry are both supported on Standalone mode on iOS! Just found that out in person today, and I was very suprised to see that! I think it was added a while back, but I think it took a little while for it to fully roll out, and be bug free.
https://firt.dev/notes/pwa-ios/
This makes PWA setup so much nicer now! You don't have to worry about iOS-specific meta tags anymore, it all just works exactly like you want it to. This is also the case for PWA icons, which is an even better thing to find out! Now you essentially only have to make two icon sizes (maybe 3, now that iOS is using them. I was using 192 and 512 before, and I think iOS likes to look for 180).
So I added fullscreen support using the Safe Area Insets style properties, created an initial app icon, Window Controls Overlay support, and a Web App Manifest for full (cross-platform) PWA installations.
Listened to almost 3 PT records so far tonight. Started with Stupid Dream, next Lightbulb Sun, and I'm at 'The Creator Has a Mastertape' on In Absentia now. That made me think of a new thing I haven't done before: Listen to a given artist's catalog fully all the way through in one go! That would be a very long day, but I'm gonna do it sometime. I really like the sound of that. I can't wait to try that with Marco Minnemann's solo work! I have all of his albums in my library, can't believe I have them all. I definitely recommend his work too! There's SOO much to listen to there. I'm starting to do that with Mike Keneally's catalog too, that's also taking some time for it to soak into my brain. Sometimes albums from those guys can take a while to really click, any of the progger guys for that matter XD. I think that's what I'm striving to have with my own writing too. Started listening through my next album projects, may start doing initial mixing for them tomorrow!
Consolidates some XSS under hivecore (#2738)
Spawn pool and evo pods are removed and their functionality is umbrella'd under the hive core. Sprites still exist though.
"Roleplay" has become an increasingly more popular and touchy subject within the community as of recently. I, wholeheartedly agree, that roleplay is an important aspect of the game, and there are ways to improve it. One of these ways is through immersion. In this MR, it is intended to increase player immersion.
One of the most memorable and haunting scenes in Aliens was when they reached the hive and they found the bodies. This very unique and cinematic scene was often able to be replicated in CM, with the marines busting open the hive and finding all the chestbursted bodies of their comrades. Roleplaying this out was commonplace. "Dear God... what did they do to you..." or acting out in disgust are just a few of the many ways having bodies in the hive positively impacted the game.
XSS was a failed attempt at spicing up the xenomorph gameplay loop at the expense of immersion and should be at least somewhat reverted while keeping balance in mind. A brief discussion with many prominent xenomorph players, including those most experienced in queen, have not particularly expressed favor to XSS either.
To start, let us remember why XSS (xeno special structures - hive core, evo pods, morpher, pool, etc) was added.
https://docs.google.com/document/d/19_zDUmLdxpUzxj-GuWu7F4bSj4zBYzmZ39s_N5X7kQ0/edit
- This is the original development document for XSS. Let us examine the major points: 1.Introduce a way for Xenomorph players to recycle - This idea was never reached.
2.Reduce Xenomorph attrition - Grand objective was unsuccessful. Very little changed.
- Offer new avenues of play "by reducing the punishment of xenos dying"
- This never happened. Dying was still just as punishing, especially with facehug nerfs.
The spawn pool - The idea of the spawn pool was successful and has remained unchanged since. I would argue, however, it is not immersive. Xenomorphs do not have bright, glowing, acidic pools in their hives. (Yes I know there was a comic with a pool, and this is not how it was used)
Egg Morpher - These used to be TURRETS. They are no longer turrets, and their sprites have been broken for almost 4 years (the bodies put inside of them used to show their face in the little purple part) They are currently defunct facehugger reservoirs. I am in favor of removing them, but I would argue that is a balance issue (number of huggers in play)
Evolution Pod - It was intended for these to be able to be eaten in order to evolve. They haven't done this for years. Why do we still have them? They take up 18 spaces of precious hive weeds, provide light, (xenomorphs HATE light) and wherever a hive core is built, these are also built. We can just merge them with the hive core because there is no reason to have them anymore.
This PR currently completely removes the spawn pool and evolution pod from gameplay, while reimagining their functions for current balance. This PR is not intended to change balance in any way.
All functionality from the spawn pool in regards to "pooled" larva has been given to the hive core, and they are now called "burrowed" larva. Chestbursts now give two larva, this is to be kept with current balance of two xenos per capture.
Evopod functionality and evolution speed boost was merged with the hive core.
n/a
🆑 TheDonkified del: Evo pods and spawn pool are removed. add: Hive core directly affects evolution speed and is where burrowed larva spawn from now on. /🆑
Co-authored-by: Morrow darthbane97@gmail.com Co-authored-by: harryob me@harryob.live
experimental_use(promise) (#25084)
- Internal
act: Unwrapping resolved promises
This update our internal implementation of act to support React's new
behavior for unwrapping promises. Like we did with Scheduler, when
something suspends, it will yield to the main thread so the microtasks
can run, then continue in a new task.
I need to implement the same behavior in the public version of act,
but there are some additional considerations so I'll do that in a
separate commit.
- Move throwException to after work loop resumes
throwException is the function that finds the nearest boundary and schedules it for a second render pass. We should only call it right before we unwind the stack — not if we receive an immediate ping and render the fiber again.
This was an oversight in 8ef3a7c that I didn't notice because it happens to mostly work, anyway. What made me notice the mistake is that throwException also marks the entire render phase as suspended (RootDidSuspend or RootDidSuspendWithDelay), which is only supposed to be happen if we show a fallback. One consequence was that, in the RootDidSuspendWithDelay case, the entire commit phase was blocked, because that's the exit status we use to block a bad fallback from appearing.
- Use expando to check whether promise has resolved
Add a status expando to a thrown thenable to track when its value has
resolved.
In a later step, we'll also use value and reason expandos to track
the resolved value.
This is not part of the official JavaScript spec — think of
it as an extension of the Promise API, or a custom interface that is a
superset of Thenable. However, it's inspired by the terminology used
by Promise.allSettled.
The intent is that this will be a public API — Suspense implementations can set these expandos to allow React to unwrap the value synchronously without waiting a microtask.
- Scaffolding for
experimental_usehook
Sets up a new experimental hook behind a feature flag, but does not implement it yet.
- use(promise)
Adds experimental support to Fiber for unwrapping the value of a promise inside a component. It is not yet implemented for Server Components, but that is planned.
If promise has already resolved, the value can be unwrapped "immediately" without showing a fallback. The trick we use to implement this is to yield to the main thread (literally suspending the work loop), wait for the microtask queue to drain, then check if the promise resolved in the meantime. If so, we can resume the last attempted fiber without unwinding the stack. This functionality was implemented in previous commits.
Another feature is that the promises do not need to be cached between attempts. Because we assume idempotent execution of components, React will track the promises that were used during the previous attempt and reuse the result. You shouldn't rely on this property, but during initial render it mostly just works. Updates are trickier, though, because if you used an uncached promise, we have no way of knowing whether the underlying data has changed, so we have to unwrap the promise every time. It will still work, but it's inefficient and can lead to unnecessary fallbacks if it happens during a discrete update.
When we implement this for Server Components, this will be less of an issue because there are no updates in that environment. However, it's still better for performance to cache data requests, so the same principles largely apply.
The intention is that this will eventually be the only supported way to suspend on arbitrary promises. Throwing a promise directly will be deprecated.
Update Stylelint to v14, extend SCSS plugins, remove primer-* configs, resolve issues (#821)
This is a catch-all PR that modernizes and updates our Stylelint config, and resolves all open issues. This is a pretty big change - so I want to update all of our related dependencies in lockstep.
In particular, this PR
- updates stylelint to
v14 - adds in the standard stylelint config for SCSS (
stylelint-config-standard-scss) - swaps out
stylelint-config-prettierforstylelint-config-prettier-scss -
properly updatecompletely remove@primer-related plugins:primerfrom our configuration - autofix, manually resolve, or disable all newly-introduced lint errors; I've avoided manually resolving errors that would be a behavioural change
- re-runs
npm run format
See the "next steps" section on some extra thoughts on disabling errors.
(implicitly, I'm also using node 16/the new package-lock format).
I've introduced several new disabled rules. Let me quickly explain what's going on; there are two categories of rules I've disabled:
- rules that were temporary disables; they were frequent enough that I couldn't manually resolve them, but should be simple. I plan on opening issues to re-enable each of these rules, just after this PR
declaration-block-no-redundant-longhand-properties: this is just tedious and error-proneno-descending-specificity: this one is tricky since it could have impacts on the cascade (though that seems unlikely)scss/no-global-function-names: I think we need to import map and then usemap.get, but I'll leave this as out of scope for now
- rules that are long-term disables; due to the SASS-based nature of our theme, I think we'll keep these in limbo
alpha-value-notationcauses problems with SASS using themodernsyntax - literals like50%are not properly interpolated, and they cause formatting issues on the sitecolor-function-notationalso causes problems with SASS, but in this case themodernsyntax breaks SASS compilation; we're not alone (see this SO post).
In addition, we have many inline stylelint-disable comments. I'd open a separate issue to audit them, especially since I think some disables are unnecessary.
note: there hasn't been much other discussion, so I'm going to remove primer's stylelint config.
If I do add @primer/stylelint-config, I get a ton of errors about now using @primer's in-built SCSS variables. I imagine that we probably won't want to use these presets (though I could be wrong). In that case, I think we could either:
- disable all of those rules
- not use
@primer/stylelint-config, since we're not actually using primer, and shift back to the standard SCSS config provided by Stylelint
Any thoughts here? I also don't have the original context as to why we do use the primer rules, perhaps @pmarsceill can chime in?
New phrases New emoji-only responses Some of the smartest people I know actively believe the press … amazing Some hate humanity, but I love humanity so much You represent the problem: journalists who think they are the only source of legitimate information. That’s the big lie.
Boiler rework Part 1: Globber base boiler (#965)
A total redesign of the base boiler reminiscent of the old premoba boiler that would shoot projectile "Globs" with a modern CM take.
Base boiler as it is right now, is completely unfun, to play against and to even play as. You'd be hard-pressed to find someone who enjoys playing it past the first 10 minutes of doing so. It is this way not because it's weak, but because it's unchallenging and 100% "safe" gameplay. There are no combos, cool moves you can do, or even satisfying effects, you just hit a button to spawn a telegraph which becomes a gas cloud.
This PR, turns that right ontop of its head. Instead of "safe" gameplay, globber's design philosophy is centered around being challenging, fun and even adding new gameplay dynamics.
Globber will have higher HP, faster walkspeed, and faster firing bombard compared to premoba.
However, globber will have their fellow xenos making plays to cover for boiler, either directly through bodyblocking shots or making plays to distract marines due to a minimal zoom range.
These both, in theory, will create a new gameplay dynamic where boilers will still be able to block marine spearheads, but Globber needs to help make a small counter push with their fellow brethren in order for Globber to directly strike at marines and giving the Xenos the choice to either capitalize on their advantage or heal up upon a successful glob.
Design doc https://hackmd.io/@-h91mVK3RhaURcykLHRxJQ/S1W0FCZPj
Globber will feature [TENTATIVE] higher HP and [TENTATIVE] faster walk speed. It however will be slightly more vulnerable to fire as fire deals [TENTATIVE]% more damage to it!
Globber Active 1 - Bombard: Spit a large acid glob that will, upon impact, immediately spread a gas glob of your choice
- Cooldown: 30 seconds
- cost: 200 plasma
- Windup: 5 seconds
Globber Active 2 - Acid spray, instantly sprays a line of acid, May make it a cone spray if it is too weak
- 8 second c/d
- No windup
- 40 plasma
- 6 tile range
Globber Active 3 - Shift spits: Switch between acid and neuro gas globs. Acid deals more raw damage while neuro slows,blinds and eventually knocks down marines. Neuro has a larger radius than acid
Globber Active 4 - Acid shroud: A quick windup action that dumps an acid cloud over the boiler. Cooldowns other abilities similar to dump acid.
Globber Active 5 - Zoom: Short ranged zoom with short windup. Trades awareness for zoom
Globber Passive: Brute armor, Globber features brute armor, however, it does not protect against flames! Globber takes 1.5x damage to fire!
Acid glob: Pretty much the same as before. May adjust numbers.
Neuro smoke rework:
- Instead of insta blindness and deafness, these will now have a chance of applying for every tick you are in the smoke. You still have blurry/weldervision though
- Oxyloss toned down, it was 9 per tick, now two
- Knockdown chance lowered to 5% per tick. Stamina damage replaces RNG knockdowns
- Now deals stamina damage, and am making it stack fast, targeted knockdown time is 2-3 seconds
- Minor immediate slowdown applied. May remove as it stacks with stamina damage slow
- chance of dealing minor tox damage
The boiler rework is a total rework of the boiler strain and it's strains.
I'm not gonna write the entire design doc here, but in short:
-Base boiler will be reworked (as shown here), named Globber
- trapper will be totally scrapped for 'Grenadier', a heavy siege strain that lobs devastating nades that's counterable and challenging. Grenadier will have the same zoom as Globber
- A long-range, general-purpose strain will be added, named "Striker Boiler", which combines both the Railgun boiler and the mostly forgotten "Acid Splatter" strains in the past, with a modern CM twist.
design docs( old as fuck and needs updating) REPLACE ME WITH NEW ONE cmss13-devs/cmss13-design-docs#7 Striker design doc cmss13-devs/cmss13-design-docs#8
TL;DR base boiler is a literal NPC strain that no one likes to play as or against. Attempt to make it more fun or die trying
if the design philosophy fails, then we can simply just tweak a few values and have premoba boiler again.
Design doc is already made but its ancient as shit and I'm just gonna make a new one so its WIP for now.
Design doc https://hackmd.io/@-h91mVK3RhaURcykLHRxJQ/S1W0FCZPj
🆑 Totalepicness add: Added "Globber Boiler", which is a total replacement of base boiler, designed to kill the "safe" gameplay loops of current base boiler in an attempt for a more challenging and fun caste to both play as and against. balance: Globber Active 1 - Bombard: Spit a large acid glob that will, upon impact, immediately spread a gas glob of your choice balance: Globber Active 2 - Spray acid: Instantly sprays a line of acid balance: Globber Active 3 - Shift spits: Switch between acid and neuro gas globs. Acid deals damage while neuro slows, blinds and eventually knocks down marines. Neuro has a larger radius than acid balance: Globber Active 4 - Acid shroud: A quick windup action that dumps an acid cloud over the boiler. Cooldowns other abilities similar to dump acid. balance: Globber Active 5 - Zoom: Short-ranged zoom with no windup. balance: Globber Passive: Globber features armor, but it is weaker against flames! Stay away from fire! refactor: Refractored some minor spit code and icons balance: Neuro has been completely reworked to deal mainly stamina damage, causes dizzyness and has a small chance to make you 'stumble' in a random direction along with minor tox damage. Stay out of it! add: Completly reworked neuro gas, it now uses a proper effect with escalating effects the larger the dosage rather than RNG. fix: Acid now deals damage to cades and now has a good chance of going over instead of being airtight fix: Boiler globs no longer can target mobs and track them. /🆑
Co-authored-by: Epicness coolguyethanw@gmail.com Co-authored-by: Geeves ggrobler447@gmail.com Co-authored-by: Segrain Segrain@users.noreply.github.com Co-authored-by: harryob me@harryob.live
[FIX] stock,purchase,mrp: accumulative security days
Usecase to reproduce:
- Set the warehouse as 3 steps receipt
- Put a security delay of 3 days for purchase
- Set a product with a vendor and 1 days as LT
- Replenish with the orderpoint
You expect to have a schedule date for tomorrow that contains all the product needed in the incoming 4 days.
Currenly the internal transfer from QC -> Stock is for tomorrow (ok). The transfer from Inpur -> QC is plan for 2 days in the past. (not ok) The PO date is plan for 5 days in the past. (not ok)
It happens because the system check at each stock.rule application if
purchase is part of the route. If it's then it applies the security lead
time. It's a mistake because we should apply it only the first time.
To fix it we directly set it when the orderpoint run and not during
stock.move creation.
However for MTO it's not that easy. We don't want to deliver too
early the customer. So we keep applying the delay during the
stock.move creation but only when it goes under the warehouse stock
location.
X-original-commit: 97f52bd40d97109a7983549d252476959ddceada Part-of: odoo/odoo#112314
Add files via upload
Apollo Hospitals was established in 1983, renowned as the architect of modern healthcare in India. As the nation's first corporate hospital, Apollo Hospitals is acclaimed for pioneering the private healthcare revolution in the country. As a data scientist working at Apollo 24/7, the ultimate goal is to tease out meaningful and actionable insights from Patient-level collected data. You can help Apollo hospitals to be more efficient, to influence diagnostic and treatment processes, to map the spread of a pandemic.
One of the best examples of data scientists making a meaningful difference at a global level is in the response to the COVID-19 pandemic, where they have improved information collection, provided ongoing and accurate estimates of infection spread and health system demand, and assessed the effectiveness of government policies. How can you help here?
The company wants to know: • Which variables are significant in predicting the reason for hospitalization for different regions • How well some variables like viral load, smoking, Severity Level describe the hospitalization charges
Column Profiling Age: This is an integer indicating the age of the primary beneficiary (excluding those above 64 years, since they are generally covered by the government). Sex: This is the policy holder's gender, either male or female Viral Load: Viral load refers to the amount of virus in an infected person's blood Severity Level: This is an integer indicating how severe the patient is Smoker: This is yes or no depending on whether the insured regularly smokes tobacco. Region: This is the beneficiary's place of residence in Delhi, divided into four geographic regions - northeast, southeast, southwest, or northwest Hospitalization charges: Individual medical costs billed to health insurance
Concept Used: Graphical and Non-Graphical Analysis 2-sample t-test: testing for difference across populations ANOVA Chi-square
nukes the last default ss13 door on big red (#2830)
i thought i fixed this? didn't i guess removed the weirdass ss13 door in the OR theater's observer area yeah
it's ugly
Screenshots & Videos
Put screenshots and videos here with an empty line between the
screenshots and the <details> tags.
🆑 maptweak: removed yet another default ss13 door from big red /🆑
satrting troops for jowland, removed annoying FUCKING BITCH WHO TALKS AT THE END OF PAKISTAN NATIONAL ANTHEM
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe feature in the kernel works. We had reports of several races, including some reports of apps bypassing our recursion check so that a process that was forked as part of a core_pattern setup could infinitely crash and refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space programs that are inserted as the forked process of core_pattern. They contend that in order for their programs (such as abrt and apport) to work, all the running processes in a system must have their core limits set to a non-zero value, to which I say 'yes'. I did this by design, and think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I thought I would take a look at it. The first suggestion was to make the recursion check fail on a non-zero 'special' number, like one. That way the core collector process could set its core size ulimit to 1, and enable the kernel's recursion detection. This isn't a bad idea on the surface, but I don't like it since its opt-in, in that if a program like abrt or apport has a bug and fails to set such a core limit, we're left with a recursively crashing system again.
So I've come up with this. What I've done is modify the call_usermodehelper api such that an extra parameter is added, a function pointer which will be called by the user helper task, after it forks, but before it exec's the required process. This will give the caller the opportunity to get a call back in the processes context, allowing it to do whatever it needs to to the process in the kernel prior to exec-ing the user space code. In the case of do_coredump, this callback is ues to set the core ulimit of the helper process to 1. This elimnates the opt-in problem that I had above, as it allows the ulimit for core sizes to be set to the value of 1, which is what the recursion check looks for in do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and allows for customization of the helper process prior to calling exec. Its return code gates the continuation of the process, or causes its exit. Also add an arbitrary data pointer to the subprocess_info struct allowing for data to be passed from the caller to the new process, and the subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes an argp and envp pointer for freeing, which is ugly. Lets instead just make the subprocess_info structure public, and pass that to the cleanup and init routines
Signed-off-by: Neil Horman nhorman@tuxdriver.com Reviewed-by: Oleg Nesterov oleg@redhat.com Cc: Andi Kleen andi@firstfloor.org Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org
Loadout - Sniper facepaint (#2015)
This PR is here to add the sniper facepaint into the loadout for 4 points like the skull facepaint.
I tested it and it worked well as expected.
I saw a lot of marines asking the sniper for their bodypaint recently, and i thought, that since it doesnt change anything game-wise we could give it on the loadout, as the sniper isnt always here and sometime even throw it to the trash...also people wont annoy the sniper for his paint too.
((sorry for the webedit i ran into some problem doing the PR with visual code studio))
I think its good because it add more customisation to characters with one more good looking facepaint and like i said earlier, i saw some marines asking the sniper for it (talked about it on discord and people seemed to be ok with it)
Screenshots & Videos
i posted the pic here https://discord.com/channels/150315577943130112/1054515157923020842 (if in the pic you see the facepaint above the other paint its normal, i tested it with the code above the other but it should appear under the skull paint in the pr)
🆑 Skegal add: Added Full Body Paint to Loadout /🆑
Acid vest TGUI (#2050)
converts the acid vest config to TGUI
this took a long time to do because the way it's set up was somewhat annoying
fuck nanoui
🆑 ui: converted the A.C.I.D. harness to use TGUI /🆑
Co-authored-by: Stan_Albatross swt91a@gmail.com
macsec: avoid heap overflow in skb_to_sgvec
While this may appear as a humdrum one line change, it's actually quite important. An sk_buff stores data in three places:
- A linear chunk of allocated memory in skb->data. This is the easiest one to work with, but it precludes using scatterdata since the memory must be linear.
- The array skb_shinfo(skb)->frags, which is of maximum length MAX_SKB_FRAGS. This is nice for scattergather, since these fragments can point to different pages.
- skb_shinfo(skb)->frag_list, which is a pointer to another sk_buff, which in turn can have data in either (1) or (2).
The first two are rather easy to deal with, since they're of a fixed maximum length, while the third one is not, since there can be potentially limitless chains of fragments. Fortunately dealing with frag_list is opt-in for drivers, so drivers don't actually have to deal with this mess. For whatever reason, macsec decided it wanted pain, and so it explicitly specified NETIF_F_FRAGLIST.
Because dealing with (1), (2), and (3) is insane, most users of sk_buff doing any sort of crypto or paging operation calls a convenient function called skb_to_sgvec (which happens to be recursive if (3) is in use!). This takes a sk_buff as input, and writes into its output pointer an array of scattergather list items. Sometimes people like to declare a fixed size scattergather list on the stack; othertimes people like to allocate a fixed size scattergather list on the heap. However, if you're doing it in a fixed-size fashion, you really shouldn't be using NETIF_F_FRAGLIST too (unless you're also ensuring the sk_buff and its frag_list children arent't shared and then you check the number of fragments in total required.)
Macsec specifically does this:
size += sizeof(struct scatterlist) * (MAX_SKB_FRAGS + 1);
tmp = kmalloc(size, GFP_ATOMIC);
*sg = (struct scatterlist *)(tmp + sg_offset);
...
sg_init_table(sg, MAX_SKB_FRAGS + 1);
skb_to_sgvec(skb, sg, 0, skb->len);
Specifying MAX_SKB_FRAGS + 1 is the right answer usually, but not if you're using NETIF_F_FRAGLIST, in which case the call to skb_to_sgvec will overflow the heap, and disaster ensues.
Signed-off-by: Jason A. Donenfeld Jason@zx2c4.com Cc: stable@vger.kernel.org Cc: security@kernel.org Signed-off-by: David S. Miller davem@davemloft.net
signal: add pidfd_send_signal() syscall
The kill() syscall operates on process identifiers (pid). After a process has exited its pid can be reused by another process. If a caller sends a signal to a reused pid it will end up signaling the wrong process. This issue has often surfaced and there has been a push to address this problem [1].
This patch uses file descriptors (fd) from proc/ as stable handles on struct pid. Even if a pid is recycled the handle will not change. The fd can be used to send signals to the process it refers to. Thus, the new syscall pidfd_send_signal() is introduced to solve this problem. Instead of pids it operates on process fds (pidfd).
/* prototype and argument /* long pidfd_send_signal(int pidfd, int sig, siginfo_t *info, unsigned int flags);
/* syscall number 424 */ The syscall number was chosen to be 424 to align with Arnd's rework in his y2038 to minimize merge conflicts (cf. [25]).
In addition to the pidfd and signal argument it takes an additional siginfo_t and flags argument. If the siginfo_t argument is NULL then pidfd_send_signal() is equivalent to kill(, ). If it is not NULL pidfd_send_signal() is equivalent to rt_sigqueueinfo(). The flags argument is added to allow for future extensions of this syscall. It currently needs to be passed as 0. Failing to do so will cause EINVAL.
/* pidfd_send_signal() replaces multiple pid-based syscalls */ The pidfd_send_signal() syscall currently takes on the job of rt_sigqueueinfo(2) and parts of the functionality of kill(2), Namely, when a positive pid is passed to kill(2). It will however be possible to also replace tgkill(2) and rt_tgsigqueueinfo(2) if this syscall is extended.
/* sending signals to threads (tid) and process groups (pgid) */ Specifically, the pidfd_send_signal() syscall does currently not operate on process groups or threads. This is left for future extensions. In order to extend the syscall to allow sending signal to threads and process groups appropriately named flags (e.g. PIDFD_TYPE_PGID, and PIDFD_TYPE_TID) should be added. This implies that the flags argument will determine what is signaled and not the file descriptor itself. Put in other words, grouping in this api is a property of the flags argument not a property of the file descriptor (cf. [13]). Clarification for this has been requested by Eric (cf. [19]). When appropriate extensions through the flags argument are added then pidfd_send_signal() can additionally replace the part of kill(2) which operates on process groups as well as the tgkill(2) and rt_tgsigqueueinfo(2) syscalls. How such an extension could be implemented has been very roughly sketched in [14], [15], and [16]. However, this should not be taken as a commitment to a particular implementation. There might be better ways to do it. Right now this is intentionally left out to keep this patchset as simple as possible (cf. [4]).
/* naming */ The syscall had various names throughout iterations of this patchset:
- procfd_signal()
- procfd_send_signal()
- taskfd_send_signal() In the last round of reviews it was pointed out that given that if the flags argument decides the scope of the signal instead of different types of fds it might make sense to either settle for "procfd_" or "pidfd_" as prefix. The community was willing to accept either (cf. [17] and [18]). Given that one developer expressed strong preference for the "pidfd_" prefix (cf. [13]) and with other developers less opinionated about the name we should settle for "pidfd_" to avoid further bikeshedding.
The "_send_signal" suffix was chosen to reflect the fact that the syscall takes on the job of multiple syscalls. It is therefore intentional that the name is not reminiscent of neither kill(2) nor rt_sigqueueinfo(2). Not the fomer because it might imply that pidfd_send_signal() is a replacement for kill(2), and not the latter because it is a hassle to remember the correct spelling - especially for non-native speakers - and because it is not descriptive enough of what the syscall actually does. The name "pidfd_send_signal" makes it very clear that its job is to send signals.
/* zombies */ Zombies can be signaled just as any other process. No special error will be reported since a zombie state is an unreliable state (cf. [3]). However, this can be added as an extension through the @flags argument if the need ever arises.
/* cross-namespace signals */ The patch currently enforces that the signaler and signalee either are in the same pid namespace or that the signaler's pid namespace is an ancestor of the signalee's pid namespace. This is done for the sake of simplicity and because it is unclear to what values certain members of struct siginfo_t would need to be set to (cf. [5], [6]).
/* compat syscalls */ It became clear that we would like to avoid adding compat syscalls (cf. [7]). The compat syscall handling is now done in kernel/signal.c itself by adding __copy_siginfo_from_user_generic() which lets us avoid compat syscalls (cf. [8]). It should be noted that the addition of __copy_siginfo_from_user_any() is caused by a bug in the original implementation of rt_sigqueueinfo(2) (cf. 12). With upcoming rework for syscall handling things might improve significantly (cf. [11]) and __copy_siginfo_from_user_any() will not gain any additional callers.
/* testing */ This patch was tested on x64 and x86.
/* userspace usage */ An asciinema recording for the basic functionality can be found under [9]. With this patch a process can be killed via:
#define _GNU_SOURCE #include <errno.h> #include <fcntl.h> #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/types.h> #include <unistd.h>
static inline int do_pidfd_send_signal(int pidfd, int sig, siginfo_t *info, unsigned int flags) { #ifdef __NR_pidfd_send_signal return syscall(__NR_pidfd_send_signal, pidfd, sig, info, flags); #else return -ENOSYS; #endif }
int main(int argc, char *argv[]) { int fd, ret, saved_errno, sig;
if (argc < 3)
exit(EXIT_FAILURE);
fd = open(argv[1], O_DIRECTORY | O_CLOEXEC);
if (fd < 0) {
printf("%s - Failed to open \"%s\"\n", strerror(errno), argv[1]);
exit(EXIT_FAILURE);
}
sig = atoi(argv[2]);
printf("Sending signal %d to process %s\n", sig, argv[1]);
ret = do_pidfd_send_signal(fd, sig, NULL, 0);
saved_errno = errno;
close(fd);
errno = saved_errno;
if (ret < 0) {
printf("%s - Failed to send signal %d to process %s\n",
strerror(errno), sig, argv[1]);
exit(EXIT_FAILURE);
}
exit(EXIT_SUCCESS);
}
/* Q&A
- Given that it seems the same questions get asked again by people who are
- late to the party it makes sense to add a Q&A section to the commit
- message so it's hopefully easier to avoid duplicate threads.
- For the sake of progress please consider these arguments settled unless
- there is a new point that desperately needs to be addressed. Please make
- sure to check the links to the threads in this commit message whether
- this has not already been covered. */ Q-01: (Florian Weimer [20], Andrew Morton [21]) What happens when the target process has exited? A-01: Sending the signal will fail with ESRCH (cf. [22]).
Q-02: (Andrew Morton [21]) Is the task_struct pinned by the fd? A-02: No. A reference to struct pid is kept. struct pid - as far as I understand - was created exactly for the reason to not require to pin struct task_struct (cf. [22]).
Q-03: (Andrew Morton [21]) Does the entire procfs directory remain visible? Just one entry within it? A-03: The same thing that happens right now when you hold a file descriptor to /proc/ open (cf. [22]).
Q-04: (Andrew Morton [21]) Does the pid remain reserved? A-04: No. This patchset guarantees a stable handle not that pids are not recycled (cf. [22]).
Q-05: (Andrew Morton [21]) Do attempts to signal that fd return errors? A-05: See {Q,A}-01.
Q-06: (Andrew Morton [22]) Is there a cleaner way of obtaining the fd? Another syscall perhaps. A-06: Userspace can already trivially retrieve file descriptors from procfs so this is something that we will need to support anyway. Hence, there's no immediate need to add another syscalls just to make pidfd_send_signal() not dependent on the presence of procfs. However, adding a syscalls to get such file descriptors is planned for a future patchset (cf. [22]).
Q-07: (Andrew Morton [21] and others) This fd-for-a-process sounds like a handy thing and people may well think up other uses for it in the future, probably unrelated to signals. Are the code and the interface designed to permit such future applications? A-07: Yes (cf. [22]).
Q-08: (Andrew Morton [21] and others) Now I think about it, why a new syscall? This thing is looking rather like an ioctl? A-08: This has been extensively discussed. It was agreed that a syscall is preferred for a variety or reasons. Here are just a few taken from prior threads. Syscalls are safer than ioctl()s especially when signaling to fds. Processes are a core kernel concept so a syscall seems more appropriate. The layout of the syscall with its four arguments would require the addition of a custom struct for the ioctl() thereby causing at least the same amount or even more complexity for userspace than a simple syscall. The new syscall will replace multiple other pid-based syscalls (see description above). The file-descriptors-for-processes concept introduced with this syscall will be extended with other syscalls in the future. See also [22], [23] and various other threads already linked in here.
Q-09: (Florian Weimer [24]) What happens if you use the new interface with an O_PATH descriptor? A-09: pidfds opened as O_PATH fds cannot be used to send signals to a process (cf. [2]). Signaling processes through pidfds is the equivalent of writing to a file. Thus, this is not an operation that operates "purely at the file descriptor level" as required by the open(2) manpage. See also [4].
/* References */ [1]: https://lore.kernel.org/lkml/20181029221037.87724-1-dancol@google.com/ [2]: https://lore.kernel.org/lkml/874lbtjvtd.fsf@oldenburg2.str.redhat.com/ [3]: https://lore.kernel.org/lkml/20181204132604.aspfupwjgjx6fhva@brauner.io/ [4]: https://lore.kernel.org/lkml/20181203180224.fkvw4kajtbvru2ku@brauner.io/ [5]: https://lore.kernel.org/lkml/20181121213946.GA10795@mail.hallyn.com/ [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6nv4@brauner.io/ [7]: https://lore.kernel.org/lkml/36323361-90BD-41AF-AB5B-EE0D7BA02C21@amacapital.net/ [8]: https://lore.kernel.org/lkml/87tvjxp8pc.fsf@xmission.com/ [9]: https://asciinema.org/a/IQjuCHew6bnq1cr78yuMv16cy [11]: https://lore.kernel.org/lkml/F53D6D38-3521-4C20-9034-5AF447DF62FF@amacapital.net/ [12]: https://lore.kernel.org/lkml/87zhtjn8ck.fsf@xmission.com/ [13]: https://lore.kernel.org/lkml/871s6u9z6u.fsf@xmission.com/ [14]: https://lore.kernel.org/lkml/20181206231742.xxi4ghn24z4h2qki@brauner.io/ [15]: https://lore.kernel.org/lkml/20181207003124.GA11160@mail.hallyn.com/ [16]: https://lore.kernel.org/lkml/20181207015423.4miorx43l3qhppfz@brauner.io/ [17]: https://lore.kernel.org/lkml/CAGXu5jL8PciZAXvOvCeCU3wKUEB_dU-O3q0tDw4uB_ojMvDEew@mail.gmail.com/ [18]: https://lore.kernel.org/lkml/20181206222746.GB9224@mail.hallyn.com/ [19]: https://lore.kernel.org/lkml/20181208054059.19813-1-christian@brauner.io/ [20]: https://lore.kernel.org/lkml/8736rebl9s.fsf@oldenburg.str.redhat.com/ [21]: https://lore.kernel.org/lkml/20181228152012.dbf0508c2508138efc5f2bbe@linux-foundation.org/ [22]: https://lore.kernel.org/lkml/20181228233725.722tdfgijxcssg76@brauner.io/ [23]: https://lwn.net/Articles/773459/ [24]: https://lore.kernel.org/lkml/8736rebl9s.fsf@oldenburg.str.redhat.com/ [25]: https://lore.kernel.org/lkml/CAK8P3a0ej9NcJM8wXNPbcGUyOUZYX+VLoDFdbenW3s3114oQZw@mail.gmail.com/
Cc: "Eric W. Biederman" ebiederm@xmission.com Cc: Jann Horn jannh@google.com Cc: Andy Lutomirsky luto@kernel.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Oleg Nesterov oleg@redhat.com Cc: Al Viro viro@zeniv.linux.org.uk Cc: Florian Weimer fweimer@redhat.com Signed-off-by: Christian Brauner christian@brauner.io Reviewed-by: Tycho Andersen tycho@tycho.ws Reviewed-by: Kees Cook keescook@chromium.org Reviewed-by: David Howells dhowells@redhat.com Acked-by: Arnd Bergmann arnd@arndb.de Acked-by: Thomas Gleixner tglx@linutronix.de Acked-by: Serge Hallyn serge@hallyn.com Acked-by: Aleksa Sarai cyphar@cyphar.com
Ezekiel 25:17. "The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men. Blessed is he who, in the name of charity and good will, shepherds the weak through the valley of the darkness. For he is truly his brother's keeper and the finder of lost children. And I will strike down upon thee with great vengeance and furious anger those who attempt to poison and destroy my brothers. And you will know I am the Lord when I lay my vengeance upon you."
lib: test_user_copy: style cleanup
While writing the tests for copy_struct_from_user(), I used a construct that Linus doesn't appear to be too fond of:
On 2019-10-04, Linus Torvalds torvalds@linux-foundation.org wrote:
Hmm. That code is ugly, both before and after the fix.
This just doesn't make sense for so many reasons:
if ((ret |= test(umem_src == NULL, "kmalloc failed")))where the insanity comes from
why "|=" when you know that "ret" was zero before (and it had to be, for the test to make sense)
why do this as a single line anyway?
don't do the stupid "double parenthesis" to hide a warning. Make it use an actual comparison if you add a layer of parentheses.
So instead, use a bog-standard check that isn't nearly as ugly.
Fixes: 341115822f88 ("usercopy: Add parentheses around assignment in test_copy_struct_from_user") Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper") Signed-off-by: Aleksa Sarai cyphar@cyphar.com Reviewed-by: Nathan Chancellor natechancellor@gmail.com Reviewed-by: Christian Brauner christian.brauner@ubuntu.com Link: https://lore.kernel.org/r/20191005233028.18566-1-cyphar@cyphar.com Signed-off-by: Christian Brauner christian.brauner@ubuntu.com
fucking hell no idea what i did. submit questions rework, added tags, fucked shit up
Life is one big road with lots of signs. So when you riding through the ruts, don't complicate your mind. Flee from hate, mischief and jealousy. Don't bury your thoughts, put your vision to reality. Wake Up and Live!
Incorret theme should not prevent napari from start (#5605)
For the current implementation, the error in theme registration prevents the napari form from starting. It may be problematic for bundle users.
In this PR I add try: ... except to handle an error during theme
registration and convert it to logging exceptions. I use logging because
it happened before creating GUI.
- Bug-fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality to not work as expected)
- This change requires a documentation update
- example: the test suite for my feature covers cases x, y, and z
- example: all tests pass with my change
- example: I check if my changes works with both PySide and PyQt backends as there are small differences between the two Qt bindings.
Install napari-gruvbox, pygments==2.6 (bellow 2.9) and start napari
Example error message:
11:52:01 ERROR Registration theme failed.
1 validation error for Theme
syntax_style
Incorrect `syntax_style` value: gruvbox-dark provided. Please use one of the following: default, emacs, friendly, colorful, autumn, murphy, manni, monokai, perldoc, pastie, borland, trac, native, fruity, bw, vim, vs, tango, rrt, xcode, igor, paraiso-light, paraiso-dark, lovelace, algol, algol_nu, arduino, rainbow_dash, abap, solarized-dark, solarized-light, sas, stata, stata-light, stata-dark, inkpot (type=assertion_error)
Traceback (most recent call last):
File "/home/czaki/Projekty/napari/napari/utils/theme.py", line 391, in _install_npe2_themes
register_theme(theme.id, theme_dict, manifest.name)
File "/home/czaki/Projekty/napari/napari/utils/theme.py", line 266, in register_theme
theme = Theme(**theme)
File "/home/czaki/Projekty/napari/napari/utils/events/evented_model.py", line 200, in __init__
super().__init__(**kwargs)
File "pydantic/main.py", line 342, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 1 validation error for Theme
syntax_style
Incorrect `syntax_style` value: gruvbox-dark provided. Please use one of the following: default, emacs, friendly, colorful, autumn, murphy, manni, monokai, perldoc, pastie, borland, trac, native, fruity, bw, vim, vs, tango, rrt, xcode, igor, paraiso-light, paraiso-dark, lovelace, algol, algol_nu, arduino, rainbow_dash, abap, solarized-dark, solarized-light, sas, stata, stata-light, stata-dark, inkpot (type=assertion_error)
11:52:01 ERROR Registration theme failed.
1 validation error for Theme
syntax_style
Incorrect `syntax_style` value: gruvbox-light provided. Please use one of the following: default, emacs, friendly, colorful, autumn, murphy, manni, monokai, perldoc, pastie, borland, trac, native, fruity, bw, vim, vs, tango, rrt, xcode, igor, paraiso-light, paraiso-dark, lovelace, algol, algol_nu, arduino, rainbow_dash, abap, solarized-dark, solarized-light, sas, stata, stata-light, stata-dark, inkpot (type=assertion_error)
Traceback (most recent call last):
File "/home/czaki/Projekty/napari/napari/utils/theme.py", line 391, in _install_npe2_themes
register_theme(theme.id, theme_dict, manifest.name)
File "/home/czaki/Projekty/napari/napari/utils/theme.py", line 266, in register_theme
theme = Theme(**theme)
File "/home/czaki/Projekty/napari/napari/utils/events/evented_model.py", line 200, in __init__
super().__init__(**kwargs)
File "pydantic/main.py", line 342, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 1 validation error for Theme
syntax_style
Incorrect `syntax_style` value: gruvbox-light provided. Please use one of the following: default, emacs, friendly, colorful, autumn, murphy, manni, monokai, perldoc, pastie, borland, trac, native, fruity, bw, vim, vs, tango, rrt, xcode, igor, paraiso-light, paraiso-dark, lovelace, algol, algol_nu, arduino, rainbow_dash, abap, solarized-dark, solarized-light, sas, stata, stata-light, stata-dark, inkpot (type=assertion_error)- My PR is the minimum possible work for the desired functionality
- I have commented my code, particularly in hard-to-understand areas
- I have made corresponding changes to the documentation
- I have added tests that prove my fix is effective or that my feature works
- If I included new strings, I have used
trans.to make them localizable. For more information see our translations guide.
Co-authored-by: Lorenzo Gaifas brisvag@gmail.com
Matterforge Recipe expansion (#5168)
This PR adds a few more matterforge recipes, some of stupidly high difficulty and pointless rewards if miners are doing their job (looking at you steel to gold), some of more usefulness (gold to plat, plat to osmium). All require different temperature and energy ranges so they cannot be rushed thoroughly. Not much thought was put into realism but eh who cares, the matterforge is a cool thing ingame and its fun to use. Some temperatures ranges (Steel to gold) are very narrow hence the use of a gyrotron would be needed to get the most out of it. Or precise heating (temperature can be raised to exorbitant amounts to prevent heater cheese). This also would allow for Research to collab with cargo for exports specially if dynamic prices ever come. In particular looking at the gold to plat transmutation here. Plat can be exported by cargo in which cargo can order more shit from.
I aint a good coder else I would add specific atmospheric conditions needed, not just temperature (e.g. N2O must be present). Reminded me a bit of TGs gas reactions but less gamy.
More Matterforge recipes. Most relatively pointless and niche, some allow science to give cargo something to sell, others can help with theres an overabundance of Plat due to new miners. Mostly just giving some extra uses for the forge. Oh and an alternative way to get plasteel while sacrificing phoron sheets. Also bragging rights of effectively turning iron (and carbon) into gold at specific temperatures and energy levels on the particle focus.
A proper coder should check if these recipes are fine. Its 2:30 AM and I thought this would just be neat.
🆑 add: Various matterforge recipes /🆑
yeah i made an ugly website. but i made it look cute like a fuckin gangster
Admins can now choose where fish go (#73109)
I've pigeonholed myself as the fish guy now. It seems like someone made events easier to add admin controls for so I thought I'd add some to the event I most recently touched.
Instead of letting the RNG choose admins can now direct a circle of carp to converge upon a specific location, or even a trail of specific locations if they want the carp to just sort of swim in a circle around the space station (although the ones on the far side of the station from the starting point will travel all the way through it to get there). This also works with magicarp. They don't really move fast enough for you to use this to punish a specific person but you can use it to annoy a specific location full of people.
Plausibly there's no reason the code wouldn't work for a specified atom instead of a turf (as long as it sticks to one z level) but I couldn't think of an elegant way of selecting that whereas "use my current ghost location" is very intuitive, so I didn't add one.
Plausibly this permits admins do more fun things.
🆑 admin: Admins can direct where carp (or magicarp) are interested in going when manually triggering the event /🆑
set letter to technical-failure if we cant find it in s3
otherwise we'll just do nothing until the next day, when we'll try and send it again. i think the chance of it appearing in s3 overnight feels slim to unlikely - this was behaviour we added three years ago1 but i'm not sure i remember us ever receiving these log messages.
Create kiwisucks.html
Kiwi is a very bad parakeet, there is no wonder why nobody likes her, first of all, she is trying to impersonate Goose, who is better then kiwi. First, shes green, Second, shes annoying, and lastly, she is a bad bird who gets sensetive at everything. At the end of the day, everyone knows that kiwi sucks, and Goose is better then her in every possible way.
Compose migration (#26)
- Modify configuration files to support Kotlin & Jetpack Compose
As discussed this morning, we plan on moving to Kotlin and Jetpack compose. This commit marks the beginning of the modification to make it.
- Update minSdk to comply with firebase requirement
Changes:
-
Change from minSdk:24 to minSdk:28 to comply with the firebase realtime database requirements
-
Delete old java activity file and write basic test
Changes:
-
Remove
GreetingActivity.javaandMainActivity.javaand dependencies -
Write simple
ComposeActvitityTest.kt -
fix: Support for coverage with Kotlin
-
Added Mockito
-
Fixed the build.gradle with proper versions
-
🔥 💯 :triump: base 😡
Co-authored-by: BoyeGuillaume guillaume.boye@epfl.ch
supplies sprite
The unenlightened masses They cannot make the judgment call Give up free will forever Their voices won't be heard at all Display obedience While never stepping out of line And blindly swear allegiance Let your country control your mind Live in ignorance And purchase your happiness When blood and sweat is the real cost Thinking ceases, the truth is lost Don't you worry You'll be told exactly what to do I give my people the lives they need The righteous will succeed The fires of greed will burn the weak So we'll make freedom obsolete Making whole the fabric of society Collective consciousness controlled as you will see MIND CONTROL Let your country control your soul Let your country control your soul Let your country control your soul Let your country control your soul
[MIRROR] Brings the monkey back down (body horror edition/addition.) [MDB IGNORE] (#19572)
- Brings the monkey back down (body horror edition/addition.) (#73325)
Let me paint you a story. A long time ago monkeys once rested their feet on the floor, this was a time of bliss and peace. But sometime around the horrors of making monkeys subtypes of humans did an atrocity occur.
The monkeys were moved up.
I thought this was bad, and alot of people on the forum tended to agree
with me
This was do to some purpose of adjusting them so it could be easier to
fit item sprites onto them instead of preforming the hours of work
refractoring to make the heights of the items dynamic and adjustable. A
simple pixel shift may have sufficed, but you see, such a change would
NEVER allow the frankensteining of monkey and human features together.
This is that refractor.
In essence, the following is now true. A top_offset can now be generated for a human based on a varible on their chest and legs. By default, and as is true with human legs and chests, this variable is ZERO by default. Monkey legs and chest have NEGATIVE values proportionate and onto how much smaller their sprite is compared to humans. Other bodyparts, as well as any other accociated overlays, or clothing will automatically be offset to this axis. THIS MEANS THAT MONKEYS ARE ON THE FLOOR. But is means something else too. Something more freakish,
What abominable monsters, unreachable by players as long as we can't
stitch monkeys and humans together (oh but just wait until the feature
freeze ends)
Oh but you might be thinking, if legs can make a mob go down.
can it make a mob
go up??
OH NO
These lads are stepping, and have been implemented solely for proof of concept as a way to flex the system I have created and remain inaccessible without admin intervention.
But really, when all is said and done, all this PR does in terms of player facing changes is move the monkey back down.
Oh and fixed monkey husked which have been broken for who knows how
long.
The monkey is restored to its original position. Tools now exist to have legs and torsos of varying heights. Monkey Husking is fixed.
🆑 itseasytosee fix: Monkeys ues the proper husk sprites. imageadd: The monkey has been moved back down to its lower, more submissive position. refactor: Your bodyparts are now dynamically rendered at a height relevant to the length of your legs and torso, what does this mean for you? Not much to be honest, but you might see a monkey pop up a bit if you cut its legs off. admin: The Tallboy is here /🆑
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com> Co-authored-by: san7890 <the@ san7890.com>
-
Brings the monkey back down (body horror edition/addition.)
-
Update species.dm
-
Delete infuser_entries.dm
Co-authored-by: itseasytosee 55666666+itseasytosee@users.noreply.github.com Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com> Co-authored-by: san7890 <the@ san7890.com> Co-authored-by: Gandalf 9026500+Gandalf2k15@users.noreply.github.com
fix build errors (i fucking hate typescript fuck you typescript)
Add files via upload
Command Line Interface for the new gpt-4 model. Just a demo for shaking out the dust on this connection. Usage should be apparent from the code but here's a basic: python CLI_GPT4.py -u "it's raining" -a "Dogs like people." prints the outgoing message: [{'role': 'system', 'content': 'You are a happy idea bot, you give people ideas that make them happy'}, {'role': 'user', 'content': "it's raining"}, {'role': 'assistant', 'content': 'Dogs like people.'}] and the reply: How about having a fun indoor game day with your family or friends? You can play board games, video games, or even create your own DIY games. Enjoy some healthy competition and laughter as you make the most of the rainy day. Don't forget to prepare some snacks and cozy beverages like hot chocolate or warm tea to complete the experience.