2,390,996 events, 1,188,827 push events, 1,914,884 commit messages, 158,659,093 characters
Update MELEE.dec
Welp, I just realized that I made a fucky wucky on one of the combo sequences in the original commit when I added the Player Translated flags, so I have fixed my idiotic error by reverting and fixing it up.
Created Text For URL [sundiatapost.com/man-proposes-to-his-girlfriend-in-public-and-gets-the-biggest-embarrassment-of-his-life-video/]
[CommitMessageUsernameChecker] Handle exceptions
This a definitely "check to see if the reviewers are paying attention" commit...
I mean... it would be kinda funny if they weren't, but also sort of not surprising based on how often my PR descriptions and commit messages are regularly ignored:
cough cough
Oh... yeah, I am totally not bitter...
/me is definitely a little bit bitter...
/me definitely making this commit message longer than it needs to be...
/me wondering if anyone has noticed yet...
/me probably needs to push this change for that to be effective...
/me git push -u origin ...
few things: i added a function to profile page that supposedly is used to read data but im kinda stuck there. sign up view i added code so that database adds email and password in the addPerson() function and also I understand how to track a user better throughout all views so that we may not even have to read from the database (ill still try to get that working though dw). i started looking how to upload photos and it involves a diff thing (Firebase Storage) which i added to pod file, you just need to pod install i think (check to make sure). it looks plausible just am bored of reading shit i don't understand well. i will keep you updated and plz call if you don't understand some of these things. It will help me too to understand it better if i have to explain it. enjoy florida! looks like a lot of fun and you guys all look wonderful!
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]
There are a few nice things though...
People criticized the NVIDIA API because they kind of brute-forced their extensions, however I have to admit that for selecting devices, this method is not THAT bad.
I mean, if you compare all the DRM/KMS/OpenGL code that goes like "Here's our nice way to probe for devices" and then try to probe EVERY SINGLE GPU DEVICE DRIVER MODULE NAME under the sun, in order to get the DRM device filepath associated to it, the EGL way proposed by NVIDIA isn't THAT BAD.
Now, I provided some code to the glmark2 codebase that mimicked Kwin way for device probing. The whole thing used udev to get the properties of DRM devices present, and tried to chose the right one based on multiple criterias and... there's a lot of bug reports that want to go BACK to the old "probe every fucking module name" way because they have strangely weird setup that makes it hard to differentiate the desired GPU from the others.
That said, I'm not talking about EGLStreams here... I still don't see what that brings on the table.
Signed-off-by: Myy Miouyouyou [email protected]
Fucking Schiool
Why do I have to do xyz, why do I have to go to bed at 11, why does life suck?
The answer to that, my friend, is 42.
"8:35am. I am up. Yesterday was a mess, but there is no doubt about it - the UI difficulties that have plagued me for years are going to be resolved this month. Without a doubt.
The Svelte guy deserves great praise for his accomplishment.
If I weren't obsessed about drawing out the power of the next gen hardware for the sake of AI, and was a webdev instead, I'd like to think that I would have made an UI language much like Svelte.
I mean, what he did might seem simple, but webdev has existed for decades and yet only now this comes out.
Being able to do things in less than 100 lines of code that would have previously taken 1000 is a game changer for me.
Blazor has a similar design, so if I want to stay with .NET, I can just go with it.
8:40am. It is really wonderful, I have two, not just one options that are both decent when it comes to UI creation.
I said that Pharo has good UI support, but not like this. This - this is what I wanted all along.
Before this, the only real choice in my mind was Elm, but having a virtual DOM and diffing on every pass while elegant and effective is only a 2/3rds of a solution at most. It is a solution, but it does not quite capture what UI programming really is. It more like works around the issues.
The Svelte design is without a doubt 100% there. It is perfect.
8:45am. I think I can allow myself to get excited about programming once more. Give me a year and I will have complete mastery of web development.
Without a doubt, I will try ML once again and this time I am not going to end up being glued to the command line.
Before I start chilling, let me say one thing - I am surprised how similar desktop UI development and web development are. I thought there would be more pronounced differences, but I was wrong. Desktop might lack HTML and CSS, but besides that the programming model is identical.
I guess in the end, me looking down on webdev was merely ignorance.
8:50am. Now, let me chill for a bit and I will start. I am actually motivated today, so I won't dawdle too much."
mm: replace TIF_MEMDIE checks by tsk_is_oom_victim
TIF_MEMDIE is set only to the tasks whick were either directly selected by the OOM killer or passed through mark_oom_victim from the allocator path. tsk_is_oom_victim is more generic and allows to identify all tasks (threads) which share the mm with the oom victim.
Please note that the freezer still needs to check TIF_MEMDIE because we cannot thaw tasks which do not participage in oom_victims counting otherwise a !TIF_MEMDIE task could interfere after oom_disbale returns.
Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Michal Hocko [email protected] Cc: Mel Gorman [email protected] Cc: Tetsuo Handa [email protected] Cc: David Rientjes [email protected] Cc: Johannes Weiner [email protected] Cc: Roman Gushchin [email protected] Signed-off-by: Andrew Morton [email protected] Signed-off-by: Linus Torvalds [email protected] Signed-off-by: DennySPB [email protected]
Optimize ReasonReactRouter url comparison
cc @nikgraf @rickyvetter
As much as possible, we try not to drag in runtime in ReasonReact (and the current RR's React.re is runtime-free, apart from a few empty module outputs). This is not just to give a very comfortable and reliable guarantee of "zero-cost perf", but also to ensure there's no semantic mismatch between React.js and ReasonReact. As seen with... well, most codebases, any helper that inserts itself into two layers potentially breaks things, and old versions of RR certainly had bugs regarding discrepancies vs React.js. The relatively new hook-based version can guarantee "zero interop bug", which is something extremely nice to rely on whenever we can.
This is just a tangent though; but yeah, no runtime is great for many reasons. In this particular diff, the generic object comparison was added in 9147410fb0ee296950b8d79e9cd59eb392a7ee50. This isn't great:
- The generic comparison is theoretically wrong because it doesn't properly handle some of JS' corner-cases (imagine someone puts a
Symbolon an object, etc.): https://github.com/BuckleScript/bucklescript/blob/80297bbb138f5e0d69c7fed74c5b6043391b2505/lib/js/caml_obj.js#L305 - The above code, because of its genericity, is also extremely slow, since it introspects into some runtime types, allocates (in a comparison!...), is not tail-recursive (https://github.com/BuckleScript/bucklescript/blob/80297bbb138f5e0d69c7fed74c5b6043391b2505/lib/js/caml_obj.js#L385).
- It's even worse because in the router, we just want "not equal". If you check the JS output of the diff, you'll see that it's calling
caml_notequal, which is literally!caml_notequal. So we do a full check for deep equality first, then negate it, instead of bailing early in 95% of the cases. - This is especially bad because ReasonReact is a base library.
So we hand-roll our own urlNotEqual comparison:
- It only needs to handle our
urlrecord. Super lean, and easily and verifiably 100% correct, unlike the generic version. - The fastest checks possible, with even better readability because it's not generic. See the new JS output; no runtime introspection, no allocation, tail recursive.
- Even better, bails early by checking the other fields first.
- Removes the need for dragging in
caml_obj(Instagram, and I'm sure some other high-profile highly constrained use-cases, has some informal "be a good citizen" rule regarding introducing new infra; i.e. "don't take over everything, don't be a burden, etc". The Reason community should definitely follow this mantra more, and more so than other FP communities. Don't forcefully shove Reason where you can cause resentments from unrelated teams).
This restores the Router to be mostly allocation-free (edit: except now I see that a rather bad and allocation-heavy implementation of useUrl went in... cc @rickyvetter). We can confidently say "this is the fastest and leanest Router for React, not to mention that it actually fulfills more feature requirements of a router than alternatives thanks to our non-opinionated pattern matching on the URL and letting you do the rest (also keep in mind also that OCaml pattern matching doesn't allocate).
Btw, don't get attached to this particular diff's elegant implementation. Generally speaking, we should prefer array over list. It's just that for our Router, list really is a better representation, for once.
Lastly, this diff is one of the reasons why I'm uneasy with all the deriving or other codegen for creating equality comparisons. Once you dumbly generate those, you naturally reach for the slowest possible equal comparison (see all the points above), and since most folks don't look at the generated JS, that comparison's cost is entirely hidden now. That's no way to teach performance and correctness.
===
It's hard to write up what "quality" means for Reason libraries, but I'd like this diff to be an example of it. People naively think "quality" means "elegance" and "less visible code", but that's just "cleanness", like how disorganizingly stuffing your clothes into a corner still makes a clean room but doesn't make it easier to find a clothe back. For Reason, I'd like us to mentally inline all the code, pretend they're all visible to you, then evaluate the quality. This has the consequence that we get more careful about dragging in dependencies, that we don't pretend abstracting into a function means the cost is zero now (refer to my recent Reason conf talk), and that we go beyond the superficial polish into deeper polish.
"https://arxiv.org/abs/2002.12499 On Catastrophic Interference in Atari 2600 Games
This paper is interesting. Let me read the Satanophany chapter and then I'll go for it. After that comes the Blazor talk from yesterday.
9:10am. "The Memento agent is far more sample efficient than training the baseline Rainbow agent longer. The Memento agent achieves the same median performance increase in only 5M frames compared to 200M frames for the longer-training Rainbow agent."
9:15am. Yeah, the fact that a single task in RL might have multiple subtasks which cause catastrophic forgetting is what I considered myself. This is not some big insight. It is just that I do not how to resolve the issue.
Reseting from random weights is interesting, but it is hardly the right way to go. Does the brain really do this? I doubt it.
Though I wonder what the Deepmind/OpenAI guys would think about this paper? If they had integrity they should feel shame over throwing so much hardware at the games without resolving the underlying issues. If they want to be seen as the best, then they should do this rather than waiting for somebody else to do it.
9:35am. Though I had been reading that paper, I still dawdled a bit too much. Let me go through the Blazor talk. Then I'll check out that Svelte post. Then comes the MySQL lecture.
9:40am. https://youtu.be/Khn7sDUSEJM?t=934
This is super cool. Yeah, dedicating myself to thoroughly mastering this for the next few years sounds like what I should be doing. Whatever I do, these kinds of UIs is how I should be expressing myself in programming. More than just using this, I should be diving under the hood to understand the secrets of this.
This is real programming.
9:50am. https://youtu.be/Khn7sDUSEJM?t=1605
Interesting that he is talking about gRPC here for efficient client-server communication.
https://youtu.be/Khn7sDUSEJM?t=3309
Blazor for native UIs? That's the future right there. Or part of it. I did not think they would have gone that far, but they are really going all out here.
10:30am. This was great.
10:35am. I am looking at the HN threads and it seems that there is a way to use F# with Blazor. That should be interesting.
https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-about-blazor/
10:40am. I guess I'll save the MySQL lecture for later. Let me read some of this and then I'll watch a talk by Rich Harris.
11:15am. https://svelte.dev/blog/svelte-3-rethinking-reactivity
Let me watch the video accompanying this.
11:20am. https://youtu.be/AdNJ3fydeao?t=532
I actually saw this coming yesterday. In the Vue tutorial, or was it maybe the Svelte tutorial itself, Brad did not need to spread into the array and assign to it. He could have added to an existing array and then just triggered the update by reassigning itself. That would have worked as well.
11:40am. https://youtu.be/AdNJ3fydeao?t=1136
I wonder what talk he is talking about here?
11:55am. https://youtu.be/AdNJ3fydeao?t=1825
Transitions are interesting too. I've been wondering how I would animate moving cards in my GUI. Svelte has a solution.
12:10pm. Uf, that was a lot to digest. Let me have that break. I want to see more Blazor, but I'll leave that for later.
What I need to do is get back to the grind. I am going to go through the MySQL video and then the ASP.NET lecture after that.
I am not sure whether I feel like messing with the legacy stuff now that I know about Blazor, but I should spend some time on it even if I won't use it. I want to at least understand some of it.
1:30pm. Did I forget to commit? Yes, I did. At any rate, the next thing on my TODO list are chores. Then a bit chilling. Then the MySQL lecture. I'll install that studio and start following along. If not, I'll just move to the ASP.NET lecture."
serial: core: Allow processing sysrq at port unlock time
[ Upstream commit d6e1935819db0c91ce4a5af82466f3ab50d17346 ]
Right now serial drivers process sysrq keys deep in their character receiving code. This means that they've already grabbed their port->lock spinlock. This can end up getting in the way if we've go to do serial stuff (especially kgdb) in response to the sysrq.
Serial drivers have various hacks in them to handle this. Looking at '8250_port.c' you can see that the console_write() skips locking if we're in the sysrq handler. Looking at 'msm_serial.c' you can see that the port lock is dropped around uart_handle_sysrq_char().
It turns out that these hacks aren't exactly perfect. If you have lockdep turned on and use something like the 8250_port hack you'll get a splat that looks like:
WARNING: possible circular locking dependency detected [...] is trying to acquire lock: ... (console_owner){-.-.}, at: console_unlock+0x2e0/0x5e4
but task is already holding lock: ... (&port_lock_key){-.-.}, at: serial8250_handle_irq+0x30/0xe4
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&port_lock_key){-.-.}: _raw_spin_lock_irqsave+0x58/0x70 serial8250_console_write+0xa8/0x250 univ8250_console_write+0x40/0x4c console_unlock+0x528/0x5e4 register_console+0x2c4/0x3b0 uart_add_one_port+0x350/0x478 serial8250_register_8250_port+0x350/0x3a8 dw8250_probe+0x67c/0x754 platform_drv_probe+0x58/0xa4 really_probe+0x150/0x294 driver_probe_device+0xac/0xe8 __driver_attach+0x98/0xd0 bus_for_each_dev+0x84/0xc8 driver_attach+0x2c/0x34 bus_add_driver+0xf0/0x1ec driver_register+0xb4/0x100 __platform_driver_register+0x60/0x6c dw8250_platform_driver_init+0x20/0x28 ...
-> #0 (console_owner){-.-.}: lock_acquire+0x1e8/0x214 console_unlock+0x35c/0x5e4 vprintk_emit+0x230/0x274 vprintk_default+0x7c/0x84 vprintk_func+0x190/0x1bc printk+0x80/0xa0 __handle_sysrq+0x104/0x21c handle_sysrq+0x30/0x3c serial8250_read_char+0x15c/0x18c serial8250_rx_chars+0x34/0x74 serial8250_handle_irq+0x9c/0xe4 dw8250_handle_irq+0x98/0xcc serial8250_interrupt+0x50/0xe8 ...
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&port_lock_key);
lock(console_owner);
lock(&port_lock_key);
lock(console_owner);
*** DEADLOCK ***
The hack used in 'msm_serial.c' doesn't cause the above splats but it seems a bit ugly to unlock / lock our spinlock deep in our irq handler.
It seems like we could defer processing the sysrq until the end of the interrupt handler right after we've unlocked the port. With this scheme if a whole batch of sysrq characters comes in one irq then we won't handle them all, but that seems like it should be a fine compromise.
Signed-off-by: Douglas Anderson [email protected] Signed-off-by: Greg Kroah-Hartman [email protected] Signed-off-by: Sasha Levin [email protected]
grammar and spelling mistakes ... fuck you grammarly
Use zic's new "-b slim" option to generate smaller timezone files.
IANA tzcode release 2019b adds an option that tells zic not to emit the old 32-bit section of the timezone files, and to skip some other space-wasting hacks needed for compatibility with old timezone client libraries. Since we only expect our own code to use the timezone data we install, and our code is up-to-date with 2019b, there's no apparent reason not to generate the smallest possible files.
Unfortunately, while the individual zone files do get significantly smaller in many cases, they were not that big to begin with; which means that no real space savings ensues on filesystems that don't optimize small files. (For instance, on ext4 with 4K block size, "du" says the installed timezone tree is the same size as before.) Still, it seems worth making the change, if only because this is presumably the wave of the future. At the very least, we'll save some cycles while reading a zone file.
But given the marginal value and the fact that this is a new code path, it doesn't seem worth the risk of back-patching this change into stable branches. Hence, unlike most of our timezone-related changes, apply to HEAD only.
Discussion: https://postgr.es/m/[email protected]
c++: Fix non-constant TARGET_EXPR constexpr handing [PR93998]
We ICE on the following testcase since I've added the SAVE_EXPR-like constexpr handling where the TARGET_EXPR initializer (and cleanup) is evaluated only once (because it might have side-effects like new or delete expressions in it). The problem is if the TARGET_EXPR (but I guess in theory SAVE_EXPR too) initializer is *non_constant_p. We still remember the result, but already not that it is *non_constant_p. Normally that wouldn't be a big problem, if something is *non_constant_p, we only or into it and so the whole expression will be non-constant too. Except in the builtins handling, we try to evaluate the arguments with non_constant_p pointing into a dummy1 bool which we ignore. This is because some builtins might fold into a constant even if they don't have a constexpr argument. Unfortunately if we evaluate the TARGET_EXPR first in the argument of such a builtin and then once again, we don't set *non_constant_p.
So, either we don't remember the TARGET_EXPR/SAVE_EXPR result if it wasn't constant, like the following patch does, or we could remember it, but in some way that would make it clear that it is non-constant (e.g. by pushing into the global->values SAVE_EXPR, SAVE_EXPR entry and perhaps for TARGET_EXPR don't remember it on TARGET_EXPR_SLOT, but the TARGET_EXPR itself and similarly push TARGET_EXPR, TARGET_EXPR and if we see those after the lookup, diagnose + set *non_constant_p. Or we could perhaps during the builtin argument evaluation push expressions into a different save_expr vec and undo them afterwards.
2020-03-03 Jakub Jelinek [email protected]
PR c++/93998
* constexpr.c (cxx_eval_constant_expression)
<case TARGET_EXPR, case SAVE_EXPR>: Don't record anything if
*non_constant_p is true.
* g++.dg/ext/pr93998.C: New test.
Big ol' day of debugging.
Holy crap these 2 issues caused a lot of troubles:
- Moving the trails to a pool Object, they stopped rendering after the starting list of preinnitialized pool objects > they now are rendered by the pool Object instead of the Trail Object, in which case it no longer loses track of them
- Collisions again. Somewhere a world or local reference got mixed up so 0,0 of the grid is once again top left instead of centered. AI dont collide properly because I have no fucking idea what Tim did to that class but Im going to be rebuilding it from scratch now that i can focus on AI instead of debugging basic ass shit.
Add files via upload
Data Visualization Project
Topic: Lyme: Visualizing Disease Spread
Questions:
- Can you visualize the number of dengue fever cases reported each week in Colorado Counties for the years 2002 to 2004?
- Can you visualize the number of dengue cases each week (in each location) based on environmental variables describing changes in temperature, precipitation and humidity?
Dataset: The data has taken from drivenData.org, it was released as a part of their competition DengAI. Dataset from the competition has only 2 cities Sanjuan and Iquitos, but we have added three more cities Cusco, Tijuana and Rosario with random precipitation, humidity and temperature. Dengue fever is a mosquito-borne disease that occurs in tropical and sub-tropical parts of the world. In mild cases, symptoms are similar to the flu: fever, rash, and muscle and joint pain. In severe cases, dengue fever can cause severe bleeding, low blood pressure, and even death. Because it is carried by mosquitoes, the transmission dynamics of dengue are related to climate variables such as temperature and precipitation. An understanding of the relationship between climate and dengue dynamics can improve research initiatives and resource allocation to help fight life-threatening pandemics.
Our data contains Climatic variables such as precipitation, temperature, humidity for each City. And also, we have total cases of Dengue Affected Cases for the Corresponding Year and Week of the Year.
Column Names:
- City- Name of the city
- Year-Dengue Affected Year
- Weekofyear-Week of the Year
- week_start_date-Week start data in the format mm-dd-yy
- avg_temp- Average air temperature according to Climate Forecast System Reanalysis measurements (0.5x0.5-degree scale).
- precip_amt-Total Precipitation amount according to Climate Forecast System Reanalysis measurements (0.5x0.5-degree scale).
- Humidity_amt-Mean Specific humidity according to Climate Forecast System Reanalysis measurements (0.5x0.5-degree scale).
- total_cases- Total cases predicted.
Holy fucking shit. I hate this. Database seems to be working decently now tho.