node-sass + libsass source coupling

For better packaging I would like to have a complete source of the project in a single zip file.
Normally this is not a problem in Github, since I can simply pulls the zip file of every commit:
(e.g. https://github.com/sass/node-sass/archive/v2.0.1.zip)
Due to our use of submodules, however, the zipfile does not include a proper version of libsass as well as test specs are missing (I normally do not need them).
There are few possible solutions:

include libsass in our git and have one .zip file including libsass and our node bindings.

download two zipfiles separately, e.g. https://github.com/sass/node-sass/archive/v2.0.1.zip and https://github.com/sass/libsass/archive/3.1.0.zip

teach node-sass to use an out-of-tree libsass (use extracted sources or use a library)

My preferred solution would be 3, is that feasible?

Thanks for your proposal.
This is similar to https://github.com/sass/node-sass/issues/389, which is actively under consideration at https://github.com/sass/node-sass/issues/712 and ultimately tackled by https://github.com/sass/node-sass/pull/743. Lets discuss it at #712.
The idea really is to make user point to any libsass commit and recompile the binary. The steps which our script might follow would be:
# in node-sass root directory
#
# when user will run `node scripts/update`
#
# read the value of npmSassConfig.libsass
# from package.json, which is the SHA1 commit hash
# to libsass. Then:
git clone https://github.com/sass/libsass
git reset --hard my_favourite_SHA1_commit_hash
npm update    # installs missing dev dependencies
node scripts/build -f

I think people can do all that today manually. This little automation will not bringing an extraordinary advantage anyway..

Due to our use of submodules, however, the zipfile does not include a proper version of  libsass

What do you mean, can you expand on it? The packaged libsass code is always pointing to the version of libsass we are releasing node-sass against.

as well as test specs are missing

Yes and new we have removed the entire test directory from the production package for vNext. User can always use git to pull it. The idea really is to keep the package size as slim as possible.
Now that you have mentioned, I will remove libsass from package as well. :wink:

I read #712 and #743 and came to the conclusion they are about binary package downloads, i.e. package with an already compiled binding file.
What most packagers need is just a version number and a source file corresponding to this version.
During an automated build it is much simpler to get a .zip file than play with git. I have an automated build that installs clean-room operating system, nodejs/iojs, npm and all dependencies - it fetches
source zipfiles, produces binary packages and installs them as necessary. This is all automated. I do not fetch python, node and other dependencies from git - the build system compiles them once into the binary package and unless something changes I am using those packages for testing. Each packages has a version number, not Git hash.
Besides, users of the package want to know that they have 2.0.1 and they can upgrade to, say, 2.0.2 and not use git hashes only. (Again, this is not a binary executable as in http://github.com/sass/node-sass-binaries but a complete binary package which can be installed with tar, without even calling npm).
This is similar to #389 problem, but instead of checking some code into src/libsass using git it might be better to point to existing libsass sources or even compiled binary. If we don't want to link shared libsass library, we can always use shared one (libsass.a).

What most packagers need is just a version number and a source file corresponding to this version.

Today with v2.0.1, if you try require('node-sass').info(), you get node-sass and the corresponding libsass versions. Also you can require('path/to/node-sass/package.json').libsass to get only libsass version. See package.json#L4.

But this works only after the the module has been built...
> require('node-sass').info()
Error: `libsass` bindings not found. Try reinstalling `node-sass`?
    at getBinding (/home/saper/sw/test2/node_modules/node-sass/lib/index.js:22:11)
    at Object.<anonymous> (/home/saper/sw/test2/node_modules/node-sass/lib/index.js:188:23)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at repl:1:1
    at REPLServer.defaultEval (repl.js:132:27)

I'll try two-zip approach and will see where I can arrive at.

You can also try require('./package.json').libsass.

Walking into this error, brought me here. How do we fix this today, and avoid this in the future?
Error: `libsass` bindings not found. Try reinstalling `node-sass`?

@kevinSuttle, sorry to tell you this but you landed on an unrelated issue. You can search the issue tracker and find the reasons of that exception.

Closing it as a direct duplicate of https://github.com/sass/node-sass/issues/389.
@saper, lets continue this discussion there.


'TorchAMPOptimizer' object has no attribute 'state'

🐛 Describe the bug
when i was training a resnet with colossalai , i import torch.optim.sgd as my optimizer ,but when i use booster .boost to wrap the optimizer ,and i run the code :  ‘’optimizer.state.pop(optimizer.param_groups[-1]['params'][0], None)‘’，the program reports a bug 'AttributeError: TorchAMPOptimizer' object has no attribute 'state',
but before i use the booster.boost  ,the code is running correctly.

Environment
i was using pytorch==1.12.1 +cu116  torchvision==0.13.1+cu116 torchaudio==0.12.1+cu116
nvidia RTX2080 *4     cuda 11.6

将optimizer.state.pop 改成  optimizer.optim.optim.state.pop


Bridge request for wertpapier-forum.de

I would like to request a bridge for https://www.wertpapier-forum.de/.
This excellent forum does offer private RSS feeds (they look like this https://www.wertpapier-forum.de/discover/1.xml/?member=40858&key=342b066f30adb66ec0b1949332fd9d51) for logged in users but not for the public.
Is there any way to create a RSS bridge for all new posts?
For logged in users it looks like this and can be accessed via https://www.wertpapier-forum.de/discover/unread/

Can be closed. The RSS feed turned public.


Week 3 Oct - 9 Oct

So the problem we discussed today was when TreeContentProvider.resolveChildren(node: ITreeNode) is called, how does the extension identify node from within the tree? We discussed the following members on ITreeNodeoptions:

id: number: This would not be the best since id is just some arbitrary unique number from the extension's point of view.
equals(other: ITreeNode): boolean: This would not solve the issue as the extension does not have a reference to the node as the return value from TreeContentProvider.provideTreeContent is used to construct another object.
data: any: Allowing each tree node to keep some data object would solve the issue, it would also open a lot of doors some of which we may not want to open as well as require the extension author to fill it in to be able to unique ID the nodes. Let's reconsider this when there is a solid use case.
parent: ITreeNode: This enables the extension to precisely identify the node within a tree, even down to the index of the child by calling into ITreeNode.parent.children.indexOf if needed. Let's add this to the API.

Tasks for this week:

[ ] Add ITreeNode.uri (let's get it functional first!)
[ ] Create and persist the tree on the extension host side then synchronize it with a copy on the main thread. The tree on the extension host side will always be kept up to date so it can provide each node's parent (ITreeNode.parent) in real time.
[ ] Add ITreeNode.parent
[ ] Add some tests
[ ] Discuss approach with wider team
[ ] PR to Microsoft/vscode
[ ] Add ITreeNode.iconUri

[ ] Remove isChildrenResolved

Here's a concrete example of why we need ITreeNode.parent in order to identify the node within the tree. Say you implement an outline view for C#, the structure of the file looks like this:

class A

class B

class A

How do you distinguish either class A when resolveChildren(ITreeNode) is called?

As per today's discussion:
Actionable items:

[ ] rename isExpanded to something like shouldInitiallyExpand to avoid confusion
[ ] As provideTreeContent only provides root of tree, should be named like provideTreeRoot
[ ] remove children from TreeContentNode's interface. Instead make it provided by resolveChildren
[ ] Make Provider generic
[ ] and functions like getLabel(node: T) to TreeContentNode's interface.

Thoughts on onclick Uri:

Uri doesn't prevent user from doing whatever he wants if he can make a custom ContentProvider that registers for a special scheme.
User might want to fire custom action (like executing a CLI command) when node get clicked
User might not want to open any editor/webpage when node get clicked
Need to worry conflict of schemes
What if later we want to support right-click, double click, Enter key, etc?

As for the reusability argument

If I'm writing an ext I wouldn't trust other providers
Creates dependency. For example, what if A depends on B's provider which uses libgit 2.0, but B upgrades to libgit 3.0?

So overall I'm not really for it, unless there are benefits that largely overweights these downsides.

A similar API is CodeLens:
declare namespace vscode {
  registerCodeLensProvider(selector: DocumentSelector, provider: CodeLensProvider): Disposable;
  registerCommand(command: string, callback: (args: any[]) => any, thisArg?: any): Disposable;
  export class CodeLens {
    range: Range;
    command: Command;
    isResolved: boolean;
  }
  export interface Command {
    title: string;
    command: string;
    arguments?: any[];
  }
}

Users could register a command that does whatever he wants when a CodeLens is clicked.
An example, vscode-gitlens

Can we do something similar by adding a string leftClickCommand to TreeNode interface?

A command: Command property is on CodeLens, CompletionItem and StatusBarItem.
export interface Command {
  title: string;
  command: string;
  arguments?: any[];
}

which is fired after clicking CodeLens or StatusBarItem, or confirming a CompletionItem.
User can register command in this form
registerCommand(command: string, callback: (args: any[]) => any, thisArg?: any): Disposable;

I think we should follow this convention.

[ ] Update doc for TreeContentNode
[ ] Flexbility example for  TreeContentNode onClickCommand.


Question regarding public and private keys

Why does this app request the private key to login, yet other Android apps for Nostr like Amethyst only require the public key to login?

"Should I enter my private key in the client?
Generally, it’s better not to enter your private key into any client. Most clients that ask for private keys do their absolute best to keep your key secure but given the nature of software, there are always breaches, exploits, and bugs that could potentially expose your private key.
Remember, your private key is your identity in Nostr, so if it is compromised, you’ll have to start from scratch rebuilding your identity, and you’ll lose your list of followers and all your private messages."
source:  https://nostr.how/en/clients

We are fully aware of this feature and we plan to add login with public key in the future.


UEFI fixes and comments addressed

Description

This is an attempt to address vmware issues with  #3638, to prevent having to revert the entire PR. see #3978 for the issue.

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):
How Has This Been Tested?

@blueorangutan package

@DaanHoogland a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✖centos6 ✔centos7 ✔debian. JID-1078

@blueorangutan package

@DaanHoogland a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✖centos6 ✔centos7 ✔debian. JID-1079

@blueorangutan help

@DaanHoogland I understand these words: "help", "hello", "thanks", "package", "test"
Test command usage: test [mgmt os] [hypervisor] [additional tests]
Mgmt OS options: ['centos6', 'centos7', 'ubuntu']
Hypervisor options: ['kvm-centos6', 'kvm-centos7', 'kvm-ubuntu', 'xenserver-71', 'xenserver-65sp1', 'xenserver-62sp1', 'vmware-67u3', 'vmware-65u2', 'vmware-60u2', 'vmware-55u3', 'vmware-51u1', 'vmware-50u1']
Additional tests: list of space separated tests with paths relative to the test/integration directory, for example: component/test_acl_listvm.py component/test_volumes.py
Note: when additional tests are passed, you need to specify mgmt server os and hypervisor or use the matrix command.
Blessed contributors for kicking Trillian test jobs: ['rhtyd', 'nvazquez', 'PaulAngus', 'borisstoyanov', 'DaanHoogland', 'shwstppr', 'andrijapanicsb', 'Spaceman1984', 'Pearl1594', 'davidjumani', 'harikrishna-patnala']

@blueorangutan test centos7 vmware-67u3

@DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

@blueorangutan test centos7 vmware-67u3

@DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

@pavanaravapalli I saw #3985. happy to go with that, but please consider the changes here as well as they address some of the comments made. Let me know and I'll close this.

Trillian test result (tid-1290)
Environment: vmware-67u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 31687 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr3983-t1290-vmware-67u3.zip
Intermittent failure detected: /marvin/tests/smoke/test_kubernetes_supported_versions.py
Smoke tests completed. 82 look OK, 1 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_add_delete_kubernetes_supported_version
Error
0.18
test_kubernetes_supported_versions.py

similar code merged in #3985,
remaining will be added to #4021


Minimize and stabilize the inference dependencies

It would be great to minimize the dependencies that need to be installed for the inference demo.
We need a lot more things for training but the inference code should be pretty self-contained (we should be able to drop WhisperX, Whisper, even the SpeechBrain model by default). This would speed up the Collab demo a lot.
It would be good to also freeze the versions so we avoid surprise warnings like these: https://github.com/collabora/WhisperSpeech/discussions/35

This is done.


Reorganize code and complete test coverage

Codecov Report

Merging #11 (65d916c) into main (d298e83) will decrease coverage by 4.8%.
The diff coverage is 95.6%.

@@           Coverage Diff           @@
##            main     #11     +/-   ##
=======================================
- Coverage   97.8%   93.0%   -4.9%
=======================================
  Files          4       6      +2
  Lines         92     100      +8
=======================================
+ Hits          90      93      +3
- Misses         2       7      +5

Impacted Files
Coverage Δ

quickhttp/_version.py
80.0% <80.0%> (ø)

quickhttp/__init__.py
100.0% <100.0%> (ø)

quickhttp/__main__.py
100.0% <100.0%> (ø)

quickhttp/cli.py
100.0% <100.0%> (ø)

quickhttp/exceptions.py
100.0% <100.0%> (ø)

quickhttp/http_server.py
90.6% <100.0%> (ø)


temp files have not be deleted

I have found the temp files of reading xlsx files, the created temp- files have not been deleted at all. They are all kept in your temp folder inside your PC.
I think it's really a serious problem!!!!!!!!

You closed the issue, did you not think it was a bug anymore? This library should clean up after itself as long as it runs to completion. If you abort execution early with a kill command then that isn't guaranteed, but in any other case it should remove the temp file when you close the reader.

@monitorjbl I have to close the workbook manually to delete temp files.

I had a similar problem, temp file would not be deleted even if I closed the workbook. I was getting the file from urlConnection.getInputStream().  I had to close the inputStream first and then close the workbook. Maybe it will help someone who encounters it.


WebApp -  Set default pool and default validator for Avail

Describe the task

[x] Set "SubWallet Official 01" as the default pool for Avail
[x] Set validator as the default validator for Avail

Version test: https://b0b00c85.subwallet-webapp.pages.dev/
Validation passed.

Set "SubWallet Official 01" as the default pool for Avail
Set validator as the default validator for Avail: Auto select 16 validator

Auto-select SubWallet Stake
Status # Blocked
Commission < 100%


Support underscores for configuration file (aka, _myst.yml)

We currently support a configuration file called myst.yml. When MyST sites start to have a lot of pages, it can be hard to quickly find the myst.yml file among the long list. You have to scroll down to the ms and find it there.
For users that find this annoying, we could support one or more versions of the myst.yml filename. For example, either _ or . would bump it to the top of the list of files in most file explorers, making it easier to quickly find.
Note: this might become unnecessary once we implement nested file/folders for documents:

https://github.com/executablebooks/mystmd/issues/670

So if this would be non-trivial to support then we could just prioritize #670 instead

strong agreement here 👍
I'd just like to add that #670 would not necessarily help in the case of a transition from jb1
I like that the 2 jb-related files appear close to one another among a large list of files
but not enough that I'd go for the overwhelming task of splitting the contents into folders :)
to be clear, I do support #670 as well, because I need it too
not because of the folder thing though - I often use a single folder - but because of the alteration in the filenames where e.g. digits get removed, as far as I can tell


[question] Cluster not imported properly with Terraform

Hi,
I'm running Rancher HA 2.2.9 on AWS and everything is functional. Importing manually an existing EKS cluster is successful, as well other cluster related UI actions.
I'm currently trying to automate the cluster import, with Terraform:
provider "rancher2" {
  api_url   = format("https://%s/v3", var.rancher_domain)
  token_key = var.rancher_token
}

resource "rancher2_cluster" "default" {
  name = format("%s-%s", data.aws_eks_cluster.default.name, data.aws_region.default.name)
}

Once the EKS cluster is successfully created, it is imported into Rancher, with a Pending status. Editing the cluster inti UI will reveal the import command:
kubectl apply -f https://rancher.domain.com/v3/import/j1fqsqktgspkft9qtfm3xqzf9j07tx2rl2n8r4grqz8q7fnxqsxdv3.yaml

I can execute it fine and the cluster will be imported. However, I believe this should be done automatically.
When I look at the terraform plan, everything is there, here it is a sample:
 # rancher2_cluster.default will be created
  + resource "rancher2_cluster" "default" {
      + annotations                             = (known after apply)
      + cluster_registration_token              = (known after apply)
      + default_pod_security_policy_template_id = (known after apply)
      + default_project_id                      = (known after apply)
      + desired_agent_image                     = (known after apply)
      + desired_auth_image                      = (known after apply)
      + docker_root_dir                         = (known after apply)
      + driver                                  = (known after apply)
      + enable_cluster_alerting                 = false
      + enable_cluster_istio                    = false
      + enable_cluster_monitoring               = false
      + enable_network_policy                   = false
      + id                                      = (known after apply)
      + kube_config                             = (known after apply)
      + labels                                  = (known after apply)
      + name                                    = "amerigo-alpha-us-west-2"
      + system_project_id                       = (known after apply)

      + cluster_auth_endpoint {
          + ca_certs = (known after apply)
          + enabled  = (known after apply)
          + fqdn     = (known after apply)
        }

      + cluster_monitoring_input {
          + answers = (known after apply)
        }

      + rke_config {
          + addon_job_timeout     = (known after apply)
          + addons                = (known after apply)
          + addons_include        = (known after apply)
          + ignore_docker_version = (known after apply)
          + kubernetes_version    = (known after apply)
          + prefix_path           = (known after apply)
          + ssh_agent_auth        = (known after apply)
          + ssh_key_path          = (known after apply)

          + authentication {
              + sans     = (known after apply)
              + strategy = (known after apply)
            }

          + authorization {
              + mode    = (known after apply)
              + options = (known after apply)
            }

          + bastion_host {
              + address        = (known after apply)
              + port           = (known after apply)
              + ssh_agent_auth = (known after apply)
              + ssh_key        = (sensitive value)
              + ssh_key_path   = (known after apply)
              + user           = (known after apply)
            }

          + cloud_provider {
              + custom_cloud_provider = (known after apply)
              + name                  = (known after apply)

              + aws_cloud_provider {
                  + global {
                      + disable_security_group_ingress = (known after apply)
                      + disable_strict_zone_check      = (known after apply)
                      + elb_security_group             = (known after apply)
                      + kubernetes_cluster_id          = (known after apply)
                      + kubernetes_cluster_tag         = (known after apply)
                      + role_arn                       = (known after apply)
                      + route_table_id                 = (known after apply)
                      + subnet_id                      = (known after apply)
                      + vpc                            = (known after apply)
                      + zone                           = (known after apply)
                    }

                  + service_override {
                      + region         = (known after apply)
                      + service        = (known after apply)
                      + signing_method = (known after apply)
                      + signing_name   = (known after apply)
                      + signing_region = (known after apply)
                      + url            = (known after apply)
                    }
                }

              + azure_cloud_provider {
                  + aad_client_cert_password         = (sensitive value)
                  + aad_client_cert_path             = (known after apply)
                  + aad_client_id                    = (sensitive value)
                  + aad_client_secret                = (sensitive value)
                  + cloud                            = (known after apply)
                  + cloud_provider_backoff           = (known after apply)
                  + cloud_provider_backoff_duration  = (known after apply)
                  + cloud_provider_backoff_exponent  = (known after apply)
                  + cloud_provider_backoff_jitter    = (known after apply)
                  + cloud_provider_backoff_retries   = (known after apply)
                  + cloud_provider_rate_limit        = (known after apply)
                  + cloud_provider_rate_limit_bucket = (known after apply)
                  + cloud_provider_rate_limit_qps    = (known after apply)
                  + location                         = (known after apply)
                  + maximum_load_balancer_rule_count = (known after apply)
                  + primary_availability_set_name    = (known after apply)
                  + primary_scale_set_name           = (known after apply)
                  + resource_group                   = (known after apply)
                  + route_table_name                 = (known after apply)
                  + security_group_name              = (known after apply)
                  + subnet_name                      = (known after apply)
                  + subscription_id                  = (sensitive value)
                  + tenant_id                        = (sensitive value)
                  + use_instance_metadata            = (known after apply)
                  + use_managed_identity_extension   = (known after apply)
                  + vm_type                          = (known after apply)
                  + vnet_name                        = (known after apply)
                  + vnet_resource_group              = (known after apply)
                }

              + openstack_cloud_provider {
                  + block_storage {
                      + bs_version        = (known after apply)
                      + ignore_volume_az  = (known after apply)
                      + trust_device_path = (known after apply)
                    }

                  + global {
                      + auth_url    = (known after apply)
                      + ca_file     = (known after apply)
                      + domain_id   = (sensitive value)
                      + domain_name = (known after apply)
                      + password    = (sensitive value)
                      + region      = (known after apply)
                      + tenant_id   = (sensitive value)
                      + tenant_name = (known after apply)
                      + trust_id    = (sensitive value)
                      + username    = (sensitive value)
                    }

                  + load_balancer {
                      + create_monitor         = (known after apply)
                      + floating_network_id    = (known after apply)
                      + lb_method              = (known after apply)
                      + lb_provider            = (known after apply)
                      + lb_version             = (known after apply)
                      + manage_security_groups = (known after apply)
                      + monitor_delay          = (known after apply)
                      + monitor_max_retries    = (known after apply)
                      + monitor_timeout        = (known after apply)
                      + subnet_id              = (known after apply)
                      + use_octavia            = (known after apply)
                    }

                  + metadata {
                      + request_timeout = (known after apply)
                      + search_order    = (known after apply)
                    }

                  + route {
                      + router_id = (known after apply)
                    }
                }

              + vsphere_cloud_provider {
                  + disk {
                      + scsi_controller_type = (known after apply)
                    }

                  + global {
                      + datacenters          = (known after apply)
                      + insecure_flag        = (known after apply)
                      + password             = (sensitive value)
                      + port                 = (known after apply)
                      + soap_roundtrip_count = (known after apply)
                      + user                 = (sensitive value)
                    }

                  + network {
                      + public_network = (known after apply)
                    }

                  + virtual_center {
                      + datacenters          = (known after apply)
                      + name                 = (known after apply)
                      + password             = (sensitive value)
                      + port                 = (known after apply)
                      + soap_roundtrip_count = (known after apply)
                      + user                 = (sensitive value)
                    }

                  + workspace {
                      + datacenter        = (known after apply)
                      + default_datastore = (known after apply)
                      + folder            = (known after apply)
                      + resourcepool_path = (known after apply)
                      + server            = (known after apply)
                    }
                }
            }

          + dns {
              + node_selector        = (known after apply)
              + provider             = (known after apply)
              + reverse_cidrs        = (known after apply)
              + upstream_nameservers = (known after apply)
            }

          + ingress {
              + extra_args    = (known after apply)
              + node_selector = (known after apply)
              + options       = (known after apply)
              + provider      = (known after apply)
            }

          + monitoring {
              + options  = (known after apply)
              + provider = (known after apply)
            }

          + network {
              + options = (known after apply)
              + plugin  = (known after apply)

              + calico_network_provider {
                  + cloud_provider = (known after apply)
                }

              + canal_network_provider {
                  + iface = (known after apply)
                }

              + flannel_network_provider {
                  + iface = (known after apply)
                }

              + weave_network_provider {
                  + password = (known after apply)
                }
            }

          + nodes {
              + address           = (known after apply)
              + docker_socket     = (known after apply)
              + hostname_override = (known after apply)
              + internal_address  = (known after apply)
              + labels            = (known after apply)
              + node_id           = (known after apply)
              + port              = (known after apply)
              + role              = (known after apply)
              + ssh_agent_auth    = (known after apply)
              + ssh_key           = (sensitive value)
              + ssh_key_path      = (known after apply)
              + user              = (sensitive value)
            }

          + private_registries {
              + is_default = (known after apply)
              + password   = (sensitive value)
              + url        = (known after apply)
              + user       = (sensitive value)
            }

          + services {
              + etcd {
                  + ca_cert       = (known after apply)
                  + cert          = (sensitive value)
                  + creation      = (known after apply)
                  + external_urls = (known after apply)
                  + extra_args    = (known after apply)
                  + extra_binds   = (known after apply)
                  + extra_env     = (known after apply)
                  + gid           = (known after apply)
                  + image         = (known after apply)
                  + key           = (sensitive value)
                  + path          = (known after apply)
                  + retention     = (known after apply)
                  + snapshot      = (known after apply)
                  + uid           = (known after apply)

                  + backup_config {
                      + enabled        = (known after apply)
                      + interval_hours = (known after apply)
                      + retention      = (known after apply)

                      + s3_backup_config {
                          + access_key  = (sensitive value)
                          + bucket_name = (known after apply)
                          + custom_ca   = (known after apply)
                          + endpoint    = (known after apply)
                          + folder      = (known after apply)
                          + region      = (known after apply)
                          + secret_key  = (sensitive value)
                        }
                    }
                }

              + kube_api {
                  + extra_args               = (known after apply)
                  + extra_binds              = (known after apply)
                  + extra_env                = (known after apply)
                  + image                    = (known after apply)
                  + pod_security_policy      = (known after apply)
                  + service_cluster_ip_range = (known after apply)
                  + service_node_port_range  = (known after apply)
                }

              + kube_controller {
                  + cluster_cidr             = (known after apply)
                  + extra_args               = (known after apply)
                  + extra_binds              = (known after apply)
                  + extra_env                = (known after apply)
                  + image                    = (known after apply)
                  + service_cluster_ip_range = (known after apply)
                }

              + kubelet {
                  + cluster_dns_server    = (known after apply)
                  + cluster_domain        = (known after apply)
                  + extra_args            = (known after apply)
                  + extra_binds           = (known after apply)
                  + extra_env             = (known after apply)
                  + fail_swap_on          = (known after apply)
                  + image                 = (known after apply)
                  + infra_container_image = (known after apply)
                }

              + kubeproxy {
                  + extra_args  = (known after apply)
                  + extra_binds = (known after apply)
                  + extra_env   = (known after apply)
                  + image       = (known after apply)
                }

              + scheduler {
                  + extra_args  = (known after apply)
                  + extra_binds = (known after apply)
                  + extra_env   = (known after apply)
                  + image       = (known after apply)
                }
            }
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.
rancher2_cluster.default: Creating...
rancher2_cluster.default: Creation complete after 5s [id=c-5dt9k]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Into UI, the cluster shows as pending, instead of being added. Do I miss and specific permissions. I execute both terraform apply and kubectl apply -f from same terminal.

cc @rawmind0


Add css variables to components

Description:
(Link to bug/feature from Issues and how you resolve it)
Add css variable to give user of the following omni input components the ability to style the auto select hover color of the internal input element
omni-email-field
omni-number-field
omni-pin-field
omni-search-field
omni-text-field
Expose a new css variable on the Modal component to give users the ability to apply a min width to the component
Added blur on enter for Search field component
Testing was done via a alpha
All Submissions:

[x] I have followed the contribution guidelines for this project.
[x] I have checked to ensure there aren't other open Pull Requests for the same update/change.

Changes to Core Features:

[x] I have added an explanation of what my changes do and why I would like to include them.
[x] I have written new tests for my core changes, as applicable.
[x] I have successfully ran tests with my changes locally.
[x] I have added/updated docs, as applicable.

Note there is currently a issue on the docs site where the Icon component stories do not render as expected hence those specific tests failing the following ticket has been logged as a issue to address this.
In the case of the Select component a issue should be logged for that this results in screenshot comparisons being inconsistent and usually results in the tests for this component failing.
https://github.com/capitec/omni-components/issues/219

Merging this the current screenshot comparison for some of the input fields are out by 1 pixel.
Cases for failures for Icon and Select component is logged as an issue that needs to be addressed in future


is mobile target in roadmap

Hi,
thank you for all your work, this is great! :)
i was asking myself if mobile compatibility for iOS and Android was in the roadmap?
thx

I think one solution for that could be to use the Just-in-time (JIT)
compiler of pytorch to export a model in c++. SpeechBrain supports it. With
that, you should be able to export it to all the devices you want, right?
Maybe in the future we can do a tutorial on that.
On Tue, 16 Mar 2021 at 05:08, kezakool @.***> wrote:

Hi,
thank you for all your work, this is great! :)
i was asking myself if mobile compatibility for iOS and Android was in the
roadmap?
thx
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/speechbrain/speechbrain/issues/573, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEA2ZVVRIFJP7BBKUPAJO33TD4NX3ANCNFSM4ZIEJLHQ
.

@mravanelli is there anything out there yet? I'd like to run a SpeechBrain model on iOS and Android devices as well. Is it possible at this point and can I find a guide somewhere for this particular topic?

Just-in-time (JIT) compiler of pytorch to export a model in c++. SpeechBrain supports it.

Hi ,SIr please update me if there is any update about tutorial..?
it will be highly apprecaited.
thank you

@mravanelli is there anything out there yet? I'd like to run a SpeechBrain model on iOS and Android devices as well. Is it possible at this point and can I find a guide somewhere for this particular topic?

@stefan-falk
You may find the following sub-project of next-gen Kaldi helpful
https://github.com/k2-fsa/sherpa-ncnn
It supports Android, iOS, Raspberry pi, etc. I
t also has detailed documentation for building and deploying, though it does not support models from Speechbrain.
Help in adding support for SpeechBrain is highly appreciated.


testing: parallel benchmark results are poorly documented

The way parallel benchmark results are reported is easy to misinterpret, and the correct way to interpret them is not documented. Typically this makes perfectly-scalable benchmarks appear to perform much worse at low parallelism, and makes not-at-all-scalable benchmarks appear to be doing fine. For example, this came up in https://github.com/golang/go/issues/31820#issuecomment-489112014
Specifically, the "ns/op" reported is not CPU-ns/op, it's wall-ns/op. For example, suppose each op takes exactly 100 ns, regardless of parallelism. If the single-threaded benchmark runs for 1 sec, it will execute 10,000,000 ops, so ns/op = 1s/10,000,000 ops = 100 ns/op. But if the same benchmark runs 4-way parallel for 1 sec, it will execute 40,000,000 ops, so ns/op = 1s/40,000,000 = 25 ns/op. (I really wish it didn't work this way...)
Interpreting the results of CPU-bound parallel benchmarks is further complicated by hyper-threading (though this isn't the fault of the testing package).
I don't think we can change the reported ns/op at this point. We could perhaps introduce a new metric for parallel benchmarks. At the very least, we should document this.

Looking at improving this documentation now.
Considering where best to document - thinking this detail would be best added in a little of the documentation for testing.B.RunParallel and within the summary of the testing package as a note.
Would anyone recommend any additional areas to document this?

I just submitted https://go-review.googlesource.com/c/go/+/447136 for improving the documentation, PTAL.

I don't think we can change the reported ns/op at this point.

That's unfortunate. I think fixing the value would be the best solution here. This doesn't really fall under the Go 1 compatibility promise, does it?

We could perhaps introduce a new metric for parallel benchmarks.

I can send a patch for this. Maybe real-ns/op?
It also seems like it's possible to overwrite the reported "ns/op" with a better value like this:
start := time.Now()
b.RunParallel(func(p *testing.PB) {
	// ...
})

nsOp := float64(time.Since(start).Nanoseconds()) / (float64(b.N) / float64(runtime.GOMAXPROCS(-1)))
b.ReportMetric(nsOp, "ns/op")

Perhaps instead of reporting a new metric, we could add a convenience API, e.g. b.CorrectParallelMetrics().
But again, I'd prefer if the current behavior could be fixed.
Regardless of further action, I hope the documentation patch makes sense and can be applied in the meantime.

I can send a patch for this. Maybe real-ns/op?

I'd suggest adding a ops/sec metric along with the existing one (ns/op). This should make the output much more intuitive.


Add Ability to Manage Findings Tag with Api v2

#1340

[X] Your code is flake8 compliant
[ ] If this is a new feature and not a bug fix, you've included the proper documentation in the ReadTheDocs documentation folder. https://github.com/DefectDojo/Documentation/tree/master/docs or provide feature documentation in the PR.

you can perform any of the following request to control finding tags:
GET
POST
DELETE
on this newly added endpoint:
http://<IP_ADDRESS>:8080/api/v2/findings/:id/tags/
data format to pass in for POST  or DELETE will be an array of tags:
{
"tags": ["tag1", "tag2", "tag3"]
}

@propersam GET and POST work wonderfully. The DELETE function seems to be missing the data field though. It returns a 400 error for an empty tag list.

I kind of did that on purpose....
it does not seem logical to pass in an empty tag list to Delete method..
also if the tag you entered is not a part of the available tags...it return 400 error as well

That part makes sense. I didn't word that very well. The issue is there is no text box to enter the payload. All there is an ID field.

DELETE method receives the same data format as POST...
e.g.
{
"tags": ["tag1", "tag2"]
}
to delete 'tag1' and 'tag2'

For the sake of understandable documentation there have been an update...
a new end point as been added..
http://<IP_ADDRESS>:8080/api/v2/findings/:id/remove_tags/
this endpoint cn take PUT or PATCH method..
and receive data format:
{
"tags": ["tag1", "tag2"]
}
Delete method is no more supported on http://<IP_ADDRESS>:8080/api/v2/findings/:id/tags/ endpoint


siteatclick.com/admin is not working again

https://www.siteatclick.com/admin/Login.aspx?returnurl=https%3A%2F%2Fwww.siteatclick.com%2Fadmin%2FHome.aspx

Closing this on behalf of Ajayraj.. @ajayrajecb


Add option to use decryption key other than the default

Issue
With the latest update to Minecraft Dungeons a new AES key is required to decrypt the pak files.
Solution
By giving the user the option to provide their own key we remove the need to wait for a new release to use the tool and enable it to be used with older versions of the game.
To do

[ ] Add option to provide new decryption key if default fails #23 #37
[ ] Add option to relaunch with different pak files and decryption key

When I build the releases I include all the AES keys for any of the releases of MCD so the latest version of MCDSaveEdit is already backwards compatible.

When I build the releases I include all the AES keys for any of the releases of MCD so the latest version of MCDSaveEdit is already backwards compatible.

Yes, that's true, but for example now we have to wait for you to update, when we could just put the new one without bothering you.


[plugin server-bare-modules] Package subpath './package.json' is not defined by "exports" when using remix.run

Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch<EMAIL_ADDRESS>for the project I'm working on.
this fix this error
[plugin server-bare-modules] Package subpath './package.json' is not defined by "exports"
when using remix.run
Here is the diff that solved my problem:
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index 57e3943..5916362 100644
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -25,6 +25,7 @@
     "react": ">=17.0.0"
   },
   "exports": {
+    "./package.json": "./package.json",
     ".": {
       "import": "./index.js",
       "require": "./_commonjs/index.js",

This issue body was partially generated by patch-package.

This is more related to your node version which is outdated (or your Yarn version if you use it).
Update your node version and try again.


Setup the software release process by adding release branches and CI/CD actions

We have 3 types of releases of w3-poc,

main: production ready: release by deploying to IPFS and pin files
alpha: internal test: only for local test, without deploying to IPFS
beta: external test: deploying to IPFS without pin files

Setup each branches and adding github actions for releases, may referring the article, and the yml

@weihaopeng  help @Jianru-Lin to setup

branch
version
action
description

main
main
tag x.y.z
production ready

dev
alpha
tag x.y.z-alphan
internal test

release
beta
tag x.y.z-betan
external test

Do we need release branch? Or just dev and main branches, tag alpha and beta both on dev?

Current progress:
The ci workflow is updated and it will build and upload the files to our IPFS server now.

Next step I will create & config the release action. Then the uploaded website link will be displayed in our release note automatically with the source code package.
@ericwangqing @weihaopeng FYI

Current progress:

Every time we push code to the dev branch, there will be a new release generated. The release files include our source code package and the compiled package (w3-poc.tar.gz).
I will update it to follow our goal especially generate the IPFS link.
@ericwangqing @weihaopeng FYI

Current progress:

A new file named ipfs.txt is added in a release. Its content looks like this:
added QmdXSr4v1VsZqaQS7GwGuDwk9b9LBkjJzYJTaW9mtPPNvo dist/assets/index.c8938944.js
added QmY8J5kEZeDwhxmrcXgj7QNcfLWW7X6CNYXjJYKnSQ5TLM dist/index.html
added QmUEzjtXfRdWCrTVdRH49PiDa2wBnYqXjYZR6vYXwDCoHj dist/assets
added QmNYjrnaKCVeXRyYYZX3xapN3q2iJBfiQx4wwpT5VU9zWN dist

The last line is what we want. It means the root directory content id of our website. And we can access our website with the id.
@ericwangqing @weihaopeng FYI


create a Github readme file

as a developer, I need to create a readme file so that visitors looking at the repo are aware of all necessary information

Tasks

[ ] create the readme.md file
[ ] add introduction
[ ] add license information
[ ] add contributing information
[ ] add installation instructions
[ ] add technology stack information
[ ] add dependency information

Definition of Done

[ ] the readme.md file has been created
[ ] the introduction section is complete
[ ] the license information section is complete
[ ] the contributing information section is complete
[ ] the installation instructions section is complete
[ ] the technology stack information section is complete
[ ] the dependency information section is complete

still valid, low priority


[Github] Lets migrate to our new icon/logo

I think after we decide to use a shiny and pretty glasshour icon . it might be a nice
decision to migrate our logo also in github. What do you think @captn3m0  ?

:clap: :star_struck: :heavy_heart_exclamation:

Switched to https://github.com/endoflife-date/endoflife.date/blob/master/assets/logo-512x512.png at both GitHub and OpenCollective.

It looks awesome :clap:

Now it could be proudly printed on a :coffee: mug ot :shirt: :sunglasses:


[Feature] Progress Bar - Add time_end key and display if present

Adds the ability to include a time_end parameter to the page_data passed into a progress_bar(...) page.
I use progress_bar for displaying timers, I thought since there's so much space underneath the progress bar it would be nice to include a time_end which is really up to the caller to decide if it's an estimate or the exact time the progress bar will reach 100%

I opted to go for parsing the input as a datetime as an iso formated string.
An improvement could also be determining if it's a timestamp. In my case I'm pulling from a timer, which includes a finishes_at which is a datetime, and I believe timestamps are pretty easy to make into datetimes I figured to not include for now.
As a habit I also ran the code through black formatting.

Here's an example page_data for the service call that includes some context unrelated to these changes, mainly timer_name and progress are fetched from a call to another script before this service call. They're unrelated and it's just to illustrate we're passing in time_end to include an optional display of a second time in the space below the progress bar.
page_type: progress_bar
header: "{{ timer_name }} Timer"
progress: "{{ progress.percent_complete }}"
footer: "{{ progress.remaining_text }}"
time_end: "{{ state_attr(timer_entity, 'finishes_at') }}"
footer_offset: 15

[!NOTE]
As an aside the script in use above does keep the timer page active by forcing a loop to stay open until the timer is cancelled or completed. That is to say it makes me interested in where #49 is going.

I opted for a "light grey" rgb(151, 151, 151) as the default time_end_color, but I don't really have a strong opinion.
My thinking was it should look different than the time above and this was a quick way to achieve that, it is also customizable like the time_color is.
And here's how it looks (please excuse the bad photo, the light grey doesn't look this muted and I think is more legible):

As another example situation where I use the progress_bar page in my normal rotation of pages, set on the integration configuration is like during the work day which also are fed from a timer, but is a template helper (sensor) I've created off the work_day timer and could make use of the time_end parameter.
The sensor state as the value for time_end is a timestamp device class.
- page_type: progress_bar
  enabled: "{{ states.schedule.work_week.state }}"
  progress: "{{ states('sensor.work_day_8h_percent_complete') }}"
  footer: >-
    {% set finishes_at = state_attr('timer.work_day_8h', 'finishes_at') %} {{
    '00:00:00' if finishes_at == None else (as_datetime(finishes_at) -
    now()).total_seconds() | timestamp_custom('%H:%M:%S', false) }}
  footer_offset: "15"
  header: Work Day
  time_end: "{{ states.sensor.work_ends.state }}"

Please let me know if I should change anything if this could be an acceptable feature.
This was my first time testing a custom integration on my only home assistant install - so please let me know if I missed anything!

i would be very happy if you would concentrate on the essentials when making changes and not replace ' with ". this way i have to check the entire code for changes because more lines have been changed accordingly. otherwise i will gladly adopt your idea :D

i would be very happy if you would concentrate on the essentials when making changes and not replace ' with ". this way i have to check the entire code for changes because more lines have been changed accordingly. otherwise i will gladly adopt your idea :D

Sure, I've narrowed the formatting to one commit, but if its helpful I'll drop it entirely

i would be very happy if you would concentrate on the essentials when making changes and not replace ' with ". this way i have to check the entire code for changes because more lines have been changed accordingly. otherwise i will gladly adopt your idea :D

Sure, I've narrowed the formatting to one commit, but if its helpful I'll drop it entirely

No no no, I think it's fiiiiine. I think it was needed anyways.

i would be very happy if you would concentrate on the essentials when making changes and not replace ' with ". this way i have to check the entire code for changes because more lines have been changed accordingly. otherwise i will gladly adopt your idea :D

Sure, I've narrowed the formatting to one commit, but if its helpful I'll drop it entirely

No no no, I think it's fiiiiine. I think it was needed anyways.

haha ok, I already force-pushed an update - looks like theres more for me to change 😄
so if it's okay I'll run formatting on the file at the end of an approving review

no problem it's not urgent... give me a sign when you are ready. i test every time anyway and then write the readme directly... i don't think i do anything else anymore -.-

no problem it's not urgent... give me a sign when you are ready. i test every time anyway and then write the readme directly... i don't think i do anything else anymore -.-

well if it's helpful, I started the README changes!


added custom driver support in scrape function

I am using Scweet with the flask backend to scrape the data, but facing few problems while deploying because of selenium. While searching for alternative ways, I figured out that we can use Docker to containerize the whole application and run the selenium service through docker image.
While implementing this, I found that there is no way to define or pass custom driver with scrape function. I have implemented this feature on my own, but would like to merge this in the library.

Would be really useful in other methods such as get_users_followers, get_users_following as well


SOLR-17195: Add 'minPrefixLength' soft limit

https://issues.apache.org/jira/browse/SOLR-17195
Description
Prefix-based queries consume memory in proportion to the number of terms in the index that start with the prefix.  Short prefixes tend to match many more indexed terms, and consume more memory as a result, often causing instability issues on the node.
Yet Solr (prior to this PR) offers no way to restrict the prefixes used in queries.
Solution
This PR adds a solrconfig.xml property, minPrefixLength, which operates similarly to the existing maxBooleanClauses.  Users who submit a query with a prefix shorter than the minimal acceptable length will receive an error of the form:
Query <snip> does not meet the minimum prefix length [2] (actual=[1]).  Please try with a larger prefix, or adjust minPrefixLength in your solrconfig.xml

Some notes on the implementation:

currently only enforced for 'string' and 'text' fields, where this cardinality problem occurs most frequently
defaults to '2' in the default configset, prohibiting only single-character prefixes.
can be overridden in the default configset with the solr.min.prefixLength sysprop/env-var

Tests
Tests for solrconfig.xml in SolrCoreTest. Tests for the limiting itself in PrefixQueryTest.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[x] I have run ./gradlew check.
[x] I have added tests for my changes.
[x] I have added documentation for the Reference Guide

Three questions I'd like to answer before this is merged:

I can imagine scenarios where an advanced user might want to enable this feature, but still be able to exempt certain queries.    Is it worth adding a query-param feature flag, that can be used to disable the limit on a query-by-query basis?
Some faceting codepaths run prefix queries in the course of processing certain types of facets.  Should we enforce this limit on these codepaths or skip it?
Is there any value in expanding the limit to cover field types other than 'string'?

Other TODOs:

ref-guide docs
additional testing
tidy/check.

I wish we brainstormed this a bit on the dev list or something prior to you showing up with a PR where there is maybe inertia to continue with it the way it is

I don't really think that's a fair characterization.  The JIRA ticket was open and advertised to all of us on issues@ 3 months ago, and no one chimed in there.  Sometimes the brainstorming and feedback just doesn't appear until there's a 'patch' to stimulate it, so I wrote one 🤷
In any case, I'm happy to discuss/brainstorm the overall approach now.  I think it stands on its own without considering "inertia".

In short, my thought process was that the more broadly applicable the limit is, the more effective it will be at protecting stability.  It's hard to achieve stability if the safeguards you're relying on are opt-in, "off" by default, or only apply to a subset of relevant queries.  So I wanted to make the "minPrefix" limit be opt-out, apply broadly, etc.
Solr already has a query-time limit that fits this "broadly applicable" model pretty well, also in service of stability: maxBooleanClauses.  mBC has caused its share of issues, but the underlying model is sound and has been a part of Solr for at least a decade.  Users are already familiar with this sort of limit coming in under solrconfig.xml, etc.
So that's mostly what I've tried to do in this PR: (1) make it "broad" by design, and (2) follow mBC as a model in terms of how to configure, document, and implement.
@dsmiley - You noted above your preference for something parser-specific.  Can you elaborate on that preference a bit?

I'm sorry for challenging your due diligence on soliciting input.

In short, my thought process was that the more broadly applicable the limit is, the more effective it will be at protecting stability. It's hard to achieve stability if the safeguards you're relying on are opt-in, "off" by default, or only apply to a subset of relevant queries. So I wanted to make the "minPrefix" limit be opt-out, apply broadly, etc.

This runs the real risk of an obscure limit showing itself in production that would hot have been caught in a test setup for a use-case that should absolutely not have such a limit.  Generally "q" is provided by a user, uses a more user-facing query parser (namely edismax), and would be a nice place for such a limit.  But otherwise, queries show up in tons of other places for internal use-cases written by systems programmers (i.e. us devs) using the default "lucene" query parser where I don't think such a limit at all makes sense (at least not by default).  Random examples -- delete-by-query, facet.query, join query.
The same is so for maxBooleanClauses!  I was hoping you wouldn't bring that up but of course you did; it's the precedent for your decision.  That unfortunate precedent caused a huge ugly debate with only one person holding veto power that insisted on maxBooleanClauses as it exists today.  That might have made Yonik leave to do Heliosearch over, if there was a huge straw break that back.  I hope we don't repeat that mistake.  I've only ever increased maxBooleanClauses to something insane, not because there isn't a risk of users doing expensive queries that we want to limit, but instead because the correct (IMO) place to enforce query constraints is at the query parser.  And we do this where I work for various things that in-effect constraint the query complexity.
@markrmiller you and most others were involved in that ugly debate... what do you think of Jason's approach here?

Generally "q" is provided by a user, uses a more user-facing query parser (namely edismax), and would be a nice place for such a limit. But otherwise, queries show up in tons of other places for internal use-cases written by systems programmers (i.e. us devs) using the default "lucene" query parser

I'm not sure the edismax=user-queries, lucene=system-queries generalization is a safe one to make.
And even if it is, I think you're making an additional assumption here that "system" queries wouldn't also benefit from this check.  I'm not sure I agree.  System-devs are more likely than the average user to know about Solr's performance pitfalls, but is that safe to assume across the board?  I think our many years with the project put us in danger of overestimating the knowledge and context other users might have, and underestimating the value of safeguards.
That's the key issue for me IMO - if I was more comfortable with those generalizations I'd be happy with an edismax fix.  But as-is they feel like pretty shaky ground to base cluster-stability on.

I've only ever increased maxBooleanClauses to something insane, not because there isn't a risk of users doing expensive queries that we want to limit

maxBooleanClauses is, admittedly, a pain.  For one, it's terribly calibrated, or at least terribly out of date.  (Is 1024 clauses even a lot on today's hardware?  It seems like nothing!). I'm not here to defend it.  And I can't speak to the old debate without reading up on it.  (Do you have a pointer handy @dsmiley ?)
But conceptually I think maxBooleanClauses takes the right response to a "DANGER" stimulus.  If something has the potential to take down a cluster a global block is the safest thing to do.  Solr should be stable by default, even if that means admins have a little extra work to do to "unlock" certain query patterns.

Generally "q" is provided by a user, uses a more user-facing query parser (namely edismax), and would be a nice place for such a limit. But otherwise, queries show up in tons of other places for internal use-cases written by systems programmers (i.e. us devs) using the default "lucene" query parser

Thinking about this a bit more, I wonder if the real issue here is that there's no way to tell Solr unequivocally, on a request-by-request basis: "Don't second-guess me, I know this is safe".  If users had a way to communicate that, there wouldn't be any need for us as developers to try to generalize about which queries came from "end" users, what users may or may not know about Solr performance, etc.
Would adding something like that  make you feel any better about the parser-agnostic approach @dsmiley ?  It'd give savvy "system" users a way to sidestep the "hitting a limit for the first time in prod" false-positive you expressed concern about above.

“what do you think of Jason's approach here?”
It is a kind thorny practice that evades a good definitive judgment.
I suppose the idea is, at some, perhaps fairly arbitrary limit, you fail things to force the user to reckon with what they are doing more carefully and actively raise limits of they think that's the correct action. I say perhaps fairly arbitrary because it's difficult to do any better, given varying hardware and data.
The cost is that is that things that worked fine in testing may start blowing up randomly in production, perhaps needlessly, until you address the situation.
Thorny. Benifit / reward, what lines are drawn where, it's all pretty subjective. So I don't know.
As a user, I certainly would want to be able to opt in, though yes, that makes the effort likely of little value, particularly if it's opt-in per limit. A universal opt-in would be better but would likely still end up as little value then. As a user, I'll still be pissed when production starts failing things the first time, and I judge it, should not be doing that for my case. And at that point, I would be very unhappy if there was not a universal opt-out. Thorny.
I do see the value, but in most cases, that value would not likely be high enough to convince me as a user that this was a good default system practice. Other than for very particular things, it doesn't seem like a common practice because of how thorny it is.
I think some limits have a bit more clear value, though. Things that can build up over time and then are very difficult to address. Something along the lines of no limit to the number of fields on a document, where things can work fine for the first 6 months, but over time, you are using more and more fields and eventually the system just kind of seizes under the weight, and you can't do much but start over. Maybe hitting something much earlier that said you are using a strangely large number of fields, this is not a very scable approach, you have to change a configuration to continue down this path, would make a lot more sense.

One use case where opt-in still has a lot of value is when one team runs Solr as a service or for other teams. In that case, it's much more of an available feature than automatic user self protection.

@markrmiller mentioned to me offline that it was clear that my preference was for cluster-stability over convenience/admin-friendliness, but that I never made the rationale behind that preference explicit.  He suggested I take one last crack at making the case for across-the-board limiting, as explicitly as possible.  So here it is:
Ultimately my rationale is pretty simple: aggressive prefix queries have the potential to block all traffic if they trigger an OOM.  That's a worst-case-scenario for an administrator.
There's pain for administrators either way.  Realizing that some setting has errantly blocked some "known safe" queries definitely brings a serious "annoyance-factor".  But to put myself in an administrator's shoes, I'd rather deal with that on 10, 20, even 100 clusters than deal with an "all traffic" outage at 3am because of a runaway prefix query.

So that's my last pitch for across-the-board limiting.  I'll give this a few days to see if it sways anyone; if no one else is convinced enough to chime in or reverse course though I'll go forward with something like the more limited approach that David championed.

I've been on vacation lately.
I suggested a limit based on the query parser.  This suggestion isn't limited to edismax; it'd include some others that users are likely to use.  Another angle is to employ this limit only on a TextField, which generally should be used for keyword search and thus user queries.  I think I can be comfortable with that.  But not StrField in particular (in terms of opt-in vs opt-out).  That's where my concern is most likely to be used in practice.

I suggested a limit based on the query parser. This suggestion isn't limited to edismax; it'd include some others that users are likely to use.

Did you have particular parsers in mind @dsmiley ?  Or is there somewhere else that the project relied on this "end-user" vs "admin" parser distinction, that I could get a list from?
I'm on board with expanding the set of parsers that will enforce this limit, but I don't have a great sense what you or others would consider "end-user" parsers.  If you have a concrete subset in mind, then I'm happy to run with that.

Another angle is to employ this limit only on a TextField, which generally should be used for keyword search and thus user queries.

I think I agree that "field-type" is a better predictor of "user query or not" than the query-parser would be.
Maybe my experience is idiosyncratic, but prefix queries on TextField aren't the common case from what I've seen.  Anecdotally, prefix queries are much much more common on StrField.
We could apply the limit only on TextField, but if that only covers (e.g.) 20% of the prefix queries that'll hit the index - is it providing stability?  I guess it still could, if the terms dictionary was large enough.  But still, leaving the majority prefix-query use-case uncovered doesn't feel great...  I'm just thinking-aloud/rambling at this point I guess.

Anyway, let me think through which of these two approaches (field-based vs parser-based) I like better, and I'll push up a modification shortly.
Thanks for sticking with this through your time off any everything @dsmiley ; hope you had a good trip!

The more I think through this today, the more I start to wonder whether I was wrong to oppose an "opt-in" solution originally.
It doesn't benefit all users the way an opt-out solution would, but maybe that's for the best given the high level of concern around annoyance and false-positives. Shrewd users, and folks who especially need it (e.g. the "service" use case Mark mentioned) would get a really comprehensive limit at their disposal once they enable it.  And of course, it'd keep us out of the business of trying to guess which queries are likely to be "user queries".
Is that something you could get behind @dsmiley ?

One idea is that maybe we would want to have a page in the ref guide that was "The Defensive Solr Setup" and you could reference this type of feature and other features that enable this?   Maybe someday we ship a configset that represents a configuration that is very protective?   To make it easier for non experts to adopt this type of feature?

"user" query parsers: complexphrase, dismax, edismax.  All others seem internal to me.  We could have an abstract method on QParserPlugin (or QParser) that compels plugin authors to indicate what the default prefix query limit should be (if any).
Field types:  (I accept this approach too, albeit I like it less)

Is that something you could get behind @dsmiley ?

I'm unsure exactly what you are asking me.  I'm definitely behind "opt-in" :-)

I'm unsure exactly what you are asking me. I'm definitely behind "opt-in" :-)

