condition with a contradiction:  "type: Error, reason: "NoError"

The following condition is confusing, it's in 'error', but reason is set to 'NoError'
    - lastTransitionTime: "2020-02-18T12:22:01Z"
      lastUpdateTime: "2020-02-18T12:22:01Z"
      message: No error seen
      reason: NoError
      status: "False"
      type: Error

Is it expected, if yes: could we improve the message/reason fields ?

@nan-yu   is that intended ?

Yes, that's intended. The type Error with False status implies no error, which is in line with reason NoError.
Initially, I was thinking remove this condition. However, I saw somewhere documented that the guidelines around condition is to set the condition to false, not clear it. The absence implies Unknown, not false.
@ant31


[wip] Add checks for missing override

Motivation
Adds more static checks to bring us closer to the runtime system: in this case, detect when we've used override or implementation where there are no associated overridable and/or abstract methods.
Test plan

See included automated tests.

This needs some updates in the monorepo before merging.

I'm setting this to merge, as the pay-server PR is approved and in the queue, so we can bump Sorbet as soon as both merge.


Warning on interface{} bools

package main

import (
	"fmt"
)

func main() {

	var b interface{}

	b = true

	if b == true {
		fmt.Println("True")
	}
}

Gives:
/Users/bep/go/src/github.com/bep/temp/main.go:13:5: should omit comparison to bool constant, can be simplified to b (S1002)

Which is an advice that looks impossible to follow.
Great tool, BTW.

Will fix.


Code cleanup: avoid Expect(len(X))...

What this PR does / why we need it:
The gomega-idiomatic form
Expect(x).To(HaveLen(n))
is better than
Expect(len(x)).To(Equal(n))
because when the expectation fails, the tester sees the value of x, not
just its length, and has more information to debug it.
Similarly,
Expect(x).To(BeEmpty())
fails more clearly than
Expect(len(x)).To(Equal(0)).
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Release note:

NONE

/approve

Nice thanks
This PR gave me the idea to have a script where we can add some keywords and a message for static analyze,
for example
IF Expect && len && Equal Then Warn(please use Expect(x).To(HaveLen(n)) syntax instead)
(lets say it knows to find words like grep -w)
I believe there might a tool already that assist with various code styles of golang that we can use?

That's a great idea, currently, we have no automated mechanism that would prevent this pattern to again creep in.
There is golangci-lint, which seems to most popular at the moment, I haven't found such option in it, but it allows adding custom linters as plugins, so we could write our own.


Dev-Lite Test: CODAP + PSD 1.1.0-dev.2

Dev-Lite Test
Mentions: @samreid @catherinecarter
Simulation links

github repository for issues
wrapper + CODAP integration

Test Matrix

