testcafe failing to connect when using --proxy option

What is your Test Scenario?
I'm trying to run testcafe in our pipeline (Semaphore) using a docker image based on the official one, where the only additions are copying our tests inside it and install some other additional npm packages used by them. Those tests run against a test environment, that for security reasons can only be accessed either via VPN or a proxy.  I'm using the --proxy flag but the test run fails.
From that same container, if I run curl https://mytestserver.dev --proxy $HTTP_PROXY it connects without problems, so does a Cypress container running in the same pipeline.
What is the Current behavior?
Tests fail to run, with the message
ERROR Unable to establish one or more of the specified browser connections.
1 of 1 browser connections have not been established:
- chromium:headless

Hints:
- Use the "browserInitTimeout" option to allow more time for the browser to start. The timeout is set to 2 minutes for local browsers and 6 minutes for remote browsers.
- The error can also be caused by network issues or remote device failure. Make sure that the connection is stable and the remote device can be reached.

As per suggestion here I set
DEBUG=hammerhead:*,testcafe:*

And the log is:
021-07-07T15:23:44.572Z testcafe:utils:temp-directory Found temp directories: []
2021-07-07T15:23:44.574Z testcafe:utils:temp-directory Temp directory path:  /tmp/testcafe/chrome-profile-128Nvnnsbk1AEpG
2021-07-07T15:23:44.587Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:46.423Z testcafe:compiler:typescript version: 3.9.10
2021-07-07T15:23:46.425Z testcafe:compiler:typescript options: [Object: null prototype] {
  experimentalDecorators: true,
  emitDecoratorMetadata: true,
  allowJs: true,
  pretty: true,
  inlineSourceMap: true,
  noImplicitAny: false,
  module: 1,
  moduleResolution: 2,
  target: 3,
  jsx: 2,
  suppressOutputPathCheck: true,
  skipLibCheck: true
}
2021-07-07T15:23:48.119Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.120Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.121Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.122Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.124Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.221Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.222Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.223Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.224Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.225Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.226Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.227Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.228Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.230Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.232Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.232Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.234Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.235Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.236Z testcafe:compiler:typescript path: "typescript"
2021-07-07T15:23:48.245Z testcafe:bootstrapper tests compilation took 3.67 s
2021-07-07T15:25:44.563Z testcafe:browser:connection:469Ca~Y status changed to 'closing'
2021-07-07T15:25:44.585Z testcafe:browser:connection:469Ca~Y TypeError: Cannot read property 'config' of undefined
    at BrowserProviderPluginHost.isHeadlessBrowser (/app/node_modules/testcafe/src/browser/provider/built-in/dedicated/base.js:65:51)
    at BrowserProvider.canUseDefaultWindowActions (/app/node_modules/testcafe/src/browser/provider/index.ts:260:53)
    at BrowserProvider.closeBrowser (/app/node_modules/testcafe/src/browser/provider/index.ts:323:44)
    at BrowserConnection._closeBrowser (/app/node_modules/testcafe/src/browser/connection/index.ts:208:13)
    at BrowserConnection.close (/app/node_modules/testcafe/src/browser/connection/index.ts:410:9)
    at Function._closeConnection (/app/node_modules/testcafe/src/runner/browser-set.ts:55:9)
    at async Promise.all (index 0)
    at BrowserSet.dispose (/app/node_modules/testcafe/src/runner/browser-set.ts:163:9)
    at Function.from (/app/node_modules/testcafe/src/runner/browser-set.ts:108:13)
    at async Promise.all (index 0)
2021-07-07T15:25:44.586Z testcafe:browser:connection:469Ca~Y status changed to 'closed'

I had the chance to get the logs in our proxy server, and found out this entry coming from the ip in semaphore where the container is running:
TCP_DENIED/403 4464 GET http://<IP_ADDRESS>:1337/browser/connect/sYNp3vU - HIER_NONE/- text/html

Denying access to that request is logical as it points to a local network address.
Incidentally I tried using firefox:headless just in case but found out that the --proxy option is completely ignored.
What is the Expected behavior?
I would expect the hammerhead proxy to issue requests to our proxy with the urls that our tests are visiting, not a local ip address.

Your Environment details:

testcafe version:                   1.14.2
node.js version:                    14.16.1
command-line arguments:  docker run --rm -v ~/results:/app/results --env HTTP_PROXY=$HTTP_PROXY $ECR_REPO:$TESTCAFE_IMAGE chromium:headless --proxy $HTTP_PROXY
platform and version:          Linux Ubuntu 18.04.1 VM in Semaphore
other:

I even tried to use the option --proxy-bypass with that initial request to a local IP address, but didn't work either.

Got the same issue from my end - had to downgrade to  testcafe: 1.14.0 until this is fixed.

I can confirm since version 1.14.1:
Cli options:
--proxy and --proxy-bypass are ignored
Config file options (.testcaferc.json):
proxy
proxyBypass
in both cases proxy setup variables are ignored.

@s0leris Interestingly, I downgraded and it worked for me just in Firefox, keeps failing in chromium.

@ejosafat: on my hands I can confirm that v. 1.14.0 is working well on:

Firefox (Linux, Mac)
Chrome (Linux, Mac)
Chromium (Linux, Mac)
Safari (Mac)

@ejosafat: on my hands I can confirm that v. 1.14.0 is working well on:

Chromium (Linux, Mac)

it's that installed in your host? I'm using Chromium from the official docker image (1.14.0), maybe there is some problem with the chromium version installed there.

Hi folks,
Need to make sure that the --proxy and --proxy-bypass parameters are passed correctly. To check it, do the following:

open the node_modules/testcafe/lib/lib/runner/index.js file
find the run method
add the console.dir statement in the following way:

...
this.configuration.mergeOptions(options);
console.dir(this.configuration);
...

After that, please run your tests and share the console output.

@miherlosev, this is the output:
TestCafeConfiguration {   _options: {     browsers: Option { name: 'browsers', value: [Array], source: 'Input' },     src: Option { name: 'src', value: [Array], source: 'Input' },     screenshots: Option { name: 'screenshots', value: [Object], source: 'Input' },     skipJsErrors: Option { name: 'skipJsErrors', value: true, source: 'Input' },     debug: Option { name: 'debug', value: true, source: 'Configuration' },     concurrency: Option { name: 'concurrency', value: 1, source: 'Configuration' },     selectorTimeOut: Option {       name: 'selectorTimeOut',       value: 60000,       source: 'Configuration'     },     assertionTimeOut: Option {       name: 'assertionTimeOut',       value: 5000,       source: 'Configuration'     },     pageLoadTimeOut: Option {       name: 'pageLoadTimeOut',       value: 5000,       source: 'Configuration'     },     pageRequestTimeout: Option {       name: 'pageRequestTimeout',       value: 5000,       source: 'Configuration'     },     proxy: Option {       name: 'proxy',       value: 'odindevs:d2MRG7p-QzBp3g8N@<IP_ADDRESS>:3128',       source: 'Input'     },     'proxy-bypass': Option {       name: 'proxy-bypass',       value: '<IP_ADDRESS>',       source: 'Configuration'     },     reporter: Option {       name: 'reporter',       value: [Array],       source: 'Configuration'     },     skipUncaughtErrors: Option {       name: 'skipUncaughtErrors',       value: false,       source: 'Configuration'     },     developmentMode: Option {       name: 'developmentMode',       value: true,       source: 'Configuration'     },     retryTestPages: Option {       name: 'retryTestPages',       value: false,       source: 'Configuration'     },     cache: Option { name: 'cache', value: false, source: 'Configuration' },     filter: Option { name: 'filter', value: null, source: 'Configuration' },     hostname: Option { name: 'hostname', value: '<IP_ADDRESS>', source: 'Input' },     port1: Option { name: 'port1', value: 61114, source: 'Input' },     port2: Option { name: 'port2', value: 61115, source: 'Input' },     ssl: Option { name: 'ssl', value: undefined, source: 'Input' },     experimentalCompilerService: Option {       name: 'experimentalCompilerService',       value: undefined,       source: 'Input'     },     configFile: Option { name: 'configFile', value: undefined, source: 'Input' },     proxyBypass: Option { name: 'proxyBypass', value: '<IP_ADDRESS>', source: 'Input' },     tsConfigPath: Option { name: 'tsConfigPath', value: undefined, source: 'Input' },     videoPath: Option { name: 'videoPath', value: undefined, source: 'Input' },     videoOptions: Option { name: 'videoOptions', value: undefined, source: 'Input' },     videoEncodingOptions: Option {       name: 'videoEncodingOptions',       value: undefined,       source: 'Input'     },     appCommand: Option { name: 'appCommand', value: undefined, source: 'Input' },     appInitDelay: Option {       name: 'appInitDelay',       value: 1000,       source: 'Configuration'     },     clientScripts: Option { name: 'clientScripts', value: undefined, source: 'Input' },     compilerOptions: Option {       name: 'compilerOptions',       value: [Object],       source: 'Input'     },     quarantineMode: Option {       name: 'quarantineMode',       value: undefined,       source: 'Input'     },     debugMode: Option { name: 'debugMode', value: false, source: 'Input' },     debugOnFail: Option { name: 'debugOnFail', value: false, source: 'Input' },     selectorTimeout: Option {       name: 'selectorTimeout',       value: 10000,       source: 'Configuration'     },     assertionTimeout: Option {       name: 'assertionTimeout',       value: 3000,       source: 'Configuration'     },     pageLoadTimeout: Option {       name: 'pageLoadTimeout',       value: 3000,       source: 'Configuration'     },     browserInitTimeout: Option {       name: 'browserInitTimeout',       value: undefined,       source: 'Input'     },     speed: Option { name: 'speed', value: 1, source: 'Configuration' },     stopOnFirstFail: Option { name: 'stopOnFirstFail', value: false, source: 'Input' },     disablePageCaching: Option {       name: 'disablePageCaching',       value: false,       source: 'Input'     },     disablePageReloads: Option {       name: 'disablePageReloads',       value: false,       source: 'Input'     },     disableScreenshots: Option {       name: 'disableScreenshots',       value: false,       source: 'Input'     },     disableMultipleWindows: Option {       name: 'disableMultipleWindows',       value: false,       source: 'Input'     },     ajaxRequestTimeout: Option {       name: 'ajaxRequestTimeout',       value: undefined,       source: 'Input'     },     takeScreenshotsOnFails: Option {       name: 'takeScreenshotsOnFails',       value: false,       source: 'Configuration'     }   },   _filePath: '/Users/enrico/Documents/OdinServices/BitBucket/e2e-automation/.testcaferc.json',   _overriddenOptions: [] }

I can confirm that proxy and proxy value are written on output (I have changed values of --proxy for security reason)

