Async Validation on components

Is there a way to do asynchronous validation on the redux-form-material-ui?
I tried to link it with<EMAIL_ADDRESS>but it seems that the async function does not return the error to the components in redux-form-material-ui.
const asyncValidate = (values, dispatch) => {
  var emailValid = 0;
  return sleep(1000) // simulate server latency
    .then(() => {
      request.post(apiUrl + '/checkemail')
      .send(querystring.stringify({
        email: values.email,
      }))
      .end(function(err, result) {
        // const json = result.body;
        if (!err) {
          // console.log(props);
          var resValid = JSON.parse(JSON.parse(result.text).text).result;
          // It returns 1 if the email is found
          emailValid = resValid;
        }
      });
      setTimeout(() => {
        console.log(emailValid);
        if (emailValid === 1) {
          throw { email: 'Email is already taken !!!' };
        } else if (emailValid === 0) {
          dispatch(postRegister(values));
          resolve();
        }
      }, 500);
    })
}

It just returns as an invalid Object, and is not read by redux-form as an Error object.
Can anyone help me with this? Is there a better way to do this in conjuction with using redux-form-material-ui?

Here's a working demo.
https://codesandbox.io/s/0RWElKV5G

I've solved my own problem.
And I would like to share it here. The problem what I've experienced is, if you are validating through API (using like: Request, SuperAgent, and axios), you cannot put it inside the sleep Promise like in the example. The example does not show how to use a request HTTP client to access API. Before, I was using request and superagent to pass the error data to the asyncValidation. I realized that those do not support Promise (at least not out of the box like axios). So, I tried to use axios, and it looks like this...
`import axios from 'axios';
import request from 'superagent';
import querystring from 'querystring';
import path from 'path';
import srequest from 'sync-request';
import { postRegister } from '../actions/index';
const apiUrl = apiconfig.api_url_reducer;
const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));
const asyncValidate = (values , dispatch) => {
var error = {};
axios.post(apiUrl+'/checkemail', querystring.stringify({ email: values.email }))
.then(function(response) {
var resvalid = JSON.parse(response.data.text).result;
if(resvalid === 1) {
error.email = 'Email has been used...';
}
});
return sleep(500).then(() => {
if(error.email) {
console.log(error);
throw error;
}
});
};
export default asyncValidate;`
In my code, I've put the axios code outside the sleep Promise. Becuase it will not return a valid Promise if I put it inside.
Please provide examples for using API call for future references. Thank you.


Bug when trying to search for mongoose.Schema.Types.Long field

I am using adminbro with Express and mongoose tools. I have one filed with type mongoose.Schema.Types.Long (https://www.npmjs.com/package/mongoose-long). When somebody tries to search for this field there is an error
Error: Can't use $options with Long.
is there any way to search for Long field? Thanks.

I don't think so :( - I am looking at the code right now and we use this $options:
{
   autopopulate: false, skip: offset, limit, sort: sortingParam,
}

so it seems that this library doesn't allow you to sort or paginate, which is the basic requirement of AdminBro.
Since this won't be fixed, and I don't think we can find a workaround - I am closing this issue


Update from sourceview3 to sourceview4

The latter is still GTK3 based

It exists here already but we should maybe include it here instead of the deprecated sourceview3?
https://crates.io/crates/sourceview4
@BrainBlasted ?

Version 4 of the upstream Gnome library is still based on GTK3 (source):

GtkSourceView 4.x is also for GTK 3 (but with all the deprecated API removed).

I would be fine with that, @sdroege

I guess this mostly depends then on whether someone wants to actually maintain it as part of the gtk-rs organization :)

I'm open to +/- maintain it, does it matter to move it from /World/Rust to gtk-rs?

I'm fine with it.

We could also keep maintaining it as is on the gnome gitlab and instead update the sourceview crate on crater, unless there's something in gtk-rs that depends on it.

I guess we can close this, I have updated sourceview4 to the latest release few months ago.


added bucket sort in javascript

Assigned Issue Number ?
#007
Language Opted ?
C/C++/Python/Java/...
Number of files added or updated ?
1/2/3/4/...
Name of these files ?
main folder => sub_folder => ... => ... => ... file.py
example :
Algorithm => Search_Algorithm => Linear_Search => Linear_Search.py
Checklist

[x] I've read the contribution guidelines.
[ x] I've referred the correct issue number.
[ x] I've fill up this entire template correctly.

BucketSort.js already exist :warning:
Can't merge :no_good:


Integration tests (sbt scripted) fail for the current master branch (0.2.0)

