Adding styling to a specific post page supported by its comment form

Added label counters represent the number of each label in comments of
a specific post, more user-friendly appearance of comments showing
profile image for both comments and post all in [post_detail.html][1]
file
Updated views function to ease the use of objects in the html file and
support extra logic needed for presenting label counters- changes on [Post/views,py][2]
Updated [commenting_system/forms.py][3] to support better styling and
ease the use of form fields in the html file

closes #140

@Leeadar

I'm not sure what causes the problem with the navbar it might be due to the various links I used for styling I'm not sure I know how to fix it to be honest since all I changed was in this particular HTML file
The submit button will work with an older version of the form (the label and the comment part)- I'll change it back and in case I would have an answer for how to use the new style without breaking it (due to customizing widgets for the modelForm of comment) it will be as it was unfortunately
The purpose of this PR is mainly design, not sure if adding more logic to the view would be wise, but I can try adding a modal in HTML if you really want it so it would make a pop-up window style action
It's not very indicative I have nothing to do with this comment, I can try moving the username.
Giving up on profile picture won't change anything with spacing I can try adding a line if its critical, the best I can suggest is removing the labels per comment and leaving it only appear on top as it is next to the post

@Leeadar Regarding the 4'th point it seems inconsistent and unclear moving the name before the picture (also the defining line between comments was blur due to profile pictures with white background mainly)-  look :


Click is not working in innerHTML

I am developing the hybrid mobile app in ionic2. In that, I want to bind HTML content which is coming from a backend API.
Following is my code:
htmlCode ='
Please visit your ELIGIBILITY & BENEFITS SUMMARY to find the summary of benefits information.
'

In this, the click event is not working. Even when I used safe HTML then also it is not working.

What do I need to do so that the click works?

Hello! Thank you for opening an issue with us!
The Ionic Framework issues list is designated for the reporting of bugs with the Ionic Framework or for requesting new features. As this seems like more of a support question I am going to close this issue.
I urge that you ask this question on our forum or on our slack channel.
If this turns out to be an issue with the Ionic Framework, please open an issue here with the template fully filled out and with a sample application that duplicates your issue.
Thanks for using Ionic!


Vitest runs tests 3x slower than Jest with threads: true (default) setting

Describe the bug
With the latest Vitest/Vite dependencies, Vitest is ~3 times slower than Jest in https://github.com/EvHaus/jest-vs-jasmine (more or less like a typical front-end repo) with the  threads: true (default) setting.
 That issue was closed but threads: true is still 3-4 slower than Jest after the issue was closed and the repro dependencies updated).
The issue was raised in Discord chat as well.
With threads: false Vitest is ~2 times faster, but the cost of it - there's no real isolation. With threads: false it's unfortunately not even close what Jest is doing in terms or resetting state, so not even sure if makes sense to compare threads: false with Jest (maybe threads: false should be compared with uvu or other "run-once-and-forget" runners with no real isolation). In a variety of projects that we have worked on, even with pure stateless components, the proper isolation is a super important concern. Especially in watch mode where introducing some unwanted state/mocking or polluting global/process state is simply an expected thing to happen due to the nature of various incremental changes (that are not always good or final) that simply break not properly isolated watch mode.
Reproduction
git clone https://github.com/EvHaus/jest-vs-jasmine

yarn

(if required, install hyperfine)
hyperfine --warmup 1 'yarn workspace jest test' 'yarn workspace vitest test --threads=true'

System Info
System:
    OS: macOS 11.2.3
    CPU: (16) x64 Intel(R) Xeon(R) W-2140B CPU @ 3.20GHz
    Memory: 25.41 MB / 32.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node
    Yarn: 3.1.1 - ~/.yarn/bin/yarn
    npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Browsers:
    Chrome: 97.0.4692.71
    Firefox Developer Edition: 61.0
    Safari: 14.0.3

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

@cbxp User time will be higher because Vitest is multi-threaded.
User time is the time processor spent running a process. If you have multiple cores, user time will be higher for multi-threaded apps. Because it aggregates all the work that all cores did.

One of the reasons why Jest is fast is cache.
I added yarn workspace jest test --no-cache to the example of jest-vs-jasmine.
 This, hopefully, will allow us to drop costly isolation using Workers. We will essentially have the same isolation as Jest.
But I did not have time to work on this recently (there is the war going on)

@pmdarrow I'm investigating switching to vm.runInNewContext from vm.runInThisContext. This, hopefully, will allow us to drop costly isolation using Workers. We will essentially have the same isolation as Jest.

I don't think we can do it without getting the same problems Jest has, because VM has terrible support for ESM. I already tried it.

My team in the process of migrating a large test suite (6073 tests) from jest to vitest. With jest, the full suite runs in 3m47s. With the latest vitest (0.18.0) it runs in 10m7s. We really want to continue with vitest but this kind of a slow down is making it challenging. We don't want to disable isolation, as it's crucial for reliability in a test suite this large. Is there any plan to improve the performance vitest, or is jest doing something fundamentally different that vitest won't be able to replicate? @antfu @sheremet-va @Demivan

You can get speed boost by disabling isolation. Bear in mind tho, that it will make globalThis object sharable between tests.

After investigating it more and checking with @sheremet-va i don't think it can be implemented with current state of vm module. Fixing all the issues will mean getting all Jest bugs too.
Lets hope ShadowRealm implementation will be better then vm module.

So is the summary that we're stuck with the performance where it's at right now, unless we want to sacrifice isolation? If so, I think this should be published in the docs somewhere. It took us a considerable amount of effort to update our suite to work with vitest (which we believe is the way forward) only to find out it's 3x slower 😢

Vitest runs tests 3x slower than Jest

That is an incorrect statement. It really deps on what and how your tests are written. You can't say a man walks faster than cars without the context (in a traffic jam or something it might be true). The reason why this is happening commonly due to you are using some giant dependencies, where in isolation, they will be executed multiple times for each tests. Vitest is on-demand like Vite, while Jest will bundle the code, so in some scenario it would be more efficient than Vitest.
While indeed there is some space for optimization like pre-bundle the deps, or waiting for vm to support ESM. But in general, it's still trade-offs between speed and correctness. For performance and also for good practice, I would suggest to make the tests as "unit" as possible, or mocking dependencies whenever you can.

Is there anyway of debugging vitest performance? Maybe list what takes time on each run, or which dependencies are loaded?
After switching a React Testing Library application (built with Vite) from Jest to Vitest, the test time CI (Azure DevOps) went from around 50s with code coverage using Jest, to 2 minutes without code coverage in Vitest.
It could very well be related to dependencies we are using (like Material UI), but it's really hard to debug.

Like @thebuilder and @pmdarrow we have also experienced a 3x slowdown of tests after migrating to vitest from jest, our large CI unit test suite now takes 15 mins instead of 5 when running on GHA.

Ok, I can have a look at this. Can anyone set up a minimal repo (2~3 test files, or the less possible) of how the slowdown is being observed (as I personally do not face such a slowdown when doing unit testing or testing Vue)? Thanks

@antfu Maybe https://github.com/EvHaus/jest-vs-jasmine can help. It's more than 2~3 test files, but I think you can easily just strip out the test suites and reduce them. The latest benchmark shows:
   73.626s ± 0.308s for 'yarn workspace jest test'
   232.393s ± 0.457s for 'yarn workspace vitest test'

Hm, looking at the repo, I wonder if the problem is in .module.css files 🤔 Currently Vitest doesn't process css files, but processes module.css by default (we have a PR to auto mock it in https://github.com/vitest-dev/vitest/issues/1512). We can start from that 👀

@antfu is https://github.com/EvHaus/jest-vs-jasmine sufficient for a reproduction or would you like it to be trimmed down further?

I trimmed a bit locally. Flow + Less is a bit less common tbh, but yes with your tests I can confirm it surfaced some bottleneck of Vitest, where I am still investigating.

@antfu is there anything that we could do to help move this forward?

I am not sure my issue is related, but from time to time this happens, my fans are going off and cpu usage rises to 700%... Something going on with vitest... If this is related, how can I debug, mitigate this?

@phifa I don't think that's related to this discussion - that's just vitest using as many cores as possible. If you don't want this behaviour, you can turn it off: https://vitest.dev/guide/features.html#threads.

Same experience here. Jest ran my test-suite in about 3-5 minutes, after migrating to vitest it now takes 10-17 minutes 😞
I'm sure it would be a lot faster if I disabled threads, but it's not worth dealing with all the potential issues that comes with that.
I do have .less files in my project as well, but they are not called .module.less so I'm not sure if that would affect anything?

Same experience here

I wonder, if enabling deps.fallbackCJS helps?

@phifa I don't think that's related to this discussion - that's just vitest using as many cores as possible. If you don't want this behaviour, you can turn it off: https://vitest.dev/guide/features.html#threads.

The link is about threads btw 😄

@dmLinker @pmdarrow We also want to use vitest as our modern test tool but for now we switched to @swc/jest with good performance gain (3x)

FYI -- I updated my benchmarks to get rid of Flow, LESS and switched to more modern ways of doing things: TypeScript, Testing-Library, etc... and that had a drastic impact on the results.
Vitest is now consistently the fastest, with Jasmine just behind and Jest still consistently 4x slower than both (details).

NOTE: I'm using isolate: false in Vitest to ensure it performs at its best.

Summary
  'yarn workspace vitest test' ran
    1.17 ± 0.01 times faster than 'yarn workspace jasmine test'
    4.64 ± 0.03 times faster than 'yarn workspace jest test'
    4.64 ± 0.06 times faster than 'yarn workspace jest-swc test'
   10.11 ± 0.06 times faster than 'yarn workspace fastest-jest-runner test'

What this tells me is that there's some other external factor at play here. Perhaps a third-party library, or an extra preprocessor, or something.

Glad to hear that, thanks for the update @EvHaus!
I think there is indeed some more space for us to optimize further.

@EvHaus @antfu that's not an apples-to-apples comparison. Jest has fully isolated tests, so setting isolate: false is an unfair comparison. And it's clear most devs want their tests isolated.

@EvHaus  As you can see from the benchmark above, there was a performance problem when isolate was true.

https://github.com/vitest-dev/vitest/issues/579#issuecomment-1154571206
https://github.com/vitest-dev/vitest/issues/579#issuecomment-1197227773

Is it even possible to use testing-library and JSDom without isolate: true? You can't use screen to getBy* from the DOM since it will most likely contain multiple render outputs at the same time.

Speaking from experience, enabling isolate: false in a large test suite will cause all sorts of unexpected behaviour and flaky tests. In theory, it's possible, but if you add more than a couple developers on a project, it will get out of hand pretty quickly.

that's not an apples-to-apples comparison. Jest has fully isolated tests, so setting isolate: false is an unfair comparison.

