fix: shutdown gateway-cln-extension on lightningd exit

-Works when lightningd requests plugin stop, and when the task group is generally shutting down

Re: cdecker, "the shutdown signal is not reliable (if the main daemon crashes or aborts the plugin's don't get the signal), as such we must be robust against sudden disappearances"

we should observe the reliability of cln-plugin shutdown subscription, so we can be resilient to lightningd crashes.

Codecov Report
Base: 63.39% // Head: 63.36% // Decreases project coverage by -0.04% :warning:

Coverage data is based on head (28176ba) compared to base (8c2ad4a).
Patch coverage: 0.00% of modified lines in pull request are covered.

: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
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1765      +/-   ##
==========================================
- Coverage   63.39%   63.36%   -0.04%
==========================================
  Files         124      124
  Lines       24666    24684      +18
==========================================
+ Hits        15638    15640       +2
- Misses       9028     9044      +16

Impacted Files
Coverage Δ

gateway/ln-gateway/src/bin/cln_extension.rs
0.25% <0.00%> (-0.02%)
:arrow_down:

fedimint-core/src/core.rs
95.26% <0.00%> (-0.25%)
:arrow_down:

modules/fedimint-ln/src/lib.rs
73.68% <0.00%> (-0.14%)
:arrow_down:

modules/fedimint-mint/src/lib.rs
77.83% <0.00%> (-0.12%)
:arrow_down:

fedimint-server/src/lib.rs
76.48% <0.00%> (+0.25%)
:arrow_up:

fedimint-server/src/net/peers.rs
90.00% <0.00%> (+0.57%)
:arrow_up:

fedimint-server/src/multiplexed.rs
91.25% <0.00%> (+2.50%)
:arrow_up:

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

when I was running the cli-test.sh I got the following logs:

Context

+ lightning-cli --network regtest --lightning-dir=/tmp/nix-shell.LFSoSm/fm-8St2/ln1 plugin stop gateway-cln-extension
2023-02-27T13:40:03.589Z INFO    plugin-gateway-cln-extension: Shutting down...
mint 1: 2023-02-27T13:40:10.027494Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 2: 2023-02-27T13:40:10.028085Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 3: 2023-02-27T13:40:10.028086Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 0: 2023-02-27T13:40:10.069371Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 1: 2023-02-27T13:40:20.031045Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 3: 2023-02-27T13:40:20.031876Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 2: 2023-02-27T13:40:20.031939Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 0: 2023-02-27T13:40:20.073923Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 1: 2023-02-27T13:40:30.034251Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 2: 2023-02-27T13:40:30.035122Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 3: 2023-02-27T13:40:30.035088Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
mint 0: 2023-02-27T13:40:30.077561Z  WARN fedimint_bitcoind::bitcoincore_rpc: bitcoind returned error on cmd 'sendrawtransaction': JSON-RPC error: RPC error response: RpcError { code: -27, message: "Transaction already in block chain", data: None } addr="http://<IP_ADDRESS>:18443"
2023-02-27T13:40:33.589Z UNUSUAL plugin-gateway-cln-extension: Timeout on shutdown: killing anyway
2023-02-27T13:40:33.589Z INFO    plugin-gateway-cln-extension: Killing plugin: stopped by lightningd via RPC
{
   "command": "stop",
   "result": "Successfully stopped gateway-cln-extension."
}
2023-02-27T13:40:33.592163Z  WARN ln_gateway::actor: Error sent over HTLC subscription: status: Unknown, message: "error reading a body from connection: broken pipe", details: [], metadata: MetadataMap { headers: {} }
++ cat /tmp/nix-shell.LFSoSm/fm-8St2/.pid
++ sed '1!G;h;$!d'
+ kill 66010 66007 66006 66002 65305 65304 65239
+ pkill gatewayd
2023-02-27T13:40:33Z tor: Thread interrupt
2023-02-27T13:40:33Z Shutdown: In progress...
2023-02-27T13:40:33Z torcontrol thread exit
2023-02-27T13:40:33Z addcon thread exit
2023-02-27T13:40:33Z opencon thread exit

+ lightning-cli --network regtest --lightning-dir=/tmp/nix-shell.LFSoSm/fm-8St2/ln1 plugin stop gateway-cln-extension
2023-02-27T13:40:03.589Z INFO    plugin-gateway-cln-extension: Shutting down...
...
2023-02-27T13:40:33.589Z UNUSUAL plugin-gateway-cln-extension: Timeout on shutdown: killing anyway
2023-02-27T13:40:33.589Z INFO    plugin-gateway-cln-extension: Killing plugin: stopped by lightningd via RPC

The way I read this is that the plugins is killed by lightnind because the 30s timeout hit? So I wasn't 100% sure if that shutdown really worked. (I wanted to look into this but currently didn't have the time.)

ok, so when I was running just test-real for PR #1778  I got the following logs:
test result: ok. 31 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 59.89s

+ kill_fedimint_processes
+ lightning-cli --network regtest --lightning-dir=/tmp/nix-shell.omzbty/fm-xiTG/ln1 plugin stop gateway-cln-extension
2023-02-27T17:21:41.579Z INFO    plugin-gateway-cln-extension: Received shutdown event ... gracefully shutting down the plugin
2023-02-27T17:22:11.578Z UNUSUAL plugin-gateway-cln-extension: Timeout on shutdown: killing anyway
2023-02-27T17:22:11.578Z INFO    plugin-gateway-cln-extension: Killing plugin: stopped by lightningd via RPC
{
   "command": "stop",
   "result": "Successfully stopped gateway-cln-extension."
}
++ cat /tmp/nix-shell.omzbty/fm-xiTG/.pid
++ sed '1!G;h;$!d'
+ kill<PHONE_NUMBER>21 109457
+ pkill gatewayd

And between receiving the shutdown hook and our plugin being killed, are exactly 30 seconds, so I think we're running into the timeout here.


[SE-0268] Amend proposal to remove the oldValue deprecation change

This effectively reverts #1097 and removes the oldValue deprecation change from the proposal text based on core team decision.
Proposal acceptance announcement: https://forums.swift.org/t/accepted-se-0268-refine-didset-semantic/31822

cc @airspeedswift


[Bug]: LLama3 LoRA load failed

Your current environment
vllm 0.5.4
🐛 Describe the bug
I try to load llama3-8B lora model but encounter error as bellow:
ValueError: While loading /models/llama3-8b-instruct-lora-0719-r64, expected target modules in ['q_proj', 'k_proj', 'v_proj', 'o_proj', 'gate_proj', 'up_proj', 'down_proj', 'embed_tokens', 'lm_head'] but received ['w2', 'w3', 'w1']. Please verify that the loaded LoRA module is correct
I searched the issues for problems related to LoRA and found that it might be due to the lack of support for w1, w2, and w3. Additionally, the supported_lora_modules in the model of llama doesn't include these items.
If I want to properly use LoRA with LLaMA3, should I avoid these layers during model finetune, or will there be support for them in the future?

I think you should first check if any LoRA files for other models have been loaded.

I think you should first check if any LoRA files for other models have been loaded.

Thank you for your reply. I have checked that the base model doesn't contain these layers. The error might have occurred due to using a finetune configuration from another model.


j

Bug Report Dump (Auto-generated)

Version 1.12.0 (1106)
Device: iPhone 5s (iOS 10.3.2)
TestFlight: false

What
Sent with GitHawk


[Docs] Update README.md for style guide & basic readability

Description
This PR updates the top-level README at a basic level to meet the style guide and tweak a few sections (making more of vizro-ai earlier on the page). It does not address core messaging changes as we're still discussing them.
Screenshot
Notice

[x] I acknowledge and agree that, by checking this box and clicking "Submit Pull Request":

I submit this contribution under the Apache 2.0 license and represent that I am entitled to do so on behalf of myself, my employer, or relevant third parties, as applicable.
I certify that (a) this contribution is my original creation and / or (b) to the extent it is not my original creation, I am authorized to submit this contribution on behalf of the original creator(s) or their licensees.
I certify that the use of this contribution as authorized by the Apache 2.0 license does not violate the intellectual property rights of anyone else.
I have not referenced individuals, products or companies in any commits, directly or indirectly.
I have not added data or restricted code in any commits, directly or indirectly.

