2,356,370 events, 1,154,386 push events, 1,837,372 commit messages, 136,158,127 characters
Adding a lot since my last commit. Have developed the growth mechanics. Different climates generate different food yields. Food storage is in effect. Bands will always prioritize moving into tiles with highest food yields. Also updated the UI to be prettier and better at conveying information I need. I really need to commit more because I am struggling to remember everything I did here. My next steps are adding rivers, refining growth mechanic, deciding when bands evolve, incorporating variations in growth rate based on lifestyle, and creating a map of the Middle East. Rivers will enhance yields for the tile. They will be a type of Terrain for the Region. This is coming along nicely. I am prett exicted. Oh yeah! I am planning on doing multiple instances of the map in the essay to model populations in different maps e.g. single tile versus whole Middle East. I would also like to get someone to draw me some art for it.
Creating Bullet Split
Fuck you kent and your wierd script errors.
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]
You only need the src and res btw idiot
Yeah, you are stupid
Merge pull request #8 from ListeKoen/sfoie
i hate my life
3a except morgan
"The documentation for Morgan is not the best, and you may have to spend some time figuring out how to configure it correctly." fuck you
Move to maven (#9)
- Move back to maven
Fuck that shit: Bin müde. IntelliJ will nicht, wie ich will. Compiler springt nach jedem IntelliJ-Neustart zurück auf Java 13 und jammert dass er nicht mit 13 compilen kann...
In maven kann ich schön sagen Java 8 und alles UTF-8 und er hält seine Fresse und macht einfach... Hätte Gradle genommen aber kb auf was fremdes. Nazi halt und so. Ich weiß das Gradle auch maven repo etc. nutzen kann. Ich weiß dass Android Studio gradle nutzt. Aber juckt. Fremd = Böse hat uns die gute AFD beigebracht also done.
-
Prepare directory layout 1/2
-
Prepare directory layout 2/2
-
Prepare directory layout 3/2
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]
"1:10pm. Wow, I am wasting time. Well, let me do it for a bit longer, do the chores and then I will start this thing.
2pm. Breakfast done, chores done. It is time to start studying Typescript. Let me go through that course. Then I will stop wasting time and try that demo plugin in Typescript itself.
I want to get this done rather than getting buried in APIs.
I am a programmer, so what I should be doing is programming. Studies are for the students.
Now where was I?
This is really boring. I should just skim this and learn as I go along.
This is super boring. Let me watch the video.
3:15pm. This is ultra super boring!!!
Let me finish module 2 and I will reconsider my path.
3:30pm. Let me go through section 3.
This is such a waste of time, but on the other hand, it is super basic so I have to do it to get a passing familiarity with Typescript.
3:55pm. I am taking a little break right now. The tedium of this is really doing me in.
4:30pm. Oh, TS compiler will automatically do the import statements as well. That is nice.
4:55pm. Finally done with section 3. Yeah, the tedium of going through this shit is definitely high. It seems easy tasks have a way of making up for it by being boring.
5pm. Ok, ok...
Let me just go through this last thing and then I'll quickly peek at the TS documentation.
5:10pm. Uf, let me take a break here. I need a break.
6:05pm. Done with lunch. Let me finish up the section 4 videos and then I am done for the day.
6:30pm. https://www.typescriptlang.org/docs/handbook/decorators.html
This OO lingo for what should be simple function composition is getting to me.
https://www.typescriptlang.org/docs/home.html
Instead of trying to read through that course, I should have gone for the documentation instead.
6:35pm. But honestly there is no way I can do that right now. I am dead here.
This was so tedious, I was barely paying attention. Yet, I did my best. Tomorrow I will give the documentation a brush and after that I will jump straight into programming.
6:45pm. I need to start playing around with some basic plugins. I need to start establishing control over the editor. Once I do that, everything will be much easier.
7:05pm. When things get hard, it is easy to forget what your goals are. Constant remainders are needed to remain on course."
This commit re-implements the memory model used by macaw symbolic
There are two major changes:
- The interface to memory models in Data.Macaw.Symbolic has changed
- The suggested implementation in Data.Macaw.Symbolic.Memory has changed
The change improves performance and fixes a soundness bug.
macawExtensions(Data.Macaw.Symbolic) takes a new argument: aMkGlobalPointerValidityPred. UsemkGlobalPointerValidityPredto provide one.mapRegionPointersno longer takes a default pointer argument (delete it at call sites)GlobalMapreturns anLLVMPtr sym winstead of aMaybe (LLVMPtr sym w)
Users of the suggested memory model do not need to worry about the last change,
as it has been migrated. If you provided your own address mapping function, it
must now be total. This is annoying, but the old API was unsound because
macaw-symbolic did not have enough information to correctly handle the Nothing
case. The idea of the change is that the mapping function should translate any
concrete pointers as appropriate, while symbolic pointers should generate a mux
over all possible allocations. Unfortunately, macaw-symbolic does not have
enough information to generate the mux itself, as there may be allocations
created externally.
This interface and implementation is concerned with handling pointers to static memory in a binary. These are distinguished from pointers to dynamically-allocated or stack memory because many machine code instructions compute bitvectors and treat them as pointers. In the LLVM memory model used by macaw-symbolic, each memory allocation has a block identifier (a natural number). The stack and each heap allocation get unique block identifiers. However, pointers to static memory have no block identifier and must be mapped to a block in order to fit into the LLVM memory model.
The previous implementation assigned each mapped memory segment in a binary to its own LLVM memory allocation. This had the nice property of implicitly proving that no memory access was touching unmapped memory. Unfortunately, it was especially inefficient in the presence of symbolic reads and writes, as it generated mux trees over all possible allocations and significantly slowed symbolic execution.
The new memory model implementation (in Data.Macaw.Symbolic.Memory) instead uses a single allocation for all static allocations. This pushes more of the logic for resolving reads and writes into the SMT solver and the theory of arrays. In cases where sufficient constraints exist in path conditions, this means that we can support symbolic reads and writes. Additionally, since we have only a single SMT array backing all allocations, mapping bitvectors to LLVM pointers in the memory model is trivial: we just change their block identifier from zero (denoting a bitvector) to the block identifier of the unique allocation backing static data.
This change has to do some extra work to ensure safety (especially that unmapped memory is never written to or read from). This is handled with the MkGlobalPointerValidityPred interface in Data.Macaw.Symbolic. This function, which is passed to the macaw-symbolic initialization, constructs well-formedness predicates for all pointers used to access memory. Symbolic execution tasks that do not need to enforce this property can simply provide a function that never returns any predicates to check. Implementations that want a reasonable default can use the mkGlobalPointerValidityPred from Data.Macaw.Symbolic.Memory. The default implementation ensures that no reads or writes touch unmapped memory and that writes to static data never write to read-only segments.
This change also converts the examples in macaw-symbolic haddocks to use doctest to ensure that they do not get out of date. These are checked as part of CI.
basically reverse-engineering javafx's word wrap algorithm
my latest theory is the few remaining discrepancies (in the number of rows I think we need vs the rows the wrapped text actually takes up) are being caused by my algo not accounting for the word boundary-preservation that the javafx wrapping algo does.
I wish I could just find the algorithm that JavaFx uses somewhere in its codebase, but although it's technically open source it may as well not be.
The JavaFx source incredibly difficult to navidate, and I haven't anything remotely related to the actual wrapping or layout functionality's implementation.
Just want to take a moment to vomit about how utterly shite the design is. Everything is coupled to everything else, meaning nothing can be pulled out or reused, without it also requiring seemingly the rest of JavaFx. Nothing can be subclassed. 300 line classes are embedded inside other 400 line classes, hiding them from the world.
Such an ugly piece of shit codebase.
Even from an outside perspective, so much essential functionality is hidden behind a failed attempt to use CSS for styling. So many missing Java APIs. Using CSS Strings removes Java's biggest advantages: compile-time checking and type safety. What a stupid idea.
They didn't even manage to fully implement CSS. They've got neither a complete Java API to their components, nor a compliant or complete CSS interface.
I deeply, deeply dislike the design decisions made.
The only excuse is that this code was probably written around 2006, and was only originally intended to be closed source.
The saving grace is the ubiquitous javadoc.
Created Text For URL [www.theguardian.com/film/2020/feb/11/to-all-the-boys-ps-i-still-love-you-review-romcom-sequel]
C3M0_A: Brainstorming
@afadoomer - I am currently rethinking the gameplay in this map as I am not sure what the best decision is. That's why I want to ask you as well for your thoughts.
Currently we added the day-night cycle to the map, making it partially a really stresful job beating the map. No time to tell the story, no time to "discover" everything. On the other hand it's a nice feature in general to have the cycle. But is it really necessary?
I am thinking about stripping the whole day/night cycle from the map and turning it in a horror-survival with a lot of puzzles, a lot of story, resembling the gameplay of Resident Evil somehow.
What do you think of this decision? What would you suggest?
Finish readme.
And mention how much you love to worship GOD.
tests: check calls to yyerror from the user actions
This revealed a number of things I had not realized:
-
the Java location tracking was aliasing the same pair of positions for all the symbols (see previous commit).
-
in impure parsers, it's quite easy to use incorrect locations for diagnostics, since yyerror uses yylloc, which is the location of the lookahead, not that of the current lhs. So we need something like
{ YYLTYPE old_yylloc = yylloc; yylloc = @$; yyerror (]AT_PARAM_IF([result, count, nerrs, ])[buf); yylloc = old_yylloc; }
Maybe we should do that little yylloc dance in the skeleton instead of leaving it to the user? It might be costly... But that's only for users of the impure parsers, which are asking for trouble anyway.
-
in glr.cc invoking yyerror is somewhat cumbersome: the C++ interface is not available as we are in yyparse (which in C), and yyerror is used by glr.cc itself to bind it to the user's parser::error. If we call yyerror, we need:
yyerror (]AT_LOCATION_IF([[&@$, ]])[yyparser, ]AT_PARAM_IF([result, count, nerrs, ])[msg);
However calling yy::parser::error is easier, once we know that the current parser object is available as 'yyparser'. Which also saves us from having to pass the parse-params ourselves:
yyparser.error (]AT_LOCATION_IF([[@$, ]])[msg);
- tests/calc.at: Invoke yyerror by hand, instead of using fprintf etc. Adjust expectations.