TLS Initialization

WASI-libc initializes TLS with this function: WASI-libc TLS Initialization. Currently, we are failing because dl_tls_static_size and dl_tls_static_align in glibc-nptl are never initialized. It is assumed that other functions dependent on this TLS initialization will also fail. We need to determine if our libc is currently calling any function to initialize TLS, and if not, why this is the case. Subsequently, we need to find a way to integrate the WASI-libc version of TLS initialization with our libc.

Let's talk tomorrow and see what we can figure out about this

I think the first step is to see if our libc is calling some sort of tls_init function at all on startup. It would be super helpful to be able to see what functions glibc calls before main(). If there is some sort of function being called that probably would be the best place to try to integrate what wasi-libc is doing.

Nick and Professor Cappos raised a great point that init_static_tls  should be called before the main function, possibly in the crt1.o file.

In WASI-libc, crt1.o will call __libc_start_main, which then calls __init_libc, and subsequently calls __init_tls(aux).

Here is the current crt1.c we are using, but encountered some errors:
#include <stdlib.h>

// Declaration of the external main function
extern int main(int argc, char **argv, char **envp);

// Declaration of the __libc_start_main function
extern int __libc_start_main(int (*main) (int, char **, char **),
                             int argc,
                             char **ubp_av,
                             void (*init) (void),
                             void (*fini) (void),
                             void (*rtld_fini) (void),
                             void (*stack_end));

// Weak definitions for init, fini, and rtld_fini
void __attribute__((weak)) _init(void) {}
void __attribute__((weak)) _fini(void) {}
void __attribute__((weak)) _rtld_fini(void) {}

void _start() {
    int argc;
    char **argv;
    char **envp;
    __libc_start_main(main, argc, argv, _init, _fini, _rtld_fini, 0);
    // main();
}

void __wasm_call_dtors() {

}

void __wasi_proc_exit(unsigned int exit_code) {

}

wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_end
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_end
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_end
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __preinit_array_end
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __preinit_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __preinit_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __preinit_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __init_array_end
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __init_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __init_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __init_array_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(dl-support.o): undefined symbol: _dl_sysinfo_int80
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(dl-support.o): undefined symbol: __ehdr_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(dl-support.o): undefined symbol: __ehdr_start
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(dl-support.o): undefined symbol: __ehdr_start

wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_end
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_start

Learning from wasi-libc, above errors can be solved by initializing both extern void (*__fini_array_start []) (void) 0; and
extern void (*__fini_array_end []) (void) 0; into 0 in /glibc/csu/libc-start.c::160

This sounds like a good strategy overall.  Let's look at both wasi-libc and
glibc and really understand what they are doing and why.  Then we can model
our design on whatever is most appropriate.
On Thu, Jul 11, 2024 at 5:48 PM Yuchen Zhang @.***>
wrote:

wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_end
wasm-ld: error: ../../glibc/sysroot/lib/wasm32-wasi/libc.a(libc-start.o): undefined symbol: __fini_array_start
Learning from wasi-libc, above errors can be solved by initializing both extern
void (__fini_array_start []) (void) 0; and
extern void (__fini_array_end []) (void) 0; into 0 in
/glibc/csu/libc-start.c::160
—
Reply to this email directly, view it on GitHub
https://github.com/Lind-Project/lind-wasm/issues/2#issuecomment-2223999504,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGROD5Z6QFMVKJQZRK5CQ3ZL34UPAVCNFSM6AAAAABKT6LUBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTHE4TSNJQGQ
.
You are receiving this because you were assigned.Message ID:
@.***>

Previously, we encountered the error of not initializing dl_tls_static_size and dl_tls_static_align. After discussing with Professor Cappos and Nick, the solution was to call TLS initialization before the main function (in crt1.c). After checking the source code and testing, I now know that we should call __libc_setup_tls, which will then call init_static_tls. Since __libc_setup_tls is a void function, we don't need to provide any arguments.
Using GDB to follow the execution path, I confirmed that the previous error has been resolved:
int a = GLRO(dl_tls_static_size);
int b = GLRO(dl_tls_static_align);
(gdb) p a
$1 = 2048
(gdb) p b
$2 = 64

Now, I will to move forward to address the error:
Caused by:
    0: failed to invoke command default
    1: error while executing at wasm backtrace:
           0: 0x26e04 - <unknown>!__libc_message_impl
           1: 0xd3af - <unknown>!__libc_assert_fail
           2: 0x34b9d - <unknown>!allocate_stack
           3: 0x33cff - <unknown>!__pthread_create_2_1
           4:  0x599 - <unknown>!__original_main
           5:  0x4ea - <unknown>!_start
           6: 0x41d6f - <unknown>!_start.command_export
       note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information
    2: memory fault at wasm address 0x8dfb4000 in linear memory of size 0x30000
    3: wasm trap: out of bounds memory access

Now, the error is due to an assertion failure:
      /* Adjust the stack size for alignment.  */
      size &= ~tls_static_align_m1;
      assert (size != 0);

in /glibc/nptl/allocatestack.c

After discussing with Professor Cappos and Nick, we decided to adopt WASI-libc's threading part into glibc. The reason is that simply calling __libc_start_main is not working because it also initializes the .fini_array, which is a section in ELF binaries, and WebAssembly doesn't support that.
I have recompiled WASI-libc with debug info and am now able to use GDB to trace the execution path:

_start(void) in /wasi-libc/libc-bottom-half/crt/crt1-command.c
__wasi_init_tp() in /wasi-libc/libc-bottom-half/crt/crt1-command.c
__init_tp((void *)__get_tp()); in /wasi-libc/libc-top-half/musl/src/env/__init_tls.c
__init_tp(void *p) in /wasi-libc/libc-top-half/musl/src/env/__init_tls.c

I am now integrating the WASI-libc threading implementation into glibc and have migrated __init_tls.c into the csu directory and updated the Makefile accordingly. After fixing many define and initialization issues, we are now facing these errors:
__init_tls.c:287:21: error: '__builtin_wasm_tls_align' needs target feature bulk-memory
        size_t tls_align = __builtin_wasm_tls_align();
                           ^
__init_tls.c:288:28: error: '__builtin_wasm_tls_base' needs target feature bulk-memory
        volatile void* tls_base = __builtin_wasm_tls_base();

It seems like these two functions need to be enabled by the WebAssembly target feature in clang/llvm.

The functions __builtin_wasm_tls_align and __builtin_wasm_tls_base are WebAssembly-specific built-in functions provided by LLVM to handle thread-local storage (TLS) in WebAssembly. These functions are part of the WebAssembly support in LLVM and Clang. After checking the Makefile of the WASI-libc implementation, I found that adding -mbulk-memory to the CFLAGS enables that feature, which fixed the issue mentioned above.

In order to create a thread stack, glibc will use mmap to allocate the memory, and mmap is not fully support by our version of glibc , so working on that now.

WASI-libc does not support mmap in the same way that traditional operating systems like Linux do because the WebAssembly System Interface (WASI) is designed to be a lightweight, secure, and portable interface for WebAssembly (WASM) modules. Here are the key reasons:
1. Portability and Security:
WASI aims to provide a secure and portable interface for running WebAssembly modules across different environments. Traditional mmap functionality, which allows direct memory mapping, can introduce security risks and complexity. WASI focuses on maintaining a simple, consistent interface that can be safely implemented across various platforms.
2. Simplified Abstraction:
WebAssembly is designed to run in a sandboxed environment, where direct access to low-level memory management features like mmap is restricted. This sandboxing is crucial for ensuring that WebAssembly modules cannot perform unsafe operations that could compromise the host environment.
3. Lack of Underlying OS Support:
WebAssembly is designed to be platform-independent, meaning it does not rely on specific operating system features. mmap is an OS-specific system call, and supporting it directly would require WASI to provide abstractions over many different operating systems, which goes against its design principles of simplicity and portability.
4. Use of Emulation Libraries:
To provide similar functionality where necessary, WASI supports emulation libraries like wasi-libc that can offer limited mmap-like capabilities. This emulation is done to provide basic compatibility for applications that rely on mmap, but it is not a full implementation of the mmap system call.
Example of Enabling Emulated mmap in WASI
As seen in the error message you encountered, WASI provides minimal mmap emulation that can be enabled by defining _WASI_EMULATED_MMAN and linking against the wasi-emulated-mman library. This allows for basic memory mapping operations within the constraints of the WASI environment.
Summary
WASI-libc's lack of native mmap support is a design choice aligned with WebAssembly's goals of portability, security, and simplicity. By using emulation libraries and adhering to WASI's constraints, developers can still achieve necessary memory management functionality in a way that is consistent with WebAssembly's architecture.

After discussing with Professor Cappos and Nick, we are now attempting to use __wasi_thread_spawn in WASI-libc instead of __clone_internal. However, we are encountering the following issue:
Error: failed to run main module `thread.wasm`

Caused by:
    0: failed to instantiate "thread.wasm"
    1: unknown import: `wasi::thread-spawn` has not been defined

After migrating the WASI-libc threading code, we encountered the following error:
Error: failed to run main module `thread.wasm`

Caused by:
    0: failed to instantiate "thread.wasm"
    1: unknown import: `wasi::thread-spawn` has not been defined

This issue was due to the threading configuration not being enabled at runtime. By adding the --wasi threads=y flag, we then encountered another error:
Error: unknown import: `wasi_snapshot_preview1::lind_syscall` has not been defined

After examining the source code of Wasmtime, we discovered that since threading support is experimental, the developers have separated thread and preview into two independent modules. Therefore, we need to enable both --wasi threads=y and --wasi preview2=y at runtime.

After fixing the above issue, we are now encountering the following error:
2024-07-26T16:52:15.657304Z ERROR wasmtime_wasi_threads: failed to find a wasi-threads entry point function; expected an export with name: wasi_thread_start

thread 'main' panicked at /home/dennis/Documents/lind-wasm/wasmtime/crates/wasi-threads/src/lib.rs:138:21:
thread_id = -1

