Need sample for Blob Storage lifecycle management

Query/Question
Is manage Azure Blob Storage lifecycle policy supported by DotNet SDK? If yes, can you please provide a how to sample.
Environment:

Name and version of the Library package used: [Azure.Storage.Blobs 12.7.0]
Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): Windows 10 .NET Core 3.1
IDE and version : [eVisual Studio 16.8.3]

Thank you for your feedback.  Tagging and routing to the team best able to assist.  Please be aware that due to the holidays, responses may be delayed.

Thank you for your feedback.  Tagging and routing to the team best able to assist.  Please be aware that due to the holidays, responses may be delayed.

Just for reference are you referring to
https://azure.microsoft.com/en-us/blog/azure-blob-storage-lifecycle-management-now-generally-available/
https://docs.microsoft.com/en-us/azure/storage/blobs/storage-lifecycle-management-concepts?tabs=azure-portal ?
Looks like creating management policies through the management plane storage SDK.
@blueww is there a feature like this in the management storage SDK or is there a sample available?

Just for reference are you referring to
https://azure.microsoft.com/en-us/blog/azure-blob-storage-lifecycle-management-now-generally-available/
https://docs.microsoft.com/en-us/azure/storage/blobs/storage-lifecycle-management-concepts?tabs=azure-portal ?
Looks like creating management policies through the management plane storage SDK.
@blueww is there a feature like this in the management storage SDK or is there a sample available?

Correct i am looking for sample on how to use DotNet Storage SDK for storage lifecycle management

Correct i am looking for sample on how to use DotNet Storage SDK for storage lifecycle management

I seems found it: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Microsoft.Azure.Management.Storage/src/Generated/Models/ManagementPolicyBaseBlob.cs

I seems found it: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Microsoft.Azure.Management.Storage/src/Generated/Models/ManagementPolicyBaseBlob.cs


Please, edit SubRegion to SubRegion.EasternEurope for Croatia

https://github.com/nager/Nager.Country/tree/master/src/Nager.Country/CountryInfos/CroatiaCountryInfo.cs
Please, change SubRegion to SubRegion.EasternEurope for Croatia.

Okay mledoze have also changes the subregions
https://github.com/mledoze/countries/commit/a04e0d64474443d980048ff5a06bb9b447b60042


Option for Active Background Sync

A similar app for Wear OS is able to consistently synchronize battery percentage/status, etc for its complications/tiles, using background processes from the mobile (phone) app counterpart (that relies on the Android's "Device & App Notifications" permission). As a result, its watch complications/tiles only update when the phone's companion app in the background signals a status change (like phone charging/discharging) (regardless of Bluetooth connection or Wi-Fi connection between phone and watch), instead of the Wear OS app updating itself at 5-(or so)-minute intervals to check for the phone app's response. This proves to save the watch's battery life, and I would like to see something similar in SimpleWear, for battery status and the whole suite (hotspot enabled, flashlight on/off, do not disturb status, etc), especially considering that when I'm using the tiles sometimes, it gets stuck at this screen only until the next interval or I hit the reload button:

I should not have to do that, and it defeats the purpose of a "shortcut" that is the tile. It's just rather annoying.
Watch: Google Pixel Watch 3 LTE (45mm)
Wear OS version: 5
Watch app version: 1.15.4
Phone: Motorola Edge 40 Pro
Phone Android version: 14
Phone app version: 1.15.3

@thewizrd Any update on this issue?


ci: Add req to toml file

What was the problem/requirement? (What/Why)
Integ could not run due to not having pytest
What was the solution? (How)
Add req to toml file so integ could run sucessfully
What is the impact of this change?
We have integ test for JA
How was this change tested?
./pipeline/integ.sh
Was this change documented?
NA
Is this a breaking change?
No

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Can we please put more details into the PR description? It will help all users what we are adding.


Not accurate prop type for Marker component

In the current code the type of coordinates prop is set to Array and this is not correct. Why?
Mapbox-gl is accepting for marker coordinates a LngLatLike object, which is described as ‘an array of two numbers representing longitude and latitude, or an object with lng and lat or lon and lat properties.’ (cited from https://docs.mapbox.com/mapbox-gl-js/api/geography/#lnglatlike)
That mean that v-mapbox code is a far more restricting than the library it is using. This forces us, developers, to convert an object to an array, i.e. to use more primitive attributes than can be used. Especially in the case of longitude and latitude it is error prone – you can easily misorder the coordinates and use [latitude, longitude] instead of [longitude, latitude] (I’ve almost trained myself to check that other location immediately when my markers are not present – then started to use objects instead of arrays every time  it is possible :-) ).

I'm not sure about this. We should support both if we can. When it comes to working with LngLat, it's easy to mix it up. Especially if you wrote application logic that uses the other order arround.
At the same time, I dont think it makes sense to send in an object as a prop.
Instead, it would make more sense to send two props, lat and long, and have prop validation that ensures both are provided.

@Maker-Mark , the point is that mapgox-gl is already accepting LngLatLike object and also v-mapbox is working correctly passing an LngLatLike object. The only issue is that an error message in shown in the developer console – ‘you are passing an object, but an array is expected’, etc.
An array with two numbers, longitude and latitude, is also a valid value for LngLatLike object. See the source code
export type LngLatLike = LngLat | {lng: number, lat: number} | {lon: number, lat: number} | [number, number];

Is this in harmony with your words ‘we should support both’?

@karol-bujacek Ahh you're right. We just need to expect a lat lon like type. Not sure where that would go in this repo.


[Minor] Correct LogisticRegression test case for probability2prediction.

What changes were proposed in this pull request?
Set correct column names for force to use probability2prediction in LogisticRegressionSuite.
How was this patch tested?
Change unit test.

Test build #70921 has started for PR 16477 at commit f825a89.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70921/
Test PASSed.

LGTM

Merged into master, thanks for all your reviews.


Make README more newbie friendly

Not sure how to test to see if this link behaves properly...

Note that I omitted one book for the purpose of eliminating one extra scroll.

Happy to make tweaks based on your feedback, @speric.
Already received feedback from a friend that this is not intended to be run within irb. However, it is indeed useful to see if it is working, so perhaps we can include both. Again, focusing on step-by-step for a newbie.

Thanks, @ddfreyne! Will come back to this tomorrow after some sleep.

Removed [WIP]. This is ready for final review.

Please walk me through resolving this merge conflict.

I can help you out later.

Hi @speric, should I stop working on this PR and close it? Looks like the README is getting updated in parallel in master and I am not sure if the changes in my PR are for nought.

@opensourcegrrrl I made a few changes in the app itself that necessitated updating the README. This work had begun before you opened your PR. I'm sorry that there's now a merge conflict with your branch, but I couldn't release a new version of the gem without documenting the changes, as they were breaking changes.
Anyway, it's up to you if you want to rebase and work on the new README or not. I don't want to give you work to do, but neither do I want to discourage you from doing something you want to do!
I also would like to say that I appreciated your changes and the direction you were going. I did not realize until recently that many people use this gem who don't write Ruby, and I assumed too much familiarity with Ruby in the README.
I am going to make further changes to the README in the next day or two that are directly influenced by this PR. Specifically, I liked the way you moved explanations of what each method does, and what it returns, out of a comment within the Markdown code block. It reads better than the way I had it. Also, I now capture one of the mysterious errors you mentioned in another issue, and print out a readable explanation of what happened. In a future change to the README I will document how to work around that error.
So, thank you!

@speric Ok, great. If you can wrap up your changes by Sat night, say, I can hopefully incorporate all of the feedback from Denis by Sunday night Berlin time. If not, that is okay too.
Kinda want to wrap things up as "good enough" before heading on vacation to China for about ten days. I anticipate not being on my ’puter as much, and my internet connections are likely to be spotty.
Also, I can easily just create a new branch after your changes, and thereby forego dealing with merge conflicts. :)

Update: I have a healing fractured hand, and will need to revisit this in May. If you don't mind, please just keep this open so I can come back to it.

@opensourcegrrrl I am going to close this for now; feel free to re-open it in the future.

Yeah, no problem. Will need to come back to this due to priorities. Thanks for the note!


Resolves #186, #191

I have not forgotten about this. I'm just very busy recently.

Codecov Report

Merging #231 into master will increase coverage by 0.3%.
The diff coverage is 92.59%.

@@            Coverage Diff            @@
##           master     #231     +/-   ##
=========================================
+ Coverage   84.92%   85.23%   +0.3%
=========================================
  Files          33       32      -1
  Lines        4862     4076    -786
=========================================
- Hits         4129     3474    -655
+ Misses        733      602    -131

Thank you for updating.


Change data file formats to xml or json

The reason is two-fold:

XML/json is more standard
We can get better error messages when parsing fails

Stats for the largest file: settings
19k - proto file
26k pretty compact xml (n instead of name, f instead of field, tab instead of 2 spaces etc)
19k - pretty compact json
(12k - compact json)
Solution: json is our text format of choice.

json is beeing written and read now.  binary file is also written as a backup for when/if the json filing fails


Update vsvars.cmd

In this version, we added an echo statement to give some output to the console, and we also set a new environment variable called MY_VAR with the value my_value. We also added a new path to the PATH environment variable.

Changes not needed.  Please don't spam us with PRs


feat: support docker

Add support for Docker

@technikhil314 Please kindly check this PR. It will enable the offline-diff-viewer to run as a container-based application.

Just trying to understand the use case here. Isnt just going to site and seeing the diff there more easy and convenient? @muhammad-asn

Just trying to understand the use case here. Isnt just going to site and seeing the diff there more easy and convenient? @muhammad-asn

I think It will help if someone want to deploy (self-hosted) using containerization.


pipenv install: TypeError: 'NoneType' object is not callable

Issue description
We had 2 pipeline runs using the same settings within a timeframe of 30 minutes. The first run went fine while the second failed suddenly. Turns out that in the meantime the new version 2021.11.5 was released.
After pinning pipenv to 2021.5.29 it works again.
Expected result
All packages got installed.
Actual result
$ python3 --version
Python 3.8.10
$ pip3 install pipenv && pipenv install --system --deploy
Collecting pipenv
  Downloading pipenv-2021.11.5-py2.py3-none-any.whl (3.9 MB)
Collecting virtualenv
  Downloading virtualenv-20.10.0-py2.py3-none-any.whl (5.6 MB)
Requirement already satisfied: setuptools>=36.2.1 in /usr/lib/python3/dist-packages (from pipenv) (45.2.0)
Collecting virtualenv-clone>=0.2.5
  Downloading virtualenv_clone-0.5.7-py3-none-any.whl (6.6 kB)
Requirement already satisfied: pip>=18.0 in /usr/lib/python3/dist-packages (from pipenv) (20.0.2)
Collecting certifi
  Downloading certifi-2021.10.8-py2.py3-none-any.whl (149 kB)
