Skip to content

Latest commit

 

History

History
1102 lines (799 loc) · 59.2 KB

2022-01-06.md

File metadata and controls

1102 lines (799 loc) · 59.2 KB

< 2022-01-06 >

2,252,348 events recorded by gharchive.org of which 2,252,348 were push events containing 4,001,195 commit messages that amount to 221,607,619 characters filtered with words.py@e23d022007... to these 25 messages:

Thursday 2022-01-06 00:07:32 by Alec Goncharow

Add a couple of thin validations to avoid footguns

After spending several hours last week getting tripped up on very silly issues I have decided to add validations that hope to protect myself from bad GLSL uniform alignment and bind groups not being reboud on resize if they rely on resources which get recreated on resize.

The first of which is a much harder thing to validate from my perspective, so in the hopes of not adding too much overhead to playing with the uniforms I have decided to require each to implement an arbitrary trait, AlignedGLSL, that defines the validate_alignment function whenever a uniform is registered. At the moment all these functions do is assert_eq! between a constant value I manually input and the output of std::mem::size_of for each uniform. At the very least, this should keep alignment at my forethought when editing these uniforms and catch most cases of updating the structs without considering alignment. The edge case which could be painful is reworking the struct into a malaligned state but same overall size.

The second validation which is bit more well done in terms of actual validation is for surface_bound bind groups as I call them. As long as I remember to include any new surface_bound bind groups in the relevant bind_group calls there ought to be a very obvious panicking if a resize happens and a previously bound surface_bound_bind_group manages to not get rebound.


Thursday 2022-01-06 00:23:16 by Shane F. Carr

Create notes-2021-09-09.md

2021-09-09 ECMA-402 Meeting

Logistics

Attendees

  • Shane Carr - Google i18n (SFC), Co-Moderator
  • Corey Roy - Salesforce (CJR)
  • Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison
  • Thomas Steiner - Google (TOM)
  • Frank Yung-Fong Tang - Google i18n, V8 (FYT)
  • Long Ho - (LHO)
  • Zibi Braniecki - Mozilla (ZB)
  • Eemeli Aro - Mozilla (EAO)
  • Greg Tatum - Mozilla (GPT)
  • Yusuke Suzuki - Apple (YSZ)
  • Louis-Aimé de Fouquières - Invited Expert (LAF)
  • Richard Gibson - OpenJS Foundation (RGN)
  • Myles C. Maxfield - Apple (MCM)

Standing items

Status Updates

Editor's Update

RGN: No updates.

MessageFormat Working Group

RCA: We are working on a middle-ground data model that I hope will unblock the situation. EAO is focused on it, with Stas, Mihai, etc. EAO also put together an initial spec proposal.

EAO: I put together a spec outline, not a specific proposal. I think we will be able to merge it later this week.

Proposal Status Changes

https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking

FYT: Some more Test262 coverage is done. But we still need help.

RCA: I updated browser compat for locale info, documentation for hour cycle, etc.

FYT: Do we have an instruction guide about how to update MDN?

RCA: The process is moving quickly. It will be easier, though: you can just edit a Markdown file.

Pull Requests

Add changes to Annex A Implementation Dependent Behaviour

tc39/proposal-intl-locale-info#43

FYT: We added some changes to Appendix A. Does this look good? Do we have consensus to report this to TC39?

SFC: +1

RGN: +1

LAF: +1

Conclusion

Approved

Change weekInfo to express non-continouse [sic] weekend

tc39/proposal-intl-locale-info#44

FYT: Some regions have a non-contiguous weekend. This PR changes the data model to reflect that.

LAF: I wonder how this should be understood for all countries. In certain countries, the two "out of business" days may be not contiguous. Should we call it business day and non business day? Because "weekend" might not be the correct terminology.

SFC: Is there precedent in CLDR for using "business day" instead of "weekend"?

EAO: A quick Google search suggests that Brunei calls these days "weekend".

SFC: LAF, please open an issue on the repository to discuss the option name change.

SFC: Do we have consensus on the change?

LAF: +1

SFC: +1

Conclusion

Approved

Proposals and Discussion Topics

CollationsOfLocale() order

tc39/proposal-intl-locale-info#33

SFC: I feel that lists should define their sort order. This is similar to the plural rule strings discussion from a couple of months ago.

ZB: I represent the other side. I think developers should not be depending on the order.

LAF: (inaudible)

RGN: There is guaranteed to be an observable order. The question is whether that order is enforced across implementations, and if so, what should that order be?

FYT: Could we return a Set?

RGN: Sets also have observable order.

SFC: I propose we bring the meta question to TC39-TG1 as a change to the style guide.

LAF: +1 about order issue

FYT: OK

Conclusion

SFC to make a presentation to TC39-TG1 to establish a best practice in the style guide.

Define if "ca" Unicode extensions have an effect on Intl.Locale.prototype.weekInfo

tc39/proposal-intl-locale-info#30

LAF: My opinion about ISO-8601 is that it is not connected to any locale. Something like Gregorian is connected to a locale, and could carry week info. But ISO-8601 is international.

SFC: I think we should consult with CLDR.

FYT: This is about the first day of the week and minimal days in the week, not the weekend days. I personally believe that we shouldn't limit the extension; for example, a subdivision could have legislation to change this info.

LAF: In my opinion, the impact of saying whether Sunday or Monday is the first day of week, or on the minimal days, is to make a "week calendar": a calendar that lays out days in a week, dated by week number. I can imagine that some countries would like to distribute their own calendar, but I feel that there is a need among people to have the same week numbers. I don't know for sure where the correct place for this concept is.

ZB: This is inspired by the mozIntl API. The reason I needed it was for a general calendrical widget, the HTML picker. I think date pickers in general need this, not just calendar layout. I think it is a high-importance API.

SFC: I think the calendar subtag, or other subtags like the subdivision, should be taken into account.

FYT: I think we should take the whole locale to influence the result.

FYT: Do we need to make any changes to the proposal, and if so, what changes are needed?

RCA: No strong opinion on that, but concerned by the possible conflict with Temporal

