Losing end of link text when using commas

[Bug]
When link text includes a comma, everything after the comma is removed from link text when using asciidoctor-epub3. This doesn't happen when generating standard html  / xhtml out of AsciiDoctor.
https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone[Well-known Labels, Annotations and Taints, `topology.kubernetes.io/zone`]

becomes this out of asciidoctor-epub3:

Well-known Labels

Regular Asciidoctor generates:

Well-known Labels, Annotations and Taints, topology.kubernetes.io/zone

Hmm... The text is getting swallowed here...

Hmm... The text is getting swallowed here...

@mojavelinux this looks like a total bug to me in core... It is doing regexes on converted text (???). When we arrive at that line, link_text is "Well-known Labels, Annotations and Taints, topology.kubernetes.io/zone".

Found docs, thanks: https://docs.asciidoctor.org/asciidoc/latest/macros/link-macro-attribute-parsing/#link-text-alongside-named-attributes

1. Using double quotes
https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone["Well-known Labels, Annotations and Taints, `topology.kubernetes.io/zone`"]

becomes:

"Well-known Labels, Annotations and Taints, `topology.kubernetes.io/zone`"

Where code markup isn't converted.
2. Using double quotes only around the text itself and not the topology.kubernetes.io/zone
https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone["Well-known Labels, Annotations and Taints," `topology.kubernetes.io/zone`]

Or using a combo with a ^:
https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone["Well-known Labels, Annotations and Taints,^" `topology.kubernetes.io/zone`]

Yields:

Well-known Labels, Annotations and Taints,

**3. Using the carat at the end gives: **
https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone["Well-known Labels, Annotations and Taints, `topology.kubernetes.io/zone`^"]

Well-known Labels, Annotations and Taints, <code class=

4. Placing just a carat at the end of the link text:
https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone[Well-known Labels, Annotations and Taints, `topology.kubernetes.io/zone`^]

Is the same as the original problem:

Well-known Labels

All that to say, trying to do this with commas and literal / code generating backticks may just be too much. I'm surprised that it works fine in AsciiDoctor's generation of html / xhtml but not here in the epub3 generated xhtml.

I'm not convinced by the docs though... There is no
= in document itself. Subtitutionss operate on converted content where = was injected by the converter.

It is doing regexes on converted text (???).

This is extremely well known and won't be changed until the AsciiDoc Language specification is changed (as it is one of the key reasons why we are doing the specification).

I'm surprised that it works fine in AsciiDoctor's generation of html / xhtml but not here in the epub3 generated xhtml.

That happens because html converter inserts ..., while epub inserts ... and that = explodes the thing. I guess we could stop adding class="literal" and your particular case will be fixed, but I believe there are numerous other ways to end up with = in markup inside the link.

The issue here is that the EPUB 3 converter adds a CSS class to the code span. The double quotes around the CSS class name interfere with the double quotes around the link text. So this is just one of those edge cases in AsciiDoc that require a workaround.
The simplest workaround is to use a passthrough.
https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone[pass:n[Well-known Labels, Annotations and Taints, `topology.kubernetes.io/zone`]]

I'm surprised that it works fine in AsciiDoctor's generation of html / xhtml but not here in the epub3 generated xhtml.

As Marat pointed out, it's because the EPUB 3 converter doesn't produce the same HTML as the built-in HTML converter. And the extra markup it uses introduces a conflict.

I see! I will use the passthrough method to workaround this. Thank you both!


NodeSelector "compatibility" to select EKS master nodes IP on NetworkPolicies

Antrea 1.6 brought a great feature that allows network policies to target nodes.
That allows for example have a single net policy rule that make PODs labeled with some label be able to connect to the API without knowing previously the IP of the kubernetes master nodes while keeping a default deny policy for the cluster.
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: require-api-can-connect-api
spec:
    priority: 99
    tier: Emergency
    appliedTo:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          requires-api:  "true"
    egress:
    - action: Allow
      enableLogging: true
      to:
      - nodeSelector:
          matchLabels:
            node-role.kubernetes.io/control-plane: ""
      ports:
        - protocol: TCP
          port: 6443

From the documentation , that nodeSelector  adds the Node IPs to the rule's destination address group.
It would be nice if there is a way to create that same kind of rule for environments where the masters "are not" nodes. Like in EKS for example.
Some kind of EndpointSelector, so I could create a rule that would add the endpoints from kubernetes.default service in the default namespace to the addressgroup used in the policy.

@jsalatiel If your Pods access kube API via service address, perhaps toServices can meet your requirement: https://github.com/antrea-io/antrea/blob/main/docs/antrea-network-policy.md#acnp-for-toservices-rule
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: require-api-can-connect-api
spec:
    priority: 99
    tier: Emergency
    appliedTo:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          requires-api:  "true"
    egress:
    - action: Allow
      enableLogging: true
      toServices:
      - name: kubernetes
        namespace: default

I think that most webhooks (nginx ingress for example) connect to the api server directly through the endpoints, not the services, but i am gonna check that out.

I guess they connect to service, otherwise all these components need to watch endpoints API themselves and implement an client side loadbalancing, which is kube-proxy/antrea-proxy is designed to avoid.

@tnqn  You are right! thanks!
Another single question, is there a fromService?
Use case: I can connect to the api using the:
toServices:
      - name: kubernetes
        namespace: default

But how can I point the control plane IP  in EKS as from in a net policy rule?
The IPs are the endpoints' IP  for kubernetes.default service in EKS.
On prem I can just add the nodeSelector for the masters label.

Closing this in favor of #3805


Avg stdev cast double

Basically, I think we want the semantics of things like average to be defined by MyriaL rather than by the backends. That is more like the "write once, run anywhere" model we want for Raco.
As a start, make AVG and STDEV force-insert casts to doubles. However, this breaks the tests.
@7andrew7 pretty unhappy with this hack, any suggestions? I noticed you had a note that you did not want to force semantics in MyriaL, so I thought maybe I'd let you ring in..

@7andrew7 @dhalperi what is the status of this issue? Can it be closed and marked as a discussion thread? Or should it be merged?


Bug on Save when tickbox unchecked

When Tickbox for disclaimer not ticked and new repair saved it looks like it has saved but cannot be found in the list.
Would be better to prompt for tick or at least error ?

Hi @L1ndaR  can you confirm which form you were using when you hit this issue-
Was this when you were checking in at an event, or when you were adding an item yourself to an event in the normal way?

Thanks. Ok will check it out!

Cannot replicate on either method to add item.
Closing until more info can be obtained.


refactor(app): Support 802.1X networks in new Wi-Fi form

overview
This PR updates the wi-fi connect modal added in #2515 and adds the 802.1X methods and sub-options from the GET /wifi/eap-options endpoint.
Closes #2412, closes #2413
TODO: add a gif here
changelog

refactor(app): Support 802.1X networks in new Wi-Fi form

refactor because functionality is still behind a feature flag
Made a docstring only change in the API, because the docs for /wifi/configure were incorrect

review requests
Please see tickets for additional acceptance criteria. Also, please note that certificate credentials are will not be supported until #2415.

Launch app with new connection card enabled
make -C app dev OT_APP_DEV_INTERNAL__MANAGE_ROBOT_CONNECTION__NEW_CARD=1

Select an 802.1X network

If you're in the office, hit me up for network credentials

Type in the credentials

[ ] 802.1X modal displays all the different fields for the different EAP types
[ ] Required fields are marked with * and are at the top of the list
[ ] Modal scrolls if options overflow the modal
[ ] Robot connects to network with spinner

Addressing @sfoster1 and @IanLondon's sort concerns. I don't want to change the API response shape because back-compat is nice, but I will be:

Continuing to try to sort required fields up top
If a type: 'file' input has a matching type: 'password' field, always place it directly after the file input

This will add the requirement to the API that all file associated passwords start with the full name of the file field
This is already true of the existing response
Even if the password field is optional (which I think they all are), it could sort before other required fields


Axum askama htmx example does not work

as the title says the example does not work.
here is the compile output
error: template "counter_component.html" not found in directories ["C:\\Users\\klownie\\Documents\\Art\\PortofolioWebsite\\turfAskamaTest\\templates"]
 --> src/main.rs:3:10
  |
3 | #[derive(Template)]
  |          ^^^^^^^^
  |
  = note: this error originates in the derive macro `Template` (in Nightly builds, run with -Z macro-backtrace for more info)

error: template "counter_component.html" not found in directories ["C:\\Users\\klownie\\Documents\\Art\\PortofolioWebsite\\turfAskamaTest\\templates"]
 --> src/main.rs:9:10
  |
9 | #[derive(Template)]
  |          ^^^^^^^^
  |
  = note: this error originates in the derive macro `Template` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `{closure@src/main.rs:20:25: 20:27}: Handler<_, _>` is not satisfied
   --> src/main.rs:20:25
    |
20  |         .route("/", get(|| async { HelloTemplate { count: 0 } }))
    |                     --- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Handler<_, _>` is not implemented for closure `{closure@src/main.rs:20:25: 20:27}`
    |                     |
    |                     required by a bound introduced by this call
    |
    = note: Consider using `#[axum::debug_handler]` to improve the error message
    = help: the following other types implement trait `Handler<T, S>`:
              `Layered<L, H, T, S>` implements `Handler<T, S>`
              `MethodRouter<S>` implements `Handler<(), S>`
