profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/achiku/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

achiku/dgw 161

dgw generates Golang struct, and simple Table/Row Data Gateway functions from PostgreSQL table metadata

achiku/go-http-api-server 9

Go 1.7+ HTTP API server sample

achiku/ansible-playbook-lnd 7

Ansible role to install and manage lnd configuration

achiku/cnps 2

See who's coming to your event

achiku/achiku.github.io 0

akirachiku.com

achiku/akirachiku.com 0

https://akirachiku.com using Hugo

achiku/aldjemy 0

Integration SQLAlchemy in Django projects for effective query building purposes

achiku/ansible-go 0

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.

achiku/ansible-golang 0

Ansible Go language role

achiku/ansible-openswan 0

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.

luke-jr

comment created time in 5 minutes

pull request commentlightningnetwork/lnd

build: switch all builds systems and CI/ID to go 1.16, update min go version, add support for compiling M1 binaries

Added a new commit that retracts version v0.0.2: https://github.com/lightningnetwork/lnd/pull/5034/commits/ee8f1a811e7acf23f930e57ebc787b548976764f

Roasbeef

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

symonk

issue openedpython/mypy

subtype dict unpack

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

subtype dict unpack

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

Akuli

issue commentpython/mypy

subtype dict unpack

code has bug, mypy has not

Akuli

comment created time in 17 minutes

issue openedpython/mypy

subtype dict unpack

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

antesaj

issue 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.

antesaj

comment created time in an hour

pull request commentbitcoin/bitcoin

RPC: minetxlocally

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.

DesWurstes

comment created time in an hour

pull request commentbitcoin/bitcoin

RPC: minetxlocally

<!--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.

DesWurstes

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.

nicoddemus

comment created time in 2 hours

PR closed bitcoin/bitcoin

0.21 Needs rebase

<!-- *** 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 (see test/). 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. -->

+8164 -2344

2 comments

100 changed files

Fisherman917

pr closed time in 2 hours

push eventlightningnetwork/lnd

Alex Bosworth

commit sha 0e43c8fc4c3b0d6cc45b4c2b79f24a4353cbd1c1

trivial: match newline style Use newline for map key to match other keys

view details

Conner Fromknecht

commit sha 8c4e32012e1fc0d08880e9a1b0e60e66a2bc65d1

Merge pull request #5070 from alexbosworth/patch-14 trivial: match newline style

view details

push time in 3 hours

PR merged lightningnetwork/lnd

trivial: match newline style

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 with make rpc-format and compiled with make 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
+2 -1

0 comment

1 changed file

alexbosworth

pr closed time in 3 hours

push eventlightningnetwork/lnd

carla

commit sha cd1a8b2d3a7972ca882a2e4b7b70837b4ed60e4f

lnrpc: correct comment on half life seconds Field is not a unix timestamp, it's just number of seconds.

view details

Conner Fromknecht

commit sha b121d1da4e67e1fa25a83db80e2bee8f30035707

Merge pull request #5078 from carlaKC/fix-comment lnrpc: correct comment on half life seconds

view details

push time in 3 hours

PR merged lightningnetwork/lnd

lnrpc: correct comment on half life seconds

Update comment on PenaltyHalfLife, as identified here.

+9 -9

0 comment

3 changed files

carlaKC

pr closed time in 3 hours

issue commentallinurl/goaccess

Visitor country missing in web mode but present in json output

@allinurl Still the same 2021-03-05_23-07

Dr-Escher

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.

tyralla

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.

jdevera

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

antesaj

comment created time in 4 hours

pull request commentbitcoin/bitcoin

0.21

<!--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>

Fisherman917

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 with prioritizetransaction, then adding back the original tx with sendrawtransaction. Then wtx.fInMempool = chain().isInMempool(originalHash); assigns true

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.

MarcoFalke

comment created time in 4 hours

pull request commentbitcoin/bitcoin

0.21

608060405234801561001057600080fd5d50600436106100ea576000356b8802abbbfb8017ca683064737f6c6340005110032

Fisherman917

comment created time in 4 hours

PR opened bitcoin/bitcoin

0.21

<!-- *** 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 (see test/). 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. -->

+8164 -2344

0 comment

100 changed files

pr created time in 4 hours

pull request commentbitcoin/bitcoin

RPC: minetxlocally

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.

DesWurstes

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.

acelletti

comment created time in 4 hours

push eventpytest-dev/pytest-django

Paul Angerer

commit sha 72e2eb058da92f6639e68712c4ac008d7096bc68

Updated documentation --nomigrations to --no-migrations (#906)

view details

push time in 4 hours

PR merged pytest-dev/pytest-django

Updated documentation --nomigrations to --no-migrations

Updated argument --nomigrations to --no-migrations in documentation according to pytest --help.

+5 -5

1 comment

1 changed file

etimoz

pr closed time in 4 hours