Allow pass name paramter in BaseMessageStringPromptTemplate

Based on OPENAI Cook book example, pass example_user and example_assisatant in message name is a way of few shot example, link is here .
response = openai.ChatCompletion.create(
model=MODEL,
messages=[
{"role": "system", "content": "You are a helpful, pattern-following assistant that translates corporate jargon into plain English."},
{"role": "system", "name":"example_user", "content": "New synergies will help drive top-line growth."},
{"role": "system", "name": "example_assistant", "content": "Things working well together will increase revenue."},
{"role": "system", "name":"example_user", "content": "Let's circle back when we have more bandwidth to touch base on opportunities for increased leverage."},
{"role": "system", "name": "example_assistant", "content": "Let's talk later when we're less busy about how to do better."},
{"role": "user", "content": "This late pivot means we don't have time to boil the ocean for the client deliverable."},
],
temperature=0,
)
Will you consider this feature in the future?

few-shot example do not need this kind of things. Just input it as normal Human input or system role input is enough. like:
here is some kind of examples for you:
user: New synergies will help drive top-line growth.
assistant: Things working well together will increase revenue.
user: Let's circle back when we have more bandwidth to touch base on opportunities for increased leverage.
assistant: Let's talk later when we're less busy about how to do better.

LLM just eat the whole input, the json data structure is just a program way, but eventually it will combine together and send to LLM

TLDR: This feature would be great to have in LangChain.
To my understanding,

The ChatGPT model (chat-davinci-003-alpha) is a language model designed for conversational interfaces, and thus operates slightly differently from previous GPT models such as text-davinci-002 and text-davinci-003.
Previous models were text-in and text-out (i.e. they accepted a prompt string and returned a completion to append to the prompt). The ChatGPT model (GPT-3.5A), however, is conversation-in and message-out (i.e. it expects a prompt string that is formatted in a specific chat-like transcript format, and returns a completion that represents a model-written message in the chat).

Differences:

Which means that few-shot learning with ChatGPT models looks closer to
<|im_start|>system
Translate from English to French
<|im_end|>
<|im_start|>system name=example_user
How are you?
<|im_end|>
<|im_start|>system name=example_assistant
Comment allez-vous?
<|im_end|>
<|im_start|>user
{{user input here}}<|im_end|>

Depending on how future models have been trained, passing examples as part of the system's input could make a big difference (e.g., providing protection against prompt injection).
Source: ChatGPT API: Prompt formatting
Also, see discussion in https://news.ycombinator.com/item?id=34988748.


Fixed #1847 - Flow: Unsteady Flow Crash

This bug was caused by an attempt to use an instance of a QuadTreeRectangle
that had previously been freed. QuadTreeRectangles are now allocated as shared
pointers to make chaching them for re-use by multiple Grid objects
easier. Populating a QuadTreeRectangle instance is an expensive operation
and it is desireable to re-use the tree as much as possible.

John, this PR should be equivalent to what you originally authored. Rolling back was becoming difficult on the previous branch, so I created this new branch and new PR. Please review and merge.

Was this branch forked from the flow branch, or from master? It appears like it came from master and doesn’t have flow support in it. Hence, I can’t test it.

On Oct 2, 2019, at 1:34 PM, Samuel Li<EMAIL_ADDRESS>wrote:
John, this PR should be equivalent to what you originally authored. Rolling back was becoming difficult on the previous branch, so I created this new branch and new PR. Please review and merge.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub, or mute the thread.

John Clyne
National Center for Atmospheric Research
303.497.1236 (w),<PHONE_NUMBER> (c)
<EMAIL_ADDRESS>

