Add quickstart documentation

Codecov Report
Patch and project coverage have no change.

Comparison is base (abb68f1) 100.00% compared to head (c0c2fd7) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #16   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            5         5
  Lines          153       153
  Branches        27        27
=========================================
  Hits           153       153

Files Changed
Coverage Δ

src/minevent/conditions.py
100.00% <ø> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fix spyder build

Description of changes
This PR updates a few python packages which fixes the build of spyder.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Python libs should be merged against staging, because they trigger too much rebuilding.

Please restart this.


Add rewrite path / utm_ codes callback

Fixed in https://github.com/simpleanalytics/scripts/pull/29


MGMT-1565 change cluster refresh status using get cluster from db once

It will prevent races when we get cluster with state A and then because of a race
we can get a cluster with a different state.

Ran 45 of 45 Specs in 619.159 seconds
SUCCESS! -- 45 Passed | 0 Failed | 0 Pending | 0 Skipped
--- PASS: TestSubsystem (619.16s)
PASS


Typo Fix

Hi,
I found there is a typo in the LICENSE-CC-BY-NC. Now fixed.
Best,
Yipeng

Thanks @sypsyp97! I'm merging this 🚀


How can we add our location like this on Google Maps? This example only shows the White House.

In the provided example code, the map displays the indoor view for the White House. I want to add this functionality for another location that doesn't have indoor details mapped on Google Maps. Can you please explain how to add indoor details to the map? Only then can I use this package to display it in my app.


Supporting more than 1 location for template toolkit

Not sure why this cannot automatically merge. Looks ok to me but hey GitHub thinks it's WRONG.

your branch is still on release 83, so not sure the merge worked as expected

Ok seems I needed to pull in those changes from master. Not sure why I didn't do that originally

looking better now, no issue from my side


python311Packages.watchfiles: 0.19.0 -> 0.20.0

Diff: https://github.com/samuelcolvin/watchfiles/compare/refs/tags/v0.19.0...v0.20.0
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

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

4 packages failed to build:

streamlit (python310Packages.streamlit)
streamlit.dist (python310Packages.streamlit.dist)
python311Packages.streamlit
python311Packages.streamlit.dist

35 packages built:

baserow
baserow.dist
dmarc-metrics-exporter
dmarc-metrics-exporter.dist
irrd
irrd.dist
lektor
lektor.dist
paperless-ngx
python310Packages.altair
python310Packages.altair.dist
python310Packages.anywidget
python310Packages.anywidget.dist
python310Packages.bentoml
python310Packages.bentoml.dist
python310Packages.unstructured-api-tools
python310Packages.unstructured-api-tools.dist
python310Packages.vega
python310Packages.vega.dist
python310Packages.watchfiles
python310Packages.watchfiles.dist
python311Packages.altair
python311Packages.altair.dist
python311Packages.anywidget
python311Packages.anywidget.dist
python311Packages.bentoml
python311Packages.bentoml.dist
python311Packages.unstructured-api-tools
python311Packages.unstructured-api-tools.dist
python311Packages.vega
python311Packages.vega.dist
python311Packages.watchfiles
python311Packages.watchfiles.dist
strictdoc
strictdoc.dist


Remove the IAM Policy Controller

Remove the governance-policy-framework (integration) tests related to IAM.
Ref: https://issues.redhat.com/browse/ACM-10859
Signed-off-by: yiraeChristineKim<EMAIL_ADDRESS>

/unhold


Fix bugs in FramebufferTag, add VBEInfoTag.

This adds VBEInfoTag and friends in a new module vbe_info and a test for this, as well as fixing a few bugs in the implementation of FramebufferTag and adding a new method current_address() to Reader.

@tuomas56 Thanks for the PR!
@rust-osdev/multiboot2 Does someone have time reviewing this?

I'll take a look @phil-opp

Seems good @tuomas56! I would say this is ready to merge. Can anyone else from @rust-osdev/multiboot2 confirm with me on this?

Thank you for making the requested changes! @rust-osdev/multiboot2 We should publish a 0.9.0 crate that includes these changes.  If anyone has some free time to do so, that'd be much appreciated! Otherwise, I can do it some time next week


woodpecker-server: 0.15.8 -> 0.15.11

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for woodpecker-server is: Woodpecker Continuous Integration server
meta.homepage for woodpecker-server is: https://woodpecker-ci.org/
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.15.9 with grep in /nix/store/gndj4mm1srd96nyjzwnddjc73bbs2aba-woodpecker-server-0.15.9
found 0.15.9 in filename of file in /nix/store/gndj4mm1srd96nyjzwnddjc73bbs2aba-woodpecker-server-0.15.9

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

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
woodpecker-agent
woodpecker-cli
woodpecker-server

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gndj4mm1srd96nyjzwnddjc73bbs2aba-woodpecker-server-0.15.9 \
  --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 woodpecker-server https://github.com/r-ryantm/nixpkgs/archive/63f854566f8f090990ea56a3ad1ef2fd1226e19f.tar.gz

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

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

3 packages built:

woodpecker-agent
woodpecker-cli
woodpecker-server

Maintainer pings
cc @ambroisie @techknowlogick for testing.

Opened a bug upstream, will wait to see if they patch it out or if it might be on purpose.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for woodpecker-server is: Woodpecker Continuous Integration server
meta.homepage for woodpecker-server is: https://woodpecker-ci.org/
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.15.10 with grep in /nix/store/23wr5qv9cg88y6fvw2bd7a70w1a807jl-woodpecker-server-0.15.10
found 0.15.10 in filename of file in /nix/store/23wr5qv9cg88y6fvw2bd7a70w1a807jl-woodpecker-server-0.15.10

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

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
woodpecker-agent
woodpecker-cli
woodpecker-server

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/23wr5qv9cg88y6fvw2bd7a70w1a807jl-woodpecker-server-0.15.10 \
  --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 woodpecker-server https://github.com/r-ryantm/nixpkgs/archive/d58aa93150f9005b3388a17cd951947c98cba5eb.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/23wr5qv9cg88y6fvw2bd7a70w1a807jl-woodpecker-server-0.15.10
ls -la /nix/store/23wr5qv9cg88y6fvw2bd7a70w1a807jl-woodpecker-server-0.15.10/bin

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

3 packages built:

woodpecker-agent
woodpecker-cli
woodpecker-server

Maintainer pings
cc @ambroisie @techknowlogick for testing.

The rogue log line is still present in v0.15.10, bumped the issue to see if it gets fixed.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for woodpecker-server is: Woodpecker Continuous Integration server
meta.homepage for woodpecker-server is: https://woodpecker-ci.org/
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.15.11 with grep in /nix/store/mpgw8x1qgm4aymds4hl4q51fg8ilzddk-woodpecker-server-0.15.11
found 0.15.11 in filename of file in /nix/store/mpgw8x1qgm4aymds4hl4q51fg8ilzddk-woodpecker-server-0.15.11

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

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
woodpecker-agent
woodpecker-cli
woodpecker-server

Instructions to test this update (click to expand)

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

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

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

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

3 packages built:

woodpecker-agent
woodpecker-cli
woodpecker-server

Maintainer pings
cc @ambroisie @techknowlogick for testing.


Tables

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] The commit message follows Conventional Commits
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Other... Please describe:

What is the current behavior?

Closes #
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

if I change value of this input and press Tab to go to the next cell, it triggers a recalculation of Total and rerendering a table and table loses focus

if I change value of this input and press Tab to go to the next cell, it triggers a recalculation of Total and rerendering a table and table loses focus

Moreover, it loses focus pressing Tab after any editing


Installation issue on dokku (similar to heroku): cannot find module providing package embed

I use dokku to deploy pgweb to my web server. Dokku works like Heroku but let's you deploy software on your own server.
I have cloned the repo and pushed it to the dokku server to start the deployment.
This issue occurred:
-----> Running: go install -v -tags heroku github.com/sosedoff/pgweb
       build github.com/sosedoff/pgweb: cannot load embed: cannot find module providing package embed

Any ideas on how to fix it?

Version 1.12.17


Fix reading VTK surface meshes [vtk-surface-fix]

The mesh space dimension was not set correctly in the VTK mesh reader when reading straight sided surface meshes.
Resolves #2547 and #2563.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#2566
@pazner
@tzanio
@tzanio + @bslazarov + @mlstowell
09/23/21
⌛due 10/07/21
⌛due 10/14/21

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

@HFH104864 can you confirm this works for you?
(I can add you as a reviewer, if you accept the invite to join the MFEM organization)

This pull request works for my .vtu 3D surface mesh model.

This pull request works for my .vtu 3D surface mesh model.

Great, thanks for checking!

Merged in next for testing...


canot import vector from flet