Collecting filelock<4,>=3.2
  Downloading filelock-3.3.2-py3-none-any.whl (9.7 kB)
Collecting backports.entry-points-selectable>=1.0.4
  Downloading backports.entry_points_selectable-1.1.0-py2.py3-none-any.whl (6.2 kB)
Collecting distlib<1,>=0.3.1
  Downloading distlib-0.3.3-py2.py3-none-any.whl (496 kB)
Collecting platformdirs<3,>=2
  Downloading platformdirs-2.4.0-py3-none-any.whl (14 kB)
Collecting six<2,>=1.9.0
  Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
Installing collected packages: filelock, backports.entry-points-selectable, distlib, platformdirs, six, virtualenv, virtualenv-clone, certifi, pipenv
Successfully installed backports.entry-points-selectable-1.1.0 certifi-2021.10.8 distlib-0.3.3 filelock-3.3.2 pipenv-2021.11.5 platformdirs-2.4.0 six-1.16.0 virtualenv-20.10.0 virtualenv-clone-0.5.7
/usr/share/python-wheels/requests-2.22.0-py2.py3-none-any.whl/requests/__init__.py:89: RequestsDependencyWarning: urllib3 (1.26.6) or chardet (3.0.4) doesn't match a supported version!
Installing dependencies from Pipfile.lock (5264b9)...
Traceback (most recent call last):
  File "/usr/local/bin/pipenv", line 8, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 1137, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 1062, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 1668, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 763, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/decorators.py", line 84, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 763, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/cli/command.py", line 220, in install
    do_install(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 1991, in do_install
    do_init(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 1255, in do_init
    do_install_dependencies(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 818, in do_install_dependencies
    batch_install(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 725, in batch_install
    c = pip_install(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 1427, in pip_install
    r = write_requirement_to_file(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 1359, in write_requirement_to_file
    line = requirement.line_instance.get_line(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 2553, in line_instance
    self.line_instance = self.get_line_instance()
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 2547, in get_line_instance
    return Line(line)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 171, in __init__
    self.parse()
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 1289, in parse
    self.parse_extras()
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 577, in parse_extras
    self.line, extras = pip_shims.shims._strip_extras(self.line)
TypeError: 'NoneType' object is not callable

Steps to replicate
$ pipenv --support
Pipenv version: '2021.11.5'
Pipenv location: '/usr/local/lib/python3.8/dist-packages/pipenv'
Python location: '/usr/bin/python3'
Python installations found:

3.8.10: /usr/bin/python3
3.8.10: /usr/bin/python3.8
3.8.10: /bin/python3
3.8.10: /bin/python3.8

PEP 508 Information:
{'implementation_name': 'cpython',
 'implementation_version': '3.8.10',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.18.0-305.19.1.el8_4.x86_64',
 'platform_system': 'Linux',
 'platform_version': '#1 SMP Tue Sep 7 07:07:31 EDT 2021',
 'python_full_version': '3.8.10',
 'python_version': '3.8',
 'sys_platform': 'linux'}

System environment variables:

KUBERNETES_SERVICE_PORT_HTTPS
CI_PROJECT_NAMESPACE
GITLAB_USER_ID
SAST_EXCLUDED_ANALYZERS
CI_RUNNER_VERSION
KEY_VAULT_ID
FF_SKIP_NOOP_BUILD_STAGES
KUBERNETES_SERVICE_PORT
CI_SERVER_NAME
CI_RUNNER_DESCRIPTION
GITLAB_USER_EMAIL
PWC_CA_BUNDLE
CI_SERVER_REVISION
FF_USE_WINDOWS_LEGACY_PROCESS_STRATEGY
CI_RUNNER_EXECUTABLE_ARCH
CI_REGISTRY_USER
CI_REGISTRY_PASSWORD
CI_API_V4_URL
CI_RUNNER_SHORT_TOKEN
CI_JOB_NAME
LOG_LEVEL
HOSTNAME
GITLAB_USER_LOGIN
FF_SKIP_DOCKER_MACHINE_PROVISION_ON_CREATION_FAILURE
CI_PROJECT_NAME
CI_PIPELINE_SOURCE
CI_BUILD_REF_NAME
DS_DEFAULT_ANALYZERS
CI_JOB_STATUS
CI_PIPELINE_ID
CI_BUILD_REF_SLUG
CI_COMMIT_REF_SLUG
CI_SERVER
SECRETS_ANALYZER_VERSION
SAST_SEMGREP_METRICS
FF_GITLAB_REGISTRY_HELPER_IMAGE
CI_COMMIT_SHORT_SHA
FF_CMD_DISABLE_DELAYED_ERROR_LEVEL_EXPANSION
CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX
SECRET_DETECTION_EXCLUDED_PATHS
PWD
CI_RUNNER_TAGS
CI_PROJECT_PATH
FF_USE_NEW_BASH_EVAL_STRATEGY
DS_EXCLUDED_PATHS
CI_SERVER_TLS_CA_FILE
CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX
ADDITIONAL_CA_CERT_BUNDLE
DS_MAJOR_VERSION
CI_COMMIT_REF_PROTECTED
FF_USE_POWERSHELL_PATH_RESOLVER
VAULT_CACERT
CI_SERVER_VERSION_MINOR
CI_COMMIT_SHA
HOME
FF_NETWORK_PER_BUILD
KEY_NAME
CI_DEPENDENCY_PROXY_PASSWORD
KUBERNETES_PORT_443_TCP
CI_PROJECT_VISIBILITY
CI_CONCURRENT_PROJECT_ID
CI_COMMIT_MESSAGE
SECURE_ANALYZERS_PREFIX
CI_BUILD_NAME
FF_USE_DIRECT_DOWNLOAD
CI_SERVER_VERSION
CI_REGISTRY
CI_SERVER_PORT
CUSTOMER_USER_EMAIL
CI_PIPELINE_IID
CI_REPOSITORY_URL
CI_SERVER_URL
FF_ENABLE_BASH_EXIT_CODE_CHECK
GITLAB_FEATURES
CI_COMMIT_DESCRIPTION
CI_JOB_STAGE
CI_PIPELINE_URL
CI_DEFAULT_BRANCH
CI_BUILD_REF
SCAN_KUBERNETES_MANIFESTS
CI_SERVER_VERSION_PATCH
CI_COMMIT_TITLE
VAULT_ADDR
CI_PROJECT_ROOT_NAMESPACE
ENVIRONMENT
LICENSE_MANAGEMENT_SETUP_CMD
GITLAB_USER_NAME
CI_PROJECT_DIR
SHLVL
CI_RUNNER_ID
CI_PIPELINE_CREATED_AT
CI_COMMIT_TIMESTAMP
CI_DISPOSABLE_ENVIRONMENT
CI_JOB_JWT
KUBERNETES_PORT_443_TCP_PROTO
CI_BUILD_ID
DS_EXCLUDED_ANALYZERS
CI_SERVER_PROTOCOL
CI_COMMIT_AUTHOR
KUBERNETES_PORT_443_TCP_ADDR
CI_COMMIT_REF_NAME
CI_SERVER_HOST
CI_JOB_URL
CI_JOB_TOKEN
SAST_EXCLUDED_PATHS
CI_JOB_STARTED_AT
CI_CONCURRENT_ID
CI_BUILD_TOKEN
CI_COMMIT_BRANCH
CI_PROJECT_CLASSIFICATION_LABEL
FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY
CI_RUNNER_REVISION
LICENSE_MANAGEMENT_VERSION
CI_BUILD_BEFORE_SHA
CI_DEPENDENCY_PROXY_USER
FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR
CI_PROJECT_PATH_SLUG
CI_NODE_TOTAL
KUBERNETES_SERVICE_HOST
KUBERNETES_PORT
KUBERNETES_PORT_443_TCP_PORT
CI_BUILDS_DIR
CI_JOB_ID
CI_PROJECT_REPOSITORY_LANGUAGES
PATH
CI_PROJECT_ID
CI
GITLAB_CI
CI_JOB_IMAGE
CI_COMMIT_BEFORE_SHA
CI_PROJECT_TITLE
CI_SERVER_VERSION_MAJOR
VAULT_NAMESPACE
CI_CONFIG_PATH
FF_USE_FASTZIP
CI_BUILD_STAGE
CI_DEPENDENCY_PROXY_SERVER
KEY_LENGTH
ACTION
CI_PROJECT_URL
OLDPWD
_
LC_CTYPE
PIP_SHIMS_BASE_MODULE
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONDONTWRITEBYTECODE
PIP_PYTHON_PATH
PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenv–specific environment variables:
Debug–specific environment variables:

PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD: /builds/VqLQkzTA/4/pwc-de/team-the-forge/cloud-melter/cloud-melter-key-management

Contents of Pipfile ('/builds/VqLQkzTA/4/pwc-de/team-the-forge/cloud-melter/cloud-melter-key-management/Pipfile'):
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"
[packages]
requests = "*"
python-slugify = "*"
hvac = "*"
logging-formatter-anticrlf = "*"
[dev-packages]
[requires]
python_version = "3.8"

Contents of Pipfile.lock ('/builds/VqLQkzTA/4/pwc-de/team-the-forge/cloud-melter/cloud-melter-key-management/Pipfile.lock'):
{
    "_meta": {
        "hash": {
            "sha256": "259c38054ef2e2340e283cee83b35e947651d969a2f2f3ceff5814a3365264b9"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.8"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.python.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "certifi": {
            "hashes": [
                "sha256:78884e7c1d4b00ce3cea67b44566851c4343c120abd683433ce934a68ea58872",
                "sha256:d62a0163eb4c2344ac042ab2bdf75399a71a2d8c7d47eac2e2ee91b9d6339569"
            ],
            "version": "==2021.10.8"
        },
        "charset-normalizer": {
            "hashes": [
                "sha256:e019de665e2bcf9c2b64e2e5aa025fa991da8720daa3c1138cadd2fd1856aed0",
                "sha256:f7af805c321bfa1ce6714c51f254e0d5bb5e5834039bc17db7ebe3a4cec9492b"
            ],
            "markers": "python_version >= '3'",
            "version": "==2.0.7"
        },
        "hvac": {
            "hashes": [
                "sha256:3e8a34804b1e20954a2b4991cc13ed9c09b32e50dadd9d3438224481150f6568",
                "sha256:f905c59d32d88d3f67571fe5a8a78de4659e04798ad809de439f667247d13626"
            ],
            "index": "pypi",
            "version": "==0.11.2"
        },
        "idna": {
            "hashes": [
                "sha256:84d9dd047ffa80596e0f246e2eab0b391788b0503584e8945f2368256d2735ff",
                "sha256:9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"
            ],
            "markers": "python_version >= '3'",
            "version": "==3.3"
        },
        "logging-formatter-anticrlf": {
            "hashes": [
                "sha256:1d5b9b208938d637263d4d40f7841aa84164fd3fa128b633df55602c04fba60b"
            ],
            "index": "pypi",
            "version": "==1.2"
        },
        "python-slugify": {
            "hashes": [
                "sha256:6d8c5df75cd4a7c3a2d21e257633de53f52ab0265cd2d1dc62a730e8194a7380",
                "sha256:f13383a0b9fcbe649a1892b9c8eb4f8eab1d6d84b84bb7a624317afa98159cab"
            ],
            "index": "pypi",
            "version": "==5.0.2"
        },
        "requests": {
            "hashes": [
                "sha256:6c1246513ecd5ecd4528a0906f910e8f0f9c6b8ec72030dc9fd154dc1a6efd24",
                "sha256:b8aa58f8cf793ffd8782d3d8cb19e66ef36f7aba4353eec859e74678b01b07a7"
            ],
            "index": "pypi",
            "version": "==2.26.0"
        },
        "six": {
            "hashes": [
                "sha256:1e61c37477a1626458e36f7b1d82aa5c9b094fa4802892072e49de9c60c4c926",
                "sha256:8abb2f1d86890a2dfb989f9a77cfcfd3e47c2a354b01111771326f8aa26e0254"
            ],
            "markers": "python_version >= '2.7' and python_version not in '3.0, 3.1, 3.2, 3.3'",
            "version": "==1.16.0"
        },
        "text-unidecode": {
            "hashes": [
                "sha256:1311f10e8b895935241623731c2ba64f4c455287888b18189350b67134a822e8",
                "sha256:bad6603bb14d279193107714b288be206cac565dfa49aa5b105294dd5c4aab93"
            ],
            "version": "==1.3"
        },
        "urllib3": {
            "hashes": [
                "sha256:4987c65554f7a2dbf30c18fd48778ef124af6fab771a377103da0585e2336ece",
                "sha256:c4fdf4019605b6e5423637e01bc9fe4daef873709a7973e195ceba0a62bbc844"
            ],
            "markers": "python_version >= '2.7' and python_version not in '3.0, 3.1, 3.2, 3.3, 3.4' and python_version < '4'",
            "version": "==1.26.7"
        }
    },
    "develop": {}
}

Still seeing this bug in the most recent release:
pipenv install
/usr/share/python-wheels/requests-2.22.0-py2.py3-none-any.whl/requests/__init__.py:89: RequestsDependencyWarning: urllib3 (1.26.6) or chardet (3.0.4) doesn't match a supported version!
Installing dependencies from Pipfile.lock (459de7)...
Traceback (most recent call last):▉▉▉▉▉ 0/25 — 00:00:00
  File "/usr/local/bin/pipenv", line 8, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 1137, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 1062, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 1668, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 763, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/decorators.py", line 84, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/click/core.py", line 763, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/cli/command.py", line 220, in install
    do_install(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 1991, in do_install
    do_init(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 1255, in do_init
    do_install_dependencies(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 818, in do_install_dependencies
    batch_install(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 725, in batch_install
    c = pip_install(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 1427, in pip_install
    r = write_requirement_to_file(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/core.py", line 1359, in write_requirement_to_file
    line = requirement.line_instance.get_line(
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 2553, in line_instance
    self.line_instance = self.get_line_instance()
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 2547, in get_line_instance
    return Line(line)
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 171, in __init__
    self.parse()
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 1289, in parse
    self.parse_extras()
  File "/usr/local/lib/python3.8/dist-packages/pipenv/vendor/requirementslib/models/requirements.py", line 577, in parse_extras
    self.line, extras = pip_shims.shims._strip_extras(self.line)
TypeError: 'NoneType' object is not callable

user@ip-XXX-XXX-XXX-XXX ~/etl-process
 % pipenv --version
/usr/share/python-wheels/requests-2.22.0-py2.py3-none-any.whl/requests/__init__.py:89: RequestsDependencyWarning: urllib3 (1.26.6) or chardet (3.0.4) doesn't match a supported version!
pipenv, version 2021.11.5.post0

Having the same issue

Also had this issue (in our GH actions flow) and just fixed it like @RolandColored mentioned (pinning the previous version):
    - name: Install pipenv
      uses: dschep/install-pipenv-action@v1
      with:
        version: 2021.5.29

Yeah that's what I reverted to as well.

Having the same issue. With version 2021.5.29 it works

Just had the same issue with CircleCI and environment caching. In our case we had to change our cache key combined with pinning version to 2021.5.29 to reset the cache:
- save_cache:
    key: deps-v2021-11-18-{{ .Branch }}-{{ checksum "Pipfile.lock" }}

- save_cache:
    key: deps-{{ .Branch }}-{{ checksum "Pipfile.lock" }}

Or you can explicitly uninstall pipenv without altering your cache key:
command: |
	sudo pip install pipenv
	pipenv install --dev --deploy

command: |
	sudo pip uninstall pipenv -y
	sudo pip install pipenv==2021.5.29
	pipenv install --dev --deploy

This is still an issue: https://app.netlify.com/sites/fastlane-docs-preview/deploys/6198c31ed708b60781875373.

Cross referencing an issue in the Netlify support forum, for which this seems to be the root cause https://answers.netlify.com/t/issues-with-netlify-python-requests/48018

this seems to happen again in the latest version 2022.4.20 which was released earlier today

I got same problem using version 2022.4.20 and using python3.6 in Ubuntu18.04.
but the problem did not happen both of following case

using version 2022.4.8 and using python3.6
using version 2022.4.20 and using python3.8

Python 3.6 support was dropped.  We missed the setup.py which is why it thinks that it's fine release for python 3.6 but it's not because pip dropped support and we vendored in the latest pip.  So we drop support too.  Python 3.6 was EOL 6 months ago.

Thank you for your reply.
I got it.
Then, which python version does the Pipenv support now?
README.md says "v3.6 or above". it may be old information.
https://github.com/pypa/pipenv#installation
Pipenv can be installed with Python 3.6 and above.

In my app-test-buildspec.yml file, we had a config like below. One of the commands is pip install --upgrade pip pipenv and I have changed it to pip install 'pipenv==2021.5.29' as instructed above. It works well on the DEV stack but for some reasons the QA stack is still using the latest pipenv. Does anyone know what did I miss?
phases:
pre_build:
commands:
- pip install --upgrade pip pipenv


New Julia benchmark

First, you might want to benchmark Julia on master as is (or possibly next nightly, I just noticed yet one more improvement merged just now "Remove alloca from codegen").
I don't know if the issue with your very unusual benchmark is fixed. But Julia does use -O2 by default so you might also want to try running with -O0 (or --inline=no that I think is at least implied by the lowest level) or -O1, since there is no Julia debug/development-build  mode, and that's the closest I can think of; Or even with --compile=min
At least if you see an improvement, there's also a further 25% improvement available (but you have to opt into this new Julia parser, it will be merged into Julia, but then also at first off by default):
https://github.com/JuliaLang/JuliaSyntax.jl/pull/228
I also wanted to point that out for you for D (or other) language.

I reran with Julia master and got:
| Lang-uage | Temp-lated | Check Time [us/fn] | Compile Time [us/fn] | Build Time [us/fn] | Run Time [us/fn] | Check RSS [kB/fn] | Build RSS [kB/fn] | Exec Version | Exec Path |
| :-------: | ---------- | :----------------: | :------------------: | :----------------: | :--------------: | :---------------: | :---------------: | :----------: | :-------: |
| D         | No         |    7.6 (3.7x)      |   17.1 (10.7x)       |   21.2 (12.0x)     |     78 (4.0x)    |    4.4 (9.8x)     |   13.4 (30.1x)    | v2.103.0-rc.1-87-g7e84fb3333-dirty | dmd       |
| D         | No         |    5.0 (2.4x)      |   91.6 (57.1x)       |   92.4 (52.4x)     |    325 (16.6x)   |    4.8 (10.7x)    |   19.8 (44.3x)    | 1.30.0       | ldmd2     |
| D         | No         |    7.3 (3.5x)      |  232.8 (145.2x)      |  231.3 (131.0x)    |     64 (3.2x)    |    4.6 (10.3x)    |   19.2 (43.1x)    | 11.3.0       | gdc       |
| D         | Yes        |   19.9 (9.6x)      |   32.2 (20.1x)       |   36.0 (20.4x)     |     49 (2.5x)    |   12.6 (27.8x)    |   22.0 (49.4x)    | v2.103.0-rc.1-87-g7e84fb3333-dirty | dmd       |
| D         | Yes        |   10.5 (5.1x)      |   97.7 (61.0x)       |  100.0 (56.7x)     |    272 (13.9x)   |   12.9 (28.6x)    |   28.9 (64.8x)    | 1.30.0       | ldmd2     |
| D         | Yes        |   13.3 (6.5x)      |  244.7 (152.7x)      |  241.7 (136.9x)    |     62 (3.1x)    |   13.4 (29.6x)    |   28.8 (64.6x)    | 11.3.0       | gdc       |
| C         | No         |    2.1 (best)      |    1.6 (best)        |    1.8 (best)      |     20 (best)    |    0.5 (best)     |    0.4 (best)     | 0.9.27       | tcc       |
| C         | No         |    9.4 (4.6x)      |  293.4 (183.1x)      |  303.0 (171.6x)    |     36 (1.9x)    |    2.7 (6.0x)     |   13.6 (30.6x)    | 12.1.0       | gcc       |
| C         | No         |    5.9 (2.9x)      |  207.8 (129.7x)      |  203.7 (115.4x)    |     60 (3.1x)    |    2.7 (6.1x)     |   14.2 (31.7x)    | 9.5.0        | gcc-9     |
| C         | No         |    6.1 (3.0x)      |  217.8 (135.9x)      |  219.4 (124.3x)    |     37 (1.9x)    |    2.7 (6.1x)     |   14.2 (31.8x)    | 10.4.0       | gcc-10    |
| C         | No         |    6.7 (3.3x)      |  228.2 (142.4x)      |  221.2 (125.3x)    |     38 (1.9x)    |    2.6 (5.9x)     |   14.1 (31.7x)    | 11.3.0       | gcc-11    |
| C         | No         |   10.1 (4.9x)      |  298.7 (186.4x)      |  299.2 (169.5x)    |     23 (1.1x)    |    2.8 (6.2x)     |   13.6 (30.6x)    | 12.1.0       | gcc-12    |
| C         | No         |   18.1 (8.8x)      |  119.7 (74.7x)       |  120.6 (68.3x)     |    612 (31.2x)   |    2.1 (4.6x)     | sampling error    | 14.0.0-1     | clang     |
| C         | No         |   18.1 (8.8x)      |  115.6 (72.1x)       |  118.6 (67.2x)     |    545 (27.8x)   |    2.1 (4.6x)     |    9.4 (21.1x)    | 14.0.0-1     | clang-14  |
| C++       | No         |   14.3 (7.0x)      |  233.5 (145.7x)      |  233.9 (132.5x)    |     38 (1.9x)    |    4.4 (9.7x)     |   14.0 (31.5x)    | 11.3.0       | g++       |
| C++       | No         |   14.3 (6.9x)      |  229.4 (143.1x)      |  232.4 (131.7x)    |     34 (1.7x)    |    4.4 (9.7x)     |   14.1 (31.5x)    | 10.4.0       | g++-10    |
| C++       | No         |   14.1 (6.8x)      |  228.5 (142.6x)      |  236.8 (134.1x)    |     37 (1.9x)    |    4.4 (9.7x)     |   14.0 (31.5x)    | 11.3.0       | g++-11    |
| C++       | No         |   23.1 (11.2x)     |  315.3 (196.8x)      |  318.3 (180.3x)    |     65 (3.3x)    | sampling error    |   16.4 (36.8x)    | 12.1.0       | g++-12    |
| C++       | No         |   26.0 (12.6x)     |  128.9 (80.4x)       |  127.9 (72.5x)     |    541 (27.6x)   |    2.2 (4.8x)     |    9.4 (21.1x)    | 14.0.0-1     | clang     |
| C++       | No         |   25.2 (12.2x)     |  129.4 (80.7x)       |  132.7 (75.2x)     |    541 (27.6x)   |    2.2 (4.8x)     |    9.4 (21.1x)    | 14.0.0-1     | clang-14  |
| C++       | Yes        |   30.5 (14.8x)     |  278.3 (173.6x)      |  277.9 (157.5x)    |     28 (1.4x)    |    8.0 (17.7x)    |   20.5 (46.0x)    | 11.3.0       | g++       |
| C++       | Yes        |   30.9 (15.0x)     |  278.2 (173.6x)      |  279.6 (158.4x)    |     27 (1.4x)    |    8.0 (17.6x)    |   21.8 (48.9x)    | 10.4.0       | g++-10    |
| C++       | Yes        |   29.1 (14.1x)     |  281.9 (175.9x)      |  280.7 (159.0x)    |     27 (1.4x)    |    8.0 (17.7x)    |   20.6 (46.1x)    | 11.3.0       | g++-11    |
| C++       | Yes        |   41.7 (20.3x)     |  371.1 (231.6x)      |  366.9 (207.8x)    |     26 (1.3x)    |    8.0 (17.7x)    |   20.6 (46.1x)    | 12.1.0       | g++-12    |
| C++       | Yes        |   40.0 (19.4x)     |  129.5 (80.8x)       |  134.5 (76.2x)     |    381 (19.5x)   |    4.0 (8.8x)     |   12.6 (28.3x)    | 14.0.0-1     | clang     |
| C++       | Yes        |   39.1 (19.0x)     |  132.9 (82.9x)       |  136.4 (77.3x)     |    622 (31.7x)   |    4.0 (8.8x)     |   12.6 (28.3x)    | 14.0.0-1     | clang-14  |
| Ada       | No         |    N/A             |    N/A               |  943.7 (534.7x)    |     68 (3.5x)    |    N/A            |   31.3 (70.2x)    | 12.1.0       | gnat      |
| Ada       | No         |    N/A             |    N/A               |  950.3 (538.4x)    |     69 (3.5x)    |    N/A            |   31.4 (70.3x)    | 12.1.0       | gnat-12   |
| Go        | No         |   16.0 (7.8x)      |    N/A               |    N/A             |    N/A           |    4.0 (8.9x)     |    N/A            | 1.18.3       | gotype    |
| N/A       | N/A        |    N/A             |    N/A               |    N/A             |    N/A           |    6.5 (14.5x)    |   24.3 (54.4x)    | N/A          | N/A       |
| N/A       | N/A        |    N/A             |    N/A               |    N/A             |    N/A           |   11.2 (24.8x)    |   23.5 (52.7x)    | N/A          | N/A       |
| Go        | No         |    N/A             |    N/A               |  166.0 (94.0x)     |    132 (6.7x)    |    N/A            |   28.3 (63.4x)    | 1.18.3       | go        |
| N/A       | N/A        |    N/A             |    N/A               |    N/A             |    N/A           |    N/A            |   18.4 (41.1x)    | N/A          | N/A       |
| N/A       | N/A        |    N/A             |    N/A               |    N/A             |    N/A           |    N/A            |   50.3 (112.8x)   | N/A          | N/A       |
| Zig       | No         |   22.5 (10.9x)     |    N/A               |  531.6 (301.2x)    |   1150 (58.7x)   |    5.6 (12.5x)    |   34.8 (78.1x)    | 0.11.0-dev.2545+311d50f9d | zig       |
| Zig       | Yes        |   27.2 (13.2x)     |    N/A               |  547.6 (310.2x)    |   1123 (57.3x)   |    5.6 (12.5x)    |   35.9 (80.5x)    | 0.11.0-dev.2545+311d50f9d | zig       |
| Rust      | No         |   73.5 (35.7x)     |    N/A               |  230.6 (130.6x)    |   1474 (75.2x)   |   13.6 (30.1x)    |   29.7 (66.6x)    | 1.70.0-nightly | rustc     |
| Rust      | Yes        |   84.9 (41.2x)     |    N/A               |  148.9 (84.4x)     |   1442 (73.6x)   |   15.7 (34.8x)    |   18.6 (41.6x)    | 1.70.0-nightly | rustc     |
| Nim       | No         |   36.7 (17.8x)     |    N/A               |   80.5 (45.6x)     |     66 (3.3x)    |    4.2 (9.3x)     |    8.0 (18.0x)    | 1.4.6        | nim       |
| C#        | No         |    N/A             |    N/A               |   21.6 (12.2x)     |    384 (19.6x)   |    N/A            |    4.4 (9.8x)     | <IP_ADDRESS>   | mcs       |
| N/A       | N/A        |    N/A             |    N/A               |    N/A             |    N/A           |    N/A            |   13.2 (29.6x)    | N/A          | N/A       |
| OCaml     | No         |    N/A             |    N/A               |  445.5 (252.4x)    |    637 (32.5x)   |    N/A            |   34.6 (77.5x)    | 4.13.1       | ocamlopt  |
| OCaml     | No         |    N/A             |    N/A               |   87.6 (49.6x)     |    907 (46.3x)   |    N/A            |   17.7 (39.6x)    | 4.13.1       | ocamlc    |
| Julia     | No         |    N/A             |    N/A               |  410.5 (232.6x)    |    N/A           |    N/A            |   25.6 (57.4x)    | 1.10.0-DEV   | julia     |
| Julia     | Yes        |    N/A             |    N/A               |  335.6 (190.1x)    |    N/A           |    N/A            |   25.4 (56.8x)    | 1.10.0-DEV   | julia     |

Since the script is using --compile=min, then alternatively you could drop it to see if the default is better, or e.g. -O0.
Anyway, it's at least going in the right direction. And 1.8.0-DEV is of course very outdated, and I expect 1.9.0 to be released in a week or so, so it's time for 1.10.0-DEV.

Using -O0 is slower than --compile=min. I checked.

Closing this.

Good to know about -O0 (also slower with the default -O2, or -O1?). You can get 25% faster parsing with JuliaSyntax.jl, but since it likely wasn't the bottleneck (your call to check, or decide to use that non-default option), I guess you can ignore it.

They did fix constprop to be faster, but there's no way to drop that optimization completely. Doing away with it, or all opt, doesn't seem like a priority. Because you don't compile code that often. In Julia 1.9, modules are fully precompiled to assembly.
You could at least update to the latest numbers, as you did in the table above, to the actual readme. I might look into this extra 25% speed, I understand if not a priority for you, not sure it is for me (i.e. for this benchmark).

FYI: I can confirm with JuliaSyntax.jl (it's easy to use, but for the benchmark as is it's needs to be compiled into the sysimage) I get 21% faster.

FYI "Add native UTF-8 Validation using fast shift based DFA #47880" was just merged and it seems 20x faster.
I'm not actually sure if the parser uses it, but instead of looking into it, we can see if the parser gets faster in the next nightly. So you may want to wait with publishing new results. [I only see the new parser calls isvalid for individual Char, not Strings, what would you think Dlang does?]

Hi,
I think you have a long benchmark (or so I recall, maybe only after inlining). I think this might be relevant (to test on when merged to master):
https://github.com/JuliaLang/julia/pull/50756

Can you perform the benchmark yourself?

I can, and did (now that that PR was merged).
I do get 12% improvement over 1.9.2, which is though not the great improvement I was hoping for, nor did the PR help. I.e. I get similar on the beta, where I believe it's not in.
$ juliaup default dev
..
| Lang-uage | Temp-lated | Check Time [us/fn] | Compile Time [us/fn] | Build Time [us/fn] | Run Time [us/fn] | Check RSS [kB/fn] | Build RSS [kB/fn] | Exec Version | Exec Path |
| :-------: | ---------- | :----------------: | :------------------: | :----------------: | :--------------: | :---------------: | :---------------: | :----------: | :-------: |
| Julia     | No         | N/A                | N/A                  |  585.9 (1.2x)      | N/A              | N/A               |   31.9 (1.1x)     | 1.11.0-DEV   | julia     |
| Julia     | Yes        | N/A                | N/A                  |  489.9 (best)      | N/A              | N/A               |   28.8 (best)     | 1.11.0-DEV   | julia     |

vs. 554.7 on 1.9.2. I also trued all settings for JULIA_INTERPRET_FLAGS and JULIA_COMPILE_FLAGS. I.e. defaults are still much slower, though maybe some improvement there too.


CORS fitting not being configured with params in default.yaml

The call to create the CORS object in https://github.com/theganyo/swagger-node-runner/blob/master/fittings/cors.js#L11 passes an object that looks like:
{
  "name": "cors",
  "input": { "some": "params passed in default.yaml" }
}

Changing that line to:
  var middleware = CORS(fittingDef.input);

allows actually passing variables.
WDYT?

Yeah, cool thought. Though it's a breaking change.

@theganyo how is it breaking?
What am I missing?
Is there another way to configure the CORS middleware?

Ah, I see. Sorry. Yes, I think you're right... the intent was to be able to configure it in the yaml, but it seems there should have been tests to verify that.


Allow to override the root-process heuristic

We're using python binaries, but they are packaged into a binary that runs python with the actual python code from itself. Because of that the profiler won't find any process called 'python'. I understand that this is quite a corner case, but would it make sense to allow to override the process name to look for?

Hi @ensonic,
In normal operating mode, the profiler doesn't rely on the process name but on its PID, which it retrieves from the container. Have you tried profiling, and it didn’t work? Perhaps you could try using eBPF to generate a CPU flamegraph.
For my part, I will try a similar scenario with a python binary package.

@ensonic According the error, py-spy is unable to determine that it's a python application. It's unable to profile this (corner) case.

Good to know that the error is coming from py-spy. I'll poke at it.


unable to import into node_modules

hello @simform-solutions, @tejas-ardeshna, @BirjuVachhani, @DevarshRanpara
i cloned this repo, added one line change, and decided to import my repo link to my package.json as the version. but it keeps failing. when i add their repo to the node modules i dont get the folders that contain the components. just package.json and readme file appears.  theres nothing wrong with internet connection or how i added it. ive been doing it for long. is there any other way to do it ??

+1 bump

@quavo19 @seshubonam
Thank you for expressing your interest in this library.
To assist us in investigating the specific issue you encountered, Kindly provide us with the precise steps you followed so that we can investigate this issue further from our end.

sure @dhruv-h-simform,
1 i first forked this repo.
2 then i made my change.
3 and deleted my node_modules from the project and cleaned my yarn-lock and caches.
4 then i added the link to the repo in place of the library version like this
 "react-native-story-view": "https://github.com/quavo19/react-native-story-view.git",

instead of
 "react-native-story-view": "^0.0.3",

5 then i installed the dependecies with yarn
but it didnt work, as i explained what happened earlier

Hello @quavo19
We have done with investigate of your issue and we have found one solution.
If you have forked any library to your GitHub then you need to follow below command as per npm documentation to install forked library as package into your project.
npm install git+https://github.com/user-name/package-name.git

or
yarn add git+https://github.com/user-name/package-name.git

In, your case command would be this
yarn add git+https://github.com/quavo19/react-native-story-view.git

Reference npm documentation:- https://docs.npmjs.com/cli/v9/configuring-npm/package-json#git-urls-as-dependencies
let us know if you have still face this issue.

@dhruv-h-simform

it still doesnt install all the files from my repo, just the readme other unuseful stuff.
i tried with your url but still the same thing

Hello @quavo19
Do one thing. In your forked repository quavo19/react-native-story-view you need to change prepare script in package.json. Just add yarn build after husky install. (husky install & yarn build)
Once changes was done just commit that changes and again install by following steps:

rm -rf node_modules
yarn cache clean
yarn
yarn add git+https://github.com/quavo19/react-native-story-view.git

After adding prepare was look like this,
"scripts": {
    "prepare": "husky install & yarn build",
  }

Please verify and let us know.

hello @dhruv-h-simform, its a mobile app so there is no specific build command, its just the native commands
"android": "react-native run-android",
"ios": "react-native run-ios",
"start": "react-native start",

so for this, the
"prepare": "husky install & yarn start" command keeps failing when i run yarn
as shown below

Hello @quavo19,
Please check again by adding this command to prepare the script husky install && yarn build.
Let us know if it is not working.

Hello @quavo19, Please check again by adding this command to prepare the script husky install && yarn build.
Let us know if it is not working.

@dhruv-h-simform sir, please it did not work .


GIVEAWAY cmd and rep cmd has bug

after giving rep its showing opps error occured but the user got rep
and in giveaway start cmd entering duration in minutes still its showing duration not sprcified
please fix it and in giveaway start cmd add duration in hour and minutes both

Any logs or attachments that can help us investigate?
Feel free to join us at: https://discord.gg/fE75UShbqB

Rep command seems to work.
Can you please elaborate on how we can replicate the error?


add TreeNode.from_linkage/to_linkage methods

The scipy linkage object is returned by the scipy hierarchical clustering methods, so being able to load or generate these from TreeNode's provides the glue between scipy's hierarchical clustering and skbio's TreeNode.
@ebolyen is working on this. @wasade, would you be available to review?

Adding the to_linkage method would be extremely helpful.  For example, it would be really nice to pass a linkage matrix into seaborn.clustermap to align a tree with a heatmap.

Agree, is anyone available to work on to_linkage?

I'll need this for a paper anyways, so I'll probably have something ready within a month.

Awesome! Is it okay if I assign this issue to you?

Sure thing.
On Thu, Aug 11, 2016 at 3:42 PM, Jai Ram Rideout<EMAIL_ADDRESS>wrote:

Awesome! Is it okay if I assign this issue to you?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/biocore/scikit-bio/issues/346#issuecomment-239269210,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD_a3UOWPW5CeO5IcltUBJ475GbpTlW1ks5qe3sOgaJpZM4B67pq
.

This will be really great to get in there.

Hi @gregcaporaso @jairideout .  I've been looking at this more carefully.
It turns out that this is a really hard problem.

The linkage format assumes balanced distances (i.e. the distance between children and their parents are equal), it is not possible to actually encode the branch lengths into the linkage matrix
The encoding isn't very clear - but if I have to guess based on the source code, it looks like there is a reverse post-traversal going on (right node gets traversed first instead of the left node).

Sorry to be the bear of bad news - but it looks like we would lose the branch length information if we cast to this object.  But if we really wanted this, it is probably possible to do this cast by setting all of the distances to 1 or something.  Even with this scheme, it is tricky to figure out how to get the right matrix, given the traversal issue.

@mortonjt, branch lengths can be encoded, and siblings do not have to have identical distances to their parents (except for tips), however the tree does have to be an ultrametric binary tree (strictly bifurcating with every tip being equidistant to the root).
The linkage isn't exactly a reversed depth-first search, it actually is ordered by shortest subtree (you should see distances increase as you traverse the linkage matrix as the distance recorded represents the tip to root so far).
I think we should have some way of validating that a given tree is bifurcating and ultrametric, and raise an error otherwise.

@ebolyen you are right - this method will only work properly on ultrametric bifurcating trees.  I didn't know about the shortest subtree ordering.  Thanks!

This may of interest in the future -- particularly now that seaborn remains to be the best plotting program for dendrogram heatmaps.


Support of cardano-rosetta for Cardano 8.0.0

Ask a question
When are you going to release a new cardano-rosetta with cardano 8.0.0?

Sorry for the delay in communication. We just merged a version bump for node 8.1.2 and preparing the new release for 2.2.0, which will include it.
So I'm closing this issue, I hope it will solve your problems. If not let me know.


fix(Angular) - Regression error Unable to build library with a CloudinaryModule dependency

Error:
Building entry point '@iko/media/ui-cloudinary-image'
------------------------------------------------------------------------------
node_modules/@cloudinary/angular/lib/cloudinary.module.d.ts:1:22 - error NG6002: Appears in the NgModule.imports of MediaUiCloudinaryImageModule, but could not be resolved to an NgModule class.

This likely means that the library (@cloudinary/angular) which declares CloudinaryModule has not been processed correctly by ngcc, or is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if so. Also consider checking with the library's authors to see if the library is expected to be compatible with Ivy.

1 export declare class CloudinaryModule {
                       ~~~~~~~~~~~~~~~~

———————————————————————————————————————————————

>  NX   ERROR  Running target "media-ui-cloudinary-image:build" failed

Fails in:
"@cloudinary/angular": "1.0.0-beta.11",
"@cloudinary/base": "1.0.0-beta.4",
This works fine using
"@cloudinary/angular": "1.0.0-beta.8"
Project uses Angular 12.2 with all libraries using Ivy

Hi there,
I'm checking with my teammates but it's nighttime for them now.  Would you share with me a code snippet where the error occurs?
Thanks,
Mo

I imported CloudinaryModule into a Ivy enabled angular library module.
Example
Imports: [CloudinaryModule]
Was working with w beta 8. Stopped working with beta 11.
Cheers,
Bjorn

Bjorn Harvold
E-mail: @.***
U.S. Mobile: +1-917-494-6357
Google Voice: +1-917-934-3912
Skype: +1-917-720-3351 / bjornharvold
Thai Mobile: +66-85151-0325
Hong Kong: +852-8198-8406
Facebook: bjornharvold
Twitter: @bjornharvold
LinkedIn: bjornharvold
On 17 September 2021 at 02:57:56, momoip @.***) wrote:

Hi there,
I'm checking with my teammates but it's nighttime for them now. Would you
share with me a code snippet where the error occurs?
Thanks,
Mo
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cloudinary/frontend-frameworks/issues/98#issuecomment-921202715,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAE4V7YP7MWIBWIEHIZL5RLUCJD4JANCNFSM5EEZ3NBA
.

Thanks @bjornharvold, we have opened an internal ticket to look into this issue. We will update here with any new insights.

We tested with an ivy-enabled angular 12.2 app and did not find any issues.   If this issue still persists, would you share with us a live example?

Did you test with Angular libraries?
Steps:

Create 2 Angular libraries that are Ivy enabled
Library 1 depends on Library 2
Library 2 depends on CloudinaryModule

On October 1, 2021 at 6:13:18 AM, momoip @.***) wrote:
We tested with an ivy-enabled angular 12.2 app and did not find any issues.
If this issue still persists, would you share with us a live example?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudinary/frontend-frameworks/issues/98#issuecomment-931767139,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAE4V73Q32QYHYJP2VL2BMTUETVI5ANCNFSM5EEZ3NBA
.

Will test and update you.

We are not able to reproduce based on your steps and did not see any issue.  Would you please provide us with a live example?

Would you mind upgrade to v12 and get the latest Cloudinary code and let me know if it resolves your issue?

We are using Angular / CLI v12.2.10 at the moment. I don't see any new releases from Cloudinary in the last 30 days. @cloudinary/angular is still on 1.0.0.beta.11. This looks like a dependency issue on Cloudinary side.

You can find a way to reproduce here:
https://github.com/bjornharvold/cloudinary-issue-98/tree/master/cloudinary
Here's what I found: You had renamed @cloudinary/base to @cloudinary/url-gen. That fixed this latest error. Will continue testing for the initial error and the reason I created this ticket.

As I changed to using<EMAIL_ADDRESS>I am now unable to start my app:
(node:8003) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'data' of undefined
    at ProjectHasher.<anonymous> (/Users/crash/git/iko-travel-spa/node_modules/@nrwl/workspace/src/core/hasher/hasher.js:248:41)
    at Generator.next (<anonymous>)
    at /Users/crash/git/iko-travel-spa/node_modules/tslib/tslib.js:117:75
    at new Promise (<anonymous>)
    at Object.__awaiter (/Users/crash/git/iko-travel-spa/node_modules/tslib/tslib.js:113:16)
    at /Users/crash/git/iko-travel-spa/node_modules/@nrwl/workspace/src/core/hasher/hasher.js:241:79
    at new Promise (<anonymous>)
    at ProjectHasher.<anonymous> (/Users/crash/git/iko-travel-spa/node_modules/@nrwl/workspace/src/core/hasher/hasher.js:241:50)
    at Generator.next (<anonymous>)
    at /Users/crash/git/iko-travel-spa/node_modules/tslib/tslib.js:117:75
(node:8003) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:8003) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

When I downgrade to beta-8 and use @cloudinary/base, I am able to run my app again.

Never mind. I had to change all the import to reflect the new library imports @cloudinary/base -> @cloudinary/url-gen.


Does this need a 1.18.2 build?

Was gonna ask, then I saw someone made a similar issue... and then closed it for no reason.
Basically, does this mod already work with 1.18.2, or would a build have to be made with it in mind?
@Tfarcenim

Alright, some light testing has proven it works on 1.18.2. It just needs to be marked as such on Curse. Keeping this open for reference until then.

I've basically been unable to progress with my community server because of large packets.

I've basically been unable to progress with my community server because of large packets.

Try this
https://www.curseforge.com/minecraft/mc-mods/connectivity

i tried that sadly, they both don't fix the packet issue, and i've had to post an issue on both.

it was forgero, issue resolved.

1.18.2 now has an official build with 1.19.2 on the way.


Gear button has a border in search

Issue Type: Bug

Search in Folder
Click on the gear of "files to exclude"
Focus on editor
Border stays

VS Code version: Code 1.24.1 (24f62626b222e9a8313213fb64b10d741a326288, 2018-06-13T17:41:50.128Z)
OS version: Darwin x64 17.6.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz (4 x 3100)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: enabledrasterization: enabledvideo_decode: enabledvideo_encode: enabledvpx_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
4, 3, 2

Memory (System)
16.00GB (0.86GB free)

Process Argv
/Applications/Visual Studio Code.app/Contents/MacOS/Electron

Screen Reader
no

VM
0%

Extensions (20)

Extension
Author (truncated)
Version

gc-excelviewer
Gra
2.0.21

vscode-docker
Pet
0.0.27

gitignore
cod
0.5.0

systemd-unit-file
coo
1.0.0

vscode-eslint
dba
1.4.12

ansible-vault
dho
0.1.3

tslint
eg2
1.0.32

vscode-npm-script
eg2
0.3.4

terraform-autocomplete
erd
0.0.8

flow-for-vscode
flo
0.8.1

terraform
mau
1.1.2

dotenv
mik
1.0.1

python
ms-
2018.5.0

cpptools
ms-
0.17.4

Go
ms-
0.6.83

jenkinsfile-support
sec
0.1.0

vscode-nginx
sha
0.5.0

cmake
twx
0.0.17

vscode-react-native
vsm
0.6.11

jinja
who
0.0.8

(1 theme extensions excluded)

The border indicates that the option is 'on'.

@chrmarti that looks weird, I think would be nice if instead of a border the icon will have a different color

-1, we consistently use this style to indicate something is checked also in the find widget for example.

@bpasero for me it does not look obvious.

We should consider using an alternate style for showing when a state is "enabled" or "checked" as our focus border treatment already uses the border style so it can be confusing. Adding this to the backlog.

Will close this in a favor of #36439


WIP: Add Google Storage support

The website mentions S3-compatible storage should work with Google Storage which exposes the same API as S3. I'm not sure how old this documentation is and if this is even still possible. I could not get this working so I added native support for Google Storage.
We are currently testing and improving this with our own reporting system (1.2 billion requests per day). I thought I already make a pull request to get some community feedback.
One thing that still needs to be done is some tests. Although if I look at the Azure tests for example, I don't really see much benefit as it really only tests if the correct functions are called and not if the implementation really works.
This pull request also updates com.maxmind.geoip2 to 2.6.0 including the needed changes to WikipediaIrcDecoder.java. This is needed because the old geoip2 version depends on a really old version of com.google.http-client.

@erikdubbelboer i am wondering, there is not any authentication or credentials to connect/push to a GCS ?

@b-slim No, by default it will get the required auth from the gcloud tool which is installed and configured by default when running on a compute or appengine instance, or can be manually configured on other machines.

@erikdubbelboer, thanks for the answer, so suppose in case i have (i is the druid process) the wrong credentials how i figure that out ? is there a special exception  or any logging to tell me i am using wrong configs  if i am debugging what's going on.

need to add UTs.

@erikdubbelboer is this still WIP?
can we add this module and the docs to extensions-contrib? this way we can just merge it without having to address all of the CR

@fjy We started using hadoop index tasks, so after using hadoop already only #2646 and #2645 were needed for druid to support google cloud storage through hadoop. I guess using hadoop in between is a bit slower but none of that stuff is time sensitive. The advantage is that druid in combination with hadoop, and hadoop with google cloud storage are much more tested than the code I wrote for this pull request.
Before this I did some testing where instead of #2645 I had hadoop index tasks with "gs://" output schemes create segments which the historical node could directly load using the code in this pull requests. So only the index tasks would require hadoop, everything else could access google cloud storage directly. I guess this is a bit faster and some people might like not having to rely on hadoop for their historical nodes to work.
So I guess one issue is, if you want to merge this, what should happend with "gs://" schemes? Should they generate hadoop segments like with #2645 or should they generate segments that can directly be downloaded using this pull request?
So I'm not sure what I should do with this pull request. I don't know if anyone is really interested in it. Maybe it's a better idea if I just contribute some documentation on how to use hadoop for google cloud storage like we do now?

@erikdubbelboer We'd love to have direct GCS support without the overhead of maintaining a Hadoop cluster. #2645 already helps us quite a bit that we needn't keep scaling HDFS on our Data Proc cluster for historical segments. But this will allow us to even scale down the Hadoop nodes and not worry about affecting queries.

@sandepudi I'm not sure how queries have anything to do with HDFS? When you're using gs:// and aren't using hadoop for indexing you basically only need one node to "proxy" the segment requests.
It shouldn't be too hard to get this pull request working with the latest changes. But the reason we didn't choose for this route is that it isn't tested as well as the HDFS code. If you want I can bring the pull request up to date and see if there is interest in merging?

That would be awesome.

Update: I looked into this code again as we are exploring the option to only start hadoop for our nightly reindex task. One problem I'm running into now is that we already have a lot of segments with a hdfs LoadSpec. We would need to someone convert these to a google load spec. Or we need to somehow have this google storage plugin also handle the hdfs spec segments. I looked into this but I'm not familiar with how these specs are bound to their type and if this can be overwritten for example. Anyone have any suggestions of this is possible? Otherwise is converting all the payloads in mysql and all the descriptor.json files enough to change the load specs?

I just amended this pull request. It's rebased against master and contains some test cases. So some new feedback would be appreciated.
Right now I'm testing converting hdfs segments to google segments using a small python script: https://gist.github.com/erikdubbelboer/55c699b43e4275779b328a8c37d902fd
After that I'll slowly upgrade our cluster to <IP_ADDRESS> including these changes to test them even more.

I pushed some more bug fixes.
We are now using this code (on 0.9.1) in production in the following ways:

Realtime nodes push segments directly to GCS.
Historical nodes pull directly from GCS.
Hadoop index tasks push their results directly to GCS.
Hadoop index tasks store their logs directly in GCS.
Overlords pull the index tasks directly from GCS.

All our old segements have been converted using the python script. So now we basically only start our Hadoop cluster once per night to index the previous day.

FYI, we were able to make it work perfectly just by adding a
jets3t.properties file with "s3service.s3-endpoint=storage.googleapis.com"
in conf/druid/_common.
Corentin Kerisit
VSRE compliant
On Sat, Jul 30, 2016 at 11:48 AM, Erik Dubbelboer<EMAIL_ADDRESS>wrote:

I pushed some more bug fixes.
We are now using this code (on 0.9.1
https://github.com/erikdubbelboer/druid/tree/0.9.1) in production in
the following ways:

Realtime nodes push segments directly to GCS
https://cloud.google.com/storage/.
Historical nodes pull directly from GCS.
Hadoop index tasks push their results directly to GCS.
Hadoop index tasks store their logs directly in GCS.
Overlords pull the index tasks directly from GCS.

All our old segements have been converted using the python script
https://gist.github.com/erikdubbelboer/55c699b43e4275779b328a8c37d902fd.
So now we basically only start our Hadoop cluster once per night to index
the previous day.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/druid-io/druid/pull/2458#issuecomment-236356375, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABEwwi3KAIQF5AgyE2FfDQZv4koxkCe7ks5qax3zgaJpZM4HY9yR
.

FYI, we were able to make it work natively just by adding a jets3t.properties file with:

s3service.s3-endpoint=storage.googleapis.com

in conf/druid/_common.

@cerisier That sounds a lot easier. I had no idea this was possible. Do you also use it for all the features I mentioned above?

@cerisier when things get propagated around druid tends to only consider *.jar files (see https://github.com/druid-io/druid/issues/1213 ). Did you see this effect?

@erikdubbelboer is this still WIP?

Moving this to 0.9.3 to allow for more time for review

We have been using this in production for two weeks now without issues so it seems to be fine. I removed the WIP.

I just pushed a small fix for a bug someone was having and rebased on master.

Fixed a missing case when converting google segments. And again rebased on master.
And I back ported this branch to <IP_ADDRESS>
See: https://github.com/erikdubbelboer/druid/tree/<IP_ADDRESS>-google-extensions
For people who want to try these changes with <IP_ADDRESS> here are my build artifacts:
https://www.atomx.com/druid-<IP_ADDRESS>-bin.tar.gz
https://www.atomx.com/druid-google-extensions-<IP_ADDRESS>.jar
Test failing has nothing to do with this pull.

I rebased on master and fixed all changes needed for #3585
When testing this pull request on 0.9.2 I found that the geoip was again causing conflicts so I modified the exclusions even more to fix it.

I haven't reviewed this too carefully, but given this is a contrib extension, I am 👍

@nishantmonu51 can you help with review here?

@erikdubbelboer minor conflict in docs here

I have rebased on master.

@erikdubbelboer It is still showing conflicts, can you try rebasing again ?

@nishantmonu51 fixed and fixed.

@erikdubbelboer Thanks :)


Create LICENSE

Hallo hannahrobot,
i really appreciate your tutorial and code exmples. It was very helpful in understanding the principles of an online game. My friend is a teacher and we try now to implement our own version of this game for his school. Therefore I would like to ask you, if you may add a license to this project?

Hey Hannahrobot, just wanna give you a short upload on the project. We are testing it with the students, but having some server issues at the moment. The school is located in germany, but i am not sure how much into detail i can go here.


Hand tracking is slower than the old Mediapipe for Android

In the old Mediapipe's sample app my test phone could track hands in real time, in this version it is lagging behind. What could be the problem? First thought that comes to my head is analyze case for CameraX being slower. Old Mediapipe sample used an older CameraX version and handled SurfaceView manually if my memory is serving me right. Is there anyway I can get around this and get the same speed for this version? Forgive me if I am asking anything obvious as I am still rather new to Android development.

Perhaps the problem could be this issue here:
https://groups.google.com/a/android.com/g/camerax-developers/c/jgeLgaeiO6g
I cannot try on different devices right now. But similar to what is seen on that issue, my device seems to work well with older Mediapipe sample which used an older cameraX, this could be a problem with newer cameraX that affects this sample.

Hi @EmreSafaCelik!
So since the Task Library accepts a MPImage, which I'm creating from a Bitmap (I pass in an ImageProxy because of CameraX that I then turn into a Bitmap for preprocessing, but you can change this method around for whatever), I think you'd be OK to try any method that can get an object that's convertible to an MPImage that you want to process asynchronously. I believe MediaPipe Tasks is working the same under the hood while we make it easier to use, but I'll confirm that and update you if I'm wrong there.
That said, I'm honestly not sure if CameraX is slower or not now. Out of curiosity, would you mind sharing what device you're using for testing? I can see if I have something similar laying around, plus I want to reach out to a buddy on the CameraX team to see if they have any insight around it.
Thanks!

Hello Paul, thank you for responding.
The device I am mainly testing on is Xiaomi Mi 11 Lite, I have also tested on Xiaomi mi note 9 and 7.
I realized the older sample had lower fps in both preview and analyze, but they were in synchrony with each other. I will try using the same thread for both analyze and preview in the new version and see how much of an fps drop I get.
https://user-images.githubusercontent.com/69720413/219100386-7373e480-427a-4db2-a61f-ee866450bda8.mp4
https://user-images.githubusercontent.com/69720413/219100419-cfd9d2b3-de5e-478d-a1e2-f4df82e00a65.mp4

Got it, thanks! So I'm able to replicate the slower tracking on my Pixel 7 Pro, too. Inference time is ranging from 50ms to 150ms per frame on my device, so I did reach out to the camera team to see if they're aware of anything under the hood that may have changed. A part of me also wonders if it's my drawing code for the OverlayView being a bit slow, too, but I haven't dug into that.

I tried it this way to quickly test if it would make any difference if draw function was less burden, doesn't feel like it is.
override fun draw(canvas: Canvas) {
super.draw(canvas)
results?.let { handLandmarkerResult ->
val points = mutableListOf()
        for (landmarks in handLandmarkerResult.landmarks()) {
            for (i in landmarkConnections.indices step 10) {
                val startX =
                    landmarks[landmarkConnections[i]].x() * imageWidth * scaleFactor
                val startY =
                    landmarks[landmarkConnections[i]].y() * imageHeight * scaleFactor
                points.add(startX)
                points.add(startY)
            }
            canvas.drawPoints(points.toFloatArray(), pointPaint)
        }
    }
}

https://user-images.githubusercontent.com/69720413/219197860-f276cb00-6434-4e1a-be1f-f48562dc13b8.mp4
Running analyzer on main executor also didn't sync them.
I have been trying to use https://github.com/supremetech/mediapipe-demo-hand-detection to get rid of Bazel for a while and had this exact problem after integrating it to CameraX. It persists here too so I guessed It might be about CameraX. But now I managed to connect some dots and realized you are also (probably?) using this project, so the problem might be something unrelated as CameraX is not the only thing in common. Though running both preview and analyzer on main executor had somewhat solved this with the price of fps on both in my app. Here it seems not to.

https://issuetracker.google.com/issues/144795164
this is likely the issue I had when I ran both on main executor on my app. The fps dropped a lot when I did that.

Hi, @EmreSafaCelik. Are you saying that the FPS drop is lower than the original sample, or is it in line with what the older sample had? If the FPS is too low and it's a problem for you, can you add a comment on the issue you linked to with the devices you tested? That will help us prioritize a fix. Thanks!

Hi Donovan. Though I no longer have problems with the delay for now, It would be great if it was resolved. I added a comment on the issue I linked.
As for whether saying FPS drop is worse than the original, it is not. As the videos above show it, there is a delay in tracking. FPS is fine. Older sample had both the preview and tracking synced as the videos above show, but had worse fps overall.

Thanks for the update EmreSafaCelik!
Since it sounds like the issue is on the Android side (with the issue link you posted), I'll leave this thread open for a few more days in case you have other updates before I close it out. Let me know if I'm misunderstanding what's going on though so I don't prematurely cut off a channel :)
Thanks!


Change the index.html file in the Chripy Starter to index.md

I was trying to open the GitHub pages page, but all it would show is --- layout: home ---. Once I renamed the file, it worked. IDK if that is just an issue with my run of it or not. If it is feel free to close this request. Thanks for the great Jekyll theme!

Please make sure you read through the contributing guidelines carefully, if you don't follow the rules inside to open issue in the future, then your account will be banned, thank you.

Sorry, i never saw that. My bad.


Option to center all blocks in Flowchart window

If you lose track of where the  blocks are in your Flowchart window it can be hard to find them again.

I'm changing this to a bug as several users have run into this problem.


Force to compile with UTF8 encoding

What problem does this fix? Isn't UTF-8 the default?

Yes, according to doc here, the default encoding is set to null, which uses the system default encoding.

Fixed. Thanks @chenjunjiedada!


Lyra doesnot really like debug bar

Please see attached
I have a clean Laravel 7, with barryvdh/laravel-debugbar installed

I am testing it and I have already found the problem, in the next patch version it will be solved.


Feature request: Add support for Hodlcoin - 1GB AES Pattern Search POW

Hodlcoin is gaining popularity but the algo is missing from major pool sofwares.
Hodlcoin source code:
https://github.com/HOdlcoin/HOdlcoin
Algo:
https://github.com/HOdlcoin/HOdlcoin/blob/HODLCoin0.11.3/src/primitives/block.cpp
https://github.com/HOdlcoin/HOdlcoin/blob/HODLCoin0.11.3/src/patternsearch.cpp
Suprnova.cc is running MPOS and have a Hodlcoin support https://hodl.suprnova.cc/ but I did not manage to find 1GB AES Pattern Search POW from the source code.

MPOS is not actively developed anymore, so no new coins will be added. Sometimes new coins use MPOS forks and add a specific coin to it, but most of the time there is no PR against upstream to add support globally or the changes for a coin are so drastic that no generic implementation exists.
You may find help out there, but core won't be adding new coins.

And quick hint, have you tried running the coin at all? Many times MPOS will still work since it only looks at shares that have to be added by modified stratum instances. They do most of that work, MPOS only takes care of payouts.
As long as they don't do anything crazy in their API regarding basic coin functions, it may still be usable.


[bp/1.25] test: fix flaky test DownstreamProtocolIntegrationTest.HandleDownstreamSocketFail (#27546)

The test manually introduces EBADF error on the connection between Envoy and the test client. However, the IoHandleMatcher doesn't distinguish UDP socket from TCP. If the upstream HTTP/3 connection gets the same port number as downstream TCP connection, the EBADF error will be applied to the wrong connection.
Enforce IoHandleMatcher to match socket type.
Risk Level: low, test only
Testing: existing tests
Docs Changes: N/A
Release Notes: N/A
Partially Fix #27490

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

this is failing with
test/integration/shadow_policy_integration_test.cc:18:9: error: member initializer 'SocketInterfaceSwap' does not name a non-static data member or base class
        SocketInterfaceSwap(Network::Socket::Type::Stream) {
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

i guess if we want to pick this to this branch we will need to pick other change/s also

this is failing with
test/integration/shadow_policy_integration_test.cc:18:9: error: member initializer 'SocketInterfaceSwap' does not name a non-static data member or base class
        SocketInterfaceSwap(Network::Socket::Type::Stream) {
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

i guess if we want to pick this to this branch we will need to pick other change/s also

What this branch is? The PR just fixed a test utility. Why is it need to be picked into a specific branch?

thanks @danzh2010 for clarification offline - seems this should not be necessary


Sequence deleted by ingestion server

Description

The ingestion server destroys the auto-incrementing sequence of the id key during the ingestion making it impossible to add objects from the Django admin.
Reproduction

To see the database before ingestion, stop the load_sample_data.sh script at line 46 using exit and run just init.
To see the database after ingestion, remove the exit, comment out lines 9 to 45 and run just init.

Screenshots

Before ingestion:
openledger=# \d audio
                                                Table "public.audio"
            Column            |           Type           | Collation | Nullable |              Default
------------------------------+--------------------------+-----------+----------+-----------------------------------
 id                           | integer                  |           | not null | nextval('audio_id_seq'::regclass)

After ingestion:
openledger=# \d audio
                                   Table "public.audio"
            Column            |           Type           | Collation | Nullable | Default
------------------------------+--------------------------+-----------+----------+---------
 id                           | integer                  |           | not null |

Additional context

There is code for setting up a temporary sequence for the id column but the sequence does not exist on the final table.
https://github.com/WordPress/openverse-api/blob/1ed4146889fd8c455d00e8bc01417f9e62885a40/ingestion_server/ingestion_server/queries.py#L111
Resolution

[ ] 🙋 I would be interested in resolving this bug.

This is low priority because we're not supposed to be adding objects from the admin anyway so no actual functionality is broken.

Oh dang, thanks for finding this!


Permanently moved

https://bro.teru.sexy/Teruko/TsunArt

Though I'll still be completing issues here, since migrating is too much work, and Gitlab has a backup anyway.

The repo is still mirrored here. Yay.


When exporting a model from training pipeline, generate a readme with the support content type and other info

For now we generate the readme as part of the assets_generation scripts (see #658), and not as part of the model export. Ideally we keep model export as minimal as possible, and we generate whatever can be derived from that with some automation in this repo.


Refactoring authority framework, value pairs and controlled vocabulary

References
Wiki page with the preliminary discussion:  https://wiki.lyrasis.org/display/DSPACE/4Science+proposal+to+improve+authority+support+in+DSpace7
Rest Contract PR https://github.com/DSpace/Rest7Contract/pull/128
Angular PR: will be open in a couple of days
Description
This PR restores the previous way of DSpace to store metadata when values are retrieved from valuepairs and controlled vocabularies (without the authority ID in the metadatavalue).
Nevertheless, value-pairs and controlled vocabularies are managed using the same infrastructure previously used for Authority Control, for these reasons we agree to rename all these features under the common name of controlled vocabularies.
Finally, this PR also fix a couple of outstanding issues that were noted on the previous implementation
https://jira.lyrasis.org/browse/DS-4350
https://jira.lyrasis.org/browse/DS-4371
https://jira.lyrasis.org/browse/DS-4408
this also replace the previous PR https://github.com/DSpace/DSpace/pull/2743 adding the necessary features to support the visualization of the hierarchical vocabularies
Instructions for Reviewers
ITs have been added to cover the new VocabularyEntryDetails endpoint and the refactoring related to the link repositories.
Other than reviewing the code by inspection and checking the ITs it could be useful to verify the correct exposition of the default submission definitions where the value-pairs must be exposed as common_types vocabulary. It is also possible to enalbe the srsc controlled vocabulary to verify that it meet the example in the REST Contract
Checklist

[ ] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & integration tests). Exceptions may be made if previously agreed upon.
[X] My PR passes Checkstyle validation based on the Code Style Guide.
[X] My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods.
[X] My PR passes all tests and includes new/updated Unit or Integration Tests based on the Code Testing Guide.
[N/A] If my PR includes new, third-party dependencies (in any pom.xml), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[X] If my PR modifies the REST API, I've linked to the REST Contract page (or open PR) related to this change.

@tdonohue @benbosman your previous feedback should have been addressed. I have also created an internal PR (see https://github.com/4Science/DSpace/pull/157 ) to show the changes that are needed if we want to go ahead and remove the need for the metadata & collection parameters, let me know if you like to get these changes in

I've verified https://github.com/4Science/DSpace/pull/157 in more detail today, and I see you're retrieving the field from the choices.plugin.dc.contributor.author = SolrAuthorAuthority configuration. This should work correctly.
I'd recommend to update this branch to include those changes, so I can review both combined

@abollini can you also let me know how this will work with ORCID?
I tried enabling solr authority and using /server/api/submission/vocabularies/SolrAuthorAuthority/entries?filter=0000-0002-8715-1113 but it didn't work

@tdonohue @benbosman  all your previous feedback have been addressed as far as I can check. To simply the review I have explicitly linked the "solution" under each not yet resolved comment.
About the ORCID test mentioned here https://github.com/DSpace/DSpace/pull/2792#issuecomment-658795765 it cannot be performed because the ORCID integration with the authority framework was dropped sometimes ago but it should be restored (I have created https://github.com/DSpace/DSpace/issues/2891  for that)

latest feedback has been addressed. The angular part is in this PR https://github.com/DSpace/dspace-angular/pull/751 that as by today dev mtg discussion will be updated today by @atarix83 to be in a testable status

This is at +2, as it the corresponding Angular PR (https://github.com/DSpace/dspace-angular/pull/751).  So, I'm merging both & pushing an update to the REST API demo site.  Thanks @abollini & @Micheleboychuk (and all the reviewers)!


Add --hide-secrets flag

Fixes: https://github.com/helm/helm/issues/7275

What this PR does / why we need it:
The PR contains my proposition for resolving https://github.com/helm/helm/issues/7275 issue. Instead of implementing the new flag just for the --dry-run option I decided to go with more general approach applicable for other actions like install.
The PR introduces new flag --hide-secrets which replaces all values in Secrets data fields with [HIDDEN] text.
For example:
Secret:
apiVersion: v1
kind: Secret
metadata:
  name: secret-sample
data:
  test: YmFyCg==
  password: bXktcGFzc3dvcmQ=

would be displayed as:
apiVersion: v1
kind: Secret
metadata:
  name: secret-sample
data:
  test: '[HIDDEN]'
  password: '[HIDDEN]'

The replacing is done after applying manifest and before outputting it.
Special notes for your reviewer:
I am curious to hear your thoughts/criticism/other ideas.
If applicable:

[ ] this PR contains documentation
[x] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

Hi, @Szymongib - thanks for implementing this solution! Would you mind fixing the merge conflict so we can evaluate it? Thanks.

Hi, @Szymongib - thanks for implementing this solution! Would you mind fixing the merge conflict so we can evaluate it? Thanks.

Hi @bridgetkromhout, thanks for taking a look, I have fixed conflicts.

Hi @bridgetkromhout, thanks for taking a look, I have fixed conflicts.

Did you intend to have this work for helm template foo? I tried using the global flag --hide-secrets with it and that didn't seem to have any effect.
I did try a helm install foo --dryrun --hide-secrets, that worked great.

From what I see helm template uses different rendering mechanism (it does not use statusPrinter.WriteTable) therefor it does not apply to it.
I could implement it, but I will leave it up for the discussion.

I could implement it, but I will leave it up for the discussion.

Hi there, I brought this up in today's helm developer community meeting. There's consensus that helm template too should have this since a lot of users log helm template contents too. Would you be able to add support for this?

Would you be able to add support for this?

Sure, I will try to squeeze it in next week.

Hi @sbose78 I did some refactoring as I noticed some issues. Implemented the functionality additionally for helm template and helm get manifest.
I think I got all commands that print manifest but if I missed some feel free to let me know.

Thank you, I will review!

Works for helm template now too, thank you!
( will reviewing code in detail )

We are running into same issue being addressed by this pr and we would love to bring back --dry-run and--debug switches. @Szymongib  thanks for getting this done. Is this something planned for next release? And this is something getting merged soon?

This is good for merge, my from perspective.
On Thu, Mar 25, 2021, 01:10 Samir Mowade @.***> wrote:

We are running into same issue being addressed by this pr and we would
love to bring back --dry-run and--debug switches. @Szymongib
https://github.com/Szymongib thanks for getting this done. Is this
something planned for next release? And this is something getting merged
soon?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/pull/9130#issuecomment-806368131, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEFEABBYM6NRXE5VE56GG3TFLAU5ANCNFSM4U4ZPVXQ
.

Hi @bacongobbler thanks for the feedback, this PR came up more of as a PoC to validate the idea, maybe getting some better suggestions from maintainers.
It does make some assumptions as it is not meant to be a general thing as the function name states HideManifestSecrets this assumes the input if valid Helm manifest produced by other Helm operation it was never meant to be something that operates of either K8s files or resources and should be treated as a function that edits text that happens to be in YAML format.
This came up as a result of me not wanting to change the actual text representation of manifest, parsing the YAML to any real Kubernetes representation removes all formatting, indentation and may change the order of the fields and the function was just meant to sanitize the text. The output produced by the function is not in any way valid Kubernetes object as data fields need to be base64.
Using any kind of parser will fundamentally change the manifest therefore I chose not to do it as regular manifest could look completly different than the one produced with --hide-secrets flag. Not sure what is your view on that, maybe it is ok, but personally I do not think that would be desired behavior.

this PR came up more of as a PoC to validate the idea

I'm confused. If this is a proof-of-concept, why post this as a pull request and ask us to consider merging it?

Using any kind of parser will fundamentally change the manifest therefore I chose not to do it as regular manifest could look completly different than the one produced with --hide-secrets flag. Not sure what is your view on that, maybe it is ok, but personally I do not think that would be desired behavior.

I'm not sure I fully understand what you mean. All I'm asking is for you to use proper Kubernetes client libraries to load and validate resources similar to how we parse manifest files in pkg/kube. I'm not asking you to change the input and output. I'm asking you to remove the custom YAML parser logic and instead pass it to apimachinery to properly encode/decode Kubernetes API objects.

I'm confused. If this is a proof-of-concept, why post this as a pull request and ask us to consider merging it?

It was posted more than half a year ago to spark up a discussion with maintainers, propose some solution to a highly requested issue, I am not sure what would be the other way to propose it as this is what PRs are for as for my understanding.

I'm not asking you to change the input and output. I'm asking you to remove the custom YAML parser logic and instead pass it to apimachinery to properly encode/decode Kubernetes API objects.

If I understand you correctly that was my initial idea but realized that decoding part of the manifest to for example v1.Secrect changing some values and encoding it back to YAML will fundamentally change how it looks -- formatting and indentation may change, comments will be removed, fields may switch order. That would result in manifest rendered with --hide-secrets and without the flag, to differ more than just sanitized values which do not seem right to me. That lead me to treat is more as a YAML processing problem more than K8s manifests processing problem.
There may be a solution that I am not aware of so it would be great if you could elaborate.

Hi, @Szymongib - Would you mind fixing the merge conflict so we can evaluate it? Thanks.

This feature is being developed for a long time
@Szymongib  please resolve conflicts in go.mod
@jdolitsky merge this feature and realize for user
I've been waiting for this for over a year

Moving to 3.8.0 as the PR is failing tests.

@bacongobbler @sbose78 please review/actualize your request changes

Closing as inactive.

This is very bad

As I stated in my last review, the code proposed here is very brittle. I provided feedback how the author can proceed following kubernetes best practices.
If you have code to review @wirwolf, I'd be very happy to review and provide feedback. But the code proposed here was not ready to be shipped to production.

@bacongobbler as I stated in the response I do not think that what you proposed is the solution due to reasons I elaborated in the comment above and I do not think that what you consider to be possible next steps will lead to an acceptable solution.
I understand and fully accept that you do not want this code in the project but as I mentioned in the PR initially I wanted to spark up the discussion so we can perhaps iterate on the solution or switch to some other approach.

In my projects, I have to add secrets with kubectl before deploying my app in this manner:
    ${KUBECTL} -n ${KUBE_NAMESPACE} create secret generic ${CI_PROJECT_NAME}-generic \
        --from-literal=APP_DEBUG="${APP_DEBUG}" \
      -o yaml --dry-run | ${KUBECTL} -n ${KUBE_NAMESPACE} replace --force -f -

for hiding secrets in pipeline. And after that, I deploy helm chart with annotations in Deployment
        rollme: {{ randAlphaNum 5 | quote }}

for restart pod(for apply changes, no matter change secrets or not).
Any solution will work for me to get rid of these crutches.
https://github.com/SomeBlackMagic/php-ddd-docker-kuber-skeletorn/blob/master/.helm/site-app/templates/deployment.yaml#L23
https://github.com/SomeBlackMagic/php-ddd-docker-kuber-skeletorn/blob/master/.pipelines/prerequisites.sh#L10


tcp keepalive issues

Hi!
I have this kind of issues:
{"v":0,"name":"---","message":"tcp set_keepalive error: Invalid argument (os error 22)","severity":"WARNING","timestampSeconds":1730129780,"timestampNanos":584648375,"logging.googleapis.com/sourceLocation":{"function":"hyper_util::client::legacy::connect::http","line":719,"file":"/usr/local/cargo.cache/1.82.0-slim-bookworm/registry/src/index.crates.io-6f17d22bba15001f/hyper-util-0.1.9/src/client/legacy/connect/http.rs"}}
When I run the spider to crawl from an HTTP (not HTTPS) endpoint.
Tried with v2.10.26.
I don't think it is an issue, I believe I have misconfigured something. Can you please help me?
Thank you

Hi, are you adjusting the tcp keep alive option in reqwest?

This issue belongs in https://github.com/hyperium/hyper/issues?page=2&q=TCP+keep+alive

Sorry @j-mendez, to which issue on the link (hyper issues page 2) do you refer?
Honestly I can't figure it out...