Static Code Analysis can be attempted without selected file

Issue Report Checklist

[x] Searched the issues page for similar reports
[x] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[x] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[ ] Could not reproduce inside jupyter qtconsole (if console-related)
[x] Tried basic troubleshooting (if a bug/error)

[x] Restarted Spyder
[ ] Reset preferences with spyder --reset
[ ] Reinstalled the latest version of Anaconda
[x] Tried the other applicable steps from the Troubleshooting Guide

[x] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
Static code analysis can be attempted when no file is selected and causes an internal error.
What steps reproduce the problem?

Delete pylint.results in spyder-py3, start spyder, run a Static Code Analysis on a file
rename, move or delete the file (which should be the only one listed in the path dropdown)
open an existing .py file in spyder.
restart spyder. The path field in the analysis tab is now cleared but the Analyse Button is now active
click it

What is the expected output? What do you see instead?
The button should not be active. Clicking it should have no effect
Paste Traceback/Error Below (if applicable)

Traceback (most recent call last):
  File "/usr/lib64/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/leo/.local/lib/python3.6/site-packages/pylint/__main__.py", line 7, in <module>
    pylint.run_pylint()
  File "/home/leo/.local/lib/python3.6/site-packages/pylint/__init__.py", line 19, in run_pylint
    Run(sys.argv[1:])
  File "/home/leo/.local/lib/python3.6/site-packages/pylint/lint.py", line 1394, in __init__
    linter.check(args)
  File "/home/leo/.local/lib/python3.6/site-packages/pylint/lint.py", line 801, in check
    self._do_check(files_or_modules)
  File "/home/leo/.local/lib/python3.6/site-packages/pylint/lint.py", line 920, in _do_check
    for descr in self.expand_files(files_or_modules):
  File "/home/leo/.local/lib/python3.6/site-packages/pylint/lint.py", line 959, in expand_files
    self.add_message(key, args=message)
  File "/home/leo/.local/lib/python3.6/site-packages/pylint/utils.py", line 449, in add_message
    self.stats['by_module'][self.current_name][msg_cat] += 1
KeyError: None

Versions

Spyder version: 3.3.3
Python version: 3.6.8
Qt version: -
PyQt version: -
Operating System name/version: Fedora 28 64-Bit

Dependencies

IPython >=4.0     :  6.4.0 (OK)
cython >=0.21     :  None (NOK)
jedi >=0.9.0      :  0.12.1 (OK)
matplotlib >=2.0.0:  2.2.3 (OK)
nbconvert >=4.0   :  5.3.1 (OK)
numpy >=1.7       :  1.14.5 (OK)
pandas >=0.13.1   :  0.22.0 (OK)
psutil >=0.3      :  5.4.3 (OK)
pycodestyle >=2.3 :  2.3.1 (OK)
pyflakes >=0.6.0  :  1.6.0 (OK)
pygments >=2.0    :  2.2.0 (OK)
pylint >=0.25     :  1.7.5 (OK)
qtconsole >=4.2.0 :  4.3.1 (OK)
rope >=0.9.4      :  0.11.0 (OK)
sphinx >=0.6.6    :  1.7.5 (OK)
sympy >=0.7.3     :  None (NOK)

Thanks for reporting. We'll fix this in our next version.

@definite-purple By "no selected file", do you mean no files open the Editor? Pretty much every command breaks in that instances rather than disabling itself; I thought our approach was just to ensure there is always an open file in the Editor by opening a new untitledN one if the user closes everything.

No. The static code analysis tab has this selector dropdown thing, and i meant that no file path is shown in there.
At least one code file is always open on the editor when reproducing the error

Thanks for clarifying!

@dalthviz, please take a look at this one.


Repo settings

I've enabled protected settings for the main branch. Non-admins can't push commits the main branch anymore, they're required to send a pull request.
Do we want to enable Discussions and/or Sponsorships @crftwrk?

Good, thank you!
Yes, I'm fine to enable Discussions and Sponsorship. But I'm not sure if we can find someone who wants to sponsor this tiny project, but let's try.

Been thinking about this for a while.
Setting up the sponsor page is a bit more than I thought and we should do this carefully to get the chance to catch real sponsors. We also have to think about how the money should then be shared.
The discussions are a community and we need users to get this alive.
Later this year, I would like to remove all free products from the shop, add new paid child-themes there and provide direct download links for the free products instead. Because there are too much orders every day and database gets crowded.
This seems to be a good point for me to open the sponsors and discussions and inform users by blog and newsletter. Is this an idea?

Yeah, I agree. I also paused setting up the sponsor page simply because it had too many inputs of which I didn't know what to do with them.
Removing the free products could be a good plan, especially if you're getting sick of too many free orders.

Yeah I second this thought it cool at first having the theme and child theme as downloadable items on the account on your website.  But would make sense to have direct links to the packages.
I've seen some other developers just point people to their github and ask them to download the latest release package.

Completely fine by me, otherwise we may make too many changes all at once. Let's indeed focus on the discussions and direct downloads.

I guess for sponsorship, sponsors want something for their money.  So like you say you 'need to get give a clear picture of the benefit to the sponsor'
Promotion around core benefits bootscore

Easy of use
Solid
Bootstrap latest version
Great plugins
Support
WordPress
Fast
Developer and Scaling safe
etc etc

I guess you'll looking for companies who then will use the product in the long term for their web developments and want to sponsor the maintenance and evolution of the product.
Suppose you got to take off the developer hat and put on the marketer and salesman hat.  Build the brand and sell the concept of premium developer-centric theme, that is going to save a massive amount of time at project intiation and is going to be a solid foundation and platform to build off like other:

Astra
Genesis
Elementor - Hello Theme  (not so much this because it's tied to a pagebuilder product)
Divi
StoreFront
OceanWP

Here we go:

https://bootscore.me/#download
https://bootscore.me/blog/news/final-move-to-github/

I visited the download page just now, and maybe it's a nice idea to add a small GitHub button after each theme and plugin that's on here? Can't remember the layout on pc that quickly, but on mobile having a small button right from the download button would be a nice addition.

https://github.com/sponsors/bootscore


Feature/registering users

It needs to be outside of the login form for my implementation to function correctly

It's unnecessary to log in at all only to have the browser logout. This should be prevented on the server

I'm not sure how to do that with the forms as they are now. So if you can do it then cool, otherwise we can leave it as I have it right now.


Add back link to list of bindings from FAQ

I haven't used Hugo in many years, and there might be a smarter way, but I added something to make home page sections link-able
Addresses already-closed issue https://github.com/prql/prql/issues/818

Thanks a lot @mklopets !


No demo?

In the docs page, demo for group links to panel, http://expandjs.com/demo/mat-panel

Thanks and sorry for the delay.
For the moment we have removed the demo link to not create further confusion. We will put it back soon, once we create a demo for it.


Fix/make helm and kustomize consistent

Why are these changes needed?

In https://anyscale-ray--49085.com.readthedocs.build/en/49085/cluster/kubernetes/getting-started/raycluster-quick-start.html some instructions in helm part are not consistent with Kustomize part.
To make them consistent for a better user experience.
Related doc PR: https://github.com/ray-project/ray/pull/49167
Executing the Kustomize instructions get results as follow:
kubectl get pods

kubectl get rayclusters

kubectl get pods --selector=ray.io/cluster=raycluster-kuberay

Related issue number

Closes https://github.com/ray-project/kuberay/issues/2616
Checks

[ ] I've made sure the tests are passing.
Testing Strategy

[ ] Unit tests
[ ] Manual tests
[ ] This PR is not tested :(

@kevin85421 PTAL


Configuration is clumsy

The only way to activate the block ignores or change stuff like raycast count and whether to show particles is by using scoreboard commands directly. I want to make an UI for it, probably using an interactive /tellraw.

May eventually implement this into Retina v2.


lstsq is inaccurate

jax.numpy.linalg.lstsq seems to be much less accurate than numpy.linalg.lstsq. I was trying to implement a random perspective transform inspired by torchvision. One of the steps is to find a least-squares solution of a @ x = b.
Both in NumPy and PyTorch (using the right args), I am able to get a sufficiently-accurate answer. However, the results from JAX are unusable for me. Here is a specific example that I was trying to solve:
import numpy as np
import jax.numpy as jp

# data
a = jp.array([[122, 1141, 1, 0, 0, 0, 0, 0],
              [0, 0, 0, 122, 1141, 1, -156536, -1459977],
              [686, 1209, 1, 0, 0, 0, -493286, -869838],
              [0, 0, 0, 686, 1209, 1, -877486, -1547319],
              [626, 2, 1, 0, 0, 0, -450148, -1812],
              [0, 0, 0, 626, 2, 1, 0, 0],
              [23, 339, 1, 0, 0, 0, 0, 0],
              [0, 0, 0, 23, 339, 1, 0, 0]], dtype=jp.float32)
b = jp.array([0, 1279, 719, 1279, 719, 0, 0, 0], dtype=jp.float32)

# numpy
x = np.linalg.lstsq(a, b, rcond=None)[0]
print(np.abs(a @ x - b).sum()) # 0.0005

# jax
x = jp.linalg.lstsq(a, b, rcond=None)[0]
print(jp.abs(a @ x - b).sum()) # 562

In order to get an accurate answer in JAX, I had to use the following lstsq solver:
# jax (custom)
lstsq = lambda a, b: jp.linalg.solve(a.T @ a, a.T @ b)
x = lstsq(a, b)
print(jp.abs(a @ x - b).sum()) # 0.005

Is this sort of low accuracy expected or is it a bug?
I tested this in JAX 0.3.14 on CPU and 0.3.8 on GPU and TPU.

I think you should enable the 64-bit precision to match the Numpy precision.
import jax
jax.config.update("jax_enable_x64", True)

Thank you, this solves the problem on CPU/GPU. Using float64, I get the following errors:
NumPy: 3.5e-09
JAX: 4.7e-09
Custom: 5e-12
However, I intend to run the code on TPUs, so float64 is not really an option.
In PyTorch, for example, I can get good-enough results with float32 when I set driver=gels:
import torch
at = torch.tensor(a.tolist(), dtype=torch.float32)
bt = torch.tensor(b.tolist(), dtype=torch.float32)
for driver in ['gelsy', 'gels', 'gelsd', 'gelss']:
    xt = torch.linalg.lstsq(at, bt, driver=driver)[0]
    error = torch.abs(at @ xt - bt).sum()
    print(driver, float(error))
# gelsy 3198
# gels 0.001
# gelsd 562
# gelss 562

Perhaps the results in JAX are not a bug, I was simply surprised that they're so different from NumPy. Do you think this could at least be mentioned in the docs?

You're welcome.
There is a section related to 64-precision in the doc.

I suspect this comes down to the algorithm used to compute the least squares solution. Currently we use a SVD to do so:
https://github.com/google/jax/blob/b666f665ece2b91e7c07c65d27cf485a779638b6/jax/_src/numpy/linalg.py#L571
This is one of the"textbook answers on how to compute the solution to a least squares solution; the others are based on Cholesky decomposition of the a.T @ a matrix (much as you have done) and based on QR decomposition. The solution based on computing a.T @ a is usually supposed to be less accurate, because it "squares" the condition number of the matrix.
It seems for your matrix the SVD-based methods, both ours and those of LAPACK are inaccurate. I wonder why! Hopefully one of our numerical experts can chime in.
(Aside: On CPU and GPU, we should probably call LAPACK and Cusolver to compute least squares rather than rolling our own. The main thing missing that would enable us to do this is that we would need to define gradients for the least-squares computation directly. It would then not be difficult to make lstsq a primitive call to a LAPACK function: indeed the same ones that NumPy/Scipy/PyTorch use.
Since you mentioned that you are interested TPU, this isn't an option: there's no other library to resort to.)
On TPU I would be tempted to try the QR-decomposition based version which incidentally is not dissimilar to how the LAPACK function sgels works. (See http://www.netlib.org/lapack/explore-html/d0/db8/group__real_g_esolve_ga166c189c7bcd808a9468c05e53da816f.html for the details of the LAPACK function):
For a square matrix it looks something like this:
def lstsq(a, b):
  q, r = jp.linalg.qr(a)
  z = q.T @ b
  return lax.linalg.triangular_solve(r, z, left_side=True)

It might make sense to allow the user to select the algorithm, as Scipy and Pytorch do.

both ours and those of LAPACK, are inaccurate
This could be because we are using single precision for a computationally intense operation and you are losing accuracy quickly as a result. For example, the answer in this thread compares the FLOPS for SVD, QR, and Cholesky (https://math.stackexchange.com/questions/51150/exact-computational-costs-flop-count-for-algorithms).

@amir-saadat I agree that double precision would be the most popular choice here. Certainly most of the time NumPy will silently upcast and compute in double precision. We intentionally do not do this in JAX because it is a very unfriendly thing to do on accelerators.
It does not however explain why we see such different precision behavior between different algorithms computed at the same precision.

More data points, mostly echoing the above: this is more of an algorithm question than a CPU/GPU/TPU question imho.
A is very ill-conditioned. Its singular values go from 2e6 down to 4e-1
[2.4730732e+06 6.3774088e+05 1.7518223e+03 7.7507446e+02 5.2085254e+02
 3.9505237e+02 8.7445968e-01 4.3333033e-01]

The SVD of A itself is fairly accurate, even for JAX: ||A - USV^T||/||A|| is about 1e-6. This is expected: the SVD can be compute accurately even for ill-conditioned / singular matrices.
But this does not mean that all singular values are accurate. Only the very large ones are well resolved, with near full accuracy. The very small one probably have at most 1 digit of accuracy, if not none.
JAX uses the SVD directly (pretty much the textbook algorithm, as mentioned above) for computing the minimal norm least square. But this requires inverting the singular values (larger than rcond). Since the smallest singular values are the least accurate, this is probably pretty inaccurate.
Numpy should be using gelsd https://www.smcm.iqfr.csic.es/docs/intel/mkl/mkl_manual/lse/functn_gelsd.htm
It's possible that gelsd has better accuracy / properties and is less sensible to the above, although I am not sure how it is implemented.

For the sake of experiments, consider adding this to jaxlib.
With that, adding CUSOLVER_INCREASE_PRECISION=1 will force cuSolver to run one more iteration to get slightly better accuracy.
diff --git a/jaxlib/cuda/cusolver_kernels.cc b/jaxlib/cuda/cusolver_kernels.cc
index 7ff986617..6af4e6fde 100644
--- a/jaxlib/cuda/cusolver_kernels.cc
+++ b/jaxlib/cuda/cusolver_kernels.cc
@@ -20,6 +20,8 @@ limitations under the License.
 #include <stdexcept>
 #include <utility>
 #include <vector>
+#include <cstdio>
+#include <limits>

 #include "absl/status/status.h"
 #include "absl/status/statusor.h"
@@ -859,9 +861,19 @@ static absl::Status Gesvdj_(cudaStream_t stream, void** buffers,
         float* s = static_cast<float*>(buffers[2]);
         float* u = static_cast<float*>(buffers[3]);
         float* v = static_cast<float*>(buffers[4]);
+        if(std::getenv("CUSOLVER_INCREASE_PRECISION") != nullptr) {
+          JAX_RETURN_IF_ERROR(JAX_AS_STATUS(cusolverDnXgesvdjSetTolerance(params, std::numeric_limits<float>::epsilon())));
+          JAX_RETURN_IF_ERROR(JAX_AS_STATUS(cusolverDnXgesvdjSetMaxSweeps(params, 1000)));
+        }
         JAX_RETURN_IF_ERROR(JAX_AS_STATUS(cusolverDnSgesvdj(
             handle.get(), d.jobz, d.econ, d.m, d.n, a, d.m, s, u, d.m, v,
             d.n, static_cast<float*>(work), d.lwork, info, params)));
+        int executed_sweeps = -1;
+        double residual = -1.0;
+        JAX_RETURN_IF_ERROR(JAX_AS_STATUS(cusolverDnXgesvdjGetSweeps(handle.get(), params, &executed_sweeps)));
+        JAX_RETURN_IF_ERROR(JAX_AS_STATUS(cusolverDnXgesvdjGetResidual(handle.get(), params, &residual)));
+        printf("Dgesvdj residual = %e\n", residual);
+        printf("Dgesvdj number of executed sweeps = %d \n", executed_sweeps);
         break;
       }
       case CusolverType::F64: {

Also consider
# bug_11433.py

import numpy as np
import jax.numpy as jp

# data
a = jp.array([[122, 1141, 1, 0, 0, 0, 0, 0],
              [0, 0, 0, 122, 1141, 1, -156536, -1459977],
              [686, 1209, 1, 0, 0, 0, -493286, -869838],
              [0, 0, 0, 686, 1209, 1, -877486, -1547319],
              [626, 2, 1, 0, 0, 0, -450148, -1812],
              [0, 0, 0, 626, 2, 1, 0, 0],
              [23, 339, 1, 0, 0, 0, 0, 0],
              [0, 0, 0, 23, 339, 1, 0, 0]], dtype=jp.float32)
b = jp.array([0, 1279, 719, 1279, 719, 0, 0, 0], dtype=jp.float32)

def residual(a, b, x):
  return np.linalg.norm(np.array(a) @ np.array(x) - np.array(b)) / np.linalg.norm(np.array(b))

# numpy
x = np.linalg.lstsq(a, b, rcond=None)[0]
print("Numpy (dgelsd): ", residual(a, b, x))

# jax
x = jp.linalg.lstsq(a, b, rcond=None)[0]
print("JAX (sgesvdj): ", residual(a, b, x))

# jax with 0 rcond
x = jp.linalg.lstsq(a, b, rcond=0)[0]
print("JAX (sgesvdj + rcond=0): ", residual(a, b, x))

Then
[1] Vanilla: Numpy 8e-8, JAX 1e-1
$ python3 bug_11433.py
Numpy (dgelsd):  8.859738e-08
Dgesvdj residual = 6.153713e-07
Dgesvdj number of executed sweeps = 4
JAX (sgesvdj):  0.12339112
...
JAX (sgesvdj + rcond=0):  0.26171464

[2] Increasing cuSOLVER's accuracy: Numpy 8e-8, JAX 1e-1 (rcond=None) or 3e-4 (rcond=0)
$ CUSOLVER_INCREASE_PRECISION=1 python3 bug_11433.py
Numpy (dgelsd):  8.859738e-08
Dgesvdj residual = 3.484288e-09
Dgesvdj number of executed sweeps = 5
JAX (sgesvdj):  0.12339121
...
JAX (sgesvdj + rcond=0):  0.0003707072

[3] Using JAX on CPU: Numpy 8e-8, JAX 1e-1 (rcond=None), JAX 4e-3 (rcond=0)
$ CUDA_VISIBLE_DEVICES="" python3 bug_11433.py
Numpy (dgelsd):  8.859738e-08
JAX (sgesvdj):  0.123391196
JAX (sgesvdj + rcond=0):  0.005672992

So

Increasing the accuracy of the SVD
and decreasing rcond (to capture more singular values)
give a better solution.


OnRamp logo logs the user out

Expected Behavior
The button shouldn't log the user out, a few suggestions would be

Make the button open a tab to the OnRamp wiki or informational page
Take the user to the main dashboard

Current Behavior
When clicking on the "OnRamp" logo in the upper left the user is logged out and there is already a "Logout" button in the upper right.
Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

Version used:
Environment name and version (e.g. Chrome 39, node.js 5.4):
Operating System and version (desktop or mobile):
Link to your project:

just disable as a button.


read_info missing in docs

There is no reference to mne.io.read_info in the documentation.

Indeed, PR welcome


Fix info for casks that use staged_path as suite.

Changes to the core

[x] Followed hacking.md.

Is this a common case? I'd really rather we create a new directory rather than moving staged_path.

Yeah, it's probably better to simply disallow suite '.' as only 4 casks use it.


Integrate Welcome Bot

I can add a welcome bot config file having a proper message that will show up when any user will open up an issue or pull-request for the first time.
For reference, check out: https://github.com/apps/welcome

I would like to work on it as a part of Cross Woc

I would like to work on it as a part of Cross Woc

I am assigning you this one. Make sure you read README.md file and How to Contribute.
I will be giving you 4-5 days to do this. Is it ok foor you?

I would like to work on it as a part of Cross Woc

I am assigning you this one. Make sure you read README.md file and How to Contribute.
I will be giving you 4-5 days to do this. Is it ok foor you?

It is ok for me bro

Thank you @muthuannamalai12
PR > #18


Chore: make changes to DeviceList

Type of change

Enhancement
Bugfix

Description

Handle pagination on applying filters.
Re-style the toolbar
Change device query according to mock
Handle options for multiple select
Get credentials in device list query to get device type
Modify CSS of IoTProjectDetailHeader and IoTDeviceDetailHeader
Fix some typos
Update README.md of mock-server

Screenshot

Checklist

[ ] Update/write design documentation in ./documentation/design
[ ] Write tests and make sure they pass
[ ] Resolve all warnings
[ ] Update license
[ ] Write test cases for null checks in Unit Tests
[ ] Reference relevant issue(s) and close them after merging

@ajaypratap003 , suggestions in #4931 have been addressed here.


Fix CSV output [redundant with masseditvar branch]

Fixes csv outputting cell.tostring instead of cell.value.tostring

apparently this commit is already redundant


.hadolint.yaml is not being respected

Describe the bug
Hadolint is working out of the box inside VSC. But it does not respect my '.hadolint.yaml' rules.
To Reproduce
Steps to reproduce the behavior:

Install Hadolint via the marketplace
place a '.hadolint.yaml' file in the root directory (I store mine in .config but I moved it to root for testing)

Expected behavior
Hadolint should now be showing up errors in the problems tab (it does). It should also ignore any disabled rules in the '.hadolint.yaml' file. (It does not)

Not sure if this has anything to do with WSL 2.0 but I am using Windows 11.

I have closing this issue because the problem seems to be with hadolint itself and not the fault of the plugin. You can find this issue reported here https://github.com/hadolint/hadolint/issues/1043


Please add a setting to turn off 'Run Script|Debug Script' popup when hovering over npm scripts in package.json

When editing quickly in the package.json it's easy to accidentally hit a popup that VS Code recently seems to have introduced to start a debugger or execute a script. This happened to me a lot and it's not only disturbing the workflow but also is prone to errors when accidentally hit. Working fast this is very unwanted behaviour for me as it executes stuff I don't like to be executed with all problems involved.

I've searched everywhere on how to turn this off, but can't find anything on this feature. I also posted a question on stackoverflow, but there doesn't seem to be a way to turn this behaviour off.
Please add a setting to turn this feature off!!

These are called codelenses. Please search settings for npm codelens

@gjsjohnmurray  I did, and found this, but when setting it to 'never' it doesn't turn off:

So I figured that was a different thing. But it could as well be a bug then?

Please use the Start Extension Bisect command to investigate which extension is adding the two CodeLens items shown in your original screenshot.

Forget that suggestion. I misinterpreted your original screenshot. What you are seeing is on the hover tip, and comes from here:
https://github.com/microsoft/vscode/blob/78397428676e15782e253261358b0398c2a1149e/extensions/npm/src/scriptHover.ts#L45-L90
Back in 2018 @egamma apparently moved these from CodeLenses to hover links in https://github.com/microsoft/vscode/commit/73b72464b3f71db7ac3b763f37e84769bd411a7b but didn't retain the configuration setting.
The setting I originally pointed you to is checked by code last touched by @connor4312 in February 2021 on https://github.com/microsoft/vscode/commit/5b2dc0cad226379252cd85683eaafbba73b25493
Perhaps some rationalization is needed.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This hover has been there for at least 4 years since when I joined the team. There's no setting to turn this off right now as far as I know.

Thanks for the confirmation. Then this feature request for that setting was about time ;)

This hover has been there for at least 4 years since when I joined the team. There's no setting to turn this off right now as far as I know.
PR's welcome for this

Hi Connor, thanks for your reply. Just out of interest, what is this setting then if this is not the one?:

This setting controls the CodeLens run/debug actions.

This setting controls the CodeLens run/debug actions.

Not sure why @connor4312  gave this a like. As written in my posts above that's the exact same setting I already tried several times by switching it to 'never'.  But it doesn't turn the behaviour off. Neither after a restart of VS Code. The popup keeps coming when hovering over the package.json scripts.
So as stated above this is either a bug (see above post about the commit that might have removed this?) or this setting is meant to do something else, which I would find pretty confusing if that would be the case, looking at the description.

It only controls the CodeLens, not the hover tooltip, as the description stated. And thus this issue is turned into a FR.

It only controls the CodeLens, not the hover tooltip, as the description stated. And thus this issue is turned into a FR.

Yeah, I just see it controls this little guy in the package.json:

Not sure what your point was by posting what I already posted, but hey, we're having some fun ;)
Hope the FR will make it to add a setting to remove the unwanted hover.
Have a nice day

@connor4312 I take this issue as we want a new configuration parameter that controls the hover tooltip actions. If so, please let me know to submit a PR.

Yes, that sounds accurate. Note this should be grouped under npm settings rather than debug.javascript since functionality is provided by the npm extension for that. (Yes, we should probably move over code lenses there now that js-debug is built-in, too...)

@connor4312 I've just submitted a PR. Could you please review the PR?
However, I made the changes in the npm extension and didn't move anything to the js-debug extension.

Thanks @babakks ! Very nice to be able to turn this off now!


Package name meaning Issue

Hi,

How about the meaning of euler? is it meaning classic code?
I only know euler is a mathematician.
BR

Each package has its own small description. You can find the godoc of the library, as well as the package description in https://pkg.go.dev/github.com/lca1/lattigo


Add access field to defaults

Access field can be present in device node,
and it's value should be inherited down the line.
Examples:

lm3s6965.svd (access field is present and is used)
ARMCM3.svd (access field is present, but is not used)

Side note:
Maybe this whole inheritance (and derivedFrom) thing can be done in parser?
So you don't have to deal with all this Options later on.
Or is it better to keep parser plain and simple?

I'd prefer to keep the "AST" as a one to one representation of the SVD file for now.
@homunkulus r+
Thank you, @pftbest.

:pushpin: Commit e1b2a2b has been approved by japaric

:hourglass: Testing commit e1b2a2b with merge e1b2a2b...

:sunny: Test successful - status-travis
Approved by: japaric
Pushing e1b2a2b984b007b736c1c045ddd2ece19cec684c to master...


Cannot properly "unpack" LogCameraTransform from BuiltinTransform

check it:
>>> import PyOpenColorIO as ocio

>>> group_transform = ocio.Config().getProcessor(
...         BuiltinTransform("ARRI_ALEXA-LOGC-EI800-AWG_to_ACES2065-1")
...     ).createGroupTransform()

>>> print(f"Looks as expected: \n\n", group_transform)

Looks as expected:

<GroupTransform direction=forward, transforms=
        <LogCameraTransform base=10, logSideSlope=0.24719 0.24719 0.24719, logSideOffset=0.385537 0.385537 0.385537, linSideSlope=5.55556 5.55556 5.55556, linSideOffset=0.0522723 0.0522723 0.0522723, linSideBreak=0.010591 0.010591 0.010591, direction=inverse>
        <MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=0.6802055051062792 0.2361366016064812 0.08365789328723973 0 0.08541497974214032 1.017470878607042 -0.1028858583491822 0 0.002056521669296831 -0.06256250038479215 1.060505978715495 0 0 0 0 1, offset=0 0 0 0>>

however...
>>> print("[type(xf) for xf in group_transform])

[<class 'PyOpenColorIO.Transform'>, <class 'PyOpenColorIO.MatrixTransform'>]

As you can see, the second transform "unpacks" as a MatrixTransform instance, but the first transform is an instance of PyOpenColorIO.Transform -- meaning, none of the expected LogCameraTransform attributes or methods are attached to the instance.
In writing this, I've discovered another bug that I think is related... stay tuned!

Thanks for reporting @zachlewis
This is related to #1211 - most likely the same polymorphism issue in the bindings.

Thanks for reporting @zachlewis
This is related to #1211 - most likely the same polymorphism issue in the bindings.

I suggest we close this issue and paste your comments into #1211.

I suggest we close this issue and paste your comments into #1211.


timestamp() error on Windows with dates before 1970

Hi there,
I'm working through your NBA example, and I'm noticing that anywhere where we're trying to use .timestamp(), e.g.

t = datetime.strptime(row["date"], "%Y-%m-%d").timestamp()
or when setting timestamps=True in the plotting (ts = [datetime.fromtimestamp(t) for t in ts])

it throws an error when encountering dates before 1970, as below:
OSError: [Errno 22] Invalid argument
This doesn't happen in the online notebook, and from some googling it sounds like it's a Windows specific issue. I was able to work around it in the main section by simply manually calculating the timedelta and converting it to seconds (t = (datetime.strptime(row["date"], "%Y-%m-%d") - datetime(1970, 1, 1)).total_seconds()), but that doesn't help me with the plotting, unfortunately.
Do you have any suggested workarounds or fixes? Let me know if any more info is needed.
Edit: To clarify, I'm running Python 3.8 in Spyder 4.1.1 on Windows

i hope this helps,similar problem
https://stackoverflow.com/q/54470408/10346275
also,set your date back by 1 year and try again

Hi @Biggels , apologies for the delay (and thank you @spidyhackx for helping out.)
Thanks for reporting. I don't have access to a Windows machine, so it is difficult for me to debug this. I'm glad you were able to work around it in the main notebook.
For the plotting: an easy fix would be to call plot_scores with timestamps=False. This function returns fig, ax, so you could always use ax.set_xticklabels() as needed to create a pretty plot.
Would the following change in plot_scores fix things on windows?
ts = [datetime(1970, 1, 1) + t for t in ts]

Thanks for the tip on setting ticklabels manually. Seems obvious in hindsight :)
As for your suggested change, I don't believe you can add a float directly to a datetime object. From some testing, it looks like you have to convert the float time in seconds to a timedelta object first. The following snippet, for example, worked for me to convert all the float times in my dictionary of observations to datetime objects:
from datetime import datetime, timedelta
ts = [observation['t'] for observation in observations]
ts = [datetime(1970, 1, 1) + timedelta(seconds=t) for t in ts]

Ah, yes, makes sense. OK, I'll change this in the plotting function 👍


search handler

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #58
Test URLs:

Before: https://main--zemax--hlxsites.hlx.page/
After: https://issue-58--zemax--hlxsites.hlx.page/drafts/zjun/webinars

@FrancoisZhang  There is this slight flicker when you hover the tabs in the column.. Can you please smoothen it out ?

@kunwarsaluja sure, I have fixed that in latest commit


New Proxmox Kernal Prefix in comming.

update log:
proxmox-kernel-6.2 (6.2.16-7) bookworm; urgency=medium

change pve- prefix to proxmox-

merge proxmox-kernel-meta packaging into main kernel repository

bump ABI to 6.2.16-6

Thank you for informing me! I have made the changes to version 1.3 to reflect this change from Proxmox.


[KonvaTimeLine]Added Range validation

✅ Closes: #138

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


 Jesse mentioned that there is not an existing convention for how to make this happen. But maybe we can invent one!?
Anyways, here is what I'm thinking:
Embed this Schema Migration demo ( https://youtu.be/xz4j5tU0ZRU) into this docs page: https://www.cockroachlabs.com/docs/stable/flyway.html
Here are a couple existing examples of how that should look:
• https://www.cockroachlabs.com/docs/v20.1/topology-duplicate-indexes.html
• https://www.cockroachlabs.com/docs/cockroachcloud/stable/cockroachcloud-upgrade-to-v20.1.html
• https://www.cockroachlabs.com/docs/stable/demo-automatic-cloud-migration.html
If this goes well, I have a list of other videos to embed (https://docs.google.com/spreadsheets/d/1hdXbwPtVrcUHr6HMsQ6WUSkxBBdpdbK4vck6uSCgO1w/edit?usp=sharing). And there will be more on the way. But I don't want to get too far ahead of myself....

@dankellycockroach
Thanks for opening this issue! And thanks for sharing your doc - it's awesome.
I think I can add these videos pretty quickly. Expect a PR soon!


Multiple instances of Shopify Context

Overview
I'm coming from my own custom implementation of OAuth and handling app access through a node (actually NextJs) backend. This library looks great! But I'd like to set up multiple Shopify Apps that use the same backend server for OAuth.
It looks like this package is meant to use the Singleton pattern, so initializing context upfront, and then accessing it everywhere else.
Is there a way I can set up multiple instances of the package so different Express routes can handle different Shopify apps?
i.e.
const myApp = new Shopify({ api_key, api_secret_key, ...etc });
const myApp2 = new Shopify({ api_key2, api_secret_key2, ...etc });

app.get('/my-app/auth/callback', async (req, res) => {
  const session = await myApp.Auth.validateAuthCallback(
    req,
    res,
    req.query as unknown as AuthQuery,
  );
  console.log(session.accessToken);
  return res.redirect(`/?host=${req.query.host}&shop=${req.query.shop}`); // wherever you want your user to end up after OAuth completes
});

app.get('/my-app-2/auth/callback', async (req, res) => {
  const session = await myApp2.Auth.validateAuthCallback(
    req,
    res,
    req.query as unknown as AuthQuery,
  );
  console.log(session.accessToken);
  return res.redirect(`/?host=${req.query.host}&shop=${req.query.shop}`); // wherever you want your user to end up after OAuth completes
});

Its pretty hacky, but I was able to do it with this package by setting
Shopify.Context.API_KEY
Shopify.Context.API_SECRET_KEY
and
Shopify.Context.SCOPES
Before calling the relevant auth functions
And for offline token, just skipping the Shopify.Auth.beginAuth and storing the token explicitly so I can find it
and call Shopify.Clients.Rest(shop,token) directly.

@paulomarg Any updates on this?

This will now be possible with the upcoming version 6 of the API library.  There's a release candidate currently available for download (v6.0.0-rc1).

@mkevinosullivan Is v6.0.0-rc1 released?
If it is, Can you point me to the documentation for handling multiple shop context on the same server?

@avtans-kumar-shipsy Sorry I didn't see this comment until now ... with v6 you can create two different instances as follows:
const shopify1 = shopifyApi({config for 1});
const shopify2 = shopifyApi({config for 2});


Associate users with specifications

Distinguish on specification overview between "general" specifications and specifications created by the logged in user. First of all, there needs to be an association on the data model and within the backend domain. There are some possibilities on how to distinguish your own and other specifications in the frontend:

Show your own specifications on top of the specification list
Somehow visually tag your own specification
Provide two seperate lists of specifications (e.g. "All Specifications" & "Your Specifications") where you can switch between both of them via tabs

I think this very closely related to #5: It should be possible to associate a specification with more than one user (i.e. the responsible developers), and it should be possible to have different rights for these users. Maybe we need a relation specification-user-permission level? This would also allow for users to have unusually few permissions.
Or should this "author" association be totally separate from permission management? However, this will probably confuse users.

Correct. Although, I see this as kind of a "precondition" for permission-management. This issue has solely the purpose of associating users with specifications and generating views for that such that the user can somehow distinguish between "his own" specifications and others.
Permission management would then be an addition to that, such that you can specify what others can see/edit about your specifications.
I thought it would be better to split this into two separate issues.

I'm not sure if separating both issues isn't more work, that's why I commented yesterday: If I understand this issue correctly, each spec has exactly one "author" who can then (with #5) change its permissions.
However, I don't think that one author is the best idea - a spec is usually developed by a team, which must be stored and managed differently. Therefore I think it might make sense to include permission management at least in the design, so that we don't need to rework everything.
In essence, I think we want an ACL for the specs, so I'd say we use that already for this ticket even if we don't need its full might.

I agree on the implementation details (i.e. instantiating a many-to-many instead of a one-to-many between specifications and users). Interesting question: should we introduce permission-management on versions too? Or is the granularity of specification-permissions already enough!?
Regarding the splitting of the issues: this issue has one focus that does not directly come to mind when thinking about permission management - as I mentioned before, the focus is to visually seperate your "owned" specifications (i.e. later on also specifications that you have write acces to) from all the other specifications, as I may want to quickly see all my owned specifications as a developer (since I'm obligated to maintain them, and/or delete them).

Please bear for a moment with my pipe dream here: I don't want too many configuration options, because that makes everything complicated without achieving a lot. So, I don't think permissions per version are sensible (why should somebody maintain one version, but not another). However (sorry ;)), separating permissions between stable and proposed (SNAPSHOT) versions makes sense again: Most developers can see the stable spec, but you want to show the new proposal to a handful of people so you can discuss it. So this is what I would like to see.
Regarding this issue: I'm sorry, I've understood it to mean way more than just a visual distinction (i.e. associating authors to a spec). Just separating them in the list (maybe with color (think about colorblind people), maybe with a filter) is a good idea. I just wanted to prevent a data structure that will be obsolete as soon as we start on the permission system. I'll go ahead and change the title so we both know what is meant.


Feature/package name validation

added package name validation for init cmd
added a simple workflow only trigger when pull request to develop to check the code can build & all tests pass.

@tanvir-retailai the current validation rule is like this:

The path must consist of one or more path elements separated by slashes (/, U+002F). It must not begin or end with a slash.
Each path element is a non-empty string made of up ASCII letters, ASCII digits, and limited ASCII punctuation (-, ., _).
A path element may not begin or end with a dot (., U+002E).
The leading path element (up to the first slash, if any), by convention a domain name, must contain only lower-case ASCII letters, ASCII digits, dots (., U+002E), and dashes (-, U+002D); it must contain at least one dot and cannot start with a dash.`

not sure do we need to also implement this or not:
For a final path element of the form /vN where N looks numeric (ASCII digits and dots),
N must not begin with a leading zero, must not be /v1, and must not contain any dots.


Add NHWC layout support to Pooling (cuDNN only)

Description
This PR adds NHWC layout support to Pooling operator. Work mostly done by @DickJC123
Training using TensorCores is more efficient when using NHWC data layout. Convolutions and BatchNorm operators in MXNet already have support for NHWC, while Pooling operator currently accepts only NCHW format. This PR introduces NHWC layout support for Pooling when using cuDNN.
This PR is part of upstreaming improvements available in NVIDIA's NGC MXNet container and was tested as part of it to train multiple convnets to expected accuracy. We also introduced additional tests checking consistency between NHWC and NCHW versions of pooling.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Comments

Support for channel last is done only when cuDNN is enabled (noted in the updated documentation)

@mxnet-label-bot add [pr-awaiting-review]
Thanks for your contribution @ptrendx
Could you rebase to the latest master branch

Thanks for the contribution guys.  FYI: I'm keeping an eye on this one and will do my best to get it past CI.  We had a few CI issues that this PR looks like it has been caught up in.  If you have a chance rebasing might help.

I took care of it :)
I actually just wanted to show up as contributor of this PR :P Just kidding, I hope everything is fine now.

Thanks for the contribution @DickJC123 and @ptrendx !
Adding @apeforest @yuxihu and @anirudh2290 to help review.

@ptrendx can you please add more details in description explaining what is this PR doing and the motivation behind doing it(why is this done). Also, if you can please add any required background information, it would be helpful.

Have you ever tried to pass NHWC input into MKL-DNN pooling? Seems it's not well handled here.

The new parameter layout will also be passed to quantized_pooling: https://github.com/apache/incubator-mxnet/blob/master/src/operator/quantization/quantized_pooling.cc

Do we have any other operator exposing layout information to front user? Does NDArray know the layout information of itself?

@ptrendx It would be great if you can add in the PR description why we need this option. Thanks!

@TaoLv
Re MKLDNN: Per title of this PR this is enabling NHWC support only for cuDNN path. I don't know whether MKLDNN supports NHWC pooling.
Re quantized pooling: that file seems to assume NCHW layout. What would you like me to do with it?
Re layout parameter: Yes, other operators expose layout information (in fact, pooling already does as well) - see convolutions (e.g. here https://mxnet.incubator.apache.org/api/python/gluon/nn.html#mxnet.gluon.nn.Conv2D) and batchnorm (axis parameter). NDArray does not know its layout and for many use cases it would not make sense. That is why layout is exposed as an operator parameter.

@apeforest @Vikas89 Not sure I understand the question. Are you asking why do we need NHWC support for pooling?

@Vikas89  I took a stab at modifying PR description to include motivation and testing that we did.

@apeforest Re: bool return of Forward(), Backward(), etc.
As you know, MXNet has been moving to a more imperative style of processing.  Before that, all operators were subclasses of Operator, which defined Forward() and Backward() as returning void.  Now, operators like Pooling are their own class and can define Forward() and Backward() as they desire.  In addition, with every operator, we face the chore of selecting the best implementation (cudnn, cuda, mkldnn, etc.).  Rather than code the selection logic in a central place, I recommend each implementation be asked (in a favored order) whether it supports the operation, given its parameters.  With the cudnn convolution operator back in the "pre-imperative era", I added a 'Supports(..., param, ...) method.  Sadly, this tended to repeat a lot of the checks and analysis done by the actual Forward() and Backward() calls.  Rather than adding a repetitive Supports() method to Pooling, I realized how much cleaner it was to just have Forward() or Backward() return a flag indicating whether the function could be performed.  This allows the implementation selector to cleanly fall back to another implementation.

Prior to this PR, in MXNet, the Pooling operator did not have a parameter to specify the layout, forcing a transposition always to NCHW.

@DickJC123 Good to know that. Could you explain a bit more about when and where this kind of transposition happens?
With this new feature, what's the typical usage in user model? Does user need to specify layout in each layer and each operator?

I love that approach about the operator selection, dick!

The forced transposition I referred to is done currently by the user in the python model.  With this new feature, the Transpose operators could get removed in favor of a Pooling with the new layout parameter.
I'm a bit sorry that NDArray's don't carry the layout information.  As a result, the layout has to travel along with the data ('out-of-band') and be passed into the operators along the way.  On the other hand, having multi-input operators deal with inconsistent layouts would be a headache.  Anyway, that's a discussion to be debated in its own thread.

Sure. It's a problem of MXNet, not this PR. Do you mind documenting some where what does the output layout look like? Then user can know what they need to do before sending the output to next layer.

@DickJC123 Thanks for your detailed explanation about the operator selection logic. I like the way you used a boolean return type for Forward() and Backward() methods to choose the right operator implementation. Although it might be an elegant way, this method is not yet well received in the developer community. And all the other operators do not currently implement in this way. I am afraid that using it alone in this operator without a clear guideline may cause more confusion for prospect developers. Can you still follow the traditional way of declaring Forward() and Backward() function and maybe propose this in a separate thread to refactor the Forward() and Backward() with boolean return type?

Tested this PR on CPU w/ and w/o MKL-DNN  and got error message as below.
w/o MKL-DNN:
Traceback (most recent call last):
  File "test_pool_nhwc.py", line 28, in <module>
    test_pooling_nhwc()
  File "test_pool_nhwc.py", line 21, in test_pooling_nhwc
    out_nhwc = mx.nd.Pooling(data=inp_nhwc, kernel=kernel, pool_type='max', global_pool=False, stride=stride, pad=pad, layout='NHWC')
  File "<string>", line 132, in Pooling
  File "/home/lvtao/Workspace/mxnet/python/mxnet/_ctypes/ndarray.py", line 92, in _imperative_invoke
    ctypes.byref(out_stypes)))
  File "/home/lvtao/Workspace/mxnet/python/mxnet/base.py", line 252, in check_call
    raise MXNetError(py_str(_LIB.MXGetLastError()))
mxnet.base.MXNetError: [12:35:52] src/operator/nn/./pooling-inl.h:167: Check failed: param_.layout.value() == kNCW || param_.layout.value() == kNCHW || param_.layout.value() == kNCDHW Need CuDNN for layout support

w/o MKL-DNN:
terminate called after throwing an instance of 'dmlc::Error'
  what():  [12:28:11] src/engine/./threaded_engine.h:380: std::exception
A fatal error occurred in asynchronous engine operation. If you do not know what caused this error, you can try set environment variable MXNET_ENGINE_TYPE to NaiveEngine and run with debugger (i.e. gdb). This will force all operations to be synchronous and backtrace will give you the series of calls that lead to this error. Remember to set MXNET_ENGINE_TYPE back to empty after debugging.

Stack trace returned 10 entries:
[bt] (0) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(dmlc::StackTrace()+0x42) [0x7f547889afb6]
[bt] (1) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(dmlc::LogMessageFatal::~LogMessageFatal()+0x1b) [0x7f547889b233]
[bt] (2) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(mxnet::engine::ThreadedEngine::ExecuteOprBlock(mxnet::RunContext, mxnet::engine::OprBlock*)+0x66e) [0x7f547b7ad24c]
[bt] (3) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(void mxnet::engine::ThreadedEnginePerDevice::CPUWorker<(dmlc::ConcurrentQueueType)0>(mxnet::Context, mxnet::engine::ThreadedEnginePerDevice::ThreadWorkerBlock<(dmlc::ConcurrentQueueType)0>*, std::shared_ptr<dmlc::ManualEvent> const&)+0x8b) [0x7f547b7bfe9d]
[bt] (4) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(mxnet::engine::ThreadedEnginePerDevice::PushToExecute(mxnet::engine::OprBlock*, bool)::{lambda()#1}::operator()() const::{lambda(std::shared_ptr<dmlc::ManualEvent>)#1}::operator()(dmlc::ManualEvent) const+0x33) [0x7f547b7be22b]
[bt] (5) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(std::_Function_handler<void (std::shared_ptr<dmlc::ManualEvent>), mxnet::engine::ThreadedEnginePerDevice::PushToExecute(mxnet::engine::OprBlock*, bool)::{lambda()#1}::operator()() const::{lambda(std::shared_ptr<dmlc::ManualEvent>)#1}>::_M_invoke(std::_Any_data const&, std::shared_ptr<dmlc::ManualEvent>)+0x4a) [0x7f547b7c2751]
[bt] (6) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(std::function<void (std::shared_ptr<dmlc::ManualEvent>)>::operator()(std::shared_ptr<dmlc::ManualEvent>) const+0x5c) [0x7f547b7b6142]
[bt] (7) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(void std::_Bind_simple<std::function<void (std::shared_ptr<dmlc::ManualEvent>)> (std::shared_ptr<dmlc::ManualEvent>)>::_M_invoke<0ul>(std::_Index_tuple<0ul>)+0x56) [0x7f547b7b6036]
[bt] (8) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(std::_Bind_simple<std::function<void (std::shared_ptr<dmlc::ManualEvent>)> (std::shared_ptr<dmlc::ManualEvent>)>::operator()()+0x1b) [0x7f547b7b5ee1]
[bt] (9) /home/lvtao/Workspace/mxnet/python/mxnet/../../lib/libmxnet.so(std::thread::_Impl<std::_Bind_simple<std::function<void (std::shared_ptr<dmlc::ManualEvent>)> (std::shared_ptr<dmlc::ManualEvent>)> >::_M_run()+0x1c) [0x7f547b7b5e30]

Aborted (core dumped)

I would be prefer to leave the booleans in. If there is no harm in taking that approach, I'd rather go down that path and use this operator implementation as example for others rather than waiting for a saint who's going to refactor everything - because that won't happen.
Dicks designs often greatly improved the architecture or usability of mxnet, thus I really appreciate these things and definitely would not like to see these improvements blocked because some people can't adapt that fast.
This project had some sub-par design decisions that mainly involved choosing preprocessor statements instead of proper class design and abstraction. This PR is a good step towards the first direction and I think everybody should support this path.
I'm feeling strong for having this new method in as long as it doesn't have any drawbacks. If there are any, I'm happy to revisit my decision.

Thanks for the test Tao! Can you check why that has not been caught by our CI? What are we missing?

Seems there is no negative test for this feature. Only GPU with certain versions of CUDNN will be tested.

Great catch! Do you mind adding a test that runs on both cpu and gpu?
I'm still having trouble to understand why we are exposing the Backend (whether it's cudnn or mkldnn) to the frontend and making conditional tests. The tests should work with any Backend (except if there is no valid implementation available). In an ideal world, we would just call the Operator and the mkldnn/cudnn magic would be done by the Backend. I think this new structure is a good step towards that.
Can we already add a generalized test that both works on CPU and GPU at this stage to catch Taos error?

@marcoabreu The harm of leaving this boolean return type in this PR is that it will cause confusion to developers and also leave unclear messages to MXNet users. E.g. when it returns false, what happens in the Python frontend, any clear message? If this is meant to signal the frontend that this operatator implementation is not supported on particular platform, we need a consistent log message (in fact, we already achieve this via a different way in https://github.com/apache/incubator-mxnet/blob/master/src/operator/nn/mkldnn/mkldnn_pooling.cc#L53). Falling back to the conventional void return type seems not affect any functionality of this PR. I would like this PR to mainly focusing on the new feature in Pooling only and we can have a separate PR to change void to boolean return type and invite more discussions there. I am open to any other suggestions and add @Vikas89 @yuxihu for their comments.

@apeforest I expect that this PR is one of multiple. In the end, there will be a dispatcher in between the operators and the initial call to the operators. That dispatcher will evaluate the capabilities of every registered operator and then return a unified message. The frontends shouldn't even know about the fact that there may be multiple operators.
The way it was done in mkldnn is also not consistent. This evaluation has to come from a central component and the further processing as well. In this particular example you gave, the process would then fail to execute an operator although there might be other implementations available that actually support the requested operation.
I think you got valid points regarding what's going to happen with the return value and at which point this logic is finally handled. Dick might be happy to answer this.

Closing in favor of PR #13749


'Windows 10 or newer devices that are either Azure AD joined or hybrid Azure AD joined are active on the network.' is ambiguous

Windows 10 or newer devices that are either Azure AD joined or hybrid Azure AD joined are active on the network.

Which network? Is this reliant on intranet connectivity or will internet access be enough for the timestamp to update? If its intranet, how is it making this determination?

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

ID: ad8e93b0-2d8b-68c0-62ee-be44831b1557
Version Independent ID: b55939f9-e552-9818-80b7-535601d4bc7b
Content: How to manage stale devices in Azure AD
Content Source: articles/active-directory/devices/manage-stale-devices.md
Service: active-directory
Sub-service: devices
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

@erishiamu
Thanks for your feedback! We will investigate and update as appropriate.

Azure AD joined devices are only reliant on internet connectivity.
Hybrid Azure AD joined devices rely on internet connectivity for an Azure AD activity timestamp but also require line of sight to a domain controller to regularly update credentials.
#please-close


add spaces webdav for  apiShareOperationsToShares2 suite

Description

use spaces WebDAV URL for apiShareOperationsToShares2 suite from oc/core
includes:

getWebDAVSharePermissions.feature
shareAccessByID.feature (no need)
uploadToShare.feature

It includes tests for adjusting the quota of users Bug (https://github.com/owncloud/product/issues/247)
Related

part of https://github.com/owncloud/ocis/issues/2854

done with #39710


generate an automatic municipality select list

in order to select which list to fill
https://github.com/hunter-x/night-vision-data/blob/master/frontend/src/components/crowdsourcing/RootCrowdsourcing.js#L60
this could be generated from the database  to get
quick mongo solution db.getCollection('lists').aggregate([       {$group: {          _id: {nom_fr: "$nom_fr"}          }      } ])

https://github.com/hunter-x/night-vision-data/commit/21aeaabc91b0652e7b0e30db8b18284756d337d0


Make it easier to test load all the .sql files during a docker build operation.

Issue: Make it easy to test load all files from docker-entrypoint-initdb.d and verify they work, during a docker build, without fully starting the final db instance.
I have a Dockerfile that does FROM postgis/postgis:10-3.0-alpine, which itself has FROM postgres:10-alpine or such. Then we add a bunch of machine generated .sql files into docker-entrypoint-initdb.d, to effectively create a readonly db artifact that can be used in our various environments. Sometimes we find issues where they don't integrate well in our final container we build (ex, one file creates an index on a column that changed in another). But we don't find out until we actually run the container. We actually used to do at the end of our Dockerfile a RUN /docker-entrypoint.sh postgres --describe-config to create that behaviour, but at some point a while back, the adding of the _pg_want_help function caused these options to short-circuit the db load process there (it always exits with success regardless of whether the docker-entrypoint-initdb.d files are valid or not).
In order to catch this at build time, I have created a hacked up dbtest.sh that sources the docker-entrypoint.sh, then runs a limited version of the startup process that basically does everything in _main except the final exec<EMAIL_ADDRESS>But I'm concerned that this will be hard to keep in sync with the docker-entrypoint.sh if other changes are made in the future.
I feel like this would be best to modify the docker-entrypoint.sh to allow it to stub out that part of the startup into a separate function. Or, add a magic keyword to the docker-entrypoint.sh to activate special init-db-but-don't-launch behavior.  It also feels like this would be generally useful for people, and also would maybe give people the option to create containers where the initdb.d stuff is already loaded into tables during the container build process (though that specific feature might be bad, too). In our case, /var/lib/postgresql/data isn't kept in the build, so the full load of the docker-entrypoint-initdb.d will happen on container load, which happens to work well for us.
I can create a PR, but was wondering if there are preferences here as to the preferred paths, first. I think option 3 below seems least disruptive, but also slightly harder to use for some users...

Create a magic keyword that when docker-entrypoint.sh postgres-load-only and it does everything but the exec "$@" at the end of _main.
Create a fake option docker-entrypoint.sh postgres --load-only that shell strips out and then lets the init start and then skips the exec "$@" at the end of _main
Move all of the init stuff into a function called something like docker_init_all that takes almost everything out of _main into a function, and _main would just be effectively docker_init_all $@;exec "$@". Then a user could just source docker-entrypoint.sh and then docker_init_all to clone that functionality. In a dockerfile, it could look like RUN . /docker-entrypoint.sh ; docker_init_all

We had a similar scenario, not about testing the dump at build time but more as to build a reusable Docker image for integration testing.
The dump we want to use takes quite a long time to load from a plain text SQL file and it's not very practical to load it at each initial start of the container - once data is loaded it only takes a second to start
Here is an attempt at implementing this feature, not exactly the same keywords as in the initial request, but the change is quite minimal
diff --git a/docker-entrypoint.sh b/docker-entrypoint.sh
index 749445d..762c7e9 100755
--- a/docker-entrypoint.sh
+++ b/docker-entrypoint.sh
@@ -222,6 +222,7 @@ docker_setup_env() {
        file_env 'POSTGRES_USER' 'postgres'
        file_env 'POSTGRES_DB' "$POSTGRES_USER"
        file_env 'POSTGRES_INITDB_ARGS'
+       file_env 'POSTGRES_EMBED_INITDB'
        : "${POSTGRES_HOST_AUTH_METHOD:=}"

        declare -g DATABASE_ALREADY_EXISTS
@@ -343,6 +344,10 @@ _main() {
                fi
        fi

+    if [ "$POSTGRES_EMBED_INITDB" ]; then
+        exit 0
+    fi
+
        exec "$@"
 }

and a Dockerfile that can be used to build this image
FROM postgres as initdb

ENV POSTGRES_PASSWORD=secret
ENV POSTGRES_DB=test

COPY testdump.sql /docker-entrypoint-initdb.d/

ENV POSTGRES_EMBED_INITDB=true
RUN /usr/local/bin/docker-entrypoint.sh postgres

FROM postgres as final

ENV POSTGRES_PASSWORD=secret
ENV POSTGRES_DB=test
COPY --from=initdb ${PGDATA} ${PGDATA}

I can issue a Pull Request if necessary but I'm not sure how it should be structured as the docker-entrypoint.sh seems to be copied in a few places and vary for a single line in the Alpine version

I just stumbled upon this thread while trying to implement the same thing! For lack of better ("better" depends on the priorities of course) alternatives, I want to "bake" the imported/processed SQL right into the Docker image.
I ended up with a slightly modified version of Rémi's approach:
diff --git a/docker-entrypoint.sh.orig b/docker-entrypoint.sh
old mode 100644
new mode 100755
index a383a36..62655a1
--- a/docker-entrypoint.sh
+++ b/docker-entrypoint.sh.new
@@ -343,7 +343,9 @@ _main() {
 		fi
 	fi

-	exec "$@"
+	if [ "${POSTGRES_INIT_THEN_EXIT:-}" != '1' ]; then
+		exec "$@"
+	fi
 }

 if ! _is_sourced; then

Here is my Dockerfile, stripped ad-hoc from domain-specific code:
FROM ghcr.io/public-transport/gtfs-via-postgres AS sql

WORKDIR /importer

ENV DEST_PATH=/tmp/sql/gtfs.sql
ADD import.sh ./
RUN --mount=type=cache,target=/tmp/gtfs,sharing=locked \
	./import.sh

FROM postgis/postgis:15-3.4-alpine AS import

# configure access to the container-local PostgreSQL server
ARG POSTGRES_USER
ENV POSTGRES_USER=$POSTGRES_USER
ARG POSTGRES_PASSWORD
ENV POSTGRES_PASSWORD=$POSTGRES_PASSWORD
ARG POSTGRES_DB
ENV POSTGRES_DB=$POSTGRES_DB

# patch pre-populated docker-entrypoint.sh
ADD docker-entrypoint.sh /usr/local/bin/
# tell docker-entrypoint.sh *not to* (re)start PostgreSQL after importing /docker-entrypoint-initdb.d/*
ENV POSTGRES_INIT_THEN_EXIT=1

# We prefix our GTFS SQL with `20_`, so that it gets processed *after* the pre-existing PostGIS init script (/docker-entrypoint-initdb.d/10_postgis.sh).
RUN --mount=type=bind,from=sql,source=/tmp/sql,target=/tmp/sql \
	ln -s /tmp/sql/gtfs.sql /docker-entrypoint-initdb.d/20_gtfs.sql && \
	/usr/local/bin/docker-entrypoint.sh postgres && \
	rm /docker-entrypoint-initdb.d/20_gtfs.sql

# For the final image, use an "unadulterated" PostGIS image.
FROM postgis/postgis:15-3.4-alpine

# Copy over the imported DB from the `import` stage.
COPY --from=import /var/lib/postgresql/data /var/lib/postgresql/data


Why is pyarrow.dataset direct from S3 so much slower than using dataset locally and upload/download separately?

Describe the usage question you have. Please include as many useful details as  possible.
I'm using pyarrow.dataset.dataset and pyarrow.dataset.write_dataset to convert a newline-delimited (jsonl) file to parquet, and seeing very different end-to-end processing times for the following three approaches:

Let the dataset API handle all the filesystem details (223s)
Pass dataset an s3fs.S3Filesystem object (70s)
Use smart_open to handle download/upload from/to S3 and use dataset on local filesystem (30s)

More detail with code snippets documented in this StackOverflow question.
From previous use of pyarrow.parquet.ParquetFile I know that options like buffer_size and pre_buffer can impact performance and I thought there might be similar options with the dataset API but I couldn't find anything in the documentation, would greatly appreciate some insight into this.
Component(s)
Python

Closing this as I was able to figure it out.  I was able to improve performance by creating a scanner and tweaking the batch_readahead and batch_size options.  More info posted at https://stackoverflow.com/a/78220987/12309386

Great to hear, thanks for coming back with an update!


Update the latest updates from the remote upstream.

Merge commits from the remote upstream

Merge the latest commits from the remote upstream.


fix(lint): correct globs

Description
Fix globs -  silly mistake from copy pasting from the first package that I converted.
Closes TURBO-1270

Sending this one through as CI has passed, and it could create a situation where bad code sneaks in that's not being checked in CI


perf: avoid copying buffer/window variables to lua

Context:
I noticed that :FzfLua buffers gets very slow and uses gigabytes of memory after I explore a directory with many files with fern.vim. After some investigation, I found out that

the most of the time is spent converting vim value to lua value (encode_vim_to_lua)
fzf-lua unintentionally loads buffer variables with vim.fn.getbufinfo
fern stores the directory structure in buffer variable, which is cyclic due to reference to the parent node
converting vim values containing cycles to lua value seems to exhibit time/space complexity that is quadratic on the degree of the graph node.

Problem:
Calling vim.fn.{getbufinfo,getwininfo} in lua can be slow because it has to convert potentially big and cyclic data structures stored in vim buffer/window variables into lua values.
Solution:
Remove buffer/window variables from the result before passing it to lua.

Wow, interesting find and great fix @tomtomjhj!
Do you think we can recreate the vimL function as simple function in utils instead?
I’m in the middle of refactoring the :FzfLua auto-complete and trying to get rid of that specific vim file you modified,

I just read your comment why it’s vimL
" Calling vim.fn.getbufinfo in lua can be expensive because it has to convert
" all the buffer variables into lua values. Since fzf-lua does not access
" buffer variables, this cost can be avoided by clearing the entry before
" passing the info to lua.

Maybe we can define by streaming the function definition via vim.cmd or perhaps there is another command that loads vial similar to lua’s loadstring, I’ll do some digging.

Looks like we can source the vimL directly with nvim_exec2.

@tomtomjhj, merged, added https://github.com/ibhagwan/fzf-lua/commit/7aedfca54a24eae73f1a6ecfa8de0adcfc09c1a5 on top.
Additional changes:

For some reason I don't trust the autoload folder so I made sure it's sourced on init
Just in case, changed the implementation to use utils.get{buf|win}info which includes fallback to vim.fn if our functions aren't loaded
Return for non-existing buffers windows changed to an empty list [] instead of v:false to prevent potential exceptions


TextCNN rand model downloads pretrained vectors even if not needed

TextCNN rand model downloads pretrained word vectors even if not needed. rand model initializes word vectors randomly and updates in the training process. So, I think there is not need to download word vectors for this model.

There should be a flag passed to _build_vocab  function representing the type of model. If the model is other than rand, then pretrained vectors should be downloaded.

@leezu @eric-haibin-lin your thoughts on this?

@leezu I have code ready for this and iam able to reproduce the results as well. What do you think?

Yes, your proposal is sensible.

Sure, will submit PR to this

Fixed via #1222


Create nodes iterator

Previously could just do this:
        for node in self.nodes:
            if self.nodes[node].address != self.address:
                self.nodes[node].query()

But now have to call a method and define our own list of nodes
        nodes = self.poly.getNodes()
        for node in nodes:
            if nodes[node].address != self.address:
                nodes[node].query()

should be done the real python way? https://docs.python.org/3/library/itertools.html

Agree that there should be a better way to iterate over the node list.  However, I don't think access the internal node list data structure directly from the interface module is the right way to do it.

Yes, agree, only supplied that for info, it's actually a problem now because PGC does it differently.

In my Nodeserver wrapper class I have two properties: "nodes" which is an iterable collection of Node objects, and "nodesDict" which is an iterable dictionary of address: node pairs. They return  self.poly.nodes_internal.values() and self.poly.nodes_internal respectively.


CupertinoRefreshControl doesn't disappear in some cases

I tested this behavior on the example https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/cupertino/cupertino_refresh_demo.dart
If i change childCount to 2, after a pull to refresh, the CupertinoRefreshControl widget doesn't disappear. RefreshIndicatorMode seems correctly set to "done" so the problem could be related to the scrollview or to the render system

Yup, I can repro, it's definitely broken

Not sure I completely understand what's going on yet. Seems like the sliver constraints are correctly reflecting that there's a -60px overlap and is in overscroll mode at the end of the refresh but isn't triggering the overscroll physics for some reason.

Without onrefresh field or with a short delay it works, but if the delay is more than 1 second it remains stuck

I'm experiencing this as well. Please see sample code to reproduce the issue as well as gif demonstrating the issue here: https://stackoverflow.com/questions/50305379/flutter-cupertinorefreshcontrol-does-not-dismiss

The flow is basically that after _RenderCupertinoRefreshSliver.performLayout returns a SliverGeometry with a scrollOffsetCorrection, in RenderViewport.performLayout, if the list was previously filling the viewport, in offset.applyContentDimensions, it would eventually look for how much scroll extent there is and if it was different, it would eventually go to the scroll activity and trigger delegate.goBallistic(0.0) on IdleScrollActivity.
However, if both with and without the refresh indicator, the list content is smaller than the viewport, ScrollPosition.applyContentDimensions ends up skipping everything and doesn't trigger the now overscrolled list to snap back.

So in other words, if the list is too short, the Cupertino Refresh Control
will not disappear.
Is there anyway to fix this?
On Tue, 15 May 2018, 7:47 am xster<EMAIL_ADDRESS>wrote:

The flow is basically that after _RenderCupertinoRefreshSliver.
performLayout returns a SliverGeometry with a scrollOffsetCorrection, in
RenderViewport.performLayout, if the list was previously filling the
viewport, in offset.applyContentDimensions, it would eventually look for
how much scroll extent there is and if it was different, it would
eventually go to the scroll activity and trigger delegate.goBallistic(0.0)
on IdleScrollActivity.
However, if both with and without the refresh indicator, the list content
is smaller than the viewport, ScrollPosition.applyContentDimensions ends
up skipping everything and doesn't trigger the now overscrolled list to
snap back.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/17474#issuecomment-389050050,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGxBzh-T9eTiGBHffRlCQ4VFWS912sHXks5tymwFgaJpZM4T6H2O
.


Added Greek translation.

Issue #78

Ευχαριστώ πολύ! This is the first non-Latin-script language for Marinara...looking good :)
Thanks again for your contribution. I will add you to the contributors list.

I really appreciate it! Keep up the good work :D You have built an excellent app.


As VALIDATOR, I want to cross-check my study data against the study define.xml for invalid units for normalized test parameters such as PK so that I can stay compliant with CG0556, CG0557, CG0559, CG0560

Given an SDTM Findings domain in scope, and when test parameters matching certain nomenclature that indicates a normalization scheme, it is expected compatible units of measurement be used for the corresponding test results. Use cases are as follows.
Assumptions

Variable PPTESTCD is populated using the CDISC CT codelist PKPARMCD (C85839).
Variable PPTEST is populated using the CDISC CT codelist PKPARM (C85493).

Case 1: Test parameters normalized by weight
When:

Domain: PP
and PPTESTCD nomenclature: ends with W, except when it ends with DW (dose adjusted by body weight)

Check 1:

Study define: variable PPORRESU does not use any of these CDISC CT codelists: PKUWG (C128684) or PKUWKG (C128683)
and (study data: PPORRESU is not one of the values in the CDISC CT codelists and package date specified in the study define.
or study data: PPORRESU does not end with /g, if PKUWG is the CT; or, /kg if PKUWKG is the CT (case sensitive))

Check 2:

Study define: variable PPSTRESU does not use any of these CDISC CT codelists: PKUWG (C128684) or PKUWKG (C128683)
and (study data: PPSTRESU is not one of the values in the CDISC CT codelists and package date specified in the study define.
or data: PPSTRESU does not end with /g, if PKUWG is the CT; or, /kg if PKUWKG is the CT (case sensitive))

Case 2: Test parameters normalized by dose
When:

Domain: PP
and PPTESTCD nomenclature: ends with D

Check 1:

Study define: variable PPORRESU does not use any of these CDISC CT codelists: PKUDMG (C128685) or PKUDUG (C128686)
and (study data: PPORRESU is not one of the values in the CDISC CT codelists and package date specified in the study define.
or study data: PPORRESU does not contain /mg, if PKUDMG is the CT; or, /ug if PKUDUG is the CT (case sensitive))

Check 2:

Study define: variable PPSTRESU does not use any of these CDISC CT codelists: PKUDMG (C128685) or PKUDUG (C128686)
and (study data: PPSTRESU is not one of the values in the CDISC CT codelists and package date specified in the study define.
or study data: PPSTRESU does not end with /mg, if PKUDMG is the CT; or, /ug if PKUDUG is the CT (case sensitive))

I am investigating these other normalization schemes through NCI EVS:
Normalized by weight
PPTESTCD ends with W
PPORRESU/PPSTRESU should end with /g from PKUWG (C128684); or end with /kg from PKUWKG (C128683)
Normalized by dose
PPTESTCD ends with D
PPORRESU/PPSTRESU should contain with /mg from PKUDMG (C128685); or end with /ug from PKUDUG (C128686)
Normalized by dose & weight (weight-adjusted dose)
PPTESTCD ends with DW
PPORRESU/PPSTRESU should ???
Normalized by surface area (SA)
PPTESTCD ends with S
PPORRESU/PPSTRESU should contain m2 or cm2 from PKUNIT (C85494)
Normalized by BMI
PPTESTCD ends with B
PPORRESU/PPSTRESU should contains kg/m2 or mg/cm2 from PKUNIT (C85494)

@chowsanthony
It seems like the rule will involve some variation of these 4 checks:
Raise an error if:
PPTESTCD ends in W but not DW and
The specified codelist(s) for PPSTRESU from the define are not contained by [C128684, C128683, C85494] and (PPSTRESU ends with /g or PPSTRESU ends with /kg)
If so we would just need the specified codelist for PPSTRESU from the define . Am I misunderstanding something?

The validation process is complete. The engine successfully checks the study data against the define xml for the scenarios mentioned in the Acceptance criteria. One of the reports generated for this scenario is attached below. It had 3 errors which were detected successfully.

CORE-Report-2023-06-14T15-40-47.xlsx


mobile_app integration: Unique IDs are not created

Home Assistant release with the issue:

0.102.3
Last working Home Assistant release (if known):
N/A, unknown
Operating environment (Hass.io/Docker/Windows/etc.):

Hass.io running in VM on Windows 10
Integration:

https://www.home-assistant.io/integrations/mobile_app/
Description of problem:
The mobile_app integration self-reports that it does not assign unique IDs and I appear to be having naming collisions when attempting to use two different Pixel 3 devices for location tracking.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

N/A, default_config.
Traceback (if applicable):
Log Details (ERROR)

Wed Dec 04 2019 22:24:45 GMT-0500 (Eastern Standard Time)

Error doing job: Task exception was never retrievedTraceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 399, in _async_add_entity raise HomeAssistantError(msg) homeassistant.exceptions.HomeAssistantError: Entity id already exists: device_tracker.pixel_3_3. Platform mobile_app does not generate unique IDs

Additional information:
Identical to Bloomsky issue located here: https://github.com/home-assistant/home-assistant/issues/27246

Having an issue that i belive is cause by this, me and the wife have a pocophone f1 and when integrated to ha looks like this.

i get a notify service setup for one of the phones.
Found this in log.
019-12-17 21:53:58 INFO (MainThread) [homeassistant.components.notify] Setting up notify.mobile_app
2019-12-17 21:53:58 WARNING (MainThread) [homeassistant.components.mobile_app.notify] Found duplicate device name POCOPHONE F1
2019-12-17 21:53:58 WARNING (MainThread) [homeassistant.components.mobile_app.notify] Found duplicate device name POCOPHONE F1
They are not named the same within the phone.

seems to be the same with 103.2

This is fixed for device trackers in https://github.com/home-assistant/home-assistant/pull/30457
For other issues, please open a new issue.