Heatmap doesn't render (v6.12)

Describe the bug
Heatmap layers do not appear on the screen, despite being present as layers on a map object
I should note that the heatmap DOES appear when developing on localhost. I'm using Webpack to bundle a react app - but even when I normalized the differences between the webpack = production and webpack = development environments the same behaviour occurs (not visible on production build)
Since there are so many differences between developing on localhost vs on a https domain, and using webpack with development/production mode, I thought it worth posting here as a starting point to figure out the problem. Hope that's okay!
Looking at the site - nccrd.saeon.ac.za the map clearly works as do other layers. It's just the heatmap that does not. I have also tried running npm install instead of npm run ci to see if the problem was maybe related to the lock file (it is not - this did not help)
To Reproduce

Go to https://nccrd.saeon.ac.za. There should be a yellowish heat map on top of the base map
Go to the developer console. the map, and other relevant objects have been attached to the window object for debugging

// window objects
window.VectorSource // (import VectorSource from 'ol/source/Vector')
window.WKT // (import WKT from 'ol/format/WKT')
window.Heatmap  // import Heatmap from 'ol/layer/Heatmap'

// (1) Defined the layer making function
makeLayer = data => {
  const format = new WKT()
  return new Heatmap({
    gradient: ['#893448', '#d95850', '#eb8146', '#ffb248', '#f2d643', '#ebdba4'],
    source: new VectorSource({
      features: data.POINT_LOCATIONS.data.map(({ xy, normalizedBudget }) => {
        const feature = format.readFeature(xy, {
          dataProjection: 'EPSG:4326',
          featureProjection: 'EPSG:4326',
        })

        feature.set('normalizedBudget', normalizedBudget)
        return feature
      }),
    }),
    blur: 100,
    radius: 80,
  })
}

// (2) Create the layer
heatMapLayer = makeLayer(data)

// (3) Add the layer
map.addLayer(heatMapLayer)

By interrogating that map object, you can see that the heatmap layer just ... doesn't show:
// Confirm that the map object is the map that is on the screen
map.getAllLayers()[0].set('opacity', 0.3) // it is!

// There are 3 layers - the 3rd is the heatmap that we just added above. delete it
map.removeLayer(map.getAllLayers()[2])

// Now there are 2 layers. The base layer and the invisible heatmap
heatmap = map.getAllLayers()[1]

// And I can see that all the features are there as supposed to be
heatmap.getSource().getFeatures() // This looks the same as on localhost

Also, looking at the DOM output, I can see that the <canvas> element seems to be correctly placed and sized. I have no idea why Heatmap layers just don't seem to appear on maps.
Expected behavior
I expected the heatmap to render!

The source code is here, in case it is helpful: https://github.com/SAEON/national-climate-change-systems

map.getLayers().item(1).getSource().getFeatures().map(function(f){return f.getGeometry().getType()}) shows you have features with geometry collections (containing mostly one, occasionally two point geometries).  Heatmap requires features with a point geometry, not a geometry collection.

Hi @mike-000. Thank you so much for a quick reply!
I can see that when I change the WKT to be POINT WKT instead of GEOMETRYCOLLECTION that things work. The API delivers points in the form of GEOMETRYCOLLECTION () that defaults to POINT () when my xy column is null. This happens a lot on localhost but not at all on the test deployment (I didn't realize that).
I thought the heat map wouldn't mind GEOMETRYCOLLECTION so long as it contained only points, but I guess that the Heatmap will at some point filter out non point locations?
This took me a fair number of hours to (not) figure out - I definitely won't make this mistake again. It may be easier to use the heatmap in general if there was a warning / error if non-point geometries are fed to it

A reasonable expectation perhaps as before OpenLayers version 6 any geometry which was stylable as a point (including MultiPoint, and Point within GeometryCollection) would have worked, and other geometry types could be made to work by setting a point geometry in the style - e.g. https://stackoverflow.com/questions/56780705/creating-heatmap-in-openlayers-with-vector-source-containing-linestrings which does not work with version 6.
For both Heatmap and WebGLPointsLayer on which it is now based I think a geometryFunction option similar to that available in ol/source/Cluster https://openlayers.org/en/latest/apidoc/module-ol_source_Cluster-Cluster.html could be a useful addition to allow it to be used when sources contain features with other geometries.

Simply improving the type for the WebGLPoint layer's source, i.e. changing it from VectorSource to VectorSource<Point> would make it obvious that only point geometries work. That would be a quick fix.

That would be helpful @ahocevar. Would that throw an error if something other than VectorSource<Point> was provided even if I were consuming the library in a non-typescript project?

@zachsa When you use an IDE with TypeScript integration (e.g. VS Code), it will show you a warning. Also when your project is in JavaScript. This is the setup I use, and I find it very helpful.

Would it be possible to log that warning to the console at runtime?
I have noticed using vs code that I get a lot of things that seem in some way to be associated with typescript (I guess). Intellisense for instance methods for one. But I don't really know how it works, and I imagine that the people who would need this type of feedback the most - people less familiar with openlayers and/or typescript - would miss this.

Well, we check the geometry already anyway, so I created #13298 to warn when a geometry is not a Point.


Support preserveSymlinks from tsconfig.json

Problem

This might be more a feature request then a bug report.

This issue is related to rollup-plugin-dts https://github.com/Swatinem/rollup-plugin-dts/issues/143 which has not been solved.
As described in the issue, the plugin is not able to resolve Vue3 types from PNPM symlinks (default configuration).
As commented https://github.com/Swatinem/rollup-plugin-dts/issues/143#issuecomment-1036050903, the issue has not been fixed/solved, because it can be overcome setting preserveSymlinks: false, you have 3 options.
Workaround using tsconfig.json:
"compilerOptions": {
  "preserveSymlinks": false
}

Workaround using rollup.config plugins:
import dts from 'rollup-plugin-dts'
// rollup.config.ts
plugins: [
  dts({
   compilerOptions: {
      preserveSymlinks: false
    }
  })
]

Another workaround is using shamefully-hoist in .npmrc.
ignore-workspace-root-check=true
shamefully-hoist=true
node-linker=hoisted

Workarounds:

The tsconfig.json workaround does not work, because pkgroll does not care about preserveSymlinks.
The rollup.config workaround can't be used, because you can't configure rollup plugins with pkgroll.
The .npmrc workaround is really annoying because it actually disables all pnpm benefits.

Build-Error:
packages/vue build$ pkgroll --clean-dist --target=es2020 --minify
packages/vue build: src/index.ts(2,10): error TS2305: Module '"vue"' has no exported member 'defineComponent'.
packages/vue build: src/index.ts(2,27): error TS2305: Module '"vue"' has no exported member 'h'.
packages/vue build: src/index.ts(8,9): error TS7006: Parameter 'props' implicitly has an 'any' type.
packages/vue build: Error [RollupError]: [plugin dts] src/index.ts: Failed to compile. Check the logs above.
packages/vue build:     at getRollupError (/home/dev/typescript-dev/begin/pkgroll-issue/node_modules/.pnpm/rollup@4.18.0/node_modules/rollup/dist/shared/parseAst.js:282:41)
packages/vue build:     at Object.error (/home/dev/typescript-dev/begin/pkgroll-issue/node_modules/.pnpm/rollup@4.18.0/node_modules/rollup/dist/shared/parseAst.js:278:42)
packages/vue build:     at Object.error (/home/dev/typescript-dev/begin/pkgroll-issue/node_modules/.pnpm/rollup@4.18.0/node_modules/rollup/dist/shared/rollup.js:804:32)
packages/vue build:     at Object.error (/home/dev/typescript-dev/begin/pkgroll-issue/node_modules/.pnpm/rollup@4.18.0/node_modules/rollup/dist/shared/rollup.js:19790:42)
packages/vue build:     at generateDtsFromTs (/home/dev/typescript-dev/begin/pkgroll-issue/node_modules/.pnpm/pkgroll@2.1.1_typescript@5.5.2/node_modules/pkgroll/dist/rollup-plugin-dts-BzOer96X.js:30:1744)
packages/vue build:     at Object.transform (/home/dev/typescript-dev/begin/pkgroll-issue/node_modules/.pnpm/pkgroll@2.1.1_typescript@5.5.2/node_modules/pkgroll/dist/rollup-plugin-dts-BzOer96X.js:30:1852)
packages/vue build:     at /home/dev/typescript-dev/begin/pkgroll-issue/node_modules/.pnpm/rollup@4.18.0/node_modules/rollup/dist/shared/rollup.js:989:40 {
packages/vue build:   id: '/home/dev/typescript-dev/begin/pkgroll-issue/packages/vue/src/index.ts',
packages/vue build:   hook: 'transform',
packages/vue build:   code: 'PLUGIN_ERROR',
packages/vue build:   plugin: 'dts',
packages/vue build:   watchFiles: [
packages/vue build:     '/home/dev/typescript-dev/begin/pkgroll-issue/packages/vue/src/index.ts'
packages/vue build:   ],
packages/vue build:   [Symbol(augmented)]: true
packages/vue build: }
packages/vue build: Failed
/home/dev/typescript-dev/begin/pkgroll-issue/packages/vue:
 ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL<EMAIL_ADDRESS>build: `pkgroll --clean-dist --target=es2020 --minify`
Exit status 1
 ELIFECYCLE  Command failed with exit code 1.

Expected behavior
I expect pkgroll to pick-up compilerOptions.preserveSymlinks from tsconfig.json, to resolve the issue, but it doesn't.
Possible solutions
For testing I edited node_modules/pkgroll/dist/cli.js line 37 compilerOptions:{composite:!1,preserveSymlinks:!1}. This solves the issue.
<EMAIL_ADDRESS>So a solution would be to check for and add preserveSymlinks here:
https://github.com/privatenumber/pkgroll/blob/46c38750a44992f9977471819f4bfa0ef2039639/src/utils/get-rollup-configs.ts#L66C6-L66C21
Minimal reproduction URL
https://github.com/jrson83/pkgroll-issue
Version
v2.1.1
Node.js version
v21.7.2
Package manager
pnpm
Operating system
Linux
Bugs are expected to be fixed by those affected by it

[X] I'm interested in working on this issue

Compensating engineering work financially will speed up resolution

[ ] I'm willing to offer financial support

Are there any side effects to enabling preserveSymlinks all the time? If not, we can add it like we did with composite.

I did some more research and found more issues in several repositories on this apparently very complex topic.
This PR is very helpful, in addition this very precise explanation of the problem and the solution:

https://github.com/developit/microbundle/pull/967
https://github.com/ezolenko/rollup-plugin-typescript2/issues/234#issuecomment-1139202740

Quote:

false is actually the default of resolve, Rollup itself, TS itself, which all reflect how Node itself treats symlinks (i.e. require.resolve).

If not, we can add it like we did with composite.

This would be a solution that unbuild has also implemented with this PR:

https://github.com/unjs/unbuild/pull/57

Another thing we could try is following this PR (and also several rollup/esbuild related plugins):

https://github.com/ezolenko/rollup-plugin-typescript2/pull/332

The solution here is linked in the source code:
https://github.com/microsoft/TypeScript/blob/c219989232a9db9fb6a5057dd34e21acc628a3b1/src/compiler/sys.ts#L1488
We could try here:
https://github.com/privatenumber/pkgroll/blob/46c38750a44992f9977471819f4bfa0ef2039639/src/utils/get-rollup-configs.ts#L188-L189
@privatenumber maybe we could create a small test which fails the current issue, in order to try if implementing the condition solves the problem. This sounds like a cleaner solution to me.
If it is to complex we could just go with default value false.

:tada: This issue has been resolved in version 2.4.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


clj-kondo: 2024.09.27 -> 2024.11.14

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/clj-kondo/clj-kondo/releases.
meta.description for clj-kondo is: Linter for Clojure code that sparks joy
meta.homepage for clj-kondo is: https://github.com/clj-kondo/clj-kondo
meta.changelog for clj-kondo is: https://github.com/clj-kondo/clj-kondo/blob/v2024.11.14/CHANGELOG.md
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2024.11.14 with grep in /nix/store/97zjm6za9knr2ysx3smzw41xy9n8l37n-clj-kondo-2024.11.14
found 2024.11.14 in filename of file in /nix/store/97zjm6za9knr2ysx3smzw41xy9n8l37n-clj-kondo-2024.11.14

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

6 total rebuild path(s)

6 package rebuild(s)

First fifty rebuilds by attrpath

clj-kondo
tests.writers.bin.babashka
tests.writers.simple.babashka
tests.writers.wrapping.babashka
tests.writers.wrapping.babashka-bin

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/97zjm6za9knr2ysx3smzw41xy9n8l37n-clj-kondo-2024.11.14 \
  --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 clj-kondo https://github.com/r-ryantm/nixpkgs/archive/50bd7379bec1ef17135325712247d9c130a4fc00.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/50bd7379bec1ef17135325712247d9c130a4fc00#clj-kondo

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/97zjm6za9knr2ysx3smzw41xy9n8l37n-clj-kondo-2024.11.14
ls -la /nix/store/97zjm6za9knr2ysx3smzw41xy9n8l37n-clj-kondo-2024.11.14/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.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 1 package built:

clj-kondo

Maintainer pings
cc @jlesquembre @bennyandresen for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


Is there a way to modify the virtualenv's directory?

Consistently creates new virtualenv's at ~/.virtualenvs/.
Is there a way to modify this? Is ~/.virtualenvs/ best practice for some reason? Sorry for the stupid question -- newish the Python.

@corysimmons: http://virtualfish.readthedocs.io/en/latest/usage.html#configuration-variables
Totally understand and respect that you are new(ish) to Python, but please be sure to read the docs thoroughly before filing issues. Thanks!  (^_^)

Ahh, I'm sorry. That was an obvious one.
Thanks for your help though!


Is there a binary version available in the AUR?

It kinda takes forever to build a browser in my PC and I was wondering if there was a binary version available in the AUR?
If so what would be the package name?

See https://github.com/ungoogled-software/ungoogled-chromium-archlinux/issues/143, the code is technically there but I still require feedback from Eloston on some internal things before that can get pushed

I hope to see it soon then mate =D


#85 Fixed, no crop webview now, and added progressbar while loading webview

1- removed the margin from the dialog.
2- Navigation bar height is considered while making the dialog full screen, so content does not crop.
3- added a progress bar while page is loading.
4- progress bar hide when page loading is completed.

awesome!! was thinking about this.


failed build

Output of the info page (if this is a bug)
--- Setting rtloader paths to lib:/root/datadog-agent/dev/lib | header:/root/datadog-agent/dev/include | common headers:
# github.com/DataDog/datadog-agent/pkg/secrets
pkg/secrets/check_rights_nix.go:68:32: undefined: syscall.S_IWGRP
pkg/secrets/check_rights_nix.go:86:17: undefined: syscall.S_IXGRP

Describe what happened:
cannot build an agent as it checks for the value that is defined inside a UNIX system as default:
Freebsd/stat.h (https://github.com/freebsd/freebsd-src/blob/master/sys/sys/stat.h#L261)
Looks like a problem is in GO syscall https://github.com/DataDog/datadog-agent/blob/main/pkg/secrets/check_rights_nix.go#L68
Describe what you expected:
agent is built
Steps to reproduce the issue:
follow build process from readme: invoke agent.build --build-exclude=systemd
Additional environment details (Operating System, Cloud provider, etc):
FreeBSD13.0, go 1.17

Hi @spagu, while we currently don't provide official support for FreeBSD or other BSDs, we are happy to accept PRs to make it buildable and/or fix any issues.
In this case, I would try first to build without secrets support, as in
invoke agent.build --build-exclude=secrets,systemd

since the offending file has the secrets build tag. If that doesn't work (e.g. you find more issues), feel free to comment again so that we can continue helping you.

Running into this in 2024, @mx-psi what is the official stance of the DD agent on FreeBSD? I can take a look at fixing the build issues for FreeBSD as it's a blocker for using this in OTel on FreeBSD (since the datadog exporter/receiver call into this library).

@polyrain I think https://github.com/DataDog/datadog-agent/issues/11340#issuecomment-1073640872 still stands (we will accept PRs that make it buildable, with no guarantees that we will actively test this), but I am not on the team that would officially approve this, so I think the best we can do is that if you open a PR (start small!) I can sort it out internally to get the right people to look into it.

using this in OTel on FreeBSD

About this, I assume you are talking about the Collector. If so, if you want to collaborate on this I am happy to help guide you through the process (I am a Collector maintainer and have experience with this specifically with s390x and Plan 9 support). We could also make some sort of guide/blog post on opentelemetry.io about what adding support for this entailed :) Feel free to contact me on the CNCF Slack or via email.


Strange NoSuchMethodError when using 2.2.0

I've been trying to upgrade from 2.1.0 to 2.2.0 and now I have a few tests that fail with this exception:
java.lang.NoSuchMethodError: com.nhaarman.mockitokotlin2.MockingKt.withSettings([Lkotlin/reflect/KClass;Ljava/lang/String;Ljava/lang/Object;Lorg/mockito/stubbing/Answer;ZLorg/mockito/mock/SerializableMode;Z[Lorg/mockito/listeners/InvocationListener;ZLcom/nhaarman/mockitokotlin2/UseConstructor;Ljava/lang/Object;Z)Lorg/mockito/MockSettings;

	at com.qonto.qonto.ui.otp.setup.phonenumber.PhoneNumberPresenterTest.<init>(PhoneNumberPresenterTest.kt:180)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:217)
	at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:266)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:263)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)

