move au sources into region directories

This cleans up the au directory into regions in line with https://github.com/openaddresses/openaddresses/blob/master/CONTRIBUTING.md#naming-files

act/statewide is broken and has been since 2015 http://results.openaddresses.io/sources/au/city_of_canberra.
I'd like to delete it since the ACT Government doesn't seem to provide their address data as open data currently, but I'm not sure if deleting the source would also clear out the 2015 data which I guess is better than nothing.

We could use the cached data we have from late 2015 as a data source, perhaps? That would keep those ~176k addresses around.

That would be ideal, that's what I'm not sure of, if changing the directory/filename will loose the history that we have at http://results.openaddresses.io/sources/au/city_of_canberra

It’ll lose that specific history, but the address points will still exist someplace which may be a fair trade. We don't really have a smart way of handling file movements.

It’ll lose that specific history, but the address points will still exist someplace which may be a fair trade. We don't really have a smart way of handling file movements.

I'm happy with that then. If the historical address points will still exist somewhere.


Migrate to webpack 4

Assigned to @yamadapc

Related to #1616

I started working on that in #1825.


Update _widget_reader.py - save json

I've edited it and it should work (I've tested saving the data and then loading it from File->OpenFile).  I did this for YtReader and TimeSeriesReader. But the validate_data_model function does not return the model only the JSON. I don't know if it bothers or not but I had a problem converting the returned model to JSON. Besides, there is a hardcoded $schema$ because without it I couldn't load JSON files and I didn't know where I could get it into the function.

Why'd you close the PR?

Oh nevermind, I see you opened a second.


allow users to trap errors from runAsync

Currently errors are trapped by try/catch statement in runAsync, eg:
   runAsync: async (interpreter, code, ...args) => {
        try {
            return await interpreter.doString(clean(code), ...args);
        }
        catch (error) {
            io.get(interpreter).stderr(error);
        }
    },

As a polyscript user I would like to have more granular control on the error being returned from runAsync.
The reason is that there are multiple scripts running on the page outputting to different parts of the page and I need to know which script caused the error and what the error is.  Using io seems too restrictive and I want to be able to handle the error more freely.

As a polyscript user I would like to have more granular control on the error being returned from runAsync.

that's what the io field in define is for, you can fine-tune anything you like, like we will do in PyScript soon.
Please see the documentation around io field when defining custom types ... you can postMessage the error instead, if that's what you are after, or do anything you like, really ... the stderr utility is there exactly to address this use case.
Anything in particular you belive is not working after defining that io.stderr yourself?

Yes.  If I have two blocks of code I have no idea which one triggered io.stderr.

it was a PyScript requirement to be able to intercept errors and show these gracefully or in a custom way ... what you are asking is to re-throw the error as it is after invoking stderr which would result into duplicated errors shown in console if you don't define your own io field ... hence I am not sure what you are asking ... you can define your own stderr and throw errors out of the blue there instead of just logging, or posting these around ... right?
what is it that you are trying to achieve? What is "more granular control" if you can fully control what an error does already?

on a second though, maybe you want a return value that's not just undefined when an error occur? if that's the case, we could think about a solution to that ... but it might require a Symbol you should import and check against its validity to disambiguate with the rest of possible return values ... would that work?
import { ERROR } from 'polyscript';

// ...

const result = interpreter.runAsync(stuff);
if (result === ERROR) {
  // do your thing
}

P.S. if you throw in your custom io.stderr you would solve your issue ... but dare I say my latest suggestion might be desired for ourselves too ... please let me know if that would work for you too, thanks!

ok thats an interesting proposition, throwing in io.sterrr.  probably would work for my case..

If I have two blocks of code I want the errors to be displayed next to each piece of code.  Thats the use case i am trying to aim for.

but I am not sure how that could ever look like.

actually I do ... beforeRunAsync hook gives you a way to store anywhere the current element id, and you can use that info to reach the place where the error occurred ... as you use async results might vary because if you invoke 2 callbacks simultaneously, first come, first serve .... if you don't though, you're good.

the question though is: why do you use multiple scripts at all? each script bootstraps a runtime a part, if the env or the config is different, but you can always combine all of them into one script, which is ideal for both you and this project to handle.

I have multiple charts (eg matplotlib) and each chart is a piece of python code.  If something wrong with the code I would show an error in place of the chart.  Combining them won't help because of variable conflation and error handling.

but do you need those charts in main? they will block and if you try to parallelize these these would block way more ... if you use workers then you have display to show either results or error, if you don't you should resolve each chart one after the other so you won't have issues in there neither ... I think you are, however, mixing too much JS, main, and pyodide on main ... it can work, but your logic is screaming for issues to me, either out of blocked thread, or out of indirections to handle your use cases. I would instead use a worker, 1 to many targets, and store files as a config for the worker so you never block and each chart can be shown one after the other.

P.S. to explain where I come from, multiple PyScript "classic" on a page never really worked by design ... hence my questioning around why suddenly you want to do that ... is it really needed?

Currently workers doesn't work in my app (due to the crossOriginIsolated headers being too strict, no SharedArrayBuffer access) so yes I am using main-thread and it works fine for me.
I could use display to show the results, but not all errors are in user land.  For example there is a typo in the code and pyodide complains, or there are some OOM issues.
I've able to render 12 charts on the main thread no problem, with 100k points each.  Not ideal but it works, and perf is not that bad.
Yes all chart code is resolved one after another.

Here is a screenshot of what I am building.  This is not a fake screenshot but the real product looks more or less similar, has polyscript/pyodide + webR support and it works reasonably well:

this is amazing
how do you include webR? I've tried myself but it was lacking a few primitives, most importantly, it was lacking sync code execution ... did you just for this and added webR out of async features only? ... or did you just use a diffente webR I tried?

thanks!

here is my webR implementation: https://pyscript.com/@bugzpodder/divine-hat-copy/latest
I understand there was a big debate around async vs sync python code, but I really didn't try to understand the details so I can't help beyond this.  But it sounds like you are right and I am only using async features only ie in my demo i just did  await webR.evalRVoid(code);
To be clear here are my feature requirements:

support as many libraries as possible (webR and pyodide takes care of that, I needed to write a custom regex parser to parse packages and install them)
be able to run multiple code blocks and do canvas/svg rendering targeting different DOM elements for each code block
be able to catch and display errors in each code block separately (this issue)
Be able to have arbitrary input data like a dataframe into the python/webR environment

...I needed to write a custom regex parser to parse packages from code blocks and install them

Slightly off-topic, so apologies, but @bugzpodder if you're inspecting code to import packages, you may find Pyodide's loadPackagesFromImports() useful.

...I needed to write a custom regex parser to parse packages from code blocks and install them

Slightly off-topic, so apologies, but @bugzpodder if you're inspecting code to import packages, you may find Pyodide's loadPackagesFromImports() useful.

So actually looking at this right now (and previously) and honestly it's super confusing between this and micropip.  But my understanding is that for custom packages (eg plotly) you'll need micropip.install.  eg 'seaborn' won't work with loadPackagesFromImports but works with micropip.  There is a find_imports in pyodide.code but AFAIK it acts similar to a regex which I already have thanks to a previous PR in pyscript.

