Chore: replace atheris with hypothesis in test_utils.py

Proposed changes
Atheris fuzzer tests were disabled. Atheris does not behave nicely on windows and not that great on my local system either. After consulting @dvilelaf and @Adamantios we decided to replace the tests in which the library is used with hypothesis tests.
TODO:

remove atheris from tox.ini
https://github.com/valory-xyz/open-autonomy/blob/8ff95afdc1a7c8f6b782a98b8f22709ae3fe4dc7/tox.ini#L49-L52
address flaky test failure seen in child PR, see https://github.com/valory-xyz/open-autonomy/pull/1615#issuecomment-1339633506

Fixes
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce? (A breaking change is a fix or feature that would cause existing functionality and APIs to not work as expected.)
Put an x in the box that applies

[ ] Non-breaking fix (non-breaking change which fixes an issue)
[ ] Breaking fix (breaking change which fixes an issue)
[ ] Non-breaking feature (non-breaking change which adds functionality)
[ ] Breaking feature (breaking change which adds functionality)
[ ] Refactor (non-breaking change which changes implementation)
[ ] Messy (mixture of the above - requires explanation!)

Checklist
Put an x in the boxes that apply.

[ ] I have read the CONTRIBUTING doc
[ ] I am making a pull request against the main branch (left side). Also you should start your branch off our main.
[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have locally run services that could be impacted and they do not present failures derived from my changes

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

e2e test failure:2022-12-05T22:21:27.3382172Z [97827]stdout>  File "/tmp/tmpv79piaun/agent_00000/vendor/valory/skills/abstract_round_abci/base.py", line 1992, in last_timestamp
2022-12-05T22:21:27.3382344Z [97827]stdout>    raise ABCIAppInternalError("last timestamp is None")
...
2022-12-05T22:21:36.0405091Z Exit Code	Package
2022-12-05T22:21:36.0405240Z 1       	valory/agents/registration_start_up

I'm going to address potential flakiness due to execution time of the tests in a separate PR - discussed with @Adamantios earlier this morning, as there are a couple more things that should be moved and this can be done in concert

test failures

windows 3.9 - addressed in #16252022-12-07T11:04:51.8322370Z E           hypothesis.errors.Flaky: Hypothesis test_fuzz_send_signing_request(self=<packages.valory.skills.abstract_round_abci.tests.test_behaviours_utils.TestBaseBehaviour at 0x1c53e435400>, input_bytes=b'\x0cgr\xaf') produces unreliable results: Falsified on the first call but did not on a subsequent one
2022-12-07T11:04:51.8322983Z
2022-12-07T11:04:51.8323431Z ..\..\..\..\.tox\packages-py3.9-win\lib\site-packages\hypothesis\core.py:886: Flaky
2022-12-07T11:04:51.8324074Z ---------------------------- Captured stdout call -----------------------------
2022-12-07T11:04:51.8324564Z Falsifying example: test_fuzz_send_signing_request(
2022-12-07T11:04:51.8325051Z     input_bytes=b'\x0cgr\xaf',
2022-12-07T11:04:51.8325711Z     self=<packages.valory.skills.abstract_round_abci.tests.test_behaviours_utils.TestBaseBehaviour at 0x1c53e435400>,
2022-12-07T11:04:51.8326149Z )
2022-12-07T11:04:51.8326865Z Unreliable test timings! On an initial run, this test took 255.98ms, which exceeded the deadline of 200.00ms, but on a subsequent run it took 2.22 ms, which did not. If you expect this sort of variability in your test timings, consider turning deadlines off for this test by setting deadline=None.

test_fuzz_send_signing_request failed on windows 3.9 CI run because of a hypothesis "Unreliable test timings", but I believe that stacked #1625 will fix it since it globally sets a deadline of 5000 on CI.

the failure is thusfar incomprehensible to me, as we use an autouse fixture that sets the deadline to 5000ms
2022-12-07T14:43:01.8560072Z Unreliable test timings! On an initial run, this test took 284.36ms, which exceeded the deadline of 200.00ms, but on a subsequent run it took 3.92 ms, which did not. If you expect this sort of variability in your test timings, consider turning deadlines off for this test by setting deadline=None.

whereas we have set the deadline to 5000ms - this is also logged in CI. I have tested it locally and it is indeed the case also in the test.
However, I also noticed the following, which I have not seen before, 28 times over:
2022-12-07T14:50:00.2308720Z /opt/hostedtoolcache/Python/3.9.15/x64/lib/python3.9/asyncio/base_events.py:686: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=False>
2022-12-07T14:50:00.2359170Z sys:1: ResourceWarning: unclosed <socket.socket fd=197, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0, raddr=/run/docker.sock>

this is not seen on ubuntu 3.7 and 3.8 runs here, but also on 3.10 which passes.


Stack trace in console

Version
4.11.2
Description
Even though the playback does not seem to be affected, a stack trace is always being shown in the console when music starts to play:
setPositionState error:  TypeError: Failed to execute 'setPositionState' on 'MediaSession': The provided double value is non-finite.
    at r.updateMediaSessionPositionState (main.5c6ec5e2.js:27)
    at r.updateMediaSessionMetadata (main.5c6ec5e2.js:27)
    at r.onAddMediaSession (main.5c6ec5e2.js:27)
    at r.value (main.5c6ec5e2.js:27)
    at Qi (main.5c6ec5e2.js:27)
    at Gi (main.5c6ec5e2.js:27)
    at Yi (main.5c6ec5e2.js:27)
    at Ki (main.5c6ec5e2.js:27)
    at qi (main.5c6ec5e2.js:27)
    at xi (main.5c6ec5e2.js:27)

Steps to Reproduce
Just go to the demo, http://www.lijinke.cn/react-music-player/, open the browser console and you will see the error.
Expected Behavior
No errors in the browser console

Thanks. done


Bug: error specifying IAM policy

I'm trying to grant a lambda function access to an S3 bucket so the lambda function can cache its result. I tried to hand-code an IAM Policy Document by adding it to the function's initial policy, but unfortunately, I'm getting an error about a missing parameter for aws-cdk-lib.aws_iam.PolicyStatement.fromJson().
decdk version: 2.0.0-pre.194
aws-cdk version: 2.40.0 (build 56ba2ab)
# yaml-language-server: $schema=./decdk.schema.json
# ^ Use the redhat.vscode-yaml extension for vscode to get completion
Resources:

  SvgRasterFunction:
    Type: aws-cdk-lib.aws_lambda.Function
    Properties:
      runtime: PROVIDED_AL2
      handler: NOT_APPLICABLE
      memorySize: 10240
      code:
        fromAsset:
          path: target/x86_64-unknown-linux-musl/release
          exclude:
            - "*"
            - "!bootstrap"
      environment:
        CACHE_BUCKET: { Fn::GetAtt: CacheBucket.bucketName }
      initialPolicy:
      - fromJson:
          Version: 2012-10-17
          Statement:
          - Sid: FirstStatement
            Effect: Allow
            Action:
            - s3:PutObject
            - s3:GetObject
            Resource:
            - { Fn::GetAtt: CacheBucket.arn }
            - { Fn::Join: ["", [{ Fn::GetAtt: CacheBucket.arn }, "/*"]]}

  CacheBucket:
    Type: aws-cdk-lib.aws_s3.Bucket

josh@nyx:~/proj/shards-next/svg-raster$ cdk --app "decdk decdk.yaml" deploy
TypeError: Expected required parameter 'obj' for aws-cdk-lib.aws_iam.PolicyStatement.fromJson

Subprocess exited with error 1

Ah. I figured it out.

@misterjoshua Thanks for coming up with this example. DeCDK should definitely support nested intrinsics. Re-opening so I can keep track of it

Notes to myself:

the need for obj will go away with #265
I've got the example working with Fn:GetAtt, however not with Ref
Ref is used in an unknown type context here and thus should resolve to the CDK intrinsic, not the Construct object

Simplified template for the Ref issue:
{
      Resources: {
        Bucket: {
          Type: 'AWS::S3::Bucket',
          Properties: {
            BucketName: 'my-bucket',
          },
        },
        Topic: {
          Type: 'aws-cdk-lib.aws_sns.Topic',
          Properties: {
            displayName: { 'Ref': Bucket },
          },
        },
      },
    }

@misterjoshua The latest release makes this possible
      - fromJson:
          obj:
            Resource:
            - { Ref: CacheBucket }
            - { Fn::Join: ["", [{ Ref: CacheBucket }, "/*"]] }

@misterjoshua The latest release makes this possible
      - fromJson:
          obj:
            Resource:
            - { Ref: CacheBucket }
            - { Fn::Join: ["", [{ Ref: CacheBucket }, "/*"]] }

Thank you! This will help a ton!


Google Maps Travel Time Docker fails to start

Home Assistant release (hass --version): 0.19.1
Python release (python3 --version): 3.4
Component/platform: sensor/google_travel_time
Description of problem: Fails to start due to SSL error.
Problem-relevant configuration.yaml entries and steps to reproduce:
sensor:
    platform: google_travel_time
    api_key: XXXX_XXXXX_XXXXX
    origin: Trondheim, Norway
    destination: Paris, France
    travel_mode: bicycling

Traceback (if applicable):
 16-05-08 14:06:17 INFO (MainThread) [requests.packages.urllib3.connectionpool] Starting new HTTPS connection (1): maps.googleapis.com
 16-05-08 14:06:17 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform google_travel_time
 Traceback (most recent call last):
   File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 578, in urlopen
     chunked=chunked)
   File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 351, in _make_request
     self._validate_conn(conn)
   File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 814, in _validate_conn
     conn.connect()
   File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connection.py", line 289, in connect
     ssl_version=resolved_ssl_version)
   File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/util/ssl_.py", line 308, in ssl_wrap_socket
     return context.wrap_socket(sock, server_hostname=server_hostname)
   File "/usr/local/lib/python3.4/ssl.py", line 362, in wrap_socket
     _context=self)
   File "/usr/local/lib/python3.4/ssl.py", line 580, in __init__
     self.do_handshake()
   File "/usr/local/lib/python3.4/ssl.py", line 807, in do_handshake
     self._sslobj.do_handshake()
 ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/usr/local/lib/python3.4/site-packages/requests/adapters.py", line 403, in send
     timeout=timeout
   File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 604, in urlopen
     raise SSLError(e)
 requests.packages.urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/usr/local/lib/python3.4/site-packages/googlemaps/client.py", line 201, in _get
     resp = requests.get(base_url + authed_url, **requests_kwargs)
   File "/usr/local/lib/python3.4/site-packages/requests/api.py", line 71, in get
     return request('get', url, params=params, **kwargs)
   File "/usr/local/lib/python3.4/site-packages/requests/api.py", line 57, in request
     return session.request(method=method, url=url, **kwargs)
   File "/usr/local/lib/python3.4/site-packages/requests/sessions.py", line 475, in request
     resp = self.send(prep, **send_kwargs)
   File "/usr/local/lib/python3.4/site-packages/requests/sessions.py", line 585, in send
     r = adapter.send(request, **kwargs)
   File "/usr/local/lib/python3.4/site-packages/requests/adapters.py", line 477, in send
     raise SSLError(e, request=request)
 requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/usr/src/app/homeassistant/helpers/entity_component.py", line 98, in _setup_platform
     discovery_info)
   File "/usr/src/app/homeassistant/components/sensor/google_travel_time.py", line 48, in setup_platform
     travel_mode, is_metric)
   File "/usr/src/app/homeassistant/components/sensor/google_travel_time.py", line 73, in __init__
     self.update()
   File "/usr/src/app/homeassistant/util/__init__.py", line 289, in wrapper
     result = method(*args, **kwargs)
   File "/usr/src/app/homeassistant/components/sensor/google_travel_time.py", line 117, in update
     traffic_model="optimistic")
   File "/usr/local/lib/python3.4/site-packages/googlemaps/distance_matrix.py", line 130, in distance_matrix
     return client._get("/maps/api/distancematrix/json", params)
   File "/usr/local/lib/python3.4/site-packages/googlemaps/client.py", line 205, in _get
     raise googlemaps.exceptions.TransportError(e)
 googlemaps.exceptions.TransportError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)