Conclusion

SFC, FYT, and LAF agree that the whole locale (including extension subtags) should influence the weekInfo. FYT to share these notes with Anba and wait for follow-up.

JS Input Masking 🎭

FYT: Thanks for the discussion. (1) Some parts of what you proposed… if the formats are the same across different regions, it shouldn't be part of Intl. For example, if the ISBN format is the same across regions, it shouldn't be in Intl. (2) Is the name "input masking" correct? (3) A new item to consider is the postcode. That differs a lot around the world. The US has 5-4, India has 6 digits, Canada has special alphabetic rules. (4) It would be good to validate whether a string is a valid input. For example, maybe 13 digits is a valid ISBN, but not 14 digits. (5) A Googler on our team built libphonenumber, and it ended up being their full-time job for a while.

TOM: Postcodes are interesting. For validation, that's interesting and useful. Thanks for confirming that it is useful. I think it would make sense to have it in the proposal.

EAO: (1) Having built a library like this in the past, you start facing the issue of how to report errors on the input. So it becomes error reporting, but you need to do a best effort at the formatting while also reporting errors in a side channel. (2) Formatting while the string is being edited is just really hard; you should just wait until the field loses focus.

TOM: I agree that live updating the field is challenging. What you said about error reporting is interesting. Verification needs a lot of thought. I think it's something most developers probably want.

EAO: The biggest question is, how does the side-channel error reporting happen? Because that's an interesting question for a UI component like this.

TOM: It seems like it could hook into the mechanism for email verification that we already have. And for on-the-fly formatting, hopefully you could write the formatter so that it can listen to whatever event the developer thinks is the right event.

EAO: It's not just about a binary error. It's about providing more context to the error messages.

TOM: I think many things can be done. I'm new to this area, so I don't know the precedent. I'm looking for more experience.

ZB: Thanks TOM for the presentation. I've worked in this area before. I'm excited about the space, and I have a lot of questions. (1) Parsing is hard. There are a lot of questions here. What happens if they write LTR and RTL? What happens if they type in Arabic numerals? What if they use different kinds of separators? You quickly get into an uncanny valley. (2) You should also think about address formatting, which is like postcode and phone number. Where do you stop? (3) International placeholders is an interesting topic. How do you present a placeholder for a phone number? That really depends on the region. (4) I'm not sure that adding ??? is good for the scope of the spec. (5) About whether this belongs in a spec. It seems like a lot of UX teams will want to customize exactly what the output looks like: they agree on most of the format, but want to change a couple things. There's a good question about how much of this is i18n. (6) And finally, and this is the strongest point, if we were to specify what you are specifying, we would need to back it with a strong library. Because speccing it in ECMA-402 doesn't give us everything. So why not start with writing the foundational library, maybe one that can be used in many different programming languages, and then once you have the library, come back to ECMA-402 and ask whether we should bake it into the browser? That can then help us answer questions about whether the payload is sufficiently high such that it makes sense to ship it in the browser. So basically, I think we should start with a library. I think ECMA-402 is likely not the right place to start.

TOM: We could build a library, but we run the risk of making the "15th way of doing things" (in reference to the XKCD comic). Temporal started by making a polyfill, and is now integrating it into the browser. We already have a lot of input masking libraries.

RCA: I think this is really useful. (1) I'm concerned that the scope could be very large. (2) I'm concerned about what ZB said; organizations where I've worked have wanted to have their own way of doing things with slightly different interactions and so on. That formatter could be a custom thing for that institution. (3) Another thing is the interoperability with HTML. You could have an input credit card, the pattern, the validation, etc. (4) Highly interactive input fields could slow performance on low-resource devices.

TOM: For performance, the obvious tweak would be to do validation on the server.

YSZ: I think this is a super important part of the application. (1) Like FYT said, some of this data is not Intl data. (2) Phone validation is very complicated, like ZB said. We need to care about the UI; for example, inputting the credit card should trigger a numeric keyboard rather than an alphabetic keyboard. So it seems like we need . Did you consider starting there?

TOM: I thought about that, and I put it in the explainer as an alternative.

SFC: In order to avoid the "15th standard" issue, you should approach the industry leader in i18n standards, the Unicode Consortium, about making a working group to establish the industry canonical solution. ECMA-402 looks for prior art, and Unicode is the place we point to most often. This is similar in a way to the MessageFormat Working Group, which was chartered to resolve the competing standards for MessageFormat by bringing all the authors together.

TOM: Yeah, reaching out to Unicode and seeing if this has come up before would be a good option. As I've said, I had this in the String prototype, and then realized that this should maybe be Intl. Credit card numbers are generally not Intl, but phone numbers are. So creating that prior art makes sense.

ZB: I had discussed this a few years ago with Unicode. But with what SFC said, where there are multiple competing libraries, it means that we don't know what the answer is yet. Once we put it in ECMA-402, we won't be able to change it. When writing a library, we can make it and discard it with something better later. It makes sense that we need a place to assemble expertise from the many organizations. Maybe Unicode is the place. And only after we have that canonical implementation, we can evaluate whether it fits in ECMA-402.

MCM: The question about new input forms was raised earlier. Did you list use cases where form input types would NOT be sufficient for, where you need the JS APIs?

TOM: In a Node.js server, and you have a CSV file of unformatted phone numbers, you might want to format on the server. So it makes sense to have isomorphic Node and client-side behavior.

MCM: Has Node.js said that they need a standard for this? Aren't there already Node modules for this?

TOM: Deno is an interesting case. They've started implementing Web APIs like fetch. Programmers are used to the way Web APIs work, and they use them in Deno the way they expect them to work.

LookupMatcher should retain Unicode extension keywords in DefaultLocale

tc39/ecma402#608

GPT: Seems reasonable to me.

EAO: +1

CJR: +1

Conclusion

OK to move forward with this change; review the final spec text when ready.

ships the entire payload requirement

tc39/ecma402#588

Conclusion

FYT to follow up with Anba's suggestions on the Intl Enumeration API to harden the locale data consistency.