I have a linter issue with this PR because codespell is picking up a term in the Vale folder and trying to correct it (we need it be in Vale so it's spotted and flagged for, you guessed it, correction). How can I persuade codespell this is fine (e.g. filter out the .vale folder from scanning?). cc @huong-li-nguyen @l0uden
codespell................................................................Failed
- hook id: codespell
- exit code: 65

.vale/styles/Microsoft/Terms.yml:50: utilising ==> utilizing

I have a linter issue with this PR because codespell is picking up a term in the Vale folder and trying to correct it (we need it be in Vale so it's spotted and flagged for, you guessed it, correction). How can I persuade codespell this is fine (e.g. filter out the .vale folder from scanning?). cc @huong-li-nguyen @l0uden

I just pushed the change :)


Deleting faces is not working

What Operating system and version is LibrePhotos running on:
Zorin OS 16
What architecture is LibrePhotos running on:
x64
How is LibrePhotos installed:
Docker
If running via Docker or Kubernetes please list version including docker-compose:
latest
Are you running LibrePhotos on a virtual machine if so please list:
N/D
How is you picture library mounted on the host (or in the virtual machine):
Native Docker volume and Nextcloud
Description of issue:
After updating the trash button on the face recognition tab is not working when deleting a face it is not deleted
How can we reproduce it:
delete faces
Additional Information:

Include a ZIP file containing your log files.
Provide pictures or links to videos that clearly demonstrate the issue.

This issue should be resolved by this week's release. Would be great, if you could confirm that.


vkGetInstanceProcAddr with unknown name crashes on linux

When capturing on linux, and if my app calls vkGetInstanceProcAddr with an unknown name, I get
/home/olv/projects/Vulkan-Loader/loader/unknown_function_handling.c:315: loader_phys_dev_ext_gpa_term_no_check: Assertion `NULL != inst' failed.

gdb says
(gdb) bt
#4  0x00007ffff7eeebd9 in loader_phys_dev_ext_gpa_term_no_check (inst=0x0,
    funcName=0x5555555607d8 "vkFoo")
    at /home/olv/projects/Vulkan-Loader/loader/unknown_function_handling.c:315
#5  0x00007ffff7edc0c2 in loader_gpdpa_instance_terminator (inst=0x55555568faf0,
    pName=0x5555555607d8 "vkFoo") at /home/olv/projects/Vulkan-Loader/loader/loader.c:3953
#6  0x00007ffff7eee63f in loader_check_layer_list_for_phys_dev_ext_address (inst=0x5555555712b0,
    funcName=0x5555555607d8 "vkFoo")
    at /home/olv/projects/Vulkan-Loader/loader/unknown_function_handling.c:187
#7  0x00007ffff7eee73e in loader_phys_dev_ext_gpa_impl (inst=0x5555555712b0,
    funcName=0x5555555607d8 "vkFoo", is_tramp=true)
    at /home/olv/projects/Vulkan-Loader/loader/unknown_function_handling.c:222
#8  0x00007ffff7eeeb6e in loader_phys_dev_ext_gpa_tramp (inst=0x5555555712b0,
    funcName=0x5555555607d8 "vkFoo")
    at /home/olv/projects/Vulkan-Loader/loader/unknown_function_handling.c:307
#9  0x00007ffff7ebb5e6 in trampoline_get_proc_addr (inst=0x5555555712b0, funcName=0x5555555607d8 "vkFoo")
    at /home/olv/projects/Vulkan-Loader/loader/gpa_helper.c:262
#10 0x00007ffff7ee6527 in vkGetInstanceProcAddr (instance=0x5555555712b0, pName=0x5555555607d8 "vkFoo")
    at /home/olv/projects/Vulkan-Loader/loader/trampoline.c:106

I noticed this because volk can call vkGetInstanceProcAddr with unknown names.

loader_check_layer_list_for_phys_dev_ext_address does not return false immediately because there is a very common implicit layer, VK_LAYER_MESA_device_select, on linux.  The layer provides get_physical_device_proc_addr and calls down the chain and reaches loader_gpdpa_instance_terminator.
loader_phys_dev_ext_gpa_term_no_check gets NULL because loader_get_instance has this check
    if (VK_NULL_HANDLE == instance || LOADER_MAGIC_NUMBER != ptr_instance->magic) {
        return NULL;

Because ptr_instance points to a HandleWrapper created by gfxreconstruct, it does not have magic and NULL is returned.

Any thought about this?  I think this is a loader bug.  Should I file an issue against Vulkan-Loader?

Any thought about this? I think this is a loader bug. Should I file an issue against Vulkan-Loader?

Resources are very thin currently on GFXReconstruct. Go ahead and submit against the loader. One of the loader resources may get some time to triage this.

Thanks.  I filed a loader issue instead.  Closing.

According to https://github.com/KhronosGroup/Vulkan-Loader/issues/927#issuecomment-1119865794, this is a gfxreconstruct bug.

From my understanding of how the loader and layer infrastructure works (not anything specific to gfxreconstruct), the main issue is that vk_layerGetPhysicalDeviceProcAddr isn't passing through gfxreconstruct and therefor the 'unwrapping' of the instance handle doesn't occur.
Except, when I was looking at that commit, its clear that gfxreconstruct doesn't unwrap the instance handle. Which casts doubt onto my hypothesis that the lack of interception is what is causing the crash.

@charles-lunarg can you go into more detail about your conclusion that "gfxreconstruct doesn't unwrap the instance handle"?  As far as I can tell every override taking a VkInstance unwraps it, e.g. https://github.com/LunarG/gfxreconstruct/blob/365757b47e32cf8346c00300fc82deb47969b76f/framework/generated/generated_vulkan_api_call_encoders.cpp#L116 unwraps through https://github.com/LunarG/gfxreconstruct/blob/365757b47e32cf8346c00300fc82deb47969b76f/framework/encode/vulkan_handle_wrapper_util.h#L44

I agree, the GPDPA isn't passing through GFXR, which is why I say "add back in the VK function overrides that call through that map", meaning add back in an override in the GFXR layer for GPDPA like there was before @9d73340
I should probably clarify by saying "add back in an override ofor GPDPA like before, except use the new map".

I can confirm that this problem is reproducible by running hello_triangle from the Khronos Vulkan Samples, which also happen to use Volk.
libVkLayer_MESA_device_select.so![Unknown/Just-In-Time compiled code] (Unknown Source:0)

libvulkan.so.1!loader_check_layer_list_for_phys_dev_ext_address(struct loader_instance * inst, const char * funcName) (unknown_function_handling.c:187)

libvulkan.so.1!loader_phys_dev_ext_gpa_impl(struct loader_instance * inst, const char * funcName, _Bool is_tramp) (unknown_function_handling.c:222)

libvulkan.so.1!trampoline_get_proc_addr(struct loader_instance * inst, const char * funcName) (gpa_helper.c:262)

vkGetInstanceProcAddrStub(void * context, const char * name) (/home/andrew/checkouts/khronos-vulkan-samples/third_party/volk/volk.c:37)

volkGenLoadInstance(void * context, PFN_vkVoidFunction (*)(void *, const char *) load) (/home/andrew/checkouts/khronos-vulkan-samples/third_party/volk/volk.c:318)

volkLoadInstance(VkInstance instance) (/home/andrew/checkouts/khronos-vulkan-samples/third_party/volk/volk.c:103)

HelloTriangle::init_instance(HelloTriangle * const this, HelloTriangle::Context & context, const std::vector<char const*, std::allocator<char const*> > & required_instance_extensions, const std::vector<char const*, std::allocator<char const*> > & required_validation_layers) (/home/andrew/checkouts/khronos-vulkan-samples/samples/api/hello_triangle/hello_triangle.cpp:255)
...

In this case Volk was trying to load the missing Windows 10 function "vkAcquireWinrtDisplayNV".

@andrew-lunarg Can you describe a bit more about this situation? What layers are active & which version of the loader are you using are the main bits of info. Does it reproduce if you use an ancient loader? Trying to establish if this is a recent breakage in behavior or was always broken.

I have a strong lead on what is happening. The main issue is that gfxreconstruct does not implement vk_layerGetPhysicalDeviceProcAddr but does wrap handles. This means when the loader calls down the vk_layerGetPhysicalDeviceProcAddr chain, a layer that is expecting an unwrapped handle gets one that is wrapped, causing :boom:.
The hitch is that this issue only explodes when the wrapping handle layer is closest to the application. When I investigated the loader, I found that it placed gfxreconstruct closer to the application in newer versions (1.3.214 and 1.3.204) and in old versions it put it closer to the driver (1.1.130 and 1.2.160). I will do further regression testing to figure out which commit caused the order to be flipped, as that may be a loader bug of its own.
What would have fixed this is if the gfxreconstruct layer had implemented vk_layerGetPhysicalDeviceProcAddr like it shouldn't of removed.

Update for those curious:
I found the loader commit that changed the behavior.
Gist is that the loader's handling of XDG paths was a bit silly, and @MarkY-LunarG did a great job cleaning it up. HOWEVER, the side effect is that it changed the search order the loader does, which switches around the order that MESA_device_select and GFXReconstruct are found. The old search order happened to hide this bug from most users.
Commit in question.
https://github.com/KhronosGroup/Vulkan-Loader/commit/4c8bf4cc69db55817800ccff16d96a83ee9c9ea6

I have a strong lead on what is happening. The main issue is that gfxreconstruct does not implement vk_layerGetPhysicalDeviceProcAddr but does wrap handles. This means when the loader calls down the vk_layerGetPhysicalDeviceProcAddr chain, a layer that is expecting an unwrapped handle gets one that is wrapped, causing boom.
...
That sounds right. My repro blows up in the MESA device select layer in exactly this situation. It tries to look up an instance that the loader gives it in a table of instances that it has seem before, but the instance isn't there, the table lookup returns null, and it dereferences the null pointer.
Happens here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/device-select-layer/device_select_layer.c#L611 based on a null it gets from here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/device-select-layer/device_select_layer.c#L102

This is not a solution of course but for what its worth, commenting out these lines in volk.c lets my repro (hello_triangle from the samples) run with trace capture enabled.
vkAcquireWinrtDisplayNV = (PFN_vkAcquireWinrtDisplayNV)load(context, "vkAcquireWinrtDisplayNV");
vkGetWinrtDisplayNV = (PFN_vkGetWinrtDisplayNV)load(context, "vkGetWinrtDisplayNV");

These are unknown physical device functions.

@charles-lunarg wrote:

What would have fixed this is if the gfxreconstruct layer had implemented vk_layerGetPhysicalDeviceProcAddr like it shouldn't of removed.

As you pointed out, vk_layerGetPhysicalDeviceProcAddr was removed in https://github.com/LunarG/gfxreconstruct/pull/215 to workaround loader bugs, so there wasn't a choice at the time.

Thats a fair point, however because gfxreconstruct does handle wrapping, its required to implement all functions that take handles which could be intercepted. So its trading one crash for another. It just happened to be at the time that the other crash wasn't occurring.

@charles-lunarg  https://github.com/KhronosGroup/Vulkan-Loader/blob/master/docs/LoaderLayerInterface.md#layer-unknown-physical-device-extensions says "This support is optional and should not be considered a requirement."  Can you explain further what that means?

In isolation, that makes it appear as 'optional'. But if you look at the handle wrapping section, it declares that "This means that the layer must intercept every Vulkan function which uses the object in question, and wrap or unwrap the object, as appropriate." Which is a much stronger statement about what layers are required to do. Handle wrapping only works if the layer intercepts ALL functions which accept the handle and the layer wraps/unwraps as needed. This is a big reason why handle wrapping is not recommended.
https://github.com/KhronosGroup/Vulkan-Loader/blob/master/docs/LoaderLayerInterface.md#wrapping

This is something we can and will fix.  I think it should be pretty straightforward to implement GetPhysicalDeviceProcAddr much as GFXR did before, but using a map by instance as I described above or maybe we can add the function pointer to the unwrapped instance struct.  As noted, @andrew-lunarg is looking into this further.
At some later date we can look into re-architecting GFXR to use maps from Vulkan handles to internal data instead of wrapping, and evaluate the performance hit.
However, it's not clear at all to me the wrapping section is a "stronger statement".

The section about GetPhysicalDeviceProcAddr says "This is only required if a layer intends to support some functionality not directly supported by loaders released in the public".  GFXR doesn't support functionality not directly supported by public loaders, so it seems reasonable to take "optional" at face value.
The "optional" statement is earlier in the doc, so I think logically it takes precedent from that point of view.
For at least a couple of years, a layer developed by reading the doc and assuming support is optional would not have failed under these circumstances because of the previous loader behavior.  So both the "optional" interpretation and the behavior of the loader were consistent!
Finally, for at least some period of time, as noted in Dustin's original PR, implementing this function in a wrapping layer would have tripped a loader bug, so a layer attempting to do things the right way and implement unwrapping for all functions would have crashed!
For these reasons I think any developer could argue reading the "optional" section and interpreting it as truly "optional" is reasonable.  I wonder if GFXR isn't the only layer suddenly having issues with VOLK.  I think it may be a good idea to state in the doc that GetPhysicalDeviceProcAddr is not optional if a layer implements wrapping.

Dereferencing a null pointer in a different layer also seems like a bug we should report; it would be simple enough for the Mesa layer to return NULL if it doesn't find the instance in its map, and then any other layer that interprets that "optional" statement would continue to work for this particular set of circumstances.

Dereferencing a null pointer in a different layer also seems like a bug we should report; it would be simple enough for the Mesa layer to return NULL if it doesn't find the instance in its map, and then any other layer that interprets that "optional" statement would continue to work for this particular set of circumstances.

I have an issue noted in Mesa on this. Awaiting comment. My best hope was that it would stop them segfaulting.
Issue in mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6526

At some later date we can look into re-architecting GFXR to use maps from Vulkan handles to internal data instead of wrapping, and evaluate the performance hit.

That seems the right way to go. Since it lets us not hook every single function using a handle type we would otherwise wrap, there may be performance gains as well as losses.

4. I wonder if GFXR isn't the only layer suddenly having issues with VOLK.
It would be interesting to use the configurator to turn on lots of layers in different orders with the samples and see what shakes out. Seems like something that could be in CI for their project or the loader's.

The issue is that a layer that wraps handles MUST ALWAYS intercept ALL functions that take handles which it wraps. No if ands or buts. And well, functions that are unknown to the layer is a big problem with handle wrapping. As soon as there is a function being called which uses one of the wrapped handles that the layer doesn't intercept, any other layer is liable to crash, if it happens to be between the application and the layer that wraps. I understand how reading the docs can lead someone to a different conclusion, but this is just the nature of handle wrapping and exactly why its not advised. Layers aren't all knowing, so intercepting all functions, including unknown ones, is practically impossible.
I will say that without knowing why dustin was seeing crashes, I cannot speculate as to what the actual issue was he was working around. I suspect it may have been something unrelated to this and has since been fixed.
I fully support the notion of moving away from handle wrapping. There are just so many gotcha's and annoyances with it that make it very undesirable unless absolutely necessary.

I appreciate you both putting in so much thought on this issue, which I've stumbled into due to hitting it myself while starting what should have been my getting to know the code, first task, from a position of vague familiarity with the loader as an application developer. So thanks for the great input, I'm learning from you! :)

I wonder if the fact that the old GetPhysicalDeviceProcAddr() was passing through wrapped instances without unwrapping them might have been responsible for some of the problems he sought to solve by removing it entirely. It certainly should have had consequences and there could have been interactions that depended on the layer stacking order.

@olvaffe Can you check to make sure that current dev fixes your issue?  My repro of Vulkan-Samples on Ubuntu is resolved.

I can still repro.
With https://github.com/LunarG/gfxreconstruct/commit/46cbaef4215c8647fee99f89ea21b6e92838f9b0 and https://github.com/KhronosGroup/Vulkan-Loader/commit/c3601d4d914212a22e0ebed5329847b9ce89596f, and a modified vkcube to call vkGetInstanceProcAddr(demo->inst, "vkFoo") right after vkCreateInstance,
$ VK_INSTANCE_LAYERS=VK_LAYER_MESA_device_select:VK_LAYER_LUNARG_gfxreconstruct gdb vkcube
(gdb) run
...
[gfxrecon] INFO - Initializing GFXReconstruct capture layer
[gfxrecon] INFO -   GFXReconstruct Version 0.9.14-dev (dev:46cbaef)
[gfxrecon] INFO - Recording graphics API capture to gfxrecon_capture_20220607T193549.gfxr
[gfxrecon] INFO -   Vulkan Header Version 1.3.216
vkcube: /home/olv/projects/Vulkan-Loader/loader/unknown_function_handling.c:315: loader_phys_dev_ext_gpa_term_no_check: Assertion `NULL != inst' failed.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x00007ffff7bf8546 in __GI_abort () at abort.c:79
#2  0x00007ffff7bf842f in __assert_fail_base (fmt=0x7ffff7d6edf8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
    assertion=0x7ffff7e2ceb5 "NULL != inst",
    file=0x7ffff7e2ce60 "/home/olv/projects/Vulkan-Tools/out/Vulkan-Loader/loader/unknown_function_handling.c", line=315,
    function=<optimized out>) at assert.c:92
