Make remaining connection age duration available to handlers

Is your feature request related to a problem? Please describe.
The below example is Go-specific, but the issue probably affects all other languages too and hence the feature request is here and not in a language-specific repo.
I have a server that handles long running bi-directional streams. Client (there are many) establishes a connection and then server may eventually have something to reply with. The request may be open for minutes, hours, days. In the middle there is a load balancer so I have to ensure the connection is closed before the timeout setting on the load balancer, otherwise it aborts the connection. To do that server has max connection age set to a number and in addition to that on each request code starts a timing out context. Once it times out, the server just returns nil from the handler, closing the connection cleanly. Client sees io.EOF and reconnects immediately, likely using a different TCP connection.
The problem is that sometimes the server has multiple things to reply with over a period of time that is smaller than max connection age. In this case the underlying TCP connection is reused and my timeout context only signals "done" when it's too late and the max connection age grace has also expired. Actually, the request's context signals sooner than my own context. The client gets an error (rpc error: code = Unavailable desc = closing transport due to: connection error: desc = "error reading from server: EOF", received prior goaway: code: NO_ERROR, debug data:) rather than io.EOF.
Describe the solution you'd like
Let the request handler know how much time it can occupy the connection for without breaching the max connection age. Ideally it's a context (for Go) that is canceled when max connection age duration elapses.
Request context is a different thing. It's "done" when max connection age grace duration elapses and the connection is aborted. Even if handler returns nil, client gets an error.
Describe alternatives you've considered
For now I have came up with a workaround - max poll duration that a handler can wait for an event is just a little under 50% of the max connection age. And then max connection age for gRPC is set to 35% of the max connection age for the load balancer. This way even if some time is "consumed" by the "fast" requests, a long request that starts right before
max connection age for gRPC expires, can still run for ~50% of time and end without breaching the overall max connection age of the load balancer. 35% is because it's 35% +/- 10% jitter - must be under 50%.
The above works but it's wasteful as connections could be sitting idle for much longer. Instead, both server and client have to do work to re-establish the network and logic connection/etc.
I'm going to try the Handler.TagConn suggestion from https://github.com/grpc/grpc-go/issues/4597#issuecomment-881085539 as it'll allow the server to better utilize the available connection time.
Additional context
https://github.com/grpc/grpc-go/issues/4597 is where I initially requested this feature.
Fix/workaround is here https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/merge_requests/424, perhaps it can help understand the issue I'm having. Thank you.

cc @ejona86
Note that in grpc/grpc-go#4597 I recommended having the client simply restart the stream when this happens, but @ash2k is concerned about the additional UNAVAILABLE errors caused by MAX_CONNECTION_AGE "polluting" metrics and masking real UNAVAILABLE problems.

Let the request handler know how much time it can occupy the connection for without breaching the max connection age. Ideally it's a context (for Go) that is canceled when max connection age duration elapses.
Request context is a different thing. It's "done" when max connection age grace duration elapses and the connection is aborted. Even if handler returns nil, client gets an error.

I think a more general / elegant solution here may be:

Have the server adjust the deadline of the RPC according to the remaining MAX_CONNECTION_AGE (+ GRACE?) for the connection.

The handler in this example could then make sure it always returns a little earlier than the RPC's deadline.

What is wrong with setting the MAX_CONNECTION_AGE_GRACE to be the maximum amount of time the service may keep the RPC open (or vise versa)?

In the middle there is a load balancer so I have to ensure the connection is closed before the timeout setting on the load balancer, otherwise it aborts the connection.

If the load balancer is killing the RPCs, then the backend doesn't actually know how much time is left; that information is not communicated over HTTP/2. In this case, the backend server wouldn't even see a GOAWAY, as the connection that is shutting down isn't the balancer→server but client→balancer.
A long time ago we discussed trying to communicate some things like this, but it depends heavily on your topography and there's lots of ways to shoot yourself in the foot. Even with server-side and client-side application-specific code reacting to notification, none of the simple solutions support client → load balancer → some other proxy → server.

Have the server adjust the deadline of the RPC according to the remaining MAX_CONNECTION_AGE (+ GRACE?) for the connection.

We hadn't considered that in the "long time ago" discussion, but it'd require the load balancer to do that in this case. That requires a gRPC-aware load balancer and earlier we were assuming generic HTTP/2 proxies. It seems like a pretty good solution if you have a grpc-aware proxy. (And yes, add in grace time.)

We hadn't considered that in the "long time ago" discussion, but it'd require the load balancer to do that in this case. That requires a gRPC-aware load balancer and earlier we were assuming generic HTTP/2 proxies. It seems like a pretty good solution if you have a grpc-aware proxy. (And yes, add in grace time.)

This idea is related solely to the gRPC feature of max connection age, and unrelated to the other concern of an LB in the middle killing connections.  (This user has worked around the LB problem already by setting max connection age according to their knowledge of the LB's behavior.)  This may be worth doing in a vacuum, since we know the RPC can't proceed beyond MAX_CONNECTION_AGE+GRACE.

It seems the user is having trouble still with the LB:

For now I have came up with a workaround - max poll duration that a handler can wait for an event is just a little under 50% of the max connection age. And then max connection age for gRPC is set to 35% of the max connection age for the load balancer.

Normally I'd expect the (L7) load balancer → backend to have a very high max connection age, potentially infinite. The load balancer sets its max connection age based on its scaling requirements, and copying those values to all backends is brittle. Having to adjust the max connection ages in this Byzantine way is not something I'd want people to have to. The core issue is the connections are independent so you have to "hack the math" to make this approach work.
If the load balancer's grace period is no smaller than the backend's maximum poll duration, then there are no issues. Max connection age controls the freshness of new load distribution and max connection age grace controls the freshness of old load distribution. It seems best to focus on the grace time and not the age itself.

This may be worth doing in a vacuum, since we know the RPC can't proceed beyond MAX_CONNECTION_AGE+GRACE.

It certainly is interesting. I'm not sure it produces better results than adjusting the grace periods though, although I'd agree it is really nice as zero setup and high simplicity. I'm not wild about having the server behave differently depending on how old the connection is; I'm concerned about second-order effects and even trouble debugging. If we went this way, I may argue that we implement it as an option that limits to deadline to only the grace time (even if not already shutting down), which would be much more predictable. But that seems too strict.

I'm not wild about having the server behave differently depending on how old the connection is

The server does behave differently based on connection age, because of MAX_CONNECTION_AGE support itself.  This is exposing that difference to the application up front, rather than silently killing the connection out from under it later.

limits to deadline to only the grace time (even if not already shutting down), which would be much more predictable. But that seems too strict.

For sure that's too strict and I don't see any reason most users would want an option with that behavior.  Note that the server owner knows the grace period already, so they can trivially set it to this value themselves in an interceptor.
I can see concerns about predictability w.r.t. the deadline changing, since users will see a change in behavior if they are using the RPC deadline for something besides "time to end the RPC now" (e.g. rejecting an RPC with a deadline that is too small).  So we could still make it optional, but I think it would make more sense to set the deadline to the point in time the connection will be hard-closed.  Interceptors don't know connection establishment time, so there is no way to have them implement this behavior on their own.

Thanks for considering my use case. I'd like to clarify - I described the whole picture, including the load balancer just for completeness of "how it works in production". I control the load balancer so I can set any timeout on it, but it has to be set to a number and cannot be infinite. It shouldn't be infinite for other reasons (proxys, proper load distribution, etc.). Please forget the load balancer, the same problem happens on a single machine with server and client communicating directly.
I just want the server to know when to return from the request handler - right after MAX_CONNECTION_AGE was reached - to avoid any errors. This "deadline timer" should not include the grace period because stopping the request handler is not instantaneous and may take a very short while, but not 0. Thank you.

This "deadline timer" should not include the grace period because stopping the request handler is not instantaneous and may take a very short while, but not 0.

IMO it should include the grace period, otherwise RPCs will unnecessarily fail because of this feature.  (Consider an RPC that comes in right before the grace period is about to begin, and could complete by the end of the grace period.)
If the request handler knows it needs to properly respond without an error before the "deadline" (either the actual deadline set by the client or an artificial one as described here), then it will need to return at least a few milliseconds before that deadline.  To be safe, I'd return 5-10 seconds earlier.  But I wouldn't want the gRPC server to try to guess what that buffer should be for the user.  I'd rather communicate the exact moment at which things will fail, and let the user apply the offset they believe works best for them.

IMO it should include the grace period, otherwise RPCs will unnecessarily fail because of this feature. (Consider an RPC that comes in right before the grace period is about to begin, and could complete by the end of the grace period.)

I see what you mean. I think it depends on the implementation. I see these options:
Option 1: My thinking is in grpc-go it can be a context that is "done" when MAX_CONNECTION_AGE expires. The handler receives the signal and returns cleanly, client gets no error. The fact that the context is "done" doesn't necessarily mean that the RPC will fail. It's just a signal and it is also a separate context from the existing ServerStream.Context(). My understanding is that the existing one is "done" when grace time expires and the connection is forcibly closed. I.e. we already have a context that includes both durations.
Option 2: Provide a "remaining connection age+grace" duration. However, how is it going to behave if grace period is infinity? We still want the server to stop and let the connection be closed. Not a very flexible option.
Option 3: Provide a "remaining connection age" duration. This is as useful (or even better) to me as option 1 because it allows to construct a context with or without the grace period. The important bit is that max connection age has +/- 10% jitter and I don't have to deal with that if I'm provided with an exact number. This is the most flexible option as it allows to do both things - return right after MAX_CONNECTION_AGE expires or use some of the grace period too (e.g. grace duration minus 5-10 seconds you suggested, or some percentage of it). This is also a cross-language version (contexts are Go-specific obviously).

Consider an RPC that comes in right before the grace period is about to begin, and could complete by the end of the grace period.

In my case it's fine - my code uses both contexts. It understands that one is for "exit if idle" and the one from ServerStream.Context() is "hard abort, don't waste your time, the connection is no longer there". So if the first one is "done" but we are in the request handling phase (not idle sleep time between server-side "check for event" attempts), we continue as long as the second context is not "done". I hope that clarifies what I'm doing.

The server does behave differently based on connection age, because of MAX_CONNECTION_AGE support itself.

Yes, but it exposes itself as a semi-ugly error and the fix is to configure things differently or live with it. I see that as a feature; when well-configured, it is invisible and the grace period is mostly not exceeded (maybe just long-tail RPCs). The discussion here will align RPCs to the death of the connection as part of normal and "good" operation, which worries me.

Please forget the load balancer, the same problem happens on a single machine with server and client communicating directly.

That's a bit hard to do because for it to work for you you have to abusing MAX_CONNECTION_AGE on the backend. I'm not wild about extending MAX_CONNECTION_AGE behavior so it can be better abused. As I've also mentioned, many solutions are dependent on your network topology, which means we solve this for direct connections, and then we need another solution for single-LB-usages, and then still may need to consider multi-LB usages. And after all that, it doesn't seem too much superior than the basic KISS approach, which I haven't heard a reply as to:

What is wrong with setting the MAX_CONNECTION_AGE_GRACE to be the maximum amount of time the service may keep the RPC open (or vise versa)?

Yes, but it exposes itself as a semi-ugly error and the fix is to configure things differently or live with it. I see that as a feature; when well-configured, it is invisible and the grace period is mostly not exceeded (maybe just long-tail RPCs). The discussion here will align RPCs to the death of the connection as part of normal and "good" operation, which worries me.

I think my setup is well configured - MAX_CONNECTION_AGE + MAX_CONNECTION_AGE_GRACE are sufficiently below the load balancer's timeout (LB is never a problem for me) and long-tail RPCS are precisely what I cannot make to work properly (i.e. without errors). Could you elaborate a bit more on why allowing server to close the response stream just after MAX_CONNECTION_AGE "worries" you?

What is wrong with setting the MAX_CONNECTION_AGE_GRACE to be the maximum amount of time the service may keep the RPC open (or vise versa)?

For the same reason this is not the default behavior - it's inefficient. Short-lived requests will cause the underlying connection to be closed (and then reopened). My whole setup with long-polling bidi streaming requests/response is meant to make it more efficient:

if there are no events, connections are idle but open for as long as possible i.e. MAX_CONNECTION_AGE or a bit more.
if there are events, a connection is reused as much as possible to avoid paying the cost of re-establishing the connection.

For the same reason this is not the default behavior - it's inefficient.

Efficiency isn't a boolean. Even your suggested approach would be less efficient than cooking something up with UDP. My goal is not to make things 100% efficient in someone's mind. The goal is to make it "reasonably" efficient.
But I do debate that it is inefficient. In fact, because your backend MAX_CONNECTION_AGE has to be a third (or was it ½ of ⅓?) of the LB's MAX_CONNECTION_AGE, that approach is more "inefficient" than my suggestion. My goal would be to have the backend MAX_CONNECTION_AGE essentially infinite and keep RPCs within the LB's limits.

Short-lived requests will cause the underlying connection to be closed (and then reopened)

What? Short-lived requests continue using the same connection until MAX_CONNECTION_AGE expires, unless MAX_CONNECTION_IDLE kicks in which seems unlikely for you. But still, who said anything about short-lived requests? What is wrong with medium-lived requests or increasing MAX_CONNECTION_AGE_GRACE?

My whole setup with long-polling bidi streaming requests/response is meant to make it more efficient

Let's say you want to allow the long-lived RPCs to last for an hour. Then you gracefully close them in the backend after an hour and you set your LB's MAX_CONNECTION_AGE_GRACE to at least 1 hour + 1 minute. If you want to limit most client→LB connections to last ~1 hour, then set the LB's MAX_CONNECTION_AGE to at most 1 hour - 1 minute. This is very easy to reason about doesn't require a useless MAX_CONNECTION_AGE configured in the backend. It is also "perfectly" "efficient," for some definition for both of those terms.
It'd be common for MAX_CONNECTION_AGE and MAX_CONNECTION_AGE_GRACE to not be so similar. The lifetime of the longest RPC is dependent on how frequently you want to balance your backends whereas MAX_CONNECTION_AGE is dependent on how frequently you want to balance your balancers. The max age and max age grace only align if the LB is the limiting factor and these old RPCs are a substantial portion of traffic.
The only issue with it in my mind is that it takes some coordination between the backend and the LB; the LB must be at least as permissive as the backend. No matter what the backend has to be aware of the LB's settings to predict its own performance/behavior, so this doesn't seem particularly onerous.

The goal is to make it "reasonably" efficient.

I fully agree with this goal! :)