DateTimeFormat fractionalSecondDigits: conflict between MDN and spec

tc39/ecma402#590

GPT: It seems reasonable to match the Temporal behavior.

SFC: Do we want to add 4-9 now, or wait until Temporal is more stable?

Conclusion

Seems reasonable to move forward with a spec change. Still some open questions from Anba and SFC.

Presumptive incompatible change in future edition erroneuosly listed

tc39/ecma402#583

RGN: The spec version is immutable.

FYT: Is there a way to publish errata?

RGN: I don't think so… I do see some errata on ECMA International, but I don't see references to those errata.

SFC: The PR in question is tc39/ecma402#471. It was merged in January. I don't know why the change to Annex B made it into the edition, but not the normative change to numberformat.html.

FYT: The other issue is that we have long tables in the PDF that get cut off.

RGN: We're trying to raise funding to generate the PDF by a better mechanism.

Conclusion

Ujjwal to investigate.

Accept plural forms of unit in Intl.NumberFormat

tc39/ecma402#564

CJR: If we accept the plurals in RelativeTimeFormat, I can see a case for doing that also in NumberFormat.

SFC: There are basically 3 approaches. (1), we only accept singular units. (2), we accept plural forms for all units… stripping off the "s"? (3), only special-case duration units like days and hours.

EAO: Pluralization for all units is challenging. "inches", "kilometers-per-hour"

CJR: Having listened to your explanation, SFC, I agree with your assessment. Doing it on an ad-hoc basis is leading away from consistency.

RCA: +1 for not allowing plurals.

RGN: I share this opinion. Is there already a reference to CLDR, to prevent this from coming up again?

Conclusion

Stay consistent with CLDR, and add a normative reference to CLDR if there isn't already one.


Thursday 2022-01-06 01:34:57 by 0Tateki0

EverDawn_Tateki_1

<Beginning of development under name: "EverDawn">

This changelog will largely be dealing with fixing issues that occurred due to the branch merge.

[Start of Changes]

Moved Menu Camera up to Y = 200 just to get it out of the way of the gameplay scene. (and out of the river).

Created a new Scene: Title_Scene

The title screen functions as a typical title screen but will likely also have other features that may be needed in case of a damaged download or something of the like. (Creating some sort of method to clear cache for example if there happens to be an issue that prevents the game from booting into the main menu for whatever reason. I've seen it happen in some of the mobile games I play and I'd rather play it safe than sorry to get features like this implemented in case of an issue.) The scene is then intended to be unloaded after the main menu is loaded and other functionality is confirmed to have loaded correctly.

Added an end game/surrender button into InGameScene this just unloads InGameScene by directly loading Main_Menu_Scene

Created End_Game_Canvas in InGameScene to eventually display game results and etc. It should be activated after the game ends. It also has a button to load back into the main menu.

Created EndGame() in GameManager.cs which runs when a player's score reaches 3. It destroys all GameObjects and TowerObjects that the game manager has in its respective lists and removes them from said lists. This is not yet implemented with the timer or if the player's keep dies.

It should then hide the gameplay HUD and display the end of game screen. but man am I having some trouble with object references so this part of the code is currently commented out

Added text to the game queue/loading overlay

Added Pot's meme logo into the project as the title screen as Title_Screen_Background_Moon which has an attached script Moon_Background_Temp_Animator which basically just makes it act like a panorama.

Preemptively changed the Scene_Loader_Unloader script to make it a singleton. This is commented out as other objects that need it don't have the functionality to use it as a singleton yet though. Eventually, this object should be used as a singleton that's instantiated at boot or something, opposed to existing in all scenes independently. It's also a prefab now that is added in all scenes under the "loading" type of empty.

Created a basic singleton type script called Data_Storage that is capable of serializing a file through C#'s built in means. This was more meant as a test to see how C# goes about serializing files and uses a super basic like cookie cutter type method of going about it. All it currently does is create a binary file which stores a list which could theoretically be used to store what cards are selected. There is not currently anything implemented that uses this script.

The bottom menu selection buttons are no longer setup as a toggle group, but are now managed by the UI_Tab_Group and UI_Tab_Button scripts. These scripts should allow for flexible Tab System implementation. I'm to expand the functionality of these scripts in the future (ex: probably also going to add color options eventually).

Added a couple sprites - some jokes, some for the tab system, etc. One is a slightly edited version of one of Noden's concept arts. (Changed to be 16x9 resolution and gave it a transparent background.) I just needed something a little closer to what we'd actually be working with so I can work on adjusting the positioning and stuff of character backgrounds in the future.


Thursday 2022-01-06 02:35:22 by Johnwstump

Began work on displaying a 'Food' 'Joke'

Hooked up the API and the local database and did some work to get the joke to display with a loading icon.

These 'jokes' are really, aggressively awful. I am actually despairing of ever finding anything funny ever again because my synapses have been fried by these terrible jokes.


Thursday 2022-01-06 03:34:46 by mitko1717

added my answers for Follow Up Questions

Follow Up Questions

  1. Explain the flow of data from the store to the UI and back as simply as you can.

i guess store it's just a root data of whole project. we can manipulate, change, update it and everything on the page will rerender depends on state of the store.

  1. How else can we improve the experience of the site? What suggestions can you make to the product team and the development team?

create mobile format

  1. What recommendations can you make to the development team for scalability?

who am i to recommend anything?

  1. What knowledge up front could have helped this go smoother or faster?

i've already worked with redux toolkit store (u can see it an my portfolio), but worked on this project was a bit harder, cause there were two stores and i had to control both of them to render everything correctly

  1. How was it working around these libraries? Anything trip you up?

everything is great. but maybe mobX better. for my opinion.


Thursday 2022-01-06 03:46:51 by Chimmiemdp

FUCK YOU

Changed the file names from "FNF Voicebank" To "Chromatics" Cause that just makes sense lmao, Added some new shit and fixed some broken shit blah blah blah. Complain in the issues section if something's wrong and i'll (maybe) fix it


Thursday 2022-01-06 04:47:26 by Daniel Kish

