No option to show method signatures in output (overloading)

Unless I just missed it, there seems to be no way to get async-profiler to emit method signatures in its output.  If there's a lot of method overloading going on or you're dealing with obfuscated code (e.g. Minecraft), then there's no way to distinguish some methods with the same names.

async-profiler currently prints signatures only in JFR output format (-o jfr).
I'll consider an option to dump signatures in other formats, too.

This would be amazing for a project I am profiling right now. Basically there are about 100 methods all named visit() with with different signatures for the different types to visit.

Here is a diff that adds the method signature to the stack traces:
diff --git a/src/frameName.cpp b/src/frameName.cpp
index b071afb..2ed01e6 100644
--- a/src/frameName.cpp
+++ b/src/frameName.cpp
@@ -56,18 +56,20 @@ char* FrameName::javaMethodName(jmethodID method) {
     jclass method_class;
     char* class_name = NULL;
     char* method_name = NULL;
+    char* signature = NULL;
     char* result;

     jvmtiEnv* jvmti = VM::jvmti();
     jvmtiError err;

-    if ((err = jvmti->GetMethodName(method, &method_name, NULL, NULL)) == 0 &&
+    if ((err = jvmti->GetMethodName(method, &method_name, &signature, NULL)) == 0 &&
         (err = jvmti->GetMethodDeclaringClass(method, &method_class)) == 0 &&
         (err = jvmti->GetClassSignature(method_class, &class_name, NULL)) == 0) {
         // Trim 'L' and ';' off the class descriptor like 'Ljava/lang/Object;'
         result = javaClassName(class_name + 1, strlen(class_name) - 2, _simple, _dotted);
         strcat(result, ".");
         strcat(result, method_name);
+        strcat(result, signature);
         if (_annotate) strcat(result, "_[j]");
     } else {
         snprintf(_buf, sizeof(_buf), "[jvmtiError %d]", err);
@@ -76,6 +78,7 @@ char* FrameName::javaMethodName(jmethodID method) {

     jvmti->Deallocate((unsigned char*)class_name);
     jvmti->Deallocate((unsigned char*)method_name);
+    jvmti->Deallocate((unsigned char*)signature);

     return result;
 }

Added -g option to print method signatures.
-agentpath equivalent of this option is sig.

This is awesome, thanks!


【TinyLLaVA-3.1B Inference】

Hello, I would like to know how to perform inference with TinyLLaVA-3.1B? Simply replacing the model_id in the script of tiny-llava-v1-hf with TinyLLaVA-3.1B results in an error: 'You are using a model of type tiny_llava_phi to instantiate a model of type llava. This is not supported for all configurations of models and can yield errors.

The tiny-llava-v1-hf is our legacy model and it is compatible with native huggingface, as the weights have been converted to the hf implementation. If you want to load the legacy model, you should check out our model card.
To use TinyLLaVA-3.1B, we have updated our readme file. The warnings can be ignored as they do not affect performance (they are hf integration warings).

Thank you very much! However, I encountered the following error during the inference. Do I need to compile the environment in TinyLLAVA?
[2024-02-24 12:46:22,640] [INFO] [real_accelerator.py:110:get_accelerator] Setting ds_accelerator to cuda (auto detect)
Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.
You are using a model of type siglip_vision_model to instantiate a model of type clip_vision_model. This is not supported for all configurations of models and can yield errors.
Traceback (most recent call last):
  File "/media/dell/data1/TinyLLaVABench/inference_tiny_llava.py", line 133, in <module>
    tokenizer, model, image_processor, context_len = load_pretrained_model(
  File "/media/dell/data1/TinyLLaVABench/tinyllava/model/builder.py", line 127, in load_pretrained_model
    model = TinyLlavaPhiForCausalLM.from_pretrained(model_path, low_cpu_mem_usage=True, **kwargs)
  File "/media/dell/data1/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/modeling_utils.py", line 3594, in from_pretrained
    no_split_modules = model._get_no_split_modules(device_map)
  File "/media/dell/data1/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/modeling_utils.py", line 1690, in _get_no_split_modules
    raise ValueError(
ValueError: TinyLlavaPhiForCausalLM does not support `device_map='auto'`. To implement support, the model class needs to implement the `_no_split_modules` attribute.

The tiny-llava-v1-hf is our legacy model and it is compatible with native huggingface, as the weights have been converted to the hf implementation. If you want to load the legacy model, you should check out our model card.
To use TinyLLaVA-3.1B, we have updated our readme file. The warnings can be ignored as they do not affect performance (they are hf integration warings).

Thank you very much! However, I encountered the following error during the inference. Do I need to compile the environment in TinyLLAVA?
[2024-02-24 12:46:22,640] [INFO] [real_accelerator.py:110:get_accelerator] Setting ds_accelerator to cuda (auto detect)
Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.
You are using a model of type siglip_vision_model to instantiate a model of type clip_vision_model. This is not supported for all configurations of models and can yield errors.
Traceback (most recent call last):
  File "/media/dell/data1/TinyLLaVABench/inference_tiny_llava.py", line 133, in <module>
    tokenizer, model, image_processor, context_len = load_pretrained_model(
  File "/media/dell/data1/TinyLLaVABench/tinyllava/model/builder.py", line 127, in load_pretrained_model
    model = TinyLlavaPhiForCausalLM.from_pretrained(model_path, low_cpu_mem_usage=True, **kwargs)
  File "/media/dell/data1/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/modeling_utils.py", line 3594, in from_pretrained
    no_split_modules = model._get_no_split_modules(device_map)
  File "/media/dell/data1/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/modeling_utils.py", line 1690, in _get_no_split_modules
    raise ValueError(
ValueError: TinyLlavaPhiForCausalLM does not support `device_map='auto'`. To implement support, the model class needs to implement the `_no_split_modules` attribute.

Sorry for the delay. We have updated on how to install relevant enviroments and packages here.❤

compile

Thanks for your timely reply. Another new error:
- This IS expected if you are initializing TinyLlavaPhiForCausalLM from the checkpoint of a model trained on another task or with another architecture (e.g. initializing a BertForSequenceClassification model from a BertForPreTraining model).
- This IS NOT expected if you are initializing TinyLlavaPhiForCausalLM from the checkpoint of a model that you expect to be exactly identical (initializing a BertForSequenceClassification model from a BertForSequenceClassification model).
Traceback (most recent call last):
  File "/media/dell/data1/TinyLLaVABench/predict_RS_img_background_generation_tiny_llava.py", line 133, in <module>
    tokenizer, model, image_processor, context_len = load_pretrained_model(
  File "/media/dell/data1/TinyLLaVABench/tinyllava/model/builder.py", line 145, in load_pretrained_model
    vision_tower.load_model()
  File "/media/dell/data1/TinyLLaVABench/tinyllava/model/multimodal_encoder/clip_encoder.py", line 25, in load_model
    self.image_processor = CLIPImageProcessor.from_pretrained(self.vision_tower_name)
  File "/media/dell/data1/miniconda3/envs/glamm/lib/python3.10/site-packages/transformers/image_processing_utils.py", line 206, in from_pretrained
    image_processor_dict, kwargs = cls.get_image_processor_dict(pretrained_model_name_or_path, **kwargs)
  File "/media/dell/data1/miniconda3/envs/glamm/lib/python3.10/site-packages/transformers/image_processing_utils.py", line 335, in get_image_processor_dict
    resolved_image_processor_file = cached_file(
  File "/media/dell/data1/miniconda3/envs/glamm/lib/python3.10/site-packages/transformers/utils/hub.py", line 356, in cached_file
    raise EnvironmentError(
OSError: /media/dell/data1/pretrain_weights/SigLIP does not appear to have a file named preprocessor_config.json. Checkout 'https://huggingface.co//media/dell/data1/pretrain_weights/SigLIP/main' for available files.

It seems the preprocessor_config.json is lacking in https://huggingface.co/bczhou/TinyLLaVA-3.1B-SigLIP/tree/main.

The tiny-llava-v1-hf is our legacy model and it is compatible with native huggingface, as the weights have been converted to the hf implementation. If you want to load the legacy model, you should check out our model card.
To use TinyLLaVA-3.1B, we have updated our readme file. The warnings can be ignored as they do not affect performance (they are hf integration warings).

Thank you very much! However, I encountered the following error during the inference. Do I need to compile the environment in TinyLLAVA?
[2024-02-24 12:46:22,640] [INFO] [real_accelerator.py:110:get_accelerator] Setting ds_accelerator to cuda (auto detect)
Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.
You are using a model of type siglip_vision_model to instantiate a model of type clip_vision_model. This is not supported for all configurations of models and can yield errors.
Traceback (most recent call last):
  File "/media/dell/data1/TinyLLaVABench/inference_tiny_llava.py", line 133, in <module>
    tokenizer, model, image_processor, context_len = load_pretrained_model(
  File "/media/dell/data1/TinyLLaVABench/tinyllava/model/builder.py", line 127, in load_pretrained_model
    model = TinyLlavaPhiForCausalLM.from_pretrained(model_path, low_cpu_mem_usage=True, **kwargs)
  File "/media/dell/data1/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/modeling_utils.py", line 3594, in from_pretrained
    no_split_modules = model._get_no_split_modules(device_map)
  File "/media/dell/data1/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/modeling_utils.py", line 1690, in _get_no_split_modules
    raise ValueError(
ValueError: TinyLlavaPhiForCausalLM does not support `device_map='auto'`. To implement support, the model class needs to implement the `_no_split_modules` attribute.

Sorry for the delay. We have updated on how to install relevant enviroments and packages here.❤

I suggest that you could post a link about SigLIP in your repo just like https://github.com/BAAI-DCAI/Bunny/blob/main/README.md#support-models to make it clearer. Thank you again for your promptness and patience.

The tiny-llava-v1-hf is our legacy model and it is compatible with native huggingface, as the weights have been converted to the hf implementation. If you want to load the legacy model, you should check out our model card.
To use TinyLLaVA-3.1B, we have updated our readme file. The warnings can be ignored as they do not affect performance (they are hf integration warings).

Thank you very much! However, I encountered the following error during the inference. Do I need to compile the environment in TinyLLAVA?
[2024-02-24 12:46:22,640] [INFO] [real_accelerator.py:110:get_accelerator] Setting ds_accelerator to cuda (auto detect)
Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.
You are using a model of type siglip_vision_model to instantiate a model of type clip_vision_model. This is not supported for all configurations of models and can yield errors.
Traceback (most recent call last):
  File "/media/dell/data1/TinyLLaVABench/inference_tiny_llava.py", line 133, in <module>
    tokenizer, model, image_processor, context_len = load_pretrained_model(
  File "/media/dell/data1/TinyLLaVABench/tinyllava/model/builder.py", line 127, in load_pretrained_model
    model = TinyLlavaPhiForCausalLM.from_pretrained(model_path, low_cpu_mem_usage=True, **kwargs)
  File "/media/dell/data1/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/modeling_utils.py", line 3594, in from_pretrained
    no_split_modules = model._get_no_split_modules(device_map)
  File "/media/dell/data1/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/modeling_utils.py", line 1690, in _get_no_split_modules
    raise ValueError(
ValueError: TinyLlavaPhiForCausalLM does not support `device_map='auto'`. To implement support, the model class needs to implement the `_no_split_modules` attribute.

It seems that the build_vision_tower function from tinyllava/model/multimodal_encoder/builder.py identifies the weight you provided as CLIPVisionTower and it is causing error. Try renaming the weights to ".../siglip", and it should be fixed.

compile

I recompile the environment under TinyLLAVA, and change the path of CLIPVisionTower from https://huggingface.co/bczhou/TinyLLaVA-3.1B-SigLIP to https://huggingface.co/google/siglip-so400m-patch14-384, then the inference is OK.

compile

I recompile the environment under TinyLLAVA, and change the path of CLIPVisionTower from https://huggingface.co/bczhou/TinyLLaVA-3.1B-SigLIP to https://huggingface.co/google/siglip-so400m-patch14-384, then the inference is OK 😄.

Could I directly use the https://huggingface.co/google/siglip-so400m-patch14-384? It seems that the visionCLIP part has been fine-tuned in the paper, but I can still get results that appear to be correct. @baichuanzhou

compile

I recompile the environment under TinyLLAVA, and change the path of CLIPVisionTower from https://huggingface.co/bczhou/TinyLLaVA-3.1B-SigLIP to https://huggingface.co/google/siglip-so400m-patch14-384, then the inference is OK 😄.

Could I directly use the https://huggingface.co/google/siglip-so400m-patch14-384? It seems that the visionCLIP part has been fine-tuned in the paper, but I can still get results that appear to be correct. @baichuanzhou
We found that it was the builder function from tinyllava/model/multimodal_encoder/builder.py that caused your error and fixed it. Our uploaded vision model was finetuned by us, and different from the google's version. So to get the results from the paper, you should use ours.

compile

I recompile the environment under TinyLLAVA, and change the path of CLIPVisionTower from https://huggingface.co/bczhou/TinyLLaVA-3.1B-SigLIP to https://huggingface.co/google/siglip-so400m-patch14-384, then the inference is OK 😄.

Could I directly use the https://huggingface.co/google/siglip-so400m-patch14-384? It seems that the visionCLIP part has been fine-tuned in the paper, but I can still get results that appear to be correct. @baichuanzhou

We found that it was the builder function from tinyllava/model/multimodal_encoder/builder.py that caused your error and fixed it. Our uploaded vision model was finetuned by us, and different from the google's version. So to get the results from the paper, you should use ours.

Thank you, it's working properly now.

compile

Thanks for your timely reply. Another new error:
- This IS expected if you are initializing TinyLlavaPhiForCausalLM from the checkpoint of a model trained on another task or with another architecture (e.g. initializing a BertForSequenceClassification model from a BertForPreTraining model).
- This IS NOT expected if you are initializing TinyLlavaPhiForCausalLM from the checkpoint of a model that you expect to be exactly identical (initializing a BertForSequenceClassification model from a BertForSequenceClassification model).
Traceback (most recent call last):
  File "/media/dell/data1/TinyLLaVABench/predict_RS_img_background_generation_tiny_llava.py", line 133, in <module>
    tokenizer, model, image_processor, context_len = load_pretrained_model(
  File "/media/dell/data1/TinyLLaVABench/tinyllava/model/builder.py", line 145, in load_pretrained_model
    vision_tower.load_model()
  File "/media/dell/data1/TinyLLaVABench/tinyllava/model/multimodal_encoder/clip_encoder.py", line 25, in load_model
    self.image_processor = CLIPImageProcessor.from_pretrained(self.vision_tower_name)
  File "/media/dell/data1/miniconda3/envs/glamm/lib/python3.10/site-packages/transformers/image_processing_utils.py", line 206, in from_pretrained
    image_processor_dict, kwargs = cls.get_image_processor_dict(pretrained_model_name_or_path, **kwargs)
  File "/media/dell/data1/miniconda3/envs/glamm/lib/python3.10/site-packages/transformers/image_processing_utils.py", line 335, in get_image_processor_dict
    resolved_image_processor_file = cached_file(
  File "/media/dell/data1/miniconda3/envs/glamm/lib/python3.10/site-packages/transformers/utils/hub.py", line 356, in cached_file
    raise EnvironmentError(
OSError: /media/dell/data1/pretrain_weights/SigLIP does not appear to have a file named preprocessor_config.json. Checkout 'https://huggingface.co//media/dell/data1/pretrain_weights/SigLIP/main' for available files.

It seems the preprocessor_config.json is lacking in https://huggingface.co/bczhou/TinyLLaVA-3.1B-SigLIP/tree/main.

same problem. How to solve it?

https://huggingface.co/bczhou/TinyLLaVA-3.1B-SigLIP

Using preprocessor_config.json from https://huggingface.co/bczhou/tiny-llava-v1-hf/blob/main/preprocessor_config.json, but the size not match. @baichuanzhou could you help to figure it out?

https://huggingface.co/bczhou/TinyLLaVA-3.1B-SigLIP

 Using preprocessor_config.json from https://huggingface.co/bczhou/tiny-llava-v1-hf/blob/main/preprocessor_config.json, but the size not match. @baichuanzhou could you help to figure it out?

Which model type are you using? tiny-llava-v1-hf is our legacy model and cannot be loaded with load_pretrained_model function. See its model card for how to run inference with it.

Inference as Run Inference example, and use files from https://huggingface.co/bczhou/TinyLLaVA-3.1B/tree/main, it reports
.


 The boost was missing, the cost was missing, and the death chance is way too high because of gorajan, which noone will consider risking. It's bad enough it bases magic defence on armadyl in OSRS haha.
Changes:

Replaces Hellfire bow boost
Adds the Hellfire arrow cost back
Reduces the Gear death chance by cutting the Max Magic Defence in half

For reference, Full karils, Amulet of Fury, Abyssal cape, and Hellfire bow, had 26% death chance, which is  the same as black d'hide top and bottom and nothing else in OSB. That death chance is way too high when you're using good gear and risking your Hellfire to a smite.

The change above brings the Full Karils set described down to 14.27% death chance, from 26%
Hellfire bow CAN be smited, costing the user a significant repair charge (1b cash + repair materials, ~ 1.3b total)
Locks Combatant's cape / Ranged master cape - Not necessary, but would otherwise cost 1b on EVERY death, not just smites, and that cost is just too high for anyone to bear.

Other checks:

[x] I have tested all my changes thoroughly.

Opinionated changes shouldn't be included like this in a PR thats just to fix a bug.

Opinionated changes shouldn't be included like this in a PR thats just to fix a bug.

Fair and fixed


use separate config.d file for xrootd >= 4.9.0 (SOFTWARE-3485)

@edquist there seem to be failures in the CI, could you take a look?

Yaaaaay!  Travis is happy now!


Query operation support for SQL Connector

Description:
Add support for below mentioned query operator for mysql and JDBC connectors.
public function query(@untainted string sqlQuery, typedesc<record {}>? rowType = ()) returns stream<record{}, sql:Error>;

Related to this -  https://github.com/ballerina-platform/ballerina-lang/issues/21407


feat(config): import Z-Wave Alliance Files batch 3

Batch 3 for volunteer review

I'll take a swing at this one.

@blhoward2 — you mind taking a look at my commits so far to ensure I'm on the right track with these?

Yeah, just remove it and change the min value.
Sent from my iPhone

On Feb 11, 2021, at 8:56 PM, Craig Lockwood<EMAIL_ADDRESS>wrote:

@1ockwood commented on this pull request.
In packages/config/config/devices/0x0086/zw141.json:

		}

	]

},

"121": {

	"label": "External Switch Mode For S2",

	"valueSize": 1,

	"minValue": 0,

	"maxValue": 4,

	"defaultValue": 0,

	"unsigned": true,

	"readOnly": false,

	"writeOnly": false,

	"allowManualEntry": false,

	"options": [

		{

			"label": "Unidentified mode",

The manual doesn't explain in any detail what it is, and I can't find any other resources explaining it further. Should I go ahead and remove it? This is from the manual:
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@blhoward2 — FYI, I've now gone over all the files, so should be ready for review.

and @blhoward2 you wanted to split one param into partials - I think that didn't happen yet.

Yeah I had a question for you on that. I thought it was a partial param based on a manual I looked at but that is a newer model with very different options and values. This one doesn't purport to be a partial param in the description but the values and default value don't make sense to me. Thoughts on that one?


Why do i keep getting this error :(

when running my code in the broswer i get this error malformed header from script 'index.py': Bad header: Deleting original file Young T, referer: http://myserver.dev/
Help anyone?

Carefully read new issue template and provide all requested information.


User Defined Metrics example

Fixes #239
@shreyasbapat
@ritzvik

Is this symbolic?

@shreyasbapat I did import the symbolic module for the various pre-defined metrics (einsteinpy.symbolic) . Could that be the issue? If yes, then what is the approach to be made?

I am sorry for the delayed response. The issue was not for symbolic module :(
The issue was intended for the use of metric module.


Search doesn't trigger any request

In both Firefox and Vivaldi, entering a common keyword such as contract and pressing Enter doesn't return any search result.
The console tab reports the following error upon page load:
Uncaught TypeError: marked is not a function
    fields https://open-contracting.github.io/editor-tools/js/main.js:25
    fields https://open-contracting.github.io/editor-tools/js/main.js:56
    fields https://open-contracting.github.io/editor-tools/js/main.js:56
    fields https://open-contracting.github.io/editor-tools/js/main.js:56
    fields https://open-contracting.github.io/editor-tools/js/main.js:56
    transform https://open-contracting.github.io/editor-tools/js/main.js:92
    onResponse https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:628
    jQuery 6
    fromNetwork https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:623
    loadPrefetch https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:876
    initialize https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:891
    initialize https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:898
    Bloodhound https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:849
    <anonymous> https://open-contracting.github.io/editor-tools/js/main.js:62
main.js:25:53
    fields https://open-contracting.github.io/editor-tools/js/main.js:25
    fields https://open-contracting.github.io/editor-tools/js/main.js:56
    fields https://open-contracting.github.io/editor-tools/js/main.js:56
    fields https://open-contracting.github.io/editor-tools/js/main.js:56
    fields https://open-contracting.github.io/editor-tools/js/main.js:56
    transform https://open-contracting.github.io/editor-tools/js/main.js:92
    onResponse https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:628
    jQuery 6
    fromNetwork https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:623
    loadPrefetch https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:876
    initialize https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:891
    initialize https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:898
    Bloodhound https://open-contracting.github.io/editor-tools/js/vendor/typeahead.bundle.js:849
    <anonymous> https://open-contracting.github.io/editor-tools/js/main.js:62

The network tab of the developer tools indicates no request is fired when search terms are entered.

This bug is back, identical.

Marked v4 broke the tool. I've frozen to Marked v3. Thanks for reporting!


Changed to ReactDOM, and added Navigation example

A few changes to the docs:

Changed to using ReactDOM.render() as in 0.14 that is changing
Added a transitionTo  / mixin example
Added a History example - I wasn't able to find any docs on this but fished it out of an issue.

Hold off on this for a bit - need to fulling migrate my app over - I think I'm not using transitionTo properly in 1.0

Okay - here are some updates to the Docs

@wesbos could I ask you to send another PR but for the new-docs branch? I'm working on the new docs there. Thanks!

Yeep. Would you prefer separate commits in the future? I think I might have a few more things here and there.

@wesbos I don't mind


Add tests for message actions.

First part of #1055
Added new tests for doNarrow thunk

rebased

updated

rebased

Looks good!


Feature request: backgroud RSS updation

Update operation is block UI. Could you please make background update process.

Hi,
First of all: Newsbeuter is abandoned, but I maintain a fork called Newsboat.
As for your request: updating doesn't block UI for me. Perhaps I misunderstand what you mean by "block"? I just checked, and after I press R to reload all thread, I can still jump between feeds with n, open them with Enter and even read articles. Does your Newsbeuter behave differently?
If you can reproduce the problem with Newsboat, please open an issue there, and let's figure out what's going on.

Ah, sorry, you probably meant updating a single feed (r by default). This indeed blocks the UI. Just saw this while testing something else. I've opened a Newsboat issue for that; thanks for reporting!


Switch from archive based install to git clone based install

Problem

Frequent upstream upgrades, that require minimal package updates, while a built-in full upgrade solution exists. + many users want to be able to switch to dev branch

Solution

Rework of the scripts, install is now made with git clone rather than fetching a *.tar.gz archive, updates are made daily (cron job) using the built-in script (util/udall) An option is added to swith to dev branch in the app's config panel in YunoHost admin.

PR Status

[x] Code finished and ready to be reviewed/tested
[x] The fix/enhancement were manually tested (if applicable)

Automatic tests
Automatic tests can be triggered on https://ci-apps-dev.yunohost.org/ after creating the PR, by commenting "!testme", "!gogogadgetoci" or "By the power of systemd, I invoke The Great App CI to test this Pull Request!". (N.B. : for this to work you need to be a member of the Yunohost-Apps organization)

!testme ...
... And sorry for the ridiculous number of commits!


[in_app_purchase] iOS SKError code is not sent to the client

An in_app_purchase error on iOS is modeled by class SKError which has the following required fields:
  /// Error [code](https://developer.apple.com/documentation/foundation/1448136-nserror_codes)
  /// as defined in the Cocoa Framework.
  final int code;

  /// Error
  /// [domain](https://developer.apple.com/documentation/foundation/nscocoaerrordomain?language=objc)
  /// as defined in the Cocoa Framework.
  final String domain;

  /// A map that contains more detailed information about the error.
  ///
  /// Any key of the map must be a valid [NSErrorUserInfoKey](https://developer.apple.com/documentation/foundation/nserroruserinfokey?language=objc).
  final Map<String, dynamic> userInfo;

When reporting an error back to the client, this class is converted into IAPError, but only the fields domain and userInfo are included, while the field code is omitted:
    purchaseUpdatedController
        .add(transactions.map((SKPaymentTransactionWrapper transaction) {
      PurchaseDetails purchaseDetails =
          PurchaseDetails.fromSKTransaction(transaction, receiptData)
            ..status = SKTransactionStatusConverter()
                .toPurchaseStatus(transaction.transactionState)
            ..error = transaction.error != null
                ? IAPError(
                    source: IAPSource.AppStore,
                    code: kPurchaseErrorCode,
                    message: transaction.error.domain,
                    details: transaction.error.userInfo,
                  )
                : null;
      return purchaseDetails;
    }).toList());

As a result, it is impossible to determine for example if the purchase was canceled by the user (code = SKErrorPaymentCancelled) or failed for another reason.

Any update?
Why is this plugin neglected? :(

This is an error on the Apple side, not particular to this plugin:
https://forums.developer.apple.com/thread/128301
https://forums.developer.apple.com/thread/98763

I don't think those linked issues are related. This issue is about getting the details of the error, not about whether the platform is passing back the right error code.
Looks to me like the IAPError uses kPurchaseErrorCode because it is platform independent. The specific, and platform dependent, error codes are available from purchaseDetails.skPaymentTransaction.error.code on iOS. Still looking for the Android equivalent but it would be under the purchaseDetails.billingClientPurchase property. It looks to me like this is an intentional choice of the plugin designers to currently surface a platform independent error.

On iOS platform PurchaseDetails object has a field called: skPaymentTransaction which has a SKError object. Then you can access error code from this object.


[PTRun] Run preview

Add a Preview Panel to the Run Plugin
Closes microsoft/PowerToys#34273.
Has been implemented for discussion on its usefulness and feedback  gathering.

Just want to note this would be perfect for creators and editors alike. Especially if this uses existing thumbnails so software like Adobe Bridge or Honeyview can generate previews from other filetypes.


camelCase support for cssLoaderOptions

@thekevinscott  has done a wonderful job with pull request #16
However, there doesn't seem to be support for camelCase option of css-loader.
Would support for this be added soon?
Problem:
Everything works fine for one-worded classnames like 'navbar', 'column', 'sticky' etc. However, for class names like 'navbar-bg', 'column-12', 'sticky-top' has an empty string. (ie class in the HTML instead of something like class="23Tbhqewpe_54Yu"
Expected behaviour:
classnames like navbar-bg gets transformed to navbarBg (or their hashes)
I am a newbie, so could you help me with any other workaround to camelCasing for legacy css (for eg: foundation framework)?

It's not released yet.

@timneutkens Thanks for letting me know.
Do you have a rough estimate of the date for next release ? :smiley:


Single Product eCommerce Website with Email Checkout in PHP

Proposed title of the article
Single Product eCommerce Website with Email Checkout in PHP
Proposed article introduction
It takes a lot of passion to provide an online eCommerce solution. It allows you to meet a diverse range of consumers with differing degrees of requirements.
 It is possible to integrate an eCommerce system into an application that promotes a single product.
Key takeaways

Benefits of a custom eCommerce website
Buy now and Checkout controls on a single product UI
AJAX checkout and jQuery form validation
eCommerce checkout via email PHP code flow
Final product: a single-product e-commerce site

Article quality
This article is brief and straightforward to make the viewers easily interpret and understand. similar articles providing similar content are long and tedious to read
References
N/A

I'm going to close this topic due to inactivity.
It can be reopened.


First pass at Shallow Gravy support

This should now theoretically support both Shallow Gravy and 3.8.x.
There were two main avenues for porting to the new filesystem layout.
First I parameterized $codedir and $confdir where I reasonably
could, so that if there are changes in the future, it should be
relatively easy to port. Second, I wrote a classroom::compatibility
shim class that drops in some janky symlinks so that legacy PE
filesystem layouts will work unchanged with the new layout. This means
that when it comes time to drop 3.x support, we just drop the shim.
This isn't 100% parameterized, because some of the paths exist in static
files, but the paths that would need corrected only exist in three
files:

files/pre-commit
files/process_reports.rb
files/sudoers.classroom

I ended up conflating a lot of overall cleanups and code refactoring
into this, simply because I was touching the same lines of code and I
didn't want to write and rewrite the code multiple times.
I should also note that this isn't truly complete, as the pltraining/rbac
and other modules may need updated.

No. Because I'm ensuring that it can never be called on it's own, we can assume that the classroom class has been included, so its variables are in the catalog.

I'm trying to slowly migrate it back towards best practices instead of overly clever.


Configuration via System.config

To have a good modularization in our project we currently add our project root directory to the includePaths property of the sass compiler options.
This way we can place a variables and mixins file in a specific place in our app and import it in all submodules relative to the project root.
I would like to switch from our gulp based transpile-and-copy workflow to your plugin. For the above to work I would need to pass some options to the sass compiler in your plugin. Would this be possible to integrate?

I don't know if this is possible. The only thing I know is that you can import plugins with a ! like import 'some/data.json!';. But how you can pass arguments to that is a thing I don't know. You should open a new issue at SystemJS and reference to this issue here. Maybe Guy Bedford know a solution for that.

I think it should be possible as plugin-typescript does the same thing with its System.config.typescriptOptions.

Ok I can see it. What options would you like to see in the config settings? I am thinking about to add something like this to my config.js:
System.config({
  sassOptions: {
  }
});

+1 for sassOptions.    Would a PR that implements sassOptions be helpful?

I spent a little time with this tonight and have some questions about injecting Sass at runtime.  (I haven't had a chance to look at bundling yet.)
I could get plugin-sass to preload imported files with lazyFiles, but since the file load takes place in the browser, it has the drawback of having to provide a complete manifest of every file that might be imported.  (Globbing isn't possible over HTTP out of the box.)
I'm considering amending the import override to look at the directories specified in the includePaths, but I'm fearful this will have nasty performance consequences.  This also doesn't fully resolve the above complete manifest issue as all subdirectories will also have to be explicitly listed.
I suppose the files could be globbed in a Gulp task and added to a special collection in the configuration, but that also feels improper to me.
I'm a bit at a loss as which option is best.  I also feel like there must be a better, simpler way of accomplishing this without a precompile.
Thoughts?

@screendriver Are you actively working on this? Would a PR that implements sassOptions be helpful?

The next features I am working on is to optionally disable autoprefixer and include sassOptions in a configuration file.
I am not experienced enough to use lazyFiles. I am using the loading mechanism of SystemJS. So I don't know if it's working what you trying to use. But Sass injection at runtime (sass-inject) is only meant for development time. For production you have to use the bundling mechanism from jspm. At bundling time all transpiled SASS files will directly included in your bundle.js file so there is no need for lazyFiles.

@screendriver I think I should have been more clear about the use case I was trying to address.  I wanted to use sass-plugin at runtime for development, but could not as some of the resources required to compile the sass sheet were located outside of the project.
As I understand it (and it is completely possible I'm wrong), sass-inject is run entirely in the browser, and as such, the referenced paths for local files in this situation will not work.  To address that, the file listing would need to be to valid HTTP endpoints.  Since HTTP doesn't support globbing, I don't think you could get away with specifying a base path only and hoping the child paths resolve.  This means that you'd end up specifying every valid sheet and partial URI path in includePaths.  While technically valid, it's not very pretty, and can (and probably will) lead to maintainability problems.  Furthermore, those endpoints would have to be available at bundle-time, and there's no guarantee they will be.
As I read @frederikschubert's original post, I took it as wanting to use plugin-sass at development time as well as production bundling, and after reading your comments, I'm beginning to think that maybe I misunderstood the original intent.  Won't using sass-builder and the JSPM bundler lead to the problems that @frederikschubert was trying to avoid, specifically the "gulp based transpile-and-copy workflow" at development time?

Done. Please let me know if anything is missing or not working.
@rosshinkley for SystemJS you don't need Gulp tasks that concat / minify and uglify your code. Everything is already there and shipped with jspm.


docs: ✏ Fix broken logo image in storybook (top left)

Fix broken logo image in storybook (top left)
✅ Closes: #262
The below structure change seems to fix it, not sure why ¯_(ツ)_/¯

I did find some still open issues on storybook's github about theming cache issues, see https://github.com/storybookjs/storybook/issues/13200
Adding the following seemed to clear it out and let me see the fixed logo. I didn't want to commit it since I don't really know what it might impact for a logo fix (low value) but something to try if you can't get theme changes to show in your local version.

From the docs:

NOTE: The flag --no-manager-cache disables the internal caching of Storybook and can serverely impact your Storybook loading time, so only use it when you need to refresh Storybook's UI, such as when editing themes.
https://storybook.js.org/docs/react/api/cli-options

So it's probably a good move not to commit that haha


Rename long cirrus job names

Basically, add a 'name' tag (remote, local) to each incantation
of TEST_REMOTE_CLIENT: true/false
I have no idea if this will work or what results it'll produce.
Signed-off-by: Ed Santiago<EMAIL_ADDRESS>

Looks promising so far:
- testing TEST_REMOTE_CLIENT:true image:fedora-31-libpod-594030756...
+ testing image:fedora-31-libpod-5940307564953600 name:remote

I had hoped it would chop off the name:, but that's only 5 characters, and overall this gives us 11 characters max vs 24.
Cirrus is throttling me because of too-quickly-repeated jobs; I'll wait a while before retrying.

@cevich PTAL. I tried everything I could think of; there doesn't seem to be a way to get rid of the -libpod-123456789 suffix. IMHO this is still good enough as it is.

...found it in containers/storage configuration.  Example of what it looks like (using Cirrus WebUI for convenience):  https://cirrus-ci.com/build/6574673093722112
Point is, the variable name possibly doesn't need to be so verbose.  For instance $FEDORA_CACHE_IMAGE_NAME -> $FIMG1 and $PRIOR_FEDORA_CACHE_IMAGE_NAME -> $FIMG2 (or whatever is short and makes sense).
Though I'm seeing image: fully-spelled-out-name-122343455667 appear as well.  Not sure if that affects...where are you trying to use the unique (human readable) task name from?

I'm not sure we're talking about the same thing. For the first part of this PR (TEST_REMOTE_CLIENT), a shorter variable name would help, but I think this approach is better. For the second part, I don't think variable names come into play at all. I was just trying to get rid of the useless libpod-XXXXXXX garbage that gets displayed on github results. Unfortunately I can't find any way to do so.

Filed https://github.com/cirruslabs/cirrus-ci-docs/issues/589 in hopes of getting a way to display user-provided names

OMG everybody look at how nice and readable those CI job names are!

sweet!

LGTM

/approve

/hold
@cevich are you responsible for podbot? If so can you check if there's some unwelcome interaction between this PR and podbot?
The short version is: this PR took a lot of retries to get to pass. There were two jobs flaking over and over again: fedora-30 remote and local. Eventually, one of those finally passed. When it did, podbot pinged me (twice!) on #podman :
13:55:18 <podbot_50205371> edsantiago: Cirrus-CI testing successful for PR 'Rename long cirrus job names': https://github.com/containers/libpod/pull/5387
13:56:11 <podbot_56650334> edsantiago: Cirrus-CI testing successful for PR 'Rename long cirrus job names': https://github.com/containers/libpod/pull/5387

Two different podbots, almost a minute apart. But it was a lie: my job had not finished. The second job was still running; it finally passed about ten minutes later (and there was no corresponding podbot message on IRC).

More info: doesn't look like my PR's fault. I just saw podbot spit out five identical messages for one unrelated PR:
20:48:33 <podbot_65422381> sgrunert: Cirrus-CI testing successful for PR 'Fix podman image sign help output': https://github.com/containers/libpod/pull/5389
20:48:33 <podbot_49421838> sgrunert: Cirrus-CI testing successful for PR 'Fix podman image sign help output': https://github.com/containers/libpod/pull/5389
20:48:33 <podbot_59304614> sgrunert: Cirrus-CI testing successful for PR 'Fix podman image sign help output': https://github.com/containers/libpod/pull/5389
20:48:33 <podbot_56459706> sgrunert: Cirrus-CI testing successful for PR 'Fix podman image sign help output': https://github.com/containers/libpod/pull/5389
20:48:38 <podbot_53830764> sgrunert: Cirrus-CI testing successful for PR 'Fix podman image sign help output': https://github.com/containers/libpod/pull/5389

The PR in question is green, but I wasn't paying close enough attention to check if it went green before those messages or after.

When it did, podbot pinged me (twice!) on #podman

Those notices come from the success_task script.  It's possible for there to be multiple executions of the success task at the same time.  I believe this is caused by a combination of multiple side-effects involving dependent tasks.  I debugged it fully once, but couldn't find a simple way to guarantee only once notice is sent per sha.
This is another thing we could move into post-cirrus automation, where we can have more guarantees about the actual completion-state of the overall build.

doesn't look like my PR's fault.

Not I highly doubt it's anything you did.

Thanks. I've seen some weird podbot messages the past 24 hours, and I concur.
/hold cancel

@edsantiago this is really really fantastic, thank you again for helping with these things.  The name length was a loud complaint I heard frequently during initial implementation, but (at the time) was impossible to fix.
One minor suggestion in addition to my comments above:  Consider if we could just drop the term 'testing' entirely from the displayed names.  Everybody here knows / assumes most/all activities here are about or for "testing".  Might help get the names even shorter :grinning:
In any case, this is a vast improvement as-is and I think the results speak for themselves.
LGTM as-is after fixing up contrib/cirrus/cirrus_yaml_test.py, it's fine if you prefer to do followup PRs for my other suggestions.

Consider if we could just drop the term 'testing' entirely from the displayed names

I shortened ti to test. I'd like to keep some common prefix, because Cirrus/Github sorts results. A common prefix helps cluster everything in testing_task together, making it easier IMO for the eye to pick up common success/failure elements.
I would like to explore further renaming of tasks, but believe a followup PR would be better.
Thanks for your feedback! That was helpful; Fixes, cleanup, and rebase coming soon.

okay, follow-up PRs are perfectly fine by me, let's get this in quick so everyone can benefit as-is...

/lgtm


Bitcoin balance shows 0 because of connection issue

I see users reporting that the Bitcoin balance is not loading, this is reported quite often, every week I would say.

Here is an example with this error in the console:

The user reporting the above was able to resolve it by switching on their VPN. So I assume localization restrictions played a role.

Another user reported it resolved by switching from "socks4" proxy to "socks5", alternative VPN connection. Again I assume a localization issue was causing the connection error in the first place. They didn't share their location or console logs. Notice that bitcoin transaction data is shown but the balance is not (due to different API endpoints, I assume).

Is this related @markmhx https://github.com/hirosystems/wallet/issues/3872 I think this should have a higher priority, P3. Users are left confused or think they lost funds.

A user encountering this issue (Bitcoin balance not showing) can check connection issues by opening the console, to do  that follow these steps:

Open the wallet in a tab, do this via the top right menu (three dots) and then click "Open in new tab"
Then in that tab with the wallet press Ctrl+Shift+I, and click the "console" tab.

If you see any errors you can also paste a screenshot here.
Then to workaround the problem, try turning off any blockers you have installed or switch on a VPN, if you already have a VPN on, try switching to an IP address from a different location.

So I assume localization restrictions played a role.

Is Blockstream blocking certain regions, and are we still getting reports of this?


Implement subpages for Creation/Deletion section

The Creation and Deletion section has several commands such as touch, mkdir, etc. Place the information for each command on a separate subpage and implement the progress bar so that it indicates which subpage the user is on.

Triaged for now. Either close or leave open for a future version.


Use blob storage for indexedDB (#42)

Fixes #42
Now capacitor-blob-writer stores actuals blobs in IndexedDB on the web platform, instead of converting them to base64 strings. Also write_blob function returns a valid URL for the web environment (now the README example actually works in a browser).
All the tests in the demo app have passed unchanged (tested web only):
starting tests
wrote 10 bytes in 76ms
wrote 10 bytes in 18ms
wrote 10 bytes in 9ms
wrote 10 bytes in 22ms
wrote 10 bytes in 14ms
wrote 10 bytes in 15ms
wrote 10 bytes in 25ms
wrote 10 bytes in 32ms
wrote 10 bytes in 41ms
wrote 5242880 bytes in 19ms
tests passed!

Docs and benchmarks have been updated accordingly. The performance gains are quite impressive! It even managed to save a 512 MB file!

Size
Filesystem
BlobWriter

1 kilobyte
4ms
9ms

1 megabyte
180ms
16ms

8 megabytes
1.5s
43ms

32 megabytes
5.2s
141ms

64 megabytes
10.5s
0.2s

512 megabytes
Error[3]
1.1s

This implementation does not remove the previous one, but uses it as a fallback. You might consider removing Filesystem.appendFile version entirely since blobs in IDB are widely supported now (in chrome since 2014). Anyway, this decision is up to you.
Also this might be considered a breaking change since Filesystem.readFile now returns a blob instead of a string. So, the package should be versioned appropriately.

What happens when you run, say,
let img = document.createElement("img");
Filesystem.getUri({path}).then(function (result) {
    img.src = Capacitor.convertFileSrc(result.uri);
});

Does it work?

@diachedelic It will do exactly what it did before the PR. Meaning, it doesn't work. It returns the path from a fake file system, which browser does not understand. This is ultimately a Capacitor.Filesystem's issue.
It is possible to make it work with the new implementation. But we need to modify convertFileSrc or getUri implementation. Maybe something like that:
import { convertFileSrc } from "capacitor-blob-writer";

let img = document.createElement("img");
Filesystem.getUri({path}).then(function (result) {
    img.src = convertFileSrc(result.uri);
});

To implement this we need a way to tell if we are dealing with a blob file without reading it. Because now it looks exactly like a normal file. I guess we could add an extra property or mess around with filetype prop. Which one is better depends on the stat implementation which I haven't look into yet.
To summarize, although the behavior is broken, this PR does not affect it.

Is it even possible to get a URL to a Blob in IndexedDB without using URL.createObjectURL?

That is to say, a URL which could be set as img.src?

Is it even possible to get a URL to a Blob in IndexedDB without using URL.createObjectURL?

I don't think so. This is exactly what URL.createObjectURL was created for. You do not have any URLs in indexedDB. It's just a database.

What I think might work:
function convertFileSrc({path}) {
const { type } = Filesystem.stat({path});
if (type == "blob") {
  const { data } = Filesystem.readFile({path});
  return URL.createObjectURL(data);
} else {
  return Filesystem. convertFileSrc(path);
}

Where we set type = "blob" in advance.

Thanks. I think it makes sense for the application developer to keep track of whether they are storing files as strings or Blobs. Blobs on the web platform can be accessed via Filesystem.readFile and then turned into a URL via URL.createObjectURL, in place of Filesystem.getUri and Capacitor.convertFileSrc on native platforms.
I am now just thinking about the breakage.

I think you should just semantically version it as 2.0.0 to avoid breaking changes upon update. Developers who want the new features and performance improvements will be able to opt in by manually updating.

What I think might work:
function convertFileSrc({path}) {
  const { type } = Filesystem.stat({path});
  if (type == "blob") {
    const { data } = Filesystem.readFile({path});
    return URL.createObjectURL(data);
  } else {
    return Filesystem.convertFileSrc(path);
  }
}

Where we set type = "blob" in advance.

If you think this is a good idea, I might try to properly implement this as a QOL feature. So we won't put it off completely on the developers.

The plugin's interface is currently very simple, it is just a single function. I would prefer not to complicate it with an alternative convertFileSrc.

I don't see it a much of a complication since we will still have the function as a default export, meanwhile adding an option for a url converter for those who needs it. I may even be called something like convertBlobSrc to not confuse it with the original implementation.
import writeBlob, { convertBlobSrc } from "capacitor-write-blob";

Since the second import is completely optional I don't see how it would complicate the interface.

Thanks. I think it makes sense for the application developer to keep track of whether they are storing files as strings or Blobs. Blobs on the web platform can be accessed via Filesystem.readFile and then turned into a URL via URL.createObjectURL, in place of Filesystem.getUri and Capacitor.convertFileSrc on native platforms.
I am now just thinking about the breakage.

Actually I think this is a good idea to switch implementation depending on a platform. This actually brings even more incentive to put the utility function into the library. Personally, I as an application developer prefer all system-specific functionality to be hidden away.
That said, given this change we would really want to remove "appendFile" fallback to avoid any incompatibility. As I said before it shouldn't cause any issues.

The problem with URL.createObjectURL is that it requires a complementary URL.revokeObjectURL to avoid memory leaks. Memory leaks can very quickly result in termination of the WebView on iOS, which is really hard to debug.
If we build URL.createObjectURL into the plugin, I don't see how we can also build in URL.revokeObjectURL. That's why I'd prefer to leave it up to the application developer. They will know when they don't need the URL anymore.

You are right about removing fallback mode for the web platform.

Yeah, I was also concerned about URL.revokeObjectURL... I guess the best we can do is to document it, so the developers know they should use it. I added a note for that in the readme, not sure if that's enough though.
I get your point why you want leave that up to developers. But what about the URL.createObjectURL returned from write_blob function? Do you think it's fine there?

I am thinking that write_blob should no longer produce a URI.

I am thinking that write_blob should no longer produce a URI.

I think it makes sense, since a user already has an access to a blob they write. So they do URL.createObjectURL themselves.

So, @diachedelic, are you going to merge this or you still considering something?

@diachedelic, I've implemented the requested changes.

Thanks. Nice doing business with you!

This feature is available in v1.1.0. I realised that we could make the behaviour opt-in, thereby avoiding breakage.


Setup failed for custom integration openhasp

Hi
I have just upgraded to HA Operating System 10.2 (from 10.1) and HA started I get:
Logger: homeassistant.setup
Source: setup.py:214
First occurred: 9:04:20 AM (1 occurrences)
Last logged: 9:04:20 AM

Setup failed for custom integration openhasp: Unable to import component: Exception importing custom_components.openhasp

I cannot restart HA as it fails the config check:
Logger: homeassistant.components.websocket_api.http.connection
Source: components/hassio/__init__.py:563
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 9:07:06 AM (1 occurrences)
Last logged: 9:07:06 AM

[140586943335056] The system cannot restart because the configuration is not valid: Component error: openhasp - Exception importing custom_components.openhasp
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 199, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1849, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1889, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/components/hassio/__init__.py", line 563, in async_handle_core_service
    raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: The system cannot restart because the configuration is not valid: Component error: openhasp - Exception importing custom_components.openhasp

How do I go about fault finding this?
I have disabled openHASP in the integrations, but this hasn't helped.
Appreciate any pointers!!

Problem also here:
after HA 10.2 update, the openHASP integration (0.7.0) do not discover anymore my openHasp device (WT32-SC01 - V.0.6.3)...
Do you have any solutions ?

Do you have any solutions ?

Update the device to v0.7.0 or downgrade the integration to 0.6.6... Both need to be on the same version level.

If I have disabled openHASP, can I safely ignore the config check and force a HA restart?

It seems you have a yaml error in openhasp.yaml. The Custom Component works fine with HA 10.2 here.

We added a Pre-Release 0.7.2 with support for HA 2024.1. Please help test it before release by redownloading this version of the Custom Component in HACS.


I suggest you to improve the CSS of issues tabs and buttons and icons of watch, unstar and fork

Hello @talaub,
Guten Tag!
Here is the screenshot:

Others:


Support for EdDSA Algorithm

It looks like this is one of the new algorithms, and is listed on jwt.io. It's the only thing on there that you don't support. Keep it up!

It is supported in master code now.

https://docs.authlib.org/en/latest/specs/rfc8037.html


Refreshing template in Vit (Question)

Hi,
I want to ask you about template refreshing in VitTracker.
I see in Python code the method self. model. update(image) it looks like there is no update template (always first template), On the other hand, I see when I run some video examples that the tracker "Jump" to another object that is different from the original template and continues with this object.
So there is some template udate logic that you implement in your code?
and if Yes how I can control this updated template?

You can try to call self.model.init again with tracking results to set template.

Thank you for your comment, So if I understand from your answer there is no template refreshing that you do in the code? (I can do this manually using init method)
When I look at the documentation of Vit in OpenCV, for example, I see that the update method gets to frame and cv::Rect bb so what is the difference? in cpp you update the bb with the method or only use the init bb?

there is no template refreshing

If init() does not count, yes.

so what is the difference? in cpp you update the bb with the method or only use the init bb?

I do not get your question well but if I am not mis-understanding, you are asking the meaning of the second parameter in update(frame, bbox), right? It serves as the return output. See code here for more details:
https://github.com/opencv/opencv/blob/43c1c81c8c70955e3059637a7f0a099ccd2533b4/modules/video/src/tracking/tracker_vit.cpp#L170-L203
Note that although the template is not refreshed in update() but the target bbox does get updated (see line 200).

You may try refreshing template to see whether you get a better tracking result that does not make the jump.


[FLINK-2946] Add orderBy() to Table API

Thanks for contributing to Apache Flink. Before you open your pull request, please take the following check list into consideration.
If your changes take all of the items into account, feel free to open your pull request. For more information and/or questions please refer to the How To Contribute guide.
In addition to going through the list, please provide a meaningful description of your changes.

[ ] General

The pull request references the related JIRA issue
The pull request addresses only one issue
Each commit in the PR has a meaningful commit message

[ ] Documentation

Documentation has been added for new functionality
Old documentation affected by the pull request has been updated
JavaDoc for public methods has been added

[ ] Tests & Build

Functionality added by the pull request is covered by tests
mvn clean verify has been executed successfully locally or a Travis build has passed

Thanks for opening this PR @dawidwys!
I skimmed over the changes and it looks good. I will do a more detailed review hopefully soon.
Thanks also for adding a lot of tests. It is definitely good to have extensive test coverage, but end-to-end tests such as yours add quite a bit to the build time. Flink uses Travis as CI service which kills builds after 2h. Unfortunately, we are experiencing build time outs already and have to be careful when adding tests.
I would like to ask you to remove some of the tests which check for different expression syntax but end up in identical executions. In addition, it would be good to add one SQL test that executes a query which sorts on two fields to have the SQL part covered.
We will add a unit test framework, that checks for correct parsing of the expressions without actually executing queries in a separate effort.

Always glad to help! In fact I would be happy for any suggestions what can I work on further.
I changed the tests.

Thanks for the PR @dawidwys. I had a few comments. Please let me know if you have any questions.
Regarding a follow task, we have several open issue to extend / improve the Table API. For instance, you could add support for outer joins. That should not be too hard, because the DataSet API supports them natively. Alternatively, we will soon have an interface to define external tables and there will be issues to implement the interface for different storage systems (HBase, ...) or formats (Parquet, ...).

I tried to address all your comments. Unfortunately I didn't notice lines longer than 100 yesterday, sorry for that.
I started working on outer joins, but unfortunately I could not find an appropriate jira, so I would be grateful if you could point me to such. Afterwards I will happily work on introducing storages.

Hi @dawidwys, thanks for the fast update. I'll have a look at the PR tomorrow.
The JIRA for Table API outer joins is FLINK-2971. I'll assign it to you. Thanks!

Thanks for the update @dawidwys. PR looks good except for a few minor comments.
Can you also rebase to the current master? A recent commit updated some code that your PR is touching (DataSetScan).
Then it should be good to merge.

Thanks for the fast update @dawidwys.
PR is good to merge :-)

Merging


Fetch tank status in frontend

This changeset alters the frontend app to periodically make an HTTP request to the pond service,  obtaining the status of the various prawn tanks.
It displays the data in a minimal way.
Solves the last requirement in #36

The display is damn ugly (it's JSON directly written as text into the webpage - don't tell anyone).  But CORS (including pre-flight OPTIONS!) is working!
🚢 SHIP IT 🚢
We'll clean up the display ASAP in unstable.


Add patch to fix symbol resolution issues on macOS

This PR adds a patch to pycbc.scheme to load libgomp using RTLD_GLOBAL, which fixes (or at least works around) the failures on macOS seen in #71 and #73.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

I confirm that using RTLD_GLOBAL seems to fix this.

Why is this being patched on the conda-forge feedsock, and not upstream?

I'm not sure this is globally relevant, or only in the context of a conda package. But, I am happy to remove this patch if it is included upstream in a future release.

@duncanmmacleod @titodalcanton Before merging this, I'd like to see confirmation that this issue is specific to conda, and not just MaxOSX. I agree with @josh-willis that this should be in pycbc directly if it is the correct fix. If not, I think we need to understand what the difference is.

Why is this being patched on the conda-forge feedsock, and not upstream?

I'm not sure this is globally relevant, or only in the context of a conda package. But, I am happy to remove this patch if it is included upstream in a future release.

Well I think we should test it to make sure it doesn't break multi-threaded FFTs via FFTW (which is the main thing I would be worried about) and that it works on both MacOS and Linux (which Tito may have already done) and then assuming not, we should do this upstream.
And then we should probably also revisit in the near term testing all of these things at the top-level, as opposed to doing it in the scheme once you know you need it.

This change was made in the main PyCBC repo https://github.com/gwastro/pycbc/pull/4353


0.6.2 Appears to break editor window colour in Gruvbox Dark Hard

Upon installing 0.6.2 my editor window is now light, other Dark themes are not affected.

Hi @snus-kin
Apologies for the delayed response. Could you please check the 'Editor - Color Scheme' setting?

Hi, using v0.6.3 seems to work now, wondering if there was version mismatch between the plugin & the IDE I was experiencing. Couldn't say what I was doing Feb 9th :).

I'll close this issue.


Add label cheatcode

function label(address addr, string label) external;

Sets a label label for addr in test traces.
If an address is labelled, the label will show up in test traces instead of the address.

Happy birthday


”Rățălești”, ”Romanești”, ”Zgubea” are listed in the drop-down menu

Description:
When user writes ”Rățălești”, ”Romanești”, ”Zgubea” the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Rățălești"

Expected results
The location appears in the drop-down menu as "Sat Rățălești, VÂLCEA (Roșiile)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Romanești"

Expected results
The location appears in the drop-down menu as "Sat Romanești, VÂLCEA (Roșiile)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Zgubea"

Expected results
The location appears in the drop-down menu as "Sat Zgubea, VÂLCEA (Roșiile)".


[Request] Add Unity Hub

Unity is a popular game engine. and Unity Hub a simple tool for install and uninstall Unity (game engine) and manage for the projects.
https://unity3d.com/get-unity/download
https://public-cdn.cloud.unity3d.com/hub/prod/UnityHubSetup.exe
Thanks

nonportable/unity-hub-np


Modell BFUS
FW :<IP_ADDRESS>A_202007211802
I Copy y20ga_0.2.0.tgz to my SD card
i plug it in my camera and start, but nothing happend after 30 seconds the blue light is lightning permanent.
please help me what should i have to do ...
i want donate something but it does´t work

You want to copy the contents of this archive to the SD card, not the archive itself.


SPIKE Analyze tools that could be added to secure VANotify

The purpose of this spike would be to research and document any security concerns that must be addressed for VANotify prior to going into production

[ ] Consult with VA/VSP teams to understand and evaluate what tools are currently used for security/vulnerability scanning (Fortify, Sonar, Snyk, sastscan, hawkeye, bandit, dependabot, pyup, codeclimate, Twistlock)

Fortify - may need a licence, and what do we do with the uploaded results?
Sonar - nice github action, free for open source projects
Snyk - dependency scanning, nice github action, pricing unclear
Hawkeye - dependency scanning (out-of-date and vulnerabilities), security issues (using bandit)
Bandit - security issues scanning, installed as python dependency
Dependabot - dependency scanning and updates, build into github
PyUp - dependency scanning, can make PRs or run as a github check
CodeClimate - not really security, more of a code quality tool

[ ] Document options that need to be added

[ ] Do we need to add a Security policy, as recommended by github?

[ ] Discuss and document the results within our team

Timebox - 3 Days
Assumption:

Implementation of the options for remediation will be done in a different card (#104). One card for each tool that we add.
Static code analysis
Dependency checks
Docker container vulnerability checks
Scanning of committed Secrets
Scanning for PII is out of scope for this story

Tools that might be of interest that are offered by DOTS (DevOps Tool Suite) team:

Codacy
code.scan
Twistlock

Should ADR be part of this or implementation story?

Tooling used by VSP:

Brakeman (scanning ruby dependency tree for known security vulns)
plus being responsive to github security alerts in the repos
static code analysis I think is mostly rubocop / eslint at this point

Another tool to review:
https://github.com/marketplace/actions/sast-scan

https://github.com/sonarsource/sonarcloud-github-action

https://lgtm.com/
It was bought by GitHub and seems well integrated with GitHub.
Free for opensource.

Matrix and recommendations documented in this spreadsheet

After following up with team at dev sync this morning, took some follow-up actions and have these recommendations:
Recommend: Bandit / Hawkeye

Meets our needs (minus image scanning), but no dashboard

Recommend: lgtm

Provides dashboard view that bandit/hawkeye don't provide, so it will be complimentary to them. Also does code reviews.

Recommend: dependabot

More actively maintained and now within the Github ecosystem, so easier integration. Also being used by other orgs like gov.uk, Mozilla, and PyPi. Has flexibility of adding reviewer to dependency update if necessary.

It depends how we feel between the two below, recommendation is:
_Based on price estimates comparisons, Twistlock is more expensive than Snyk, though Twistlock is a more robust tool with more application lifecycle management coverage (including runtime monitoring). We can try using Snyk free version as a stopgap until we are ready to consider more whole lifecycle management needs and/or to see if Snyk's free version's constraints impede our productivity.
If we need a tool like Twistlock/Prisma Cloud anyway for runtime support, we should opt for it over Snyk, especially see if the low-end $9k business edition meets all our needs._
Twistlock

meets all of our needs include image scanning and provides runtime monitoring
already in VA ecosystem, used by DOTS
pricing: https://aws.amazon.com/marketplace/pp/Palo-Alto-Networks-Prisma-Cloud-Enterprise-Edition/B07QDBGS6L
based on ^^ estimates, low-end $9000 (business edition) to $18000 (enterprise edition) per year.

Snyk

big pros: can scan terraform and has github actions, and more or less free, other than need license for container scanning.
con: there is free version for both Snyk OpenSource and Snyk Container licenses. Snyk's value-add is container scanning and terraform scanning. Free version is limited to 100 container scan tests per month / 200 vulnerability scans per month. For up to 10 devs, standard edition is $708 per month (approx $8,496 per year). hawkeye/lgtm meets all our needs except for image scanning. If we are going to pay for this tool, we might as well go for Twistlock which also provides runtime monitoring.

Noting a conversation has been scheduled with Sara Diaz from InfoSec for next week.


StatefulSet, DaemonSet, Service, Pod resources watching support

Will be available when supported in library: https://github.com/flant/kubedog/issues/22

Solved in https://github.com/flant/dapp/pull/1142


Please invite me to the GitHub Community Organization

Name
Ito Kazuki
Discord Username (if applicable)
Toptal
Additional Context
I like design and code. I really want to take part in this organization.

thanks.
On Sat, Jan 13, 2024 at 9:28 AM github-actions[bot] <
@.***> wrote:

Closed #977 https://github.com/Design-and-Code/support/issues/977 as
completed.
—
Reply to this email directly, view it on GitHub
https://github.com/Design-and-Code/support/issues/977#event-11477418107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BFGTVPXBMLDBGBCB7HI5SD3YOJHUXAVCNFSM6AAAAABBZGDVYCVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGQ3TONBRHAYTANY
.
You are receiving this because you authored the thread.Message ID:
@.***>


ForwardAuth forward cookie to auth server

Do you want to request a feature or report a bug?
Feature
What did you expect to see?
I am using the ForwardAuth to protect my traefik dashboard. However, my auth server needs to identify which user wants to login. Currently this information is in a cookie of the domain (the auth server and the traefik dashboard are on the same domain). It would be great if I could control the ForwardAuth in such a way that it would forward this cookie to the server such that it can identify the user.
I think this is not possible at the moment, but if I am wrong please help me how to get this done. I do not understand how the auth server currently knows how to give access or deny access since it does not receive any information if I am right.

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI has spotted that your issue might be a configuration problem or relates to something that doesn't look like a bug.
To confirm this, please join our Community Forum and reach out to us on the Traefik section.
In case I'm wrong (well, that would be embarrassing :sweat_smile:), my developers will re-open the issue and fix me!
In the meantime, you can double check Traefik's documentation.


fix resouce_limit calculation, wasm_tests compilation errors

@heifner why was this issue closed?

It was closed because the wasm_tests.cpp was already ported and moved to the unittests directory.


fix: patched semantic release

:tada: This PR is included in version 1.35.1 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Minor, linux: taskbar icon is generic wayland "W" rather than the spyder icon

Issue Report Checklist

[ x] Searched the issues page for similar reports
[x] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[x] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[ ] Could not reproduce inside jupyter qtconsole (if console-related)
[x] Tried basic troubleshooting (if a bug/error)

[x] Restarted Spyder
[ ] Reset preferences with spyder --reset
[ ] Reinstalled the latest version of Anaconda
[ ] Tried the other applicable steps from the Troubleshooting Guide

[x] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
Spyder does not get its application icon right in taskbar and application title bar in Linux Wayland. The generic "W" logo that is used for wayland application is used instead.
What steps reproduce the problem?

Install Spyder on a Linux distribution (tested on Manjaro) using a virtual env and pip
Launch Spyder from the command line
See Spyder opening and working correctly. However the taskbar icon is a W and there is also a W in the left corner of the title bar.
Hovering with the mouse on the taskbar tells that the application is "Python", not "Spyder"

What is the expected output? What do you see instead?
Spyder should get its own icon on the task bar to make it immediately recognizable.  We'll try to take a look at this problem in a future version.

I have looked a bit into the issue. If my understanding is correct, this is a hard to solve issue, being ultimately due to a limitation in the Wayland protocols as reported in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/52.
Wayland breaks Qt setWindowIcon (https://bugreports.qt.io/browse/QTBUG-101427) and currently pretends that every GUI application has a .desktop file. Unfortunately python applications installed with pip or pipx don't get any. Maybe just drop this until Wayland catches up with other platforms, Win, MacOs and the aging X11. Alternatively as a showstopper it could be Spyder itself to check for its own desktop file in .local/share/application and propose to write one if it is missing and it is possible to do so.

Alternatively as a showstopper it could be Spyder itself to check for its own desktop file in .local/share/application and propose to write one if it is missing and it is possible to do so.

That's not easy to do with pip alone and it'd be hard to implement for different Spyder's installed in several envs.
But the good news is that we're going to have a Linux installer based on conda packages for Spyder 6. That will come with its own desktop file, which will solve this issue according to what you said. Even if Spyder is a regular Python package, if you really want a smooth application experience, I think you'll need to use our installers in the future. It's fine if you don't, of course, but then you'll have to put up with annoyances like this one.
Since that's the best the we could do in the min term, I'm going to close this issue as "won't fix".

Perfectly OK not to fix. When I reported the issue, I did not know the cause yet, so sorry for the noise. My gratitude in advance should you have the occasion to interact with the Wayland developers to advocate their following up with the plan to provide a protocol extension to make setWindowIcon work as it does in the other platforms.

Sorry, I don't have time for that. But you're welcome to reference this comment when talking to the Wayland developers to let me know that we fully embrace a way to make setWindowIcon work as in Xorg.


Fix deprecation warning when using primary colors as fallbacks

Platforms Impacted

[x] iOS
[x] macOS

Description of changes
Use private values (FallbackThemeColor.primary) instead of deprecated public API (Colors.primary) in Colors.primary(for:) color API.
Verification
There are no more compiler warnings regard using the deprecated Colors.primary API.
Pull request checklist
This PR has considered:

[x] Light and Dark appearances
[x] VoiceOver and Keyboard Accessibility
[x] Internationalization and Right to Left layouts
[x] Different resolutions (1x, 2x, 3x)
[x] Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)

Microsoft Reviewers: Open in CodeFlow

this is the right fix. There are clients who are still using MSFColors.primary etc for setting their branding colors. the intention of this code to make clients move away from the primary property and use the MSFColors primary for window instead. the fallback color to be communicationBlue is incorrect because different apps will have different app branding color

this is the right fix. There are clients who are still using MSFColors.primary etc for setting their branding colors. the intention of this code to make clients move away from the primary property and use the MSFColors primary for window instead. the fallback color to be communicationBlue is incorrect because different apps will have different app branding color

There is not any modification to the existing behavior. I just created move the usage of primary colors to the private scope so the warnings of using deprecated public API is gone.

There is not any modification to the existing behavior. I just created move the usage of primary colors to the private scope so the warnings of using deprecated public API is gone.

Clients using MSFColors.primary will still get warnings as before. With this fix the compilation of Colors.primary(for:) (MSFColors primary for window) will get no more warnings (it now use private scoped colors now).

Clients using MSFColors.primary will still get warnings as before. With this fix the compilation of Colors.primary(for:) (MSFColors primary for window) will get no more warnings (it now use private scoped colors now).

As you can see, FallbackThemeColor.primary is the same as the existing Colors.primary. The only difference is that FallbackThemeColor.primary is of fileprivate access scope.

As you can see, FallbackThemeColor.primary is the same as the existing Colors.primary. The only difference is that FallbackThemeColor.primary is of fileprivate access scope.

fallbacktheme colors won't necessarily have the same color as colors.primary. if client code set the primary color, there are places within sdk that calls colorsforwindow instead of getting the app branding color it will now fallback to communicationblue.

fallbacktheme colors won't necessarily have the same color as colors.primary. if client code set the primary color, there are places within sdk that calls colorsforwindow instead of getting the app branding color it will now fallback to communicationblue.

Thanks Harrie. Now all the Colors.primary colors will act as proxy and get/set colors from FallbackThemeColor.primary as single source.

Thanks Harrie. Now all the Colors.primary colors will act as proxy and get/set colors from FallbackThemeColor.primary as single source.


Update version

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


Can't find variable: document

I am trying to use react-intl-tel-input (http://patw0929.github.io/react-intl-tel-input/) in my React-Native project,
but I get the error of "Can't find variable: document"
Is there any work around or components to use this react components in react-native?

It doesn't work because  assumes it is running on a webpage and it renders to HTML.

Did anyone find a solution to this?


(CFACT-268) Don't resolve custom facts when --no-custom-facts is used

This commit fixes a regression around the --no-custom-facts
command-line option. Currently, the option is not being honored,
and so custom facts will be resolved even if the option is used.
This commit ensures that custom facts will not be resolved if either
this option is passed or if Ruby is not present.

:+1:

:+1:

CLA signed by all contributors.

Not too worried about coveralls for this one :)


Could I use npm install --registry?

Hi,
When I use 'create-react-app myapp' to create project, it auto npm install libs from npmjs.org.
Could I use create-react-app myapp --registry=xxxx to install libs?
Or create-react-app myapp --manual to run npm install manual?
Thanks.

Could you please explain the use case for this?

Connect to npmjs.org sometimes is slow even broke in China, We use npm.taobao.org more than the former.
And I think it's useful for some people who behind a company firewall and can only npm install from their self-build npm repository.

Does setting a global registry override help?
http://stackoverflow.com/a/22390936/458193

Yes, you're right. I forgot this. Thanks.


Use @google-cloud/iam-credentials instead of googleapis

Description of Change
Reduce core package size by using @google-cloud/iam-credentials instead of googleapis
Fix https://github.com/cloud-carbon-footprint/cloud-carbon-footprint/issues/275
Checklist

[ ] PR description included and stakeholders cc'd
[ ] tests are changed or added
[ ] yarn test passes
[ ] yarn lint has been run
[ ] git pre-commit hook is successfully executed.
(Please refrain from using --no-verify)
[ ] yarn changeset was run and relevant packages have been updated as a major/minor/patch bump with descriptions
(Determine version update using Semantic Versioning)
[ ] relevant documentation is changed or added

PR has been rebase due to conflict with upstream

Thanks for this @vhiairrassary -- changes look good! We went ahead and updated your branch again with the latest on trunk -- sorry for pushing directly to you branch! We'll do a final review and merge this down tomorrow.

Merged! Thanks again @vhiairrassary -- this is is a solid improvement to the codebase.


Bug: Proxy Cache Missed Updates

I've seen a couple of failures of the clientgo_cached_proxy_resolver_test.go unit tests recently:

https://github.com/Kong/kubernetes-ingress-controller/pull/1463/checks?check_run_id=2952969675#step:6:1115
https://github.com/Kong/kubernetes-ingress-controller/pull/1463/checks?check_run_id=2953105965#step:6:1106
https://github.com/Kong/kubernetes-ingress-controller/runs/2966800964?check_suite_focus=true#step:6:1133

The failures look like this:
 === RUN   TestCaching
    clientgo_cached_proxy_resolver_test.go:101: configuring and starting a new proxy server
    clientgo_cached_proxy_resolver_test.go:105: ensuring the integrity of the proxy server
    clientgo_cached_proxy_resolver_test.go:110: intentionally freezing async updates to inspect cache state during tests
    clientgo_cached_proxy_resolver_test.go:113: generating 10 new objects to the proxy cache server
    clientgo_cached_proxy_resolver_test.go:123: adding 10 new objects to the proxy cache server
    clientgo_cached_proxy_resolver_test.go:129: ensuring the consistency of the underlying object cache (that objects were added properly)
{"level":"info","msg":"the proxy cache server has been started","time":"2021-06-30T13:58:47Z"}
    clientgo_cached_proxy_resolver_test.go:134: flushing the cache state to kong admin api
    clientgo_cached_proxy_resolver_test.go:137:
        	Error Trace:	clientgo_cached_proxy_resolver_test.go:137
        	Error:      	Condition never satisfied
        	Test:       	TestCaching
--- FAIL: TestCaching (10.21s)

There would appear be a bug in the proxy cache server implementation that causes a missed update (or perhaps the tests just aren't quite right) that can happen only very occasionally in CI.
The purpose of this report is to identify the root cause and get that fixed prior to KIC 2.0 beta.1.

https://github.com/Kong/kubernetes-ingress-controller/pull/1502 fixes this issue, turns out it was just a race condition with the mocking implementation in the tests, not a problem with the proxy cache server implementation itself.


Cannot configure Execution Environments

Problem
Using VSCode3 on MacOS remoting to an Ubuntu 22.04 dev host, the error message:
[Error - 2:24:20 PM] ExecutionEnvironment service not correctly initialized.
Checking the Output - Ansible Support:
[Error - 2:24:20 PM] ExecutionEnvironment service not correctly initialized.
[Error - 2:24:20 PM] ExecutionEnvironment service not correctly initialized.
Error: error inspecting object: no such object: "hub.domain.net/winrm_image:latest"
Error: Command failed: podman inspect --format='{{json .Config}}' hub.domain.net/winrm_image:latest
Error: error inspecting object: no such object: "hub.domain.net/winrm_image:latest"

    at checkExecSyncError (node:child_process:828:11)
    at Object.execSync (node:child_process:902:15)
    at /home/ansible/.vscode-server/extensions/redhat.ansible-2.0.58/out/server/src/server.js:2:121696
    at Generator.next (<anonymous>)
    at s (/home/ansible/.vscode-server/extensions/redhat.ansible-2.0.58/out/server/src/server.js:2:118981) {
  status: 125,
  signal: null,
  output: [
    null,
    '',
    'Error: error inspecting object: no such object: "hub.domain.net/winrm_image:latest"\n'
  ],
  pid: 164205,
  stdout: '',
  stderr: 'Error: error inspecting object: no such object: "hub.domain.net/winrm_image:latest"\n'

Settings.py
{
"ansible.ansible.path": "/home/ansible/.local/bin/ansible",
"ansible.ansible.reuseTerminal": true,
"ansible.ansibleNavigator.path": "/home/ansible/.local/bin/ansible-navigator",
"ansible.executionEnvironment.enabled": true,
"ansible.executionEnvironment.image": "hub.domain.net/winrm_image:latest",
"ansible.lightspeed.enabled": true,
"ansible.lightspeed.suggestions.enabled": true,
"ansible.python.interpreterPath": "/usr/bin/python3",
"ansible.validation.lint.path": "/home/ansible/.local/bin/ansible-lint",
"python.defaultInterpreterPath": "/usr/bin/python"
}
In the terminal I can run:
podman pull hub.domain.net/winrm_image:latest. successfully
podman images shows the image I want
However my Private Automation Hub requires a login, much like quay and registry. I have not found settings to cover that so maybes that' the problem?
Solution
The extension correctly pulls the image or if not missing, uses the one specified.
Alternatives
No response
Additional context
No response

We only support official EE for the use case.


Image gallery: eternal loop

When clicking on one picture of an image gallery, the image is zoomed. From then, it should be possible to navigate by clicking or by switching images with the finger throughout the entire gallery and not only throughout the current page (when pagination is used).

We cannot reproduce. Please send a link

https://www.admin.ch/gov/de/start/bundesrat/bilder-und-reden-des-bundesrats/offizielle-bundesratsbilder.paging-1.html


getView() expects a string

This is not a pressing issue as I have found a way around it for now, just curious as to whether the getView function has changed recently or I am doing something wrong.
The code snippet below is located in the example marketing package. Following the same format leavves me with an object yet getView is expecting a string.
// Load initial view data.
  if (type === "node--landing_page") {
    for (const section of node.field_sections) {
      if (section.type === "paragraph--view" && section.field_view) {
        const view = await getView(section.field_view, {
          params: {
            include: "field_location,field_images.field_media_image",
          },
        })

        section.field_view = {
          name: section.field_view,
          ...view,
        }
      }
    }
  }

I managed to work around it by using the below snippet:
if(type === 'node--home') {
    for (const paragraph of node.field_paragraphs) {
      if (paragraph.type === "paragraph--project_carousel_block" && paragraph.field_pcb_view) {
        const view = await getView(`${paragraph.field_pcb_view.resourceIdObjMeta.drupal_internal__target_id}--${paragraph.field_pcb_view.resourceIdObjMeta.display_id}`, {
          params: {
            include: "field_project_thumbnail_image.field_media_image,field_project_types",
          },
        });

        paragraph.field_pcb_view = {
          name: paragraph.field_pcb_view,
          ...view,
        }
      }
    }
  }

Am I missing something?

@rilrom Is field_pcb_view a views reference field?
In the marketing example, since we're not rendering the actual view in Twig, I'm using a simple List (text) field type to reference the view.

field_view returns the NAME--DISPLAY which works with getView.

Just a quick note (since you're using paragraphs and referencing the marketing example): this example needs updating. The way paragraphs is loaded (via dynamic import) is not the best for SSG.
I'm going to push an updated version soon.
So if you hit any issues or have any questions feel free to ping me here on GitHub or Drupal Slack or @shadcn.
Happy to help.


Refunding Transaction from Collective to Itself

This is initially discussed at, https://github.com/opencollective/opencollective-api/pull/6887#issuecomment-977899304. We don't currently support refunding a transaction made from a collective to itself. For example adding funds to a collective selecting the Source as the same collective and then trying to refund this transaction will hit an error (after https://github.com/opencollective/opencollective/issues/4369 is completed it will show a more user friendly error such as; Cannot refund a transaction from the same collective).
We need to think about what we should do here. My thoughts are,

The word refund doesn't really make sense in the front-end in this case as we are refunding to the same collective.
Even if we do create refund transactions might be confusing when looking at the transactions list.

I propose that in this case the host admins should be able to remove the transaction and in the UI instead of refund it should show remove maybe? And when clicked on this a confirmation box appears (similar to the refund case) but after confirming the transaction should be soft deleted and should not appear on the UI.
Does this sound reasonable? If there's any alternative suggestions let me know. 🤔
cc: @znarf @Betree

It's an edge case and we should not overthink it. As a matter of simplicity, I would not touch anything on the Frontend side.
On the API side, I'm fine with soft-deleting as a first temporary measure if creating a real Refund transaction is complicated.

Would be great to tackle this.


[release-2.4] Fix Gatekeeper namespace creation detection

This is a manual cherry-pick of https://github.com/stolostron/governance-policy-framework/pull/463
Closes https://github.com/stolostron/backlog/issues/25118

/retest


⚠ BroadcasTheNet has degraded performance

In 266bf73, BroadcasTheNet ($BTN) experienced degraded performance:

HTTP code: 525
Response time: 24450 ms

Resolved: BroadcasTheNet performance has improved in 7a3c1d2.


Trainer activity: Focus answer text field automatically

If the user clicks on "Next" in the trainer activity the app should focus the text field for the answer and show the keyboard automatically.

Fulfilled with this commit.


Allow V8 flags to be configured at runtime

This PR allows flags for V8 to be configured at runtime by the root project (where the initrd was packed) in /runtime.json, like:
{
  "v8": {
    "flags": "--my-v8-flags --expose-wasm --harmony --more"
  }
}

Hopefully, runtime.json will also contain flags for runtime.js in the future (e.g. enabling SMP).
On a minor note, the performance global has been added to the .eslintrc. Somehow it was overlooked in the code style pull request.

This is amazing, looks great! 🎉
Let's merge this, then I'll tag a new release!


Expose wrapValidateAccessTokenAndGetUser

Supports validating the JWT and extracting its data without the authorization aspect

Closing PR. I didn't realize that validateAccessTokenAndGetUser is already exposed and does exactly this.


how report.html be designed?

how report.html be designed?
Or how to covert cpuprofile to a list like
Array<{
costTime: number,
functionName: string,
}>

It's build with Discovery.js, its source can be found in app folder. You can run it locally with npm start command in the cloned repo.
If you need a subset of data, open a report page:

Write a query and copy JSON using "f" button:

Query example:
functions.({
  name,
  loc,
  selfTime,
  totalTime
})

You also can customize view:

Or just click "as table" in struct view:

Also you can use this link with prefilled query, just load you profile file using "Open file..." in top right corner.


Record struct are not supported for custom runtime types

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
I have a strongly typed id implemented using the new record struct data structure but when I try to expose it from my graphql scheme I'm getting an error. This is working fine for other custom types, including the same data structure implemented as a record class. Is there any extra setup involved that I'm missing?
Steps to reproduce
I have the following set up code:
.AddTypeConverter<string, MyCustomId>(from => MyCustomId.Create(from))
.AddTypeConverter<MyCustomId, string>(from => from.Value)
.BindRuntimeType<MyCustomId, StringType>()

If MyCustomId is defined as:
public record class MyCustomId(string Value);
Everything works fine.
If MyCustomId is defined as:
public readonly record struct MyCustomId(string Value);
I get the following error:
The type of the member Id of the declaring type ViewModel is unknown  (HotChocolate.Data.Filters.FilterInputType<MyCompany.MyViewModel>)'
Relevant log output
No response
Additional Context?
No response
Product
Hot Chocolate
Version
12.3.0

I will write a test for this.

So for filtering this is a bit different. The mapping of scalar to filter input type is similar but not exactly the same as on the schema builder. While in most cases this works fine, binding a runtime type like this, will not work.
With #5760  you can use structs for filtering, but it would infer it as an "object" rather than a scalar. With #5759 there is a bit more documentation around how to bind and override the filters.
In your case this will work:
services
    .AddGraphQLServer()
    .AddFiltering(x => x.BindRuntimeType<MyCustomId, StringOperationFilterInputType>())
    .AddTypeConverter<string, MyCustomId>(from => new MyCustomId(from))
    .AddTypeConverter<MyCustomId, string>(from => from.Value)
    .BindRuntimeType<MyCustomId, StringType>()
   ...


Regression onicecandidateerror in TS4.4

onicecandidateerror should have a RTCPeerConnectionIceErrorEvent argument.
https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/onicecandidateerror
RTCPeerConnectionIceErrorEvent was removed here https://github.com/microsoft/TypeScript/commit/9d443b76aac0832d7f3c890441264d39307fe31a
    onicecandidateerror: ((this: RTCPeerConnection, ev: RTCPeerConnectionIceErrorEvent) => any) | null;

onicecandidateerror was readded in this merge with the incorrect type here https://github.com/microsoft/TypeScript/commit/eb1e5664447b47850370f28d8f7237cb5fc03ed1
    onicecandidateerror: ((this: RTCPeerConnection, ev: Event) => any) | null;

Currently in TS4.4 if I do something like this.
    peerConnection.onicecandidateerror = (errorEvent: RTCPeerConnectionIceErrorEvent) => {}

I get
     TS2322: Type '(errorEvent: RTCPeerConnectionIceErrorEvent) => void' is not assignable to type '(this: RTCPeerConnection, ev: Event) => any'.
  Types of parameters 'errorEvent' and 'ev' are incompatible.

To expedite the triage process, we need everyone to follow the issue template and instructions.
When you clicked "Create New Issue", the issue form was pre-populated with a template and some instructions. We need you to read those instructions completely, follow them, and then fill in all the fields in that template.
We are not able to assist with issues that don't follow the template instructions as they represent a significantly larger amount of work compared to issues which are correctly specified. Thank you for understanding.