Add additional options added to os_networks since 2.8

This allows you to set the MTU. Fixes #17.

Should we also bump the required Ansible version for this release of os_networks?

We could use argument splatting to maintain compatibility with older versions:
https://github.com/ansible/ansible/pull/43798
This would allow us to support >= 2.7, thoughts?

From my limited testing it seems you can pass arguments with omit with ansible>=2.5:
(t6) [will@juno ~]$ cat test5.yml
---
- hosts: localhost
  tasks:
    - copy:
        src: /tmp/test.yml
        dest: /tmp/sfsfsad.yml
        madeupparam: "{{ hello | default(omit) }}"

(t6) [will@juno ~]$ pip install -U 'ansible<2.6'
Requirement already up-to-date: ansible<2.6 in /tmp/t6/lib/python3.8/site-packages (2.5.15)
Requirement already satisfied, skipping upgrade: jinja2 in /tmp/t6/lib/python3.8/site-packages (from ansible<2.6) (2.10.3)
Requirement already satisfied, skipping upgrade: cryptography in /tmp/t6/lib/python3.8/site-packages (from ansible<2.6) (2.8)
Requirement already satisfied, skipping upgrade: PyYAML in /tmp/t6/lib/python3.8/site-packages (from ansible<2.6) (5.1.2)
Requirement already satisfied, skipping upgrade: setuptools in /tmp/t6/lib/python3.8/site-packages (from ansible<2.6) (42.0.1)
Requirement already satisfied, skipping upgrade: paramiko in /tmp/t6/lib/python3.8/site-packages (from ansible<2.6) (2.6.0)
Requirement already satisfied, skipping upgrade: MarkupSafe>=0.23 in /tmp/t6/lib/python3.8/site-packages (from jinja2->ansible<2.6) (1.1.1)
Requirement already satisfied, skipping upgrade: six>=1.4.1 in /tmp/t6/lib/python3.8/site-packages (from cryptography->ansible<2.6) (1.13.0)
Requirement already satisfied, skipping upgrade: cffi!=1.11.3,>=1.8 in /tmp/t6/lib/python3.8/site-packages (from cryptography->ansible<2.6) (1.13.2)
Requirement already satisfied, skipping upgrade: bcrypt>=3.1.3 in /tmp/t6/lib/python3.8/site-packages (from paramiko->ansible<2.6) (3.1.7)
Requirement already satisfied, skipping upgrade: pynacl>=1.0.1 in /tmp/t6/lib/python3.8/site-packages (from paramiko->ansible<2.6) (1.3.0)
Requirement already satisfied, skipping upgrade: pycparser in /tmp/t6/lib/python3.8/site-packages (from cffi!=1.11.3,>=1.8->cryptography->ansible<2.6) (2.19)
(t6) [will@juno ~]$ pip install --force -U 'ansible<2.6'
Processing ./.cache/pip/wheels/5d/e4/6c/4dbd88e9fc05c66792127952b466288b18f1c7acc6a1e8a73a/ansible-2.5.15-cp38-none-any.whl
Processing ./.cache/pip/wheels/d9/45/dd/65f0b38450c47cf7e5312883deb97d065e030c5cca0a365030/PyYAML-5.1.2-cp38-cp38-linux_x86_64.whl
Collecting paramiko
  Using cached https://files.pythonhosted.org/packages/4b/80/74dace9e48b0ef923633dfb5e48798f58a168e4734bca8ecfaf839ba051a/paramiko-2.6.0-py2.py3-none-any.whl
Collecting cryptography
  Using cached https://files.pythonhosted.org/packages/ca/9a/7cece52c46546e214e10811b36b2da52ce1ea7fa203203a629b8dfadad53/cryptography-2.8-cp34-abi3-manylinux2010_x86_64.whl
Collecting setuptools
  Using cached https://files.pythonhosted.org/packages/9e/d5/444a443d890f09fc1ca1a2c3c9fc7e84cb148177b05ac94fe5084e3d9abb/setuptools-42.0.1-py2.py3-none-any.whl
Collecting jinja2
  Using cached https://files.pythonhosted.org/packages/65/e0/eb35e762802015cab1ccee04e8a277b03f1d8e53da3ec3106882ec42558b/Jinja2-2.10.3-py2.py3-none-any.whl
Collecting pynacl>=1.0.1
  Using cached https://files.pythonhosted.org/packages/27/15/2cd0a203f318c2240b42cd9dd13c931ddd61067809fee3479f44f086103e/PyNaCl-1.3.0-cp34-abi3-manylinux1_x86_64.whl
Collecting bcrypt>=3.1.3
  Using cached https://files.pythonhosted.org/packages/8b/1d/82826443777dd4a624e38a08957b975e75df859b381ae302cfd7a30783ed/bcrypt-3.1.7-cp34-abi3-manylinux1_x86_64.whl
Collecting cffi!=1.11.3,>=1.8
  Using cached https://files.pythonhosted.org/packages/05/7d/723ceca757d8016850d1110df44b91121695f22f782f876b483ecb3928a9/cffi-1.13.2-cp38-cp38-manylinux1_x86_64.whl
Collecting six>=1.4.1
  Using cached https://files.pythonhosted.org/packages/65/26/32b8464df2a97e6dd1b656ed26b2c194606c16fe163c695a992b36c11cdf/six-1.13.0-py2.py3-none-any.whl
Processing ./.cache/pip/wheels/f2/aa/04/0edf07a1b8a5f5f1aed7580fffb69ce8972edc16a505916a77/MarkupSafe-1.1.1-cp38-cp38-linux_x86_64.whl
Processing ./.cache/pip/wheels/f2/9a/90/de94f8556265ddc9d9c8b271b0f63e57b26fb1d67a45564511/pycparser-2.19-py2.py3-none-any.whl
Installing collected packages: PyYAML, pycparser, cffi, six, cryptography, pynacl, bcrypt, paramiko, setuptools, MarkupSafe, jinja2, ansible
  Found existing installation: PyYAML 5.1.2
    Uninstalling PyYAML-5.1.2:
      Successfully uninstalled PyYAML-5.1.2
  Found existing installation: pycparser 2.19
    Uninstalling pycparser-2.19:
      Successfully uninstalled pycparser-2.19
  Found existing installation: cffi 1.13.2
    Uninstalling cffi-1.13.2:
      Successfully uninstalled cffi-1.13.2
  Found existing installation: six 1.13.0
    Uninstalling six-1.13.0:
      Successfully uninstalled six-1.13.0
  Found existing installation: cryptography 2.8
    Uninstalling cryptography-2.8:
      Successfully uninstalled cryptography-2.8
  Found existing installation: PyNaCl 1.3.0
    Uninstalling PyNaCl-1.3.0:
      Successfully uninstalled PyNaCl-1.3.0
  Found existing installation: bcrypt 3.1.7
    Uninstalling bcrypt-3.1.7:
      Successfully uninstalled bcrypt-3.1.7
  Found existing installation: paramiko 2.6.0
    Uninstalling paramiko-2.6.0:
      Successfully uninstalled paramiko-2.6.0
  Found existing installation: setuptools 42.0.1
    Uninstalling setuptools-42.0.1:
      Successfully uninstalled setuptools-42.0.1
  Found existing installation: MarkupSafe 1.1.1
    Uninstalling MarkupSafe-1.1.1:
      Successfully uninstalled MarkupSafe-1.1.1
  Found existing installation: Jinja2 2.10.3
    Uninstalling Jinja2-2.10.3:
      Successfully uninstalled Jinja2-2.10.3
  Found existing installation: ansible 2.5.15
    Uninstalling ansible-2.5.15:
      Successfully uninstalled ansible-2.5.15