Sorry, you're absolutely right. I should be including both isolate=true and isolate=false in the benchmarks as some of the test runners do not have that feature. I've updated the suite accordingly and the latest results confirm that Vitest is still really slow when isolation is enabled:
'yarn workspace vitest test --isolate=false' ran
    1.19 ± 0.02 times faster than 'yarn workspace jasmine test'
    4.18 ± 0.04 times faster than 'yarn workspace jest-swc test'
    4.21 ± 0.04 times faster than 'yarn workspace jest test'
    8.34 ± 0.07 times faster than 'yarn workspace vitest test'
    9.34 ± 0.07 times faster than 'yarn workspace fastest-jest-runner test'

TLDR: With isolate enabled Vitest runs 8x slower than without.

And it's clear most devs want their tests isolated.

Is it even possible to use testing-library and JSDom without isolate: true?

Speaking from experience, enabling isolate: false in a large test suite will cause all sorts of unexpected behaviour and flaky tests...

We should probably keep this issue focused on the performance analysis, so forgive me if I'm derailing it a bit, but I did want to chime in and say that this has not been my experience at all. At my last job we used Jasmine (which I believe doesn't have isolation) with a huge number of UI test suites, and more recently we're using Vitest with isolation off. We've never had any issues or flakiness or cases where we pick up DOM elements from previous renders.
For us, if the choice is between isolation or performance, I would choose performance. When the difference is 8x it's a no-brainer, but even if the difference was only 15-20% I think I would still favour the performance boost over isolation. All this to say -- I think it's good that isolate exists as an optional feature that users can opt into. I don't think it's necessary in all cases.

At my last job we used Jasmine (which I believe doesn't have isolation) with a huge number of UI test suites, and more recently we're using Vitest with isolation off. We've never had any issues or flakiness or cases where we pick up DOM elements from previous renders.

AFAIK, Jasmine doesn't even have watch mode, so I'm guessing you are comparing/referring to full runs with isolation vs full runs w/o isolation.
In watch mode it's easy to introduce some unwanted state/mocking or polluting global/process state to the nature of various incremental changes (that are not always good or final). Without proper isolation watch mode becomes unusable and unreliable, it's not even a choice between isolation or performance it's between working as expected vs restarting watch mode every few minutes.

Same thing for me.
I just finished migrating a project with 3,000+ tests (in 450+ test files).
With Jest, it takes 30 to 40 seconds on Jest. With Vitest, it takes 130 to 150 seconds on Vitest.
Roughly 3 to 4 times slower, which is a bummer, because we'll probably have to abort the migration at this point.

Weighing in...
We have a project at around 718 tests, Vue 2.7 / Vuetify.
Vue-CLI / Jest - after the first run, I get a consistent 11s to run.
On our Vite / Vitest branch - its taking around 27.5s.

Please, to all the people who basically just add "+1" - stop. A lot of people are following this thread, and it doesn't help anyone, including maintainers.
If you have real examples, please provide it. Otherwise it's just an annoying notification.

Has there been an attempt to improve Vitest's performance? I also experienced slower test-performance with Vitest compared to Jest (about 1.5x slower) as documented here. It would be unfortunate to see this project fail after being heralded as superior to the existing options.

Hi all, I've been trying to understand what's causing the slowness in Vitest + Element Plus and I put together a small repo: https://github.com/purepear/vitest-element-plus-debug.
It has 2 Vue3 components:
/////////////////////////////// NativeButton.vue //////////////////////////////////
<script setup>
defineProps({ text: String })
</script>

<template>
  <button type="button">{{ text }}</button>
</template>

/////////////////////////////// ElementButton.vue //////////////////////////////////
<script setup>
import { ElButton } from 'element-plus'
defineProps({ text: String })
</script>

<template>
  <ElButton type="primary">{{ text }}</ElButton>
</template>

And 100 test files for each of the 2 components:
/////////////////////////////// 100 x NativeButton.test.js //////////////////////////////////
import { mount } from '@vue/test-utils'

import NativeButton from<EMAIL_ADDRESS>
test('renders NativeButton', () => {
  const wrapper = mount(NativeButton, { props: { text: 'test button' }})

  expect(wrapper.find('button').text()).toBe('test button')
})

/////////////////////////////// 100 x ElementButton.test.js //////////////////////////////////
import { mount } from '@vue/test-utils'

import ElementButton from<EMAIL_ADDRESS>
test('renders ElementButton', () => {
  const wrapper = mount(ElementButton, { props: { text: 'test button' }})

  expect(wrapper.find('button').text()).toBe('test button')
})

Results:
npm run vitest-native   ->  6.77s
npm run vitest-element  ->  18.66s
npm run jest-native     ->  2.51s
npm run jest-element    ->  5.10s

Vitest is significantly slower than Jest. I understand there are reasons(isolation for example), but it's still quite the difference.

Vitest runs the ElButton tests almost 3 times slower than the native button tests.
The "collect" time is the biggest difference: 5.67s vs 109.69s (multi-worker?).
Perhaps element-plus is a barrel import(?) and importing one component imports the whole library? (even though tree-shaking works for builds, it slows down vitest significantly)

Questions
What does the "collect" duration in the Vitest results mean?
Am I doing sth wrong?
Any ideas for improvements on either side (vitest and/or element-plus)?

Perhaps element-plus is a barrel import(?) and importing one component imports the whole library? (even though tree-shaking works for builds, it slows down vitest significantly)

Yes, when you import the component, it imports the whole library. Vitest also needs to do this 100 times for each test file. Excluding it from inline might help. Also, it might be a good idea to alias element-plus to its CJS version, since this is what jest is importing.

What does the "collect" duration in the Vitest results mean?

Basically, it means the time it took for Vitest to do this:
await import('/path-to-test-file.js')

There is also a bottleneck for just importing vitest (~400 ms for each file), which should be fixed in #2721.

Just a heads up. The next Vitest version should enable profiling workers (thanks to @AriPerkkio in #2702), so it might be easier to find the problem. In the meantime you can enable a few environmental variables to debug performance:

VITE_NODE_DEBUG_RUNNER=true will log modules that take a lot of time to load
DEBUG=vite-node:* will show resolve and load time
VITE_NODE_DEBUG_DUMP=load enables debug cache (which DOESN'T refresh, so don't use it for your regular tests), so you can see what files were transformed and how they look like

Thanks for the great advice @sheremet-va 🙇.  Aliasing element-plus to a dist build(for example element-plus/dist/index.full.mjs) instead of element-plus/lib/index.js sped up things even further: ~7.30s (compared to the initial ~18.66s)

On a bigger real world project (couple hundred test files with couple thousand tests... ~30% of those using element-plus)... I managed to shave off 25s (~112s initially, 87s now ). And on top of that, switching to Node 18 brought it down to 70s. And the upcoming "~400 ms for each file" improvement sound brilliant! 🥳
I was actually tried @AriPerkkio's PR and did some profiling before I came here but couldn't quite understand what's going on :)
https://github.com/vitest-dev/vitest/pull/2702 and https://github.com/vitest-dev/vitest/pull/2721 - great stuff guys 🙌  Can't wait to get my hands on the next release.

There is also a bottleneck for just importing vitest (~400 ms for each file), which should be fixed in https://github.com/vitest-dev/vitest/pull/2721.

Hey @sheremet-va, just want to double check that I'm not doing sth wrong.
I tried updating https://github.com/purepear/vitest-element-plus-debug from 0.27.3 to 0.28.1 and I noticed about 200-300ms speed improvement total - for 100 files it was previously ~7.15s and now it's ~6.85s. The result seems the same w/ or w/o using globals.
Just curious if that's expected with the recent improvements (one time ~400ms bump or ~400 per file) :)

I tried updating purepear/vitest-element-plus-debug from 0.27.3 to 0.28.1 and I noticed about 200-300ms speed improvement total - for 100 files it was previously ~7.15s and now it's ~6.85s. The result seems the same w/ or w/o using globals.

Isn't this a good result? 😄 Vitest creates 100 workers and runs all tests and it takes just 6.85s.
I run tests against Vitest tests, and they saw ~20% improvement with the PR, but we usually don't import anything besides Vitest. And our tests also run for ~7s without frontend frameworks like "element". I don't promise the same percentage gains in other projects 😄
I want to add a more robust debugging experience to Vitest, so it's easier to see the bottleneck in userland projects. Maybe we can see something that can be improved in Vitest, but as you pointed out the problem is usually in user dependencies (inlining and importing large dependencies takes a lot of time). Maybe we can bundle dependencies as Vite does?
I also noticed tests are running and stopping for ~1s, I already open an issue in tinypool, so maybe there is something to improve there.

Isn't this a good result? 😄 Vitest creates 100 workers and runs all tests and it takes just 6.85s.

I'm not saying it isn't 😆
I'm very grateful for you hard work 🙇 Thank you!
I was just double checking that I'm not missing on even better result.
My understanding was that in 0.27.3 Vitest was taking ~400ms to import itself in for each file/worker. I was thinking that in 0.28.0 this was not longer the case... but sounds like my understanding was wrong.
I added one more simple scenario (and multiplied the test 100 times):
/////////////////////////////// calc.js //////////////////////////////////
export function sum(a, b) {
  return a + b
}

/////////////////////////// 100 x calc.test.js //////////////////////////////
import { sum } from '@/calc'

test('sum works', () => {
  expect(sum(1, 2)).toBe(3)
})

To summarize my results so far, after updating to Vitest 0.28.1 (and aliasing the element-plus to the pre-bundled dist build):
100 x ElementButton.test.js: ~7.6s
100 x NativeButton.test.js:  ~6.8s (no big deps)
100 x calc.test.js:          ~6.5s (no big deps)

Looks like the bottleneck is the workers spin-off. 🤔

Looks like the bottleneck is the workers spin-off. 🤔

Just firing up a worker takes ~50ms. Importing files inside took around ~350ms. I found that we import the whole vite package there for each test file, which was very inefficient. Now overall it takes ~150ms. (First workers take longer to fire up). This is fixed in 0.28.3, can you check it?
There is also one possible improvement. Since firing up workers take more time initially, we might run faster tests first, but I didn't test it yet.

Thanks for all the incredible improvements you're doing lately, guys!!!
Turns out the simple "calc.test.js" runs with similar speed to the other component tests because the global Vitest environment was jsdom. (see my previous comment for the speed comparison)
This means that the bottleneck in these cases is mostly jsdom. I wonder if there're opportunities for improvements on importing/bootstrapping jsdom for each worker 🤔
Here are some results when running the 100 x calc.test.js for 2 versions and 2 environments on my machine:
Vitest 0.28.2
node: ~3.25
jsdom: ~6.5

Vitest 0.28.3
node: ~2.45
jsdom: ~5.30

As for the bigger real world project: updating to 0.28.3 shaved off about 3 seconds(from ~72s to ~69s).
But now I know that I need to change the environment to node in many non-component tests so that they don't bootstrap jsdom for no reason. (Or vice versa, set the global to node and set jsdom in component test... or use the environmentMatchGlobs option).
For example:
// @vitest-environment node

import { sum } from '@/calc'

test('sum works', () => {
  expect(sum(1, 2)).toBe(3)
})

This is a great thread to help debugging slow tests, which I just ran into. My time was almost entirely spent in transform/collect (7 tests in 5 files taking 6 seconds!!!).
The DEBUG envvar mentioned above is very helpful!
DEBUG=vite-node:* npm run test
From this, I saw that a library I import (svelte-heroicons) was basically re-importing hundreds of small icons, but this added up a lot - especially if it happens more than once.
I vaguely recall this from an issue I created a year ago, but forgot about. Not a huge deal during web dev, but a ridiculously huge deal during unit tests with testing-library/svelte.
Anyways, hope this can be of use to someone else.

@sureshjoshi same problem was seen at https://github.com/vitest-dev/vitest/issues/1861#issuecomment-1413419837.
In order to import a single icon from svelte-awesome-icons, all the +2000 Svelte files its entrypoint re-exported had to be run through Svelte compiler + all other transforms. By modifying the import statements to point to the exact file instead of the library entrypoint/barrel file, the whole 14 minute test run decreased to 4 minutes.

Thanks @AriPerkkio - that's a similar workaround proposed here: https://github.com/rgossiaux/svelte-headlessui/issues/107, but I think Prettier or ESLint or one of my styling tools has been changing them back to non-default imports 🤷🏽
The linked issues also seem to suggest that this shouldn't be an issue anymore with some Svelte/SvelteKit updates.
But thanks for the link!

@AriPerkkio Did you use a preprocessor to handle this for you? Or was it done manually? I have this problem with a couple libraries, and it feels like a preprocessor is a decent approach (kinda like what carbon does with optimizeImports).
Also, when running in the browser, Vite pre-bundles these large deps as of recently - so there isn't as much of a burden. is there some way vitest could do similar? Or, should it already be doing that - and I've just messed something up?

0.29.0 is out. This release adds deps.experimentalOptimizer. Please, try this flag if you have any performance issues. Don't forget to enable threads, if you used --no-threads before!
Any feedback concerning this flag should be published via new issues, NOT inside this issue. Thank you.

0.29.0 is out. This release adds deps.experimentalOptimizer option. Please, try this flag if you have any performance issues. Don't forget to enable threads, if you used --no-threads before!
Any feedback concerning this flag should be published via new issues, NOT inside this issue. Thank you.

I would highly argue that this flag is a solution vitest is still simply slow. Our previous setup with jest was taking around 30-40s and here, we're facing over 200s just to finish the same tests - and we don't really have any huge dependencies besides vue, vuex and moveable. We have around ~1500 tests to be run in 360 files, where we use snapshots & expectations. We really were pretty excited about moving onto vite with vitest but this seems simply unrealistic.
What's even more funny in this case -> with the flag enabled the tests are running even slower :)  The results with this flag on/off presented below.
With experimentalOptimizer: true ->  Duration  218.01s (transform 23.50s, setup 47.16s, collect 1850.54s, tests 48.56s)
With experimenalOptimizer: false ->  Duration  210.45s (transform 21.67s, setup 44.51s, collect 1764.43s, tests 49.67s)

Could it be, that the optimizer has issues with setup files? When I run the tests I get an error as following:

My setup file has the following imports
´´´ts
import 'vitest-localstorage-mock';
import { setupServer } from 'msw/node';
import matchers from '@testing-library/jest-dom/matchers';
import { fetch, Request, Response } from 'cross-fetch';
´´´
When I add vitest-localstorage-mock to the excludes, same error shows for 'msw/node' and so on. After all imports to the excludes
nearly all tests fail with

Just to be sure that I did not misunderstood anything I also tried to explicitly include those imports, but the error then remains the same as before.

Could it be, that the optimizer has issues with setup files? When I run the tests I get an error as following:
My setup file has the following imports
import 'vitest-localstorage-mock';
import { setupServer } from 'msw/node';
import matchers from '@testing-library/jest-dom/matchers';
import { fetch, Request, Response } from 'cross-fetch';

When I add vitest-localstorage-mock to the excludes, same error shows for 'msw/node' and so on. After all imports to the excludes
nearly all tests fail with
Just to be sure that I did not misunderstand anything I also tried to explicitly include those imports, but the error then remains the same as before.

Yes, there is a bug where it doesn’t include setup files (and node builtins). You can add it manually using „experimentalOptimizer.entries“ for now. There will probably be a release today or tomorrow.
Also, as I said before, please create separate issue when discussing experimental optimizer.

I turned on
deps: {
  experimentalOptimizer: {
    enabled: true,
  },
}

But there was an error
throw new Error(`ViteNodeServer: ${id} not found. This is a bug, please report it.`);

I have the same problem as @dmitriybo  with @mui/material

Any feedback concerning this flag should be published via new issues, NOT inside this issue. Thank you.

@marpro200 @dmitriybo @sheremet-va lets continue this specific topic ("ViteNodeServer: ${id} not found. This is a bug, please report it.") in #2940

I tested on my end with a different setup.
Many test files (5000)
1 test per test file
Repo: https://github.com/aurelienbottazini/test-js-test-runners
Jest finishes in 70 seconds on my computer
Vitest is very very slow (i end up canceling the task, tired of waiting) and test are progressively running slower and slower.
toward the end i even see slowness reports/warnings for each spec:

Running with --isolate=false is also very very slow
--isolate=false --single-thread=true is also very very slow

Running with --isolate=false is also very very slow

@aurelienbottazini this reproduction case seems to hit performance issue related to test reporter. See https://github.com/vitest-dev/vitest/issues/2602.
If you use --isolate false --reporter tap in your reproduction case the tests will execute fast.
~/x/test-js-test-runners/vitest  $ time npm exec vitest -- run --reporter tap --isolate false

TAP version 13
1..5000
ok 1 - test/sum.0.test.js # time=2.00ms {
    1..1
    ok 1 - adds 1 + 2 to equal 3 # time=0.00ms
}

...

ok 5000 - test/sum.999.test.js # time=0.00ms {
    1..1
    ok 1 - adds 1 + 2 to equal 3 # time=0.00ms
}