Sorry - I should've been more concrete.  I'm asking if you could live with a parser-agnostic (i.e. global) limit like what the PR currently implements, if it was made "opt-in" rather than "opt-out".
AFAICT that combination would address your concerns around false-positives, making work for admins, etc.  And it'd be my preference over a parser-aware approach, as I'm not totally comfortable with the idea of inferring query origin from the parser implementation.
If you're -1 on any sort of a "global" limit, even as an opt-in feature, I'll implement parser-aware.  But I didn't want to do that without checking where you stood on the global+optIn approach.

Alright @dsmiley - I took in most of your suggestions:

The logic for determining the limit now lives in QParser
QParser looks at the solrconfig.xml setting, but uses a local-param override if specified
The setting is now "opt-in", with the flag value "-1" used in the default configset.

Lmk what you think; hopefully this is close.

AFAIK - the last outstanding question here is whether to bundle in a separate change to make ComplexPhraseQParser be schema-aware in how it creates its queries.  There's a few technical hurdles there unfortunately - so my plan (unless I hear any vetos) is to punt on that for now.  Full discussion of the idea and subsequent issues here..
I'll give a little more time for feedback, but I'll look to merge sometime this week otherwise


Texture name is not generated correctly when osc inputs have more than 3 informations

Hello,
I tried to send osc messages from some apps like ZIGSIM, but VEDA has no response and the texture remain black.
So I checked 3 types of osc inputs, like below...
/foo (--> osc_foo)
/foo/bar (--> osc_foo_bar)
/foo/bar/hoge (--> osc_foo_bar_hoge)

