Got ESP_ERR_NVS_NOT_ENOUGH_SPACE when write zero length data with nvs_set_blob (IDFGH-4110)

Environment

Module or chip used: ESP32-WROOM-32E
IDF version: v4.3-dev-1197-g8bc19ba893e5
Build System: idf.py
Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp-2020r3) 8.4.0
Operating System: Linux
Power Supply: USB

Problem Description
I try to randomly write blob data with 512B/1KB/2KB/3KB strings.
nvs_set_blob(handle, key, str, strlen(str));
And use below code to clear my blob data.
nvs_set_blob(handle, key, "", 0);
It works in most time.
But I found if I repeat writing the blob data more times, it's possible to hit ESP_ERR_NVS_NOT_ENOUGH_SPACE error
when I call nvs_set_blob(handle, key, "", 0).
What make me confused is when this happen, it's ok to call nvs_set_blob(handle, key, str, strlen(str)); with short string.
Note, when this issue happen, in writeMultiPageBlob()
    do {
        Page& page = getCurrentPage();
        size_t tailroom = page.getVarDataTailroom();
        size_t chunkSize =0;
printf("chunkCount=%d tailroom=%d dataSize=%d\r\n", chunkCount, tailroom, dataSize);
        if (!chunkCount && tailroom < dataSize && tailroom < Page::CHUNK_MAX_SIZE/10) {

Above printf shows "chunkCount=0 tailroom=0 dataSize=0".
I'm wondering if there is something wrong when calling nvs_set_blob with dataSize = 0.
Expected Behavior
IMHO, clear blob data with writing dataSize=0 should not got ESP_ERR_NVS_NOT_ENOUGH_SPACE error.
Especially when it's ok to write short string with the same key.
Actual Behavior
Sometimes nvs_set_blob(handle, key, "", 0) returns ESP_ERR_NVS_NOT_ENOUGH_SPACE.
But it's ok to write some short string (non-zero length) with the same key.
Steps to reproduce
Just repeat read/write NVS with variable length data (to make it fragment).

Thanks for reporting, we will look into.

Hi @AxelLin, sorry for the late reply! From what you tell us, it looks like a bug somewhere in the NVS system. We're investigating this now. I'm not sure whether nvs_set_blob was ever meant to be used with 0 length... Does deleting the blob item instead of writing a blob with length 0 work for you?

Hi @0xjakob
Honestly, I don't know if repeating create key / delete key is better or worsen to the NVS system.
Our application API assumes the empty string in a blob key means clear the stetting.
So we prefer to keep the key with empty string rather than delete it.

@AxelLin I think the empty string key isn't a problem. I kind of reproduced the issue locally now. The problem seems to be with the 0 length blob. It looks like this check fails in some situations when the length is zero and there isn't enough space in the current page anymore. The result is the failure ESP_ERR_NVS_NOT_ENOUGH_SPACE instead of requesting a new page.
I'll try to fix this tomorrow.

@AxelLin Disregard the first sentence of my previous comment. I think I fixed the issue, at least all our tests work. Could you apply the attached patch to see whether it fixes your problem? There's certainly a situation where a blob write with 0 length can cause trouble, as mentioned above.
0001-NVS-fixed-bug-when-blob-data-size-0.zip

Hi @0xjakob
Thanks for your prompt response.
I have tested with your patch.
After hitting ESP_ERR_NVS_NOT_ENOUGH_SPACE, it's still possible not able to set empty value.
Below is my debug print when nvs_set_blob with a long string (3422 bytes) fails.
chunkCount=0 tailroom=32 dataSize=3422
chunkCount=0 tailroom=1440 dataSize=3422
chunkCount=1 tailroom=192 dataSize=3422
chunkCount=2 tailroom=32 dataSize=3422
chunkCount=3 tailroom=0 dataSize=3422
I got ESP_ERR_NVS_NOT_ENOUGH_SPACE.
Then sometimes set empty value also fails.
I'm not sure if the patch works or not because even without the patch setting empty value is also working in most of the time.
But I notice setting small string with nvs_set_str/nvs_set_blob also fails if setting empty value fails,
this is a difference without the patch.
(Although setting integer values still works)
Below is my nvs_stats numbers when this issue happen.
nvs_stats.free_entries = 127
nvs_stats.used_entries 1007
nvs_stats.total_entries = 1134
But I notice 2 unusual things:

When nvs_set_blob(handle, key, "", 0); fails
If I reboot the device and try again, then nvs_set_blob(handle, key, "", 0); works.
I'm not sure it will  work always or just sometimes, but it looks like reboot indeed makes some difference.

Sometimes, the nvs key disappear if nvs_set_blob fails with ESP_ERR_NVS_NOT_ENOUGH_SPACE.
(Just like the key was deleted, this is unexpected behavior)
I hit this twice, but I don't have a good steps to reproduce it. ( I just randomly upload various size data to different keys).

BTW, I'm wondering what is the recommend action when NVS system is really too fragment.

@AxelLin Hi.
Setting a blob item with a key that hasn't been written yet involves at least two item writes (blob entry with key and blob index entry) into a page. If I'm not mistaken, they have to be two contiguous items. Not sure whether that's the case in your situation, but if, then your observation makes sense:

But I notice setting small string with nvs_set_str/nvs_set_blob also fails if setting empty value fails,
this is a difference without the patch.
(Although setting integer values still works)

For your two listed observations 1. and 2., this looks not quite right. Does this happen with or without the patch?
The recommended action if NVS becomes too fragmented is to increase the partition size. NVS is intended for storage of small parameters, even though you can store blobs and strings. If you have a large blob, it might be better to store it in a separate partition either as raw data or using a file system. Keep in mind though that the IDF filesystems may not be completely power-off tolerant. NVS is designed to be power-off tolerant (I realize the irony since you sometimes get different results after rebooting the device). You can also store a chunk of raw data in another partition and use NVS to store some meta parameters about this chunk (like length, last written date, etc.), which might help for power-off tolerance.

@AxelLin Hi.
Setting a blob item with a key that hasn't been written yet involves at least two item writes (blob entry with key and blob index entry) into a page. If I'm not mistaken, they have to be two contiguous items. Not sure whether that's the case in your situation, but if, then your observation makes sense:

In my test, I always test setting to existing key. (I never delete a key, I may set it to different value or empty value)

But I notice setting small string with nvs_set_str/nvs_set_blob also fails if setting empty value fails,
this is a difference without the patch.
(Although setting integer values still works)

For your two listed observations 1. and 2., this looks not quite right. Does this happen with or without the patch?

Currently, all my test is with your patch and a few debug prints I added (for all test in my previous report).

The recommended action if NVS becomes too fragmented is to increase the partition size. NVS is intended for storage of small parameters, even though you can store blobs and strings. If you have a large blob, it might be better to store it in a separate partition either as raw data or using a file system. Keep in mind though that the IDF filesystems may not be completely power-off tolerant. NVS is designed to be power-off tolerant (I realize the irony since you sometimes get different results after rebooting the device). You can also store a chunk of raw data in another partition and use NVS to store some meta parameters about this chunk (like length, last written date, etc.), which might help for power-off tolerance.

Now I confirmed indeed some difference between reboot when hit ESP_ERR_NVS_NOT_ENOUGH_SPACE.

nvs_set_blob with a long string failed and return ESP_ERR_NVS_NOT_ENOUGH_SPACE
call nvs_set_blob(handle, key, "", 0); also fails with ESP_ERR_NVS_NOT_ENOUGH_SPACE.
Then I check the nvs_stats numbers:
nvs_stats.free_entries = 127
nvs_stats.used_entries 1007
nvs_stats.total_entries = 1134

Then I reboot, check the nvs_stats numbers again:
nvs_stats.free_entries = 231
nvs_stats.used_entries 903
nvs_stats.total_entries = 1134
The free_entreis becomes larger, I think that's why nvs_set_blob(handle, key, "", 0); works after reboot.
Regarding the free_entreis count inconsistent after reboot, that probably worth tracing.

Hi @AxelLin I will continue looking into this on Monday. I have confirmed that there is the issue I fixed in the patch but haven't yet looked into your other issues.

@AxelLin Is there any chance that you can send us some reproducing code? When I try myself, I never get ESP_ERR_NVS_NOT_ENOUGH_SPACE, neither using the host tests, nor using the target tests. I tried both with and without the patch. The test code for the target looks like this:
TEST_CASE("overwrite blob with new empty blob", "[nvs_storage]")
{
    const size_t BLOB_SIZE = 3422;

    nvs_handle_t handle;
    esp_err_t err = nvs_flash_init();
    if (err == ESP_ERR_NVS_NO_FREE_PAGES || err == ESP_ERR_NVS_NEW_VERSION_FOUND) {
        nvs_flash_erase();
        err = nvs_flash_init();
    }
    TEST_ESP_OK(err);

    uint8_t *blob = calloc(BLOB_SIZE, 1);
    TEST_ASSERT(blob != NULL);
    TEST_ESP_OK(nvs_open("test_ns", NVS_READWRITE, &handle));

    char BLOB_NAME [] = "blob";
    uint8_t start = 0;
    for (size_t i = 0; i < 0xFF; i++) {
        blob[0] = (uint8_t) i;
        esp_err_t result = nvs_set_blob(handle, BLOB_NAME, blob, BLOB_SIZE);
        if (result != ESP_OK) {
            break;
        }
        start = (start + 1) % 0xFF;
    }

    // overwrite the blob with an empty blob
    TEST_ESP_OK(nvs_set_blob(handle, BLOB_NAME, "", 0));

    nvs_close(handle);

    free(blob);

    nvs_flash_deinit();
}

I don't have code snipt to test it automatically.
I have various settings with different key types, I just randomly update the value.
I test it manually by repeating update nvs values.
I think maybe increase settings (with different key types) and reduce your NVS partition
can make it easier to reproduce.

@AxelLin Disregard the first sentence of my previous comment. I think I fixed the issue, at least all our tests work. Could you apply the attached patch to see whether it fixes your problem? There's certainly a situation where a blob write with 0 length can cause trouble, as mentioned above.
0001-NVS-fixed-bug-when-blob-data-size-0.zip

Hi,
Just wondering if any issue with above patch?
It has been there for a long period but not merged to recent esp-idf update.

@AxelLin Disregard the first sentence of my previous comment. I think I fixed the issue, at least all our tests work. Could you apply the attached patch to see whether it fixes your problem? There's certainly a situation where a blob write with 0 length can cause trouble, as mentioned above.
0001-NVS-fixed-bug-when-blob-data-size-0.zip

Hi,
Just wondering if any issue with above patch?
It has been there for a long period but not merged to recent esp-idf update.

Hi @AxelLin,
The fix has been merged to master, the patch contains some additional changes.
The important line is here:
https://github.com/espressif/esp-idf/blob/master/components/nvs_flash/src/nvs_storage.cpp#L192
Hope this helps,
Jakob

Hi @AxelLin,
The fix has been merged to master, the patch contains some additional changes.
The important line is here:
https://github.com/espressif/esp-idf/blob/master/components/nvs_flash/src/nvs_storage.cpp#L192
Hope this helps,
Jakob

@AxelLin Do you still have the issue described above even if you rebase onto current master?

@AxelLin Do you still have the issue described above even if you rebase onto current master?

Hi @0xjakob
My test looks lood so far, but I think it needs more time to verify.
I will close the issue if it's still does not hit the issue next week.
Thanks a lot for your support.

Hi @0xjakob
My test looks lood so far, but I think it needs more time to verify.
I will close the issue if it's still does not hit the issue next week.
Thanks a lot for your support.


Please describe how to use BERT or ELECTRA Models for Longformer training.

Hi,
I am interested in traing a german longformer model. But there is no german RoBERTa. I have seen that it is possible to use BERT as a basis but you only have a description to use RoBERTa. Since there seems to be some demand:

https://github.com/allenai/longformer/issues/85
https://github.com/allenai/longformer/issues/21
https://github.com/allenai/longformer/issues/82
https://github.com/allenai/longformer/issues/77
https://github.com/allenai/longformer/issues/72
https://github.com/allenai/longformer/issues/65
https://github.com/allenai/longformer/issues/61

Could you please add a 2nd jupyter notebook on how to use BERT as basis or describe in detail what to change on the existing notebook for RoBERTa? That would realy be awsome.
Thanks
Philip

At least for BERT, here's what seems to be working for me (altering the notebook), at least for generating the model with global attention (haven't attempted pre-training yet):

swap what is imported from Transformers (obviously) from roberta
swap model names in the 'from_pretrained()' method to your chosen BERT model.
remove all ".roberta" instances (e.g., 'model.roberta.encoder...' --> 'model.encoder')
remove the line incrementing +=2 to max_position, and in general remove all instances of '2', as BERT does not reserve the first two tokens. I.e., set 'k=0', set 'step = current_max_pos', and remove the '2' from slicing of .position_embeddings.weight[:] .

@simonlevine Thank you for your post.  Very useful for me. I'm thinking since BERT models also have token_type_ids embeddings and Roberta models don't. Do you think that we need to provide any other modification in token_type_ids embeddings ?

@msobroza Hi Max, It's my understanding that since config=model.config in the notebook, type_vocab_size defaults to whatever model you pull in. Additionally, the tokenizer should be inherit all parameters from whatever model you pulled in. So, I don't think that token_type_ids present additional steps. However, when pulling in your new model as LongformerModel.from_pretrained(...), there appear to be Roberta-specific parameters that may be overwritten.
I suggest, then to use a similar protocol to what appears in the notebook, something like this but for your specific model:
logger.info(f'Loading the model from {model_path}')
tokenizer = RobertaTokenizerFast.from_pretrained(model_path)
model = RobertaLongForMaskedLM.from_pretrained(model_path)

Hi.
I'm trying to use DistilBert as my baseline model for creating my Longformer model, but it has been quite a task. Apparently DistilBert has no "encoder" layer. I'd be grateful if someone could help me how to do this?

Please check https://github.com/allenai/longformer/issues/95, @krrishdholakia was able to convert BERT into long. This also applies to ELECTRA as it seems it is reusing the BERT code.
@FeryET, DistilBert has a slightly different implementation of selfattention. Following the convert_model_to_long.ipynb notebook, your DistilBertLongSelfAttention (instead of RobertaLongSelfAttention) will need more code in the forward function to convert the format used in MultiHeadSelfAttention into the format of LongformerSelfAttention. You also need to check that the position embedding is extended correctly.

@PhilipMay Any progress on this? I'd be very interested in a German Longformer model.

@PhilipMay I am also interested in training a Longformer model in Turkish, but facing the same issue with you. Have you made any progress on this?


sklearn-0.19: deprecation warnings of y_train_mean

In sklearn-0.19, the y_train_mean of GaussianProcessorRegressor has been deprecated. See:
https://github.com/scikit-learn/scikit-learn/blob/ec0dbf0399c4187a1d17e66de17265c67588373f/sklearn/gaussian_process/gpr.py#L153
This results in tons of warnings, as scikit-optimize itself depends on this attribute, at https://github.com/scikit-optimize/scikit-optimize/blob/e08a067abfa759fa60f279eaf2df569bafc79147/skopt/learning/gaussian_process/gpr.py#L305
Reported in #461.

Fixed in #464

That seems like a good hot-fix but I'm not sure scikit-optimize wants to rely on private attributes?

That seems like a good hot-fix but I'm not sure scikit-optimize wants to rely on private attributes?

Previously, this wasn't in a private attribute :(

I can't seem to find a discussion of public vs private in https://github.com/scikit-learn/scikit-learn/pull/7846 It looked like there was no compelling reason to leave it public, it definitely needed to be renamed because it didn't end with a trailing underscore. We could still make it public again if there's a good reason, but we should do so quickly then.

maybe @jnothman or @tguillemot remember?

I suppose we should have been more careful with it. PR to make it public?

But y_train_ is stored! Why can't you take the mean yourself at no enormous cost??

But y_train_ is stored! Why can't you take the mean yourself at no enormous cost??

+1. How do you feel about sending your first PR to scikit-optimize :p ?

Ah, @MechCoder, there was a time when I watched your every issue, but there's just too much to keep abreast of across projects.


[Bugfix] Fix inappropriate content of model_name tag in Prometheus metrics

Description
When deploying a local model, such as one located at a path like /mnt/Qwen1.5-14B-chat/, the Prometheus metrics output exposes this model path information.
The metrics output looks like this:
...
# HELP vllm:num_requests_running Number of requests currently running on GPU.
# TYPE vllm:num_requests_running gauge
vllm:num_requests_running{model_name="/mnt/Qwen1.5-14B-Chat/"} 0.0
# HELP vllm:num_requests_swapped Number of requests swapped to CPU.
# TYPE vllm:num_requests_swapped gauge
vllm:num_requests_swapped{model_name="/mnt/Qwen1.5-14B-Chat/"} 0.0
# HELP vllm:num_requests_waiting Number of requests waiting to be processed.
# TYPE vllm:num_requests_waiting gauge
vllm:num_requests_waiting{model_name="/mnt/Qwen1.5-14B-Chat/"} 0.0
# HELP vllm:gpu_cache_usage_perc GPU KV-cache usage. 1 means 100 percent usage.
# TYPE vllm:gpu_cache_usage_perc gauge
vllm:gpu_cache_usage_perc{model_name="/mnt/Qwen1.5-14B-Chat/"} 0.0
# HELP vllm:cpu_cache_usage_perc CPU KV-cache usage. 1 means 100 percent usage.
# TYPE vllm:cpu_cache_usage_perc gauge
vllm:cpu_cache_usage_perc{model_name="/mnt/Qwen1.5-14B-Chat/"} 0.0
# HELP vllm:prompt_tokens_total Number of prefill tokens processed.
# TYPE vllm:prompt_tokens_total counter
vllm:prompt_tokens_total{model_name="/mnt/Qwen1.5-14B-Chat/"} 0.0
# HELP vllm:generation_tokens_total Number of generation tokens processed.
...

This raises two issues:

The local deployment path of the model is inadvertently revealed,  this is a high risk;
The model_name in metrics does not correspond to the model name provided in ModelCard by openai.api_server.

This PR solves the problem, by passing the served_model_name parameter into ModelConfig and parsing it in the LLMEngine. For scenarios not using openai.apiserver, served_model_name can also be passed to AsyncEngineArgs/EngineArgs. And when served_model_name parameter is not specified, the Prometheus metrics output will behave as before (although I still do not recommend this).

Thanks for suggestions @njhill!
I agree moving served_model_name to EngineArgs is a more elegant way and has less impact on the other parts.  In addition, this parameter should support either list or str.
The latest update contains:

Move served_model_name to EngineArgs
Support served_model_name as type list or str
Add descriptions for this parameter
Add test case in test_metrics.py

Thank you again for the suggestions @njhill !😊


Inconsistent support for empty matrices in linalg

Some functions in scipy.linalg handle empty matrix arguments and some don't - there doesn't seem to be an obvious pattern. On the other hand, numpy.linalg seems to support empty matrices in all functions (though I didn't test exhaustively).
For example, solve and cholesky both support empty matrices by explicitly handling empty matrix arguments before calling LAPACK:
>>> import numpy as np
>>> from scipy import linalg
>>> a = np.array([]).reshape((0, 0))
>>> linalg.solve(a, a)
array([], shape=(0, 0), dtype=float64)
>>>  linalg.cholesky(a)
array([], shape=(0, 0), dtype=float64)

while inv and most other functions don't:
>>> linalg.inv(a)

Traceback (most recent call last):
  File "...\.venv\Lib\site-packages\IPython\core\interactiveshell.py", line 3433, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-12-8c6d9a341a08>", line 1, in <module>
    linalg.inv(a)
  File "...\.venv\Lib\site-packages\scipy\linalg\_basic.py", line 958, in inv
    raise ValueError('illegal value in %d-th argument of internal '
ValueError: illegal value in 4-th argument of internal getrf|getri

Empty matrix support can be convenient when matrix sizes are determined dynamically, for example, according to statistical significance tests.

Agreed. This is something we should consider breaking backwards compatibility to attain a consistent implementation. Edge cases had been our soft spot in linalg for such functions that grew a bit heterogeneously.

I'm interested in looking into this issue. From what I can tell the cholesky decomp function returns an empty array of the same size. This seems like it would also serve as a valid return for the inverse function right?
Also, Iĺl look into other functions that could benefit from empty matrix support that do not already implement it.

I'm interested in looking into this issue. From what I can tell the cholesky decomp function returns an empty array of the same size. This seems like it would also serve as a valid return for the inverse function right?

Yup, it should just be an array of the same (zero size) dimensions as the input.
I think either solve or cholesky could be used for reference. For functions like inv, the result should be consistent with the result from the corresponding function in numpy.

Hi @boatwrong, thanks for working on this. I should have some free time over the next couple of weeks, so if you want I'd be happy to continue from where you left off.

@JosefKutas Apologies for my late response, thank you for reaching out and looking into this! Please feel free to continue on.
What you’ve explained/written looks great and I appreciate you taking it further than I could.

From: Jozsef Kutas @.>
Sent: Wednesday, June 7, 2023 18:23
To: scipy/scipy @.>
Cc: boatwrong @.>; Mention @.>
Subject: Re: [scipy/scipy] Inconsistent support for empty matrices in linalg (Issue #17658)
Hi @boatwronghttps://github.com/boatwrong, thanks for working on this. I should have some free time over the next couple of weeks, so if you want I'd be happy to continue from where you left off.
—
Reply to this email directly, view it on GitHubhttps://github.com/scipy/scipy/issues/17658#issuecomment-1581648098, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUUREPEXPWJU422HRC7XIP3XKEENLANCNFSM6AAAAAATJ6YOQU.
You are receiving this because you were mentioned.Message ID: @.***>


Remove --bs-headings-color CSS variable due to backward compatibility issues

Fixes #36365.
The null value breaks existing styling where hyperlinks with a heading helper class no longer appear blue. This will have to be resolved most likely in v6 I'd think to avoid any other BC issues.

Cannot check right now but couldn't a fallback value be a better fix? Something like var(--bs-heading-color, inherit) — to be tested, could be currentcolor or explicitly using body color too.

Any fallback like that presents the same issue unfortunately—links with .h1 would appear dark gray instead of Bootstrap blue as it'd be inheriting from the body.

Usually not in favor of using element and class selectors, but not sure to have a better solution.
There're at least two ways I can think of:

using the :any-link pseudo-class which would feel a bit more elegant than element selector—but wouldn't differ that much;
using a custom cascade based on custom properties, e.g. var(--bs-link-color, var(--bs-heading-color)) which would ensure the first get applied.

I can't find any other way around for now. Andy thought?

Hmm... for the second option, both values are always set (globally), so not sure a custom cascade would help much?

Uh, you're right. I don't think it's safe to move --bs-link-color to links reboot, sadly, since it could be used on other elements than links.
I can't find any other way. Let's go for a.hn then?

For now, going to outright remove this one. We can circle back on a new variable when we're able.


How to use tensorboard

My tensorboard is blank.
I use conda, not tensorflow installed using pip. I thought at first that it was my tensorflow and tensorboard version issues. I dealt with it for a long time until I successfully started tensorboard on another tensorflow program. I found that it is not a version issue.
What should I do with this issue, this program must be running in version 1.0.0? It seems that now the conda minimum version of tensor is 1.0.1, and I should

I can see the graphs while/after training, but I can't playback the sounds after generating. It always shows 3 audio players, but none of them work.


Upgrade DataFusion version

This PR upgrades to a recent version of DataFusion. There are two changes in DataFusion that had to be addressed here:

get_table_provider now returns a logical TableSource instead of a physical TableProvider
Joins now support filter conditions other than equi-join conditions

Changes in this PR:

Remove DaskTableProvider
Update join_condition() to handle all filter conditions

@jdye64 Please take a look when you get a chance

Codecov Report

:exclamation: No coverage uploaded for pull request base (datafusion-sql-planner@0c30a7b). Click here to learn what that means.
The diff coverage is n/a.

@@                    Coverage Diff                    @@
##             datafusion-sql-planner     #566   +/-   ##
=========================================================
  Coverage                          ?   58.86%
=========================================================
  Files                             ?       72
  Lines                             ?     3559
  Branches                          ?      720
=========================================================
  Hits                              ?     2095
  Misses                            ?     1334
  Partials                          ?      130

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Package Installation Issue

Steps to reproduce

Attempt to install via "python3 -m poetry add hikari"

Expected Result

Successful installation of the package.
Actual Result

Unsuccessful installation of the package.
--> python3 -m poetry add hikari
Using version ^2.0.0-alpha.103 for hikari

Updating dependencies
Resolving dependencies...

  SolverProblemError

  The current project's Python requirement (>=3.8,<4.0) is not compatible with some of the required packages Python requirement:
    - hikari requires Python >=3.8.0,<3.11, so it will not be satisfied for Python >=3.11,<4.0

  Because no versions of hikari match >2.0.0-alpha.103,<3.0.0
   and hikari (2.0.0.dev103) requires Python >=3.8.0,<3.11, hikari is forbidden.
  So, because repl-python3-rectangularfortunatedesigners depends on hikari (^2.0.0-alpha.103), version solving failed.

  at /opt/virtualenvs/python3/lib/python3.8/site-packages/poetry/puzzle/solver.py:241 in _solve
      237│             packages = result.packages
      238│         except OverrideNeeded as e:
      239│             return self.solve_in_compatibility_mode(e.overrides, use_latest=use_latest)
      240│         except SolveFailure as e:
    → 241│             raise SolverProblemError(e)
      242│
      243│         results = dict(
      244│             depth_first_search(
      245│                 PackageNode(self._package, packages), aggregate_package_nodes

  • Check your dependencies Python requirement: The Python requirement can be specified via the `python` or `markers` properties

    For hikari, a possible solution would be to set the 'python' property to ">=3.8,<3.11"

    https://python-poetry.org/docs/dependency-specification/#python-restricted-dependencies,
    https://python-poetry.org/docs/dependency-specification/#using-environment-markers
exit status 1

System info

Python 3.8.2
Further info

Easy to consistently replicate on replit.com.
Checklist

[X] I have made sure to remove ANY sensitive information (bot token, passwords,
credentials, personal details, etc).
[X] I have searched the issue tracker and have made sure it's not a duplicate.
If it is a follow up of another issue, I have specified it.

This is not really a bug but it is caused by something we did intentionally. We top cap the maximum python version we support to the latest available. This is done to ensure compatibility throughout all python versions we support. In poetry, specifying ^3.8 will be translated to >=3.8,<4.0, but hikari only (as of current releases version) allows only until 3.10.
You will have to set your python version in poetry to >=3.8,<3.11 to allow it to install.

I understand it's not a bug, just figured I should inform you about it in case it was not intentional.  Since it is I'll close the issue.


test(typescript): verify subextensions work

test for https://github.com/esbuild-kit/esm-loader/issues/20

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Enable spell check for all files and fix

fix #2776

:x: There is undocummented changes. Run chronus add to add a changeset or click here.
The following packages have changes but are not documented.

:x:@typespec/http

You can try these changes at https://cadlplayground.z22.web.core.windows.net/prs/2881/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/prs/2881/


Lib JSON misbehaving

Discussed in https://github.com/zephyrproject-rtos/zephyr/discussions/79017

Describe the bug
Originally posted by ofirshe September 25, 2024
Hey,
I recently conducted a test and encountered an issue with the JSON encoding in my application, and I would appreciate your assistance. Below is a snippet of my code:
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <stdbool.h>
#include <zephyr/data/json.h>

#define REGULATOR_NUM_DEVICES 17

/* Regulator */
typedef struct regulator_stats
{
    /* Voltage, in millivolts */
    bool is_read_vout_supported;
    int32_t last_voltage_mv;
    int32_t max_voltage_mv;
    int32_t min_voltage_mv;

    /* Current, in milliamperes */
    bool is_read_iout_supported;
    int32_t last_current_ma;
    int32_t max_current_ma;
    int32_t min_current_ma;

    uint32_t last_measurement_from_uptime_ms;
} regulator_stats_t;

static const struct json_obj_descr regulator_stats_json_description[] =
{
    /* Voltage */
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, is_read_vout_supported, JSON_TOK_TRUE),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, last_voltage_mv, JSON_TOK_NUMBER),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, max_voltage_mv, JSON_TOK_NUMBER),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, min_voltage_mv, JSON_TOK_NUMBER),

    /* Current */
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, is_read_iout_supported, JSON_TOK_TRUE),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, last_current_ma, JSON_TOK_NUMBER),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, max_current_ma, JSON_TOK_NUMBER),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, min_current_ma, JSON_TOK_NUMBER),

    JSON_OBJ_DESCR_PRIM(struct regulator_stats, last_measurement_from_uptime_ms, JSON_TOK_NUMBER),
};