real    0m3.530s
user    0m7.545s
sys     0m1.565s

@AriPerkkio Really great to see the performance improvements from https://github.com/vitest-dev/vitest/pull/3006. Moving the 5000 test above from 5667.68s to 4.63s is huge!

I've noticed that one of the reasons why there is a difference between Jest and Vitest is the fact that Vitest imports jsdom for each test file which takes a lot of time (300ms on my M1 Mac to simply import jsdom). So one of my recommended solutions is to try to use happy-dom, which takes 3 times less to import.

Vitest imports jsdom for each test file

I guess it wouldn’t do it when testing pure node code? Does it mean that the issues discussed here do not apply to testing server code?

@adrian-gierakowski
Yep, it depends on the environment. You can check out my previous comment https://github.com/vitest-dev/vitest/issues/579#issuecomment-1406519409

I've noticed that one of the reasons why there is a difference between Jest and Vitest is the fact that Vitest imports jsdom for each test file which takes a lot of time (300ms on my M1 Mac to simply import jsdom). So one of my recommended solutions is to try to use happy-dom, which takes 3 times less to import.

Uff, that's a lot. I guess when you combine this with testing library, it really adds up.

Why not import jsdom or happy-dom once and reuse for all test files in need of it?

Hi guys!
Our project has a lot of files that are connected during the test (utils, components, openApi interfaces). Because of what, even one test takes a very long time (threads: true, isolate: true):
Duration  12.96s (transform 8.48s, setup 859ms, collect 10.01s, tests 528ms, environment 1.11s, prepare 151ms)

I run the test in debug mode with DEBUG=vite-node:* vitest and I see that vitest connects all the files one by one, it takes a lot of time:
vite-node:server:request /src/store/rootReducer.ts +43ms
2023-04-16T12:55:51.351Z vite-node:client:execute /home/pkolt/projects/moto_ui/src/store/rootReducer.ts
  vite-node:server:request /src/store/actionSession/index.ts +23ms
2023-04-16T12:55:51.357Z vite-node:client:execute /home/pkolt/projects/moto_ui/src/store/actionSession/index.ts
  vite-node:server:request /src/store/actionSession/slice.ts +6ms
2023-04-16T12:55:51.363Z vite-node:client:execute /home/pkolt/projects/moto_ui/src/store/actionSession/slice.ts
  vite-node:server:request /src/store/actionSession/types.ts +7ms
2023-04-16T12:55:51.369Z vite-node:client:execute /home/pkolt/projects/moto_ui/src/store/actionSession/types.ts
  vite-node:server:request /src/store/actionSession/thunks.ts +4ms
2023-04-16T12:55:51.378Z vite-node:client:execute /home/pkolt/projects/moto_ui/src/store/actionSession/thunks.ts
  vite-node:server:request /src/store/bankAccount/index.ts +10ms
2023-04-16T12:55:51.383Z vite-node:client:execute /home/pkolt/projects/moto_ui/src/store/bankAccount/index.ts
  vite-node:server:request /src/store/bankAccount/slice.ts +5ms
2023-04-16T12:55:51.389Z vite-node:client:execute /home/pkolt/projects/moto_ui/src/store/bankAccount/slice.ts
  vite-node:server:request /src/store/bankAccount/types.ts +7ms
2023-04-16T12:55:51.394Z vite-node:client:execute /home/pkolt/projects/moto_ui/src/store/bankAccount/types.ts
  vite-node:server:request /src/store/bankAccount/thunks.ts +3ms

Is it possible to merge the imported files into one so that Vitest does not waste time downloading them one by one?

SUMMARY
I've written up a summary of all the advice given in this GitHub Issue as a time saver for those coming here in the future.
Improving Vitest Performance

SUMMARY
I've written up a summary of all the advice given in this GitHub Issue as a time saver for those coming here in the future.
Improving Vitest Performance

--no-threads is outdated. If you want your tests to run in sequence without firing up new workers use --single-thread
--no-threads now uses child_process instead of workers, so your code might run even slower with it.

If a test that takes 30 seconds locally takes over 30 minutes on your server, the first thing you need to check is that the test is written correctly.
There seems to be something causing an infinite loop or timeout.

If a test that takes 30 seconds locally takes over 30 minutes on your server, the first thing you need to check is that the test is written correctly. There seems to be something causing an infinite loop or timeout.

After your comment, I realized there was a test with using vi.useFakeTimers, but it's strange that I didn't have any issues locally.
I ended up being able to make it work without any changes to the tests, using the option threads: false thanks to the issue I mentioned earlier.

I also noticed that after moving from Jest to Vitest, my tests were taking 2-3x more time to run.
After doing some experiments lately, one thing that drastically reduced the time to run all specs was to disable experimental fetch (NODE_OPTIONS='--no-experimental-fetch' yarn test). We currently use whatwg-fetch.
Before: 126.28s
After disabling experimental fetch: 53.05s