I was able to successfully receive the above 2 patterns, but last one was not.
I don't know where is wrong. How to do when osc inputs have more than 3 informations?
btw thanks for your work, I love it.

Thanks @almina-orange !
uh, it was a typical regex bug 😭
just fixed and published VEDA v2.13.2. plz try it out!

Hi @fand ! It works. thanks!


Cut links/added a few bullets to Wiki link section

Remember to add PRs to the project board so they show up, and request reviewers :)


Strange "abort" message when starting ZSH with Prezto

Unable to find a similar existing issue.
Description
Whenever I launch iTerm or Alacritty, I see an unwanted "Abort" message. For example...
Last login: Thu Mar 19 00:01:34 on ttys000
[9]    8156 abort
Q:	Know what the difference between your latest project
and putting wings on an elephant is?
A:	Who knows?  The elephant might fly, heh, heh...
~ ❯
Expected behavior

I'd expect to see something similar to the above but minus the [9]    8156 abort line.
Actual behavior
See above.
Steps to Reproduce
Launch shell with iTerm or Alacritty
Versions

Prezto commit:
Prezto files appear to have been created on 9 Mar 2018
ZSH version:
ZSH version 5.8 (Just upgraded from earlier version - same problem)
OS information:
macOS 10.14.6

The reason I'm reporting this issue here is that when I remove the source "${ZDOTDIR:-$HOME}/.zprezto/init.zsh" line from my .zshrc file, I do not see the Abort message, which seems to point to Prezto. I may well be wrong in this assumption. If so, apologies :)