struct my_struct
{
    regulator_stats_t regulator_devices_stats_arr[REGULATOR_NUM_DEVICES];
    uint32_t regulator_devices_stats_arr_len;
};

static struct my_struct ms;

static const struct json_obj_descr ms_desc[] =
{
    /* Regulator Devices Stats */
    JSON_OBJ_DESCR_OBJ_ARRAY(struct my_struct, regulator_devices_stats_arr, REGULATOR_NUM_DEVICES,
                regulator_devices_stats_arr_len, regulator_stats_json_description,
                ARRAY_SIZE(regulator_stats_json_description)),
};

int main()
{
	int i;
	ssize_t encoded_len;
	char buffer[8192] = { 0 };

	for (i = 0; i < REGULATOR_NUM_DEVICES; i++)
	{
		ms.regulator_devices_stats_arr[i].is_read_vout_supported = ms.regulator_devices_stats_arr[i].is_read_iout_supported = false;
		ms.regulator_devices_stats_arr[i].max_voltage_mv = ms.regulator_devices_stats_arr[i].max_current_ma = INT32_MIN;
		ms.regulator_devices_stats_arr[i].min_voltage_mv = ms.regulator_devices_stats_arr[i].min_current_ma = INT32_MAX;
		ms.regulator_devices_stats_arr[i].last_voltage_mv = ms.regulator_devices_stats_arr[i].last_current_ma = 0;
		ms.regulator_devices_stats_arr[i].last_measurement_from_uptime_ms = 0;
	}
	ms.regulator_devices_stats_arr_len = REGULATOR_NUM_DEVICES;
	encoded_len = json_calc_encoded_len(ms_desc, ARRAY_SIZE(ms_desc), &ms);
	if (encoded_len < 0)
	{
		printf("failed to calculate the string length of the encoded json; rc = %d", encoded_len);
		return -1;
	}
	json_obj_encode_buf(ms_desc, ARRAY_SIZE(ms_desc), &ms, buffer, sizeof(buffer));
	printf("%s\n", buffer);

	return 0;
}

