HLS: Downloading failed due to incorrect padding of a single segment.

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting a bug unrelated to a specific site
[X] I've verified that I'm running yt-dlp version 2023.07.06 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Provide a description that is worded well enough to be understood
I am downloading a video using hls (m3u8) link, it seems that the encryption of ONE of it's segment is corrupted (incorrect padding). only because of that yt-dlp failed to download the video.
But VLC media player and hls.js (on webpage) are able to play video completely. So it should be yt-dlp's behaviour to skip that problematic segment instead of breaking the whole download.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
[debug] Command-line config: ['-vU', 'https://videoscdn.classplusapp.com/20A5D0497A57E6CAD1DAB0DD94B1C7994EA25E93E18125F6F11AF02C6477C97C/4054133/videos/4054133-pr-basic-concepts-of-grammar-3--10000-1644403937893-480p.m3u8?key=1692293326-6-0-c396a38f77a1debd914c85a3d9b6e63f', '-N', '32', '-o', 'test.%(ext)s']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[b532a3481] (pip)
[debug] Python 3.11.4 (CPython AMD64 64bit) - Windows-10-10.0.19045-SP0 (OpenSSL 1.1.1u  30 May 2023)
[debug] exe versions: ffmpeg 6.0-full_build-www.gyan.dev (setts), ffprobe 6.0-full_build-www.gyan.dev
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1855 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>yt-dlp is up to date<EMAIL_ADDRESS>[generic] Extracting URL: https://videoscdn.classplusapp.com/20A5D0497A57E6CAD1DAB0DD94B1C7994EA25E93E18125F6F11AF02C6477C97C/4054133/videos/4054133-pr-basic-concepts-of-grammar-3--10000-1644403937893-480p.m3u8?key=1692293326-6-0-c396a38f77a1debd914c85a3d9b6e63f
[generic] 4054133-pr-basic-concepts-of-grammar-3--10000-1644403937893-480p: Downloading webpage
[debug] Identified a direct video link
[generic] 4054133-pr-basic-concepts-of-grammar-3--10000-1644403937893-480p: Downloading m3u8 information
[generic] 4054133-pr-basic-concepts-of-grammar-3--10000-1644403937893-480p: Checking m3u8 live status
[debug] Formats sorted by: hasvid, ie_pref, lang, quality, res, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[debug] Default format spec: bestvideo*+bestaudio/best
[info] 4054133-pr-basic-concepts-of-grammar-3--10000-1644403937893-480p: Downloading 1 format(s): 0
[debug] Invoking hlsnative downloader on "https://videoscdn.classplusapp.com/20A5D0497A57E6CAD1DAB0DD94B1C7994EA25E93E18125F6F11AF02C6477C97C/4054133/videos/4054133-pr-basic-concepts-of-grammar-3--10000-1644403937893-480p.m3u8?key=1692293326-6-0-c396a38f77a1debd914c85a3d9b6e63f"
[hlsnative] Downloading m3u8 manifest
WARNING: Live HLS streams are not supported by the native downloader. If this is a livestream, please add "--downloader ffmpeg --hls-use-mpegts" toyour command
[hlsnative] Total fragments: 359
[download] Destination: test.mp4
[debug] File locking is not supported. Proceeding without locking
WARNING: The download speed shown is only of one thread. This is a known issue
[download]  90.3% of ~ 244.13MiB at    2.37MiB/s ETA 00:09 (frag 324/359)ERROR: Data must be padded to 16 byte boundary in CBC mode
Traceback (most recent call last):
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\YoutubeDL.py", line 1560, in wrapper
    return func(self, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\YoutubeDL.py", line 1709, in __extract_info
    return self.process_ie_result(ie_result, download, extra_info)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\YoutubeDL.py", line 1768, in process_ie_result
    ie_result = self.process_video_result(ie_result, download=download)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\YoutubeDL.py", line 2897, in process_video_result
    self.process_info(new_info)
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\YoutubeDL.py", line 3363, in process_info
    success, real_download = self.dl(temp_filename, info_dict)
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\YoutubeDL.py", line 3084, in dl
    return fd.download(name, new_info, subtitle)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\downloader\common.py", line 461, in download
    ret = self.real_download(filename, info_dict)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\downloader\hls.py", line 375, in real_download
    return self.download_and_append_fragments(ctx, fragments, info_dict)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\downloader\fragment.py", line 516, in download_and_append_fragments
    if not append_fragment(decrypt_fragment(fragment, self._read_fragment(ctx)), frag_index, ctx):
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\downloader\fragment.py", line 378, in decrypt_fragment
    return unpad_pkcs7(aes_cbc_decrypt_bytes(frag_content, decrypt_info['KEY'], iv))
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\yt_dlp\aes.py", line 11, in aes_cbc_decrypt_bytes
    return Cryptodome.AES.new(key, Cryptodome.AES.MODE_CBC, iv).decrypt(data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Dev\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\Cryptodome\Cipher\_mode_cbc.py", line 246, in decrypt
    raise ValueError("Data must be padded to %d byte boundary in CBC mode" % self.block_size)
ValueError: Data must be padded to 16 byte boundary in CBC mode

Same issue as #3810, #3578, #1297
workaround: use ffmpeg as downloader, add --downloader ffmpeg to your command


add promo block

‘You should receive an email confirming that your promo subscription is activated up to ‘date’. Please login with this email on your device or on <url, web page>. ‘
or


Preventing the Win32 API LoadLibrary() current directory DLL injection issue.

Preventing the Win32 API LoadLibrary() current directory DLL injection issue.

When loading the DLL file by the LoadLibrary() function in Windows VPN programs, we changed the behavior not to search the current directory. Based on this improvement, even if there are untrusted DLL files in the current directory, it is now safe to avoid the problem of unexpected security problem caused by the default loading behavior of Windows. Acknowledgments: This is based on a report by Herman Groeneveld, aka Sh4d0wman.

Your great patch is much appreciated. We are considering to apply your patch into the SoftEther VPN main tree.
SoftEther VPN Patch Acceptance Policy:
http://www.softether.org/5-download/src/9.patch
You have two options which are described on the above policy.
Could you please choose either option 1 or 2, and specify it clearly on the reply?

1

Hi @dnobori in the future when you merge a Pull Request, could you please the "Squash and commit" functionality of github instead of merge whenever possible? This keeps the history linear and somehow better to read. Thanks


Fix KSLinux Support

Description
Fix Build for #726 and #724

Add KSLinux Support
Add KSLinux Logo
Fix #726

I Had Fix All Bugs , and Modified as your notice.
KSLinux has a built-in initrd, so the PID of bash is 1
It'll get into a dead loop without PID=1 Check

Remove the parent check and instead make the loop look like this:
while [[ -z "$term" ]] || ((parent > 2)); do

parent Check script I added has been removed

Remove the parent check and instead make the loop look like this:
while [[ -z "$term" ]] || ((parent > 2)); do
This should fix it.
@dylanaraps
This will not work properly due to *sh will not set $term value ($term will always blank, and run into a dead loop)
((parent > 2)) test command will not run.

Lets remove all of the get_term changes and we'll handle it in a separate PR.

I Had Removed all the changes of get_term()


Fixed #1769: rm: -d should match GNU's output

Using some code from @growse 's pull request, I made a quick match statement that checks if the error is the Directory not found error. If so, it uses the show_custom_error_description macro to output said error, just without the "(os error)" part.

@syvlestre that's totally fine

I am not a huge fan for this PR. I think it adds unnecessary complexity. Sorry :(


Handling NULLs in composite keys

By most relational die-hards, including the designers of PostgreSQL, a composite key like (a, b, NULL) is considered an incomplete key as they interpret NULL as "unknown" rather than as its own value.  They would expect you to use a different, non-NULL value to represent "none", e.g. (a, b, none).
When a composite key has any NULLs in it:

A uniqueness constraint is not enforced on the incomplete key, so you can encounter multiple rows with the "same" incomplete key combination (a, b, NULL).
A foreign key constraint is not enforced on the incomplete references, so you can have arbitrary values like (x, z, NULL) where x and z would not be found in the referenced table no matter which value you were to substitute for the NULL.

I don't think we expect to diverge from SQL or Postgres too much here, so I suggest that when we are producing navigable links via foreign key, we should probably disable the link feature when we encounter incomplete references, i.e. references with one or more NULLs in them. Providing navigation by partial match would probably encourage the wrong understanding of how the ERM works.
In our actual projects, we should probably try to be more disciplined and introduce non-NULL constraints on our keys and references, and introduce different tombstone values to represent "none" rather than "unknown".  But, we still want Chaise to do appropriate things when it encounters less rigorous models...

@jrchudy check whether we have already handled this case?

Isn't the attributegroup api handling it? Whenever one of the columns of composite key is null, it is returning null as the value of foreign key.

A null value cannot participate in a valid key nor foreign key whether
a simple scalar value or as any part of a composite value.  This is a
part of SQL and PostgreSQL semantics, not specific to ERMrest or
Chaise.
The null value represents "unknown" or "incomplete" data and bypasses
the uniqueness constraints of the DB. More than one row could be
present with the same null state, meaning null cannot be used to
identify a row uniquely.

Ermrestjs seems to handle this case already.. Let's open another issue if we find a bug related to this.


trtllm-build Mixtral-8x7B-v0.1 fp16 failed

System Info

NVIDIA A100 80G * 2
Libraries

TensorRT-LLM 0.11.0

Driver Version: 525.105.17
CUDA Version: 12.4

Who can help?
@byshiue
Information

[X] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[ ] My own task or dataset (give details below)

Reproduction

Create model config file
Mixtral-8x7B-v0.1.json

use build command build model:
`export max_batch_size=2048
export tp_size=2
export max_num_tokens=2048
trtllm-build --model_config $model_cfg
--use_fused_mlp
--gpt_attention_plugin float16
--output_dir $engine_dir
--max_batch_size $max_batch_size
--max_input_len 2048
--max_output_len 2048
--reduce_fusion disable
--workers $tp_size
--max_num_tokens $max_num_tokens
--use_paged_context_fmha enable
--multiple_profiles enable`

Expected behavior
Build success
actual behavior
OutOfMemory
trtllm-build output log:
[07/29/2024-03:08:43] [TRT-LLM] [W] Found pynvml==11.5.3 and cuda driver version 525.105.17. Please use pynvml>=11.5.0 and cuda driver>=526 to get accurate memory usage.
[TensorRT-LLM] TensorRT-LLM version: 0.11.0
[07/29/2024-03:08:45] [TRT-LLM] [I] Set bert_attention_plugin to auto.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set gpt_attention_plugin to float16.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set gemm_plugin to None.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set gemm_swiglu_plugin to None.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set nccl_plugin to auto.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set lookup_plugin to None.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set lora_plugin to None.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set moe_plugin to auto.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set mamba_conv1d_plugin to auto.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set context_fmha to True.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set context_fmha_fp32_acc to False.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set paged_kv_cache to True.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set remove_input_padding to True.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set use_custom_all_reduce to True.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set reduce_fusion to False.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set multi_block_mode to False.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set enable_xqa to True.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set tokens_per_block to 64.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set use_paged_context_fmha to True.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set use_fp8_context_fmha to False.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set multiple_profiles to True.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set paged_state to True.
[07/29/2024-03:08:45] [TRT-LLM] [I] Set streamingllm to False.
[07/29/2024-03:08:45] [TRT-LLM] [W] Implicitly setting LLaMAConfig.rope_theta = 1000000.0
[07/29/2024-03:08:45] [TRT-LLM] [W] --max_output_len has been deprecated in favor of --max_seq_len
[07/29/2024-03:08:45] [TRT-LLM] [W] padding removal and fMHA are both enabled, max_input_len is not required and will be ignored
[07/29/2024-03:08:47] [TRT-LLM] [W] Found pynvml==11.5.3 and cuda driver version 525.105.17. Please use pynvml>=11.5.0 and cuda driver>=526 to get accurate memory usage.
[07/29/2024-03:08:49] [TRT-LLM] [W] Logger level already set from environment. Discard new verbosity: error
[TensorRT-LLM] TensorRT-LLM version: 0.11.0
[07/29/2024-03:08:49] [TRT-LLM] [W] Logger level already set from environment. Discard new verbosity: info
[07/29/2024-03:08:52] [TRT] [W] profileSharing0806 is on by default in TensorRT 10.0. This flag is deprecated and has no effect.
[07/29/2024-03:09:09] [TRT] [W] Unused Input: position_ids
[07/29/2024-03:09:09] [TRT] [W] Detected layernorm nodes in FP16.
[07/29/2024-03:09:09] [TRT] [W] Running layernorm after self-attention in FP16 may cause overflow. Exporting the model to the latest available ONNX opset (later than opset 17) to use the INormalizationLayer, olayernorm layers to run in FP32 precision can help with preserving accuracy.
[07/29/2024-03:09:09] [TRT] [W] [RemoveDeadLayers] Input Tensor position_ids is unused or used only at compile-time, but is not being removed.
[07/29/2024-03:10:11] [TRT] [E] [virtualMemoryBuffer.cpp::resizePhysical::140] Error Code 2: OutOfMemory (Requested size was<PHONE_NUMBER>2 bytes.)
[07/29/2024-03:10:11] [TRT] [E] [virtualMemoryBuffer.cpp::resizePhysical::140] Error Code 2: OutOfMemory (Requested size was<PHONE_NUMBER>2 bytes.)
[07/29/2024-03:10:11] [TRT] [W] Requested amount of GPU memory<PHONE_NUMBER>2 bytes) could not be allocated. There may not be enough free memory for allocation to succeed.
[07/29/2024-03:10:12] [TRT] [E] Error Code: 2: Requested size was<PHONE_NUMBER>2 bytes.
[07/29/2024-03:10:12] [TRT] [E] [globWriter.cpp::makeResizableGpuMemory::424] Error Code 2: OutOfMemory (Requested size was<PHONE_NUMBER>2 bytes.)
[07/29/2024-03:10:12] [TRT-LLM] [E] Engine building failed, please check the error log.
additional notes
I attempted to validate the performance tests described in perf-overview and successfully validated the performance tests for Llama-2-7b-hf and Meta-Llama-3-8B. However, when building Mixtral-8x7B-v0.1, I encountered an out-of-memory error. I am using two A100 80GB GPUs. What type of GPU is required to compile Mixtral-8x7B-v0.1?

Hi, vonchenplus
Please decrease the max_batch_size/max_input_len/max_output_len when building the engine.
I think a rough estimation is that

for Mixtral8x7b with fp16 precision, its weight consumes ~87GB
the fp16 KVcache consumes ~65536*2048(max_bs)*4096(max_in + max_out)*2(fp16)/1024/1024/1024 = 1024GB
the sum of the two is far larger than your GPUs capacity (160GB)

I have a few questions I'd like to ask:

When I set the workers parameter to 2 during trtllm-build, is only one GPU being used in the end? Because I see that only one GPU's memory is being utilized.
When you tested Mixtral-8x7B-v0.1 fp16, what graphics card did you use?

Hi, @vonchenplus

How do you observe that only one GPU was used?  Could you double confirm your observation by print the workers here: https://github.com/NVIDIA/TensorRT-LLM/blob/93293aa46d5e37c885fc2852d711e9dccb03bb18/tensorrt_llm/commands/build.py#L408?
I think 2xA100 is OK

Hi, @Kefeng-Duan ,

I checked yesterday and confirmed that the workers are set to 2, but it seems that only one card is being used.
However, in my current test, using two cards is indeed not working.

Hi, @vonchenplus

are your torch.cuda.device_count() = 1 or 2?
even when you decrease the max_bs/max_seqin/max_seqout to a proper range?   what's the failure message?
Thanks

Hi @Kefeng-Duan

torch.cuda.device_count() is 2.
I didn't reduce max_bs/max_seqin/max_seqout because I wanted to reproduce the performance mentioned in your report.

Hi @vonchenplus , in the Mixtral-8x7B-v0.1.json file you shared, tp_size is set to 1, if you want to do TP2 with dummy weights, you'll need to set mapping as
"mapping": {
        "world_size": 2,
        "tp_size": 2,
        "pp_size": 1
    },

Hi @kaiyux,
It's already working, thanks you.


add ability to set the color of the icons in a c-tip

What's Changed
c-tile
Add ability to set the color of the icons in the c-tile

Coverage increased (+0.01%) to 72.556% when pulling 854f0449c2434cba18110ffb68ffeeb2912cc123 on tile-tip into 3dbdea5c52e5c3b02da2318a03656b5227b07b32 on master.


visitor can "checkout" the items in my cart so I can purchase my desired goods. #10

Think of a typical user experience on popular websites from a guest user and logged-in user perspective.
You can just start with by simulating the experience of checking out with a simple confirmation page.

mostly complete just add stripe


Fix the stack management for account procedures

AFAIU, the current code is organized as follows:

miden lib is used to expose easy to use functions to users, e.g.:

https://github.com/0xPolygonMiden/miden-base/blob/dbe83c90916b9465a850355e6a4ed67f1ec034ff/miden-lib/asm/miden/account.masm#L87-L96
And internally this function manages the stack, such that the user won't lose its state:
https://github.com/0xPolygonMiden/miden-base/blob/dbe83c90916b9465a850355e6a4ed67f1ec034ff/miden-lib/asm/miden/account.masm#L96-L101

the kernel library expects padded stack, since it can't return more than 16 elements, and it must overwrite some of the elements in the stack:

https://github.com/0xPolygonMiden/miden-base/blob/dbe83c90916b9465a850355e6a4ed67f1ec034ff/miden-lib/asm/kernels/transaction/api.masm#L163-L170
The above means the user would exec.set_item and have a nice to use API.
However, for security, set_account_item must authenticate the origin of the call, e.g. to prevent a rogue note from changing the account's code. This means the function can not be execed, and it must be called instead.
Now, because the call can return at most 16 elements in the stack, the code above that was suppose to provide a nice API is unusable, because it is pushing 3 elements to the stack which are never cleaned up:
https://github.com/0xPolygonMiden/miden-base/blob/dbe83c90916b9465a850355e6a4ed67f1ec034ff/miden-lib/asm/miden/account.masm#L97-L102

To provide the above interface, one thing that could be done, is to use the same strategy as https://github.com/0xPolygonMiden/miden-base/issues/701, and have the address to dyncall in memory. That way the user would initialize the memory with the callback addresses in the beginning of the transaction script, and then would exec the code in miden/account.masm, which would in turn use a dyncall to transition to the authenticated account code.

I think a couple of things may be conflated here. A few comments:

However, for security, set_account_item must authenticate the origin of the call, e.g. to prevent a rogue note from changing the account's code. This means the function can not be execed, and it must be called instead.

We need to use syscall rather than call to invoke kernel procedures - though, the effect on the stack would be the same in both cases.

Now, because the call can return at most 16 elements in the stack, the code above that was suppose to provide a nice API is unusable, because it is pushing 3 elements to the stack which are never cleaned up:

I'm not sure I follow this part. The referenced code should not leave any extra items on the stack (if it does, there is a bug somewhere). The call sequence looks something like this:

The user runs exec.account::set_item in miden/accounts.masm. This is the procedure which has the user-friendly interface (i.e., the user does not need to worry about padding the stack).
Internally, account::set_item does the stack padding and makes a syscall to set_account_item defined in api.masm.
Then, set_account_item performance procedure authentication and executes account::set_item defined in miden/kernels/tx/account.masm.
a. As a side note, putting the kernels modules into the miden library was probably not a good decision - they should be in a separate library which is imported by the api.masm instead of the miden library.

Flow between items 2 and 3 has been the source of quite a bit of confusion, and we should probably refactor it (as is described in #685) - but all of this is hidden from the user because exec.account::set_item from the first step should work like any other function.

The user runs exec.account::set_item in miden/accounts.masm. This is the procedure which has the user-friendly interface (i.e., the user does not need to worry about padding the stack).

This only works from inside the account context, as in set_item is not a nice to use function for transaction scripts, for the account code, otherwise the authentication would fail. So there is another call done by the tx script to the code that does set_item. This is the one I'm referring to.

This only works from inside the account context, as in set_item is not a nice to use function for transaction scripts, for the account code, otherwise the authentication would fail. So there is another call done by the tx script to the code that does set_item. This is the one I'm referring to.

hmmm - account::set_item should only be available from account context. Trying to execute it from transaction or note script should be an error. We list here which kernel procedure are allowed to be called from which context.

Or I guess you mean we have a procedure on the account which internally invokes account::set_item, and this procedure is called from a transaction script via the call instruction. In this case yes, the caller is responsible for padding the stack and this is also one of the motivations for defining a consistent ABI described in #685.

hmmm - account::set_item should only be available from account context. Trying to execute it from transaction or note script should be an error. We list here which kernel procedure are allowed to be called from which context.

Yes. We seem to agree on how it works. We don't seem to agree on how useful it is.
Basically what I'm trying to say is this only works as a nice to use function if you're writing the account code. And there is very little use for that. The vast majority of the code will be note scripts or tx scripts. At least in my eyes, the most common case should be the easiest. So that would be making the so-called nice to use functions usable from the tx script.
Account code is more complicated, we can't really hide the padding of the stack, because the function exposed by the account are called, and they have to handle these conventions anyways. If they have to be aware of the convention when exposing the account's API, it doesn't seem that much extra to assume the author can call the kernel using the same convention.

Basically what I'm trying to say is this only works as a nice to use function if you're writing the account code. And there is very little use for that. The vast majority of the code will be note scripts or tx scripts.

I am not sure about the last point. Writing account procedures which internally call kernel procedures would be fairly common too. I can't say whether it will be more or less common then writing note/tx scripts - but in my mind they are roughly comparable in importance.
I agree that there isn't much we can do with the procedures exposed by the account interface itself because they must be call-ed. And #685 attempts to define a standard way to call them. But I don't think just because we can't make these procedures as "easy-to-use" as regular procedures, we should make other procedures more complicated.
So, basically, my thinking is:

Invoking kernel procedures from within account procedures could work the way it does now (where the user does not need to worry about padding the stack).
Invoking account procedures from note/tx scripts would be more complicated and the user would need to pad the stack, but the methodology for padding should be standardized to have a "uniform ABI".

@bobbinth I think that everything you described was done by ABI PR. The procedures from the miden::account could be executed only in the account context: we can enter it by calling the contracts procedures (wallet, faucets, auth) or by calling the procedures from the user's account. In all these cases stack should be padded before the call.
I think that this issue is not relevant anymore.


pythonPackages.faker: 8.8.2 -> 9.3.1

Motivation for this change
Update Mirage-IM dependencies (although the new version works OK without them).
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[ ] Fits CONTRIBUTING.md.

faker needs to go into python-unstable, cc @mweinelt

Yes, the python-unstable branch I believe. Based on previous matrix-nio bumps, that package causes under 10 rebuilds so you can split up this PR and send matrix-nio directly to master if you'd like to get it in faster.

Sorry, no. Needs to go into staging, python-unstable was merged two days ago.

What about this 11 commits?

These extra commits are from master, looks like you based your PR on the very tip of master. Since these commits haven't been auto-merged into staging yet they show up here when you change the base branch.
The solution is to rebase /just your/ commits onto $(git merge-base upstream/master upstream/staging) and then force push before changing the base branch

Can I just cherry-pick this modification in staging?

Yeah that works too now. The merge-base dance is just if you want to avoid the codeowners spam in the future


Add Unit test cases for Clair Client.

Coverage increased (+0.6%) to 56.197% when pulling b925569767bbcd252841937c5bbd0a314b3e10c4 on reasonerjt:master into 4d4b27b400a9278c7c53c09ac21ae83814416092 on vmware:master.


Fixing typos

This PR fixes a few typos I spotted.

Oh could you sign the commit?

Learn more about signing commits.

Oh could you sign the commit?

Done.

thank you @deining !


Horizon a10 appliance UI improvements

As a horizon user, I want a polished UI experience when creating a10 images and instances
When creating a10 images:

[ ] Add a visual distinction between the image source and the username, password so that a user doesn't think they're the credentials to download the image.
[ ] Add explanation of what the username, password, and api version are for
[ ] Consider letting the user use an existing glance image instead of a url

When creating a10 instances:

[ ] Use a password input for the password input
[ ] Filter list of images to only show a10 images. Will need to tag a10 images, which didn't work using v1/v2 client.

When listing a10 instances:

[ ] Filter list of instances to only show a10 instances. Will need to tag a10 instances or save 'em in a neutron service.

Oddly, tags are being added to the image but the filter doesn't work.  The docs say the following structure is a valid filter:
{"filters":
  "tag": "a10"
}

... but that filters returns all results.  I'd be happier to see if return zero results or blow up spectacularly if that filter is invalid.  At least then I know it's processing the filter.

Using an existing glance image for an upload doesn't seem useful - the user will already have access to that image in the Launch Appliance screen.  Eventually, I see this screen evolving into something that hits a web service, authenticates using user creds, and allows the user to pull A10 images in "automagically".

Regarding credentials for URLs... ugh.  Glance handles existing URLs not as gracefully as I'd like... how is it going to handle credentials?  I'm willing to find out, but am apprehensive.

Don't worry about credentials for URLs. Just make it obvious that these aren't credentials for the URL. They are the credentials for api control of instances spun-up from the image.


Adding support for G5 EGVRecord sizes

Let's discuss how you want to manage the versioning of the old and new versions of this record. It would also be good if we could get a G4 Share receiver with the new software update and see if a) this change is also compatible with it and b) how the device reports itself.

We need to add version/feature detection for 505 anyway.  The way decocare handles model vs pump capabilities is kind of nice (may be biased)... not sure how to apply it here, quite yet.
Perhaps G5EGV can inherit from EGVRecord, and some version sniffing smarts can delegate accordingly?

dexcom_reader should be able to identify models pretty easily.  All of that is in the firmware header page.  The following is what my un-upgraded Share receiver reports.
>>> import dexcom_reader.readdata as rd
>>> d = rd.Dexcom.FindDevice()
>>> dex = rd.Dexcom(d)
>>> print dex.GetFirmwareHeader().attrib
{'BLEVersion': '<IP_ADDRESS>', 'DexBootVersion': '3', 'BLESoftDeviceVersion': '<IP_ADDRESS>', 'RFVersion': '<IP_ADDRESS>', 'ApiVersion': '<IP_ADDRESS>', 'ProductName': 'Dexcom G4 Receiver with Share', 'SoftwareNumber': 'SW10586', 'TestApiVersion': '<IP_ADDRESS>', 'SchemaVersion': '1', 'PortVersion': '<IP_ADDRESS>', 'FirmwareVersion': '<IP_ADDRESS>', 'ProductId': 'G4ShareReceiver'}

Here's the G5 receiver:
{'DexBootVersion': '3', 'BLESoftwareVersion': '<IP_ADDRESS>/1.0.1', 'RFVersion': '1', 'ApiVersion': '<IP_ADDRESS>', 'ProductName': 'Dexcom G5 Mobile Receiver', 'SoftwareNumber': 'SW10617', 'TestApiVersion': '<IP_ADDRESS>', 'BLEHardwareVersion': 'HW003C', 'SchemaVersion': '1', 'ProductId': 'G5MobileReceiver', 'PortVersion': '<IP_ADDRESS>', 'FirmwareVersion': '<IP_ADDRESS>', 'BLEDeviceAddress': '1BE0E50482CF'}

Seems like ApiVersion is a good bifurcation point, agreed?

Here's my original g4:
>>> print dex.GetFirmwareHeader( ).attrib
{'DexBootVersion': '3', 'RFVersion': '<IP_ADDRESS>', 'ApiVersion': '<IP_ADDRESS>', 'ProductName': 'Dexcom G4 Receiver', 'SoftwareNumber': 'SW10050', 'TestApiVersion': '<IP_ADDRESS>', 'SchemaVersion': '1', 'PortVersion': '<IP_ADDRESS>', 'FirmwareVersion': '<IP_ADDRESS>', 'ProductId': 'G4Receiver'}
>>>

I have a Gen4 receiver with bluetooth that I just updated to the G5 software. I am away on my honeymoon now, but when I return on the 19th, I will test this out.

how is the progress coming on the reading the Dexcom G5 receiver? Have you guys tested it yet? Just got back from my trip and I am ready to jump in.

@esteward The branch in this PR works for reading G5 data, though there are some extra bits still undecoded for Meter, Insertion, and EGV entries.
This won't be merged as-is; we have to determine a plan for bifurcating records by version. Would you send over the output of GetFirmwareHeader( ).attrib for your upgraded G4 receiver? That'll be helpful in deciding where the split point is.

@loudnate I will apologize in advance as I am still a noob with many things on here. I would be more than happy to send you over the output of GetFirmwareHeader( ).attrib for my upgraded Gen 4 receiver. I am not sure out I do that though, would you mind walking me through that?

python
Python 2.7.3 (default, Mar 18 2014, 05:13:23)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.

from dexcom_reder.readdata import Dexcom
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named dexcom_reder.readdata
from dexccom_reader.readdata import Dexcom
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named dexccom_reader.readdata
from dexcom_reader.readdata import Dexcom
d = Dexcom(Dexcom.FindDevice())
d.GetFirmwareHeader().dict
{'attrib': {'DexBootVersion': '3', 'BLESoftwareVersion': '<IP_ADDRESS>/1.0.1', 'RFVersion': '1', 'ApiVersion': '<IP_ADDRESS>', 'ProductName': 'Dexcom G5 Mobile Receiver', 'SoftwareNumber': 'SW10617', 'TestApiVersion': '<IP_ADDRESS>', 'BLEHardwareVersion': 'HW003C', 'SchemaVersion': '1', 'ProductId': 'G5MobileReceiver', 'PortVersion': '<IP_ADDRESS>', 'FirmwareVersion': '<IP_ADDRESS>', 'BLEDeviceAddress': 'B192A69CEAC4'}, 'tag': 'FirmwareHeader', '_children': []}

d.GetFirmwareHeader().dict
{'attrib': {'DexBootVersion': '3', 'BLESoftwareVersion': '<IP_ADDRESS>/1.0.1', 'RFVersion': '1', 'ApiVersion': '<IP_ADDRESS>', 'ProductName': 'Dexcom G5 Mobile Receiver', 'SoftwareNumber': 'SW10617', 'TestApiVersion': '<IP_ADDRESS>', 'BLEHardwareVersion': 'HW003C', 'SchemaVersion': '1', 'ProductId': 'G5MobileReceiver', 'PortVersion': '<IP_ADDRESS>', 'FirmwareVersion': '<IP_ADDRESS>', 'BLEDeviceAddress': 'B192A69CEAC4'}, 'tag': 'FirmwareHeader', '_children': []}

The Dexcom record pages contain a header that provides a revision field.
The format is as follows:
fieldname      bytes

index          4
nRecs          4
recordType     1
revision       1
pageNumber     4
r1             4
r2             4
r3             4
j1             1
j2             1
``

When I parse an EGV record page header on my own device (Share2), I get a header of `PageHeader(index=56430, size=38, recordType=4, revision=2, pageNumber=1485, r1=0, r2=0, r3=0, j1=201, j2=71)`.  I suspect you will see `revision=3`, which could be handled slightly differently.

The ReadDatabasePartitionInfo is interesting as well.
<PartitionInfo SchemaVersion='1' PageHeaderVersion='1' PageDataLength='500'>
    <Partition Name='ManufacturingData' Id='0' RecordRevision='1' RecordLength='500'/>
    <Partition Name='FirmwareParameterData' Id='1' RecordRevision='1' RecordLength='500'/>
    <Partition Name='PCSoftwareParameter' Id='2' RecordRevision='1' RecordLength='500'/>
    <Partition Name='SensorData' Id='3' RecordRevision='1' RecordLength='20'/>
    <Partition Name='EGVData' Id='4' RecordRevision='2' RecordLength='13'/>
    <Partition Name='CalSet' Id='5' RecordRevision='3' RecordLength='249'/>
    <Partition Name='Aberration' Id='6' RecordRevision='1' RecordLength='15'/>
    <Partition Name='InsertionTime' Id='7' RecordRevision='1' RecordLength='15'/>
    <Partition Name='ReceiverLogData' Id='8' RecordRevision='1' RecordLength='20'/>
    <Partition Name='ReceiverErrorData' Id='9' RecordRevision='1' RecordLength='500'/>
    <Partition Name='MeterData' Id='10' RecordRevision='1' RecordLength='16'/>
    <Partition Name='UserEventData' Id='11' RecordRevision='1' RecordLength='20'/>
    <Partition Name='UserSettingData' Id='12' RecordRevision='3' RecordLength='48'/>
</PartitionInfo>

The revisions listed here match the headers listed for my receiver.  You can see it fairly easily for yourself with the following command:
>>> import dexcom_reader.readdata as rd
>>> d = rd.Dexcom.FindDevice()
>>> dex = rd.Dexcom(d)
>>> for item in dex.DataPartitions():
...     print item.attrib
...
{'RecordLength': '500', 'Name': 'ManufacturingData', 'RecordRevision': '1', 'Id': '0'}
{'RecordLength': '500', 'Name': 'FirmwareParameterData', 'RecordRevision': '1', 'Id': '1'}
{'RecordLength': '500', 'Name': 'PCSoftwareParameter', 'RecordRevision': '1', 'Id': '2'}
{'RecordLength': '20', 'Name': 'SensorData', 'RecordRevision': '1', 'Id': '3'}
{'RecordLength': '13', 'Name': 'EGVData', 'RecordRevision': '2', 'Id': '4'}
{'RecordLength': '249', 'Name': 'CalSet', 'RecordRevision': '3', 'Id': '5'}
{'RecordLength': '15', 'Name': 'Aberration', 'RecordRevision': '1', 'Id': '6'}
{'RecordLength': '15', 'Name': 'InsertionTime', 'RecordRevision': '1', 'Id': '7'}
{'RecordLength': '20', 'Name': 'ReceiverLogData', 'RecordRevision': '1', 'Id': '8'}
{'RecordLength': '500', 'Name': 'ReceiverErrorData', 'RecordRevision': '1', 'Id': '9'}
{'RecordLength': '16', 'Name': 'MeterData', 'RecordRevision': '1', 'Id': '10'}
{'RecordLength': '20', 'Name': 'UserEventData', 'RecordRevision': '1', 'Id': '11'}
{'RecordLength': '48', 'Name': 'UserSettingData', 'RecordRevision': '3', 'Id': '12'}
>>>

I'm moving development on this project into the openaps community namespace, so multiple people can take care of maintenance.
https://github.com/openaps/dexcom_reader/pull/1
These patches are really exciting, what's the status, are they backward/future compatible?

No, this PR isn't backwards-compatible. It was just an example of the G5 compatibility. It sounds like @mgranberry's discovery of the revision in the page header is the way to go! It just needs to be built.

G5

$ openaps use cgm-local  GetFirmwareHeader
{
  "DexBootVersion": "3",
  "BLESoftwareVersion": "<IP_ADDRESS>/1.0.1",
  "RFVersion": "1",
  "ApiVersion": "<IP_ADDRESS>",
  "ProductName": "Dexcom G5 Mobile Receiver",
  "SoftwareNumber": "SW10617",
  "TestApiVersion": "<IP_ADDRESS>",
  "BLEHardwareVersion": "HW003C",
  "SchemaVersion": "1",
  "ProductId": "G5MobileReceiver",
  "PortVersion": "<IP_ADDRESS>",
  "FirmwareVersion": "<IP_ADDRESS>",
  "BLEDeviceAddress": "8161B4A30ACC"
}

G5.
Configure the model:
 $ openaps use cgm-local  config -5
{
  "model": "G5"
}

Example

pi@murse:~/aps $ openaps use cgm-local  oref0_glucose --hours .2 --no-raw
[
  {
    "trend_arrow": "FLAT",
    "system_time": "2016-05-30T20:26:06",
    "direction": "Flat",
    "sgv": 119,
    "display_time": "2016-05-30T13:24:05",
    "date":<PHONE_NUMBER>000.0,
    "dateString": "2016-05-30T13:24:05",
    "device": "openaps://cgm-local",
    "type": "sgv",
    "glucose": 119
  },
  {
    "trend_arrow": "FLAT",
    "system_time": "2016-05-30T20:21:08",
    "direction": "Flat",
    "sgv": 115,
    "display_time": "2016-05-30T13:19:08",
    "date":<PHONE_NUMBER>000.0,
    "dateString": "2016-05-30T13:19:08",
    "device": "openaps://cgm-local",
    "type": "sgv",
    "glucose": 115
  }
]

This shipped in dexcom_reader, pip install -U dexcom_reader, over here: https://github.com/openaps/dexcom_reader


Blocks rendering issue with inline return

When there is an in-line return, the return character is displayed as the not-defined glyph and the block itself is larger than normal. The block is a different size based on how many in-line returns there are.
Also, if you add in-line returns, the block itself will grow over existing blocks instead of moving them to a different coord space in the editor.

use Libraries.Compute.Statistics.DataFrame
DataFrame frame
frame:LoadFromCommaSeparatedValue(
"Group,Amount
K-12,108
University,12
Adult Novice,4
Eduator,10
Professional, 0
None,8"
)
output frame:ToText()

Associated crash log
QuorumStudio.log


excluded kotlin-stdlib from the shaded jar

Attempted fix for #203

this needs more work to figure out


NoAnnotationError

I just did a fresh clone of your repo and an npm install, and I am seeing the exact same NoAnnotationError in the Chrome developer console.  This is chrome version 44.0.2403.157 (64-bit) on osx.
I also see it in an up to date version of Google Chrome Canary.
Are you not seeing these?

@ctindel ya I see the error again :/ sorry I'm looking into it again

can you git clone the repo again and run npm run clean-start

Yeah that seems to have fixed it.  I see what you changed, the problem was just that some angular files were missing from the webpack bundle?

yeah that might have been the case thanks for pinging me about it :+1:

Thanks for keeping an example repo that tracks the changes in angular2 so quickly!


Camera Not Available - This camera is being viewed by someone else

Expected Behavior
Live view of camera should work in Home app
Current Behavior
Get thumbnail preview in Home app but tapping on it to see live view generates error in title: "Camera Not Available - This camera is being viewed by someone else" along with a dimmed image of the camera view.
Steps to Reproduce (for bugs)
Using Cynical SecuritySpy, added 1 camera to HomeKit-Bridge, added camera as accessory.
Versions
v 1.0.2
Configuration
No special configuration
Homebridge Log / Command Output
May 16 10:40:23 nodessertro IndigoServer[467]: HomeKit Bridge Error	Exception in plugin.serverButtonRunAction_Edit line 3313: 'key id 775840116 not found in database'
May 16 10:40:35 nodessertro IndigoServer[467]: HomeKit Bridge Error	Exception in plugin.serverButtonRunAction line 3193: invalid literal for int() with base 10: '277ee55af3d65651c42533b91b8e3fd5c2b7aa32f8cfa2fbe00f42e7c5d6cf22'
May 16 10:41:07 nodessertro IndigoServer[467]: HomeKit Bridge Error	Exception in homekit.deviceInitialize line 877: local variable 'obj' referenced before assignment
May 16 10:41:07 nodessertro IndigoServer[467]: HomeKit Bridge Error	Exception in homekit.detCharacteristicValues line 1031: 'key id 775840116 not found in database'
May 16 15:18:37 nodessertro IndigoServer[467]: HomeKit Bridge Error	Exception in plugin.serverFormFieldChanged_Device line 3595: 'key objectType not found in dict'
May 16 15:18:37 nodessertro IndigoServer[467]: HomeKit Bridge Error	Exception in plugin.serverFormFieldChanged_Action line 3654: 'key objectType not found in dict'
May 16 15:55:47 nodessertro IndigoPluginHost[1823]: ascii dump: CommandServerWriteLog[2019-5-16 15:26:04] Loaded plugin: homebridge-camera-ffmpeg
[2019-5-16 15:26:04] Registering platform 'homebridge-camera-ffmpeg.Camera-ffmpeg'
[2019-5-16 15:26:04] ---
[2019-5-16 15:26:04] Loaded plugin: homebridge-indigo2
[2019-5-16 15:26:04] Registering platform 'homebridge-indigo2.Indigo2'
[2019-5-16 15:26:04] ---
[2019-5-16 15:26:04] Loaded config.json with 0 accessories and 2 platforms.
[2019-5-16 15:26:04] ---
[2019-5-16 15:26:04] Loading 2 platforms...
[2019-5-16 15:26:04] [HomeKit Bridge Server] Initializing Indigo2 platform...
[2019-5-16 15:26:04] [HomeKit Bridge Server] HomeKit Bridge base URL is http://<IP_ADDRESS>:8558
[2019-5-16 15:26:04] [HomeKit Bridge Server] HomeKit Bridge serverId is 52436507
[2019-5-16 15:26:04] [Camera-ffmpeg] Initializing Camera-ff ... 5-16 15:50:19] [HomeKit Bridge Server] (MEDIA ROOM) Floor Lamp Hue 2: get(Saturation) => 0
[2019-5-16 15:50:19] [HomeKit Bridge Server] (MEDIA ROOM) Rear Overheads: get(Brightness) => 0
[2019-5-16 15:50:19] [HomeKit Bridge Server] (MEDIA ROOM) Rear Overheads: get(On) => false
[2019-5-16 15:50:19] [HomeKit Bridge Server] Mel's Lamp: get(On) => false
[2019-5-16 15:50:19] [HomeKit Bridge Server] (MEDIA ROOM) Front Overheads: get(Brightness) => 0
[2019-5-16 15:50:19] [HomeKit Bridge Server] (MEDIA ROOM) Front Overheads: get(On) => false
[2019-5-16 15:50:19] [HomeKit Bridge Server] Under Counter: get(On) => true
[2019-5-16 15:50:19] [HomeKit Bridge Server] Sink Overheads: get(On) => false
[2019-5-16 15:50:19] [HomeKit Bridge Server] Island Overheads: get(On) => false
[2019-5-16 15:50:19] [HomeKit Bridge Server] Bench Overheads: get(On) => false
[2019-5-16 15:50:19] [Camera-ffmpeg] Snapshot from (CAMERA) Front Door at 480x270

Device Simulation Report
DEVICE SIMULATION DATA
Service :
	alias : (CAMERA) Front Door
	model :
	subModel :
	indigoType : indigo.Device
	pluginType : indigo.Device.org.cynic.indigo.securityspy.camera
	type : CameraRTPStreamManagement
	desc : Camera RTP Stream
	objId : 89106128
	serverId : 52436507
	invertOnState : False
	convertFahrenheit : False
	required : (List)
		SelectedRTPStreamConfiguration<EMAIL_ADDRESS>		SetupEndpoints :
		SupportedAudioStreamConfiguration :
		StreamingStatus :
		SupportedVideoStreamConfiguration<EMAIL_ADDRESS>		SupportedRTPConfiguration<EMAIL_ADDRESS>	optional : (List)
		Name
	native : True
	requiresPlugin : (List)
	actions : (List)
	loadOptional : False
	characterDict : (Dict)
		SupportedVideoStreamConfiguration<EMAIL_ADDRESS>		SelectedRTPStreamConfiguration<EMAIL_ADDRESS>		SupportedRTPConfiguration<EMAIL_ADDRESS>

This is currently an issue with Homebridge and not the plugin.  The ffmpeg libraries broke a little while back, no word on when they will be operable again.  I wish I had them back too but for now there isn’t much that can be done.

Thanks for the quick reply. Such a drag. I was so excited that I actually
got it halfway working.
On Thu, May 16, 2019 at 4:10 PM Colorado Four Wheeler <
<EMAIL_ADDRESS>wrote:

This is currently an issue with Homebridge and not the plugin. The ffmpeg
libraries broke a little while back, no word on when they will be operable
again. I wish I had them back too but for now there isn’t much that can be
done.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Colorado4Wheeler/HomeKit-Bridge/issues/130?email_source=notifications&email_token=AL3FWKM4UZNSCLNEOMPY2A3PVXSWNA5CNFSM4HNQZ772YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVTJF4Q#issuecomment-493261554,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL3FWKKPUP5EDXAFD5C2K6TPVXSWNANCNFSM4HNQZ77Q
.


Support Non-Isomorphous Inputs

It may be impossible to supply multiple mtz files without --separate-files in the current experimental branch. I should check on this and write a test.

Just to comment on this -- the default behavior in rs for rs.concat(), DataSet.append(), DataSet.join(), and DataSet.merge() is to use the first cell in the list (or for the DataSet ones, to keep the cell of the calling DataSet). Each of the methods also have a check_isomorphous=True argument, that can be set to False to avoid this check.
Those methods and the check_isomorphous flag may provide a simple way to implement this sort of behavior.


[Bug] Compressed backups use unconventional file extensions

Documentation

[x] I acknowledge that I have read the relevant documentation.

Describe the bug

Gzip compressed backups have the file extensions in the wrong order. They are named:
backup.2024-10-13T02_00_00Z.gzip.sql
Which means you cannot just decompress them, since gzip does not recognize the .sql extension:
$ gunzip backup.2024-10-13T02_00_00Z.gzip.sql
gzip: backup.2024-10-13T02_00_00Z.gzip.sql: unknown suffix -- ignored

It would be better if the files are called *.sql.gz so they can be recognized by tools like gunzip by default.
Expected behaviour

Steps to reproduce the bug

Create a gzip compressed backup.
Check the created filename.

Environment details:

Kubernetes version: 1.30.5+k3s1
Kubernetes distribution: k3s
mariadb-operator version: 0.34.0
Galera data-plane version (init and agent): N/A
Install method: helm

Additional context

Hey @pkerwien ! Thanks for raising this.
Although I agree, we should follow conventional extensions to leverage existing tooling, this change implies breaking changes, as there will be user who already have backups taken with previous versions of the operator. For this reason, we should also think about the migration path as part of this issue. I'm thinking about the following options:

Declare a breaking change in the release notes and provide a migration script.
Include a migration step for old backups as part of the operator's backup subcommand.


[🐞] Cookies return stale values server-side

Which component is affected?
Qwik City (routing)
Describe the bug
When updating a cookie, it does not persist its value within the same execution cycle. Reading it immediately after being set returns a stale value server-side.
Reproduction
Add onRequest to Qwik-Starter
Steps to reproduce
In Qwik-starter add this code:
export const onRequest = (event: RequestEvent) => {
  let cookieValue: any = event.cookie.get("qwik-cookie")?.json();
  console.log("cookie value on entry =", cookieValue);
  let message: string;

  // SET TO FOO
  message = "foo";
  event.cookie.set("qwik-cookie", { message });
  cookieValue = event.cookie.get("qwik-cookie")?.json();
  console.log(`cookie value should === '${message}'`, cookieValue);

  // SET TO BAR
  message = "bar";
  event.cookie.set("qwik-cookie", { message });
  cookieValue = event.cookie.get("qwik-cookie")?.json();
  console.log(`cookie value should === '${message}'`, cookieValue);
};

First Page load console output:
cookie value on entry = undefined
cookie value should === 'foo' undefined  <--- SHOULD BE 'foo'
cookie value should === 'bar' undefined  <--- SHOULD BE 'bar'

Reload Page console output:
cookie value on entry = { message: 'bar' }
cookie value should === 'foo' { message: 'bar' }  <--- SHOULD BE 'foo'
cookie value should === 'bar' { message: 'bar' }

System Info
System:
    OS: macOS 13.1
    CPU: (8) arm64 Apple M1
    Memory: 78.77 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 19.4.0 - ~/.nvm/versions/node/v19.4.0/bin/node
    npm: 9.2.0 - ~/.nvm/versions/node/v19.4.0/bin/npm
  Browsers:
    Chrome: 111.0.5563.146
    Firefox Developer Edition: 110.0
    Safari: 16.2
  npmPackages:
    @builder.io/qwik: 0.100.0 => 0.100.0
    @builder.io/qwik-city: ~0.100.0 => 0.100.0
    undici: 5.21.0 => 5.21.0
    vite: 4.2.1 => 4.2.1

Additional Information
There doesn't seem to be a workaround other storing and passing the latest value too all functions that might want to update it, which is highly impractical.

WORKAROUND
Here is a workaround until this issue is fixed.
import { type CookieOptions, type Cookie } from<EMAIL_ADDRESS>
// instantiate a cookie cache
const cookieCache: any = {};

// Save cookie to cache and then set cookie
const setCookie = (cookie: Cookie, name: string, value: any, options: CookieOptions) => {
  cookieCache[name] = value;
  cookie.set(name, value, options);
};

// Get cookie from cache or from cookie
const getCookie = (cookie: Cookie, name: string) => {
  return cookieCache[name] || cookie.get(name);
};

UPDATED WORKAROUND
LiveCookie is greatly based on core's cookie.ts logic and associated Pull Request #3667. At entry points, such as server$, simply create a new instance of the LiveCookie class and pass it to deeper functions that must update the cookies. Be cautious of creating closures, or 'unlikely' race conditions.
//
// USAGE EXAMPLE
//
import { LiveCookie } from '~/utils/LiveCookie';

export const signin_server = server$(async function () {
  const liveCookie = new LiveCookie(this.cookie);
  await foo( liveCookie );
  await bar( liveCookie );
});

//
// LiveCookie.ts Utility
//
import { type CookieOptions, type Cookie } from<EMAIL_ADDRESS>
const LIVE_COOKIE = Symbol('live-cookies');

export class LiveCookie {
  cookie: Cookie;
  private [LIVE_COOKIE]: Record<string, string | null> = {};

  constructor(cookie: Cookie) {
    this.cookie = cookie;
    const cookies = Object.entries(cookie.getAll()).reduce(
      (obj: Record<string, string | null>, [key, value]) => {
        obj[key] = typeof value === 'string' ? value : value.value;
        return obj;
      },
      {}
    );
    this[LIVE_COOKIE] = cookies;
  }

  set(name: string, value: any, options: CookieOptions) {
    this[LIVE_COOKIE][name] = value;
    this.cookie.set(name, value, options);
  }

  get(name: string) {
    const value = this[LIVE_COOKIE][name];
    if (!value) {
      return null;
    }
    return {
      value,
      json() {
        return JSON.parse(value);
      },
      number() {
        return Number(value);
      },
    };
  }

  has(cookieName: string) {
    return !!this[LIVE_COOKIE][cookieName];
  }

  delete = (name: string) => {
    this.cookie.delete(name);
    this[LIVE_COOKIE][name] = null;
  };
}

Fixed! https://github.com/BuilderIO/qwik/issues/3625


[iOS] Image misaligned when wrapped inside Text Vs outside text

When we have an image inside text and the same image outside Text, they are misaligned.
Environment
Environment:
OS: macOS Sierra 10.12.6
Node: 8.9.1
Yarn: 1.3.2
npm: 5.6.0
Watchman: 4.7.0
Xcode: Xcode 9.0 Build version 9A235
Android Studio: Not Found
Packages: (wanted => installed)
react: 16.3.1 => 16.3.1
react-native: 0.55.1 => 0.55.1
Steps to Reproduce

Create a view with style of flexDirection: 'row'
Create two images (use the same image and apply same height and width on both)
Wrap one image inside a text component.

Actual Behavior

The image wrapped inside the text component is not aligned correctly with the image outside the text.

@react-native-bot Reproduced the issue on 0.55.1


How to  Integration User Account and Authentication LDAP?

When I config the uaa.yml on uaa server,  then restart the uaa server , all config has resotre, why?
Anther issue,  can’t   click  the apply change  on OPS Manager dashboard.

It seems you are running a PCF manager. For that, please go through the official support channel.
A standalone UAA would not overwrite its configuration file.
In a Cloud Foundry environmnent, the configuration files will always be overwritten by the manifest.


Interpreted a variable named events as DOM Event

Product and Version [VSCode]:
OS Version [Windows]:10
IntelliCode Extension Version: 1.1.6
Target Platform or Language [e.g. Node.js]:Nodejs
Steps to Reproduce / Scenario:

Declare a variable with a name event data type does not matter
Try to access as of it's properties with dot notation

false alarm


Discussion for the Microsoft.AspNetCore.App implicit version

Leave comments/questions about the Microsoft.AspNetCore.App implicit version.
Copy from @natemcmaster
After reviewing customer feedback and lots of design discussion, we think the implicit package version has created more confusion than help. We are planning to change course and go back to recommending using the Version attribute on the PackageReference to Microsoft.AspNetCore.App/All.
See https://github.com/aspnet/Home/issues/3292.

I've changed the PackageReferences in my projects from Microsoft.AspNetCore.All to Microsoft.AspNetCore.App (without version number) as was suggested by the ASP.NET Core 2.0 to 2.1 migration guide. After that I got a bunch of build warnings like this:
Warning NU1604: Project dependency Microsoft.AspNetCore.App does not contain an inclusive lower bound. Include a lower bound in the dependency version to ensure consistent restore results.
Warning NU1602: [Project Name] does not provide an inclusive lower bound for dependency Microsoft.AspNetCore.App. An approximate best match of Microsoft.AspNetCore.App 2.1.0 was resolved.
The Microsoft.AspNetCore.App description here contains the following phrase: "The Microsoft.AspNetCore.App metapackage is not a traditional package that is updated from NuGet." If it's not a normal NuGet package, I would expect that I should not be getting NuGet warnings for it.  Getting build warnings when everything is actually fine is annoying and creates a risk that after some time I'll stop paying attention to build warnings at all and miss some "genuine" warning.
I don't think NU1602 and NU1604 should be suppressed at the project level, as these warnings make sense for "normal" NuGet packages. I tried to disable these warnings for the PackageReferences for Microsoft.AspNetCore.App using the instructions from here:
<PackageReference Include="Microsoft.AspNetCore.App">
  <NoWarn>NU1602,NU1604</NoWarn>
</PackageReference>

I got fewer build warnings, but some projects still reported them. These projects themselves did not contain PackageReferences for Microsoft.AspNetCore.App, but they referenced other projects that did. To suppress warnings for these projects, I had to add PackageReferences for Microsoft.AspNetCore.App to their .csproj files. Then I was able to build the solution without warnings.
If it's relevant - I'm using Visual Studio 2017 Community Edition, version 15.7.3
My question is - is there a simpler way to suppress build warnings for Microsoft.AspNetCore.App package? It would be also good to update documentation for this metapackage and include an instruction of how to suppress them.

@JunTaoLuo please comment.

The warnings you are getting suggests that you are using the 2.0 SDK which doesn't contain the logic that sets the implicit versions for Microsoft.AspNetCore.App. Do you have the latest 2.1 SDK (2.1.300) installed? See: https://www.microsoft.com/net/download/

Hello @JunTaoLuo,
I have it installed on my workstation:

I also have a lot of older SDKs installed, so that might be causing the problem...

Hmm then I'm curious why it's not working. What does dotnet --info say? I'm not sure installing previous SDKs will resolve the issue but it may help.

Here's the output of dotnet --info:
.NET Core SDK (reflecting any global.json):
 Version:   2.1.300
 Commit:    adab45bf0c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.300\

Host (useful for support):
  Version: 2.1.0
  Commit:  caa7b7e2ba

.NET Core SDKs installed:
  1.0.0-preview2-003131 [C:\Program Files\dotnet\sdk]
  1.0.0-preview2-1-003177 [C:\Program Files\dotnet\sdk]
  1.0.0 [C:\Program Files\dotnet\sdk]
  1.0.2 [C:\Program Files\dotnet\sdk]
  1.0.3 [C:\Program Files\dotnet\sdk]
  1.0.4 [C:\Program Files\dotnet\sdk]
  1.1.0 [C:\Program Files\dotnet\sdk]
  2.0.0 [C:\Program Files\dotnet\sdk]
  2.0.2 [C:\Program Files\dotnet\sdk]
  2.0.3 [C:\Program Files\dotnet\sdk]
  2.1.2 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.100 [C:\Program Files\dotnet\sdk]
  2.1.101 [C:\Program Files\dotnet\sdk]
  2.1.102 [C:\Program Files\dotnet\sdk]
  2.1.103 [C:\Program Files\dotnet\sdk]
  2.1.104 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.300 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Hmm I'm unable to reproduce the issue locally, but I also don't have many older SDKs installed so that may be the problem. Are you able to reproduce the issue on the command line with dotnet restore? If so, can you collect the msbuild binlog and share it with me so I can debug (run dotnet restore /bl and attach the msbuild.binlog)?

For me following change in csproj project file helped:  <Project Sdk="Microsoft.NET.Sdk">  -> <Project Sdk="Microsoft.NET.Sdk.Web">
My case was a class library project that was converted from 2.0 to 2.1 and had a following reference:
<PackageReference Include="Microsoft.AspNetCore.App" />
Using Visual Studio 15.7.3 and 2.1.300 SDK.

Sorry for the slow response, but as @ToTameALand mentioned the problem here is that the SDK must be set to Microsoft.NET.Sdk.Web for the implicit version to be set correctly. The sample at https://docs.microsoft.com/en-us/aspnet/core/fundamentals/metapackage-app?view=aspnetcore-2.1 shows this but maybe we can make this more explicit @Rick-Anderson ?

@JunTaoLuo, @ToTameALand, thank you for looking into this! You are right, all projects in my solution that produced the NuGet build warnings indeed use Microsoft.NET.Sdk instead of Microsoft.NET.Sdk.Web. I assume that they use Microsoft.NET.Sdk because they are class libraries, not ASP.NET Core projects. It looks like I should not have added references to Microsoft.AspNetCore.App there in the first place...
I've removed the references to Microsoft.AspNetCore.App from my class libraries, actual ASP.NET Core projects still reference Microsoft.AspNetCore.App. I don't get any warnings when building my solution now.
As regards https://docs.microsoft.com/en-us/aspnet/core/fundamentals/metapackage-app?view=aspnetcore-2.1, a warning like "Do not add a reference to Microsoft.AspNetCore.App to your class library, it won't work properly" could be included there, so that another developer wouldn't make the same mistake that I did.

Same issue here, the comment https://github.com/aspnet/Docs/issues/6430#issuecomment-394864697
help me remove warning

When I install current SDK (2.1.301) and publish default web applicatation to azure with implicit version, I get:
HTTP Error 502.5 - Process Failure
App Service Development Console in Azure Portal:
> dotnet --info
D:\home\site\wwwroot
.NET Core SDK (reflecting any global.json):
 Version:   2.1.300
 Commit:    32f29b6eb9

> dotnet webapplication1.dll
D:\home\site\wwwroot
It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '2.1.1' was not found.

If it is recommended to use implicit version, then WTF?

It looks like azure doesn't have the 2.1.301 SDK or the 2.1.1 runtime installed yet. @davidebbo do you know when the new bits will be available?

Previous comment was 3 days ago, and deployment completed Friday morning PST. My guess is that at the time @Liero tried it wasn't there yet, but got there shortly after. Please try again.

@JunTaoLuo: my point is, that following recommended practices results in very poor developer experience. Do you think that application startup failure caused just by installing latest SDK locally that differs only in patch version is predictable and expected behavior? If no, then do something about it.

@Liero In general we don't expect to increment the implicit version of the Microsoft.AspNetCore.App metapackage during patches, as described in the documentation: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/metapackage-app?view=aspnetcore-2.1. However, during this release, we realized there were some issues with our version ranges that could lead to more warnings and errors in future patches so we needed to modify the metapackage and increment the implicit version used by apps targeting netcoreapp2.1. We hope we don't have to do this in the future so this should not happen again.

@iancooper what kind of warnings are you seeing? The reason we updated the base implicit version this release was to avoid such warnings so I'd be interested to see why it didn't work for you.

I am using Razor pages and seeing this warning. How do I fix the issue? Here is my .csproj file:
<Project Sdk="Microsoft.NET.Sdk.Razor">

  <PropertyGroup>
	<TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
	<PackageReference Include="Microsoft.AspNetCore.App">
		<NoWarn>NU1604</NoWarn>
	</PackageReference>
  </ItemGroup>

</Project>

@mrlife  <Project Sdk="Microsoft.NET.Sdk.Web">

The implicit version gave me build errors in VSTS, although I am using SDK 2.1.301 there (as I do locally). I reference the Microsoft.Net.Sdk.Web and updated the other necessary NuGets for my project to 2.1.1 but in VSTS the build fails with NU1107 (version conflict), see https://github.com/aspnet/Home/issues/3250

After reviewing customer feedback and lots of design discussion, we think the implicit package version has created more confusion than help. We are planning to change course and go pack to recommending using the Version attribute on the PackageReference to Microsoft.AspNetCore.App/All.
See https://github.com/aspnet/Home/issues/3292.

I am struggling with this right now with a ton of these errors:

If I pin my App version at 2.1.4 I have no issues. I do not understand these errors, my test project never references Microsoft.AspNetCore.Authentication <IP_ADDRESS> my parent project never references Microsoft.AspNetCore.Authentication <IP_ADDRESS>. And Icant even find any transitive dependencies that reference those numbers. So what is going on here? Did we decide that everyone should start pinning versions? I may have misread but the linked aspnet issue says "[Nate: July 9]: this was not implemented, and we are not planning to implement right now." so are we NOT deciding to stop generating templates using an implicit .App version?
Test Project
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <RootNamespace>MyIdentityServer.UnitTests</RootNamespace>
    <LangVersion>latest</LangVersion>
    <IsPackable>false</IsPackable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.8.0" />
    <PackageReference Include="Moq" Version="4.9.0" />
    <PackageReference Include="xunit" Version="2.4.0" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\..\src\MyIdentityServer\MyIdentityServer.csproj" />
  </ItemGroup>

</Project>

SUT
<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <LangVersion>latest</LangVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="ComponentSpace.Saml2.Licensed" Version="2.0.6" />
    <PackageReference Include="IdentityServer4" Version="2.2.0" />
    <PackageReference Include="IdentityServer4.EntityFramework" Version="2.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="2.1.3" />
    <PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.1.4" />
    <PackageReference Include="Serilog.AspNetCore" Version="2.1.1" />
    <PackageReference Include="CustomDataProtection" Version="2.0.0" />
  </ItemGroup>
</Project>

@VictorioBerra Try specifying an explicit version for AspNetCore.App (e.g. 2.1.3) and set the  to the same version (e.g. below ). For console or .Net Standard library also specify the same RuntimeFrameworkVersion. That way you will have all projects running with the same Core SDK and packages.

@VictorioBerra This is the same issue as https://github.com/aspnet/Mvc/issues/7710. The solution is to add a versionless reference to Microsoft.AspNetCore.App: <PackageReference Include="Microsoft.AspNetCore.App" /> to your test project and change the sdk from Microsoft.NET.Sdk to Microsoft.NET.Sdk.Web

@JunTaoLuo Thanks! so in 2.2 or 3.0 is this supposed to be resolved without having to add App and Web to a NON-web test project? Just seems ugly/hacky.

@zuckerthoben I hope I can avoid lucking runtime versions with RuntimeFrameworkVersion. Something I liked about the All metapackage was that when i upgraded that, I knew I had all the latest fixes. And if my app didn't run, it was obvious I was missing that specific runtime and i would install it and be on my way.
In short, upgrading using NuGet was just easier.

@JuanMejiaVelez Actually, this did not solve my issue. I get the same errors if I change my test project to .Web and add a versionless app reference.

I will try to repro. I am actually getting inconsistent behavior now that I have been flipping everything around with versions/web. I can't even get my orig errors to come back.

@JunTaoLuo I was able to repro! https://github.com/VictorioBerra/aspnet-Docs-issues-6430
git clone https://github.com/VictorioBerra/aspnet-Docs-issues-6430.git
Essentially I created new apps with dotnet new mvc/xunit and then I added all the packages I am using, and I also picked something random from Microsoft.AspNetCore.Authentication to use in my HomeController.
Now when I open the solution I get the same error:

If you could let me know the solution i would really appreciate it.
Versions
Visual Studio Enterprise 15.8.2
dotnet info
U:\>dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.401
 Commit:    91b1c13032

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.401\

Host (useful for support):
  Version: 2.1.3
  Commit:  124038c13e

.NET Core SDKs installed:
  1.0.0-preview2-003121 [C:\Program Files\dotnet\sdk]
  1.0.0-preview2-003131 [C:\Program Files\dotnet\sdk]
  1.0.0-preview2-1-003177 [C:\Program Files\dotnet\sdk]
  1.0.3 [C:\Program Files\dotnet\sdk]
  1.1.0 [C:\Program Files\dotnet\sdk]
  2.0.0 [C:\Program Files\dotnet\sdk]
  2.0.2 [C:\Program Files\dotnet\sdk]
  2.0.3 [C:\Program Files\dotnet\sdk]
  2.1.2 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.101 [C:\Program Files\dotnet\sdk]
  2.1.102 [C:\Program Files\dotnet\sdk]
  2.1.103 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.300 [C:\Program Files\dotnet\sdk]
  2.1.301 [C:\Program Files\dotnet\sdk]
  2.1.302 [C:\Program Files\dotnet\sdk]
  2.1.400 [C:\Program Files\dotnet\sdk]
  2.1.401 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

U:\>

I was able to build the Sample test project by applying the fix I mentioned in the comment above: https://github.com/VictorioBerra/aspnet-Docs-issues-6430/pull/1. Let me know if this works for you.

Replying here to keep the discussion in one place:
@JunTaoLuo this seems to work just fine. Although I really do dislike the idea of having to target a web Sdk via a test project. What will be the approach in 2.2 or 2.3? I assume this is not a permanent workaround?

@natemcmaster has more up to date information on this but I think it's the same for 2.2. However for the release after that, it will be reworked.

@JunTaoLuo I noticed a new problem related to all this I think. If you run this following command in the fixed version of the PR you gave me you get the following error:
Command
dotnet ef migrations list
Error
me@DESKTOP MINGW64 /c/Users/me/Desktop/temp/corebug/src/SampleMVC (JunTa                                                                                oLuo-johluo/fix)
$ dotnet ef migrations list
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileLoadException: Could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor..ctor(Object reportHandler, IDictionary args)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.EntityFrameworkCore.Tools.ReflectionOperationExecutor..ctor(String assembly, String startupAssembly, String projectDir, String dataDirectory, String rootNamespace, String language)
   at Microsoft.EntityFrameworkCore.Tools.Commands.ProjectCommandBase.CreateExecutor()
   at Microsoft.EntityFrameworkCore.Tools.Commands.MigrationsListCommand.Execute()
   at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
   at Microsoft.EntityFrameworkCore.Tools.Program.Main(String[] args)
Exception has been thrown by the target of an invocation.

Updating all NuGets fixed this issue somehow.

FYI, there's currently ongoing work with how references to Microsoft.AspNetCore.App should work, see https://github.com/dotnet/sdk/pull/2501.

And update on my previous comment https://github.com/aspnet/Docs/issues/6430#issuecomment-403296211 in which I said

After reviewing customer feedback and lots of design discussion, we think the implicit package version has created more confusion than help. We are planning to change course and go back to recommending using the Version attribute on the PackageReference to Microsoft.AspNetCore.App/All.

Part of this has changed. We still believe the implicit package version is confusing, but after testing and experimenting with alternatives, we do not have a solution for 2.1 or 2.2 that we feel is significantly better. We are planning to change course in 3.0 and rework how this all works, but that is pretty far away.
Therefore, our recommendation for now is that users reference Microsoft.AspNetCore.App like this:
<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

We have made a few changes to the 2.2 SDK to make this work better for test projects, and will continue to improve our docs and guidance for how to deal with the issues with this design. Again, we hope to fix many of these issues in 3.0 with a refactoring of the way shared frameworks are referenced.

@natemcmaster Thanks a lot for keeping us up to date. Looking forward to 2.2 and removing the .Web SDK from my test projects.

I have a netstandard2.0 class library that references some AspNetCore packages. Do I target reference the 2.2.0 version of these packages, or 2.2.1/2.2.2 where available?
I've read the metapackage docs, this issue and the issue referenced in the OP, but I couldn't find clear guidance on this.

I am wondering a similar question. @stijnherreman are you asking the same thing as this? https://github.com/aspnet/AspNetCore/issues/8626#issuecomment-474470270

@VictorioBerra I think that's a different issue, related to https://github.com/aspnet/Announcements/issues/324.

I have a simple netcoreapp2.1 framework dependent Web API application that contains an implicit reference to the Microsoft.AspNetCore.App package.  And, I have specified a RuntimeFrameworkVersion to indicate that the application must use a minimum runtime patch version; in this case version 2.1.9.
I am trying to test the behavior when only runtime patch version 2.1.8 is installed.  I am expecting an error to occur as described in the following document:
https://docs.microsoft.com/en-us/dotnet/core/versions/selection
The application runs without error and upon inspection, the dotnet.exe process is using runtime patch version 2.1.8.  This is not desirable.
Without doing a self-contained deployment, how can I force the Web API application to use a minimum runtime patch version and fail if the required runtime is not installed?
I think I am missing some key fundamental.  Roll-forward behavior is acceptable, but roll-backward behavior is not.

I definitely find the implicit version confusing, because I want to be able to change to for things like https://github.com/aspnet/Announcements/issues/239 -- I would expect new versions of packages all the way up to Microsoft.AspNetCore.App to be published such that they no longer accept the insecure transitive dependency so that I don't need to add new dependencies on things I get from the metapackage just to avoid insecure packages.

@scottmcm your feedback is consistent with what many others have said about this design. This feedback was part of the motivation for refactoring the way Microsoft.AspNetCore.App works in 3.0. One of the major changes here is that Microsoft.AspNetCore.App will no longer be a NuGet package at all, so you won't have to worry about metapackage versions and transitive dependencies and their related problems.

Thanks, @natemcmaster.  I'll look forward to 3.0 then.


[Event Request] Codeunit 23 Item Jnl.-Post Batch - OnAfterCheckItemAvailability

Hi, would it be possible to get an event OnAfterCheckItemAvailability in Codeunit 23 Item Jnl.-Post Batch, like this :

IsHandled := false;
            OnAfterCheckItemAvailability(ItemJnlLine,IsHandled);
            if not IsHandled then begin

                if ItemJnlTemplate.Recurring then
                    Window.Open(
                    Text001 +
                    Text002 +
                    Text003 +
                    Text004)
                else
                    Window.Open(
                    Text001 +
                    Text002 +
                    Text005);

                Window.Update(1, "Journal Batch Name");

            end;

    [IntegrationEvent(false, false)]
    local procedure OnAfterCheckItemAvailability(var ItemJournalLine: Record "Item Journal Line"; IsHandled: Boolean)
    begin
    end;

?
Thanks

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


What's the difference and relationship between spatial attention and self attention

Since both of the spatial and self attention are used in the modulated attention, in
my understanding both of these two parts are used to capture the spatial information, so may you tell me what's the difference and relationship between spatial attention and self attention.

same as this issue: https://github.com/zhmiao/OpenLongTailRecognition-OLTR/issues/15#issuecomment-514042191


Enable printing from scripts

This adds a module with some functions to be used in validators or minting policies to print information that is contained on the TxInfo to BuiltinString. The intended use is debugging. You have to jump through quite a few hoops to accomplish this, and I'm indebted to @facundominguez for finding out the main tricks.
However, even with the (mild) optimisations I took, the capabilities introduced here are not at all usable in production code. It seems to be inherently inefficient to work with BuiltinString, and even for very simple examples, printing the whole TxInfo will cause scripts to run over budget. It remains to be investigated which protocol parameters (?) and choices made during transaction generation we can tweak to temporarily allow bigger execution budgets.

It remains to be investigated which protocol parameters (?) and choices made during transaction generation we can tweak to temporarily allow bigger execution budget.

This is a concern when offering the code as a standalone library, since in cooked there is allowBigTransactions, right?


Progress bars / verbose flag etc

For algorithms, it might be nice to have an option to be able to track some information when running the routine.
For example, for CG, it migh bi interesting to check the current residual, for adam/lbfgs/... the value of the loss function, etc.
Should we maybe start to add something like a verbose flag for algorithms?

For low-level algorithms, I would not add a progressbar or output, but instead a callback, similar to what scipy does:
You can specify a function that will be called after each iteration with the current parameters.
For  higher level algorithms, such as 'CG - Sense Reconstruction', 'Superresolution-Reconstruction' etc I would agree that a verbose flag with progress bars is helpful.

I am also not sure... I would say for algorithms that are specifically designed to minimize/maximize a functional, it feels that the value of this functional at the current estimate is the minimium required information to be output. Further information is without doubt inherently linked to the algorithm of choice... regarding mypy, I unfortunately lack the experience to have an opinion :D

Add callback to:

[x] CG (#195)
[ ] ADAM
[ ] LBFGS
[ ] NUFFT ?? (#162)

For NUFFT, this would require looking at the looping logic used inside torchkbnufft..

Maybe something like:
from typing import TypedDict

class OptimizerStatus(TypedDict):
    solution: torch.Tensor
    iteration_number: int

class CgStatus(OptimizerStatus):
    solution_update: torch.Tensor
    objective_value: float # maybe this can be part of the parent class because we probably always want that?

def cg_print_current_status(current_status: CgStatus):
    """callback function which doesn't make any sense"""
    print(f'It {current_status['iteration_number']}: {current_status['solution']} + {current_status['solution_update']} - obj: {current_status['objective_value']}')


White-list dialog module methods in Electron IPC handler

This PR fixes an issue where Electron IPC handler allows the frontend part of the application to invoke any electron main process module API (bypassing sandbox/nodeIntegration configuration).
The issue is fixed by specifying a white-list of allowed modules/methods in the handler for dialog module. ElectronApp.callDialog types are updated to reflect that (breaking change, ElectronApp is marked as @beta).
This PR also suggests to remove ElectronApp.callShell and ElectronApp.callApp methods until a real use case  for such APIs emerges (breaking change, ElectronApp is marked as @beta, also couldn't find any usage of these APIs in iTwin/internal repositories).

@wgoehrig can you take a look at this?


[Incompatability] Standalone Ancient Scepter doesn't play nice with some reworked skills.

As the title says, the Scepter versions of some skills (As of testing, Commando Suppressive fire and Nade were affected) are bugged, and simply behave like the normal skill, but have a placeholder scepter name for the skill such as: "COMMANDO_SPECIAL_SCEPTER_NAME" or something of the like. I wouldn't be surprised if this was intended/a couldn't-be-bothered issue, as scepter compatibility is always asked for. I couldn't seem to upload an image of the issue, but I could probably get one to you over discord (TEA#9790). Here's the log from testing, in case it's needed.
LogOutput.log

Thanks for catching that! The skills work as intended, I just forgot to set their name properly. I'll fix it up.


Check if both parties are empty before auto-accepting trade

Sometimes, when Steam are having server issues, trade offers can be empty like this one. However, they are not really empty. Steam servers could be updating or whatever other reason.
And I noticed in this piece of code that it is not checked if the person who sent the trade is not asking for any items in return. I don't know if their API could actually return a empty trade offer for both parties, but it'd be better to check if both parties have no items before auto-accepting it... Better safe than sorry.

I don't know either but it definitely won't hurt to improve the check.

I was wondering if I should add a check for SteamMasterID in this case, but in the end decided that I don't want to deal with steam fuckups at all, it's better to ignore broken trade and don't bother it, who knows what could happen if we accepted it.

I agree...


Fix inconsistent handling of constraints comments with backtracking resolver

Resolves #1712.
Investigating the root cause of the issue led to what could be a faulty condition in the backtracking resolver.
self.existing_constraints will always be empty when a generated .txt file doesn't exist yet, but will contain all the generated file dependencies when it does exist, so the condition that is removed by this PR will always evaluate to False for all dependencies in this case.
Consequently, this condition in the writer will also evaluate to False, preventing the retrieval of the constraints annotations when an already existing .txt file is updated.
There may be a specific reason this condition is here, but since the information only seems relevant for annotating the dependencies, it doesn't seem to me that it is relevant.
The PR also adds a specific test that ensures that running pip-compile twice (once with a non-existing .txt file, and once when it already exists) provides the same output for both resolvers. Without the change in the PR, the test fails for the backtracking resolver, but passes for the legacy one.
Contributor checklist

[x] Provided the tests for the changes.
[x] Assure PR title is short, clear, and good to be included in the user-oriented changelog

Maintainer checklist

[x] Assure one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
[ ] Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

Not sure why the CI is failing, but it doesn't seem to be related to this PR, as the same error appears on other workflows (https://github.com/jazzband/pip-tools/actions/runs/3382935861/jobs/5618360528#step:10:257).

Not sure why the CI is failing, but it doesn't seem to be related to this PR, as the same error appears on other workflows (https://github.com/jazzband/pip-tools/actions/runs/3382935861/jobs/5618360528#step:10:257).

Yeah, that's unrelated to the PR. I'm gonna merge this anyway.


godot4-working

updated everything to work with godot 4, mostly fixing animation tree and character materials. some minor quality of life changes like making pilars their own scene and fixing collision

I'm afraid I can't merge this because this project template is specifically for the old Godot 3.5, for legacy compatibility.
For Godot 4 there is a different repository.
https://github.com/pemguin005/Third-Person-Controller--SoulsLIke-Godot4
A side note, I haven't posted that Godot4 repo to the Godot Library, because i have been in the works making a new controller, completely overhauling the former method and expanding on its functionality. It should be releasing here pretty soon. I'm just finishing sound FX, and the level map for it.


Basic Gates Workbook Tasks 1.8, 1.9, 1.10 V3

Basic Gates Workbook Tasks 1.8, 1.9, 1.10 V3

Seem to be ID conflicts, closing request


Update README with test instructions

Update README with instructions for people to run with their system Python, without having to use Tox/virtualenv, which might put them off. Also having Tox instructions is fine.
See also https://github.com/pylast/pylast/pull/121#issuecomment-69449692:

If you changed them to use python setup.py test, the test dependencies will be installed automatically. However, in order to get this working properly, we would need to add a test entry point.

This is done.


Running Commands on Remote Development Host Fails

Describe the bug
Running Doki theme installation/sticker&bg removal commands fail when working via remote development.
I'm fairly new to VSCode but it seems that Doki must be installed on both local and remote hosts for the theming to work properly - Themed CSS appear to not load when Doki Theme is not installed on the remote host.
A workaround is to simply run the commands on a non-remote window then command palette -> Reload Window
To Reproduce

Install fresh VSCode for Mac and the Remote-SSH (v0.84.0) extension
Set up SSH host and connect
Install Doki-Theme (v84.1.6) on both local and remote hosts
Command Palette -> >Doki-Theme: Install Vanilla's Sticker (etc)
Follow the sudo chmod instructions in the Asset Installation Help (etc) window
Repeat >Doki-Theme: Install Vanilla's Sticker (etc)

Expected Behavior

Running the same command after following the chmod instructions should work.
Should be able to run these commands in the remotely connected window.

Environment
Version: 1.69.2 (Universal)
Commit: 3b889b090b5ad5793f524b5d1d39fda662b96a2a
Date: 2022-07-18T16:12:57.074Z (2 wks ago)
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 21.4.0
Doki-Theme (v84.1.6)
Logs
This seems to be the only log with a stacktrace, but I can provide other logs if needed.
window.log
Note
Perhaps related to https://github.com/doki-theme/doki-theme-vscode/issues/164

Hmm, that sounds similar to this comment?
https://github.com/doki-theme/doki-theme-vscode/issues/131#issuecomment-1066969847
If it is, where does yours normally fail? Because last I tried the assets get carried over in the new VS Code that gets brought up.

Reading through the comment, I'm not entirely sure if it's the same issue. For me, the themes (once installed locally) will show up correctly in both local and remote environments. The issue is mainly that I'm unable to run commands to install/remove themes while on a remotely connected window.
Not sure if this recording is helpful but in it I demonstrate attempting to add stickers/bgs in a remote window and it failing, even after changing ownership of files as per the helper tabs. I then do the same commands on a local window which succeeds. Reloading both windows will successfully display the sticker/bg. I repeat the same for the removal commands.
Interestingly, the sticker still shows up in the help info tab when the command fails on the remote window, even though it should be uninstalled.

The issue is mainly that I'm unable to run commands to install/remove themes while on a remotely connected window.

Ah that's because the your vscode running on your MacBook is acting as a client (front-end) to your remote session. Which explains why the removal on your non connected works for both of your VSCode windows.
The issue is that when you are connected to your remote session, the guts (backend) of vscode are provided by the remote code server. So when you run the command there, it's  different environment.
I think you just need to run the command once on your non-connected VS code instance, and it will carry over (based on the gif you uploaded, which was handy, thanks!).
That should fix your issue, correct?

As an aside, I don't usually upload recordings to github but is there an easy way to upload files larger than 10mb? Had to compress the recording to a gif (no scrubbing) due to filesize limits

I'm on a MacBook, so I normally just do the screen recording then just use ffmpeg to convert to mp4, ex
ffmpeg -i Screen\ Recording\ 2022-07-13\ at\ 3.00.31\ PM.mov -vcodec h264 -acodec mp2 animation.mp4

you can also adjust the sizing during conversion as well to make it smaller, but typically the mp4 is smaller

If the behavior of needing to run the commands on a local environment is intended, then I'd say that's okay! (As opposed to somehow being able to pass those commands back to a local env context)
However, if that's the case I think for usability purposes it might be nice if the helper tab that gets opened up can either detect it's in a remote environment and show an appropriately tailored helper tab, or to include said information in the current set of helper tabs. (Something like "Hey, I think you're trying to run me in a remote context which won't work! Please try again in a local context." etc)
Either way, I appreciate the helpful info and context! And thank you for the ffmpeg tip as well! I always forget how powerful ffmpeg is 😅
Finally, would it be better for this issue to be closed and to reopen with a feature request for the above or just keep it as is?

However, if that's the case I think for usability purposes it might be nice if the helper tab that gets opened up can either detect it's in a remote environment and show an appropriately tailored helper tab, or to include said information in the current set of helper tabs. (Something like "Hey, I think you're trying to run me in a remote context which won't work! Please try again in a local context." etc)

I'll include something that calls out the SSH connection explicitly. This plugin should work if running on a code server, but I don't think the SSH connection is the same (I can investigate more when I work #164 ).
So you can leave this open, I'll close it when I've added this to the help menu.
Thanks for providing helpful debugging information!


plumb through XLA HLO version of all_gather

We currently use our own implementation in terms of axis_index and psum, but IIUC the XLA HLO version can be more efficient in some cases.

This is done!


threetenbp and java 8

The public API exposes org.threeten.bp.Duration and other classes. Oops.
Figure out what to do when we move to Java 8. Keep it forever? Replace with java.time, bump the major version, and change the package?

That might have side effects on the client libraries. Given LTS, I'm not sure if we can move off of threeten if that's actively being used.

LTS shouldn't affect this. That's a separate branch.

@XN137 We don't have any plans at this moment. However, this is definitely a good improvement to our client libraries, we may implement this idea once we have some capacity.

Closing this issue in favor of tracking this topic in the generator https://github.com/googleapis/gapic-generator-java/issues/726