But I do debate that it is inefficient. In fact, because your backend MAX_CONNECTION_AGE has to be a third (or was it ½ of ⅓?) of the LB's MAX_CONNECTION_AGE, that approach is more "inefficient" than my suggestion. My goal would be to have the backend MAX_CONNECTION_AGE essentially infinite and keep RPCs within the LB's limits.

It does not have to be. It's only set this way to work around the current limitation of gRPC. It has to be way under the limits to avoid getting the errors.

What? Short-lived requests continue using the same connection until MAX_CONNECTION_AGE expires, unless MAX_CONNECTION_IDLE kicks in which seems unlikely for you. But still, who said anything about short-lived requests? What is wrong with medium-lived requests or increasing MAX_CONNECTION_AGE_GRACE?

Ok, I misunderstood what you are suggesting. I thought you are suggesting to set MAX_CONNECTION_AGE to a small number and MAX_CONNECTION_AGE_GRACE to the LB's timeout. That's why I said "it would be inefficient with short lived connections". Let me try to answer your question again.

What is wrong with setting the MAX_CONNECTION_AGE_GRACE to be the maximum amount of time the service may keep the RPC open (or vise versa)?

So let's say the LB timeout is 1 hour. After that it aborts the connection. The server has to send GOAWAY and finish all pending RPCs in under 1 hour or the client will see an abort. How do I do that?

It does not have to be. It's only set this way to work around the current limitation of gRPC. It has to be way under the limits to avoid getting the errors.

I do believe it is necessary (although, if MAX_CONNECTION_AGE_GRACE=0 it doesn't help enough). Otherwise you have to make assumptions like the long-lived RPC was created early in the connection's lifetime. You may be able to do that, but that isn't generally the case so isn't worth spending much time considering.
The client's connection and the backend's connection are created at independent times. Their lifetimes are separate and they aren't 1:1. Thinking more, this approach will cause many clients to a backend to re-create the RPC at the same time. Far too many poor properties.

an equivalent of gRPC's MAX_CONNECTION_AGE=1 hour and MAX_CONNECTION_AGE_GRACE=0

Ooph. You will have errors with MAX_CONNECTION_AGE_GRACE=0. Period. Nothing you can do. Even short-lived RPCs will see errors.
If you can't change the LB, then I suggest you accept the LB will kill your streams and have clients restart the streams without a backoff if they failed after receiving a message.

I do believe it is necessary (although, if MAX_CONNECTION_AGE_GRACE=0 it doesn't help enough). Otherwise you have to make assumptions like the long-lived RPC was created early in the connection's lifetime. You may be able to do that, but that isn't generally the case so isn't worth spending much time considering.

Exactly. And I don't want to make such assumptions because they are incorrect. I want to use the connection for as long as max connection age permits but not longer and without any incorrect assumptions. How do I do that?

The client's connection and the backend's connection are created at independent times. Their lifetimes are separate and they aren't 1:1.

Is that accurate? My understanding is that for HTTP/2 the LB would not load balance each request as it does with HTTP/1.1, it's just picking a backend and that's it - the connection stays with it until the backend closes it or LB aborts it. And actually I'm using WebSockets (see below) so it's always 1:1, right?

Ooph. You will have errors with MAX_CONNECTION_AGE_GRACE=0. Period. Nothing you can do. Even short-lived RPCs will see errors.

Yes, I will have errors if the server cannot know how much time this tcp connection still has. If it does, then it can finish the RPC before it's too late. Setting MAX_CONNECTION_AGE + MAX_CONNECTION_AGE_GRACE less than LB timeout is a workaround for that (it's a standard practice, right?). Setting it to a smaller number is totally fine, but not like a half or a third. That is too inefficient in my mind. But I also don't have a choice with current gRPC Go implementation.

If you can't change the LB, then I suggest you accept the LB will kill your streams and have clients restart the streams without a backoff if they failed after receiving a message.

I'm using Google Cloud load balancer in WebSocket mode. gRPC is tunneled by client and unwrapped by the server to hide it from the LB. We cannot do native HTTP/2 at the moment because for that this LB requires the backend to do TLS, which it does not at the moment (cert management is a hard problem). So that's why WebSockets. And in this mode there is only a single timeout setting there: https://cloud.google.com/load-balancing/docs/https/#timeouts_and_retries
I don't understand what you are suggesting I should do :) I tried two solutions and both work:

Set MAX_CONNECTION_AGE + MAX_CONNECTION_AGE_GRACE much less that LB timeout. This is inefficient because it causes connection re-establishment too often. Could be less often, but then I get errors, as described in first message here.
Currently the code uses Handler.TagConn to track when the connection was established as suggested here https://github.com/grpc/grpc-go/issues/4597#issuecomment-881085539. Based on that in each request a timing out context is started and request returns when it expires. This works, but is not as nice than it could be because it has to account for +/- 10% max conn age jitter that gRPC adds (i.e. code has to use 10% less of time of the connection that it ideally could).

Essentially this issue is about exposing the actual remaining connection age to the application so that it can finish responding before it's too late. I'd appreciate if you explain why this is not good i.e. what can go wrong.
Re. the LB again. Even if we used HTTP/2 to the backend (I hope we'll do that eventually), I don't see a way to set the grace period here https://cloud.google.com/load-balancing/docs/backend-service#timeout-setting. The closest thing I found is connection drainging but it's for a different purpose it seems.
p.s. we are talking about the LB again, but as I said above, even without LB in the picture with direct client-server comms it's still a problem. Server doesn't know how much time it can keep the long-polling connection open without replying. Playing with MAX_CONNECTION_AGE(_GRACE) is a workaround for that. Currently whatever they are set to, polling has to be configured by the user to make sure server replies in time. Instead I'd like to have an API to find out when to stop. I believe this is a valid use case.

Is that accurate? My understanding is that for HTTP/2 the LB would not load balance each request as it does with HTTP/1.1, it's just picking a backend and that's it - the connection stays with it until the backend closes it or LB aborts it. And actually I'm using WebSockets (see below) so it's always 1:1, right?

Websockets would be 1:1. But a websocket is more similar to a gRPC stream/RPC, not connection. Each RPC gets selected to a particular backend, but the connections are separate. The connections being 1:1 is more of an attribute of L4 load balancing. Even if the L7 LB has affinity to a particular backend for a particular client connection, then connections themselves would have independent lifetimes.

I'm using Google Cloud load balancer in WebSocket mode. gRPC is tunneled by client and unwrapped by the server to hide it from the LB.

Oh, then the LB is essentially an L4 LB. That changes a lot of the discussion. And now I understand more of the constraints and such. When using an L4 LB, your backend will need to have the MAX_CONNECTION_AGE and such based on what the LB allows. And now it makes sense that the grace time would be zero, because it is at an L4 layer.

We cannot do native HTTP/2 at the moment because for that this LB requires the backend to do TLS, which it does not at the moment (cert management is a hard problem).

That's a very fair reason. Not that it changes anything, but I'm a bit surprised you aren't just using the TCP load balancer. That would avoid the websocket tunneling. There could be other reasons to do this tunneling, so it isn't bad. I'll just assume there's a good reason, but I did want to mention that the TCP LB is a more typical solution.

Set MAX_CONNECTION_AGE + MAX_CONNECTION_AGE_GRACE much less that LB timeout. This is inefficient because it causes connection re-establishment too often. Could be less often, but then I get errors, as described in first message here.

You should be able to set MAX_CONNECTION_AGE + MAX_CONNECTION_AGE_GRACE to be just a few seconds shy of the LB's limit and not see frequent failures. You may see rarer failures just because a LB may need to load shed or is being restarted and random networking issues (these are general problems; I don't know how much they apply to GCLB itself but I do see "Note that events such as GFE restarts might cause sessions to terminate sooner than this timeout" in the docs).
You'll also want to enable server-side keepalive to be a few seconds shy of 10 minutes to account for the "TCP session timeout". You may choose to use MAX_CONNECTION_IDLE, but it is sort of unrelated once you enable keepalive (and it isn't a replacement for keepalive).
I see the docs say "For example, a practical timeout value for external HTTP(S) load balancers is 1 day (86400 seconds)." In that case, a MAX_CONNECTION_AGE of 1 hour and a MAX_CONNECTION_AGE_GRACE of 23 hours - 1 minute doesn't seem so bad. Your backend would then limit itself to 23 hours - 2 minutes.
1 hour max age may be a good idea for you in general, as it means your backends will be more balanced; the longer the max age, the longer it takes to rebalance backends when you start new servers. When using an L4 LB the max age tends to skew lower, like 1-10 minutes. But it does depend on the sort of traffic you expect.