This is on a test that does something like this:
    private val otpViewModel = mock<OTPSetupViewModel> {
        on { mustSwitchOtpFromAppToSms() } itAnswers { mustSwitchOtpFromAppToSms }
        on { createMfaBySms() } itAnswers { createMfaBySmsResponse }
        on { showError } itAnswers { showErrorLiveData }
    }

Any idea?

@BoD There's no itAnswers method in Mockito-kotlin.

Oh you're right, this is from Kluent actually...  But still this only happens when updating the version of mockito-kotlin.  Do you have an idea of what could be the issue, or should I try to open an issue on the Kluent project? 😊

I would check my imports. I don't know Kluent, but my guess is that on might be the from Mockito-kotlin, where it probably should have used one from Kluent?

So I checked and there is no on in Kluent - but if I use doAnswer from mockito-kotlin, I still have the same error.
Here's my imports:
import com.nhaarman.mockitokotlin2.doAnswer
import com.nhaarman.mockitokotlin2.eq
import com.nhaarman.mockitokotlin2.mock
import com.nhaarman.mockitokotlin2.never
import com.nhaarman.mockitokotlin2.timeout
import com.nhaarman.mockitokotlin2.verify
(other imports omitted but nothing from Kluent anymore)

and the modified version:
    private val otpViewModel = mock<OTPSetupViewModel> {
        on { mustSwitchOtpFromAppToSms() } doAnswer { mustSwitchOtpFromAppToSms }
        on { createMfaBySms() } doAnswer { createMfaBySmsResponse }
        on { showError } doAnswer { showErrorLiveData }
    }

Any idea what could be wrong?

Oh I have more info: I also upgraded org.mockito:mockito-core from 3.0.0 to 3.1.0.  If I revert to 3.0.0 I no longer have this issue.  That makes sense?

Makes sense, as Mockito-kotlin internally relies on mockito. There's probably a breaking change in Mockito.

All right thank you. I just looked and I notice Mockito-kotlin depends on a fairly old version of org.mockito:mockito-core (2.23.0).  I guess it would be cool to upgrade that.  In the meantime I think on my side I'll stay with mockito-kotlin 2.1.0.
Thanks!

So if I understand correctly mockito-kotlin 2.2.0 works fine with Mockito 3.0.0 but not with Mockito 3.1.0, correct?

That's correct.

@BoD Could you post a bit more of the test code? Can't reproduce the issue with upgraded mockito-core dependency.