The only thing micropip.install won't work is for custom modules (eg if you have import pyscript, pyodide, pyodide_js, etc) and modules from python stdlib which I hard coded.  it would be nice to remove the stdlib entries.
Also some packages have different imports and package names, eg sklearn vs scikit-learn, or some underscore vs dash differences.


Ability to change how a melee weapon is triggered

Description
Right now, melee weapons can only be triggered by left-clicking. This causes problems when these weapons are used as attachments on guns which themselves are triggered when left-clicked.
Proposal: adding the ability to specify how a melee weapon can be triggered, and to have this also work for weapons which specify the melee weapon as a Melee_Attachment
Configuration
Using the existing configuration for setting a trigger serializer. The proposal is to make it also work for melee weapons:
  Shoot:
    Trigger: <TriggerSerializer>

Don't use left click for shooting.


Seeking backward doesn't work well

Pre-fetching only works when playing the video forward in time.  However, when doing an annotation, a user will want to find the beginning of the track, which can involve seeking backward.

Find a fish you want to track
grab the track head and drag backward to look for the fish's first appearance.

result: lots of waiting for an image to appear.

I'm assuming this is referencing the ImageAnnotator, it is the one that has precaching of 10 frames ahead of the current position.
I don't know if this should be tacked onto this or a different issue, but the caching system and playing system has some flaws with slower connections.
There is no waiting system for a specific set of frames to be loaded before playing.  This means that if you have a slower connection and try to play the image list it will just keep skipping ahead and trying to load new frames even if it can't load them in time for the specified frame rate.  It's main goal is to maintain frame rate and not to display the images.

It's main goal is to maintain frame rate and not to display the images.

Yeah I think that's a problem too.  We can break these into other issues if we end up working to fix them.

Updated the caching system so it takes in some arguments for a number of seconds to cache.  Defaulting that right now to 8.  As you play through the scene the caching is a sliding window which continually updates so that should be okay.
The caching now has a specifier for the allocation of time to the left(backwards) and right(forwards) of the current frame.  Specified as a number less than 1 it will use that number for the forward amount.  IE frontBackRatio=0.75 means that 75% of the specified cache time will look ahead while 25% will look backwards.
I've updated the playback so that if you encounter an image source in which .complete is falsey it will stop the playback and check the cache to make sure at least a user specified number of seconds (defaulted to 3 I believe) are available in their entirety before playing back again.  The same thing occurs if you attempt to hit play right after seeking.  It will wait for at least the minimum amount is available before resuming the playback.  This will displaying a loading spinner while waiting,  We can change this to a different icon, css animation or GIF if wanted.

Things left to do:

[ ] I feel like the seeking and loading of a new single frame while seeking is taking too long.  Like it isn't properly killing the other requests for image data and is spending time waiting for other images before being able to seek.  I need to look into this a bit better

[ ] Part of the above issue is that the caching shouldn't start at the minimum number (which is behind the current frame).  It would start at the currently seeked frame and then work it's way out in both directions from there.  Maybe even giving priority to the forward direction.

[ ] .complete on an Image object has some caveats referenced in the MDN documentation.  Make sure these corner cases don't impact the caching system:MDN docs for image.complete


Contribution to dev-tips

Thanks for the awesome tips so far @umaar!  Are you looking for contributions to dev-tips?

I'd appreciate contributions to the project like:

Feedback on tips.
Sharing what you think is useful to other channels.

Thanks!

Okay! Sure!


ActionGroup button is missing its right border if next to a disabled button

🐛 Bug Report

See "overflowMode: collapse disabledKeys" story, right border is missing when un-collapsed

🤔 Expected Behavior
right border of the Move button should exist
😯 Current Behavior
right border of the Move button doesn't exist
🧢 Your Company/Team
RSP

I'm happy to work on this issue!

I think https://github.com/another-maverick is taking this one already @paulgpeterson. Anything else you'd like to work on?

I just joined the slack channel and saw the discussion! Sure, I'll find something else.

this one go fixed with #2710

Yes it did, thank you for the comment


Discussion - Sass

We've Sassified our workflow! You can now access all of the mighty powers that Sass offers, including mixins, functions, and variables! We're really looking forward to seeing how people use variables within the new Foundation for Emails. The idea is to update a variable within your _settings.scss, such as a primary color, and see your style cascade everywhere it needs to go! We're interested in a few things around this:

Do we have the all the variables you expected?
How often do you think you'll use these Sass variables?
Did it work like you'd expect?

This issue was moved to zurb/ink#161


Not parsing Curl Command

curl -v -H "Content-Type: application/json" -H "X-API-Version: 200" -d '{"userName":"username123","password":"password123", "authLoginDomain":"local"}' -X POST -k https://<IP_ADDRESS>/rest/login-sessions

Fixed in 1.9.0. Thanks for the report.


GenerateReleaseNotes task - show test results

Look at including any tests associated with the build/release
Not sure if there may be issues with any test just run not being available

Had a bit of a look at this, not sure what data to make available. In initially I thought it could be actual tests, but if there are unit tests there could be a huge number. Probably better to just list test runs with pass/fail and maybe coverage.


Dark mode added

Description
Night switch with css and js
Retainable property
Fixes:  #740

Type of change
It can retain the last theme from memory