Even if we used HTTP/2 to the backend (I hope we'll do that eventually), I don't see a way to set the grace period here

Yeah, I don't see much either, but with just a minute of searching. It seems it may have an infinite grace time for the connection, which is possible since there is a response timeout. So essentially the response timeout is the grace time.

Playing with MAX_CONNECTION_AGE(_GRACE) is a workaround for that.

You must play around with those settings. That is unavoidable when using L4 LB. You only have this problem because the LB architecture. The problem with exposing the remaining lifetime to the application is it aligns many RPCs to the same event which will cause bursts. Yes, that alignment already happens, but we aren't encouraging it. I'd strongly recommend the grace time to allow the majority of RPCs to naturally complete which is quite different than recommending someone purposefully align RPCs to connection death. I'd consider adding gitter to the time we provide, but that seems at direct conflict to your goal.

I believe this is a valid use case.

It is valid. But I'm concerned it over-optimizes ignoring other costs. Even if it was perfect for your use-case, it can be a sharp edge for other users. So we are weighing 1) how much benefit does it provide 2) how much pain may it cause 3) how much cost will it take to define/implement 4) likelihood it will be used in inappropriate situations. Saving 10% of a connection's lifetime is low benefit for (1). I'd be much more likely to see the benefit that you don't have to copy configuration to your service, although there's generally very few service methods that are long-lived which again means limited gain.

I still believe that shortening deadlines to match when the connection will be closed by the server would be:

very easy for us to implement, at least in Go,
completely transparent to users, and
beneficial for users.

The only possible negative impact would be failing some RPCs that would not have otherwise failed if the server is checking that the deadline is at least some value greater than the keepalive grace period.  However, even in this case, this is technically what the user wants, because the RPC cannot exist on the server for longer than the connection.
The benefits of doing this are not (just?) maximizing connection lifetimes, but also properly surfacing RPC lifetimes to the server application, which could result in not wasting resources to process the RPC.  For expensive RPCs, or RPCs where failures are costly, this could be a big win.

Re. TCP load balancing. Yes, we could use it, but we are routing requests differently based on URL path - not everything is gRPC-over-websocket, some paths server plain HTTP. Thanks for the tip anyway as I have forgotten it's possible.

You should be able to set MAX_CONNECTION_AGE + MAX_CONNECTION_AGE_GRACE to be just a few seconds shy of the LB's limit and not see frequent failures. You may see rarer failures just because a LB may need to load shed or is being restarted and random networking issues (these are general problems; I don't know how much they apply to GCLB itself but I do see "Note that events such as GFE restarts might cause sessions to terminate sooner than this timeout" in the docs).

All of the above makes sense and we already do that. But the problem is not with the LB aborting the connections :) The problem is that the application code does not know when to return from a request.

You'll also want to enable server-side keepalive

Yes, we do that too. Connections are stable, nothing misbehaves.

I see the docs say "For example, a practical timeout value for external HTTP(S) load balancers is 1 day (86400 seconds)." In that case, a MAX_CONNECTION_AGE of 1 hour and a MAX_CONNECTION_AGE_GRACE of 23 hours - 1 minute doesn't seem so bad. Your backend would then limit itself to 23 hours - 2 minutes.

That makes sense. What I'd like to have is a way for gRPC to tell me these numbers (or a single number for remaining connection age, actually) somehow so that I can use an API rather than do the math in my code. Currently I have to provide these numbers to gRPC and also inject into my application code (into all RPC handlers). This is not great UX.

1 hour max age may be a good idea for you in general, as it means your backends will be more balanced; the longer the max age, the longer it takes to rebalance backends when you start new servers. When using an L4 LB the max age tends to skew lower, like 1-10 minutes. But it does depend on the sort of traffic you expect.

Yes, makes sense. We have 30 min 30 sec timeout on the LB and the app must stay below that. App is configured with 30 minutes as a parameter, everything else is derived from it.

The problem with exposing the remaining lifetime to the application is it aligns many RPCs to the same event which will cause bursts. Yes, that alignment already happens, but we aren't encouraging it. I'd strongly recommend the grace time to allow the majority of RPCs to naturally complete which is quite different than recommending someone purposefully align RPCs to connection death.

I see your point and I think it's a valid point! Then perhaps we can find a solution that does not have this problem? What I want is gRPC to tell the RPC handler when to stop to avoid running past MAX_CONNECTION_AGE+MAX_CONNECTION_AGE_GRACE and getting an abort.

I'd consider adding gitter to the time we provide, but that seems at direct conflict to your goal.

No, it's actually not! It would totally work for me! My points/asks:

I don't want to calculate this in my code, I want gRPC to tell the handler when to stop ("or else...!"). Doing it myself is possible (I do that already) but it's ugly, brittle, hard to maintain, easy to get wrong, etc.
I don't want clients to get errors because of server not returning from the handler in time.
I don't mind having not a 100% "utilization" of MAX_CONNECTION_AGE+MAX_CONNECTION_AGE_GRACE time by my handler.

I'm fine with X + [0, MAX_CONNECTION_AGE_GRACE*Z), where X is the remaining connection age and Z is some extra coefficient so that there is a guaranteed bit of time even after the signal. E.g. Z can be 0.9 to leave 10% of grace time for the handler to finish. What I was saying in previous comments is that I don't like it when utilization is a third or a half, but this would work for me.
Existing Context in gRPC Go is not doing what I'm after, it's cancelled when it's too late. I think it should not change it's behavior - I need both types of signal. The max conn age signal (the thing I'm asking for here) is a "soft stop" (handler exits if it hasn't started preparing a response and is just waiting for an event) and the existing context is a "hard stop" (abort even if handler started preparing a response because there is no point in finishing even if it takes 1ms of time).
WDYT? Thank you for taking the time to respond.

I still need this.


Routes problem

Hi! I have a problem with httproutes.
When i'm using
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
that's all right.
but when i'm using only
config.MapHttpAttributeRoutes();
swagger works wrong.
Can you help me?

You'll have to elaborate a little more. Swashbuckle supports both traditional routing and attribute routing so there's clearly something unexpected going on. But, the details you've provided don't really give any clues

when i'm using attribute routing my swagger help page looks like
controllers: http://myscreenshot.info/i/0005/850081421838506382412903453461.html
auth controller: http://myscreenshot.info/i/0005/596261421838700772055617516738.html
Raw: http://myscreenshot.info/i/0005/722411421838647287753349207174.html
but none of the controller does not work button "show/hide"

I can't see all of the raw screenshot but it does look like the description for "Auth" is coming back successfully. Did you check the raw docs for each individual controller, e.g. api-docs/Tour, api-docs/TourAction etc. If any one fails it will probably break the whole UI so worth checking that first.
Next, I would take a look at your JavaScript console to see if the issue may be on the client-side (albeit  because of some issue with the spec)
Also, is there anything else that has changed (other than atributes routes) since this last worked for you. Support for Attribute Routing has been out there for a long time and this is the first issue I've seen in relation to it.

Hi! thank you, i have found a problem.
When i'm using
[Route("")]
like there
http://myscreenshot.info/i/0005/724721421926162826508593138368.html
http://myscreenshot.info/i/0005/981251421926207854582926062044.html
i get a problem.
when i remove this action - swagger works ok!
i think, problem with empty action routename

Interesting ... I'd never considered the use of an empty route in an API before.
Even with the empty route, I still can't repro your issue so there must be something else at play.
Is there an error in your JavaScript console?

Closing due to inactivity. Still unable to repro


Invalid link in verification of email address

https://support.grid.tf/ doesnt exist

Seems to be fixed (probably added redirect / fallback)


Uvicron restapi with FastAPI shows shutting down while inferencing using pytorch models

I tried to load and inference from a pytorch model using fastAPI(with uvicorn).
But while predicting time it shows like this
INFO:     Shutting down
INFO:     Waiting for connections to close. (CTRL+C to force quit)
I tried the same method using flask and worked fine within milliseconds.
Here is the code for  pretrained  model prediction using fastapi

But While predicting with fastAPI it shows like this

(Since it is a pytorch RoBERTA based huge pretrained model,  the model size is around 600MB)

Please follow our issue template: https://github.com/tiangolo/fastapi/issues/new/choose

@Kludex updated
Please put your thoughts in https://github.com/tiangolo/fastapi/issues/3283

Looks like this and #3283 were solved by the suggestion here: https://github.com/tiangolo/fastapi/issues/3283#issuecomment-851002452
Can this and #3283 be closed @pradeepdev-1995?


Errror when run demo ?

I use GPU when inference but i don't know why error  . Which one model run on CPU ?