Are you using docker?
On Sun, May 8, 2016, 07:10 Lewis Juggins<EMAIL_ADDRESS>wrote:

Home Assistant release (hass --version): 0.19.1
Python release (python3 --version): 3.4
Component/platform: sensor/google_travel_time
Description of problem: Fails to start due to SSL error.
Problem-relevant configuration.yaml entries and steps to reproduce:
sensor:
platform: google_travel_time
api_key: XXXX_XXXXX_XXXXX
origin: Trondheim, Norway
destination: Paris, France
travel_mode: bicycling
Traceback (if applicable):
16-05-08 14:06:17 INFO (MainThread) [requests.packages.urllib3.connectionpool] Starting new HTTPS connection (1): maps.googleapis.com
16-05-08 14:06:17 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform google_travel_time
Traceback (most recent call last):
File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 578, in urlopen
chunked=chunked)
File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 351, in _make_request
self._validate_conn(conn)
File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 814, in validate_conn
conn.connect()
File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connection.py", line 289, in connect
ssl_version=resolved_ssl_version)
File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/util/ssl.py", line 308, in ssl_wrap_socket
return context.wrap_socket(sock, server_hostname=server_hostname)
File "/usr/local/lib/python3.4/ssl.py", line 362, in wrap_socket
_context=self)
File "/usr/local/lib/python3.4/ssl.py", line 580, in init
self.do_handshake()
File "/usr/local/lib/python3.4/ssl.py", line 807, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.4/site-packages/requests/adapters.py", line 403, in send
timeout=timeout
File "/usr/local/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 604, in urlopen
raise SSLError(e)
requests.packages.urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.4/site-packages/googlemaps/client.py", line 201, in _get
resp = requests.get(base_url + authed_url, **requests_kwargs)
File "/usr/local/lib/python3.4/site-packages/requests/api.py", line 71, in get
return request('get', url, params=params, **kwargs)
File "/usr/local/lib/python3.4/site-packages/requests/api.py", line 57, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.4/site-packages/requests/sessions.py", line 475, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.4/site-packages/requests/sessions.py", line 585, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.4/site-packages/requests/adapters.py", line 477, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/app/homeassistant/helpers/entity_component.py", line 98, in _setup_platform
discovery_info)
File "/usr/src/app/homeassistant/components/sensor/google_travel_time.py", line 48, in setup_platform
travel_mode, is_metric)
File "/usr/src/app/homeassistant/components/sensor/google_travel_time.py", line 73, in init
self.update()
File "/usr/src/app/homeassistant/util/init.py", line 289, in wrapper
result = method(*args, **kwargs)
File "/usr/src/app/homeassistant/components/sensor/google_travel_time.py", line 117, in update
traffic_model="optimistic")
File "/usr/local/lib/python3.4/site-packages/googlemaps/distance_matrix.py", line 130, in distance_matrix
return client._get("/maps/api/distancematrix/json", params)
File "/usr/local/lib/python3.4/site-packages/googlemaps/client.py", line 205, in _get
raise googlemaps.exceptions.TransportError(e)
googlemaps.exceptions.TransportError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/home-assistant/home-assistant/issues/2009

@balloob I am, yes.

This is an issue with docker / python / requests. I'm not sure about a fix.
On Sun, May 8, 2016, 08:00 Lewis Juggins<EMAIL_ADDRESS>wrote:

@balloob https://github.com/balloob I am, yes.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/home-assistant/home-assistant/issues/2009#issuecomment-217725330

@balloob looks like it's related to this;
https://github.com/certifi/python-certifi/issues/26
Which appears to be due to Jessie being on OpenSSL 1.0.1k, 1.0.2 fixes the issue.
Nasty workarounds;

Pin an old version of certifi==2015.4.28, which contains the weak certs.
Set $REQUESTS_CA_BUNDLE to the old, weak certs.

I've just had a look, and it would appear that Alpine has OpenSSL 1.0.2h in v3.3, I believe that moving to Alpine would be the cleanest solution.
Does the project have any ties to Debian?

No ties - we are now basing our image on the Python 3.4 image provided by Docker.

@balloob Looks like there's a community openzwave package in community;
nmap - Check, https://pkgs.alpinelinux.org/packages?name=nmap
net-tools - Check, https://pkgs.alpinelinux.org/packages?name=net-tools
cython3 - No cython3, but cython 0.23.4 exists https://pkgs.alpinelinux.org/packages?name=cython
libudev-dev - Potentially one of these? https://pkgs.alpinelinux.org/packages?name=udev
sudo - Check, https://pkgs.alpinelinux.org/packages?name=sudo
libglib2.0-dev - Potentially one of these? https://pkgs.alpinelinux.org/packages?name=glib
I'm not sure if all those packages are still required if using https://pkgs.alpinelinux.org/packages?name=openzwave - I'm unfamilar with zwave, or its requirements.
Rest looks to be relatively straight forward, potentially quite an easy transition (and a smaller image!).

I wonder if it wouldn't be easier to either uninstall certifi (means older certificates) or install OpenSSL 1.0.2 inside Docker.


Upgrades to Webpack 2

Hi!
I've been using relay-starter-kit for a while now, just to tinker about with how GraphQL and Relay works. I thought I'd migrate over one of the changes that I'd made locally. This change upgrades the version of Webpack to version 2, alongside extracting the configuration to its conventional location.

Thanks. Looks reasonable to me. I'm going to apply a couple of tiny tweaks on top of this and test it out.

Ok, tested this out with npm install, npm run update-schema, npm run start. Everything seems to be working fine, so going to merge. Thanks once again @sh1989.


🚀 [Feature Request]: Support Frontline Service Plan

Contact Details
PSCloudPC
Feature
No
Feature Description
Support the new cloudPcFrontLineServicePlan resource type.

Property
Type
Description

displayName
String
The display name of the front-line service plan. For example, 2vCPU/8GB/128GB Front-line or 4vCPU/16GB/256GB Front-line.

id
String
The unique identifier (ID) of the front-line service plan.

totalCount
Int32
The total number of front-line service plans purchased by the customer.

usedCount
Int32
The number of service plans that have been used for the account.

Feature Output
Get-CPCFrontLineServicePlan
Possible implementation
No response

This feature should be renamed. It is already possible to find the SKUs but the assigned licenses should also work for the regular service plans.

Get-CPCServicePlan Already supports this feature:


View list of students with incomplete tasks

User Story
As a user I can view a list of students who have incomplete tasks so that I can easily find out which students have tasks which are overdue.

This is good to have, but not crucial to our app. Closing due to lack of time to implement.


[BEAM-10961] enable strict dependency checking for sdks/java/extensions/euphoria

Split from #13686
R: @ibzib

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java_Examples_Dataflow_Java11

Run Java_Examples_Dataflow_Java11 PreCommit


Update fabricbot.json

Details
changing PM user for task "Reassign to PM when a user adds "status: ready for triage" tag

:tada: This PR is included in version 2.10.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add PreferHostingUrls to WebHostBuilder and IServerAddressesFeature

#968
Let's see if we like this naming.

cc @glennc @DamianEdwards for naming approval.

@JunTaoLuo can you share samples of what users code might look like?

I'm not sure PreferHostingUrls makes it clear what the user is configuring.
That said, naming is hard. Been thinking about this and can't come up w/ anything better. And PreferConfigurationFromIWebHostBuilderOverIServer is certainly not good.

What would you like to see in a sample? I would imagine the default would look like the following
public static void Main(string[] args)
{
    var host = new WebHostBuilder()
        .PreferHostingUrls(true)
        .UseKestrel(options => options.Listen(IPAddress.Loopback, 5001))
        .UseContentRoot(Directory.GetCurrentDirectory())
        .useStartup<Startup>()
        .Build();

    host.Run();
}

This way, http://localhost:5001 configured on the server is used if no address is configured by the environment variable. However, if ASPNETCORE_URLS is set, then that will override the default configured on Kestrel (once the changes in Kestrel are made).

@natemcmaster @JunTaoLuo How about PreferWebHostBuilderUrls?

@natemcmaster @JunTaoLuo How about PreferWebHostBuilderUrls?

Downvotes are so passive aggressive. So here's some text describing the downvote.

Well, I tried :P

:shipit:


Build error

Hey,
I'm having some trouble running make and can't seem to find a solution.
It eventually outputs the following error message:
(though I do end up with a ./krml...)
ocamlbuild -I src -I lib -I parser -I kremlib -use-menhir -use-ocamlfind -classic-display -menhir "menhir --infer --explain" Kremlin.native
ln -sf Kremlin.native krml
make -C kremlib
make[1]: Entering directory '/home/jlamma/fstar/kremlin/kremlib'
/home/jlamma/fstar/FStar/bin/fstar.exe --record_hints --use_hints --use_two_phase_tc true --odir .extract --warn_error @332 --cache_checked_modules --cache_dir obj --hint_dir hints --include ../runtime --cmi --already_cached 'Prims FStar -FStar.Kremlin.Endianness LowStar -LowStar.Lib'  --dep full C.Endianness.fst C.Failure.fst C.fst C.Loops.fst C.String.fst FStar.Kremlin.Endianness.fst LowStar.Lib.AssocList.fst LowStar.Lib.LinkedList2.fst LowStar.Lib.LinkedList.fst Spec.Loops.fst C.String.fsti LowStar.Lib.AssocList.fsti TestLib.fsti ../runtime/WasmSupport.fst FStar.UInt128.fst FStar.Date.fsti FStar.HyperStack.IO.fst FStar.IO.fst FStar.Int.Cast.Full.fst FStar.Bytes.fsti FStar.Dyn.fsti LowStar.Printf.fst LowStar.Endianness.fst > .depend
(Error 317) Expected FStar.Reflection.Types to be already checked but could not find it
1 error was reported (see above)
make[1]: *** [Makefile:58: .depend] Error 1
make[1]: Leaving directory '/home/jlamma/fstar/kremlin/kremlib'
make: *** [Makefile:28: kremlib] Error 2