Vitest 0.34.0 is released with the new experimentalVmThreads flag which should make tests run as fast as they do in Jest. If you have any issues with the new pool, please open a separate issue instead of commenting here.

I updated the benchmark to use experimentalVmThreads, the results confirm the optimizations!
<EMAIL_ADDRESS>'yarn workspace bun test' ran
    1.37 ± 0.06 times faster than 'yarn workspace vitest test --isolate=false'
    1.72 ± 0.07 times faster than 'yarn workspace jasmine test'
    6.49 ± 0.[34](https://github.com/EvHaus/test-runner-benchmarks/actions/runs/5730584383/job/15529649956#step:6:35) times faster than 'yarn workspace jest test'
   11.50 ± 0.65 times faster than 'yarn workspace vitest test'

<EMAIL_ADDRESS>with experimentalVmThreads:true
'yarn workspace bun test' ran
  1.51 ± 0.05 times faster than 'yarn workspace jasmine test'
  5.53 ± 0.05 times faster than 'yarn workspace jest test'
  5.60 ± 0.05 times faster than 'yarn workspace vitest test --isolate=false'
  5.61 ± 0.05 times faster than 'yarn workspace vitest test'

The test previous ran in 101.259s but now runs in 60.171s, which is also identical to Jest's speed!
Side-note: Looks like using isolate:true together with experimentalVmThreads:true isn't a good idea (it makes the tests run much slower). I'm guessing it re-enables isolation due to threads being used.
I think based on this excellent new development we can probably close this ticket?

Looks like using isolate:true together with experimentalVmThreads:true isn't a good idea

isolate should have zero effect on vmThreads because they are always isolated (one context per test file), so I'm not sure what you mean 🤔
The fastest way to run tests is still using only --threads --isolate=false because there is only a single cache for all test files.

I think based on this excellent new development we can probably close this ticket?

We still need a way to run tests using VM inside the forked process to support process.chdir and test suites that fail when running inside worker because they rely on unstable low-level API. This is the next step.

So I'm guessing experimentalVmThreads:trueignores the isolate config value entirely.

Yes, it has no effect: https://vitest.dev/config/#isolate

Improved performance by 50% for me thanks for this

Conceptually, experimentalVmThreads is a separate runner (they are called pools in the codebase historically) from threads. We have several of them:

threads
child_process
browser
experimentalVmThreads

isolate only has an effect on the first three. The last one is always isolated because otherwise it becomes just a threads. If you need to disable isolation, do not use experimentalVmThreads.

We are using msw on React test and we are facing this issue when enabling experimentalVmThreads.
ReferenceError: Request is not defined
at FetchInterceptor. (/Users/mike/devel/web-app/node_modules/@mswjs/interceptors/src/interceptors/fetch/index.ts:42:13)
at step (/Users/mike/devel/web-app/node_modules/@mswjs/interceptors/lib/interceptors/fetch/index.js:59:23)
at Object.next (/Users/mike/devel/web-app/node_modules/@mswjs/interceptors/lib/interceptors/fetch/index.js:40:53)
at /Users/mike/devel/web-app/node_modules/@mswjs/interceptors/lib/interceptors/fetch/index.js:34:71
at new Promise ()
at __awaiter (/Users/mike/devel/web-app/node_modules/@mswjs/interceptors/lib/interceptors/fetch/index.js:30:12)
at globalThis.fetch (/Users/mike/devel/web-app/node_modules/@mswjs/interceptors/src/interceptors/fetch/index.ts:41:42)
at baseHttpService (/Users/mike/devel/web-app/src/utils/services/api.service.ts:70:35)
at Object.post (/Users/mike/devel/web-app/src/utils/services/api.service.ts:91:5)
at Module.queryFunctions (/Users/mike/devel/web-app/src/utils/services/api-query-functions.ts:155:56)

We are using msw on React test and we are facing this issue when enabling experimentalVmThreads.

I will ask this again: If you have any issues with the new pool, please open a separate issue instead of commenting here. In your case, jsdom doesn't provide Request, so it's not available. When not using --experimentalVmThreads, we don't isolate Node.js globals from JSDOM globals, they are just overridden on top of already existing Node.js globals. You need to provide these globals yourself when using --experimentalVmThreads.
I am locking this issue. Open new issues if you have problems when running --experimentalVmThreads with a reproduction.

vmThreads is out of experimental since Vitest 1.0, so I feel like this issue can be closed. A few suggestions on how you can improve the performance of your tests:

disable isolation if you don't need test-file isolation (Vitest won't reset module cache and changed global variables) - combine this with --poolOptions.threads.singleThread or --poolOptions.forks.singleFork to run all tests inside the same worker one after another which removes startup time completely
disable parallelism if your machine is not powerful enough
import functions directly from the module instead of a barrel file if you have one (don't use barrel files in general)
cleanup your setup files - remove imports that are non needed for every test
if you use a UI library with a lot of components, enable deps.optimizer.web.enabled and add it to deps.optimizer.web.include
try --pool=vmThreads or --pool=vmForks if your tests were faster in Jest


Try downgrading webmock to make content specs pass

We've seen some failures on the content repo content page specs and webmock looks like the only recently-updated related gem, so this is just testing the theory that it's affected the test suite in some way.
Reverting #943

Scratch this, there were successful builds after this was merged.


GameObjects seems to not able to be unparent completely (parent to root)

GameObjects seem unable to be completely unparented ( which means parent to Scene root), although I have recently added the code to have a dummy drop filed to the parent to root, and TreeExtension returns a pointer now. Please take a look, it would be great if it could be fixed.

Hi! You shoud have a look to the latest version of TreeExt in class_exercises_2024. There is code about how to reparent childs properly tested


chore: Remove proxy-setup health check

There are no sevices dependent on security-proxy-setup
finishing. Remove the health check.
Closes #17
Closes #27
Signed-off-by: Bryon Nevis<EMAIL_ADDRESS>

Schedule for Hanoi

@jpwhitemn @tingyuz Can we unfreeze this one now that Geneva release is cut?

@bnevis-i  I removed the hold label so that we can work on it.

@bnevis-i Need to rebase...

@lenny-intel Merged in master instead.  Make sure to squash marge it.

Thank you, @lenny-intel !


[Enhancement] Use issue templates

Providing some rudimentary issue templates can help rid a lot of the mess and annoyances with people complaining, asking for new releases, and allow to quickly get a good overview of what should be worked on, etc.
Bugs & enhancements belong in issues, everything else in the Telegram channel. Employ checkboxes, e.g.

[ ] This is an enhancement request, not a cry for help.

stale, pointless (issues are not being spammed with new posts any longer it seems)


Incompatibility between versions of TF and CUDA dynamic libraries

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 10 Enterprise 64 bit, version 10.0.17763
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): pip install tf-nightly-gpu
TensorFlow version: tf-nightly-gpu 2.4.0.dev20201019
Python version: 3.8.6
Installed using virtualenv? pip? conda?: Pip (in conda env)
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version: CUDA 11.1/cuDNN <IP_ADDRESS>
GPU model and memory: NVIDIA Quadro P5000 (16 GB)

Describe the problem
I installed MS Visual Studio Community 2019, CUDA (express installation) and, cuDNN, as per the respective instructions.
I created a new conda env with Python 3.8.6 and activated it. I installed tf-nightly-gpu using pip.
I launched Python and imported tensorflow, then listed GPU devices: all DLLs were found but one (cusolver64). The version of the library looked for by TF is 10 while CUDA 11.1 installs version 11.
Provide the exact sequence of commands / steps that you executed before running into the problem
`>>> import tensorflow as tf
2020-10-19 17:17:23.185914: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cudart64_110.dll

tf.config.list_physical_devices('GPU')
2020-10-19 17:17:44.311308: I tensorflow/compiler/jit/xla_cpu_device.cc:41] Not creating XLA devices, tf_xla_enable_xla_devices not set
2020-10-19 17:17:44.320150: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library nvcuda.dll
2020-10-19 17:17:44.361274: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1720] Found device 0 with properties:
pciBusID: 0000:65:00.0 name: Quadro P5000 computeCapability: 6.1
coreClock: 1.7335GHz coreCount: 20 deviceMemorySize: 16.00GiB deviceMemoryBandwidth: 269.00GiB/s
2020-10-19 17:17:44.373653: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cudart64_110.dll
2020-10-19 17:17:44.392056: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cublas64_11.dll
2020-10-19 17:17:44.397830: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cublasLt64_11.dll
2020-10-19 17:17:44.407985: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cufft64_10.dll
2020-10-19 17:17:44.417194: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library curand64_10.dll
2020-10-19 17:17:44.424211: W tensorflow/stream_executor/platform/default/dso_loader.cc:60] Could not load dynamic library 'cusolver64_10.dll'; dlerror: cusolver64_10.dll not found
2020-10-19 17:17:44.433236: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cusparse64_11.dll
2020-10-19 17:17:44.440903: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cudnn64_8.dll
2020-10-19 17:17:44.445862: W tensorflow/core/common_runtime/gpu/gpu_device.cc:1757] Cannot dlopen some GPU libraries. Please make sure the missing libraries mentioned above are installed properly if you would like to use GPU. Follow the guide at https://www.tensorflow.org/install/gpu for how to download and setup the required libraries for your platform.
Skipping registering GPU devices...
[]`

Any other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

I installed CUDA 10.2 over 11.1 and the problem seems to be resolved:
Python 3.8.6 | packaged by conda-forge | (default, Oct  7 2020, 18:22:52) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow as tf
2020-10-19 22:06:00.388483: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cudart64_110.dll
>>> tf.config.list_physical_devices('GPU')
2020-10-19 22:06:07.953857: I tensorflow/compiler/jit/xla_cpu_device.cc:41] Not creating XLA devices, tf_xla_enable_xla_devices not set
2020-10-19 22:06:07.963030: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library nvcuda.dll
2020-10-19 22:06:07.998966: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1720] Found device 0 with properties:
pciBusID: 0000:65:00.0 name: Quadro P5000 computeCapability: 6.1
coreClock: 1.7335GHz coreCount: 20 deviceMemorySize: 16.00GiB deviceMemoryBandwidth: 269.00GiB/s
2020-10-19 22:06:08.010311: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cudart64_110.dll
2020-10-19 22:06:08.029107: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cublas64_11.dll
2020-10-19 22:06:08.036516: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cublasLt64_11.dll
2020-10-19 22:06:08.049843: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cufft64_10.dll
2020-10-19 22:06:08.057249: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library curand64_10.dll
2020-10-19 22:06:08.068477: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cusolver64_10.dll
2020-10-19 22:06:08.078004: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cusparse64_11.dll
2020-10-19 22:06:08.084994: I tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library cudnn64_8.dll
2020-10-19 22:06:08.089183: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1862] Adding visible gpu devices: 0
[PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]