@clyne  how did you test it for your previous PR?
If you look at the commit history of the other PR (https://github.com/NCAR/VAPOR/pull/1856/commits), it's got one commit from you, and many commits from me. This current PR is equivalent to the point where your single commit was in and my subsequent commits were not.

My bad. I tested it by manually copying the changes into the flow branch. I wanted to fix to be on its own branch because it will affect other renderers besides flow.


Logging

Logging feature in the library and verbosity support in the ltd app.

This issue is handled by adding verbosity in fmt namespace.


Change robot model

Hi,
These days, I would like to replace the robot model with my own four-wheel differential model. But I don't know how to replace it. Could you give me some suggestions? Where should I change?

Hi,
You can launch your own robot from the launch file here: https://github.com/reiniscimurs/DRL-robot-navigation/blob/main/TD3/assets/multi_robot_scenario.launch#L7-L11
Please see other issues on changing the robot model, like: https://github.com/reiniscimurs/DRL-robot-navigation/issues/82

Hi,
Thank you for your reply. I have changed my robot, but I meet some difficulties. When I use command " python3 train_velodyne_td3.py", in rviz, there is only the model. Other than that, nothing happened. And the terminal displays  errors.

This is my multi_robot_scenario.launch file.

This is my mini.gazebo.launch file.

This is my xacro file.

And in the velodyne_env.py, I just modified the vehicle name

So could you give me some suggestions?

Hi,
in the first image you can see that you have an error. So it seems your subscriber is not getting any odom information from your subscriber. You should check your topic names and if they are subscribed to what they should be. Also, the issue might be in differential drive plugin so you should check that for your robot

Hi，
Thank you for your reply. Today,  I checked all the nodes and topics, and it seemed normal. But it don’t send "/cmd_vel" topics.  And I checked my differential drive plugin. It seems to be fine. I don't konw how to solve it. Could you give me some suggestions?
Thank you very much.
This is my differential drive plugin file.

Added:
When I first use command " python3 train_velodyne_td3.py", it prints many errors. And when I kill it, then use command " python3 train_velodyne_td3.py" again, it shows differently, but it still has errors.

I would suggest to first try understanding the error messages yourself, backtracking them and debugging them. And only after you have sincerely tried to understand (and googled them) to ask about issues here. There are many google answers to your p gain errors (which are not really errors). You are asking questions about things that are not part of this repo and something that you should be working on your own end about your own changes. Do actually investigate on your own end before asking questions.
For the other issue, your odom value is None because your subscriber is not returning any values. As you can see from your topics in rostopic list, your plugin does not seem to use robot namespace. So your topic names do no match where you subscribe to them and where they are published.

Hi，
Thank you for your patient response. I had solved my problems. The problem was the namespace. However, from topic list and rqt, “goal_point”"linear_velocity""angular_velocity" didn't publish. From rviz, we can't see the target point and the movement path. What could be the reason for this? And in the code, where are the set target points and action tracks displayed?

Are you sure they are not published? Because they are in your rostopic list. If you want to check if anything is published to a topic you can just read it at runtime with rostopic echo your_topic_name. If it outputs anything, it is eing published.
It seems to me that you are just not displaying anything in rviz. I suggest to familiarize yourself with rviz and follow some tutorials on how to display information there.

Thank you for your reply. I will try it.


How to make it work with Next.js?

What are the steps to make it work for Next.js project (pages router)?

No updates about this? I'm also interested

Hey! I've received a lot of requests for this feature, so I've decided to start working on an 'unplugin' plugin for this library ahead of the rewrite. This way, you'll be able to use it wherever you need!


Please document markdown SSR

Is your feature request related to a problem? Please describe.
It's unclear from the docs currently how to make a folder of markdown files and set a CSS module for it (blog, blog style / layout)
Describe the solution you'd like
Please document how to integrate markdown and how to style the markdown separately from the main app (for a blog)
Describe alternatives you've considered
Perhaps this could work with pure vite but I'm wary of getting sucked into workarounds and want to do it the idiomatic sveltekit way
How important is this feature to you?
Having a markdown blog is really important to me because it's much more readable than HTML
Additional context
One super cool thing would be to integrate roam research style [[wiki links]] -- with backlinks. This could make sveltekit a legit platform for Zettelkasten
Also, perhaps a svelte version of "MDX" To embed svelte components in markdown, would be epic, since we could make interactive data viz in our blogs
Just one man's opinion, I like the idea of markdown files "just working"

Perhaps this could go in a community-maintained recipe somewhere, but I don't think this belongs in Kit itself or in its official documentation.

https://github.com/sveltejs/sites uses Markdown as does https://github.com/sveltejs/kit/tree/master/examples/realworld.svelte.dev, so there are some examples you can follow


Add cf-rolling-restart v1.1.0

Adding a new plugin, cf-rolling-restart, to the community repo. Helps perform zero downtime restarts on PCF applications.

Closing PR and confirming the CLA has been signed by Home Depot. Will re-open based on @cfdreddbot's comment once confirmed.


People to talk to for all questions

How much overlap is there between the different Sami languages? What do they consst of.
Big enough difference for them to have their own stopword list?
What are the three Sami languages at https://www.nrk.no/sapmi
Sources of text to generate stopwords list from?
Other people I should talk to?

Closest Sami language center.

Difference:
Big enough differences: Yes. North- and Lule Sami has some overlap
Three Sami languages at https://www.nrk.no/sapmi

South Samin
Lule Sami
North Sami
Trying these news bulletins as source for stopword lists.

Traits
At least North Sami has a lot of prepositions and cases built into the words. This means there are a lot of different versions of words. Since the stopword list won't have any logic like stemming or lemmatization to it, we need to add all versions of words. But mostly this affects non-stopwords which means it may be easier to identify stopwords if they don't have a lot of different variants/versions.


ClientCertificateCredential undeclared type with azure_identity 0.11.0

Is ClientCertificateCredential supported in version 0.11.0 of the azure_identity crate?
I'm getting errors when I'm trying to use it in my project even though I'm pointing my toml at the latest version. I also noticed that the crates.io entry is missing the struct definitions for ClientCertificateCredential and CertificateCredentialOptions.
 Thank you in advance!

To use the client certificate features of the azure_identity crate, you need to specify the client_certificate feature.  Can you check that you have this feature enabled?


Succeeded in Python runtime, but failed in C++ runtime

System Info

CPU architecture: x86_64
CPU/Host memory size (if known): 40G
GPU name :RTX 3060-6G
TensorRT-LLM branch or tag TensorRT-LLM commit: TensorRT-LLM version: 0.14.0.dev2024092400
Versions of TensorRT, AMMO, CUDA, cuBLAS, etc. used: cuda 12.4, tensorrt 10.3.0
Container used (if running TensorRT-LLM in a container): nvcr.io/nvidia/tensorrt:24.08-py3
NVIDIA driver version: 550.107.02
OS : ubuntu22.04

Who can help?
No response
Information

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

Tasks

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

Reproduction

tried to run inference of tinyllama engine with C++ runtime based on executor API

root@dbedfb3d0654:/workspace/TensorRT-LLM/examples/cpp/executor/build# ./executorExampleBasic ../../../llama/tinyllama-engine/
[TensorRT-LLM][INFO] ckpt0
[TensorRT-LLM][INFO] Engine version 0.14.0.dev2024092400 found in the config file, assuming engine(s) built by new builder API.
[TensorRT-LLM][INFO] Initializing MPI with thread mode 3
[TensorRT-LLM][INFO] Initialized MPI
[TensorRT-LLM][INFO] Refreshed the MPI local session
[TensorRT-LLM][INFO] MPI size: 1, MPI local size: 1, rank: 0
[TensorRT-LLM][INFO] Rank 0 is using GPU 0
[TensorRT-LLM][INFO] TRTGptModel maxNumSequences: 2048
[TensorRT-LLM][INFO] TRTGptModel maxBatchSize: 2048
[TensorRT-LLM][INFO] TRTGptModel maxBeamWidth: 1
[TensorRT-LLM][INFO] TRTGptModel maxSequenceLen: 2048
[TensorRT-LLM][INFO] TRTGptModel maxDraftLen: 0
[TensorRT-LLM][INFO] TRTGptModel mMaxAttentionWindowSize: (2048) * 22
[TensorRT-LLM][INFO] TRTGptModel enableTrtOverlap: 0
[TensorRT-LLM][INFO] TRTGptModel normalizeLogProbs: 1
[TensorRT-LLM][INFO] TRTGptModel maxNumTokens: 8192
[TensorRT-LLM][INFO] TRTGptModel maxInputLen: 2047 = min(maxSequenceLen - 1, maxNumTokens) since context FMHA and usePackedInput are enabled
[TensorRT-LLM][INFO] TRTGptModel If model type is encoder, maxInputLen would be reset in trtEncoderModel to maxInputLen: min(maxSequenceLen, maxNumTokens).
[TensorRT-LLM][INFO] Capacity Scheduler Policy: GUARANTEED_NO_EVICT
[TensorRT-LLM][INFO] Context Chunking Scheduler Policy: None
[TensorRT-LLM][INFO] Loaded engine size: 2103 MiB
[TensorRT-LLM][ERROR] tensorrt_llm::common::TllmException: [TensorRT-LLM][ERROR] Assertion failed: sizeof(*this) <= buffer_size (/workspace/TensorRT-LLM/cpp/tensorrt_llm/kernels/decoderMaskedMultiheadAttention/decoderXQAImplCommon.h:118)
1       0x7fd1368a3c66 tensorrt_llm::common::throwRuntimeError(char const*, int, std::string const&) + 102
2       0x7fd136a5c227 tensorrt_llm::kernels::jit::CubinObjRegistryTemplate<tensorrt_llm::kernels::XQAKernelFullHashKey, tensorrt_llm::kernels::XQAKernelFullHasher>::CubinObjRegistryTemplate(void const*, unsigned long) + 1047

Expected behavior

In contrast, the inference succeeded in python runtime with the same engine file

root@dbedfb3d0654:/workspace/TensorRT-LLM/examples# python3 run.py --engine_dir ./llama/tinyllama-engine/  --max_output_len 100 --tokenizer_dir ./llama/TinyLlama/TinyLlama_v1_1/ --input_text "How do I count to nine in French?"
[TensorRT-LLM] TensorRT-LLM version: 0.14.0.dev2024092400
[TensorRT-LLM][INFO] Engine version 0.14.0.dev2024092400 found in the config file, assuming engine(s) built by new builder API.
[TensorRT-LLM][INFO] Engine version 0.14.0.dev2024092400 found in the config file, assuming engine(s) built by new builder API.
[TensorRT-LLM][INFO] MPI size: 1, MPI local size: 1, rank: 0
[TensorRT-LLM][INFO] Engine version 0.14.0.dev2024092400 found in the config file, assuming engine(s) built by new builder API.
[TensorRT-LLM][INFO] Refreshed the MPI local session
[TensorRT-LLM][INFO] MPI size: 1, MPI local size: 1, rank: 0
[TensorRT-LLM][INFO] Rank 0 is using GPU 0
[TensorRT-LLM][INFO] TRTGptModel maxNumSequences: 2048
[TensorRT-LLM][INFO] TRTGptModel maxBatchSize: 2048
[TensorRT-LLM][INFO] TRTGptModel maxBeamWidth: 1
[TensorRT-LLM][INFO] TRTGptModel maxSequenceLen: 2048
[TensorRT-LLM][INFO] TRTGptModel maxDraftLen: 0
[TensorRT-LLM][INFO] TRTGptModel mMaxAttentionWindowSize: (2048) * 22
[TensorRT-LLM][INFO] TRTGptModel enableTrtOverlap: 0
[TensorRT-LLM][INFO] TRTGptModel normalizeLogProbs: 1
[TensorRT-LLM][INFO] TRTGptModel maxNumTokens: 8192
[TensorRT-LLM][INFO] TRTGptModel maxInputLen: 2047 = min(maxSequenceLen - 1, maxNumTokens) since context FMHA and usePackedInput are enabled
[TensorRT-LLM][INFO] TRTGptModel If model type is encoder, maxInputLen would be reset in trtEncoderModel to maxInputLen: min(maxSequenceLen, maxNumTokens).
[TensorRT-LLM][INFO] Capacity Scheduler Policy: GUARANTEED_NO_EVICT
[TensorRT-LLM][INFO] Context Chunking Scheduler Policy: None
[TensorRT-LLM][INFO] Loaded engine size: 2103 MiB
[TensorRT-LLM][INFO] [MemUsageChange] Allocated 360.01 MiB for execution context memory.
[TensorRT-LLM][INFO] [MemUsageChange] TensorRT-managed allocation in IExecutionContext creation: CPU +0, GPU +0, now: CPU 0, GPU 2098 (MiB)
[TensorRT-LLM][INFO] [MemUsageChange] Allocated 346.15 MB GPU memory for runtime buffers.
[TensorRT-LLM][INFO] [MemUsageChange] Allocated 1.41 GB GPU memory for decoder.
[TensorRT-LLM][INFO] Memory usage when calculating max tokens in paged kv cache: total: 5.79 GiB, available: 1.43 GiB
[TensorRT-LLM][INFO] Number of blocks in KV cache primary pool: 960
[TensorRT-LLM][INFO] Number of blocks in KV cache secondary pool: 0, onboard blocks to primary memory before reuse: true
[TensorRT-LLM][INFO] Max KV cache pages per sequence: 32
[TensorRT-LLM][INFO] Number of tokens per block: 64.
[TensorRT-LLM][INFO] [MemUsageChange] Allocated 1.29 GiB for max tokens in paged KV cache (61440).
[10/04/2024-05:05:27] [TRT-LLM] [I] Load engine takes: 1.5954880714416504 sec
Input [Text 0]: "<s> How do I count to nine in French?"
Output [Text 0 Beam 0]: "How do I count to nine in French? How do I count to nine in French? How do I count to nine in French? How do I count to nine in French? How do I count to nine in French? How do I count to nine in French? How do I count to nine in French? How do I count to nine in French? How do I count to nine in French? How do I count to nine in French? How do I count to nine in French? How"
[TensorRT-LLM][INFO] Refreshed the MPI local session

actual behavior

There is sth wrong with C++ runtime since python runtime works

[TensorRT-LLM][ERROR] tensorrt_llm::common::TllmException: [TensorRT-LLM][ERROR] Assertion failed: sizeof(*this) <= buffer_size (/workspace/TensorRT-LLM/cpp/tensorrt_llm/kernels/decoderMaskedMultiheadAttention/decoderXQAImplCommon.h:118)

additional notes

Maybe there is some error in how to use C++ runtime.

@yjjuan , please provide a reproducer.

I built my trt engine with command: trtllm-build --checkpoint_dir TinyLlama_v1_1  --gemm_plugin float16 --output_dir tinyllama-engine/
Next, I tried to use your example script in cpp runtime to run tinyllamma : /executorExampleBasic ../../../llama/tinyllama-engine/

@DanBlanaru , could you please try to reproduce this?


Creating an Apple Account without 2FA

Question Checklist

[x] Updated fastlane to the latest version
[ ] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Question Subject

Apple account creation without 2FA
Question Description

Hi, I’m following guidance on trying to run Fastlane on CI but can’t work out how to create an Apple account for use with the Apple developer program without 2FA. I’ve tried creating an account with and without an invitation to the developer team. Does anyone know if Apple are now enforcing 2FA on all accounts?

No, you can still invite Apple IDs to your team (even as an admin role) without 2FA enable. The only caveat is that you will need a business / organization account for this to work. Personal developer accounts cannot give access to the developer center.

I have created accounts both by invitation from multiple organizational accounts as well as simply creating one from https://appleid.apple.com/account#!&page=create. I have tried them numerous times with the same result. Since the end of 5/2020 they have all required 2FA. There is not an explicit statement during the creation of the ID that 2FA will be enables, but it is automatically on every time.

@mobdevross @marcomorain Thanks for reporting this! I was able to create one without 2FA during in the middle of May but I have not tried since. I will also try today to verify but I trust the reports you are given 😊
I will then update the docs and try to figure out if there are ways we can work around this.

Same issue here. It looks like creating an Apple account now requires verification via phone. I assumed this was just a one time verification, but it appears it auto-enables 2FA.

I got the same issue. You're not able to create new AppleIDs without 2FA auto-enabled. And there's no way to disable 2FA after it's enabled.
What a mess :-(

It's no longer possible to create Apple IDs without 2FA. @joshdholtz is working hard to enable authentication across the board with the new App Store Connect API, which allows authentication through the key etc.


Fix the maps!

Maps are borken. Need fixing.

This issue was moved to DemocracyClub/electionleaflets#74


Video Streaming Not Working on WebGL

I'm getting the below issue when trying to stream video on WebGl. It's working fine on all other platforms
"Error: Loading failed.  File not found, codec not supported, video resolution too high or insufficient system resources"
1- Upload a video on vimeo
2- Test in Unity - Working fine
3- Test in Android and iOS - Working fine
4- Test in Web GL and loading is failed
2019.2.6f1
Mac OS

Most probably a CORS issue, WebGL can´t fetch url´s outside the domain of the installed build, unless you use a proxy, I´m trying to do the same with other assets, still working on a solution.

If you are using AVPRO make sure you select adaptive resolution and for the vimeo token, do not generate it from "Get Token" button because you will get CORS issue. Instead go to https://developer.vimeo.com/ and create a new app, and then you can generate a API token and insert it into Unity. This will fix the CORS issue and you will be able to play the videos from Webgl. Make sure to setup AVPRO (hls.js or dash.js)
If you are not using AVPRO then you will not be able to play the videos on Webgl because Unity Media player does not support adaptive resolution.
If you don't select adaptive resolution vimeo will not return .m3u8 (hls.js) or .mpd (dash.js) and you will get playback error.

@germancinho Would you mind giving some pointers on how you got it working?

this SDK definitely doesn't work well on WebGL, so in the end, I've implemented the Vimeo Player API (https://github.com/vimeo/player.js/) via jslib.


the stack becomes incomprehensible When an exception is caught

Hi Kjell,
I have a question, src/crashhandler_unix.cpp::signalHandler::LogCapture trigger(FATAL_SIGNAL, static_castg3::SignalType(signal_number), dump.c_str()); to saveMessage with FATAL_SIGNAL, the function “exitWithDefaultSignalHandler” will be called finally, the stack may be "corrupted"?
demo:
25     while (count--)
26     {
27         LOG(INFO) << "INFO: " << count;
28         sleep(1);
29         int a = 1 / 0;
30     }
The stack is like this:
(gdb) bt
#0  0x00007f6ba49fd8c7 in kill () from /lib64/libc.so.6
#1  0x0000000000427986 in g3::internal::exitWithDefaultSignalHandler (level=..., fatal_signal_id=fatal_signal_id@entry=8)
at /home/xxx/thirdparty/g3log-1.3/src/crashhandler_unix.cpp:246
#2  0x00000000004221cf in g3::LogWorkerImpl::bgFatal (this=0xa72050, msgPtr=...)
at /home/xxx/thirdparty/g3log-1.3/src/logworker.cpp:67
#3  0x0000000000422773 in operator() (__closure=)
at /home/xxx/thirdparty/g3log-1.3/src/logworker.cpp:110
#4  std::_Function_handler<void(), g3::LogWorker::fatal(g3::FatalMessagePtr)::__lambda9>::_M_invoke(const std::_Any_data &) (__functor=...)
at /usr/include/c++/4.8.2/functional:2071
#5  0x000000000040b5fc in std::function<void ()>::operator()() const (this=0x7f6ba47c2de0) at /usr/include/c++/4.8.2/functional:2471
#6  0x0000000000409eee in kjellkod::Active::run (this=0xa72080) at ../../../../itpub/thirdparty/include/g3log/active.hpp:40
#7  0x000000000041a299 in std::_Mem_fn<void (kjellkod::Active::)()>::operator()<, void>(kjellkod::Active) const (this=0xa723e8, __object=0xa72080)
at /usr/include/c++/4.8.2/functional:601
#8  0x0000000000419ab1 in std::_Bind_simple<std::_Mem_fn<void (kjellkod::Active::)()> (kjellkod::Active)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0xa723e0)
at /usr/include/c++/4.8.2/functional:1732
#9  0x00000000004190dd in std::_Bind_simple<std::_Mem_fn<void (kjellkod::Active::)()> (kjellkod::Active)>::operator()() (this=0xa723e0)
at /usr/include/c++/4.8.2/functional:1720
#10 0x0000000000418a16 in std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (kjellkod::Active::)()> (kjellkod::Active)> >::_M_run() (this=0xa723c8)
at /usr/include/c++/4.8.2/thread:115
#11 0x00007f6ba5356220 in ?? () from /lib64/libstdc++.so.6
#12 0x00007f6ba55b0dc5 in start_thread () from /lib64/libpthread.so.0
#13 0x00007f6ba4abe29d in clone () from /lib64/libc.so.6
(gdb)
And then, we turn off the ENABLE_FATAL_SIGNALHANDLING and recompile it,  the stack becomes "normal":
29              int a = 1 / 0;
Missing separate debuginfos, use: debuginfo-install glibc-2.17-106.tl2.5.x86_64 libgcc-4.8.5-4.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64 zlib-1.2.7-15.el7.x86_64
(gdb) bt
#0  0x0000000000408d82 in G3LogTest (argc=2, argv=0x7ffcc0d75408) at server_log_test.cpp:29
#1  0x00000000004091c5 in main (argc=2, argv=0x7ffcc0d75408) at server_log_test.cpp:60
(gdb)

In both cases the stack isn't corrupted. In both cases the offending line
or function doesn't seem to be shown either.
The stack as it is shown is exactly what happens when the signal was
triggered. I'm not sure why it doesn't catch your fatal code sequence.
Potentially you are using it in the main function and not in a subsequent
function so the top call stack, of the function where it's running is
missing?
I suggest that you try the fatal examples that are provided with g3log. Ref
CMake options for building them and let us know if the stack trace works.
On Thu, Aug 30, 2018 at 11:49 PM ngmj<EMAIL_ADDRESS>wrote:

Hi Kjell,
I have a question, src/crashhandler_unix.cpp::signalHandler::LogCapture
trigger(FATAL_SIGNAL, static_castg3::SignalType(signal_number),
dump.c_str()); to saveMessage with FATAL_SIGNAL, the function
“exitWithDefaultSignalHandler” will be called finally, the stack may be
"corrupted"?
demo:
25 while (count--)
26 {
27 LOG(INFO) << "INFO: " << count;
28 sleep(1);
29 int a = 1 / 0;
30 }
The stack is like this:
(gdb) bt
#0 0x00007f6ba49fd8c7 in kill () from /lib64/libc.so.6
#1 https://github.com/KjellKod/g3log/pull/1 0x0000000000427986 in
g3::internal::exitWithDefaultSignalHandler (level=...,
fatal_signal_id=fatal_signal_id@entry=8)
at /home/xxx/thirdparty/g3log-1.3/src/crashhandler_unix.cpp:246
#2 https://github.com/KjellKod/g3log/pull/2 0x00000000004221cf in
g3::LogWorkerImpl::bgFatal (this=0xa72050, msgPtr=...)
at /home/xxx/thirdparty/g3log-1.3/src/logworker.cpp:67
#3 https://github.com/KjellKod/g3log/pull/3 0x0000000000422773 in
operator() (__closure=)
at /home/xxx/thirdparty/g3log-1.3/src/logworker.cpp:110
#4 https://github.com/KjellKod/g3log/pull/4
std::_Function_handler<void(),
g3::LogWorker::fatal(g3::FatalMessagePtr)::__lambda9>::_M_invoke(const
std::_Any_data &) (__functor=...)
at /usr/include/c++/4.8.2/functional:2071
#5 https://github.com/KjellKod/g3log/pull/5 0x000000000040b5fc in
std::function<void ()>::operator()() const (this=0x7f6ba47c2de0) at
/usr/include/c++/4.8.2/functional:2471
#6 https://github.com/KjellKod/g3log/pull/6 0x0000000000409eee in
kjellkod::Active::run (this=0xa72080) at
../../../../itpub/thirdparty/include/g3log/active.hpp:40
#7 https://github.com/KjellKod/g3log/pull/7 0x000000000041a299 in
std::_Mem_fn<void (kjellkod::Active::)()>::operator()<,
void>(kjellkod::Active) const (this=0xa723e8, __object=0xa72080)
at /usr/include/c++/4.8.2/functional:601
#8 https://github.com/KjellKod/g3log/pull/8 0x0000000000419ab1 in
std::_Bind_simple<std::_Mem_fn<void (kjellkod::Active::)()>
(kjellkod::Active)>::_M_invoke<0ul>(std::_Index_tuple<0ul>)
(this=0xa723e0)
at /usr/include/c++/4.8.2/functional:1732
#9 https://github.com/KjellKod/g3log/issues/9 0x00000000004190dd in
std::_Bind_simple<std::_Mem_fn<void (kjellkod::Active::)()>
(kjellkod::Active)>::operator()() (this=0xa723e0)
at /usr/include/c++/4.8.2/functional:1720
#10 https://github.com/KjellKod/g3log/pull/10 0x0000000000418a16 in
std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (kjellkod::Active::)()>
(kjellkod::Active)> >::_M_run() (this=0xa723c8)
at /usr/include/c++/4.8.2/thread:115
#11 https://github.com/KjellKod/g3log/issues/11 0x00007f6ba5356220 in
?? () from /lib64/libstdc++.so.6
#12 https://github.com/KjellKod/g3log/issues/12 0x00007f6ba55b0dc5 in
start_thread () from /lib64/libpthread.so.0
#13 https://github.com/KjellKod/g3log/issues/13 0x00007f6ba4abe29d in
clone () from /lib64/libc.so.6
(gdb)
And then, we turn off the ENABLE_FATAL_SIGNALHANDLING and recompile it,
the stack becomes "normal":
29 int a = 1 / 0;
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-106.tl2.5.x86_64 libgcc-4.8.5-4.el7.x86_64
libstdc++-4.8.5-4.el7.x86_64 zlib-1.2.7-15.el7.x86_64
(gdb) bt
#0 0x0000000000408d82 in G3LogTest (argc=2, argv=0x7ffcc0d75408) at
server_log_test.cpp:29
#1 https://github.com/KjellKod/g3log/pull/1 0x00000000004091c5 in main
(argc=2, argv=0x7ffcc0d75408) at server_log_test.cpp:60
(gdb)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/KjellKod/g3log/issues/285, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUP3rjSCwVButDmoooD4b3XvdY2LuGZks5uWM5lgaJpZM4WUoam
.

I should add that getting a stack trace after a fatal crash is something I
expect but there are instances when due to memory corruption etc it doesn't
work well.  Extracting a stack trace after a fatal event follows code that
works now but it is using tricks that are according to the standard
technically undefined behavior.
On Fri, Aug 31, 2018 at 7:57 AM Kjell Hedström<EMAIL_ADDRESS>wrote:

In both cases the stack isn't corrupted. In both cases the offending line
or function doesn't seem to be shown either.
The stack as it is shown is exactly what happens when the signal was
triggered. I'm not sure why it doesn't catch your fatal code sequence.
Potentially you are using it in the main function and not in a subsequent
function so the top call stack, of the function where it's running is
missing?
I suggest that you try the fatal examples that are provided with g3log.
Ref CMake options for building them and let us know if the stack trace
works.
On Thu, Aug 30, 2018 at 11:49 PM ngmj<EMAIL_ADDRESS>wrote:

Hi Kjell,
I have a question, src/crashhandler_unix.cpp::signalHandler::LogCapture
trigger(FATAL_SIGNAL, static_castg3::SignalType(signal_number),
dump.c_str()); to saveMessage with FATAL_SIGNAL, the function
“exitWithDefaultSignalHandler” will be called finally, the stack may be
"corrupted"?
demo:
25 while (count--)
26 {
27 LOG(INFO) << "INFO: " << count;
28 sleep(1);
29 int a = 1 / 0;
30 }
The stack is like this:
(gdb) bt
#0 0x00007f6ba49fd8c7 in kill () from /lib64/libc.so.6
#1 https://github.com/KjellKod/g3log/pull/1 0x0000000000427986 in
g3::internal::exitWithDefaultSignalHandler (level=...,
fatal_signal_id=fatal_signal_id@entry=8)
at /home/xxx/thirdparty/g3log-1.3/src/crashhandler_unix.cpp:246
#2 https://github.com/KjellKod/g3log/pull/2 0x00000000004221cf in
g3::LogWorkerImpl::bgFatal (this=0xa72050, msgPtr=...)
at /home/xxx/thirdparty/g3log-1.3/src/logworker.cpp:67
#3 https://github.com/KjellKod/g3log/pull/3 0x0000000000422773 in
operator() (__closure=)
at /home/xxx/thirdparty/g3log-1.3/src/logworker.cpp:110
#4 https://github.com/KjellKod/g3log/pull/4
std::_Function_handler<void(),
g3::LogWorker::fatal(g3::FatalMessagePtr)::__lambda9>::_M_invoke(const
std::_Any_data &) (__functor=...)
at /usr/include/c++/4.8.2/functional:2071
#5 https://github.com/KjellKod/g3log/pull/5 0x000000000040b5fc in
std::function<void ()>::operator()() const (this=0x7f6ba47c2de0) at
/usr/include/c++/4.8.2/functional:2471
#6 https://github.com/KjellKod/g3log/pull/6 0x0000000000409eee in
kjellkod::Active::run (this=0xa72080) at
../../../../itpub/thirdparty/include/g3log/active.hpp:40
#7 https://github.com/KjellKod/g3log/pull/7 0x000000000041a299 in
std::_Mem_fn<void (kjellkod::Active::)()>::operator()<,
void>(kjellkod::Active) const (this=0xa723e8, __object=0xa72080)
at /usr/include/c++/4.8.2/functional:601
#8 https://github.com/KjellKod/g3log/pull/8 0x0000000000419ab1 in
std::_Bind_simple<std::_Mem_fn<void (kjellkod::Active::)()>
(kjellkod::Active)>::_M_invoke<0ul>(std::_Index_tuple<0ul>)
(this=0xa723e0)
at /usr/include/c++/4.8.2/functional:1732
#9 https://github.com/KjellKod/g3log/issues/9 0x00000000004190dd in
std::_Bind_simple<std::_Mem_fn<void (kjellkod::Active::)()>
(kjellkod::Active)>::operator()() (this=0xa723e0)
at /usr/include/c++/4.8.2/functional:1720
#10 https://github.com/KjellKod/g3log/pull/10 0x0000000000418a16 in
std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (kjellkod::Active::)()>
(kjellkod::Active)> >::_M_run() (this=0xa723c8)
at /usr/include/c++/4.8.2/thread:115
#11 https://github.com/KjellKod/g3log/issues/11 0x00007f6ba5356220 in
?? () from /lib64/libstdc++.so.6
#12 https://github.com/KjellKod/g3log/issues/12 0x00007f6ba55b0dc5 in
start_thread () from /lib64/libpthread.so.0
#13 https://github.com/KjellKod/g3log/issues/13 0x00007f6ba4abe29d in
clone () from /lib64/libc.so.6
(gdb)
And then, we turn off the ENABLE_FATAL_SIGNALHANDLING and recompile it,
the stack becomes "normal":
29 int a = 1 / 0;
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-106.tl2.5.x86_64 libgcc-4.8.5-4.el7.x86_64
libstdc++-4.8.5-4.el7.x86_64 zlib-1.2.7-15.el7.x86_64
(gdb) bt
#0 0x0000000000408d82 in G3LogTest (argc=2, argv=0x7ffcc0d75408) at
server_log_test.cpp:29
#1 https://github.com/KjellKod/g3log/pull/1 0x00000000004091c5 in main
(argc=2, argv=0x7ffcc0d75408) at server_log_test.cpp:60
(gdb)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/KjellKod/g3log/issues/285, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUP3rjSCwVButDmoooD4b3XvdY2LuGZks5uWM5lgaJpZM4WUoam
.

We found that the trace of stack was not shown exactly when some  undefined fatal errors happend in the project, so I use the fatal demo to trace the track processed in g3log as follows:
The dump info was triggered with "FATAL_SIGNAL" in the "signalHandler" function.
-> LogCapture trigger(FATAL_SIGNAL, SIGSEGV, dump.c_str());
-> saveMessage( ..., FATAL_SIGNAL, ... )
if (internal::wasFatal(level)) {....}
-> fatalCall(FatalMessagePtr message)
...
-> exitWithDefaultSignalHandler( FATAL_SIGNAL, SIGSEGV )
-> kill(getpid(), SIGSEGV ); exit(SIGSEGV);
so a new stack may be triggered when "kill(getpid(), SIGSEGV )"?


Document Publish to Public pipeline deprecation

PR: https://dev.azure.com/azure-sdk/internal/_git/azure-sdk-docs-eng.ms/pullrequest/936

@JonathanCrd is there an equivalent issue to remove the functionality from the OpenAPI Hub portal?

I just realized, you are going to have to update the comment the bot creates in the spes PR: https://github.com/Azure/azure-rest-api-specs/blob/main/.github/comment.yml#L2

is there an equivalent issue to remove the functionality from the OpenAPI Hub portal?

No, but instruction were provided on the docs.
The bot instructions have been updated too.


Error selecting columns from RNAcentral bed file

Describe the bug
Hello! I am trying to implement the WIND piRNA protocol to process my data and it is not possible for me to run the docker implementation, but I have all of the software installed and figured it would be no problem.  I created an Rscript to prepare the annotation which was taken from the Step 1 script.  I think that I may be missing a step in the 'read_bed' plyranges section. It could also be that the RNAcentral bed file simply doesn't contain the same information.  I see that there is an optional step 1 script, should I be using that one instead?  Thank you Matt
To Reproduce
## Change to data directory
setwd("/dataVol/genomes/GRCm39_piRNA/")

library(tidyverse)
library(data.table)
library(plyranges)
library(BSgenome.Mmusculus.UCSC.mm39)
library(here)

## import RNACentral bed file
sRNA <- here("mouse_data", "RNACentral", "mus_musculus.GRCm39.bed") %>% read_bed(genome_info ="mm39") %>% select("sRNA_id" = name, "gene_type" = NA.1, "source" = NA.2) %>% mutate(type = "exon")

Error
> sRNA <- here("mouse_data", "RNACentral", "mus_musculus.GRCm39.bed") %>% read_bed() %>% select("sRNA_id" = name, "gene_type" = NA.1, "source" = NA.2) %>% mutate(type = "exon")
Error in select_rng(.data, .drop_ranges, ...) :
  Cannot select/rename the following columns: seqnames, start, end, width, strand

Then if I add '.drop_ranges = TRUE' I get a slightly different error
> sRNA <- here("mouse_data", "RNACentral", "mus_musculus.GRCm39.bed") %>% read_bed() %>% select("sRNA_id" = name, "gene_type" = NA.1, "source" = NA.2, .drop_ranges = TRUE) %>% mutate(type = "exon")
Error in `select_rng()`:
! Can't subset columns that don't exist.
✖ Column `NA.1` doesn't exist.
Run `rlang::last_trace()` to see where the error occurred.

Desktop (please complete the following information):

OS: Ubuntu linux x86_64
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
> sessionInfo()
R version 4.3.1 (2023-06-16)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.6 LTS

Matrix products: default
BLAS/LAPACK: /usr/local/lib/libopenblas_zenp-r0.3.18.so;  LAPACK version 3.9.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

time zone: America/Los_Angeles
tzcode source: system (glibc)

attached base packages:
[1] stats4    stats     graphics  grDevices utils     datasets  methods
[8] base

other attached packages:
 [1] here_1.0.1                         BSgenome.Mmusculus.UCSC.mm39_1.4.3
 [3] BSgenome_1.68.0                    rtracklayer_1.60.1
 [5] Biostrings_2.68.1                  XVector_0.40.0
 [7] plyranges_1.20.0                   GenomicRanges_1.52.0
 [9] GenomeInfoDb_1.36.1                IRanges_2.34.1
[11] S4Vectors_0.38.1                   BiocGenerics_0.46.0
[13] data.table_1.14.8                  lubridate_1.9.2
[15] forcats_1.0.0                      stringr_1.5.0
[17] dplyr_1.1.2                        purrr_1.0.2
[19] readr_2.1.4                        tidyr_1.3.0
[21] tibble_3.2.1                       ggplot2_3.4.3
[23] tidyverse_2.0.0

loaded via a namespace (and not attached):
 [1] SummarizedExperiment_1.30.2 gtable_0.3.3
 [3] rjson_0.2.21                Biobase_2.60.0
 [5] lattice_0.21-8              tzdb_0.4.0
 [7] vctrs_0.6.3                 tools_4.3.1
 [9] bitops_1.0-7                generics_0.1.3
[11] parallel_4.3.1              fansi_1.0.4
[13] pkgconfig_2.0.3             Matrix_1.6-1
[15] lifecycle_1.0.3             GenomeInfoDbData_1.2.10
[17] compiler_4.3.1              Rsamtools_2.16.0
[19] munsell_0.5.0               codetools_0.2-19
[21] RCurl_1.98-1.12             yaml_2.3.7
[23] pillar_1.9.0                crayon_1.5.2
[25] BiocParallel_1.34.2         DelayedArray_0.26.7
[27] abind_1.4-5                 tidyselect_1.2.0
[29] stringi_1.7.12              restfulr_0.0.15
[31] rprojroot_2.0.3             grid_4.3.1
[33] colorspace_2.1-0            cli_3.6.1
[35] magrittr_2.0.3              S4Arrays_1.0.5
[37] XML_3.99-0.14               utf8_1.2.3
[39] withr_2.5.0                 scales_1.2.1
[41] timechange_0.2.0            matrixStats_1.0.0
[43] hms_1.1.3                   BiocIO_1.10.0
[45] rlang_1.1.1                 glue_1.6.2
[47] R6_2.5.1                    MatrixGenerics_1.12.3
[49] GenomicAlignments_1.36.0    zlibbioc_1.46.0

Hello! So I am wondering if there was a major downgrade in the RNAcentral information?  So I also ran into errors using the gff3 with STAR what I had to do was use the UCSC tools, gffToGenePred -> genePredToGTF and then sort. I wonder f there is some manipulation like this that will return the proper bed file with the necessary fields?

what about "bedToBigBed'

Thank you!  It's working! I really appreciate your help!


Go Runtime Handle Callbacks

:rocket: Feature Request
Runtime methods currently don't handle callback responses from the API. Basically, they should 😄. This is a non-trivial task that kernel request methods need to handle.
The custom UnmarshalJSON implementation for runtime response apis may be an appropriate place to distinguish between a callback response and everything else, as this is where error and ok responses are currently deciphered. Decoding the callback should trigger additional runtime request round trips until a complete response is received.

[x] blocked by https://github.com/aws/jsii/issues/2561

Emm..not sure what happening here with all these linked issues, I definitely did not intend to close this out.


building HTR with llvm > 6.0

We're encountering this error when building htr with GPU support:
LLVM ERROR: Cannot select: 0xaf35c48: f64,ch = AtomicLoadFAdd<(load store monotonic (s64) on %ir.119)> 0xb101068:1, 0xaf34d40, 0xb101068
 0xaf34d40: i64 = add 0xab48d58, 0xb2d26a8
  0xab48d58: i64,ch = CopyFromReg 0xb2904e8, Register:i64 %28
   0xadb23f0: i64 = Register %28
  0xb2d26a8: i64 = NVPTXISD::MUL_WIDE_SIGNED 0xaf359d8, Constant:i32<8>
   0xaf359d8: i32 = sub 0xaf34da8, 0xab48948
    0xaf34da8: i32,ch = CopyFromReg 0xb2904e8, Register:i32 %3
     0xaf358a0: i32 = Register %3
    0xab48948: i32 = and 0xab48bb8, Constant:i32<-256>
     0xab48bb8: i32 = add 0xaf34da8, 0xb2d2160
      0xaf34da8: i32,ch = CopyFromReg 0xb2904e8, Register:i32 %3
       0xaf358a0: i32 = Register %3
      0xb2d2160: i32 = srl 0xaf34ee0, Constant:i32<24>
       0xaf34ee0: i32 = sra 0xaf34da8, Constant:i32<31>
        0xaf34da8: i32,ch = CopyFromReg 0xb2904e8, Register:i32 %3
         0xaf358a0: i32 = Register %3
        0xab48a18: i32 = Constant<31>
       0xb100f30: i32 = Constant<24>
     0xadb1758: i32 = Constant<-256>
   0xadb16f0: i32 = Constant<8>
 0xb101068: f64,ch = load<(load (s64) from %ir.16)> 0xb2904e8, 0xb2d2710, undef:i64
  0xb2d2710: i64,ch = CopyFromReg 0xb2904e8, Register:i64 %2
   0xb100d90: i64 = Register %2
  0xadb1f78: i64 = undef
In function: __kernel_id_Exports_CalculateAverageTemperature_cuda33
make: *** [prometeo_main_CH41StMix.o] Error 250

It doesn't happen when legion is built with llvm60, but after trying with llvm90 and 130, the issue comes up. Not sure if this is an application bug but would appreciate any help

Is there a way to generate a minimized reproducer from this? You've got the task name in the error message there (Exports_CalculateAverageTemperature) so hopefully it's just a matter of slicing out that one task, and then cutting it down until it stops generating the error.
Also, would appreciate information on the Legion commit, CUDA version, GPU architecture, etc.

@mariodirenzo would be able to comment more on slicing out the tasks. I've posted the full error here if that provides any more insight
LLVM version: 13.0, Legion commit: latest control_replication (69eadbca) , CUDA 10.2, GPU arch: kepler

@cmelone Is there any chance you could try building on a newer GPU (e.g. Pascal/Volta/Ampere)? Kepler's pretty old, so it may be possible that the instruction LLVM wants to generate literally doesn't exist for that architecture.

To be clear, I don't think you need to find a different machine. Assuming you're using offline mode, you can build for a different GPU architecture by just setting -fcuda-arch to something like pascal and see if it reproduces (even though the binary you generate this way won't run on the GPUs you've got in this machine).

i haven't encountered the issue on lassen, which has volta. yellowstone only has maxwell and kepler, so would you say that there's just irresolvable incompatibilities between those GPUs and newer llvm versions?
i will try out the -fcuda-arch approach to confirm

The issue can be reproduced be compiling the following code
import "regent"

struct Type {
   dcsi_d : double;
   deta_d : double;
   dzet_d : double;
   temperature : double;
}

__demand(__cuda, __leaf) -- MANUALLY PARALLELIZED
task CalculateAverageTemperature(Fluid : region(ispace(int3d), Type))
where
   reads(Fluid.{dcsi_d, deta_d, dzet_d, temperature})
do
   var acc = 0.0
   __demand(__openmp)
   for c in Fluid do
      var cellVolume = 1.0/(Fluid[c].dcsi_d*Fluid[c].deta_d*Fluid[c].dzet_d)
      acc += Fluid[c].temperature*cellVolume
   end
   return acc
end

task main()

end

regentlib.saveobj(main, "repro.o", "object")

with the command $LEGION_DIR/language/regent.py repro.rg -fflow 0 -finner 1 -foffline 1

-fgpu-arch volta fixes the issue

Thanks for checking and the reproducer.
What's the expected lifetime of this machine?
If I'm reading this correctly, looks like Kepler (sm_35) is deprecated in CUDA 11, so NVIDIA will not be supporting this GPU for much longer: https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html#title-new-cuda-libraries
If the Kepler GPUs will be short(ish) lived (say, 1 year or less) I might be inclined to say we stick with LLVM 6 on this machine until the end of its life. I'm not sure how much luck I'll have convincing LLVM to work with the older GPUs. If the machine is going to be around for a while (with these GPUs) I'll need to think more about the best path forward.

I talked to Steve and it seems that kepler and maxwell will stay on yellowstone for at most another year.

Same output as the parent issue

I just pushed a branch fix-regent-kepler-ctrlrepl with a potential workaround. Can you try that with LLVM 13 and both Kepler/Maxwell GPUs?

Thanks. HTR compiles with that branch of legion on both maxwell and kepler. I'm able to run a small solver test on maxwell successfully (but will run the complete test suite to confirm). On kepler, I get this error when running the app:
[gitlabci@yellowstone-login-0-2 llvm110_error]$ cat htr6/solverTests/3DPeriodic/slurm-252125.out
Sending output to 1x1x1
Invoking Legion on 1 rank(s), 1 node(s) (1 rank(s) per node), as follows:
/home/hpcc/gitlabci/llvm110_error/htr6/src/prometeo_ConstPropMix.exec -i 1x1x1.json -o 1x1x1 -ll:cpu 1 -ll:ocpu 2 -ll:onuma 1 -ll:othr 10 -ll:ostack 8 -ll:gpu 1 -ll:fsize 11000 -ll:zsize 512 -ll:ib_zsize 512 -ll:util 2 -ll:io 1 -ll:bgwork 1 -ll:cpu_bgwork 100 -ll:util_bgwork 100 -ll:csize 220000 -ll:rsize 512 -ll:ib_rsize 512 -ll:gsize 0 -ll:stacksize 8 -lg:sched -1 -lg:hysteresis 0
[0 - 7f05fa221880]    0.000000 {5}{gpu}: Failed to load CUDA module! Error log: ptxas application ptx input, line 29809; error   : Feature 'rsqrt.approx.ftz.f64' requires PTX ISA .version 4.0 or later
ptxas application ptx input, line 29962; error   : Feature 'rsqrt.approx.ftz.f64' requires PTX ISA .version 4.0 or later
ptxas application ptx input, line 30158; error   : Feature 'rsqrt.approx.ftz.f64' requires PTX ISA .version 4.0 or later
...
ptxas fatal   : Ptx assembly aborted due to errors
CU: cuModuleLoadDataEx = 218 (CUDA_ERROR_INVALID_PTX): a PTX JIT compilation failed
[largemem-1-9:38526] *** Process received signal ***
[largemem-1-9:38526] Signal: Aborted (6)
[largemem-1-9:38526] Signal code:  (-6)
[largemem-1-9:38526] [ 0] /lib64/libc.so.6(+0x363b0)[0x7f05f789e3b0]
[largemem-1-9:38526] [ 1] /lib64/libc.so.6(gsignal+0x37)[0x7f05f789e337]
[largemem-1-9:38526] [ 2] /lib64/libc.so.6(abort+0x148)[0x7f05f789fa28]
[largemem-1-9:38526] [ 3] /home/hpcc/gitlabci/llvm110_error/legion6/bindings/regent/libregent.so(+0xe4cf69)[0x7f05f934ef69]
[largemem-1-9:38526] [ 4] /home/hpcc/gitlabci/llvm110_error/legion6/bindings/regent/libregent.so(+0xe5883f)[0x7f05f935a83f]
[largemem-1-9:38526] [ 5] /home/hpcc/gitlabci/llvm110_error/legion6/bindings/regent/libregent.so(+0xe5a5fe)[0x7f05f935c5fe]
[largemem-1-9:38526] [ 6] /home/hpcc/gitlabci/llvm110_error/legion6/bindings/regent/libregent.so(+0xe5ac09)[0x7f05f935cc09]
[largemem-1-9:38526] [ 7] /home/hpcc/gitlabci/llvm110_error/legion6/bindings/regent/libregent.so(+0xe5be81)[0x7f05f935de81]
[largemem-1-9:38526] [ 8] /home/hpcc/gitlabci/llvm110_error/legion6/bindings/regent/libregent.so(+0xbcf1dc)[0x7f05f90d11dc]
[largemem-1-9:38526] [ 9] /home/hpcc/gitlabci/llvm110_error/legion6/bindings/regent/libregent.so(_ZN5Realm7Runtime27configure_from_command_lineERSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EEb+0x145)[0x7f05f90d50d5]
[largemem-1-9:38526] [10] /home/hpcc/gitlabci/llvm110_error/legion6/bindings/regent/libregent.so(_ZN6Legion8Internal7Runtime10initializeEPiPPPcb+0x3cf)[0x7f05f8d3aa7f]
[largemem-1-9:38526] [11] /home/hpcc/gitlabci/llvm110_error/htr6/src/prometeo_ConstPropMix.exec(main+0xf415)[0x423fb5]
[largemem-1-9:38526] [12] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f05f788a505]
[largemem-1-9:38526] [13] /home/hpcc/gitlabci/llvm110_error/htr6/src/prometeo_ConstPropMix.exec[0x414ae2]
[largemem-1-9:38526] *** End of error message ***
srun: error: largemem-1-9: task 0: Aborted

I merged the first part fix to master, so it will make it into control_replication the next time someone does a merge. That will at least get Maxwell working for you.
I'm hoping someone from NVIDIA can comment on rsqrt.approx.ftz.f64. As best I can tell, this is available in sm_20, so I'm not sure why it wouldn't be available on Kepler: https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions__summary-of-floating-point-instructions
As best I can tell, we're calling math functions through libdevice, so this ought to be implemented in a way that's compatible with the given architecture: https://gitlab.com/StanfordLegion/legion/-/blob/master/language/src/regent/gpu/cuda.t#L586
@cmelone can you add a print(libdevice, libdevice_version) to this line in Terra (and cd terra.build/build && make clean && make -j4): https://github.com/terralang/terra/blob/master/src/cudalib.lua#L100 . And then run again and see what it prints out.

Note to self to look at this to see if it's applicable: https://github.com/clang-omp/clang_trunk/issues/16#issue-92584104

@cmelone Can you try this workaround? Build Terra with the following patch:
diff --git a/src/terralib.lua b/src/terralib.lua
index 4a9dccf..3a899aa 100644
--- a/src/terralib.lua
+++ b/src/terralib.lua
@@ -4346,7 +4346,7 @@ end
 local cudatarget
 function terra.getcudatarget()
     if cudatarget == nil then
-        cudatarget = terra.newtarget {Triple = 'nvptx64-nvidia-cuda', FloatABIHard = true}
+        cudatarget = terra.newtarget {Triple = 'nvptx64-nvidia-cuda', FloatABIHard = true, Features = '+ptx42'}
     end
     return cudatarget
 end

(Note: cd build && make clean && make if you're not using a clean build of Terra. I've had trouble with dirty builds in the past.)

I get the same error after applying the patch, and this is the output of the print statement:
/usr/local/cuda-10.2/nvvm/libdevice/libdevice.10.bc	nil

I'm hoping someone from NVIDIA can comment on rsqrt.approx.ftz.f64. As best I can tell, this is available in sm_20, so I'm not sure why it wouldn't be available on Kepler: https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions__summary-of-floating-point-instructions

sm_20 does support rsqrt.approx.ftz.f64 but the instruction requires PTX ISA version 4.0: https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-rsqrt-approx-ftz-f64. I'm surprise to hear that NVPTX can even emit that instruction with a wrong PTX ISA version... this sounds to me like a bug in NVPTX. Can someone dump the PTX with @elliottslaughter 's patch and upload it? I think the first few lines showing the PTX ISA version should be sufficient? I feel the patch should have worked, but some plumbing might still be missing in Terra.

@cmelone pass -fcuda-dump-ptx 1. (https://gitlab.com/StanfordLegion/legion/-/blob/master/language/src/regent/config.t#L105) you will need to redirect the output to a file.

I'm replicating this with @mariodirenzo 's original reproducer and the command line:
./regent.py test_bug_1264.rg -fcuda 1 -fcuda-offline 1 -fcuda-arch kepler -fcuda-dump-ptx 1 > ptx2.out

The output I get starts with:
//
// Generated by LLVM NVPTX Back-End
//

.version 3.2
.target sm_30
.address_size 64

What confuses me though is that the change I proposed for @cmelone (adding Features = "+ptx42" to the newtarget for NVPTX) doesn't do anything. I can confirm that the features get passed into createTargetMachine here:
https://github.com/terralang/terra/blob/269701d66aa60b9bcd52f2062e50b38e3acd9baa/src/tcompiler.cpp#L317
And I can confirm that the resulting TargetMachine has the right features:
TargetMachine->getTargetFeatureString +ptx42

But the PTX output does not change.
I'm pretty sure this matches the Clang code path. Clang supports a flag -target-feature which you can see being tested with +ptx42 here:
https://github.com/llvm/llvm-project/blob/llvmorg-13.0.0/clang/test/Driver/cuda-detect.cu#L180
The flags are being parsed here into PTXVersion:
https://github.com/llvm/llvm-project/blob/llvmorg-13.0.0/clang/lib/Basic/Targets/NVPTX.cpp#L44-L63
PTXVersion makes its way into Features here:
https://github.com/llvm/llvm-project/blob/llvmorg-13.0.0/clang/lib/Basic/Targets/NVPTX.h#L79
And Features go into createTargetMachine here:
https://github.com/llvm/llvm-project/blob/llvmorg-13.0.0/clang/lib/CodeGen/BackendUtil.cpp#L903-L904
I may need help from some LLVM folks to figure out what I'm missing.

@cmelone Could you try the following workaround?
diff --git a/language/src/regent/gpu/cuda.t b/language/src/regent/gpu/cuda.t
index 4947eb6d6..2de6c0e69 100644
--- a/language/src/regent/gpu/cuda.t
+++ b/language/src/regent/gpu/cuda.t
@@ -199,7 +199,7 @@ end)

 local supported_archs = {
   ["fermi"]   = 20,
-  ["kepler"]  = 30,
+  ["kepler"]  = 32,
   ["k20"]     = 35,
   ["maxwell"] = 52,
   ["pascal"]  = 60,

This hack is based on the observation that LLVM sets a minimum PTX version of 4.0 for compute capability 3.2 (https://github.com/llvm/llvm-project/blob/llvmorg-13.0.0/llvm/lib/Target/NVPTX/NVPTX.td#L103). I'm not 100% sure what the differences between 3.0 and 3.2 are, but I'm hoping they're small enough that we can get away with it. (I don't see anything below 3.5 in https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#compute-capabilities so it's hard to do research on what the differences are.)

See: https://en.wikipedia.org/wiki/CUDA#GPUs_supported
Tesla K10 was a Kepler that was SM 3.0, so maybe the most consistent thing to do here is to be setting arch to "k20" if y'all are indeed using a K20 (or K40), and then you'll be at SM 3.5 with the existing code I think?

I believe the keplers are k40. I’ll try Elliott’s patch and get back

I no longer encounter the error after applying Elliott's most recent patch. Thanks for the help everyone

Ok, I'll plan on pushing that as our workaround for this issue, probably tomorrow.
To @streichler 's point, it has to be exactly SM 3.2, because this line in LLVM provides the workaround only for 3.2 (not 3.0 and not 3.5). https://github.com/llvm/llvm-project/blob/llvmorg-13.0.0/llvm/lib/Target/NVPTX/NVPTX.td#L103
If someone can tell me why my Features workaround didn't work, I could pursue that, but in the meantime I'll take the hacky workaround that actually works.

I'm just going to add one more note here to myself, in case I ever need to revisit this:
Based on @pmccormick's tests with Kitsune, it seems you need to set this in two places:

https://github.com/pmccormick/kitsune/blob/38b314145bee191525bafa76eec0591c44cf1e8d/llvm/lib/Transforms/Tapir/CudaABI.cpp#L440 (this is what I was testing)
https://github.com/pmccormick/kitsune/blob/38b314145bee191525bafa76eec0591c44cf1e8d/llvm/lib/Transforms/Tapir/CudaABI.cpp#L842 (an attribute on the function; I was missing this)

The PTX version feature string itself looks like what I was generating: https://github.com/pmccormick/kitsune/blob/38b314145bee191525bafa76eec0591c44cf1e8d/llvm/lib/Transforms/Tapir/CudaABI.cpp#L293
So it probably would be possible to do this, but a bit of a pain since is requires touching every kernel (and Terra-level changes). As long as the current workaround is good enough, let's stick with it.


feat(turbine): Supply Git SHA when creating an application and displa…

…y it
Description of change

Fixes https://github.com/meroxa/turbine-project/issues/65
Type of change

[ ]  New feature
[ ]  Bug fix
[x]  Refactor
[ ]  Documentation

How was this tested?

[ ]  Unit Tests
[x]  Minikube manual testing
[ ]  Tested in staging

Demo
Before

After

Additional references

Documentation updated

Note that i had to manually make a default pipeline before being able to deploy


Use scoded for B and BS

This changes the decoding and representation of  the DynamoDb AttributeValue B and BS.
B is a binary value Base64 encoded on the wire, while BS is an ordered set of binary base64 encoded value.
Given that feral depends already on scodec, it makes sense to use BinaryVector to model the binary value.

We need to bump the base version to 0.3 because this is a breaking change.
https://github.com/typelevel/feral/blob/424590163f05fd4d06692c0880815eff387708db/build.sbt#L21

Also this solves a big where the BS DynamoDB AttributeValue BS type was modelled as a single String that would fail the decoding.

Sorry, I couldn't quite understand. Would you mind sharing an example? Did we add a test for this case?

Sorry, I couldn't quite understand. Would you mind sharing an example? Did we add a test for this case?

Sure,
B on the wire is a Base64 encoded binary, and at this moment it is modelled as a string. Not ergonomic but it works.
{
  "B": "Base64..."
}

On the other hands BS on the wire is an array of Base64 encoded binary strings:
{
  "BS": [
    "Base64...",
    "Base64..."
  ]
}

But, right now, on feral, it is decoded as a single String, and so the circe decoding fails.
Does it make sense?

Oh, I totally missed that! That is indeed a bug, not related to String vs Bytevector but because we forgot List 🤦 thanks!

Oh, I totally missed that! That is indeed a bug, not related to String vs Bytevector but because we forgot List 🤦 thanks!

Yeah sorry I have conflated two things given that it was a breaking change anyway


Cleanup branches

We should cleanup the branches.
As mentioned in the contribution guidelines developers work on their own forks so there should be no need for branches on the main repo.
I would accept version branches i.e. branch for <IP_ADDRESS> and another for <IP_ADDRESS> but outside of that we should keep it clean and consistent with contribution guidelines.
Also I don't think it looks too good having 16 branches sitting there with the majority being stale at this point.

I agree, I've been hesitant to delete the old/dead branches without first discussing it with someone. @PaycoinMaster @xmk3 your opinions?

I Agree with this

Currently all but the master branch are random patches and should have been deleted when they were merged into master. I'll gladly delete all of these assuming there's no argument against it (I'll give @xmk3 a bit to respond lol)

Spoke to @xmk3 he's for it. I forgot you could do this from the branches menu on github (used to be you had to push from git to delete a branch); you want to clean those up @PaycoinMaster or should I?

Thanks everyone. I'm all for making a <IP_ADDRESS> branch, thoughts?

Sure? Do we need it? lol

Not really, someone might find it useful if they needed to build from source an earlier version and I notice Bitcoin does it for all major releases from 0.8
But someone could also just use the tag <IP_ADDRESS> so probably a bit redundant. Happy to not do it if you don't think it's needed.

Generally the main reason for having a version branch is if you are going to be supporting multiple versions.
A good example is how Android has a branch for each major version (KitKat, Lollipop, etc); these have numeric tags for each release but as they go through and fix certain bugs and do sub versions they add that code to the version branch instead of a dev or master branch ((master itself is more or less the development branch in the case of android).
Being that we don't/won't be supporting older versions I don't think this is necessary personally but I really have no strong feelings one way or the other.
--
I deleted all of the merged branches but I left the stale ones, personally I think all of them can go (including the one marked testnet as we're not using that branch and it's extremely out of date).

I see your point. I'm happy to leave out version branches until such time support for older versions is applicable.
Agree to remove stale branches.
I notice that you introduced a new branch yesterday?

That branch was auto-created when I clicked the revert option from a PR. We can delete it after it's merged.

Cool, thanks.

All branches but master have been removed.


Ability to receive XML output from callback (rather than String or JSON)

For my purposes, it would be useful if the module provided the ability to return raw XML rather than forcing JSON or string output.
It's a trivial improvement - I may submit a pull request in the near future.

I have no plans to export XML as default.
I would suggest using a library like xml-js to convert the json output to XML.
var convert = require('xml-js');
var result = convert.json2xml(json, {});

I just browsed through the code and realised I already had this feature blastjs 😊,
calling blast.stringOutput = true OR blast.outputString(true); should give you the raw output.


Choose your course guidance

Trello card
https://trello.com/c/TCBRpFYi/5038-improve-guidance-around-choosing-a-course
Context
We know candidates can sometimes struggle with understanding which courses they want to apply for.
We have some guidance on the site around this (namely, our Train to teach if you have a degree page), but the page feels very long and quite lost in terms of what it’s actually trying to do.
We need to review our content around choosing your training course to help users get a better idea of what they need to consider.
We should look at our Train to teach if you have a degree page and potentially develop new content around choosing the right course for you.
Changes proposed in this pull request
Guidance to review

This has now been replaced by a new PR.


Release 1.7.x branch

@lchayoun did I miss something? :)

We merged the HEADER option to 1.7.x as well.
https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit/commits/1.7.x
But I'm unable to release it.

I see! I'll take care of it later today

Reminder :)

Hey @lchayoun good morning.
I believe we have it release now.
NEW VERSION RELEASED
BUILD FINISHED

Could you please help me out to create a release here on GitHub I'm uncertain what's added with this one :D

@lchayoun
FYI v1.7.6.RELEASE is on maven central.


PlanningCalendar Appointments not resizable to the left side

Hey, are there any plans to make the left side of appointments inside the PlanningCalendar resizable?
The PlanningCalendarRow has the appointmentResize Optionm but it only works for the right side of the appointment. I find this to be inconsistent in the design. The SinglePlanningCalendar allows resizing to both sides (up and down).
OpenUI5 version:
Any
Browser/version (+device/version):
Any
Any other tested browsers/devices(OK/FAIL):
X
URL (minimal example if possible):
https://sapui5.hana.ondemand.com/sdk/#/entity/sap.m.PlanningCalendar/sample/sap.m.sample.PlanningCalendarDnD
User/password (if required and possible - do not post any confidential information here):
Steps to reproduce the problem:

Go to left side of Appointment
Try resizing it to the left

What is the expected result?
Appointment gets resized to the left and the StartDate gets updated
What happens instead?
Mouse cursor doesn't change and the left side is not draggable

Hello @UltimateToaster,
Thank you for sharing this finding. I've created an internal incident<PHONE_NUMBER>. The status of the issue will be updated here in GitHub.
Regards,
Niya

Backlog item is BGSOFUIBALKAN-7399


std::fmt::Display implementation on error shapes does not honor the sensitive trait

This model:
@error("client")
structure ErrorWithMessage {
    message: SensitiveString
}

@sensitive
string SensitiveString

generates:
#[allow(missing_docs)] // documentation missing in model
#[derive(std::clone::Clone, std::cmp::PartialEq)]
pub struct ErrorWithMessage {
    #[allow(missing_docs)] // documentation missing in model
    #[doc(hidden)]
    pub message: std::option::Option<std::string::String>,
}
impl std::fmt::Debug for ErrorWithMessage {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        let mut formatter = f.debug_struct("ErrorWithMessage");
        formatter.field("message", &"*** Sensitive Data Redacted ***");
        formatter.finish()
    }
}
impl ErrorWithMessage {
    /// Returns the error message.
    pub fn message(&self) -> std::option::Option<&str> {
        self.message.as_deref()
    }
    #[doc(hidden)]
    /// Returns the error name.
    pub fn name(&self) -> &'static str {
        "ErrorWithMessage"
    }
}
impl std::fmt::Display for ErrorWithMessage {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "ErrorWithMessage")?;
        if let Some(inner_1) = &self.message {
            write!(f, ": {}", inner_1)?;
        }
        Ok(())
    }
}
impl std::error::Error for ErrorWithMessage {}
...