To run the application, I use the following configurations: CONFIG_MAIN_STACK_SIZE=131072 and CONFIG_JSON_LIBRARY=y.
The console output shows that the first device is encoded correctly, but the values for the subsequent devices become corrupted and shift between fields:
{"regulator_devices_stats_arr":[{"is_read_vout_supported":false,"last_voltage_mv":0,"max_voltage_mv":-2147483648,"min_voltage_mv":2147483647,"is_read_iout_supported":false,"last_current_ma":0,"max_current_ma":-2147483648,"min_current_ma":2147483647,"last_measurement_from_uptime_ms":0},
								{"is_read_vout_supported":false,"last_voltage_mv":0,"max_voltage_mv":0,"min_voltage_mv":-2147483648,"is_read_iout_supported":true,"last_current_ma":0,"max_current_ma":0,"min_current_ma":-2147483648,"last_measurement_from_uptime_ms":2147483647},
								{"is_read_vout_supported":true,"last_voltage_mv":0,"max_voltage_mv":0,"min_voltage_mv":0,"is_read_iout_supported":false,"last_current_ma":2147483647,"max_current_ma":0,"min_current_ma":0,"last_measurement_from_uptime_ms":-2147483648},
								{"is_read_vout_supported":false,"last_voltage_mv":2147483647,"max_voltage_mv":0,"min_voltage_mv":0,"is_read_iout_supported":false,"last_current_ma":-2147483648,"max_current_ma":2147483647,"min_current_ma":0,"last_measurement_from_uptime_ms":0},
								{"is_read_vout_supported":false,"last_voltage_mv":-2147483648,"max_voltage_mv":2147483647,"min_voltage_mv":0,"is_read_iout_supported":false,"last_current_ma":0,"max_current_ma":-2147483648,"min_current_ma":2147483647,"last_measurement_from_uptime_ms":0},
								{"is_read_vout_supported":false,"last_voltage_mv":0,"max_voltage_mv":-2147483648,"min_voltage_mv":2147483647,"is_read_iout_supported":false,"last_current_ma":0,"max_current_ma":0,"min_current_ma":-2147483648,"last_measurement_from_uptime_ms":2147483647},
								{"is_read_vout_supported":true,"last_voltage_mv":0,"max_voltage_mv":0,"min_voltage_mv":-2147483648,"is_read_iout_supported":true,"last_current_ma":0,"max_current_ma":0,"min_current_ma":0,"last_measurement_from_uptime_ms":-2147483648},
								{"is_read_vout_supported":false,"last_voltage_mv":2147483647,"max_voltage_mv":0,"min_voltage_mv":0,"is_read_iout_supported":false,"last_current_ma":2147483647,"max_current_ma":0,"min_current_ma":0,"last_measurement_from_uptime_ms":0},
								{"is_read_vout_supported":false,"last_voltage_mv":-2147483648,"max_voltage_mv":2147483647,"min_voltage_mv":0,"is_read_iout_supported":false,"last_current_ma":-2147483648,"max_current_ma":2147483647,"min_current_ma":0,"last_measurement_from_uptime_ms":0},
								{"is_read_vout_supported":false,"last_voltage_mv":0,"max_voltage_mv":-2147483648,"min_voltage_mv":2147483647,"is_read_iout_supported":false,"last_current_ma":0,"max_current_ma":-2147483648,"min_current_ma":2147483647,"last_measurement_from_uptime_ms":0},
								{"is_read_vout_supported":false,"last_voltage_mv":0,"max_voltage_mv":0,"min_voltage_mv":-2147483648,"is_read_iout_supported":true,"last_current_ma":0,"max_current_ma":0,"min_current_ma":-2147483648,"last_measurement_from_uptime_ms":2147483647},
								{"is_read_vout_supported":true,"last_voltage_mv":0,"max_voltage_mv":0,"min_voltage_mv":0,"is_read_iout_supported":false,"last_current_ma":2147483647,"max_current_ma":0,"min_current_ma":0,"last_measurement_from_uptime_ms":-2147483648},
								{"is_read_vout_supported":false,"last_voltage_mv":2147483647,"max_voltage_mv":0,"min_voltage_mv":0,"is_read_iout_supported":false,"last_current_ma":-2147483648,"max_current_ma":2147483647,"min_current_ma":0,"last_measurement_from_uptime_ms":0},
								{"is_read_vout_supported":false,"last_voltage_mv":-2147483648,"max_voltage_mv":2147483647,"min_voltage_mv":0,"is_read_iout_supported":false,"last_current_ma":0,"max_current_ma":-2147483648,"min_current_ma":2147483647,"last_measurement_from_uptime_ms":0},
								{"is_read_vout_supported":false,"last_voltage_mv":0,"max_voltage_mv":-2147483648,"min_voltage_mv":2147483647,"is_read_iout_supported":false,"last_current_ma":0,"max_current_ma":0,"min_current_ma":-2147483648,"last_measurement_from_uptime_ms":2147483647},
								{"is_read_vout_supported":true,"last_voltage_mv":0,"max_voltage_mv":0,"min_voltage_mv":-2147483648,"is_read_iout_supported":true,"last_current_ma":0,"max_current_ma":0,"min_current_ma":0,"last_measurement_from_uptime_ms":-2147483648},
								{"is_read_vout_supported":false,"last_voltage_mv":2147483647,"max_voltage_mv":0,"min_voltage_mv":0,"is_read_iout_supported":false,"last_current_ma":2147483647,"max_current_ma":0,"min_current_ma":0,"last_measurement_from_uptime_ms":0}]}

