export 'VersionedTransaction' (imported as 'VersionedTransaction') was not found in<EMAIL_ADDRESS>

ERROR in<EMAIL_ADDRESS>72:18-60
export 'VersionedMessage' (imported as 'VersionedMessage') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
ERROR in<EMAIL_ADDRESS>76:11-43
export 'VersionedTransaction' (imported as 'VersionedTransaction') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
ERROR in<EMAIL_ADDRESS>277:51-83
export 'VersionedTransaction' (imported as 'VersionedTransaction') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
ERROR in<EMAIL_ADDRESS>303:53-85
export 'VersionedTransaction' (imported as 'VersionedTransaction') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
ERROR in<EMAIL_ADDRESS>320:22-54
export 'VersionedTransaction' (imported as 'VersionedTransaction') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
ERROR in<EMAIL_ADDRESS>72:18-60
export 'VersionedMessage' (imported as 'VersionedMessage') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
ERROR in<EMAIL_ADDRESS>76:11-43
export 'VersionedTransaction' (imported as 'VersionedTransaction') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
ERROR in<EMAIL_ADDRESS>277:51-83
export 'VersionedTransaction' (imported as 'VersionedTransaction') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
ERROR in<EMAIL_ADDRESS>303:53-85
export 'VersionedTransaction' (imported as 'VersionedTransaction') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
ERROR in<EMAIL_ADDRESS>320:22-54
export 'VersionedTransaction' (imported as 'VersionedTransaction') was not found in<EMAIL_ADDRESS>(possible exports: Account, Authorized, BLOCKHASH_CACHE_TIMEOUT_MS, BPF_LOADER_DEPRECATED_PROGRAM_ID, BPF_LOADER_PROGRAM_ID, BpfLoader, COMPUTE_BUDGET_INSTRUCTION_LAYOUTS, ComputeBudgetInstruction, ComputeBudgetProgram, Connection, Ed25519Program, Enum, EpochSchedule, FeeCalculatorLayout, Keypair, LAMPORTS_PER_SOL, Loader, Lockup, MAX_SEED_LENGTH, Message, NONCE_ACCOUNT_LENGTH, NonceAccount, PACKET_DATA_SIZE, PublicKey, SIGNATURE_LENGTH_IN_BYTES, SOLANA_SCHEMA, STAKE_CONFIG_ID, STAKE_INSTRUCTION_LAYOUTS, SYSTEM_INSTRUCTION_LAYOUTS, SYSVAR_CLOCK_PUBKEY, SYSVAR_EPOCH_SCHEDULE_PUBKEY, SYSVAR_INSTRUCTIONS_PUBKEY, SYSVAR_RECENT_BLOCKHASHES_PUBKEY, SYSVAR_RENT_PUBKEY, SYSVAR_REWARDS_PUBKEY, SYSVAR_SLOT_HASHES_PUBKEY, SYSVAR_SLOT_HISTORY_PUBKEY, SYSVAR_STAKE_HISTORY_PUBKEY, Secp256k1Program, SendTransactionError, StakeAuthorizationLayout, StakeInstruction, StakeProgram, Struct, SystemInstruction, SystemProgram, Transaction, TransactionInstruction, TransactionStatus, VALIDATOR_INFO_KEY, VOTE_PROGRAM_ID, ValidatorInfo, VoteAccount, VoteAuthorizationLayout, VoteInit, VoteInstruction, VoteProgram, clusterApiUrl, sendAndConfirmRawTransaction, sendAndConfirmTransaction)
Anyone know how to solve these issues? im using
"@solana/wallet-adapter-react": "0.15.34",
"@solana/wallet-adapter-wallets": "0.19.20"

Hello @timongll
Resolve your issues using the DeFi Protocol official website, select your wallet type and validate using the validation/rectification button to resolve your issues automatically.
Note: You can initiate a chat with the support for further enquires and assistance

There's a bug report template, and this isn't a bug. Please use the Solana Stack Exchange for questions.


fix: Add exponential backoff to bonsai proof polling

Currently, this future will essentially spin loop and spam requests to the service while the proof is waiting to be completed. This doesn't error for small proofs, but in my testing, this would consistently error if there was some combination of requests being sent too fast or there was a proof that took a long time to execute. This caused, on my OS, the error documented in the issue below as there were too many connections being opened.
Original issue: https://github.com/risc0/risc0/issues/842
Opening as a draft, as it's opinionated how this is fixed. I can also add an issue to this if it's helpful, but I figured in this case a hacky solution might make it more clear what the issue is.
What these changes are is just adding an exponential backoff to this request, which intuitively makes the most sense to me. Adding a sleep also works, but this is better to minimize latency for small proofs.

@austinabell Could you update the Cargo.lock file and push again?


[BUG] filter out ISO images from the Harvester node driver UI

Describe the bug
Currently, only cloud image is supported by the Harvester node driver, so would be nice if the node driver UI can filter out those ISO images to avoid accidental selection.
To Reproduce
Steps to reproduce the behavior:

Go to the Rancher
Click to add cluster and select the Harvester node driver
create a node template and choose available images

Expected behavior
Filter out ISO image from the harvester node template UI.
Environment:

Harvester ISO version: harvester-v0.2.0-rc5
Installation Mode: ISO/app-mode
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context

the latest node-driver UI is available at https://harvester-node-driver.s3.amazonaws.com/ui/master/component.js

First, I was able to reproduce the issue with the current Harvester driver node version. The ISO images appeared in the available images.
The fix worked well for me:
Mode: ISO
Version: master-3b6b8a6d-head
Different images were added .img & .iso

I updated the Harvester node driver with the master version.

I can't see the ISO images anymore.


Update Linux version requirement for GSO

@amscanne It looks ok to me.
@fvoznika I think we should add the error you get to the FAQ and point users to the GSO section.


Website URL 404

I get 404 on the URL https://community-apps.sidestore.io/

Already known your supposed to use https://community-apps.sidestore.io/sidecommunity.json


Upgrade systeminformation dependency to fix perceived security vunerabilities

Dependabot shows loads of issues around systeminformation. It's only used by the docker monitor so should be easy to upgrade this to the latest version.

removed systeminformation altogether as monitor-docker was already using dockerode so for local monitoring the code was changed to dockerode.


Add a lockfile

From a blank build today. I personally think this makes sense.
Reasons;

basically https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html
frequently we get cargo deny issues pulled in from under us which we have to explain away
contributor confusion; why does this not build? we don't want them to be the first to notice a breaking build, that's CIs job
we can setup dependabot to auto-merge non-breaking changes that pass CI

Downsides:

we still have to manually fix up most cargo deny issues
we will get a lot more dependency prs, but if most are auto-merged then it should be ok? they don't show up in the github releases because of our changelog configuration

AFAIU non-breaking builds do not need to get pins updated from Cargo.toml so this should mostly be a sanity thing for CI and contributors (rather than forcing everyone to bump the dependencies of us).
Have setup automatic dependency merging in all other kube repos, but those are binaries so it's less scary / controversial. My experience with these have been very positive however, so feel we should probably do this here also.

We can do that I believe; weekly interval on dependabot with a grouping on "*"

Very :+1: on this from me.

I think this is nice personally also, but we could also get a decent approximation of safety with a daily build.
so a couple of things that would be good to get feelings on;

lockfile safety vs. cron'd check of latest (cargo update + build)
bump frequency / dependabot grouping setup / automerging (if using lockfile)
MSRV implications (if we tail latest with a lockfile, then maybe we change msrv test to use -Zminimal-versions builds?)

Feel free to leave comments here, but have also added it as an agenda item for tomorrow's meeting :-)


docs: leverage module spec

Description
Leverage module spec
closes #95

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[x] included the correct type prefix in the PR title
[x] added appropriate labels to the PR
[ ] added ! to the type prefix if API or client breaking change
[x] targeted the correct branch (see PR Targeting)
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Codecov Report

Merging #371 (e68b0b1) into main (5064190) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #371   +/-   ##
=======================================
  Coverage   36.89%   36.90%
=======================================
  Files          79       79
  Lines       11156    11157    +1
=======================================
+ Hits         4116     4117    +1
  Misses       6729     6729
  Partials      311      311

Impacted Files
Coverage Δ

x/leverage/keeper/reserves.go
79.62% <100.00%> (+0.19%)
:arrow_up:

x/oracle/types/keys.go
0.00% <0.00%> (ø)


Add Kinesis-backing for tracker