Successfully installed MarkupSafe-1.1.1 PyYAML-5.1.2 ansible-2.5.15 bcrypt-3.1.7 cffi-1.13.2 cryptography-2.8 jinja2-2.10.3 paramiko-2.6.0 pycparser-2.19 pynacl-1.3.0 setupt
ools-42.0.1 six-1.13.0
(t6) [will@juno ~]$ ansible-playbook test5.yml
 [WARNING]: Unable to parse /etc/ansible/hosts as an inventory source

 [WARNING]: No inventory was parsed, only implicit localhost is available

 [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [localhost] ************************************************************************************************************************************************************

TASK [Gathering Facts] ******************************************************************************************************************************************************
ok: [localhost]

TASK [debug] ****************************************************************************************************************************************************************
ok: [localhost] => {
    "test": "VARIABLE IS NOT DEFINED!"
}

TASK [copy] *****************************************************************************************************************************************************************
ok: [localhost]

PLAY RECAP ******************************************************************************************************************************************************************
localhost                  : ok=3    changed=0    unreachable=0    failed=0

(t6) [will@juno ~]$ pip install --force -U 'ansible<2.5'
Processing ./.cache/pip/wheels/db/8e/a9/1aa2d1ed37b34b4f07fa3860e2adeb6bf0d943dd38cd07c928/ansible-<IP_ADDRESS>-cp38-none-any.whl
Collecting paramiko
  Using cached https://files.pythonhosted.org/packages/4b/80/74dace9e48b0ef923633dfb5e48798f58a168e4734bca8ecfaf839ba051a/paramiko-2.6.0-py2.py3-none-any.whl
Collecting jinja2
  Using cached https://files.pythonhosted.org/packages/65/e0/eb35e762802015cab1ccee04e8a277b03f1d8e53da3ec3106882ec42558b/Jinja2-2.10.3-py2.py3-none-any.whl
Collecting setuptools
  Using cached https://files.pythonhosted.org/packages/9e/d5/444a443d890f09fc1ca1a2c3c9fc7e84cb148177b05ac94fe5084e3d9abb/setuptools-42.0.1-py2.py3-none-any.whl
Collecting cryptography
  Using cached https://files.pythonhosted.org/packages/ca/9a/7cece52c46546e214e10811b36b2da52ce1ea7fa203203a629b8dfadad53/cryptography-2.8-cp34-abi3-manylinux2010_x86_64.whl
Processing ./.cache/pip/wheels/d9/45/dd/65f0b38450c47cf7e5312883deb97d065e030c5cca0a365030/PyYAML-5.1.2-cp38-cp38-linux_x86_64.whl
Collecting pynacl>=1.0.1
  Using cached https://files.pythonhosted.org/packages/27/15/2cd0a203f318c2240b42cd9dd13c931ddd61067809fee3479f44f086103e/PyNaCl-1.3.0-cp34-abi3-manylinux1_x86_64.whl
Collecting bcrypt>=3.1.3
  Using cached https://files.pythonhosted.org/packages/8b/1d/82826443777dd4a624e38a08957b975e75df859b381ae302cfd7a30783ed/bcrypt-3.1.7-cp34-abi3-manylinux1_x86_64.whl
Processing ./.cache/pip/wheels/f2/aa/04/0edf07a1b8a5f5f1aed7580fffb69ce8972edc16a505916a77/MarkupSafe-1.1.1-cp38-cp38-linux_x86_64.whl
Collecting cffi!=1.11.3,>=1.8
  Using cached https://files.pythonhosted.org/packages/05/7d/723ceca757d8016850d1110df44b91121695f22f782f876b483ecb3928a9/cffi-1.13.2-cp38-cp38-manylinux1_x86_64.whl
Collecting six>=1.4.1
  Using cached https://files.pythonhosted.org/packages/65/26/32b8464df2a97e6dd1b656ed26b2c194606c16fe163c695a992b36c11cdf/six-1.13.0-py2.py3-none-any.whl
Processing ./.cache/pip/wheels/f2/9a/90/de94f8556265ddc9d9c8b271b0f63e57b26fb1d67a45564511/pycparser-2.19-py2.py3-none-any.whl
Installing collected packages: pycparser, cffi, six, cryptography, pynacl, bcrypt, paramiko, MarkupSafe, jinja2, setuptools, PyYAML, ansible
  Found existing installation: pycparser 2.19
    Uninstalling pycparser-2.19:
      Successfully uninstalled pycparser-2.19
  Found existing installation: cffi 1.13.2
    Uninstalling cffi-1.13.2:
      Successfully uninstalled cffi-1.13.2
  Found existing installation: six 1.13.0
    Uninstalling six-1.13.0:
      Successfully uninstalled six-1.13.0
  Found existing installation: cryptography 2.8
    Uninstalling cryptography-2.8:
      Successfully uninstalled cryptography-2.8
  Found existing installation: PyNaCl 1.3.0
    Uninstalling PyNaCl-1.3.0:
      Successfully uninstalled PyNaCl-1.3.0
  Found existing installation: bcrypt 3.1.7
    Uninstalling bcrypt-3.1.7:
      Successfully uninstalled bcrypt-3.1.7
  Found existing installation: paramiko 2.6.0
    Uninstalling paramiko-2.6.0:
      Successfully uninstalled paramiko-2.6.0
  Found existing installation: MarkupSafe 1.1.1
    Uninstalling MarkupSafe-1.1.1:
      Successfully uninstalled MarkupSafe-1.1.1
  Found existing installation: Jinja2 2.10.3
    Uninstalling Jinja2-2.10.3:
      Successfully uninstalled Jinja2-2.10.3
  Found existing installation: setuptools 42.0.1
    Uninstalling setuptools-42.0.1:
      Successfully uninstalled setuptools-42.0.1
  Found existing installation: PyYAML 5.1.2
    Uninstalling PyYAML-5.1.2:
      Successfully uninstalled PyYAML-5.1.2
  Found existing installation: ansible 2.5.15
    Uninstalling ansible-2.5.15:
      Successfully uninstalled ansible-2.5.15
Successfully installed MarkupSafe-1.1.1 PyYAML-5.1.2 ansible-<IP_ADDRESS> bcrypt-3.1.7 cffi-1.13.2 cryptography-2.8 jinja2-2.10.3 paramiko-2.6.0 pycparser-2.19 pynacl-1.3.0 setup
tools-42.0.1 six-1.13.0
(t6) [will@juno ~]$ ansible-playbook test5.yml
 [WARNING]: Unable to parse /etc/ansible/hosts as an inventory source

 [WARNING]: No inventory was parsed, only implicit localhost is available

 [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [localhost] ************************************************************************************************************************************************************
ERROR! Unexpected Exception, this is probably a bug: invalid syntax (task_executor.py, line 568)
to see the full traceback, use -vvv
(t6) [will@juno ~]$

So it would seem this would work in a backwards compatible way. Maybe I'm missing something?


[Feature Request]: BIP-352 support

Silent Payments would be a nice feature add IMHO.
https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki
https://bitcoin.design/guide/how-it-works/silent-payments/
https://silentpayments.xyz/docs/wallets

afaik silent-payments work only w/ the taproot internal key not the taptree and a liana taproot "wallet"/account will always have a taptree.
i've spend some time to wrap my head around how we can integrate it in liana, and the only way i think about is having a separate "wallet"/account w/o recoverry path for receiving SP and, i'm not sure if we want to do this.
but maybe @josibake @cygnet3 @Sosthene00 have better idea

If i remember correctly bip352 mandate to use key path spend for Taproot. I'm not even sure it can do P2WSH? In this case it would only be possible for very specific usages which would be confusing to a user.
-------- Original Message --------
On 12/9/24 11:04 PM, pythcoiner  wrote:

afaik silent-payments work only w/ the taproot internal key not the taptree and a liana taproot "wallet"/account will always have a taptree.
i've spend some time to wrap my head around how we can integrate it in liana, and the only way i think about is having a separate "wallet"/account w/o recoverry path for receiving SP and, i'm not sure if we want to do this.
but maybe @.(https://github.com/josibake) @.(https://github.com/cygnet3) @.***(https://github.com/Sosthene00) have better idea
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


apply shouldn’t edit hosts file if no domains changed

Currently nitro apply always prompts for your password and updatse updates the hosts file, even if there’s nothing to change in it.
Ideally, Nitro should be aware of whether anything just changed that would require a change to the hosts file, and skip that step if not.

@brandonkelly I think we can close this out, since we are forcing a remove and re-add during apply?

With v2, the apply command will not prompt for host file changes if nothing has new has been added.


End-of-route handling

Need to decide on what trains do after they finish a route. Do they remain stationary on the track? If so, they shouldn't technically release themselves from that portion of the resource.
This logic should be handled in the train running code.

I think the best way to do this, given that it's a queuing model, is to have trains not "disappear" from the network ever, but instead implement an infinite (or nearly infinite) capacity yard at the end of a location that absorbs the trains. That said, if trains are idle and are not scheduling more events the simulation will run its course and terminate.
This is already implemented and no additional change is required.


Incorrect Dashboard page returned

I have Traefik set up in kubernetes as an ingress LB.  I also have traefik itself serving up the dashboard page.  Traefik is a LoadBalanced service, so  ELB round-robins over 3 instances of Traefik.
A couple hours after I restart Traefik,  when I attempt to view the Dashboard page,  I get this instead:

I haven't dug into this too much just yet. I wanted to see if this was a known issue before I dig in to the cause.

Hey. This is a duplicate of #796 and therefore closed ;-)


Additional Technical Details

[Enter feedback here]

Is this available across all clients (iOS, Android, Windows, MacOS)?
Does the user need to be authenticated for it to be present?
Are there administrative controls to control if this feature is made available?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 86d4ed41-8d7e-9caa-d6f9-dea2ba149ade
Version Independent ID: 5dff4476-cde0-ebcf-f831-255905fde53a
Content: Raise hand in Teams meetings - Microsoft Teams
Content Source: Teams/raise-hand-meetings.md
Service: msteams
GitHub Login: @cichur
Microsoft Alias: v-cichur

Hello @vshakyaver
1 Yes. Raise your hand is always available in any meeting you join and is supported on all clients except meeting room devices (at the moment).
2. No.
3. A Teams admin doesn't have to create a policy for the feature to appear in a meeting.

@vshakyaver  Thank you for submitting feedback. We understand that this issue has been resolved.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


Update to new SDK-style MSbuild project files

This allow easily run application on the .NET Core and .NET 5, by simply changing target frameworks,

@codeprof can you take a look?


Updates to Postgres ETL

Fixes #14
This is working PR to address issues with the Postgres ETL.

load_data.py was missing the truncate table command, this has been added.
Inserting a million records into the table via asyncpg is indeed concurrent with the new code, and is much faster than before (on my machine finishes in about 2 mins wall-clock time)

Closing this as we can revisit the sqlx code fixes using the new directory structure.


Docs are wrong

The docs say an object is returned with a flag and the points:

However it looks like it returns a Point[][], which seems to be inline with me using the module.

Argh I must have forgotten to update the docs. Thanks for reporting.

No worries, thank you for the wonderful library!
On Tue, Jun 30, 2020, 7:21 PM Preet<EMAIL_ADDRESS>wrote:

Argh I must have forgotten to update the docs. Thanks for reporting.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pshihn/points-on-path/issues/2#issuecomment-652096853,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTSGCDTEYNIJH6Y5RQNLCDRZJXG5ANCNFSM4OM3D3HA
.


DMS cannot be imported normally

Hi,when i execute ./aws2tf.py -t dms，the log shows "The parameter Logging.CloudWatchLogStream is read-only and cannot be set." at the end

Can you give me a  pointer to which terraform resource type is associated with that error - so I reproduce it and fix.

thanks，the issues mentioned above have been fixed, but when I execute  ./aws2tf.py -t ec2 -m, the logs shows these errors
Error: Reference to undeclared resource
on aws_dms_replication_instance__share-wick-adtomic-amazon.tf line 31, in resource "aws_dms_replication_instance" "share-wick-adtomic-amazon":
31:   vpc_security_group_ids = [aws_security_group.sg-096ed6b075bb5ed2b.id]
A managed resource "aws_security_group" "sg-096ed6b075bb5ed2b" has not been
declared in the root module.
Error: Reference to undeclared resource
on aws_dms_replication_instance__share-wick-adtomic-walmart.tf line 31, in resource "aws_dms_replication_instance" "share-wick-adtomic-walmart":
31:   vpc_security_group_ids = [aws_security_group.sg-096ed6b075bb5ed2b.id]
A managed resource "aws_security_group" "sg-096ed6b075bb5ed2b" has not been
declared in the root module.
Error: Reference to undeclared resource
on aws_nat_gateway__nat-030df4f73fc064fe3.tf line 7, in resource "aws_nat_gateway" "nat-030df4f73fc064fe3":
7:   subnet_id                      = aws_subnet.subnet-031077dbb7484636a.id
A managed resource "aws_subnet" "subnet-031077dbb7484636a" has not been
declared in the root module.
Error: Reference to undeclared resource
on aws_route_table_association__subnet-031077dbb7484636a_rtb-013d0cc094e8889fb.tf line 4, in resource "aws_route_table_association" "subnet-031077dbb7484636a_rtb-013d0cc094e8889fb":
4:   subnet_id      = aws_subnet.subnet-031077dbb7484636a.id
A managed resource "aws_subnet" "subnet-031077dbb7484636a" has not been
declared in the root module.

Hi
Hmm - not quite sure why those dependancies have't been picked up - could you try getting them manually with:
./aws2tf.py -t aws_security_group -i sg-096ed6b075bb5ed2b -m
&
./aws2tf.py -t aws_subnet -i subnet-031077dbb7484636a -m
And see if these exist / are picked up.
I'll look at catching this kind of thing another way as well ...

Have reproduced the problem - there's a bug in the merge (-m) logic somewhere - will advise when it's fixed.

Merging should be fixed now


Fix MCA dtype and other Tiled/Bluesky related fixes

The original GeRM libCA IOC reports the .MCA PV's type as DBF_LONG, which corresponds to np.int64 / <i8.
Fixed:

Caproto IOC side:

MCA dtype to be int64
save_hdf5 exporting function defaults to int64

Ophyd side:

fixed the descriptor of the data to report dtype_numpy="<i8"
make the kind of the frame_shape component "omitted" to avoid failures with bluesky's TiledWriter
use dataset rather than path in stream_resource

I went ahead and merged with one approval - I'd like to release it and redeploy the IOC.


Build with aeson 0.10 & http-types 0.9

yesod-auth-oauth2 is currently being excluded from stackage since it isn't compatible with these dependencies.
See: https://github.com/fpco/stackage/issues/845 and https://github.com/fpco/stackage/issues/880

Thanks for the report. I'll try to get this addressed this week.

I've bumped the version bounds and ran stack build --resolver nightly-2016-01-03, but I see:
While constructing the BuildPlan the following exceptions were encountered:

--  While attempting to add dependency,
    Could not find package hoauth2 in known packages

--  Failure when adding dependencies:
      hoauth2: needed (>=0.4.7 && <0.5), not present in build plan (latest applicable is 0.4.8)
    needed for package: yesod-auth-oauth2-0.1.5

If there's a workaround, let me know, but it seems we're blocked until hoauth2-0.4.8 (also mentioned in your linked issues) is addressed.

You're right; hoauth2 needs to make the same upgrades, since yesod-auth-oauth2 depends on it. I've opened an issue over there as well.

A new version of hoauth2 is available (0.5), and it is included in nightly-2016-01-08, since the author of hoauth2 has added himself to stackage. Try again?

Released with bounds change as 0.1.6.

Nice, thanks! I've opened a PR to restore yesod-auth-oauth2 to stackage:
https://github.com/fpco/stackage/pull/1110

Awesome, thanks for handling the stackage end of this -- anything I should look at about the build errors over there?

The travis build error on that PR is due to reasons other than the PR itself, so, nothing to worry about.


channel mode +j (join throttle)

https://freenode.net/kb/answer/channelmodes

This mode takes one parameter of the form n:t, where n and t are positive integers. Only n users may join in each period of t seconds, so with e.g. 3:10 only 3 users could join within 10 seconds. Invited users can join regardless of +j, but are counted as normal. You can use this mode to prevent bot attacks. Observe the average join rate of your channel and pick a good value for +j. This mode could be combined with +f to forward throttled users to an overflow channel.

This seems largely redundant with #1509


Pandas dependency

Hi!
In numerous parts of the code, the attribute include_groups=False has been set while calling the pandas.DataFrame.apply. function. The attribute was previously unavailable in pandas "<2.0.0". However this dependency is not enforced in Niimpy; therefore, running scripts in environments with older versions runs into errors.
Niimpy Version
1.2.0
Current Behaviour
Installing Niimpy does not consider versions for dependencies, leading to some errors like mentioned.
Expected Behaviour
Dependency versions should be specified (e.g., in pyproject.toml) to be enforced at package installation.

Thank you for submitting an issue!
I think this is worth updating directly in the main branch and pushing a minor version to PyPI. I'm fixing this now.

include_groups=False was added to silence warnings in Pandas 2.2 and later. It include_groups=True will become deprecated behavior in a later version.

A lot of tests fail with pandas 2.0

I was unable to compile pandas 2.1 on my laptop, so I'm testing with a workflow.

It seems pandas 2.1 is not compatible with numpy < 2.0. Updating to only pandas 2.2.

Version 1.2.1 with the dependency change is in PyPI. Closing this issue.


switch and for statements in getMax and sumElements, more test cases

I got rid of the jumpi commands in the first two functions and changed the for loops to inline assembly for loops.  I also added two more test cases for getMax to get better test coverage.

Ok, finally got the changes deployed, will you PR with the deployed-update branch? I'll open an update branch for each Lib also


sssd: 2.8.1 -> 2.8.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/SSSD/sssd/releases.
meta.description for sssd is: "System Security Services Daemon"
meta.homepage for sssd is: "https://sssd.io/"
meta.changelog for sssd is: "https://sssd.io/release-notes/sssd-2.8.2.html"
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.8.2 with grep in /nix/store/w6d9hd7ihyvkzxs6psyxwf5404kq16b8-sssd-2.8.2
found 2.8.2 in filename of file in /nix/store/w6d9hd7ihyvkzxs6psyxwf5404kq16b8-sssd-2.8.2

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
autofs5
sssd

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/w6d9hd7ihyvkzxs6psyxwf5404kq16b8-sssd-2.8.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A sssd https://github.com/r-ryantm/nixpkgs/archive/d68f54c1473fa3537a9f9d8f5d71cef0c6630681.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/w6d9hd7ihyvkzxs6psyxwf5404kq16b8-sssd-2.8.2
ls -la /nix/store/w6d9hd7ihyvkzxs6psyxwf5404kq16b8-sssd-2.8.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

autofs5
sssd

Maintainer pings
cc @outergod @illustris for testing.

@ofborg build sssd sssd.passthru.tests

@ofborg build sssd autofs5


Files available not working

Competition link: https://www.codabench.org/competitions/1711/
Hi, I've set the parameters Make Programs Available and Make Input Data Available to True (kindly see the attached image 1), however, nothing is still visible from the Files tab (attached image 2). Could you please help me fix this? Thanks!

Thank you for reporting this problem. I am able witness it on your competition indeed.
We are going to investigate this issue. Some questions:

Did you create this competition using a bundle submission or the form ("upload" or "create")?
Is it happening again when you re-create the same competition?
If you used a bundle file, could you please share it?

It seems that the dumps are also failing for this competition:

Hi Adrien,
Thanks! Regarding your questions:

I created it from scratch (“create”)
Will check this tomorrow and let you know!
Not applicable

On Mon, 20 Nov 2023 at 22:24, Adrien Pavão @.***> wrote:

Thank you for reporting this problem. I am able witness it on your
competition indeed.
We are going to investigate this issue. Some questions:

Did you create this competition using a bundle submission or the
form ("upload" or "create")?
Is it happening again when you re-create the same competition?
If you used a bundle file, could you please share it?

It seems that the dumps are also failing for this competition:
[image: Capture d’écran 2023-11-20 à 22 23 02]
https://user-images.githubusercontent.com/11784999/284396741-a361c8ac-979b-4a71-8c21-cb8e1d31bd29.png
—
Reply to this email directly, view it on GitHub
https://github.com/codalab/codabench/issues/1236#issuecomment-1819825978,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIXZKXO2PIR53T5H27WXD5DYFPDCVAVCNFSM6AAAAAA7TKXRZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJZHAZDKOJXHA
.
You are receiving this because you authored the thread.Message ID:
@.***>

I could dump the re-upload the competition, and the problem happens again.
The fact that you used the form ("create") is an interesting information. The problem may be there.

Thanks Adrien,
I'm however unable to create the competition using the "upload" form as I get the following error.

An interesting thing here is that if I download your bundle.zip, extract it, and zip it back, it is not anymore accepted by the server.

I could dump the re-upload the competition, and the problem happens again.

Can you please share the dump with me

Thanks Adrien,
I'm however unable to create the competition using the "upload" form as I get the following error.

This is because your zip bundle is missing competition.yaml file or your are zipping the folder.
If you have the first problem of missing yaml file then please check these example bundles: https://github.com/codalab/competition-examples/tree/master/codabench
If your yaml file is there then make sure to zip the contents of the folder where you have your yaml and other files (do not zip the parent folder )

Hi Insah,
I'm completely sure my bundle has the competition.yaml file in the main directory. Please find it attached.
bundle_2.zip

Apologies if my question is primitive, do you mean zip -r bundle.zip bundle/* ?

You can use the following
cd bundle

zip -r bundle.zip ./*

Thanks a lot, Insah,
I've created the competition using the upload form: https://www.codabench.org/competitions/1714/
Yet, Make programs available still does not work for me (I'm testing this from another account).

I see them clearly in the files tab

Yes, starting kit and public data are the publicly visible files that I set in the competition.yaml file. It seems that make programs available (and probably make input files available as well) cannot be changed after creation, which may be a bug.

Noting this down. We will look into this soon.

Todos:

checking make programs available and make input data available does not work.
this bundle when uploaded can reproduce this bug Bundle
also check this when a comp is created using the UI

Other issues related to the Files tab:

#1229

@Aktsvigun
How did you upload the scoring program and input data?
I am thiking maybe you have the same problem of including a folder in the root of the zip instead of zipping the files directly.
Is that the case? I am not sure but the problem may be linked to this.
Could you try to zip the scoring program and input data using Ihsan's procedure, re-upload them, and re-create a task, to see if it solves the problem?
cd folder
zip -r program.zip *

The problem may comes from below this line: https://github.com/codalab/codabench/blob/1f93bbc518d1c5b63a052d04985069d523716832/src/static/riot/competitions/detail/_tabs.tag#L227

I confirm it is specifically linked to tasks, and not to competition. When changing to another task it works, then back to this task it fails.
The only difference I can think of right now is that the failing task does not have an ingestion program.

I confirm that the bug raises when the task does not have an ingestion program.

Dear @Didayolo , this indeed works, thank you! But my public data is still invisible to other users, kindly see competition https://www.codabench.org/competitions/1741. There is only input data present in the "Files" tab.

When I try to edit the phase of your competition using the editor, I see no public data linked to it:

This looks strange because I included it in the competition.yaml file - have I done this wrong?

Hi @Aktsvigun, expect some delay in the fix of this problem. However, in the meantime, you can easily work-around it by supplementing your tasks with a dummy ingestion program. Is there any remaining issue that you are not able to avoid?

This looks strange because I included it in the competition.yaml file - have I done this wrong?

You can still link a public data after your competition is uploaded.

@bbearce Another interesting issue for you if you want / have time for it.


Proxy works with 'npm start' but not with the build version

Hi!
I have made a Data Fetching to a GraphQL server using the new "proxy" configuration of create-react-app 0.3.0 and... It works perfectly! Except in the build version :/
What I mean is, if I execute npm start the browser opens a tab with all the data. That's OK.
But, if I run:
$ npm run build
$ npm install -g pushstate-server
$ pushstate-server build

And I open the URL http://localhost:9000 I don't have data. And, in the console of the browser appears an error (/graphql?query={crtEstacioNodes(orderBy... etc.). It seems that the build version is ignoring the configuration of the proxy and is making the call without the host/port.
Maybe (probably!) I'm doing something wrong, but,... What?
Thanks a lot!!!

It is only intended for development. (I wanted to call it devProxy, cc @vjeux :wink: )
This feature was added for people who serve their frontend apps from / in production and serve the backend APIs from the same host. Like here: https://www.fullstackreact.com/articles/using-create-react-app-with-a-server/.
In this scenario it's inconvenient to separate them in development because they're going to end up on the same host in production.
However there is no possible way CRA could proxy anything in production because it produces a static bundle. At this point it is assumed that if you use proxy, you host the app at the root of the same host. If it's not your situation, you need to actually embed the server URL into your production bundle, and request from it directly. You can use NODE_ENV to determine whether you are running in production, or been pass a custom environment variable. This is documented in the usage guide.

Ohhhh! It's true. I'd read the article a week ago and I didn't remember this issue. The problem is that the GraphQL Server works in another host. Or in the same host, but in a different port. I use nodejs with express, for this reason I suppose that this solution Enable Cors will works. What do you thing?

Yep, if you serve from another host or port in production, you need to enable CORS.

Thanks a lot @gaearon !!! :+1:


Question about Already published apps on AppleStore

Hello.
When we publish on Apple Store we use our developer credentials, so, before publish on gitHub as
public is there something to delete in particular?
I have some old apps, i was considering publish as public.
Not sure...
Have you guys done it?
Thanks

Yea if you could remove any sensitive information, go for it.. developer id, api keys. If you are not sure, feel free to ask
Sent with GitHawk

Well, exactly where should I look for?
Plist?
Thanks for the answer

Well you can find the developer id also in project settings .. do you use any third party services other than Apple? Fabric or some back end service
Sent with GitHawk

Closing, feel free to ask questions again

thanks


'dart:ui/window.dart': Failed assertion: line 284: '': is not true

The following assertion was thrown building LandingPage(dirty):
I/flutter ( 7567): 'dart:ui/window.dart': Failed assertion: line 284: '<optimized out>': is not true.
I/flutter ( 7567):
I/flutter ( 7567): Either the assertion indicates an error in the framework itself, or we should provide substantially
I/flutter ( 7567): more information in this error message to help you determine and fix the underlying cause.

Related to https://github.com/dart-lang/sdk/issues/34586.
@manideepu0014 cold you provide a complete minimal code sample to reproduce the error?
and you flutter doctor -v

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now.
Could everyone who still has this problem please file a new issue with the exact descriptions what happens, minimal reproducible sample code (if related), logs and the output of 'flutter doctor -v'  please.

E/flutter ( 4131): Receiver: null
E/flutter ( 4131): Tried calling: uid
E/flutter ( 4131): #0      Object.noSuchMethod (dart:core-patch/object_patch.dart:51:5)
E/flutter ( 4131): #1      HelperMethods.getCurrentUserInfo (package:taxigo_user_app/helpers/helpermethods.dart:24:41)
E/flutter ( 4131): #2      main (package:taxigo_user_app/main.dart:24:17)
E/flutter ( 4131):
E/flutter ( 4131): #3      _runMainZoned.. (dart:ui/hooks.dart:231:25)
E/flutter ( 4131): #4      _rootRun (dart:async/zone.dart:1190:13)
E/flutter ( 4131): #5      _CustomZone.run (dart:async/zone.dart:1093:19)
E/flutter ( 4131): #6      _runZoned (dart:async/zone.dart:1630:10)
E/flutter ( 4131): #7      runZonedGuarded (dart:async/zone.dart:1618:12)
E/flutter ( 4131): #8      _runMainZoned. (dart:ui/hooks.dart:223:5)
E/flutter ( 4131): #9      _startIsolate. (dart:isolate-patch/isolate_patch.dart:301:19)
E/flutter ( 4131): #10     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:168:12)


[FEEDSTOCK REQUEST] Forecasting time series packages/dependencies to be included in a future open-ce release

Open-CE Team,
My name is Jesse Harmon and I collaborating with the POWER enablement and optimization team.
We are requesting the following forecasting time series packages/dependencies to be included in a future open-ce release:
numpy
pandas
prophet (https://facebook.github.io/prophet)
orbit-ml (https://github.com/uber/orbit)
cmdstan
pystan
cmdstanpy
Thanks for all your help,
Jesse

Hi @harmojd , thanks for reaching out!
We will check whether we can include the following libraries in our OpenCE 1.8 release stream, which we're currently working on:

prophet
orbit-ml
cmdstan
pystan
cmdstanpy

The following libraries are provided by Anaconda for Power. That's why we don't include them into OpenCE:

pandas
numpy

We will of course ensure that above time series libs work with the pandas / numpy versions from Anaconda.

Alexander,
Thanks for your help!  We really appreciate it!
After meeting/collaborating with the POWER enablement and optimization team
we discussed that numpy/pandas from Anaconda are not optimized for POWER.
Dillard's is using packages from https://urldefense.com/v3/__https://anaconda.org/rocketce__;!!IoaeSlivZg!w3Q4pNXtFfMGkeh0Lhu4Vy_lTmR_TFiUUqFI1YX_lRwxi80tME8jRfXxeAZJdTyXfXDVNUzJhgwtHCfDan5MFa5MwiSh1Qxv35tptKyZ4aUnGcGBg_c-xMYwO7olFh9LQGFF3g$   and we
thought by adding these packages into OpenCE this would make it easier for
the RocketCE team to optimize these packages from a CI/CD perspective.
Thanks for your help,
Jesse and Lenin
On Mon, Oct 10, 2022 at 1:11 AM Alexander Lang @.***>
wrote:

Hi @harmojd
https://urldefense.com/v3/__https://github.com/harmojd__;!!IoaeSlivZg!zS5fOCz-ceEC8zvGIYmA3rKImJerhEqPK-pSrEDAW_jQ7O6GNqSF2GEM3dofI4QlddU2hWYLLduMMzxJH7RWNYz33yAn$
, thanks for reaching out!
We will check whether we can include the following libraries in our OpenCE
1.8 release stream, which we're currently working on:

prophet
orbit-ml
cmdstan
pystan
cmdstanpy

The following libraries are provided by Anaconda for Power. That's why we
don't include them into OpenCE:

pandas
numpy

We will of course ensure that above time series libs work with the pandas
/ numpy versions from Anaconda.
—
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/open-ce/open-ce/issues/705*issuecomment-1272826116__;Iw!!IoaeSlivZg!zS5fOCz-ceEC8zvGIYmA3rKImJerhEqPK-pSrEDAW_jQ7O6GNqSF2GEM3dofI4QlddU2hWYLLduMMzxJH7RWNfZJ7-O-$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AHHKVFVGPZNANE346VNTWELWCOXSNANCNFSM6AAAAAARAATP44__;!!IoaeSlivZg!zS5fOCz-ceEC8zvGIYmA3rKImJerhEqPK-pSrEDAW_jQ7O6GNqSF2GEM3dofI4QlddU2hWYLLduMMzxJH7RWNRbh8E1Q$
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @harmojd ,
a quick update: as numpy will also benefit from MMA optimizations on P10, we will try to include it in OpenCE as well.

Alexander,
Awesome!  This is great news!
Thank you so much,
Jesse
On Wed, Oct 12, 2022 at 12:58 AM Alexander Lang @.***>
wrote:

Hi @harmojd
https://urldefense.com/v3/__https://github.com/harmojd__;!!IoaeSlivZg!38UNXUXE1eC6alz0QkuDz-5iNtzYuSkMIJ5WoQItmH7Xc7mVC5I3q-f1CpJc8E_Ki83HN68Ypw02wCjveOC0mBO4Ysjj$
,
a quick update: as numpy will also benefit from MMA optimizations on P10,
we will try to include it in OpenCE as well.
—
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/open-ce/open-ce/issues/705*issuecomment-1275631115__;Iw!!IoaeSlivZg!38UNXUXE1eC6alz0QkuDz-5iNtzYuSkMIJ5WoQItmH7Xc7mVC5I3q-f1CpJc8E_Ki83HN68Ypw02wCjveOC0mA9nSTQB$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AHHKVFWL4V36C57KYLFWMQTWCZHSDANCNFSM6AAAAAARAATP44__;!!IoaeSlivZg!38UNXUXE1eC6alz0QkuDz-5iNtzYuSkMIJ5WoQItmH7Xc7mVC5I3q-f1CpJc8E_Ki83HN68Ypw02wCjveOC0mHC4x7a6$
.
You are receiving this because you were mentioned.Message ID:
@.***>

Alexander,
We are looking at other frameworks that can benefit from Power10
optimizations like around OpenBLAS.
We are already using PuLP(https://urldefense.com/v3/__https://anaconda.org/conda-forge/pulp__;!!IoaeSlivZg!zsdp_nAZTvpwjpOdPMEjodr1IdTQghhq2CBJRlhdXbK5xmEQ18aYojKiJiZNYlCUKEf6nk2AFg-L9Norvngqnfh3mlUokhX7sXblQRnaaQmTn6-3Ic6p2rpLkcHJHtSbReZPW3ZH$  ) but we are
needing the ability to use the Clp solver.
Is it possible to have this framework added to OpenCE?
https://urldefense.com/v3/__https://github.com/google/or-tools__;!!IoaeSlivZg!zsdp_nAZTvpwjpOdPMEjodr1IdTQghhq2CBJRlhdXbK5xmEQ18aYojKiJiZNYlCUKEf6nk2AFg-L9Norvngqnfh3mlUokhX7sXblQRnaaQmTn6-3Ic6p2rpLkcHJHtSbRRoFkNw5$
Google Operations Research Tools (or-tools) python package
https://urldefense.com/v3/__https://anaconda.org/conda-forge/ortools-python__;!!IoaeSlivZg!zsdp_nAZTvpwjpOdPMEjodr1IdTQghhq2CBJRlhdXbK5xmEQ18aYojKiJiZNYlCUKEf6nk2AFg-L9Norvngqnfh3mlUokhX7sXblQRnaaQmTn6-3Ic6p2rpLkcHJHtSbRXtGb7eV$
Thanks,
Jesse and Lenin
On Fri, Oct 14, 2022 at 4:25 PM Jesse Harmon @.***>
wrote:

Alexander,
Awesome!  This is great news!
Thank you so much,
Jesse
On Wed, Oct 12, 2022 at 12:58 AM Alexander Lang @.***>
wrote:

Hi @harmojd
https://urldefense.com/v3/__https://github.com/harmojd__;!!IoaeSlivZg!38UNXUXE1eC6alz0QkuDz-5iNtzYuSkMIJ5WoQItmH7Xc7mVC5I3q-f1CpJc8E_Ki83HN68Ypw02wCjveOC0mBO4Ysjj$
,
a quick update: as numpy will also benefit from MMA optimizations on
P10, we will try to include it in OpenCE as well.
—
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/open-ce/open-ce/issues/705*issuecomment-1275631115__;Iw!!IoaeSlivZg!38UNXUXE1eC6alz0QkuDz-5iNtzYuSkMIJ5WoQItmH7Xc7mVC5I3q-f1CpJc8E_Ki83HN68Ypw02wCjveOC0mA9nSTQB$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AHHKVFWL4V36C57KYLFWMQTWCZHSDANCNFSM6AAAAAARAATP44__;!!IoaeSlivZg!38UNXUXE1eC6alz0QkuDz-5iNtzYuSkMIJ5WoQItmH7Xc7mVC5I3q-f1CpJc8E_Ki83HN68Ypw02wCjveOC0mHC4x7a6$
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @harmojd ,
quick update: we're on track to deliver the following packages in OpenCE 1.8 in Q4:

prophet
orbit-ml
cmdstan
cmdstanpy

We found pystan to be available in Anaconda default channel. This is why we don't build the package in OpenCE.
You can track our progress in  https://github.com/open-ce/open-ce/issues/706

Hi @harmojd ,
on your other request (sorry for the late response): you'd like us to include or-tools, correct? Because you can use pulp from Anaconda...

Alexander,
This is great news!  Thank you!
It would be awesome if you all could include Google's or-tools optimization
package to complement the other forecasting time series packages you will
add in OpenCE 1.8.
Thank you for your help,
Jesse
On Tue, Nov 15, 2022 at 3:33 AM Alexander Lang @.***>
wrote:

Hi @harmojd
https://urldefense.com/v3/__https://github.com/harmojd__;!!IoaeSlivZg!3FoVb9fYAJX7WDuDivE2pXsG49-BUyaBwfAnNORDWyfwVVVepCDLqi2_hncflsjRikK67hfixhIuODCTSWus5IWGE7tu$
,
on your other request (sorry for the late response): you'd like us to
include or-tools, correct? Because you can use pulp from Anaconda...
—
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/open-ce/open-ce/issues/705*issuecomment-1315037600__;Iw!!IoaeSlivZg!3FoVb9fYAJX7WDuDivE2pXsG49-BUyaBwfAnNORDWyfwVVVepCDLqi2_hncflsjRikK67hfixhIuODCTSWus5MNkq8L2$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AHHKVFRNSTY7WVPQQB3XVCDWINKGTANCNFSM6AAAAAARAATP44__;!!IoaeSlivZg!3FoVb9fYAJX7WDuDivE2pXsG49-BUyaBwfAnNORDWyfwVVVepCDLqi2_hncflsjRikK67hfixhIuODCTSWus5DLlTRoV$
.
You are receiving this because you were mentioned.Message ID:
@.***>

Ok. I won't promise anything now, but will check with the team tomorrow...

Hi @harmojd ,
we'll need more time to integrate or-tools. We're now starting the release build for OpenCE 1.8. Once 1.8 is released (tentatively next week from our end), we will pick up the work for or-tools?to include it in 1.8.1...

Alexander,
Thank you for the update!  We really appreciate all your help.
Thanks,
Jesse and Lenin
On Thu, Nov 24, 2022 at 3:12 AM Alexander Lang @.***>
wrote:

Hi @harmojd
https://urldefense.com/v3/__https://github.com/harmojd__;!!IoaeSlivZg!0malf5GhGwbEisrn35U8xMpWGsVhfrzBE2zakzcRdueL65kRUAZDqQFR2CFpMADbhsXI3ImhZtAzVMX8NPeJx0NqdobO$
,
we'll need more time to integrate or-tools. We're now starting the
release build for OpenCE 1.8. Once 1.8 is released (tentatively next week
from our end), we will pick up the work for or-tools?to include it in
1.8.1...
—
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/open-ce/open-ce/issues/705*issuecomment-1326158354__;Iw!!IoaeSlivZg!0malf5GhGwbEisrn35U8xMpWGsVhfrzBE2zakzcRdueL65kRUAZDqQFR2CFpMADbhsXI3ImhZtAzVMX8NPeJx2JK4zjI$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AHHKVFQPJWCLIPW7NYUHEDTWJ4WPXANCNFSM6AAAAAARAATP44__;!!IoaeSlivZg!0malf5GhGwbEisrn35U8xMpWGsVhfrzBE2zakzcRdueL65kRUAZDqQFR2CFpMADbhsXI3ImhZtAzVMX8NPeJx20YkV2w$
.
You are receiving this because you were mentioned.Message ID:
@.***>


Does not find Evernote

Environment
Windows build number: [run "ver" at a command prompt] Microsoft Windows [Version 10.0.18363.836]
PowerToys version: V0.18.1
PowerToy module for which you are reporting the bug (if applicable): Launcher

Steps to reproduce

Does not find Evernote win32 app. However finds Evernote Clipper
Expected behavior

Finds Evernote
Actual behavior
 Does not find, only Evernote Clipper

Screenshots

Closing this issue in favour of #3223

@alekhyareddy28, what makes you think think #3969 fixes evernote?  Same exe and dedup code fubared it up?

@alekhyareddy28, what makes you think think #3969 fixes evernote? Same exe and dedup code fubared it up?

Evernote was one of the programs like FileExplorer which had a null LnkResolvedPath but for shortcut applications (lnk files). It was the same issue.
It finds it now with the changes made in that PR.

fixed in 0.18.2 official release.  https://github.com/microsoft/PowerToys/releases/

Excuse me @rwnash. What's the name of this app?

Thank you for fixing this in the most recent update. It was on my todo list to add this as an issue.


nixos/opentracker: add declarative configuration

Motivation for this change
Proper configuration of opentracker from nix. This depends on #156795.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[x] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

So much love the the module :+1: Even with update script and test!
I will try out the module once the PR out of draft stage!

It's ready. I just marked it as a draft until #156795 is merged in case that needs adjustments.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1879

Do we really need to rebuild the package for every config change? Is there no config file, envs, etc?

Do we really need to rebuild the package for every config change? Is there no config file, envs, etc?

Yes, enabling/disabling features is mostly done at compile time. https://erdgeist.org/arts/software/opentracker/index/#build-instructions


Detect --help, and run help

Unrecognized command: '--help'. See carthage help. not as helpful as it could be when parsing commands
if the argument that failed to parse contains help but was not exactly "executable help"  the error should be printed and executable help should be run.
Maybe even -h

Im not sure the feasibility but
-fputs("Unrecognized command: '\(verb)'. See `\(executableName) help`.\n", stderr)
+fputs("Unrecognized command: '\(verb)'. See `\(executableName) help`.\n", stderr)
+if NSRegularExpression(pattern: "-h|help|--help", options: []) {
+  _ = run(command: "help", arguments: [])
+}

Same for carthage {command} --help as an equivalent to carthage help command. I think this will help a lot of people (including me, who always forgets this syntax).


Typescript definition file

Hi,
I'm using discord.js for a bot project of mine written in TypeScript. For now I've made my own typings file (not great/complete) and I was wondering if you're going to provide an official (i.e. made by the contributors of this project) one in the mid/long term?

Debatable... I think we won't be providing one, but still waiting on other contributors' input

Alright, as I started one I might as well try to complete it and open a PR :smiley:

@chadrien Any progess on this? If you already have something, someone could continue on it if you stopped.

Hi @GexoXYZ: I was absorbed by other things and completely forgot this, sorry! I have something already but it's not perfect and far from complete: https://github.com/chadrien/cycle-discord/blob/master/src/custom-typings/discord.d.ts
Feel free to go ahead from this as I may not have the time to continue working on this in the time being.

Unless someone else is working on this, I'm going to take a stab at it. I'll post any updates here.

I've started writing the definition file. So far it seems functional, however I'm worried that it's not correct. Can anyone take a look and tell me if it looks okay?
https://github.com/Falconerd/discord.js-td/blob/master/index.d.ts

Okay, I've completed an initial version. I haven't written tests for it yet as I'm out of time. When it's all testing properly I'll see if I can submit it to definitely-typed.
https://github.com/Falconerd/discord.js-td/blob/master/index.d.ts

https://github.com/nicholastay/discord.js.d.ts

Sweet, I'll remove mine as one is better

As of 9.0.2, the typescript definition would be out-of-date. It'd be great if someone could update it!

Doesn't look like this is going to happen ;(

Why close it? Somebody may attempt it in the future if it stays open.

I'll do it!

Made a litte start already: https://gist.github.com/ItsDizzy/b3852392ee9dc0e4f092411bf8176eb2

Generated this template 99% automatically from docs.json https://gist.github.com/oorooroot/091e392cdc45a995b2fade876980c0cd
Need some review on it, please. Creating typings first time.

@oorooroot how did you do that?

@oorooroot good job.

@oorooroot and thank you very much, I really needed this haha

@oorooroot: Looks really good 👍
The comments might be removed though? Looks like it's just a plain copy of code comments, so it might not be necessary in the definition file and it's also "code" (well not really, they're comments) duplication.
But appart from that, nice job! Maybe you could open a PR with this and a modified package.json adding a scripts entry to generate it the way you did so the discord.js team could automate it when they make changes/new releases.

@chadrien i think that comments are necessary for class, member and argumet description, when using definitions in any IDE. I will refactor my script in few days, polishing some things, including better comments.
Im still not sure if it is such good idea, to generate typings from docs. During parsing the docs i found some argument or member types, that are not defined by docs.json or any javascript code in the project(you can found this type definitions at the end of my .d.ts file, VerificationLevel or RoleData for example, all of them typed as any).
There are also some documetation-described types that looks strange for me. As example @returns {Promise<Invite, Error>} here https://github.com/hydrabolt/discord.js/blob/indev/src/client/Client.js#L197
or @returns {Object<string, boolean>} here https://github.com/hydrabolt/discord.js/blob/indev/src/structures/EvaluatedPermissions.js#L24 not sure if Object<string, boolean> is correct definition in js, but in typescript definitions i just replaced with {[K:string]: boolean}(such cases are hardcoded in my script so it is pretty ugly for now).
So there are some "special requirements" to documentation, if we wsnt to get all the things typed 100% automaticaly.

The , mean it can return 2 types. Promise<Invite, Error> means it will either return a Promise with a Invite type or one with an Error type, the corrent way of defining this would be Promise<Invite | Error>

@chadrien I came here to offer to do this also, because I'm in almost the exact same situation, want to convert my bot to TS, need a def file.
Just wanted to point out that the way users acquire typing files has changed in Typescript 2.0
See here for more info
This means publishing a Scoped NPM package (@types/discord.js)
if you need any help, give me a bell, really keen to give back to this project.

@Mischala I would also like an @types package

someone might want to take a look at https://github.com/englercj/tsd-jsdoc. it generates typescript definitions from jsdoc, and we have the entire client documented with jsdoc :)

I thinks that is what @oorooroot did

@GusCaplan good call, will have to check if @hydrabolt 's jsdocs are read correctly by that tool

@iCrawl Is there a reason this can't be maintained as part of the original project?
especially with these improvements to the Typescript's typing's acquisition.

0 at all. There was just no PR yet. I will have a talk with him so it will probably be included in indev.


Convert some colors like Selection from HEXA to HEX.

Convert from the transparent colors into the non-transparent ones.

converter: https://tdekoning.github.io/rgba-converter/


New deps, auth token lib, debug, parse cmd line.

Update deps, add library for dealing for auth tokens, parse commandline, enable debug printing.

This looks great! And also looks like a suitable solution to https://github.com/CloudCredo/graphite-nozzle/issues/3 (@bonzofenix and @cloud-dude - would you care to comment?).
I'm getting a Received a status code 401 Unauthorized error message when trying to run it. My admin user has the correct scopes, and running the previous nozzle against the same bosh-lite CF seems to work fine. Is there something I'm missing?

@teddyking ah yes, forgot to update the docs about that.
This PR makes the assumption that a client have been added to the installation like, https://github.com/cloudfoundry-incubator/datadog-firehose-nozzle#configure-cloudfoundry-uaa-for-firehose-nozzle
I can alter the PR to use the go-cfclient if you would rather login with a normal user like we do in firehose-to-syslog.

Ah that'd be it.
Let's keep it as it is and update the docs - it probably makes sense to keep in line with what other nozzle authors are doing.

@teddyking agreed, to some extent, makes it harder to test against bosh-lite as you have to remember to create a firehose user in the manifest though.
Maybe we can suggest to the Pivotal foks to have a default firehose user in the templates?

Looks great - all merged. Thanks for the PR!
And yeah I think it'd be really useful to have a default firehose user in the templates.


ImportError: No module named 'squeeze.squeeze'

Did you solve this problem?I met the same question as you

Did you check if there is a file named "squeeze.cpython-****.so"?

I have the same problem

try to change the pah of 'squeeze', like it "<AFM_root>/squeeze"

I sloved it by git clean ``-xdf and   make again

I sloved it by git clean -xdf and make again

That's great! Thanks.


Docstring missing for matplotlib.pyplot.plot

I use VSCode and the python extension for my everyday coding. Typically I use it in REPL mode, connecting to a Jupyter session. I am very happy with this environment.
One thing that I wonder about is they way help popups work.  I'm not sure if it is a misconfiguration on my part or if it is supposed to work that way,
I have attached a screenshot of a minimal example, where the documentation for plt.plot() is very limited in the editor window; but help(plt.plot) at the console gives the full information. I get full documentation for some, but not all commands. The same example in, e.g., Spyder gives full information.
Misconfiguration or feature? I run the latest version of VSC and the extension on a Mac/Catalina.

Closing since static code analysis is unable to determine dynamic assignments at runtime. Possible solution is to have package declare it statically, helping editors. In any case, LS can't do much here.


Make LR self contained (Windows only)

This PR is initially for discussion.
It adds a Lua binary (5.2) to the bin directory, so LuaRocks runs completely independent of the Lua host installation, to reduce chances of interference. Basically the next step after moving the binaries out of the PATH (was also to reduce interference).
Not sure whether is worth the hassle. Just a possibility; maybe install Lua (5.1/5.2/Jit) itself as a rock as LR then no longer depends on Lua being present on the host.
please comment.

I know I'm (very) late to get into the discussion, but binaries in git repos irritate me so I can't keep myself out of this.
@Tieske ,

Though I agree with your comments; untidy and storing binaries being bad. But the alternative is a more complex setup, with limited maintenance capability/resources

You said earlier that it just developers to use git. What's so complicated for a developer to use subtree/subproject(s)?

(Hisham basically). The gain would be appr. two dozen developers having less stuff in their repo (visibly only, the full history including binaries will still be in their Git repo!).

If you let binaries into the repo then sooner or later you will want to update them. Or (hopefully) you'll understand what a bad idea it was and delete them. Binaries expire. period.
And my last 5 cents: if you did that for win32 why stop? Add win64, MacOS, LuaJIT, Lua6, whatnot, etc.etc. for completeness(?)


Always error on property override accessor

With useDefineForClassFields: true, it was already an error to have a property override an accessor or vice versa, because neither works with that flag on. With useDefineForClassFields: false, it is possible to have a property usefully override a getter/setter pair, but there will be a runtime error if there is no setter. My analysis of our user tests, and our partner's analyses of their internal code bases, didn't show any uses of this pattern, however.
However, this is a new error, so I'm going to hold this change until 4.0, even though it shouldn't affect many projects.
The code change to add the error is tiny. Most of the review adds a codefix, fixPropertyOverrideAccessor. This codefix just delegates to generate get/set accessor, and moves the code into a central place. I added parameters to the function so that it could be called from a refactor as well as a codefix. I think it's possible to reconcile the types used in the two, but I didn't want to do it here.
Fixes #34585
Fixes #34788

Assigning this to two people since the reviewers list is broken. @jessetrinity this is only technically touches refactors, but I thought it might be interesting to you anyway.

Easiest way to view the changes to the original refactor code is to view just 4d541d2b7430d4a6e85c9191654a8d83fd3d2019 with whitespace turned off.

Github isn't showing e466bb94c173b1eaaf697590538b0c47651f5efa which I just pushed but it sure seems to be the head of always-error-on-property-override-accessor!

See here for the actual commit history: https://github.com/microsoft/TypeScript/commits/always-error-on-property-override-accessor

How then are we meant to constrain properties of a base class?
export class ApolloQuery<Data, Variables> {
  variables: Variables; // the `variables` property must be assignable to Variables
  // ...
}

import { ApolloQuery } from 'apollo-elements';

import MyQuery from './my.query.graphql';

import { MyQueryData } from '../codegen.ts';

class MyQueryElement extends ApolloQuery<MyQueryData, MyQueryVariables> {
  get variables(): MyQueryVariables { // ts2611
    return somehowParse(this.location); // say, derived from window.location.href by the app's spa router
  }
}

This is perfectly reasonable JavaScript, but now errors in TypeScript 4

@bennypowers
Your case would result in the variables getter being overridden with an instance data property with a value of undefined.

If you need to specify that a certain property must be present in subclasses, you can use an abstract class:
export abstract class ApolloQuery<Data, Variables> {
	declare abstract readonly variables: Variables;
}

The above allows implementations to use an accessor or data property.

@brianmhunt @ExE-Boss filed https://github.com/microsoft/TypeScript/issues/40220, which proposes not making @ExE-Boss's solution an error, and keeping Sub.prop an accessor instead of turning it into a property.

IIRC, we can't make an abstract mixin class

Should this really apply to declare declarations? E.g. when a subclass getter overrides a superclass and you know better than the compiler.
class Super {
   get prop(): boolean | number | string { /* … */ }
}
class Sub {
   // Based on the inner-workings of the getter, I know for sure this will always be a boolean.
  declare prop: boolean; // error: ts(2610)
}

'prop' is defined as an accessor in class 'Super, but is overridden here in 'Sub' as an instance property. ts(2610)

@chharvey
Since there’s no setter, it should be:
class Sub extends Super {
	// Based on the inner-workings of the getter, I know for sure it will always be a boolean.
	declare readonly prop: boolean;
}

@ExE-Boss — even with readonly, I still get the same error: Playground

Notwithstanding other considerations, declare readonly prop: boolean seems like an elegant option.  Perhaps it would be worth opening a separate issue?

@brianmhunt
See https://github.com/microsoft/TypeScript/issues/40220, which was opened by @sandersn in https://github.com/microsoft/TypeScript/pull/37894#issuecomment-679238923.

@sandersn
This PR should probably be locked with new comments being directed to https://github.com/microsoft/TypeScript/issues/40220.

This change has made upgrading to TS4.0+ incredibly difficult for the vscode-docker extension. We share a UI framework with quite a number of other Azure-related VSCode extensions; this framework heavily (ab)uses the ability to override properties with accessors. Never had any problems. Hundreds of files across dozens of repos would need to be fixed to be able to upgrade.
It would be very nice to have either the ability to suppress this specific error only in source (i.e. #19139) or globally.

I would like to chime on and repeat what @bwateratmsft said. We are a library vendor with a very large TypeScript definition file that has been in use since almost TypeScript 1.0. Our Typescript definition file curently works with all versions of TypeScript 2.8 and newer (until 4.0) and we haven't heard complaints from our customers.
Now with this incompatible change, it becomes literally impossible to support all our customers properly: Since the support for the declaration of property accessors was only added with 3.6, until today we have been declaring our properties as "fields". Now with 4.0 this actually becomes an error and our customers cannot switch to 4.0.
However in order to workaround this, we would need to require all existing users to at least switch to 3.6.
So ultimately library vendors  have this dilemma. Since AFAIK you can only have one type definition file for your project, you need to decide whether you want to support existing customers (before 3.6 - which isn't really old, at all), or allow customers to switch to 4.0. No matter how we decide, we will be doing an incompatible change for a large fraction of our users. From a user's perspective this is even worse: In order to switch to a newer version of TypeScript, I now have to make sure that all my dependencies are either "old" or "brand-new" - I cannot have a mixture. This makes migration a nightmare. It wouldn't be so much of a problem, if there was a way to make this a warning that can be disabled.
I agree that this should be an error for TypeScript code that calls TypeScript code, but for libraries (type definition files), this change single-handedly invalidates a great number of third party libraries that cannot be used with the most recent version of TypeScript anymore. This shouldn't be an error that you cannot even ignore, because this literally works in JavaScript and this is about JavaScript-interop.
Please make this configurable to help adoption of TypeScript 4.0

I wanted to add an update since I figured out a way to upgrade the Docker extension. Essentially, we have an intermediate class that redefines the properties as abstract--now child classes can do either a property or an accessor. I'm sure this won't work in every scenario but hopefully can help some.
Before:
class Foo {
    public readonly bar?: string
}

class Baz extends Foo {
    public get bar(): string { // Error!
        return 'abcde';
    }
}

Now:
class Foo {
    public readonly bar?: string;
}

abstract class Intermediate extends Foo {
    public abstract bar?: string;
}

class Baz extends Intermediate {
    public get bar(): string { // No error
        return 'abcde';
    }
}

class PropertyBaz extends Intermediate {
    public readonly bar?: string; // Also no error
}

Ewww.. Thanks for the update @bwateratmsft . I don't think this is feasible for large libraries and also messes with code completion and docs, though:
It doesn't work for typescript definition files targetting TS < 3.6 because you can't have accessors in there.
To quote the docs:

[Before 3.6] The rationale was that accessors weren’t distinct from properties as far as writing and reading to these properties

... and with 4.0 this has become an error. So that's a very tough change and a very short migration of less than one year. Every .d.ts file that is older than one year now and modelled properties, now breaks with 4.0 and there is nothing you can do.
The choice is to either annoy your older users by breaking their builds when you update your typings to work with 4.0, or annoy the new users that are using 4.0 - there is no way one can satisfy both. I guess your code only works with 3.6 and newer, now?
Is there no way to have two d.ts files in node modules that depend on the typescript version used? Are we left with duplicating our node modules for the various typescript versions out there?

The choice is to either annoy your older users by breaking their builds when you update your typings to work with 4.0, or annoy the new users that are using 4.0 - there is no way one can satisfy both. I guess your code only works with 3.6 and newer, now?
Is there no way to have two d.ts files in node modules that depend on the typescript version used? Are we left with duplicating our node modules for the various typescript versions out there?

Use the typesVersions package.json key.

@sandersn When we upgraded to TypeScript 4.0, this validation seems to be incompatible with API Extractor's mixins.  For example, this code:
api-extractor-model/src/model/ApiEnum.ts
  /** @override */
  public get members(): ReadonlyArray<ApiEnumMember> {
    return super.members as ReadonlyArray<ApiEnumMember>;
  }

...is overriding a mixin base class that is defined using an interface:
api-extractor-model/src/mixins/ApiItemContainerMixin.ts
export interface ApiItemContainerMixin extends ApiItem {
  /**
   * Returns the members of this container, sorted alphabetically.
   */
  readonly members: ReadonlyArray<ApiItem>;

The error is:
src/model/ApiEnum.ts:62:14 - error TS2611: 'members' is defined as a property in class 'ApiDeclaredItem & ApiReleaseTagMixin & ApiNameMixin & ApiItemContainerMixin', but is overridden here in 'ApiEnum' as an accessor.

But because ApiItemContainerMixin is an interface, there doesn't seem to be any way to express that members is a property getter.  (Even though the actual implementation is a getter.)

Also, // @ts‑ignore does not work in our case, because it doesn't get emitted in the .d.ts file.

Seems this comment did not age very well ;-) :

A read/write property (whether implemented as a field or a get/set pair) is substitutable for a read-only property.

Indeed if what you are saying is true, then this change is even worse than I thought.

@octogonz Can you open a separate issue for that? It sounds like a bug, and I couldn't repro it from your description:
interface I {
  readonly members: void
}
class K implements I  {
  get members(): void {
    return void 0 as void;
  }
}

I cloned rushstack but ApiEnum doesn't actually implement any interface now, so I guess you must have already worked around this?

@sandersn The bug involves extends not implements because it is a mixin.  I can open a separate issue.
I can also find the commit hash that failed, gimme a minute...

Clone the branch https://github.com/microsoft/rushstack/tree/octogonz/ts-37894
rush install
rush build --to api-documenter

You will see this error:
[api-extractor] Warning: C:/Git/rushstack/apps/api-extractor-model/dist/rollup.d.ts:345:9 - (Compiler) 'members' is defined as a property in class 'ApiDeclaredItem & ApiReleaseTagMixin & ApiNameMixin & ApiItemContainerMixin', but is overridden here in 'ApiEnum' as an accessor.
The only fix that worked was to delete the problematic property from the API.

Here's a minimal repro (playground link):
// Mixin utilities
export type Constructor<T = {}> = new (...args: any[]) => T;
export type PropertiesOf<T> = { [K in keyof T]: T[K] };

interface IApiItemConstructor extends Constructor<ApiItem>, PropertiesOf<typeof ApiItem> {}

// Base class
class ApiItem {
  public get members(): ReadonlyArray<ApiItem> {
    return [];
  }
}

// Normal subclass
class ApiEnumMember extends ApiItem {
}

// Mixin base class
interface ApiItemContainerMixin extends ApiItem {
  readonly members: ReadonlyArray<ApiItem>;
}

function ApiItemContainerMixin<TBaseClass extends IApiItemConstructor>(
  baseClass: TBaseClass
): TBaseClass & (new (...args: any[]) => ApiItemContainerMixin) {
  abstract class MixedClass extends baseClass implements ApiItemContainerMixin {
    public constructor(...args: any[]) {
      super(...args);
    }

    public get members(): ReadonlyArray<ApiItem> {
      return [];
    }
  }

  return MixedClass;
}

// Subclass inheriting from mixin
export class ApiEnum extends ApiItemContainerMixin(ApiItem) {
  // This worked prior to TypeScript 4.0:
  public get members(): ReadonlyArray<ApiEnumMember> {
    return [];
  }
}

This is a wacky technique obviously. But to be fair, it was demonstrated in the TypeScript 2.2 release announcement. 😁
I almost regret choosing this approach, except that the mess is mostly on the implementation end.  For end users of our API, the mixins rather neatly fit the sparse matrix of declaration features into a normal-looking class hierarchy.

I believe the better solution is, if the base class only has a getter (thus the base class property is readonly), then there should be an error in that particular case. Otherwise, there should be no error.
Blocking normal JavaScript behavior is against TypeScript's design goals, and this change does not improve static type checking.
This is painful upgrading a library to TS 4.

I believe the better solution is, if the base class only has a getter (thus the base class property is readonly), then there should be an error in that particular case. Otherwise, there should be no error.
Blocking normal JavaScript behavior is against TypeScript's design goals, and this change does not improve static type checking.
This is painful upgrading a library to TS 4.

The whole purpose of useDefineForClassFields, if you ask me, is specifically for inheritance involving accessors, and the ability to write class fields in sub classes.
By disabling "override" of accessors when useDefineForClassFields is set to false, end users now always have an effective situation that is no different than useDefineForClassFields set to true, effectively making useDefineForClassFields always true.
Yes, there are actual runtime differences, but with this new rule preventing accessor override when useDefineForClassFields is false, the end user will never experience the difference (even when trying to intentionally), effectively nullifying the need for the useDefineForClassFields option.
What I mean is, that now, you either never use accessors in a class hierarchy for a given prop, or you use only accessors, which makes useDefineForClassFields essentially obsolete.

The whole purpose of useDefineForClassFields, if you ask me, is specifically for inheritance involving accessors, and the ability to write class fields in sub classes.
By disabling "override" of accessors when useDefineForClassFields is set to false, end users now always have an effective situation that is no different than useDefineForClassFields set to true, effectively making useDefineForClassFields always true.
Yes, there are actual runtime differences, but with this new rule preventing accessor override when useDefineForClassFields is false, the end user will never experience the difference (even when trying to intentionally), effectively nullifying the need for the useDefineForClassFields option.
What I mean is, that now, you either never use accessors in a class hierarchy for a given prop, or you use only accessors, which makes useDefineForClassFields essentially obsolete.

Blocking normal JavaScript behavior is against TypeScript's design goals,

Exhibit 1:
This is an error on the playground:
const lucky = true + 12

because we decided to restrict the normal JS behaviour — it's surprising and weird.
Exhibit 2:
In Chrome's console, this code doesn't set _foo
class Foo {
  _foo: number = 1
  get foo() {return this._foo}
  set foo(v) {this._foo = v}
}

class Bar extends Foo {
  foo = 123
}

That is, the de facto JS VM gives this code surprising behaviour that we decided to restrict. Sometime in the future, these semantics will be in the spec. At that point we'd like to deprecate and remove [[Set]] semantics. Between now and then, it's worth making the pattern an error so that people can't observe a difference between the two.

Still no alternatives to this day?

Huh, just stumbled upon this issue when upgrading my project to TS 4. "Solved" it with // @ts-ignore
The pattern, perfectly valid in JavaScript is restricted in TypeScript. Is the TS design goal to limit the expressiveness of the language?
The ability to abstract the property access is very useful, I don't know how did you conclude this pattern is not used anywhere. Probably you've examine only a small portion of the TS codebases out there.
It seems the motivation was to fix #34585, #34788. But even the author of 34585 complains about this change.
@sandersn Please hear all the people in this thread. Please provide a flag for this breaking behavior.

@sandersn In this comment you write:

There were 7 examples of accessor-override-property, all of which were trying to make the derived property readonly by only providing get, which would crash with [[Set]], so I think those accessors were never used.

However, the main use case for this pattern is not making a property readonly. It is about augmenting the property access:
class Foo {
    bar             : string
}

class Baz extends Foo {
    $bar : string

    get bar(): string {
        // CAN TRIGGER SOMETHING HERE
        return this.$bar
    }

    set bar(value: string) {
        // CAN TRIGGER SOMETHING HERE
        this.$bar = value
    }
}

And again, it is perfectly valid in JavaScript.

The base doesn't trigger the accessors, which is confusing:
class Foo {
    bar             : string
    showBar() {
        this.bar = 'uh-oh' // DOESN'T TRIGGER Baz setter
        console.log(this.bar) // DOESN'T TRIGGER Baz getter
    }
}

class Baz extends Foo {
    $bar : string

    get bar(): string {
        // CAN TRIGGER SOMETHING HERE
        return this.$bar
    }

    set bar(value: string) {
        // CAN TRIGGER SOMETHING HERE
        this.$bar = value
    }
}

Is the TS design goal to limit the expressiveness of the language?

It's goal number 1: identify constructs that are likely to be errors.

The base is not supposed to trigger anything - in the base class the bar is a property. More over, in the subclass it is also a property - from the user perspective. The underlying implementation details have changed. Not sure where do you see an error here.

An example from the real world code:
 class SomeClass extends BaseClass {
        @special_reactive_decorator()
        reactiveProperty     : SomeClass

        // our override for the `parent` property, which is needed to update the `parentEvent` property
        private _parent : this

        get parent () : this {
            return this._parent
        }
        set parent (value : this) {
            this._parent = value
            this.reactiveProperty = value
        }
}

In this example, we extend the base model, which has a regular property parent, and in the subclass, duplicate all writes to parent to another special reactive property, which triggers updates elsewhere.
@sandersn I don't see any errors here. I also foresee you saying - okay, just create a method setParent and override that, but the thing is, in the rest of the codebase the parent is assumed to be a property and fixing all those places / changing the contract is not an option. Thankfully JavaScript is expressive enough to allows to easily augment the property access with the getters/setters in the subclass.
@everyone in this thread, please post your examples where you use the property augmentation with getters/setters and describe the use case it solves for you. Need to demonstrate that this pattern is valid.

The problem is in BaseClass. There, this.parent is not the same as this.parent in SomeClass. This is confusing in two ways: broadly, JS doesn't normally work this way; narrowly, this.parent references in BaseClass don't update reactive properties in SomeClass.

This is confusing in two ways: broadly, JS doesn't normally work this way;

Not clear what you mean. This pattern is perfectly valid in JavaScript. From consumer perspective, both BaseClass and SomeClass have the same interface.

this.parent references in BaseClass don't update reactive properties in SomeClass

Not clear again. Why do you expect the parent class to work in the same way as the subclass. The whole purpose of subclassing the BaseClass with SomeClass is to add that reactivity update. Of course, in the BaseClass that update does not happen, because BaseClass does not have the reactiveProperty in the first place.

@canonic-epicure I think the inconsistency @sandersn is referring to can be illustrated with this example. You can see the logged results by clicking the "Run" button in the toolbar.

I think the confusion stems from the fact that this does not work with class fields. It does however work in almost any older code that defined fields in a different way, e.g. by declaring the field with a default on the prototype of the base class, or simply setting the value in the constructor, which is not what happens with class fields.
We had the same problem in our code: our code was written with without ES classes and ES class fields. And when we wrote our typescript typings for the JS library, we declared properties and field as a field and it was possible to have subclasses "override those fields" with getters and setters, but we are not able to model that anymore with the change.
I too, find it unintuitive that the code you posted does not work, which is due to the way class fields work in JS:

Public instance fields are added with Object.defineProperty() either at construction time in the base class (before the constructor body runs), or just after super() returns in a subclass.

Due to this mechanism, your get and set accessors simply disappear (get hidden) and your code does not work, but only if you are using native class fields.

@andrewbranch Yes, I'm totally for treating this as an error for the ES class fields, your example illustrates it very well and @yGuy describes what happens in it:

Due to this mechanism, your get and set accessors simply disappear (get hidden) and your code does not work, but only if you are using native class fields.

However, personally, I think ES class fields are non-idiomatic JavaScript, because they always "hide" the value in the prototype (even if the fields does not have the initializer). This breaks the other idiomatic JavaScript pattern, where you "thread" some property object through the class hierarchy, at each level using the value of the previous level as a prototype. Plus it breaks the "property access augmentation" pattern.
Also, anybody tried to benchmark the class instantiation, the "old" class properties vs "new" ES class fields? If you try, you'll be very surprised.
This is why, personally, I'm not going to use the useDefineForClassFields setting and I think, the "old" way of handling class fields in TypeScript is correct and more idiomatic JS.
I believe the compiler error discussed in this thread should only be generated for the useDefineForClassFields : true case.

@sandersn @andrewbranch Any comments regarding the note, that the compiler error under discussion is only relevant for the ES class fields case?

The way I see it, the very useful pattern has been needlessly restricted in TypeScript. Language expressiveness has been artificially limited.
This compiler error is protecting the the useDefineForClassFields : true users, at the expense of useDefineForClassFields : false users, who lose the property access augmentation pattern.
Why favoring one part of the community?

There seems to be a confusion of intention here among commentors. TS is actually tracking the JS standard on this feature, which has effectively been implemented in JS since Chrome 72 shipped with these semantics enabled.
This is necessary to prepare for a shift within JS itself on this issue:
https://github.com/tc39/proposal-class-fields
https://github.com/tc39/proposal-decorators/#set
useDefineForClassFields effectively means that in TS (and hence the compiled result in JS) there is a difference between
class A {
   x
}

compiling with useDefineForClassFields=false to
class A {
}

vs compiling with useDefineForClassFields=true to
class A {
    constructor() {
        Object.defineProperty(this, "x", {
            enumerable: true,
            configurable: true,
            writable: true,
            value: void 0
        });
    }
}

given the new rule that even stating defined fields like x above are initialised to undefined when useDefineForClassFields=true in the new JS standard ... as opposed to just being omitted in the traditional TS compilation with useDefineForClassFields=false.
This has flow-on issues with conformity of field overrides in subclasses ... and the proposal itself notes the contested nature of this issue.
TS adapts to these differing intentions by using the keyword declare ... which now can be used to also redeclare a field in a subclass, but without incurring the effect that field being initialised in the subclass itself.
This is not a case of favouritism. TS must adapt to the new JS standard itself ... but as with most of these progressive adaptations, legitimate JS may require hacks within TS to accommodate edge cases.

I don't think there's a confusion here, I believe all commentors understand the topic very well. I'm just pointing that, the compiler error being discussed is only valid for the new JS standard (useDefineForClassFields=true) and not valid for the "classic" TypeScript class fields (useDefineForClassFields=false).
Personally, I think that "define" semantic for class fields is a very unfortunate ES spec quirk. Also, if you benchmark the instantiation of class with native JS fields, you'll notice its 10x slower. That is why, again personally, I'm not going to use native class fields, nor the "define" semantic for them.
People who prefer the "define" semantic, will of course benefit from this compiler error, which will protect them from some un-intuitive errors in the code, as illustrated by @andrewbranch. But what about people who are not going to use the "define" semantic? Such people are just needlessly restricted from using the very useful and practical patterns, arising from the property augmentation with getter/setter. This is why I believe the error should be only enabled in the useDefineForClassFields=true case.

You are demonstrating the confusion that you say does not exist, and I feel for your situation because I have had to do extensive recoving to accommodate new behaviours. You seem to be confusiing a decision that TS has made to move towards an emerging JS syntax standard vs some favouritism. That's the confision that I am highlighting.
This is not a criticism of your argument - I actually agree that this is a sharp incline for adoption by some coders and I wish that there were a keyword that could accommodate the legacy coding intentions better or just make useDefineForClassFields=false more inclusive until the next major version bump in TS. My comment was just a defence of the difficult position that TS must take to evolve the language.
The performance ramifications etc are not a TS issue: the conversation regarding these issues was at the JS level and TS was appartently rather neutral.
The problem that TS faces is that as a represtation of "JS + types", it needs to maintain good conformity with the JS representation and syntax of the language itself. Imagine the situation of doing the reverse of what you are doing: ie instead of going from TS->JS, go from JS->TS with the following code:
class A {
   x
}

Which interpretation  is correct when copying and pasting this into TS from JS: useDefineForClassFields=false or useDefineForClassFields=true? By default, this new JS lanuage construct now means that the original coder meant useDefineForClassFields=true.
I have no insight into the internal politics of TS, but I presume that useDefineForClassFields=false will actually become a legacy feature.

I have no objection that useDefineForClassFields=true is a new default behavior, matching JS. That's fine.
However there are reasons (performance, loss of useful programming patterns) to use the "legacy" behavior: useDefineForClassFields=false. The majority of the codebases is written with the useDefineForClassFields=false assumption, this setting is going to be supported for a very long time.
Now again, the people who are not going to use the "define" semantic - they lose the patterns I've mentioned because of this compiler error. Why do we have this error? To protect the people who will be using the "define" semantic.
The 2nd group of people is favored at the expense of the 1st.
What is the confusion here?

The confusion is that you are mistaking a TS design goal for favouritism.
"6. Align with current and future ECMAScript proposals."
If you want better legacy support for useDefineForClassFields=false, then I support that, but my point has (repeatedly) been that this is not favouritism.

Yes, my only point is that "legacy" behavior has been needlessly restricted by this compiler error. Also I'm pointing that this "legacy" behavior will have to be supported for a very long time (performance problem with native class fields), so its worth actually fixing this restriction.

@sandersn @andrewbranch Thanks for the feedback. @poseidonCore You are right, its not a favoritism. It is ignoring.

TS must adapt to the new JS standard itself ... but as with most of these progressive adaptations, legitimate JS may require hacks within TS to accommodate edge cases.

I can see that this can make sense for newly compiled TypeScript code.
I don't understand why the same rules need to be put into place for type definition files. Because of course I can describe an existing API that works like described above. And still TS now sees this as an error, when it clearly is not one. That is inconvenient to everyone, because the way it has been implemented in the third party library ( no matter what useDefineForClassFields is set to), this implementation will error out. Third party library and typings authors need to adjust their type definition files so that TS will accept it.
And this has certainly not been an edge case for JavaScript for years, so many files are affected, I guess. In fact I would argue that the majority of hand-written JS code did never use the define approach and thus all that we are left with this implementation is needlessly invalidated type definition files. So at least this was ignoring the perspective of the type definition authors.

@yGuy: https://github.com/microsoft/TypeScript/issues/40220

Additional consideration is that, according to the TC39 proposal, it will be possible to switch to the Set semantic for certain properties, using the ES decorators:
As a mitigation, the decorators proposal provides the tools to write a decorator to make a
public field declaration use [[Set]] semantics. Even if you disagree with the default,
the other option is available. (This would be the case regardless of which default TC39 chose.)

This means, that the "property access augmentation" pattern will still remain valid in JavaScript, even for native class fields, a user will just need to opt-in for it, using the decorator. Not in the TypeScript though.
But if you don't listen, how can you hear?

This is what I was referring to when I said "I wish that there were a keyword that could accommodate the legacy coding intentions better", and is why I linked to https://github.com/tc39/proposal-decorators/#set.
There is a relevant discussion here: https://github.com/tc39/proposal-decorators/#how-should-i-use-decorators-in-transpilers-today
As for "But if you don't listen, how can you hear?" ... bear in mind that these are still proposals, and the TS team is probably hearing more than what you yourself are listening to.

Part of this conversation has been hovering right on the edge of what’s appropriate for this particular forum, so while I appreciate that you all have kept it from getting out of hand so far, I want to preemptively refocus it and lower the temperature. The TypeScript team is very open to criticism on technical decisions we’ve made based on technical reasons and anecdotes about your own experience using the language. I would ask that the discussion on the issue tracker (1) assume good intentions of everyone involved, and (2) remain focused on the language feature in question. Thanks!

@andrewbranch I'm totally for constructive discussion. It is just sometimes you need to shout to be heard (and noticed).
Summarizing the recent comments:

Overriding property of the base class with getter/setter pair is a useful "classic" JavaScript pattern, which allows for example augmenting property access in some 3rd party codebase (or even in your own code)
Right now, in "modern" JavaScript this pattern won't work as expected (as demonstrated by your example). However, there's a promise from TC39 commitee to provide an opt-in escape route to the "classic" behavior with decorator
In TS "classic/modern" switch is defined with "useDefineForClassFields" compiler option (SET/DEFINE semantic for class fields)
The "classic" behavior with "SET" semantic will need to be supported for a long time, since a lot of code is written with SET semantic in mind
It may or may not be reasonable to restrict this pattern for "DEFINE" semantic - personally I don't have an opinion on this. Perhaps the decision on this can be postponed until the decorator proposal reaches stage 3 at least. Perhaps it should be more like a linter rule, than a compiler error.
It is very reasonable to keep the pattern valid for SET semantic
Right now, the compiler restricts this pattern for both SET/DEFINE semantics
Proposal is - to keep the compiler error only for the "DEFINE" semantic

It looks to me like there are two distinct new proposals that have come out of the discussion, which are related to #40220.

#40220 proposes that ambient properties be allowed to override accessors.
It sounds like @yGuy also wants accessors to override ambient properties to model JS dependencies.
It sounds like @canonic-epicure wants to use [[Set]] semantics to build a TS class hierarchy.

@canonic-epicure @yGuy can you open sibling issues to #40220? It'll make it easier to prioritise long-term. And @canonic-epicure I think you've collected enough arguments to make a solid proposal. However, I still don't understand your example code. Can you rework that for the proposal? I think you may just need to make clear that it only works with [[Set]].

@sandersn Ok, opened a new issue with proposal. Elaborated on the example and made the SET/DEFINE context more explicit.

@andrewbranch @sandersn Ok, the proposal created. What will be the next step?

A Workaround
Use case: Narrowing the type of an accessor on a subclass
Example:
interface Options { /*...*/ }

class Super {
  #options: Options;
  get options(): Options { return this.#options; }
  set options(o: Options) { this.#options = o; this.optionsChanged() }
  optionsChanged?(): void
}

interface SpecificOptions extends Options { /*...*/ }

class Sub {
  declare options: SpecificOptions;
}

Workaround:
interface Options { /*...*/ }

class Super {
  /** @internal */
  static o(proto: Super, _: string): void {
    Object.defineProperty(proto, 'options', {
      get() { return this.#options; },
      set(v) { this.#options = v; this.optionsChanged?.(v); },
    });
  }
  #options: Options;
  @Super.o options: Options;
}

interface SpecificOptions extends Options { /*...*/ }

class Sub {
  declare options: SpecificOptions;
}

Explanation: The original reason for using accessors to define options was to run side effects when setting the property. This change prevents subclasses from narrowing the type of options. The solution is to define the accessors using a decorator defined as a static function on the super class. We could also use a function declaration if we didn't use private storage.


Deployment to raspberry PI (Arm64) fails

Motivation
I want to to try out Kong as API-gateway on my PI 4 running K8S.
Expectation
I figured that the image used in the current chart version does not find an image for the arm64 architecture, but found out there was a dedicated docker image for arm, so I overrode that.
What happens
Still, I was unsuccessful spinning up a pod of arm64v8/kong:ubuntu.
Output on stdout:
standard_init_linux.go:211: exec user process caused "exec format error"

This indicates the platform does not match.
I am not 100% sure this is the place to ask, since my setup is K8S (K3S distribution) and deployment via Helm, so feel free to redirect!
Observations
I installed with
helm install kong --namespace=kong --skip-crds --set ingressController.installCRDs=false --set image.repository=arm64v8/kong --set image.tag=ubuntu kong/kong

The pod triggered seems to hold the proper (overridden) image (from kubectl describe):
proxy:
    Container ID:   containerd://211e508357f16194b8a6c003579c26ace13c87408a91396b479a5f52f91d3a19
    Image:          arm64v8/kong:ubuntu
    Image ID:       docker.io/arm64v8/kong@sha256:39e4b224efc8b79152c7f2cdc7fd9f89e86dbb514b8257cf2e246bcc41f78a8a

Thanks for your support and the great work on Kong!
Oliver
Remark: this is a crossposting from the docker-kong repo, since I really don't understand to which part (chart, image) the issue is more related to. Linking those issues.

@hutchic How do use arm64 Docker image of Kong? Does the Docker repo or tag change?

Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:        18.04
Codename:       bionic

Can you send the output of lsb_release -a and uname -a?

sure!
lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

uname -a
Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

May there be the culprit? armv7l? I assumed the PI 4 has got an armv8 processor
Remark: I try running it inside a K3S-Kubernetes cluster. So there's no docker, but only containerd. This shouldn't make a difference as per my understanding though.

armv7l (in Docker terminology arm32v7) is indeed the culprit as it's a 32 bit processor and running a
arm64v8 image won't work.
If there's enough demand we can look into building arm32v7

I'd also be interested in a arm32v7 build at some point in the future!

I'd also be interested in a arm32v7 build at some point in the future!

I would be interested too!

I would be interested too!


faster models

Thank you for the convenient interface for HuggingFace.
In batch mode, DistilBertBaseUncased  scores 21 texts/second with a modest CPU, but I would like to score millions of texts, so I would like to compare other models such as SqueezeBERT and MobileBERT. Would you be willing to add support for some more models?

I read the docs :)