loading pretrained crnn model from crnn.pth
0%|                                                                                | 0/4 [00:00<?, ?it/s]
Traceback (most recent call last):
File "/home/thorpham/Documents/challenge/super-resolution/TPGSR/main.py", line 76, in
main(config, args, opt_TPG=opt)
File "/home/thorpham/Documents/challenge/super-resolution/TPGSR/main.py", line 16, in main
Mission.demo()
File "/home/thorpham/Documents/challenge/super-resolution/TPGSR/interfaces/super_resolution.py", line 1480, in demo
images_sr = model(images_lr)
File "/home/thorpham/anaconda3/envs/torch/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1051, in _call_impl
return forward_call(*input, **kwargs)
File "/home/thorpham/Documents/challenge/super-resolution/TPGSR/model/tsrn.py", line 195, in forward
spatial_t_emb = self.infoGen(text_emb)
File "/home/thorpham/anaconda3/envs/torch/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1051, in _call_impl
return forward_call(*input, **kwargs)
File "/home/thorpham/Documents/challenge/super-resolution/TPGSR/model/tsrn.py", line 103, in forward
x = F.relu(self.bn1(self.tconv1(t_embedding)))
File "/home/thorpham/anaconda3/envs/torch/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1051, in _call_impl
return forward_call(*input, **kwargs)
File "/home/thorpham/anaconda3/envs/torch/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 916, in forward
return F.conv_transpose2d(
RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cpu and cuda:0! (when checking arugment for argument weight in method wrapper_slow_conv_transpose2d)

@ThorPham Hi, have you altered the code by yourself or you run the test with multi-gpu? Our model may have some bugs when runing the test with multi-gpu process.

@ThorPham Also you may try to figure out which device the input arguments are in. This may help you figure out the buggy part.

Thank you


[webapi] Add nexus4 baseline data for bdd tests

Impacted TCs num(approved): New 0, Update 7, Delete 0
Unit test Platform: Crosswalk Project for Android 15.44.374
Unit test result summary: Pass 7, Fail 0, Blocked 0

Why there's no nexus 3?

I will add nexus3 baseline after Lijun provide.

OK, I will merge it first.


i18n: Add Japanese translation

Purpose
Add Japanese version of i18n.

私を併合する

I can read English so please comment in English instead of Japanese with machine translation.


WebsocketClient Invalid login credentials, did I hash the secret

Hi,
I try to use pirivate channel for websoket, but I recieved
{"type":"error","code":400,"msg":"Invalid login credentials"}
I use this code
const params = {         key: '{api_key}',         secret: '{my_secret}',         subAccountName: '{subname}',     }     const ws = new WebsocketClient(params);
Do I have to use signature ( SHA256 HMAC of my secret) ?

Are api_key and my_secret variables containing your key and secret as a string?
Try to console.log('my params object: ', params); to inspect what you're sending into the ws client. I think what you're looking for is something like this:
const api_key = 'lkmasdflkmadlfskmadsf';
const api_secret = 'asdfasdfasdf';
const subname = 'sub1';
const params = { key: api_key, secret: my_secret, subAccountName: subname, };
const ws = new WebsocketClient(params);

You don't need to create a signature, the connector does it for you. There's also ftx websocket examples here and here.

Yes it's my key and secret in string.
It's work with the Rest API
 const client = new RestClient(key, secret, {"subAccountName": subAccountName});

Just in case, I wonder when you said you were doing this:
const params = { key: '{api_key}', secret: '{my_secret}', subAccountName: '{subname}', }

You actually meant to try this:
const params = { key: `${api_key}`, secret: `${my_secret}`, subAccountName: '{subname}', }

Not sure if I misunderstood what you said in your first message, or if there was a misunderstanding about string templates in JS.


TCP version

As far as I know it's UDP only. Would it be possible to add TCP support?

Hi Gaborapp,
Indeed it is currently UDP only, as OSC generally is.
Adding support for TCP is largely doable, but I have no plan to code it myself.

Thanks. Would you accept a pull request about this?
As I see it now oscpack can be replaced with liblo that supports TCP.

Yes, I would accept a PR!
Some recommandations:

there should be a setting to choose UDP vs TCP, defaulting to UDP.
oscpack is used only to write/parse OSC messages, not to send/receive them. I used the UE4 network functions instead. So the TCP connections should be established using the UE4 functions too. I'm not inclined to replace oscpack.
I guess some new events are needed (connected, disconnected, etc.). I would prefix them with "TCP" so that people do not expect them to work when using UDP.

Several years later...
7e99bb89ac7845f9e7b129f1e4dce32dcb3ae3e7 adds a DispatchPacket method. I use it to plug this plugin with the nDisplay event system, but that would work to receive from TCP too.


8957 flatten vizjson layers

Backend changed to make vizjson layers a flat structure. This made a lot of options in the vizjson presenter unnecessary.
Also made some changes to Torque to avoid generating SQL when in a named map (there was code for that, but it didn't work).
Relevant generated vizjson looks like this:
Named map:
  "layers": [
    {
      "id": "f02e24a4-d00e-40ae-80e8-3e891a4a71e4",
      "type": "CartoDB",
      "infowindow": [...],
      "tooltip": [...],
      "layer_name": "ny_firecompanies_1",
      "interactivity": "cartodb_id",
      "visible": true,
      "options": {
        "attribution": "CartoDB attribution"
      }
    },
    {
      "id": "0d2ac92b-d8cf-48c8-818d-b15beb79c8b6",
      "type": "torque",
      "order": 2,
      "legend": [...],
      "options": {
        "attribution": "CARTO attribution",
        "visible": true,
        "table_name": "ec_kvy_31_1_2",
        "user_name": "jtorres"
      },
      "cartocss": [...],
      "cartocss_version": "2.1.1"
    },
  ],

Anonymous:
  "layers": [
    {
      "id": "f02e24a4-d00e-40ae-80e8-3e891a4a71e4",
      "type": "CartoDB",
      "infowindow": [...],
      "tooltip": [...],
      "legend": [...],
      "order": 1,
      "visible": true,
      "options": {
        "layer_name": "ny_firecompanies_1",
        "cartocss": [...],
        "cartocss_version": "2.1.1",
        "interactivity": "cartodb_id",
        "attribution": "CartoDB attribution",
        "sql": "select * from ny_firecompanies_1"
      }
    },
    {
      "id": "0d2ac92b-d8cf-48c8-818d-b15beb79c8b6",
      "type": "torque",
      "order": 2,
      "legend": [...],
      "options": {
        "attribution": "CARTO attribution",
        "visible": true,
        "table_name": "ec_kvy_31_1_2",
        "user_name": "jtorres"
      },
      "cartocss": [...],
      "cartocss_version": "2.1.1",
      "sql": "select * from ec_kvy_31_1_2"
    },
  ],

Closes #8957

CR @juanignaciosl @alonsogarciapablo

hey @javitonino could you paste here an example viz.json with basemap, cartodb layers and a torque layer?

I did post the relevant part (CartoDB and torque layers above) as they are probably easier to read at a glance. Complete examples:
Named map: https://gist.github.com/javitonino/17f9f6f57679543948f58b71660a1d08
Anonymous: https://gist.github.com/javitonino/fcfcdac8de3e454aabe41d60b460a5c3

I'm testing this out while I work on the cdb.js side now and will comment later/tomorrow to see how everything worked out. Thanks @javitonino!

It's not relevant for cdb.js (cause it basically "flattens" the options), but I noticed that "CartoDB" layers have the layer_name in a different "position" in the two different versions of the viz.json (it's a "first class citizen" in the "named_map" version, and it's inside of "options" in the "anonymous" version). It would be nice to unify it. I guess they should all be "options" ( 😕 ).
Also, I noticed that "CartoDB" layers don't have order anymore, but other layers do have it. IMO, we either add it back, or remove it from all layers. In this last case, CartoDB.js will asume that the order of layers in the viz.json is the order in which they should be rendered (as it's currently the case).

A couple of things I noticed too:

"Tiled" layers don't/won't have infowindows and tooltips AFAIK, so infowindow and tooltip can be :fire: to clean up the viz.json a bit more :)

The interactivity and options.interactivity keys in "CartoDB" layers is not used anymore by CartoDB.js, so I think we can safely :fire: those too.

layer_name is indeed extracted from options in the named map version. The same thing happens with interactivity, it is inside options in the anonymous version, but at top level on the named map version. I think we can move them both into options. Maybe we can even :fire: interactivity but I'm just speculating on that, would be nice though. Just read the last comment, :fire:ing them.
order has always been a mess, I'd remove it, as it doesn't match the order in which tables are returned (they are reordered so torque is on top).
Ok to remove infowindow and tooltip from basemaps.
So:

Removing interactivity
Putting layer_name inside options
Removing infowindow and tooltip from basemaps
Removing order

Thanks for your changes @javitonino! I'll make sure everything still works with those 👍

Updated the branch with the discussed changes. That should tidy up the vizjson a lot, so thanks for the suggestions @alonsogarciapablo!
Basemaps can surely still be cleaned up a little, as right now, we return all the options in that layer instead of explicitly listing the attributes we want in the final vizjson.
And I just realized that this is an opportunity to also remove odyssey related fields, so I'm going for it.

This seems to be playing nice with cartodb.js. I talked with @alonsogarciapablo and the plan to deploy this is to first merge cdb.js changes and bump the editor in a PR (with support for the new+old vizjson), and after that: test and merge this one.
CR @juanignaciosl

I've made some comments, all of minor. Nothing else to say about the code. This is a huge change! 💪

So I have been running some of the builder smokes, plus some privacy changes, and nothing broke. I think we can merge this. I did some backend changes (refactors, but the behaviour is the same) that I would like a CR on (@juanignaciosl). But otherwise, I will go for a merge on Monday so we have the whole week to react if something goes wrong.

Sounds 👍

I've done a minor suggestion.

One refactor leads to another indeed. I took @juanignaciosl comment (thanks!, that was a great idea for a refactor) to heart and ran with it. Please take a look.

:clap: :clap: great job @javitonino! Flat layers FTW!

So much nicer! Thank you too for the cartodb.js side. Still in awe it worked at first try! :tada:


Can't rename or delete a Folder in Prompt Flow in ai.azure.com

Is your feature request related to a problem? Please describe.
This is about usability.  If I click on a Folder in the Files view in Prompt Flow, I get the option to add a new folder or to add a new file.  I can't rename an existing folder and neither can I delete it.
Describe the solution you'd like
If I rename a folder in my PromptFlow (in VS Code) then I can't rename it (or delete it) in ai.azure.com.
Describe alternatives you've considered
PF doesn't allow any easy solutions.  I can rename or delete a file, why not a folder.
Additional context
I raised this issue months ago using the feedback tool within ai.azure.com.  Now raising in github where I hope it gets more visibility.