I've just downloaded and reinstalled Prezto using the instructions on https://github.com/sorin-ionescu/prezto and it seems to have sorted the problem. I should have used zprezto-update but I didn't spot that until too late!


Run: Enable running a remote script using a URL, repository or GitHub path

This change makes run able to run a remote script from a URL, a git repository URL or a GitHub path. For example, in order to run Test Drive users can now use either of these three methods to run it directly, without having to install it first:

marathon run https://github.com/johnsundell/testdrive.git
marathon run https://raw.githubusercontent.com/JohnSundell/TestDrive/master/Sources/TestDrive.swift
marathon run johnsundell/testdrive

The latter is the big improvement, that enables running remote scripts using a very concise syntax.

@pixyzehn @garricn @kareman @darthpelo @cojoj @alexaubry would love your thoughts on this! 😄

@JohnSundell that's awesome! I love the GitHub path syntax. It's very clean, and will make it even easier to use scripts. Is it also available for install?
Maybe it'd be useful to update the README to reflect the new features 😊

Oh man, amazing stuff!!! ❤ I love it!!!
Yeah, @alexaubry is right, but I guess @JohnSundell will add proper stuff to README 😉 This remote thing will be a super nice case for reusing simple scripts from Gists.

Happy you guys like it 😄 @alexaubry yeah it's available for install as well, out of the box, because they use the same code path to resolve a script 👍 I will totally add it to the README as well! 🚀