Note how the Debug implementation honors the sensitive trait, but the Display implementation does not.
The code that generates the Debug implementation is:
https://github.com/awslabs/smithy-rs/blob/ffafbec885c1e83a460fed38fc98119bb63d0439/codegen-client/src/main/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/StructureGenerator.kt#L108-L127
The code that generates the Display implementation is:
https://github.com/awslabs/smithy-rs/blob/ffafbec885c1e83a460fed38fc98119bb63d0439/codegen-client/src/main/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/error/TopLevelErrorGenerator.kt#L82-L93

During implementation of Logging in the Presence of Sensitive Data, I added https://github.com/awslabs/smithy-rs/blob/dcfb85578ef10e8d4fcb037c2fcf7d2a5e879f70/rust-runtime/aws-smithy-http-server/src/instrumentation/sensitivity/sensitive.rs.
Re-using this machinery might be a good idea because:

Anything using Sensitive would be enjoy toggling via the feature flag unredacted-logging.
The redaction word is no longer a "magic constant" by virtue of https://github.com/awslabs/smithy-rs/blob/dcfb85578ef10e8d4fcb037c2fcf7d2a5e879f70/rust-runtime/aws-smithy-http-server/src/instrumentation/sensitivity/mod.rs#L26.

This changes the proposed implementation very slightly:
impl std::fmt::Debug for ErrorWithMessage {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        let mut formatter = f.debug_struct("ErrorWithMessage");
        formatter.field("message", Sensitive(self.message));
        formatter.finish()
    }
}

