there were a lot of events recorded by gharchive.org of which 2,238,891 were push events containing 3,401,350 commit messages that amount to 261,032,551 characters filtered with words.py@e23d022007... to these 63 messages:
Small VoxPrimalis Fixes (#18944)
-
fuck you i don't need to give you a fucking summary
-
fixes
[MODULAR] Fixes All Known Modular Persistence (NIF) Saving Issues (#19096)
-
Fuck
-
Holy shit
[MIRROR] Abductor scientist self-retrieve failure/runtime fix [MDB IGNORE] (#19179)
- Abductor scientist self-retrieve failure/runtime fix (#73172)
Since the abductor outfit/implant would load before the abductor ship (and it's teleport pad) when first generating a team, a runtime would occur when trying to link the pad to the implant. Another would occur every time you attempted to retrieve yourself (as the linked pad would be null), preventing recall and completely neutering an abductor team's most important maneuver.
Now, using the implant will perform the linking process again if no linked pad is found, and provides the owner with a warning if (by some great calamity) they genuinely have no pad to teleport back to. This solves the issue of the implant sometimes not linking to a pad properly on initialize, and makes them way less prone to breaking.
Apparently this has been broken for a while, presumably since the abductor ship was made into a lazyloading template.
The funny silly grey men get to torture the poor hapless crew once again.
🆑 fix: abductor scientist's retrieval implants will now properly recall the owner, and inform them upon recall failure. /🆑
- Abductor scientist self-retrieve failure/runtime fix
Co-authored-by: Rhials [email protected]
windows: ignore empty PATH elements
When looking up an executable via the _which function, Git GUI
imitates the execlp() strategy where the environment variable PATH
is interpreted as a list of paths in which to search.
For historical reasons, stemming from the olden times when it was uncommon to download a lot of files from the internet into the current directory, empty elements in this list are treated as if the current directory had been specified.
Nowadays, of course, this treatment is highly dangerous as the current
directory often contains files that have just been downloaded and not
yet been inspected by the user. Unix/Linux users are essentially
expected to be very, very careful to simply not add empty PATH
elements, i.e. not to make use of that feature.
On Windows, however, it is quite common for PATH to contain empty
elements by mistake, e.g. as an unintended left-over entry when an
application was installed from the Windows Store and then uninstalled
manually.
While it would probably make most sense to safe-guard not only Windows
users, it seems to be common practice to ignore these empty PATH
elements only on Windows, but not on other platforms.
Sadly, this practice is followed inconsistently between different software projects, where projects with few, if any, Windows-based contributors tend to be less consistent or even "blissful" about it. Here is a non-exhaustive list:
Cygwin:
It specifically "eats" empty paths when converting path lists to
POSIX: https://github.com/cygwin/cygwin/commit/753702223c7d
I.e. it follows the common practice.
PowerShell:
It specifically ignores empty paths when searching the `PATH`.
The reason for this is apparently so self-evident that it is not
even mentioned here:
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables#path-information
I.e. it follows the common practice.
CMD:
Oh my, CMD. Let's just forget about it, nobody in their right
(security) mind takes CMD as inspiration. It is so unsafe by
default that we even planned on dropping `Git CMD` from Git for
Windows altogether, and only walked back on that plan when we
found a super ugly hack, just to keep Git's users secure by
default:
https://github.com/git-for-windows/MINGW-packages/commit/82172388bb51
So CMD chooses to hide behind the battle cry "Works as
Designed!" that all too often leaves users vulnerable. CMD is
probably the most prominent project whose lead you want to avoid
following in matters of security.
Win32 API (CreateProcess())
Just like CMD, `CreateProcess()` adheres to the original design
of the path lookup in the name of backward compatibility (see
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
for details):
If the file name does not contain a directory path, the
system searches for the executable file in the following
sequence:
1. The directory from which the application loaded.
2. The current directory for the parent process.
[...]
I.e. the Win32 API itself chooses backwards compatibility over
users' safety.
Git LFS:
There have been not one, not two, but three security advisories
about Git LFS executing executables from the current directory by
mistake. As part of one of them, a change was introduced to stop
treating empty `PATH` elements as equivalent to `.`:
https://github.com/git-lfs/git-lfs/commit/7cd7bb0a1f0d
I.e. it follows the common practice.
Go:
Go does not follow the common practice, and you can think about
that what you want:
https://github.com/golang/go/blob/go1.19.3/src/os/exec/lp_windows.go#L114-L135
https://github.com/golang/go/blob/go1.19.3/src/path/filepath/path_windows.go#L108-L137
Git Credential Manager:
It tries to imitate Git LFS, but unfortunately misses the empty
`PATH` element handling. As of time of writing, this is in the
process of being fixed:
https://github.com/GitCredentialManager/git-credential-manager/pull/968
So now that we have established that it is a common practice to ignore
empty PATH elements on Windows, let's assess this commit's change
using Schneier's Five-Step Process
(https://www.schneier.com/crypto-gram/archives/2002/0415.html#1):
Step 1: What problem does it solve?
It prevents an entire class of Remote Code Execution exploits via
Git GUI's `Clone` functionality.
Step 2: How well does it solve that problem?
Very well. It prevents the attack vector of luring an unsuspecting
victim into cloning an executable into the worktree root directory
that Git GUI immediately executes.
Step 3: What other security problems does it cause?
Maybe non-security problems: If a project (ab-)uses the unsafe
`PATH` lookup. That would not only be unsafe, though, but
fragile in the first place because it would break when running
in a subdirectory. Therefore I would consider this a scenario
not worth keeping working.
Step 4: What are the costs of this measure?
Almost nil, except for the time writing up this commit message
;-)
Step 5: Given the answers to steps two through four, is the security measure worth the costs?
Yes. Keeping Git's users Secure By Default is worth it. It's a
tiny price to pay compared to the damages even a single
successful exploit can cost.
So let's follow that common practice in Git GUI, too.
Signed-off-by: Johannes Schindelin [email protected]
[FIX] stock,purchase,mrp: accumulative security days
Usecase to reproduce:
- Set the warehouse as 3 steps receipt
- Put a security delay of 3 days for purchase
- Set a product with a vendor and 1 days as LT
- Replenish with the orderpoint
You expect to have a schedule date for tomorrow that contains all the product needed in the incoming 4 days.
Currenly the internal transfer from QC -> Stock is for tomorrow (ok). The transfer from Inpur -> QC is plan for 2 days in the past. (not ok) The PO date is plan for 5 days in the past. (not ok)
It happens because the system check at each stock.rule application if
purchase is part of the route. If it's then it applies the security lead
time. It's a mistake because we should apply it only the first time.
To fix it we directly set it when the orderpoint run and not during
stock.move creation.
However for MTO it's not that easy. We don't want to deliver too
early the customer. So we keep applying the delay during the
stock.move creation but only when it goes under the warehouse stock
location.
Part-of: odoo/odoo#109640
Add default graphical packages for WSL and wslu utils
Turns out WSL2 ships with working, pre-configured, out-of-box support for graphical apps and sound (using the main, official Ubuntu distro). No tweaking or installation needed. That is absolutely mind-blowing.
Gimp and Inkscape run beautifully. I prefer using boring, steady, predicable xterm and it looks fantastic in WSL with my default Xresources config, including anti-aliased fonts. Clipboard support between WSL and Windows Just Works (TM) in xterm and gVim. You can tell the apps are running out of a container rather than natively, but there's only a very slight input lag. Firefox can't be installed because Ubuntu still thinks Snaps are a good idea (but that's not WSL's fault). Overall surprisingly great experience.
As WSL has matured, I've wondered if WSL makes Windows a better, more
friendly development environment than OS X nowadays. This clinches it:
the answer is yes. Much eeasier to install, better defaults, more
features, way more similar to running native Linux. And this environment
is fully supported by Microsoft rather than the neglected and abused
red-headed step-children that Apple has with Homebrew, XQuartz,
/usr/local, and the random mishmash of BSD and GNU utils.
If you can't run Linux natively at work, running a full Linux inside Windows via WSL is a better experience than running a half-UNIX alongside OS X via Homebrew and XQuartz.
Apple has been moving away from their UNIX roots and is being ever more hostile to open source projects. In contrast, Microsoft is leaning in, hard, with WSL. Never thought I'd be here, but as a programmer I'll be requesting Microsoft hardware instead of Apple hardware at future jobs.
Merge rust-bitcoin/rust-bitcoin#1532: Improve Psbt error handling
e7bbfd391353fd03d60550c768364e9de5d3e8c5 Improve Psbt error handling (DanGould)
Pull request description:
This initial work attempts to fix #837's first 2 points
- The current psbt::serialize::Deserialize has an error type of consensus::encode::Error. I think we should cleanly separate consensus encoding errors from application-level encoding errors like psbt.
- There is a recursive dependence between encode::Error and psbt::Error which would need to be cleanly dissected and separated so that there is no dependence or only one-way dependence.
arturomf94 how compatible do your #1310 changes look to address #837's third point with this design?
- There are a lot ParseError(String) messages that could use a better type to downflow the information.
I think your prior art would completely address this issue now.
encode::Error has an Io variant. now that Psbt::deserialize returns psbt::Error and produces an io::Error, we need an Io variant on psbt::Error. Except that doing so breaks #[derive(Eq)] and lots of tests for psbt::Error.
Kixunil, I'm trying to understand your feedback regarding a solution to this problem.
I believe that the best error untangling would be to make decodable error associated.
I meant having associated
Errortype atDecodabletrait. Encoding should only fail if the writer fails so we should haveio::Errorthere (at least until we have something likegenio).[it] is a problem to instantiate consensus::encode::Error in [the psbt] module for
io::Error?It certainly does look strange. Maybe we should have this shared type:
/// Error used when reading or decoding fails. pub enum ReadError<Io, Decode> { /// Reading failed Io(Io), /// Decoding failed Decode(Decode), // consensus and PSBT error here }However this one will be annoying to use with
?:( We could haveResultExtto providedecode()andio()methods to make it easier.If that's not acceptable then I think deduplicated IO error is better.
Kixunil didn't we just get rid of Psbt as Decodable? Would this make more sense to have as an error associated with Deserialize? Or did we do the opposite of what we should have by making Psbt only Serialize/Deserialize because of #934, where only consensus objects are allowed to be Decodable? I wonder if we prioritized that strict categorization and are stuck with worth machinery because of it. My goal with #988 was to get to a point where we could address #837 and ultimately implement PSBTv2.
ACKs for top commit: tcharding: ACK e7bbfd391353fd03d60550c768364e9de5d3e8c5 apoelstra: ACK e7bbfd391353fd03d60550c768364e9de5d3e8c5
Tree-SHA512: 32975594fde42727ea9030f46570a1403ae1a108570ab115519ebeddc28938f141e2134b04d6b29ce94817ed776c13815dea5647c463e4a13b47ba55f4e7858a
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.14 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.14 differences 2. change prepare_kill_siginfo() to use struct siginfo instead of kernel_siginfo 3. use copy_from_user() instead of copy_siginfo_from_user() in copy_siginfo_from_user_any() 4. replaced COND_SYSCALL with cond_syscall 5. Removed __ia32_sys_pidfd_send_signal in arch/x86/entry/syscalls/syscall_32.tbl. 6. 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: I34da11c63ac8cafb0353d9af24c820cef519ec27 Signed-off-by: Suren Baghdasaryan [email protected] Signed-off-by: electimon [email protected]
Simplify with-google-analytics example (#43894)
- Make sure the linting passes by running
pnpm build && pnpm lint - The "examples guidelines" are followed from our contributing doc
First of all thanks for this amazing project and all the help you provide with these examples.
It seems there is code duplication in this example. After some tests
locally seem to _document.js is not necessary for gtag to work
properly.
I am aware of vercel/next.js#40645 and I would like to ask @dave-hay, @SukkaW and @ijjk to consider this is still necessary. If so why then not move all content of the scripts from _app to _document?
In any case, I am open to adding here some comments explaining what is the reason for this code duplication if necessary.
Changes that come from vercel/next.js#43897
- The
eventhashChangeComplete should be removed since/homeand/home/#sectionis not new pageview, but just reference to the same page.
If we go from /home to /home/#section (with a button click or a link for
example) this shouldn't trigger a new page visit on gtag.
For this reason, I think we should revert the changes from vercel/next.js#36079. If there is a better argument of why this should stay I am also open to creating comments to clarify this on the example since I don't think should be the default behavior and not useful in most cases.
- The
id="gtag-init"was added with no context to the example from vercel/next.js#29530
If there is a reason for this id in the script to existing I am open to adding a comment that clarifies this since in my experience is not necessary at all.
Edit: Batching with vercel/next.js#43897 as recommended by vercel/next.js#43897 (comment)
Co-authored-by: JJ Kasper [email protected]
[jak2] improve loader for jak 2 levels (#2206)
Add a debug window for the loader to show levels and fix an issue with jak 2 level unloading. I never really thought about how this works for > 2 levels, and there is a chance that you could unload the wrong level in some cases.
The problem is some combination of merc-only levels not counting toward the "in use" detection, and the unloader ignoring what the game wants to load.
I don't remember why using merc models doesn't contribute to "in use" but I'm afraid to change this for jak 1. Instead, we can have the unloader avoid unloading levels that the game is telling us are loaded. This is what we should have done originally, but there was a time when Jak 1 didn't tell the loader anything, and we had this stupid detection thing.
I think this is the first step toward just getting rid of the "in use" detection and trusting the game for everything.
add torch.autograd._set_view_replay_enabled, use in aot autograd (#92588)
tldr; this should fix some minor perf regressions that were caused by adding more as_strided() calls in aot autograd.
This PR adds a new context manager, torch.autograd._set_view_replay_enabled().
Context: AOT Autograd has special handling for "outputs that alias graph intermediates". E.g. given this function:
def f(x):
y = torch.mul(x, 2)
out = y.view(-1)
return out
AOT Autograd will do the following:
def fn_to_compile(x):
y = torch.mul(x, 2)
out = y.view(-1)
# return the graph intermediate
return y, out
compiled_fn = compile(fn_to_compile)
def wrapper(x):
y, out = compiled_fn(x)
# regenerate the alias of the graph intermediate
return out._view_func(y)
What's annoying is that out._view_func() will result in a .as_strided call, because out is an ordinary runtime tensor. This (likely?) caused a perf regression, because when running the backward, out as_strided_backward() is slower than our view_backward().
In this PR, I added some TLS for instructing autograd to do view replay instead of as_strided, even when given a normal tensor. I'm definitely interested in thoughts from autograd folks (cc @albanD @soulitzer). A few points that I want to bring up:
(1) One reason that this API seems generally useful to me is because of the case where you torch.compile() a function, and you pass in two inputs that alias each other, and mutate one of the inputs. Autograd is forced to add a bunch of as_strided() calls into the graph when this happens, but this would give users an escape hatch for better compiled perf in this situation
(2) To be fair, AOT Autograd probably won't need this TLS in the long term. There's a better (more complicated) solution, where AOT Autograd manually precomputes the view chain off of graph intermediates during tracing, and re-applies them at runtime. This is kind of complicated though and feels lower priority to implement immediately.
(3) Given all of that I made the API private, but lmk what you all think.
This is a followup of pytorch/pytorch#92255.
Pull Request resolved: pytorch/pytorch#92588 Approved by: https://github.com/ezyang, https://github.com/albanD
kbuild: remove the target in signal traps when interrupted
BugLink: https://bugs.launchpad.net/bugs/1996812
[ Upstream commit a7f3257da8a86b96fb9bf1bba40ae0bbd7f1885a ]
When receiving some signal, GNU Make automatically deletes the target if it has already been changed by the interrupted recipe.
If the target is possibly incomplete due to interruption, it must be deleted so that it will be remade from scratch on the next run of make. Otherwise, the target would remain corrupted permanently because its timestamp had already been updated.
Thanks to this behavior of Make, you can stop the build any time by pressing Ctrl-C, and just run 'make' to resume it.
Kbuild also relies on this feature, but it is equivalently important for any build systems that make decisions based on timestamps (if you want to support Ctrl-C reliably).
However, this does not always work as claimed; Make immediately dies with Ctrl-C if its stderr goes into a pipe.
[Test Makefile]
foo:
echo hello > $@
sleep 3
echo world >> $@
[Test Result]
$ make # hit Ctrl-C
echo hello > foo
sleep 3
^Cmake: *** Deleting file 'foo'
make: *** [Makefile:3: foo] Interrupt
$ make 2>&1 | cat # hit Ctrl-C
echo hello > foo
sleep 3
^C$ # 'foo' is often left-over
The reason is because SIGINT is sent to the entire process group. In this example, SIGINT kills 'cat', and 'make' writes the message to the closed pipe, then dies with SIGPIPE before cleaning the target.
A typical bad scenario (as reported by 1, 2) is to save build log by using the 'tee' command:
$ make 2>&1 | tee log
This can be problematic for any build systems based on Make, so I hope it will be fixed in GNU Make. The maintainer of GNU Make stated this is a long-standing issue and difficult to fix 3. It has not been fixed yet as of writing.
So, we cannot rely on Make cleaning the target. We can do it by ourselves, in signal traps.
As far as I understand, Make takes care of SIGHUP, SIGINT, SIGQUIT, and SITERM for the target removal. I added the traps for them, and also for SIGPIPE just in case cmd_* rule prints something to stdout or stderr (but I did not observe an actual case where SIGPIPE was triggered).
[Note 1]
The trap handler might be worth explaining.
rm -f $@; trap - $(sig); kill -s $(sig) $$
This lets the shell kill itself by the signal it caught, so the parent process can tell the child has exited on the signal. Generally, this is a proper manner for handling signals, in case the calling program (like Bash) may monitor WIFSIGNALED() and WTERMSIG() for WCE although this may not be a big deal here because GNU Make handles SIGHUP, SIGINT, SIGQUIT in WUE and SIGTERM in IUE.
IUE - Immediate Unconditional Exit WUE - Wait and Unconditional Exit WCE - Wait and Cooperative Exit
For details, see "Proper handling of SIGINT/SIGQUIT" 4.
[Note 2]
Reverting 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files") would directly address 1, but it only saves if_changed_dep. As reported in 2, all commands that use redirection can potentially leave an empty (i.e. broken) target.
[Note 3]
Another (even safer) approach might be to always write to a temporary file, and rename it to $@ at the end of the recipe.
>
It would require a lot of Makefile changes, and result in ugly code, so I did not take it.
[Note 4]
A little more thoughts about a pattern rule with multiple targets (or a grouped target).
%.x %.y: %.z
<recipe>
When interrupted, GNU Make deletes both %.x and %.y, while this solution
only deletes
Fixes: 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files") Reported-by: Ingo Molnar [email protected] Reported-by: Rob Herring [email protected] Signed-off-by: Masahiro Yamada [email protected] Tested-by: Ingo Molnar [email protected] Reviewed-by: Nicolas Schier [email protected] Signed-off-by: Sasha Levin [email protected] Signed-off-by: Kamal Mostafa [email protected] Signed-off-by: Stefan Bader [email protected]
Jesus Christ I've deleted this code through the github windows shitty ui 3 times now I hate this bullshit FUCK
TCP: stricter registry management
ThreadSanitizer pointed at a potential data race between dnsio_tcp_request_threads_stop()'s access to thr->stop_watcher and the free(thr) that happens just before a tcp thread actually exits, and this commit "fixes" it by adding an unregister function and putting explicit locks around all related operations.
Technically, I don't think there was a real bug here that anyone could hit at runtime. There are logical constraints the sanitizer can't see: that the free() can only be reached during clean termination, which is triggered by request_threads_stop anyways, thus ensuring that the stop function's access to thr happens before (causes) the eventual free(), combined with the fact that the stop function is only called once from main().
But still: it's a bad smell and I'd rather just be over-cautious and future-proof, since adding these locks and calls doesn't harm anything in the perf-critical fast paths.
We already fixed the other side of this once (the sequencing at startup) in f5ea429ca a couple years ago, so it's not like there isn't potential for further bugs, especially if we make more TCP changes down the line and get confused.
[Side note - in general the current code isn't amenable to analysis with ThreadSanitizer, because TSan doesn't grok what we're doing with various lock-free mechanisms like our stats-gathering hacks and our liburcu data swaps + reclaims. However, I do have some prototype code which uses C11 atomics for the stats and swaps out userspace-rcu with a C11 atomics variant that's just for this kind of testing as well, which cleans things up well enough that TSan is no longer confused, so that I can use it to look for issues like this one. I think those bits will make it into 4.x, so that we can easily build a development copy of the code that's TSan friendly, but for now it's not easy to try TSan on the master branch for yourself because of all the RCU/stats false-positives]
waht does dis do skid code and take my company? FUCK YOU LOL
(hopefully) webedits a grammatical correction into headbite's kill message (#2537)
when someone dies to headbite it displays as
Urr Mot'herr has died to executed by headbite at the Containers from Elder Lurker (GIT-222)
hopefully with this simple one line webedit it should instead be
Urr Mot'herr has died to headbite execution at the Containers from Elder Lurker (GIT-222)
god fucking knows if this is the right line
uhm it reads better
Screenshots & Videos
github
🆑 spellcheck: 'executed by headbite' to 'headbite execution' when listing someone dying to a headbite in deadchat /🆑
Adds Ludicrously In-Depth Black Market to Recquisitions. (#2014)
VASTLY enhances the Black Market. Black market items are obtainable by deconstructing a supply computer and pulsing the circuit board. If you're knowledgeable in engineering enough.
Added a whole new category for black market items and thoroughly enhanced the possible contraband items to order. Guns, drugs, and worse are plentiful in stock...
Various valuable, rare, or otherwise interesting items now have a 'black market value' that allows them to be sent down the ASRS elevator in exchange for black market points to order various things with. Anything that's 'rare' is probably worth something. Added a scanner to the black market to let them detect said points.
Added DIALOGUE to the black market.
FIxed some construction wirecutter steps needing a screwdriver for some reason.
Changed up Req's mapping to add a hidden storage room.
slightly changed human remains' description
Added the maintenance jack, can be found in the black market for now.
Improved supply shuttle code somewhat.
VASTLY enhances the Black Market. Black market items are obtainable by deconstructing a supply computer and pulsing the circuit board. If you're knowledgeable in engineering enough.
Black Market is comically underused, by comically enhancing it like this it will freshen shipside roleplay and create new and interesting scenarios for MPs, req, and bystanders to interact with.
Added a whole new category for black market items and thoroughly enhanced the possible contraband items to order. Guns, drugs, and worse are plentiful in stock...
The contraband needs to be actually meaningful to the players for it to have any impact. The list of loot has been curated so that players will be intrigued, but will not be able to abuse it for too-stronger-than-usual gear without blatant drawbacks.
Various valuable, rare, or otherwise interesting items now have a 'black market value' that allows them to be sent down the ASRS elevator in exchange for black market points to order various things with. Added a scanner to the black market to let them detect said points.
This means CTs could go on scavenger hunts through the ship, evading curious MPs to sift through maintenance and various hidey holes scanning everything.
Added DIALOGUE to the black market.
Finally, we have dialogue in CM! The very first human NPC. We're ignoring WO because nobody likes WO.
FIxed some construction wirecutter steps needing a screwdriver for some reason.
Necessary in this PR to avoid stupid confusion when deconstructing the computers.
Changed up Req's mapping to add a hidden storage room.
To let CTs hide their goodies so they won't be in open sight. NOT DONE YET!
Screenshots & Videos
Put screenshots and videos here with an empty line between the
screenshots and the <details> tags.
🆑 add: VASTLY enhances the Black Market. Black market items are obtainable by deconstructing a supply computer and pulsing the circuit board. If you're knowledgeable in engineering enough. add: Added a whole new category for black market items and thoroughly enhanced the possible contraband items to order. Guns, drugs, and worse are plentiful in stock... add: Various valuable, rare, or otherwise interesting items now have a 'black market value' that allows them to be sent down the ASRS elevator in exchange for black market points to order various things with. Anything that's 'rare' is probably worth something. Added a scanner to the black market to let them detect said points. add: Added DIALOGUE to the black market. fix: FIxed some construction wirecutter steps needing a screwdriver for some reason. spellcheck: slightly changed human remains' description add: Added the maintenance jack, can be found in the black market for now. code: Improved supply shuttle code somewhat. /🆑
Co-authored-by: harryob [email protected] Co-authored-by: XSlayer300 [email protected] Co-authored-by: Segrain [email protected] Co-authored-by: Zonespace [email protected]
Create README.md
Crime is a very old concept which has moved on in society from generation to generation. Nobody is safe today. Criminals are employing scientific procedures to commit crimes as science and technology evolve, and authorities have been surprised by criminals' increased knowledge as society advances. Many crimes are perpetrated for the purpose of obtaining money or property wealth, with the most common being family feuds over property allocation. It is claimed to be a widespread societal issue that has an impact on not just a society's quality of life but also its economic progress. It is focused as major issue that has a direct impact on an individual's quality of life as well as indirect societal consequences. With the rapid increase of crimes and the types of crimes, researchers are finding a strong connection in the various features affecting the crime like the geographic features, age, gender and many more yet to come into picture. Despite the fact that crimes can happen anywhere, it is normal for criminals to focus their efforts on regions where they are most familiar and at ease. We seek to improve societal awareness by giving an advanced approach to identifying criminal hotspots and determining the nature, location, and time of crimes committed. Furthermore, having such a system in place would assist police in taking proactive actions in preventing and solving crimes at a far faster rate by allowing for crime prediction and prevention. Various types of crimes are discussed here and focus on their intensities in the highest city in the highest year is put forward with machine learning concepts for the societal and police benefits in solving the crime. These crimes are represented in different visualization techniques like bar graphs, pie charts to get a clear picture about the crime.
The above problem made me to go for a research about how can solving a crime case made easier. Through many documentation and cases, it came out that machine learning and data science can make the work easier and faster. The aim of this project is to make crime prediction using the features present in the dataset. The dataset is extracted from the official sites. With the help of machine learning algorithm, using python as core we can predict the type of crime which will occur in a particular area. The objective would be to train a model for prediction. The training would be done using the training data set which will be validated using the test dataset.
ABSTRACT
The project Criminal Record Management System is a Criminal record management system that uses to record crime activities of criminals. It can be used to report crime activities. This project is mainly useful for law and enforcement agencies. The law and enforcement authority can preserve records of the criminals and search any criminal using the system. This is an application with database system in which police will keep the record of criminals who have been arrested. We have used Python, Anaconda, Jupiter, MySql and Google colab to develop this project. We also used binary search algorithm to find a criminal from database. The project’s interface is very user friendly and helpful for authorities for easier and fast access of criminal records. The main objective of the project on "Criminal Database Management System" is to manage the detail of Case Id, Name, Age, Sex, Identification Mark, Crime Done, etc. It manages all the information criminal and their record.
PREDICTIVE MODELING Predictive modeling is the way of building a model that is capable of making predictions. The process includes a machine learning algorithm that learns certain properties from a training dataset in order to make those predictions. Pattern classification tasks can be divided into two parts, Supervised and unsupervised learning. In supervised learning, the class labels in the dataset, which is used to build the classification model, are known. In a supervised learning problem, we would know which training dataset has the particular output which will be used to train so that prediction can be made for unseen data.
DATA PREPROCESSING This process includes methods to remove any null values or infinite values which may affect the accuracy of the system. The main steps include Formatting, cleaning and sampling. Cleaning process is used for removal or fixing of some missing data there may be data that are incomplete. Sampling is the process where appropriate data are used which may reduce the running time for the algorithm. Using python, the preprocessing is done.
MODEL SELECTION Based on the defined goal(s) (supervised or unsupervised) we have to select one of or combinations of modeling techniques. Such as • KNN Classification • Logistic Regression • Decision Trees • Random Forest • Support Vector Machine (SVM) • Bayesian methods
IMPLEMENTATION
The dataset used in this project is taken from Kaggle.com. The dataset obtained from kaggle.com is maintained and updated by the Chicago police department. The implementation of this project is divided into following steps –
DATA COLLECTION Crime dataset from kaggle.com is used in CSV format.
DATA PREPROCESSING
10k entries are present in the dataset. The null values are removed using df = df.dropna() where df is the data frame. The categorical attributes (Location, Block, Crime Type, Community Area) are converted into numeric using Label Encoder. The date attribute is splitted into new attributes like month and hour which can be used as feature for the model.
FEATURE SELECTION
Features selection is done which can be used to build the model. The attributes used for feature selection are Block, Location, District, Community area, X coordinate , Y coordinate, Latitude , Longitude, Hour and month,
Gen 8 Battle Factory: Remove Darmanitan-Galar's Choice Band set (#9354)
- Gen 8 Battle Factory: Remove Band set from Ubers Darmanitan-Galar
Credentials: https://cdn.discordapp.com/attachments/1042959218208157696/1067534457160089731/image.png (i am "lost wind's elegy")
Darm-G's firepower is just fine with scarf; there aren't many (if any?) relevant 1hkos or 2hkos you miss out on compared to band. The only one I can think of is missing out on the OHKO vs Sp. Def Necrozma Dusk Mane, and nobody's leaving their NDM in anyway + you probably have like 12 other things to deal with it.
Without scarf, however, you miss out on really good source of offensive checking and revenge killing potential. Scarf outspeeds huge threats like non scarf Yveltal, Eternatus, Calyrex-Shadow, etc.
What sparks had to say about band darm in proper SS Ubers: sparks — Today at 1:53 PM not really but with band building needs to be more focused cos the speed over the 90s and etern etc is insane with scarf
sparks — Today at 1:54 PM while with band you're very much focused on "how to take out ndm and capitalize while not being weak to ho"
As a secondary factor, it would make Ubers in BF a lot better. Currently you have to not only win the coinflip of what move Darm clicks but also the coinflip of what item it is. Both of these are more or less up to random chance.
- Update data/mods/gen8/factory-sets.json
Co-authored-by: Kris Johnson [email protected]
Oneline the ability block numbers for creatures
Okay, there's a process here:
- Get the ability blocks into the format:
- Apply a couple seds to put it into correct table format
- Remove any of these stray fenced code blocks that are everywhere
This is the creatures version of #1 above, done as a proof of concept. I have already designed the s/// commands to do #2 but … let's get this far with the monsters first. Then I'll start writing the macros to fix the fenced code blocks. A few more commits to go and I'll push these out together.
I'm debating whether or not to squash them before I do. My sense is that I won't, and I'll explain why for anyone who stumbles across this commit log: This is a considerable amount of work! When some loser suit at WotC/Hasbro starts talking about how this game belongs to them, as if it was something they worked hard for and us "freeloaders" are just using for free like it was nothing … it isn't.
It would probably actually be easier to recreate the content than reformat theirs—but people value the promise they made that this stuff belonged to the world now and have depended on that to make the D&D ecosystem larger. Easy, huh?
Yeah, easy. I'ma make me a bandit:
Bandit
medium humanoid (any race), any non-lawful alignment
Armor Class: 12 (light armor)
HP: 9 (2d8)
Speed: 30ft
----------------------------
STR DEX CON INT WIS CHA
+1 +1 +1 -1 +0 +0
----------------------------
Senses: Passive perception 10
Languages: Native for background, at least some common typical
Challenge: 1/4 (50 xp)
Actions
Sword. +3 to hit, 5ft reach, hit: 6 (d6 + 3) slashing
Crossbow. (Ranged) +3 to hit, 60-300ft range,
hit: 7 (d8 +3) piercing
Knife. 3ft reach, hit 3 (d4 + 1) slashing/piercing
Bandits operate in bands that will raid or lie in ambush for
those with valuables to steal. They needn't be evil, since
desperation leads to desperate actions. Regardless of their
native language, they'll typically speak enough common to
communicate their demands. Banditry is a nervous profession
since any bandit taken into custody by local authorities faces
execution within 48 hours.
Good as the 5E bandit? Probably. I just designed common humanoid aiming for level zero and a half, fairly tough/fast, but not too bright, and armed well enough to be a threat to other common folk. Especially if faced with a band of bandits. And I came up with it in less time than it took me to look up the 5E stat block for such a creature.
But my bandit is gonna be different than yours, etc. The whole idea was that WotC put their bandit under a free license so we'd all agree to use that one, or something close to it. And in exchange for that they got to be the biggest game out there. If they want to give that up with 6E, it's their loss—but they can't take away 5E.
And that's why we're doing all this work.
Create Balloon Everywhere_gfg.cpp
Balloon Everywhere EasyAccuracy: 72.39%Submissions: 6K+Points: 2 Lamp Don't Miss Out on the Exciting World of Data Science and Unlock Your Full Potential Today. Try this course!
Bob is very fond of balloons. Once he visited an amusement park with his mother. The mother told Bob that she would buy him a balloon only if he answer her problem right. She gave Bob a string S [contains only lowercase characters] and asked him to use the characters of string to form as many instances of the word "balloon" as possible. Return the maximum number of instances that can be formed.
Help Bob to solve the problem.
Note: You can use each character in the string at most once.
Example 1:
Input: S: nlaebolko Output: 1 Explanation: Here, the number of occurence of 'b' = 1 of occurence of 'a' = 1 of occurence of 'l' = 2 of occurence of 'o' = 2 of occurence of 'n' = 1 So, we can form 1 "balloon" using the letters.
Example 2:
Input: S: loonbalxballpoon Output: 2 Explanation: Here, the number of occurence of 'b' = 2 of occurence of 'a' = 2 of occurence of 'l' = 4 of occurence of 'o' = 4 of occurence of 'n' = 2 So, we can form 2 "balloon" using the letters.
Your Task: The task is to complete the function maxInstance() which takes a string as the only input parameter and should return the maximum instances that can be formed of the word "balloon" using the given string.
Expected Time Complexity: O(n), n is size of the given string. Expected Auxiliary Space: O(26).
Constraints: 1 <= s.length <= 106 https://practice.geeksforgeeks.org/problems/45fa306a9116332ece4cecdaedf50f140bd252d4/1
Setting Guide for G4 My Little Pony's Equestria
A full setting guide for the universe of My Little Pony Friendship is Magic. Trying to blend show accuracy and tone with 5e's general heroic fantasy vibes, I've been maintaining this guide since I created it in 2016. Contains Races, Feats, Subclasses, Spells, Items mundane and magical, Religions, and more.
README insights 80smusic WorldMusic absolutelyproductions adifferentspin afrobashment afrobeat afrofuturism ambientmusic arabicmusic arcology artisanvideos asmrmusic ausmusic aussiehiphop australianmusic australianpsychrock azerbaijanimusic balkanmusic banglamusic bilingualporn bleachedir bollywoodmusic bossanova brazilianmusic breakbeat canadianmusic celticmusic chansonfrancaise chinafuturism chinesemusic classy_asses crazyfuckingvideos damnthatsinteresting darksideplayground deepintoyoutube densegifs dirtytalk_spanish documentaries educationalgifs fetishjav fmrp forbiddencarejav fullforeignmovies fullmoviesonyoutube funnyjav futureporn gifsthatkeepongiving gonewildaudible gonewildaudio gonewildtube hapanal happycrowds homemadexxx illbeyourguide ilovejav imaginaryfeels imaginarysliceoflife imaginarytechnology interdimensionalcable interestingasfuck japaneseasmr japanesegameshows japanesekissing japaneserimming jav_gifs jav_nsfw javboratory javengsub javforscience javlovers javsubtitle javuncensored kinkypillowtalkaudio lectures mealtimevideos mechanical_gifs menintroublejav neverchangejapan nonenglishporn nottimanderic nsfwasmr obscuremedia outstruments petitejav pillowtalkaudio playitagainsam praisethecameraman qualityyoutube rakugo recut retroeducationalfilms retrofuturism sensualasmr sexwithmixedgirls sexyaccents sf_videos shewantstofuck shittyrobots shortfilm shortfilms silentcinema throughtheboxers tiktokcringe tiktokorchestra timestopjav u_Frogacuda unbgbbiivchidctiicbg unintentionalasmr unknownvideos unusualinstruments vanillaaudio videoessay whyweretheyfilming wmafblowjobs woahdude youboobers youtubetitties
Handle frenemies dead round update calling cheaters
There is a very peculiar issue with the migration. Really weird one.
Look at the transactions. https://explorer.sui.io/object/0x7c901b42a5ffcd22e057e66e42b7c25002b44f4e An account cheated by calling update via RPC during frenemies downtime. 73 scores a huge advantage! They could do it probably because their name is so short. So, it didn't cause overflow.
Sorry, I'm from the phone and did not test it. But, the issue seems to be real and dangerous and needs to be fixed. Probably you would not do it so radically like I did, just stopping the person from getting any more scores.
Perhaps you would just prefer to subtract the unfair advantage, gained during dead round, which might be huge. It might be life or death situation where someone gets pushed out of 2000 by a cheater.
Fuck this Json type.
Cargo cannot find this Struct in scope. FUCK IT. I REALLY LOVE THIS LANGUAGE BUT THIS SHIT...
Touch Rehash + Legacy Parity
Doing a side-by-side check with both the usability/user experience and code itself of the legacy version, from the legacy-types tag.
Discovered some missing touch input handling logic, which I hadn't rewritten yet as part of the full rework. Now I remember choosing to do that later, once I had everything working again. Makes sense now!
Going to work on the Shortcuts parts, coming up. Having modules is going to make that so much easier, so relieved I have that, and TypeScript!
Seeing a lot of parts of the code that can be restructured, now that I know how everything works again, so that will be coming up soon, too. Essentially, everything has been nearly repackaged into the new component structures (not a single, big honkin thing), so now it's safer to edit things, since they all have dedicated places for each implementation detail. TypeScript is great for this, too!
I tried adding a local, more-advanced type definition for PointerEvent.pointerType to be "mouse" | "pen" | "touch", just like it says on MDN, but it didn't like me trying to override an already defined property with a narrower type. maagh. There might be a way to override it using a different file, and adding it to the tsconfig, but I didn't look too far into it since it's mostly just a bonus little feature for me.
I wish other browsers did what Chromium does, and has pointerType present on the ancestor MouseEvent class, as that's what's been causing this whole debockle. It works great to check the pointerType within the click event, but only Chromium has support for that, so I had to make my own workaround to get the same information into the event logic. also a meegh.
Added a style hook by matching the [open] attribute on the host <menu-drop> element, so you can style things based on the root element, a nice and simple selector! menu-drop[open].
Latest news on the laptop upgrade plan: Was gonna go with the M2 Macbook Air, 512 GB, 16 GB SSD. Read more reviews, and it sounded like it was a generally lukewarm response compared to the M1 Air. Looked into the same specs for the M1 Air, and it was a much better price! Then I found that the refurbished M1 Pro MB Pro was exactly the same price as a new M2 Air (a hair lower, actually!), with those specs, and you get all of the other great stuff that comes with the Pro. Better chip, screen, screen size, 120Hz, ports, just wow. Then I watched some more videos about the reviews for that, specific to programmers. One YouTuber made a great argument that you don't need to have great hardware to do cool things. You should be doing cool things before you upgrade to fancier tech. You don't want to break the bank before you have better ideas for what your plans are down the line. That swayed me to feel like I should just wait to upgrade until later, when it's more obvious what I should get. I also thought, that if it's been this challenging of a decision for this long now, maybe I'm just not ready for upgrading big like that, maybe that's just a sign for that. Mentioned that to my family, and they think I should upgrade though, so that makes me feel a bit stronger about it. I just don't want to upgrade because I want to, but because I need to. I don't want to change things up just because. As my friends and I were saying, if it ain't broke, don't upgrade! haha. Been doing all of my coding on my Ubuntubook for ages now, and I am still blown away with how durable he's been! great lil dude. Only rockin' 16 GB eMMC, and 4 GB RAM. And I read today that the display has only been able to show 72% of the sRGB spectrum this whole time LOL. No wonder it's not looked the best. It does look great, nice and crisp to read code on though. Not the best of approach angles though, haha. The screen turns to differnt colors when looking from across the room. Night shift essentially looks orange. Framework is still in my interest too. I really like the idea of consolidating my workspace into a single computer though, even if I store some of my data on external drives, to help manage the internal disk space. Being able to have my music library, code, and game on the same machine, reliably, has been less so for me for the last while. My iMac can do that, but it's been harder to work with consistently. I think I've mentioned that already at some point (not waking from sleep). Oh yeah, having my iPhone backups on there too, easy to do everything from one place, at least from a software perspective.
Either Asahi Linux or a UTM Ubuntu VM on Apple Silicon is also part of my dream, that would be the ideal setup to move from my Chromebook over to a MacBook. I will likely move to plain macOS with time, but I really do love working with Linux as of now, and there's more I want to explore with that. Living in the terminal is great.
[FIX] website: redirect to case insensitive URL if not exact match
Before this commit, if a link to a page was not correct because of a case mismatch, it would simply land on a 404 page. While it's correct, as URL are case sensitive, it leads to a few bad UX flow at the admin/editor level:
- Create a link in your page (on a text or a button eg), type an URL which does not exists (to create it after) like /Page
- Click on the link/button you just made, you are redirected to /Page which display a 404 with the "Create page" option (correct)
- When you click on that button, it will actually create a page with /page URL, leading to a mismatch between the URL you created and the page URL. Your link/button will still lead to a 404 URL as it points to /Page.
Since it's just a fallback when an exact URL match is not found, it should not break anything and should not have bad impact at any level (seo/speed etc). Indeed:
- It's done through a 302 redirect
_serve_page()is already a fallback case, so it will only make thewebsite.redirectand 404 cases a bit slower due to the extra search query.
The only possible scenario seems to be if the user (mind the uppercase):
- Created a /Page page
- Created a redirect from /page to /another-page
In this case, /page won't land on /another-page but on /Page. This flow seems unlikely and is not actually wrong either way. At least, it certainly is less important than ensuring a case insensitive fallback.
Finally, note that another solution would have been to either:
- Force page URL to lower case.
-> This is not stable friendly, people might be relying on this to
create pages with different casing:
/Batman-VII-The-Dark-Knight-Whatevers, while not recommended, doesn't sounds idiot. On top of not being stable friendly, we probably want to keep offering this possibility - Redirect all URLs to lowercase endpoints. -> This is obviously not stable and not Odoo's jobs. It should be something decided by the sysadmin and done at nginx (etc) level.
task-3110294 opw-3104030
closes odoo/odoo#111523
X-original-commit: 8f24aba86faf2639109b56887781b0daaf60be98 Signed-off-by: Quentin Smetz (qsm) [email protected] Signed-off-by: Romain Derie (rde) [email protected]
[MIRROR] Rebuilds Luxury Shuttle (mostly), makes it emag-only [MDB IGNORE] (#19229)
- Rebuilds Luxury Shuttle (mostly), makes it emag-only (#72940)
Changes the really goofy old lux shuttle to a cooler layout with some
additions to make it a luxury and not just
"anti-poor-people protection + food"
Shuttle was made bigger to make it less cramped for the luxury class, pool was moved to its own room, added an arcade and a bar corner, has real lasers to shoot poors with (20c each shot), has fire extinguishers now Adds a new preopen variant of hardened shutters Adds a paywall pin subtype for the luxury shuttle, and a laser gun subtype
Made emag-only at a price of 10000 credits
The old luxury shuttle looked REALLY awful with its pool, was pretty cramped even in the luxury section and BARELY resembled a luxury.. This luxury shuttle provides luxuries such as a less poorly designed pool, more space for legs, arcade, to make it resemble a luxury unlike the old one
🆑 add: Luxury Shuttle is now bigger, and less ugly! Poor people still get it rough though... /🆑
- Rebuilds Luxury Shuttle (mostly), makes it emag-only
Co-authored-by: jimmyl [email protected]
Tramstation: Growing Pains (#72331)
Lots of QoL and structural changes in attempt to make the cool map even cooler.
🆑 MMMiracles add: Tramstation has received a substantial overhaul! Please consult your local tour guide and station maps for changes. /🆑
Changes (as of so far)
- The Tramstation tunnels have been extended 6 tiles each way, making that trek across the central rail a little more dangerous.
- No more mid-way safety net on the transit rails. You're either making it or you're jumping to the bottom floor to avoid the tram.
- The central rail apparently had a negative slowdown, meaning you actually WERE faster to just run the gauntlet because it literally made you faster. This has been reverted because I want you to get hit by a train.
- The side routes are now a bit more dangerous since you can get pushed off into the lower floor
- Fauna overhaul! Several locations including the transit tunnels have gotten some greenery to help liven up transit between sectors. Please do not rip up the AstroTurf it is very expensive in space.
- Handicap-accessible departments! Every major wing and departments with multiple floors has been given a 2x3 elevator segment for those among the crew who have been hit by the tram a few too many times. Handicap inaccessible staircases may or may not come after this (i hate the handicapped)
- Expanded Security wing! You know that lame hallway between interrogation and the courtroom access? Now its a whole holding wing fit with essentials to keep your inmates content while waiting for their due process (never ever).
- Reworked Bridge! Front row seats to the western tram dock as well as a furnished meeting room with various corporate memorabilia!
- The HoP's office has been moved to function more as an arrival gate for late joining crew! Scenic queue lines and an option to block off the lower dorm access if you really want to enforce the 'Papers, Please' roleplay you've always wanted out of your HoP experience.
- Combined the teleporter/gateway/eva access into one special external operations room. All you off-station needs in one convenient place!
- More multi-z integration! Several segments (mainly maintenance level transfers) have been given overhangs and better methods to move between levels. This is still being expanded upon as of current PR posting.
- The power/pipe access shafts have been changed to be more public-facing and now also act as another inbetween for maintenance-dwelling crew to shift between floors.
- Multi-z solars! Both solar wings have been extensively overhauled to include multi-z structuring and easily doubled the amount of roundstart panels on the map.
- Escape pod bay! Casually borrowing from a certain ship map, there is now a centralized location for all station escape pods on the floor below Arrivals. Honestly makes more sense thematically instead of having a bunch of scattered bays.
- MULEBOT integration! Each major department now has delivery drop-off points along with Cargo getting a minor restructuring to fit 4 MULEBOTs. Seedy side-tunnels and drop points have been added for departments that aren't normally accessible from upper maintenance so they can still properly deliver cargo if sent this way. I can't guarantee this won't end in MULEBOTs getting ran over by a tram because they're fickle beasts.
- Complete rework of the disposals/piping/wirenet! I literally ripped everything up and rebuilt it with (hopefully) better stability in mind. Disposals is now also set up in that it'll try to avoid going through departments unnecessarily if your package isn't marked for it.
- Cargo's mail room and trash room has been overhauled to be more easily accessed for cargo techs and for routing mail.
- The chef has access to the morgue's back door via the front maintenance hatch while Robotics can now access the same back door via their maintenance shaft.
- The chem lab's starting area has been expanded so chemists don't have to worry as much about digging if they don't have large projects.
Fixes all antag datum moodlets being removed when any single antag datum is removed (#73305)
All antag datums operated under the antag_moodlet mood category, which
is clearly an issue when you can (and commonly) have multiple antag
datums of different types on your mob.
New antag datums of different type will now no longer override older antag datum moodlets, now they will stack. This means traitor revolutionaries are the most zealous folk on the station.
This has a few potential oversights down the line:
- Someone adds an antag datum players can have duplicates of, and also has a moodlet associated
- Re-used moodlets in antag datums that can easily be stacked will be noticed
- Most solo antags used
focusedright now, but none can stack outside of admemes
But I don't think it's an issue for now.
Prevents a quick revolution from stripping you of your joy.
Fixes #67313
🆑 Melbert fix: Revolutionary Heretics and Cultists Traitors no longer lose all of their joy in life after being de-converted from their respective causes. /🆑
sched/core: Fix ttwu() race
Paul reported rcutorture occasionally hitting a NULL deref:
sched_ttwu_pending() ttwu_do_wakeup() check_preempt_curr() := check_preempt_wakeup() find_matching_se() is_same_group() if (se->cfs_rq == pse->cfs_rq) <-- BOOM
Debugging showed that this only appears to happen when we take the new code-path from commit:
2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is descheduling")
and only when @cpu == smp_processor_id(). Something which should not be possible, because p->on_cpu can only be true for remote tasks. Similarly, without the new code-path from commit:
c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu")
this would've unconditionally hit:
smp_cond_load_acquire(&p->on_cpu, !VAL);
and if: 'cpu == smp_processor_id() && p->on_cpu' is possible, this would result in an instant live-lock (with IRQs disabled), something that hasn't been reported.
The NULL deref can be explained however if the task_cpu(p) load at the beginning of try_to_wake_up() returns an old value, and this old value happens to be smp_processor_id(). Further assume that the p->on_cpu load accurately returns 1, it really is still running, just not here.
Then, when we enqueue the task locally, we can crash in exactly the observed manner because p->se.cfs_rq != rq->cfs_rq, because p's cfs_rq is from the wrong CPU, therefore we'll iterate into the non-existant parents and NULL deref.
The closest semi-plausible scenario I've managed to contrive is somewhat elaborate (then again, actual reproduction takes many CPU hours of rcutorture, so it can't be anything obvious):
X->cpu = 1
rq(1)->curr = X
CPU0 CPU1 CPU2
// switch away from X
LOCK rq(1)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 9
switch_to(Z)
X->on_cpu = 0
UNLOCK rq(1)->lock
// migrate X to cpu 0
LOCK rq(1)->lock
dequeue_task(X)
set_task_cpu(X, 0)
X->cpu = 0
UNLOCK rq(1)->lock
LOCK rq(0)->lock
enqueue_task(X)
X->on_rq = 1
UNLOCK rq(0)->lock
// switch to X
LOCK rq(0)->lock
smp_mb__after_spinlock
switch_to(X)
X->on_cpu = 1
UNLOCK rq(0)->lock
// X goes sleep
X->state = TASK_UNINTERRUPTIBLE
smp_mb(); // wake X
ttwu()
LOCK X->pi_lock
smp_mb__after_spinlock
if (p->state)
cpu = X->cpu; // =? 1
smp_rmb()
// X calls schedule()
LOCK rq(0)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 0
if (p->on_rq)
smp_rmb();
if (p->on_cpu && ttwu_queue_wakelist(..)) [*]
smp_cond_load_acquire(&p->on_cpu, !VAL)
cpu = select_task_rq(X, X->wake_cpu, ...)
if (X->cpu != cpu)
switch_to(Y)
X->on_cpu = 0
UNLOCK rq(0)->lock
However I'm having trouble convincing myself that's actually possible on x86_64 -- after all, every LOCK implies an smp_mb() there, so if ttwu observes ->state != RUNNING, it must also observe ->cpu != 1.
(Most of the previous ttwu() races were found on very large PowerPC)
Nevertheless, this fully explains the observed failure case.
Fix it by ordering the task_cpu(p) load after the p->on_cpu load, which is easy since nothing actually uses @cpu before this.
Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") Reported-by: Paul E. McKenney [email protected] Tested-by: Paul E. McKenney [email protected] Signed-off-by: Peter Zijlstra (Intel) [email protected] Signed-off-by: Ingo Molnar [email protected] Link: https://lkml.kernel.org/r/[email protected] Change-Id: I40e0e01946eadb1701a4d06758e434591e5a5c92
initial git repository commit
.gitignore removed Fuck you too git and git kraken
1)Testing the api controller was a pain in the ass, with the redis-om library. (the components wehre not properly initialised during the test period, specifically a document template could not be found, but actually building it was in conflict with the existing template that is normally loading during build. (fuck) Moved it to a different project "WebDriverTesting", where I will do all integration test. Unit tests should still be performed in this project.
2)Added bootstrap template to thymeleaf and started using fragments to show a sidebar
more span macro changes in brain traumas and disease files (#73273)
i was fucking around with brain traumas on a downstream and noticed they had similar issues to quirks so i decided to continue work from #73116
(search in VSC for span class = 'notice')
its going to be a bit of a thing to get all of these but this is a
decent chunk i think
there was only one annoying/tough file. imaginary_friend.dm had class = 'game say' and class = 'emote' both of which after some testing did not seem like they did anything. ill try to keep that in mind in other files if i continue to do this but i either omitted them because they didnt have any formatting or, in the case of emote, turned it into name, which i think is what you'd want those messages to look like.
there were also a few small spelling errors that i fixed
more consistent and stops people from copying brain trauma formatting wrong
they should all work the same
Co-authored-by: san7890 [email protected]
ZEN: Implement zen-tune v4.12
4.9: In a surprising turn of events, while benchmarking and testing hierarchical scheduling with BFQ + writeback throttling, it turns out that raising the number of requests in queue actually improves responsiveness and completely eliminates the random stalls that would normally occur without hierarchical scheduling.
To make this test more intense, I used the following test:
Rotational disk1: rsync -a /source/of/data /target/to/disk1 Rotational disk2: rsync -a /source/of/data /target/to/disk2
And periodically attempted to write super fast with: dd if=/dev/zero of=/target/to/disk1/block bs=4096
This wrote 10gb incredibly fast to writeback and I encountered zero stalls through this entire test of 10-15 minutes.
My suspicion is that with cgroups, BFQ is more able to properly sort among multiple drives, reducing the chance of a starved process. This plus writeback throttling completely eliminate any outstanding bugs with high writeback ratios, letting the user enjoy low latency writes (application thinks they're already done), and super high throughput due to batched writes in writeback.
Please note however, without the following configuration, I cannot guarantee you will not get stalls:
CONFIG_BLK_CGROUP=y CONFIG_CGROUP_WRITEBACK=y CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_IOSCHED_BFQ=y CONFIG_BFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_BFQ=y CONFIG_SCSI_MQ_DEFAULT=n
Special thanks to h2, author of smxi and inxi, for providing evidence that a configuration specific to Debian did not cause stalls found the Liquorix kernels under heavy IO load. This specific configuration turned out to be hierarchical scheduling on CFQ (thus, BFQ as well).
4.10: During some personal testing with the Dolphin emulator, MuQSS has serious problems scaling its frequencies causing poor performance where boosting the CPU frequencies would have fixed them. Reducing the up_threshold to 45 with MuQSS appears to fix the issue, letting the introduction to "Star Wars: Rogue Leader" run at 100% speed versus about 80% on my test system.
Also, lets refactor the definitions and include some indentation to help the reader discern what the scope of all the macros are.
4.11: Increase MICRO_FREQUENCY_UP_THRESHOLD from 95 to 85 Increase MIN_FREQUENCY_UP_THRESHOLD from 11 to 6
These changes should help make using CFS feel a bit more responsive when working with mostly idle workloads, browsing the web, scrolling through text, etc.
Increasing the minimum frequency up threshold to 6% may be too aggressive though. Will revert this setting if it causes significant battery drain.
4.12: Make bfq the default MQ scheduler
Reduce default sampling down factor from 10 to 1
With the world eventually moving to a more laptop heavy configuration, it's getting more important that we can reduce our frequencies quickly after performing work. This is normal with a ton of background processes that need to perform burst work then sleep.
Since this doesn't really impact performance too much, lets not keep it part of ZEN_INTERACTIVE.
Some time ago, the minimum frequency up threshold was set to 1 by default, but the zen configuration was never updated to take advantage of it.
Remove custom MIN_FREQUENCY_UP_THRESHOLD for MuQSS / ZEN_INTERACTIVE configurations and make 1 the default for all choices.
Change-Id: I2a31fbc97fe12ffce30457ec2e83ed25764e2daf Signed-off-by: Harsh Shandilya [email protected]
feat: continue adding to Lua port
Yeah, this is a horrible mixed-bag commit. Just showing that we can compile multiple translation units in a single invocation (may want to refactor the Makefile to do that a little more traditionally, to be honest; compile each source individually, then link... but then again, this is simple and the project is tiny so speed is not a concern).
PMC and Whiteout stuff (#1966)
As a preword, I came up with every change in this PR and coded them in the span of 10 hours, so some things may be iffy.
PMCs and Whiteout may be good, but they're a bit outdated, this modernizes multiple loadout aspects, enables antag vendors for admin-spawn, and does some balance changes to certain portions(specifically chem ERT).
Individual changes, numbered, will go over each in why its good, may have forgotten one or two things.
- Buffs whiteout flamer with blue flame damage, belt-linked magharn, and pyro underbarrel extinguisher
- Adds a synthetic repair kit(medkit), with synth repair tools, gives it to whiteout.
- Adds breaching charges and swaps crowbars to tactical in whiteout loadouts
- Gives whiteout PMC sniper goggles(thermals)
- Gives whiteout medic the required gear to actually repair a downed member of the team, and just a lot of synth heals.
- Gives whiteout leader a pyro extinguisher.
- Gives whiteout weapons default attachments.
- Adds an 'advanced' mini-flamer with the same stats as UPP integrated UBF, gives it to NSG23 and random m41/2 attachie.
- Gives detainer PMCs a version of the corporate m41A MK2(goon gun), with attachies and adv flamer to replace flamethrower.
- Swaps chem PMC TL P90(name is too long) with an M41/2
- Gives normal PMC ERT roles a webbing vest with meds and miniextinguisher
- Gives PMC Surgeon the essentials required to act as a medic, swaps NSG with M39/2, gives them a normal but unique look.
- Whiteout and PMC SG powerpacks have 30k power by default, instead of 10k.
- Gives PMC guns more options for random attachments, and gives m41/2 its intended collapsible stock
- Gives PMC engi m39/2 instead of P90
- Removes flamer from potential PMC loadouts.
- Gives PMCs better CQC skill.
- Gives PMC TLs autoinjector pouches(which gives chem TL a second pouch in the first place)
- Detainer PMCs now have tac-sechuds, PMC TLs have sensorhuds.
- Enables antag vendor for PMC roles. (Look at file changes for the specific things, too long for pr desc)
Modernization and some needed loadout/balance changes(IMO). Per number:
- Whiteout flamer did worse damage than napalm, and was incredibly easy to lose.
- More heals for each member of the whiteout team, allows more self-sufficiency.
- Breach charges for tacticool breaches, crowbar doubles as a melee weapon in case the player doesn't know about synth punch
- Whiteout didn't have proper NVG, thermals allows them to do tacticooler breaches by lining up people wth breach charge.
- Whiteout medic didn't have a lot of heals at all, and didn't have a defib, so they weren't much of a medic.
- To extinguish the flames and lead charges, works like pyro underbarrel extinguisher, but handheld.
- Default tacticool attachment, already made whiteout subtypes for HEAP, why not give them good attachies with them too.
- Mini-flamer sucks, gives a better version for NSG and m41/2, same stats as the already existing UPP integrated UBF.
- Detainers had flamers which sucked, gives them corpo m41s which aren't as good as /2s, but have adv UBF for flames.
- P90 sucks, having default m41/2 fits with other leader type, also gives them a better gun than their underlings.
- Medkit but in a webbing, its my personal combat webbing load when I play so its good.
- PMC Surgeon was horrifically undergeared, they didn't even have a medhud, gives them basic gear similar to PMC med but with a beret to tell them apart.
- ERTs don't have spare batteries to get usually, more staying power in fights.
- More options for attachies to further make PMC weapons better, also gives m41/2 the m41 collapsible stock because it needed it.
- P90 sucks, support roles getting the m39/2 is cool.
- Flamer sucks to get as PMC, and adv. UBF as a potential m41/2 attachie makes a full-sized flamer useless too.
- PMCs could fireman carry, and multi-strip, but did it horrifically slow, gives them MP level CQC(master for spec, expert for TL)
- TL getting extra meds is neat, also chem TL had an empty pocket slot and no meds, thats bad.
- Sechud-thing for PMC detainers is useful(stops flashbang trolling for one), giving PMC TL a sensorhud to watch their team's status is also good.
- Makes doing event bases for PMCs much easier, too long to post the specific changes here but look at files for them.
I forgot to take screenshots but it all works. 👍 I spawned myself as every changed role and tested every individual change extensively.
🆑 add: PMCs are now able to use antag vendors. balance: Multiple loadout and skill changes to PMCs and Whiteout balance: Buffs whiteout flame damage to blue flame damage. fix: PMC Investigator Lead now appropriately spawns with a medical pouch in their pocket, instead of nothing. fix: Maximum skill preset now appropriately also has BE and intel skill, at maximum of course. fix: PMC Smartgunner now appropriately a VP78 to go along with their VP78 magazines fix: Whiteout now appropriately have night vision. fix: M41A/2 now appropriately comes equipped with a collapsible stock. spellcheck: PMC smartgun drum now has a seperate description and name from base SG to match its different appearance. /🆑
core: merge reserved_ports into host_networks (#13651)
Fixes #13505
This fixes #13505 by treating reserved_ports like we treat a lot of jobspec settings: merging settings from more global stanzas (client.reserved.reserved_ports) "down" into more specific stanzas (client.host_networks[].reserved_ports).
As discussed in #13505 there are other options, and since it's totally broken right now we have some flexibility:
Treat overlapping reserved_ports on addresses as invalid and refuse to start agents. However, I'm not sure there's a cohesive model we want to publish right now since so much 0.9-0.12 compat code still exists! We would have to explain to folks that if their -network-interface and host_network addresses overlapped, they could only specify reserved_ports in one place or the other?! It gets ugly. Use the global client.reserved.reserved_ports value as the default and treat host_network[].reserverd_ports as overrides. My first suggestion in the issue, but @groggemans made me realize the addresses on the agent's interface (as configured by -network-interface) may overlap with host_networks, so you'd need to remove the global reserved_ports from addresses shared with a shared network?! This seemed really confusing and subtle for users to me. So I think "merging down" creates the most expressive yet understandable approach. I've played around with it a bit, and it doesn't seem too surprising. The only frustrating part is how difficult it is to observe the available addresses and ports on a node! However that's a job for another PR.
allow getting format_instructions from agent_path (#968)
In real-life scenarios, we do indeed need to make slight adjustments to the text of "format_instructions", making the user experience friendlier and more closely aligned with specific scenarios.
CF-1121 Update Magic Weather for BC5 / SDK V6 (#768)
- If applicable, unit tests
- If applicable, create follow-up issues for
purchases-iosand hybrids
- Migrated from SDK
5.0.0to6.0.0-alpha.2 - Changes to
PaywallAdapterto make paywall show more useful information to user- Duration (gross code)
- Multiple offers (and "best offer" first)
- Pricing phases (gross looking now but will improve later)
- Works for both subscriptions and one-time purchases
The initial migration (with only necessary code changes to compile) made for a very confusing paywall 👇
- The subscriptions relied on the product title (which is the same for each base plan)
- Did not include the duration so user had no idea what they were buying
- This is because these were previously in the individual subscription titles for BC4
- It did use the default/best offer which was nice but didn't explain any offer info
Big rework to programmatically show as much info as we could (even though it is kind of ugly UI right now) 👇
- Shows all the options for each subscription with "best offer" on top
- This might be overkill because why not just choose the best offer but wanted to show this as example 🤷♂️
- Shows the pricing phases that come with each option
- Needed very different logic for subscriptions vs one-time purchases
- This is because one-time purchases contain all the data in the
StoreProduct - Where subscriptions contain all needed data in
SubscriptionOptionandPricingPhases
Screen.Recording.2023-02-02.at.5.11.33.AM.mov
Removes skull balaclava and skull facepaint from loadout, places them hidden on the Almayer. (#2526)
This removes the skull balaclavas and the facepaints from the loadout menu and instead places them in 2 places hidden around the Almayer. The reason I have done this is that they are almost exclusively used by people who who are referencing a character- usually Ghost from MW2 (either version) or the characters from COD Ghosts. See below for more details.
This is an OOC meme item that doesn't fit the tone of CM, particularly because we already have an item with a skull on it in case you want to use it: Armor! They wrote things on armor in the movie, including a skull!
Instead, we have these types of people, running a skull 'clava in every round even as command or medical characters. This is a modern 'operator' look, not a Space 'Nam-esque look and not an Aliens look. If you want something that'd remind you of Space 'nam, just look at the classic 'born to kill' helmet. Now, look at these CALL OF DUTY CHARACTERS THAT THIS ITEM REFERENCES!
This is goofy as hell and kind of an outlier among the customization options since it is very clearly a reference to COD. Look at its description:
"The face of your nightmares. Heed the call of duty as the ghost in the night with this metal 'clava. Additionally protects against the cold. Now in black!"
You'd get laughed off a real marine base for wearing this, let alone wearing one on an op. We don't need more people running this every round, and this gives them something to fight over between eachother- if you want to larp as Simon 'Ghost' Riley from hit video game COD MW2 (either version) then you'll have to hunt it down.
Screenshots & Videos
Put screenshots and videos here with an empty line between the
screenshots and the <details> tags.
🆑 del: Removed skull balaclavas and skull facepaint from the loadout options maptweak: adds a single skull facepaint and balaclava, each hidden in their own locations on the Almayer. /🆑
Removes Autodocs from the Almayer (#2607)
Removes autodocs from medbay. They're replaced with 2 random potted plants. :)
EDIT: Tomorrow I will update this PR to give nurses surgery skill.
Autodocs fundamentally and inseparably, irrevocably, DESTROY medbay and surgery gameplay. There is NO REASON, EVER to put someone through manual surgery when you could just haha autodoc them instead. Autodocs kill the good old hell medbay lines, they make surgeons extremely lazy and stagnant (Tales of surgeons doing surgery for a few minutes, then giving up and autodoccing the patient are common, not to mention the times where they miss something in the autodoc schedule), they remove all skill depth, floor, ceiling, the middle from medbay, and they also make marines complacent by having them want the funny magic robot machine rather than an actual human to treat them.
I understand that this may be too sudden of a change. If so, I propose the following: Cryo tubes could slowly heal a marine up entirely, removing organ damage and bone breaks through the course of a very slow 5-10 minutes. This will allow marines and nurses to get treated if there's no doctor around or alive. However, I think the best course of action is to just ram this change through and make medbay adapt. Embrace the suck.
Screenshots & Videos
Put screenshots and videos here with an empty line between the
screenshots and the <details> tags.
🆑 balance: Removes Autodocs from the Almayer /🆑
Proposed changed for Sida's profile
layout: profile title: "Sida Lillian" image: "assets/images/profiles/Sida-Lillian/Sida-Lillian.jpg" country: Uganda region: West Nile hub: CC4D languages: "English (Fluent spoken and written), Bari/Kakwa (Fluent spoken and spoken), Arabic (good spoken only), Lugbara (fair spoken only)" mail: [email protected] phone: "+256782739162" whatsapp: website: telegram: "+256782739162" github: github.com/sidalillian linkedin: twitter: facebook: https://www.facebook.com/profile.php?id=100074066215635 instagram: mastodon: wikifab: skills:
- {name: Web & Software, number: 1, qualification: "using platforms, basic social media experiences, software download and installation \n \n
- {name: Community & Moderation, number: 2, qualification: "connecting people, trauma healing, event facilitation and meditation \n \n
- Certificate of participation in trauma healing& meditation training \n
- She was trained and facilitated a post training on how to use Condoms under the #ASKnet project 2018"}
- {name: Data Security & Research, number: 3, qualification: "data collection and protection of personal data \n \n
- Certificate in data collection"}
Sida Lilian is a female South Sudanese refugee in Uganda.
Expert in data collection, trauma healing, mediation, event facilitation of different types.
She was trained on how to collect both qualitative and quantitative data by REACH Uganda, Danish Refugee Council, Norwegian Refugee Council Uganda and GROUND TRUTH SOLUTIONS, she was also trained and worked as frontline worker on the *BOOST FOR THE YOUNGEST by Save The Children under Dubai Cara not only that she was also trained on Social Enterprise online by Makerere University - Canada in 2018, she was trained and worked as hygiene Promoter by CEFORD Uganda and was also trained and worked as Community Development Worker (CDW) by Danish Refugee Council.
She is confident, talented and determined to transform her community.
cocci: make "coccicheck" rule incremental
Optimize the very slow "coccicheck" target to take advantage of incremental rebuilding, and fix outstanding dependency problems with the existing rule.
The rule is now faster both on the initial run as we can make better use of GNU make's parallelism than the old ad-hoc combination of make's parallelism combined with $(SPATCH_BATCH_SIZE) and/or the "--jobs" argument to "spatch(1)".
It also makes us much faster when incrementally building, it's now viable to "make coccicheck" as topic branches are merged down.
The rule didn't use FORCE (or its equivalents) before, so a:
make coccicheck
make coccicheck
Would report nothing to do on the second iteration. But all of our patch output depended on all $(COCCI_SOURCES) files, therefore e.g.:
make -W grep.c coccicheck
Would do a full re-run, i.e. a a change in a single file would force us to do a full re-run.
The reason for this (not the initial rationale, but my analysis) is:
-
Since we create a single "*.cocci.patch+" we don't know where to pick up where we left off, or how to incrementally merge e.g. a "grep.c" change with an existing *.cocci.patch.
-
We've been carrying forward the dependency on the *.c files since 63f0a758a06 (add coccicheck make target, 2016-09-15) the rule was initially added as a sort of poor man's dependency discovery.
As we don't include other *.c files depending on other *.c files has always been broken, as could be trivially demonstrated e.g. with:
make coccicheck make -W strbuf.h coccicheckHowever, depending on the corresponding *.c files has been doing something, namely that if an API change modified both *.c and *.h files we'd catch the change to the *.h we care about via the *.c being changed.
For API changes that happened only via *.h files we'd do the wrong thing before this change, but e.g. for function additions (not "static inline" ones) catch the *.h change by proxy.
Now we'll instead:
-
Create a / pair in the .build directory, E.g. for swap.cocci and grep.c we'll create .build/contrib/coccinelle/swap.cocci.patch/grep.c.
That file is the diff we'll apply for that - combination, if there's no changes to me made (the common case) it'll be an empty file.
-
Our generated *.patch file (e.g. contrib/coccinelle/swap.cocci.patch) is now a simple "cat $^" of all of all of the / files for a given .
In the case discussed above of "grep.c" being changed we'll do the full "cat" every time, so they resulting *.cocci.patch will always be correct and up-to-date, even if it's "incrementally updated".
See 1cc0425a27c (Makefile: have "make pot" not "reset --hard", 2022-05-26) for another recent rule that used that technique.
As before we'll:
-
End up generating a contrib/coccinelle/swap.cocci.patch, if we "fail" by creating a non-empty patch we'll still exit with a zero exit code.
Arguably we should move to a more Makefile-native way of doing this, i.e. fail early, and if we want all of the "failed" changes we can use "make -k", but as the current "ci/run-static-analysis.sh" expects us to behave this way let's keep the existing behavior of exhaustively discovering all cocci changes, and only failing if spatch itself errors out.
Further implementation details & notes:
-
Before this change running "make coccicheck" would by default end up pegging just one CPU at the very end for a while, usually as we'd finish whichever *.cocci rule was the most expensive.
This could be mitigated by combining "make -jN" with SPATCH_BATCH_SIZE, see 960154b9c17 (coccicheck: optionally batch spatch invocations, 2019-05-06).
There will be cases where getting rid of "SPATCH_BATCH_SIZE" makes things worse, but a from-scratch "make coccicheck" with the default of SPATCH_BATCH_SIZE=1 (and tweaking it doesn't make a difference) is faster (~3m36s v.s. ~3m56s) with this approach, as we can feed the CPU more work in a less staggered way.
-
Getting rid of "SPATCH_BATCH_SIZE" particularly helps in cases where the default of 1 yields parallelism under "make coccicheck", but then running e.g.:
make -W contrib/coccinelle/swap.cocci coccicheckI.e. before that would use only one CPU core, until the user remembered to adjust "SPATCH_BATCH_SIZE" differently than the setting that makes sense when doing a non-incremental run of "make coccicheck".
-
Before the "make coccicheck" rule would have to clean "contrib/coccinelle/.cocci.patch", since we'd create "+" and ".log" files there. Now those are created in .build/contrib/coccinelle/, which is covered by the "cocciclean" rule already.
Outstanding issues & future work:
-
We could get rid of "--all-includes" in favor of manually specifying a list of includes to give to "spatch(1)".
As noted upthread of 1 a naïve removal of "--all-includes" will result in broken *.cocci patches, but if we know the exhaustive list of includes via COMPUTE_HEADER_DEPENDENCIES we don't need to re-scan for them, we could grab the headers to include from the .depend.d/.o.d and supply them with the "--include" option to spatch(1).q
Signed-off-by: Ævar Arnfjörð Bjarmason [email protected] Signed-off-by: Taylor Blau [email protected]
Colony Guns Part 3: Longarms Rework (#2334)
Updates and buffs the following weapons:
- Basira-Armstrong Rifle
- Model 12 Bolt-Action Rifle
- M37-17 pump shotgun
- Dragunov sniper rifle
- The BA rifle has been reflavored as the removed 'ceremonial' ABR-40, now a hunting-civilian version of the L42. It effectively has the same stats as the L42, just don't take the stock off!
- Its magazines can only fit 12 bullets, but they still have the classic L42 kick to them. The magazines are completely compatible between both military and civilian gun types.
- Additionally, there are now holo-targeting magazines available for the ABR-40, for hunting target capture purposes.
-
- The Contractor ERT has a chance to spawn with a tacticool ABR-40 loadout, with three spare holotarget magazines on their webbing.
- Like its sprite implies, this is now the new Basira-Armstrong rifle.
- Its stats have recieved an overhaul and it can now hold its own against a Xenomorph (or marine if you're CLF)
- Additionally, its bullets will push back (not stun) targets within three meters, to increase viability for colony usage.
- Did you know that the 10% damage mod this gun was supposed to have didn't work? Now it does! And it deals 15% more damage to make up for it.
- However, it can now be melted down.
- The dragunov has been revamped into a DMR, needing no skill to fire, dealing good damage, and having the same push-back feature the bolt-action now has.
All of these weapons are seen as, and are, a complete joke and ignored in favor of chungillionaire among us sus impostor running around PBing xenos with buckshot. Buffing them to be useful paves the way for civilians to use civilian weaponry instead of chungillionarius.
This is intended as asset recycling. IIRC, Triiodine disliked the existence of a ceremonial rifle and thought that was goofy, which is an understandable opinion, but it pains me to see the gun's cool assets go unused. I took the opportunity and made the lame and mediocre Basira into this cool gun which marines and survivors will take a lot more interest in than a Basira plinker.
While it does have L42 stats, colonists won't be able to locate any L42A ammo on the colony, meaning they are limited to 12-round magazines. Still, giving them a weapon like this is a great way to incentivize them to step out of their chungus zone.
As for the contractor addition, these are supposed to be ex-USCM mercenaries, who are trained in the usage of marine equipment. It makes sense that they'd grab the civilian version of a primary marine gun and tune it to their liking.
Chomp made this really cool backend for a bolt-action that tragically ended up never being used, not really, aside from a half-hearted few rifles being thrown in at Shiva's Snowball. Since these guns are so weak, it's plain to see why nobody even looks at them twice. So I changed that.
Bugfix and a small damage buff to make up for it. It being unacidable was lame anyways. Spread projectiles are still bugged and don't inherit the base gun's damage mod, but that's out of scope.
This gun has been a joke since 2017, it's time to give it some love. Still needs one-hand sprites but not my problem.
Screenshots & Videos
Put screenshots and videos here with an empty line between the
screenshots and the <details> tags.
🆑 balance: Updates and buffs the following weapons: Basira-Armstrong Rifle, Model 12 Bolt-Action Rifle, M37-17 pump shotgun, Dragunov sniper rifle imageadd: The Basira rifle has been reflavored as the removed 'ceremonial' ABR-40, now a hunting-civilian version of the L42. It effectively has the same stats as the L42, just don't take the stock off! add: Its magazines can only fit 12 bullets, but they still have the classic L42 kick to them. The magazines are completely compatible between both military and civilian gun types. add:: Additionally, there are now holo-targeting magazines available for the ABR-40, for hunting target capture purposes. add: The Contractor ERT has a chance to spawn with a tacticool ABR-40 loadout, with three spare holotarget magazines on their webbing. balance: Like the bolt-action rifle's sprite implies, this is now the new Basira-Armstrong rifle. add: Its stats have recieved an overhaul and it can now hold its own against a Xenomorph (or marine if you're CLF) add: Additionally, its bullets will push back (not stun) targets within three meters, to increase viability for colony usage. balance: Did you know that the 10% damage mod the M37-17 pump shotgun was supposed to have didn't work? Now it does! And it deals 15% more damage to make up for it. del: However, it can now be melted down. balance: The dragunov has been revamped into a DMR, needing no skill to fire, dealing good damage, and having the same push-back feature the bolt-action now has. /🆑
fix(DB/Locale): deDE fix request items texts #02 (#14615)
Process of translation: only original sources of deDE texts by researching multiple sources, reverse translation by searching for related quest items/NPCs and using these names to reconstruct a proper translation.
This fixes the terms
Coldtooth-Mine (Eisbeißermine), Doomhammer (Schicksalshammer), Fizzle (Zischel), Fizzledowser (Rutenwünschels), Fizzlebub (Zischelbub), Burning Blade (Brennende Klinge), Ashenvale (Eschental), Bloodscalp/s/stamm (Blutskalpe, Blutskalpstamm), Darkspeartrolle/Darkspears/Darkspearstamm (Dunkelspeere, Dunkelspeertrolle, -stamm), Moonglade (Mondlichtung), Starblaze (Sternenschauer), Shadowglen (Laubschattental), Darrowshire (Darroheim), Booty Bay (Beutebucht), Ratchet (Ratschet), Dizzywig (Flunkerblick), Hearthglen (Herdweiler), Chillwindspitze (Zugwindspitze), Stormrage (Sturmgrimm), Stormpike (Sturmlanze/n), Ironforge (Eisenschmiede), Thunderhorn (Donnerhörner), Steamboil (Kesseldampf), Twilight-Hammer, -klan (Schattenhammer/Schattenhammerklan), Fathom-Kern (Tiefenkern), Blackfathom Deeps (Tiefschwarze Grotte), Blackrock-* (Schwarzfels-*), Hawkwind (Falkenwind), Feathermoon (Mondfeder), Moonrage (Mondzorn), Firemane (Feuermähne), Searingblade (Sengende Klinge), Ragefireabgrund (Flammenschlund), Ironbands Areal (Eisenbands Lager), Zandalar (Zandalari), Southshore (Süderstade)
for quest progress/request text entries for the deDE localisation with proper casus/declension (these are not proper translated names of locations/NPCs that have been left over by Blizzard since their language localisations in TBC in 2006 and onward).
Added missing progress/request text entries for 308, 311, 417, 1644, 1787, 5059, 5060, 5721, 6004, 6023, 6025, 6187, 8042, 8043, 8044, 8046, 8047, 8048, 8050-8079, 8102, 8107, 8108, 8111, 8112, 8113, 8117, 8118, 8142, 8143, 8147, 8183-8195, 8238, 8239, 8240, 8243, 8246, 8860, 9594, 9692, 9707, 10414, 10415, 10919, 11451. (A lot of them are Zandalari/Zul'Gurub related quests.)
Replaced post-Cataclysm progress/request text entries for 933, 935, 6387, 7383.
Fixed a wrong $R with plain text at progress/request text for 9147.
Added missing female gender equivalent to 6391.
(There are probably more changes in the file that aren't further explained here as it was hard to keep track of everything. If you think I made a mistake or have questions please contact me directly.)
- Fixing a lot in the quest_request_items_locale table.
- Fixing some of the tasks in azerothcore/azerothcore-wotlk#14244 Referring to my other two bug reports from CC Github:
- chromiecraft/chromiecraft#4697
- chromiecraft/chromiecraft#4745
- Read the text on top.
- Not tested.
All of the changes are to reward texts of quests, can be tested by completing quests or simply reviewing the changed file.
- [ ]
- [ ]
When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].
You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:
http://www.azerothcore.org/wiki/How-to-test-a-PR
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.
[Java.Interop.Tools.Expressions] Add Java.Interop.Tools.Expressions
Fixes: dotnet/java-interop#616
Context: dotnet/java-interop#14 Context: ff4053cb1e966ebec1c16f97211b9ded936f2707 Context: da5d1b8103bb90f156b93ebac9caa16cfc85764e Context: 4787e0179b349ab5ee0d0dd03d08b694acea4971 Context: 41ba34856ab119ea6e22ab103320180143fdf03d
Remember jnimarshalmethod-gen (176240d2)? And it's crazy idea to
use the System.Linq.Expressions-based custom marshaling
infrastructure (ff4053cb, da5d1b81) to generate JNI marshal methods
at build/packaging time. And how we had to back burner it because
it depended upon System.Reflection.Emit being able to write
assemblies to disk, which is a feature that never made it to
.NET Core, and is still lacking as of .NET 7?
Add src/Java.Interop.Tools.Expressions, which contains code which
uses Mono.Cecil to compile Expression<T> expressions to IL.
Then update jnimarshalmethod-gen to use it!
~~ Usage ~~
% dotnet bin/Debug-net7.0/jnimarshalmethod-gen.dll \
bin/TestDebug-net7.0/Java.Interop.Export-Tests.dll \
-v -v --keeptemp \
--jvm /Library/Java/JavaVirtualMachines/microsoft-11.jdk/Contents/Home/lib/jli/libjli.dylib \
-o _x \
-L bin/TestDebug-net7.0 \
-L /usr/local/share/dotnet/shared/Microsoft.NETCore.App/7.0.0
First param is assembly to process; Java.Interop.Export-Tests.dll
is handy because that's what the run-test-jnimarshal target in
Makefile processed.
-
-v -vis really verbose output -
--keeptempis keep temporary files, in this case_x/Java.Interop.Export-Tests.dll.cecil. -
--jvm PATHis the path to the JVM library to load+use. -
-o DIRis where to place output files; this will create_x/Java.Interop.Export-Tests.dll. -
-L DIRaddsDIRto library resolution paths; this addsbin/TestDebug/net7.0(dependencies ofJava.Interop.Export-Tests.dll) andMicrosoft.NETCore.App/7.0.0-rc.1.22422.12(net7 libs).
By default the directories containing input assemblies and the
directory containing System.Private.CoreLib.dll are part of the
default -L list.
When running in-tree, e.g. AzDO pipeline execution, --jvm PATH
will attempt to read the path in bin/Build*/JdkInfo.props
a'la TestJVM (002dea4a). This allows an in-place update in
core-tests.yaml which does:
dotnet bin/Debug-net7.0/jnimarshalmethod-gen.dll \
bin/TestDebug-net7.0/Java.Interop.Export-Tests.dll \
-v -v --keeptemp -o bin/TestDebug-net7.0
~~ Using jnimarshalmethod-gen output ~~
What does jnimarshalmethod-gen do?
% ikdasm bin/TestDebug-net7.0/Java.Interop.Export-Tests.dll > beg.il
% ikdasm _x/Java.Interop.Export-Tests.dll > end.il
% git diff --no-index beg.il end.il
# https://gist.github.com/jonpryor/b8233444f2e51043732bea922f6afc81
is a ~1KB diff which shows, paraphrasing greatly:
public partial class ExportTest {
partial class '__<$>_jni_marshal_methods' {
static IntPtr funcIJavaObject (IntPtr jnienv, IntPtr this) => …
// …
[JniAddNativeMethodRegistration]
static void __RegisterNativeMembers (JniNativeMethodRegistrationArguments args) => …
}
}
internal delegate long _JniMarshal_PP_L (IntPtr jnienv, IntPtr self);
// …
wherein ExportTest._<$>_jni_marshal_methods and the _JniMarshal*
delegate types are added to the assembly.
This also unblocks the desire stated in 4787e017:
For
Java.Base, @jonpryor wants to support the custom marshaling infrastructure introduced in 77a6bf86. This would allow types to participate in JNI marshal method ("connector method") generation at runtime, allowing specialization based on the current set of types and assemblies.
What can we do with this jnimarshalmethod-gen output? Use it!
First, make sure the tests work:
% dotnet test --logger "console;verbosity=detailed" bin/TestDebug-net7.0/Java.Interop.Export-Tests.dll
…
Passed! - Failed: 0, Passed: 17, Skipped: 0, Total: 17, Duration: 103 ms - Java.Interop.Export-Tests.dll (net7.0)
Then update/replace the unit test assembly with
jnimarshalmethod-gen output:
% \cp _x/Java.Interop.Export-Tests.dll bin/TestDebug-net7.0
% dotnet test --logger "console;verbosity=detailed" bin/TestDebug-net7.0/Java.Interop.Export-Tests.dll
…
Total tests: 17
Passed: 17
core-tests.yaml has been updated to do this.
~~ One-Off Tests ~~
One-off tests: ensure that the generated assembly can be decompiled:
% ikdasm bin/TestDebug-net7.0/Java.Interop.Tools.Expressions-Tests-ExpressionAssemblyBuilderTests.dll
% monodis bin/TestDebug-net7.0/Java.Interop.Tools.Expressions-Tests-ExpressionAssemblyBuilderTests.dll
% ikdasm _x/Java.Interop.Export-Tests.dll
% monodis _x/Java.Interop.Export-Tests.dll
# which currently fails :-()
Re-enable most of Java.Interop.Export-Tests.dll for .NET 7;
see 41ba3485, which disabled those tests.
To verify the generated IL, use the dotnet-ilverify tool:
dotnet tool install --global dotnet-ilverify
Usage of which is "weird":
$HOME/.dotnet/tools/ilverify _x/Java.Interop.Export-Tests.dll \
--tokens --system-module System.Private.CoreLib \
-r 'bin/TestDebug-net7.0/*.dll' \
-r '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/7.0.0/*.dll'
All Classes and Methods in /Volumes/Xamarin-Work/src/xamarin/Java.Interop/_x/Java.Interop.Export-Tests.dll Verified.
# no errors!
where:
--tokens: Include metadata tokens in error messages.--system-module NAME: set the "System module name". Defaults tomscorlib, which is wrong for .NET 5+, so this must be set toSystem.Private.CoreLib(no.dllsuffix!).-r FILE-GLOB: Where to resolve assembly references for the input assembly. Fortunately file globs are supported…
~~ Removing System.Private.CoreLib ~~
System.Private.CoreLib.dll is private; it's not part of the
public assembly surface area, so you can't use
csc -r:System.Private.CoreLib … and expect it to work. This makes
things interesting because at runtime everything "important" is in
System.Private.CoreLib.dll, like System.Object.
Specifically, if we do the "obvious" thing and do:
newTypeDefinition.BaseType = assemblyDefinition.MainModule
.ImportReference (typeof (object));
you're gonna have a bad type, because the resulting IL for
newTypeDefinition will have a base class of
[System.Private.CoreLib]System.Object, which isn't usable.
Fix this by:
- Writing the assembly to a
Stream. - Reading the
Streamfrom (1) - Fixing all member references and assembly references so that
System.Private.CoreLibis not referenced.
If jnimarshalmethod-gen.dll --keeptemp is used, then a .cecil
file is created with the contents of (1).
Additionally, and unexpectedly -- jbevain/cecil#895 -- Mono.Cecil
adds a reference to the assembly being modified. Remove the declaring
assembly from AssemblyReferences.
it's all on me
Chris, I was wrong. You were never the reason we failed, it was all on me. I understand how you feel. I didn't think it would be that hard to put in the shooting mechanic. I should have asked the teacher. I was the whole reason that Sandstorm was a failure. I'm so sorry I blamed you for our failure. I don't know if you're going to pull the origin and read this, but if you do, I hope you can see it in your heart to forgive me.
Update ActionPopupInspect.gd
lousy goddamn sequence_active/dialog_active bullshit
"https://news.ycombinator.com/item?id=34725047
Not laid off but I've just ended a year long sabbatical. Looking for work now is a terrible experience. A lot of ghosting, recruiters absolutely useless, agencies not looking for new talent. I have done two dozen interviews, twice as many resumes sent to interested recruiters, and only one offer, which I was not very excited about and declined.
I'm focusing on my SaaS project, and trying to market myself outside the box instead of the old resume as my 16 years long career doesn't seem to impress anyone. Sorry, I will not elaborate further as you're all my competition here.
Brutal. I should not see this period as typical.
Maybe it is dumb to think that I'll improve my chances much by adding some exp in this kind of environment.
7:55pm. https://storyteller.io/
This guy posted in that thread, so I applied to him on a whim.
This site is really interesting.
9:20pm. https://www.youtube.com/watch?v=tKIQfeOXynI Mastering Elmish
Somebody posted this 1:22h video yesterday.
https://youtu.be/tKIQfeOXynI?t=56
The good thing about Elmish is that it is not about web development. It is about universal stuff.
https://youtu.be/tKIQfeOXynI?t=127
Just what is wrong with the video here?
https://youtu.be/tKIQfeOXynI?t=247
Oh it is possible to reload the Ionide plugin like this.
9:35pm. https://youtu.be/tKIQfeOXynI?t=432
This video is unbearable to watch due to the partial frames.
9:40pm. I am playing with setting up the Elmish project again. Ran into the femto bug.
9:45pm. I've zipped the folder. Let me see if I can open an issue.
https://github.com/Zaid-Ajaj/Femto/issues/
Actually the issue I have seems to be exactly issue 98.
10:10pm. Ok, at this point I am convinced this has something to do with webpack.
10:15pm. Yeah, it doesn't have anything to do with NPM packages. This is purely an issue with webpack, I think.
///
Do you have any advice how to set up Fable.Elmish + React from scratch? I keep getting weird errors and it has been a nightmare to get it to work. A part of it was because I was trying to use .NET 7 which run into issues with Femto not being able to resolve NPM packages correctly. I've moved past that by downgrading to .NET 6.
At first I was suspicious of the NPM packages themselves, but now I think there is something wrong with the Fable template's Webpack configuration because I tried copying the SAFE Dojo's dependencies and it did not fix it. I took a look at it and SAFE Dojo's Webpack config is beyond arcane. I am not sure whether it is worth studying it.
I'll have to open an issue on the Elmish repo as half of the examples are busted right now, but since I am suspecting Webpack, I thought I might ask you for advice. So please.
///
Asked here. I'll open a proper issue tomorrow.
https://vitejs.dev/guide/#community-templates
I do not want to study this right now.
10:35pm. https://www.reddit.com/r/fsharp/comments/10xrtl3/updated_net_managed_languages_strategy_net/
Don Syme left MS?
No, he is still there, just on a different project.
10:40pm. Let me watch Mitsuha. I should get dinner.
Tomorrow I will open an issue on the elimsh repo regarding the specific issue, and study Vite.
2/10/2023
9:30am. I am up.
Hmmmm, this is the second time I've gotten the creepy mail.
https://github.com/m-r-a-k-g-r
I guess this is some kind of cyberbullying. The annoying thing is that corrupted text takes up so much of the screen that I can't find the report button.
Ah, it is in his profile.
9:50am. I wasted 20 mins reporting this guy.
https://mangadex.org/title/4ae47330-e64d-4e4e-9d1e-433bd8b18937/u12-under-12
I had no idea I was following this.
I'll check out ch 1 as well as Fabiniku. Let me chill a bit.
I'll leave replying to the robot RL guy for later. Did I get a reply to what I asked the guy on Reddit yesterday?
Oh, I got something good.
I thought that string was meaningless, but I wonder if it is tied to the id - |> Program.withReactBatched "app"
Yeah, I had this hunch yesterday, but ignored it.
I'll first try matching the id, and then I am going to try his advice.
10:25am. Chilled enough. Let me start.
<body>
<div id="app">
<p>Fable is running</p>
<p>You can click on this button:</p>
<button class="my-button">Click me!!!</button>
<script src="bundle.js"></script>
</div>
</body>I've put this div in the body, with the id="app".
|> Program.withReactSynchronous "app"
I'll use app as a placeholder. Now let me try running it.
ERROR in ./src/fable_modules/Fable.Elmish.React.4.0.0/react.fs.js 3:0-43
Module not found: Error: Can't resolve 'react-dom/client' in 'E:\Webdev\Fable\fable-elmish-example\src\fable_modules\Fable.Elmish.React.4.0.0'
resolve 'react-dom/client' in 'E:\Webdev\Fable\fable-elmish-example\src\fable_modules\Fable.Elmish.React.4.0.0'
Parsed request is a module
using description file: E:\Webdev\Fable\fable-elmish-example\package.json (relative path: ./src/fable_modules/Fable.Elmish.React.4.0.0)
Field 'browser' doesn't contain a valid alias configuration
resolve as module
E:\Webdev\Fable\fable-elmish-example\src\fable_modules\Fable.Elmish.React.4.0.0\node_modules doesn't exist or is not a directory
E:\Webdev\Fable\fable-elmish-example\src\fable_modules\node_modules doesn't exist or is not a directory
E:\Webdev\Fable\fable-elmish-example\src\node_modules doesn't exist or is not a directory
looking for modules in E:\Webdev\Fable\fable-elmish-example\node_modules
existing directory E:\Webdev\Fable\fable-elmish-example\node_modules\react-dom
using description file: E:\Webdev\Fable\fable-elmish-example\node_modules\react-dom\package.json (relative path: .)
using description file: E:\Webdev\Fable\fable-elmish-example\node_modules\react-dom\package.json (relative path: ./client)
no extension
E:\Webdev\Fable\fable-elmish-example\node_modules\react-dom\client doesn't exist
.js
E:\Webdev\Fable\fable-elmish-example\node_modules\react-dom\client.js doesn't exist
.json
E:\Webdev\Fable\fable-elmish-example\node_modules\react-dom\client.json doesn't exist
.wasm
E:\Webdev\Fable\fable-elmish-example\node_modules\react-dom\client.wasm doesn't exist
as directory
E:\Webdev\Fable\fable-elmish-example\node_modules\react-dom\client doesn't exist
E:\Webdev\Fable\node_modules doesn't exist or is not a directory
E:\Webdev\node_modules doesn't exist or is not a directory
looking for modules in E:\node_modules
E:\node_modules\react-dom doesn't exist
@ ./src/App.fs.js 10:0-100 91:18-46
Sigh, this fucking thing again?
Ohhh, I got it to work! Another example, I mean.
As to why the previous one did not work, it is probably because...yeah, I am using the prerelease.
ERROR in ./src/fable_modules/Fable.Elmish.React.4.0.0/react.fs.js 3:0-43
Module not found: Error: Can't resolve 'react-dom/client' in 'E:\Webdev\Fable\fable-elmish-example\src\fable_modules\Fable.Elmish.React.4.0.0'
resolve 'react-dom/client' in 'E:\Webdev\Fable\fable-elmish-example\src\fable_modules\Fable.Elmish.React.4.0.0'
Nope, I've tried downgrading, but it still does not work.
PS E:\Webdev\Fable\fable-elmish-example> dotnet femto src --resolve
[10:42:56 INF] Analyzing project E:/Webdev/Fable/fable-elmish-example/src/App.fsproj
[10:42:56 INF] Running dotnet restore against the project
[10:43:00 INF] Using npm for package management
[10:43:04 INF] Found package.json in E:\Webdev\Fable\fable-elmish-example
[10:43:05 INF] Executing required actions for package resolution
[10:43:05 INF] Uninstalling [react, react-dom]
[10:43:07 INF] Installing dependencies [[email protected], [email protected]]
[10:43:12 INF] ✔ Package resolution complete
Hmmm, it actually reinstalled them. Let me try again.
Oh that was it!
Let me try upgrading Fable to prerelease once more.
Yeah, it works. For the sake of Femto, I'll stick to the .NET 6.
10:45am. Everything works now!
This took up so much of my time yesterday, but now I am smoothly sailing. I really should have realized that I need to attach it to some html id, I mean I did have that example in Blazor, but I was too dumb to realize what the script was asking me. I even had the notion once, but ignored the impulse as I wasn't sure if it was right.
11am. https://github.com/Zaid-Ajaj/elmish-getting-started/issues/
Added a bit of info to issue 31 here.
Ok...
During the night, I thought that today might be the time to study both Webpack and debugging. Right now I don't actually know how to debug even regular F# projects in VS Code. I have debugged TS projects in the past, but have forgotten how that went.
11:05am. Since I've resolved the issue I'll leave that for later.
I'll do what I wanted to yesterday which is study the Elimish examples. Also the book. I forgot that it existed.
let timestamp = model.current.ToString("yyyy-MM-dd HH:mm:ss.ffff")Oh, I did not know you could format the time like this. This is something to keep in mind.
let view model dispatch =
let timestamp = model.current.ToString("yyyy-MM-dd HH:mm:ss.ffff")
Html.div [
Html.div [Html.text timestamp]
Html.div [
Html.label [
prop.children [
Html.input [
prop.type' "checkbox"
prop.isChecked model.enabled
prop.onCheckedChange (fun b -> dispatch (Toggle b))
]
Html.text " enabled"
]
]
]
]Now that it has come to this, I can finally let myself focus on the example code. It is easy to understand.
let subscribe model =
[ if model.enabled then
["timer"], timer Tick ]Oh wow, I didn't realize that subscriptions are also done based on model state.
I really like the Elmish library a lot more than my reactive techniques.
11:20am. Ok...Let me move forward to the next example.
module Hour =
type Msg =
| Hour of int
type Model = int
let init () =
0, []
let update (Hour hour) model =
hour, []
let subscribe model =
[ ["timer"], Sub.timer (60*1000) (fun now -> Hour now.Hour) ]This should really be a minute, but whatever.
11:35am. https://elmish.github.io/elmish/docs/subscription.html#ids-and-dependencies
How does it work? It is taking advantage of ID uniqueness. Let's say that intervalMs is initially 1000. The sub ID is ["timer"; "1000"], Elmish starts the subscription. Then intervalMs changes to 2000. The sub ID becomes ["timer"; "2000"]. Elmish sees that ["timer"; "1000"] is no longer active and stops it. Then it starts the "new" subscription ["timer"; "2000"].
Hmmm, is that how it is?
11:55am. This last example gives me an error when I try to use it. It says that string length must be non negative.
let zeros = 23 - s.Length
s + String.replicate zeros "0"Huh is it this?
let zeros = 23 - s.Length |> max 0Let me try this.
Yeah, that was it. But it is really strange that this would result in a negative value.
let s = now.ToString("yyyy-MM-dd HH:mm:ss.ffff")It says that this is 24. How can that be?
Yeah, it is exactly 24. Looks can be deceiving! I'd have guessed it was something like 15.
12:15pm. I've studied the example. I really like this kind of UI work. I am not sure if hot reloading is working correctly, but the changes are swift to be applied.
Let me report an error.
https://github.com/elmish/elmish/issues/
Opened issue 270.
12:25pm. Now where was I?
https://elmish.github.io/react/
Both React and React Native applications need a root component to be rendered at the specified placeholder, see browser and native tutorials for details.
Ah, so that is where it was written.
12:30pm. Time for chores here.
What I will do next is go through the rest of the docs.
1:40pm. Right now I am breakfasting.
https://boards.4channel.org/g/thread/91436854/do-you-realize-4chan-is-going-to-become-more#p91437054
For people like you there is "heaven-banning"
Is this real?
https://news.ycombinator.com/item?id=31588260
Note: The story is made up, the author says so in the first comment on Twitter, easy to miss. Very interesting idea though.
Also in the image the date says Aug 8 2024.
heaven-banning, the hypothetical practice of banishing a user from a platform by causing everyone that they speak with to be replaced by AI models that constantly agree and praise them, but only from their own perspective, is entirely feasible with the current state of AI/LLMs
Let me finish this chapter and then I am going to resume my studies. I really like that react has lazy views. This is brilliant. This is exactly what is needed to eliminate the weakness of the Elm pattern.
2:30pm. I got distracted by a reply from that issue I opened.
Now where was I?
https://elmish.github.io/react/tutorials/browser.html
Let me read this. Stop getting distracted me, and finish these studies.
https://elmish.github.io/react/tutorials/browser.html#create-the-program-instance
Take a look at this. It says exactly what I need to start the application here.
https://zaid-ajaj.github.io/Feliz/#/
It seems here I can program in native react without having to reach for the Elm pattern. It reminds me of some JS libraries that I looked at. I wonder what the type of this is?
module App
open Feliz
[<ReactComponent>]
let Counter() =
let (count, setCount) = React.useState(0)
Html.div [
Html.button [
prop.style [ style.marginRight 5 ]
prop.onClick (fun _ -> setCount(count + 1))
prop.text "Increment"
]
Html.button [
prop.style [ style.marginLeft 5 ]
prop.onClick (fun _ -> setCount(count - 1))
prop.text "Decrement"
]
Html.h1 count
]
open Browser.Dom
ReactDOM.render(Counter(), document.getElementById "app")It says this way of doing things is deprecated.
2:45pm.
module App
open Feliz
[<ReactComponent>]
let Counter() =
let (count, setCount) = React.useState(0)
Html.div [
Html.button [
prop.style [ style.marginRight 5 ]
prop.onClick (fun _ -> setCount(count + 1))
prop.text "Increment"
]
Html.button [
prop.style [ style.marginLeft 5 ]
prop.onClick (fun _ -> setCount(count - 1))
prop.text "Decrement"
]
Html.h1 count
]
open Browser.Dom
let x = ReactDOM.createRoot (document.getElementById "app")
x.render(Counter())I like this. I remember React being very nasty in TS, but this is not bad at all.
https://elmish.github.io/react/tutorials/native.html
Hmmm, what is ReactNative?
Does it even work for Windows? I'd guess so.
https://microsoft.github.io/react-native-windows/
Nevermind that for now.
2:55pm. https://elmish.github.io/browser/
Let me read this.
https://elmish.github.io/browser/tutorials/routing.html
I do not understand this.
https://elmish.github.io/urlParser/
Nevermind this.
https://github.com/elmish/elmish/blob/v4.x/docs/index.md#controlling-termination
Don't get this.
https://elmish.github.io/debugger/
Ok, I am done with the Elmish docs.
3:05pm. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/fable/
I guess I should read this.
https://zaid-ajaj.github.io/the-elmish-book/#/chapters/fable/hello-world
I really starts from the beginning.
https://vitejs.dev/guide/why.html
Let me just read the why for Vite.
Once you experience how fast Vite is, we highly doubt you'd be willing to put up with bundled development again.
I'll leave this for later.
I found a template for this and started wondering what it was.
Fast 3kB alternative to React with the same modern API
I see.
I think I saw Fable.Lit used in SAFE Dojo. Or was it mentioned in that thread?
Nevermind this for now. React is good enough for the time being.
https://zaid-ajaj.github.io/Feliz/#/
I'll leave Feliz for later as well. Let me take a look at the Elmish book.
3:35pm. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/fable/node-packages
I am getting distracted like this. I really liked the straight code examples more. At my level, I can just look and get it, so increased wordiness of this book is just taking up my time.
https://zaid-ajaj.github.io/the-elmish-book/#/chapters/elm/render-html
I am going to have to get used to writing html, but that is fine.
Oh, he is doing a comparison here.
https://zaid-ajaj.github.io/the-elmish-book/#/chapters/elm/using-css#external-style-sheets
Ah, so Bulma is a CSS styling library. I see.
https://zaid-ajaj.github.io/the-elmish-book/#/chapters/elm/form-inputs#bootstrapping-the-program
Only here he shows how to bootstrap the program.
As I have mentioned earlier, we will be using Bulma as our CSS framework and Font Awesome for, well, the awesome icons.
Naruhodo.
Don't worry if you aren't familiar with the classes that Bulma provides. I wasn't either when I started writing the chapter! It is a matter of looking up the documentation to see what classes you need.
https://zaid-ajaj.github.io/the-elmish-book/#/chapters/elm/todo-app-part2
Hmmm, are HTML object classes the same thing as style classes? Nevermind that for now.
Although this would work, it requires considerable amount of work to take every class exposed from Bulma and writing in the module, not to mention that you have to maintain the module and update it when Bulma introduces breaking changes. Finally, you would have to follow this process for every CSS framework you want to use. What if there was a tool that does all things for us using a single line of code? Enter TypedCssClasses written by Zanaptak , a type-provider that infers the class names exposed from a stylesheet and makes them available during compile-time!
Cool. I'll keep this in mind.
4:45pm. Had to take a break. Let me resume.
If we ignore the views, I could use Elmish for pretty much anything. It is like the video said, this is universal.
5:10pm. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/commands/async-recursive-updates
Come to think of it, instead of Spiral's custom diff thing, could I have implemented the whole thing in terms of the Elm pattern? Did I really need that weird Hopac thing?
...Yeah, I did need it. For the simple reason that Elm messages are async, while Hopas is synchronous concurrency.
But then again, I could have done typechecking synchronously in the server. There is no reason to say that it needs to by async. Parsing could have been.
Well, I could have made is semi-async.
5:15pm. Nevermind this for now.
5:20pm. Yeah, now I am lost in thought, but it would be very hard to model the problem that I want using the async concurrency style. Nevermind it.
What the Elmish style would be good though is organizing code.
5:30pm. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/commands/http
Here is some webdev stuff.
But you might wondering, why bother with a different static file server other than webpack development server? The reason is that the development server is kind of special and injects a lot of JavaScript artifacts in your index.html during development, for example to make the web page refreshed after you edit your source files. These added artifacts could be incompatible with many browsers and might break your actual application in a production environment.
This is pretty informative.
I've been kind of skimming it up to now, but I'll up me level of attention.
You might say "Well, this is just a silly example code, real-world code doesn't look like this, right?" Actually, real-world JavaScript can be even uglier, because when loading data from a server, especially for a RESTful API, the front-end code ends up with having to request data from multiple endpoints. However, this problem is not specific to calling web APIs and also applies to any callback based API such as the file system API when running JavaScript in a Node.js environment.
5:55pm. > Alright, after this little detour you must be wondering why this is relevant to our F# implementation of httpRequest. To put it simply: F#'s Async expressions compiled with Fable are more or less the equivalent of JavaScript's Promises, they are just syntax sugar around callback-based APIs.
The important differences is that Promises memoize their results, while Asyc reruns it.
6pm. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/commands/working-with-json
This is useful. I am doing JSON transfers for Spiral.
For example, Fable.SimpleJson is the power-engine behind Fable.Remoting and Elmish.Bridge where the library handles the deserialization of types on the front-end correctly and efficiently.
Important one page chapter.
6:05pm. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/commands/using-json
So far this book is really taking up my time, but I am absorbing it readily.
https://zaid-ajaj.github.io/the-elmish-book/#/chapters/commands/using-json
let storeInfoDecoder : Decoder<StoreInfo> =
Decode.object (fun get -> {
name = get.Required.Field "name" Decode.string
since = get.Required.Field "since" (Decode.map string Decode.int)
daysOpen = get.Required.Field "daysOpen" (Decode.list Decode.string)
products = get.Required.Field "products" (Decode.list productDecoder)
})This is interesting. How can this possibly have correct...
No maybe it could. After all, it is using the decoder here. With Spiral I could automate this, but sure, you could make a decoder by hand like this too.
Edit: Later it shows that F# can do it too using reflection.
6:20pm. Time for lunch.
I do not remember what I am using for JSON conversion in Spiral, but I think it is some other library.
6:30pm. Having lunch here.
I thought this book would be just about UIs, but this is a decent web dev book in general.
6:50pm. Done with lunch. Let me resume.
https://zaid-ajaj.github.io/the-elmish-book/#/chapters/commands/elmish-hackernews
Actually, let me stop here. Who is going to go on anymore.
6:55pm. As the last thing for day, I guess I'll reply to the robotics guy.
///
Hey Marko,
How are you?
Thank you for the link - the videos look very good! Let me know once you do the RL programming in Spiral ones.
Yes, it's likely that UPMEM prefers to work with someone interested in their hardware. But I think you did well to tell them that. If you find a company with interesting hardware, then it'll be easier to approach them :)
Yes, you're right about the immitation learning approach!
I should probably go for it. But for now I'm still just finding excuses not to do it... (I need more courage). But you should too! You're very passionate and super knowledgeable about this space! What would you need to focus exclusively on your ideas?
It was a long journey... I studied medicine but figured I wouldn't be a very good doctor because there were other things I preferred to do/explore. After that I spent more than a decade doing other work until coming across with coding and finding how much fun it is. When my second attempt at starting a company failed, I decided to look for a job as a software dev. It still took me 8 months of practising and almost another 8 of job search. I've been working as a software dev for almost 2 years now and loving it.
How about you, any progress on the job search front?
Take care!
///
///
What would you need to focus exclusively on your ideas?
What else, but money? I'll need money to buy the hardware I need. If my father gets into an accident, I'll need money to support myself. Computer hardware is not infinitely durable. If something happens to my PC, how am I to replace it without money?
How about you, any progress on the job search front?
Horrible. I thought it was just my resume, but...
https://news.ycombinator.com/item?id=34725047 Ask HN: Laid off folks, are you getting hired?
Given the economic environment with a lot of senior devs entering the market, it would be weird if anybody was interested in a hobbyist like me. I didn't get literally nothing though.
When I posted on the F# sub, one guy was interested, but for that F# position I'd need to relocate to Austria. Also I got in touch with a Serbian guy, but local salaries here in Croatia are really shitty, and even worse in Serbia, so I was never interested in working locally. As an example, while I was looking at the LinkedIn notification tab, I noticed one Cro company in the big city 1h drive away was hiring .NET devs. The salary is 12-16k euro per month. It is a waste of time.
Well, it depends on what kinds of jobs the guy manages to find. He wants to take the role of an agent/CTO and is putting together a technically capable team so we'll see how it turns out.
Personally, I am willing to work on anything as long as it is remote, but I do not want to spend my time competing for jobs as a freelancer as the jobs are always so lowly paid, which is why I am applying to startups. This gives me time to build up my webdev skills.
I have to admit, F# is really wonderful right now for this purpose. Its Fable compiler even compiles to Python these days, which gives me access to all its ML libraries.
In a way this period where nobody is calling me for interviews suits me just fine. I am not expecting anything, so I am not stressed out about the interviews. The night before the interview with the Serbian guy, I could not sleep properly.
My preference would be to work for a startup. Maybe an artist or a designer could make it as a freelancer, but just what kind of project can you build in a short amount of time as a programmer? Not much.
Anyway, there is no forcing it in the current situation. I've gotten rejected from half the places I applied to, but the rest are still pending. I'll let them float for a while. Later on, if having no pro experience turns out to be such a big deal, I'll just make some up. Let me tell you, a couple of months ago, I tried pretending to be an ex Google/Tesla/Microsoft engineer, and the places I applied to were pestering me for an interview. But the environment is not right for that.
The Serbian guy I mentioned pushed me into the direction of webdev, and I know already that most of the money is in that, so I've yielded to it. It will take me a few months to become really proficient doing it in a functional style, but after that I'll be capable of anything as a programmer. I'll make a few portfolio pieces like a CFR Leduc/Holdem agent, as well as my personal website. I still want to make Youtube vids, but the context has changed - I'll make something others can log into online and check out. The Youtube videos will be presentations of my work.
I am wondering, what is your skillset like? Python?
https://zaid-ajaj.github.io/the-elmish-book/#/
Currently I am reading this. I thought it would just be a UI book, but it is a pretty good webdev book. Back in 2020 I had a lot of trouble absorbing this as I wanted to work on Spiral and only wanted to learn enough to do the VS Code plugin for it, but now that I am diving right into it, I feel like I am absorbing it like a sponge. It is pretty fun.
///
7:40pm. This was a bit too wordy, but it is good enough. I am done for the day.
I want to read the Ragweed Princess. I've been getting into it lately. Tomorrow I will finish the Elmish book and look at the SAFE Stack examples. Oh right, I also want to look at the Feliz library. Well, one thing at a time. It won't be long before I can start work on my own projects."
FROMGIT: bpf: Do not change gso_size during bpf_skb_change_proto()
This is technically a backwards incompatible change in behaviour, but I'm going to argue that it is very unlikely to break things, and likely to fix far more then it breaks.
In no particular order, various reasons follow:
(a) I've long had a bug assigned to myself to debug a super rare kernel crash on Android Pixel phones which can (per stacktrace) be traced back to BPF clat IPv6 to IPv4 protocol conversion causing some sort of ugly failure much later on during transmit deep in the GSO engine, AFAICT precisely because of this change to gso_size, though I've never been able to manually reproduce it. I believe it may be related to the particular network offload support of attached USB ethernet dongle being used for tethering off of an IPv6-only cellular connection. The reason might be we end up with more segments than max permitted, or with a GSO packet with only one segment... (either way we break some assumption and hit a BUG_ON)
(b) There is no check that the gso_size is > 20 when reducing it by 20, so we might end up with a negative (or underflowing) gso_size or a gso_size of 0. This can't possibly be good. Indeed this is probably somehow exploitable (or at least can result in a kernel crash) by delivering crafted packets and perhaps triggering an infinite loop or a divide by zero... As a reminder: gso_size (MSS) is related to MTU, but not directly derived from it: gso_size/MSS may be significantly smaller then one would get by deriving from local MTU. And on some NICs (which do loose MTU checking on receive, it may even potentially be larger, for example my work pc with 1500 MTU can receive 1520 byte frames [and sometimes does due to bugs in a vendor plat46 implementation]). Indeed even just going from 21 to 1 is potentially problematic because it increases the number of segments by a factor of 21 (think DoS, or some other crash due to too many segments).
(c) It's always safe to not increase the gso_size, because it doesn't result in the max packet size increasing. So the skb_increase_gso_size() call was always unnecessary for correctness (and outright undesirable, see later). As such the only part which is potentially dangerous (ie. could cause backwards compatibility issues) is the removal of the skb_decrease_gso_size() call.
(d) If the packets are ultimately destined to the local device, then there is absolutely no benefit to playing around with gso_size. It only matters if the packets will egress the device. ie. we're either forwarding, or transmitting from the device.
(e) This logic only triggers for packets which are GSO. It does not trigger for skbs which are not GSO. It will not convert a non-GSO MTU sized packet into a GSO packet (and you don't even know what the MTU is, so you can't even fix it). As such your transmit path must already be able to handle an MTU 20 bytes larger then your receive path (for IPv4 to IPv6 translation) - and indeed 28 bytes larger due to IPv4 fragments. Thus removing the skb_decrease_gso_size() call doesn't actually increase the size of the packets your transmit side must be able to handle. ie. to handle non-GSO max-MTU packets, the IPv4/IPv6 device/ route MTUs must already be set correctly. Since for example with an IPv4 egress MTU of 1500, IPv4 to IPv6 translation will already build 1520 byte IPv6 frames, so you need a 1520 byte device MTU. This means if your IPv6 device's egress MTU is 1280, your IPv4 route must be 1260 (and actually 1252, because of the need to handle fragments). This is to handle normal non-GSO packets. Thus the reduction is simply not needed for GSO packets, because when they're correctly built, they will already be the right size.
(f) TSO/GSO should be able to exactly undo GRO: the number of packets (TCP segments) should not be modified, so that TCP's MSS counting works correctly (this matters for congestion control). If protocol conversion changes the gso_size, then the number of TCP segments may increase or decrease. Packet loss after protocol conversion can result in partial loss of MSS segments that the sender sent. How's the sending TCP stack going to react to receiving ACKs/SACKs in the middle of the segments it sent?
(g) skb_{decrease,increase}_gso_size() are already no-ops for GSO_BY_FRAGS case (besides triggering WARN_ON_ONCE). This means you already cannot guarantee that gso_size (and thus resulting packet MTU) is changed. ie. you must assume it won't be changed.
(h) changing gso_size is outright buggy for UDP GSO packets, where framing matters (I believe that's also the case for SCTP, but it's already excluded by [g]). So the only remaining case is TCP, which also doesn't want it (see [f]).
(i) see also the reasoning on the previous attempt at fixing this (commit fa7b83bf3b156c767f3e4a25bbf3817b08f3ff8e) which shows that the current behaviour causes TCP packet loss:
In the forwarding path GRO -> BPF 6 to 4 -> GSO for TCP traffic, the coalesced packet payload can be > MSS, but < MSS + 20.
bpf_skb_proto_6_to_4() will upgrade the MSS and it can be > the payload length. After then tcp_gso_segment checks for the payload length if it is <= MSS. The condition is causing the packet to be dropped.
tcp_gso_segment(): [...] mss = skb_shinfo(skb)->gso_size; if (unlikely(skb->len <= mss)) goto out; [...]
Thus changing the gso_size is simply a very bad idea. Increasing is unnecessary and buggy, and decreasing can go negative.
Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper") Signed-off-by: Maciej Żenczykowski [email protected] Signed-off-by: Daniel Borkmann [email protected] Cc: Dongseok Yi [email protected] Cc: Willem de Bruijn [email protected] Link: https://lore.kernel.org/bpf/CANP3RGfjLikQ6dg=YpBU0OeHvyv7JOki7CyOUS9modaXAi-9vQ@mail.gmail.com Link: https://lore.kernel.org/bpf/[email protected]
(cherry picked from commit 364745fbe981a4370f50274475da4675661104df https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=364745fbe981a4370f50274475da4675661104df ) Test: builds, TreeHugger Bug: 188690383 Signed-off-by: Maciej Żenczykowski [email protected] Change-Id: I0ef3174cbd3caaa42d5779334a9c0bfdc9ab81f5
refactor: use string template literals
note to more experienced, older dev me in the future: if you have found a way to make this automatically, then please feel free to laugh at your young yourself. my fingers fucking hurt.
It Came From Outer Spess: Adds midround changelings, delivered by an absolutely disgusting changeling meteor (#73018)
Adds a new dynamic midround opportunity and random event - Space Changeling.
2023-01-28.13-20-32.mp4
If you are fortunate enough to recieve this role, you will be stuffed into a changeling meteor and hurled at the side of the station. With no crew identities, no access, and no equipment, you'll have to rely on your free organic space suit and armblade to infiltrate the station and get settled.
With no disguises to fall back on, the midround changeling experience may lead to some very unfavorable situations. It's not unlikely that you'll be spotted making your way inside, or that someone will see the impact site and cause a panic. This role is not easy, but keep in mind that you also have nothing to lose in the event that you use Lesser Form/Headslug.
Aside from the starting circumstances, you have the same objectives and capabilities as a roundstart changeling. Getting inside of the station will be the hard part, but from there you can do what changelings do best and blend in.
A brief note on the free stuff you get:
You get the organic space suit and armblade for free. The space suit is absolutely vital, but I decided that the armblade should be given for free as well. It's necessary for breaking open windows or airlocks and getting access to the station, since otherwise your options are limited to arrivals/departures. Having to pay a 2 point tax to avoid walking naked into the main hallways of the station and getting gibbed is lame, and with the added difficulty of the role I think it's fair.
Also, this is my 100th PR here! :)
Adds midround changelings in a WAY COOLER way than just making a random crew/new arrival a changeling.
Lets people experience Hardmode Changeling, and test the adaptability and flexibility of the most versatile antagonist even harder than before. Losing the option to bypass the whole shape-shifter thing by disguising as your crew identity presents a welcome change to the formula.
Adds a teensy bit more midround variety, so we stop getting Nightmare At The Thirty Minute Mark every round.
🆑 Rhials add: Midround changeling spawn event. add: Changeling meteor. It has a present for you. /🆑
Proper name tags (#644)
-
Name Tag Asset is IN
-
More UI Stuff
Background layer, proper + Prefab stuff
- New Player Response Asset
just tried to make it a lil prettier really
- applied the prefab DURRRR
oops
- New version babyyyy
woooo
- FUCKIN FIXED THIS SHIT
BITCHEEEEZZZZ
- more fixes??
yes, more.
- last one
maybe
Co-authored-by: Max [email protected]
Extract nkError diagnostics data
nkError has a reportId which unfortunately opens any possible
"report" crawling its way in there. This commit introduces a new
design where nkError owns it's diagnostic data, as well as,
ast_types where nkError and friends are defined, owns the data
types. Report and all the associated cruft now is there simply to do
rendering.
Report still handles, routing and final consolidation, but in future
developments that will likely evolved further.
Overall Change:
- AST/Sem drop
ReportIdand associated memory leak - AST/Sem now define a diagnostic type and are primary data owners
Reportis now used in legacy situations and rendering, the former is to be addressed in future commits
What didn't change/major caveats:
structuredReportHookstill usesReport, this consequences...conceptand{.explain.}related erros have regressed, their tests marked with known issue, as this isn't a full conversion- diagnostics involving magics, have inconsistent rendering, a pre- existing issue, sorting this out is future work
Each module should own/define the data types that it's fundamentally in
charge of. Modules which are effectively components, like lexer,
parser, vm, etc, should produce diagnostics, events, telemetry,
whatever and their caller should handle output/rendering of these. The
key part about that last point is that the renderer and its format must
not be pushed into these modules, rather the renderer should consume
what they produce (directly or via an intermediary/translation).
For those wondering about why a value type was use inside the nkError
instead of the current ref object. I ran 3 bootstrap runs with each
version of nkError, and with the TAstDiag (value type) was
consistently ~10% slower during the bootstrap process.
| run | type | real | user | sys |
|---|---|---|---|---|
| 1 | pastdiag | 28.675 | 27.056 | 2.527 |
| 2 | pastdiag | 28.184 | 26.663 | 1.372 |
| 3 | pastdiag | 28.276 | 26.682 | 1.446 |
| 1 | tastdiag | 31.562 | 29.245 | 3.236 |
| 2 | tastdiag | 30.453 | 28.413 | 1.871 |
| 3 | tastdiag | 30.368 | 28.311 | 1.896 |
| type | real | user | sys | summary |
|---|---|---|---|---|
| pastdiag | 28.38 | 26.80 | 1.78 | avg |
| tastdiag | 30.79 | 28.66 | 2.33 | avg |
| pastdiag | 0.20 | 0.17 | 0.50 | avg dev |
| tastdiag | 0.51 | 0.39 | 0.60 | avg dev |
The report data types are rather bloated, eg: using Int128 for
enum high/low values.
For diagnostics, it's best to capture very little data, and then query within the rendering layer. Temper this where querying is reproducing complex analysis, reconstituting heavy context, or keeping data large data sets alive just so it can be queried later.
It's very possible we don't clean-up the symbol table of abandoned analyses. This likely results in space leaks, or rather an overhead while processing each module.
This style of conditional 0 < foo is forbidden, it's just not
accessible code and prone to reasoning and ultimatley logic errors.
When doing inline error state representation in a data type, such as
TLineInfo, where the invalid state is
TLineInfo(line: 0, col: -1, fileIndex: InvalidFileIdx), the default
initiatlization of objects is not our friend. This became a minor issue
during nkError construction. Where the line info on the provided
wrongNode: PNode parameter might be invalid. Hard to say, as the
default initialization is technically a valid location. A heuristic was
put into place to work around it and I think it'll hold until we fix it
properly. I see this as a language design problem, now one could argue
that a better selection of invalid state is required, but when working
in a retroactive case such as this, it's a non-starter. Furthermore, the
ergonomics of {.requiresInit.} leave much to be desired. I'm not sure
what exactly the answer is, but I think this is the difference between
something very primitive like a struct vs an actual object.
A number of node consts sets in ast_query and related modules are not
defined as compositions of each other. This can easily lead to changes
that only impact partial parts of the compiler and introducing yet more
bugs. This might be worth of a compiler style guide remark.
Just like a large amount of imports is likely a source of issues, so are
broad exports, avoid these like the plague. Removing these from
reports and related modules resulted in a number of significant and
hard to debug errors -- first encountered within CI, via a bors try.
They manifested as a doc gen build failure, which was seen as an
undefined symbol error. All because reports and friends were
exporting large swaths of other modules, eg: ast_types. After much
debugging and fixing error diagnostics to provide recursive dependency
detection as part of those unindentifier errors, it was fixed. It wasted
an entire day. Exports just create massive public surfaces, don't do it.
Finally, this commit impacts a very wide swath of the compiler, lots of code had to be updated, along with many stylistic fixes. What follows is a list of more detailed changes, in no particular order:
ast_types/nkError higlights:
- defines all its own diagnostic data types for
nkError - design-wise,
nkErrornodes are now much more likely to contain the immediate ast they're taking the place of, like a true wrapper. This should allow for easy recovery by simply gettingn.diag.wrongNode. - call mismatch related types (
SemCallMismatchandSemDiagnostics) moved toast_types - moved
NodeIdintoast_types frompacked_ast, so it can be used more broadly, such as inPAstDiag` as mentioned above. - Removed
ReportID, insteadPAstDiaguses theNodeIdof the first error node they're embedded inas theirdiagId. This is an easy way to have a monotonic sequence, while also some correlation between diag and error node. Due to copies, thediagIdandPNode
ast procs like newNode no longer have to care about sons on
nkError nodes, this also stops accidental traverls.
ast_query literal node kind const as sets
Now, various const set ranges relating to literals were defined
independently, now only the smallest sets are, while bigger sets are
defined based on the smaller sets. Going forward, this should ensure
adding new node kinds updates all broader ranges.
means: nkLiterals* = nkIntLiterals + nkFloatLiterals + nkStrLiterals
Extracting a style guide remark out of the commit message would be a
good idea.
msgs now bridges translating PAstDiag to legacy Report for routing
and rendering. Although, routing should probably not be part of Report
stuff.
Moved illformed ast message creation routines earlier in msgs to
reuse them when generating legacy report message strings. String
generation should move to a rendering layer in the future.
More consistent VM/Gen event to AST diag mapping, mostly within
compilerbridge which now has simplified/fewer pathways.
Removed traceReason from VM stacktrace events
This includes legacy reports, the primary motivation is that it was
being captured and not used. Additionally, not all stacktraces can be
related back to a meaningful vm event.
Also, the fixing up of data types also resulted in some code
simplification in vmgen and sem.
Clean-up identifier errors and fix vm err location
- cleaned up various expected identifier messages
- vm errors now capture instantiation info correctly
- errors don't set location data on diagnostics if already present, to honour overrides
Diag mapping in vm and vmgen was updated.
Mapping vm and vmgen events to PAstDiag are presently in their
respective modules as they both directly depend upon ast_types. Not an
ideal situation, but a lot more refactoring is required until vm is
free of AST knowledge/dependencies.
options module now manages ReportSet as a simple collection of
NodeIds of diagnostics that have been reported.
Removed ConfigRef param from types.typeMismatch, it wasn't being
used
Better error for is with wrong number of args:
- previously:
wrong number of arguments - now: `'is' operator takes 2 arguments'
- fixed
tests/errmsgs/tmisctest to match wording
Undeclared identifier errors now output any recursive modules imports that were detected as those can be a cause of such errors.
Recursive dependency tracking from the importer is cheaper, as it now only stores FileIndex pairs. Unfortunately, we don't have a clearing mechanism, so new minor space leak. :/
removed some eager diag message data querying
Fixed doc gen error report rendering, which weren't outputing the full text, making it impossible to find where errors/hints/warnings were occurring. Without this fix, it meant an unclosed backtick in a doc block was breaking CI... cool.
Removed some bounds tracking in reports
A number of Reports are tracking, but never using a pair of Int128
in order to know out of bound issues for arrays, ranges, ordinals, etc.
The data is rarely if ever output in messages and that's a lot of
bytes in most cases. Disabled whereever this was inconvenient, it can be
restored for error messages we wish to improve as future work.
Created rsemBigOrdsEnergy to not overload mismatchCount tuple with
Int128 bloat, and moved the following reports there:
rsemSetTooBigrsemArrayExpectsPositiveRangersemInvalidOrderInEnum(partial list) No longer capturecountMismatchdata for these as it's unreported:rsemExpectedLow0DiscriminantrsemExpectedHighCappedDiscriminant(partial list)
The errorKind property now returns a TAstDiagKind
Errors related to positions in calls where identifiers are expected have been updated to provide a bit more context:
- dot calls, callable fields access, etc errors wording update,
indicating the problematic identifier and then the call expression
within which it was found. See:
rsemExpectedIdentifierWithExprContexthandling incli_reporter - updated
astreprto handle newdiagfield ofnkErrorvariant Resulting in the following test changes: nimsuggesttesttchk1updated for messages with "found" wording instead of "got"
countMismatch in reports are now ints, instead of Int128,
seiously, how many were we expecting?
The string value of mSizeOf as "sizeOf" was taken from VM tests, but
doesn't jive with other tests that serialize the same magic. Need to
figure out which convention to go by.
concept and {.explain.} error msg regression
The compiler presently doesn't emit useful diagnostics for these,
simply a count of number of diagnostics failed. The implementation is
tied up with structuredReportHook, which in turn uses Report, and
there isn't a reasonable way to turn this into PAstDiag for
consumption. The following tests are disabled knownIssue:
- tests/lang_experimental/concepts/t3330
- tests/lang_experimental/concepts/texplain
- tests/lang_experimental/concepts/twrapconcept
Noted issues with the reports module and friends, hopefully it wards
off any further profileration and people can help with incremental
rework.
types.semReportTypeMismatch no longer takes a ConfigRef parameter.
This turned out to be unnecessary/unused after all the diag changes.
sigmatch has fewer dependencies on reports_sem
getReport moved to msgs, dropped conf param
Creating a new use qualifier diagnostic via
semstmts.newSymChoiceUseQualifierDiag will assert that there are at
least two choices to avoid spurious errors.
Removed a number of compile warnings by removing unused imports.
updated astrepr to use ast diagnostics from nkError nodes.
Reduce broad exports by Report related modules:
reportswas leakingast_typeseverywherereports_basehad overlapping exports
Formatting/Style clean-ups in these modules
Random Report Changes:
- remove
rsemUserRaw, it's never used - renamed
rrsemCompilesErrortorsemComplesHasEffects
Special thanks to zerbina for all the code reviews and suggestions!
Co-authored-by: zerbina [email protected]
Document Silent Messages. (#5910)
Hey folks!
This is actually my 2022 hackweek project which I got to finish to completion. :)
During a message send request, if you include the new
SUPPRESS_NOTIFICATIONS flag it will not broadcast any push/desktop
notifications but will still increment the relevant mention counters.
The intention is that you can get someone's attention but not feel like you could be distracting them. Like when you DM someone at 5am. I'm sure some bots can leverage this as well to avoid noise or something.
Also this should work for the webhook send request as well.
[Add a picture of the UI here]
If you're looking to leverage this as a non-bot, you can write @silent
as the very first thing in a message. Make sure your client is
up-to-date btw. Autocomplete a-la @everyone is not planned. Eventually we may
put this in an "actual UI", for now this is where it lives. :)
Also sorry to all the users on Discord named silent who may have some textual conflict now. Forgive me!
Admins can now choose where fish go (#73109)
I've pigeonholed myself as the fish guy now. It seems like someone made events easier to add admin controls for so I thought I'd add some to the event I most recently touched.
Instead of letting the RNG choose admins can now direct a circle of carp to converge upon a specific location, or even a trail of specific locations if they want the carp to just sort of swim in a circle around the space station (although the ones on the far side of the station from the starting point will travel all the way through it to get there). This also works with magicarp. They don't really move fast enough for you to use this to punish a specific person but you can use it to annoy a specific location full of people.
Plausibly there's no reason the code wouldn't work for a specified atom instead of a turf (as long as it sticks to one z level) but I couldn't think of an elegant way of selecting that whereas "use my current ghost location" is very intuitive, so I didn't add one.
Plausibly this permits admins do more fun things.
🆑 admin: Admins can direct where carp (or magicarp) are interested in going when manually triggering the event /🆑
Captain's Spare ID Safe Can Only Hold ID Cards (#72584)
I've personally seen this strategy play out the exact same way on more than one occasion in an higher frequency lately (I've never played as either side, just witnessed it)- and it always just seems to be an abuse of a skewed in-game mechanic. So, this PR makes it so that you can only put IDs into the spare ID safe. Nothing else.
I think this balance change is needed because it really sort of ruins what I like about nuclear operatives, having to run around and stay fluid for whatever the nuclear operatives could have, not "HAHA WE WILL PUT IT IN OUR (NEARLY) IMPENETRABLE SAFE THAT THEY WILL NEED TO USE A C4 DIRECTLY ON AND JUST END UP PLAYING BLOONS TOWER DEFENSE SIX AS WE AWAIT THOSE RED FUCKS TO ARRIVE". I miss when it would be fun to inject it into a monkey who could crawl around vents, put it in a disposals loop around the station to keep the nukies on a wild goose chase, or just holding your ground in the brig and retreating if they batter you down. It's just a very OP location in a very OP place with lots of warranted OP armor for it's intended use case, which is not really being followed by putting the all-important disk in the safe.
It's just very strong overall due to how protected-from-damage the spare ID safe is, and I don't really like the fact that this is emerging as a new "meta gameplay" (even used when there aren't any nuclear operatives), it just sullies the different variety of ways you can defend yourself against nuclear operatives when there appears to be the clear choice. I don't like that concept where you can have a strategy so good that you shouldn't do it.
Also, it's an ID Safe. Not a disk safe.
🆑 balance: Due to materials costing a lot more than ever, Nanotrasen's Spare ID Safe Supplier have cut down on the space inside of the ID Safe, meaning you can only cram in things as thin as an ID Card. /🆑
whitepaper
Singers and actors, gather round! The ultimate competition for aspiring artists has finally arrived! The Singer and Actor Contest is the perfect platform to showcase your talents and take your career to the next level.
Whether you're a seasoned performer or just starting out, this contest is open to all levels of experience. Showcase your singing or acting abilities to a panel of industry experts and compete for the chance to win exciting prizes and opportunities.
With a mission to support and encourage aspiring artists, this contest is designed to provide a platform to perform and share your work with the world. Whether you're a singer or an actor, this contest offers a chance to shine and gain recognition for your skills and hard work.
So what are you waiting for? Sign up today and unleash your full potential. The Singer and Actor Contest is the perfect opportunity to take your talents to the next level and achieve your dreams!
backgrounds, consistency, and style
- improved formatting on input "buttons" used in lines and shading windows ("buttons" are a better height, and infobuttons float right now)
- moved all definitions of objects/dictionaries meant for holding commonly accessed elements into v2helperscript.js
- added descriptions of what each script is for to v2.html
- background keeper object is unfortunately stored in base-value-manager.js for right now so it doesn't break but i want to make that better
- fixed several functions where i forgot to say "this." because i forgot js is silly, so many more functions should work now
- made lineart and shading classes but idk. we'll see
- added background support and you can actually count them already :)
- info window is now hidden using its own special function so it stops acting weird
- reduced / swapped out debug buttons to more relevant things. sorry showMessage tests
- removed unused craftSize section left over from v1, as that's handled in base values now
- changed "lineart bonuses" to just "lineart" to fit better with the other buttons
Fix reloading when using useAnimatedKeyboard (#3932)
Fixes software-mansion/react-native-reanimated#3786
On the main thread CADisplayLink calls updateKeyboardFrame 60 times
per second. Calling updateKeyboardFrame calls listener on the JS side.
When reloading the runtime gets destroyed on the JavaScript thread. So
when those two things happen at the same time (which in this case
happens often) we get the crash that we're trying to call a js function
on destroyed js runtime.
NativeReanimatedModule::~NativeReanimatedModule(), we're cleaning up
everything here:
I've tried and it appeared to work at first but I still got crashes when
running the 1000 listeners
example
and probably that's why:
So when ~NativeReanimatedModule is being called the runtime related
stuff is already deleted and there is a short window of time that the
runtime is being deleted and we still call js stuff, or at least that's
my theory 🤷♀️
So my proposition for now is to listen for
RCTBridgeDidInvalidateModulesNotification notification. It's called
just before deleting happens. Also I'm using
RCTUnsafeExecuteOnMainQueueSync because I want to wait until the
listeners are completely deleted on the main thread and then delete js
stuff.
If you look a bit above [[NSNotificationCenter defaultCenter] postNotificationName:RCTBridgeDidInvalidateModulesNotification line in
React code you'll see that React calls invalidate on all modules' data
before even posting the notification. Maybe we should clean reanimated
stuff here. I haven't explored that though yet and I don't know where is
reanimated's module data and what is module data at all and where to put
that invalidate function, I just got this idea while posting this PR.
Just run AnimatedKeyboardExample and reload the app. Also the the 1000 listeners example nicely catches other data races.
Tested with changes from software-mansion/react-native-reanimated#3911 and it works Also tested on FabricExample and surprisingly it also works.
[kibana] Thank you for everything, Spencer! 🧔🏻♂️ (#150759)
Inspired by @kertal, and extracted from his PR elastic/kibana#150660, specifically @thomasneirynck's proposal.
Holding for 24 hours, for our friends in later time zones.
Several of us felt a dev-only easter egg-- where, if you're lucky, @spalger joins you as you test your latest feature-- would be a fun tribute as he leaves us for new and exciting opportunities.
Elasticians, feel free to send your love to @spalger in the channel of your choice, of course, but we'd appreciate your review of this pull request. ❤️
Co-authored-by: spalger [email protected]
Updating: 2/10/2023 11:00:00 PM
- Added: Sit. · Rafal Pastuszak (https://sonnet.io/posts/sit/)
- Added: In defense of Junior Engineers - Jampa.dev (https://jampa.dev/posts/why-when-and-how-to-hire-junior-software-engineers)
- Added: User or *User - Do We Need Struct Pointers Everywhere? (https://preslav.me/2023/02/06/golang-do-we-need-struct-pointers-everywhere/)
- Added: The Joy Of Duplexes (https://codahale.com/the-joy-of-duplexes/)
- Added: On Vercel: If some of my sites are down… (https://remysharp.com/2023/01/30/on-vercel-if-some-of-my-sites-are-down)
- Added: I hate stackoverflow and ChatGPT is my savior (https://fgclue.wordpress.com/2023/02/09/i-hate-stackoverflow-and-chatgpt-is-my-savior/)
- Added: Extreme earners are not extremely smart (https://liu.se/en/news-item/de-som-tjanar-mest-ar-inte-smartast)
- Added: Data visualization with Metabase from CSV files with SQLite - Ritza Articles (https://ritza.co/articles/data-visualisation-with-metabase-from-csv/)
- Added: Efficiency traps (https://jorzel.github.io/efficency-traps/)
- Added: What's On Tap for .NET 8 (Preview 1 Coming this Month) -- Visual Studio Magazine (https://visualstudiomagazine.com/articles/2023/02/10/net-8-preview.aspx)
- Added: Why do you want to touch your Mac screen so badly? (https://morrick.me/archives/9715)
- Added: My most important email filter that helps me control my chaos (https://martin.sh/reduce-noise-by-filtering-newsletters/)
- Added: The Pareto frontier of foreign languages - Tanner Hoke (https://tannerhoke.com/posts/pareto-languages/)
- Added: We Should Communicate Probabilities With Flips (https://blog.charliemeyer.co/we-should-communicate-probabilities-with-flips/)
- Added: Experimenting with PeerJS (https://rtnf.bearblog.dev/experimenting-with-peerjs/)
Generation took: 00:09:05.7670844 Maintenance update - cleaning up homepage and feed