Skip to content

Latest commit

 

History

History
859 lines (702 loc) · 40.7 KB

2021-01-17.md

File metadata and controls

859 lines (702 loc) · 40.7 KB

< 2021-01-17 >

1,969,338 events, 1,131,024 push events, 1,631,344 commit messages, 111,730,757 characters

Sunday 2021-01-17 00:36:56 by Jean-Paul R. Soucy

New data: 2021-01-16. See data notes for important messages.

Vaccine datasets:

  • 2021-01-11: Our Ontario vaccine dataset has changed. Previously, we used two datasets: the MoH Daily Situation Report (https://www.oha.com/news/updates-on-the-novel-coronavirus), which is released weekdays in the evenings, and the “COVID-19 Vaccine Data in Ontario” dataset (https://data.ontario.ca/dataset/covid-19-vaccine-data-in-ontario), which is released every day in the mornings. Because the Daily Situation Report is released later in the day, it has more up-to-date numbers. However, since it is not available on weekends, this leads to an artificial “dip” in numbers on Saturday and “jump” on Monday due to the transition between data sources. We will now exclusively use the daily “COVID-19 Vaccine Data in Ontario” dataset. Although our numbers will be slightly less timely, the daily values will be consistent. We have replaced our historical dataset with “COVID-19 Vaccine Data in Ontario” as far back as they are available.
  • 2020-12-17: Vaccination data have been added as time series in timeseries_prov and timeseries_hr.
  • 2020-12-15: We have added two vaccine datasets to the repository, vaccine_administration_cumulative.csv and vaccine_distribution_cumulative.csv. These data should be considered preliminary and are subject to change and revision. The format of these new datasets may also change at any time as the data situation evolves.

Upcoming changes (specific dates to be announced soon):

  • The data structure of time series data will change in response to user feedback. This will only consist of adding additional columns to make the data easier to work with. The core columns will remain the same, for now. More details to follow. Initially, the updated dataset will be provided alongside the new dataset. After a time, the new data format will completely replace the old format.

Recent changes:

  • 2021-01-08: The directories cases_extra and mortality_extra have been moved to other/cases_extra and other/mortality_extra.

Revise historical data: cases (MB, ON); mortality (MB).

Note regarding deaths added in QC today: “The data also report 67 new deaths, for a total of 9,005.” We report deaths such that our cumulative regional totals match today’s values. This sometimes results in extra deaths with today’s date when older deaths are removed.

https://www.quebec.ca/en/health/health-issues/a-z/2019-coronavirus/situation-coronavirus-in-quebec/#c47900

Note about SK data: As of 2020-12-14, we are providing a daily version of the official SK dataset that is compatible with the rest of our dataset in the folder official_datasets/sk. See below for information about our regular updates.

SK transitioned to reporting according to a new, expanded set of health regions on 2020-09-14. Unfortunately, the new health regions do not correspond exactly to the old health regions. Additionally, the provided case time series using the new boundaries do not exist for dates earlier than August 4, making providing a time series using the new boundaries impossible.

For now, we are adding new cases according to the list of new cases given in the “highlights” section of the SK government website (https://dashboard.saskatchewan.ca/health-wellness/covid-19/cases). These new cases are roughly grouped according to the old boundaries. However, health region totals were redistributed when the new boundaries were instituted on 2020-09-14, so while our daily case numbers match the numbers given in this section, our cumulative totals do not. We have reached out to the SK government to determine how this issue can be resolved. We will rectify our SK health region time series as soon it becomes possible to do so.


Sunday 2021-01-17 07:08:04 by Koi-3088

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 [email protected] 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


Sunday 2021-01-17 10:04:26 by Antonino Scordino

Create boom.mp4

[Verse 1] I'm a Creeper, Minecraft's Grim Reaper Blowing up blocks like Al-Qaeda I'm not a creature that'll eat ya but I'll leave ya petrified Peter reminds peeps of Minesweeper Clicking on a brick then you die in the deep I'll find your mine, I'm a mind reader Now the mine is mine, it's finders-keepers Oh, hi! I'm a Creeper, so nice, nice to meet ya Is that the time? It's time to leave and tick-tock, tick-tock

[Hook] Boom, boom, boom I can't stop singing this bloody tune, tune, tune It's gonna make my brain go boom, boom, boom I can't stop singing this bloody tune, tune, tune (Pew, pew, pew, pew, pew)

[Verse 2] I do what I wanna, move aside, mama Tick-tick, I'm a suicide bomber I take control then I'm gonna leave a gaping hole, Belladonna That'll take it's toll when I'm on a quest to invade Detonate your soul, fizz like a lemonade then blow So you better stay indoors Or I'll find your mine when you're mining ore You'll be dying, lying in gore Darling, aw! What you crying for? Did somebody break your diamond sword? I'm the volatilest sort, what a violent force That'll frighten Spartans, hark and hear Leonidas talk When he sees me, "Tonight, we dine indoors" [Hook] Boom, boom, boom I can't stop singing this bloody tune, tune, tune It's gonna make my brain go boom, boom, boom I can't stop singing this bloody tune, tune, tune (Boom, ay)

[Verse 3] It's official, a ballistic missile couldn't get this result I blow through stone like a six-foot chisel So you'd better shiver when you hear that sizzle, fo-shizzle Take a listen, it's a premonition of my mission Death by demolition If I don't come home, there's a sign in my kitchen To describe why I'm missing, "Gone fission" White hot raps, I got stacks Sometimes when I die, I drop tracks I got a lot, Ocelot, fight off cats If I'm feeling nice then I might not, blast

[Hook] Boom, boom, boom I can't stop singing this bloody tune, tune, tune It's gonna make my brain go boom, boom, boom I can't stop singing this bloody tune, tune, tune (Boom) [Outro] My hobbies and interests include going boom, boom, boom


Sunday 2021-01-17 10:48:53 by Christian Brauner

BACKPORT: signal: add pidfd_send_signal() syscall

The kill() syscall operates on process identifiers (pid). After a process has exited its pid can be reused by another process. If a caller sends a signal to a reused pid it will end up signaling the wrong process. This issue has often surfaced and there has been a push to address this problem [1].

This patch uses file descriptors (fd) from proc/ as stable handles on struct pid. Even if a pid is recycled the handle will not change. The fd can be used to send signals to the process it refers to. Thus, the new syscall pidfd_send_signal() is introduced to solve this problem. Instead of pids it operates on process fds (pidfd).

/* prototype and argument /* long pidfd_send_signal(int pidfd, int sig, siginfo_t *info, unsigned int flags);

/* syscall number 424 */ The syscall number was chosen to be 424 to align with Arnd's rework in his y2038 to minimize merge conflicts (cf. [25]).

In addition to the pidfd and signal argument it takes an additional siginfo_t and flags argument. If the siginfo_t argument is NULL then pidfd_send_signal() is equivalent to kill(, ). If it is not NULL pidfd_send_signal() is equivalent to rt_sigqueueinfo(). The flags argument is added to allow for future extensions of this syscall. It currently needs to be passed as 0. Failing to do so will cause EINVAL.

/* pidfd_send_signal() replaces multiple pid-based syscalls */ The pidfd_send_signal() syscall currently takes on the job of rt_sigqueueinfo(2) and parts of the functionality of kill(2), Namely, when a positive pid is passed to kill(2). It will however be possible to also replace tgkill(2) and rt_tgsigqueueinfo(2) if this syscall is extended.

/* sending signals to threads (tid) and process groups (pgid) */ Specifically, the pidfd_send_signal() syscall does currently not operate on process groups or threads. This is left for future extensions. In order to extend the syscall to allow sending signal to threads and process groups appropriately named flags (e.g. PIDFD_TYPE_PGID, and PIDFD_TYPE_TID) should be added. This implies that the flags argument will determine what is signaled and not the file descriptor itself. Put in other words, grouping in this api is a property of the flags argument not a property of the file descriptor (cf. [13]). Clarification for this has been requested by Eric (cf. [19]). When appropriate extensions through the flags argument are added then pidfd_send_signal() can additionally replace the part of kill(2) which operates on process groups as well as the tgkill(2) and rt_tgsigqueueinfo(2) syscalls. How such an extension could be implemented has been very roughly sketched in [14], [15], and [16]. However, this should not be taken as a commitment to a particular implementation. There might be better ways to do it. Right now this is intentionally left out to keep this patchset as simple as possible (cf. [4]).

/* naming */ The syscall had various names throughout iterations of this patchset:

  • procfd_signal()
  • procfd_send_signal()
  • taskfd_send_signal() In the last round of reviews it was pointed out that given that if the flags argument decides the scope of the signal instead of different types of fds it might make sense to either settle for "procfd_" or "pidfd_" as prefix. The community was willing to accept either (cf. [17] and [18]). Given that one developer expressed strong preference for the "pidfd_" prefix (cf. [13]) and with other developers less opinionated about the name we should settle for "pidfd_" to avoid further bikeshedding.

The "_send_signal" suffix was chosen to reflect the fact that the syscall takes on the job of multiple syscalls. It is therefore intentional that the name is not reminiscent of neither kill(2) nor rt_sigqueueinfo(2). Not the fomer because it might imply that pidfd_send_signal() is a replacement for kill(2), and not the latter because it is a hassle to remember the correct spelling - especially for non-native speakers - and because it is not descriptive enough of what the syscall actually does. The name "pidfd_send_signal" makes it very clear that its job is to send signals.

/* zombies */ Zombies can be signaled just as any other process. No special error will be reported since a zombie state is an unreliable state (cf. [3]). However, this can be added as an extension through the @flags argument if the need ever arises.

/* cross-namespace signals */ The patch currently enforces that the signaler and signalee either are in the same pid namespace or that the signaler's pid namespace is an ancestor of the signalee's pid namespace. This is done for the sake of simplicity and because it is unclear to what values certain members of struct siginfo_t would need to be set to (cf. [5], [6]).

/* compat syscalls */ It became clear that we would like to avoid adding compat syscalls (cf. [7]). The compat syscall handling is now done in kernel/signal.c itself by adding __copy_siginfo_from_user_generic() which lets us avoid compat syscalls (cf. [8]). It should be noted that the addition of __copy_siginfo_from_user_any() is caused by a bug in the original implementation of rt_sigqueueinfo(2) (cf. 12). With upcoming rework for syscall handling things might improve significantly (cf. [11]) and __copy_siginfo_from_user_any() will not gain any additional callers.

/* testing */ This patch was tested on x64 and x86.

/* userspace usage */ An asciinema recording for the basic functionality can be found under [9]. With this patch a process can be killed via:

#define _GNU_SOURCE #include <errno.h> #include <fcntl.h> #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/types.h> #include <unistd.h>

static inline int do_pidfd_send_signal(int pidfd, int sig, siginfo_t *info, unsigned int flags) { #ifdef __NR_pidfd_send_signal return syscall(__NR_pidfd_send_signal, pidfd, sig, info, flags); #else return -ENOSYS; #endif }

int main(int argc, char *argv[]) { int fd, ret, saved_errno, sig;

     if (argc < 3)
             exit(EXIT_FAILURE);

     fd = open(argv[1], O_DIRECTORY | O_CLOEXEC);
     if (fd < 0) {
             printf("%s - Failed to open \"%s\"\n", strerror(errno), argv[1]);
             exit(EXIT_FAILURE);
     }

     sig = atoi(argv[2]);

     printf("Sending signal %d to process %s\n", sig, argv[1]);
     ret = do_pidfd_send_signal(fd, sig, NULL, 0);

     saved_errno = errno;
     close(fd);
     errno = saved_errno;

     if (ret < 0) {
             printf("%s - Failed to send signal %d to process %s\n",
                    strerror(errno), sig, argv[1]);
             exit(EXIT_FAILURE);
     }

     exit(EXIT_SUCCESS);

}

/* Q&A

  • Given that it seems the same questions get asked again by people who are
  • late to the party it makes sense to add a Q&A section to the commit
  • message so it's hopefully easier to avoid duplicate threads.
  • For the sake of progress please consider these arguments settled unless
  • there is a new point that desperately needs to be addressed. Please make
  • sure to check the links to the threads in this commit message whether
  • this has not already been covered. */ Q-01: (Florian Weimer [20], Andrew Morton [21]) What happens when the target process has exited? A-01: Sending the signal will fail with ESRCH (cf. [22]).

Q-02: (Andrew Morton [21]) Is the task_struct pinned by the fd? A-02: No. A reference to struct pid is kept. struct pid - as far as I understand - was created exactly for the reason to not require to pin struct task_struct (cf. [22]).

Q-03: (Andrew Morton [21]) Does the entire procfs directory remain visible? Just one entry within it? A-03: The same thing that happens right now when you hold a file descriptor to /proc/ open (cf. [22]).

Q-04: (Andrew Morton [21]) Does the pid remain reserved? A-04: No. This patchset guarantees a stable handle not that pids are not recycled (cf. [22]).

Q-05: (Andrew Morton [21]) Do attempts to signal that fd return errors? A-05: See {Q,A}-01.

Q-06: (Andrew Morton [22]) Is there a cleaner way of obtaining the fd? Another syscall perhaps. A-06: Userspace can already trivially retrieve file descriptors from procfs so this is something that we will need to support anyway. Hence, there's no immediate need to add another syscalls just to make pidfd_send_signal() not dependent on the presence of procfs. However, adding a syscalls to get such file descriptors is planned for a future patchset (cf. [22]).

Q-07: (Andrew Morton [21] and others) This fd-for-a-process sounds like a handy thing and people may well think up other uses for it in the future, probably unrelated to signals. Are the code and the interface designed to permit such future applications? A-07: Yes (cf. [22]).

Q-08: (Andrew Morton [21] and others) Now I think about it, why a new syscall? This thing is looking rather like an ioctl? A-08: This has been extensively discussed. It was agreed that a syscall is preferred for a variety or reasons. Here are just a few taken from prior threads. Syscalls are safer than ioctl()s especially when signaling to fds. Processes are a core kernel concept so a syscall seems more appropriate. The layout of the syscall with its four arguments would require the addition of a custom struct for the ioctl() thereby causing at least the same amount or even more complexity for userspace than a simple syscall. The new syscall will replace multiple other pid-based syscalls (see description above). The file-descriptors-for-processes concept introduced with this syscall will be extended with other syscalls in the future. See also [22], [23] and various other threads already linked in here.

Q-09: (Florian Weimer [24]) What happens if you use the new interface with an O_PATH descriptor? A-09: pidfds opened as O_PATH fds cannot be used to send signals to a process (cf. [2]). Signaling processes through pidfds is the equivalent of writing to a file. Thus, this is not an operation that operates "purely at the file descriptor level" as required by the open(2) manpage. See also [4].

/* References */ [1]: https://lore.kernel.org/lkml/[email protected]/ [2]: https://lore.kernel.org/lkml/[email protected]/ [3]: https://lore.kernel.org/lkml/[email protected]/ [4]: https://lore.kernel.org/lkml/[email protected]/ [5]: https://lore.kernel.org/lkml/[email protected]/ [6]: https://lore.kernel.org/lkml/[email protected]/ [7]: https://lore.kernel.org/lkml/[email protected]/ [8]: https://lore.kernel.org/lkml/[email protected]/ [9]: https://asciinema.org/a/IQjuCHew6bnq1cr78yuMv16cy [11]: https://lore.kernel.org/lkml/[email protected]/ [12]: https://lore.kernel.org/lkml/[email protected]/ [13]: https://lore.kernel.org/lkml/[email protected]/ [14]: https://lore.kernel.org/lkml/[email protected]/ [15]: https://lore.kernel.org/lkml/[email protected]/ [16]: https://lore.kernel.org/lkml/[email protected]/ [17]: https://lore.kernel.org/lkml/CAGXu5jL8PciZAXvOvCeCU3wKUEB_dU-O3q0tDw4uB_ojMvDEew@mail.gmail.com/ [18]: https://lore.kernel.org/lkml/[email protected]/ [19]: https://lore.kernel.org/lkml/[email protected]/ [20]: https://lore.kernel.org/lkml/[email protected]/ [21]: https://lore.kernel.org/lkml/[email protected]/ [22]: https://lore.kernel.org/lkml/[email protected]/ [23]: https://lwn.net/Articles/773459/ [24]: https://lore.kernel.org/lkml/[email protected]/ [25]: https://lore.kernel.org/lkml/CAK8P3a0ej9NcJM8wXNPbcGUyOUZYX+VLoDFdbenW3s3114oQZw@mail.gmail.com/

Cc: "Eric W. Biederman" [email protected] Cc: Jann Horn [email protected] Cc: Andy Lutomirsky [email protected] Cc: Andrew Morton [email protected] Cc: Oleg Nesterov [email protected] Cc: Al Viro [email protected] Cc: Florian Weimer [email protected] Signed-off-by: Christian Brauner [email protected] Reviewed-by: Tycho Andersen [email protected] Reviewed-by: Kees Cook [email protected] Reviewed-by: David Howells [email protected] Acked-by: Arnd Bergmann [email protected] Acked-by: Thomas Gleixner [email protected] Acked-by: Serge Hallyn [email protected] Acked-by: Aleksa Sarai [email protected]

(cherry picked from commit 3eb39f47934f9d5a3027fe00d906a45fe3a15fad)

Conflicts: arch/x86/entry/syscalls/syscall_32.tbl - trivial manual merge arch/x86/entry/syscalls/syscall_64.tbl - trivial manual merge include/linux/proc_fs.h - trivial manual merge include/linux/syscalls.h - trivial manual merge include/uapi/asm-generic/unistd.h - trivial manual merge kernel/signal.c - struct kernel_siginfo does not exist in 4.9 kernel/sys_ni.c - cond_syscall is used instead of COND_SYSCALL arch/x86/entry/syscalls/syscall_32.tbl arch/x86/entry/syscalls/syscall_64.tbl

(1. manual merges because of 4.9 differences 2. change prepare_kill_siginfo() to use struct siginfo instead of kernel_siginfo 3. exclude kill() changes to avoid struct kernel_siginfo usage 4. exclude copy_siginfo_from_user_any() to avoid struct kernel_siginfo usage 5. use copy_from_user() instead of copy_siginfo_from_user() in copy_siginfo_from_user_any() 6. replaced COND_SYSCALL with cond_syscall 7. Removed __ia32_sys_pidfd_send_signal in arch/x86/entry/syscalls/syscall_32.tbl. 8. Replaced __x64_sys_pidfd_send_signal with sys_pidfd_send_signal in arch/x86/entry/syscalls/syscall_64.tbl.)

Bug: 135608568 Test: test program using syscall(__NR_pidfd_send_signal,..) to send SIGKILL Change-Id: I00f1c618b2e9dbafae4d4113ad4d8a1a44b6957c Signed-off-by: Suren Baghdasaryan [email protected]


Sunday 2021-01-17 10:50:36 by Ayush Mandowara

feat(vim): move successful experiments to settings

The split movements are fantastic. I've gotten used to them. Hence, keeping the -<h/j/k/l> as my default move betwen splits option. Honestly, I never actually remembered to use the other mappings such as gh, and ended up using anyway. The resize option using +<left/right/up/down> is also convenient enough. Hence, removing the comment about the experiment, and moving to mappings. The words separated by - should be considered as complete words to keeping this in the settings. I think I set the path option for the gF command. Although I don't use the option all that much, still it doesn't hurt to keep that option enabled. nu + rnu combo is good. Maybe need to set a remap for disabling/enabling rnu as sometimes during screensharing it's difficult to communicate the exact line we are discussing.


Sunday 2021-01-17 10:53:07 by Marko Grdinić

"10:30am. Let me chill for a while.

11am. Let me start here.

There is no avoiding this. Let me just start work on the comment. It might take me a day or a few, but it will be done. After that I am will be done with challenging work on the compiler. I will get back to the docs after that.

comments : LineComment option []

It is finally time to make use of this.

For now, let me forget the later phases. Let me just concern myself with the parser.

11:10am.

    | TopInl of Comments * VSCRange * (VSCRange * VarString) * RawExpr * is_top_down: bool
    | TopRecInl of Comments * VSCRange * (VSCRange * VarString) * RawExpr * is_top_down: bool

Ok, I've sprinkled this in all the right places.

The parser is done.

Let me continue going forward.

type TopEnv = {
    nominals_next_tag : int
    nominals_aux : Map<GlobalId, {|name : string; kind : TT|}>
    nominals : Map<GlobalId, {|vars : Var list; body : T|}>
    prototypes_next_tag : int
    prototypes_instances : Map<GlobalId * GlobalId, Constraint Set list>
    prototypes : Map<GlobalId, {|name : string; signature: T|}>
    ty : Map<string,T>
    term : Map<string,T>
    constraints : Map<string,ConstraintOrModule>
    }

term here will have to change so it includes the comments as well.

| TyModule of Map<string, Comments * T>

TyModule as well.

let in_module m a =
    {a with
        ty = Map.add m (TyModule a.ty) Map.empty
        term = Map.add m (TyModule a.term) Map.empty
        constraints = Map.add m (M a.constraints) Map.empty
        }

Argh, no, this is not it.

    | TyModule of Map<string, Comments * T>
    | TyFun of T * T

Instead of the module here, should I attack a comment to the TyFun itself?

    | TyModule of Map<string, T>
    | TyComment of Comments * T
    | TyFun of T * T

How about I go with this?

let rec tt (env : TopEnv) = function
    | TyComment(_,x) | TyMetavar(_,{contents=Some x}) -> tt env x

I'll have to adjust everything, but it will be worth it.

let rec visit_t = function
    | TyMetavar(_,{contents=Some x} & link) -> shorten x link visit_t
    | a -> a

Should I have visit ignore the comments? Hmmm, let me just roll with it like this for now.

Actually, for now let me not even focus on displaying the comments. Let me just add all the machine and make sure that things still work.

            match visit_t a'', visit_t b'' with
            | TyComment(_,a), b | a, TyComment(_,b) -> loop (a,b)

Dealing with these in unification is easy enough.

11:40am. Ok, the compiler builds. Let me try running it. But though I've filled in the inexhuastive cases, TyComments are not being used anywhere, so I expect this will work.

The way I've set things up now would allow local statement to propagate their comment data...

But I've made comment stripping really fast in union, so nevermind that.

Ah, yes. I should not ignore comment in show_t. That is what hover is using to print them.

I'll get to that later. Let me try running it. I just need to make sure that nothing is broken before I proceed.

Server bound to: tcp://*:13805 & tcp://*:13806
Unhandled exception: System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at Spiral.BlockParsing.loop@1180-68(Env s, Int32 line, FSharpList`1 d) in C:\Users\Marko\Source\Repos\The Spiral Language\The Spiral Language 2\BlockParsing.fs:line 1181
   at Spiral.BlockParsing.comments[a](Env s) in C:\Users\Marko\Source\Repos\The
Spiral Language\The Spiral Language 2\BlockParsing.fs:line 1186
   at [email protected](Env d) in C:\Users\Marko\Source\Repos\The Spiral Language\The Spiral Language 2\BlockParsing.fs:line 1208
   at Spiral.BlockParsing.top_inl_or_let(Env d) in C:\Users\Marko\Source\Repos\The Spiral Language\The Spiral Language 2\BlockParsing.fs:line 1208
   at [email protected](Env d) in C:\Users\Marko\Source\Repos\The Spiral Language\The Spiral Language 2\BlockParsing.fs:line 1257
   at [email protected](FSharpFunc`2 a, FSharpFunc`2 b, Env d) in C:\Users\Marko\Source\Repos\The Spiral Language\The Spiral Language 2\BlockParsing.fs:line 1256

I did not expect this, but it is a good thing that I decided to be cautious and did the check.

if line < 0 then

What the hell is this.

let comments (s : Env) =
    let line_near_to = line s
    let rec loop line d =
        if 0 <= line then
            match s.comments.[line] with
            | Some(r,text) -> loop (line-1) (text :: d)
            | _ -> d
        else d
    loop (line_near_to-1) []
    |> String.concat "\n"
    |> fun x -> Ok(x.TrimEnd())

Let me go with this.

11:50am. Let me take a break here. I feel like I will be able to make rapid progress on this now that I've broken the ice.

I'll do the breakfast and chores, and then get back to this and deal with this today. Then I will be free."


Sunday 2021-01-17 13:46:04 by Masahiro Yamada

modpost: file2alias: go back to simple devtable lookup

commit ec91e78d378cc5d4b43805a1227d8e04e5dfa17d upstream.

Commit e49ce14150c6 ("modpost: use linker section to generate table.") was not so cool as we had expected first; it ended up with ugly section hacks when commit dd2a3acaecd7 ("mod/file2alias: make modpost compile on darwin again") came in.

Given a certain degree of unknowledge about the link stage of host programs, I really want to see simple, stupid table lookup so that this works in the same way regardless of the underlying executable format.

Signed-off-by: Masahiro Yamada [email protected] Acked-by: Mathieu Malaterre [email protected] [nc: Omit rpmsg, sdw, fslmc, tbsvc, and typec as they don't exist here Add of to avoid backporting two larger patches] Signed-off-by: Nathan Chancellor [email protected] Signed-off-by: Sasha Levin [email protected]


Sunday 2021-01-17 21:15:16 by wrincewind

updated Soul Gem crafting (#1753)

  • Updated book to match v3.0.4-9.

did a general quality pass, removed extranious $(item) tags where $(l:) tags were already being used, added a page for the explosive charges, added a description of blood transfer to and from the blood altar, added a 2x soulforge template, removed progress bar (for now)

  • added changelog

also added links from the changelog to various relevant pages in the book, and added anchors accordingly.

  • Update manual to 3.0.6-11

updated changelog, added page for Well of Suffering, rewrote entry on Explosive Charges, slightly tweaked the Anointments to better describe how they wear off, added a $(blood) tag to the manual (same colour as $(fire) so we can talk about Blood more dramatically. This is BLOOD magic after all! (Note, make sure this works - the word 'blood' in the Well of Suffering should be red.

  • Update soul_gem.json

to mirror the changes to the hellfire forge. Thanks, Way!


Sunday 2021-01-17 21:27:37 by Tenz1999

Building a MarkovTable with variable key length

As in the previous assignment, for this one you should create a class called MarkovTable with a method called readFile that takes a String as a parameter (indicating the name of a file to be opened) and returns a boolean (which indicates whether or not the attempt to read the file was successful).

This class should have a private member variable of type HashMap<ArrayList, ArrayList>.

You'll notice that the map in this version of the assignment associates an ArrayList to an ArrayList. This is because instead of associating a word with the words that can potentially follow it, you are instead associating a group of one or more words with the words that can potentially follow them. Here is an example where the key length is three:

It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to Heaven, we were all going direct the other way—in short, the period was so far like the present period, that some of its noisiest authorities insisted on its being received, for good or for evil, in the superlative degree of comparison only

Consider the string of words “it was the” (which I’ve bolded). Below is a list of all the words in this paragraph that appear immediately after “it was the”.

[ best, worst, age, age, epoch, epoch, season, season, spring, winter ]

As stated above your key length is 3: you are looking for each individual word that can follow "it was the".

If the key length is 1, the table built should be identical to the table built by your program in the previous assignment in this module. If the key length is two, the value associated with that key is a container containing all possible individual words that can follow each side-by-side pair of words in the sample file. If the key length is three, the value is each individual word that can follow each set of three side-by-side words in the sample file, and so forth.

As in the previous assignment, you should treat the first word in the file as if it followed the last word in the file. For example, if this was your sample text, and if your key length were 2:

one fish two fish red fish blue fish

The key/value pairs in your HashMap would be:

['one fish'] : ['two'] ['fish two'] : ['fish'] ['two fish'] : ['red'] ['fish red'] : ['fish'] ['red fish'] : ['blue'] ['fish blue'] : ['fish'] ['blue fish'] : ['one'] ['fish one'] : ['fish']

(note: this sample text is too short to be good for a markov generator using a key length of 2 -- the important thing to notice about it is the last two entries in the table)

As in the previous example, test your class with this sample file.


< 2021-01-17 >