I think the current implementation would only make sense if the @sensitive trait could only be used in member shapes:
structure ErrorWithMessage {
    @sensitive
    message: String
}

That way you could only worry about the field being sensitive in the context of the encompassing ErrorWithMessage struct (like we do in the Debug/Display impls for it).
But if we have a plain type like:
@sensitive
string SensitiveString

That should be sensitive regardless of where it's used, but currently you could do:
println!("{}", error_with_message.message/* or .unwrap() */)

And have it logged.

I think the only way to fix it would be to generate a Sensitive<String> everywhere SensitiveString is used in the Smithy model.

Done in #1802.

@jjant We should create a new issue with your findings in https://github.com/awslabs/smithy-rs/issues/1743#issuecomment-1260989510 about whether we should wrap Strings to make their Display implementation honor sensitive; we still need to (eventually) make a decision on that.


Add content to Skip link guidance about problem caused by preservation of fragment identifiers between pages

The skip link component adds a #main-content fragment identifier to the current URL. This can persist across pages causing an unexpected jump to the main content area on load. I'd like to add a warning about this to the guidance, along with tips about ways teams could write their code to avoid this.
Related component
https://design-system.service.gov.uk/components/skip-link/
Context
This problem has been seen to happen in the following scenario:

the skip link was used, thereby adding #main-content to the current URL
you leave the page via a successful form submission
the form doesn't set the action attribute and so POSTs to the current URL
the server uses the POST -> Redirect -> GET pattern to navigate to the next page