What extra information do you need?


Charts!

Charts!

Apply a class now (light-blue, blue, etc) instead of applying the fill directly.
Now correspond to the correct colors from the CSS.
Get darker when hovered over.
Better rendering when the browser is resized.

Now @charlie just has to plug in the data (how their marginal income is affected by these programs) :dancer:

(Also leaving this for you to look at @charlie since I think you were investigating charts last night)

Clicking on the chart does things!

Here we go!


[4.1.0rc1] Building Docker image from sources fails

Bug description
Hello Superset-Team,
we are trying to build the superset docker image from the pre-release 4.1.0rc on GitHub. Running docker build however leads to an error as seen below. This error also occurres in our CI environments. Will this be fixed in the next release?
How to reproduce the bug

git clone https://github.com/apache/superset.git
cd superset
git checkout tags/4.1.0rc1
docker build -t superset .

Screenshots/recordings

Superset version
master / latest-dev
Python version
3.9
Node version
18 or greater
Browser
Chrome
Additional context
No response
Checklist

[X] I have searched Superset docs and Slack and didn't find a solution to my problem.
[X] I have searched the GitHub issue tracker and didn't find a similar bug report.
[ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

yes this workaround fixes it. Running npm install after deleting package-lock.json did not work for me but just running npm install did. Closing the issue.

This is odd... I didn't run into it. Please give 4.1.0rc2 a test for this when it comes out soon. When that happens, it'll be announced on the dev mailing list.
If you haven't already, you can subscribe to the Apache Superset Dev Mailing Listserv<EMAIL_ADDRESS>with public visibility here) by sending an email to<EMAIL_ADDRESS>


Error occurs when attempting to delete a node that has child nodes under certain conditions

Describe the Bug
When node A in reactflow has the parentNode property, if the node B pointed to by parentNode has an index position greater than node A in the nodes array, an error will be thrown when node B is deleted: throw new Error(Parent node ${node.parentNode} not found).
Example Website
https://openai-red.vercel.app/reactflow
Steps to Reproduce the Bug or Issue

go to https://openai-red.vercel.app/reactflow
click "change nodes order".
delete "parent node 1"
reproduce the error "Error: Parent node 1 not found"

Expected behavior
No matter whether I change the order of nodes or not, deletion should not result in an error.
Screenshots or Videos
https://github.com/wbkd/react-flow/assets/169468/b39b098e-a18f-4431-b398-accda24c2e30
The error occurs when I change the order of nodes and place the parent node after the child node.
Platform

OS: macOS
Browser: Chrome
Version: Version 116.0.5845.179

https://github.com/wbkd/react-flow/pull/3433

As explained in the docs, the nodes array has to be sorted when you are working with subflows.


Feature/swift5

update project to Swift 5, and resolve some issues

@andy380743909 thanks for the PR. It just so happens that I've been planning on working on this project and some other Lua-iOS efforts (such as updating a SPM that provides a Lua interpreter). So the timing is great!
I have only spent a little time so far looking at your PR and the existing master branch and one issue I need to figure out is that when I try running (either branch) I'm not getting any keyboard input.
I just wanted to check with you to see if you had any issues along those lines and if so, did you have to do anything in particular to resolve it. Hopefully later today I'll have more time to look this over and figure out what's going wrong--possibly I'm overlooking something simple.
Also, should mention I'm using Xcode Version 11.5 (11E608c) -- which version of Xcode are you using?

Hi @profburke，the code works fine on my mac，my Xcode Version 11.5 (11E608c).
I didn't do anything with the UI, I just fixed the Swift syntax errors, so I don't know what happened with the input.
You can check whether the app is freezed, deadlocked?

@andy380743909 -- so I'm not sure what the problem was -- other than probably me just doing something dumb. Works fine now.
Thanks again for the PR.
I have one question about the last commit. So since system was remove, I agree with the need to do something to os_execute, but I'm not seeing something about what the proposed code does. It looks to me like it just forces calls to os_execute to remove subdirectories assuming that that cmd happens to be a path.
I think what I may do instead is just change os_execute to return nil and an error message. Maybe later on I might try and make use of https://github.com/holzschu/ios_system or similar.
What do you think?

@profburke I think you are right. The. solution in my PR is not good. I misunderstood the os_execute function, and just took someone's solution.
I will revert the wrong code.
The ios_system is a nice library.


Problem in the Model download cell of Paperspace.

4 hours before all worked good. Don't know, why this happened.

Tried to add "!pip install gdown". Didn't solved.

UI started to work when I switched machine. Don't know why, so, will not close until someone figure it out.

did you run the first cell ?

did you run the first cell ?

Yes. First and second cell were done. But, the had been done much faster than ussual.


Add an option to block incoming email that is considered spam

Sometimes we want some accounts do not get spam email delivered to them at all.
This is especially relevant for email accounts that have forwarding set and the mail service being forwarded to is sending back spam denial messages. This could cause our mail provider to black list some addresses, and in those cases it is best to not forward the message at all.
This is already happening with at least one account we forward email to so we need this filtering in place before we start forwarding email for that account for real.

Duplicate of GH-43


Total marks calculator docker

Changed necessary files

Changed necessary files.

Thanks for taking the time to make some code changes and submit a PR! And apologies for the delay in getting back to you.
Based on a review of the changes you've submitted, the changes appear to be focused for your specific needs and wouldn't apply to the broader community/audience. Therefore, we're unfortunately unable to accept these changes. However, you're welcome to continue to maintain your own fork!
If you have any other ideas for improvements to the project, feel free to submit a new PR or open a new issue!


make it pypi package

The current environment for doc AMR do not list all required dependencies, since it is used to install within our parser environment.
I'm under the impression that this repo is temporary, and will be merged into main branch one day, so it would be a problem.


Warning: Tried to initialize from a previous compilation (build/app.dill), but the file was not self-contained.

initialize_from.dill.gz
Thank you for taking the time to file an issue!
This tracker is for issues related to:

Analyzer
Common Front End (CFE) and kernel
Dart core libraries ("dart:async", "dart:io", etc.)
Dart VM
dart2js
dartfix
dev_compiler

Some other pieces of the Dart ecosystem are maintained elsewhere. Please
file issues in their repository:

Dart language: https://github.com/dart-lang/language
Dart website: https://github.com/dart-lang/site-www
Flutter: https://github.com/flutter/flutter
Linter: https://github.com/dart-lang/linter
dartfmt: https://github.com/dart-lang/dart_style

If you aren't sure, file the issue here and we'll find the right home for it.
In your issue, please include:

Dart SDK Version (dart --version)
Whether you are using Windows, MacOSX, or Linux (if applicable)
Whether you are using Chrome, Safari, Firefox, Edge (if applicable)

Missing some or all of the above might make the issue take longer or be
impossible to act on.
If you simply have a question, consider starting with Stack Overflow:
https://stackoverflow.com/questions/tagged/dart
For a real-time response, consider our Gitter channel:
https://gitter.im/dart-lang/sdk

@lamikam100 Thank you for submitting this bug. It appears any useful information or logs did not properly attach when the bug was submitted. Can we you please re-describe the issue and attach any relevant logs?

+1

Looks like this is the underlying issue:
https://github.com/dart-lang/sdk/issues/36032


does not work

I'm using this plugin in "neovim HEAD" and now I'm getting an error.
[denops] (translate) SyntaxError: The requested module<EMAIL_ADDRESS>does not provide
an export named 'assertString' at file:///home/mimikun/.local/share/nvim/lazy/dps-translate-vim/denops/translate/deps.ts
:7:3
[denops]     at async main (file:///home/mimikun/.local/share/nvim/lazy/denops.vim/denops/@denops-private/worker/script.
ts:71:17) {
[denops]   code: "ERR_MODULE_NOT_FOUND"
[denops] }

I solved it by forking this repository and making the following changes:
diff --git a/denops/translate/deps.ts b/denops/translate/deps.ts
index 4bd06a2..574c43d 100644
--- a/denops/translate/deps.ts
+++ b/denops/translate/deps.ts
@@ -10,5 +10,5 @@ export {
   ensureString,
   isNumber,
   isString,
-} from<EMAIL_ADDRESS>+} from<EMAIL_ADDRESS> export { openPopup } from "https://pax.deno.dev/Omochice/dps-popup-toy/mod.ts";

oops, unknownutil v3 contains breaking changes...
I'll migrate it.

I fix inyerfaces of unknownutil on 97b5ca27e5d0f34a86015f35bb1abb42468ef0a7 .
But some dependencies are outdated.
May need to re-cache deno module.

Thanks!
but An error occurred and the translation result is not displayed.

[denops] at WritableStreamDefaultController.writeAlgorithm (ext:deno_web/06_streams.js:3773:14)

Sorry, It looks the way is invalid to receive arguments...
I fixed it on 21e4a901 and checked with below version:
NVIM v0.10.0-dev-92760a7f4
Build type: Release
LuaJIT 2.1.0-beta3
Run "nvim -V1 -v" for more info

VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Sep 02 2023 19:52:05)
Included patches: 1-1850

It's solved.
Thanks!


Android 10 app not working

App not working on android 10 device

This has already been fixed in the Fix crash issue that multiple resolution separators (x & ×) are used in MediaStore commit.


nixos-rebuild: cleanup script

Motivation for this change
Applied a bunch of suggestions from shellcheck
Noticed some not-best practices when creating https://github.com/NixOS/nixpkgs/pull/126544
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

I kept the commits separate in case some of the changes are more controversial than other, I can always cherry pick the controversial ones into a separate PR

Result of nixpkgs-review pr 126547 at d809789f run on x86_64-linux 1

2 packages built successfully:

nixos-rebuild
tests.trivial

I've tried my previous workflows with this script, and they all seem to still pass. The majority of these changes I believe are pretty mundane, as they shouldn't affect behavior.


feat: Port Combinatorics.Catalan

[x] depends on: #2587

This PR/issue depends on:

leanprover-community/mathlib4#2587
By Dependent Issues (🤖). Happy coding!

This PR/issue depends on:

leanprover-community/mathlib4#2587
By Dependent Issues (🤖). Happy coding!

bors r+


event or onSubmit should be typed as SubmitEvent

I want to use the submitter property of a SubmitEvent and found no reason why the event argument passed to the onSubmit callback of Form currently is an Event.

Thanks again for your contribution to the improvement of the library! You are right. I will improve the types here with the next release.