i try you sample floating action button menu
but error no found package vector
Traceback (most recent call last):
File "C:\Users\LENOVO\Pictures\fletapp\flet2\main.py", line 4, in
from fab import AnimatedMenuButton, MenuItem
File "C:\Users\LENOVO\Pictures\fletapp\flet2\fab.py", line 9, in
from flet import (
ImportError: cannot import name 'Vector' from 'flet' (C:\Users\LENOVO\AppData\Local\Programs\Python\Python311\Lib\site-packages\flet_init_.py)

from this file
https://github.com/flet-dev/examples/blob/main/python/community/floating_menu_button/menubutton.py

up

You can get it working by importing the vector properly. There are other issues with the example however that I do not have time to resolve at the moment (Error displaying ElevatedButton),
Here is the code to import the vector properly
`import math
import threading
import time
from dataclasses import dataclass, field
from typing import Callable, Optional
import flet
from beartype.typing import List
from flet import (
ButtonStyle,
ClipBehavior,
Container,
ElevatedButton,
FilledButton,
Page,
Stack,
colors,
icons,
)
from flet_core.utils import Vector`


Numerical issues with automatic matrix derivatives

While it is my impression that automatic differentiation generally enjoys numerical stability, this does not seem to extend directly to complicated expressions involving matrix calculus.
In particular, for objectives involving matrix inverses the error can grow disproportionately large, leading to e.g. scipy optimization routines failing to converge.
In my case I see TF with absolute element-wise gradient errors (comparing to the numerical Jacobian from tf.test.compute_gradient) around 10e-4 when my analytical gradient (also written using TF, only explicitly) gets errors near 10e-15.
The problem likely boils down to the TF graph computing the inverses naively and not exploiting e.g. Cholesky and/or triangle structure or reframing multiplications as more stable linear system solves.
I'm not sure I can readily provide a MWE as the code is somewhat complicated, but it is basically Gaussian process regression with a heavily parameterized kernel function.
The objective itself has a form similar to what is found in the snippet below, with the callable instance kernel holding several tuneable parameters.
   #kernel computations
    self.K = self.kernel(self.Xtrain) + self.kernel.diag(self.Xtrain) + self.kernel.noise(self.Xtrain)  +    self.kernel.jitter(Xtrain)
    self.Ktest = self.kernel(self.Xtest) + self.kernel.noise(self.Xtest)  + self.kernel.jitter(self.Xtest)
    self.Kx = self.kernel(self.Xtrain, self.Xtest)
    self.L = tf.cholesky(self.K)

    self.Ly = tf.matrix_triangular_solve(self.L, self.ytrain, lower = True)
    self.LKx = tf.matrix_triangular_solve(self.L, self.Kx, lower = True)
    self.llk = -0.5*tf.reduce_sum(self.Ly**2.) - 0.5*logdet_chol(self.L)
    self.objective = - self.llk

Continued matrix calculus support was one of the primary reasons I picked TF over the alternatives, so I am really hoping this is something that can be fixed in the future.

Are your gradients computed in single or double precision? 10e-4 doesn't sound surprising of your gradient computation is in single precision. Could you perhaps boil this down to a reproducible example program and include your analytical gradient computation for comparison? If you peel off one step at a time in your objective, can you identify a step that is particularly inaccurate, or is it a gradual loss across the chain of matrix gradients?
I agree with your general point that long chains of matrix operations (especially inverses and solves) can cause a loss of accuracy (especially in single precision). And since TensorFlow is not really a computer algebra system, the gradients are constructed by "naively" composing the individual op gradients using the chain rule without any algebraic simplification  / graph rewriting that could possibly improve accuracy.
I don't think your comment about the gradient implementations is accurate: All the gradient ops in https://github.com/tensorflow/tensorflow/blob/master/tensorflow/python/ops/linalg_grad.py use triangular and general matrix solves rather than forming and multiplying by the inverse (apart from determinant where the gradient is a scalar time the inverse). The Cholesky gradient uses a blocked algorithm, but also uses proper backsolves at the core. https://cs.corp.google.com/piper///depot/google3/third_party/tensorflow/core/kernels/cholesky_grad.cc?rcl=131328798&l=108
Please have a look at those functions and let us know if you find something that you think could be improved, or even better submit a pull request with improvements to the code.

@Bonnevie I assume that your logdet_chol is something like this:
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/contrib/distributions/python/ops/operator_pd_cholesky.py#L101

@Bonnevie any more thoughts on this?

@Bonnevie No, we do not do any dynamic checks for structure or sparsity in matrices, only functions like matrix_triangular_solve or cholesky_solve explicitly presuppose triangular structure.
Thanks for providing the analytic gradients and your analysis. I will take a look sometime in the coming week and respond here.

To answer your question about the auto-diff engine: The engine itself only knows how to apply the chain rule to compose the "gradients" of entire ops to derive the gradient of all trainable variables in a model w.r.t. the loss:
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/python/ops/gradients.py#L307
The entire gradient for matrix operations is computed in whole by hand-written gradient functions and then composed. See, e.g. https://github.com/tensorflow/tensorflow/blob/master/tensorflow/python/ops/linalg_grad.py#L33
The algebraic simplifications you do in your derivation simply cannot be done automatically in the current system, and would require manually writing a function for the gradient of log-determinant (or your entire log-likelihood function). That being said, I'm taking a second look at the linear solvers to see if perhaps adding a few steps of iterative refinement would help with the accuracy of the gradients.

@Bonnevie Would you mind providing the condition numbers and norms of the special input cases that are causing issues (or perhaps even links to the matrices themselves)?

Is there a way to compute the logdet of a matrix on the  GPU and be able to backprop on it?

@alexmonroe87 currently most of the higher level linear algebra ops (cholesky, determinant, matrix_inverse,  matrix_solve etc.) are CPU only. There has been some interest in contributing GPU implementations based on the cuSolver library, but no recent progress. See https://github.com/tensorflow/tensorflow/issues/2217

Closing due to inactivity.


Create github integration plugin to fetch PR

Implement [sc-92874]

Replaced by https://github.com/dataiku/dss-plugin-github/pull/2 so closing this one.


DownloadDispatcher.transferData() may crash with a nullpointer exception

DownloadDispatcher.transferData() may crash with a nullpointer exception as such:
java.lang.NullPointerException: Attempt to invoke virtual method 'void java.io.OutputStream.close()' on a null object reference
    at com.thin.downloadmanager.DownloadDispatcher.transferData(DownloadDispatcher.java:232)
    at com.thin.downloadmanager.DownloadDispatcher.executeDownload(DownloadDispatcher.java:141)
    at com.thin.downloadmanager.DownloadDispatcher.run(DownloadDispatcher.java:83)

The problem lies in the finally block at the end of the method
try {
    if (out != null) out.flush();
    if (outFd != null) outFd.sync();
} catch (IOException e) {
} finally {
	try {
		out.close();
	} catch (IOException e) {
		e.printStackTrace();
	}
}

out is normally checked against null before used, but in the finally block there is no check so if out is null it will crash here.

Ignore me, seems like this is fixed in the latest code. Just that the version I'm running doesn't have the fix.


feat: ✨ add resource attributes to span attributes

https://github.com/SigNoz/signoz/issues/881

This was merged already to Develop


Unable to highlight dynamically created content

Have a html that downloads code from the internet and displays it using the following javascript callback:
function display_file(fileInfo)
{
	$('#div_pygments_loadfiles')[0].innerHTML +=
	`
	  ${fileInfo.path}

${fileInfo.data}

	`
}

It creates a
 block to hold the code. The element inspection using the developer tools shows that it is classed with "python hljs" as expected, but the code is not highlighted, only the background is painted with the desired color/pattern. Tried several styles but all behave the same way.
The same downloaded code, if copied and pasted to the  section with the same
 tags, is highlighted normally.

You can download the file demo.html from my Bitbucket snippet to check it out:
https://bitbucket.org/snippets/runsun/bMKzz
or copy and paste its raw file:
https://bitbucket.org/!api/2.0/snippets/runsun/bMKzz/f64fda6945c927511d7e6e96f2387fd185e7caa1/files/demo.html

You have to use the highlightBlock function after you have added new content. The default behavior is highlighting only when the page loads.


Add UIUC Parboil Benchmakr Suite to Ocelot Regression Tests

From<EMAIL_ADDRESS>on July 08, 2009 10:00:04
Describe the New Feature: Create a regression test based on the UIUC Parboil benchmark suite. Which milestone does the feature belong to? 0.5.0 Which branch does the new feature go in? Trunk
Original issue: http://code.google.com/p/gpuocelot/issues/detail?id=9

From<EMAIL_ADDRESS>on July 10, 2009 08:12:31
It seems like the complete benchmark suite is not available online.  Some of the
required headers seem to be missing.  Blocked until I hear back from the UIUC folks.
Status: Blocked

From<EMAIL_ADDRESS>on July 29, 2009 15:14:53
Haven't heard back from the UIUC folks about this... Moving on to other benchmarks...
Status: WontFix

From<EMAIL_ADDRESS>on August 22, 2009 21:07:01
Found the relevant files on the UIUC website.  Was able to compile the benchmarks and
integrate them into the ocelot codebase.  There are now regression tests that all
pass for each parboil benchmark.
Status: Fixed


Why GQA instructions are different from the paper?

Hi! Thank you for MDETR, it is an amazing idea and special thanks for documenting your code. It helped me a lot in understanding MDETR.
I have a question about the GQA dataset fine-tuning for visual question answering.
The paper says

[we] fine-tune first for 5 epochs on the unbalanced all GQA split, followed by 10 epochs on the balanced split similar to what is done in prior work [28, 5]. During the first 5 epochs, we train the modulated detection losses along with the question answering, but put a weight on question answering loss that encourages the model to focus more on this task. For the balanced split fine-tuning, we only use the question answering loss.

However, "reproduce results" instructions in gqa.md suggest fine-tuning for 125 epochs on either "all" or "balanced" split. It also seem to use detection loss for all of the epochs.
Could you clarify why these instructions are different and what kind of the results one can expect from the github instructions vs paper instructions. Currently, after training for 25 epochs with github instructions (balanced dataset) I have about 53% validation accuracy (gqa_accuracy_answer_total_unscaled) which is much lower than the number in the paper (62%).
Also, how important have you found the detection objective for this task?

Hi! Thanks for your interest :)
Sorry for the confusion - we ran experiments and seem to have not correctly updated the paper. We will be uploading a revision very soon. I'll describe our setup below, please let me know if you have any further questions.
This was the command that we used for first fine-tuning on the "all" split, which is essential to getting good final performance that we report, after further finetuning on the balanced split.
(make sure to change the configs/gqa.json to point to the all split)
python run_with_submitit.py --dataset_config configs/gqa.json --ngpus 8 --ema --epochs 125 --epoch_chunks 25 --do_qa --split_qa_heads --lr_drop 150 --load https://zenodo.org/record/4721981/files/pretrained_resnet101_checkpoint.pth--nodes 4 --batch_size 4 --no_aux_loss --qa_loss_coef 25 --lr 1.4e-4 --lr_backbone 1.4e-5 --text_encoder_lr 7e-5
For the finetuning on all, we do use the detection losses and you can see we have --qa_loss_coef 25, which is the weight on the qa loss to encourage the model to focus on this task. Also, unlike regular MDETR training, we have --no_aux_loss which further reduces the emphasis on the detection losses (this means we are not supervising each layer, but only the last layer). We did have ablation runs which did not have the detection losses at all during this phase but these runs performed consistently worse.
Once we have a model finetuned on the "all" set,  we finetune on the "balanced" set (GQA leaderboard eval script focuses on this split which is why its common practice to do this) for 10 epochs using the command given below:
(make sure to change the configs/gqa.json to point to the balanced split)
python run_with_submitit.py --dataset_config configs/gqa.json --ngpus 8 --ema --epochs 10 --do_qa --split_qa_heads  --load /path/to/model/finetuned/on/all--nodes 4 --batch_size 4 --no_aux_loss --qa_loss_coef 25  --ce_loss_coef 0 --bbox_loss_coef 0 --giou_loss_coef 0 --lr 7e-5 --lr_backbone 1.4e-5 --text_encoder_lr 7e-5
We have not uploaded the intermediate checkpoint after finetuning on all, but you can tell me if you need it I can provide it to you.
Hope this makes sense and I'll update the readme to be more clear as well.
Best,
Aish