#3  0x00007ffff7c07222 in __GI___assert_fail (assertion=0x7ffff7e2ceb5 "NULL != inst",
    file=0x7ffff7e2ce60 "/home/olv/projects/Vulkan-Tools/out/Vulkan-Loader/loader/unknown_function_handling.c", line=315,
    function=0x7ffff7e2d020 <__PRETTY_FUNCTION__.0> "loader_phys_dev_ext_gpa_term_no_check") at assert.c:101
#4  0x00007ffff7e00292 in loader_phys_dev_ext_gpa_term_no_check (inst=0x0, funcName=0x5555555650eb "vkFoo")
    at /home/olv/projects/Vulkan-Tools/out/Vulkan-Loader/loader/unknown_function_handling.c:315
#5  0x00007ffff7ded9c6 in loader_gpdpa_instance_terminator (inst=0x555555803580, pName=0x5555555650eb "vkFoo")
    at /home/olv/projects/Vulkan-Tools/out/Vulkan-Loader/loader/loader.c:3930
#6  0x00007ffff7dffcf8 in loader_check_layer_list_for_phys_dev_ext_address (inst=0x5555556463a0, funcName=0x5555555650eb "vkFoo")
    at /home/olv/projects/Vulkan-Tools/out/Vulkan-Loader/loader/unknown_function_handling.c:187
#7  0x00007ffff7dffdf7 in loader_phys_dev_ext_gpa_impl (inst=0x5555556463a0, funcName=0x5555555650eb "vkFoo", is_tramp=true)
    at /home/olv/projects/Vulkan-Tools/out/Vulkan-Loader/loader/unknown_function_handling.c:222
#8  0x00007ffff7e00227 in loader_phys_dev_ext_gpa_tramp (inst=0x5555556463a0, funcName=0x5555555650eb "vkFoo")
    at /home/olv/projects/Vulkan-Tools/out/Vulkan-Loader/loader/unknown_function_handling.c:307
#9  0x00007ffff7dcce0b in trampoline_get_proc_addr (inst=0x5555556463a0, funcName=0x5555555650eb "vkFoo")
    at /home/olv/projects/Vulkan-Tools/out/Vulkan-Loader/loader/gpa_helper.c:262
#10 0x00007ffff7df7ecc in vkGetInstanceProcAddr (instance=0x5555556463a0, pName=0x5555555650eb "vkFoo")
    at /home/olv/projects/Vulkan-Tools/out/Vulkan-Loader/loader/trampoline.c:106
#11 0x0000555555560296 in demo_init_vk ()
#12 0x0000555555562609 in demo_init ()
#13 0x00005555555626fe in main ()

If I use the loader from the system (version <IP_ADDRESS>-2 on debian testing), things are fine.  I bisected to https://github.com/KhronosGroup/Vulkan-Loader/commit/2ded39d6f85ab8d8bde66e1963e7b7151db77285 where the failure started happening.
Because layer order was mentioned above, I tried reversing the order and got a different failure
$ VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_gfxreconstruct:VK_LAYER_MESA_device_select gdb vkcube
(gdb) run
...
[gfxrecon] INFO - Initializing GFXReconstruct capture layer
[gfxrecon] INFO -   GFXReconstruct Version 0.9.14-dev (dev:46cbaef)
[gfxrecon] INFO - Recording graphics API capture to gfxrecon_capture_20220607T193933.gfxr
[gfxrecon] INFO -   Vulkan Header Version 1.3.216

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fb21c3 in get_instance_proc_addr (instance=0x5555557feb10, name=0x7fffec0f04b0 "vk_layerGetPhysicalDeviceProcAddr")
    at ../src/vulkan/device-select-layer/device_select_layer.c:630
630	   return info->GetInstanceProcAddr(instance, name);
(gdb) bt
#0  0x00007ffff7fb21c3 in get_instance_proc_addr (instance=0x5555557feb10, name=0x7fffec0f04b0 "vk_layerGetPhysicalDeviceProcAddr")
    at ../src/vulkan/device-select-layer/device_select_layer.c:630
