3,002,283 events, 1,329,852 push events, 2,138,824 commit messages, 150,794,684 characters
Fix Memory Issues in Metric Reporter for Classification Tasks over large Label Spaces
Summary: Currently, we store the score for every label for every instance in the epoch for computing soft metrics and for writing these to file as part of the Test workflow. This is horrible when your label space is 10K and you have a large training/validation/test set. Simply using "num_batches_per_epoch" isnt helpful because this is not respected during valaidation or testing anyways. Also it really slows down training.
In this diff I add a is_memory_efficient flag to the Classification Metric Reporter to avoid storing all of this information when we dont really need it. A better solution would be to refactor ALL of the metric reporters and that is beyond the scope of this fix. To be honest, I'm decently happy with this compormise.
Reviewed By: snisarg
Differential Revision: D21006627
fbshipit-source-id: 20ab34ca7b10b96ff982ad8a9fb680f7811b0730
finally fixed the stupid date picker bug HOLY SHIT
Tones down Mekanism (#22)
- Update Mekanism.cfg
why the FUCK did the maker of mekanism make a goddamn bronze, BRONZE sword better than diamond.
WHY DOES ADDING TWO BLACK ROCKS MAKE IT DOUBLE DAMAGE?!?!?
WHAT THE FUCK REEEEEE
This brings everything closer to vanilla, and nerfs the shit out of the armour spawnrate on zombies/skeletons etc because it's a massive pain in the dickhole.
- Update Mekanism.cfg
this is why you don't assume no config changes were madebefore deleting the file.
Reverts Space Suit Heaters (#77)
-
Update README.md
-
Reverts Shitty Spacesuits
-
Fucking conflicts
-
Delete README.md
-
Delete README.md
-
bloody hell trabis
-
Update _spacesuits.dm
Co-authored-by: Mark Suckerberg [email protected]
axed support for most custom weapons
fuck it, we're starting from square one. i felt like starting from scratch with only the ones we use, so yeah.
SUPPORT LIST NOW: Winchester 1894 Automag 44. CZ Evo AN-92 VMP SPX Centerfire Winchester 1894 KS23 AEK 971 CZ Evo Owen Gun
a few other obscure ass optic attachment mods that i can't be bothered to write.
oh yeah, added in a check to change the sg 552's reload timer to sync with its original animations if you have CWA installed. this is currently the only timer change it has. i'm not sure about the other timers which might need the original values ovk set to sync up right.
- disabled murky medic dozer g_patch
docs: update CONTRIBUTING.md
Given our experience today cutting releases of v10 and v9.5.1, we spent
some time looking at the effects of .yarnrc files, dist tags, and the
behavior of yarn version with various different flags:
liferay/liferay-js-themes-toolkit#473
Armed with that knowledge, I think we should make some updates to the documentation here:
-
Make it clear that
yarn changelogmust run from a package directory, not from the top level ("project" is ambiguous; is it the repo, or a package?). -
Drop "project-name" from version number because liferay-changelog-generator will grab it from .yarnrc directly, since:
-
Provide details on version number format for prereleases.
-
Switch a
git add -ufor agit add -p, because it is safer and provides another chance to catch mistakes. -
Document use of
--prepatchand friends: I suggest we make this the "blessed" way to cut prereleases to avoid possible human errors. -
Fix typo ("google" -> "Google")
Note that the recommendation to use requires --prepatch etc and
standardize on a prefix-id of "pre" (ie. making v1.2.3-pre.0) requires
us to set a default --preid in a .yarnrc file. I think that always
using the same "pre" id in this way makes it less likely that we'll
screw up a release, and the cost of losing the distinction between
"alpha", "beta" etc prereleases is a worthwhile sacrifice. We never
really want customers using prereleases anyway; they are almost always
used for internal testing only.
We can do this in a single root-level .yarnrc because yarn will walk up the tree looking for files, merging them. (I tested this).
Docs: https://classic.yarnpkg.com/en/docs/cli/version
requirements: Bump python-social-auth version.
We had a bunch of ugly hacks to monkey patch things due to upstream being temporarily unmaintained and not merging PRs. Now the project is active again and the fixes have been merged and included in the latest version - so we clean up all that code.
Create README.md
PRIVACY POLICY MODEL FOR MOBILE APPLICATIONS This privacy policy governs your use of the software application [Dori 20] (“Application”) for mobile devices that was created by [Meshal AlTamimi]. The Application is [a daily reminder of love]
What information does the Application obtain and how is it used? User Provided Information The Application obtains the information you provide when you download and register the Application. Registration with us is optional. However, please keep in mind that you may not be able to use some of the features offered by the Application unless you register with us.
When you register with us and use the Application, you generally provide (a) your name, email address, age, user name, password and other registration information; (b) transaction-related information, such as when you make purchases, respond to any offers, or download or use applications from us; (c) information you provide us when you contact us for help; (d) credit card information for purchase and use of the Application, and; (e) information you enter into our system when using the Application, such as contact information and project management information. We may also use the information you provided us to contact your from time to time to provide you with important information, required notices and marketing promotions. Automatically Collected Information
In addition, the Application may collect certain information automatically, including, but not limited to, the type of mobile device you use, your mobile devices unique device ID, the IP address of your mobile device, your mobile operating system, the type of mobile Internet browsers you use, and information about the way you use the Application.
Does the Application collect precise real time location information of the device? This Application does not collect precise information about the location of your mobile device.
Do third parties see and/or have access to information obtained by the Application? Only aggregated, anonymized data is periodically transmitted to external services to help us improve the Application and our service. We will share your information with third parties only in the ways that are described in this privacy statement. We may disclose User Provided and Automatically Collected Information: • as required by law, such as to comply with a subpoena, or similar legal process; • when we believe in good faith that disclosure is necessary to protect our rights, protect your safety or the safety of others, investigate fraud, or respond to a government request; • with our trusted services providers who work on our behalf, do not have an independent use of the information we disclose to them, and have agreed to adhere to the rules set forth in this privacy statement. • if [DEVELOPER COMPANY NAME] is involved in a merger, acquisition, or sale of all or a portion of its assets, you will be notified via email and/or a prominent notice on our Web site of any change in ownership or uses of this information, as well as any choices you may have regarding this information.
What are my opt-out rights? You can stop all collection of information by the Application easily by uninstalling the Application. You may use the standard uninstall processes as may be available as part of your mobile device or via the mobile application marketplace or network. You can also request to opt-out via email, at [[email protected]].
Data Retention Policy, Managing Your Information We will retain User Provided data for as long as you use the Application and for a reasonable time thereafter. We will retain Automatically Collected information for up to 24 months and thereafter may store it in aggregate. If you’d like us to delete User Provided Data that you have provided via the Application, please contact us at [email protected] and we will respond in a reasonable time. Please note that some or all of the User Provided Data may be required in order for the Application to function properly.
Children We do not use the Application to knowingly solicit data from or market to children under the age of 13. If a parent or guardian becomes aware that his or her child has provided us with information without their consent, he or she should contact us at [email protected]. We will delete such information from our files within a reasonable time.
Security We are concerned about safeguarding the confidentiality of your information. We provide physical, electronic, and procedural safeguards to protect information we process and maintain. For example, we limit access to this information to authorized employees and contractors who need to know that information in order to operate, develop or improve our Application. Please be aware that, although we endeavor provide reasonable security for information we process and maintain, no security system can prevent all potential security breaches.
Changes This Privacy Policy may be updated from time to time for any reason. We will notify you of any changes to our Privacy Policy by posting the new Privacy Policy here and informing you via email or text message. You are advised to consult this Privacy Policy regularly for any changes, as continued use is deemed approval of all changes. You can check the history of this policy by clicking here.
Your Consent By using the Application, you are consenting to our processing of your information as set forth in this Privacy Policy now and as amended by us. "Processing,” means using cookies on a computer/hand held device or using or touching information in any way, including, but not limited to, collecting, storing, deleting, using, combining and disclosing information, all of which activities will take place in the United States. If you reside outside the United States your information will be transferred, processed and stored there under United States privacy standards.
Contact us If you have any questions regarding privacy while using the Application, or have questions about our practices, please contact us via email at [email protected].
Сделаны замены жанров для Автокорректора: postapocalyptic – на sf_postapocalyptic; Космическая фантастика - на sf_space; sci_economics - на sci_economy; cyberpunk - на sf_cyberpunk; epic-fantasy - на sf_epic; heroic-fantasy - на sf_heroic; fantasy - на sf_fantasy и sf_action; historical-fantasy - на historical_fantasy; historical-fantasy - на historical_fantasy; popadantsy, popadantsy-vo-vremeni - на popadanec; popadantsy-v-magicheskie-miry - на popadanec и sf_fantasy; popadantsy-v-kosmos - на popadanec и sf_space; publicism - на nonf_publicism; fantasy-action - на sf_fantasy; fantasy-erotika - на sf_fantasy и love_sf; thriller_psychology - на thriller; thriller_mystery - на thriller и sf_mystic; sf-space - на sf_space; sf-social - на sf_social; sf-action - на sf_action; sf-heroic - на sf_heroic; sf-history - на sf_history; science-fiction - на sf; sci-fi - на sf; religion_all - sci_religion; ref_all - на ref_encyc; poetry_all - на poetry; paranormal - на sf_mystic; modern-prose - на prose_contemporary; love_conremporary, love_contrmporary - на love_contemporary; love_all - на love; kriminal_detective - на det_crime; ironical-fantasy - на humor_fantasy; humor_all - на humor; detektive - на detective; dark-fantasy - на fantasy; culture_all - на sci_culture; detskaya-literatura - на children; action - на det_action;
lua: change runtime option change behavior
As described in the manpage changes. This makes more sense than the previous approach, where options could "unexpectedly" stick. Although this is still a somewhat arbitrary policy (ask many people and you'd get a number of different expectations on what should happen), I think that it reflects what mpv's builtin stuff does.
All the copying is annoying, but let's just hope nobody is stupid enough to change these properties per video frame or something equally ridiculous.
Dispose of initPatchFile - instantiate patchers per patch: RRR SSS TTT
TTT
@@ -1222,3 +1222,3 @@ def init(self, p_name, p_file, p_sources): self.racesPatched = set()
-
self.id_spells = {}
-
self.id_spells = defaultdict(set)
@@ -1239,4 +1239,3 @@ def scan(self,modFile,record,bashTags): elif u'R.AddSpells' in tags:
-
self.id_spells[record.fid] = curSpells | \ -
self.id_spells.get(record.fid, set())
-
self.id_spells[record.fid] |= curSpells
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.
Other pros:
- more straightforward - new patch new patchers
- will move all config phase 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)
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]
soc: qcom: rpmh-rsc: Caller handles tcs_invalidate() exclusivity
Auditing tcs_invalidate() made me worried. Specifically I saw that it used spin_lock(), not spin_lock_irqsave(). That always worries me unless I can trace for sure that I'm in the interrupt handler or that someone else already disabled interrupts.
Looking more at it, there is actually no reason for these locks anyway. Specifically the only reason you'd ever call rpmh_rsc_invalidate() is if you cared that the sleep/wake TCSes were empty. That means that they need to continue to be empty even after rpmh_rsc_invalidate() returns. The only way that can happen is if the caller already has done something to keep all other RPMH users out. It should be noted that even though the caller is only worried about making sleep/wake TCSes empty, they also need to worry about stopping active-only transfers if they need to handle the case where active-only transfers might borrow the wake TCS.
At the moment rpmh_rsc_invalidate() is only called in PM code from the last CPU. If that later changes the caller will still need to solve the above problems themselves, so these locks will never be useful.
Continuing to audit tcs_invalidate(), I found a bug. The function didn't properly check for a borrowed TCS if we hadn't recently written anything into the TCS. Specifically, if we've never written to the WAKE_TCS (or we've flushed it recently) then tcs->slots is empty. We'll early-out and we'll never call tcs_is_free().
I thought about fixing this bug by either deleting the early check for bitmap_empty() or possibly only doing it if we knew we weren't on a TCS that could be borrowed. However, I think it's better to just delete the checks.
As argued above it's up to the caller to make sure that all other users of RPMH are quiet before tcs_invalidate() is called. Since callers need to handle the zero-active-TCS case anyway that means they need to make sure that the active-only transfers are quiet before calling too. The one way tcs_invalidate() gets called today is through rpmh_rsc_cpu_pm_callback() which calls rpmh_rsc_ctrlr_is_busy() to handle this. When we have another path to get to tcs_invalidate() it will also need to come up with something similar and it won't need this extra check either. If we later find some code path that actually needs this check back in (and somehow manages to be race free) we can always add it back in.
Signed-off-by: Douglas Anderson [email protected] Reviewed-by: Maulik Shah [email protected] Reviewed-by: Stephen Boyd [email protected] Tested-by: Maulik Shah [email protected] Link: https://lore.kernel.org/r/20200413100321.v4.9.I07c1f70e0e8f2dc0004bd38970b4e258acdc773e@changeid Signed-off-by: Bjorn Andersson [email protected]
Refactor build system, remove hvt compile-time specialization
This is a large change, and the majority of it is effectively a full re-write of the build system. The actual removal of hvt compile-time specialization is fairly straightforward.
User-visible changes:
- 'configure.sh' now needs to be run manually before running 'make', this is consistent with POLA.
- conversely, 'make clean' no longer cleans Makeconf. Use 'distclean' or 'clobber' for that.
- 'configure.sh' will now print the targets that can (will) be built on this system. The strategy is still "build everything we can", however I have disabled Genode on all systems except Linux due to toolchain issues.
- You can now build a subset of targets from the top-level 'make', by specifying 'CONFIG_XXX=' (disable) or 'CONFIG_XXX=1' (enable) either on the command line, or editing the generated Makeconf.
- Makefiles use silent rules by default. To get the old verbose ones back, use 'make V=1'.
- The 'solo5-hvt' tender is no longer "specialized" to the unikernel. We build two tenders, 'solo5-hvt' with all non-debug modules configured and 'solo5-hvt-debug' with additional debug modules (gdb, dumpcore where available).
- 'solo5-hvt-configure' is kept around for now for backward compatibility with OPAM/MirageOS but is essentially a NOP.
Developer-visible changes:
- The build system now has proper support for auto-generation of dependencies. This means you can safely edit source files, run make and be sure you will get a complete incremental build.
- Makefiles have been refactored to use common best practices, remove repetition, consistent variable names and clear interfaces between configure.sh/Makeconf/Makefiles, all the while keeping them simple enough to understand for me on a Monday morning before coffee. I.e. limit use of macros, eval, etc.
- hvt tender modules are no longer defined by compile-time flags, instead a dynamic array is placed into a special ELF section (.modules). This means that a hvt tender binary can be combined from an arbitrary set of hvt_module_XXX object files, which is the right way to do things going forward and also simplifies the build system (not needing to build multiple targets from the same set of sources).
Shortcomings / TODOs:
- Dependency files (*.d) are stored in-tree. I spent several days on trying to figure out how to get them to work out of tree, but in combination with the non-recursive use of subdirectories in 'bindings' I could not figure out the required Makefile magic.
- HVT_DROP_PRIVILEGES=0 is non-functional with the new modules arrangement, but needs a re-design anyway.
Other changes included as part of this PR:
- Revert privilege dropping on FreeBSD (see discussion in #282).
- The build system changes effectively implement option 1 in #292, i.e. on x86_64 -m no-red-zone is only used for bindings, not for application code.
- tests/tests.bats has been refactored for DRY as it was getting totally unmaintainable.
style: Remove layout.css.webkit-appearance.enabled.
I don't think we want to keep the ugly widget hacks forever. Let me know if you'd rather keep the property behind a pref but I don't think there's a point in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
TripleKarel.py now will paint the outside of any of the buildings given in the worlds folder that relate to the TripleKarel.py file. This is cool. It is so interesting learning Python and Karel, and I can tell that my background in JavaScript is making it less strenuous of a learning experience, but it is still challenging. Honestly, I wish I had learned Karel before JavaScript just because of the limited features to the language, it is naturally less of a learning curve while still introducing you to key concepts found in other languages.
Adding Autopilot to HoloLens Insider Preview page
@scooley Since you drove the work / @Teresa-Motiv Since you wrote up the Autopilot doc Can one of you take a look at this for review and then signoff if it's good?
Since the autopilot doc went live (yay!), I was considering adding more details onto the HoloLens Release preview notes. I was thinking mostly to update the email to instead go to the akams link we have there. As well as a small action about autopilot taken directly from the top of the autopilot page.
I remember at some point someone being wary about having autopilot be a strongly featured on the Insider page because they were worried that everyone would think they could magically use it once they updated. This seemed odd to me, but now that the page is an very strong resource on setting it up and requirements I think it merits me adding it in. Unless anyone has any objections.
FYI @yannisle
Holy shit the way characters were implemented is stupid Trying to clean up that mess
fuck you for making me do all this for a large file
Cognitive behavioral therapy (CBT) is a psycho-social intervention that aims to improve mental health. CBT focuses on challenging and changing unhelpful cognitive distortions (e.g. thoughts, beliefs, and attitudes) and behaviors, improving emotional regulation, and the development of personal coping strategies that target solving current problems. Originally, it was designed to treat depression, but its uses have been expanded to include treatment of a number of mental health conditions, including anxiety. CBT includes a number of cognitive or behaviour psychotherapies that treat defined psychopathologies using evidence-based techniques and strategies.
add some more artifact names
an athame engraved with mystical runes [magicbane, modified from "runed athame"] a golden curved sword with a hydra-head hilt [y'ha-talla] a golden stiletto inlaid with delicate filigree [kingslayer, also made it gold for coolness/niche holy] an iron rapier with buttons on the haft [rod of lordly might] a lance with a grail on the hilt [rhon] a long sword that emanates soft music [singing sword] a massive war hammer embossed with a lightning bolt [mjollnir] a metallic bloodstained chain bullwhip [vampire killer] a metallic three-pronged long sword [tobiume] a ram-headed mace [rod of the ram] a samurai sword with a chrysanthemum on the hilt [kiku] a shell wave-etched trident [nodens, also made it shell] a silver polished long sword [mirror brand] a silver saber decorated with amber swirls [grayswandir] a silver snow-colored samurai sword [sode] a silver wolf-hilted saber [werebane] a turquoise scaled bullwhip [xiuhcoatl, also made it dragonhide] a worn axe labeled as belonging to 'Jack' [giantslayer] a leather gorgon-emblemed round shield [aegis] a rainbow-glinting sparkling white gem [arkenstone]