note: required by a bound in `axum::routing::get`
   --> C:\Users\klownie\.cargo\registry\src\index.crates.io-6f17d22bba15001f\axum-0.7.7\src\routing\method_routing.rs:385:1
    |
385 | top_level_handler_fn!(get, GET);
    | ^^^^^^^^^^^^^^^^^^^^^^---^^^^^^
    | |                     |
    | |                     required by a bound in this function
    | required by this bound in `get`
    = note: this error originates in the macro `top_level_handler_fn` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `{closure@src/main.rs:23:17: 23:41}: Handler<_, _>` is not satisfied
   --> src/main.rs:23:17
    |
23  |             get(|Path(count): Path<u64>| async move { CounterTemplate { count } }),
    |             --- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Handler<_, _>` is not implemented for closure `{closure@src/main.rs:23:17: 23:41}`
    |             |
    |             required by a bound introduced by this call
    |
    = note: Consider using `#[axum::debug_handler]` to improve the error message
    = help: the following other types implement trait `Handler<T, S>`:
              `Layered<L, H, T, S>` implements `Handler<T, S>`
              `MethodRouter<S>` implements `Handler<(), S>`
note: required by a bound in `axum::routing::get`
   --> C:\Users\klownie\.cargo\registry\src\index.crates.io-6f17d22bba15001f\axum-0.7.7\src\routing\method_routing.rs:385:1
    |
385 | top_level_handler_fn!(get, GET);
    | ^^^^^^^^^^^^^^^^^^^^^^---^^^^^^
    | |                     |
    | |                     required by a bound in this function
    | required by this bound in `get`
    = note: this error originates in the macro `top_level_handler_fn` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.
error: could not compile `axum-askama-htmx` (bin "axum-askama-htmx") due to 4 previous errors

nvm it does work
the error message is just misleading


MultiCharacter Support / Blue Circle Disappears

It would be nice to see multicharacter support in this script, specifically with kashacters. Currently, you can have multiple characters and buy different businesses but sometimes the blue circle will disappear for players even though they're on the correct account. The current fix I found for this was just doing /business reload and the circle would show back up.

I'm not planning to do multichar support.


binary symlinks

Maintains symlinks to package binaries under ~/Library/Caches/hermit/binaries
For example:
juho@MacBook-Pro binaries % tree
.
├── gradle-7.2
│   └── gradle -> /Users/juho/Library/Caches/hermit/pkg/gradle-7.2/bin/gradle
└── openjdk-11.0.10_9
    ├── jaotc -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jaotc
    ├── jar -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jar
    ├── jarsigner -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jarsigner
    ├── java -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/java
    ├── javac -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/javac
    ├── javadoc -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/javadoc
    ├── javap -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/javap
    ├── jcmd -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jcmd
    ├── jconsole -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jconsole
    ├── jdb -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jdb
    ├── jdeprscan -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jdeprscan
    ├── jdeps -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jdeps
    ├── jfr -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jfr
    ├── jhsdb -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jhsdb
    ├── jimage -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jimage
    ├── jinfo -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jinfo
    ├── jjs -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jjs
    ├── jlink -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jlink
    ├── jmap -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jmap
    ├── jmod -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jmod
    ├── jps -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jps
    ├── jrunscript -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jrunscript
    ├── jshell -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jshell
    ├── jstack -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jstack
    ├── jstat -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jstat
    ├── jstatd -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/jstatd
    ├── keytool -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/keytool
    ├── pack200 -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/pack200
    ├── rmic -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/rmic
    ├── rmid -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/rmid
    ├── rmiregistry -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/rmiregistry
    ├── serialver -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/serialver
    └── unpack200 -> /Users/juho/Library/Java/JavaVirtualMachines/jdk-11.0.10_9.jdk/Contents/Home/bin/unpack200

This is a pre-condition on adding runtime-dependencies where we will add these package specific binaries to the PATH when calling a specific package with deps.

Yes, tests!


Class "Filament\PluginServiceProvider" not found

Installed this plugin on a fresh Filament environment and this error is returned:
Class "Filament\PluginServiceProvider" not found
Laravel: v11.2.0
Filament: v3.2.62
Timepicker: v1.0.4

Any solution on this?

Timepicker v3 was rewritten for Filament v3, however it is incompatible with Laravel v11:

laravel/framework replaces illuminate/contracts and thus cannot coexist with it.

The issue is with the composer requirement "illuminate/contracts": "^10.0". Looks like it needs to be removed.

please try now we have update the package


[$125] Desktop - Avatars in split preview card too close to right edge

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: <IP_ADDRESS>
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @shawnborton
Slack conversation:
Action Performed:

Create a split with two other people
Look at the preview card

Expected Result:
Avatar stacak should be 20px (or is it 16px?) away from the right edge of the card, it should match the same padding as left side
Actual Result:
Avatar stack is too close to right edge
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/93399543/06b7652d-e12c-4bbe-a912-f219f21fcc7f
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~014ce3040ec2425cf6
Upwork Job ID:<PHONE_NUMBER>623753216
Last Price Increase: 2023-11-15

I'm going to try and fix this in an ongoing PR. If not we can let this be external.

Proposal
Please re-state the problem that we are trying to solve in this issue.
The avatars are incorrectly placed
What is the root cause of that problem?
The avatars use the negative margin here:
https://github.com/Expensify/App/blob/e953a657a5d4bb492a1b4cb7b74dcd6acc6ad9f9/src/styles/styles.ts#L2662
What changes do you think we should make in order to solve the problem?
We should remove this negative margin:
https://github.com/Expensify/App/blob/e953a657a5d4bb492a1b4cb7b74dcd6acc6ad9f9/src/styles/styles.ts#L2662
What alternative solutions did you explore? (Optional)

Proposal
Please re-state the problem that we are trying to solve in this issue.
The avatars are incorrectly placed
# What is the root cause of that problem?
The avatars margin is -10 instead of 16
App/src/styles/styles.ts
What changes do you think we should make in order to solve the problem?
we have 16 px in the front padding so we need to make the avatar padding -16 instad of -10
 marginRight: -16,

Proposal
Please re-state the problem that we are trying to solve in this issue.
The avatars are incorrectly placed
What is the root cause of that problem?
We have incorrect marginRight in moneyRequestPreviewBoxAvatar
What changes do you think we should make in order to solve the problem?
We need to remove marginRight or smaller than now.
https://github.com/Expensify/App/blob/cc5a272b3fdcdbe9ecfca056cc8bbd4a405a5b17/src/styles/styles.ts#L2683
What alternative solutions did you explore? (Optional)

Thanks. The PR is ready: https://github.com/Expensify/App/pull/31430

Payment summary:

C - @paultsimura - $125 - paid via Upwork
C+ - @parasharrajat - $125 - to be paid via NewDot

Closing. Thanks everyone!


Refactor containerd serve function

Signed-off-by: Qiang Huang<EMAIL_ADDRESS>

@mlaventure @stevvooe Updated.

@hqhq Wait, sorry, I didn't catch this before. It is very weird to have this functions not take listeners and then launch their own goroutines. Typically, this should be done in main.

@stevvooe Why is this weird? I see we're doing the same thing in cmd/containerd-shim/main.go, and there is no logic change at all. I just feel there are too much trivial work in main action function which can be moved to sub-functions.

@hqhq In Go, functions with Serve in the name take a listener and block forever. Pushing this logic out to other functions doesn't really make things clearer. For the most part, this is just obfuscating unix socket creation.

@stevvooe Personally I'd like main function to be sample and only call a few functions to identify the functionalities, like startMetricsServer, startProfilerServer, startGRPCServer etc.. And main function doesn't care how they do it (by parsing socket addresses, creating socket files, calling Server functions etc..), they can be details in sub functions. This can follow your functions with Serve in the name take a listener and block forever best practice but it'll still need us to pass cli.Context as parameter.
Anyway, this isn't any big deal, just personally think it's clearer and amuses gocyclo, we can have consensus later since containerd main function isn't too complicated yet. I'll close it for now and thanks for all your comments.


Adding non-passive event listeners

Description
DevTool of chrome canary in verbose mode gives a violation