I am unsure if this is an issue with my implementation or a potential problem with the library. I am currently using the latest changes in the JSON library 878640f.
To Reproduce
Run the code snippet I attached above and check the console output to observe that the encoded output is incorrect. To run the application, I'm using the following configurations: CONFIG_MAIN_STACK_SIZE=131072 and CONFIG_JSON_LIBRARY=y
Expected behavior
I expected all 17 devices to be initialized with identical values like this:
{"is_read_vout_supported":false,"last_voltage_mv":0,"max_voltage_mv":-2147483648,"min_voltage_mv":2147483647,"is_read_iout_supported":false,"last_current_ma":0,"max_current_ma":-2147483648,"min_current_ma":2147483647,"last_measurement_from_uptime_ms":0}
Environment:
OS: Windows
Toolchain: Zephyr SDK
Version used: 3.7.99
Additional context
When I add __attribute__((packed, aligned(1))) to the struct regulator_stats, the issue gets resolved. However, I don't see any indication in the library that requires all structs to be packed. I also checked the Zephyr json test source file, and none of the structs there are packed either.
Best regards.

Hey,
When I add attribute((packed, aligned(1))) to the struct regulator_stats, the issue gets resolved. However, I don't see any indication in the library that requires all structs to be packed. I also checked the Zephyr json test source file, and none of the structs there are packed either.

Please use our bug template when reporting bugs. You need to edit this issue to include the information requested in https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/001_bug_report.md

@cfriedt, I have aligned with the bug template.

Hi,
Could someone kindly help with this? We're utilizing JSON encoding extensively in our application, and it appears there's a problem with the encoding.
Any assistance would be greatly appreciated.

@ofirshe - the main stack size is gigantic. You should be able to do what you need to with a stack size of maybe 4096 bytes (just a guess).
Also, the 8k buffer is larger than most stack sizes in Zephyr. Consider making it static, or allocating it from the heap?

Hi @cfriedt,
You're right—the current approach isn't clean. Allocating this buffer on the stack isn't ideal, and I agree with your point about the main stack size; I just set an arbitrary number to avoid stack corruption. However, even if you move the buffer to the data segment, the same issue with the JSON encoding persists.

Hi,
Could someone kindly take a look at the JSON encoding issue I'm experiencing?
Thanks again.

Hi,
I recently pulled the latest json.c and json.h files from the Zephyr project based on commit 03029e7bd7, and created a basic application outside of the Zephyr OS. I ran the application on Linux and encountered the same issue as described previously.
And again, I found that adding __attribute__((packed, aligned(1))) to the regulator_stats struct resolves the issue.
To replicate this, you can clone the project, run make to compile, and execute ./main to see the result.
json_encoding_failure_app.zip
Best regards,
Ofir.

Hi @cfriedt,
I experimented with various permutations of the field order in the regulator_stats struct and found that the following order works without the need for the packed attribute:
typedef struct regulator_stats
{
    /* Voltage, in millivolts */
    int32_t last_voltage_mv;
    int32_t max_voltage_mv;
    int32_t min_voltage_mv;

    /* Current, in milliamperes */
    int32_t last_current_ma;
    int32_t max_current_ma;
    int32_t min_current_ma;
    bool is_read_iout_supported;
    bool is_read_vout_supported;

    uint32_t last_measurement_from_uptime_ms;
} regulator_stats_t;

Regardless of alignment considerations, the JSON library should support any valid field order and type combination, as long as the types are documented as supported. Since the documentation doesn’t mention any restrictions, this behavior appears to be unintended.

I experimented with various permutations of the field order in the regulator_stats struct and found that the following order works without the need for the packed attribute:

My first guess is that this would work as well.
typedef struct regulator_stats
{
     /* Voltage, in millivolts */
     int32_t last_voltage_mv;
     int32_t max_voltage_mv;
     int32_t min_voltage_mv;
     bool is_read_vout_supported;

     /* Current, in milliamperes */
     int32_t last_current_ma;
     int32_t max_current_ma;
     int32_t min_current_ma;
     bool is_read_iout_supported;

     uint32_t last_measurement_from_uptime_ms;
} regulator_stats_t;

Regardless of alignment considerations, the JSON library should support any valid field order and type combination.

Maybe.
I'm not incredibly familiar with the JSON lib, but it might do what is relatively normal in C functions when given a pointer, which is assume that the target of the pointer is naturally aligned. Some architectures with certain micro-architectural enhancements are able to catch this and perform an unaligned fetch. However, others cannot - many in the embedded space. So expecting the JSON library (effectively the compiler) to detect and (actually) un-optimize for that use case might not be very tenable. It might be possible, but could require a lot of work / redesign of the macro system.
I would guess the easiest thing to do would be to trigger a BUILD_ASSERT() when struct members are not naturally aligned.

Hi @cfriedt,
In case no attributes are applied to the struct, I believe the compiler should automatically enforce proper alignment by adding any necessary padding between fields. To verify this, I added a check for the alignment of each field, and indeed, every field address was aligned to a 4-byte boundary—no alignment issues were detected. This leads me to believe that alignment isn't the problem here.
Below is the modified loop, where I also checked the field addresses:
    for (i = 0; i < REGULATOR_NUM_DEVICES; i++)
    {
        // Initialize values
        ms.regulator_devices_stats_arr[i].is_read_vout_supported = ms.regulator_devices_stats_arr[i].is_read_iout_supported = false;
        ms.regulator_devices_stats_arr[i].max_voltage_mv = ms.regulator_devices_stats_arr[i].max_current_ma = INT32_MIN;
        ms.regulator_devices_stats_arr[i].min_voltage_mv = ms.regulator_devices_stats_arr[i].min_current_ma = INT32_MAX;
        ms.regulator_devices_stats_arr[i].last_voltage_mv = ms.regulator_devices_stats_arr[i].last_current_ma = 0;
        ms.regulator_devices_stats_arr[i].last_measurement_from_uptime_ms = 0;

        // Get the start address of the struct
        uintptr_t struct_addr = (uintptr_t)&ms.regulator_devices_stats_arr[i];
        printf("Start address of regulator_stats[%d]: %p\n", i, (void*)struct_addr);

        // Check alignment of every field in the struct
        uintptr_t addr_is_read_vout_supported = (uintptr_t)&ms.regulator_devices_stats_arr[i].is_read_vout_supported;
        uintptr_t addr_last_voltage_mv = (uintptr_t)&ms.regulator_devices_stats_arr[i].last_voltage_mv;
        uintptr_t addr_max_voltage_mv = (uintptr_t)&ms.regulator_devices_stats_arr[i].max_voltage_mv;
        uintptr_t addr_min_voltage_mv = (uintptr_t)&ms.regulator_devices_stats_arr[i].min_voltage_mv;
        uintptr_t addr_is_read_iout_supported = (uintptr_t)&ms.regulator_devices_stats_arr[i].is_read_iout_supported;
        uintptr_t addr_last_current_ma = (uintptr_t)&ms.regulator_devices_stats_arr[i].last_current_ma;
        uintptr_t addr_max_current_ma = (uintptr_t)&ms.regulator_devices_stats_arr[i].max_current_ma;
        uintptr_t addr_min_current_ma = (uintptr_t)&ms.regulator_devices_stats_arr[i].min_current_ma;
        uintptr_t addr_last_measurement_from_uptime_ms = (uintptr_t)&ms.regulator_devices_stats_arr[i].last_measurement_from_uptime_ms;

        // Check alignment for 4-byte boundaries (for int32_t and bool fields)
        if (addr_is_read_vout_supported % 4 != 0)
            printf("Error: regulator_stats[%d].is_read_vout_supported at %p is not aligned\n", i, (void*)addr_is_read_vout_supported);
        if (addr_last_voltage_mv % 4 != 0)
            printf("Error: regulator_stats[%d].last_voltage_mv at %p is not aligned\n", i, (void*)addr_last_voltage_mv);
        if (addr_max_voltage_mv % 4 != 0)
            printf("Error: regulator_stats[%d].max_voltage_mv at %p is not aligned\n", i, (void*)addr_max_voltage_mv);
        if (addr_min_voltage_mv % 4 != 0)
            printf("Error: regulator_stats[%d].min_voltage_mv at %p is not aligned\n", i, (void*)addr_min_voltage_mv);
        if (addr_is_read_iout_supported % 4 != 0)
            printf("Error: regulator_stats[%d].is_read_iout_supported at %p is not aligned\n", i, (void*)addr_is_read_iout_supported);
        if (addr_last_current_ma % 4 != 0)
            printf("Error: regulator_stats[%d].last_current_ma at %p is not aligned\n", i, (void*)addr_last_current_ma);
        if (addr_max_current_ma % 4 != 0)
            printf("Error: regulator_stats[%d].max_current_ma at %p is not aligned\n", i, (void*)addr_max_current_ma);
        if (addr_min_current_ma % 4 != 0)
            printf("Error: regulator_stats[%d].min_current_ma at %p is not aligned\n", i, (void*)addr_min_current_ma);
        if (addr_last_measurement_from_uptime_ms % 4 != 0)
            printf("Error: regulator_stats[%d].last_measurement_from_uptime_ms at %p is not aligned\n", i, (void*)addr_last_measurement_from_uptime_ms);
    }