Given all that, the browser will preserve #main-content in the new URL[^1] causing the next page to jump to the start of the main content area when it loads.
This was picked up as an issue by the Digital Accessibility Centre (DAC) in a recent audit of GOV.UK Notify[^2], who stated that it failed the WCAG 2.4.3 (Focus Order) success criteria.
Given the POST -> Redirect -> GET pattern is so commonly used in web apps, I think there's some value in making teams aware of this problem and helping them write their code in a way that stops it happening.
Alternatives
N/A
Additional information (if applicable)
Suggested changes, to stop the problem occurring are:

setting the action attribute on the <form> tag to match the current URL, without #main-content
setting the URL for the next page explicitly using the Content-Location header

References
[^1]: This is correct behaviour, as defined in Handling of fragment identifiers in redirected URLs
[^2]: Issue 'ID: DAC_Focus_order_01' on page 19 of the audit report (needs a GDS Google account for access)

Will investigate if this can be fixed in code before deciding on any content. Also if this affects other components.

We also has this issue picked up in an accessibility audit.
It flagged that the URL fragment ‘#main-content’ was persisting between page redirects, which “could be confusing and disorienting for screen reader and keyboard only users, who would expect focus to begin at the top of the page.”
Part of the issue is an inconsistency of approach; as outlined above, all our forward submit buttons on each form page preserve the skip link fragment, due to the native browser behaviour for 3xx redirects, but any link with a href does not (eg. back buttons, links in the footer). Where the fragment is preserved, focus begins at the heading level 1 or first form field of the newly loaded page. Where it isn’t preserved, it will be at the top of the next page, at the skip link. The auditors felt that this was focus “behaving unexpectedly”, in a manner that could be “confusing and disorienting” .
The auditors have suggested that focus always begins at the top of newly loaded pages, at the beginning of the  element (ie. at the skip link), as “this will make the navigation more predictable and understandable to screen reader and keyboard only users.”
We’re not sure this advice is correct. We think that:

Keyboard users don’t want to always have to skip header / menu content on every page
While more consistent, the burden of making the skip link required on every page would be a worse outcome for users than having it persist 90% of the time
This is browser built in behaviour for 3xx redirects, defined in the HTML specification, and we shouldn't override that sort of thing without strong reason

If you do have any suggestions on what course of action will lead to the best experience for users, we'd be happy to hear them!

Since I raised this issue, my team (GOV.UK Notify) has implemented a fix for the issue so its worth adding an update.
We decided that fragment identifiers should be stripped from URLs used in POST requests and chose the approach of setting the action attribute to the URL of the page.
We felt that the reasons fragment identifiers are carried through seemed related to the use of HTTP requests for 'resources', so more about how APIs use HTTP than user interfaces in web browsers. The GET -> REDIRECT -> POST pattern for web pages carrying through the fragment seemed more like an accident of how empty actions are interpreted and adherence to the HTTP spec. The latter has to work for both APIs and user interfaces in web browsers so cannot prioritise the needs of our (website) users.
When we looked at pages we redirect to, they are often very different from the one you came from. Even when they aren't, like pages that make up parts of a transactional journey, we have evidence from an accessibility audit that that situation can also be confusing for most users, particularly those using screen readers, or not.
In terms of the approach, we had to change a lot of pages so were mainly guided by the risks involved. The risk of changing the action was easier for us to manage than adding Content-Location for all POST requests and our code had access to the page URL so the implementation was fairly simple. I could imagine that decision being different if you worked on a project where the HTML was harder to change or the test coverage for the HTML in pages wasn't as comprehensive.
We looked into just setting action="#" to flush the fragment identifier. This did work but we felt the intent was less clear when reading the code and we worried about the impact of this being added to the browser history.