user removal kinda working i think? i honestly dont remember. pretty sure I can remove the user from the class registrant list but my function to update the registrant count is not working


Thursday 2022-01-06 04:51:32 by brayjamin

Merge pull request #19 from MercerK/bugfix/sql

What's good, I should first mention that I'm not at all knowledgeable on driver-related stuff like this and thus concur that this is indeed black magic lmao

While this seems like a fix for a problem caused by a much larger issue, that issue has been found inherently ambiguous by @hb432 and others. Perhaps in the future we can attempt to patch that, however the severity of this issue is impactful enough that I think it's a good move to merge your pull request right now instead of venturing down that rabbit hole...

I compiled this myself and have confirmed that CoreProtect & other previously affected plugins seem to be working fine now. Thank you!


Thursday 2022-01-06 05:16:39 by Tyler Hoban

this shit is fucking awful, dont fucking commit it to main until fixed

its a rush placeholder


Thursday 2022-01-06 05:58:44 by Jack Papel

Skewers are now functional! + Major refactors

Condiment tags are still kinda fucky wucky

Practically everything is brand new, as if it were from scratch.

Lots of changes. To be honest I've been working on this so long, and I'm tired, and I don't remember everything. But I'll list some: Dev command CondimentItem Idk everything just feels better, less loosey-goosey. Like proper I guess. Hopefully it's easier for you folks to work with.

Alright, Night.


Thursday 2022-01-06 07:20:42 by Koi

Mr. Mime is a thing, unfortunately. Mild clean, some more Cherish set handling attempts. Exclude set MetDate from mystery gifts. Fix daycare enum parsing. Check for no result in case $qc was used or some other weird thing happens. Remove FixOT and TradeCord as routine types (FlexTrade handles both). Try to apply trainer info for Mystery gifts. Re-add fixed met date if not GO origin. Update DenBot distribution data, minor fixes. Fix Yamask-Galar in daycare, some more oopsies. -Add DenBot - a seed lookup and day skipper bot for raids. -Change AutoRoll's behavior to make use of some of DenBot's functionality. Minor clean. Revise TradeCord "traded" check, remove potential user path straggler entries because paranoia, some minor fixes. TradeCord fixes (shocker, I know). Extract Json serializer. Minor clean and fixes. Minor fixes. Fix Milcery when an Alcremie variant is a parent. Update to latest Core and ALM dependencies. Handle non-shiny events in a better way. Work around a race condition? Simplify and de-bugify trade completion check. Fix indexing, improve chance for Melmetal-Gmax because it's nigh impossible to get. Rework TradeCord internals, add new functionality: -Migrate user data from ".txt" files to a serialized Json (migration for a large amount of users will take a few minutes, be patient). -Make TradeCord configurable, add its own settings category. -Add some template events with an optional end timer (YYYY/MM/DD 8PM as an example, though any local time format should work). -Add barebones Pokedex (counter, flavor text). -Can check dex completion by typing $dex, check missing entries by typing $dex missing. -Completing the Pokedex will slightly improve shiny rate. -Can now mass release cherish event Pokemon and shinies ($massrelease shiny/cherish). -Various tweaks, improvements, and bugfixes.

Slightly change FixOT's behavior: -If a shown Pokemon is illegal and an event, attempt to find a match within the MGDB first. -Try to force users to trade away the shown Pokemon, log attempt to change shown Pokemon. Add consideration for easter eggs being enabled in settings, fix Suicune Change species rng for TradeCord, some bugfixes (I really need to rewrite this mess) Add check if we're using ListUtil for Giveaway instead of TradeCord. Amend commit since I'm squashing and force-pushing while bringing the fork in line with the main branch Add Giveaway module to Discord bot (#22)