Furthermore, to support my assumption, when the packed attribute is used, the JSON encoding works despite the compiler not adding padding, which results in unaligned access for some fields.
As mentioned earlier, the JSON library should support any valid field order and type combination as long as the types are documented as supported. Since no restrictions are mentioned in the documentation, this issue seems unintended. Would you know who might be able to assist in resolving this?

In that case, I would agree - there likely is something wrong with the JSON library.

Thanks, @cfriedt. I'm also not very familiar with the code within that library; @d3zd3z, could you please assist in resolving this issue? It appears to be a core problem with the library that shouldn't be overlooked.

I believe I've identified the problem. It indeed relates to alignment issues.
For this struct and its JSON description:
typedef struct regulator_stats {
    /* Voltage, in millivolts */
    bool is_read_iout_supported;
    int32_t last_voltage_mv;
    int32_t max_voltage_mv;
    int32_t min_voltage_mv;

    /* Current, in milliamperes */
    bool is_read_vout_supported;
    int32_t last_current_ma;
    int32_t max_current_ma;
    int32_t min_current_ma;

    uint32_t last_measurement_from_uptime_ms;
} regulator_stats_t;

static const struct json_obj_descr regulator_stats_json_description[] = {
    /* Voltage */
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, is_read_vout_supported, JSON_TOK_TRUE),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, last_voltage_mv, JSON_TOK_NUMBER),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, max_voltage_mv, JSON_TOK_NUMBER),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, min_voltage_mv, JSON_TOK_NUMBER),

    /* Current */
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, is_read_iout_supported, JSON_TOK_TRUE),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, last_current_ma, JSON_TOK_NUMBER),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, max_current_ma, JSON_TOK_NUMBER),
    JSON_OBJ_DESCR_PRIM(struct regulator_stats, min_current_ma, JSON_TOK_NUMBER),

    JSON_OBJ_DESCR_PRIM(struct regulator_stats, last_measurement_from_uptime_ms, JSON_TOK_NUMBER),
};

The get_elem_size() function retrieves a size of 32, while the actual size is 36.
If we break it down in terms of potential memory layout, it would look something like this:

bool is_read_iout_supported (1 byte)
Padding (3 bytes)
int32_t last_voltage_mv (4 bytes)
int32_t max_voltage_mv (4 bytes)
int32_t min_voltage_mv (4 bytes)
bool is_read_vout_supported (1 byte)
Padding (3 bytes)
int32_t last_current_ma (4 bytes)
int32_t max_current_ma (4 bytes)
int32_t min_current_ma (4 bytes)
uint32_t last_measurement_from_uptime_ms (4 bytes)

The total would be: 1 + 3 + 4 + 4 + 4 + 1 + 3 + 4 + 4 + 4 + 4 = 36.
It seems that the get_elem_size() function does not account for the padding between the fields.

@cfriedt @d3zd3z Should I create a new issue that summarizes all the messages from this current discussion, to make the problem I found more concrete and focused (and close this one)?

@ofirshe - you can probably update your summary here. No need to create a new issue.

@cfriedt I edited the main post.

Hi,
Could someone please assist in resolving this issue? I use the JSON library extensively, and I'm concerned that this problem may be affecting other parts of my application as well.

@ofirshe - can you make a pull request to fix the issue?

Hey @cfriedt,
I'm not very familiar with the library's code and am unsure how best to address this edge case. Given its complexity, I believe someone with more experience in the codebase would be better suited to handle it.

@ofirshe - ok.
The issue has low priority, and there are workarounds. The maintainer likely will get to it eventually.
Thanks for your patience.

Hey @cfriedt,
Is there a chance this issue will be addressed soon? It seems quite tricky, and developers who aren’t careful about alignment issues might run into hidden problems with the JSON library.

@d3zd3z ?

@cfriedt @d3zd3z ?

Hello @cfriedt,
As mentioned earlier, those who are not careful with alignment issues might run into subtle problems with the JSON library. I'm not sure if a workaround exists, as you suggested here.
Would it be possible for someone else to take a look at this? I noticed from git blame that many others were involved in the development of the library. Is there someone you would recommend who could assist?
Best regards,
Ofir.

Definitely the assignee is the best for now, since @d3zd3z is the maintainer. You could 'at' others who have worked on JSON potentially here to attract attention and maybe another person could help.


WIP: Project management

This PR is where I'm tracking modifications to project management. Done so far:

[X] Refactor project listening into new autoload script
[X] Maintain a list of projects which have been loaded for the solution (when a solution exists)

The list of projects can be used to display "server loading progress" in the statusline - here's an example using vim-sharpenup, PR#4:

Things I hope to achieve here:

[X] Detect whether the server is the OmniSharp-rolsyn HTTP server when stdio was expected, so we can warn the user, ~then change mode~. This will allow us to make stdio the default in a backwards-compatible way.
Update: I looked into restarting the server in HTTP mode, but it requires too many changes for little gain. The entire session is set up either for HTTP or stdio including autocmds for linting engines and compatibility checks. Detecting the wrong server and stopping it cleanly with a warning message is fine.
[x] Improve the load system so that highlighting/completion etc. become available as soon as the current project is loaded. Diagnostics will still warn of unloaded references, and definitions in unloaded projects will not be available until those projects are loaded etc.

Note: the final point hopefully encompasses a fix for #599 Update: it does not, #599 is a WSL bug and will be fixed on the OmniSharp-roslyn side.
Closes #468
Update: Since looking into the project loading mechanisms involves heavy use of the logs, I have included some other updates here that make this a bit more manageable:

[X] Give each OmniSharp-roslyn session its own log file. This means that a single vim session may be writing to multiple logs, if it is running multiple sessions. The old "stdio.log" file is still used as a global catchall - the filename of each session log is added to it, so it is possible to gf into actual log files from there.
[x] Format the log in a similar way to the VSCode formatting, making it actually readable - the raw JSON is extremely difficult to find relevant information in.
[X] Add new filetype and syntax for the logs, including folding raw requests/responses (when logging at debug level).

Status update: 4f2e069 is a very different approach to project loading, and works really well - highlighting, for example, is available very quickly, and no errors are received from the server. Request-replaying also works much better, as pending requests are saved per-buffer, instead of per-command, meaning that 2 buffers can have pending highlighting requests replayed as soon as their buffers are initialised.
However there are some diagnostic timeouts happening on the server which I believe are new, and diagnostics appear to take longer now than before. So I'll look into this before merging.


Update Move-CsUser.md to address minimum MicrosoftTeams module versio…

…n requirement
We have introduced some changes on cmdlets available in MicrosoftTeams module to deprecate some left out functionality as part of SFBO infra decoupling.

@VikneshMSFT - approved


Fix view change deadlock, caused by confusion of S and S prime

In the view change code, the matching checkpoint sets S' was being used instead of the view change set S.
Because of this, view change was requiring 2f+1 low watermarks at or below the sequence number within the checkpoint set, when this needs to be considered over the whole view change set.  This could lead to a scenario where view change never completes, and the network locks up, view changing indefinitely.
This changeset fixes this behavior, and includes a test which verifies its correctness.
It also includes a fix for another observed deadlock in which the executor thread attempts to deliver a checkpoint while the pbft message thread attempts to initiate state transfer.
Finally, this changeset also causes the 'fall behind' recovery to mark the current view as active.  The correctness fo this should be verified with PBFT protocol experts, and it is flagged as such in the code, but otherwise could cause a replica to fail to rejoin a network if its view change timer expires before realizing it is behind.
All of these fixes have been verified to help address the stress related problems observed in #920, #917, #793, and #699
Passes all go tests.
Passes all behave tests.
Signed-off-by: Jason Yellick<EMAIL_ADDRESS>

LGTM. Also confirmed unit and behave tests are passing.

FWIW, I also confirm that the view-change modification makes sense.


FolderChooserDialog title

Pls add setTitle to FolderChooserDialog.
Ty!

It purposely displays the current folder, I do not plan to allow changing that.


Added Nebula Crowdsale contract ABI

Hi, Please accept my modification about nebula ai crowdsale address, there was a mistake in it. I appologize for the inconvience. Also could you please tell me when would the contract visible on the website under "Select Existing Contract" dropdown list. Thank you very much
Best
Tony

@tpang-nebula-ai Thanks for updating it. It should will show up in the next release.