@cojoj @alexaubry Updated the README 👍


Change Title of the website from default to Website's name.

Describe the bug
The title of the website is currently the default React App title.
Expected behavior
Title should have the name of the website.
Screenshots

Please assign me this issue under SSOC.

@Some already raised a pr for this.

@kushagra-singhh Someone already raised a pr for this.

okay then...closing the issue !!


Add new setting "activatorActiveStyle" to the scrollspy component.

This new setting will allow specifying a CSS style as an alternative to class names. This will be useful when dealing with themed stylesheets that may override local classes.
If activatorActiveStyle has been set and properly formed, it will override any setting for activatorActiveClass.
Typically, the activator would be a link responsible for activating a scroll target within a page, but may also be used to highlight a corresponding menu item when the scroll target is in view.

Completed.


Landing Page : Content Addition

Is your feature request related to a problem? Please describe.
Persuasive Description about the platform
Describe the solution you'd like
Some content can be added in the landing page. Like catchy introduction about your platform can be added. For example IMAGINE AI : Ignite Innovations using AI
Many more catchy phrases can be added so that platform appears more appealing to the user.
Describe alternatives you've considered
Overall appearance of the landing can also be changed.
@SurajPratap10 Please assign this issue to me under GSSOC'23 as I have experience in designing and content writing.