@gdrolet
Please move the issue to closed status as it is resolved.

Closed as resolved

@gdrolet Could you please provide the cusolver64_10.dll file. I have the same issue and will have to download the whole cuda toolkit but I have been facing some bandwidth issues lately. It would be a huge help.

@Akhilesh64 DLL is here until 11/12/2020:
https://transfert.mffp.gouv.qc.ca/?ShareToken=790B76CF0EBA6B094F39CF985247901B63D4AD19

@gdrolet You're a lifesaver thanks.

@gdrolet you are a hero man

While I am thankful for @gdrolet for providing a "solution" I do not like it one bit, because I simply do not understand how this solves the issue, also this is not really a "solution" but an incredible dirty one at best.
I am using a similar setup as the issue starter, however I am using a RTX 3090, which should be incompatible with CUDA 10 and lower. So I installed CUDA 11.1, the latest cuDnn version (all on Windows), switched to python 3.8 and the latest tf-nightly-gpu version.
I encountered the same issue as the OP, and I thought about the different methods described in similar issues (renaming the *_11.dll file that to the "10" version, downgrading although that should not work, etc), but then I simply decided to install 10.2 over the newer version.
This however WILL change the CUDA_PATH to the 10.2 version instead of the 11.1. The installation that does not have cudnn installed. In essence, tensorflow should have problems (it is incompatible with the RTX 3000 series GPUs and cudnn is missing). But it still does work. But I tested it with a few simple GAN training loops and everything looks in order.
So how is this the case? Am I overlooking something? Which of the two versions is actually used?
Also @Saduf2019 do you know when this is actually solved for real, meaning it looks for the correct cusolver64_11.dll instead of the 10 version? This solution is not a clean one and it might cause problems down the line. When you have blog posts such as that one struggling with TF on RTX 3000, one gets worried that their models and computations are not 100% correct or might produce giberish.

I noticed that the cusolver64_10.dll file transfer expired. Can you repost it @gdrolet?

@linuxmaster0312 here you go:
https://drive.google.com/file/d/1-3Yk-QZ1eUta1T40BaxFpO4uyn7BPU4o

for other people who may come across this and have v11 installed, I know it may not be a good solution but making a copy of cusolver64_11.dll and renaming it to cusolver64_10.dll seems to be working fine for me.

@jd1378  are you able to use tensorflow normally with your gpu?

no, it seems it was only working with a limited case, tried with another and it throws error. don't use it

Tried the cusolver64_10.dll  workaround which allowed me to import tensorflow nightly gpu and the system recognizes my GPu, but trying to run through the simple train_and_evaluate example notebook crashes with:
	 [[node model/dense_1/MatMul (defined at <ipython-input-6-69417c50baa2>:2) ]] [Op:__inference_train_function_706]

Function call stack:
train_function

and in the jupyter console:
2020-11-26 11:02:59.365169: E tensorflow/stream_executor/cuda/cuda_blas.cc:226] failed to create cublas handle: CUBLAS_STATUS_ALLOC_FAILED
2020-11-26 11:02:59.365208: W tensorflow/stream_executor/stream.cc:1455] attempting to perform BLAS operation using StreamExecutor without BLAS support
[I 11:03:15.022 NotebookApp] Saving file at /Tensorflow/train_and_evaluate.ipynb

This is a 3070 with cuda 11.1 and the tensorflow-nightly-gpu from pip (windows 10, python 3.8)

@astrowonk add this after importing all the libraries in you code
physical_devices = tf.config.list_physical_devices('GPU') tf.config.experimental.set_memory_growth(physical_devices[0], True)

For folks trying to use cuda 11.1, we recommend sticking to CUDA 11.0. That's the version we've built & tested against.

For folks trying to use cuda 11.1, we recommend sticking to CUDA 11.0. That's the version we've built & tested against.

CUDA 10 is too old for the latest Ampere cards, no? I was trying to test running on a gpu with a 3070.

@pkanwar23 that is not fully compatible  with rtx 30

@gdrolet
Please update if this is still an issue

@Saduf2019 The issue still persists.

I installed CUDA 11.2 and its respective cuDNN. When running:
import tensorflow as tf tf.config.list_physical_devices('GPU')
The .dll that is missing is cusolver64_10.dll. The CUDA installation doesn't have that .dll, it only has the *_11.dll. What I did was install the CUDA 10.2, leaving my CUDA_PATH pointing to my 11.2 installation and copied the file 'cusolver64_10.dll' from my CUDA 10.2 installation path; Which on Windows could be "%USERPROFILE%/Program files/NVIDIA GPU Computing Toolkit/CUDA/v10.2/bin/".
I'm not sure this solution is optimal, in the sense that would break things in your programs or models.
I would like to know if this solves your problem and is a good solution that won't break things.

@carlosscmx This should work. I did it in a similar way. My models (using custom training loops / steps) worked fine as well, nothing of note was encountered.

Exactly the same issue, haven't been able to try @carlosscmx  workaround.
CUDA 11.2
cuDNN 8.  (tried a few)
Tensorflow 2.4

I have  Windows 10 x64, CUDA 11.2, cuDNN 8, Tensorflow 2.4
I also have some problem
I solved it with copied file cusolver64_10.dll into C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.2\bin

Thanks @fshofmann copying the cusolver64_10.dll into C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.2\bin instantly solved it for me as well (without installing the dev version of tf-nightly gpu)

For folks trying to use cuda 11.1, we recommend sticking to CUDA 11.0. That's the version we've built & tested against.

I have a windows machine and tried to download CUDA 11.0 and CUDA 11.0-updated but the download links are broken (I could not download any of them). That is why I had to install CUDA 11.1 instead and I ran into the same issue as the others here.

I have a windows machine and tried to download CUDA 11.0 and CUDA 11.0-updated but the download links are broken (I could not download any of them).

Can you reach out to NVIDIA about this?  CC @nluehr

@Akhilesh64 DLL is here until 11/12/2020:
https://transfert.mffp.gouv.qc.ca/?ShareToken=790B76CF0EBA6B094F39CF985247901B63D4AD19

Hi, could you please share the dll?

@Akhilesh64 DLL is here until 11/12/2020:
https://transfert.mffp.gouv.qc.ca/?ShareToken=790B76CF0EBA6B094F39CF985247901B63D4AD19

Hi, could you please share the dll?

While I am thankful for @gdrolet for providing a "solution" I do not like it one bit, because I simply do not understand how this solves the issue, also this is not really a "solution" but an incredible dirty one at best.
I am using a similar setup as the issue starter, however I am using a RTX 3090, which should be incompatible with CUDA 10 and lower. So I installed CUDA 11.1, the latest cuDnn version (all on Windows), switched to python 3.8 and the latest tf-nightly-gpu version (from today. November 10th).
I encountered the same issue as the OP, and I thought about the different methods described in similar issues (renaming the *_11.dll file that to the "10" version, downgrading although that should not work, etc), but then I simply decided to install 10.2 over the newer version.
This however WILL change the CUDA_PATH to the 10.2 version instead of the 11.1. The installation that does not have cudnn installed. In essence, tensorflow should have problems (it is incompatible with the RTX 3000 series GPUs and cudnn is missing). But it still does work. But I tested it with a few simple GAN training loops and everything looks in order. I did some testing (deleting the DLLs that need to be loaded, sometimes from cuda 11, sometimes from version 10), because I know nothing about how loads the necessary dlls and because I thought the CUDA_PATH matters. Interestingly it does not. My TF installation still loads the DLLs from CUDA 11.1 (CUDA_PATH_V11.1) and then automatically goes into the 10.2 folder (CUDA_PATH_V10.2) to load the solver DLL.
For my own sanity's sake, I set the (normal) CUDA_PATH to version 11.1 because I am afraid other tools I use might use the wrong version.
Also @Saduf2019 do you know when this is actually solved for real, meaning it looks for the correct cusolver64_11.dll instead of the 10 version? This solution is not a clean one and it might cause problems down the line. When you have blog posts such as that one struggling with TF on RTX 3000, one gets worried that their models and computations are not 100% correct or might produce giberish.

Have you tried to train you model under this configuration? Does this works fine?

@NoahCSHN I faced the same issue and my models are pretty good. I can testify for that. I came looking for the issue everywhere. Whatever works, if it works its fine. Thanks to everyone.

@NoahCSHN Sorry for the very late reply (github issue notifications get easily buried in the inbox), but for other readers sake I can very much confirm that is does work indeed fine (as mentioned 4 months ago). Since last year I've done extensive evaluations of some of my models that were build using the sequential and functional keras API (custom training loops, my subclassed custom models were a mess due to other reasons) and the results do match what I expected.
At the moment I am a bit out of the loop when it comes to this issue, but I sure hope that we will get a clean solution this year :)

any updates? it's been 2 years after all. proposed solutions are better than nothing, but their hackiness level is not on par with the prestige TF+NVIDIA have in the ML world


Messed up video page controls/focus.

After first opening the video page any click on any of the control below (like show more replies in comment section) will reload the whole page. After that it will function somewhat properly but still not ideally. For example, typing in comment is a pain because every time you try to insert ' ' (hit space) the actually (un)pauses the video and not typing. Chrome 41

Regarding the space bar issue: Disable "Enable shortcuts on page" until this can be fixed. It is a known issue.

Thanks! This feature is named bad though. It's more like hotkeys. And it was translated wrong into my language with shortcut as in "file shortcut")

I discovered the cause for my "page reloading" issue.
YouTube doesn't enforce https for me so my main page with subscriptions was open in plain http => all videos I opened used http at first. But any click on comment section elements made the page reload into https.


Set type hints for parse and serialize to typing.Any

It's possible to use scalars for other types than str, f.ex. raw JSON with objects and/or lists or floats.
Given a scalar type that's not a pydantic class we might want to return a JSON serializable type like a dict or list from the serialize function.
Similarly we might want to accept such type when parsing it to our custom type.

We use custom scalars for raw JSON in some cases. Maybe this is a weird example but to demonstrate how this would be used.
# schema.graphql
scalar MyScalar

type Mutation {
  create(input: MyScalar!): String!
}

# query.graphql
mutation TestMutation($input: MyScalar!) {
  create(input: $input)
}

@dataclass
class SnowmanKeys:
    keys: list[str]
    value: str = "⛄"

MyScalar = SnowmanKeys

def serialize_my_scalar(value: MyScalar):
    return {k: value.value for k in value.keys}

[tool.ariadne-codegen.scalars.MyScalar]
type = "scalars.MyScalar"
serialize = "scalars.serialize_my_scalar"

With this setup, given the following code
await Client().test_mutation(input=SnowmanKeys(keys=["foo", "bar"]))

The generated GraphQL request would be
{
    'query': 'mutation TestMutation($input: MyScalar!) { create(input: $input) }',
    'variables': {
        'input': { 'foo': '⛄', 'bar': '⛄' }
    }
}