I have now integrated the WebAssembly format assembly code wasi_thread_start.s into glibc, compiled it into an object file (.o), and linked it into the sysroot. However, at runtime, we encounter the following error:
Invalid input WebAssembly code at offset 230547: global is immutable: cannot modify it with global.set

It seems to be due to the global.set __stack_pointer and global.set __tls_base instructions in the assembly file.

Hmm, I believe the globals are defined in the asm file. So it's weird this is happening there. Are there some compilation options were missing?

Previously, our implementation of lind_syscall was located in the preview2 module in Wasmtime. However, since the thread module is experimental, developers have made the thread implementation a separate module, causing conflicts between preview2 and the thread module. The command we were using was:
/wasmtime/target/debug/wasmtime run --wasi threads=y --wasi preview2=y thread.was

After discussing with Coulson and Qianxi, we decided to port the lind_syscall implementation into wasi_common as well. Qianxi did a great job on this, and here is the commit: https://github.com/Lind-Project/wasmtime/commit/4663b69cd1f0fc99d86d217854c05e7be6fbc8e8. Now, we only need to enable --wasi threads=y to activate the thread module.

Great update! Seems like this is really close.

Now we have fully implemented pthread_create, allowing us to print 'hello world' from another thread. The issues we encountered have been resolved by:

Adding -matomics -mbulk-memory to wasm-config.sh.
Adding -Wl,--shared-memory when compiling user programs.
This approach avoids modifying or making ad-hoc changes to any previous implementations in glibc or wasi-libc.

Next, Qianxi and I will continue working on the pthread_exit issue:
Error: error while executing wasm backtrace:
    0:  0x552 - <unknown>!undefined_weak:__pthread_unwind
    1: 0x3c671 - __do_cancel
                    at /home/dennis/Documents/lind-wasm/glibc/nptl/../sysdeps/nptl/pthreadP.h:271:3
    2: 0x3c671 - __pthread_exit
                    at /home/dennis/Documents/lind-wasm/glibc/nptl/pthread_exit.c:36:3
    3: 0x38436 - __wasi_thread_start_C
                    at /home/dennis/Documents/lind-wasm/glibc/nptl/pthread_create.c:276:2
    4: 0x381ec - <unknown>!wasi_thread_start
    5: 0x47e59 - <unknown>!wasi_thread_start.command_export

Caused by:
    wasm trap: wasm `unreachable` instruction executed

We will also working on the pthread_join issue.

some update on the pthread_exit issue:
we found that wasm reached "unreachable" instruction because there is no definition of "pthread_unwind" function, which is called by __pthread_exit. By reviewing decompiled wasm file (wat file), we noticed that this function is marked as "undefined_weak". After some searching around, it turns out this means that this function is declared as weak function, but it does not have an associated definition. However, pthread_unwind does have a definition in unwind.c, though it is not marked as weak here. So I tried to remove the "weak" keyword from pthread_unwind declaration, and it looks like it got linked successfully. But now a new error says "_Unwind_ForcedUnwind", which is called by pthread_unwind, is not found. It turns out that this function is defined and compiled as an '.os' file, not '.o' file. But we only include '.o' file when run gen_sysroot, so I added the .os file into sysroot, and now _Unwind_ForcedUnwind is also linked into the code.
The next issue is "__libc_unwind_link_get function is not found". This function has two versions depends on whether "SHARED" macro is defined globally. I first tried to recompile unwind-link.c (which contains the file) with SHARED flag set, and it is able to compile. However, when trying to run the thread code, it turns out that __libc_unwind_link_get will call libc_malloc (instead of the malloc used by threading, which is defined under malloc directory). The libc_malloc internally used mmap, so it will fail with "out of bound memory access".
I also tried to use non-shared version of __libc_unwind_link_get function, in which case this will just return a constant. In this case, the code is able to compile and run without any error. However when I looked into the wat file, I found out that the thread is still not exited successfully, it is instead entering an infinite loop that never return when calling __pthread_exit.
So looks like currently we have two ways to try, the first way is try to fix the __libc_unwind_link_get with correct malloc implementation. Or we can try what wasi-libc does for __pthread_exit (their __pthread_exit implementation looks significantly different from ours currently).

It seems we finally need to patch in futex(). You should experiment with my branch here: https://github.com/Lind-Project/lind-wasm/issues/1

Now, we are able to make pthread_join working with futex. We faced two issues along the way. The first issue is that the pthread struct in main thread is not shared with the pthread struct in the child thread. pthread_join requires pthread->tid to work, so if this is not shared, pthread_join will not work. We fix this issue by passing pthread struct into the start_args, so the child thread could use the same pthread struct as parent. Another minor issue is about futex implementation in rustposix. The first argument of futex_syscall is supposed to be the an address, but we are using u32 to hold the value, which would overflow in 64 bit machine. We fixed it by changing the argument type to u64.
So pthread_create, pthread_join and pthread_exit are all working right now, and I guess we are basically done for the pthread for now? (though pthread_exit will not be able to expose to user space, since looks like exiting a thread half way in not possible in wasmtime currently (at least without modifying wasmtime implementation), as the only way to make a thread legitimately exits is letting wasi_thread_start function returns).


60fpsFixes: add patch to improve framelimiter above 60FPS

Continued from older PR #25
(with the new framelimiter & UseDynamicFrametime setting in latest re4_tweaks most of this PR is no longer needed, the code that updates the settings menu with new framerates might still be useful in future though, so for now will probably just leave this PR as a draft.
There are still many issues with UseDynamicFrametime though, seems a lot of the game code is set up to only work properly when the frametime is exactly the same between frames, maybe some way of decoupling the graphics rendering from the deltaTime var would be good to look into...)