[x] Tester 1 (Tester =JD  , Platform = Win 11 chrome   , Time =2 {max 2 hours}
[x] Tester 2 (Tester = NS , Platform =  mac + safari/chrome, Time = 1.5 {max 2 hours}
[x] Tester 3 (Tester = KW, Platform = Win 11 Chrome, Time = 1)

Features included

[x] PhET-iO
[ ] Dynamic Locale
[ ] Alternative Input
[ ] UI Sound
[ ] Sonification
[ ] Description
[ ] Voicing

Focus and Special Instructions
Please test the following:

Collecting data for each of the available variables across different launchers/sample sizes
Checking and unchecking variables in the sidebar menu attached to the sim
Deleting variables by right-clicking the column on the CODAP table
Various combinations of 2 and 3 listed above
Checking/unchecking variables after some data has already been collected - Data should not be collected for a variable unless its box is checked when the projectile lands
Confirm that clicking save/export/make a copy in the CODAP menu will save the entire combined state of the sim + CODAP integration

Issues to Verify
There are no known issues to verify.

For QA...

General features

What to Test

Click every single button.
If there is sound, make sure it works.
Make sure you can't lose anything.
Play with the sim normally.
Try to break the sim.
Try to include browser version numbers
If there is a console available, check for errors and include them in the Problem Description.
Run through the string tests on at least one platform, especially if it is about to go to rc.
Check the Game Up harness on one platform.

PhET-iO features

What to Test

Make sure that public files do not have password protection. Use a private browser for this.
Make sure that private files do have password protection. Use a private browser for this.
Make sure standalone sim is working properly.
Make sure the wrapper index is working properly.
Make sure each wrapper is working properly.
Launch the simulation in Studio with ?stringTest=xss and make sure the sim doesn't navigate to youtube
For newer PhET-iO wrapper indices, save the "basic example of a functional wrapper" as a .html file and open it. Make
sure the simulation loads without crashing or throwing errors.

Accessibility features

What to Test

Specific instructions can be found above.

Make sure the accessibility (a11y) feature that is being tested doesn't negatively affect the sim in any way. Here is
a list of features that may be supported in this test:

Alternative Input
Interactive Description
Sound and Sonification
Pan and Zoom
Mobile Description
Voicing

Test all possible forms of input.

Test all mouse/trackpad inputs.
Test all touchscreen inputs.
Test all keyboard navigation inputs (if applicable).
Test all forms of input with a screen reader (if applicable).

Screen Readers
This sim may support screen readers. If you are unfamiliar with screen readers, please ask Katie to introduce you to
screen readers. If you simply need a refresher on screen readers, please consult the
QA Book, which should have all of the information
you need as well as a link to a screen reader tutorial made by Jesse. Otherwise, look over the a11y view before opening
the simulation. Once you've done that, open the simulation and make sure alerts and descriptions work as intended.

Platforms and Screen Readers to Be Tested

Windows 10 + Latest Chrome + Latest JAWS
Windows 10 + Latest Firefox + Latest NVDA
macOS + Safari + VoiceOver
iOS + Safari + VoiceOver (only if specified in testing issue)

Critical Screen Reader Information
We are tracking known screen reader bugs in
here. If you find a screen reader bug,
please check it against this list.

Keyboard Navigation
This sim supports keyboard navigation. Please make sure it works as intended on all platforms by itself and with a
screen reader.
Magnification
This sim supports magnification with pinch and drag gestures on touch screens, keyboard shortcuts, and mouse/wheel
controls. Please test magnfication and make sure it is working as intended and well with the use cases of the
simulation. Due to the way screen readers handle user input, magnification is NOT expected to work while using a screen
reader so there is no need to test this case.

FAQs for QA Members

There are multiple tests in this issue... Which test should I do first?
Test in order! Test the first thing first, the second thing second, and so on.

How should I format my issue?

We typically assign the developer who opened the issue in the QA repository.

My question isn't in here... What should I do?
You should:

Consult the QA Book.
Google it.
Ask Katie.
Ask a developer.
Google it again.
Cry.

Calling QA here


Add HTTP Basic auth

Right now, the only auth we have is OAuth2, which is definitely preferred for production. But HTTP Basic might be a nice "lowest common denominator" auth scheme.

The canonical format for a file that has HTTP Basic auth is the htpasswd format. But I think that uses MD5, which is a horrible idea.


WIP: Review make commands on Linux Arm64

Pull Request Motivation
Some make commands do not function on Mac M1 / Arm64 Architecture e.g. due to naming conflicts of variables used for checksum validation.
Kind
Bug
Release Note
NONE

I have a container with Ubuntu:22.04 kernel running as my dev-env on my Mac.
When trying to run make test I get errors like
make/tools.mk:377: warning: undefined variable 'KUBEBUILDER_TOOLS_linux_arm64_SHA256SUM'
./hack/util/checkhash.sh _bin/downloaded/tools/kubebuilder_tools_1.26.0_linux_arm64.tar.gz
./hack/util/checkhash.sh: line 24: $2: unbound variable
make: *** [make/tools.mk:377<EMAIL_ADDRESS>Error 1

This is why I started to rewrite how checksums are validated.
I assumed you might have had a reason for going with this hardcoded approach, so I wanted to check whether my approach works for you.
I am fine with changing directions and working on the update-* scripts to provide the required checksums in tools.mk. 🙂
I don't really like to install things on my system directly if I can go with containerised dev environments, so I would like to continue working on this instead of switching to using my Mac directly.

The PR description should really mention Linux arm64...

sure 🙂 I can see how this better describes the issue

We actually intentionally chose to hardcode the hashes though so that things would break "loudly" if an already-released artefact changed after being released. I'm not really sure if that's a thing we'd want to lose. It ensures that everyone's working with the exact same tools.

Is that a thing? Wouldn't that be released under a new version number?

The concern is an attack on the upstream which results in a rerelease.
–Or depending on where you get your archives from, detecting that the archive generation has changed: https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/

Thanks for clarifying about running in a container! Now that I understand we're talking about adding linux/arm64 I think I'd say that the easiest thing would be to add hashes for each dependency for linux/arm64 like KUBEBUILDER_TOOLS_linux_arm64_SHA256SUM=... and so on. It's a pain, but it should be pretty simple and should unblock you pretty quickly!
Totally understand the desire to use a containerised env and I think linux/arm64 support would be good to add - we've just not really had anyone around that wanted that as a development environment who could test it!

Is that a thing? Wouldn't that be released under a new version number?

Unfortunately it's a thing - some packages will release, say, version 2 and then notice a mistake, delete the old version 2 and release a new version 2. It's also something we have to consider for supply-chain security - if someone could intercept our request to download Helm or compromised the Helm download servers, they could backdoor it.

Alright 🙂
I will start working on that tomorrow. Thanks for the detailed explanation 🙇
I actually had a feeling my approach would be easier to intercept, it is good to have that suspicion confirmed :sigh

even though make test works now I only had to add like 4 shasums.
I will check more make-commands and further add to this PR, so this is not done yet.

When receiving this error message
cd _bin/tools/ && ln -f -s<EMAIL_ADDRESS>crane
cd _bin/tools/ && ln -f -s<EMAIL_ADDRESS>kind
cd _bin/tools/ && ln -f -s<EMAIL_ADDRESS>kubectl
cd _bin/tools/ && ln -f -s<EMAIL_ADDRESS>yq
❌  Error: the kind cluster kind isn't responding. Please run:
    kind delete cluster --name kind
and then retry.
make: *** [make/e2e-setup.mk:68: _bin/scratch/kind-exists] Error 1

it took me a moment to realise that kind actually exists as a binary under _bin/tools. Now that I know it is quiet obvious to me from the output, but changing the output to something that makes it a bit more clear could help out quiet a lot.
This PR is probably a bad place to put this discussion. Please let me know whether I should have opened that discussion at another place 🙂

now that I finally slew the signoff-beast 😅 ....
I am at a point where make e2e runs through but little over 300 tests fail, a lot of them due to timeout issues. I think that has to do with me running these tests in a container on a m1 MacBook Air.
Does that sound plausible to you folks? I am a bit at a loss thinking about other ways to test this. We should be fine for this PR, since the tests run through and it only is about making make commands fit for m1, but that just does not feels right ^^
I am not quiet finished yet as I have not run all of the make commands yet but I would appreciate your thoughts on that 🙂

a lot of them due to timeout issues. I think that has to do with me running these tests in a container on a m1 MacBook Air.

I suspect that's probably not the case. They shouldn't time out like that - often timeouts can be caused by a startup failure, e.g. the test needs Vault to be running but it failed to start for some reason so the test will wait until it times out. I would expect any M1 machine to be fast enough to run the tests.
I don't think we need all the e2e tests to pass on your machine for this to merge though! This is an improvement for some people even if the e2es don't pass locally, and since none of the active maintainers are using M1 (AFAIK) we can't really make it an officially supported development platform anyway!

The following make commands are tested inside an ubuntu:22.04 container running on a m1  mac and do work now

vendor-go
which-go
ci-presubmit
test-ci
verify-licenses
clean
e2e-build
e2e-setup-kind
e2e
integration-test
test
tidy
tricy-scan-all
unit-test
update-all
release-artifacts
release-manifests

I did not test

go-workspace
ko-deploy-certmanager
ko-images-push
release-manifest-signed
release
upload-release

make e2e stills throws a lot of timeout errors, which indeed are often depended on vault.

 Vault Error example
Apr 27 19:26:49.781: INFO: vault health failed: Get "https://<IP_ADDRESS>:35971/v1/sys/health?drsecondarycode=299&performancestandbycode=299&sealedcode=299&standbycode=299&uninitcode=299": dial tcp <IP_ADDRESS>:35971: connect: connection refused
  [FAILED] in [JustAfterEach] - /projects/cert-manager/test/e2e/suite/issuers/vault/certificate/approle.go:117 @ 04/27/23 19:26:50.497
  Apr 27 19:26:54.668: INFO: Got pod logs "e2e-tests-create-vault-certificate-7jczv/chart-vault-cm-e2e-create-vault-certificate-0-vault" for addon:
  ==> Vault server configuration:
           Api Address: https://<IP_ADDRESS>:8200
                   Cgo: disabled
       Cluster Address: https://chart-vault-cm-e2e-create-vault-certificate-0.chart-vault-cm-e2e-create-vault-certificate-internal:8201
 Environment Variables: CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_PORT, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_PORT_8200_TCP, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_PORT_8200_TCP_ADDR, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_PORT_8200_TCP_PORT, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_PORT_8200_TCP_PROTO, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_PORT_8201_TCP, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_PORT_8201_TCP_ADDR, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_PORT_8201_TCP_PORT, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_PORT_8201_TCP_PROTO, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_SERVICE_HOST, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_SERVICE_PORT, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_SERVICE_PORT_HTTPS, CHART_VAULT_CM_E2E_CREATE_VAULT_CERTIFICATE_SERVICE_PORT_HTTPS_INTERNAL, GODEBUG, HOME, HOSTNAME, HOST_IP, KUBERNETES_PORT, KUBERNETES_PORT_443_TCP, KUBERNETES_PORT_443_TCP_ADDR, KUBERNETES_PORT_443_TCP_PORT, KUBERNETES_PORT_443_TCP_PROTO, KUBERNETES_SERVICE_HOST, KUBERNETES_SERVICE_PORT, KUBERNETES_SERVICE_PORT_HTTPS, NAME, PATH, POD_IP, PWD, SHLVL, SKIP_CHOWN, SKIP_SETCAP, VAULT_ADDR, VAULT_API_ADDR, VAULT_CLUSTER_ADDR, VAULT_DEV_ROOT_TOKEN_ID, VAULT_K8S_NAMESPACE, VAULT_K8S_POD_NAME, VERSION
            Go Version: go1.20.1
            Listener 1: tcp (addr: "[::]:8202", cluster address: "[::]:8203", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
            Listener 2: tcp (addr: "[::]:8200", cluster address: "[::]:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
             Log Level:
                 Mlock: supported: true, enabled: false
         Recovery Mode: false
               Storage: inmem
               Version: Vault v1.13.1, built 2023-03-23T12:51:35Z
           Version Sha: 4472e4a3fbcc984b7e3dc48f5a8283f3efe6f282

==> Vault server started! Log data will stream in below:
2023-04-27T19:25:24.498Z [INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""
2023-04-27T19:25:24.506Z [INFO]  core: Initializing version history cache for core
2023-04-27T19:25:24.578Z [INFO]  core: security barrier not initialized
2023-04-27T19:25:24.607Z [INFO]  core: security barrier initialized: stored=1 shares=1 threshold=1
2023-04-27T19:25:24.632Z [INFO]  core: post-unseal setup starting
2023-04-27T19:25:24.712Z [INFO]  core: loaded wrapping token key
2023-04-27T19:25:24.712Z [INFO]  core: successfully setup plugin catalog: plugin-directory=""
2023-04-27T19:25:24.712Z [INFO]  core: no mounts; adding default mount table
2023-04-27T19:25:24.766Z [INFO]  core: successfully mounted: type=cubbyhole version="v1.13.1+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: "
2023-04-27T19:25:24.767Z [INFO]  core: successfully mounted: type=system version="v1.13.1+builtin.vault" path=sys/ namespace="ID: root. Path: "
2023-04-27T19:25:24.795Z [INFO]  core: successfully mounted: type=identity version="v1.13.1+builtin.vault" path=identity/ namespace="ID: root. Path: "
2023-04-27T19:25:24.807Z [INFO]  core: successfully mounted: type=token version="v1.13.1+builtin.vault" path=token/ namespace="ID: root.  Path: "
2023-04-27T19:25:34.425Z [INFO]  core: successfully mounted: type=identity version="v1.13.1+builtin.vault" path=identity/ namespace="ID: root. Path: "
2023-04-27T19:25:34.425Z [INFO]  core: successfully mounted: type=cubbyhole version="v1.13.1+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: "
2023-04-27T19:25:34.499Z [INFO]  core: successfully mounted: type=token version="v1.13.1+builtin.vault" path=token/ namespace="ID: root. Path: "
2023-04-27T19:25:34.507Z [INFO]  rollback: starting rollback manager
2023-04-27T19:25:34.507Z [INFO]  core: restoring leases
2023-04-27T19:25:34.507Z [INFO]  identity: entities restored
2023-04-27T19:25:34.507Z [INFO]  identity: groups restored
2023-04-27T19:25:34.508Z [INFO]  core: post-unseal setup complete
2023-04-27T19:25:34.508Z [INFO]  core: vault is unsealed
2023-04-27T19:25:34.508Z [INFO]  expiration: lease restore complete
2023-04-27T19:25:34.612Z [INFO]  expiration: revoked lease: lease_id=auth/token/root/h40e3dd69c11d10736febd618a8b3e00a3e118038d6e010fe2898e36cb0b2c3a3
2023-04-27T19:25:34.677Z [INFO]  core: successful mount: namespace="" path=secret/ type=kv version=""
2023-04-27T19:25:34.697Z [INFO]  http: TLS handshake error from <IP_ADDRESS>:45060: EOF
WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.
You may need to set the following environment variables:
  $ export VAULT_ADDR='http://[::]:8202'

The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.
Unseal Key: aeA0M9hO8UHD+n4tSohi+xEX5up+EsWi1zaOkKN/6KE=
Root Token: vault-root-token
Development mode should NOT be used in production installations!
2023-04-27T19:25:40.132Z [INFO]  http: TLS handshake error from <IP_ADDRESS>:42172: read tcp <IP_ADDRESS>:8200-><IP_ADDRESS>:42172: read: connection reset by peer
2023-04-27T19:25:52.159Z [INFO]  secrets.pki.pki_6561cdd4: 91ede0c5-d7cd-01ea-4287-81f045f279c4: succeeded in migrating to issuer storage version 2
2023-04-27T19:25:52.162Z [INFO]  core: successful mount: namespace="" path=root-ca/ type=pki version=""
2023-04-27T19:25:52.406Z [INFO]  secrets.pki.pki_079956a5: 76c70d17-cf5f-67f8-9ccf-abdc50b9298e: succeeded in migrating to issuer storage version 2
2023-04-27T19:25:52.457Z [INFO]  core: successful mount: namespace="" path=intermediate-ca/ type=pki version=""
2023-04-27T19:25:52.788Z [INFO]  core: enabled credential backend: path=approle/ type=approle version=""
2023-04-27T19:26:25.093Z [INFO]  http2: server: error reading preface from client <IP_ADDRESS>:39348: read tcp <IP_ADDRESS>:8200-><IP_ADDRESS>:39348: read: connection reset by peer
STEP: De-provisioning test-scoped addon @ 04/27/23 19:26:54.668
Apr 27 19:26:55.730: INFO: Expected Certificate test-vault-certificate condition Ready=True (generation >= 1) but it has: [{Ready False 2023-04-27 19:26:11 +0000 UTC DoesNotExist Issuing certificate as Secret does not exist 1} {Issuing True 2023-04-27 19:26:32 +0000 UTC DoesNotExist Issuing certificate as Secret does not exist 1}]
STEP: Deleting test namespace @ 04/27/23 19:26:57.79
<< Timeline

I would like to get rid of these errors to be able to test properly, but it feels like it has nothing to do with this issue.
What do you think @SgtCoDFish ?

/ok-to-test
/kind feature

I would like to get rid of these errors to be able to test properly, but it feels like it has nothing to do with this issue.
What do you think?

I don't see errors like this running on linux/amd64 and can't test linux/arm64 currently (although it's conceivable I could test on a 64 bit raspberry pi :thinking: )
This is a bit of a tricky one because I could totally see how the vault failures could be specific to your laptop, but it's also possible that they're caused by Vault on linux/arm64 somehow.
Could you leave this one with me until ~Tues next week and I'll have a think? Maybe I can get a Pi working to test this out!

/test pull-cert-manager-master-e2e-v1-27-upgrade

OK, I set up my pi4 with an arm64 OS but I'm afraid I couldn't get kind working properly and I've run out of time to try to get it working :upside_down_face:
In my case, kindnet wasn't even coming online at all because of a containerd error. Could be specific to a Pi, but I don't have the time atm to look into it more. If you can find any logs from Vault when you run locally that'd be super helpful!

/lgtm
/approve
Thanks for the debugging!
We've discussed this in our standup today and our consensus was to merge since it makes things better even if we can't confirm that the tests are 100% OK on linux/arm64.
I'll raise a website PR for this page which lists linux/arm64 support as experimental, since we can't realistically test it at the moment.
Thank you for this, it's much appreciated!


Bug with creating Overlays

Version Number
1.19
What branch are you on?
nightly
Describe the Bug
Hello
An error appears when creating overlays.
I have tried all possible versions, the error is the same.
Relevant Collection/Overlay/Playlist Definition
libraries:
  Фильмы:
    metadata_path:
    - pmm: basic
    - pmm: tautulli
    overlay_path:
      - reset_overlays: plex
      - remove_overlays: true
      - reapply_overlay: true
      - pmm: resolution                                                    # 1, 4
      - pmm: audio_codec                                                   # 2
      - pmm: mediastinger                                                  # 3
      - pmm: ratings                                                       # 5, 6, 7
settings:
  cache: true
  cache_expiration: 60
  asset_directory: config/assets
  asset_folders: true
  asset_depth: 0
  create_asset_folders: true
  prioritize_assets: false
  dimensional_asset_rename: false
  download_url_assets: true
  show_missing_season_assets: false
  show_missing_episode_assets: false
  show_asset_not_needed: true
  sync_mode: append
  minimum_items: 1
  default_collection_order:
  delete_below_minimum: true
  delete_not_scheduled: false
  run_again_delay: 2
  missing_only_released: false
  only_filter_missing: false
  show_unmanaged: true
  show_unconfigured: true
  show_filtered: false
  show_options: false
  show_missing: true
  show_missing_assets: true
  save_report: false
  tvdb_language: rus
  ignore_ids:
  ignore_imdb_ids:
  item_refresh_delay: 0
  playlist_sync_to_user: all
  playlist_exclude_users:
  playlist_report: false
  verify_ssl: true
  custom_repo:
  check_nightly: false
plex:                            # Can be individually specified per library as well; REQUIRED for the script to run
  url: http://<IP_ADDRESS>:32400
  token: ********************
  timeout: 60
  db_cache:
  clean_bundles: false
  empty_trash: false
  optimize: false
tmdb:                            # REQUIRED for the script to run
  apikey: ****************
  language: ru
  cache_expiration: 60
  region: RU
tautulli:                        # Can be individually specified per library as well
  url: http://<IP_ADDRESS>:8181
  apikey: ********************

Logs
https://gist.github.com/denozord/31c5871ab07a654e46397ee2f2a23077

I'm guessing you're running Plex 1.32.7 - it has this known issue, it has been fixed in the 1.32.8 beta, so you need to either downgrade or wait for 1.32.8 to go public

This is a regression on the Plex side that was introduced in Plex 1.32.7.  Plex has fixed it in 1.32.8.
Your options are:

downgrade to Plex 1.32.6
upgrade to the beta 1.32.8
add an "Overlay" sharing label to any one thing in the library.

Thx.

And how do I remove the word Movies from the genre name in collections? I've searched all over the wiki, but I can't find anything

Use the "name_format" template variable:
https://metamanager.wiki/en/latest/defaults/both/genre.html#template-variables


Provide an option to always show parent folder for files in tabs

VSCode Version: Version 1.6.0-insider (1.6.0-insider)
OS Version:

This is a fantastic feature for js devs - is there a way to always turn this on so all file tabs show the parent directory name not just when dupe filenames are open?
https://www.dropbox.com/s/oqgf7tdqg5vsm7b/Screenshot 2016-09-28 18.23.16.png?dl=0

Currently there is no setting for this.

Also interested in seeing this! Should it be a feature or extension?

seems a bit much to make it an extension.  i'd vote for a configurable option

Either a feature or an extension would be great... I have to say, for index files it'd I'd really love it if the parent folder name was emphasized over the "index" file name (e.g., if "index" was greyed out a bit)
This would really set apart vscode for me, as working in multiple index files requires a significant cognitive load

One of those things that not many people will think to search/vote for, but I think a lot of people would gain value from.

+1, especially useful for components like
/components/Button/index.js ;)

For reference, tabsTitleControl.ts#L272 would be the place to check for a config setting:
const description = label.hasAmbiguousName && label.description ? label.description : '';

I need this feature only for children folders of speciefed folder (for domain based structure of components).
Example
/components/Footer/Copyright.tsx > Footer/Copyright
/components/Footer/Contacts.tsx > Footer/Contacts
/components/Footer/Links.tsx > Footer/Links

An Atom plugin exists for this.  If someone makes an equivalent plugin for VSC first -- great -- if not, it'd be nice to see it become an editor setting.

#33718 provides a simple boolean configuration which controls whether tab descriptions are always shown.
A more complicated followup PR could provide a template system similar to window.title.

Replaced #33718 with #33815, which instead adds a simple template system.

Pushed the changes, a new setting "workbench.editor.tabSubtitle" allows to control this. If you pick short, medium or long, the tab description will always be visible and either show parent folder, workspace root relative path or full path.

Verification: play around with the workbench.editor.labelFormat setting and see that the description portion of the editor label in the tab well changes depending on the setting. Also verify for when tabs are disabled.

Going along with this I find myself getting confused by fuzzy find really
often here because it doesn't prioritize index.js files. Would be
dramatically helpful if it weighted those as high as regular files, and
highlighted them more clearly too.
On Thu, Sep 21, 2017 at 9:12 AM Benjamin Pasero<EMAIL_ADDRESS>wrote:

Verification: play around with the workbench.editor.labelFormat setting
and see that the description portion of the editor label in the tab well
changes depending on the setting. Also verify for when tabs are disabled.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/12965#issuecomment-331205407,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAvRIO9tBhDzhFVoCRLCiwdzxLIktMkks5skorhgaJpZM4KJfJ7
.


PubsubTableProviderIT.testSQLSelectsArrayAttributes[0] failing in SQL PostCommit

Failing since https://ci-beam.apache.org/job/beam_PostCommit_SQL/6260/

java.lang.AssertionError: Did not receive signal on projects/apache-beam-testing/subscriptions/result-subscription--1731534761628855545
in 60s
	at org.apache.beam.sdk.io.gcp.pubsub.TestPubsubSignal.pollForResultForDuration(TestPubsubSignal.java:341)
	at
org.apache.beam.sdk.io.gcp.pubsub.TestPubsubSignal.waitForSuccess(TestPubsubSignal.java:288)
	at org.apache.beam.sdk.extensions.sql.meta.provider.pubsub.PubsubTableProviderIT.testSQLSelectsArrayAttributes(PubsubTableProviderIT.java:256)

Imported from Jira BEAM-12320. Original Jira may contain additional context.
Reported by: bhulette.

There were fixes in https://github.com/apache/beam/pull/22612 so I will try to reproduce this.


Redirect to edit view after creating new model

This is less confusing for the user because they don't return to a list view which may not actually include the newly created model.
Changes view.create_model() to return the newly created model, including for all concrete backends.

This one is questionable. I see where it is coming from: with "Submit" button, action was well defined. With "Save" button it is logical to stay on the same page and use other means to get back to the list view (for example - with help of Cancel button).
I'll keep this one open (you can change your base class and template to get desired for your behavior) and would like to collect more feedback first.

Great, feedback is welcome. We could also make this configurable (since to implement this behaviour without this patch you have to re-implement both create_model and create_view which duplicates a lot of code.)
My motivation is that it's jarring to go back to a listing view that doesn't (potentially) even contain your newly created item. A use case we see a lot is that users want to create an item and then double check it, either because some fields are only filled in after creation or because they want to save a draft and then keep editing. As it stands, they have to save the new item and then find/search for it in the listing view to keep editing it.

I also think this is a good idea. Any objections if I merge?

I always use 3 buttons (I include in my customized theme)
[Save, Save and continue editing, Cancel]
This is how Django admin does, I think it is very nice

Guys, I think you got this and issue #884 pretty wrong. (And I would at least have expected a note about the change of behaviour in the 1.2.0 change log). The behaviour seems totally inconsistent to me.
Current unintuitive user experience:

Add a single new record: Create > Save > Cancel. Adding a new record must never ever end with a click on Cancel.
Add a new record: In this case, Save means: Just save and do nothing else (actually, it changes to edit view, but I bet that not a single user notices that. Also, what's the big difference between editing a new record vs. an existing one from the user's perspective).
Add a new record when can_edit = False: Now Save means again go back to List view. (And users won't check if they have edit rights or not when creating a new record, so this seems inconsistent for them)
Edit a record: After having learnt how the save button works for a new record, I would expect to stay on the edit page, but no, in this case, Save means: Leave the form and go back to list view.
Create and edit mode have 3 buttons each, but the middle one is different (Save and add vs. Save and continue) which is a bad user experience per se. Every normal user expects these buttons to work consistently. But no, Save and continue is for edit mode what Save is in create mode.
Another unexpected behaviour caused by the last point is that you click on Save while creating a new record ("just to save things for now"), then after that you want to click on Save and add - "huh - where did that button go?"

How does Django admin do it? i.e. how should it be done correctly?

Consistency:  No matter whether in create or edit mode, django has always the same 3 buttons: Save, Save and continue, Save and add. They always perform the same action no matter what. Save closes out the dialog and goes back to list view and the others are self explanatory. You may have been misguided here by the fact that the User table shows a non-default behaviour in that Save doesn't go back to list view directly but goes to the edit-in-detail page.
Now, since django admin doesn't have a Cancel or Close button, you always see the breadcrum menu list which allows you to back out. So for flask admin, either always show the List tab (also in edit mode) or introduce a Cancel/Close button somewhere which might end up in an overdose of buttons, though.

:+1: @fzumstein

@fzumstein Sounds good, any chance for the pull request?

Would love to, but I fear I am not very efficient at it :/

I can try to fix this, but I it will take some time because I am not able to work on this right now, maybe tomorrow or by this weekend.

+1 for harmonising the buttons across all the views, and making the buttons in the same positions do similar things across different views. Borrowing from Django works well for me.

@fzumstein I agree, the Create > Save > Cancel flow is not intuitive at all. Also, it would be great to have the same tabs on the edit page as on the add page. And harmonising the three buttons makes lots of sense.
Thanks for coming back to this issue. Looks like we might get a decent UX improvement out of it.

@fzumstein I'm planning to add tabs to the edit_view like this: http://i.imgur.com/LZO6tnu.png
I also want to change the text on the buttons. I'd like to do something similar to django grappelli's buttons: http://i.imgur.com/dPUYjwK.png (Delete, Save, Save and add another, Save and continue editing)
For the create_view, we could have a cancel button instead of the delete button.
Does that sound good?

@pawl I think this could work... is the Edit tab always visible or only when you click on the pencil to edit a record?

@fzumstein It's only visible when editing a record. I thought it looked odd without it: http://i.imgur.com/cpbOSlt.png
I saw the issue by @petrus-jvrensburg (https://github.com/flask-admin/flask-admin/pull/831#issuecomment-115265197) after my comment yesterday.
It's a good summary of what needs to happen:

It looks like the concensus is for three buttons on both the 'add' and 'edit' views:
Save, Save and continue, Save and add.

Furthermore, in stead of having an explicit cancel button, we'll display the same tabs from the 'add' view on the 'edit' view.

However, I would like to keep the cancel button since users are used to it, but I think we can keep it from looking crowded by aligning to the other side. I'd also like to change the text on the buttons.

sounds good to me then!
Am Sonntag, 5. Juli 2015 schrieb Paul Brown :

@fzumstein https://github.com/fzumstein It's only visible when editing
a record. I thought it looked odd without it:
http://i.imgur.com/cpbOSlt.png
I saw the issue by @petrus-jvrensburg
https://github.com/petrus-jvrensburg (#831 (comment)
https://github.com/flask-admin/flask-admin/pull/831#issuecomment-115265197)
after my comment yesterday.
It's a good summary of what needs to happen:
It looks like the concensus is for three buttons on both the 'add' and
'edit' views:
Save, Save and continue, Save and add.
Furthermore, in stead of having an explicit cancel button, we'll display
the same tabs from the 'add' view on the 'edit' view.
However, I would like to keep the cancel button since users are used to
it, but I think we can keep it from looking crowded by aligning to the
other side. I'd also like to change the text on the buttons.
—
Reply to this email directly or view it on GitHub
https://github.com/flask-admin/flask-admin/pull/831#issuecomment-118602118
.

Redirecting to edit view after creating a model isn't idiot-proof however: one of my users got confused and used the User edit form to "create 3 more user accounts" - well, we thought there was a strange session sharing bug when one user logged in to see the another user's name within the app.


fix(chart): Fix bugs ‘Older Dates with Year 1937 or less in charts is showing as NAN’

SUMMARY

I made modifications in two places to try to solve the problem.The problem may be that the time data transmitted by the backend to the front-end is a timestamp, but when the length of a number timestamp number is greater than 12 (excluding symbols) when the time is less than 1937, the front-end JSON conversion will become 'BigNumber' and cannot be directly converted into formatted form.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[x] Has associated issue:fixes #24561
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

How to obtain approval from maintenance personnel?

I can't speak to the code but appreciate you working on this!

I can't replicate https://github.com/apache/superset/issues/24561 on 3.0.0rc2, following the same steps I use to reproduce the behavior on 2.1.0.  Maybe closed by the PR that @justinpark flagged as related, https://github.com/apache/superset/pull/23339 ?  (though #24561 wasn't Trino-specific).
@wangkun723 are you able to try out 3.0.0rc2 release candidate version or the latest version from Github and see if the original bug has already been fixed?  If so then this PR could probably be closed.

我无法按照我在 2.1.0 上重现行为的相同步骤在 3.0.0rc2 上复制#24561 。也许被 PR 关闭了@justinpark标记为相关，#23339？（尽管#24561不是 Trino 特有的）。
@wangkun723您是否可以尝试 3.0.0rc2 候选版本或latest来自 Github 的版本，看看原始错误是否已修复？如果是这样，那么这个 PR 可能会被关闭。

It still exists

It seems that the issue this PR was attempting to solve is no longer an issue in current versions. That's probably how this slipped under the radar for so long... it's just not needed nowadays. If anyone is still experience the bug or sees a need for this PR, just say the word, so we can reopen it and see if it passes current CI. Thanks for the contribution!


remove unaligned references

As of Rust 1.62.0, compiling with the i686-pc-windows-msvc target gives the following warning:
warning: the following packages contain code that will be rejected by a future version of Rust: starship-battery v0.7.9
(...)
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 30`

Running the suggested command gives the following:
The package `starship-battery v0.7.9 (C:\Users\Clement\Documents\GitHub\rust-battery)` currently triggers the following future incompatibility lints:
> warning: reference to packed field is unaligned
>    --> src\platform\windows\ffi\mod.rs:120:36
>     |
> 120 |         let device_path = unsafe { (***pdidd).DevicePath.as_ptr() };
>     |                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     |
> note: the lint level is defined here
>    --> src\platform\windows\ffi\mod.rs:1:10
>     |
> 1   | #![allow(unaligned_references)]
>     |          ^^^^^^^^^^^^^^^^^^^^
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523>
>     = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
>     = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)
>
> warning: reference to packed field is unaligned
>    --> src\platform\windows\ffi\mod.rs:150:17
>     |
> 150 |                 &mut query.BatteryTag as *mut _ as minwindef::LPVOID,
>     |                 ^^^^^^^^^^^^^^^^^^^^^
>     |
> note: the lint level is defined here
>    --> src\platform\windows\ffi\mod.rs:1:10
>     |
> 1   | #![allow(unaligned_references)]
>     |          ^^^^^^^^^^^^^^^^^^^^
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523>
>     = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
>     = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)
>

which refers to https://github.com/rust-lang/rust/issues/82523.
This PR just changes out the unaligned references with the suggested fixes to silence the warning. I'm not 100% certain if this is the correct way of doing it and would appreciate a check by someone who's better versed at working with this stuff, but it does seem to work if I run the simple example included with the repo on my laptop.

Removed the mutable reference (preferring to just copy the value and update it afterwords as needed) and bumped MSRV across the project to 1.51.

btw feel free to squash the commits.

@ClementTsang Thanks for the contribution!


add link to ESLint CLIEngine docs, clarify use of envs

Thank you for creating and maintaining this very useful plugin!
I ran into some issues trying to get the envs options to work, and think that these additions will help clarify what is actually going on. Hopefully it will save someone else some time.

Much appreciated!


Fix a panic in Postgres revision parsing for incompatible ZedTokens

If Postgres is passed a ZedToken from CRDB, it will (incorrectly) interpret the token and try to create a slice with too much capacity. This change caps the delta on the transaction IDs and returns an error in that scenario
Fixes #1539

Are we sure it's a size issue, rather than an int vs float issue?
in our case, the similarly sized GhUKEzE2OTM1NDA5NDQ5NTk3MjA1OTI= does not cause the pre-change panic that GiAKHjE2OTM1NDA5NDAzNzMwNDU3MjcuMDAwMDAwMDAwMQ== does.

Yeah, its a capacity failure on trying to create a slice to track the overlap revisions. The panic occurs on a uint64, so it cannot be a float issue

Yeah, its a capacity failure on trying to create a slice to track the revisions. The panic occurs on a uint64, so it cannot be a float issue

The failing token GiAKHjE2OTM1NDA5NDAzNzMwNDU3MjcuMDAwMDAwMDAwMQ== decodes to \x1a \n\x1e1693540940373045727.0000000001
So if it's a size issue, we'd expect \x1a \n\x1e1693540940373045728 (GiAKHjE2OTM1NDA5NDAzNzMwNDU3Mjg=) to throw as well?

So if it's a size issue, we'd expect \x1a \n\x1e1693540940373045728 (GiAKHjE2OTM1NDA5NDAzNzMwNDU3Mjg=) to throw as well?

We would, except the lack of a decimal point means that it is interpreted as size 0. This is because legacy Postgres revisions were stored as a decimal representing a range, where X.Y was a range from Y->X.
In the case of the first revision given,<PHONE_NUMBER>373045727.0000000001 became<PHONE_NUMBER>373045727 -> 1 for a size of<PHONE_NUMBER>373045726. In your second example,<PHONE_NUMBER>373045728 became<PHONE_NUMBER>373045728->1693540940373045728, with a size of 0.
This is all because legacy Postgres revisions were stored in this particular format, and giving a CRDB revision that "just so happened" to hit the legacy parsing code perfectly

Ah, interesting on the postgres history, ty.
so here the second part of the decimal timestamp is correctly being parsed as an xmin candidate, and correctly assigned to xmin on L208, as if it was a postgres revision.
it's correct then to return the error at that point, not dismiss the float timestamp sooner.
thanks again!


Ontological connections

Currently, Ryven allows node connections to be made willy-nilly. It would be very nice to have strict type checking when connecting the I/O of two nodes, which could be done as a thin layer on top of Ryven. Following a Zoom call with Joerg, it would be ideal to leverage ontological developments inside pyiron to control these checks. Since getting pyiron to be fully ontological is a very big task, in the short term let's develop an ontological layer on top of the very narrow slice of pyiron for which we have ironflow nodes.
Desired behaviour:

Node connections between ports are impossible if the types do not match
Selecting an I/O port highlights all the available O/I ports in the graph which are valid connections
Selecting an I/O port activates some manner of "suggested node" menu, which shows nodes containing appropriate O/I ports

Catching up to the ontological work that's already been going on, and the architecting the ontology check so it's as loosely coupled to Ryven and the pyiron nodes as possible will all take some thinking time, so this feature won't be immediately available.

Idea: let the Result node have a dropdown/search window that lets you go through the ontology to select the class of value you are searching for. Then when you click on the input port to this node, the context-sensitive suggestion model shows you the selection of next-previous nodes necessary to accomplish your goal. This is merely a particular instance of Joerg's ontological goal of being able to write workflows in reverse, but I liked the UX of starting with the results node and how it integrates with our ideas about port highlights, so I wanted to make a quick note.

These ideas are implemented in #162, #163, #164, #165, #166, #168, #169, #170, and #172.


Enhancement: Validation styles for outlined fields

Hi!
The current validation looks like this:

Setting the border color instead would look much better:

I hope this will be included in a future release. Thanks.

The following styles solve the problem:
.mdc-text-field__input.invalid {
    border-bottom: none !important;
}

.invalid + .mdc-notched-outline > .mdc-notched-outline__leading, .invalid + .mdc-notched-outline > .mdc-notched-outline__notch, .invalid + .mdc-notched-outline > .mdc-notched-outline__trailing {
    border-color: red !important;
}

@kristof12345  thanks for finding a solution. Do you want to submit a PR on develop for this fix?

@enkodellc Ok. I tried to create a new branch, but I’m not allowed to push it. (This would be my first contribution to a public repo, so I might be doing something wrong. )
Another question: what do you use to compress the css to a single line?

@kristof12345 you do not have rights to create a new branch or push. You will need to Fork the repo on your account. Then submit a PR using your Fork, don't forget to change the branch to develop.
Once you submit a PR I can revew and merge it into Develop. I don't have rights to merge to master.
This will help:  https://opensource.com/article/19/7/create-pull-request-github
I know it is not super straight forward but it is a skill you will use in the future as you contribute more and it is an asset in your developer arsenal :)

Fix is in Develop Branch.


create test-runner-test and chalk-test packages to prevent circular dependencies at the package level

Add new .opam packages in order to prevent circular dependencies at the package level. Basically test-runner.lib references chalk.lib and chalk.test references test-runner.lib. chalk.lib and chalk.test were being built in the same package which caused a circular dependency with test-runner.lib.
As a consequence of this I'm also going to update the test-runner docs as well to encourage this pattern.
Addresses https://github.com/facebookexperimental/reason-native/issues/16

Great seeing this! It looks good to me but I'll leave it to someone else to approve it :)


x/tools/gopls: support language features for text/template, html/template

See discussion on https://github.com/microsoft/vscode-go/issues/228.

I was looking into this and noticed that Goland has IDE-level support for this. It requires the use of a comment to specify the embedded type.
{{- /*gotype: package/import/path.type_name*/ -}}.

I can't see a way to support language features without some sort of "type hint" for template files, so maybe this is something to consider making standard.
https://blog.jetbrains.com/go/2018/12/14/go-templates-made-easy/

@a-h it actually works quite nice even without these magic comments. I never used them. It has almost everything you expect when working with html templating languages out of the box.

Has there been any discussion what the default template file extensions should be?
I currently see the following suggestions in VS Code:

Go Template File - tmpl
Golang GO Template - gogo
Golang HTML Template - gohtml
Golang Java Template - gojava
Golang JavaScript Template - gojs
Golang JSON Template - gojson
Golang PHP Template - gojava
Golang Text Template - gotemplate
Golang TypeScript Template - gots
Golang YAML Template - goyaml

I think this is not the optimal approach. It would be more flexible to use a single extension to indicate that a file is a Go template with a pattern like filename.ext.gotmpl.
AFAIK all template files are text templates for Go with the exception of html. Extension scheme I proposed makes it obvious what the template filename should be and identifies go template files uniquely - .tmpl extension has other uses.

It should be configurable. In most of projects we used *.html for go templates. Once I saw .gohtml. And absolutely never .tmpl.
There actually was an issue where I mentioned these concerns @harvastum. It was quite some time ago, it may also be in old repo (which was owned by Microsoft at the moment).

Has there been any discussion what the default template file extensions should be?
I currently see the following suggestions in VS Code:
* Go Template File - `tmpl`

* Golang GO Template - `gogo`

* Golang HTML Template - `gohtml`

* Golang Java Template - `gojava`

* Golang JavaScript Template - `gojs`

* Golang JSON Template - `gojson`

* Golang PHP Template - `gojava`

* Golang Text Template - `gotemplate`

* Golang TypeScript Template - `gots`

* Golang YAML Template - `goyaml`

I think this is not the optimal approach. It would be more flexible to use a single extension to indicate that a file is a Go template with a pattern like filename.ext.gotmpl.
AFAIK all template files are text templates for Go with the exception of html. Extension scheme I proposed makes it obvious what the template filename should be and identifies go template files uniquely - .tmpl extension has other uses.

I agree this is certainly the most flexible, but can VS Code do something like layered syntax parsing where it is able to work with Go template syntax and YAML at the same time without creating a new language definition?

It should be configurable. In most of projects we used *.html for go templates. Once I saw .gohtml. And absolutely never .tmpl.

Yes, it obviously should be configurable. But defaults are powerful. People will use them, they will become convention and at some point, standard. This choice is pretty important.

This has soaked for a while as an experimental feature, and we should make it default.
But it sounds like we should expose some additional configuration before turning it on by default. @pjweinb WDYT?

what extra configuration? i think there's already an enabling/disabling
option.
On Fri, Nov 5, 2021 at 10:45 AM findleyr @.***> wrote:

This has soaked for a while as an experimental feature, and we should make
it default.
But it sounds like we should expose some additional configuration before
turning it on by default. @pjweinb https://github.com/pjweinb WDYT?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/36911#issuecomment-962092627, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJIAIZ26MO3HCRSKQVRQLDUKQQ4BANCNFSM4KN6JELA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

what extra configuration?

Just the file extension(s). Per @inliquid's https://github.com/golang/go/issues/36911#issuecomment-961245361:

It should be configurable. In most of projects we used *.html for go templates. Once I saw .gohtml. And absolutely never .tmpl.

FWIW, I've seen all of those, including .tmpl.  I think .tmpl or .gohtml is probably fine as a default, but it should be possible for users to configure it for codebases using different file extensions.
I suppose this doesn't need to block templates being enabled by default, since users can always disable if it doesn't work for them.
@pjweinb does that make sense? Any other concerns before moving this out of experimental?

i agree that people should be able to set the file extensions. (That
affects both gopls and vscode-go.) I'll do the gopls option when I get back.
On Fri, Nov 5, 2021 at 5:08 PM findleyr @.***> wrote:

what extra configuration?
Just the file extension(s). Per @inliquid https://github.com/inliquid's #36911
(comment)
https://github.com/golang/go/issues/36911#issuecomment-961245361:
It should be configurable. In most of projects we used *.html for go
templates. Once I saw .gohtml. And absolutely never .tmpl.
FWIW, I've seen all of those, including .tmpl. I think .tmpl or .gohtml is
probably fine as a default, but it should be possible for users to
configure it for codebases using different file extensions.
I suppose this doesn't need to block templates being enabled by default,
since users can always disable if it doesn't work for them.
@pjweinb https://github.com/pjweinb does that make sense? Any other
concerns before moving this out of experimental?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/36911#issuecomment-962287422, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJIAI7XIP2FBC6NS3MYG4DUKR5XDANCNFSM4KN6JELA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Forms / iOS: Build error after updating to beta 23

After updating to Mapsui 2.0 beta 23, I get the following error message if I try to build the project:
Error MT2101: Can't resolve the reference 'SkiaSharp.SKTypeface SkiaSharp.SKTypeface::FromFamilyName(System.String)', referenced from the method 'System.Void Mapsui.Rendering.Skia.LabelRenderer::UpdatePaint(Mapsui.Styles.LabelStyle,System.Single)' in 'SkiaSharp, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=0738eb9f132ed756'. (MT2101)

I don't get the build error. You are building on Mac?
SkiaSharp.Svg has no 1.68 release. That might have something to do with this.

https://github.com/mono/SkiaSharp.Extended/issues/68#issuecomment-462200821

You should your update your own SkiaSharp packages to 1.68.

the project

Is that Mapsui or your app?

Am I missed something? This error has nothing to do with the SVG package. It has to do with the SKTypeface implementation.
So 2.0 beta 22 worked and beta 23 not. Correct? If I‘m right, than @pauldendulk changed the Skia Package already in beta 22. Difference between both are only a small change in Mapsui.Forms.
I would say, that we should search the problem elsewhere. Perhaps it is really a problem with Skia package?

The SVG package references an older version of SkiaSharp. Updating might cause mixing up version. I do not actually think this is the problem but when investigating a bug I try to generate several hypotheses.

SkiaSharp was updated in beta 23. So, it is undoubtedly related to the update. The question is how.
https://github.com/Mapsui/Mapsui/releases

I have no updated the nuspec. That is probably it.

Sorry, I thought the update to 1.68.0 was bevor beta 22.
There are changes in SkiaSharp, because Skia removes font handling. They say, that this isn‘t a Skia problem. So SkiaSharp try to mimik the old behavior. Perhaps the problem is because of this?

Beta 24 was released with updated nuget dependencies. Let's see if this fixed the problem.

Yes, I built my iOS project on a Mac through a TFS build agent which also do the upload to ITC for me. Except for Mapsui, my app runs without SkiaSharp. Depending on the file changes when I updated the Mapsui package, I notice this one here in the iOS config file:
      <dependentAssembly>
        <assemblyIdentity name="SkiaSharp" publicKeyToken="0738eb9f132ed756" culture="neutral" />
        <bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="SkiaSharp.Views.iOS" publicKeyToken="0738eb9f132ed756" culture="neutral" />
        <bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>" />
      </dependentAssembly>

Maybe this causes the problem? I will try the latest beta release later today.

beta 25 was released.

This was an error in the nuspec which was fixed in 2.0.0-beta.25


Cuda out of memory error for ecalib and pics

I'm new to this MRI business, so I may be doing something totally crazy. Here is my code (part of it, anyway):
kspace = cfl.readcfl('data/{}'.format(filename))
sensitivities = bart(1, 'ecalib -g', kspace)

I get this error:
CUDA Pointwise Eigendecomposition...
ERROR: Error: ERROR: cuda error: 230 out of memory
Aborted (core dumped)
Traceback (most recent call last):
  File "sandbox.py", line 32, in <module>
    sensitivities = bart(1, 'ecalib -g', kspace)
  File "/home/chris/bart/python/bart.py", line 61, in bart
    raise Exception("Command exited with an error.")

The file is a 1 GB .cfl file (and the kspace array is just over 1 GB in memory). Is that too big? Here are my GPU specs:

It worked great without using the GPU. pics also works fine without the GPU, but dies with the same error.
The shape of kspace is (320, 288, 236, 6). I'm not sure what the last dimension is; can I somehow slim down the 4th dimension from 6 to 1 to help things fit? Maybe I'm going down the wrong road.
edit: I got my .cfl from here (the first entry): http://mridata.org/undersampled/knees
2nd edit: I tried using kspace[:,:,:100,:], but I get an error as well:
ERROR: invalid argument
Aborted (core dumped)
Traceback (most recent call last):
  File "sandbox.py", line 32, in <module>
    sensitivities = bart(1, 'ecalib -g', kspace)
  File "/home/chris/bart/python/bart.py", line 61, in bart
    raise Exception("Command exited with an error.")
Exception: Command exited with an error.

Hi,
I got same out of memory error previously. Dr. Martin Uecker told me to try 'rsense' . Currently, 'rsense' comes with limited regularization options, thus my solution is:

perform 1D ifft along Readout dimensions.
using gpu pics to recon 288x236x6 data (repeat 320 times).

The last dimensions 6 is channel dimension for parallel imaging, that is using 6 receivers of different sensitivities to do sampling. Thus you can't slim down the 4th dimension from 6 to 1.
Best wishes,

I haven't tested the GPU implementation of ecalib, so I can't comment on it.
As @siatjiasen said, you are running out of memory. If you are just interested in seeing if it's possible to run on the GPU, you could try to coil-compress the data to a smaller number of channels first using the bart cc command. But you will probably lose some accuracy.
If you want to go the slice-by-slice route and require more advanced options than are currently available through bart rsense, you can call bart pics in a loop. I suggest using the Grasp script as a reference.
In the future we will probably merge rsense and pics.


adding Kotlin

I request you to please make a label as reference which would comprise the resources that can be referred to get the names of the new programming language

I request you to please make a label as reference which would comprise the resources that can be referred to get the names of the new programming language

Done!

Thank You For Contributing!


[ci] Add GitHub actions to lint/test

Linting with pylint and black. We can talk about what exceptions we tolerate. Do we want to lint scripts as well?
For the unit test config, it's not fully tested but it should work.
I'm stuck with the requirements, how should we proceed? environement.yml is nice, I like it. But having a requirements.txt can be useful as well for non-conda users. What do you think about having requirements.txt and dev-requirements.txt and having them called in the environement.yml (with -r)? That would make a nice compromise IMO.
Codecov should be set up for asteroid but also not sure yet.

Do you know how conflicts between conda and pip are handled in the env file? e.g if pytorch is both in dependencies and pip? I guess that pip will just saw requirement satisfied but I'm not sure. In this case, it's fine to repeat numpy/pytorch/scipy in both deps and pip. WDYT?

Do you know how conflicts between conda and pip are handled in the env file? e.g if pytorch is both in dependencies and pip? I guess that pip will just saw requirement satisfied but I'm not sure. In this case, it's fine to repeat numpy/pytorch/scipy in both deps and pip. WDYT?

I've seen errors where the culprit was that numpy was somehow installed twice (probably by both conda and pip). Haven't had any other negative experiences with combining conda and pip though. Is it troublesome to use conda in Github Actions?

My guess is that setting up conda will take quite some time.
Also, how does it behave to install cudatoolkit on a CPU-only machine?

Maybe I'm missing something. How would you handle the deps specification between

conda env file
requirements.txt
setup.py
In particular, the versions are currently fixed in the conda env file (==), is this necessary? Would you also fix it in the setup.py?

Maybe I'm missing something. How would you handle the deps specification between
* conda env file

* requirements.txt

* setup.py
  In particular, the versions are currently fixed in the conda env file (`==`), is this necessary? Would you also fix it in the setup.py?

setup.py should not be very strict when it comes to ranges of versions.
Currently, environment.yml shows one of many possible combinations of package versions that should work. I think it makes sense to pin packages at least some packages for development and testing.
I've never worked on a project that had both environment.yml and requirements.txt. The reason why I prefer conda is that it's the only way I've been able to install pytorch with CUDA support on Windows.
In other packages, I've been handling dependencies in requirements.txt and setup.py separately. E.g. audiomentations has additional dependencies in requirements.txt and more strict version specs in requirements.txt compared to setup.py

My guess is that setting up conda will take quite some time.
Also, how does it behave to install cudatoolkit on a CPU-only machine?

I see. How about instead making a Dockerfile for running tests in Github Actions? That seems more feasible, doen't it?
Re cudatoolkit on a CPU-only machine: I've been doing RUN sed -i.bak "s|- cudatoolkit=10.1|- cpuonly|" environment.yml to deal with this

IDK, will we need ffmpeg during testing?

IDK, will we need ffmpeg during testing?

It depends. Do we need to load special audio file formats, like ogg/opus in testing?

No, I don't think we'll ned any of this. That's why I don't think it's worth it to setup conda for CI.
I'll add a req file in ./github/workflows with all what's needed for testing and we'll see how we handle deps later.

Ready to merge IMO


develop branch: Custom field warning is prompted multiple times when running the 'gen'

...
INFO: Field Confirmed Version is a custom field
INFO: Field Category is a custom field
INFO: Field Confirmed License is a custom field
INFO: Field Match Level is a custom field

The custom field warning prompt multiple times depends on how many resource it process.
If the input has 10 resources, then the above warning will prompts for 10 times.

Dup of #238


Concurrency

Dear Airflow Maintainers,
Before I tell you about my issue, let me describe my environment:
Environment

Version of Airflow: 1.7.0
Airflow components and configuration: CeleryExecutor, Redis for broker, MySQL for tasks
Operating System: Ubuntu 14.4
Python Version: 2.7.9

The issue:
We are using airflow to verify the data that is coming from the api. The api has limits (16 requests per second), so we are using concurrency parameter to limit the number of running tasks.
However, worker often creates more than 1 subprocess (normally 2) for a certain task. This behaviour is unpredictable, so we are not able to run things in parallel.
ps aux | grep airflow
/bin/sh -c airflow run /usr/bin/python /usr/local/bin/airflow run <task name> <args> --local -sd <dag path>
/usr/bin/python /usr/local/bin/airflow run <task name> <args> --local -sd <dag path>
/usr/bin/python /usr/local/bin/airflow run <task name> <args> --job_id <id> --raw -sd <dag path>

Is there any key setting I'm missing? Please advice.

Airflow will create multiple subprocesses for a task, but the task's execute() method should only be called one time (that includes the python_callable of a PythonOperator or the bash_command of a BashOperator.
What you may want to do instead is use a Pool. Pools limit the number of tasks no matter what your global concurrency parameters are.

you can use queue to control the concurrency issues. like rabbitmq

Closing for now. Please create Jira issue if needed. Please note that 1.7.1 will still be able to oversubscribe to Pools - this is a known issue and will be fixed in a later release.


Integ

@marcobonici tests now pass, problem with the CC integration is marked as todo but with rtol parameter it works with 10^-5.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 86.84211% with 5 lines in your changes missing coverage. Please review.

Files with missing lines
Patch %
Lines

src/integrals.jl
86.84%
5 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Files with missing lines
Coverage Δ

src/Blast.jl
100.00% <ø> (ø)

src/integrals.jl
86.84% <86.84%> (ø)

@marcobonici fixed :)

Added everything and checks pass 😎


Add Jenkinsfile to build plugin on https://ci.jenkins.io

Since builds on Cloudbees CI are disabled, I think it is good to build this plugin on Jenkins own CI. I've added this Jenkinsfile that should do the job, take a look at this example: https://github.com/jenkinsci/android-lint-plugin/blob/master/Jenkinsfile

It appeared here - https://ci.jenkins.io/job/Plugins/job/jobConfigHistory-plugin/
Build is failing now though.


sam0 DMA and UART bugfixes

Several bugfixes related to the sam0 platform when using async UART with DMA transfers.
4a4ae4f05378916ad87c5958f8850c97e481a2f7 fixes the issue in which the sam0 uart driver is loaded in PRE_KERNEL_1 as CONFIG_KERNEL_INIT_PRIORITY_DEVICE (default level 50) but when utilizing CONFIG_UART_ASYNC_API the dma device is not ready during init since it is only initialized in POST_KERNEL.
Changing the sam0 DMA driver to load during PRE_KERNEL_1 with CONFIG_KERNEL_INIT_PRIORITY_DEFAULT (default level 40) allows DMA to be ready.
c29519fd06f4d06b7000d7c8359bc48e5d37fc98 fixes the issue building without CONFIG_UART_INTERRUPT_DRIVEN causes a build failure since uart_sam0_err_check is guarded by the above define but .err_check is not.
e116aefcf3c58776dc4110a958c3dc6eabaf67b3 fixes the issue when using the async driver with the UART_TX_DONE event not occurring when TX is actually done.
The sam0 device generates a DMA interrupt when the DMA transfer from the TX ram buffer to the SERCOM DATA register is completed not when the data is finished being sent.
Therefore when the user callback is expecting all TX data to be completed the transfer is still ongoing and if UART_TX_DONE should trigger an external hardware event such as disabling a RS485 transceiver, data corruption will occur.
The following was tested with an ATSAMD21 device.

I changed from:
https://github.com/zephyrproject-rtos/zephyr/blob/fcfe597e5dadb96ecef5d6e8c82ffc99b5f4d59c/tests/drivers/uart/uart_async_api/boards/atsamr21_xpro.overlay#L1-L15
to:
&dmac {
	status = "okay";
};

&sercom0 {
	/* Configure DMA channels for async operation */
	dmas = <&dmac 0 1>, <&dmac 1 2>;
	dma-names = "rx", "tx";
};

&sercom3 {
	status = "okay";
	compatible = "atmel,sam0-uart";
	current-speed = <115200>;

	/* Internally loop-back TX and RX on PAD0 */
	rxpo = <0>;
	txpo = <0>;
	pinctrl-0 = <&pa17d_sercom3_pad1 &pa16d_sercom3_pad0>;

	/* Configure DMA channels for async operation */
	dmas = <&dmac 0 7>, <&dmac 1 8>;
	dma-names = "rx", "tx";
};

I'm still not get characters at console. I noted that a hard fault happen but I couldn' t get data on console.
@rocky134 , how did you conduct your test? Can describe it? I wondering if missing something.
Note:

This PR is passing CI because Zephyr is skipping SAM0 boards at tests/drivers/uart/uart_async_api/testcase.yaml.
Current pinctrl code requires pin definitions even for loopback interfaces. It is something that may require improvements.

I conduct more tests and noted that sam0 maybe is broke at main.
I restored to e49c7f1780 (random commit - 4 weeks ago - need bisect) and I got below:
*** Booting Zephyr OS build zephyr-v2.6.0-1658-ga7cdaf9ebf08  ***
Running test suite uart_async_test
===================================================================
START - test_single_read_setup
 PASS - test_single_read_setup in 0.1 seconds
===================================================================
START - test_single_read

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/uart/uart_async_api/src/test_uart_async.c:82: test_single_read: (k_sem_take(&rx_rdy, K_MSEC(100)) not equal to 0)
RX_RDY timeout
*** Booting Zephyr OS build zephyr-v2.6.0-1658-ga7cdaf9ebf08  ***
Running test suite uart_async_test
===================================================================
START - test_single_read_setup
 PASS - test_single_read_setup in 0.1 seconds
===================================================================
START - test_single_read

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/uart/uart_async_api/src/test_uart_async.c:82: test_single_read: (k_sem_take(&rx_rdy, K_MSEC(100)) not equal to 0)
RX_RDY timeout

small note for reference: c8cca16c20 - last commit that above test pass before regression (without rocky134 changes).
@rocky134, can you try run above tests and report to us?
BTW, thank you for your PR.

@rocky134 , how did you conduct your test? Can describe it? I wondering if missing something.

I first discovered this when data corruption was occurring when handling UART_TX_DONE in the callback I would drive a GPIO low to signify transmit complete to a RS485 half duplex transceiver.  After noticing the last byte would always be corrupted, under an oscilloscope I found that the GPIO would be driven low half way through the last byte being transmitted, to which I traced back the UART_TX_DONE event coming from the DMA transfer complete, not the tx completed.
Once I made the changes data corruption stopped occurring transmitting and receiving still worked, and I verified with an oscilloscope and system view that the sequence of events occurred in the right order. Then I was satisfied that the problem was fixed.
I added the following before taking the systemview sample.
--- a/drivers/serial/uart_sam0.c
+++ b/drivers/serial/uart_sam0.c
@@ -14,6 +14,7 @@
 #include <drivers/uart.h>
 #include <drivers/dma.h>
 #include <string.h>
+#include "SEGGER_SYSVIEW.h"

 #ifndef SERCOM_USART_CTRLA_MODE_USART_INT_CLK
 #define SERCOM_USART_CTRLA_MODE_USART_INT_CLK SERCOM_USART_CTRLA_MODE(0x1)
@@ -144,6 +145,7 @@ static void uart_sam0_dma_tx_done(const struct device *dma_dev, void *arg,
        SercomUsart * const regs = cfg->regs;

        regs->INTENSET.reg = SERCOM_USART_INTENSET_TXC;
+       SEGGER_SYSVIEW_MarkStart(0x4);
 }

 static int uart_sam0_tx_halt(struct uart_sam0_dev_data *dev_data)
@@ -673,6 +675,7 @@ static void uart_sam0_isr(const struct device *dev)

        if (dev_data->tx_len && regs->INTFLAG.bit.TXC) {
                regs->INTENCLR.reg = SERCOM_USART_INTENCLR_TXC;
+               SEGGER_SYSVIEW_MarkStop(0x4);

                k_work_cancel_delayable(&dev_data->tx_timeout_work);

I'm still not get characters at console. I noted that a hard fault happen but I couldn't' t get data on console.

yes, I noticed that too on the most recent main branch, my local branch I was working in was up to f3435b75efbfd7614ff873f8bfa90a031d6d27e8. One issue I had that was new was in pinmux.c muxa would not be ready since they're at the same initialization level. changing pinmux.c to init at PRE_KERNEL_2 fixed that problem.

@rocky134, can you try run above tests and report to us?

I ran the tests in zephyr/tests/drivers/uart/uart_async_api with the following device tree fragment,
&sercom3 {
	status = "okay";
	compatible = "atmel,sam0-uart";
	current-speed = <115200>;
	rxpo = <0>;
	txpo = <0>;
	dmas = <&dmac 0 0x08>, <&dmac 1 0x07>;
	dma-names = "tx", "rx";

	pinctrl-0 = <&pa23c_sercom3_pad1>, // rx pin
				<&pa22c_sercom3_pad0>; // tx pin
};

(I am using a custom board based off the atsamd21_xpro but using the ATSAMD21G17A instead. )
however I was not able to get the tests to pass either, same as your errors. both with and without my changes. I also tried changing
rxpo = <1>;

and physically soldered a wire between RX and TX but that did not pass either.
I tested the above on both the current main branch commit fcfe597e5dadb96ecef5d6e8c82ffc99b5f4d59c with my merge changes and a previous commit without any changes but I was not able to get the tests to pass.

Hi @rocky134,
The #38089 fixes init hard fault. Thank you for sharing solution.

It seems a bit strange how the line in this PR R144 causes a coding style compliance fail when other uses of this declaration at L249, L327 and L1057 were merged without compliance failures.

@rocky134 - are there any issues that can be linked to this PR? I believe the compliance failure may be a false positive. @galak, can you confirm?
@nandojve, can you please review?

are there any issues that can be linked to this PR?

As far as I know, there are not any open issues related specifically to this PR however it is still an issue with how async serial is being handled that needs to be fixed. As stated in the original post, handling UART_TX_DONE expecting transmission to be completed when it actually isn't yields data loss when used to disable the DE pin of a half duplex transceiver, similar to issue #38264.
I chose to create a PR with the fix rather than just open an issue since I already fixed the issue after discovering it. Creating this PR was an afterthought to share my fix with others.

@rocky134 - compliance failure is fixed, LGTM, but will still need one other review. @nandojve ?

@rocky134 - compliance failure is fixed, LGTM, but will still need one other review. @nandojve ?

Hi @cfriedt , I'll check this weekend.

@rocky134 ,
I was wondering if you could add below changes as two newer commits. One describes how proper configure DMA channels. The other one configure samr21 to pass at tests/drivers/uart/uart_async_api. The error happen because cells channel must be unique when configuring multiple peripherals. I mean, SERCOM0 uses 2 channels [0,1] and SERCOM3 should use 2 different channels [10, 11], for instance.
I think your PR fixes #35721 but need someone run tests on some SAME5x board CC: @stephanosio @arvinf ?
diff --git a/dts/bindings/dma/atmel,sam0-dmac.yaml b/dts/bindings/dma/atmel,sam0-dmac.yaml
index 5260e3624f..739065dbb3 100644
--- a/dts/bindings/dma/atmel,sam0-dmac.yaml
+++ b/dts/bindings/dma/atmel,sam0-dmac.yaml
@@ -14,6 +14,26 @@ properties:
     "#dma-cells":
       const: 2

+# #dma-cells : Must be <2>.
+# The 1st cell specifies the DMAC channel to be used for the data transfer.
+#   This channel should be unique between all peripherals that are using the
+#   DMAC instance.
+# The 2nd cell define the peripheral trigger which is source of the transfer.
+#   For details on trigger selection and trigger modes, refer to
+#   "Transfer Triggers and Actions".
+#   See the SoC's reference manual for all the supported request sources.
+#
+# Example of devicetree dma channel configuration:
+#
+# &sercom3 {
+#     /* Configure DMA channels for async operation */
+#     dmas = <&dmac 10 7>, <&dmac 11 8>;
+#     dma-names = "rx", "tx";
+# };
+#
+# In above fragment 10 and 11 represents the different channels used to
+# transfer data between peripheral and ram. The numbers 7/8 are, for instance,
+# uart_rx/tx peripheral trigger for sercom3.
 dma-cells:
   - channel
   - trigsrc
diff --git a/tests/drivers/uart/uart_async_api/boards/atsamr21_xpro.overlay b/tests/drivers/uart/uart_async_api/boards/atsamr21_xpro.overlay
index 8d39931188..e4df1a1fda 100644
--- a/tests/drivers/uart/uart_async_api/boards/atsamr21_xpro.overlay
+++ b/tests/drivers/uart/uart_async_api/boards/atsamr21_xpro.overlay
@@ -1,5 +1,15 @@
 /* SPDX-License-Identifier: Apache-2.0 */

+&dmac {
+       status = "okay";
+};
+
+&sercom0 {
+       /* Configure DMA channels for async operation */
+       dmas = <&dmac 0 1>, <&dmac 1 2>;
+       dma-names = "rx", "tx";
+};
+
 &sercom3 {
        status = "okay";
        compatible = "atmel,sam0-uart";
@@ -9,7 +19,10 @@
        rxpo = <0>;
        txpo = <0>;

+       /* PAD0 must be configured to allow loop-back works */
+       pinctrl-0 = <&pa16d_sercom3_pad0>;
+
        /* Configure DMA channels for async operation */
-       dmas = <&dmac 0 7>, <&dmac 1 8>;
+       dmas = <&dmac 10 7>, <&dmac 11 8>;
        dma-names = "rx", "tx";
 };

I was wondering if you could add below changes as two newer commits.

they have been added @nandojve

rebased PR to current main head per recommendation here https://github.com/zephyrproject-rtos/zephyr/issues/35721#issuecomment-922394760


Training segmentation model error - "too many synchronization issues, file not used in training data and to be fixed!"

We are trying to add some more training data and for some (but not all) files that we add as well as some of the files included from the start we get the following error when running ./gradlew train_segmentation
VARNING: 100.v84-264.training.segmentation.tei.xml / too many synchronization issues, file not used in training data and to be fixed!

I've looked through some of the files looking for the fixes to make but I can't find anything that stands out. Is there any way to see more information about the error?
Currently my hypothesis is that we've misunderstood the structure required by the model. We don't have any nested fields but everything is not covered by the other tags, such as body etc.
Example:
<tei>
	<teiHeader>
		...
	</teiHeader>
	<text>
		<note place="headnote">some note</note>
		<page>1</page> out of 200 <-- this text is outside of any other tag. Could this be the error?
		<body>
		    some body <lb/>
		     some more body
		</body>
	</text>
</tei>

Dear @karatekaneen,
for each document, there are two files associated to it (see the section "general principle"): https://grobid.readthedocs.io/en/update_header/training/General-principles/, one XML file and one feature file.
The error you are seeing is due to a missing synchronisation between those two files.
It is normal to have part of the data outside tags, but the format you are showing in the example is "strange". Usually, you don't have "teiHeader", as the structure is much flatter.
Could you share the whole training examples?

Hmm, so the error could be that we happened to modify the text by mistake maybe?
Here are the files:

Raw file
XML

For future readers; if the links are dead this is the xml and the raw file for 100.v84-264.training.segmentation.tei.xml that are included in this repo.

@karatekaneen I have a few questions.
The file that you sent me is already in the training repository, I wonder why did you try to modify it?
I also see that all the line break (<lb/>) and spaces have been modified.

(green = original, grey = yours)
Did you generate your XML and RAW file from the PDF or you just modify the original from the grobid-trainer repository?

I could have sworn that I did not modify the file but it's clear that it's not quite true.
I'm going to do a hard reset and rebuild of the project and this problem (at least for this file) will probably go away.
Is it correct to assume that the errors from the other files stemmed from that the file contents was modified?
Anyways, thanks for the help and thanks for the awesome project!

@karatekaneen I think you have an old version. I can see this file has been modified in april/may 2020 when we updated the various models. I think if you do a git pull you should be able to get the current version.


[TTT] Update repo url and add missing includes

Thanks for the PR, but going forward, this repository will use the newer TOML format for the rewritten docgen, the old one resides at https://github.com/rumblefrog/sp-manifest
The plan is to migrate to this one when the rest of the features are complete.


The result of evaluation.ipynb

Hello, I'm using this repo. I notice that the results in evaluation.ipynb  are not very consistent with the paper, especially the precision will be lower, why is this?
Thank you!

Data distribution could be one of the reasons. I didn't know how the authors categorized and split their data, so I did this with my best guess


Delete_repo

Description:
Create a new script called 'Delete_repo' that allows users to delete a repository on GitHub. This script will provide a convenient way for users to remove unwanted repositories without having to manually navigate to the GitHub website.
The 'Delete_repo' script is a Bash script designed to facilitate the deletion of repositories on GitHub. It provides a convenient command-line interface for users to delete repositories without having to navigate to the GitHub website. The script utilizes the GitHub API to authenticate the user and perform the necessary actions to delete the specified repository.

I am an active participant of the GirlScript Summer of Code (GSSoC) program and I would like to contribute to this issue. I believe it aligns well with my skills and interests.

@sahil-sagwekar2652 Please review this PR and merge it and give the relevant tag.
Thanks

@sahil-sagwekar2652 Any updatation required from my side??


Add colors to logging

Add colors for each level of log, probably using chalk

See commit: 7e349e15dfc2f5b1ec8a4b48c4cee03de7e9cecb


Add aggregate grade distribution GraphQL query

Bumping @ageor0114

@LEON-MING or @g-luo can you merge this in (i can't)


update virus_plowing.js

When I spawn a new virus, it will now get destroyed if it spawns on another sprite; before my if statements for destroying the new virus were wrong.
I also added some comments

Awesome! Great work.


Integrate All Steps with Object Storage

When the script is run want it to be able to pickup from previous failures.

With the download process after data is downloaded it is copied to object storage, immediately after
When the download process starts before it attempts to retrieve data from object storage first before going to its official sources
When processing starts, it determines what needs to be done based on what data exists in the object storage

started implementing this with the modis pipeline.  Requires knowledge of the input /output files from each process.  Due to the way the code is constructed this is going to be a bigger job then was initially anticipated.


Do you have a plan to release the  model checkpoint in the paper?

VERY NICE WORK!!!
It is really expensive to reproduce the model with the  same perfermance as the one in the paper,  So do you have a plan to release some the trained model checkpoint?
thank you.

I just want to ask too, thank you.@jiaw-z


Making the public API more familiar

The public API for streaming structs and newtypes could be made more familiar to users that come from other Rust crypto libraries.
In continuation of trying to make the streaming API more consistent (https://github.com/brycx/orion/pull/87) the general approach seems to be that all one-shot functions are also part of the struct (an example of this is the RustCrypto Digest trait). Maybe the current should be changed to:

module::one_shot_function() -> module::Ctx::one_shot_function()
module::verify() -> module::Ctx::verify()

For the newtypes API, to be more consitent with types throughout Rust, we chould change:

get_length -> len

Changing the newtype API seems worthwhile, but it's debatable whether changing the straming struct API will make a noticable difference in usability.

Can we clarify one thing? Is moving the functions from module to impl potentially more ergonomic, because you can now call ctx.verify etc? And it will be based on the type of ctx itself?

It will be based on the implementation of Ctx itself. Currently the module has the same name as Ctx, but this might change in the future if more variants of Ctx are added to the module, for example both SHA256 and SHA512 exist in a sha2 module, thus making a module-level verify() function confusing and will result in duplicate version of it at module-level.
ctx.verify will not exactly be available though, because verifying using incremental processing isn't provided, so it'll remain that you need to provide all the data at call: ``Ctx::verify()`.

Just for more information: we could technically add the new function and use a deprecated warning on the previous usage, right?

We could do that, but I don't think it makes much sense in this case. There is already a list of breaking changes coming up for the next major version bump. Marking these functions deprecated in the next major version would simply require another major version bump before they could be completely removed.
Aside from that, I personally don't feel marking functions as deprecated really does any good. For example, orion will fail to compile if any warnings are issued by the compiler, which will happen if one of its dependencies deprecates something (this happened with getrandom recently) and thereby break orion. So it'll depend on users whether deprecation is breaking or not.

Gotcha! The approach sounds good to me.

Fixed in #107.


Named parallelism limits

FEATURE REQUEST:
I propose to have named parallelism, and by that I mean the ability to define several parallelism limits, and let different templates define which parallelism limit it consumes.
Why
We have several different tasks scattered around in the workflow which consume some limit resource, e.g. a database with limited capacity. We want maximum parallelism in general, but have a global limit of e.g. 10 to the database so it does crash. The different tasks does not fit after each other in a steps list.
Concrete proposals
I have 3 different proposals, in increased complexity
Proposal 1
Each task consumes a single parallelism-limit:
spec:
  parallelism-limits:
  - name: influx-limit
    value: 10
  - name: sql-limit
    value: 4
  templates:
  - name: some-thingy-which-needs-influx
    parallelism: influx-limit   # 10 of these can run at the same time
...

Proposal 2
Each task can consume 1 of several limits:
spec:
  parallelism-limits:
  - name: influx-limit
    value: 10
  - name: sql-limit
    value: 4
  templates:
  - name: some-thingy-which-needs-both-influx-and-sql
    parallelism:
    - influx-limit
      sql-limit # So at most 4 of this task can run at the same time
...

Proposal 3
Each task can consume x of several limits:
spec:
  parallelism-limits:
  - name: influx-limit
    value: 10
  - name: sql-limit
    value: 4
  templates:
  - name: some-thingy-which-needs-both-influx-and-sql-and-a-lot-of-influx
    parallelism:
    - influx-limit: 3 # at  most 3 of these can run at the same time
    - sql-limit:1
...

I'm not sure if this is relevant, but I'd be quite interested in a global limit that works across workflows if that isn't already possible. That is, submitting two workflows, and having them essentially share a semaphore.

This sounds like #2550 . Closing and duplicate.


Update CLI usage for IDReusePolicy: TerminteIfRunning

What changed?
Update CLI usage for IDReusePolicy: TerminteIfRunning

Why?
It's missing

How did you test it?
Local test

Potential risks
No

Coverage decreased (-0.005%) to 66.794% when pulling 84d8246ba7867c884cb21e1d3f135a65d92c1d11 on qlong-cli-usage-terminate-if-running into 28fd61d8e83e0439476b57b37527b4a1c9bc51a0 on master.


Please invite me to the GitHub Community Organization

Name
rajel718
Discord Username (if applicable)
No response
Additional Context
Hello, everyone.
As a senior web developer, I would like to join in your community.
Thanks.

Welcome to ChryzHub @rajel718  🎉🥳


Checks for mistress file

Need to add checks for the mistress file when it is returned.

Standard checks already implemented in R

Columns with coded values must only contain exactly those values

Looks like much of the issue with coded values is caused by different capitalisations.
I propose we chose to have everything coded in lowercase and then pass mistress values through a lowercase function. This will leave only this issue of misspelled coded values which is less prevalent.

Component of #19

These should be identical checks to the master and output dataset.


Add a "related projects" section

As per the discussion in #425, it could be interesting to list LaraDock related projects in the docs.
LaraDock-related projects:

laradock-cli - https://github.com/logaretm/laradock-cli
laradock_env - https://github.com/bagart/laradock_env

Other Docker stacks:

magedock - https://github.com/ojhaujjwal/magedock
rubydev-dock - https://github.com/scudelletti/rubydev-dock

This should help promote other projects as well as LaraDock.
What do you guys think?

Awesome let's do this :D


Proselint and standard vars

This pull request introduces two things:  the concept of a set of "standard linter variables" and functionality, and a central means to define a proselint linter.  Both of these come out of work I've been doing to more capably support running linters inside containers, yet are sufficiently generic so as to be generally useful.  This PR is intended to introduce these ideas, and open things up for discussion.
The standard functionality introduced is aimed at making certain common things -- for now, executable and options -- easy.  Using a function like ale#linter#util#SetStandardVars() ensures that every calling linter can be expected to have these variables defined, and makes it easy to introduce new variables (e.g. ...image, ..._use_docker, etc) without having to go back and touch each linter.
The standard vars introduced here are:

g:ale_{ft}_{linter}_executable
g:ale_{ft}_{linter}_options

These variables have been slowly making their way into a significant number of linters, completely independent of this PR.
Documentation of these variables is centralized -- no sense in copy and pasting the same docs everywhere.  Linters using this setup can refer to the general documentation from their specific help text; e.g. the proselint linter converted does just that.
Note that the neovim tests will fail until #806 is merged and the image rebuilt.

No. There's no need to write some functions to wrap defining the options. Defining them is one of the easiest things to do. Documenting them requires more effort, and there's no way to avoid that, as the documentation is required.
There's no point in wrapping the existing code for defining linters in more generic code which won't have much use. I'd rather copy and paste the GetExecutable and GetCommand functions into different files. They typically don't remain so simple for very long. Many linters offer many different options and behave in various useful ways.
We can't use lambda syntax in the codebase yet, as NeoVim 0.1.7 is supported as a minimum, and will be supported until 0.20 becomes more common.


Add Poland flag

@Mati365 This looks great but we have already received 2 PRs for this. I will keep this open just in case others collapse.
Keep contributing. :smile:

@Mati365 Previous PR was merged, so this is a duplicate. I'm closing this. Keep contributing! :smile:


React missing common.min.css

agnostic-react/dist/common.min.css appears to be missing in dist:
https://github.com/AgnosticUI/agnosticui/tree/master/agnostic-react/dist

Fixed


rpc docs: remove docs for EOL versions

Removes the RPC documentation for 0.16.0, 0.16.1, 0.16.2, 0.16.3, 0.17.0, 0.18.0, 0.19.0, 0.20.0.
Keeps 0.21 for now as it's only just gone EOL (happy to remove if preferred).
24.0 should be added shortly.

Would it be difficult to keep these? Agree cleanup and reducing the amount of things to maintain is good, but I must admit that there are a few links to RPC docs in the review club website, e.g. here.

Ok. Will leave these as-is for now. Maybe we should add some/all of the missing versions?

Issue about potentially adding docs for older versions https://github.com/bitcoin-core/bitcoincore.org/issues/921#issue-1448836204


Add a github action flow to support Tekton build

Fix https://github.com/redhat-buildpacks/testing/issues/9

cc @cmoulliard


Revise Share plan page

UX wireframe @JEK-III - http://h90c3m.axshare.com/#g=1&p=write_plan
Related issues for other write plan tabs #494 #495

Add plan visibility settings to top of page; blue notepad mentions outstanding need to determine threshold for adding "public" and "org" DMPs to list - TBD
Revise Manage collaborators table
Revise Invite collaborators section

The plan visibility section should be copied over from the edit plan details page. This section should be disabled if plan.is_test?.

Just need to wire up the JS logic for the visibility section.

Functionality works as expected w/exception of related issue #516 for test plans
@JEK-III please confirm or add to the list of style changes:

Remove boldface for field names
Remove colons for field names
Align everything on this page w/the "Add collaborator" button at the bottom (so all headings, text, table should shift to the right
Font size for headings should be smaller (refer to wireframes)

There are still colons when sharing a plan but I guess these may be addressed as part of global styling so safe to close out here?
I also wonder if we should change 'Read Only' to lower case 'o' since that seems to be our norm elsewhere
Page looking good though

I concur w/ @sjDCC suggestions above re

removing boldface and colons
and changing to "Read only"

These are documented in the general styling ticket so maybe only the second item needs to be addressed here.

@JEK-III and @briri - please update wireframe and application to say "Read only"
@briri - align all elements on this page per wireframe (to the inner rule established by the radio buttons and Email box below)

Need to change the logic of when the visibility section is enabled. We are now requiring that 50% of the plan's questions have an answer before allowing that section to be enabled. See the new Help documentation for details: https://docs.google.com/document/d/12MH0c8ow1gQ8_tvE1T02DUYYEys6gaMiEF_hmaLxyQY/edit#heading=h.vre1agcio86y

closing. work was completed prior to Bootstrap


国内模型镜像

非常有意思的工作，但是huggingface 最近总是连接超时，是否可以放一个国内可以下载的链接呢。

The Model runs through Llama.cpp for GGUF files, available at https://huggingface.co/Green-Sky/TinyLlama-1.1B-step-50K-105b-GGUF/tree/main
theres also a vLLM colab, at https://colab.research.google.com/drive/1StFCIjMYt2GwOktHSY1D2aNxhxVR4W-e?usp=sharing

translation for OP's post:
"Very interesting work, but HuggingFace has been timing out recently. Can you provide a link that can be downloaded in China?"
我不太清楚国内一般用什么平台，你有什么推荐吗？
I am not quite sure what platforms are commonly used in China. Do you have any recommendations?

@jzhang38 Thanks, google translate gave me similar, but the exact, gave the best answer I could. I guess The Llama.cpp and vLLM parts are still Valid, but is there a link outside Huggingface?

https://modelscope.cn/datasets没有相应的数据集，是否可以考虑放一个

最近https://huggingface.co无法访问

Depending on the license, torrents or ipfs might be an option.

Hello, @Ma-Yongqiang and @hjing100, I have uploaded the latest checkpoints to modelscope. You can now download them and have fun using the following links: https://www.modelscope.cn/models/chaoscodes/TinyLlama-1.1B-intermediate-step-240k-503b/ and https://www.modelscope.cn/models/chaoscodes/TinyLlama-1.1B-Chat-v0.1/.

Hello, @Ma-Yongqiang  and @hjing100 , I've uploaded the latest checkpoints to modelscope. You can now download them and have fun using the following links:
TinyLlama-1.1B-intermediate-step-240k-503b
TinyLlama-1.1B-Chat-v0.1

thanks for your hard work ~ @ChaosCodes

https://modelscope.cn/datasets没有相应的数据集，是否可以考虑放一个

严重支持！