Do I understand correctly that your example works right now, but mypy produces error for serialize_my_scalar in scalars.py?

Yes and now! It's true that it works now but in fact not even mypy reports this, I think it's because the method call is resolved dynamically so mypy doesn't know the caller from the generated code.
The reason I wanted to change this was purely because I read the code as some form of documentation because it took me quote some time to figure out when these methods was call. It's still not fully clear to me if and how dataclasses and pydantic classes will be automatically (de)serialized without passing these methods or not so right now I'm basically using something similar to my example. Having the type hints set correct would've avoid confusion for me and also be more representative of reality.

Also this should be changed here as well.

Fixed!

The reason I wanted to change this was purely because I read the code as some form of documentation because it took me quote some time to figure out when these methods was call.

These methods are called in base_model.py - file attached to every generated client.

It's still not fully clear to me if and how dataclasses and pydantic classes will be automatically (de)serialized without passing these methods or not so right now I'm basically using something similar to my example.

The idea was like this:

If type is a bultin (eg. str, int...) then you don't need to provide serialize/parse methods
Similar to 1. if pydantic can handle type then again you don't need to provide serialize/parse methods (eg. dataclass, datetime.datetime etc.). You still can if you want to customize how type is treated, like in your example, from your method you will get {"key1": "⛄", "key2": "⛄"} instead of default {"keys": ["key1", "key2"], "value': "⛄"}.
If type is not handled by pydantic (eg. class MyCustomType:) then you need to provide parse and/or serialize.

While I was playing with your example a little bit, I found some inconsistency in implementation of 2. case, where we don't provide serialize, looks like right now we only support these "pydantic handled" types in results but not in inputs. I will address that in separate issue

@mat-sop Thanks for the explanation!
I'm starting to ponder if doing what I do in the example above is more abusing the serialize method but it's really convenient to be able to go straight from what the API serves to what I want to work with internally. This also seems to be what the example does with going from a - separated string to an internal class representation.
One actual use case that I have though is that I have an API that requires a field prefixed with __, let's call it __field. If I create a dataclass like this:
@dataclass
class MyScalar:
    __field: str
    another_field: str

Without a custom serialize method the generated request containing a MyScalar type would only contain another_field in the serialized output. So even though a simple class or dict can represent the type the default parsing and serialization will throw away fields I need. I'm not aware of a better way to solve this but maybe there's a better solution?
Either way I think since a scalar in GraphQL context isn't necessarily a string having the methods type hinted as typing.Any better represents custom scalars. Please let me know if you don't agree!

Please rebase on main branch


Compatibility check and testing for Responsive Design (materialize)

Notification from ioBroker Check and Service Bot
Dear Adapter developer,
ioBroker should be fully usable and operable on mobile devices
So please check your Materialize or React based Adapter for Responsive Design.
You can perform these tests in the developer console of your browser (F12).
Future additions and corrections to this issue will be published at the responsive-design-initiative repository. Please check https://github.com/iobroker-community-adapters/responsive-design-initiative?tab=readme-ov-file#responsive-design-initiative for updates.

For adapters in the Materialize design, important classes for the correct resolution should also be used for mobile devices.
List of classes for different display sizes:

lx - width in 1/12 of screen on large screens (1200px <= width < 1536px)
mx - width in 1/12 of screen on middle screens (900px <= width < 1200px)
sx - width in 1/12 of screen on small screen (600px <= width < 900px)

The recommended values for a <div> are as follows:
<div class="col s12 m6 l4">

The classes s,m and l must be configured in each <div>.
Custom css for the mobile resolution
If you use your own CSS styles in your adapters, you should define the necessary values for the mobile resolution in the area. The area must be listed as follows in the CSS:
/* Style for small Screens */
@media screen and (max-width: 768px) {
  here your input...
}

/* Style for very small Screens */
@media screen and (max-width: 600px) {
  here your input...
}

Integration of css and js files
It is also important that the following js and css files are included in index_m.html or tab_m.html
<!-- Load ioBroker scripts and styles -->
<link rel="stylesheet" type="text/css" href="../../lib/css/fancytree/ui.fancytree.min.css" />
<link rel="stylesheet" type="text/css" href="../../css/adapter.css" />
<link rel="stylesheet" type="text/css" href="../../lib/css/materialize.css">

<script type="text/javascript" src="../../lib/js/jquery-3.2.1.min.js"></script>
<script type="text/javascript" src="../../socket.io/socket.io.js"></script>

<script type="text/javascript" src="../../lib/js/materialize.js"></script>
<script type="text/javascript" src="../../lib/js/jquery-ui.min.js"></script>
<script type="text/javascript" src="../../lib/js/jquery.fancytree-all.min.js"></script>

<script type="text/javascript" src="../../js/translate.js"></script>
<script type="text/javascript" src="../../js/adapter-settings.js"></script>
<script type="text/javascript" src="words.js"></script>

Adapter-settings.js and adapter.css are very important for a responsive design. These files are provided and maintained by the admin.

Please close the issue after you checked it.
Feel free to contact me (@iobroker-bot) if you have any questions.
And THANKS A LOT for maintaining this adapter from me and all users.
Let's work together for the best user experience.
your
ioBroker Check and Service Bot
@simatec for evidence
Note: If you added Responsive Design tests already, simply close this issue.

This issue should not be considered stale.


generatejson.py number of parser arguments incorrect?

Hello! Sorry if I missed something, but on line 237 of generatejson.py it says
parser.add_argument('--item', default=None, action='append', nargs=6,
but then the code proceeds to require 7 arguments:
item-name='A name'
item-path='A path'
item-stage='A stage'
item-type='A type'
item-url='A url'
script-do-not-wait='A boolean'
pkg-skip-if='A string'
which for me leads to ValueError("length of metavar tuple does not match nargs").
If I updated nargs=7, the code works as expected and generates bootstrap.json in the output directory.
Should that be fixed or am I missing something here?

It could be a bug. I've merged some PRs lately that I personally haven't tested and trusted the author. If you have fixed it, please PR it and I'll merge.

I have it fixed in 100 so you can reference that or merge that piece.

I fixed it. Thanks for the note.


Error: Trying to access flag --preserve_unused_tokens before flags were parsed

I have been using the following code fine until this morning. I got an error for using bert.run_classifier.convert_examples_to_features(test_InputExamples, label_list, MAX_SEQ_LENGTH, tokenizer)
Please let me know how to fix it
import pandas as pd
import bert
from bert import run_classifier
from bert import optimization
from bert import tokenization
from tensorflow.contrib import predictor
import pkg_resources
pkg_resources.get_distribution("bert-tensorflow").version

input_words = "Hello"

DATA_COLUMN = "message"
LABEL_COLUMN = "category_label"

test = pd.DataFrame({DATA_COLUMN: [input_words], LABEL_COLUMN : [0]})

BERT_MODEL_HUB = "https://tfhub.dev/google/bert_uncased_L-12_H-768_A-12/1"

def create_tokenizer_from_hub_module():
  """Get the vocab file and casing info from the Hub module."""
  with tf.Graph().as_default():
    bert_module = hub.Module(BERT_MODEL_HUB)
    tokenization_info = bert_module(signature="tokenization_info", as_dict=True)
    with tf.Session() as sess:
      vocab_file, do_lower_case = sess.run([tokenization_info["vocab_file"],
                                            tokenization_info["do_lower_case"]])

  return bert.tokenization.FullTokenizer(
      vocab_file=vocab_file, do_lower_case=do_lower_case)

tokenizer = create_tokenizer_from_hub_module()

test_InputExamples = test.apply(lambda x: bert.run_classifier.InputExample(guid=None,
                                                               text_a = x[DATA_COLUMN],
                                                               text_b = None,
                                                               label = x[LABEL_COLUMN]), axis = 1)

# We'll set sequences to be at most 128 tokens long.
MAX_SEQ_LENGTH = 128
label_list = [6,1,2,4,3,5,0]
# Convert our test features to InputFeatures that BERT understands.
test_features = bert.run_classifier.convert_examples_to_features(test_InputExamples, label_list, MAX_SEQ_LENGTH, tokenizer)

Error:
INFO:tensorflow:Writing example 0 of 1
INFO:tensorflow:Writing example 0 of 1
UnparsedFlagAccessError: Trying to access flag --preserve_unused_tokens before flags were parsed.
---------------------------------------------------------------------------
UnparsedFlagAccessError                   Traceback (most recent call last)
<command-35675914> in <module>
     16 label_list = [6,1,2,4,3,5,0]
     17 # Convert our test features to InputFeatures that BERT understands.
---> 18 test_features = bert.run_classifier.convert_examples_to_features(test_InputExamples, label_list, MAX_SEQ_LENGTH, tokenizer)
     19
     20 input_ids_list = [x.input_ids for x in test_features]

/databricks/python/lib/python3.7/site-packages/bert/run_classifier.py in convert_examples_to_features(examples, label_list, max_seq_length, tokenizer)
    778
    779     feature = convert_single_example(ex_index, example, label_list,
--> 780                                      max_seq_length, tokenizer)
    781
    782     features.append(feature)

/databricks/python/lib/python3.7/site-packages/bert/run_classifier.py in convert_single_example(ex_index, example, label_list, max_seq_length, tokenizer)
    394     label_map[label] = i
    395
--> 396   tokens_a = tokenizer.tokenize(example.text_a)
    397   tokens_b = None

I got same error.

Hey, this is an error caused due to a recent version update in bert.
Change pip install bert to pip install bert==1.0.1
This will solve the error by installing the previous version.
You can use the previous version till the developers fix this issue.

Do you know when will it be fixed by the developer?

I am getting same error, any progress on this?

Hey, this is an error caused due to a recent version update in bert.
Change pip install bert-tensorflow to pip install bert-tensorflow==1.0.1
This will solve the error by installing the previous version.
You can use the previous version till the developers fix this issue.

Degraded the bert-tensorflow version, resolved!

For me, downgrading bert-tensorflow from 1.0.4 to 1.0.1 solved the issue.
I'm retraining a model from colab

Any news here? Downgrading can't be the final solution 🤔

For me, downgrading bert-tensorflow to 1.0.1 and downgrading tensorflow to 2.0.0 worked but w/ one work around.
context: after downgrading the libraries and running my script, error was thrown:     with tf.gfile.GFile(vocab_file, "r") as reader: AttributeError: module 'tensorflow' has no attribute 'gfile'
So to fix this, I edited the code in site-packages/bert/tokenization.py where gfile was being called and replaced it with with tf.io.gfile.Gfile(vocab_file, "r") as reader
it's not the cleanest, but it worked for me.

Hey, this is an error caused due to a recent version update in bert.
Change pip install bert-tensorflow to pip install bert-tensorflow==1.0.1
This will solve the error by installing the previous version.
You can use the previous version till the developers fix this issue.

Thanks, it helps a lot!

Is Google really using Bert in their search engine but ignoring updating it to TensorFlow 2.4? I have the error AttributeError: module 'tensorflow_estimator.python.estimator.api._v1.estimator' has no attribute 'TPUEstimator' and a search from Google led me here.

Is Google really using Bert in their search engine but ignoring updating it to TensorFlow 2.4? I have the error AttributeError: module 'tensorflow_estimator.python.estimator.api._v1.estimator' has no attribute 'TPUEstimator' and a search from Google led me here.

same issue

I'm having the exact same issue. When I try downgrading to 1.0.1 version I have this error :
with tf.gfile.GFile(vocab_file, "r") as reader: AttributeError: module 'tensorflow' has no attribute 'gfile'

Does anyone know any solution for this please ?

Hello Friends,
I had this issue with tf 2.8 and bert 1.0.4 as well. I just stick these lines before the offending call:
import sys
sys.argv=['preserve_unused_tokens=False']     #Or true, if you like
flags.FLAGS(sys.argv)

Hello Friends, I had this issue with tf 2.8 and bert 1.0.4 as well. I just stick these lines before the offending call: import sys sys.argv=['preserve_unused_tokens=False'] #Or true, if you like flags.FLAGS(sys.argv)
Cheers!

what is the 'flags' variable?

Trying to access flag --preserve_unused_tokens before flags were parsed.
im still stuck at this
downgraden not really impact to me

I set the flag manually. Not sure this is right but made my code work.
import sys
from absl import flags
sys.argv=['preserve_unused_tokens=False']
flags.FLAGS(sys.argv)

I set the flag manually. Not sure this is right but made my code work.
import sys
from absl import flags
sys.argv=['preserve_unused_tokens=False']
flags.FLAGS(sys.argv)

This fixes the issue

I set the flag manually. Not sure this is right but made my code work.
import sys
from absl import flags
sys.argv=['preserve_unused_tokens=False']
flags.FLAGS(sys.argv)

Hey thanks,it worked for me

Hello Friends, I had this issue with tf 2.8 and bert 1.0.4 as well. I just stick these lines before the offending call: import sys sys.argv=['preserve_unused_tokens=False'] #Or true, if you like flags.FLAGS(sys.argv)
Cheers!

thankyou,it fixes the issue


Fix broken build by adding a missing semicolon after a class property

Fix build issue :
SyntaxError: src/LazyLoad.jsx: A semicolon is required after a class property (13:2)
  11 |     visible: false,
  12 |   }