MarketPlace "supposed UTF-8 string is not valid UTF-8"

Description
After upgrading to 6.10, I'm back with the error described here https://github.com/OpenNebula/one/issues/6390. When it previously occurred, it self-resolved after a few days and we dropped it there.
Adding --verbose doesn't actually get any relevant output, and nothing is written to log files in /var/log/one/ when this happens.
I'm happy to collect more debug info if anyone can give me an hint here. Thanks!
To Reproduce
root@gvm:~# onemarketapp  list
Unexpected error executing code for particular method, detected by Xmlrpc-c method registry code.  Method did not fail; rather, it did not complete at all.  263409-byte supposed UTF-8 string is not valid UTF-8.  Unrecognized UTF-8 initial byte value 0x96

Expected behavior
The command completes with no errors.
Details

Affected Component: ONE
Hypervisor: N/A
Version: 6.10

Additional context

Progress Status

[ ] Code committed
[ ] Testing - QA
[ ] Documentation (Release notes - resolved issues, compatibility, known issues)

what OS are you on? Cannot reproduce on my end

Debian 11
Is there any way to look a bit deeper at what's throwing this error?

One thing, in case it rings a bell to you - onemarketapps list throws the error above, but I'm able to see the list of IDs through onemarket show:
root@gvm:~# onemarket show 0
MARKETPLACE 0 INFORMATION
ID             : 0
NAME           : OpenNebula Public
USER           : oneadmin
GROUP          : oneadmin
STATE          : ENABLED
MARKET_MAD     : one

MARKETPLACE CAPACITY
TOTAL:         : 0M
FREE:          : 0M
USED:          : 0M

PERMISSIONS
OWNER          : uma
GROUP          : u--
OTHER          : u--

MARKETPLACE TEMPLATE
DESCRIPTION="OpenNebula Systems MarketPlace"
MARKET_MAD="one"

MARKETAPPS
435
[...]
509

(I only have the default MarketPlace and Docker's, which is empty)

Hello @gbonfiglio,
we had some charset/locale issues with the DB in the past, it looks like it is carried over by the upgrade.
Identify corrupted app ID
Let's try to identify the app, with the wrong locale, in the onemarket list I can see app IDs from 435..509, try to execute:
for i in {435..509}; do onemarketapp show $i; done

Note the app ID, which fails to display, later I'll refer to this app as <corrupted_app_id>
Get more info to help us solve the issue
Now let's try to identify the issue, please connect to the MySQL DB and send as output of the following commands:
$ mysql -s -u <mysql_username> -p<mysql_password> opennebula
mysql> select * from local_db_versioning;
mysql> SELECT default_character_set_name,default_collation_name FROM information_schema.SCHEMATA WHERE schema_name = "opennebula";
mysql> SELECT CCSA.character_set_name,CCSA.collation_name FROM information_schema.`TABLES` T,information_schema.`COLLATION_CHARACTER_SET_APPLICABILITY` CCSA WHERE CCSA.collation_name = T.table_collation A
ND T.table_schema = "opennebula" AND T.table_name = "marketplaceapp_pool";
mysql> select * from marketplaceapp_pool where oid=<corrupted_app_id>;

You can find your MySQL username and password in /etc/one/oned.conf
Workaround to solve the issue
It should be enough to remove the corrupted app from the DB, the OpenNebula will reload the app in 10 minutes.
$ mysql -s -u <mysql_username> -p<mysql_password> opennebula
mysql> delete from marketplaceapp_pool where oid=<corrupted_app_id>;

Run onedb fsck to fix market reference to deleted app

Hey Pavel, thanks for the update here - what would I be looking for exactly in the onemarketapp show cycle you shared above? It prints a lot of stuff, but nothing in stderr. I've also grepped "error, UTF-8, xmlrpc" and nothing is returned.

First two outputs in the meantime:
MariaDB [opennebula]> select * from local_db_versioning;
+-----+---------+------------+-------------------------------------------------------------------------------+----------+
| oid | version | timestamp  | comment                                                                       | is_slave |
+-----+---------+------------+-------------------------------------------------------------------------------+----------+
|   0 | 5.4.1   |<PHONE_NUMBER> | OpenNebula 5.4.6 daemon bootstrap                                             |        0 |
|   1 | 5.6.0   |<PHONE_NUMBER> | Database migrated from 5.4.1 to 5.6.0 (OpenNebula 5.6.0) by onedb command.    |        0 |
|   2 | 5.8.0   |<PHONE_NUMBER> | Database migrated from 5.6.0 to 5.8.0 (OpenNebula 5.8.0) by onedb command.    |        0 |
|   3 | 5.10.0  |<PHONE_NUMBER> | Database migrated from 5.8.0 to 5.10.0 (OpenNebula 5.9.80) by onedb command.  |        0 |
|   4 | 5.12.0  |<PHONE_NUMBER> | Database migrated from 5.10.0 to 5.12.0 (OpenNebula 5.12.0) by onedb command. |        0 |
|   5 | 6.0.0   |<PHONE_NUMBER> | Database migrated from 5.12.0 to 6.0.0 (OpenNebula 6.0.0) by onedb command.   |        0 |
|   6 | 6.2.0   |<PHONE_NUMBER> | Database migrated from 6.0.0 to 6.2.0 (OpenNebula 6.2.0) by onedb command.    |        0 |
|   7 | 6.4.0   |<PHONE_NUMBER> | Database migrated from 6.2.0 to 6.4.0 (OpenNebula 6.4.0) by onedb command.    |        0 |
|   8 | 6.6.0   |<PHONE_NUMBER> | Database migrated from 6.4.0 to 6.6.0 (OpenNebula 6.6.0) by onedb command.    |        0 |
|   9 | 6.8.0   |<PHONE_NUMBER> | Database migrated from 6.6.0 to 6.8.0 (OpenNebula 6.8.0) by onedb command.    |        0 |
|  10 | 6.10.0  |<PHONE_NUMBER> | Database migrated from 6.8.0 to 6.10.0 (OpenNebula 6.10.0) by onedb command.  |        0 |
+-----+---------+------------+-------------------------------------------------------------------------------+----------+
11 rows in set (0.000 sec)

MariaDB [opennebula]> SELECT default_character_set_name,default_collation_name FROM information_schema.SCHEMATA WHERE schema_name = "opennebula";
+----------------------------+------------------------+
| default_character_set_name | default_collation_name |
+----------------------------+------------------------+
| latin1                     | latin1_swedish_ci      |
+----------------------------+------------------------+

Hey Pavel, thanks for the update here - what would I be looking for exactly in the onemarketapp show cycle you shared above? It prints a lot of stuff, but nothing in stderr. I've also grepped "error, UTF-8, xmlrpc" and nothing is returned.

I expected the same error as onemarketapp list for one of the onemarketapp.
Are you sure the command onemarketapp list was working in 6.8 version? The upgrade to 6.10 doesn't touch the market apps, i don't see how it may fail after upgrade.
I know we had some charset issues when the MySQL changed default charset from latin1 to utf8mb4, but they should be fixed by #6113 , included in 6.8.0 version.
You can try
$ onemarket disable 0    # It will remove all apps from this marketplace
$ onemarektapp list      # To double check the error disappeard, there should be no apps
$ onemarket enable 0     # To reload all apps

If this doesn't help, please post here as a file attachment full output of select * from marketplaceapp_pool;

Are you sure the command onemarketapp list was working in 6.8 version?

I am not as I never tried it before, but the MarketPlace UI in Sunstone was definitely working as I pulled the Debian 12 image 10 days ago or so, now it's erroring out in the same way. This issue presented after the upgrade to 6.8, but disappeared afterwards (see https://github.com/OpenNebula/one/issues/6390).

I have now disabled both marketplaces:
root@gvm:~# onemarket list
  ID NAME                                                                                SIZE AVAIL        APPS MAD     ZONE STAT
   1 DockerHub                                                                                0M -               0 dockerh    0 off
   0 OpenNebula Public                                                                                0M -               0 one        0 off

The error persists:
root@gvm:~# onemarketapp list
Unexpected error executing code for particular method, detected by Xmlrpc-c method registry code.  Method did not fail; rather, it did not complete at all.  12175-byte supposed UTF-8 string is not valid UTF-8.  Unrecognized UTF-8 initial byte value 0x96

There are still some entries in the database, dump here: https://gist.github.com/gbonfiglio/395b785219f1be249a20e78410666b9f
(none of those entries is familiar to me, must be auto-downloaded stuff)

I've recovered it based on your suggestions above like this:
1 - disable all markets
2 - stop OpenNebula
3 - delete from marketplaceapp_pool;
4 - onedb fsck
5 - start
Now list works. Waiting for the apps to be pulled again.
I'm curious as to how/why those entries got stuck in my DB though?

Glad to here it works.
Thanks for the list of remaining apps - they are all from the DockerHub market. All of them registered in last month. Some of them contains UTF8 characters.
I'm afraid that if you enable DockerHub market again, the error returns.
I'll make a note for me for later, as I can't work on this now.
Possible steps to reproduce:

backend DB with charset latin1
Markeplace app with UTF8 characters

onemarketapp list may return UTF8 error
onemarket disable may not delete apps with UTF8 characters

Thankyou! Two more things for you:

DockerHub has always been empty for me, including while things were broken (onemarket show 1 returned no apps)
Now 12 hours later, it's still empty (whilst the ONE MarketPlace has fully populated) and things are working
This is my current DB dump (now that things are working): https://gist.github.com/gbonfiglio/1e4407c5a7cca3d2e641f9b797ba7a5d

Should I see something in the DockerHub marketplace?

I forgot that the DockerHub marketplace was removed in release 6.10, you may safely delete it by onemarket delete DockerHub

DockerHub has always been empty for me, including while things were broken (onemarket show 1 returned no apps)

The corrupted marketapps were orphaned, because the onemarket disable DockerHub removed references from the market, but removing the app failed due to corrupted UTF8 string

Gone! In this case, shouldn't the 6.10 migration have killed it?

Closing this, created more general issue, for possible charset bugs #6709


Python wishlist

I'm going to file separate issues for a lot of these, in the interest of expediency I'm just dumping a lot of todos, bugs, and nice-to-haves here.

[ ] "start_effect" parameter help should know effects.ParticleEffects is the best fit:

[ ] the top answers shouldn't be keywords:

[ ] globals used in only one function could be made into locals in both py and ts:

[ ] No way to collapse image literals:

[ ] We shouldn't auto-complete all the parameters for simple functions, maybe only ones with handlers or enum args:

[ ] bad auto-complete emits __internal.__onOff symbol:
sprite.set_flag completes into sprite.set_flag(SpriteFlag.StayInScreen, __internal.__onOff(False))

[ ] auto-complete emits enum with camel case instead of all-caps snake case:

[ ] auto-complete for "img" should fill in a blank image literal, not whatever this is:

For reference, issue on internals showing up in auto complete: https://github.com/microsoft/pxt-arcade/issues/1898 need to skip over shim=TD_ID functions when emitting the completion

Split this into: https://github.com/microsoft/pxt-arcade/issues/2036 https://github.com/microsoft/pxt-arcade/issues/2034 https://github.com/microsoft/pxt-arcade/issues/2035


Create 3Sum.cpp

The issue is resolved and giving required output as above.

Issue is resolved @akgmage please check


ncrease CDK Installer unit test coverage

test this

Codecov Report

Merging #720 into master will decrease coverage by 0.14%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #720      +/-   ##
==========================================
- Coverage   96.96%   96.82%   -0.15%
==========================================
  Files          29       29
  Lines        2537     2674     +137
  Branches      216      380     +164
==========================================
+ Hits         2460     2589     +129
+ Misses         77       72       -5
- Partials        0       13      +13

Impacted Files
Coverage Δ

browser/model/cdk.js
95.23% <100%> (-3.82%)
:arrow_down:

browser/pages/confirm/controller.js
78.88% <0%> (-2.93%)
:arrow_down:

browser/services/componentLoader.js
98.78% <0%> (-1.22%)
:arrow_down:

browser/services/data.js
97.29% <0%> (-0.77%)
:arrow_down:

browser/model/helpers/hash.js
100% <0%> (ø)
:arrow_up:

browser/services/platform.js
100% <0%> (ø)
:arrow_up:

browser/model/installable-item.js
100% <0%> (ø)
:arrow_up:

browser/directives/pathValidator.js
100% <0%> (ø)
:arrow_up:

browser/model/helpers/version.js
100% <0%> (ø)
:arrow_up:

... and 17 more

Continue to review full report at Codecov.

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


Add a sliver version

Something like SliverGrid + DragSelectGridView

I could try to make a pr if you agree this is needed

Every Flutter grid uses SliverGrid. Can you please further elaborate what are you trying to achieve? :)