"it is recommended" is overly passive

VSCode Version: 1.6.1
OS Version: Linux

Time for a really petty bug report. Ready?
There are several locations where VS Code uses "it is recommended" without any context, and it just feels wrong. Specific examples:

"It is recommended to keep the commit's first line under 50 characters" when typing a commit message > 50 char. What is recommending that? This could be reworded as:

"The Git style guide recommends the first line is under 50 characters."

"It is recommended to install the 'someone.something' extension" when opening certain filetypes. What is recommending this and why? Plenty of replacements here; off the top of my head:

"You may want to install '{extension}' to edit this type of file."
"The extension '{extension}' may be useful in your project." -- still kind of vague, but removes the "it" that doesn't refer to anything
"This filetype can be handled by the '{extension}' extension in the Marketplace."

You can see more in a search, though the two above are the main ones that are a little bothersome.

Worth thinking about, although I'm not sure where to send this issue.

I think it's a sound recommendation to improve the user experience. Good feedback.

Just came here to add this as an issue, as well. "It is recommended..." immediately tripped my "non-native speaker" alarm because it's a very common phrasing that, for examples, some of my Romanian colleagues would use.
It's technically correct, of course, but doesn't feel right as OP stated, with examples.
unrelated, but it took me a while to figure out why this was tagged as "polish" when it's clearly only an English issue.

Just had one of these pop up saying "It is recommended to install the docker extension" when I wasn't doing anything with docker. Ended up here wondering if advertising was introduced to Code or something, so I definitely think it's worth changing.


Improve fragment methods and normalisation

The fragment api is awkward especially with fragments on queries etc. I believe there's room for improvement and possibly implementing our own normalisation.

https://github.com/gql-dart/ferry/pull/359

Normalize 0.6.1 has been released which addresses these issues.

Do we need to release a new version of our package? I did not check our pub spec

The new version should be covered by our version range, so I expect not.


Add unit test scenarios for UnsavedRelationList

Not entirely sure what triggers an UnsavedRelationList to exist. Will need to look into that. First guess is that it might be when an unsaved model is added to a DataList?
$model = NewModel::create();
// $model hasn't been saved yet
$page->Models()->add($model);

I think it's the other side of the relation not being written yet which triggers this
$page = Page::create();
$page->Models()->add(SomeModel::get()->first()); // I think $page->Models() is an `UnsavedRelationList`


ENH: Add Snakemake as a language to Linguist, so snakemake files are distinguishable from Python

Github uses linguist to categorize programming languages.
It would be great if snakemake was supported. Yes, it's a superset of Python, so may be classified as Python. But it really isn't valid Python and so classifying it separately would be helpful.
This could be a great "help wanted" and "good first issue" issue, as anyone can contribute:
https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding-a-language
smk should tick all the boxes (correct me if I'm wrong).
One benefit would be that snakemake shows up distinctively in such stats:

Ah that's amazing! :) Can't wait for this to percolate all the way through to syntax highlighting on Github, and maybe also StackOverflow etc
The ENH: label I learned from numpy. Meant for commit messages but I think it's just as useful for issues.

API: an (incompatible) API change
BENCH: changes to the benchmark suite
BLD: change related to building numpy
BUG: bug fix
DEP: deprecate something, or remove a deprecated object
DEV: development tool or utility
DOC: documentation
ENH: enhancement
MAINT: maintenance commit (refactoring, typos, etc.)
REV: revert an earlier commit
STY: style fix (whitespace, PEP8)
TST: addition or modification of tests
TYP: static typing
REL: related to releasing numpy
https://numpy.org/doc/stable/dev/development_workflow.html#writing-the-commit-message

Next logical step would be to get syntax highlighting via highlight.js : https://highlightjs.readthedocs.io/en/latest/language-requests.html
Thanks @SilasK for getting in a time machine and opening a PR a month ago :D

Next logical step would be to get syntax highlighting via highlight.js : https://highlightjs.readthedocs.io/en/latest/language-requests.html Thanks @SilasK for getting in a time machine and opening a PR a month ago :D

There is already a highlighting for VIM https://github.com/snakemake/snakemake/blob/main/misc/vim/syntax/snakemake.vim and VScode https://github.com/snakemake/snakemake-lang-vscode-plugin/blob/master/languages/snakemake.json. You might peak into them for inspiration.

For the linguist, I simply set the python highlighter as before. Before snakemake was a sublanguage of python on linguist. I don't know exactly how to change this.  For linguist it requires a github with a highlight grammar https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding-a-language
Does this exist for snakemake?

Prior art of a highlight grammar may be in @maarten-k's references. The VS Code extension highlighting grammar is ok but could be better - maybe it's just raw Python, haven't looked.


Customizable Marketplace message for denylisted extensions and extension updates

This feature request is an add-on to the extension allowlist/denylist under development in https://github.com/microsoft/vscode/issues/84756. cc @isidorn who requested that this be filed as a separate request.
The VS Code Marketplace is a great place for engineers to discover new extensions directly in their editor. We would love to maintain the usability of this Marketplace even with a strict allowlist policy in place so that our engineers have actionable information on what to do to allowlist an extension (or its update) within our organization.
Organizations will have different procedures for modifying the allowlist. Stripe has an online approval flow for new software dependencies that would be augmented with VS Code extensions once the  allowlist functionality is available. Users would need to navigate to this form, fill it out for the specific extension and version, and get it approved.
It would be wonderful if VS Code supported modifying the message that shows up or is displayed when an extension is denylisted. If the message could be templated with the extension_id and version, we could even render a link directly to a pre-filled out web form, which would remove a lot of the friction from allowlisting a new extension.
For example, we might render something like:

$extension_id@$extension_version is not an approved VS Code extension at Stripe. You can begin the approval for this extension at http://go/vscode-extn/$extension_id@$extension_version

Ideally, the link would be clickable and redirect to the relevant form, with most fields pre-filled out.
If there is no UI space for an interactable message like this, then I would also accept a configurable URL (templated with extension ID and version) that is put somewhere for the user to visit for more info; we could link to a templated help document that then links to the form if the user decides they want to allowlist the extension. (Maybe a "More info" button or link?)

Very useful.+1 pls.

At present we show following message for the policy enabled settings:

Oof, that is a discouraging message. In our organization, it can be changed, but via a specific process.


latest version marked as 1.20.1 compatible but its not

Describe the bug
https://modrinth.com/mod/fabricbettergrass/version/1.0.3+1.20.6 marked as 1.20-1.20.6 compatible, but i cant load 1.20.1 with this version
To Reproduce
Steps to reproduce the behavior:

Download 1.0.3
launch minecraft 1.20.1
crash

Expected behavior
Work on marked versions
Desktop (please complete the following information):

OS: windows 11
Minecraft 1.20.1
Fabric Loader version 0.15.11
Mods fabric api and midnight lib
Version 1.0.3

Can you provide logs? (preferably upload it to mclo.gs)

Fixed! This version was supposed to support 1.20-1.20.6 but the new automated publishing script uploaded the wrong file, making this version crash!
this means there was a similar crash with all the other mc versions too 😅


Fix surveys

remove experiment service

[x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
[x] Title summarizes what is changing.
[ ] Has a news entry file (remember to thank yourself!).
[ ] Appropriate comments and documentation strings in the code.
[ ] Has sufficient logging.
[ ] Has telemetry for enhancements.
[ ] Unit tests & system/integration tests are added/updated.
[ ] Test plan is updated as appropriate.
[ ] package-lock.json has been regenerated by running npm install (if dependencies have changed).

Codecov Report

Merging #4838 (cf26d7e) into main (68b67c2) will decrease coverage by 25%.
The diff coverage is n/a.

@@           Coverage Diff            @@
##            main   #4838      +/-   ##
========================================
- Coverage     72%     47%     -26%
========================================
  Files        410     279     -131
  Lines      26940   19128    -7812
  Branches    3902    2936     -966
========================================
- Hits       19540    9086   -10454
- Misses      5877    9314    +3437
+ Partials    1523     728     -795

Impacted Files
Coverage Δ

src/client/datascience/liveshare/postOffice.ts
4% <0%> (-84%)
:arrow_down:

src/client/common/refBool.ts
16% <0%> (-84%)
:arrow_down:

src/client/datascience/liveshare/serviceProxy.ts
5% <0%> (-83%)
:arrow_down:

src/client/datascience/raw-kernel/rawSocket.ts
4% <0%> (-81%)
:arrow_down:

...ce/interactive-window/interactiveWindowProvider.ts
16% <0%> (-76%)
:arrow_down:

...nt/datascience/interactive-common/serialization.ts
9% <0%> (-73%)
:arrow_down:

...ractive-common/interactiveWindowMessageListener.ts
17% <0%> (-73%)
:arrow_down:

...rc/client/datascience/jupyter/debuggerVariables.ts
8% <0%> (-73%)
:arrow_down:

src/client/datascience/jupyter/jupyterNotebook.ts
4% <0%> (-72%)
:arrow_down:

...atascience/jupyter/jupyterSessionManagerFactory.ts
28% <0%> (-72%)
:arrow_down:

... and 298 more


Introduce SPI for creating Mistral AI Client

This is very similar to what is done for OpenAI and it will directly enable this
cc @langchain4j

Summary by CodeRabbit

New Features

Introduced a new client for interacting with Mistral AI services, enabling chat completions, streaming chat completions, embeddings, and model listings.

Refactor

Updated MistralAiClient to an abstract class with enhanced functionality and a new builder method for configuration.

Chores

Changed access modifiers of several classes and methods from package-private to public, improving their usability across the codebase.

🙏🏼


jfsCache is using too much disk

the /var/jfsCache  directory is becoming larger and larger, is this normal and Can I change to other directory?

Please check and read https://juicefs.com/docs/community/guide/cache/#client-read-cache


Pricing page

What does this pull request do? Explain your changes. (required)

Specific updates (required)

How did you test each of these updates (required)

Does this pull request close any open issues?

Screenshots (optional)

Checklist

[ ] I have read the CONTRIBUTING document.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.

Don't green light yet, still need to wire some elements up correctly

When opening the Pricing page there is a warning in console that would be nice to be addressed: Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://reactjs.org/link/unsafe-component-lifecycles for details.
It was probably not introduced by this PR, but it's still something that we want to address so to it makes it easier to keep updated with the latest Next.js versions

Just be aware this is coming from React Reveal, going to try and update, but if that doesn't work will need to assess whether console issue is more or less important than fade animations.

Also just cleared all console logs, shouldn't have any additional issues, notice rehydration issue related to next link


Allow for richer validation

This PR paves the way for allowing for richer validation by taking into account all of the current values as well as the type of operation being performed.
It also paves the way for overloading the validation to perform serialization.

Pull Request Test Coverage Report for Build 2596

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 2595:
0.0%

Covered Lines:
21

Relevant Lines:
21

💛  - Coveralls


Upgrade flutter-devicelab-mac-15 to latest Big Sur beta

We have reports https://github.com/flutter/flutter/pull/68050 doesn't work on newer betas.  Upgrade flutter-devicelab-mac-15 (currently running 20A5299w) to the newest beta (currently beta 10).

Tried updating via System Preferences, but hit
An error occurred while downloading the selected updates. Please check your internet connection and try again.

Following https://developer.apple.com/forums/thread/653343?answerId=632205022#632205022, tried downloading it directly and then upgrade, but hit:
This copy of the Install macOS Big Sur Beta application is damaged, and can‘t be used to install macOS.

That's unfortunate, looks like a common problem too.  Are you able to restore it from the new image without going into the lab? Or boot into recovery mode? https://developer.apple.com/forums/thread/653347

Tried a couple of times, but the new image doesn't work..
Manual intervention seems needed for boot to recovery mode. Once we reboot, we are losing connection to the bot, then not able to press any button to enter the recovery mode from remote.

@jmagman did you get access to the lab to get the machine?

Got it! Being able to book into recovery didn't help, I'm stuck on beta 1.  Waiting for @timsneath to send me the ipsw to try restoring with Configurator.

I was able to restore to beta 10 with the ipsw.  Closing.


InMobi Adapter IllegalState

MAX Module Version
4.1.5
React Native Version
0.70.2
Device/Platform Info
Android
Current Behavior
Hi,
I've a lot of these issue since I implement InMobi ads into my app through AppLovinMAX
legalStateException
Calling View methods on another thread than the UI thread.

Android Version
Android 11 33%
Android 12 22%
Android 10 21%
Android 9 12%
Other 9%
Thanks
Expected Behavior
No response
How to Reproduce
Implement last version of InMobi Adapter
Additional Info
No response

Looks to be an issue with InMobi's latest SDK. We've downgraded the SDK in our latest adapter v<IP_ADDRESS>:
https://github.com/AppLovin/AppLovin-MAX-SDK-Android/commit/fb2fc9efd7a314f6cafe46d8fea447cf948b7a6b

Hi @jonathanroze, We've released InMobi Android adapter v<IP_ADDRESS> certified with v10.1.3 of InMobi's SDK. You should no longer see the crash.
You can find the changes here: https://github.com/AppLovin/AppLovin-MAX-SDK-Android/commit/6dd9e0d681a6d4b570753b33978512d9e61e5605


⚠ Bofrost.lu has degraded performance

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

HTTP code: 200
Response time: 1366 ms

Resolved: Bofrost.lu performance has improved in 7e6d778 after 6 minutes.


Update logger url [#175337534]

DO NOT MERGE: need to wait until production log-ingester is adding ids to the logs.

@scytacki It is also failing on master so I added a PT story to fix it:
https://www.pivotaltracker.com/story/show/184047920


Clallbacks: Cannot feed value of shape (16, 128, 128, 1) for Tensor 'conv2d/truediv:0', which has shape '(?, 128, 128, 3)'

The project is much beneficial for me! Howeverm I got an error when traning at the code (outs = sess.run(tensors, feed_dict=ins)) in the file callbacks.py. The detail is following:
1/157 [..............................] - ETA: 29:39 - loss: 0.17492019-10-28 20:54:58.429846: I tensorflow/core/platform/default/device_tracer.cc:641] Collecting 1361 kernel records, 15 memcpy records.
156/157 [============================>.] - ETA: 0s - loss: 0.0912<class 'list'>
<class 'dict'>
self.model.total_loss: Tensor("loss_1/mul:0", shape=(), dtype=float32)
metrics_tensors: {}
self.model.outputs: [<tf.Tensor 'conv2d/truediv:0' shape=(?, 128, 128, 3) dtype=float32>]
W1028 20:55:51.747634<PHONE_NUMBER>63296 deprecation_wrapper.py:119] From /home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/callbacks/callbacks.py:334: The name tf.keras.backend.get_session is deprecated. Please use tf.compat.v1.keras.backend.get_session instead.
tensors:  [<tf.Tensor 'loss_1/mul:0' shape=() dtype=float32>, {}, <tf.Tensor 'conv2d/truediv:0' shape=(?, 128, 128, 3) dtype=float32>]
Cannot feed value of shape (16, 128, 128, 1) for Tensor 'conv2d/truediv:0', which has shape '(?, 128, 128, 3)'
Traceback (most recent call last):
File "/home/taoh/.vscode/extensions/ms-python.python-2019.9.34911/pythonFiles/ptvsd_launcher.py", line 43, in
main(ptvsdArgs)
File "/home/taoh/.vscode/extensions/ms-python.python-2019.9.34911/pythonFiles/lib/python/ptvsd/main.py", line 432, in main
run()
File "/home/taoh/.vscode/extensions/ms-python.python-2019.9.34911/pythonFiles/lib/python/ptvsd/main.py", line 316, in run_file
runpy.run_path(target, run_name='main')
File "/home/taoh/anaconda3/envs/3Dircadb_Use_Unet/lib/python3.6/runpy.py", line 263, in run_path
pkg_name=pkg_name, script_name=fname)
File "/home/taoh/anaconda3/envs/3Dircadb_Use_Unet/lib/python3.6/runpy.py", line 96, in _run_module_code
mod_name, mod_spec, pkg_name, script_name)
File "/home/taoh/anaconda3/envs/3Dircadb_Use_Unet/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/bin/train.py", line 344, in
entry_func()
File "/home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/bin/train.py", line 340, in entry_func
raise e
File "/home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/bin/train.py", line 336, in entry_func
run(project_dir=project_dir, gpu_mon=gpu_mon, logger=logger, args=args)
File "/home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/bin/train.py", line 290, in run
hparams=hparams, no_im=args.no_images, **hparams["fit"])
File "/home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/train/trainer.py", line 122, in fit
raise e
File "/home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/train/trainer.py", line 107, in fit
val_ignore_class_zero)
File "/home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/train/trainer.py", line 215, in _fit_loop
self.model.fit_generator(**fit_kwargs)
File "/home/taoh/anaconda3/envs/3Dircadb_Use_Unet/lib/python3.6/site-packages/tensorflow/python/keras/engine/training.py", line 1433, in fit_generator
steps_name='steps_per_epoch')
File "/home/taoh/anaconda3/envs/3Dircadb_Use_Unet/lib/python3.6/site-packages/tensorflow/python/keras/engine/training_generator.py", line 331, in model_iteration
callbacks.on_epoch_end(epoch, epoch_logs)
File "/home/taoh/anaconda3/envs/3Dircadb_Use_Unet/lib/python3.6/site-packages/tensorflow/python/keras/callbacks.py", line 311, in on_epoch_end
callback.on_epoch_end(epoch, logs)
File "/home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/callbacks/callbacks.py", line 428, in on_epoch_end
TPs, relevant, selected, metrics = self.predict()
File "/home/taoh/Project/DeepLearning/Examples/AwesomeExLearning/MultiPlanarUNet-master/MultiPlanarUNet/callbacks/callbacks.py", line 353, in predict
outs = sess.run(tensors, feed_dict=ins)
File "/home/taoh/anaconda3/envs/3Dircadb_Use_Unet/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 950, in run
run_metadata_ptr)
File "/home/taoh/anaconda3/envs/3Dircadb_Use_Unet/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1149, in _run
str(subfeed_t.get_shape())))
ValueError: Cannot feed value of shape (16, 128, 128, 1) for Tensor 'conv2d/truediv:0', which has shape '(?, 128, 128, 3)'