> 13 |   componentDidMount() {

@duvillierA What is your os? I have no errors when build project


Fixed wrong topic title in the outline

Category

[x] Content fix
[ ] New article
[ ] Example checked item (delete this line)

What's in this Pull Request?
Fixes a wrong topic title in the outline of the docs. Accidentally there was the same title for two different topics.

thx @PaoloPia, appreciated.


Merge refs/heads/temp-branch-6404137664 into alpha

Merge refs/heads/temp-branch-6404137664 into alpha

This PR has been merged into alpha. Thanks for your contribution!

This PR has been merged into alpha. Thanks for your contribution!


OS-190

Enabled a way using google-junit toolbox to automatically pick up all *Test.class from any package.
Added Ignore annotation for certain files that have undergone rapid changes since 1.0.0
For the registry module, the resources folder can mean both main\resources and test\resources. Apparently it looks like the resource count is double so (even though they are not copied). Hence, I've modified a test case.
Added a jacoco-check and kept a min of 15% coverage per bundle (even at package level we are easily not meeting - requires some thought on package usages).
Status as of today

Element
Missed Instructions
Cov.
Missed Branches
Cov.
 Closing and pushing directly to release.


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Runtime warning in FPRNSURLSessionInstrument when running on iOS 17 RC built with Xcode 15 RC

Description
Similar to https://github.com/firebase/firebase-ios-sdk/issues/11536, a runtime warning as below occurs when running on iOS 17 RC built with Xcode 15 RC.
Warning:
The request of a upload task should not contain a body or a body stream, use `upload(for:fromFile:)`, `upload(for:from:)`, or supply the body stream through the `urlSession(_:needNewBodyStreamForTask:)` delegate method.

Code:
/** Instruments -uploadTaskWithRequest:fromData:.
 *
 *  @param instrument The FPRNSURLSessionInstrument instance.
 *  @param instrumentor The FPRClassInstrumentor to add the selector instrumentor to.
 */
FOUNDATION_STATIC_INLINE
NS_EXTENSION_UNAVAILABLE("Firebase Performance is not supported for extensions.")
void InstrumentUploadTaskWithRequestFromData(FPRNSURLSessionInstrument *instrument,
                                             FPRClassInstrumentor *instrumentor) {
    ...
    NSURLSessionUploadTask *uploadTask =
        ((OriginalImp)currentIMP)(session, selector, request, bodyData); // This line causes the warning
    if (uploadTask.originalRequest) {
      FPRNetworkTrace *trace =
          [[FPRNetworkTrace alloc] initWithURLRequest:uploadTask.originalRequest];
      [trace start];
      trace.requestSize = bodyData.length;
      [trace checkpointState:FPRNetworkTraceCheckpointStateInitiated];
      [FPRNetworkTrace addNetworkTrace:trace toObject:uploadTask];
    }
    return uploadTask;
  }];
}

Reproducing the issue
Run an app and check the runtime warnings on Xcode.
Firebase SDK Version
10.9.0 (also occurred with 10.15.0)
Xcode Version
15.0 (15A240d)
Installation Method
Swift Package Manager
Firebase Product(s)
Analytics, App Distribution, Authentication, Crashlytics, DynamicLinks, Performance
Targeted Platforms
iOS
Relevant Log Output
The request of a upload task should not contain a body or a body stream, use `upload(for:fromFile:)`, `upload(for:from:)`, or supply the body stream through the `urlSession(_:needNewBodyStreamForTask:)` delegate method.

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

Yeah same on ios 17.0

I can see exactly the same warning here.
App crash rating increases, not sure related to it or not.

@skywalkerlw The fix is staged for our next 10.16.0 release planned for next week.

We are still seeing this warning in 10.16.0 - did the fix get released with this change?

The fix got deployed in the InstrumentUploadTaskWithRequestFromData function, but it looks like the same issue is still in InstrumentUploadTaskWithStreamedRequest.
thanks for the report. We'll put this on this list for the next release.


2406 error

I get the 2406 error but the access id and key are correct, the project and tuya account have been created on 24 June and I've updated the plugin today to the latest version 1.2.1.

I also get this error and I'm not sure how to proceed -- I created my project/key yesterday and have confirmed that the values are exactly correct in my config.

@gjs12 your screenshot above includes your password in the debug output -- you probably want to redact that

No, it is some  replacement code. The logs don't show the actual passwords and secret keys

Hi @gjs12 @shamanskyh , logs already protect important information.
We observed a problem with the data in Australia, which has now been fixed. If your configuration is correct, you can restart the plugin and try again

Hi @gjs12 @shamanskyh , logs already protect important information.
We observed a problem with the data in Australia, which has now been fixed.And your cloud project Availability Zone needs to be located in Europe , If your configuration is correct, you can restart the plugin and try again

Hi Hanh94, still the same issue unfortunately.

@gjs12 could you check if your IoT cloud project is created after May 25th, 2021? Your cloud project's Availability Zone needs to be Europe, as your region is Australia (country code 61).

The error code is 2406, please check the last faq of the doc: https://developer.tuya.com/en/docs/iot/Tuya_Homebridge_Plugin?id=Kamcldj76lhzt
Troubleshoot:

Your cloud project on the Tuya IoT Platform should be created after May 25, 2021. Otherwise, you need to create a new project or migrate data to a new project. For more information, see Operation on the Tuya IoT Platform.
On the Tuya IoT Platform, you have linked devices by using Tuya Smart or Smart Life app in your cloud project.

Yes, my cloud project was created on 24 June 2021 and I used the Tuya smart app to link my devices in the app and they do show up in the Europe zone in my project's devices list, a power plug and a motion sensor. I'm also using the correct username and password, I've checked it multiple times.

Hey folks -- I think I've resolved this issue for myself and thought I'd share what I learned here in case it's helpful.
In my cloud project, the only availability zone I had selected was "America" and I set my country code my config.json to 1. Adding "Eastern America" to my availability zones seems to have solved the authentication issue for me.

Hi @shamanskyh @gjs12 ,Sorry for the late reply.
Recently, our team has been sorting out interface issues such as code 2406.
The same country code for Tuya SmartLife apps on different phones may correspond to different Availability zones.
Therefore, we recommend that you select all available Availability Zones in the cloud project, and we will improve the plugin login experience as soon as possible.
Hope this doc has been helpful: https://developer.tuya.com/en/docs/iot/Tuya_Homebridge_Plugin?id=Kamcldj76lhzt. Any questions, please contact us.

Hi @Hanh94, I've added all zones to the availability zones but so far hasn't made a difference.

Hi @Hanh94, I've added all zones to the availability zones but so far hasn't made a difference.

Hi @gjs12 ,Sorry for the late reply.
The login error code 2406 only has two cases:
1.Use accessID and accessKey that were created before May 25, 2021.
2.The project created is after May 25, 2021, but there is no associated Tuya smart or Smart Life APP account.
Please check your configuration and contact us if you have any questions.

Hi @Hanh94, something must have changed at the back end as it is working now. The power plug is showing up, not the motion sensor but that might be because it is not supported (yet).

Hi @Hanh94, something must have changed at the back end as it is working now. The power plug is showing up, not the motion sensor but that might be because it is not supported (yet).

Hi @gjs12 , The categories we currently support.

Hi @Hanh94, something must have changed at the back end as it is working now. The power plug is showing up, not the motion sensor but that might be because it is not supported (yet).

Hi @gjs12 , Regarding Device Support, please submit a New Device Support issue.
If there are no problems with error code 2406 for login, the issue will be closed. Thank you for your contribution.


⚠ Bofrost.lu has degraded performance

In 91988e1, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2387 ms

Resolved: Bofrost.lu performance has improved in b933199 after 6 minutes.


Can you comment on version compatibility?