Basically one that you could put in a CustomScrollView and wrap with Sliver widgets like SliverSafeArea

I'll need to take a deeper look into this to decide whether a structural change is required. I should be able to point the key parts that should be taken into consideration to apply such change.
I'll try to get do this at this weekend :)

IS there any good news ? I need SliverGrid version.


Fix dupe account handling in 'ledger-tool program run' command

Problem
The agave-ledger-tool's functionality to execute sBPF programs out-of-band did not properly handle duplicate accounts.
Summary of Changes
This patch introduces instruction account deduplication.
Locally tested to confirm that duplicate accounts are serialized correctly and that non-duplicate account behavior didn't change.
Fixes #

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 82.1%. Comparing base (b0cfffb) to head (c661df5).
Report is 3 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##           master    #1191     +/-   ##
=========================================
- Coverage    82.1%    82.1%   -0.1%
=========================================
  Files         886      886
  Lines      236372   236372
=========================================
- Hits       194204   194193     -11
- Misses      42168    42179     +11


Hardcode aave token cards

Based on #2060
Closes #2058, closes #2061

[x] Need TokenScript updated files for aEth for testing
[x] Need TokenScript updated files for debt token for testing (look for "//hhh replace with debt token" and paste the token contract)

Buzz @colourful-land and @James-Sangalli

[ ] I'm getting a very different "Borrowing Power Used" used from Weiwu's example. Weiwu and James to verify when you get it running.

[ ]  I'm getting a very different "Borrowing Power Used" used from Weiwu's example. Weiwu and James to verify when you get it running.

Borrow power in the aETH card is correct and wrong in the debt card.


Update win32 version

This pr updates the Win32 version, given some recent changes on katip and iohk-monitoring-framework.
The new version allows to revert an ugly hack we did to support seeking in windows.

Don't forget to update the nix stuff.

@mrBliss I fixed nix.
Maybe we want to ask the opinion of people at the network team for this pr?

@mrBliss I fixed nix.
Maybe we want to ask the opinion of people at the network team for this pr?

@coot You're working on Windows support. What's your opinion?

Yes I am fine with it.

One thing that might be best to check before we merge this is whether all downstream repos can handle this dependency change on Win32: cardano-node, cardano-byron-proxy, and cardano-explorer. I don't think it will be an issue, though.

btw, the stack.yaml still pins the Win32 version to <IP_ADDRESS>: https://github.com/input-output-hk/ouroboros-network/pull/1160/files#diff-fafd0cdcd559a7b124cc61c29413fb54R74

Subsumed by #1164.


Donor checks the status of the closed aid package (order placed, order shipped, order received).

[ ] Donor checks the status of the closed aid package (order placed, order shipped, order received).

Fixed at: https://github.com/LSFLK/MedicinesforLK/pull/164
The statuses we have on the implementation are a bit different, btw.


FR: Need a more detailed README

Readme should be a bit more detailed, including:

How to include this in Maven / Gradle
Current version
How to use or a link to documentation
Link to license and Contributing

See https://github.com/GoogleCloudPlatform/Template for suggested outline.

Agreed.

Before adopting this library in google-cloud-java we should fix this. Also, do we have the javadoc available somewhere? If not, can we use gh-pages for it (similar to what guava does)?
@lesv Is this library referenced from official docs? I see that in this page the REST Apiari's credentials are introduced instead.
/cc @garrettjonesgoogle

I was just looking for this in official docs, can't seem to find.

I'm fine with using gh-pages.

I'm happy w/ just gh-pages & the readme.


Layout-put not working anymore

It seems like the layout-put tag is not working as expected anymore. The test confirms this:
4) render layout-use:
     Error: Unexpected output for "/marko/test/fixtures/templates/layout-use/template.marko":
EXPECTED (/marko/test/fixtures/templates/layout-use/expected.html):
---------

BODY CONTENT
FOOTER CONTENT
HEADER CONTENT

BODY CONTENT
FOOTER CONTENT
VALUE HEADER

BODY CONTENT
FOOTER CONTENT
DEFAULT TITLE

BODY CONTENT
FOOTER CONTENT
---------
ACTUAL (/marko/test/fixtures/templates/layout-use/actual.html):
---------

DEFAULT TITLE

DEFAULT TITLE

DEFAULT TITLE

---------

Instead of using the content from layout-put it falls back to the default if available.
Any idea what's wrong here?

I'm not seeing any failing tests and our CI never reported any failing tests. I will take a look and see if I can reproduce and report back soon.
Thanks for reporting the problem.

@viviangledhill I just did a refresh npm install with the latest code of<EMAIL_ADDRESS>(master branch) and I am still not able to reproduce the problem. Which version of marko are you testing with?

I also tested with the latest code on the v1.6 branch and am not able to reproduce.

Also, one other thought: if you have marko-layout or marko-async installed as dependencies in your project then you should remove those dependencies. Both marko-layout and marko-async are core dependencies of marko and are already included. Having multiple versions of those modules might be causing problems in your app.

That is strange. If I checkout the latest version with a blank npm install ... it's still failing.
I'm using node 0.10.36.
Any idea how I could triage this issue?

Did the same on a different machine. Everything went fine without issues. Most likely it's just a problem with my machine.
Let me know if you have any idea how I could isolate this issue.
Thanks
-Vivian

@viviangledhill Did you try deleting your node_modules directory?

Yes, did that without success.
Anyhow, found the issue.
There was a node_modules directory in a parent directory by accident. So for some reason it interfered with that and caused these errors.
Thanks for your quick help!
-Vivian

Ok. Interesting. I'll look into making a change to prevent the core taglibs from loading multiple times even though it is an edge case. Thanks for the update and I'm glad you got everything working.


Refuse to load LavaDome within non-top documents

Make sure the LavaDome code refuses to load in non-top documents from the start, to not allow attackers to reload the entire page within an iframe they control its environment. e.g:
const ifr = document.body.appendChild(document.createElement('iframe'));
const payload = `// hook into a primitive LavaDome counts on to steal its secret`;
ifr.contentWindow.eval(payload);
const html = await (await fetch('/')).text();
ifr.contentDocument.write(html);

I'm on the fence with this one. I can think of legit use cases (XO iframe where LavaDome is integrated), and then if I want to support non-top docs conditionally it's practically impossible to do so safely, because passing a bool arg indicating whether to run or not can also be tampered by the attacker..
Closing for now, also because I'm not sure there's an actual attack surface here to begin with.


Issue 96

Added the welcome screen for when no database is open in JabRef; as show in the image below:

Mandatory checks

[ ] Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
[ ] Tests created for changes (if applicable)
[ ] Manually tested changed features in running JabRef (always required)
[x] Screenshots added in PR description (for UI changes)
[ ] Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
[ ] Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

@u7663394 ready for review now


[docs-infra] Dark mode not persisting after switching from light mode

Steps to reproduce
Link to live example: (required)
Steps:
1.Navigate to the website in light mode.
2.Switch to dark mode.
3.Note the appearance in dark mode.
4.Refresh the page or navigate to another page within the website.
Current behavior
After switching from light mode to dark mode, the website briefly displays in light mode before switching back to dark mode.
https://github.com/mui/material-ui/assets/93616362/5c558e6d-cfff-469e-8271-bcc007c00889
Expected behavior
The website should consistently remain in dark mode after the user has selected it, regardless of previous light mode usage.
Context
This issue affects the user experience of the website, particularly for users who prefer dark mode for extended periods. Consistent dark mode usage is expected for better accessibility and visual comfort.

  Output from `npx @mui/envinfo` goes here.

Search keywords: MUI, dark mode, light mode, bug, behavior, environment, reproducible

Hey @twassim1234, thanks for the issue! Can you try to reproduce this problem somehow? I can't reproduce it myself. From the issue description, it seems you intended to attach a video, but it apparently didn't go through. That would be helpful.

https://github.com/mui/material-ui/assets/93616362/7d747cf7-61cf-406f-a426-4aa275479d03

Hey @twassim1234, thanks for the issue! Can you try to reproduce this problem somehow? I can't reproduce it myself. From the issue description, it seems you intended to attach a video, but it apparently didn't go through. That would be helpful.

I add another video and now it's clear

The rendering is done with 4 steps:

Render light mode
Add space for the tabbed code blocks
Add the tab state and the code associated
Style all the code blocks

I've successfully reproduced the bug in my browser. In the video, you can see that the first attempt showed the bug mentioned , while the second attempt worked as expected. This confirms the existence of the bug.
https://github.com/mui/material-ui/assets/147313410/cf8bfff8-c34d-42e9-9c2a-9861e780d85a

I've successfully reproduced the bug in my browser. In the video, you can see that the first attempt showed the bug mentioned , while the second attempt worked as expected. This confirms the existence of the bug.

i think there is nothing changed

I've successfully reproduced the bug in my browser. In the video, you can see that the first attempt showed the bug mentioned , while the second attempt worked as expected. This confirms the existence of the bug.

i think there is nothing changed

Could you please explain more what do you mean by nothing changed ? I jus t wanted to show that the bug does indeed happen but not all the time.

We are aware of this issue, we can avoid it once all docs is migrated to use CSS variables. For example, at this moment this is done on the landing page: https://mui.com (if you refresh there is no flickering there), but it is not done in the docs pages. We have a guide on how you can avoid this in your apps in https://mui.com/material-ui/experimental-api/css-theme-variables/overview/ guide.

We are aware of this issue, we can avoid it once all docs is migrated to use CSS variables. For example, at this moment this is done on the landing page: https://mui.com (if you refresh there is no flickering there), but it is not done in the docs pages. We have a guide on how you can avoid this in your apps in https://mui.com/material-ui/experimental-api/css-theme-variables/overview/ guide.

To facilitate the process, would you be open to providing some guidance or examples on how we can implement this effectively in the docs pages? Perhaps we could collaborate on improving the documentation together. Additionally, if there are any specific challenges or roadblocks you've encountered in implementing CSS variables in the docs, feel free to share, and we can work through them together.