Add a tool to create and render stageable changelog entries

Writing changelog entries is not super fun. Writing them after the fact, especially when you didn't write the original feature, is even less fun. And merge conflicts because of synchronizing a changelog file are SUPER not-fun.
This PR solves those problems. It introduces a changelog tool similar to what many of the SDK teams use (and indeed cribs some code from them).
Workflow

When creating a pull request, you create a changelog entry by running .changes/new-change. This creates a JSON file in .changes/next-release/ containing the changelog entry and its metadata (e.g. whether it's a documentation change, feature change, etc.)
When the pull request is opened a GitHub action will automatically add a PR comment with a suggestion that you can click on to add the PR number.
During a release, the changelog is updated by running .changes/render --release-version 1.2.3. This compiles all pending changes in .changes/next-release/ into a single file in the .changes/releases/ directory. It then renders all of the releases in .changes/releases/ into a markdown file that can be written to CHANGELOG.md. If for some reason the changelog needs to be re-rendered out of band, ./change/render can be called without a version to just do the rendering.

In effect, the canonical source for the changelog becomes the changelog JSON files, and the actual markdown representation is just a derived artifact.
Why?
Using distinct files for changelog entries solves a major problem: merge conflicts. These are horribly annoying to deal with during development, especially on a file that is essentially documentation and semantically has no reason to ever conflict. This problem is less bad for Smithy itself than it is for SDKs that have daily releases, but it's a problem for us too with our relatively large team.
What's different?
This differs from what other SDKs do in a few ways. Firstly, and most notably, we aren't deriving a version number from these. We could! It would not be hard! But I elected not to do that in this PR since it's not as big a problem for us.
We also have a habit of linking the PRs for all of our changes in the changelog. This is actually kinda annoying because it creates a bit of a chicken-egg scenario. This is why I added the github action to automatically add it. If the action is annoying we can always get rid of it and just stop relying on the links. But that would be a shame.
Mechanically there's also a change in that I used modern python to write this, and updated any borrowed code to also be modern python.
Why not use jmeslog?
jmeslog is a standalone tool derived from the python team's changelog tool (which started it all). It is essentially exactly what they do and want, but there's a few things that prevent us from using it. Notably, we need the current date and pr links. jmeslog doesn't have that and doesn't currently allow for easy extension in that way.
It also has things we don't necessarily want, like a category. That's really mostly used in the sdks to indicate changes made for a particular service. With hundreds of services, that's an issue worthy of calling out. But smithy itself doesn't need it.
But also, it's a dependency, and it has dependencies. I'd rather not have dependencies if I can avoid it. And what we need is ultimately not that complex. And doing it ourselves gives us some flexibility.
All that said, there's definitely a world where jmeslog is updated to a place where we can more comfortably use it.
Why not derive changelogs from commits?
The audience for changelogs and the audience for commit messages are two separate (though sometimes intersecting) audiences. Commits may contain conext about technical junk that only mattters to people working on the code itself.
There is also not necessarily a 1-1 relationship between a changelog entry and a commit. Large features are often broken up into logical commits that make reviewing and code diving easier, but aren't important to the changelog. You might also have commits that make changes unimportant to the changelog audience, such as formatting changes or changes to CI configurations.
Commits are also, critically, immutable. Did you make a typo in your commit? Now it's preserved forever in your changelog. With JSON files, you can just change them. Those changes are now part of the commit record!
Also, on a more subjective level, have you seen repos that have semantic commits? They're ugly.  And if you're following best practices for commit messages, that's eating into your 50 character limit for the title.
Any unfortunate bits?
There's no line wrapping, so you better believe the changelog is gonna have some long lines. It doesn't really matter though, because it'll all be natural when you're seeing it fully rendered. The line boundary thing these days mostly helps with readability when you're editing a file, but you will never manually edit the file.
Also the automated commit will hide the status checks in GitHub's UI for some reason. That's why it's only added after all the other checks and isn't run if said checks fail. Also why you can do it manually.
What's next?
Provided this goes through, the next step will be to backfill all the current changelog entries. That'll certainly be a task.
A github action to create the version bump pr would be sweet. We'd need to add the ability to derive a version number from the feature list, which isn't hard. Then the script could just aslo perform the version bump by writing that one file. Then it could be just a button press away in github. Maybe as a fully automated release?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Since initially opening this PR I had to change the way the GitHub action worked. Previously when it detected an introduced changelog without an associated PR it would just amend it and push a commit. It turns out that this is a permissions nightmare on a PR from a fork that isn't easily resolveable as it would need permissions from each of the forks. A bit annoying, to say the least.
So I changed it to instead post a review comment. The genius of this being that  whoever opens the PR is doing the committing, so no permission issues! Except there were permission issues. Solveable this time though. The new problem was related to the old - when handling a PR from a fork, posting comments would fail. In this case, I lacked permissions for the main repo. I lacked those permissions because the maximum permissions level for a pull_request GitHub action triggered by a fork is read.
The workaround is to instead use pull_request_target, which runs the action from the context of the target (i.e. main) instead of the PR. With this, we can have those elevated permissions. The downside is that the action won't run on this PR because it doesn't exist on main yet. You can however see how it works in this closed testing pr.
I split the PR into two commits. One of those commits is just the action, so that it can be reverted if it ends up being a menace without having to revert the entire tool.


Add GISAID accession numbers

Also need to make these searchable..

Have search by accession number working locally.

Added with commit 7b2e3164edf62860b79448d53493c83719996e16
See #37 for implementing search


Move Kernels.cu to Alpaka

Moves the kernels found in Kernels.cu to Kernels.cuh and over to alpaka. I also deleted Kernels.cu since there was no code left in the file after the change. This PR also removes the unnecessary Constants.h file.
One note, I had to change the thread size from (1, 32, 32) to (1, 16, 16) for the "removeDupPixelQuintupletsInGPUFromMap" kernel since the original thread size resulted in a runtime error relating to invalid configuration. The maximum threads per block is 1024, so I'm not sure why (1, 32, 32) throws an error, but (1, 16, 16) is faster anyway as you can see from the timing. This does not throw an error in the CUDA version, so this error is specific to something in Alpaka.
This PR Timing

Current Alpaka_Move Timing

Validation Plots: Here
Comparison to Master: Here

Also, I think the reason constants.h was .h and not .cuh was because it is used in code/core/write_sdk_ntuple.h. I'm not sure if a .cuh file will work there or not.
It is needed in that file in case we switch around the half vs full precision. I think changing the data types can cause issues if they don't match up. Are you running alpaka with half precision? If not, perhaps that is why it seems to run ok now? What is your memory usage with alpaka?

Also, I think the reason constants.h was .h and not .cuh was because it is used in code/core/write_sdk_ntuple.h. I'm not sure if a .cuh file will work there or not. It is needed in that file in case we switch around the half vs full precision. I think changing the data types can cause issues if they don't match up. Are you running alpaka with half precision? If not, perhaps that is why it seems to run ok now? What is your memory usage with alpaka?

Actually browsing the code, I don't see the half precision switch in the write_sdl_ntuple file. Which is sort of strange. I don't remember it being removed. But if that is the case than constants.cu -> .cuh seems reasonable.
And I guess you aren't removing Kernels.cu just moving everything to kernels.cuh. which seems fine. though perhaps renaming it would still be good.
Otherwise, I think this looks good.

Thanks for going through the PR and the comments, @tresreid!

browsing the comments, the "scoreX" functions can probably be removed. These were historically used to get the r-z chi2 values which were used for duplicate removal. But those are now implemented in the runtime of building the objects and the scores are saved directly there.
The checkX and rmXtomemory should all be kept as they are still used to look for duplicates between objects and to mark objects as duplicates.

Ok, that's exactly what we do here and the main of my question. So the PR is good to go once Gavin finalizes the few minor comments left.

A lot of the functions within code/core are used for the CPU part and should be purged but I think there was an issue doing this before. I think the issue was that a lot of the validation and writing to the Ntuple stuff uses some of these functions. @sgnoohc would know best since the CPU side of things were all his domain.

Sure. I guess we will hit that wall when Gavin makes the relevant PR and we can involve Philip in the loop then, so that everything is done properly.

It is my preference that constants.cu should be kept. I think this should be our config file where we define all of our constants and cuts. So if we need to change something, we change it there instead of having to dig through 100000 lines for code to figure out what needs to be changed. Take for example the PT cut that we are still apparently having issues with. Since this is implemented throughout the code, when we wanted to change it we had to find all the instances of it being used. If this was set in one easy to find place we wouldn't still be having this issue. Same for all other cuts. And in the future we can feed this into some ML implementation (like TMVA) to help try to optimize these cuts. I think it is worth the clarity to keep.

I totally agree and this is the direction we are moving with this PR, right? Our goal would be to have only Constants.cuh and Constants.cu which will include all of the constants and "configuration variables" throughout the code.

Kernel.cu I would prefer if we kept since many of those functions are used for duplicate removal and are used in several places for different objects. For example, I believe the checkPLs function is used for pT5, pT3 dup rm and cross cleaning. I think this is the best place for it rather than within the larger pixelobjects file(s). Maybe rename it to DuplicateRemoval.cu or something that clarifies the purpose. I don't think having the extra file hurts us in any real way here.

Unless I have misunderstood, the plan was to anyways keep the Kernels files. But all the functions had to be moved from Kernels.cu to the Kernels.cuh file due to this.
I am fine with renaming as long as the name is descriptive, so I leave it up to @GNiendorf to decide.

Also, I think the reason constants.h was .h and not .cuh was because it is used in code/core/write_sdk_ntuple.h. I'm not sure if a .cuh file will work there or not.

But the validation plots, which run the NTuple, worked fine, so it should be fine, right?

It is needed in that file in case we switch around the half vs full precision. I think changing the data types can cause issues if they don't match up. Are you running alpaka with half precision? If not, perhaps that is why it seems to run ok now? What is your memory usage with alpaka?

My understanding is that we are still running with half precision. Alpaka does not support it but it works since we are only compiling for the "cuda" backend up till now (@GNiendorf please correct me if my understanding is not right). In the long run, we would probably have to either drop it or check with the developers if it's going to be supported in some way. I would leave that as a final step in the migration but of course Gavin is the best person to decide that.
Memory usage should be checked at some point - I guess this can happen once all of the kernels have been migrated and before we migrate the memory transfers?

Yeah, This is something I would have to look into but if everything works fine as is then i guess it isn't an issue.

Thanks for going through the PR and the comments, @tresreid!

browsing the comments, the "scoreX" functions can probably be removed. These were historically used to get the r-z chi2 values which were used for duplicate removal. But those are now implemented in the runtime of building the objects and the scores are saved directly there.
The checkX and rmXtomemory should all be kept as they are still used to look for duplicates between objects and to mark objects as duplicates.

Ok, that's exactly what we do here and the main of my question. So the PR is good to go once Gavin finalizes the few minor comments left.

A lot of the functions within code/core are used for the CPU part and should be purged but I think there was an issue doing this before. I think the issue was that a lot of the validation and writing to the Ntuple stuff uses some of these functions. @sgnoohc would know best since the CPU side of things were all his domain.

Sure. I guess we will hit that wall when Gavin makes the relevant PR and we can involve Philip in the loop then, so that everything is done properly.

It is my preference that constants.cu should be kept. I think this should be our config file where we define all of our constants and cuts. So if we need to change something, we change it there instead of having to dig through 100000 lines for code to figure out what needs to be changed. Take for example the PT cut that we are still apparently having issues with. Since this is implemented throughout the code, when we wanted to change it we had to find all the instances of it being used. If this was set in one easy to find place we wouldn't still be having this issue. Same for all other cuts. And in the future we can feed this into some ML implementation (like TMVA) to help try to optimize these cuts. I think it is worth the clarity to keep.

I totally agree and this is the direction we are moving with this PR, right? Our goal would be to have only Constants.cuh and Constants.cu which will include all of the constants and "configuration variables" throughout the code.

Kernel.cu I would prefer if we kept since many of those functions are used for duplicate removal and are used in several places for different objects. For example, I believe the checkPLs function is used for pT5, pT3 dup rm and cross cleaning. I think this is the best place for it rather than within the larger pixelobjects file(s). Maybe rename it to DuplicateRemoval.cu or something that clarifies the purpose. I don't think having the extra file hurts us in any real way here.

Unless I have misunderstood, the plan was to anyways keep the Kernels files. But all the functions had to be moved from Kernels.cu to the Kernels.cuh file due to this. I am fine with renaming as long as the name is descriptive, so I leave it up to @GNiendorf to decide.

Yeah ok. I initially misunderstood from the comments what was happening when you were removing those files. But understanding now that the functions are being moved to header files, I think everything is fine.

Timing

Comparison Plots: Here


addAppNamespace sporadic issues

Sometimes, after deployment of the NW plugin, no POD is able to start. The vswitch logs contain the following issue:
adding app namespace returned non-zero return code

It seems that this is mostly reproducible if not all the system containers have initialized before deploying the plugin, but this needs further investigation.

issue-log.txt

2017-11-22 07:29:58,330 DEBG 'contiv-agent' stdout output:
time="2017-11-22 07:29:58.33044" level=warning msg="Ignoring pod IP releasing for pod ID that is empty string (possible echoes from restart?)" loc="ipam/ipam.go(325)" logger=cni-grpc tag=00000000

2017-11-22 07:29:59,035 DEBG 'contiv-agent' stdout output:
time="2017-11-22 07:29:59.03496" level=warning msg="Timeout of resync callback" loc="kvdbsync/watch_impl.go(142)" logger=defaultLogger tag=00000000
time="2017-11-22 07:29:59.03508" level=info msg="Resync of K8s resources took 4.001297169s" durationInNs=4001297169 loc="resync/plugin_impl_resync.go(99)" logger=resync-orch tag=00000000

2017-11-22 07:29:59,152 DEBG 'contiv-agent' stdout output:
time="2017-11-22 07:29:59.15211" level=info msg="Stn configured" loc="contiv/remote_cni_server.go(394)" logger=cni-grpc tag=00000000

2017-11-22 07:29:59,162 DEBG 'contiv-agent' stdout output:
time="2017-11-22 07:29:59.16210" level=error msg="adding app namespace returned non-zero return code: -30" loc="contiv/remote_cni_server.go(398)" logger=cni-grpc tag=00000000


Registering single client as multiple applications in Spring Eureka

We are using Spring Eureka for service registry in our project. There are 12 microservices and each microservices serves 4-5 functionality.
For example a microservice called "MathOperations" serves functions like addition, subtraction, multiplication. With the help of Eureka, if I want to call one of the method, I will be invoking a REST call "http://MathOperations/addition". Now, the problem is, I dont want "MathOperations" to be there in url. I just want to call "http://addition", it should invoke the mathoperations addition method and respond with the result. It is ensured that, all the functionalities will have a unique name across microservices.
This is my thought process (correct me if I'm wrong), Can I register each functionality as a service to Eureka?

No I dont think so.

How would the service know what it was performing addition without the /addition path?

Can we register an application as multiple service like "addition", "subtraction" etc.,? Then, when we hit http://addition, it has to be routed to addition method.

No. Service Discovery is limited to, essentially, the host and port the service is running on.


[BUG] Transient issue with mismatch x-ms-client-request-id error occurring when upgrading to Azure.Storage.Blobs v12.15.0

Library name and version
Azure.Storage.Blobs v12.15.0
Describe the bug
A transient issue is occurring where upgrading to v12.15.0 of Azure.Storage.Blobs will cause a transient issue where the following client side SDK error will occur.
Response x-ms-client-request-id '<response-client-request-id>' does not match the original expected request id, '<original-client-request-id>'.
Downgrading to Azure.Storage.Blobs v12.14.1 helps mitigate the issue.
We were not able to get logs to confirm the mismatch in client request id. We were also not able to get a network trace on whether the issue was in a proxy or firewall or cache changing the x-ms-client-request-id.
So far doesn't seem like the issue is in Azure.Core
Expected behavior
A transient error of mismatch client request id does not occur.
Actual behavior
Mismatch client request id error occurs.
Reproduction Steps
n/a
Call any Storage API
Environment
Azure.Storage.Blobs v12.15.0
AKS cluster

Looking for any one else who has hit this issue and has logs available for us to look further into this issue. Or a different environment set up as well.

We also see this in our logs.

Related issue:
https://github.com/microsoftgraph/msgraph-sdk-dotnet/issues/1734

Thank you for the update, good to hear! Do you have an idea when the next release is?

We're aiming to see if we can do a release next week with just the change to point at the latest Azure.Core release.
Will update the thread if anything changes.

@vedion We were actually able to release today. So when available please upgrade to Azure.Storage.Blobs v12.5.1 which points at Azure.Storage.Common v12.14.1 which points at Azure.Core 1.30.


AWS::Serverless::Api - Auth property doesn't allow intrinsic functions?

I am currently deploying an API to multiple environments (prod, test, dev). I would like to turn off "Auth" in dev so we can focus on developing post-login features in that environment. However it is not possible to conditionally add the "Auth" property to my Api resource because of how we are validating:
https://github.com/awslabs/serverless-application-model/blob/4fa5d6a4ec60e82681daae6f0ff9d7669642c266/samtranslator/model/api/api_generator.py#L312
Therefore something like this is not possible currently:
Api:
  Type: AWS::Serverless::Api
  Properties:
    ...
    Auth:
      Fn::If:
        - IsDev
        - !Ref "AWS::NoValue"
        - DefaultAuthorizer: CognitoAuthorizer
          Authorizers:
            CognitoAuthorizer:
              UserPoolArn: !GetAtt UserPool.Arn
              Identity:
                Header: Authorization
                ValidationExpression: "."

@beatleboy501 This should be resolved in a pr https://github.com/awslabs/serverless-application-model/pull/1179 going out in v1.16 release.

The intrinsic mapping for API was not added in v1.16 or v1.20.0 from what I can see. I can see intrisic mapping for function deployment preferences (https://github.com/awslabs/serverless-application-model/pull/1196)


Event refactor

Description of the change
This refactor addresses multiple deficiencies with how we transfer information from our front-end API to our internal Notifier process.
This refactor solves multiple bugs, and presents a scalable mechanism to add new functionality in a composable way with the least amount of changes due to a very modularized scheme.
What changed:

The Notifier used to represent a sandboxed/isolated boundary between the SDK's innards and its API. Now the Notifier is just another switchable self-contained module just like the Transformer, Sender and Marshaller.
A new Sandbox module that represents the aforementioned isolated boundary which offers two flavors: async useful for unit testing, and isolated which leverages Dart's Isolates.

We keep the same level of security by sandboxing our memory, and full thread-enabled concurrency.
This helps remove business logic from the Notifier, which used to handle both the process pipeline and the isolation.

The way the API forwards messages to the Notifier is through Event instances, which is a type-safe way of encoding action and the data associated with such action. This event is dispatched to the Sandbox and the Sandbox sends it to the Isolate stream, and then it's given to the Notifier.
The Notifier encodes the pipeline that processes these Events.

There are two types of Events:

Events that modify context (the SDK's state): In this case, the Notifier acts as a simple Reducer that modifies its internal state given the Event's data.
Events that forward data to Rollbar's API: In this case, the event is put through the Marshalling pipeline, the data is transformed if necessary, persisted and then sent.

Wrangler has been renamed to Marshaller.

Type of change

[x] Bug fix (non-breaking change that fixes an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Maintenance
[ ] New release

Related issues

Shortcut stories and GitHub issues (delete irrelevant)

Fixes https://github.com/rollbar/rollbar-flutter/issues/91
Fixes https://github.com/rollbar/rollbar-flutter/issues/93
Closes https://github.com/rollbar/rollbar-flutter/issues/83
122325, 122324

Checklists
Development

[x] Lint rules pass locally
[x] The code changed/added as part of this pull request has been covered with tests
[x] All tests related to the changed code pass in development

Code review

[x] This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
[x] "Ready for review" label attached to the PR and reviewers assigned
[x] Issue from task tracker has a link to this pull request
[ ] Changes have been reviewed by at least one other engineer

@diegov I'm gonna have to fix the CI on a different PR. There's some general work I'll need to do to prevent it from failing every time we do certain kind of changes. Do you think you could approve so I can merge?


Fix installed pkg-configs

Commit 2239556 patched the pkg-config files during installation, but
forgot to escape references to the prefix variable.

This seem like a patch that will be needed ton Debian.

Not only. By not escaping ${prefix}, you're gnerating -L/lib${prefix} instead of the (I guess) intended -L${prefix}/lib.

Please ignore this request. I've found a cleaner way to fix this installation problem, and moved it into a separate branch to allow other fixes to be merged concurrently. I'll open a new pull request for the new branch.


Monitoring of the tiki chain

Using a combination of sentry and amplitude as developers should be able to determine the volume and performance of the tiki chain spanning from minting to backup.
Acceptance Criteria:

Mint rate
Backup ratio
Bug/performance monitoring from start to finish

bug monitoring will be done by sentry in
https://github.com/tiki/wallet/issues/32
https://github.com/tiki/localchain/issues/18


Introduce LogAnnotation

Type-safe annotations for loggable values

Rename into TofuAnnotation because conflict with zio.LogAnnotation

Rename to TofuAnnotation because conflict with zio.LogAnnotation

It hides the intention IMO. Perhaps TofuLogAnnotation is better


Add --retry option for autify web test run

In some cases, Autify users want to automatically retry specific tests a limited number of times (once or twice) until it passes. If Autify CLI can support this (with --retry option along with --wait option), that would be great.

@meih Thank you for the feature request. We released --max-retry-count in beta channel. Feel free to try it out and give us any feedback! https://github.com/autifyhq/autify-cli/pull/104
autify update beta
autify web test run --wait --max-retry-count 2

Cool!  Thanks for implementing this so quickly.


Try to fix GitHub CI pemissions

Describe the bug
There are currently two actions in the CI that require write permission to the repository in order to work correctly: the documentation generation and the coverage report generation.
Steps to reproduce the behavior:
See CI on #400.
Expected behavior
The CI should not be failing on expected missing permissions. We should either:

fix the CI to work even when the PR is from a branch outside of the tqec repository.
let the actions requiring write permission fail silently.

Options

Related discussion about this error in peaceiris/actions-gh-pages: https://github.com/peaceiris/actions-gh-pages/issues/1102, where they recommend to change permissions.
We could use continue-on-error  a job can then still pass.

I can create a PR for the second one, if that's what you prefer.

Options
1. Related discussion about this error in `peaceiris/actions-gh-pages`: [support:  unable to access 'https://github.com/saigkill/SaschasToolbox.git/': The requested URL returned error: 403 peaceiris/actions-gh-pages#1102](https://github.com/peaceiris/actions-gh-pages/issues/1102), where they recommend to change permissions.

2. We could use [`continue-on-error` ](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error) a job can then still pass.

I can create a PR for the second one, if that's what you prefer.

Option number 1 is not the reason, the current permission is read/write (like in the screen shown). It is due to the fact that branches from external contributors (i.e., not from the tqec repository) are considered potentially insecure and are not given the write permission. continue_on_error seems like a good solution, you can create a PR :) Also, try to create it from your own account (which should be your only option as you should not have the right to create a branch in tqec/tqec) to test live.


Correcting mostly small typos while I was reading the README

You will have hard time to see what I changed because you mostly use a line per paragraph. I suggest you limit lines to less than 80 characters so they are easily side by side diffable and let the .md processor join them together.

Thanks a lot for the edits @gae123


Provide source information for deprecation warnings from extensions

Coverage decreased (-0.02%) to 95.018% when pulling be46fe6f8a5398b80f8aa0b123cb2de2ebdf3e85 on drdavella:extension-warnings into 111d1ec98571ef3bb1e446993df68255f5c898d8 on spacetelescope:master.


Fix incorrect uses of inline namespaces in spec

  // [execution.queries], general queries
  inline namespace unspecified {
    struct get_scheduler_t;
    inline constexpr get_scheduler_t get_scheduler{};
    struct get_allocator_t;
    inline constexpr get_allocator_t get_allocator{};
    struct get_stop_token_t;
    inline constexpr get_stop_token_t get_stop_token{};
  }

The idea was for get_scheduler_t to not have std::execution as an associated namespace, since we don't want to end up looking there for tag_invoke overloads. However, inline namespace doesn't achieve that.
Proposed resolution
Change this to:
  // [execution.queries], general queries
  namespace general-queries {
    struct get_scheduler_t;
    struct get_allocator_t;
    struct get_stop_token_t;
  }
  using general-queries::get_scheduler_t;
  using general-queries::get_allocator_t;
  using general-queries::get_stop_token_t;

  inline constexpr get_scheduler_t get_scheduler{};
  inline constexpr get_allocator_t get_allocator{};
  inline constexpr get_stop_token_t get_stop_token{};

Apply this change everywhere.

@ericniebler : I can work on this, but I propose a 2-phase fix for this issue:

make the changes just in .bs spec
also make the changes in the code

I think it would make sense to fix 2) only after the unit tests that I have are merged (one PR pending and another set of commits that are not yet up). This way, we also have the change tested.

See PR #377  for the changes in the spec only.

@ericniebler: I'm trying to fix this in the code, and I realize the this introduces a usability problem.
types like set_value_t are not directly visible by the user. The best thing that the user can do is use decltype(set_value) instead. But, this resolves into const hidden_namespace::set_value_t.
While I was trying to make the code work by taking the decayed type, this will not work, as we are violating the specification. For example, take the following code:
    friend inline_scheduler tag_invoke(
        ex::get_completion_scheduler_t<decltype(ex::set_value)>, my_sender) {
      return {};
    }

This will be incompatible with <IP_ADDRESS>, as the CPO passed to get_completion_scheduler needs to be exactly set_value_t. A const set_value_t is illegal.
Thus, that function should become:
    friend inline_scheduler tag_invoke(
        std::decay_t<decltype(ex::get_completion_scheduler)><std::decay_t<decltype(ex::set_value)> >, my_sender) {
      return {};
    }

Similarly a completion signature will look like:
  struct my_sender : ex::completion_signatures<     //
                         std::decay_t<decltype(ex::set_value)>(), //
                         std::decay_t<decltype(ex::set_error)>(std::exception_ptr)> {

As you can see, without type aliases, the user code becomes quite messy.
Please see #392  for how this looks like.
I would propose to also add a note to the specification indicating that the user should use decay_t<decltype(CPO)> (wording change, not semantic change)


[Learn] Automation API Pathway

Adding the Automation API Pathway.
closes pulumi/devrel-team#89

Note: My Falcon API went a bit sideways for the last module. That will go up later tonight.

I'm still reviewing this in detail, but in the meantime, a few things to think about:

The intro could probably do more to explain the problem to be solved, so the overall shape of the solution is clear and well motivated (i.e., "why Automation API?") Without this, I had trouble picturing what we'd be doing and why. A concrete scenario and a diagram could go a long way here, I think -- just a little something more to give me a stronger mental model of what the situation is, what the parts are, what each one's for, and how each step brings me closer to the ultimate goal.

The directory structure and filenames should probably be spelled out more clearly. I'm definitely not strong with Python (working on it!), but I did get confused as to which files were supposed to go where, what they were supposed to be called, etc. (The first thing I did was run pulumi new in learn-auto-api, but at some point I got the sense that maybe wasn't what you'd intended, so I had to go back and do a bunch of cleanup up, renaming, debugging, etc., to get back on the right track, and I never quite made it.)

I get the choice of the Random provider (keeps it simple), but for me at least, it was a bit of a mental shift to think about "random string" as a placeholder for "some theoretical cloud infra", especially since was already making another mental shift to think about driving Pulumi programmatically. I'm not sure what the best alternative is, though -- maybe Docker? Maybe it's okay -- it certainly works with the Random provider -- I just kept having to remind myself that that code wasn't there just to generate a random string, it was there as a stand-in for something else.

Hope this helps as an initial pass -- lemme know what you think.

I'm still reviewing this in detail, but in the meantime, a few things to think about:

The intro could probably do more to explain the problem to be solved, so the overall shape of the solution is clear and well motivated (i.e., "why Automation API?") Without this, I had trouble picturing what we'd be doing and why. A concrete scenario and a diagram could go a long way here, I think -- just a little something more to give me a stronger mental model of what the situation is, what the parts are, what each one's for, and how each step brings me closer to the ultimate goal.

Fair point. I was kinda taking it people are coming to this doc already knowing something about it, but I don't have the insight yet into who is coming from where.

The directory structure and filenames should probably be spelled out more clearly. I'm definitely not strong with Python (working on it!), but I did get confused as to which files were supposed to go where, what they were supposed to be called, etc. (The first thing I did was run pulumi new in learn-auto-api, but at some point I got the sense that maybe wasn't what you'd intended, so I had to go back and do a bunch of cleanup, renaming, debugging, etc., to get back on track, and I never quite made it.)

Ah, good callout. I'm actually debating whether a running file tree might be a good addition to all of these pages, to be honest. It's really hard not to have a gigantic block of code every few lines and still keep everyone on board.

I get the choice of the Random provider (keeps it simple), but for me at least, it was a bit of a mental shift to think about "random string" as a placeholder for "some theoretical cloud infra", especially since was already making another mental shift to think about driving Pulumi programmatically. I'm not sure what the best alternative is, though -- maybe Docker? Maybe it's okay -- it certainly works with the Random provider -- I just kept having to remind myself that that code wasn't there just to generate a random string, it was there as a stand-in for something else.

Yeah, I was trying to avoid the chaos we had with the Docker provider in Fundamentals with M1 and other oddities, but I agree it might be way too theoretical. I'll have to try to make something work, maybe as a follow-up :/

Hope this helps as an initial pass! Lemme know what you think.

It does! Thank you!

I'm actually debating whether a running file tree might be a good addition to all of these pages, to be honest.

Glad you mentioned this! Definitely something to keep talking about as we put these pages to actual use. We have a ton of flexibility, here, so if we want to do more, we totally can.

@cnunciato I figured out how to get Hugo to spit out line numbers for code blocks, but right now it breaks the copy button:

If I choose inline, the button copies the code and the line numbers.
If I choose table, the line numbers get separated, but the button doesn't copy the code.

I'm guessing the copy button looks for a specific attribute. Think it's worth worrying about here in this PR? I was thinking the code was getting complex enough that it might have been worth it, but it's been fussy.
ref: https://gohugo.io/content-management/syntax-highlighting/#highlighting-in-code-fences

:unsure-fry: I may need to re-rebase this...

Blocked by pulumi/theme#145 as this pathway requires line numbers for reference points.

Lint error being fixed in https://github.com/pulumi/pulumi-hugo/pull/1577

Note: Dismissing Kat's review considering PTO and how far it's come.

@cnunciato re:the placeholder images, we've been leaving them for each topic page because the system doesn't render without them (e.g., https://github.com/pulumi/pulumi-hugo/blob/master/themes/default/content/learn/building-with-pulumi/secrets/meta.png). Think we should find a way to remove them as a spike later?


Broken image link in Readme

Description
There's a broken link to to first image in this repo's readme.

Hey, I'll fix it.

Thank you, sir


Incorrectly detects NFS shares are mounted

Actual behavior
Risk Factor: high (inhibitor)
Title: Use of NFS detected. Upgrade can't proceed
Summary: NFS is currently not supported by the inplace upgrade.
We have found NFS usage at the following locations:

Currently mounted NFS shares

Remediation: [hint] Disable NFS temporarily for the upgrade if possible.
Key: 9881b25faceeeaa7a6478bcdac29afd7f6baaaed
Expected behavior
When no NFS shares are actually mounted (as you can see from the preupgrade log message above), there should be no inhibition.
System information (please complete the following information):

OS and version: AlmaLinux 8.10
Linux pvr.interlinx.bc.ca 4.18.0-553.5.1.el8_10.x86_64 #1 SMP Wed Jun 5 09:12:13 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux

leapp-0.14.0-1.el8_6.noarch
leapp-deps-0.14.0-1.el8_6.noarch
leapp-data-almalinux-0.2-7.el8.noarch
leapp-upgrade-el8toel9-deps-0.16.0-6.el8_6.elevate.20.noarch
leapp-upgrade-el8toel9-0.16.0-6.el8_6.elevate.20.noarch
python3-leapp-0.14.0-1.el8_6.noarch

And the problem is here https://github.com/AlmaLinux/leapp-repository/blob/249925a3180b325a2eba40c06486c46d7d9eded8/repos/system_upgrade/common/actors/checknfs/actor.py#L33-L38
But this exact issue was reported upstream  over 2 years ago!  And it was fixed upstream over two years ago.
So why are we still hitting this using 2 year old code?  This project has even released/tagged 0.19.0 so why are we still using 0.16.0?

@brianjmurrell 0.19.0 is in Testing now and expected to become stable in August.
You can use it to migrate now, it's well tested already.
https://wiki.almalinux.org/elevate/ELevate-testing-guide.html

0.19.0 is in stable now so closing


chore: added CSS Dinner in Youtube CSS

Fixes Issue
Closes #557
Changes proposed
It's a fun game to learn and practice CSS selectors.
Screenshots

Updated description

Updated it in ui-generators

Note to reviewers
Any kind of feedback would be appreciated.

@CBID2

Hey @parma1111! :) You're close! :) Just fix the typos and proofreading suggestions and your PR! :)

Hey @CBID2 ! :) All conflicts had been fixed. Now you can review the PR.

@parma1111, looks like @rupali-codes needs to do a force push merge.

@parma1111, looks like @rupali-codes needs to do a force push merge.

I'm looking for it 😅

@rupali-codes @CBID2

@rupali-codes @CBID2

Haha, thanks for your patience Parma, appreciate it :)


Switch to GitHub Actions for parallel builds + publishing?

Hope all is well! :) Just found out that GitHub Actions now has built-in support for Docker buildx + QEMU. This is great news, because it removes the need for custom scripts like linux_circle_vm_setup.sh, therefore reducing complexity in this repo.
Pushing a new multi-platform image is then as easy as: https://github.com/docker/build-push-action/blob/master/docs/advanced/multi-platform.md
We could also build the amd64 and arm64 images in parallel on PRs, using a GH Actions matrix. That should significantly bring down the build time, which is currently 1 hour.
The alternative is to have CircleCI build the images natively on amd64 and arm64 (now that they have arm64 support in beta, which I saw you're already using in drud/ddev 🎉), but I'm not sure if your CircleCI license allows for simultaneous workflows. Building arm64 natively should at least speed things up significantly. When pushing both images to Docker Hub, I believe they still need to be built using QEMU on the same host, but that could e.g. be done with the multi-platform approach in GH Actions as mentioned above (or just leaving it at CircleCI).
So I think would mean there's three options for speeding up PR builds:

Using a GitHub Actions matrix for simultaneous amd64 and arm64 builds from a amd64 host (I wouldn't be surprised if GH adds native arm64 support later this year, they already support self-hosted Linux arm64)
Using native CircleCI machines for both amd64 and arm64 builds in parallel, but again I don't know if your CircleCI license allows for simultaneous builds
Use GitHub Actions for building the amd64 image and CircleCI for the arm64 image natively, that way you still have parallel builds 🤓

Curious to hear your thoughts on this, happy to help!

Outstanding!
Also, we'll be retiring ddev-images and moving this back to ddev, since it's not needed to have ddev-live builds any more. So let's move this back into ddev and incorporate the new workflow at the same time. Thanks!

Alrighty! So then we just update the ddev-webserver image over there, correct? But doesn't it add a LOT of build time to PRs, since this will be building all supported PHP versions (5.6 to 8.0)? 🤯 Any preferred approach here?

I think as a separate build stage would be the ticket, think we can pull that off.  It could also be a separate Dockerfile, but I think different build stage (with proper targeting in Makefile?) .
If you're interested in taking this on, let's do it as a two-stage project

Move the ddev-images logic to ddev-webserver
Start using the build-and-push-docker-images action

Note that https://github.com/docker/build-push-action isn't a GitHub feature, but an action maintained by Docker. It looks like it's getting proper maintenance, but I've sure seen a lot of crappy unmaintained GitHub actions. And some of those I've gotten emails from Github promoting them.
I'm fine with doing all image builds on GitHub, as cost will be important now that there's no (current) funding for the project. We have a good bit of credit left on CircleCI, but my plan is to move everything possible to Github.

A related issue is updating images more often to avoid supply-chain problems, or fix them quickly. To date, the base image build has been only every few weeks or months; the only guaranteed build has been at major release time. But it seems like we should do like a lot of docker images and push new stuff to the same tag, and do it regularly.  Related issue: https://github.com/drud/ddev/issues/2969
So... regular build/push is in our future, so we'll want to be aware of that as we work on automating the push.
Also, figuring out how to do a docker build when something has changed before testing the ddev code is also a planned thing. If we could cache layers it might not be horribly painful. But probably will be. But the current manual technique of having to name a tag and push it manually in order to test isn't good enough.

Hope to have time this weekend to work on the first stage (moving the ddev-images logic to ddev-webserver). If someone reading this already has time earlier that'd be great, feel free to start working on this! Will report back here when I have an update 🚀

I've been tracking ways to build natively and speed things up massively, here's one of them, https://github.com/jesec/rtorrent/blob/master/.github/workflows/publish-rolling.yml


2.0.1+ not registering jobs if autoStartup=false

autoStartup = false should just prevent the scheduler from starting but register and schedule jobs as it used to. currently no job is defined/scheduled at all if autoStartup=false
ref. https://github.com/grails-plugins/grails-quartz/blob/master/src/main/groovy/quartz/QuartzGrailsPlugin.groovy#L285

I moved a Job to a different package and then the Job was not correctly configured, so I think that my fix is not fully correct.
I think that the check on autoStartup should be completely removed


Investigate discrepancies: TCS 1346, TCS 1476

What Happened
From QA notes (thanks @mkewins !):

for tcs 1476, the reports show up on both the new pseudo-intersection and the mid-block... should this happen?

for tcs 1346 (example from the bug report) the data is still in MOVE (7 TMCs), don't know where this data is stored in flow

What Should Happen
Either these should be consistent with FLOW, or we should have a clear explanation for the discrepancy.
To Reproduce
See #529 for original reports and steps to reproduce.

Re: TCS 1476 - there is no actual centreline intersection there; it's part of the midblock, which is why it shows up there.  (In general, intersections with private driveways - into malls, apartment / condo buildings, etc. - are not in the centreline.)  Right now, location selection is tied to centreline locations; changing this is definitely a bigger task than we can get to for next release.
Re: TCS 1346 - this data is in FLOW at Find Stations > First Street: Yorkdale > "HIGHWAY 401 ACCESS RD AT YORKDALE RD (PX 1346)".  (For whatever reason, Find Signals does not surface this data in FLOW; I'm not really sure what that search function is for?)
Marking as closed for now.


Inconsistent results for some layers

Are there any tricks to ensure accurate generation of the different icon sizes?
When I run the plugin, most of the image look correct, but a group involving a repeating symbol does not seem to be scaled down correctly.
I admit to being new with Sketch, so could be something I've done.

To be honest, I'm not sure what could be the problem there. Plugin works by just scaling entire artboard to different sizes, same as if you would manually select artboard then click on scale option, you might wanna try that just to check if the result is same.

Yea, I played with it for a while and the results did seem to be inconsistent, although I'm not sure why. I ended up recreating the layers with rectangles instead of lines, which seems to scale better.
Thanks


CRASH proc ceases execution of caller

I made this work by having the CRASH proc return a special kind of exception. I also swapped around the args to Assert.AreEqual in my tests because I didn't realise it mattered before.

Just edited this to also make the stack overflow exception stop every proc in the stack, instead of just the top-most.


improve swc-plugin package.json template

I had some ideas to improves the generated package.json of the swc plugin new command.

package.json scripts

prepublishOnly (will be run automatically on npm publish)
ensure that the very latest source is compiled.
test
I thought running cargo test might be a better default than "echo \"Error: no test specified\" && exit 1"
what do you think?
dev
maybe this is too much - what do you think?

package.json files

The result will stay the same as before just with less config.
from https://docs.npmjs.com/cli/v7/configuring-npm/package-json#files:

Certain files are always included, regardless of settings:
package.json
README
LICENSE / LICENCE
The file in the "main" field

you can try it with:
npm pack

for test and dev, I'd suggest to leave it as-is. First, it is identical to what npm init --yes does for minimal scaffolding. Also I'm not sure if we just want to proxy cargo command for those.
General idea for scaffolding template is making as minimal as much as user configure anything else for their own.

@kwonoj - okay I removed dev and test from this PR 👍
I understand that npm is not a necessary proxy for cargo.
My idea behind adding test anyway was rather to add some guidance for js devs seeing a swc-plugin on npm.
Probably their first action (if they are new to rust) would be to check the package.json especially main and scripts.
What about moving the test idea to discussions?

I think current feedback discussion is good enough to see if the current template causes unnecessary inconveniences for the plugin authors. There would be multiple ways to setup scripts for the template, and it is highly subjective to each individual - reason I prefer to have an absolute minimum required field for the template.
Especially, we do not have a custom command to run tests or build. It is straightforward cargo subcommand we expect plugin author should be familiarized since our template is rustlang based one. Do not think we have to hide / proxy it into node's specific norm by default. If ppl would like to do it it should be fine, but not as a de facto recommended from swc's core.

I didn't intent this change to be for plugin authors. It is only straightforward for devs who already used cargo before.
This was rather an idea to be more inclusive for npm users who like to make a first contribution to an oss swc plugin and have not used cargo before.
But I am totally fine with adding it and already removed it from this PR.
What do you think about the other changes?


Emotes starting with a colon (':') can't be tab-completed

Checklist

[X] I'm reporting a problem with Chatterino
[X] I've verified that I'm running the most recent nightly build or stable release
[X] I've looked for my problem on the wiki
[X] I've searched the issues and pull requests for similar looking reports

Describe your issue

type :tf:
press ESC to close the popup
press TAB (or whatever key you set completion to)

Expected: A space is inserted.
Actual: No space is inserted.
This worked in Chatterino 2.4.6 and broke in 2.5.0-beta.1. Enabling "smarter" emote completion does not fix this.
Screenshots
No response
OS and Chatterino Version
Chatterino Nightly 7.5.1 (commit 0668f29d) built on 2024-05-12 with Qt 6.5.0, MSVC 193933521

For completeness' sake smarter emote completion is just sorting of completion


ft_quantile_discretizer could never have worked

Inside ft_quantile_discretizer
setNumBuckets = ensure_scalar_double(n.buckets)
should be replaced by
setNumBuckets = ensure_scalar_integer(n.buckets)
setNumBuckets requires as input an integer

library(sparklyr)
sc <- spark_connect(master = "local", version = "2.0.1", hadoop_version = "2.7")
x <- copy_to(dest = sc, df = iris, name = "iris", overwrite = TRUE)
ft_quantile_discretizer(x, input.col = "Sepal_Length", output.col = "grp", n.buckets = 5L)
 Error: java.lang.Exception: No matched method found for class org.apache.spark.ml.feature.QuantileDiscretizer.setNumBuckets

Thanks for catching this!


toml: cannot load TOML value of type string into a Go slice

Config file seems to fail to load with the error message on the title. Aparently it's related to data format.
In the .conf file I changed:
listen = "<IP_ADDRESS>:123"
to
listen = ["<IP_ADDRESS>:123"]
Not sure if that's correct, but apparetnly that got rid of the error message and doh-client started to work.
Go version is 1.10.1 linux/arm.

 :) I should have payed attention to the changelog or the .conf file in the src directory.
I checked /etc/doh-client.conf (in my case that file is unmodified as I copied and renamed the conf files I use), but that wasn't replaced after make install.
Maybe it would be a good idea to install and overwrite an /etc/doh-client.conf.example or something like this?
Thanks

Maybe it would be a good idea to install and overwrite an /etc/doh-client.conf.example or something like this?

Thank you for your suggestion. I will implement this when I am free.

Fixed in 71b8c093c0d13f36b3bbf6cf0c58af3027cd1b1c. Closing.


Add support for translations / internationalization / localization of page elements

When people build HTML outputs with mystjs, there are many labels, titles, tooltips, etc that are hard-coded in English. For communities that wish to use this tool for non-English speakers, they need the ability to display these elements in the language of their choice.
This could be done by having a translation bank in this project, and the ability for users to trigger certain languages in their configuration. It could also be done by giving users the ability to define their own translated phrases and insert them into the outputs.
I know this is likely a large effort with many under-the-hood changes, so consider this a "long term tracking issue" to note that we need to do it as some point, and to track down the work over time.

QuantEcon is currently undertaking a project assessing how AI can be used to assist with translations to other languages. We are exploring a range of tooling including ChatGPT, various OpenAI models, and service layers such as crowdin which has support for open-source projects.
Our vision is to develop an open-source compatible workflow that uses AI to get to the 90% mark in the translation, leaving the last 10% to human proof-reading and updates. This is the approach we are taking in our first translation project of the introductory lecture series
There are various technical aspects to this project in the medium to longer term including:

How to enable good version control of source material in multiple languages. It would be nice to have tooling that allows for better line-by-line level control in the translation process for bi-directional updates from, for example, English -> Chinese, or from Chinese -> English. There may not always be a single source of truth in future projects, so bi-directional updating would be really useful.
Enabling an interface that allows reader feedback to improve translations (that isn't a pull request)


Does it support llava-video?

In my opinion, LLaVA-Video introduces a high-quality dataset, and the model is still based on the LLaVA architecture. Therefore, I think VisionZip can be applied to LLaVA-Video.

I encountered an error, Could u help me?
File "/root/work/filestorage/hrz/code/lmms-eval-main/VisionZip/visionzip/llava_arch.py", line 43, in encode_images_visionzip_multi
image_features, keep_idx = self.get_model().get_vision_tower().forward(images)
File "/root/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1688, in getattr
raise AttributeError(f"'{type(self).name}' object has no attribute '{name}'")
AttributeError: 'ClipEncoderLayer' object has no attribute 'metric

Hi 🤗,
The metric is calculated in this [line](https://github.com/dvlab-research/VisionZip/blob/641be94a8337af06fe4889794adf81b3c12cf32c/visionzip/clip_encoder.py#L45).
Please check if the model correctly executed this line.
If you encounter any further errors, feel free to ask me.
Best,
Senqiao


Balaclava Face Mask

About the PR
A balaclava mask will protect the identity of the person on whom it is worn
The balaclava can be purchased at uplink for 2 TC, as well as at the cinema vending machine and syndiedrobe using emag
Redone https://github.com/space-wizards/space-station-14/pull/19561
Why / Balance
Will help the antagonist hide his identity and looks super
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl: VulfiMoon

add: Gorlex found a huge box with balaclavas in space Russia and distributes it to agents as a means of protecting the face from identity disclosure

Yeah, sprite is bad

Кажется, что спрайт нуждается в улучшении, например, в правильном затенении и тому подобном.

The sprite was taken from another PR author https://github.com/space-wizards/space-station-14/pull/19561. I just redesigned the prototype and added a sprite for the reptile.

everything is in order, this is a closed and unaccepted pr, which you may not be guided by by design

I'll redo the sprite now, don't worry

I think this should be one telecrystal instead of two. It’s literally just a black face mask. Gas masks are available everywhere and do the same thing.

I think this should be one telecrystal instead of two. It’s literally just a black face mask. Gas masks are available everywhere and do the same thing.

2 TC for style and to protect your face from revealing your identity

I think it shouldn’t be in the uplink at all, since it’s just a sock with holes.  I'd rather just add it to the crafting menu

I'll replace the sprite soon

Please replace Russia in CL with USSP, lore moment

Thank you, (Spacibo, comrade)

I think this should be one telecrystal instead of two. It’s literally just a black face mask. Gas masks are available everywhere and do the same thing.

I still decided, I will remove it from the uplink and add it to the craft menu

I see no reason why it would be bad if the crew could fashion masks from cloth. This is a bit speculative but would this still be worth 2 tc then?

I already wrote above. I will make a craft, you will need fabric and in return you will receive an ugly version of a balaclava

I'll close PR for now, then I'll rework it

So... this blocks identity even if you have an id equipped?

no it works like other masks
this should not be 2 tc (price of an entire fish /!) for what can be gotten all over maints for free

this should not be 2 tc (price of an entire fish /!) for what can be gotten all over maints for free

it could be in a kit? E.g. "Thieving kit" Balaclava, thieving gloves, rag/syndicate soap and a smoke bomb for 5/6 TC?


symbol causes parser to stop

Version - 4.5.1
2a. Node Version - 11.7.0
2b. Browser - Chrome 75
Command Code

let fields = [];
if (leads.length > 0) {
  fields = Object.keys(leads[0]);
}
const opts = { fields };
const parser = new Json2csvParser(opts);
const csv = parser.parse(leads);

Dataset Sample

3420 Tuscany Dr SE | Grand Rapids | MI | 49546
1859 Misty Ridge | Byron Center | MI | 49315
1616 Cedar Creek Dr | Zeeland | MI | 49464
4536 Orchard Creek CT SE | Grand Rapids | MI | 49546
12551 68th | Allendale | MI | 49401
935 72nd St SE | Grand Rapids | MI | 49508
5510 Cascade   Rd SE #200|  Grand Rapids | MI | 49508

Output

3420 Tuscany Dr SE | Grand Rapids | MI | 49546
1859 Misty Ridge | Byron Center | MI | 49315
1616 Cedar Creek Dr | Zeeland | MI | 49464
4536 Orchard Creek CT SE | Grand Rapids | MI | 49546
12551 68th | Allendale | MI | 49401
935 72nd St SE | Grand Rapids | MI | 49508
5510 Cascade   Rd SE |

I can confirm that all of the information going into the parser is included but once it comes out it stops at the "#" symbol and returns everything prior to it as its result.
Expectation is that the "#" would be included in the string and continue to parse till the end and return the entire dataset instead of stopping at the "#" symbol.

Hi @N00nDay ,
Could you also share the exact input that you are using? (Your dataset sample is not valid JSON)
And what output would you expect? (Your output doesn't use quotes and use | as separator but that's not how you define the opts)
I tried:
const { Parser } = require("json2csv")

const leads = [
  { address: '3420 Tuscany Dr SE', town: 'Grand Rapids', state: 'MI', zipcode: '49546' },
  { address: '1859 Misty Ridge', town: 'Byron Center', state: 'MI', zipcode: '49315' },
  { address: '1616 Cedar Creek Dr', town: 'Zeeland', state: 'MI', zipcode: '49464' },
  { address: '4536 Orchard Creek CT SE', town: 'Grand Rapids', state: 'MI', zipcode: '49546' },
  { address: '12551 68th', town: 'Allendale', state: 'MI', zipcode: '49401' },
  { address: '935 72nd St SE', town: 'Grand Rapids', state: 'MI', zipcode: '49508' },
  { address: '5510 Cascade   Rd SE #200', town: 'Grand Rapids', state: 'MI', zipcode: '49508' }
];
const fields = leads.length > 0 ? Object.keys(leads[0]) : [];
const parser = new Parser({ fields });
const csv = parser.parse(leads);

and the result was:
"address","town","state","zipcode"
"3420 Tuscany Dr SE","Grand Rapids","MI","49546"
"1859 Misty Ridge","Byron Center","MI","49315"
"1616 Cedar Creek Dr","Zeeland","MI","49464"
"4536 Orchard Creek CT SE","Grand Rapids","MI","49546"
"12551 68th","Allendale","MI","49401"
"935 72nd St SE","Grand Rapids","MI","49508"
"5510 Cascade   Rd SE #200","Grand Rapids","MI","49508"

as expected.

My apologies.  After further review of my issue I have diagnosed the issue is not this plugin but rather my process of converting the csv information into a downloadable file.
Here is the code I am using:
export default function downloadCSV(name, csv) {
  if (isEmpty(csv)) return null;

  const filename = name || "export.csv";

  console.log("csv: ", csv);

  if (!csv.match(/^data:text\/csv/i)) {
    csv = "data:text/csv;charset=utf-8," + csv;
  }
  let data = encodeURI(csv);

  console.log("data: ", data);

  let link = document.createElement("a");
  link.setAttribute("href", data);
  link.setAttribute("download", filename);
  link.click();
}

Any reason you can think of that this would only return all data prior to the "#" symbol or have a better way of providing a user the ability to download a csv file on button click?

Yeah. encodeURI doesn't encode the hash (#) which is a reserved character to indicate the beginning of a fragment identifier.
You want to use encodeURIComponent instead which encodes also the reserve characters.
However, doing that in your current function will produce an error because also the data type will be encoded.
What you want is: csv = 'data:text/csv;charset=utf-8,' + encodeURIComponent(csv);.
If your data already contains the data:text/csv;charset=utf-8, you probably want to split the string to encode the second part only.
Let me know if that helps!


Walnut: Enable multi-class verification via single API request

Description
This PR optimizes the Walnut verification process, enabling verification through a single API request.
Tests

[x] Yes
[ ] No, because they aren't needed
[ ] No, because I need help

Added to documentation?

[ ] README.md
[ ] Dojo Book
[x] No documentation needed

Checklist

[x] I've formatted my code (scripts/prettier.sh, scripts/rust_fmt.sh, scripts/cairo_fmt.sh)
[x] I've linted my code (scripts/clippy.sh, scripts/docs.sh)
[x] I've commented my code
[ ] I've requested a review after addressing the comments

Summary by CodeRabbit

New Features

Enhanced verification process with improved data handling for class names and hashes.

Bug Fixes

Refactored verification function to streamline payload processing and result handling.

Chores

Updated dependencies and workspace configuration in the project setup.

@barabanovro pls rebase on main

@kariy Done!


Unable to render  from @carbon/ibm-products

What will this achieve?
implementing a feature /ui dialog
How will success be measured?
it's not a bug rather it's an improper usage. thanks<EMAIL_ADDRESS>who helped me with it and it's solved now.
Additional information

Designs
Existing code
etc

Turns out this was just a typo during implementation, ie <TearSheet /> instead of <Tearsheet />.


[ROCKETMQ-184]-It takes too long(3-33 seconds) to switch to read from slave when master crashes

JIRA:https://issues.apache.org/jira/browse/ROCKETMQ-184?jql=project %3D ROCKETMQ
Problem, no listener is triggered when Chanel is close.
When async command sent to the server, and the server is crash before sending response to client, the callback can not be invoked in time. Instead, the callback can only be triggered by the timeout scan service.
This is obvious for pulling message since the timeout is by default 30 seconds. So if master crashes before process response to the client, the client can not repull until scan service tell it, which takes at most 30 seconds. And repull will have 3 seconds delay, so the HA to read from slave has to take 3-33 seconds when this problem occurs.

Coverage increased (+0.04%) to 34.666% when pulling 0dc37e1c10450f143e58faa857f5bf8ccbee1ca3 on Jaskey:ROCKETMQ-184-slave-switch into 42f78c281cbeb5072b04eaf03b1a8059b8d281a7 on apache:develop.

Coverage decreased (-0.0007%) to 34.631% when pulling 65ffffdf26a3d38a1a32814b85c9c02d95c63dec on Jaskey:ROCKETMQ-184-slave-switch into 42f78c281cbeb5072b04eaf03b1a8059b8d281a7 on apache:develop.

invokeOneway should also be updated if so, otherwise, it's likely to leak semaphore.

Thanks @Jaskey, this is indeed a good place to improve.
For the implementation, I suggest an alternative generic way, instead of add a close future for each request, we add the opaque integer into a collection per channel. Remove the opaque integer on response or invalidate all of them in NettyConnectManageHandler. Suggested approach has fewer memory footprint and we may also easily cover the sync request scenario -- respond earlier before timeoutMillis amount of time elapsed in case channel experiences problems.

@lizhanhui
I have considered that, which will takes more efforts to achieve the same goal. Since I need to change some structure to make the connect manager to get access to the responseFuture map.
For my first implementation, I just want to issue this problem and involve you guys to discuss.
If you think that is indeed a better approach, I will submit an updated implementations for that, and then let all guys to choose.

You are right that more changes are required for my suggested approach. But, IMO, the suggested way is more unified in design and may also save a few memory footprint in case we have very large semaphore initial capacity.
Indeed, this is the place we need to enhance.
Let's bring more guys into discussion before you implement the suggested approach.  They should easily conceive what's going on here via checking changes made in your PR. Any opinion on this issue? @zhouxinyu @shroman @vongosling

Thanks @Jaskey , agree with @lizhanhui , use NettyConnectManageHandler to handle this close event is a better way, no need to import two mechanisms.

Coverage increased (+0.1%) to 37.974% when pulling 388e88bfc732ab67c62e510a24f72cf9acf50051 on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage increased (+0.1%) to 37.974% when pulling 388e88bfc732ab67c62e510a24f72cf9acf50051 on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage increased (+0.1%) to 37.974% when pulling 388e88bfc732ab67c62e510a24f72cf9acf50051 on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage increased (+0.02%) to 37.869% when pulling 40d77eaffe64cf4e3070f5e2440e7d0fa4281a0e on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage increased (+0.02%) to 37.869% when pulling 40d77eaffe64cf4e3070f5e2440e7d0fa4281a0e on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage increased (+0.02%) to 37.869% when pulling 40d77eaffe64cf4e3070f5e2440e7d0fa4281a0e on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage increased (+0.004%) to 37.858% when pulling abd61c8aa1b6e9dd583dd3e018286b778d7acab1 on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage decreased (-0.09%) to 37.761% when pulling abd61c8aa1b6e9dd583dd3e018286b778d7acab1 on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage decreased (-0.09%) to 37.761% when pulling abd61c8aa1b6e9dd583dd3e018286b778d7acab1 on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage decreased (-0.09%) to 37.761% when pulling abd61c8aa1b6e9dd583dd3e018286b778d7acab1 on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

Coverage increased (+0.04%) to 37.894% when pulling d8faa3364945c4f119e8fea0626183113bc45a80 on Jaskey:ROCKETMQ-184-slave-switch into 6a9628b3c3e6835e37baf7b58ad9300364d4d384 on apache:develop.

@zhouxinyu @lizhanhui
please review the updated pr

please review the updated pr

Looks this PR is not updated. Do you forget to push your changes?

@lizhanhui
It has been refactored using the close event handler mechanism according to your advice, please review the pr from close callback in  NettyRemotingClient.java

@lizhanhui @vsair @zhouxinyu @shroman
any ideas for this updated solution?

+1

LGTM @zhouxinyu

@zhouxinyu @vongosling @shroman what's your advice, can this pr be merged?

Coverage increased (+0.09%) to 39.238% when pulling 80f4e6b24daf0cf3e7b7cdc75298665adbea4d4c on Jaskey:ROCKETMQ-184-slave-switch into cba30897c169c7182e3f8b53ead169e5a458f13e on apache:develop.

This pr is not updated from the source for long, so I updated just now , please review.
I think this is a good improvement for HA


[occm] Fix updating octavia port when using externalClusterPolicy Local

What this PR does / why we need it:
Currently if service uses externalClusterPolicy: Local the loadbalancers will not work. It works for few minutes but after that loadbalancers will go to ERROR state. Read issue #1749
Which issue this PR fixes(if applicable):
fixes #1749
Release note:

Fix to octavia monitor_port when updating loadbalancer

I am still verifying this

/kind bug

/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance
/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.19
/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.20
/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.21

/lgtm

/approve


REPL has an error:

The REPL has an error:
Error: $$restProps is an illegal variable name (Field.svelte:53:16)
https://svelte.dev/repl/5ba56f98dc7f4911818ec5617c6b3024?version=3.19.0

Try with the latest version of Svelte: https://svelte.dev/repl/5ba56f98dc7f4911818ec5617c6b3024?version=3.23.0

$$restProps is a Svelte feature added in 3.20.0


toggle es5 build for easier use of component

What
tweaking build to import / use in app.
Ticket
https://vertexvis.atlassian.net/browse/SDK-760
Test Plan

Areas of Possible Regression

Out of scope changes made in PR

Dependencies

going a different route here.


Header line

Added config option contain_header (default is false), if set to true it will use first line of csv input as column names.
Added config option stream_identity which allows to differentiate streams (e.g. csv files) and use different column names (and|or order) for each file.
We use it in production for couple months now - works nicely.
Tested against logstash-1.5.0.

I had signed the CLA, but my email was not made public on GitHub profile. I suspect this is the reason for CLA — Some commit authors have not signed the CLA or are not members of...
I have now made the email public, is it possible to remove this CLA error ?

What if Logstash is restarted in the middle of the processing of a file? I don't see it persisting the captured column names so it seems they would be lost.

@zamblauskas the CLA check uses the git commit author on the commits, not your github email address. Further, this check is only done per commit not periodically. I've run my script to re-check everything and things are looking ok on CLA :) Thanks!

What if Logstash is restarted in the middle of the processing of a file?

I agree with this concern. We have plans to make a seekable file input that will allow something like a csv codec to remember where in a file it last read, but also be able to re-learn the headers for a given CSV from the beginning. This isn't possible today, though.

What if Logstash is restarted in the middle of the processing of a file?

Not an issue in our use case - we process a large number of small files, each single time only.
But might be a problem for other users - agree.
Will take a look how sincedb is used in logstash and how easy it would be to save the header.

I expected sincedb to be some kind of a self-contained full-blown db, turns out it's just a simple file :) But it's possible to save the headers in a similar manner.
After little bit more thinking about saving headers in a db/file, I think it's not possible to do it properly within a filter.
Main obstacle is rotating files - the filter wouldn't know that a rotation happened and that it needs to re-read the headers for a given file.
That seekable file input @jordansissel mentioned is required in this case, hence leaving this PR as it is for now.

Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run; then  say 'jenkins, test it'.

This is an important feature.  Is there anything I can do to help out getting this request integrated?

Wanted to chase this one up @jordansissel @magnusbaeck; isn't the sincedb best handled by the input itself? Why do we care if we drop a line once it has passed that point?
To my (un-ruby) mind, this is the same as using something like   if "_dateparsefailure" in [tags] { drop {} } if you have a date column and you want to easily drop the header from the output. If I wanted to reprocess the file then I know the input (assuming file) will handle it.

Just FYI it looks like the PR that I submitted that got merged has a little overlap with this one (just the contains_header part).. See #36.


add png extension

Using this module in https://github.com/sindresorhus/is-image btw ;)

Can you do a release after merging?

Oh boy, how did I miss that one? Thanks :)


Sensitivity/batch runner based on new odin-js

This will fail until https://github.com/mrc-ide/odin-js/pull/23 is merged and npm updated as I have no idea how to properly depend on in-development versions of packages. Confirmed working locally via some ugly hacks :)
Fixes #10, which was an initial implementation, tests are copied over

I've not had that approach work well with TS things - I think the wheels fall off when it hits jest


converting notebook from library to client API access

Current coverage is 79.55%

Merging #169 into develop will not affect coverage as of c6beec0

@@            develop    #169   diff @@
=======================================
  Files            21      21
  Stmts          2930    2930
  Branches          0       0
  Methods           0       0
=======================================
  Hit            2331    2331
  Partial           0       0
  Missed          599     599

Review entire Coverage Diff as of c6beec0

Powered by Codecov. Updated on successful CI builds.


Error Could not connect to debug target

I'm trying to go through the lsp-sample with Language Server Extension Guide.
I'm using the Launch Client configuration to debug:
{
			"type": "extensionHost",
			"request": "launch",
			"name": "Launch Client",
			"runtimeExecutable": "${execPath}",
			"args": [
				"--extensionDevelopmentPath=${workspaceRoot}"
			],
			"outFiles": [
				"${workspaceRoot}/client/out/**/*.js"
			],
			"preLaunchTask": {
				"type": "npm",
				"script": "watch"
			}
		}

and getting
Visual Studio Code Error processing attach : Error Could not connect to debug target at http://localhost:6009: Promise was canceled
at e (/opt/visual-studio-code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:15:2455839)
at async t (/opt/visual-studio-code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:73:46107)
at async w.launch (/opt/visual-studio-code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:15:2477534)
at async t.Binder.captureLaunch (/opt/visual-studio-code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:73:115411)
at async t.Binder._launch (/opt/visual-studio-code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:73:114962)
at async Promise.all (index 5)	at async t.Binder._boot (/opt/visual-studio-code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:73:114222)	at async t.default._onMessage (/opt/visual-studio-code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:15:2463780)

error.
Changing the port on which the server should be running did not result in success.
What could be the reason for this behavior?
I'm using Manjaro Linux, Node.js 14.12.0 and VS Code 1.50.1.

Did your server start? The client has a rule for when it starts.
https://github.com/microsoft/vscode-extension-samples/blob/master/lsp-sample/package.json#L20
This means, that you need to open such a file in vscode first. Then connect to your server.

@Razzeee This actually solved the problem, thanks for the help!


Please, describe permissions required from user

Let's assume that user have permissions only to one application insights instance from N. Will application map show to this user other "components"?
Do "components discovery" support "discovery" across different resources groups/subscriptions? (Let's imagine that each microservice deployed in a separate resource group or even subscription. if application insights can discover dependencies in such case- great, if now- ok, but it need to be specified in an article).
Documentation stated "Components can be separate Application Insights instrumentation keys (even if subscriptions are different)" (C), but required permission - unclear.
Is role on all application insights instances

enough to see components across multiple instances of app insights?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bfc7b703-b823-5719-36de-0eeaf096b3ca
Version Independent ID: d85431d2-7253-80e9-9036-b62e2e230cca
Content: Application Map in Azure Application Insights - Azure Monitor
Content Source: articles/azure-monitor/app/app-map.md
Service: azure-monitor
Sub-service: application-insights
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@SychevIgor Thanks for the feedback! We are currently investigating and will update you shortly.

@SychevIgor One of the key takeaways from the documentation here is how the application maps are created:
https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-map#composite-application-map

You can see the full application topology across multiple levels of related application components. Components could be different Application Insights resources, or different roles in a single resource. The app map finds components by following HTTP dependency calls made between servers with the Application Insights SDK installed.

Hopefully that clears up how visibility is defined.

@SychevIgor We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.

It was anything, but not an answer on question.
Question was about permissions

@SychevIgor Referring to the quote above, the user permissions are dependent on being able to view the Application Insights resource.  The Application Insights resource in turn makes a map by finding components that it makes HTTP dependency calls to with the Application Insights SDK installed.

@kobulloc-MSFT could you explain - "what does it mean" for non-English speakers like?
What RBAC need to be assigned to me as a user to see all components on application map?
If some user will have access to only one application insights instance, will application map show all components or will be scoped to application insights instances accessible for this user?

@SychevIgor To see components in the Application  Map, the user would need a Reader role for the Application Insights resource.  If the user does not have permission to see a resource (e.g. resource B) that is linked to a resource they do have permission to see (e.g. resource A), then they would only see the node they have permission to see (resource A) in the Application Map.
Application Map is capable of reading across different subscriptions and resource groups.  It is only limited by tenant (e.g. microsoft.com vs contoso.com).

@SychevIgor We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


✨ Read HTTP end points as a data source

Can probably use something like Beautiful Soup to extract tabular data from HTML content.
Should be able to read RSS.

This should probably be a function dataset with the end point as one Param and config as the other params ( like the table name/number, if it's HTML/XML//JSON)


testing with zips

where do I place it? I tried python test_vision_detector_search.py
and I put corr in /home/chuong/cos-pomdp/experiments/thor/
but it keeps telling me this error:
FileNotFoundError: [Errno 2] No such file or directory: '/home/john/cos-pomdp/experiments/thor/../../data/thor/corrs/distances_bedroom_AlarmClock-DeskLamp_FloorPlan321.json'

should I make 2 folders? that seems weird.

Sorry, I’ve forgotten :)
Look into how it’s used.


ROCm support using hip

Hi! Greetings from Centor fro High Energy Physics, Tsinghua University.
Currently we succesfully depoyed pytorch with the latest rocm-3.5.0 support on Gentoo. Pytorch uses a python script build_amd.py to convert all cuda codes into hip codes (called hipify). So, with rocm developer tools including hipcc and rocm libraries, torch can be compiled and run on AMD GPU without modification of pytorch front-end. So would jittor consider including support on ROCm?

This sounds interesting, we hope Jittor can support AMD GPU, you can add my wechat(randonlang) for further discussing


Fix distutils deprecation in setup.py

The historical distutils Python standard module has been marked as deprecated since Python 3.10 and has been removed since Python 3.12... it's time to act!
The solution is simple.
Replace from distutils.core import setup by from setuptools import setup.
Thanks to @CAM-Gerlach for the reminder (I had completely forgotten about this...).

Sorry... wrong project!!
Note for later: never create an issue before drinking your morning coffee.


Access denied for user 'root'@'

On changing the mysql password in the various config env and yml files
I'm only able to get as far as: Access denied for user<EMAIL_ADDRESS>(using password: YES)Please provide the root password for your MySQL installation
Whilst running make run
I can not work out how to send the mysql password to the docker containers, changing the env files doesn't seem to be enough.

Hit me up on whatsapp i can help you!
Whatsapp : +6285790752549

Mine is related to workbench


How to keep alive

I'm using the 'node-xmpp-client' to make a demo, and I can send one message to the other users registered in my ejabberd server. But I don't know how to make this client keep alive.
this is my demo
index.html
<!DOCTYPE html>
<html>
  <head>
    <title></title>
    <script src="node-xmpp.js"></script>
    <!--<script src="../../index.js"></script>-->
    <script src="chat.js"></script>
  </head>
  <body>
  </body>
</html>

chat.js
(function (global) {
  'use strict'

  var XMPP = global.XMPP

  /* Note these are connection details for a local dev server :) */
  var client = new XMPP.Client({
    websocket: { url: 'ws://<IP_ADDRESS>:5280/websocket/' },
    jid<EMAIL_ADDRESS>    password: '123456',
    host:'<IP_ADDRESS>',
    preferred: 'PLAIN',
    reconnect: true
  })

  client.on('online', function () {
    console.log('online')

    var recipients =<EMAIL_ADDRESS>    recipients.forEach(function (to) {
      var stanza = new XMPP.Element('message', {to: to, type: 'chat'})
        .c('body')
        .t('Hello from browser')
      client.send(stanza)
    })

  })

  client.on('stanza', function(stanza) {
    console.log('Incoming stanza: ')
    // console.log('Incoming stanza: ', stanza.toString())
  })

  client.on('error', function (err) {
    console.error(err)
  })

}(this))

the 'node-xmpp.js' is build by https://github.com/node-xmpp/node-xmpp/tree/master/packages/node-xmpp-client

And I have no idea where to use the code below.
this.client.connection.socket.setTimeout(0) this.client.connection.socket.setKeepAlive(true, 10000)
this is my first time to use this, sorry for my bad code format and my poor english.

when i use setInterval to send message, it's ok. But on my other xmpp app, it seem's like the user uses this js is offline. and can't receive messages.
  setInterval(function () {
      // can always send message
      recipients.forEach(function (to) { var stanza = new
      XMPP.Element('message', {to: to, type: 'chat'})   .c('body')   .t('ping')
      client.send(stanza) })
    }, 1000)

My best guess is that you don't reply to pings sent by ejabberd.

the main issues is that when i login my<EMAIL_ADDRESS>by the code above, the<EMAIL_ADDRESS>logon by iOS APP send message to  xx, and xx is offline in zz's user list

You need to send a presence stanza once connected.

OK， i will try to do that tomorrow， cuz it is midnight now in China.  see you.

Wonderful! It works now! Thanks for your help.
And one more questions, where could I find detail docs, something like the XMPP.Element has the function c/t/up, and the client.on can listen the status 'online'/'error'/'offline', etc.
client.send(new XMPP.Element('presence', {})
      .c('show').t('chat').up()
      .c('status').t('hello everyone')
    )

client.on('stanza', function (stanza) {
    if (stanza.is('message') && (stanza.attrs.type == 'chat')) {
      // chat from other users
      console.log('Incoming stanza: ', stanza.getChildText('body'))
    } else {
      // others
      console.log('Incoming stanza: ', stanza.toString())
    }

We're lacking in documentation for the moment. You're best bet is the examples and the source code.


Performance improvement for timeoutable

move timeout_skip check earlier to avoid unnecessary record lookup

Thanks for your contribution. Would you mind clarifying what you mean by "unnecessary record lookup" here? Is that an actual DB lookup (which I'm not clearly seeing from the code), or just skipping the timestamp check that happen in timedout?:
https://github.com/heartcombo/devise/blob/29943a26e61d68198666c59e07457dba3c75f581/lib/devise/models/timeoutable.rb#L30-L32

@carlosantoniodasilva This is to skip the user defined timeout_in method on the user model. I'd imagine most of the time this would result in a db lookup, ie: if user admin or has some special role.

We can't really account for what people may implement in their model, but more often than not, that shouldn't result in a DB lookup. Even being admin or a special role, it would be dependent upon the client implementation -- and I'm inclined to think most people that use this module don't even override that method, very few would do.
That said, I see no harm in reversing those conditionals and bailing out early based on the "skip" flag set in the env, so I'll merge it. Thanks for the contribution.


Bad error message when no path is passed for CSS output

Using Node 12.6.0:
> npx icomoon-build --css -p .\res\icons.json --fonts dist/
internal/fs/utils.js:426
    throw new ERR_INVALID_ARG_TYPE(propName, ['string', 'Buffer', 'URL'], path);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be one of type string, Buffer, or URL. Received type boolean
    at Object.openSync (fs.js:439:10)
    at Object.writeFileSync (fs.js:1206:35)
    at <my project root>\node_modules\icomoon-build\lib\cli.js:23:20
    at Array.forEach (<anonymous>)
    at <my project root>\node_modules\icomoon-build\lib\cli.js:17:70
    at <my project root>\node_modules\icomoon-build\lib\icomoon.js:104:9
    at ChildProcess.exithandler (child_process.js:288:7)
    at ChildProcess.emit (events.js:203:13)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)

Turns out I misread the command line options.
Would be nice if such misusage generated an easy to understand error though. Leaving this open for that.


fix getRowHeight actually get the height of the next row

PR Details

Description

Related Issue

Motivation and Context

How Has This Been Tested

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

fix getRowHeight actually get the height of the next row

Codecov Report

Merging #860 (3702cc2) into master (5faa364) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #860   +/-   ##
=======================================
  Coverage   97.45%   97.45%
=======================================
  Files          31       31
  Lines       10869    10869
=======================================
  Hits        10592    10592
  Misses        155      155
  Partials      122      122

Flag
Coverage Δ

unittests
97.45% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

rows.go
93.58% <100.00%> (ø)

Continue to review full report at Codecov.

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

Hi @gq-tang thanks for your PR, the GetRowHeight function gets a row's height by row number, not row index, so the docs for it just should be updated.


Failed to import - node-fetch-native

Failing module
import 'https://esm.sh/@notionhq/client'
import 'https://esm.sh/@tensorflow/tfjs'

Error message
These modules have node-fetch-native as a dependency. However<EMAIL_ADDRESS>returns a 500
/* esm.sh - error */
throw new Error("[esm.sh] " + "npm: can't get metadata of package 'process/browser' (405 Method Not Allowed: {\"code\":\"MethodNotAllowedError\",\"message\":\"GET is not allowed\"})");
export default null;

Additional info

esm.sh version: 95
Browser version:
Arc Version 0.69.0 (34772)
Chromium Engine Version 105.0.5195.127

this should be fixed in last update

@ije Awesome thank you! That loads fine now.
Unfortunately, the parent packages still don't load because node-fetch-native depends on worker_threads. I see a request to https://esm.sh/error.js?type=unsupported-nodejs-builtin-module&name=worker_threads&importer=node-fetch-native. It'd be great to get this working in the browser.
Thanks again for your great work!


Swagger UI is not able to fetch data from Rest API.

Describe the bug
In the Swagger UI, whenever the "Execute" button is clicked, a javascript fetch function is executed and it should retrive the data from rest api as soon as data is correct (authorization token, rest api protocol, ip adress, port and context path and authorized user permissions).
However via HTTPS it is always a FetchError on Google Chrome and NetworkError on Mozilla FireFox.
To Reproduce
Steps to reproduce the behavior:

Deploy REST API in the oscm-core container
Deploy Swagger UI
Above 2 steps can be done by using task/swagger branch in the oscm-dockerbuild and swagger branch in the groovy pipeline branch to deploy OSCM.
Fill in data and try to execute an endpoint in the Swagger UI.
Note: curls generated by Swagger UI should actually work.

Expected behavior
An endpoint method is executed and response code and optionally a JSON is returned.
Observed behavior
FetchError or NetworkError is received.
Additional context
In case of any questions contact me directly.

This is completed on swagger-module branch and will be merged into the swagger branch. Afterwards I will fix the version validation issue, add version parameter to swagger-ui to be selectable and when this is done - we will attempt to merge it with master, but that is going to happen probably in next sprint


Update live-common

https://ledgerhq.atlassian.net/browse/LL-6308
https://github.com/LedgerHQ/ledger-live-common/releases/tag/v20.2.0
https://github.com/LedgerHQ/ledger-live-common/releases/tag/v20.3.0
see https://github.com/LedgerHQ/ledger-live-desktop/pull/3962 for impact of the scope

Hey there, upon trying to build this PR on Android, I ran into a syntax error in node_modules/pdkdf, let me know if you need additional details, can't provide a screenshot here @gre

ok i think i had it one once, but i had it fixed by running with node 14
are you sure you are fully on node 14?
i had it once and then i made sure to confirm my "nvm" and it fixed it
i think it happens if you yarn with node 12 and then go node 14.

thanks! we are on it.

Link for context

https://github.com/crypto-browserify/pbkdf2/issues/96
https://github.com/tradle/rn-nodeify/issues/102

Hey guys,
Ran into something dirty while performing regression testing.
Steps to reproduce :

Perform a successful swap via Paraswap
Go to History > Select the last swap
-> see screenshots below


Problem printing

Description
What steps will reproduce the problem?

What is the expected output? What do you see instead?
Please provide any additional information below
File "/usr/lib/python3/dist-packages/spyder/widgets/variableexplorer/collectionseditor.py", line 449, in createEditor
if not editor.setup_and_check(value, title=key, readonly=readonly):
File "/usr/lib/python3/dist-packages/spyder/widgets/variableexplorer/arrayeditor.py", line 619, in setup_and_check
self.data.flags.writeable = True
ValueError: cannot set WRITEABLE flag to True of this array
Version and main components

Spyder Version: 3.2.6
Python Version: 3.6.7
Qt Versions: 5.9.5, PyQt5 5.10.1 on Linux

Dependencies
pyflakes >=0.6.0 :  1.6.0 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pygments >=2.0   :  2.2.0 (OK)
pandas >=0.13.1  :  0.22.0 (OK)
numpy >=1.7      :  1.16.0 (OK)
sphinx >=0.6.6   :  1.6.7 (OK)
rope >=0.9.4     :  0.10.5 (OK)
jedi >=0.9.0     :  0.11.1 (OK)
psutil >=0.3     :  5.4.2 (OK)
nbconvert >=4.0  :  5.3.1 (OK)
sympy >=0.7.3    :  None (NOK)
cython >=0.21    :  None (NOK)
qtconsole >=4.2.0:  4.3.1 (OK)
IPython >=4.0    :  5.5.0 (OK)
pylint >=0.25    :  1.8.3 (OK)

Duplicate of #8582. We'll fix this in our next version.

How can I do until then?

Just wait, there's no workaround for this, sorry. However, the new version (3.3.3) with this is going to be available in a couple of hours.


Line 144 character 19 - error with & when running script

Thank you for reporting an issue, making a suggestion, or asking a question. We appreciate your feedback - to help the team understand your
needs please complete the below template to ensure we have the details to respond. Thanks!
Category

[ ] Suggested sample, script, or tool
[ ] Bug in existing sample, script, or tool
[ ] Question / Feedback

Instructions
Delete this section after reading

All suggestions, questions and issues related to FastTrack OSS are welcome, please let us know what's on your mind.
This is not a general support forum for FastTrack, questions should be related to an existing or proposed OSS contribution
Remember to include sufficient details and context
If you have multiple suggestions, questions, or bugs please submit them in seperate issues so we can track resolution
Complete the section below that matches your need and delete the others
Thank you for your feedback!

Issue Details
Suggested Sample, Script, or Tool
Please described the sample, script or tool you think would be useful. Ensure you provide enough detail for us to understand and include the use case(s) covered. Samples, scripts, and tool should be generic and applicable to a wide range of customers.
Bug in existing sample, script, or tool
Expected / Desired Behavior
Please describe the expected behavior.
Observed Behavior
Please describe the behavior that occured.
Steps to Reproduce
Please describe the steps to reproduce the bug in sufficient detail to allow testing.
Question / Feedback
Ask away! - but remember this isn't a general support forum for FastTrack. Questions should be related to the OSS projects.

Hi @brentja - we haven't been able to respond as you haven't provided enough information for us to act. Can you please provide additional details?