#1  0x00007fffebdced9c in gfxrecon::dispatch_CreateInstance (pCreateInfo=0x7fffffffc960, pAllocator=0x0, pInstance=0x7fffffffcaf0)
    at /home/olv/projects/gfxreconstruct/layer/trace_layer.cpp:163
#2  0x00007fffebe4569e in gfxrecon::encode::VulkanCaptureManager::OverrideCreateInstance (pCreateInfo=0x7fffffffc960, pAllocator=0x0,
    pInstance=0x7fffffffcaf0) at /home/olv/projects/gfxreconstruct/framework/encode/vulkan_capture_manager.cpp:581
#3  0x00007fffebf1f64d in gfxrecon::encode::CreateInstance (pCreateInfo=0x7fffffffc960, pAllocator=0x0, pInstance=0x7fffffffcaf0)
    at /home/olv/projects/gfxreconstruct/framework/generated/generated_vulkan_api_call_encoders.cpp:59
#4  0x00007ffff7defacc in loader_create_instance_chain (pCreateInfo=0x7fffffffcab0, pAllocator=0x0, inst=0x5555556463f0,
    created_instance=0x7fffffffcaf0) at /home/olv/projects/Vulkan-Loader/loader/loader.c:4653
#5  0x00007ffff7df8dc7 in vkCreateInstance (pCreateInfo=0x7fffffffcfc0, pAllocator=0x0, pInstance=0x7fffffffd1b0)
    at /home/olv/projects/Vulkan-Loader/loader/trampoline.c:595
#6  0x00005555555601ec in demo_init_vk ()
#7  0x0000555555562609 in demo_init ()
#8  0x00005555555626fe in main ()
(gdb) p info
$1 = (struct instance_info *) 0x0

The device select layer got instance=0x5555557feb10, which was unknown to the layer.  I guess the pointer was to gfxreconstruct's wrapped VkInstance.

I reproduce your assert if I add in vkGetInstanceProcAddr(demo->inst, "vkFoo") in vkcube's init.
It looks like a small necessary changed got dropped from PR 707 because of aggressive reviewing.  I've put it back in PR 714.  You're welcome to try https://github.com/bradgrantham-lunarg/gfxreconstruct branch brad-put-back-table-vk_layergpdpa if you're feeling adventurous.  Tomorrow we'll merge that PR if it passes all our testing.

https://github.com/LunarG/gfxreconstruct/commit/82e04fabc1b92852354e4d379017a7744435410b fixed the original issue and the layer ordering issue for me.  Thanks!


iptsd: build iptsd-calibrate

Description of changes
Enables the building of iptsd-calibrate tool, which can be used to manually calibrate the touch detection parameters of iptsd.
Things done

Built on platform(s)

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 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.

Is there a way to integrate this in the NixOS module?

No idea what could be done from the NixOS module side. It's an interactive app that you'd launch manually. The app outputs measured values (tailored to your finger shape), which you need to manually convert to NixOS configuration like this:
{ ... }: {
  # Replace with `services.iptsd.config` when using NixOS builtin module
  microsoft-surface.ipts.config = {
    Contacts = {
      SizeMin = 0.600;
      SizeMax = 1.500;
      AspectMin = 1.000;
      AspectMax = 2.500;
    };
  };
}


HARVESTER: The saved preference will be reset after the page is refreshed

Summary
PR Checklist
~- Is this a multi-tenancy feature/bug?
- [ ] Yes, the relevant RBAC changes are at:~
~- Do we need to backport changes to the old Rancher UI, such as RKE1?
- [ ] Yes, the relevant PR is at:~
~- Are backend engineers aware of UI changes?
- [ ] Yes, the backend owner is:~
Fixes The saved preference will be reset after the page is refreshed

Occurred changes and/or fixed issues

https://github.com/harvester/harvester/issues/3958

Technical notes summary

const asUserPreference = opt.asUserPreference !== false;

// undefined !== false => const asUserPreference = true

Areas or cases that should be tested

Areas which could experience regressions

Screenshot/Video

@mergify backport release-harvester-v1.1

@mergify backport release-harvester-v1.2


Updating units tests to use set_up_variable_cube.

Addresses #GitHubissuenum
Description
I changed a variety of unit tests to use the set_up_cubes.py code. However there is still a bug in test_DiagnoseConvectivePrecipitation.py. I have put comments in the code to try and explain what is happening. I don't think it is an IMPROVER issue right now.
Testing:

[ ] Ran tests and they passed OK (mostly)
[x] Added new tests for the new feature(s)

There is a ValueError for one of the unit tests in test_DiagnoseConvectivePrecipitation which says "ValueError: 'time' is not in list"

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 9

Clones added
============
- improver_tests/utilities/test_DifferenceBetweenAdjacentGridSquares.py  2

Clones removed
==============
+ improver_tests/convection/test_DiagnoseConvectivePrecipitation.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

Clones added
============
- improver_tests/utilities/test_DifferenceBetweenAdjacentGridSquares.py  2

Clones removed
==============
+ improver_tests/convection/test_DiagnoseConvectivePrecipitation.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Clones added
============
- improver_tests/utilities/test_DifferenceBetweenAdjacentGridSquares.py  2

Clones removed
==============
+ improver_tests/convection/test_DiagnoseConvectivePrecipitation.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity decreasing per file
==============================
+ improver/nbhood/nbhood.py  -1

Clones added
============
- improver_tests/utilities/test_DifferenceBetweenAdjacentGridSquares.py  2

Clones removed
==============
+ improver_tests/convection/test_DiagnoseConvectivePrecipitation.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

Complexity decreasing per file
==============================
+ improver/nbhood/nbhood.py  -1

Clones removed
==============
+ improver_tests/utilities/test_OccurrenceWithinVicinity.py  -8
+ improver_tests/convection/test_DiagnoseConvectivePrecipitation.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity decreasing per file
==============================
+ improver/nbhood/nbhood.py  -1

Clones removed
==============
+ improver_tests/convection/test_DiagnoseConvectivePrecipitation.py  -1
+ improver_tests/utilities/test_OccurrenceWithinVicinity.py  -8

See the complete overview on Codacy

Hi Caroline,
I’ll look at this as well when I do the updates ☺ I hope things are going well,
Cheers,
Katie
From: cgsandford<EMAIL_ADDRESS>Sent: 22 June 2020 18:13
To: metoppv/improver<EMAIL_ADDRESS>Cc: Howard, Kathryn<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [metoppv/improver] Updating units tests to use set_up_variable_cube. (#1280)
@cgsandford commented on this pull request.

In improver_tests/utilities/test_OccurrenceWithinVicinity.pyhttps://github.com/metoppv/improver/pull/1280#discussion_r443708598:

@@ -257,16 +203,9 @@ def test_with_multiple_realizations_and_times(self):

             ],

         ]

     )

   data = np.zeros((2, 2, 4, 4))

   data[0, 0, 2, 1] = 1.0

   data[1, 1, 1, 3] = 1.0

   cube = set_up_cube(

       data,

       "lwe_precipitation_rate",

       "m s-1",

       timesteps=np.array([402192.5, 402195.5]),

       realizations=np.array([0, 1]),

   )

   cube = add_coordinate(self.cube, self.timesteps, "time", order=[1, 0, 2, 3])

Ah I missed this! Can I add to Ben's comments here: when using this function to add a time dimension, it is much preferred to use the is_datetime argument, for example:
cube = add_coordinate(
self.cube, [datetime(2017, 11, 9, 12), datetime(2017, 11, 9, 15)], "time",

order=[1, 0, 2, 3], is_datetime=True

)
It was designed this way to make the tests more human-readable, and so that if we do ever want to change the handling of time coordinates (units or datatypes), we only have to update that once in the set_up_test_cubes module.
Please could you update that wherever it's used, rather than setting the time point values as integers?
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/metoppv/improver/pull/1280#discussion_r443708598, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGMBO462TTBLZOKXL6RNMJ3RX6GLRANCNFSM4OBM6YCA.

 Here is an overview of what got changed by this pull request:

Complexity decreasing per file
==============================
+ improver/nbhood/nbhood.py  -1

Clones removed
==============
+ improver_tests/convection/test_DiagnoseConvectivePrecipitation.py  -1
+ improver_tests/utilities/test_DifferenceBetweenAdjacentGridSquares.py  -2
+ improver_tests/utilities/test_OccurrenceWithinVicinity.py  -8

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity decreasing per file
==============================
+ improver/nbhood/nbhood.py  -1

Clones added
============
- improver_tests/nbhood/nbhood/test_BaseNeighbourhoodProcessing.py  3

Clones removed
==============
+ improver_tests/utilities/test_OccurrenceWithinVicinity.py  -8
+ improver_tests/convection/test_DiagnoseConvectivePrecipitation.py  -1
+ improver_tests/utilities/test_DifferenceBetweenAdjacentGridSquares.py  -2

See the complete overview on Codacy

I think I have addressed all the comments from @bayliffe  and added the extra unit test.

 Here is an overview of what got changed by this pull request:

Complexity decreasing per file
==============================
+ improver/nbhood/nbhood.py  -1

Clones added
============
- improver_tests/nbhood/nbhood/test_BaseNeighbourhoodProcessing.py  3

Clones removed
==============
+ improver_tests/utilities/test_OccurrenceWithinVicinity.py  -8
+ improver_tests/convection/test_DiagnoseConvectivePrecipitation.py  -1
+ improver_tests/utilities/test_DifferenceBetweenAdjacentGridSquares.py  -2

See the complete overview on Codacy


Monolingual LM training data

@mfederico
What is the priority of supporting monolingual data for LM training.
MMT uses today only the target translation as LM.

This feature has been introduced with this commit: https://github.com/ModernMT/MMT/commit/d0478428c8234acbe75f545bcf08ef1f691f5bec
You can find it in the develop branch right now, it will be released with version 0.12 as expected.