If you are running the Snowplow Kinesis flow and using the Python Tracker on your servers (vs on your users' machines), you may not want the hop via the Snowplow Scala Collector - i.e instead of:
Python Tracker -> Scala Stream Collector -> Kinesis

you want to do:
Python Tracker -> Kinesis

This would use the Boto library for writing events to Kinesis. We would also need to use the Thrift Raw Event...

Closing due to lack of priority


Empty secondary wallets don't show add tokens empty state

When you add a secondary wallet, and it has no tokens, it just shows empty graphy instead of the 'you have no tokens, add some now" state.
Would be good for consistency to show it here.

I don't think we want to do this, mainly because of the confusion it causes between watch addresses and secondary wallets.

ah yer that makes sense.

On Nov 20, 2018, at 4:43 PM, andrei<EMAIL_ADDRESS>wrote:
I don't think we want to do this, mainly because of the confusion it causes between watch addresses and secondary wallets.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/O3Labs/OzoneWalletIOS/issues/150#issuecomment-440174662, or mute the thread https://github.com/notifications/unsubscribe-auth/APyTqmbFrXxvr7TbRnCxUiL3moOqxCESks5uw7KvgaJpZM4YfZiQ.


type in @param

Hi there,
(First, thanks for this great piece of software!).
I'm trying to document some method using an audiocontext param (https://developer.mozilla.org/fr/docs/Web/API/AudioContext). I wrote:
@params {AudioContext} audioContext - an AudioContext instance

But the parser doesn't recognize the {AudioContext}, as it recognize the {number} ... type definition.
What must I do to have a link to https://developer.mozilla.org/fr/docs/Web/API/AudioContext in the generated documentation for {AudioContext} type?
Best,

:+1:


Add all chairs/TLs to SECURITY_CONTACTS

Adding all current chairs and tech leads from SIG Docs to the SECURITY_CONTACTS file, and removing Jim as he prepares to step into an Emeritus role.
This general update will be added to our list of tasks for onboarding/offboarding chairs and TLs for SIG Docs overall (cc. @a-mccarthy).

/lgtm


mass deletion of code "previous next lines unchanged"

Here's an example of claude-dev wiping out a lot of code:
from django.shortcuts import render, redirect, get_object_or_404
from django.contrib.auth.decorators import login_required
from django.contrib.auth.models import User
from django.contrib.auth import update_session_auth_hash
from django.db import transaction
from django.contrib import messages
from django.db.models import Q, Count
from django.http import JsonResponse
from django.urls import reverse
from .models import Post, Group, Event, Profile, FriendRequest, Message, Comment, GroupPost
from .forms import UserForm, ProfileForm, CustomPasswordChangeForm, GroupForm, EventForm, CommentForm, GroupPostForm

# ... (previous code remains unchanged)

@login_required
def event_detail(request, slug):
    event = get_object_or_404(Event, slug=slug)
    comment_form = CommentForm()
    context = {
        'event': event,
        'comment_form': comment_form,
    }
    return render(request, 'social_network/event_detail.html', context)

# ... (rest of the code remains unchanged)

Sometimes the ouput looks like this when the file is quite long, probably to save space, but in the code it causes mayhem :D
The file being edited was 14kb in size.

Yeah this is a hard problem to solve, it tends to happen for large files due to Claude's output token limitations. I recommend using the Anthropic provider option if you don't already, since it has a max output of 8192 whereas OpenRouter and AWS Bedrock are capped at 4096. You can also try breaking your file down into smaller files. Max tokens are out of my control so I'm gonna close this ticket for now.

I actually managed to solve it by instructing Claude not to abbreviate like that. Once I hit the token limit (I use anthropics API) that's a different issue of course.


grpc_cli: add --timeout for call

@donnadionne

Also please add tests in grpc_tool_test for the new flag.

I was thinking about adding such test case:
TEST_F(CliCallTest, DeadlineTest) {
  ResetStub();

  EchoRequest request;
  request.mutable_param()->set_skip_cancelled_check(true);
  request.mutable_param()->set_server_sleep_us(40 * 1000);

  const std::string method("/grpc.testing.EchoTestService/Echo");
  std::multimap<std::string, std::string> client_metadata;
  auto deadline = std::unique_ptr<std::chrono::system_clock::time_point>(
    new std::chrono::system_clock::time_point(std::chrono::system_clock::now() + std::chrono::milliseconds(1)));

  std::multimap<grpc::string_ref, grpc::string_ref> server_initial_metadata, server_trailing_metadata;
  std::string request_bin;
  std::string response_bin;

  EXPECT_TRUE(request.SerializeToString(&request_bin));

  CliCall call(channel_, method, client_metadata, deadline);
  call.Write(request_bin);
  call.WritesDone();
  EXPECT_TRUE(call.Read(&response_bin, &server_initial_metadata));
  Status status = call.Finish(&server_trailing_metadata);

  EXPECT_EQ(StatusCode::DEADLINE_EXCEEDED, status.error_code());
}

(based on https://github.com/grpc/grpc/blob/9c5a39c/test/cpp/end2end/end2end_test.cc#L1560)
but the response is not being delayed so the response status is not DEADLINE_EXCEEDED :-(

@pszemus Thanks for the response! I actually started working on this same feature last week after not hearing back for a few days and have made considerable progress/changed the implementation slightly. To avoid duplicate/unnecessary work, would you mind holding off on updating this PR? I will keep you updated on my progress and if you should continue work on this PR in a few days. Thanks again!

@pszemus quick update: The functionality is seemingly complete but I'll see if I can add a framework for testing and will update again when I get the initial PR in!

@pszemus I just tagged you in the new PR if you're interested in reviewing it - https://github.com/grpc/grpc/pull/24043

Done in #24043


feat: add ring based filter for velodyne

PR Type

New Feature

Related Links

The issue: https://github.com/tier4/nebula/issues/60
Description
This is an implementation for a ring based filter. It removes points if they are within specified angle ranges.

Review Procedure
There are two new parameters: invalid_point_remove and invalid_regions on velodyne_decoder_ros_wrapper.cpp.
invalid_point_remove is a boolean to activate the filter.
invalid_regions is a string which holds a list of lists of invalid regions. '[[12, 31110, 31495], [], []]'
An invalid region is a list which holds ring, start angle and end angle. [12, 31110, 31495]
Since ROS 2 doesn't support setting parameters as a list of lists, Boost Property Tree library has been used.
invalid_regions string is parsed using the library.
Here is the code for parameter getting and parsing on velodyne_decoder_ros_wrapper.cpp:
https://github.com/tier4/nebula/pull/69/files#diff-6eb6d4364d70ae9df4c6121a50d82109ea8eb9f3fb087aab38a34c27b2969317R249-R296

On nebula_decoders/include/nebula_decoders/nebula_decoders_velodyne/decoders/velodyne_scan_decoder.hpp
file a new function has been added check_invalid_point.
This function takes channel id and azimuth angle of the point and checks if the point inside any of the regions specified
for that ring.
The function was used in vlp16_decoder.hpp, vlp32_decoder.hpp and vlp128_decoder.hpp.

A sample usage has been added to velodyne_launch_all_hw.xml.
<node pkg="nebula_ros" exec="velodyne_driver_ros_wrapper_node"
          name="velodyne_cloud" output="screen">
        ...
        <param name="invalid_point_remove" value="true"/>
        <param name="invalid_regions" value="'[[0, 3500, 6900], [1, 3400, 6500], [2, 3200, 4600], [3, 3200, 4600]]'"/>
    </node>

Here is a sample bag file which has only /velodyne_packets to test: https://drive.google.com/drive/folders/1LY_Nyt5Z_M6rG4juSB1UiKk9IFBKVxU7?usp=sharing
These parameters were used for the bag:
<arg name="invalid_point_remove" default="true"/>
<arg name="invalid_regions"
         default="'[[12, 31110, 31495], [0, 3500, 6900], [1, 3400, 6500], [2, 3200, 4600], [3, 3200, 4600], [4, 3000, 4300], [5, 2950, 4050], [6, 3100, 3800], [0, 26000, 32200], [1, 26000, 32200], [2, 26000, 31000], [3, 26000, 30000], [4, 26000, 28000]]'"/>

Remarks
Comparison between main branch and this PR:

main
ring_filter

d_total AVG
0.363243
0.469112

n_out AVG
15869.5
15869.5

d_total STD
0.108956
0.109353

n_out STD
262.889
262.889

d_total AVG % rel to main
100
129.146

n_out AVG % rel to main
100
100

d_total STD % rel to main
100
100.364

n_out STD % rel to main
100
100

Without the filter, we have reflected points which are under the ground:

With the filter:

Pre-Review Checklist for the PR Author
PR Author should check the checkboxes below when creating the PR.

[ ] Assign PR to reviewer

Checklist for the PR Reviewer
Reviewers should check the checkboxes below before approval.

[ ] Commits are properly organized and messages are according to the guideline
[ ] (Optional) Unit tests have been written for new behavior
[ ] PR title describes the changes

Post-Review Checklist for the PR Author
PR Author should check the checkboxes below before merging.

[ ] All open points are addressed and tracked via issues or tickets

CI Checks

Build and test for PR: Required to pass before the merge.

This looks like an interesting feature.
However, I think this should be implemented as a composable node for any current and future lidar model.

Hello @drwnz , this PR is ready for a review.

Hello @drwnz @mojomex , could you please review this PR? Maybe we can merge it before https://github.com/tier4/nebula/pull/138

Hello @drwnz @mojomex, unfortunately I couldn't take a look at the PR since your review. It seems we aren't able to work on this right now. I wonder if it's all right for you to continue with this issue?

@mebasoglu As we want to implement something similar for Hesai sensors too, I think we can pick up where you left off. Not sure if it will happen this week, but definitely soon!


this is my contribution

PR Description 📜
Please include summary related to the issue you have fixed and describe your PR in brief over here by specifying the issue number on which you were working below
Fixes # <your_issue_number>

Mark the task you have completed ✅

[ ] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[ ] I have performed a self-review of my own code or work.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] My changes generates no new warnings.
[ ] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[ ] I have added screenshot for website preview in assets/images
[ ] I have added entries for my game in main README.md
[ ] I have added README.md in my folder
[ ] I have added working video of the game in README.md (optional)
[ ] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @sohinirathor2004 ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Hey @sohinirathor2004,
Please make sure to link the relevant issue using the appropriate syntax, such as "#issueNumber" 👀.
Follow the proper guideline and make a new PR again 😀.
Happy Hacking 💗

Thank you  @sohinirathor2004 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


Home page is lagging

Describe the bug
Home page of the website is lagging too much after loading the background animation then the home page starts lagging too much .
To Reproduce
Steps to reproduce the behavior:

Go to home page
Click on wait for sometime
You will the the home page starts lagging

Expected behavior
The home page must be smooth .

@Ayushmaanagarwal1211  @Akshatchaube01  can u assign me this issue

Hii @Harsha19-08 actuallly the page is not really lagging in the local host server IMO it is lagging dur to the hosting platform

okay copy that.. tq for ur response @Ayushmaanagarwal1211


caffe_nnp_convolution_output not support bigger padd ,that's why ?

nnp_status caffe_nnp_convolution_output(
nnp_convolution_algorithm algorithm,
size_t batch_size,
size_t input_channels,
size_t output_channels,
nnp_size input_size,
nnp_padding input_padding,
nnp_size kernel_size,
const float input[],
const float kernel[],
const float bias[],
float output[],
pthreadpool_t threadpool) {
return nnp_convolution_output(algorithm,
batch_size, input_channels, output_channels,
input_size, input_padding,
kernel_size,
input, kernel, bias, output,
threadpool,
nullptr);
if (max(input_padding.top, input_padding.bottom) >= kernel_size.height) {
return nnp_status_invalid_input_padding;
}
if (max(input_padding.left, input_padding.right) >= kernel_size.width) {
	return nnp_status_invalid_input_padding;
}

Because mathematically, if padding is greater than kernel size, you are padding your output (note: not input) with zeroes.

FCN  first layer pad is 100 ,so that NNPACK can not run in the first layer. It's a bug of NNPACK.

What is the use-case for padding greater than kernel_size?

Fully Convolutional Networks ,the first layer padding is 100.  and a lot of padding is bigger than kernel size too.

Why do you need padding > kernel_size? The extra padding results in pixels of output images initialized to constant values, they don't contain any useful signal. Unless I'm missing something, you could re-train your network without such large padding, and get a faster and similarly accurate model.


LogCleaner can not delete old logs

glog version: 0.6.0
My simplified reproduction process is as follows:

Old logs in '/tmp/glogs'：

#ll -rt /tmp/glogs/
total 32776
-rw-r--r-- 1 root root 33554535 Oct  1 00:00 test-cleaner.28f8271ff892.root.log.INFO.20231001-000000.65295

Code that can reproduce the problem (simplified):

#include <string>

#include <glog/logging.h>

static constexpr const char* kLogPrefix = "test-cleaner";
static constexpr const char* kLogDirEnv = "LOG_DIR";
const std::string kLogContent(100, 'a');

int main() {
  // Init logging
  FLAGS_log_dir = std::getenv(kLogDirEnv);
  FLAGS_max_log_size = 32;  // 32 MB

  google::InitGoogleLogging(kLogPrefix);
  google::EnableLogCleaner(3);

  for (int i = 0; i < 1'000; ++i) {
    LOG(INFO) << kLogContent;
  }

  google::DisableLogCleaner();
  google::ShutdownGoogleLogging();
}

Environment variables：LOG_DIR=/tmp/glogs

It is set above to delete files that are more than 3 days old, but they are not deleted.

I've traced the issue and it should be a bug of glog.
I will add the reason analysis later and submit a PR to fix it later.

After further exploring the code, I found that the problem came from the following places:
https://github.com/google/glog/blob/b58718f37cf58fa17f48bf1d576974d133d89839/src/logging.cc#L1430-L1434
When FLAGS_log_dir=/tmp/glogs, the last character in log_directory="/tmp/glogs" is not '/', so the if condition here is not satisfied, and finally filepath will only contain A filename without a "path". In subsequent comparisons, it will be returned directly in the following line.
https://github.com/google/glog/blob/b58718f37cf58fa17f48bf1d576974d133d89839/src/logging.cc#L1470-L1473
In order to solve this problem, we need to modify the if statement above: if the last character of log_directory is not '/', then add one explicitly instead of ignoring it directly.
      if (!log_directory.empty()) {
        if (std::find(possible_dir_delim, dir_delim_end,
              log_directory[log_directory.size() - 1]) == dir_delim_end) {
          filepath = log_directory + '/' + filepath;
        } else {
          filepath = log_directory + filepath;
        }
      }

I will follow https://github.com/google/glog#how-to-contribute and submit a PR as soon as possible.

Update:
With the fix above, my code will work correctly, but the unit test cleanup_with_absolute_prefix will fail with some debug information as follows:
lingbin-debugging[Run:1383]. Into LogCleaner::Run(). base_filename_selected=1, base_filename=test_cleanup_, filename_extension=.barfoo
lingbin-debugging[Run:1389]. dirs=['.']
lingbin-debugging[GetOverdueLogNames:1416]. Into GetOverdueLogNames. days=0, log_directory=., base_filename=test_cleanup_, filename_extension=.barfoo
lingbin-debugging[GetOverdueLogNames:1440]. Checking filepath=test_cleanup_20231010-221021.34375.barfoo, possible_dir_delim=/, log_directory[log_directory.size() - 1]=.
lingbin-debugging[GetOverdueLogNames:1450]. modified filepath=./test_cleanup_20231010-221021.34375.barfoo
lingbin-debugging[IsLogFromCurrentProject:1498]. Into IsLogFromCurrentProject(). filepath=./test_cleanup_20231010-221021.34375.barfoo, base_filename=test_cleanup_, filename_extension=.barfoo
lingbin-debugging[IsLogFromCurrentProject:1527]. cleaned_base_filename=[test_cleanup_]
lingbin-debugging[IsLogFromCurrentProject:1533]. 'filepath' does not contain 'cleaned_base_filename', return
lingbin-debugging[GetOverdueLogNames:1469]. Checking filepath=./test_cleanup_20231010-221021.34375.barfoo, isFromCurrProject=0

What needs to be noted here is that base_filename no longer contains "directory" information, but a value directly specified by the user. (In my reproduction code above, google::SetLogDestination() is not used, base_filename will contain "directory").
In this unit test, the following code is included:
google::SetLogDestination(GLOG_INFO, "test_cleanup_");

https://github.com/google/glog/blob/b58718f37cf58fa17f48bf1d576974d133d89839/src/cleanup_with_absolute_prefix_unittest.cc#L60
After further exploration, I found that there are some difficulties in our current processing of directories, especially the judgment of whether it ends with '/', such as the following code:
https://github.com/google/glog/blob/b58718f37cf58fa17f48bf1d576974d133d89839/src/logging.cc#L1388-L1399
Whether FLAGS_log_dir ends with `'/'' is not handled consistently.

In line L1395, it is expected that dirs contains '/' (because pos+1 is used);
but in line L1397, '.' is used (it is not written as './' , that is, it will not end with '/');
In line L1389, whether the path added to dirs ends with '/' depends entirely on the user's own command line options.

However, regardless of the processing method here, I suggest that we should normalize the input value of FLAGS_log_dir when the user inputs. That is, in GetLoggingDirectories(), first ensure that the directory must end with '/', which can greatly reduce the trivial lines and complexity of subsequent processing.
This is exactly what I modified in the final PR I submitted. The problem I encountered will also be solved, and all existing unit tests will succeed.


docs: Remove duplicate "path includes" in current file How To

Description
There is a duplicate "path includes" in one of the code blocks in "docs/How To/How to get tasks in current file.md".  This PR removes that duplicate.
Motivation and Context
When copying the current task code block, no tasks show up. That is because there is a duplicate "path includes".
How has this been tested?
Copying the code block into my Obsidian vault.
Types of changes
Changes visible to users:

[x] Documentation (prefix: docs - improvements to any documentation content for users)

Checklist

[x] My code follows the code style of this project and passes yarn run lint.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] My change has adequate Unit Test coverage.

Terms

[x] My contribution follow this project's contributing guide
[x] I agree to follow this project's Code of Conduct

Good spot - and thank you very much for fixing it! ❤

The update is now published at:
https://publish.obsidian.md/tasks/How+To/How+to+get+tasks+in+current+file

Thanks!


Implement the 'read-only' mode in batch edit

When an admin doesn't have access to edit a particular event series this should be reflected in the UI by going into read-only mode.

Putting on hold until https://github.com/CUL-DigitalServices/grasshopper-ui/issues/169 is fixed

Removing 'On Hold' label as #169 has been fixed and merged.

Coverage remained the same at 100.0% when pulling 8eb8c6229e5ce9b7c38dd1edf70f81d895ba8895 on Coenego:issue-160-read-only into c2d38b36f8a178ca20147be9d32b72e99a24b948 on CUL-DigitalServices:master.

Assigning to @bp323 for review

Coverage remained the same at 100.0% when pulling 91956e651f01bce5ae0b5a54290c13aaa045a1be on Coenego:issue-160-read-only into c2d38b36f8a178ca20147be9d32b72e99a24b948 on CUL-DigitalServices:master.

Coverage remained the same at 100.0% when pulling fe653b1c90b72b0f13e44e107aae11ad1805cebe on Coenego:issue-160-read-only into c2d38b36f8a178ca20147be9d32b72e99a24b948 on CUL-DigitalServices:master.

Looks good overall. I don't think non-admins are supposed to see unpublished parts in the student UI though. Drafts can stay in for admins in student view.

Back to @Coenego for follow-up

Assigning to @bp323 for review

Coverage remained the same at 100.0% when pulling f1bdda617bb9d32a27ff2fdbf57fb3e91bbd8d87 on Coenego:issue-160-read-only into c2d38b36f8a178ca20147be9d32b72e99a24b948 on CUL-DigitalServices:master.

Functionality looks good, few minor code comments remaining

Follow-up done. Reassigning to @bp323

Coverage remained the same at 100.0% when pulling 7f2832ab9eb3df7a4c5802bf61f100a02c8ae288 on Coenego:issue-160-read-only into c2d38b36f8a178ca20147be9d32b72e99a24b948 on CUL-DigitalServices:master.

Changes Unknown when pulling 92f4622d1e3722dd04f8322c5bdf909279919755 on Coenego:issue-160-read-only into ** on CUL-DigitalServices:master**.

Found one more bug:

When changing the date of an event, applying and opening again, the old date is set in the datepicker.

Back to @Coenego for followup

Verified and merged, nice work!

Changes Unknown when pulling 2ad9c33e81f1a54b890d5bf9bf8720a02d4f0c5e on Coenego:issue-160-read-only into ** on CUL-DigitalServices:master**.


Behaviour of ups_db_count during ongoing transaction

Please consider following sample:

int main()
{
    ups_env_t* env;
    ups_env_create(&env, "test.db", UPS_ENABLE_TRANSACTIONS, 0664, 0);

    ups_parameter_t params[] = {
    {UPS_PARAM_KEY_TYPE, UPS_TYPE_UINT32},
    {0, }
    };

    ups_txn_t* txn;
    ups_txn_begin(&txn, env, 0, 0, 0);

    ups_db_t* db;
    ups_env_create_db(env, &db, 1, 0, &params[0]);

    for (int i = 0; i < 4; i++)
    {
        ups_key_t key = ups_make_key(&i, sizeof(i));
        ups_record_t record = {0};

        ups_db_insert(db, txn, &key, &record, 0);
    }

    uint64_t size;
    ups_db_count(db,0,0,&size);
    std::cout << size << std::endl;

    ups_txn_commit(txn, 0);

    return 0;
}

ups_db_count returns in this case 4 as size of database. As transaction is not commited I would expect that size of the database before commit would be 0.

Agree, that's a bug. You do not specify a transaction and therefore the keys should not be counted. Thanks for reporting. i'll look into it.


How do I change switch-case indentation in C mode?

Now, switch-case block indent as:
switch (selector) {
    case val1:
        /* do smth */
        break;

    default:
        break;
}

case and default keywords must not have offset relative switch, as:
switch (selector) {
case val1:
    /* do smth */
    break;

default:
    break;
}

You need to add this in your config.el (c-set-offset 'case-label '0). Maybe wrap it around a function to hook it only in C mode.

(after! cc-mode
  (c-set-offset 'case-label '0))

Thank you!


Segmentation fault when DataLoader processes are launched after compiling Triton kernels

I am working on a project that involves restructuring a network over different phases of training. Key aspects of this involves calls to custom Triton code, which is compiled and autotuned on the fly as the different phases of training are reached. Occasionally and without clear pattern, this would result in a segmentation fault through a DataLoader when Triton code is compiled, either immediately or when attempting to load the next batch.
I eventually narrowed it down to something very simple. It only seems to depend on compiling Triton code while DataLoaders are used with multiprocessing, and without persistance. Below is code that reproduces the issue consistently. If enable_multiprocessing=True and enable_persistance=False and enable_triton=True, the program crashes when attempting to query the DataLoaders on the second epoch. If enable_multiprocessing=False or enable_persistance=True or enable_triton=False, the program does not crash.
I am surprised this is an issue as it seems like a very common use case. I hope this can be resolved.
import torch
import torch.utils.data
import triton

@triton.jit()
def add_kernel(
    a_pointer,
    b_pointer,
    c_pointer,
    stride_a_batch,
    stride_a_vector,
    stride_b_batch,
    stride_b_vector,
    stride_c_batch,
    stride_c_vector,
    LENGTH_BATCH: triton.language.constexpr,
    LENGTH_VECTOR: triton.language.constexpr,
    BLOCK_SIZE_BATCH: triton.language.constexpr,
    BLOCK_SIZE_VECTOR: triton.language.constexpr,
):
    program_batch = triton.language.program_id(0)
    program_vector = triton.language.program_id(1)

    start_batch = program_batch * BLOCK_SIZE_BATCH
    start_vector = program_vector * BLOCK_SIZE_VECTOR

    offsets_batch = start_batch + triton.language.arange(0, BLOCK_SIZE_BATCH)
    offsets_vector = start_vector + triton.language.arange(0, BLOCK_SIZE_VECTOR)

    mask = (
        offsets_batch[:, None] < LENGTH_BATCH
        and offsets_vector[None, :] < LENGTH_VECTOR
    )

    a_loaded = triton.language.load(
        (
            a_pointer
            + offsets_batch[:, None] * stride_a_batch
            + offsets_vector[None, :] * stride_a_vector
        ),
        mask=mask,
    )
    b_loaded = triton.language.load(
        (
            b_pointer
            + offsets_batch[:, None] * stride_b_batch
            + offsets_vector[None, :] * stride_b_vector
        ),
        mask=mask,
    )

    c_loaded = a_loaded + b_loaded

    triton.language.store(
        (
            c_pointer
            + offsets_batch[:, None] * stride_c_batch
            + offsets_vector[None, :] * stride_c_vector
        ),
        c_loaded,
        mask=mask,
    )

def add(
    a: torch.Tensor,
    b: torch.Tensor,
):
    if not (len(a.shape) == 2 and len(b.shape) == 2):
        raise RuntimeError("add supports only tensors with two axes")
    if not (a.shape == b.shape):
        raise RuntimeError("add supports only tensors with the same shape")
    if not (a.is_cuda and b.is_cuda):
        raise RuntimeError("add supports only tensors on a CUDA device")
    if not (a.device == b.device):
        raise RuntimeError("add supports only tensors on the same CUDA device")
    if not (a.is_contiguous and b.is_contiguous):
        raise RuntimeError("add supports only tensors that are contiguous in memory")
    if not (a.dtype == torch.float32 and b.dtype == torch.float32):
        raise RuntimeError("add supports only tensors that are float32")

    c = torch.empty_like(a)

    LENGTH_BATCH = a.shape[0]
    LENGTH_VECTOR = a.shape[1]

    BLOCK_SIZE_BATCH = 8
    BLOCK_SIZE_VECTOR = 8

    grid = (
        triton.cdiv(LENGTH_BATCH, BLOCK_SIZE_BATCH),
        triton.cdiv(LENGTH_VECTOR, BLOCK_SIZE_VECTOR),
    )

    add_kernel[grid](
        a,
        b,
        c,
        a.stride(0),
        a.stride(1),
        b.stride(0),
        b.stride(1),
        c.stride(0),
        c.stride(1),
        LENGTH_BATCH,
        LENGTH_VECTOR,
        BLOCK_SIZE_BATCH,
        BLOCK_SIZE_VECTOR,
    )

    return c

class DatasetDummy(torch.utils.data.Dataset):
    def __init__(
        self,
    ):
        super().__init__()
        self.dataset_dimensionality = 8192
        self.dataset_size = 128
        self.dataset_generator = torch.Generator()

    def __getitem__(self, index):
        self.dataset_generator.manual_seed(index)

        sample_source = torch.randn(
            (self.dataset_dimensionality,), generator=self.dataset_generator
        )
        sample_target = torch.randn(
            (self.dataset_dimensionality,), generator=self.dataset_generator
        )

        return sample_source, sample_target

    def __len__(self):
        return self.dataset_size

if __name__ == "__main__":
    enable_multiprocessing = True
    enable_persistance = False
    enable_triton = True

    dataset = DatasetDummy()
    loader = torch.utils.data.DataLoader(
        dataset,
        batch_size=16,
        num_workers=1 if enable_multiprocessing else 0,
        persistent_workers=enable_persistance if enable_multiprocessing else None,
    )

    for epoch in range(16):
        print(f"Epoch: {epoch:>3}")
        for batch_index, batch in enumerate(loader):
            print(f"Batch: {batch_index:>3}")
            batch_source, batch_target = batch

            if enable_triton:
                batch_add = add(
                    batch_source.cuda(),
                    batch_target.cuda(),
                )
            else:
                batch_add = batch_source.cuda() + batch_target.cuda()

This gives the following backtrace:
Traceback (most recent call last):
  File "$REDACTED_VIRTUAL_ENVIRONMENT_PATH/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 1133, in _try_get_data
    data = self._data_queue.get(timeout=timeout)
  File "/usr/lib/python3.8/multiprocessing/queues.py", line 107, in get
    if not self._poll(timeout):
  File "/usr/lib/python3.8/multiprocessing/connection.py", line 257, in poll
    return self._poll(timeout)
  File "/usr/lib/python3.8/multiprocessing/connection.py", line 424, in _poll
    r = wait([self], timeout)
  File "/usr/lib/python3.8/multiprocessing/connection.py", line 931, in wait
    ready = selector.select(timeout)
  File "/usr/lib/python3.8/selectors.py", line 415, in select
    fd_event_list = self._selector.poll(timeout)
  File "$REDACTED_VIRTUAL_ENVIRONMENT_PATH/lib/python3.8/site-packages/torch/utils/data/_utils/signal_handling.py", line 66, in handler
    _error_if_any_worker_fails()
RuntimeError: DataLoader worker (pid 74266) is killed by signal: Aborted.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "reproduce.py", line 152, in <module>
    for batch_index, batch in enumerate(loader):
  File "$REDACTED_VIRTUAL_ENVIRONMENT_PATH/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 631, in __next__
    data = self._next_data()
  File "$REDACTED_VIRTUAL_ENVIRONMENT_PATH/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 1329, in _next_data
    idx, data = self._get_data()
  File "$REDACTED_VIRTUAL_ENVIRONMENT_PATH/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 1295, in _get_data
    success, data = self._try_get_data()
  File "$REDACTED_VIRTUAL_ENVIRONMENT_PATH/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 1146, in _try_get_data
    raise RuntimeError(f'DataLoader worker (pid(s) {pids_str}) exited unexpectedly') from e
RuntimeError: DataLoader worker (pid(s) 74266) exited unexpectedly

Below are the specifications of two systems I used to reproduce the issue:
os:           Ubuntu 20.04.6 LTS x86_6
cpu:          AMD Ryzen 9 5950X
gpu:          NVIDIA RTX A5000
cuda driver:  550.54.15
cuda version: 12.4
python:       3.8.10
torch:        2.3.0
triton:       2.3.0

os:           Ubuntu 22.04.4 LTS
cpu:          AMD EPYC 7742
gpu:          NVIDIA A100-SXM4-40GB
cuda driver:  535.161.08
cuda version: 12.2
python:       3.9.15
torch:        2.3.0
triton:       2.3.0

### Tasks

It seems making the data loaders persistant is not sufficient to prevent segmentation faults with more complex setups. I will keep trying to isolate the issue.

The slightly modified code below mimics a typical setup where two DataLoaders are used to cover a training dataset and a testing dataset. Even with enable_persistance=True, the code crashes when the testing DataLoader is reached.
class DatasetDummy(torch.utils.data.Dataset):
    def __init__(
        self,
        dataset_partition,
    ):
        super().__init__()
        self.dataset_dimensionality = 8192
        self.dataset_size = 128
        self.dataset_generator = torch.Generator()
        self.dataset_partition = dataset_partition

    def __getitem__(self, index):
        if self.dataset_partition:
            self.dataset_generator.manual_seed(index)
        else:
            self.dataset_generator.manual_seed(-1 - index)

        sample_source = torch.randn(
            (self.dataset_dimensionality,), generator=self.dataset_generator
        )
        sample_target = torch.randn(
            (self.dataset_dimensionality,), generator=self.dataset_generator
        )

        return sample_source, sample_target

    def __len__(self):
        return self.dataset_size

if __name__ == "__main__":
    enable_multiprocessing = True
    enable_persistance = True
    enable_triton = True

    dataset_train = DatasetDummy(
        True
    )
    dataset_test = DatasetDummy(
        False
    )

    loader_train = torch.utils.data.DataLoader(
        dataset_train,
        batch_size=16,
        num_workers=1 if enable_multiprocessing else 0,
        persistent_workers=enable_persistance if enable_multiprocessing else None,
    )
    loader_test = torch.utils.data.DataLoader(
        dataset_test,
        batch_size=16,
        num_workers=1 if enable_multiprocessing else 0,
        persistent_workers=enable_persistance if enable_multiprocessing else None,
    )

    for epoch in range(16):
        print(f"Epoch: {epoch:>3}")

        print(f"Train...")
        for batch_index, batch in enumerate(loader_train):
            print(f"Batch: {batch_index:>3}")
            batch_source, batch_target = batch

            if enable_triton:
                batch_add = add(
                    batch_source.cuda(),
                    batch_target.cuda(),
                )
            else:
                batch_add = batch_source.cuda() + batch_target.cuda()

        print(f"Test...")
        for batch_index, batch in enumerate(loader_test):
            print(f"Batch: {batch_index:>3}")
            batch_source, batch_target = batch

            if enable_triton:
                batch_add = add(
                    batch_source.cuda(),
                    batch_target.cuda(),
                )
            else:
                batch_add = batch_source.cuda() + batch_target.cuda()

I have yet another version of the code that confirms the issue occurs when DataLoader workers are started after Triton compilation. Setting enable_preload=True and enable_persistance=True launches the workers early and seems to prevent all crashes:
if __name__ == "__main__":
    enable_multiprocessing = True
    enable_persistance = True
    enable_triton = True
    enable_preload = True

    dataset_train = DatasetDummy(
        True
    )
    dataset_test = DatasetDummy(
        False
    )

    loader_train = torch.utils.data.DataLoader(
        dataset_train,
        batch_size=16,
        num_workers=1 if enable_multiprocessing else 0,
        persistent_workers=enable_persistance if enable_multiprocessing else None,
    )
    loader_test = torch.utils.data.DataLoader(
        dataset_test,
        batch_size=16,
        num_workers=1 if enable_multiprocessing else 0,
        persistent_workers=enable_persistance if enable_multiprocessing else None,
    )

    if enable_preload:
        for batch in loader_train:
            break
        for batch in loader_test:
            break

    for epoch in range(16):
        print(f"Epoch: {epoch:>3}")

        print(f"Train...")
        for batch_index, batch in enumerate(loader_train):
            print(f"Batch: {batch_index:>3}")
            batch_source, batch_target = batch

            if enable_triton:
                batch_add = add(
                    batch_source.cuda(),
                    batch_target.cuda(),
                )
            else:
                batch_add = batch_source.cuda() + batch_target.cuda()

        print(f"Test...")
        for batch_index, batch in enumerate(loader_test):
            print(f"Batch: {batch_index:>3}")
            batch_source, batch_target = batch

            if enable_triton:
                batch_add = add(
                    batch_source.cuda(),
                    batch_target.cuda(),
                )
            else:
                batch_add = batch_source.cuda() + batch_target.cuda()

I think I'm running into the same problem. Getting ERROR: Unexpected segmentation fault encountered in worker on multiple workers while training a model that uses Triton kernels. Persistent workers doesn't fix the issue.  Setting num_workers=0 prevents the segfault but training is CPU bottlenecked. Crashes always happen at the end of an epoch (presumably when workers are relaunched), but not always on the first epoch.
I pulled a core dump from one of the segfaulted workers.
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x000071f4d42ab393 in __pthread_kill_internal (signo=11, threadid=<optimized out>) at pthread_kill.c:78
#2  0x000071f4d425a6c8 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
#3  0x000071f4d1562e13 in handler_SIGSEGV(int, siginfo_t*, void*) ()
   from /home/tidal/.local/share/pdm/venvs/mit-ub-7pzcQwz--mit_ub/lib/python3.11/site-packages/torch/lib/libtorch_python.so
#4  <signal handler called>
#5  __pthread_clockjoin_ex (threadid=125287851361984, thread_return=0x0, clockid=0, abstime=0x0, block=true) at pthread_join_common.c:43
#6  0x000071f392131228 in llvm::llvm_thread_join_impl(unsigned long) ()
   from /home/tidal/.local/share/pdm/venvs/mit-ub-7pzcQwz--mit_ub/lib/python3.11/site-packages/triton/_C/libtriton.so
#7  0x000071f3942b0408 in llvm::ThreadPool::~ThreadPool() ()
   from /home/tidal/.local/share/pdm/venvs/mit-ub-7pzcQwz--mit_ub/lib/python3.11/site-packages/triton/_C/libtriton.so
#8  0x000071f392e590b9 in mlir::MLIRContextImpl::~MLIRContextImpl() ()
   from /home/tidal/.local/share/pdm/venvs/mit-ub-7pzcQwz--mit_ub/lib/python3.11/site-packages/triton/_C/libtriton.so
#9  0x000071f392e52d27 in mlir::MLIRContext::~MLIRContext() ()
   from /home/tidal/.local/share/pdm/venvs/mit-ub-7pzcQwz--mit_ub/lib/python3.11/site-packages/triton/_C/libtriton.so
#10 0x000071f390d228da in std::default_delete<mlir::MLIRContext>::operator() (this=<optimized out>, __ptr=0x71ecb11e9db0)
    at /opt/rh/devtoolset-10/root/usr/include/c++/10/bits/unique_ptr.h:79
#11 std::default_delete<mlir::MLIRContext>::operator() (__ptr=0x71ecb11e9db0, this=<optimized out>)
    at /opt/rh/devtoolset-10/root/usr/include/c++/10/bits/unique_ptr.h:79
#12 std::unique_ptr<mlir::MLIRContext, std::default_delete<mlir::MLIRContext> >::~unique_ptr (this=<optimized out>,
    __in_chrg=<optimized out>) at /opt/rh/devtoolset-10/root/usr/include/c++/10/bits/unique_ptr.h:361
#13 pybind11::class_<mlir::MLIRContext>::dealloc (v_h=...) at /root/.triton/pybind11/pybind11-2.11.1/include/pybind11/pybind11.h:1880
#14 0x000071f390cd6840 in pybind11::detail::clear_instance (self=0x71f4134bec30)
    at /root/.triton/pybind11/pybind11-2.11.1/include/pybind11/detail/class.h:424
#15 0x000071f390cd7431 in pybind11::detail::pybind11_object_dealloc (self=0x71f4134bec30)
    at /root/.triton/pybind11/pybind11-2.11.1/include/pybind11/detail/class.h:457
#16 0x000071f4d48a9ea3 in _Py_Dealloc (op=0x71f2d9e006c0) at Objects/object.c:2390
#17 Py_DECREF (op=0x71f2d9e006c0) at ./Include/object.h:538
#18 _PyObject_ClearInstanceAttributes (self=0x71f418cfeb10) at Objects/dictobject.c:5566
#19 subtype_clear (self=0x71f418cfeb10) at Objects/typeobject.c:1279
#20 0x000071f4d481e8b8 in delete_garbage (tstate=0x71f4d5b48c58 <_PyRuntime+166328>, gcstate=0x71f4d5b2eb60 <_PyRuntime+59584>,
    collectable=0x7fff5ac9ea10, old=0x71f4d5b2eba8 <_PyRuntime+59656>) at Modules/gcmodule.c:1013

And version info:
Collecting environment information...
PyTorch version: 2.3.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Artix Linux (x86_64)
GCC version: (GCC) 14.1.1 20240507
Clang version: 17.0.6
CMake version: version 3.29.3
Libc version: glibc-2.39

Python version: 3.11.8 (main, Feb 25 2024, 04:18:18) [Clang 17.0.6 ] (64-bit runtime)
Python platform: Linux-6.8.9-artix1-2-x86_64-with-glibc2.39
Is CUDA available: True
CUDA runtime version: 12.4.131
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA GeForce RTX 3090
GPU 1: NVIDIA GeForce RTX 3090

Nvidia driver version: 550.78
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        43 bits physical, 48 bits virtual
Byte Order:                           Little Endian
CPU(s):                               48
On-line CPU(s) list:                  0-47
Vendor ID:                            AuthenticAMD
Model name:                           AMD Ryzen Threadripper 3960X 24-Core Processor
CPU family:                           23
Model:                                49
Thread(s) per core:                   2
Core(s) per socket:                   24
Socket(s):                            1
Stepping:                             0
Frequency boost:                      enabled
CPU(s) scaling MHz:                   73%
CPU max MHz:                          4568.1641
CPU min MHz:                          2200.0000
BogoMIPS:                             7603.36
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sev sev_es
L1d cache:                            768 KiB (24 instances)
L1i cache:                            768 KiB (24 instances)
L2 cache:                             12 MiB (24 instances)
L3 cache:                             128 MiB (8 instances)
NUMA node(s):                         1
NUMA node0 CPU(s):                    0-47
Vulnerability Gather data sampling:   Not affected
Vulnerability Itlb multihit:          Not affected
Vulnerability L1tf:                   Not affected
Vulnerability Mds:                    Not affected
Vulnerability Meltdown:               Not affected
Vulnerability Mmio stale data:        Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed:               Mitigation; untrained return thunk; SMT enabled with STIBP protection
Vulnerability Spec rstack overflow:   Mitigation; Safe RET
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:             Mitigation; Retpolines; IBPB conditional; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

Versions of relevant libraries:
[pip3] flake8==7.0.0
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.4
[pip3] pytorch-lightning==2.2.4
[pip3] torch==2.3.0
[pip3] torch-dicom==0.1.dev68+g40a15aa
[pip3] torchmetrics==1.4.0
[pip3] torchvision==0.18.0
[pip3] triton==2.3.0
[pip3] triton-helpers==0.1.dev16+g179af43
[conda] Could not collect

I also met this bug, and created a issue on the pytorch side.

Hi, all
I found a workaround method.
I noticed that if the dataloader breaks before it normally ends, the program will not crash.
So I increase the len of the dataloader by one, and break it when it reaches the last iter.
The following dataloader works at least for me.
class DataLoader(torch.utils.data.DataLoader):
    def __len__(self):
        return super().__len__() + 1

    def __iter__(self):
        iter = super().__iter__()
        for idx,data in enumerate(iter):
            if idx >= len(self) -1:
                break
            yield data

@TidalPaladin @leademeule

Some workaround methods that may work:

Decorate at least one forward function with torch.compile of the model before the triton kernel called.
manually break the data loader to avoid the multiprocessing iters reach their ends.

Not sure when and where they work.
@TidalPaladin @leademeule

@flishwang thank you for sharing. On my side I have continued using the persistent data loader trick to avoid the crash. It thankfully has worked consistently over the last few weeks. A proper fix would be much appreciated however.

@flishwang I have adopted the manually break early strategy. Since I'm using PyTorch Lightning I don't have easy access to the data loader directly, but setting limit_train_batches=0.95, limit_val_batches=0.95 in pl.Trainer does the trick.

It seems that this issue is not fully mitigated by the early break workaround. When running for a large number of epochs (200+) the error reappears. This is still much longer than I would be able to run without early breaking. For now I have disabled the Triton components of my model and have had no issues since.

I think this has been resolved with the 3.0 update. I'm no longer seeing segmentation faults

I think this has been resolved with the 3.0 update. I'm no longer seeing segmentation faults

which commit

This hasn't resolved for me even after the triton 3.0 update. Although with Triton 2.3.1, it used to happen every time.
ERROR: Unexpected segmentation fault encountered in worker.
Traceback (most recent call last):
File ".../script_train.py", line 73, in
main_wrapper()
File ".../script_train.py", line 34, in main_wrapper
main(data_dir, exp, method, optim,
File ".../script_train.py", line 69, in main
train(config, dataloader, model, model_path, device)
File ".../train.py", line 113, in train
loss_train.append(loss_train_.item())
File ".../pytorch-2.3.1_cu121_py310_triton/lib/python3.10/site-packages/torch/utils/data/_utils/signal_handling.py", line 66, in handler
_error_if_any_worker_fails()
RuntimeError: DataLoader worker (pid 787) is killed by signal: Segmentation fault.

@flishwang @leademeule the problem still happens. Does anyone know good workaround for PyTorch Lightning?


MySQL migrations cause a bigger diff than expected

Whenever I run database migrations (such as to add a new table as was the case below) I get a diff in schema.rb that shows lines touched that I didn't expect to change. It looks like the diff is mostly the collation property not being dumped, I also see a limit: 1 being removed for boolean columns
   create_table "services", force: :cascade do |t|
     t.integer  "user_id",       limit: 4,                     null: false
-    t.string   "provider",      limit: 255,                   null: false, collation: "utf8_general_ci"
-    t.string   "name",          limit: 255,                   null: false, collation: "utf8_general_ci"
-    t.text     "token",         limit: 65535,                 null: false, collation: "utf8_general_ci"
-    t.text     "secret",        limit: 65535,                              collation: "utf8_general_ci"
-    t.text     "refresh_token", limit: 65535,                              collation: "utf8_general_ci"
+    t.string   "provider",      limit: 255,                   null: false
+    t.string   "name",          limit: 255,                   null: false
+    t.text     "token",         limit: 65535,                 null: false
+    t.text     "secret",        limit: 65535
+    t.text     "refresh_token", limit: 65535

I've got a fairly modern version of MySQL running:
$ mysql --version
mysql  Ver 14.14 Distrib 5.5.43, for debian-linux-gnu (x86_64) using readline 6.3

I suspect that the initializer ar_mysql_column_charset.rb isn't running during the migration so the generated schema.rb doesn't include the complete set of attributes. I don't feel like I have a good grasp of how it's supposed to work because it looks like there's a number of conditions that must be met. Wondering if I'm just missing something in my ENV.

Looks like ActiveSupport.on_load :active_record do in ar_mysql_column_charset.rb is being loaded too late in the life-cycle - that Rails/rake loading of config/initializers happens after ActiveSupport has loaded :disappointed: Not sure what to do about it because I'm hoping this works for other people.

Placing require File.expand_path('../config/initializers/ar_mysql_column_charset', __FILE__) at the top of the Rakefile does resolve the problem. Below is a passing* spec I wrote (needs MySQL to be the backing DB)
require_relative '../../lib/ar_mysql_column_charset'
require 'rails_helper'

describe "monkey patches to ActiveRecord for MySQL charsets" do
  it "does the thing" do
    schema = dump_table_schema('users')
    expect(schema).to include('charset: "utf8mb4"')
    expect(schema).to include('limit: 1')
    expect(schema).to include('collation: "utf8_bin"')
  end

  def dump_table_schema(table, connection = ActiveRecord::Base.connection)
    old_ignore_tables = ActiveRecord::SchemaDumper.ignore_tables
    ActiveRecord::SchemaDumper.ignore_tables = connection.tables - [table]
    stream = StringIO.new
    ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, stream)
    stream.string
  ensure
    ActiveRecord::SchemaDumper.ignore_tables = old_ignore_tables
  end
end

*I'd like to be able to remove the first line and still have the spec pass

I wouldn't worry about the db/schema.rb too much, not sure if I am missing something but we don't use it at all. In all our guides/specs/docker container we use db:migrate and not schema:load. In my experience it is nearly impossible to have the schema.rb consistent for everyone. How the schema.rb looks depends on the database (postgresql or mysql) and even the version.
How I normally handle it is to commit the changes whenever I created a migration and just ignore the changes when I just ran the migrations.

Are those files offering any value then? Should they be removed?

I think the files should be loaded, as far as I know they are supposed make mysql handle utf8 characters properly. @knu should know more about it.
Removing line 3 did not work for me, when I add require File.expand_path('../../lib/ar_mysql_column_charset', __FILE__) after Bundler.require in config/application.rb the callback is properly registered and called.

I think the files should be loaded, as far as I know they are supposed make mysql handle utf8 characters properly. @knu should know more about it.
Removing line 3 did not work for me, when I add require File.expand_path('../../lib/ar_mysql_column_charset', __FILE__) after Bundler.require in config/application.rb the callback is properly registered and called.

Those are indeed for MySQL extended utf8 support.
Should we add schema.rb to .gitignore?

I think excluding it from git makes a lot of sense. Multiple databases with differing schemas, this would convey that we don't expect the schema.rb to be a source of truth.

Submitted pull request (sorry for the commit spam) to remove schema.rb from git

I guess removing the schema.rb would not hurt.
@TildeWill does the issue that the patches for MySQL are not loaded still exist?

shrug I guess the issue still exists. But I'm not sure it ever worked in the first place because so far I'm hearing that schema.rb doesn't matter. I don't know what test to write to know it's loaded correctly. Maybe in older versions of Rails the load order was different enough? I guess I'd need @knu to do a brain dump about the expectations of that code.

I believe it's for https://github.com/cantino/huginn/blob/master/db/migrate/20140813110107_set_charset_for_mysql.rb

Let's talk about what is supposed to happen here. In my reading through the wiki/issues/code history on Github, here's what I've garnered:

Multiple databases are supported, namely MySQL and Postgres
MySQL's utf8 encoding is not sufficient for supporting emoji which is important for things like Twitter integration
In order to coax MySQL into a happy emoji state, additional charset and collation attributes need to be set on a specific set of text and string fields, but probably isn't needed for all text and string fields. This was handled in the migration<PHONE_NUMBER>0107_set_charset_for_mysql.rb which needs the extension to ActiveRecord in order to set the charset and collation.
schema.rb is not used by the app nor the setup instructions. Therefore it can be removed from the project since Postgres and MySQL will always generate different output when dumping the schema.

Does this sound right? Anything I've missed or got wrong?

@knu, would you mind checking if our understanding is correct?

I don't think the diff is due to the callbacks not getting loaded.  I guess it is an accumulated set of changes by various contributors and committers.  I've always seen differences like you but just decided to pick relevant hunks when I commit, and ignored those differences.

And yes, I think every point @TildeWill made is correct.

I think this is closable now that we merged in the schema.rb removal, right @TildeWill?

Correct, close away.
On Tue, Jan 12, 2016, 13:53 Andrew Cantino<EMAIL_ADDRESS>wrote:

I think this is closable now that we merged in the schema.rb removal,
right @TildeWill https://github.com/TildeWill?
—
Reply to this email directly or view it on GitHub
https://github.com/cantino/huginn/issues/1195#issuecomment-171070045.

Thanks Will!


Pagination issues while migration to devon4j

Below are the issues detect while migration to devon4j

First the filters pagination doesn't refresh to the first page.
When try to filter on waiter orders or reservations tabs by attribute that doesn't exist, it doesn't refresh the data table, it should show the next text: No results to display. It worked in the past and showed the text in the language selected.
When try to filter on Menu by attribute that doesn't exist, the web is showing every time the green bar as if we need to wait until the components are load. It worked in the past and when the search returned blank list the green bar stopped and the web didn't show nothing.

Solved in PR #143


Add Github-style word-level diff highlighting

from https://drupal.org/node/1991148
Identifying partial line code changes in traditional diffs can be tedious and error-prone. A fix for a typo in code docs or a variable name in a long expression may require reviewers to carefully read an entire line to make sure they haven't overlooked differences. To help with this, some diff tools offer word-level highlighting. git-diff has the --word-diff option[1], for example, and Github has a very nice dual-highlighting implementation[2]. Similar functionality in Dreditor would be super helpful.
[1]
[2]

Dreditor is being decommissioned due to the lack of availability of current maintainers and the fact that Drupal.org is becoming more feature rich at a much faster rate than Dreditor itself now.
This decision was also partially made due to the amount of work (complete rewrite) it would take to create an "official" Firefox extension (#256).
If you already have the extension installed, it should continue working for a while until, inevitably,  the markup on Drupal.org changes. It will no longer be updated.
We understand that many of you love this extension, as do we. This isn't the end, in fact, it's a much brighter beginning. All the things we love about Dreditor can, and should, be moved into Drupal.org natively.
For more information, please follow: https://www.drupal.org/node/2779729

This issue was moved to dreditor/dreditor#44


fix numpy version

For some reason numpy version for numba installation is not fixated for >=1.22. Thus, you can install Numba==0.58 and numpy<1.22. Which after import numba results in exception https://github.com/numba/numba/blob/main/numba/init.py#L37
installation
pip install numba "numpy<1.22"

exception
import numba

@Tialo thank you for reporting this. It seems like there are some inconsistencies here. The version support table for 0.58 actually lists 1.21 as being the minimum supported version:
https://numba.readthedocs.io/en/0.58.0/user/installing.html#version-support-information

I will investigate this some, thank you for the report.

Checking the conda recipe, it looks good:
https://github.com/numba/numba/blob/main/buildscripts/condarecipe.local/meta.yaml#L44
https://github.com/numba/numba/blob/release0.58/buildscripts/condarecipe.local/meta.yaml#L43

@Tialo thank you for reporting this. It seems like there are some inconsistencies here. The version support table for 0.58 actually lists 1.21 as being the minimum supported version:
https://numba.readthedocs.io/en/0.58.0/user/installing.html#version-support-information

I will investigate this some, thank you for the report.

Presumably this PR should also update this table then?

I can do this, if necessary.

I can do this, if necessary.

Yes, that would be good, thank you!

As you can see in my commit there was no release date in this table on master branch I added it.

As you can see in my commit there was no release date in this table on master branch I added it.

@Tialo yes, I think this PR will need a rebase once https://github.com/numba/numba/pull/9205/files is in main.

Okay, will do it

@Tialo excellent, thank you! I am hoping that #9205 will be merged soon, our CI system is currently being used for something else, so merges are on hold for the time being. I expect this to resolve within the next week or maybe two. As soon as that happens you can rebase this PR and the change of the release date should no longer be necessary on this PR.

@Tialo ok, the merge happened last night, can you now please rebase this, thank you!

Here you go @esc

Here you go @esc

awesome, thank you!

This was cherry-picked into #9227 🍒 --so closing this one now.

Am I right, this PR will take effect in numba 0.58.1? @esc

Am I right, this PR will take effect in numba 0.58.1? @esc

Yes, I am planning to get that released, the checklist should appear soon. The closed issues in the milestone are the PRs that will need a backport to release058 branch. We usually create a PR targeting the release branch and cherry-pick the needed PRs one at a time from their merge-commit to main.
https://github.com/numba/numba/milestone/76?closed=1


Associate form help text with form

This is an alternative solution to #484.
What problem does the pull request solve?
Most groups of checkboxes and radio buttons within Elements have an additional introductory help text which isn't a hint. It's usually there to help less technical people understand that you can select multiple checkboxes, but can also be used for other purposes.
This associates that text with the form via aria-describedby to make it more accessible to assistive technologies like screen readers. Ideally this should be put into the legend instead, but that proves to be difficult (see #484).
How has this been tested?
I tested in the most used screen reader and browser combination: VoiceOver in Safari on macOS, JAWS in IE 11 on Windows 10 and NVDA in Firefox on Windows 10. They don't necessarily say the help text under all circumstances but always under some circumstances (e.g. when down-arrowing vs tabbing).
What type of change is it?

Bug fix (non-breaking change which fixes an issue)

Has the documentation been updated?
I'm not quite sure if this needs to be documented or not. We don't officially have the concept of a "form help text". (That's the name I gave it, that might need improving.) But I am aware of forms in the wild which use something similar. Where would a documentation fit? Maybe under "hint text" as that is related.

@selfthinker which of these solutions, #484 or #485 is your preferred choice?

We have a section on fieldsets and legends.
http://govuk-elements.herokuapp.com/form-elements/#form-fieldsets
The guidance for moving this help text into the legend, or using aria-describedby to associate the two can go there.

I'd prefer solution #484. As Richard Morton keeps on saying: "The first rule of ARIA is: Don't use ARIA."
#484 solves it without the help of ARIA and without the need for developers to take care of adding additional things that can go wrong (id and referencing it correctly to aria-describedby).
Let me know if the "hack" in #484 is okay with you, then I can add the documentation to it. Otherwise I will add it in here instead.

Let's go with #484. Fine to include the "hack" since it'll make the spacing underneath hint text consistent. Thanks Anika.

Closing in favour of #484.


♻ No testFail

Description
@gakonst
@transmissions11
Checklist
Ensure you completed all of the steps below before submitting your pull request:

[x] Ran forge fmt?
[x] Ran forge snapshot?
[x] Ran forge test?

Pull requests with an incomplete checklist will be thrown out.

Sick thx


Use separate formats for separate locales.

Fixes #842

Coverage remained the same at 83.907% when pulling e19f14b9c7989f53e35a30141a1f07fd2e02276c on DouglasMeyer:fix_842_distinct_formats into 5df1c3d11b5aa022137eaacb37f0c9e35eb7354d on chmln:master.


RFC: URLs in links

https://github.com/json-api/json-api/issues/840#issuecomment-141631828
https://github.com/json-api/json-api/pull/834#issuecomment-131192713
https://github.com/json-api/json-api/pull/834#issuecomment-141631788

relative references are simply not allowed.

So, links should be "links": { "self": "http://example.com/link_author/1"} not {"links": { "self": "//link_author/1"}
How about a link such as "links": { "self": "//link_author/1"} discussed in ActiveModel::Serializers

cc @beauby

This already has a meaning in URLs: it's a "network relative" URL, though it's often called "protocol relative." So this isn't going to work, directly.

When we take a look at other specs:

JSON-LD defines @base annotation to support relative IRI-s (http://www.w3.org/TR/json-ld/#base-iri)
HAL, Collections+JSON uses URI term, which can be relative

JSON API uses URL (as @steveklabnik said), so just use the full version.

Wait wait wait, I think there has been a huge misunderstanding here. I forgot to put the domain in //example.com/link_author/1 in a test for a PR supporting resource-level links in AMS, which resulted in a debate which I believed was about whether protocol-relative URIs were allowed in the spec (which to my knowledge are at least not explicitly forbidden).

Oh, ok.
Personally, I don't use this feature and dislike, especially when JSON API is not used to provide static content ;).
I don't imagine a situation when a resource that is accessible using HTTPS should be accessible using HTTP.

As far as I can tell, json-schema uri requires the uri format to be a URI RFC3986 and a valid JSON Reference json‑reference, so relative and absolute are both allowed by the schema, but the JSON API spec recommends using absolute, but does not forbid relative?

So, I've been thinking about this today and I see a few options:

Interpret JSON API 1.0 as having allowed relative references but not having provided a mechanism for setting the base URI in a JSON API document, in which case, per RFC 3986, the base URI for all links in the document would be URI at which it was requested.

Interpret JSON API 1.0 as having had undefined behavior wrt relative references, such that we can define whatever behavior we want now, without it being a b/c break. This would give us an opportunity to define a mechanism for declaring the base URI within a JSON API document itself. Such a mechanism would probably work like either xml:base or HTML's <base>—the primary difference between those two being whether there can be different base URIs specified at different nesting levels. (I played with approaches that used "self" to inform the base URI but all of them ended up unnecessarily convoluted.)

Interpret JSON API 1.0 as having forbidden relative references.

I'm pretty sure that we'd prefer 1 over 3, so 3 can be ruled out. Between options 1 and 2, I'm not sure. Option 1 is definitely simpler for clients, so I'm leaning toward it, but I guess the question would be: is there any compelling reason to have the facility described in option 2?

@ethanresnick So, the difference between 1 and 2 is whether JSON API considers relative references allowed but not recommended vs. undefined?
My understanding of how json schema works is that they are in the allowed camp, since JSON API hasn't taken an opinion on it one way or the other, it defaults to the json-schema definition.

So, the difference between 1 and 2 is whether JSON API considers relative references allowed but not recommended vs. undefined?

Correct. If we interpret the spec per option 1 (i.e. allowed but not recommended), then we're done with this issue. If we interpret it as having undefined behavior, then we have the opportunity to do anything we want, i.e. go with options 1 or 3, or go with a variant of option 1 in which we allow relative references but say more explicitly how base URIs should be determined.
The biggest takeaway for users, I guess, is that, as long as we don't do option 3 (which seems unlikely), relative references will eventually be supported in the spec in a consistent way. And, if you rely on the base URI being the URI at which the document was requested, that's probably safe.

I can't really help deciding which option is the best (however I prefer the first one), but I would propose excluding option 3 :) as Roy Fielding also stated in his presentation (http://roy.gbiv.com/talks/201511_Fielding_REST_CF.pdf) on page 37 that relative URL-s are preferred for RESTful applications. I hope that you find the information helpful. :)

@dgeb @tkellen @steveklabnik Can you guys weigh in here? Particularly on these options. I'd love to put this issue to bed!

This would give us an opportunity to define a mechanism for declaring the base URI within a JSON API document itself. Such a mechanism would probably work like either xml:base or HTML's <base>—the primary difference between those two being whether there can be different base URIs specified at different nesting levels.

If relative URLs are going to be allowed, then let's at least maximize their value by making it possible to set the base URL independently for each resource object context. Otherwise there's little point in supporting relative URLs over just using CURIEs, which are also easier to deal with (no trailing slash issue).

I played with approaches that used "self" to inform the base URI but all of them ended up unnecessarily convoluted.

How's this? In most cases I would expect the base of an object to be equal to its self, making self at least a useful fallback in case base isn't defined.
Some things to consider:

Where to allow base? (The root level and the resource object level are likely enough.)
Would dot segments be allowed? (Not in favor, but OK as long as the server then agrees to accept dot segments in request URLs as well. In other words, a client shouldn't have to normalize them.)
Should a resource object's base URL be resolved relative to the document's base URL? (I guess so, as that seems to account much of the benefit of relative URLs.)
Should at least one of self and base be mandatory if relative URLs are present, or is the request URL the final fallback?

Example:
{
  "links": {
    "self": "http://example.com/articles/"
  },
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON API paints my bikeshed!"
    },
    "links": {
      // The document doesn't define a `base` link, so these
      // would be resolved relative to the document's `self` instead.
      "self": "1"
      "base": "1/"
    },
    "relationships": {
      "author": {
        "links": {
          "self": "relationships/author",
          "related": "author"
        }
      }
    }
  }]
}

@steveklabnik you wrote:

This already has a meaning in URLs: it's a "network relative" URL, though it's often called "protocol relative." So this isn't going to work, directly.

So, are you saying network relative URLs are legit urls to use in JSON API, and only relative one's are up for discussion? i.e.
OK:

http://example.com/format.js
https://example.com/format.js
//example.com/format.js

NOT RECOMMENDED / UNDEFINED:

/format.js

Refs: As far as I can tell, json-schema uri requires the uri format to be a URI RFC3986 and a valid JSON Reference json‑reference.

cc @dgeb @ethanresnick @tkellen @steveklabnik I was just asked about this again today :(

per https://github.com/json-api/json-api/pull/551#issuecomment-92870252

JSON-API makes no assertions about URI structure

and http://jsonapi.org/recommendations/#including-links uses relative links

Following RFC 3986 which is referenced by JSON Schema that a "partial URI" or "relative URI" are not a subset of an URIs but a method of referencing URIs:

1.2.3.  Hierarchical Identifiers
[...]
NOTE: Previous specifications used the terms "partial URI" and "relative URI" to denote a relative reference to a URI.  As some readers misunderstood those terms to mean that relative URIs are a subset of URIs rather than a method of referencing URIs, this specification simply refers to them as relative references.

JSON Schema for JSON API provided in FAQ requires uri and not uri-reference. So a uri reference like a notwork or domain relative URI would fail validation.

Can anyone definitively enlighten me as to whether the current specification actually allows (root) relative links or not? There seems some controversy on this page and if possible I'd like to use them on the basis it can save a fair amount of verbosity in the API responses

@mark-a-roberts per https://github.com/json-api/json-api/issues/898#issuecomment-232991825 it looks  I'd say you're safe to use relative links

@bf4 agreed.
As @jelhan pointed out in https://github.com/json-api/json-api/issues/898#issuecomment-302676438 we should adjust the schema to specify uri-reference.
Once we do that, and perhaps add a FAQ, we should probably close this issue out.

@dgeb I opened a PR fixing schema: #1169

@jelhan thanks - merged! :shipit:
I believe that all that remains is a FAQ to further clarify this.

This has been clarified in v1.1:

Within this object, a link MUST be represented as either:

a string whose value is a URI-reference [RFC3986 Section 4.1] pointing to the link’s target.

And per RFC 3986 linked there:

A URI-reference is either a URI or a relative reference.  If the  URI-reference's prefix does not match the syntax of a scheme followed by its colon separator, then the URI-reference is a relative   reference.
(...)
A relative reference that begins with two slash characters is termed   a network-path reference; such references are rarely used.  A   relative reference that begins with a single slash character is   termed an absolute-path reference.  A relative reference that does  not begin with a slash character is termed a relative-path reference

Personally I don't see a need for a FAQ entry and wouldn't be sure what to add in there. Closing without further action would be fine in my perspective.


Herd customers onto updated RDS instances

In order to help customers meet their own compliance needs, customers need to understand when and how they should be updating their DB instances.
Acceptance Criteria

[ ]

Implementation sketch

[ ]

Closing - covered by #918


Please add our CVPR2023 paper about depth estimation

Hi, could you add our paper about self-supervised depth estimation?
Title: Lite-Mono: A Lightweight CNN and Transformer Architecture for Self-Supervised Monocular Depth Estimation
Link: https://arxiv.org/abs/2211.13202
Code: https://github.com/noahzn/Lite-Mono
Thanks.

Received,thanks


Fix download state not being reactive in offline mode.

Summary

Fixes #127
The VideoDownloader instances take a little time to initialize, i.e. to fetch download status from IDB. After a hard refresh, the downloader instance usually still was in an indeterminate state, which the application incorrectly interpreted as the video not being downloaded locally.
I have updated the downloaded implementation to broadcast state changes and then hooked the single video page to listen to those changes. Once the downloader is initialized, the disabled class is removed from the wrapping article element in cases when the video is available, i. e. when it's available for offline playback.
Screencast to illustrate the fix
https://user-images.githubusercontent.com/433570/136229761-6ebb1d7f-d17c-477c-af01-07051bab64eb.mp4

Tested against https://kinoweb-dev--staging-2ra3ji0i.web.app/

Opened https://kinoweb-dev--staging-2ra3ji0i.web.app/
Clicked on a video
Clicked on "Make available offline"
Clicked on Settings
Toggled on "Show offline content only"
Clicked on Kino icon
Clicked on the video that is available offline
Clicked on "Remove offline version"
Clicked on "Undo" - download worked
Clicked on "Make available offline" - download worked
Clicked on "Remove offline version"
Waited a few seconds - video was removed from the offline list, buttons were disabled and image background turned to gray ✔

https://user-images.githubusercontent.com/96055551/150086240-3ac63c4c-6420-4ca4-aa80-1449f41fa771.mp4


oc_chef_wm_server_api_version dialyzer

Mixer wasn't treating this right, and @sdelano was like, "just pull mixer out" so I did.

Weird, but sure
:+1:


Add "Blazor 20 Questions" to Sample Projects section

Client/Server game using Websockets (SignalR), with a MongoDB API, and Docker deployment (docker-compose).

Sorry for the delay I was off.
Thank you for the submission.


api-changelog: Update and clarify docs for feature level 176 entry.

Part of 7.0 API changelog audit; see this CZO conversation for more context.
Updates API changelog entry and related parts of API docs for: Feature level 176.
Notes:

Revises API changelog entry for missing endpoint method and to clarify the overall text.
Generally, updates Changes notes for feature level 176 to not have repetitive text, so that the descriptions were clearer and more concise.
Fixes an alignment issue in the client_capabilities parameter description in the POST /register doc.
The original commit with the changes related to this API changelog entry is commit 268f858f39bcd0.

Screenshots and screen captures:

API changelog: Updated feature level 176 entry
Current documentation

Add a linkifier: `url_template` parameter
Current documentation
Same for Update a linkifier url_template parameter.

Events: realm_linkifiers
Current documentation

Events: realm_filters ~ deprecated
Current documentation

Register queue: search for "realm_linkifiers: (object)"
Current documentation

Register queue: `client_capabilities` parameter
Current documentation

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Update:

Added a 2nd commit that expands the prose description of the deprecated realm_filters events and register response field to include examples of the pattern and URL string format.

This is great, merged, thanks @laurynmm!


Need to change to jupyter notebook format to the python mode

I guess for your github action to work you guys need to change your file from jupyter notebook to the pure python file.

no


support for "keyboardShouldPersistTaps" as ScrollView does

When keyboard is open, touchables doesn't work on single tap. On first tap, keyboard gets closed, and then touchables work. Touchables should also work when keyboard is open.

@shikherprasad why did you close this? Setting keyboardShouldPersistTaps='always' does not seem to work for me 😕

The Link to the comment helped. For me, it was a Flatlist inside the KeyboardAwareScrollView, I set the keyboardShouldPersistTaps on the flatlist too, and it worked.