So I tested using the latest version, 1.15.0, within the latest testcafe docker image. Firefox seems to be working now, even without the --proxy-bypass option; however, chromium still fails to run (with --proxy and --proxy-bypass options in the command line). The configuration output in that last case is:
TestCafeConfiguration {
  _options: {
    src: Option { name: 'src', value: [Array], source: 'Configuration' },
    videoPath: Option {
      name: 'videoPath',
      value: 'results/videos',
      source: 'Configuration'
    },
    videoOptions: Option {
      name: 'videoOptions',
      value: [Object],
      source: 'Configuration'
    },
    screenshots: Option {
      name: 'screenshots',
      value: [Object],
      source: 'Configuration'
    },
    selectorTimeout: Option {
      name: 'selectorTimeout',
      value: 5000,
      source: 'Configuration'
    },
    reporter: Option {
      name: 'reporter',
      value: [Array],
      source: 'Configuration'
    },
    developmentMode: Option {
      name: 'developmentMode',
      value: false,
      source: 'Configuration'
    },
    retryTestPages: Option {
      name: 'retryTestPages',
      value: false,
      source: 'Configuration'
    },
    cache: Option { name: 'cache', value: false, source: 'Configuration' },
    filter: Option { name: 'filter', value: null, source: 'Configuration' },
    hostname: Option { name: 'hostname', value: '<IP_ADDRESS>', source: 'Input' },
    port1: Option { name: 'port1', value: 35075, source: 'Input' },
    port2: Option { name: 'port2', value: 42109, source: 'Input' },
    ssl: Option { name: 'ssl', value: undefined, source: 'Input' },
    experimentalCompilerService: Option {
      name: 'experimentalCompilerService',
      value: undefined,
      source: 'Input'
    },
    configFile: Option { name: 'configFile', value: undefined, source: 'Input' },
    skipJsErrors: Option { name: 'skipJsErrors', value: undefined, source: 'Input' },
    skipUncaughtErrors: Option {
      name: 'skipUncaughtErrors',
      value: undefined,
      source: 'Input'
    },
    quarantineMode: Option {
      name: 'quarantineMode',
      value: undefined,
      source: 'Input'
    },
    debugMode: Option { name: 'debugMode', value: undefined, source: 'Input' },
    debugOnFail: Option { name: 'debugOnFail', value: undefined, source: 'Input' },
    assertionTimeout: Option {
      name: 'assertionTimeout',
      value: undefined,
      source: 'Input'
    },
    pageLoadTimeout: Option {
      name: 'pageLoadTimeout',
      value: undefined,
      source: 'Input'
    },
    browserInitTimeout: Option {
      name: 'browserInitTimeout',
      value: undefined,
      source: 'Input'
    },
    speed: Option { name: 'speed', value: undefined, source: 'Input' },
    stopOnFirstFail: Option {
      name: 'stopOnFirstFail',
      value: undefined,
      source: 'Input'
    },
    disablePageCaching: Option {
      name: 'disablePageCaching',
      value: undefined,
      source: 'Input'
    },
    disablePageReloads: Option {
      name: 'disablePageReloads',
      value: undefined,
      source: 'Input'
    },
    disableScreenshots: Option {
      name: 'disableScreenshots',
      value: undefined,
      source: 'Input'
    },
    disableMultipleWindows: Option {
      name: 'disableMultipleWindows',
      value: undefined,
      source: 'Input'
    },
    pageRequestTimeout: Option {
      name: 'pageRequestTimeout',
      value: undefined,
      source: 'Input'
    },
    ajaxRequestTimeout: Option {
      name: 'ajaxRequestTimeout',
      value: undefined,
      source: 'Input'
    }
  },
  _filePath: '/app/.testcaferc.json',
  _overriddenOptions: []
}