Thank you! This makes sense.


Fetch tests should test local storage

Spotted while working on other things that assert_pointer wasn't a good test for fetch, since it only validates that the git commit objects have the right pointer data, not that the content exists locally.
Added assert_local_object and refute_local_object instead & used in fetch tests.

Ah yeah, good call :+1:


JANDEX-49: Top-level ClassInfo read from an index file now reports the correct NestingType

@n1hility please review

I think we can close this PR as @n1hility introduced a more complex fix in https://github.com/wildfly/jandex/commit/ce4dd9a57e4ac6f308da57aac01fcede1a94370a. @gastaldi could you pls test your app with Jason's fix?


Where can I download the electronic circuit board of PS-CPU_ELECTRONIC_BOARD.PRT in the head of iCub?

Where can I download the electronic circuit board of PS-CPU_ELECTRONIC_BOARD.PRT in the head of iCub?
Clone all folders but no related electronic circuit boards were found.

cc @MrAndrea

Thank you for your reply


server didn't handle connect and disconnect event

origin line 63 in Startup.cs:
app.UseMqttServer(server => app.ApplicationServices.GetRequiredService<Mqtt.MqttService>());
should be as following:
app.UseMqttServer(server => app.ApplicationServices.GetRequiredService<Mqtt.MqttService>().ConfigureMqttServer(server));

thanks. I missed that

How do you connect a client(Mqtt Client) to this server ?

How do you connect a client(Mqtt Client) to this server ?

I think the sample app included client connection from blazer/wpf/xamarin form


"url.Error Post"

*url.Error Post https://itch.io/api/1/7B9DN2B3UcoFJSok3SUX15EUH71ygcW7xKYBr4d1/wharf/builds/34657/files/128265: EOF
C:/Go/src/runtime/asm_386.s:1629 (0x44f991)
Not sure what this means but I'm guessing either there's a bug or you need a better error message. Command was a butler push

Sounds like a network error. Can you reproduce it (does it happen every time) ?
Does it happen on other computers you have access to? In the same network/in a different network?
Can you ping itch.io ?

See https://groups.google.com/forum/m/#!topic/Golang-Nuts/HsaLNTMq3eI - this error seems to happen when the server in question messes up badly. I wouldn't introduce a custom error message for this since it's not a "usual" error

It worked just fine on retry, so i guess its a network error as you
suggested
On 21 Jun 2017 10:35 p.m., "Amos Wenger"<EMAIL_ADDRESS>wrote:

See https://groups.google.com/forum/m/#!topic/Golang-Nuts/HsaLNTMq3eI -
this error seems to happen when the server in question messes up badly. I
wouldn't introduce a custom error message for this since it's not a "usual"
error
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/itchio/butler/issues/108#issuecomment-310212061, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAgLNkWmn_iM4dTNi4ZpZ_7gf12SdR3lks5sGYyZgaJpZM4OBgyg
.


Added GEOSHAPE field and test polygon search

coverage: 80.338% (+0.05%) from 80.289%
when pulling bdd92ded8a1095b269daf88d3661d133e438ba91 on vladvildanov:vv-geoshape-queries
into cbef71090b710063cbc3e00b8f29947195846ce9 on predis:v2.x.

coverage: 80.338% (+0.05%) from 80.289%
when pulling b292ef6f04108045e5485923e78f5007be9accff on vladvildanov:vv-geoshape-queries
into cbef71090b710063cbc3e00b8f29947195846ce9 on predis:v2.x.

coverage: 80.338% (+0.05%) from 80.289%
when pulling 5ff5f6932ac98a7f3d1c83c86f33bece67c5f8cd on vladvildanov:vv-geoshape-queries
into cbef71090b710063cbc3e00b8f29947195846ce9 on predis:v2.x.

coverage: 80.338% (+0.05%) from 80.289%
when pulling f6f0dec12833e1e04d11d294493b59c58f3f8c26 on vladvildanov:vv-geoshape-queries
into c5fdfc81ef854797f8b949c1f67152731a7616ce on predis:v2.x.

coverage: 80.342% (+0.05%) from 80.293%
when pulling 8bbb1175285bf65b9d401be63c8d5c4306fa2a82 on vladvildanov:vv-geoshape-queries
into 5d22ed775a912d5ca41d6348a9fdf30b83ede4d5 on predis:v2.x.


ARROW-13409: [C++][FlightRPC] Expose server shutdown with deadline

This is to resolve ARROW-13409.

@lidavidm fixed the linting. Sorry about that.


[Pods] DCOS-9984:  Adjust task directory path handling to support pods

Introduce and integrate a new util to get the task directory from Mesos state which is capable of handling nested task groups (pods).
Closes DCOS-9984

When tests pass I am 👍

Awesome work! Just a few #nits :shipit:


Questions about the pretrained DETR models for PSGTR and PSGFormer

Thanks for your work!
I have successfully installed the framework and run the code (no errors reported).
However, I have a similar problem to #33 ：during training, the result is always zero.

According to the logs you provided, I compared and found that my log section does not have anything related to model loading：

I used the latest code and did not make any changes.
My questions are::
Have you ever encountered this problem?
Is the lack of weight loading content in my logs omitted in the later code or does it not appear due to model loading failure?
The most important question: In what way are the pre-trained models of DETR such as detr_pan_r50.pth and detr4psgformer_r50.pth obtained, and can we train them ourselves?
What is the difference between them (in my understanding, both pre-trained models use their Encoder part for global information extraction)
Thanks!

I found that when loading the DETR pre-trained model “./work_dirs/checkpoints/detr4psgformer_r50.pth” with “psgformer_r50_psg”, there were many missing hints：
missing keys in source state_dict:
bbox_head.transformer.decoder2.layers.0.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.0.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.0.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.0.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.0.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.0.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.0.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.0.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.0.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.0.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.0.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.0.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.0.norms.0.weight, bbox_head.transformer.decoder2.layers.0.norms.0.bias, bbox_head.transformer.decoder2.layers.0.norms.1.weight, bbox_head.transformer.decoder2.layers.0.norms.1.bias, bbox_head.transformer.decoder2.layers.0.norms.2.weight, bbox_head.transformer.decoder2.layers.0.norms.2.bias, bbox_head.transformer.decoder2.layers.1.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.1.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.1.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.1.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.1.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.1.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.1.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.1.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.1.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.1.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.1.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.1.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.1.norms.0.weight, bbox_head.transformer.decoder2.layers.1.norms.0.bias, bbox_head.transformer.decoder2.layers.1.norms.1.weight, bbox_head.transformer.decoder2.layers.1.norms.1.bias, bbox_head.transformer.decoder2.layers.1.norms.2.weight, bbox_head.transformer.decoder2.layers.1.norms.2.bias, bbox_head.transformer.decoder2.layers.2.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.2.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.2.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.2.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.2.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.2.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.2.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.2.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.2.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.2.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.2.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.2.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.2.norms.0.weight, bbox_head.transformer.decoder2.layers.2.norms.0.bias, bbox_head.transformer.decoder2.layers.2.norms.1.weight, bbox_head.transformer.decoder2.layers.2.norms.1.bias, bbox_head.transformer.decoder2.layers.2.norms.2.weight, bbox_head.transformer.decoder2.layers.2.norms.2.bias, bbox_head.transformer.decoder2.layers.3.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.3.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.3.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.3.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.3.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.3.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.3.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.3.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.3.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.3.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.3.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.3.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.3.norms.0.weight, bbox_head.transformer.decoder2.layers.3.norms.0.bias, bbox_head.transformer.decoder2.layers.3.norms.1.weight, bbox_head.transformer.decoder2.layers.3.norms.1.bias, bbox_head.transformer.decoder2.layers.3.norms.2.weight, bbox_head.transformer.decoder2.layers.3.norms.2.bias, bbox_head.transformer.decoder2.layers.4.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.4.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.4.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.4.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.4.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.4.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.4.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.4.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.4.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.4.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.4.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.4.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.4.norms.0.weight, bbox_head.transformer.decoder2.layers.4.norms.0.bias, bbox_head.transformer.decoder2.layers.4.norms.1.weight, bbox_head.transformer.decoder2.layers.4.norms.1.bias, bbox_head.transformer.decoder2.layers.4.norms.2.weight, bbox_head.transformer.decoder2.layers.4.norms.2.bias, bbox_head.transformer.decoder2.layers.5.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.5.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.5.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.5.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.5.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.5.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.5.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.5.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.5.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.5.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.5.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.5.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.5.norms.0.weight, bbox_head.transformer.decoder2.layers.5.norms.0.bias, bbox_head.transformer.decoder2.layers.5.norms.1.weight, bbox_head.transformer.decoder2.layers.5.norms.1.bias, bbox_head.transformer.decoder2.layers.5.norms.2.weight, bbox_head.transformer.decoder2.layers.5.norms.2.bias, bbox_head.transformer.decoder2.post_norm.weight, bbox_head.transformer.decoder2.post_norm.bias, bbox_head.rel_query_embed.weight, bbox_head.sub_query_update.0.weight, bbox_head.sub_query_update.0.bias, bbox_head.sub_query_update.2.weight, bbox_head.sub_query_update.2.bias, bbox_head.obj_query_update.0.weight, bbox_head.obj_query_update.0.bias, bbox_head.obj_query_update.2.weight, bbox_head.obj_query_update.2.bias, bbox_head.sop_query_update.0.weight, bbox_head.sop_query_update.0.bias, bbox_head.sop_query_update.2.weight, bbox_head.sop_query_update.2.bias, bbox_head.rel_cls_embed.weight, bbox_head.rel_cls_embed.bias
Could this be the problem? I have not modified any code. @Jingkang50