I saw there were some issues with newer versions of OCaml, but this happened even with 4.06.0.

kremlin assumes that you've run a full build of F* before in $FSTAR_HOME ... can you run make from F*'s toplevel directory?

Thank you so much, that fixed it!
I had only run the following commands from F*'s INSTALL.md:
make 1 -j6
make libs -j6

is INSTALL.md out of date? maybe you can submit a PR there to fix it? pinging @mtzguido who talked about "make libs" just this morning

Ah, indeed INSTALL.md is wrong: make libs only builds the binary objects for fstarlib/fstartaclib, it doesn't verify the library nor generate its .checked files, which Kremlin requires. Thanks for the heads up!


Creating a gas chanel crashed the game

I'm now here at GitHub, so I don't know whice parts of the crash report i should attach here. Here's the whole thing:
crash-2020-12-06_16.32.37-server.txt
Gas tank did not show up in the xnet controller and crating a gas chanel craashed the game.
I used version: XNetGases-1.16.4-2.1.0. as can be seen in the crash report.
I'm not sure if it's the xnet  or xnet gases that caused the crash.

Looks like XNet got an update and something has changed in the API. I'll update it in a few mins.

The 1.15 version of XNet also received an update to its API. Will you also be updating the 1.15 version of this mod?

Ah, will do. Gonna port the slurry channel while I'm at it.

Awesome, thanks so much it is appreciated!

Alright, should be up on CurseForge now. Slurries already worked but it is not possible to extract them directly from machines. It is not behaving like it should, which is most likely a fault in mekanism itself. Going around that issue would take too much work, so just extract from gas tanks instead of directly from machines in case of slurries.


bring 2.x up to date with recent 1.x work

PR #20 was one proposal along these lines, but I think
a) there were concerns with approach, and
b) there may have been additional updates since then

Closed by #47, which provides a way forward based off the v1.x branch and abandons the 2.x line.


Support for .razor, .scss, css

Hi, really cool extension.  I love it.  What LOE would it be to add support for .razor, .scss and .css files?

Thanks for the nice words!
Collecting some links here while investigating how to add the extra languages:
https://github.com/TylerBrinks/ExCSS

Thanks for the nice words!
Collecting some links here while investigating how to add the extra languages:
https://github.com/TylerBrinks/ExCSS

Thank you so much.  I'm writing a massive platform in Blazor and use .razor, .scss, and .css all day every day.  Support for those extension types would make my life so much easier!  Keep up the good work.  I'm using it right now for all of my .cs files!

Grab the new release for CSS support 🚀 !


Refactor WorkflowGroup API to conform to new design

We want to refactor the WorkflowGroup API to address compatibility issues with Micronaut and Quarkus arising from the library's reliance on Spring framework.
We would like to have the Events API migrated to the new REST dependency and ensure the on going updates to the unit tests to validate the modifications and uphold code quality.
For guidance on the expected changes, kindly refer to this pull request #54.

Sure

@sharmaudit124 there seems to be no traction on this issue. Are you still working on it?

@sccalabr are you available to pick this up ASAP?


scala-native

Any guesses on the build failure?

Codecov Report

Merging #713 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #713   +/-   ##
=======================================
  Coverage   86.79%   86.79%
=======================================
  Files          87       87
  Lines        2492     2492
  Branches       60       60
=======================================
  Hits         2163     2163
  Misses        329      329

Impacted Files
Coverage Δ

core/src/main/scala/shapeless/generic.scala
0% <0%> (ø)
:arrow_up:

core/src/test/scala/shapeless/generic.scala
83.69% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a285b6c...29c129a. Read the comment docs.

Build is green now

What was the problem?
Anyhow, LGTM ... many thanks ... merging! :-)


Add optional inputmode attr

What's this PR do?
Adds an inputmode prop to our  component to render that attribute on text fields where the prop is passed.
Why are we doing this? How does it help us?
inputmode is a tiny UX enhancement for supported touch devices. Designating the inputmode sets the appropriate touch keyboard for a user and saves them from having to toggle to the correct character set when filling out our forms.
Inspired by this CSS Tricks blog post

Unlike changing the type of the form, inputmode doesn’t change the way the browser interprets the input — it instructs the browser which keyboard to display.

How should this be manually tested?
Spin up locally and ensure the following:

All Zip code fields: inputmode="numeric"

All email fields: inputmode="email" (I think type="email" already provides the correct keyboard, so this one isn't completely necessary, but I figure can't hurt)

All url fields: inputmode=url

Donation amount field on /donate: inputmode="decimal" I didn't use numeric here because I'm assuming our form validation doesn't accept anything but numbers and decimals. This forces a number + decimal pad disallowing changing to letters, punctuation, etc. I feel fine about this since it matches the validation rules, but open to discuss.

All remaining fields don't have the inputmode attribute at all.  (This is why you see default=null in the prop type definition. If there's a better way to force the attr to not show, let me know.)

Try it out on device and click around the form with this link: https://donations-testing-pr-208.herokuapp.com/donate
How should this change be communicated to end users?
N/A
Are there any smells or added technical debt to note?
Shouldn't be.
What are the relevant tickets?
https://3.basecamp.com/3098728/buckets/736178/todos/1803780167
Have you done the following, if applicable:
(optional: add explanation between parentheses)

[ ] Added automated tests? ( )
[x] Tested manually on mobile? ( )
[x] Checked for performance implications? ( )
[ ] Checked for security implications? ( )
[ ] Updated the documentation/wiki? ( )

FWIW, looks like ds-toolbox-test is in yarn.lock twice on this branch. I noticed because when I did a fresh yarn, it tried to remove the one from #master.

Is there a chance that's some quirk that might be happening in your local env? I'd think if anything were specific to this branch, I'd see a code change in yarn.lock and it listed as a file here:

But maybe I somehow snuck it in another way that I wouldn't see in git? I'm confused :sadtodd:

@ashley-hebler Yeah, maybe it has been this way for a little while. Here's where I see it.

I see I see, you removed the dupe here and I haven't rebased since then. I'll force push just to be safe, but I don't think that would have added an extra instance.


Added: Check engines version

Close #707

Cool! Just look at my idea to test the entire code.

PR Updated

PR updated

Except my last comment this lgtm!

You could also add a note in the CHANGELOG ;)

I pushed required changes.


practical guide to add "legacy data"

Moving your legacy data into an ARC - a practical guide.

Create an (empty) ARC
dump what you have into an "additional payload" folder archive inside the ARC

git controlled
git LFSed

Move files from there (to "proper" places in the ARC)

FilesShare / Server to HUB

Rsync
file integrity (md5, sha, etc.)
...

git LFS - Move pointers, not files

tried, didn't work, need to test again

how to handle raw data already submitted to public repositories?

download and add?
add list of links / PIDs from that repo?
build a (CWL) workflow and / or CI/CD to check links to orig. files?

Is there a size limit for data in ARCs?
How to integrate scripts?

CWL unrealistic for all
add as assays?
still add as workflows?

How to reference (external) data used for analysis?
How to cite / acknowledge use of DataPLANT tools & services

adapted from discussion with @shiltemann

Will close for now.
Most parts of this are now described to different extents.
I've created a draft article on this branch: https://github.com/nfdi4plants/nfdi4plants.knowledgebase/tree/legacy-data-guide


Add a workaround with the range constraint warning.

This can help future people who encounter the warning and didn't consider the simple workaround @IainNZ presented in #14.


bot stuck after starting web server

