scheduler | /usr/local/lib/python3.10/dist-packages/airflow/models/base.py:49 MovedIn20Warning: Deprecated API features detected! These feature(s) are not compatible with SQLAlchemy 2.0. To prevent incompatible upgrades prior to updating applications, ensure requirements files are pinned to "sqlalchemy<2.0". Set environment variable SQLALCHEMY_WARN_20=1 to show all deprecation warnings. Set environment variable SQLALCHEMY_SILENCE_UBER_WARNING=1 to silence this message. (Background on SQLAlchemy 2.0 at: https://sqlalche.me/e/b8d9)
webserver | /usr/local/lib/python3.10/dist-packages/airflow/models/base.py:49 MovedIn20Warning: Deprecated API features detected! These feature(s) are not compatible with SQLAlchemy 2.0. To prevent incompatible upgrades prior to updating applications, ensure requirements files are pinned to "sqlalchemy<2.0". Set environment variable SQLALCHEMY_WARN_20=1 to show all deprecation warnings. Set environment variable SQLALCHEMY_SILENCE_UBER_WARNING=1 to silence this message. (Background on SQLAlchemy 2.0 at: https://sqlalche.me/e/b8d9)
triggerer | /usr/local/lib/python3.10/dist-packages/airflow/models/base.py:49 MovedIn20Warning: Deprecated API features detected! These feature(s) are not compatible with SQLAlchemy 2.0. To prevent incompatible upgrades prior to updating applications, ensure requirements files are pinned to "sqlalchemy<2.0". Set environment variable SQLALCHEMY_WARN_20=1 to show all deprecation warnings. Set environment variable SQLALCHEMY_SILENCE_UBER_WARNING=1 to silence this message. (Background on SQLAlchemy 2.0 at: https://sqlalche.me/e/b8d9)
i tried airflow standalone on ec2 instance and error occured
Related
I've been unable to query my existing contract recently due to Unable to create Enum via index 128, in Alive, Tombstone when using api.query.contracts.contractInfoOf. I get this error both on the command line and in the polkadot-js apps explorer.
These are the steps I took:
Deploy a contract with a salt
Retrieve the contract deployedAddress
Use contractInfoOf
const contractInfo = await api.query.contracts.contractInfoOf(deployedAddress);
I've tried downgrading ink! to 3.0-rc5, 3.0-rc4, 3.0-rc3 and then compiling but it doesn't seem to make any difference. Whenever my contract is built it references rc6 at the top:
{"metadataVersion":"0.1.0","source":{"hash":"0x...","language":"ink! 3.0.0-rc6","compiler":"rustc 1.58.0-nightly",
Which suggests its ignoring my .toml and using rc6 to compile the contract.
I changed my cargo-contract version to 0.14 but that causes polkadot-js to fail at reading the contract abi.
I've tried using the substrate-contracts-node using the latest commit from master and also using the v0.1.0 release. Same error in both cases.
> rustup info
stable-x86_64-unknown-linux-gnu (default)
rustc 1.56.1 (59eed8a2a 2021-11-01)
There are more details in an issue on polkadot-js.
Any pointers on how to get a working setup would be very helpful!
The problem here was substrate-contracts-node using an old version of the metadata.
I was able to check out the repo before the metadata merge was reverted and build locally (cargo build).
So checkout 8d91b8e to get the node to work with versions 7.7.1 and 6.6.1 of polkadot-js packages.
> git checkout 8d91b8e578065a7c06433cbd41ac059bf478a0bd
> cargo build
> ./target/debug/substrate-contracts-node --dev --tmp --version
substrate-contracts-node 0.1.0-8d91b8e-x86_64-linux-gnu
Starting 2020-12-09, VSCode's Rust Analyzer extension no longer loads for me. On launch, it prints out this error message:
Cannot activate rust-analyzer: bootstrap error. See the logs in "OUTPUT > Rust Analyzer Client" (should open automatically). To enable verbose logs use { "rust-analyzer.trace.extension": true }
Enabling extension tracing produces the following diagnostic just before failing:
INFO [12/10/2020, 10:03:22 AM]: Using server binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: Checking availability of a binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe --version: {
status: 3221225506,
signal: null,
output: [ null, '', '' ],
pid: 1648,
stdout: '',
stderr: ''
}
where <user> is the name of the user account I use to log into the system1.
The status value reported in the error diagnostic (3221225506) translates to 0xC0000022 (STATUS_ACCESS_DENIED). Navigating to the binary from within VSCode's integrated terminal and trying to execute rust-analyzer-windows.exe --version doesn't produce any output, which seems to reinstate that running this executable from VSCode is somehow blocked.
It appears that something changed with respect to access rights executing the server binary from within VSCode. In between Rust Analyzer working and Rust Analyzer no longer working I didn't update Rust, nor rustup, nor VSCode, nor any extensions.
I did install 2020-12 Cumulative Update for Windows 10 Version 20H2 for x64-based Systems (KB4592438), though, and the time Rust Analyzer started failing coincides with the time the update got installed. That could literally just be a coincidence.
What additional steps can I take to get to the root cause of the issue, and how do I get Rust Analyzer working again?
Version information:
Rust Analyzer (stable): v0.2.408
Windows 10 Pro: Version 10.0.19042 Build 19042
VSCode: 1.51.1 (user setup)
1 This is also the user account VSCode runs under, including all of its spawned processes. Navigating to the path from a command prompt running under this account reveals that rust-analyzer-windows.exe is present, and executing rust-analyzer-windows.exe --version prints a version identifier, as expected.
Unfortunately, I didn't quite get to investigate the root cause of this.
A system reboot that was forced upon me appears to have restored World Peace.
Clearing proxy config works for me.
I'm not sure this covered all situation, but it might be related to the network.
I am trying to build a python 3.5 environment that supports an old hddm library. Standard approaches fail due to my/anaconda's apparent inability in ignore (or downgrade) the 10.1 cuda library in favor of an older one that works with hddm.
There is a yml file available that describes a successful environment. But the advertised command
conda env create -file hddm_py35.yml
fails with an error listing all of the packages "not found." Here are the errors.
(base) PS C:\Users\Peter\anaconda3_Sep2020> conda env create --file .\hddm_py35.yml
Collecting package metadata (repodata.json): done
Solving environment: failed
ResolvePackageNotFound:
odo==0.5.0=py35_1
cffi==1.7.0=py35_0
dill==0.2.5=py35_0
singledispatch==3.4.0.3=py35_0
nb_conda_kernels==2.0.0=py35_0
requests==2.14.2=py35_0
scikit-learn==0.17.1=np111py35_1
wheel==0.29.0=py35_0
jedi==0.9.0=py35_1
widgetsnbextension==1.2.6=py35_0
bitarray==0.8.1=py35_1
theano==1.0.2=py35_0
pytz==2016.6.1=py35_0
pylint==1.5.4=py35_1
ruamel_yaml==0.11.14=py35_0
partd==0.3.6=py35_0
llvmlite==0.13.0=py35_0
multipledispatch==0.4.8=py35_0
pyparsing==2.1.4=py35_0
console_shortcut==0.1.1=py35_1
ipython_genutils==0.1.0=py35_0
patsy==0.4.1=py35_0
pytest==2.9.2=py35_0
heapdict==1.0.0=py35_1
ipywidgets==5.2.2=py35_0
bokeh==0.12.2=py35_0
hdf5==1.8.15.1=2
networkx==1.11=py35_0
backports==1.0=py35_0
pyasn1==0.1.9=py35_0
pyqt==5.6.0=py35h6538335_6
zlib==1.2.11=hbb18732_2
et_xmlfile==1.0.1=py35_0
traitlets==4.3.0=py35_0
colorama==0.3.7=py35_0
argcomplete==1.0.0=py35_1
pywin32==220=py35_1
astropy==1.2.1=np111py35_0
nose==1.3.7=py35_1
freetype==2.8=h0224ed4_1
pkginfo==1.3.2=py35_0
cloudpickle==0.2.1=py35_0
sqlalchemy==1.0.13=py35_0
lazy-object-proxy==1.2.1=py35_0
markupsafe==0.23=py35_2
prompt_toolkit==1.0.3=py35_0
pickleshare==0.7.4=py35_0
itsdangerous==0.24=py35_0
babel==2.3.4=py35_0
click==6.6=py35_0
six==1.10.0=py35_0
libdynd==0.7.2=0
jdcal==1.2=py35_1
pymc==2.3.6=np111py35_2
pathlib2==2.1.0=py35_0
astroid==1.4.7=py35_0
numba==0.28.1=np111py35_0
qtconsole==4.2.1=py35_2
wrapt==1.10.6=py35_0
idna==2.1=py35_0
pytables==3.2.2=np111py35_4
_nb_ext_conf==0.3.0=py35_0
dynd-python==0.7.2=py35_0
numexpr==2.6.1=np111py35_0
werkzeug==0.11.11=py35_0
rope==0.9.4=py35_1
jupyter_client==4.4.0=py35_0
pyzmq==15.4.0=py35_0
python-dateutil==2.5.3=py35_0
beautifulsoup4==4.5.1=py35_0
blaze==0.10.1=py35_0
nbformat==4.1.0=py35_0
nbpresent==3.0.2=py35_0
sip==4.18=py35_0
chest==0.2.3=py35_0
glob2==0.5=py35_0
locket==0.2.0=py35_1
mistune==0.7.3=py35_0
alabaster==0.7.9=py35_0
setuptools==27.2.0=py35_1
win_unicode_console==0.5=py35_0
filelock==2.0.6=py35_0
_license==1.1=py35_1
ipykernel==4.5.0=py35_0
qt==5.6.2=vc14h6f76a7e_12
pep8==1.7.0=py35_0
xlwings==0.10.0=py35_0
spyder==3.0.0=py35_0
xlrd==1.0.0=py35_0
scipy==0.18.1=np111py35_0
dask==0.11.0=py35_0
nbconvert==4.2.0=py35_0
pip==8.1.2=py35_0
mkl==11.3.3=1
nb_anacondacloud==1.2.0=py35_0
cython==0.24.1=py35_0
flask-cors==2.1.2=py35_0
ipython==5.1.0=py35_0
cycler==0.10.0=py35_0
jpeg==9b=he27b436_2
menuinst==1.4.1=py35_0
anaconda==4.2.0=np111py35_0
configobj==5.0.6=py35_0
boto==2.42.0=py35_0
unicodecsv==0.14.1=py35_0
scikit-image==0.12.3=np111py35_1
contextlib2==0.5.3=py35_0
conda-build==3.0.19=py35h15d37ab_0
jinja2==2.8=py35_1
conda-verify==2.0.0=py35_0
get_terminal_size==1.0.0=py35_0
qtpy==1.1.2=py35_0
anaconda-client==1.5.1=py35_0
decorator==4.0.10=py35_0
ply==3.9=py35_0
openpyxl==2.3.2=py35_0
sockjs-tornado==1.0.3=py35_0
pyyaml==3.12=py35_0
snowballstemmer==1.2.1=py35_0
toolz==0.8.0=py35_0
py==1.4.31=py35_0
xlwt==1.1.2=py35_0
clyent==1.2.2=py35_0
bottleneck==1.1.0=np111py35_0
jupyter==1.0.0=py35_3
mkl-service==1.1.2=py35_2
simplegeneric==0.8.1=py35_1
wcwidth==0.1.7=py35_0
h5py==2.6.0=np111py35_2
gevent==1.1.2=py35_0
pycrypto==2.6.1=py35_4
datashape==0.5.2=py35_0
psutil==4.3.1=py35_0
nltk==3.2.1=py35_0
jsonschema==2.5.1=py35_0
notebook==4.2.3=py35_0
pycparser==2.14=py35_1
xlsxwriter==0.9.3=py35_0
jupyter_core==4.2.0=py35_0
qtawesome==0.3.3=py35_0
fastcache==1.0.2=py35_1
jupyter_console==5.0.0=py35_0
tornado==4.4.1=py35_0
path.py==8.2.1=py35_0
pyflakes==1.3.0=py35_0
sympy==1.0=py35_0
pandas==0.20.1=np111py35_0
pygments==2.1.3=py35_0
anaconda-clean==1.0.0=py35_0
mpmath==0.19=py35_1
comtypes==1.1.2=py35_0
cryptography==1.5=py35_0
chardet==3.0.4=py35_0
entrypoints==0.2.2=py35_0
sphinx==1.4.6=py35_0
greenlet==0.4.10=py35_0
anaconda-navigator==1.3.1=py35_0
flask==0.11.1=py35_0
pyopenssl==16.2.0=py35_0
lxml==3.6.4=py35_0
icu==58.2=h3fcc66b_1
docutils==0.12=py35_2
statsmodels==0.6.1=np111py35_1
nb_conda==2.0.0=py35_0
imagesize==0.7.1=py35_0
(base) PS C:\Users\Peter\anaconda3_Sep2020>
The failure occurred within seconds. I get the feeling that conda didn't even try to look for these packages!?!?
Am I supposed to download these packages, put them somewhere, and then tell conda to find them on my hard drive?
Is there a flag that tells conda to do its usually find-and-load for all "missing" packages -- but only in the environment I'm describing? In my base environment (3.8) I don't wish to downgrade.
Should make a new 3.5 environment and then work through the list one-by-one and uninstall/remove/downgrade each package by hand?
Meta question: This must be a FAQ, and yet I'm not able to google for the answer. That usually means googling for "conda install environment from yaml file" doesn't contain the appropriate vocabulary for, well, trying to induce conda to install an environment from a yaml file. What question should I have asked?
1) Am I supposed to download these packages, put them somewhere, and then
tell conda to find them on my hard drive?
Not necessary. But searching for the versions on anaconda.org helps identify channels for one-by-one manual download.
2) Is there a flag that tells conda to do its usually find-and-load for all
"missing" packages -- but only in the environment I'm describing? In my base
environment (3.8) I don't wish to downgrade.
There is no evidence that conda will automatically download files listed in a yaml file that are missing in the present environment.
3) Should make a new 3.5 environment and then work through the list one-by-
one and uninstall/remove/downgrade each package by hand?
Yes.
4) Meta question: This must be a FAQ, and yet I'm not able to google for the
answer. That usually means googling for "conda install environment from yaml
file" doesn't contain the appropriate vocabulary for, well, trying to induce
conda to install an environment from a yaml file. What question should I have
asked?
There is no evidence that yaml files are anything other than lists of version of packages in an environment. They cannot be used to make new environments (unless all of the components are already present in the host environment, maybe) so their value is largely annotative. Evidently.
For the case of making an environment for hddm in 2020, well, don't try. Cuda support will work against you. There is a hddm host at https://colab.research.google.com/ that is properly configured (without cuda disruption) so that you can use it to kick tires, etc. Getting hddm to work in any other context probably requires dedicated hardware so that the cuda driver can be manipulated for this application only and not break any other applications in the process.
I have built a Cordova-based Windows application. As soon as I add any plugin, the app starts crashing with the exception cordova/windows8/commandProxy not found.
Cordova version: 4.3.0
It seems that cordova/windows8/commandProxy is deprecated in Cordova 4.3.0.
I have replaced this statement in plugin file
require("cordova/windows8/commandProxy")
to
require("cordova/exec/proxy")
and it seems to work.
For example I changed line number 18 in PushPluginProxy.js from
require("cordova/windows8/commandProxy").add("PushPlugin", module.exports);
to
require("cordova/exec/proxy").add("PushPlugin", module.exports);
The name in the string varies depending on the plugin.
Alternatively, you can patch the plugin like in this pull request from the AppVersion plugin i.e.:
Change
require("cordova/windows8/commandProxy").add("AppVersion", AppVersionProxy);
to
cordova.commandProxy.add("AppVersion", AppVersionProxy);
Using version 3.7 of equinox I can set :
Constants.FRAMEWORK_STORAGE_CLEAN, "true" and
"osgi.console", consolePortasString()
With equinox version 3.9 setting FRAMEWORK_STORAGE_CLEAN to "true" does not work but setting to "onFirstInit" does.
Has the "true"setting been intentionally dropped from equinox?
Also the console port setting does not work in 3.9.
What is the suggested/intended method for setting these values in 3.9?