Hello, have you solved this problem yet？

I found that when loading the DETR pre-trained model “./work_dirs/checkpoints/detr4psgformer_r50.pth” with “psgformer_r50_psg”, there were many missing hints：
missing keys in source state_dict: bbox_head.transformer.decoder2.layers.0.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.0.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.0.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.0.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.0.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.0.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.0.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.0.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.0.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.0.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.0.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.0.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.0.norms.0.weight, bbox_head.transformer.decoder2.layers.0.norms.0.bias, bbox_head.transformer.decoder2.layers.0.norms.1.weight, bbox_head.transformer.decoder2.layers.0.norms.1.bias, bbox_head.transformer.decoder2.layers.0.norms.2.weight, bbox_head.transformer.decoder2.layers.0.norms.2.bias, bbox_head.transformer.decoder2.layers.1.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.1.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.1.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.1.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.1.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.1.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.1.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.1.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.1.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.1.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.1.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.1.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.1.norms.0.weight, bbox_head.transformer.decoder2.layers.1.norms.0.bias, bbox_head.transformer.decoder2.layers.1.norms.1.weight, bbox_head.transformer.decoder2.layers.1.norms.1.bias, bbox_head.transformer.decoder2.layers.1.norms.2.weight, bbox_head.transformer.decoder2.layers.1.norms.2.bias, bbox_head.transformer.decoder2.layers.2.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.2.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.2.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.2.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.2.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.2.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.2.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.2.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.2.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.2.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.2.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.2.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.2.norms.0.weight, bbox_head.transformer.decoder2.layers.2.norms.0.bias, bbox_head.transformer.decoder2.layers.2.norms.1.weight, bbox_head.transformer.decoder2.layers.2.norms.1.bias, bbox_head.transformer.decoder2.layers.2.norms.2.weight, bbox_head.transformer.decoder2.layers.2.norms.2.bias, bbox_head.transformer.decoder2.layers.3.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.3.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.3.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.3.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.3.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.3.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.3.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.3.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.3.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.3.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.3.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.3.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.3.norms.0.weight, bbox_head.transformer.decoder2.layers.3.norms.0.bias, bbox_head.transformer.decoder2.layers.3.norms.1.weight, bbox_head.transformer.decoder2.layers.3.norms.1.bias, bbox_head.transformer.decoder2.layers.3.norms.2.weight, bbox_head.transformer.decoder2.layers.3.norms.2.bias, bbox_head.transformer.decoder2.layers.4.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.4.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.4.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.4.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.4.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.4.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.4.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.4.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.4.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.4.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.4.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.4.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.4.norms.0.weight, bbox_head.transformer.decoder2.layers.4.norms.0.bias, bbox_head.transformer.decoder2.layers.4.norms.1.weight, bbox_head.transformer.decoder2.layers.4.norms.1.bias, bbox_head.transformer.decoder2.layers.4.norms.2.weight, bbox_head.transformer.decoder2.layers.4.norms.2.bias, bbox_head.transformer.decoder2.layers.5.attentions.0.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.5.attentions.0.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.5.attentions.0.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.5.attentions.0.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.5.attentions.1.attn.in_proj_weight, bbox_head.transformer.decoder2.layers.5.attentions.1.attn.in_proj_bias, bbox_head.transformer.decoder2.layers.5.attentions.1.attn.out_proj.weight, bbox_head.transformer.decoder2.layers.5.attentions.1.attn.out_proj.bias, bbox_head.transformer.decoder2.layers.5.ffns.0.layers.0.0.weight, bbox_head.transformer.decoder2.layers.5.ffns.0.layers.0.0.bias, bbox_head.transformer.decoder2.layers.5.ffns.0.layers.1.weight, bbox_head.transformer.decoder2.layers.5.ffns.0.layers.1.bias, bbox_head.transformer.decoder2.layers.5.norms.0.weight, bbox_head.transformer.decoder2.layers.5.norms.0.bias, bbox_head.transformer.decoder2.layers.5.norms.1.weight, bbox_head.transformer.decoder2.layers.5.norms.1.bias, bbox_head.transformer.decoder2.layers.5.norms.2.weight, bbox_head.transformer.decoder2.layers.5.norms.2.bias, bbox_head.transformer.decoder2.post_norm.weight, bbox_head.transformer.decoder2.post_norm.bias, bbox_head.rel_query_embed.weight, bbox_head.sub_query_update.0.weight, bbox_head.sub_query_update.0.bias, bbox_head.sub_query_update.2.weight, bbox_head.sub_query_update.2.bias, bbox_head.obj_query_update.0.weight, bbox_head.obj_query_update.0.bias, bbox_head.obj_query_update.2.weight, bbox_head.obj_query_update.2.bias, bbox_head.sop_query_update.0.weight, bbox_head.sop_query_update.0.bias, bbox_head.sop_query_update.2.weight, bbox_head.sop_query_update.2.bias, bbox_head.rel_cls_embed.weight, bbox_head.rel_cls_embed.bias
Could this be the problem? I have not modified any code. @Jingkang50

Hello, have you solved this problem yet？

Hello, have you solved this problem yet？ I aslo meet the problem


Spawn example crashes on Intel Mac

As of commit ca6d4a03ccd8cb50bc6d7851fd7f80362fc24a3d, the spawn example panics in the wgpu backend on a 2019 Intel MacBook Pro with Radeon 5500M graphics.
The following error is printed by the panic message:
wgpu error: Validation Error

Caused by:
    In a ComputePass
      note: encoder = `<CommandBuffer-(0, 1, Metal)>`
    In a set_bind_group command
      note: bind group = `particles_spawner_bind_group`
    dynamic binding at index 0: offset 576 does not respect device's requested `min_storage_buffer_offset_alignment` limit 256

This panic further results in a failed assertion in the Metal layer (because the command encoder is prematurely released) which triggers an Apple crash report dialogue.
I haven't yet had the chance to check how the example behaves on other Apple hardware or OS versions.

Discussed on Discord here.

Fixed. Also added some code in the spawn example to force aligning to 256 bytes to test that codepath. Other examples are left untouched.


Crash when surface is small

Hello, thank you for this lib. I discovered that my app sometimes crashes without logs. And now I found, that in some places my templates were not optimal and sometimes layout is wrong. It crashes when passed width/height for surface is, for example, 300x4.
                <Surface
                    style={{
                        height: size.height,
                        width: size.width,
                    }}
                >
                    <Blurhash hash={blurhash} />
                </Surface>

So I found that when surface size is calculated in runtime (inside onLayout, for example), sometimes when size is not yet set and is zero, it's also crash

@schiller-manuel There are no logs, I'm testing it only on ios and it crashes silently :( I didn't try to put something else into Surface


Add logging

