[Bug]: Password flag error with shopify theme dev and push commands

Please confirm that you have:

[X] Searched existing issues to see if your issue is a duplicate. (If you’ve found a duplicate issue, feel free to add additional information in a comment on it.)
[X] Reproduced the issue in the latest CLI version.

In which of these areas are you experiencing a problem?
Theme
Expected behavior
The password flag should work for push and dev commands (dev as per v3.29.0 if I'm not mistaken).
Actual behavior
When passing the --password flag, shopify cli ends abruptly with an error:
bundler: failed to load command: shopify (/Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/bin/shopify)
✗ An unexpected error occured.

If I don't pass the password flag, it runs normally.
This started to happen after I updated the cli to v3.34.0, it was working on v.3.33.0. Updated via homebrew update + upgrade.
NoteL the stack trace is saying node.js v19.4.0, but I'm using node v16 with nvm.
Stack trace
bundler: failed to load command: shopify (/Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/bin/shopify)
✗ An unexpected error occured.
        To submit an issue include the stack trace.

/Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/api.rb:78:in `block in request': 429 (ShopifyCLI::API::APIRequestThrottledError)
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/util.rb:172:in `retry_after'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/api.rb:89:in `request'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/theme_access_api.rb:43:in `rest_request'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/theme_admin_api.rb:38:in `rest_request'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/theme_admin_api.rb:18:in `get'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/development_theme.rb:48:in `exists?'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/development_theme.rb:34:in `ensure_exists!'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/development_theme.rb:71:in `find_or_create!'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/dev_server.rb:192:in `theme'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/dev_server.rb:289:in `syncing_theme_message'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/dev_server.rb:170:in `block in sync_theme'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-ui/lib/cli/ui/frame.rb:103:in `open'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/dev_server.rb:169:in `sync_theme'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/dev_server.rb:102:in `start'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/theme/dev_server.rb:64:in `start'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/project_types/theme/commands/serve.rb:49:in `call'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/command/sub_command.rb:16:in `call'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/command.rb:27:in `call'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/core/executor.rb:17:in `block (2 levels) in call'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/executor.rb:37:in `block (2 levels) in with_logging'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-ui/lib/cli/ui/stdout_router.rb:169:in `with_id'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/executor.rb:36:in `block in with_logging'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-ui/lib/cli/ui.rb:176:in `log_output_to'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/executor.rb:35:in `with_logging'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/core/executor.rb:16:in `block in call'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/executor.rb:45:in `block (2 levels) in with_traps'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/executor.rb:55:in `twrap'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/executor.rb:44:in `block in with_traps'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/executor.rb:55:in `twrap'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/executor.rb:43:in `with_traps'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/core/executor.rb:15:in `call'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/core/entry_point.rb:17:in `block in call'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/core/monorail.rb:26:in `log'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/lib/shopify_cli/core/entry_point.rb:16:in `call'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/bin/shopify:50:in `block (2 levels) in <top (required)>'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/error_handler.rb:75:in `handle_abort'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/vendor/deps/cli-kit/lib/cli/kit/error_handler.rb:21:in `call'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/bin/shopify:49:in `block in <top (required)>'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/gems/shopify-cli-2.34.0/bin/shopify:59:in `<top (required)>'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/bin/shopify:25:in `load'
        from /Users/kenji/Library/Caches/shopify-cli-nodejs/vendor/ruby-cli/2.34.0/ruby/3.2.0/bin/shopify:25:in `<top (required)>'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/cli/exec.rb:58:in `load'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/cli/exec.rb:58:in `kernel_load'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/cli/exec.rb:23:in `run'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/cli.rb:491:in `exec'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/cli.rb:34:in `dispatch'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/cli.rb:28:in `start'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/gems/3.2.0/gems/bundler-2.4.2/exe/bundle:45:in `block in <top (required)>'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/3.2.0/bundler/friendly_errors.rb:117:in `with_friendly_errors'
        from /opt/homebrew/Cellar/ruby/3.2.0/lib/ruby/gems/3.2.0/gems/bundler-2.4.2/exe/bundle:33:in `<top (required)>'
        from /opt/homebrew/opt/ruby/bin/bundle:25:in `load'
        from /opt/homebrew/opt/ruby/bin/bundle:25:in `<main>'
/opt/homebrew/Cellar/shopify-cli/3.34.0/libexec/lib/node_modules/@shopify/cli/node_modules/yoga-layout-prebuilt/yoga-layout/build/Release/nbind.js:53
        throw ex;
        ^

AbortSilent [Error]
    at execCLI2 (file:///opt/homebrew/Cellar/shopify-cli/3.34.0/libexec/lib/node_modules/@shopify/theme/node_modules/@shopify/cli-kit/dist/public/node/ruby.js:47:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  tryMessage: null,
  type: 1,
  nextSteps: undefined
}

Node.js v19.4.0

Reproduction steps

Install shopify cli v3.34.0 via homebrew
Try a shopify theme dev or shopify theme push command with the flags --path=<PATH> --store=<YOUR_STORE> --password=<THEME_ACCESS_PASSWORD> --theme=<THEME_ID>

In my case I used --path=src and a theme ID (not theme name)
Operating System
Mac OS Ventura 13.1
Shopify CLI version (check your project's package.json if you're not sure)
v3.34.0
Shell
zsh
Node version (run node -v if you're not sure)
v16.19.0
What language and version are you using in your application?
No response

Also seeing this issue. For us it seems to be store-specific as another development store is unaffected.

Some interesting logs when using the --verbose flag:

... and this when using a custom app password, instead of theme access password:

Updated to 3.38.0 and this is still happening. Seems to be some kind of throttling issue?

This error code can be found in the log attached to @kenji-twp’s original report above, too.
There’s quite a delay after the initial “Viewing theme…” output so perhaps something is making multiple attempts at something and getting throttled as a result?
This is still isolated to (so far) one of our development stores. There does not seem to be a way to downgrade to an earlier version with homebrew – are there any other workarounds (other than not using the --pasword flag, which we’re already having to do due to this)?

This seems to be fixed in the latest release v3.40.2


fix(logger): middleware stores initial persistent attributes correctly

Description of your changes
In #1328 it was reported that the Logger middleware injectLambdaContext was not clearing correctly the state and potentially leaking attributes set during an execution in the subsequent one.
Prior to this PR the middleware was improperly storing the initial persistent attributes of each logger instance passed to the middleware. This caused issues when clearing the state after each invocation, since the initial persistent attributes were now unusable.
This PR fixes the issue and adds new unit tests. Once merged this PR will close #1328.

Once merged, this PR closes #1328.
How to verify this change
See checks under the PR as well as integration test run here. New unit tests were added to demonstrate the fix & avoid future regressions.
Related issues, RFCs

Issue number: #1328
PR status
Is this ready for review?: YES
Is it a breaking change?: NO
Checklist

[x] My changes meet the tenets criteria
[x] I have performed a self-review of my own code
[x] I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have made corresponding changes to the examples
[x] My changes generate no new warnings
[x] The code coverage hasn't decreased
[x] I have added tests that prove my change is effective and works
[x] New and existing unit tests pass locally and in Github Actions
[ ] Any dependent changes have been merged and published
[x] The PR title follows the conventional commit semantics

Breaking change checklist

[ ] I have documented the migration process
[ ] I have added, implemented necessary warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I believe we also ran into this, but I didn't have time at the time to investigate the root cause. Instead we overrode the addPersistentLogAttributes() method to clear out any existing keys matching the ones being added in this call.
This is what we added:
  // Override addPersistentLogAttributes() and not appendKeys() since the latter delegates to the former
  addPersistentLogAttributes(attributes?: LogAttributes | undefined): void {
    // I've found that attributes don't always get cleared consistently even when `clearState` is set to `true`
    // So we'll clear out any keys we're about to set to make sure
    if (attributes != null) {
      this.removePersistentLogAttributes(Object.keys(attributes));
    }

    super.addPersistentLogAttributes(attributes);
  }

We've upgraded to v1.6.0 but haven't yet removed this override, but once we have some time to test, we'll do so and retest as I think this PR should fix the issue we saw. If not, I'll create a separate bug later on.


.iml file

Is there a need for the .iml file to be in the project directory, can it not be in the .idea directory>
(Rust plugin gets this wrong as well. :-(

That's the default place for Intellij to put it. I personally like to have *.iml and .idea/ in my gitignore file. If using dub there's no need for IDE specific files to be in version control.

*.iml and .idea should really be in .gitignore anyway

Interesting though that none of the JetBrains plugins leave a .iml file in the top level of a project.


[docs] Searching in docs does not jump to correct place in page

Do you want to request a feature or report a bug?
Bug
Bug: What is the current behavior?
When on https://community.algolia.com/instantsearch.js/documentation/, If I search (eg. label), and click on the result or select it through the keyboard, nothing happens. I'm not redirected to the correct part of the doc.

Bug: What is the expected behavior?
I would expect the page to jump to the selected part of the page/
Bug: What browsers are impacted? Which versions?
Tested on Chrome Version 57.0.2987.133 (64-bit) on Ubuntu
Bug: What is the proposed solution?
Selecting a result should jump to the correct part. Maybe it's time to use DocSearch on this website?

Will be fixed in v2 because the docs is completely different.

Won't we keep the v1 website up for people still using it?

Does work for me but I have seen situations of this happening even on GitHub where clicking on an anchors you are already in (from a url POV) does not work.

Can you try on this url with transf as the search term and select the transformData answer? I tried on both Chrome and Firefox and I'm not redirected.
To be honest I'm not sure where I should be redirected, but having a search result that does nothing just looks bad

I can replicate your issue Tim, the transformData item goes towards /documentation/

The index was not updated for a while sigh. The issue is no more with v2 (now using docsearch by Algolia)


Wormhole Integration

Create example with Wormhole Integration.

Nice suggestion; great to have on Celo Sage or Celo Examples, not on Celo Composer.
Closing issue.


Modern Firebase functions folder and new updateClasDocNetworksOnUserChange function

PT-188117155

Another option to consider would be retaining the top-level functions folder for shared files and pushing version-specific files into v1 and v2 subfolders.

Since the shared files are shared between the functions and the runtime it seemed best to move them to the top level.


Add synchronization to ensure that the integration test repository is only created once

This should allow running integration tests in parallel again.
fixes #7

@djc if you want to have a quick look - was unable to pick you as reviewer for some reason

LGTM (with little knowledge about what the underlying code is actually doing).

Thanks Dirkjan, I think this can be considered in a fairly abstract fashion without looking at the actual code that it wraps.

To whomever reviews this - please feel free to merge after reviewing if I am still on vacation :)

Did you test this?
If you run with multiple threads, each method in one test file is executed in parallel. Therefore in one single file you will apply the crd only once.
If you run with multiple files, files are executed after each other and setup a new (it is not a real global variable while testing). So for each different file you will apply the crd again.
Thats what you wanted to avoid?
Check that test example:
playground.tar.gz

I tested it, but only with one file, that is true.
That being said, the objective was to avoid trying to create the crd multiple times in parallel as only this would create issues.
If files are executed consecutively and we can ensure that we only try to create the CRD once per file that is sufficient for our needs - not perfect, but should do the trick.


Compatibility with Powershell 6.0?

I tried installing the feature as per the documentation steps and the module seems to install. However, when i attempt to invoke using the following command: Get-VSSetupInstance
The command is not detected. Lower versions of PS (5.0 below) seem to work, though.
Specs used:

PS 6.0.0-alpha.18
Win7 x64

PowerShell 6.0 runs on .NET Core which does not support all the types declared. We are considering how to deal with this, but it is not currently supported.

Thank you for the fast response.
On Thu, Apr 20, 2017 at 4:14 AM, Heath Stewart<EMAIL_ADDRESS>wrote:

PowerShell 6.0 runs on .NET Core which does not support all the types
declared. We are considering how to deal with this, but it is not currently
supported.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vssetup.powershell/issues/15#issuecomment-295421211,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE-pz1NbPCzXMUIa8JTVrv5q-TxtYrYKks5rxmsMgaJpZM4NBLCg
.

Ran into the same issue. Looking forward to the fix!

As of PowerShell Core 6.0 beta 4, the module works. The type System.Runtime.InteropServices.TypeLibImportClassAttribute still isn't supported by .NET Standard 2.0, but somehow it still works (perhaps that type is not truly necessary for non-embedded PIAs).


Extracting the Lisp example

I have a need for a Lisp parser and evaluator. I was going to write one myself, but I realized that the example here is already probably better than what I would have come up with on my own.
I could make a package that consumes this one, but I don't want all the extra dependencies.
Am I best off taking the code from here and starting a separate project? Could I call it "petit_lisp"?
Since the code in this repo is MIT-licensed, I believe I am allowed to do so, so I suppose I am mostly asking about how people feel about it, or if there are better alternative approaches.
(Aside: What I actually need is a near-Elisp, so I will need to add lots of library functions e.g. to an ElispEnvironment and also make a few parsing changes. I also want to add a mechanism for interrupting evaluation after some time i.e. to prevent infinite loops. It looks like I can do all or most of this additively, but I'm not positive about that.)

Sure, take the code as a starting point and pick your own name, the license allows you to do that as long as you include the original copyright notice.
I am definitely also interested in improving this implementation (particularly macros), but this code serves merely as simple use-case of PetitParser and is not supposed to implement a specific Lisp standard. Likely the current implementation is closer to Scheme, because this is what I am most familiar with ...

Thank you. As I've been playing with it, I find that the changes I need to make are not purely additive, so my initial idea of having a "generic core with Elisp overlay" seems unrealistic. I may have to explicitly specialize it for Elisp.

Likely the current implementation is closer to Scheme, because this is what I am most familiar with ...

Yes, I started to feel the difference (Lisp-1 vs Lisp-2) when I accidentally rebound a function with a function argument. I love the simplicity of Scheme, and what I really need is just an Elisp-ish configuration language, so I'd like to stick with it as much as possible.

I should ask explicitly: Do you object to me using the word "petit"? I am thinking something like "petit_lisp" or "petit_elisp".

Sure, that sounds good!

OK, thank you. I will close as I don't think there's anything else to discuss.


Add optional context to resolveCallableDependencies

Now that modules have tree traversal we should add context to resolveCallableDependencies.
What steps will reproduce the problem?
Application has User component.
Module A has User component.
Somewhere in Module A try to use resolveCallableDependencies on something that requires a User component.
What is the DESIRED result?
I'd love to get my modules' User component.
What do you get instead?
The applications' User component.
Additional info
Basically the way \Yii::$app is used in the container is as a preferred ServiceLocator. Instead we could support passing in any ServiceLocator as a context.
Current signature:
public function resolveCallableDependencies(callable $callback, $params = [])

Proposed signature:
public function resolveCallableDependencies(callable $callback, $params = [], ServiceLocator $context = null)

Temporary backwards compatible implementation:
public function resolveCallableDependencies(callable $callback, $params = [], ServiceLocator $context = null) {
if (!isset($context)) {
    $context = \Yii::$app;
}

At some point we should then remove the default and always require explicit context (thus removing the access to the global).

Q
A

Yii version
2.0.13

PHP version

Operating system

Any input, i'm happy to defend the proposal if anyone has an opinion :)

It makes sense to me. @yiisoft/core-developers what do you think?

agree. It makes sense to make Yii::$app in resolveCallableDependencies customizable

Can't do so w/o breaking BC.

Why not? Adding an optional argument is allowed right?
Anyway, I'm fine with pushing this to 2.1

Why not? Adding an optional argument is allowed right?

@samdark for which version should I make a PR?
Or should this be closed since you're working on a new DI project that will change everything?

I'm still unsure if we'll be able to use that DI library in 3.0.0 since it may change framework too much. Will get an answer in a few weeks (hopefully).

So definitely not in 2.x. Should I make a PR for 2.0.x then?

Ah, but won't there be a 2.1? Or we going to 3 immediately?


Table of Contents SEO Updates - Undo Revert

Fixes following issues|Adds following features:

Resolve bug where how to steps starts at 2 instead of 1
Add chevron / toggle chevron up and down to mobile toc
Make Table Of Contents sticky on mobile and positioned just below the nav
Allow Authors to use short hand titles for the table of contents
Allow Authors to control whether numbers are shown for each header corresponding to each table of contents link

Resolves: MWPW-160248
Original PR: https://github.com/adobecom/express/pull/1209

since this is undoing a revert for a PR already verified, I'm gonna merge and have it catch today's stage to main train


chatgpt-api command not work in my centos7,node16,but work normally in my windows

Looks like you need to update your Node.js.


is-mergeable-object is a devDependency

When I try to require your package I get an Error: Cannot find module 'is-mergeable-object' message.
Is there any reason the is-mergeable-object package is included in the dev dependencies in your package.json?

found my mistake. my bad, sorry. it should be a dev-dep as it is. my configuration tricked me.

have the same issue

The only way that should happen is if your build step is messing up and including ./index.js instead of respecting the main entry point in the package.json:
https://github.com/TehShrike/deepmerge/blob/7640d50c9d9dcd5a17a6e92fdca1bd6de9d9caf9/package.json#L18

The only way that should happen is if your build step is messing up and including ./index.js instead of respecting the main entry point in the package.json:
https://github.com/TehShrike/deepmerge/blob/7640d50c9d9dcd5a17a6e92fdca1bd6de9d9caf9/package.json#L18

this can potentially happen when using esm


Provide ability to handle unhandled key

I have a .... strange API, where I may not know all of the keys I need to import before importing, and I need to return all values I received. This is a simple change to allow unhandled keys to be tracked in the object.
I get this is a bit weird, but I'm not sure how else to get this behavior without much pain.
Thoughts @nbonatsakis / @arrouse  ?

@KingOfBrian is the +rzi_foundUnhandledValue:forKey: method intended for you to override? If so, it should go in the header.

I left it out because it felt like it would be confusing being that it's such a weird use case.


Add API approvals to tests

Summary
This pull request integrates API Approvals into our testing framework, designed to ensure that all changes to the public APIs of our projects are deliberate and documented. This feature automatically generates or updates a snapshot of the public API in a text document for each project and target framework during local tests. During continuous integration, these snapshots are verified to ensure they have been appropriately updated and included in the pull request.
Implementation Details

Local Test Snapshot Generation/Update: During local development, running the tests will automatically generate or update the existing snapshot of the public API for each project and target framework. This ensures that developers can immediately see and verify any changes they make to the API.
CI Verification: In the continuous integration environment, the API snapshots are checked to confirm that they match the API changes included in the pull request. If there is a mismatch, the CI build will fail, prompting for an update to the snapshots to reflect the latest API state.
GitHub Integration: Updated API snapshots are included in pull requests, allowing GitHub to display the modified public API changes directly in the pull request interface. This visibility makes it easier for reviewers to understand the scope and impact of the API changes being introduced.

Benefits

Immediate Feedback on API Changes: Developers get instant feedback on how their code changes affect the public API, enabling quick adjustments and informed decision-making.
Streamlined Review Process: Including updated API snapshots in pull requests provides reviewers with a direct view of API changes, facilitating a more effective and focused review process.
Enhanced Documentation: Automatic generation and updating of API snapshots helps ensure our documentation remains in sync with the actual codebase, aiding both new and existing users.
Prevention of Unintended API Modifications: By enforcing snapshot updates and verifications, we safeguard against unintentional API alterations that could lead to compatibility issues for our users.

Conclusion
The addition of automated API Approvals and snapshot updates to our testing and integration processes significantly strengthens our control over the project's public interfaces. This integration ensures high standards of compatibility and reliability, shielding end-users from unintended changes and fostering a stable development environment.

Well, the PR works ... sort-of.  It won't pass tests because the CI build does not have SupportedOSPlatformAttribute on any members of any of the builds.  If you import the 1.5.0 NuGet package into a new net6.0 project, and try using Base64QRCode.ImageType.Gif it does not have the attribute and will not provide a warning.  (Just one example.)
So, while the PR accurately identifies that the build is broken ... the build is broken.  I'm going to try to try modifying the build workflow until I can identify the problem.

So you say the recently published 1.5.0 nugget package is broken? Or did you mean the build for this specific PR was broken?
If 1.5.0 is broken, we should fix it asap and release a 1.5.1 before more people download a broken release.

The NuGet package 1.5.0 doesn’t have any SupportedOSPlatformAttribute markings in it. Not a critical issue, since mostly it was marked on windows-only members in the net6.0-windows build, but nevertheless, it is not correct.
I was able to fix the issue by using dotnet build instead of msbuild in the CI script. (We can see the test passes now.)

I’d probably release 1.5.1 if it was me, but the only affect will be people on net6.0 trying to create a base64 QR code encoded as gif/jpeg. They would get a build warning before attempting it in production and getting an exception.

Thanks for your help. I will release 1.5.1 this evening (GMT+2 - don't know if it's your evening, too).
But I don't nevertheless I don't understand how msbuild could produce this error. I would understand it, if Ms build failed the build completely, but it built. There's was an artifact produced. I would have expected to see at least some errors. :-/
By the way - same old story. I chose msbuild over dotnet build for a reason, but can't remember the reason anymore. (Probably the reason is also overhauled over the years...)

The 1.5.1 build is correct.  Attached is a screen snip from a consuming project, which did not look this way with 1.5.0:

If you have the time to review additional PRs, I may have time to provide a few more PRs.

Taking the time for reviews is the least I can do if you're already devoting so much work/time to the QRCoder. So yes, gladly!

Most specifically for v1.x, I would like to provide a performance update PR.

That sounds like a great idea. Performance optimizations are always welcome.

For v2, I could assist with PR(s) to split off System.Drawing.Common functionality and bring SkiaSharp and ImageSharp to QRCoder.

Here I would ask you to wait a little bit. I have been thinking about version 2.0 for the last few days and have identified a few points that need to be clarified before we start with a 2.0. I am currently preparing a larger post here in which I would like to collect feedback from the community first.

Finally, I may be able to assist with improvements with the CI scripts. For instance, currently all tests run on Windows; it would not be difficult to also run tests on Linux.

This is also a great idea that can already be implemented now (before version 2.0). Additional tests under Linux would certainly not do any harm. It might also be a possibility to work on the performance of the CI/build scripts. The total execution time of 12-15 minutes is already very slow and sometimes painful... There may still be scope for runtime optimization here too.

Sounds good.  Look for a performance PR soon.  So far it cuts down the memory allocation for small QR codes by about 50%, and large ones by about 30%.  I'm only about halfway done though.  It's going to change a lot of code, however, but not the structure (the method names are all the same, and the signatures change very little).  I could just change a few methods per PR if you want it broken out more.

Within the performance PR, in certain areas I may including all the old code as comments, so it's easier to see what was translated to what - if GitHub's compare is inadequate.  Then we can delete the comments after you've had time to review the code.

(no public API changes, of course)

Within the performance PR, in certain areas I may include all the old code as comments, so it's easier to see what was translated to what - if GitHub's compare is inadequate. Then we can delete the comments after you've had time to review the code.

That sounds like a plan. In general I think we've a very complete/robust set of test cases around the core generator so that even bigger code changes might be tested accordingly. Nevertheless I'll have a deeper look onto the changes and might pull out the ISO Norm I used back then when implementing the generator initially. ;-)


incorrect prop-types error for VFC

This is essentially the same issue as #3090 except that the VFC abbreviation was also overlooked in the fix that closed that issue. Basically the same changes need to be made as in #3092 except replace VoidFunctionComponent with VFC.

Presumably both VFC and VoidFunctionComponent are provided as types?

Yes. See https://github.com/DefinitelyTyped/DefinitelyTyped/blob/f3875116e52fe94338292fc418c89b2ef8216c4c/types/react/index.d.ts#L557.

This does not seem to be fixed after updating to v7.29.4.
Maybe we missed adding VFC here?
https://github.com/yannickcr/eslint-plugin-react/blob/d9531c3bc539e292eb297a04c7b9312e8b63a223/lib/util/propTypes.js#L104-L113

@dlech seems plausible :-) can you file a new issue, or better, a PR with a failing test case?


pip install tesseract

has any experienced this install issue?
Expected Behavior:
Suggested Fix:

I don't know. Please use the Tesseract user forum for questions.


Add action for using the whistle on the action bar

About the PR

Adds an action for using the whistle on the action bar
Why / Balance

Mostly quality of life
Not sure if CM13 has an action for whistling, but the source code seems to indicate it does
Technical details

Duplicated the Whistle component and system to avoid having to modify upstream files too much.
Re-parented the RMCWhistle to not inherit the upstream Whistle component.
Added EmitSoundOnActionComponent and SoundActionEvent to upstream files, plus a function in SharedEmitSoundSystem to play a sound once said event gets raised.
Media

Requirements

[x] I have read and I am following the Pull Request Guidelines. I understand that not doing so may get my pr closed at maintainer’s discretion
[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

:cl:

tweak: Whistles can now be used from the action bar.

Thank you for the review! I applied the changes and will keep them in mind for future PRs.

Moved all the RMC-specific code to the _RMC14 folders, did have to change the access level of TryEmitSound to be able to access it from outside the SharedEmitSoundSystem without code duplication.


Add protobuf formatter and linter

Add protobuf formatter
support protobuf auto format when user save file.
Add protobuf linter
Support google protobuf style

protobuf formatting can be done by calling clang-format
protobuf linting can be done by calling protolint


fix(preventOverflow): altAxis + tether

I am sure the logic for the math can be more compressed/elegant because it feels kinda weird, especially regarding isOriginSide, but this is what I've come up with to fix the issue.
Fixes #1365 https://github.com/popperjs/popper-core/issues/1242#issuecomment-884651318
@panzarino

Also fixed in v3 https://github.com/popperjs/popper-core/pull/1416


REFACTOR: channel-row

allows to quickly leave all channels and not only direct message channels
makes channel-row tag less
adds an instant animation when unfollowing a channel to make UI more responsive
introduces chat-channel-leave-btn to encapsulate all this btn logic


Http4s blaze should provide better feedback when rejecting a bad request (400)

I'll start explaining myself with an example. Let's say we deploy an http4s blaze server with info level logging. We then hit the server with a request for http://<IP_ADDRESS>:8080/foo?bar={} and get 400 in response. The response body is empty - no feedback there. The logs? No info there too. (for now, let's not discuss why this is a valid URL according to Firefox and Chrome and an invalid according to parboiled)
Switching logger level to debug, would give us the precious error message. But IMO using debug logs on production is not the way to go. I would like the problem to be diagnosable "by default", and the IMO info level is the "default" for production. So what can we do about it?

This log could be an info level log.
The response message could contain error information.

I can make a PR for one or both of these, but I would like to first hear your (maintainers'/community) opinion on that. Especially I would like to know which solution you would prefer.

I'm sorry for the overdue reply, and thank you for reporting.
I'm reluctant to log full stack traces on client errors, because logging stack traces at high volume can really gum up a server, and it becomes an attack vector.  I prefer Option 2.
I like what Jetty does.  In response to this request,
GET foo/bar HTTP/1.0

We get:
HTTP/1.1 400 Bad URI
Content-Type: text/html;charset=iso-8859-1
Content-Length: 50
Connection: close
Server: Jetty(9.4.39.v20210325)

Bad Message 400

reason: Bad URI

It tells us the broad category of what's wrong, without putting anything into the body that could be used in an XSS attack.


Extended Protection authorization issue

Hi. Please tell me if anyone has encountered this problem.
I followed the manual "https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/" strictly.  After enabling Extended Protection on some users' devices, Outlook does not connect, keeps asking for password and does not let me authorize. The problem is not NTLM or SLL unloading.
After that, I rolled back the script and started enabling all the settings manually one by one in IIS. And this problem appeared when I enabled Windows Authentication (Extended Security) in DefaultWebSite under RPC. This problem occurs not on all devices in the local network, but only on some, a pattern I have not identified.

@Asmund22 did you verify that the Outlook client isn't forced to use NTLMv1 as the article provides?

If you are still having issues with connectivity, then you must open a ticket for investigation. The issues on GitHub are for issues with running the script. Not for issues with the product. The script is to assist you with enabling Extended Protection against your Exchange Server correctly.

I'm sure all clients only use NTLMv2.

I'm sure all clients only use NTLMv2.

Then you would likely need to open a case to troubleshoot the issue to determine why your environment is experiencing the problem.

Closing issue, no issue with script.


Trailing slash on realm URL can happen, and breaks /events

[Original title: "Message list won't update, on iOS on physical device". Better characterized below after some debugging.]
AFAIK this doesn't appear in any actual release we've made -- but it happens on 25.7.121 and 25.8.122 (aka current master), in their respective alpha release builds, on my iPhone 7 running iOS 12.3. So we can't make a release until it's fixed.
It also happens in a debug build on that same device.
It doesn't happen in a debug build on an iPhone XR simulator running iOS 12.4... nor on an iPhone 7 simulator running iOS 12.4.
The symptoms are:

When looking at a message list, it (usually!) fails to update when something changes -- a message arrives, a reaction, etc.
When you send a message, it goes through fine... but the "outbox" object, which shows up as a message with a spinner on it, sticks around. It's still there even if you leave the message list and come back.

Ohhh -- it's that we're just not getting events.
First clue to this was on looking in the debug console, seeing this happening over and over:
{route: "events?queue_id=1563767601%3A50342&last_event_id=-1", params: {…}, httpStatus: 404, json: undefined}

But wait, why was I seeing updates if I navigated out of the message list and then back to it? ... It's because we were doing a new fetch. I'm not entirely sure why that is -- don't we avoid those if we're all caught up? the log shows we had caughtUp of {older: false, newer: true} for the narrow in question, hmm -- but the log shows we were, and that certainly explains getting the updates then.
I thought I'd spotted an update another time, too, while still looking at the message list. Maybe I'd somehow provoked another fetch? Or maybe I'd just confused that with seeing an update after navigating away and back.
Anyway, that certainly explains all the symptoms. Next question: what's in turn causing it.

Puzzling. Odd facts include:

It works fine for (my usual account on) chat.zulip.org. Where it doesn't work is a test org on kandra-test.zulipchat.com.

Possibly another symptom of #3196, somehow? That test org still has that setting enabled.

I'm not seeing anything corresponding to these requests when I look in the zulipchat.com server logs. There are no 404s at all in /var/log/zulip/tornado.log (which has numerous 200 lines for successful requests of the same type); presumably that means these requests aren't making it to Tornado, but I don't see any sign of them in /var/log/nginx/{access,error}.log either.

Aha! The error seems to be...
in the case where it's failing, the request is going to a URL like https://example.zulipchat.com//api/v1/events?queue_id=1234567890%3A12345&last_event_id=-1. With a double slash at the start of the path.
I think this naturally happens if the realm value we've saved has a trailing slash.
And, indeed, the Redux log shows that is the case for the realm value on that account on that device; but not for the czo account, nor for the account as I've saved it in the simulators where this didn't reproduce.
Phew. Well, that won't be too hard to resolve, then.

OK, at this point there are two puzzles, both of which go to the question of how widespread this is.

How did I manage to have a realm value ending in a slash? In the current code, that should be impossible because -- well, SmartUrlInput (which we use for entering the URL that becomes the realm value) is a bit intricate, but among other things we apply fixRealmUrl to the URL, and that among other things strips a trailing slash.
Going through the history, that logic was added in commit 507839a39, of 2017-05-11. ... Ah, but git describe --contains says it only went out in 1.0.11 -- of 2017-06-28. By then I'd surely have installed the app on my main personal device (having started work at Zulip earlier that month); and, via an iCloud backup/restore, that data was inherited by the iPhone where I'm seeing the issue. OK, that's explained then.

Ha, and also the logic only strips a single trailing slash. So by entering two trailing slashes at login, I've just reproduced the issue on my Android phone, too.

What changed now? This extra slash has presumably been there for over two years, on my successive iPhones, every time I use this test org there. Which... at a minimum I use that device to smoke-test each release, and I might use czo but I'm pretty sure I've often used this test org there. Might not have been today or this week that something changed to trigger this, but surely in the last few months.

In any case, no longer a critical priority, because it's hard to trigger unless you have an install that's over two years old. I might not be the only one, though -- we should do something to clean these up.

@timabbott Do you know a reason why this might have started failing recently? Summarizing what I found above:

A request to something like https://example.zulipchat.com//api/v1/events?queue_id=1234567890%3A12345&last_event_id=-1 -- note the double-slash -- returns 404, and doesn't make it to tornado.log at all.

Other routes (//api/v1/register and everything else) are fine, though; only events is affected.

I've almost surely been making these double-slash requests every time I use my test org, on my physical iPhone, for the past two years. I'm not certain just how recently I would have noticed if it broke (it's possible the last few times I've tested things on my iPhone have all been on czo instead of that test org)... but I'd be surprised if it was already broken by a few months ago.

Some change in our nginx and/or load-balancer setup, perhaps?

Things I expect we'll want to do to clean this up:

Tweak fixRealmUrl so it strips any number of trailing slashes.
Add a migration that strips trailing slashes on realm in all existing accounts.

Woah, that's weird.  I am not aware of server-side changes that might have caused this; git log -p zproject/urls.py doesn't show any recent relevant changes.  If it were affecting all routes, I would have speculated that this could be a change in upstream Django or Tornado that we took; here's what our code looks like:
    # used to register for an event queue in tornado
    url(r'^register$', rest_dispatch,
        {'POST': 'zerver.views.events_register.events_register_backend'}),

    # events -> zerver.tornado.views
    url(r'^events$', rest_dispatch,
        {'GET': 'zerver.tornado.views.get_events',
         'DELETE': 'zerver.tornado.views.cleanup_event_queue'}),

So those should behave the same.  A Tornado upgrade might be the source; zerver/tornado/application.py defines the Tornado URLs, and /register isn't one of them.  Not much to test with that theory, since only /events is user-facing.

Huh, odd, then.
Well -- I guess that will stay a mystery, then. Most likely it's been this way for some months, which at least means the fact nobody noticed before is a good sign that this is affecting very few people.

Hmm, while working on https://github.com/zulip/zulip-mobile/pull/4034, I found that, apparently, we're accessing the social auth endpoints with a double slash, every time —
https://chat.zulip.org//accounts/login/social/google
— and it works fine in production, but I get a 404 with a dev server. (Why the difference, I wonder?)
This isn't really related to how the realm URL is stored in Redux, but I'm posting this here in case it leads to clues about the following oddness, which I think still hasn't been fully explained?
@gnprice said:

A request to something like https://example.zulipchat.com//api/v1/events?queue_id=1234567890%3A12345&last_event_id=-1 -- note the double-slash -- returns 404, and doesn't make it to tornado.log at all.
Other routes (//api/v1/register and everything else) are fine, though; only events is affected.

Here's where the extra slash is getting added, in src/start/AuthScreen.js:
  beginWebAuth = async (url: string) => {
    otp = await webAuth.generateOtp();
    webAuth.openBrowser(`${this.props.realm}/${url}`, otp);
  };

where url is .login_url on an item in external_authentication_methods, and all of these have a leading slash, which you can see in, e.g.,
curl https://chat.zulip.org/api/v1/server_settings | jq .external_authentication_methods

We should probably be using a proper library for joining URLs rather than string concatenation.

We should probably be using a proper library for joining URLs rather than string concatenation.

Makes sense. I just opened https://github.com/zulip/zulip-mobile/issues/4081 for this, linking to a few other comments along these lines.

(Opened a fix for the duplicated slashes issue as https://github.com/zulip/zulip-mobile/pull/4082.)

We just had a report of this last week, in #4070.
AFAIK that's the first report we've heard from a user other than me. On the other hand... this user sure doesn't sound like they've been using the app since 2017 and just now hit the issue, so that means it is possible for a new user (not only a very old one) to run into in real life.
And because it hits when you first log in, and makes the app just basically not work at all, it's likely to be under-reported due to people simply giving up.
So, we should fix it. Here's the steps I described above:

Things I expect we'll want to do to clean this up:

Tweak fixRealmUrl so it strips any number of trailing slashes.
Add a migration that strips trailing slashes on realm in all existing accounts.

@gnprice said:

So, we should fix it. Here's the steps I described above:

Things I expect we'll want to do to clean this up:

Tweak fixRealmUrl so it strips any number of trailing slashes.
Add a migration that strips trailing slashes on realm in all existing accounts.

Makes sense. I've got https://github.com/zulip/zulip-mobile/pull/3819 open for this, awaiting review at your convenience.

clues about the following oddness, which I think still hasn't been fully explained?
@gnprice said:

A request to something like https://example.zulipchat.com//api/v1/events?queue_id=1234567890%3A12345&last_event_id=-1 -- note the double-slash -- returns 404, and doesn't make it to tornado.log at all.
Other routes (//api/v1/register and everything else) are fine, though; only events is affected.

@chrisbobbe Do you mean the contrast between //api/v1/events and //api/v1/anything-else? That one, I think we understand well enough for this issue:

In the client, we're treating those routes the same way -- so that when the realm URL has a trailing slash, we send a double-slash.
The server is giving different results, though.
This isn't too surprising, because /events uniquely needs to be routed to our Tornado server -- so either Tornado, or something else in the chain leading there, apparently rejects the double-slash URL, while plain Django accepts it.

I've got #3819 open for this

Ah, thanks for the reminder >_> I'll take a look now.

Do you mean the contrast between //api/v1/events and //api/v1/anything-else?

Right.

This isn't too surprising, because /events uniquely needs to be routed to our Tornado server -- so either Tornado, or something else in the chain leading there, apparently rejects the double-slash URL, while plain Django accepts it.

Ah, OK! It sounds like either this solves the mystery you mention here —

Huh, odd, then.
Well -- I guess that will stay a mystery, then.

— or you were referring to a different mystery. In any case, it sounds relevant.

Ah, yeah. The really mysterious thing to me was what changed on the server -- the same account where things weren't working and that caused me to report this bug, I'd used in the past and it must have worked before.
(But I wasn't sure how recently I might have used that particular test account on that device and seen things working, which helped make it hard to pin down.)


pre-release

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+28.8%) to 96.97%

Totals

Change from base Build<PHONE_NUMBER>:
28.8%

Covered Lines:
64

Relevant Lines:
66

💛  - Coveralls


feat(combobox): implement on open event for combobox

Description

"combobox-on-expand" dispatch event is implemented. This event will trigger every time when we open the Combobox.
New property "show-loader" has been implemented. This will be helpful to show the custom loader slot content.

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots:
Before (If applicable):

After:

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation update
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

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.

Please resolve the conflicts


Add Featured Profile Component

For the home page, the easiest thing to do is to make a featured profile card component that stores specific data (picture, name, link). Then, we could put a container (or just a div) on the homepage and change these profiles as we see fit. So ideally, this component should take a picture url, a page url, and a name. This will return a card with a picture and name that is properly linked with react-router

Finished this, will PR soon similar to #75


Any plan to support the Logitech G915?

So the G915 is one of the new keyboards not supported in LGS and only supported in Ghub. Ghub is a freaking nightmare, however, and the RGB settings are the only settings for the G915 I want to change. Is there any hope that you guys will support the G915 at all? Specifically I want to be able to change the stock animation and remove the RGB illumination timeout.
Thanks.

I've been using G915 with Aurora. I've selected "Logitech - G910" as keyboard and it has worked well enough. So it seems that both keyboards (G910 and G915) talk same language.
Few times Aurora crashed but after I learned what functions caused those crashes I've just avoided using those and everything seems to work well.

The G910 works, but doesn't support the LEDs for the media keys, or recognize the volume roller.

+1
This might have renewed interested with the TKL version being released recently. It's still a little weird when resuming from sleep, but otherwise 910 profile works.

+1
This might have renewed interested with the TKL version being released recently. It's still a little weird when resuming from sleep, but otherwise 910 profile works.

Have you tried the G915 TKL with the G815 support?

Have you tried the G915 TKL with the G815 support?

Yep, and it's still spotty.

As I realised, there is no need to hold back @holrits ; I using G915 with Aurora right now. You will need G HUB instead of LGS :)
What do You mean spotty, @charmarkk ? Thanks for info


[Bug]: Vue style loss since Rspack v1.0.4

Version
System:
OS: macOS sonoma 14.6.1
Binaries:
Node: 18.20.4 - /usr/local/bin/node
npm: 10.7.0 - /usr/local/bin/npm
Browsers:
Chrome: 128.0.6613.120
npmPackages:
@rspack/core: 1.0.2

Details
When I used<EMAIL_ADDRESS>the page style of vue3 was lost (each page was loaded asynchronously). When I rolled back the version to 1.0.1-beta.13, everything was normal
Reproduce link
No response
Reproduce Steps
rsbuild dev

Related to https://github.com/web-infra-dev/rspack/pull/7846
We will release a new version to fix this issue soon.

When will it be released?

Today

Fixed in:

https://github.com/web-infra-dev/rsbuild/releases/tag/v1.0.3
https://github.com/web-infra-dev/rspack/releases/tag/v1.0.5


(question): how to disable search bar

Hello everyone, i'm kinda new exploring plugins, and i didn't find any thing related to that in the documentation (please warn me if it does exist), so. How to disable the search bar (if it's possible) in the file browser?

Thanks for answering me, i guess :D

Telescope (and by extension, this plugin) is a fuzzy finder over lists - so searching is kind of the whole point.
If you're not interested in searching, then this plugin might not be for you.

I understand, thanks for the answer jamestrew.


Use bundler caching in CI

Not sure if I added the:
- gem update --system
- gem install bundler

If I did, they can go, if you did, you can choose.

Looks good. Why is cache not default?


🎉 1.1.1

ℹ About this release

Version: 1.1.1
Type: patch
Last Release: 1.1.0 (1/10/2024, 8:13:05 PM) [?]
Commits to merge: 11 [?]

📦 Dependencies

Update @prisma/client from ^5.8.0 to ^5.9.1
Update mailparser from ^3.6.6 to ^3.6.7
Update moment-timezone from ^0.5.44 to ^0.5.45

📦 Development Dependencies

Update prisma from ^5.8.0 to ^5.9.1

:tada: This PR is included in version 1.1.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v1.1.1

Your semantic-release bot :package::rocket:


Free drink tickets for Speakers

we need a few beforehand for tomorrow.
Thank you man!

Everyone can ping the bot using sysarmy, adminfest or adminbirras string and will get a code for the machine. Only sponsors will have pre printed tickets.


"Enter Attendance" at top of page for logged in users

Dependent on attendance fixes

this was fixed with #115


Heavy buoyancy jitter

When switching in the demo to the boat mode and increasing wind speed and chopiness, the jitter is very visible. It seems to not come from the physics system, but the wave heights computed in the compute shader.

Could you share your settings/OS/render mode? I'm not getting any jitter if frameskip or heightmap sync frameskip are set to 0, and only getting the amount of jitter I'd expect to see with those settings increased.

Bildschirmaufzeichnung vom 2024-02-13, 22-03-56.webm
This is the latest commit on devel. I also have frameskip and heihgtmap sync set to 0. I reduced the lods to 1 to get acceptable fps.

I use Linux/integrated graphics, so I only got ~25fps, but that shouldnt affect the waves.

I think that may possibly be Z-fighting, the cameras in the example scene have a very large range (near 1.0 far 16000.0) which would make that likely to happen.
If you lower the far plane on the camera, does that reduce this flickering?

I've finally had a chance to sit down and investigate this closer, and it's definitely not Z-fighting. It's also noticeable on Windows 10 with a Radeon 6700.
It appears to be the result of the ocean simulation being out of sync with the buoyancy/physics system. If I run on a strong enough computer to reach 60fps, Vsync enabled, and 0 simulation and height map sync frame skips, then the ocean simulation is in sync (or near enough) with the physics system, the jitter is not noticeable.
If the Ocean TPS counter in the example scene is either above or below 60, the jitter becomes noticeable. Possibly because the height map is getting updated by the compute shaders on the render thread when the physics thread is trying to use it.
So the solution here is likely to make the height map sync in the render thread happen in sync with the buoyancy calculations in the physics thread, ideally without a significant performance impact.

Also setting the "maximum physics steps per frame" godot setting to 1 helped for me a bit. I tried once to get the wave height of buoyancy probes in _process(), store them, and access them later in _physics_process(), but that didnt seem to work (maybe I did it wrong though)

Once asynchronous gpu readbacks get implemented into godot it might help with the jitteriness of buoyant objects as explained by acerola in his buoyancy video


Netflix plugin??

Can someone make a Netflix plugin? Willing to pay for it.

This would be pretty cool tbh. Should have to be too much different from the youtube one.

@Benji-Collins You know how to make it?

No I don't unfortunately.

oh

A lot of sites block logins if they can tell that it comes from a proxy and I don't think that there's a way around this yet. In such cases it's probably better to use a VPN.

Trying to unblock Netflix. I got a web proxy working for everything for Netflix except the playing of videos. Netflix uses web sockets to play videos but the proxy doesn’t support those so I need someone to add that for me...


package structure

Separate your project into behaviors. Currently I perceive this as a single monolithic package that could have been made into multiple ones.
https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1
https://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project

Thanks for pointing this out.
I was thinking of adding a mock package to allow easy implementation and testing when integrating the package but I was wondering if people won't prefer making their own mocks.
For the split of the package itself, I'm thinking of a split by service, one sub-package by Twilio entity. eg: one for phonenumbers one for sms one for voice etc...
WDYT ?


Build is old. Need to rebuild the project.

The project has not been rebuilt since 1d1cd4 (Added support for stoken). So build\ angular-no-captcha.min.js does not reflect changes in src\ angular-no-captcha.js.

Fixed


Revert "updating tower-cli docs to use the standard ansible tower themes and …"

Reverts ansible/tower-cli#411
Since we don't have plan to actually include CLI docs to official site, this PR should be reverted as it blocks readthedocs rendering.

there's a strange flake8 failure, maybe due to the branch point?

Coverage remained the same at 90.37% when pulling 65b71005ea80ca352bebb8568e6bdd24366ede0e on revert-411-towercli-saw-docs into 71d452452420f8241a5709c3746375dbca23ea65 on master.


Download Links Missing

Sorry to bother you again, but KissAnime changed it's HTML/CSS and now Minimal KissAnime isn't showing Download Links anymore.

807bdbd should fix this.


Adding Farm Tools Enhancement

Description
Our team is tasked with enhancing the game by introducing a set of essential tools that the player can utilise. This addition will allow the player to interact with their environment in new ways and enable more strategic gameplay decisions for the player. Players will have access to tools like a hoe for preparing soil, watering can to nurture crops and a sickle for harvesting. These tools will offer the player a comprehensive toolkit for successful crop management.
SubFeature/component
Each tool will have its unique functionality:
Hoe: Players can interact with tiles to till the ground, preparing it for planting crops.
Shovel: The shovel acts as an undo button for tilled soil or planted crops that the player does not wish to be there.
Watering Can: Crops on specific tiles can be watered, nurturing their growth over time.
Sickle: Certain plants can be harvested using the sickle, providing essential resources.
Tractor: A multi-functional vehicle with an inventory system, farming abilities, and travel features.
Design: sourcing art for all the above tools
Examples
Hoe: To plant seeds effectively, players will need to use the hoe to till the ground before sowing their crops.
Shovel: The shovel acts as an undo button for tilled soil or planted crops that the player does not wish to be there.
Watering Can: Once planted, crops require water to flourish. The watering can allows players to interact with crops and provide the necessary hydration for their development.
Sickle: When crops have matured, the sickle can be use to harvest them.
Tractor: The tractor will become a player's reliable companion for hauling resources, moving around the game world efficiently, and assisting in farming tasks. The tractor bundles tilling, harvesting, etc..? into one.
Dependencies
Sickle, shovel, watering can and hoe - the functionality of changing the tile depends on team 7 (tile system) and team 6 (crops).
Milestones

[x] Goal 1 (Aug. 22): Implement basic functionality of hand-held tools, including interaction mechanics and preliminary animations. Extend item class and ensure functionality for items of different types (tools, consumables etc...)
[x] Goal 2 (Aug. 24): Complete implementation of watering can, sickle, shovel, ensuring seamless integration with the existing game mechanics.
[x] Goal 3 (Aug. 26): Thorough testing and debugging to ensure the tools function flawlessly and enhance the overall gameplay experience.
[x] Goal 4 (Aug. 28): Implement polished animations for each tool, enhancing the visual appeal and realism of the interactions.

Completion Deadline: Aug. 30
Extras (optional)

[x] Goal 5: If time persists implement basic functionality of tractor (moving tractor + getting in and out of the  tractor)

Documentation
Members
Shanon Lakshan Chandrasekara (@86LAK)
Jackson Trenerry (@JTrenerry)
Peter Lahanas (@p-lahanas)
Cohen Porteous (@cmp6)
Liam Anderson (@LiamAnd)

Above commit closes this


How to compile wenet executables on an ARM-based ubuntu machine?

Problem description:
/usr/bin/ld: ../fc_base/libtorch-src/lib/libtorch.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/ctc_prefix_beam_search_test.dir/build.make:99: ctc_prefix_beam_search_test] Error 1
make[2]: Leaving directory '/home/taishan/test/wenet/runtime/server/x86/build'
make[1]: *** [CMakeFiles/Makefile2:400: CMakeFiles/ctc_prefix_beam_search_test.dir/all] Error 2
make[1]: Leaving directory '/home/taishan/test/wenet/runtime/server/x86/build'
make: *** [Makefile:155: all] Error 2
A version problem with libtorch seems to be causing the problem.
set(PYTORCH_VERSION "1.6.0")
......
elseif(${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
set(LIBTORCH_URL "https://download.pytorch.org/libtorch/cpu/libtorch-cxx11-abi-shared-with-deps-${PYTORCH_VERSION}%2Bcpu.zip")
set(URL_HASH "SHA256=c6c0d3a87039338f7812a1ae343b9e48198536f20d1415b0e5a9a15ba7b90b3f")
The CMakeLists file at runtime specifies the path to the libtorch download and the URL_HASH. How do I change the default values here to download the arm version of libtorch.
Looking forward to receiving your reply!

~/test/wenet/runtime/server/x86/fc_base/libtorch-src/lib$ file libtorch.so libtorch.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0c8cb78054367df4779d343b1308c477078f7750, not stripped
The default URL of the CMakeList file to download libtorch is x86 architecture. I would like to know how to modify the set(LIBTORCH_URL xxx) and set(URL_HASH) to obtain the arm architecture libtorch.

你可以在这里看到，定义torch下载的url

你可以在这里看到，定义了LIBTORCH_URL 下载的url

The link from the official website is to download x86 libtorch, but I don't know a URL to download aarch64 libtorch

我想你是在寻找这个问题，其中提出了https://github.com/KumaTea/pytorch-aarch64/releases，可以下载相关内容

我也有这个问题


Update .env_sample

@ihsaan-ullah @bbearce @acletournel
This concerns the installation of Codabench. How can we confirm that this change is good?
If the installation previously worked for you, please try to re-install from scratch using this .envfile.

Not sure if this is useful


Improve WAL MT scalability.

After https://github.com/orientechnologies/orientdb/issues/2874  we have all chances to impove WAL scalability.
WAL can be presented as multi producer - single consumer queue.
To implement this queue we can use single producer - single consumer queue where each separate thread will play producer role and WAL thread will play consumer role.
Queues can be stored inside of thread aware hash map as we did for RW spin lock.
For SPSC queue we can use improved version of Lamprot queue  or Fast Flow queue.
To keep append only (queue like) WAL nature and prevent reordering of records on producers side
we will calculate LSN on producers side using atomic variable, on consumer side we will use simple TreeMap to sort records by LSN as criticical size of buffer or time limit will be reached we will flush all WAL records which have no gaps between each other on disk.

Related also to https://github.com/orientechnologies/orientdb/issues/3882

Optional for 3.0

Implemented in 3.0.9


Update specs2-core, specs2-scalacheck to 4.10.1

Updates

org.specs2:specs2-core
org.specs2:specs2-scalacheck

from 3.+ to 4.10.1.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.specs2" } ]

labels: test-library-update

Superseded by #25.

Superseded by #25.


Linkfix for thymeleaf link

On this page
https://spring.io/guides/gs/serving-web-content/
If you search thymeleaf on that page, the first link is broken. I
think the correct link should be
http://www.thymeleaf.org/doc/tutorials/2.1/thymeleafspring.html, but
not 100% sure.

Resolved via https://github.com/spring-guides/gs-serving-web-content/commit/99a8bb77758a2d041bfadaaf6c8241fd59d27ae7


Camp Harmony report: total paid for registration

Ellen says: the payment report is not detailed enough. It shows just the total amount paid, which will include any campership donations. I want to separate campership donations from registration.
We can get total paid for linens from the report showing how many linens we need.

I have a campership donation report, ask Ellen if this works: https://harmonyreg.sffmc.org/admin/organization/1/event/1/reports?reportId=4

Please see if the latest version works

Looks great! Closing ticket.


Data Encryption and Decryption in Java Using Spring Boot

Article checklist
Pre-submission checks

Please ensure that you have only one open topic suggestion (issue) + in-review article (linked pull request) at a time. This will ensure that we complete the review process in a timely manner from inception to publishing

If you have not already, please go over our Resources Page for more tips and tricks on how to improve your overall technical writing so reviews are swifter, increase the chance of a payout and provide more value to our readers.

For first-time contributors and for more details on our submission guidelines, see our Contributing Guidelines.

Formatting and structure checks

[x] Have you used the correct folder and file structure? - see Contribution Guidelines

[x] Is your article properly formatted in Markdown? - see Github Markdown guide

[x] Have you used our preferred heading structure? - H3 (###) and up

[x] Does your article follow any of the suggested structure formats? - see example formats

[x] Is your article over 750 words? - Tool: Wordcounter.net

[x] Is the article you are submitting an in-depth and unique article? Does it go beyond what is in the official docs and what is covered in other blog sites. See these articles as examples.

[x] Does your article provide enough value and detail about your topic? - Articles should be clear, accurate, and fully explained.

[x] Can your article be understood by beginners? - Assume the audience is smart but has no prior exposure to the common terminology in your article.

[x] Have you included a hero image that is 600x400 pixels and have the copyright to use it? - Tools: Pixlr Image Editor for resizing and Unsplash for Creative Commons images

Grammar & plagiarism checks

[x] Have you spellchecked and grammar checked your article? - Tools: Write&Improve - ProWritingAid - Grammarly
[x] Please place your article through a 3rd party plagiarism checker. We suggest using Quetext, this tool is free and has a daily limit. We typically accept articles with 10% or less.
[x] Have you checked your article for readability? - Tool: Hemmingway
[ ] Have you added sources for quotes and images that aren't yours?

Technical checks

[x] Are your code snippets properly formatted for syntax highlighting - see Syntax guide
[x] Have you checked your code runs correctly and you've highlighted all necessary dependencies for installation?
[x] Are the software programs and packages you're highlighting in your article up to date, using current versions and not deprecated?

Topic suggestion this closes

Remove the backticks and add the issue number below to link and close your Topic Suggestion (issue) when your article has been published (PR has been merged). See this video for more details.

`This closes issue #4268

Finally, delete the article checklist notes in blockquotes and submit your PR. We look forward to reviewing your article.

This fixes #4268

Upon running your article through our 3rd party plagiarism checker it seemed to raise a few flags and the % was higher than we typically accept. Please see attached PDF - and revisit the article to ensure we are contributing wholly unique and original content. Be sure to see our resources page to see more info on plagiarism and what is considered as such.
Data Encryption and Decryption in Java Using Spring Boot #4615 Copyleaks Report.pdf

@teevyne
Good afternoon and thank you for submitting your topic suggestion.
It seems this PR is still quite a bit aways from being completed. As a rule of thumb - please only submit articles (pull requests) with a complete and fully polished article - ready to be published.
All revisions and edits should be completed on your own forked repo (as to not take up room in the queue).
We will be closing this and please re-submit when it is ready to be published as a new PR (and you can add the duplicate label) and ping the reviewer and myself.
Closing a PR does NOT mean the article can not be published (or fixed) it simply means that the edits, revisions, and fixes will happen outside of the queue.

@teevyne
Please ping me in the new PR when all the changes are done.
Thanks.

@teevyne
Please ping me in the new PR when all the changes are done.
Thanks.

I definitely will. I am working on it as we speak. Thank you very much


[Kernel]  Expand MoE weight loading + Add Fused Marlin MoE Kernel

Summary

Expands weight loading to support grouped and per channel weight quantization. Cleans-up fp8 MoE to use the updated weight loading
Adds Marlin Fused MoE Kernel for w4a16 by @ElizaWszola
Adds CompressedTensorsMoEMethod to support MoE w4a16 models from llm-compressor and compressed-tensors
Tested using 2 and 4 TP with Mixtral

TODO:

Test with deepseek v2

Next Steps:

The CompressedTensorsMoEMethod is not leveraging the scheme structure in-place for compressed-tensors in order to keep the scope of this PR focused on the kernel + updated weight loading. Will be updated in a follow-up to use the scheme structure

co-authored by @ElizaWszola, from Neural Magic

/ready

Have you tested deepseek-v2?

I tried to run deepseek-v2-fp8(https://huggingface.co/neuralmagic/DeepSeek-Coder-V2-Instruct-FP8) with this PR and 8 L40 GPUs, and encountered the following error:
model:
VllmWorkerProcess pid=6252) INFO 08-22 22:07:58 model_runner.py:890] Loading model weights took 28.2205 GB
(VllmWorkerProcess pid=6256) INFO 08-22 22:07:58 model_runner.py:890] Loading model weights took 28.2205 GB
(VllmWorkerProcess pid=6255) INFO 08-22 22:07:58 model_runner.py:890] Loading model weights took 28.2205 GB
(VllmWorkerProcess pid=6254) INFO 08-22 22:07:58 model_runner.py:890] Loading model weights took 28.2205 GB
(VllmWorkerProcess pid=6257) INFO 08-22 22:07:58 model_runner.py:890] Loading model weights took 28.2205 GB
INFO 08-22 22:07:58 model_runner.py:890] Loading model weights took 28.2205 GB
(VllmWorkerProcess pid=6251) INFO 08-22 22:07:58 model_runner.py:890] Loading model weights took 28.2205 GB
(VllmWorkerProcess pid=6253) INFO 08-22 22:07:58 model_runner.py:890] Loading model weights took 28.2205 GB
ERROR 08-22 22:07:59 multiproc_worker_utils.py:120] Worker VllmWorkerProcess pid 6252 died, exit code: -15
INFO 08-22 22:07:59 multiproc_worker_utils.py:123] Killing local vLLM worker processes
Process SpawnProcess-1:
Traceback (most recent call last):
File "/usr/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap
self.run()
File "/usr/lib/python3.9/multiprocessing/process.py", line 108, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/entrypoints/openai/rpc/server.py", line 230, in run_rpc_server
server = AsyncEngineRPCServer(async_engine_args, usage_context, rpc_path)
File "/usr/local/lib/python3.9/dist-packages/vllm/entrypoints/openai/rpc/server.py", line 31, in init
self.engine = AsyncLLMEngine.from_engine_args(
File "/usr/local/lib/python3.9/dist-packages/vllm/engine/async_llm_engine.py", line 740, in from_engine_args
engine = cls(
File "/usr/local/lib/python3.9/dist-packages/vllm/engine/async_llm_engine.py", line 636, in init
self.engine = self._init_engine(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/engine/async_llm_engine.py", line 840, in _init_engine
return engine_class(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/engine/async_llm_engine.py", line 272, in init
super().init(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/engine/llm_engine.py", line 284, in init
self._initialize_kv_caches()
File "/usr/local/lib/python3.9/dist-packages/vllm/engine/llm_engine.py", line 390, in _initialize_kv_caches
self.model_executor.determine_num_available_blocks())
File "/usr/local/lib/python3.9/dist-packages/vllm/executor/distributed_gpu_executor.py", line 38, in determine_num_available_blocks
num_blocks = self._run_workers("determine_num_available_blocks", )
File "/usr/local/lib/python3.9/dist-packages/vllm/executor/multiproc_gpu_executor.py", line 192, in _run_workers
driver_worker_output = driver_worker_method(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/torch/utils/_contextlib.py", line 116, in decorate_context
return func(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/worker/worker.py", line 222, in determine_num_available_blocks
self.model_runner.profile_run()
File "/usr/local/lib/python3.9/dist-packages/torch/utils/_contextlib.py", line 116, in decorate_context
return func(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/worker/model_runner.py", line 1097, in profile_run
self.execute_model(model_input, kv_caches, intermediate_tensors)
File "/usr/local/lib/python3.9/dist-packages/torch/utils/_contextlib.py", line 116, in decorate_context
return func(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/worker/model_runner.py", line 1415, in execute_model
hidden_or_intermediate_states = model_executable(
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/model_executor/models/deepseek_v2.py", line 504, in forward
hidden_states = self.model(input_ids, positions, kv_caches,
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/model_executor/models/deepseek_v2.py", line 461, in forward
hidden_states, residual = layer(positions, hidden_states,
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/model_executor/models/deepseek_v2.py", line 401, in forward
hidden_states = self.mlp(hidden_states)
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/model_executor/models/deepseek_v2.py", line 148, in forward
final_hidden_states = self.experts(
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/model_executor/layers/fused_moe/layer.py", line 287, in forward
final_hidden_states = self.quant_method.apply(
File "/usr/local/lib/python3.9/dist-packages/vllm/model_executor/layers/quantization/fp8.py", line 499, in apply
return fused_experts(x,
File "/usr/local/lib/python3.9/dist-packages/vllm/model_executor/layers/fused_moe/fused_moe.py", line 544, in fused_experts
moe_align_block_size(curr_topk_ids, config['BLOCK_SIZE_M'], E))
File "/usr/local/lib/python3.9/dist-packages/vllm/model_executor/layers/fused_moe/fused_moe.py", line 228, in moe_align_block_size
ops.moe_align_block_size(topk_ids, num_experts, block_size, sorted_ids,
File "/usr/local/lib/python3.9/dist-packages/vllm/_custom_ops.py", line 28, in wrapper
return fn(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/vllm/_custom_ops.py", line 485, in moe_align_block_size
torch.ops._C.moe_align_block_size(topk_ids, num_experts, block_size,
File "/usr/local/lib/python3.9/dist-packages/torch/ops.py", line 1061, in call
return self._op(*args, **(kwargs or {}))
RuntimeError: CUDA error: invalid argument
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with TORCH_USE_CUDA_DSA to enable device-side assertions.

@fengyang95 it looks like your issue is due to incorrectly compiled or linked functions, possibly from older builds. Could you build vllm in a fresh environment?

ooks like your issue is due to incorrectly compiled or linked functions, possibly from older builds. Could you build vllm in a fresh environment?

I tried recompiling in a new environment but still encountered the same issue. Has this been tested on ds-v2?

ooks like your issue is due to incorrectly compiled or linked functions, possibly from older builds. Could you build vllm in a fresh environment?

@mgoin I tried recompiling in a new environment but still encountered the same issue. Has this been tested on ds-v2?

@fengyang95 Do you mind sharing a code snippet of what you're running?
The scope of the fused marlin kernel  introduced in this PR is focused on w4a16 models.  It does not support FP8 models at the moment.

@fengyang95 Do you mind sharing a code snippet of what you're running? The scope of the fused marlin kernel introduced in this PR is packed w4a16 models. It does not support FP8 models at the moment.
Oh, I was using an FP8 model.
https://huggingface.co/neuralmagic/DeepSeek-Coder-V2-Instruct-FP8

@fengyang95  FP8 models will use the triton kernels which should work with the DeepSeek V2 model listed.
Adding FP8 Fused MoE Marlin kernel is not in scope at the moment.

How should I load a w4a16 version of deepseek-v2 that was compressed using llm-compressor?


AAID crashes once connection to car is successful

Hello,
I've noticed recently that with bmw connected functioning and registering as connected to the vehicle, the AAID app will only open momentarily and then it immediately force closes and after a few tries, actually causes my head unit to crash and reboot which sometimes allows for the connection to remain stable and other times it does not.
Anyone else having this issue?

Apart from the head unit crash, I have the same issue. See #322

I haven't seen any new crashes come through the analytics, can you pull an adb logcat to see what specific crash you are seeing?

@hufman This morning with the MyBMW app connected: first AAID didn't start, after I started it on my phone it's crashed.
logcat_06-23-2021_09-28-41.txt

@hufman the application works well, but only until you launch it on your phone - look at 08:58:15
logcat_06-24-2021_08-58-34.zip

I think I fixed this by unsubscribing from the MyBMW debug status announcements. The particular error message seems to indicate that the RPC buffer to receive these announcements was filling up, even though each individual message was tiny (900bytes combined to be bigger than 2MB), so I suspect there's some lag in some phones that cause the messages to back up and overflow, which I never could see on my own phone.
After about 30 minutes, check the latest build (c9fc6ff) and see if it helps.

@hufman New log: 11:11:43:637
logcat_06-24-2021_11-11-54.zip

It's hard to tell, I'm not sure that the log says what version you installed, but it looks like you installed at 11:04 and the updated package only got uploaded at :03 after the hour. Can you confirm the version string of the installed app version?
If it is the new version, I guess the fix didn't help.

@hufman I run c9fc6ff:

I tried reducing how many copies of the BclListener are subscribed, maybe it helps? It was previously registering about 4 copies, now it should just register one, which should reduce how much traffic is passing through the Binder buffer.

I spent 20 minutes today doing everything to crash AAiD - I couldn't. :) The app works stably, I think the problem is solved.

@unlive74 I'm glad to hear that!
@samusishere have you experienced this headunit crash recently? I pushed a tweak yesterday that might have helped.

@hufman I just saw the notification you pushed the new change! I noticed that using the mini app actually allowed the head unit to connect to my device and stay connected, and AAID wouldn't crash and neither would the headunit. It only occured whenever I used the BMW connected app. Still haven't been able to make the new MyBMW application connect to my vehicle and open the connection for apps.

I'm glad you figured it out! I'm very intrigued by you saying the Mini app can connect, what sort of car do you have?

I have a 2013 late model year 528i with what AAID calls ID4++

Haha it's true, both the MyBMW and the Mini apps (starting in version 1.4.0) include the USB Accessory configuration to load either brand! How funny is that! The Connected apps only have their own respective brands.
I'll close this then, it seems to be resolved.

@hufman it seems to me that the latest builds are worse connected to the car. 3 days ago this worked almost always (may be 95%), but now only 50%. Connection occurs if you run AAID.

I suspect something about the change in c9fc6ff, it directly relates to the connection listening, so I'll take a look.

Just posted 3a63718 which might behave better, at least with my 1 test so far!


Set Pin confirmation fills last circle with delay

On Set Pin last entered number in confirmation fills circle with delay

Moreover, the last entered digit is prefilled on next confirmation screen.
For example if I enter 9999999 on the first screen, and on the second confirmation screen I enter 5 - it immediately fills 2 circles (with 9 and 5)


Add missing libevent-dev dependency to Dockerfile

Thanks!

@omar-polo  I think in final stage should be installed libevent (not -dev) too. I don't want to mess up with next pull requests.

That's fine for me, less stuff in the image the better.
However, I was playing with the idea of building a statically-linked executable; I'm not sure what would be the best way to set up the image in that case, though.  Help is greatly appreciated :)


Lab-H: instructions update

Part2: PHP Ldap interface has been updated. Screenshots in instructions need to be update.

fixed


Feature Request: Function to parse only at runtime specified fields

I'm looking for a easy way to parse just the at runtime provided fields. So something like:
parseFields :
    { fieldSeparator : Char }
    -> List String
    -> String
    -> Result Problem (List (List String))

parseFields ',' ["id", "name", "color"] "id,name,color\n1,bike shed,green\n"

If the specified fields are not available it should it result in an error (maybe there should also be a flag wether to allow additional fields in the CSV).
Maybe this is already possible with decodeCsv, but if so I'm not sure how, since into needs a function with a pre defined arity.

Can you say more about what you're trying to do? https://package.elm-lang.org/packages/BrianHicks/elm-csv/latest/Csv-Parser#parse may suit you but I'd like to know more anyway so we can keep you in type-safety land.

I'm building a website where a user can specify which fields a CSV should have, and the validate CSVs against that schema. I.e. the available fields must be specified at runtime.

Ah, I see! When you say a schema, are you talking about the types of data in the columns or only their names? I can't think of a really easy way for you to get this data out of the decoder package, but you could parse it and then look at the first row to get the names.

but you could parse it and then look at the first row to get the names

That's what I'm doing now, but it's a shame that I can't use any of elm-csv's helper functions then. I only get a List (List String) and have to do the rest myself. 😅 A parseFields as described here, would make things quite easier.
I mean, I've already written in now: https://csvcheck.surge.sh
…but maybe for the next poor soul ;-)


Nschweitzer/acix 87/merge a6a7

What does this PR do?

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge

/merge


Misleading return type when using merge_init_into_class

Currently, when merge_init_into_class and show_signature_annotations are enabled, the class signature looks like None is returned when the class is called, which looks strange and misleading:
SomeClass() -> None

The simplest solution seems to be hiding the return type for classes. The ideal solution is to take the return type from __new__.

I didn't even notice that, thanks. I agree that we could simply remove the return type.


Adds ReflectArgumentFlag

Adds ReflectArgumentFlag with ENUM_USE_TO_STRING to force
ReflectArgumentType to use the toString instead of name as the String
representation of an enum.
This addresses #43 in a way that is backwards compatible while retaining
some of the ergonomics of the current ReflectArgumentType for enums.

Thank you for PR.
Because you first mentioned "A new type class is provided that is able to parse the string representations of enums", I thought that we will have new ArgumentType subclass, say, EnumToStringArgumentType, which only takes enums, and performs conversion using enum constant's toString, like so:
ap.addArgument('--foo').type(new EnumToStringArgumentType<Lang>(Lang.class));

and leave current ReflectArgumentType untouched.  This could be simpler a bit?
Also I notice that this could be backward incompatible (well, ABI) if we change method signature from <T> Argument type(Class<T> type) to  <T> Argument type(Class<T> type, ReflectArgumentFlag... flags).  Probably, we will need recompilation in this case.

I did originally have it as a new type, but found it ended up confusing which type class should be used as there would then be a deprecated EnumArgumentType, a default ReflectArgumentType with a nice helper method if you don't need overloaded toStrings, and an EnumToStringArgumentType if you do.
I was playing around with the adapting the ReflectArgumentType and figured I'd submit a PR to get your opinion on it. I'm happy to change it to a new class if you'd prefer. It certainly would make the implementation simpler.
Regarding breaking the ABI - I had originally considered that and kept the <T> Argument type(Class<T> type) overload, but then forgot about that and deleted it. I believe it can safely be re-added.

It seems updated patch set is broken.

Should be fixed now. I think I must have done something odd in the Github client.

Thank you!  Please take a look at my comment, they are just editorial.
After comments are resolved, could you squash commits into one?  Then I'll merge this PR.

Squashed.

Thank you very much!  Merged now.