Hooks the ConfigReadINI call so we can update frametime used for framelimiter based on the variableframetime variable - with this it seems framerates above 60 can work without being too broken, likely many issues to be found (and hopefully fixed) though of course.
If anyone wants to try it out, here's a build with this PR:
(E: latest build can be found at https://github.com/nipkownix/re4_tweaks/pull/50#issuecomment-1046060996)
re4_tweaks1.7.3_framelimit-fix-v2b.zip
(old)
re4_tweaks1.7.3_framelimit-fix-v2.zip
re4_tweaks1.7.3_framelimit-fix.zip
In v2 the ingame settings now includes extra framerates (30/60/90/120/144) - if you want even higher you can edit your RE4 config.ini file.
Framerate should probably be a multiple of 30, but maybe others will work fine too, who knows.
You may need to set DisableVsync in re4_tweaks dinput8.ini if the new framerates don't work for you, or unset fullscreen mode in game settings (or in config.ini) - hopefully if your monitor supports the refresh rate natively it should just work though.
If re4_tweaks shows a message about framerate setting, set IgnoreFPSWarning to true in dinput8.ini (should already be set in the above ZIP)
If you notice anything weird please let us know about it here - most problems are likely things that were set for 30FPS timings, game probably also had the same issue at 60FPS too, but running at higher framerates makes things much more apparent (try using variableframerate 200 if you want to go on a bug hunt :)
TODO (both should be working in latest commit)

maybe hook ConfigWriteINI as well to also update framelimiter after user changed settings (done via hooking settings menu code)
find out whether 90/120/144 options could be added to ingame settings (seems possible!)

Framerate TODO

menu selection is tied to FPS (thanks to @Keith94 for reporting)
scope/binocular blur is broken again at higher framerates lel
footstep sounds seem messed up at higher FPS
enemies seem to turn around much quicker at higher FPS, and attack you almost instantly (so that means 60FPS has been hard-mode this whole time?)

Should note that this is different to the other FixSlowdown PR, that one tries allowing game to see the true delta-time between frames, instead of locking the delta-time to an expected FPS - which fixes the slowdown issue when the expected FPS can't be reached, but also exposes a lot of issues in a game that wasn't developed to work like it - if enough time is spent to understand the games animation system I'm sure those could be worked around, but right now there's not really enough known unfortunately.
(RE4VR might give us some clues about that, doubtful that they maintain the full 120FPS+ required for VR at all times, so likely they probably added improvements to allow delta-times, finding where those improvements were made would probably help us a lot - RE4VR was actually built on top of the QLOC port, so a lot of the fixes might transfer over pretty well)
Meanwhile all this PR does is allow game to also make use of 90/120/144Hz frametimes - without fixing the deltaTime issue at all - this seems to allow game to play at higher framerates without as many issues, but still means the slowdown issue happens when the expected FPS can't be reached.
At higher framerates like 90/120/144+ it's much more likely that game will miss the framerate target too, so I wouldn't really consider this a proper fix, mostly just something useful for showing what happens when higher framerates are used.

Great work so far!

scope/binocular blur is broken again at higher framerates lel

I imagined this would be a problem lol
Pushed a quick fix, should be working fine.
Also, I was going to push a commit to allow people to change the FPS without having to go back to the main menu, since this restriction doesn't appear to make sense:
// Allow the user to change the frame rate without going back to the main menu first
pattern = hook::pattern("F7 82 ? ? ? ? ? ? ? ? 74 ? 83 3D ? ? ? ? ? 75 ? 6A");
injector::MakeNOP(pattern.count(1).get(0).get<uint32_t>(10), 2, true);

Seems to work fine if I use it with the vanilla FPS list, but it.. forcefully closes the options screen if the custom FPS list is enabled. Not sure why. Feel free to add that in if you can find the problem.

Noticed an issue with the audio. Every footstep sound sounds like it's multiplied and repeats like an echo.
Same with Jars and boxes being destroyed as well as doors opening.

Gotta say I'm seeing a surprisingly low ammount of bugs at 144 fps. Nice!
Most notable ones were the slower aim speed (for which I pushed a fix), and sound issues like this one:
https://user-images.githubusercontent.com/33870163/151721012-ea77991a-cc1f-4ac7-8860-54e015b87275.mp4
This plaga sound kept looping after I killed it, for some reason.

@nipkownix those are all with 144Hz right? Have you tried with 120Hz at all? Could be that some of those issues were because of 144Hz not being multiple of 30.
IIRC I mentioned in one of these github posts before that main game loop seemed to be running at half the games framerate, (seemed like 60Hz = 30Hz game loop, so maybe 120Hz = 60Hz), wonder if that could be causing some of these issues with sounds & other things being duplicated.
I'll have to dig up that post, perhaps if it was forced to stay at 30Hz it'd stop some of these issues.

Edit3: Trash d3d9 AMD drivers probably play a part in this, since I'm getting a performance boost using DXVK. Oh well.

Wonder if D3D12 would perform better for you at all, I did a quick test of making the game use D3D9On12 but for me it just resulted in a huge performance loss (from ~180FPS down to ~80...), I think I've heard AMD is usually better than NV at running D3D12 though, so maybe wouldn't be as bad.
(then again info about D3D9On12 is pretty sparse, for all I know it wasn't even running in D3D12 and that could just be for making D3D9 interoperate with D3D12 things, not sure.)

Wonder if D3D12 would perform better for you at all, I did a quick test of making the game use D3D9On12 but for me it just resulted in a huge performance loss (from ~180FPS down to ~80...), I think I've heard AMD is usually better than NV at running D3D12 though, so maybe wouldn't be as bad.

I've tried Josh's whatever it is he named his dll and got a huge performance loss too. Also some geometry was pitch black for some reason. Guess it was shader-related.
DXVK is working nicely though. Still can't maintain 144 fps in every area, but oh well.

those are all with 144Hz right? Have you tried with 120Hz at all? Could be that some of those issues were because of 144Hz not being multiple of 30.

Ah yeah. I'll do some more testing and see if I can reproduce those issues at 120 fps.

Hm, just noticed PadRead has some ConfigGetVariableFramerate calls inside it, seems to use two different values for something for 30/60, seems easy enough to work out what they'd be for other framerates - @nipkownix do you know if any of your aiming patches affect that stuff at all?

Not sure if my aiming patches affect that stuff. I was aware there were checks in place. Maybe I should start to check it more in IDA.
My current patch just tries to make the delta values be consistent regardless of the frame rate, but I did notice it isn't perfect. Maybe the checks you mentioned are messing with it somehow.

I see that it's already on the TODO list, but it's not just the footstep sounds.
Every footstep sounds like it's multiplied and repeats like an echo, but so do other things too such as jars and boxes and other actions performed by the player / NPCs such as attacks etc.
Amazing work! Really can't wait to replay RE4 in 120fps mode and with fully remastered textures as well. This is what Capcom should've done in the first place. Once the bugs have been fixed, this'll be the ultimate way to play RE4, I can't wait! :D

That repeating/echoing effect occurs with the neck cracking sound after a suplex, even in 60fps.

Would like to update this to latest master but a lot of conflicts there.. @nipkownix maybe it's worth merging the aiming/mouse turning/FixSniperFocus stuff into master seperately of this PR? or have those already been merged maybe?

maybe it's worth merging the aiming/mouse turning/FixSniperFocus stuff into master seperately of this PR? or have those already been merged maybe?

Well, they haven't, but they're not really necessary unless we go above 60 fps. Meh.
I went ahead and rebased the PR on top of the latest master for you. Just tested a bit and everything seems to be fine.

Ahh right, wasn't sure if there was anything here that might have applied for 60FPS too.
Thanks for the rebase! Here's a build for anyone that wants to try it out:
dinput8-framelimit-fix-v3.zip
If you have issues running above 60, try toggling fullscreen in-game, or edit your games config.ini so first line ends with your desired framerate, eg. resolution 1920 1080 120.
Like I mentioned on Steam thread I haven't seen any major gamebreaking issues with this yet, mostly seems to just be audio related surprisingly, and there might be an issue with grenades exploding too (but that might only happen at 144Hz or other non-divisible-by-30 framerates)
Would still be interested in hearing of any other weirdness that it might cause though.

BTW if anyone finds any duplicated-sounds which can be triggered somehow (eg. moving into certain area triggers it, or pressing a button or something) please let me know, would help a lot with finding what causes that... (or is that not a problem with 120FPS, only 144?)

BTW if anyone finds any duplicated-sounds which can be triggered somehow (eg. moving into certain area triggers it, or pressing a button or something) please let me know, would help a lot with finding what causes that... (or is that not a problem with 120FPS, only 144?)

It happens at 120fps as well. Breaking objects such as the vases and boxes repeats as well as the footsteps etc. Been a while since I checked but I’ll try to get back to it and look for other audio issues while playing when I get back home.

Will update this PR soon. The master branch is now hooking the mouse delta stuff as well, so I'll need to adapt the aiming speed fixes here to fit there. (these shouldn't even be needed when using raw input though)

Updated to include the latest raw input work:
dinput8-framelimit-fix-v4.zip
The mouse aiming speed fixes ended up being needed even with raw input, though. Meh. Shouldn't cause any issues though.

I'm sure you already know this,
but at higher-than-60 framerates,
the repeat rate of moving your little selection square across your inventory is too fast,
and the repeat rate delay is far less, meaning it's too easy to overshoot.

Changing the Sleep(3) call at 0x97B83B to Sleep(90) (0x97B83C 03 -> 5A) seems to affect the 120Hz audio somewhat, kinda helps with the weird repeating/reverb that it has, but there's still definitely a difference between 60 & 120, mainly seems volume related somehow?
AFAIK the loop that holds that Sleep call is what handles audio in the game, seems to be running in a seperate thread & runs at whatever your CPU can handle though, changing variableframerate didn't seem to affect speed of it at all, but somehow changing the value for that Sleep call does have an effect, weird.

Wow, although it still has its bugs, playing through the game with 120FPS + raw input feels AMAZING. So smooth and responsive! No longer do I think the Wii version has the best controls 😅 If you guys manage to perfect both these tweaks, imo the gameplay would be superior to even the RE5 PC port(which doesn't have as nice mouse turning as yours). Here are some bugs that I noticed on a 120FPS Professional playthrough, hopefully there's something that helps:
-certain enemies get stuck in animation loop
https://user-images.githubusercontent.com/99100463/156760756-a8b91525-d5d1-425a-8f5f-08acd35249a2.mp4
-audio glitches such as multiplied audio(this happens with 60fps too) or skipping if too fast
https://user-images.githubusercontent.com/99100463/156761537-7adaac82-9ade-4142-bfb1-e654e8b148cb.mp4
-some attacks do less damage than on 30/60fps(these guys always die with 3 lanterns)
https://user-images.githubusercontent.com/99100463/156761402-6ea8c32e-3ef4-4e33-8851-6de041769608.mp4
-harder to run up elevations like these
https://user-images.githubusercontent.com/99100463/156760929-bae6784c-5f45-41b3-91e2-18240769edfc.mp4
-some enemy attacks do more damage than on 30/60fps
https://user-images.githubusercontent.com/99100463/156760910-1fa67fb6-4423-4456-b7b9-2245cc8ae019.mp4
-game is slow-motion in more demanding areas
https://user-images.githubusercontent.com/99100463/156760941-67521f11-3fcb-4e44-8a1f-25126509b84f.mp4
-character/environment models don't pop up correctly during cutscenes and such
https://user-images.githubusercontent.com/99100463/156761242-590a4372-9b4e-4d2a-8fd3-1cb602c10abc.mp4
Even with these issues, this is still my new preferred way to play, it's just so fluid... I'm hoping you guys manage to work out all the kinks eventually 🙏

Here's a build of 1.7.5 with the framelimiter fixes added, seems to still work as it did before:
re4_tweaks-1.7.5-framerateFix.zip

Here's a build of 1.7.5 with the framelimiter & aim speed fixes added, seems to still work as it did before: re4_tweaks-1.7.5-framerateFix.zip

Is there one without console? 🥺

i have a rtx 3080 / 12900 ks @ 5.4 ghz  and using the above fix with hd project and the re 4 tweaks
i run 1440p  270 hz gsync and was geting out of sync shooting .
now its working 270 hz perfectly sao far even when they throw dynomight no fps slow downs !
ill keep this updated

any updates ?

@emoose, got a weird enemy loop here:

They get stuck trying to get bombs to throw. Happens after a couple of successful throws at 240 fps.
The function looping is em10_R1_R305Bomber (but other normal bomber enemies are looping too, as posted earlier in the comments).
It loops here, because a1->pWeapon_610 is always null:

This section in the same func is supposed to set up pWeapon:

It works fine at first, but then em10MakeWeapon starts returning 0 all the time.
Apparently, what is actually failing is cManager_cEm_::createBack inside SetWeapon, called inside em10MakeWeapon. Haven't figured out why ::createBack fails though.

Haven't figured out why ::createBack fails though.

Maybe it's not clearing up older EmWep instances properly, and ends up hitting Em limit, is the count shown inside Em Manager near the max limit shown there?
We can increase that limit by editing CNS/Cons data (that stuff was brought up on the discord recently too), maybe it's just an issue of higher FPS meaning more EmWep instances are spawned at a single time, making it hit the maximum - or it could be an issue with them not being disposed properly.

Ah 60 is the default CNS value baked into the EXE afaik, might mean the room doesn't have a CNS value defined for it - maybe worth testing with that default value increased (int at 0xBFC044 in 1.1.0) and see if it still ends up breaking or not (changing that to something like 180 should be fine, seen other rooms using that at least)
Maybe there's some ceiling it hits where it starts to dispose of them, but ends up hitting that tiny 60 limit before it.
Still kinda strange that increased framerate makes so many of them spawn though, maybe there's an issue with it running that em10MakeWeapon code in multiple frames when it should have only really been ran once.

an y updates on  this ?  any  updates on no fps lock fixes on higher fps

It's been 18 months.
Has progress been made on this?
Is there another mainline release coming ever?

same the last update i can play@360 hz @ 360 fps ona14900 ks and rtx 4090  with minmal bugs just  fastswitching invintory and some audio bugs but shes like 90 % perfect

same the last update i can play@360 hz @ 360 fps ona14900 ks and rtx 4090 with minmal bugs just fastswitching invintory and some audio bugs but shes like 90 % perfect

What is the lastest FPS unlock build?


Simple POST to teams incoming webhook url is not working

We have a below go code to send notifications to teams channel. It was working fine for sometime. For the past 4 weeks, if we send 10 message, only 3-5 are getting delivered. That is also random.
And to make things worse, the response.StatusCode is always 200. And no code change for past 3 months. Could someone help to understand how to fix this issue ?
postBody := Message{
    Title:      "title",
    TextFormat: "markdown",
    Text:       "summary",
}

jsonValue, err := json.Marshal(postBody)
if err != nil {
    return fmt.Errorf("error on making request to teams webhook: %s", err)
}

req, err := http.NewRequest("POST", "teamsUrl-incoming-webhook-url", bytes.NewBuffer(jsonValue))
if err != nil {
    return fmt.Errorf("error on creating post request to teams: %s", err.Error())
}
req.Header.Set("Content-Type", "application/json")

resp, err := http.DefaultClient.Do(req)
if err != nil {
    return fmt.Errorf("error on making request to teams webhook for message %s: %s", title, err)
}
defer resp.Body.Close()

if resp.StatusCode == 200 {
    fmt.Printf("Sucessfully sent '%s' message to teams\n", title)
}

I tried to print the response body and response headers
v, _ := json.Marshal(resp.Body)
fmt.Printf("Response body: %s\n", string(v))
fmt.Printf("Response Header: %+v\n", resp.Header)

Response body is empty and response headers doesn't indicate any failures
Below is the screenshot of the incoming webhook we are using

Please let me know if need any details from me to debug this issue.

@dineshba - Thanks for reporting your issue.
We will investigation this issue and get back to you.
Meanwhile if you get any error log please share with us.

There is no error. Response from the api is 200 and response body is empty.
Response header contains request-id. See if this request ids are useful to debug the issue
Request-Id:[60cf0e31-1e56-b36e-f4cc-075e365d6e74]
Request-Id:[d589550c-ddb2-1b91-ed1c-19099f662a19]

Blocked by the same issue.
We implemented a scheduler to call webhook url and send simple text message daily to Team Channel last week. The response is always 200, but the message doesn't show up yesterday(Thursday)  and Tuesday.
No code change at all.

@dineshba ,@Yuqing-cat - We are checking this with engineering team and get back to you

@dineshba - We have raised the ICM for this issue, We will inform you once issue is resolved.

@dineshba -Are you seeing the notifications on team's web or getting issue on both Web and Desktop?

I am able to see the issue happening again after I created this issue. Closing for now.


Unique seed not set for each simulator

Habitat-Lab: v0.1.7 & master
🐛 Bug
Each environment should get a unique seed, but it looks like each process in the process group is provided the same seed in this code: https://github.com/facebookresearch/habitat-lab/blob/a7eb39fb3b420f9e6f528796f97457715bd79a09/habitat_baselines/rl/ppo/ppo_trainer.py#L217
# Multiply by the number of simulators to make sure they also get unique seeds
self.config.TASK_CONFIG.SEED += (
    torch.distributed.get_world_size()
    * self.config.NUM_ENVIRONMENTS
)

Expected behavior
As far as I understand, torch.distributed.get_world_size() is a fixed number (the number of processes in the process group). Instead, shouldn't local_rank be used to modify the seed?
# Multiply by the number of simulators to make sure they also get unique seeds
self.config.TASK_CONFIG.SEED += (
    local_rank
    * self.config.NUM_ENVIRONMENTS
)

CC: @mathfac

Yeah, that should be torch.distributed.get_rank().  Made a PR


fix: improve default_prompt

📑 Description
(closes: #417)
Attempt to improve the default_prompt aiming to:

Prevent Prompt Injection by specifying variable text win triple dashes -.
Keep output concise but insightful.
Clearer output Error vs Solution.

Original Prompt

New Prompt

Note: After a few tests, the text Provide the most possible solution seemed to be better than  Provide the most likely solution as it explored multiple options as opposed to focusing the answer on a single option.
✅ Checks

[ ] My pull request adheres to the code style of this project
[ ] My code requires changes to the documentation
[ ] I have updated the documentation as required
[ ] All the tests have passed

ℹ Additional Information

I wonder how the prompt behaves in case there are several errors on an object? Could you please provide an example with this case?

Example for a broken pod and deployment with multiple issues (hope this is what you had in mind with your question)

broken-pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: broken-pod
spec:
  containers:
    - name: broken-pod
      image: nginx:1.a.b.c
      livenessProbe:
        httpGet:
          path: /
          port: 90
        initialDelaySeconds: 3
        periodSeconds: 3

broken-deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: broken-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx-container
          image: nginx:latest
          ports:
            - containerPort: 80
          livenessProbe:
            httpGet:
              path: /healthz #doesn't exist in nginx
              port: 80
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /readiness #doesn't exist in nginx
              port: 80
            initialDelaySeconds: 20
            periodSeconds: 5

You still have only one error per object.
Please try with this object:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: fake-ingress
spec:
  rules:
  - host: fake-ingress.example.com
    http:
      paths:
      - backend:
          service:
            name: fake-service
            port:
              number: 80
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - fake-ingress.example.com
    secretName: fake-secret

Thanks @matthisholleville for providing the example, here the results:
Current Default Prompt
0 default/fake-ingress(fake-ingress)
- Error: Ingress default/fake-ingress does not specify an Ingress class.
- Error: Ingress uses the service default/fake-service which does not exist.
- Error: Ingress uses the secret default/fake-secret as a TLS certificate which does not exist.
The Ingress resource is trying to use a service and a TLS certificate that do not exist, and it also does not specify which Ingress class to use.

To fix this error, create the necessary service and secret resources, and specify the Ingress class to use in the Ingress resource.

Proposed Default Prompt
0 default/fake-ingress(fake-ingress)
- Error: Ingress default/fake-ingress does not specify an Ingress class.
- Error: Ingress uses the service default/fake-service which does not exist.
- Error: Ingress uses the secret default/fake-secret as a TLS certificate which does not exist.
Error: Ingress default/fake-ingress needs an Ingress class, service default/fake-service doesn't exist, and secret default/fake-secret is a non-existent TLS cert.

Solution:
1. Create a service named default/fake-service.
2. Create a secret named default/fake-secret with your TLS cert.
3. Add an ingress class to your Ingress resource, like nginx or traefik.
4. Update your Ingress resource to use the service and secret created in step 1 and 2.

I really like the solution part @camigira but the error part in the prompt seems redondant.
What do you think @AlexsJones ?

I really like the solution part @camigira but the error part in the prompt seems redondant.
What do you think @AlexsJones ?

I think as long as it yields the outputs that are clear and understandable to the user its good.
I don't know whether the error being specified in the block improves the prompt at all - we need to try with additional backends to be sure.

👋 @AlexsJones @matthisholleville
I saw this PR was approved but there are still unresolved conversations. Should I mark as completed and merge?
Thanks!


feat: move to accelerate launch for distributed training

Description of the change

Related issue number
Closes #87
How to verify the PR
I have launched a multi gpu training using FSDP and accelerate
accelerate launch --main_process_ip $MASTER_ADDR --main_process_port $MASTER_PORT --config_file config/accelerate_fsdp_config.yaml tuning/sft_trainer.py --peft_method none --tokenizer_name_or_path $MODEL_PATH --model_name_or_path ${MODEL_PATH} --data_path ${DATA_PATH} --output_dir ${OUTPUT_PATH} --num_train_epochs 5 --per_device_train_batch_size 2 --per_device_eval_batch_size 4 --evaluation_strategy "no" --save_strategy "epoch" --learning_rate "1e-5" --warmup_ratio 0.03 --lr_scheduler_type "cosine" --logging_steps 1 --include_tokens_per_second --packing False --response_template "\n### Label:" --dataset_text_field "output" --use_flash_attn False --torch_dtype bfloat16

$MASTER_ADDR and $MASTER_PORT are set by the job launcher (Pytorch Job launcher from kubeflow operator). I have used twitter_complaints.json for the training data and Llama 7B as the base model. Rest of the training arguments used are shown in the above command.
I have used the accelerate config thats being added by this PR (config/accelerate_fsdp_llama_2_procs.yaml).
Some screenshots on the training.
GPU and memory utilization

Training loss curve

Concerns
Saving model
ref - https://huggingface.co/blog/ram-efficient-pytorch-fsdp
set full state dict before saving the model
    trainer.accelerator.state.fsdp_plugin.set_state_dict_type("FULL_STATE_DICT")

Was the PR tested

[ ] I have added >=1 unit test(s) for every new method I have added.
[ ] I have ensured all unit tests pass

@Ssukriti I have addressed your comments and cherry picked Fabian's commit from his PR to here (automatically credits him at commit https://github.com/foundation-model-stack/fms-hf-tuning/pull/92/commits/4aa0153ab0c55ac5b305b8d60e8f00f89cc354d4). Looking forward to your review, thanks.

@Ssukriti @fabianlim I have collated all your review comments and have updated the PR, please review, thank you.

@Ssukriti The PR is ready, thank you.


Add register deviceLabel

Adds an optional deviceLabel field to REGISTER.
See:
https://github.com/nimiq-network/core/pull/395
https://github.com/nimiq-network/mining-pool/pull/12

https://github.com/nimiq-network/developer-reference/pull/24


Properly support GX5

Updated udev rule to differentiate between the GX3 (legacy) and the GX5 (current) and install a different launch file

Any movement on this?


Migration to gpt4-o plus improvements and fixes

Tasks

[x] feat: codeblock
[x] fix: follow-up questions
[ ] fix: short token context

test

[ ] cross compatibility

closes #87 #69

Codeblocks!!


Cannot read property 'options' of undefined

Hello.
I just tried creating a simple chart and i keep getting this problem:
"data is not defined" on main.js file
"Cannot read property 'options' of undefined " on chart.js file
I'm using the introduction example:

On the mains.js i have:
var ctx = document.getElementById("myChart").getContext("2d");
var myNewChart = new Chart(ctx).PolarArea(data);
What's wrong and why either options or data is always underfined.

A jsFiddle demonstrating the problem would be helpful. At a minimum, can you include how your data object is defined, and what order you are loading your scripts?

That's the problem. I've tried defining options as shown in documentation without success. If someone could demonstrate first documentation example working on a jsfiddle would be helpfull.

What version are you using?
v1.x samples:
https://github.com/nnnick/Chart.js/tree/master/samples
v2.0-alpha samples:
https://github.com/nnnick/Chart.js/tree/v2.0-dev/samples

v2.0.0-alpha4
Probably it's the problem.

I think it would be best to produce a JSFiddle or codepen for your setup, and we'll take a look.  I am currently using 2.0-alpha4 in production. It works great, and there are still some quirks to work out (you may have found one, who knows). Post the link here and we'll take a look!

@jonnydevv v2.x uses a different way of instantiating the chart. See the samples that @tannerlinsley linked on how to do it. It's different than v1.x


Provide prebuild dev containers for Konfig

Feature request
Now creating a new codespace with konfig's devcontainer.json needs about 3min to prepare the environment. That's time-consuming and can be speeded up by configuring a prebuild.
To enable prebuild, our KusionStack organization needs to pay for the compute and storage costs.
cost estimate
Here's the estimated cost for one year's usage: 72 dollars per year

basic: 48 dollars per year
(10min each prebuild) * (30 repeated prebuild each month) * (2core) / (60min) * (0.18 dollar) = 1.8 dollars per month
(0.1 GB each prebuild) * (30 repeated prebuild each month)*(0.01dollar) = 0.1 dollar per month

time consumption
A successful prebuild of minikube+kusion env costs about 5-7 min.
trigger policy
The prebuild process can be triggered in 3 kinds of scheduling policies:

Every push (the default setting) - With this setting, prebuilds will be updated on every push made to the given branch.
On configuration change - With this setting, prebuilds will be updated every time associated configuration files for a given repo and branch are updated.
Scheduled - With this setting, you can have your prebuilds updated on a custom schedule that's defined by you.
And to meet our needs, we can choose the second one: trigger prebuild each time the .devcontainer.json is changed.

ref:

https://github.com/features/codespaces
github pricing
enabling github codespaces for your organization
billing for codespaces
configure prebuild
Set a spending limit

And..., no it can not be self-hosted, so the prebuild process make use of our computing & storage resources bought from Aliyun & AWS:

Already applied for a free usage for our open source project from here and now we can wait for a few days to see if we are enabled to use codespaces & prebuild for free:

Already applied for a free usage for our open source project from here and now we can wait for a few days to see if we are enabled to use codespaces & prebuild for free:

The application is approved by the Github Codespaces Team and KusionStack can use GitHub Codespaces as a free team


Fix the example

The example migration is irreversible thus should contain both #up and #down methods.
There are additional safety measurements related to column removal. I'm not sure if they're applied for this particular example scenario.

I'm not sure if they're applied for this particular example scenario.

This is fine.
Thank you for the contribution ❤


0.1.66 breaks semver

0.1.66 includes cdee1e7, which introduces a breaking change.  Existing code that compiles under Rust 1.3.0-1.5.0 stops compiling due to the transitive dependency on void.

cc @Amanieu I'd love to avoid a semver bump. How hard would it be to make the thread_local crate work on Rust 1.3?

Just to clarify: I've worked around this for now by restricting the maximum version of regex my crate will allow.
Even if you bump the next release, keep in mind that Cargo will select 0.1.66 for existing code unless that code is modified.  One possible resolution would be to release a 0.1.67 that resolves the issue, followed by a 0.2 (if you want to go down that road), and 0.1.66 would be yanked.  That way, old code should continue to work.

Yup, already ahead of you. :-) #208 should fix the issue. I'll yank 0.1.66 and push out a new release once #208 lands.

This is an interesting lesson to be learned. This means, for example, that once regex moves to 1.0, it will never be able to use any new Rust features or standard library additions beyond what it could when it was released without a major version bump.
cc @rust-lang-nursery/libs @rust-lang/libs

thread_local 0.2.4 now supports Rust 1.3.

As a heads up, I tried compiling thread_local 0.2.5 under Rust 1.3, and it failed due to its dependency on kernel32-sys which uses cyclic imports that confuse older compilers.
@BurntSushi You can use new features, you just have to gate them.  scan-rules does this with a build script that enables various features based on the compiler version.
Dependencies are a bigger pain, because I'm not aware of any way to control dependencies based on Rust version.

@DanielKeep You might be on to something, kernel32-sys is tested on Rust 1.4 for Windows.
And yeah, sure, conditional compilation will let us use new stuff. But that's a pain. :-)

OK, I suspect removing the kernel32-sys dependency from thread_local is probably not realistic, since it's used for getting thread ids. So I guess that means:

We continue with the revert back to mempool.
We issue a semver bump to 0.2.

Alternatively, I could have thread_local fall back to a thread_local!-based thread id on older rustc versions (using build.rs to detect the rustc version).

Actually that won't work since I can't make the winapi dependency optional...

@DanielKeep out of curiosity, what's the reason you'd like to stay compatible with 1.3? I haven't heard many reasons for moving back, so I'm quite interested in what's going on here :)
In general I do not consider it a breaking change to require a newer Rust version so long as the newer version is "sufficiently old", so I wouldn't say that 1.0.0 of regex would never be able to bump the Rust version (it would just do so one a large-ish delay)

Oh gah thought I accidentally closed it, then I realized it legit closed it, sorry for the noise...

@BurntSushi There are a couple approaches we might consider here:

Introducing more cfg switches to make it easier to "polyfill" from older versions of Rust. For example, #[cfg(stable(duration))] or some such.

Introducing some explicit version and/or feature dependency specification in Cargo.toml, and keying off this when resolving a dependency graph. There are a lot of fine details here, but @wycats has a rough design in mind.

I expect this will become a more pressing issue when we start to stabilize major language additions like specialization.

Sounds good.
I've released 0.1.67 on crates.io with #209 (and the perf improvements from #205 :-)).

@alexcrichton Just to quickly address your question: because Cargo is ignorant of language version requirements, and because I said I would.  If you're using 1.3, there's no way to stop Cargo from selecting a version of a dependency that you just can't use.  I do consider that a breaking change, since it means that existing code can stop working, without modification.  This applies to both cargo update and just checking the code out for the first time as a new contributor or user.
I've worked on projects that were, for various reasons technical and practical, stuck on older compilers and libraries.  As a result, I'm somewhat militant about sticking to compatibility promises, even the implicit ones.  :)
@BurntSushi Thanks for your work; again, I know this is a pain to deal with.  <3


Can't find API reference for technology.tabula:tabula

This artefact presented on Central Maven Repository
https://search.maven.org/artifact/technology.tabula/tabula/1.0.3/jar

This is working to me: https://javadoc.io/doc/technology.tabula/tabula/1.0.3


Support X-Audit-Log-Reason header

DiscordBM should support the X-Audit-Log-Reason header so users can send and receive(?) audit reasons.

resolved by #19


1.19 version flagged as 1.18 so curseforge updates the 1.18 client to 1.19 causing pack to crash.

1.19 version flagged as 1.18 so curseforge updates the 1.18 client to 1.19 causing pack to crash.

Just commenting here to let you know I reported this to Curseforge staff on Discord and they say it's on your end, even though it very clearly isn't.
So you might be getting more deferrment from their "support staff" unfortunately. They'd rather argue instead of passing it up to someone that can find the problem on their end.

I already reported to the CF Dev discord and they are looking into it.


Create MR branch logic does not include remote branches

Prerequsities

[x] I'm on the latest version of the plugin
[x] I've installed the required dependencies
[x] I've run :h gitlab.nvim.troubleshooting and followed the steps there

Bug Description
get_all_merge_targets -> get_all_remote_branches -> branches calls git branch, which is seemingly incorrect if we are trying to fetch remote branches - should use git branch --remotes or git branch --all.
I have thrown in some debug printing strings to enumerate the issue, as follows:
# Listing the current branch
[user] -- DBGSTR [git.lua:52-7] current_branch=test-branchy

# Output from `git branch` as called by M.branches()
[user] -- DBGSTR [git.lua:69-9] all_branches=master
[user] * test-branchy

# Parsing of string to Lua table
[user] -- DBGSTR [git.lua:79-10] lines={ "master", "* test-branchy" }

Then the following code:
  return List.new(lines)
    :map(function(line)
      -- Trim "origin/"
      return line:match("origin/(%S+)")
    end)
    :filter(function(branch)
      -- Don't include the HEAD pointer
      return not branch:match("^HEAD$")
    end)

is obviously going to skip all of these lines, as none of them match the patterns (the first filter filters out all branches, and the second pattern has nothing to match against).
If I change the call to be git branch --remotes, it looks more like this:
# Listing the current branch
[user] -- DBGSTR [git.lua:54-8] remotes={ { "master", "test-branchy" } }

# Output from `git branch` as called by M.branches() (with --remotes)
[user] -- DBGSTR [git.lua:69-9] all_branches=master
[user] * test-branchy
[user]   remotes/origin/master
[user]   remotes/origin/test-branchy

# Parsing of string to Lua table
[user] -- DBGSTR [git.lua:79-10] lines={ "master", "* test-branchy", "  remotes/origin/master", "  remotes/origin/test-branchy" }

# Comparisons later on which show that some branches actually get returned (above no branches were returned)
[user] -- DBGSTR [git.lua:57-5] branch=master
[user] -- DBGSTR [git.lua:58-6] current_branch=test-branchy
[user] -- DBGSTR [git.lua:57-5] branch=test-branchy
[user] -- DBGSTR [git.lua:58-6] current_branch=test-branchy

Thank you for the MR! Closing this out.


 If you want to support GitHub and maybe get some features, maybe check it out.
The ip2tor project exists to help websites that block Tor users. And this issue expresses the sentiment of the many users downstream, whether because they are in repressed countries, they like liberty, or they like security/privacy, use Tor.
In the year 2021 when Google and Facebook employees will quit their livelihood and put their careers as risk to protest how their employers are hurting people, you can also expect open source projects that are anti-human, like this one, to receive strong negative feedback.


Interactionmanager fixes, tests, documentation

Added tests, docs and fixes to the InteractionManager

Codecov Report

Merging #106 into master will decrease coverage by 7.1%.
The diff coverage is 88.88%.

@@            Coverage Diff             @@
##           master     #106      +/-   ##
==========================================
- Coverage   83.04%   75.93%   -7.11%
==========================================
  Files         117      117
  Lines        2530     2772     +242
  Branches      118      123       +5
==========================================
+ Hits         2101     2105       +4
- Misses        429      667     +238

Impacted Files
Coverage Δ

.../com/ing/baker/runtime/petrinet/TaskProvider.scala
70.83% <100%> (ø)
:arrow_up:

.../runtime/core/interations/InteractionManager.scala
100% <100%> (+25%)
:arrow_up:

.../main/scala/com/ing/baker/runtime/core/Baker.scala
73.59% <66.66%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c730442...e41883b. Read the comment docs.


[frameit] Fix frameit for iPad 10.5

Add sizes::IOS_IPAD_10_5 to iPad Pro case
Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context

Currently frameit is not able to find a frame for the iPad Pro 10.5.

https://github.com/fastlane/fastlane/issues/9651

Ran frameit on a universal app, localized in 11 languages.
Description

Added another case for the iPad Pro frame.

@joshdholtz sorry for the late reply, I wasn't sure If I still had the screenshots on my laptop, but it turns out I did. I'm on macos Mojave right now so I am not able to run this again on the exact same environment but I can try. Here are some examples, all at 1668 x 2224:

@cyupa Uhhhh, I am very surprised that this worked for you 🤔 I did not get this working for me. My screenshot was actually placed in only a small portion of this frame so I started this PR to generate frames specifically for the other iPad pro sizes - https://github.com/fastlane/fastlane/pull/13261

Ah man, I was so close to my first PR on fastlane 😂 Just kidding, thanks for your help!


added bulk import method and corresponding test

Codecov Report

Merging #72 into master will increase coverage by 0.12%.
The diff coverage is 94.73%.

@@            Coverage Diff             @@
##           master      #72      +/-   ##
==========================================
+ Coverage   82.18%   82.31%   +0.12%
==========================================
  Files          12       12
  Lines        1892     1911      +19
==========================================
+ Hits         1555     1573      +18
- Misses        337      338       +1

Impacted Files
Coverage Δ

pyArango/tests/tests.py
97.64% <100%> (+0.05%)
:arrow_up:

pyArango/collection.py
68.98% <85.71%> (+0.34%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ac5dbba...82ae84c. Read the comment docs.

I like that! You see something missing you add it with a test! Great work thanks


jQuery extern definition for .text() should only have return type 'string'

Hi, I noticed that in jquery-1.8.2.externs.js, the return type of jQuery.prototype.text is {(string | !jQuery)}, but shouldn't this simply be {string}? Thanks in advance

When .text(str) is used as a setter, you can do things like $('#id').text('foo').text('bar'). In this case .text() is returning @type {!jQuery}.
Are you getting a type error from jQuery.prototype.text in this extern?

Ah ok, that makes sense then. Thanks for the feedback!

On Nov 10, 2015, at 3:01 PM, Dominator008<EMAIL_ADDRESS>wrote:
When .text(str) is used as a setter, you can do things like $('#id').text('foo').text('bar'). In this case .text() is returning @type https://github.com/type {!jQuery}.
Are you getting a type error from jQuery.prototype.text in this extern?
—
Reply to this email directly or view it on GitHub https://github.com/google/closure-compiler/issues/1250#issuecomment-155595277.


Fixed 5XX error due to invalid condition

Fixed 5XX error due to invalid condition

Codecov Report

Merging #89 (6bcae3a) into main (d51dbdb) will decrease coverage by 0.58%.
The diff coverage is 62.50%.

@@            Coverage Diff             @@
##             main      #89      +/-   ##
==========================================
- Coverage   96.53%   95.95%   -0.59%
==========================================
  Files           4        4
  Lines         404      420      +16
==========================================
+ Hits          390      403      +13
- Misses         14       17       +3

Impacted Files
Coverage Δ

service/routes.py
94.87% <57.14%> (-1.04%)
:arrow_down:

service/models.py
99.12% <100.00%> (+0.01%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d51dbdb...6bcae3a. Read the comment docs.


Unclear how to set up Events

Can't seem to set up custom Events with this.
Do I need to link Firebase (doesn't seem to support React Native)?

@Laurensdc check out the README here for instructions how to use custom events: https://github.com/ryanvanderpol/expo-analytics#events
No, you don't need to use Firebase.  Just use a regular Google Analytics account.

@ryanvanderpol Doesn't seem to work for me, maybe the events don't show up immediately?

you can try looking under "Realtime" (can't remember off the top of my heas if events show up there). The regular event reporting can take many hours to show up, in my experience.

Thanks I'll give it a go and close this issue. Cheers!

It took almost 48 hours for my Events to show up, but they did just work!


python312Packages.jalali-core: init at 1.0.0, python312Packages.jdatetime: refactor

Fix build (https://hydra.nixos.org/build/272080314)

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 348048 run on x86_64-linux 1

8 packages built:

python311Packages.jalali-core
python311Packages.jalali-core.dist
python311Packages.jdatetime
python311Packages.jdatetime.dist
python312Packages.jalali-core
python312Packages.jalali-core.dist
python312Packages.jdatetime
python312Packages.jdatetime.dist


fix: solve the secret token of the k8s v1.24 service account

Signed-off-by: qinyer<EMAIL_ADDRESS>
What type of PR is this?

/kind bug
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for reviewers:

Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

Codecov Report

Merging #541 (fbe3bc5) into master (5137c96) will increase coverage by 0.14%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##           master     #541      +/-   ##
==========================================
+ Coverage   14.11%   14.25%   +0.14%
==========================================
  Files         133      137       +4
  Lines       18851    19212     +361
==========================================
+ Hits         2661     2739      +78
- Misses      15901    16178     +277
- Partials      289      295       +6

Impacted Files
Coverage Δ

pkg/cli/registry/registry.go
0.00% <ø> (ø)

pkg/controller/cronbackupcontroller/controller.go
2.15% <0.00%> (-0.07%)
:arrow_down:

pkg/scheme/core/v1/k8s/kubeadm.go
2.41% <0.00%> (-0.14%)
:arrow_down:

pkg/scheme/core/v1/k8s/kubeadm_step.go
0.00% <0.00%> (ø)

pkg/scheme/core/v1/k8s/node.go
0.32% <0.00%> (ø)

pkg/utils/strutil/strutil.go
57.57% <0.00%> (-12.80%)
:arrow_down:

pkg/nodestatus/node_status.go
11.37% <0.00%> (ø)

pkg/oplog/operation_log.go
23.52% <0.00%> (ø)

pkg/errors/errors.go
68.75% <0.00%> (ø)

pkg/oplog/options.go
0.00% <0.00%> (ø)

... and 3 more

/cc @lixd

/approve


Remove pdoc "python>=3.7"

We test only with Python 3.8-3.10 and min. Python is 3.7. So we didn't need the extra limitation.

Codecov Report

Merging #145 (b5f08a4) into master (c84a113) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #145   +/-   ##
=======================================
  Coverage   95.25%   95.25%
=======================================
  Files          57       57
  Lines        1874     1874
=======================================
  Hits         1785     1785
  Misses         89       89

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Deleting sessions command / operator.

Digdag server uses large database area when running the server for a long time.
In this situation, Digdag user wants to delete past sessions. But currently, those feature doesn't implement yet.
An Idea

digdag delete_sessions command deletes sessions previous the specific date
delete_sessions> operator delete sessions previous of the specific date.

Ref: Twitter

This is good because similar system commands or internal workflow might be required for this feature https://github.com/treasure-data/digdag/pull/845. To mitigate this issue, we already have option that we could use Postgresql as Digdag backend instead of h2db. What do you think?

@muga Thank you for replying this issue.
I think It is a good mitigation solution to use PostgreSQL instead of H2.
Until introduce a new command, a document about deleting session statement may help for PostgreSQL users.
(I think nobody knows how to delete Digdag sessions in PostgreSQL)

@hiroyuki-sato Thank you for suggesting. Got it. sounds reasonable. To make such document, we'd better to investigate 1) what tables we want to reduce 2) what order to reduce size of tables. In my case, sessions, session_attempts, task_archives tables are top 3.

According to the record I can confirm, the task_archives table is 8 to 9 times larger than the other tables, the next large table is session_attempts (2 times larger than other tables).

So, it's enough to make a delete statement for task_archives and session_attempts table.

I ended scheduling this sql to delete records older than 1 mont:
DELETE FROM task_archives WHERE id IN (SELECT id FROM session_attempts WHERE created_at < (NOW() - INTERVAL '1 MONTH'));
DELETE FROM session_attempts WHERE created_at < (NOW() - INTERVAL '1 MONTH');
DELETE FROM sessions WHERE last_attempt_created_at < (NOW() - INTERVAL '1 MONTH');

Hello @muga,
may I suggest a digdag command-line option where you can specify a max age for cleaning up old sessions?
For instance:
# delete sessions older than 30 days
$ digdag sessions --cleanup 30d

This way the cleanup would work regardless of the DB backend and would be suitable for cronjobs.


Fix Double Tap Detection on Certain Devices

#18 seems to have broken a large number of device's ability to double tap to unblur. Investigate the issue and fix or revert the PR.

Everything I've seen so far is WAI behavior


alluxio2.9.3 An error occurs in the /bin/alluxio format command

Alluxio Version:
What version of Alluxio are you using?
alluxio2.9.3
Describe the bug
A clear and concise description of what the bug is.
/bin/alluxio format

system info：

java：

logs:
logs.zip
/etc/hosts

conf：
conf.zip
To Reproduce
Steps to reproduce the behavior (as minimally and precisely as possible)
Expected behavior
A clear and concise description of what you expected to happen.
Urgency
Describe the impact and urgency of the bug.
Are you planning to fix it
Please indicate if you are already working on a PR.
Additional context
Add any other context about the problem here.

Have you configured passwordless SSH login among all master nodes?

ssh pairwise non-encryption has been configured @humengyu2012

@humengyu2012  The root user of the system has already been granted password free access

Please check whether the dir exists:
[2023-12-21 11:15:16][node02] 2023-12-21 11:15:16,632 INFO  [main](Format.java:134) - Formatting Data path for tier 0:/mnt/ramdisk/alluxioworker
[2023-12-21 11:15:16][node02] 2023-12-21 11:15:16,635 ERROR [main](Format.java:97) - Failed to format


Update container to support for Apple silicon

$ sysctl -a | grep brand
machdep.cpu.brand_string: Apple M2 Pro

this is just a rename? I don't see any functional change here correct?

Yup，This is update shell to support apple m1, m2, mN

but absolutely no shell commands have changed, you've just changed the strings printed?


in sct_label_vertebrae: argument missing when calling sct_maths -mul in function clean_labeled_segmentation

See line 611:

FIxed in commit 8c38071


Add Wagtail collections support and Django po files

I'm testing Wagtail Collections,  these have Image and Document support, but will be great add Video support.
And, Wagtail embed video haven't localization support, but, i don't know if it's a django-embed-videos or wagtail-embedvideos problem.

Ok, i couldn't make the locale files, so, with this i can't help.

Well man, i want help with this, so:

[ ] Translate and make localization files.
[ ] Create EmbedVideoBlock.
[ ] Make Video Collections.


feat: add finishMake hook

Related issue (if exists)
https://github.com/web-infra-dev/rspack/issues/3158

Summary
Adds the afterCompile hook needed for ProgressPlugin.

copilot:summary

Walkthrough
copilot:walkthrough

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Create configuration for automated build on CircleCI

Add "CircleCI status badge" to GEOSgcm repository's README once the branch feature/pchakrab/#33-circleci-config has been merged to master


Pane Coordinates to Screen Coordinates

Hello, thank you for this excellent library. I am trying to implement a way to zoom in a specific node automatically, is there a way for me to translate the position of a node to use setTransform function from ReactFlow Instance?
Thank you.

You can use the setCenter function of the useZoomPanHelper hook https://reactflow.dev/docs/api/hooks/

Ooh thank you, i completely missed the focus node button. Thank you this is exactly what i needed.

You can use the setCenter function of the useZoomPanHelper hook https://reactflow.dev/docs/api/hooks/ example implementation: https://reactflow.dev/examples/use-zoom-pan-helper-hook/

Hello again, i am using version 8.3.2 and it seens that setCenter function on useZoomPanHelper does not exist. I tried to use transform function but it goes off my flowMap.
  const store = useStore();
  const { zoomIn, zoomOut,transform} = useZoomPanHelper();
  const { nodes } = store.getState();

  const handleFind = (id) => {
    if (nodes.length) {
      const node = nodes.find( el => el.id == id)
      const x = node.__rf.position.x + node.__rf.width / 2;
      const y = node.__rf.position.y + node.__rf.width / 2;
      const zoom = 1.85;
      transform({x,y,zoom});
    }
}

You can use the setCenter function of the useZoomPanHelper hook https://reactflow.dev/docs/api/hooks/ example implementation: https://reactflow.dev/examples/use-zoom-pan-helper-hook/

Hello again, i am using version 8.3.2 and it seens that setCenter function on useZoomPanHelper does not exist. I tried to use transform function but it goes off my flowMap.
  const store = useStore();
  const { zoomIn, zoomOut,transform} = useZoomPanHelper();
  const { nodes } = store.getState();

  const handleFind = (id) => {
    if (nodes.length) {
      const node = nodes.find( el => el.id == id)
      const x = node.__rf.position.x + node.__rf.width / 2;
      const y = node.__rf.position.y + node.__rf.width / 2;
      const zoom = 1.85;
      transform({x,y,zoom});
    }
}

The setCenter function should still work. Do you get an error?

The setCenter function should still work. Do you get an error?

We closed this issue due to inactivity. Feel free to re-open it when the issue still occurs.

We closed this issue due to inactivity. Feel free to re-open it when the issue still occurs.


FIXED: Carry incorrect when using addition in 32-bit ALU

Describe the changes you have made in this PR -

Fixed the issue with incorrect output when adding two binary numbers in the ALU.
Improved bit width handling in the resolve() method.
Added conditional logic to correctly handle addition and masking for both small (<=32 bits) and large (>32 bits) bit widths.
Ensured correct computation of carry-out by checking for overflow bits.

Screenshots of the changes (If any) -
Before:
Test case 1: adding 10...0 and 10...0

Test case 2: adding 0...010 and 0...010

After:
Test case 1: adding 10...0 and 10...0

Test case 2: adding 0...010 and 0...010

issuelink: https://github.com/CircuitVerse/CircuitVerse/issues/4984

@subhamkumarr plz check

@subhamkumarr please can u review again

@gr455 can u review my PR?


Handle python depencies for the Meltano and its components

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/193
Originally created by @mbergeron on 2018-12-05 13:40:07

This stems out of the following discussion that happened after two production jobs started to fail.
15h]
tlapiana @jschatz dependency issue?

[14h]
jschatz @Micaël Bergeron was going to look at this. I am not sure what the issue is at the moment.

[14h]
Micaël Bergeron yes it is, there's an MR for it in "target-snowflake"

[14h]
Micaël Bergeron its a deps conflict for 'idna'

[14h]
tlapiana should this have been caught in a build process during the release? do more checks need to get run before release or is this unrelated?

[12h]
jschatz I ran into it in general python. It's a shortcoming in pip. Not sure exactly how it went down but the main problem is that our dependencies in setup py are not frozen. Which is the way it should be but it doesnt read from requirements.txt. so in the end we need to lock the dependencies somehow. That way right now seems to be with setup.py

[3m]
Micaël Bergeron basically one of our sub-deps (azure-common) is not pinning its deps and pip has not deps resolver.

> should this have been caught in a build process during the release? do more checks need to get run before release or is this unrelated?

basically this might just happen anytime you `pip install X`, if there is a sub-deps that has an unbounded dep. I'm actually very surprised `pip` doesn't resolve dependencies. What now? As we manage the venv in meltano, we could do `pip download ... --no-deps`, extract the `requirements.txt` then `pip install -r requirements.txt (if it exists)` then `pip install ...`

[<1m]
Micaël Bergeron @tlapiana tl;dr; the build process might go on just fine then 2 months later you can't install  the package properly.

It seems pip by itself is not a viable solution for deployment unless you are certain that your dependency tree is completely pinned.
Solution 1
The process I describe above:

pip download --no-deps  -d /tmp/...
(for package url)
-tar xzf /tmp/... $(basename -s .tar.gz /tmp/.../requirements.txt)

[optional] pip install -r /tmp/.../requirements.txt

(for package git repo)

unzip /tmp/... /requirements.txt
[optional] pip install -r /tmp/.../requirements.txt

pip install /tmp/...

I think it seems weird to use that to deploy but :shrug:
Scrappy solution
Manually resolve conflicts in the setup.py of each project.
/cc @jschatz1 @iroussos

View 8 previous comments from the original issue on GitLab


restructuring and moving content

Apologies, but what order of the tutorials we will use from now?

I agree, this is hard to review w/o a proper preview. This is the "to be" structure:

Is the access from locally running app to a HANA removed?

Yes, we didn't want to describe that as it's more complicated and not really a starter scenario.

We could keep it as advanced and reference it as possible next step. Then you'd need to adapt that one accordingly.

We could keep it as advanced and reference it as possible next step. Then you'd need to adapt that one accordingly.

If it will be the last, you do not have to adapt anything in the dependencies.
You need to fetch the env from the CF (e.g. copypaste it) and remove everything except binding to HANA. I wonder if there is a command to do that without manual editing.

I agree, this is hard to review w/o a proper preview. This is the "to be" structure:

I brought all those changes to a QA instance. There's no such type as mission or group, so you can't see the structure as it would be productive. But I'll add all the links to the QA server and that order one would do them later. So you can check out if the flow works as expected. It starts with the BAS setup for Java, not the general one as we didn't change that.
User/PW (both): 20Digital20

https://developers-qa.sap.com/tutorials/cp-cap-java-app-studio.html
https://developers-qa.sap.com/tutorials/cp-cap-java-custom-handler.html
https://developers-qa.sap.com/tutorials/cp-cap-java-reusable-service.html
https://developers-qa.sap.com/tutorials/cp-cap-java-service-reuse.html
https://developers-qa.sap.com/tutorials/cp-cap-java-custom-logic.html
https://developers-qa.sap.com/tutorials/cp-cap-java-security-local.html
https://developers-qa.sap.com/tutorials/cp-cap-java-deploy-cf.html
https://developers-qa.sap.com/tutorials/cp-cap-java-security-cf.html

In the 4th tutorial of the previous list, we mention that until that point no custom code has been needed. But we already did some custom coding in the 2nd tutorial. Could we move that to later? Or just delete that sentence and keep the order?


Bug in IColorPresentationHandler

Hello, I have recently updated from 17.4 to 18.1 and I believe there is bug somewhere regarding the IColorPresentationHandler.
My DocumentColorPresentationHandler implements IColorPresentationHandler and ever since I updated, this handler seems to break other handlers and more generally, my extension that interacts with my server. For example, when I try to use this handler, my DidOpenTextDocument event in my TextDocumentSyncHandler never fires, my SemanticTokensHandler never hits, etc. When I comment it out, all of my handlers work, including my DocumentColorHandler, which implements IDocumentColorHandler (until I try to make a textDocument/colorPresentation request, of course). So I don't think the problem is related to the IDocumentColorHandler.
This leads me to believe the issue has something to do with IColorPresentationHandler.
One thing I noticed is that even though the LSP Specification's entry for Color Presentation Request states that "This request has no special capabilities and registration options since it is send as a resolve request for the textDocument/documentColor request," the IColorPresentationHandler interface requires us to implement both DocumentColorRegistrationOptions and ColorProviderCapability in our color presentation handlers, which are the same type of registration options and capability that the IDocumentColorHandler interface requires us to have for our implementations of it, which I found strange. I'm not sure if this is supposed to be this way or not, but I would think that its not, and it's just something I noticed and thought may have something to do with the IColorPresentationHandler causing problems.

I can take a look at what might be going on.


Add Vendor: Beamer

---
base_pricing: 59
currency: USD
name: Beamer
pricing_scheme: per month
pricing_sources:
  - https://www.getbeamer.com/pricing
sso_pricing: 299
updated_at: 2024-12-16
vendor_url: https://www.getbeamer.com/

Thanks @kimsey0 for your help!


Change delegates to weak references

SpotlightViewController contained a strong reference to a SpotlightTransitionController, which in turn had a strong reference to the SpotlightViewController through the delegate variable.
This caused a reference cycle that prevented SpotlightViewControllers from being deallocated, leaking memory.
By changing the delegate variable in SpotlightTransitionControllerDelegate  to a weak variable, this retain cycle is prevented. I changed the delegate in SpotlightViewControllerDelegate to a weak variable as well, as this is common practice for delegates.

@robhor I was careless... thx!


*** extconf.rb failed ***

I do have following issue:
  vagrant plugin install vagrant-kvm
  Installing the 'vagrant-kvm' plugin. This can take a few minutes...
  /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/installer.rb:562:in `rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

          /opt/vagrant/embedded/bin/ruby extconf.rb
  checking for virNetworkPtr in libvirt/libvirt.h... *** extconf.rb failed ***
  Could not create Makefile due to some reason, probably lack of
  necessary libraries and/or headers.  Check the mkmf.log file for more
  details.  You may need configuration options.

  Provided configuration options:
        --with-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/opt/vagrant/embedded/bin/ruby
        --with-libvirt-include
        --without-libvirt-include
        --with-libvirt-lib
        --without-libvirt-lib
        --with-libvirt-config
        --without-libvirt-config
        --with-pkg-config
        --without-pkg-config
  /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:381:in `try_do': The compiler failed to generate an executable file. (RuntimeError)
  You have to install development tools first.
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:491:in `block in try_compile'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:443:in `with_werror'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:491:in `try_compile'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:1022:in `try_type'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:1050:in `block in have_type'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:790:in `block in checking_for'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:284:in `block (2 levels) in postpone'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:254:in `open'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:284:in `block in postpone'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:254:in `open'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:280:in `postpone'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:789:in `checking_for'
        from /opt/vagrant/embedded/lib/ruby/1.9.1/mkmf.rb:1049:in `have_type'
        from extconf.rb:10:in `block in have_libvirt_types'
        from extconf.rb:10:in `each'
        from extconf.rb:10:in `have_libvirt_types'
        from extconf.rb:211:in `<main>'

  Gem files will remain installed in /home/jax/.vagrant.d/gems/gems/ruby-libvirt-0.4.0 for inspection.
        Results logged to /home/jax/.vagrant.d/gems/gems/ruby-libvirt-0.4.0/ext/libvirt/gem_make.out
              from /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/installer.rb:540:in `block in build_extensions'
              from /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/installer.rb:515:in `each'
              from /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/installer.rb:515:in `build_extensions'
              from /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/installer.rb:180:in `install'
              from /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/dependency_installer.rb:297:in `block in install'
              from /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each'
              from /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each_with_index'
              from /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/dependency_installer.rb:270:in `install'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/commands/plugin/action/install_gem.rb:38:in `block in call'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/commands/plugin/gem_helper.rb:42:in `block in with_environment'
              from /opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/user_interaction.rb:40:in `use_ui'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/commands/plugin/gem_helper.rb:41:in `with_environment'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/commands/plugin/action/install_gem.rb:28:in `call'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/warden.rb:34:in `call'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/commands/plugin/action/bundler_check.rb:20:in `call'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/warden.rb:34:in `call'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/builder.rb:116:in `call'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/runner.rb:61:in `block in run'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/util/busy.rb:19:in `busy'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/runner.rb:61:in `run'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/commands/plugin/command/base.rb:17:in `action'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/commands/plugin/command/install.rb:44:in `execute'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/commands/plugin/command/root.rb:47:in `execute'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/cli.rb:46:in `execute'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/environment.rb:467:in `cli'
              from /opt/vagrant/embedded/gems/gems/vagrant-1.2.2/bin/vagrant:84:in `<top (required)>'
              from /opt/vagrant/bin/../embedded/gems/bin/vagrant:23:in `load'
              from /opt/vagrant/bin/../embedded/gems/bin/vagrant:23:in `<main>'

I serachf or the file:
⮀sudo find / -xdev -name libvirt.h
/usr/include/libvirt/libvirt.h
virNetworkPtr is define inside of the header. ....
any idea?
More info:
vagrant -v
Vagrant version 1.2.2
Linux jax 3.9.5-1-ARCH #1 SMP PREEMPT Sat Jun 8 09:22:45 CEST 2013 x86_64 GNU/Linux
libvirtd --version libvirtd (libvirt) 1.0.6
qemu 1.5.0-4

Hit this problem when installing vagrant-libvirt and it failed to installed ruby-libvirt and discovered that the problem system was missing pkg-config. Appears that when pkg-config is missing or possibly also when /usr/lib/pkgconfig/libvirt.pc is missing that the script ext/libvirt/extconf.rb from ruby-libvirt is failing to find the headers/libraries but never indicates that the reason is pkg-config being missing.
The hint is that the listed configuration options:
  Provided configuration options:
        --with-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/opt/vagrant/embedded/bin/ruby
        --with-libvirt-include
        --without-libvirt-include
        --with-libvirt-lib
        --without-libvirt-lib
        --with-libvirt-config
        --without-libvirt-config
        --with-pkg-config
        --without-pkg-config

Has nothing listed for --with-libvirt-include or --with-libvirt-lib.


Unable to set local time for device.

When the H10 turns off, its timestamp will reset to its default value of nanoseconds from 2000/01/01 UTC to 2019/01/01 UTC. In the Polar SDK (docs) there is a function to set the local time, but it currently is unavailable here. When you try to compare timestamps coming from the sensor you'll be surprised to find that the sensor took its measurements several years in the past.
I'm not planning on fixing this, I just want to leave an issue in case someone will want fix it and so people know why this is happening.

Thanks for the info. If I have a chance to look I'll keep this in mind.

I've opened an issue on the sdk to see if they have any info here

Since the SDK owners weren't helpful with calling setLocalTime, do you think it's acceptable to just have a crate-local time and manually adjust the timestamps in the data? At least with the H10 we always know the baseline is 2019-01-01T00:00:00Z<PHONE_NUMBER>00000000 nanoseconds) so we can add an offset to the user defined start time.

I've been working in my fork to port the sdk code. They use protobuf to send messages. They mention an RFC 70 and RFC 60 which I can't locate anywhere. I've been trying to research to learn how setLocalTime works.
That said, I do think manually modifying the time stamps will work.
For #4, I just closed it because you hadn't said anything on it, and I was planning to continue pushing to my fork and didn't want unrelated changes to appear in the pull request.

Are the RFCs they mention not just the IETF RFC documents? Maybe not since I'm not sure how these in particular would be useful but I haven't looked into any of this in quite a long time since I'm busy with other things.
RFC 60
RFC 70

I'm nit experienced in this area, but I didn't think it was these rfcs (60, 76, 77 - I put the wrong numbers) because their subjects seem unrelated.
rfc60 describes ncp which is a transport protocol like tcp/ip that has been obsolete (from tcp/ip) since then 80s. I don't see how this would be useful, especially since the device is using Bluetooth to communicate already.
rfc76 relates to networking using Arpanet (and arpanet originally used ncp). It's another rfc about how to connect to computers which doesn't seem helpful or useful for a Bluetooth application.
rfc77 is a report on networking meetings so I'm skeptical on its relevance.
Once again, I'm new to all this so I could be completely wrong, this is just why I didn't think these rfcs were related.


Native Automation: Monaco editor does not show code completion widget when testing in native automation mode

What is your Scenario?
Test the Monaco Editor code completion.
What is the Current behavior?
When typing some text, the editor should display a code completion widget with code suggestions. It is working fine in proxied mode. However, the widget is not shown in native automation mode.
What is the Expected behavior?
The code completion widget should appear in native automation mode.
What is your public website URL? (or attach your complete example)
https://microsoft.github.io/monaco-editor/playground.html?source=v0.39.0#example-creating-the-editor-hello-world
What is your TestCafe test code?
import { Selector } from "testcafe";

fixture`monaco`.page`https://microsoft.github.io/monaco-editor/playground.html?source=v0.39.0#example-creating-the-editor-hello-world`;

test('Test', async t => {
    await t
        .typeText(Selector('.inputarea'), 'document')
        .debug();
});

Your complete configuration file
No response
Your complete test report
No response
Screenshots
Proxied mode:

Native automation mode:

Steps to Reproduce
Run the test above in native automation and proxied modes.
TestCafe version
2.6.2
Node.js version
18.16.0
Command-line arguments
npx testcafe chrome test.js
Browser name(s) and version(s)
Chrome
Platform(s) and version(s)
Windows 10
Other
No response

fixed in https://github.com/DevExpress/testcafe/pull/7773