And the shape of X_ins is (?, 128, 128, 1), the shape of y_ins is (?, 128, 128, 3), and the shape of tensor is  (?, 128, 128, 3).

The model is

Hi!
Your y_ins should be of shape (?, 128, 128, 1) with each entry giving an integer-valued label. That is, values in {0, 1, 2} in your case for a 3-class problem. I would expect that you have your label maps stored in one-hot encoding (which would be normal, but not what is used here).
I am, however, surprised that you did not get a more appropriate error message - so perhaps this is not the error. I will look into it later this week as soon as I have more time.
If this does solve your issue let me know.

Hi! Thank you for your reply! One thing I did not mention. I changed slightly your code in the callbacks.py
(y_ins = {in_tens: in_ for in_tens, in_ in zip(self.model.targets, y)}  --> y_ins = {in_tens: in_ for in_tens, in_ in zip(self.model.output, y)}),
due to the error "Unet object has no attribute 'targets' "

And I tried doing binary segmentation. The error still exists.

So I think that one-hot encoding cannot solve the problem.

Hi! I think I understand it. The problem is the code of callbacks.py:
'y_ins = {in_tens: in_ for in_tens, in_ in zip(self.model.targets, y)}', because I changed 'targets'(,,,1) to 'outputs'(,,,2) for binary segmentation.
However, I still do not know the placeholder variable name of y_ins due to the error "Unet object has no attribute 'targets' ".
Best Wishes,
Tao H

Hi! Maybe I solved the problem. I replaced 'targets' with '_targets' and it works. However, I do not known if it is true.

Best Wishes,
Tao H

Hi,
Please update to the latest version (0.2.4) with TensorFlow >=2.0. If you still receive this error, please raise a new issue.
Cheers,
Mathias


"Unprotected" Warning

There should be some sort of indicator on the main screen that is really obvious and obnoxious when you're running in a mode that is preventing the save function from working.

Warning message will be in next build. Most likely 4.2.0

I get the warning message popping constantly, even when the save functionality seem to be working fine.

problem fixed, the program encounters some random errors when saving due to too many things happening at once and it is trying to save too quick since the last save. Yeah, I save pretty much constantly. This caused an error in saving because the lock hadn't been released on the file since the last save. I've not modified it to remove the message if a successful save happens. Completely untested, but hey, whatever, we'll see what happens.


Clustering of Overlays