Here is the abridged output of sbt scripted, I suspect that the failing test have to do with the output tagged as [error]:
[error] [pool-11-thread-5] WARN de.zalando.swagger.ValidationsConverter$ - Ignoring nonsense validations for date: maxLength(10), minLength(0), pattern("""/[1-9][A-Z0-9]*/""".r)
[error] [pool-11-thread-5] WARN de.zalando.swagger.ValidationsConverter$ - Ignoring nonsense validations for date-time: maxLength(10), minLength(1), pattern("""/[1-9][A-Z0-9]*/""".r)
[error] [pool-11-thread-5] WARN de.zalando.swagger.ValidationsConverter$ - Ignoring nonsense validations for date-time: maxLength(10), minLength(0), pattern("""/[1-9][A-Z0-9]*/""".r)
[error] [pool-11-thread-5] WARN de.zalando.swagger.ValidationsConverter$ - Ignoring nonsense validations for date: maxLength(10), minLength(0), pattern("""/[1-9][A-Z0-9]*/""".r)
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path(), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint GET /pets/{id} , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path("schema" / "model"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path("schema" / "model"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path("schema" / "model"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint GET /pets/findByTags , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint PUT /pets , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint POST /pets , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint GET /pets/{petId} , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint POST /pets/{petId} , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint DELETE /pets/{petId} , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint GET /pets/findByStatus , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("stores" / "order"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users" / "createWithList"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call PUT Path("users" / "{username}"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users" / "createWithArray"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("stores" / "order"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users" / "createWithList"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call PUT Path("users" / "{username}"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users" / "createWithArray"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("string"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("string2"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("string"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("string2"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path(), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path(), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path("test-path" / "{id}"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint GET /pets/findByTags , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint PUT /pets , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint POST /pets , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint GET /pets/{petId} , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint POST /pets/{petId} , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint DELETE /pets/{petId} , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] INFO de.zalando.apifirst.generators.ScalaPlayCallEnricher - Not generating tests for secure API endpoint GET /pets/findByStatus , this issue will be addressed in future versions of the plugin
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("stores" / "order"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users" / "createWithList"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call PUT Path("users" / "{username}"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users" / "createWithArray"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("stores" / "order"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users" / "createWithList"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call PUT Path("users" / "{username}"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path("users" / "createWithArray"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path("schema" / "model"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path("schema" / "model"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path("schema" / "model"), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call GET Path(), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path(), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path(), defaulting to MimeType("application/json")
[error] [pool-11-thread-3] WARN de.zalando.apifirst.generators.ScalaPlaySpecEnricher - No mime-types is defined for call POST Path(), defaulting to MimeType("application/json")
...
[info] [error] Failed: Total 98, Failed 59, Errors 0, Passed 39
[info] [error] Failed tests:
[info] [error] 	numbers_validation.yaml.Numbers_validationYamlSpec
[info] [error] 	heroku.petstore.api.yaml.HerokuPetstoreApiYamlSpec
[info] [error] 	nakadi.yaml.NakadiYamlSpec
[info] [error] 	cross_spec_references.yaml.Cross_spec_referencesYamlSpec
[info] [error] 	full.petstore.api.yaml.FullPetstoreApiYamlSpec
[info] [error] 	echo.EchoApiYamlSpec
[info] [error] 	form_data.yaml.Form_dataYamlSpec
[info] [error] 	error_in_array.yaml.Error_in_arrayYamlSpec
[info] [error] 	admin.SimplePetstoreApiYamlSpec
[info] [error] 	hackweek.yaml.HackweekYamlSpec
[info] [error] 	split.petstore.api.yaml.SplitPetstoreApiYamlSpec
[info] [error] 	string_formats_validation.yaml.String_formats_validationYamlSpec
[info] [error] 	uber.api.yaml.UberApiYamlSpec
[info] [error] (test:test) sbt.TestsFailedException: Tests unsuccessful
[info] [error] Total time: 57 s, completed Dec 19, 2016 12:00:06 PM
[info] + swagger / compile
[success] Total time: 333 s, completed Dec 19, 2016 12:00:07 PM

@zyv Hey, thank you for the issue.
The failing tests are by design. The idea is that at the moment you provide a specification, the tests and controller skeletons are generated. But at this moment the tests should fail because there is no implementation in controllers yet. That's exactly what we want to see in our scripted tests - after initial artefacts were generated, the tests are red.
Does it make sense?

Hi Slava,
Thank you for the explanation! I can roughly follow what you are saying, but I would argue that it's very confusing to see lots of failures as a result of running scripted tests, so maybe the output could be somehow rearranged to make it more clear what's going on & what's expected and/or document this. However, I can't propose a better solution, because I'm not knowledgeable enough about your code; so feel free to close this issue...
--Yury.

@zyv Hey, thanks for your feedback. One idea could be instead of returning "Not implemented" from freshly generated controllers to return some random generated data. This would make tests pass, but the downside is that the developer cannot distinguish anymore between tests passing because of the proper implementation or just because of this random data returned from the API.
Leaving this issue open to investigate the possibilities further.

Yes, returning random data doesn't sound like a great option at all... Moreover, there is always a chance that the tests will accidentally pass.
I would have actually expected that expected failures are interpreted as success and unexpected successes as failures in the integration tests context, only as I said I have no constructive suggestions on how to implement that.

That's exactly what is happening during the scripted test, I guess log entry prefix [info] [error] should give a hint that this is a nested test configuration in which outer test expects inner test to fail.


Revert to setup

closes #471
pyproject.toml + flit broke the namespace package (replacing titiler.core by titiler_core)

Note: I found a way to make it work using setuptools
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

[tool.setuptools.dynamic]
version = {attr = "titiler.core.__version__"}

[tool.setuptools]
include-package-data = true

But right now setuptool support of pyproject.toml is marked as experimental. we might re-try pyproject + build system later!


Error in extension onActivate stops app from booting properly

Describe the bug
An exception within extension onActivate can cause app to not load properly. User will see just splash screen forever.

@jakolehm Any extension or a bundled extension?

@Nokel81 it happened with a non-bundled extension so I would assume any extension.

Okay thanks, will investigate

@jakolehm I cannot reproduce this on master.
My extension code is:
renderer.ts:
import { Renderer } from "@k8slens/extensions";

export default class RendererExtension extends Renderer.LensExtension {
  protected onActivate(): void {
    throw new Error("this is an error");
  }
}

main.ts:
import { Main } from "@k8slens/extensions";

export default class MainExtension extends Main.LensExtension {
  onActivate(): void {
    throw new Error("an error");
  }
}

And if it the extension is enabled then I do eventually see the main window.

@Nokel81 ok, I'll verify this again with latest master.

Cannot reproduce this with current master.


Allow disabling default linters with linter.removeLinter

Description of the problem or steps to reproduce
I was trying to replace the gcc linting for clang with custom flags by customizing the linter through a custom plugin (mostly to see how it works).
I first tried to use the linter.removeLinter function (that isn't documented in the readme but is in the source code) and it didn't disabled the gcc linting. For disabling the gcc linter one has to do something like linter.makeLinter("gcc", "", "", {}, "")
Weirdly, calling linter.removeLinter("gcc") after that line seems to remove the custom gcc linter settings and replace it with the default one. It seems the linters table in the linter plugin is being initialized after the user's custom plugin?
Specifications

Commit hash: 74523d2
OS: Linux (Fedora 31)
Terminal: gnome-terminal, zsh

I think this is because the order in which plugins are initialized is currently arbitrary, so the linter is initialized after your plugin. It would probably be a good idea to have support for controlling the order plugins are initialized in. In the meantime, you can modify the linter in onBufPaneOpen which will happen after plugins are initialized.


How does the "field" meta query work?

I apologize if I am missing something obvious, but I cannot get the "field" query parameter to work. In my case I have a user record type with a name and an age, and I want to show the name only. I have tried writing the query string in all kinds of formats, including "?field[name]" and "?fields[name]", but nothing happens and the meta object just says "µ:meta":{ ... "field":{} }".
I'd be grateful if you could give me an example on how to use the "fields" parameter correctly!
I happened upon another issue while trying to find the correct format for the query string. The following URL gave an unexpected result:
/users?limit=1&sort=-age&fields[age]
When making a GET request to the above URL, the meta object returned this "µ:meta":{ ... "field":{}, "sort":{"age&fields[age]":false} }".

I figured it out the correct format: "fields[user]=name". When using this format, the above issue does not apply. The only thing is that the meta "field" definition is always empty, showing just "µ:meta":{ ... "field":{} }". Perhaps this is due to the query parameter being called "fields", but the meta parameter is called "field"? It's just a wild guess though.

It's definitely a bug that the meta field object is empty, will investigate.

Fixed in commit https://github.com/fortunejs/fortune-micro-api/commit/fdac50624baf142f0d09b35874432c7446f39b13.


Merge branch 'develop' into feature/ping-pong

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines
[x] Tests for the changes have been added/updated (for bugfix/feature)
[ ] Docs have been added/updated (for bugfix/feature)

PR Type
What kind of change does this PR introduce?

[x] Feature (a new feature)
[ ] Bugfix (a bug fix)
[ ] Style (changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc))
[x] Refactor (a code change that neither fixes a bug nor adds a feature)
[ ] Perf (a code change that improves performance)
[x] Test (adding missing tests or correcting existing tests)
[ ] Build (changes that affect the build system, CI configuration or external dependencies)
[ ] Docs (changes that affect the documentation)
[ ] Chore (anything else), please describe:

What is the current behavior?

What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information
Closes #421

Todo:

[ ] Add more coverage for DiscordMessageDmService
[ ] Respond to pong on a channel


Grouped updates: Dependabot encountered an unknown error

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
yarn
Package manager version
No response
Language version
No response
Manifest location and content before the Dependabot update
No response
dependabot.yml content
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "tuesday"
      timezone: "Asia/Tbilisi"
      time: "17:00"
    commit-message:
      # Use our PR title naming convention
      prefix: "UPGRADE - "
    groups:
      # Dependabot grouped updates:
      # Docs at https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#groups
      # This is the name of your group, it will be used in PR titles and branch
      # names
      low-risk:
        patterns:
          - "core-js"
          - "nuxt-edge"
          - "@nuxt/*"
          - "postcss*"
          - "autoprefixer"
          - "@vue*"
          - "*jsdom*"
          - "*babel*"
          - "path-parse"
          - "^vue$"
          - "lodash"
          - "*typescript*"
          - "msw"
          - "chromatic"
          - "*storybook*"
          - "*faker*"
          - "*jest*"
          - "*chai*"
          - "*cypress*"
          - "*lint*"
          - "*prettier*"
          - "json5"
          - "husky"
          - "office-addin*"
            # matching all packages that start with "@types"
          - "@types*"
      high-risk:
        patterns:
          - "ahoy.js"
          - "@nylas/components-mailbox"
          - "vue-infinite-loading"
          - "vue-clamp"
          - "floating-vue"
          - "portal-vue"
          - "line-awesome"
          - "graphql*"
          - "@rails/actioncable"
          - "*apollo*"
          - "@nuxtjs/*"
          - "tailwindcss"
          - "@tailwindcss/forms"
          - "*sentry*"
        exclude-patterns:
          - "@nuxtjs/storybook"

Updated dependency
No response
What you expected to see, versus what you actually saw
Dependabot failed to update your dependencies because an unexpected error occurred. See the logs for more details.

updater | ➤ YN0007: │ recital-frontend@workspace:. must be built because it never has been before or the last one failed
updater | ➤ YN0009: │ recital-frontend@workspace:. couldn't be built successfully (exit code 1, logs can be found here: /tmp/xfs-3833ad4b/build.log)
updater | ➤ YN0000: └ Completed in 43s 252ms
updater | ➤ YN0000: Failed with errors in 48s 193ms
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/helpers.rb:121:in `run_yarn_command'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb:159:in `run_yarn_berry_top_level_updater'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb:110:in `block (2 levels) in run_yarn_updater'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb:107:in `chdir'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb:107:in `block in run_yarn_updater'
updater | 	from /home/dependabot/common/lib/dependabot/shared_helpers.rb:187:in `with_git_configured'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb:106:in `run_yarn_updater'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb:79:in `run_current_yarn_update'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb:60:in `block in updated_yarn_lock'
updater | 	from /home/dependabot/common/lib/dependabot/workspace/base.rb:26:in `block in change'
updater | 	from /home/dependabot/common/lib/dependabot/workspace/base.rb:26:in `chdir'
updater | 	from /home/dependabot/common/lib/dependabot/workspace/base.rb:26:in `change'
updater | 	from /home/dependabot/common/lib/dependabot/shared_helpers.rb:33:in `in_a_temporary_repo_directory'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb:56:in `updated_yarn_lock'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb:32:in `updated_yarn_lock_content'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater.rb:240:in `updated_yarn_lock_content'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater.rb:171:in `yarn_lock_changed?'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater.rb:199:in `block in updated_lockfiles'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater.rb:198:in `each'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater.rb:198:in `updated_lockfiles'
updater | 	from /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater.rb:43:in `updated_dependency_files'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/dependency_change_builder.rb:86:in `generate_dependency_files'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/dependency_change_builder.rb:36:in `run'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/dependency_change_builder.rb:25:in `create_from'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/group_update_creation.rb:87:in `create_change_for'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/group_update_creation.rb:48:in `block in compile_all_dependency_changes_for'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/group_update_creation.rb:28:in `each'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/group_update_creation.rb:28:in `compile_all_dependency_changes_for'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/create_group_update_pull_request.rb:41:in `perform'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:97:in `run_update_for'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:82:in `block in run_grouped_dependency_updates'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:73:in `each'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:73:in `run_grouped_dependency_updates'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:41:in `perform'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:62:in `run'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/update_files_command.rb:38:in `perform_job'
updater | 	from /home/dependabot/dependabot-updater/lib/dependabot/base_command.rb:52:in `run'
updater | 	from bin/update_files.rb:23:in `<main>'
updater | time="2023-07-11T14:15:51Z" level=info msg="task complete" container_id=job-692272807-updater exit_code=1 job_id=692272807 step=updater
updater | time="2023-07-11T14:15:53Z" level=warning msg="updater container failed" error="waiting for updater: bad response from container: 1" exit_code=1 job_id=692272807

Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
https://github.com/recitalsoftware/recital-frontend/network/updates/692272807
Smallest manifest that reproduces the issue
No response

It seems to be failing on this yarn up command: https://github.com/dependabot/dependabot-core/blob/f0ecb5e891ade37c813be8ca0b21e63af9afd639/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/yarn_lockfile_updater.rb#L159-L162
I looked up the full logs of job 692272807 and it also includes:
failed to allocate memory (NoMemoryError)
Perhaps Dependabot is running into a bug in Yarn that's consuming all the memory while resolving the dependency graph?

@bmulholland are you still having this problem?
I noticed there's quite a few out-of-memory reports in the Yarn classic repo: https://github.com/yarnpkg/yarn/issues?q=is%3Aissue+is%3Aopen+memory

We're using Yarn Berry, not Classic.
Looks like dependabot stopped trying: "Dependabot updates have stopped for your repository due to repeated errors."
I've triggered a manual update and will update when that's done.

Yes, it's still happening

We're using Yarn Berry, not Classic.

Oops, right you are!

Yes, it's still happening

There's clearly two errors: one is the dependency resolution failure and the other an out of memory error during a different dependency resolution.
You might be able to recreate the resolution error outside of Dependabot by manually updating package.json to bump the dependency, and then run yarn up -R <dependency> --mode=update-lockfile. You can see the first dependency it fails on in the new log is at 2023/10/02 16:38:34.
As for the out of memory error I can check to see if we can get that repo on a private beta where Dependabot runs on Actions. That will give the update more memory to work with.

Thanks Jake. I'm not sure which packages are causing issues; I don't see a specific one called out in the dependabot logs. I did try a local y up -R "**", and that does seem to use upwards of 800MB of memory (wwhhhatttt???). No resolution errors though, just assorted false-positive warnings.

Hi @bmulholland ; sorry about the challenges with grouped updates - I understand it can be challenging.
Would you be willing to join the private beta of Dependabot on actions? We can do an internal check to see if it resolves the memory requirements.

@bmulholland: Can you share your repo name. There is an way to increase the instance size so that Dependabot jobs does not runs out of memory, if that does not fixes it then we move to Dependabot on actions (if you willing to join).

@bmulholland : My apologies, your previous message was missed. Your repo (recitalsoftware/recital-frontend) is now onboarded on Dependabot on actions (private beta).
Couple of things:

The repo should have actions enabled. If not then enable Actions.
Any Dependabot version and security jobs running on Actions will not get charged. It is FREE!

Thank you! Sounds good, will confirm on Tuesday when our weekly upgrade runs

Okay so the upgrades before were taking close to 40 minutes when they worked, or they'd take longer than 45 and time out. That's why they were flaky for me, I think. The new job, with github actions, took 15 minutes -- 3x faster, and nowhere close to a place where they'd time out. That's much better! Love it, thank you :)


Failure to compile on CentOS 7: undefined packer.ConfigTemplate

Steps to get me here:

fresh vagrant box running cent7

install go v1.4

get packer to build (0.8.6)

Find and fix problem with ssh (builder/softlayer/ssh.go builder/softlayer/step_create_ssh_key.go both refer to "code.google.com/p/go.crypto/ssh".  The 'right' version appears to be "golang.org/x/crypto/ssh")

clone this repo

run this command:
$ go build -o $GOPATH/bin main.go
github.com/leonidlm/packer-builder-softlayer/builder/softlayer
builder/softlayer/builder.go:45: undefined: packer.ConfigTemplate
$ echo $?
2

Close me.  This is a duplicate of #17
Chased the pull requests and found something that compiles.

Fixed with aaee0561423ff696e3f516895a9ef671b6d2afd6


Report invalid, nested, multi-segment crate-paths

There was a bug in the previous path-validating code that didn't detect multi-segment paths that started with crate.
// Successfully reported
use foo::{crate};

// BUG: was not being reported
use foo::{crate::bar};

This was due to my confusion about path-associativity. That is, the path with no qualifier is the innermost path, not the outermost. I've updated the code with a lot of comments to explain what's going on.
This bug was discovered when I found an erroneous ok test which I reported here:
https://github.com/rust-analyzer/rust-analyzer/issues/4226
This test now fails and has been modified, hopefully in the spirit of the original test, to be correct.  Sorry about submitting the bug in the first place!

bors r+


Support Redis Cluster for BullMQ

Hi,
We have upgraded the BullMQ in our project recently, and switched to redis cluster. With redis cluster, we get more scalability of our project. As bull-monitor is an important tool for us, it would be very helpful when bull-monitor  also support redis cluster for BullMQ.
Here is how it works by BullMQ: Redis cluster
We forked this project and get it running with cluster mode. Basically the change is very easy, nothing need to be changed besides adding some lines into the  fixtures/bull-server/server/index.ts file
the connection is a redis cluster, we use ioredis here:
const bullconnection = new redis.Cluster(bullConf, {   redisOptions: {     username: redis_user_bull,     password: process.env.REDIS_PW_BULL,     tls: env !== 'local' && env !== 'dev' ? {} : undefined,   },   dnsLookup: (address: string, callback: (e: any, a: string) => void) =>     callback(null, address),   scaleReads: 'slave',   enableAutoPipelining: false, //what is this for??   enableOfflineQueue: true,   enableReadyCheck: true,   slotsRefreshTimeout: 500000, });
By queue definition, not only the queue name but also the prefixes of the queue is needed:
for (let i = 0; i < queues.length; i++) {   mqQueues.push(     new BullMqQueue(queues[i], {       prefix: prefixes[i],       connection: bullconnection,     })   );   queue_prefix_lut.push({     queue: queues[i],     prefix: prefixes[i],   }); }
To each worker, the prefix also need to be added:
mqQueues.forEach((queue) => {   const queuePrefix = queue_prefix_lut.find((i) => i.queue === queue.name);   new MqWorker(     queue.name,     async (job) => {       return some return value from ${job.name};     },     {       prefix: queuePrefix && queuePrefix.prefix,       connection: bullconnection,     }   ); });
Redis cluster is a very useful feature of BullMQ, hope you are also interested in it and add it as a feature in bull-monitor.
here is our fork repo

@xueya-long I don't quite understand what's going on here. If you want to use  a cluster - just do it, it has nothing to do with bull-monitor.
Also this  fixture thing that you linked is made only for development purposes.

Hi @s-r-x ,
bull-monitor is connected with a redis client per REDIS_URI, and this redis client is only for BullMQ caches. The connection for redis client and redis cluster is different. Redis cluster allows us save all caches of the project with big scalability feature. When we chenge the REDIS_URI to cluster uri, bull-monitor cannot connect to the cluster, the connection inside bull-monitor need to be changed. And for redis cluster mode, BullMQ need a hash tag (prefix) for each Queue and Worker.  It is more like a topic for a redis cluster connection for bull-monitor :)


Inconsistent icon-font vertical alignment

'FontAwesome' and 'devicons' icon fonts seem to have large discrepancies in vertical alignment.

Same as #144


check file error

header.php: add file error check

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Looks good to me. Thanks for the fix!


Include libvirt platform as part of the PRs tests

Why is this PR needed?
This PR is needed to start using libvirt platform to tests skuba PRs in addition to the current VMWare tests.
Part of SUSE/avant-garde#1227
What does this PR do?
This commit sets to test skuba PRs using testrunner for libvirt and
vmware platforms. Moreover it cleans up some of the previous old and
unused VMWare job settings.
Anything else a reviewer needs to know?
Info for QA
None, it is CI PR.
Related info
Info that can be relevant for QA:

link to other PRs that should be merged together
link to packages that should be released together
upstream issues

Status BEFORE applying the patch
How can we reproduce the issue? How can we see this issue? Please provide the steps and the prove
this issue is not fixed.
Status AFTER applying the patch
How can we validate this issue is fixed? Please provide the steps and the prove this issue is fixed.
Docs
If docs need to be updated, please add a link to a PR to https://github.com/SUSE/doc-caasp.
At the time of creating the issue, this PR can be work in progress (set its title to [WIP]),
but the documentation needs to be finalized before the PR can be merged.
Merge restrictions
(Please do not edit this)
We are in v4-maintenance phase, so we will restrict what can be merged to prevent unexpected surprises:
What can be merged (merge criteria):
    2 approvals:
        1 developer: code is fine
        1 QA: QA is fine
    there is a PR for updating documentation (or a statement that this is not needed)

Note that we should have a follow up card for improving this configuration. At least for the two areas:

Use an updated terraform-provider-libvirt that solves network restrictions
Use a generic name for the server, not node52

@pablochacin @Itxaka
My plan regarding this PR is doing to following on Monday:

Unless something there isn't something terrible merge it on Monday
It is possible that it will not work, however it will not break any current stuff, as it is a new job
Run a follow up PR in which we will be able to actually modify and update and validate the code within the PR itself as the job will already be there and running.

This way we can verify and test the final setup within the PR process.

My plan regarding this PR is doing to following on Monday:

Unless something there isn't something terrible merge it on Monday
Play de waka mole game on the new job :P
It is possible that this new job doesn't work, however it will not break any current stuff, as it is a new job
Run a follow up PR in which we will be able to actually modify and update and validate the code within the PR itself as the job will already be there and running.

This way we can verify and test the final setup within the PR process.

@davidcassany if you only want to test this pipeline, what you could do is to change the pr-test job to use this pipeline. That way this PR will test it but no other PR will be affected, this until we can test this works.

@davidcassany if you only want to test this pipeline, what you could do is to change the pr-test job to use this pipeline. That way this PR will test it but no other PR will be affected, this until we can test this works.

Good point this is another option I did not consider. The only problem is that once validated I will have to revert it from pr-test and you'll have to trust me it works :)

Good point this is another option I did not consider. The only problem is that once validated I will have to revert it from pr-test and you'll have to trust me it works :)

We trust you, bro!
But what I suggest is for you to test. I think we are not sure the jenkins credentials will work, for example. One you have tested, you can revert this change and submit the final version like this one.


Extract data utils & refactor demo

This is a step towards decoupling data loaders from the actual renderer. The ZarrLoader class is more general than the TiffPyramidLoader and allows for controlling which channels to return as well and handling n-dim data. Both loaders implement .getTile({x, y, z}) which is used to fetch the data in the renderer.
I refactored the demo to accomedate these changes and used hooks to update components. I would appreciate feedback on this!

Ideally, I'd like to move initializing the Pool for the tiff loader outside of the renderer as well. I don't think viv should be aware of anything in regard to how data are fetched.
I couldn't think of a clear solution for this so a usePool flag is returned by each loader. Ideally the end user would instantiate the pool and optionally pass this as a param to initPyramidLoader.

Can you checkout this branch and try the demo? Everything seems to be working, but TIFF seems pretty slower on my machine. I'm wondering if it has something to do with moving Pool out of state and into the createTiffPyramid function. I would wait to merge until this can be resolved.

@manzt Now that everything is merged and so forth, would you be able to write to tests against the Zarr util?  I don't think it's worth out time to do it for TIFF given how volatile that is but now that Zarr is stabilizing, I think we should.  Also note that you'll need to update your environment as a bunch of packages have been updated/added.

@ilan-gold I added a few tests for some of our zarr current use cases. I also installed a new dev-dep, tap-dot, to print the tap output nicely in the terminal. There are several reporters that do the same thing so feel free to reconfigure if you wish to.
One thing to note, running these tests are super slow on my machine. It seems like an electron app is spun up? Also there is no way to run test:watch would be super useful for implementing new functionality and refactoring.

tape-run has other options for other headless browsers, but electron was the default.  I didn't look too deeply into it once I got it working since I didn't mind the time it took to run.  I spent quite a bit of time getting the tests to run properly independently of this.  If you want to file an issue/fix it here, faster tests are always better.


Support Android Targets

close #260
Signed-off-by: leleliu008<EMAIL_ADDRESS>

Thank you for your PR! We merged Android platform support in #274.


Incorrect free VRAM reporting when two CUDA cards with different VRAM capacities are installed, preventing Ollama from using GPU inference

What is the issue?
Dear ollama developer:
First of all, thank you very much for developing and maintaining ollama. Open source leads the world to a brighter future!
I use the gemma2:27b model, my problem is:

When my device only has a Tesla P40 (with 24G VRAM) installed, ollama can automatically use GPU inference and run very well.
When I also install a Quadro K620 (with 2G VRAM) for display output, ollama cannot use P40 and is forced to use CPU inference.

The nvidia-smi output is:

The server.log is
server-2.log
I set the evironment variable "CUDA_VISIBLE_DEVICES" to the uuid of my P40, and the log time=2024-07-31T04:44:20.388+08:00 level=INFO source=types.go:105 msg="inference compute" id=GPU-085790c7-bee0-4de1-db17-6685d68470ca library=cuda compute=6.1 driver=12.4 name="Tesla P40" total="23.9 GiB" available="23.7 GiB" seems to tell that ollama has found the P40 card. However, the next log time=2024-07-31T04:44:37.793+08:00 level=INFO source=memory.go:309 msg="offload to cuda" layers.requested=-1 layers.model=47 layers.offload=0 layers.split="" memory.available="[1.6 GiB]" memory.required.full="15.3 GiB" memory.required.partial="0 B" memory.required.kv="736.0 MiB" memory.required.allocations="[0 B]" memory.weights.total="14.4 GiB" memory.weights.repeating="13.5 GiB" memory.weights.nonrepeating="922.9 MiB" memory.graph.full="509.0 MiB" memory.graph.partial="1.4 GiB" seems to tell that available VRAM was just 1.6GB which was exactly the free VRAM of my K620, and then ollama used cpu_avx2 to run the inference.
I guess here Ollama ignored the CUDA_VISIBLE_DEVICES environment variable I set, and detected the free VRAM of K620 instead of P40, and automatically used CPU reasoning after finding that gemma2:27b could not be run with only 1.5GB of VRAM.
I don't know Golang, so I wonder if this is a bug in ollama's judgment of free VRAM. I hope you can check this problem, thanks!
OS
Windows
GPU
Nvidia
CPU
Intel
Ollama version
0.3.0

This sounds like it's a variation of #5239
Could you try running the server with OLLAMA_DEBUG=1 set?  The CUDA_VISIBLE_DEVICES should have caused it to ignore the smaller GPU as a workaround, but clearly there's another bug in there somewhere.

Thanks for your reply!
I've set OLLAMA_DEBUG=1 and here is the server log:
server.log
I noticed this log time=2024-07-31T12:02:33.626+08:00 level=DEBUG source=gpu.go:406 msg="updating cuda memory data" gpu=GPU-085790c7-bee0-4de1-db17-6685d68470ca name="Tesla P40" overhead="0 B" before.total="23.9 GiB" before.free="23.7 GiB" now.total="2.0 GiB" now.free="1.4 GiB" now.used="617.1 MiB"
First, Ollama detected the P40 correctly, but in this "updating cuda memory data" step, it re-detected the the VRAM of P40 as 2GB (actually the VRAM of K620). I think this may be the problem.

Hi @XJTU-WXY, I think I might have found a possible solution to your issue. Have you tried relocating your K620 to a different PCIe slot and moving the P40 to the top slot (primary slot) on your motherboard? This might allow Ollama to correctly detect the free VRAM of the P40 and use it for GPU inference. Let me know if this works for you!

Hello! During this period of time, I did some tests and tried to read the relevant code of ollama, and then I found some problems.
First of all, I have found a way to make ollama correctly detect the VRAM of CUDA cards on my device: set the numbers of both cards in the CUDA_VISIBLE_DEVICES environment variable and reverse their order (CUDA_VISIBLE_DEVICES=1,0)
The reason for doing this is:
When I set CUDA_VISIBLE_DEVICES to only the P40 card, the VRAM detection will be incorrect as mentioned before. So I tried not setting CUDA_VISIBLE_DEVICES (Equivalent to CUDA_VISIBLE_DEVICES=0,1), but ollama still couldn't use GPU inference. The log was like this: server.log
I noticed these logs:
time=2024-08-02T08:33:01.218+08:00 level=INFO source=types.go:105 msg="inference compute" id=GPU-085790c7-bee0-4de1-db17-6685d68470ca library=cuda compute=6.1 driver=12.4 name="Tesla P40" total="23.9 GiB" available="23.7 GiB"
time=2024-08-02T08:33:01.218+08:00 level=INFO source=types.go:105 msg="inference compute" id=GPU-481cc3a7-596a-18f2-bdfe-3e2eab3612ba library=cuda compute=5.0 driver=12.4 name="Quadro K620" total="2.0 GiB" available="1.6 GiB"
They were printed by
https://github.com/ollama/ollama/blob/ce1fb4447efc9958dcf279f7eb2ae6941bec1220/gpu/types.go#L102-L115
Then I noticed these logs:
time=2024-08-02T08:33:30.963+08:00 level=DEBUG source=gpu.go:406 msg="updating cuda memory data" gpu=GPU-085790c7-bee0-4de1-db17-6685d68470ca name="Tesla P40" overhead="0 B" before.total="23.9 GiB" before.free="23.7 GiB" now.total="2.0 GiB" now.free="1.1 GiB" now.used="881.9 MiB"
time=2024-08-02T08:33:30.978+08:00 level=DEBUG source=gpu.go:406 msg="updating cuda memory data" gpu=GPU-481cc3a7-596a-18f2-bdfe-3e2eab3612ba name="Quadro K620" overhead="22.3 GiB" before.total="2.0 GiB" before.free="1.6 GiB" now.total="24.0 GiB" now.free="1.6 GiB" now.used="110.4 MiB"
They were printed by
https://github.com/ollama/ollama/blob/ce1fb4447efc9958dcf279f7eb2ae6941bec1220/gpu/gpu.go#L380-L423
As we can see, the order of CUDA cards is reversed compared to the actual, but the "updating cuda memory data" step detected VRAM in the actual order. This might be the reason why the VRAM detection of the two cards is incorrect. When I reverse the order of numbers of the two cards in CUDA_VISIBLE_DEVICES, ollama can finally use GPU inference. The log was like this:
server-1.log. The order in "inference compute" is correct, and therefore the VRAM detection is correct.
I know nothing about Golang and CUDA libraries, so I have no idea why the code blocks above get reversed order of cards.
@ahjavid Thanks for your suggestion, but the layout of the PCIE slot in my motherboard does not allow me to change the position of the two cards, I can't verify whether the method you mentioned can solve the problem. Sorry.

Is this still seen on the latest releases?  If so, could you share an updated server log with OLLAMA_DEBUG=1 set?


Review

Please review, @Marcel73125

Review from Moser Marcel (Marcel 73125)
Description of repository
This repository of jakobsvolba provides two functions and contains an approved open-source license.
The first function calculates the capacity factor of a powerplant based on the yearly energy yield in kWh as well as the nominal power of the power plant in kW and returns the capacity factor in percent.
The second function calculates the full load hours of a powerplant based on the yearly energy yield in kWh as well as the nominal power of the power plant in kW and returns the full load hours (in hours).
Automated tests are ran to verify the correct behavior of the functions after each commit.
A .gitignore file is also included to decrease the requirement for manually ignoring each file of a certain type.
A linter (ruff) to automatically format changed files after each commit is implemented.
The linter (ruff) fails as expected.
Pytest fails as expected.
Tests
-[x] License exists
-[x] Create a fork and start a pull request
-[x] Pytest fails as expected
-[x] Ruff linter fails as expected

Submission of second homework assignment, @danielhuppmann.


Reference HAProxy Ingress' latest branch

What type of PR is this?

/kind documentation
What this PR does / why we need it:
This PR changes HAProxy Ingress' external link to the latest branch - v0.13, which is the first controller version that implements Gateway API and was already graduated to GA.
Which issue(s) this PR fixes:

Does this PR introduce a user-facing change?:

NONE

/ok-to-test
/lgtm

/lgtm

/approve


Protocol path extensions should verify correct number of parameters

If number of parameters of extended path does not match protocol path declaration, an error should be thrown

+1

Implemented for 0.9.2


feat(edge-compute): add specific edge endpoint checkin interval

fix #3843

020/05/26 04:46:06 [DEBUG] [internal,edge,poll] [status: IDLE] [port: 0] [schedule_count: 0] [checkin_interval_seconds: 300.000000]
2020/05/26 04:47:01 [DEBUG] [internal,edge,docker] [message: Docker runtime configuration check] [engine_status: %!s(agent.EngineStatus=1)] [leader_node: false]
2020/05/26 04:47:01 [DEBUG] [internal,edge,poll] [status: IDLE] [port: 0] [schedule_count: 0] [checkin_interval_seconds: 300.000000]
2020/05/26 04:48:01 [DEBUG] [internal,edge,docker] [message: Docker runtime configuration check] [engine_status: %!s(agent.EngineStatus=1)] [leader_node: false]
2020/05/26 04:49:01 [DEBUG] [internal,edge,docker] [message: Docker runtime configuration check] [engine_status: %!s(agent.EngineStatus=1)] [leader_node: false]
2020/05/26 04:50:01 [DEBUG] [internal,edge,docker] [message: Docker runtime configuration check] [engine_status: %!s(agent.EngineStatus=1)] [leader_node: false]
2020/05/26 04:51:01 [DEBUG] [internal,edge,docker] [message: Docker runtime configuration check] [engine_status: %!s(agent.EngineStatus=1)] [leader_node: false]
2020/05/26 04:51:06 [DEBUG] [internal,edge,poll] [status: IDLE] [port: 0] [schedule_count: 0] [checkin_interval_seconds: 300.000000]
2020/05/26 04:52:01 [DEBUG] [internal,edge,docker] [message: Docker runtime configuration check] [engine_status: %!s(agent.EngineStatus=1)] [leader_node: false]
2020/05/26 04:52:01 [DEBUG] [internal,edge,poll] [status: IDLE] [port: 0] [schedule_count: 0] [checkin_interval_seconds: 300.000000]

Seems this happens after a updating the poll frequency at the endpoint level. Not sure if its related to removing the old endpoint client.

I didn't change the agent, so I assume it's an existing bug, I'll check it and open a bug in agent

Ok I'll review this one again separately then.

Please rebase that PR on the develop branch.


it should work with the dot.?

Challenge Testing Objects for Properties has an issue.
User Agent is: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:

// Setup
var myObj = {
  gift: "pony",
  pet: "kitten",
  bed: "sleigh"
};

function checkObj(checkProp) {
  // Your Code Here
  if(myObj.hasOwnProperty(checkProp) === true ){
     result = myObj.checkProp; // myObj[checkProp];
    return result;
  }else{
    return "Not Found";
}

  return "Change Me!";
}

// Test your code by modifying these values
checkObj("pet");

### info ###
in the
result = myObj[checkProp];
it is the correct to use an the dot "." ?
result = myObj.checkProp;
in my code it not pass that as correct.
i need to put brackets.

You need to use myObj[checkProp].
Also, please only post in the issues section after trying to get help from the gitter chat.

@BerkeleyTrue thank you for your time.
I only would like to now if is correct to use the dot and if yes why they do not pass it.

Using the dot is incorrect. See http://stackoverflow.com/questions/4968406/javascript-property-access-dot-notation-vs-brackets


LDAC as sink possible?

Thanks to the great guide in wiki, I was able to compile bluez-alsa from source on my Raspberry Pi Zero.
It should act as a bluetooth receiver so I need bluez-alsa to be sink for the several codecs.
For configuration I used:
../configure --enable-aac --enable-ldac
and got this as replay:
checking for AAC... yes
checking for LDAC_ABR... yes
checking for LDAC_DEC... no
checking for LDAC_ENC... yes
Looking at configure.ac, if I didn't misunderstood, the script is looking for ldacBT_dec.
As far as I could see, ldacBT only creates ldacBT_abr and ldacBT_enc but never (also in earlier versions) ldacBT_dec.
After compiling I could connect with my Android Smartphone and select AAC in developer options. When I tried LDAC it always switches back to AAC so to me it looks like LDAC as sink is not working.
Since I'm very new to this, I hope I did not misinterpret things.
Is it correct the LDAC is not possible as a sink at the moment or am I just missing something? If so, could you please give me a hint which way to go?
Thank for support!
Side question:
In contrast to the guide I couldn't find any packages for libopenaptx/libopenaptx-dev in the Raspbian Repository. Can someone confirm that this also has to be installed form source?

As far as I could see, ldacBT only creates ldacBT_abr and ldacBT_enc but never (also in earlier versions) ldacBT_dec.

See this (last example): https://github.com/Arkq/bluez-alsa/wiki/Installation-from-source#additional-dependencies For decoding support you need full version of Sony's LDAC library (not the one available in AOSP). For that you will need to contact with Sony. Also please note that the library which Sony provides does not have pkg-config support, you will have to provide correct cflags and libs as in the wiki example.

I couldn't find any packages for libopenaptx/libopenaptx-dev in the Raspbian Repository.

Debian introduces libopenaptx in release 11 ("bullseye") due to be released this month. It usually takes a while for Raspios to be updated to a new upstream Debian though. Ubuntu introduced it in release 20.10 "Groovy Gorilla".

@Arkq does this LDAC decoder library work out of the box? Or some modifications are required?

It won't work out of the box, it uses different API than Sony's LDAC. You
will have to modify BlueALSA decoder function.

There are two possible solutions:

Add support to BlueALSA for that library
Edit library's API
Which one should be preferred?

It depends. If this library is already widely used and packaged with few
distributions, we can add support for it in bluez-alsa. However, if this
library is not widely known, I would opt for API change, or adding new API
as an adaptation layer for official Sony's LDAC library. The benefit of
having the same API is a seamless change between different implementation
of the same algorithm.
The Sony's LDAC API is not complicated. It uses the same handle as encoder

getHandle function is the same. Then there are two functions, one for
codec initialization and one for actual decoding. API alone is not a
subject for patents, so using the same API will not break any law.

LDACBT_API int
ldacBT_init_handle_decode(
HANDLE_LDAC_BT hLdacBT,
int cm,
int sf,
int nshift,
int var1,
int var2 );
LDACBT_API int
ldacBT_decode(
HANDLE_LDAC_BT hLdacBT,
unsigned char *p_stream,
void *p_pcm,
LDACBT_SMPL_FMT_T fmt,
int stream_sz,
int *used_bytes,
int *pcm_sz );

Okay, I will give that a try. Given that probably no one uses this library, API change or adaptation layer seems to be better way.

I added adaptation layer, it probably works, but I'm not able to test it and don't want to release without any tests.
I'm on LMDE 4, EHfive' spulseaudio bluetooth module was deleted (maybe incorrectly? At least, I can't see them in pacmd list-modules). I can remove device, pair and after few seconds it disconnects:
[CHG] Device XX:XX:XX:XX:XX:XX ServicesResolved: no
[CHG] Device XX:XX:XX:XX:XX:XX Connected: no

And then connect XX:XX:XX:XX:XX:XX gives
Failed to connect: org.bluez.Error.Failed

Any ideas?

Try connecting instead of pairing. That's first idea. Also, please check whether your host running bluealsa and remote device have matching Bluetooth profiles. Maybe there is nothing to connect. Also, sometimes it is required to have HFP enabled with wide band speech capability (some phones require that, e.g. iPhone).

@Arkq
It now connects (but only if connection is initiated on both devices and not every time) and plays audio with SBC, AAC, aptX (not HD though). But with LDAC it gives no sound probably because of this error: Bluetooth: Dropping L2CAP data: receive buffer overflow

Are you using Android with your tests? I've seen such errors when streaming
AAC from Android phone which was not conformant with the Bluetooth spec.
But it was long time ago (4 year maybe) when AAC was not in mosts Android
phones.

@Arkq
Yes, Android. Will look with Raspberry Pi later, but I think that problem is with library. What is receive buffer? Is it pcm.data or something else? What is it's size?

Buffer for received data is "bt.data" and it's size should be equal to
transport MTU. But the error you've got is from BlueZ, I think.

@Arkq
What actually happens? I can see debug messages from decoder library. Does this mean it actually decodes something? Or it receives no data to decode?

If you can see logs from decoder library, then you have to make sure that
the encoder (e.g. Android) has encoded the stream properly. But, "L2CAP"
log message does not seem like a log from decoder. I might be wrong though,
I've never been using the decoding library which you are trying to adopt to
bluealsa.

I used to have WH-1000XM4 with LDAC sink support and it worked, so I assume it encodes stream properly.
L2CAP is from gnome-logs (it's also visible in dmesg), decoder messages - from ldacBT_decode which is called by bluealsa (and therefore printf prints messages to the same console bluealsa prints its debug messages).

There are few approaches how to debug it. The most "low level" is to
register Bluetooth traffic on host with bluealsa, e.g. with tcpdump,
wireshark, etc. Then extract raw assembled A2DP frames (the easiest way is
to use wireshark), then from these frames extract LDAC data (strip RTP
header) and concatenate all these frames and use decoder library to decode
the stream. If it will work then you will have to debug bluealsa in a
similar way. Save to a file raw LDAC data (without RTP header) and compare
it with data recorded with wireshark. I follow these steps when I encounter
serious troubles with encoder/decoder.

There is also other option, but I'm not sure whether it will work (I was not using it since long time ago). In the src/a2dp-sbc.c there is a function a2dp_sink_dump(). Remove static from it and add it's declaration to e.g. a2dp.h. Then in the file src/a2dp-ldac.c in line 345 replace a2dp_ldac_dec_thread with a2dp_sink_dump. This should create simple stream dump in  /tmp directory. Play few seconds of LDAC audio and attach the dump file here with log lines "BT read: xxx" which will say how long the frames are in the dump file. Then I will try to feed these data directly into the bluealsa and check whether Sony's decoder will decode your stream.

@Arkq
I added a2dp_sink_dump declaration to ba-transport.h because a2dp.h gave compilation error:In file included from
../../src/ba-transport.h:24,
                 from ../../src/a2dp-sbc.h:19,
                 from ../../src/a2dp-sbc.c:11:
../../src/a2dp.h:131:29: warning: ‘struct ba_transport_thread’ declared inside parameter list will not be visible outside of this definition or declaration
 void *a2dp_sink_dump(struct ba_transport_thread *th);
                             ^~~~~~~~~~~~~~~~~~~
../../src/a2dp-sbc.c:317:7: error: conflicting types for ‘a2dp_sink_dump’
 void *a2dp_sink_dump(struct ba_transport_thread *th) {
       ^~~~~~~~~~~~~~
In file included from ../../src/ba-transport.h:24,
                 from ../../src/a2dp-sbc.h:19,
                 from ../../src/a2dp-sbc.c:11:
../../src/a2dp.h:131:7: note: previous declaration of ‘a2dp_sink_dump’ was here
 void *a2dp_sink_dump(struct ba_transport_thread *th);
       ^~~~~~~~~~~~~~

BT read: 669
ba-a2dp-sink--ldac-.dump.tar.gz

Ok, I will check that but in ~2 hours. Now I'm checking tomatoes and
cucumbers in grocery store :)

I assumed that the mode was stereo, 96000 Hz. There were no errors during decoding.
Decoded wave file: decoded-LDAC.wav.zip

@Arkq
This is in logs then phone does not connect to PC: SET_CONFIGURATION request rejected: Stream End Point in Use (19).
I also made my own sink dump.zip. Here is the code for dump (also available in my libldacdec fork)
int ldacBT_decode(HANDLE_LDAC_BT hLdacBT, uchar *p_stream, void *p_pcm, LDACBT_SMPL_FMT_T fmt, int stream_sz, int *used_bytes, int *pcm_sz){
    (void)stream_sz;
    ldacdec_t *dec = (ldacdec_t *)hLdacBT->hLDAC;

    FILE *fp = fopen("/tmp/ldac.dat","ab");
    FILE *raw = fopen("/tmp/ldac.pcm","ab");
    if(fp==NULL){
        fp=fopen("/tmp/ldac.dat","wb");
    }
    if(raw==NULL){
        fp=fopen("/tmp/ldac.pcm","wb");
    }
    fwrite(p_stream, 1, stream_sz, fp);

    printf("LIBLDACDEC: Format: %d, ", fmt);

    if(fmt != LDACBT_SMPL_FMT_S16 && fmt != LDACBT_SMPL_FMT_S32 && fmt != LDACBT_SMPL_FMT_F32) return hLdacBT->error_code_api=517; //FIXME: Add other PCM types;

    if(hLdacBT->proc_mode != LDACBT_PROCMODE_DECODE) return hLdacBT->error_code_api=1000;

    int result = ldacDecode_type(dec, p_stream, p_pcm, used_bytes, fmt);
    *pcm_sz = dec->frame.frameSamples;
    printf("decode result: %d, frameSamples: %d\n", result, dec->frame.frameSamples);
    if(result == -1) return hLdacBT->error_code_api=516;

    fclose(fp);
    fclose(raw);
    return  hLdacBT->error_code_api=result;
}

This should be just raw LDAC data and it is decoded by library but sound is not what I expect:
output.wav.zip, it looks like channels were not deinterleaved.
Raw file is also not good.
Maybe I am using some params wrong? Can you please give short brief about all ldacBT_decode parameters?

/* LDAC decode processing.
 *
 *  Arguments
 *      hLdacBt    HANDLE_LDAC_BT    LDAC handle.
 *      p_stream   unsigned char *   Input "ldac_transport_frame" sequence.
 *      p_pcm      void *            Output PCM signal sequence.
 *      fmt        LDACBT_SMPL_FMT_T Audio format type of output pcm.
 *      stream_sz  int               Size of input data. Unit:Byte.
 *      used_bytes int *             Used bytes of input data. Unit:Byte.
 *      pcm_sz     int *             Size of output PCM signal sequence. Unit:Byte.
 *  Return value
 *      int : 0 for success, -1 for failure.
 */
LDACBT_API int ldacBT_decode( HANDLE_LDAC_BT hLdacBT, unsigned char *p_stream, void *p_pcm,
                              LDACBT_SMPL_FMT_T fmt, int stream_sz, int *used_bytes, int *pcm_sz );

Definition of LDACBT_SMPL_FMT_T you've got in inc/ldacBT.h in AOSP libldac.

@Arkq
Yes, looks like I used them correct. I have this
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 656, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 492, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 328, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 164, used_bytes: 164

in my logs continuously, it looks fine to me. I also tried 2 different phones: Galaxy A51 and Redmi 8A. Both of them didn't work but in different ways: A51 segfaulted my library (probably because I called fwrite with NULL argument, but it was caused by another error):
bluealsa: D: ../../src/a2dp-sbc.c:336: Opening BT dump file: /tmp/ba-a2dp-sink--ldac-.dump
bluealsa: D: ../../src/a2dp-sbc.c:350: IO loop: START: a2dp_sink_dump: A2DP Sink (LDAC)
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 668
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 17
...
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 668
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 13
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 668
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 17
...
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 668
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 13
...
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 668
bluealsa: D: ../../src/a2dp-sbc.c:358: BT read: 17

A51 dump, full logs and decoder logs attached. Interesting parts are (negative stream size?):
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 655, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 491, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 327, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 163, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 0, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: -164, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: -328, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: -492, used_bytes: 164
LIBLDACDEC: Format: 4, LDACDEC: syncword: 0
result: -1, pcm_sz: 256, stream_sz: -656, used_bytes: 164
bluealsa: D: ../../src/utils.c:647: Unknown error code: 0xffffffee (API: 4095, handle: 1023, block: 1006)
bluealsa: E: ../../src/a2dp-ldac.c:307: LDAC decoding error: Unknown error
*** Segmentation fault

Illegal sync word (probably related to BT read: 13/17, it happened before encoding parameters were changed):
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 655, used_bytes: 220
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 435, used_bytes: 220
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 215, used_bytes: 220
LIBLDACDEC: Format: 4, LDACDEC: syncword: 1
result: -1, pcm_sz: 256, stream_sz: 4, used_bytes: 220
bluealsa: E: ../../src/a2dp-ldac.c:307: LDAC decoding error: Invalid sync-word

And this is without parameter change (other try):
result: 0, pcm_sz: 256, stream_sz: 655, used_bytes: 110
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 545, used_bytes: 110
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 435, used_bytes: 110
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 325, used_bytes: 110
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 215, used_bytes: 110
LIBLDACDEC: Format: 4, LDACDEC: syncword: aa
result: 0, pcm_sz: 256, stream_sz: 105, used_bytes: 110
LIBLDACDEC: Format: 4, LDACDEC: syncword: 1
result: -1, pcm_sz: 256, stream_sz: 4, used_bytes: 110
bluealsa: E: ../../src/a2dp-ldac.c:307: LDAC decoding error: Invalid sync-word
*** Segmentation fault

Redmi 8A gave no sound and empty dump file (0 bytes), with SBC it played music just fine.

If you've got negative stream, something is not right with the ldacBT_decode API call. The decoding loop expects that in the used_bytes there will be the number of bytes used in a single decoding step - number of bytes for one LDAC frame. Then, this loop iterates over all frames in the RTP packet. So the total bytes of A2DP transport frames should equal to rtp.frames * LDAC_i_frame_len. So, either the RTP header is incorrect, or returned used_bytes is too big.

@Arkq
Can you check A51 dump? It printed 3 different BT read values (previous dump had only 1), I think this is may be somehow related.

@Arkq
I found the error: sound was present (but it wasn't inaudible because internally library has PCM float with range not [-1.0;1.0] but [SHRT_MIN;SHRT_MAX]). With this fix I was able to decode my first and second dumps. For first it was necessary to only add offset of 13 to every frame, for second - while(ptr[0]!=0xAA){ptr++;filePosition++;} too. Some frames are just to small, I have no ideas why.
However, it still won't work, I can see 2 problems:

Sound is played only half of the time at double speed (and there is nothing in other half ). This is probably because I misused some parameters (BlueALSA expects something another in them), but what is used incorrect? Can you check it?
Playback (even bad) stops after few seconds. This is probably has something to do with this: bluealsa-aplay: D: ../../../utils/aplay/aplay.c:480: Device marked as inactive: XX:XX:XX:XX:XX:XX and Bluetooth: Dropping L2CAP data: receive buffer overflow. It may not be caused by library but it still ruins everything. And I don't know how to fix this. Any ideas?

It would be great if someone checked library and confirmed that this issue is present on other devices.

According to https://github.com/Arkq/bluez-alsa/issues/482#issuecomment-906060241 the work is done here. Since it's not a strict bluez-alsa project issue I'm closing it then.

not sure about original library from issue #104: it won't even install

I originally extracted this library from some FiiO player running android FW, so it is obviously linked against Bionic libc. You can try using the lib with something like https://github.com/libhybris/libhybris

@Arkq
Is it possible that debugging info about MTU is incorrect?
I changed default MTU in kernel to 688 (and this is value which is shown), but I can't find it in Wireshark logs. It only shows 672 (which was default) and few other values (IIRC 512, 1024, 1008).
So it seems that MTU is set to 672, but everything still works. There's no buffer overflow probably because of that 688 in kernel.
Looks like that BlueALSA should set incoming MTU, but I can't find any code related to that. Is there any easy way to set it to at least 673 for better LDAC sink compatibility?

The MTU for read/write comes from BlueZ. See this: https://github.com/Arkq/bluez-alsa/blob/master/src/ba-transport.c#L556 BlueALSA only respects this value, that's all.

Oh, I think somebody tried to use my library in Pipewire and got the exact same issue. So this probably should be reported to BlueZ as bug?

Hi, Could anyone please tell me whether LDAC sink is currently stable? Are there any known problems (except that we have to change MTU)? Thank you very much!

@andreadaoud
Yes, it's pretty stable. You may always check by yourself.
One of the problems is with Samsung phones. For some reason they also transfer small packets of unknown data which are not properly decoded. Simple patch for BlueALSA fixes that, see issue in my libldacdec fork

@anonymix007 Thank you very much for your great work on libldacdec! One more question: is the fixed-point branch ready to use?

@andreadaoud
Yes, it works fine. But you don't need it unless you're going to use device without FPU.


 Tried to allocate 1.22 GiB. GPU 2 has a total capacity of 79.33 GiB of which 688.00 MiB is free. Process 3711898 has 78.64 GiB memory in use. Of the allocated memory 75.65 GiB is
 allocated by PyTorch, and 1.78 GiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Mem
ory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)

Reduce the resolution to 256.

Reduce the resolution to 256.

It works, many thanks!
BTYW, how do I train with higher resolution? From readme I thought opensora implemented sequence parallel but didn't find it in code.

The convolutional structure of VAE has strong extrapolation, and we only trained it at low resolutions. SP training was used for training the diffusion model.

The convolutional structure of VAE has strong extrapolation, and we only trained it at low resolutions. SP training was used for training the diffusion model.

Many thanks for your reply!


org settings: Hide less used tabs by default for non-admins.

This page: https://chat.zulip.org/#organization/organization-profile shows a number of different tabs, which can be a bit overwhelming for non-admins.
We should hide some of the tabs by default, and add a link "Show more organization settings" at the bottom of the last tab. Clicking on it should unhide the hidden tabs, and change the link to "Show fewer organization settings".
For each tab, there are a few options:

For members: show/collapse/hide
For guests: show/collapse/hide

Show means always show.
Collapse means hide by default, but show when you click "Show more organization settings"
Hide means always hide, even in the uncollapsed state.
I'll use X/Y to mean do X for members, and Y for guests.
Organization profile: collapse/collapse
Organization settings: collapse/collapse
Organization permissions: collapse/collapse
Custom emoji: show/show
User groups: show/hide
Auth methods: collapse/collapse
Users: show/hide
Deactivated users: show/hide
Bots: show/hide
Default streams: collapse/hide
Linkifiers: show/show
Custom profile fields: hide/hide
Invitations: hide/hide

@zulipbot claim

@zulipbot PR is awaiting review.
@timabbott  #12321 is a somewhat smaller PR, and ready for review.


Update to a dev version latest bitcoin master 0e2e55971275da64ceb62e8991a0a5fa962cb8b1

Update to a version of dev rust-bitcoin so that we can prepare for rust-miniscript release. The integration tests are updated to point a personal fork of rust-bitcoincore-rpc to have rust semver type issues.
After we have this, we can make progress on tapscript while we await finalized rust-bitcoin release. After which, we can remove the git dependencies and have crates.io dependencies instead.

@apoelstra, this can help move things forward on rust-miniscript

Resolving the comments in follow up PR


Fix #5595 : batch_simple regression.

Fix  #5595 : batch_simple regression.
The container details weren't returned in the job description anymore.
    [ ] Feature is added
    [x] The linter is happy
    [x] Tests are added
    [x] All tests pass, existing and new

Codecov Report

Merging #5644 (0bf9499) into master (bcb6399) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #5644      +/-   ##
==========================================
- Coverage   96.21%   96.20%   -0.01%
==========================================
  Files         742      742
  Lines       72642    72686      +44
==========================================
+ Hits        69889    69926      +37
- Misses       2753     2760       +7

Flag
Coverage Δ

servertests
36.93% <7.14%> (+<0.01%)
:arrow_up:

unittests
96.14% <100.00%> (-0.01%)
:arrow_down:

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

Impacted Files
Coverage Δ

moto/batch/models.py
91.57% <100.00%> (+0.03%)
:arrow_up:

moto/xray/mock_client.py
80.00% <0.00%> (-14.00%)
:arrow_down:

moto/awslambda/models.py
94.20% <0.00%> (-0.42%)
:arrow_down:

moto/utilities/utils.py
94.11% <0.00%> (ø)

moto/config/responses.py
100.00% <0.00%> (ø)

moto/comprehend/models.py
98.11% <0.00%> (ø)

moto/config/models.py
99.34% <0.00%> (+<0.01%)
:arrow_up:

moto/config/exceptions.py
99.46% <0.00%> (+<0.01%)
:arrow_up:

moto/organizations/models.py
99.59% <0.00%> (+<0.01%)
:arrow_up:

moto/rds/models.py
94.51% <0.00%> (+<0.01%)
:arrow_up:

... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Allow extra_data and payload to be sent, too

Any thoughts @paulstatezny? Did you specifically exclude this data?

@mbrevda Sorry for the delay. I did not intentionally exclude this data. Just wasn't this thorough. Thanks for building on it. :smile:

@Seldaek - can we get this merged?

Looks good so let's merge, I'm in holidays so not watching github too closely


Allow debug adapters prioritize suggestions via breaking alphabetic sorting

Suggestions returned by the debug adapter are currently sorted by label then by type. This prevents debug adapters from suggesting their own completion order. For example, for JavaScript objects, useless __defineGetter__ suggestions are shown at the very top:

Begin able to control the order allows adapters listing properties as they wish, for example by prototype, hence pushing the object's properties to the very bottom.

I experimented with addressing it and the simplest way I found was prepending zero-width space to the suggestions in order to push them lower the stack. VS Code shows these suggestions, but does not quite like applying them out of the box. With a single line change to isWhitespaceAtPos that starts treating \u200B as a space makes it happy.
That might sound hacky, but formally it looks Ok and allows not introducing any additional completions settings and/or DAP capabilities. I'm happy to submit a PR if you find the approach reasonable.

@isidorn We can take the  "hacky" fix for now, but we should start addressing this in a better way, which might involve extending the DAP.

@pavelfeldman agree with your point that putting the useless properties at the end is the right thing to do.
@weinand as for extending the DAP I think the right apporach would be to go with sortText which we already expose in vscode.d.ts.
As for the hacky solution we can also go down that route, however for changes at isWhitespaceAtPos we need @jrieken approval since that would change all fuzzy scoring used by the suggest widget.
Thus I would lean towards extending the DAP.

Ok, I've created a DAP feature request for adding a "sortText" to the "CompletionItem" type.

With a single line change to isWhitespaceAtPos that starts treating \u200B as a space makes it happy.

Generally that's a fair change - the list of whitespace characters in definitely  not complete. Anyways, the proper way to tackle this is @weinand's sortText extension.

Any solution works for me. DAP sourText extension sounds great. It requires more changes in VS Code itself - it seemed fairly opinionated in how it wanted to alphabetically sort items, but overall sounds like a great addition!

@isidorn
I've added an optional "sortText" attribute to the "CompletionItem" type.
Please implement sorting completion items based on this.

Debug console now supports the sortText.
Try it out from Wednesday vscode insiders and let me know how it behaves.

I've added sample code for completions to mock-debug and verified that sorting completion items work.

Adding verified label per @weinand comments. And seems to work for Pavel as well.


Peering Request

Full Name
Kerfuffle
ASN
35008
PeeringDB Integration

[X] My PeeringDB Entries are current
[X] Peer at ALL EXCHANGES (and skip the Peer Address(es) field below)

Peer Address(es)
<IP_ADDRESS>
2001:67c:760:a::5
Multihop

[x] Multihop Peering Request

Code of Conduct (TODO)

[X] I agree to follow this project's Code of Conduct

Hi,
Here are the peering details for the Route Views collectors:
route-views5 multihop:

ip4: <IP_ADDRESS>
ip6: 2001:468:d01:33::80df:3369
asn: 6447

sfmix:

ip4: <IP_ADDRESS>
ip6: 2001:504:30::ba00:6447:1/64
asn: 6447

The peering sessions are up on our side:
route-views5:

    Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
    <IP_ADDRESS>   4      35008         0         0        0    0    0    never       Active        0 Kerfuffle, LLC

    Neighbor                              V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
    2001:67c:760:a::5                     4      35008         0         0        0    0    0    never       Active        0 Kerfuffle, LLC

sfmix:

    Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
    <IP_ADDRESS>  4      35008         0         0        0    0    0    never       Active        0 Kerfuffle, LLC

    Neighbor                 V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
    2001:504:30::ba03:5008:1 4      35008         0         0        0    0    0    never       Active        0 Kerfuffle, LLC

Route Views collects routing data which is freely made available.
For reference, real-time monitoring of the data you are contributing to
this collector can be examined using the BGPStream/bgpreader toolkit.
example 1. live data
bgpreader -l -p routeviews -R  -j
example 2. data past 24 hours
bgpreader -I 24h -c  -j
For more information, please see: http://www.routeviews.org/routeviews/index.php/faq/
and https://bgpstream.caida.org/


Make watchOS scheme shared so that it can be seen by carthage

Ah, yeah, that seems important. Merged into swift-2.0 as 8a117b1.
Thanks!


Various requests and LIG bug

This package is amazing!! Thank you so much for putting it together. I had a hard time using it though and noticed a few issues of issues (detailed below) that made me eventually drop it in favor of writing my own abstractions, so I believe this feedback, if incorporated, would make your package much more helpful and popular for others! So sorry for dumping all of these issues/feature requests on you without putting in some pull requests myself but I hope it's useful :)

I think this was the biggest issue for me, the interface is confusingly split across an object (SequenceClassificationExplainer) that also acts as a quasi-factory method. The constructor and instance also overlap in their functionality, e.g. my understanding is that there's two ways to attribute a bunch of texts:

    for text, label in zip(texts, labels):
        explainer = SequenceClassificationExplainer(text, model, tokenizer)
        attributions = explainer(index=1)
        print(attributions.word_attributions)             # note how the products of the inference/attribution live in two different objects
        print(cls_explainer.predicted_class_index)

or, equivalently
    explainer = SequenceClassificationExplainer("",  model, tokenizer)
    for text, label in zip(texts, labels):
        attributions = explainer(text= text, index=1)
        print(attributions.word_attributions)             # products of the inference/attribution still live in two different objects?
        print(cls_explainer.predicted_class_index)

I think it might be much cleaner to have one object which is in charge of orchestrating the attribution!
    explainer = SequenceClassificationExplainer(model, tokenizer)
    for text, label in zip(texts, labels):
        attributions = explainer.explain(text= text, index=1)
        print(attributions.word_attributions)             # products of the inference/attribution live in same object
        print(attributions.predicted_class_index)

true_class in visualize() is expected to be a string, but immediately cast to an int https://github.com/cdpierse/transformers-interpret/blob/2e41a6b518f12e67697213764c7921398f9d016d/transformers_interpret/explainers/sequence_classification.py#L110

I think there's a bug in how you're calling LIG? I think using the input_ids as a baseline is bad because then there's nothing for LIG to interpolate between when computing gradients. I'm less sure about the token type ids but I think the preferred approach is just giving it the special tokens and pads as your baseline.

https://github.com/cdpierse/transformers-interpret/blob/deebcf8e109ef405a6cf52e5f0e102be2bda45b1/transformers_interpret/attributions.py#L54

Argument "text" goes unused
https://github.com/cdpierse/transformers-interpret/blob/deebcf8e109ef405a6cf52e5f0e102be2bda45b1/transformers_interpret/attributions.py#L99

It would be nice if cls_explainer.visualize() optionally wrote to a file and instead returned the HTML so the user could decide what to do with it.

Again, thank you so much for putting this together and hope this is useful for you!

Hi @rpryzant,
Thank you very much for the suggestions and input, this package is super nascent at the moment and there are a lot of things I would like to change going forward with it many of which you have mentioned here. I'm going to address each of your comments point by point as I think that's easiest:

Totally in agreement on this, it's my biggest issue with the package at the moment aswell especially since I've been working on a question answering explainer and the design of the constructor has kind of started to fall apart. I'm going to separate the constructor from the instantiated object. At the time I guess I really liked the idea of a one liner but it doesn't really work well and the two behaviors are confusing.

The only change I would make to the example you provided is that I would try and keep the instance of the explainer as a callable rather than invoking a explain method, I would be interested though in why you would do it this way. Also when you refer to the products of the inference and attribution living in the same versus different object I couldn't see a significant difference between your first and last example other than text being a required argument to the explain method.
This is how I would go about structuring the interface:
    explainer = SequenceClassificationExplainer(model, tokenizer)
    for text, label in zip(texts, labels):
        attributions = explainer(text= text, index=1)
        print(attributions.word_attributions)
        print(attributions.predicted_class_index)

You're right I think this is a layover of an old bug I was having with the visualizer where I was casting everything to string for safety. I'm doing two different behaviors here for models of different types i.e. models that have a single node output are having the class cast to a int (either 0 or 1) whereas models that have multi-node ouputs have the true class cast to a string. I'll definitely fix this although I don't think it should be causing any major issues as the type casting here is purely cosmetic.

I think you be incorrect here, from what I can see I am using ref_input_ids which is special tokens plus pads for attributions, when token type ids and position ids are available I also use their reference type ids as well. The team at Captum  were very helpful recently in helping me figure out how to pass reference ids for token type and position ids you can check that out here pytorch/captum#624

Yep it does, that's probably going to go in the next update.

The latest version should be returning the iPython HTML object in visualize, writing to a file has been optional from the start I believe.

Thank you again for this input, I really appreciate it especially at this stage of the project, I think it has a lot of room to grow but I need to figure out interface issues like those you have highlighted first. Would love to hear any other suggestions you might have in the future.


Updated Readme Fixed repo url

url to get repo wasn't valid

Thanks for the fix! We're not set up to directly accept GitHub pull requests; changes need to go through our Gerrit instance. I have manually pushed your change through there: http://review.couchbase.org/#/c/53918/
Closing this PR as it the change is now merged.