Thanks, rigrassm. Co-authored-by: Koi-3088 61223145+Koi-3088@users.noreply.github.com Specify USB port instead of adding the first result (can be found via Device Manager). Re-add boolean check because we don't want to fix everything FixOT will attempt to regenerate illegal Pokémon. Apply trash bytes for reasons. Minor TradeCord fixes and adjustments. Minor clean for C#9 Use "GetValidPreEvolutions()" instead of "GetPreEvolutions()". Index forms correctly. Fix the fixed and re-introduced empty daycare index error. an Ultra Ball. Add EvoTree breeding for TradeCord. Remove unnecessary value declarations for pinging on encounter match. Mildly beautify EncounterBot mark output. Integrate Anubis' system update prevention into Soft Reset and Regigigas Encounter Modes. Rename "Regi" Encounter Mode to "Soft Reset". Speed up "A" clicks for Regigigas and Soft Reset modes. Add Mark logging output for EncounterBot. Fix oops (re-order logic, remove unnecessary lines). Add optional species and form specification for $massrelease Use an obscure string splitter because people like symbols in their names. Fix things that broke after rebasing to the latest main repo commit. Use a less unfortunate field name and value splitter...again. Fix Marowak-Alola always generating as an NPC trade. Add filters for "$list " to narrow down results. Fix Cherish Pichu and Octillery Stop making dumb mistakes, me (implying the rest of it isn't a dumb mistake). Can't breed antiques. Use a less unfortunate embed name and value splitter Add Melmetal-Gmax to TradeCord. Add ability to search by caught ball. Have MassRelease ignore events. Add specific regional form breeding. Revise egg rate and egg shiny chance. Have trade evolutions hold an Everstone. Add an extra right click when navigating to settings for AutoRoll. Add reworked encounter/egg/fossil logs. Minor clean. Minor clean. Get rid of EncounterBot, FossilBot, EggFetch text logs until I properly rework them. Break on an empty page due to aggressive rounding Add multi-page lists for Tradecord. More random bugfixes. Fix some bugs before major clean Add Language parameter for TradeCord. Change trainer info input format for TradeCord. Move focus on Showdown set instead of randomizing a pkm file. Allow user to enter whatever they want for $list, handle edge cases like Kommo-o Add "$list all" to show non-duplicate caught species. Automatically remove from favorites if trading or gifting (small QOL thing). Change how favorites are removed from user file. Revert base egg shiny chance nerf. Fix daycare Add favorites command to TradeCord. Slightly nerf eggs. Fix TradeCord list for shinies Add TradeCord (my dumbest and messiest project so far, Archit pls don't hate the mess). Add Showdown output for Star/Square shinies and OTGender. Add optional link code input for FixOT. Change how OTName, TID, SID is displayed. Add Regigigas SR bot. Add SoJ Camp SR bot. Ribbons now work with EggTrade (remove ribbons if egg). Remove EggRoll. Add another filter for FixOT Fix.. FixOT Update offsets for EncounterBot catching. Slightly change StrongSpawn to work with Regi SR and make it its own mode. Make SpinTrade only available for USB-Botbase Update valid eggs for CT winforms: resize icon.ico to fix crash at startup on unix using mono Rework Spin, read initial in-game coordinates in order to correct drift Add TID, SID, Language output for Showdown Remove obsolete OT and Language parsing Very minor clean until I have time for a proper one. Detach controller when stopping USB bot. Actually set LastUsedBall for EncounterBot (missed when bringing in line with main repo) Move extra RaidBot timings following the official commit Remove PKHeX Discord invite from Readme.md

Maybe fewer people will pester devs now about my unofficial fork? Update for latest main repo EncounterBot commits. Update README.md Add back best commit: Red's SpinTrade. Add egg trades, foreign Dittos and OT for Twitch. If ItemMule is enabled, also display the item a user is receiving. Add periodic time sync toggle for all methods of hosting (except for non-soft locked AutoRoll) to (hopefully) prevent den rollover during extended hosts.

Add routine to exit a lobby for SoftLock if no players are ready in time (to preserve soft lock).

Add a routine to recover from disbanded lobbies (when someone disconnects unexpectedly) for SoftLock.

Add a routine to restart game if all else fails and we're stuck in a raid.

Add a routine for adding and deleting friends if we're soft locked and raids go empty.

Slightly reorganize settings, extract methods, minor clean. Don't use such a generic file name for stream assets. Check USB port index for running bots. Should fix adding additional USB bots when no config is saved. Add fixed met date for FixOT. How do I boolean Change airplane mode logic, tweak timings and routine for soft lock lobby exit Rework EggRoll cooldown (static list in favor of a txt file). Start clean up and refactor Add setting to increase delay after pressing "Home" after a date skip. Use USB port index for blocking and sprite pngs if connection type is USB Add option for airplane host (usb-botbase required) Add option to softlock on selected species for AutoRoll Add automatic compatibility for all console languages when date skipping (have to set ConsoleLanguage under ScreenDetection) Attempt to fix multiple USB device add and connect...again Minor clean Fix oops? Handle add/remove of bots Distinguish between multiple USB devices, tweak BotRemoteControl for USB, other various fixes Add SpA modifier for foreign Dittos Add alpha USB-Botbase support Fix DateTime parsing for European format for EggRoll Set fixed EggMetDate and MetDate for EggRoll More FixOT filters Remove Beheeyem. Oops. Split EggRoll into its own routine and trade type, only output "Receiving: Mysterious Egg" if routine is EggRoll, other minor tweaks and fixes Make FixOT its own queue with roles and counts Add a couple more OTs to $fix Parsing for EggRaffle auto-clear and $clearcooldown Adjust timings and split Watt collecting clicks for AutoRoll Fix oops with file attachments for Ditto Further improvements for OT, memes for invalid pokemon (disable EasterEggs) Add spaces, digits for OT Randomize memes, cut down bloat Fix miscellaneous bots after Anubis' recent QOL additions -Ignore events for OT because headache. -Add overlooked "$convert " input for OT. -Move $clearcooldown to SudoModule -Clear timer automatically if NoTrainerFound -More reliable Dittos -Foreign Dittos for $convert -Command to clear cooldown for EggRaffle in case trade gets disconnected -Fix "Trade finished" line to keep result secret -EggRaffle as a toggle, option to specify channels -Seed Check output to both DMs and Channel (apparently some want it) -Randomly generated egg raffle via a "$roll" command with a configurable cooldown -FixAdOT reworked, has its own command "$fix" and no longer overrides $clone -Ball: output for Showdown sets -Fix oversight -Option to output Seed Check results to Discord channel with a User mention -Showdown set output for OT name and eggs -Basic "OT: " option without Showdown set output -Initial $convert support for EggTrade -Egg moves for EggTrade test attempt -Minor update -EggTrade (by nicknaming a Pokémon "Egg" using $trade) -Failsafe for memes if enabled but field left blank or incomplete -Niche breedable Ditto trade mode. Add minimize button EggFetch text logs StrongSpawn mode for EncounterBot Re-add EncounterBot Master Ball catching More parsing for FixAdOTs Park Ball as held item instead of string Actually remove the offset instead of saying I did Initial DLC commit Faster code entry Removed catching for EncounterBot (need a new offset) CloneBot mode to fix Nickname and OT if adverts detected


Thursday 2022-01-06 07:48:04 by Qu Wenruo

btrfs-progs: print-tree: Use BFS as default traversal method

When debugging tree nodes with higher level, default DFS is not that reader friendly:

file tree key (262 ROOT_ITEM 16) node 33800192 level 2 items 4 free 117 generation 16 owner 262 fs uuid 2d66d111-6850-4ca1-ae73-03f50adde41c chunk uuid 11141e63-2534-4d04-a0bd-c0531a8f5b88 key (256 INODE_ITEM 0) block 33771520 gen 15 key (330 EXTENT_DATA 0) block 33325056 gen 11 key (438 EXTENT_DATA 0) block 33652736 gen 15 key (654 EXTENT_DATA 0) block 33644544 gen 15 node 33771520 level 1 items 59 free 62 generation 15 owner 256 fs uuid 2d66d111-6850-4ca1-ae73-03f50adde41c chunk uuid 11141e63-2534-4d04-a0bd-c0531a8f5b88 key (256 INODE_ITEM 0) block 33787904 gen 15 key (256 DIR_ITEM 273597024) block 33124352 gen 9 [...] leaf 33787904 items 30 free space 1868 generation 15 owner 256 fs uuid 2d66d111-6850-4ca1-ae73-03f50adde41c chunk uuid 11141e63-2534-4d04-a0bd-c0531a8f5b88 item 0 key (256 INODE_ITEM 0) itemoff 3835 itemsize 160 generation 6 transid 15 size 12954 nbytes 0 block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0 sequence 528 flags 0x0(none) atime 1565071339.446118888 (2019-08-06 14:02:19) ctime 1565071339.449452222 (2019-08-06 14:02:19) mtime 1565071339.449452222 (2019-08-06 14:02:19) otime 1565071338.89452221 (2019-08-06 14:02:18) item 1 key (256 INODE_REF 256) itemoff 3823 itemsize 12 index 0 namelen 2 name: .. item 2 key (256 DIR_ITEM 2487323) itemoff 3781 itemsize 42 location key (487 INODE_ITEM 0) type FILE transid 7 data_len 0 name_len 12 name: file_reg_115 [...] leaf 33124352 items 31 free space 1873 generation 9 owner 256 [...]

However such DFS will show the leaves before nodes. If tracing things like drop_progress, we want to see nodes first then leaves.

So change default behavior to BFS to life of developers easier.

This affects 'btrfs inspect-internal dump-tree' output, the traversal order can be selected by --dfs or --bfs options.

Signed-off-by: Qu Wenruo wqu@suse.com Signed-off-by: David Sterba dsterba@suse.com


Thursday 2022-01-06 10:07:54 by barade

1.9.7

  • Allow Undead and Night Elf citizens to directly build their goldmines instead of housings.
  • Add missing hero icon for Cenarius.
  • Fix level of Auto Repair ability when constructing a new Power Generator.
  • Fix singleplayer detection for generating savecodes.
  • Hero Mountain Giant is not affected by Improved Mount anymore.
  • Mention Single/Multiplayer in stats multiboard title.
  • Remove Cyclone from Cenarius.
  • Set the level of research Cheap Evolution from a savecode as well.
  • Replace Demon Infernals by creep Infernals for Dark Portal from Archimonde at level 3.
  • Store the hero level in the savecode file name.
  • Add missing hero icons for Admiral Proudmoore.
  • Fix counting sold workers in the stats multiboard.
  • Make walls invulnerable.
  • Use player colors for font in the stats multiboard.
  • Translate tooltips of Summon Lava Spawn into English.
  • Increase range of True Sight from Arcane Observatory.
  • Revise savecode messages and print a message during hero selection.
  • The lowest hero level of playing users will determine the Evolution level of creeps and bosses.
  • Improved Mount research increases the sight range and the cargo slots of mounts.
  • Fix tooltip of Improved Mount research.
  • Add Neutral Goblin Laboratory and Neutral Mercenary Camp to Freelancers to separate upgrades and units from the Hideout.
  • Freelancer AI builds these buildings as well as a Power Generator and uses more upgrades.
  • Give multiple melee bosses orbs, so they can attack air units.
  • Freelancer AI attacks with trained creeps.
  • Give Freelancer AI some start resources.
  • Enable Freelancer research for Freelancer AI.
  • Add missing hero icon of Anasterian Sunstrider.
  • Add hero glow to Anasterian Sunstrider.
  • Add walls and gates to be constructed by female citizens.
  • Add Neutral Citizens (female).
  • Haunted and Entrangled Goldmines train female citizens and pets now.
  • Female Citizens can place Goblin Land Mines now.
  • Add Pick up all Items to the backpack.
  • Refresh backpack on using Demigod cheats.
  • Initial savecode for buildings.

Thursday 2022-01-06 11:50:39 by KAMLESH KUMAR

Problem 2

Problem #https://www.hackerearth.com/practice/algorithms/searching/linear-search/practice-problems/algorithm/rest-in-peace-21-1/ The grandest stage of all, WrestleMania XXX recently happened. And with it, happened one of the biggest heartbreaks for the WWE fans around the world. The Undertaker's undefeated streak was finally over.

Now as an Undertaker fan, you're disappointed, disheartened and shattered to pieces. And Little Jhool doesn't want to upset you in any way possible. (After all you are his only friend, true friend!) Little Jhool knows that you're still sensitive to the loss, so he decides to help you out.

Every time you come across a number, Little Jhool carefully manipulates it. He doesn't want you to face numbers which have "21" as a part of them. Or, in the worst case possible, are divisible by 21.

If you end up facing such a number you feel sad... and no one wants that - because you start chanting "The streak is broken!" , if the number doesn't make you feel sad, you say, "The streak lives still in our heart!"

Help Little Jhool so that he can help you!

Sample Input 3 120 121 231

Sample Output The streak lives still in our heart! The streak is broken! The streak is broken!


Thursday 2022-01-06 13:19:27 by Will Castro

Fix localised gamemodes extending to all game modes (fuck you Fifty)


Thursday 2022-01-06 13:57:02 by Gallyus

1984: Suppressed Bans (#5251)

  • Suppressor Permission Critical fix to ban notes

  • Confirmation alert

  • Allow Temp Bans Relevant terminology changes

  • I totally did not not do this at 3am

  • FUCK I FORGOT TO UPDATE THE UI TGUI SUCKS BUT HOLY SHIT THIS STUFF IS /AWFUL/

  • irc>tgs


Thursday 2022-01-06 14:37:47 by Peter Williams

Actually fix auto-updating

I wasn't super comfortable with the changes to msiexec before and I think that I understand the issues better now. Our release automation was creating MSIs with identical ProductCodes and PackageCodes, which is forbidden for the PackageCode field and carries some semantic implications for the ProductCode. In principle things are more auto-update-friendly if you have continuity in the ProductCode, but it looks like we should change it with every release. That way, the msiexec /i works (while still maintaining some sense of continuity because the packages keep the same UpgradeCode), and we don't run into problems with the installation "source": the upgrades were failing because the installer wants the upgrade package to have been downloaded to the same directory as the package that was used to make the initial install (!!). The docs also say that you can't rename the MSI file within the same ProductCode (!!!), which I want to do for traceability.

Anyway, the newest version of Cranko (0.10.2) will now update these codes when it's setting up for a release, so we can go back to the previous msiexec invocation. I'm also adding arguments to save a log file in the tempdir since that could come in handy for debugging.


Thursday 2022-01-06 15:39:55 by Gustavo Niemeyer

Revert v2 line length change as discussed in #670

It was clearly a mistake to accept the default formatting change in v2, and now there's no ideal choice. Either we revert the change and break some projects twice, or we keep the change and break some projects once. Given the report comes from Kubernetes, which has a relevant community and code size, we'll revert it. At the same time, to simplify the life of those that already started migrating towards the v3 behavior, a new FutureLineWrap function is being introduced to trivially preserve the new behavior where desired.

The v3 branch is not affected by this, and will retain the default non-wrapping behavior. It will also be changed soon to support per arbitrary line-wrapping for individual encoding operations.

Thanks to everyone who offered code and ideas, and apologies for the trouble.


Thursday 2022-01-06 17:24:20 by W. Trevor King

ci-operator/config/openshift/release: Move stable-4.6 to fast

stable-4.6 isn't getting updates since 1, so these jobs were falling behind and not using new, EUS-targeted updates:

$ for CHAN in fast stable eus; do MAX="$(curl -s "https://api.openshift.com/api/upgrades_info/graph?channel=${CHAN}-4.6" | jq -r '.nodes[].version' | sort -V | tail -n1)"; echo "${MAX} ${CHAN}"; done | sort 4.6.48 stable 4.6.52 eus 4.6.52 fast

We want to exercise 4.6.52, not the slowly-rotting-out 4.6.48, so we can ensure we aren't stranding EUS customers, and so we can keep CI humming along if providers make changes that make 4.6.48 less reliable. Bumping to fast will give us the most recent supported release in the channel, in a way that doesn't die when the non-EUS stable stream goes end-of-life.

Generated with:

$ rename 's/stable/supported/g' ci-operator/config/openshift/release/stable-4.6 $ sed -i 's/channel: stable/channel: fast/' ci-operator/config/openshift/release/supported-4.6 $ sed -i 's/from-stable/from-supported/g' ci-operator/config/openshift/release/supported-4.6 $ git add -A ci-operator/config/openshift/release

I expect we want to do this for all 4.7 and later jobs too, but leaving them for a follow-up commit (unless the job also touches 4.6), so we can see how painful the job-renaming is for TestGrid history and other consumers. I've used "supported" in the new job names, so we have a bit of freedom in the future to make channel adjustments without having to keep bumping the job names.


Thursday 2022-01-06 17:27:16 by W. Trevor King

ci-operator/config/openshift/release: Move stable-4.6 to fast

stable-4.6 isn't getting updates since 1, so these jobs were falling behind and not using new, EUS-targeted updates:

$ for CHAN in fast stable eus; do MAX="$(curl -s "https://api.openshift.com/api/upgrades_info/graph?channel=${CHAN}-4.6" | jq -r '.nodes[].version' | sort -V | tail -n1)"; echo "${MAX} ${CHAN}"; done | sort 4.6.48 stable 4.6.52 eus 4.6.52 fast

We want to exercise 4.6.52, not the slowly-rotting-out 4.6.48, so we can ensure we aren't stranding EUS customers, and so we can keep CI humming along if providers make changes that make 4.6.48 less reliable. Bumping to fast will give us the most recent supported release in the channel, in a way that doesn't die when the non-EUS stable stream goes end-of-life.

Generated with:

$ rename 's/stable/supported/g' ci-operator/config/openshift/release/stable-4.6 $ sed -i 's/channel: stable/channel: fast/' ci-operator/config/openshift/release/supported-4.6 $ sed -i 's/from-stable/from-supported/g' ci-operator/config/openshift/release/supported-4.6 $ make jobs $ git add -A ci-operator

I expect we want to do this for all 4.7 and later jobs too, but leaving them for a follow-up commit (unless the job also touches 4.6), so we can see how painful the job-renaming is for TestGrid history and other consumers. I've used "supported" in the new job names, so we have a bit of freedom in the future to make channel adjustments without having to keep bumping the job names.


Thursday 2022-01-06 18:21:14 by W. Trevor King

ci-operator/config/openshift/release: Move stable-4.6 to fast

stable-4.6 isn't getting updates since 1, so these jobs were falling behind and not using new, EUS-targeted updates:

$ for CHAN in fast stable eus; do MAX="$(curl -s "https://api.openshift.com/api/upgrades_info/graph?channel=${CHAN}-4.6" | jq -r '.nodes[].version' | sort -V | tail -n1)"; echo "${MAX} ${CHAN}"; done | sort 4.6.48 stable 4.6.52 eus 4.6.52 fast

We want to exercise 4.6.52, not the slowly-rotting-out 4.6.48, so we can ensure we aren't stranding EUS customers, and so we can keep CI humming along if providers make changes that make 4.6.48 less reliable. Bumping to fast will give us the most recent supported release in the channel, in a way that doesn't die when the non-EUS stable stream goes end-of-life.

Generated with:

$ rename 's/stable/supported/g' ci-operator/config/openshift/release/stable-4.6 $ sed -i 's/channel: stable/channel: fast/' ci-operator/config/openshift/release/supported-4.6 $ sed -i 's/from-stable/from-supported/g' ci-operator/config/openshift/release/supported-4.6 $ make jobs $ sed -i 's/stable-4.6/supported-4.6/g' core-services/release-controller/_releases/.json core-services/release-controller/_releases/priv/.json $ git add -A ci-operator core-services/release-controller/_releases

I expect we want to do this for all 4.7 and later jobs too, but leaving them for a follow-up commit (unless the job also touches 4.6), so we can see how painful the job-renaming is for TestGrid history and other consumers. I've used "supported" in the new job names, so we have a bit of freedom in the future to make channel adjustments without having to keep bumping the job names.


Thursday 2022-01-06 18:42:40 by W. Trevor King

ci-operator/config/openshift/release: Move stable-4.6 to fast

stable-4.6 isn't getting updates since 1, so these jobs were falling behind and not using new, EUS-targeted updates:

$ for CHAN in fast stable eus; do MAX="$(curl -s "https://api.openshift.com/api/upgrades_info/graph?channel=${CHAN}-4.6" | jq -r '.nodes[].version' | sort -V | tail -n1)"; echo "${MAX} ${CHAN}"; done | sort 4.6.48 stable 4.6.52 eus 4.6.52 fast

We want to exercise 4.6.52, not the slowly-rotting-out 4.6.48, so we can ensure we aren't stranding EUS customers, and so we can keep CI humming along if providers make changes that make 4.6.48 less reliable. Bumping to fast will give us the most recent supported release in the channel, in a way that doesn't die when the non-EUS stable stream goes end-of-life.

Generated with:

$ sed -i 's/channel: stable/channel: fast/' ci-operator/config/openshift/release/stable-4.6

I expect we want to do this for all 4.7 and later jobs too, but leaving them for a follow-up commit (unless the job also touches 4.6).

I'd personally like to rename the jobs, because "stable-4.6" in a job name seems like it could be interpreted as "the latest 4.6.z from https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.6" (which it used to be, but with this commit, it's now the latest from fast-4.6). Or folks might think it was the latest 4.6.z from 2, which includes releases which may not even be in candidate-4.6 yet. Something like supported-4.6 or released-4.6 or ga-4.6 in the job name seems like it would be less confusing. But Scott feels like any improvement in job-name readability would be small, and the disruption of folks adapting to a new job-naming convention would be larger, so we're leaving the job names alone. If we change our mind, we can always come back through and rename things in the future.


Thursday 2022-01-06 19:21:55 by Paolo Giannozzi

GTH pseudopotentials have a special treatment, which unfortunately was not implemented in some parts of the code involving stress calculation and maybe other cases as well. For the time being, I have added it to the cpu version (but not in the GPU one, that stops with an error message). For the future: I think that the more special cases we allow, the more we run into trouble. In my opinion, GTH pseudopotentials should be treated on the same footing as other pseudopotentials: computed on an interpolation table and interpolated.

Side remark: there is another special case, spline interpolation (as opposed to the hand-made one). I think there should be just ONE type of interpolation.


Thursday 2022-01-06 20:20:01 by Jason Rhinelander

Use SQLAlchemy for database backend

We're using it fairly minimally: essentially still writing manual queries, but now using SQLAlchemy to handle placeholder binding which is nicer, and portable.

The API now goes like this:

  • db.get_conn() returns a connection from the connection pool; web.appdb, in particular, is a preloaded, app-context connection object that most code uses.

  • web.query() does an SQLAlchemy 'text' query, which is almost like regular prepare+bind+execute, except that it always uses :name for placeholders and binds using name=... keyword arguments. That is, instead of:

    db.execute("SELECT token FROM rooms WHERE id = ?", (123,))
    

    we now do:

    query("SELECT token FROM rooms WHERE id = :id", id=123)
    

    or equivalently:

    db.query(appdb, "SELECT token FROM rooms WHERE id = :id", id=123)
    

    (the latter version is more useful where an app context doesn't exist and you need to pass in some other conn, such as is now done in main).

  • transactions are now controlled with a with appdb.begin_nested(): context, replacing the custom nested tx handler I made for sqlite.

We could start using more advanced SQLAlchemy query composition, but that seems like more of a pain rather than something useful. (I don't want to use SQLAlchemy ORM, because in my experience ORM just gets in the way as soon as you want non-trivial database structure, which we have here).

This will allow us to (easily) add postgresql support. (Other database are probably a no-go: SQLite has long looked up to postgresql for features and syntax and so the two are very similar dialects).


Thursday 2022-01-06 22:38:45 by GoldenAlpharex

Dullahan Partial Refactor: They Work Again Edition (#63696)

So, a few months ago I was like "hmm there's something weird going on with party pods...", which got me looking into important_recursive_hearers or something like that. I spoke about it in the coding channel and Kyler actually fixed it before I did. But I also caught a similar glitch with Dullahans, so I decided to investigate...

Two months later...

I present to you a partial unfuckening of the Dullahans, in that I made them fully functional once again:

They only hear speech through their head (not sounds, sadly, someone else would have to tell me how to do that because I otherwise really wouldn't know how to do it in a sane way), they speak through their head, runechat-included. When you spawn a Dullahan, you're set to look through the Dullahan's eyes (so from their head), and that doesn't reset when you log off and back in, or admin-ghost and come back in your body. When you're looking through your head, your view will no longer be reset to your body upon entering a locker, which is nice to avoid not being blind while looking through your body. Dullahan heads no longer look completely lifeless and without organs. They have eyes that don't look dead and that even match the player's intended eye color. Dullahan can now properly examine things from their head, which was intended and 100% not functional. Dullahan heads now speak with the proper name of their owner, instead of having a random name attached to it at round-start. Dullahan heads are also now properly named too. Dullahans can now properly whisper, sing and do all these funny things that they were unable to do before. Dullahan whispers will now properly respect the range of the whisper. Dullahans can now succumb in hardcrit by whispering, as intended. This potentially fixes other species that worked similarly not being able to succumb, like abductors, although I didn't test if they normally could, I just know they absolutely will be able to now. When switching from Dullahans to a different species, your old head will no longer stay behind. I also added a proc for species to do some code when we get a ckey login in our mob, which could potentially be useful for other stuff in the future, but it was necessary here as the view is reliant on the client, which we want to ensure doesn't get weird view glitches like having their head's vision overlay while actually being centered on their body.

I also made it so say() now takes a range argument, which is 7 by default, just so things that aren't humans can also whisper and do all those kinds of things. Going with that, there's probably a few more things that will be able to be done better thanks to this, although I haven't tested every edge case with this, but I doubt it will make much of a difference in the future.


< 2022-01-06 >