pipenv lock --pre won't change

installed packages from requirements
pipenv run pip install -r requirements.txt
it works correctly
so pipenv graph returns same as pipenv run pip freeze
but I can not create lock file, nor pipenv lock, or pipenv lock --pre either
pipenv graph output:
eth-account==0.1.0a2
  - attrdict [required: <3,>=2.0.0, installed: 2.0.0]
    - six [required: Any, installed: 1.11.0]
  - eth-keyfile [required: >=0.5.0,<0.6.0, installed: 0.5.1]
    - cytoolz [required: <1.0.0,>=0.9.0, installed: <IP_ADDRESS>]
      - toolz [required: >=0.8.0, installed: 0.9.0]
    - eth-keys [required: <1.0.0,>=0.1.0-beta.4, installed: 0.1.0b4]
      - cytoolz [required: <1.0.0,>=0.9.0, installed: <IP_ADDRESS>]
        - toolz [required: >=0.8.0, installed: 0.9.0]
      - eth-utils [required: >=0.5.0<1.0.0, installed: 0.8.1]
        - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
          - toolz [required: >=0.8.0, installed: 0.9.0]
        - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
    - eth-utils [required: >=1.0.0-beta.1,<2.0.0, installed: 0.8.1]
      - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
        - toolz [required: >=0.8.0, installed: 0.9.0]
      - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
    - pycryptodome [required: >=3.4.7,<4.0.0, installed: 3.6.1]
  - eth-keys [required: <0.3.0,>=0.2.0b1, installed: 0.1.0b4]
    - cytoolz [required: <1.0.0,>=0.9.0, installed: <IP_ADDRESS>]
      - toolz [required: >=0.8.0, installed: 0.9.0]
    - eth-utils [required: >=0.5.0<1.0.0, installed: 0.8.1]
      - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
        - toolz [required: >=0.8.0, installed: 0.9.0]
      - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
  - eth-rlp [required: <1,>=0.1.0a2, installed: 0.1.0]
    - eth-utils [required: >=1.0.1,<2, installed: 0.8.1]
      - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
        - toolz [required: >=0.8.0, installed: 0.9.0]
      - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
    - hexbytes [required: <1,>=0.1.0, installed: 0.1.0]
      - eth-utils [required: >=1.0.1,<2.0.0, installed: 0.8.1]
        - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
          - toolz [required: >=0.8.0, installed: 0.9.0]
        - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
    - rlp [required: <1,>=0.6.0, installed: 0.6.0]
  - eth-utils [required: >=1.0.0b1,<2, installed: 0.8.1]
    - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
      - toolz [required: >=0.8.0, installed: 0.9.0]
    - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
  - hexbytes [required: <1,>=0.1.0b0, installed: 0.1.0]
    - eth-utils [required: >=1.0.1,<2.0.0, installed: 0.8.1]
      - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
        - toolz [required: >=0.8.0, installed: 0.9.0]
      - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
eth-hash==0.1.2
numpy==1.14.2
pkg-resources==0.0.0
pymongo==3.6.1
python-bitcoinrpc==1.0
typed-ast==1.1.0
web3==3.16.5
  - cytoolz [required: >=0.8.2, installed: <IP_ADDRESS>]
    - toolz [required: >=0.8.0, installed: 0.9.0]
  - eth-abi [required: >=0.5.0,<0.6.0, installed: 0.5.0]
    - eth-utils [required: ==0.7.*, installed: 0.8.1]
      - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
        - toolz [required: >=0.8.0, installed: 0.9.0]
      - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
  - eth-tester [required: ==0.1.0b11, installed: 0.1.0b11]
    - cytoolz [required: <1.0.0,>=0.9.0, installed: <IP_ADDRESS>]
      - toolz [required: >=0.8.0, installed: 0.9.0]
    - eth-keys [required: >=0.1.0b3,<0.2.0, installed: 0.1.0b4]
      - cytoolz [required: <1.0.0,>=0.9.0, installed: <IP_ADDRESS>]
        - toolz [required: >=0.8.0, installed: 0.9.0]
      - eth-utils [required: >=0.5.0<1.0.0, installed: 0.8.1]
        - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
          - toolz [required: >=0.8.0, installed: 0.9.0]
        - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
    - eth-utils [required: <1.0.0,>=0.7.1, installed: 0.8.1]
      - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
        - toolz [required: >=0.8.0, installed: 0.9.0]
      - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
    - rlp [required: <1.0.0,>=0.6.0, installed: 0.6.0]
    - semantic-version [required: <3.0.0,>=2.6.0, installed: 2.6.0]
  - eth-utils [required: <1.0.0,>=0.7.1, installed: 0.8.1]
    - cytoolz [required: <1.0.0,>=0.8.2, installed: <IP_ADDRESS>]
      - toolz [required: >=0.8.0, installed: 0.9.0]
    - pysha3 [required: >=1.0.0,<2.0.0, installed: 1.0.2]
  - lru-dict [required: >=1.1.6, installed: 1.1.6]
  - pysha3 [required: >=0.3, installed: 1.0.2]
  - requests [required: >=2.12.4, installed: 2.18.4]
    - certifi [required: >=2017.4.17, installed: 2018.4.16]
    - chardet [required: >=3.0.2,<3.1.0, installed: 3.0.4]
    - idna [required: <2.7,>=2.5, installed: 2.6]
    - urllib3 [required: <1.23,>=1.21.1, installed: 1.22]
  - rlp [required: >=0.4.7, installed: 0.6.0]
  - toolz [required: >=0.8.2, installed: 0.9.0]
websockets==4.0.1

