there were a lot of events recorded by gharchive.org of which 2,021,095 were push events containing 2,634,898 commit messages that amount to 143,114,758 characters filtered with words.py@e23d022007... to these 19 messages:
Fucking around
Just textures and cockmeshs
Remember to turn off the egg decision
music: add non-standard artist fields
Add non-standard ARTISTS/ALBUMARTIST fields to reasonable places in the ID3v2 and Vorbis parsers.
Turns out these are stupidly common when multi-artist information is used in order to maximize player compatibility. More or less, TPE1 and ARTIST will be filled in with delimited values, while ARTISTS will be filled in with native multi-value information.
This is stupid and insane, but I want to prioritize a good out of box experience without much user fiddling, so I may as well implement these.
Currently, I'm only adding the non-standard fields that I know exist. This doesn't include hypothetical but unencountered fields like TXXX:ALBUMARTISTS.
[MIRROR] [MDB IGNORE] Allows Chaplain's Spirit Sword To Redo Name If Invalid (#4104)
- Allows Chaplain's Spirit Sword To Redo Name If Invalid (#72642)
The current behavior doesn't let the sword re-choose their name if they screw it up the first time and it turns out to be filtered or sanitized out for whatever reason. That's silly in my opinion, so I changed it to be more like holoparasite name-selection behavior, where you get the text to choose your name until you get it right.
I moved the re-naming portion of the sword to be after all of the important RegisterSignal steps as well, just to be safe as we sleep as they plug in different names they might want.
You shouldn't be stuck as "spirit of the blade" permanently if you accidentally balls up the word filter, let's have it be more like holoparasite behavior to be nicer.
🆑 qol: Spirits of possessed blades (Chaplain's Null Rod Option) will be able re-try selecting their name if it ends up to be filtered for any reason. /🆑
- Allows Chaplain's Spirit Sword To Redo Name If Invalid
Co-authored-by: san7890 [email protected]
Hello Ladies and Gentlemen
Narcissistic personality disorder is a mental health condition in which people have an unreasonably high sense of their own importance. They need and seek too much attention and want people to admire them. People with this disorder may lack the ability to understand or care about the feelings of others. But behind this mask of extreme confidence, they are not sure of their self-worth and are easily upset by the slightest criticism.
A narcissistic personality disorder causes problems in many areas of life, such as relationships, work, school or financial matters. People with narcissistic personality disorder may be generally unhappy and disappointed when they're not given the special favors or admiration that they believe they deserve. They may find their relationships troubled and unfulfilling, and other people may not enjoy being around them.
Treatment for narcissistic personality disorder centers around talk therapy, also called psychotherapy.
Narcissistic personality disorder affects more males than females, and it often begins in the teens or early adulthood. Some children may show traits of narcissism, but this is often typical for their age and doesn't mean they'll go on to develop narcissistic personality disorder.
Products & Services Book: Mayo Clinic Family Health Book, 5th Edition Show more products from Mayo Clinic Symptoms Symptoms of narcissistic personality disorder and how severe they are can vary. People with the disorder can:
Have an unreasonably high sense of self-importance and require constant, excessive admiration. Feel that they deserve privileges and special treatment. Expect to be recognized as superior even without achievements. Make achievements and talents seem bigger than they are. Be preoccupied with fantasies about success, power, brilliance, beauty or the perfect mate. Believe they are superior to others and can only spend time with or be understood by equally special people. Be critical of and look down on people they feel are not important. Expect special favors and expect other people to do what they want without questioning them. Take advantage of others to get what they want. Have an inability or unwillingness to recognize the needs and feelings of others. Be envious of others and believe others envy them. Behave in an arrogant way, brag a lot and come across as conceited. Insist on having the best of everything — for instance, the best car or office. At the same time, people with narcissistic personality disorder have trouble handling anything they view as criticism. They can:
Become impatient or angry when they don't receive special recognition or treatment. Have major problems interacting with others and easily feel slighted. React with rage or contempt and try to belittle other people to make themselves appear superior. Have difficulty managing their emotions and behavior. Experience major problems dealing with stress and adapting to change. Withdraw from or avoid situations in which they might fail. Feel depressed and moody because they fall short of perfection. Have secret feelings of insecurity, shame, humiliation and fear of being exposed as a failure. When to see a doctor People with narcissistic personality disorder may not want to think that anything could be wrong, so they usually don't seek treatment. If they do seek treatment, it's more likely to be for symptoms of depression, drug or alcohol misuse, or another mental health problem. What they view as insults to self-esteem may make it difficult to accept and follow through with treatment. If you recognize aspects of your personality that are common to narcissistic personality disorder or you're feeling overwhelmed by sadness, consider reaching out to a trusted health care provider or mental health provider. Getting the right treatment can help make your life more rewarding and enjoyable.
Causes It's not known what causes narcissistic personality disorder. The cause is likely complex. Narcissistic personality disorder may be linked to:
Environment — parent-child relationships with either too much adoration or too much criticism that don't match the child's actual experiences and achievements. Genetics — inherited characteristics, such as certain personality traits. Neurobiology — the connection between the brain and behavior and thinking. Risk factors Although the cause of narcissistic personality disorder isn't known, some researchers think that overprotective or neglectful parenting may have an impact on children who are born with a tendency to develop the disorder. Genetics and other factors also may play a role in the development of narcissistic personality disorder.
Complications Complications of narcissistic personality disorder, and other conditions that can occur along with it include:
Relationship difficulties Problems at work or school Depression and anxiety Other personality disorders An eating disorder called anorexia Physical health problems Drug or alcohol misuse Suicidal thoughts or behavior Prevention Because the cause of narcissistic personality disorder is unknown, there's no known way to prevent the condition. But it may help to:
Get treatment as soon as possible for childhood mental health problems. Participate in family therapy to learn healthy ways to communicate or to cope with conflicts or emotional distress. Attend parenting classes and seek guidance from a therapist or social worker if needed.
!DOCTYPE html>
What is Narcissistic Personality Disorder?
Narcissistic personality disorder is a mental health condition in which people have an unreasonably high sense of their own importance. They need and seek too much attention and want people to admire them. People with this disorder may lack the ability to understand or care about the feelings of others. But behind this mask of extreme confidence, they are not sure of their self-worth and are easily upset by the slightest criticism.
A narcissistic personality disorder causes problems in many areas of life, such as relationships, work, school or financial matters. People with narcissistic personality disorder may be generally unhappy and disappointed when they're not given the special favors or admiration that they believe they deserve. They may find their relationships troubled and unfulfilling, and other people may not enjoy being around them.
Treatment for narcissistic personality disorder centers around talk therapy, also called psychotherapy.
Narcissistic personality disorder affects more males than females, and it often begins in the teens or early adulthood. Some children may show traits of narcissism, but this is often typical for their age and doesn't mean they'll go on to develop narcissistic personality disorder.
Click Me!
Symptoms
Symptoms of narcissistic personality disorder and how severe they are can vary. People with the disorder can:
Have an unreasonably high sense of self-importance and require constant, excessive admiration. Feel that they deserve privileges and special treatment. Expect to be recognized as superior even without achievements. Make achievements and talents seem bigger than they are. Be preoccupied with fantasies about success, power, brilliance, beauty or the perfect mate. Believe they are superior to others and can only spend time with or be understood by equally special people. Be critical of and look down on people they feel are not important. Expect special favors and expect other people to do what they want without questioning them. Take advantage of others to get what they want. Have an inability or unwillingness to recognize the needs and feelings of others. Be envious of others and believe others envy them. Behave in an arrogant way, brag a lot and come across as conceited. Insist on having the best of everything — for instance, the best car or office.
Click Me!At the same time, people with narcissistic personality disorder have trouble handling anything they view as criticism. They can:
Become impatient or angry when they don't receive special recognition or treatment. Have major problems interacting with others and easily feel slighted. React with rage or contempt and try to belittle other people to make themselves appear superior. Have difficulty managing their emotions and behavior. Experience major problems dealing with stress and adapting to change. Withdraw from or avoid situations in which they might fail. Feel depressed and moody because they fall short of perfection. Have secret feelings of insecurity, shame, humiliation and fear of being exposed as a failure.
Click Me!
WHEN TO SEE A DOCTOR
People with narcissistic personality disorder may not want to think that anything could be wrong, so they usually don't seek treatment. If they do seek treatment, it's more likely to be for symptoms of depression, drug or alcohol misuse, or another mental health problem. What they view as insults to self-esteem may make it difficult to accept and follow through with treatment.
If you recognize aspects of your personality that are common to narcissistic personality disorder or you're feeling overwhelmed by sadness, consider reaching out to a trusted health care provider or mental health provider. Getting the right treatment can help make your life more rewarding and enjoyable.
Click Me!
Causes
It's not known what causes narcissistic personality disorder. The cause is likely complex. Narcissistic personality disorder may be linked to:
Environment — parent-child relationships with either too much adoration or too much criticism that don't match the child's actual experiences and achievements. Genetics — inherited characteristics, such as certain personality traits. Neurobiology — the connection between the brain and behavior and thinking.
Click Me!
music: refactor music loading
Refactor music loading to be based off of songs entirely. This reduces efficency but enables some nices fixes, notably:
- Album artists now have basic support [You won't be able to see specific artists, but they won't be fragmented anymore]
- Samsung devices probably shouldn't get confused about artist names anymore, like in #40
This should hopefully be the last time I need to refactor this horrible system. Thank god.
Runtime crash and compilation failure fixes
- y_timers reparse issues. (Timers were called before creation thus throwing warnings in the compiler)
- removed bool tag warnings that would show up in the compiler. (#define FIX_bool_tags 0)
- dialogs that wouldn't show up because of the update of dependencies. (-1 was an invalid dialog ID but before it worked flawlessly for dialogs that didn't have a response. A sincere fuck you to the guy that fixed that. Completely useless..)
- /afactions command.
- /admins cmd dialog wouldn't show up when there was no admins online.
- /skills cmd dialog wouldn't show up when there was no skills available.
- CJ skin after first register than relog. (The reason was that the player_appearance wasn't inserted when player registers to the server)
- Replaced Iter_SafeRemove with Iter_Remove. ('Iter_SafeRemove' is deprecated)
- Account security notifications.
- 'STATUS_ACCESS_VIOLATION' compiler error message. (It was because of the 'va_ShowPlayerDialog' which was implemented in the lastest YSI y_va version and was a duplicate function)
- Added a garage dynsphere instead of a circle, and also added a limitation to world 0. (They would show up in random interiors)
- Vehicle tuning. (1 Mistake in query which saved the cars tuning)
- Fixed the saving of GPCI ID's.
- Fixed the checkcredit format and made a slight edit. (1 parameter was missing)
- Added dependency versions.
feat(persistance): persist IP addresess of disconnected devices
One of the things that was most annoying to me about this system is that when a device disconnected and no longer showed up in the Unifi API, it wouldn't show up in the hostnames anymore. This led to a couple of things - first, it meant that you'd get hostnames not found frequently when you know the device exists, it just went to sleep. Second, you'll have to wait until the next polling round to get the new hosts - even if they normally are given the same IP address.
This fixes that by adding an element of persistence by storing a lastseen and lastseenUnifi time (although the latter isn't really used). If a hostname has different IP addresses, it will use the most recent IP address. If two devices show up with the same IP address, it will use the one that was seen the most recently. This will flush those entries, but it's not that big of a deal.
Right now the entries are persisted until the application restarts. In the future, this should be made so it can bootstrap from a file or the entries time out after some sufficiently long time.
DCO-1.1 Signed-off-by: Patrick Wagstrom [email protected]
Add colorscheme support
Keeps it simple, includes headers from config.h. Fuck your dynamic colorscheme switching
0.0.6 version of app is here! What does it mean? -night theme developing is complete. -support of Semesters from API -but I don't know how to define amount of days to vacation. There can be weird solutions kinda 12-sized array of days in every month in year and array with nearest leap years... -into textAmountDaysToVacation I've put a text with a date of semester's beginning and ending. -I've added dialog_change_school_and_grade.xml that shows warning if user wants to change school and grade. -I've created beautiful layout for choosing grade and subgroup with NumberPickers for grade's letter and number. -Actually there can be some errors, but I've done APK to test it among my counterparts.
The app release of first production version into GooglePlay might be very soon!
@noteed
This fixes the broken tests: for users. I'm sorry but I had not assumed that the IDs were being stored in newtypes with the prefixes.
This broke all tests and needed to be fixed.
This commit /should/ be able to fix them using the newtype machinery.
--
The earlier ID prefixing introduced some data redundancy.
For example:
UserId "USER-1"
is not very useful: it should not contain the prefix USER- inside
the newtype value, since the newtype guarantees that the Text is a
UserId. So we were storing redundant data.
Instead, the UserId, should be stored as UserId "1" and only
rendered as USER-1 etc. when serialising (show, toJSON etc.) and
vice versa for parsing.
--
I'd love to have fixed this, but I ran out of time (and we had to leave for the evening to friends.
My apologies for that. I'll try to finish this the coming week or the next weekend.
editing xml is fun with proper tool aka fuck you json
updated the readme
Some of you may be wondering, why remove the word "hacking?" Unfortunately most people associate the word with rather negative connotations. ABiT is not meant to facilitate or condone hacking for cheating. I think the word "tweaking" describes the spirit much better - it's for fixing annoying things and jank in the game. Of course, that doesn't mean it cannot be used for cheating, but if you do, I'll be sad. Very sad. Not mad, just disappointed. And remember what Conductor says. "No cheatin'! Don't be a stinker."
On the other hand, you can cheat with regular in-game mods, though your ability to do so is somewhat hindered; but not impossible. So really, I'm just adding value to them.
i fucking suck i feel like i understand this shit less now
Bug 5055: FATAL FwdState::noteDestinationsEnd exception: opening (#877)
The bug was caused by commit 25b0ce4. Other known symptoms are:
assertion failed: store.cc:1793: "isEmpty()"
assertion failed: FwdState.cc:501: "serverConnection() == conn"
assertion failed: FwdState.cc:1037: "!opening()"
This change has several overlapping parts. Unfortunately, merging individual parts is both difficult and likely to cause crashes.
FwdState used to check serverConn to decide whether to open a connection to forward the request. Since commit 25b0ce4, a nil serverConn pointer no longer implies that a new connection should be opened: FwdState helper jobs may already be working on preparing an existing open connection (e.g., sending a CONNECT request or negotiating encryption).
Bad serverConn checks in both FwdState::noteDestination() and FwdState::noteDestinationsEnd() methods led to extra connectStart() calls creating two conflicting concurrent helper jobs.
To fix this, we replaced direct serverConn inspection with a usingDestination() call which also checks whether we are waiting for a helper job. Testing that fix exposed another set of bugs: The helper job pointers or in-job connections were left stale/set after forwarding failures. The changes described below addressed most of those problems.
A proper fix for Bug 5055 required answering a difficult question: When should a dying job call its callbacks? We only found one answer which required cooperation from the job creator and led to the following rules:
-
AsyncJob destructors must not call any callbacks.
-
AsyncJob::swanSong() is responsible for async-calling any remaining (i.e. set, uncalled, and uncancelled) callbacks.
-
AsyncJob::swanSong() is called (only) for started jobs.
-
AsyncJob destructing sequence should validate that no callbacks remain uncalled for started jobs.
... where an AsyncJob x is considered "started" if AsyncJob::Start(x) has returned without throwing.
A new JobWait class helps job creators follow these rules while keeping track on in-progress helper jobs and killing no-longer-needed helpers.
Also fixed very similar bugs in tunnel.cc code.
-
Many ConnOpener users are written to keep a ConnectionPointer to the destination given to ConnOpener. This means that their connection magically opens when ConnOpener successfully connects, before ConnOpener has a chance to notify the user about the changes. Having multiple concurrent connection owners is always dangerous, and the user cannot even have a close handler registered for its now-open connection. When something happens to ConnOpener or its answer, the user job may be in trouble. Now, ConnOpener callers no longer pass Connection objects they own, cloning them as needed. That adjustment required adjustment 2:
-
Refactored ConnOpener users to stop assuming that the answer contains a pointer to their connection object. After adjustment 1 above, it does not. HappyConnOpener relied on that assumption quite a bit so we had to refactor to use two custom callback methods instead of one with a complicated if-statement distinguishing prime from spare attempts. This refactoring is an overall improvement because it simplifies the code. Other ConnOpener users just needed to remove a few no longer valid paranoid assertions/Musts.
-
ConnOpener users were forced to remember to close params.conn when processing negative answers. Some, naturally, forgot, triggering warnings about orphaned connections (e.g., Ident and TcpLogger). ConnOpener now closes its open connection before sending a negative answer.
-
ConnOpener would trigger orphan connection warnings if the job ended after opening the connection but without supplying the connection to the requestor (e.g., because the requestor has gone away). Now, ConnOpener explicitly closes its open connection if it has not been sent to the requestor.
Also fixed Comm::ConnOpener::cleanFd() debugging that was incorrectly saying that the method closes the temporary descriptor.
Also fixed ConnOpener callback's syncWithComm(): The stale CommConnectCbParams override was testing unused (i.e. always negative) CommConnectCbParams::fd and was trying to cancel the callback that most (possibly all) recipients rely on: ConnOpener users expect a negative answer rather than no answer at all.
Also, after comparing the needs of two old/existing and a temporary added ("clone everything") Connection cloning method callers, we decided there is no need to maintain three different methods. All existing callers should be fine with a single method because none of them suffers from "extra" copying of members that others need. Right now, the new cloneProfile() method copies everything except FD and a few special-purpose members (with documented reasons for not copying).
Also added Comm::Connection::cloneDestinationDetails() debugging to simplify tracking dependencies between half-baked Connection objects carrying destination/flags/other metadata and open Connection objects created by ConnOpener using that metadata (which are later delivered to ConnOpener users and, in some cases, replace those half-baked connections mentioned earlier. Long-term, we need to find a better way to express these and other Connection states/stages than comments and debugging messages.
We improved many closure callbacks to make sure (to the extent possible) that Connection and other objects are in sync with Comm. There are lots of small bugs, inconsistencies, and other problems in Connection closure handlers. It is not clear whether any of those problems could result in serious runtime errors or leaks. In theory, the rest of the code could neutralize their negative side effects. However, even in that case, it would only be a matter of time before the next bug bites us due to stale Connection::fd and such. These changes themselves carry elevated risk, but they get us closer to reliable code as far as Connection maintenance is concerned. Without them, we will keep chasing deadly side effects of poorly implemented closure callbacks.
Long-term, all these manual efforts to keep things in sync should become unnecessary with the introduction of appropriate Connection ownership APIs that automatically maintain the corresponding environments (TODO).
Improved Security::PeerConnector::serverConn and Http::Tunneler::connection management, especially when sending negative answers. When sending a negative answer, we would set answer().conn to an open connection, async-send that answer, and then hurry to close the connection using our pointer to the shared Connection object. If everything went according to the plan, the recipient would get a non-nil but closed Connection object. Now, a negative answer simply means no connection at all. Same for a tunneled answer.
Refactored ICAP connection-establishing code to to delay Connection ownership until the ICAP connection is fully ready. This change addresses primary Connection ownership concerns (as they apply to this ICAP code) except orphaning of the temporary Connection object by helper job start exceptions (now an explicit XXX). For example, the transaction no longer shares a Connection object with ConnOpener and IcapPeerConnector jobs.
Probably fixed a bug where PeerConnector::negotiate() assumed that sslFinalized() does not return true after callBack(). It may (e.g., when CertValidationHelper::Submit() throws). Same for PeekingPeerConnector::checkForPeekAndSpliceMatched().
Fixed FwdState::advanceDestination() bug that did not save ERR_GATEWAY_FAILURE details and "lost" the address of that failed destination, making it unavailable to future retries (if any).
Polished PeerPoolMgr, Ident, and Gopher code to be able to fix similar job callback and connection management issues.
Polished AsyncJob::Start() API. Start() used to return a job pointer, but that was a bad idea:
-
It implies that a failed Start() will return a nil pointer, and that the caller should check the result. Neither is true.
-
It encourages callers to dereference the returned pointer to further adjust the job. That technically works (today) but violates the rules of communicating with an async job. The Start() method is the boundary after which the job is deemed asynchronous.
Also removed old "and wait for..." post-Start() comments because the code itself became clear enough, and those comments were becoming increasingly stale (because they duplicated the callback names above them).
Fix Tunneler and PeerConnector handling of last-resort callback requirements. Events like handleStopRequest() and callException() stop the job but should not be reported as a BUG (e.g., it would be up to the callException() to decide how to report the caught exception). There might (or there will) be other, similar cases where the job is stopped prematurely for some non-BUG reason beyond swanSong() knowledge. The existence of non-bug cases does not mean there could be no bugs worth reporting here, but until they can be identified more reliably than all these benign/irrelevant cases, reporting no BUGs is a (much) lesser evil.
TODO: Revise AsyncJob::doneAll(). Many of its overrides are written to check for both positive (i.e. mission accomplished) and negative (i.e. mission cancelled or cannot be accomplished) conditions, but the latter is usually unnecessary, especially after we added handleStopRequest() API to properly support external job cancellation events. Many doneAll() overrides can probably be greatly simplified.
Update base for Update on "Implement SymBool"
We have known for a while that we should in principle support SymBool as a separate concept from SymInt and SymFloat ( in particular, every distinct numeric type should get its own API). However, recent work with unbacked SymInts in, e.g., pytorch/pytorch#90985 have made this a priority to implement. The essential problem is that our logic for computing the contiguity of tensors performs branches on the passed in input sizes, and this causes us to require guards when constructing tensors from unbacked SymInts. Morally, this should not be a big deal because, we only really care about the regular (non-channels-last) contiguity of the tensor, which should be guaranteed since most people aren't calling empty_strided on the tensor, however, because we store a bool (not a SymBool, prior to this PR it doesn't exist) on TensorImpl, we are forced to immediately compute these values, even if the value ends up not being used at all. In particular, even when a user allocates a contiguous tensor, we still must compute channels-last contiguity (as some contiguous tensors are also channels-last contiguous, but others are not.)
This PR implements SymBool, and makes TensorImpl use SymBool to store the contiguity information in ExtraMeta. There are a number of knock on effects, which I now discuss below.
- I introduce a new C++ type SymBool, analogous to SymInt and SymFloat. This type supports logical and, logical or and logical negation. I support the bitwise operations on this class (but not the conventional logic operators) to make it clear that logical operations on SymBool are NOT short-circuiting. I also, for now, do NOT support implicit conversion of SymBool to bool (creating a guard in this case). This does matter too much in practice, as in this PR I did not modify the equality operations (e.g.,
==on SymInt) to return SymBool, so all preexisting implicit guards did not need to be changed. I also introduced symbolic comparison functionssym_eq, etc. on SymInt to make it possible to create SymBool. The current implementation of comparison functions makes it unfortunately easy to accidentally introduce guards when you do not mean to (as boths0 == s1ands0.sym_eq(s1)are valid spellings of equality operation); in the short term, I intend to prevent excess guarding in this situation by unit testing; in the long term making the equality operators return SymBool is probably the correct fix. - I modify TensorImpl to store SymBool for the
is_contiguousfields and friends onExtraMeta. In practice, this essentially meant reverting most of the changes from pytorch/pytorch#85936 . In particular, the fields on ExtraMeta are no longer strongly typed; at the time I was particularly concerned about the giant lambda I was using as the setter getting a desynchronized argument order, but now that I have individual setters for each field the only "big list" of boolean arguments is in the constructor of ExtraMeta, which seems like an acceptable risk. The semantics of TensorImpl are now that we guard only when you actually attempt to access the contiguity of the tensor via, e.g.,is_contiguous. By in large, the contiguity calculation in the implementations now needs to be duplicated (as the boolean version can short circuit, but the SymBool version cannot); you should carefully review the duplicate new implementations. I typically use theidentitytemplate to disambiguate which version of the function I need, and rely on overloading to allow for implementation sharing. The changes to thecompute_functions are particularly interesting; for most of the functions, I preserved their original non-symbolic implementation, and then introduce a new symbolic implementation that is branch-less (making use of our new SymBool operations). However,compute_non_overlapping_and_denseis special, see next bullet. - While the contiguity calculations are relatively easy to write in a branch-free way,
compute_non_overlapping_and_denseis not: it involves a sort on the strides. While in principle we can still make it go through by using a data oblivious sorting network, this seems like too much complication for a field that is likely never used (because typically, it will be obvious that a tensor is non overlapping and dense, because the tensor is contiguous.) So we take a different approach: instead of trying to trace through the logic computation of non-overlapping and dense, we instead introduce a new opaque operator IsNonOverlappingAndDenseIndicator which represents all of the compute that would have been done here. This function returns an integer 0 ifis_non_overlapping_and_densewould have returnedFalse, and an integer 1 otherwise, for technical reasons (Sympy does not easily allow defining custom functions that return booleans). The function itself only knows how to evaluate itself if all of its arguments are integers; otherwise it is left unevaluated. This means we can always guard on it (assize_hintwill always be able to evaluate through it), but otherwise its insides are left a black box. We typically do NOT expect this custom function to show up in actual boolean expressions, because we will typically shortcut it due to the tensor being contiguous. It's possible we should apply this treatment to all of the othercompute_operations, more investigation necessary. As a technical note, because this operator takes a pair of a list of SymInts, we need to support convertingArrayRef<SymNode>to Python, and I also unpack the pair of lists into a single list because I don't know if Sympy operations can actually validly take lists of Sympy expressions as inputs. See for example_make_node_sizes_strides - On the Python side, we also introduce a SymBool class, and update SymNode to track bool as a valid pytype. There is some subtlety here: bool is a subclass of int, so one has to be careful about
isinstancechecks (in fact, in most cases I replacedisinstance(x, int)withtype(x) is intfor expressly this reason.) Additionally, unlike, C++, I do NOT define bitwise inverse on SymBool, because it does not do the correct thing when run on booleans, e.g.,~Trueis-2. (For that matter, they don't do the right thing in C++ either, but at least in principle the compiler can warn you about it with-Wbool-operation, and so the rule is simple in C++; only use logical operations if the types are statically known to be SymBool). Alas, logical negation is not overrideable, so we have to introducesym_notwhich must be used in place ofnotwhenever a SymBool can turn up. To avoid confusion with__not__which may imply thatoperators.__not__might be acceptable to use (it isn't), our magic method is called__sym_not__. The other bitwise operators&and|do the right thing with booleans and are acceptable to use. - There is some annoyance working with booleans in Sympy. Unlike int and float, booleans live in their own algebra and they support less operations than regular numbers. In particular,
sympy.expanddoes not work on them. To get around this, I introducesafe_expandwhich only calls expand on operations which are known to be expandable.
TODO: this PR appears to greatly regress performance of symbolic reasoning. In particular, python test/functorch/test_aotdispatch.py -k max_pool2d performs really poorly with these changes. Need to investigate.
Signed-off-by: Edward Z. Yang <ezyangmeta.com>
[ghstack-poisoned]
0.13.0
- added
Tierenum - changed a lot of unsigned ints to signed ones because apparrently the API likes to return stupid values
- changed
map_nameonMapto an Option because fuck you that's why
Update base for Update on "Implement SymBool"
We have known for a while that we should in principle support SymBool as a separate concept from SymInt and SymFloat ( in particular, every distinct numeric type should get its own API). However, recent work with unbacked SymInts in, e.g., pytorch/pytorch#90985 have made this a priority to implement. The essential problem is that our logic for computing the contiguity of tensors performs branches on the passed in input sizes, and this causes us to require guards when constructing tensors from unbacked SymInts. Morally, this should not be a big deal because, we only really care about the regular (non-channels-last) contiguity of the tensor, which should be guaranteed since most people aren't calling empty_strided on the tensor, however, because we store a bool (not a SymBool, prior to this PR it doesn't exist) on TensorImpl, we are forced to immediately compute these values, even if the value ends up not being used at all. In particular, even when a user allocates a contiguous tensor, we still must compute channels-last contiguity (as some contiguous tensors are also channels-last contiguous, but others are not.)
This PR implements SymBool, and makes TensorImpl use SymBool to store the contiguity information in ExtraMeta. There are a number of knock on effects, which I now discuss below.
- I introduce a new C++ type SymBool, analogous to SymInt and SymFloat. This type supports logical and, logical or and logical negation. I support the bitwise operations on this class (but not the conventional logic operators) to make it clear that logical operations on SymBool are NOT short-circuiting. I also, for now, do NOT support implicit conversion of SymBool to bool (creating a guard in this case). This does matter too much in practice, as in this PR I did not modify the equality operations (e.g.,
==on SymInt) to return SymBool, so all preexisting implicit guards did not need to be changed. I also introduced symbolic comparison functionssym_eq, etc. on SymInt to make it possible to create SymBool. The current implementation of comparison functions makes it unfortunately easy to accidentally introduce guards when you do not mean to (as boths0 == s1ands0.sym_eq(s1)are valid spellings of equality operation); in the short term, I intend to prevent excess guarding in this situation by unit testing; in the long term making the equality operators return SymBool is probably the correct fix. I modify TensorImpl to store SymBool for theThis appears to cause performance problems, so I am leaving this to an update PR.is_contiguousfields and friends onExtraMeta. In practice, this essentially meant reverting most of the changes from pytorch/pytorch#85936 . In particular, the fields on ExtraMeta are no longer strongly typed; at the time I was particularly concerned about the giant lambda I was using as the setter getting a desynchronized argument order, but now that I have individual setters for each field the only "big list" of boolean arguments is in the constructor of ExtraMeta, which seems like an acceptable risk. The semantics of TensorImpl are now that we guard only when you actually attempt to access the contiguity of the tensor via, e.g.,is_contiguous. By in large, the contiguity calculation in the implementations now needs to be duplicated (as the boolean version can short circuit, but the SymBool version cannot); you should carefully review the duplicate new implementations. I typically use theidentitytemplate to disambiguate which version of the function I need, and rely on overloading to allow for implementation sharing. The changes to thecompute_functions are particularly interesting; for most of the functions, I preserved their original non-symbolic implementation, and then introduce a new symbolic implementation that is branch-less (making use of our new SymBool operations). However,compute_non_overlapping_and_denseis special, see next bullet.- While the contiguity calculations are relatively easy to write in a branch-free way,
compute_non_overlapping_and_denseis not: it involves a sort on the strides. While in principle we can still make it go through by using a data oblivious sorting network, this seems like too much complication for a field that is likely never used (because typically, it will be obvious that a tensor is non overlapping and dense, because the tensor is contiguous.) So we take a different approach: instead of trying to trace through the logic computation of non-overlapping and dense, we instead introduce a new opaque operator IsNonOverlappingAndDenseIndicator which represents all of the compute that would have been done here. This function returns an integer 0 ifis_non_overlapping_and_densewould have returnedFalse, and an integer 1 otherwise, for technical reasons (Sympy does not easily allow defining custom functions that return booleans). The function itself only knows how to evaluate itself if all of its arguments are integers; otherwise it is left unevaluated. This means we can always guard on it (assize_hintwill always be able to evaluate through it), but otherwise its insides are left a black box. We typically do NOT expect this custom function to show up in actual boolean expressions, because we will typically shortcut it due to the tensor being contiguous. It's possible we should apply this treatment to all of the othercompute_operations, more investigation necessary. As a technical note, because this operator takes a pair of a list of SymInts, we need to support convertingArrayRef<SymNode>to Python, and I also unpack the pair of lists into a single list because I don't know if Sympy operations can actually validly take lists of Sympy expressions as inputs. See for example_make_node_sizes_strides - On the Python side, we also introduce a SymBool class, and update SymNode to track bool as a valid pytype. There is some subtlety here: bool is a subclass of int, so one has to be careful about
isinstancechecks (in fact, in most cases I replacedisinstance(x, int)withtype(x) is intfor expressly this reason.) Additionally, unlike, C++, I do NOT define bitwise inverse on SymBool, because it does not do the correct thing when run on booleans, e.g.,~Trueis-2. (For that matter, they don't do the right thing in C++ either, but at least in principle the compiler can warn you about it with-Wbool-operation, and so the rule is simple in C++; only use logical operations if the types are statically known to be SymBool). Alas, logical negation is not overrideable, so we have to introducesym_notwhich must be used in place ofnotwhenever a SymBool can turn up. To avoid confusion with__not__which may imply thatoperators.__not__might be acceptable to use (it isn't), our magic method is called__sym_not__. The other bitwise operators&and|do the right thing with booleans and are acceptable to use. - There is some annoyance working with booleans in Sympy. Unlike int and float, booleans live in their own algebra and they support less operations than regular numbers. In particular,
sympy.expanddoes not work on them. To get around this, I introducesafe_expandwhich only calls expand on operations which are known to be expandable.
TODO: this PR appears to greatly regress performance of symbolic reasoning. In particular, python test/functorch/test_aotdispatch.py -k max_pool2d performs really poorly with these changes. Need to investigate.
Signed-off-by: Edward Z. Yang <ezyangmeta.com>
[ghstack-poisoned]
Unironically removes the atmos and black beret (#72722)
Removes atmos berets
Berets shouldn't be thrown into every job, it's milsim circlejerking
dressup shit that creeps out of our milsim containment jobs (security)
and into other innocent jobs. There is absolutely no reason for this job
to have a beret just straight up. Can we add unique hats to the game,
not the same one recolored every way to Sunday? That's my problem. We
don't have unique clothes, we have a billion types of beret when the
BASE BERET TYPE has IS_PLAYER_COLORABLE_1 so ANYONE can color it. So
again, why do we have the atmos beret? To clog the wardrobe, a vending
machine added specifically because we couldn't stop clogging the
original locker atmos techs spawned in?
The black beret has the same problem: recolored item when you can get the item of any color
🆑 del: Atmospherics beret and black beret /🆑
[ci] noUncheckedIndexedAccess to false stupid mistake I WANT TO DIE I HATE THIS