I got my bot working, and i can look at it online going to localhost:8000 on my computer, but the bot wont start after the web server is up and running
it goes
`--------------------Starting bot--------------------
2016-09-29 21:10:50,559 [       cli] [INFO] PokemonGO Bot v1.0
2016-09-29 21:10:50,572 [       cli] [INFO] commit: unknown
2016-09-29 21:10:50,573 [       cli] [INFO] No auth argument specified, checking for C:\Users\chris\Documents\Git\PokemonGo-Bot\pokemongo_bot..\configs\auth.json
2016-09-29 21:10:50,575 [       cli] [INFO] No config argument specified, checking for C:\Users\chris\Documents\Git\PokemonGo-Bot\pokemongo_bot..\configs\config.json
2016-09-29 21:10:50,582 [       cli] [INFO] Configuration initialized
2016-09-29 21:10:50,584 [pokemongo_bot.health_record.bot_event] [INFO] Health check is enabled.

I got my bot working, and i can look at it online going to localhost:8000 on my computer
so everything works even online from outside the LAN?

but the bot wont start after the web server is up and running
so then start the bot and afterwards the web server.

and just gets stuck there, while the python server is running and doing everything.
what is the output if the web-server is not running?
What is the setting of websocket_server in your config?

(11160) wsgi starting up on http://<IP_ADDRESS>:4000
is the port correct?

I had the same issue, I think.
Changed the last line in my config to this: 		"server_url": "localhost:4000"
Now everything is working

that helped, but i realized my main problem was because in the "userdata.js" (im running multiple bots) I did "user@domain, user2@domain"
what i fixed was "user@domain", "user2@domain"


feat: add guid to each objects metadata on export

needed by https://github.com/area28technologies/io.area28.unity/pull/44

There seems to be a cleaner way to do this that I missed 😅, tried it and it works well
https://github.com/atteneder/glTFast/blob/main/Documentation~/ExportRuntime.md


501 server error: after installed PhantomJS, i run "pyspider all" in linux, then i visit web url and run the handler, but it raise error, what does it mean?

Handler is as below:
class Handler(BaseHandler):
def on_start(self):
    self.crawl('http://www.baidu.com', fetch_type='js', callback=self.index_page)

def index_page(self, response):
    return {
        "url": response.url
    }

Output is as below:
[E 150430 11:21:55 base_handler:192] 501 Server Error
Traceback (most recent call last):
File "/home/op1/installs/env/lib/python2.7/site-packages/pyspider-0.3.4-py2.7.egg/pyspider/libs/base_handler.py", line 185, in run_task
result = self._run_task(task, response)
File "/home/op1/installs/env/lib/python2.7/site-packages/pyspider-0.3.4-py2.7.egg/pyspider/libs/base_handler.py", line 168, in _run_task
response.raise_for_status()
File "/home/op1/installs/env/lib/python2.7/site-packages/pyspider-0.3.4-py2.7.egg/pyspider/libs/response.py", line 183, in raise_for_status
raise http_error
HTTPError: 501 Server Error

fixed with 3983b54987e1525ed92385b6541b664bbc52e7c7

really appreciate your quick reply, it really helps a lot, thank you!!!


Copy XPath of selected node

Dear all,
first of all thank you for this editor.
I use it mainly for viewing large XML files (up to 300MB) and checking / searching content within specific nodes / XPaths.
XMLNotepad already offers a feature to search within an XPath (Find > "Use XPath").
As a user searching a lot within specific XPaths, I would like to be able to copy the XPath of nodes from the tree view and/or start a search within this specific node from the context menu of the tree view, to minimize the waiting time and get more specific results.
At the moment, I know only of Notepad++ with the "XML Tools"-Plugin, that has this ability: https://stackoverflow.com/questions/3148217/how-to-get-the-xpath-of-a-certain-node-when-viewing-an-xml-file-in-visual-studio
Edit: I am aware, that the XPath of the selected node gets pre-populated in the search field, when enabling the tick-box at "Use XPath". This is a bit cumbersome, though, because XMLNotepad freezes for several minutes after ticking this box (given large filesizes).
Kind regards,
LeMapper

Does the "Copy XPath" command work? It should copy the XPath expression that locates the selected node in the tree view to your clipboard.

Hopefully Copy XPath does the trick.


njit(parallel=True) causes lost of array changes when array is passed in for both input&output purposes

numba version:

0.34.0              np113py36_0  defaults

code
from numba import jit, njit
import numpy as np

@njit(parallel=True)
def test7(a):
    length = a.size
    for i in range(length):
        test8(i, a)
    return a

@njit(parallel=True)
def test8(i, a):
    if i>4:
        a[i] = i
    # print(a[i])  # comment or uncomment this line with have different output
    return 0

a = np.zeros(8, dtype=np.float64)
output = test7(a)
print(output)

comment print(a[i]) will output:

[ 0.  0.  0.  0.  0.  0.  0.  0.]

uncomment print(a[i]) will output:

[ 0.  0.  0.  0.  0.  5.  6.  7.]

I think print statement shouldn't alter the output in such a way

The array changes issue is already fixed in master branch. But I get an error when the print is enabled: RuntimeError: missing Environment.
This might be related to the runtime environment issue with prints @sklam

Closing since the array problem was fixed and the printing issue is being tracked in #2411.


'dashing-devel' branch to the default branch

Hello, @joonr7 .
It would be better if you replace the default branch from master branch to  dashing-devel branch.
I think merging dashing-devel into the master branch is also a good way, if you will not create any branches.
Thanks.

Thanks harderthan sensei


Suggestion for Dependent-Type-Like Functions: Conservative Narrowing of Generic Indexed Access Result Type

Search Terms
generic indexed access type dependent function
generic narrowing
Suggestion
TypeScript does not provide dependent types, but by combining various features such as unions, literal types and indexed access types we can obtain fairly similar behaviour to a dependent function from the caller point of view. Unfortunately, the implementer of such functions is faced with either the possibility of creating unsoundness (pre 3.5) or forced to assert the return type with unsound features (post 3.5). There are some differences with typical dependent functions, which is why we call these dependent-type-like functions.
This suggestion proposes an addition to the typechecking part of TypeScript, which aids the programmer in writing dependent-type-like functions. The main attractive point of this suggestion is that it does not introduce any additional syntax, and is meant to be a conservative extension. Thus it is not a breaking change with regards to the changes introduced in 3.5, but it does enable certain sound scenarios to typecheck.
Use Case
The main use case is dependent-type-like functions, the depLikeFun example is a minimalistic scenario showcasing such a situation. In this example, we have the depLikeFun function which returns number when its input is of type "t" and boolean when its input is of type "f".
interface F {
  "t": number,
  "f": boolean,
}

function depLikeFun<T extends "t" | "f">(str: T): F[T] {
  if (str === "t") {
    return 1;
  } else {
    return true;
  }
}

depLikeFun("t"); // has type number
depLikeFun("f"); // has type boolean

This pattern occurs in various places, such as the TypeScript dom bindings, in issues such as #31672 and #32698, in comments of related issues such as #13995, or on stackoverflow questions. This extension could serve as a workaround for related issues such as #22609 and #23861.
Problem
The problem lies in the implementation of the function. The pre-3.5 behaviour enabled the creation of unsoundness in these type of functions. TypeScript checked the return value using the constraint of key type T, simplifying F[T] to number | boolean. However, this is unsound since the caller can provide a more specific type for T such as "t".
// pre-3.5
function depLikeFun<T extends "t" | "f">(str: T): F[T] {
  if (str === "t") {
    return true; // should be error
  } else {
    return 1; // should be error
  }
}

depLikeFun("t"); // has type number, but is actually a boolean
depLikeFun("f"); // has type boolean, but is actually a number

The post-3.5 behaviour also isn't satisfactory for this use case. It disallows the depLikeFun to be implemented, which means the implementer needs to use unsafe type assertions. By #30769, assigning to type F[T] is interpreted as a write to F at key T. This means that the result type F[T] is checked against the intersection of its possibilities, which is number & boolean and thus never.
// post-3.5
function depLikeFun<T extends "t" | "f">(str: T): F[T] {
  if (str === "t") {
    return 1; // unexpected error: '1' is not assignable to never
  } else {
    return true; // unexpected error: 'true' is not assignable to never
  }
}

Mistakes are more likely to occur in complex situations, and thus aiding the user with these types of functions seems in line with TypeScript's design goals.
Examples
In a dependently typed language depLikeFun would be modeled as function depFun(str: "t" | "f"): F[str]. There are meaningful differences between depending on the actual value of the input versus the type of an input. This distinction makes this issue more tricky to solve than appears on first sight. In this section we showcase the expected behaviour of the addition on certain representative examples.
The main idea behind the addition is as follows: in a dependent-type-like function we cannot narrow the type T of a variable when its value is checked. For example, if str has type T extends "t" | "f" and we check whether str === "t", then it is unsafe to narrow T to "t" in that branch, since T could also be instantiated with the wider type "t" | "f". Instead, we add knowledge about the type T within the branch which is more conservative, but makes it possible to allow the behaviour of dependent-type-like functions. In more traditional programming language theory, the knowledge added is very similar to adding a lower bound "t" <: T into the context.
Basic Use Case
First we look at the depLikeFun example. In the if-branch, returning 1 is allowed since after checking str === "t" the type of T can only be "t" or "t" | "f". Thus, the caller will expect either a number or number | boolean, and thus it is safe to return the value 1.
Note: The claim above that T can only be "t" or "t" | "f" is not quite true due to branded types. For example, T could also be the type Branded, defined as type Branded = "t" & {_branded?: any}. In this case the caller expects a value of type unknown, so returning 1 is also safe.
function depLikeFun<T extends "t" | "f">(str: T): F[T] {
  if (str === "t") {
    return 1; // no error
  } else {
    return true; // no error
  }
}

An example which does not occur for dependent functions, but does occur in dependent-type-like functions, is the following. The type T can be attributed to multiple inputs, this possibility is what makes it unsafe to fully narrow the type parameter based on a check of the input str. However, the reasoning above still holds since the added knowledge is true regardless of how many inputs T is linked to.
function depLikeFun<T extends "t" | "f">(str: T, str2: T): F[T] {
  if (str === "t") {
    return 1; // no error
  } else {
    return true; // no error
  }
}

The extension is conservative, and behaviour of other cases should be the same as in 3.5. However, what might change is the error message users see when implementing dependent-type-like functions. In the situation below, instead of comparing true / 1 to never, they get compared against the simplified indexed access type within each branch. This is number in the then branch and boolean in the else branch.
function depLikeFun<T extends "t" | "f">(str: T): F[T] {
  if (str === "t") {
    return true; // Type 'true' is not assignable to type 'number'
  } else {
    return 1; // Type '1' is not assignable to type 'boolean'
  }
}

Non-Return Indexed Access
The type F[T] can occur elsewhere in the function. This extension retains the normal TypeScript behaviour in those cases, and is only enabled when checking the return type of a function. In the following example we have a value of type F[T] as second input to the function. Within the then branch, this type should not be simplified to number, since it can actually be of type boolean. Checking the first input value does not give us any information regarding the second input value, and thus we cannot do any more simplification.
function depLikeFun<T extends "t" | "f">(str: T, ft: F[T]): F[T] {
  if (str === "t") {
    const n: number = ft; // Type 'F[T]' is not assignable to type 'number'.
    return 1;
  } else {
    return true;
  }
}

let x: boolean = false;
depLikeFun<"t" | "f">("t", x); // ft can be of type 'boolean'

Transitive Type Parameters
TypeScript allows an indexed access with a type parameter which has a direct transitive line to a correct bound. For example, it allows function depLikeFun<T extends "t" | "f", B extends T>(str: B): F[B], but disallows function depLikeFun<T extends "t", F extends "f", B extends T | F>(str: B): F[B].
In these situation it seems safe to let information flow through the transitive chain in both directions. For example, when checking an input of type B, we can add knowledge about T. And vice versa for checking an input of type T and an input of type B.
function depLikeFun<T extends "f" | "t", B extends T>(str: B): F[T] {
  if (str === "t") {
    return true; // no error
  } else {
    return 1; // no error
  }
}

function depLikeFun<T extends "f" | "t", B extends T>(str: T): F[B] {
  if (str === "t") {
    return true; // no error
  } else {
    return 1; // no error
  }
}

Consistency with Conditional Types
TypeScript provides alternative means of creating type-level functions by using conditional types. Instead of creating the record type F, we can create the type constructor F which provides a similar mapping.
type F<A extends "t" | "f"> =
  A extends "t" ? number :
  A extends "f" ? boolean :
  never;

Which can be used as seen below.
function depLikeFun<T extends "t" | "f">(str: T): F<T> {
  if (str === "t") {
    return true;
  } else {
    return 1;
  }
}

This raises the question whether the addition of typechecking for dependent-type-like functions should be added for type level functions created with conditional types too, for consistency purposes. Two points worth noting is that: users were never able to implement this behaviour using conditional types (even pre-3.5), and, type level functions with conditional types are not restricted to a domain of string keys which makes things more complex. Nevertheless, we feel it is a point worth bringing up for discussion.
Behaviour with any
The result of instantiating a dependent-type-like function with the any type gives a result of any. This occurs, for example, when disabling --strictNullChecks and calling the function with null. Any behaviour related to interaction with null/any and dependent-type-like functions is supposed to be unchanged compared to 3.5.
Compiler Changes
In this section we roughly outline the suspected changes to the compiler needed to implement this extension.

The main change is an addition to the checkReturnStatement (checker.ts) function. When the criteria for enabling dependent-type-like function checking are true, we instantiate the type parameter based on a lookup of checks with literals in the control flow graph. These criteria are currently: the index type is a type parameter, this type parameter is declared in the enclosing function, the index type can be used to index the object type and the object type is concrete.
To be able to check the control flow graph in return statements, the graph for return statements needs to be bound in the bindWorker function (binder.ts).

Workaround
The current suggested workaround seems to be unsafe type assertions or overloaded signatures, both of which are unsafe features. Neither are satisfactory since the typechecker does not help in preventing programmer mistakes when implementing dependent-type-like functions.
Related Suggestions
The following list gathers related suggestions.

extending the TypeScript syntax, such as a oneof generic constraint: #25879, #27808 or #30284
dependent types in TypeScript, which would have a huge impact on the compiler and is possibly out of scope for the TypeScript project
this extension is a more refined idea based on previous ideas of narrowing types based on term-level checks such as #21879

Complementary to oneof constraints
This proposal has some overlapping use cases with proposals which propose to extend TypeScript with a form of oneof generic constraint, as mentioned in point 1. This proposal is not competing with these, but rather should be seen as complementary. The oneof proposals suggest a new generic constraint which is more restrictive in which instantiations it allows. However, for many of these use cases this is only part of the solution. In addition to adding this syntax, the typechecker must also take this restriction into account to typecheck the original use cases. This proposal kickstarts the implementation of this additional behaviour by focusing on a more constrained use case which does not need this new constraint. If a oneof generic constraint is added to TypeScript, the behaviour defined in this proposal can be extended to take this additional constraint into account.
Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

NOTE: (Regarding bullet point 1) The goal of this proposal is to provide more complete typechecking than 3.5, and thus we want to avoid breaking any code compared to 3.5.

@ahejlsberg this is a co-effort with @jack-williams that looks very promising. Thoughts?

Silly question but,
Will this also narrow T to "t" and "f"?
What about the more generalized narrowing of T from an arbitrary discriminated union type?

@AnyhowStep
Narrowing the type parameter T to "t" or "f" is unsound.
Consider this situation:
function f<T extends "t" | "f">(x: T, y: T) {
    if (x === 't') {
        y // has type "t", but can possibly be inhabited by "f"
    }
}

@rubenpieters

In more traditional programming language theory, the knowledge added is very similar to adding a lower bound "t" <: T into the context.

According to what @jack-williams told me in another issue, it's not necessarily sound to narrow to T super "t" in this case either (and you seem to acknowledge as much by saying "very similar"): can you give me an example of when lower-bounding wouldn't be sound?

My bad . I meant narrow x. Sorry!

@fatcerberus
It is similar to lower bounds, in that the bound is applicable only in a very limited scope: the indexed access type of a function return type.
Adding a lower bound into the context can be problematic in scenarios similar as described in the Non-Return Indexed Access section. But this is dependent on the rules of how the simplification of indexed access works. So possibly for TypeScript there wouldn't be an issue.
Adding the general form of lower bounds seem more complicated without enabling interesting use cases, compared to keeping the bounds limited in checking the return statement.
@AnyhowStep
That seems ok on first sight. But I'm not sure if this should be part of this proposal.

It's probably better not to think of these as 'true' lower-bounds on the type, rather a lower bound on the type's behaviour as a set of keys.
When we see str === "t", we don't know that T is lower-bounded by "t", but we do know that the set of keys denoted by T include "t". It's a weaker statement but sufficient for refining indexed access types because they only care about T as a set of keys.
@AnyhowStep
Narrowing x would be sound but comes with additional technical challenges and it doesn't help us assign a value to F[T] (unless we are returning something like f[x]).

When we see str === "t", we don't know that T is lower-bounded by "t"

Don’t you, though?  I mean, yes, you can manually instantiate the generic using an unrelated type and then cast, but that’s already unsound in so many other ways that I don’t think we need to account for it at that point.
If there’s a case I’m missing where full lower-bounding would make a valid instantiation unsound, please enlighten me, I’m all ears! 👂

@fatcerberus
I don't think lower bounds by themselves create unsoundness. The problem arises when creating interaction between lower bounds and the indexed access simplification.
For example, imagine we add the lower bound "t" <: T in the if-branch. This is ok by itself, but does not let us typecheck the return-statement. For this to work we need to add a rule which allows us, given a lower bound "t" <: T and F[T] then F[T] simplifies to number. However, this is problematic as the type of the variable ft also gets simplified, which is unsound. So, having the interaction between a lower bound and indexed access simplification be applicable everywhere creates unsoundness.
function depLikeFun<T extends "t" | "f">(str: T, ft: F[T]): F[T] {
  if (str === "t") {
    const n: number = ft; // ft would be simplified to `number`, but can be `boolean`
    return 1;
  } else {
    return true;
  }
}

let x: boolean = false;
depLikeFun<"t" | "f">("t", x); // ft can be of type 'boolean'

I think for the initial proposal we would only look at invoking narrowing for specific forms of return type, but ideally we would be more liberal and handle cases like:
const enum Flags {
    On,
    Off
}

interface FlagLights {
    [Flags.On]: 'green';
    [Flags.Off]: 'red';
}

interface FlagText {
    [Flags.On]: 'on';
    [Flags.Off]: 'off';
}

function getToggleProps<T extends Flags>(flag: T): { colour: FlagLights[T]; text: FlagText[T] } {
  switch (flag) {
    case Flags.On:
      return { colour: 'green', text: 'on'};
    case Flags.Off:
      return { colour: 'red', text: 'off'};
  }
}

Indeed. If we do want to handle narrowing of generic indexed access inside a structure, we do have to take care to only handle the positive positions. Otherwise we get the same problem as I mentioned above.
function depLikeFun<T extends "t" | "f">(str: T): (ft: F[T]) => F[T] {
  if (str === "t") {
    return (ft: number) => { // should be rejected
        return 1;
    };
  } else {
    return (ft: F[T]) => {
        return true;
    };
  }
}

depLikeFun<"t" | "f">("t")(true); // ft can be `boolean`
``

After experimenting more with this, I feel that limiting the implementation to the checkReturnStatement is something that will be too brittle to work for more complex cases. For example, the type of use case @jack-williams pointed where the indexed access is nested inside the return type.
Therefore, I suggest to focus the implementation inside the getSimplifiedIndexedAccessType function instead. On first sight this might bring along some problematic interactions, but I think there are proper solutions for them.
Let's focus on this function which gathers the essence of these interactions:
function f<T extends "t" | "f">(
    t: T,
    t2: T, // second key which we do not test
    ft: F[T], // a value of type F[T]
    f: F, // a record of type F
) {
    if (t === "t") {
        const n: number = ft; // a) should be rejected, ft can be bool
        f[t2] = 1; // b) should be rejected, f[t2] can be bool
        return 1; // c) should be accepted
    }
    throw "";
}

This use case shows three scenarios, two of which should be rejected and one which should be accepted. Scenario A showcases that the variance is important when doing the simplification for this proposal, this information is already part of the getSimplifiedIndexedAccessType function which we can reuse. Scenario B is a bit more problematic, but it is possible to resolve this problem using something like #33089 , which assigns a specific write indexed access type to the lhs of the expression f[t2] = 1]. Scenario C is the normal operation of the extension, and since the implementation is located in the getSimplifiedIndexedAccessType it naturally extends towards checking indexed access inside nested structures as well.
Any thoughts / comments are welcome.

Function overloading provides a functional workaround.
Since depLikeFun return type is dependent of its parameters type, the function type can be:
{
    (str: "t"): number;
    (str: "f"): boolean;
}

And it can be safely defined this way:
type K = string | number | symbol;
const keyIs = <k extends K, C, T extends { [i in k]: unknown; }, V extends { [i in k]: C; }>(
  args: T | V, k: k, c: C): args is V => args[k] === c;

function depLikeFun(str: "t"): F["t"];
function depLikeFun(str: "f"): F["f"];
function depLikeFun(...args: ["t"] | ["f"]) {
  if (keyIs(args, 0, 't' as const)) {
    return 1 as number;
  } else {
    return true as boolean;
  }
}
const myNumber = depLikeFun('t'), myBoolean = depLikeFun('f');

@miginmrs This is covered in the Workaround section.
As far as I can see, your workaround is unsafe as mentioned. The compiler does not prevent incorrect implementations of depLikeFun. If we swap the 1 and boolean return values in your example, the compiler does not prevent it. Playground link.

@rubenpieters Thank you for the note, I didn't notice this before.
By the way, I am still thinking for a workaround by the time the feature is implemented, it could be ugly, but this is the best I could:
type depLikeFun<arg, T> = typeof depLikeFun extends { (x: arg): T; } ? T : never;
function depLikeFun(str: "t"): F["t"];
function depLikeFun(str: "f"): F["f"];
function depLikeFun(str: "t" | "f") {
  if (str === 't') {
    const ret: depLikeFun<typeof str, number> = 1;
    return ret;
  } else {
    const ret: depLikeFun<typeof str, boolean> = true as boolean;
    return ret;
  }
}
const myNumber = depLikeFun('t'), myBoolean = depLikeFun('f');

@miginmrs Actually, I think you can simplify your depLikeFun type with just F[typeof str]. Then it becomes this:
function depLikeFun(str: "t"): F["t"];
function depLikeFun(str: "f"): F["f"];
function depLikeFun(str: "t" | "f") {
  if (str === "t") {
    const ret: F[typeof str] = 1;
    return ret;
  } else {
    const ret: F[typeof str] = true as boolean;
    return ret;
  }
}

It requires the discipline of annotating the return type with this expression to prevent mistakes, but is the neatest workaround I've seen so far.

Code
in this case
Type Guards can work by isKnownLifecycleKey
but Type Guards can't work by in
export declare const lifecycleMap: {
    install: {
        readonly name: "install";
        readonly before: readonly ["preinstall"];
        readonly after: readonly ["postinstall", "prepublish", "prepare", "preshrinkwrap", "shrinkwrap", "postshrinkwrap"];
    };
    pack: {
        readonly name: "pack";
        readonly ignoreSelf: true;
        readonly before: readonly ["prepublish", "prepare", "prepack"];
        readonly after: readonly ["postpack"];
    };
    publish: {
        readonly name: "publish";
        readonly before: readonly ["prepublish", "prepare", "prepublishOnly", "prepack", "postpack"];
        readonly after: readonly ["postpublish"];
    };
};

export interface ILifecycleEntry
{
	readonly name: string;
	readonly ignoreSelf?: boolean;
	readonly before: readonly string[];
	readonly after: readonly string[];
}

export type ILifecycleMapKeys = keyof typeof lifecycleMap;

export type ILifecycleMap<K extends string = string> = typeof lifecycleMap & Record<string, ILifecycleEntry>;

export function getLifecycle1<K extends ILifecycleMapKeys>(scriptName: string | K)
{
	if (isKnownLifecycleKey(scriptName))
	{
		return lifecycleMap[scriptName]
	}

	return (lifecycleMap as ILifecycleMap)[scriptName]
}

export function getLifecycle2<K extends ILifecycleMapKeys>(scriptName: string | K)
{

	if (scriptName in lifecycleMap)
	{
		return lifecycleMap[scriptName]
	}

	return (lifecycleMap as ILifecycleMap)[scriptName]
}

function isKnownLifecycleKey<K extends ILifecycleMapKeys>(scriptName: string | K): scriptName is ILifecycleMapKeys
{
	return scriptName in lifecycleMap
}

Expected behavior:
Actual behavior:

TS2536: Type 'string | K' cannot be used to index type '{ install: { readonly name: "install"; readonly before: readonly ["preinstall"]; readonly after: readonly ["postinstall", "prepublish", "prepare", "preshrinkwrap", "shrinkwrap", "postshrinkwrap"]; }; pack: { readonly name: "pack"; readonly ignoreSelf: true; readonly before: readonly ["prepublish", "prepare", "prepack"]; readonly after: readonly ["postpack"]; }; publish: { readonly name: "publish"; readonly before: readonly ["prepublish", "prepare", "prepublishOnly", "prepack", "postpack"]; readonly after: readonly ["postpublish"]; }; }'.

Playground Link:
https://www.typescriptlang.org/v2/en/play?#code/KYDwDg9gTgLgBAE2AYwDYEMrDsiA7AZ3lQEsAzFATzWAFl0wAuOAbwCg5O4TCZ1VUzdlxFws6BPlSU4edAFtgzAEQ8i-VMoDcHUZ3GS80uACNgZaErHAJUmQG1lYLGr4DlAXR179Nw8fQyGGAoZgM7OEdIIlcNZQAaOCcsMABXE1ICAAsEpOdgMExgXOTgbKgeAGsAdygGEvKq2vrEpwgiRrwaurBPby4AX37OQuRKoV09cKMZOUUVUcrtSdFp4xIAczxLAGVgVDJmGChU4GHVvwizCywwy5nI0rSMkmyS-MKsd5T0Mb6VkRrGSBYKhay2B5RdowRb-ERDFbPTJZCY+cH+WYKKxOdLI5ZooGmcyWO4Q4xRFK4145VofIrfApU7IAeRmDNhtOhsK8AK4hJBIVJGMe0RhTJyPPhOgRbFAkFg3DwoLIv2wAEkADLkKg0ACiSqglDY7AAkIS5lYiBU8BsdGb7ustrt9mQAPzMEwQCCoGx4O2E64k9ERK08Db2Hn2snAoKC4MPUM2iPStiy8DQeAwShgdVaijIag++hgADSwEoBDgAF44JVyxAyHAszmG3BSPnC3QGDo0-LM9nc9qCzRiwAeEtwUDBPAISuJjbVuDzgB8i+bwFb7Z1RYYcAAZHAAEooaAIUfzxKaoed-XHSjLnu9jNwMipPDIGAkfBwDbAGB57dgAARnHScQGnWc4CvDsRwYMsK2XAAKAhkAqMAYAAOSxZh5zgAAfOASwASmNNgTXIOBENeEttmqPAAOHH14OQ1CSHQrDFCIkiTVNe0YFSKA8Dba9YLAewULQzCsQ8MiBlTPiBKExCt0YrswDgdBK2gwDiyI8TWPY6S2Dkp8FVfd9P2-X9-xEn0ACZQKnYAZy0hjO2LeCCCQiS2Kk+Yl2OMN8MIkj2DIiiWMkjjsB4YSYJ3MBuN4rB+MEuKdIYfSoqMk0TIUtLlNstSNNcordKy3zopkkzzI-L8hOo2j6KK+DHPA5zIO01SPPLLzIsq7CAutBcCOInCDL8mLK11cC6g-cdLzc0TPOXUj8qEnzDMURV0u6hhjLYIA

Any progress or plans on this issue @ahejlsberg @RyanCavanaugh? This is still holding us back on TS 3.4 😭 From what I understand, the only workaround is a bunch casting everywhere. For us, that's going to be over 1000 places and surely going to introduce some mistakes.
Thanks for the help!

Was this partially enabled by https://github.com/microsoft/TypeScript/pull/43183?

I came to report a similar issue and think it's a duplicate of this, so I'll put the example function here:
const getFirstTwoLetters = function<T extends string | undefined> (
	strIn : T
) : T {
	if(typeof strIn === 'undefined') {
		return strIn;
	}
	//At this point in execution, TypeScript knows strIn is of type string.
	//It should also be able to figure out that T is of type string,
	//with no undefined option.
	return strIn.substring(0, 2);
}

The error thrown on the last line is TS(2322):

Type 'string' is not assignable to type 'T'.
'string' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'string | undefined'.

By the point that return statement is reached, 'T' could NOT logically have been instantiated with a different subtype of that constraint.

I recently asked the following Stack Overflow question, and was directed here.
The gist of it, I tried to do the following and all the returns were considered not valid:
interface Obj {
  foo: number;
  bar: string;
}

function createValueOfObjKey<Key extends keyof Obj>(key: Key): Obj[Key] {
  switch (key) {
    case "foo":
      return 0;
    case "bar":
      return "";
  }
}

Now, further into development I ran into additional issues, and wanted to ask if the following is also related to the topic at hand.
Let's suppose the above function (function createValueOfObjKey<Key extends keyof Obj>(key: Key): Obj[Key]) worked, disregarding implementation details. Now, I wrote this function, for TypeScript to be able to guarantee me, that the return value is assignable to the given key. I've found that this only works if it's done "statically", meaning, the exact variant is known.
Consider the following example:
interface Obj {
  foo: number;
  bar: string;
}

type ObjKeyValTuple<Key extends keyof Obj> = Key extends Key ? [Key, Obj[Key]] : never;

// "Static" — works
{
  const staticTupleValid: ObjKeyValTuple<"foo"> =
    // Correct: no error.
    ["foo", 0];
  const staticTupleInvalid: ObjKeyValTuple<"bar"> =
    // Correct: complains about invalid value.
    ["bar", 0];
}

// "Dynamic" — does not work
{
  // Simulating dynamically getting key, e.g. parsing input.
  // Cast required, as removing it leads to TypeScript narrowing the type
  // to the specified variant.
  const key: keyof Obj = "foo" as keyof Obj;
  const value = getValue(key, "1");
  const dynamicTuple: ObjKeyValTuple<typeof key>
    // Incorrect: complains but should work.
    = [key, value];

  // Simulating dynamically getting value, e.g. parsing input
  // The function guarantees that the returned value is assignable to the
  // property `Key` (passed as parameter `key`) in `Obj`.
  function getValue<Key extends keyof Obj>(key: Key, input: string): Obj[Key] {
    switch (key) {
      case "foo":
        // The casts are needed because of the present issue.
        return parseInt(input) as Obj[Key];
      case "bar":
        return input as Obj[Key];
    }

    // This is for some reason also required, because exhaustive checks
    // are not workings...
    throw new Error("unreachable");
  }
}

@Elias-Graf thanks!!!

I believe I just ran into a case where this would apply:
type DataNameMap = {
  string: string;
  number: number;
};

type DataTranslationMap = {
  string: DataNameMap["number"];
  number: DataNameMap["string"];
};

type DataTranslationObject = {
  [key in keyof DataNameMap]: {
    arg: {
      to: key;
      data: DataTranslationMap[key];
    };
    res: DataNameMap[key];
  };
};

type DataTranslationUnion = DataTranslationObject[keyof DataTranslationObject];

function dataTranslation<O extends keyof DataTranslationObject>(arg: {
  to: O;
  data: DataTranslationObject[O]["arg"]["data"];
}): DataTranslationObject[O]["res"] | undefined;
function dataTranslation<U extends DataTranslationUnion>(
  arg: U["arg"]
): U["res"] | undefined {
  if (arg.to === "number") {
    return Number.parseInt(arg.data);
  }

  if (arg.to === "string") {
    return arg.data.toString();
  }

  return undefined;
}

I believe the overloading and maybe more could be removed if this was implemented, because I only had to add it to link the return type to the argument type. Otherwise, just the union worked fine.

Coincidentally, even though all the possibilities are covered, the function still needs an ending return statement. Not sure if this is intended, and how to work around it if it is? I would prefer if that undefined could be removed, based on the fact that another return will always be reached.

Discussion of soundness should make a distinction between the functions external contract and its internal implementation type checking.
If the external contract is unsound, the internal implementation type checking cannot be correct.
The external contracts for non-distributive template functions such as
declare function depLikeFun<T extends "t" | "f">(str: T, str2: T): F[T];

do not specify correlation of the 3 instances of T, and
declare function depLikeFun<T extends "t" | "f">(str: T): F[T];

do not specify correlation of the 2 instances of T.  So there is no way to implement correct return type checking.
Here are two ways that have sound external contracts: first function overloads, and then a distributed template function.
interface F {
  "t": number,
  "f": boolean,
}

// Using overloads the external contract is sound
function dlf(k:"t"): number;
function dlf(k:"f"): boolean;
// implementation
function dlf(k:keyof F): F[keyof F] {
   // However, the internal contract has a bug
   // return 1; // no error, fail
   if (k==="t"){
      const r1: F[typeof k] = 1; // no error, pass
      const r2: F[typeof k] = true; // error, pass
      // return 1; // no error, pass
      return true; // no error, fail BUG
   }
   else {
      const r1: F[typeof k] = 1; // error, pass
      const r2: F[typeof k] = true; // no error, pass
      // return true; // no error, pass
      return 1; // no error, fail BUG
   }
   // Solution - flow analysis is ALMOST THERE.
   // It knows the correct type correlation, but is just not applying it to the return value.
}

// We can also define signatures using a distributed template function (easier than overloads for many keys)
type Sigs<F extends Record<string,any>> = & {
    [k in keyof F]: (k:string) => F[k]
}
// This shows the correlation between sigs parameter and return value is correct.
const fsigst: Sigs<F>["t"] = (k:string) => 1;
const fsigsf: Sigs<F>["f"] = (k:string) => true;
const fsigsx: Sigs<F>["t"] = (k:string) => true; // expect error, pass

// This function provides a sound external contract
const dlf2: Sigs<F>[keyof F] = (k: keyof F): F[typeof k] => {
   // However, the internal contract has a bug (same as overloads)
   // return 1; // no error, fail
   if (k==="t"){
      const r1: F[typeof k] = 1; // no error, pass
      const r2: F[typeof k] = true; // error, pass
      // return 1; // no error, pass
      return true; // no error, fail  BUG
   }
   else {
      const r1: F[typeof k] = 1; // error, pass
      const r2: F[typeof k] = true; // no error, pass
      // return true; // no error, pass
      return 1; // no error, fail BUG
   }
   // Solution - exactly the same as for the overloads case.
}

typescript playground
The flow analysis in both cases appears to ALMOST working well in exactly the same way in both cases, but fails to apply it knowledge correctly to the return value.  It would call that a bug rather than a design problem. @ahejlsberg - would you agree?

What's the current status?

What's the current status?

@craigphicks I don't think there is anything different between if and switch statements. I guess your code works because there are function overloads which will bypass some checks.

These examples, not using overloads, are better:
declare const x: 1|2;
function f2(): 1|2|undefined {
    switch (x){
        case 1: return x;
        case 2: return x;
    }
    x; // error - unreachable code detected (but type is displayed as "never"
}

function f3(): 1|2|undefined { // error - not all code paths return a value
    if (x===1){
        return x;
    }
    if (x===2){
        return x;
    }
    x; // (not unreachable error) type is displayed never
}
```

