Google Sign-in on iOS not working

My iOS application is essentially a WKWebView and has been using the web-flow sign-in process for about a year without any issues.
Today, however, our users can't log into the iOS version of the app at all (the Android version still works). After what appears to be a successful login (according to the debug window), the pop-up window throws two errors. The first is one is "Can't close the window because it was not opened by JavaScript". This one pretty much kills the rest of the process, but I can see that lso has complete values. If I try to call lso.relayAuthResponse() in my Safari debug window, just to test, I can see an "invalid_orgin" error.
I haven't changed any of the code on my end and this has been working since about the end of Q1 2016 (when it was first implemented).
Is this related to bug #277 ? Like 277, my code uses a custom sign-in button.

HI @PDSBGreg, sorry about what seems to be a regression. The "invalid_origin" error is different: this method expects arguments and raise an error if not received.
What are you using to have your app run in a WKWebView? Cordova? Is there any chance the WKWebView plugin has been updated recently?

It's a self-made Cordova (but basically that). Cordova doesn't (or didn't anyway) let you encode videos to specific formats or audio the way we needed it. This is affecting all iOS versions that we've tested as of this weekend (9.3.5 up to 10.2.1). 10.2.1 is new-ish (out a couple of weeks ago), but it was working Friday and isn't today. 9.3.5 was released at some point last year.

Just to confirm: are you using gapi.auth2?

@PDSBGreg Re. #277 we haven't seen any errors in the console, and this relates to the web only, so the symptoms are different but it may be a related regression. We also have Cordova apps with Google auth on Android (using cordova-plugin-chrome-apps-identity) and iOS (using cordova-plugin-googleplus) and these are both unaffected by this issue. The googleplus plugin was the only one we could find that meets Apple's current standards, and may be an alternative for you.

Yes, we're using gapi.auth2.
-- The following may or may not be related...
I'm not exactly sure how I would be able to use a Cordova plugin without Cordova. At this point I'm looking into using the iOS Google SignIn code. The problem with it, though, is that it uses Safari and cookies to handle the log in / out. And, since we're on shared devices (between staff and students at the school board), I need to have an actual "complete" sign out which doesn't (or didn't last year when I checked) happen with the iOS Google SignIn code.
The way the current solutions work is that when the sign-in button is pressed, the iOS ViewController intercepts the call and creates a new WKWebView using the same memory pool as the original WKWebView (which essential creates a pop-up window). When the user logs out of the app, I flush the memory pool and re-create the web views, so there is no history of the previous user. As far as I know, this can't happen with the iOS Google code.

@PDSBGreg thanks for the details. The Google Sign-In iOS SDK indeed relies on Safari and cookies to improve the sign-in experience, however, in your use case, this is detrimental. Have you considered asking your users to enable Private Mode on their devices? Once enabled, all Safari views should be using this mode, so I think this would allow to keep the signed-in Google account restricted to the sign-in flow.
GSI v2 does not officially support WKWebView as we provide the iOS SDK so we may have made a change that I'm not aware of that created this issue. I would highly recommend try to use GSI iOS SDK for a better and more reliable support.

Private mode in Safari breaks some of the in house web-only applications that use sessionStorage (pop-up windows don't inherit sessionStorage items in private mode...or, again, they didn't used to). It also blocks the single sign on information behind our Active Directory.
Looks like I'll be looking at re-writing the login process. Do you know how the request for offline access with Google Drive will be affected? That call is supposed to come directly after the 1st login attempt (and does in our current work-flow), but I'm not entirely sure how I can do that with the new sign-in way.

@PDSBGreg I am not entirely sure to understand your question: do you need to get an offline code to access Google Drive? Could you use this: https://developers.google.com/identity/sign-in/ios/offline-access?
I think setting the serverClientId would allow to get both idToken and code.

Yes, something like that. I'll see if I can get that working tomorrow.
Thanks. ... I guess there isn't any change of rolling the code back to before whatever got pushed out over the weekend?

As gapi.auth2 do not officially support WKWebView, and, more importantly than that, we have deprecated OAuth login in UIWebView/WKWebView (see blog post) we are not able to roll back the code for this reason.

Interesting. I wish I would have seen that sooner!
Last comment for the night. Any idea how I can connect the idToken, etc that I receive from the iOS SignIn code back to gapi.auth2.getAuthInstance() and the Google Drive javascript library ... gapi.client.load('drive', 'v3') ...? Since all of the application logic is held in the web view?

This is currently not possible to use gapi.client with a token received externally (i.e. not obtained through gapi.auth or gapi.auth2). In your use case, you probably have to query yourself the endpoints instead of using gapi.client.

Ok. Looks like I have a lot of re-writing ahead of me. I'll close this since it won't be fixed.

Thanks for your understanding!


Expand the number of analog inputs

Is your feature request related to a problem? Please describe.
Apparently there's only five analog inputs available at the moment.
Describe the solution you'd like
Let's use the full potential of all 16 pins please.

it was arbitray in deed. On the mega we don't have pressing memory restrictions (but we do on the UNO and ProMicro).
What is your use case for the 16 analog inputs?


Fastnlight: Watch recover[\W_]+your[\W_]+lost[\W_]*+Bitcoin

Fastnlight requests the watch of the watch_keyword recover[\W_]*+your[\W_]*+lost[\W_]*+Bitcoin. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

recover[\W_]*+your[\W_]*+lost[\W_]*+Bitcoin has been seen in 21 true positives, 0 false positives, and 0 NAAs.

Approved by Ryan M in Charcoal HQ


Trades for Offer

When showing a manage (create/update/remove) offer it would be nice to drill down to show all the corresponding trades that may have happened for that offer. It's nice that you show the effects but if I understand correctly those are only if the offer has an immediate effect when it makes its way into the ledger, so it's hard to determine which offers eventually caused a trade.

Implemented in v0.12 for update/remove offer operations. For create offer case the links in the operation description will be available once #188 is implemented.
At this point all offers (including deleted) with full trades and changes history can be explored using search box.


update-properties doesn't seem to respect allowMajorUpdates parameter

I'm writing a CI script to update to update properties that define versions to the latest stable version, but without breaking the build -- so major updates are not allowed.
mvn versions:update-properties -DallowMajorUpdates should be ideal for this, but it doesn't appear to work as advertised:
[INFO] Minor version changes allowed
[INFO] Updated ${lombok.version} from 1.18.2 to 1.18.22
[INFO] Minor version changes allowed
[INFO] Updated ${slf4j.version} from 1.7.13 to 2.0.0-alpha6
[INFO] Minor version changes allowed
[INFO] Updated ${junit.version} from 4.12 to 4.13.2

The lombok and junit updates are as expected, but the slf4j update is obviously a major version change!
The doc:

Whether to allow the major version number to be changed.

from http://www.mojohaus.org/versions-maven-plugin/update-properties-mojo.html#allowMajorUpdates
This is versions-maven-plugin:2.9.0:update-properties.

The doc:

Whether to allow the major version number to be changed.

the same doc:

Default: true

-DallowMajorUpdates = -DallowMajorUpdates=true => allow
What if you set it to false to disallow major updates?

Yes, sorry, that's what I've been doing. I will update the bug description to clarify this.

Getting similar (for artifact with the latest version in central 3.0.0-M5) result.
I'm pretty sure it's due to the fact, that every rc, m, alpha, beta, snapshot releases are still considered as < 3.0.0, which in my case is set as upper bound to update.
But if my project depends on org.codehaus.mojo:versions-maven-plugin, in version 1.3 (which has only final releases in central):

with -DallowMajorUpdates=true property is updated to 2.9.0,
with -DallowMajorUpdates=false property is updated to 1.3.1.
which is all as expected.

Also see https://maven.apache.org/pom.html#Version_Order_Specification.

Similar:

#11
#299
for the same reasons.

I'm pretty sure it's due to the fact, that every rc, m, alpha, beta, snapshot releases are still considered as < 3.0.0, which in my case is set as upper bound to update.

That is technically true, but wouldn't you agree that it would still constitute a major version update?

But if my project depends on org.codehaus.mojo:versions-maven-plugin, in version 1.3 (which has only final releases in central):
* with `-DallowMajorUpdates=true` property is updated to **2.9.0**,

* with `-DallowMajorUpdates=false` property is updated to **1.3.1**.
  which is all as expected.

Yes, this correct behavior is also what I've been seeing with other dependencies.

Also see https://maven.apache.org/pom.html#Version_Order_Specification.

I was vaguely aware of this but thanks for bringing it to my attention, it's very helpful. This part in particular:

Note: As 2.0-rc1 < 2.0, the version requirement [1.0,2.0) excludes 2.0 but includes version 2.0-rc1, which is contrary to what most people expect. In addition, Gradle interprets it differently, resulting in different dependency trees for the same POM. If the intention is to restrict it to 1.* versions, the better version requirement is [1,1.999999).

So I understand the technical reason why allowMajorUpdates (and others?) works like it does, but the allowMajorUpdates name doesn't communicate that it relies on this behavior -- the "major" part even implies that it should behave like I assume Gradle does.
I don't think you would break a lot by changing this behavior so that 2.0-rc1 is excluded from upgrades, as I don't think many users depend on it, in fact they would probably find it surprising. Failing that, maybe an additional parameter could control whether to use the current behavior or one where 2.0-rc1 would not be a valid target.

I'm pretty sure it's due to the fact, that every rc, m, alpha, beta, snapshot releases are still considered as < 3.0.0, which in my case is set as upper bound to update.

That is technically true, but wouldn't you agree that it would still constitute a major version update?

Yes, yes I would! I was surprised by the current behaviour as well.

This has been addressed in #753 which is already available in the latest release (2.13.0)
@slachiewicz please close


Issue while installing MMCV and MMDET

Thanks for your error report and we appreciate it a lot.
Describe the bug
Not able to set up the environment for mmdetection.  I installed all the prerequisite libraries.
pip install torch==1.9.0+cu111 torchvision==0.10.0+cu111 torchaudio==0.9.0 -f https://download.pytorch.org/whl/torch_stable.html
pip install tqdm
pip install torchpack
pip install mmcv-full==1.4 -f https://download.openmmlab.com/mmcv/dist/cu111/torch1.9.0/index.html
pip install mmdet==2.22.0
Reproduction

What command or script did you run?

Running setup.py after installing all the above packages, results in an error.

Did you make any modifications on the code or config? Did you understand what you have modified?
No

What dataset did you use?
I am using nuscenes but before that, I am not able to build the environment to run create_Data.py

Environment

Please run python mmdet/utils/collect_env.py to collect necessary environment information and paste it here.

Collecting environment information...
PyTorch version: 1.9.0+cu111
Is debug build: False
CUDA used to build PyTorch: 11.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.4 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.14.0
Libc version: glibc-2.9

Python version: 3.6.10 |Anaconda, Inc.| (default, Mar 23 2020, 23:13:11)  [GCC 7.3.0] (64-bit runtime)
Python platform: Linux-5.4.0-120-generic-x86_64-with-debian-buster-sid
Is CUDA available: True
CUDA runtime version: 11.0.167
GPU models and configuration: GPU 0: NVIDIA A100-PCIE-40GB
Nvidia driver version: 510.73.08
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.0.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.0.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.0.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.0.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.0.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.0.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.0.1
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip] crumpets-torch==3.0.0a5+cuda110
[pip] msgpack-numpy==0.4.8
[pip] numpy==1.18.1
[pip] pytorch-ignite==0.4.1
[pip] pytorch-transformers==1.1.0
[pip] torch==1.9.0+cu111
[pip] torch-geometric==1.6.0
[pip] torchaudio==0.9.0
[pip] torchpack==0.3.1
[pip] torchtext==0.6.0
[pip] torchvision==0.10.0+cu111
[conda] crumpets-torch            3.0.0a5+cuda110          pypi_0    pypi
[conda] magma-cuda110             2.5.2                         5    local
[conda] mkl                       2019.1                      144
[conda] mkl-include               2019.1                      144
[conda] msgpack-numpy             0.4.8                    pypi_0    pypi
[conda] nomkl                     3.0                           0
[conda] numpy                     1.18.1           py36h94c655d_0
[conda] numpy-base                1.18.1           py36h2f8d375_1
[conda] pytorch-ignite            0.4.1                    pypi_0    pypi
[conda] pytorch-transformers      1.1.0                    pypi_0    pypi
[conda] torch                     1.9.0+cu111              pypi_0    pypi
[conda] torch-geometric           1.6.0                    pypi_0    pypi
[conda] torchaudio                0.9.0                    pypi_0    pypi
[conda] torchpack                 0.3.1                    pypi_0    pypi
[conda] torchtext                 0.6.0                    pypi_0    pypi
[conda] torchvision               0.10.0+cu111             pypi_0    pypi

You may add addition that may be helpful for locating the problem, such as
Already mentioned above.

Error traceback
If applicable, paste the error trackback here.
*********************************calling setup.py*********************************
running develop
running egg_info
creating mmdet3d.egg-info
writing mmdet3d.egg-info/PKG-INFO
writing dependency_links to mmdet3d.egg-info/dependency_links.txt
writing top-level names to mmdet3d.egg-info/top_level.txt
writing manifest file 'mmdet3d.egg-info/SOURCES.txt'
reading manifest file 'mmdet3d.egg-info/SOURCES.txt'
writing manifest file 'mmdet3d.egg-info/SOURCES.txt'
running build_ext
building 'mmdet3d.ops.spconv.sparse_conv_ext' extension
creating /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build
creating /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6
creating /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d
creating /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops
creating /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv
creating /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src
Emitting ninja build file /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/build.ninja...
Compiling objects...
Allowing ninja to set a default number of workers... (overridable by setting the environment variable MAX_JOBS=N)
[1/7] /usr/local/cuda/bin/nvcc  -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/reordering_cuda.cu -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/reordering_cuda.o -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_BFLOAT16_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ --expt-relaxed-constexpr --compiler-options ''"'"'-fPIC'"'"'' -w -std=c++14 -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ -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 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
FAILED: /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/reordering_cuda.o
/usr/local/cuda/bin/nvcc  -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/reordering_cuda.cu -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/reordering_cuda.o -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_BFLOAT16_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ --expt-relaxed-constexpr --compiler-options ''"'"'-fPIC'"'"'' -w -std=c++14 -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ -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 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
nvcc fatal   : Unsupported gpu architecture 'compute_86'
[2/7] /usr/local/cuda/bin/nvcc  -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/maxpool_cuda.cu -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/maxpool_cuda.o -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_BFLOAT16_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ --expt-relaxed-constexpr --compiler-options ''"'"'-fPIC'"'"'' -w -std=c++14 -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ -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 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
FAILED: /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/maxpool_cuda.o
/usr/local/cuda/bin/nvcc  -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/maxpool_cuda.cu -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/maxpool_cuda.o -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_BFLOAT16_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ --expt-relaxed-constexpr --compiler-options ''"'"'-fPIC'"'"'' -w -std=c++14 -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ -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 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
nvcc fatal   : Unsupported gpu architecture 'compute_86'
[3/7] /usr/local/cuda/bin/nvcc  -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/indice_cuda.cu -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/indice_cuda.o -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_BFLOAT16_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ --expt-relaxed-constexpr --compiler-options ''"'"'-fPIC'"'"'' -w -std=c++14 -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ -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 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
FAILED: /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/indice_cuda.o
/usr/local/cuda/bin/nvcc  -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/indice_cuda.cu -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/indice_cuda.o -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_BFLOAT16_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ --expt-relaxed-constexpr --compiler-options ''"'"'-fPIC'"'"'' -w -std=c++14 -D__CUDA_NO_HALF_OPERATORS__ -D__CUDA_NO_HALF_CONVERSIONS__ -D__CUDA_NO_HALF2_OPERATORS__ -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 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
nvcc fatal   : Unsupported gpu architecture 'compute_86'
[4/7] c++ -MMD -MF /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/reordering.o.d -pthread -B /opt/conda/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/reordering.cc -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/reordering.o -w -std=c++14 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
[5/7] c++ -MMD -MF /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/maxpool.o.d -pthread -B /opt/conda/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/maxpool.cc -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/maxpool.o -w -std=c++14 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
[6/7] c++ -MMD -MF /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/indice.o.d -pthread -B /opt/conda/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/indice.cc -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/indice.o -w -std=c++14 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
[7/7] c++ -MMD -MF /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/all.o.d -pthread -B /opt/conda/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_CUDA -I/netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/include -I/opt/conda/lib/python3.6/site-packages/torch/include -I/opt/conda/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/opt/conda/lib/python3.6/site-packages/torch/include/TH -I/opt/conda/lib/python3.6/site-packages/torch/include/THC -I/usr/local/cuda/include -I/opt/conda/include/python3.6m -c -c /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/mmdet3d/ops/spconv/src/all.cc -o /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/bevfusion/build/temp.linux-x86_64-3.6/mmdet3d/ops/spconv/src/all.o -w -std=c++14 -DTORCH_API_INCLUDE_EXTENSION_H '-DPYBIND11_COMPILER_TYPE="_gcc"' '-DPYBIND11_STDLIB="_libstdcpp"' '-DPYBIND11_BUILD_ABI="_cxxabi1011"' -DTORCH_EXTENSION_NAME=sparse_conv_ext -D_GLIBCXX_USE_CXX11_ABI=0
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
ninja: build stopped: subcommand failed.
Traceback (most recent call last):
  File "/opt/conda/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 1672, in _run_ninja_build
    env=env)
  File "/opt/conda/lib/python3.6/subprocess.py", line 438, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['ninja', '-v']' returned non-zero exit status 1.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "setup.py", line 161, in <module>
    zip_safe=False,
  File "/opt/conda/lib/python3.6/site-packages/setuptools/__init__.py", line 161, in setup
    return distutils.core.setup(**attrs)
  File "/opt/conda/lib/python3.6/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/opt/conda/lib/python3.6/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/opt/conda/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/opt/conda/lib/python3.6/site-packages/setuptools/command/develop.py", line 38, in run
    self.install_for_development()
  File "/opt/conda/lib/python3.6/site-packages/setuptools/command/develop.py", line 140, in install_for_development
    self.run_command('build_ext')
  File "/opt/conda/lib/python3.6/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/opt/conda/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/opt/conda/lib/python3.6/site-packages/setuptools/command/build_ext.py", line 87, in run
    _build_ext.run(self)
  File "/opt/conda/lib/python3.6/site-packages/Cython/Distutils/old_build_ext.py", line 186, in run
    _build_ext.build_ext.run(self)
  File "/opt/conda/lib/python3.6/distutils/command/build_ext.py", line 339, in run
    self.build_extensions()
  File "/opt/conda/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 709, in build_extensions
    build_ext.build_extensions(self)
  File "/opt/conda/lib/python3.6/site-packages/Cython/Distutils/old_build_ext.py", line 195, in build_extensions
    _build_ext.build_ext.build_extensions(self)
  File "/opt/conda/lib/python3.6/distutils/command/build_ext.py", line 448, in build_extensions
    self._build_extensions_serial()
  File "/opt/conda/lib/python3.6/distutils/command/build_ext.py", line 473, in _build_extensions_serial
    self.build_extension(ext)
  File "/opt/conda/lib/python3.6/site-packages/setuptools/command/build_ext.py", line 208, in build_extension
    _build_ext.build_extension(self, ext)
  File "/opt/conda/lib/python3.6/distutils/command/build_ext.py", line 533, in build_extension
    depends=ext.depends)
  File "/opt/conda/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 539, in unix_wrap_ninja_compile
    with_cuda=with_cuda)
  File "/opt/conda/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 1360, in _write_ninja_file_and_compile_objects
    error_prefix='Error compiling objects for extension')
  File "/opt/conda/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 1682, in _run_ninja_build
    raise RuntimeError(message) from e
