Authentication middleware prevent CORS to be send correctly

I have an authentication middleware. In the middleware if the request method is OPTIONS I am returning the handler intact with the aim that aiohttp-cors handle the preflight request and return the correct response headers. However, the response headers are not being sent correctly by the signals.
It is quite possible that I am doing something wrong in my middleware, and the OPTIONS call need to be handled differently.  This is my middleware:
@middleware
async def auth_middleware(request, handler):
    if isinstance(request.match_info.route, SystemRoute):  # eg. 404
        return await handler(request)

    if request.method == hdrs.METH_OPTIONS:
        return await handler(request)

    try:
        request['claims'] = await authenticate(request)
    except ValueError as e:
        raise HTTPUnauthorized(PayloadErrors(e.args[0]))

    return await handler(request)

I am creating the app as following:
def create_app():
    app = Application(middlewares=middlewares)
    setup_cors(app)
    return app

And this is how I am setting up cors:
def setup_cors(app: Application):
    resources = [
        'http://localhost:8100',
        'http://www.example.com',
    ]

    cors = aiohttp_cors.setup(app, defaults={
        resource: aiohttp_cors.ResourceOptions(
            allow_credentials=True,
            expose_headers='*',
            allow_methods='*',
            allow_headers='*',
        ) for resource in resources
    })

    for route in app.router.routes():
        cors.add(route)

However, whenever I make a call I get the following error:
Unhandled exception
Traceback (most recent call last):
  File "/python3.7/site-packages/aiohttp/web_protocol.py", line 398, in start
    await resp.prepare(request)
  File "/python3.7/site-packages/aiohttp/web_response.py", line 299, in prepare
    await request._prepare_hook(self)
  File "/python3.7/site-packages/aiohttp/web_request.py", line 686, in _prepare_hook
    await app.on_response_prepare.send(self, response)
  File "/python3.7/site-packages/aiohttp/signals.py", line 35, in send
    await receiver(*args, **kwargs)
  File "/python3.7/site-packages/aiohttp_cors/cors_config.py", line 171, in _on_response_prepare
    assert hdrs.ACCESS_CONTROL_ALLOW_ORIGIN not in response.headers
AssertionError
Unhandled exception
Traceback (most recent call last):
  File "/python3.7/site-packages/aiohttp/web_protocol.py", line 398, in start
    await resp.prepare(request)
  File "/python3.7/site-packages/aiohttp/web_response.py", line 299, in prepare
    await request._prepare_hook(self)
  File "/python3.7/site-packages/aiohttp/web_request.py", line 686, in _prepare_hook
    await app.on_response_prepare.send(self, response)
  File "/python3.7/site-packages/aiohttp/signals.py", line 35, in send
    await receiver(*args, **kwargs)
  File "/python3.7/site-packages/aiohttp_cors/cors_config.py", line 171, in _on_response_prepare
    assert hdrs.ACCESS_CONTROL_ALLOW_ORIGIN not in response.headers
AssertionError

@bmamouri I too have the same issue. A dirty fix was to move the validation of the auth request headers to each route, making them call a common validation function. But this issue renders the aiohttp middleware component unusable with this library.

Hello, I still have this issue.

I have an authentication middleware. In the middleware if the request method is OPTIONS I am returning the handler intact with the aim that aiohttp-cors handle the preflight request and return the correct response headers. However, the response headers are not being sent correctly by the signals.
It is quite possible that I am doing something wrong in my middleware, and the OPTIONS call need to be handled differently. This is my middleware:
@middleware
async def auth_middleware(request, handler):
    if isinstance(request.match_info.route, SystemRoute):  # eg. 404
        return await handler(request)

    if request.method == hdrs.METH_OPTIONS:
        return await handler(request)

    try:
        request['claims'] = await authenticate(request)
    except ValueError as e:
        raise HTTPUnauthorized(PayloadErrors(e.args[0]))

    return await handler(request)

I am creating the app as following:
def create_app():
    app = Application(middlewares=middlewares)
    setup_cors(app)
    return app

And this is how I am setting up cors:
def setup_cors(app: Application):
    resources = [
        'http://localhost:8100',
        'http://www.example.com',
    ]

    cors = aiohttp_cors.setup(app, defaults={
        resource: aiohttp_cors.ResourceOptions(
            allow_credentials=True,
            expose_headers='*',
            allow_methods='*',
            allow_headers='*',
        ) for resource in resources
    })

    for route in app.router.routes():
        cors.add(route)

However, whenever I make a call I get the following error:
Unhandled exception
Traceback (most recent call last):
  File "/python3.7/site-packages/aiohttp/web_protocol.py", line 398, in start
    await resp.prepare(request)
  File "/python3.7/site-packages/aiohttp/web_response.py", line 299, in prepare
    await request._prepare_hook(self)
  File "/python3.7/site-packages/aiohttp/web_request.py", line 686, in _prepare_hook
    await app.on_response_prepare.send(self, response)
  File "/python3.7/site-packages/aiohttp/signals.py", line 35, in send
    await receiver(*args, **kwargs)
  File "/python3.7/site-packages/aiohttp_cors/cors_config.py", line 171, in _on_response_prepare
    assert hdrs.ACCESS_CONTROL_ALLOW_ORIGIN not in response.headers
AssertionError
Unhandled exception
Traceback (most recent call last):
  File "/python3.7/site-packages/aiohttp/web_protocol.py", line 398, in start
    await resp.prepare(request)
  File "/python3.7/site-packages/aiohttp/web_response.py", line 299, in prepare
    await request._prepare_hook(self)
  File "/python3.7/site-packages/aiohttp/web_request.py", line 686, in _prepare_hook
    await app.on_response_prepare.send(self, response)
  File "/python3.7/site-packages/aiohttp/signals.py", line 35, in send
    await receiver(*args, **kwargs)
  File "/python3.7/site-packages/aiohttp_cors/cors_config.py", line 171, in _on_response_prepare
    assert hdrs.ACCESS_CONTROL_ALLOW_ORIGIN not in response.headers
AssertionError

the issue is here
Path : site-packages\aiohttp_cors\cors_config.py
Line: 171 : assert hdrs.ACCESS_CONTROL_ALLOW_ORIGIN not in response.headers
i had to comment this line to get it working

the issue is here
Path : site-packages\aiohttp_cors\cors_config.py
Line: 171 : assert hdrs.ACCESS_CONTROL_ALLOW_ORIGIN not in response.headers
I had to comment this line to get it working


12345 port is not open

Bug Description
When trying to reach the /agent/api/v1/metrics/targets endpoint, I repeatedly got curl: (7) Failed to connect to <IP_ADDRESS> port 12345 after 0 ms: Connection refused error messages.
When looking at the Service of the application, it doesn't look like it is listed in PORT(S):
kubectl get svc -A | grep grafana
kubeflow              grafana-agent-k8s             ClusterIP   <IP_ADDRESS>   <none>        3500/TCP,3600/TCP            26m

Similarly, the juju status output does not show any Ports:
grafana-agent-k8s/0*  blocked   idle   <IP_ADDRESS>                 grafana-cloud-config: off, logging-consumer: off

This suggests that the port is not open.
Workaround
The port is just not open, so we can still reach the desired endpoint from within the unit:
juju ssh grafana-agent-k8s/0 curl localhost:12345/agent/api/v1/metrics/targets
To Reproduce

juju deploy grafana-agent-k8s  --channel latest/stable
curl -v <unit IP>:12345/agent/api/v1/metrics/targets
See error

Environment
juju 3.5.1
microk8s 1.29
Relevant log output
curl -v <IP_ADDRESS>:12345/agent/api/v1/metrics/targets
*   Trying <IP_ADDRESS>:12345...
* connect to <IP_ADDRESS> port 12345 failed: Connection refused
* Failed to connect to <IP_ADDRESS> port 12345 after 0 ms: Connection refused
* Closing connection 0
curl: (7) Failed to connect to <IP_ADDRESS> port 12345 after 0 ms: Connection refused
ubuntu@ip-172-31-15-25:~$ juju status grafana-agent-k8s
Model     Controller  Cloud/Region        Version  SLA          Timestamp
kubeflow  uk8s-351    microk8s/localhost  3.5.1    unsupported  20:38:37Z

App                Version  Status   Scale  Charm              Channel        Rev  Address         Exposed  Message
grafana-agent-k8s  0.32.1   waiting      1  grafana-agent-k8s  latest/stable   45  <IP_ADDRESS>  no       installing agent

Unit                  Workload  Agent  Address      Ports  Message
grafana-agent-k8s/0*  blocked   idle   <IP_ADDRESS>         logging-consumer: off, grafana-cloud-config: off

Additional context
No response

This has partly been addressed by open_ports in https://github.com/canonical/grafana-agent-k8s-operator/pull/289, which landed in Revision 71.
The missing step is to bind <IP_ADDRESS> instead of localhost in the config/layer.

@lucabello:
I'm not sure whether we want to expose this port externally as it comes with quite some security implications that we've yet to assess.


Allow persistent connection option

Excon allows a connection flag to keep the socket open (for the current thread). That flag is called persistent: true. See docs https://github.com/excon/excon
This changes the Faraday adapter a bit, to make sure we will memoize the connection when that flag is passed.
cc @brasic

@olleolleolle I addressed the spec change. let me know if you have any questions. thansk

Thanks, @arthurnn  for this change - should be generally available, now at https://rubygems.org/gems/faraday-excon


Outlier Detection for non-error status codes

Title:  Support outlier detection of other status codes (particularly 4xx).
Description:
Outliers can be hosts returning an abnormal rate of any status code, not just 5xx. Although 4xx errors are generally considered client errors, if a host starts returning a large number of 4xx, it may signal it has some problem (possibly related to authz, authn, etc) and should be considered an outlier. At Pinterest, we are interested in being able to identify 4xx outliers in addition to 5xx outliers (although I can imagine this could have a general solution for all 300+ status codes).
[optional Relevant Links:]

Any extra documentation required to understand the issue.

Sounds good. I will implement this. I think that the API should be extended to define status codes considered as errors, so one can specify exact codes which will cause a node to be considered an outlier.

@cpakulski  wanted to check if there are any plans to support the above? this would be amazingly helpful feature..
" I think that the API should be extended to define status codes considered as errors, so one can specify exact codes which will cause a node to be considered an outlier."
this will be really helpful, for cases like lets say we want to eject for all 5xx except 502 for some reason or something like that if required 🙏