Are you working on it? @astha-05

Yes @SurajPratap10 I'm working on it. I'll finish it by sunday.

Hey @SurajPratap10 Can it be assigned to me? It's been 3 weeks but hasn't been done yet


Side Panel Guidelines

As a user of the design system, I want to build a side panel that's consistent with other products at Trimble to create a consistent user experience, make sure I'm on brand, and that I'm building an accessible product.

@enowak1031
Can this be closed as complete?
I guess this is for Side Navigation guidelines - i.e. https://modus.trimble.com/components/side-navigation/ ?

Nope... Side panel is different from side nav. Side panel controls content within the main frame and displays on the right of the screen. Thanks for checking :)

@msankaran0712 to change the repo to styleguide


There is no value for the neg_coeff

what value you used for the neg_coeff?
in evaluate.py

loss = self.args.pos_coeff * pos_loss + self.args.neg_coeff * neg_loss

The default value of neg_coeff is 1.0, which can be located in the updated evaluate.py file

thank you for the update!


port k8s plugin from aws v2 to v3 client

Hey, I just made a Pull Request!
port k8s plugin from aws v2 to v3 client
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

@jamieklassen I see you have become the kube plugin maintainer. Congrats. I wonder, if you had a chance, I would appreciate if you could review this pull request.

@backstage/maintainers  can we get a review?