I had the same issue and we also use Kluent. In this Test it turned out we used the mock method from Kluent instead of mockitotokotlin and with that we got:
java.lang.NoSuchMethodError: com.nhaarman.mockitokotlin2.MockingKt.withSettings([Lkotlin/reflect/KClass;Ljava/lang/String;Ljava/lang/Object;Lorg/mockito/stubbing/Answer;ZLorg/mockito/mock/SerializableMode;Z[Lorg/mockito/listeners/InvocationListener;ZLcom/nhaarman/mockitokotlin2/UseConstructor;Ljava/lang/Object;)Lorg/mockito/MockSettings;
After changing from import org.amshove.kluent.mock to import com.nhaarman.mockitokotlin2.mock
the test works fine.

Sorry to reply so late.  I can confirm that we do use the mock method from mockitokotlin and have the issue so that's not the culprit.
If a new version of mockito-kotlin with an up-to-date version of the dependency to mockito could be released, I can easily see if that resolves the issue.  Plus I guess it's generally a good idea to be up to date ;)

It's been several years :) Would it be possible to try to make mockito-kotlin depend on a recent version of mockito?
Currently it depends on 2.23.0 from Oct 2018, while the he latest is 3.8.0 from Feb 2021.

See #408 as well for updated dependencies.


1 epoch

Is it meant to be only one epoch in training?
Your config files state 1 epoch, is that just as quick example?
I tried to train PADIM for 10 on mvtec leather and wood and the metrics stay the same anyway, so it seems nothing as gained by training more.
Lightning module also warn that there is no optimizer so I guess train only finds the correct thresholds and that takes 1 epoch.

Hi @sequoiagrove, PADIM algorithm doesn't require any CNN-based learning. It rather uses the CNN to extract the features of the training set, which is then used to fit a multivariate gaussian model. We therefore use 1 epoch to go through the entire training set and extract the features.

For the warning that there is no optimiser is also related to the above statement. Since we use the CNN only to extract the features, there is no optimiser set for the CNN training.

that's what I thought.
to make the infrence work I had to  copy paste some code snippets from your differnt branches to get a displayable heatmap that makes sense.
One issue is that there is not "stats" and thresholds in meta_data, only the image size, so I changed it to return the anomaly map unaltered :  output ,score= inference.predict(image=args.image_path, superimpose=False)
and the inference.py takes  anomaly_map, image_score . then I normalize it myself i = (i-min) / (max-min) . Looking good.
I tried training my own example with only good samples. It highlighted most my flaws, except some very small subtle changes.
is that expected outcome and will it be better at finding small anomalies if I provide annotated anomaly images in training? or do I need to choose one of the other models for such challenges?
Nevertheless, Impressive work :)

One issue is that there is not "stats" and thresholds in meta_data, only the image size, so I changed it to return the anomaly map unaltered : output ,score= inference.predict(image=args.image_path, superimpose=False)
and the inference.py takes anomaly_map, image_score . then I normalize it myself i = (i-min) / (max-min) . Looking good.
I tried training my own example with only good samples. It highlighted most my flaws, except some very small subtle changes.

This is a PR we just merged this morning, and haven't thoroughly tested yet. Maybe @ashwinvaidya17 could provide a better insight here.

is that expected outcome and will it be better at finding small anomalies if I provide annotated anomaly images in training? or do I need to choose one of the other models for such challenges?

The models don't use annotated images, so adding them wouldn't help. To find the small anomalies, you could either increase the image size or configure tiling from the config file. This is mainly because when a large image is resized into 256x256, detecting small anomalies becomes even smaller and detecting them becomes almost impossible. Using larger input or tiled input image could provide better performance.
In addition, our hyper-parameter optimisation tool will soon become publicly available so that parameter tuning could also be done to find the best parametrisation for custom datasets.

ah ok , I checked out this friday. Now I re-checked out and now I get good maps out of the box, as long I reverted lightning back to 1.3.6 , put number of workers down to a reasonable amount, and add cv2.waitKey() after imshow.

Yeah, there is a PR that bumps up the lightning version to 1.6.0dev, but there are some breaking changes, and might take some time to merge this.
Good catch for cv2.waitKey(), we'll add it asap

Also found that line 149 in torch.py (inferencer) has to be 👍
anomaly_map = anomaly_map.detach().numpy()
in order to run stfpm models.
and patchcore cannot train at the moment due to datatypes:
| Name                  | Type                     | Params
0 | image_threshold       | AdaptiveThreshold        | 0
1 | pixel_threshold       | AdaptiveThreshold        | 0
2 | training_distribution | AnomalyScoreDistribution | 0
3 | min_max               | MinMax                   | 0
4 | image_metrics         | MetricCollection         | 0
5 | pixel_metrics         | MetricCollection         | 0
6 | model                 | PatchcoreModel           | 68.9 M
68.9 M    Trainable params
0         Non-trainable params
68.9 M    Total params
275.533   Total estimated model params size (MB)
Epoch 0:   6%|███████████▌                                                                                | 8/132 [00:26<06:56,  3.36s/it]Traceback (most recent call last):
File "tools\train.py", line 66, in
train()
File "tools\train.py", line 61, in train
trainer.fit(model=model, datamodule=datamodule)
File "C:\Anaconda3\envs\anomalib_env\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 458, in fit
self._run(model)
File "C:\Anaconda3\envs\anomalib_env\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 756, in _run
self.dispatch()
File "C:\Anaconda3\envs\anomalib_env\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 797, in dispatch
self.accelerator.start_training(self)
File "C:\Anaconda3\envs\anomalib_env\lib\site-packages\pytorch_lightning\accelerators\accelerator.py", line 96, in start_training
self.training_type_plugin.start_training(trainer)
File "C:\Anaconda3\envs\anomalib_env\lib\site-packages\pytorch_lightning\plugins\training_type\training_type_plugin.py", line 144, in start_training
self._results = trainer.run_stage()
File "C:\Anaconda3\envs\anomalib_env\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 807, in run_stage
return self.run_train()
File "C:\Anaconda3\envs\anomalib_env\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 869, in run_train
self.train_loop.run_training_epoch()
File "C:\Anaconda3\envs\anomalib_env\lib\site-packages\pytorch_lightning\trainer\training_loop.py", line 566, in run_training_epoch
self.on_train_epoch_end(epoch_output)
File "C:\Anaconda3\envs\anomalib_env\lib\site-packages\pytorch_lightning\trainer\training_loop.py", line 606, in on_train_epoch_end
training_epoch_end_output = model.training_epoch_end(processed_epoch_output)
File "d:\projects\anomalib\anomalib\models\patchcore\model.py", line 297, in training_epoch_end
embedding = self.model.subsample_embedding(embedding, sampling_ratio)
File "d:\projects\anomalib\anomalib\models\patchcore\model.py", line 229, in subsample_embedding
random_projector.fit(embedding)
File "d:\projects\anomalib\anomalib\models\patchcore\utils\sampling\random_projection.py", line 124, in fit
self.sparse_random_matrix = self._sparse_random_matrix(n_features=n_features).to(device)
File "d:\projects\anomalib\anomalib\models\patchcore\utils\sampling\random_projection.py", line 85, in _sparse_random_matrix
components[i, c_idx] = data.double()
IndexError: tensors used as indices must be long, byte or bool tensors

Thanks for reporting these!

could it be confudsion between torch install that happened when I struggled to enable my GPU?
form conda list:
pytorch                   1.10.1          py3.8_cuda11.3_cudnn8_0    pytorch
pytorch-lightning         1.3.6                    pypi_0    pypi
torch                     1.8.1                    pypi_0    pypi
torch-metrics             1.1.7                    pypi_0    pypi
torchaudio                0.10.1               py38_cu113    pytorch
torchmetrics              0.6.2                    pypi_0    pypi
torchvision               0.9.1                    pypi_0    pypi

fixed it:
in patchcore/utils/random projections.py line 79-83:
c_idx = torch.tensor(
sample_without_replacement(
n_population=n_features, n_samples=nnz_idx, random_state=self.random_state
),dtype=torch.long
)

patchcore inference:
File "d:\projects\anomalib\anomalib\utils\normalization\min_max.py", line 31, in normalize
normalized = ((targets - threshold) / (max_val - min_val)) + 0.5
TypeError: unsupported operand type(s) for -: 'numpy.ndarray' and 'Tensor'
mixed datatypes.

Found the issue. I prnted the data types trough out the inference. in model.py score and map is tensor all the way, it is in the deploy/torch.py you ask "isinstance(map, tensor)" . andboth of them are, but it is false because it is two tensors, not just one. and the code for false is to convert pred_score to numpy. but anomaly_map is assumed to be numpy already. the metadata is still tensors so I cant just also convert the map to numpy.
if I just don't convert the score it works, but I guess that breaks some of the other models.
so we need to handle the special case of getting two tensors.

this works for all three models I trained padim, patchcore and stfpm:
    if isinstance(predictions, Tensor):
        anomaly_map = predictions
        pred_score = anomaly_map.reshape(-1).max()
    else:
        if isinstance(predictions[1],( Tensor)):
            anomaly_map, pred_score = predictions
            pred_score = pred_score.detach()
        else:
            anomaly_map, pred_score = predictions
            pred_score = pred_score.detach().numpy()

@sequoiagrove It is possible that some metrics might have diverged from when we collected the results. There is a plan to re-evaluate all the algorithms. Also, a benchmarking script is in PR state which will help gather results but merging this is pushed back before a refactor we are planning. Here is a tip, if you want to log anomaly images, you can modify log_images to log_images_to: [local]. It will save the results in the results folder after training completion.

diverged metrics: dropping from 0.99 to 0.44 and 0.03 is rather critical?
log images: nice :)
Also padim dropped in performance, but not as crazy.
Here's a patchcore result of "good" parts:

this is padim:
DATALOADER:0 TEST RESULTS
{'image_AUROC': 0.7589669823646545,
'image_F1': 0.8787878751754761,
'pixel_AUROC': 0.9781586527824402,
'pixel_F1': 0.22379672527313232}