@gauravojha I still plan to work on this. Your example with excepting 502 is a very good point. Please keep an eye on this issue and I should land a PR within few weeks.

@cpakulski Any progress on this pls? 🙂

I wrote a proposal and coded working prototype some time ago. Then it was put on hold but I plan to open a formal PR within next month.


[AKS] Add DataCollectionSettings support for AKS Monitoring Addon in MSI auth mode

Related command

Description

Added  DataCollectionSettings support for AKS Monitoring Addon in MSI auth mode
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

Hi, @zhoxing-ms , can you please review this PR?

@Fuming Could you please help review this AKS related PR?

hi, @FumingZhang , can you please review this PR?

Hi, @zhoxing-ms , can you please review and help on merging this PR?


Can't write the correct values

Hi, I have a BLE balance board I want to connect to Unity but having issues when writing to the device.
I tested with Universal Sample and some other libraries. The Device is working and also can get notify from the Unity Demo scene.
As example one of the characteristics control the led on the board as R G B Rainbow and gets 4 byte value so when I send "FF 00 00 00" it will glow red.
I tried to change parse text input as Hex but couldn't manage to write to the board.
public static Byte[] FormatData(string data, DataFormat format)
    {
        try
        {
                string[] values = data.Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);
                byte[] bytes = new byte[values.Length];

                for (int i = 0; i < values.Length; i++)
                    bytes[i] = Convert.ToByte(values[i], (format == DataFormat.Dec ? 10 : (format == DataFormat.Hex ? 16 : 2)));

            return bytes;

        }
        catch (Exception error)
        {
            return null;
        }
    }`

`
    public void Write()
    {

        byte[] payload = FormatData(writeInput.text,DataFormat.Hex);
        BleApi.BLEData data = new BleApi.BLEData();
        data.buf = new byte[512];
        data.size = (short)payload.Length;
`

Hi @Dragelans :),
what error message do you get?

Hi @adabru ,
I don't get any error , when I set blocking mode true it just freezes though so not sure if it's totally cause of an error or the format type I send

Hi @adabru again,
With the dll, I wrote a test console application to check blocking mode. It returns "Write Success"  but having no affect on the device.
In datasheet, there are specific lengths in this case 4 bytes. on toolBLEx I manually send the bytes it works but if send more than 4 it doesn't have any affect so I thought it might be about the buffer size maybe but when i change buffer size to bytes length it gives error about not correct size and closes the application.

Are you setting the BLEData size property to 4?

I did, but on code when sending it's already resizing bytebuffer array from 0 to data size so that was not the issue.
I checked another BLE library for console and compared the send code. there were 2 main differences.
1- Byteorder, I see in reference library it goes something like "Writer.Byteorder(LittleEndian)" meanwhile it didn't on dll. I actually encountered this in another library where i had to enter bytes reverse. Though don't think that was the main problem since even if I entered in wrong order it should have done something.
2- WriteWithoutResponse , in other library It was WriteWithResponse so I changed that and now it's working. Since haven't work on bluetooth before I have no idea why it makes a difference but now it works.
https://github.com/adabru/BleWinrtDll/blob/f2635b7b02432ea3006983657107f092c862171d/BleWinrtDll/BleWinrtDll.cpp#L533-L536

Thank you very much for sharing. There seems to be a related issue: https://github.com/adabru/BleWinrtDll/issues/33
Do you have a thought on how that could be implemented so that users won't have the same hard time as you did? Otherwise it can be added to the readme.

Thank you very much for sharing. There seems to be a related issue: #33
Do you have a thought on how that could be implemented so that users won't have the same hard time as you did? Otherwise it can be added to the readme.

Good question, though not sure. Seems like difference between With and Without Response is With sends back acknowledgment but don't know how this affects the device since again as I mentioned, don't have much experience with bluetooth in general.
I'd say WithResponse can be added as default to repo but that might slow down the connection as waiting response causes a bit delay.
Maybe a section on readme can be added for possible errors and solutions


Arduino Mega not working with WRAE

I've been trying to using an Arduino Mega (2560) with my raspberry pi. I uploaded standard firmata, and tried using windows remote arduino experience to connect to the board, in order to test that firmata is working correctly. However, it tells me the connection has failed, and asks if I've uploaded standard firmata.
Is this a common issue? I figured that it should at least be working for windows remote arduino experience, if not when it is hooked up to the pi.
I know this problem (or at least one similar) was mentioned in this thread:
https://github.com/ms-iot/remote-wiring/issues/80
specifically
"Coming back to this issue, I had a bit of time to debug it on the mega and partially solved the problem. From what I can tell, the mega has a lot more pins than the Uno and as such, takes a bit longer to count them all and build the capabilities. Thus, it would send a new request before giving the board time to complete the request which was sent before and never giving it time to actually respond.
In RemoteDevice.cpp, around line 497, I changed Sleep( delay_ms ); to Sleep( 1000 );
Obviosuly it is a temporary solution but at least it works."
I tried to implement this in my visual studio project (which has been verified to work with an arduino uno) However, since remote wiring is now installed via the simple nuget command (Install-Package Windows-Remote-Arduino), and the manual method doesn't appear to work, as it gave the following error when I tried to add the firmata and remote wiring references:
"a reference could not be added. primarywinmdoutputgroup parameter name output group not known or another build error occured"
Any advice?

Hi @dflintt,
It seems editing the RemoteDevice.cpp is the best way to use Remote Arduino with the Mega.  This was discussed at https://social.msdn.microsoft.com/Forums/en-US/33ee6f83-fab8-43c0-8d28-b85d8347634a/arduino-mega-and-firmata?forum=WindowsIoT
Sincerely,
IoTGirl

Sorry, I don't think I was clear enough. I know that this has been discussed, but my problem is that I can't edit RemoteDevice. See picture below:

The installation guide says to install windows remote arduino using the nuget package manager command (link here: https://github.com/ms-iot/remote-wiring/blob/develop/installation.md ). This adds the reference in the project, but clicking on it pops up the error message above. (This project has already been built, so that isn't the issue).
The alternative installation instruction is to import the microsfot maker firmata and microsoft maker remotewiring packages (which contain remote device) into the project and them add them as a reference. But that doesn't appear to work, as it is giving me the following error:

So I suppose to rephrase my question, do you know why this isn't importing correctly anymore? I followed the manual install instructions on the link above.

@IoTGirl I don't mean to be rude, but this is fairly urgent, and a response would really be appreciated.

Sleep ( 1000 ); does not work for me but Sleep( 200 ); works.

Closing based on answer given by @DeveloperMK


README Broken

Some Images and icons are not appearing properly. Project and contributors sections are appearing twice.
I don't think having contributors section in README is any good because It's already appears on right side of repository.
Assign Someone else

/assign


Add Giphy Integration to Clack

Wanted to be able to attach Gifs to my
messages, and using the new beta components allows
me to add this Giphy Integration!
Discussed with Adam about how to do this and we ended
up with adding an api route to get the api token
from the server and store this within a config context
(incase we have any more that we want to retrieve).
I've applied for a production key from Giphy
(currently we can make a max of 100 api calls per
hour) so hopefully we can get this soon.
Test Plan:
Add GIPHY_API_KEY in .env and ran Clack
locally. Can attach and send gifs!

Add GIPHY_API_KEY in .env and ran Clack locally.

Make sure to add to the .env in 1password if you haven't already! And we'll need to manually add it to the .env on the clack server. I think all the directions for ssh access are in Notion, and then you just edit the .env by hand, LMK if you need help with this (the clack deploy is wonky).


[WIP] add image info

Please provide a description of this PR:

@zirain: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-helm_istio
21a9beb079b81f45602e3f781e42ad574d69d9b7
link
true
/test integ-helm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.


Team Beta Submission

Team Beta Submission Assignment 1

Hi Professor,
Do we need to make any other changes as well?

please remove changes to config.py

Done professor


async / await and PromiseLike

async function delay(millis: number): PromiseLike<void> {
	return Promise.resolve(undefined);
}

The code above is not valid and is rejected by the compiler.
Could you explain why a PromiseLike is not sufficient as a return value. I looked at the generated code and I couldn't spot an obvious reason.

if you use a type annotation, it is going to be used to create the promise object wrapping the return value. there is no "value" named PromiseLike, so it is going to fail at runtime.
so either do not give it a type annotation, and it would be inferred to be the built-in "Promise", or use a Promise library.

Also, since you're returning a promise and not the value, you don't need to mark it as async anyway.

This might get complicated if you use two libraries which use different promise implementation. Then the code needs to wrap them.
I still think that the code should allow PromiseLike.The awaiter code the compiler generate could still create an instance of a Promise since it conforms to PromiseLike. However the cast method must not do an instanceof Promise check. Instead it would need to check for a then function. All the awaiter code needs right now is a then function.

@dbaeumer if you want to annotate the return value as PromiseLike<T>, then just return a value assignable to type T from the async function and it works fine. E.g.:
async function f1(): PromiseLike<void> {
    /* ...some async operation... */
    return;
}

async function f2(a: number, b: number): PromiseLike<number> {
    /* ...some async operation... */
    return a + b;
}

async function f3(): PromiseLike<string> {
    /* ...some async operation... */
    return 'foo';
}

@Arnavion shorten my example to much. I need the async keyword since I want to use await in the body. Something like:
declare function use(): PromiseLike;
async function delayer(millis: number): Promise {
let result = await use();
return Promise.resolve(undefined);
}

@dbaeumer but why do you need the line return Promise.resolve(undefined);? Why not just allow the async body to return - it will wrap the return value in a promise - you don't need to create the promise explicitly. i.e.:
async function delayer(millis: number) {
    let result = await use();
}

That will return Promise<void>, no need for any annotations or creating explicit promises.

Is this what you are trying to do:
async function delayer(millis) {
    await new Promise(resolve => setTimeout(resolve, millis));
}

That will return a Promise<void> that resolves after millis milliseconds.

@yortus the example is not about implementing a delayer :-). Here is what I want to do: I have a library that provides APi to others. This API is speced in terms of PromiseLike. Now I want to asyncfy the library. To do so I need to change all signatures to return Promise instead of PromiseLike otherwise I can't use await inside the implementation. This is still doable. What I don't fully understand what will happen if I have code like this:
function imported(): PromiseLike<string> {
   // returns a Promise that is not the 'native' Promise implementation in node.
}

async function wrap() {
    return imported();
}

async function use {
    var value = await wrap();
    console.log(value);
}

Will this always print a string value or could it happen to be the Promise type returned by imported(). The awaiter code does some instanceof Promise checks. If it always prints the strings I think it would be more clear if async functions return a PromiseLike
I tested it with the Promise implementation form here https://github.com/then/promise and it returned a string.

@dbaeumer if you do it like this it should always work regardless of promise implementation:
function imported(): PromiseLike<string> {
   // returns a Promise that is not the 'native' Promise implementation in node.
}

async function wrap() {
    return await imported(); // 'unwraps' the PromiseLike and 're-wraps' as native promise
}

async function use {
    var value = await wrap();
    console.log(value);
}

@dbaeumer to add to the above, the instanceof checks in the awaiter should only relate to return values inside async functions, so that if a Promise<T> is returned it does not get wrapped into a Promise<Promise<T>>.
But the await operator should work with any A+ thenable regardless of what its specific implementation is. So return await x works with any thenable x.

@yortus  I know, but this might be error prone. And in C# I can always return the called async method without await which is very nice (and to my knowledge save some CPU cycles)

@dbaeumer Isn't it possible to just await a function returning a promise (no async marker)?
function delay(t: number): PromiseLike<void> {
		return new Promise<void>(resolve => {
			setTimeout(resolve, t);
		});
	}

	await delay(1000);

@dbaeumer Awaiting an A+ promiselike won't be error prone. If you're worried about the performance difference between return x and return await x, benchmark it and see. Given that async functions are downleveled to ES6 generators which V8 can't optimise, I think you'll find any performance difference very minor next to the slowdown due to the generator body not being optimised.

@yortus what I meant with error prone is that people might forget it (especially if they come from a C# background).

@dbaeumer if you are suggesting that the awaiter implementation should get rid of the instanceof checks on the return value and just check if it's something thenable, that might make sense. But I don't know if it's been drafted that way in the ES7 spec for some technical reason. I think @rbuckton would be the one to ask.

@dbaeumer I just took a look at the awaiter function, and you can definitely rely on return x to work the way you expect even if x is a non-native promise. The instanceof checks are just used to cast all awaited expressions to native promises before calling then on them.
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, Promise, generator) {
    return new Promise(function (resolve, reject) {
        generator = generator.call(thisArg, _arguments);
        function cast(value) { return value instanceof Promise && value.constructor === Promise ? value : new Promise(function (resolve) { resolve(value); }); }
        function onfulfill(value) { try { step("next", value); } catch (e) { reject(e); } }
        function onreject(value) { try { step("throw", value); } catch (e) { reject(e); } }
        function step(verb, value) {
            var result = generator[verb](value);
            result.done ? resolve(result.value) : cast(result.value).then(onfulfill, onreject);
        }
        step("next", void 0);
    });
};

In the awaiter code, the return value of the async function is passed directly to the resolve function of the async function's promise. The Promises A+ resolution procedure, which ES6 promises adhere to, ensures that a promise resolved with any thenable will resolve to that thenable's eventual value.
So you can definitely rely on the behaviour of return x you are talking about. x can be a non-native promise and it will never be double-wrapped. As for the compiler complaining about the PromiseLike annotation on an async function, I think that's an unnecessary restriction that the compiler could relax.

@jrieken await can only be used inside the body of an async function.

yeah, but being in an async-function isn't hard, right

@jrieken yeah probably not the hardest part of the problem  :-)

I think you already got the answer to this already, but just to be sure...

This might get complicated if you use two libraries which use different promise implementation. Then the code needs to wrap them.

However the cast method must not do an instanceof Promise check. Instead it would need to check for a then function. All the awaiter code needs right now is a then function.

The cast() function in the compiler-generated awaitet is actually superfluous. It could simply do Promise.resolve() and everything would work the same, since Promise.resolve will also check whether the value is a Promise or a thenable. (The former is an optimization of the latter; the latter is required).

Coming back to your OP, as @mhegazy said the reason your code is not allowed as-is is that the the return type of an async function is used for the promise constructor inside __awaiter - it's the third parameter. There's nothing which prevents you from using PromiseLike as the return type. You just need to satisfy the compiler's demand that it be usable as __awaiter's third parameter. This compiles just fine:
interface PromiseLike<T> {
	then<U>(onFulfilled: (value: T) => U, onRejected: (reason: any) => U): PromiseLike<T>;
}

declare var PromiseLike: {
	new<T>(resolver: (resolve: (value: T) => void, reject: (reason: any) => void) => void): PromiseLike<T>;
};

async function delay(millis: number): PromiseLike<void> {
    return Promise.resolve(undefined);
}

With a real promise implementation this would be provided by its .d.ts of course.
So I don't think there's any problem?

The __awaiter implementation is designed to support an async function returning any Promise/A+ compatible promise implementation. How you determine the type of Promise to return is through the return type annotation of the async function.
The reason __awaiter has a cast function, and does not rely on Promise.resolve is that Promise/A+ does not specify a Promise.resolve static method, and several Promise/A+ compatible libraries do not implement one. The cast function is designed to act in a fashion similar to the native Promise.resolve, which wraps any promise with a different prototype chain and constructor in an instance of the promise type on which resolve was called.
Please note that the Promise identifier in __awaiter is the on provided as the third argument to the call to __awaiter, which will be the constructor function referenced in the return type annotation:
async function fn(): MyPromise<number> {
  return 1;
}

becomes:
function fn() {
  return __awaiter(this, void 0, MyPromise, function* () {
    return 1;
  });
}

In this case, MyPromise is the value of Promise inside the __awaiter helper. If MyPromise is a non-native, Promise/A+ -compatible implementation without a static resolve method, then __awaiter will still be able to function as expected.
This approach was chosen to allow you to "Bring your own Promise" to async functions, whether that is a non-native promise implementation from a library, the native Promise implementation, or a subclass of a native Promise.
The reason PromiseLike cannot be used here, is that PromiseLike is a type-only declaration and cannot be expressed as a value at runtime. If you had:
async function delay(millis: number): PromiseLike<void> {
}

How would TypeScript know what kind of Promise to create here? We cannot rely on type inference for a return value here, as the value for some return types cannot be reached at the moment the function is called. That type may come from a call to a function defined in another module.
Instead, we can rely on the type specified in the return type annotation of the async function as you must be able to reference it in the same file (either through a global reference or an import), and therefore we can verify that we can express it as a value.

@Arnavion cast is not superfluous, it is part of the specified resolution procedure for await in the official specification. It also reduces the number of Promise allocations in instances where it is not needed.
Please note that return x and return await x in an async function are functionally similar, though return await x has slightly more overhead as it requires an additional step of the generator. The reason is that regardless of whether the return value of an async function is a promise or a non-promise value, it will be wrapped by the outer promise created by the async function.

@Arnavion: While your sample compiles fine, when you execute it at runtime you will get a TypeError since PromiseLike is undefined. The type must resolve to a valid constructor function at runtime, so that it can be created via new.

cast is not superfluous, it is part of the specified resolution procedure for await in the official specification. It also reduces the number of Promise allocations in instances where it is not needed.

This is what I meant by superfluous, that it's an optimization. Note that the spec uses NPC::resolve for the return value which also does not do constructor check, and is thus the same as unconditionally calling the constructor and using resolver.resolve with the value, not Promise.resolve(). (Only Promise.resolve does the constructor-check for the value.)

While your sample compiles fine, when you execute it at runtime you will get a TypeError since PromiseLike is undefined. The type must resolve to a valid constructor function at runtime, so that it can be created via new.

Of course. The point was that the OP's code is valid. They just didn't provide a constructor for their PromiseLike, and it's not that the compiler only supports Promise as the return type.

@Arnavion: After reviewing the latest version of the spec, you are correct that there will always be an allocation of a new promise. I will look into changing __awaiter to be more in-line with the current proposal.

Here's a possible shorter alternative that I may use:
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    return new P(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator.throw(value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : new P(function (resolve) { resolve(result.value); }).then(fulfilled, rejected); }
        step((generator = generator.call(thisArg, _arguments)).next());
    });
};

I've also changed the promise constructor argument from Promise to P so it is less likely to be confused with the native Promise constructor (I'm using an uppercase value here as some JS linters complain about using new with a non-uppercased function).

@rbuckton we should file an issue to track this modification.

@mhegazy, @Arnavion: I've filed #5941 to track this issue. We can continue any related discussion in that issue.

@Arnavion: I don't want to further confuse the topic. The lib.d.ts file already defines a PromiseLike (and PromiseConstructorLike) interface that the compiler uses to verify that a promise implementation is consistent with the needs of the __awaiter helper. I would not recommend co-opting PromiseLike for other uses, and I don't believe that was @dbaeumer's intent when he filed the issue.

@rbuckton I guess this issue does bring up the surprise factor that return type annotations behave differently for async functions than they do everywhere else in TypeScript, since they are used to pass a value to the awaiter and cannot be just a type as elsewhere.
For example I found it unintuitive that the following is an error, given the way annotations work elsewhere:
async function bar(): any { // Error: Type 'any' is not a valid async function return type
}

I think that also captures the surprise that PromiseLike can't be used as a return type annotation.
Given that 'bring your own Promise implementation' could be achieved by just passing the value of Promise that is in scope when the __awaiter(...) call is made, it seems an interesting choice to diverge from how annotations otherwise behave. Was there some reason to do it this way rather than just using whatever value of Promise is in scope?

@rbuckton When in future async/await is passed through as-is without downleveling to ES6, what will the 'bring your own Promise implementation' story be like then? I can't see how the return type annotation could be used in that case?

This aligns somewhat with the C# implementation of async/await in that an async function must return Task, Task, or void (though we cannot ensure the same semantics as C# for async...void). It also allows you to return a Promise subclass from async function.
Requiring a developer to alias their type as Promise is a high bar for entry, and prevents use cases where you might want to comingle both native Promises and subclasses in the same file.
We could consider falling back to Promise for compatible type-only declarations, but I can already think of a few corner cases where that could cause issues with a user's expectation versus what we emit. The current approach is more restrictive, which allows us to consider ways to relax these restrictions in the future without causing breaking changes.

@yortus: We can still support it by nesting the async function when necessary. Being able to supply the type of Promise to use for an async function is something I will discuss with the TC39 champion for async/functions.

Requiring a developer to alias their type as Promise is a high bar for entry, and prevents use cases where you might want to comingle both native Promises and subclasses in the same file.

Not really, it just has to be in scope when __awaiter is called, not necessarily the whole file. It's not ideal, but neither is using the return type annotation as a value. I was just curious about the trade-off.

We can still support it by nesting the async function when necessary.

Just wondering what would the emit look like? Do you mean something like this:
// file: foo.ts
async function foo(): MyPromise
    //...
}

// file: foo.js
function foo() {
   return new MyPromise(function (resolve, reject) {
       foo_1().then(resolve, reject);
    });

    async function foo_1()
        //...
    }
}

@rbuckton thanks a lot for the very good explanation how async and await works under the hood. Now that I understand it, it makes sense to me and the current implementation covers all my needs. Especially the one that we don't want to force a promise library onto others when implementing interfaces we spec.
However I would have never found out myself that the return type of a async function determines the Promise to use. In that regard I agree with @yortus.  May be it would be helpful to extend the error message with something like this: Type 'xxx' is not a valid async function return type. Valid return types are Promise/A+ compatible implementations.

+1 for better error message.

How about adding "everything you thought you knew about type annotations is wrong!"
Only half joking, since this feature uses type annotation syntax but behaves very differently.

@yortus the behavior here is consistent with other parts in the system, e.g. generators, and is consistent with use of other promise libraries and other languages. i know you filed #5945, but i do not see any new design points that were not available at the time this design decision was made, let a side being a breaking change.

the behavior here is consistent with other parts in the system, e.g. generators

@mhegazy can you clarify what you mean by this?

interface SomeIterator {
	next: Function;
}

interface SomePromise {
	then: Function;
}

function* gf(): SomeIterator { } // OK

async function af(): SomePromise { } // ERROR

How is this consistent?

More examples:
interface SomeIterator {
	next: Function;
}

interface SomePromise {
	then: Function;
}

// Generator functions
var genFuncRet1: SomeIterator = (function* () {})(); 		// OK: IterableIterator<T> is assignable to SomeIterator
var genFuncRet2: any = (function* () {})();          		// OK: IterableIterator<T> is assignable to any (duh!)
function* genFunc1(): SomeIterator { }                  	// OK: IterableIterator<T> is assignable to SomeIterator
function* genFunc2(): any { }                           	// OK: IterableIterator<T> is assignable to any (duh!)

// Async functions
var asyncFuncRet1: SomePromise = (async function () {})();	// OK: Promise<T> is assignable to SomePromise
var asyncFuncRet2: any = (async function () {})();          // OK: Promise<T> is assignable to any (duh!)
async function asyncFunc1(): SomePromise { }                // ERROR: Wut??
async function asyncFunc2(): any { }                        // ERROR: Surprise!

The behaviour here is not consistent with other parts of the type system, not even generators. Annotations on generators describe the JavaScript behaviour but don't change it. Annotations on async functions change the JavaScript behaviour, and give compiler errors (like above) when used to describe it.

As you mentioned, a gnerator function return type annoation is not the type of the item it iterates on, rather an iterator. similarly an async function return type annotation is not the type of the promised value, rather a promise.
This is also consistent with the normal type annotation, as the annotation is what the function returns, with no exceptions. an async function returns a promise, you can call it without an await and get the promise.
The other instances you reference go back to the down-level/promise library support, which is a unique aspect.

@mhegazy I recognise there are aspects that are consistent with other parts and have no problem with these aspects. Return value annotations must agree with what is actually returned - that's always been the case.
But its the nature of the inconsistencies that alarms me. For example:
// File: foo1.ts
import BluebirdPromise = require('bluebird');
export async function foo() { }

// File: foo2.ts
import BluebirdPromise = require('bluebird');
export async function foo(): BluebirdPromise { }

These two files differ only by a return type annotation. Yet they have different runtime semantics! This is an important departure for TypeScript from several of (what I thought were) it's key goals. Namely:

Type-annotating a function will never change it's runtime semantics (goal 7: "Preserve runtime behavior of all JavaScript code.")
Removing a function annotation will never change it's runtime semantics (also goal 7)
Removing all the annotations in a program will never change it's runtime semantics (goal 9: "Use a consistent, fully erasable, structural type system.")

Prior to v1.7 anyone interoperating with TypeScript code could rely on the above three statements, since all parts of TypeScript respected them and they are in fact written for all to see in the design guidelines and are widely regarded as a core concept of the language.
Now all three statements are false, with the arrival of this "unique aspect".
It's not simply a "unique aspect" - it's a significant departure from the design goals. Perhaps it seems like an insignificant corner case now, but in a few years when async functions are as widely used as ordinary functions, I think more users will be raising similar issues to the one raised by the OP here.

I am not sure i agree with these statements. there is a transformation taking place. the mere fact of putting "async" modifier on a function changes its semantics, and has a clear runtime impact. that is, in my opinion, similar to exporting a function.
Now, to make this transformation work we need a promise constructor. There are a few options:

a global Promise variable that is assumed to always exist.
a per function value, extracted from the return type annotation.

Each of these approach have its own pros and cons. @rbuckton has outlined some of these earlier. we can discuss this more, but i do not see how either would violate the design goals.

the mere fact of putting "async" modifier on a function changes its semantics

'async' is a JavaScript modifier, not a TypeScript type annotation! Of course it changes the runtime behaviour, that's expected. But can you see that just changing a type annotation and getting different Javascript code and behaviour is something completely new to TypeScript, and is in fact in conflict with statements like "[don't] emit different code based on the results of the type system." (non-goal 5).
A type annotation is a result of the type system - it is not JavaScript - ergo it should not emit different code!
Async function return type annotations are not erasable because that would potentially change runtime behaviour. That is not permitted in a "consistent, fully erasable, structural type system" (goal 9).

BTW regarding the two options:

a global Promise variable that is assumed to always exist.
a per function value, extracted from the return type annotation.

The current implementation is doing both of these isn't it? If no annotation is present it passes the identifier Promise to the awaiter function and assumes it exists.

While I'm still adamant that TypeScript should not be emitting different code based on a type annotation, I feel like I'm not getting very far making that case, so can I make a different suggestion?
Would it be possible to alter the current implementation so that it works as the OP expected? That is, if an async function has its return type annotated with 'just a type', not a class (e.g. the PromiseLike interface), then that should not be an error as long as the annotation is type-compatible with Promise, and such a function would return a standard ES6 Promise.
That would mean the following would be valid code:
async function foo(a: PromiseLike<number>, b: PromiseLike<number>): PromiseLike<number> {
    return await a + await b;
}

...and calling this function would return an ES6 Promise instance.
I think this could be done as a non-breaking change because it only affects cases that are currently compile errors.
The advantage of this would be that return type annotations on an async functions would work much the same as they do on normal functions and generator functions. It would resolve this issue and ones like it that are otherwise sure to come up from surprised users.

Would it be possible to alter the current implementation so that it works as the OP expected? That is, if an async function has its return type annotated with 'just a type', not a class (e.g. the PromiseLike interface), then that should not be an error as long as the annotation is type-compatible with Promise, and such a function would return a standard ES6 Promise.

for target ES3/ES5 i think this is more confusing that just using the type annotation. we should make the error message more expressive. for target ES6 and above, i do not see why not.

I tend to agree with @yortus that the current behavior is confusing since type annotation have an impact on the generated JS code. As you can see with #5998 the code generator doesn't handle this well either.

@dbaeumer, #5998 is a different issue. the import was not marked correctly, and was elided at emit time. this issue should be fixed in nightlies.

@dbaeumer, @mhegazy: Even if we changed the behavior for async functions to only use a "Promise" value that is in scope, we would still need to watch out for import elision. Consider:
import { Promise } from "promise";
export async function f() {}

We would still need to ensure Promise is not elided even though its only used in type position.

@yortus: If we were to drop the type-directed emit for the return-type annotation, there could be possible confusion for end users. Consider:
export class MyPromise<T> extends Promise<T> { }
export async function f(): MyPromise<T> { }

The above would still be legal, as we would check assignability of MyPromise<T> to Promise<T> as if MyPromise<T> were an interface, however:
console.log(f() instanceof MyPromise); // "false"

In C#, an async method must return Task, Task<T> or void. If we dropped the ability to support custom Promise types or Promise subclasses from an async function, then our only option would be to ensure that the return type must be Promise<T> to avoid possible confusion due to our structural type system. In that case, returning PromiseLike<T> would still not be legal.
If we wanted to be very strict about the return type, then we wouldn't even allow local redeclaration of Promise, and would only allow the use of a global Promise. I still contend that this would make it harder for developers to use async functions in a down-level host once we support down-level emit for generators.

for target ES3/ES5 i think this is more confusing that just using the type annotation. we should make the error message more expressive.

@mhegazy yes right, for ES3/ES5 it would be better to error since there is no builtin 'Promise'.

for target ES6 and above, i do not see why not.

hardly a ringing endorsement :) But I really hope this can be done for consistency's sake.

I tend to agree with @yortus that the current behavior is confusing since type annotation have an impact on the generated JS code.

@dbaeumer its not the confusion so much that bothers me, it's that it doesn't seem to reconcile with TypeScript's own design goals. I'm astounted that there hasn't been any direct response to this so far. The goals are clear - types should not change emitted code, and the type system should be fully erasable. The current implementation disregards both of these goals in its treatment of return type annotations. It would be nice at the very least for someone to acknowledge this. Maybe they are just general guidelines and not strict rules. That's fine - please just someone say something to the community about this.

We would still need to ensure Promise is not elided even though its only used in type position.

@rbuckton good point, this also applies to custom promises and promise polyfills in the current implementation - just filed #6003 for this.

@rbuckton you say users would be confused by this:
export class MyPromise<T> extends Promise<T> { }
export async function f<T>(): MyPromise<T> { }

console.log(f() instanceof MyPromise); // "false"

OK, this could be confusing for users who think that return type annotations affect runtime behaviour - which given that TypeScript's type system is supposed to be completely erasable should be nobody. But let's say it is confusing for argument's sake. Here is the same code slightly modified to use generator functions instead:
export class MyIterator<T> implements Iterator<T> {/***/}
export function* f<T>(): MyIterator<T> { }

console.log(f() instanceof MyIterator); // "false"

Shouldn't this be just as confusing by the same argument? If this is not confusing, isn't that because users know that return type annotations do not actually modify the generated code?

If we dropped the ability to support custom Promise types or Promise subclasses from an async function

I don't think anybody is suggesting dropping this support.
Anyway what you think of the suggestion here: https://github.com/Microsoft/TypeScript/issues/5911#issuecomment-162866988? This would give:
export class MyPromise<T> extends Promise<T> { }
export async function f<T>(): MyPromise<T> { }

console.log(f() instanceof MyPromise); // "true"

...because MyPromise is a class (ie exists in both type and value spaces) - so that would be handled exactly as it is currently. Then this example:
export async function f<T>(): PromiseLike<T> { }
console.log(f() instanceof Promise); // "true"

...would compile and work - because PromiseLike<T> is only a type (ie exists in type but not value space), so this would be a normal async function (ie not using custom promise) and the return type annotation would just need to be compatible with Promise.

our only option would be to ensure that the return type must be Promise<T> to avoid possible confusion due to our structural type system. In that case, returning PromiseLike<T> would still not be legal.

Here is this logic, as I understand it, expressed as a function:
function f(): PromiseLike<number> {
	return Promise.resolve(42);
}

It compiles just fine. The return value is a Promise<T> and the return type PromiseLike<T> is legal. So there shouldn't be any problem annotating PromiseLike<T> on an async function that returns a Promise<T>.

@mhegazy, @rbuckton What do you think of the following minor change to async function parse/emit to address this issue? It's a non-breaking change and it makes type annotations on async functions consistent with how they behave for ordinary and generator functions.
Given this sample code
async function foo(): P {/***/} // or if no annotation, treat P as Promise<any>

Current compiler behaviour pseudocode, with proposed additional logic
let isPromiseType = P is assignable to PromiseLike<any>
let isPromiseConstructor = typeof P is assignable to PromiseConstructorLike

if (isPromiseType) {

        if (isPromiseConstructor) {

                // use P as custom promise type in emit
                emit async function with `P` as third argument to `__awaiter`

                return
        }

        // <========== PROPOSED ADDITIONAL LOGIC ==========>
        else if (target >= ES6) {
                // P is not a constructable promise, but it is a promise-like type
                // use builtin Promise class in emit
                emit async function with `Promise` as third argument to `__awaiter`

                return
        }
        // </========== PROPOSED ADDITIONAL LOGIC ==========>
}

// If we fall through to here...
generate compiler error `"Type 'P' is not a valid async function return type"`

Results:
class CustomPromise extends Promise<any> {}
class FooBar {}
interface Thenable {
    then(onfulfilled?: (value) => any, onrejected?: (reason) => any): Thenable;
}

async function f1() { }                 // OK, returns a builtin Promise
async function f2(): CustomPromise {}   // OK, returns a CustomPromise
async function f3(): FooBar {}          // ERROR: 'FooBar' is not a valid async function return type
async function f4(): Thenable {}        // OK, return type is Thenable, returns a builtin Promise
async function f5(): any {}             // OK, return type is any, returns a builtin Promise
async function f6(): number {}          // ERROR: number is not a valid async function return type

Note f4 and f5 are currently errors but would be valid with this proposed change.

// P is not a constructable promise, but it is a promise-like type

@yortus, the proposal above is actually a type-directed emit. The emit logic, in this proposal, depends on whether the type checker managed to correctly resolve the type from the type annotation, and correctly identified that it is constratable.
This breaks the transpile scenarios, where the compiler has access only to one file at a time. For these scenarios the transformation done by the emitter is expected to be a pure syntactic transformation on a file-level with no involvement of the type system what so ever. .d.ts files are not even loaded, even lib.d.ts is not loaded.
You have referred to the current implementation as "type-directed" emit. That is not correct. The current implementation will always emit the same output regardless of the return type, whether it is defined or not, whether the type checker resolved it correctly or not, or whether it is a single file transformation or a whole program compilation. This is one of the axioms that we have strived to maintain and have rejected a lot of proposals that will contradict it.
Just to elaborate, type-directed emit means that the emitted code for a given input is based on the view of the type system. if the type system thinks of a name as a number, it will emit it differently from if it thought it was a string.
The async function transformation has nothing to do with the type system, it is purely syntactic. it is however, type-annotation specific emit. for that, i do not see the problem, and i do not see how that is significantly different from using the value "Promise" from the current scope.

This breaks the transpile scenarios, where the compiler has access only to one file at a time.

This finally might explain something about why we seem to be at such cross purposes. Can you please confirm if I have understood the implications of this. Suppose the compiler needs to emit code for async (): M => {} but doesn't know what type M is. The current implementation always emits M, leaving the question of validity of M in that type position to the checker. OTOH what I have proposed above needs to emit M if M is a constructable promise type, but if M is just an interface it needs to emit Promise instead. But it doesn't have information about M's type so it can't know what to emit.
Is that what you mean?
This may clear up a few things. I've been looking from an 'in principle' perspective. I.e. in principle, PromiseLike<T> is a valid type annotation for any function returning a Promise<T>, regardless whether it's (): PromiseLike<any> => Promise.resolve(42) or async (): PromiseLike<any> => 42. I mean in principle. There exists a compiler implementation that can do this. It is consistent with type theory.
OTOH I think you are speaking from an implementation perspective. The way the TypeScript compiler is structured, and which parts have access to which information at which time, and what compiler options must be supported (eg single file parse/emit) all constrain the possibilities in practice.
Would that be a fair assessment? I hope so because it has been very frustrating (I'm sure for you too) trying to understand the objections to supporting syntax like async (): PromiseLike<any> => 42, and why function* (): any {} is valid but async function (): any {} is an error.

The current implementation will always emit the same output regardless of the return type

If you mean the return type annotation, what about #6007?

You have referred to the current implementation as "type-directed" emit. That is not correct.

I just adopted that phrase because that's how @rbuckton and @DanielRosenwasser describe it here and here. Given #6007, I think it needs some special name because no other features emit different code when you remove a type annotation AFAIK.

+1
I met this issue in my scenario. My tsconfig is set to AMD(typescript 1.7.5) and my code is like this:

'use strict';

import { TPromise } from 'base/TPromise';

export class MyClass {

    async f1(): TPromise<number> {
        await this.use();
        return new TPromise<number>((c,e,p)=> {
            c(2);
        });
    }

    async use(): TPromise<string>{
        return new TPromise<string>((c,e,p)=> {
            c('abc');
        });
    }
}

And it will generate:
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, Promise, generator) {
    return new Promise(function (resolve, reject) {
        generator = generator.call(thisArg, _arguments);
        function cast(value) { return value instanceof Promise && value.constructor === Promise ? value : new Promise(function (resolve) { resolve(value); }); }
        function onfulfill(value) { try { step("next", value); } catch (e) { reject(e); } }
        function onreject(value) { try { step("throw", value); } catch (e) { reject(e); } }
        function step(verb, value) {
            var result = generator[verb](value);
            result.done ? resolve(result.value) : cast(result.value).then(onfulfill, onreject);
        }
        step("next", void 0);
    });
};
define(["require", "exports", 'base/TPromise'], function (require, exports, TPromise_1) {
    'use strict';
    class MyClass {
        f1() {
            return __awaiter(this, void 0, TPromise, function* () {
                yield this.use();
                return new TPromise_1.TPromise((c, e, p) => {
                    c(2);
                });
            });
        }
        use() {
            return __awaiter(this, void 0, TPromise, function* () {
                return new TPromise_1.TPromise((c, e, p) => {
                    c('abc');
                });
            });
        }
    }
    exports.MyClass = MyClass;
});

TPromise is just like PromiseLike, it is another promise implementation which I grabbed from vscode(winjs).
So the error message is:
TPromise is undefined
In my case, it should generate something like (focus on TPromise_1.TPromise part)
 return __awaiter(this, void 0, TPromise_1.TPromise, function* ()

We unfortunately cannot loosen the restriction around the return type annotation of an async function, as there may be existing user code that relies on the return type annotation pointing to a type that also has a reachable constructor value of the same name.
As of #6631 we are further restricting the return type annotation of an async function in ES6 or higher to be only Promise<T>. The rationale for that decision can be found here: https://github.com/Microsoft/TypeScript/pull/6631#discussion_r51040975.

I am closing this issue based on our current plans to restrict the return type annotation to only Promise<T>. We may reinvestigate this issue in a later release.

I've read through a bunch of these issues, and I have to raise this flag again.
Just now I installed 2.2 dev and I'm getting this error.  I understand the concerns about how specifying the actual promise that ends up getting used is a good choice.  I also understand how the awaiter works.
I have my own Promise lib.  And I still don't see the value in making this more restrictive.
The PromiseLike interface is... Well something should be available that is more generic IMO.


chore: SpendableNoteUndecoded + bench SpendableNote decoding  (PoC)

As a part of #4923 I wanted to see if decoding SpendableNote is indeed slow, and how much could we save if we skipped decoding of the signature using an alternative parallel type.
     Running benches/divan.rs (target-nix/release/deps/divan-2d8a606864c20c66)
Timer precision: 20 ns
divan                               fastest       │ slowest       │ median        │ mean          │ samples │ iters
├─ spendable_note_decode            93.5 µs       │ 188 µs        │ 94.32 µs      │ 96.49 µs      │ 100     │ 100
╰─ spendable_note_undecoded_decode  14.79 µs      │ 24.49 µs      │ 14.88 µs      │ 15.11 µs      │ 100     │ 100

Seems like decoding seem to be orders of magnitude less than what was suspected, in the range of 100us, which even with hundreds of notes should not be a huge problem.
Using an alternative type is indeed significantly faster. It wouldn't be a lot of effort to use it tactically e.g. when reading all notes for the purposes of using TieredCounts instead of "streaming notes" in #4923.
But given how relatively small numbers we see here, and how infrequent note selection is in practice, I'm not sure if it's worthwile.
You can try it yourself by running cargo bench, let me know what you think.

@elsirion @douglaz , as we have been discussing note consolidation PR #4922

How do you like using divan? I played around with criterion in #4953 a bit, also works. I think we should get the benchmarks even if we end up not doing the delayed decoding.

I usually go with criterion, but heard about about divan at some point and wanted to try it out. Criterion does bunch of extra stuff like html graphs, and storing previous runs under ./target/critterion which is useful... sometimes. Divan has a nicer derive macro and they say that they have better support for stuff like generics. By default it's also much faster, while criterion wants to run everything for many seconds (there are options to make it go faster). I don't have a strong preference either way.

https://github.com/nvzqz/divan/issues/43 ehh, divan doesn't seem compatible with cargo nextest ...

@elsirion Converted to criterrion and cherry-picked your decoding benches in  #4955 . Another commit, because I'm switching to jj and I'm still lame using it.


Projects with same name don't work.

Environment data
dotnet --info output:
.NET SDK (reflecting any global.json):
 Version:   5.0.402
 Commit:    e9d3381880

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  20.04
 OS Platform: Linux
 RID:         ubuntu.20.04-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.402/

Host (useful for support):
  Version: 5.0.11
  Commit:  f431858f8b

.NET SDKs installed:
  5.0.402 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.11 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.11 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

VS Code version: <IP_ADDRESS>
C# Extension version: v1.23.16
OmniSharp log
Starting OmniSharp server at 10/30/2021, 2:43:58 PM
    Target: /home/shadowblitz16/Documents/dev/cs/AstroWars/AstroWars.sln

OmniSharp server started.
    Path: /home/shadowblitz16/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/run
    PID: 76296

[info]: OmniSharp.Stdio.Host
        Starting OmniSharp on ubuntu 20.4 (x64)
[info]: OmniSharp.Services.DotNetCliService
        Checking the 'DOTNET_ROOT' environment variable to find a .NET SDK
[info]: OmniSharp.Services.DotNetCliService
        Using the 'dotnet' on the PATH.
[info]: OmniSharp.Services.DotNetCliService
        DotNetPath set to dotnet
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Located 1 MSBuild instance(s)
            1: StandAlone 17.0.0 - "/home/shadowblitz16/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin"
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        MSBUILD_EXE_PATH environment variable set to '/home/shadowblitz16/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin/MSBuild.exe'
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Registered MSBuild instance: StandAlone 17.0.0 - "/home/shadowblitz16/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin"
            CscToolExe = csc.exe
            MSBuildToolsPath = /home/shadowblitz16/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin
            CscToolPath = /home/shadowblitz16/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin/Roslyn
            BypassFrameworkInstallChecks = true
            MSBuildExtensionsPath = /home/shadowblitz16/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild
[info]: OmniSharp.WorkspaceInitializer
        Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpFormattingWorkspaceOptionsProvider, Order: 0
[info]: OmniSharp.WorkspaceInitializer
        Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.Completion.CompletionOptionsProvider, Order: 0
[info]: OmniSharp.WorkspaceInitializer
        Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.RenameWorkspaceOptionsProvider, Order: 100
[info]: OmniSharp.WorkspaceInitializer
        Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.ImplementTypeWorkspaceOptionsProvider, Order: 110
[info]: OmniSharp.WorkspaceInitializer
        Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.BlockStructureWorkspaceOptionsProvider, Order: 140
[info]: OmniSharp.Cake.CakeProjectSystem
        Detecting Cake files in '/home/shadowblitz16/Documents/dev/cs/AstroWars'.
[info]: OmniSharp.Cake.CakeProjectSystem
        Could not find any Cake files
[info]: OmniSharp.MSBuild.ProjectSystem
        Detecting projects in '/home/shadowblitz16/Documents/dev/cs/AstroWars/AstroWars.sln'.
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/home/shadowblitz16/Documents/dev/cs/AstroWars/Game/Project.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/home/shadowblitz16/Documents/dev/cs/AstroWars/GameSharp/Project.csproj'
[info]: OmniSharp.Script.ScriptProjectSystem
        Detecting CSX files in '/home/shadowblitz16/Documents/dev/cs/AstroWars'.
[info]: OmniSharp.Script.ScriptProjectSystem
        Could not find any CSX files
[info]: OmniSharp.WorkspaceInitializer
        Configuration finished.
[info]: OmniSharp.Stdio.Host
        Omnisharp server running using Stdio at location '/home/shadowblitz16/Documents/dev/cs/AstroWars' on host 76111.
[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: /home/shadowblitz16/Documents/dev/cs/AstroWars/Game/Project.csproj
[info]: OmniSharp.MSBuild.ProjectManager
        Successfully loaded project file '/home/shadowblitz16/Documents/dev/cs/AstroWars/Game/Project.csproj'.
[info]: OmniSharp.MSBuild.ProjectManager
        Adding project '/home/shadowblitz16/Documents/dev/cs/AstroWars/Game/Project.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: /home/shadowblitz16/Documents/dev/cs/AstroWars/GameSharp/Project.csproj
[info]: OmniSharp.MSBuild.ProjectManager
        Successfully loaded project file '/home/shadowblitz16/Documents/dev/cs/AstroWars/GameSharp/Project.csproj'.
[info]: OmniSharp.MSBuild.ProjectManager
        Adding project '/home/shadowblitz16/Documents/dev/cs/AstroWars/GameSharp/Project.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Update project: Project
[info]: OmniSharp.MSBuild.ProjectManager
        Update project: Project

Steps to reproduce

Have two projects with the same filename in differently named folders
Have one project referencing the other
Have a solution in which they have difference explicit names
Open sln folder in vs code with omnisharp plugin enabled.

Expected  behavior
It loads the projects properly

Actual behavior
It fails to load one of the projects.

A lot has changed with O# project loading since this issue was opened. If you are still having problems, please open a new issue at https://github.com/omnisharp/omnisharp-roslyn/issues


Progress updates for compute intensive functions

Is your feature request related to a problem? Please describe.
There are a number of functions in the clustering/spatial LDA processing that can take a long time. Some of them have progress bars, some of them print updates every 10 FOVs, and some of them have no output tracking. This makes it hard to know how long something will take
Describe the solution you'd like
We should standardize the way runtime info is displayed. There are two important pieces of information.

How much progress has the function made
How much time has elapsed, and how much time is remaining

If the tqdm library can handle both of these for us, then that's great. I don't remember the exact issue with time estimate in the deepcell function, but if it's not accurate than it's not helpful to include. Instead, we can print elapsed time after set intervals.

How many of these still need a progress bar?

@ngreenwald we now print out an update every 5 FOVs or so, for the cohort you tested on MIBIAN how long did it take to print out each update. If it's a significantly long time, perhaps we can consider adding a progress bar to each intermediate step too.

So all of the pixel/cell clustering has either a progress bar or printed out FOV numbers? Is there anything in spatial LDA, KNN, etc that still needs this?

Spatial LDA will definitely need a second look at because of how long it takes, I don't remember if Calico updated their training function to display progress so I'll look into this over the weekend.
KNN I'm assuming refers to neighborhood analysis? It's been a hot while since I've run that notebook, I remember it not taking a very long time to run on the tests I did, but I'll look into this one as well just in case.

Spatial enrichment doesn't have a progress bar currently; I can add one to the batching version this weekend, since those are the ones called by users anyways.

Per discussions with @ngreenwald and @cliu72, we'll need to add the following progress bars:

The EDA calculation in the spatial LDA preprocessing notebook
The KMeans clustering in neighborhood analysis. This point will require more discussion because silhouette score is prohibitively slow for massive cohorts. @cliu72 and I will be discussing a subsetting method.

Talk to @ackagel, he did some work on the cluster evaluation for the spatial LDA preprocessing notebook. We should standardize across both notebooks if possible, and be consistent about what metrics we use

@cliu72 if the updated KMeans clustering in neighborhood analysis runs quickly with the new method, I can leave out the tqdm bar for that.

We will need to open a PR to address adding progress bar updates for compute_cluster_metrics_inertia and compute_cluster_metrics_silhouette in the neighborhood analysis notebook.


Crash on pressing "cc" in query window

bug description
When I type "cc" in the query window, rainfrog crashes.
technical details
system info

Ubuntu 20.04, kernel 5.4.0-181-generic
rainfrog 0.2.0-VERGEN_IDEMPOTENT_OUTPUT (2024-09-17)

crash logs
name = "rainfrog"
operating_system = "Ubuntu 20.4.0 (focal) [64-bit]"
crate_version = "0.2.0"
explanation = """
Panic occurred in file '/home/mmior/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rainfrog-0.2.0/src/vim.rs' at line 344
"""
cause = 'called Result::unwrap() on an Err value: Unknown { .. } - "Unknown error while interacting with the clipboard: X11 server connection timed out because it was unreachable"'
method = "Panic"
backtrace = """
0: 0x556eb246eddb - rainfrog::components::editor::Editor::transition_vim_state::h3d20a324e016faeb
1: 0x556eb2469670 - <rainfrog::components::editor::Editor as rainfrog::components::Component>::handle_events::h8f0e2253b14231bc
2: 0x556eb25372c3 - rainfrog::app::App::run::{{closure}}::he0d0e37f1050d599
3: 0x556eb2527cb5 - tokio::runtime::runtime::Runtime::block_on::h7a11a1e1f1e03fdf
4: 0x556eb24f508f - rainfrog::main::h95949b0ba75cec25
5: 0x556eb259d463 - std::sys::backtrace::__rust_begin_short_backtrace::h0cf30c58468529e8
6: 0x556eb24f4ca2 - main
7: 0x7f649a4aa083 - __libc_start_main
at /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308
8: 0x556eb2255fee - _start
9:        0x0 - """

### steps to reproduce
Steps to reproduce the behavior. If possible, include the preceding query with sensitive information removed:
1. Press Alt+2 to go to the query window
2. Press cc

thanks for reporting; looks like it might be an issue with the clipboard manager: https://github.com/1Password/arboard/issues/153
will investigate

i was able to reproduce in a vm; it looks like extending the timeout for creating the Clipboard instance might help (https://github.com/1Password/arboard/pull/147), so i will try that later to see if that's the issue or if there's a different root cause
in the meantime, i have a pr to fallback to using the textarea's buffer instead of panicking: https://github.com/achristmascarl/rainfrog/pull/81

@achristmascarl Thanks! Confirmed that PR prevents the panic on my machine.

great! i'll close this for now, and continue tracking the X11 clipboard timeout here: https://github.com/achristmascarl/rainfrog/issues/83


feat: signers

Adds signers page.
Figma file - https://www.figma.com/file/31q1g27k69z1yXb6r6vrRD/Stacks-Explorer-Working-File?node-id=6378%3A8913&mode=dev
Currently using fake data. Waiting for the API to finish work on signers data endpoints. Slack context here https://hiropbc.slack.com/archives/C03UFUA5Q65/p1708373349155149
Work remaining:

[ ] Add href to

[ ] Add API request for signers and staking information to power the signer table

[ ] Hook up the Voting Power Sort Filter with the Signer List

[ ] Also use API request for signers and staking information to power Addresses Stacking header card

Great start!
Here are some things that I am seeing:
1- The figma has a 6-column grid where the first box takes 2 spaces. The implementation has a 5fr grid

2- Maybe we can build an example of a row with more than one address

Looks awesome @BLuEScioN ! I only have some minor UI/color comments:
Top stats

[ ] Arrow: Can it be green-600 / green-500 when up, and red-600 / red-500 when down?

[ ] Progress bar colors:
For Stacking cycle circle, can you please update the stroke width to 4px and the slate color to purple-200? (apologies for this as I changed it later in the design)

In dark mode, this color should be different:

Table header tags

[ ] Replace text "STX staked" for "STX stacked"
[ ] Font spacing: It looks more spaced in the implementation than in the design, I think it doesn't have the -1% letterspacing as set in the UI theme

Table

[ ] The list starts at #0, I think it should start at 1

[ ] Both Signer key and Address should have a hover underline (that'll link to Signer ID, and Address ID)

[ ] Address font-color should be slate-700 (light mode), slate-600 (dark mode)

[ ] Would it be possible to center-align the first column? (rank numbers)

[ ] Would it be possible to have that first column sticky on mobile horizontal scroll?

For "See Stacking historical data", I think it's better to hide until we have a Stacking page (WIP)

The list starts at #0, I think it should start at 1

I am using test data. This can be fixed when we are getting data from the API

Would it be possible to center-align the first column? (rank numbers)

This can be done, yes, although it requires a bit of additional rework. I did not get to this fyi cc @He1DAr

Would it be possible to have that first column sticky on mobile horizontal scroll?

I think so. The work required for this would probably overlap with the work for "Would it be possible to center-align the first column? (rank numbers)". I also did not get to this fyi @He1DAr


Guideline on height of in-meeting dialog is misleading

This can be interpreted as saying that the height of the dialog automatically expands along with the content, which is NOT the case. The developer MUST specify the height of the content in the URL for the in-meeting dialog, and we will honor that up to the maximum height.
This is basically the same how we handle the width-- honor the value specified, up to the max width.
Please clarify this, and also let's try to describe the height and width in the same way, to avoid confusion.

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

ID: 09c05a14-d442-bcd1-f233-1beeddfd4bb1
Version Independent ID: eb958ded-39dc-c0ab-a7c8-2d5bf334ab16
Content: Designing your meeting extension - Teams
Content Source: msteams-platform/apps-in-teams-meetings/design/designing-apps-in-meetings.md
Product: msteams
GitHub Login: @heath-hamilton
Microsoft Alias: lajanuar

@aosolis , Yes, height and width specified for in-meeting dialog while forming the URL, we generally made them as constant and read it to update the URL, the best way to define height & width in constant file and use those values in externalResourceURL of in-meeting dialog

Closed with PR #2902


Dev cleanup dispersion data

Main additions:

Number of GeoServer layers is kept to 20 by default to keep GeoServer performance reasonable, also specified via NUMBER_OF_LAYERS in AermodAgent.

Added NUMBER_OF_LAYERS parameters in DispersionInteractor that specifies the number of timesteps to show in the dispersion dropdown, should ideally match the number specified in AermodAgent

Added a route in ShipInputAgent to clear old data, via the /clear-old-data route

Added IGNORE_BUILDINGS flag in AermodAgent when the buildings dataset is too large and slows down the simulation

Limit number of process in AermodAgent to 1, in case of duplicate requests to updateDerivation when the previous request is still executing

Limit number of process in UpdateVirtualSensors route in DispersionInteractor, to prevent duplicate requests from the visualisation

When ship data are deleted (/clear-old-data), the ship layer still shows up in visualisation despite all ship data were supposedly deleted.

This is intentional, the ships layers are created by the Aermod agent and only stored in 1 table, hence they can be easily deleted manually if needed. The ships data is very difficult to clear without resetting the database


citing use of package

Do you have a preferred citation we should use in publications if we display results of brain figures using hcp-utils?

Thanks! I am really glad that it's useful.
Please cite the github URL of the package.
Btw. I would be happy if at some stage you could e-mail me your paper..

Yes, once it has been accepted, we will share the paper. Do you know if there is a way to generate half of the 3D brain image to plot the subcortical parcels? We are trying to edit the source code in hcp_utils.py to only show the left hemisphere and the corresponding left parcels. We are wondering if we could edit the function load_surfaces and do something similar to below:
for hemisphere, hemisphere_name in [('L', 'left')]:
     elif count==1:
                #meshes[variant] = meshes[variant+'_left']

You mean subcortical? Then there is no way using hcp_utils as it uses nilearn's surface plot which plots only cortical surfaces (as I discussed in the other issue).
I now remember that once I made some 3d plot with subcortical structures using matplotlib 3d but that was rather ugly and slow. I do not know if I can locate the script...


chore: prep for 3.1.0 release

Summary of Changes
Add RELEASE.md and prep for 3.1.0rc1

Oops, forgot to rm the news fragment fikes.


build github.com/360EntSecGroup-Skylar/goreporter: cannot load golang.org/x/tools/go/gcimporter15

build github.com/360EntSecGroup-Skylar/goreporter: cannot load golang.org/x/tools/go/gcimporter15

golang.org/x/tools/go/gcimporter15 has not been found
new path: golang.org/x/tools/go/gcexportdata

Same problem @wgliang
build github.com/360EntSecGroup-Skylar/goreporter: cannot load golang.org/x/tools/go/gcimporter15: module golang.org/x/tools@latest (v0.0.0-20200228224639-71482053b885) found, but does not contain package golang.org/x/tools/go/gcimporter15

According to gcimporter · pkg.go.dev gcimporter has been deleted since October 2017.
I solve this problem by Installing multiple Go Version.
go get golang.org/dl/go1.8
go1.8 download
go1.8 get -u github.com/360EntSecGroup-Skylar/goreporter


Update sbt-scalafmt to 2.4.3

Updates org.scalameta:sbt-scalafmt from 2.4.2 to 2.4.3.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "sbt-scalafmt" } ]

labels: sbt-plugin-update, semver-patch

Codecov Report

Merging #164 (c5ad5d1) into main (d32d2c0) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #164   +/-   ##
=======================================
  Coverage   70.00%   70.00%
=======================================
  Files           4        4
  Lines          80       80
  Branches        4        4
=======================================
  Hits           56       56
  Misses         24       24

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 d32d2c0...c5ad5d1. Read the comment docs.


AUDIO tag stops SAFE Browser from rendering

Operation System: Linux 64-bit
Beaker Version: ??
SAFE Browser Version: 0.6.0 (alpha-2)
Notes: I'm using mocknet. Compiled and run with NODE_ENV=dev.
Problem
If I include an AUDIO tag (from the HTML5 standard), the SAFE Browser will load that page correctly, then it will not render any new pages or reload any previously loaded pages. Existing pages continue to render.
I have evidence that the page does execute but does not render. This is based on the dev tools, which shows the full set of page contents as being populated. Additionally, an AUDIO tag set to autoplay will play even when the HTML is not rendered.
I see this problem with both file:// and safe:// protocols.
Steps to reproduce

Grab any mp3 file. I'm using a small one that is only a few seconds long. Name the file file.mp3.
Save below text as an HTML file alongside file.mp3.
Open the HTML file in the SAFE Browser using file://. It will load. (Optionally: upload the two files using web hosting manager and open it using safe://, the result will not change)
Create a new tab. Reload previously open tabs. Open the HTML file over again. None render.

HTML file:
<!DOCTYPE html>

    <META CHARSET="utf-8"/>
    <META NAME="viewport" CONTENT="width=device-width, initial-scale=1.0">
    <TITLE>Music Player</TITLE>

Back to splash.

    <AUDIO src="file.mp3" controls="true"></AUDIO>

More info
Once the rendering stops, Window > Developer Tools > Reload Shell Window causes the whole window to go blank outside the menu (all tabs are lost).
Closing and restarting the SAFE Browser will allow the browser to render again... an AUDIO tag shows up.
Related issues
I searched both https://github.com/beakerbrowser/beaker/issues and https://github.com/electron/electron/issues for issues related to Audio tags, but could not find any case in which the rendered display was relevant.

Thanks for bringing it up to our notice. However, this seems to be a chromium related issue which ripples in electron. Here is the link to the issue . We will check into the issue certainly and figure out what best we can do. Thanks again!

@krishnaIndia Reading through that ticket, it would appear the issue is specifically that AUDIO or VIDEO tags don't work.
In the case reported here, the AUDIO tag does work: the mp3 audio plays just fine.
After loading a page successfully, however, the SAFE Browser will not render any pages (even those with no AUDIO tag).

@btbonval, I get you now. A similar issue was also reported previously in one of the testnets. We will try to reproduce this at our end and resolve.

@btbonval what flavour of linux are you running?

Linux Mint 18.1 which appears to be based on Ubuntu 16.04.

I wanted to highlight more of my workflow and version numbers, since @joshuef and I are running similar operating systems.
For the original error report above, I was using the alpha-2 tag with commit 5cc7965d47f5036296e49f4a7ef3dec5e5fc43c3. However, someone changed the beaker-plugin-safe-app-0.3.0.tgz file without updating the file version or file name, so alpha-2 doesn't work anymore:
error https://s3.eu-west-2.amazonaws.com/beaker-plugin-safe-app/beaker-plugin-safe-app-0.3.0.tgz: Fetch succeeded for undefined. However, extracting "https://s3.eu-west-2.amazonaws.com/beaker-plugin-safe-app/beaker-plugin-safe-app-0.3.0.tgz" resulted in hash "93ff8377180dc84c046b8598a15b9cd61190437a", which did not match the requested hash "496a9b46ffc32e050a5a636629dc4bd23d656de5".

Side note: please update version numbers when changing a file or append the hash onto the file name. It really helps keep things consistent between source repos and static file hosting. Appending the hash to file names is common for CDN files to avoid similar out-of-sync problems between e.g. HTML and CSS, JS and HTML, or two JS files, which might be updated independently.
Just like with web_hosting_manager, the solution was to ditch the tag and switch to master.
So now I'm using safe_browser master with commit bf21e5eb76499369b728178282861a0c2477bd3b with a fresh compiled version of the browser.
I'm using the following versions:

nvm 0.33.4
node 7.10.1
yarn 1.0.2

My build process:
export NODE_ENV=dev
yarn upgrade
yarn burnthemall
yarn run package
tar -czf safe_browser-0.6.0-bf21e5eb-dev.tgz dist/

There's an intermediary step here because I sandbox dev from testing as a matter of personal practice. I move the tgz to a new system.
tar -xzf safe_browser-0.6.0-bf21e5eb-dev.tgz dist/
export NODE_ENV=dev
./dist/linux-unpacked/safe-browser

To keep the replication steps as simple as possible:

I loaded the browser
Did not login
Clicked File > Open File
Chose the html file with an AUDIO tag
Did not play the audio nor have the audio set to autoplay (it opened just fine and looked correct)
Opened a new tab: tab was blank and did not render the usual tab screen.

Thanks for the detailed updates!
One note on your build process, you want to have a yarn build step before you package, as this will update bundles js.

I have evidence that the page does execute but does not render.

If this is the case, it could well be that you're hitting a browser tab/webview issue. There's been some problems with electron webviews not rendering properly. Perhaps you can try increasing z-index of the webview via devtools of the browser (or tweaking some other css)?

Sorry to say, @btbonval we don't support mint at the moment.  We don't have a system to test against so I can't dig deeper. (As noted, everything worked as expected on Ubuntu 16.)
I'll leave this open for now incase you're able to debug the browser tabs via devtools 👍
Thanks @btbonval

Thanks for the feedback, @joshuef .
I thought yarn burnthemall included yarn build. I'll double check that.
The good news is that the problem isn't reproducible ;)  That means, generally, an app with AUDIO should work for most people, and it can be tested even when this error is present, it just requires restarting the browser sometimes.
The dev tools show up. I can even inspect the HTML, but nothing on the page highlights. I'll try changing the z-index as an experiment.
However, if I use Reload Shell Window after an AUDIO tag is used, all actual the tabs disappear and the window is only left with its title and the menu. It amplifies the problem. Hard to imagine that's related to z-index, but I don't really know what reloading the shell window does.
I'll post any experiment results here.

Reload Shell Window is actually reloading the whole electron app/user interface so yeh, that's going to be a hard refresh on everything.
Even your devtools would be destroyed as the BrowserWindow electron element which it is attached to is destroyed.

I'm closing this now as we are not supporting Mint for the moment. Please feel free to re-open it if this issue is seen still in the supported platforms though.


Can not add second Slack account

Reported by pla on 16 Jul 2015 12:20 UTC
When I scan the QR for a second Slack (https://slack.com/) account FreeOTP doesn't add a new entry. FreeOTP seems to think it is the same as the first Slack account (guessing). My phone is a Asus Zenfone 2 model ASUS_Z00AD. I tried this with ADB logcat running but I didn't see anything interesting. Thanks, PLA

I also have the said issue. Adding the first Slack Team QR Code works just fine, but adding the second does not work.

I had a similar issue scanning a QR for a third Slack account (16th token). The QR matched and then the app went back to the main list without adding the token.
I renamed the previous two Slack account tokens from the default so I'm not entirely sure if this is the same issue.

Even if I modify user, and description, adding a second TOTP secret results in nothing.
It should either: add a new code, tell the user a previous code is already known add if he wants to replace it or add a new code.

A workaround in the meantime is to change your email address in each Slack workspace.
If you're using an email provider like Gmail that supports the<EMAIL_ADDRESS>format then you can still use your single email account for each one. I was able to get all my Slack workspaces added to FreeOTP by using<EMAIL_ADDRESS>in each.


Pyston compatibility for the test suite

numba already works on Pyston, but there were two small snags in the test suite that caused the tests to not pass.

This is exciting, I didn't even know Numba worked on Pyston! Slightly tangential, but how easy is it to add Pyston to the Azure CI tests?

This is exciting, I didn't even know Numba worked on Pyston! Slightly tangential, but how easy is it to add Pyston to the Azure CI tests?

Indeed, great to see Numba works with Pyston.
RE Azure. I think it'd require a llvmlite development conda package that works under Pyston adding to the numba channel somewhere. Other than that I think it's just selectively adding in some conda channels and probably a e.g. $PYTHON_IMPL identifier to the build scripts/Azure config.

Notes:

Initially CUDA tests were failing on Pyston, segfault very early on in library loading, I then installed SciPy from conda-forge and it seemed to "fix it" and all the CUDA tests passed, even though the SciPy build itself was broken, no idea why as yet (imagine it's to do with changing some underlying libraries to get SciPy to install)!
Seems like there's no suitable SciPy build for Pyston so could not run the numba.tests.test_linalg tests which use SciPy's BLAS/LAPACK bindings.

One note (mentioned OOB, but putting here for posterity) is that current Pyston conda packages are built in the conda-forge style, using the python_abi method for managing alternative interpreters.  Anaconda's packages don't yet do this, so testing with Pyston should be done in an environment built this way to avoid contamination by packages with an incompatible ABI:
conda create -n pyston_env  # create an empty environment
conda activate pyston_env
echo 'channels: [pyston,conda-forge]' | conda config --env --stdin
conda install pyston # add whatever other packages you want

(reference: https://github.com/pyston/pyston/wiki/Using-conda)


Filter out Pub/Sub topics the user shouldn't care about.

List the topics to hide.

I don't necessarily know which ones I should. I will create a blacklist of regexs to hide, and add to it as we notice more that shouldn't be there.


Filter By Value

Description

Pressing enter on Filter by value dialogue does not apply the filter, On older versions clicking enter will apply the filters

Please provide us with a way to restore the previous Filter By Value button instead of the drop down menu
DBeaver Version
23.1.2
Operating System
Windows 10
Database and driver
No response
Steps to reproduce
No response
Additional context
No response

Thank you for bug report.

Could you clarify on which older version applying filter worked by enter?

Another part of your issue about restoring Filter by value button in the column header is duplicate of #19199

Could you clarify on which older version applying filter worked by enter?

I've been using version '21.0.2' until yesterday.

One question unrelated to the issue..  Are there any way to disable the dialogue when using advanced paste?

AFAIK there is no such possibility.

The sorting and filtering of the old version are more usable, but the current one requires two more clicks. I hope it can be restored.


enh: added noten achi

Probably not in lexicographic order.

achievements in that file are intentionally in lexicographical order.
derogatory slurs in flavour text will not be accepted.
I'm not sure why build is also failing but I suspect it's not related, I can't compile locally anymore either after some updates. should sort that out first.
to be fair, I never wrote a contributing guide and I totally should but no, for how liberal I am on swear words that flavour text will not get merged.
please resubmit taking the above in account.


Turbo Stream append(...) requires a model

Hi,
<turbo-frame id="list">
...
</turbo-frame>

<turbo-frame id="action">
    <button>More</button>
</turbo-frame>

I'm trying to achieve infinite scrolling. Basically, when the More button is pressed, it gets a turbo stream combo, one to append to list, another to replace/update action with a new More button.
However append() insists on having a model. Is it a limitation on turbo? Any suggestions on what I can do for now? Thank you.

Sorry, should have tried before asking.
Replace ->append(...) with action("append").
Can I file a PR so that ->append() will call ->action("append")? Small quality of life improvement. :)

Yeah, I've noticed the turbo-rails gem allows passing the DOM ID or a model to the shortcut methods. Something I missed on my implementation. I'll try to handle this soon, but feel free to give it a try if you want to!

Ok, I will file a PR. I already managed to get my infinite scrolling to work :)

As of 1.3.0 you're now able to specify the DOM ID as a string in the shorthand methods, as well as passing a second optional content parameter to them, which can either be a string, an instance of a View, or a carefully handcrafted HtmlString instance. Docs were updated. Here's some quick examples:
// Chaining the view
response()->turboStream()->update('some_dom_id')->view('my-view', ['name' => 'lorem']);

// View as content
response()->turboStream()->before('some_dom_id', view('my-view', ['name' => 'lorem']));

// String as content
response()->turboStream()->update('heading_title', $post->title);

// Carefully handcrafted HtmlString instance
response()->turboStream()->append('quote', new HtmlString(
  Blade::render('quotes', ['quote' => Inspiring::quote()]),
));


Go to definition not working when using "relative to project root" import paths.

Consider the following foundry project structure:
.
└── myproject/
    ├── src/
    │   ├── FileA.sol
    │   └── FileB.sol
    └── test/
        └── Test.t.sol

In FileA.sol, I use import paths relative to the root of the project:
import { MyItem } from "src/FileB.sol";
import { Something } from "test/Test.t.sol";

When I use "go to definition" on those imported items, the file that gets opened is an absolute path: /src/FileB.sol or /test/Test.t.sol which obviously do not exist at the root of my filesystem.

You need to prefix the imports with ./ for example ./src so they can be differentiated from libraries dependencies

Note that hover cards for the items imported like in my post above work fine, so the LSP can find those items indeed. Only the file that gets opened on "go to definition" has the wrong path, because a leading slash is added.

Same issue here.


Typo fix, line 155

Hi @bitrvmpd, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;


fix view and add tests

This PR fixes #129 and the shape-bug indicated in #132.

There is two other places with potential underflow, e.g.:
                 return 1 + (
                     std::is_integral<std::remove_reference_t<T>>::value ?
                     integral_skip_impl<S...>::count(i) :
                     integral_skip_impl<S...>::count(i - 1)
                     );

Congrats on solving this one.

thanks!