This PR introduces code to enable logging in the jwst_reffiles package. Currently logging covers only mkrefs.py, mkref.py, and pipeline/calib_prep,.py. Logging for modules that will be plugged in will be captured in different files. The names of these files are present in the log file created by these code changes.
I have added the minimum logging level for 1) the output log file and 2) messages to the screen, as user inputs. This way users can customize the logs without having to update the code itself. Both parameters default to using INFO as the minimum log level. Options are 'critical', 'warning', 'info',' and 'debug'.
To set the levels:
mkrefs.py -vvv --cfgfile mkrefs.cfg example_readnoise_module My_dir/darks/*DARK-600*level1b_Sept2018_uncal.fits My_dir/A1/F150W2/NRCN815A-LIN-53650[5678]*uncal.fits --logFileLevel info --logScreenLevel warning
The output log file is written to a directory specified by the runID, and includes a timestamp in the filename, for uniqueness.

@bsunnquist or @aliciacanipe, do you have a few minutes to test this at some point? I think a successful test would be that a logfile is created and that it's populated with messages of the appropriate severity level. And that the permissions are such that the logfile is world readable.
To call, use the same command that you have used in the past, but tack on two more keywords:
--logFileLevel info --logScreenLevel warning. The values of the keywords are the minimum severity levels that should appear in the log file and on the screen, respectively. Allowed values are 'debug', 'info', 'warning', 'error', and 'critical'. (I don't think i have any critical messages in the code.)

I should be able to test this later this week

I tried running this, but received an AttributeError: 'mkrefsclass' object has no attribute 'logger' (see attached). I'm using an old cfg file - do these have to be updated with more information for these new logging features to work?

That fixed it, but now I'm receiving a permission error (see attached). I'm running in the wit shared central storage directory, and I think you're running on your computer, so maybe that's the issue?

Here are what the permissions look like on the file:

Hmmm, I was afraid of this. Right now I have permissions being set such that the log file is readable and writable by the owner and the group. But when I ran tests, the files I created were under the 'staff' group. It looks like yours are under STSCI/wit. Maybe I should just open up permissions to make the files readable and writable by everyone. Eventually lots of people could  be using this package, and I have no idea what other groups could be used.

OK, now the log files should be writable.

Yeah, there are a lot of groups, so that makes sense. Just ran it again and got this attribute error:

Oops. I forgot to prepend an 'S_' to those. I just pushed an updated copy.

Getting that same permission error again, looks like the permissions haven't changed on that file

Ah, wait, I started fresh (deleted the test1 directory), and the log files permissions changed correctly (read and write for everyone), but I still got this error

Looks like it doesn't want to let you change the group associated with the file. I'll have to think about why that might be.

Thinking about it last night, it seems like setting all files to have the same Unix group doesn't really help us much. So I turned off that command entirely. I switched the default permissions such that any files you create should be readable and writable by you, and group readable.

Looks good! I just re-ran with --logFileLevel info and the log file is generated with INFO, WARNING, and ERROR entries (see attached). There are some warnings/errors in there e.g. "ERROR - WARNING: It seems like the filename...is not a fits file" and "WARNING - ERROR: file...did not get created with strun command!". Though the output readnoise fits files look good, and the log file permissions are correct (rw for me, r for group, no access for everyone else).
mkrefs_2019-02-28-14-46.log

Excellent thanks! I clarified those ERROR - WARNING and WARNING - ERROR messages. Do you think this is ready to merge?


[OSD-20017] create config file with login --multi even if target config file exists

What type of PR is this?
bug
What this PR does / Why we need it?
Without this change, when using login --multi on a cluster where we already did it, but where credentials expired, the connection will not work.
Which Jira/Github issue(s) does this PR fix?
Resolves #OSD-20017
Special notes for your reviewer
Pre-checks (if applicable)

[ x] Ran unit tests locally
[ x] Validated the changes in a cluster
[na ] Included documentation changes with PR

Codecov Report
Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (d797914) 45.93% compared to head (b7342dc) 45.90%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #301      +/-   ##
==========================================
- Coverage   45.93%   45.90%   -0.03%
==========================================
  Files          53       53
  Lines        3753     3751       -2
==========================================
- Hits         1724     1722       -2
  Misses       1754     1754
  Partials      275      275

Files
Coverage Δ

pkg/login/kubeConfig.go
58.06% <33.33%> (-1.32%)
:arrow_down:

Also, given the changes made to the CreateClusterKubeConfig function that it now overwrites the kubeconfig file each time it is called, rather than only creating it if it doesn't exist, we might need to update test cases accordingly.
Apart from that, LGTM, great work @Tof1973 :+1:

Cannot understand why it has to check the file existence before writing... cc @samanthajayasinghe please let me know if there is a reason
/lgtm
/label tide/merge-method-squash


unhandledRejection: Error: NEXT_NOT_FOUND on terminal after running npm run dev

Description
Unfortunately I can't add a reproduction repository, but I'll try to describe what happens. After starting the application there are many errors in the terminal. They do not affect the work of the application in any way. I just wonder what they are related to?
Verifications

[X] I've verified that the problem I'm experiencing isn't covered in the docs.
[X] I've searched for similar, existing issues on GitHub and Stack Overflow.
[X] I've compared my app to a working example to look for differences.

Mandatory reproduction URL
I'm using App Router
Reproduction description
Steps to reproduce:

npm run dev
open terminal
there is tones of unhandledRejection: Error: NEXT_NOT_FOUND

Expected behaviour
Here is repeated errors messages i see on terminal after running npm run dev
 ⨯ node_modules/next/dist/client/components/not-found.js (26:18) @ notFound
 ⨯ unhandledRejection: Error: NEXT_NOT_FOUND
    at notFound (webpack-internal:///(rsc)/./node_modules/next/dist/client/components/not-found.js:23:19)
    at eval (webpack-internal:///(rsc)/./node_modules/next-intl/dist/esm/server/react-server/RequestLocale.js:24:74)
    at /PROJECT/URL/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:360290
    at a (webpack-internal:///(rsc)/./node_modules/next-intl/dist/esm/server/react-server/RequestLocale.js:35:26)
    at o (webpack-internal:///(rsc)/./node_modules/next-intl/dist/esm/server/react-server/getLocale.js:8:95)
    at eval (webpack-internal:///(rsc)/./node_modules/next-intl/dist/esm/server/react-server/getTranslations.js:19:147)
    at /PROJECT/URL/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:360290
    at Module.generateMetadata (webpack-internal:///(rsc)/./src/app/[locale]/layout.tsx:24:81)
    at /PROJECT/URL/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:405577
    at /PROJECT/URL/node_modules/next/dist/server/lib/trace/tracer.js:133:36
    at NoopContextManager.with (/PROJECT/URL/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:7062)
    at ContextAPI.with (/PROJECT/URL/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:518)
    at NoopTracer.startActiveSpan (/PROJECT/URL/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:18093)
    at ProxyTracer.startActiveSpan (/PROJECT/URL/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:18854)
    at /PROJECT/URL/node_modules/next/dist/server/lib/trace/tracer.js:122:103
    at NoopContextManager.with (/PROJECT/URL/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:7062)
    at ContextAPI.with (/PROJECT/URL/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:518)
    at NextTracerImpl.trace (/PROJECT/URL/node_modules/next/dist/server/lib/trace/tracer.js:122:28)
    at /PROJECT/URL/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:405484
    at /PROJECT/URL/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:407498
    at ta (/PROJECT/URL/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:407530)
    at ti (/PROJECT/URL/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:407932)
    at runNextTicks (node:internal/process/task_queues:60:5)
    at listOnTimeout (node:internal/timers:540:9)
    at process.processTimers (node:internal/timers:514:7)
    at async tl (/PROJECT/URL/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:36:2223)
    at async /PROJECT/URL/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:36:2596 {
  digest: 'NEXT_NOT_FOUND'
}
null

Thanks in advance

A reproduction would be important to look into this, but based on the stack trace, it could be that your error is caused by this misconfiguration: Unable to find locale. You should see an error message pointing towards this on the console though.

I also currently can't provide a lot of information but we just had to hotfix rollback next-intl from 3.14.0 to 3.13.0 as a big part of our app (NextJS, App Router, RSC, TRPC) was completely broken:
a [TRPCClientError]: Suspense Exception: This is not a real error! It's an implementation detail of `use` to interrupt the current render. You must either rethrow it immediately, or move the `use` call outside of the `try/catch` block. Capturing without rethrowing will lead to unexpected behavior.

To handle async errors, wrap your component in an error boundary, or call the promise's `.catch` method and pass the result to `use`
    at a.from (/var/task/apps/web/.next/server/chunks/8292.js:1:1194)
    at /var/task/apps/web/.next/server/chunks/8292.js:5:1545 {
  meta: undefined,
  shape: undefined,
  data: undefined,
  digest: '3877659871',
  [cause]: Error: Suspense Exception: This is not a real error! It's an implementation detail of `use` to interrupt the current render. You must either rethrow it immediately, or move the `use` call outside of the `try/catch` block. Capturing without rethrowing will lead to unexpected behavior.

We've never had this issue before.
Rolling back to 3.13 fixed it immediately. (the only change we commited which fixed the issue)
Might me able to provide more information after Tuesday.

Interesting. If you could provide some more information or ideally a reproduction, that would be helpful.
There was another report about 13.14, we were able to resolve that: https://github.com/amannn/next-intl/issues/1072

I can't provide a full reproducable example but maybe an excerpt of the code might help to show what we're using:
import { notFound, redirect, RedirectType } from "next/navigation";
import { TRPCClientError } from "@trpc/client";
import { TRPCError } from "@trpc/server";
import { getTranslations } from "next-intl/server";

import { api } from "~/trpc/server";

async function getData(id: string) {
  try {
    return await api.getData.query({
      id,
    });
  } catch (error) {
    if (error instanceof TRPCClientError) {
      const errorCode =
        error.cause instanceof TRPCError ? error.cause.code : "UNKNOWN";
      if (errorCode === "BAD_REQUEST" || errorCode === "NOT_FOUND") {
        notFound();
      }
    }
    throw error;
  }
}

export default async function Page({
  params,
}: {
  params: { id: string };
}) {
  const { id } = params;
  const data = await getData(id);

  if (data.isComplete) {
    redirect("/different/path", RedirectType.replace);
  }

  const t = await getTranslations();

  return <div>// ... component that uses t</div>;
}

As I said, this code never resulted in any problems before upgrading to 3.14

I don't see an issue with that code. Can you try to isolate the issue to a particular line that causes the issue? Can you also post your i18n.ts?

@amannn We figured it out: We called useLocale in serverside code which - for some reason - used to work fine before 3.14 but now throws an error. Now everything works fine again.

@ilikali Were you able to figure out a solution eventually?
"default" is in any case not a valid locale. The locale is not only used for reading messages, but also for formatting dates, etc.
I'm wondering why you have to do these gymnastics in the middleware? It seems like what you need is localePrefix: 'as-necessary', why can't you declare the two locales your app supports in the regular way, as it's shown in the docs and examples?

@amannn I’ll try to explain why I’m facing such a dilemma. The fact is that my website uses two locales: Azerbaijani and Russian. However, the site also has pages that start with "/az", meaning "/az/[slug]" - where "az" is not a locale in the URL of the page. Therefore, I had to rename the "az" locale to "default", and then use code to check if the "default" locale is selected to simulate a call to the "az" locale. I understand this sounds very complex, but these are the realities of my project.

Uh, that really asks for trouble. As mentioned above, "default" is not a valid locale and you should really use az or ru to initialize APIs from next-intl. I'd in any case use localePrefix: 'always' as this allows for pathnames like /az/az in your case, where it's clear what the locale and what the path is.
I'll close this issue for the time being, as this isn't a bug report but rather a usage question and also no reproduction was provided that shows a bug in next-intl.


Feature Request - include full chat session URL in notes created during import

Description
When a new note is created via the import, Nexus records the conversation_id in the YAML, but it would be also useful for a full URL to be generated with https://chatgpt.com/c/conversation_id within the note itself (outside YAML).
Use case
With a clickable URL, the user could easily open the ChatGPT conversation and continue with additional queries from that same session without having to copy/paste the  conversation_id onto the https://chatgpt.com part of the URL.

Hi.
I realize this is missing in the documentation, but you can click the
document title, it will open the conversation in your browser.
Obviously it requires your browser to have a session with your ChatGPT
account.
Try it.
I will update the documentation to clarify this point.
Le 2024-10-21T12:14:23.000+02:00, oktavius_k
@.***> a écrit :

DESCRIPTION
  When a new note is created via the import, Nexus records the
 conversation_id in the YAML, but it would be also useful for a full
 URL to be generated with https://chatgpt.com/c/conversation_id
 within the note itself (outside YAML).

  USE CASE
  With a clickable URL, the user could easily open the ChatGPT
 conversation and continue with additional queries from that same
 session without having to copy/paste the conversation_id onto the
 https://chatgpt.com part of the URL.

 —
 Reply to this email directly, view it on GitHub
 [https://github.com/Superkikim/nexus-ai-chat-importer/issues/9], or
 unsubscribe
 [https://github.com/notifications/unsubscribe-auth/ACM7BZJPTKJJFBVGYAURFWLZ4THX7AVCNFSM6AAAAABQJZX6ZCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYYDEMBVGMYDMNQ].
 You are receiving this because you are subscribed to this
 thread.Message ID:
@.***>

Yes, it worked! Nice feature.

Glad you like it.
Documentation has been updated. Closing this issue.


Redesign

you don't have to use this if you don't want to
i was just bored

oshit https://i.bread.moe/9jrab.png


Repo sync for protected CLA branch

The pull request is created from master637733760362028046 to master to fix git push error for protected CLA branch

@opbld17 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Fix releasing.md font

Signed-off-by: jwcesign<EMAIL_ADDRESS>What type of PR is this?
/kind cleanup

What this PR does / why we need it:

Fix releasing.md font

Which issue(s) this PR fixes:
Fixes #none
Special notes for your reviewer:

Before:

After:

cc @RainbowMango


I want to run this locally with my LLM, such as Ollama.

I want to be able to run this application locally with my LLM, such as Ollama.
The application now requires openai.api.key in LangChain4jConfig. No way to skip the langchain4j-openai creation or provide an alternative langchain4j-ollama
In Spring AI it's easy to use just a different starter and app works without the change.
spring-ai-ollama-spring-boot-starter instead of spring-ai-openai-spring-boot-starter

Fair point. The intent of the project was to show how the different libraries compare, so I haven't focused too much on making it easy to change models, so like you said, you'd need to do code changes in the LangChain4j example if you want to use ollama.
Need to look into it. Do you have ideas on how we could make the langchain code support easier swapping of LLMs?

I think the easiest way to do it would be swapping spring profiles (Ex: "open-ai", "ollama"). Default could be "open-ai"

@nevenc  just FYI we just added a Quarkus version on the quarkus branch and you can do exactly what you're looking to do.
The README describes how to do that.


new feature: Add is_current for Metadata

Feature Description
I propose to add is_current_version: bool in Metadata to allow users to different if this version the latest version of file.
Problem and Solution
Metadata now contains version for the given file, but there is no way for users to different if this version the latest version of file.
Additional Context
No response
Are you willing to contribute to the development of this feature?

[ ] Yes, I am willing to contribute to the development of this feature.

All services that support version will also support is_current_version, so there's no need to add a new capability for this. This will be a simple feature to implement.

Hi, I'm willing to solve this issue.

Hi, @Wenbin1002, thank you in advance. I have assigned this issue to you, enjoy it!

Do you have any additional information? This is my first time contributing to a Rust project, and I’ve only briefly glanced at the code. It seems like I just need to add a field to the metadata, implement the corresponding setter and getter functions, and initialize it correctly. By the way, should is_current_version use bool or Option<bool>?

It seems like I just need to add a field to the metadata, implement the corresponding setter and getter functions, and initialize it correctly.

Yep!

By the way, should is_current_version use bool or Option?

Using bool is fine with me, but this question inspired me to consider that is_current_version might not be the best name, maybe we can just use is_current.

Using bool might not be a good idea. How do we set the default value ? In most cases, true would be appropriate, but what happens when performing a stat operation with a special version ?

Using bool might not be a good idea. How do we set the default value ? In most cases, true would be appropriate, but what happens when performing a stat operation with a specific version ?

Nice question. I checked the docs for AWS S3 and found that there is no way to know if the given version id is current or not.
So it's better for us to use Option<bool> here with None as default.

For HeadObject without version_id, we will set it to Some(true).
For HeadObject with version_id, we will set it to None.
For ListObjects, we will set all keys to Some(ture)
For ListObjectVersions, we will decided the value based on IsLatest.


list of buckets appear at top of page, instead of on their own page.

Request: Bring the bucket list to the top of the page, as it was before.
Short description:

Current state:

a list of five buckets are on an unstyled starting page.

Desired state:

This list matches the look from  before re-architecture, where they were in styled boxes at top of page.

Tasks:

[ ] Bring routing omponent from client.org back to app.org
[ ] Display it based on our bucketlist bundle instead of possible routes.
[ ] clicking on the bucket updates the query param for bucket, and triggers a refresh.
[ ] there is a loading state inbetween switches, as data repopulates.

implemented in fefa566b7108b5cbaf02aca4bb162438b80f0da0 and part of #181


chore: add plugin request issue template

Which problem is this PR solving?

Updates #406

Codecov Report

Merging #407 into master will increase coverage by 0.32%.
The diff coverage is n/a.


⚠ Bofrost.lu has degraded performance

In 2de90c2, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1710 ms

Resolved: Bofrost.lu performance has improved in 6140f5e after 13 minutes.


On OpenShift, the broker secret isn’t always available

At least in the gateway pods, the broker secret is mounted but is sometimes empty, which prevents the syncer from connecting to the broker. The cluster eventually recovers, when a gateway restarts and grabs the secret.

@skitt my understanding is that submariner-io/admiral#330 reduces the impact of this issue, but do you have an idea of what else should be done? should we track it separately or keep this issue open?

I want to keep this open, because the Admiral fix reduces the impact but doesn’t fix everything. I’m investigating the token rotation which seems to be causing problems with OpenShift, at least in 4.9; I haven’t seen the issue in 4.10 so things might have changed there.


cluster SCAN - provide a per node function to execute?

In relation to #7
I wonder would a good enhancement be to create a version of scan_iter that receives a callback function instead of a loop.
The callback function would have a signature async def cb(node, key)
This way you could execute commands on the key directly against the correct node, and also in parallel across nodes (but sequentially on a single node).
I think we'd need a better interface than cx.execute_command_on_nodes([node]... though for this to be comfortable (I don't even know if that's possible to call externally?)
Thoughts?
Would it need a different name from scan_iter or should it just accept a new callback parameter?

Hmm, what's the use-case here? eg. what sort of commands would you envision wanting to provide via callback?
Initially, this sounds orthogonal to the scan_iter command entirely -- this sounds more like just providing a general way to "run arbitrary method on each node"?

Run an arbitrary method on each node against a particular key that lives on that node...
I've been running something like this for a while now in production and it has provided very good speedups.
Use cases:

find out the memory usage of each key that you are scanning
peek streams to determine whether they need further processing

These all benefit from the parallel execution of the follow-up command.  I dunno how much benefit is derived from executing the command directly against the correct cluster node, but I reckon it isn't hurting.


Reverse Tunneling enabled by the container

Before you start please confirm the following.

[X] Yes, I've searched similar issues on GitHub.
[X] Yes, I've checked whether this issue is covered in the Portainer documentation or knowledge base.

Problem Description
I'm seeing high and unusual traffic from the Portainer container and seeing this on the logs:
2023/07/27 02:50PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:766 > starting Portainer | build_number=32198 go_version=1.19.4 image_tag=linux-amd64-2.18.4 nodejs_version=18.16.1 version=2.18.4 webpack_version=5.68.0 yarn_version=1.22.19
2023/07/27 02:50PM INF github.com/portainer/portainer/api/http/server.go:345 > starting HTTPS server | bind_address=:9443
2023/07/27 02:50PM INF github.com/portainer/portainer/api/http/server.go:330 > starting HTTP server | bind_address=:9000
2023/07/31 02:54AM INF github.com/portainer/portainer/api/cmd/portainer/main.go:495 > encryption key file not present | filename=portainer
2023/07/31 02:54AM INF github.com/portainer/portainer/api/cmd/portainer/main.go:518 > proceeding without encryption key |
2023/07/31 02:54AM INF github.com/portainer/portainer/api/database/boltdb/db.go:124 > loading PortainerDB | filename=portainer.db
2023/07/31 02:54:33 server: Reverse tunnelling enabled
2023/07/31 02:54:33 server: Fingerprint 2f:5f:cf:c5:02:cc:ce:75:b3:91:44:94:5c:fc:f5:8c
2023/07/31 02:54:33 server: Listening on <IP_ADDRESS>:8000...

It makes no sense why Portainer would enable a Reverse Tunnel into the port 8000.
Expected Behavior
Don't allowing Reverse Tunneling.
Actual Behavior
Portainer allowed a 3rd party to open a reverse tunneling into my container.
Steps to Reproduce
1.- Install Portainer.
2.- Define a secure password generated by password generator.
Portainer logs or screenshots

Portainer version
2.18.4
Portainer Edition
Community Edition (CE)
Platform and Version
Docker 24.0.5
OS and Architecture
Debian 10
Browser
No response
What command did you use to deploy Portainer?
I used Ansible with the following Playbook:
---
- name: Update Portainer
  hosts: Docker6
  remote_user: root
  gather_facts: no
  vars:
    ansible_python_interpreter: /usr/bin/python3
  tasks:
    - name: Re-create Portainer-CE container
      docker_container:
        name: Portainer
        image: portainer/portainer-ce:latest
        state: started
        pull: true
        recreate: yes
        restart_policy: unless-stopped
        volumes:
          - Portainer:/data
          - /var/run/docker.sock:/var/run/docker.sock
        env:
          VIRTUAL_HOST=
          LETSENCRYPT_HOST=
          VIRTUAL_PORT=9000
        networks:
          - name: Main
    - name: Cleanup dangling images
      shell: |
        oldimage=`docker images | grep '<none>' | awk '{print $3}'`
        if [ -z "$oldimage" ]
        then
        echo "There is no dangling images found!"
        else
        docker rmi ${oldimage} -f
        fi
      ignore_errors: yes

Additional Information
No response

After some reviews I'm seeing that the tunneling is expected as the documentation states on https://docs.portainer.io/start/install/server/docker/linux:

By default, Portainer Server will expose the UI over port 9443 and expose a TCP tunnel server over port 8000. The latter is optional and is only required if you plan to use the Edge compute features with Edge agents.

I'm still concerned about some logs after the last posted originally:
{"log":"2023/07/31 02:54AM INF github.com/portainer/portainer/api/cmd/portainer/main.go:766 \u003e starting Portainer | build_number=32198 go_version=1.19.4 image_tag=linux-amd64-2.18.4 nodejs_version=18.16.1 version=2.18.4 webpack_version=5.68.0 yarn_version=1.22.19\n","stream":"stderr","time":"2023-07-31T02:54:33.281418176Z"}
{"log":"2023/07/31 02:54AM INF github.com/portainer/portainer/api/http/server.go:330 \u003e starting HTTP server | bind_address=:9000\n","stream":"stderr","time":"2023-07-31T02:54:33.575694387Z"}
{"log":"2023/07/31 02:54AM INF github.com/portainer/portainer/api/http/server.go:345 \u003e starting HTTPS server | bind_address=:9443\n","stream":"stderr","time":"2023-07-31T02:54:33.590126603Z"}
{"log":"{\"time\":1690772338,\"message\":\"http: response.WriteHeader on hijacked connection from github.com/portainer/libhttp/error.writeErrorResponse (error.go:37)\"}\n","stream":"stderr","time":"2023-07-31T02:58:58.029951165Z"}
{"log":"{\"time\":1690772338,\"message\":\"http: response.Write on hijacked connection from encoding/json.(*Encoder).Encode (stream.go:231)\"}\n","stream":"stderr","time":"2023-07-31T02:58:58.030034626Z"}

Ensure you close any ports your not using for inbound/ingress traffic, to avoid any security issues with ports that Portainer may open on the server instance


[T2A6][T01-T3]Yogamurti Sutanto

Ready for review

@yogamurti Some comments added. Please close the PR after reading comments.


vscode install C# Extension error

Environment data
dotnet --info output:
.NET Core SDK (reflecting any global.json):
Version:   3.0.100
Commit:    04339c3a26
Runtime Environment:
OS Name:     Mac OS X
OS Version:  10.14
OS Platform: Darwin
RID:         osx.10.14-x64
Base Path:   /usr/local/share/dotnet/sdk/3.0.100/
Host (useful for support):
Version: 3.0.0
Commit:  7d57652f33
.NET Core SDKs installed:
3.0.100 [/usr/local/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
VS Code version:
1.38.1
C# Extension version:
1.21.3
Steps to reproduce
open project show message
The .NET Core SDK cannot be located. .NET Core debugging will not be enabled. Make sure the .NET Core SDK is installed and is on the path.
AND
Some projects have trouble loading. Please review the output for more details.
Expected  behavior
Actual behavior

This is duplicate of https://github.com/OmniSharp/omnisharp-vscode/issues/3290, please update the extension to 1.21.4 which was released today.

uddate the extension to 1.21.4，but have same question

This is duplicate of #3290, please update the extension to 1.21.4 which was released today.

update the extension to 1.21.4，but have same question

hi,
Same situation here. I just installed extension version 1.21.7 and getting same error.
On VSCode, in a terminal, I'm able to execute this:
$ dotnet --version
3.0.100

But VSCode is not able to find .Net Core 3.0 SDK
My info:
$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.14
 OS Platform: Darwin
 RID:         osx.10.14-x64
 Base Path:   /usr/local/share/dotnet/sdk/3.0.100/

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  3.0.100 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

I have the same set up and issue as gpalazuelosg.  Is there any visibility into this issue and when it might be rectified?


refactor(aws-ecs): rename NamespaceOptions to CloudMapNamespaceOptions

Rename NamespaceOptions to CloudMapNamespaceOptions.
BREAKING CHANGE: Renamed NamespaceOptions to CloudMapNamespaceOptions.

Please read the contribution guidelines and follow the pull-request checklist.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@eladb @rix0rrr please merge


Is this ready for production?

Hi!
This project looks really nice, and it's nice to see that it's backed by Facebook. That said, how production ready is this project? What kind of performance can you expect from the server rendering compared to Razor?
Any examples of sites that use it? Is it used internally at Facebook?

It's not used internally at Facebook, it was mainly a side project for me. I have one page on my site powered by it (http://dan.cx/socialfeed.htm). I know there's a few other people that use it in production but I can't remember the sites at the moment.
Server-side rendering performance should be pretty good if you use the JS engine pooling (which is enabled by default).

Thanks for answering, much appreciated!
Have you done any benchmarks on the difference between rendering the same type of content with Razor and React?
In your own view, would you be comfortable using this for a business critical site with moderate to heavy load?

Btw, didn't mean to throw you a curve ball question about your project like that. I have every intention to research this myself as well (and of course share my findings!).

Here are the results of some early tests. The tests are a bit naive, so take the results for what they are.
I created three projects, one with vanilla MVC and a few Razor views. The second project outputs the exact same thing, but with React.NET instead of Razor. And the third also outputs the same but using React with Node.js.
The test was to send 100 000 requests through Apache Bench to them on my Windows 8 developer machine.
Razor won the tests. Node.js came in at about 50% slower than that, and React.NET at about 800% slower than Razor.
800% might sound like a lot but I'm quite impressed given how little the Razor-project had to do in comparison.

The test was to send 100 000 requests through Apache Bench to them on my Windows 8 developer machine.

It'd be great if you could upload your benchmarking code. ReactJS.NET hasn't been heavily optimised yet so potentially there's some slow code paths that could be improved
Did you have JavaScript engine pooling enabled? It's on by default. How many concurrent requests were you doing? By default there's an upper limit of 25 concurrent JS engines. If you have more than 25 concurrent requests, the request needs to wait in a queue until one of the engines is available.

Have you done any benchmarks on the difference between rendering the same type of content with Razor and React?

I haven't yet.

In your own view, would you be comfortable using this for a business critical site with moderate to heavy load?

Yes, as long as you load test it :)

I didn't change anything, just downloaded through NuGet and ran it. The limit of 25 engine instances should be somewhat responsible of how far behind Razor it was since I set the concurrency to 100 in AB.
I should also say that I installed React.NET in a project that we are going to ship in a few months that performs nowhere near as fast as my Razor example (since it does a lot of "real work" like database calls etc). And when I measured that, React.NET with some componenets rendering server side only slowed down the benchmark by 1/20.
What's your take on https://github.com/Offroadcode/SuperchargedReact.Net? It claims to be faster because it doesn't use an engine pool. To me that sounds like using Node.js without the cluster module. And since the React rendering is syncronous I'm not sure how much you benefit by using just one engine instance.

@andersekdahl we wrote SuperChargedReact off the back of trying to get React.Net in production. During our testing we found V8 was holding on to some unmanaged memory every time we ran the page (due to global vars we had in our JS rather than anything React.NET was doing). We tried digging it to the why and how to fix it (trigger garbage collection basically) but found too many levels of abstraction (all of which are for good reason) for a quick enough turn around for go live so chose to write our own. The outcome of which is SuperChargedReact. Its fast purely because it does away with the idea of handling multiple JS engines so we can tune it to run as fast as possible and leverage all the performance the V8 runtime can give us.
The lessons we learnt we are hoping to feed back into React.NET as time allows as I think its a great project and very noble to try to support so many OS's and its a great body of work.
Regarding the lack of pooling in SuperChargedReact, we us the recommend way of spinning up a new instance of V8 using ClearScripts own tips for performance and its so fast I can't see the benefit to trying to pool it as yet. Its certainly something we could add but in our tests its simply not been needed.
We will be continuing to develop SuperChargedReact for our needs but will be feeding back what we learn into React.NET to make it an even better product than it already is.

@PeteDuncanson Thank you for the clairification! I'll definitely check out SuperChargedReact!

Closing this out since it's just a question, but please feel free to continue the discussion if you like.
@PeteDuncanson I'm still considering dropping JavaScriptEngineSwitcher and depending entirely on V8, which would bring a lot of the benefits of your Supercharged project.

@Daniel15 our first site running on SuperChargedReact goes live today! Will be keeping an eye on it and feeding back. Still keen on doing some PR's with our ideas/changes in for React.Net but go live has gobbled up all my spare CPU cycles :)

Hi @PeteDuncanson - How has Supercharged been working in your live environment? I've just been running a load test with 1000 users for 3 minutes on React.Net, and it seems to get a lot of JSPoolExhaustExceptions. Have you done any load testing with SuperChargedReact?

@yrki

I've just been running a load test with 1000 users for 3 minutes on React.Net, and it seems to get a lot of JSPoolExhaustExceptions.

Default pool size is 10 engines at startup and 25 engines maximum,  to ensure it doesn't consume an excessive amount of memory. That's most likely the bottleneck in your testing. You'll need to increase those for higher concurrency (SetStartEngines and SetMaxEngines in your ReactConfig)

Any news about a real benchmarking between razor, react.net (with different engine configurations and limits) and SuperChargedReact ?

Hi Guys,
We did a lot of performance testing on React.Net which spawned the need for SuperChargedReact but that was nearly 2 years ago. SuperCharged does enough for our needs, sits on 3 servers and is plenty fast enough chewing through 500K of JS running our booking engine for a travel company. We've not touched it for a while simply because its not needed anything doing to it. The docs are certainly limited which we need to work on. Its currently running that site with ReactRouter v1 but with React Router v4 out I want to make some changes there as thats currently a bottle neck for us getting out site upgraded with React.
Thanks to "crazy internet time" that site is already super old at 18 months but all that "old out of date tech" we chose then is still doing an amazing job and now we can start upgrading it all bit by bit.
Some folks have raised some crazy bench marks (as ever) and in those cases I'd suggest folks do their own testing to make sure either solution fits your needs. The up shot is SuperCharged works for our need and our requirements and hasn't given us a hiccup. React.Net is also awesome work (far more supported and documented than ours) so I would include that in any tests you want to do.
Biggest differences between the two solutions are that:

We target only V8 for speed, React.Net has always aimed to be engine agnositic so it can run on anything.
We spin up one engine on start up and then ask that for a new context for ever single request. This is documented as being the fastest way to get a clean instance and the nicest on memory as GC can just throw away the whole engine once done. Its not as fast as having a pool but we found the pools just grew in memory usage in our testing which causes a lot of additional code to manage it and some unexpected results/performance. Throwing it away is a touch slower but pragmatic to debug as "it always works".
Daniel has been supporting, commenting, improving his library the whole time and I can't see that stopping. If you meet him you owe him a beer (I owe him dinner). We are lazy asses and stop once its good enough (which in our case was running a multi-million pound site at "damn thats quick" speeds), simple as that. Our support of SuperCharged up to date has been "flakey" as we are busy either earning money at our day jobs or raising our kids. So currently if you want supported solution Daniel is the best shot.

Any more questions let me know and I try to answer then :)
Cheers
Pete

I hate to resurrect this,  but as it is now 2018 does anyone have any updated figures?

@RichardWright Now there is a more recent discussion.

@Taritsyn thanks


Hide options when selecting by difficulty on mobile

Can't reproduce this bug; I might have fixed it in an earlier commit and forgot to link it here


Switch to functional backend lazily

FIxes #90
After this commit, instead of loading the libraries ahead of usage,
when an arrayfire function is called for first time, a functional
backend is loaded on the fly.

This does not fix #90. Think of this scenario:

You install arrayfire from the installer
You also for some reason have the CUDA toolkit installed on your system
You do not have an NVIDIA GPU available currently

In such a case, the backend that should be picked is either OpenCL or CPU. However the current mechanism picks CUDA, but errors out because the no nvidia gpu is available.
The proper solution would be to call some function (lets say randu) after loading a library to see if it throws an exception. If an exception is throw, continue until a library can both be loaded and randu works.

Okay, i understand what you meant by functional now.


Web socket client not annotated with @ClientEndpoint

Tomcat 9, Java 8, getting the following error
javax.websocket.DeploymentException: Cannot use POJO class [com.github.kklisura.cdt.services.impl.WebSocketServiceImpl$1] as it is not annotated with @ClientEndpoint
at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:122)
at com.github.kklisura.cdt.services.impl.WebSocketServiceImpl.connect(WebSocketServiceImpl.java:86)
at com.github.kklisura.cdt.services.impl.WebSocketServiceImpl.create(WebSocketServiceImpl.java:76)
at com.github.kklisura.cdt.services.impl.ChromeServiceImpl.lambda$new$3(ChromeServiceImpl.java:94)
at com.github.kklisura.cdt.services.impl.ChromeServiceImpl.createDevToolsService(ChromeServiceImpl.java:176)
at com.github.kklisura.cdt.services.impl.ChromeServiceImpl.createDevToolsService(ChromeServiceImpl.java:161)

In com.github.kklisura.cdt.services.impl.WebSocketServiceImpl.connect(WebSocketServiceImpl.java:86), instead of new Endpoint(), creating a CustomClientEndpoint class with @ClientEndpoint annotation and using it in WEB_SOCKET_CONTAINER.connectToServer seems to fix the problem.
// CustomClientEndpoint.java
@ClientEndpoint
public final class CustomClientEndpoint extends Endpoint {
  private static final Logger LOGGER = LoggerFactory.getLogger(CustomClientEndpoint.class);

  public CustomClientEndpoint() {}

  @Override
  public void onOpen(Session session, EndpointConfig config) {
    LOGGER.info("Connected to ws server");
  }
}

// WebSocketServiceImpl.java:86
session = WEB_SOCKET_CONTAINER.connectToServer(
                    CustomClientEndpoint.class,
                    uri);

@kklisura Can you check.

Thanks @clubLowlow for reporting this issue and thanks @hariprasaadssalem for suggesting a fix.  👍 🙏
I was able to fix this and release it as snapshot version, 1.3.1-SNAPSHOT, so you can give it a try before releasing as new version.
<dependency>
  <groupId>com.github.kklisura.cdt</groupId>
  <artifactId>cdt-java-client</artifactId>
  <version>1.3.1-SNAPSHOT</version>
</dependency>

If there's nothing more I'll be releasing this as 1.3.1 in next few days.

@kklisura I validated with 1.3.1-SNAPSHOT... Things are working fine...
Thank you for this wonderful project. :)

Thanks @clubLowlow for reporting this issue and thanks @hariprasaadssalem for suggesting a fix. 👍 🙏
I was able to fix this and release it as snapshot version, 1.3.1-SNAPSHOT, so you can give it a try before releasing as new version.
<dependency>
  <groupId>com.github.kklisura.cdt</groupId>
  <artifactId>cdt-java-client</artifactId>
  <version>1.3.1-SNAPSHOT</version>
</dependency>

If there's nothing more I'll be releasing this as 1.3.1 in next few days.

sorry about that!I can't find the 1.3.1-SNAPSHOT on mvnrepository.Have you released the version?

Thanks @clubLowlow for reporting this issue and thanks @hariprasaadssalem for suggesting a fix. 👍 🙏
I was able to fix this and release it as snapshot version, 1.3.1-SNAPSHOT, so you can give it a try before releasing as new version.
<dependency>
  <groupId>com.github.kklisura.cdt</groupId>
  <artifactId>cdt-java-client</artifactId>
  <version>1.3.1-SNAPSHOT</version>
</dependency>

If there's nothing more I'll be releasing this as 1.3.1 in next few days.

sorry about that!I can't find the 1.3.1-SNAPSHOT on mvnrepository.Have you released the version?

You probably need to add snapshot repository to your pom:
  <repositories>
    <repository>
      <id>snapshots-repo</id>
      <url>https://oss.sonatype.org/content/repositories/snapshots</url>
      <releases><enabled>false</enabled></releases>
      <snapshots><enabled>true</enabled></snapshots>
    </repository>
  </repositories>

in order to fetch a snapshot version.
...or you can wait couple of hours for me to release version 1.3.1. I'll be doing it later tonight.


More control on error messages

Hey,
we are currently doing a pass on our UX for our authentication flow and we would like to customize error messages coming from the API. Currently, if we request a password reset for a unknown email, we get a not-so-human-friendly error "Invalid email.".
Would it be possible to customize such messages? It could be enough for us if we had to provide a "translation" for those and they would be rendered using it. I know we could do it on the template side, but I find this solution not really elegant since it would put too much logic to my taste in the template.

This might be something we want to the SDK and have it supported in the integration


Allow msg Filetype

Hey,
is it possible to allow .msg Files (Saved from Outlook?) or generally own file extensions?
Thank you

Have you tried setting allowedExtensions as indicated in the readme?
allowedExtensions={['jpg', 'jpeg']}