I tried this other patchcore repo  [ https://github.com/hcw-00/PatchCore_anomaly_detection ]on mvtec/screws and it gives me:
{'img_auc': 0.5911047345767575, 'pixel_auc': 0.9048583939897462}
and rather random anomaly maps as well..

Thanks for reporting this discrepancy @sequoiagrove. We'll investigate the benchmarks


Make buf and str modules public

Commit ac427665353318bd54b61afc2de6dbb1df9f312e seems to have broken part of the documentation. Right now there is no way to access the docs of any of the structs in the buf and str modules. Making those modules public fixes this.
(It's entirely possible that there is a better way to fix the docs, but rustdocs confuses me).

This seems like a rustdoc bug. I am talking w/ @alexcrichton about it.

I filed an issue: https://github.com/rust-lang/rust/issues/24296
I'm not sure if we should fix in the mean time...

I'm not sure either. I guess that depends on when you think this will be fixed.
I've been trying to find a workaround, but I haven't found one that works yet. I'll try to make some time this weekend to look into this issue, but I'm not very optimistic.

well, a large PR w/ many rustdoc fixes landed recently, so maybe let's wait to see if it handles the issue?

Looks like that didn't help :-/

Closing this for now. Hopefully rustdoc will get a fix one  day :(


OpenAPI docs show body params as query params

Describe the bug

This should show as a body parameter for a POST endpoint with a Pydantic model parameter, e.g.:
@app.post('/test')
async def test(
    input: MyModel
):
    ...

Expected behavior
Should be shown as a body parameter.

Closing as it appears to be a FastAPI issue with a discussion here: https://github.com/tiangolo/fastapi/discussions/11472


Added a velocity shutdown failsafe.

This commit adds a fixed timeout to velocity commands that causes the vehicle to stop moving if no command is specified within a given time window.
This mirrors the failsafe velocity shutdown that is provided on the Arduino controller, which shuts down if the board is disconnected.

@christomaszewski can you test if this PR shuts down the boat with the following test:

Start up the boat and connect to it from the tablet through an airgateway.
Teleop the boat up to speed using the teleop panel.
Turn off the airgateway by pulling its power cord.

The boat should stop moving within a second.

We tested this in the office and it seems to work without the issues we noticed on the lake. Velocity shutdown works. Can we use a similar mechanism to go home after a longer timeout?

Yeah, I think we can make this the basis for the failsafe check as well. Merging.


Mac mac_host_engine flakey on clang crash

The Mac mac_host_engine is flaking on a clang frontend crash.  It's happened 2/10 last invocations.
Is this related to the GOMA migration?  I don't think this is probably a problem we've created for ourselves but is some infra issue related to our clang version.
cc @jmagman
example
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac mac_host_engine/8228/overview
error text
FAILED: obj/third_party/vulkan-deps/spirv-tools/src/source/opt/libspvtools_opt.value_number_table.o
../../buildtools/mac-x64/clang/bin/clang++ -MD -MF obj/third_party/vulkan-deps/spirv-tools/src/source/opt/libspvtools_opt.value_number_table.o.d -DUSE_OPENSSL=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D_LIBCPP_DISABLE_AVAILABILITY=1 -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../.. -Igen -I../../third_party/libcxx/include -I../../third_party/libcxxabi/include -I../../flutter/build/secondary/third_party/libcxx/config -I../../third_party/vulkan-deps/spirv-tools/src -I../../third_party/vulkan-deps/spirv-headers/src/include -I../../third_party/vulkan-deps/spirv-tools/src/include -Igen/third_party/vulkan-deps/spirv-tools/src -isysroot /Volumes/Work/s/w/ir/cache/osx_sdk/xcode_14e300c/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -mmacosx-version-min=10.14.0 -fno-strict-aliasing -fstack-protector-all -arch x86_64 -fcolor-diagnostics -Wall -Wextra -Wendif-labels -Werror -Wno-missing-field-initializers -Wno-unused-parameter -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-implicit-int-float-conversion -Wno-deprecated-copy -Wno-psabi -Wno-deprecated-literal-operator -Wno-unqualified-std-cast-call -Wno-non-c-typedef-for-linkage -Wno-range-loop-construct -Wunguarded-availability -Wno-deprecated-declarations -fvisibility=hidden -Wstring-conversion -Wnewline-eof -O2 -fno-ident -fdata-sections -ffunction-sections -g2 -Wno-implicit-fallthrough -Wno-newline-eof -Wno-unreachable-code-break -Wno-unreachable-code-return -std=c++17 -fvisibility-inlines-hidden -std=c++17 -fno-rtti -nostdinc++ -nostdinc++ -fvisibility=hidden -fno-exceptions -stdlib=libc++  -c ../../third_party/vulkan-deps/spirv-tools/src/source/opt/value_number_table.cpp -o obj/third_party/vulkan-deps/spirv-tools/src/source/opt/libspvtools_opt.value_number_table.o
clang++: error: clang frontend command failed with exit code 139 (use -v to see invocation)
Fuchsia clang version 18.0.0 (https://llvm.googlesource.com/llvm-project 725656bdd885483c39f482a01ea25d67acf39c46)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Volumes/Work/s/w/ir/cache/builder/src/out/host_release/../../buildtools/mac-x64/clang/bin
clang++: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: /Volumes/Work/s/w/ir/x/t/value_number_table-bbb3c5.cpp
clang++: note: diagnostic msg: /Volumes/Work/s/w/ir/x/t/value_number_table-bbb3c5.sh
clang++: note: diagnostic msg: Crash backtrace is located in
clang++: note: diagnostic msg: /Users/chrome-bot/Library/Logs/DiagnosticReports/llvm_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang++: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
clang++: note: diagnostic msg:

********************

https://github.com/flutter/engine/pull/49248 landed yesterday.  I'm not sure if that has addressed the issue though.

Routing to team-infra since we won't be able to file an issue with the toolchain team without the crash dump and reduced repro mentioned in the error message. Assigning to @keyonghan since he was looking into this yesterday.

I will try adding some recipes logics to collect the crash repro files, and with that we can follow up with toolchain team.

https://flutter-review.googlesource.com/c/recipes/+/53421 to collect the dump files when crash happens.

Un-assigning myself considering the infra support is available.

https://flutter-review.googlesource.com/c/recipes/+/55320 to collect clang crash dump for rbe builds.

Engine tree is red on a new flake: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac Production Engine Drone/311038/infra, with crash dump files attached.

Thanks! Would it be possible to include this file mentioned in the logs as well?
clang++: note: diagnostic msg: /Users/chrome-bot/Library/Logs/DiagnosticReports/llvm_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang++: note: diagnostic msg: (choose the .crash file that corresponds to your crash)

Unfortunately, I think the crash might be flaky. I've downloaded the reproducer and the driver script, but it doesn't crash when I run it locally. I have it executing in a tight loop now, and hopefully it will crash at some point.

Yeah, I can do that. Will update here when ready. Assigning to myself for the infra support.

Bumping the priority as it flaked >15 times in recent 100 runs: https://ci.chromium.org/ui/p/flutter/builders/luci.flutter.prod/Mac mac_host_engine?limit=100

All crashes have been happening only on build797-m9 and not crashing on the other x86 bots, so it seems like this is an issue with that particular bot.

I just saw this show up on build804-m9 ( https://ci.chromium.org/ui/p/flutter/builders/prod/Mac Production Engine Drone/332573/overview )

Closing this a superseded by https://github.com/flutter/flutter/issues/147191


gherkin/parser seems to be missing

Summary

It looks like the gherkin parser was moved from a standalone gem to something in cucumber mono repo but looks like something may not have been updated properly.
/home/travis/.rvm/gems/ruby-2.3.7/gems/cucumber-core-3.2.0/lib/cucumber/core/gherkin/parser.rb:2:in `require': cannot load such file -- gherkin/parser (LoadError)
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/cucumber-core-3.2.0/lib/cucumber/core/gherkin/parser.rb:2:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/cucumber-core-3.2.0/lib/cucumber/core.rb:3:in `require'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/cucumber-core-3.2.0/lib/cucumber/core.rb:3:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/foodcritic-7.1.0/lib/foodcritic.rb:2:in `require'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/foodcritic-7.1.0/lib/foodcritic.rb:2:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/foodcritic-7.1.0/bin/foodcritic:2:in `require_relative'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/foodcritic-7.1.0/bin/foodcritic:2:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.3.7/bin/foodcritic:23:in `load'
	from /home/travis/.rvm/gems/ruby-2.3.7/bin/foodcritic:23:in `<main>'
	from /home/travis/.rvm/gems/ruby-2.3.7/bin/ruby_executable_hooks:24:in `eval'
	from /home/travis/.rvm/gems/ruby-2.3.7/bin/ruby_executable_hooks:24:in `<main>'

Expected Behavior
Run without failure
Current Behavior

/home/travis/.rvm/gems/ruby-2.3.7/gems/cucumber-core-3.2.0/lib/cucumber/core/gherkin/parser.rb:2:in `require': cannot load such file -- gherkin/parser (LoadError)
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/cucumber-core-3.2.0/lib/cucumber/core/gherkin/parser.rb:2:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/cucumber-core-3.2.0/lib/cucumber/core.rb:3:in `require'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/cucumber-core-3.2.0/lib/cucumber/core.rb:3:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/foodcritic-7.1.0/lib/foodcritic.rb:2:in `require'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/foodcritic-7.1.0/lib/foodcritic.rb:2:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/foodcritic-7.1.0/bin/foodcritic:2:in `require_relative'
	from /home/travis/.rvm/gems/ruby-2.3.7/gems/foodcritic-7.1.0/bin/foodcritic:2:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.3.7/bin/foodcritic:23:in `load'
	from /home/travis/.rvm/gems/ruby-2.3.7/bin/foodcritic:23:in `<main>'
	from /home/travis/.rvm/gems/ruby-2.3.7/bin/ruby_executable_hooks:24:in `eval'
	from /home/travis/.rvm/gems/ruby-2.3.7/bin/ruby_executable_hooks:24:in `<main>'

It fails to find the library/file.
Possible Solution

Temp work around add ~> 5.1 to your Gemfile or gemspec while waiting for a fix.
Steps to Reproduce (for bugs)
I experienced this issue with running foodcritic
Your Environment

Version used: 3.2.0
Operating System and version: travis (trusty I think)
Link to your project: unfortunately the project I discovered this in is private but here is a link to foodcritic: https://github.com/Foodcritic/foodcritic

Looks like it was pulled in from here: https://github.com/Foodcritic/foodcritic/blob/v14.1.0/foodcritic.gemspec#L22 will open an issue on that repo

We can probably trace it, I don't have the time right now but maybe a little later this evening I will: https://rubygems.org/gems/gherkin/reverse_dependencies

According to https://rubygems.org/gems/cucumber-core/versions/3.2.0 its pulling in >= 5.0.0 not ~> 5.1.0

So the released gem specifies it as :point_up: https://github.com/cucumber/cucumber-ruby-core/blob/v3.2.0/cucumber-core.gemspec#L17 but the master has it pessemistically pinned. I can put together a PR to pin it, wait to have it released, then we should be able to release a v4 that pulls in the new dependency as ~> 6.0 as that is a breaking change.

Upgrading to v6 is underway btw: https://github.com/cucumber/cucumber-ruby/pull/1313

Given a few people have experienced this today, and there's likely to be more over the coming days, I've released v3.2.1 (with just the pessimistic version change). :)


custom tag in rg-modal is not evaluated

Hi,
thanks for your great library.
While playing around I found a possible bug: If the content of a button is set to an html string which contains a riot tag, the tag is not evaluated correctly. I get the custom tag inside the button, but its html is empty.
Any help is appreciated, thanks.

Right that's a scenario I never thought about! I think I could wrap a riot compile in the rg-raw tag to fix this. It would also fix it in other content: "" instances...watch this space

Actually I think we'll need to wait until v2.4.0 of Riot is released to make use of the additional compiler APIs

Does this work now?
Example:
https://plnkr.co/edit/35HE8BJtzfEdp5b42vtX?p=preview


Remove telemetry except of messages, which may indicate a bug in our code

Closes https://github.com/getappmap/appmap-intellij-plugin/issues/424
Closes https://github.com/getappmap/appmap-intellij-plugin/issues/398
This PR removes most of the telemetry message. Please refer to this comment for a list of the removed messages.

There are no tests for the remaining messages:

run_config:incompatible_jdk
authentication:failed
open_api:failure

An incompatible JDK setup can't be tested well. Testing the remaining two messages would require a mock OAuth server setup and a mocked AppMap CLI, which would take considerable time. Could you please open a new issue if you'd like tests?


screen offset issue when zooming in/out and multiple node dimensions being updated simultaneously, using (v11 & v12)

Describe the Bug
In screenshot attached below, notice the background ends (and the bottom-left panel is not at bottom left), as the graph has shifted up significantly. In this state, you can't drag the background & can sometimes get stuck with actions not responding.
It is possible to shift it back by (a) scrolling out all the way on the graph or (b) pressing the fullscreen button on the bottom-left panel.

Bug appears on v11 and v12
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue
hard to reproduce, but happens when modifying the dimensions of a node (in an uncontrolled fashion, using custom node) and updating.
question: is there some width/height for the node that i should be sure to update, when updating a node's dimensions in uncontrolled way?
Expected behavior
Expected no layout shifts; layout shifts seem to happen when scrolling while a node dimensions are changing in an uncontrolled way
Screenshots or Videos
No response
Platform
OS: macOS
Browser: Arc/Chrome
React flow version 11 and version 12.
Additional context
No response

looks like a weird bug 🧐 If you find a way to repro it, please let us know.
If you want to set a specific width/height for a node, you should use node.style.

Hey, we have the same behaviour..
We have initial screen with few initial nodes and edges, then we have dynamically added nodes and edges when a user zooming in. So when you select and then unselect dynamically added edge, layout(react-flow__renderer element) moves up. Also, if you drag layout after unselect edge, the layout is also moving up and down depending on your drags.
We're using Reactlow version 11.10.3.

---- Hacky solution ---
We've found that when we add position: fixed!important to the react-flow__renderer  element, this behaviour is eliminated.

Similarly to someone else, I'm noticing that adding position: fixed!important to the react-flow__renderer element eliminates this behavior (but is hacky as it causes my nodes to appear outside of the previously absolute boundary of the renderer.
Any chance this helps narrow down the issue? @moklick


Use CalledMethodsChecker from CF distribution rather than legacy version

Some of the code (especially to handle exceptional stores) is kind of ugly, but this should work for now. I'll need to make some changes in the CF itself for that to be cleaner, but I wanted to get this working version here so that we can start using it.
Rather than preserving the old CMPredicate evaluation code, I used the default version from the CF. That uses a less-precise subtyping relationship, but we aren't using CMPredicate for MustCall anyway so I didn't think it was important. I can switch it back if a reviewer feels strongly.

Rather than preserving the old CMPredicate evaluation code, I used the default version from the CF. That uses a less-precise subtyping relationship, but we aren't using CMPredicate for MustCall anyway so I didn't think it was important. I can switch it back if a reviewer feels strongly.

This is fine.

Was the idea to keep all the existing test cases even if they are redundant with the called methods checker tests, just to ensure no breakage?

Yes, that was the idea.


Add property "priorityMixPolicy" of VM Scale Set to .NET SDK for Version 2022-08-01

Closed the old PR due to a mistake made when rebasing my local feature branch onto the wrong branch
Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

Hi CPlat SDK team. Just as an FYI: This PR initially had no ci failures as of commit 2a5570a. I then changed a single comment in one of the files (no code changes at all) and the ci failures came up again. Additionally, these ci failures seemingly have nothing to do with my changes. The branch this PR is based off of has the latest changes from the 2022-08-01 branch. I have messaged Theodore on the side about this but wanted to put it out here as well, as I know the .NET SDK merges are taking place soon.


Update README

Description

Update README

Type of change

This change requires a documentation update

Checklist:

[yes] My code follows PEP8 style guide
[yes] I have removed unnecessary print statements from my code
[yes] I have made corresponding changes to the documentation if necessary
[yes] My changes generate no errors
[yup] No commented-out code
[ye] Size of pull request kept to a minimum
[yuppers] Pull request description clearly describes changes made & motivations for said changes

https://trello.com/c/agxeF6Ex/181-documentation-as-a-developer-i-want-to-be-able-to-see-what-the-ds-app-does-so-that-i-can-locally-deploy-and-know-who-built-it

Overall great changes and formatting, I just have the one gripe concerning upper management being cataloged in FT 42. I think listing them with their titles at the top of the list is more applicable, since their roles supersede any single team iteration.

Please kindly check updated Contributors section I added your suggestion


Unpackaged metadata not provided to sfdx build in newest sfpowerscripts version

Describe the bug
Newest sfpowerscripts version gives the following error upon Orchestrator Build: Un-packaged metadata directory unpackagedMetadata was specified but does not exist. I see that support of this option was added as a result of this issue.
To Reproduce
Steps to reproduce the behavior:

Create an Unlocked Package, test-package, under the src directory and add it to the sfdx-project.json and include an Account field, testField__c
Add another directory, src/unpackaged, and add another Account field, testField2__c
Add the unpackagedMetadata option as below:

"unpackagedMetadata": {
    "path":"src/unpackaged"
},

Create a new version of test-package using sfdx sfpowerscripts:orchestrator:build -v devhub --branch master --diffcheck --buildnumber $(Build.BuildId) -f config/project-scratch-def.json & the latest version of sfpowerscripts using container: ghcr.io/dxatscale/sfpowerscripts:latest

Expected behavior
A new package version is successfully created
Actual behavior
sfdx throws the following error:  Un-packaged metadata directory unpackagedMetadata was specified but does not exist.
Screenshots

Platform Details (please complete the following information):

OS: Linux
Version: Ubuntu Latest
Salesforce CLI(sfdx cli) Version:

sfpowerscripts: latest (20.2.11)
sfdx: 7.179.0

CI Platform: Azure DevOps

Additional context
If downgrading to sfpowerscripts version: 19.7.3 using container: ghcr.io/dxatscale/sfpowerscripts:19.7.3-3140166080 then the orchestrator:build works successfully as expected

ixed in Jan23


Import roles from external repos

The top .travis.yml needs to be updated or deleted. A quick update would be to intall ansible galaxy and run ansible-galaxy install -r requirements.yml --roles-path ./roles/ as the first test step, prior to ansible-lint.
Ansible lint doesn't make a whole pile of sense in here, since we'd be coupling the PR/merge tests to external sources of failure.
Running some kind of integration test (e.g. making sure that the installation happens correctly by running the (gated) master branches from the component roles, does have some merit.

The top .travis.yml needs to be updated or deleted. A quick update would be to intall ansible galaxy and run ansible-galaxy install -r requirements.yml --roles-path ./roles/ as the first test step, prior to ansible-lint.

Done.

Ansible lint doesn't make a whole pile of sense in here, since we'd be coupling the PR/merge tests to external sources of failure.

There is still a playbook, so I suppose it still makes sense. We should probably move the lint checks out of this though and into the role repos so that it's caught there.

Running some kind of integration test (e.g. making sure that the installation happens correctly by running the (gated) master branches from the component roles, does have some merit.

Integration test will basically be done here when a change happens, but unfortunately it's harder to result in one github changes triggering tests elsewhere. I think we get some more of that kind of functionality if we use the built in GitHub CI (GitHub Actions) but I don't know enough about it to set it up currently.


Refactor if statements in URL.swift

This is just some light refactoring on URL.swift
It mirrors the changes I made to the swift-corelibs-foundation repo.

@swift-ci Please smoke test

@swift-ci Please smoke test and merge


Update dependencies.

Updating our dependencies.

1.4.5 on 19.3 with Selenium 3 is really... fun and blowing up our tests a lot. Restarted build so hopefully it passes now...

@PragTob I'm working on a custom docker image that will hopefully make these builds more reproducible (and maybe even faster?).

@aaronrenner does this look ok now?

Well then... :shipit:

@keathley About the docker image... before you do that, I'd like to make it so the SeleniumDriver handles starting up and monitoring the selenium server like we do with phantom and chromedriver. Also, once we make it so phantom doesn't start up automatically, we can configure our builds to only install webdriver server (phantom/chrome/selenium) that we need. I know it's annoying right now, but if we can make these changes and get things working reliably, we won't have a docker image to maintain.


Narcolepsy

Narcolepsy MONDO:0021107
Narcolepsy is currently classified into two subtypes  1 and 2 (narcolepsy with cataplexy and narcolepsy without cataplexy respectively)
See MONDO classification  here: https://www.ebi.ac.uk/ols4/ontologies/mondo/classes/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FMONDO_0021107?lang=en
0000-001-9310-0163
Thank you!  Gioconda

Hi @galyea123 can you please clarify what the action item is? Thank you!

Hi!  Narcolepsy with cataplexy is narcolepsy type 1 and Narcolepsy without cataplexy is narcolepsy type 2. (https://www.ninds.nih.gov/health-information/disorders/narcolepsy)
Type 1 narcolepsy (previously known as narcolepsy with cataplexy)—This diagnosis is based on the individual either having low levels of a brain hormone (hypocretin) or reporting cataplexy and having excessive daytime sleepiness on a special nap test.
Type 2 narcolepsy (previously known as narcolepsy without cataplexy)—People with this condition experience excessive daytime sleepiness but usually do not have muscle weakness triggered by emotions. They usually also have less severe symptoms and have normal levels of the brain hormone hypocretin.narcolepsy without cataplexy.
In MONDO narcolepsy is classified as:
narcolepsy without cataplexy
narcolepsy-cataplexy syndrome (3)
narcolepsy 1
narcolepsy 3
narcolepsy 7
In addition to that notice that the Orphanet page for narcolepsy type 1 links to all the OMIM subtypes not only 1, 3 and 7 (this are subtypes that are only based in the specific gene mutation and usually only one or two cases and some only associate with susceptibility or the association is not yet well-defined.
Thank you, Gioconda
I

@sabrinatoro and @galyea123 - could you please review this and see if you agree:

Hi Sabrina!  I think it should follow the current classification. Narcolepsy is currently subdivided into two types according to the International Classification of Sleep Disorders, 3rd edition and also to Orphanet:
narcolepsy type 1 (NT1), formerly known as narcolepsy with cataplexy) and
narcolepsy type 2 (NT2), formerly known as  narcolepsy without cataplexy.
Unlike canine narcolepsy which is monogenic, narcolepsy in humans is not a single genetic disease and it is sporadic in most cases (considered multifactorial). Most of NT1carry a specific HLA haplotype HLA-DQB1*06:02 which confer a susceptibility to the disease.
NT2 is also a complex disorder, but its genetic is even less understood.
This is helpful: https://www.nature.com/articles/s41439-018-0033-7
Thank you, Gioconda


KEDA Kafka-Scaler not scaling up anymore if close to max replica count

Report
I recognized in various situations that if the KEDA Kafka scaler is already close to the maximum replica count, the scaler seems to stop working. It's not scaling up to the maximum replica count, even though lag is way above target.
Expected Behavior
Given 1 topic, 24 partitions, 24 max replicas and a lag threshold of 1000 messages: Maybe I'm missing out on something, but shouldn't the scaler hit the maximum of 24 replicas when the lag is at ~55k, given a threshold of 1k messages and 21 existing replicas?
While testing with other scaling mechanisms (e.g. CPU only) I already reached the limit of 24 replicas and the cluster has > 60% of resources left, just to be able to rule that out as a possible problems as well.
Actual Behavior
See this example:

At first, the scaler seems to work properly. Around 13:25 the amount of messages-in is increased, and lag starts to build up - so the scaler scales up and seems working correctly. At 13:35, lag again starts to rise and builds up till roundabout 55k without any scaling activity, although it should scale up to the maximum of 24 consumer replicas. It stays at 21 consumers until I killed my producer and the lag was decreasing towards 0 again.
Looking at the logs, it seems like the autoscaler just stopped working at some point.
Opposed to this, in a phase where the scaler seems to work properly I also observe logs like this:
keda-operator-77f866d85b-l7hgz 2023-07-13T12:03:54Z    INFO    Reconciling ScaledObject    {"controller": "scaledobject", "controllerGroup": "keda.sh", "controllerKind": "ScaledObject", "ScaledObject": {"name":"consumerapp-scaled-object","namespace":"kafka"}, "namespace": "kafka", "name": "consumerapp- │

But in the phase of not scaling up anymore, there were none of the Reconciling-logs overall.
Steps to Reproduce the Problem
Suppose the following setup:
1 topic, 24 Partitions, maximum of 24 replicas, lag threshold of 1000 messages
My scaled object is configured like this:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: release-name-consumerapp-scaled-object
  labels:
    helm.sh/chart: consumerapp-0.1.0
    app.kubernetes.io/name: consumerapp
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "0.1.12"
    app.kubernetes.io/managed-by: Helm
  annotations:
    scaledobject.keda.sh/transfer-hpa-ownership: "true"
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: release-name-consumerapp
  pollingInterval:  30
  cooldownPeriod:   300
  idleReplicaCount:
  minReplicaCount: 1
  maxReplicaCount: 24
  triggers:
    - metadata:
        bootstrapServers: cluster-kafka-bootstrap.kafka:9092
        consumerGroup: group1
        lagThreshold: "1000"
        offsetResetPolicy: latest
        partitionLimitation: 1-24
        topic: topic1
      type: kafka
  advanced:
    horizontalPodAutoscalerConfig:
      name: consumerapp
      behavior:
        scaleUp:
          stabilizationWindowSeconds: 90
          policies:
            - periodSeconds: 45
              type: Pods
              value: 2
        scaleDown:
          stabilizationWindowSeconds: 300
          policies:
            - periodSeconds: 120
              type: Percent
              value: 100
            - periodSeconds: 60
              type: Pods
              value: 4

If necessary, I can provide all other charts for this setup.
Logs from KEDA operator
No response
KEDA Version
2.11.1
Kubernetes Version
1.26
Platform
Google Cloud
Scaler Details
Kafka
Anything else?
No response

Hi!
I have the feeling that the issue is related with the partition filtering (partitionLimitation).  Could you try removing that parameter?

Hi,
thank you for the fast answer! I already did a run without using this parameter at all, result is more or less the same, although this time it scaled up to 22 replicas and stopped again:

I did another test run with the doubled amount of partitions (48). Now the scaler scaled up to the max replica count of 24 and everything works as intended.
So it seems like it's somehow related to the amount of partitions and the issue occurs only if the amount of replicas is close to the amount of partitions?

Are you scrapping KEDA metrics by chance? If yes, you could see what KEDA is seeing from kafka (keda_scaler_metrics_value). Could you share it too? That's the raw value that KEDA exposes to the HPA controller.
Based of the previous logs like this:
keda-operator-77f866d85b-l7hgz 2023-07-13T11:50:21Z    DEBUG    grpc_server    Providing metrics    {"scaledObjectName": "consumerapp-scaled-object", "scaledObjectNamespace": "kafka", "metrics": "&ExternalMetricValueList{ListMeta:{   <nil>},Items:[]ExternalMetricValue{ExternalMetricValue{MetricName:s0-kafka-topic1,MetricLabels:map[string]string{},Timestamp:2023-07-13 11:50:21.730253149 +0000 UTC m=+4289.499786044,WindowSeconds:nil,Value:{{23000000 -3} {<nil>}  DecimalSI},},},}"}

In the other hand, KEDA is exposing 23000 several times in a row, which is too "round" value and looks like if has 23 "available partitions" in kafka (maybe due to an error getting them) and that's why the scaler limits the messages.
Could you give another try, setting the parameter allowIdleConsumers: true?

If I'm right this my suspicious, now it will work because the scaler won't limit the result to available partitions

Maybe we can improve the formula somehow to enforce that the difference is always above the tolerance, but I'm not sure if it's doable. Maybe calculating the tolerance somehow 🤔
@zroubalik , WDYT?

I have an idea for how this could be solved, and I'm interested in implementing it if there is consensus that the new approach is worthwhile.
Advantages:

keda_scaler_metrics_value will show the actual value used for scaling rather than a clamped value in the !allowIdleConsumers case (less confusing for users)
HPA will be able to scale to the number of partitions (or to the max replica value in the case of other scalers who implement this idea)
Disadvantages:
The max replicas shown in the HPA might not match minReplicaCount on the scaled object, potentially causing confusion (which would need to be addressed in docs)

My idea is that we could create an interface which scalers could choose to implement which allows the scalers to provide a maxReplicaCount if they want to. So this code:
https://github.com/kedacore/keda/blob/96322750070a0f9fbe34ff422ba772594ebca075/controllers/keda/hpa.go#L293-L295
would be changed to ask each trigger's scaler if its trigger has a maxReplicaCount and if so, the HPA would be given the lowest value provided (including the configured value from the scaledobject).
So, for example, imagine a scaled object with maxReplicaCount of 10 and a kafka trigger with a lagThreshold of 1, with allowIdleConsumers: false and aimed at a topic with only 5 partitions. The HPA would get configured with maxReplicaCount of 5 even though the scaled object has a higher value.  That way if the lag got really huge (like, say, 1,000), you would see that value propagate through the system and HPA would show that value and that it wants to scale up, but can't because of the maxReplicaCount of 5, which came from the kafka scaler's limit based upon the number of partitions.
While it is a little confusing, I find the current method even more confusing, since the actual lag value gets masked when it exceeds the number of partitions/lag threshold. Not to mention the confusion of scenarios like the one reported here where it won't scale to the number of partitions without some hackery.

I have an idea for how this could be solved, and I'm interested in implementing it if there is consensus that the new approach is worthwhile.

I think that we will have to wait until the end of the summer because we are partially (or totally) signed off. We can discuss it on the next community standup in the worst case.
FYI @kedacore/keda-core-contributors


Refs #36

Implement test_multiply_str under test_float.py

Hello @Rushane, thanks for the interest in contributing.
I'm afraid this change is not acceptable, however, because 1) it's adding a copy of a virtualenv directory, 2) the test_multiply_str test is already generated dynamically, there is no need to write it.
Note that a test name under the list not_implemented means that the code to handle that particular case (in this case, multiplying a string by a float) wasn't yet implemented, but it doesn't mean that the test itself isn't implemented -- it's generated and run by the test suite.

Thanks for replying.
So, how I would know if a test is run by the test suite? is it that all of the tests that are supposed to generate errors are run by the test suite?


[Question]: Model(qwen-plus) not authorized

Describe your problem
为什么提示这个错误？明明APIkey已经配置

Select the model in system setting or dialog setting that's available.


Pass search filters to -core.

[Resolves https://github.com/eregs/notice-and-comment/issues/173]
Depends on https://github.com/eregs/regulations-core/pull/50

Heads up, merge conflicts

Conflicts resolved.

Excited to see this!


Error opening 'log.txt' in zipfile

Hello, I get the following exception when creating an archive:
Error Domain=ObjectiveZipErrorDomain Code=-1 "OZZipException" UserInfo={NSLocalizedDescription=OZZipException, NSLocalizedFailureReason=Error opening 'log.txt' in zipfile

Hello,
this library is more than 10 years old and is deprecated since more than 3 years. You should really find an alternative.
I can't support it forever.
Sorry.


feat: add cls module

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Forward TMMBR and TMMBN packets

Forward TMMBR and TMMBN feedback packets to the corresponding RtpReceiver.

Question: should we also check possible TMMB packets into received RTCP compound packets?

Also, this depends on #89

NOTE: I do know that the PR is wrong, as it must extract all the items from the TMMB packet and get the RtpReceiver associated to each one. But, since I've also improved something in the logs in the same Peer.cpp file, may we keep the work in this branch?

Question: should we also check possible TMMB packets into received RTCP compound packets?

Compound packets are decomposed on reception, just when parsing. After parsing them Mediasoup does not know whether they came in a compound or separately. It just processes the packets separatelly.

Yes, right... I always forget that our RTCP design is so cool :)


Image does not build on other architectures than x86_64

Hello,
I get this error /usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory  if I try to generate an image with your dockerfile, do you have any idea what the problem might be ?
Thanks for your help

@bakousylla Which command triggers this error?

@bakousylla Still, please provide me the aws command which triggered this error.
Anyway: I just uploaded a new version of the tool including the mentioned library. Can you check if this resolves your issue?

I'have the same issue /usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory after pulling your modif

@bakousylla So please advise: Which cmmand triggers this error?

when I just try to build image

(base) ➜  docker-dind-awscli git:(master) docker build -t test:latest "."

OK: 30 MiB in 28 packages
Docker version 20.10.10, build b485636
/usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
The command '/bin/sh -c apk --update-cache add         binutils         curl         groff         bash         zlib     && sed -i 's/ash/bash/g' /etc/passwd     && curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub     && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk     && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk     && apk del libc6-compat     && apk add         glibc-${GLIBC_VER}.apk         glibc-bin-${GLIBC_VER}.apk     && curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip     && unzip -q awscliv2.zip     && aws/install     && rm -rf         awscliv2.zip         aws         /usr/local/aws-cli/v2/*/dist/aws_completer         /usr/local/aws-cli/v2/*/dist/awscli/data/ac.index         /usr/local/aws-cli/v2/*/dist/awscli/examples     && apk --no-cache del         binutils         curl     && rm glibc-${GLIBC_VER}.apk     && rm glibc-bin-${GLIBC_VER}.apk     && rm -rf /var/cache/apk/*     && docker --version     && aws --version' returned a non-zero code: 127

It seems that you are trying to build this image on aarch64 architecture, right?
Your main issue is, that currently the Dockerfile downloads & installs the x86_64 build of the glibc library set.
I found an open issue upstream there asking for an arm port: https://github.com/sgerrand/alpine-pkg-glibc/issues/126
Maybe this approach to build a container without GLIBC works on aarm64? : https://github.com/aws/aws-cli/issues/4685#issuecomment-788657890

you are right, I have the arm root:xnu-7195.141.6~3/RELEASE_ARM64_T8101 arm64, I'll try your solution without GLIBC, thanks a lot

I think I got it working with GLIBC on ARM by installing GLIBC from SatoshiPortal, which also provides them for aarch64. Afterwards you also have to install the aarch64 version of the awscli.  Hoping this helps someone!

@Ic3w0lf Awesome. Thanks for you contribution.
If I find a feasible easy way to crosscompile for other architectures I might adopt your example into my build and start publishing for additional architectures, too.
Just our of curiosity: What is you motivation for a aarch64?  Raspberry Pi? Apple M1? Any new server plattform?

@bentolor Super glad this is helpful :) My main motivation is Apple M1 in this case. I don't have any Apple Silicon myself, but wanted to provide this container as multiarch build for my colleagues who often go with M1 (especially in the future).
I couldn't really test in-depth if this works but asked a friend who is on M1 if he could quickly run aws --version in this container and he reported it works! :crossed_fingers:
Looking forward to see you try out other architectures as well! What architectures do you have in mind?

@Ic3w0lf Thanks for your insights.
To be honest: You issue showed me my ignorance regarding alternative platforms. Till now in IT we just developed for x86 and that was it. The latest moves in the market (ARM-based M1 & server hardware) and given that the list of supported architecture has grown quite a lot for popular open-source projects, I wondered which other architectures I should keep in mind for Docker workloads.
Looking on the linked list I think windows-amd64 might be potentially relevant, too.
But it seems we are both driven by the same interest in being prepared for upcoming trends. I just resurrected my old Raspberry Pi 3B and installed an aarch64 version of ubuntu on it so I can test your Dockerfile.

@bentolor Thank you for insights as well!
I agree with you. Until now it has pretty much been amd64 or nothing but I am really glad that Apple is heating up the architecture debate. Even though I am not an Apple fan I love the competition they bring into the game :)
And please let me know if awscli works as expected on a native arm system once you get to it!
Cheers and have a great evening!

Hitting the same error.  Haven't yet attempted the workaround, but wondering if there were any updates on a cross compiled option?

@david-AH just for my "census": Which architectures are you missing? Unfortunately this needs to be tackled individually per plattform right now.

Apple M1 -> arm64

Okay, after I realized cross-building is quite simple usine QEmu, I did a first run, but failed to succeed. You can see my efforts at https://github.com/bentolor/docker-dind-awscli/tree/experimental/aarch64 and there is a BUILD.md describing what needs to be done to get the build running.
Unfortunately the build fails with errors like
/usr/glibc-compat/sbin/ldconfig: /usr/glibc-compat/lib/ld-linux-aarch64.so.1 is not a symbolic link

OK: 32 MiB in 28 packages
Docker version 20.10.21, build baeda1f
/usr/local/bin/aws: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

Not sure what's the culprit here. I also had to downgrade the glibc version as the source does not provide newer builds.


Convert a number to binary.

Proposal
I would like to add the Calculator of converting a number to binary. Please assign me this issue under LGMSOC'21.

go ahead @deepaahuja92
Dead line 22 june

@deepaahuja92 this is already implemented under Binary Section, you can explore the app, amd find more issues, in our slck channel I provided a video for some ideas

sir where is the video? in which channel??
On Thu, Jun 17, 2021 at 1:04 PM Rajinderpal Singh @.***>
wrote:

Closed #5279 https://github.com/makesmatheasy/makesmatheasy/issues/5279.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/makesmatheasy/makesmatheasy/issues/5279#event-4902396785,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASJE3UMN4K45KXTFJVEFWR3TTGQRHANCNFSM4623XN2A
.

sir where is the video? in which channel??
…
On Thu, Jun 17, 2021 at 1:04 PM Rajinderpal Singh @.***> wrote: Closed #5279 <#5279>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5279 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASJE3UMN4K45KXTFJVEFWR3TTGQRHANCNFSM4623XN2A .

@deepaahuja92 its in the slack channel of our project
Here is the link of video
https://youtu.be/y0TIFvA45Ns


yotta documentation doesnt describe .yotta_ignore

.yotta_ignore needs to be be referenced/documented for the following reasons:

it excludes the subdirs in /test subdir so the test doesnt get build, for example

fixed by #263


webdrivercss tests fail on travis CI

Here is the content of my .travis.yml:
language: node_js
node_js:
  - "4.2.1"
env:
  - CXX=g++-4.8
addons:
  apt:
    sources:
    - ubuntu-toolchain-r-test
    packages:
    - g++-4.8

before_install:
  - sudo apt-get install graphicsmagick libcairo2-dev
  - export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig
  - npm install -g bower

install:
  - npm install
  - bower install

before_script:
  - npm install -g gulp
  - npm install -g karma
  # see https://github.com/webdriverio/gulp-webdriver/issues/20
  - npm install webdriverio

script: npm test

My tests run ok locally, but all of them are failing with near the same error on Travis:
[ { baselinePath: 'test/css/screenshots/buttons.primary.1024px.baseline.png',
    regressionPath: 'test/css/screenshots/buttons.primary.1024px.regression.png',
    diffPath: 'test/css/diffs/buttons.primary.1024px.diff.png',
    message: 'mismatch tolerance exceeded (+8.94), image-diff created',
    misMatchPercentage: 8.99,
    isExactSameImage: false,
    isSameDimensions: true,
    isWithinMisMatchTolerance: false,
    properties: { name: 'primary', elem: '.bb-btn--primary' } } ]

Here is the code of the test:
  it('buttons should have correct styles', function* () {
    yield browser.url('/buttons.html');
    const res = yield browser.webdrivercss('buttons',[
      {
        name: 'primary',
        elem: '.bb-btn--primary'
      }
    ]);

    assert.ok(res.primary[0].isWithinMisMatchTolerance, 'primary');
  });

Webdriver config:
webdrivercss: {
      screenshotRoot: 'test/css/screenshots',
      failedComparisonsRoot: 'test/css/diffs',
      misMatchTolerance: 0.05,
      screenWidth: [1024]
    }

Tests are being run on phantomjs. Any ideas what may cause the issue? Thanks.

@pavloo have you been able to check the actual screenshots?

@christian-bromann unfortunately no. any ideas on how to check them on travis? thanks

@pavloo you could make an after_failure step in travis that publishes the screenshot folder to a repo somewhere

You could also use something like https://github.com/webdriverio/webdrivercss-adminpanel.
I'm guessing the issue is small rendering differences between your local browser and what Travis uses. Using browserstack or sauce labs is almost a necessity for this sort of test.

@Blackbaud-PatrickOFriel @klamping I'll check it out, thanks


Copy Button in get-started page alignment fixed and make it responsive

Fixes #1338
Changes:
copy button alignment improved without any errors .
Screenshots of the change:

Ok sorry for that I will fix this


Building for MSM8960/mako - no lkboot.img created

I'm trying to port to the Nexus 4.
I've copied the msm8960-aries target folder and changed the lk target to msm8960. Unfortunately no lkboot.img file is created.
Any hints?

aries builds native bootloader images because it has board security disabled.
check this out: https://github.com/grub4android/build/blob/master/devices/condor/device.mk


maximum recursion depth exceeded when loading a vcf from a URL

For both load_vcf and load_vcf_fast we seem to end up in an infinite recursion involving url parsing:
In [3]: varcode.__version__
Out[3]: '0.4.16+1.g84db1b3'

In [5]: x = varcode.load_vcf("https://github.com/hammerlab/varcode/blob/master/test/data/multiallelic.vcf")
...
/Users/tim/sinai/git/varcode/varcode/vcf.pyc in load_vcf(path, genome, reference_vcf_key, only_passing, allow_extended_nucleotides, include_info, chunk_size, max_variants)
     84
     85     require_string(path, "Path or URL to VCF")
---> 86     parsed_path = parse_url_or_path(path)
     87
     88     if parsed_path.scheme and parsed_path.scheme.lower() != "file":

/Users/tim/sinai/git/varcode/varcode/vcf.pyc in parse_url_or_path(s)
    458     if s.startswith("//"):
    459         s = "/" + s.lstrip("/")
--> 460     return urllib.parse.urlparse(s)

/usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urlparse.pyc in urlparse(url, scheme, allow_fragments)
    141     Note that we don't break the components up in smaller bits
    142     (e.g. netloc is a single string) and we don't expand % escapes."""
--> 143     tuple = urlsplit(url, scheme, allow_fragments)
    144     scheme, netloc, url, query, fragment = tuple
    145     if scheme in uses_params and ';' in url:

/usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urlparse.pyc in urlsplit(url, scheme, allow_fragments)
    174     allow_fragments = bool(allow_fragments)
    175     key = url, scheme, allow_fragments, type(url), type(scheme)
--> 176     cached = _parse_cache.get(key, None)
    177     if cached:
    178         return cached

RuntimeError: maximum recursion depth exceeded in cmp

Can also be reproduced by running:
$ RUN_TESTS_REQUIRING_INTERNET=1 nosetests test/test_vcf.py

Ah, it's from the load_vcf_fast -> load_vcf rename. I'll push a fix

Not as easy as I thought
        # pandas.read_table nominally supports HTTP, but it tends to crash on
        # large files and does not support gzip. Switching to the python-based
        # implementation of read_table (with engine="python") helps with some
        # issues but introduces a new set of problems (e.g. the dtype parameter
        # is not accepted). For these reasons, we're currently not attempting
        # to load VCFs over HTTP with pandas, and fall back to the pyvcf
        # implementation here.

I think I'll switch it to just download the URL to a temporary file and then open that.


Fairing: Add tutorials for single node and distributed training with LightGBM

Currently, we have example notebooks for single node and distributed training with LightGBM but we do not have any documentation. Add a tutorial that describes how to use Fairing to train and predict with LightGBM, based on the example notebooks.
Single node training:
https://github.com/kubeflow/fairing/blob/master/examples/lightgbm/simple-training.ipynb
Distributed training:
https://github.com/kubeflow/fairing/blob/master/examples/lightgbm/distributed-training.ipynb

/label doc-sprint

The example notebooks were written for using Fairing and LightGBM to train on Kubeflow on GKE. Assuming that the code is not revised with instructions for using LightGBM in general, this tutorial should go in the following folder:
/docs/fairing/gcp/tutorials/

@joeliedtke Should we close this issue as obsolete?

/area docs
/priority p2


Removing current directory throws errors

Minimal steps to reproduce:
mkdir /tmp/atuin-test
cd !$
rm -rf /tmp/atuin-test

Now, the same error message is written for every interaction with the shell (like, typing ls):
Error: No such file or directory (os error 2)

Location:
    atuin-client/src/settings.rs:138:74

Even if I create the same directory again, the error message gets written.
Version:
$ cargo install --list
atuin v0.7.1 (https://github.com/ellie/atuin.git?rev=0b9dc6696be#0b9dc669):
    atuin

Discussion continued in #195


Add note about not using free to determine swap availability inside container.

Fixes #6833.

Thanks for the contribution!


fix the separator can not show

What does the pull request do?
Try to fixes #9643
use the
Fixed issues

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

You can test this PR using the following package version. 11.0.999-cibuild0027317-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-nightly/nuget/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0027316-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-nightly/nuget/v3/index.json) [PRBUILDID]

@danwalmsley I think this is your area.

You can test this PR using the following package version. 11.0.999-cibuild0027582-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]


Remove slider UX is terrible

Native input element so while accessible, how we connect it results in a sub-par experience. While the constant conversion jumps are not nice they are kinda expected right now, but there is too much going on when putting the slider to 100%.
Investigate and decide if native input type="range" should be replaced by a component with more control.

a quick fix wold be a max button since most issues are around the 100% position.
Credit to https://twitter.com/Karel_C/status/1324354282674515969


Print errors to stderr

In Gpv1 we used stderr for log messages we wanted to show as alerts. In Gpv2 I decided to go with regex filtering but it turns out that our kubernetes set up cannot handle regexes for long messages properly. So we need to go back to stderr.

Maybe we can hide this in our kubernetes container by wrapping the output of our rust process in some bash function that pipes to different streams based on a regex (https://stackoverflow.com/questions/18559869/how-to-split-a-stream-to-stdoutstderr-based-on-regular-expression-pattern)?
This way our main binary would still log in a more standard way.

It is a little more complicated because we also have to consider the log separator because log messages can be multi line. Probably too complicated for a bash script but could be a python script or simple rust binary. Having that could be nice for other projects in the future too. On the other hand it's more work to set that up because the docker container will need to contain the extra binary and the pipe instead of just running the main binary.

Could something like this work?
log_splitter.sh
#!/bin/bash

common="^[0-9]{4}\-[0-9]{2}\-[0-9]{2}T[0-9]{2}\:[0-9]{2}\:[0-9]{2}\.[0-9]{3}Z[ ]*"
std_err_re="$common ERROR"
std_out_re="$common (TRACE|DEBUG|INFO|WARN)"

stream="/dev/stdout"
IFS=''
while read line
do
    if [[ $line =~ $std_err_re ]]
    then stream="/dev/stderr"
    elif [[ $line =~ $std_out_re ]]
    then stream="/dev/stdout"
    fi
    echo $line >> $stream
done

cargo run ... | log_splitter.sh

Nice, that does seem to work and isn't as complicated as I thought. Couple of changes I made locally:

use #!/bin/sh for portability
use read -r to prevent special handling of \

Last thing I am not sure about is whether when echoing the line we need something special like "$line" because of how shell scripts expand variables and strings. Will look that up.


docs: document that NRGkick support only exists for older models

The list of supported charging cables has been updated to include only older NRGkick charging cables.
Currently, DiniTech GmbH refuses to publish the specification of the current communication protocol. According to discussions with NRGkick Support, it is also not guaranteed that a release is planned.
Further info:

https://github.com/evcc-io/docs/pull/464
https://github.com/evcc-io/evcc/discussions/4048

Nrgkick 2nd  gen released new API:
https://www.nrgkick.com/wp-content/uploads/2024/07/local_api_docu_simulate.html
would be great to include it!!


Strip Authorization value from logged headers

Summary
Replace the value of the Authorization header with REDACTED in the basic serializer.
Full changelog

Updated the basic serializer to replace the value of the Authorization header with the string REDACTED if present. This still indicates whether the client sent the header while not recording the actual credential in the log system.
Update serializer unit tests to confirm this behavior and use a more realistic header table.

Notes
As this is technically a new feature, and modifies existing existing functionality, PRing to next, though I think we could reasonably apply it to master and count it as bugfix instead depending on whether we think anyone relies on the existing behavior here (I don't think anyone should). The diff applies equally on either.
Including the actual value of Authorization is risky, as it will persist credentials to some log store. That store is not necessarily encrypted (and even if is, may be storing credentials normally stored in a one-way hash with reversible encryption) and may have different access controls than the normal credential store.
We furthermore already log the credential ID in .authenticated_entity.id for Kong-managed credentials, so at least some of the information lost with this change is available via other means.

PR CI failure appears to have been some issue with grpcbin: the same test succeeded on the push with only one commit, and succeeded for the PR with Postgres (there shouldn't be any meaningful difference between them). Please re-run if needed.

@rainest While we're doing this, what's your take on logging cookies? Should we drop those as well?
Any other standard header comes to mind?

Of https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Authentication we may encounter Proxy-Authorization, although unlikely--should be only in cases where there's some other upstream proxy that needs it. Should be fine to exclude as well, since it's only credentials.
Cookie and Set-Cookie are a harder call, as they can contain both credentials and generic information that affects non-authentication parts of the response (e.g. that a user has set their preferred language to German). I'd lean towards dropping them to be on the safe side and working towards a more tunable system depending on whether anyone values the ability to log them.

Of https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Authentication we may encounter Proxy-Authorization, although unlikely--should be only in cases where there's some other upstream proxy that needs it. Should be fine to exclude as well, since it's only credentials.

Agreed, this seems like a safe bet to exclude.

Cookie and Set-Cookie are a harder call, as they can contain both credentials and generic information that affects non-authentication parts of the response (e.g. that a user has set their preferred language to German). I'd lean towards dropping them to be on the safe side and working towards a more tunable system depending on whether anyone values the ability to log them.

Yeah, cookies sound like a case-by-case thing, I can imagine people trying to debug applications and getting annoyed by them ceasing to be available. I wouldn't mind merging this with the authorization exclusions only, as an incremental improvement, and then go for the tunable system where cookie (or other) headers can be enabled/disabled as a future step. @bungle, what do you think?

Updated to strip Proxy-Authorization and make the implementation a bit more flexible and leave it open to adding cookie headers later.


salt-call is parsed wrongly

When running something like sudo salt-call state.apply test=True falco parsed the command and program name wrong.
The output I get is the following:
Warning Sensitive file opened for reading by non-trusted program (user=root user_loginuid=1001 program=run command=run call state.apply test=True pid=2123116 file=/etc/sudoers.d/[REDACTED] parent=sudo gparent=bash ggparent=sshd gggparent=sshd container_id=host image=<NA>)

As you can see, the command field looks wrong; it interprets salt-call  as run call while program is seen as run.

Activate default rules for falco
run sudo salt-call state.apply test=True

Unfortunately this needs salt installed but it might be enough to just use an alias like alias echo=salt-call.

I expect program=salt-call and command=salt-call state.apply test=True

Environment

Falco version: 0.34.1

System info:

Thu Apr 13 16:29:08 2023: Falco version: 0.34.1 (x86_64)
Thu Apr 13 16:29:08 2023: Falco initialized with configuration file: /etc/falco/falco.yaml
Thu Apr 13 16:29:08 2023: Loading rules from file /etc/falco/falco_rules.yaml
Thu Apr 13 16:29:08 2023: Loading rules from file /etc/falco/falco_rules.local.yaml
{
  "machine": "x86_64",
  "nodename": "[REDACTED]",
  "release": "5.15.0-60-generic",
  "sysname": "Linux",
  "version": "#66-Ubuntu SMP Fri Jan 20 14:29:49 UTC 2023"
}

Cloud provider or hardware configuration: VM in Openstack
OS: Ubuntu 22.04.2 LTS

Kernel: 5.15.0-60-generic #66-Ubuntu SMP Fri Jan 20 14:29:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Installation method: DEB

Hi! Thanks for opening this issue!
This issue is well known and is being tracked:

https://github.com/falcosecurity/libs/issues/1011
https://github.com/falcosecurity/libs/issues/988

And a couple of related PRs:

https://github.com/falcosecurity/libs/pull/976

Thanks @FedeDP, then I'd close this one!

Feel free to comment on other issues if you feel :) every feedback is appreciated!


Check for ParagraphNode instance rather than type

Fix for displaying placeholder for custom nodes

You can if use $isParagraphNode instead. It’s imported from Lexical.

You can if use $isParagraphNode instead. It’s imported from Lexical.

Fixed!

You'll need to rebase onto main to fix that failing integrity check - I  just merged the fix in

You'll need to rebase onto main to fix that failing integrity check - I just merged the fix in

@acywatson, unfortunately I had created this PR from the browser, so I couldn't rebase any changes from main. I have now cloned the repo locally and created a new PR (#3557).

Closed in favor of #3557


Load Filter Criteria for MATS Method Data

Create views that load the data for each dropdown in the module

[x] Parameted Code

[x] Method Code

created View camdecmpswks.vw_matsmethods_master_data_relationships