Update request: glib-networking 2.76.1 → 2.78.0

Package name: glib-networking
Latest released version: 2.78.0

Current version on the unstable channel: 2.76.1
Current version on the stable/release channel: 2.76.0

[x] Checked the nixpkgs pull requests

Notify maintainers
@jtojnar
@NixOS/gnome

Note for maintainers: Please tag this issue in your PR.

Part of #247766


Consider removing "keep metadata" checkbox

Can this be removed, or is there an important reason for it? It doesn't seem like something that needs to be used often, and I think it might be confusing for many folks. And because the setting is remembered, it might get unchecked inadvertently and basically become a data loss issue.

Can this be removed, or is there an important reason for it?

I thought that some people may find it useful to save a file without any embedded metadata.
For example, someone may want to remove the EXIF metadata for file size or privacy reasons before uploading the WebP file to the Internet.
I can remove the checkbox if you want, there are probably other apps that can remove embedded metadata from WebP files.

Yeah my advice has generally been to use an external utility to strip the metadata if that's what someone wants.
Basically, either all of the built-in/bundled FileTypes should have a "keep metadata" option, or none of them should.

Basically, either all of the built-in/bundled FileTypes should have a "keep metadata" option, or none of them should.

That makes sense, I will remove the checkbox.
Sent with GitHawk


Why it not works?

I do it

and get it

fixed in https://github.com/kapi1525/NoiseExtension/commit/b33f2ce9a88c2f77f5f790e0fd2055dfb1e1f8ff
will release new version with those fixes in a few days.
for now you can download a test build here: https://github.com/kapi1525/NoiseExtension/actions/runs/7393336826/artifacts/1144458992


mbedtls_x509_crt_parse_file() return value is different in 2.3.x than 2.4.x

I am testing an upgrade to mbedtls-2.4.x (2.4.0 & 2.4.1) and found that my code is failing here:
    mbedtls_x509_crt_init(&ctx->ca_cert);
    ret = mbedtls_x509_crt_parse_file(&ctx->ca_cert, ca_file);
    if (ret != 0) {
        char tmp[1024];
        mbedtls_strerror(ret, tmp, 1024);
        flb_error("[TLS] Invalid CA file: %s | %s", ca_file, tmp);
        goto error;
    }

the error is:
[TLS] Invalid CA file: /etc/ssl/certs/ca-certificates.crt | UNKNOWN ERROR CODE (0001)

if I use mbedtls-2.3 parsing /etc/ssl/certs/ca-certificates.crt works just fine, but with 2.4 I got a different value (UNKNOWN ERROR CODE).
would you please advice how to fix it ?

checking the mbedtls examples I found:

cert_write.c: it checks return value of mbedtls_x509_crt_parse_file() != 0
cert_app.c:  it checks return value of mbedtls_x509_crt_parse_file() < 0
cert_write.c: it checks return value of mbedtls_x509_crt_parse_file() != 0

what's the proper way to validate ?

Hi Eduardo,
As mentioned in include/mbedtls/error.h:
Currently we try to keep all error codes within the negative space of 16 bits signed integers to support all platforms (-0x0001 - -0x7FFF).
Therefore, only negative values are considered errors.
The documentation for  mbedtls_x509_crt_parse_file() says that this function is "permissive", so it may return a positive value whenever some certificates can be parsed but others cannot. If this is the case, the positive value corresponds to the number of failed certificates.
As for the examples you showed, it is very dependent on the usage of mbedtls_x509_crt_parse_file(). For example, on cert_write.c, we don't want any failures in the issuer certificate chain, hence we check for any value different from 0. On cert_app.c, the application parses the CA certificate chain, and it is possible that it will return failed certificates along the chain.
Regards,
mbed TLS Team Member
Ron

Thanks for the explanation!


Add a plugin to detect possible bugs in array key literals.

For this code:
var_export(['0' => 'y', 0 => 'z']);
var_export(['y', 'a' => 'z']);

The DuplicateArrayKeyPlugin will emit the below errors:
src/test.php:3 PhanPluginDuplicateArrayKey Duplicate/Equivalent array key
literal(0) detected in array - the earlier entry will be ignored.
src/test.php:4 PhanPluginMixedKeyNoKey Should not mix array entries of
the form [key => value,] with entries of the form [value,].
(Also detects bugs such as ['a' => 'b', 'a' => 'c'], which is syntactically valid php)
Aside: the wiki doesn't mention the recommended way to contribute plugins.

Are the developers of phan planning to rename local variables to camelCase? I see underscores in variable names as a very common convention, including in the example plugin.
If it's unimportant, can that specific codeclimate check be disabled?
The parameter $code_base is not named in camelCase.

This has nothing to do with Phan, does it? Phan has no opinion on style
issues like that and the check is certainly not in Phan.
On Fri, Nov 11, 2016 at 9:14 PM, Tyson Andre<EMAIL_ADDRESS>wrote:

Are the developers of phan planning to rename local variables to
camelCase? I see underscores in variable names as a very common convention,
including in the example plugin.
If it's unimportant, can that specific codeclimate check be disabled?
The parameter $code_base is not named in camelCase.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/etsy/phan/pull/390#issuecomment-260102655, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADVcadFcI50gENOb_cChbmDV9dY21xYks5q9UsfgaJpZM4KwKBh
.

 I have no idea if it can be turned off.

https://github.com/etsy/phan/pull/392

Thanks for another lovely patch, @TysonAndre!


Templates waterfall form

Hi @JuanAr, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.
TTYL, AZPRBOT;


Remove cask/cmd/zap

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

remove cask/cmd/zap because of https://github.com/Homebrew/brew/issues/14799

Thanks again @hyuraku! Looks good once CI is 🟢


CasSaml11Response code lines unused

I was looking at CasSaml1Response.cs and noticed that these lines are not actually used...
var xmlReaderSettings = new XmlReaderSettings();
xmlReaderSettings.ConformanceLevel = ConformanceLevel.Auto;
xmlReaderSettings.IgnoreWhitespace = true;
xmlReaderSettings.IgnoreComments = true;
xmlReaderSettings.CloseInput = true;
....
string authMethod = SamlUtils.GetAttributeValue(authenticationStmtNode.Attributes, "AuthenticationMethod");
...
IList authValues = new List();
IDictionary<string, IList> authenticationAttributes = new Dictionary<string, IList>();
authValues.Add(authMethod);
authenticationAttributes.Add("samlAuthenticationStatement::authMethod", authValues);
Is this intentional? Or have I miss understood something?

I have commented out lines 115-119, line 152, and lines 163-166 of CasSaml1Response.cs. I then compiled the assembly and used it in a test project, using the Saml11 ticket validator, with success. I also tested with the role provider enabled without issue.
As Jetski5822 pointed out, xmlReaderSettings and authenticationAttributes are never consumed anywhere in the ProcessValidAssertion() method, as far as we can tell. Perhaps these are artifacts left over from initial development? If a project maintainer could confirm these findings, I will create a pull request to remove these unused lines and we can close out this old issue?

@hokiecoder @Jetski5822
I think I'm going to take a glance over at the Java and PHP client repos to see what they are doing to get some insight as to what this code might have been used for at one point or intended to be used for.

This is orphaned code that was in the repo, since it was in Git, all the way back to this files first commit by @serac in https://github.com/apereo/dotnet-cas-client/commit/50046c7a62e40fca3da415952701ea6dc90af494
I didn't do any further research, but it may have been for debugging XML purposes or something carried over from the Java CAS Client project.
I'm going to remove the orphaned code in develop since this doesn't warrant a hotfix release.  I'll be available in the next minor/major release.

@phantomtypist I looked through the Java client code and came to my understanding that the handling of XML documents in .NET is quite different than in Java, so the code doesn't really have much comparison. However, I did look through the docs on the properties that are, in a futile effort, being set in this .NET client's code as mentioned by Jetski5822. I agree with your assessment that the code is orphaned as XmlReaderSettings is not even used by the XmlDocument class directly. It seems, to me, that it is useful for when XML is being read from a source with the intention of being (possibly) modified and stored again. But in the case of this project, the XML is just being parsed to create a SAML response object.
Just an FYI to concur with your choice!


Fix checkout.session.completed handler to properly handle buying extra credits

We had a flaw in our "credit buy" links where we forgot to include the client_reference_id, which tells us which user bought the credits. I added that query param in the links and adjusted the webhook handler. Also did a small refactor for encoding/decoding logic so that it's clearer what it does.
Tested on staging and I was able to buy myself extra credits without problems.

Thanks @lukemelia for code change suggestions!


Is there an intelligent prompt ide or plug-in to support grammar?

Is there an intelligent prompt ide or plug-in to support grammar?

There is not. Pull requests welcome, of course.
https://github.com/glycerine/zygomys/blob/master/zygo/liner.go#L11  shows the tab completion machinery that is installed, which is limited. Mostly LISP grammar is incredibly uniform, it is learned very quickly.  I do recommend emacs for the electric brace functionality and general LISP friendliness it provides.

I will pay close attention to your project and see how the smarttip plugin is progressing. I think it is already rich enough. Why is it not compatible with Goland's smart tips? I think this will be liked by many people.

@glycerine I'm considering zygomys for a project of mine.  I've been wanting to dive into language design for a while now, and I think building this kind of feature might be a good jumping-off point for me.
Would you be generally available to help me out if I were to undertake this?

@lthibault Hi Louis, lisp has almost no grammar, just prefix forms, so this "feature" makes no sense to me. Hence I cannot recommend it.  I don't see the goal or idea.  More importantly, it doesn't do anything towards your goal of learning about language design.

@glycerine Fair point -- thanks for the candid feedback (seriously, you just helped me avoid a potential rabbit-hole)!


Added gis_no command for Norway