notice rlp == 0.6.0 and eth-utils==0.8.1
but PIpfile.lock:
{
    "_meta": {
        "hash": {
            "sha256": "3318a8c9cf795facae71cacba9dc932aa533c651b052985dac495707865076b7"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.5"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.python.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "attrdict": {
            "hashes": [
                "sha256:86aeb6d3809e0344409f8148d7cac9eabce5f0b577c160b5e90d10df3f8d2ad3"
            ],
            "version": "==2.0.0"
        },
        "certifi": {
            "hashes": [
                "sha256:13e698f54293db9f89122b0581843a782ad0934a4fe0172d2a980ba77fc61bb7",
                "sha256:9fa520c1bacfb634fa7af20a76bcbd3d5fb390481724c597da32c719a7dca4b0"
            ],
            "version": "==2018.4.16"
        },
        "chardet": {
            "hashes": [
                "sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae",
                "sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691"
            ],
            "version": "==3.0.4"
        },
        "cytoolz": {
            "hashes": [
                "sha256:84cc06fa40aa310f2df79dd440fc5f84c3e20f01f9f7783fc9c38d0a11ba00e5"
            ],
            "version": "==<IP_ADDRESS>"
        },
        "eth-abi": {
            "hashes": [
                "sha256:717f33b654fdaed61c3276d26bfa6ca2006ce3254c98d6c8ed0ac645acd5b34b",
                "sha256:a0a9bd9c6985f7d696c195911f097ec70adc2199553f61ac6236c7066eea5ba9"
            ],
            "version": "==1.1.1"
        },
        "eth-account": {
            "hashes": [
                "sha256:23262f2e618fee16c80ba295d10f13e480d8908774a2eaa8a2957ee96dec38ed",
                "sha256:42c405c1caa77f9aa5daf0a5cc9e89e7215ee39625a0dc18b7bdf7774bedf87d"
            ],
            "version": "==0.2.2"
        },
        "eth-hash": {
            "hashes": [
                "sha256:43adcab75a957fcf8c453d5542be55e4e0bd4e166270f45b09ac69b4d6486a06",
                "sha256:8695f5f3794497d1357b2ef6e84c67a7daf4bfec1dde9f76ff6b2022c2cc03a6"
            ],
            "version": "==0.1.2"
        },
        "eth-keyfile": {
            "hashes": [
                "sha256:70d734af17efdf929a90bb95375f43522be4ed80c3b9e0a8bca575fb11cd1159",
                "sha256:939540efb503380bc30d926833e6a12b22c6750de80feef3720d79e5a79de47d"
            ],
            "version": "==0.5.1"
        },
        "eth-keys": {
            "hashes": [
                "sha256:5ab2612f457452dc0a318655051cdd05c20f4db2f445003a46c98d324101b0e4",
                "sha256:b48fc92a527bd905525855ebe45e79ba17be6654c4bedb947119648c145c74c0"
            ],
            "version": "==0.2.0b3"
        },
        "eth-rlp": {
            "hashes": [
                "sha256:05d8456981d85e16a9afa57f2f2c3356af5d1c49499cc8512cfcdc034b90dde5",
                "sha256:a94744c207ea731a7266bd0894179dc6e51a6a8965316000c8e823b5d7e07694"
            ],
            "version": "==0.1.2"
        },
        "eth-utils": {
            "hashes": [
                "sha256:0eb71bdafda7e7e4c80ba98c06b3f89472e8ba0183a149be678f13cbb3b2e9b4",
                "sha256:add4cc71b64e40b15c1e7b037905daf59da58e046004bde7a2915f86a7fc8e57"
            ],
            "version": "==1.0.3"
        },
        "hexbytes": {
            "hashes": [
                "sha256:27cc227ae95fc20d44325ac0329a0293d656a05230da079650705030c7d7a819",
                "sha256:67e5608cb4a14d0a4ced058e595bb1f70c207ef2b5219fdc82af10e54bcf38de"
            ],
            "version": "==0.1.0"
        },
        "idna": {
            "hashes": [
                "sha256:2c6a5de3089009e3da7c5dde64a141dbc8551d5b7f6cf4ed7c2568d0cc520a8f",
                "sha256:8c7309c718f94b3a625cb648ace320157ad16ff131ae0af362c9f21b80ef6ec4"
            ],
            "version": "==2.6"
        },
        "lru-dict": {
            "hashes": [
                "sha256:365457660e3d05b76f1aba3e0f7fedbfcd6528e97c5115a351ddd0db488354cc"
            ],
            "version": "==1.1.6"
        },
        "mypy": {
            "hashes": [
                "sha256:01cf289838f266ae7c6550c813181ee77d21eac9459dbf067e7a95a0a2db9721",
                "sha256:bc251cb31bc236d9fe4bcc442c994c45fff2541f7161ee52dc949741fe9ca3dd"
            ],
            "index": "pypi",
            "version": "==0.600"
        },
        "parsimonious": {
            "hashes": [
                "sha256:ae0869d72a6e57703f24313a5f5748e73ebff836e6fe8b3ddf34ea0dc00d086b"
            ],
            "version": "==0.8.0"
        },
        "pycryptodome": {
            "hashes": [
                "sha256:043c82cd3dd3120286a1b325ace93000cf52abb13a067c3ecb6220f874fe4c30",
                "sha256:0cdd73492859d853f60b8185715312dbca465879661e28d354d1cf5ea11860e7",
                "sha256:15013007e393d0cc0e69f4329a47c4c8597b7f3d02c12c03f805405542f70c71",
                "sha256:19d81b92bff837cdade735b9023808556bb4868e1ce194dad4d5ec4e2b2851f3",
                "sha256:1ceb3e87605c4f0080115a8a00abf45f5df27b0166a37fd669fbff4523273cfc",
                "sha256:2354a77051ed4a2959ce2aac508071eb3e42fc348ea39228b2eac335990bf508",
                "sha256:27bd2878200690b050dca34f505b5c623532324b3de40267c1484784063134df",
                "sha256:322f239e51fda80233762400a8975ab728639b571fa58545b95b9c44042af010",
                "sha256:49a71eb990af30ff6276cfe201eb83ed3640ae989c1b5973f7b55a46c94232d1",
                "sha256:4b5a2680008da3ac0cef2d3661597e0cbf8a3eb19eed35b859fd67e2de63eb85",
                "sha256:6d34fe5134eb5d62368e21e6f203ac1770bc7273e9536c4a280121312c2de53a",
                "sha256:733d5eb7e5ceed8b9d0b3c24c81f52c04cb5de6786461388204fceefe4456aa5",
                "sha256:7c73d3798fe2946953768b788ce554c0d4b390780f5e73d63bd833241af27bfe",
                "sha256:97af76f5200f15e97cac58d77f319dec40b4bada98de697c91a9517e63b41d1a",
                "sha256:97cc46ff02b99dafdc2e0385b325cec0f8a15bf8b285d6ed1d7e4a3bc2067ce1",
                "sha256:a561b59e0c3548eb649af381b7c38c6fd8392bbd4d0a8214794b2b761f405af4",
                "sha256:ab2c633bfc23cf41be9281228517cb6f87879f4f1aeb154ed72bd53ab7cc83e9",
                "sha256:adb54316998337f315520bbd8ef4d8bbd940b4ddfaef8ba1db3c137c5e499399",
                "sha256:b4a3b710287eb1fc3e2cc1af018063f003530dff00c9ea4c55ae19bc1f3923cc",
                "sha256:bcfdb66d6604882c3f96eea922552c2487cc0aec4b883cd217b9d341d2f8fad0",
                "sha256:c08c053eb8716bbbd5e13e38f453b9e46a063e68df8659f3c421dcb7519fd381",
                "sha256:e51da4ef9d9e2695a04044152f380c2db17adc9fc6fad8e24d863ead9cd548ed",
                "sha256:e850e07f54dc3de9a1efdd59d227fcd1cb30cdd307dafdc647c79e8f30cf5032",
                "sha256:ebc579c41fe26748dc1bad4f9105f08740ee28826293a28103b3875968695a5e",
                "sha256:ed94cb1b4bf24be734f2bf2db3e8ea75f3914d2f8e684291bee54bbe4a5a9151",
                "sha256:f5e19802295e63bdf83bb92849285c01f7167840efb1c1e08507a50b10ba7efa",
                "sha256:fc569682f012b1f62f8d28d8f9bc71f1de67648cd1bc124ef8ccf8db4edfc28a"
            ],
            "version": "==3.6.1"
        },
        "pymongo": {
            "hashes": [
                "sha256:051770590ddbd5fb7db17d3315d4c1b0f18039d830dd18e1bae39451c30d31cd",
                "sha256:061085dfe4fbf1d9d6ed2f2e52fe6ab72559e48b4294370b433751638160d10b",
                "sha256:07fdee1c5567f237796a8550233e04853785d8dcf95929f96ab519ed91543109",
                "sha256:0d98731aaea8cb32b535c376f6785927e4e3d9459ffe1440b8a639827a849350",
                "sha256:10f683950f70626ccedf4a662d1c0b3244e8e013c2067872af5633830abd1bfd",
                "sha256:192ee5e33821931f4ec6df5fff4361220c0c92bb5b7437c6db52e20a0c9b4d98",
                "sha256:2954b99cfeb76776879e9f8a4cae9c5e19d5eff92d0b7b663ceddcf192adb66b",
                "sha256:36a992e02fced328de5304145dc3729a8cea12e58ad34b842a6f46d7941c9fc7",
                "sha256:419ed5d5b76ef304815f354d9df7f2085acfd6ff7cc1b714ca702e2239b341c2",
                "sha256:42ec201fd9a26e7c1e611e3db19324dead51dd4646391492eb238b41749340e8",
                "sha256:4400fa92af310bf66b76c313c7ded3bb63f3d63b4f43c3bfbff552cf294dc9fa",
                "sha256:44abdc26989600bb03b62d57616ec7c1b9182290720167c39e38c3a2b0d44e44",
                "sha256:45fb9f589c0f35436dbe391c53a387ffffa8d086b8521a86fca4f3e1d0edbf71",
                "sha256:4807dfbb5cdcfe0224329992dc48b897c780d0ad7553c3799d34f84ba5cab446",
                "sha256:54daf67e1e7e7e5a5160c86123bdd39b1d3b25876c2ab38230dc2a764cb3d98f",
                "sha256:5f2814a9492a724fd77c90ffc01f810276ef9972ae02587bfaae40835f9b8407",
                "sha256:5fd6ce5ed3c6c92d2c94756e6bf041304e5c7c5a5dbea31b8957d52a78bdf01d",
                "sha256:601e00fe7fb283f04c95f5dafb787c0862f48ca015a6f1f81b460c74e4303873",
                "sha256:63a47a97b5cb4c67c86552b15e08df12ff026a648211120adf5ebe00453e85e9",
                "sha256:6c4459d5c2b45ba55e14360e03078426015c1b0881facaec51bd9bd9e2304cec",
                "sha256:7fbd9233e8b6741b047c5857e2ad5efb74091f167d7fa8a2a3379217165058f9",
                "sha256:7ffac35362c07c103b024b89875e8d7f0625129b65c56fa8a3ecebbd56110405",
                "sha256:833bc6cb2ec7058dea9f5840a9314ac74738d2117486a044e88f3976e37ea7a0",
                "sha256:92cb26a2a9b38e8df5215803f950b20a6c847d5e00d1dd125eaa84f05f9472d7",
                "sha256:97d6a218c4ad4f8fdde0143776d5224e884cbcfe631e7446379fa1790d8cf04f",
                "sha256:9e5f0e8967d95a256038817460844a8aab588b9bc9ba6296507a1863960a0e44",
                "sha256:9e6db7ff63fb836d56e62216e10e868c23a99f3cb02875411eb2cb787acf58c7",
                "sha256:a0a695eef38c15570f6da3b4900e1a1d85fa92c754177d5f05267b49da79c92b",
                "sha256:aa46076524471729430afacca3dd8ad4578878eca6fc9e2b593a0b381b5bbeb7",
                "sha256:abf83b908e535b1386a7732825994e6e36eff6394c1829f3e7a23888136484fa",
                "sha256:adb2dba52c8a2a2d7bcd3b267f7bbf7c822850cf6a7cd15211b9f386c3a670ef",
                "sha256:ae7b3479822a03f6f651913de84ba67101f23e051ae88034085e974f472dcfff",
                "sha256:c596af57286ef28cae7a48e3070d222f96f5f0eab76ad39d680ae6b9bbc957c7",
                "sha256:cc15b30f0ac518e6cbd4b6e6e6162f8aa14edfe255d0841146f146151bd58865",
                "sha256:d23498d62063b715078947bef48fa4d34dc354f3b268ed15dc6b46fc809a88e9",
                "sha256:dd29bb5bc9068ccc248c8c145efd839421f04363b468b47cfa2d4902ca369afe",
                "sha256:e2745dd408a26d4517702d1686afc8e1e1638d2167e857c684f912192cc00dcf",
                "sha256:e53ad0cc6c489f83e7f6bb6121aa73bb6f6488410024a3bd77c16af1aa3a1000",
                "sha256:ecb11113407d919f8714cc7d0841985044633d0b561ef3d797e1b494a3e73537",
                "sha256:ece2c2add66d3ec2720a963bf073ca11fc3b0b58159767fc3bc5ddaad791d481",
                "sha256:ef25c8675f5c8c19832f69cd97d728d99bb4ab9c3b200e28a5c8416631afaf3c",
                "sha256:f62a818d643776873713c5676f17bd95ac4176220b13dd12c14edd3a450d1ac9",
                "sha256:f7ebcb846962ee40374db2d9014a89bea9c983ae63c1877957c3a0a756974796"
            ],
            "index": "pypi",
            "version": "==3.6.1"
        },
        "python-bitcoinrpc": {
            "hashes": [
                "sha256:a6a6f35672635163bc491c25fe29520bdd063dedbeda3b37bf5be97aa038c6e7"
            ],
            "index": "pypi",
            "version": "==1.0"
        },
        "requests": {
            "hashes": [
                "sha256:6a1b267aa90cac58ac3a765d067950e7dbbf75b1da07e895d1f594193a40a38b",
                "sha256:9c443e7324ba5b85070c4a818ade28bfabedf16ea10206da1132edaa6dda237e"
            ],
            "version": "==2.18.4"
        },
        "rlp": {
            "hashes": [
                "sha256:492c11b18e89af42f98e96bca7671ffee4ad4cf5e69ea23b4d2221157d81b512",
                "sha256:dc6c5887f354508892b70f2897ca3d135411d669e0103092e689c224ef8de8e9"
            ],
            "version": "==1.0.1"
        },
        "six": {
            "hashes": [
                "sha256:70e8a77beed4562e7f14fe23a786b54f6296e34344c23bc42f07b15018ff98e9",
                "sha256:832dc0e10feb1aa2c68dcc57dbb658f1c7e65b9b61af69048abc87a2db00a0eb"
            ],
            "version": "==1.11.0"
        },
        "toolz": {
            "hashes": [
                "sha256:929f0a7ea7f61c178bd951bdae93920515d3fbdbafc8e6caf82d752b9b3b31c9"
            ],
            "version": "==0.9.0"
        },
        "typed-ast": {
            "hashes": [
                "sha256:0948004fa228ae071054f5208840a1e88747a357ec1101c17217bfe99b299d58",
                "sha256:25d8feefe27eb0303b73545416b13d108c6067b846b543738a25ff304824ed9a",
                "sha256:29464a177d56e4e055b5f7b629935af7f49c196be47528cc94e0a7bf83fbc2b9",
                "sha256:2e214b72168ea0275efd6c884b114ab42e316de3ffa125b267e732ed2abda892",
                "sha256:3e0d5e48e3a23e9a4d1a9f698e32a542a4a288c871d33ed8df1b092a40f3a0f9",
                "sha256:519425deca5c2b2bdac49f77b2c5625781abbaf9a809d727d3a5596b30bb4ded",
                "sha256:57fe287f0cdd9ceaf69e7b71a2e94a24b5d268b35df251a88fef5cc241bf73aa",
                "sha256:668d0cec391d9aed1c6a388b0d5b97cd22e6073eaa5fbaa6d2946603b4871efe",
                "sha256:68ba70684990f59497680ff90d18e756a47bf4863c604098f10de9716b2c0bdd",
                "sha256:6de012d2b166fe7a4cdf505eee3aaa12192f7ba365beeefaca4ec10e31241a85",
                "sha256:79b91ebe5a28d349b6d0d323023350133e927b4de5b651a8aa2db69c761420c6",
                "sha256:8550177fa5d4c1f09b5e5f524411c44633c80ec69b24e0e98906dd761941ca46",
                "sha256:a8034021801bc0440f2e027c354b4eafd95891b573e12ff0418dec385c76785c",
                "sha256:bc978ac17468fe868ee589c795d06777f75496b1ed576d308002c8a5756fb9ea",
                "sha256:c05b41bc1deade9f90ddc5d988fe506208019ebba9f2578c622516fd201f5863",
                "sha256:c9b060bd1e5a26ab6e8267fd46fc9e02b54eb15fffb16d112d4c7b1c12987559",
                "sha256:edb04bdd45bfd76c8292c4d9654568efaedf76fe78eb246dde69bdb13b2dad87",
                "sha256:f19f2a4f547505fe9072e15f6f4ae714af51b5a681a97f187971f50c283193b6"
            ],
            "version": "==1.1.0"
        },
        "urllib3": {
            "hashes": [
                "sha256:06330f386d6e4b195fbfc736b297f58c5a892e4440e54d294d7004e3a9bbea1b",
                "sha256:cc44da8e1145637334317feebd728bd869a35285b93cbb4cca2577da7e62db4f"
            ],
            "version": "==1.22"
        },
        "web3": {
            "hashes": [
                "sha256:87edb8e9e2be222a51e24010d7604cb5ee8e926f4282136df6842be5cec9eec1",
                "sha256:d282cc6fc4a011e289aecb482ce0f27139013e0ea0258639f23c0d7b08362448"
            ],
            "index": "pypi",
            "version": "==4.2.1"
        },
        "websockets": {
            "hashes": [
                "sha256:0c31bc832d529dc7583d324eb6c836a4f362032a1902723c112cf57883488d8c",
                "sha256:1f3e5a52cab6daa3d432c7b0de0a14109be39d2bfaad033ee5de4a3d3e11dcdf",
                "sha256:341824d8c9ad53fc43cca3fa9407f294125fa258592f7676640396501448e57e",
                "sha256:367ff945bc0950ad9634591e2afe50bf2222bc4fad1088a386c4bb700888026e",
                "sha256:3859ca16c229ddb0fa21c5090e4efcb037c08ce69b0c1dfed6122c3f98cd0c22",
                "sha256:3d425ae081fb4ba1eef9ecf30472ffd79f8e868297ccc7a47993c96dbf2a819c",
                "sha256:64896a6b3368c959b8096b655e46f03dfa65b96745249f374bd6a35705cc3489",
                "sha256:6df87698022aef2596bffdfecc96d656db59c8d719708c8a471daa815ee61656",
                "sha256:80188abdadd23edaaea05ce761dc9a2e1df31a74a0533967f0dcd9560c85add0",
                "sha256:d1a0572b6edb22c9208e3e5381064e09d287d2a915f90233fef994ee7a14a935",
                "sha256:da4d4fbe059b0453e726d6d993760065d69b823a27efc3040402a6fcfe6a1ed9",
                "sha256:da7610a017f5343fdf765f4e0eb6fd0dfd08264ca1565212b110836d9367fc9c",
                "sha256:ebdd4f18fe7e3bea9bd3bf446b0f4117739478caa2c76e4f0fb72cc45b03cbd7",
                "sha256:f5192da704535a7cbf76d6e99c1ec4af7e8d1288252bf5a2385d414509ded0cf",
                "sha256:fd81af8cf3e69f9a97f3a6c0623a0527de0f922c2df725f00cd7646d478af632",
                "sha256:fecf51c13195c416c22422353b306dddb9c752e4b80b21e0fa1fccbe38246677"
            ],
            "version": "==4.0.1"
        }
    },
    "develop": {}
}

        "rlp": {
            "hashes": [
                "sha256:492c11b18e89af42f98e96bca7671ffee4ad4cf5e69ea23b4d2221157d81b512",
                "sha256:dc6c5887f354508892b70f2897ca3d135411d669e0103092e689c224ef8de8e9"
            ],
            "version": "==1.0.1"

        "eth-utils": {
            "hashes": [
                "sha256:0eb71bdafda7e7e4c80ba98c06b3f89472e8ba0183a149be678f13cbb3b2e9b4",
                "sha256:add4cc71b64e40b15c1e7b037905daf59da58e046004bde7a2915f86a7fc8e57"
            ],
            "version": "==1.0.3"

different versions.
How to make them consistent.
and Yes, I've searched for an issues, --pre key won't solve my problem.
Could you please be more verbose in your arguments, what exactly means 'Allow pre–releases.'.
Thanks

Sure thing! Pre-releases (I know this term doesn’t make sense) are just releases tagged with an ‘alpha’, ‘beta’, ‘dev’ or ‘rc’ tag so basically 1.0.3 is a normal release while 1.0.3rc1 is 1.0.3 release candidate 1 and is a pre-release.  That just means that someday 1.0.3 will be released and that this version is a precursor to that which isn’t finished.
We have had other issues specifically related to eth-utils, you may want to look those up and see how they were resolved.
Do you still think the —pre flag won’t help?

The output is indeed a bit strange:
[packages]
eth-account = "==0.1.0a2"
eth-hash = "==0.1.2"
numpy = "==1.14.2"
web3 = "==3.16.5"

$ pipenv lock --pre
Locking [dev-packages] dependencies…
Locking [packages] dependencies…

Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.
Could not find a version that matches eth-keys<0.2.0,<0.3.0,>=0.1.0b3,>=0.2.0b1
Skipped pre-versions: 0.1.0b1, 0.1.0b1, 0.1.0b2, 0.1.0b2, 0.1.0b3, 0.1.0b3, 0.1.0b4, 0.1.0b4, 0.2.0b1, 0.2.0b1, 0.2.0b2, 0.2.0b2, 0.2.0b3, 0.2.0b3
There are incompatible versions in the resolved dependencies.

Notice the log says it’s skipping pre-versions, even when I specified --pre. We might be dropping the flag somewhere…

I think do_install drops it in the do_init call

oh, I just got around to reading this.  Lets look at the error message: Could not find a version that matches eth-keys<0.2.0,<0.3.0,>=0.1.0b3,>=0.2.0b1.  We can filter this down a bit, because <0.2.0 is already less than 0.3.0 so we can just axe the 0.3.0 constraint, and similarly, 0.2.0b1 is greater than 0.1.0b3.  This leaves our available package space for eth-keys to match against as: >=0.2.0b1,<0.2.0.
The versions we skip aren't super useful, because if you look carefully they are usually duplicated a bunch.  We skip lots of stuff, this is one of the reasons I wasn't totally on board with showing the listing of skipped prerelease versions in the first place.  This is super misleading -- it implies that we skipped these versions because they were prerelease versions.  What actually happened is that we skipped these versions, and also, they happened to be prerelease versions.
I can tell you without looking at any code or doing any dependency resolution that there is no such version that will satisfy <0.2.0, >=0.2.0b1, so this is most likely not a bug.  It would actually be quite odd if we didn't respect the --pre argument because we use it ourselves all the time in our own pipfile.
Anyway I've fielded dozens of issues related to this set of ethereum tooling, the maintainers just seem to randomly pin stuff that conflicts across all of their software.  Pip doesn't have a dependency resolver, it will always install whatever you tell it to install.  That is one of the key distinguishing features of pipenv -- if you want to install 5 packages, and 3 of them try to install conflicting versions of requests, pipenv doesn't just let them go ahead and race to see who wins -- it will actually stop and tell you about the problem.   I'd recommend opening an issue against the packages you're trying to install and asking them to sort this out

there is no such version that will satisfy <0.2.0, >=0.2.0b1

I’m not sure how the logic works, but 0.2.0b1, 0.2.0b2, and 0.2.0b3 should all be considered matching this criteria. If they are not, this is a bug.

same issue. use pip install web3 success, but with pipenv install failed with:
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
 Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.
Could not find a version that matches eth-keys<0.3.0,>=0.2.0b3
Skipped pre-versions: 0.1.0b1, 0.1.0b1, 0.1.0b2, 0.1.0b2, 0.1.0b3, 0.1.0b3, 0.1.0b4, 0.1.0b4, 0.2.0b1, 0.2.0b1, 0.2.0b2, 0.2.0b2, 0.2.0b3, 0.2.0b3
There are incompatible versions in the resolved dependencies.


Support for parsing the Tokens out of the Azure CLI AccessTokens file

Both the Node.JS and Python Azure CLI's store the authentication tokens generated from az(ure) login in ~/.azure/accessTokens.json.
Attempting to load this file using adal.LoadToken() fails due to there being multiple Tokens within a single file with a different schema - as such I've added a new method to load the tokens out of the file generated by the Azure CLI.
I've tested this on macOS with multiple subscriptions associated with the Azure account and this seems to work, but I'm unaware of if the file contents is different for users with a single subscription on the account?

@tombuildsstuff,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@marstr thanks for taking a look - I've updated this to point at dev + made the changes requested :)

@marstr no worries, thanks for reviewing so quickly :)
off-topic: it might be because I've been contributing to TF for a while - but it'd be really handy to have a Makefile for all of the common commands (see: formatting, linting, building etc, here's ours for reference) - would you be interested if I sent a PR to add that? :)

That sounds great! Would it be a literal makefile or just a shortcut command?

@marstr @mcardosos I've put together #163 after some playing around, not sure if that's helpful :)

Awesome!
@tombuildsstuff Thanks for the contribution! :D


cmd/go: coverage profile should be cached with tests

As briefly discussed here: https://twitter.com/_rsc/status/956888213314068481
I don't see why Go shouldn't cache the results of -coverprofile when running tests, as test coverage shouldn't vary from run to run, given the same set of arguments.
What version of Go are you using (go version)?
go version go1.10rc1 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
$GOOS="darwin"
$GOARCH="amd64"

What did you do?
Call go test -coverprofile=coverprofile.out ./... multiple times.
What did you expect to see?
Test results cached between runs.
$ go test -coverprofile=coverprofile.out ./...
ok  	github.com/bbrks/tmp	2.893s	coverage: 46.1% of statements
$ go test -coverprofile=coverprofile.out ./...
ok  	github.com/bbrks/tmp	(cached)

What did you see instead?
Test results were not cached between runs.
$ go test -coverprofile=coverprofile.out ./...
ok  	github.com/bbrks/tmp	2.893s	coverage: 46.1% of statements
$ go test -coverprofile=coverprofile.out ./...
ok  	github.com/bbrks/tmp	2.893s	coverage: 46.1% of statements

I was hoping this change would make it into go1.11 but it seems its not working yet in go1.11beta3. Looking at the CL it seems it got stuck due to merge conflicts? Any chance we can pick up this issue and still include it in v11?

@fgrosse Looks like it's being targeted for 1.12 now. I don't think it will be rescheduled this close to 1.11's release.

Alright, thanks for the update on this issue.
Ben Brooks<EMAIL_ADDRESS>schrieb am Mo., 6. Aug. 2018, 13:34:

@fgrosse https://github.com/fgrosse Looks like it's being targeted for
1.12 now. I don't think it will be rescheduled this close to 1.11's release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/23565#issuecomment-410678519, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAsvTP9Zd6Qik3yRHeE5td0dAye-tjLeks5uOCnbgaJpZM4RuY2-
.

Any updates on this?

Any plans on this? We have a huge go monorepo and this prevents us from leveragin test cache in our tooling.

Is this something that could be still implemented or is the idea abandoned?

This is a feature I'd love to see make it into go one day. We run out unit tests against a large monorepo and would like to be able to generate a coverage report for every PR but it's not feasible to do for the entire repo if the test results aren't cached.

Would it be possible to review proposed CL?
In my case this feature would allow to save a lot of resources in CI.

Sadly, I think it's unlikely that the CL will be reviewed now that we're more than a month into the freeze period for 1.19.
When the 1.20 tree is open for development, I'll ping the reviewers again in hopes of moving the CL forward. I'll also propose it as a "early-in-cycle" change on the golang-dev mailing list once that thread is created, which will hopefully raise its priority. If a month passes after the 1.20 tree opens and there are still no reviews, I'll send a new message in the golang-dev mailing list requesting reviews. That seems to be the most effective way to prompt reviews, but it's also noisy so I hope it won't be necessary. If any of these steps sound inappropriate, please let me know. This is my first CL to the Go project and I haven't found clear documentation on what to do when a CL is left in limbo.
In the meantime, I know @vearutop has already tested the changes and seen positive results. If anyone else is willing to test or review the CL, I'm happy to address feedback. Community testing can help strengthen the CL, resulting in fewer iterations needed once members of the Go team have time to review.

Aside from reviews, one other potential blocker could be the WIP changes for #51430. When I read the original proposal, I thought the changes would be independent of this CL but I haven't kept up with the stack of changes in the proposed implementation to be certain. It's also possible I misunderstood the proposal. Either way, @thanm if you can find the time to take a look at CL 376134 and comment on whether it conflicts with your changes for #51430, I'd appreciate it. I understand if that informal review needs to be pushed until 1.20 opens.

@jproberts I looked over your CL and I don't see any significant conflicts with my work, LGTM. I'll leave a couple of minor comments on your CL.

What is the general approach in go in case of patches, where the original author doesn't respond anymore? is it ok if someone else picks them up?

@alvaroaleman I'm not sure the general approach but I've closed my PR. From my perspective, anyone is welcome to attempt to fix this issue.
I've resolved the long existing merge conflicts and pushed them to https://github.com/jproberts/go/commit/ace4a178499cf382b7efed63239818bac4bebc92 . I think that's a good starting point but the impression I've gotten from the reviewers is that they'd prefer to make the current test caching more robust before extending it to profiles. So while I hope my code can still be used, I think there's more work to do and I can't commit to taking that on. I've blocked this long enough. Sorry y'all.
The 1.22 tree is open for development for the next 5 months, so hopefully someone else can push this work through in that time.

Could we, at least, add a note that test cache doesn't work with -race and -coverprofile?
I had to find the hard way, after long time trying and thinking that it's me who's wrong.
Maybe here would be the proper place?
https://pkg.go.dev/cmd/go#hdr-Build_and_test_caching

I agree with the ChangeList comment—this enhancement does more than just save developer time; it also offers significant environmental benefits. I urge the Go development team to consider this matter with the gravity it deserves. While I understand that it may not be as appealing as a new feature or a runtime issue, and thus might not be prioritized as highly, it nonetheless warrants serious consideration.

@macnibblet you have some feedback on the CL. Not sure if you got notified.

@ryancurrah I have, but I have been swamped with work, but this is still high up on my to do list.

@macnibblet Brian, who is reviewing your CR is leaving Google. Maybe if we can get the CR comments addressed we can get it merged before he leaves. I have addressed his comments in my diff.
diff --git a/src/cmd/go/alldocs.go b/src/cmd/go/alldocs.go
index dde47ac1b8..f45a85256a 100644
--- a/src/cmd/go/alldocs.go
+++ b/src/cmd/go/alldocs.go
@@ -1803,8 +1803,9 @@
 //
 // The rule for a match in the cache is that the run involves the same
 // test binary and the flags on the command line come entirely from a
-// restricted set of 'cacheable' test flags, defined as -benchtime, -cpu,
-// -list, -parallel, -run, -short, -timeout, -failfast, -fullpath and -v.
+// restricted set of 'cacheable' test flags, defined as -benchtime, -cover,
+// -covermode, -coverprofile, -cpu, -list, -parallel, -run, -short, -timeout,
+// -failfast, -fullpath and -v.
 // If a run of go test has any test or non-test flags outside this set,
 // the result is not cached. To disable test caching, use any test flag
 // or argument other than the cacheable flags. The idiomatic way to disable
diff --git a/src/cmd/go/internal/test/cover.go b/src/cmd/go/internal/test/cover.go
index f614458dc4..461b60c3ca 100644
--- a/src/cmd/go/internal/test/cover.go
+++ b/src/cmd/go/internal/test/cover.go
@@ -16,7 +16,8 @@ import (

 var coverMerge struct {
 	f          *os.File
-	sync.Mutex // for f.Write
+	fsize      int64 // size of valid data written to f
+	sync.Mutex       // for f.Write
 }

 // initCoverProfile initializes the test coverage profile.
@@ -36,18 +37,19 @@ func initCoverProfile() {
 	if err != nil {
 		base.Fatalf("%v", err)
 	}
-	_, err = fmt.Fprintf(f, "mode: %s\n", cfg.BuildCoverMode)
+	s, err := fmt.Fprintf(f, "mode: %s\n", cfg.BuildCoverMode)
 	if err != nil {
 		base.Fatalf("%v", err)
 	}
 	coverMerge.f = f
+	coverMerge.fsize += int64(s)
 }

 // mergeCoverProfile merges file into the profile stored in testCoverProfile.
 // It prints any errors it encounters to ew.
-func mergeCoverProfile(ew io.Writer, file string) {
+func mergeCoverProfile(file string) error {
 	if coverMerge.f == nil {
-		return
+		return nil
 	}
 	coverMerge.Lock()
 	defer coverMerge.Unlock()
@@ -57,28 +59,33 @@ func mergeCoverProfile(ew io.Writer, file string) {
 	r, err := os.Open(file)
 	if err != nil {
 		// Test did not create profile, which is OK.
-		return
+		return nil
 	}
 	defer r.Close()

 	n, err := io.ReadFull(r, buf)
 	if n == 0 {
-		return
+		return nil
 	}
 	if err != nil || string(buf) != expect {
-		fmt.Fprintf(ew, "error: test wrote malformed coverage profile %s.\n", file)
-		return
+		return fmt.Errorf("test wrote malformed coverage profile %s", file)
 	}
 	_, err = io.Copy(coverMerge.f, r)
 	if err != nil {
-		fmt.Fprintf(ew, "error: saving coverage profile: %v\n", err)
+		return fmt.Errorf("saving coverage profile: %w", err)
 	}
+
+	return nil
 }

 func closeCoverProfile() {
 	if coverMerge.f == nil {
 		return
 	}
+	// Discard any partially written data from a failed merge.
+	if err := coverMerge.f.Truncate(coverMerge.fsize); err != nil {
+		base.Errorf("closing coverage profile: %v", err)
+	}
 	if err := coverMerge.f.Close(); err != nil {
 		base.Errorf("closing coverage profile: %v", err)
 	}
diff --git a/src/cmd/go/internal/test/test.go b/src/cmd/go/internal/test/test.go
index 08fac5f395..f877d27c1a 100644
--- a/src/cmd/go/internal/test/test.go
+++ b/src/cmd/go/internal/test/test.go
@@ -126,8 +126,9 @@ elapsed time in the summary line.

 The rule for a match in the cache is that the run involves the same
 test binary and the flags on the command line come entirely from a
-restricted set of 'cacheable' test flags, defined as -benchtime, -cpu,
--list, -parallel, -run, -short, -timeout, -failfast, -fullpath and -v.
+restricted set of 'cacheable' test flags, defined as -benchtime, -cover,
+-covermode, -coverprofile, -cpu, -list, -parallel, -run, -short, -timeout,
+-failfast, -fullpath and -v.
 If a run of go test has any test or non-test flags outside this set,
 the result is not cached. To disable test caching, use any test flag
 or argument other than the cacheable flags. The idiomatic way to disable
@@ -1337,6 +1338,13 @@ type runCache struct {
 	id2 cache.ActionID
 }

+func coverProfTempFile(a *work.Action) string {
+	if a.Objdir == "" {
+		panic("internal error: objdir not set in coverProfTempFile")
+	}
+	return a.Objdir + "_cover_.out"
+}
+
 // stdoutMu and lockedStdout provide a locked standard output
 // that guarantees never to interlace writes from multiple
 // goroutines, so that we can have multiple JSON streams writing
@@ -1395,13 +1403,6 @@ func (r *runTestActor) Act(b *work.Builder, ctx context.Context, a *work.Action)
 		return nil
 	}

-	coverProfTempFile := func(a *work.Action) string {
-		if a.Objdir == "" {
-			panic("internal error: objdir not set in coverProfTempFile")
-		}
-		return a.Objdir + "_cover_.out"
-	}
-
 	if p := a.Package; len(p.TestGoFiles)+len(p.XTestGoFiles) == 0 {
 		reportNoTestFiles := true
 		if cfg.BuildCover && cfg.Experiment.CoverageRedesign && p.Internal.Cover.GenMeta {
@@ -1425,7 +1426,7 @@ func (r *runTestActor) Act(b *work.Builder, ctx context.Context, a *work.Action)
 					if err := work.WriteCoverageProfile(b, a, mf, cp, stdout); err != nil {
 						return err
 					}
-					mergeCoverProfile(stdout, cp)
+					mergeCoverProfile(cp)
 				}
 			}
 		}
@@ -1615,7 +1616,9 @@ func (r *runTestActor) Act(b *work.Builder, ctx context.Context, a *work.Action)
 	a.TestOutput = &buf
 	t := fmt.Sprintf("%.3fs", time.Since(t0).Seconds())

-	mergeCoverProfile(cmd.Stdout, a.Objdir+"_cover_.out")
+	if err = mergeCoverProfile(a.Objdir + "_cover_.out"); err != nil {
+		return err
+	}

 	if err == nil {
 		norun := ""
@@ -1637,7 +1640,7 @@ func (r *runTestActor) Act(b *work.Builder, ctx context.Context, a *work.Action)
 			cmd.Stdout.Write([]byte("\n"))
 		}
 		fmt.Fprintf(cmd.Stdout, "ok  \t%s\t%s%s%s\n", a.Package.ImportPath, t, coveragePercentage(out), norun)
-		r.c.saveOutput(a)
+		r.c.saveOutput(a, coverProfTempFile(a))
 	} else {
 		if testFailFast {
 			testShouldFailFast.Store(true)
@@ -1735,6 +1738,18 @@ func (c *runCache) tryCacheWithID(b *work.Builder, a *work.Action, id string) bo
 			// Note that this list is documented above,
 			// so if you add to this list, update the docs too.
 			cacheArgs = append(cacheArgs, arg)
+		case "-test.coverprofile",
+			"-test.outputdir":
+			// The `-coverprofile` and `-outputdir` arguments, which
+			// only affect the location of profile output, are cacheable. This
+			// is based on the process where, upon a cache hit, stored profile
+			// data is copied to the specified output location. This mechanism
+			// ensures that output location preferences are honored without
+			// modifying the profile's content, thereby justifying their
+			// cacheability without impacting cache integrity. This allows
+			// cached coverage profiles to be written to different files.
+			// Note that this list is documented above,
+			// so if you add to this list, update the docs too.

 		default:
 			// nothing else is cacheable
@@ -1847,6 +1862,26 @@ func (c *runCache) tryCacheWithID(b *work.Builder, a *work.Action, id string) bo
 		j++
 	}
 	c.buf.Write(data[j:])
+
+	// Write coverage data to profile.
+	if cfg.BuildCover {
+		// The cached coverprofile has the same expiration time as the
+		// test result it corresponds to. That time is already checked
+		// above, so we can ignore the entry returned by GetFile here.
+		f, _, err := cache.GetFile(cache.Default(), testCoverProfileKey(testID, testInputsID))
+		if err != nil {
+			if cache.DebugTest {
+				fmt.Fprintf(os.Stderr, "testcache: %s: test coverage profile not found: %v\n", a.Package.ImportPath, err)
+			}
+			return false
+		}
+		if err := mergeCoverProfile(f); err != nil {
+			if cache.DebugTest {
+				fmt.Fprintf(os.Stderr, "testcache: %s: test coverage profile not merged: %v\n", a.Package.ImportPath, err)
+			}
+			return false
+		}
+	}
 	return true
 }

@@ -1993,7 +2028,12 @@ func testAndInputKey(testID, testInputsID cache.ActionID) cache.ActionID {
 	return cache.Subkey(testID, fmt.Sprintf("inputs:%x", testInputsID))
 }

-func (c *runCache) saveOutput(a *work.Action) {
+// testCoverProfileKey returns the "coverprofile" cache key for the pair (testID, testInputsID).
+func testCoverProfileKey(testID, testInputsID cache.ActionID) cache.ActionID {
+	return cache.Subkey(testAndInputKey(testID, testInputsID), "coverprofile")
+}
+
+func (c *runCache) saveOutput(a *work.Action, coverprofileFile string) {
 	if c.id1 == (cache.ActionID{}) && c.id2 == (cache.ActionID{}) {
 		return
 	}
@@ -2014,12 +2054,29 @@ func (c *runCache) saveOutput(a *work.Action) {
 	if err != nil {
 		return
 	}
+	saveCoverProfile := func(testID cache.ActionID) {}
+	if coverprofileFile != "" {
+		coverprof, err := os.Open(coverprofileFile)
+		if err == nil {
+			saveCoverProfile = func(testID cache.ActionID) {
+				cache.Default().Put(testCoverProfileKey(testID, testInputsID), coverprof)
+			}
+			defer func() {
+				if err := coverprof.Close(); err != nil && cache.DebugTest {
+					fmt.Fprintf(os.Stderr, "testcache: %s: closing temporary coverprofile: %v", a.Package.ImportPath, err)
+				}
+			}()
+		} else if cache.DebugTest {
+			fmt.Fprintf(os.Stderr, "testcache: %s: failed to open temporary coverprofile: %s", a.Package.ImportPath, err)
+		}
+	}
 	if c.id1 != (cache.ActionID{}) {
 		if cache.DebugTest {
 			fmt.Fprintf(os.Stderr, "testcache: %s: save test ID %x => input ID %x => %x\n", a.Package.ImportPath, c.id1, testInputsID, testAndInputKey(c.id1, testInputsID))
 		}
 		cache.PutNoVerify(cache.Default(), c.id1, bytes.NewReader(testlog))
 		cache.PutNoVerify(cache.Default(), testAndInputKey(c.id1, testInputsID), bytes.NewReader(a.TestOutput.Bytes()))
+		saveCoverProfile(c.id1)
 	}
 	if c.id2 != (cache.ActionID{}) {
 		if cache.DebugTest {
@@ -2027,6 +2084,7 @@ func (c *runCache) saveOutput(a *work.Action) {
 		}
 		cache.PutNoVerify(cache.Default(), c.id2, bytes.NewReader(testlog))
 		cache.PutNoVerify(cache.Default(), testAndInputKey(c.id2, testInputsID), bytes.NewReader(a.TestOutput.Bytes()))
+		saveCoverProfile(c.id2)
 	}
 }

diff --git a/src/cmd/go/testdata/script/test_cache_inputs.txt b/src/cmd/go/testdata/script/test_cache_inputs.txt
index 1868da9842..5576d9a7a6 100644
--- a/src/cmd/go/testdata/script/test_cache_inputs.txt
+++ b/src/cmd/go/testdata/script/test_cache_inputs.txt
@@ -120,6 +120,27 @@ go test testcache -run=TestOSArgs -fullpath
 go test testcache -run=TestOSArgs -fullpath
 stdout '\(cached\)'

+# Ensure that specifying a cover profile does not prevent test results from being cached.
+go test testcache -coverprofile=cover.out
+! stdout '\(cached\)'
+go test testcache -coverprofile=cover.out
+stdout '\(cached\)'
+
+# A new -coverprofile file should use the cached coverage profile contents.
+go test testcache -coverprofile=cover.out
+go test testcache -coverprofile=cover1.out
+stdout '\(cached\)'
+
+# A new -covermode should not use the cached coverage profile.
+go test testcache -coverprofile=cover.out
+go test testcache -covermode=count -coverprofile=cover.out
+! stdout '\(cached\)'
+
+# A new -coverpkg should not use the cached coverage profile.
+go test testcache -coverprofile=cover.out
+go test testcache -coverpkg=math -coverprofile=cover.out
+! stdout '\(cached\)'
+

 # Executables within GOROOT and GOPATH should affect caching,
 # even if the test does not stat them explicitly.

I am willing to pitch in with reviews etc as well if you think it would help. Thanks.

This is such a long-lasting painful issue 😭 For years, so close to solution, yet so far.

@thanm I have a new PR that I will look to see through the review process https://github.com/golang/go/pull/69339. If your generous offer of review is still on the table I would appreciate it.

@thanm I have a new PR that I will look to see through the review process #69339. If your generous offer of review is still on the table I would appreciate it.

Happy to review. I am tied up at the moment but I should be able to take a look in a couple of days. Thanks for sending the CL.

I have to get a test working on arm64. One test is failing on amd64 but it works on arm64. I have not had a chance to troubleshoot it, I will try to get to it soon now that it's getting quiet at work with the holidays.


chore(main): release 0.8.0

:robot: I have created a release beep boop
0.8.0 (2024-03-15)
Features

新增覆盖物组件 AMapRectangle (be3b9d8)
替换了高德 jsapi 的类型声明库 (492b909)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/xyy94813/amap-react-components/releases/tag/v0.8.0 :sunflower:


Do not show died players while in task state

When not in debug mode, the console shouldn't log the dead players while in Task state. It leaks information to the player using "Among us capture". The log should be displayed only once the state is changed to discuss.
When in debug mode, IMHO, the log should display as soon as the player die is detected.

Yeah this was implemented in WinForms but lost when we moved to WPF. Re-added in c44de02a44afc800ea8ee86c6d1be53d84c7c88d


add origin to telemetry to better measure usage

As we launch different tools like Gradio or lavague-qa CLI, we should measure usage of those interfaces with LaVague.

add origin to WebAgent and telemetry
default: "default"

Then we can start WebAgent with WebAgent(origin="lavague-qa") or WebAgent(origin="gradio")
This won't give us complete observability of LaVague QA (because it continues beyond agents) but will atleast measure basic usage of the tool.
@adeprez what do you think ?

#543


Layers are not selected in layer control

Hi,
I'm using tile layers (WMS). My problem is that, although the layers are visible when I open my map, they are not selected in the Layers control.
Then if I choose to select a layer in the Layers control, the map will finally reflect what is selected and what is not.
I don't think this is working properly.
Regards,
Barbara

hi @mourner ,  seems the same problem with me: there are no "set default" or "selected"  for  first layer.
The example at docs not show how to say "!!THIS IS THE DEFAULT LAYER!!",
var baseMaps = {
    "Grayscale": grayscale,   // how to say this is default
    "Streets": streets
};

... as in HTML <select> or checked in HTML checkbox.


Upgrade to 2.7.0

Pull Request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[x] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[x] Build-related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the new behavior?
Made some function deprecated.
Upgrade the code to 2.7
Fixed all warnings
Tried to make some fn generic (didn't look through all of em)
Replaced some while pop_front to for loop
Updated all assert to assert! and removed their error message as the default one is a good enough default value

@0xLucqs Ready for review.
An upgrade to latest edition should still be performed, will open an issue

flemme de review je close bonne journée

Random things I've noticed (not necessarily enabled by 2.7.0):

in bytes/src/utils.cairo, uint_min can be removed, replaced by core::cmp::min
there's probably something that can be done with iterators on ByteReader, Queue, Stack, Vec and elsewhere(?)

Since we now have const arrays (❤ dw ❤), IMO it's worth adding optimized pow2 and pow10 as these are the most commonly used power functions. Even in Alexandria, all the bitshift fns use pow(2, n).

updated utils.cairo
y, but I'd leave it for another PR as those are "extra" changes and this PR is big enough
Also would leave for another PR 😅 , please open an issue for that

@gaetbout we should suppress the warnings on compilation otherwise it's going to appear on all dependent repositories

I removed all warnings that are from the lib.
I believe the new warnings are from using now deprecated Alexandria stuff

my point is: what currently is used inside alexandria itself should not be triggering warnings

@0xLucqs ?

@0xLucqs ? :D

I want @milancermak to approve as well


[Go] change embedder plugins to use Init and New

Change the pinecone and localvec plugins to use a New function that returns an ai.Retriever, and an Init function that registers one with genkit.
This makes the pinecone and localvec plugins consistent with each other, and with other plugins such as googleai.

Argh, I did not mean to include the menu samples.


can't add new worker on existing cluster

[BUG]
rancher 2.2.2
k8s 1.11
custom
single install/non-HA
For whatever reason I suddenly can't add new worker to our existing 80 node cluster thats been running since months (where we add and remove worker every week or so) ...
Following error on the new worker:
time="2019-05-14T13:41:41Z" level=info msg="Error while getting agent config: invalid response 500: Failed to construct node config. Error: failed to find plan for 10.3.x.x"
Error on the webui:
This cluster is currently Updating. Delete https://10.3.x.x:6443/api/v1/namespaces/default/serviceaccounts/netes-default: can not build dialer to c-q89w5:m-16d45e0c7c90
I tested with different worker rancher versions, was always the same problem, issue must be on the master.
This is quite a problem.
edit: solution below

It seems that in the other use cases, upgrading to k8s 1.13 has solved the issue for them. Would you be able to see if that fixes it for you?

I can't just upgrade the whole cluster for testing purposes. Furthermore this is not a k8s issue but a rancher issue, after all adding worker nodes doesn't work.

Ok so we upgraded to 1.12 and the issue disappeared.
Clearly a Rancher bug, my assumption was right.

We have the same issue here with rancher 2.2.3. We can't add new nodes but we are already at the latest kubernetes version 1.13.5 so we cannot upgrade.
Error while getting agent config: invalid response 500: Failed to construct node config. Error: failed to find plan for xxx.xxx.xxx.xxx

@bhupfer  Ok maybe I drew the wrong conclusion then. I didn't get anything proper from logs, did you have a look at rancher master logs?

The rancher logs look similar to our web-ui. We have the repeating error:
2019/05/28 07:26:45 [INFO] kontainerdriver rancherkubernetesengine listening on address <IP_ADDRESS>:10122
2019/05/28 07:26:45 [INFO] kontainerdriver rancherkubernetesengine stopped
2019/05/28 07:26:45 [ERROR] ClusterController c-2kkwc [cluster-provisioner-controller] failed with : Delete https://10.x.x.x:6443/api/v1/namespaces/default/serviceaccounts/netes-default: can not build dialer to c-2kkwg:m-3a4a7d540b79
2019/05/28 07:26:45 [INFO] Provisioning cluster [c-2kkwc]
2019/05/28 07:26:45 [INFO] Updating cluster [c-2kkwc]
It repeats every 5 Seconds.

@bhupfer try to make sure that your new worker does not have the same hostname as an existing or prrior existing worker, they always need to have brand new hostnames. try again

Same here, same log output.
Rancher/K8S Details:
-Rancher server v2.2.3
-Rancher installation type: High availability, K8S v1.11.1
-K8S cluster managed by Rancher: v1.11.3
Worker Node Details:
-OS: Ubuntu 16.04.06, Kernel 4.15
-Docker version: 1.12.6
Please help

I've tried a total new never used Hostname. The Problem still persists.
Rancher Agent Log:
time="2019-06-12T06:17:01Z" level=info msg="Error while getting agent config: invalid response 500: Failed to construct node config. Error: failed to find plan for <IP_ADDRESS>"
time="2019-06-12T06:17:06Z" level=info msg="Error while getting agent config: invalid response 500: Failed to construct node config. Error: failed to find plan for <IP_ADDRESS>"
Rancher Log:
2019/06/12 06:22:25 [ERROR] ClusterController c-3kkwc [cluster-provisioner-controller] failed with : Delete https://10.xxx.xxx.xxx:6443/api/v1/namespaces/default/serviceaccounts/netes-default: can not build dialer to c-123wc:m-345a7d540b75
2019/06/12 06:22:25 [INFO] Provisioning cluster [c-3kkwc]
2019/06/12 06:22:25 [INFO] Updating cluster [c-3kkwc]
Rancher Server: 2.2.3
K8s Version: 1.13.5
OnPrem Cluster managed by Rancher.
Tested OS:

Ubuntu 1804
RancherOS 1.5.1

The error is shown when a worker is added while the cluster is unavailable (either in Updating state or where cluster/node-agents are not connected). If you can supply the View in API output for the affected cluster, that would confirm that.
can not build dialer to means that the agent is not connected to Rancher, you can check the logging on that host for the agent container to see whats going on, it might get stuck so deleting it might help to recreate it (if the actual k8s cluster is still healthy). Using the API for that node can help you identify it, use https://rancher.yourdomain.com/v3/nodes/c-123wc:m-345a7d540b75 for your last log.
If any of you can supply the requested info, I can confirm and change the code to have the worker wait for Cluster in Active state or something else before proceeding.

Created https://github.com/rancher/rancher/issues/23253 to add better logging/investigate to prevent node from registering when cluster is not ready. If you encounter this in any other situation, let me know.


New version: Microsoft.OneDrive version 21.205.1003.0005

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Have you tested your manifest locally with winget install --manifest <path>?
[X] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

/azp run

.


Migrate podman inspect and tag to image library

Signed-off-by: baude<EMAIL_ADDRESS>

One nit otherwise LGTM

bot, retest this please

@rh-atomic-bot r+


Video (and probably audio) streams are not going back to life after a short network shutdown

Hi,
If I shutdown the network interface for a long time, the 'room-disconnected' event is fired as expected, though after a long timeout which is probably reasonable.
If the emulated network downtime period is relatively short, say, few seconds, then only data streams are going back to life but the video (probably audio too) streams are just freezing without any error reporting though their stream.pc.peerConnection.iceConnectionState becomes "disconnected".
The expected behaviour is maybe whether to fire 'stream-removed' and 'room-disconnected' events or to bring the streams back to life after the downtime.
Please assist.

This should be working now.
Ice fails now remove the publisher or the subscriber from the room


Clarify documentation regarding "cdef public"

I think the documentation about cdef public is unclear, especially about the "linking" part. In particular, it seems to imply that you can link code against the extension module (i.e. using the .so file as a dynamic library). That works on Linux, but isn't portable (it does not work on OS X for example).

To be clear, "the Cython-generated C file" is not what's linked of course

Technically, you are right. But I think this is a case where it is clear what is meant.

I'm not sure--I think it's clear enough to us because we know what the use case is.  But I could see someone coming to this for the first time being confused.  That said, a slight change of wording wouldn't fix that either.  I think maybe the specific example you give later is good enough to clarify.

In any case, it's better than before. Thanks.


Have the same name when compiled the less file.

Today, I have a problem. In different files, the animation's  keyframe name will compile to the "a", "b", "c" ... by index. So when I quote two css files will have the same name problem. So I can't use the two files in the same HTML.
 Support questions should be directed to StackOverflow.


error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused

What type of bug is this?
Other
What subsystems are affected?
Other
Minimal reproduce step
Regular build.
What did you expect to see?
n/a
What did you see instead?
error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused
   --> /wrkdirs/usr/ports/databases/greptimedb/work/RustPython-9ed51374125b5f1a9e5cee5dd7e27023b8591f1e/vm/src/class.rs:124:17
    |
123 |                 let r: &Py<PyType> = &typ;
    |                                       --- backing allocation comes from here
124 |                 &*(r as *const _)
    |                 ^^^^^^^^^^^^^^^^^
    |
    = note: casting from `core::PyRef<type_::PyType>` (8 bytes) to `core::Py<type_::PyType>` (856 bytes)
    = note: `#[deny(invalid_reference_casting)]` on by default

warning: `rustpython-vm` (lib) generated 5 warnings
error: could not compile `rustpython-vm` (lib) due to 1 previous error; 5 warnings emitted

What operating system did you use?
FreeBSD 14.1
What version of GreptimeDB did you use?
0.9.0
Relevant log output and stack trace
n/a

Duplicated with https://github.com/GreptimeTeam/greptimedb/issues/4219

rust-1.79.0

close as a duplicate of https://github.com/GreptimeTeam/greptimedb/issues/4219


Parallelize over multiple VMs

Hi,
I'm running neural style in a VM. Is it possible to parallelize the process over multiple VMs?
Thanks.

You could run multiple independent VMs each running their own instance of neural-style, but there's no easy way to parallelize the computation of a single instance across VMs.


fix(NODE-3681): Typescript error in Collection.findOneAndModify UpdateFilter $currentDate

Description
When a field with boolean value true, is passed into $currentDate, it will no longer throw an TS error.
What is changing?
Example:
$currentData: {
   lastModified: true
} // no longer throws a TS error

Is there new documentation needed for these changes?
No.
What is the motivation for this change?
The motivation is that the Node Driver should not output unnecessary errors to users.

Release Highlight

Collection.findOneAndModify's UpdateFilter.$currentDate no longer throws on collections with limited schema
Example:
const collection = new Collection(); // collection with no schema
collection.update(
    $currentData: {
       lastModified: true
    } // no longer throws a TS error
);

Double check the following

[x] Ran npm run check:lint script
[x] Self-review completed using the steps outlined here
[x] PR title follows the correct format: type(NODE-xxxx)[!]: description

Example: feat(NODE-1234)!: rewriting everything in coffeescript

[x] Changes are covered by tests
[x] New TODOs have a related JIRA ticket

CI failures are unrelated.  All TS-related tasks pass in CI.


[CDS-100620] Expression option in GitOps deploy stage environment tab

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

 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.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://672b158dbeadb902b6cad666--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://672b3955beadb931bbcad752--harness-developer.netlify.app


Guild Profile: Crash on viewing profile

A react error is given when pressing the "Server Profile" button, resulting in an immediate crash before any window pops up. This was reproducible by both right clicking and using the server's context menu.
The full error can be seen below:
95f46b4ca96f251d8bd0.js:130 Error: Minified React error #130; visit https://reactjs.org/docs/error-decoder.html?invariant=130&args[]=undefined&args[]= for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
    at nl (2558d62ca90f56f71658.js:5907)
    at e (2558d62ca90f56f71658.js:5846)
    at Ba (2558d62ca90f56f71658.js:5858)
    at $s (2558d62ca90f56f71658.js:5903)
    at Gu (2558d62ca90f56f71658.js:5893)
    at wu (2558d62ca90f56f71658.js:5893)
    at Uu (2558d62ca90f56f71658.js:5893)
    at yu (2558d62ca90f56f71658.js:5890)
    at 2558d62ca90f56f71658.js:5835
    at t.unstable_runWithPriority (2558d62ca90f56f71658.js:6024)
    at Ki (2558d62ca90f56f71658.js:5835)
    at qi (2558d62ca90f56f71658.js:5835)
    at Xi (2558d62ca90f56f71658.js:5835)
    at vu (2558d62ca90f56f71658.js:5887)
    at Ma (2558d62ca90f56f71658.js:5855)
    at e (2558d62ca90f56f71658.js:4706)
    at 2558d62ca90f56f71658.js:4704
    at Set.forEach (<anonymous>)
    at Function.r [as setState] (2558d62ca90f56f71658.js:4704)
    at Object.I [as openModal] (2558d62ca90f56f71658.js:3567)
    at GuildProfile.openGuildProfileModal (GuildProfile.plugin.js:1575)
    at action (GuildProfile.plugin.js:1557)
    at 2558d62ca90f56f71658.js:2316
    at r (95f46b4ca96f251d8bd0.js:126)

Same here, its been happening for the last hour or two.

Yup, I was going to report and saw people having the same problem. My Discord version is Stable 12661 (6ac3f2f) if it would be helpful.

It will probably be fixed soon

Quick fix:
Line: 1136
old
const Text = (external_BoundedLibrary_namespaceObject.WebpackModules.getByDisplayName('Text'));

new
const { Text }= (external_BoundedLibrary_namespaceObject.WebpackModules.find(e => !e.window && !e.Image && !e.Span && e.Text ));

Line: 1177
old
const UserMention = external_BoundedLibrary_namespaceObject.WebpackModules.getByDisplayName('UserMention');

new
const { UserMention } = external_BoundedLibrary_namespaceObject.WebpackModules.getByProps('UserMention');


Changelog

Hi,
first of all, thanks a lot for the great library (Y)
I can see that a new version have been recently released - v2.5.0. The question - how do I know what exactly has been changed in this version compared to the previous one? Are there any breaking changes to take care of while upgrading? What are the new APIs added?
Thanks in advance

Thanks @dmytro-gokun  for your suggestion for Changelog that can track changes in versions and breaking changes.
Changelog will be added to the project with a new PR.
There is no Breaking change in v2.5.0. Current projects net40,net45 (net4x) and netstadard2.0/netcoreapp2.x  can upgrade to this version without breaking change.
The test is done in multi target framework.
2.5.0 (2019-04-29)
Bug Fixes

Fix  the null EntryAssembly Exception in  unit test net4x projects ( issue: #389 )
Fix  the test case 'Add unit tests for Issue #389 and #392
Fix CSC error CS7027: Error signing output with public key from file 'CommandLine.snk' -- Invalid public key in appveyor CI.
Fix the error CS0234: The type or namespace name 'FSharp' for net40 Framework.
Fix Mis-typed CommandLine.BaseAttribute.Default results in ArgumentException: Object of type 'X' cannot be converted to type 'Y' (issue #189)

Features

Add support for net40 and net45 without breaking change of the netstandard2.0 project for CSharp and Fsharp projects.
Commandline project is becoming multi-target Framework net40,net45,net461 and netstandard2.0.
Commandline.Test project is becoming multi-target Framework net461 and netcoreapp2.0.
Enhance the CSharp demo project to support  multi-target Framework net40; net45; netcoreapp2.0, netcoreapp2.1

@moh-hassan
Hi, I just upgraded from a rather old version to 2.5.0 and ParserState attribute, HelpOption attribute, IParserState are no longer available. And HelpText.AutoBuild has a new signature.
Where can I find a migration path?

@cosmoKenney ,
What the version you upgraded from?

If you are upgrading from v1.x to v2.x, there is a major change
This post may help but it isn't complete.
Have a look to  this   and https://github.com/commandlineparser/commandline/issues/225

@moh-hassan
Hmm... this is killing me. I just need to make some simple changes to this project. I may need to roll back to 1.9. The new version is way overkill for what I need.
ParseArgumentsStrict used to return boolean indicating success or fail. But now there is a result object from the generic ParseArguments. How do I get parse status from the ParserResult?

Try reading getting start in the readme  or wiki

How do I get parse status from the ParserResult?

Have a look to this demo online
Just know how to call parser and how to return result and modify the options.
I will try to complete the document of migration .
V2.x have many valuable features.

I migrated an online  demo application in v1.9
To version 2.5
with comments in the source code  how to be converted
It 's simple steps.
I Hope it may help you.

@moh-hassan This issue still not ready?

@sm-g
CHANGELOG.md  is added in v2.6.0
What do you mean by "not ready"?

I mean "why this issue still open".
пт, 6 сент. 2019 г., 8:18 Mohamed Hassan<EMAIL_ADDRESS>
@sm-g https://github.com/sm-g
CHANGELOG.md
https://github.com/commandlineparser/commandline/blob/master/CHANGELOG.md
is added in v2.6.0
What do you mean by "not ready"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/commandlineparser/commandline/issues/440?email_source=notifications&email_token=ABXRNEIFE7YJ64TNZ2GS5STQIHR25A5CNFSM4HJIUMWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6BYDTY#issuecomment-528712143,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABXRNENMAMODR5LCPME76OTQIHR25ANCNFSM4HJIUMWA
.

@sm-g
Thanks for reminding :)
Closed.


Method Array.Empty not found

What You Are Seeing?
Can't build c# project since cake nuget packages don't get downloaded.
What is Expected?
Cake should download it's dependencies.
What version of Cake are you using?
$ ./build.sh
Restoring NuGet package Cake.0.22.2.

Installed dotnet core via: https://www.microsoft.com/net/core#linuxubuntu
$ dotnet --version
2.0.0

Installed mono via: sudo apt install mono-devel
$ mono --version
Mono JIT compiler version 4.2.1 (Debian <IP_ADDRESS>+dfsg2-7ubuntu4)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen

Are you running on a 32 or 64 bit system?
64
What environment are you running on?  Windows? Linux? Mac?
Ubuntu 16.4.3 LTS Server
Are you running on a CI Server?  If so, which one?
Custom Jenkins installation
How Did You Get This To Happen? (Steps to Reproduce)
git clone <project>
chmod u+x build.sh
./build.sh

Can you point us to a project where this problem occurs?  i.e. a public GitHub Repo, where we can try to reproduce the problem, and help with debugging?
https://gitlab.com/lyze237/OwlPlugins
Output Log
$ ./build.sh -verbosity=diagnostic
Downloading packages.config...
Downloading NuGet...
Feeds used:
  /var/lib/jenkins/.nuget/packages/
  https://api.nuget.org/v3/index.json

Restoring NuGet package Cake.0.22.2.
Adding package 'Cake.0.22.2' to folder '/var/lib/jenkins/jobs/OwlPlugins/workspace/tools'
Added package 'Cake.0.22.2' to folder '/var/lib/jenkins/jobs/OwlPlugins/workspace/tools'
Error: Method 'String.Format' not found.
Unhandled Exception:
System.MissingMethodException: Method 'Array.Empty' not found.
  at Cake.Core.Diagnostics.CakeBuildLog.Write (Verbosity verbosity, LogLevel level, System.String format, System.Object[] args) <0x40273eb0 + 0x002a3> in <filename unknown>:0
  at Cake.Core.Diagnostics.LogExtensions.Error (ICakeLog log, Verbosity verbosity, System.String format, System.Object[] args) <0x40273e60 + 0x00042> in <filename unknown>:0
  at Cake.Core.Diagnostics.LogExtensions.Error (ICakeLog log, System.String format, System.Object[] args) <0x40273e20 + 0x00023> in <filename unknown>:0
  at Cake.Program.Main () <0x41b0ad60 + 0x00637> in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.MissingMethodException: Method 'Array.Empty' not found.
  at Cake.Core.Diagnostics.CakeBuildLog.Write (Verbosity verbosity, LogLevel level, System.String format, System.Object[] args) <0x40273eb0 + 0x002a3> in <filename unknown>:0
  at Cake.Core.Diagnostics.LogExtensions.Error (ICakeLog log, Verbosity verbosity, System.String format, System.Object[] args) <0x40273e60 + 0x00042> in <filename unknown>:0
  at Cake.Core.Diagnostics.LogExtensions.Error (ICakeLog log, System.String format, System.Object[] args) <0x40273e20 + 0x00023> in <filename unknown>:0
  at Cake.Program.Main () <0x41b0ad60 + 0x00637> in <filename unknown>:0

Hi,
Cake.0.22.0 targets .NET 4.6 which requires Mono 4.4.2 or later to work alternatively .NET Core 1.0.4.
And example of what's needed for a GitLab docker container (or Linux in general) can be seen in this Dockerfile

https://github.com/devlead/gitlabs-dotnet/blob/master/Dockerfile

Example usage on GitLabs

https://github.com/cake-build/cake/blob/develop/.gitlab-ci.yml

Hey!
Thanks, didn't see that, works now fine!

For anybody trying this with ubuntu 17.04, you need to install some depenencies manually:

libicu55
libllvm3.6
liblldb-3.6

E.g.:
wget http://security.ubuntu.com/ubuntu/pool/main/i/icu/libicu55_55.1-7ubuntu0.2_amd64.deb
sudo dpkg -i libicu55_55.1-7ubuntu0.2_amd64.deb
wget http://mirrors.kernel.org/ubuntu/pool/main/l/llvm-toolchain-3.6/libllvm3.6v5_3.6.2-3ubuntu2_amd64.deb
sudo dpkg -i libllvm3.6v5_3.6.2-3ubuntu2_amd64.deb
wget http://mirrors.kernel.org/ubuntu/pool/main/l/llvm-toolchain-3.6/liblldb-3.6_3.6.2-3ubuntu2_amd64.deb
sudo dpkg -i liblldb-3.6_3.6.2-3ubuntu2_amd64.deb

Getting this error on macOS as well. Is it the same story with Mono, @devlead ..? What do I need to do to get 0.22+ working?
Cake.0.21.0 works fine at the moment.

Cake 0.22.0+ targets .NET 4.6, which means you'll need Mono 4.4.2 or later, Mono 5.4 was recently released, we currently build Cake with Cake and run integration tests on MacOS and Linux using Mono versions 4.4.2 and 5.2. If you're running an older version of mono, then I'll suggest you'll try a newer version.

First time for me running Cake on macOS (only ran it on Win in the past), so not sure which version of Mono I'm running :-)

Try mono - -version


[rstmgr] D2S review opens

[x] make another copy of scanmode for shadow usage.
[x] clean up alert indexing nit
[x] check whether it makes sense to pull this out as a parameter (maybe a Sec parameter?) - but this is a low-prio cleanup.
[x] add a terminal error state where the checker FSM should move to upon detecting a fatal error condition.
[x] split FSM alert from consistency checker alert (i.e. make two channels) so that they can be classified separately in the alert handler - but keep both conditions as fatal.
[x] It would be good to detect a transition into and out of scanmode and assert POR as an atomic operation. This likely incurs addition of non-scannable sequential elements (due to edge detection and due to the delay needed in order to assert the resets before letting scanmode propagate to the system and steer all the muxes). Need to double check with DFT guys from Nuvoton.
[ ] Chris to sync spreadsheet to CMs
[x] Take a look at documentation comments and check what can be fixed.

@tjaychen should we split out the POR on scan entry/exit into a separate issue so that we can mark this done and close it?

yeah we can do that. Although that particular feature won't show up in open source though, so maybe we should file it as a closed source issue.

Done.

spreadsheet sync'd.


usb: device_next: update IAD during CDC ACM initialization

Set bFirstInterface of IAD during class initialization.

@tmon-nordic @desowin please refrain from approving twice under different accounts in the future


Update OpenEXR and spill out it's deps

Description
update OpenEXR to latest
add IMath and Deflate submodule
force OpenEXR to use local deps (IMath & Deflate) instead of using fetchContent
Testing
compiles Nabla

currently, IMath & Deflate submodules point to OP's repo, @AnastaZIuk suggested to fork IMath; should Deflate also be forked?

currently, IMath & Deflate submodules point to OP's repo, @AnastaZIuk suggested to fork IMath; should Deflate also be forked?

actually as long as we don't plan to modify their CMake we don't have to fork


Break out operator configuration and startup

Makefile: Drop -mod=readonly from test directive
Remove the -mod=readonly option from the unit test directive to ensure that we are using the vendor directory for unit tests.
go.mod Add go-logr dependency
go.mod:
Explicitly add go-logr in support of operator.go.
vendor/modules.txt:
Run go mod vendor.
Break out operator configuration and startup
controllers/externaldns_controller.go ->
pkg/operator/controller/externaldns/controller.go:
Move the exteraldns controller.go to a subdir of the new controller directory. Update the package name used for the controller.
pkg/operator/operator.go:
New file. Implements operator New(...) and Start(...) functions to move startup logic code out of cmd/.
pkg/operator/config/config.go:
New file to define options necessary to start the operator.
pkg/operator/scheme.go:
New file to define the API types necessary for the operator's clients to work. Implements GetOperatorScheme to relocate startup logic from cmd/.
cmd/externaldns-operator/main.go:
Strip out relocated code in an attempt to minimize code/logic in cmd/.

/cc @alebedev87

/lgtm


add mapzen.js example usage for API key and language; shorten imports…

… to just refill-style

It took me a long time to figure out the Tangram global scene options, especially for setting language, so I wanted to provide an example in the docs. There a larger question around if we should show this type of code snippet for all sdk options, but at least having it there for 2 is better than 0 for now?

LGTM, glad to have shorter URLs and condensed attribution


menu not working

menu (in footer for example) does not work.
this line:
// set in local dom
Polymer.dom(context).appendChild(ul);
does not append child to the element.

This is fixed in dev.  I will release it soon.


[Bug]: Puppeter very slow when converting html to pdf

Bug description
Having a bit html which results in 50-60 pages pdf, my puppeteer takes more than 20 seconds to convert it to pdf (page.pdf).
Here are my args:
'--no-sandbox',
'--disable-setuid-sandbox',
'--disable-dev-shm-usage',
'--hide-scrollbars',
'--disable-gpu',
'--full-memory-crash-report',
'--mute-audio',
"--proxy-server='direct://'",
'--proxy-bypass-list=*'

What could be the problem? Is there any issue with fonts, images, or anything like that that could be slowing down the process?
Thanks a lot
Puppeteer version
13.0.1
Node.js version
14.16.0
npm version
6.14.11
What operating system are you seeing the problem on?
Linux
Relevant log output
No response

I noticed that the parts of my html that make Puppeteer take a very long time are table.
So, it looks like Puppeteer is slow rendering this kind of element?

They are really long tables, so maybe the problem is that Puppeteer just cant make it faster when there is so much html to render?

After a lot of testing, I can't manage to bring the generation time down, so I'm assuming that Puppeteer just can't handle very well a few pages of pdf.
I will try finding another libraries or options to generate our pdfs.

Do you have any progress?

akitaTian

None at all. I managed to bring down the html generation time. That is, the execution of my spa in the browser.
After that, when I use page.pdf, it takes about 15 seconds to finish a 65 page document. I think it is insane, however, if I try to do CTRL+P on my Chrome browser, it takes about the same time to give me the preview so I assumed that this is as far as we can go with Chrome/Puppeteer.
I'm sure there is some CSS that is making this process slower, maybe the tables (I have 18 on this document).

My html document is about 600 pages,  it takes about 40 seconds by chrome browser or firefox browser
. Maybe i should find another way to convert.  Thanks for your work. -.-

I've read on many places about converting to pdf using page ranges, and then using another library/tool to merge the pages. That could bring down your time.
Before puppeteer, we used wkhtmltopdf and it was quite faster. However, you'll have to do css adjustments as it doesn't run a Chromium browser under the hood. It runs QTBrowser.
Check it out.

Regarding performance I have created the following Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1277420
Long story short, performance implodes when using header/footer and the page has high memory usage.

They just lowered the priority, sad news. This is important and is a major feature in all Chrome browsers.
https://bugs.chromium.org/p/chromium/issues/detail?id=1277420

I'm using Puppeteer to create PDFs as well, and I noticed a significant difference in generation time depending on the content. In my case, having an  element in both the header and footer increased the time to generate a 32-page PDF (containing table) from 1.32 seconds to 9.59 seconds. Removing these images dramatically improved the performance.
I will try svg instead of img

Update: i tried with svgs and its much faster! from 9.59 seconds to 1.93seconds

In my case, puppeteer in docker takes about 1 second to render a blank page without any content. It quickly becomes a few seconds when a few simple html elements are added...


added unit test: string with variable get expanded

Skipped as it's unclear if its a bug

I believe this is a bug, shouldn't we try to fix in this pull request too?

If it's a bug, yes. Although I could be handy to expand also strings? For configuring passwords globally etc.

It could have use cases but I think it is a bit counter intuitive

Agree. But I'm always reticent (not sure if this is the correct English word) with changing things non-backwards compatible.

I'll merged the test for now, when we figure out what to do a new pull request can be added

:+1:

It seems to me that, there is a (new) bug originated in the change of the source Eventlog from the original Post: https://github.com/NLog/NLog/issues/669
I'm new to github, so - if this is not the place to say this please tell me so.
What I noticed: The EventLog-Target has as Source a Layout
https://github.com/nlog/nlog/wiki/EventLog-target
But: trying to set it like this failed:
logEvent.Properties["MySource"] = useSource;
logEvent.Properties["EventID"] = dicId.EventId;

   <target xsi:type="EventLog" name="ELNoFileName" machineName="."
            source="${event-properties:item=MySource}" log="Application"
            eventId="${event-properties:EventID}"
            layout="ELNoFileName (${event-properties:item=MySource}): ${message}"/>

It DOES set the EventID, it DOES set the source, but it seems to me it KEEPS the source the same for all logevents to the target after the first loggin-action.
Now - as you can see - it's pretty mystic for me. How to report such a bug or how to give you guys the possibility to re-create this problem?
Maybe it's also about the useSource?`Basically i fill it like this:
 var eventLogSource = !string.IsNullOrEmpty(userMethod?.DeclaringType?.Assembly.GetName().Name)
                ? userMethod.DeclaringType.Assembly.GetName().Name
                : "Application Error";

@ArchonMegalon is this the same issue as https://github.com/NLog/NLog/issues/1542?

Hi! Yes! I was not able to find my own post again, so I opened a new issue. Sorry for that!


Added new methods to gradients, and customization options to fractals that use them

I think the current selection of gradients for the fractals could be a bit dull, so what if we make it wider by adding customization options?
In the first commit, I added the option of reversing the gradient (turning the gradient upside down):

At some point I added the option of rotating the hue of the colors in the gradient. However, in the last commit I removed the HueRotation property in the EffectData. because the user can just use Adjustments > Hue / Saturation; but if you think that keeping that property is a good idea, you could drop the last commit.

👍 I think just leaving it at allowing the user to reverse the gradient seems good. Can the Rotate methods also be removed to avoid introducing unused code?

Yeah, no problem, they have been removed now


GitHub Desktop Pull Request Notification Testing - Failed Unit Tests

This is just a general pull request comment. Not a review comment.


Any way to get the model?

HF removed the model and the website has been down for months, could you upload the model to torrents or something similar for private use?

not currently, no, I'm sorry


mithril-modal and  m.redraw.strategy("none")

Hi, I'm using Leo's modal  module:
https://github.com/HumanDesign/mithril-modal
If the modal view contains "input" field for instance ,each click causes redraw as it should.
The problem is that i must call "e.stopPropagation()",  m.redraw.strategy("none") still causes redraw and closing the modal. on input click
best

This is explained pretty well here: http://lhorie.github.io/mithril/mithril.redraw.html#strategy

Lastly, be aware that if a user action triggers more than one event handler (for example, oninput and  onkeypress, or an event bubbling up to event handlers in multiple ancestor elements), every event  triggers a redraw by default. Setting strategy to none in any one of those handlers will not affect the  redrawing strategy of other handlers (and remember that strategy("none") has no effect on asynchronous redraws).

10x


Add Slofile to Slack page

Link where content currently exists
https://techqueria.org/communities/slack
Updates you'd like to make
Add https://slofile.com/slack/latinos at the end of the sentence "As you are waiting for your Slack invite" with "You can also get a taste of our Slack workspace by checking out Slofile profile."
Any additional context?
N/A

Hello, I would like to help you with this.

@KonradGladala Sure go ahead!


macos cmake build install_name missing @rpath or abspath

When building openblas with cmake, I am seeing that the dylib on macos only has the dylib name as its install_name. Therefore, linking applications struggle to use this binary.
$ otool -D libopenblas.0.3.dylib
libopenblas.0.3.dylib:
libopenblas.0.dylib

Makefile built seems fine, likely by design.
I am wondering if this is an expected behaviour?

The cmake build was a later addition and may still be missing some details of the gmake one. I take it the toplevel CMakeLists.txt is currently lacking the -headerpad_max_install-names -install_name ... options at ir near line 274 ?

CMake can take of it. One just needs to add something like
IF(APPLE)
  SET(CMAKE_INSTALL_NAME_DIR @rpath)
ENDIF(APPLE)

https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_NAME_DIR.html

@martin-frbg to me it makes more sense to bump the minimum cmake version to 3 so you get MACOSX_RPATH by default.
Notice that CMake 3.19 already complains about OpenBLAS's cmake minimum version being too old.
Also notice that CMake 3 was released over a decade ago.
Changed in version 3.27: Compatibility with versions of CMake older than 3.5 is deprecated. Calls to cmake_minimum_required(VERSION) or cmake_policy(VERSION) that do not specify at least 3.5 as their policy version (optionally via ...<max>) will produce a deprecation warning in CMake 3.27 and above.

Changed in version 3.19: Compatibility with versions of CMake older than 2.8.12 is deprecated. Calls to cmake_minimum_required(VERSION) or cmake_policy(VERSION) that do not specify at least 2.8.12 as their policy version (optionally via ...<max>) will produce a deprecation warning in CMake 3.19 and above.


enoent on OTP 25

This issue on OTP-25 has come up for us a few times, https://github.com/open-telemetry/opentelemetry-erlang/issues/545
pubkey_os_cacerts:get/0 is failing with enoent for some reason. Have you seen this at all? Does there just need to be some error handling there to fallback to pre-OTP-25 behaviour if it fails?

Ah! My mistake... It looks like the following is happening:

pubkey_os_cacerts:load/0 returns an error, resulting in a bad match:
https://github.com/erlang/otp/blob/07cf1c5caab19852ccf85ae7000d788913f3411d/lib/public_key/src/pubkey_os_cacerts.erl#L38
tls_certificate_check:maybe_load_authorities_trusted_by_otp/3 fails to catch the exception because it's matching anything that's both not of the error class nor for an undef reason, rather than neither:
https://github.com/g-andrade/tls_certificate_check/blob/93bfba794fe55c1b7fb8ee3d410311c1f870d079/src/tls_certificate_check_shared_state.erl#L372

I've reproduced the issue and applied a fix: tls_certificate_check 1.17.4 should work as expected. Thanks for reporting!


basic pwa setup

Description
Basic PWA setup and update the README, lol I think the README is not that great but please feel free to suggest 🙌
Additional Information

[X] I have read the contributing docs (if this is your first contribution)
[X] This is not a duplicate of any existing pull request

Related Issues
Your ENS/address: shivbhonde.eth

gj Shiv!! 🙌
I'm trying this out to add extra details to Readme with the stuff I find difficult to execute during the setup, and found myself in trouble while trying to run yarn vercel. I had to change the import from contract.ts to use this route to make it work:
import { Prettify } from "viem/types/utils";

Think is related with SE2 issue #419, because I found the same problem while trying to yarn vercel a fresh SE2. Here are the details (screenshots from my SE2 test but the errors were the same on this PR):
yarn vercel, throws an error while building. Those are details for the errors on Vercel console:

Error from bash console on Windows:
$ yarn vercel
Vercel CLI 28.15.1
? Set up and deploy “E:\GitHub\scaffold-eth-2\packages\nextjs”? [Y/n] y
? Set up and deploy “E:\GitHub\scaffold-eth-2\packages\nextjs”? [Y/n] y
Loading scopes…
? Which scope do you want to deploy to?
? Which scope do you want to deploy to? tokodev
Searching for existing projects…
? Link to existing project? [y/N] n
? Link to existing project? [y/N] n
? What’s your project’s name? (nextjs) se2-test-viem-folder
? What’s your project’s name? se2-test-viem-folder
Verifying project name…
? In which directory is your code located? ./
? In which directory is your code located? ./
Setting up project
Uploading [--------------------] (0.0B/80.4KB)
Uploading [======--------------] (24.2KB/80.4KB)
Uploading [=============-------] (55.4KB/80.4KB)
Uploading [=================---] (71.4KB/80.4KB)
Uploading [====================] (80.4KB/80.4KB)
Local settings detected in vercel.json:
Auto-detected Project Settings (Next.js):
- Build Command: next build
- Development Command: next dev --port $PORT
- Install Command: `yarn install`, `pnpm install`, `npm install`, or `bun install`
- Output Directory: Next.js default
? Want to modify these settings? [y/N] n
? Want to modify these settings? [y/N] n
Deploying tokodev/se2-test-viem-folder
Linked to tokodev/se2-test-viem-folder (created .vercel)
Inspect: https://vercel.com/tokodev/se2-test-viem-folder/8n1XJey375nRJ5T2jp9aHy4BPwbH [1s]
https://se2-test-viem-folder-a65w9fbhz-tokodev.vercel.appQueued
Building
Error: Unexpected error. Please try again later. ()

I've just added some additional info to the Readme, and re-worded / formatted some sections.
We'll have to add all the features explanations when we have them, and keep improving current content in further iterations 🙌

Great work @technophile-04!! And thanks @Pabl0cks for the review.
I'll give it a go this week. Will also set up the auto-deployment in Vercel & set up a Firebase

Hey all! left some review comments.
Also, following the instructions, I get this when clicking "allow notification" (after accepting it in my browser/installed pwa)

Any ideas on what I might be doing wrong?

I think this is ready for a first merge.
I'm gonna create a branch "deployed-demo", where I'll branch from main and will use a Sepolia Contract so it works... until we firgure out next steps. It'll be connected to the BG's Vercel (something like pwa-demo.buidlguidl.com)
Thanks @technophile-04 & @Pabl0cks !


modules/sshd: print the offending keys when we detect duplicate sshd config keys.

Description of changes
Follow-up to #231467, print the offending keys when we detect them to make it easier to correct them.
Ping @teto
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] 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.05 Release Notes (or backporting 22.11 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

[x] Fits CONTRIBUTING.md.

for easier visibility, thats how an error may look like:
       Failed assertions:
       - Duplicate sshd config key; does your capitalization match the option's? Duplicate keys: (KbdInteractiveAuthentication, kbdInteractiveAuthentication), (PasswordAuthentication, passwordAuthentication)
(use '--show-trace' to show detailed location information)

@RaitoBezarius it may be good to merge this and backport it to 23.05 before the release, since the current behaviour on the release branch is pretty confusing.

I've just tested it and it seems to work. Thanks a lot.
The ideal scenarii would be:

that openssh REALLY checks its config
that we modify the module to standardize the case, sadly the issue was raised too close to the release process so this change will do.


[Feature]: Open options with macro (slash command)

Describe the feature
AdiBags had /adibags for opening the options, handy for making a macro to quickly open the options (and the custom filters). I can't find any working slash command for BetterBags and I miss that nifty little feature :)
Describe the implementation
Slash command /betterbags should open the options pane.

/bb
:)


fix: update default playwright test case for lib-project

Summary
When you create a Library project with playwrite using create-svelte,  the default test case fails because the content of the H1 in a new Library project is different.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[ ] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

[ ] Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

Thanks! Can you generate a fix changeset before we merge it?

I wonder if we need this level of differentiation. Maybe it'd be simpler to just have them both say "Welcome to your new project" or to test some other attribute on the page or something

@eltigerchino @benmccann
Hi thanks for checking the PR!
Added the changeset but I could also do what @benmccann said.
Open to any suggestions😄

You'll need to lint and format the project too. The lint check is currently failing.

@eltigerchino
my bad! Formatted the code!
CI / test-kit (18, ubuntu-latest, chromium) (pull_request) has failed for some reason tho.....


[Feature]: Crates.io package

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe.
Trying to use Milvus from a Rust service
Describe the solution you'd like.
Is this package going to be available on Crates.io? Trying to use this from a Rust service.
Describe an alternate solution.
No response
Anything else? (Additional Context)
No response

I see that the "milvus" crate is owned by @andreytkachenko here. The API looks surprisingly similar, is this project a fork of it? Perhaps we could get them in sync?

I see that the "milvus" crate is owned by @andreytkachenko here. The API looks surprisingly similar, is this project a fork of it? Perhaps we could get them in sync?

Yep I thought andrey is one of the contributor of milvus rust SDKs.
Once the SDK finally went to public we should keep everything in sync.

Ah, I see that now, sorry, just trying out this lib for the first time. I was just quite confused because the crate links back to his repo which is on 0.2.0 while the code here is 0.1.0.

The crate package has been published, you could use it with cargo add milvus-sdk-rust


closes #585 - Emoji picker should have KodaDot colors

Thank you for your contribution to the KodaDot NFT gallery.
Let's do a quick check before the merge.
Your contribution will be an eternal part of the community codebase
Before submitting this PR, please make sure:

[ ] Code builds clean without any errors or warnings
[ ] I've merged recent default branch -- main and I've no conflicts
[ ] I didn't break any original functionality

Optional

[ ] I've tested it on mobile and everything works

PR type

[ ] Bugfix
[ ] Feature
[ ] Refactoring

What's new? (maybe part of changelog)

closes #<issue_number> - <Brief_description_how_you_fixed_it>

If issue contains bounty label ($,$$,$$$)

Your KSM address: <Kusama_address>

Community participation

[ ] Are you at KodaDot Discord? If no, let's join us - https://discord.gg/35hzy2dXXh

Screenshot

[ ] Whenever your fix will change something on UI, a screenshot is more than welcome

closes #585

@monstar1995 let's DM me on Discord