achiku/dgw 161
dgw generates Golang struct, and simple Table/Row Data Gateway functions from PostgreSQL table metadata
Go 1.7+ HTTP API server sample
Ansible role to install and manage lnd configuration
See who's coming to your event
akirachiku.com
https://akirachiku.com using Hugo
Integration SQLAlchemy in Django projects for effective query building purposes
Ansible role that installs Go (http://golang.org/). The latest stable release that has been compiled for x86 64-bit Linux systems is installed by default, and different platforms and versions are supported by modifying the role variables.
Ansible Go language role
ansible openswan role
pull request commentbitcoin/bitcoin
Replace unused BIP 9 logic with draft BIP 8
@michaelfolkson Are you saying that the LOT=true code can't even exist, or just that it can't be enabled for any SF proposals (specifically Taproot)?
Seems like a bizarre requirement considering it is actually in the BIP, but perhaps theres a reason.
comment created time in 5 minutes
pull request commentlightningnetwork/lnd
Added a new commit that retracts version v0.0.2
: https://github.com/lightningnetwork/lnd/pull/5034/commits/ee8f1a811e7acf23f930e57ebc787b548976764f
comment created time in 7 minutes
issue closedpytest-dev/pytest
[Fork Infra] xdist compatibility issues on github actions
This seems to only occur on my fork, any ideas why that is? When I opened a draft PR against pytest-dev it was OK it seems. I have no idea why it is attempting to use pytest 5.4
Run tox -e py36-xdist
.package create: D:\a\pytest\pytest\.tox\.package
.package installdeps: setuptools>=42.0, setuptools-scm[toml]>=3.4, wheel
py36-xdist create: D:\a\pytest\pytest\.tox\py36-xdist
py36-xdist installdeps: pygments>=2.7.2, pytest-xdist>=2.1.0, -e.
ERROR: invocation failed (exit code 1), logfile: D:\a\pytest\pytest\.tox\py36-xdist\log\py36-xdist-1.log
================================== log start ==================================
Obtaining file:///D:/a/pytest/pytest
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Preparing wheel metadata: started
Preparing wheel metadata: finished with status 'done'
Collecting pygments>=2.7.2
Downloading Pygments-2.8.0-py3-none-any.whl (983 kB)
Collecting pytest-xdist>=2.1.0
Downloading pytest_xdist-2.2.1-py3-none-any.whl (37 kB)
Collecting py>=1.8.2
Using cached py-1.10.0-py2.py3-none-any.whl (97 kB)
Collecting iniconfig
Downloading iniconfig-1.1.1-py2.py3-none-any.whl (5.0 kB)
Collecting pluggy<1.0.0a1,>=0.12
Using cached pluggy-0.13.1-py2.py3-none-any.whl (18 kB)
Collecting toml
Using cached toml-0.10.2-py2.py3-none-any.whl (16 kB)
Collecting packaging
Using cached packaging-20.9-py2.py3-none-any.whl (40 kB)
Collecting attrs>=19.2.0
Downloading attrs-20.3.0-py2.py3-none-any.whl (49 kB)
Collecting atomicwrites>=1.0
Downloading atomicwrites-1.4.0-py2.py3-none-any.whl (6.8 kB)
Collecting colorama
Using cached colorama-0.4.4-py2.py3-none-any.whl (16 kB)
Collecting importlib-metadata>=0.12
Using cached importlib_metadata-3.7.0-py3-none-any.whl (11 kB)
Collecting pytest-xdist>=2.1.0
Downloading pytest_xdist-2.2.0-py3-none-any.whl (36 kB)
Downloading pytest_xdist-2.1.0-py3-none-any.whl (36 kB)
INFO: pip is looking at multiple versions of pygments to determine which version is compatible with other requirements. This could take a while.
Collecting pygments>=2.7.2
Downloading Pygments-2.7.4-py3-none-any.whl (950 kB)
Downloading Pygments-2.7.3-py3-none-any.whl (950 kB)
Downloading Pygments-2.7.2-py3-none-any.whl (948 kB)
INFO: pip is looking at multiple versions of <Python from Requires-Python> to determine which version is compatible with other requirements. This could take a while.
INFO: pip is looking at multiple versions of pytest to determine which version is compatible with other requirements. This could take a while.
ERROR: Cannot install pytest 5.4.1.dev1410+g220455a17 (from D:\a\pytest\pytest), pytest-xdist==2.1.0, pytest-xdist==2.2.0 and pytest-xdist==2.2.1 because these package versions have conflicting dependencies.
The conflict is caused by:
The user requested pytest 5.4.1.dev1410+g220455a17 (from D:\a\pytest\pytest)
pytest-xdist 2.2.1 depends on pytest>=6.0.0
The user requested pytest 5.4.1.dev1410+g220455a17 (from D:\a\pytest\pytest)
pytest-xdist 2.2.0 depends on pytest>=6.0.0
The user requested pytest 5.4.1.dev1410+g220455a17 (from D:\a\pytest\pytest)
pytest-xdist 2.1.0 depends on pytest>=6.0.0
To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies
=================================== log end ===================================
ERROR: could not install deps [pygments>=2.7.2, pytest-xdist>=2.1.0, -e.]; v = InvocationError("'D:\\a\\pytest\\pytest\\.tox\\py36-xdist\\Scripts\\python.EXE' -m pip install 'pygments>=2.7.2' 'pytest-xdist>=2.1.0' -e.", 1)
___________________________________ summary ___________________________________
ERROR: py36-xdist: could not install deps [pygments>=2.7.2, pytest-xdist>=2.1.0, -e.]; v = InvocationError("'D:\\a\\pytest\\pytest\\.tox\\py36-xdist\\Scripts\\python.EXE' -m pip install 'pygments>=2.7.2' 'pytest-xdist>=2.1.0' -e.", 1)
Error: Process completed with exit code 1.
closed time in 7 minutes
symonkissue openedpython/mypy
Bug Report
To Reproduce
from typing import Dict
a: Dict[int, str] = {}
b: Dict[object, str] = {object(): 'a', 'lol': 'b', **a}
Expected Behavior no error
Actual Behavior
confusing error message Argument 1 to "update" of "dict" has incompatible type "Dict[int, str]"; expected "Mapping[object, str]"
even though update method was not used
Your Environment
<!-- Include as many relevant details about the environment you experienced the bug in -->
- Mypy version used: 0.812
- Mypy command-line flags: none
- Mypy configuration options from
mypy.ini
(and other config files): none - Python version used: 3.7.3
created time in 14 minutes
issue closedpython/mypy
Bug Report
mypy errors code below
To Reproduce
from typing import Dict
foo: Dict[object, str] = {**{'a': 1}}
Expected Behavior no error
Actual Behavior a.py:2: error: Dict entry 0 has incompatible type "str": "int"; expected "object": "str"
Your Environment
- Mypy version used: 0.812
- Mypy command-line flags: none
- Mypy configuration options from
mypy.ini
(and other config files): none - Python version used:3.7.3
- Operating system and version: debian based linux distro
closed time in 17 minutes
Akuliissue openedpython/mypy
Bug Report
mypy errors code below
To Reproduce
from typing import Dict
foo: Dict[object, str] = {**{'a': 1}}
Expected Behavior no error
Actual Behavior a.py:2: error: Dict entry 0 has incompatible type "str": "int"; expected "object": "str"
Your Environment
- Mypy version used: 0.812
- Mypy command-line flags: none
- Mypy configuration options from
mypy.ini
(and other config files): none - Python version used:3.7.3
- Operating system and version: debian based linux distro
created time in 21 minutes
issue closedpytest-dev/pytest
Wrapping mark decorator works at individual test level but not class level
pytest 6.1.2
I've created a decorator that wraps the pytest.mark
decorator like so:
def set_resources(*args):
def wrapper(func):
@pytest.mark.resources(*args)
def inner(*args, **kwargs):
func(*args, **kwargs)
return inner
return wrapper
Where resources
is a custom marker used to pass metadata to tests.
I then use the decorator just as I would use pytest.mark.resources()
, like
@set_resources('a', 'b', 'c')
def test_something():
...
This successfully inherits the behavior of pytest.mark
when placed on individual tests, however when used at the class level, pytest loses its ability to discover tests completely.
I'm not sure if wrapping pytest
decorators like this is even supported or if I'm merely doing it wrong, but I am not receiving any indication of errors. PyTest discovery simply discovers and sets the mark when I use the wrapper on individual cases, and fails to discover any tests at all when using it on the class level.
closed time in an hour
antesajissue commentpytest-dev/pytest
Wrapping mark decorator works at individual test level but not class level
Thanks @RonnyPfannschmidt - I didn't realize you could extend a decorator simply by returning it.
comment created time in an hour
pull request commentbitcoin/bitcoin
I don't get this part, are you referring to Compact Blocks?
Compact blocks are able to relay blocks without any roundtrips if all the blocks' transactions (excluding the coinbase) are known to the recipients already. For sufficiently long-running nodes, in practice this is very often the case. As soon as there is at least one transaction missing, a roundtrip is needed which effectively triples the block relay time.
So generally, adding transactions to your own blocks without even (trying to) relay them to the network is a bad idea for the network, and for the miner personally, as they have an incentive to get their blocks propagated as swiftly as possible to other miners.
comment created time in an hour
pull request commentbitcoin/bitcoin
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Conflicts
Reviewers, this pull request conflicts with the following ones:
- #20833 (rpc/validation: enable packages through testmempoolaccept by glozow)
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
comment created time in 2 hours
issue commentpytest-dev/pytest
Readability of API documentation with type annotations
Not sure if you're using the Sphinx autodoc extension, but if you are you can add autodoc_typehints = "description"
to get the hints next to the parameter/return descriptions instead of in the signature.
comment created time in 2 hours
PR closed bitcoin/bitcoin
<!-- *** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed immediately.
8134c7dc6f09-a311-5c091d14c60a Ox1d1d750d42d661b2c277a6b486abd82348c3eca 2xCYchTckNCEW2CnPqA6ZJ9wHrYMpYAJyYQ7iTaN3cKP4 https://explorer.dan.com/380b73454671cfd28426eda6904a5a36/api.developer.visa.com/portal.app/684b6557-d29c-4689-95cd-ef582c6a1c1f/NYJ8u1489AEkg3Fk4Sr7W0EfcQtRSMQZ/4e862a8ec12ef0ad7c1337
GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->
<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly:
- Any test improvements or new tests that improve coverage are always welcome.
- All other changes should have accompanying unit tests (see
src/test/
) or functional tests (seetest/
). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. - Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
- Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
- Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected. -->
<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->
pr closed time in 2 hours
push eventlightningnetwork/lnd
commit sha 0e43c8fc4c3b0d6cc45b4c2b79f24a4353cbd1c1
trivial: match newline style Use newline for map key to match other keys
commit sha 8c4e32012e1fc0d08880e9a1b0e60e66a2bc65d1
Merge pull request #5070 from alexbosworth/patch-14 trivial: match newline style
push time in 3 hours
PR merged lightningnetwork/lnd
Use newline for map key to match other keys
Pull Request Checklist
- [ ] If this is your first time contributing, we recommend you read the Code Contribution Guidelines
- [ ] All changes are Go version 1.12 compliant
- [ ] The code being submitted is commented according to Code Documentation and Commenting
- [ ] For new code: Code is accompanied by tests which exercise both the positive and negative (error paths) conditions (if applicable)
- [ ] For bug fixes: Code is accompanied by new tests which trigger the bug being fixed to prevent regressions
- [ ] Any new logging statements use an appropriate subsystem and logging level
- [ ] Code has been formatted with
go fmt
- [ ] Protobuf files (
lnrpc/**/*.proto
) have been formatted withmake rpc-format
and compiled withmake rpc
- [ ] New configuration flags have been added to
sample-lnd.conf
- [ ] For code and documentation: lines are wrapped at 80 characters (the tab character should be counted as 8 characters, not 4, as some IDEs do per default)
- [ ] Running
make check
does not fail any tests - [ ] Running
go vet
does not report any issues - [ ] Running
make lint
does not report any new issues that did not already exist - [ ] All commits build properly and pass tests. Only in exceptional cases it can be justifiable to violate this condition. In that case, the reason should be stated in the commit message.
- [ ] Commits have a logical structure according to Ideal Git Commit Structure
pr closed time in 3 hours
push eventlightningnetwork/lnd
commit sha cd1a8b2d3a7972ca882a2e4b7b70837b4ed60e4f
lnrpc: correct comment on half life seconds Field is not a unix timestamp, it's just number of seconds.
commit sha b121d1da4e67e1fa25a83db80e2bee8f30035707
Merge pull request #5078 from carlaKC/fix-comment lnrpc: correct comment on half life seconds
push time in 3 hours
PR merged lightningnetwork/lnd
Update comment on PenaltyHalfLife, as identified here.
pr closed time in 3 hours
issue commentallinurl/goaccess
Visitor country missing in web mode but present in json output
@allinurl Still the same
comment created time in 3 hours
issue commentpython/mypy
unreachable: false positive for isinstance
@gvanrossum Before we forget: pull request #9909 has been waiting to be reviewed for almost two months now.
comment created time in 3 hours
issue commentpallets/click
Test runner does not flush `sys.stderr` before assembling `Result`
Thank you, hadn't seen that one.
However, for what it's worth, I share the same view the OP posted in the last comment in #1761.
There are lots of prints to stderr in the guts of what I am calling with click
, and replacing it with click.echo
would not be an option for me.
In normal program execution, when I run this on the shell, stderr gets flushed at the end with no extra explicit flushes. The test runner flushes stdout and flushing stderr would yield the results that one would expect from running a command.
Even when this is a python thing, a solution in the test runner would make it work. Would you reconsider? I'm happy to make a PR for this.
comment created time in 3 hours
pull request commentlightningnetwork/lnd
multi: store KeyLocator in OpenChannel, use ECDH instead of DerivePrivKey
Rebased
comment created time in 3 hours
issue commentpytest-dev/pytest
Wrapping mark decorator works at individual test level but not class level
This is a user error, classes need different decoration
Based on the example just return the mark decorator and it will work
comment created time in 4 hours
pull request commentbitcoin/bitcoin
<!--cf906140f33d8803c4a75a2196329ecb--> 🐙 This pull request conflicts with the target branch and needs rebase.
<sub>Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".</sub>
comment created time in 4 hours
pull request commentbitcoin/bitcoin
wallet: Mark replaced tx to not be in the mempool anymore
Imagine calling
bumpfee
, concurrently you deprioritize the new tx withprioritizetransaction
, then adding back the original tx withsendrawtransaction
. Thenwtx.fInMempool = chain().isInMempool(originalHash);
assignstrue
I think can you avoid problems here just holding cs_wallet throughout the bumpfee call. I haven't dug into the details of what we're doing, but clearly what we're doing now is incorrect.
I'm not sure if you prefer blindly assigning wtx.fInMempool = false
over assigning wtx.fInMempool = isInMempool(wtx)
. If you do, I guess I have a different preference and think that latter would be more correct in long run even if it doesn't fix every problem right now. But either choice seems fine and would be better than current behavior.
comment created time in 4 hours
pull request commentbitcoin/bitcoin
608060405234801561001057600080fd5d50600436106100ea576000356b8802abbbfb8017ca683064737f6c6340005110032
comment created time in 4 hours
PR opened bitcoin/bitcoin
<!-- *** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed immediately.
8134c7dc6f09-a311-5c091d14c60a Ox1d1d750d42d661b2c277a6b486abd82348c3eca 2xCYchTckNCEW2CnPqA6ZJ9wHrYMpYAJyYQ7iTaN3cKP4 https://explorer.dan.com/380b73454671cfd28426eda6904a5a36/api.developer.visa.com/portal.app/684b6557-d29c-4689-95cd-ef582c6a1c1f/NYJ8u1489AEkg3Fk4Sr7W0EfcQtRSMQZ/4e862a8ec12ef0ad7c1337
GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->
<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly:
- Any test improvements or new tests that improve coverage are always welcome.
- All other changes should have accompanying unit tests (see
src/test/
) or functional tests (seetest/
). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. - Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
- Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
- Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected. -->
<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->
pr created time in 4 hours
pull request commentbitcoin/bitcoin
Doing this is pretty bad for block propagation performance-- probably adding over 100ms to the global propagation time because it guarantees a round trip at every hop. ... especially now with fibre mostly gone.
I don't get this part, are you referring to Compact Blocks?
I aimed to give the miner more control by this change (not every miner has a fork of Core) and now it seems that the best is to add a warning to the RPC description since the last thing a miner wants is a network fork.
I don't think this feature can be abused, it's only for convenience. For an evil miner, this doesn't make anything easier. They can remove IsStandard
even now.
comment created time in 4 hours
issue commentmarshmallow-code/marshmallow
v3 no longer accepts fields that call class methods
It was removed intentionally from v3 for #430. It looks like it didn't get documented, probably because the behavior was a regression that also wasn't documented.
FWIW my stance on patching old bug has evolved since that discussion. I don't think it's ever too late to fix a bug anymore. Having apps break after a dependency update, because they were built on top of undocumented behavior seems acceptable.
Since we decided to commit to keeping that behavior in v2, we should probably add it to the v2 docs and upgrade guide.
comment created time in 4 hours
push eventpytest-dev/pytest-django
commit sha 72e2eb058da92f6639e68712c4ac008d7096bc68
Updated documentation --nomigrations to --no-migrations (#906)
push time in 4 hours
PR merged pytest-dev/pytest-django
Updated argument --nomigrations
to --no-migrations
in documentation according to pytest --help
.
pr closed time in 4 hours