RuntimeError: Error compiling objects for extension

I tried building MMC and MMDet from source using following commands:
git clone https://github.com/open-mmlab/mmcv.git
cd mmcv
pip install -r requirements/optional.txt
MMCV_WITH_OPS=1 MMCV_CUDA_ARGS='-gencode=arch=compute_80,code=sm_80' pip install -e .
git clone --branch v2.20.0 https://github.com/open-mmlab/mmdetection.git
cd /netscratch/mishra/Thesis_Fusion/BEVFusion/BEVFusion_Baseline/mmdetection
pip install -r requirements/build.txt
pip install -v -e .

still, the same error while running setup.py.
@ZwwWayne any inputs on this.

It seems to be the cause of CUDA operators in mmdet3d. We have not test it in the high version.

I also encountered this problem, my PyTorch version is 1.9.0+cu111 too!!!
I look forward to your reply to my questions as soon as possible. Thanks!
Log as follows:
ninja: build stopped: subcommand failed.
Traceback (most recent call last):
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\torch\utils\cpp_extension.py", line 1666, in _run_ninja_build
subprocess.run(
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\subprocess.py", line 516, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['ninja', '-v']' returned non-zero exit status 1.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "setup.py", line 4, in
setup(
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools_init_.py", line 108, in setup
return distutils.core.setup(**attrs)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools_distutils\core.py", line 185, in setup
return run_commands(dist)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools_distutils\core.py", line 201, in run_commands
dist.run_commands()
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools_distutils\dist.py", line 969, in run_commands
self.run_command(cmd)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools\dist.py", line 1221, in run_command
super().run_command(command)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools_distutils\dist.py", line 988, in run_command
cmd_obj.run()
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools\command\build_ext.py", line 84, in run
_build_ext.run(self)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\Cython\Distutils\old_build_ext.py", line 186, in run
_build_ext.build_ext.run(self)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools_distutils\command\build_ext.py", line 345, in run
self.build_extensions()
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\torch\utils\cpp_extension.py", line 709, in build_extensions
build_ext.build_extensions(self)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\Cython\Distutils\old_build_ext.py", line 195, in build_extensions
_build_ext.build_ext.build_extensions(self)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools_distutils\command\build_ext.py", line 467, in build_extensions
self._build_extensions_serial()
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools_distutils\command\build_ext.py", line 493, in _build_extensions_serial
self.build_extension(ext)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools\command\build_ext.py", line 246, in build_extension
_build_ext.build_extension(self, ext)
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\setuptools_distutils\command\build_ext.py", line 548, in build_extension
objects = self.compiler.compile(
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\torch\utils\cpp_extension.py", line 682, in win_wrap_ninja_compile
_write_ninja_file_and_compile_objects(
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\torch\utils\cpp_extension.py", line 1355, in _write_ninja_file_and_compile_objects
_run_ninja_build(
File "D:\Python\Anaconda\anaconda3\envs\mmlab\lib\site-packages\torch\utils\cpp_extension.py", line 1682, in _run_ninja_build
raise RuntimeError(message) from e
RuntimeError: Error compiling objects for extension


adding benchmark for more extrinsics

in the process of adding a benchmark for removing identity traits, which is a pre-cursor for setting up a baseline for #19

Do you want this merged now, or do you want it merged when we've done a bit for #19? Currently you've got #19 linked to close when this is merged.

thanks for pointing that out -- didn't realize that -- only meant to link it for context's sake but realized my other work on the actual optimization hasn't been published and put into a PR yet

I'm going to refresh my review on this so that I can give it one more skim and approve it when you mark it ready for review.

I think these changes got blown out somehow, going to add them back in through #53


Clean-up patches #2

Here is the 2nd batch of clean-up patches discussed in https://github.com/orbitersim/orbiter/issues/338 to enable C++20 standard conformance.
The purpose of these patches is to enable C++20 conformance of the existing code with minimal changes, so that further clean-up can be done as the next step.
Most of these patches consist of adding const to variables point to string literals, and where that's not possible, adding explicit char* casts.

Rebased to include the recent Date2Int() fix and ran a few scenarios to make sure things are working.


Same code works on macOS Python 3.7.2 but not on Ubuntu 16.04 Python 3.5.2

Reporting a bug

[x] I am using the latest released version of Numba (most recent is visible in
the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
[x] I have included below a minimal working reproducer (if you are unsure how
to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Hello,
The following minimal example gave me errors (appended at the end of this message) on Ubuntu 16.04 with Python 3.5.2, while it works well on my Mac with Python 3.7.2 (both are inside a virtual environment and have Numba 0.45.1).
Could you please help me to fix this?
Thank you very much in advance!
import numpy as np
import scipy.sparse
import numba

@numba.jit(nopython=True, parallel=True, cache=True)
def simplex_projection_inequality_sparse(data, indices, indptr, num_vectors):
    """
    simplex project (with inequality constraints) of each row or each column of a sparse matrix C
    If C is CSR: each row; if C is CSC: each column
    data, indices, indptr, shape: representation of C (same notation as scipy csr/csc matrix)
    num_vectors = number of rows if C is CSR
                = number of cols if C is CSC
    """
    x = np.zeros(len(data))
    for i in numba.prange(num_vectors):
        # projection for each row independently
        start = indptr[i]
        end = indptr[i+1]
        ci = data[start:end]
        u = np.maximum(ci, 0)
        if np.sum(u) <= 1:
            xi = u
        else:
            ni = end - start
            a = -np.sort(-ci)
            lambdas = (np.cumsum(a) - 1)/np.arange(1, ni+1)
            for k in range(ni-1, -1, -1):
                if a[k] > lambdas[k]:
                    xi = np.maximum(ci - lambdas[k], 0)
                    break
        x[start:end] = xi
    return x

def test():
    A = scipy.sparse.random(4, 5, density=0.5, format='csr')
    x = simplex_projection_inequality_sparse(A.data, A.indices, A.indptr, A.shape[0])

if __name__ == "__main__":
    test()

Traceback (most recent call last):
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/errors.py", line 662, in new_error_context
yield
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/lowering.py", line 258, in lower_block
self.lower_inst(inst)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/lowering.py", line 410, in lower_inst
func(self, inst)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/npyufunc/parfor.py", line 240, in _lower_parfor_parallel
bool(alias_map), index_var_typ, parfor.races)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/npyufunc/parfor.py", line 1103, in _create_gufunc_for_parfor_body
locals)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 1036, in compile_ir
lifted_from=lifted_from)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 398, in compile_ir
return self._compile_ir()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 910, in _compile_ir
return self._compile_core()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 890, in _compile_core
res = pm.run(self.status)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
return func(*args, **kwargs)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 266, in run
raise patched_exception
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 257, in run
stage()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 515, in stage_nopython_frontend
self.locals)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 1123, in type_inference_stage
infer.build_constraint()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/typeinfer.py", line 883, in build_constraint
self.constrain_statement(inst)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/typeinfer.py", line 1162, in constrain_statement
self.typeof_assign(inst)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/typeinfer.py", line 1233, in typeof_assign
self.typeof_global(inst, inst.target, value)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/typeinfer.py", line 1372, in typeof_global
self.lock_type(target.name, lit or typ, loc=inst.loc)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/typeinfer.py", line 950, in lock_type
tv.lock(tp, loc=loc, literal_value=literal_value)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/typeinfer.py", line 82, in lock
assert not self.locked
AssertionError: Failed in nopython mode pipeline (step: nopython frontend)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "test.py", line 41, in
test()
File "test.py", line 38, in test
x = simplex_projection_inequality_sparse(A.data, A.indices, A.indptr, A.shape[0])
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/dispatcher.py", line 395, in _compile_for_args
raise e
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/dispatcher.py", line 352, in _compile_for_args
return self.compile(tuple(argtypes))
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
return func(*args, **kwargs)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/dispatcher.py", line 693, in compile
cres = self._compiler.compile(args, return_type)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/dispatcher.py", line 76, in compile
status, retval = self._compile_cached(args, return_type)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/dispatcher.py", line 90, in _compile_cached
retval = self._compile_core(args, return_type)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/dispatcher.py", line 108, in _compile_core
pipeline_class=self.pipeline_class)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 972, in compile_extra
return pipeline.compile_extra(func)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 390, in compile_extra
return self._compile_bytecode()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 903, in _compile_bytecode
return self._compile_core()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 890, in _compile_core
res = pm.run(self.status)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
return func(*args, **kwargs)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 266, in run
raise patched_exception
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 257, in run
stage()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 764, in stage_nopython_backend
self._backend(lowerfn, objectmode=False)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 703, in _backend
lowered = lowerfn()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 690, in backend_nopython_mode
self.metadata)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/compiler.py", line 1143, in native_lowering_stage
lower.lower()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/lowering.py", line 177, in lower
self.lower_normal_function(self.fndesc)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/lowering.py", line 218, in lower_normal_function
entry_block_tail = self.lower_function_body()
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/lowering.py", line 243, in lower_function_body
self.lower_block(block)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/lowering.py", line 258, in lower_block
self.lower_inst(inst)
File "/usr/lib/python3.5/contextlib.py", line 77, in exit
self.gen.throw(type, value, traceback)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/errors.py", line 670, in new_error_context
six.reraise(type(newerr), newerr, tb)
File "/home/ubuntu/.env/python3/lib/python3.5/site-packages/numba/six.py", line 659, in reraise
raise value
numba.errors.LoweringError: Failed in nopython mode pipeline (step: nopython mode backend)
Failed in nopython mode pipeline (step: nopython frontend)
File "test.py", line 16:
def simplex_projection_inequality_sparse(data, indices, indptr, num_vectors):

x = np.zeros(len(data))
for i in numba.prange(num_vectors):
^
[1] During: lowering "id=9[LoopNest(index_variable = parfor_index.178, range = (0, num_vectors, 1))]{342: <ir.Block at test.py (28)>, 40: <ir.Block at test.py (16)>, 365: <ir.Block at test.py (29)>, 469: <ir.Block at test.py (31)>, 246: <ir.Block at test.py (23)>, 472: <ir.Block at test.py (31)>, 345: <ir.Block at test.py (28)>, 223: <ir.Block at test.py (22)>}Var(parfor_index.178, test.py (16))" at test.py (16)
This should not have happened, a problem has occurred in Numba's internals.
You are currently using Numba version 0.45.1.
Please report the error message and traceback, along with a minimal reproducer
at: https://github.com/numba/numba/issues/new
If more help is needed please feel free to speak to the Numba core developers
directly at: https://gitter.im/numba/numba
Thanks in advance for your help in improving Numba!

I can replicate this bug.

Same problem on current master branch (bdd8e312a24c5b76ee4fe480abe553cff349aa51).  No repo on OSX as described in the issue.  Bug seems come from parfor codepath.

This is a problem in parfor type inference extension trying to reject the same IR node into a different block object. It causes a duplicated constraint created. I have yet to find out why it only replicate on py3.5.

Closing as Python 3.5 is not supported. If this can be reproduced on a supported Python version with the latest Numba (0.55) please do reopen/file a new issue, thanks.


proposal: net/http: define and export RequestBodyTooLargeError

What version of Go are you using (go version)?

$ go version
go version go1.12 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN="/Users/foo/go/bin"
GOCACHE="/Users/foo/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/foo/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/lf/rbfblwvx6rx3xhm68yksmqjwdv1dsf/T/go-build261266046=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Upon limiting the maximum request size (by using MaxBytesReader as in https://stackoverflow.com/a/28292505/381140) I wanted to specially handle too large request body error in a clean way with error type assertion, and return custom response body.
More people asked for the same feature: https://groups.google.com/forum/#!topic/golang-nuts/gMzVGDgPyrY
What did you expect to see?
I expected net/http to have RequestBodyTooLargeError defined and returned by MaxBytesReader so type assertion can be done instead of error message comparison.
What did you see instead?
Trivial error string implementation is returned https://golang.org/src/net/http/request.go#L1114

There is a similar issue in the parsePostForm function: https://golang.org/src/net/http/request.go#L1158.

@rsc At a very least set those string as constants, current code looks ugly and stands against all the things that we love in golang.

@rsc, I think this issue fell off the tracker because it's from before the "Proposal" tag. Can this be tagged? If the proposal is accepted, I'm happy to file the CL.

CC @neild

FWIW, #41493 is a dupe with all positive feedback. I propose that MaxByteReader should return errors of the type ErrorMaxBytesExceeded struct { MaxSize int64 } that can be checked with errors.As.

A http.MaxBytesReader is defined as "similar to io.LimitReader", but "returns a non-EOF error for a Read beyond the limit".
Wrapping the incoming request body in a MaxBytesReader is the recommended way to set a limit on the size of an incoming request body. It interacts with other elements of HTTP request processing in some non-obvious ways: For example, (*Request).ParseForm sets a 10MiB limit on the size of parsed form data, except when the request Body is a MaxBytesReader.
This proposal, as I understand it, is to return a defined error when a MaxBytesReader hits the read limit.
This seems reasonable to me.
The net/http package defines only one exported error type, http.ProtocolError, which is deprecated. It defines a number of sentinel error values. Since the creator of a MaxBytesReader knows what maximum size they provided it, I think that providing this information in the error response is unnecessary, and this should be a sentinel error. Perhaps:
// ErrRequestBodyTooLarge is returned after a ReadCloser created by MaxBytesReader reads
// past its limit.
var ErrRequestBodyTooLarge = errors.New("http: request body too large")

A couple questions, and my proposed answers:

Does Close return ErrRequestBodyTooLarge if the limit is exceeded? Currently Close does not return an error in this case, but I think it should.
Does Read return ErrRequestBodyTooLarge, or an error wrapping this one? I don't have a strong opinion here. If this was a new package, I'd argue for wrapping, but given the extensive use of bare sentinels in net/http I think consistency argues for returning an unwrapped ErrRequestBodyTooLarge.

Since the creator of a MaxBytesReader knows what maximum size they provided it, I think that providing this information in the error response is unnecessary, and this should be a sentinel error.

Not necessarily. I want to wrap different handlers in different middleware, so that the processImage handler has a 25MB limit, but the processUser handler has a 1MB limit, for example. I want to be able to write generic error response middleware that can prompt the user with different messages for different overages.

What if instead of defining an error type, we add http.IsMaxBytesError(err error) (size int)? If the error isn’t from MaxBytesReader, it returns 0, otherwise it returns a positive number. It’s easier to use than a defined type and lets us hide the implementation details.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

I'm not really enthusiastic about increasing net/http's API surface with another type, but MaxBytesError seems reasonable. (I'd say that you can just wrap the io.ReadCloser returned by MaxBytesReader with your own type that adds whatever error you want--but there's a type assertion for the case when a Request.Body is a *maxBytesReader, so you can't actually do that).
type MaxBytesError struct {
  Limit int64
}

I don't think we should add http.IsMaxBytesError; error predicates are a perfectly fine pattern, but we don't have any in net/http now. A type fits the existing API better.
A struct is better than an int64. Better to always plan for extension rather than guess when you might need it.
We should maybe define that MaxBytesError{} is equivalent to any MaxBytesError, so you can write this if you don't care about the size:
if errors.Is(err, &http.MaxBytesError{}) { ... }

tl;dr, I'm reluctantly in favor of adding http.MaxBytesError.

We probably don't need the special definition at the end.
You can use
if errors.As(err, new(*http.MaxBytesError)) { ... }

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Issue title should be changed to "net/http: add MaxBytesError".


Update cloud-services-guestos-update-matrix.md

#sign-off

#sign-off

Hi @raiye, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (raiye). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

Hi @raiye, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (raiye). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;


Map - Media/ExternalMaterial/Links Info

Like Viber's info for a group

I was thinking of similar sum up featore for:

all un-approved nodes with open IBIS discussion
-...


will not build 'Builder called die...'

Description of changes
update to cura 5.3.1
change log
release tag
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

Currently stuck with error during build:
.
.
.
@nix { "action": "setPhase", "phase": "fixupPhase" }
post-installation fixup
wrapping Qt applications in /nix/store/zk9i0h4536a8lhnif6ll18k01r6ka1bm-cura-5.3.1/bin /nix/store/zk9i0h4536a8lhnif6ll18k01r6ka1bm-cura-5.3.1/sbin /nix/store/zk9i0h4536a8lhnif6ll18k01r6ka1bm-cura-5.3.1/libexec /n>
shrinking RPATHs of ELF executables and libraries in /nix/store/zk9i0h4536a8lhnif6ll18k01r6ka1bm-cura-5.3.1
checking for references to /build/ in /nix/store/zk9i0h4536a8lhnif6ll18k01r6ka1bm-cura-5.3.1...
patching script interpreter paths in /nix/store/zk9i0h4536a8lhnif6ll18k01r6ka1bm-cura-5.3.1
stripping (with command strip and flags -S -p) in  /nix/store/zk9i0h4536a8lhnif6ll18k01r6ka1bm-cura-5.3.1/lib

Builder called die: Cannot wrap '/nix/store/zk9i0h4536a8lhnif6ll18k01r6ka1bm-cura-5.3.1/bin/cura' because it is not an executable file
Backtrace:
10 assertExecutable /nix/store/vvvy5ip4mw3kqp83vmhpaivfw138ms25-make-binary-wrapper-hook/nix-support/setup-hook
63 wrapProgramBinary /nix/store/vvvy5ip4mw3kqp83vmhpaivfw138ms25-make-binary-wrapper-hook/nix-support/setup-hook
58 wrapProgram /nix/store/vvvy5ip4mw3kqp83vmhpaivfw138ms25-make-binary-wrapper-hook/nix-support/setup-hook
49 wrapQtApp /nix/store/9mq3c0irk15b13bzm5bllsfkaq3gdb59-wrap-qt5-apps-hook/nix-support/setup-hook
128 _callImplicitHook /nix/store/blpvf60m29q02c0lc5fyhim30ma4y1vv-stdenv-linux/setup
144 _eval /nix/store/blpvf60m29q02c0lc5fyhim30ma4y1vv-stdenv-linux/setup
87 runHook /nix/store/blpvf60m29q02c0lc5fyhim30ma4y1vv-stdenv-linux/setup
1459 fixupPhase /nix/store/blpvf60m29q02c0lc5fyhim30ma4y1vv-stdenv-linux/setup
1596 genericBuild /nix/store/blpvf60m29q02c0lc5fyhim30ma4y1vv-stdenv-linux/setup
6 main /nix/store/6xg259477c90a229xwmb53pdfkn6ig3g-default-builder.sh


Invalid or unexpected token

/Users/mysuer/Desktop/project/src/views/Home.vue:1
<template>
^

I get this error after running npm run sitemap, I am confused as the build npm run build runs successfully
Can someone help with this please?

This is probably because you imported/required a Vue file in your vue.config.js (or you imported a .js file which in turns import a .vue file). Importing anything other than .js(on) files (or anything that resolves to it) is a Webpack feature and will never work with Node.js.
The simplest fix is to define your routes in a plain JS module with no static imports (or JS-only imports), and use dynamic imports to load your Vue components.

I ran into this problem as well.  I was able to get around it by using dynamic imports on all the components as the README outlines
https://github.com/cheap-glitch/vue-cli-plugin-sitemap/blob/main/README.md?plain=1#L88
However, this results in the entire compiled vue app being chunked into separate js for each route which is not optimal.  It's a tricky problem to solve however as the issue boils down to handling/expecting SFC syntax outside of vue.

This is very hacky, but I was able to create a workaround without granularly chunking my app up into individual pages with this update to package.json
"sitemap": "rm sitemap.xml && cat src/routes.ts | sed '/import/d' | sed '/component/d' > src/sitemap-routes.ts && vue-cli-service sitemap && rm src/sitemap-routes.ts"

and updating my vue.config.js file to use that temporary file:
const { routes } = require('./src/sitemap-routes.ts');

This of course requires your routes file be structured in a way where deleting the entire import and component lines will still yield valid JS/TS ... and requires sed so some windows users may not be able to use this approach without getting into that whole WSL thing.
All in all this "solution" is only valid on personal (single dev) projects and not suitable for a team project.

being chunked into separate js for each route which is not optimal

Why not? This is the recommended way to handle routes in any SPA that grows beyond a very simple prototype. It avoids loading the whole bundle when rendering a single page.

This is very hacky, but I was able to create a workaround without granularly chunking my app

You might be interested in https://router.vuejs.org/guide/advanced/lazy-loading.html#grouping-components-in-the-same-chunk


compress/flate return ErrUnexpectedEOF even when the decompression finished successfully

What version of Go are you using (go version)?

$ go version
go version go1.12.7 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPROXY="direct"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/52/bd76hd590sz1fsl094m08hf0m9dmwt/T/go-build177584568=/tmp/go-build -gno-record-gcc-switches -fno-common"
go env Output
$ go env

What did you do?
Using compress/inflate to do data compression and decompression, the reader of inflate.go returns ErrUnexpectedEOF even when the data is decompressed successfully, check the example below.
package main

import (
	"fmt"
	"compress/flate"
	"bytes"
	"io/ioutil"
)

func main() {
	var b bytes.Buffer
	zw, _ := flate.NewWriter(&b, flate.BestSpeed)
	zw.Write([]byte("hello"))
	zw.Flush()
	compressed := b.Bytes()
	fmt.Println(compressed)

	r := flate.NewReader(bytes.NewReader(compressed))
	rawData, err := ioutil.ReadAll(r)
	fmt.Println(err) // -> unexpected EOF
	fmt.Println(string(rawData)) // -> "hello"

}

What did you expect to see?
The error should be nil when decompression succeed, because we always check the error first.
What did you see instead?
error is ErrUnexpectedEOF.

You forgot to Close the writer: https://play.golang.org/p/Chet8ii7MyO

Looks so, thanks!


fix: use correct chain-id when filtering and checking txs

Overview
consistently pass the correct chain-id to the application using RequestPrepareProposal and RequestProcessProposal
this PR still needs to update the go.mod to use the official tag of tendermint after its released
closes #2020 and #2021
Checklist

[x] New and updated code has appropriate documentation
[x] New and updated code has new and/or updated testing
[x] Required CI checks are passing
[x] Visual proof for any user facing features like CLI or documentation updates
[x] Linked issues closed with keywords

unit tests failing?

yeah sorry, waiting for tests to finish locally but they should be fixed

Codecov Report

Merging #2022 (9091c3c) into main (30c50a0) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##             main    #2022   +/-   ##
=======================================
  Coverage   21.54%   21.54%
=======================================
  Files         127      127
  Lines       14293    14293
=======================================
  Hits         3079     3079
  Misses      10922    10922
  Partials      292      292

Impacted Files
Coverage Δ

app/prepare_proposal.go
0.00% <0.00%> (ø)

app/process_proposal.go
0.00% <0.00%> (ø)


ArrayBuffer input support

Fix #3545

Merci beaucoup Jérémy pour le PR. I've switched the base branch to flow for inclusion in the next release, which will also fix the Windows CI errors seen here. Please can you rebase against this branch and update the TypeScript definitions in lib/index.d.ts too.

Closed in favor of #3548


perf(array-repeat-strategy): call array.slice with all arguments

Also, is array.slice the fastest way to clone an array?

@martingust @jdanyow What do you guys think?

Looking at the spec again, I was wrong :sweat_smile:, passing the 2nd argument causes an extra call to ToInteger so omitting it should be faster.

If end is undefined, let relativeEnd be len; else let relativeEnd be ToInteger(end).

It's probably very browser specific. I just tested FF on Mac and slice was faster than the while loop, but only by a little bit.

I think we can leave it as is for now.


forge script nonce issue related to selectFork

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (deae4f1 2023-10-11T00:27:48.322843000Z)
What command(s) is the bug in?
forge script
Operating System
macOS (Apple Silicon)
Describe the bug
Hello, at aave governance v3 we have a script that:

iterates trough multiple chains to check for some configuration correctness
submits a single txn on mainnet

While when testing everything works/worked fine, when actually submitting via ledger we're getting nonce issues like:

nonce changed unexpectedly while sending transactions. Expected 2007 got 2006 from provider.

The issue seems to happen whenever we do selectFork within a script.
Here i created a minimal reproduction:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import {Script} from 'forge-std/Script.sol';

contract Reproduction is Script {
  function run() public {
    uint256 previousFork = vm.activeFork();
    vm.selectFork(previousFork);
    vm.startBroadcast();
    address(0x25F2226B597E8F9514B3F68F00f494cF4f286491).call{value: 1}(new bytes(0));
  }
}

The script is started with a mainnet rpc, calls selectFork witht he activeForkId which is 0 and i think should essentially just be a noop in that case?.
The trace looks as follows:
Traces:
  [41465] Reproduction::run()
    ├─ [0] VM::activeFork() [staticcall]
    │   └─ ← 0
    ├─ [0] VM::selectFork(0)
    │   └─ ← ()
    ├─ [0] VM::startBroadcast()
    │   └─ ← ()
    ├─ [7180] 0x25F2226B597E8F9514B3F68F00f494cF4f286491::fallback{value: 1}()
    │   ├─ [55] 0x10c74b37Ad4541E394c607d78062e6d22D9ad632::fallback() [delegatecall]
    │   │   └─ ← ()
    │   └─ ← ()
    └─ ← ()

Script ran successfully.

Instead of being able to submit the txn though, i'm getting:
###
Finding wallets for all the necessary addresses...
##
Sending transactions [0 - 0].

Error:
EOA nonce changed unexpectedly while sending transactions. Expected 46 got 45 from provider.

Seems related:

https://github.com/foundry-rs/foundry/issues/4701

edit: updated the example to be even more minimal (initially though was related to multichain, but just calling selectFork(activeForkId) will reproduce the same issue.
In practice what we do is:

store the current forkId
switch to another fork
test some stuff
switch back to the previous fork
The example is simplified, as it seems like most of this is unrelated to the actual error.

Also, for anyone facing this, one workaround which seems to work for us is to simply not switch back to the fork but always create a new one:
- uint256 previousFork = vm.activeFork();
- vm.selectFork(previousFork);
+ vm.createSelectFork(vm.rpcUrl('mainnet'));

I've proposed a fix here. #6271

@sakulstra @Evalir can close this as completed since https://github.com/foundry-rs/foundry/pull/6271 is merged?

@RedaOps i think it's working fine now thx.


feat: create initial package

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


_BrotliDecoderDecompress missing on macOS 14.5 intel

ImportError: dlopen(... site-packages/imgui_bundle/_imgui_bundle.cpython-312-darwin.so, 0x0002): symbol not found in flat namespace '_BrotliDecoderDecompress'

Works fine on my M3 mac, but not on the intel mac. Any thoughts on what's missing?

freetype is used by imgui to improve font rendering. And freetype uses Brotli.
You might try to compile from source and comment out those lines:
https://github.com/pthom/imgui_bundle/blob/f8db311b9c0828330e6b277238243ae3ccb8db76/CMakeLists.txt#L167-L168

Hm. But isn't all of that in the wheel? Or is it expecting something to be installed at runtime (maybe via brew?)

Ok, so https://files.pythonhosted.org/packages/29/1b/155fb7bc2605e2e8d8134befa48870f24252d0010931b429c0a45116195e/imgui_bundle-1.5.2-cp312-cp312-macosx_14_0_x86_64.whl does not have .dylibs, but https://files.pythonhosted.org/packages/87/f7/e0c7f1461743fee24373156aa134f6822881bab6794807992b32916dbaa3/imgui_bundle-1.5.2-cp312-cp312-macosx_14_0_arm64.whl does. So it's something about the build?

Hi Dustin,
Building Python libraries with native linked libraries is always complex. Below is an analysis of what I see.
Main CMakeLists:
in the main CMakeLists of imgui_bundle, we call ibd_force_freetype_static_for_python()
https://github.com/pthom/imgui_bundle/blob/f8db311b9c0828330e6b277238243ae3ccb8db76/CMakeLists.txt#L165-L168
 ibd_check_freetype_availability(freetype_default)
 # Note: to reduce wasm size, you may want to disable freetype on emscripten.
 option(HELLOIMGUI_USE_FREETYPE "Use freetype for text rendering" ${freetype_default})
 ibd_force_freetype_static_for_python()

ibd_check_freetype_availability & ibd_force_freetype_static_for_python
This sets HELLOIMGUI_FREETYPE_STATIC=ON
https://github.com/pthom/imgui_bundle/blob/f8db311b9c0828330e6b277238243ae3ccb8db76/imgui_bundle_cmake/imgui_bundle_build_lib.cmake#L27-L50
function(ibd_force_freetype_static_for_python)
    # For python bindings, we force the usage of a static version of freetype
    if(IMGUI_BUNDLE_BUILD_PYTHON AND HELLOIMGUI_USE_FREETYPE)
        # if using vcpkg, we suppose it uses the static version of freetype
        if(NOT "$ENV{CMAKE_TOOLCHAIN_FILE}" MATCHES "vcpkg")
            set(HELLOIMGUI_FREETYPE_STATIC ON CACHE BOOL "" FORCE)
        endif()
    endif()
endfunction()

# Check if freetype is available: ON by default, except on Android and MinGW
# On MacOS, if building a distributable wheel with cibuilwheel for a version less than 14.0, we disable freetype
function(ibd_check_freetype_availability result_var)
    # freetype is available by default
    set(${result_var} ON PARENT_SCOPE)

    # Except on Android and MinGW
    # Freetype is not available on Android. The mix SDL + Freetype cause issues (cannot find SDL.h)
    # Freetype currently fails to build on MinGW
    if(ANDROID OR MINGW)
        set(${result_var} OFF PARENT_SCOPE)
        return()
    endif()

hello_imgui_build_lib.cmake: build a static version of freetype (without Brolti) and links with it
hello_imgui_build_lib.cmake will

downloads a build freetype if HELLOIMGUI_FREETYPE_STATIC (we can see in the logs that this is done)
Call

set(freetype_linked_library freetype) # We would like this to be the result of our compilation...
target_link_libraries(imgui PUBLIC ${freetype_linked_library})

https://github.com/pthom/hello_imgui/blob/6f96155f5cb90dff93da21444d8586aca1ade17b/hello_imgui_cmake/hello_imgui_build_lib.cmake#L391-L421
        if(HELLOIMGUI_FREETYPE_STATIC AND NOT HELLOIMGUI_FETCH_FORBIDDEN)
            message("Forcing download of Freetype because HELLOIMGUI_FREETYPE_STATIC is ON")
            set(download_freetype ON)
        endif()

        if (download_freetype)
            message(STATUS "HelloImGui: downloading and building freetype")

            set(backup_shared_lib ${BUILD_SHARED_LIBS})
            set(BUILD_SHARED_LIBS OFF CACHE BOOL "" FORCE)

            if (NOT HELLOIMGUI_INSTALL)
                set(SKIP_INSTALL_ALL ON CACHE INTERNAL "" FORCE) # disable Freetype install
            endif()

            include(FetchContent)
            if(IOS)
                set(FT_DISABLE_HARFBUZZ ON CACHE BOOL "" FORCE)
                set(FT_DISABLE_BROTLI ON CACHE BOOL "" FORCE)
            endif()
            FetchContent_Declare(
                freetype
                GIT_REPOSITORY https://github.com/freetype/freetype.git
                GIT_TAG        VER-2-13-2
                GIT_PROGRESS TRUE
            )
            FetchContent_MakeAvailable(freetype)
            set(freetype_linked_library freetype)

and then freetype_linked_library is used with:
    target_link_libraries(imgui PUBLIC ${freetype_linked_library})

Wheel build log:
Below, I include extracts from the build logs on GitHub CI
We can see this lines, which shows that

Freetype was built
However, the link did not use our built version, but instead a version at '/opt/homebrew/Cellar/brotli/1.1.0/lib/libbrotlidec.1.1.0.dylib which is not for the correct architecture

Some extracts:
Build of freetype:
https://github.com/pthom/imgui_bundle/actions/runs/11166142777/job/31039470761#step:3:5460
"  -- HelloImGui: downloading and building freetype"
https://github.com/pthom/imgui_bundle/actions/runs/11166142777/job/31039470761#step:3:7678
"    [173/308] Building C object _deps/freetype-build/CMakeFiles/freetype.dir/src/autofit/autofit.c.o"
https://github.com/pthom/imgui_bundle/actions/runs/11166142777/job/31039470761#step:3:7868
Link step, extract
    [306/308] Linking CXX shared module _imgui_bundle.cpython-312-darwin.so
    ld: warning: ignoring duplicate libraries: '-ldl', 'external/hello_imgui/hello_imgui/src/hello_imgui/libimgui_test_engine.a', 'external/immapp/immapp/libimmapp.a', 'external/libimgui.a', 'external/libimgui_md.a', 'external/libimgui_node_editor.a'
    ld: warning: ignoring file '/opt/homebrew/Cellar/libpng/1.6.44/lib/libpng16.16.dylib': found architecture 'arm64', required architecture 'x86_64'
    ld: warning: ignoring file '/opt/homebrew/Cellar/libpng/1.6.44/lib/libpng16.16.dylib': found architecture 'arm64', required architecture 'x86_64'
    ld: warning: ignoring file '/opt/homebrew/Cellar/harfbuzz/9.0.0/lib/libharfbuzz.0.dylib': found architecture 'arm64', required architecture 'x86_64'
    ld: warning: ignoring file '/opt/homebrew/Cellar/brotli/1.1.0/lib/libbrotlidec.1.1.0.dylib': found architecture 'arm64', required architecture 'x86_64'
    [307/308] cd /var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/tmplel4blzs/build && /opt/homebrew/Cellar/cmake/3.30.3/bin/cmake -E copy /var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/tmplel4blzs/build/_imgui_bundle.cpython-312-darwin.so /Users/runner/work/imgui_bundle/imgui_bundle/bindings/imgui_bundle/_imgui_bundle.cpython-312-darwin.so
    [308/308] cd /var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/tmplel4blzs/build && /opt/homebrew/Cellar/cmake/3.30.3/bin/cmake -E copy /var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/tmplel4blzs/build/_imgui_bundle.cpython-312-darwin.so /private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/cibw-run-k97iif_g/cp312-macosx_x86_64/build/venv/lib/python3.12/site-packages/imgui_bundle/_imgui_bundle.cpython-312-darwin.so

Those warnings explain the failure:
    ld: warning: ignoring file '/opt/homebrew/Cellar/libpng/1.6.44/lib/libpng16.16.dylib': found architecture 'arm64', required architecture 'x86_64

Conclusion
We did build a static version of freetype.
Unfortunately, the lines
     set(freetype_linked_library freetype)
    target_link_libraries(imgui PUBLIC ${freetype_linked_library})

Do not give precedence to our static libraries and instead it uses a library found on the OS which does not have the good architecture.

I'm trying two patches:

https://github.com/pthom/imgui_bundle/commit/2bbce5b3b91aa8627f47cc2d3151306930faa805: disable the use of system libraries. CMake is happily ignoring this, and still tries to link brotli, harfbuzz from homebrew...
https://github.com/pthom/hello_imgui/commit/67e0cc8b2e20ec5f31e4ac9759d24448c939ebec:
build freetype without harfbuzz, brotli and png

For more details, see https://chatgpt.com/share/66ffb718-6408-8004-be5b-9e74064a8709
Please keep in touch and answer the two questions below:

Try the previous wheel, after having installed freetype

brew install freetype

The idea is that I guess that the stock version of freetype is built with harfbuzz, brotli and png. Maybe they will be found once you run. Keep me informed whether it works or not.

Try the wheels at https://github.com/pthom/imgui_bundle/actions/runs/11178781726/job/31077057633
They are using those two patches and I hope they will work.

Conclusions and follow-up

Building freetype without support for brotli, png, and harfbuzz might limit the range of possible fonts (see chatgpt analysis below)
building python libraries with native dependencies is a nightmare: I'm begin to think I might have to switch to conan,  instead (or in addition to) pip.

Effect of disabling features in freetype, according to ChatGPT:

Disabling Harfbuzz, Brotli, and PNG in FreeType primarily affects fonts with advanced layout features and bitmap compression.
Harfbuzz: Without it, complex text shaping (for scripts like Arabic, Hindi, etc.) won’t work, but most Latin-based fonts will be unaffected.
Brotli: Disabling it affects fonts using Brotli compression, mostly impacting modern Google Fonts or web-based fonts.
PNG: Disabling PNG impacts bitmap glyphs that use PNG, typically affecting embedded bitmaps in some fonts (e.g., emoji fonts).
For most general-purpose fonts, the impact will be minimal.

Hi! I also happened to encounter this problem today.
I can verify that using the wheel at:
https://github.com/pthom/imgui_bundle/actions/runs/11178781726/artifacts/2015448630
imgui_bundle-1.5.2-cp312-cp312-macosx_14_0_x86_64.whl
Fixed the problem for me. Thank you!

@dwgrth : Thanks! If you have time, could you also try other the alternative (brew install freetype + install the standard wheel), and tell me if it works for you.
Thanks!

Maybe you could uninstall the system freetype?

However, the wheel fixed the problem for me too.

Are you planning to do a release with this fix in the near future?

Yes, I think I will make a release in about a month.

So.. no.


Always on red warning section/separator

A noob vim-airline question. I just installed vim-airline without any custom configuration. At the very right end of the status line there is an always on red/orange (solarized dark theme) right separator showing. This appears no regardless of using powerline symbols or not. This could be intentional, to indicate an empty warning section. If I add trailing whitespaces to a buffer, this section expands to show 'trailing X'.
Is it possible to have this section and it separator to only show if warnings exist. I would like to not have a red/orange separator in the statusline, distracting me when there are no warning. Perhaps the separator could simply have a neutral color when there are no warnings. Any suggestions are welcome.

Am 2016-11-01 09:05, schrieb hejersbo:

A noob vim-airline question. I just installed vim-airline without any
custom configuration. At the very right end of the status line there
is an always on red/orange (solarized dark theme) right separator
showing. This appears no regardless of using powerline symbols or not.
This could be intentional, to indicate an empty warning section. If I
add trailing whitespaces to a buffer, this section expands to show
'trailing X'.
Is it possible to have this section and it separator to only show if
warnings exist. I would like to not have a red/orange separator in the
statusline, distracting me when there are no warning. Perhaps the
separator could simply have a neutral color when there are no
warnings. Any suggestions are welcome.

This is expected. Duplicate of #1280 See there for a solution

Thanks for quick response. Referenced solution worked.


Add support for low level JWE functions

This PR adds support for low level JWE creation and decryption using the XChacha20Poly1305 symmetric cipher and asymmetric cipher using x25519 key exchange. It also includes a minimal implementation of the concatKDF. All crypto is implemented using the @stablelib packages.
Test vectors where generated using the jose-chacha library.
In addition all reliance on Buffer is removed from the library.

Merged master into this branch, so should be mergeable now.

Thank you very much @mirceanis! Looking forward to future updates :)


Local Layer latest version compatible with WAB 2.8?

We are going to use Dynamic Layers on our own ArcGIS Server and Feature Layers , and we are going to use WAB 2.8, is Latest local Layer compatible with WAB 2.8? If not what needs to be done to make it compatible, Thanks

A 2.8 version is available below; I just haven't rolled it out yet, but it
should be tested to work and contains a number of bug fixes.
https://github.com/cmndrbensisko/LocalLayer/tree/LocalLayerv.2.8
On Tue, Jul 10, 2018 at 4:16 PM, gbhardwaj09<EMAIL_ADDRESS>wrote:

We are going to use Dynamic Layers on our own ArcGIS Server and Feature
Layers , and we are going to use WAB 2.8, is Latest local Layer compatible
with WAB 2.8? If not what needs to be done to make it compatible, Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cmndrbensisko/LocalLayer/issues/63, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AF_6yoNJX-5YWhDhoCon0fBwNFeTJa_cks5uFQuNgaJpZM4VKDYo
.

Thanks a lot :)

Can we adjust opacity of Dynamic layers in Local Layer config? I have a map service where I don't want to change opacity of all layers


armada-load-tester loadtest not submitting without --watch fix

fix #419
Use a nested WaitGroup to ensure level 1 goroutines wait for level 2 goroutines.
Can alternatively be done using same WaitGroup and expecting two routines to finish (Add(2)), as there is a 1-1 mapping between level 1 and level 2 goroutines. Thought this way was more explicit.

You could even have runSubmission function create the waitGroup and return it. Call it something like submissionComplete.
Then callers to runSubmission can use the waitGroup to wait for submission to finish.

Thanks for the comments, will proceed to fix


Using GPU and Still Get: Illegal instruction (core dumped)

Hi,
I'm trying to use the library to quantize the pretrained ResNet18 model into hybrid mode (or in my case, any FP8 mode is fine).
However, when I try to run the following codes, it gives me the error: Illegal instruction (core dumped). I'm confused by the message, and I noticed that an issue is reported with same problem. The reason of the old issue is because of the version of CPU is too old, but I am trying to use GPU (Nvidia A100) instead of CPU. And the followings are my system settings and codes, hope this might help. Thanks.
In addition, I also want to double check the meaning of "device input to the script" you've mentioned here.
Thanks and wish you a good day.
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   43 bits physical, 48 bits virtual
CPU(s):                          256
On-line CPU(s) list:             0-255
Thread(s) per core:              2
Core(s) per socket:              64
Socket(s):                       2
NUMA node(s):                    8
Vendor ID:                       AuthenticAMD
CPU family:                      25
Model:                           1
Model name:                      AMD EPYC 7713 64-Core Processor
Stepping:                        1
Frequency boost:                 enabled
CPU MHz:                         2905.102
CPU max MHz:                     3720.7029
CPU min MHz:                     1500.0000
BogoMIPS:                        3992.55
Virtualization:                  AMD-V
L1d cache:                       4 MiB
L1i cache:                       4 MiB
L2 cache:                        64 MiB
L3 cache:                        512 MiB
NUMA node0 CPU(s):               0-15,128-143
NUMA node1 CPU(s):               16-31,144-159
NUMA node2 CPU(s):               32-47,160-175
NUMA node3 CPU(s):               48-63,176-191
NUMA node4 CPU(s):               64-79,192-207
NUMA node5 CPU(s):               80-95,208-223
NUMA node6 CPU(s):               96-111,224-239
NUMA node7 CPU(s):               112-127,240-255
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full AMD retpoline, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
                                 rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2
                                 apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skini
                                 t wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 invpcid_single hw_pstate ssbd mba ibrs ibpb stibp v
                                 mmcall fsgsbase bmi1 avx2 smep bmi2 invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_
                                 occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd amd_ppin arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean f
                                 lushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov su
                                 ccor smca sme sev sev_es

import torch
import torchvision

import os
import torch
import torchvision
import torchvision.transforms as transforms
import torchvision.datasets as datasets

import time
import argparse
from mpemu import mpt_emu

def modelSetup():
    # load resnet18 pretrained model.
    model = torchvision.models.resnet18(pretrained=True)
    return model

# main function
def main():

    # Get model
    model = modelSetup()

    # Output model & its weights
    print(model)

    # Transfer model to FP8 using FP8-Emulation-Toolkit
    list_exempt_layers = ["conv1","fc"]
    model, emulator = mpt_emu.quantize_model (model,
                                              dtype="hybrid",
                                              device="cuda",
                                              list_exempt_layers=list_exempt_layers)

main()

modify the cmd_inference.py script to remove the last line --no_cuda

https://github.com/IntelLabs/FP8-Emulation-Toolkit/issues/6#issuecomment-1669490530

@xuann6 same problem!

@lippman1125 I somehow fix the problem. Maybe you can paste your code here for me to take a look?

@xuann6 I am also getting the same error running the code you posted above. What was your fix?

@uvikas can you paste your code? Have you add the list_exempt_layers in to quantization condition?

@xuann6 I am using the same code you posted above.
import torch
import torchvision

import os
import torch
import torchvision
import torchvision.transforms as transforms
import torchvision.datasets as datasets

import time
import argparse
from mpemu import mpt_emu

def modelSetup():
    # load resnet18 pretrained model.
    model = torchvision.models.resnet18(pretrained=True)
    return model

# main function
def main():

    # Get model
    model = modelSetup()

    # Output model & its weights
    print(model)

    # Transfer model to FP8 using FP8-Emulation-Toolkit
    list_exempt_layers = ["conv1","fc"]
    model, emulator = mpt_emu.quantize_model (model,
                                              dtype="hybrid",
                                              device="cuda",
                                              list_exempt_layers=list_exempt_layers)

main()

Getting Illegal instruction error

Use device=torch.device("cuda") instead of just passing the string. That should fix your issue.
Also, the latest update should support AMD devices including MI 200 GPUs.


Add md files and update some links

Yooo @codenamejason thanks for this!
Made a little tweak and ready to merge.


Fix navbar

Description
Fix and update navbar in all pages according to the landing page.
Definition of Done

[x] All of the required items are completed.
[x] Approval by 1 mentor.

Hey can u assign me....

clarification needed - all page's navbar should be same as index.html page, right?

Yes @ronitsingh1405

Hey I see that issue #19 is similar to this issue so maybe I can work on both at the same time :)

@ronitsingh1405 Ok join our discord server link is in readme for communication.


feat: s3 interface endpoint

Description
Creates the opportunity to create interface style S3 endpoint while it maintains backward API compatibility.
Fixing the error which was introduced in #573 and #564
Motivation and Context
In the PR #573 variable "s3_endpoint_type" was introduced. This works with default ("Gateway") value. However if you try to  attach "Interface" interface style endpoint to a route table it will cause error
Used configuration
  enable_s3_endpoint        = true
  enable_public_s3_endpoint = false
  s3_endpoint_type          = "Interface"

Error message
Error: An Interface VPC Endpoint must always have at least one Security Group

A gateway style endpoint attach itself to a route table

An interface style endpoint attach itself to subnets and needs SG to make it work

Just looking through the existing PR's to see if anyone had added support for this. The S3 interface endpoint doesn't support private DNS though as I just found out.


Update CloudBigtableIO Java Doc.

Marcal is off to his vacation

LGTM

Jeff, please also take a look.

LGTM


Don't require backticks around reserved words used as column names

From https://github.com/liquidata-inc/go-mysql-server/issues/169

This is a lot better now. The problem still exists but shouldn't come up nearly as often. Closing this out for the time being.


apicall hook snprintf function and variants

Some decoding routines rely on string formatting routines such as snprintf. Example: 9dab...106c

@mr-tz can I take up this issue and could you guide me where to find example you mentioned

Of course, unfortunately, I don't have the sample handy anymore, but we can easily create a test C program that uses snprintf etc. to test API hooks we create. Can you go ahead with that or do you want me to provide more details?

Ok, I will make the test C program and start working on this

@mr-tz Sorry for the delay. I was using this C code to test the hook
#include <stdio.h>

void print_string(char* buffer, int value) {

    snprintf(buffer, 100, "The value is: %d", value);
}

int main() {
    char buffer[100];
    int value = 42;

    print_string(buffer, value);

    printf("%s\n", buffer);

    return 0;
}

But the hook wasn't getting triggered. Is there something wrong I am doing ?
Here is my code

That looks good. Does vivisect recognize the snprintf call correctly? If not you could link it dynamically.

Ok yes I will check on that

@mr-tz I have gone through the documentation of Vivisect and tried to play around with it. From how much I observe the the only way to find the snprintf call is to parse opcode from the basic block in the function and find out which set of operations is likely to do a snprintf call. I can't figure out how to find what set assembly-level code will likely resemble the call we are targeting. Could you guide me through or is my logic behind the implementation wrong?

Did you try dynamic linking?


docker compose build failed when running to vcs import < dependencies.repos

@sea-bass Hi,as the title described,the build process failed when running to vcs import < dependencies.repos:

I don't know if it is due to the network setup on my host machine because I use clash for windows to proxy my network,but the error still occurs after I set the --build-arg http_proxy and --build-arg https_proxy to my host proxy configuration:

so I want ask you if there any solution and I'd appreciate it if you could give me some advice!

Ooh, that is tricky one...
You could try RUN sudo apt install openssl in the Dockerfile and change the contents of the dependencies.repos file to use the SSH form (e.g., git@github.com/ROBOTIS-GIT/turtlebot3.git)... or set up the git config with your proxy as part of the build.
Both of these possible solutions are described in this StackOverflow post

Ooh, that is tricky one...
You could try RUN sudo apt install openssl in the Dockerfile and change the contents of the dependencies.repos file to use the SSH form (e.g., git@github.com/ROBOTIS-GIT/turtlebot3.git)... or set up the git config with your proxy as part of the build.
Both of these possible solutions are described in this StackOverflow post

OK,thanks for your detailed reply,I'll try the sugeestios you have mentioned above and give you feedback if there is any progress!:-)

Ooh, that is tricky one...
You could try RUN sudo apt install openssl in the Dockerfile and change the contents of the dependencies.repos file to use the SSH form (e.g., git@github.com/ROBOTIS-GIT/turtlebot3.git)... or set up the git config with your proxy as part of the build.
Both of these possible solutions are described in this StackOverflow post

OK,thanks for your detailed reply,I'll try the sugeestios you have mentioned above and give you feedback if there is any progress!:-)

Update:Sorry to give you the feedback so late because I'm not at home these days,but now the installation seems to be ok after I turn off the ssl certificate follow the blog:

but I'm not sure whether this will impact my network afterwards,Anyway,I will continue to follow up the feedback if there is any problem after

Ooh, that is tricky one...
You could try RUN sudo apt install openssl in the Dockerfile and change the contents of the dependencies.repos file to use the SSH form (e.g., git@github.com/ROBOTIS-GIT/turtlebot3.git)... or set up the git config with your proxy as part of the build.
Both of these possible solutions are described in this StackOverflow post

OK,thanks for your detailed reply,I'll try the sugeestios you have mentioned above and give you feedback if there is any progress!:-)

Update:Sorry to give you the feedback so late because I'm not at home these days,but now the installation seems to be ok after I turn off the ssl certificate follow the blog:  but I'm not sure whether this will impact my network afterwards,Anyway,I will continue to follow up the feedback if there is any problem after

The error still occurred and I confused the apt-get update part with vcs import < dependencies.repos,the screenshot still shows the process of apt-get update not vcs import < dependencies.repos which means I have to try other solutions:-(

You can either add --recursive parameter to vcs in the docker file
RUN vcs import --recursive < dependencies.repos

or clone them locally in a new directory src then copy it to the workspace:
In a native terminal inside the repository
mkdir src
vcs import < dependencies.repos ./src/

And modify this line to COPY src/ ./src/ https://github.com/sea-bass/turtlebot3_behavior_demos/blob/187dbf35a4439ed55b5bfa2b79961e48c4da94a5/docker/Dockerfile#L28


Change Signal Categorization

Public Behavior (renamed from Public's Behavior): vaccine acceptance, mask wearing.
Early Indicators: CTIS-CLI, CTIS-CLI-in-community, DV-CLI
Cases and Testing: Cases, Antigen-TPR (Quidel), PCR-TPR (CAN)
Late Indicators: Hospitalizations (HHS), Deaths

I'll fetch feedback on this Tuesday afternoon.

@sgratzl @krivard This looks perfect, with the exceptions that:

the Google symptoms search signal is in the Public Behavior category, and
there's no PCR-TRP at the moment?

I'd be happy implementing this in time for the v3 launch if we're able to---looks like the change at this point would just be creating a new category "Cases and Testing" and putting those two signals in there (they are currently lumped in the "Late Indicators" category, in the current version). If not, then it's also not a big deal (not launch-blocking, for me).

@sgratzl Just a reminder about this for v3.1. Thanks!

current dev: https://dev--cmu-delphi-covidcast.netlify.app/

@sgratzl I know you just closed this, but going to look at your screenshot led to one small request ---- I wonder if it's easy enough to change with just one line in some spreadsheet somewhere.
Can you put "COVID-Related Doctor Visits" so it shows up as the last indicator (among the three) in the "Early Indicators" category?  Logically, it comes later than the other two.  Thanks!