Folks,
We've tested the proxy, proxy-bypass settings with a real proxy server (see our test here).
If you have issues with these settings, this means you specify them incorrectly or there is incompatibility with the proxy server in use.
Please update to the latest TestCafe version (.1.15.0) and make sure you pass proxy settings correctly (see https://github.com/DevExpress/testcafe/issues/6363#issuecomment-878052970). If the configuration output doesn't contain the proxy, proxy-bypass fields, you configured them incorrectly. Refer to the documentation to resolve the issue.
If you are using Docker, CI, or some non-local environment, please refer to its documentation to configure proxy settings correctly.
If you are sure that the issue relates to TestCafe and you can share an example that we can run locally, please feel free to create a separate issue.

I used the same command line to run 1.15.0, just replacing the browser used, in Firefox worked, in Chromium not, I would say that if the flags or the proxy server configuration were wrong, it wouldn't have worked in Firefox. Unfortunately, for security reasons, I can't share an example that runs against our proxy.
However, I do appreciate you looking into this matter and the quick response. Thanks so much!

@miherlosev: first of all, thank you so much for your support.
I tried to use v 1.15.0 following your instructions this morning, but unfortunately it doesn't work on my environment, where with 1.14.0 running perfectly.
My question is where I can find the parser of variables, because it looks weird that just changing my package.json file replacing testcafe version from 1.14.0 to 1.14.1 (until version 1.15.0) I got different behaviour.
I would like analize differences between to version on a proxy variable parser.
Another interesting point is that between 1.14.0 and 1.14.1 (until version 1.15.0) looks that even variables about proxy, and proxyBypass on .testcaferc.json file are ignored.

So I tested using the latest version, 1.15.0, within the latest testcafe docker image. Firefox seems to be working now, even without the --proxy-bypass option; however, chromium still fails to run (with --proxy and --proxy-bypass options in the command line). The configuration output in that last case is:
TestCafeConfiguration {
  _options: {
    src: Option { name: 'src', value: [Array], source: 'Configuration' },
    videoPath: Option {
      name: 'videoPath',
      value: 'results/videos',
      source: 'Configuration'
    },
    videoOptions: Option {
      name: 'videoOptions',
      value: [Object],
      source: 'Configuration'
    },
    screenshots: Option {
      name: 'screenshots',
      value: [Object],
      source: 'Configuration'
    },
    selectorTimeout: Option {
      name: 'selectorTimeout',
      value: 5000,
      source: 'Configuration'
    },
    reporter: Option {
      name: 'reporter',
      value: [Array],
      source: 'Configuration'
    },
    developmentMode: Option {
      name: 'developmentMode',
      value: false,
      source: 'Configuration'
    },
    retryTestPages: Option {
      name: 'retryTestPages',
      value: false,
      source: 'Configuration'
    },
    cache: Option { name: 'cache', value: false, source: 'Configuration' },
    filter: Option { name: 'filter', value: null, source: 'Configuration' },
    hostname: Option { name: 'hostname', value: '<IP_ADDRESS>', source: 'Input' },
    port1: Option { name: 'port1', value: 35075, source: 'Input' },
    port2: Option { name: 'port2', value: 42109, source: 'Input' },
    ssl: Option { name: 'ssl', value: undefined, source: 'Input' },
    experimentalCompilerService: Option {
      name: 'experimentalCompilerService',
      value: undefined,
      source: 'Input'
    },
    configFile: Option { name: 'configFile', value: undefined, source: 'Input' },
    skipJsErrors: Option { name: 'skipJsErrors', value: undefined, source: 'Input' },
    skipUncaughtErrors: Option {
      name: 'skipUncaughtErrors',
      value: undefined,
      source: 'Input'
    },
    quarantineMode: Option {
      name: 'quarantineMode',
      value: undefined,
      source: 'Input'
    },
    debugMode: Option { name: 'debugMode', value: undefined, source: 'Input' },
    debugOnFail: Option { name: 'debugOnFail', value: undefined, source: 'Input' },
    assertionTimeout: Option {
      name: 'assertionTimeout',
      value: undefined,
      source: 'Input'
    },
    pageLoadTimeout: Option {
      name: 'pageLoadTimeout',
      value: undefined,
      source: 'Input'
    },
    browserInitTimeout: Option {
      name: 'browserInitTimeout',
      value: undefined,
      source: 'Input'
    },
    speed: Option { name: 'speed', value: undefined, source: 'Input' },
    stopOnFirstFail: Option {
      name: 'stopOnFirstFail',
      value: undefined,
      source: 'Input'
    },
    disablePageCaching: Option {
      name: 'disablePageCaching',
      value: undefined,
      source: 'Input'
    },
    disablePageReloads: Option {
      name: 'disablePageReloads',
      value: undefined,
      source: 'Input'
    },
    disableScreenshots: Option {
      name: 'disableScreenshots',
      value: undefined,
      source: 'Input'
    },
    disableMultipleWindows: Option {
      name: 'disableMultipleWindows',
      value: undefined,
      source: 'Input'
    },
    pageRequestTimeout: Option {
      name: 'pageRequestTimeout',
      value: undefined,
      source: 'Input'
    },
    ajaxRequestTimeout: Option {
      name: 'ajaxRequestTimeout',
      value: undefined,
      source: 'Input'
    }
  },
  _filePath: '/app/.testcaferc.json',
  _overriddenOptions: []
}

I can't see in your output proxy, and proxy-ypass definitions.
You should have output like this in case of proxy, and proxyBypass use:
CLI case:
`
......
proxy: Option {
name: 'proxy',
value: 'odindevs:d2MRG7p-QzBp3g8N@<IP_ADDRESS>:3128',
source: 'Input'
},
proxyBypass: Option { name: 'proxyBypass', value: '<IP_ADDRESS>', source: 'Input' },
.....
`
Configuration case:
`
......
proxy: Option {
name: 'proxy',
value: 'odindevs:d2MRG7p-QzBp3g8N@<IP_ADDRESS>:3128',
source: 'Configuration'
},
proxyBypass: Option { name: 'proxyBypass', value: '<IP_ADDRESS>', source: 'Configuration' },
.....
`

@sly4you, that's the interesting bit. I can't see the options there; however, I'm running this (from within the docker container):
$ testcafe chromium:headless --proxy $HTTP_PROXY --proxy-bypass <IP_ADDRESS>

@sly4you, that's the interesting bit. I can't see the options there; however, I'm running this (from within the docker container):
$ testcafe chromium:headless --proxy $HTTP_PROXY --proxy-bypass <IP_ADDRESS>

That's the reason because of your issues.
It's so clear that from version 1.14.1 options about proxy are not working, unfortunately I don't have enough knowledge to look around the code and discover this bug.
Here @miherlosev has written that issue is solved, but output of configuration is still saying differently.
:(

My question is where I can find the parser of variables, because it looks weird that just changing my package.json file replacing testcafe version from 1.14.0 to 1.14.1 (until version 1.15.0) I got different behaviour.

The command-line argument parser is located in the 'node_modules/testcafe/lib/cli/argument-parser.ts' file.
You can debug the parsing process using the console.log statement.
Judging by your description, there is some issue with argument parsing. You can create a docker image with which it's possible to reproduce the issue, share it with us, and specify your environment details (operation system, version, terminal name, node version). We will investigate this.

My question is where I can find the parser of variables, because it looks weird that just changing my package.json file replacing testcafe version from 1.14.0 to 1.14.1 (until version 1.15.0) I got different behaviour.

The command-line argument parser is located in the 'node_modules/testcafe/lib/cli/argument-parser.ts' file.
You can debug the parsing process using the console.log statement.
Judging by your description, there is some issue with argument parsing. You can create a docker image with which it's possible to reproduce the issue, share it with us, and specify your environment details (operation system, version, terminal name, node version). We will investigate this.

I think I found the problem, and it's related not during a variables parsing, but during variable merge on file
'node_modules/testcafe/lib/runner/index.js' on function -->> useProxy() <--
Version 1.14.0 (lines 374,377)
   useProxy(proxy, proxyBypass) {         this.configuration.mergeOptions({ proxy, proxyBypass });         return this;     }
Version 1.15.0 (lines 436,440)
   useProxy(proxy, proxyBypass) {         this._options.proxy = proxy;         this._options.proxyBypass = proxyBypass;         return this;     }
It looks like that there is no merge on configuration options on last version (1.15.0), and result is that final configuration is without proxy/proxyBypass options.
I don't have lot of time to analyse what's the meaning about " this._options.proxy = proxy;", and "this._options.proxyBypass = proxyBypass;", so as a test I have simply modified version 1.15.0 function on this way:
   useProxy(proxy, proxyBypass) {         this._options.proxy = proxy;         this._options.proxyBypass = proxyBypass;         this.configuration.mergeOptions({ proxy, proxyBypass });         return this;     }
And everything is back to work well.
I hope it will be useful for you.
Cheers :)

Thank you for the provided information. I've reproduced the problem.
For team:
The proxy settings specified in the command-line interface will not be applied to the runner.
testcafe chrome --proxy proxy-host --proxy-bypass <IP_ADDRESS>

Thank you for the provided information. I've reproduced the problem.
For team:
The proxy settings specified in the command-line interface will not be applied to the runner.
testcafe chrome --proxy proxy-host --proxy-bypass <IP_ADDRESS>

Even if you have proxy options on .testcaferc.json instead of cli it doesn't work.

Hi there. We found the issue with the proxy and it's related to the HTTP/2 protocol. This issue will be resolved in the testcafe-hammerhead (https://github.com/DevExpress/testcafe-hammerhead/issues/2668). Based on your error, it seems to me that this is not your case. In your case, the browser connections have not been established. This may mean that there is an issue with your firewall. Try using --hostname localhost in your command-line interface.

Thanks for looking into this.
We don't use a firewall. The issue I can see in our proxy logs is that Testcafe is making request connections to a local IP address (<IP_ADDRESS>, which is the IP of the docker container) through the proxy server when it should send requests only to our testing server. Adding the --proxy-bypass <IP_ADDRESS> is not working at all. Using --hostname localhost doesn't work either. And that it's using Chromium; if I use Firefox, it just ignores the proxy options altogether, so it tries to connect to the testing server without going through the proxy.
However, if I downgrade to the official testcafe docker image tagged 1.14.0, it works in Firefox, but not in Chromium which stills tries to request the local ip through the proxy.
It looks to me like a regression bug in testcafe, not a firewall problem.

Sorry, but --hostname doesn't work right now. PR with this fix is ready and waiting for review. After that, you need to try again to run tests with this command. Your error is related to a browser connection, but we don't use a proxy for this. It means that the error isn't in the proxy.

@ejosafat , also, you can try to assign [hostname in the configuration file](Also, you can try to assign hostname in the configuration file. This should work now.
). This should work now.

Hey everyone,
Been following along, added the --hostname localhost using 1.15.2 but still having the same issue described above, the proxy setting in the testcaferc file or the command line is being ignored. Proxy setting works well on 1.14.0 using Firefox. Did anyone find a solution? Thanks in advance.

Hi @cyanbutton , please describe what kind of error you get.

@cyanbutton, please try to update your testcafe to the 1.15.3 version and run the tests again. If this doesn't help, please attach your testcafe log here.

Folks,
The issue was in the code that outputs debug information. Try running your tests with the latest TestCafe version (1.15.3).
If the issue persists, please share the debug output.
To do this:

download a custom TestCafe build.
rename it to testcafe-1.15.3.tgz.
execute the npm i testcafe-1.15.3.tgz command in your terminal.
set the following environment variable: set DEBUG=testcafe:cli*,testcafe:runner*.
redirect the debug output to the file: testcafe chrome test.js 2>log.txt.
share with  us the file with debug information.

Hey everyone,
1.15.3 has the same issue, even with --disable-http2
Please find attached the log, FYI I removed the proxy value.

@cyanbutton
We first thought that CLI options were incorrectly overridden from the configuration file.
Judging by the log, overriding works correctly.
We need to reproduce the issue. For this, we require a complete example that we can download and run on our side. We would appreciate it if you send us such an example.

Hi @miherlosev
I've been looking for an open proxy that would work with TestCafe, had no luck, but using version 1.14.0 and running
testcafe chrome test.js --proxy <IP_ADDRESS>:8139 would return Failed to connect to the proxy. error. When using 1.15.3 the test would just run, but ignore the proxy, the IP address does not change. Have attached an example that checks the IP to see if it's the same as the proxy. You'll need to run npm install, it will install 1.15.3. Hope this helps.

The attached example didn't help us reproduce the issue.
Our tests use the programmatic way to run TestCafe. Use the programmatic API to run your tests and let us know about your results.
const createTestCafe = require('testcafe');

const testCafe = await createTestCafe(options);
const runner   = testCafe.createRunner();

await runner
    .src('test.js')
    .browsers('chrome')
    .useProxy('<IP_ADDRESS>:8139')
    .run();

await testcafe.close();

Update the example to:
const createTestCafe = require('testcafe');

async function start () {

	const testCafe = await createTestCafe();
	const runner   = testCafe.createRunner();

	await runner
		.src('test.js')
		.browsers('chrome')
		.useProxy('<IP_ADDRESS>:8139')
		.run();

	await testcafe.close();
}

return start();

But get the same result, with or without .useProxy the IP address remains the same. The setting is ignored. Hope this helps.

Hi @cyanbutton
We can't run your example. Please try to create a new example with another page and without protection from CloudFlare.

Hi @Aleksey28
CloudFlare, odd didn't see that. How about https://ipinfo.io/ip is it blocked? This new example uses TestCafe 1.15.3 and a new open proxy, that so far has been up and works with TestCafe. It compares the result from https://ipinfo.io/ip to a hard coded value that is the proxy ip.
After npm install please run node  api.js
This example works for me using TestCafe 1.14.0 but not 1.15.3
Thanks!

TestCafe can use an external proxy only for pages served over HTTP. If I change https:// to http:// in your example, I can observe the same behavior with both TestCafe versions.
Could you please let me know if you can still reproduce the issue with HTTP pages on your side?
In the meantime, I filed an issue to update the documentation with a note that proxies only work for HTTP.

Hey @VasilyStrelyaev thanks for the follow up.
I can't find a site to show me my ip address that is http:// any suggestions?
How do I test https:// sites through a proxy like in version 1.14.0? Tried establishing an https connection with the TestCafe server from the example here, but my ip address does not change.

http://ipinfo.io/ip does open through HTTP, but Cloudflare wouldn't allow me to connect via the public proxies I managed to find. Can you please try to use HTTP and disable HTTP/2 in your project simultaneously? To disable HTTP/2, use the disableHttp2 configuration file property or pass the disableHttp2 option to the runner.run() method. I just want to check if the problem persists and we still need to find a way to reproduce it.
The limitation due to which TestCafe cannot access HTTPS websites via external proxies is intended and has been in effect since before 1.14.0. I cannot determine the cause of the behavior you see in 1.14.0 without additional investigation.
To sum up, you cannot use external proxies for HTTPS and HTTP/2 connections with the current TestCafe version.

I'm experiencing the same issue that @cyanbutton described with testcafe version 1.15.3. I use the CLI, not the testcafe runner. When downgrading to testcafe version 1.14.0, the issue does not exist.

Sadly http://ipinfo.io/ip converts to https:// before the page loads, and I can't find a site to show me my IP that uses http://.
Looks like we'll be staying with 1.14.0 until https://github.com/DevExpress/testcafe-hammerhead/issues/2668 is completed 😞
Thanks everyone.

Just found http://test-ipv4.com/ that works with http:// using this, TestCafe 1.15.3 and a proxy, shows the proxy address for me. So it looks like the proxy work correctly for http:// sites, just have to wait for https://github.com/DevExpress/testcafe-hammerhead/issues/2668 for the proxy to work with https:// sites.

This is interesting. Our testing server is https, and 1.14.0 works fine. Our proxy server only gets request to the test URL. However, any version above that, our proxy server register this in the logs:
TCP_DENIED/403 4464 GET http://<IP_ADDRESS>:1337/browser/connect/sYNp3vU - HIER_NONE/- text/html
where that IP is the internal IP of the docker container where the tests are running, which means is sending a request to the proxy with the IP address of the container; as it's a local network address, the proxy denies the request.

+1 same issue that @cyanbutton @mhanci92 are experiencing. After 1.14.0 I'm unable to connect to https sites via proxy.

@samlin86 , @mhanci92, @cyanbutton did you try to use disableHttp2:
{
"disableHttp2": true
}

Anyway, the fact that you need to enable this option to test the https page over the proxy looks like a bug. We will investigate it and update this thread once we have any results.

@aleks-pro Just tried "disableHttp2": true workaround and am able to connect to https sites via proxy using 1.16.0. 😮 🥳
Not sure how I missed this in @VasilyStrelyaev comment 😓
THANK YOU BOTH!

https://github.com/DevExpress/testcafe/issues/6363
Hi folks,
We automatically downgrade the protocol to HTTP 1 if proxy settings are enabled. So, using the disableHttp2 option is not necessary.
Try removing this option and run your tests with the latest testcafe version (1.17.2-rc.2) and let us know about the results.


[feature] Update references checks for BYOB

Update references checks to check for references to the delegator workflow.

pre-release/references.sh
pre-submit.actions/references.sh
RELEASE.md

I think this is already working properly. The scripts search under .github/workflows/ for the string slsa-framework/slsa-github-generator/.github/actions/..., so the delegator workflows will be taken into account.

Right now I think the scripts miss uses of delegator_generic_slsa3.yml.
This will be an issue for any workflows (like the nodejs one) that use BYOB in our repo.
https://github.com/slsa-framework/slsa-github-generator/blob/71cb86986c57cd8173e44c4746c09c3cce7c1c5f/.github/workflows/builder_nodejs_slsa3.yml#L78

Got it. I understand what you mean. Agreed.


how to manage the quality of the microsoftdivtools in vscode

Is your feature request related to a problem? Please describe.

Describe the solution you'd like:

Describe alternatives you've considered:

Additional context:

Closing as incomplete. Please feel free to add more information if you have any and we can re-open the issue.

To manage the quality of Microsoft DevTools in Visual Studio Code (VSCode), you can follow these steps:
Stay up to date with VSCode and DevTools versions – Make sure you are using the latest version of the VSCode extension and DevTools. Microsoft and the community continually release updates and improvements to address bugs and security vulnerabilities and improve features. Check for updates regularly and install them.
Report problems and provide feedback: If you encounter any issues or bugs using DevTools in VSCode, please report them to Microsoft via the VSCode GitHub repository or the Visual Studio Code feedback channels. Providing detailed information about the problem, steps to reproduce, and system configurations can help Microsoft identify and fix problems more effectively.
Get Involved in the Community: Join the VSCode community forums, discussion groups, and GitHub repositories to interact with other users, developers, and members of the Microsoft team. Participating in the community can help you stay informed about updates, known issues, workarounds, and best practices, as well as provide valuable feedback to improve the quality of DevTools.
Follow coding best practices – Follow coding best practices while using DevTools in VSCode. This includes following coding conventions, using appropriate coding patterns, writing clean and maintainable code, and thoroughly testing your code.
Customize settings – VSCode and DevTools offer a wide range of settings that you can customize to your needs. Review and configure settings related to DevTools to optimize your workflow and ensure that the tools work as expected.
Stay informed about documentation and tutorials: Stay up to date with the official documentation and tutorials provided by Microsoft for DevTools in VSCode. The documentation provides comprehensive information on the features, usage, and troubleshooting of the DevTools, which can help you use them effectively and avoid potential problems.
Use recommended extensions: Microsoft provides a list of recommended extensions for VSCode, including those that are specifically designed to enhance DevTools functionality. Installing and using these recommended extensions can help ensure that you are using high-quality and well-maintained tools.
By following these steps, you can effectively manage the quality of Microsoft DevTools in Visual Studio Code and optimize your coding workflow. Remember to stay up to date, report issues, participate in the community, follow coding best practices, customize settings, stay informed about documentation and tutorials, and use recommended extensions.


Improve pkg-config file generation

It would be good to improve the CMake generated .pc file for relocatability - namely, it should use ${prefix} etc. variables and relative paths whenever possible, but still support absolute paths when so required.
See e.g. libjxl and libtiff
Same goes for OpenEXR btw...

While I support the suggestion of using ${prefix} etc., I don't know of a case, where relative paths are used. From the almost 1200 pkg-config files on my machine, only a handful uses relative paths and all of them look like the generation of the files was buggy and the paths were not properly expanded during file generation. Also the pkg-config documentation you linked doesn't mention relative paths. It speeks of installation paths, which IMO should always be absolute paths.

I don't know of a case, where relative paths are used.

With the known exception of NixOS (there might be others though), CMAKE_INSTALL_LIBDIR etc. seem to be always relative.
Using exclusively absolute paths in the pkg-config file prevents the package from being relocatable.

From the almost 1200 pkg-config files on my machine, only a handful uses relative paths

From the more modest 249 on mine, only 23 use absolute paths.

With the known exception of NixOS (there might be others though), CMAKE_INSTALL_LIBDIR etc. seem to be always relative.

Yes it's usually relative. There's CMAKE_INSTALL_FULL_LIBDIR from the GNUInstallDirs which are guaranteed to be absolute paths. But if you prepend the {exec_,}prefix to it, it will always be an absolute path.
Imath uses the *_FULL_*DIR variables and so is IMO not affected by the issue from the NixOS discussion you linked, but can indeed lead to issues when relocating. That's why I said, I like the ${prefix} notation.

From the more modest 249 on mine, only 23 use absolute paths.

Do you have an example?

The generation has been changed in https://github.com/AcademySoftwareFoundation/Imath/commit/2496f3ea05e5b3a562b530a38b21c70b8536a215

Ok, if you want to be picky, relative to $prefix in terms of relocatability then. Of course $prefix has to be set to something initially, but then you have the pkg-config --define-variable=prefix=/foo mechanism to relocate it wherever.

Oh it's not about being picky. IMO it's more about people from different regions have a different interpretation of english, especially if it's not their native language and about trying to communicate as precise as possible in such circumstances.
And the 4th time, in the hope, you won't ignore it further:

The generation of the files is a different matter, and I say it again, I support the idea of using ${prefix} notation to make the files relocatible and improve the logic to support both absolute and relative paths in the CMAKE_INSTALL_* variables.

I was just extremely confused, what you're talking about relative path's in .pc files.

No probs, glad we converged.

With the known exception of NixOS (there might be others though), CMAKE_INSTALL_LIBDIR etc. seem to be always relative.

It purely depends on how you define -DCMAKE_INSTALL_LIBDIR at configure time. This is in contrast to e.g. Meson, where you can pass --prefix=/usr --libdir=/usr/lib and it will be consistently relativized for you. It's important for cases where these paths aren't necessarily a single constant location.
(But Meson doesn't have this problem anyway, because pkg-config file creation is a core feature of Meson and handles all the edge cases for you. It even supports prefix=${pcfiledir}/../../ without individual projects having to hardcode support for it -- all it took was a small patch to Meson itself, so that all projects benefited. It's a great shame that cmake doesn't care to provide support for pkg-config.)

It purely depends on how you define -DCMAKE_INSTALL_LIBDIR at configure time.

That's the thing, why would one have to define both CMAKE_INSTALL_{LIBDIR,INCLUDEDIR}? Defining -DCMAKE_INSTALL_PREFIX should suffice, and CMake figures out CMAKE_INSTALL_{LIBDIR,INCLUDEDIR} correctly as relative to that in most cases. The problem then is that on some platforms, like nixOS, those are not relative to the prefix, but absolute, so this needs to be managed like in the examples above. I don't see a need to burden the users of Imath with further configuration options. Besides, the current Imat pkg-config template doesn't even use CMAKE_INSTALL_{LIBDIR,INCLUDEDIR} variables, but CMAKE_FULL_INSTALL_{LIBDIR,INCLUDEDIR}, so one has to provide an absolute path there (you can't define it as something like "\${exec_prefix}/lib" as it might be used elsewhere in CMake scripts), which doesn't solve the relocation issue...

But Meson doesn't have this problem anyway, because pkg-config file creation is a core feature

Not discussing pkg-config file creation by Meson here, but by CMake. I used Meson just as an example on how one can consume a relocatable pkg-config file properly generated by whatever build system.

Just getting to this now. Take a look at #291, I think that's what you're suggesting, but I don't use pkg-config much, so please confirm this works as you'd expect. If so, I'll submit the similar fix for openexr. Thanks.


How to generate a modal popup link

I have a custom view with details_modal = True and the view action icon works fine but I would also like to link from one of my columns to popup the same modal view.  I have  column_formatters set to override the default column display behavior but I don't know how to generate a link for doing the popup.
    def _mycolumn_formatter(view, context, model, name):
        if model.mycolumn:
           markupstring = '{}'.format(HOW_DO_I_GENERATE_THIS, model.mycolumn)
           return Markup(markupstring)
        else:
           return ""

Any help or pointers would be greatly appreciated.

Not sure if this is the best way but I solved it by doing this....
markupstring = '{}...
'.format(url_for('MYDETAILESVIEW', id=model.id,
next=url_for('MYLISTVIEW)),  model. mycolumn[:26])


Behaviour when moving before the first item

downshift version: 3.1.5
node version: 8.9
npm (or yarn) version: 5.6.0 (1.3.2)

Relevant code or config
<form onSubmit={this.onSubmit}>
          <Downshift
              onChange={this.downshiftOnChange}
              itemToString={this.downshiftItemToString} >
            {({ selectedItem, getInputProps, getItemProps, highlightedIndex, isOpen, inputValue, getLabelProps }) => (

                  <input {...getInputProps({
                    placeholder: Search products,
                    onChange: this.inputOnChange
                  })} ref={this.input} />
{isOpen ? (

...
            )}
          </Downshift>
          <input type="submit" value="Submit" className="dropdown-button" />
        </form>

What you did:

I enter a term like "test", I see a list of suggested results
press the down cursor key, selects first item of results
press the up key, I'm on the last item of the results

Suggested solution:

I would like to return to the input text box

I would like to return to the input text box

You're actually always in the input box... At any point you can continue typing because the focus never leaves the input box.


Migrate to ESLint

TSLint is deprecated and is now in security fix only support, after this year, it will receive no updates at all.. https://github.com/palantir/tslint/issues/4534.

Done by dc965b9be0bf17bbfe1a581b0e88eafd16ebd919


New workflow to apply the pr approved label

Github already has review:approved search filter, so this seems kinda redundant.

Github already has review:approved search filter, so this seems kinda redundant.

The use case is for skimming the pr list and quickly differentiating between whats approved and whats  not, not for searching approved prs

The use case is for skimming the pr list and quickly differentiating between whats approved and whats not, not for searching approved prs

The pr list already shows review status like "approved" or "changes requested."

This workflow also doesn't seem to remove the label if someone requests changes.

The pr list already shows review status like "approved" or "changes requested."

Mm, I don't think it does for "approved"

The use case is for skimming the pr list and quickly differentiating between whats approved and whats not, not for searching approved prs

The pr list already shows review status like "approved" or "changes requested."

Nah, it only does for requesting changes (i approved this one for example)

The pr list already shows review status like "approved" or "changes requested."

Mm, I don't think it does for "approved"

Somehow this repo seems to have that disabled for the master branch. It shows for PRs targeting different branches like the april fools branch.

This workflow also doesn't seem to remove the label if someone requests changes.

This is a good point though.

This workflow also doesn't seem to remove the label if someone requests changes.

i mean you have to apply the awaiting changes labels yourself anyways

The pr list already shows review status like "approved" or "changes requested."

Mm, I don't think it does for "approved"

Somehow this repo seems to have that disabled for the master branch. It shows for PRs targeting different branches like the april fools branch.

ah thats cool, gonna ask if there is a way to enable this
For the other thing, we already have to manually remove "Awaiting changes" so you can remove the label when adding that one

failing

failing

AFAIK its failing cuz the action in this pr doesnt have the perms to apply the label in the main repo.

Can we get this workflow merged? I think it would be useful with the new maintainer policy since we now need a second maintainer to merge after approval. The label makes it easy to find PRs which are waiting for that.

Although I would rather we figure out why the review:approved tag does not work

Also for future GitHub actions PRS, please prove your pr works by making a new fork of the repo (probably will need you making a new org) and running your action in there.


Robot issues app

What's new

Adds a micro app for displaying reported robot issues.

A quick and dirty way to test it would be replacing https://github.com/open-rmf/rmf_ros2/blob/main/rmf_fleet_adapter/src/rmf_fleet_adapter/agv/FleetUpdateHandle.cpp#L882-L888, with some fake issues
      // object issue
      nlohmann::json object_issue_msg;
      object_issue_msg["category"] = name + "object_category";
      nlohmann::json object;
      object["first_field"] = "first_value";
      object["second_field"] = "second_value";
      object_issue_msg["detail"] = std::move(object);
      issues_msg.push_back(std::move(object_issue_msg));
      // array issue
      nlohmann::json array_issue_msg;
      array_issue_msg["category"] = name + "string_category";
      array_issue_msg["detail"] = {"first_value", "second_value"};
      issues_msg.push_back(std::move(array_issue_msg));
      // string issue
      nlohmann::json string_issue_msg;
      string_issue_msg["category"] = name + "string_category";
      string_issue_msg["detail"] = "string_value";
      issues_msg.push_back(std::move(string_issue_msg));

Self-checks

[ ] I have prototyped this new feature (if necessary) on Figma
[ ] I'm familiar with and follow this Typescript guideline
[ ] I added unit-tests for new components
[ ] I tried testing edge cases
[ ] I tested the behavior of the components that interact with the backend, with an e2e test

Discussion

I have not been able to implement resetting all the open accordions when a new robot is selected. Any ideas?

I think this could be part of robot info, what do you think?

I was playing around with that idea too. The next step is actually to include robot logs too, and I was hoping to avoid panels/spaces that will most of the time remain empty.
What do you adding it as a clickable icon at the end of the robot table row, that opens up an overlay?

I don't see any advantage of that over just having it on the robot info. If there is no issues, it would actually be important to indicate that. There should be an indicator at the robot table to quickly find robots with issues, but I don't think it needs any special click handler, it can just open the robot info as normal.


All examples are not working in CodeSandBox

All examples are not working in CodeSandBox
Property 'children' is missing in type '{}' but required in type 'Props'.ts(2741) demo.tsx(20, 3): 'children' is declared here.
Issue located at: https://codesandbox.io/s/c503m?file=/demo.tsx
from: https://material-ui.com/components/app-bar/

[X] The issue is present in the latest release.

@vince7488 The linked codesansbox seems to work as expected. I'm going to assume it's a support request.


Homework21: Ekaterina Tsiunel

pytest

this hw is in branch homework_21 which is made from branch homework_20 (just for info)

Ready for review

all comments fixed

@Stml89 Could you please see one more time!
I've added conftest.py file with setting for correct logs level tracking in html-reports


HAWQ-338. refer build instruction to wiki page

So we can only keep one copy, and the latest copy.

+1

The fix looks good. +1

Open for 29 days, +2 on votes, can we get this merged?


compare

Any thoughts on a compare function?
compare :: (a -> Number) -> a -> a -> Number

var compare = R.curry(function(f, x, y) {
  return f(x) - f(y);
});

Basically, shorthand for converting (a -> Number) functions into comparators. I've found it helpful for things like this:
var compareLength = compare(R.length);

R.sort(compareLength, ['hey', 'hi', 'hello', 'cya']);
// => ["hi", "hey", "cya", "hello"]

It could also be accompanied by a sortByComparing function.
var sortByComparing = R.curry(function(f, xs) {
  return R.sort(compare(f), xs);
});

R.sortByComparing(R.length, ['hey', 'hi', 'hello', 'cya']);
// => ["hi", "hey", "cya", "hello"]

R.sortBy does this in a more generic fashion:
R.sortBy(R.length, ['hey', 'hi', 'hello', 'cya']);
// => ["hi", "hey", "cya", "hello"]

The function passed to it could generate String or numeric keys; either would work fine, as would Dates.  Basically, anything that you could compare with a < b would work.

:+1:
Awesome, I guess I would confused by the (a -> String) part of the type signature in sortBy - should have given it a poke first though. Thanks for the reply.

Most of our type signatures were created in a heroic effort by @buzzdecafe.  He did this over the course of only a day or two.  He got a surprisingly high percentage of them right, but we really need to look through them more carefully and decide where some polishing is due.
This one is slightly more odd.  I'm pretty sure that function was mine (else it's very similar to one I'd written earlier.)  And I honestly expected it to be used with Strings.  I never really thought about Numbers (or Dates) until this issue was raised.  So it was documented for how we expected the function to be used.  I think this one should be redocumented, because the implementation is clearly right: as long as the keys your function generates are sortable by <, it should just work.  Often things like this that fall out of the implementation are intentionally not documented, since we want to feel free to change the implementation, but this feels more like a case of learning from the implementation.


docs: create wonderful readme

A readme should be prepared explaining the purpose of the project, its setup and how it works.

fixed at #27


[Bug] Duplicate issues are generated for a binary application

Affected Version: 0.5.0-beta.1
Binary used: https://github.com/windup/windup-sample-apps/blob/master/sample-binaries/jee-example-app-1.0.0.ear
Run analysis with Source + Dependencies mode, Application and Internal Deps scope with targets EAP and Containerization. A rule is matched twice:
log4j-removed-00001

Closing, these are different rules.


Vim yank to system clipboard not working

Hello,
System details:
Mac Sierra 10.12.5
Vim --version
`

vim --version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jun 24 2017 12:45:56)
MacOS X (unix) version
Included patches: 1-666
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl             +file_in_path    +mouse_sgr       +tag_old_static
+arabic          +find_in_path    -mouse_sysmouse  -tag_any_white
+autocmd         +float           +mouse_urxvt     -tcl
-balloon_eval    +folding         +mouse_xterm     +termguicolors
-browse          -footer          +multi_byte      +terminfo
++builtin_terms  +fork()          +multi_lang      +termresponse
+byte_offset     -gettext         -mzscheme        +textobjects
+channel         -hangul_input    +netbeans_intg   +timers
+cindent         +iconv           +num64           +title
-clientserver    +insert_expand   +packages        -toolbar
+clipboard       +job             +path_extra      +user_commands
+cmdline_compl   +jumplist        +perl            +vertsplit
+cmdline_hist    +keymap          +persistent_undo +virtualedit
+cmdline_info    +lambda          +postscript      +visual
+comments        +langmap         +printer         +visualextra
+conceal         +libcall         +profile         +viminfo
+cryptv          +linebreak       +python          +vreplace
+cscope          +lispindent      -python3         +wildignore
+cursorbind      +listcmds        +quickfix        +wildmenu
+cursorshape     +localmap        +reltime         +windows
+dialog_con      -lua             +rightleft       +writebackup
+diff            +menu            +ruby            -X11
+digraphs        +mksession       +scrollbind      -xfontset
-dnd             +modify_fname    +signs           -xim
-ebcdic          +mouse           +smartindent     -xpm
+emacs_tags      -mouseshape      +startuptime     -xsmp
+eval            +mouse_dec       +statusline      -xterm_clipboard
+ex_extra        -mouse_gpm       -sun_workshop    -xterm_save
+extra_search    -mouse_jsbterm   +syntax
+farsi           +mouse_netterm   +tag_binary
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/local/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang   -L. -fstack-protector -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib  -L/usr/local/lib -o vim        -lncurses -liconv -framework Cocoa   -mmacosx-version-min=10.1
2 -fstack-protector-strong -L/usr/local/lib  -L/usr/local/Cellar/perl/5.26.0/lib/perl5/5.26.0/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc -F/usr/local/opt/python/Frameworks -framework Python   -lruby.2.4.1 -lobjc`

Seeing an issue where the command "*Y / "*y is no longer copying to the system clipboard. I was using this option before I upgraded my operating system from OSX 10.10, but it stopped working after the upgrade.
Through some searching online, I tried adding the line set clipboard=unnamed to my .vimrc, but that didn't fix the issue either.
I am happy to provide more details! Thanks for all your hard work.

Does "+y work?

No luck!

@cjappl
I've just done a clean installation of macOS 10.12.5 on my Mac, and then built and tested Vim 8.0.0684 as follows:
$ git clone https://github.com/vim/vim.git
$ cd vim/src
$ ./configure && make test

The build was done successfully, and the tests including testdir/test_quotestar.vim were all passed.
After that, I did $ VIMRUNTIME=../runtime ./vim on Terminal.app and tried yanking and pasting to and fro between that vim instance and another Terminal.app instance, and found no issue with that.  Just to make sure, I also examined the content of the system clipboard with pbcopy and pbpaste and confirmed that data transfer between Vim and the system clipboard had no issue.
So, @cjappl , would you tell us more specifically how you were convinced that "Vim yank to system clipboard not working"?  Since the investigation here was done with the factory default Vim, this could be helpful for you to find out the cause of the yank failure by comparing the build configuration and the runtime settings here with yours.

@nuko8
Interesting, I am following the same steps and getting the following report. Seems to point exactly to the problem!
From test_quotestar.vim:
Found errors in Test_quotestar():
First run:
function RunTheTest[24]..Test_quotestar[6]..Do_test_quotestar_for_macunix line 12: Expected 'text from pasteboard to vim via quotestar' but got ''
function RunTheTest[24]..Test_quotestar[6]..Do_test_quotestar_for_macunix line 19: Expected 'text from vim to pasteboard via quotestar' but got ''
Second run:
function RunTheTest[24]..Test_quotestar[6]..Do_test_quotestar_for_macunix line 12: Expected 'text from pasteboard to vim via quotestar' but got ''
function RunTheTest[24]..Test_quotestar[6]..Do_test_quotestar_for_macunix line 19: Expected 'text from vim to pasteboard via quotestar' but got ''

Test results:
test_eval FAILED

From test_quotestar.vim:
Found errors in Test_quotestar():
First run:
function RunTheTest[24]..Test_quotestar[6]..Do_test_quotestar_for_macunix line 12: Expected 'text from pasteboard to vim via quotestar' but got ''
function RunTheTest[24]..Test_quotestar[6]..Do_test_quotestar_for_macunix line 19: Expected 'text from vim to pasteboard via quotestar' but got ''
Second run:
function RunTheTest[24]..Test_quotestar[6]..Do_test_quotestar_for_macunix line 12: Expected 'text from pasteboard to vim via quotestar' but got ''
function RunTheTest[24]..Test_quotestar[6]..Do_test_quotestar_for_macunix line 19: Expected 'text from vim to pasteboard via quotestar' but got ''
TEST FAILURE
make[1]: *** [report] Error 1
make: *** [scripttests] Error 2

Does this mean there is a problem in my vimrc potentially? What can I do to further debug this issue.

As a secondary step, I tried:
mv ~/.vimrc ~/vimrc
To "hide" my vimrc, same error occured.

Does this mean there is a problem in my vimrc potentially?

It rather looks like the problem exists on the system side, too...  On a terminal, what do you have when you run the following sequence of commands?
$ echo 'test' | pbcopy && pbpaste

Also, I've been a bit concerned about this statement in your first post:

Seeing an issue where the command "*Y / "*y is no longer copying to the system clipboard. I was using this option before I upgraded my operating system from OSX 10.10, but it stopped working after the upgrade.

Since I've never heard of such an issue, I can't make out exactly what you were talking about and hence don't understand what option you were referring to.  After all, were you able to use "*Y/"*y on 10.10 using "this option"? What was that "this option"?  How did you yank with that?  Anyway, that statement sounds to me that the *-register has already failed to work on your Mac since 10.10, which probably matters much more than "this option"'s stopping working this time.
In conjunction with that, will you try this?: Open Vim and type :reg * and press return.  Then what does Vim say?

As a secondary step, I tried:
mv ~/.vimrc ~/vimrc
To "hide" my vimrc, same error occured.

Since the test suite is written not to depend on user settings, the result is anticipated...

Ah, interesting! This seems to be an issue with TMUX. Thanks for helping me discover the problem.
So to answer your question, the echo test wasn't working, which means it was on pbcopy's side of things.
It turns out there is an issue introduced in sierra:
https://github.com/tmux/tmux/issues/543
The solution was to follow the steps in joshuamcginnis's answer. Now it's working perfectly.
Closing, thanks again for the help

Oh, that's it!  Thank you for the nice follow-up.  I should have thought of tmux first but somehow I had been missing it.  Hopefully, this thread could be helpful for those who face the same trouble.

Yep, that was an important piece of the puzzle I didn't even realize!

On MacOS 12.2 I suddenly cannot yank a line with the Y command or the yy command. I copy and past lines constantly and this is a real pain.
It's been a long time since the above conversation.  Do people think I have to compile vim myself?  It's been a long time since I've done that sort of thing (I'm 79).

Missing a lot of details. It might be better to ask on the vim-use mailinglist or use vi.stackexchange.com for help on how to setup vim correctly. You need to provide at least the output of :version including all compile options (check for +clipboard) and say what exactly does not work. Certainly yanking should work by default. You can check using the :reg command, whether it worked. If you are talking about the system clipboard and you do have +clipboard it may depend on your system and I don't know for MacOS. Also try without any additional complexities like terminal multiplexer (tmux, screen) or ssh sessions first and start with a pristine configuration like using vim --clean.


Plugin is abandoned.

?

?

My life has become far crazier than I expected, and now I simply don't have the time to maintain this plugin. If I do ever get the time, I might come back and work on this again. But I've not only lost most of my free time, I've also lost my passion for Bukkit. Development in Bukkit is painful, and I honestly aught to just rewrite most of DecoHeads to be a little more flexible for future features. But rewriting an entire plugin is a long and difficult process, and I'm not sure if/when I will have the time to do that.

Okay I understand. Could you just update the plugin when is a new version ? For example when there is 1.13, will you be able to update it please ?

The plugin should hopefully still work just fine when 1.13 comes out.


Add ability to pass to QueryFactory and DatabaseFactory in AsyncQueryEva...

...luator apply()

Not liking the inversion that this config style causes, but in the interest of progress: #shipit


Tag version 0.2.1 ?

Reviewing the work of @lboynton and the few other commits I see that we keep BC. We should update our patch version (since this is <1.0.0).

What keeps us from releasing a stable version?

php-http/discovery
Just like guzzle5

Can we tag a stable then? After #8

Lets wait for a while. The life of this adapter has been very short. Lets tag 0.3.0 after #8 and hope that 1.0 = 0.3 after a couple of months.


Add libloader plugin to CMake build

This builds the libloader plugin with CMake, and fixes a typo in a comment in healthchecks/CMakeLists.txt which I copied part of for these changes.

[ci approve autest]

[approve ci autest]


Remove Automate Worker

Since the Automate Worker wasn't being used, temporarily removed.
The revert of the commit didn't work since that was done before the application root directory was changed.

@gmcculloug @Fryguy @jrafanie @chessbyte
Please review

:+1:

@mkanoor @Fryguy @chessbyte this patch causes miq to fail to start because miq_workers table still have records for workers of the delete type.
"ActiveRecord::SubclassNotFound: The single-table inheritance mechanism failed to locate the subclass: 'MiqAutomateWorker'"
db:reset solves it, but it would be better to have this cleanup handle it instead of the need to delete the data in the db.

@mkanoor : can you add a migration to address what @abonas reported?

@abonas why, as a developer, are you even running rake evm:start?

as on every evm:start they are re-added (not sure from where)

This should not be happening... @gmcculloug ?

@abonas why, as a developer, are you even running rake evm:start?

because it starts the miq server :smile:
on a more serious note, evm:start documented in the old developer setup page
http://manageiq.org/community/install-from-source/
as well as the new developer setup page
http://manageiq.org/documentation/development/developer_setup/
so, developers can't know they should not use it (btw, why not?)
(and iirc, for a long time, rails server didn't properly work because of the file structure in miq repo)

Most developers on the project run bundle exec rails server and bundle exec rails console to do the "worker" things manually. There is also MIQ_SPARTAN mode that developers run when they do need a handful of workers running.

@gmcculloug @Fryguy
The sequence of events is
(1) You have a server running
(2) You update the source code
(3) You run evm:kill with the new code,the kill fails leaves the workers table intact.
The next start of the server fails.

Why would someone update the source code while the code is running?

http://talk.manageiq.org/t/source-code-updated-while-server-is-running/985

@gmcculloug @Fryguy
The sequence of events is
(1) You have a server running
(2) You update the source code
(3) You run evm:kill with the new code,the kill fails leaves the workers table intact.
The next start of the server fails.

I didn't experience this, and I didn't have a server running when deleting workers.

@abonas
Can you check the evm.log to see if the evm:kill that you performed was successful. If all the workers have been terminated cleanly the mi_worker table would be empty? If for some reason evm:kill fails then its going to leave debris behind.


Include checksums and additional tags to S3 artefact uploads

What this PR does / why we need it:
During the upload to S3 job of the nightly Action:

md5sums and sha256sums will be calculated for every artefact
both values will be supplied to S3 to verify proper upload (ref)
md5sum and sha256sum will be added to the release manifest
md5sum and sha256sum will be added as tags to every uploaded artefact (along with Garden Linux version, platform, architecture and comittish)

All this to have the possibility to track and check integrity of image artefact from the moment on they come out of the build pipeline.
Special notes for your reviewer:
Tested in https://github.com/gardenlinux/gardenlinux/actions/runs/9465059139
Do not cherry-pick to rel-* branches as this will require changes to glci as well.
Release note:

Checksums (md5 and sha256) are now calculated for and added to each release artefact.

@fwilhe: You are right, comments always help. 😉
Added with  https://github.com/gardenlinux/gardenlinux/pull/2139/commits/496a30557a011a9abedb70428d9ac43c114b3ada

comments always help. 😉

🫠


npm run prod failing for classes used only in javascript

Laravel Mix Version: 6.0.27 (npm list --depth=0)
Node Version (node -v): v16.3.0
NPM Version (npm -v): 7.15.1
OS: Windows 10

Description:
Running the npm run prod command fails to identify the classes used only inside js. I am using tailwind css.
Steps To Reproduce:

Create a new laravel project
Install tailwind.
in app.js create an object to append to the DOM ex:

elem.innerHTML += '<img src="' +
                GLOBAL.recipesUrl +
                '/' +
                element +
                '" class="max-h-v-70 max-w-v-60" />';

I created max-h-v-70 max-w-v-60 in my tailwind.config.js. They work 100%. Tested with npm run watch.
(The code may not be correctly defined but you get the idea)
4. Never use max-h-v-70 or max-w-v-60 inside a .blade.php file.
5. Run npm run prod
6. They are not present inside public/css/app.css
Expected Result
Both classes presented inside public/css/app.css

You need to configure your purge array in tailwind for it to work correctly.


add option for number of n_gsps dynamic

Pull Request
Description
make number of gsps in manager live an optional input
Fixes #
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.
Please also list any relevant details for your test configuration

[ ] Yes

If your changes affect data processing, have you plotted any changes? i.e. have you done a quick sanity check?

[ ] Yes

Checklist:

[ ] My code follows OCF's coding style guidelines
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked my code and corrected any misspellings

Codecov Report

Merging #656 (2913214) into main (d0f70fd) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #656   +/-   ##
=======================================
  Coverage   93.26%   93.26%
=======================================
  Files          47       47
  Lines        3179     3179
=======================================
  Hits         2965     2965
  Misses        214      214

Impacted Files
Coverage Δ

nowcasting_dataset/manager/manager_live.py
93.93% <100.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Kanban Board Issue

Hi,
Here is the link to the Projects containing all tasks that have been allocated between myself and my partner.
We are a team of two so we removed all tasks with dragon in them.

Hi @DammyShittu  🙋♀,
STATUS APPROVED ✔
Your project is complete!  There is nothing else to say other than... it's time to merge it 🔗 🚢
Congratulations! 🎉
Cheers 🥂  and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Thank you @AshakaE 👍


Main thread is blocked by editor tree population

When the multithreaded generation process completes, QodotMap recursively traverses its children and sets their owned to the active editor tree to make them appear in the scene tree.
This process is expensive and causes the editor to hang momentarily. Much like .map file parsing, it's fine for smaller maps but becomes noticeable for more complex ones like ad_chapters.
If possible this should be done in a threaded manner, and failing that it should be timesliced.

This appears to be unintentionally improved in the qodot-map-refactor branch, the editor no longer fills the console with errors upon adding objects to the editor tree.

Turns out that the aforementioned fix was thread-unsafe.
I put some work into this during the recent QodotMap threading refactor, but it doesn't look like something that can be avoided without reducing population speed to a crawl.
One possible avenue of research is talking directly to VisualServer and PhysicsServer since their APIs are thread-safe, but I don't think you can actually modify the tree with them. That would end up being a much larger task aimed at optimizing the whole plugin to the metal, so for now I'm going to close this and let it be.


Initial concentrations

This PR changes how initial_condition_dict work.

CRNs now have an initial_condition_dict (property). This can be set via the constructor, at compilation time via Mixture.Compile_CRN, or via the method CRN.update_initial_condition().
Mixtures and Components now store initial conditions as parameters using the mechanism name "initial concentration", part_id = mixture.name, and parameter name = str(species) (or if a species comes from a component.get_species(), component.name).
Components still have an initial concentration property, however this just adds a parameter to their parameter_database [kept for backward compatability]

Implementing these changes has resulted in many tests cases being altered, new tests cases (in particular the test_initial_condition file) as well as minor to underlying code regarding parameter searching and sbml writing, and changes to some example notebooks.

Two comments:

There's an unused initial_condition_vector() function in chemical_reaction_network.py line 191. Please remove it. (There's also an associate test: test_initial_condition_vector() in test_chemical_reaction_network.py)
Could you please rename initial_condition_dict in simulate_with_roadrunner()? Thanks! I wrote the function before the remaining PR, hence the old naming convention.

Just an idea: maybe we could call the initial concentration variable simply initial_concentration without the dict. Probably, we don't need to encode the data structure in the variable name. What do you think? (we gain 5 characters! :))


VS2022 / c++20 boost::signals2::disconnect compilation error

Hello,
We're upgrading our c++ projects to Visual studio 2022 / c++20 and we have an compiler error with boost::signals2::signal::disconnect + boost::bind.
...\include\boost\signals2\detail\signal_template.hpp(530,46): error C2088: '==': illegal for class
Here is an example:
class CTest
{
public:
       boost::signals2::signal<void()> mySignal;
	CTest()
	{
		mySignal.connect(boost::bind(&CTest::Method, this));
		mySignal.disconnect(boost::bind(&CTest::Method, this)); //=> generates error with VS 2022 c++20, not with c++17
	}

	void Method()
	{}
};

Is there a workaround for this ?
Thanks
Regards,
Laurent

Sorry, duplicate.
I didn't see my previous message was transfered.


Automatic view tracking

Problem
At the moment all events are being tracked manually. Tracking across different Android activities or iOS view controllers requires manual work.
Solution
Integrate Android and iOS tracking without requiring the user to implement everything them self.
A mapping should be created between Android and iOS.

To formalise the view tracking conventions, I suggest naming the events: viewStart and viewStop.
On Android view tracking events are gathered using it's Application.ActivityLifecycleCallbacks. iOS events are gathered using the UIViewController.
A mapping overview is shown below.

Platform
tracked event
native event

Android
viewStart
onActivityStarted

Android
viewStop
onActivityStopped

iOS
viewStart
viewDidAppear

iOS
viewStop
viewWillDisappear


搜图功能失效了吗

复现步骤 / Step to reproduce
搜索界面，点击别针图标，选择本地相册，选择一张从其他途径获得的图片或从本应用下载保存的作品图片
预期行为 / Expected behaviour
e站有的一般都会搜到，没有的会显示无查询数据
实际行为 / Actual Behaviour
无论有没有都显示无查询数据，包括刚下载的作品图片，翻墙也不行，以前可以搜到
应用日志 / App logs
init LogUtil success
init UserSetting success
init TabBarSetting success: default
init SiteSetting success
init FavoriteSetting success
init MyTagsSetting success: default
init EHSetting success, site: EX
init DownloadSetting success: default
init EHRequest success
init PreferenceSetting success
Refresh tag translation data
init TagTranslationService success
init TagSearchOrderOptimizationService success
init MouseSetting success: default
init QuickSearchService success
init HistoryService success
init PerformanceSetting success: default
init SuperResolutionSetting success: default
init SuperResolutionService success
init ReadSetting success
init Gallery groups: []
init Archive groups: []
init ArchiveDownloadService success. Tasks count: 0
init DownloadService success, download task count: 0
start download executor
init SearchHistoryService success
SimpleDashboardPageLogic get data, prevGid:null, nextGid:null
refresh FavoriteSetting
refresh SiteSetting
refresh EHSetting
refresh MyTagsSetting
init VolumeService success
Refresh local gallerys, preCount:0, newCount: 0, timeCost: 306ms
Tag translation data downloaded
Tag translation data is up to date, timestamp: 2024-04-29T16:40:33.000Z
refresh SiteSetting success
refresh default tag set success, length: 0
refresh EHSetting success
refresh FavoriteSetting success
Latest version:[v7.5.3], current version: [v7.5.3]
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.paused
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.resumed
File search
Get redirect url success:https://exhentai.org/?f_shash=99cbb419b4433d871fcf2317c7803f3ce7d808b1&fs_from=JPEG_20240430_175144_5018782701037874117.jpg&fs_similar=on
Get gallerys data with file search, prevGid:null, nextGid:null
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.resumed
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.paused
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.inactive
?? App state change: -> AppLifecycleState.resumed
File search
Get redirect url success:https://exhentai.org/?f_shash=ae89eb17693db2067a88c08a66d40e37359ab8c2&fs_from=JPEG_20240430_175307_5057702606666187227.jpg&fs_similar=on
Get gallerys data with file search, prevGid:null, nextGid:null
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.paused
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.resumed
File search
Get redirect url success:https://exhentai.org/?f_shash=44119d9223d86ae818a0a5bddffd21ecb8d5a366&fs_from=JPEG_20240430_175338_9048899316160423703.jpg&fs_similar=on
Get gallerys data with file search, prevGid:null, nextGid:null
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.paused
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.resumed
File search
Get redirect url success:https://exhentai.org/?f_shash=c9904aa84963a16c454f3d1b5dab939d84ec8654&fs_from=JPEG_20240430_175420_2317051503655628896.jpg&fs_similar=on
Get gallerys data with file search, prevGid:null, nextGid:null
App state change: -> AppLifecycleState.inactive
?? App state change: -> AppLifecycleState.resumed
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.paused
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.resumed
File search
Get redirect url success:https://exhentai.org/?f_shash=48f4ca9ccdb6d6a680632b8ea778cf10d3d960cc&fs_from=JPEG_20240430_180356_3592955211936865691.jpg&fs_similar=on
Get gallerys data with file search, prevGid:null, nextGid:null
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.paused
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.resumed
FavoritePageLogic get data, prevGid:null, nextGid:null
Get history by page index 0
Get gallery details:https://e-hentai.org/g/2638969/2390b4fcf5/
Try to find gallery via firstLink: GalleryUrl{isEH: true, gid: 2638969, token: 2390b4fcf5}
Record history: 2638969
Begin to load Thumbnail 0 with page size: 40
cache hit: https://<IP_ADDRESS>/g/2638969/2390b4fcf5/?p=0&hc=1
Begin to load Thumbnail 6 with page size: 20
cache hit: https://<IP_ADDRESS>/g/2638969/2390b4fcf5/?p=0&hc=1
Begin to load Thumbnail 2 with page size: 20
cache hit: https://<IP_ADDRESS>/g/2638969/2390b4fcf5/?p=0&hc=1
Begin to load Thumbnail 3 with page size: 20
cache hit: https://<IP_ADDRESS>/g/2638969/2390b4fcf5/?p=0&hc=1
Begin to load Thumbnail 4 with page size: 20
cache hit: https://<IP_ADDRESS>/g/2638969/2390b4fcf5/?p=0&hc=1
Begin to load Thumbnail 5 with page size: 20
cache hit: https://<IP_ADDRESS>/g/2638969/2390b4fcf5/?p=0&hc=1
Begin to load Thumbnail 1 with page size: 20
cache hit: https://<IP_ADDRESS>/g/2638969/2390b4fcf5/?p=0&hc=1
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.paused
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.resumed
File search
Get redirect url success:https://exhentai.org/?f_shash=7fb68ac653fc76d369b2121a2eb140b4e82f2dd3&fs_from=JPEG_20240430_180751_9090277669700106601.jpg&fs_similar=on
Get gallerys data with file search, prevGid:null, nextGid:null
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.paused
App state change: -> AppLifecycleState.hidden
App state change: -> AppLifecycleState.inactive
App state change: -> AppLifecycleState.resumed
应用设置 / App Settings
No response
备注 / Addition details
搜图功能对我很重要，不知是否是新版的问题
JHenTai 版本号 / JHenTai version
7.5.3+2207
操作系统版本 / operating system version
Android
设备型号 / Device model
三星note8
自查步骤 / Verify steps

[X] 您已仔细查看并知情 常见问题 中的内容 / You have checked Q&A carefully
[X] 您已搜索过 历史Issue，没有找到类似内容 / I have searched on History Issues, No duplicate or related open issue has been found
[X] 您确保这个 Issue 只提及一个问题。如果您有多个问题报告，烦请发起多个 Issue / Ensure there is only one bug report in this issue. Please make mutiply issue for mutiply bugs
[X] 您确保已使用最新版本测试，并且该问题在最新版本中并未解决 / This bug have not solved in latest version

给出搜索时使用的图片，以及网页上能搜到而app里搜不到的截图。
从日志中的链接看，本来这个图片E站上就搜不到结果。


.write, .write_utf8, etc fail

Writing to the terminal using .write, .write_utf8, etc fail:
Uncaught (in promise) LinkError: import object field '__wbg_write_b033ab804b165ec5' is not a Function

However, using .writeln works fine.
Severity: This is currently breaking development of my projects. Being able to write to the terminal without appending a newline is somewhat vital functionality.
xterm-js-rs: 0.1.2, with feature xterm-addon-fit
browser: Firefox 120.0.1
wasm-bindgen: 0.2.89
packing command: wasm-pack build --target web
Cc: @segeljakt

I'm going to try my best to build a patch for this

write_callback and associated also don't work...

nevermind, found the issue. it was with my build system. no bug here, thank you for your amazing work :)


[WIP] React 18

...

Security Insights

(3) Vulnerable direct dependencies were detected
1 vulns in ansi-regex < 4.1.1 via yarn.lock
1 vulns in glob-parent < 5.1.2 via yarn.lock
1 vulns in minimist < 1.2.6 via yarn.lock

Action Items

Review dependencies for available updates
See this Splunk dashboard for more CVE details
Review PR for security impact; comment "security review required" if needed or unsure
Verify aviary.yaml coverage of security relevant code

Questions or Comments? Reach out on Slack: #support-infosec.


Add support for Enumerator interface

/**

Allows enumerating over a COM collection, which may not have indexed item access.
/
interface Enumerator {
/*

Returns true if the current item is the last one in the collection, or the collection is empty,
or the current item is undefined.
*/
atEnd(): boolean;

/**

Returns the current item in the collection
*/
item(): T;

/**

Resets the current item in the collection to the first item. If there are no items in the collection,
the current item is set to undefined.
*/
moveFirst(): void;

/**

Moves the current item to the next item in the collection. If the enumerator is at the end of
the collection or the collection is empty, the current item is set to undefined.
*/
moveNext(): void;
}

This interface has been deprecated in ES2015


make tracer.randomID recursive to ensure non-zero

The way it is written, two 0 results in a row would cause problems.
Signed-off-by: Derek Perkins<EMAIL_ADDRESS>

two 0 results in a row would cause problems.

what problems? The loop loops until the value is not zero.

My bad, I read if instead of for. I blame @jnewmano.


Unable to join some servers

Some servers give this message
`ParseGamestate: bad command byte
at JKClient.JKClient.ParseGamestate (JKClient.Message msg) <0x1029ab6e0 + 0x00538> in <562819ea416f4ec7b28904a828b8da40#292ada85d3b0bbfd350a324c511caba2>:0
at JKClient.JKClient.ParseServerMessage (JKClient.Message msg) <0x1029ab4d0 + 0x0017f> in <562819ea416f4ec7b28904a828b8da40#292ada85d3b0bbfd350a324c511caba2>:0
at JKClient.JKClient.PacketEvent (JKClient.NetAddress address, JKClient.Message msg) <0x1029a7600 + 0x00133> in <562819ea416f4ec7b28904a828b8da40#292ada85d3b0bbfd350a324c511caba2>:0
at JKClient.NetClient.GetPacket () <0x1029bbcd0 + 0x000bf> in <562819ea416f4ec7b28904a828b8da40#292ada85d3b0bbfd350a324c511caba2>:0
at JKClient.JKClient.Run () <0x1029ad050 + 0x00193> in <562819ea416f4ec7b28904a828b8da40#292ada85d3b0bbfd350a324c511caba2>:0  `
tried both on iOS and Android both the same error

Hi.
What exact servers did you try to connect to?
List them or just show a screenshot, please.

half of the mb2 servers

Yeah, I know about that issue.
The problem is in encoding game entities. And it's different in MBII.
Fixing it is very simple but some of MBII devs asked me to not add that because:

they think it's illegal (which is wrong since encoding data is publicly available);
they fear people will exploit the app to fill servers with bots or do some other bad things.

I respect their request so I did not add that special encoding, but maybe I will add the feature eventually in the future. That is a dilemma for me now.
Sorry for having the negative experience.
Though if you are a programmer I can tell you what you should do to fix it so you could build an app for yourself.

Oooh i see now, It's not a problem but why does some of the MB2 work though, for example AOD Honor Duels? is it because its not loading Open mode assets?
I haven't developed in long time for mobile but would like to have a look at it

You are close. That depends on maps and maps configuration.
In the very beginning some special entities are parsed out anyways if they are presented in the map data. That's where it fails.
If the map doesn't have those special entities then initial parsing (GameState) passes and everything works.

Actually I could try to make some changes yet to please the MBII devs' request. I will try that on this weekend, so don't bother fixing it yourself for now.

Ok not a problem let me know how it goes, my plan for this was just to create an app for inner clan members and who ever has admin role on the server they can just go into the app and deal with any problems there, but normal normal members won't have access. as you can perform smod commands in the chat.

Unfortunately there is no way to make it work without adding support for MBII explicitly. So I won't make it.
We discussed everything in PM though, just reporting here.


chore(Data/IsROrC): make proper_isROrC an instance

Testing if Lean 4 can deal with this kind of instances.
I'm going to wait for CI, then bench this PR.

Failed to make it work, closing


Running dolly-2.0-3b on a local machine

Any success running the smallest Dolly 2.0 on a local machine? I failed to do so on an Apple M1 MacBook. I understand this might not necessarily be a good enough to run the model but just checking in case I might be doing something wrong.

Probably not; search other issues here for comments. You need a GPU, and won't really be able to access the GPU on a Mac with this.


Fix typos in Import-PfxCertificate calls in service-fabric-cluster-security

Fix extra space in Read-Host call
Remove extra 'C:' in file path

Hi @MattKotsenas, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

@MattKotsenas - Thanks for the fix!


Fixes #298

Looks good to me, but I don't fully know the type internals so perhaps @erizocosmico wants to take a look at it too.

@erizocosmico
According to sql.Scanner, the only reference types are []byte and time.Time?
Not 100% sure about time.Time
// Reference types such as []byte are only valid until the next call to Scan
// and should not be retained. Their underlying memory is owned by the driver.
// If retention is necessary, copy their values before the next call to Scan.


Add support for Somfy Tahoma Alarm

Did you read the instructions?

[X] I have read the README, including the advanced debugging section.

The request
Hi,
I'm not sure if this is already supported, but my integration does not find the built-in alarm of the Somfy Tahoma.
I have some motion and window closure sensors and want to arm and disarm the alarm from HA. Hope you know what I mean.
A month ago I tried the addin of openhab and they use the same Overkiz API and the alarm was detected, so the API should support that. But I really want to use HA instead of openhab.
Should the integration discover the alarm, or is this unsupported?
Thank you for your time and help.
Greetings
Which gateway / hub do you use?
Somfy Tahoma
Device model (optional)
No response
Device type (optional)
No response
Additional information
No response

Please include your diagnostics information. You can download this via the integrations page, 3 dots and than select download diagnostics.

Hi,
thank you for having a look.
I see, that there is a alarm detected, but it does not show in the device list. I am a HA newbie, so I might miss something.
config_entry-overkiz-c7a5b52daea1a27726ebf43bea363277.json.txt

It seems that your alarm control panel is already supported in ha-tahoma (not in core!). If you go to the integrations page and look up the devices of this integration, do you see 'Alarm' in the list?
There should be a disabled alarm control panel entity, that you can enable.

I searched through all devices and entities within the settings filtered by the integration. There is no alarm, partial* or anything. I am only seeing my rooms, sensors, shutters etc. Maybe I am not on the right page? Sorry for my little knowledge. I am trying to evaluate HA.
Is the settings view, the page you mean?

If you go to /config/integrations and than click on "x devices" at the Overkiz integration. Can you send me a screenshot of that page?

Hi,
this was the page I was referring to. On this page there are following entries:
All of my ContactSensor, PositionableRollerShutterWithLowSpeedManagement, SmokeSensor, OccupancySensor and 1 entry with Model: Tahoma Pro.
The list is long, so I think the Model Column is what you wanted to know. If not, please let me know.
On each device page I can do, what I am expecting to do: Roller Shutters can move, ContactSensors let me know their state, etc.
On the Tahoma Pro page, there is only a Device Info (not much info), Diagnose with an HomeKit code and 3 Boxes for automation, Scenes and scripts.
Thank you again for taking your time.

Hi, sadly I am pretty sure.
I sorted after Model and if the name should be the same it should appear between Tahoma Pro and my SmokeSensor, but it does not.

I browsed the diagnostics and I can see there is a TSKAlarmController listed, but I can't see it anywhere in the UI. Sadly I don't speak Python. I tried to add an Alarm Panel on the dashboard, but it says there is no entity to add. Dunno if this is supported.
I tries to reinstall, tried to switch the alarm via the app to get it detected. No success.
Is there any way to add it manually via a configuration file?
Thank you for helping me out.

@ryoshi87 , would you be able to work with me via Discord (iMick #1903) so we can speed up the development? Easiest would be if you could temporary change your password and send your credentials, so I can do some live debugging on my machine.

As said in discord. Seemed to had a setup error on my side. Its working with the latest dev core. Closing this.


append python-gitignore to .gitignore

Not a fan of doing this as i mostly just add to the ignore as required.


V0.2 merge algorithm into agent

Description
Merged Algorithm class into Agent
Linked issue(s)/Pull request(s)

issue_number

Type of Change

[ ] Non-breaking bug fix
[ ] Breaking bug fix
[x] New feature
[ ] Test
[ ] Doc update
[ ] Docker update

Related Component

[ ] Simulation toolkit
[x] RL toolkit
[ ] Distributed toolkit

Has Been Tested

OS:

[ ] Windows
[ ] Mac OS
[x] Linux

Python version:

[ ] 3.6
[x] 3.7

Key information snapshot(s):

Needs Follow Up Actions

[ ] New release package
[ ] New docker image

Checklist

[ ] Add/update the related comments
[ ] Add/update the related tests
[x] Add/update the related documentations
[ ] Update the dependent downstream modules usage

Codecov Report

Merging #259 (7bad295) into v0.2 (97e4fa8) will decrease coverage by 0.15%.
The diff coverage is 36.36%.

@@            Coverage Diff             @@
##             v0.2     #259      +/-   ##
==========================================
- Coverage   64.37%   64.22%   -0.16%
==========================================
  Files         113      112       -1
  Lines        5553     5565      +12
==========================================
- Hits         3575     3574       -1
- Misses       1978     1991      +13

Flag
Coverage Δ

unittests
64.22% <36.36%> (-0.16%)
:arrow_down:

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

Impacted Files
Coverage Δ

maro/rl/agent_manager/abs_agent_manager.py
51.16% <ø> (ø)

maro/rl/model/abs_block.py
66.66% <ø> (ø)

maro/rl/model/fc_block.py
22.91% <ø> (ø)

maro/rl/model/learning_model.py
34.18% <28.57%> (ø)

maro/rl/agent/abs_agent.py
50.00% <31.57%> (-3.34%)
:arrow_down:

maro/rl/agent/dqn.py
22.68% <36.36%> (ø)

maro/rl/agent/policy_optimization.py
30.76% <80.00%> (ø)

maro/rl/actor/abs_actor.py
69.23% <100.00%> (ø)

maro/rl/actor/simple_actor.py
28.57% <100.00%> (ø)

maro/rl/agent_manager/simple_agent_manager.py
35.08% <100.00%> (ø)

... and 1 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #259 (7bad295) into v0.2 (97e4fa8) will decrease coverage by 0.15%.
The diff coverage is 36.36%.

@@            Coverage Diff             @@
##             v0.2     #259      +/-   ##
==========================================
- Coverage   64.37%   64.22%   -0.16%
==========================================
  Files         113      112       -1
  Lines        5553     5565      +12
==========================================
- Hits         3575     3574       -1
- Misses       1978     1991      +13

Flag
Coverage Δ

unittests
64.22% <36.36%> (-0.16%)
:arrow_down:

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

Impacted Files
Coverage Δ

maro/rl/agent_manager/abs_agent_manager.py
51.16% <ø> (ø)

maro/rl/model/abs_block.py
66.66% <ø> (ø)

maro/rl/model/fc_block.py
22.91% <ø> (ø)

maro/rl/model/learning_model.py
34.18% <28.57%> (ø)

maro/rl/agent/abs_agent.py
50.00% <31.57%> (-3.34%)
:arrow_down:

maro/rl/agent/dqn.py
22.68% <36.36%> (ø)

maro/rl/agent/policy_optimization.py
30.76% <80.00%> (ø)

maro/rl/actor/abs_actor.py
69.23% <100.00%> (ø)

maro/rl/actor/simple_actor.py
28.57% <100.00%> (ø)

maro/rl/agent_manager/simple_agent_manager.py
35.08% <100.00%> (ø)

... and 1 more

Continue to review full report at Codecov.

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


Fix GKE RBAC note in installation instructions.

Somehow this note got split into two parts with another note inserted in between.

/assign @joshvanl

Thanks for that! @mltsy  :sweat_smile:
It looks like the formatting is a bit off though. You can test the website locally with ./scripts/server at the repo root, or by checking the deploy/netlify details in the CI information below.
I think it should be the case of added an extra space before the ```bash
/unassign
/assign @mltsy

Oh!  Interesting - it looked fine in both the VSCode preview and the Github preview.
Thanks for the tips - I tried running ./scripts/server and got an error:
Building sites … ERROR 2020/05/14 09:32:04 Transformation failed: SCSS processing failed: file "stdin", line 6, col 1: File to import not found or unreadable: ../vendor/bootstrap/scss/bootstrap.

But I tried with the extra space you suggested and will see how it comes out in deploy/netlify... 🤞

Well that first one didn't work... I'm not sure why - it seems like the markdown processor being used (wherever that is) is not following standard or github markdown specs... must be another flavor I'm not familiar with...?

Huh, that didn't work either - well I'm a little stumped!  I guess I'll just remove the code-block from the blockquote, which makes it read a little weird, but at least doesn't mess up the whole document 😅  If you happen to know what kind of markdown we're supposed to be using here, maybe we can fix it!

/assign @JoshVanL

Wow!  Somehow giving up and removing the blockquote actually made it to what I was trying to do in the first place with standard markdown, and put the code block inside the blockquote! 😆

/approve
/ok-to-test
/lgtm