Hello :)
I would love to use clustering for my overlays, just like this package (https://angular-maps.com/api-docs/js-marker-clusterer/modules/AgmJsMarkerClustererModule.html) does it, so that you basically put a wrapper, maybe called 'agm-overlay-cluster', around the overlays and they get grouped on specific zoom levels, depending on the density (if they are too near to each other).
Another method I could imagine (if it's not too complex to develop) is, that you can put a value on each overlay and the most valuable ones are filtered out on lower zoom levels (like here on checkfelix: https://www.checkfelix.com/explore/). For example if I have 15 blog entires in city A and 20 in city B, the more valuable one (B) is filtered out if I zoom out and they are about to collide (and A disappears, or just gets smaller).
But again, I'd also be happy if the basic clustering method works, but if this is even easier, or as much effort to develop as method 1, I would prefer this one :)
It would be awesome if you implement one of those functionalities!
Have a great day!

Acknowledged. Will get back. I estimate maybe we could do this in two weeks.
One thought I’m thinking, is just to feed back the zoom level and make it the developers choice as what to show.  We shall see

@tsgreenberg1217 . It’s being a hot topic for us to add clustering to our package

yeah, it would be a cool feature!

Todd has already begun to show success here with clustering by img url reference. We may have something by the end of this week.
Not to self: here is the existing clustering code from the agm/core:
https://github.com/SebastianM/angular-google-maps/tree/master/packages/js-marker-clusterer

Todd has already started to show progress on this item and it is now a branch called clusterer.
It will still take us the rest of the week to finalize a first run. Todd has just showed proof of concept


Build(deps-dev): Bump @types/node from 18.8.3 to 18.8.4 (#4186)

Pull request opened by the merge tool on behalf of #4186

Merged in 83c67ecc03d0fe13dd5346593a00b87dfe99ab0d


Submodules support

Fixes #1344
This PR removes the prior implementation of git SubModules support and replaces it with a version, which is optional.
In .github/AL-Go-Settings.json you can add the following settings:
"useSubModules": "recursive",
"subModulesTokenSecretName": "ghTokenWorkflow"
to enable SubModules support and use the ghTokenWorkflow secret for checking out submodules.
If the SubModulesTokenSecretName is not specified, AL-Go will look for a secret called subModulesToken.
If a secret called subModulesToken is not provided, AL-Go will use the github.token.

TODO:

[x] Release Notes
[x] Update secrets.md
[x] Update settings.md

Minor: subModules should be submodules all around.

Have renamed and added git in front of everything

How about having a custom AL-Go-specific composite checkout action that handles the git submodules logic?

actions/checkout without submodules to be able to read the settings
depending on the new useSubmodules setting and secret, do the appropriate checkout.

This way the workflows won't be so polluted, and the logic will be centralized.

We could do that - not sure how much we gain from that - would rather see whether this solves the issue before adding refactoring task to this.

As I mentioned, if it's a single action, the workflows won't be so polluted (just the current actions/checkout will be replaced with AL-Go-Actions/checkout that will take care of reading the needed settings, secrets and checking out the code). Currently, the following is duplicated across build workflows and it doesn't have to be:

And yes, I acknowledge that - but this is really a bug fix to make sure that people upgrading won't have to downgrade.
I will add an item to the backlog to fix this - it isn't faster to fix it now than fixing it later - and this would include quite some new risks,


Fix AutoCF's reference-stealing value move constructor

This commit replaces AutoCF<T, L>(T&&) with
AutoCF<T, L>(TakeOwnershipT, const T&) to clear up the confusion between
the const ref constructor (+1 refcount) and the value move constructor
(+0 refcount; reference-stealing).
Fixes #2447.
NOTE: This commit introduces changes in WinObjC.Language, and proper consumption will require a new package to be built. However, the framework-side changes do not depend on the new SmartTypes changes and will function properly without them.

I'm going to dismiss some of your reviews to re-review some new changes. Since it's comparatively difficult to revise WinObjC.Language files, I'd like to get the AutoId TakeOwnershipT stuff in today.

@rajsesh-msft @bbowman I dismissed your reviews because I specialized AutoId for TakeOwnershipT as well.

With these changes, we no longer need to do this:
AutoId<NSObject> thing;
thing.attach([NSObject new]);

We can instead do this:
AutoId<NSObject> thing{woc::TakeOwnership, [NSObject new]);


Fix: errors when wasm32 is targeted.

There were compilation issues when target is wasm32-unknown-unknown due to:

Window::set_inner_size being used while not being defined instead of Window::request_inner_size
window.canvas() not being unwrapped before being Intoed

There were unreachable code due to misspellings of  feature in comfy-wgpu.

Closing to fix coding style issues


Clear indication of completion and status

It's not as obvious as it should be whether fMRIPrep finished successfully or not.
Perhaps a quick summary:

X subjects successfully run
Y errors encountered

And some flagging characters, such as *******[...], to make sure people see it.

Is there currently any way to determine if fmriprep has stopped processing? A file that does or does not exist, perhaps?

The HTML reports are written at the end. That's probably the best indicator at the moment.

There is this https://github.com/poldracklab/fmriprep/blob/4cb3385ec8389ff62fbd375385a7c03327f523f3/fmriprep/cli/run.py#L404

When might that start appearing?

That's been there for long. Not sure why it doesn't really show up. But it is probably working because we are identifying about 60% of the runs as successful in sentry (and that means this line must be hit at some point).
We'll look into this - it could be that you only see it if you are running with --notrack.

In the 312 fmriprep jobs we've "successfully' run so far, we've seen it 0 times.
I'd love to see something even more explicit like I mentioned in #1922 someday.

It might need a -v or -vv.

While working on the config file, it seems that for some reason the level of the 'cli' log is modified, or the log is shut down at some point.
Long story short, writing that log entry into the workflows log made it show up in my tests.
Should be a really easy fix.


Free react course in 1 hour + CERTIFICATE

I am participating in Hacktoberfest 2021, and I have found a free react course.
LINK : https://www.udemy.com/course/react-basic-in-just-1-hour/

@Ankurrsingh you have to add free courses with certificate,in this course they will not provide certificate so add another , I'm closing the issue.


Adding some utility functions to cache:

GetRefresh: Get item from cache, update TTL. This allows users to store resources in cache and have them automatically removed if they haven't been used for X amount of time
GetRefreshDefault: Same as GetRefresh with default duration (=~ SetDefault)
Pop: Get elements from cache, and remove them

TODO (and soon to follow)
A couple of tests covering these 3 functions

Found this fork: https://github.com/arp242/zcache


IL3820 driver cleanup

Preparing the IL3820 for portrait and landscape support, it currently crashes when configured as portrait.

Got it working with the Hello World label of the demo project, will test it with more widgets and it definitely needs some code style improvements.


Postgres and ARRAY_AGG panick

What language are you using?
Python.
What version are you using?
Python 3.10.6
connector-x version 0.3.1
What database are you using?
PostgreSQL
What dataframe are you using?
Pandas
Can you describe your bug?
Running a "normal" SQL query works fine, but when the query contains an "array_agg" function the read_sql call fails.
What are the steps to reproduce the behavior?
This works fine
conn = "postgresql://......"
cx.read_sql(conn, """
  SELECT
    a.id
  FROM table_a a
  JOIN table_b b ON a.id = b.id
  LIMIT 10
""")

This panicks
conn = "postgresql://......"
cx.read_sql(conn, """
  SELECT
    a.id,
    ARRAY_AGG(b.id) AS b_id_list
  FROM table t
  JOIN table_b b ON a.id = b.id
  LIMIT 10
""")

For the above, the type of both ids is UUID so the panick is:
thread '<unnamed>' panicked at 'not implemented: _uuid', /__w/connector-x/connector-x/connectorx/src/sources/postgres/typesystem.rs:100:22

For an aggregation on a varcahr column, the panick is the same as the above but with the varchar not implemented message.
Database setup if the error only happens on specific data or data type
Nothing special, just 2 tables with any type of postgres data dypes.

Thanks for the issue. The reason for the error is that we cannot support uuid arrays in postgres currently, which will be eventually converted to object (string) array in pandas. I will redirect this issue to #121


carousel contents collide when going left for the first time

When clicking the right arrow on the carousel, the current content exists to the left and the next content enters from the right, just as expected.
When clicking the left arrow on a carousel, the next content correctly enters from the left. However, the current content also exists to the left, instead of to the right. For all subsequent left-arrow clicks, it works as expected.
The same wrong behavior is also observed when clicking the right arrow after having clicked the left arrow at least once.

The fix should be merged in shortly and will be released in 0.13.3 likely around Wednesday.


Help with RadeonVII error "atombios stuck in a loop" (not a ROCm issue)

This is not a ROCm issue, I know; but maybe somebody in the know could kindly help me a bit:
On Ubuntu 20.04 (Linux kernel 5.3.0-18) a Radeon VII GPU fails at initialization (boot) time with this message in dmesg:
[drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing 9300 (len 1031, WS 12, PS 8) @ 0x93A0
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing 9274 (len 63, WS 0, PS 8) @ 0x9295
amdgpu 0000:67:00.0: gpu post error!
amdgpu 0000:67:00.0: Fatal error during GPU init
[drm] amdgpu: finishing device.

What does this mean -- is the GPU hardware-damaged beyond repair? or is there anything that can be done to fix the GPU?
Thank you!

I have already seen this error and recovered by reinstalling. Try changing your riser if you have one, if that does not work it is possible a kernel issue.
Which kernel do you use?

Thanks @preda for reaching out.
I will check with our kernel team and get back with possible solution.
Thank you.

Most likely it indicates a hardware failure. The kernel can't read the VBIOS, which is a big problem, and isn't likely to be software. Try powering off for 30sec and restarting. If it still fails, I'd recommend the usual HW testing before an RMA (switch PCIe slots, try a different motherboard, different power connectors from PSU, etc)
Thank you.

Most likely it indicates a hardware failure. The kernel can't read the VBIOS, which is a big problem, and isn't likely to be software. Try powering off for 30sec and restarting. If it still fails, I'd recommend the usual HW testing before an RMA (switch PCIe slots, try a different motherboard, different power connectors from PSU, etc)
Thank you.

I have seen this error and recovered by rolling back to a previous kernel.

@ROCmSupport thank you for the communication!
@valeriob01 I diagnosed the affected GPU by swapping it with another good GPU of the same model, so I ruled out a software issue (the GPU itself is affected). I was just wondering whether the GPU breakage is "soft" and can be fixed "at home" or it's up for RMA. Seems like the latter, and the GPU was RMA'd already. I'm still not clear on what triggered the problem.

@ROCmSupport thank you for the communication!
@valeriob01 I diagnosed the affected GPU by swapping it with another good GPU of the same model, so I ruled out a software issue (the GPU itself is affected). I was just wondering whether the GPU breakage is "soft" and can be fixed "at home" or it's up for RMA. Seems like the latter, and the GPU was RMA'd already. I'm still not clear on what triggered the problem.

So it seems your case is more severe than mine and this error same can be triggered under different conditions.