Implemented gis_no command for Norway which uses the Kartverkets Elevation WPS service. More info can be found on the geonorge.no website.
Also, I implemented an XML to JSON function, which takes a string containing an XML document and outputs a JSON object. It relies on no external dependencies, like xmldom, and uses the usual string manipulation functions like slice. It only parses tag values and stores them as a string and ignores XML attributes. Depending on if the returned string in the elevation module starts with a {, the JSON parser is used, otherwise, it uses the new function. The function accepts both JS strings and Java strings.
As the Kartverkets Elevation WPS returns an overconsumption warning, which warns you to wait a minute to make a request again, it is advisable to use small work areas and use the smooth:false option.

Thank you for this addition!
I'm glad that some people have the courage to contribute to BTE-tools, it's really not easy. If someone has the skills, one should make it a mod.
I just ran the "standard" linter on the code, everything else is very well done.
I will release a new version very soon.


rchk problems

Currently:
Package duckdb version 0.2.1-2
Package built using 79279/R 4.1.0; x86_64-pc-linux-gnu; 2020-09-30 14:05:37 UTC; unix
Checked with rchk version 36c7ad2294619ba0a81109c9acb675eea2c96e6d
More information at https://github.com/kalibera/cran-checks/blob/master/rchk/PROTECT.md

Function duckdb_execute_R
  [UP] unprotected variable <unnamed var:   %2 = alloca %struct.SEXPREC*, align 8> while calling allocating function std::__1::unique_ptr<duckdb::QueryResult, std::__1::default_delete<duckdb::QueryResult> >::~unique_ptr() duckdb/src/duckdbr.cpp:611

While this might be a false positive, it would be useful to remove this error. Could the ~StreamQueryResult() destructor allocate (theoretically) through some obscure path?
I see two remedies:

Switch to unique_ptr<MaterializedQueryResult>, perhaps through a helper function. (Let's hope this destructor isn't flagged as an allocating function.)
Introduce a helper function that stores the intended result in a caller-owned VECSXP object of length one.

It is unfortunate that we can't seem to easily replicate locally what CRAN is seeing: https://github.com/kalibera/rchk/issues/24.

Can you try generic_result.reset(); just before the last UNPROTECT in  duckdb_execute_R ? I don't have rchk running here :/

I can't replicate the results either: https://github.com/kalibera/rchk/issues/24.

Merged now in #1041.


Find media in list

Hello,
Maybe it's already here and I didn't find it but is it possible to add a new feature to help us find if a movie/show/episode (by trakt Id) is present in a specific list ?
You can use the media summary endpoint to add these information -> /movies/:trakt-id?availability_in_lists=listId1,listId2.
In the response we should see something like this
{
   ...
   availability: {
      listId1: true,
      listId2: true
   }
}

With this option we can show in the detail view of a media if it is available in one or more lists

Found it in the documentation -> https://trakt.docs.apiary.io/#reference/movies/lists/get-lists-containing-this-movie
Thank you.


ENH: Flexibilize "sophisticated" pepolar to allow monomodal execution

Changes proposed in this pull request

Documentation that should be reviewed

What use case is this intended to support?

I have a dataset with all four AP/PA/LR/RL EPIs. This should be easy to handle by topup.

What about len(suffixes) >= 2, then? Or we could drop the length check altogether and rely on sdcflows to not create estimators with too few inputs.

What about len(suffixes) >= 2, then? Or we could drop the length check altogether and rely on sdcflows to not create estimators with too few inputs.

The idea is that the four images are of the same modality. That would allow for epi + bold (which should be capture by the other condition, and disallow more than 2 images)

Got it. Let's add a comment, as I'm sure I'll forget.

Sure, I'll add it later today
On Sun, Nov 3, 2024, 13:57 Chris Markiewicz @.***>
wrote:

Got it. Let's add a comment, as I'm sure I'll forget.
—
Reply to this email directly, view it on GitHub
https://github.com/nipreps/fmriprep/pull/3393#issuecomment-2453418957,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAESDRSXEOWKSYYIKKP4HLDZ6YFULAVCNFSM6AAAAABRCP3HQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGQYTQOJVG4
.
You are receiving this because you authored the thread.Message ID:
@.***>


cmd/build: add new --manifest-only, --manifest-path and -arch options

This PR tweaks the build binary to make it easier for otk to use it to generate reference images. With the tweaks here the tests in otk can generate reference images via:
$ go run github.com/osbuild/images/cmd/build@latest -type -distro centos-9 type qcow2 -arch aarch64 -manifest-only -manifest-path test/data/reference-images/<our-location>

that can then be used to validate that the otk generated images are identical to the ones generated by images

The idea of having this is good but there's some confusion for me; how is this different from using cmd/gen-manifests. Perhaps it'd be better suited to add the manifest-path there?

Sure, that could also be done, I have no super strong opinion either way. My reasoning is that using gen-manifest seems to be more geared for the mass build task and it will be harder to add a "--manifest-path" as it will be auto-generated which means the other tool that drives it needs to know what the resulting filename is (or use the same pattern) and it also needs post-processing bcause AFAICT the generated files are not manifests but contain a build-request key and some extra data. Can all be done but I would rather move "build" into a more generally useful tool (that we can eventually use for project excosim) - but happy to hear other thoughts (e.g. @achilleas-k )

My reasoning is that using gen-manifest seems to be more geared for the mass build task and it will be harder to add a "--manifest-path" as it will be auto-generated which means the other tool that drives it needs to know what the resulting filename is (or use the same pattern)

This got me thinking if it would be useful to have a --filename-format flag that can interpret patterns.  For example, our current (default) format would be (in standard Go template form):
{{ distro }}-{{ arch }}-{{ type }}-{{ config_name }}.json

(though we also do s/-/_/ on each component).

it also needs post-processing bcause AFAICT the generated files are not manifests but contain a build-request key and some extra data.

The extra bits can be skipped with --metadata=false in gen-manifests.  That produces clean manifests.

Closing as this is no longer used/needed for https://github.com/osbuild/otk/pull/188


Async pick/sample functions don't work with explicit rendering

Async functions Scene.prototype.sampleHeightMostDetailed() and Scene.prototype.clampToHeightMostDetailed() do not play nice with explicit rendering.  The way these functions work is:

create a promise for each point to be sampled, which resolves when all high-detail tiles needed for sampling that point have been loaded.

create a promise which resolves when all promises created at step 1 resolve.

pass the promise from step 2 to deferPromiseUntilPostRender(), which returns a new promise that resolves during the next post-render event after the promise from step 2 has resolved.  This prevents the risk of modifying primitives during render callback (see https://git.patrocinium.com/pub/cesium/commit/502f34abebb4ffb06dfc1671db0983c52fdffe70)

The return value is the promise created at step 3.

If an app that is using explicit rendering calls sampleHeightMostDetailed(), and waits for the returned promise without explicitly calling scene.requestRender(), the promise won't resolve, because there are no post-render events.  This means the app may seem non-responsive to the user.
The app can't easily schedule a render using calling scene.requestRender(), because there's no way to know when the promise from step 2 resolved.  The solution that worked for me is to modify deferPromiseUntilPostRender() to call scene.requestRender() when promise 2 resolves:
    function deferPromiseUntilPostRender(scene, promise) {
        // Resolve promise after scene's postRender in case entities are created when the promise resolves.
        // Entities can't be created between viewer._onTick and viewer._postRender.
        var deferred = when.defer();
        promise.then(function(result) {
            var removeCallback = scene.postRender.addEventListener(function() {
                deferred.resolve(result);
                removeCallback();
            });
            scene.requestRender();      <== add this line
        });
        return deferred.promise;
    }

Incidentally, it would also be very desirable for an app to be able to cancel pending calls to the async pick/sample functions when they are no longer needed.  I'm doing it by setting scene._mostDetailedRayPicks = [], because I know I'm the only user of that array, but that wouldn't work in a more complex app.
Browser: Chrome
Operating System: MacOS 10.14.6
No time to do a sandcastle, sorry.

@richard-ling that seems like a good fix. I'll open a PR shortly.

Incidentally, it would also be very desirable for an app to be able to cancel pending calls to the async pick/sample functions when they are no longer needed.

Can you open a separate issue for this? It does sound like a useful feature.


Cannot Upload asset files

There is no way to upload Asset files in the SDK

Hi,
you will be able to upload everything that has a non local url. So you would be able to upload it (temporarily) to google drive, dropbox, or any other 3rd party provider, and then create an asset, process it and publish it. Afterwards you can safely delete it from the 3rd party upload.

Ok I will update the issue title

Hey,
sorry, but it is just not possible to upload an asset to contentful directly. Please use a third-party upload library to receive a url containing your assets.

Could you provide a working example?

Hey,
sure, you would create an upload like this:
https://www.contentful.com/developers/docs/references/content-management-api/#/reference/uploads/upload-a-file/creating-an-upload-resource/console/android
and then create a new asset using the following snippet and the upload id from the previous step in the uploadFrom file field:
https://www.contentful.com/developers/docs/references/content-management-api/#/reference/assets/assets-collection/create-an-asset/console/android
In total it will look something like this:
// initialize
final String spaceId = "SPACE_ID";
final String cmaToken = "CMA_TOKEN";
final String filePath = "FILE_PATH";

final CMAClient client = new CMAClient.Builder()
    .setAccessToken(cmaToken)
    .build();

// create binary upload
final CMAUpload cmaUpload = client
    .uploads()
    .create(
        spaceId,
        FileUtils.openInputStream(new File(filePath))
    );

// create asset
CMAAsset asset = new CMAAsset();
asset.getFields()
    .setTitle("en-US", "Title")
    .setDescription("en-US", "Picture");

CMAAssetFile file = new CMAAssetFile()
    .setUploadFrom(
        new CMALink(CMAType.Upload).setId(cmaUpload.getId())
    )
    .setFileName("filename.jpg")
    .setContentType("image/jpeg");

asset.getFields().setFile("en-US", file);

// create asset on contentful
asset = client.assets().create(spaceId, asset);

client.assets().process(asset, "en-US");

// wait till processing is done
String url = asset.getFields().localize("en-US").getFile().getUrl();
int attempts = 10;
while (attempts > 0 && (url == null || url.length() == 0)) {
  asset = client.assets().fetchOne(spaceId, asset.getId());
  url = asset.getFields().localize("en-US").getFile().getUrl();
  attempts--;

  try {
    Thread.sleep(500);
  } catch (Exception e) {
    e.printStackTrace();
  }
}

if (attempts <= 0) {
  throw new IllegalStateException("Could not finish processing for " + asset);
}

client.assets().publish(asset);

Greetings,
Mario


Failed to execute 'setSelectionRange' on 'HTMLInputElement': The input element's type ('number') does not support selection.

I got warnings:
bootstrap-editable.js:666 Uncaught InvalidStateError: Failed to execute 'setSelectionRange' on 'HTMLInputElement': The input element's type ('number') does not support selection.
when setting editable to

+1

Dupe: https://github.com/vitalets/x-editable/issues/939


Cancers

Ozonated generator water sorce ai bing cancer prevention tomer teeth gingivitis plant growth singal cell organizum perpetual generator water sorce

Nasa project cancer prevention


Support API queries for non-enumerated ecosystems

Enable OSV.dev API queries for specific versions in non-enumerated ecosystems (e.g., Ubuntu, Rocky Linux, AlmaLinux).
curl -d '{"package": {"name": "curl", "ecosystem": "Ubuntu"}, "version": "8.2.1-1ubuntu3.1"}' http://api.osv.dev/v1/query

I think we can close this as done @hogo6002  ?


tickets/SP-1359

PR for updates to demonstrate how to use getOverlappingExposures to tutorial notebook 03c on big cutouts

Forgot to write down but, tested at data.lsst.cloud with dp02 butler repo, not dp02-direct, and it works fine.


Define a project brief

Define the expected criteria for starting the project using 'epics' in the form of bullet points.
Expected outcome:

Clearly defined user goals
Understand client expectations
Gauge project scope

I am thinking of something like this, let me know what you think.

As a user I can visit the homepage so that I can find out about yk and its website features
As a user I can view local historic and current information about yk so that I can learn about yk
As a user I can read news articles so that I can keep up to date with local news
As a user I can view posts from other yk community members so that I can see content other yk users are sharing
As a user I can sign up to the yk site so that I can interact with the logged in features of yk


Delete old Python implementation

The old Python script is quite confusingly still in the repo.

Occasionally some people still seem to prefer it, though I don't know why.
I leave it for occasions people want to grab it instead, since I've encountered at least a couple of people that do so instead of using the Go release. Some probably do it so they can change it to fit their needs but don't use Go. ¯\_(ツ)_/¯
And while I understand finding it would be as simple as going to the last commit that would have it once removed, I think at some point I'll just put it in its own branch clearly marking it deprecated if I ever get back to touching this haha.


Lack of feature - pre-selected item in FUEL UX Tree

When building a tree, one should be able to inform in datasource if the item is checked or not.
I could not find this basic feature and till now, even a workaround...

Any news ?


feat(GlobalPage): Make footer optional

Overview

Makes footer prop optional for use in new enterprise module landing pages where we don't want to show the footer

PR Checklist

[ ] Related to designs:
[x] Related to JIRA ticket: WEB-2288
[x] I have run this code to verify it works
[ ] This PR includes unit tests for the code change
[ ] This PR includes testing instructions tests for the code change
[ ] The alpha package of this PR is passing end-to-end tests in all relevant Codecademy repositories

Testing Instructions

Don't make me tap the sign.
PR Links and Envs

Repository
PR Link
PR Env

Monolith
Monolith PR
Monolith Env

Portal
Portal Link
Portal Env

Another Repo
Another Link
Another Env

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.291-alpha.d25477.0@codecademy/gamut-labs@35.7.1-alpha.d25477.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://640f9193b96d6c1501189426--gamut-preview.netlify.appDeploy Logs


ParamsByPath now iterates response pages plus recursive

Only 10 parameters are being retrieved when many more exist.   This is caused by aws-sdk bug/feature with a max pagination result limit of 10 when using the path call.  The PR adds iterating through the page results to fix this.

Nice one!


[SPARK-16371][SQL] Do not push down filters incorrectly when inner name and outer name are the same in Parquet

What changes were proposed in this pull request?
Currently, if there is a schema as below:
root
  |-- _1: struct (nullable = true)
  |    |-- _1: string (nullable = true)

and if we execute the codes below:
df.filter("_1 IS NOT NULL").count()

This pushes down a filter although this filter is being applied to StructType.(If my understanding is correct, Spark does not pushes down filters for those).
The reason is, ParquetFilters.getFieldMap produces results below:
(_1,StructType(StructField(_1,IntegerType,true)))
(_1,IntegerType)

and then it becomes a Map
(_1,IntegerType)

Now, because of  ....lift(dataTypeOf(name)).map(_(name, value)), this pushes down filters for _1 which Parquet thinks is IntegerType. However, it is actually StructType.
So, Parquet filter2 produces incorrect results, for example, the codes below:
df.filter("_1 IS NOT NULL").count()

produces always 0.
This PR prevents this by pre-checking supported types for Parquet filter push down.
How was this patch tested?
Unit test in ParquetFilterSuite.

Hi, @rxin @liancheng, I hope this is not missed to 2.0..

cc @viirya as well.

Test build #61840 has started for PR 14067 at commit 54b8348.

Test build #61841 has started for PR 14067 at commit 39e66ee.

LGTM pending Jenkins.
2.0.0 RC2 has already been cut. We may have this in 2.0.0 if there was another RC.

Oh, @liancheng I just corrected some more. Please take another look..

Test build #61842 has started for PR 14067 at commit ffaa666.

The description seems incorrect. It should be a StringType, instead of IntegerType?

yes it is, I just found I will correct them all. Thank you!

Another question is when the inner field is not the same name, we still can push down the filter, right?

Test build #61843 has started for PR 14067 at commit 1300042.

If so, then this patch seems completely skip all such push down.

Hm... I though Spark does not support filter-push down for nested fields.

Test build #61841 has finished for PR 14067 at commit 39e66ee.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/61841/
Test PASSed.

Test build #61840 has finished for PR 14067 at commit 54b8348.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/61840/
Test PASSed.

Test build #61842 has finished for PR 14067 at commit ffaa666.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/61842/
Test PASSed.

Test build #61843 has finished for PR 14067 at commit 1300042.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/61843/
Test PASSed.

Merged build finished. Test PASSed.

Yea, currently Spark SQL doesn't support column pruning and/or filter push-down for nested fields.

OK. LGTM then.

I'm going to merge this and fix some comments myself with another pr. Merging in master/2.0.

FYI https://github.com/apache/spark/pull/14074/files


Fix typos

@GeertvanHorrik,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Thanks for your contributions!


Added sqlalchemy query to retrieve job history stats per destination

This PR addresses https://github.com/usegalaxy-eu/tpv-metascheduler-api/issues/6
Query added in example_tpv_config_locations_api.yml  that retrieves historical statistics about job states per destination. Currently the query is filtered for .pulsar. destinations and a timefrane of 30 days.
An example request with the additional stats that will be sent to the API is in the README.md
TODO:

Add logic that can use these additional statistics @abdulrahmanazab

Looks great, but these new attributes are job specific, right?
The way it is not, it is site specific. Or is it supposed to be like:
When a submission of a job J of tool X is made, then TPV gets the attributes of each destination (which are specific to jobs of tool X) which then can be used in the logic?

They are aggregates across all past and current jobs submitted to a specific site/destination. The aggregates are not filtered for specific tools but could be if that's a requirement?


in-page ToC overlaps footer when window is short enough

from June 2020 pre-launch bug bash
Created by: Lia
Description
ToC should go behind footer
Info
Bug source: unknown
Browser: Chrome + Safari
PR: none
Attachments

Confirmed with @liaprins-czi that this isn't reproducible anymore, so it likely got fixed by another PR 😄


fontbakery.com crash, site is currently not useable

Observed behaviour

(Describe the results you're getting)
Expected behaviour
(Describe what you expected to happen, or wished was different)
Resources and steps needed to reproduce
(Provide the font file that causes the issue, and the exact steps to reproduce it. Also mention the FontBakery version you're using, and some details about your system, e.g. OS, Python version, etc.)

Sorry; I fixed it!


Feat: Vault details

Polkadot Vault details
4 new components: RootAccountLg/Md, DerivedAccount, ContextMenu
Style fixes for Vault onboarding

Task linked: CU-8692x3zz5 Show Polkadot Vault wallet details


A broken link to Flare's website

You have a broken link to Flare here: https://github.com/flame-engine/flame/blob/master/doc/images.md#FlareAnimation

Fixed on befbb90


LogCapture defaults to DEBUG and changes all output during testing.

I'm not sure what the intended behavior is.  One problem is django nose seems to output all logging commands to the console during test.  I need to find a fix for that as well.
But what I found is when I upgraded nose, LogCapture sets the default logging level to 0 at the root logger.  Is this the intended behavior?  Or should the logcapture level be only set for the specific logcapture handler?
(relevant code:

/perfcat/pcat/virtualenv/lib/python2.7/site-packages/nose/plugins/logcapture.py(195)setupLoghandler()
194         loglevel = getattr(self, "loglevel", "NOTSET")
--> 195         root_logger.setLevel(getattr(logging, loglevel))
196
)

Before:

ipdb> import logging_tree
ipdb> logging_tree.printout()
<--""
   Level WARNING
   Handler Stream <open file '<stderr>', mode 'w' at 0x7f290ef00270>
   Handler <nose.plugins.logcapture.MyMemoryHandler object at 0x27f7e50>
   |
   o<--"celery"
   |   Handler <kombu.log.NullHandler object at 0xc35950>
   |   |
   |   o<--"celery.task"
   |       Handler <kombu.log.NullHandler object at 0xc35ad0>
   |
   o<--"django"
   |   Handler <logging.NullHandler object at 0x1693850>
   |   |
   |   o<--[django.db]
   |   |   |
   |   |   o<--"django.db.backends"
   |   |
   |   o<--"django.request"
   |       Level ERROR
   |       Handler <django.utils.log.AdminEmailHandler object at 0x1693950>
[...]

After:

ipdb> logging_tree.printout()
<--""
   Handler Stream <open file '<stderr>', mode 'w' at 0x7f290ef00270>
   Handler <nose.plugins.logcapture.MyMemoryHandler object at 0x27f7e50>
   |
   o<--"celery"
   |   Handler <kombu.log.NullHandler object at 0xc35950>
   |   |
   |   o<--"celery.task"
   |       Handler <kombu.log.NullHandler object at 0xc35ad0>
   |
   o<--"django"
[...]

Might be same issue as #160


Special transformers case from args

xpu_backend can be None, and in the transformers integration we pass it to PartialState due to the fact that no_cuda is a toggleable option and can still be True on CPU. This PR makes it so that if the last case is hit in this block:
        if self.no_cuda:
            self.distributed_state = PartialState(cpu=True)
            self._n_gpu = 0
        elif is_sagemaker_mp_enabled():
            local_rank = smp.local_rank()
            device = torch.device("cuda", local_rank)
            self._n_gpu = 1
            torch.cuda.set_device(device)
        elif self.deepspeed:
            # Need to do similar for Accelerator init
            os.environ["ACCELERATE_USE_DEEPSPEED"] = "true"
            self.distributed_state = PartialState(timeout=timedelta(seconds=self.ddp_timeout))
            del os.environ["ACCELERATE_USE_DEEPSPEED"]
            self._n_gpu = 1
        else:
            self.distributed_state = PartialState(backend=self.xpu_backend)
            self._n_gpu = 1

the xpu_backend will be set properly if it's None (the default)

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

Merging as with https://github.com/huggingface/transformers/pull/23085 the default is still None so this is still a valid conditional


feature request - users want to customize mustache template

sometimes developers want to provide their customized mustache template they prefer but they don't wanna override the existing jhipster-lite src code. I hope there is a way for dev users to input the path to the customized template from the cli, for example, jhipster-lite-cli-command ... --override-mustache-template SecurityConfiguration.java.mustache=SOME_LOCAL_FILE_PATH.
if this is through API calls interaction:

need an API endpoint for GET request and return mutache template content
find a way to allow POST API to upload a customized mustache template (with a simply validation) to generate their code

This is a possibility provided by generator-jhipster -> see the full documentation at https://www.jhipster.tech/modules/creating-a-blueprint/
But in my opinion, this approach makes the generator-jhipster really complex, and hard to maintain, because it needed to be sync with generator-jhipster -> https://www.jhipster.tech/modules/official-blueprints/
Very few official blueprints are sync with v7.
In JHipster Lite, the approach is totally different, as you'll generate step by step only what you want.
I don't think providing this possibility you suggested, is the right direction for this project as it will bring a big complexity which is not necessary.
So your use case is to have your own SecurityConfiguration.java file, instead of the one provided by JHipster Lite. For that, you have different solutions:
Solution 1:

init project with JHipster Lite, add Maven, add Java Base
add Spring Boot, add Tomcat
instead of adding Security JWT, code it yourself, don't use the Security API to generate these files

If you're not happy with the provided files, it's easy to make the choice to not use the API.
Solution 2:

init project with JHipster Lite, add Maven, add Java Base
add Spring Boot, add Tomcat
add Security JWT, and edit the file you want, so edit your SecurityConfiguration with your own version

This solution is the best in my opinion, as it's quick.
Solution 3:

fork the project
create a new context and code the generation part your want, by using templates provided by JHipster Lite and your own templates
as it's in a new context, you won't have any conflict when rebasing against upstream main branch

Thank you @pascalgrimaud! I think I gave a bad example - should be "controller/service/repository". But Solution 3 is definitely a good option if we want to keep jhipster-lite simple - the only drawback is the forked new repo would need to keep updating by pulling from upstream whenever there is a new feature/version published from upstream. What I really mean is something like Shadowing in Gatsby Themes, however, again, at this moment and the early stage of LIte, we can ignore it for now.

@jhcao23 : another possibility is to publish jhipster-lite as a library, so you could use it as a Maven Dependency. You'll have all the template engine with mustache

yes, we are in a very early stage. We need to :

add more options
add at least 1 front framework
build a front, to call different APIs, instead of using Swagger

Then, we can add docs to help users to fork / use JHipster Lite as library, as the current structure / architecture of generator can still completely change

looking forward and willing to contribute whenever possible!


Allow executing external scripts on submitted data

e.g. an R script that does some transformation/cleaning each time before saving the data to the database.
The external command might look like: Rscript someWorkOnData.R input.json

The current idea is to do it on the frontend, after it fetches all the data.


Ignore whitespace when applying patch

I believe differing whitespace was causing the cmake project generation to fail on windows. They failed both on my machine and on my github CI, with the following error message:
  1>Checking Build System
  No update step for 'dawn-populate'
  Building Custom Rule C:/Dev/OpenGL/OpenGL/build/_deps/dawn-subbuild/CMakeLists.txt
  Performing patch step for 'dawn-populate'
CUSTOMBUILD : error : patch failed: tools/fetch_dawn_dependencies.py:88 [C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\dawn-populate.vcxproj]
CUSTOMBUILD : error : tools/fetch_dawn_dependencies.py: patch does not apply [C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\dawn-populate.vcxproj]
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for 'C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\CMakeFiles\129330622950a4e0f0da4883dd240834\dawn-populate-update.rule;C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\CMakeFiles\129330622950a4e0f0da4883dd240834\dawn-populate-patch.rule;C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\CMakeFiles\129330622950a4e0f0da4883dd240834\dawn-populate-configure.rule;C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\CMakeFiles\129330622950a4e0f0da4883dd240834\dawn-populate-build.rule;C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\CMakeFiles\129330622950a4e0f0da4883dd240834\dawn-populate-install.rule;C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\CMakeFiles\129330622950a4e0f0da4883dd240834\dawn-populate-test.rule;C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\CMakeFiles\313edad76fa1c357ee99429dc1a178af\dawn-populate-complete.rule;C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\CMakeFiles\944f518010a464a380ea8c00f25811c5\dawn-populate.rule;C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\CMakeLists.txt' exited with code 1. [C:\Dev\OpenGL\OpenGL\build\_deps\dawn-subbuild\dawn-populate.vcxproj]

CMake Error at C:/Program Files/CMake/share/cmake-3.30/Modules/FetchContent.cmake:1918 (message):
  Build step for dawn failed: 1
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.30/Modules/FetchContent.cmake:1609 (__FetchContent_populateSubbuild)
  C:/Program Files/CMake/share/cmake-3.30/Modules/FetchContent.cmake:2145:EVAL:2 (__FetchContent_doPopulation)
  C:/Program Files/CMake/share/cmake-3.30/Modules/FetchContent.cmake:2145 (cmake_language)
  C:/Program Files/CMake/share/cmake-3.30/Modules/FetchContent.cmake:1978:EVAL:1 (__FetchContent_Populate)
  C:/Program Files/CMake/share/cmake-3.30/Modules/FetchContent.cmake:1978 (cmake_language)
  OpenGL/build/_deps/webgpu-src/cmake/FetchDawn.cmake:51 (FetchContent_Populate)
  OpenGL/build/_deps/webgpu-src/CMakeLists.txt:27 (include)

-- Configuring incomplete, errors occurred!

I see that this repository has CI that verifies that it builds on windows, so I'm not sure why it failed for me but succeeded elsewhere. I wonder if it could somehow be a difference in git's autocrlf setting affecting line endings. Regardless, the change in this PR causes builds to succeed on windows, mac, and ubuntu for me.
By the way, you can probably tell that I've been reading your book haha. I wanted to say that I really appreciate you having written it. It's clear how much effort went into creating it and the associated repositories.

It is indeed probably related to the autocrlf, and I remember running into a similar issue in other project when using git apply in a patch command; I adopted the same fix at the time so you proposal is sound!

By the way, you can probably tell that I've been reading your book haha. I wanted to say that I really appreciate you having written it. It's clear how much effort went into creating it and the associated repositories.

Thanks a lot, I appreciate the feedback :) And thanks for taking the time to contribute back with all these PRs!


bpython: fix build

aeb63f40dd11157dc41f1f773abafe6f2666ac16 bumped bpython to 0.18, but it
failed to build afterwards, due to the .desktop file being renamed.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ x Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build python3.pkgs.bpython


Update Dataset type to support multilabel datasets

Currently, the Dataset abstract class only supports single-class datasets. This is because of the getY method defined here:
https://github.com/Kotlin/kotlindl/blob/master/dataset/src/jvmMain/kotlin/org/jetbrains/kotlinx/dl/dataset/Dataset.kt#L23
which only returns a single Float per index, instead of a FloatData.

@PatrickLaflamme Could you give a case when it could be useful for KotlinDL? Did you try to do some cases?


Add color customization to LifetimeTrackerDashboardIntegration

@krzysztofzablocki Whoops! Just finally getting around to your recommendation a few months later: https://github.com/krzysztofzablocki/LifetimeTracker/issues/76 ;)
Should I remove the "Update Pod configuration" commit so we just merge the color customization functionality? While I certainly need it to get the example app to build on my machine, I imagine it could just be a problem on my end and doesn't need to be merged to your codebase.

Yay! Thank YOU for merging so quickly 😄