[ ] Bug fix (non-breaking change which fixes an issue)
[ ✔] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[✔ ] I have made this from my own
[ ✔] I have taken help from some online resourses and mentioned in PR
[ ✔] My code follows the style guidelines of this project
[✔ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

@arpit456jain I have made PR . Kindly merge it under hacktoberfest-accepted.


typo: Double word "Active"

Capitalized "Directory" too

@nschonni : Thanks for your contribution! The author, @asmalser-msft, has been notified to review your proposed change.

I sign-off too, thanks #sign-off


Possible to release projector weights too?

Hi,
Thanks for releasing the pre-trained weights for the ResNet-50 backbone! Would it be possible to also release the weights of the pre-trained projector associated with the pre-trained ResNet-50?
This would be extra helpful for downstream tasks where there is considerably more unlabeled than labeled data, making it easy to fine-tune the whole model (backbone encoder + projector) by minimizing the BT loss on the unlabeled samples prior to training a classifier on the labeled subset.

Yes, absolutely. I've update the README to include the link to the full checkpoint.


[redux-actions_v2.x.x] createAction doesn't return Function

Since the last change a33adf993162d655d6822b2ec9c37da73edd7e3c flow is complaining about the wrong type because the return type of createAction isn't a function anymore. Instead the new type is an object which can't be used as a type.
The following Flow output shows what the problem is:
Cannot use object type as a type because object type is a value. To get the type of a value use typeof.

      7│ import { add } from './actions';
      8│
      9│ type Props = {
     10│   add: add
     11│ }
     12│
     13│ class App extends React.Component<Props> {

I found a question on Stackoverflow which is about the same problem: https://stackoverflow.com/questions/39671873/flowtype-annotation-for-callback/39678032

I spent more time investigation the bug and it seems that there is no other solution. It tried to create an intersection type ((() => {}) & { toString: () => T } but this resulted in different errors.
It's a little bit strange that the bug occurred after the change and never before. Also that only a few actions have the wrong type. Here a short example:
type Props = {
	add: add, // => Error
    remove: remove // => Good
}

@floriangosse I would say that as a rule of thumb always use typeof. I did some testing and while Flow accepts you to use function as type in some cases, the type is very loose and you can pass what ever to it. With typeof Flow is able to infer more.

Ok, thanks. I already started using typeof - first at the places where flow is complaining about it.
Thanks for your help. :) I will close this issue.


why are relationships ordered?

Why is the Relationship class ordered by using @total_ordering ?
When will you ever compare relationships to sort them?

@zvr there is no particular use of total_ordering but it is also used in Annotator class (which is pretty similar in working with relationship) so for maintaining code similarity, I used it here.

Unless there is a reason, I'd suggest you remove all this extra code.

I've removed the total_ordering feature from relationship.py file


python310Packages.python-barcode: 0.14.0 -> 0.15.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.python-barcode is: Create standard barcodes with Python
meta.homepage for python310Packages.python-barcode is: https://github.com/WhyNotHugo/python-barcode
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.15.1 with grep in /nix/store/mwv018vrp2cpa1zdwb9nl2j7d2318zaa-python3.10-python-barcode-0.15.1
found 0.15.1 in filename of file in /nix/store/mwv018vrp2cpa1zdwb9nl2j7d2318zaa-python3.10-python-barcode-0.15.1

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

8 total rebuild path(s)

8 package rebuild(s)

First fifty rebuilds by attrpath
maigret
python310Packages.pyhanko
python310Packages.python-barcode
python310Packages.xhtml2pdf
python311Packages.pyhanko
python311Packages.python-barcode
python311Packages.xhtml2pdf
sasview

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/mwv018vrp2cpa1zdwb9nl2j7d2318zaa-python3.10-python-barcode-0.15.1 \
  --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 python310Packages.python-barcode https://github.com/r-ryantm/nixpkgs/archive/e5f5a9d28a67057d7699d02a81a16294e2ed590f.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/mwv018vrp2cpa1zdwb9nl2j7d2318zaa-python3.10-python-barcode-0.15.1
ls -la /nix/store/mwv018vrp2cpa1zdwb9nl2j7d2318zaa-python3.10-python-barcode-0.15.1/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

8 packages built:

maigret
python310Packages.pyhanko
python310Packages.python-barcode
python310Packages.xhtml2pdf
python311Packages.pyhanko
python311Packages.python-barcode
python311Packages.xhtml2pdf
sasview

Maintainer pings
cc @WolfangAukang for testing.

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

16 packages built:

maigret
maigret.dist
python310Packages.pyhanko
python310Packages.pyhanko.dist
python310Packages.python-barcode
python310Packages.python-barcode.dist
python310Packages.xhtml2pdf
python310Packages.xhtml2pdf.dist
python311Packages.pyhanko
python311Packages.pyhanko.dist
python311Packages.python-barcode
python311Packages.python-barcode.dist
python311Packages.xhtml2pdf
python311Packages.xhtml2pdf.dist
sasview
sasview.dist


Add test functions to test new unify function

Adds test functions to test unify_bad_channels.

@anaradanovic Hi Ana! Let's hold off on merging this until we can chat more tomorrow :)

Ok, pytest is passing!!!

@anaradanovic Hi Ana! Ok, Dan thinks that we're ready to accept this PR.

Ok, now, actually for real we're ready to accept this PR!

indeed!  @anaradanovic please merge this one, then we'll do a final review/merge of the combined work


prev button not working

this.callbacks.onPrevious is not a function

Hello!
Thanks for this nice little wizard!
I have the same issue, for both the onNext and onPrevious.

Hello @weber-s
Ops, indeed. My bad! 😅
It worked like a charm. I already commited this fix.
Thank you for your suggestion.


Upgrade to QuickJS NG

Description of changes
This PR upgrades LLRT to use QuickJS NG.
QuickJS-NG (Next Generation) is a better maintained community owned fork of the original QuickJS source. This fork has a lot of bug fixes, significant performance improvements and more recent ECMA support

Currently there are a few things that's broken. "performance" intrinsic is enabled by default and not writable. A PR has been merged in upstream making it writable
Custom allocators are causing segfaults
Also child_process rust tests are failing due to TypeId not being stable resulting in corrupted Class/Function Vtables. Very strange since it only behaves so for child_process rust test and not anywhere else.

Checklist

[x] Created unit tests in tests/unit and/or in Rust for my feature if needed
[x] Ran make fix to format JS and apply Clippy auto fixes
[x] Made sure my code didn't add any additional warnings: make check
[x] Added relevant type info in types/ directory
[x] Updated documentation if needed (API.md/README.md/Other)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

🎉


Get segmentation fault with FFT callback function

pr.py
import numpy as np
import cupy as cp

code = r'''
__device__ cufftComplex CB_ConvertInput(
    void *dataIn,
    size_t offset,
    void *callerInfo,
    void *sharedPtr) {
            return make_float2(0.0, 0.1);
}

__device__ cufftCallbackLoadC d_loadCallbackPtr = CB_ConvertInput;
'''

in_arr = cp.random.rand(12, dtype=np.float32)

with cp.fft.config.set_cufft_callbacks(cb_load=code):
    out_arr = cp.fft.fft(in_arr)

print(out_arr)

Run with
CUDA_VISIBLE_DEVICES=0 python pr.py

Then I got
[1]    410392 segmentation fault (core dumped)  CUDA_VISIBLE_DEVICES=0 python pr.py

My system information:
OS                           : Linux-5.12.8-arch1-1-x86_64-with-glibc2.33
Python Version               : 3.9.5
CuPy Version                 : 9.1.0
CuPy Platform                : NVIDIA CUDA
NumPy Version                : 1.20.0
SciPy Version                : 1.6.3
Cython Build Version         : 0.29.23
Cython Runtime Version       : 0.29.23
CUDA Root                    : /opt/cuda
nvcc PATH                    : /opt/cuda/bin/nvcc
CUDA Build Version           : 11030
CUDA Driver Version          : 11030
CUDA Runtime Version         : 11030
cuBLAS Version               : 11402
cuFFT Version                : 10402
cuRAND Version               : 10204
cuSOLVER Version             : (11, 1, 1)
cuSPARSE Version             : 11500
NVRTC Version                : (11, 3)
Thrust Version               : 101100
CUB Build Version            : 101100
Jitify Build Version         : 60e9e72
cuDNN Build Version          : 8200
cuDNN Version                : 8200
NCCL Build Version           : 20906
NCCL Runtime Version         : 20906
cuTENSOR Version             : None
cuSPARSELt Build Version     : None
Device 0 Name                : NVIDIA GeForce GTX 1080
Device 0 Compute Capability  : 61
Device 0 PCI Bus ID          : 0000:17:00.0
Device 1 Name                : NVIDIA Quadro K600
Device 1 Compute Capability  : 30
Device 1 PCI Bus ID          : 0000:65:00.0

I cannot reproduce this. Your reproducer runs fine on my system with both CUDA 11.2 & 11.3 (and driver 11.3). If you can run gdb on the dumped core we could get some hints. Another thing to try is to clear the existing cache (~/.cupy/callback_cache or perhaps just everything under ~/.cupy/).

btw what's your OS and how Python and CuPy were installed?

@leofang
My system is archlinux. The cupy is installed from archlinuxcn/python-cupy.
After deleting .cupy folder, I got a warning before the segmentation fault.
nvprune warning : No device code that matched architecture, so stripped out all device code

CUDA_VISIBLE_DEVICES=0 valgrind python pr.py

part of valgrind output

```
==646703== Use of uninitialised value of size 8
==646703==    at 0x49B77B2: PyObject_Realloc (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49EB528: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ED788: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ED673: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A6201E: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ED673: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A6201E: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ED673: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49E9445: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A61056: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49E98C9: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A61056: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==
==646703== Invalid read of size 4
==646703==    at 0x498E282: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A77656: PyObject_Dir (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A77595: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49BE127: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A6512: _PyObject_MakeTpCall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A1F85: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADADA: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A1E66: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499BC00: _PyEval_EvalCodeWithName (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A52D62: PyEval_EvalCode (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A59C8B: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==  Address 0x7394020 is 80 bytes inside a block of size 1,112 free'd
==646703==    at 0x484118B: free (vg_replace_malloc.c:755)
==646703==    by 0x4989147: PyObject_Free (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4988956: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x498C3FF: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49925DF: PyDict_SetItemString (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49BD52A: PyModule_AddObject (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49D3B3C: PyModule_AddIntConstant (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x5450AD02: PyInit__socket (in /usr/lib/python3.9/lib-dynload/_socket.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x4A7E11E: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AE5A7: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A30EA: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==  Block was alloc'd at
==646703==    at 0x483E7C5: malloc (vg_replace_malloc.c:380)
==646703==    by 0x4984F03: PyObject_Malloc (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x498884C: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x498C3FF: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49932DB: _PyObject_GenericSetAttrWithDict (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4992CDC: PyObject_SetAttr (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4992C52: PyObject_SetAttrString (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A51385: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A512CD: PyModule_AddFunctions (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A5101E: _PyModule_CreateInitialized (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x5450AB54: PyInit__socket (in /usr/lib/python3.9/lib-dynload/_socket.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x4A7E11E: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==
==646703== Invalid read of size 4
==646703==    at 0x498D832: PyMem_Free (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49F73EC: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499ED87: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADADA: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499D566: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499BC00: _PyEval_EvalCodeWithName (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A52D62: PyEval_EvalCode (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A59C8B: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AE5A7: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A30EA: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==  Address 0x75eb020 is 224 bytes inside a block of size 576 free'd
==646703==    at 0x484118B: free (vg_replace_malloc.c:755)
==646703==    by 0x4989147: PyObject_Free (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4988956: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x498C3FF: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499F2BA: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499BC00: _PyEval_EvalCodeWithName (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A52D62: PyEval_EvalCode (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A59C8B: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AE5A7: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A30EA: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==  Block was alloc'd at
==646703==    at 0x483E7C5: malloc (vg_replace_malloc.c:380)
==646703==    by 0x4984F03: PyObject_Malloc (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x498884C: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x498C3FF: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499F2BA: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499BC00: _PyEval_EvalCodeWithName (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A52D62: PyEval_EvalCode (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A59C8B: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AE5A7: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A30EA: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==
==646703== Conditional jump or move depends on uninitialised value(s)
==646703==    at 0x4A1E693: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49DB768: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499D7B9: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADCFD: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A1E66: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x521B9BD0: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521BAFC6: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521C6911: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521E3249: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x49A652A: _PyObject_MakeTpCall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A260A: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==
==646703== Use of uninitialised value of size 8
==646703==    at 0x4A1E6AB: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49DB768: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499D7B9: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADCFD: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A1E66: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x521B9BD0: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521BAFC6: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521C6911: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521E3249: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x49A652A: _PyObject_MakeTpCall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A260A: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==
==646703== Warning: noted but unhandled ioctl 0x30000001 with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Warning: noted but unhandled ioctl 0x27 with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Warning: noted but unhandled ioctl 0x25 with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Warning: noted but unhandled ioctl 0x37 with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Warning: noted but unhandled ioctl 0x17 with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Warning: set address range perms: large range [0x200000000, 0x300200000) (noaccess)
==646703== Warning: set address range perms: large range [0x761b5000, 0x961b4000) (noaccess)
==646703== Warning: noted but unhandled ioctl 0x19 with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Warning: set address range perms: large range [0x10006000000, 0x10106000000) (noaccess)
==646703== Warning: noted but unhandled ioctl 0x49 with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Warning: noted but unhandled ioctl 0x21 with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Warning: noted but unhandled ioctl 0x1b with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Warning: noted but unhandled ioctl 0x44 with no size/direction hints.
==646703==    This could cause spurious value errors to appear.
==646703==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==646703== Conditional jump or move depends on uninitialised value(s)
==646703==    at 0x49B22CE: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A982C1: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AE5A7: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x15AE9439: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B0D40D: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B1EE88: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521D3411: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521E1666: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x49BE0FD: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x160C1277: ??? (in /usr/lib/python3.9/site-packages/cupy/_util.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521E8023: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521FA96B: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==
==646703== Invalid read of size 4
==646703==    at 0x49B22C4: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A982C1: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AE5A7: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x15AE9439: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B0D40D: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B1EE88: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521D3411: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521E1666: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x49BE0FD: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x160C1277: ??? (in /usr/lib/python3.9/site-packages/cupy/_util.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521E8023: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521FA96B: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==  Address 0x5b80020 is 1,968 bytes inside a block of size 4,333 free'd
==646703==    at 0x484383F: realloc (vg_replace_malloc.c:1192)
==646703==    by 0x49F36A8: _PyBytes_Resize (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A65256: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AB3B8: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A44F5B: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A64D4D: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49BD713: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49B4086: PyObject_VectorcallMethod (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A98281: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AE5A7: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x15AE9439: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B0D40D: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==  Block was alloc'd at
==646703==    at 0x483E7C5: malloc (vg_replace_malloc.c:380)
==646703==    by 0x499A233: PyBytes_FromStringAndSize (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A651FE: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AB3B8: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A44F5B: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A64D4D: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49BD713: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49B4086: PyObject_VectorcallMethod (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A98281: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49AE5A7: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x15AE9439: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B0D40D: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==
==646703== Conditional jump or move depends on uninitialised value(s)
==646703==    at 0x49B7479: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49B6DD6: _PyUnicodeWriter_PrepareInternal (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A0C895: PyUnicode_Format (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A2BE9: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADCFD: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499D566: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADCFD: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49BD450: PyVectorcall_Call (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x15AE218E: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B1F9C1: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==
==646703== Use of uninitialised value of size 8
==646703==    at 0x49B7491: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49B6DD6: _PyUnicodeWriter_PrepareInternal (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x4A0C895: PyUnicode_Format (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49A2BE9: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADCFD: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499D566: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADCFD: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49BD450: PyVectorcall_Call (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x15AE218E: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B1F9C1: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==
==646703== Conditional jump or move depends on uninitialised value(s)
==646703==    at 0x4988BDC: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x521D32C0: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521DFD19: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521F6DF2: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15AE218E: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B33B17: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15AF1009: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x49AFA7A: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499D7B9: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADADA: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499D566: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==
==646703== Use of uninitialised value of size 8
==646703==    at 0x4988BF4: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x521D32C0: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521DFD19: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x521F6DF2: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/_kernel.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15AE218E: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15B33B17: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x15AF1009: ??? (in /usr/lib/python3.9/site-packages/cupy/_core/core.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x49AFA7A: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499D7B9: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x49ADADA: _PyFunction_Vectorcall (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499D566: _PyEval_EvalFrameDefault (in /usr/lib/libpython3.9.so.1.0)
==646703==    by 0x499C218: ??? (in /usr/lib/libpython3.9.so.1.0)
==646703==
==646703== Conditional jump or move depends on uninitialised value(s)
==646703==    at 0x44243004: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x43FE5391: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x440ADFF4: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x7D67ACE4: DSELaunch::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D614FD7: StridedMultiKernel::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6514FE: Callback::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61D02C: Queue::launch(device const&, fftDynamicParameters&, void*, void*, void const*, Pitch, Pitch, Pitch, unsigned int, Dim) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6FA99C: fftDimensionCT::exec(device const&, fftDynamicParameters&, void*, void*, void const*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61A721: fftCooleyTukeyC2C::exec(void*, void*, void const*, fftDynamicParameters const&, device const&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5FD2F3: Visitors::Execute::operator()(Operation::Queue&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EEFC1: cufftExecuteDescriptor(fftHandleStruct*, cudaLibXtDesc_t*, cudaLibXtDesc_t*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EF12F: cufftExecute(fftHandleStruct*, void*, void*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==
==646703== Use of uninitialised value of size 8
==646703==    at 0x4424300C: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x43FE5391: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x440ADFF4: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x7D67ACE4: DSELaunch::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D614FD7: StridedMultiKernel::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6514FE: Callback::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61D02C: Queue::launch(device const&, fftDynamicParameters&, void*, void*, void const*, Pitch, Pitch, Pitch, unsigned int, Dim) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6FA99C: fftDimensionCT::exec(device const&, fftDynamicParameters&, void*, void*, void const*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61A721: fftCooleyTukeyC2C::exec(void*, void*, void const*, fftDynamicParameters const&, device const&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5FD2F3: Visitors::Execute::operator()(Operation::Queue&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EEFC1: cufftExecuteDescriptor(fftHandleStruct*, cudaLibXtDesc_t*, cudaLibXtDesc_t*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EF12F: cufftExecute(fftHandleStruct*, void*, void*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==
==646703== Use of uninitialised value of size 8
==646703==    at 0x44243010: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x43FE5391: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x440ADFF4: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x7D67ACE4: DSELaunch::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D614FD7: StridedMultiKernel::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6514FE: Callback::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61D02C: Queue::launch(device const&, fftDynamicParameters&, void*, void*, void const*, Pitch, Pitch, Pitch, unsigned int, Dim) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6FA99C: fftDimensionCT::exec(device const&, fftDynamicParameters&, void*, void*, void const*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61A721: fftCooleyTukeyC2C::exec(void*, void*, void const*, fftDynamicParameters const&, device const&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5FD2F3: Visitors::Execute::operator()(Operation::Queue&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EEFC1: cufftExecuteDescriptor(fftHandleStruct*, cudaLibXtDesc_t*, cudaLibXtDesc_t*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EF12F: cufftExecute(fftHandleStruct*, void*, void*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==
==646703== Invalid read of size 8
==646703==    at 0x44243010: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x43FE5391: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x440ADFF4: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x7D67ACE4: DSELaunch::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D614FD7: StridedMultiKernel::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6514FE: Callback::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61D02C: Queue::launch(device const&, fftDynamicParameters&, void*, void*, void const*, Pitch, Pitch, Pitch, unsigned int, Dim) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6FA99C: fftDimensionCT::exec(device const&, fftDynamicParameters&, void*, void*, void const*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61A721: fftCooleyTukeyC2C::exec(void*, void*, void const*, fftDynamicParameters const&, device const&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5FD2F3: Visitors::Execute::operator()(Operation::Queue&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EEFC1: cufftExecuteDescriptor(fftHandleStruct*, cudaLibXtDesc_t*, cudaLibXtDesc_t*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EF12F: cufftExecute(fftHandleStruct*, void*, void*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==646703==
==646703==
==646703== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==646703==  Access not within mapped region at address 0x18
==646703==    at 0x44243010: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x43FE5391: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x440ADFF4: ??? (in /usr/lib/libcuda.so.465.31)
==646703==    by 0x7D67ACE4: DSELaunch::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D614FD7: StridedMultiKernel::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6514FE: Callback::proc(fftDynamicParameters const&, device const&, void*, void const*, unsigned int, Dim, Pitch, Pitch, unsigned long long, unsigned long long, unsigned long long, unsigned long long) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61D02C: Queue::launch(device const&, fftDynamicParameters&, void*, void*, void const*, Pitch, Pitch, Pitch, unsigned int, Dim) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D6FA99C: fftDimensionCT::exec(device const&, fftDynamicParameters&, void*, void*, void const*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D61A721: fftCooleyTukeyC2C::exec(void*, void*, void const*, fftDynamicParameters const&, device const&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5FD2F3: Visitors::Execute::operator()(Operation::Queue&) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EEFC1: cufftExecuteDescriptor(fftHandleStruct*, cudaLibXtDesc_t*, cudaLibXtDesc_t*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==    by 0x7D5EF12F: cufftExecute(fftHandleStruct*, void*, void*) (in /home/sz/.cupy/callback_cache/cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so)
==646703==  If you believe this happened as a result of a stack
==646703==  overflow in your program's main thread (unlikely but
==646703==  possible), you can try to increase the size of the
==646703==  main thread stack using the --main-stacksize= flag.
==646703==  The main thread stack size used in this run was 8388608.
==646703==
==646703== HEAP SUMMARY:
==646703==     in use at exit: 68,190,220 bytes in 72,927 blocks
==646703==   total heap usage: 147,982 allocs, 75,055 frees, 221,211,609 bytes allocated
==646703==
==646703== LEAK SUMMARY:
==646703==    definitely lost: 0 bytes in 0 blocks
==646703==    indirectly lost: 0 bytes in 0 blocks
==646703==      possibly lost: 326,214 bytes in 1,175 blocks
==646703==    still reachable: 67,838,838 bytes in 71,747 blocks
==646703==         suppressed: 25,168 bytes in 5 blocks
==646703== Rerun with --leak-check=full to see details of leaked memory
==646703==
==646703== Use --track-origins=yes to see where uninitialised values come from
==646703== For lists of detected and suppressed errors, rerun with: -s
==646703== ERROR SUMMARY: 9468 errors from 203 contexts (suppressed: 4 from 2)
```

My system is archlinux. The cupy is installed from archlinuxcn/python-cupy.
After deleting .cupy folder, I got a warning before the segmentation fault.

nvprune warning : No device code that matched architecture, so stripped out all device code

@szsdk This is interesting 🤔 Looks like cufft's static library does not contain device code for sm61. I will do a few checks when I can access my workstation, and in the meanwhile could you check this: go to ~/.cupy/callback_cache/, and there should be at least 1 static library named libcufft_static_xxxxx_sm61.a. What is the file size of it? I guess it is very small.

@leofang These are files in my folder:
.rwxr-xr-x 7.8M sz 31 May 17:03 cupy_callback_48c7d38101a2a47abcd2b647b8c2cc81.cpython-39-x86_64-linux-gnu.so
.rw-r--r--  18M sz 31 May 17:03 libcufft_static_10402_sm61.a

Thanks, @szsdk. I will send a patch to fix this.
On CUDA 11.3:
import os
import sys
import subprocess
import cupy as cp

sm_list = cp.cuda.nvrtc.getSupportedArchs()
print(sm_list)
for i in sm_list:
    print(f"on sm_{i}...")
    #p = subprocess.run(['echo', str(i)])
    p = subprocess.run(['nvprune', '-arch', f'sm_{i}', '/usr/local/cuda-11.3/lib64/libcufft_static.a', '-o', 'temp.a'], env=os.environ)
    if p.stderr:
        print(p.stderr)
    else:
        print("OK")

Output:
(35, 37, 50, 52, 53, 60, 61, 62, 70, 72, 75, 80, 86)
on sm_35...
OK
on sm_37...
nvprune warning : No device code that matched architecture, so stripped out all device code
OK
on sm_50...
OK
on sm_52...
nvprune warning : No device code that matched architecture, so stripped out all device code
OK
on sm_53...
nvprune warning : No device code that matched architecture, so stripped out all device code
OK
on sm_60...
OK
on sm_61...
nvprune warning : No device code that matched architecture, so stripped out all device code
OK
on sm_62...
nvprune warning : No device code that matched architecture, so stripped out all device code
OK
on sm_70...
OK
on sm_72...
nvprune warning : No device code that matched architecture, so stripped out all device code
OK
on sm_75...
OK
on sm_80...
OK
on sm_86...
OK

@szsdk I sent a patch (#5304). But I have another question: Do you get any stdout/stderr outputs other than the nvprune warning and the segfault? If libcufft_static_10402_sm61.a does not contain any device code, shouldn't nvcc fail at the linking stage? I am a bit concerned that we get a segfault directly instead of an error.

But I have another question: Do you get any stdout/stderr outputs other than the nvprune warning and the segfault? If libcufft_static_10402_sm61.a does not contain any device code, shouldn't nvcc fail at the linking stage? I am a bit concerned that we get a segfault directly instead of an error.

I ran a local test myself and nvcc did not complain...Very strange.

@leofang The warning and segfault were all I got.

@leofang  I have access to another NVIDIA 1080 machine. I get the same warning (copy 9.10), but not segfault.

Hmm this is strange...Is it with or without my patch? Have you checked if the output is correct?

Let me clarify.
This is an another NVIDIA 1080 card. I installed cupy with pip install cupy. The version of cupy is 9.1.0, without your patch.
This is my test code.
import numpy as np
import cupy as cp

code = r'''
__device__ cufftComplex CB_ConvertInput(
    void *dataIn,
    size_t offset,
    void *callerInfo,
    void *sharedPtr) {
            return make_float2(1.0, 0.0);
}

__device__ cufftCallbackLoadC d_loadCallbackPtr = CB_ConvertInput;
'''

in_arr = cp.random.rand(12, dtype=np.float32)

with cp.fft.config.set_cufft_callbacks(cb_load=code):
    out_arr = cp.fft.fft(in_arr)

print(cp.__version__)
print(out_arr)
print(cp.fft.fft(cp.ones(12)))

This is the output.
/home/szsdk/anaconda3/lib/python3.8/site-packages/cupy/fft/_fft.py:149: UserWarning: cuFFT plan cache is disabled on CUDA 11.1 due to a known bug, so performance may be degraded. The bug is fixed on CUDA 11.2+.
  cache = get_plan_cache()
9.1.0
[0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j
 0.+0.j 0.+0.j]
[12.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j
  0.+0.j  0.+0.j  0.+0.j]

I do not think I get the correct answer. From my understand, the answer should be the last line. I am new to this callback function. Please correct me if I am wrong.

I get the same result with another 980 machine. Same cupy installation.
9.1.0
[0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j
 0.+0.j 0.+0.j]
[12.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j  0.+0.j
  0.+0.j  0.+0.j  0.+0.j]

Yes, you're right: for the test input (a flat signal) we should get a single nonzero value at the zero frequency. It's nice that you have access to both 980 and 1080! If we can fix one (#5304) we fix them all. They are the same corner case.

Sure. This is my output.
# make
>>> GCC Version is greater or equal to  5.3.0 <<<
/opt/cuda/bin/nvcc -ccbin g++ -I../../common/inc -m64 -dc -std=c++11 --threads 0 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_70,code=sm_70 -gencode arch=compute_75,code=sm_75 -gencode arch=compute_80,code=sm_80 -gencode arch=compute_86,code=sm_86 -gencode arch=compute_86,code=compute_86 -o simpleCUFFT_callback.o -c simpleCUFFT_callback.cu
nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' and 'sm_50' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
/opt/cuda/bin/nvcc -ccbin g++ -m64 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_70,code=sm_70 -gencode arch=compute_75,code=sm_75 -gencode arch=compute_80,code=sm_80 -gencode arch=compute_86,code=sm_86 -gencode arch=compute_86,code=compute_86 -o simpleCUFFT_callback simpleCUFFT_callback.o -L/usr/lib/x86_64-linux-gnu -L/usr/lib64 -lcufft_static -lculibos
nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' and 'sm_50' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
mkdir -p ../../bin/x86_64/linux/release
cp simpleCUFFT_callback ../../bin/x86_64/linux/release

# ./simpleCUFFT_callback
[simpleCUFFT_callback] is starting...
GPU Device 0: "Pascal" with compute capability 6.1

Transforming signal cufftExecC2C
Transforming signal back cufftExecC2C

Thanks, looks like it should just work on Arch Linux.

@leofang  I tested both my 1080 machines. And the new patch (cf78fbf86eec6a8a4baef2d5628bb96130c4879) works on both.
Cheers.
But I cannot compile cupy from source on my 980 machine. It complains that cudnn.h is missing. The dependency on cudnn is optional, isn't it?

Thanks, @szsdk. So #5304 should be good to go.
Yeah cuDNN is optional. Could you post the full log for the failed build? The actual cause might be buried somewhere.

install.log
I attached the output of my installation. @leofang

@szsdk Could you clear all files and rebuild? git clean -fdx I think there are some leftover files from a previous build that are incompatible with your current environment.

@leofang Thanks, everything works now on the 980 workstation.


Scrollable Dialog outside of content

I have a Dialog that is long, vertically, and autoScrollBodyContent={true} set, so that the content scrolls.
What I'd like to have happen is that when using the scrollbar/trackpad/mobile device to scroll outside of the Dialog, the content area also scrolls so that the user is not forced to target the content area.
Is this functionality achievable with any version of material-ui, or is this a pattern that should be avoided? I've tried adding event listeners to scroll, it doesn't get fired because the underlying page isn't scrollable due to Dialog being open.

@dlcoffee Is it a duplicate of #7438?

@oliviertassinari yeah i think it's very similar. the solutions in that issue are for mobile only and suggest using a full screen Dialog instead. I was wondering if this would be possible for a regular sized Dialog on all devices. Maybe I should close this issue and comment on that one instead?

@dlcoffee Alright, let's move the discussion to the other issue.


[Wrangler Ignore option 2] exclude/include logic in wrangler.toml for static asset uploads

This PR is the secondary implementation/option to close #716. The first option is #720.
Wrangler will look at wrangler.toml's site section for fields to ignore:
[site]
bucket = "./public"
entry-point = "workers-site"
include = ["included_dir"] # optional
exclude = ["excluded_dir"] # optional

The include and exclude fields will apply to the bucket directory. Its behavior above is exactly the same as https://github.com/ashleygwilliams/cargo-generate#include--exclude (this is also the standard for cargo).
Keep in mind that, consistent with other implementations of include/exclude, the include field always overrides the exclude one.
This PR also contains a bunch of unit tests to ensure that our exclude/include logic works as expected.

@EverlastingBugstopper responding to questions:

There is no output about what's being ignored, given that the user explicitly already states what should be ignored in the wrangler.toml file. I can definitely add some info text about node_modules being ignored, though.
You can't really use .gitignore with the paths like ./img--it's a bit of an antipattern, you usually just provide img/. The same applies for this approach with exclude/include. This is because these types of ignore patterns can come from a .ignore file anywhere in a project, so using relative paths dependent on . is unsafe.
I can definitely make the error message a bit better and remind folks to use an array if they just provide a string.
I'll add info logs for everything ignored. :)

Makes sense - re no. 2, do you think it makes sense to print a message::warn when something that is in an include or an exclude is not recognized? is that possible? like "hey looks like you wanna ignore this but i have no idea what that even is". maybe not necessary but might be helpful. the info logs might be enough for this

@EverlastingBugstopper I might wait until we see a ticket related to git entries starting with ./ -- I feel like this case is unlikely, but if an issue is filed, I will definitely add additional hand-holding logic!


Added compatibility for IE and web workers.

@florianebmeier You will need this before deploying new authly versions to front end projects.


Range-ify std.string.leftJustify() with leftJustifier()

http://dlang.org/phobos/std_string.html#.leftJustify
Unit tests at 100%.

LGTM

Do you think consistency with #3224 is worth the trouble?

LGTM

noice

Auto-merge toggled on


[BUG] Promise response not expected ;(

Before posting a bug, be sure that someone else has not posted it already and it is an actual bug with noblox.js and not other frameworks like discord.js
Describe the bug
When i try to get player information / blurb / status, etc
To Reproduce
Steps to reproduce the behavior:

Try to get a player information

Expected behavior
Return player information / blurb / status
Screenshots

Additional context
_Promise [Object] {
_bitField: 0,
_fulfillmentHandler0: undefined,
_rejectionHandler0: undefined,
_promise0: undefined,
_receiver0: undefined,
_cancellationParent: Promise [Object] {
_bitField: 1,
_fulfillmentHandler0: [Function],
_rejectionHandler0: undefined,
_promise0: [Circular],
_receiver0: undefined,
_cancellationParent: Promise [Object] {
_bitField: 1,
_fulfillmentHandler0: [Function],
_rejectionHandler0: undefined,
_promise0: [Circular],
_receiver0: undefined,
_onCancelField: [Function],
_branchesRemainingToCancel: 1
},
_branchesRemainingToCancel: 1
}
_

Fixed

https://github.com/sentanos/roblox-js/issues/36


Filtering on variants results in different set of variants when launching saved analysis vs. launching with variant set.

See Analysis A1130. There are 126 filtered variants that don't pass any of the gene.iobio standard filters. These are not showing up in the saved analysis.
Also, there is a De novo variant that doesn't show up under the De novo filter when launched from the variant set (called Slivar filtered variants). But when launching from the saved analysis, the De novo variant does show up under the appropriate filter.

Notice that the variant shows up under 'filtered variants' when gene.iobio launched with the variant set. This is b/c it doesn't match the De novo filter since it is an inframe deletion. So why does it pass the filter after it is saved as an analysis??

In particular, there is a de novo variant in gene SPRX that is in the 'slivar prioritized variant'. When gene.iobio is launched with the variant set, this variant shows up under 'filtered variants', meaning it didn't pass any of the standard filters, which is odd, b/c it does seem to pass the 'De novo' filter criteria. Then, if I click on the gene in the genes panel, the variant moves under the 'De novo variants' filter.
You can try this by launching with the 'Tony - troubleshooting SPRX' variant set.

So we know there are a few problems here:

The filters should be sorted based on the way they are originally ordered on a fresh launch of gene.iobio. This order is not being maintained when launching a saved analysis.
The 'filtered variants' (variants in variant set, but not passing any of the gene.iobio filters) are getting lost after saving analysis. These variants need to be restored when the saved analysis is launched
There is an inconsistency in how a variant is passing a filter when launched from a variant set vs when the gene is clicked.


User can save a page after successful verification and is capable of importing that page to mediawiki

Best way might be to request the whole page via the standard mediawiki API and add our verification data inside of it, like we do it in the php version.

already implemented in data-accounting-external-verifier
./verified_import.js

Needs to be exposed via the UI.


Use global namespace for all native functions

Solve issue #46.
This should give a minor performance improvement.

The build is failing on Travis CI.
Please add phpcs.xml.dist to .gitattributes, so that it’s not included in distribution exports, and also update the phpcs command in .travis.yml.
Thanks!


An attempt was made to access a socket in a way forbidden by its access permissions

When I do openplayground run, this is what I'm getting:
Initializing download manager...
Download loop started...
 * Serving Flask app 'server.app'
 * Debug mode: off
An attempt was made to access a socket in a way forbidden by its access permissions

I ran the cmd prompt with admin and still got the same message.

Closing due to inactivity.

please reopen. i get the same error. tavern, kobold, and kobold extensions are running on 8000, 5000, and 5001
is the default to run on 7060 or whatever and is there/isn't there a failure mode where the port is incremented, or does it only try to run on 1 or 2 ports?
if so, which line defines the port? I can't find it
python app.py

Serving Flask app 'app'
Debug mode: on
アクセス許可で禁じられた方法でソケットにアクセスしようとしました。

me too. please reopen

Reopen.

I found a fix. It may not be ideal for some developers, but on app.run() function, pass in the port argument, and due to the fact that Flask's default port is 5000, you may want to change it to 5001 or 8080, or anything you would like. This worked for me.

I think specific port has no permission to run. Give the permission and run

This worked for me.
Finding which task is running on the default port 5000:
netstat -ano | find/i "5000"
Killing the process:
taskkill /PID <task pid> /F


[ZEPPELIN-3836] [FOLLOWUP] Update link in README.md

What is this PR for?
After https://github.com/apache/zeppelin/pull/3211, some link in README.md need to be updated.
What type of PR is it?
Bug Fix
What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-3836
Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

Merge to master


async / await not working in Windows build

Operation System: Win10
Beaker Version: https://github.com/maidsafe/safe_browser/releases/download/0.4.0/safe-browser-v0.4.0-win-x64.zip
The following line throws an error (easily reproduceable when executed in the console):
(async () => { console.log('test'); })();
Error:
Uncaught SyntaxError: Unexpected token (
However it seems to work under linux:
https://forum.safedev.org/t/probably-promise-overuse/881/10?u=mindphreaker

https://forum.safedev.org/t/probably-promise-overuse/881/13?u=hunterlester

This is working as expected with latest code from browser's master branch.


application crashes if runtime is missing

We have currently the problem that a GUI app (LabVIEW, we have no control of) that is calling into the generated *.NE.dll crashes without any error.
So I'm looking for a way to prevent the call into abort() in case of a missing runtime.
I was hoping for the mentioned methods preload_runtime() and/or set_failure_callback() but I somehow miss whether these could be used for issuing an error to the GUI and not crashing it.
Could these function be the right way to go and if yes, are there any examples available I could use as guidance?
If not, is there any other way to achieve this?
Thanks a lot Thomas

@tvogel-nid There is presently no way to address this since I'm not sure how to handle the case in practice. Let me walk through the scenario I have in mind.
A managed binary exposes the following function:
IntPtr DoWork(int a, float f);

The native export looks like the following:
void* DoWork(int a, float f);

The question I am struggle with is, what happens if the runtime fails to load? Do I return NULL? That could indicate something completely unexpected and likely not what is desired.
I suppose I could provide another option, attribute? ,for users to define "default" values for each method in the event the CLR fails to load but I'm not really a fan of that in practice. I guess we could also provide a native callback that could be supplied that indicates "give me data of this size because the runtime has failed to load" – that is rather complicated too.
My initial thinking here was that the CLR is the equivalent of a native dependency so the failure should be the same. Do you have a suggested UX for this type of failure?

@AaronRobinsonMSFT even after thinking it over and over I still have no real idea how to overcome this problem.
Would it be an option to call just exit() instead of abort()? Maybe selectable by a compile switch.
Problem seems to be that my controlling application(LabVIEW) uses so called "call library function nodes" to call into the DLL and reacts with a full crash without any warning/error to a SIGABRT that is issued by the abort() as far as I understand.

@tvogel-nid I can absolutely change how the application fails. In fact, I can also permit users to provide their own native code during a runtime load or export discovery failure. This would involve consumers providing C code – I assume this is okay.
I can think of two options:

Create a new .NET DNNE Attribute that takes a snippet of C code that will be compiled into the final binary for these failure cases.

Have an MSBuild Item that permits setting additional C files that will be included in the native export binary. The native API would be expanded to allow registration at run-time or perhaps during link where the user defines their own failure callbacks in C.

Both approaches wouldn't change the current behavior of the DNNE fallback being abort since the user defined native callbacks could call exit or whatever they like instead. However, if the user still didn't define an process termination strategy the system would failure as currently defined.
Do you have a preference here? Other takes?

@tvogel-nid I am going to follow @jkoritzinsky's suggestion and permit an override mechanism. This will enable you or anyone else to override the default behavior as desired. Once could imagine a Dialog box being presented that would indicate to the user what to install and once the user acknowledged that the process would terminate via any number of ways—exit(), abort(), etc. This permits people the ability to provide a nice reason as to why something is going down.
If this is something needed soon, let me know and I will publish a new package otherwise I'll wait a bit to see if anyone has other needs.

This support was published in 1.0.28 – https://www.nuget.org/packages/DNNE/1.0.28.


Invalid link to the docker image on website

Introduction
The page https://sql-page.com/your-first-sql-website/ contains an erroneous link to the docker image: https://hub.docker.com/repository/docker/sqlpage/SQLPage/general (which 404's) instead of https://hub.docker.com/r/lovasoa/sqlpage.
Screenshots

fixed :)


Write systemd init script for bigchaindb

This is needed if we want bigchaindb to start on boot, as we may on testnet & production machines (e.g. virtual machines on Azure, launched from the Azure Marketplace).
Note: Using systemd rather than Upstart or System V init scripts assumes a recent version of Ubuntu, but that's probably okay since Ubuntu 16.04 is an LTS version and it uses systemd init scripts.
This will also help with graceful shutdown and restart of BigchainDB Server: see issue #662

You could also consider using Supervisor in my experience its a much more user friendly alternative.

systemd is a superset of supervisor.
As in the run supervisor, we will need a systemd config.
On Tue, 17 Jan 2017 at 5:09 PM, Rodolphe Marques<EMAIL_ADDRESS>wrote:

You could also consider using Supervisor http://supervisord.org/ in my
experience its a much more user friendly alternative.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/bigchaindb/bigchaindb/issues/1049#issuecomment-273214136,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE1QqrIVjuetEvxmw83GVsYt5RSYRJfZks5rTOfIgaJpZM4Llb8q
.

Digged into this a little bit. So far I have:
[Unit]
Description="bigchaindb server"
Documentation="https://docs.bigchaindb.com"
#Requires=network-online.target mongod.service?
#After=
[Service]
#User=bigchaindb
User=krish
#EnvironmentFile=/etc/environment PYTHONPATH?
TimeoutSec=30
#ExecStartPre=-/xxx/bigchaindb-pre-start.bash
ExecStart=/xxx/bin/bigchaindb -c /etc/bigchaindb/.bigchaindb start
#ExecStop=/xxx/bigchaindb-stop.bash flush and cleanup here
Restart=always
RestartSec=5

#[Install]
#WantedBy=multi-user.target

and
diff --git a/setup.py b/setup.py
index 9dd050b..491bbe4 100644
--- a/setup.py
+++ b/setup.py
@@ -127,4 +127,5 @@ setup(
         'docs': docs_require,
     },
     package_data={'bigchaindb.common.schema': ['*.yaml']},
+    data_files=[('/etc/systemd/system', ['bigchaindb.service'])]
 )

The workflow should be more like:

Create the user and group during pip install, OR create the user group as an exec-pre-start script.
Create and configure a .bigchaindb conf file in /etc/bigchaindb/.
Point python to be python3.

Will get back to this later.

We're going to stop working on this for now because internally we're going to be using Docker to start/restart BigchainDB inside containers.
If you, dear reader, need a systemd init script for your own BigchainDB deployment, then comment below to let us know.