[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive.

This violation comes for touchstart and mousewheel events

Steps to Reproduce

Create a small demo application using Polymer
Open the application in chrome canary
In console of devTool switch level to verbose.

Versions

Polymer: v1.X.X
webcomponents: vX.X.X

I analyzed my app with Lighthouse

it suggest to uses passive listeners to improve scrolling performance.

@khammami I got the same warning too. But the one adding non-passive listeners is polymer itself.. and some iron component. How should we replace that?

Hi @wingliu0, here what I found about passive events. touch listeners should be annotated with {passive: true}. I believe the best way to replace them is by reporting each non passive listener you find to the team.

@khammami  true, but will they still maintain the polymer 1.x?

@wingliu0 I think so, at least till the final release of v2

Dupe of https://github.com/Polymer/polymer/issues/3604


How to dispatch many actions in one action creator

I have some example on fluce:
function authFormSubmit(fluce) {
  const {valid, disabled, data: {username, password}} = fluce.stores.authForm

  if (disabled) return

  if (!valid) {
    fluce.dispatch(AUTH_FORM_ERROR, new Error('Form is invalid'))
    return
  }

  fluce.dispatch(AUTH_FORM_DISABLED, true)
  fluce.dispatch(AUTH_FORM_ERROR, null)

  authorize({username, password})
    .then(
      user => fluce.dispatch(CURRENT_USER, user),
      error => fluce.dispatch(AUTH_FORM_ERROR, error)
    )
    .then(
      () => fluce.dispatch(AUTH_FORM_DISABLED, false)
    );
}

How to implement same action creator in redux? Should I create action creator for every action type?

I'd probably let action creator return a function. If it's a function, it's given dispatch and the state.

I added support for async ACs as described above. For now, they can't access the state—I'll probably get back to it at some point, but I don't want to rush an API.

Update: you can do this now.
// Could also look into state in the callback form
export function incrementIfOdd() {
  return (dispatch, state) => {
    if (state.counterStore.counter % 2 === 0) {
      return;
    }

    dispatch(increment());
  };
}


Advice on four-star probability

The four-star rate is a bit low, and there are often three-stars, which are not quite like the actual situation.

会在后续优化概率


Refactor Google Assistant

Description:
We tried to get our Google Assistant integration certified by Google and we ran into a couple of issues #12935.
When I was looking into fixing the bugs, I realized that the code could benefit from a major cleaning. I've followed a similar model as we used for Alexa and have structured all the logic based on the traits that Google supports.
Because of this, I have removed a few hacks:

It is no longer possible to override the domain that Home Assistant uses for an entity. This was bound to go wrong when we would test supported features for different domains.
Removed support for disguising temperature sensors as thermostats. We should follow the traits that Google offer us and not offer things that will only work half.

I'm running the old tests on the new code without modification. Will add some new tests for the new code on top of that too with as goal to replace the old tests too. The old tests test too many things at once, making it difficult to test specific code paths.
To refactor:

[x] SYNC
[x] QUERY
[x] EXECUTE

To add:

[x] More error checking and reporting
[x] More tests

This refactor will open up the way to easily implement a ton more traits easily. Especially excited about the Toggles trait that can turn things on/off.
Fixed bugs:

We will now correctly report the new state as a response to an execute command
We will raise error when trying to set temperature out of range of the device

CC @philk
Breaking change: Google Assistant has removed the type option for entity configuration and no longer allows sensors to disguise as thermostats.
Related issue (if applicable): #12935
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Checklist:

[x] The code change is tested and works locally.

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

I've tested the code locally and verified that it works.

@balloob I have actual lights that are switches in home assistant (due to how the rfxcom component works). I used the override to let them show up as lights in Google assistant and enable queries such as "turn on all living room lights". What is the recommended way to handle this case now?

@bmesuere I have a switch that controls a light. I have named it Driveway light and I can turn it on/off by saying turn on/off driveway light. I am thinking you can still add it to a group or try out light.group.

light.group will actually not work as it is limited to lights. The reason for removing it is that all of Google Assistant works by testing against supported_features property. By overriding the domain, we pass switch supported features to light supported features and things start going weird. It's not up to the Google Assistant to support shortcomings in other integrations. Instead, consider using a light.template to make a switch be represented as a light. If you want the sensor as thermostat feature back, use the generic thermostat.

@balloob how do templates work in this way? For example, how can I make a remote behave as a switch so I can use it to turn on/off my TVs with Google Assistant?

@CWSpear Use template switch, for example.
Also, please don't use merged PRs for discussions. Open a new issue (if it is an issue) or post in forums for configuration questions.

@arsaboo I tried and didn't get any good answers. In fact, the only response I got was point here. And here got me an answer in 13 minutes...
But I will try and keep it in mind for next time. Anyway, that link helped, and I think I've got it figured out. Thanks!


feat(tauri) use config as JSON

[ ] Bugfix
[x] Feature
[ ] New Binding Issue #___
[ ] Code style update
[x] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes. Issue #___
[x] No

The PR fulfills these requirements:

[x] It's submitted to the dev branch and not the master branch
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
This PRs changes the tauri-config parsing, to evaluate src-tauri/tauri.conf.json instead of tauri.conf.js, to make it easier to read it on Rust. Thanks to @nklayman for starting this and doing most of the Node CLI work.

We need to rebuild all the examples here.

The tests for react/create-react-app, react/next.js, and svelte/svelte-app should pass once https://github.com/tauri-apps/tauri/pull/232 is merged

The quasar build tests are failing because tauri-webpack hasn't been updated yet.


Remove dependencies on OperationInternals and OperationInternals

Part of the work to unify LRO
Uses OperationInternal and OperationInternal<T> instead of OperationInternals and OperationInternals<T>.

That would be a separate PR.
https://github.com/Azure/azure-sdk-for-net/pull/29071

To avoid any issues that can be caused by references to these types in azure-sdk-for-net . When all generated types are updated, I can safely clean-up hand-written code in azure-sdk-for-net and then remove these types from autorest.csharp repo.
Converted to draft

LGTM. Previously I was confused of the purpose of OperationInternals. Its value is just to set the 1s polling interval. Now we have the default 1s interval in RetryAfterDelayStrategy, then we don't need OperationInternals.


[Request] please add PDFgear  🫡

Name: [pdfgear]
Description: [Read, edit, convert, merge, and sign PDF files across devices, for completely free and without signing up.]
Homepage: [https://www.pdfgear.com/]
Download link(s): [https://www.pdfgear.com/download/pdfgear_setup_v2.1.0.exe]
Some indication of popularity/repute:  [Get more practical video tutorials on the PDFgear YouTube Channel]
5 BEST PDF Editors in 2023 (One is REALLY FREE!)
Vision ：
Revolutionizing the way people interact with PDFs.
We believe everyone has access to the tools they need, which is why we're currently offering PDFgear for free. We take privacy seriously and ensure all data is secure.

Why close the issue? As I see that nobody added the requested manifest, including me as I don't have much time.

Thank you for your reply. I'm sure you are a busy developer and i do not want to add any unnecessary burden for you.
Therefore, I think requesting some other buckets to try might be better for now. Closing the request temporarily would not be a bad option.
Exploring alternative solutions could help determine if there are any good fit options without extra workload. And closing it for now allows you to come back to it later should your needs or timelines change.
Please don't feel obligated to continue assisting if it starts to take up too much of your time. I appreciate you considering my initial question,If you have time and bandwidth available in the future, please feel free to reopen this issue so we can continue exploring options.

@aka-phrankie
I added the manifest for this app -  in case you dont already have this bucket amongst your scoop buckets run scoop update && scoop bucket add anderlli0053_DEV-tools https://github.com/anderlli0053/DEV-tools && scoop install anderlli0053_DEV-tools/upnqr .


update to rc2

update to angular rc2 dependency
It should not have any breaking changes affect this library.
https://github.com/angular/angular/blob/master/CHANGELOG.md#breaking-changes
so we can update our app.
Thanks!

@fdu-axiometrics you can update your app without any problems. NPM shows a warning, but that is not a problem. We will update the peerDependencies in the next release, as the current version is fully functional with rc2.


CP210X serial kernel module

Could you please add
CONFIG_USB_SERIAL_CP210X=m
to the kernel config?
This builds the cp210x kernel module which is needed by the HUSBZ-1 Zigbee/Zwave USB stick.

CONFIG_USB_SERIAL_CP210X [=m] is already set in the recent pre-release kernels.


Finalizing Rearrangement fields

I just finished making all the (relevant) Change-O tools work with the AIRR format.
Here's the set of spec changes I think are necessary after going through that as well as input
from a few other discussions. Some of those discussions were offline, but some of it's covered in
the issues: #84, #83, #82, #75, #58.
Before making a pull request with changes, I want to hear others' thoughts as some of these things
require naming decisions which I'm undecided on.  For all fields listed, I've proposed a non-exhaustive
list of alternative names. I tend to prefer short names, but there's a good argument for longer,
more explicit names as well.
Fields to modify
rearrangement_id (rearrangment)

Remove from required.
Add the tag x-crwg: true to denote the field as required in the CRWG context.
Update the definition to clarify that the field serves as a unique identifier for the
Rearrangement object and is not necessarily derived from the input sequence or
alignment tool result.

rearrangement_set_id (rearrangement_set)

Remove from required.
Add the tag x-crwg: true to denote the field as required in the CRWG context.
Update the definition to clarify that the field serves as a unique identifier for an
arbitrary collection of Rearrangement object and is not necessarily a meaningful
cross-study, biological classification.

cell_index

Remove from required.
Change type to string.

sequence (query_sequence, sequence_input)

Clarify in the definition that this field contains the unmodified sequence that was input
into the tool. Alternatively, this may contain an intermediate "output" sequence in the sense of
a consensus sequence, unique sequence, assembled mate-pair sequence, or other results of pre-V(D)J
alignment processing embedded in the alignment tool. Basically, whatever the alignment field (below)
was based on that meets the NCBI GenBank submission criteria: "an uncorrected sequence, which
may have gone through assembly or consensus, but not indel correction or truncation".

functional

Rename to productive.

Necessary fields to add
The following fields are missing, but necessary:
sequence_id (query_id)

String. The identifier for the sequence.
This replaces rearrangement_id as the row key for the Rearragenment object,
within the context of an analysis file (the default context). The default expectation is that this would be
equal to the input sequence header, but that is not strictly required, especially in cases where
sequence corresponds to such an above described intermediate sequence.
The TL;DR of why this is needed is because rearrangment_id and sequence_id have conflicting
semantics, depending upon whether we are in an analysis file or database context.

alignment (aligned_sequence / sequence_alignment)

Nucleotide string. The aligned output sequence (typically just the V(D)J region).
This differs from sequence in that in may include gaps, deletions, masking or trimming
so that it is aligned against the reference sequence in the germline field (below). Some examples of
what this field looks like are SEQUENCE_VDJ/SEQUENCE_IMGT from changeo, V-D-J-REGION
in the 2_IMGT-gapped-nt-sequences and 3_Nt-sequences files from IMGT/HighV-QUEST,
the mature_seq field in partis.
My opinion is that this should be a required field because it's a primary analysis field. However, it's
not universal output. For example, IgBLAST doesn't (presently) output this field for the full V(D)J.
Instead, it has individual alignment output in the query seq column of the V/D/J hit table section.
We could also support the above via v_alignment, d_alignment, and j_alignment fields.

germline (germline_sequence)

Nucleotide string. The aligned full germline sequence (stitched V(D)J germlines).
Should be aligned with the sequence in the alignment field. Some examples of what this field looks
like are GERMLINE_VDJ/GERMLINE_IMGT from changeo and the naive_seq field in partis.
As with alignment, IgBLAST doesn't provide a full length alignment for the germline, but does provide
individual V/D/J aligned germlines via the subject seq column which we could support via
v_germline, d_germline, and j_germline fields.
I also think this should be required to compel tool writers to provide it.

Optional fields to add
The following missing fields are not necessarily needed, but I think we should add them as they are common aligner output.
chain (chain_type)

String. Specifier for the chain. Eg, VH, VL.

stop

Boolean. Whether the V(D)J sequence contains a stop codon.

vj_in_frame (v_j_in_frame)

Boolean. If the V and J are in frame.

mutated_invariant

Boolean. If an invariant codon is mutated or missing.

Additional aligned sequence fields to add
These fields are not required, but they appear in the output of several tools, so I think we should add them as official optional fields.

np1 (np1_nt, np1_sequence, np1_seq, np1_alignment)
np2 (np2_nt, np2_sequence, np2_seq, np2_alignment)
cdr1 (cdr1_nt, cdr1_sequence, cdr1_seq, cdr1_alignment)
cdr2 (cdr2_nt, cdr2_sequence, cdr2_seq, cdr3_alignment)
cdr3 (cdr3_nt, cdr3_sequence, cdr3_seq, cdr3_alignment)
fwr1 (fwr1_nt, fwr1_sequence, fwr1_seq, fwr1_alignment)
fwr2 (fwr2_nt, fwr2_sequence, fwr2_seq, fwr2_alignment)
fwr3 (fwr3_nt, fwr3_sequence, fwr3_seq, fwr3_alignment)
fwr4 (fwr4_nt, fwr4_sequence, fwr4_seq, fwr4_alignment)

The big issues here are what to call them, whether this implies a name change to the junction_nt field, and how this defines the names of positional fields (below).
By default, we have been assuming all sequences are nucleotides, so that sequence implies sequence_nt. I think this is easier than having an _nt and _aa field for everything.
There's also an implication that cdr1_sequence is the cdr1 sequence as it appears in the input sequence (sequence field) and cdr1_alignment is the cdr1 as it appears in the output sequence (alignment field). Whereas, cdr1 implies neither, but we can define it as extracted from the alignment field in the description.
Clarify naming of positional fields
Related to the above, maybe we should modify the names of the positional fields so they imply a direct relationship to the sequence field that they correspond to? For example:

v_start to v_sequence_start or v_alignment_start
v_end to v_sequence_end or v_alignment_end
v_germ_start to v_germline_start
v_germ_end to v_germline_end
d_start to d_sequence_start or d_alignment_start
d_end to d_sequence_end or d_alignment_end
d_germ_start to d_germline_start
d_germ_end to d_germline_end
j_start to j_sequence_start or j_alignment_start
j_end to j_sequence_end or j_alignment_end
j_germ_start to j_germline_start
j_germ_end to j_germline_end

Note, I think we actually need both *_sequence_start and *_alignment_start - one for NCBI GenBank submission (*_sequence_start) and one for analysis purposes (*_alignment_start), but I don't think we need to include both in the spec, because we can derive one from the other using the CIGAR string.

Thanks for summarizing this for us @javh.
I'm in the camp of having more fields specified is better. Even a field that can be derived from another, if the field is useful and/or being used by a tool, then I prefer it to be specified. That means I'm basically good with all the additional fields and would also advocate for both *_sequence_start and *_alignment_start fields to be added.
For naming, I also prefer the names to be more specific, the exception being some "core" fields like sequence is fine, it doesn't need to be sequence_input. Especially if a field might have different contexts, like you point out where fields may refer to either the input sequence or the output alignment.
It seems reasonable to assume all sequences are nt and thus use _aa for when it's amino acids. However, I also think it's reasonable to put _nt on the field if it may not necessarily be obvious that it's a sequence. Here I side on being more specific. I'm okay with junction_nt, I also prefer fwr3_nt over just fwr3 or fwr3_sequence. Is there any reason to provide (say) fwr3 as amino acids? Maybe, so fwr3 and fwr3_sequence might be ambiguous while fwr3_nt and fwr3_aa are less so.
I would eliminate the x-crwg tag, 1) because it isn't useful to the CRWG API spec nor to the AIRR library, and 2) crwg is probably not the best name. I'm fine with rearrangement_set and rearrangement_set_id not being required for now. It's probably premature to specify these technical details anyways until CRWG is further along.
Lastly, for sequence_id, it might be useful for the AIRR library to generate one if one isn't provided, which could be helpful for tools that depend upon it. Of course, tools could just as easily do it themselves.

Here is what I thought.

Under "Fields to modify", everything look fine except for the "sequence" field .  I thought we should be strict about names and definitions for required fields so that we have a consistency in what they represent.  I'd use "query_sequence" to avoid any ambiguity.  As for definition, I thought it should only mean the original query sequence itself (or reversed and complemented as is defined in the original specs).  If a  tool wants to provide a sequence string of some other kind, it can be provided by a custom field.

"Necessary fields to add".

query_id seems to be a better name as reasoned above.
alignment (aligned_sequence / sequence_alignment).  I am not sure about the purpose of this.  Isn't alignment already represented by the existing CIGAR alignment field?
germline (germline_sequence).  Same as 2) above.

"Optional fields to add"

chain (chain_type).  If you took this from igblast, this means VH, VK, VL for B cell recepotor, VB, VA, VG, or VD for TCR.  I'd prefer "chain_type" since it's a little more clear but I am fine with alternative names.
I'd use stop_codon to be clear.
vj_in_frame (v_j_in_frame).  vj_in_frame is better since it's more consistent with existing names like np1_seq, etc.
mutated_invariant.  I am not what it refers to since we have a few different invariant amino acid positions.

"Additional aligned sequence fields to add".
Since the current specs have CIGAR string to represent alignment already, can't these additional alignment fields could be treated as custom fields and let the tools  themselves to define?

"Clarify naming of positional fields".
I'd use "v_query_start" and "v_germline_start", etc to be clear.  v_query_start indicates the first position in the query sequence that is aligned to the germline V sequence.  I am not sure what you meant by referring to both sequence_start and alignment_start.

Just wanted to address @jianye00's questions. (No opinions to offer yet.)
alignment, germline
This is partially addressed by the CIGAR string, yes, but not entirely because the CIGAR strings are by segment. Though, vdj_cigar could cover it, with masking for N/P regions. Not sure if that would conflict with how the alignment process works for some tools.
A simple example of what these two fields look like would be:
 sequence> CCCCCCACTGGNAGTTGAGGATGAGGGGCTGATTATTAGCTTCAGTCGTATGACGGGGACCAAGGTCAGGGGGG
alignment>      CACTGGNAGTTGAGGATGAGGGGCTGATTATTA---GCTTCAGTCGTATGACGGGGACCAAGGTCA
 germline>      CACTGGGAGCTGAGGATGA--GGCTGATTATTAAGTGGTTNNNNCGTGTGANNGGGACCAAGGTCA
   region> LLLLLVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVNNNNDDDDDDDNNJJJJJJJJJJJJJCCCCCC

Basically, the alignment field is just the concatenated top V hit query seq, N/P1, D hit query seq, N/P2, and J hit query seq in the IgBLAST output (to make a full length aligned, observed sequence). The germline field is then the corresponding full length inferred, aligned, germline sequence made using the subject seq fields instead.
These two fields are key analysis fields for us, because we do a lot of direct string comparisons between the full length observed and germline V(D)J sequences. While we should be able to make these from the CIGAR strings and N/P positions, that just adds an extra processing step before we can actually use the file for analysis.
mutated_invariant
This comes from the IMGT/HighV-QUEST output and how they define productive. If any invariant residue is either mutated or absent, then they note it. It's kind of like the stop field, which says a stop codon is found, but not where or how many. Though, maybe it would be better as string specifying the invariant. Eg, C104P being cystine 104 to proline.
I don't think it's a necessary field. Certainly not something I think IgBLAST needs to output. It'd just be present in the spec as an optional field to support IMGT's output.
Additional aligned sequence fields to add
Definitely. I was just thinking it'd be nice to have a set of official names for these optional fields because they are so common. They wouldn't be required.
x_sequence_start, x_alignment_start.
The difference is just whether it refers to the position in the unmodified input sequence or the aligned sequence. In the example above, j_alignment_start would be 53, but j_sequence_start would be 55, because the leader sequence (L in regions) has been removed (-5) and gaps have been inserted (+3) in the alignment sequence.

I basically agree with @schristley

I am for having useful fields specified even if they can be derived
I also prefer to use specific names
I advocate for both *_sequence_start and *_alignment_start fields to be added
I am ok with the assumption of nt by default and add *_nt wherever needed (juncion_nt)
I would make the _alignments required and maybe use _aln instead of _alignment (sequence_aln, np1_aln, cdr1_aln), to make it shorter?
vj_in_frame better than v_j_in_frame
either chain or chain_type
either stop or stop_codon
add mutated_invariant

I like sequence_input (and sequence_id) better than just sequence, query (and query_id) or query_sequence. As I see it, query_sequence is any sequence that I use to do some comparison to a reference, and it could be the whole input sequence, or maybe a part of the input sequence, or I may be using the aligned sequence as query for some analysis... I see query_sequence as something that can change with the context and sequence input as the 'raw' sequence data. But my opinion is probably biased due to the fact that we currently use SEQUENCE_INPUT. So if you go with query, that's fine.

@javh Ok you are essentially saying you want to add additional alignment fields (other than the existing CIGAR field).  Since an alignment involves two sequences, there will be two alignment string fields (i.e. AGCT--CGTAGC) for each alignment (One is for the query and the other is for the germline).  For each alignment, you also want to add start and stop coordinates (and in both sequence and alignment coordinates), for both query and germline.  And of course we have 4 alignment categories (whole vdj, v, d, j).   Is that correct?  That's lots of fields but I am fine with it if people think that's not too many and such information is useful.
I'd say we could use "v_query_start" and "v_germline_start" to indicate sequence coordinates and "v_query_alignment_start" and "v_germline_alignment_start" to indicate alignment coordinates.
Mutated_invariant could stay but we better indicate which one it is.  Stop codon is a little different, it does not matter where it is, you have the same result (no protein).  The effect of mutation at different invariant position could be different.

@jianye00, yeah, that's the idea. Though, a lot of these fields will just be name reservations for tools that need them and not mandatory output. The list of expected output would just be the things under the required tag - the following:

sequence_id
sequence
rev_comp
germline_database
productive
alignment (debatable)
germline (debatable)
v_call
d_call
j_call
c_call
v_score
d_score
j_score
c_score
v_cigar
d_cigar
j_cigar
c_cigar
junction_nt
junction_aa

If a tool didn't output 'j_query_startorj_germline_startthen you could just get it from the N/S operators at the front ofj_cigar` if you needed it, but if a tool did want to output it, we'd have a reserved field name for it.

Oh, one thing I didn't notice before... We have germline_database in the required fields.
Isn't this more of a metadata item?

Sure that should not be here...typically the databases are fixed for a given run and therefore the values are the same for all queries.
I noticed this two fields:
alignment (debatable)
germline (debatable)
what are they?

I noticed this two fields:
alignment (debatable)
germline (debatable)
what are they?

The full length, aligned query and germline sequences from the "Necessary fields to add" section in my original post.

Ok, then the names need to be a little more informative, something lilke query_alignment, germline_alignment.

I'd also want to suggest an additional field.  We have seen some user requests to output the translated amino acid sequence for the query (the translation would be from start of V gene in the query) .
Currently the translation  is available in the standard output but that's not easy to parse.  Could this be appropriate for an optional field in AIRR format?  Of course we could add it as a custom field but it seems to be of general interest.

Yeah, I think that makes sense. It'd just be adding more _aa fields.

Pinging @laserson, @williamdlees and @psathyrella for any input.

For 'chain type' I suggest  adding locus and region as defined in the draft germline schema at https://github.com/airr-community/gldb-wg/blob/master/germline_schema/schema/receptor_germline_schema.yaml
locus:
type: [Heavy, Light-Kappa or Light-Lambda for B-cell sequences, or Alpha, Beta or Gamma for T-cell sequences]
description: Gene locus
region:
type: [V,D,J,C]
description: Gene region
For the other fields - I agree that it is helpful to define 'useful' fields even if they can be derived. I think quite a few people will find the cigar string difficult to work with. There is no Excel implementation, for example. Having the cdrs and fwrs explicit will be helpful in applications that are less computationally oriented and it makes sense to have reserved field names and explicit definitions.

gene_locus (or v_gene_locus, v_call_locus ?) seems appropriate as mentioned by @williamdlees but maybe not gene_region as the [V,D,J,C] regions are implicitly defined (v_call, etc.). Also gene_locus seems to infer B-cell vs T-cell. Is that sufficient? Accurate for all species?

Sorry I somehow missed this before. A couple of comments:

@schristley : Yes, there are VLR loci in Agnatha, which are rearranged and expressed in various lymphocyte populations in these animals. While these cells seem to exhibit convergent functions, they are not classical B or T cells. IMO we should restrict ourselves to Gnathostoma for now, as the inclusion of VLR will require substantially more changes than the locus.
All the alternative IGH constant regions in non-mammalian species are already covered by locus:heavy. However, the options for locus should also include the Ig sigma and iota light chain loci present in fishes and frogs. Also see this post on b-t.cr.
I think that even though TRD does hide within the TRA locus it should be mentioned in VC (either separate or as TRAD).
Finally, I would strongly opt for renaming region to segment. The usual definition is that the "V region" is the stretch of DNA/RNA  that encodes the "V domain" protein structure and is created by the rearrangement of a genomic V, D and J segment. This definition would then also be in line with the current keys used in the INSDC feature table.

@williamdlees
It seems to me that the already-defined "locus" is an appropriate replacement of "chain type" and basically convey the same thing.  But why the Delta type is missing for TCR (probably also mentioned by @BusseChristian )?   I don't seem to see the reason for adding "region" since we are dealing with rearranged sequence, not individual v, d or j element.

I'm working on combining everyone's responses into a PR right now... quick question:
Is rev_comp suppose to be True if the content of sequence is reverse complemented w.r.t. the input read, or is sequence suppose to remain in its original orientation and rev_comp indicates the alignment is reversed w.r.t. sequence?
Ie, does rev_comp=True indicate that sequence and junction are in the same or opposite orientations?

or is sequence suppose to remain in its original orientation and rev_comp indicates the alignment is reversed w.r.t. sequence?

That's how I interpret it. The input sequence had to be reverse complemented to be aligned, so sequence and junction are in opposite orientations.

The rev_comp should be clearly defined.  We have always used a simple approach.  If the input read contains vdj sequence in opposite orientation, we first reverse and complement the input read and then  use the reversed/complemented read for alignment.  Therefore, all output data (i.e., alignment coordinates,  nucleotide sequence, translated protein sequence, etc) are based on the reversed/complemented sequence of the original read.
Another thing is that if we want to add alignment fields for the entire vdj alignment, I thought we should also add the corresponding fields for individual v, d, j and c elements since some tools only deal with individual alignments.

I added @jianye00's definition for rev_comp to the description after merging #89.
Maybe let's address fields like v_sequence_alignment, v_germline_alignment, etc, that are exact derivatives of CIGAR when we get to the hit table format? For now, I think maybe keep them as custom fields? If they become a need, we can always add them later.
I'm also having mixed feelings about including optional explicit IMGT numbered alignment fields like sequence_imgt and germline_imgt that we use, so I left them out of the current pull request in favor of just using sequence_alignment and germline_alignment for those tools that need that. (Also, to avoid dragging out the discussion, so I could merge #89.)
Closing this for now. If you notice something that I didn't address, please reopen.


Basler hardware frame counters cannot be trusted to accurately detect hardware frame drops

Harp trigger timestamps are paired with frames by using the Zip operator to combine each frame with each trigger, in order of arrival. This assumes there are no dropped frames.
To protect the pairing of Harp triggers with grabbed frames in the presence of spurious accidental frame drops, we have code in place to compute the difference in hardware frame counters across two grabbed frames. If the frame counter difference is greater than one frame, we will pad the video sequence with null frames to ensure that the pairing can still be done in order.
https://github.com/SainsburyWellcomeCentre/aeon_acquisition/blob/c13d7d8bb9becda6a67d4a763d840fe09a64b234/src/Aeon.Acquisition/PylonCapture.cs#L22
However, while running CPU performance benchmarks for closed-loop latency, we identified a strange behavior in the timestamp of video frames after such a frame drop correction. Specifically, we observed that even though null frames were generated for drops detected with the hardware frame counter, the adjusted timestamp had a significant difference to the latest live "real-time" trigger timestamp.

On further investigation, we discovered that differences in hardware frame counters can sometimes be smaller than differences in the hardware timestamp across two frames. One possible explanation for this would be if the frame drops are due to a faulty USB connection which forces the camera microcontroller to reset the connection. If during this recovery procedure the microcontroller ignores trigger TTLs coming from the Harp device, those triggers would not be able to initiate a new exposure at the hardware level, and thus the hardware frame counter would not be incremented.
We prototyped a new strategy for correcting hardware frame drops based on hardware timestamp differences, which as expected did solve the issue:
.FillGaps(frame => frame.ChunkData.Timestamp, (previous, current) => (int)Math.Round((current - previous - frameInterval) / frameInterval))

We now need to develop this approach further to validate the numerical calculations against possible edge cases such as clock wraparound, etc. We also need to automatically extract the expected camera trigger frequency to compute the ideal frame interval. We are currently not sure if this is a Basler specific behavior since we have not yet observed this in the FLIR cameras, so for now we will modify only the Basler acquisition.

After further testing, this issue does indeed seem to be specific to highly degenerate hardware configurations where the integrity of the USB communication between the camera and the computer is compromised, to the point where the camera firmware starts to ignore electrical triggers.
When this happens it is a permanent condition, and the problem will promptly manifest usually under a minute after starting the workflow. It is also non-transient, meaning it will constantly reoccur as long as the workflow is running and compromise the integrity of all the collected data from the affected camera.
On the other hand, in non-degenerate situations, we always get correct frame drop reporting and the existing recovery mechanisms are appropriate, and the issue might be transient.
Given the above our current approach is to assume that this is a non-recoverable error that requires prompt intervention. We do not want to try to pad the sequence based on hardware-timestamps and start masking out a transmission problem which is fundamentally irrecoverable. Our approach to this issue will be to track it as part of the online quality control system and report it as a critical alert if it ever happens.

Closing as I think resolved, feel free to re-open if not


Use correct which command instead of non-existent where

This fixes the instructions for finding the location of the kubectl binary.

@Katee Thanks you for your contribution.
Could you please sign the CLA before the PR can be reviewed.
You can follow the steps documented here: CLA Steps

Hi @Katee, can you confirm your status on EasyCLA, as the changes seems to be beneficial for the kubectl uninstallation documents.

I'm not authorized to sign a CLA. I was expecting my employer (Alphabet/Verily) to already have something on file for Kubernetes. I've reached out about it.

Hi @Katee , I'm closing this PR for the following reasons:

this PR fails the CLA check
this PR makes changes to the English and Chinese localization

Typically PRs target one localization with the change to the English site first.
Feel free to reopen this PR with /reopen in a comment when you are ready to work on this PR to remove the change to the Chinese localization and when the CLA has been signed or when Linux Foundation has verified the employer has signed the CLA
/close

/reopen

As these instructions are for macos, where works
here's an output from my macos laptop for both where and which:

$ where kubectl                                                                                [14:30:48]
/Users/reylejano/.rd/bin/kubectl
$ which kubectl                                                                                [14:10:55]
/Users/reylejano/.rd/bin/kubectl

I'm running MacOS Ventura and I don't have a where command. It appears to be a command on Windows, but not on MacOS: https://apple.stackexchange.com/questions/272717/macos-equivalent-of-the-where-command-used-in-a-windows-command-prompt
@reylejano does alias where return anything?

I'm running MacOS Ventura and I don't have a where command. It appears to be a command on Windows, but not on MacOS: https://apple.stackexchange.com/questions/272717/macos-equivalent-of-the-where-command-used-in-a-windows-command-prompt
@reylejano does alias where return anything?

alias where returns nothing
If where is not available on all macos versions then we should use which
/approve


Add a sql2pgroll package to convert SQL to pgroll migrations

Add a sql2pgroll package to convert SQL to pgroll migrations.
Add a (hidden for now) pgroll sql command that uses the package to convert SQL strings on the command line to pgroll migrations.
The sql2pgroll package is incomplete, with almost all SQL falling back to conversion using raw SQL migrations. Only some CREATE TABLE statements and the ALTER TABLE ... ALTER COLUMN ... SET NOT NULL statement are currently handled.
$ pgroll sql "create table foo(a serial primary key, b text unique)"

[
  {
    "create_table": {
      "columns": [
        {
          "name": "a",
          "pk": true,
          "type": "serial"
        },
        {
          "name": "b",
          "nullable": true,
          "type": "text",
          "unique": true
        }
      ],
      "name": "foo"
    }
  }
]

Issue tracking the work remaining on sql2pgroll: https://github.com/xataio/pgroll/issues/504


Inconsistent Navigation Menu Links

The dropdown navigation menu links are pretty inconsistent going from page to page.  For example
On the home page, clicking Learn -> Home is the same as angularjs.org (not docs.angularjs.org)
Clicking Learn -> Tutorial is the same as Develop -> Tutorial - http://docs.angularjs.org/tutorial (or was that on purpose?)
This is a more generalized problem of issue #65

Fixed on org, shorty fixed in the docs app, too


Redefine CARGO_TARGET_DIR to be only an artifacts directory

Problem
There are a couple of issues with the CARGO_TARGET_DIR that are seemingly in conflict with each other:

Multiple locations of target dirs complicate excluding them from backups and full-disk search, cleanup of the temp files, moving temp files to dedicated partitions, out of slow network drives or container mounts, etc. Users don't like that the target dir is huge, and multiple instances of it add up to lot of disk space. Users would prefer a central location to ease management of the temp files, and also to dedupe/reuse dependencies across many projects.

People (and tools) are relying on a relative ./target directory being present to copy or run built files out of there. Additionally, users may not want to configure a shared CARGO_TARGET_DIR due to risk of file name conflicts between projects.

However, the dilemma between 1 and 2 exists only because Cargo uses CARGO_TARGET_DIR for two different roles:

A cache for all intermediate build products (a place where crates.io crates are built, where compiler-private temp files are) which aren't project-specific, and/or files that users don't need to access directly.
A location for user-facing final build products (artifacts) that users expect to be there and need to access.

Proposed Solution
So to satisfy both uses, I suggest to change the thinking about what the role of CARGO_TARGET_DIR should be. Instead of thinking where to put the same huge all-purpose mixed CARGO_TARGET_DIR, think how to deduplicate and slim CARGO_TARGET_DIR, and move everything non-user-facing out of it.
Instead of merging or sharding the CARGO_TARGET_DIR as-is with all of its current content, and adding --artifact-dir as a separate place where final products are being copied to — make CARGO_TARGET_DIR to be the artifact dir (without copying).
As long as the CARGO_TARGET_DIR dir is the place for all of the build files, of all crates including all the crates.io and local builds, with all the caches, all the temp junk, then this is going to be a problematic large directory that needs to be managed. But if the purpose of the ./target dir was changed to be only for user-facing files (files that users can name, and would access via ./target path themselves), then this directory would be relatively small, with a good reason to stay workspace-relative.
What isn't an intermediate build product? (and should stay in ./target)

linked (and stripped) binaries of the current workspace, including binaries for the examples,
libraries of the current workspace as .a/.so, where lib.crate-type calls for them. Possibly .rlib/.rmeta in the future if there's a stable ABI.
linked binaries for tests and benches of the current workspace (to make it easy to launch them under a debugger/profiler, and so they can use relative file paths to read workspace assets).
debug symbols for all of the above.
.d files for all of the above (so that IDEs and other build systems know when to rebuild the artifacts).
if Cargo adds some "staging" directory (a non-private OUT_DIR for build.rs, see #13663), then for build scripts belonging to the current workspace it would be inside ./target as well.

So generally files that users build intentionally, and may want to access directly (run themselves, or package up for distribution) and files that users may need configure their IDE and debugger to find inside the project.
Crates in [patch.crates-io] with a path are a gray area, an might also have their artifacts included in the ./target dir (but in some way that avoids clobbering workspaces' files).
What isn't a final build product, and doesn't belong to ./target:

anything related to building crates from crates.io, or any other registry (packages with source = "registry+…")
all .fingerprint and incremental dir content of all crates. These are implementation details of the compiler, and nobody should be accessing these directly via ./target/….
.o files. Users are not supposed to use them directly either (Rust has static libs for this).
proc macro libs. They're not useful without rustc present.

All of these should be built in some other shared build cache dir (one that is not inside CARGO_TARGET_DIR), configurable by a new option/env var.
Registry dependencies would get unique paths derived from rustc version + package IDs + enabled features (so that different crates using different features don't invalidate each others' caches all the time). This would enable sharing built crates.io dependencies across all projects for the same local user, without also causing local workspaces to clobber each others' CARGO_TARGET_DIR/profile/product paths. Temp directories for local projects would need some hashed paths in the shared build/temp dir too.
Advantages

Such split removes about 90% of the weight from ./target dirs (for cargo itself, it makes ./target/debug with binaries and tests take 415MB, instead of 4.2GB). This makes cleanup of all the scattered target dirs less of a pressing problem.
The ./target keeps relatively few files, and removes high-frequency-churning files out of it, which makes it less of a problem for real-time disk indexing (like search and backups on macOS).
I/O latency of ./target stops being critical for build speeds, unlike I/O of the incremental cache and rewrites of thousands of .o files. It becomes feasible to have project directory on a network drive without overriding CARGO_TARGET_DIR (network filesystems are used by non-Linux systems where tools like Vagrant and Docker have to run full-fat VMs, and can't cheaply share the file system).
It makes ./target contain only workspace-unique files, which makes it justified for every workspace to have one.
It enables moving registry deps to a shared build directory, without side effect of local projects overwriting each others' files. Sharing of dependencies matches users' expectation that the same dependencies shouldn't be redundantly rebuilt for each local project.
It's almost entirely backwards compatible. Users can get the benefits without breaking their existing workflows, post-build scripts, and integrations. It doesn't invalidate documentation/books/tutorials that refer to target/release/exe etc.
It could be the default behavior, so it could benefit all users without friction of adding --artifact-dir or .cargo/config.

Notes
No response

In terms of incompatibilities, only a few come to my mind:

Hacks that recursively search ./target looking for a file built by some build script in its OUT_DIR. Ideally this should be solved by adding proper support for building arbitrary assets in Cargo, but for the sake of keeping compatibility with CARGO_TARGET_DIR, this could be made to work by keeping OUT_DIRs as subdirectories or symlinks in ./target.

Binaries trying to link to .so/.dylib of their Rust dependencies, where the deps are built by Cargo, and are not installed on the system. This is currently basically unsupported in Cargo, because there's no way to set rpath to anything that works (absolute path is too build-specific, and relative doesn't work for tests and examples that are in a different dir than bins). But if users are hacking around it with custom post-build steps, they may expect to find the 3rd party shared libs in ./target. This again would be better solved by having Rust/Cargo aware of dylib dependencies, and copy/hardlink dylibs as needed and set rpath accordingly. Not many deps have crate-type = "cdylib", so these also could be kept/symlinked in ./target for back-compat.

Build containers could have very strict read-only filesystems with only CARGO_TARGET_DIR and CARGO_HOME subdirs being writeable. This could be made backwards-compatible by reverting back to the current everything-in-one-place behavior when CARGO_TARGET_DIR is set, and picking other env vars for configuring locations of the trimmed ./target and the intermediate products cache dir.

@poliorcetics from https://github.com/rust-lang/rfcs/issues/3664#issuecomment-2183534143

Yes, the issue should be moved to cargo I think.
I'm not convinced at all this won't break backwards compatibility in some way.

It makes ./target contain only workspace-unique files, which makes it justified for every workspace to have one.

And I don't want one in any cargo project while still keeping isolation, which is entirely different from what you are proposing.

It enables moving registry deps to a shared build directory, without side effect of local projects overwriting each others' files. Sharing of dependencies matches users' expectation that the same dependencies shouldn't be redundantly rebuilt for each local project.

Once again, the RFC I wrote and original issue I inspired myself from do not ask for that, it asks for the opposite: myself and many others want separate targets dirs for every project.
There are probably as many reasons as there are users for it but common ones are different sets of features amongst projects, sharing of build caches for specific projects, CI builds wanting to separate projects for security, or one project pinning 1.2.3 in a dep B of a dep A and the other project pinning 1.2.4: A can have the same version for both but it's dependencies won't and cargo is not made to handle the case at the moment.
You are fundamentally solving a different issue, one that the RFC I posted is not trying to solve.

Overall, I see this as a solution alternative to #6790 and had recommended we have that conversation there (or on internals).

What isn't an intermediate build product? (and should stay in ./target)

This is likely going to be the most difficult topic to work through and we'll need to make sure we get wide input on this from #6790 users and others.

Registry dependencies would get unique paths derived from rustc version + package IDs + enabled features (so that different crates using different features don't invalidate each others' caches all the time). This would enable sharing built crates.io dependencies across all projects for the same local user, without also causing local workspaces to clobber each others' CARGO_TARGET_DIR/profile/product paths. Temp directories for local projects would need some hashed paths in the shared build/temp dir too.

imo this is out of scope for this proposal (see #5931) and we should keep this focused so as not to get distracted.

I see this as a re-framing of the problem, addressing #6790 and rust-lang/rfcs#3371
Instead of us defining a new artifact-dir, we say target-dir is the artifact directory and move everything else out into a "working directory".

The move can be gradual as these files are considered implementation details.
We avoid "yet another flag" problem of --artifact-dir because controlling of the location of the "working directory" is too low level for the CLI and should be reserved for config
A big downside compared to --artfact-dir is that target-dir is not the final directory files are put under but the parent directory.  This is especially annoying for cargo build vs cargo build --target, dealing with profile names, etc

Potential names

working-dir (arbitrarily chose this one to refer to the concept moving forward)
build-dir

Cargo script would default its target-dir as its working-dir
This would need input from

artifact-dir users
cache / cache clean up users
random other systems that dig into the target dir

This would need an audit of ways we publicly treat the target dir as a working dir, like exposing CARGO_TARGET_TMPDIR

Sharing sources over NFS adds another incompatibility when the ability to move ./target out of the sources is eliminated.
Every modern buildsystem allows to keep sources and build results separated (and users and tools do not have problems with it).  I do not think that cargo should go the way back and enforce a fixed ./target directory.

I'm not suggesting to force it to always be ./target. The CARGO_TARGET_DIR can continue to move this directory elsewhere.
The main point is to reduce severity of problems that the current high-churn high-volume content of this dir causes.

We talked about this in today's Cargo team meeting.
Our care abouts include

Moving intermediate artifacts away

Having a transition plan for tool authors

Providing a profile-agnostic location for final artifacts
Resolving the "elide target when host" within the final artifact path
Having a coherent story for users, for example

Users today mostly interact with target-dir for dealing with final artifacts, so we likely want to preserve that
If we create a new directory for intermediate artifacts, we might not want to templatize target-dir as that will push people down one path moving intermediate artifacts and then we completely change it on the user what path they should go, rather than having a stable story for how to handle this

While we acknowledged the potential for user confusion with CARGO_TARGET_TMPDIR, we were fine with it not being associated with target-dir
The general shape of what we proposed in the meeting is...
Shiny future
target-work-dir: Home of intermediate artifacts

Goals:

Move intermediate artifacts out of source
Don't force a transition for what term/variable people reach out to to access final artifacts

name is a placeholder
No CLI flag for target-work-dir
Precedence (note the lack of target-dir)

target-work-dir config
target-work-dir default ("{cargo-cache}/target/{workspace-manifest-path-hash}")

target-artifact-dir: Home of final artifacts

Goals:

Provide profile-agnostic path
Provide a way for users to opt-out of the target-platform from being elided when building for the host-platform

name is a placeholder (e.g. do we want the target prefix)
--artifact-dir CLI flag is added
will error if {platform} or {legacy-platform} is not present with multi-target builds
Precedence

target-artifact-dir config / cli
target-dir config / cli
target-artifact-dir default ("{workspace-root}/target/{legacy-platform}/{profile}")

Legacy target-dir

--target-dir is hidden on CLI.  Maybe shows up in man pages
No templating supported

Other

CARGO_TARGET_TMPDIR points within target-work-dir

Path to Shiny Future
target-work-dir
In theory, we could trivially do this by

locking target-work-dir and target-dir (if different)
doing all work in target-work-dir and only when we do the "hardlink or cp" do we reference target-dir

Initial default is "{workspace-root}/target"
Template supports

{workspace-root}
{cargo-cache} (pointing to CARGO_HOME for now)
{workspace-manifest-path-hash}

Steps

Implement
Call for testing
Stabilize with opt-in to new location
Call for testing
Switch to opt-out

Notes:

Throughout those steps, we would work closely with tool authors to make sure they had a smooth transiti
The opt-in/opt-out could either be

.cargo/config.toml target-work-dir field
A one-off environment variable if we don't want to stabilize the above yet

target-artifact-dir
Assumption: target-work-dir takes some pressure off of target-artifact-dir
Defaulted to final location ("{workspace-root}/target/{legacy-platform}/{profile}")
Template supports

{workspace-root}
{cargo-cache} (pointing to CARGO_HOME for now)
{workspace-manifest-path-hash}
{platform}
{legacy-platform} (elides host-target)

Needs all of the details in the tracking issue to be finalized.
Contingencies
If target-work-dir takes more than N time (1 year?) to stabilize, then we re-evaluate approving rust-lang/rfcs#3371.  This is to try to balance the needs of the people who want something like rust-lang/rfcs#3371 now vs (1) the long-term inapplicability of that RFC and (2) the lack of stable "blessed" workflow for users (telling users to use solution X for several months and then telling them that is no longer "right" and they need to use solution Y).
Alternatives

Maintain target-dir as the "artifact base dir" and provide a query command (like buck2 analyze) to ask what the "artifact dir" is
Don't expose target-artifact-dir in CLI, leaving it for more advanced uses
Have only target-dir and target-artifact-dir

Downside: harder end-user transition as they reach out to target-dir for final artifacts.  While we eventually de-emphasize target-dir, those workflows will work just fine

Have only target-dir and target-work-dir

Downside: access to final artifacts is still annoying
Only append final directories ({platform}/{profile}) if no templates are available

Downside: this would be confusing
We do this for {dl} but that is a more limited / off in the weeds use case rather than front and center for users

Change the meaning of target-dir if target-work-dir or target-artifact-dir is present

This gets confusing

Something we overlooked in the above analysis is other "artifacts".  In particular, I'm thinking of cargo package which places files in $CARGO_TARGET_DIR/packages.  I'm assuming at least the .crates location is part our stable API.  We'd need to decide about the files laid out on disk next to it.
Ways of solving this

Like examples going to examples/, we could make the profile and target template dirs blank and always put this under packages/
We could have a high level {default} variable that is artifact-specific.

Just commenting here as I'm dealing with my own issues regarding the target dir, but personally, while it's nice for target to contain final build products only by default, I still will want all of these build products out of the target directory for the sake of excluding them from backups and snapshotting.
For some context, I use ZFS snapshots as a form of fast local backups; not long-term backups in case of hardware or extreme software failure, but decent short-term backups in case I accidentally delete a file or mess up an update. However, I explicitly go out of my way to exclude as many things as possible from auto-snapshotting that qualify as "cache" because they can very quickly clog up my disk if I'm not careful.
(Also: since snapshotting is a filesystem-level feature, I can't just say "don't save files of this type in snapshots" since snapshotting works by instantly copying the state of the FS, and doesn't copy files over like a long-term backup would.)
For example, today I just deleted 200 GiB of snapshots of target directories. Not the current target directories, but past versions of them from previous snapshots. Snapshots are good for incremental stuff like code because they're copy-on-write, but the contents of a binary are effectively random to any snapshotting tool and they'll end up being fully duplicated every time they're snapshotted, and that means you can end up with several times that amount of data in snapshots until everything eventually gets old enough to be deleted. The "effectively random" part also applies especially to the final products, since while crates that don't change won't change in their compiled artifacts, the final linked products definitely will.
So, as far as I'm concerned, moving the final build products back into the workspace without also having the option to keep them out effectively un-solves the problem that moving the target directory was meant to solve. After all, the final build products, modulo LTO (which isn't really going to happen for debug builds) will effectively be the same size as all the intermediate products, so, that means that about half the disk usage will not be saved. (I'm extremely approximating here; the point is that it's a considerable amount of the disk usage, even if it's not half. Even 10% of the size is still a lot when you consider that these are being multiplied across several snapshots.)
And note that yes, other languages like Node and Python also have this exact same problem, but I don't think that other languages' inability to solve this problem forgives Rust not solving it. Also, even though node_modules can be massive, hundreds of GiB of binary artifacts is pretty hard to beat.
I love the idea of keeping intermediate products deduplicated and in one place. I just don't want that to obscure the goal of having the final products also somewhere else too.

After all, the final build products, modulo LTO (which isn't really going to happen for debug builds) will effectively be the same size as all the intermediate products

No, the intermediate products are usually many many times larger. Not just double, they can be 1000× larger! On the project I'm currently working, a debug build of 20MB executable creates 2300MB of junk in target/.
There are often many duplicate copies of libstd and other dependencies in each .rlib file. There is a lot of duplication across code units. There's plenty of completely unused objects included in the dependencies, and stripped even without LTO (rust relies on --as-needed flag). There are also often separate copies for build dependencies, builds with cfg(test), incremental build cache,

@clarfonthey the plan calls for both target-work-dir and target-artifact-dir to be templated so you can move their content out.  It does not call out templating of target-dir as it calls for phasing that out.  If we wanted to templatize it as a convenience way of setting both of the above, we'd likely want to wait for the above so we set the precedence for what people are generally expected to work with, rather than shifting expectations around on the user.

I still will want all of these build products out of the target directory for the sake of excluding them from backups and snapshotting.

FWIW, I've had decent results with target being a symlink to somewhere that is not subject to backups/snapshotting. cargo clean will remove the symlink, but everything else I've used is largely fine. Note that this puts intermediate and final artifacts into the same bucket.

I'm in the same boat as @clarfonthey, but with BTRFS snapshots, which I create every 15 minutes and then stream to longer-term storage. My debug builds at easily 2.5G and I clean up target that is 300-700G basically every week.
I created ~/.cache/cargo/{git,registry,target} for this reason, where ~/.cache is in a separate subvolume that is not subject for snapshotting/backups. ~/.cargo/{git,registry} are symlinks now (still hoping cargo starts respecting XDG one day) because they also grow to substantial sizes (currently 1.08M files and 24.1G together).
Proposed separation (especially templating for both new options) should work nicely for such use case, CARGO_TARGET_DIR in .profile has major consequences for build times when jumping between projects.
Excited!

Personally I also don't care about having the artifacts copied anywhere, I access them via cargo run etc. directly from the work-dir anyway. It'd be nice if we could do something like target-artifact-dir = false to just disable it.


not possible to call a method for an expression that has the NULL

Please provide us with the following information:

This issue is for a: (mark with an x)
- [x ] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

On a Win10 20H1 Machine in Powershell ISE (64bit) with the following restrictions:
PS C:\Windows\system32> Get-ExecutionPolicy -List

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process    Unrestricted
  CurrentUser    Unrestricted
 LocalMachine    Unrestricted

Any log messages given by the failure

PS C:\Windows\system32> C:\Users\TesterTest\Desktop\test-connection.ps1
It is not possible to call a method for an expression that has the NULL.
In C:\Users\TesterTest\Desktop\test-connection.ps1:167 Zeichen:5
+     $currentPrincipal = New-Object Security.Principal.WindowsPrincipa ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull

PowerShell is NOT running with elevated privileges

Recommended action: This test needs to be running with elevated privileges

Script completed successfully.

Expected/desired behavior

Script works
OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

Versions

Mention any other details that might be useful

Thanks! We'll be in touch soon.

Same issue here.
The script fails because of
New-ScheduledJobOption: The 'New-ScheduledJobOption' command was found in the module 'PSScheduledJob', but the module could not be loaded. For more information, run 'Import-Module PSScheduledJob'.


fix: unit tests for replay. Closes #373

Signed-off-by: Yashash H L<EMAIL_ADDRESS>

Could you please add a unit test that invokes ctx.Done() path too?


Trace: Implement built-in trace for xplat

Implements a standalone solution to trace function calls in a *nix application
See additional embedder notes inside the source code comments

moved into #2296


Current context not work for new line(new code), I miss something?

Neovim version: v0.5.1
System: openSUSE x64
Everything is ok when opening the file. When adding new code to the file, the indent line highlight not work for new line.
there is a gif(need to click the picture with the mouse to play it in the new tab):

this is my config:
call plug#begin(stdpath('config') . '/plugged')
Plug 'nvim-treesitter/nvim-treesitter', {'do': ':TSUpdate'}
Plug 'lukas-reineke/indent-blankline.nvim'
call plug#end()

lua << EOF
vim.g.indent_blankline_show_current_context = true
vim.g.indent_blankline_use_treesitter = 1
vim.g.indent_blankline_context_patterns = {
  'class',
  'function',
  'method',
  '^if',
  '^while',
  '^typedef',
  '^for',
  '^object',
  '^table',
  'block',
  'arguments',
  'typedef',
  'while',
  '^public',
  'return',
  'if_statement',
  'else_clause',
  'jsx_element',
  'jsx_self_closing_element',
  'try_statement',
  'catch_clause',
  'import_statement',
  'labeled_statement'
}
vim.g.indent_blankline_buftype_exclude = {"terminal"}
vim.g.indent_blankline_show_trailing_blankline_indent = false

vim.cmd [[highlight IndentBlanklineIndent1 guifg=#E06C75 gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent2 guifg=#E5C07B gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent3 guifg=#98C379 gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent4 guifg=#56B6C2 gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent5 guifg=#61AFEF gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent6 guifg=#C678DD gui=nocombine]]

require("indent_blankline").setup {
  context_highlight_list = {
    "IndentBlanklineIndent1",
    "IndentBlanklineIndent2",
    "IndentBlanklineIndent3",
    "IndentBlanklineIndent4",
    "IndentBlanklineIndent5",
    "IndentBlanklineIndent6",
  },
  show_current_context = true,
}
EOF
augroup IndentBlanklineContextAutogroup
    autocmd!
    autocmd CursorMoved * IndentBlanklineRefresh
augroup END

fixed! +1

@yyangdid How did you fix it? I encountered this in Python. But run:
:lua print(require "indent_blankline.utils".get_current_context(vim.g.indent_blankline_context_patterns))

shows false. The treesitter seems to not update the newly pasted code. Updated neovim and treesitter but still not working. A workaround is to run :e but that will mess up the folding 😖

I haven't used nvim for some time, I can't remember how it was solved at that time.
In fact, I've converted to VSCode + remote-ssh.
But I backed up my nvim configuration, you can check these two config files:

indent-blankline config: indentblankline.lua
treesitter config: treesitter.lua

I hope it helps, good luck.


[IGNORE] wait for stable canvas in stories

This should hopefully fix some of the flakiness we're seeing in our storybook snapshots for charts that use canvas in happo.
Checklist

[x] Pull request has a descriptive title and context useful to a reviewer.
[x] Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, IGNORE.
[x] All commits have DCO signoffs.
[x] Changes that impact the UI include screenshots and/or screencasts of the relevant changes.

TODO

[x] Email Happo to share a feature request for an async waitFor.

Screenshots
Note that in the before, the animation in the gauge chart hasn't finished and in the after it has.

Henric got back to me with an easier workaround for the async that I'm going to adjust this to use.