Numba CUDA Matrix Multiplication Example

Reporting a bug

[] I have tried using the latest released version of Numba (most recent is
visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
[y] I have included a self contained code sample to reproduce the problem.
i.e. it's possible to run as 'python bug.py'.

When executing the example https://numba.pydata.org/numba-doc/dev/cuda/examples.html, the resulting matrix is not filled entirely - only first column. The grid index j is always 0. I was trying it on different computing clusters with jupyter notebooks, e.g., Colab, where numba is of version: 0.54.1. I was not able to run it with the latest numba 0.55.0rc1, but the example seems the same for varying versions. On another cluster, I had the same problems with numba 0.53.1. Input were np arrays of float32 - varying shapes.
See Colab Notebook: https://colab.research.google.com/drive/1uewkzBaGEcrr9CCPeyR0YtJus9I3Nvwf
Would you check that? Do you have any idea on that?
Thanks in advance!

The documentation linked is for an old version (unfortunately Google tends to prioritise it in search results) - the current documentation, which has undergone some fixes to the matrix multiplication example, is at: https://numba.readthedocs.io/en/latest/cuda/examples.html
Could you try the example from the current version of the docs with and let me know if you have any further issues with it please?

Thank you for your fast reply. I checked the example on the link. The code is actually the same and I experience the same problem. I saw there is a sample program call on this page. Hence, I tried it with that sample program call. I get the same problem. It really surprises me that the second grid-index is always 0. Would you look into that?

Many thanks for following up!

I checked the example on the link. The code is actually the same and I experience the same problem.

I'm seeing different code on https://numba.pydata.org/numba-doc/dev/cuda/examples.html (the outdated version) and https://numba.readthedocs.io/en/latest/cuda/examples.html (the latest version) - the matmul kernel looks the same but otherwise the examples are different and there are no examples of launching the kernel on the old documentation.

I saw there is a sample program call on this page. Hence, I tried it with that sample program call.

Can you indicate where the sample program call is please (if it's somewhere in the latest docs)? Maybe we have something else in the docs that needs fixing.

See Colab Notebook: https://colab.research.google.com/drive/1uewkzBaGEcrr9CCPeyR0YtJus9I3Nvwf

The issue in the Colab notebook is that the kernel expects a 2D grid to be launched:
    i, j = cuda.grid(2)

but it is only launched with a 1D grid:
matmul[100, 10](x_d, y_d, z_d, j_d)

and
matmul[100,100](Ax, Bx, Cx, Dx)

The launch configuration is [100, 10] in the first case - this specifies 100 blocks with 10 threads each. Because the block and thread counts are both integers, this gives a 1D grid. For a 2D grid, a tuple of two integers is needed - for example [(16, 16), (16, 16)] would launch a grid of 256 blocks (indexed 0-15 in the x and y directions) with 256 threads each (indexed similarly) - when you call cuda.grid(2), with this grid, threads will get linear indices in the i and j directions from 0 to 256.
If I modify the example to:
import numba.cuda as cuda
import numpy as np

from scipy.spatial.distance import cdist
def sample_random_matrices(shape=(10000, 12)):
    A = np.random.uniform(low=0, high=10, size=shape).astype('float32')
    B = np.random.uniform(low=0, high=10, size=shape).astype('float32')
    return (A, B)

A, B = sample_random_matrices((10, 10))

@cuda.jit
def matmul(A, B, C, D):
    """Perform square matrix multiplication of C = A * B
    """
    i, j = cuda.grid(2)
    if i < C.shape[0] and j < C.shape[1]:
        tmp = 0.
        for k in range(A.shape[1]):
            tmp += A[i, k] * B[k, j]
        C[i, j] = tmp
        D[i,j] = j # I added this for debugging

x_h = np.arange(16).reshape([4, 4])
y_h = np.ones([4, 4])
z_h = np.zeros([4, 4])
j_h = np.zeros([4, 4])

x_d = cuda.to_device(x_h)
y_d = cuda.to_device(y_h)
z_d = cuda.to_device(z_h)
j_d = cuda.to_device(j_h)
matmul[(16, 16), (16, 16)](x_d, y_d, z_d, j_d)

z_h = z_d.copy_to_host()
print(z_h)
print(x_h @ y_h)
print(j_h)

Ax = cuda.to_device(A)
Bx = cuda.to_device(B)
Cx = cuda.to_device(np.zeros((A.shape[0], B.shape[0])))
Dx = cuda.to_device(np.zeros((A.shape[0], B.shape[0])))
matmul[(16, 16), (16, 16)](Ax, Bx, Cx, Dx)
print(Cx.copy_to_host())
print(Dx.copy_to_host())

(changing only the launch configurations) then I see something more like the expected output:
[[ 6.  6.  6.  6.]
 [22. 22. 22. 22.]
 [38. 38. 38. 38.]
 [54. 54. 54. 54.]]
[[ 6.  6.  6.  6.]
 [22. 22. 22. 22.]
 [38. 38. 38. 38.]
 [54. 54. 54. 54.]]
[[0. 0. 0. 0.]
 [0. 0. 0. 0.]
 [0. 0. 0. 0.]
 [0. 0. 0. 0.]]
[[249.87261713<PHONE_NUMBER>3<PHONE_NUMBER>6<PHONE_NUMBER><PHONE_NUMBER>1
<PHONE_NUMBER>3<PHONE_NUMBER>1<PHONE_NUMBER>2<PHONE_NUMBER>2<PHONE_NUMBER>5]
 [260.6976195<PHONE_NUMBER>7<PHONE_NUMBER>2<PHONE_NUMBER>1<PHONE_NUMBER>4
<PHONE_NUMBER>8<PHONE_NUMBER>4<PHONE_NUMBER>3<PHONE_NUMBER>7<PHONE_NUMBER>3]
 [180.12683988<PHONE_NUMBER>2<PHONE_NUMBER>9<PHONE_NUMBER><PHONE_NUMBER>
<PHONE_NUMBER>8<PHONE_NUMBER>9<PHONE_NUMBER>7<PHONE_NUMBER>1<PHONE_NUMBER>4]
 [228.13237385<PHONE_NUMBER>7<PHONE_NUMBER>8<PHONE_NUMBER>9<PHONE_NUMBER>7
<PHONE_NUMBER>6<PHONE_NUMBER><PHONE_NUMBER>3<PHONE_NUMBER>5<PHONE_NUMBER>9]
 [139.92408329<PHONE_NUMBER>6<PHONE_NUMBER>6<PHONE_NUMBER>4<PHONE_NUMBER>5
<PHONE_NUMBER>5<PHONE_NUMBER>3<PHONE_NUMBER>9<PHONE_NUMBER>6  85.52878535]
 [200.28756336<PHONE_NUMBER>3<PHONE_NUMBER>6<PHONE_NUMBER>3<PHONE_NUMBER>
<PHONE_NUMBER>4<PHONE_NUMBER>7<PHONE_NUMBER><PHONE_NUMBER>7<PHONE_NUMBER>1]
 [249.29658222<PHONE_NUMBER><PHONE_NUMBER>9<PHONE_NUMBER><PHONE_NUMBER>4
<PHONE_NUMBER>7<PHONE_NUMBER>1<PHONE_NUMBER>7<PHONE_NUMBER><PHONE_NUMBER>1]
 [171.18225312<PHONE_NUMBER>6<PHONE_NUMBER>4<PHONE_NUMBER>4<PHONE_NUMBER>1
<PHONE_NUMBER>4<PHONE_NUMBER>8<PHONE_NUMBER>2<PHONE_NUMBER><PHONE_NUMBER>6]
 [254.54236126<PHONE_NUMBER>5<PHONE_NUMBER>6<PHONE_NUMBER>4<PHONE_NUMBER>6
<PHONE_NUMBER>4<PHONE_NUMBER>9<PHONE_NUMBER>3<PHONE_NUMBER><PHONE_NUMBER>6]
 [111.72266674<PHONE_NUMBER>5<PHONE_NUMBER>6<PHONE_NUMBER>4<PHONE_NUMBER>7
<PHONE_NUMBER>5<PHONE_NUMBER>1<PHONE_NUMBER>5<PHONE_NUMBER>7<PHONE_NUMBER>4]]
[[0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
 [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
 [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
 [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
 [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
 [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
 [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
 [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
 [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]
 [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.]]

If you make a similar modification, do you get the output you expect?
Note that if you use the code above with larger matrices (more than 256 elements in either direction) then you will need a bigger grid. The example from the new documentation includes a section on launching the kernel, which computes an appropriate launch configuration based on the size of the matrix: https://numba.readthedocs.io/en/latest/cuda/examples.html#id4:
# Controls threads per block and shared memory usage.
# The computation will be done on blocks of TPBxTPB elements.
# TPB should not be larger than 32 in this example
TPB = 16

# ...

threadsperblock = (TPB, TPB)
blockspergrid_x = math.ceil(z_h.shape[0] / threadsperblock[0])
blockspergrid_y = math.ceil(z_h.shape[1] / threadsperblock[1])
blockspergrid = (blockspergrid_x, blockspergrid_y)

fast_matmul[blockspergrid, threadsperblock](x_d, y_d, z_d)

Chapter 2 of the CUDA C++ Programming Guide provides some further background information on launch configurations - although the example code there is in C++, the general principles of execution outlined there also apply in Python.
I hope this is helpful - if anything above needs clarification, please do let me know. If you have additional questions / issues in future, the Numba Discourse can also be a good place to ask - it has more active users answering questions than the Issue tracker.

Thanks a lot for all the details and links. That helped a lot and solved the problem. Now I get the correct results. I see that I overlooked that the 2D grid requires tuples for each value. On the latest documentation page, for the fast_matmul() kernel the launch sample it is correctly stated. From a user experience perspective, it would be nice to have this sample call to launch the matmul() kernel in an analogous ways. All in all the latest documentation with the sample calls to launch the kernel is definitely a very helpful.

That helped a lot and solved the problem. Now I get the correct results.

Many thanks for confirming!

On the latest documentation page, for the fast_matmul() kernel the launch sample it is correctly stated. From a user experience perspective, it would be nice to have this sample call to launch the matmul() kernel in an analogous ways.

This is a good point - will look at updating the docs.

All in all the latest documentation with the sample calls to launch the kernel is definitely a very helpful.

Many thanks for your kind words! I've created a PR that adds a sample call to the matmul kernel: https://github.com/numba/numba/pull/7680
If you could have a look at the updated page (hosted at https://numba--7680.org.readthedocs.build/en/7680/cuda/examples.html) and provide and feedback / further comments on the PR https://github.com/numba/numba/pull/7680, that would be much appreciated!

Closing as it appears that the original issue is resolved and no further follow-up has been received.


TypeError: Cannot read property 'valueDeclaration' of undefined

TypeScript Version:  3.8.0-dev.20191101
Running into this exception when trying to create declarations from .js files.  Cannot use the Playground to illustrate this; it doesn't support .d.ts generation
Using tsconfig.json:
  {
    "compilerOptions": {
      "allowJs": true,
      "checkJs": true,
      "declaration": true,
      "emitDeclarationOnly": true
    },
    "include": ["foo.js"]
  }

Run tsc, which should create foo.d.ts.  Run it again to get the error.
Expected behavior:
a different error about refusing to overwrite .d.ts files
Actual behavior:
$ tsc
/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:78600
                throw e;
                ^

TypeError: Cannot read property 'valueDeclaration' of undefined
    at getExpandoSymbol (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:28794:31)
    at getTypeReferenceType (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:35293:22)
    at getTypeFromJSDocValueReference (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:35332:32)
    at getTypeReferenceType (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:35307:33)
    at resolveImportSymbolType (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:36697:24)
    at getTypeFromImportTypeNode (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:36672:42)
    at getTypeFromTypeNode (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:37005:28)
    at getTypeFromTypeNode (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:36982:28)
    at getDeclaredTypeOfTypeAlias (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:33085:39)
    at tryGetDeclaredTypeOfSymbol (/Users/boneskull/projects/boneskull/sync-monorepo-packages/node_modules/typescript/lib/tsc.js:33216:24)

This may or may not have anything to do with the fact I'm only generating declarations from .js files.

What's the content of foo.js ?

I was having this same issue with the new Typescript 3.7.2. The problem was the import below that's importing a const instead of a type.
Component.jsx
/** @typedef {import('app/utils/validations').INVALID_FILE} INVALID_FILE */

app/utils/validations.js
export const INVALID_FILE = 'INVALID_FILE';

I've also seen this issue when upgrading to TypeScript 3.7.2 (3.6.4 works fine)
I've narrowed it down so that I can only see the error (Cannot read property 'valueDeclaration' of undefined) when type annotations like the following are included:
  /**
   * @param {InstanceType<import('../../utils/templateUtils')['HasNoCostError']>} error
   */
  constructor(error) {

This is the syntax I currently use to annotate that a parameter is an instance of a class which is definied in a separate .js file. I also talk about this here: https://github.com/microsoft/TypeScript/issues/29485#issuecomment-518316889
I've created a small gist which should reproduce the problem: https://gist.github.com/lukehesluke/8ef8e7061c6533e208e055aedb4e31b1
Keen to see how this develops and happy to help if that's useful

I have the same issue. :(
I have no ts files in my repository, and only a couple that use jsdocs to import jsdoc typedefs...
Any advice for tracking down the offending file?
Building project '/home/name/projectName/tsconfig.json'...

/usr/local/lib/node_modules/typescript/lib/tsc.js:78566
                throw e;
                ^

TypeError: Cannot read property 'valueDeclaration' of undefined
    at getBaseConstructorTypeOfClass (/usr/local/lib/node_modules/typescript/lib/tsc.js:32851:40)
    at serializeAsClass (/usr/local/lib/node_modules/typescript/lib/tsc.js:31138:42)
    at serializeSymbolWorker (/usr/local/lib/node_modules/typescript/lib/tsc.js:30937:29)
    at serializeSymbol (/usr/local/lib/node_modules/typescript/lib/tsc.js:30894:38)
    at /usr/local/lib/node_modules/typescript/lib/tsc.js:30879:29
    at Map.forEach (<anonymous>)
    at visitSymbolTable (/usr/local/lib/node_modules/typescript/lib/tsc.js:30878:42)
    at symbolTableToDeclarationStatements (/usr/local/lib/node_modules/typescript/lib/tsc.js:30766:17)
    at /usr/local/lib/node_modules/typescript/lib/tsc.js:29639:106
    at withContext (/usr/local/lib/node_modules/typescript/lib/tsc.js:29659:37)

I tried to get the declaration files for the openlayers project, but failed with error
> shx rm -rf build/ol && shx mkdir -p build/ol && shx cp -rf src/ol build/ol/src && node tasks/serialize-workers && tsc --project config/tsconfig-build.json

/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:78566
                throw e;
                ^

TypeError: Cannot read property 'valueDeclaration' of undefined
    at getExpandoSymbol (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:28787:31)
    at getTypeReferenceType (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:35269:22)
    at getTypeFromJSDocValueReference (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:35309:32)
    at getTypeReferenceType (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:35283:33)
    at getTypeFromJSDocValueReference (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:35309:32)
    at getTypeReferenceType (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:35283:33)
    at resolveImportSymbolType (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:36674:24)
    at getTypeFromImportTypeNode (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:36649:42)
    at getTypeFromTypeNode (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:36982:28)
    at checkImportType (/home/arszp/project/te/openlayers/node_modules/typescript/lib/tsc.js:49326:13)

an error is thrown at code similar to https://github.com/microsoft/TypeScript/issues/34926#issuecomment-550366377

Here's a sample code that'd reproduce this error:
// test.ts
declare namespace ಠ_ಠ.clutz.jspb {
  type AnyFieldType = boolean | number | string;
}
declare module 'goog:jspb.AnyFieldType' {
  import AnyFieldType = ಠ_ಠ.clutz.jspb.AnyFieldType;
  export default AnyFieldType;
}

And here's the runtime behavior when type checking this code:
// index.ts
import * as ts from 'typescript';

const program = ts.createProgram({
  rootNames: process.argv.slice(2),
  options: ts.getDefaultCompilerOptions(),
});

function visit(c: ts.Node): ts.ImportEqualsDeclaration|undefined {
  if (ts.isImportEqualsDeclaration(c)) {
    return c;
  }
  return c.forEachChild(visit);
}

let importEqDecl: ts.ImportEqualsDeclaration|undefined;
for (const root of program.getRootFileNames()) {
  const sf = program.getSourceFile(root)!;
  importEqDecl = visit(sf);
}

const tc = program.getTypeChecker();
const moduleRef = importEqDecl!.moduleReference;
const symbol = tc.getSymbolAtLocation(moduleRef)!;

console.error(ts.SymbolFlags[symbol.flags], symbol.name, symbol.valueDeclaration);
// Prints "TypeAlias AnyFieldType undefined"

To execute, run yarn tsc && node index.js test.ts
Typescript version: 3.5.3

@RyanCavanaugh from what I can tell, the contents of foo.js are irrelevant as long as it outputs some sort of declaration.

To @lepsch's comment, I'll check and see if I am also importing a value instead of a @typedef.  Either way, this seems to be new behavior which was introduced somewhere after v3.7.0-dev.20191017 and on or before 3.8.0-dev.20191101.

Same is happening for us, the stacktrace only includes typescript files so i don't know what's causing it :(

Same issue for me.

I've created a branch in my project which illustrates the problem with v3.7.2.
After cloning this branch, run npm install (or npm ci) and npm run build:declarations, which should dump the error.  tsconfig.declarations.json is the config file used (extending tsconfig.base.json) by this script.
I know this is a far cry from a "minimal, reproducible example," but it's better than nothing. 😝

Rolled back to 3.6.4. No errors with the same code.
Hey @RyanCavanaugh, you have critical production bug here in your compiler!

Is there a way to overcome this without downgrading to 3.6? Weird this issue hasn't got more responses as it seems to be pretty critical, my project just doesn't launch on 3.7.

@ahocevar Thanks for that!  -- I went through minimizing the "far cry" example above, which took almost the same time as getting through a far cry game, and got something manageable.  The problem is when using an import in a jsdoc as you have in index.js.
I checked that it's fixed now, but it'll still be interesting to look at since it's slightly different.

Thanks for the fix @elibarzilay!

Has this been fixed?
Im still getting the error testing against v3.8.0-dev.20191205
Here is my stack trace:
Trace
    at withContext (node_modules/typescript/lib/typescript.js:36361:25)
    at Object.typeToTypeNode (node_modules/typescript/lib/typescript.js:36316:28)
    at typeToString (node_modules/typescript/lib/typescript.js:36283:40)
    at Object.typeToString (node_modules/typescript/lib/typescript.js:33355:24)
    at Parser.getDocgenType (node_modules/react-docgen-typescript/lib/parser.js:284:43)
    at node_modules/react-docgen-typescript/lib/parser.js:331:29
    at Array.forEach (<anonymous>)
    at Parser.getPropsInfo (node_modules/react-docgen-typescript/lib/parser.js:309:27)
    at Parser.getComponentInfo (node_modules/react-docgen-typescript/lib/parser.js:129:30)
    at node_modules/react-docgen-typescript/lib/parser.js:702:27
    at Array.map (<anonymous>)
    at node_modules/react-docgen-typescript/lib/parser.js:701:14
    at Array.reduce (<anonymous>)
    at parseWithProgramProvider (node_modules/react-docgen-typescript/lib/parser.js:694:10)
    at parse (node_modules/react-docgen-typescript/lib/parser.js:71:20)
    at Object.module.exports (node_modules/react-styleguidist/lib/loaders/props-loader.js:41:12)
 FAIL  Failed to compile

[internal]
INTERNAL ERROR: Cannot read property 'valueDeclaration' of undefined
stack trace:
TypeError: Cannot read property 'valueDeclaration' of undefined
    at getBaseConstructorTypeOfClass (node_modules/typescript/lib/typescript.js:40026:40)
    at serializeAsClass (node_modules/typescript/lib/typescript.js:38036:42)
    at serializeSymbolWorker (node_modules/typescript/lib/typescript.js:37770:29)
    at serializeSymbol (node_modules/typescript/lib/typescript.js:37711:38)
    at node_modules/typescript/lib/typescript.js:37686:25
    at Map.forEach (<anonymous>)
    at visitSymbolTable (node_modules/typescript/lib/typescript.js:37685:33)
    at symbolTableToDeclarationStatements (node_modules/typescript/lib/typescript.js:37556:17)
    at node_modules/typescript/lib/typescript.js:36340:106
    at withContext (node_modules/typescript/lib/typescript.js:36362:37)
error Command failed with exit code 1.

Similar to what @jasonwilliams said, can someone please help me understand the state of this bug?
Associated PR #353600 was merged into master and into release-3.7, and a later commit on that branch is tagged as v3.7.3.
Does that mean that this issue is fixed in v3.7.3?

@jasonwilliams, the stacktrace looks like it's in a different place, so probably a different bug...

@elibarzilay the top of the first stack trace leads into the bottom of the second one

I'm seeing the same stacktrace as @jasonwilliams
    TypeError: Cannot read property 'valueDeclaration' of undefined
        at getBaseConstructorTypeOfClass (/home/arian/git/main/frontend/node_modules/typescript/lib/typescript.js:40038:40)
        at serializeAsClass (/home/arian/git/main/frontend/node_modules/typescript/lib/typescript.js:38042:42)
        at serializeSymbolWorker (/home/arian/git/main/frontend/node_modules/typescript/lib/typescript.js:37776:29)
        at serializeSymbol (/home/arian/git/main/frontend/node_modules/typescript/lib/typescript.js:37717:38)
        at /home/arian/git/main/frontend/node_modules/typescript/lib/typescript.js:37699:29
        at Map.forEach (<anonymous>)
        at visitSymbolTable (/home/arian/git/main/frontend/node_modules/typescript/lib/typescript.js:37698:42)
        at symbolTableToDeclarationStatements (/home/arian/git/main/frontend/node_modules/typescript/lib/typescript.js:37562:17)
        at /home/arian/git/main/frontend/node_modules/typescript/lib/typescript.js:36347:106
        at withContext (/home/arian/git/main/frontend/node_modules/typescript/lib/typescript.js:36368:37)

Version: typescript 3.8.0-dev.20191207

See above -- this issue was in the neighborhood of resolveImportSymbolType down to getExpandoSymbol, and these new traces don't seem similar to that.

@elibarzilay right, so do you want me to make a new issue?

@jasonwilliams, yeah, with its own repro (hopefully more minimized than the one for this...)

Any update on this? I'm getting the error with the same stracktrace as @jasonwilliams, but unfortunately cannot narrow it down and make a repro as my project is pretty large and stack doesn't help at all.


fix(virtual-scroll): replace implicit any's

Short description of what this resolves:
Same idea as #9511 from yesterday. Is it possible to have the tests for Ionic run with noImplicitAny to prevent this in the future?
Latest nightly throws me some errors on serve.
[10:01:32]  typescript: node_modules/ionic-angular/components/virtual-scroll/virtual-util.d.ts, line: 22
[10:01:32]  typescript: node_modules/ionic-angular/components/virtual-scroll/virtual-util.d.ts, line: 25
            Call signature, which lacks return-type annotation, implicitly has an 'any' return type.

      L21:  add: {
      L22:      (name: string);
      L23:  };

            Call signature, which lacks return-type annotation, implicitly has an 'any' return type.

      L24:  remove: {
      L25:      (name: string);
      L26:  };

            Call signature, which lacks return-type annotation, implicitly has an 'any' return type.

      L28:  setAttribute: {
      L29:      (name: string, value: any);
      L30:  };

[10:01:32]  typescript: node_modules/ionic-angular/components/virtual-scroll/virtual-util.d.ts, line: 29

I'm using "noImplicitAny": true in my tsconfig.json compilerOptions, which some other developers will probably be using as well.
Changes proposed in this pull request:

Add an explicit void return type

Ionic Version: 2.0.0-rc.3-201612062256

thanks!


rethink algorithm

keyspace of ~1500 words has an recursive descent time estimated at >40 billion years.
We're going to need a bigger boat.

Markov generator with dictionary filter?

large corpus -> foreach (word) { only include if in dict } -> markov (polov!)

https://www.jeffcarp.com/posts/2019/markov-chain-python/

training: http://qwone.com/~jason/20Newsgroups/


Chart widget doesn't show the line

The column is shown in pivot table though

Testcase is here: http://<IP_ADDRESS>/index.html#/d/test/ChartBug.dashboard?ns=SAMPLES

fixed in https://github.com/intersystems-ru/DeepSeeWeb/commit/c993f9c05434e67bd47701f9e31406561fba985c


Bump version, mention exporting /dev/shm

This should bump the Galaxy version to 15.05. Also, a number of the deeptools programs need to write temporary files, which will be placed in /dev/shm. This is fixed to 64 megs in the Docker container and can't easily be changed. It's simple enough to just export the system /dev/shm.

Thanks @dpryan79.
We should fix this behaviour in deeptools. To make it really portable.


Lassoing spots with image basemaps does not get image basemap spots

Does not get the nested spots on an image basemap.

The function that determines which spots are included when spots are lassoed is used in 3 places:

Grabbing the spots to include for Stereonet
Adding a tag to spots lassoed on the map
Listing the spots in the map extent (the screen boundary is used as the "lasso")

Should children spots be included in all 3 instances above? Children spots include spots in image basemaps and strat sections and can include a specified number of generations. @panamint55 @ellennelson10

Talked with Ellen.  It should all image basemap spots for Stereonet and all sunspots in images.  Same for tags.  Same for the map extent, probably.  How hard is this to do?

@panamint55  If they're all the same (if children spots should be included in all 3 situations in the bulleted list above) it is easy and done already. I just need to push it into the code base.

Go for it.


[RND-279] Protect against revealing the OpenSearch password in logs

Before
Note that the username and password are set to the same value here.

After


Standardize log format

Currently our logs are either space delimited strings or json objects.
We should standardize on one format in order to make querying logs easier.
Risk: this is just about housekeeping

Not going to happen.

Not going to happen


What IAM role is required for publish profile?

What IAM role is required to download the publish profile?  Our development team has this greyed out in the portal.  Is there a specific action that can be granted in a custom role to allow this level of access?

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

ID: 8d91844e-d0d6-362a-eae7-575a0b03505f
Version Independent ID: dc6bc695-7c25-8cb2-f4bd-12a866587bb2
Content: Publish to Azure App Service - Visual Studio
Content Source: docs/deployment/quickstart-deploy-to-azure.md
Product: visual-studio-windows
Technology: vs-ide-deployment
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

@shawnstl Thanks for your question. It looks like you're having an issue with the product itself, rather than an issue with the documentation. Here are a few options where you might consider asking your question:
https://social.msdn.microsoft.com/Forums/vstudio
https://www.stackoverflow.com
https://www.reddit.com/r/VisualStudio/
As well, you might also consider using the Report a Problem tool to report the issue.


TypeError: null is not an object (evaluating 'path.node.type')

Hi! I'm currently using a combo of librairies to rewrite an identifier from scripts that can be found while browsing the web.

For reproduction, let's say we'll use the script from https://hoppscotch.io/assets/index-1408198b.js which is a module.

I use meriyah to parse the code using the following:
import { parse } from "meriyah";

const ast = parse(code, {
  module: true
});

Now, I'll use estree-toolkit to traverse the AST, with the following:
import { traverse } from "estree-toolkit";

traverse(ast, {
  $: { scope: true }, // When I disable this (: false), the error goes away... but I need path.scope !
  MemberExpression (path) {
    if (!path.node) return;

    if (path.node.object.type === "Identifier") {
      // do stuff with path.scope ...
      // that part of the code is not important, it already threw anyway.
    }
  }
});

Here is the full trace I get
758 | // From -
759 | //  const { a, b: [c, { d }], e: f = 0, ...g } = x;
760 | // Returns paths to
761 | // - a, c, d, f, g
762 | const findVisiblePathsInPattern = (path, result) => {
763 |     switch (path.node.type) {
               ^
TypeError: null is not an object (evaluating 'path.node.type')
      at findVisiblePathsInPattern (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/scope.mjs:763:12)
      at registerBindingFromPattern (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/scope.mjs:834:4)
      at CatchClause (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/scope.mjs:975:8)
      at crawl (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/scope.mjs:1108:16)
      at init (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/scope.mjs:1052:8)
      at init (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/nodepath.mjs:112:16)
      at crawl (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/scope.mjs:1165:12)
      at init (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/scope.mjs:1052:8)
      at init (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/nodepath.mjs:112:16)
      at crawl (/home/vexcited/Projects/.../node_modules/estree-toolkit/dist-es/scope.mjs:1165:12)

Also, I should mention that I use Bun to run this piece of code. I don't know if that changes anything though.

Thanks for opening a detailed issue. The issue has been resolved. Use v1.7.3.

It's fixed, thanks a lot for the fast reply!


feat(extension): add github cli manual

Description
Raycast extension to search GitHub CLI Manual.
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hello @pernielsentikaer, thanks for the feedback!
I just made the requested changes.


How to customize the subnet of docker_gwbridge

In the swarm mode, there is a bridge named docker_gwbridge which provides the access to outside networks.  It gets the default subnet <IP_ADDRESS>/16. So it add a route <IP_ADDRESS> which conflicts the existing routes. So how can I customize the subnet of docker_gwbridge?

@shaloulcy
You need to create it manually before joining the cluster
Leave the swarm, remove the docker gw network, manually create it passing your configuration then init/join the cluster.

Thanks!!!

@aboch is this documented?

Not sure, need to check.

@justincormack Opened the above for updating the documentation.
I think this issue can be closed now as the requested information was provided.

agreed, closing this issue; documentation is being handled in https://github.com/docker/docker.github.io/issues/400


Unavailable Request type.

Hi,
I am seeing lot of requests where MAPI inspector shows  'Unavailable Request type.'.
Please see the attached screenshots:

Steps to reproduce :
Using outlook, simply compose email with large inline text or attach a file and hit send.
Environment:
Windows 10 Pro.
Outlook (16.0.6326.1019) 32-bit. Office 365 Business.
Fiddler <IP_ADDRESS>.
Thanks.

Hello aongeek - Can you please share your trace with me ?

Hi Tarun,
Please find link below, 2 sessions exported in Fiddler's Session Archive format.
https://www.dropbox.com/s/my0iwfpcoii8uav/trace.saz?dl=0
I observed this issue mostly in case of nspi requests. Please let me know if you need more data.
Thanks.

Thanks,.
From: wazhar<EMAIL_ADDRESS>Sent: Wednesday, January 27, 2016 3:24 AM
To: OfficeDev/MAPI-Inspector-for-Fiddler<EMAIL_ADDRESS>Cc: tarunchopra<EMAIL_ADDRESS>Subject: Re: [MAPI-Inspector-for-Fiddler] Unavailable Request type. (#12)
Hi Tarun,
Please find link below, 2 sessions exported in Fiddler's Session Archive format.
https://www.dropbox.com/s/my0iwfpcoii8uav/trace.saz?dl=0
I observed this issue mostly in case of nspi requests. Please let me know if you need more data.
Thanks.
—
Reply to this email directly or view it on GitHubhttps://github.com/OfficeDev/MAPI-Inspector-for-Fiddler/issues/12#issuecomment-175568893.

Thanks.

Hello Wazhar :
We have updated MAPIFiddlerInspector.dll and MAPI.js at this location ( https://github.com/OfficeDev/MAPI-Inspector-for-Fiddler) which will resolve your issue. Please try these out and share your inputs.
Thanks.

Hi,
NSPI requests are being decoded now. However I have seen several IndexOutOfRangeExceptions. Seems like Decompression function is failing. I have seen such issues before ( with emsmdb requests) but could not conclusively determine where was the issue.
Please see trace and screenshot below.
https://www.dropbox.com/s/thxhsux7ksnet7b/session_2916.saz?dl=0
https://www.dropbox.com/s/tqkdncfezh7uh6p/Screenshot 2016-01-29 22.17.18.png?dl=0
Thanks.

Glad that worked out. One small request ; shall we close this issue and open a new one for 'IndexOutOfRangeExceptions' so that it's easily discoverable looking at the subject line ?

I agree. Please go ahead.

Opened a new issue to track - IndexOutOfRangeExceptions exception. (https://github.com/OfficeDev/MAPI-Inspector-for-Fiddler/issues/15 )

Wazhar : Would request you to close this issue.

Resolved and verified.

Wazhar : This issue (https://github.com/OfficeDev/MAPI-Inspector-for-Fiddler/issues/15 ) is resolved now. Please get the latest binary set and give it a shot.


Use withdraw pattern in the rollback

What's wrong
Currently, in our rollback function, we directly send the reward to the disputer. This frontrunner can detect balance change easily and front-run a rollback.
    function rollback() internal {
       ...
        msg.sender.transfer(reward);
        address(0).transfer(burn);
    }

How can we fix it
We instead define a rewards mapping. The rollback tracks how much reward owes to the disputer, then the disputer can claim the reward by themself.
    function rollback() internal {
       ...
        rewards[msg.sender] = reward;
        address(0).transfer(burn);
    }

    function claimReward(){
        require(rewards[msg.sender] > 0, "No reward for this claimer");
        msg.sender.transfer(reward);
    }

Pros: Watchers are less discouraged to watch.
Cons: Frontrunners are less excited to rush that fraudproof on-chain.
Note: We had this discussion https://github.com/thehubbleproject/hubble-contracts/discussions/444. It says it is desired for frontrunners to outbid the watcher to make a fraudproof seen on chain sooner.

 Anyway, the update of the reward should be additive rewards[msg.sender] += reward;
The safest way to protect from the front-run is the commit-reveal scheme but is sophisticated.

disputer commit hashes
disputer reveal hashes
the earliest committer for the same point gets the bond

Also, all disputers reward could be put into timelock contract, it could protect from smart bots, who try to reach the reward immediately.
For a general bot, there is a risk, that locked money should not be withdrawable for any purposes, that's why the general bot (not specially developed for the hubble) will not front-run such transactions.

Thanks for the quick inputs and the good strategies for front-run protection.
It looks like the withdrawal pattern does not change the arm-race game too much and we still want the frontrunner to compete for the fraud-proof. Let's stay with the status quo.


[koord-runtime-proxy]: fix panic when no hook registered

Ⅰ. Describe what this PR does
When no hook is registered, the dispatch will return a nil rsp, which will cause panic for UpdateRequest

Ⅱ. Does this pull request fix one issue?
partly fixes #352 (the panic part)

Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[ ] I have written necessary docs and comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in make test

/approve


Bad performance of targeted versions of AutoPGD and PGD attacks

I've tested several targeted adversarial attacks (FGSM, PGD, AutoPGD and Fast Wasserstein (not from this framework)) in the same setup: Here you can see the scores for different epsilon values and l_inf norm :

and here, the best score for an epsilon in [0, 0.5] interval and specified norm.

From the results we notice two strange things:

AutoPGD has really bad performance although claiming to have state of the art results
PGD isn't affected by the choice of epsilon

You can find the code for comparison here
To Reproduce
Run the targeted PGD and targeted AutoPGD attacks on CIFAR 10 with different epsilon values
Expected behavior

PGD shall change the score depending on epsilon
AutoPGD shall perform better, according to the paper

System information:

Linux
Python 3.8.5
ART version: 1.5.0
PyTorch 1.7.0

Hi @bezirganyan Thank you very much for using ART!
Thank you for providing the code of your experiments, to get a better understanding I have a few questions: Is your model trained on normalised or un-normalised data? What is the accuracy on benign test data as calculated in line L140

Hi @bezirganyan Thank you very much for using ART!
Thank you for providing the code of your experiments, to get a better understanding I have a few questions: Is your model trained on normalised or un-normalised data? What is the accuracy on benign test data as calculated in line L140

Hi @beat-buesser, Thanks a lot for the reply.
The results are from model trained on an un-normalized data. I also have the one on normalized data, but, I don't have the results of that training anymore.
The accuracy on benign test data is 92.4%.

Hi @beat-buesser, Thanks a lot for the reply.
The results are from model trained on an un-normalized data. I also have the one on normalized data, but, I don't have the results of that training anymore.
The accuracy on benign test data is 92.4%.

Ok, that sounds good.
I looked closer at your code and noticed L112 and L113 overwriting attributes. I'm not sure if this will solve the problem entirely but it might explain why changing eps does not change the mis-classifications of PGD. ProjectedGradientDescent is a wrapper around the framework-specific implementations and the changed attributes are not passed to the actual internal attack. You can either set the attributes with ProjectedGradientDescent.set_params or use ProjectedGradientDescentPyTorch directly to automate setting the parameters.
Would you be able to share the weights for one of the models to run your script?

Ok, that sounds good.
I looked closer at your code and noticed L112 and L113 overwriting attributes. I'm not sure if this will solve the problem entirely but it might explain why changing eps does not change the mis-classifications of PGD. ProjectedGradientDescent is a wrapper around the framework-specific implementations and the changed attributes are not passed to the actual internal attack. You can either set the attributes with ProjectedGradientDescent.set_params or use ProjectedGradientDescentPyTorch directly to automate setting the parameters.
Would you be able to share the weights for one of the models to run your script?

Oh, I see the problem regarding the PGD. Will try again with set_params.
The problem with AutoPGD is independent from that though, right? It responds to epsilon change, but behaves really poorly.
Here you can find the trained model for reproducing the results.
Also I just pushed a small bug fix, so please do a git pull before running the code. The bug fix will not anyhow affect the strange behavior, but will prevent from results overwriting each other.

Oh, I see the problem regarding the PGD. Will try again with set_params.
The problem with AutoPGD is independent from that though, right? It responds to epsilon change, but behaves really poorly.
Here you can find the trained model for reproducing the results.
Also I just pushed a small bug fix, so please do a git pull before running the code. The bug fix will not anyhow affect the strange behavior, but will prevent from results overwriting each other.

@bezirganyan Thank you for sharing the model and the updated code, I'll try it out later today.
Yes, AutoPGD should not be affected by the attributes change, although set_params is also here always the safer approach in case of internal changes in the future. The last time I tested AutoPGD it was slightly better in accuracy than PGD while achieving much smaller perturbations for the test model we used, but we made some changes to AutoPGD recently, therefore I'm very interested to learn how AutoPGD performs in your experiments and to see if something needs to be improved.

@bezirganyan Thank you for sharing the model and the updated code, I'll try it out later today.
Yes, AutoPGD should not be affected by the attributes change, although set_params is also here always the safer approach in case of internal changes in the future. The last time I tested AutoPGD it was slightly better in accuracy than PGD while achieving much smaller perturbations for the test model we used, but we made some changes to AutoPGD recently, therefore I'm very interested to learn how AutoPGD performs in your experiments and to see if something needs to be improved.

@bezirganyan I was able to run your code. So far, one thing I noticed is  that your code is using art.utils.to_categorical in two calls with the default argument nb_classes=None. This leads to unexpected target labels as to_categorical tries to derive the total number of categories from the provided labels which doesn't work for targeted labels, in this case to_categorical needs to be provided as to_categorical(target_classes, nb_classes=10) in lines 71 and 76.

@bezirganyan I was able to run your code. So far, one thing I noticed is  that your code is using art.utils.to_categorical in two calls with the default argument nb_classes=None. This leads to unexpected target labels as to_categorical tries to derive the total number of categories from the provided labels which doesn't work for targeted labels, in this case to_categorical needs to be provided as to_categorical(target_classes, nb_classes=10) in lines 71 and 76.

@beat-buesser thanks. I rerun the code with your suggestions. From the logs it seems that the problem with PGD is resolved, but AutoPGD still performs  poorly. Will keep you updated as soon as I summarize the results.

@beat-buesser thanks. I rerun the code with your suggestions. From the logs it seems that the problem with PGD is resolved, but AutoPGD still performs  poorly. Will keep you updated as soon as I summarize the results.

@beat-buesser Here is the summarized version of the updated analysis.

As you can see the PGD attack now works as expected, while AutoPGD continues to behave poorly, while I believe it had to perform at least as good as the vanilla PGD attack.

@beat-buesser Here is the summarized version of the updated analysis.

As you can see the PGD attack now works as expected, while AutoPGD continues to behave poorly, while I believe it had to perform at least as good as the vanilla PGD attack.

Hi @bezirganyan Thank you very much for the updated experiment code and results.
I looked further into it and I think I have discovered two issues with targeted AutoProjectedGradientDescent that most likely cause your observations:

in the experiments on this (I think) undefended model, the loss value seems to decreases very fast to often numerical 0 already before the first check on having the step size, the loss stays there but it suddenly changes to larger values which I think is caused by amplified random numerical noise in the gradients based on a loss value close to 0. I fixed this with a break condition.

after fixing the first issue I noticed that the criterion for counting if a step got into the right direction should depend on if the attack is targeted or untargeted, currently it is defined for untargeted attacks where the loss criteria is expected to only increase. I modified it to expected a decreasing value for the loss criteria in targeted attacks.

I have pushed the updates to https://github.com/Trusted-AI/adversarial-robustness-toolbox/pull/860
Could you please test it and let us know how it performs in your experiments?

Hi @bezirganyan Thank you very much for the updated experiment code and results.
I looked further into it and I think I have discovered two issues with targeted AutoProjectedGradientDescent that most likely cause your observations:

in the experiments on this (I think) undefended model, the loss value seems to decreases very fast to often numerical 0 already before the first check on having the step size, the loss stays there but it suddenly changes to larger values which I think is caused by amplified random numerical noise in the gradients based on a loss value close to 0. I fixed this with a break condition.

after fixing the first issue I noticed that the criterion for counting if a step got into the right direction should depend on if the attack is targeted or untargeted, currently it is defined for untargeted attacks where the loss criteria is expected to only increase. I modified it to expected a decreasing value for the loss criteria in targeted attacks.

I have pushed the updates to https://github.com/Trusted-AI/adversarial-robustness-toolbox/pull/860
Could you please test it and let us know how it performs in your experiments?

Hello @beat-buesser. Thanks a lot for the fix. I rerun the AutoPGD and now it performs similar to PGD.
Here you can see the results

Now, I suppose it does not perform better, since the model is not anyhow protected. From your own experiments on protected models, does it perform much better than the PGD attack?
Furthermore, when I tried to run the code with the updated version, I got the error"
  File "generate.py", line 71, in attack_model
    x_test_adv = attacker.generate(x=x_test.cpu(), y=to_categorical(target_classes.cpu(), nb_classes=10))
  File "/usr/local/share/anaconda3/lib/python3.7/site-packages/art/attacks/attack.py", line 74, in replacement_function
    return fdict[func_name](self, *args, **kwargs)
  File "/usr/local/share/anaconda3/lib/python3.7/site-packages/art/attacks/evasion/auto_projected_gradient_descent.py", line 474, in generate
    f_0 = self.estimator.loss(x=x_k, y=y_batch, reduction="mean")
  File "/usr/local/share/anaconda3/lib/python3.7/site-packages/art/estimators/classification/pytorch.py", line 508, in loss
    return loss.detach().numpy()
TypeError: can't convert cuda:0 device type tensor to numpy. Use Tensor.cpu() to copy the tensor to host memory first.

Which I fixed by changing return loss.detach().numpy() to return loss.cpu().detach().numpy() in art/estimators/classification/pytorch.py file.

Hello @beat-buesser. Thanks a lot for the fix. I rerun the AutoPGD and now it performs similar to PGD.
Here you can see the results

Now, I suppose it does not perform better, since the model is not anyhow protected. From your own experiments on protected models, does it perform much better than the PGD attack?
Furthermore, when I tried to run the code with the updated version, I got the error"
  File "generate.py", line 71, in attack_model
    x_test_adv = attacker.generate(x=x_test.cpu(), y=to_categorical(target_classes.cpu(), nb_classes=10))
  File "/usr/local/share/anaconda3/lib/python3.7/site-packages/art/attacks/attack.py", line 74, in replacement_function
    return fdict[func_name](self, *args, **kwargs)
  File "/usr/local/share/anaconda3/lib/python3.7/site-packages/art/attacks/evasion/auto_projected_gradient_descent.py", line 474, in generate
    f_0 = self.estimator.loss(x=x_k, y=y_batch, reduction="mean")
  File "/usr/local/share/anaconda3/lib/python3.7/site-packages/art/estimators/classification/pytorch.py", line 508, in loss
    return loss.detach().numpy()
TypeError: can't convert cuda:0 device type tensor to numpy. Use Tensor.cpu() to copy the tensor to host memory first.

Which I fixed by changing return loss.detach().numpy() to return loss.cpu().detach().numpy() in art/estimators/classification/pytorch.py file.

Hi @bezirganyan That's great, thank you very much for the updated results and also for reporting the issue in the first place, the solution of it has already been helpful for other users of ART!
In my experiments on untargeted attacks AutoPGD achieved slightly better attack success in terms of accuracy but with a smaller adversarial perturbations than PGD. An additional interesting visualisation in your experiments could therefore be the mean adversarial perturbation per image and its standard deviation for AutoPGD and PGD as function of eps. Also, AutoPGD and PGD have different default values for the number of iteration and number of random restarts which you could consider before comparing them directly, I think the best would be to optimise these parameters until convergence of the attack success before comparison. You also could then repeat the same experiment with an adversarially trained model e.g. https://github.com/MadryLab/robustness
Thank you for the error message, we have opened a pull request with a fix in #862

Hi @bezirganyan That's great, thank you very much for the updated results and also for reporting the issue in the first place, the solution of it has already been helpful for other users of ART!
In my experiments on untargeted attacks AutoPGD achieved slightly better attack success in terms of accuracy but with a smaller adversarial perturbations than PGD. An additional interesting visualisation in your experiments could therefore be the mean adversarial perturbation per image and its standard deviation for AutoPGD and PGD as function of eps. Also, AutoPGD and PGD have different default values for the number of iteration and number of random restarts which you could consider before comparing them directly, I think the best would be to optimise these parameters until convergence of the attack success before comparison. You also could then repeat the same experiment with an adversarially trained model e.g. https://github.com/MadryLab/robustness
Thank you for the error message, we have opened a pull request with a fix in #862


#275 cassandra container autoconfig

#275

[ERROR]     Non-resolvable parent POM for com.playtika.testcontainers:embedded-cassandra:1.74-SNAPSHOT: Could not find artifact com.playtika.testcontainers:testcontainers-spring-boot:pom:1.74-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 7, column 13 -> [Help 2]

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

Complexity increasing per file
==============================
- embedded-cassandra/src/main/java/com/playtika/test/cassandra/EmbeddedCassandraDependenciesAutoConfiguration.java  1
- testcontainers-common/src/main/java/com/playtika/test/common/utils/FileUtils.java  3
- embedded-cassandra/src/test/java/com/playtika/test/cassandra/EmbeddedCassandraDisabledTest.java  1
- embedded-cassandra/src/main/java/com/playtika/test/cassandra/EmbeddedCassandraBootstrapConfiguration.java  1
- embedded-cassandra/src/test/java/com/playtika/test/cassandra/EmbeddedCassandraTest.java  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- embedded-cassandra/src/test/java/com/playtika/test/cassandra/EmbeddedCassandraDisabledTest.java  1
- embedded-cassandra/src/main/java/com/playtika/test/cassandra/EmbeddedCassandraBootstrapConfiguration.java  1
- testcontainers-common/src/main/java/com/playtika/test/common/utils/FileUtils.java  3
- embedded-cassandra/src/main/java/com/playtika/test/cassandra/EmbeddedCassandraDependenciesAutoConfiguration.java  1
- embedded-cassandra/src/test/java/com/playtika/test/cassandra/EmbeddedCassandraTest.java  1

See the complete overview on Codacy


bind: 9.16.10 -> 9.16.11

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/bind/versions.
meta.description for bind is: "Domain name server"
meta.homepage for bind is: "https://www.isc.org/downloads/bind/"
meta.changelog for bind is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 9.16.11 with grep in /nix/store/rwciv9c8c2zfk4minq19g4l79sv4g4s3-bind-9.16.11

directory tree listing: https://gist.github.com/fc0a5d1d0a75ae519f131dec2cea80e4

du listing: https://gist.github.com/0269c50c2f3e5a440f1a5e3b52676fd3

Rebuild report (if merged into master) (click to expand)

76 total rebuild path(s)

28 package rebuild(s)

28 x86_64-linux rebuild(s)
21 i686-linux rebuild(s)
6 x86_64-darwin rebuild(s)
21 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
acme-sh
autofs5
bashSnippets
bind
blueberry
check-wmiplus
cinnamon.cinnamon-common
cinnamon.cinnamon-gsettings-overrides
cinnamon.cinnamon-screensaver
cinnamon.cinnamon-session
cinnamon.cjs
cinnamon.nemo
cinnamon.warpinator
cinnamon.xapps
dnsutils
dwm-status
host
inxi
monitoring-plugins
nmapsi4
python37Packages.xapp
python38Packages.xapp
python39Packages.xapp
sssd
tests.nixos-functions.nixos-test
tests.nixos-functions.nixosTest-test
testssl
twa

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/rwciv9c8c2zfk4minq19g4l79sv4g4s3-bind-9.16.11 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A bind https://github.com/r-ryantm/nixpkgs/archive/f2c064bb8caf4bb0ec2af0150f332900c3cd4ee4.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/rwciv9c8c2zfk4minq19g4l79sv4g4s3-bind-9.16.11
ls -la /nix/store/rwciv9c8c2zfk4minq19g4l79sv4g4s3-bind-9.16.11/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

dwm-status

25 packages built:

acme-sh
autofs5
bashSnippets
bind
blueberry
check-wmiplus
cinnamon.cinnamon-common
cinnamon.cinnamon-gsettings-overrides
cinnamon.cinnamon-screensaver
cinnamon.cinnamon-session
cinnamon.cjs
cinnamon.nemo
cinnamon.warpinator
cinnamon.xapps
dnsutils
host
inxi
monitoring-plugins (nagiosPluginsOfficial)
nmapsi4
python37Packages.xapp
python38Packages.xapp
python39Packages.xapp
sssd
testssl
twa

Maintainer pings
cc @peti @globin for testing.

Result of nixpkgs-review pr 110369 run on x86_64-linux 1

2 packages blacklisted:

tests.nixos-functions.nixos-test
tests.nixos-functions.nixosTest-test

1 package failed to build:

dwm-status

25 packages built:

acme-sh
autofs5
bashSnippets
bind
blueberry
check-wmiplus
cinnamon.cinnamon-common
cinnamon.cinnamon-gsettings-overrides
cinnamon.cinnamon-screensaver
cinnamon.cinnamon-session
cinnamon.cjs
cinnamon.nemo
cinnamon.warpinator
cinnamon.xapps
dnsutils
host
inxi
monitoring-plugins
nmapsi4
python37Packages.xapp
python38Packages.xapp
python39Packages.xapp
sssd
testssl
twa

Result of nixpkgs-review pr 110369 run on x86_64-linux 1

2 packages blacklisted:

tests.nixos-functions.nixos-test
tests.nixos-functions.nixosTest-test

1 package failed to build:

dwm-status

25 packages built:

acme-sh
autofs5
bashSnippets
bind
blueberry
check-wmiplus
cinnamon.cinnamon-common
cinnamon.cinnamon-gsettings-overrides
cinnamon.cinnamon-screensaver
cinnamon.cinnamon-session
cinnamon.cjs
cinnamon.nemo
cinnamon.warpinator
cinnamon.xapps
dnsutils
host
inxi
monitoring-plugins
nmapsi4
python37Packages.xapp
python38Packages.xapp
python39Packages.xapp
sssd
testssl
twa


How to add nixcasks to pkgs?

Hi,
first of all thank you for this project.
I am pretty new to nix and nixos.
I am using Home Manager, nix-darwin to manage my MacBook unfortunately there is some heavy lifting as you also encountered with homebrew in nix-darwin. Now I found your project and want to use it.
BUT, I do not know how to add nixcasks = inputs.nixcasks.legacyPackages."${system}" to pkgs.
My configuration:
inputs = {
...
nixcasks = {
      url = "github:jacekszymanski/nixcasks";
      inputs.nixpkgs.follows = "nixpkgs";
    };
...
};

outputs = {
   darwinConfigurations = let
      system = "aarch64-darwin";
      specialArgs =
        {
          inherit username usermail userfullname userbusinessmail userauthorizedkeys;
          pkgs = import nixpkgs {
            inherit system;
            config.allowUnfree = true;
            overlays = [
              nur.overlay
              nixpkgs-firefox-darwin.overlay
              nix-vscode-extensions.overlays.default
            ];
          };
        }
        // inputs;
       baseArgs = {inherit agenix nix-darwin mac-app-util home-manager system specialArgs nixpkgs;};
    in {
      macdb = import ./hosts/macdb.nix baseArgs;
    };
};

Thank you for your help!
Daniel

I don't have an answer since I am very much in the same situation.  I've been trying to figure it out by looking at these dotfiles and these dotfiles but haven't had any luck with it yet.  Granted, I also am still new to nix, so I may be missing something obvious.

Could you also post an example of a configuration with Home Manager?  I think that would be really useful.

Sure, here's my flake.nix, my macOS hostname is adapa:
{
  description = "Home Manager configuration of jsz";

  inputs = {
    # Specify the source of Home Manager and Nixpkgs.
    nixpkgs.url = "github:nixos/nixpkgs/nixos-23.05";
    nixpkgs-unstable.url = "nixpkgs/nixos-unstable";
    impermanence.url = "github:nix-community/impermanence";
    nurrepo.url = "github:nix-community/NUR";
    nerdy.url = "github:GenericNerdyUsername/nixpkgs/c6944a78e5edf4341df9518045ab1d723e4c4f5a";
    flake-utils.url = "github:numtide/flake-utils";
    nixcasks = {
      url = "/Users/jsz/Devel/jacekszymanski/nixcasks";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    jacekszymanski = {
      url = "github:jacekszymanski/nur-packages";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    home-manager = {
      url = "github:nix-community/home-manager/release-23.05";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    nix-vscode-extensions = {
      url = "github:nix-community/nix-vscode-extensions";
      inputs = {
        nixpkgs.follows = "nixpkgs";
        flake-utils.follows = "flake-utils";
      };
    };
    darwin = {
      url = "github:lnl7/nix-darwin/master";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    nix-homebrew = {
      url = "github:zhaofengli-wip/nix-homebrew";
      inputs = {
        nixpkgs.follows = "nixpkgs";
        nix-darwin.follows = "darwin";
        flake-utils.follows = "flake-utils";
      };
    };
    homebrew-core = {
      url = "github:homebrew/homebrew-core";
      flake = false;
    };
    homebrew-cask = {
      url = "github:homebrew/homebrew-cask";
      flake = false;
    };

  };

  outputs =
    { nixpkgs
    , home-manager
    , nurrepo
    , jacekszymanski
    , nerdy
    , nix-vscode-extensions
    , nixpkgs-unstable
    , impermanence
    , darwin
    , nix-homebrew
    , ... } @ inputs:

    let
      systems = [
        "x86_64-linux"
        "x86_64-darwin"
        "aarch64-linux"
      ];

      overlay-unstable = final: prev: {
         unstable = import nixpkgs-unstable {
           inherit (prev) system;
           config.allowUnfree = true;
         };
      };

      forAllSystems = f: nixpkgs.lib.genAttrs systems (system: f system);
      stuff = forAllSystems (system: rec {
        nurpkgs = import nixpkgs { inherit system; };
        nerdyjetbrains = (import nerdy { inherit system; }).jetbrains;
        nur = import nurrepo {
          inherit pkgs nurpkgs;
          repoOverrides = { jacekszymanski = import jacekszymanski { inherit pkgs nixpkgs; }; };
        };
        vscode-exts = nix-vscode-extensions.extensions."${system}";
        nixcasks = import inputs.nixcasks {
          inherit pkgs nixpkgs;
          osVersion = "monterey";
        };
        pkgs = import nixpkgs {
          inherit system;
          config.allowUnfree = true;
          config.packageOverrides = prev: {
            inherit nur vscode-exts nixcasks;
            jetbrains = nerdyjetbrains;
          };
        };
      });
    in {

      nixosConfigurations."enkidu" = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          # Overlays-module makes "pkgs.unstable" available in configuration.nix
          ({ config, pkgs, ... }: { nixpkgs.overlays = [ overlay-unstable ]; })
          inputs.impermanence.nixosModules.impermanence
          ./systems/enkidu/configuration.nix
        ];
      };

      darwinConfigurations."adapa" = darwin.lib.darwinSystem {
        system = "x86_64-darwin";
        modules = [
          /*
          nix-homebrew.darwinModules.nix-homebrew
          {
            nix-homebrew = {
              enable = true;
              user = "jsz";
              taps = with inputs; {
                "homebrew/homebrew-core" = homebrew-core;
                "homebrew/homebrew-cask" = homebrew-cask;
              };
              mutableTaps = false;
            };
          }
          */
          ./systems/adapa/configuration.nix
        ];
      };

      homeConfigurations = {
        "jsz@enkidu" = let system = "x86_64-linux"; in home-manager.lib.homeManagerConfiguration {

          inherit (stuff.${system}) pkgs;

          modules = [
            ./hm/conf/enkidu.nix
          ];

          # Optionally use extraSpecialArgs
          # to pass through arguments to home.nix
        };

        "jsz@adapa" = let system = "x86_64-darwin"; in home-manager.lib.homeManagerConfiguration {
          inherit (stuff.${system}) pkgs;

          # Specify your home configuration modules here, for example,
          # the path to your home.nix.
          modules = [ ./hm/conf/adapa.nix ];

        };
      };
    };

}

@jacekszymanski many thanks your first recommendation did work!
I do not know, if this issue can be resolved or not cause @oneirocosm chimed in with another question.
For me personally it can be closed.
Thanks again.

If some cask isn't working for whatever reason, feel free to post an issue with logs/error messages. I'm not saying that every cask is going to work with Nix (e.g. some apps require to be run from /Applications, or run installers and these most probably won't be supported), but some may be fixable, and after merging the overrides branch it will be possible to add/override specific steps for individual casks if that's what's needed.


Provide a view that group answer that share commonalities (same comments or same grade, ...)

#201


Extend client library to support UserIdMapper endpoint

k8s convention for listing resources
On Wed, Jul 10, 2019 at 2:41 PM MarkGreenPR<EMAIL_ADDRESS>wrote:

@MarkGreenPR commented on this pull request.
What's up with the all caps at the end of this: prUserIdMappersLIST
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/pavedroad-io/clients/pull/3?email_source=notifications&email_token=AAM4YWUJTU6NLV3OAWSBNVTP6ZJPTA5CNFSM4H7XOX72YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB6CPOQY#pullrequestreview-260372291,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAM4YWSNL2C3E6BY2L6O3G3P6ZJPTANCNFSM4H7XOX7Q
.

--
John Scharber
Founder/CEO
www.pavedroad.io
(925) 200-7231


[SDP-898] data: increase max attempts to the receiver validate the PII

What
This PR increases the maximum attempts for the receiver validate its PII.
Why
Avoid blocking the receiver forever from receiving the payment.
Known limitations
N/A
Checklist
PR Structure

[x] This PR has a reasonably narrow scope (if not, break it down into smaller PRs).
[x] This PR does not mix refactoring changes with feature changes (split into two PRs otherwise).
[x] This PR's title starts with the name of the package, area, or subject affected by the change.

Thoroughness

[x] This PR adds tests for the new functionality or fixes.
[x] This PR contains the link to the Jira ticket it addresses.

Configs and Secrets

[x] No new CONFIG variables are required -OR- the new required ones were added to the helmchart's values.yaml file.
[x] No new CONFIG variables are required -OR- the new required ones were added to the deployments (pr-preview, dev, demo, prd).
[x] No new SECRETS variables are required -OR- the new required ones were mentioned in the helmchart's values.yaml file.
[x] No new SECRETS variables are required -OR- the new required ones were added to the deployments (pr-preview secrets, dev secrets, demo secrets, prd secrets).

Release

[x] This is not a breaking change.
[x] This is ready for production.. If your PR is not ready for production, please consider opening additional complementary PRs using this one as the base. Only merge this into develop or main after it's ready for production!

Deployment

[ ] Does the deployment work after merging?

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr56.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr56.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr56.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr56.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr56.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr56.previews.kube001.services.stellar-ops.com

@marcelosalloum it was suggested by the team.

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr56.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr56.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr56.previews.kube001.services.stellar-ops.com


Fixes #7301: Set LANG for terminal process

Setting LANG for the terminal process fixes it. This is also useful when running Cygwin under Windows, so I'm not checking for the platform.
Computing the LANG value could be improved by getting all available values from 'locale -a', but would also make the fix much more involved.

Thanks for the test :smile:
I'm thinking this should probably be Mac specific though since I'd rather it didn't change my LANG config on Linux, we also only want it to apply on Unix-like systems.  This can be easily achieved/testable by just adding an setLang parameter to createTerminalEnv:
public static createTerminalEnv(parentEnv: IStringDictionary<string>, shell: IShell, workspace: IWorkspace, locale: string, setLang: boolean): IStringDictionary<string>

let env = TerminalService.createTerminalEnv(process.env, this.configHelper.getShell(), this.contextService.getWorkspace(), platform.locale, platform.isMacintosh);

It also makes sense for Windows when using Cygwin's bash. Currently the locale isn't set properly with that:
$ locale
LANG=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

@chrmarti so there's 2 options then:

LANG is only set when it's not empty
A terminal.integrated.setLocaleVariables setting that's on by default on OS X

I'm leaning towards 2 as I'd rather the terminal didn't have LANG on Linux if I explicitly did not set it.

Looks like I just caused some conflicts with my copy/paste change. After they're fixed you can merge this in :+1:


CoPilot has stopped using the content of the file, or much any context at all

Possibly related to #1274

VS Code Version:  1.89.1
OS Version: macOS Sonoma
CoPilot Version: v1.198.0

Steps to Reproduce:

Have a file open with some code you want help with
Ask CoPilot a question

Expected:

CoPilot uses the file, and even the project, as context for understanding the question.

Actual:

CoPilot gives some general answer as if there is no context
It actually even seems like it doesn't use the chat history as context

Asking CoPilot to take the file into consideration, it just says it is an AI and can't do such things. Selecting text doesn't help either. The only trace I've seen is that it once referred to the filename.

Same answer as in https://github.com/microsoft/vscode-copilot-release/issues/1274#issuecomment-2148781028- likely, the context isn't fitting into the context window. You can also install the latest update and see if it's any different. In the latest we should not list the selection in Used References if it was not actually used. Concrete examples also help

I had no selection when I first encountered this, and only a rather small (30-ish LOC) selection when I tried that.
However, I can no longer reproduce the problem, even in the same file, using the same question.
As for concrete example. I had this file opened: https://github.com/BetterThanTomorrow/calva/blob/published/src/providers/inspector.ts
My chat question was:

Is it possible to render an item differently when it is expanded than when it is collapsed?

Here's a screenshot of the exchange:

It was very unlike how I am used to CoPilot working. But since it is now back in its old excellent self, I'm fine with this issue being closed.

Ok, maybe there was actually an issue before. Glad it's working better now.


[pylint] Implement invalid-length-returned (PLE0303)

Add pylint rule invalid-length-returned (PLE0303)
See https://github.com/astral-sh/ruff/issues/970 for rules
Test Plan: cargo test
TBD: from the description: "Strictly speaking bool is a subclass of int, thus returning True/False is valid. To be consistent with other rules (e.g. PLE0305 invalid-index-returned), ruff will raise, compared to pylint which will not raise."

The tests run locally fine when using commit 670d66f as rebase, but there are failures when using the next commit, c221035. Was there some limit reached (rule is u16 in rule_set.rs / contains()) maybe?

Try bumping the value in const RULESET_SIZE: usize = 13;

Try bumping the value in const RULESET_SIZE: usize = 13;

@charliermarsh Is the performance drop of 4% also related to this please? The newly introduced rule is quite lightweight.

@tibor-reiss I bumped the index (and fixed the perf regression). You can rebase and we should then see the impact of your rule.


Added tty, stdinopen, workingdir for system-services

Fixes #220, #213, #214.

Added .DS_Store in .gitignore based on #231.

Can you make this change in the refactor branch of rancher-compose
https://github.com/rancherio/rancher-compose/tree/refactor

Godeps folder is vendored code which means the source is in a different repo that we copy in.  So we don't change anything in Godeps.

Closing this PR as I've moved the change into the correct folder.


docker-compose: add dcip function

function that shows the IP address of a running docker-compose service
Cannot use an alias, since the function takes an argument

I rather put this in a feature branch of my repo


Device side - device twin does not include Tags

There is an error in this statement: "Retrieve device twin. This operation returns the device twin document (including tags and desired and reported system properties) for the currently connected device."
The device-side device twin does not include the tags. This is also stated above in the overview picture.

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

ID: 8ff6fbb2-5679-a9e7-b9f3-40d638cadae8
Version Independent ID: fa51c99a-0df6-cebf-aecc-b08df5f85454
Content: Understand Azure IoT Hub device twins
Content Source: articles/iot-hub/iot-hub-devguide-device-twins.md
Service: iot-hub
GitHub Login: @wesmc7777
Microsoft Alias: wesmc

@sebader Thanks for reaching out! we are currently investigating and we will update you shortly

@sebader Thanks for catching that and taking the time to report it. I have assigned the issue to the content author to evaluate and update as appropriate.

@reassign JimacoMS3

Hi @sebader -- thanks for the catch! And thanks for taking the time to report it. I'll make the change to the topic and let you know when it's published. Thanks again!
-Jimaco

#reassign JimacoMS3

Hi @sebader,
Thanks again for your feedback. I've updated the topic here: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-device-twins#device-operations . Please let me know if any other changes are required.
Best,
Jimaco

looks good! thanks


Non-Inventoriable items on codeunit Release Service Document (COD 416)

Good afternoon. In the course of a development, we found an isue in the Service Module. When we try to release a Service Order the system will check for the Location Code in the Service Line table (5902). However, if we want to select for the Service Order an Item of type = Service (which is Non-Inventoriable) the validation for the Location Code does not make sense to be executed. Making a comparison with the action of release in the Release Sales Order action (COD414), the validation that is present is that the Location Code validation should only exist for items of type Inventoriable. In the ServiceLine table there is a function to check if the item is Non-Inventoriable, so, the soulution would be something like this:
[Behaviour of the Release Sales Order action with evidence to the Inventority of the Sales Header (COD414)]

[The same behaviour does not exist int the Service Order Release Action (COD416)]

[Suggested solution for the problem in evidence (COD416)]

We would like to ask you if in a future release a fix like the suggested solution could be shipped.
Thank you and best regards
Jorge Correia

Thank you for reaching out. Your request could be reporting a product bug not related to the AL extensibility. Please reach out to the relevant support channels as specified in Product Support
On premises - https://support.microsoft.com/en-us/supportforbusiness/productselection?sapId=93d37907-ad94-d591-22e9-593cfa09dd3f
On line – read more here https://docs.microsoft.com/en-ca/dynamics365/business-central/dev-itpro/administration/manage-technical-support or contact your partner
If you are a partner open a support incident through Partner Center - https://partner.microsoft.com/en-us/pcv/dashboard/overview


dependencies needed for net-browserify

Do We have to add the below dependencies along with net-browserify.

You have to run a websocket proxy for this library to work.

Thank you

No, it isn't possible to open arbitrary connections from the browser because of security.


Performance issues when running in development mode

Describe the Bug
When running my application locally, I experience severe lags when dragging nodes. When opening this issue, I deployed the app on Netlify and noticed that the performance problems are vanished. I have attached videos that show this issue. The deployed version is available at https://react-flow--arguemapper.netlify.app.
Your Example Website or App
https://github.com/recap-utr/arguemapper/tree/react-flow
Steps to Reproduce the Bug or Issue

Run the app locally.
Click on Load Demo on the right sidebar.
Move the nodes around on the canvas.

Expected behavior
The expected behavior can be seen on the deployed version.
Screenshots or Videos
https://user-images.githubusercontent.com/5160954/178964220-46fca166-2d9e-4bcb-9c0a-a646d9d4cd93.mp4
https://user-images.githubusercontent.com/5160954/178964304-45c1613c-1c1c-41ea-a7b3-5962b2f331b5.mp4
Platform

OS: macOS
Browser: Safari (also happens with the newest version of Chrome, but to a much lesser extent)
Version: 15.5

Additional context
No response

I had the time to perform some additional investigation on this matter. The problem seems to be tied to the mode React is running in. If I set NODE_ENV=production, then the lags do also not occur when running locally.
My impression is that the lags are caused by updates to the viewports when the nodes are dragged by the user. Here is an error message that is shown after moving a node around for a few seconds:
react-dom.development.js:86 Warning: Maximum update depth exceeded. This can happen when a component calls setState inside useEffect, but useEffect either doesn't have a dependency array, or one of the dependencies changes on every render.
printWarning		@	react-dom.development.js:86
error			@	react-dom.development.js:60
checkForNestedUpdates	@	react-dom.development.js:27300
scheduleUpdateOnFiber	@	react-dom.development.js:25475
dispatchSetState	@	react-dom.development.js:17527
(anonymous)		@	Graph.tsx:131
updateNodePositions	@	slicedToArray.js:7
(anonymous)		@	useViewport.js:18
call			@	dispatch.js:57
gesture			@	drag.js:148
mousemoved		@	drag.js:71
(anonymous)		@	on.js:3

Hey @mirkolenz
thanks for the additional information and the repo. I will see if I can find something. Does this happen with our examples as well or in your code base?

@moklick I just cloned the stress test example to run it locally. I did not experience this problem at all: It is just as fluid as on the web page and the error regarding the maximum update depth is not thrown when dragging nodes around. So it seems to be something related to my codebase. I created my own context provider for managing states of the graph. Could "nested context providers" be related to this issue?

This is not an issue with React Flow. I would put the nodes and edges in a separate context or better use a library like Zustand. It's 1.1kb minified and gzipped and saves you a lot of work and headaches :D Right your context changes whenever you drag a node. That means that the Inspectorcomponent for example re-renders while you drag a node, even if it doesn't request the nodes array.

Thank you for having a look. I migrated everything to Zustand and did not observe a major performance boost. What did the trick for me was to use a local state for the nodes. Now only the canvas is rerendered when dragging nodes.
Thank you so much for looking into my issue even though it was not caused by a bug in React Flow!

In most cases it's possible to achieve this even if the nodes and edges are stored in the global store. Only the components get re-rendered on drag where you import the nodes from the store. This isn't always necessary. There are two ways to prevent this.

You only need specific information of the nodes: Let's say you want to display the names of the nodes, then you could write a selector that only selects this information:

const nodeNames = useStore(s => s.nodes.map(n => n.data.name));

You need the nodes in an event handler: You can access the store with help of the useStoreApi without triggering re-renderings in an event handler for example:

const store = useStoreApi();

const onClick = () => {
  const { nodes } = store.getState();
  console.log(nodes);
}

I am learning so many things, thank you 😃
Just one question regarding useStoreApi(): Is this a special hook exposed by Zustand? I am only aware of the set, get, api utilities within a store but am unable to find references to useStoreApi()

We are using Zustand with a Provider (because there might be multiple RFs on a page or a user want to put the ReactFlowProvider somewhere higher in the tree) but if you are using Zustand the normal way you can just do:
const useStore = create(() => ({ nodes:[] }));

// somewhere in an event handler or useEffect
useStore.getState().nodes;

https://github.com/pmndrs/zustand#readingwriting-state-and-reacting-to-changes-outside-of-components

Ah, ok. Thank you for the clarification. I will try to get rid of my "local" states with these tips 😄

Good Afternoon, Im using Redux Toolkit with react flow, and while using "onNodesChange" from the library itself in the store, the node lags like hell and if I use use useNodesState in the component itself then it works fine. Early help would really be appreciated.

@Pegasus2212 could you create a codesandbox for this?


vm: BigInt intrinsics can take quadratic time without checking for interrupts

If someone does a BigInt operation in a background isolate, the intrinsified operations can take quadratic time without checking for an interrupt / safepoint request. This can prevent a foreground isolate in the same group from reaching a safepoint and create arbitrarily long pauses.

One way to avoid the issue is to not use the quadratic code for 'big' problems, e.g. switch to Karatsuba multiplication for bigger products.


Add SIGIR21 to the Anthology

[ ] Add SIGIR21 to ir.chatnoir.eu
- [x] Run GrobID extraction
- [ ] Add to index
[ ] Add dblp entries to ir.webis.de

sigir 2021 is listed as journal in the dblp is that correct or shall i add it to the conference?


Drop-down goes below footer in Add role

Rancher versions: 2.0 master 1/31
Steps to Reproduce:

Go to Security/Roles
Click on Add Role
Click on Inherit from a Role drop-down

Results:  The drop-down goes below the footer.  We shouldn't do this.

Version - 2.0 master 2/1
Verified fixed


[BUG] Red/pink hues in RGB images produced by the OV9782 sensor on OAK-D-Pro-W-97 camera

Check if issue already exists
[x] Google it (e.g. error xy github luxonis depthai)
[x] Check troubleshooting in documentation.
Describe the bug
This issue is captured in a good amount of detail in this blog post from Luxonis on Color Filtering Enhancement.
I am experiencing the same issue with significant red/pink hue affecting the color camera images, however this does not only appear in outdoor environments as implied by the blog post. In fact, I have been testing exclusively in an indoor office environment (e.g. mainly under fluorescent lighting).
Here is the image I'm seeing (plain white whiteboard used to highlight the significant hue):

Minimal Reproducible Example
Very straightforward MRE (single .cpp file):
main.zip
After reading this blog post on the Lense Shading Correction issue, and also this page on Camera tuning for the OV9782, I went ahead and downloaded the indicated tuning blob for the OV9782 sensor and dropped the following in at line 9 of the above .cpp file:
int main() {
     // Create pipeline
     dai::Pipeline pipeline;
     pipeline.setCameraTuningBlobPath("/home/andre/Downloads/tuning_color_ov9782_wide_fov.bin");

and when I re-run the program this is the output image:

As you can see, there is still a significant and unacceptable amount of red/pink hue affecting the image. If anything it looks significantly worse.
For a good baseline of what I'd expect to be seeing, here is an image captured of the whiteboard using the above program, but using the OAK-D Pro (non-wide version):

Expected behavior
I would have expected the new camera tuning blob to help the red/pink hue issue, even if at least marginally. See above for more info.

I haven't received a replacement yet. You can check to see if this is actually the issue by getting an IR LED and seeing if the camera can see the IR LED in an else dark environment. If it has the IR filter like the imx378 type cameras you should only see a little red dot. If you see lots of red then the cameras have the issue.

Thank you for reporting. We will replace the faulty devices - please reach out to us<EMAIL_ADDRESS>if you haven't already to discuss the next steps.
The new batch of units should be available any day now. We are sorry for the issues and delays.
Thank you,
Karolina


Combine version strings for multi-module dependencies

Signed-off-by: Daniel Widdis<EMAIL_ADDRESS>Description
Reduces the noise of dependabot updates by only having a single version to update.
Issues Resolved
Fixes #229
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Should we keep a variable for implementation "org.apache.lucene:lucene-core:9.4.0-snapshot-ddf0d0a"?

Should we keep a variable for implementation "org.apache.lucene:lucene-core:9.4.0-snapshot-ddf0d0a"?

My usual preference is to have all versions as separate properties.
My fix commit crossed paths with your comments -- do you want me to change all dependencies in the file to the same format?

My fix commit crossed paths with your comments -- do you want me to change all dependencies in the file to the same format?
Looks like you already did. Looks clean now!


Desc $0.02

Only use bulleting if u have a minimum of 3 bullet points
a succinct paragraph under ur ## DESC works just fine
no need to uselessly "flower up" ur presentation

Fixed unnecessary bullet points in readme


[resotocore][feat] Uml model shows dependant complex types

Example

Codecov Report

Merging #913 (d1bb2f1) into main (ea63d67) will decrease coverage by 0.10%.
The diff coverage is 61.53%.

@@            Coverage Diff             @@
##             main     #913      +/-   ##
==========================================
- Coverage   90.35%   90.24%   -0.11%
==========================================
  Files          70       70
  Lines       10194    10224      +30
==========================================
+ Hits         9211     9227      +16
- Misses        983      997      +14

Flag
Coverage Δ

resotocore
90.24% <61.53%> (-0.11%)
:arrow_down:

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

Impacted Files
Coverage Δ

resotocore/resotocore/model/model_handler.py
37.14% <0.00%> (-5.72%)
:arrow_down:

resotocore/resotocore/web/api.py
72.93% <0.00%> (ø)

resotocore/resotocore/db/arango_query.py
95.90% <100.00%> (ø)

resotocore/resotocore/model/model.py
92.38% <100.00%> (+0.15%)
:arrow_up:

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 ea63d67...d1bb2f1. Read the comment docs.


Profile picture appears rotated 90 degree (horizontal) when displayed as avatar

First avatar thumbnail is horizontal, but appears vertical in "Profile" section.

Fixed the bug! I'll make a PR and merge

I can't seem to reproduce the bug on my local instance on my laptop. Could this be a bug on mobile only? I'll look into testing on mobile first.

It's typically caused by mishandling EXIF data of photos from smartphone cameras. I just deployed the recent merge. Try to re-upload the image your previously used on the live version.

Did you deploy to the public site on heroku? I still see the bug on mobile.
I was able to access my local server on mobile and reproduce the error--your branch fixed it!

Oops, I thought it has been merged with main already. I just reviewed and merge the PR, so it should deploy to the public site shortly.


OsAbort in Xorg with nvidia driver and hybrid graphics (21.11)

Describe the bug
After upgrading from 21.05 to 21.11, Xorg crashes after logging in with lightdm when using the nvidia driver.
This happens regardless of session (i3, xterm, i3+xterm), hardware.nvidia.package (default or beta), and whether or not prime.sync is enabled. The problem only goes away if I unset services.xserver.videoDrivers (which results in the modesetting driver), or switch to Discrete Graphics mode in firmware setup (which breaks the ability to dim my backlight). I can also do both, which results in the nouveau driver, but that’s too slow for my needs.

journalctl -o cat -rg '\(X\) of user 0 dumped core'
X.0.log

#0  0x00007f3172463bda raise (libc.so.6 + 0x3bbda)
#1  0x00007f317244e533 abort (libc.so.6 + 0x26533)
#2  0x00000000005a626a OsAbort (Xorg + 0x1a626a)
#3  0x00000000005aba23 AbortServer (Xorg + 0x1aba23)
#4  0x00000000005ac776 FatalError (Xorg + 0x1ac776)
#5  0x00000000005a354c OsSigHandler (Xorg + 0x1a354c)
#6  0x00007f317260fee0 n/a (libpthread.so.0 + 0x12ee0)

Additional context

ThinkPad X1 Extreme Gen2 (20QV) with firmware in Hybrid Graphics mode
00:02.0 VGA compatible controller [0300]: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] [8086:3e9b]
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q] [10de:1f91] (rev a1)

Notify maintainers
(not sure who maintains the nvidia or xorg modules, maybe @lovesegfault or @Artturin might know?)
Metadata

system: "x86_64-linux"
host os: Linux 5.10.113, NixOS, 21.11 (Porcupine)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.16
channels(root): "nixos-21.11.337467.aa2f845096f, nixos-20.03-20.03.3330.1db42b7fe38, nixos-20.09-20.09.4407.1c1f5649bb9, nixos-21.05-21.05.4726.530a53dcbc9, nixos-21.11-21.11.337467.aa2f845096f, nixos-hardware, nixos-unstable-22.05pre376824.41ff747f882"
channels(delan): "home-manager-21.11, home-manager-20.03-20.03, home-manager-20.09-20.09, home-manager-21.05-21.05, home-manager-21.11-21.11, home-manager-unstable, release-20.03.tar.gz-20.03, release-20.09.tar.gz-20.09"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Resolved by removing my unused channels (cheers @K900):
k: You have like
k: Way too many channels
k: Are you sure you're not mixing ABIs somehow?
d: i only use the others to grab the occasional application, e.g. discord from nixos-unstable. i can try removing everything except nixos and home-manager…
k: That would be the first place I'd look
k: Usually when X crashes like that, it's an ABI mismatch thing
d: thanks, that worked (and i even kept nixos-hardware)! but how can channels that aren’t referenced in configuration.nix affect the build?
k: They probably got dragged in somehow


added details and example on usage of teamcity.default.properties file

Additional testing showed that there is something wrong here. Let me double-check and get back to it.

Additional testing showed that this parameter isn't working correctly: https://youtrack.jetbrains.com/issue/TW-90130

Additional testing showed that this parameter isn't working correctly: https://youtrack.jetbrains.com/issue/TW-90130

so... Do I merge this or not? :)

I will close it, as it's currently unclear. Let's wait for the fix/explanation. I will then recreate.


build: add test run Node.js 12 & Python 3.7 on macOS

Checklist

[ ] npm install && npm test passes
[ ] tests are included
[ ] documentation is changed or added
[x] commit message follows commit guidelines

Description of change

Travis CI: Add test run Node.js 12 & Python 3.7 on macOS
Edit: This test is currently run in allow_failures mode because Linux and macOS share the same env: values.

@cclauss good call, there are indeed failures there. If you plan to fix these, you can add the fixes to this PR. If not, this new run should be added to allowed failures.
Just in case it's useful, to quickly see the error locally I use
EXPERIMENTAL_NODE_GYP_PYTHON3=1 NODE_GYP_FORCE_PYTHON=python3 node bin/node-gyp.js rebuild -C test/node_modules/hello_world/ --loglevel=verbose

The Python 3 on macOS job is already run in allow_failures mode because Linux and macOS share the same env: values.  This new test in this PR is really only interesting in combination with #1843, #1844, or #1845.

The failures in test-find-python are fixed in https://github.com/nodejs/node-gyp/pull/1843, I think they're safe to ignore here. There are other failures there that show real issues.
@cclauss if you'd prefer, I can include this in https://github.com/nodejs/node-gyp/pull/1843 leaving osx python 3 in allowed failures. Would that be better?

Yes.  Please include in #1843 and I am OK withleaving osx python 3 in allow_failures mode.

Closing in favor of #1843 which now includes these changes.


[Bug]: Footer Section alignment issue

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
Elements of footer section are not aligned properly.
Social Media icons are overlapping.
Twitter's old logo has been displayed.
Contact details is displaying in multiple line, that the number must be in 1 line.
Expected behavior
Enhancement in footer section in required.
Add ScreenShots

On which device are you experiencing this bug?
Chrome, Windows
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[ ] I'm a VSOC'24 contributor
[X] I have starred the repository

@apu52 @itsekta , please assign this issue to me under GSSoC'24.
Thank You!

Hey ! have solved the issue , plz review and merge my PR ..

Hey ! @apu52 @itsekta , i have solved the issue , plz review and merge my PR ..

@Aryan681 I want to inform u that u are not assigned in this issue . First raise an issue properly , then after only when u get assigned , u can submit your PR . I am closing your PR


Forum specs

These are the specs to create a functioning forum including forum management and moderation.

Question regarding specs, I take it these will be at some stage converted in to integration tests via something like cucumber.js?

@belairWCD With either cucumber, jasmine, or a combination of the two.


Change runtime failures to BT::NodeStatus::FAILURE, add logging info to ExecutorClient

Also removed duplicate node pointer in execute_action_node.cpp
Solves: #174, #175
Contributes to: #161

Hi @sarcasticnature
Could you add some tests to cover and verify all your contributions?
Thanks!!

The rationale for utilizing a member variable (return_failure) to signal a failure is that it will not break existing implementations, i.e. people who are already deriving from the class are not required to change their code despite the new feature.

I am willing and able to add tests, but am not well practiced at writing them.  I'll request that you take a close look at them once completed to make sure that they are written properly

I'll request that you take a close look at them once completed to make sure that they are written properly

Sure!!

Actually, if I run colcon test with the arguments specified in the GitHub action, I get a ton of test failures in multiple packages (none of which I touched).  The first test case of plansys2_bt_actions (load_plugins) crashes before it even gets to the new test cases.
If, however, I run the tests on bt_action_test only (colcon test --event-handlers console_cohesion+ --return-code-on-test-failure --packages-select plansys2_bt_actions) everything passes.
@fmrico thoughts?

the errors with the other packages seem to be caused by running tests in parallel, everything seems to work with --parallel-workers 1 or --executor sequential
still no clue why the on_feedback test is failing though

Yes, @sarcasticnature , you need to add --parallel-workers 1. Tests on some packages can interfere with tests in other ones.

it looks like the tests passed this time without any changes to them... another point toward there being a race condition in the ROS action feedback/result.
@fmrico could you give the tests a shot on your machine?

I have tested it locally, and everything seems to be working well!!
Thanks @sarcasticnature