2,531,179 events, 1,286,617 push events, 2,058,647 commit messages, 156,410,081 characters
Merge pull request #147 from dmoore29/Anthony
fuck you
files from my friend
his comments: These files have not been peer reviewed, but have been vetted by scientists with extensive amounts of experience with virology and molecular biology, I hope they help.
Got rid of the annoying bullshit
FUCKING TOO MANY MESSAGES
Merge pull request #114 from cil5345/feature/login
fuck you github
commit lastest ning's code
i'm sorry my friend. forgive me. i'm so stupid.
Decouple GUI and data model patcher classes:
I spent a lot of time thinking of a common base class for GUI and business logic patchers till it dawned me: there should be no common base class. This commit decouples the config phase from the business logic. GUI is responsible for collecting the patches config and instantiating the patchers. 'name', 'text' and 'tip' are moved to gui, where they belong and are renamed to unique per hierarchy identifiers, at long last. We still have ~400 'name' in core Bash - 'text' is now down at ~120.
Since now the patchers need not be instantiated once per run we can
finally instantiate the data model patchers as needed - so I replaced
initPatchFile with __ini__ and I instantiate patchers per patch.
Other pros:
- more straightforward - new patch new patchers
- all config phase in now in a central place where we can further edit it.
- squash unresolved attributes warnings
- squash attribute defined outside of init warnings
- no MI - not a problem per se but not suitable here, actually the root of the issue
Cons:
- 'init' is less searchable than initPatchFile, but modern IDEs should be (modulo bugs) able to list implementation (Navigate > Implementation(s))
- Different init signatures in Abstract_Patcher and AListPatcher
TODOs:
-
enforce API: calling a "not isActive" patcher could raise an error (note the doc "All functions are called after this")
-
what happens if all enabled patchers are not active - we should return
-
UpdateReferences._record_types -> we have to use getReadWriteClasses: MreRecord.listTypes is not yet set when we import oblivion/patchers TODO: move to another file that is not imported in game/*/patcher
-
allowUnloaded and srcs attributes is a mess:
- changed allowUnloaded to False in CBash_AliasesPatcher, CBash_AlchemicalCatalogs, CBash_ContentsChecker
- CBash_SEWorldEnforcer: We need to have a srcs attribute as we have scanRequiresChecked=True (messy)
new issue since then (# 495) <-- RRR. We should add sources as a method mixin differentiating mod and csv sources there.
-
allowUnloaded can't be moved to getAutoItems - allSet is populated in PatcherMerge init (duh)
-
btw note common code in: Mopy/bash/basher/patcher_dialog.py Mopy/bash/basher/mod_links.py
I dropped a lot of if not self.isActive: return. The processing
is minimal (creating couple empty dicts) and since the patcher init is
only called on enabled patchers chances are they are active too.
Naming: separate names for separate class hierarchies - why can be seen
in this commit. I chose explicitly rough ones for the init hierarchy
as they (wrap better and oh) need to be easily excluded - params in
methods hierarchies are just noise, the attributes are of interest. For
those I have chosen to differentiate between class hierarchies - the
private _patcher_name is inherited from the GUI to be used in logs -
and signals a weak coupling that remains from MI.
SpecialPatcher erosion
Race patcher has its own issue by now (# 494) <-- RRR. Here I unmade it from a SpecialPatcher subclass as only CBash patchers use scan_more - RacePatcher just used group/editOrder/scanOrder overrides
-
CBash_RacePatcher: revisit allowUnloaded - False?
-
isActive for this patcher is set to True - unfortunately we can't just use AMultiTweaker/AListPatcher inits. Of course if the patcher is not enabled it shouldn't run.
-
SpecialPatcher(CBash_Patcher): yep, this permitted a common base class for _CBashOnlyRacePatchers. However it also hid some unused variable warnings. This is CBash patchers API however that does need work - for one the hasattr calls in CBash_PatchFile.buildPatch
Bye autoRe
The names patcher override was gone since d9b0c3e446c325337715eb8d809aee7aa4015de5 This whole machinery turns out to be used in one place - I moved it there
Mopy/bash/patcher/base.py: srcs are always present:
def _srcMods(self,log):
-
"""Logs the Source mods for this patcher - patcher must have `srcs` -
attribute otherwise an AttributeError will be raised."""
-
"""Logs the Source mods for this patcher."""
More SpecialPatcher erosion - move more config to gui from special
Mopy/bash/game/oblivion/patcher/special.py: Special was one of the things that stopped me from common ABC between GUI and data model - for a good reason, now at least the complexity is explicit (see get_cls_vars)
Reworked tweaks
- Names - what's the deal with bodyTags - they must be moved to game/ anyway - CBash_NamesTweaker and bodyTags -> done later on this branch by Infernio
patches_set:
Mopy/bash/patcher/init.py: moved patches set here - we need an API for patchers that have text file sources Mopy/bash/game/oblivion/patcher/special.py:
- common read from text - note I dropped some GPath calls
- works correctly? Especially: SEFF = MGEFCode('SEFF') - any reason it should not be in class scope?
- we need a common initData
-
id_exhaustion[longid] = int(time) may raise VE -
except (IndexError, ValueError): -
pass # too few items, we couldn't unpack or int() failed
- belongs to gui (should filter the sources) but oblivion/special are in the way
On a second thought as patches_set is populated in the GUI the self.srcs are always in the set if they don't exist anymore (see Mopy/bash/game/oblivion/patcher/special.py) in Mopy/bash/patcher/patchers/base.py there were if file checks but here is a classic application of EAFP:
fields=[1,2,3] mod,objectIndex,eid,time = fields[:4] Traceback (most recent call last): File "", line 1, in ValueError: need more than 3 values to unpack int('abc') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: 'abc'
Moved _read_write_records to _Abstract_Patcher - better names needed
Mopy/bash/patcher/patchers/multitweak_names.py Mopy/bash/patcher/patchers/multitweak_assorted.py: Some getTypes pruning in tweaks
self.activeTypes is only read so I replaced it with tweak_read_classes
CBash race getTypes - remove class variable races_data
Mopy/bash/patcher/patchers/importers.py: moved tag_attrs out of init, they are static
SpecialPatcher(CBash_Patcher):
scan_more is only used in CBash and then not in all the previous subclasses of SpecialPatcher
Threw some prefixing in - Mopy/bash/game/oblivion/patcher/init.py: note type names must be string, check in py3
Infernio:
Refactoring _AListsMerger a bit
Properly passes a defaultdict version of configChoices in instead of hackily assigning it later and unifies the deflstMasters/delevMasters variables as de_masters, eliminating some duplicate code.
Note this diff:
-
self.srcMods = set(self.srcs) & p_file.loadSet
-
self.srcs = set(self.srcs) & p_file.loadSet
That's almost certainly what was intended (it mirrors ListsMerger perfectly), but the srcMods/srcs difference seems to have been missed during the FO3/FNV merge.
Also dropped some commented out lines from the ListsMerger that were still in the FidListsMerger and marked mastersScanned with a FIXME - that was probably intended to avoid duplicate work for the de_masters calculation, have to check if using it is feasible.
_AListsMerger couple docstring + fixup
Note that I dropped the itemgetter import, found that usage horribly confusing, IMO the list comprehension is much clearer. Might be slower, feel free to benchmark
Co-authored-by: Infernio [email protected]
vendor: notch-city: Add 3 mode display cutout handler [2/3]
[@AgentFabulous - POSP]
- Introduces the HideCutout and StatusBarStock overlay used in the 3 mode display cutout handler. The HideCutout overlay is necessary since we can't register a content observer in the display manager code. We only have access to resources during boot. Thus, leave this as an overlay and let the config and overlay change methods handle this. Though we can probably do statusbar stock height toggling in the SystemUI code without overlays, I kinda got lazy by the end, just live with it god damn it xD
Signed-off-by: Kshitij Gupta [email protected] Change-Id: I62f63f39bcb410cfbc68e0028b9cef3d748d7eb6
UI: Layout changes for new checkbox layout possibilities
Follow-up to previous commit.
Some examples: {F8473507} {F8473508} {F8473509} {F8473510} For more screenshots, please see D7430.
We use column or row headings here to bring more structure, and to give the eye visual anchors which aid eye-scanning. The left-aligned checkboxes likewise help with this. And we keep the adherence to the center line, so the alignment matches up between the various buttons and controls.
- Changes the property split percentage from 50/50% to 40/60%. This is needed to give enough space for the checkboxes. But in most cases this looks better anyway - see Transform panel. In some cases it simply fills out the available space more efficently.
- Fix various hacks where we previously used manually defined splits. When we did this, the alignment was never quite right, and the layout code was a mess.
- Adds column headings to many places where a list of checkboxes all share a common purpose or leading text.
- Add checkbox + value configurations various places where a checkbox only serves to enable the value slider
- Removes most uses of grid flow layout. The grid flow layouts combine poorly with column headings, and also they would mess alignment up badly. The grid flow layouts also often made buttons and controls jump around on the screen if you would just resize editors slightly, causing visual confusion, making users lose their place. The logic for at what time the list of items would re-flow was often flawed, jumping to multiple columns too fast or too late - and frankly, the grid flow layouts would often just look bad.
Maniphest Task: https://developer.blender.org/T65965
Differential Revision: https://developer.blender.org/D7430
Reviewed by: Brecht Van Lommel, Pablo Vazquez.
Most work here by William Reynish, few changes by Julian Eisel.
ZEN: INTERACTIVE: Set MuQSS' yield_type to 0 (don't yield)
Turns out when I investigated performance issues with RPCS3 on Linux with MuQSS, my choice to set yield_type to 2 was flawed since I didn't benchmark or any other applications that cared about it.
Phoronix wrote an article measure performance of Liquorix against a stock 5.4 configuration here: https://www.phoronix.com/vr.php?view=28750
All the benchmarks measured framerate and Liquorix for the most part got up to 20% less FPS than stock CFS, depending on the game. Turns out some of it had to do with yield_type, and always yielding when requested dropped minimum frame times quite a bit. Disabling yield entirely raised the average frame rate a bit and the minimum frametimes on Deus Ex: Mankind Divided by nearly 10%.
Also, Linus Torvalds wrote in a forum about sched_yield. He indicated that yield used to make sense on uniprocessor configurations, but now with multi-core being the norm, yield almost always causes performance issues due to cache thrashing and thread/process migration on multicore systems: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189752
And finally, even if we don't yield, MuQSS will reschedule the thread that's spinning anyway. All setting yield_type to 2 did was reschedule the thread sooner. Lets let MuQSS decide when a thread needs to be rescheduled, not the program.
Previous commit messages:
muqss, zen: Set yield_type to 2
In my previous attempt in making games and emulators behave better, I found that making sched_yield a no-op by setting yield_type to 0 caused emulators like RPCS3 to perform far better without frame drops. Unfortunately, on my next boot I noticed the whole system felt less responsive in general.
Fortunately, always expiring the timeslice of the yielding process and calculating the next deadline also fixes this weird performance anomaly. Setting yield_type to 2 with a reduced rr_interval (2ms), should help offset the disadvantages of rescheduling a process that has yielded.
muqss, zen: Disable sched_yield by default
While experimenting with audio stutter and frame drops through the RPCS3 emulator, I found that yet again, sched_yield is the source of unpredictable performance drops. Reading the original post[1] by Con where he outlined his last (final?) change to sched_yield, he changed the behavior of sched_yield in MuQSS to only yield to better priority or deadline tasks.
It seems then on my system, emulators and games are yielding to some number of higher priority / next deadline tasks and performing much worse. If you look at the comments on the blog post, however, many people found that setting yield_type to 0 improve performance on their games.
Lets just turn sched_yield into a noop for now and see how that fairs. Worst case we'll receive a report about an application behaving badly, and best case everyone will get a net benefit in gaming and emulators.
[1] http://ck-hack.blogspot.com/2016/12/linux-49-ck1-muqss-version-0150.html
Revert "muqss, zen: Disable sched_yield by default"
This reverts commit 8ec985bcd0ded1bcdd8bb999c90c094dc9536a0b.
This change, as expected, has strange side-effects with system responsiveness when many applications are launching at boot. Also at random times, the mouse becomes unresponsive while over saturating CPU bandwidth.
Rename Connect4 my life is hell i want to die.iml to Connect4.iml
Finishes up basic mechanics and un-buggifies them
cum is stored in the red solo cup is the best receptacle For barbecues tailgates fairs and festivals And you sir do not have a pair of testicles If you prefer drinking from glass A red solos cup is cheap and disposable And in fourteen years they are decomposable And unlike my home they are not fore-closable Freddie Mac can kiss my ass woo Red solo cup I fill you up Let's have a party let's have a party I love you red solo cup I lift you up Proceed to party proceed to party Now I really love how your easy to stack But I really hate how your easy to crack 'Cause when beer runs down the front of my back Well that my friends is quite yucky But I have to admit that the ladies get smitten Admiring how sharply my first name is written On you with a sharpie when I get to hittin' On…
Merge pull request #6 from ESMAPP/dev
Seriously this shit be crazy, fuck all dis shit
So it turns out writing 3D files in 2D slices is has fucktacularly shitty performance. But we leave this as an option passed at the command line for now at least. I am just going to hold my nose and allocate yet another 3D array. Gotta make the bottlenecks as fat as possible.
Custom webpage, textline submission system
Not the prettiest websites out there but do I look like I care? This bot is a fucking joke. I can't fucking deal with this shit, man! Fuck off! How about you all kill yourselves. Fuck!!!
anyways yeah, still should work.
Replace NonAggregate with something less broken
This commit implements the proposal laid out at https://discourse.diesel.rs/t/proposed-change-replace-nonaggregate-with-something-less-broken-that-can-support-group-by/18.
The changes made in this commit now correctly enforce semantics around
the mixing of aggregate/non-aggregate expressions, and lays the
foundations required for full GROUP BY support in the future. This
commit does not implement GROUP BY as a feature in public API, though
I have added some minimal support to prove the soundness of the change.
Since this will likely be the largest breaking change in 2.0, I am going to include as much detail as I can about the problem, the reasoning behind the solution, and the likely impact of the change.
NonAggregate was originally introduced in
c66d96fa9cefaba0a418834e8cb0e78a0a87269a. The goal was to prevent the
following error at compile time:
[local] sean@sean=# select count(*), name from users; ERROR: 42803: column "users.name" must appear in the GROUP BY clause or be used in an aggregate function
I didn't think about this nearly as much as I should have at the time,
which resulted in a hilariously broken implementation that has prevented
the addition of group_by support, and left bugs in the codebase for
more than 4 years.
At the time I was focused on "mixing aggregate and non-aggregate
expressions in a select statement". Since select uses tuples to
represent multiple values, I added a trait to represent non-aggregate
values, added it as a bound for impl Expression for AnyTuple, and
called it a day. This had a number of problems.
The most obvious was that it prevented valid queries involving multiple
aggregate expressions. At the time I figured we'd have a separate
trait for aggregate expressions, and then impl Expression for AnyTuple where AllFields: NonAggregate | AllFields: Aggregate. This eventually
led to RFC #1268, which
doesn't seem likely to be stabilized soon, and even if it were we still
have the other issues with this solution.
The next issue is that you cannot say whether a given expression is
aggregate by looking at it on its own. The answer to "Is users.name
aggregate?" depends on whether or not that column appears in the group
by clause. So any trait which correctly handles this must be generic
over the group by clause, or it cannot be correctly implemented for
columns.
However, the most egregious issue with that commit is that it does not
handle any composite expressions besides tuples. Even today,
.select((count_star(), id)) fails, but .select(count_star() + id)
will compile (and either error at runtime or give non-deterministic
results depending on your backend).
This change will unfortunately have more breakage than I had anticipated. That said, the breakage only affects extremely generic code, and I do not believe that the majority of our users will notice or care about this change.
There are three main ways in which the breakage will affect users:
- The additional bound on
SelectStatement<...>: SelectDslandSelectStatement<...>: Query.- This one broke our test suite in a few places, mainly where we have really generic code to say "I can select T.eq(sql_string)". I do not believe this is representative of real code.
- I did a GitHub-wide search of all occurances of
SelectableExpression(which is not the bound on the public API, but is the bound onSelectStatement's impl, and would point to broken code). I found one repo which is relying on internals that will break, and a lot of results from Wundergraph. I didnt' look at those. This probably breaks Wundergraph. Sorry, Georg. It should be easy to fix I promise.
NonAggregatecan no longer be directly implemented- I did a GitHub-wide search for
NonAggregate. With one exception, every repo implementing this trait directly was on pre-1.0. The only affected repo is manually implementingExpressioninstead of using#[derive(AsExpression)]. With that change they will be future-proofed.
- I did a GitHub-wide search for
T: NonAggregateno longer implies(OtherType, T): NonAggregate- This broke
infer_schema, since it was relying onAssocType: NonAggregateto know(known_column, AssocType, known_column): Expression. Ironically, that's no longer important, it did still break due to the first item on this list. I could not find any code in the wild that fell into this category.
- This broke
Originally I thought that the only code which would be affected by this
is code that wrote impl NonAggregate, since that code would need to
change to impl ValidGrouping. However, I missed a few things when I
made that assessment.
The first is that... Well the feature exists. The whole point of this
was to prevent aggregate + non_aggregate from compiling when passed to
select, which implies a new trait bound somewhere. While
SelectStatement and its impls are private API, it's really easy to
couple yourself ot the bounds on those impls. It doesn't help that
rustc literally recommends that folks do that when errors occur. Any
code that is written as Foo: SelectDsl<Selection> will be fine, but
any code that's gone down the rabbit hole and has copied the bounds from
impl SelectDsl for SelectStatement<...> will break. I didn't find many
cases in the wild, but I do think it's relatively common.
The second thing I missed is that "is this aggregate" is not a binary
question. Originally I expected we would have two answers to the
question, and compound expressions would enforce that their
sub-expressions all had the same answer. The issue is that 1 doesn't
care. You can have count(*) + 1, and you can also have `non_aggregate
- 1
.1is always valid, regardless of aggregation. So we need three answers. The problem is that this means we can't haveT: NonAggregate` mean everything it used to.
On stable T: NonAggregate will mean T: ValidGrouping<()>, and that
T can be passed to everything with a NonAggregate bound (filter,
order, etc). On nightly, it also implies T::IsAggregate: MixedAggregates<is_aggregate::No, Output = is_aggregate::No>. In
English, it implies that this is valid with no group by clause, and its
output can appear with an expression which is not aggregate (but might
be with a different group by clause). The outcome of this is that T: NonAggregate implies (T, Other): NonAggregate. However the missing
link from both stable and unstable is is_aggregate::No: MixedAggregates<T::IsAggregate> being implied, which would mean
(Other, T): NonAggregate would be implied.
Ultimately this is a really long-winded way of saying that T: NonAggregate used to imply interactions with other types. That is no
longer consistently true. It's unlikely there are many affected users,
but any that are affected will need to directly have a ValidGrouping
bound.
Because this broke diesel_infer_schema, I had to do a version bump to get that crate to rely on the released 1.4.
There's a note on the unsoundness of the NonAggregate impl of
Subselect. I haven't changed the bounds on that impl, but we almost
certainly should address it before 2.0 is released.
I opted to validate the new bound in SelectDsl, so folks get errors on
.select instead of .load. We can't validate this on calls to both
.select and .group_by, since a select statement valid with a group
by is often invalid without one, and a group by clause usually makes the
default select clause invalid.
While this commit does not add proper group by support, I fleshed it out a bit to test the type constraints. Right now a column only considers itself valid if there is no group by clause, or if the group by clause is exactly that column.
I had more to say but I went on a call and lost my train of thought. I need to come back and finish writing this later.
SELECT lower(name) FROM users GROUP BY lower(name) probably can't be
represented.
BoxableExpression has been limited to only work when there's no
group by clause, and only work with types which are is_aggregate::No.
This is probably not what we want to do, but was the smallest change to
start.
sd_lavc: mitigate evil rounding issue that could lead to off-by-1 frames
A mkv sample file was provided to me, which contained a moving PGS subtitle track, with the same track rendered into the video as reference. The subtitle track appeared to stutter (while the video one was smooth). It turns out this was a timestamp rounding issue in mpv.
The subtitle timestamps in the file match the video ones exactly. They're the same within the mpv demuxer too. Unfortunately, the conversion from and to libavcodec timestamps is lossy, because mpv uses a non-integer timebase, while libavcodec supports integers only. See mp_pts_to_av() and mp_pts_from_av(). The recovered timestamp is almost the same, but is off by a very minor part. As a result, the timestamps won't compare equal, and if that happens, display of the subtitle frame is skipped. Subtitle timestamps don't go through this conversion because... libavcodec is special? The libavcodec subtitle API is special.
Fix this by giving it a microsecond of slack. This is basically as if we used an internal microseconds integer timebase, but only for the purpose of image subtitle display.
The same could happen to sd_ass, except in practice it doesn't. ASS subtitles (well, .ass files) inherently use a timebase incompatible to video, so to ensure frame exactness, ASS timestamps are usually set to slightly before the video frame's.
Discussion of better solutions:
One could rewrite mpv not to use float timestamps. You'd probably pick some integer timebase instead (like microseconds), which would avoid the libavcodec interop issue. At the very least this would be a lot of work.
It would be interesting to know whether the rounding in ther mpv<->lavc timestamp conversion could be fixed to round-trip in this case. The conversion tries to avoid problems by using the source timebase (e.g. milliseconds with mkv). But in general some rounding is unavoidable, because something between decoder and lowest demuxer layer could transform the timestamps.
One could extend libavcodec to attach arbitrary information to avpacket and return it in the resulting avframe. To some degree, such a mechanism already exists (side data). But there are certain problems that make this unfeasible and broken.
One could pass through exact mpv float timestamps by reinterpret-casting them to int64_t, the FFmpeg timestamp type. Actually mpv used to do this. But there were problems, such as FFmpeg (or things used by FFmpeg) wanting to interpret the timestamps. Awful shit that make mpv change to the current approach.
There's probably more but I'm getting bored. With some luck I wasted precious seconds of your life with my nonsense.
draw_bmp: silence another ridiculous ubsan warning
UB sanitizer complains that aval<<24 (if >=128) cannot be represented as int. Indeed, we would shift a bit into the sign of an int, which is probably UB or implementation defined (I can't even remember, but the stupidity of it burns). So technically, ubsan might be right.
Change aval to uint32_t, which I don't think has a chance of getting promoted to int. Change the other *val to uint32_t too for cosmetic symmetry.
So we have to obscure the intention of the code (*val can take only 8 bits) out of language stupidity. How nice. (What a shitty language.)