So they are both exhaustive with respect to the type, because in both cases the type is displayed as `never`.

However, with respect to reachability, the switch statement is exhaustive and the if statements are not.

I didn't make that clear in my previous post so thank you for pointing it out.

function f3(): 1|2|undefined { // error - not all code paths return a value
    if (x===1){
        return x;
    }
    if (x===2){
        return x;
    }
    return assertNever(x); // (not error) (type is shown as never)
}

function assertNever(value: never): never {
  return value;
}


add all filter transmission functions from SVO

@kbarbary I propose that we make all filters from
http://svo2.cab.inta-csic.es/svo/theory/fps/index.php?mode=browse
available through sncosmo. This would result in about 6000 total filters exposed by the program, so wanted to discuss it as an issue first.
thoughts?

Whoa, awesome. I didn't know about the filter profile service. Looks like what I was imagining the stuff in sncosmo could eventually become, but they've already done it, which is great. Some questions:

Can all filters be accessed programatically in the same way (enabling us to write minimal code on the sncosmo side to download directly from the service)?
Are you thinking they would be accessible through sncosmo.get_bandpass(), like existing filters? That is, would the difference between filters from the service and those from other sources be transparent to users? (I'm guessing yes.)
What are you thinking of for a naming scheme and how would it mesh with the existing filter naming scheme? What do we do for filters that already exist in sncosmo?
For filters that already exist in sncosmo, how do their definitions compare to the corresponding filters from the service?
What happens if a filter disappears from the service or if the service disappears? With other filters, we had the option to put them on sncosmo.github.io, but with 6000+ filters this becomes infeasible. (I admit it seems unlikely that this would happen, but it would be good to know what we would do.)

I'd like to hear others' opinions as well.

cc @mansikasliwal @profjsb

Whoa, awesome. I didn't know about the filter profile service. Looks like what I was imagining the stuff in sncosmo could eventually become, but they've already done it, which is great. Some questions:

Can all filters be accessed programatically in the same way (enabling us to write minimal code on the sncosmo side to download directly from the service)?

Yes, API docs here: http://svo2.cab.inta-csic.es/svo/theory/fps/index.php?mode=voservice

Are you thinking they would be accessible through sncosmo.get_bandpass(), like existing filters? That is, would the difference between filters from the service and those from other sources be transparent to users? (I'm guessing yes.)

Definitely. No API changes proposed here.

What are you thinking of for a naming scheme and how would it mesh with the existing filter naming scheme? What do we do for filters that already exist in sncosmo?

for a naming scheme, I propose two approaches:

for new filters that do not already exist in sncosmo:

facility::instrument-filtername
e.g.,
lasilla::combo17-b
for filters that already exist in sncosmo, i propose making the versions available from SVO as a new version of the already existing filter in the registry, with the same name, e.g.,
bessellb, version='svo-1'

For filters that already exist in sncosmo, how do their definitions compare to the corresponding filters from the service?

See above for a proposed handling of this.

What happens if a filter disappears from the service or if the service disappears? With other filters, we had the option to put them on sncosmo.github.io, but with 6000+ filters this becomes infeasible. (I admit it seems unlikely that this would happen, but it would be good to know what we would do.)

I propose we download all the filters and host them at NERSC on a project directory that will never go away, and can handle large amounts of data.

I'd like to hear others' opinions as well.

Posting a static version of all the bandpasses at Zenodo would be my default for longevity—becomes versionable too. Could also host/version using git LFS.
User could pip install bandpasses or sncosmo.download_allbandpasses() as a preamble (like what is done for some large scikit-learn datasets or large nltk models). For lighter weight usage, using a named bandpass in sncosmo would then amount to checking if that bandpass exists locally and if not downloading the bandpass from the site mentioned above.

More useful information here
http://ivoa.net/documents/Notes/SVOFPS/NOTE-SVOFPS-1.0.20121015.pdf

Having access to more bandpasses from different observatories is great!
I like @dannygoldstein 's proposals on naming.
But, beyond naming, this makes me think of a couple of issues that are more general:

Since this is a large repository, it would be good to know that bands came from this repository even when the bandpass was the first instance in sncosmo
Since, we are well-connected with certain surveys, and might prefer to use bandpasses from direct sources, can users express preferences somewhere?

This is almost like a conda channel, and maybe this could be addressed by having a source attribute in Bandpass, and users setting up a source preference somewhere ?

So I think this is a great idea and the details can be ironed out. However, there are enough tricky details about backwards compatibility, documentation, etc that it might be worthwhile to write up as an enhancement proposal before implementing. For example:

What will the local storage directory structure (in $SNCOSMO_DATA_DIR/bandpasses) look like for these filters? (Currently that directory is organized by instrument, not facility)
get_bandpass doesn't currently have versioning. Are we adding one and what will that look like in detail? What will the default version be?
Currently, when get_bandpass() receives an unknown filter, it throws an exception that lists all the known filters. This will become infeasible with 6000+ filters. What will the new behavior be?
Documentation: currently all the bandpasses are documented at https://sncosmo.readthedocs.io/en/latest/bandpass-list.html along with their transmission plots. Presumably we'll no longer do this for all 6000+ filters, since it is already done on the SVO site. How will the bandpass page change? I'm guessing we'll want to still document the non-SVO filters... but how will it be clear to users which filters are available?
Internals: how will this be implemented? This is a somewhat major architectural change because we won't be explicitly registering every single existing filter as we do now in https://github.com/sncosmo/sncosmo/blob/master/sncosmo/builtins.py
Fallback mechanism: currently if a file disappears from an external host, the fallback mechanism is clear: we remove it from redirects.json and add it to sncosmo.github.io/data. This is nice because it fixes the problem for all existing versions of sncosmo and doesn't require releasing a new version of sncosmo. Will we have something similar? Will we use the same mechanism?

There are probably several other things to consider that I haven't thought of here. Would you @dannygoldstein (or anyone else interested it implementing this) be willing to write up an enhancement proposal?

@kbarbary I will write up a proposal

Update: the only filters that are present in sncosmo that are not present in the SVO are:

radially dependent megacampsf (radially averaged are present)
4shooter2
jwst miri tophat
snls3-landolt

I'm going to reopen this. The bandpasses in SNCosmo are kind of a mess right now with different naming conventions and formats, and it would be good to think about how to improve this. This Issue has a lot of insightful discussion about this.


Cleanup of broken links on Glossary page(either removing or fixing)

Some remainder of https://github.com/perl6/doc/issues/728-related work.

No dead links now, so merged.


task: makes elements sticky when scrolling

This PR makes the table of contents, secret box, and top bar components sticky so that when the user scrolls, they all stay on the screen.
Note: the Secret Box component does take up a decent amount of screen real estate, so it might be undesirable to have it stuck to the screen. I mitigated this by minimizing the Secret Box when the user scrolls, but even then it might take up too much space. Let me know what you think.

I applied the changes manually to deal with less conflicts 🤗


Update API JSON

Codecov Report

Merging #553 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #553   +/-   ##
=========================================
  Coverage     79.45%   79.45%
  Complexity      576      576
=========================================
  Files            79       79
  Lines          2146     2146
  Branches        277      277
=========================================
  Hits           1705     1705
  Misses          263      263
  Partials        178      178


Fold readme.md into README.md

Mac OS X "case insensitive but case preserving" really
hates two files whose names with only case differences.

Thanks!


Publish opentelemetry-auto jar to maven central

This is a less ambitious version of #135 😄.
See https://github.com/open-telemetry/opentelemetry-auto-instr-java/issues/370#issuecomment-624223374.
I think there's some discussion we need to resolve in #370 first though.

Why do we need to publish anything other than opentelemetry-auto jar and exporter jars? And, probably, fat jar auto+exporters to help with #370

We also have to publish snapshot builds

I propose to publish this to Artifactory OSS/Bintray first, as this is much easier from administrative side of things. We then can easily push jars to Maven Central from Bintray. I have direct contact with JFrog, so I can take this task. But probably I will need some help with governance and such regarding e.g. Bintray account.

@iNikem that would be great! Assigning to you :smile:. Let's chat with @carlosalberto about what we can learn / leverage from his experience doing this in opentelemetry-java (https://github.com/open-telemetry/opentelemetry-java/blob/master/RELEASING.md).

Do we need separate release branch right now, while we are still in 0.X range?


Only showing a single notification

TestFlight Build running on  iOS 10.3.2
I'm only getting a single cell displaying in the read section with an 8 day old notification despite having 4 unread and several read notifications on the Github web interface.
At first I thought it was a private / public repository thing but the notification I get is from a private repository. Pull to refresh / relaunching / log-out has no effect.

Hmmm. @Malecks could you post a screenshot of the app and web notifications? You can blue out the titles if they are sensitive. I think there are certain types of notifications on web that the GitHub notifications API doesn't support.

Notifications that show in the app are indicated by the red arrows

@Malecks is the greengage-ios a private repo?

@rnystrom Yes it is! And that was my thought about why I'm not seeing notifications from there, however greengage-mobile/whitelabel is also private and I was able to see a notification from that repository in the app.

🤔 It looks like its an org permissions issue, gonna dig in this weekend and see what special stuff I need to do. Tracking in #60.


add bsd 2 clause license

The reasoning behind it is: we're all fine with that license, and we enjoy writing that code so much that it's fine for anyone to use, extend, do whatever they want with it. While we're also fine with AGPL, this may prevent people from using this software (namely in companies whose legal departments are allergic to GPL/AGPL [due to unresolved issues of these licenses]).
Please @cfcs could you approve (or disapprove) this license change, since you contributed quite a lot back than.
Thanks a lot.

Great! @dinosaure also approved on IRC; merging.


Workaround for xunit bug fix #209

@gigi81, thanks!

And the build is finally green!!! :-D
Cheers


Function name property incorrectly derived from description-less Symbol

When a function's name property is derived from a Symbol value that has no
description, the name should be "[]".
$ ./bin/es6draft --version
es6draft rev38 (build: 2015-07-06T15:04:38)
$ ./bin/es6draft -e 'var s = Symbol(); var o = { [s]: ()=>{} }; print(o[s].name);'

$

(espected: "[]")

<IP_ADDRESS> Symbol ( [ description ] )
When Symbol is called with optional argument description, the following steps
are taken:

If NewTarget is not undefined, throw a TypeError exception.
If description is undefined, let descString be undefined.
Else, let descString be ToString(description).
ReturnIfAbrupt(descString).
Return a new unique Symbol value whose [[Description]] value is descString.

9.2.11 SetFunctionName (F, name, prefix)
The abstract operation SetFunctionName requires a Function argument F, a
String or Symbol argument name and optionally a String argument prefix. This
operation adds a name property to F by performing the following steps:

Assert: F is an extensible object that does not have a name own property.
Assert: Type(name) is either Symbol or String.
Assert: If prefix was passed then Type(prefix) is String.
If Type(name) is Symbol, then

Let description be name’s [[Description]] value.
If description is undefined, let name be the empty String.
Else, let name be the concatenation of "[", description, and "]".

If prefix was passed, then

Let name be the concatenation of prefix, code unit 0x0020 (SPACE), and
name.

Return DefinePropertyOrThrow(F, "name", PropertyDescriptor{[[Value]]:
name, [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]:
true}).
Assert: the result is never an abrupt completion.

But SetFunctionName, step 4.ii sets the name variable to the empty string if the symbol's description is undefined.

That "Else" is step 4.iii is important, isn't it? Sorry for the noise.

No problem. :smiley:


⚠ Bofrost.lu has degraded performance

In c926f5a, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1449 ms

Resolved: Bofrost.lu performance has improved in ed09d79 after 34 minutes.


[DRAFT] Homebrewery as an Electron App

This draft PR is some initial work towards enabling the use of Homebrewery locally as a standalone Electron app.
While this PR produces the base functionality, the following issues have been identified:

[ ] prompt, alert, confirm all do not work in ElectronJS

[ ] login system does not work - uses prompt

[ ] switching to a new page often opens a new window

If you experiment with this and strike any issues, please record them here.

we need to change how links work in local

Or just specify a new value for NODE_ENV : electron or something similar.

login system does not work - uses prompt

This makes me think of <dialog> element showModal() method. It's not blocking, but it does present in the top-layer so cannot be behind anything, and all elements outside of the <dialog> are rendered inert while it is present, so the user cannot perform any other actions while it is displayed - but crucially, server side functions can continue as normal.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/showModal

Why would there be an account system at all?

Why would there be an account system at all?

For the same reason windows offers different accounts, multiple people might want multiple accounts, i say we keep them for the local version.

Why would there be an account system at all?

If we were able to link to file system and thus have a users in their own folders, there might be less need for an account system.
That said, I still expect that some users will want to lock their documents so that it can't be viewed accidentally - and thus if they are exposed in the filesystem, they will not be protected.
I'm not sure which option is the best way forward; at the moment, this is just a small experimental side branch.


[wip] Async server render

[ todo: write what we're doing here ]

split out rendering to a class
make logic more explicit
support a double pass async render in choo

Checklist

[x] tests pass

Context
Related to @diffcunha's experiment.
Semver Changes
Minor

lol, all tests pass. Def don't merge yet tho, because we have a race condition

@goto-bus-stop @diffcunha if you could take this for a spin, that'd be very helpful. There's a race condition in here somewhere, and I'm staring blindly at it - I think we just need a second pair of eyes on this to figure it out. Thanks!

this is hella cool, great work :D

rebased! - should be good to merge then :D

Aye; I had some issues with the SSR indicator in the UI on this branch but will merge anyway so we won't have to do much rebasing when new PRs are opened. Maybe I can fix it on master, who knows!

I've been experimenting with this new API, which at first felt magical, but I then encountered an issue with saving data to state for use in the second render pass.
I take it that the pattern of checking for data on state before rendering a view and emitting an event if something needs to be fetched is pretty common on choo (?)
Here's an example: https://gist.github.com/tornqvist/d7e65cfe97718f19d1aa01f0877795e7
The problem when used with this new API is that the stores reference to state is outdated as toString on choo doesn't mutate the state, but replaces it.
Does this use case make sense or have I misinterpreted the intended use of the prefetch api?


Use correct font

Update incorrect font usage

Looks good, as Dave said it would be good to have some before/after pics if possible.


[hotfix][docs][FLINK-9757] Fix typos found after hunspell run

What is the purpose of the change
This PR corrects typos found while hunspell run
Brief change log
typos from [FLINK-9757] description
speciyfing => specifying
Validatation => Validation
CHARACTERISTICTS => CHARACTERISTICS
developement => development
possiblities => possibilities
aggreagtions => aggregations
instancesof => instances of
Dipsatcher => Dispatcher
Kerbreros => Kerberos
dependencoes => dependencies
Dependenies => Dependencies
bulding => building
prorgams => programs
Documentation

Does this pull request introduce a new feature? ( no)
If yes, how is the feature documented? (not applicable )

@subhankarb +1, hope for merging into 1.5.1 cc @tillrohrmann


[project] Initial commit

This PR is on branch projection.

#1933

Unfortunately it appears that this design has a soundness hole as described here.


Schema objects should support schema creation, editing and saving

use frictionlessdata\tableschema\Schema;
use frictionlessdata\tableschema\Field;

// create new schema
$schema = Schema::create();
// must set fields first for new Schemas
$schema->fields = [
  new Field((object)["name" => "id", "type" => "integer"])
];
// after every change - schema is validated and will raise Exception in case of validation errors

// edit schema
$fields = $schema->fields;
$fields[] = new Field(...);
$schema->fields = $fields;
$schema->foreignKeys = ["id", "name"];

// will raise exception in case the edit causes invalid schema

// save schema
$schema->save($file_path);

saving was done in v0.1.4


iter_size/batch_accumulation is not properly appreciated when generating solver prototxt for caffe

Caffe counts iterations as number of weight updates see lines 280-282 in src/caffe/solver.cpp
Therefore number of training samples per iteration is batch_size * iter_size (or batch_accumulation parameter in DIGITS terms)
However it looks as DIGITS count number of samples per iteration only as batch_size, this results in wrong calculation of "display", "max_iter", "stepsize", "snapshot" parameters in solver.prototxt

Duplicate of #1240


Prebuilt binaries failing for Node 22 on Windows

See https://github.com/blueconic/node-oom-heapdump/actions/runs/8830424770
@spmiller when you have time, could you check why node 22 doesn't work?

Hi @paulrutter , I'm away on holiday this week but should be able to take a look first thing next week. It looks like the Windows build can't find npm?!

Great! No hurry.
Yes, somehow nom cannot be found with 22.x

Hi @paulrutter, it's lucky that "first thing next week" turned into Thursday because there is an upstream issue that has had some patched pushed recently:
https://github.com/nodejs/node/issues/52682
By the time you read this they may have cut a new NodeJS release, but I would suggest that we can't build with Node 22 on Windows until the linked issue is resolved.
Good thing Node 22 isn't LTS eh!

Then we can wait for that to be merged!

22.1 seems to have fixed it :) thanks for checking it out @spmiller
See https://github.com/blueconic/node-oom-heapdump/commit/e36551dbd5401047480b248bd64bd82f4881fe9c

I will republish as 3.2.3 tomorrow

https://github.com/nodejs/nan/issues/968

https://github.com/blueconic/node-oom-heapdump/actions/runs/9102048245

https://github.com/blueconic/node-oom-heapdump/releases/tag/3.2.3


idToken can't be retrieved from cache

Core Library
MSAL.js v2 (@azure/msal-browser)
Core Library Version
2.21.1
Wrapper Library
Not Applicable
Wrapper Library Version
None
Description
acquireTokenSilent method can be used only for accessToken.
It should also be available for idToken.
My app is using only idToken, accessToken is always empty.
Currently there is no way to get idToken from cache, with the same nice flow as it exist for accessToken.
msal.acquireTokenSilent({ forceRefresh: false, etc }) will always trigger network call.
https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/master/lib/msal-common/src/client/SilentFlowClient.ts#L68
Is there any configuration where we can set which token is main, eg { authToken: 'idToken'; //  default 'accessToken' }.
Thanks.
Error Message
No response
Msal Logs
No response
MSAL Configuration
auth: {
    clientId: config.clientId,
    authority: config.authority,
    knownAuthorities: config.knownAuthorities,
    redirectUri: config.loginRedirectUrl,
    postLogoutRedirectUri: config.logoutRedirectUrl
  },
  cache: {
    cacheLocation: CONSTANTS.localStorage,
    storeAuthStateInCookie: false
  }

Relevant Code Snippets
It's clear from the source code that network call is always required, since `!cacheRecord.accessToken` is true:

       if (request.forceRefresh) {
            // Must refresh due to present force_refresh flag.
            this.serverTelemetryManager?.setCacheOutcome(CacheOutcome.FORCE_REFRESH);
            throw ClientAuthError.createRefreshRequiredError();
        } else if (!cacheRecord.accessToken) {
            // Must refresh due to non-existent access_token.
            this.serverTelemetryManager?.setCacheOutcome(CacheOutcome.NO_CACHED_ACCESS_TOKEN);
            throw ClientAuthError.createRefreshRequiredError();
        }

### Reproduction Steps

1. check Relevant Code Snippets

### Expected Behavior

acquireTokenSilent should work for idToken if accessToken is empty.
There should be some configuration to mark main authToken.

### Identity Provider

Azure B2C Custom Policy

### Browsers Affected (Select all that apply)

Chrome, Firefox, Edge, Safari, Internet Explorer

### Regression

_No response_

### Source

External (Customer)

@easingthemes The ID token should always be returned from acquireTokenSilent. However, the ID token is currently not returned in the AccountInfo objects returned from the getAccount* APIs, which will be addressed in #5036

Thanks @jasonnutter, I've checked now deeper and indeed idToken should be retrieved from cache, just naming is confusing.
Method readAccessTokenFromCache is not referring to accessToken only, but other tokens also, depending on the type.
            switch (credType) {
                case CredentialType.ID_TOKEN:
                    matchingCredentials.idTokens[cacheKey] = entity as IdTokenEntity;
                    break;
                case CredentialType.ACCESS_TOKEN:
                case CredentialType.ACCESS_TOKEN_WITH_AUTH_SCHEME:
                    matchingCredentials.accessTokens[cacheKey] = entity as AccessTokenEntity;
                    break;
                case CredentialType.REFRESH_TOKEN:
                    matchingCredentials.refreshTokens[cacheKey] = entity as RefreshTokenEntity;
                    break;
            }

https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/master/lib/msal-common/src/cache/CacheManager.ts#L421
Thanks for the explanation and the fix.

@easingthemes Correct. In v2, MSAL will always return both an ID token and an access token.


HOTFIX: wrap StreamThread#runLoop in outer catch block

We've been amassing more and more catch blocks around the runOnce loop in the StreamThread's runLoop. Some of these have complex handling which is performed inside the catch block, such as handleCorrupted which itself can throw exceptions (see KAFKA-12523).
We also have a final catch Throwable block which invokes the exception handler on any unexpected exceptions. But since this is part of the same try as the other catch blocks, exceptions thrown from eg handleCorrupted will bypass the catch Throwable block and miss the exception handler.
Also simplifies the EOS vs ALOS code paths by just returning false from the runLoop regardless of processing mode
This should probably be cherrypicked back to the 2.8 branch cc @vvcephei

Closing this PR since we've ported this fix over to https://github.com/apache/kafka/pull/10387