Apologies if I've missed any documentation around this but can someone comment on which versions of Kubernetes/EKS are compatible with which versions of aws-alb-ingress-controller?
Specifically, I'm wondering if for example the version of ingress-controller should match K8s version? I'm asking because I'm running into the following issue:
1 controller.go:217] kubebuilder/controller "msg"="Reconciler error" \
"error"="failed to get web acl for load balancer arn:aws:elasticloadbalancing:us-west-2:114169298763:loadbalancer/app/66655845-default-springboo-bf49/5e0da9a111425711: AccessDeniedException: \
User: arn:aws:sts::112233445566:assumed-role/eksctl-ra-addon-iamserviceaccount-kube-syste-Role1-CSAMS7XALXQ8/1588915308237680554 \
is not authorized to perform: waf-regional:GetWebACLForResource on resource: \
arn:aws:waf-regional:us-west-2:112233445566:*/* with an explicit deny\n\tstatus \
code: 400, request id: c9cdedba-a6d2-4623-8019-febe18e3f170"  "controller"="alb-ingress-controller" \
"request"={"Namespace":"default","Name":"springboot-microservice-ingress"

I'm current running (not quite) the following versions and curious to know with confidence that aws-alb-ingress-controller is backwards compatible with older versions of Kubernetes.
Kubernetes: 1.15
EKS platform: eks.2
aws-alb-ingress-controller: 1.17
region: us-west-2

Thanks!

I don't believe it's due to your Kubernetes version. It's actually a new IAM permission required by v1.1.7. See the v1.1.7 release notes.
Frankly, I find this kind of change to be hostile to users. The expectation should be that a PATCH version change from 1.1.6 to 1.1.7 wouldn't have any breaking changes.

I did see the IAM permission change and had added that but didn't turn out to be the issue.
I eventually got it to work and wasn't a version incompatibility (afaik). What it ended up being in my case was a missing annotation in the service.yaml:
alb.ingress.kubernetes.io/target-type: ip

/close


Refactoring detection status test

Part of #1830

Add generated analyzer report (plist) files and source files to the repository. This way no need to call analyzer related commands of CodeChecker in this web specific tests.

This requires huge refactoring and we don't want to do this now. For this reason I close this ticket.

This requires huge refactoring and we don't want to do this now. For this reason I close this ticket.


[9.x] Collection get() allows to get nested data using dot notation

What?
Since my last PR #42938 was shot down (probably too big), this brings the ability to use get() con Collections to retrieve deeply nested data using "dot" notation.
$collection = collect([
    'fred' => ['id' => 99, ...]
    ...
]);

// Before
data_get($collection, 'fred.id');

// Now
$collection->get('fred.id');

data_get() also works with numeric indexes, like 0.id.

BC?
None. Users that expects array keys using dots are on a world of pain anyway.

I think I'm gonna rework this using a dumber-down version for building JSON.

@DarkGhostHunter Was there a specific breaking reason why this never got merged?

@DarkGhostHunter Was there a specific breaking reason why this never got merged?

get() is used to retrieve an item by their key. Seems that if a key has dots then is a BC.
This could be refactored by dataGet() instead.


[Parse] Fix SIL-deserialization

Hi Apple,
This is a minor follow-up to https://github.com/apple/swift/pull/17788 to reinstate the ability to de-serialize SIL in the Lexer. You may also need to specify the -assume-parsing-unqualified-ownership-sil flag but it should work now.
Thanks.

At the moment master is unable to compile from SIL as $ on it’s own is no longer allowed as an identifier since last summer whereas it is required in SIL.


HostedCluster Basic Immutability

Add immutability to the easier types in the API.

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/hold
please let's review a ship https://github.com/openshift/hypershift/pull/2148 and follow up if needed.

Duplicated..


Display Jitter

Trippy current calculates the StDev column as:
pub fn stddev_ms(&self) -> f64 {
    if self.total_recv > 1 {
        (self.m2 / (self.total_recv - 1) as f64).sqrt()
    } else {
        0_f64
    }
}

Where, for each successful Probe (for a given hop ttl), the total_recv, mean and m2 values are updated as follows:
let dur = probe.duration();
let dur_ms = dur.as_secs_f64() * 1000_f64;
hop.total_recv += 1;
hop.mean += (dur_ms - hop.mean) / hop.total_recv as f64;
hop.m2 += (dur_ms - hop.mean) * (dur_ms - hop.mean);

We would like to add support for a Jitter columns similar to those provided by mtr (see https://networkengineering.stackexchange.com/questions/5288/what-is-interarrival-jitter-in-mtr)

I am taking this issue on my existing fork.  I will be working towards a PR for review by EOW.

Here's a proposal for the feature after taking a look at the code. The calculation requires at least 2 round trips to be completed for each hop.  The millis Duration value from consecutive hops (HOPn - HOPn-1) results in jitter duration.
Calc: Jitter = RTTn - RTTn-1
RTT = Round trip time

Add --jitter -j option for the command line.  Starts up in jitter display mode.
Headings will have a "J" prepended in the display.
Add values to any reporting like csv.
Might need jitter mode to Mode enum tui-jitter.
Stretch - When tui display is running pressing "j" will switch to jitter mode.  This comes from having used mtr in the passed.

Am I overthinking it should I scale it back?

@trkelly23 thanks for picking this up!

Add --jitter -j option for the command line. Starts up in jitter display mode.
Headings will have a "J" prepended in the display.

Which headings would be prefixed?  I had imagined these jitter related values as additional columns in the hops table, is that what you are proposing?
Is the proposal that these columns would be calculated and/or shown only if the --jitter (-j) flag is specified?  While I think that is fine, what do you think about doing https://github.com/fujiapple852/trippy/issues/757 first or along with this change so that the selection of columns to show can be more flexible?

Add values to any reporting like csv.

Yes that makes sense, we should add to all report modes.

Might need jitter mode to Mode enum tui-jitter.

Right, similar to --tui-as-mode we may want a --tui-jitter-mode or similar to control how jitter is displayed in the Tui.  It could be as simple as a bool to turn jitter display on/off or an enum to give finer control of which columns are shown.  Just to be clear, I don't think a new --mode tui-jitter is needed here however.

When tui display is running pressing "j" will switch to jitter mode. This comes from having used mtr in the passed.

Yes that would be useful.  It shouldn't be to difficult to add as there are several other such things in the Tui already, such as pressing z to toggle the AS display mode.  I can always help you with this part if needed.

The calculation requires at least 2 round trips to be completed for each hop. The millis Duration value from consecutive hops (HOPn - HOPn-1) results in jitter duration.
Calc: Jitter = RTTn - RTTn-1
RTT = Round trip time

I just had a look in mtr and, whilst we don't need to restrict ourselves to doing things the same way, it does serve as a useful reference point.
It allows specifying these additional (non-default) columns:
Jttr: Current Jitter
Javg: Jitter Mean/Avg.
Jmax: Worst Jitter
Jint: Interarrival Jitter

It would be useful to look at how these are calculated and aim to emulate the logic here.  From a quick glance they seem more complex than simply RTTn - RTTn-1 Though I must confess statistics is not my area of expertise!

I have been working on the calculations for Jitter and wrote up a little test file with tests to validate.  After checking mtr code and description of jitter per the spec RFC-3550 I was able to create a spreadsheet to calculate the values and code to calculate.  The Jitter struct is for test purposes and these fields would go into Hop.  Note the cumulative average calculation I'm using may have uncovered a bug in the hop.mean calculation.
Please, take a look at the calculation approach.
jitter.txt
The above file changed to .txt .rs not allowed.

Note the cumulative average calculation I'm using may have uncovered a bug in the hop.mean calculation

Can you give some more details on the potential bug?
Aside from the fix I did in commit 4e90da79f7af2511dd03f7bb8377b2a8953f3cac (April 2022) the logic seems to have been the same since the very beginning.  I don't recall what prompted me to fix that, I suspect I was doing a side-by-side comparison with MTR and was correcting for a divergence between the output.
I can't remember exactly, but I believe this may have been my translation of Welford's online algorithm for computing variance on a stream of data in a single pass (note the use of m2 in that algorithm and my original code).

Please, take a look at the calculation approach

I've had a look but I may not be understand correctly.  Parsing at the code and paraphrasing, it seems the calculation you have are:
Javg:
Javg = ((Javg * total_recv) + dur_ms) / total_recv

Jint:
Jint = abs(dur_ms - Javg)

Jmax:
Jmax = max(Jmax, dur_ms)

The last one seems more like an overall max/worst calculation, rather than a mac/worst jitter calculation?
I don't see the basic Jttr calculation, unless that is what value is supported represent?  That seems to be simply using dur_ms which doesn't seem right if so?
How do these calculations compare to the logic in MTR?  Maybe best to impl these on a branch and do a side-by-side comparison?

I put a PR up after taking a look at Welford's calculation and a few stats sites.  I see now the avg can be calculated if you have the total number in the dataset,  the current avg & the new value.  Nice much less processing and overhead.
I also verified the Jitter average (javg) is cumulative according to mtr.
As you said best to move the conversation to a PR.
Thanks for all the feedback and happy holidays! 🎅

Thanks and happy holidays to you as well.
I haven't had a chance to look at the code yet but let me know if you are doing any other calculations that are not "streaming friendly" and I can take a look as I still remember a lot of those I learned in school of which mean is one (the one you already found).


Incorporate serializer_id added in 1.3.1 into main SQL DDL

The content for the CREATE TABLE statements hasn't been updated for 1.3.1, and it isn't clear that one must apply the 1.1.0 to 1.3.1 migration after executing the main script.  This commit brings the main SQL script up to 1.3.1 so that when executed, no additional migration is necessary.

@gmcelhanon sorry for the delay on this - not sure why CI didn't pick these changes up. But since this is just the README, looks good to me.


Simplify Encoder module

This PR simplifies the Encoder conversion to align it with how the Decoder is being handled at the moment.
I think this also makes the code easier to follow as it more closely resembles the actual img2img Diffusers' pipeline.
#########

[x] I agree to the terms outlined in CONTRIBUTING.md

Thanks @GuiyeC ! I tested this PR with --model-version stabilityai/stable-diffusion-2-1-base. Model conversion and text-to-image pipelines work as expected. image-to-image pipeline test failed because the VAEEncoder.mlmodelc was expecting and input with [1, 3, 768, 768] whereas the input image was of shape [1, 3, 512, 512]. I left a comment on the diff to resolve this issue. Please let me know when you get to address it.


Refactor MVDR module

Use apply_beamforming, rtf_evd, rtf_power, mvdr_weights_souden, mvdr_weights_rtf methods under torchaudio.functional to replace the class methods.
Refactor docstrings in PSD and MVDR.
Put _get_mvdr_vector outside of MVDR class as it doesn't call self methods inside.

The Si-SDR results in the built MVDR tutorial page https://output.circle-artifacts.com/output/job/18b76d8c-987c-46c2-93ba-56c9fe06f89d/artifacts/0/docs/tutorials/mvdr_tutorial.html
is the same as those in the stable version in https://pytorch.org/audio/stable/tutorials/mvdr_tutorial.html

since MVDR uses einsum for matrix operations, packing and unpacking batches are not necessary. It can be tested by the batch_consistency_test.

since MVDR uses einsum for matrix operations, packing and unpacking batches are not necessary. It can be tested by the batch_consistency_test.

Can you update the PR description to include this?


[RELEASE-1.8] Self contained containerfiles for serving images

Cherry-pick of https://github.com/openshift-knative/serving/pull/118

/lgtm
/approve