text:
Can't make it work on RN 0.59.9 w/ react-native-router-flux

I've been using v1.1.9 since last year and have experienced multiple issues with active items suddenly flying up or even to some instances where the component won't function as expected at all.
I've gone to the conclusion that updating this library might fix it since there has been a few releases after v1.1.9.
So I went and gone straight to the latest version and tried to install Reanimated and React Native Gesture Handler with the proper instructions.
After that, the draggable view no longer works on iOS, no scrolling or dragging works. On the other hand, the app won't even run on Android due to androidX support.
Take note that I am using react-native 0.59.9 and react-native-router-flux on my project. This might be insightful to what issues I am encountering now.
Any suggestions would help. Although solutions that have anything to do with upgrading to 0.60 - I cannot support right now.

Tried to do the whole reset npm cache procedure, and even reset my node_modules and iOS build folder & pods. Said error message persists

Did you clear derived data too?

Yup.

looks like an upstream bug -- https://github.com/software-mansion/react-native-reanimated/issues/409

If the fix is on react-native-reanimated v1.3.0 - which is not supported on pre-0.60 RN
Guess I have no choice then..
I've been trying to upgrade this react-native=draggable-flatlist due to some issues where the items seem to fly up and off the screen when drag-and-dropping on some occasions. Mostly encountered on Android, any clue?

@trgiansanchez I use:

authors: 1Jesper1 bcklup computerjazz trgiansanchez


text:
SDAM specification violation

Noticed a spec violation while reading through the source:
https://github.com/comtihon/mongodb-erlang/blob/master/src/mongoc/mc_monitor.erl#L63 -
This line violates the following part of the spec ("This value MUST be 500 ms, and it MUST NOT be configurable"):
https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#minheartbeatfrequencyms

Yes, got it. I'll fix.

source: gharchive/issue

authors: chowevtfy comtihon

repo: comtihon/mongodb-erlang

license_type: permissive

license_source: bigquery


text:
🛑 Af Dodmets is down

In 8a67bef, Af Dodmets (https://af.dodmets.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Af Dodmets is back up in 0665a6d after 1 hour.

repo: concorde-uptime/uptime-monitor

license: MIT

license_source: github-api


text:
Fix for issue #506 breaks checkout process when not requesting shipping details

Problem:
When checking out and the shipping details form is not required, updateShippingStates() is called on line 580 of communityStore.js. updateShippingStates() then tries to reads the class of #store-checkout-shipping-state, which is not present on the page because the shipping details form is not required. updateShippingStates() then throws a critical error.
Cause:
Code added by push #506 which, presumably, needs wrapping in a conditional.
Temporary Fix:
Roll back commit c76ab9d28c2f15eb21ffd8f2dae4e36d05c77701

Thank you for this. I've pushed up a fix for this (I'm quite surprised this wasn't noticed sooner, but it wouldn't have made it into a release - something we are due for).

authors: Mesuva losttheplot


text:
Support Bootstrap Grid Classes xs, sm, md, lg

I've noticed that in Bootstrap3.php we've got only "sm" columns. While this is okay for a basic projects, one often wants to leverage the full power of boostrap 3 columns by using col-xs-6, col-md-3, col-lg-4 or something similar.
Has anyone ever thought about this? I had a look at the code and I don't feel like that's easy to do with the current implementation.

#2551 and #2552

authors: Remo aembler

license: mit


text:
@conda-forge-admin, please add user @Zoophobus

Additional comment:
https://github.com/LCA-ActivityBrowser/activity-browser/issues/892#issue-1481339939

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added user @Zoophobus in conda-forge/activity-browser-feedstock#5.

authors: conda-forge-linter haasad

repo: conda-forge/activity-browser-feedstock


