Jest encountered an unexpected token

Issue :
I am using ts-jest to test my typescript library. When I run jest, I get the following error:
Jest encountered an unexpected token

    This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript.

    By default, if Jest sees a Babel config, it will use that to transform your files, ignoring "node_modules".

    Here's what you can do:
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/en/configuration.html

    Details:

    /Users/mohsinulhaq/Documents/react-popper-tooltip/tests/TooltipTrigger.spec.tsx:9
    const BasicTooltipTrigger = ({ tooltip, children, hideArrow, ...props }) => (<src_1.default {...props} tooltip={({ getTooltipProps, getArrowProps, placement }) => (<div {...getTooltipProps({
                                                                                ^

    SyntaxError: Unexpected token <

      at ScriptTransformer._transformAndBuildScript (node_modules/jest-runtime/build/script_transformer.js:403:17)

Here is my jest.config.js:
module.exports = {
  preset: 'ts-jest',
  globals: {
    'ts-jest': {
      diagnostics: false
    }
  }
};

and my babel.config.js:
module.exports = {
  presets: ['@babel/typescript', ['@babel/env', {loose: true}], '@babel/react'],
  plugins: [['@babel/proposal-class-properties', {loose: true}]]
};

In my package.json, I do have jest, ts-jest, babel-jest and<EMAIL_ADDRESS>installed.
Please help.
Thanks.
EDIT: I get the same output with the babel config file removed. Looks like ts-jest is not picking the babel config file up.

The only issue, when I run a project it changes jsx back to preserve

The only issue, when I run a project it changes jsx back to preserve

@zishe i was seeing the same issue. I ended up creating a tsconfig.json and a tsconfig.test.json. the latter extends tsconfig.json and changes compilerOptions.jsx to be react.
then i added this to my jest config:
   globals: {
      'ts-jest': {
        tsConfig: 'tsconfig.test.json'
      }
    }

The only issue, when I run a project it changes jsx back to preserve

@zishe i was seeing the same issue. I ended up creating a tsconfig.json and a tsconfig.test.json. the latter extends tsconfig.json and changes compilerOptions.jsx to be react.
then i added this to my jest config:
   globals: {
      'ts-jest': {
        tsConfig: 'tsconfig.test.json'
      }
    }

thanks, this worked for me.

I have since switched to babel-jest + @babel/preset-typescript, which seems to be a much better and well-supported alternative.

yeah if you haven't got any mind blowing issues with that stack go ahead. Looks like TypeORM doesn't want to work with babel stack.

I had a similar problem. Exact problem was this:
    Details:

    SyntaxError: useHover_test.tsx: Unexpected token (8:53)

       6 |
       7 | const DummyComponent: React.FC = props => {
    >  8 |   const [ref, isHovering] = useHover<HTMLDivElement>();
         |                                                      ^
       9 |   return
{isHovering && props.children}
;
      10 | };
      11 | describe('useHover', () => {

I'm using babel 7 and jest 24.9. Changing .babelrc to babel.config.js didn't resolve the problem. Content of the file was:
module.exports = function(api) {
  api.cache(true);
  return {
    presets: [
      [
        '@babel/preset-env',
        {
          targets: {
            browsers: [
              'last 2 Chrome versions',
              'last 2 Edge versions',
              'last 2 Firefox versions',
              'last 2 Safari versions',
              'IE 11',
            ],
          },
          loose: true,
          modules: false,
          useBuiltIns: 'usage',
          corejs: {
            version: 3,
            proposals: true,
          },
        },
      ],
      '@babel/preset-react',
      '@babel/preset-flow',
    ],
    plugins: [
      '@babel/plugin-transform-spread',
      '@babel/plugin-syntax-dynamic-import',
      [
        '@babel/plugin-proposal-class-properties',
        {
          loose: false,
        },
      ],
    ],
    ignore: ['node_modules'],
    overrides: [
      {
        test: ['./src/**/*.ts', './src/**/*.tsx'],
        presets: [
          '@babel/preset-typescript',
          [
            '@babel/preset-env',
            {
              targets: {
                node: 'current',
              },
            },
          ],
          '@babel/preset-react',
        ],
      },
    ],
    env: {
      test: {
        plugins: ['babel-plugin-rewire-ts'],
        presets: ['@babel/preset-env', '@babel/preset-react'],
      },
    },
  };
};

The problem in it was missing @babel/preset-typescript in env. I changed it to
    env: {
      test: {
        plugins: ['babel-plugin-rewire-ts'],
        presets: ['@babel/preset-typescript', '@babel/preset-env', '@babel/preset-react'],
      },
    },

you should have used ts-jest transformer. If you use babe-jest in transform config you don't use ts-jest so you don't need it in your dependencies

all I had to do to fix this was create a file jest.config.js with the contents of:
module.exports = {
  preset: 'ts-jest'
};

while having also installed ts-jest

@jubairsaidi I just want to add onto this, if you have anything in the transform object, remove it.
I originally had this which was causing problems with `preset: "ts--jest"
  transform: {
    // "^.+\\.(js|ts|jsx|tsx)$": "<rootDir>/node_modules/ts-jest", << removed
    "^.+\\.css$": "<rootDir>/config/jest/cssTransform.ts",
  },

I was able to get the JS node module with the offending import statement transpiled by doing:

Explicitly tell jest to include it:

"transformIgnorePatterns": [
  // Change MODULE_NAME_HERE to your module that isn't being compiled
  "/node_modules/(?!MODULE_NAME_HERE).+\\.js$"
]

and use the js-with-ts preset:
module.exports = {
  testEnvironment: "node",
  preset: "ts-jest/presets/js-with-ts",
  transformIgnorePatterns: ["/node_modules/(?!@apollo/client).+\\.js$"],
};

same error again in another project
node_modules\jest-config\build\readConfigFileAndSetRootDir.js:110
const importedConfig = await import(configUrl.href);
SyntaxError: Unexpected token import
at new Script (vm.js:51:7)
at createScript (vm.js:136:10)
at Object.runInThisContext (vm.js:197:10)
at Module._compile (module.js:613:28)
at Object.Module._extensions..js (module.js:660:10)
at Module.load (module.js:561:32)
at tryModuleLoad (module.js:501:12)
at Function.Module._load (module.js:493:3)
at Module.require (module.js:593:17)
at require (internal/module.js:11:18)
npm ERR! Test failed.  See above for more details.
:-(
Cant get it running with typescript and different presets....

same error again in another project
node_modules\jest-config\build\readConfigFileAndSetRootDir.js:110
const importedConfig = await import(configUrl.href);
SyntaxError: Unexpected token import
at new Script (vm.js:51:7)
at createScript (vm.js:136:10)
at Object.runInThisContext (vm.js:197:10)
at Module._compile (module.js:613:28)
at Object.Module._extensions..js (module.js:660:10)
at Module.load (module.js:561:32)
at tryModuleLoad (module.js:501:12)
at Function.Module._load (module.js:493:3)
at Module.require (module.js:593:17)
at require (internal/module.js:11:18)
npm ERR! Test failed. See above for more details.
:-(
Cant get it running with typescript and different presets....

I had the same error with 9.11.2 node version.
Was able to resolve it by update to 13.1.0.

For anyone still getting this error after reading all the responses above, this helped fix it for me.
I'm only using ts-jest, without any babel dependencies whatsoever in my package.json.

 It worked for me. If it is incorrect, please explain my mistake.
.babelrc
{
  "env": {
    "development": {
      "presets": ["next/babel"]
    },
    "production": {
      "presets": ["next/babel"]
    },
    "test": {
      "presets": ["next/babel"]
    }
  }
}

Most important was the test setting.

Wrestled with this error and finally got ts-jest to work in my project.  To do so, I created a bare bones repo, got it working there, and then applied what I learned to my project.  To summarize:

In tsconfig.json, I had to change "jsx": "preserve" to "jsx": "react"
After I made that change, I had to run yarn jest --clearCache as @ahnpnl  mentioned.  Without this step, it the unexpected token error would still to occur whenever I ran tests.

Here is the bare bones repo for anyone that's interested.  It's using testing-library/react, but it should work with other packages.  Also note, it doesn't rely on babel.

Thank you very much @arteforme !!!!!!!!!!!

Any reason why this bug still exists? I tried everything and its still not working, I can't get ts-jest to work at all, if I import another typescript repo. Jest really needs to have TypeScript support out of the box, with 0 configuration. At this points its just as difficult to setup like Mocha/Chai

@joshuarobs jest does support TypeScript out of the box via babel. It is just create-react-app making it hard to adjust. If you setup jest from scratch on a project not using any frameworks, it's pretty easy and straight forward.
You can also check my repo for the setup https://github.com/ahnpnl/react-ts-jest-babel with React.

@ahnpnl
I tried your repo and tried importing another of my private typescript module and it worked fine, but I can't make it work with Create React App. I'm not sure if I'm meant to use ts-jest or babel to make it work with CRA, or if its even possible in the first place to make CRA work with typescript and jest (and external typescript library imports)

@joshuarobs  I dont know how to setup for create-react-app without ejecting the project. My repo is create-react-app after ejecting. If you don't want to eject your project, it's better you ask in React community or Jest community Discord.

this works for mine:
module.exports = {
  verbose: true,
  preset: 'ts-jest',
  testEnvironment: 'node',
  collectCoverageFrom: ['**/*.{js,jsx,ts,tsx}'],
  setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
  testPathIgnorePatterns: [
    '<rootDir>/.cache/',
    '<rootDir>/.github/',
    '<rootDir>/.husky/',
    '<rootDir>/.next/',
    '<rootDir>/.vscode/',
    '<rootDir>/.yarn/',
    '<rootDir>/dist/',
    '<rootDir>/generated/',
    '<rootDir>/prisma/',
  ],
};

module.exports = function config(api) {
  return {
    presets: [
      [
        require.resolve('@babel/preset-env'),
        {
          targets: {
            browsers: ['last 2 versions', 'ie >= 11'],
            node: 'current',
          },
          corejs: '3.1.3',
        },
      ],
      require.resolve('@babel/preset-typescript'),
      ...

same issue and it works for mine:

execute jest --init, create jest.config.ts
edit jest.config.ts:

export default {
  ...
  "transform": {
    "^.+\\.(js|ts|tsx)$": "ts-jest"
  },
  ...
}

same issue and it works for mine:

execute jest --init, create jest.config.ts
edit jest.config.ts:

export default {
  ...
  "transform": {
    "^.+\\.(js|ts|tsx)$": "ts-jest"
  },
  ...
}

for me adding "js" to transform fixed the issue
This is before
"transform": {
-       "^.+\\.(ts|tsx)$": "ts-jest"
}

This is after
"transform": {
+        "^.+\\.(ts|tsx|js)$": "ts-jest"
 }

For whom having this issue in typescript 4.1 or later, and have explicitly set 'jsxImportSource' option in tsconfig.json file, you could probably try setting 'jsx' to 'react-jsx', as 'react' mode would make 'jsxImportSource' yelling.
e.g.
{
"compilerOptions": {
"jsx": "react-jsx",
"jsxImportSource": "@emotion/react",
}
}

For whom having this issue in typescript 4.1 or later, and have explicitly set 'jsxImportSource' option in tsconfig.json file, you could probably try setting 'jsx' to 'react-jsx', as 'react' mode would make 'jsxImportSource' yelling.
e.g.
{
"compilerOptions": {
"jsx": "react-jsx",
"jsxImportSource": "@emotion/react",
}
}

Confirmed that this gets be past the error of unexpected token, and then the added error of React refers to a UMD global if you were to update jsx to react.
Just for others in this same discovery, after this fix if your application specifies custom module paths in your tsconfig.json, such as:
"paths": {
      "@components/*": ["src/components/*"],
      "@hooks/*": ["src/hooks/*"],
      "@lib/*": ["src/lib/*"],
      "@context/*": ["src/context/*"],
      "@models/*": ["src/models/*"],
      "@pages/*": ["src/pages/*"],
      "@services/*": ["src/services/*"],
      "@utils/*": ["src/utils/*"],
      "@constants/*": ["src/constants/*"],
      "@server/*": ["src/server/*"],
      "@/*": ["./*"]
}

Then you also need to add to your jest.config.js a moduleNameMapper for each of your custom paths:
moduleNameMapper: {
    '@components/(.*)': '<rootDir>/src/components/$1',
    '@hooks/(.*)': '<rootDir>/src/hooks/$1',
    '@lib/(.*)': '<rootDir>/src/lib/$1',
    '@context/(.*)': '<rootDir>/src/context/$1',
    '@models/(.*)': '<rootDir>/src/models/$1',
    '@pages/(.*)': '<rootDir>/src/pages/$1',
    '@services/(.*)': '<rootDir>/src/services/$1',
    '@utils/(.*)': '<rootDir>/src/utils/$1',
    '@constants/(.*)': '<rootDir>/src/constants/$1',
    '@server/(.*)': '<rootDir>/src/server/$1',
    '@/(.*)': '<rootDir>/./$1'
}

For me the error occured in a non-React project, and the cause was simple: I've run npx ts-jest config:init in a subdirectory(by accident) instead of the root folder where tsconfig.json resides. Moving jest.config.js file up the tree fixed the problem.

The best solution is to give up on writing tests in JavaScript. Come back in another ten years.

Issue :
I am using ts-jest to test my typescript library. When I run jest, I get the following error:
Jest encountered an unexpected token

    This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript.

    By default, if Jest sees a Babel config, it will use that to transform your files, ignoring "node_modules".

    Here's what you can do:
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/en/configuration.html

    Details:

    /Users/mohsinulhaq/Documents/react-popper-tooltip/tests/TooltipTrigger.spec.tsx:9
    const BasicTooltipTrigger = ({ tooltip, children, hideArrow, ...props }) => (<src_1.default {...props} tooltip={({ getTooltipProps, getArrowProps, placement }) => (<div {...getTooltipProps({
                                                                                ^

    SyntaxError: Unexpected token <

      at ScriptTransformer._transformAndBuildScript (node_modules/jest-runtime/build/script_transformer.js:403:17)

Here is my jest.config.js:
module.exports = {
  preset: 'ts-jest',
  globals: {
    'ts-jest': {
      diagnostics: false
    }
  }
};

and my babel.config.js:
module.exports = {
  presets: ['@babel/typescript', ['@babel/env', {loose: true}], '@babel/react'],
  plugins: [['@babel/proposal-class-properties', {loose: true}]]
};

In my package.json, I do have jest, ts-jest, babel-jest and<EMAIL_ADDRESS>installed. Please help. Thanks.
EDIT: I get the same output with the babel config file removed. Looks like ts-jest is not picking the babel config file up.

it can work when tsconfig.json file add "jsxFactory": "React.createElement".

it can work when tsconfig.json file add "jsxFactory": "React.createElement".


Cow: Watch shivabook.in

Cow requests the watch of the watch_keyword shivabook\.in. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

shivabook\.in has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Add the boilerplate for a support interface

Context
We want a place to be able to administrate some of the functions of the service, eg. feature flags, job queues.
Changes proposed in this pull request
This change introduces a support interface similar to the one we built for Find.
Checklist

[ ] Attach to Trello card
[x] Rebased main
[x] Cleaned commit history
[x] Tested by running locally

@felixclack the checks were not set to required, I did that after I noticed this auto-merged


[DSEW CPR] [DRAFT] Add basic interpolation function and a test stub

Description
Adds an interpolation function to address #1539.
TODO

Expand the existing test to make sure two overlapping dataframes touched by the interpolation function a) leave existing values alone (i.e. keep overlapping values in common the same), b) interpolate in the same way regardless of overlapping window size.
Modify fetcher to always fetch approximately 5 days when params arg is "new".
Handle duplicates if two CPR files contain data for the same day.

Changelog

Add a basic interpolation function that fills in missing rows with reasonable defaults.
Add a basic test.

Fixes

Fixes #1539.

Pushed more and clearer tests. Also made the interpolation default to linear - requires only two points to do, has simpler behavior, and should produce consistent interpolation when datasets don't fully overlap.
Want to do a few more tests today and convince myself that the archiver will be given consistent input, week after week.

So I ran the current indicator on two overlapping date ranges to see how the outputs would differ.
dates1: 2022-03-05 -- 2022-03-11
dates2: 2022-03-08 -- 2022-03-14
Comparing the two receiving directories, we get a few cases:

Files that are only in receiving_dates1 have the date ranges [20220225 -- 20220307]
Files that are only in receiving_dates2 have the date ranges [20220309 -- 20220314]
Common files on the left time boundary contain a few rows present in receiving_dates1 and missing in receiving_dates2

this is either a) an actual deletion, b) an interpolation that loses a value on the left of the NA, so can't fill anymore

Common files in middle of the time boundary, with 90% row changes. This is likely updating data.
Common files on the right time boundary contain a few rows present in receiving_dates2 and missing in receiving_dates1

either a) an actual new value, b) an interpolation that loses its value on the right of the NA, so can't be filled

Seems like it will be easy to introduce bugs here if we aren't careful. Possible issue: the archivediffer treating missing rows in (3) and (5) as deletions and deleting valid interpolations. Possible solution is to restrict the receiving output of the indicator to a given range, such as that middle common files range (4). Now can we find that time range consistently, given the strange behavior of weekends in this indicator? Unclear. Currently, the indicator is still limited to only processing a ~6-day window for the data or else it runs into an error with having multiple values for the same (geo, time, signal) pair.

@krivard I updated your comment with the filled table.

Awesome. I had some time to kill while waiting for builds to finish so I fiddled with this a bit, and it looks like (at least for hospital admissions) we're getting exactly what we want:

neither the main branch nor the interpolation branch makes changes to previously-computed days where reports ranges overlap
the interpolation branch makes no changes to days where we have source data
the interpolation branch generates output for days where we don't have source data

What I did:
$ for branch in main ds/dsew-interpolation; do git checkout $branch; for r in 2022-03-05--2022-03-11 2022-03-08--2022-03-14; do rcv="receiving_${branch/\//_}_$r"; mkdir $rcv ||break;  env/bin/python -m delphi_utils set indicator.reports $r common.export_dir $rcv; env/bin/python -m delphi_dsew_community_profile ||break; done; done;
$ diff -rq receiving_main_2022-03-0* |less
# ^^ looks like the old pipeline doesn't sort its output, but we can get around that
$ diff -rq receiving_main_2022-03-0* |grep differ |awk '{print "diff -u <(sort " $2 ")","<(sort " $4 ")"}' |bash |less
# ^^ no files truly differ after sorting
$ diff -rq receiving_ds_dsew-interpolation_2022-03-0* |less
# ^^ new pipeline does sort its output, so there are no files that differ
$ diff -rq receiving_*_2022-03-05--2022-03-11 |less
# ^^ no new files, as expected; differing files is probably the sorting issue
$ diff -rq receiving_*_2022-03-05--2022-03-11 |grep differ |awk '{print "diff -u <(sort " $2 ")","<(sort " $4 ")"}' |bash |less
# ^^ no files truly differ
$ diff -rq receiving_*_2022-03-08--2022-03-14 |less
# ^^ new files covering the gap in the interpolation branch; differing files is probably the sorting issue
$ diff -rq receiving_*_2022-03-08--2022-03-14 |grep differ |awk '{print "diff -u <(sort " $2 ")","<(sort " $4 ")"}' |bash |less
# ^^ no files truly differ

What needs to happen next?

Oh you're right, this is good news. So what I would like to double check is which signals were having differences when I diffed the folders yesterday. There might be some numerical issues going on.

I just reran the folder comparison analysis above and the only signal with differing files is naat_pct_positive_7dav.

Is there anything special about that signal? Here is a sample deletion from 20220228_county_covid_naat_pct_positive_7dav.csv

Here is another example 20220302_county_covid_naat_pct_positive_7dav.csv, where the majority of the file is changed, but as you can see the changes to the values are very minor (~1%). Could it be a numerical issue?

So I suppose, we wait until the naats logic is fixed and then rerun these comparisons?

Okay, you're right that something is definitely horked in interpolation, and for whatever reason it's only showing up with naats.
I aspirationally merged Nat's naats fix into a spare branch, like this:
$ git checkout ds/dsew-interpolation
$ git checkout -b krivard/dsew-interpolation
$ git merge ndefries/cpr-lenient-check-ts-per-publishdate

(don't merge those changes into ds/dsew-interpolation yet, in case Ananya finds something and Nat needs to rebase. this is purely a throwaway merge)
Then I ran each branch (krivard/dsew-interpolation and ndefries/cpr-lenient-check-ts-per-publishdate) twice: once with reports set to 2022-03-09--2022-03-11 and once with reports set to 2022-03-11--2022-03-14. The smaller ranges are necessary so that we can avoid overlaps unique to the naats data.
Here are the available files in those two ranges, along with the positivity and volume reference dates they contain:

publish date
week
positivity refdate
volume refdate

2022-03-09
previous
2022-02-27
2022-02-23

2022-03-09
last
2022-03-06
2022-03-02

2022-03-10
previous
2022-02-28
2022-02-24

2022-03-10
last
2022-03-07
2022-03-03

2022-03-11
previous
2022-03-01
2022-02-25

2022-03-11
last
2022-03-08
2022-03-04

2022-03-14
previous
2022-03-04
2022-02-28

2022-03-14
last
2022-03-11
2022-03-07

Sorted by positivity refdate (which is the refdate used for output) we get:

publish date
positivity refdate
volume refdate

2022-03-09
2022-02-27
2022-02-23

2022-03-10
2022-02-28
2022-02-24

2022-03-11
2022-03-01
2022-02-25

2022-03-14
2022-03-04
2022-02-28

2022-03-09
2022-03-06
2022-03-02

2022-03-10
2022-03-07
2022-03-03

2022-03-11
2022-03-08
2022-03-04

2022-03-14
2022-03-11
2022-03-07

There are no backfill entries across these two ranges: no reference date is reissued with updated data.
Between the two ranges (9-11 and 11-14) there is one overlapping file, 2022-03-11. If the code were working correctly, the output from that file (refdates 2022-03-01 and 2022-03-08) should match between the two runs. Right?
The output from ndefries/cpr-lenient-check-ts-per-publishdate matches, so I'm pretty sure we're not dealing with a logic bug in the naats handling per se.
The output from krivard/dsew-interpolation does not match. Sample diff (sorted; header manually edited for readability):
--- receiving_krivard_dsew-interpolation_2022-03-09--2022-03-11/20220301_county_covid_naat_pct_positive_7dav.csv 2022-03-31 17:46:26.517258105 -0400
+++ receiving_krivard_dsew-interpolation_2022-03-11--2022-03-14/20220301_county_covid_naat_pct_positive_7dav.csv 2022-03-31 17:46:26.517258105 -0400
@@ -347,7 +347,6 @@
 13055,0.046,NA,26.285714285714285
 13057,0.045,NA,383.2857142857143
 13059,0.042,NA,171.14285714285714
-13061,0.15,NA,15.535714285714285
 13063,0.013,NA,2531.8571428571427
 13067,0.038,NA,1430.4285714285713
 13069,0.051,NA,34.0
@@ -450,7 +449,6 @@
 13299,0.078,NA,27.857142857142858
 13303,0.079,NA,10.857142857142858
 13305,0.057,NA,23.0
-13309,0.0578571,NA,6.6938775510204085
 13311,0.068,NA,42.0
 13313,0.03,NA,264.0
 13317,0.0,NA,6.142857142857143
@@ -752,7 +750,6 @@
 20173,0.044,NA,686.4285714285714
 20175,0.047,NA,10.0
 20177,0.052,NA,382.2857142857143
-20181,0.0335,NA,6.0476190476190474
 20189,0.032,NA,6.571428571428571
 20191,0.071,NA,19.714285714285715
 20193,0.234,NA,6.0
[...]

Hopefully that gives you a solid place to start looking for the cause?

Hm, ok. So the mismatch is still: a) unique to interpolation, b) unique to naats signal.
So just to make sure I have the terminology down: publish_date is the date on the file, positivity_refdate is the date in the positivity data, and volume_refdate is the date in the sample size data? Can you say more about how the positivity and volume data are used? Do we compute ratios for any signals by matching positivity_refdate and volume_refdate across files?

Correct on publish date, positivity refdate, and volume refdate.
Consult https://github.com/cmu-delphi/covidcast-indicators/pull/1562 and/or Nat for how the two refdates are used -- the TL;DR is that we match volume to positivity only within each file, and only within each week ("last week" or "previous week").

I haven't been following this super closely, but is the missing geo perhaps related to this?

@nmdefries shouldn't be, since we are comparing two receiving outputs from the same branch using the same geomapper source. The only thing changing in our comparisons is the time window over which the indicator aggregates input files.

TL;DR: I found two concrete examples of the ways the deletions and updates occurred. It's basically what was expected:

the data contains is in [a, b] and [b, c] and so the interpolation for both doesn't cover the same values
the data contains interleaved data and so the interpolation imputes different values

Case 1
Let's look at the county "13061" for the naat positivity signal. Here is what the data looks like:
# 2022-03-09--2022-03-11
            val        se  sample_size
timestamp
2022-02-27  0.2  0.100905    15.714286
2022-03-07  0.0  0.000000    15.000000
2022-03-08  0.0  0.000000    15.285714

# 2022-03-11--2022-03-14
            val   se  sample_size
timestamp
2022-03-08  0.0  0.0    15.285714
2022-03-11  0.0  0.0    15.285714

When smoothed, we get the following
# 2022-03-09--2022-03-11
              val        se  sample_size
timestamp
2022-02-27  0.200  0.100905    15.714286
2022-02-28  0.175  0.088292    15.625000
2022-03-01  0.150  0.075679    15.535714
2022-03-02  0.125  0.063066    15.446429
2022-03-03  0.100  0.050452    15.357143
2022-03-04  0.075  0.037839    15.267857
2022-03-05  0.050  0.025226    15.178571
2022-03-06  0.025  0.012613    15.089286
2022-03-07  0.000  0.000000    15.000000
2022-03-08  0.000  0.000000    15.285714

# 2022-03-11--2022-03-14
            val   se  sample_size
timestamp
2022-03-08  0.0  0.0    15.285714
2022-03-09  0.0  0.0    15.285714
2022-03-10  0.0  0.0    15.285714
2022-03-11  0.0  0.0    15.285714

This is a simple case: the only overlap for the data is the date 2022-03-08, where the values are the same. Clearly the rest of the values won't show up in receiving and will be viewed as deletions for this geo.
Case 2
Here is another geo "13059", with a less trivial case:
# 2022-03-09--2022-03-11
              val        se  sample_size
timestamp
2022-02-27  0.050  0.015800   190.285714
2022-02-28  0.045  0.015458   179.857143
2022-03-01  0.042  0.015333   171.142857
2022-03-06  0.015  0.008446   207.142857
2022-03-07  0.011  0.006831   233.142857
2022-03-08  0.011  0.006637   247.000000

# 2022-03-11--2022-03-14
              val        se  sample_size
timestamp
2022-03-01  0.042  0.015333   171.142857
2022-03-04  0.021  0.010839   175.000000
2022-03-08  0.011  0.006637   247.000000
2022-03-11  0.022  0.009534   236.714286

When smoothed, we get
# 2022-03-09--2022-03-11
               val        se  sample_size
timestamp
2022-02-27  0.0500  0.015800   190.285714
2022-02-28  0.0450  0.015458   179.857143
2022-03-01  0.0420  0.015333   171.142857
2022-03-02  0.0366  0.013956   178.342857
2022-03-03  0.0312  0.012578   185.542857
2022-03-04  0.0258  0.011201   192.742857
2022-03-05  0.0204  0.009823   199.942857
2022-03-06  0.0150  0.008446   207.142857
2022-03-07  0.0110  0.006831   233.142857
2022-03-08  0.0110  0.006637   247.000000

# 2022-03-11--2022-03-14
                 val        se  sample_size
timestamp
2022-03-01  0.042000  0.015333   171.142857
2022-03-02  0.035000  0.013835   172.428571
2022-03-03  0.028000  0.012337   173.714286
2022-03-04  0.021000  0.010839   175.000000
2022-03-05  0.018500  0.009788   193.000000
2022-03-06  0.016000  0.008738   211.000000
2022-03-07  0.013500  0.007687   229.000000
2022-03-08  0.011000  0.006637   247.000000
2022-03-09  0.014667  0.007602   243.571429
2022-03-10  0.018333  0.008568   240.142857
2022-03-11  0.022000  0.009534   236.714286

Here the data from the two date ranges is interleaved: both have 2022-03-01 and 2022-03-08, but only the first has 2022-03-06 and only the second has 2022-03-04. This naturally causes the interpolations on 2022-03-02, 2022-03-03, 2022-03-05, 2022-03-07 to be different.
Conclusions

The first case seems like an unfortunate case of inconsistent updates across geos.
The second case seems like a legitimate data update and it seems reasonable to add values in that case.

Ideally we could get the archiver to ignore the first case and not delete values. I'm not sure how we can make that happen without adding even more complex logic here.

Case 1

This is a simple case: the only overlap for the data is the date 2022-03-08, where the values are the same. Clearly the rest of the values won't show up in receiving and will be viewed as deletions for this geo.

A deletion is only detected when a file is present in both places, but a row is missing -- if the rest of the values are in files that aren't output, we shouldn't get any deletions. In this particular case, the 11-14 run has output coverage over reference dates from 3/01 through 3/11 via other regions, so we will get deletions for 3/01-3/07, but not for 2/27-2/28.
Case 2
I agree with your reasoning that the interpolator is working as intended here, but I don't like the idea of replacing the report-confirmed values for 3/06 and 3/07 with interpolated ones. This probably means extending the date range we load in each run, but that's going to get tricky with the naats matching algorithm Nat developed. If we can get it to work though, that will probably also take care of the mistaken deletions problem from Case 1.
What next

write up the problem for Ryan, since this is more complicated than we anticipated
get you, me, Nat, and maybe Ananya in a meeting to figure out how to get interpolation to activate only for reference dates where we have no data, while maintaining our ability to match total naats and naats positivity by week

Case 1: good clarification. The deletions come from the inconsistency in reporting across geos for overlapping dates.
Case 2: while extending the range will solve the issue of replacing a known value with an interpolation, I am skeptical that it will solve the problem of case 1. I expect that there will data files with publish dates on the boundaries of the range that will present inconsistent reference dates across geos and lead to the same artificial deletion phenomena.
The archiver limits us because it was designed to handle indicators that output either full date ranges or partial date ranges on each run, but it was not designed to handle partial geo reports.

I expect that there will data files with publish dates on the boundaries of the range that will present inconsistent reference dates across geos and lead to the same artificial deletion phenomena.

If we ran with reports: "all" each day, we wouldn't have boundaries 😄
...but the running time would slowly devour the world, so that's probably not the solution we want long-term

Yeaaaa, I don't think that's feasible even now - opening and interpolating just 7 files takes ~5 minutes on my machine, so if the full history is 300+ files, it would take hours.

@krivard I think this is ready for a final review, once I figure out what's failing with the build.

pretty sure it's just the linter

@krivard the linter is happy! i ran this with a modification of your
for branch in ds/dsew-interpolation; do git checkout $branch; for r in 2022-03-05--2022-03-11 2022-03-08--2022-03-14; do rcv="receiving_${branch/\//_}_$r"; mkdir $rcv ||break;  env/bin/python -m delphi_utils set indicator.reports $r common.export_dir $rcv; env/bin/python -m delphi_dsew_community_profile ||break; done; done;

and found that there were no changed files, only new and removed in the diff.
maybe to be safe i should try this on even more date windows...

Alright, I started running this
date_ranges=()
for i in {1..60}; do
    date_ranges[i]=$(date -I -d "2022-01-01 +$i days")--$(date -I -d "2022-01-01 +$(expr $i + 5) days")
done

for branch in ds/dsew-interpolation; do git checkout $branch; for r in "$date_ranges[@]"; do rcv="receiving_${branch/\//_}_$r"; mkdir $rcv ||break;  env/bin/python -m delphi_utils set indicator.reports $r common.export_dir $rcv; env/bin/python -m delphi_dsew_community_profile ||break; done; done;

and was going to diff all consecutive folders, just to make sure and I already found something strange.
Setting reports to "2022-01-02--2022-01-06" breaks because the 2021-12-30 publish date only has 1 reference value, but add_max_ts_col expects 2. The strange thing is that the 2021-12-30 publish date file has 2 reference values and setting reports to "2022-01-02--2022-01-05" confirms this, since it runs just fine. My guess is that extending to 2022-01-06 somehow filters out reference values from the 2021-12-30 file.

I think I see what happened. The 2021-12-30 file has two reference dates: 2021-12-27 and 2021-12-20. The 2022-01-06 file also has the 2021-12-27 reference date, so when we hit this line of code, the 2022-01-06 version overwrites the 2021-12-30 one and leaves it with a single reference date.
latest_sig_df = pd.concat(
            lst
        ).groupby(
            "timestamp"
        ).apply(
            lambda x: x[x["publish_date"] == x["publish_date"].max()]
        ).drop_duplicates(
        )

Aaand it turns out that Nat already fixed this issue and I just haven't merged from main into this branch in a while.


Music System Notes

Although the music system is more or less done, I'm using this issue as a place to leave comments on it and put all issues related to it.
Now, the issue that inspired me to open this: Bot can not play age restricted content, not really a problem we have to fix, but one to be aware of.

Sounds good. Assigned it as a bug that we will deal with in Version 2.

Just found about yt-dl, a fork of youtube-dl that comes out of the box with more features. A couple of the features they use, the abilities to seach YouTube and play age-restricted content, play very nicely into fixing this bug.
What do you think about this fork? Should we follow through with it and would it be easy to port our existing youtube-dl code to yt-dl?

I get this error as people use the Discord. Can you look into this error?

The music system cog can hang if a user queues a playlist. The solution is to reload the musicSystem cog. Without that command, the music system is frozen and no longer works.
Possible solutions are:

Filter and ignore playlist links
Use YTP to split the playlist into several videos that are queued.

The music on Kakapo sometimes speeds up and slows down briefly at the beginning, this is due to Discord's Compression and there is nothing we can do about the issue.


BinanceApiMarginRestClient.getMyTrades(String) is connected to wrong endpoint

BinanceApiMarginRestClient.getMyTrades(String) uses endpoint /api/v3/myTrades (spot account trade list). It should use /sapi/v1/margin/myTrades (margin account trade list).

This code came from a very old one.
We must have a little patience and try to adjust it to the new API.
This may take a time.

I have been trying to, yes. I have a workaround, but I am considering using binance-java-api. Currently, too many endpoint are missing or not working, though.
What do you mean by "adjust it to the new API"? Given that all infrastructure is in place, wouldn't it be very easy to adjust or add endpoints? I have been thinking about a pull request, but I would need it to be merged pretty soon. Alternatively, I would just keep implementing all my required endpoints in my own client.

Well, this code came from https://github.com/joaopsilva/binance-java-api and it is 4 years old. I think Binance was changed some endpoints but I'm not sure. I mean this code may not use the current Binance API endpoints and need updates.
I have no idea if this code is actualy active by the Binance people so ... every time I fix something I post here. Unfortunately I'm not working on this wrapper directly so I can't ask for P.R. but I working on a WEB portal and if I see something wrong I try to fix it and post here for someone merge to main code.
I've started to work on my web portal on this sunday so it is very basic yet. It will work using Docker to be easy to install.

@marco-eckstein Ah. forgot to ask .... have you doble checked your API key/secret if it is working? A lot of endpoints here will work only if you give a correct pair KEY/SECRET.

Yes, they are ok.


[BUG] Nightly Test: test_toleration_setting sometimes failed

Describe the bug
sometimes test_toleration_setting test failed
To Reproduce
Install Longhorn master
Run test_toleration_setting
Expected behavior
test should pass
Log
def test_toleration_setting():
        client = get_longhorn_api_client()
        apps_api = get_apps_api_client()
        core_api = get_core_api_client()
        count = len(client.list_node())

        setting = client.by_id_setting(SETTING_TAINT_TOLERATION)

        with pytest.raises(Exception) as e:
            client.update(setting,
                          value=KUBERNETES_DEFAULT_TOLERATION + ":NoSchedule")
        assert "is considered as the key of Kubernetes default tolerations" \
               in str(e.value)
        with pytest.raises(Exception) as e:
            client.update(setting,
                          value="key1=value1:NoSchedule; key2:InvalidEffect")
        assert 'invalid effect' in str(e.value)

        setting_value_str = "key1=value1:NoSchedule; key2:NoExecute"
        setting_value_dict = \
            {"key1": {"key": "key1", "value": "value1",
                      "operator": "Equal", "effect": "NoSchedule"},
             "key2": {"key": "key2", "value": None,
                      "operator": "Exists", "effect": "NoExecute"}, }

        volume_name = "test-toleration-vol"
        volume = create_and_check_volume(client, volume_name)
        volume.attach(hostId=get_self_host_id())
        volume = wait_for_volume_healthy(client, volume_name)
        with pytest.raises(Exception) as e:
            client.update(setting, value=setting_value_str)
        assert 'cannot modify toleration setting before all volumes are detached' \
               in str(e.value)

        data1 = write_volume_random_data(volume)
        check_volume_data(volume, data1)

        volume.detach()
        wait_for_volume_detached(client, volume_name)

        setting = client.update(setting, value=setting_value_str)
        assert setting.value == setting_value_str
        wait_for_toleration_update(core_api, apps_api, count, setting_value_dict)

        client = get_longhorn_api_client()

        ei = get_default_engine_image(client)
        ei_name = ei["name"]

        wait_for_engine_image_state(client, ei_name, "ready")
        volume = client.by_id_volume(volume_name)

        node = get_self_host_id()
        wait_for_node_up_longhorn(node, client)

        volume.attach(hostId=node)
        volume = wait_for_volume_healthy(client, volume_name)
        check_volume_data(volume, data1)
        data2 = write_volume_random_data(volume)
        check_volume_data(volume, data2)
        volume.detach()
        wait_for_volume_detached(client, volume_name)

        # cleanup
        setting_value_str = ""
        setting_value_dict = {}
        setting = client.by_id_setting(SETTING_TAINT_TOLERATION)
        setting = client.update(setting, value=setting_value_str)
        assert setting.value == setting_value_str
>       wait_for_toleration_update(core_api, apps_api, count, setting_value_dict)

test_toleration_setting.py:91:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

core_api = <kubernetes.client.apis.core_v1_api.CoreV1Api object at 0x7ffba4545690>
apps_api = <kubernetes.client.apis.apps_v1_api.AppsV1Api object at 0x7ffba48b6350>
count = 3, set_tolerations = {}

    def wait_for_toleration_update(core_api, apps_api, count, set_tolerations):  # NOQA
        updated = False

        for i in range(RETRY_COUNTS):
            time.sleep(RETRY_INTERVAL_LONG)
            updated = True

            da_list = apps_api.list_namespaced_daemon_set(LONGHORN_NAMESPACE).items
            for da in da_list:
                if da.status.updated_number_scheduled != count:
                    updated = False
                    break
            if not updated:
                continue

            dp_list = apps_api.list_namespaced_deployment(LONGHORN_NAMESPACE).items
            for dp in dp_list:
                if dp.status.updated_replicas != dp.spec.replicas:
                    updated = False
                    break
            if not updated:
                continue

            im_pod_list = core_api.list_namespaced_pod(
                LONGHORN_NAMESPACE,
                label_selector="longhorn.io/component=instance-manager").items
            if len(im_pod_list) != 2 * count:
                updated = False
                continue

            for p in im_pod_list:
                if p.status.phase != "Running":
                    updated = False
                    break
            if not updated:
                continue

            pod_list = core_api.list_namespaced_pod(LONGHORN_NAMESPACE).items
            for p in pod_list:
                if p.status.phase != "Running" or \
                        not check_tolerations_set(p.spec.tolerations,
                                                  set_tolerations):
                    updated = False
                    break
            if not updated:
                continue

            client = get_longhorn_api_client()
            images = client.list_engine_image()
            assert len(images) == 1
            if images[0].state != "ready":
                updated = False
                continue

            if updated:
                break

>       assert updated
E       assert False

test_toleration_setting.py:170: AssertionError

Environment:

Longhorn version: master
Kubernetes version: v1.17
Node OS type and version: Ubuntu 18.04

Additional context
Jenkins build num: longhorn-tests/370

test failed again on longhorn-tests/400:
logs:
def test_toleration_setting():
        """
        Test toleration setting

        1. Verify that cannot use Kubernetes tolerations for Longhorn setting
        2. Use "key1=value1:NoSchedule; key2:NoExecute" as toleration.
        3. Create a volume and attach it.
        4. Verify that cannot update toleration setting when any volume is attached
        5. Generate and write `data1` into the volume
        6. Detach the volume.
        7. Update setting `toleration` to toleration.
        8. Wait for all the Longhorn components to restart with new toleration
        9. Attach the volume again and verify the volume `data1`.
        10. Generate and write `data2` to the volume.
        11. Detach the volume.
        12. Clean the `toleration` setting.
        13. Wait for all the Longhorn components to restart with no toleration
        14. Attach the volume and validate `data2`.
        15.


All Engines should print commit hash on startup

@timsuchanek wants to use this to validate that the javascript code and downloaded engines are in sync. We often had the case that this did not work properly and debugging is unecessarily hard.

We have this now when querying /server_info from the query-engine runtime.

We have this also in the command line parameters for query and migration engines:
cargo run --bin prisma -- --version
2b78c35cf302bf80ae5aaa863c5eee0d09541f83

cargo run --bin migration-engine -- --version
2b78c35cf302bf80ae5aaa863c5eee0d09541f83

https://github.com/prisma/prisma-engine/commit/fe8f5f767f3122f7b76a64ab13e771c1b822268b

How will this be implemented/used?

You just run the binary with --version parameter.

Ha, yes on the engine side - I was wondering where and how this would be used by @timsuchanek to do what exactly.

When we cut a release, photon asserts the hash and throws if it's not what is expected.
-------- Original Message --------
On Oct 9, 2019, 00:46, Jan Piotrowski wrote:

Ha, yes on the engine side - I was wondering where and how this would be used by @timsuchanek to do what exactly.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.


Preview page is not showing the Geographic Scope

Creating a test Camtrap DP dataset on https://ipt3.gbif-uat.org/
Bounding coordinates are shown in the Geographic Scope of metadata, but it becomes blank in the preview page after publishing. Coordinates seem to be included in the datapackage.json properly.

Thanks Kumiko, I'll fix it

I'll deploy the fix in the next version


Add Microchip toolchain to CI tests

Part of #117

@SanjoDeundiak do we still need this?

I don't think it's relevant


Support eip1559 transactions

Our current execution engine uses legacy transactions and the gas management that goes with it.
We need to investigate how we approach eip-1559 transactions and what config and policies need to built in.
The investigation needs to determine what impact on Ignition's use with other chains such an update would have.

Closing in favour of #8


fix: update selectors for new ucc ui

Jira: https://jira.splunk.com/browse/ADDON-37160
Changes:
Update selectors for new UCC UI

:tada: This PR is included in version 2.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


ROM >= 8k fails to build

Describe the bug
A clear and concise description of what the bug is.
Version
1.2.48 (b6a6f12642df6b84facc24a77f9a6f67a0d62dab)
To Reproduce
Generate a 8kbyte ROM binary file, e.g.:
dd if=/dev/zero bs=1 count=8192 | tr '\000' 'U' > rom_configs/rom_8k.bin

Use the following configuration:
word_size = 1
check_lvsdrc = True
rom_data = "rom_configs/rom_8k.bin"
data_type = "bin"
output_name = "sky130_rom_8k
output_path = "macro/{output_name}".format(**locals())

import os
exec(open(os.path.join(os.path.dirname(__file__), 'sky130_rom_common.py')).read())

Expected behavior
Should build without any errors
Logs
[openram.router.signal_escape_router/route]: Running signal escape router...
Traceback (most recent call last):
  File "/home/runner/work/sky130-rom-experiments/sky130-rom-experiments/OpenRAM/rom_compiler.py", line 65, in <module>
    r = rom()
  File "/home/runner/work/sky130-rom-experiments/sky130-rom-experiments/OpenRAM/compiler/rom.py", line 54, in __init__
    self.r.create_layout()
  File "/home/runner/work/sky130-rom-experiments/sky130-rom-experiments/OpenRAM/compiler/modules/rom_bank.py", line [86](https://github.com/TinyTapeout/sky130-rom-experiments/actions/runs/8441697713/job/23121431113#step:4:87), in create_layout
    self.route_layout()
  File "/home/runner/work/sky130-rom-experiments/sky130-rom-experiments/OpenRAM/compiler/modules/rom_bank.py", line 124, in route_layout
    self.route_escape_pins(init_bbox)
  File "/home/runner/work/sky130-rom-experiments/sky130-rom-experiments/OpenRAM/compiler/modules/rom_bank.py", line 534, in route_escape_pins
    rtr.route(pins_to_route)
  File "/home/runner/work/sky130-rom-experiments/sky130-rom-experiments/OpenRAM/compiler/router/signal_escape_router.py", line 73, in route
    self.new_pins[source.name] = new_wires[-1]
IndexError: list index out of range
make[1]: *** [Makefile:[90](https://github.com/TinyTapeout/sky130-rom-experiments/actions/runs/8441697713/job/23121431113#step:4:91): sky130_rom_8192.ok] Error 1
make: *** [Makefile:95: sky130_rom_8192] Error 2

(You can see the complete logs here)
Additional context
Also happens on larger sizes (tried 12k, 16k, 24k, 32k), and even with smaller sizes if we increase the value of words_per_row, e.g., for a 128 bytes ROM:
dd if=/dev/zero bs=1 count=128 | tr '\000' 'U' > rom_configs/rom_128.bin

word_size = 1
words_per_row = 32

check_lvsdrc = True

rom_data = "rom_configs/rom_128.bin"
data_type = "bin"

output_name = "rom_128"
output_path = "macro/{output_name}".format(**locals())

import os
exec(open(os.path.join(os.path.dirname(__file__), 'sky130_rom_common.py')).read())

A 1-bit ROM seems very odd and I'm not surprised that doesn't work.  Why would you only need 1-bit output?
It would probably be better to have a 8 or even 32-bit output and then select which bit of the output is needed.

Thanks for responding! word_size = 1 generates a 8-bit ROM. It's the same word size as defined in the 1K example ROM:
https://github.com/VLSIDA/OpenRAM/blob/b6a6f12642df6b84facc24a77f9a6f67a0d62dab/macros/rom_configs/sky130_rom_1kbyte.py#L9

I see. This is actually a mistake as it should be in bits, not bytes like the SRAMs:
https://github.com/VLSIDA/OpenRAM/blob/b6a6f12642df6b84facc24a77f9a6f67a0d62dab/compiler/rom_config.py#L21


增加pg的ALTER TABLE XXX OWNER TO XX语法解析支持

ALTER TABLE table_name OWNER TO new_owner  语法解析的支持

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Always invoke profile service even if no claims requested

done

@brockallen The documentation doesn't give a full description of IProfileService, but am I correct in assuming that with this modification, the claims added by IProfileService.GetProfileDataAsync will be added to both Identity Token and the Access Token, but before 1.0.2 they were only added to the Identity Token?  This seems to be the behaviour I'm seeing when upgrading from QuickStart 7's version 1.0.0 to 1.1.1.

It looks like the commit is this one, and it's getting called for the Identity Token here and again for the Access Token in this method here.  So I guess the answer is that IProfileService will normally be queried for both tokens.


dart run hides part of error output

Dart version: Dart SDK version: 2.12.0-237.0.dev (dev) (Unknown timestamp) on "linux_x64"
OS: Ubuntu 18.04.5 LTS
Problem:
dart run hides part of error information normally shown by dart pub run
I've a syntax error in my pubspec.yaml
When I run
dart pub run test
output is
`Deprecated. Use dart run instead
Error on line 13, column 1 of pubspec.yaml: Expected ':'.
╷
13 │ dev_dependencies:
│ ^
╵
`
But when I run
$ dart run test
the only output is
Expected ':'.

/cc @bkonyi

I'm able to reproduce when running dart test vs pub run test. I would expect that these would be consistent, but it looks like we aren't providing as much detail in the CommandResolutionFailedException's message.


Some important details.

Added a tip for setting the webhook with osticket and how to contribute to the documentation.

Thanks for the PR @lobocode. We're currently working on improving the docs system, so please be patient until we sorted that out first - then we can review and merge your PR. :)
Sorry for the delay.

@frdmn Ok. At least pay attention in this last commit I did. Is a small (but important) correction. ;)

@lobocode We always pay attention to the full PR changes. No worries :)

@frdmn  Thank's!


Sweep: Refactor the code and file structures of this repositorySweep:

Details
Use unlimited sweep AI with GPT3.5 to
Refactor the code and file structures of this repository.
 No changes made  Edit
[X] Running GitHub Actions for packages/mrcnn/utils_common.py ✗  Edit

Use unlimited sweep AI with GPT3.5 to

Refactor the code and file structures of this repository.
Remove useless files in this repository

Use unlimited sweep AI with GPT3.5 to

Refactor the code and files in packages
Remove useless files in packages
Boost Readability and maintainability of this repository


*: remove external thread pool

Use our own simple thread pool to replace the extern crate. So when a thread is stopped, it won't be restarted again.

LGTM

/run-all-tests


log underflow in mne.stats.linear_regression

_fit_lm returns a quantity called mlog10_p_val for easier plotting of p-values. this fails when the p-value is 0.
https://github.com/mne-tools/mne-python/blob/master/mne/stats/regression.py#L134
one possible solution would to have some reasonable minimal p-value, e.g. instead of
mlog10_p_val[predictor] = -np.log10(p_val[predictor])

you could do something like
mlog10_p_val[predictor] = -np.log10(np.clip(p_val[predictor]), 0.0000000001, 1))

This is a dupe. See #1917.  Yeah, I think we should do something along the lines proposed by you, maybe using ```np.finfo(np.float64).tiny

+1 for using np.finfo. min pvalue should be around 1e-14

@TalLinzen PR welcome :)

sure, though if the min pvalue is around 1e-14 and np.finfo(np.float64).tiny is 2e-308 (on my computer) then it might be better to go for 1e-14, no?

hmm on a second thought I'm not sure what you meant when you said that the min pvalue is 1e-14. ;)

try:
In [1]: np.finfo(np.float64).eps
Out[1]: 2.2204460492503131e-16

tiny probably has to do with the smallest double precision floating point value before going denormalized, whereas eps should be the smallest d for which 1 + d > 1. eps probably makes more sense as a meaningful value in this context, but it could actually prove to be too large since eventually we deal with the log10 of the value -- that will depend on the specific calculations being done to calculate p. I guess we could start out with eps and if we decide it's clipping too many values, change it to tiny. Hopefully it won't matter which one we use either way.

is there a solution for this? I just got the same RuntimeWarning


<!--

Things to consider before you submit the PR:

[x] Are tests passing locally?
[x] Are the files formatted correctly?
[ ] Did you add unit tests?
[ ] Did you test your change with either the sample apps that are included in the repository or with a blank app that uses your change?

Description
Since we cannot use [[UIApplication sharedApplication] method] calls anymore, I've abstracted the sharedApplication to ANHApplicationProvider with a sharedApplication.
Related PRs or issues
N/A
Misc
N/A
Originally posted by @mpodwysocki in https://github.com/Azure/azure-notificationhubs-ios/pull/123

iOS 16,4

Closing as spam.   Account has been reported.


Plugin Compat - only unfreeze registries right before adding stuff

vane-core unfreezes registries (and sets the intrusive holder cache) when the core plugin's constructor is initialized. This happens before any other plugin's onEnable is called which could be before vanes' onEnables are called which add stuff to the registries. Any plugin that has their own onEnable called inbetween that does something which causes the registries to be re-frozen will interfere in vane's ability to add stuff to the registries.

Enchantment registries are now unfrozen each time as suggested beginning with vane 1.13.0.
Sorry that it took so long to add this trivial thing.


Investigate why OnXXXLandmarksOutput is called with null NormalizedLandmarkList

I made a change in https://github.com/SeedV/SeedUnityVRKit/pull/46/commits/db2d7d8dffa177666b3c7cb6b1d06857621c9203 that fixed the slow down on Windows.
But this commit also hides the root cause. In theory, if the image sent to mediapipe contains a valid posture, the result should not be null.
My current guess is that it hits a queue size limit in mediapipe. It should first queue up some input frames until it's queue is full, then it would drop any new frames after, until there are spaces in the queue again.
There's a frame pool that can be used to control concurrency. Currently the setting is 10. There may be room to optimize to set just 1 or 2 more frames larger than the queue size.

@superkudo can you help with this one? I think it's a good learning task to mediapipe processing mechanism and how input frames are handled internally.

Get it，I will track and fix this one

I debug and compare the MediaPipe and SeedVRKit XXXLandMarksOutput  called ， find the MediaPipe don’t have call with null with frame pool 10， I will try to find the difference between MediaPiepPlugin and SeedVRKit，I think source input effect the called with null

I find the reason ， It was because we set the Timeout Microsec to 0， the mideapipe is not track complete in timeout 0ms，so It callback null， In the demo it suggest set to 100000，  I set it and callback null problem is solved


Component not being loaded on Cloud Run

When deploying an app on Google Cloud Run, the following error shows when executing any st_javascript script.
Using Streamlit Community Cloud or localhost, the app works without problems.
st_javascript call:
st_javascript('''[window.innerWidth, parent.window.innerHeight];''', key=...)
Dokerfile:
#Base Image to use
FROM python:3.10-slim

#Expose port 8080
EXPOSE 8080

#Copy Requirements.txt file into app directory
COPY requirements.txt app/requirements.txt

#install all requirements in requirements.txt
RUN python -m pip install --upgrade pip && pip install -r app/requirements.txt

#Copy all files in current directory into app directory
COPY . /app

#Change Working Directory to app directory
WORKDIR /app

#Run the application on port 8080
ENTRYPOINT ["streamlit", "run", "app.py", \
  "--server.port=8080", \
  "--client.showErrorDetails=false", \
  "--client.toolbarMode=viewer"]

Closing, seems like a Cloud Run issue with JS components. Also happens with similar components


UPDATE: Azure DevOps Migration Tools 15.1.3

Will add:
ElevationRequirement: elevationProhibited
Microsoft Reviewers: Open in CodeFlow

Because this is a portable application, ElevationRequirement won't actually be checked

Automatic Validation ended with:

Installation failed with exit code -1978334960
2024-07-15 23:04:25.632 [CLI ] ShellExecute installer failed:<PHONE_NUMBER>

(Automated response - build 886.)

The only difference in this run from the previous one in the elevated permission.
Dependancies are the same as passed  before.

I believe the pipelines might be failing to de-elevate properly. This failed from an Administrator Powershell window, but was successful from a non-elevated window.


When would you release the pre-trained model in Tensorflow Hub?

I have been stay tuned for months.

There is one model available: https://alpha.tfhub.dev/google/inaturalist/inception_v3/feature_vector/1
This is Inception v3 299 trained on the original splits.
I plan to release larger models trained on our splits and an example to calculate domain similarity this weekend. Thanks for your patience.

thanks for your kind share, wish more releases of code and models
best wishes

Hi @xmczh003 ,
I've updated the repo with code, models and examples.

Hi I have a quick question that for the model released in the tensorflow hub, was trained on the train + val set? or was it trained on the original train split only. Thanks!


[Identity] Bump msal-node dep

This should be the last step in removing the vulnerable Axios dependency.

There is more than just updating the version in this PR. Can you provide some details on the other changes and what is driving us to do them? Did @azure/msal-node change anything in their API that is requiring us to now explicitly handle the null cases?

There is more than just updating the version in this PR. Can you provide some details on the other changes and what is driving us to do them? Did @azure/msal-node change anything in their API that is requiring us to now explicitly handle the null cases?

@ramya-rao-a - yes, they've updated the API to allow for it to return null in a few places that previously didn't, so we had to guard against it. That's basically what caused the non-bump changes.

@ramya-rao-a - yes, they've updated the API to allow for it to return null in a few places that previously didn't, so we had to guard against it. That's basically what caused the non-bump changes.

I am surprised that this PR moved all our packages to use node10 types instead of node8. Is there a reason behind this?

I am surprised that this PR moved all our packages to use node10 types instead of node8. Is there a reason behind this?

Good point. I did not check the pnpm-lock file when reviewing this.
@jonathandturner?

Good point. I did not check the pnpm-lock file when reviewing this.
@jonathandturner?


[SMD-169] add trailing space in line with submission template

https://dluhcdigital.atlassian.net/browse/SMD-169
Change description

fix inline with submission template dropdown value

[X] Unit tests and other appropriate tests added or updated

[X] README and other documentation has been updated / added (if needed)

[X] Commit messages are meaningful and follow good commit message guidelines (e.g. "FS-XXXX: Add margin to nav items preventing overlapping of logo")

How to test
If manual testing is needed, give suggested testing steps
Screenshots of UI changes (if applicable)

Closing this as I've modified the template to remove the trailing space instead


Show duplicate red dot error in conversation & report

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/46375
PROPOSAL: https://github.com/Expensify/App/issues/46375#issuecomment-2254303940
Tests

Login with new gmail account
Create a new workspace
Tap on a workspace chat
Create 2 expenses with same amount and merchant
Open each expense and note duplicate red dot shown under merchant
Verify duplicate red dot error shown in conversation & report page

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

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

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/user-attachments/assets/8b499084-6e0c-48de-8d0c-7fbf848e5669

Android: mWeb Chrome
https://github.com/user-attachments/assets/8ece4300-eeec-4243-b47e-627d4ae2543d

iOS: Native

iOS: mWeb Safari
https://github.com/user-attachments/assets/9fcf95a5-8183-477a-84e3-c837210d5cea

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/a65e00ff-6514-4790-b87b-24a2349cefb5

MacOS: Desktop
https://github.com/user-attachments/assets/13fce7b0-c15d-458b-b5ca-209256cd0857

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

Failing with #46375 in mWeb Desktop and android
https://platform.utest.com/services/links/v1/internal/52878509?.mp4
https://platform.applause.com/services/links/v1/external/e28a4548b82fde8d203ea7818e1f2174fb4196dc81cef8c2db886ae3d9546e74
https://platform.utest.com/services/links/v1/internal/52878671?.mp4

@nyomanjyotisa @stitesExpensify @thesahindia any thoughts on ^? Is this a deploy blocker?

oh wait the bug already exists in prod, right? I think this is NAB

FYI I believe this was deployed to prod yesterday, from this checklist - https://github.com/Expensify/App/issues/47219


Karma not capturing Chrome (Angular project)

Expected behaviour
Should run tests and show them in browser
Actual behaviour
Tries to capture browser with no success. (Browser is opened by Karma with proper url and port)
Environment Details

Karma version (output of karma --version): 3.0.0
Relevant part of your karma.config.js file

// https://karma-runner.github.io/1.0/config/configuration-file.html

module.exports = function (config) {
  config.set({
    basePath: '',
    frameworks: ['jasmine', '@angular-devkit/build-angular'],
    plugins: [
      require('karma-jasmine'),
      require('karma-chrome-launcher'),
      require('karma-jasmine-html-reporter'),
      require('karma-coverage-istanbul-reporter'),
      require('@angular-devkit/build-angular/plugins/karma')
    ],
    client: {
      clearContext: false // leave Jasmine Spec Runner output visible in browser
    },
    coverageIstanbulReporter: {
      dir: require('path').join(__dirname, '../coverage'),
      reports: ['html', 'lcovonly'],
      fixWebpackSourcePaths: true
    },
    reporters: ['progress', 'kjhtml'],
    port: 9876,
    colors: true,
    logLevel: config.LOG_INFO,
    autoWatch: true,
    browsers: ['Chrome'],
    singleRun: false
  });
};

Steps to reproduce the behaviour
There is no such steps since it's about one specific private project.
Question
Is there a logging or something like that so I could understand why Karma cannot capture Chrome?
The interesting part is that it successfully captures browser in other projects.
Log information

Try --log-level=DEBUG
Try running with --no-single-run then opening a browser at the localhost port given.  Open devtools and look into your test page. The karma server is waiting for the browser to load: your code may be hanging or erroring the load.


Connection to ap-gew4.spotify.com:443 timed out

Hi,
I am not able to use Spotify Connect on my Volumio (System Version: 2.917 Released: Wed Oct 6 12:34:49 CEST 2021) + Volumio Spotify Connect2 1.0.5. I have tried both with Multi User Device on and off.
When I select "Volumio" on the Spotify app on my phone,
it gets stuck on "connecting..."

The logs says:
Starting Live Log...
Starting Live Log...
info: CoreCommandRouter::executeOnPlugin: volumiodiscovery , saveDeviceInfo
info: CoreCommandRouter::volumioGetQueue
info: CoreStateMachine::getQueue
info: CorePlayQueue::getQueue
info: CoreCommandRouter::executeOnPlugin: system , getHwuuid
info: CALLMETHOD: system_controller system enableLiveLog true
info: CoreCommandRouter::executeOnPlugin: system , enableLiveLog
info: Launching a new LiveLog session
info: CALLMETHOD: system_controller system enableLiveLog true
info: CoreCommandRouter::executeOnPlugin: system , enableLiveLog
info: Launching a new LiveLog session
info: CoreStateMachine::getQueue
info: CorePlayQueue::getQueue
info: CoreCommandRouter::executeOnPlugin: system , getHwuuid
info: CALLMETHOD: system_controller system enableLiveLog true
info: CoreCommandRouter::executeOnPlugin: system , enableLiveLog
info: Launching a new LiveLog session
info: CALLMETHOD: system_controller system enableLiveLog true
info: CoreCommandRouter::executeOnPlugin: system , enableLiveLog
info: Launching a new LiveLog session
info: Killing previous LiveLog session
info: Starting Shairport Sync
info: Starting Shairport Sync
volumio : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/systemctl restart shairport-sync
volumio : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/systemctl restart shairport-sync
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session opened for user root by (uid=0)
volumio : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/systemctl start upmpdcli.service
Starting Shairport Sync - AirPlay Audio Receiver...
Started Shairport Sync - AirPlay Audio Receiver.
pam_unix(sudo:session): session closed for user root
pam_unix(sudo:session): session opened for user root by (uid=0)
process exited with code nullStopping Shairport Sync - AirPlay Audio Receiver...
Discovery: adding f525b3ea-7e87-4e2c-8df6-f8862c70bdcb
Starting UPnP Renderer front-end to MPD...
Started UPnP Renderer front-end to MPD.
Starting Shairport Sync - AirPlay Audio Receiver...
pam_unix(sudo:session): session closed for user root
Started Shairport Sync - AirPlay Audio Receiver.
pam_unix(sudo:session): session closed for user root
info: mDNS: Found device Volumio
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
info: Shairport-Sync Started
Error adding Membership: Error: addMembership EINVAL
info: Live Log process terminated: null
info: Upmpdcli Daemon Started
info: Shairport-Sync Started
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
volumio : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/sbin/ifconfig eth0
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
volumio : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/sbin/ifconfig wlan0
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
info: CoreCommandRouter::getUIConfigOnPlugin
info: CoreCommandRouter::executeOnPlugin: multiroom , getMultiroom
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
info: CoreCommandRouter::volumioGetVisibleSources
info: CoreCommandRouter::executeOnPlugin: my_music , getDisabledSources
info: CoreCommandRouter::executeOnPlugin: appearance , getUiSettings
info: CoreCommandRouter::executeOnPlugin: wizard , getShowWizard
info: CoreCommandRouter::executeOnPlugin: system , getShowWizard
info: CoreCommandRouter::executeOnPlugin: system , getPrivacySettings
[SpotifyConnect] config <>: toggling initvol/volume_ctrl
Under-voltage detected! (0x000d0005)
info: [MyVolumio PluginManager] Adding plugin bluetooth to plan premium
info: [MyVolumio PluginManager] Adding plugin multiroom to plan premium
info: [MyVolumio PluginManager] Adding plugin metavolumio to plan premium
info: [MyVolumio PluginManager] Adding plugin manifestui to plan premium
info: [MyVolumio PluginManager] Adding plugin cd_controller to plan premium
info: [MyVolumio PluginManager] Adding plugin smart_inputs to plan premium
info: [MyVolumio PluginManager] Adding plugin hi_res_audio to plan premium
info: [MyVolumio PluginManager] Adding plugin tidal to plan premium
info: [MyVolumio PluginManager] Adding plugin qobuz to plan premium
info: [MyVolumio PluginManager] Adding plugin tidalconnect to plan premium
info: [MyVolumio PluginManager] Adding plugin bluetooth to plan superstar
info: [MyVolumio PluginManager] Adding plugin multiroom to plan superstar
info: [MyVolumio PluginManager] Adding plugin metavolumio to plan superstar
info: [MyVolumio PluginManager] Adding plugin manifestui to plan superstar
info: [MyVolumio PluginManager] Adding plugin cd_controller to plan superstar
info: [MyVolumio PluginManager] Adding plugin smart_inputs to plan superstar
info: [MyVolumio PluginManager] Adding plugin hi_res_audio to plan superstar
info: [MyVolumio PluginManager] Adding plugin tidal to plan superstar
info: [MyVolumio PluginManager] Adding plugin qobuz to plan superstar
info: [MyVolumio PluginManager] Adding plugin tidalconnect to plan superstar
info: [MyVolumio PluginManager] Adding plugin bluetooth to plan virtuoso
info: [MyVolumio PluginManager] Adding plugin manifestui to plan virtuoso
info: [MyVolumio PluginManager] Adding plugin cd_controller to plan virtuoso
info: [MyVolumio PluginManager] Adding plugin tidal to plan virtuoso
info: [MyVolumio PluginManager] Adding plugin qobuz to plan virtuoso
info: [MyVolumio PluginManager] Adding plugin tidalconnect to plan virtuoso
info: Adding plugin bluetooth to MyMusic Plugins
info: Adding plugin cd_controller to MyMusic Plugins
info: Adding plugin smart_inputs to MyMusic Plugins
info: Adding plugin tidalconnect to MyMusic Plugins
info: [MyVolumio PluginManager] Loading plugin "my_volumio"...
info: [MyVolumio PluginManager] Loading plugin "streaming_services"...
info: [MyVolumio PluginManager] MyVolumio plugin successfully loaded
info: [MyVolumio PluginManager] Starting plugin system_controller.my_volumio
info: CoreCommandRouter::executeOnPlugin: system , getConfigParam
info: CoreCommandRouter::executeOnPlugin: system , getConfigParam
info: Starting MyVolumio Remote Streaming Endpoints
info: [MyVolumio PluginManager] Streaming Services plugin successfully loaded
info: [MyVolumio PluginManager] Starting plugin music_service.streaming_services
info: Streaming services startup
info: Starting Streaming Daemon
volumio : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/systemctl restart volumio-streaming-daemon.service
pam_unix(sudo:session): session opened for user root by (uid=0)
info: MyVolumio not started
info: Initializing device activation check
Stopping Volumio Streaming Daemon...
info: [MyVolumio PluginManager] MyVolumio plugin successfully started
Starting Volumio Streaming Daemon...
Started Volumio Streaming Daemon.
pam_unix(sudo:session): session closed for user root
############################
# Volumio Streaming Daemon #
# Running on port 7777     #
############################
Environment: production
info: CoreCommandRouter::executeOnPlugin: my_volumio , getMyVolumioStatus
Environment: production
info: Fetching Streaming Services browse cache
[2024-09-26 14:55:36] [connect] Successful connection
Voltage normalised (0x00080008)
[2024-09-26 14:55:36] [connect] WebSocket Connection <IP_ADDRESS>:3000 v-2 "WebSocket++/0.5.1" /socket.io/?EIO=4&transport=websocket&t=1727362536 101
info: CoreCommandRouter::executeOnPlugin: system , getPrivacySettings
info: CALLMETHOD: system_controller my_volumio retreiveBackendEventStates undefined
info: CoreCommandRouter::executeOnPlugin: my_volumio , retreiveBackendEventStates
info: Error : CoreCommandRouter::executeOnPlugin: No method [retreiveBackendEventStates] in plugin my_volumio
info: Received Get System Version
info: CoreCommandRouter::executeOnPlugin: system , getSystemVersion
[Vollibrespot] : Connecting to AP "ap-gew4.spotify.com:443"
info: CoreCommandRouter::executeOnPlugin: system , getSystemVersion
info: CoreCommandRouter::executeOnPlugin: system , getConfigParam
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
info: CoreCommandRouter::executeOnPlugin: multiroom , getMultiroom
info: CoreCommandRouter::volumioGetVisibleSources
info: CoreCommandRouter::executeOnPlugin: my_music , getDisabledSources
info: Listing playlists
[Vollibrespot] : Could not connect to server: Connection timed out (os error 110)
[Vollibrespot] : Connecting to AP "ap-gew4.spotify.com:443"
[Vollibrespot] : Connecting to AP "ap-gew4.spotify.com:443"
[Vollibrespot] : Could not connect to server: Connection timed out (os error 110)

The logs doesn't seem very informative (at least to me),
what could be the cause?
Thanks!

Answering my own issue
In case someone else has this problem,
I found the solution in this thread
https://community.spotify.com/t5/iOS-iPhone-iPad/Spotify-Connect-with-Volumio-not-working-anymore/td-p/6336298
Basically, ssh into volumio and delete spotify host from /etc/hosts


External Exercises Advert

Background
The need for external exercises to be present on the platform. This would allow candidates make applications  from external adverts.  An Issue was discovered  in the process flow while setting up an exercise.
User Story
As an admin, I would like to create an external advert, I want to select 'External' and be able to create my advert. I want to be able to put in my brief summary, full details, I want to be able to save and continue, then publish it.
I want to be able to pick and choose the fields to complete without any approval process so that I can publish an external advert exercise.
Admin was unable to edit, publish and change advert type to external advert.
Feature(s) Description
Edit button must be visible ( It was blank during the process flow  set up)

Ticket Champion
Matt Howley
Happy Story (optional/delete if not used)
To be able to Edit  and publish external adverts in a seamless manner during a process flow.

Hello Nick, as discussed earlier please see ticket details above. Any issues let me know please.

Hey team! Please add your planning poker estimate with Zenhub @warrensearle @tomlovesgithub @drieJAC @HalcyonJAC

Still getting warning text requesting certain fields be completed, which aren't necessary for external ads. No deal breaker, I can still save and continue anyway, but could mislead others into thinking the fields are required for publication
Screen shot.docx
My email address is automatically being listed as the exercise mailbox under contacts. If I go to delete or change it, I can't because the contacts page won't allow me to save without filling in all fields, none of which are necessary for external adverts.

@MattHowley
Thank you for sharing the screenshot.
It seems that you may use the preview link of another ticket (feature-2154), so can't see the changes.

Could you help me to go to this preview link and test again: https://jac-admin-develop--pr2301-feat-2254-streamline-0we56wtz.web.app/exercises ?
Thanks

@KoWeiJAC - looking good on admin. On the apply side, the apply button (and associated warning text 'By clicking the apply button you are agreeing that you have read all the information on the exercise information page and any guidance referred to.') shouldn't display, even when the exercise is live, as the JAC is not responsible for applications for external vacancies - we are simply advertising on their behalf, and will direct those wanting to apply to the relevant external vacancy page.

@KoWeiJAC What's the status of this ticket pls?

@MattHowley I have fixed it. Could you test it again, please?

Looks good. Thanks @HalcyonJAC

@HalcyonJAC Following Matt's approval, happy for this to be closed - no further UT required.


Add Identify keyboard shortcut to play observation's sound

#3419
Set focus to first <audio> element and play associated sound file. If an <audio> element is already active, the togglePlayFirstSound action exits early to avoid interfering with default processing.

Firefox, Chromium and Safari should now behave as described (at least on macOS 12 and Ubuntu 20.04):

SPACE will play the sound and focus on the first player. Hitting SPACE again will pause.
To avoid confusion, I removed the processing for subsequent <audio> elements; this makes the behavior Play first sound rather than Play first / current sound as previously implemented.

Implementation

Binding to keydown instead of keyup suppressed the Firefox shortcut for Toggle Play / Pause,

Thanks, @grfeller! Sorry it took me a while to get back to this.

@kueda thanks for your help and feedback in making this PR successful.


Allow PHP 8.0

IMHO we could simply widen the constraint.

I'm a fan of using the >=7.4 constraint as well but will merge as is 😄

Hopefully we won't need this bundle anymore when PHP 9 is around :wink:.


Error in example nuget locals all --list command

nuget locals all -list is an incorrect command invocation (missing second - in --list)

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

ID: 71b49477-cafa-d7d4-76fe-83aff43a3f47
Version Independent ID: 68d7a416-1397-8cf3-bead-e3cd328aca48
Content: How to manage the global packages, cache, temp folders in NuGet
Content Source: docs/consume-packages/managing-the-global-packages-and-cache-folders.md
Service: nuget
GitHub Login: @JonDouglas
Microsoft Alias: jodou

@sowa705 are you sure?  What error are you getting?
nuget.exe uses powershell conventions, which is a single -.  the dotnet CLI uses GNU conventions, whichis double --.  I believe the docs to be correct:
D:\src\NuGet.Client>nuget.exe locals all -list
http-cache: C:\Users\zivkan\AppData\Local\NuGet\v3-cache
global-packages: C:\Users\zivkan\.nuget\packages\
temp: C:\Users\zivkan\AppData\Local\Temp\NuGetScratch
plugins-cache: C:\Users\zivkan\AppData\Local\NuGet\plugins-cache


Fixed code quality issues

Description
Hi :wave:
I ran the DeepSource analysis on the forked copy of this repo and found some interesting code quality issues.
Motivation and Context
Some of the issues I have fixed boost minor performance and a few removes the anti-patterns in code.
Types of changes

[x] Fix bugs
[ ] Add new feature
[ ] Update documentation

Summary of changes

Removed length check in favour of truthiness of the object
Removed unnecessary use of comprehension
Removed methods with unnecessary super delegation
Used literal syntax to create data structure
Refactored unnecessary else / elif when if block has a continue statement
Refactored the comparison involving not
Added .deepsource.toml file

Hey @Derek-Wds :wave:
The fixes in this PR were made using DeepSource Auto-fix feature.
Can you give DeepSource a try on this repo? :sparkles:
The repo already contains the configuration file. All you need to do is Signup here and then activate analysis here.
Activating analysis will help you to continuously analyze the repo for code quality issues and you can fix most of the fix using auto-fix feature.

Hi @you-n-g @Derek-Wds :wave:
Did you try out DeepSource? I'd like to get your feedback :sparkles:

Hi @withshubh
Thanks for your adivce.
I setup it just now. But I'm not sure if it is right.

Hi @you-n-g
Follow these steps:

Install DeepSource on your repository here.
Activate analysis here.
you don't need to create the .deepsource.toml config file since the repo already has one through this PR.

And there you go :sparkling_heart:

@withshubh
Thanks so much!
DeepSource is really  a powerful tool.
I can't manage the account of microsoft.  But I install DeepSource on my personal account.
It has been installed here


osx-arm64 migration

Attempting to continue migration.
Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

closes #19

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

I suspect the configure script's use xml2-config to determine the libxml2 location is messing with the cross-compiling. Fortunately, the script includes an option to override this behavior:

# This script will query 'pkg-config' for the required cflags and ldflags.
# If pkg-config is unavailable or does not find the library, try setting
# INCLUDE_DIR and LIB_DIR manually via e.g:
# R CMD INSTALL --configure-vars='INCLUDE_DIR=/.../include LIB_DIR=/.../lib'

Will attempt to use this override to with the $PREFIX/lib and $PREFIX/include.
Also, shouldn't this recipe require libxml2? I suspect it's been fine since it is a r-base dependency, but it really is an immediate dependency for this package.

Summarizing so far, none of these were the issue:

libxml2 dependency
use of xml2-config
configure.{guess,sub}

Other idea is to see if we can tell R not to attempt loading the library when not running native. That is, the installation procedure appears to be attempting to load the library, which is problematic because the architecture mismatch.

@colinbrislawn @conda-forge/r ready for review 🙏
Narrowed down the osx-arm64 failure to the library self-loading while installing the help. For now, this skips the help installation in cross-compilation settings. I propose we release this for now (since other major R packages are waiting for this to be available), but open a separate issue to eventually get this built with a proper help documentation.
On the plus side, this recipe now runs the testthat unit tests on all native builds.

@colinbrislawn ready to merge. I'll keep working on getting the help built (#24).


Not able to upload image while creating product .

When try uploading image from app , it shows that its getting uploaded , but after the publishing images disappear .

Fixed in 1.0.3


⚠ Turnos 24x7 has degraded performance

In a7dc508, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 993 ms

Resolved: Turnos 24x7 performance has improved in 08ec623.


BearerTokenInterceptor on concurent requests? In KMM

I am using BearerTokenInterceptor class in our KMM project.
BearerTokenInterceptor(object : TokenProvider {
                                override suspend fun currentToken(): String {
                                    return authenticating.getCurrentJwtToken() ?: ""
                                }

                                override suspend fun refreshToken(previousToken: String): String {
                                    return refreshTokenHelper.refreshToken()
                                }
                            }),

And it works perfectly when we only fire one request, but when firing 2 requests at the same time, we have this issue, and we're unsure where is the problem, on the backend side, or on the client.
The code on android what will start the requests
  private fun startReq() {
        GlobalScope.launch {
            backend.....request1.execute() // some suspend function that does the apollo query
        }
        GlobalScope.launch {
            backend.....request2.execute() // same as above
        }
    }

I see in the logs that both requests fire the same exact refresh token request, with the same refresh token, one is successful, one failes, because the refresh token is no longer valid (is one time use).
I see in the source of the interceptor that it has some kotlinx.coroutines.sync.Mutex, is this supported for KMM ?
Thank you!

Hi 👋  Thanks for reporting this!
I think this can be expected from the way it is implemented, 2 requests can still be executed in parallel with the same expired auth token, and will both result in 401, and then will both call refreshToken - even if that part is guarded by the mutex, only one of them will succeed in your case.
I think what you could do is in your implementation of TokenProvider.refreshToken(), even if the refresh fails, still return the auth token - which should be valid at that point.
This means you'll still have 2 401 and 2 refreshes, only the first one will work, but both retries should work, and so that will be transparent to the caller.
Let me know if that makes sense.

Hi 👋 Thanks for reporting this!
I think this can be expected from the way it is implemented, 2 requests can still be executed in parallel with the same expired auth token, and will both result in 401, and then will both call refreshToken - even if that part is guarded by the mutex, only one of them will succeed in your case.
I think what you could do is in your implementation of TokenProvider.refreshToken(), even if the refresh fails, still return the auth token - which should be valid at that point.
This means you'll still have 2 401 and 2 refreshes, only the first one will work, but both retries should work, and so that will be transparent to the caller.
Let me know if that makes sense.

Very very interesting idea, I've added something like this, and what's even more interesting, is that now I can't reproduce the bug anymore, and it feels like the mutex is actually locking, maybe because I've added some extra variables to check if there's any current ongoing refresh? Or am I just going nuts
suspend fun refreshToken(): String {
    val ongoingRefresh = currentlyRefreshingToken
    currentlyRefreshingToken = true // added this global variable in this class
    logToConsole(text = "Attempting to refresh access token")
    val mutation = RefreshTokenMutation(refreshToken = getCurrentRefreshToken() ?: "")
    try {
        val response = apolloClient.mutation(mutation).executeOrThrowError()
        saveRefreshToken(response.authRefresh.refreshToken)
        saveJwtToken(response.authRefresh.accessToken)
        logToConsole(text = "Finished refreshing access token, auth overriding: $authOverriding")
        return response.authRefresh.accessToken
    } catch (e: Exception) {
        if (ongoingRefresh) {
            logToConsole(text = "We already refreshed this, so we just use the new token")
            return authenticating.getCurrentJwtToken() ?: throw Exception("Missing JWT token")
        }
        authenticating.logOutUser()
        throw e
    } finally {
        currentlyRefreshingToken = false
    }
}

I'm not 100% sure about the ongoingRefresh test but yes that was the idea.
One thing we'd like to mention is that we'll probably deprecate BearerTokenInterceptor in the future, because as you have noticed, it is not well tested, and it looks like its implementation may be a bit too simplistic for most apps. It is good to keep as an example of an interceptor to deal with tokens, but we're not confident that it should really be used 'as is' in prod.

This PR shows a more involved version of the BearerTokenInterceptor. Because there are so many possible implementations out there, we decided to deprecated BearerTokenInterceptor as it cannot work for all possible use cases out there.
@boldijar looks like you got a working implementation on your side? Is it ok if I close this issue?

@boldijar it's really hard to tell without more details of your server. What's more, this lib is more about GraphQL than the subtle oauth differences so things like authorization belong to somewhere else. AuthorizationInterceptor is a sample provided as inspiration but you should definitely test it/adapt it for your use case.
It looked like you had a working solution? If yes, I would keep it. Don't fix it if it ain't broke. If not then AuthorizationInterceptor is a good place to start looking.

Yep, all good! Thank you


Only allow ordered containers for just

Currently just allows all implementors of Container. This can be a footgun, if someone were to pass a HashSet - all tokens in the set would be required in a non-deterministic order. It may be a good idea to add a marker trait like OrderedContainer and require it on just.

Yes, I definitely agree with this.

Fixed by #154


Replace impls_in_trait query with smarter use of CrateImplDefs

impls_in_trait was allocating a whopping ~400 MB of RAM when running analysis-stats on r-a itself.
Remove it, instead adding a query that computes a summary CrateImplDefs map for all transitive dependencies. This can probably still be made more efficient, but this already reduces the peak memory usage by 25% without much performance impact on analysis-stats.
Before:
Total: 34.962107188s, 2083mb allocated 2141mb resident
   422mb ImplsForTraitQuery (deps)
   250mb CrateDefMapQueryQuery
   147mb MacroArgQuery
   140mb TraitSolveQuery (deps)
    68mb InferQueryQuery (deps)
    62mb ImplDatumQuery (deps)

After:
Total: 35.261100358s, 1520mb allocated 1569mb resident
   250mb CrateDefMapQueryQuery
   147mb MacroArgQuery
   144mb TraitSolveQuery (deps)
    68mb InferQueryQuery (deps)
    61mb ImplDatumQuery (deps)
    45mb BodyQuery
    45mb ImplDatumQuery

Hmm this means less incrementality though -- any change to impls will cause all trait queries to be recalculated.

Hmm this means less incrementality though -- any change to impls will cause all trait queries to be recalculated.

I think that by itself is fine, these changes seem pretty rare. Though, because of transitivity the cost of recalculation might be high -- we traverse all deps. Ideally, everything should be bound to  a single crate.

I've pushed a few commits that switch to a recursive approach, which should give better incrementality (at a slight cost in memory usage). It might be a good idea to use a hash set instead of a vec now...

@matklad anything left to do here?

bors r+


Determine where sandbox app source code lives

This will determine when/how it can be updated. The most likely candidate is in flutter/flutter itself.
This would restrict plugin updates to the same cadence on the stable channel: If a plugin bumps a point version we'd need to do a hotfix release.
Putting it in flutter/flutter makes it easier for users to depend on the plugin set and for the tool to verify the plugin list

Iceboxing for now