🙏

I dont think the e2 failure is related to my change. It would be great if someone could retrigger the build.

Hi, I believe this is in a good state to be merged.. It would be great if this could be merged before the next release if that were possible.

not stale.


Bug - Fix page order sorting

Description
After the page order is fetched from the Application object, we should use the order from this object. I was not using this value to sort the pages.
Fixes #
Type of change

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

How Has This Been Tested?

Unit Tests
Postman

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes

@trishaanand Fixed a bug in sorting. I somehow missed this and was using wrong assertions in unit tests as well. Please review 😀


FI-1357 Allow Tests and Groups to Be Marked as Optional

Allow Tests and Groups to Be Marked as Optional
Allows for tests and groups to be marked as optional. Tests can also be marked as required, which is especially useful when importing an optional test that you want to be required.
For example:
group 'Optional Group with Test' do
  optional
  test 'Optional Test in Group' do
    optional
    run { assert false }
  end
end

A test marked as optional will have a small optional chip next to the title in the list and card. The pass, fail and error icons also appear as lighter versions of the required versions.

Example Screenshot

TODO:

[x] Allows optional tests to be excluded when importing a group
[x] Indicating a test is optional in the UI
[x] Better tests
[x] Code Documentation
[x] Swagger Updates
[ ] Allow certain a group or tests within an imported group to be made required/optional

Questions & Discussion Points

Should optional always be returned in the JSON API? Or should it be an optional field that only has to be present if the test or group is actually optional? Right now optional is always present whether true or false.

Codecov Report

Merging #52 (043a749) into main (3ab6d88) will increase coverage by 0.04%.
The diff coverage is 97.91%.

:exclamation: Current head 043a749 differs from pull request most recent head 1a62f02. Consider uploading reports for the commit 1a62f02 to get more accurate results

@@            Coverage Diff             @@
##             main      #52      +/-   ##
==========================================
+ Coverage   94.44%   94.48%   +0.04%
==========================================
  Files          92       93       +1
  Lines        2123     2157      +34
==========================================
+ Hits         2005     2038      +33
- Misses        118      119       +1

Impacted Files
Coverage Δ

lib/inferno/entities/has_runnable.rb
92.85% <92.85%> (ø)

...tes/dev_infrastructure_test/infrastructure_test.rb
92.30% <100.00%> (+2.06%)
:arrow_up:

lib/inferno/apps/web/serializers/result.rb
100.00% <100.00%> (ø)

lib/inferno/apps/web/serializers/test.rb
100.00% <100.00%> (ø)

lib/inferno/apps/web/serializers/test_group.rb
100.00% <100.00%> (ø)

lib/inferno/dsl/runnable.rb
96.29% <100.00%> (+0.21%)
:arrow_up:

lib/inferno/entities.rb
100.00% <100.00%> (ø)

lib/inferno/entities/result.rb
100.00% <100.00%> (ø)

lib/inferno/entities/test_run.rb
100.00% <100.00%> (+4.00%)
:arrow_up:

lib/inferno/test_runner.rb
100.00% <100.00%> (ø)

... and 1 more

Continue to review full report at Codecov.

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

I think we should investigate other options for the optional display. The badge just makes the optional tests stand out more than the required ones, which is backwards. Maybe small-caps and a lighter font color. I'd say smaller font size but the text is already pretty small. Any suggestions from @arscan or @AlyssaWang ?

I think we should investigate other options for the optional display. The badge just makes the optional tests stand out more than the required ones, which is backwards. Maybe small-caps and a lighter font color. I'd say smaller font size but the text is already pretty small. Any suggestions from @arscan or @AlyssaWang ?

@Jammjammjamm Switch the Chip with a regular Typography or use a transparent background color, lighter font color, and italicise it?

Should optional always be returned in the JSON API? Or should it be an optional field that only has to be present if the test or group is actually optional? Right now optional is always present whether true or false.

Only including optional when it is true was problematic with blueprinter, so I'm always including it right now.

I was looking at the UI portion of this and I think the group result that's getting passed through needs to be updated re: hierarchy; e.g. if there is a non optional success and an optional fail then the overall result should be success(?)

I was looking at the UI portion of this and I think the group result that's getting passed through needs to be updated re: hierarchy; e.g. if there is a non optional success and an optional fail then the overall result should be success(?)

That should be handled. Did you see a case where it wasn't?


Add SIG Testing Spotlight article

Add SIG Testing spotlight article
Closes: #413

/cc @sandipanpanda

/retitle Add SIG Testing Spotlight article

https://github.com/kubernetes/contributor-site/pull/454#discussion_r1398185584 is the one thing I would like to see changed; the other feedback is optional.

/hold
Once https://github.com/kubernetes/website/pull/43982 is approved, it's OK to unhold this.
If it turned out that https://github.com/kubernetes/website/pull/43982 didn't get reviewed in time (there's little reviewer capacity), it's also OK to skip the mirroring and unhold to publish just this article.

Thank you @sftim , I added all your suggestions, and will add them to 43982 as well.

Both this one and the one on website are on hold waiting for the other; to break the loop, I'll unhold this one first.
/unhold

/hold
We should get both articles LGTMed before unholding.

If this gets LGTM and approval, and the deadline arrives, then it's OK to unhold.
I'll take a look at both articles.

@fsmunoz https://github.com/kubernetes/website/pull/43982 is marked as a work in progress. Is that intentional?

@sftim fixed there, thanks!

/hold cancel
https://github.com/kubernetes/website/pull/43982 is approved and LGTM


Windows Hypervisor Platform windows 10 enterprise not found

** Description**
Hi, the characteristic "Windows Hypervisor Platform" is not in the options below.
 where is it?
I have Windows 10 Enterprise

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


change checksum warning to debug print

This was super helpful when the server was continuously returning bad
checksums, but it’s a scary warning to see anytime we update the
versions file. And we’re going to need to update the versions file at
least twice a year, so it seems like a good idea to head off users
worrying about a message that is actually things working as intended.

👍🏻

@homu r+

:pushpin: Commit 817d279 has been approved by indirect

:hourglass: Testing commit 817d279 with merge 3c4d7ed...

:sunny: Test successful - status


EDA: Create logic for appending code to pipelines

Webview triggers for actions that manipulate data
VS Code to pick those up
Extend code to pipeline and execute
Get and send new placeholders to webview to update

:tada: This issue has been resolved in version 0.10.0 :tada:
The release is available on:

npm package (@latest dist-tag)
npm package (@latest dist-tag)
v0.10.0
GitHub release

Your semantic-release bot :package::rocket:


I am not able to debug when I change Python version from Python3.9 to Python3.6.

Hello,
I am using Vs code for debugging purpose. The version of VS code is 1.69.0.
I am working on EC2 instance. The instance is specifically created for dedicated task. I am not using virtual environment. all the libraries are installed as a root.
I have set up my project(open github repository) for python3.6 which is insatlled at path /usr/bin/python3.6. I am able to run my python files using python3.6.
Now I want to debug my code to understand it better. When I start debugging it takes python3.9 which is installed at path /usr/local/bin/python3.9. I want to debug using python3.6 but do not know how to do it. I have tried dew approaches and listed here.

I have changed Python: Select Interpreter to python3.6. But when I change it It does not even debug. when i click on run button it will start and stop immediately. It will not hit any breakpoint.
Here is my launch.json file:

{
    "configurations": [

        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": false
        },
        {
            "name": "Python: Module",
            "type": "python",
            "python": "/usr/bin/python3.6",
            "request": "launch",
            "program": "/home/ubuntu/ObjectDetection/July/second.pytorch",
            "console": "integratedTerminal",
            "args": [
                "kitti_data_prep",
                "--root_path",
                "/home/ubuntu/ObjectDetection/Dataset"
            ],
            "module": "second.pytorch",
            "env": {
                "PYTHONPATH": "${workspaceFolder}${pathSeparator}${env:PYTHONPATH}"
            }
        }
    ]
}

I gave python path in lauch.json also but no help.

Prefrences:Open User Settings and then search for Python: Default Interpreter Path. Specified Pythonpath as /usr/bin/python3.6. But still not able to debug. It does not hit breakpoint.

Can Anyone please help me?
I need to debug my code with python3.6 not with python3.9.
Thank you.

I installed previous version of Python v2020.5.78807 extension for VSCode (ms-python.python). then I have changed Python: Select Interpreter to python3.6. Now I can debug with python3.6.
I hope this helps someone.


fix(update-build-links): Improve title parsing

What does this PR do?
Improve title parsing, using separator instead of fixed length

Motivation
Prevent bad replace if we have more than 10 RC (see page comparison)

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


Update event-hubs-limits.md

added max # of auth rules per namespace.

@svk2,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@svk2 Thanks for the contribution! #sign-off


server: allow to use HDB backend

Add an extra argument to the LdapServer class to allow use
of the HDB backend which among other things allow the use of
SimplePagedResultsControl as LDIF doesn't.

I love this!
However, I'd rather go a step further: remove support for LDIF altogether — this is intended to be a simple yet faithful LDAP implementation ; I want to keep it as simple as possible.
What do you think?


Throw if RouteId has value

Fixes https://github.com/microsoft/reverse-proxy/issues/1029

@danirzv Are you fixing the issue #1029 by this PR? If yes, could you please add the comment Fixes #1029 to the description.

@danirzv Please, resolve merge conflicts.

Thank you!


[Task] Jobs System

Task Description
Would be nice to have a jobs system. This jobs system is really what sets Kumiko apart from most multipurpose bots with an economy. Especially on how the ranks system works.
Moving forwards with the implementation, here are some ideas to be considered:

Each job gives you a base pay + bonus (to be added later). The amount of money you have determines your current rank. The algo will be an exponential function. For example, I have an job that earns me 50 petals per hour (just like US jobs), and my rank is 1. Over time, I get more petals, (50, then 50 more, and so forth) and once I reach to an certain amount of petals (say 2500 for example), then my rank goes up. This essentially ties both the rank and jobs system together
Once you reach a certain rank, you unlock features, such as bounties, (aka quests, aka tasks), and more
The higher the rank, the better the jobs are
Include a default set of jobs?

And here is the general checklist:

[x] Add CRUD commands
[x] Add list/unlist job commands
[x] Add purge command
[x] Add transfer (ownership) command (It just doesn't make sense to "transfer" a job away, when in reality, you kinda have to apply/quit for one instead)
[x] Add remove by id command
[x] Add an application system. Aka apply/quit commands. the max amount of jobs that one user can have is 3
[x] Add the actual task running in the background that updates them as needed.

Sorry Edelweiss, but I'm going to rip off some of your ideas

Bank system (w/ Checking and savings. Just like how an actual bank works in the US)
Job, with salary
Credit Card
Personal Wallet + Debt + Premium

This jobs feature is finally done. After being considered for so long, it has finally been implemented


Localization

It would be great to have localization support for multiple languages. Hardcoded strings would use some lut (look up table) to get the correct locale string.

It's a good call, I've given it some thought and it's not quite as easy. A lot of the text is generated and is state specific - for example - "You have a banana, a peach and an apple", so a bit of work is required beyond implementing a LUT with little gain currently.


Update GIF (adding Snapshot text record) in docs that is misleading

Many people are facing this issue, They add "SNAPSHOT" for ENS text record instead of lower case snapshot  one of the reason one user said was they see capital snapshot in the GIF that is in snapshot docs

This need to be replaced with a small case snapshot

Continued here https://github.com/snapshot-labs/snapshot/issues/1049