[Change request to #2379] "Екомагазин" section

Description of a Change request:
The Number of characters in the field "Order number" in section "Eco-shop"
Reason for Change:
Improvements of the Order Form after customer reviews.
Acceptance Criteria

Under the bonus section, the user shall see the section "Екомагазин" and the statement ”Якщо Ви чекаєте замовлення з нашого Екомагазину, будь ласка введіть номер замовлення" and the field "Номер замовлення".

Validation of the shop order number – the format  from 1 to 8 symbols and the user can’t type more than 8 symbols  in the shop order input field.  When the user enters more than 8 symbols  the system shall display the error message to the user: "Номер введено невірно. Спробуйте ще раз" (Eng. "The number was entered incorrectly. Please try again."), the "Next" button is disabled and user can not go to the next page.
User can not enter similar order numbers in the fields "Order number"

Impact of Change
This change request affects 1 change request:
[Change request to #2196] Order form – step 1 #2379.
Epic: EPIC: UBS courier #2195

Duplicate to https://github.com/ita-social-projects/GreenCity/issues/6006


Coastal erosion notebook fail

The deafrica_spatialtools.py library has changed, leading to the Coastal_erosion.ipynb notebook in Real_world_examples failing when trying to load contour_extract.

Solved by PR #56


Shivam Jha

Profile Screenshot

I guess this is not participating in Hacktober right

I guess this is not participating in Hacktober right

Yes, it will not be counted


[Feature Request]:

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
I want to add an access token and refresh token for smooth auth experiences kindly assign me this under GSSOC 24 @Trisha-tech.
Use Case
Improved Security: Access tokens and refresh tokens help in maintaining secure communication between the client and server by ensuring that only authenticated users can access protected resources. This reduces the risk of unauthorized access.
Seamless User Experience: By using tokens, you can implement automatic token refreshing without requiring users to log in repeatedly. This creates a more seamless and user-friendly experience.
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

Is there an existing issue for this?

[x]  I have searched the existing issues

Feature Description
I want to add an access token and refresh token for smooth auth experiences kindly assign me this under GSSOC 24 @Trisha-tech.
Use Case
Improved Security: Access tokens and refresh tokens help in maintaining secure communication between the client and server by ensuring that only authenticated users can access protected resources. This reduces the risk of unauthorized access.
Seamless User Experience: By using tokens, you can implement automatic token refreshing without requiring users to log in repeatedly. This creates a more seamless and user-friendly experience.
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[x]  I have read the Contributing Guidelines
[x]  I'm a GSSOC'24 contributor
[x]  I have starred the repository

Hello @Vinaysohaliya , Go for It
All the Best


AVRO-1542 replacing auto_ptr by unique_ptr & std::move

Please verify

addition of flags to CMakeLists.txt and
one case where auto_ptr was being passed by reference but is now changed to pass unique_ptr by value in lang/c++/impl/FileStream.cc  : 193

all tests passed in my local build

Thank you for your pull request. It looks good, but it makes new requirement that the compiler should support C++11, which we didn't have thus far. Since we already have a dependency on Boost and Boost has been having unique_ptr for a long time, instead of using std::unique_ptr if we use boost::unique_ptr, we won't be causing new incompatibility. Do you want to make such a change?

I am afraid I wont be able to get to this anytime soon.

Since #203 has been opened to address followup comments can this PR be closed?


Upload from travis-ci.com fails to detect service

Describe the bug
Following the instructions here in my travis-ci.com build, uploading the coverage report fails with an error about "Unable to detect service".
To Reproduce
Steps to reproduce the behavior:

Visit https://travis-ci.com/github/tagatac/bagoup/builds/234787055
Click on the arrow next to line 296.
Scroll down to line 337
See error "Unable to detect service, please specify manually."

Expected behavior
codecov uploads the coverage report without issue.
Additional context
Makefile target that generates this error at the commit that triggered the build referenced above: https://github.com/tagatac/bagoup/blob/14d7c0cb2349754a7f777f3abb50f90d43c9d313/Makefile#L36-L44

Related: #252 and #23

@drazisil-codecov will investigate tomorrow
In the meantime, can you check if the following envs appear in your build? https://github.com/codecov/uploader/blob/master/src/ci_providers/provider_travisci.ts#L4

https://app.travis-ci.com/github/tagatac/bagoup/builds/234788670
echo $CI
true
echo $TRAVIS
true
echo $SHIPPABLE

Don't you want SHIPPABLE to be false? That's what the legacy script is looking for: https://github.com/codecov/codecov-bash/blob/1817ab23d6b35ff6596e48d15db366b71f17ada3/codecov#L568

That's what I was wondering, but I was on mobile. At least we know the fix now.


Title: Adding BMI calculator project

Is your feature request related to a problem? Please describe.
BMI calculator is a basic project for understanding frontend technologies.
Describe the solution you'd like.
Adding BMI calculator in basic project section of web development
Describe alternatives you've considered.
N/A
Add any other context or screenshots about the feature request here.
N/A

Hey, I am interested in fixing this issue. could you please assign it to me?


Enable Registry Client Builder to be created from Base Client Builder

Summary

Addresses https://github.com/astral-sh/uv/issues/4330, to reduce duplication in the client creation logic.
Test Plan

WIP

I don't think you'll need a specific test plan for this one, it should be well covered by our existing tests.

Can't quite reproduce the error from CI locally...
error[E0425]: cannot find value `client_builder` in this scope
   --> crates/uv/src/commands/project/mod.rs:436:46
    |
436 |     let client = RegistryClientBuilder::from(client_builder)
    |                                              ^^^^^^^^^^^^^^ not found in this scope

Thank you!


[v4.0 Beta 17] - Android Editor Runs, But Crashes When Opening Project?

Godot version
v4.0 Beta 17 Android Editor
System information
Android Tablet / Android OS Version 9 / 3GB RAM
Issue description
Hi,
Tried running v4.0 Beta 17 Android editor on my Android tablet.
The IDE runs, but crashes when opening up a project?
The tablet has:

Android OS version 9
3GB RAM

What are the official system requirements for v4.0 Beta 17 Android editor on Android?
Let me know, thanks!
Jesse
Steps to reproduce
Open a project on the v4.0 Beta 17 Android editor on Android device - it crashes?
Minimal reproduction project
N/A

also crashes on my pc
Godot Engine v4.0.beta17.official.c40020513 - https://godotengine.org
OpenGL Renderer: NVIDIA GeForce GTX 1080/PCIe/SSE2
Editing project: F:/project mzd/godot/mzd
ERROR: Condition "!method" is true. Returning: 0
at: get_builtin_method_hash (core/variant/variant_call.cpp:1348)
ERROR: Error getting method typed_assign, hash mismatch.
at: gdextension_variant_get_ptr_builtin_method (core/extension/gdextension_interface.cpp:480)
ERROR: Condition "!method" is true. Returning: 0
at: get_builtin_method_hash (core/variant/variant_call.cpp:1348)
ERROR: Condition "!method" is true. Returning: 0
at: get_builtin_method_hash (core/variant/variant_call.cpp:1348)
Godot Engine v4.0.beta17.official.c40020513 - https://godotengine.org
Vulkan API 1.3.205 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1080

We are not talking about your pc - create a new bug report please

Tablet system specifications are attached

@BetaMaxHero Please upload a minimal reproduction project to make this easier to troubleshoot.
What's the name of the tablet device?

Hi,
Android tablet is below:
https://ivankyo.com/products/vankyo-matrixpad-s20-10-inch-android-tablet
Loading below project:
https://github.com/BetaMaxHero/GDScript_Godot_4_T-Story
Jesse

Sorry:
I opened Godot v4.0 Beta 17 Android editor and created a new project and changed to compatibility rendering.
Still crashes when opening the actual editor?
Jesse

Is there something I can do when running the editor to show debug info before it crashes?
Little lost here - please advise

Hi,
I tried the 4.0 RC1 Android editor on my new Samsung Galaxy S23 Ultra smartphone with 12GB RAM, runs fine.
(screen is too small to use - have poor eyesight)
I want to buy a new Android tablet soon to run Android editor.
How much RAM is required for Android editor to run?
(would 4GB RAM work?)
My old Android tablet with 3GB RAM did not run the Android editor.
Let me know, thanks!
Jesse

@BetaMaxHero This is not the channel to ask support questions. Use Discord or forums


Runescape keeps crashing and the log said to report it here

Please provide a brief summary of the bug
Runescape and a lot of my other games keep crashing while im playing for months now. Today I reinstalled windows and it is still happening. I attached some of the crash logs. Any help would be appreciated
jvm_crash_pid_3908.log
jvm_crash_pid_14932.log
Please provide steps to reproduce where possible
No response
Expected Results
Not to crash
Actual Results
Crash
What Java Version are you using?
java 8 update 371
What is your operating system and platform?
Runelite, Windows 10
How did you install Java?
From the website
Did it work before?
No

Did you test with the latest update version?
Yes

Did you test with other Java versions?
No

Relevant log output
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000025ce6e4c28e, pid=3908, tid=5616
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.19+7 (11.0.19+7) (build 11.0.19+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.19+7 (11.0.19+7, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# J 14686 c2 jd.ao(ZLjd;[B)Ljd; (473 bytes) @ 0x0000025ce6e4c28e [0x0000025ce6e4bc60+0x000000000000062e]
#

@rascopog - Are your graphics drivers and Runescape fully up to date?  I recommend posting this crash to them as it's likely a native library causing it that's under their control.


Add an example github workflow

Signed-off-by: Tyler Ohlsen<EMAIL_ADDRESS>Description
Add an example github workflow to demonstrate auto-label github action.

Codecov Report

Merging #4 (c84725c) into main (4c509b5) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head c84725c differs from pull request most recent head d4a92e8. Consider uploading reports for the commit d4a92e8 to get more accurate results

@@           Coverage Diff           @@
##             main       #4   +/-   ##
=======================================
  Coverage   45.93%   45.93%
=======================================
  Files         150      150
  Lines        4944     4944
  Branches      951      951
=======================================
  Hits         2271     2271
  Misses       2455     2455
  Partials      218      218

Impacted Files
Coverage Δ

...aly-detection-dashboards-plugin/utils/constants.ts
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Wake-up call and alarm not working

Describe the bug
I tried to set-up a wake-up call and alarm, but I get constant errors when I trigger either of them in the Apple Home app. Protocol in Homebridge shows error (see below).

To Reproduce
Steps to reproduce the behavior:

Go to Home App
Click on FritzBox alarm or wake-up tile
Error shows in Homebridge protocol, desired action not executed

Expected behavior
FritzBox should trigger alarm call to the phone number I put in fritz-platform -> extras -> alarm
FritzBox should trigger wake-up call to internal phone number I put in fritz-platform -> extras -> wake-up
Log
Error: Internal Server Error
at Object.exports.request (/usr/local/lib/node_modules/homebridge-fritz-platform/node_modules/@seydx/fritzbox/lib/request.js:78:21)
at runMicrotasks ()
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at exports.requestXml (/usr/local/lib/node_modules/homebridge-fritz-platform/node_modules/@seydx/fritzbox/lib/request.js:230:20)
at Service.execAction (/usr/local/lib/node_modules/homebridge-fritz-platform/node_modules/@seydx/fritzbox/lib/service.js:133:20)
at Handler.set (/usr/local/lib/node_modules/homebridge-fritz-platform/src/accessories/extras/extras.handler.js:230:13) {
title: 'Invalid Response',
code: 500,
soap: {
errorCode: '501',
errorDescription: 'Action Failed',
action: 'urn:dslforum-org:service:X_VoIP:1#X_AVM-DE_DialNumber'
},
url: 'https://MYUSER:MYPASSWORD@<IP_ADDRESS>:49443/upnp/control/x_voip'
}
Desktop (please complete the following information):

OS: iPad OS 15.6.1
Browser Safari

I would be grateful for any ideas on how to solve this! Thank you!

If someone should have the some problem: In the Fritz!Box Settings „Wählhilfe“ (dialer support) has to be activated in order for these features to work.


Feature Request: IOS - Hide read articles when mark as read is invoked

Would love to see this sometimes as it would remove the need to do an extra feed refresh to hide them.  It may also cut down on the total number of read requests.
I don’t think it’s needed to do an extra network request when the articles are hidden.  Just sync the read status on the next update.

Hi @travelingflwr.  Thank you for the suggestion, but we as a team, have discussed this subject many times.
The problem with automatically removing the articles from the timeline is that is surprises the average user.  This is problematic, especially if they didn't intend mark it as read.  In fact, it is so problematic that we leave the option to clear read items by doing the refresh off by default.

Ack. Sounds very well thought out then.  Completely reasonable design then.
Thanks for the detailed explanation!!
Amy


Provide a diagnostics page

Considering changing this issue to providing a diagnostic script instead.

@softcraftsman This might be the issue to include the RBAC access check?


Fix wireguard allowedIPs

Signed-off-by: Artem Glazychev<EMAIL_ADDRESS>

@glazychev-art Is there a reason this is not doing both the IPAddresses and the Routes?

@glazychev-art Could you attach the issue?

@edwarnicke
There was no special reason.
Added both the IPAddresses and the Routes.


Instanced mesh material pipeline

Objective
This code example just suggest a direction one can take to implement instanced meshes with a material.
NOTE: all instances use the same material - this suggestion leaves out code changes required in the render core.
This example is similar to the shader_instancing example.
The key differences comparing this example with the shader_instancing example are:

can utilize materials and per instance data
all instances use a fragment shader without instance data; all instances look the same (NOTE: the red in the example comes from a spot light)

I think it has enough value as an example (maybe shortened with more comments?)
Solution
Create a pipeline which uses the material_pipeline internally. After the pipeline was specialized by the material specialize it by the instance data.
This might be the trivial direction to take where there is a trait for specializing the pipeline by the instance data.
Drawbacks
The pipeline specializes for instancing after specializing for the material. This is because the pipelines are implemented like a prototype chain: if the material pipeline specializes it specializes the mesh pipeline first, internally. As a consequence we cannot specialize the pipeline after specializing for meshes and before specializing for materials.
We could introduce a trait - exactly how material exists for the material pipeline - which specializes for instancing after the material. This means materials and instancing are separate concepts.
My guess is these concepts clash and cannot be handled independently, though.

Closing given how old this PR is, and then we support automatic instancing/batching now. However, as I've talked about before, Material has no good way of doing per-instance data stored in a storage buffer shared across all instances of a material.  That would be nice to figure out at some point.


More detailed Contributing chapter in README.md

Currently it just requests pre-commit hooks to be available, while other requests could be made.

This is done.


Devilbox Release v1.9.1

Release v1.9.1 (2021-05-17)
Added

Added PHP Xdebug info page for intranet

Changed

#769 Adjusted Xdebug 3.0 defaults
Update PHP images to 0.124

Fixed

#783 Kibana 6.6 and above uses ELASTICSEARCH_HOSTS

Currently still waiting for GH Actions to recover, so I can merge this one: https://github.com/devilbox/docker-python-sphinx/pull/2 which is required to ensure CI for documentation is back to green.


[ENH] Support packed C structs in pure Python mode

Provide a Python syntax version of
cdef packed struct MyStruct: ...

Since cython.struct() already takes arbitrary keyword arguments, a new keyword argument packed=True will not work.
We could just add a new function cython.packed_struct(). (It would just be an alias for struct() in Shadow.py.)

Can we afford to make the structures a little more pythonic? Dataclass-style, only not allowing any other members besides fields.
This would look prettier:
@cython.struct
class MyStruct:
    x: cython.int
    y: cython.int
    data: cython.double

Than this:
MyStruct = cython.struct(x=cython.int, y=cython.int, data=cython.double)

And then it will be possible to write the packed structures in this way:
@cython.packed
@cython.struct
class MyStruct:
    x: cython.int
    y: cython.int
    data: cython.double

or
@cython.packed_struct
class MyStruct:
    x: cython.int
    y: cython.int
    data: cython.double

Or even class MyStruct(metaclass=cython.struct) half-wink
A decorator @cython.packed doesn't seem a good idea to me. There is nothing you could combine it with than @cython.struct. And @cython.packed_struct reads a lot more like the C code that it aims to represent.
Defining C structs in a Python class body seems a very obvious thing to do. It would be nice to support that.

It would be nice to support that.

Should I create a separate issue dedicated to this?

restrict use of cython.declare (disallow using visibility argument).

Of course, it's easier to just not allow visibility to be defined, but in cpp it is possible to define visibility for structure members, we could add this feature, although it seems like a relatively unclaimed feature, and it will take a lot of work to put everything together.

It would be nice to support that.

Should I create a separate issue dedicated to this?

I don't think that's necessary. If we implement it as part of this ticket, then supporting both packed and normal structs will be entirely trivial. And if we want to take the easy path first, then there's still enough time to create a new ticket.

Although there are some shenanigans for c to recreate this behavior.

restrict use of cython.declare (disallow using visibility argument).

Of course, it's easier to just not allow visibility to be defined, but in cpp it is possible to define visibility for structure members, we could add this feature, although it seems like a relatively unclaimed feature, and it will take a lot of work to put everything together.

That seems outside of the scope of this ticket.

there's still enough time to create a new ticket.

Sure

if we want to take the easy path first

Hopefully we'll make the full version right away.

That seems outside of the scope of this ticket.

I just don’t know if it’s worth raising this question at all, I don’t see a simple and backward compatible implementation ... I’m probably not thinking about it enough yet.
Anyway, should I create a separate issue this time around?

should I create a separate issue this time around?

I remember discussing this topic years ago, but not where. If there isn't an issue yet, sure, would be good to have one.

Or even class MyStruct(metaclass=cython.struct)

To also raise exceptions in pure python mode in the process of creating a class in case of an attempt to use prohibited members?

Or even class MyStruct(metaclass=cython.struct)

To also raise exceptions in pure python mode in the process of creating a class in case of an attempt to use prohibited members?

I was more thinking that the result of the class creation should be a
Python Enum when running in Python. A metaclass could avoid the actual
Python class creation.
Anyway, a decorator seems a much more natural and user friendly concept
than a metaclass.

Python Enum when running in Python

Python Enum for cython.struct?

A metaclass could avoid the actual
Python class creation.
Anyway, a decorator seems a much more natural and user friendly concept
than a metaclass.

With the help of a decorator, we can make a class that uses a metaclass, so everything you listed is still possible.
def decorator(cls):
    class Wrapper(cls, metaclass=type):
        pass
    return Wrapper

Python Enum when running in Python

Python Enum for cython.struct?

Too many tickets open at the same time, I guess…

A metaclass could avoid the actual Python class creation.
Anyway, a decorator seems a much more natural and user friendly concept than a metaclass.

With the help of a decorator, we can make a class that uses a metaclass, so everything you listed is still possible.
def decorator(cls):
    class Wrapper(cls, metaclass=type):
        pass
    return Wrapper

No, not if the intention is to change the class creation. The decorated class is already created when the decorator runs on it.

using metaclasses for anything would be a totally new concept in Cython's pure Python mode

Now that sounded like it would be deserving of its own issue, but it seems like there's nothing new under the sun: #1332 😅

A decorator @cython.packed doesn't seem a good idea to me. There is nothing you could combine it with than @cython.struct

In the first solution from #4257, we could combine cython.struct with cython.cppstruct and cython.struct

A decorator @cython.packed doesn't seem a good idea to me. There is nothing you could combine it with than @cython.struct

In the first solution from #4257, we could combine cython.packed with cython.cppstruct and cython.struct

Still, packed structs are a very rare and special thing. I think it's fine to give them their own, separate decorator. Or two, if you want C++ structs.
I just think that
@cython.packed_struct
class MyStruct: ...

reads better than the more verbose
@cython.packed
@cython.struct
class MyStruct: ...

or
@cython.struct
@cython.packed
class MyStruct: ...

In which order would you write the two decorators? Is it "@packed @struct" or "@struct @packed"? Should that matter?  If it's "@packed @struct", as you would find it in C, then does that make the "@struct" harder to spot? What if multiple developers in the same project feel differently about it?
To me, all of this seems to violate the "don't make me think" principle, big time. With<EMAIL_ADDRESS>there is no need to discuss or consider anything.

Well, I agree. Okay, so be it.


Fix azd Stage

Purpose
This insures that the static frontend folder is included in the docker container.
fix #53
related https://github.com/Azure/azure-dev/issues/3546, https://github.com/Azure/azure-dev/issues/4136
Does this introduce a breaking change?
When developers merge from main and run the server, azd up, or azd deploy, will this produce an error?
If you're not sure, try it out on an old environment.
[ ] Yes
[x] No

Type of change
[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

Code quality checklist
See CONTRIBUTING.md for more details.

[-] The current tests all pass (python -m pytest).
[-] I added tests that prove my fix is effective or that my feature works
[-] I ran python -m pytest --cov to verify 100% coverage of added lines
[-] I ran python -m mypy to check for type errors
[-] I either used the pre-commit hooks or ran ruff manually on my code.

I deployed this time to make sure it works.


[pwrmgr] parameters for wakeup index

Right now, the peripheral wakeup index is auto-generated at two places

one in pwrmgr.hjson / pwrmgr_reg.h
one in top_earlgrey.h

The latter should be the only place where this is needed, but since dif_pwrmgr.c / dif_pwrmgr_unittest.c use these parameters for assert checking, top specific information ends up getting bound into the DIF.  This is not quite right.
@timothytrippel suggestion is that we just template dif_pwrmgr.c completely.  This would allow us to directly generate the index inside the header file without needing to include it in pwrmgr.hjson.

@matutem


Inconsistent behavior when inferring a generic type from a function

Bug Report
🔎 Search Terms
Not sure what to search for, tried various combos of "infer" "generic" "function" but seems too general.
🕗 Version & Regression Information
Tried in 4.0.5, 4.6.3, and 4.9.4.
⏯ Playground Link
Playground link with relevant code
💻 Code
// see also playground link

type Funcs<A, B extends Record<string, unknown>> = {
  [k in keyof B]: {
    fn: (a: A, b: B) => void;
    thing: B[k];
  };
}

function foo<A, B extends Record<string, unknown>>(fns: Funcs<A, B>) {}

foo({
  bar: {
    fn: (a: string) => {}, // <-- ERROR HERE
    thing: 'asd',
  },
});

foo({
  bar: {
    fn: (a: string, b) => {}, // <-- NO ERROR HERE
    thing: 'asd',
  },
});

Actual behavior
It infers generic <A> as unknown, in the former case only. It then checks assignability of unknown to a: string and raises an error.
Type '(a: string) => void' is not assignable to type '(a: unknown, b: { bar: string; }) => void'.
  Types of parameters 'a' and 'a' are incompatible.
    Type 'unknown' is not assignable to type 'string'.(2322)
input.tsx(3, 5): The expected type comes from property 'fn' which is declared here on type '{ fn: (a: unknown, b: { bar: string; }) => void; thing: string; }'

Expected behavior
I didn't expect it to infer unknown in the former case, and more generally was surprised that including/excluding b from the argument list would affect inference from a. I thought it should see string in both cases, and that all of the above would compile.

Aside: The contravariant-only inference on A is generally a code smell. Is there a more complete example?

@RyanCavanaugh - Thanks for the response. The real code is quite involved; I've tried to distill it down. The use case is a React H.O.C. which accepts a struct describing its remote data dependencies.
const WithMentorData = remoteDataDependencies({
  mentee: {
    decoder: personDecoder,
    src: (menteeId: string) => `/people/${menteeId}`,
  },

  mentor: {
    decoder: personDecoder,
    src: (_menteeId: string, data) => {
      if (data.mentee.state === 'ok') {
        const mentee = data.mentee.value;
        const mentorId = mentee.mentor;
        return `/people/${mentorId}`;
      }
    },
  },
});

For each dependency, src describes the URL to fetch, and decoder describes a type guard applied to the response. The src function accepts a second param data since sometimes we need the results of one fetch in order to do another. The resulting <WithMentorData/> can be used to handle data fetching for anything that needs that needs mentor information via a render prop, as long as you have the mentee ID.
return (
  <WithMentorData
    arg={menteeId}
    render={data =>
      <MentorProfile
        menteeData={data.mentee}
        mentorData={data.mentor}
      />
    }
  />
);

My code mostly works. Property names (e.g. .mentee and .mentor) are known at compile time, and the decoder types carry through to those properties. The one issue is what I've described in my OP.

This looks quite interesting, gonna try to dive into this at some point - unless somebody beats me to it.

Here's another oddity involving the same error message, so seems to be related. I've attached a screen recording because I can only trigger it by live-editing the code. Here's the sequence:

Copy/paste the bar property.
Using one keystroke, rename bar to baz.
Both fn sub-properties now display the error.
Make any change to the code.
The errors disappear.

Please ignore if this is a separate issue and/or unrelated.

Screen recording
https://user-images.githubusercontent.com/317786/216657826-9045106a-4ba1-4b88-969c-9143bb2a2c59.mov

This one is likely the same as the one reported here. I'm working on fixing that issue here. I'll try to verify later if it fixes your issue as well.

I prepared a potential fix for this issue: https://github.com/microsoft/TypeScript/pull/52597
As a workaround in the meantime you might want to prefer regular functions over arrows, it works with them: TS playground

I reproduced the issue with incorrect error messages using this test:
///<reference path="fourslash.ts"/>
// @strict: true
////
//// type Funcs<A, B extends Record<string, unknown>> = {
////   [K in keyof B]: {
////     fn: (a: A, b: B) => void;
////     thing: B[K];
////   }
//// }
////
//// function foo<A, B extends Record<string, unknown>>(fns: Funcs<A, B>) {}
////
//// foo({
////   bar: { fn: (a: string, b) => {}, thing: "asd" },
////   /*1*/
//// });

goTo.marker("1");
const markerPosition = test.markers()[0].position;
edit.paste(`bar: { fn: (a: string, b) => {}, thing: "asd" },`)
edit.replace(markerPosition + 4, 1, 'z')
verify.completions({ isNewIdentifierLocation: true });
verify.noErrors();

Now I need to dive deeper into this to understand why this is happening 😉


Observing SSL Error

@search @twitter
Scenario: Search for tweets                                         # features/twitter.feature:9
Given I set base URL to "https://api.twitter.com/1.1"             # behave_rest/steps/init.py:13 0.003s
And I set "Authorization" header to "context.twitter_auth"        # behave_rest/steps/init.py:36 0.000s
When I make a GET request to "search/tweets.json" with parameters # behave_rest/steps/init.py:121 0.458s
| q      |
| stanfy |
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/lib/python2.6/site-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "/usr/lib64/python2.6/contextlib.py", line 34, in exit
self.gen.throw(type, value, traceback)
File "/usr/lib/python2.6/site-packages/behave/runner.py", line 454, in use_context_with_mode
yield
File "/usr/lib/python2.6/site-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "/root/behave-rest/behave_rest/steps/init.py", line 138, in request_with_parameters
log_full(context.r)
File "/root/behave-rest/behave_rest/steps/init.py", line 244, in log_full
'\n'.join('{}: {}'.format(k, v) for k, v in req.headers.items()),
File "/root/behave-rest/behave_rest/steps/init.py", line 244, in
'\n'.join('{}: {}'.format(k, v) for k, v in req.headers.items()),
ValueError: zero length field name in format
  Captured stdout:

Captured stderr:
/usr/lib/python2.6/site-packages/requests/packages/urllib3/util/ssl_.py:335: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
SNIMissingWarning
/usr/lib/python2.6/site-packages/requests/packages/urllib3/util/ssl_.py:133: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
InsecurePlatformWarning
/usr/lib/python2.6/site-packages/requests/packages/urllib3/connectionpool.py:852: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
InsecureRequestWarning)
Then the response status code should equal 200                    # None
And the response status code should be among 200, 201             # None
And the response structure should equal "twitterSearchData"       # None
And the response header "status" should equal "200 OK"            # None

Failing scenarios:
features/twitter.feature:9  Search for tweets
0 features passed, 1 failed, 0 skipped
0 scenarios passed, 1 failed, 0 skipped
2 steps passed, 1 failed, 4 skipped, 0 undefined
Took 0m0.461s
Am i missing anything, Could you please help?

Sorry my bad. It was due to setup issue.


Fixed a typo in the code snippet

Fixed a typo in the code snippet

Test failed on this pull request because @anuragvickey submitted it to the development branch instead of the master branch. Tests don't currently pass on the development branch. The commit will make it to the master branch eventually, it will just take much longer for it to become a public part of the documentation.
@anuragvickey If you wish, you can resubmit this pull request against master and I can merge it in sooner.

Thank you Master!

Created a pull request for master :
https://github.com/gunthercox/ChatterBot/pull/677
Thanks & Regards,
Anurag Sharma
2017-04-03 9:17 GMT-07:00 Mallikarjunarao Kosuri<EMAIL_ADDRESS>
Thank you Master!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gunthercox/ChatterBot/pull/676#issuecomment-291193389,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM5g_RnmWNPPa5521Qkh1r2BmrPwTkc8ks5rsRuQgaJpZM4MxAnJ
.


Reset CHANGELOG.md

Motivation
Prepare CHANGELOG.md for next release
Changes

add unreleased section

Test Plan

n/a

TODO

[x] Explain motivation or link existing issue(s)
[x] Test changes and document test plan
[x] Update documentation as needed
[x] Update changelog as needed

bors merge


Potential race condition when task has a property whose value is derived from mapped dependency resolution results

This issue is happening in the test suite for the Android Gradle Plugin, when running with Gradle 6.4 RC-1 through RC-3. It doesn't happen for earlier Gradle versions (and hopefully later versions too).
The issue happens because changes in 6.4 expose a race condition in DefaultConfiguration that has been present for quite some time.
Expected Behavior
The AGP test suite passes with Gradle 6.4.
Current Behavior
This issue is the result of combining several behaviours:

The mapped provider implementation verifies that the task(s) that produce the input value have been executed when the value is queried, before invoking the mapping function.
The FileCollection.elements provider implementation calculates the tasks that produce its value by visiting the producer tasks of the source FileCollection
DefaultConfiguration visits its producer tasks by visiting the selected variants of the cached resolution results attached to the configuration instance, visiting the task dependencies of each variant.

Item 2 is new in Gradle 6.4. Previous versions would incorrectly use an empty set of producer tasks.
And separately:

DefaultConfiguration visits its files by first setting its cached resolution result to an empty and unusable resolution result, then continues with graph resolution to populate the result with the selected variants. This means that if some other thread happens to use the cached resolution result while graph resolution is happening, the results will be in an unusable state and an assertion exception is thrown.

So, given we have two tasks, task A which has an @Input property whose value is the mapped elements of a Configuration instance, and and task B with an @InputFiles property whose value is the same Configuration instance, then:

Task B starts execution, and Gradle starts visiting the input files to snapshot them.
DefaultConfiguration starts visiting its files, setting the cached resolution result to an unusable empty value.
The worker thread continues with graph resolution, during which the project lock is released.
Task A starts execution in another worker thread, and Gradle starts visiting the inputs to snapshot them.
The worker thread visits the producer tasks of the configuration instance. This attempts to use the cached resolution results, which are still in an unusable state and an exception is thrown.

Some fixes in https://github.com/gradle/gradle/pull/12971


feat: Improve connext relayer

Description

Type of change

[ ] Docs change / dependency upgrade
[ ] Configuration / tooling changes
[ ] Refactoring
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Requires changes in customer code

High-level change(s) description - from the user's perspective

Related Issue(s)
Fixes
Related pull request(s)

Not sure how this improves performance of the relayer. Currently the relayer is not bottlenecked on http requests, it is instead on the rate at which it can place new transactions on chain.
Both https requests, and cache poll pending, happen in separate threads, already right ?

For now, that is not bottlenecked, but when a lot of transactions are pending, so HTTP server are processing them, polling didn't process them as I tested.


Vue Action problem

Hi,
while trying dewhale i bumped into problem with my Action.
 error: Uncaught (in promise) GraphqlResponseError: Request failed due to following response errors:
 - Could not resolve to an Issue with the number of 3.
    at file:///home/runner/.cache/deno/npm/registry.npmjs.org/@octokit/graphql/7.1.0/dist-node/index.js:113:13
    at eventLoopTick (ext:core/01_core.js:192:13)
    at async getConnectedPr (file:///home/runner/work/dewhale/dewhale/prompts/common.ts:117:26)
    at async composeWorkflow (file:///home/runner/work/dewhale/dewhale/prompts/common.ts:458:31)
    at async main (file:///home/runner/work/dewhale/dewhale/prompts/vue-ui-gen.ts:108:18)
Error: Process completed with exit code 1.

same error here


Handle top level Error key for non-error responses

The standard retry mode will attempt to introspect any parsed response
for a top level "Error" key. If present the standard retry strategy
assumes that the response is an error response and that there will be a
nested dictionary under the "Code" key. This assumption is not
generally safe as standard responses can also contain a top level
"Error" key.
Fixes https://github.com/aws/aws-cli/issues/5644

Codecov Report

Merging #2226 (937dae8) into develop (f67b21b) will decrease coverage by 0.42%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop    #2226      +/-   ##
===========================================
- Coverage    98.23%   97.81%   -0.43%
===========================================
  Files           58       58
  Lines        10852    10855       +3
===========================================
- Hits         10661    10618      -43
- Misses         191      237      +46

Impacted Files
Coverage Δ

botocore/retries/standard.py
99.50% <100.00%> (+<0.01%)
:arrow_up:

botocore/compat.py
72.15% <0.00%> (-22.16%)
:arrow_down:

botocore/hooks.py
95.18% <0.00%> (-0.81%)
:arrow_down:

botocore/httpsession.py
92.48% <0.00%> (-0.58%)
:arrow_down:

botocore/awsrequest.py
97.22% <0.00%> (-0.35%)
:arrow_down:

botocore/utils.py
97.55% <0.00%> (-0.19%)
:arrow_down:

botocore/credentials.py
98.54% <0.00%> (-0.11%)
:arrow_down:

Continue to review full report at Codecov.

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