text:
Old httpx installed with micromamba, manual upgrade was needed

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
After micromamba install -c conda-forge airflow on a clean Python 3.10 environment, I got an httpx version that was too old, and this made airflow standalone fail:
❯ airflow standalone                                                                                (airflow310)
standalone | Starting Airflow Standalone
standalone | Checking database is initialized
Traceback (most recent call last):
  File "/Users/juan_cano/.micromamba/envs/airflow310/bin/airflow", line 11, in <module>
    sys.exit(main())
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/__main__.py", line 59, in main
    args.func(args)
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/cli/cli_config.py", line 49, in command
    return func(*args, **kwargs)
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/cli/commands/standalone_command.py", line 51, in entrypoint
    StandaloneCommand().run()
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/utils/providers_configuration_loader.py", line 55, in wrapped_function
    return func(*args, **kwargs)
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/cli/commands/standalone_command.py", line 67, in run
    self.initialize_database()
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/cli/commands/standalone_command.py", line 177, in initialize_database
    db.initdb()
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/utils/session.py", line 77, in wrapper
    return func(*args, session=session, **kwargs)
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/utils/db.py", line 739, in initdb
    _create_db_from_orm(session=session)
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/utils/db.py", line 713, in _create_db_from_orm
    from airflow.auth.managers.fab.models import Model
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/airflow/auth/managers/fab/models/__init__.py", line 27, in <module>
    from flask_appbuilder.models.sqla import Model
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/flask_appbuilder/__init__.py", line 5, in <module>
    from .api import ModelRestApi  # noqa: F401
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/flask_appbuilder/api/__init__.py", line 24, in <module>
    from flask_appbuilder.models.sqla.interface import SQLAInterface
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/flask_appbuilder/models/sqla/interface.py", line 14, in <module>
    from flask_appbuilder.filemanager import FileManager, ImageManager
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/flask_appbuilder/filemanager.py", line 10, in <module>
    from wtforms import ValidationError
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/wtforms/__init__.py", line 1, in <module>
    from wtforms import validators
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/wtforms/validators.py", line 7, in <module>
    import email_validator
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/email_validator/__init__.py", line 6, in <module>
    import dns.resolver
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/dns/resolver.py", line 30, in <module>
    import dns._ddr
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/dns/_ddr.py", line 12, in <module>
    import dns.nameserver
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/dns/nameserver.py", line 5, in <module>
    import dns.asyncquery
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/dns/asyncquery.py", line 38, in <module>
    from dns.query import (
  File "/Users/juan_cano/.micromamba/envs/airflow310/lib/python3.10/site-packages/dns/query.py", line 130, in <module>
    class _HTTPTransport(httpx.HTTPTransport):
AttributeError: module 'httpx' has no attribute 'HTTPTransport'

Then I did a manual upgrade and this fixed the problem:
❯ micromamba install -c conda-forge airflow "httpx>=0.24"                                                                          (airflow310)
conda-forge/osx-arm64                                       Using cache
conda-forge/noarch                                          Using cache

Pinned packages:
  - python 3.10.*

Transaction

  Prefix: /Users/juan_cano/.micromamba/envs/airflow310

  Updating specs:

   - airflow
   - httpx[version='>=0.24']

  Package     Version  Build         Channel           Size
─────────────────────────────────────────────────────────────
  Upgrade:
─────────────────────────────────────────────────────────────

  - httpx      0.12.1  py_0          conda-forge     Cached
  + httpx      0.25.0  pyhd8ed1ab_0  conda-forge       65kB

  Downgrade:
─────────────────────────────────────────────────────────────

  - httpcore    1.0.0  pyhd8ed1ab_0  conda-forge     Cached
  + httpcore   0.18.0  pyhd8ed1ab_0  conda-forge       45kB

  Summary:

  Upgrade: 1 packages
  Downgrade: 1 packages

  Total download: 110kB

Installed packages
List of packages in environment: "/Users/juan_cano/.micromamba/envs/airflow310"

  Name                                    Version       Build               Channel
─────────────────────────────────────────────────────────────────────────────────────────
  aiohttp                                 3.8.6         py310hd125d64_1     conda-forge
  aiosignal                               1.3.1         pyhd8ed1ab_0        conda-forge
  airflow                                 2.7.2         py310hbe9552e_0     conda-forge
  alembic                                 1.12.0        pyhd8ed1ab_0        conda-forge
  amqp                                    5.1.1         pyhd8ed1ab_0        conda-forge
  annotated-types                         0.6.0         pyhd8ed1ab_0        conda-forge
  anyio                                   4.0.0         pyhd8ed1ab_0        conda-forge
  apache-airflow                          2.7.2         py310hb6292c7_0     conda-forge
  apache-airflow-providers-common-sql     1.7.2         pyhd8ed1ab_0        conda-forge
  apache-airflow-providers-ftp            3.5.2         pyhd8ed1ab_0        conda-forge
  apache-airflow-providers-http           4.5.2         pyhd8ed1ab_0        conda-forge
  apache-airflow-providers-imap           3.3.2         pyhd8ed1ab_0        conda-forge
  apache-airflow-providers-sqlite         3.4.3         pyhd8ed1ab_0        conda-forge
  apispec                                 6.3.0         pyhd8ed1ab_0        conda-forge
  argcomplete                             3.1.2         pyhd8ed1ab_0        conda-forge
  argon2-cffi                             23.1.0        pyhd8ed1ab_0        conda-forge
  argon2-cffi-bindings                    21.2.0        py310h2aa6e3c_4     conda-forge
  arrow                                   1.3.0         pyhd8ed1ab_0        conda-forge
  asgiref                                 3.7.2         pyhd8ed1ab_0        conda-forge
  async-timeout                           4.0.3         pyhd8ed1ab_0        conda-forge
  atk-1.0                                 2.38.0        hcb7b3dd_1          conda-forge
  attrs                                   23.1.0        pyh71513ae_1        conda-forge
  babel                                   2.13.0        pyhd8ed1ab_0        conda-forge
  backoff                                 2.2.1         pyhd8ed1ab_0        conda-forge
  backports                               1.0           pyhd8ed1ab_3        conda-forge
  backports.functools_lru_cache           1.6.5         pyhd8ed1ab_0        conda-forge
  backports.zoneinfo                      0.2.1         py310hbe9552e_8     conda-forge
  bcrypt                                  4.0.1         py310had9acf8_1     conda-forge
  billiard                                4.1.0         py310h2aa6e3c_1     conda-forge
  blinker                                 1.6.3         pyhd8ed1ab_0        conda-forge
  brotli-python                           1.1.0         py310h1253130_1     conda-forge
  brotlipy                                0.7.0         py310h2aa6e3c_1006  conda-forge
  bzip2                                   1.0.8         h3422bc3_4          conda-forge
  c-ares                                  1.20.1        h93a5062_0          conda-forge
  ca-certificates                         2023.7.22     hf0a4a13_0          conda-forge
  cachelib                                0.9.0         pyhd8ed1ab_0        conda-forge
  cairo                                   1.18.0        hd1e100b_0          conda-forge
  cattrs                                  23.1.2        pyhd8ed1ab_0        conda-forge
  celery                                  5.3.4         pyhd8ed1ab_1        conda-forge
  certifi                                 2023.7.22     pyhd8ed1ab_0        conda-forge
  cffi                                    1.16.0        py310hdcd7c05_0     conda-forge
  chardet                                 5.2.0         py310hbe9552e_1     conda-forge
  charset-normalizer                      3.3.0         pyhd8ed1ab_0        conda-forge
  click                                   8.1.7         unix_pyh707e725_0   conda-forge
  click-didyoumean                        0.3.0         pyhd8ed1ab_0        conda-forge
  click-plugins                           1.1.1         py_0                conda-forge
  click-repl                              0.3.0         pyhd8ed1ab_0        conda-forge
  clickclick                              20.10.2       pyhd8ed1ab_0        conda-forge
  colorama                                0.4.6         pyhd8ed1ab_0        conda-forge
  colorlog                                4.8.0         py310hbe9552e_3     conda-forge
  colour                                  0.1.5         py_0                conda-forge
  configupdater                           3.1.1         pyhd8ed1ab_0        conda-forge
  connexion                               2.14.2        pyhd8ed1ab_1        conda-forge
  cron-descriptor                         1.4.0         pyhd8ed1ab_0        conda-forge
  croniter                                2.0.1         pyhd8ed1ab_0        conda-forge
  cryptography                            41.0.4        py310hdd3b5e7_0     conda-forge
  deprecated                              1.2.14        pyh1a96a4e_0        conda-forge
  dill                                    0.3.7         pyhd8ed1ab_0        conda-forge
  dnspython                               2.4.2         pyhd8ed1ab_0        conda-forge
  docutils                                0.20.1        py310hbe9552e_2     conda-forge
  email-validator                         1.3.1         pyhd8ed1ab_0        conda-forge
  email_validator                         1.3.1         hd8ed1ab_0          conda-forge
  exceptiongroup                          1.1.3         pyhd8ed1ab_0        conda-forge
  expat                                   2.5.0         hb7217d7_1          conda-forge
  flask                                   2.2.5         pyhd8ed1ab_0        conda-forge
  flask-appbuilder                        4.3.6         pyhd8ed1ab_0        conda-forge
  flask-babel                             2.0.0         pyh9f0ad1d_0        conda-forge
  flask-caching                           2.1.0         pyhd8ed1ab_0        conda-forge
  flask-jwt-extended                      4.5.3         pyhd8ed1ab_0        conda-forge
  flask-limiter                           3.5.0         pyhd8ed1ab_0        conda-forge
  flask-login                             0.6.2         pyhd8ed1ab_1        conda-forge
  flask-session                           0.5.0         pyhd8ed1ab_0        conda-forge
  flask-sqlalchemy                        2.5.1         pyhd8ed1ab_0        conda-forge
  flask-wtf                               1.2.1         pyhd8ed1ab_0        conda-forge
  font-ttf-dejavu-sans-mono               2.37          hab24e00_0          conda-forge
  font-ttf-inconsolata                    3.000         h77eed37_0          conda-forge
  font-ttf-source-code-pro                2.038         h77eed37_0          conda-forge
  font-ttf-ubuntu                         0.83          hab24e00_0          conda-forge
  fontconfig                              2.14.2        h82840c6_0          conda-forge
  fonts-conda-ecosystem                   1             0                   conda-forge
  fonts-conda-forge                       1             0                   conda-forge
  freetype                                2.12.1        hadb7bae_2          conda-forge
  fribidi                                 1.0.10        h27ca646_0          conda-forge
  frozenlist                              1.4.0         py310h2aa6e3c_1     conda-forge
  furl                                    2.1.3         pyhd8ed1ab_0        conda-forge
  gdk-pixbuf                              2.42.10       h15fa40c_4          conda-forge
  gettext                                 0.21.1        h0186832_0          conda-forge
  giflib                                  5.2.1         h1a8c8d9_3          conda-forge
  google-re2                              1.1           py310h0caa01f_0     conda-forge
  googleapis-common-protos                1.61.0        pyhd8ed1ab_0        conda-forge
  graphite2                               1.3.13        h9f76cd9_1001       conda-forge
  graphviz                                8.1.0         h10878c0_0          conda-forge
  greenlet                                3.0.0         py310hd5a4765_1     conda-forge
  grpcio                                  1.59.1        py310h6121c79_0     conda-forge
  gtk2                                    2.24.33       h57013de_2          conda-forge
  gts                                     0.7.6         he42f4ea_4          conda-forge
  gunicorn                                21.2.0        py310hbe9552e_1     conda-forge
  h11                                     0.14.0        pyhd8ed1ab_0        conda-forge
  h2                                      4.1.0         pyhd8ed1ab_0        conda-forge
  harfbuzz                                8.2.1         hf1a6348_0          conda-forge
  hpack                                   4.0.0         pyh9f0ad1d_0        conda-forge
  hstspreload                             2023.1.1      pyhd8ed1ab_0        conda-forge
  httpcore                                0.18.0        pyhd8ed1ab_0        conda-forge
  httpx                                   0.25.0        pyhd8ed1ab_0        conda-forge
  hyperframe                              6.0.1         pyhd8ed1ab_0        conda-forge
  icu                                     73.2          hc8870d7_0          conda-forge
  idna                                    3.4           pyhd8ed1ab_0        conda-forge
  importlib-metadata                      6.8.0         pyha770c72_0        conda-forge
  importlib-resources                     6.1.0         pyhd8ed1ab_0        conda-forge
  importlib_resources                     6.1.0         pyhd8ed1ab_0        conda-forge
  infinity                                1.5           pyhd8ed1ab_0        conda-forge
  inflection                              0.5.1         pyh9f0ad1d_0        conda-forge
  intervals                               0.9.2         pyhd8ed1ab_0        conda-forge
  itsdangerous                            2.1.2         pyhd8ed1ab_0        conda-forge
  jinja2                                  3.1.2         pyhd8ed1ab_1        conda-forge
  jsonschema                              4.19.1        pyhd8ed1ab_0        conda-forge
  jsonschema-specifications               2023.7.1      pyhd8ed1ab_0        conda-forge
  kombu                                   5.3.2         py310hbe9552e_1     conda-forge
  lazy-object-proxy                       1.9.0         py310h2aa6e3c_1     conda-forge
  lerc                                    4.0.0         h9a09cb3_0          conda-forge
  libabseil                               20230802.1    cxx17_h13dd4ca_0    conda-forge
  libcxx                                  16.0.6        h4653b0c_0          conda-forge
  libdeflate                              1.19          hb547adb_0          conda-forge
  libexpat                                2.5.0         hb7217d7_1          conda-forge
  libffi                                  3.4.2         h3422bc3_5          conda-forge
  libgd                                   2.3.3         hfdf3952_9          conda-forge
  libglib                                 2.78.0        h24e9cb9_0          conda-forge
  libgrpc                                 1.59.1        hbcf6334_0          conda-forge
  libiconv                                1.17          he4db4b2_0          conda-forge
  libjpeg-turbo                           3.0.0         hb547adb_1          conda-forge
  libpng                                  1.6.39        h76d750c_0          conda-forge
  libprotobuf                             4.24.4        hc9861d8_0          conda-forge
  libre2-11                               2023.06.02    h1753957_0          conda-forge
  librsvg                                 2.56.3        h0db3404_0          conda-forge
  libsqlite                               3.43.2        h091b4b1_0          conda-forge
  libtiff                                 4.6.0         ha8a6c65_2          conda-forge
  libtool                                 2.4.7         hb7217d7_0          conda-forge
  libwebp                                 1.3.2         hf30222e_1          conda-forge
  libwebp-base                            1.3.2         hb547adb_0          conda-forge
  libxml2                                 2.11.5        h25269f3_1          conda-forge
  libzlib                                 1.2.13        h53f4e23_5          conda-forge
  limits                                  3.6.0         pyhd8ed1ab_0        conda-forge
  linkify-it-py                           2.0.0         pyhd8ed1ab_0        conda-forge
  lockfile                                0.12.2        py_1                conda-forge
  mako                                    1.2.4         pyhd8ed1ab_0        conda-forge
  markdown                                3.5           pyhd8ed1ab_0        conda-forge
  markdown-it-py                          3.0.0         pyhd8ed1ab_0        conda-forge
  markupsafe                              2.1.3         py310h2aa6e3c_1     conda-forge
  marshmallow                             3.20.1        pyhd8ed1ab_0        conda-forge
  marshmallow-oneofschema                 3.0.1         pyhd8ed1ab_0        conda-forge
  marshmallow-sqlalchemy                  0.26.1        pyhd8ed1ab_0        conda-forge
  mdit-py-plugins                         0.4.0         pyhd8ed1ab_0        conda-forge
  mdurl                                   0.1.0         pyhd8ed1ab_0        conda-forge
  multidict                               6.0.4         py310h8e9501a_1     conda-forge
  ncurses                                 6.4           h7ea286d_0          conda-forge
  openssl                                 3.1.3         h53f4e23_0          conda-forge
  opentelemetry-api                       1.16.0        pyhd8ed1ab_0        conda-forge
  opentelemetry-exporter-otlp             1.16.0        pyhd8ed1ab_0        conda-forge
  opentelemetry-exporter-otlp-proto-grpc  1.16.0        pyhd8ed1ab_0        conda-forge
  opentelemetry-exporter-otlp-proto-http  1.16.0        pyhd8ed1ab_0        conda-forge
  opentelemetry-proto                     1.16.0        pyhd8ed1ab_0        conda-forge
  opentelemetry-sdk                       1.16.0        pyhd8ed1ab_0        conda-forge
  opentelemetry-semantic-conventions      0.37b0        pyhd8ed1ab_0        conda-forge
  ordered-set                             4.1.0         pyhd8ed1ab_0        conda-forge
  orderedmultidict                        1.0.1         py_0                conda-forge
  packaging                               23.2          pyhd8ed1ab_0        conda-forge
  pango                                   1.50.14       hcf40dda_2          conda-forge
  passlib                                 1.7.4         pyh9f0ad1d_0        conda-forge
  pathspec                                0.11.2        pyhd8ed1ab_0        conda-forge
  pcre2                                   10.40         hb34f9b4_0          conda-forge
  pendulum                                2.1.2         py310h2aa6e3c_6     conda-forge
  phonenumbers                            8.13.22       pyhd8ed1ab_0        conda-forge
  pip                                     23.3          pyhd8ed1ab_0        conda-forge
  pixman                                  0.42.2        h13dd4ca_0          conda-forge
  pkgutil-resolve-name                    1.3.10        pyhd8ed1ab_1        conda-forge
  pluggy                                  1.3.0         pyhd8ed1ab_0        conda-forge
  prison                                  0.2.1         pyhd8ed1ab_0        conda-forge
  prompt-toolkit                          3.0.39        pyha770c72_0        conda-forge
  prompt_toolkit                          3.0.39        hd8ed1ab_0          conda-forge
  protobuf                                4.24.4        py310hc08086b_0     conda-forge
  psutil                                  5.9.5         py310h2aa6e3c_1     conda-forge
  pycparser                               2.21          pyhd8ed1ab_0        conda-forge
  pydantic                                2.4.2         pyhd8ed1ab_0        conda-forge
  pydantic-core                           2.10.1        py310had9acf8_0     conda-forge
  pygments                                2.16.1        pyhd8ed1ab_0        conda-forge
  pyjwt                                   2.8.0         pyhd8ed1ab_0        conda-forge
  pysocks                                 1.7.1         pyha2e5f31_6        conda-forge
  python                                  3.10.12       h01493a6_0_cpython  conda-forge
  python-daemon                           3.0.1         pyhd8ed1ab_1        conda-forge
  python-dateutil                         2.8.2         pyhd8ed1ab_0        conda-forge
  python-graphviz                         0.20.1        pyh22cad53_0        conda-forge
  python-nvd3                             0.15.0        pyh9f0ad1d_2        conda-forge
  python-slugify                          8.0.1         pyhd8ed1ab_2        conda-forge
  python-tzdata                           2023.3        pyhd8ed1ab_0        conda-forge
  python_abi                              3.10          4_cp310             conda-forge
  pytz                                    2023.3.post1  pyhd8ed1ab_0        conda-forge
  pytzdata                                2020.1        pyh9f0ad1d_0        conda-forge
  pyyaml                                  6.0.1         py310h2aa6e3c_1     conda-forge
  re2                                     2023.06.02    h6135d0a_0          conda-forge
  readline                                8.2           h92ec313_1          conda-forge
  referencing                             0.30.2        pyhd8ed1ab_0        conda-forge
  requests                                2.31.0        pyhd8ed1ab_0        conda-forge
  requests-toolbelt                       1.0.0         pyhd8ed1ab_0        conda-forge
  rfc3339-validator                       0.1.4         pyhd8ed1ab_0        conda-forge
  rfc3986                                 2.0.0         pyhd8ed1ab_0        conda-forge
  rich                                    13.6.0        pyhd8ed1ab_0        conda-forge
  rich-argparse                           1.3.0         pyhd8ed1ab_0        conda-forge
  rpds-py                                 0.10.6        py310hd442715_0     conda-forge
  setproctitle                            1.3.3         py310h2aa6e3c_0     conda-forge
  setuptools                              68.2.2        pyhd8ed1ab_0        conda-forge
  six                                     1.16.0        pyh6c4a22f_0        conda-forge
  sniffio                                 1.3.0         pyhd8ed1ab_0        conda-forge
  sqlalchemy                              1.4.49        py310hd125d64_1     conda-forge
  sqlalchemy-jsonfield                    1.0.1.post0   pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils                        0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-arrow                  0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-babel                  0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-base                   0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-color                  0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-encrypted              0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-intervals              0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-password               0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-pendulum               0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-phone                  0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-timezone               0.41.1        pyhd8ed1ab_0        conda-forge
  sqlalchemy-utils-url                    0.41.1        pyhd8ed1ab_0        conda-forge
  sqlparse                                0.4.4         pyhd8ed1ab_0        conda-forge
  tabulate                                0.9.0         pyhd8ed1ab_1        conda-forge
  tenacity                                8.2.3         pyhd8ed1ab_0        conda-forge
  termcolor                               2.3.0         pyhd8ed1ab_0        conda-forge
  text-unidecode                          1.3           pyhd8ed1ab_1        conda-forge
  tk                                      8.6.13        hb31c410_0          conda-forge
  types-python-dateutil                   2.8.19.14     pyhd8ed1ab_0        conda-forge
  typing-extensions                       4.8.0         hd8ed1ab_0          conda-forge
  typing_extensions                       4.8.0         pyha770c72_0        conda-forge
  tzdata                                  2023c         h71feb2d_0          conda-forge
  uc-micro-py                             1.0.1         pyhd8ed1ab_0        conda-forge
  unicodecsv                              0.14.1        py_1                conda-forge
  urllib3                                 2.0.6         pyhd8ed1ab_0        conda-forge
  vine                                    5.0.0         pyhd8ed1ab_1        conda-forge
  wcwidth                                 0.2.8         pyhd8ed1ab_0        conda-forge
  werkzeug                                2.2.3         pyhd8ed1ab_0        conda-forge
  wheel                                   0.41.2        pyhd8ed1ab_0        conda-forge
  wrapt                                   1.15.0        py310h2aa6e3c_1     conda-forge
  wtforms                                 3.0.1         pyhd8ed1ab_0        conda-forge
  xz                                      5.2.6         h57fd34a_0          conda-forge
  yaml                                    0.2.5         h3422bc3_2          conda-forge
  yarl                                    1.9.2         py310hd125d64_1     conda-forge
  zipp                                    3.17.0        pyhd8ed1ab_0        conda-forge
  zlib                                    1.2.13        h53f4e23_5          conda-forge
  zstd                                    1.5.5         h4f39d0f_0          conda-forge

Environment info
❯ micromamba info                                                                                (airflow310)

       libmamba version : 1.5.1
     micromamba version : 1.5.1
           curl version : libcurl/8.1.2 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.51.0
     libarchive version : libarchive 3.5.3 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.8
       envs directories : /Users/juan_cano/.micromamba/envs
          package cache : /Users/juan_cano/.micromamba/pkgs
                          /Users/juan_cano/.mamba/pkgs
            environment : airflow310 (active)
           env location : /Users/juan_cano/.micromamba/envs/airflow310
      user config files : /Users/juan_cano/.mambarc
 populated config files :
       virtual packages : __unix=0=0
                          __osx=13.6=0
                          __archspec=1=arm64
               channels :
       base environment : /Users/juan_cano/.micromamba
               platform : osx-arm64

@astrojuanlu, I think that is probably something to report upstream to
https://github.com/apache/airflow/issues
They don't have any constraint on httpx:
https://github.com/apache/airflow/blob/2.7.2/setup.cfg#L105
It wouldn't be a good idea if we start adding constraints here on conda-forge that don't match the upstream package unless the reason for it is specific to conda-forge.

@astrojuanlu, I just noticed the downgrade of httpcore.  That may very well be the problem, and it may be conda-forge specific.  I'll look into it and try to fix httpx if I can.

@astrojuanlu, I looked into this further.  HTTPTransport was added to httpx in 0.17.0:
https://github.com/encode/httpx/releases/tag/0.17.0
So this is unrelated to httpcore and it seems to be a problem that should be reported upstream as I suggested above.  I will put this constraint here with a note, though.

@astrojuanlu, one more update on this.  I think the issue is maybe with conda-forge's version of dnspython.  The stack trace you posted seems to suggest that's where the call to httpx is originating from.  I will see if I can fix things there.  I likely won't merge #122 unless I can't fix things elsewhere.

Okay, I think the problem was that httpcore and httpx were unconstrained in https://github.com/conda-forge/dnspython-feedstock/pull/13
I have now constrained both in:
https://github.com/conda-forge/dnspython-feedstock/pull/14
If that doesn't take care of the problem, I will need to patch the old build, too.

@astrojuanlu, sorry this has been all over the place.  I believe it is solved now.  I ran:
mamba create -y -n test python=3.10 airflow

I now see:
$ mamba list -n test httpx
# packages in environment at /home/xylar/mambaforge/envs/test:
#
# Name                    Version                   Build  Channel
httpx                     0.25.0             pyhd8ed1ab_0    conda-forge
$ mamba list -n test dnspython
# packages in environment at /home/xylar/mambaforge/envs/test:
#
# Name                    Version                   Build  Channel
dnspython                 2.4.2              pyhd8ed1ab_1    conda-forge

Thanks for the blazing fast response! For consistency I can check again on macOS tomorrow, but at least on Linux I tried the same commands and I get proper versions of everything now 👍🏽

Let me know if this worked on OSX, too.

I confirm it works 👍🏽 Thanks again!

authors: astrojuanlu xylar

repo: conda-forge/airflow-feedstock


text:
Upgrade to 19.11

I think patch 11 is available for some time now, let's see if it works!
Checklist

[X] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[X] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[X] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to re-render for you, but it looks like there was nothing to do.

For the record, ./update_amber --check-updates --verbose=4 prints out the changelog associated with each update. The 19.10 -> 19.11 changelog is:

update.11 (modifies sander, rism3d.snglpnt, nab)
Released on December 17, 2019 (written by Tyler Luchko)
Description:
Add a cluster size check for cluster-particle interaction in RISM treecode
Additional changes include

Modifying cluster size check for TCF
Adding more robust check for TCF and DCF treecode asymptotics
modified syntax for passing writeVolume subroutine
workarounds for PGI compiler
fix for corner case in determining the k-space cutoff

source: gharchive/pull-request

authors: conda-forge-linter jaimergp jchodera

repo: conda-forge/ambertools-feedstock


text:
Remove noarch flag

See also: https://github.com/conda/conda-build/issues/2357

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter oschuett

repo: conda-forge/appmode-feedstock


text:
Update to v1.2

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

repo: conda-forge/array-api-compat-feedstock


text:
Rebase py3.12 support  to v1.1.1

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

No valid build backend found for Python recipe for package autogluon.common using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.

authors: conda-forge-admin suzhoum


text:
Try UCRT gcc on Windows

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Would close #31

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

@isuruf -- does using the UCRT gcc on Windows not give access to executables called gcc/g++?

gxx_win-64 doesn't. It's in gxx.

My latest attempt was using gxx. Are they not available in cmd prompts I wonder?

@isuruf - is g++ on Windows 32 bit? I'm getting OOM errors I wouldn't expect

is g++ on Windows 32 bit?

No, it's x86_64.

@conda-forge-admin, please rerender

Superseded by #55

authors: WardBrian isuruf

repo: conda-forge/cmdstan-feedstock


text:
libiconv 1.15 and 1.16 are compatible

Fixes https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/issues/80
cc @scopatz

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Do we need to adjust the iconv run exports and pinning expression to pin only to the major version?

No, because 1.17 might not be compatible.

I see. So to summarize we'd like to have a system that does more fine-grained ABI compatibility so that we can avoid shipping a version every now and then.

I didn't understand your comment. Summary is that for packages that doesn't use semver, we have to pin strict and loosen when we know that the versions are compatible.

Right OFC. But I'd be nice to automate the loosening of the pins and if we did that, it should happen on a case-by-case basis for each new version.

Sure. It would be nice to have.
Merge?

ofc merge away!

Can we get that up as an issue though? Esp for the new spec x.x might not be very descriptive. It might be better to explicitly define the min and max compatible versions. This would cover most cases, at least until packages return to a previous ABI. In this case that would have been a change on the feedstock, when it got the version bump it would have bumped the max compatible version.

In this case that would have been a change on the feedstock, when it got the version bump it would have bumped the max compatible version.

No, metadata in downstream packages need to be fixed.

authors: CJ-Wright beckermr conda-forge-linter isuruf


text:
Try to get that sweet openssl3 migration

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

The reason for this PR is that CouchDB builds against openssl 3, and then breaks when another dependency is on 1.1.
There is a migration for that but it's not being applied: https://conda-forge.org/status/#openssl3 https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/migrations/openssl3.yaml

authors: conda-forge-linter pepijndevos

repo: conda-forge/couchdb-feedstock


text:
Test python interface for OSX

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

This is a test to see if the dspsr python interface can be built currently for OSX.  It builds successfully on my local Mac dev system, and I don't remember at this point why we had to disable it for conda-forge.  Re-enabling it here as a test to see what happens.

@conda-forge-admin, please rerender

No compile errors but the import fails with missing symbols:
2023-10-04T18:17:51.8898100Z import: 'dspsr'
2023-10-04T18:18:02.0494810Z Traceback (most recent call last):
2023-10-04T18:18:02.0595720Z   File "/Users/runner/miniforge3/conda-bld/dspsr_1696442524944/test_tmp/run_test.py", line 2, in <module>
2023-10-04T18:18:02.0674520Z     import dspsr
2023-10-04T18:18:02.0777420Z   File "/Users/runner/miniforge3/conda-bld/dspsr_1696442524944/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/python3.11/site-packages/dspsr.py", line 12, in <module>
2023-10-04T18:18:02.0872860Z     import _dspsr
2023-10-04T18:18:02.0940900Z ImportError: dlopen(/Users/runner/miniforge3/conda-bld/dspsr_1696442524944/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/python3.11/site-packages/_dspsr.so, 2): Symbol not found: __ZN3dsp8SKLimits11calc_limitsEv
2023-10-04T18:18:02.1013270Z   Referenced from: /Users/runner/miniforge3/conda-bld/dspsr_1696442524944/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/python3.11/site-packages/../../libdspdsp.0.dylib
2023-10-04T18:18:02.1101240Z   Expected in: flat namespace
2023-10-04T18:18:02.1182600Z  in /Users/runner/miniforge3/conda-bld/dspsr_1696442524944/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/python3.11/site-packages/../../libdspdsp.0.dylib
2023-10-04T18:18:03.2636400Z Tests failed for dspsr-2023.10.03-py311h944f1b1_3.conda - moving package to /Users/runner/miniforge3/conda-bld/broken

Will investigate more offline.

repo: conda-forge/dspsr-feedstock


text:
bump version to force an OSX rebuild

OSX build did not succeed with initial build. Attempt to force a new build.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter hobu

repo: conda-forge/entwine-feedstock


text:
Windows support

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [25]

Hmm, need curses

Does fish itself actually have Windows support (outside of WSL)?

Yes with Cygwin

authors: conda-forge-linter jonashaag mdraw

repo: conda-forge/fish-feedstock


text:
Try to use geofileops_rc channel to evade rc channel of all underlying dependencies being used

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Note to self: I didn't change the build number, hoping that I can overwrite the label this way... we'll see...

authors: conda-forge-linter theroggy

repo: conda-forge/geofileops-feedstock


text:
Add sed hack to allow conda to set the python shebang

This PR adds a sed command to patch all of the python scripts in such a way that allows conda-build to override the shebang on install. This means that the scripts installed in a users's environment will end up with a shebang that looks like
#!/path/to/prefix/bin/python

which is more robust relative to PATH manipulation etc.
@myNameIsPatrick, please confirm that this is kosher.
Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@duncanmmacleod, looks good to me! Feel free to proceed and thanks for the addition.

repo: conda-forge/gstlal-feedstock


text:
New version 0.4.1

Checklist

[ x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I was trying to look for recipes to lint for you, but it appears we have a merge conflict.
Please try to merge or rebase with the base branch to resolve this conflict.
Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: benvial conda-forge-linter

repo: conda-forge/gyptis-feedstock


text:
Rebuild lalinference-1.11.6 for gsl26

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

The build section contained an unexpected subsection name. error_overdepending is not a valid subsection name.
The build section contained an unexpected subsection name. error_overlinking is not a valid subsection name.

authors: conda-forge-linter duncanmmacleod

repo: conda-forge/lalinference-feedstock


text:
updated v1.16

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter jschueller

repo: conda-forge/libiconv-feedstock


text:
MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've rerendered the recipe as instructed in #12.
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

Fixes #12

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin rerender

authors: beckermr conda-forge-linter

repo: conda-forge/meds-feedstock


text:
Updated mlconjug to version 3.7.16.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: SekouDiaoNlp conda-forge-linter


text:
Bump ncagg to v0.8.13

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

repo: conda-forge/ncagg-feedstock


text:
Build GUI

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

This is in the too hard basket ..


text:
Manual Python 3.11 migration

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Duplicate of gh-111.
(This also needs some extra work to that I'm handling in gh-111.)

authors: conda-forge-linter jan-janssen mbargull

repo: conda-forge/pymatgen-feedstock


text:
Remove dependency on visualization

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@conda-forge-admin, please rerender

I opened a corresponding pull request upstream https://github.com/pyscal/pyscal/pull/134

Closes https://github.com/conda-forge/pyscal-feedstock/pull/54

I noticed I forgot to increase the version number ... .

Luckily the version number is increased in https://github.com/conda-forge/pyscal-feedstock/pull/57 so we are fine.

authors: conda-forge-linter jan-janssen

repo: conda-forge/pyscal-feedstock


text:
Try update to 5.15.2.1

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

I guess pyside2-5.15.2 needs qt5.15 which is currently worked on:
https://anaconda.org/conda-forge/qt-main/files

@jan-janssen there is now a qt-main package. Maybe you can try this one:
https://anaconda.org/conda-forge/qt-main

authors: conda-forge-linter jan-janssen looooo


text:
update to 5.19.5

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: conda-forge-linter fbergmann


text:
Update Quetz to v0.10.4

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

repo: conda-forge/quetz-feedstock


text:
Update to version 0.0-3, update recipe

Checklist

[x] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter dbast


text:
MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've rerendered the recipe as instructed in #13.
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

Fixes #13

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge/core, looks like this feedstock is abandoned. I'm adding myself.

Fixes https://github.com/conda-forge/sed-feedstock/issues/12

Do you mind waiting a day just to make sure it is actually abandoned?

Sure. No hurry

@conda-forge-admin, rerender

authors: conda-forge-linter isuruf scopatz

repo: conda-forge/sed-feedstock


text:
@conda-forge-admin, please add bot automerge

[ ] I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

Environment (conda list):

$ conda list

Details about  conda and system ( conda info ):

$ conda info

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/shadow3-feedstock#3.

authors: conda-forge-linter kbeeperez


text:
@conda-forge-admin,please add bot automerge

Additional comment:
https://github.com/conda-forge/unicorn-binance-trailing-stop-loss-feedstock/issues/5

Hi! This is the friendly automated conda-forge-webservice.
I've added bot automerge as requested, but nothing actually changed.

authors: conda-forge-linter oliver-zehentleitner


text:
Support for JupyterLab 4

Context
Nebari (a major user of conda-store) will soon move to JupyterLab 4. It'll be nice to start testing if this extension works with JLab 4, and scope any incompatibilities.
Value and/or benefit
Upgrade to latest tools
Anything else?
This was discussed in the Nebari meeting today

Status update: not actively working on this because I was asked to focus on other things for now.

I have created a PR for this and #33 here: #34

authors: isumitjha nkaretnikov pavithraes

repo: conda-incubator/jupyterlab-conda-store


text:
Test all platforms with explicit example

Looks like I failed to add a windows test for #74, and windows line endings are not picked up by the \n@EXPLICIT\n check, leading to brokenedness. Hopefully the regex ^ will figure it out...

The old conda on win-64 cannot deal with .conda files...  presumably there is a way to make sure conda-lock doesn't do that. in the meatime, replaced the example solve with a lock of conda-lock itself, which doesn't generate publish .conda packages, only .tar.bz2... yet... sigh.

Great, that worked. Realized that the channels warning is also meaningless in the case of an explicit, so have squashed that as well...

So maybe now is time to make a new release?

My guinea pig with the lock files at least got to that point:
https://github.com/krassowski/jupyterlab-lsp/pull/348/checks?check_run_id=1216668382
...so :+1: to release from my side

authors: bollwyvl goanpeca

repo: conda-incubator/setup-miniconda


text:
Fix 404s on reload

Currently (with github pages), reloading the app leads to a 404.
For example, try to enter https://confio.github.io/code-explorer/codes/2
You can however go to https://confio.github.io/code-explorer/ and then click on the second code.
I had the same issue in name-app and used HashRouter which is a wee bit uglier but works.
Suggestion of HashRouter: https://stackoverflow.com/a/46060999
Other is to use a custom 404 page with some magic redirecting javascript: https://www.pluralsight.com/guides/deploying-cra-to-github-pages-using-react-router

Arg, this you don't realize when using the explorer from the start page only.
I don't like the workaround, at it adds too much indirection for nice URL which we don't really need. So until gh-pages get's a native fallback feature, I'll go with the HashRouter.

Here we go: https://confio.github.io/code-explorer/#/contracts/cosmos1ym5m5dw7pttft5w430nxx6uat8f84ck4algmhg
I implemented a router type setting, so more sophisticated deployments can easily change back to BrowserRouter.

repo: confio/code-explorer


text:
serde changes

I've been building some lightweight abstractions to facilitate stateful stream processing in .NET. As part of that effort, i've been making a lot of composite serdes and this has highlighted some API usability issues. So we need an RC4.

SerializationContext was included in the non-async serde interface for consistency with the async serdes, but it'll never be used. It's been annoying to specify SerializationContext.Empty everywhere in these composite serdes (not to mention a bit less efficient), so I took this out. This really makes the non-async serde abstractions more generally useful. Note: SerializationContext is still an awesome abstraction and a great way to think about the async case.

In the async case, having serdes as classes (implementing interfaces) is a good idea because they typically need to own state, and using closures proved to be awkward in achieving this. The additional justification for interfaces is that they can be extended (are future proof), whereas delegates can't. That argument was enough for us to go with interfaces for the non-async case as well (particularly as the serializer interface isn't optimal and just something we're using until we implement something better). However, that reasoning was made before we introduced the builder classes. These provide an alternate (and better) point of extensibility - allow any number of different serde interfaces / delegates. The downside of interfaces is it means specifying the serdes is more verbose. I was arguing this is not a big deal (it's not something that needs to happen often), which is still true, but that said I've been specifying these a fair bit in the above mentioned project, and it's meaningfully nicer for them to be straight functions.

Our serializer API is not as efficient as it could be. This is a known issue - we intentionally cut scope to get 1.0 out sooner since working out what is best and implementing it is non-trivial. Why bring this up now? Creating composite serializers has really highlighted this inefficiency - there's no way around creating lots of temporary byte[] objects. I'm not proposing fixing this now, but i'm proposing changing the name of the delegate to SimpleSerializer, leaving the name Serializer open for the final delegate type. Note, the deserializer side is easier and already very efficient (so no name change there).

Changing to delegates from interfaces is a huge breaking change really messes with what I'm working on. Things lik:e being able to resolve a set of serdes from a DI container; Having types and pattern matching; Resolving types from config with Type.GetType(name)  etc etc
Having SerializationContext is generally useful in both sync and async. No need to specify SerializationContext.Empty everywhere: just default will work fine; Or make the arg optional ... , SerializationContext ctx = default); Or add an extension method to do it for you.
The ReadOnlyMemory vs ReadOnlySpan thing is a pita. It would be nice to make the arg signatures identical. No idea how to do that though :(
+1,000,000 for leaving them as interfaces

thanks for the feedback. keep it coming!
I expect to add SerializationContext on the sync interface as a solution to the async problems (based on idea from you). Given your use cases for interfaces, i'll reinstate that as well. May or may not also have a Deserializer delegate type, which is also useful.

cool...
I guess it'd be simple enough to create some helper/adapters to "convert" from one to the other.
Q: Is it possible t describe the situation where delegates are working better for you?

i'm working on a mini stream processing framework. In that, i'm creating composite serdes in a fair few places and the SerializationContext was getting in the way. Also, the code could be shortened a fair bit by specifying these inline with delegates in places.

Sounds like another builder/fluent interface would work well. Wrapping
whatever delegate signatures you need with classes impl the interfaces
class DelegateSerializer<T>:ISerializer<T>
{
  private ro delegate serDelegate;
  ctor(delegate)
  {
    serDelegate = delegate;
  }
  public void Serialize(...) => serDelegate(...);
}

On Fri, 12 Apr 2019 at 15:43, Matt Howlett notifications@github.com wrote:

i'm working on a mini stream processing framework. In that, i'm creating
composite serdes in a fair few places and the SerializationContext was
getting in the way. Also, the code could be shortened a fair bit by
specifying these inline with delegates in places.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/confluentinc/confluent-kafka-dotnet/pull/867#issuecomment-482600631,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAvrq_mRgVC6OOZkihHrl962QFihdRFGks5vgJt6gaJpZM4cgQ5L
.

authors: AndyPook mhowlett

repo: confluentinc/confluent-kafka-dotnet


text:
fix: Support for noop "upgrade" from/to same version

Description
I am expecting an attempt to "upgrade" from/to same version to be a noop - i.e. idempotent. This does not seem to be the case, and this PR is an attempt to fix this.
To reproduce (with reference to Upgrade Confluent Platform with Ansible Playbooks):
git checkout 6.0.2-post
ansible-playbook -i /path/to/hosts.yml upgrade_kafka_broker.yml -e kafka_broker_upgrade_start_version=6.0

Expected behavior:

Playbook runs without errors, but no Kafka Broker hosts are upgraded.

Actualt behavior:
TASK [Set Inter-Broker Protocol Version to Current Version] ********************
fatal: [<kafka_broker host>]: FAILED! =>
  msg: |-
    The task includes an option with an undefined variable. The error was: 'inter_broker_protocol_version' is undefined

    The error appears to be in '<path>/cp-ansible/upgrade_kafka_broker.yml': line 33, column 7, but may
    be elsewhere in the file depending on the exact syntax problem.

    The offending line appears to be:

        - name: Set Inter-Broker Protocol Version to Current Version
          ^ here

Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Verified the expected behavior against one of our 6.0 clusters.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Any dependent changes have been merged and published in downstream modules
[ ] Any variable changes have been validated to be backwards compatible

Nice catch!

authors: domenicbove erikgb

repo: confluentinc/cp-ansible


text:
Replace "cluster.local" in Zookeeper chart

Please replace "cluster.local" with a helm variable for cluster name. Otherwise, this chart can't be used with other cluster names (e.g. "production", "integration").
See:
https://github.com/confluentinc/cp-helm-charts/blob/df888a1b51e2031b6afc218d5f0f1389e96dca63/charts/cp-zookeeper/templates/_helpers.tpl#L45

Sorry, there is already a Pull request for this issue.
https://github.com/confluentinc/cp-helm-charts/pull/128

repo: confluentinc/cp-helm-charts


text:
Type annotations using the pipe symbol (|) for union types are not supported in Python versions earlier than 3.10.

some classes or funcs use "|" for type annotations, for example class CroppedTable: def __init__ and def image and class RotatedCroppedTable def image, which make my running on python3.9 raise Error

Okay, I finally addressed this issue with 1698a31. I've been developing on python 3.10 and haven't actually tested on 3.9 but let me know what else comes up.

authors: conjuncts jiauy

repo: conjuncts/gmft


text:
Allow commands being send via intents

Since Intents can already open a (possibly new) connection, I added support for adding a little extra. With this PR it's possible to execute a command within a connection (newly created or already opened, doesn't matter).
The user gets prompted if the command should be executed as a security feature. And of course the prompt can be disabled via preferences.
While testing the new feature i found a small bug (NullPointerException), when opening a connection with no nickname provided.
This would solve #57.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

repo: connectbot/connectbot


text:
Multiple DLCs Missing From Website

Multiple modern DLCs are missing from the website. I'm not sure if this is intended or a bug, but I thought I would bring up an issue here in case it is a bug. Here are some examples:
CDProjektRed has the witcher DLCs but not Cyberpunk Phantom Liberty: https://vglist.co/companies/344
Fromsoftware has the dark souls DLCs but not Shadow of the Erdtree:
https://vglist.co/companies/32

Yeah, there isn't really an official system right now for DLC/expansions, it's been something I've toyed with a bit but haven't actually gone through and properly implemented. So that's why there's usually not coverage of it right now.

authors: connorshea pettta

repo: connorshea/vglist


text:
Remove reliance on Sprockets

Cherry-picked a few commits from #2419.
Sprockets can be fully replaced by Webpacker, so there's no reason to continue using it. This changes all usages of static images to use Webpacker instead of Sprockets. Rails 7 removes Sprockets as a hard dependency, and there's no harm backporting this change for Rails 6.1 to make Sprockets' removal easier in the Rails 7 upgrade. So here we are. Goodbye, Sprockets.

This caused a production failure when deployed, which I fixed with 1deecd44d8143927b4efc2f1e242cf45dd3b1507. Turns out you also need to remove the config.assets.* options or things will catch on fire.


text:
Add Troy token

团队背景：
创始团队具有多年金融科技行业的连续创业经验，来自Huobi，OKex，Binance的核心管理团队背景，在产品能力、技术实力、交易能力和战略能力上面表现卓越，具备构建杀手级交易科技产品的基因。
TROY联合创始人 Kira Sun，北京大学光华管理学院金融系学士，清华大学经济管理学院-MIT全球工商管理硕士；曾任中信信托有限责任公司信托经理，主导多项REITS、ABS、PPP等大型资产管理项目，拥有丰富的加密资产管理经验，参与了包括BVC16、Pure Alpha等多款被动和主动的产品设计。
Qihan Lin，本硕均毕业于上海交通大学数学系，主修计算数学，擅长衍生品的定价和交易，曾就职在东方财富、老虎证券和OKEx，从事产品工作，作为核心产品经理主导了老虎证券期货衍生品交易产品，以及OKEx的OK06指数和相关ETF产品的设计和开发，对于国内外股票券商和数字货币交易都有深入理解。
项目基本情况：
TROY作为全球加密数字领域的主经纪商(Prime Broker)，致力于打造开放式的全球交易和清结算网络协议Troy Network，并通过Troy Trade向数字资产和加密货币的专业级客户提供革命性的交易产品及经纪服务，真正实现加密经济在全球范围内的高效流转。
更多关于 TROY 的信息

官网: https://troytrade.com/
Medium: https://medium.com/@troymessage911
Telegram: https://t.me/TroyTrade_Official
Twitter:https://twitter.com/troytrade

媒体报道：
Forbes: https://www.forbes.com/sites/ilkerkoksal/2019/09/23/prime-brokerage-as-the-go-to-solution-for-investors-in-the-crypto-market/#3fa851a26549
MarketWatch: https://www.marketwatch.com/story/binance-hosts-ieo-for-prime-broker-troytrade-what-does-it-mean-for-the-bitcoin-market-2019-12-04?mod=investing&source=post_page-----b86a4726f0ec----------------------
NewsBTC: https://www.newsbtc.com/2019/11/28/troy-trade-announces-token-sale-on-binance-launchpad/
收录的交易所：
Binance
Binance DEX
代币转账调用智能合约需要的 Gas limit: 60000

存在较多问题：
1、logo不符合要求
2、缺少官方公告
3、请检查checksum

官方公告：
TROY即将登陆imToken钱包
#imToken# #5395# TROY团队正在和imToken团队积极接洽合作，完善 TROY 在 imToken 中的相关资料。完成收录后，用户便可以在 imToken 钱包里找到TROY logo，更方便快捷得管理 TROY，同时看到更多相关信息。
https://m.weibo.cn/status/4450521941008465?
团队背景：
创始团队具有多年金融科技行业的连续创业经验，来自Huobi，OKex，Binance的核心管理团队背景，在产品能力、技术实力、交易能力和战略能力上面表现卓越，具备构建杀手级交易科技产品的基因。
TROY联合创始人 Kira Sun，北京大学光华管理学院金融系学士，清华大学经济管理学院-MIT全球工商管理硕士；曾任中信信托有限责任公司信托经理，主导多项REITS、ABS、PPP等大型资产管理项目，拥有丰富的加密资产管理经验，参与了包括BVC16、Pure Alpha等多款被动和主动的产品设计。
Qihan Lin，本硕均毕业于上海交通大学数学系，主修计算数学，擅长衍生品的定价和交易，曾就职在东方财富、老虎证券和OKEx，从事产品工作，作为核心产品经理主导了老虎证券期货衍生品交易产品，以及OKEx的OK06指数和相关ETF产品的设计和开发，对于国内外股票券商和数字货币交易都有深入理解。
项目基本情况：
TROY作为全球加密数字领域的主经纪商(Prime Broker)，致力于打造开放式的全球交易和清结算网络协议Troy Network，并通过Troy Trade向数字资产和加密货币的专业级客户提供革命性的交易产品及经纪服务，真正实现加密经济在全球范围内的高效流转。
更多关于 TROY 的信息
官网: https://troytrade.com/
Medium: https://medium.com/@troymessage911
Telegram: https://t.me/TroyTrade_Official
Twitter:https://twitter.com/troytrade
媒体报道：
Forbes: https://www.forbes.com/sites/ilkerkoksal/2019/09/23/prime-brokerage-as-the-go-to-solution-for-investors-in-the-crypto-market/#3fa851a26549
MarketWatch: https://www.marketwatch.com/story/binance-hosts-ieo-for-prime-broker-troytrade-what-does-it-mean-for-the-bitcoin-market-2019-12-04?mod=investing&source=post_page-----b86a4726f0ec----------------------
NewsBTC: https://www.newsbtc.com/2019/11/28/troy-trade-announces-token-sale-on-binance-launchpad/
收录的交易所：
Binance
Binance DEX
代币转账调用智能合约需要的 Gas limit: 60000

请在官网添加跳转至官方公告的链接，并修改checksum格式

请在官网添加跳转至官方公告的链接，并修改checksum格式
请问官方公告的链接最低要求放多久？谢谢

你好。
能否告知链接什么要求？比如要在官网放多久？我们目前没有这样的位置。
感谢！
--
Charlie Chen
Marketing Director, TroyTrade
Tel: +86-151 1698 1164
TG: @charliechen
WeChat: weibopare9801
Website|Announcements|LinkedIn
This e-mail and the information it contains may be confidential, legally privileged and protected by law. Access by the intended recipient only is authorised. If you are not the intended recipient, please notify the sender immediately and delete this e-mail from your system. Any review, distribution, reproduction, publication or other use of this e-mail by persons or entities other than the intended recipient is prohibited.
原始邮件
发件人:sfsy520notifications@github.com
收件人:consenlabs/token-profiletoken-profile@noreply.github.com
抄送:TroyTradecharlie@troytrade.com; Authorauthor@noreply.github.com
发送时间:2019年12月23日(周一) 12:15
主题:Re: [consenlabs/token-profile] Add Troy token (#5395)
请在官网添加跳转至官方公告的链接，并修改checksum格式
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

超链接能跳转至官方公告即可。

您好！
官网已加上超链接。
另外，您所说的检查Checksum格式可否具体一点？
谢谢！
--
Charlie Chen
Marketing Director, TroyTrade
Tel: +86-151 1698 1164
TG: @charliechen
WeChat: weibopare9801
Website|Announcements|LinkedIn
This e-mail and the information it contains may be confidential, legally privileged and protected by law. Access by the intended recipient only is authorised. If you are not the intended recipient, please notify the sender immediately and delete this e-mail from your system. Any review, distribution, reproduction, publication or other use of this e-mail by persons or entities other than the intended recipient is prohibited.
原始邮件
发件人:sfsy520notifications@github.com
收件人:consenlabs/token-profiletoken-profile@noreply.github.com
抄送:TroyTradecharlie@troytrade.com; Authorauthor@noreply.github.com
发送时间:2019年12月24日(周二) 14:06
主题:Re: [consenlabs/token-profile] Add Troy token (#5395)
超链接能跳转至官方公告即可。
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Checksum格式已修改。

官网未见跳转至官方的链接，且json文件中合约地址仍未做checksum

官网未见跳转至官方的链接，且json文件中合约地址仍未做checksum

您好。官方链接在最底部社交入口处。json中已checksum。谢谢！

欢迎在社区中推荐用户使用 imToken 2.0 管理资产。

repo: consenlabs/token-profile


text:
Poor performance with rayon ParallelIterator

When processing several hundreds of thousands of items per second with a ParallelIterator, ProgressBar becomes a bottleneck because it grabs a global shared lock whenever the state needs to be updated. Instead, it would be better to store internal progress for each rayon thread separately and sum these counters on read.
Having said that as a Rust beginner, I'm not sure how hard such implementation could be in Rust and whether Rust has a similar structure like Java LongAdder (https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/LongAdder.html).
RelaxedCounter from https://docs.rs/atomic-counter/1.0.1/atomic_counter/ maybe?

By global shared lock do you mean the stderr lock? If writing to the console is your bottleneck, you can use ProgressBar::set_draw_delta to limit the number of updates. The bigger the number you provide the less frequent the updates are going to be and thus the less locking will occur.

No, stderr is not a problem. I already tried reducing the rendering refresh rate and it didn't help at all.
The problem is the fact that the whole ProgressBar is wrapped in an RwLock :
See this in rayon_support:
    pub struct ParProgressBarIter<T> {
        it: T,
        progress: Arc<Mutex<ProgressBar>>,
    }

And also updating the internal state requires locking:
    fn update_and_draw<F: FnOnce(&mut ProgressState)>(&self, f: F) {
        let mut draw = false;
        {
            let mut state = self.state.write().unwrap();

As a quick check I tried using RelaxedCounter and it seems to work much better on my iterator that delivers about ~1 million items / second.
Here a fragment of my original code:
    let file_scan_pb = ProgressBar::new_spinner();
    file_scan_pb.set_draw_target(ProgressDrawTarget::stdout_with_hz(1));
    file_scan_pb.set_style(ProgressStyle::default_spinner().template("Scanning files: {pos}"));

    let files = ... // obtain a parallel iterator
    files
        .progress_with(file_scan_pb)
        .foreach(|item| ...);

And after changing to the counter:
    let counter = RelaxedCounter::new(0);
    let files = ... // obtain a parallel iterator
    files
        .inspect(|_| { counter.inc(); () })
        .foreach(|item| ...);

This one is about 3x faster, just as fast as without the inspect() line at all.

Oh, I see the problem now. Could you try and use an experimental branch to see if it helps?
To do that you will need to modify your Cargo.toml. Change indicatif = "0.14.0" to indicatif = { git="https://github.com/mibac138/indicatif", branch="rayon-rate-limit" }. Then try it out like so:
let pb = ...
let iter = pb.wrap_par_iter(files);
iter.set_update_delta(1000);
iter.foreach(|item| ...);

error[E0599]: no method named `wrap_par_iter` found for struct `indicatif::progress::ProgressBar` in the current scope
  --> src/main.rs:62:36
   |
62 |     let size_groups = file_scan_pb.wrap_par_iter(files)
   |                                    ^^^^^^^^^^^^^ help: there is a method with a similar name: `wrap_iter`

Oops, please make sure you also enable with_rayon feature like so indicatif = { git="https://github.com/mibac138/indicatif", branch="rayon-rate-limit, features = ["with_rayon"] }

Does not compile :(
   Compiling indicatif v0.14.0 (https://github.com/mibac138/indicatif?branch=rayon-rate-limit#555b0eb6)
error[E0425]: cannot find value `update_delta` in this scope
  --> /home/pkolaczk/.cargo/git/checkouts/indicatif-4be6e86cdcc437b6/555b0eb/src/par_iter.rs:70:36
   |
70 |         self.data.set_update_delta(update_delta);
   |                                    ^^^^^^^^^^^^ not found in this scope

error[E0609]: no field `progress` on type `&par_iter::ProgressConsumer<C>`
   --> /home/pkolaczk/.cargo/git/checkouts/indicatif-4be6e86cdcc437b6/555b0eb/src/par_iter.rs:119:64
    |
119 |         ProgressConsumer::new(self.base.split_off_left(), self.progress.clone())
    |                                                                ^^^^^^^^ unknown field
    |
    = note: available fields are: `base`, `data`

error[E0615]: attempted to take value of method `progress` on type `par_iter::ParProgressBarIter<T>`
   --> /home/pkolaczk/.cargo/git/checkouts/indicatif-4be6e86cdcc437b6/555b0eb/src/par_iter.rs:156:62
    |
156 |         let consumer1 = ProgressConsumer::new(consumer, self.progress);
    |                                                              ^^^^^^^^ help: use parentheses to call the method: `progress()`

error: aborting due to 3 previous errors

It looks like the errors are in indicatif, however I have already fixed them. Running cargo update should make it work.

Looks like it works, however I had to disable the refresh rate, because otherwise it didn't write anything at all.
update_delta = 1:
real    0m9,160s
user    0m11,640s
sys     0m12,154s

update_delta = 10:
real    0m3,252s
user    0m7,111s
sys     0m8,080s

update_delta=100:
real    0m2,612s
user    0m6,521s
sys     0m8,098s

No progressbar at all:
real    0m2,535s
user    0m6,023s
sys     0m7,870s

I'm not entirely happy with this workaround, though, because the "speed" at which my iterator is able to deliver items is heavily dependent on mny circumstances. I'd rather progress bar recorded all updates fast like in the example with the RelaxedCounter.
{noformat}

BTW: Is it possible to do a pull-based progress bar? Like - I could provide a RelaxedCounter and PB would only fetch its value and display repeatedly?

You could write your own enable_steady_tick implementation and it should work. Something like this:
let counter = Arc::new(counter); // use this in inspect(counter.inc())

let counter2 = Arc::clone(&counter);
let pb2 = pb.clone();
thread::spawn(move || {
    if Arc::strong_count(&counter2) == 1 {
        // intensive counting is over, stop updating in a separate thread
        break;
    }
    thread::sleep(interval);
    pb2.set_position(counter2.get());
});

Thank you!
This is nice:
if Arc::strong_count(&counter2) == 1 {
        // intensive counting is over, stop updating in a separate thread
        break;
    }

I believe this could be also made to hide the progress bar once the counter is destroyed. :)

I believe this hides the progress bar once the counter is dropped? Is it right?

TLDR: Yes
When a ProgressBar is dropped it is hidden unless you have called finish or finish_with_message. The problem is that for the progress bar to be dropped all Arcs holding it must be dropped too. This check makes sure that the Arc owned by the spawned thread is dropped so that the ProgressBar can be dropped too. It could be made simpler but it requires #161 which isn't yet merged.

Using @mibac138 's fork gives me a lot of
thread '<unnamed>' panicked at 'attempt to divide by zero', /home/thom/.cargo/git/checkouts/indicatif-4be6e86cdcc437b6/c716edb/src/par_iter.rs:47:26

:(

Using @mibac138 's fork gives me a lot of
thread '<unnamed>' panicked at 'attempt to divide by zero', /home/thom/.cargo/git/checkouts/indicatif-4be6e86cdcc437b6/c716edb/src/par_iter.rs:47:26

:(

Is this a use case that indicatif is intending to support as a first class option? I also ran into this issue (indicatif being the bottleneck in a hot par_iter loop and am looking for fixes.
I'm also willing to making a PR to fix/enable this with something along the enable_steady_tick route if you are open to that

FWIW, this problem is also very visible outside of rayon: I'm parsing gzipped log files that have a few million lines, and depending on the option I pick I get vastly different speeds:

If I never inc the progress bar, it takes 34 seconds
If I .wrap_read() the file (before giving it to libflate::gzip::Decoder because otherwise it's going way over 100%), it takes about 20 minutes (never actually tried waiting that long, but it's the indicatif-provided estimate)

And when parsing another, non-gzipped log file:

If I never inc the bar, it completes in 2 seconds
If I inc the bar by blocks of file size / 2048, it completes in 2 seconds
If I .wrap_read() the file, it completes in 4 seconds
If I inc the bar on each line read, it completes in 1 min 5 sec

Overall, I'd think that the best option might be to “just” make ProgressBar's internal counter an AtomicU64, and then instead of precomputing all the metadata on each inc() (which naturally requires a mutex), to re-compute it on each tick. This being said, I'm far from familiar with the internals of indicatif, so… this may be impossible for some reason I don't see? But if it is possible, I think it'd solve all the issues at the same time, while also providing the best user interface.
WDYT?

If you're reading this thread because the progressbar is slowing down your application and don't yet know exactly why, try using set_draw_rate() and check if it still does. In my usage of indicatif I found that the application is primarily bottlenecked on terminal output, not any of what OP is talking about, even when processing 10k items per second. See also #363

If someone can retest this against current main and still sees bad performance, I'd like to hear about it. The internal locking is still pretty much the same, but a bunch of other improvements should have improved performance.

In recent versions set_draw_delta is gone and only enable_steady_tick remains. Can we get maintainer guidance on the performance impact?

pb.enable_steady_tick(Duration::from_secs(30));

Draws less often to screen, but based on time. It appears now there's not a way to minimize draws based on number of input elements (what we could do with set_draw_delta).
0.16.2:
    /// Limit redrawing of progress bar to every `n` steps
    ///
    /// By default, the progress bar will redraw whenever its state advances. This setting is
    /// helpful in situations where the overhead of redrawing the progress bar dominates the
    /// computation whose progress is being reported.
    ///
    /// If `n` is greater than 0, operations that change the progress bar such as
    /// [`ProgressBar::tick()`], [`ProgressBar::set_message()`] and [`ProgressBar::set_length()`]
    /// will no longer cause the progress bar to be redrawn, and will only be shown once the
    /// position advances by `n` steps.
    ///
    /// ```rust,no_run
    /// # use indicatif::ProgressBar;
    /// let n = 1_000_000;
    /// let pb = ProgressBar::new(n);
    /// pb.set_draw_delta(n / 100); // redraw every 1% of additional progress
    /// ```
    ///
    /// Note that `ProgressDrawTarget` may impose additional buffering of redraws.
    pub fn set_draw_delta(&self, n: u64) {
        let mut state = self.state.lock().unwrap();
        state.draw_delta = n;
        state.draw_next = state.pos.saturating_add(state.draw_delta);
    }

Haven't read lib code deeply yet but my understanding is these choices have a performance impact.

For set_draw_delta that I see above there, seems obvious we'd want to avoid a lock in favor of some type of atomic counter (as mentioned above). But haven't dug into the mechanics of the timed ticker.

[Just to step back a bit in case it helps.]
For me a couple use cases mix: I want to conditionalize the progress bar based on whether tty is available. When it's not, seems better to remove certain styles. But it's also the case that in non-tty we really don't want to redraw to screen frequently. But if mechanisms to redraw less frequently are non-performant in some way, or if indicatif itself is a potential performance bottleneck`, I would wrap things differently such that I don't use it at all in most situations.

Nice, I see stdout_with_hz. But same q: does this actually help, hurt, or have no impact on general performance of indicatif?

Nice, I see stdout_with_hz. But same q: does this actually help, hurt, or have no impact on general performance of indicatif?

To be honest, I'm not sure. But I would sincerely hope that it would help, or at the very least have no impact. I think if using it negatively impacted performance, then that would be a bug in indicatif.

The draw delta API was removed because there's now implicit rate limiting in indicatif by default. I think when I measured it for the 0.17 release (probably a good idea to read the release notes) it was like a 100x faster in the default configuration. Also progress is now measured with an atomic value there is no more lock contention for the simplest case. In general I think this issue should be closed as the performance issues have been addressed since it was opened.

Cool! FWIW I'll leave this benchmark here.
results
read_parquet_without_progress
time:   [1.1644 s 1.1664 s 1.1687 s]

read_parquet_with_progress
time:   [1.2880 s 1.2903 s 1.2929 s]

read_parquet_with_progress_reduced
time:   [1.2975 s 1.2998 s 1.3022 s]

Seems like adding Progress does have some slightly impact, but this is hardly scientific. Will update if I dive deeper.
code
use criterion::{criterion_group, criterion_main, Criterion};
use indicatif::{ProgressBar, ProgressDrawTarget, ProgressStyle};
use parquet::file::reader::{FileReader, SerializedFileReader};
use parquet::record::Row;
use std::fs::File;

/// File Name: /tmp/reducer.snappy.parquet: 12916 rows
/// Uncompressed Size: 13,141,913
const PARQUET_FILE_PATH: &str = "/tmp/reducer.snappy.parquet";

fn read_parquet_file(path: &str) -> Vec<Row> {
    let file = File::open(path).expect("Failed to open file");
    let reader = SerializedFileReader::new(file).expect("Failed to create reader");
    let iter = reader
        .get_row_iter(None)
        .expect("Failed to get row iterator");

    iter.filter_map(Result::ok).collect::<Vec<Row>>()
}

fn read_parquet_file_with_progress(path: &str) -> Vec<Row> {
    let file = File::open(path).expect("Failed to open file");
    let reader = SerializedFileReader::new(file).expect("Failed to create reader");
    let metadata = reader.metadata();
    let row_group_count = metadata.num_row_groups();

    let pb = ProgressBar::new(row_group_count as u64);
    pb.set_style(
        ProgressStyle::default_bar()
            .template("{msg} [{bar:40.cyan/blue}] {pos:>7}/{len:7} ({percent}%)")
            .expect("valid template")
            .progress_chars("##-"),
    );
    pb.set_message("Reading Parquet");

    let mut rows = Vec::new();
    for row_group_index in 0..row_group_count {
        let row_group_reader = reader
            .get_row_group(row_group_index)
            .expect("Failed to get row group");
        let row_iter = row_group_reader
            .get_row_iter(None)
            .expect("Failed to get row iterator");

        rows.extend(row_iter.filter_map(Result::ok));
        pb.inc(1);
    }

    pb.finish_with_message("Done reading Parquet");

    rows
}

fn read_parquet_file_with_progress_reduced(path: &str) -> Vec<Row> {
    let file = File::open(path).expect("Failed to open file");
    let reader = SerializedFileReader::new(file).expect("Failed to create reader");
    let metadata = reader.metadata();
    let row_group_count = metadata.num_row_groups();

    let pb = ProgressBar::new(row_group_count as u64);
    pb.set_style(
        ProgressStyle::default_bar()
            .template("{msg} [{bar:40.cyan/blue}] {pos:>7}/{len:7} ({percent}%)")
            .expect("valid template")
            .progress_chars("##-"),
    );
    pb.set_message("Reading Parquet");
    pb.set_draw_target(ProgressDrawTarget::stdout_with_hz(1));

    let mut rows = Vec::new();
    for row_group_index in 0..row_group_count {
        let row_group_reader = reader
            .get_row_group(row_group_index)
            .expect("Failed to get row group");
        let row_iter = row_group_reader
            .get_row_iter(None)
            .expect("Failed to get row iterator");

        rows.extend(row_iter.filter_map(Result::ok));
        pb.inc(1);
    }

    pb.finish_with_message("Done reading Parquet");

    rows
}

fn parquet_read_benchmark(c: &mut Criterion) {
    c.bench_function("read_parquet_without_progress", |b| {
        b.iter(|| {
            let rows = read_parquet_file(PARQUET_FILE_PATH);
            criterion::black_box(rows);
        });
    });

    c.bench_function("read_parquet_with_progress", |b| {
        b.iter(|| {
            let rows = read_parquet_file_with_progress(PARQUET_FILE_PATH);
            criterion::black_box(rows);
        });
    });

    c.bench_function("read_parquet_with_progress_reduced", |b| {
        b.iter(|| {
            let rows = read_parquet_file_with_progress_reduced(PARQUET_FILE_PATH);
            criterion::black_box(rows);
        });
    });
}

criterion_group!(benches, parquet_read_benchmark);
criterion_main!(benches);

A 10% impact is definitely more than I would expect, but I won't have time to dig in much deeper. Interested in your results if you do, though!

authors: Ekleog chris-laplante djc mibac138 mooreniemi pkolaczk sstadick thomwiggers untitaker

repo: console-rs/indicatif


text:
Extra dependencies for Preferences

With the basic preferences the only dependency we can use is a CheckBoxPreference. In many cases it would be great to define the dependencies in XML for other types as well.
A few examples:
Dependency for ListPreference value (e.g. android:dependency="myListPreference:MYVALUE")
Dependency for EditTextPreference value (e.g. checking for empty state android:dependency="myEditTextPreference:null")
Not sure if this is possible but I believe that it would be very useful. Obviously you can do this in code as well but it would save a lot of time and effort to just define these in XML.

Couple of issues off the top of my head:

How to specify multiple values?
Treat empty string as null?
Disable dependent items or hide them?
android:dependency is handled by framework; would need a new attribute.
Need for parser.

I don't think it's worth investing time and effort into such feature as not many would benefit from it. Solving this in Java will IMO allow better readability and performance.

Don't know how much effort this requires, but I for sure would be very happy to handle these from XML.
I understand that there are a lot of questions, this was just a basic idea.
How to specify multiple values?
This is only applicable to multi select preferences, normal ListPreference should be more straightforward I guess.
Treat empty string as null?
Or check for length or something.
Disable dependent items or hide them?
android:dependency disables the item, hiding could be an option.
android:dependency is handled by framework; would need a new attribute.
You mean asp:dependency or something? I wouldn't mind using it at all.
Thanks for considering it, maybe others can comment on this as well.

I'll leave this open for input. Won't implement it for now.

Ideology
I've ultimately decided against this idea, because it goes against the main goals of this library

to provide bridge between preference-v7 and appcompat-v7
to introduce missing elements from Material design

In a few words: this library is what I imagined preference-v7 would be in the first place. This library shouldn't need to exist.
Introducing proposed behavior would divert in major way from framework and introduce unnecessary complexity.
Implementation
More ideas:

How to specify multiple values?

Okay, let's stick with multi select list. Values for multi select list view are provided by a string array resource. There is no way to reuse that simply, so I need a parser for resource references.
What about edit text preference? There are infinite possibilites. So now I need a regex parser too.

Null string.

"Check the length or something" sounds pretty vague and has no informational value. I know how to check if a string is null or empty or neither. It's a question of semantics. Do we treat null in a different way than ""? What if someone else has a different idea/needs from what would be actually implemented. I don't want to lock someone in a ceratain way.
We need to distinguish from null and "null" so the parser has to know about quotes.

And so on, and so forth.

When dealing with this programmatically the consumer (you) can ultimately decide on concrete behavior of their custom dependency system, be agile and adapt quickly to changing needs.
There is no one best way to implement this. You can express your precise needs way easier in Java than you could ever mash up into one XML attribute.
I appreciate the input but I believe the cost to benefit ratio of such feature is non-existent.

Thanks for elaborating on this.


text:
🛑 anomouresbingo.partouze-cagoule.fr is down

In 095fef4, anomouresbingo.partouze-cagoule.fr (https://anomouresbingo.partouze-cagoule.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: anomouresbingo.partouze-cagoule.fr is back up in d1b259c after 5 hours.

repo: constructions-incongrues/status


text:
🛑 anomouresbingo.partouze-cagoule.fr is down

In aa359a7, anomouresbingo.partouze-cagoule.fr (https://anomouresbingo.partouze-cagoule.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: anomouresbingo.partouze-cagoule.fr is back up in 3295683 after 6 hours, 30 minutes.